TCP协议保证可靠性的几种方式

前言

TCP、UDP是传输层两种常用的协议，实际学习使用下来，感觉TCP使用较多。所以此文深入学习一下TCP协议相关机制。学习过程主体参考此文。记录主要是便于自己复习。

TCP、UDP协议对比

图源、文源

确保可靠性的方法

1、序列号和确认应答信号

每一个数据包都附带有一个序列号，序列号递增。
通过这个序列号解决了 确认应答ACK处理、重发控制、重复控制。

2、超时重发控制

此段参考此文

相关概念：

RTT（Round Trip Time）：往返时延，也就是数据包从发出去到收到对应 ACK 的时间。RTT 是针对连接的，每一个连接都有各自独立的 RTT。

RTO（Retransmission Time Out）：重传超时，也就是前面说的超时时间。

具体重传实际计算是根据RTT、RTO、SRTT等进行计算的，具体过程是数学公式。。

基于计时器的重传：

每个数据包都有相应的计时器，一旦超过 RTO 而没有收到 ACK，就重发该数据包。没收到 ACK 的数据包都会存在重传缓冲区里，等到 ACK 后，就从缓冲区里删除。

在重传的同时，TCP不仅会重传对应数据段，还会降低当前的数据发送速率，因为TCP 会认为当前网络发生了拥塞。

超时重传的缺陷：丢包的地方，及其之后的都需要重发，造成浪费。

假设数据包5丢失，数据包 6,7,8,9 都已经到达接收方，这个时候客户端就只能等服务器发送 ACK，注意对于包 6,7,8,9，服务器都不能发送 ACK，这是滑动窗口机制决定的，因此对于客户端来说，他完全不知道丢了几个包，可能就悲观的认为，5 后面的数据包也都丢了，就重传这 5 个数据包，这就比较浪费了。

快速重传

服务器如果收到乱序的包，也给客户端回复 ACK，只不过是重复的 ACK。如果客户端连续三次收到重复的 ACK，就会重传对应包，而不需要等到计时器超时。

但仍然存在问题：到底该重传多少个包？

带选择确认的重传

在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了。

SACK：接收方返回最近收到的包文序号，帮助发送方找到需要重传哪些。
图源

DACK：找到哪些重传的重复了。

SACK、DACK参考自此

3、连接管理

三握手 四挥手

交换MSS（最大消息长度）

MSS 在三次握手的时候，在两端主机之间被计算得出。两端的主机在发出建立连接的请求时，会在 TCP 首部中写入 MSS 选项，告诉对方自己的接口能够适应的 MSS 的大小。然后会在两者之间选择一个较小的值投入使用。

4、滑动窗口控制

此段参考此文

SND.WND：发送窗口
三个指针：
SND.UNA：发送窗口的第一个字节
SND.NXT：可用窗口的第一个字节
RCV.NXT：接收窗口的第一个字节

流程：

由接收方通告窗口的大小，这个窗口称为提出窗口，也就是接收方窗口。接收方提出的窗口则是被接收缓冲区所影响的，如果数据没有被用户进程使用那么接收方通告的窗口就会相应得到减小，发送窗口取决于接收方窗口的大小。可用窗口的大小等于接收方窗口减去发送但是没有被确认的数据包大小。

5、流量控制

原因：

当接收方的缓存区满了后，如果还疯狂发送，就会丢掉数据。这样会引起重发，造成资源浪费，拥堵。

描述：

在发送确认报文时，附带上多少缓存区是空闲的。当空闲为0时，发送区即停止发送。
发送区停止发送后，通过定时器，每一段时间检测询问一下接收区剩余空间，若有则继续发送。（为了避免“发一点点就满，又发一点点”，采用1、让接收方不通告小窗口给发送方 2、让发送方避免发送小数据的方法。具体见此

其他：

1、一般情况，发送窗口>=接收窗口。
2、接收窗口大小不固定，动态调整的是。
3、全双工，所有通信双方 各有俩窗口。
4、窗口适当大小，过小会增加丢包率，过大不会减少丢包率 反而浪费内存。

6、拥塞控制

见此文