传输层——TCP协议

目录

一、初步认识

二、TCP协议格式

2.1 初识协议格式 

2.2 序号与确认序号

2.3 16位窗口大小

2.4 六个标志位

三、确认应答机制

四、超时重传机制

五、连接管理机制

5.1 三次挥手

5.2 四次挥手

 六、流量控制

七、滑动窗口

八、拥塞控制

九、延迟应答

十、捎带应答

十一、面向字节流

十二、粘包问题

十三、TCP异常情况

十四、TCP小结

一、初步认识

TCP全称"传输控制协议"（Transmission Control Protocol），是如今互联网应用最为广泛的传输层协议

网络通信存在不可靠性

如今大部分计算机都基于冯诺依曼体系结构 

虽然输入设备、输出设备、内存、CPU等都在一台机器上，但各个硬件设备彼此独立。若它们之间要进行数据交互，就必须要进行通信，因此这几个设备实际是用"线"连接起来的，其中连接内存和外设之间的"线"是IO总线，而连接内存和CPU之间的"线"被称为系统总线。由于这几个硬件设备都在同一台机器上，因此这里传输数据的"线"很短，传输数据时出现错误的概率也较低

但若要进行通信的各个设备相隔千里，那么连接各个设备的"线"就会变得很长，传输数据时出现错误的概率也会大幅增高，此时要保证传输到对端的数据无误，就须引入可靠性

注意：单独的一台计算机可以看作一个小型网络，计算机上的各种硬件设备之间实际也是在进行数据通信，并且在通信时也必须遵守各自的通信协议，只不过更多是描述一些数据的含义

UDP协议存在的合理性

TCP协议是一种可靠的传输协议，使用TCP协议能够在一定程度上保证数据传输时的可靠性，而UDP协议是一种不可靠的传输协议，那这种不可靠的协议存在有什么意义呢？

不可靠和可靠仅是中性词，描述的是协议的特点，并没有贬义：

• TCP协议是可靠的协议，也意味着TCP协议需要更多的工作来保证传输数据的可靠，并且引起不可靠的因素越多，保证可靠的成本（时间+空间）就越高。如数据在传输过程中出现了丢包、乱序、检验和失败等，都是不可靠的情况
• UDP协议是不可靠的协议，也意味着UDP协议不需要考虑数据传输时可能出现的问题，因此UDP无论是使用还是维护都更为简单
• 虽然TCP复杂，但某些情况下TCP的效率不一定比UDP低，TCP中不仅有保证可靠性的机制，还有提升传输效率的各种机制

UDP和TCP没有谁好，只有谁合适，网络通信时采用TCP还是UDP完全取决于上层的应用场景。若应用场景严格要求数据在传输过程中的可靠性，那么就必须采用TCP协议；若应用场景允许数据传输出现少量丢包，那么优先选择UDP协议，因为UDP协议更为简单、轻量

二、TCP协议格式

2.1 初识协议格式 

TCP报头中各个字段的含义如下：

• 源/目的端口号：表示数据是从哪个进程来、发送到对端主机上的哪个进程
• 32位序号/32位确认序号：分别代表TCP报文中每个字节数据的编号以及对对方的确认，是TCP保证可靠性的重要字段
• 4位首部长度：表示TCP报头的长度，以4字节为单位（最大60字节）
• 6位保留字段：TCP报头中暂时未使用的6个bit位
• 16位窗口大小：保证TCP可靠性机制和效率提升机制的重要字段
• 16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）
• 16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段中的URG字段使用
• 选项字段：TCP报头中允许携带额外的选项字段（最大40字节）

TCP报头中的6位标志位：

• URG：紧急指针是否有效
• ACK：确认序号是否有效
• PSH：提示接收端应用程序立刻将TCP接收缓冲区中的数据读走
• RST：表示要求对方重新建立连接。携带RST标识的报文被称为复位报文段
• SYN：表示请求与对方建立连接。携带SYN标识的报文被称为同步报文段
• FIN：通知对方，本端要关闭了。携带FIN标识的报文被称为结束报文段

TCP报头在内核当中本质是一个位段类型，给数据封装TCP报头时，实际上就是用该位段类型定义一个变量，然后填充TCP报头中的各个属性字段，最后将这个TCP报头拷贝到数据的首部，至此便完成了TCP报头的封装

TCP如何将报头与有效载荷进行分离？

当TCP从底层获取到一个报文后，报文的前20个字节是TCP的基本报头，并且这20字节中包含了4位首部长度。因此TCP是如下分离报头与有效载荷的：

• 当TCP获取到一个报文后，首先读取报文的前20个字节，并从中提取出4位首部长度，此时便获得了TCP报头的大小size
• 若size的值大于20字节，则继续从报文中读取size−20字节的数据，这部分数据就是TCP报头中的选项字段
• 读取完TCP的基本报头和选项字段后，剩下的就是有效载荷了

注意：

• 4位首部长度的基本单位是4字节，4位数据的取值范围是0000 ~ 1111，因此TCP报头最大长度为15 × 4 = 60字节。基本报头的长度是20字节，所以报头中选项字段的长度最多为40字节
• 若TCP报头中不携带选项字段，那么TCP报头的长度就为20字节，此时报头中的4位首部长度的值就为20 ÷ 4 = 5，即0101
• 由上可知，4位首部长度的取值范围为：0101 ~ 1111

TCP如何将有效载荷交付给上层？

应用层的每一个网络进程都绑定了一个端口号。服务端进程显示绑定端口号；客户端进程由系统动态绑定端口号。而TCP的报头中涵盖了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理

注意：内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号快速找到其对应的进程ID，进而找到对应的应用层进程

2.2 序号与确认序号

对于可靠的认识

在进行网络通信时，一方发出的数据后不能保证该数据能够成功被对端收到，因为数据在传输过程中可能会出现各种错误，只有收到对端主机发来的响应消息后，该主机才能保证上一次发送的数据被对端可靠的收到了（只有历史数据可靠）

TCP要保证的是双方通信的可靠性，虽然此时主机A能够保证上一次发送的数据被主机B可靠的收到了，但主机B也需要保证发送给主机A的响应数据被主机A可靠的收到了。因此主机A在收到了主机B的响应消息后，还需要对该响应数据进行响应，但此时又需要保证主机A发送的响应数据的可靠性，这样就陷入死循环

严格意义上来说，互联网通信中不存在百分之百的可靠性，因为双方通信时总有最新的一条消息得不到响应。但实际没有必要保证所有消息的可靠性，只要保证双方通信时发送的每一个核心数据都有对应的响应即可。

对于一些无关紧要的数据（如响应数据），没有必要保证它的可靠性。因为对端若没有收到这个响应数据，会判定上一次发送的报文丢失了，此时对端将上一次发送的数据进行重传即可

这种策略在TCP中被称为确认应答机制。确认应答机制不是保证双方通信的全部消息的可靠性，而是只要一方收到了另一方的应答消息，就说明上一次发送的数据被另一方可靠的收到了

32位序号

若双方在进行数据通信时，只有收到了上一次发送数据的响应才能发下一个数据，那么此时双方的通信过程就是串行的，效率较低

因此双方在进行网络通信时，允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，这样也就能保证这些报文被对方收到

但在连续发送多个报文时，各个报文在进行网络传输时选择的路径可能不同，因此这些报文到达对端主机的先后顺序可能和发送报文的顺序不同。但报文有序也是可靠性的一种，因此TCP报头中的32位序号的作用之一就是用来保证报文的有序性

TCP将发送出去的每个字节数据都进行了编号，这个编号就是序列号：

• 如现在发送端要发送3000字节的数据，若发送端每次发送1000字节，那么就需要用三个TCP报文来发送这3000字节的数据
• 此时这三个TCP报文中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、1001和2001

此时接收端收到了这三个TCP报文后，就可根据TCP报头中的32位序列号对这三个报文进行排序（该动作在传输层进行），重排后将其放入TCP的接收缓冲区中，此时接收端接收报文的顺序就与发送端发送报文的顺序一致了

接收端在进行报文重排时，可以根据当前报文的32位序号与其有效载荷的字节数，进而确定下一个报文对应的序号

32位确认序号

当主机B收到主机A发送过来的32位序号为1的报文时，由于该报文中包含1000字节的数据。主机B已经收到序列号为1-1000的字节数据，于是主机B发给主机A的响应数据的报头中的32位确认序号的值就填成1001

• 一方面是告诉主机A，序列号在1001之前的字节数据已经收到了
• 另一方面是告诉主机A，下次发送数据时应该从序列号为1001的字节数据开始进行发送

注意：响应数据与其他数据相同，也是完整的TCP报文。该报文可能不携带有效载荷，但至少具有完整报头

如何处理报文丢失？

主机A发送了三个报文给主机B，其中每个报文的大小都是1000字节，这三个报文的32位序号分别是1、1001、2001。若这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。此时主机B在对主机A进行响应时，其响应报头中的32位确认序号填的就是1001，告诉主机A下次发送数据时应从序列号为1001的字节数据开始进行发送

此时主机B在给主机A响应时，其32位确认序号不能填3001，因为1001-2000是在3001之前的，若直接给主机A响应3001，就说明序列号在3001之前的字节数据全都收到了。因此主机B只能给主机A响应1001，当主机A收到该确认序号后就会判定序号为1001的报文丢包了，此时主机A就可以选择进行重传

因此发送端可以根据对端发来的确认序号，来判断是报文是否在传输过程中丢失

为什么要用两套序号机制？

若通信双方只有一端发送数据，另一端接收数据，那么只用一套序号即可

• 发送端在发送数据时，将该序号看作是32位序号
• 接收端在对发送端发来的数据进行响应时，将该序号看作是32位确认序号

但TCP并没有这么做，根本原因就是因为TCP是全双工的，双方可能都想给对方发送消息

• 双方发出的报文中，不仅需要填充32位序号来表明当前发送数据的序号
• 还需要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号开始进行发送

因此进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此TCP报头中出现了两套序号

总结

• 32位序号的作用：保证数据的按序到达，同时这个序号也是对端发送报文时填充32位确认序号的根据
• 32位确认序号的作用：告诉对端当前已经收到的字节数据有哪些，对端下一次发送数据时应该从哪一字节序号开始进行发送
• 序号和确认序号是确认应答机制的数据化表示，确认应答机制由序号和确认序号来保证
• 通过序号和确认序号还可以判断某个报文是否丢失

2.3 16位窗口大小

TCP存在接收缓冲区和发送缓冲区

TCP本身是具有接收缓冲区和发送缓冲区的。接收缓冲区用来暂时保存接收到的数据；发送缓冲区用来暂时保存还未发送的数据。这两个缓冲区都在TCP传输层内部实现

• TCP发送缓冲区中的数据由上层进行写入。当上层调用write/send等系统调用接口时，实际不是将数据直接发送到了网络中，而是将数据从应用层拷贝到了TCP的发送缓冲区中。
• TCP接收缓冲区中的数据最终被应用层读取。当上层调用read/recv等系统调用接口时，实际也不是直接从网络中读取数据，而是将数据从TCP的接收缓冲区拷贝到了应用层而已
• 类似于调用read和write进行文件读写时，并不是直接从磁盘读取数据，也不是直接将数据写入到磁盘上，而对文件缓冲区进行的读写操作

当数据写入到TCP的发送缓冲区后，对应的write/send函数（本质上是拷贝函数）就可以返回了，至于发送缓冲区中的数据具体什么时候发，怎么发等问题实际都是由TCP决定的。之所以称TCP为传输控制协议，就是因为最终数据的发送和接收方式、时间，以及传输数据时遇到的各种问题如何解决，都是由TCP自行决定的，用户只需要将数据拷贝到TCP的发送缓冲区，以及从TCP的接收缓冲区中读取数据即可

TCP的发送缓冲区和接收缓冲区存在的意义

• 数据在网络中传输时可能会出现某些错误，此时就可能要求发送端进行数据重传，因此TCP必须提供一个发送缓冲区来暂时保存发送出去的数据，以免数据丢失。只有当发出去的数据被对端可靠的收到后，发送缓冲区中的这部分数据才可以被覆盖
• 接收端处理数据的速度是有限的，为了保证没来得及处理的数据不会被迫丢弃，因此TCP必须提供一个接收缓冲区来暂时保存未被处理的数据。因为数据传输是需要耗费资源与时间的，不能随意丢弃正确的报文
• TCP的数据重排也在接收缓冲区中进行

经典的生产者消费者模型：

• 对于发送缓冲区来说，上层应用不断往发送缓冲区中放入数据，下层网络层不断从发送缓冲区中拿出数据准备进一步封装。此时上层应用扮演的就是生产者的角色，下层网络层扮演的就是消费者的角色，而发送缓冲区对应的就是"交易场所"
• 对于接收缓冲区来说，上层应用不断从接收缓冲区中拿出数据进行处理，下层网络层不断往接收缓冲区中放入数据。此时上层应用扮演的就是消费者的角色，下层网络层扮演的就是生产者的角色，而接收缓冲区对应的就是"交易场所"
• 因此引入发送缓冲区和接收缓冲区相当于引入了两个生产者消费者模型，该生产者消费者模型将上层应用与底层通信细节进行了解耦。生产者消费者模型的引入同时也解决了并发和忙闲不均

窗口大小

当发送端要将数据发送给对端时，本质是把自己发送缓冲区中的数据发送到对端的接收缓冲区中。但缓冲区大小是有限的，若接收端处理数据的速度小于发送端发送数据的速度，那么总有一个时刻接收端的接收缓冲区会被打满，这时发送端再发送数据过来就会造成数据被迫被丢弃，进而引起丢包重传等一系列的连锁反应（浪费资源）

因此TCP报头中就有了16位窗口大小，这个16位窗口大小中填的是自身接收缓冲区中剩余空间的大小，即当前主机接收数据的能力

接收端在对发送端发来的数据进行响应时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以根据这个窗口大小字段来调整自己发送数据的速度

• 窗口大小字段越大，说明接收端接收数据的能力越强，此时发送端可以提高发送数据的速度
• 窗口大小字段越小，说明接收端接收数据的能力越弱，此时发送端可以减小发送数据的速度
• 若窗口大小的值为0，说明接收端接收缓冲区已经被打满了，此时发送端就不应该再发送数据了

2.4 六个标志位

标志位存在的意义

TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文、断开连接时发送的断开连接的报文等。收到不同种类的报文时需要对应执行动作，如正常通信的报文需要放到接收缓冲区中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作
不同种类的报文对应的是不同的处理逻辑，所以要能够区分报文的种类。TCP就是使用报头中的六个标志字段进行区分的，这六个标志位都只占一个bit位

SYN

• 报文中的SYN被设置为1，表明该报文是一个连接建立的请求报文
• 只有在连接建立阶段，SYN才被设置，正常通信时SYN不会被设置

ACK

• 报文中的ACK被设置为1，表明该报文可以对收到的报文进行确认
• 一般除了第一个请求报文没有设置ACK以外，其余报文基本都会设置ACK。因为发送出去的数据本身就对上一条对方发送过来的数据具有一定确认能力，因此双方在进行数据通信时，可以顺便对对方上一次发送的数据进行响应

FIN

• 报文中的FIN被设置为1，表明该报文是一个连接断开的请求报文
• 只有在断开连接阶段，FIN才被设置，正常通信时FIN不会被设置

URG

双方在进行网络通信的时候，由于TCP是保证数据按序到达的，TCP通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的，对端上层在从接收缓冲区读取数据时也是按顺序读取的。但是有时候发送端可能发送了一些"紧急数据"，这些数据需要让对方上层优先提取读取

此时就需要URG标志位，以及TCP报头中的16位紧急指针

• 当URG标志位被设置为１时，需要通过TCP报头中的16位紧急指针来找到紧急数据，否则一般情况下不关注TCP报头中的16位紧急指针
• 16位紧急指针代表的就是紧急数据在报文中的偏移量
• 紧急指针只有一个，只能标识数据段中的一个位置，因此紧急数据只能发送一个字节，而至于这一个字节的具体含义就不展开讨论了

recv函数的第四个参数flags有一个MSG_OOB的选项可供设置，其中OOB是带外数据（out-of-band）的简称，带外数据就是一些比较重要的数据，因此上层若想读取紧急数据，就可以在使用recv函数进行读取，并设置MSG_OOB选项

send函数的第四个参数flags也提供了MSG_OOB的选项，上层若想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项

PSH

报文中的PSH被设置为1，是在催促对方尽快将接收缓冲区中的数据交付给上层，即使接收缓冲区中的数据还没到达所指定的"水位线"

当使用read/recv从缓冲区中读取数据时，若缓冲区中有数据read/recv函数就能够读到数据进行返回，而若缓冲区当中没有数据，那么此时read/recv函数就会阻塞，直到当缓冲区中有数据时才会读取到数据进行返回。实际这种说法是不太准确的，其实接收缓冲区和发送缓冲区都有一个水位线的概念

若接收缓冲区中有一点数据就让read/recv函数读取返回了，此时read/recv就会频繁的进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换有成本）。因此不是接收缓冲区中只要有数据，调用read/recv函数时就能读取到数据进行返回，而是当缓冲区中的数据量达到一定量时（超过水位线）才能进行读取。这就是为什么使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数不一定是吻合的

RST

报文中的RST被设置为1，表示需要让对方重新建立连接
在通信双方在连接未建立好的情况下，一方向另一方发数据，此时另一方发送的响应报文中的RST标志位就会被置1，表示要求对方重新建立连接。在双方建立好连接进行正常通信时，若通信中途发现之前建立好的连接出现了异常也会要求重新建立连接

三、确认应答机制

TCP保证可靠性的机制之一就是确认应答机制

确认应答机制就是由TCP报头中的32位序号和32位确认序号来保证的。确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证曾经发送给对方的某些消息被对方可靠的收到了

TCP将每个字节的数据都进行编号

TCP是面向字节流的，可以将TCP的发送缓冲区和接收缓冲区都想象成一个字符数组

• 上层应用拷贝到TCP发送缓冲区中的每一个字节数据天然有一个序号，即字符数组的下标，只不过这个下标是从1开始向后递增的
• 双方在通信时，本质就是将发送缓冲区中的数据远程拷贝到对方的接收缓冲区中
• 发送方发送数据时报头中所填的序号，实际就是发送的若干字节数据中，首个字节数据在发送缓冲区当中对应的下标
• 接收方接收到数据进行响应时，响应报头中的确认序号实际就是，接收缓冲区中接收到的最后一个有效数据的下一个位置所对应的下标
• 当发送方收到接收方的响应后，就可以从下标为确认序号的位置继续进行发送了

四、超时重传机制

双方在进行网络通信时，发送方发出去的数据在一个特定的事件间隔内若得不到对方的应答，此时发送方就会进行数据重发

TCP保证双方通信的可靠性，一部分是通过TCP的协议报头体现的，还有一部分是通过实现TCP的代码逻辑体现的。如超时重传机制就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送数据的确认应答报文，则会对该报文进行重传，这就是通过TCP的代码逻辑实现的，在TCP报头中是体现不出来的

丢包的多种情况

丢包有多种情况，一种是发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文，就会进行超时重传

一种情况是对方发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文（以为发送失败），而进行超时重传

• 当出现丢包时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传。
• 若是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据。但不用担心，接收方可以根据报头中的32位序号来判断曾经是否收到过这个报文，并且进行报文去重
• 当发送缓冲区中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区中删除或覆盖，而会让其保留在发送缓冲区中，以免需要进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖

超时重传的等待时间

超时重传的时间不能设置的太长也不能设置的太短

• 超时重传的时间设置的太长，会导致丢包后对方长时间收不到对应的数据，进而影响整体重传的效率
• 超时重传的时间设置的太短，会导致对方收到大量的重复报文，可能对方发送的响应报文还在网络中传输而并没有丢包，但此时发送方就开始进行数据重传了，并且发送大量重复报文会也是对网络资源的浪费

因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证"确认应答一定能在这个时间内返回"。但这个时间的长短，是与网络环境有关的。网好的时候重传的时间设置的短一点，网卡的时候重传的时间设置的长一点，即超时重传设置的等待时间一定是上下浮动的，不可能是固定的某个值

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

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍
• 若重发一次之后，仍然得不到应答，下一次重传的等待时间就是2×500ms
• 若仍然得不到应答，那么下一次重传的等待时间就是4×500ms。以此类推，以指数的形式递增
• 当累计到一定的重传次数后，TCP就会认为是网络或对端主机出现了异常，进而强转关闭连接

五、连接管理机制

TCP面向连接

TCP的各种可靠性机制都不是从主机到主机的，而是基于连接的，与连接是强相关的。如一台服务器启动后有多个客户端访问，若TCP不是基于连接的，也意味着服务器端只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区中，此时这些数据就会互相干扰

在进行TCP通信之前需要先建立连接，就是因为TCP的各种可靠性保证都是基于连接的，要保证传输数据的可靠性的前提就是先建立好连接

操作系统对连接的管理

面向连接是TCP可靠性的一种，只有在通信建立好连接才会有各种可靠性的保证，而一台机器上可能会存在大量的连接，此时操作系统就得对这些连接进行管理。

操作系统在管理这些连接时需要"先描述，再组织"，在操作系统中一定有一个描述连接的结构体，该结构体中包含了连接的各种属性字段，所有定义出来的连接结构体都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对该数据结构的增删查改

建立连接，就是在操作系统中用该结构体定义一个结构体变量，然后填充连接的各种属性字段，最后将其插入到管理连接的数据结构中即可；断开连接，就是将某个连接从管理连接的数据结构中删除，释放该连接曾经占用的各种资源。因此连接的管理也是有成本的，这个成本就是管理连接结构体的时间成本，以及存储连接结构体的空间成本

5.1 三次挥手

双方在进行TCP通信之前需先建立连接，建立连接的过程被称为三次握手

以服务器和客户端为例，当客户端想要与服务器进行通信时，需要先与服务器建立连接，此时客户端作为主动方会先向服务器发送连接建立请求，然后双方TCP在底层会自动进行三次握手

• 第一次握手：客户端向服务器发送的报文中的SYN位被设置为1，表示请求与服务器建立连接
• 第二次握手：服务器收到客户端发来的连接请求报文后，紧接着向客户端发起连接建立请求并对客户端发来的连接请求进行响应，此时服务器向客户端发送的报文中的SYN位和ACK位均被设置为1
• 第三次握手：客户端收到服务器发来的报文后，得知服务器收到了自己发送的连接建立请求，并请求和自己建立连接，最后客户端再向服务器发来的报文进行响应

客户端向服务器发起的连接建立请求，是请求建立从客户端到服务器方向的通信连接，而TCP是全双工通信，因此服务器在收到客户端发来的连接建立请求后，服务器也需向客户端发起连接建立请求，请求建立从服务器到客户端方法的通信连接

为什么是三次握手？而不是一次、两次、四次？

连接建立并不是百分之百成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到，因为前两次握手都有对应的下一次握手对其进行响应（没有响应则触发重发机制），但第三次握手是没有对应的响应报文的，若第三次握手时客户端发送的ACK报文丢失了，那么连接建立就会失败

虽然客户端发起第三次握手后就完成了三次握手，但服务器却没有收到客户端发来的第三次握手，此时服务器端就不会建立对应的连接结构体。所以建立连接时不管采用几次握手，最后一次握手的可靠性都是不能保证的

既然连接的建立都不是百分之百成功的，因此建立连接时具体采用几次握手的依据，实际是看几次握手时的优点更多

三次握手是验证双方信道通畅的最小次数：

• TCP是全双工通信的，因此连接建立的核心要务实际是：验证双方的通信信道是否是连通的
• 而三次握手恰好是验证双方通信信道的最小次数，通过三次握手后双方就都能知道自己和对方是否都能够正常发送和接收数据
• 在客户端看来，当它收到服务器发来第二次握手时，说明自己发出的第一次握手被对方可靠的收到了，证明自己能发以及服务器能收，同时当自己收到服务器发来的第二次握手时，也就证明服务器能发以及自己能收，此时就证明自己和服务器都是能发能收的
• 在服务器看来，当它收到客户端发来第一次握手时，证明客户端能发以及自己能收，而当它收到客户端发来的第三次握手时，说明自己发出的第二次握手被对方可靠的收到了，也就证明自己能发以及客户端能收，此时就证明自己和客户端都是能发能收的
• 既然三次握手已经能够验证双方通信信道是否正常了，那么三次以上的握手自然也是可以验证的，但既然三次已经能验证了就没有必要再进行更多次的握手了

三次握手能够保证连接建立时的异常连接挂在客户端（风险转移）：

• 当客户端收到服务器发来的第二次握手时，客户端就已经知道双方信道连通了，因此当客户端发出第三次握手后，这个连接就已经在客户端建立了；服务器只有收到客户端发来的第三次握手后，服务器才知道双方信道是连通的，此时服务器端才会建立对应的连接
• 因此双方在进行三次握手建立连接时，双方建立连接的时间点是不一样的。若客户端最后发出的第三次握手丢包了，此时在服务器端就不需要建立对应的连接，而客户端则需要短暂的维护一个连接
• 维护连接是需要时间成本和空间成本的，三次握手能保证连接建立异常时，这个异常连接是挂在客户端的，而不会影响到服务器。
• 虽然客户端需要短暂维护这个异常连接，但不会特别多。不像服务器，一旦多个客户端建立连接时都建立失败了，此时服务器端就需要耗费大量资源来维护这些异常连接
• 建立连接失败时的异常连接不会一直维护下去。若服务器端长时间收不到客户端发来的第三次握手，就会将第二次握手进行超时重传，此时客户端就有机会重新发出第三次握手。或者当客户端认为连接建立好后向服务器发送数据时，此时服务器会发现没有和该客户端建立连接而要求客户端重新建立连接（RST）

三次握手时的状态变化

三次握手时的状态变化如下：

• 最开始时客户端和服务器都处于CLOSED状态
• 服务器为了能够接收客户端发来的连接请求，需要由CLOSED状态变为LISTEN状态
• 此时客户端就可以向服务器发起三次握手了，当客户端发起第一次握手后，状态变为SYN_SENT状态
• 处于LISTEN状态的服务器收到客户端的连接请求后，将该连接放入内核等待队列中，并向客户端发起第二次握手，此时服务器的状态变为SYN_RCVD
• 当客户端收到服务器发来的第二次握手后，紧接着向服务器发送最后一次握手，此时客户端的连接已经建立，状态变为ESTABLISHED
• 而服务器收到客户端发来的最后一次握手后，连接也建立成功，此时服务器的状态也变成ESTABLISHED

至此三次握手结束，双方可以开始进行正常数据通信了

套接字和三次握手之间的关系

• 在客户端发起连接建立请求前，服务器调用对应listen函数，进入LISTEN状态
• 当服务器进入LISTEN状态后，客户端就可以向服务器发起三次握手了，客户端对应调用的就是connect函数
• connect函数不参与底层的三次握手，connect函数的作用只是发起三次握手。当connect函数返回时，三次挥手已经结束（成功或失败）
• 若服务器端与客户端成功完成了三次握手，此时在服务器端就会建立一个连接，但这个连接在内核的等待队列中，服务器端需要通过调用accept函数将这个建立好的连接获取上来
• 当服务器端将建立好的连接获取上来后，双方就可通过调用read/recv函数和write/send函数进行数据交互了

5.2 四次挥手

四次挥手的过程

双方维护连接都是需要成本的，因此当双方TCP通信结束之后就需要断开连接，断开连接的这个过程被称为四次挥手

以服务器和客户端为例，当客户端与服务器通信结束后，需断开连接，就需进行四次挥手

• 第一次挥手：客户端向服务器发送的报文中的FIN位被设置为1，表示请求与服务器断开连接
• 第二次挥手：服务器收到客户端发来的断开连接请求后对其进行响应
• 第三次挥手：服务器收到客户端断开连接的请求，且已经没有数据需要发送给客户端的时候，服务器就会向客户端发起断开连接请求
• 第四次挥手：客户端收到服务器发来的断开连接请求后对其进行响应

为什么是四次挥手？

由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手

某些情况下可能是三次挥手，第二次挥手与第三次挥手合并为一次（有些文章说不行，其实是可以合并的，只不过有条件，看下面的链接） 

四次挥手中的第二次和第三次挥手在某些情况下不能合并在一起，因为第三次挥手是服务器端想要与客户端断开连接时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应后，不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器端将这些数据发送完后才会向客户端发起第三次挥手

(141条消息) 我问老大：TCP 四次挥手，可以变成三次吗？_四次握手可以变三次-CSDN博客https://blog.csdn.net/chenxuyuana/article/details/126558893

四次挥手的状态变化

• 挥手前客户端和服务器都处于连接建立后的ESTABLISHED状态
• 客户端为了与服务器断开连接主动向服务器发起连接断开请求，此时客户端的状态变为FIN_WAIT_1
• 服务器收到客户端发来的连接断开请求后对其进行响应ACK，此时服务器的状态变为CLOSE_WAIT
• 当服务器没有数据需要发送给客户端时，服务器会向客户端发起断开连接请求，等待最后一个ACK到来，此时服务器的状态变为LASE_ACK
• 客户端收到服务器发来的第三次挥手后，会向服务器发送最后一个响应报文，此时客户端进入TIME_WAIT状态
• 当服务器收到客户端发来的最后一个响应报文时，服务器会彻底关闭连接，变为CLOSED状态
• 处于TIME_WAIT状态的客户端则会等待2MSL（Maximum Segment Lifetime，报文最大生存时间）才会进入CLOSED状态

套接字与四次挥手之间的关系

• 客户端发起断开连接请求，对应客户端主动调用close函数
• 服务器发起断开连接请求，对应服务器主动调用close函数
• 一个close对应的就是两次挥手（一次请求、一次响应），双方都调用close，因此是四次挥手

CLOSE_WAIT

• 双方在进行四次挥手时，若只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入到FIN_WAIT_2状态
• 若服务器没有主动关闭不需要的文件描述符，此时服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少。因此若不及时关闭不用的文件描述符，除了会造成文件描述符泄漏，可能导致连接资源没有完全释放，即内存泄漏问题
• 因此在编写网络套接字代码时，若发现服务器端存在大量处于CLOSE_WAIT状态的连接，此时可以检查是不是服务器没有及时调用close函数关闭对应的文件描述符

TIME_WAIT

• 第一次挥手丢包：客户端收不到服务器的应答，进而进行超时重传
• 第二次挥手丢包：客户端收不到服务器的应答，进而进行超时重传
• 第三次挥手丢包：服务器收不到客户端的应答，进而进行超时重传
• 第四次挥手丢包：服务器收不到客户端的应答，进而进行超时重传

若客户端在发出第四次挥手后立即进入CLOSED状态，此时服务器虽然进行了超时重传，但已经得不到客户端的响应了，因为客户端已经将连接关闭了

服务器在经过若干次超时重发后得不到响应，最终也一定会将对应的连接关闭，但在服务器进行超时重传期间并且维护这条废弃的连接，这对服务器非常不友好

为了避免这种情况，因此客户端在四次挥手后没有立即进入CLOSED状态，而是进入到了TIME_WAIT状态进行等待，此时要是第四次挥手的报文丢包了，客户端也能收到服务器重发的报文然后进行响应

TIME_WAIT状态存在的必要性：

• 客户端在进行四次挥手后进入TIME_WAIT状态，若第四次挥手的报文丢包了，客户端在一段时间内仍然能够接收服务器重发的FIN报文并对其进行响应，能够较大概率保证最后一个ACK被服务器收到
• 客户端发出最后一次挥手时，双方历史通信的数据可能还没有发送到对方。因此客户端四次挥手后进入TIME_WAIT状态，还可以保证双方通信信道上的数据在网络中尽可能的消散
• 第四次挥手丢包后，若网络状态出现了问题，尽管客户端还没有关闭连接，也收不到服务器重发的连接断开请求，此时客户端TIME_WAIT等若干时间最终也会关闭连接，而服务器经过多次超时重传后也会关闭连接。这种情况虽然也让服务器维持了闲置的连接，但毕竟是少数，引入TIME_WAIT状态就是让主动发起四次挥手的客户端承担主要成本（服务器不必维持TIME_WAIT状态）

TIME_WAIT的等待时长是多少？

TIME_WAIT的等待时长既不能太长也不能太短

太长会让等待方维持一个较长的时间的TIME_WAIT状态，在这个时间内等待方也需要花费成本来维护这个连接，浪费资源。太短可能没有达到最初目的，没有保证ACK被对方较大概率收到，也没有保证数据在网络中消散，此时TIME_WAIT就没有意义了。TCP协议规定，主动关闭连接的一方在四次挥手后要处于TIME_WAIT状态，等待两个MSL（报文最大生存时间）的时间才能进入CLOSED状态

MSL在RFC1122中规定为两分钟，但是各个操作系统的实现不同，如在Centos7上默认配置的值是60s。可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout命令来查看MSL

TIME_WAIT的等待时长设置为两个MSL的原因：

• MSL是TCP报文的最大生存时间，因此TIME_WAIT状态持续存在2MSL，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已消散
• 同时也是在理论上保证最后一个报文可靠到达的时间

 六、流量控制

TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度

接收端处理数据的速度是有限的，若发送端发的太快，导致接收端的缓冲区被打满，此时发送端继续发送数据，就会造成丢包，进而引起重传、资源浪费等一系列连锁反应

因此接收端可以将自己接收数据的能力告知发送端，让发送端控制发送数据的速度

• 接收端将接收缓冲区空余大小放入TCP报头的"16位窗口大小"字段，通过ACK通知发送端
• 窗口大小字段越大，说明网络的吞吐量越高
• 接收端一旦发现接收缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端
• 发送端接收到这个窗口之后，就会调整发送速度

当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据

• 等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了
• 主动询问。发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了

16为数字最大表示65535，那TCP窗口最大就是65535吗？

理论上是这样的，但实际上TCP报头中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的

第一次向对方发送数据时如何得知对方的窗口大小？

双方在进行TCP通信之前需先进行三次握手建立连接，而双方在握手时除了验证双方信道是否通畅以外，还进行其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始通信之前就已经知道了对方接收数据能力，所以双方在发送数据时是不会出现缓冲区溢出的

七、滑动窗口

连续发送多个数据

每次仅发送一个数据段（多次IO）效率太低，双方在进行TCP通信时可以一次向对方发送多条数据，等待多个响应的时间重叠，提高通信效率

注意：虽然双方在进行TCP通信时可以一次向对方发送大量的报文，但不能将发送缓冲区中的数据全部一次发送给对端，在发送数据时还需考虑对方的接收能力

滑动窗口

发送方可以一次发送多个报文给对方，此时也就意味着发送出去的这部分报文中有相当一部分数据是暂时没有收到应答的

发送缓冲区中的数据分为三部分：

• 已经发送并且已经收到ACK的数据
• 已经发送还但没有收到ACK的数据
• 还没有发送的数据

滑动窗口描述的是：发送方不用等待ACK一次所能发送的数据最大量

滑动窗口存在的最大意义就是可以提高发送数据的效率：

• 滑动窗口的大小等于对方窗口大小与自身拥塞窗口大小的较小值，因为发送数据时不仅要考虑对方的接收能力，还要考虑当前网络的状况
• 先不考虑拥塞窗口，并且假设对方的窗口大小一直固定为4000，此时发送方不用等待ACK一次所能发送的数据就是4000字节，即滑动窗口的大小为4000字节
• 现在连续发送1001-2000、2001-3000、3001-4000、4001-5000这四个段，不需等待任何ACK，可以直接进行发送
• 当收到对方响应的确认序号为2001时，说明1001-2000这个数据段已经被对方收到了，此时该数据段应被纳入发送缓冲区中的"第一部分"
• 滑动窗口越大，则网络的吞吐率越高，同时也说明对方的接收能力很强

当发送方发送出去的数据段陆续收到对应的ACK时，滑动窗口左边界向右移动，此时收到ACK的数据段就被归置到滑动窗口左侧。再根据当前滑动窗口的大小决定，滑动窗口右边界是否向右移动

TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口中，只有滑动窗口左侧的数据才是可以被覆盖或删除的，因为这部分数据才是发送并被对方可靠的收到了，所以滑动窗口除了支持大量发送以外，也支持TCP的重传机制

滑动窗口一定会整体右移吗？

滑动窗口不一定会整体右移的，假设对方已经收到了1001-2000的数据段并进行了响应，但对方上层一直不从接收缓冲区中读取数据，此时对方的16位窗口大小就由4000变为了3000

当发送端收到对方的响应序号为2001时，1001-2000的数据段依然保存，但此时由于对方的接收能力变为了3000，滑动窗口的大小也变为3000，右侧不能继续向右进行扩展

如何实现滑动窗口

TCP接收和发送缓冲区都被看作一个字符数组，而滑动窗口可以看作是两个指针（下标）限定的一个范围，比如用start指向滑动窗口的左侧，end指向的是滑动窗口的右侧，此时在start和end区间范围内的就可以被称为滑动窗口

 当发送端收到对方的响应时，若响应中的确认序号为x，16位窗口大小为win，此时就可以将start更新为x，而将end更新为start + win

滑动窗口中的数据一定都没有被对方收到吗？

滑动窗口中的数据是可以暂时不用收到对方确认的数据，而不是说滑动窗口中的数据一定都没有被对方收到，滑动窗口中可能有一部分数据已经被对方收到了，但可能因为滑动窗口中一部分数据，在传输过程中出现了丢包等情况，导致后面已经被对方收到的数据得不到响应

如图中的1001-2000的数据包若在传输过程中丢包了，此时虽然2001-5000的数据都被对方收到了，此时对方发来的确认序号是1001，当发送端补发了1001-2000的数据包后，对方发来的确认序号就会变为5001，此时发送缓冲区向右移动

丢包问题

情况一： 数据包已经抵达，ACK响应丢包

在发送端连续发送多个报文数据时，部分ACK丢包并不要紧，此时可以通过后续的ACK进行确认

如图中2001-3000和4001-5000的数据包对应的ACK丢失了，但发送端收到了最后5001-6000数据包的响应，此时发送端就知道2001-3000和4001-5000的数据包实际上被接收端收到了的，因为确认序号为6001的含义就是序号为6000以前的字节数据都收到了，下一次从序号为6001的字节数据开始发送

情况二： 数据包丢包

• 当1001-2000的数据包丢失后，发送端会一直收到确认序号为1001的响应报文，提醒发送端下一次应从序号为1001的字节数据开始发送
• 若发送端连续收到三次确认序号为1001的响应报文，此时就会将1001-2000的数据包重新进行发送（快重传）
• 此时当接收端收到1001-2000的数据包后，就会直接发送确认序号为6001的响应报文，因为2001-6000的数据接收端在之前就已经收到了

快重传需要在大量的数据重传和个别的数据重传之间做平衡，上述例子中发送端并不知道是否仅有1001-2000这个数据包丢了，当发送端重复收到确认序号为1001的响应报文时，理论上发送端应该将1001-7000的数据全部进行重传，但这样可能会导致大量数据被重复传送，所以发送端可以尝试先把1001-2000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包

快重传 VS 超时重传

• 快重传能够快速进行数据的重发，当发送端连续收到三次相同的应答时就会触发快重传，不需像超时重传一样需要通过设置重传定时器，在固定的时间后才会进行重传
• 虽然快重传能够快速判定数据包丢失，但快重传并不能完全取待超时重传，因为有时数据包丢失后可能并没有收到对方三次重复的应答，此时快重传机制就触发不了，而只能进行超时重传
• 快重传虽然是一个效率上的提升，但超时重传却是所有重传机制的保底策略

八、拥塞控制

为什么会有拥塞控制？

两个主机在进行TCP通信的过程中，出现个别数据包丢包的情况是很正常的，此时可以通过快重传或超时重发对数据包进行补发。但若双方在通信时出现了大量丢包，此时就不能认为是正常现象了

TCP不仅考虑了通信双端主机的问题，同时也考虑了网络的问题。双方网络通信时出现少量的丢包TCP是允许的，但一旦出现大量的丢包，此时TCP就不再认为是双方接收和发送数据的问题，而是判断双方通信信道网络出现了拥塞问题，从而需要进行拥塞控制

如何应对网络拥塞问题？

网络出现大面积瘫痪时，通信双方作为网络中两台小小的主机，看似并没有什么作用，但大部分主机都会使用TCP协议，网络出现问题一定是网络中大部分主机共同作用的结果

• 若网络中的主机在同一时间节点向网络中塞入大量数据，此时位于网络中某些关键节点下就可能阻塞许多报文，最终导致报文无法在超时时间内到达对端主机，导致了丢包问题
• 当网络出现拥塞问题时，通信双方虽然不能提出特别有效的解决方案，但双方主机可以做到不加重网络的负担
• 双方通信时若出现大量丢包，不应立即将这些报文重传，而应该少发数据甚至不发数据，待网络状况恢复后双方再恢复数据的传输速率
• 网络拥塞影响的不只是一台主机，而几乎是该网络中的所有主机，发生网络拥塞时所有使用TCP传输控制协议的主机都会执行拥塞避免算法

拥塞控制

虽然滑动窗口能够高效可靠的发送大量的数据，但在不清楚当前网络状态的情况下，贸然发送大量的数据，可能会引起或加重网络拥塞问题。因此TCP引入了慢启动机制，在刚开始通信时先发少量的数据探路，摸清当前网络状况，再决定按照多大的速度传输数据

• TCP除了有16位窗口大小和滑动窗口的概念以外，还有拥塞窗口。拥塞窗口是可能引起网络拥塞的阈值，若一次发送的数据超过了拥塞窗口的大小就可能会引起网络拥塞
• 刚开始发送数据时拥塞窗口大小定义以为1，每收到一个ACK应答拥塞窗口的值就加一
• 每次发送数据包的时候，将拥塞窗口和接收端主机反馈的16位窗口大小比较，取较小值作为实际发送数据的窗口大小，即滑动窗口的大小

每收到一个ACK应答拥塞窗口的值就加一，经过每个传输轮次，拥塞窗口以指数级别进行增长，拥塞窗口的大小变化情况如下：

"慢启动"只是初始时比较慢，越往后增长越快。若拥塞窗口一直以指数的方式进行增长，就可能在短时间内再次导致网络出现拥塞

• 为了避免短时间内再次导致网络拥塞，不能一直让拥塞窗口按指数级的方式进行增长
• 此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值时，就不再按指数的方式增长，而按线性的方式增长
• 当TCP刚开始启动的时候，慢启动阈值设置为对方窗口大小的最大值
• 在每次超时重发时，慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口的值被重新置为1，如此循环下去

• 指数增长。拥塞窗口的初始值为1，并不断按指数的方式进行增长
• 加法增大。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长
• 乘法减小。拥塞窗口在线性增长的过程中，在增大到24时发生了网络拥塞，此时慢启动的阈值将变为当前拥塞窗口的一半，即12。并且拥塞窗口的值被重新设置为1，下一次拥塞窗口由指数增长变为线性增长时拥塞窗口的值是12

九、延迟应答

若接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能较小

• 假设对方接收端缓冲区剩余空间大小为1MB，对方一次收到500KB的数据后，若立即进行ACK应答，此时返回的窗口大小为500KB
• 但接收端处理数据的速度很快，10ms内就将接收缓冲区中500K的数据消费掉了，接收端处理还远没有达到极限
• 若接收端稍等一会再进行ACK应答，如等待20ms再应答，那么这时返回的窗口大小就是1MB

注意：延迟应答的目的不是为了保证可靠性，而是留出时间让接收缓冲区中的数据尽可能被上层应用层消费掉，此时在进行ACK响应时窗口大小就更大，从而增大网络吞吐量，减少IO次数，进而提高数据的传输效率

延迟应答机制也有一定限制 

• 数量限制：每个N个包应答一次
• 时间限制：超过最大延迟时间应答一次（这个时间不会导致误超时重传）

延迟应答具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms

十、捎带应答

捎带应答是TCP通信最常规的机制。当主机A给主机B发送了一条消息，当主机B收到这条消息后需进行ACK应答，但若主机B正好也要给主机A发送消息，此时就不用单独发送一个ACK应答。此时主机B发送的这个报文就可以既包含数据，又包含对收到数据的响应，即捎带应答

捎带应答机制可提高发送数据的效率，此时双方通信时就不用发送单纯的确认报文了，减少网络IO次数

十一、面向字节流

当创建一个TCP的socket时，同时在内核中会创建一个发送缓冲区和一个接收缓冲区。

• 调用write函数可以将数据写入发送缓冲区中，此时write函数就可以进行返回了，接下来发送缓冲区中的数据由TCP自行进行发送
• 若发送的字节数太长，TCP会将其拆分成多个数据包发出。若发送的字节数太短，TCP会先将其留在发送缓冲区中，合适时机再进行发送
• 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区，可以通过调用read函数来读取接收缓冲区中的数据

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

• 写100个字节数据时，可以调用一次write写100字节，也可以调用100次write写1个字节
• 读100个字节数据时，也不需要考虑是怎么写的，既可以一次read100个字节，也可以一次read一个字节，重复100次

对于TCP而言，并不关心发送缓冲区中的是什么数据，在TCP看来只是一个个的字节数据，其任务就是将这些数据准确无误的发送到对方的接收缓冲区中就行了，而至于如何解释这些数据完全由上层应用来决定，这就被称为面向字节流

十二、粘包问题

什么是粘包？

• 粘包问题中的"包"，指的是应用层的数据包
• 在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段（仅有4位首部长度）
• 站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中
• 但站在应用层的角度，看到的只是一串连续的字节数据
• 那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包

如何解决粘包问题

要解决粘包问题，本质就是要明确报文和报文之间的边界。

• 对于定长的包，保证每次都按固定大小读取即可
• 对于变长的包，可以在报头的位置约定一个总长度的字段，从而就知道包的结束位置。如HTTP报头中就包含Content-Length属性，表示正文的长度
• 对于变长的包，还可以在包和包之间使用明确的分隔符。应用层协议是程序员自己来定的，只要保证分隔符不和正文冲突即可

UDP是否存在粘包问题？

• 对于UDP，若还没有上层交付数据，UDP的报文长度字段依然存在。同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界
• 站在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现"半个"的情况

因此UDP是不存在粘包问题的，根本原因是UDP报头中的16位UDP长度记录了UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了，而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界

十三、TCP异常情况

进程终止

当客户端正常访问服务器时，若客户端进程突然崩溃了，此时建立好的连接会怎么样？

当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。即进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别

机器重启

当客户端正常访问服务器时，若将客户端主机重启，此时建立好的连接会怎么样？

当选择重启主机时，操作系统会先杀掉所有进程然后再进行关机重启，因此机器重启和进程终止的情况是一样的，此时双方操作系统也会正常完成四次挥手，然后释放对应的连接资源

机器掉电/网线断开

当客户端正常访问服务器时，若客户端突然掉线了，此时建立好的连接会怎么样？

当客户端掉线后，服务器端在短时间内无法知道客户端掉线了，因此在服务器端会维持与客户端建立的连接，但这个连接也不会一直维持，因为TCP是有保活策略的

• 服务器会定期询问客户端的存在状况，检查对方是否在线，若连续多次没有收到ACK应答，此时服务器就会关闭这条连接
• 客户端也可能会定期向服务器"报平安"，若服务器长时间没有收到客户端的消息，此时服务器也会将对应的连接关闭

其中服务器定期询问客户端的存在状态的做法，叫做基于保活定时器的一种心跳机制，由TCP实现。应用层的某些协议，也有一些类似的检测机制，例如基于长连接的HTTP，也会定期检测对方的存在状态

十四、TCP小结

TCP协议复杂的原因是因为TCP既要保证可靠性，同时又尽可能的提高性能。

可靠性：

• 检验和
• 序列号
• 确认应答
• 超时重传
• 连接管理
• 流量控制
• 拥塞控制

提高性能：

• 滑动窗口
• 快速重传
• 延迟应答
• 捎带应答

注意：TCP的这些机制有些能够通过TCP报头体现，但有一些是通过底层代码逻辑体现出来的

TCP定时器

• 重传定时器：为了控制丢失的报文段或丢弃的报文段，即对报文段确认的等待时间
• 坚持定时器：专门为对方零窗口通知而设立的，即向对方发送窗口探测的时间间隔
• 保活定时器：为了检查空闲连接的存在状态，即向对方发送探查报文的时间间隔
• TIME_WAIT定时器：双方在四次挥手后，主动断开连接的一方需要等待的时长

理解传输控制协议

TCP的各种机制实际都没有谈及数据真正的发送，这些都是传输数据的策略。TCP协议是在网络数据传输中做决策的，提供的仅是理论支持，而数据真正的发送实际是由底层的IP和MAC帧完成的

TCP做决策和IP+MAC做执行，将这些统称为通信细节，最终的目的就是为了将数据传输到对端主机。而传输数据的目的是什么则是由应用层决定的。因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式

基于TCP的应用层协议

常见的基于TCP的应用层协议如下：文章来源地址https://www.toymoban.com/news/detail-437864.html

• HTTP（超文本传输协议）
• HTTPS（安全数据传输协议）
• SSH（安全外壳协议）
• Telnet（远程终端协议）
• FTP（文件传输协议）
• SMTP（电子邮件传输协议）
• 使用TCP套接字自定义的应用层协议

到了这里，关于传输层——TCP协议的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！