专业的家居行业网站模板,有网站代码怎么建站,重装电脑后下载wordpress,做电子商务网站 语言所有(去掉 “几乎” 修饰)问题都来自于生长速度的不一致#xff0c;换句话说#xff0c;膨胀不是均匀的#xff0c;从而产生瓶颈甚至触碰极限#xff0c;TCP/IP 从协议到实现面临的多方问题与动物体型不能无限大#xff0c;摩天大楼不能无限高本质上一样。
如今被高性能网…所有(去掉 “几乎” 修饰)问题都来自于生长速度的不一致换句话说膨胀不是均匀的从而产生瓶颈甚至触碰极限TCP/IP 从协议到实现面临的多方问题与动物体型不能无限大摩天大楼不能无限高本质上一样。
如今被高性能网络诟病的 BSD socket API 诞生之初的姿态是非常高的1980 年代的网络非常慢CPU 通过 socket API 不慌不忙地喂数据在当时是一个很直接很简单的方式就算加上拷贝上下文切换的拖累网络依然相对很慢。彼时如果能料到网卡终有一天会远超 CPUsocket API 可能就会以一种更容易扩展的形式存在。如果认识到网络只是在当时慢但总归会变快socket API 便会以更集约的方式而不是慢吞吞地将数据准备好。
如今的 DPDK零拷贝技术终究还是以 work around 出现几乎已经成了事实标准但存量应用程序非常难(几乎不可能)迁移到新方案以获取高性能。现在网络快而 CPU 慢再设计网络 API它不应该是反过来(与 socket API 相反)慢吞吞将数据交给主机而且网卡集约处理更多逻辑也就是小经理们都正在做的事不吹不黑这事(至少目前)靠谱。
再看协议本身IP 报文长度被限制在 64kB可以太网 MTU 却只有 1500这种错配意味着什么虽然大家都清楚分层模型在层间不必耦合各做各的但总会有现实考虑。
设想 IP 允许一个无限长(64bit128bit)的报文长度当需要在物理网络上发送这样的一个报文时链路将回退到电路交换而这正是分组交换网要避免的即避免长时间占用线路。考虑到典型的 T1E1 链路发送一个占用线路不超过一个容忍值的报文求其最大长度。64kB 在 1.5Mb/s T1 链路占据 0.3s 显得稍久但能容忍同时考虑实际物理链路 MTU 有限以及网络带宽会随技术发展不断提高这个实际的时间会更短且越来越短而 64kB 仅由 16bit 即可表达对带宽和内存要求也不大。
随着带宽逐渐增大压力给到了主机因为发包收包越来越快一个报文的持续间隔相对越来越短主机被中断的频率越来越高64kB 的长度显小了tcp: BIG TCP implementation 我引用好几次但终究是 work around。IPv6 仍然维持 64kB 长度限制但允许扩展头发送巨型报文这个方式就不错兼容和扩展都有了。
以上两例旨在说明主机和网络发展不对称CPU 和网卡的增长率不同产生了最初的设计并导致了最终的反转然后 work around 以及下一代的修复如此再循环。
这些经验教训似乎表明所有旧时的设计都是不足够的但并非总是如此。
继续看 TTL只有 8bit在带宽内存资源看似可以浪费的现在8bit 是一个让人看一眼就觉得可怜就想拉长的字段但它应该更长一些吗
高速转发最大的阻力就在交换节点(路由器和各类交换机)随着带宽增长以及路由(主要是增量 IPv6 路由)汇聚规整化更小的路由表在基建方面倾向于推动建设更长的链路端到端的跳数应该减少而不是增加。全球的地理范围有限网络扩展倾向于跳数增加但路由汇聚抵消了新增的那一跳互联网旨在构建连通性而不是在织蜘蛛网。所以直到 IPv6TTL 依然只有 8bit。
再看 IP 地址本身32bit 显然太短但 160bit 绝对太长了这是一个有争议的问题IPv6 取 128bit 属折中这里换一个视角IPv6 128bit 的地址长度最大的问题在于地址空间大小和期望特性间的错配。
书写记忆难度以及配置问题不值得一提毕竟 IPv4 地址也不太容易书写记忆所以才有了 DNS且不必说计算机系统处理海量信息能力对人而言本就是降维打击。
过于庞大的地址空间意味着几乎无限的分配可能性若稀疏分配路由表的存储以及查询开销将变得巨大若紧凑聚合分配理论上离散的地址将聚集在一起有助于减小路由表条目但也抵消了抗扫描的优势此外稀疏的空间抗扫描的同时也几乎让攻击溯源变得不可能。各类 trade off 是非常难的地址空间越大问题越难越容易遗留问题。
128bit 地址空间倾向于被塞入很多层间信息(反正够用)让人更容易以浪费的理念去使用。但不要忘了塞入更多信息意味着暴露更多信息这又是一个争议话题。MAC 地址位置类型甚至公司机构的规模都可能会被映射进地址空间而 IP 的初衷只是一个 best-effort 核无状态不记名128bit 空间本无碍大地址空间便于路由管理但它太大也容易被误用。
下一个问题TCP/UDP 端口号 16bit如果有下一代协议它应该扩展到 32bit 吗
事实上很少有人意识到这个问题但很多工人都遭遇并排查过 timewait socket 太多导致建连失败bindconnect 的 CPU 热点问题在此背景下很多把戏应声而出包括魔改内核缩短 timewait 时间stap -g 硬改 timewait 状态甚至 Linux 内核在 bindconnect 分别遍历奇偶端口号选择端口而这正是 CPU 热点的根源总之一塌糊涂。
本质上这是由于 16bit 端口号空间过小导致。如果扩展到 32bit问题就迎刃而解。主机简单递增并选择全局 32bit 变量作端口号即可毫不费力。
随着网络速度越来越快越要解放节点算力。随着网络带宽相对于主机的加速度越来越大传输每字节的主机时间越来越小因此协议必须越来越简洁减少计算量具体实例参见 QUICFalcon 等。
最后来看 TCP 序列号32bit 够吗
在 19701980 年代足够了但随着带宽增加序列号回绕问题必须面对同时 32bit 的序列号空间也限制了最大 rwnd 只能达到 2^30(就这还是在 wscale 选项的支持下)导致更大的带宽无法被充分利用。同样的各种复杂且难以理解的把戏就来自于这种原始设计的向后不兼容性。
设计一个向后兼容的序列号表示法并不难由于数据包的自解释性TLV 及其变体是常见的方式。可以限制最大的序列号空间为 16Byte这是个天文数字足够度量现实中可以想象的任意数据的长度因此一个序列号可以是 116Byte具体多少取决于一个额外的 4bit 长度比如它是 1110b说明后面 15Byte 都是序列号。
先这样这就是今天要讲的故事。
浙江温州皮鞋湿下雨进水不会胖。
