TCP的不可靠传输

Posted 2022-05-16 dog250

一个常见的面试题：UDP如何实现可靠传输。

既然有TCP了，干嘛用UDP重新实现一遍，就算非要卷，能比QUIC更好吗？显然，这问题没意义。

还有另一个问题，TCP如何实现不可靠传输。

数据传输只有两个协议可选(这里不抬杠)，TCP或UDP，对于那些某些数据可以丢失某些却必须送达的传输业务而言，就要在UDP上重写一个协议，可理解为松散可靠传输。实现这种协议工作量不小，收益却不大。

so，人们往往选择复用TCP，当然也继承了TCP的缺陷，如队头拥塞，而这是大多数卡顿，传输低效的根源。换句话说，TCP根本就无法实现柔性降级有损传输。

人们有几百种激进重传方案来“优化”TCP，企图快速消除队头拥塞，却没人想到对丢包宽容，而将重传作为兜底的能力，仅对那些不允许丢弃的数据重传。

为什么不迭代TCP增加松散传输能力呢？

为TCP赋予一个新的能力，而不是重新实现一个新协议，这是我的想法。不要总拿TCP升级麻烦说事，相比重新实现部署新协议，升级协议更划算。

从端到端原则看分层模型，越上层离端越近，端到端原则倾向于写更多端代码，让业务逻辑发散，底层的传输能力应尽力收敛，避免冗余。

若重新实现松散可靠传输，其中可靠传输部分和TCP就是冗余的，冗余将带来维护成本。

要组合小功能，不要实现大逻辑。

这方面的一个反例是QUIC，QUIC重新实现了可靠传输，是典型推倒重来的案例。所有需要可靠传输的业务不得不在TCP和QUIC二选一，一旦选择一个，意味着将彻底放弃另一个的迭代收益。即便全部选择QUIC，TCP存量与QUIC加起来的维护成本依然不可小觑。

该说的都说了，大致意思和前面那篇一致，不要再加一个层了，而是迭代逻辑：
TCP与移动性

对于松散可靠传输，具体做法不难：

• 应用自己决定数据是否可丢弃。
• 将应用的决定落实到TCP头的flag。
• 新增option追踪可丢弃数据序列号和长度。
• 接收端根据flag决定是否对gap回复ACK。

下图展示的更具体些：

这个迭代并非仅实现松散可靠传输，还有新玩法，它将足够的传输策略的控制权交给了应用。

应用可自己做FEC，在丢包率高或延时敏感时尽可能将数据标记为可丢弃，TCP便可在弱网中尽力传输了。在丢包率低或延迟不敏感时，可加大重传力度而减少FEC。根据D2标志位依然可以像往常一样进行速率采样进行拥塞控制。

万事切换自如。

迭代TCP而不实现新协议还有个很重要原因，中间节点对TCP更友好。此类中间节点包括状态防火墙，NAT网关等中间节点实现复杂功能虽违背端到端原则，但现实中它们存在即合理，若大规模部署QUIC，是否升级中间设备就是必须考虑的事，迭代TCP只需在端到端修改协议实现，这件事本身反而揭露了端到端原则的本质。

昨晚跟同事聊关于面试题的选择，聊到了几个可玩性比较好的面试题，比如问socket调用3个参数的意义，比如select第一个参数最大值为什么是1024(先问是不是，再问为什么)，比如80行代码实现贪吃蛇，比如单链表逆转或者单词逆序，再比如如何UDP实现可靠传输，不过最后这个问题不好玩，好玩的是另一个，如何用TCP实现不可靠传输。居家办公，时间灵活，作文以记之。
浙江温州皮鞋湿，下雨进水不会胖。