文章目录

TCP协议段格式
TCP交付过程
TCP解包过程
确认应答机制
- \[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kDvQFCTM-1689855767485)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719204622485.png)\]
32位序号/32位确认序号
TCP全双工
16位窗口大小-流量控制
6位标志位
如何理解连接
理解三次握手
理解四次挥手
理解TIME_WAIT状态
理解 CLOSE_WAIT 状态
超时重传机制
流量控制
滑动窗口
快重传机制
拥塞控制
延迟应答
捎带应答
面向字节流
粘包问题
TCP小结
- 可靠性:
- 提高性能:

TCP协议——TCP全称为 “传输控制协议(Transmission Control Protocol)”，对数据的传输进行一个详细的控制。

TCP协议段格式

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BOU7vjVl-1689855767484)(E:\笔记\image-20230712203609005.png)]$

源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;
32位序号/32位确认号: 用来支持确认应答和按序到达
4位TCP报头长度: 表示该TCP报头有多少个4字节大小;
6位标志位:
URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位窗口大小: 用来进行流量控制
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针: 标识哪部分数据是紧急数据;
40字节头部选项: 暂时忽略;

TCP交付过程

TCP协议根据目标端口号，查OS内部端口号与进程映射的hash表，找到对应进程，找到对应文件描述符和文件描述符表，进而把对应的数据copy到文件缓冲区里，上层调用read就可以读到。

TCP解包过程

Tcp的报头是变长的，其固定长度是20字节，但报头中的选项大小是不确定的。报头中的4位首部长度字段表示该TCP报头有多少个4字节，所以TCP报头的范围是[20~60]，如果tcp报文没有带选项，4位首部长度就是0101（5）。

解包的过程：

先提取20字节，根据固定报头提取4位首部长度*4字节，减去20后即选项的长度，至此就读完了报头，其剩下的都是有效载荷。
TCP没有整个报文的大小，或者有效载荷的大小，因为TCP是面向字节流的，无法判断报文和报文之间的边界，也不需要判断，具体怎么区分由应用层去做。

确认应答机制

距离变长了会导致通信不可靠，而且无法保证最新发送数据是否被对方收到，所以网络中不存在100%可靠的协议。但是，只要我所发出的消息有匹配的应答，就可以保证我刚刚发送的消息一定被对方收到了，这就是TCP的确认应答机制。即当一个报文收到了对应的应答，就能保证我发出去的数据被对方收到了。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8L4sKhP3-1689855767485)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719204518885.png)]$

client一次性可能向服务端发送多个数据，可能会导致发送的顺序不一定是接收的顺序(数据包乱序)，client确认一个应答对应哪一个请求，就需要序号。
TCP的缓冲区可以看是一个字符数组，TCP协议将每个字节的数据都进行了编号，即为32位序列号。
每一个ACK都带有对应的确认序列号, 告诉发送者我已经收到了哪些数据,下一次你从哪里开始发。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kDvQFCTM-1689855767485)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719204622485.png)]$

32位序号/32位确认序号

每一个TCP报文携带完整的报头，报头中有32位序号和32位确认号，确认序号一般是收到的序号+1，来一一对应请求和应答。
确认序号：表示确认序号之前的所有报文已经全部收到，告诉对方下次发送以确认序号指明的序号发送。
32位序号和32位确认序号允许部分确认丢失或者不给应答。
因为TCP是全双工的，任何通信的一方既可以收也可以发，双方通信时候的两对信号，就可以保证了双方在两个方向上的可靠性。
收到的报文可能是乱序的，有了序号，就可以根据报文中的序号进行排序，保证了报文按序到达。
总结：32位序号/32位确认号的作用是为了支持确认应答和按序到达。

TCP全双工

当使用write、read、recv、send等网络IO接口时，本质做的就是将数据拷贝到OS内部传输层协议的缓冲区中，TCP协议控制缓冲区数据的接收和发送。TCP既有发送缓冲区，又有接收缓冲区的，client和server就有了两对接收和发送缓冲区，所以能支持TCP全双工。

16位窗口大小-流量控制

TCP能控制缓冲区数据的接收和发送，同时也要控制发送和接收数据的快慢，TCP根据接收端的接收能力来决定发送端的发送速度，这个机制就叫做流量控制。

TCP 报头的 “16位窗口大小” 字段表示接收端的剩余接收缓冲区的大小。
接收端将自己接收缓冲区的大小放入 TCP 首部中的 “窗口大小” 字段,通知发送端。
16位数字最大表示65535字节，但是TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小 = 窗口字段的值左移 M 位。
窗口大小越大, 说明网络的吞吐量越高；接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度;如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端。

6位标志位

服务端会接收到大量的报文，但是每一种报文的匹配动作不尽相同，标志位本质就是用来标记不同的报文类型，每种报文匹配的动作是不一样的。TCP协议报头中的6位标志位中每个bit位表示特定的含义，以此来区分不同的报文类型。

URG: 紧急指针是否有效，将16位紧急指针指向的有效载荷部分的数据尽快的向上交付，通常用于机器管理。TCP具有按序到达机制的，发送数据被上方读取必须有先后顺序，如果想插队就需要URG标志位。
ACK: 确认应答标志位，凡是该报文就有应答特征，该标志位都会被设置位1，表示确认应答，大部分网络报文的ACK都是被设置为1的。
PSH: 督促对方尽快将数据进行向上交付，将数据读走。
RST: 对方要求重新建立连接，携带RST标识的报文称为复位报文。
SYN: 请求建立连接标志位，携带SYN标识的报文称为同步报文，表示该报文是一个连接请求的报文。
FIN: 通知对方本端要关闭了, 携带FIN标识的报文称为结束报文，表示该报文是一个断开连接的报文。

如何理解连接

当server端对外提供服务的时候，一定会有大量的client连接server，OS需要用先描述再组织的方式管理这些连接。连接的本质：建立连接成功的时候，就是在内存中创建对应的连接对象，对多个连接对象进行某种数据结构的组织，连接的管理就变为了对某种数据结构的管理，维护连接要消耗内存资源和cpu资源。

理解三次握手

在正常情况下, TCP要经过三次握手建立连接, 四次挥手断开连接。
$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jcX0YEQE-1689855767485)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719212619194.png)]$

第一次握手：client发出携带SYN标志位的报文给server并阻塞等待服务器应答。
第二次握手：server收到client的携带SYN标志位的报文, 会应答一个携带SYN+ACK标志位的报文表示同意建立连接。
第三次握手：client收到server发送的携带SYN-ACK标志位的报文, 会应答一个携带ACK标志位的报文表示确认收到。

注意：

三次握手有时间成本，并且客户端和服务端连接的时候，发送的是完整的报文信息。
三次握手不一定要保证连接成功，客户端只要将ACK发出，就会变为ESTABLISHED状态，但是只要服务端收到了真正的ACK才会建立真正的连接。
三次握手对客户端和服务端都要起效，各自通信了三次。

为很么要三次握手？

服务器维护连接是需要成本的，一次握手和两次握手没办法避免SYN洪水问题，三次握手能够以最小的成本减少服务端资源的消耗。另外，奇数次握手可以保证只要服务端建立连接，客户端必须建立连接，将服务端连接的成本嫁接给客户端并验证了全双工。

理解四次挥手

第一次挥手：client调用close()关闭连接, client会向server发送携带FIN标志位的报文;
第二次挥手：server收到携带FIN标志位的报文后, server会向client回应携带ACK标志位的报文;
第三次挥手：server知道client关闭了连接, 也调用close关闭连接, 这个时候server会向client发送一个携带FIN标志位的报文;
第四次挥手：client收到携带FIN标志位的报文, 再回应一个携带ACK标志位的报文给server。

注意：

断开连接的时候ACK和FIN可以被压缩为一次报文，也称为为三次挥手

为什么连接的时候是三次握手，关闭的时候却是四次握手？

建立连接时，Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的，所以建立连接只需要三次握手。由于TCP是全双工协议，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

理解TIME_WAIT状态

服务端状态变化：

[CLOSED -> LISTEN] ——服务器端调用listen后进入LISTEN状态, 等待客户端连接。
[LISTEN -> SYN_RCVD]—— 一旦监听到连接请求, 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文。
[SYN_RCVD -> ESTABLISHED]——服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了。
[ESTABLISHED -> CLOSE_WAIT]——当客户端主动关闭连接, 服务器会收到结束报文, 服务器返回确认报文并进入CLOSE_WAIT状态。
[CLOSE_WAIT -> LAST_ACK]—— 进入CLOSE_WAIT后说明服务器准备关闭连接; 当服务器真正调用close关闭连接时, 会向客户端发送FIN报文, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来。
[LAST_ACK -> CLOSED]——服务器收到了FIN对应的ACK, 彻底关闭连接。

客户端状态变化

[CLOSED -> SYN_SENT]——客户端调用connect, 发送同步报文。
[SYN_SENT -> ESTABLISHED]——connect调用成功, 则进入ESTABLISHED状态, 开始读写数据。
[ESTABLISHED -> FIN_WAIT_1]——客户端主动调用close时, 向服务器发送结束报文段, 同时进入
FIN_WAIT_1状态。
[FIN_WAIT_1 -> FIN_WAIT_2]——客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文。
[FIN_WAIT_2 -> TIME_WAIT]——客户端收到服务器发来的结束报文, 进入TIME_WAIT状态, 并发出LAST_ACK;
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态。

TCP协议规定：主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL的时间后才能回到CLOSED状态。
在TIME_WAIT状态期间，仍然不能再次使用同样的ip和端口。
MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失，同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);

理解 CLOSE_WAIT 状态

如果服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成。这是一个 BUG，只需要加上对应的 close 即可解决问题。

超时重传机制

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3UY5e8qH-1689855767486)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719222402868.png)]$

假设主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B；如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发，这就是超时重传机制。

超时时长不能太长，会影响整体的重传效率；也不能太短，有可能会频繁发送重复的包。
超时时长不能固定，因为网络环境有差异，超时时长的设置也不应该相同。TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。
超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍。累计到一定的重传次数，TCP认为网络或者对端主机出现异常, 强制关闭连接。

流量控制

TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制(Flow Control);

流量控制是两个方向上的流量控制。
三次握手的时候，前两次不能携带有效载荷，但是可以TCP报头中16位窗口的大小，即交换双方缓冲区的大小。
如果接收端缓冲区满了, 就会将窗口置为0，这时发送方不再发送数据。这时窗口探测和窗口更新通知机制将同时被使用。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ebhiAgcE-1689855767486)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719223741760.png)]$

滑动窗口

在确认应答策略中，对每一个发送的数据报文，都要给一个ACK确认应答报文对应，这会导致性能较差，TCP协议中引入滑动窗口机制允许向对方一次发送多条数据，就可以大大的提高性能。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E5V9eo8X-1689855767486)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719224119685.png)]$

滑动窗口的本质就是发送方可以以此向对方发送数据的上限，滑动窗口的上限由对方的接收缓冲区决定。滑动窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，如上图的窗口大小就是4000个字节。
TCP的缓冲区本质是字符数组，滑动窗口属于发送缓冲区的一部分，而滑动窗口的本质是指针或下标，移动就是下标的移动。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jAy5Kfu1-1689855767487)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719225009422.png)]$

滑动窗口的数据区域主要分为三部分，已经发送并且收到应答的数据，可以直接发送且暂时不需要应答的数据，尚未发送的数据。
收到第一个ACK后，滑动窗口向后移动，继续发送第后面的数据;
滑动窗口不一定向右移，当对方接收能力减少的时候，滑动窗口右侧不动，左侧向右移动，象征着对方接收能力一直减少。
tcp的发送缓冲区是环形数组，所以一直右移也不会存在越界的问题。
滑动串口的大小=min(拥塞窗口，对方接收能力的大小)。

快重传机制

数据包已经抵达，ACK被丢了。

这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DVwPIuXO-1689855767487)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719230533638.png)]$

数据包直接丢了

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vczg3fDJ-1689855767487)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719230619912.png)]$

当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 如果发送端连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送; 这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被保存到了接收端系统内核的接收缓冲区中;这种机制被称为高速重发控制/快重传。

拥塞控制

网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。TCP引入慢启动机制，先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

拥塞窗口：单台主机一次向网络中发送大量数据时，可能会引发网络拥塞的上限值。发送开始的时候, 定义拥塞窗口大小为1，每次收到一个ACK应答，拥塞窗口*2。“慢启动” 只是指初使时慢, 但是增长速度非常快，为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长。

当TCP开始启动的时候, 慢启动阈值等于窗口最大值。
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1。
拥塞控制, 是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案。

延迟应答

收到数据以后并不立即返回确认应答，延迟一会，接收端稍微等一会再应答，返回的窗口大小就会变大一些，传输效率就越高——这是延迟应答。

数量限制: 每隔N个包就应答一次;
时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 操作系统不同也有差异; 一般N取2, 超时时间取200ms;

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ulHHv8ap-1689855767487)(C:\Users\11794\AppData\Roaming\Typora\typora-user-images\image-20230719232713893.png)]$