传输层协议TCP

一、TCP协议

TCP 全称为"传输控制协议( Transmission Control Protocol ")；人如其名，要对数据的传输进行⼀个详细的控制

(1) TCP协议段格式

源/目的端口号：表示数据是从哪个进程来，到哪个进程去

32位序号/32位确认号：后面详细讲

4位TCP报头长度：表示该TCP头部有多少个32位bit(有多少个4字节)；所以TCP头部最大长度是15 * 4 = 60

6位标志位

URG：紧急指针是否有效

ACK：确认号是否有效

PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走

RST：对方要求重新建立连接；我们把携带RST标识的称为复位报⽂段

SYN：请求建立连接；我们把携带SYN标识的称为同步报文段

FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段

16位校验和：发送端填充，CRC校验；接收端校验不通过，则认为数据有问题；此处的检验和不光包含TCP首部，也包含TCP数据部分

16位紧急指针：标识哪部分数据是紧急数据

40字节头部选项：暂时忽略

(2) 确认应答(ACK)机制

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

每⼀个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下⼀次你从哪里开始发

(3) 超时重传机制

主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B

如果主机A在⼀个特定时间间隔内没有收到B发来的确认应答，就会进行重发

🔺 但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了

🔺 因此主机B会收到很多重复数据；那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉.

Ⅰ、这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果

问：那么，如果超时的时间如何确定?

最理想的情况下，找到⼀个最小的时间，保证"确认应答⼀定能在这个时间内返回"

但是这个时间的长短，随着⽹络环境的不同，是有差异的

如果超时时间设的太长，会影响整体的重传效率

如果超时时间设的太短，有可能会频繁发送重复的包

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

Linux中(BSD Unix和Windows也是如此)，超时以500ms为⼀个单位进⾏控制，每次判定超时重发的超时时间都是500ms的整数倍

如果重发⼀次之后，仍然得不到应答，等待 2*500ms 后再进行重传

如果仍然得不到应答，等待 4*500ms 进行重传；依次类推，以指数形式递增

累计到⼀定的重传次数，TCP认为⽹络或者对端主机出现异常，强制关闭连接

(4) 连接管理机制

在正常情况下，TCP要经过三次握⼿建立连接，四次挥手断开连接

📍 服务端状态转化：

[CLOSED -> LISTEN]服务器端调用listen后进入LISTEN状态，等待客户端连接

[LISTEN -> SYN_RCVD]⼀旦监听到连接请求(同步报文段)，就将该连接放入内核等待队列中，并向客户端发送SYN确认报文

[SYN_RCVD -> ESTABLISHED]服务端⼀旦收到客户端的确认报文，就进入ESTABLISHED状态，可以进行读写数据了

[ESTABLISHED -> CLOSE_WAIT]当客户端主动关闭连接(调用close)，服务器会收到结束报文段，服务器返回确认报文段并进入CLOSE_WAIT

[CLOSE_WAIT -> LAST_ACK]进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据)；当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后⼀个ACK到来(这个ACK是客户端确认收到了FIN)

[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状态转换的⼀个汇总：

较粗的虚线表示服务端的状态变化情况

较粗的实线表示客户端的状态变化情况

CLOSED是⼀个假想的起始点，不是真实状态

(5) 理解TIME_WAIT状态

TCP协议规定，主动关闭连接的一方要处于TIME_WAIT状态，等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态

我们使用Ctrl + C终⽌了server，所以server是主动关闭连接的一方，在TIME_WAIT期间仍然不能再次监听同样的server端口

MSL在RFC1122中规定为两分钟，但是各操作系统的实现不同，在Centos7 / Ubuntu上默认配置的值是60s

可以通过 cat / proc / sys / net / ipv4 / tcp_fin_timeout 查看msl的值

🔺问：想⼀想，为什么是 TIME_WAIT 的时间是 2MSL?

MSL是 TCP 报文的最大生存时间，因此 TIME_WAIT 持续存在 2MSL 的话

就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启，可能会收到来自上⼀个进程的迟到的数据，但是这种数据很可能是错误的)

同时也是在理论上保证最后⼀个报文可靠到达(假设最后⼀个ACK丢失，那么服务器会再重发⼀个 FIN；这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK)

(6) 解决TIME_WAIT状态引起的bind失败的方法

🔺在 server 的 TCP 连接没有完全断开之前不允许重新监听，某些情况下可能是不合理的

服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短，但是每秒都有很⼤数量的客户端来请求)

这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃，就需要被服务器端主动清理掉)，就会产生大量TIME_WAIT连接

由于我们的请求量很大，就可能导致TIME_WAIT的连接数很多，每个连接都会占用⼀个通信五元组 (源ip，源端口，目的ip，目的端口，协议)；其中服务器的 ip 和端口和协议是固定的；如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了，就会出现问题

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

注：对于服务器上出现⼤量的 CLOSE_WAIT 状态，原因就是服务器没有正确的关闭 socket ，导致四次挥手没有正确完成；这是⼀个BUG；只需要加上对应的 close 即可解决问题

(7) 滑动窗口

刚才我们讨论了确认应答策略，对每⼀个发送的数据段，都要给⼀个ACK确认应答；收到ACK后再发送下⼀个数据段；这样做有⼀个比较大的缺点，就是性能较差；尤其是数据往返的时间较长的时候

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

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值；上图的窗口大小就是4000个字节(四个段)

发送前四个段的时候，不需要等待任何ACK，直接发送

收到第⼀个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推

操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉

窗口越大，则网络的吞吐率就越高

那么如果出现了丢包，如何进⾏重传？这⾥分两种情况讨论

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

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

Ⅱ、数据包就直接丢了

当某⼀段报文段丢失之后，发送端会⼀直收到 1001 这样的ACK，就像是在提醒发送端"我想要的是 "1001" ⼀样

如果发送端主机连续三次收到了同样⼀个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送

这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中

🔺 这种机制被称为"高速重发控制"(也叫"快重传")

(8) 流量控制

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

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

接收端将自己可以接收的缓冲区剩余空间大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端

窗口大小字段越大，说明网络的吞吐量越高

接收端⼀旦发现自己的缓冲区快满了，就会将窗口大小设置成⼀个更小的值通知给发送端

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

如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送⼀个窗口探测数据段，使接收端把窗口大小告诉发送端
cpp 复制代码
    接收端如何把窗⼝⼤⼩告诉发送端呢?回忆我们的TCP⾸部中,有⼀个16位窗⼝字段,
就是存放了窗⼝⼤⼩信息;

    那么问题来了,16位数字最⼤表示65535,那么TCP窗⼝最⼤就是65535字节么?

    实际上,TCP⾸部40字节选项中还包含了⼀个窗⼝扩⼤因⼦M,实际窗⼝⼤⼩是窗⼝字段的值
左移M位
(9) 拥塞控制

虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据；但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题

因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵；在不清楚当前⽹络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的

TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的⽹络拥堵状态，再决定按照多大的速度传输数据

此处引入⼀个概念称为拥塞窗口

发送开始的时候，定义拥塞窗口大小为1

每次收到⼀个ACK应答，拥塞窗口加1

每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口

🔺 像上面这样的拥塞窗口增长速度，是指数级别的；"慢启动"只是指初使时慢，但是增长速度非常快

为了不增长的那么快，因此不能使拥塞窗口单纯的加倍

此处引入⼀个叫做慢启动的阈值

当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长

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

在每次超时重发的时候，慢启动阈值会变成原来的⼀半，同时拥塞窗口置回1
cpp 复制代码
少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为⽹络拥塞;
当TCP通信开始后,⽹络吞吐量会逐渐上升;随着⽹络发⽣拥堵,吞吐量会⽴刻下降;
拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对⽅,但是⼜要避免给⽹络造成太大
压⼒的折中⽅案
TCP拥塞控制这样的过程,就好像热恋的感觉
(10) 延迟应答

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小

假设接收端缓冲区为1M；⼀次收到了500K的数据；如果立刻应答，返回的窗口就是500K

但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了

在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放⼤⼀些，也能处理过来

如果接收端稍微等⼀会再应答，比如等待200ms再应答，那么这个时候返回的窗口⼤⼩就是1M

📍 ⼀定要记得，窗口越大，网络吞吐量就越大，传输效率就越高；我们的目标是在保证网络不拥塞的情况下尽量提高传输效率

那么所有的包都可以延迟应答么?肯定也不是

数量限制：每隔N个包就应答⼀次

时间限制：超过最⼤延迟时间就应答⼀次

具体的数量和超时时间，依操作系统不同也有差异；⼀般N取2，超时时间取200ms

(11) 捎带应答

在延迟应答的基础上，我们发现，很多情况下，客户端服务器在应用层也是"⼀发⼀收"的；意味着客户端给服务器说了 "How are you"，服务器也会给客户端回⼀个"Fine，thank you"

那么这个时候ACK就可以搭顺风车，和服务器回应的"Fine，thank you"⼀起回给客户端

(12) 面向字节流

📍创建⼀个TCP的socket，同时在内核中创建⼀个发送缓冲区和⼀个接收缓冲区

调用write时，数据会先写⼊发送缓冲区中

如果发送的字节数太长，会被拆分成多个TCP的数据包发出

如果发送的字节数太短，就会先在缓冲区里等待，等到缓冲区长度差不多了，或者其他合适的时机发送出去

接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区

然后应用程序可以调用read从接收缓冲区拿数据

另⼀方面，TCP的⼀个连接，既有发送缓冲区，也有接收缓冲区，那么对于这⼀个连接，既可以读数据，也可以写数据；这个概念叫做全双⼯

🔺 由于缓冲区的存在，TCP程序的读和写不需要⼀匹配，例如：

写100个字节数据时，可以调⽤⼀次write写100个字节，也可以调用100次write，每次写⼀个字节

读100个字节数据时，也完全不需要考虑写的时候是怎么写的，既可以⼀次read100个字节，也可以⼀次read⼀个字节，重复100次

(13) 粘包问题

首先要明确，粘包问题中的"包",是指的应用层的数据包

在TCP的协议头中，没有如同UDP⼀样的"报文长度"这样的字段，但是有⼀个序号这样的字段

站在传输层的角度，TCP是⼀个⼀个报文过来的；按照序号排好序放在缓冲区中

站在应用层的角度，看到的只是⼀串连续的字节数据

那么应用程序看到了这么⼀连串的字节数据，就不知道从哪个部分开始到哪个部分，是⼀个完整的应用层数据包

🔺 那么如何避免粘包问题呢? 归根结底就是⼀句话，明确两个包之间的边界

对于定长的包，保证每次都按固定大小读取即可；例如上面的Request结构，是固定大小的，那么就从缓冲区从头开始按sizeof(Request)依次读取即可

对于变长的包，可以在包头的位置，约定⼀个包总长度的字段，从而就知道了包的结束位置

对于变长的包，还可以在包和包之间使用明确的分隔符(应用层协议，是程序猿自己来定的，只要保证分隔符不和正⽂冲突即可)

🔺 思考：对于UDP协议来说，是否也存在 "粘包问题" 呢?

对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在；同时，UDP是⼀个⼀个把数据交付给应用层；就有很明确的数据边界

站在应用层的站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收；不会出现"半个"的情况

(14) TCP异常情况
cpp 复制代码
进程终⽌: 进程终⽌会释放⽂件描述符,仍然可以发送FIN.和正常关闭没有什么区别.
机器重启: 和进程终⽌的情况相同.
机器掉电/⽹线断开: 接收端认为连接还在,⼀旦接收端有写⼊操作,接收端发现连接已经不在
了,就会进⾏reset.即使没有写⼊操作,TCP⾃⼰也内置了⼀个保活定时器,会定期询问对⽅是否
还在.如果对⽅不在,也会把连接释放.
另外,应⽤层的某些协议,也有⼀些这样的检测机制.例如HTTP⻓连接中,也会定期检测对
⽅的状态.例如QQ,在QQ断线之后,也会定期尝试重新连接
(15) TCP小结

为什么TCP这么复杂？因为要保证可靠性，同时又尽可能的提高性能

可靠性：校验和、序列号、确认应答、超时重发、连接管理、流量控制、拥塞控制

提高性能：滑动窗口、快速重传、延迟应答、捎带应答

其他：定时器

(16) TCP/UDP对比

我们说了TCP是可靠连接，那么是不是TCP⼀定就优于UDP呢? TCP和UDP之间的优点和缺点，不能简单，绝对的进行比较

TCP用于可靠传输的情况，应用于文件传输，重要状态更新等场景

UDP用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等；另外UDP可以用于广播

归根结底，TCP和UDP都是程序员的⼯具，什么时机用，具体怎么用，还是要根据具体的需求场景去判定

二、补充

没有100%可靠的协议，最新的报文，永远都有应答（对历史报文的可靠性，是能100%确定的）

可靠性：对发出去的报文，要有应答，收到应答，历史报文100%被对方收到

4位首部长度

当我们写入数据时，把数据除4；读出数据时，把数据乘4

这个数据指的是报头长度=20字节+选项长度；选项最长40字节，所以取值范围为[20,60]---(除4)--->[5,15]

确认应答机制

核心：不是保证数据100%发送给对方，能否发送给对方，是基于网络判断的

丢包是被规定出来的，基于传输时间是否超过deadline

从发送方考虑，它无法知道是数据丢了，还是应答丢了

TCP通信，双方地位是对等的！TCP协议通信角度，是"对称的"

32位序号与确认信号

确认序号=32位序号+1表示：在该序号之前的所有数据，我收到了

确认序号--->发过来的数据的最后一个位置

去重场景：当序列1000的报头因转发等问题；迟迟没有送到对应主机而触发了快重传 / 超时重传机制；后发来的1000序列号报头到达了主机，此主机会返回resq=1001的确认序列号，经过一段时间，1000序列号迟迟到来至对应主机，假如resq=10001，那么就会判定这是已经收到的报头，去重并且丢弃报头

序号与确认序号是两个，可以使得发送数据和确认同时进行

🔺 捎带应答=应答+有效载荷

16位窗口大小

流量控制=可靠性+效率

接收方，如何衡量自己的接受能力？接受缓存冲区，剩余空间的大小

发送方如何得知对方的接受能力？把自己的接受能力，填写到应答报文的16位窗口大小中

6位标志位

报文本身是有类型的，TCP报头中，就必须有对应的字段表明报文类型

URG与PSH配合使用

SYN：请求建立连接，三次握手建立连接（本地也可以是4次，但捎带应答）（sever必须应答）a：双方主机建立通信共识；验证全双工，验证网络是否通畅；b：双方OS会存在大量连接，所以要管理大量连接，创建结构体；建立连接是需要成本的

为什么是四次挥手，断开连接？

答：需要征得双方同意

误区：当客户端申请断开连接时发送FIN类型报头，只是不能发送数据了，但能发报头，服务端同理

四次挥手之后，主动断开连接的一方，进入time_wait状态，被动断开立即释放连接

为什么有time_wait：等待一个2MSL的时间

理由1：确保双方4次挥手都尽可能正确完成

理由2：让陈旧报文，在网络中尽可能消散

如果一个报文，我们把他发送出去了，在收到应答之前，这个报文应该被发送方OS丢弃么？

答：不会，这样的报文需要临时保存在缓冲区（滑动窗口）中

我们可以根据对方的接收能力，动态调整发送数据的速率------>流量控制------>具体通过滑动窗口实现

滑动窗口变化：可能变大、变小、不变，但不可能向左滑动

异常工作情况(报文丢失)：为了支持滑动窗口左侧下标，不会跳过任何没有经过确认的报文！！！滑动窗口数据区域被划分到左侧，本质是删除数据

PSH标志位：提示接收端应用程序立刻从TCP缓冲区把数据读走

为什么要存在紧急指针？

答：在我们下载软件的场景下，下载一半时，我们不想下了，要暂停；正常报文是要排队，一次处理；但是我们对于暂停这个动作，不能等到下载完再处理，暂停这个动作要优先处理，即插队

16位紧急指针标识哪一部分数据是紧急数据

发送端设置MSG_OOB时，TCP头部位置URG标志，并填充紧急指针

三次握手：以最小成本验证双方通信意愿问题

🔺 time_wait与地址复用的问题

双方都可以作为断开连接的一方

一方断开的本质：不写了

断开连接，不一定是彻底释放，不发送用户数据，不代表不能发送标志位和报头

客户端进入time_wait状态，不代表彻底关闭连接

地址复用

默认不让使用地址复用，因为是忽略time_wait状态，这样不能让就报文在网络中彻底死亡；会干扰新连接

服务器重启，开启地址复用，就会使用新的fd，创建新的连接，创建新的套接字对象，只是使用了旧的ip和port

📍 套接字！=ip+端口

🔺 如果服务端出现了大量的close_wait状态，服务端可能出现了bug，它可能没有及时关闭对应的fd

4次挥手后，主动断开连接的一方，进入time_wait状态，被动断开立即释放连接

listen接口中的backlog

listen不负责三次握手，listen只是个开关，完成这个动作的是OS与协议栈

没有accept，连接也可以建立成功；accept不负责连接，只是把从内核的全连接队列里，取出一个完成三次握手的连接，创建一个新的fd；返回给用户进程

接收端维持展示不用的accept到应用层的连接个数是有上限的，即backlog+1个

拥塞控制

如果网络出现了问题，1w个中丢了1~2个，是正常情况，重传即可；但丢了9888个，那就是网络出了问题，那么此时不能重传，否则会加重网络的拥塞情况

拥塞窗口（解决方法&&实现技术）

滑动窗口=min(win窗口，拥塞窗口)

拥塞窗口：当发送数据超过该窗口，可能会发生网络拥塞，用来衡量网络拥塞的指标 / 网络接收能力的指标

拥塞控制，和谈恋爱的逻辑是一样的；采用慢启动方式执行，本质是探索网络的接收能力

拥塞窗口应该是变化的，因为网络是变化的，发生拥塞的上限也应该是变化的；TCP不知道拥塞窗口该多大，要不断尝试才知道

从1开始，2^n次方增大；遇到ssthresh变成线性增大，即拥塞避免"加法增大"；遇到网络拥塞时，重新开始慢启动，并且设置新的ssthresh值（在可靠性和效率中寻找平衡点，这种方式特点，恢复快）

延迟应答：通过延时，一定概率可以给发送方通告一个更大的接收窗口

TCP这么复杂是因为要保证可靠性的同时，也要尽可能提高性能