一分钟理解TCP重传

为什么需要重传

任何信息在介质中传输可能丢失，这是由于传输介质的物理特性决定的，所以网络不可能被设计为“可靠的”（不是由于考虑“性能”原因而是压根做不到）。既然物理层无法提供可靠数据传输那么只能由协议提供可靠传输了，其中最有名的协议就是TCP了。

TCP是基于IP的网络协议，它提供可靠、有序的数据传输。在数据传输之前客户端和服务器端通过三次握手建立连接，建立连接的就是双方交换Seq（数据包序号）、MSS（每个TCP数据包大小） 、Win（滑动窗口，一次可以确认多少个TCP数据包），连接建立完成后每个TCP数据包都要被ACK（确认）。简单来说TCP通过确认/重传机制实现了“数据包可靠传输”。

重传原理

TCP数据包头部包含了两个字段——Seq表示数据包序号，ACK表示确认序号。下面演示了三次握手过程中Seq和ACK的变化过程。

客户端随机取一个值x作为Seq发送到服务器端；服务器端回复一个TCP数据包，头部包含Seq（随机值y），ACK=x+1。注意这里有一个常见的误区，ack确认的是当前数据包的“下一个”数据包，ack其实可以作为“期望得到的下一个seq”。客户端收到服务器端回复之后单独回复一个ack=y+1，就完成TCP的握手了。

后续数据包传递都会延续seq和ack的值，如果发送端某个数据包丢失了那么接收端不会发送ack（其实是duplicate ack），发送端在等待一段时间后发现没有ack，于是主动重发数据包。发送端的等待的时间叫RTO（Retransmission TimeOut）。

RTO的选择很重要，如果太大那么网络带宽利用率会特别低，发送端要过很久才知道要重传而此时要重传的数据是在太多严重浪费带宽资源。如果太小在高延时的网络高带宽（恩，你访问国外网站就属于这种网络）中也会浪费带宽资源。于是就有了Fast Retransmit机制，简单来说当发送端发现来自接收端的多个重复ACK（duplicate ack）的时候就不再等待RTO而是直接选择重发。

总结一下：经典TCP重发是发送端主动重发的，当数据包经历了一段时间后还没有被接收端确认此时发送端主动重发数据包。Fast Retransmit是由接收端主动要求重发的，当接收端收到了“不想要”的数据包时会重复ACK“上一个”数据包从而触发发送端的重发。这两种重发策略一般是同时使用，它们是互补的。

举个例子：发送端有D1(1-10)、D2(11-20)、D3(21-30)、D4(31-40)四个数据包要发送，每个数据包10bytes用括号内的数字表示。

• 乱序的情况：接收端收到D1，发送ack=11(D2的序号)。如果在发送过程中D4在D1之后达由于D4携带的seq=31所以接收端会丢弃这个数据包然后再次发送ack=11。此时发送端会收到两个ack（duplicate ack）如果开启了Fast Retransmit特性那么发送端立即从D2开始重新发送。
• 丢包的情况：接收端收到D1，发送ack=11（D2的序号)。如果在发送过程中D2丢失那么后续到达的包是D3，由于D3携带的seq=21所以接收端会丢弃这个数据包然后再次发送ack=11。此时发送端也会出现duplicate ack从而触发重传。

如果接收端的ACK数据包丢失了或者网络时延太高那么也会触发重传。因为发送端对每个数据包都设置了一个RTO，如果到时间没有收到ACK它会“主动”重发数据包。

Q&A

Q：多线程对一个Socket写入是否会触发TCP重发？程序上是否要考虑“乱序”？

A：首先要搞清楚一点，我们往Socket写入的数据是“应用层数据包”而不是TCP数据包。TCP/IP协议栈会把应用层数据包划分出多个TCP数据包发送出去，每次write都会生成N个连续的TCP数据包。所以即便我们多线程往Socket写入也不会出现TCP数据包的乱序（应用层数据包可能是乱序的）。

Q：重传和拥塞控制有什么关系？

A：TCP拥塞控制是指尽可能的利用带宽，它围绕4个核心概念展开：慢启动、拥塞避免和快速重传、快速恢复。其中快速重传、快速恢复属于TCP重传机制，慢启动是指对滑动窗口的控制，拥塞避免好重传机制有一定关系，如果存在大量重传那么网络上可能出现了拥塞（拥塞避免的关键是识别拥塞）。

Q：怎么看“替代TCP”的说法？

A：TCP最遭人诟病的就是它的重传机制不可控。如果网络延时比较高或者质量比较差有一定丢包（特别是移动网络），TCP的重传机制触发“不及时”这就导致应用体验很差。比如一个1000帧的视频丢了第100帧那么后续的900帧都要重传（即便已经收到了）。当然这只是一个例子，视频还是可以做一定“弥补”的），如果是手机游戏（比如王者荣耀、荒野行动）情况就没有这么乐观了。为了尽可能的让“重传”可控于是诞生了各种“替代TCP”的自制协议（大部分是基于UDP），比如Google的QUIC、kcp。我个人对这方面研究不多，总体而言它们牺牲了TCP的一些“通用特性”来换取一定的“灵活性”，所以并不是惊天地泣鬼神的“替代TCP”。

Q：怎么看TCP单边加速

A：TCP单边加速是指针对通讯的某一端做性能加速，市面上有很多这种产品。但是个人觉得这些都是骗人的，并没有一种算法适合所有网络情况。要根据不同的网络情况配置不同的拥塞控制算法。比如“国际链路”属于高延时高带宽，配置了Google的BBR算法“梯子”的速度至少能提高70-80%（你懂得）。

from:https://mp.weixin.qq.com/s?__biz=MzIxMjAzMDA1MQ==&mid=2648945945&idx=1&sn=f92e903929975e05978ba57be64ba2bc&chksm=8f5b5215b82cdb03c3f6f57ff63ee3f24bc1029dd147b7524d44baa36a10be65c24f6067adec#rd