TCP协议

沉着冷静2024

已于 2024-04-07 19:25:54 修改

阅读量985

点赞数 12

分类专栏：网络文章标签： tcp/ip 网络网络协议

于 2024-04-07 19:13:07 首次发布

本文链接：https://blog.csdn.net/dev1cce/article/details/137474543

版权

网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

TCP协议

TCP协议是当今互联网当中使用最为广泛的传输层协议，原因就是TCP提供了详尽的可靠性保证，所以基于TCP的上层应用非常多，比如HTTP、HTTPS、FTP、SSH等，甚至MySQL底层使用的也是TCP。

可靠性

什么是可靠性

TCP协议是一种可靠的传输协议，使用TCP协议能够在一定程度上保证数据传输时的可靠性。

什么是可靠性？

现在计算机大部分都是冯诺依曼结构的，输入设备、输出设备、内存、CPU都在一台机器上。

这几个硬件设备是彼此独立的。如果它们之间要进行数据交互，就必须要想办法进行通信，因此这几个设备实际是用“线”连接起来的。

由于这些硬件设备都是在一台机器上的，所以它们之间的线都是非常短的。但是如果是两个特别远的设备需要进行通信，那就需要非常长的“线”。

如果线一长，数据在长距离传输过程中就可能会出现各种各样的问题，而TCP就是在此背景下诞生的，TCP就是一种保证可靠性的协议。

为什么UDP还会存在

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

其实，可靠和不可靠都是一个中性词，描述的是协议的特点。

TCP是可靠的协议，那么它要做大量的工作去保证数据的可靠，如果不可靠的因素增多，那它的成本就越高

比如，数据在传输时出现了丢包、乱序、检验和失败等等情况，时间上和空间上的成本都会变高。

所以TCP为了解决可靠性的问题，使用上一定比UDP复杂，维护难度一定比UDP高。

UDP是不可靠的协议，所以UDP就不用考虑数据传输时会出现的问题，所以维护难度一定比较低

虽然TCP复杂，但TCP的效率不一定比UDP低，TCP当中不仅有保证可靠性的机制，还有保证传输效率的各种机制。

TCP协议格式

各个字段的含义

源端口号、目的端口号

表示数据从哪个进程，发送到对端主机的哪个进程上。

32位序号、32位确认序号

分别代表TCP报文当中每个字节数据的编号以及对对方的确认，是TCP保证可靠性的重要字段

4位TCP报头长度

表示该TCP报头的长度，以4字节为单位

6位保留字段

TCP报头中暂时未使用的6个比特位

16位窗口大小

保证TCP可靠性机制和效率提升机制的重要字段

16位检验和

由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）

16位紧急指针

标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用

选项字段

TCP报头当中允许携带额外的选项字段，最多40字节

6个标志位

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

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

分离报头和有效载荷

当TCP从底层获取到一个报文后，虽然TCP不知道报头的具体长度，但报文的前20个字节是TCP的基本报头，并且这20字节当中涵盖了4位的首部长度。

步骤：

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

TCP报头当中的4位首部长度描述的基本单位是4字节，这也恰好是报文的宽度。4为首部长度的取值范围是0000 ~ 1111，因此TCP报头最大长度为15 × 4 = 60，因为基本报头的长度是20字节，所以报头中选项字段的长度最多是40字节。
如果TCP报头当中不携带选项字段，那么TCP报头的长度就是20字节，此时报头当中的4位首部长度的值就为20 ÷ 4 = 5 也就是0101。

TCP如何决定交付数据给上层的哪个协议

应用层的每一个网络进程都必须绑定一个端口号。

TCP的报头中涵盖了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理。

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

序号和确认序号

怎么实现可靠？

在网络通信时，一端发出数据后，并不能保证数据成功被对端接收到，因为在网络中可能会出现各种各样的问题。

只有收到对端发送的响应消息后，才能保证上一次发送的数据被对端接收到了。

但是网络中并不能保证百分百的可靠性，双方通信时总会有一条消息得不到响应，实际上并不用保证所以消息的可靠，只需要保证核心数据有响应就可以了。

对于一些无关紧要的数据，我们就不必保证它的可靠性，因为对端没有收到这个响应数据，会判定上次的报文丢失了，会将上次的数据进行重传。

例如，主机A和主机B进行通信，第一个收到是没有必要保证它的可靠性的。

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

序号

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

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

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

TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号。

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

在这里插入图片描述

当对端收到这3个TCP报文后，就会按顺序对这3个TCP报文进行重排，然后放到TCP的接收缓冲区中，此时报文顺序就和发送时的一样了。

确认序号

TCP报头当中的32位确认序号是告诉对端，我当前已经收到了哪些数据，你的数据下一次应该从哪里开始发。

以刚才的例子来说：

如果主机B收到主机A发来的32位序列号为1的报文时，由于该报文含有1000个字节的数据，于是主机B就会发送一个响应，其中确认序号的值会从1变为1001。

响应数据与其他数据一样，也是一个完整的TCP报文，尽管该报文可能不携带有效载荷，但至少是一个TCP报头。

报文丢失怎么办

还是以刚才的例子为例，主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号分别是1、1001、2001。

如果这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了。那么主机B只要对主机A发送TCP报文，其中确认序号填1001即可，告诉主机A下次向我发送数据时应该从序列号为1001的字节数据开始进行发送。

注意：

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

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

为什么有两套序号机制

如果通信双方只是一端发送数据，另一端接收数据，那么只用一套序号就可以了。

原因就是因为TCP是全双工的，双方可能同时想给对方发送消息。

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

复习：

32位序号的作用是，保证数据的按序到达，同时这个序号也是作为对端发送报文时填充32位确认序号的根据。
32位确认序号的作用是，告诉对端当前已经收到的字节数据有哪些，对端下一次发送数据时应该从哪一字节序号开始进行发送。
序号和确认序号是确认应答机制的数据化表示，确认应答机制就是由序号和确认序号来保证的。

此外，通过序号和确认序号还可以判断某个报文是否丢失。

窗口大小

TCP的接收缓冲区和发送缓冲区

接收缓冲区

暂时保存接收到的数据

TCP发送缓冲区当中的数据由上层应用，应用层进行写入。

当上层调用write/send这样的系统调用接口时，实际不是将数据直接发送到了网络当中，而是将数据从应用层拷贝到了TCP的发送缓冲区当中。

发送缓冲区

暂时保存还未发送的数据

TCP接收缓冲区当中的数据最终也是由应用层来读取的。

当上层调用read/recv这样的系统调用接口时，实际也不是直接从网络当中读取数据，而是将数据从TCP的接收缓冲区拷贝到了应用层而已。

这两个操作，就相当于我们调用read/write进行读取/写入磁盘上的数据时，并不是直接从磁盘上读数据或向磁盘上写数据，而是对文件缓冲区进行读写操作。

当数据写入到TCP的发送缓冲区后，对应的write/send函数就可以返回了，至于发送缓冲区当中的数据具体什么时候发，怎么发等问题实际都是由TCP决定的。

我们之所以称TCP为传输层控制协议，就是因为最终数据的发送和接收方式，以及传输数据时遇到的各种问题应该如何解决，都是由TCP自己决定的，用户只需要将数据拷贝到TCP的发送缓冲区，以及从TCP的接收缓冲区当中读取数据即可。

注意：通信双方的TCP层都是一样的，因此通信双方的TCP层都是既有发送缓冲区又有接收缓冲区。

发送缓冲区和接收缓冲区的作用：

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

窗口大小

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

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

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

窗口大小字段越大，说明接收端接收数据的能力越强，此时发送端可以提高发送数据的速度。

窗口大小字段越小，说明接收端接收数据的能力越弱，此时发送端可以减小发送数据的速度。

如果窗口大小的值为0，说明接收端接收缓冲区已经被打满了，此时发送端就不应该再发送数据了。

注意：

在编写TCP套接字时，我们调用read/recv函数从套接字当中读取数据时，可能会因为套接字当中没有数据而被阻塞住，本质是因为TCP的接收缓冲区当中没有数据了，我们实际是阻塞在接收缓冲区当中了。
而我们调用write/send函数往套接字中写入数据时，可能会因为套接字已经写满而被阻塞住，本质是因为TCP的发送缓冲区已经被写满了，我们实际是阻塞在发送缓冲区当中了。

6个标志位

存在的原因

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

6个标志位

SYN

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

ACK

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

FIN

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

URG

双方在进行通信时，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，是在告诉对方尽快将你的接收缓冲区当中的数据交付给上层。

其实发送缓冲区和接收缓冲区是有一个水位线的。

怎么理解呢？

例如，你要买1kg苹果，如果秤上的苹果只有800g，你是不会提走袋子的，直到有了1kg，你才会提走。

但是如果设置了PSH，就想到于，你妈让你赶紧称一点苹果就回来，你就是称不到1kg也会提前提走。

当报文当中的PSH被设置为1时，实际就是在告知对方操作系统，尽快将接收缓冲区当中的数据交付给上层，尽管接收缓冲区当中的数据还没到达所指定的水位线。这也就是为什么我们使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数是不一定吻合的。

RST

报文当中的RST被设置为1，表示需要让对方重新建立连接。

设置RST的情况：

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

确认应答机制

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

确认应答机制就是由TCP报头当中的，32位序号和32位确认序号来保证的。

确认应答机制不是保证双方通信的全部消息的可靠性，而是通过收到对方的应答消息，来保证自己曾经发送给对方的某一条消息被对方可靠的收到了。

怎么理解TCP把每个字节数据都进行了编号呢？

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

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

注意：双方在通信时，本质就是将自己发送缓冲区当中的数据拷贝到对方的接收缓冲区当中。

超时重传机制

双方在进行网络通信时，发送方发出去的数据在一个特定的时间间隔内如果得不到对方的应答，此时发送方就会进行数据重发，这就是TCP的超时重传机制。

TCP保证双方通信的可靠性，一部分是通过TCP的协议报头体现出来的，还有一部分是通过实现TCP的代码逻辑体现出来的。

比如超时重传机制实际就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送数据的确认应答报文，则会对该报文进行重传，这就是通过TCP的代码逻辑实现的，而在TCP报头当中是体现不出来的。

超时重传的两种情况

发送的数据报文丢失了，此时发送端在一定时间内收不到对应的响应报文。
对端发来的响应报文丢包了，此时发送端也会因为收不到对应的响应报文，而进行超时重传。

注意：

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

特定的时间

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

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

因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证“确认应答一定能在这个时间内返回”。

但这个时间的长短，是与网络环境有关的。网络状况好的时候重传的时间可以设置的短一点，网络状况不好的时候重传的时间可以设置的长一点。

也就是说超时重传设置的等待时间一定是上下浮动的，所以这个时间不可能是某个固定值。

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

计算超时最大时间

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

连接管理机制

TCP是面向连接的

TCP的各种可靠性机制实际都不是从主机到主机的，而是基于连接的，与连接是强相关的。

比如一台服务器启动后可能有多个客户端前来访问，如果TCP不是基于连接的，也就意味着服务器端只有一个接收缓冲区，此时各个客户端发来的数据都会拷贝到这个接收缓冲区当中，此时这些数据就可能会互相干扰。

每个连接都有自己的发送缓冲区和接收缓冲区。

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

操作系统对连接的管理

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

操作系统在管理这些连接时需要“先描述，再组织”，在操作系统中一定有一个描述连接的结构体，该结构体当中包含了连接的各种属性字段，所有定义出来的连接结构体最终都会以某种数据结构组织起来，此时操作系统对连接的管理就变成了对该数据结构的增删查改。
建立连接，实际就是在操作系统中用该结构体定义一个结构体变量，然后填充连接的各种属性字段，最后将其插入到管理连接的数据结构当中即可。
断开连接，实际就是将某个连接从管理连接的数据结构当中删除，释放该连接曾经占用的各种资源。

因此连接的管理也是有成本的，这个成本就是管理连接结构体的时间成本，以及存储连接结构体的空间成本。

TCP的三次握手和四次挥手

三次握手

三次握手的过程

双方在进行TCP通信之前需要先建立连接，建立连接的这个过程我们称之为三次握手。

当客户端想要和服务器通信时，需要先建立连接，客户端会主动向服务器发送连接建立请求，双方在TCP底层就会进行三次握手。

第一次握手：客户端向服务器发送的报文当中的SYN位被设置为1，表示请求与服务器建立连接。

第二次握手：服务器收到客户端发来的连接请求报文后，紧接着向客户端发起连接建立请求并对客户端发来的连接请求进行响应，此时服务器向客户端发送的报文当中的SYN位和ACK位均被设置为1。

第三次握手：客户端收到服务器发来的报文后，得知服务器收到了自己发送的连接建立请求，并请求和自己建立连接，最后客户端再向服务器发来的报文进行响应。

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

为什么是三次握手

首先连接建立不是百分之百能成功的，通信双方在进行三次握手时，其中前两次握手能够保证被对方收到。

因为前两次握手都有对应的下一次握手对其进行响应，但第三次握手是没有对应的响应报文的，如果第三次握手时客户端发送的ACK报文丢失了，那么连接建立就会失败。

如果客户端发起第三次握手后就完成了三次握手，但服务器却没有收到客户端发来的第三次握手，此时服务器端就不会建立对应的连接。

所以建立连接时不管采用几次握手，最后一次握手的可靠性都是不能保证的。

综上看来，三次握手是验证双方通信信道的最小次数：

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

三次握手能够保证连接建立时的异常连接挂在客户端

当客户端收到服务器发来的第二次握手时，客户端就已经证明双方通信信道是连通的了，因此当客户端发出第三次握手后，这个连接就已经在客户端建立了。

而只有当服务器收到客户端发来的第三次握手后，服务器才知道双方通信信道是连通的，此时在服务器端才会建立对应的连接。

因此双方在进行三次握手建立连接时，双方建立连接的时间点是不一样的。如果客户端最后发出的第三次握手丢包了，此时在服务器端就不会建立对应的连接，而在客户端就需要短暂的维护一个异常的连接。

维护连接是需要时间成本和空间成本的，因此三次握手还有一个好处就是能够保证连接建立异常时，这个异常连接是挂在客户端的，而不会影响到服务器。

虽然此时客户端也需要短暂维护这个异常，但客户端的异常连接不会特别多，不像服务器，一旦多个客户端建立连接时都建立失败了，此时服务器端就需要耗费大量资源来维护这些异常连接。

此外，建立连接失败时的异常连接不会一直维护下去。

如果服务器端长时间收不到客户端发来的第三次握手，就会将第二次握手进行超时重传，此时客户端就有机会重新发出第三次握手。

或者当客户端认为连接建立好后向服务器发送数据时，此时服务器会发现没有和该客户端建立连接而要求客户端重新建立连接。

所以TCP采用三次握手的原因：

三次握手是验证双方通信信道的最小次数，能够让能建立的连接尽快建立起来。
三次握手能够保证连接建立时的异常连接挂在客户端（风险转移）。

三次握手时的状态变化

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

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

三次握手结束，通信双方可以开始进行数据交互了。

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

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

四次挥手

四次挥手的过程

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

当客户端与服务器通信结束后，需要与服务器断开连接，此时就需要进行四次挥手。

第一次挥手：客户端向服务器发送的报文当中的FIN位被设置为1，表示请求与服务器断开连接。

第二次挥手：服务器收到客户端发来的断开连接请求后对其进行响应。

第三次挥手：服务器收到客户端断开连接的请求，且已经没有数据需要发送给客户端的时候，服务器就会向客户端发起断开连接请求。

第四次挥手：客户端收到服务器发来的断开连接请求后对其进行响应。

为什么是四次挥手

由于TCP是全双工的，建立连接的时候需要建立双方的连接，断开连接时也同样如此。

在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手。

注意：四次挥手当中的第二次和第三次挥手不能合并在一起。

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

四次挥手时的状态变化如下：

在挥手前客户端和服务器都处于连接建立后的ESTABLISHED状态。
客户端为了与服务器断开连接主动向服务器发起连接断开请求，此时客户端的状态变为FIN_WAIT_1。
服务器收到客户端发来的连接断开请求后对其进行响应，此时服务器的状态变为CLOSE_WAIT。
当服务器没有数据需要发送给客户端的时，服务器会向客户端发起断开连接请求，等待最后一个ACK到来，此

时服务器的状态变为LASE_ACK。
客户端收到服务器发来的第三次挥手后，会向服务器发送最后一个响应报文，此时客户端进入TIME_WAIT状态。
当服务器收到客户端发来的最后一个响应报文时，服务器会彻底关闭连接，变为CLOSED状态。
客户端则会等待一个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状态就是争取让主动发起四次挥手的客户端维护这个成本。

因此TCP并不能完全保证建立连接和断开连接的可靠性，TCP保证的是建立连接之后，以及断开连接之前双方通信数据的可靠性。

TIME_WAIT的等待时长是多少？

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

太长会让等待方维持一个较长的时间的TIME_WAIT状态，在这个时间内等待方也需要花费成本来维护这个连接，这也是一种浪费资源的现象。
太短可能没有达到我们最初目的，没有保证ACK被对方较大概率收到，也没有保证数据在网络中消散，此时TIME_WAIT的意义也就没有了。

TCP协议规定，主动关闭连接的一方在四次挥手后要处于TIME_WAIT状态，等待两个MSL（Maximum Segment Lifetime，报文最大生存时间）的时间才能进入CLOSED状态。

我们可以通过命令来查看MSL的值，Centos7上默认配置的值是60s。

cat /proc/sys/net/ipv4/tcp_fin_timeout

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

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

流量控制

TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，这个机制叫做流量控制（Flow Control）。

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

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

接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。

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

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

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

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

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

等待告知。

接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。

主动询问。

发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了。

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

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

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

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

滑动窗口

双方在进行TCP通信时可以一次向对方发送多条数据，这样可以将等待多个响应的时间重叠起来，进而提高数据通信的效率。

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

滑动窗口

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

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

第一部分：已经发送并且已经收到ACK的数据。
第二部分：已经发送还但没有收到ACK的数据。
第三部分：还没有发送的数据。

这里发送缓冲区的第二部分就叫做滑动窗口。（也有人把这三部分整体称之为滑动窗口，而将其中的第二部分称之为窗口大小）

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

此时的滑动窗口大小为：4001 - 1001字节。

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

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

当发送方发送出去的数据段陆陆续续收到对应的ACK时，就可以将收到ACK的数据段归置到滑动窗口的左侧，并根据当前滑动窗口的大小来决定，是否需要将滑动窗口右侧的数据归置到滑动窗口当中。

注意：

TCP的重传机制要求暂时保存发出但未收到确认的数据，而这部分数据实际就位于滑动窗口当中，只有滑动窗口左侧的数据才是可以被覆盖或删除的。

因为这部分数据才是发送并被对方可靠的收到了，所以滑动窗口除了限定不收到ACK而可以直接发送的数据之外，滑动窗口也可以支持TCP的重传机制。

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

滑动窗口不一定会整体右移的。

以刚才的例子为例，假设对方已经收到了1001-2000的数据段并进行了响应，但对方上层一直不从接收缓冲区当中读取数据，此时当对方收到1001-2000的数据段时，对方的窗口大小就由3000变为了2000。

当发送端收到对方的响应序号为2001时，就会将1001-2000的数据段归置到滑动窗口的左侧，但此时由于对方的接收能力变为了2000，而当1001-2000的数据段归置到滑动窗口的左侧后，滑动窗口的大小刚好就是2000，因此滑动窗口的右侧不能继续向右进行扩展。

所以滑动窗口在向右移动的过程中并不一定是整体右移的，因为对方接收能力可能不断在变化，从而滑动窗口也会随之不断变宽或者变窄。

如何实现滑动窗口

我们把TCP接收和发送缓冲区都看作一个字符数组，滑动窗口实际就可以看作是两个指针限定的一个范围。

start指向窗口最左侧，end指向窗口最右侧，在start和end区间的范围就可以看作滑动窗口。

当发送端收到对方的响应时，如果响应当中的确认序号为new_start，窗口大小为win，我们就可以把start更新为new_start，end更新为 start + win。

丢包问题

发送端一次发送多个报文数据时，此时的丢包情况也可以分为两种。

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

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

例如，虽然1-1000和1001-2000的ACK丢失了，但是主机A收到了2001-3000的ACK，于是主机A知道了1-1000和1001-2000的数据，主机B已经收到了，只是丢失了。

因为主机B没有收到1-1000和1001-2000的数据是不能设置确认序号为3001的；确认序号为3001的含义就是序号为1-3000的字节数据我都收到了，你下一次应该从序号为3001的字节数据开始发送。

情况二：数据包丢失了

当1-1000的数据包丢失后，发送端会一直收到确认序号为1的响应报文，就是在提醒发送端“下一次应该从序号为1的字节数据开始发送“。

如果发送端连续收到三次确认序号为1的响应报文，此时就会将1-1000的数据包重新进行发送。
此时当接收端收到1-1000的数据包后，就会直接发送确认序号为3001的响应报文，因为2001-3000的数据接收端其实在之前就已经收到了。

这种机制被称为“高速重发控制”，也叫做“快重传”。

注意：

快重传需要在大量的数据重传和个别的数据重传之间做平衡，实际这个例子当中发送端并不知道是1-1000这个数据包丢了，当发送端重复收到确认序号为1的响应报文时，理论上发送端应该将1-3000的数据全部进行重传，但这样可能会导致大量数据被重复传送。

所以发送端可以尝试先把1-1000的数据包进行重发，然后根据重发后的得到的确认序号继续决定是否需要重发其它数据包。

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

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

第1-1000的数据丢失了，后面的数据已经被接收。此时对方发来的确认序号也只能是1，当发送端补发了1-1000的数据包后，对方发来的确认序号就会变为3001。

快重传和超时重传

- 快重传是能够快速进行数据的重发，当发送端连续收到三次相同的应答时就会触发快重传；
- 而不像超时重传一样需要通过设置重传定时器，在固定的时间后才会进行重传。
虽然快重传能够快速判定数据包丢失，但快重传并不能完全取代超时重传

因为有时数据包丢失后可能并没有收到对方三次重复的应答，此时快重传机制就触发不了，而只能进行超时重传。

因此快重传虽然是一个效率上的提升，但超时重传却是所有重传机制的保底策略，也是必不可少的。

拥塞控制

慢启动

虽然滑动窗口能够高效可靠的发送大量的数据，但如果在刚开始阶段就发送大量的数据，就可能会引发某些问题。

因为网络上有很多的计算机，有可能当前的网络状态就已经比较拥塞了，因此在不清楚当前网络状态的情况下，贸然发送大量的数据，就可能会引起网络拥塞问题。

因此TCP引入了慢启动机制，在刚开始通信时先发少量的数据探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

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

每收到一个ACK应答拥塞窗口的值就加一，此时拥塞窗口就是以指数级别进行增长的，如果先不考虑对方接收数据的能力，那么滑动窗口的大家就只取决于拥塞窗口的大小，此时拥塞窗口的大小变化情况如下:

拥塞窗口	滑动窗口
1=2^0	1
1+1=2^1	2
2+2=2^2	4
4+4=2^3	8
…	…

注意：指数级增长是非常快的，因此“慢启动”实际只是初始时比较慢，但越往后增长的越快。如果拥塞窗口的值一直以指数的方式进行增长，此时就可能在短时间内再次导致网络出现拥塞。

所以：

为了避免短时间内再次导致网络拥塞，因此不能一直让拥塞窗口按指数级的方式进行增长。

此时就引入了慢启动的阈值，当拥塞窗口的大小超过这个阈值时，就不再按指数的方式增长，而按线性的方式增长。

当TCP刚开始启动的时候，慢启动阈值设置为对方窗口大小的最大值。

在每次超时重发的时候，慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口的值被重新置为1，如此循环下去。

说明：

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

主机在进行网络通信时，实际就是在不断进行指数增长、加法增大和乘法减小。

注意：

不是所有的主机都是同时在进行指数增长、加法增大和乘法减小的。每台主机认为拥塞窗口的大小不一定是一样的，即便是同区域的两台主机在同一时刻认为拥塞窗口的大小也不一定是完全相同的。

因此在同一时刻，可能一部分主机正在进行正常通信，而另一部分主机可能已经发生网络拥塞了。

延迟应答

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

假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K。

但实际接收端处理数据的速度很快，10ms之内就将接收缓冲区中500K的数据处理掉了。

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

如果接收端稍微等一会再进行ACK应答，比如等待100-200ms再应答，那么这时返回的窗口大小可能就是1M。

注意：

延迟应答的目的不是为了保证可靠性，而是留出一点时间让接收缓冲区中的数据尽可能被上层应用层处理掉，此时在进行ACK响应的时候报告的窗口大小就可以更大，从而增大网络吞吐量，进而提高数据的传输效率。
不是所有的数据包都可以延迟应答。

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

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

捎带应答

捎带应答其实是TCP通信时最常规的一种方式，就好比主机A给主机B发送了一条消息，当主机B收到这条消息后需要对其进行ACK应答，但如果主机B此时正好也要给主机A发生消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时主机B发送的这个报文既发送了数据，又完成了对收到数据的响应，这就叫做捎带应答。

捎带应答最直观的角度实际也是发送数据的效率，此时双方通信时就可以不用再发送单纯的确认报文了。

而且，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了。

面向字节流

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

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

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

例如：

100个字节的数据，你可以调用一次read全部读完；或者调用100次read，每次读取1个字节。
100个字节的数据，你可以调用一次write全部写完；或者调用100次，每次写1个字节。

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

粘包问题

什么是粘包

首先要明确，粘包问题中的“包”，是指的应用层的数据包。

在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段。
在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中。
在应用层的角度，看到的只是一串连续的字节数据。

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

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

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

UDP是否存在粘包问题？

不存在。

对于UDP，如果还没有上层交付数据，UDP的报文长度仍然在，同时，UDP是一个一个把数据交付给应用层的，有很明确的数据边界。
在应用层的角度，使用UDP的时候，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况。

TCP和UDP

UDP是不存在粘包问题的，根本原因就是UDP报头当中的16位UDP长度记录的UDP报文的长度，因此UDP在底层的时候就把报文和报文之间的边界明确了。

而TCP存在粘包问题就是因为TCP是面向字节流的，TCP报文之间没有明确的边界。

TCP异常情况

情况一：进程终止

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

当一个进程退出时，该进程曾经打开的文件描述符都会自动关闭。

因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。

也就是说进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别。

情况二：机器重启

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

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

情况三：机器断电或网络断开

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

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

保活策略：

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

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

总结

可靠性	提高性能
检验和	滑动窗口
序号	快速重传
确认应答	延迟应答
超时重传	捎带应答
连接管理
流量控制
拥塞控制

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

TCP的定时器

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

理解传输控制协议

TCP的各种机制实际都没有谈及数据真正的发送，这些都叫做传输数据的策略。

TCP协议是在网络数据传输当中做决策的，它提供的是理论支持，比如TCP要求当发出的报文在一段时间内收不到ACK应答就应该进行超时重传，而数据真正的发送实际是由底层的IP和MAC帧完成的。

TCP做决策和IP+MAC做执行，我们将它们统称为通信细节，它们最终的目的就是为了将数据传输到对端主机。

而传输数据的目的是什么则是由应用层决定的，因此应用层决定的是通信的意义，而传输层及其往下的各层决定的是通信的方式。

基于TCP的应用层协议

常见的基于TCP的应用层协议如下：

HTTP（超文本传输协议）。
HTTPS（安全数据传输协议）。
SSH（安全外壳协议）。
Telnet（远程终端协议）。
FTP（文件传输协议）。
SMTP（电子邮件传输协议）。

SYN洪泛问题

SYN洪泛问题

实际TCP在进行连接管理时会用到两个连接队列：

全连接队列（accept队列）。全连接队列用于保存处于ESTABLISHED状态，但没有被上层调用accept取走的连接。
半连接队列。半连接队列用于保存处于SYN_SENT和SYN_RCVD状态的连接，也就是还未完成三次握手的连接。

连接正常建立的过程：

当客户端向服务器发起连接建立请求后，服务器会对其进行SYN+ACK响应，并将该连接放到半连接队列（syns queue）当中。
当服务器发出的SYN+ACK得到客户端响应后，就会将该连接由半连接队列移到全连接队列（accept queue）当中。
此时上层就可以通过调用accept函数，从全连接队列当中获取建立好的连接了。

连接建立异常：

但如果客户端在发起连接建立请求后突然死机或掉线，那么服务器发出的SYN+ACK就得不到对应的ACK应答。
这种情况下服务器会进行重试（再次发送SYN+ACK给客户端）并等待一段时间，最终服务器会因为收不到ACK应答而将这个连接丢弃，这段时间长度就称为SYN timeout。
在SYN timeout时间内，这个连接会一直维护在半连接队列当中。

此时服务器虽然需要短暂维护这些异常连接，但这种情况毕竟是少数，不会对服务器造成太大影响。

但如果有一个恶意用户故意大量模拟这种情况：向服务器发送大量的连接建立请求，但在收到服务器发来的SYN+ACK后故意不对其进行ACK应答。

此时服务器就需要维护一个非常大的半连接队列，并且这些连接最终都不会建立成功，也就不会被移到全连接队列当中供上层获取，最后会导致半连接队列越来越长。
当半连接队列被占满后，新来的连接就会直接被拒绝，哪怕是正常的连接建立请求，此时就会导致正常用户无法访问服务器。
这种向服务器发送大量SYN请求，但并不对服务器的SYN+ACK进行ACK响应，最终可能导致服务器无法对外提供服务，这种攻击方式就叫做SYN洪水攻击（SYN Flood）。

如何解决SYN洪泛问题

首先这一定是一个综合性的解决方案，TCP作为传输控制协议需要对其进行处理，而上层应用层也要尽量避免遭到SYN洪水攻击。

比如应用层可以记录，向服务器发起连接建立请求的主机信息，如果发现某个主机多次向服务器发起SYN请求，但从不对服务器的SYN+ACK进行ACK响应，此时就可以对该主机进行黑名单认证，此后该主机发来的SYN请求一概不进行处理。

TCP为了防范SYN洪水攻击，引入了syncookie机制。

现在核心的问题就是半连接队列被占满了，但不能简单的扩大半连接队列，就算半连接队列再大，恶意用户也能发送更多的SYN请求来占满，并且维护半连接队列当中的连接也是需要成本的。
因此TCP引入了syncookie机制，当服务器收到一个连接建立请求后，会根据这个SYN包计算出一个cookie值，将其作为将要返回的SYN+ACK包的初始序号，然后将这个连接放到一个暂存队列当中。
当服务器收到客户端的ACK响应时，会提取出当中的cookie值进行对比，对比成功则说明是一个正常连接，此时该连接就会从暂存队列当中移到全连接队列供上层读取。

引入了syncookie机制的好处：

引入syncookie机制后，这些异常连接就不会堆积在半连接队列队列当中了，也就不会出现半连接队列被占满的情况了。
对于正常的连接，一般会立即对服务器的SYN+ACK进行ACK应答，因此正常连接会很快建立成功。
而异常的连接，不会对服务器的SYN+ACK进行ACK应答，因此异常的连接最终都会堆积到暂存队列当中。