本文主要是介绍说说过量 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 的新协议时，却把那些导致低性能的特性也一并抄了去，结果新协议也只是可用，并不简单，在它针对的范围外也不高效。
浙江温州皮鞋湿，下雨进水不会胖。
这篇关于说说过量 tcp pure ack 的利弊的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
