Linux--TCP协议的传输控制机制--0314

Gosolo！

已于 2023-03-20 19:49:59 修改

阅读量351

点赞数

分类专栏： Linux 文章标签： linux tcp/ip 网络

于 2023-03-20 00:05:02 首次发布

本文链接：https://blog.csdn.net/qq_68741368/article/details/129650912

版权

Linux 专栏收录该内容

36 篇文章 1 订阅

订阅专栏

1.确认应答（ACK）机制

TCP将每个字节的数据都进行了编号，即为序列号。

首先需要重新认识一下TCP的发送缓冲区，可以将tcp的发送缓冲区看做一个char sendbuffer[NUM]的数组。这样就完成了TCP协议对于数据的编号处理。

发送数据的时候，最后一个字节的数组下标成为报文的序号。

确认序号的意思也就是，确认序号之前的数据我已经拿到了，该从确认序号所在的字节开始向我发送数据。

2. 超时重传机制

主机A给主机B发消息，如果发送的报文数据丢失了。

站在B的角度，他无从知道主机A是否给自己发过消息，也就对数据丢包不会有任何反应。站在A的角度，他一直在等B主机的应答报文，可是总不能一直等下去吧？所以当A的一条报文发出去之后，如果迟迟没有应答，就会在一个特定的时间间隔后，重新发送这条报文。

那如果是应答的报文丢失了呢？

站在A的角度，他无法确认是自己发送的报文数据丢失了，还是应答报文数据丢失了。他都会进行超时重传。可在B的角度上，他就会一直接收到重复的报文数据！

但是就算B收到了重复的报文，可以通过序号进行去重，一定程度上也是提高了可靠性。

超时时间如何设定呢？

如果超时时间设的太长, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包;
Linux中，超时以500ms为单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍。

如果重发一次之后, 仍然得不到应答, 等待 2*500ms 后再进行重传.
如果仍然得不到应答, 等待 4*500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接。

3. 流量控制机制

接收端处理数据的速度有限.，如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制。

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端。
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后, 就会减慢自己的发送速度。
如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据。

不发送数据就是真的不进行询问了吗？

对于客户端而言，虽然不会发数据，但会不断向服务端发送窗口探测(询问服务端是否有空间接受数据)，服务端的ACK应答报文会携带窗口大小给用户端。

对于服务端而言，如果数据进行了向上交付，有了空余空间，也会向客户端发送窗口更新通知。告诉客户端可以发送消息了。

在进行流量控制的时候，第一次通信时我们如何得知对方的接受能力？

其实在三次握手的时候，由于还没有建立连接，是不能携带有效载荷的。但是由于进行客户端和服务端之间互相发送报文，是可以传入窗口大小的。

4.滑动窗口

如果主机A和主机B的消息是一条一条发送的。即A向B发送第一条消息后，等到B的应答报文后才继续发送第二条数据，会导致性能较低。那么如果我们可以一次性发送多条数据，就可以大大提高性能（将多个端的等待时间重叠在一起）。

4.1 滑动窗口在哪里呢？

在发送缓冲区。滑动窗口可以将发送缓冲区分为三个部分。一、已发送数据并且已经收到应答。二、滑动窗口内的数据（可以直接发送并且暂时不需要应答）。三、尚未发送的数据。

4.2 滑动窗口的本质

发送方可以一次性向对方推送数据的上限。（滑动窗口的上限，理应与对方的接受能力挂钩）。滑动窗口的左右区间即是下标，

下标的更新

win_start=收到应答报文中的确认序号。

win_end=win_start+收到应答报文中的窗口大小。

滑动窗口的一定往右移动吗？

不一定。当数据并没有被向上传达时，滑动窗口其实是在减少的。

滑动窗口可以为0吗？

可以的。一直没有数据向上传达，滑动窗口可能为0。

4.3 滑动窗口可能出现的丢包情况

情况一：数据包已经抵达，但是ACK丢了。

无所谓。只要数据发送到了主机B，B端就会更新确认序号。如果是前面发送的ACK丢失，主机A可以根据主机B后续的应答中获得确认序号。收到确认序号为6001的报文，就说明前面的数据都送到了。如果是后续的丢了，无非也就是再发送一边重复的数据，有历史送达的报文数据帮以去重。

情况二：数据包就直接丢失了

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK。当连续三次收到了同样一个“1001”这样的应答，就会将对应的数据1001-2000重新发送。如果接收端收到了1001，再次返回的应答中的确认序号就成为了7001.

这种由于连续收到同一个确认序号，而使发送发重新发送该序号数据的机制，称为“高速重发控制”，也称快重传。

快重传和超时重传不是对立的，而是协作的。

5.拥塞窗口

如果在刚开始阶段就发送大量的数据, 可能引发问题.因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 才导致发送的报文大量丢失。在不清楚当前网络状态下, 贸然发送大量的数据，会导致服务端更快的崩溃。

拥塞窗口：单台主机一次向网络中发送大量数据时，可能会引发网络拥塞的上限值。

当发送开始的时候，或者遇到网络拥塞的情况时，定义拥塞窗口大小为1。每次收到一个ACK应答，拥塞窗口大小*2，每次发送数据包时，将拥塞窗口和接受端的滑动窗口做对比，取较小值作为实际发送的窗口。

然而指数级的增长，一定是没有必要的，发送到一定次数后，如果没有出现网络拥塞，就会完全取决于对方的接受能力。一开始使用指数级的增长，只是为了让通信快速回复到没有网络拥塞的正常水平。

所以还需要引入一个叫做慢启动的阈值。当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式进行增长。

当TCP开始启动的时候，慢启动的阈值等于窗口最大值。

每次当超时重发时，慢启动阈值会变为原来的一半，同时拥塞窗口置回1.

6. 延迟应答

因为对方的接收缓冲区存在滑动窗口。就有可能允许发送方一次推送更多的数据，这样单次的IO操作可以提升效率。也就是说接收方的应答中如果可以给发送方同步一个更大的接收能力，就有可能可以提高效率。

那如何同步更大的接收能力？

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口大小可能比较小。但如果我们等一等，如果这段时间中接收方进行了向上递交数据，就会导致窗口大小变大，从而可能提高效率！

窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

那么所有的包都可以延迟应答吗？

数量限制: 每隔N个包就应答一次。
时间限制: 超过最大延迟时间就应答一次。

7.捎带应答

将确认应答和发送的数据这两条报文二合一。

8.面向字节流

创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区。调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去。
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 是全双工。

由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;完全取决于应用层想怎么对数据进行处理。