【Linux】TCP机制

确认号 = 对端发送的TCP报文段中的起始序号（seq）+ 该报文段中承载的TCP数据载荷的字节长度，然后填在自已TCP报头的ack_seq中，返回给他，告诉他ack_seq之前的所有数据我都收到了。对端收到了，就知道下次从哪里开始发了，自已发多少个字节。在主机A的视角，它每次发送的序号是有间隔的0,1000,2000....

🐼超时重传机制

先提出一个问题，如何看待丢包问题：

之前说:我发出的报文，对方有没有收到，我知道吗？如果得到应答，我就100%确定对方收到了~

这就是确认应答机制，可是：

如果我发的报文，丢失了，我知道吗？不知道！！为什么？因为有两种情况，一种是我发的报文，对方已经收到了，只不过应答丢了，导致我不知道~另一种是我发的这个报文丢失了~

不过结果都一样，就是我作为发送方，我没有收到应答，我也不知道对方到底有没有收到我的应答~如图:

那么丢包了，如何解决？约定出来的！正是因为我不确定对方有没有收到，所以被约定出来就是丢包了！约定这个报文被当做丢包来看！约定的规则是什么？超时重传机制！

超时重传：如果一个特定时间，时间内返回应答，那么就是确认应答，如果超出这个时间，我们统一判定为超时（不叫判定丢包），然后重发！总之，就是我收不到应答，我继续给你发

几个细节:

✅细节1：可是为什么叫超时重传？不叫丢包重传呢？因为丢包我判断不了！那就判断为超时吧~

✅细节2：如果报文没丢，是应答丢了呢？这样重传不就会导致接收端的重复吗？不用担心，如果接收端收到重复报文，自已会将报文丢弃！通过序号来去重

✅细节3: 超时时间，这个时间设置为多长？因为超时时间一定会随着网络波动，超时时长来影响的，网络的通畅程度是浮动的，超时时间太长，发送效率低，太短，频频触发超时重传机制。

TCP 为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间

🐼连接管理机制

我们已经知道，TCP通信之前，要握手协商，进行三次握手。并且我们已经大致了解了TCP三次握手时如何握手的，下面我们基于三次握手的代码行为和建立时的状态行为再来聊聊，我们先仅仅看握手部分，如图:

有几个细节:

✅细节一：一旦客户端发出了最后一个ACK的时候，自已的状态就已经变成了ESTABLEED。

✅细节二:为什么有两条连接？因为我是在一个机器上测试的，正常只会有我访问服务器的第一条连接。

✅细节三:这些大写的字母是什么？因为我们说过，TCP连接有很多行为，比如断开，连接，重连...所以就要描述起来，而这些大写的字母不就是一个个宏，就是一个数字，写在报头中，表示连接的行为。

🐼TCP三次握手，为什么是三次啊？

我们一直说，TCP三次握手，三次握手，可是为什么是三次啊？少一次可以吗？多一次可以吗？答案是不可以！

举个例子:在现实生活中男女朋友结婚，要满足什么条件？1.双方的愿意--征得双方的同意2.双方父母要愿意---征得双方父母的同意，三次握手也如次~

三次握手为什么是三次，原因有两点:

1.验证全双工

首先client发送一个SYN给server,能验证client有发的能力吗？不能，因为还没有收到server的应答，一旦收到server的应答ACK，client就知道，自已100%有发的能力！

而server一旦收到client的请求SYN，就知道自已有收的能力！

而client一旦收到server的ACK就知道，自已有收的能力。

当server一旦收到client的ACK就知道，自已有发的能力！如图:

所以，客户端到服务端，服务端到客户端，都具备收发消息的能力！也就验证了全双工，证明了网络是可靠的(不就验证了外界因素嘛,征得外界同意~)

2.建立双方要通信的共识，双方都知道，我要和对方通信了！无法抵赖~

如图 :

所以，三次握手为什么是三次？其实本质是四次，因为有了捎带应答，变成了三次。就是以最少的次数来建立共识！验证全双工！

🐼重谈TCP四次挥手

首先TCP为什么是四次挥手啊？理由和三次握手一样，要建立双方分手的共识！

🗾理解CLOSE_WAIT状态

我们先来看一下四次挥手的示意图:

提出一个问题：**四次挥手可以像三次握手一样，有捎带应答吗？**也就是server捎带应答ACK+FIN直接发给client?答案是一般不可以，也强烈不推荐！

为什么呢？因为发送一个FIN，就表明关闭了一条通道！

这意味着什么？client如果关闭了自已的fd，就表明client不会再向server写，不会再发数据了！(client由rw->r)，只关闭了一个通道！可是server还要不要给client发数据呢？不确定！server->client这条连接并没有关闭，server还可以发送数据给client,client还能读。只有当server也关闭了自已的fd,此时才关闭了server->client的这条通道。

举个例子:当client发送一个request时，就可以关闭自已的写端，不再读了。

可是server可能还有很多response发给client,暂时不关闭自已的fd，所以就处于CLOSE_WAIT状态。如图:

那么client是如何做到关闭了写，但还能读的呢？有一个系统调用shutdown。

总结:

一旦发起方提出断开连接，关闭自已的fd,发送FIN给接受方，如果接收方没有关闭自已的fd,那么此时就会处于CLOSE_WAIT状态！ 比如clientquit，故意让server不关闭自已的fd

CLOSE_WAIT带来的价值？server端如果忘记关闭自已的fd，就会导致client断开连接后，server连接处在CLOSE_WAIT状态。如果有成千上百的client访问，然后断开连接，那么就有很多条连接处于CLOSE_WAIT状态。此时系统卡顿！如果我们看到有大量的连接处于CLOSE_WAIT,可能就是server忘关fd了，文件描述符泄露了！

🗾理解 TIME_WAIT 状态

TCP规定:主动关闭连接的一方,四次挥手已经完成，自已不能立即退出，而是要等待一段时间，要处于 TIME_ WAIT 状态,等待两个MSL(maximum segment lifetime)的时间后才能回到 CLOSED 状态

为什么？

1.举个例子:client给server发送的报文，因为在网络中可能在某个路由器中积压着，导致client断开连接然后下次重连还是使用原来的端口来访问同一个服务端，导致陈旧报文的"迟来",这就造成了对新报文的干扰

所以，要处于TIME_WAIT理由有两点:

1.防止陈旧报文对新连接产生干扰，让其在网络中消散

2.没有消息就是好消息，尽量保证四次挥手的正确结束。(保证最后一个报文可靠到达(假设最后一个 ACK 丢失, 那么服务器会再重发一个 FIN. 这时虽然客户端的进程不在了, 但是 TCP 连接还在, 仍然可以重发 LAST_ACK);,不过如果client收不到重发，那么就是好消息~)

有几个细节:

✅细节一：什么是MSL？就是报文的最大生存时间。每个内核的值可能不一样

✅细节二：在TIME_WAIT状态时，连接断开了吗？没有！意味着端口号被占用。这就要求必须更换端口号。

假设服务端现在挂掉了，也就是主动断开连接的一方。可是，服务端，敢不敢轻易更换自已的端口号？不敢！但是自已处于TIME_WAIT状态，难道要等2*MSL时间？NO，服务端即便处于TIME_WAIT状态，也必须立即重启！！！

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).这个时候如果由**服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量 TIME_WAIT 连接，**如何做？

使用 setsockopt()设置 socket 描述符的选项 SO_REUSEADDR 为 1, 表示允许创建端口号相同但 IP 地址不同的多个 socket 描述符

cpp 复制代码

int opt = 1;
// 地址复用---sockaddr重复使用
setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt, sizeof(opt));

🐼流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应

因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过 ACK 端通知发送端 ;窗口大小字段越大, 说明网络的吞吐量越高
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端

发送端接受到这个窗口之后, 就会减慢自己的发送速度

如果接收端缓冲区满了, 就会将窗口置为 0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端，如图:

有两个细节:

✅细节一：第一次的时候，主机A，如何得知主机B的窗口大小的呢？通信之前，双方要经过三次握手的，前两次握手，一定不携带任何数据，因为没有建立连接共识，但是，他们是交换过报头的。所以，在通信前，双方就已经交换了对方的窗口大小！

✅细节二：16 位数字最大表示 65535, 那么 TCP 窗口最大就是 65535 字节么?

实际上, TCP 首部 40 字节选项中还包含了一个窗口扩大因子 M, 实际窗口大小是窗口字段的值左移 M 位

🐼滑动窗口

滑动窗口在哪里？是什么？滑动窗口在发送方的发送缓冲区内！属于发送缓冲区的一部分，可以暂时不用确认应答，可以直接发送的区域。发送方的发送缓冲区，我们把发送缓冲区想象为一个线性的一维数组~如何理解呢？既然是一个一维数组，并且我们属于这个一维数组的一部分，我们如何表达呢？我们可以用两个指针来表示这个窗口大小，一个是start,一个是end而end-start的大小就是滑动窗口的大小，如图：

而start就是确认序号，end = start + win；

滑动窗口的大小把发送缓冲区分成了三个部分：

直接发，暂时不要应答的数据

1.已经发送的数据(已经收到确认应答的)，那么这部分数据就可以被新数据覆盖了

2.待发送的数据，和空的数据

知道了什么是滑动窗口，下面我们再来从发送方式来理解一下，以下我们都是站在发送者的角度

在之前，我们发送报文都是说的是串行的，对每一个发送的数据段, 都要给一个 ACK 确认应答. 收到 ACK 后再发送下一个数据段. 这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.

既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).

这也就解决了我们上一节的问题，就是你凭什么可以这么发送？？？为什么没有收到接收端的应答你就可以直接发送？？？这是滑动窗口的机制所带来的好处！

滑动窗口大小：无需等待确认应答而可以继续发送数据的最大值 (这里无需等待仅仅是暂时不要，后面还是需要的)如何来理解？就是靠确认号！ 确认号表示seq前的所有数据我已经全部收到了，假设发出了4个报文，每个报文携带1000字节，序号从1开始，当滑动窗口的4个报文发送出去时，无需等待，直接发就好了，而收到的报文前三个都丢了，但是收到了最后一个报文的确认号为4000，那么发送方就可以100%确定，这4个报文，接收方都收到了，于是滑动窗口向后移动到4000，继续发送！！
所以根据确认号，确认号的意义就可以减少重发报文，让发送方获取到更多的信息！知道自已发送的报文有多少个被发送方确认了，从哪里没有确认！即使收到了不完整的报文，但是竟然带着丢包的哪些报文的信息！这就是确认号！

可是我发送方怎么知道给你发送多少字节呢？我能一直发吗？别忘了，有一个win字段，它就能决定发送报文的数据!

这里我们先暂时抛出一个结论：滑动窗口的大小，是由接收方的能力来决定的，也就是对方应答的ACK的win字段，这是个暂时观点！后面会纠正

说几个细节：

✅细节一：滑动窗口只能从左到右吗？是的，因为数据在右边!

✅细节二：滑动窗口的大小会变化吗？什么时候变大？变小？不变？

我们说了，滑动窗口的大小是根据对方的接收能力来决定的，这就意味着，当接收方发送的应答报文告诉我们WIN增大了，而我们此时还没有发数据，意味着我们可以发送的数据可以更多了，此时滑动窗口大小就增大了。同理，如果我们发数据，对方没有取数据，那么窗口大小变小！所以滑动窗口的大小是根据对方的接收能力来动态调整决定的

滑动窗口大小是否可以为0？当然可以，当对端win = 0时！

这也就意味着，如果对端窗口越大, 那么我们就可以发送更多的数据，则网络的吞吐率就越高了！

🗾丢包了怎么办？

那么如果出现了丢包, 如何进行重传? 这里分两种情况讨论
情况一: 数据包已经抵达, ACK 被丢了

这种情况下, 部分 ACK 丢了并不要紧, 因为可以通过后续的 ACK 进行确认;确认应答机制！

情况二: 数据包真就直接丢了

如图所示：当某一段报文段丢失之后, 发送端会一直收到 1001 这样的 ACK, 就像是在提醒发送端 "我想要的是 1001" 一样;

所以当发送方收到了三个连续的确认应答报文，发送发不能确定2001之后有没有丢包，发送方可以肯定确定，1001-2001真的丢包了，于是就重传了1001-2001给发送方！这个时候接收端收到了 1001 之后, 再次返回的 ACK 就是 7001 了(因为 2001 -7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;这种机制被称为 "高速重发控制"(也叫 "快重传").

补充几个个细节：

✅超时重传和快重传相互冲突吗？不冲突！而且是相互补充的！原因是当发送方在超时时间内收不到发送方的3个重复确认报文，那么此时发送方就触发了超时重传机制！所以，超时重传机制用来兜底！快重传用来提高效率上限！

我们从滑动窗口的角度再来理解真丢包这种情况，看看滑动窗口的行为：

无非就三种情况：1.滑动窗口的最左侧丢包了 2.中间报文丢失 3.最右侧报文丢失了

假设最左侧丢包了，那么滑动窗口不会移动，只有根据快重传，会重发包，当收到应答报文，滑动窗口向右移动！

假设最中间丢包了，那么滑动窗口首先会向右移动，因为中间的报文之前的没有丢包，滑动窗口会移动到丢包的地方，那么不就又变成最左侧丢包了吗？？？

**所以，从滑动窗口视角，我们都可以看成一种丢包，最左侧丢包！谁支持的？这就是确认应答机制支持的！！滑动窗口，不准跳过没有确认的报文！✅**why？

因为，没有收到的确认的报文，可能丢包了，我是不是还得重发？为了支持重传，发出的数据，不能立即删除，而是被暂时保存起来，以方便后续确认或者重传！保存在哪里？滑动窗口内！所以，已经跳过的的数据，一定是被确认的数据，重传机制，也和滑动窗口有关！

**✅**当滑动窗口还出去了怎么办？

我们把滑动窗口看成一个环形的数组即可

✅还有一个问题，为什么我们不把数据打成一个包发送，而是要一个个发送?链路层再分享！

所以滑动窗口是流量控制和重传机制的底层实现

🐼拥塞控制

✅为什么要有拥塞控制？

你不是有滑动窗口可以控制数据发送吗？为啥还要整个拥塞控制？虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题，因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据, 是很有可能引起雪上加霜的.把网络搞瘫痪了，os异常，此时可不就是你TCP说了算的！

**✅什么是拥塞控制，拥塞控制和重传有啥区别？**拥塞控制就是根据特定算法，让网络不那么拥堵！即使动态调整！

如果是少量丢包，那可能是你自已的问题，不是网络的问题，那么就需要重传

但是如果大家都丢包，丢了很多包，那么就是网络的问题了，此时网络很拥堵，那么就要减少数据包的发送！

可是有人说了，如果我自已少量丢包了，我重传行吗？我一个人重传不会影响吧？No，如果你重传我重传，那么网络拥堵就更严重了，因为大家都用的同一个TCP，都有超市重传机制。那可不行！于是就构建了拥塞控制，让全网内的TCP的所有主机，达成一个共识：面对拥塞问题的共识！

此处引入一个概念称为拥塞窗口，就是一个int，来反应拥塞程度的！

既然有了网络拥塞，所以发送数据需要考虑什么？网络！接收方！
这里纠正上面的概念，滑动窗口= min(拥塞窗口，对端的接收窗口）

✅拥塞控制如何做？

发送开始的时候, 定义拥塞窗口大小为 1，
每次收到一个 ACK 应答, 拥塞窗口加 1，这样滑动窗口的大小就成指数增长了！

为什么要设计成指数增长？因为有前期慢，增长快的特点！一旦拥堵，通过探测，发现并不怎么拥堵，那么现在的矛盾就是，尽快恢复正常通信

每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口;像上面这样的拥塞窗口增长速度, 是指数级别的. "慢启动" 只是指初使时慢, 但是增长速度非常快。

但是这样增长，不能一直增长吧？？？为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍

此处引入一个叫做慢启动的阈值ssthresh !

当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长,但是也要有增长上限啊，甭管你是指数还是线性，网络带宽有限！当增长到网络拥塞时，那么就有一个一个值，这个值就变成了网络拥塞临界值，这个值不就可以作为我们后面参考网络拥塞的指标了吗！

接着，又开始启动慢开始，当 TCP 开始启动的时候, 慢启动阈值等于窗口最大值;
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回 1;

如图：

因此，少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞;

当 TCP 通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降;拥塞控制, 归根结底是 TCP 协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。

TCP 拥塞控制这样的过程, 就好像热恋的感觉，像是谈恋爱...

🐼延迟应答

如果接收数据的主机立刻返回 ACK 应答, 这时候返回的窗口可能比较小.因为上层还没有及时取走数据。但是如果能够等一等，是不是有概率可以让上层把数据取走，这意味着什么？意味着我们接收方，可以更新一个更大的接受窗口给对方，对方知道了，一次性就可以发更多的数据，这是不是意味着网络吞吐率就高了~所以通过延迟应答，在一定概率内就能更新就出一个较大的窗口，窗口范围大了，效率就高了！

🐼捎带应答

捎带应答我们之前已经说过了，比如TCP的三次握手，其中服务器给客户端的应答，既有确认号也有SYN。这里还需要注意一下细节就是，三次握手的前两次可以携带数据吗，捎带数据？？不可以！因为连接还没有建立，不过最后一次，也就是客户端向服务器的最后一次握手的ACK，就可以携带数据了 。为什么？因为默认只要客户端发出ACK，客户端就算建立好连接了。我们可以把捎带应答就理解做顺风车~

🐼面向字节流

✅ 我们说TCP是面向字节流的。为什么？还记得我们自定义协议时，使用while循环一直读吗？为什么要一直读？为什么又要+=？因为**我们不确定对方是否发来了一个完整的报文，对方也不知道自已发来了一个完整的报文，它之负责把数据用TCP报头打包，然后发给我们，而我们怎么就能确定他发过来的数据，100%里面有一个完整的数据报呢？NO，也不知道。因为TCP通通不需要考虑，它不关心数据报具体是什么，只是负责发数据！这是我们应用层需要做的！是不是我们应用层得定协议，告诉他我以哪个边界作为分割线，将报文分开？？**我们是不是还做了unpack和pack，来解析报头，提取出来一个完整的报文，然后交付给上层，这是在干嘛？不就是在处理粘包问题吗？字节流，就是数据和数据粘在一起了，没有差别，我们需要主动分开！

**✅**UDP呢？UDP需要关心是否有一个完整报文吗？需要！所以，只要发给我们的报文一定是一个完整的报文，不会出现一个或者半个报文！

**✅所以现在能理解什么是文件流了吗？**文件流不也得解决粘包问题？所以也得想办法获取到一个个完整的数据包！有可能以"\r\n"作为数据包和数据包之间的边界？又或者是特殊字符？又或者是数字？谁也说不准，但敢肯定的是！你把数据写到了外设，最后从外设中取的这个过程中，一定要保证能取的出来！所以，也会有类似网络的"协议"!

**✅**正是因为缓冲区的存在，也正是因为TCP是面向字节流的，TCP 程序的读和写不需要一一匹配，举个例子：

写 100 个字节数据时, 可以调用一次 write 写 100 个字节, 也可以调用 100 次write, 每次写一个字节;读 100 个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100 个字节, 也可以一次 read 一个字节, 重复 100 次;现在能理解什么是面向字节流了吗？

🐼TCP 异常情况

来考虑三个特殊情况，也就是客户端程序退出了会不会成功4次挥手，服务器端知道吗？

**✅**当客户端进程终止: 进程终止会释放文件描述符, 仍然可以发送 FIN. 和正常关闭没有什么区别，会成功四次挥手，服务器端就可以关闭这个连接了

**✅**当客户端机器重启: 和进程终止的情况相同，也会重新4次挥手，服务器端就可以关闭这个连接了

✅ 当客户端机器重启机器掉电/网线断开: 服务器接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作, TCP 自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.

另外, 应用层的某些协议, 也有一些这样的检测机制. 例如 HTTP 长连接中, 也会定期检测对方的状态. 例如 QQ, 在 QQ 断线之后, 也会定期尝试重新连接。比如给每个客户端管理一个时间戳，如果过期了，服务器端就会主动断开连接。当然，这些事情都不规TCP来做，因为TCP怎么知道你要让这个客户端存活多久，一般都是由应用层自已来做的！

🐼TCP可靠性的保证

所以TCP为什么叫传输控制协议，人如其名！

根据连接管理机制，滑动窗口，超时重传，确认应答，三次握手四次挥手，流量控制，拥塞控制，序列号和确认号来保证可靠性！！！所以为什么TCP是可以保证报文不会丢失？跟这些机制，尤其是滑动窗口，确认号密切相关！

UDP：无连接，不可靠，全双工，面向数据报。

TCP：有连接，可靠，全双工，面向字节流

总之，对于网络的理解或者任何知识点的理解：不能只局限于抽象知识的表面，而是具体的示例来理解