【网络】传输层协议-Tcp协议

传输层协议-Tcp协议

Tcp协议

Udp协议不保证数据传输的可靠性，即如果网络发生故障，数据在传输过程中丢失，Udp协议不做任何提示或处理。所以为了保证数据传输的可靠性，引入了Tcp协议。

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，TCP协议是当今互联网当中使用最为广泛的传输层协议，没有之一。

TCP协议被广泛应用，其根本原因就是提供了详尽的可靠性保证，基于TCP的上层应用非常多，比如HTTP、HTTPS、FTP、SSH等，甚至MySQL底层使用的也是TCP。

1.Tcp协议格式

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

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

TCP报头当中的6位标志位：

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

Tcp协议报头与Udp协议报头一样，也是一个结构体来描述的，在系统内核中我们也找到这部分描述：

各字段注释：

struct tcphdr {  
    __be16 source;       // 源端口号，16位  
    __be16 dest;         // 目的端口号，16位  
    __be32 seq;          // 序列号，32位  
    __be32 ack_seq;      // 确认序号，32位  
    __be16 doff_reserved;// 数据偏移和保留位，其中数据偏移占4位，表示TCP头部长度（以32位字为单位）  
    __u8  flags;         // 控制位，包括URG、ACK、PSH、RST、SYN、FIN等  
    __be16 window;       // 窗口大小，16位  
    __sum16 check;       // 校验和，16位  
    __be16 urg_ptr;      // 紧急指针，16位  
};

在传输层数据进行传递时，我们是将结构体直接以二进制流的形式传递的，之前在应用层学习时我们还需要将结构体字段转化为json格式，是为了避免跨平台传输不同系统内核对于结构体定义不同导致的问题，而在传输层这里为了加快通信效率我们直接发送结构体对象，所以相应的在内核中也对跨平台问题进行了处理，如上图所示对于大端机小端机不同的字段定义。

1.1分离报头（解包）—4位首部长度

根据上面字段我们分析发现Tcp协议报头存在一个选项字段，该字段不定长就导致Tcp协议报头的长度是不定的，所以Tcp协议报头中存在有4位首部长度字段，用来确定报头长度，所以在Tcp协议中分离报头的过程如下：

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

需要注意的是，TCP报头当中的4位首部长度描述的基本单位是4字节，这也恰好是报文的宽度。4为首部长度的取值范围是0000 ~ 1111，因此TCP报头最大长度为15 × 4 = 60 15\times4=6015×4=60字节，因为基本报头的长度是20字节，所以报头中选项字段的长度最多是40字节。

如果TCP报头当中不携带选项字段，那么TCP报头的长度就是20字节，此时报头当中的4位首部长度的值就为20 ÷ 4 = 5（基本单位是4字节），也就是0101。

Tcp协议如何通过端口号将数据交付给应用层具体的进程？

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

1.2如何理解封装和解包

操作系统内可能同时存在很多收到了的报文，这些报文还没来得及进行处理，即拷贝到接收缓冲区，甚至还没有交给传输层而在网络层甚至数据链路层，那操作系统如何对这些报文进行管理呢？

先描述，再组织，所以操作系统一定存在一套对报文的管理机制，比如是一个结构体struct sk_buffer：

所以对报文的管理就变成了对链表的增删查改。

如上图所示，一个struct sk_buffer结构体中包含有head字段用来记录报头起始位置，data字段用来记录有效载荷起始位置。

所以封装的过程就是：初始时两个指针指向相同位置，比如此时要添加udp报头，就让head指针减去udp报头结构体的长度，然后再给报头字段赋值，所以所谓的封装就是指针的移动，和填充报头即可。后续再添加报头就是同样的逻辑。

解包的过程也很好理解了，就是获取head指针指向的内容(struct udp_header*)head->src_port，然后将head指针右移head+=sizeof(udp_header)，这就是解包。

1.3序号与确认序号

如何确定接收方接收到了发送方发送的数据。

在实际生活中，当两个人距离很远的时候，我们可能需要大声呼喊来传递数据，那我们如何确定他收到了呢？对方一定会传递给我一种信息来表示他收到了，比如是动作或者喊话。

在网络中也是如此，一方发出的数据后，它不能保证该数据能够成功被对端收到，因为数据在传输过程中可能会出现各种各样的错误，只有当收到对端主机发来的响应消息后，该主机才能保证上一次发送的数据被对端收到了。

实线表示该数据能够被对方可靠的收到，虚线则不能保证。

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

因为只有当一端收到对方的响应消息后，才能保证自己上一次发送的数据被对端可靠的收到了，但双方通信时总会有最新的一条消息，因此无法百分之百保证可靠性。

所以严格意义上来说，互联网通信当中是不存在百分之百的可靠性的，但是我们可以保证最新消息之前的消息都被收到了，即保证历史消息的可靠性。

以上这种机制被称为**“确认应答机制”**，即服务端向客户端发消息，客户端向服务端发响应，客户端向服务端发消息，服务端向客户端发响应。

（1）32位序号

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

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

但在连续发送多个报文时，由于各个报文在进行网络传输时选择的路径可能是不一样的，因此这些报文到达对端主机的先后顺序也就可能和发送报文的顺序是不同的。所以系统为了标识每个报文的身份引入了序号的概念。TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号。

Tcp协议报头中的32位序号填的就是发送数据中首个字节的序列号。

根据这些序列号，Tcp就能保证接收端接收到这些报文时，能够将这些报文按序列号进行重排，此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了。

（2）32位确认序号

确认序号由接收端返回给发送端，用于告知发送端哪些字节的数据已经被成功接收，即接收端期望收到的下一个字节的序号。

比如接收端接收到序号位1的报文，那么此时会根据报文长度（设为1000）得到报文最后一个位置的序号，然后接收端就形成一个（尾部序号 + 1）的确认序号发送回给发送端。

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

如果发生报文丢失的情况，比如主机A发送了三个报文给主机B，其中每个报文都是1000字节，这三个报文的32位序号分别为1、1001、2001。

如果这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。

接收端在收到报文段后，会检查序号是否连续。如果序号不连续，则说明有数据丢失，此时接收端会发送一个带有期望序号（1001）的确认报文段给发送端，请求重发丢失的数据。

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

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

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

但实际TCP却没有这么做，根本原因就是因为TCP是全双工的，双方可能同时想给对方发送消息。

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

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

序号与确认序号之间存在一种紧密的逻辑关系，它们共同维持了TCP的**“确认应答机制”**。

• 发送端：根据接收端返回的确认序号，发送端能够知道哪些数据已被成功接收，哪些数据需要重发。如果发送端在计时器超时后仍未收到某个报文段的确认信息，则会重发该报文段。
• 接收端：接收端在收到报文段后，会检查序号是否连续。如果序号不连续，则说明有数据丢失，此时接收端会发送一个带有期望序号的确认报文段给发送端，请求重发丢失的数据。

1.4窗口大小

（1）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来进行控制，所以引入了在Tcp报头中引入16位窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力。

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

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

理解调用read、write函数的阻塞现象：

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

1.5六个标志位

TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等。

收到不同种类的报文时完美需要对应执行动作，比如正常通信的报文需要放到接收缓冲区当中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作。

也就是说不同种类的报文对应的是不同的处理逻辑，所以我们要能够区分报文的种类。而TCP就是使用报头当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真。

即标志位是用来给报文标记种类的。

（1）SYN

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

（2）ACK

• 报文当中的ACK被设置为1，表明该报文可以对收到的报文进行确认。
• 一般除了第一个请求报文没有设置ACK以外，其余报文基本都会设置ACK，因为发送回给你数据就是某种意义上的ACK，所以一般都会在ACK的同时捎带上数据，这种顺便被称为**“捎带应答”**。

（3）FIN

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

（4）URG - 紧急指针

双方在进行网络通信的时候，由于TCP是保证数据按序到达的，即便发送端将要发送的数据分成了若干个TCP报文进行发送，最终到达接收端时这些数据也都是有序的，因为TCP可以通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的。

但是有时候发送端可能发送了一些“紧急数据”，这些数据需要让对方上层优先进行读取，此时应该怎么办呢？

此时就需要将URG置1，启用Tcp报头中的16位紧急指针字段。

• 16位紧急指针代表的就是紧急数据在报文中的偏移量。
• 因为紧急指针只有一个，它只能标识数据段中的一个位置，因此紧急数据只能发送一个字节。

如何读取紧急数据？

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

如何发送紧急数据？

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

（5）PSH

当PSH被置1时，该报文会告知对方尽快将你的接收缓冲区当中的数据交付给上层。

操作系统的策略是当缓冲区当中的数据量达到一定标准时才能进行读取，当PSH被置1后，此时，就不会根据这个标准，而是催促操作系统尽快将缓冲区中的数据向上交付。

（6）RST

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

2.确认应答机制（ACK）

确认应答机制是由Tcp协议报头中的序号和确认序号实现的。

如何理解TCP将每个字节的数据都进行了编号？

TCP是面向字节流的，我们可以将TCP的发送缓冲区和接收缓冲区都想象成一个字符数组char buffer[N]，这样每一个下标对应的就是一个字节数据，而这些下标就是所谓的序号。

• 双方在通信时，本质就是将自己发送缓冲区当中的数据拷贝到对方的接收缓冲区当中。
• 发送方发送数据时报头当中所填的序号，实际就是发送的若干字节数据当中，首个字节数据在发送缓冲区buffer[N]当中对应的下标。
• 接收方接收到数据进行响应时，响应报头当中的确认序号实际就是，接收缓冲区buffer[N]中接收到的最后一个有效数据的下一个位置所对应的下标。

3.超时重传机制

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

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

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

丢包分为两种情况：

• 发送的数据报文丢失，此时发送端在一定时间内接收不到接收端的响应报文就会进行超时重传。
• 接收端的响应报文丢失，此时发送端也会因为没有接收到响应报文而进行超时重传。

所以当出现丢包时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传。

如果是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序号来判断曾经是否收到过这个报文，从而达到报文去重的目的。

需要注意的是，当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或覆盖，而会让其保留在发送缓冲区当中，以免需要进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖。

超时重传的等待时间

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

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

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

Linux中（BSD Unix和Windows也是如此），超时以 500ms 为一个单位进行控制，每次判定超时重发的超时时间都是 500ms 的整数倍。如果重发一次之后，仍然得不到应答，下一次重传的等待时间就是 2 × 500ms。如果仍然得不到应答，那么下一次重传的等待时间就是 4 × 500ms。以此类推，以指数的形式递增。

当累计到一定的重传次数后，TCP就会认为是网络或对端主机出现了异常，进而强转关闭连接。

4.连接管理机制

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

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

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

而一台机器上可能会存在大量的连接，此时操作系统就不得不对这些连接进行管理。

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

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

4.1三次握手

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

（1）三次握手的过程

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

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

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

（2）三次握手并不能保证连接成功建立

首先要明确，三次握手并不能保证100%建立好连接，因为最后一次握手不能保证其可靠性（ACK报文没有应答）。

假设最后一个ACK丢包了，那么此时服务端并不认为这个连接已经建立好了，因为服务端并没有接受到ACK报文，但是客户端已经认为这个连接建立好了，接下来客户端可能就会向服务端发送数据了，当服务端接收到数据后，会给客户端发送一个RST报文（即将报头六个标志位之一RST置1）告知客户端连接建立失败了，需要重新建立连接，即重新发起三次握手。

当然不仅有着一种情况，如果连接出现异常，RST也适用，这个标志位就是用来重置连接的标志位。

（3）为什么要三次握手才能建立一个连接？

SYN洪水攻击：客户端大量向服务器发送连接请求而不对连接做处理，而服务器也必须维护这个连接，就会导致服务器要维护很多闲置连接。

三次握手情况下，服务器建立连接成功的前提是客户端必须发送ACK给服务器，服务器才建立连接，即服务器建立连接的前提是你客户端必须先建立连接。所以三次握手的机制比之一次握手两次握手不会有太大的漏洞。

具体解释：

• 如果客户端最后发出的第三次握手丢包了，此时在服务器端就不会建立对应的连接，而在客户端就需要短暂的维护一个异常的连接。
• 而维护连接是需要时间成本和空间成本的，因此三次握手还有一个好处就是能够保证连接建立异常时，这个异常连接是挂在客户端的，而不会影响到服务器。

理由一：

需要确保信道（网络）是健康的：三次握手情况下，客户端和服务器双方都会有一次确定的收发（全双工），所以三次握手机制保证了在最小成本情况下通信双方全双工。

具体解释：

• 在客户端看来，当它收到服务器发来第二次握手时，说明自己发出的第一次握手被对方可靠的收到了，证明自己能发以及服务器能收，同时当自己收到服务器发来的第二次握手时，也就证明服务器能发以及自己能收，此时就证明自己和服务器都是能发能收的。
• 在服务器看来，当它收到客户端发来第一次握手时，证明客户端能发以及自己能收，而当它收到客户端发来的第三次握手时，说明自己发出的第二次握手被对方可靠的收到了，也就证明自己能发以及客户端能收，此时就证明自己和客户端都是能发能收的。

理由二：

需要确保双方操作系统是健康且愿意通信的：通信双方通过发送SYN报文和ACK报文来确定双方的健康情况和通信意愿。

三次握手本质上也是四次握手，只不过中间两次合并了，即捎带应答（ACK+SYN），因为通常情况下服务器不会拒绝一个客户端想要连接他，所以服务器在收到客户端SYN请求后，非常迫切的一次发给客户端两条消息，即应答ACK和连接请求SYN，这就好比餐厅通常不会拒绝客人来吃饭一样。

（4）三次握手时的状态变化

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

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

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

（5）套接字和三次握手的关系

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

4.2四次挥手

当双方TCP通信结束之后就需要断开连接，断开连接的这个过程我们称之为四次挥手。

（1）四次挥手的过程

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

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

四次挥手结束后双方的连接才算真正断开。

（2）为什么是四次挥手？

• 由于TCP是全双工的，所以在断开连接时不仅要断开从客户端到服务器方向的通信信道，也要断开从服务器到客户端的通信信道，其中每两次挥手对应就是关闭一个方向的通信信道，因此断开连接时需要进行四次挥手。
• 需要注意的是，四次挥手当中的第二次和第三次挥手不能合并在一起，因为第三次挥手是服务器端想要与客户端断开连接时发给客户端的请求，而当服务器收到客户端断开连接的请求并响应后，服务器不一定会马上发起第三次挥手，因为服务器可能还有某些数据要发送给客户端，只有当服务器端将这些数据发送完后才会向客户端发起第三次挥手。

（3）四次挥手时的状态变化

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

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

至此四次挥手结束，通信双方成功断开连接。

CLOSE_WAIT：

双方在进行四次挥手时，如果只有客户端调用了close函数，而服务器不调用close函数，此时服务器就会进入CLOSE_WAIT状态，而客户端则会进入到FIN_WAIT_2状态。

但只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源。如果服务器没有主动关闭不需要的文件描述符，此时在服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少。

因此如果不及时关闭不用的文件描述符，除了会造成文件描述符泄漏以外，可能也会导致连接资源没有完全释放，这其实也是一种内存泄漏的问题。

因此在编写网络套接字代码时，如果发现服务器端存在大量处于CLOSE_WAIT状态的连接，此时就可以检查一下是不是服务器没有及时调用close函数关闭对应的文件描述符。

TIME_WAIT：

客户端不能在收到服务端关闭的FIN报文后直接关闭连接，而要等待一段时间，进入TIME_WAIT状态。

因为如果第四次挥手的报文丢包了，客户端在一段时间内仍然能够接收服务器重发的FIN报文并对其进行响应，能够较大概率保证最后一个ACK被服务器收到。

而且客户端发出最后一次挥手时，双方历史通信的数据可能还没有发送到对方。因此客户端四次挥手后进入TIME_WAIT状态，还可以保证双方通信信道上的数据在网络中尽可能的消散。

实际第四次挥手丢包后，可能双方网络状态出现了问题，尽管客户端还没有关闭连接，也收不到服务器重发的连接断开请求，此时客户端TIME_WAIT等若干时间最终会关闭连接，而服务器经过多次超时重传后也会关闭连接。

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

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

利用如下命令查看MSL时间：

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

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

（4）套接字和四次挥手之间的关系

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

5.滑动窗口

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

但实际上我们允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，此时也就能保证这些报文被对方收到了。所以根据序号和确认序号的机制，我们可以得知哪些报文被收到了，哪些没有被收到。

但是我们可以一次向对端发送多少数据呢 ？即暂时不需要应答，可以直接发送的数据。

那我们来模拟出一个发送缓冲区来，发送缓冲区可以理解为一个字符数组，序号的表示方式就是下标，一个下标对应着一个字节的数据。在这个发送缓冲区（字符数组）中我们定义两个指针start_win、end_win，start_win左面的数据表示已发送并且已收到应答的数据（可以被覆盖），start_win与end_win之间的数据表示可以发送的数据，end_win右面表示待发送的数据。

注意：这里的指针仅指两个下标，指针的概念其实可以宽泛到唯一标识一个位置即可，没有必要非是计算机中地址的概念。

那么根据这两个指针我们将发送缓冲区划分为了三块区域，你会发现中间区域就是暂时不需要应答，可以直接发送的数据范围。而这种策略被称为滑动窗口，顾名思义，随着数据的发送应答，两个指针的位置会不断更新，最终形成一个“可滑动”的窗口。

为了更好的理解这个滑动窗口，我们根据问题进行讲解：

（1）滑动窗口的大小如何确定？

滑动窗口的大小很明显是动态更新的，滑动窗口的大小等于对方窗口大小（对端缓冲区还剩多大区域）与自身拥塞窗口（拥塞窗口的解释在下面）大小的较小值，因为发送数据时不仅要考虑对方的接收能力，还要考虑当前网络的状况。

（2）滑动窗口如何移动？

如图1001-5000的数据处在窗口内部，证明此时该部分数据可以直接进行发送。

• 当收到对方响应的确认序号为2001时，说明1001-2000这个数据段已经被对方收到了，此时该数据段应该被纳入发送缓冲区当中的第一部分，而由于我们假设对方的窗口大小一直是4000，因此滑动窗口现在可以向右移动，继续发送5001-6000的数据段，以此类推。

• 伪代码：假设收到的确认序号为x，窗口大小为winSize，所以移动的过程可以表示为start_win=x；end_win=start_win+winSize；

• 滑动窗口越大，则网络的吞吐率越高，同时也说明对方的接收能力很强。

（3）为什么不一次将滑动窗口中的数据全部发送？

如上图，我们注意到滑动窗口被分为了4个分段，这4个分段是分别发送的，那为什么将这4个分段看作一个整体一起发送呢？

实际上在链路层规定：单个数据帧所能承载的长度不能超过MTU：1500字节。

当然这部分我们会在后面的学习中详谈，这里简单有个了解就好。

（4）Tcp的超时重传机制由滑动窗口实现

我们之前讲到：处于发送缓冲区中的数据要保存一段时间，直到收到ACK证明该部分数据被接收到后才会将这部分数据覆盖掉。如何实现的呢？滑动窗口的中间区域，因为滑动窗口的左面区域是已经发送并且收到ACK的数据，处于滑动窗口中间区域的数据是可以发送但是并没有受到ACK的数据，所以只要滑动窗口不移动，这部分数据就一直存在，不会被覆盖，保证了Tcp的超时重传机制可以顺利实现。

（5）数据丢包

数据包已经抵达，ACK丢失

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

比如图中1-1000、2001-3000和3001-4000的数据包对应的ACK丢失了，但只要发送端收到了6001的确认序号报文响应，此时发送端也就知道1-1000、2001-3000和3001-4000的数据包实际上被接收端收到了的。因为如果接收方没有收到1-1000、2001-3000和3001-4000的数据包，最后的确认序号不可能被置为6001，而反而会被置为1001（最小的未被接收的数据序号）。

数据丢包

那么此时确认序号不会被置为1001后面的数据，因为确认序号的定义是告知对端我接收到了确认序号之前的数据，所以当1001-2000这部分数据丢包后，哪怕后面传来了2001-3000等数据，主机B填充确认序号也一定是按顺序填充小的部分，所以当主机A收到3次重复的确认序号的报文后，就会了解到1001后面的数据丢包了，所以此时主机A就会进行重发，这种机制被称为**“快重传”**。

而且当主机B接收到1001-2000的数据后，因为之前已经接受过连续的直到6001-7000的数据了，所以此时确认序号会填充为7001，并不会浪费之前已经发送过来的数据。

在滑动窗口中描述这个过程就是：

当窗口滑动到1001-2000这部分时，滑动窗口的左侧边界就不会继续向右移动了因为该部分的确认序号并没有接收到，所以滑动窗口会阻塞在这个位置上。

注意：滑动窗口中也可能存在有已经被接收到的数据（接收到ACK的数据），但由于滑动窗口的最左侧发生丢包，导致滑动窗口不会继续右移，当最左侧的数据重传后，滑动窗口会一下子跨越这部分已经接收过的数据。

（6）快重传与超时重传

那既然有了快重传这种机制了，为什么还要存在有超时重传呢？

很明显快重传的速度高于超时重传，其实超时重传机制是一种兜底的重传机制，快重传虽然速度快迅速判断丢包情况，但是快重传的触发是需要条件的：收到3个重复的确认序号报文。

所以，滑动窗口是非常优秀的一种实现了流量控制、重传机制等诸多功能的一种方案。

6.流量控制

TCP支持根据接收端的接收数据的能力来决定发送端发送数据的速度，其实就是控制滑动窗口的大小，这个机制叫做流量控制（Flow Control）。

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

接收方会根据自身的处理能力和接收缓冲区的大小动态调整窗口大小，并通过ACK报文将新的窗口大小通知给发送方。

• 接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端。
• 窗口大小字段越大，说明网络的吞吐量越高。
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端。
• 发送端接收到这个窗口之后，就会减慢自己发送的速度。
• 如果接收端缓冲区满了，就会将窗口值设置为0，这时发送方不再发送数据，但需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

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

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

7.拥塞控制

滑动窗口的大小不仅仅取决于对端的窗口大小，因为在数据传输过程中，我们不仅仅要考虑通信双方，还要考虑所处的网络环境，所以引入了拥塞控制的概念，拥塞控制考虑的是双方通信时网络的问题，如果发送的数据超过了某种阈值就可能会引起网络拥塞，这个阈值被称为“拥塞窗口”。

所以滑动窗口的大小=min( 接收方的接收能力（对端窗口大小），拥塞窗口大小 )。

假设发生了网络拥塞的情况，如果此时处于该网络环境中的各个主机依旧不管不顾，照常收发，那么就会导致网络环境更加糟糕。如果此时处于该网络环境中的所有主机都能遵循某一种策略控制自己的数据传输的话就能很好的避免网络环境拥塞的问题。

7.1慢启动机制

在不清楚当前网络状态的情况下，贸然发送大量的数据，就可能会引起网络拥塞问题。

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

7.2拥塞窗口

拥塞窗口的大小如何界定？

根据慢启动机制，拥塞窗口的大小一定是从1开始，后续随着对网络状态的进一步判断逐渐递增。

具体的大小控制机制：

• 当拥塞窗口的大小小于慢启动设定的阈值时（慢启动阈值初始设置为对方窗口大小的最大值），以指数级递增；

• 当拥塞窗口的大小大于慢启动设定的阈值时，按线性级递增；

• 当发生网络拥塞后（超时重传），慢启动阈值会变成当前拥塞窗口的一半，同时拥塞窗口的值被重新置为1，如此循环下去。
  
  说明：

• 指数增长。刚开始进行TCP通信时拥塞窗口的值为1，并不断按指数的方式进行增长。

• 线性增长。慢启动的阈值初始时为对方窗口大小的最大值，图中慢启动阈值的初始值为16，因此当拥塞窗口的值增大到16时就不再按指数形式增长了，而变成了的线性增长。

• 乘法减小。拥塞窗口在线性增长的过程中，在增大到24时如果发生了网络拥塞，此时慢启动的阈值将变为当前拥塞窗口的一半，也就是12，并且拥塞窗口的值被重新设置为1，所以下一次拥塞窗口由指数增长变为线性增长时拥塞窗口的值应该是12。

8.延迟应答

如果接收数据的主机收到数据后立即进行ACK应答，此时返回的窗口可能比较小，引入延迟应答的目的就是为了能够通告给对端一个更大的窗口大小。

• 假设对方接收端缓冲区剩余空间大小为1M，对方一次收到500K的数据后，如果立即进行ACK应答，此时返回的窗口就是500K。
• 但实际接收端处理数据的速度很快，10ms之内就将接收缓冲区中500K的数据消费掉了。
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来。
• 如果接收端稍微等一会再进行ACK应答，比如等待200ms再应答，那么这时返回的窗口大小就是1M。

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

此外，不是所有的数据包都可以延迟应答。

• 数量限制：每N个包就应答一次。
• 时间限制：超过最大延迟时间就应答一次（需要注意的是：这个时间设置不应该导致超时重传）。

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

9.捎带应答

捎带应答就是将ACK和数据进行整合一起发送回给对端，这样可以节省一次发送，当然我认为捎带应答不仅仅针对数据和ACK进行整合，最典型的例子就是三次握手的ACK+SYN，我认为这也是某种意义上的捎带。

举例说明：

• 主机A给主机B发送了一条消息，当主机B收到这条消息后需要对其进行ACK应答。
• 但如果主机B此时正好也要给主机A发生消息，此时这个ACK就可以捎带着发送过去，而不用单独发送一个ACK应答。
• 此时主机B发送的这个报文既发送了数据，又完成了对收到数据的响应，这就叫做捎带应答。

10.面向字节流

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

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

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

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

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

11.粘包问题

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

在TCP的协议头中，没有如同UDP一样的“报文长度”这样的字段。

站在传输层的角度，TCP是一个一个报文过来的，按照序号排好序放在缓冲区中。但站在应用层的角度，看到的只是一串连续的字节数据。

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

所以我们需要解决粘包问题。

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

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

UDP是否存在粘包问题？

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

12.TCP异常情况

12.1进程终止

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

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

12.2机器重启

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

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

12.3机器掉电/网线断开

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

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

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

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

---

生活的真谛不是等待风暴过去，而是学会如何在雨中起舞。 —薇薇安·格林
进程退出时，该进程曾经打开的文件描述符都会自动关闭，因此当客户端进程退出时，相当于自动调用了close函数关闭了对应的文件描述符，此时双方操作系统在底层会正常完成四次挥手，然后释放对应的连接资源。也就是说，进程终止时会释放文件描述符，TCP底层仍然可以发送FIN，和进程正常退出没有区别。

12.2机器重启

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

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

12.3机器掉电/网线断开

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

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

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

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

---

生活的真谛不是等待风暴过去，而是学会如何在雨中起舞。 —薇薇安·格林