说说过量 tcp pure ack 的利弊

这篇具有很好参考价值的文章主要介绍了说说过量 tcp pure ack 的利弊。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

tcp 的 ack 实在太多了,如果互联网上 80% 报文是 tcp,那么其中 1/3 的报文都是 ack,此前写过几篇短文,比如 丢弃一些 pure ack 和 注入或利用 pure ack。

简单说,tcp 依靠 ack 提供 self-clock,发送 data 越多,ack 越多,如果 ack 与 data 不同步,将出现各种问题,详见 rfc2525-Stretch ACK violation。

正如哥斯拉将会压垮自身一样,tcp 的 pure ack 也会随着带宽进一步提高对系统带来越来越大的重负。pure ack 是小包,与 data 数量线性同步的 pure ack 对系统带来不对称的压力,系统最怕高频小包。

典型的三种场景不得不防,pure ack 在 sender/receiver 端与 data 竞争 cpu,pure ack 在 wifi 等 csma 网络与同流 data 竞争信道,pure ack 在交换节点与 data 竞争 buffer 和带宽。无论哪一种问题,都因摩尔定律落后于带宽发展而日趋严重。

在端侧,pure ack 的每次处理需要一次 cpu 中断,而定期轮询将损害 delivery rate 计算并降低灵敏度;在 wifi,每个反向 pure ack 都要和正向 data 竞争时隙,以 2:1 为例将侵占系统 1/3 的带宽资源;在交换节点,大量资源用于管理大量 pure ack,对 data 照顾不周将加剧拥塞,特别在丢包和恢复阶段,tcp 的 data/ack 将达到 1:1,对交换机资源占用更高,越丢包越容易更丢包。

固定资源的系统,tcp 最终吞吐将被自身 ack 限制在固定比例,ack 损耗随处理器和带宽的不对称发展趋向增加。
lro,wifi frame-aggregation 等治标不治本的技术来掩盖问题也不知是福是祸,很少有人能认识上述三个场景的问题,甚至很少有人意识到它们存在。

tcp 在 100Gbps+ 的理论吞吐有一半,另一半资源用来处理 pure ack 了,允许 tso/lro/ack-aggregation/big-tcp 再挤出些带宽,勉强到 70% 甚至 90%,但挤牙膏皮显然毫无意义,就看 1.6Tbps 网络中 tcp 如何应对。问题在 tcp self-clock 对 ack 太过依赖。

问题的意义在于新协议而不是如何改进 tcp。你会将 tcp 某特征抄进新协议吗?教科书里教的都是这特征解决了什么问题,而只字不提它是哪些问题的所在。因此我们看到一个又一个的 yet another tcp。

同样基于 tcp ack 太多的问题,果真百害无一利吗?

tcp ack 实在太多,但并非没用,正如 self-clock 顾名思义,流量由 ack 触发。在如 clos/spine-leaf 这种规整且局域对称的拓扑下,路径也对称,交换机可分析 ack 提前预期大流量,对反向的 ack 整形即可对未来流量整形,从而提前避免拥塞。这比等大流量真正到了再反压或者丢包要好太多。

对于 tcp 长连接,上述方法可以捕捉源自同一 receiver 但目标却是不同 sender 的大量 pure ack 从而预期一次潜在的 incast,对这些扇出的 pure ack 进行 pacing 整形,就可消除未来的扇入 incast,是不是很有趣。

这思路适用于一切规则拓扑下的传输协议用来消除 incast,规则拓扑下,交换机可分析途径的 request 而提前预知 response 流量特征,在获知将来潜在拥塞后,交换机可对这些 request 整形,间接控制 response 流量。

看起来像是在利用 pure ack,实际是在利用规则拓扑,规则拓扑中,交换机比端对流量具有更全局且精确的预期,得益于交换机知道流量源自哪里去往哪里。在同一尺度的网络中,规则相通,问题也相通。在广域网中,分布式特征更倾向于端到端控制,因为传播时延太大,拓扑不对称,交换机它算不准。

周末的文章 incast,拥塞控制,内存墙的秘密 我的一个回复 “数据中心服务器扇出每个 request 都携带唯一的 expired id,这个id 在请求端生成,每个 id 均唯一,该 id 表示一个时间戳,指示在发送 response 前等待多久…”,expired id 只为放大波动,每台服务器都受负载随机波动而波动,将这个波动放大到交换机带宽的粒度,incast 随之消失。这事实在广域网能得到印证,广域网没有 incast,原因就是多级链路,长距离放大了波动,从而消除了全局同步。随机修剪光纤长度就是想在数据中心人为放大随机波动。

回到 pure ack 过多问题,如果数据中心可利用 pure ack 度量或预测潜在流量特征是因为网络足够规则,那么在广域网,1:2 的 data/ack 比例则没必要,广域网波动性被放大而损害的预测精度损失不会随样本增加而缓解,按照大数定律,样本增加只能更精确测量波动本身,而波动是滞后的,拥塞控制要做的是在更粗粒度感知波动而不是精确测量波动。

以我的从业经验,细粒度度量和粗粒度度量相比,对于预测未来链路画像,并不能更精确。用历史预测未来更多的是经验走势,而它本就是粗粒度的。

足球场的面积,腿脚的灵活性决定了球门的大小,同时也约束了上场人数,因为人数不能改变每一个次射门的进球概率,人数过少或过多都将降低观赏性。这是尺度决定的,相反,将桌球打进直径 10cm 的洞却是每一个桌球玩家的基本要求。

tcp 说旧不旧,quic 几乎就是 yet another tcp,但 tcp 确实很旧,当我们要优化 tcp 或迭代一个新协议时,不能被表面现象牵着鼻子走,一定要回到 1970 年代彼时彼刻的现实,你会发现 tcp 几乎一切的设计都出自四个字,简单能用。所以也就没有那么多为什么和好不好了。tcp 后来的问题并不影响它的可用性,可如今人们几乎把高性能 tcp 玩成了烟花特效,但当人们真去设计一个试图取代 tcp 的新协议时,却把那些导致低性能的特性也一并抄了去,结果新协议也只是可用,并不简单,在它针对的范围外也不高效。

浙江温州皮鞋湿,下雨进水不会胖。文章来源地址https://www.toymoban.com/news/detail-754668.html

到了这里,关于说说过量 tcp pure ack 的利弊的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 《TCP/IP网络编程》阅读笔记--基于UDP的服务器端/客户端

    目录 1--TCP和UDP的主要区别 2--基于 UDP 的数据 I/O 函数 3--基于 UDP 的回声服务器端/客户端 4--UDP客户端Socket的地址分配 5--UDP存在数据边界 6--UDP已连接与未连接的设置 ① TCP 提供的是可靠数据传输服务,而 UDP 提供的是不可靠数据传输服务; ② UDP 在结构上比 TCP 更简洁,其不会

    2024年02月09日
    浏览(61)
  • Linux网络编程之TCP/IP实现高并发网络服务器设计指南

    目录 引言: 多进程服务器 例程分享: 多线程服务器  例程分享: I/O多路复用服务器 select 例程分享: poll 例程分享: epoll 例程分享: 总结建议         随着互联网的迅猛发展,服务器面临着越来越多的并发请求。如何设计一个能够高效处理大量并发请求的服务器成为

    2024年02月20日
    浏览(54)
  • 《TCP/IP网络编程》阅读笔记--基于Windows实现Hello Word服务器端和客户端

    目录 1--Hello Word服务器端 2--客户端 3--编译运行 3-1--编译服务器端 3-2--编译客户端 3-3--运行 运行结果:

    2024年02月10日
    浏览(66)
  • 判断服务器IP否被墙 是否被TCP阻断

    现在国内很多购买国外主机服务器的,但往往很多主机商的机子用的人多了,国内使用者用这些服务器做啥的都有,正儿八经的做外贸其实没多大事情,但往往有些人就是不遵守法律法规,长此以往用的人多了,这些国外的主机商提供的服务器ip就会遭到国内的封杀。 今天教

    2024年02月12日
    浏览(59)
  • 更安全的ftp服务器Pure-FTP搭建(4)

    实验简介 实验所属系列:Linux服务器搭建 实验对象: 本科/专科信息安全专业 相关课程及专业:计算机基础,计算机网络 实验时数(学分):2学时 实验类别:实践类 预备知识 本实验要求实验者具备如下的相关知识 也许您对FTP不陌生,但是您是否了解FTP到底是个什么玩意?

    2024年02月16日
    浏览(42)
  • 【TCP/IP】多进程服务器的实现(进阶) - 多进程服务器模型及代码实现

             经过前面的铺垫,我们已经具备实现并发服务器的基础了,接下来让我们尝试将之前的单任务回声服务器改装成多任务并发模式吧!         在编写代码前,先让我们大致将多任务(回声)服务器的模型抽象一下,如下图所示:         当客户端请求服务(

    2024年02月08日
    浏览(150)
  • TCP/IP客户端和服务器端建立通信过程

    使用Qt提供的类进行基于 TCP 的套接字通信需要用到两个类: QTcpServer 类用于监听客户端连接以及和客户端建立连接,在使用之前先介绍一下这个类提供的一些常用API函数: 构造函数 给监听的套接字设置监听 listen() 函数 在代码中 通过启动监听按钮 设置监听 参数: address :

    2024年02月07日
    浏览(65)
  • Linux高性能服务器编程 学习笔记 第一章 TCP/IP协议族

    现在Internet使用的主流协议族是TCP/IP协议族,它是一个分层、多协议的通信体系。 TCP/IP协议族包含众多协议,我们只详细讨论IP协议和TCP协议,因为它们对编写网络应用程序有最直接的影响。如果想系统学习网络协议,RFC(Request For Comments,评论请求)是首选资料。 TCP/IP协议

    2024年02月09日
    浏览(65)
  • 【TCP/IP】利用I/O复用技术实现并发服务器 - select函数

    目录 I/O复用技术 select函数 设置文件描述符 指定监视范围 设置超时 I/O复用服务器端的实现        由服务器创建多个进程来实现并发的做法有时会带来一些问题,比如:内存上的开销、CPU的大量占用等,这些因素会消耗掉服务器端有限的计算资源、进而影响程序之间的执

    2024年02月08日
    浏览(51)
  • Linux高性能服务器编程|阅读笔记:第1章 - TCP/IP协议族

    Hello! 非常感谢您阅读海轰的文章,倘若文中有错误的地方,欢迎您指出~   ଘ(੭ˊᵕˋ)੭ 昵称:海轰 标签:程序猿|C++选手|学生 简介:因C语言结识编程,随后转入计算机专业,获得过国家奖学金,有幸在竞赛中拿过一些国奖、省奖…已保研 学习经验:扎实基础 + 多做

    2024年02月01日
    浏览(58)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包