51CTO：Linux C++网络编程三

概述

1. TCP是一种面向连接的协议，提供了可靠、有序和错误检测机制的字节流服务
2. 与无连接的UDP协议相比，TCP强调数据完整性和可靠性

特点

1. 可靠性
   1. TCP确保所有数据包按顺序到达，如果丢失或出错，它们将被重新传输
2. 面向连接
   1. 在数据交换之前，通信双方必须建立连接
3. 全双工
   1. 一旦连接建立，数据可以在两个方向上同时流动
4. 流控制
   1. 通过窗口机制，发送方可以根据接收方的处理能力来调整数据的发送速率
5. 拥塞控制
   1. 当网络拥堵时，TCP会动态地减少数据传输速率

三次握手

SYN

1. 客户端发送一个SYN（同步）包到服务器，请求连接

SYN-ACK

1. 服务器响应SYN包，并向客户端发送ACK（确认）和自己的SYN

ACK

1. 客户端再次发送ACK，确认连接

细节

1. 第一次：
   1. 客户端希望与服务器建立连接时，会发送一个TCP包。
      这个包的标志位中SYN标志设置为1，序列号为随机产生的值x
   2. 收到这个包后，服务器知道客户端希望建立一个连接
2. 第二次：
   1. 在收到客户端的SYN包后，服务器必须确认这个请求
      服务器向客户端发送另一个TCP包，其中SYN和ACK标志位都设置为1
      这个包的序列号也是随机的，设为y，确认号为x+1，确认客户端的序列号加1的值
   2. 收到这个包后，客户端知道服务器已准备好建立连接
3. 第三次：
   1. 客户端向服务器发送第三个包来确认连接的建立
      这个包中ACK标志位为1，序列号为x+1，确认号为y+1
   2. 收到这个包后，服务器知道客户端已经准备好通信

图示

为什么需要三次握手

1. 三次握手的主要目的是确保双方主机都准备好建立连接
   并确定各自的初始序列号，从而确保数据传输的可靠性和顺序
2. 同步序列号：
   1. 通过三次握手，客户端和服务器可以互相通知对方的初始序列号
   2. 序列号是TCP用来识别数据字节顺序的方式，因此它们必须被双方明确同步
3. 双向通信：
   1. 当三次握手完成时，客户端和服务器都确认了对方的准备就绪，这样就可以在双方之间建立双向通信
4. 避免旧连接初始化：
   1. 有时，由于网络延迟等原因，旧的连接请求可能会迟到，达到服务器后可能被误解释为新的连接请求
   2. 通过三次握手，服务器可以识别并丢弃这些陈旧的连接请求，防止不必要的错误连接
5. 资源分配：
   1. 通过三次握手，服务器能确保客户端真实存在并准备好进行通信，这样服务器才分配必要的资源来维护这个连接
   2. 如果没有这样的过程，一个恶意客户端就能通过发送伪造的连接请求耗尽服务器的资源
6. 参数协商：
   1. 三次握手还允许客户端和服务器在连接建立过程中协商某些参数，例如窗口大小等

四次挥手

1. 当连接关闭时，需要四次挥手

FIN

1. 主动关闭方发送FIN包，表示完成发送

ACK

​ 1. 被动关闭方确认收到FIN

FIN

1. 被动关闭方发送自己的FIN

ACK

1. 主动关闭方再次发送ACK

细节

1. 第一次：
   1. 当一个端点（例如客户端）决定关闭连接时，它会发送一个FIN（完成）标志的TCP段
      这个FIN标志表示该端点已经完成了发送，没有更多的数据要传输
2. 第二次：
   1. 当接收到FIN段时，对方（例如服务器）会发送一个ACK（确认）标志的TCP段来确认收到了FIN段
   2. 此时，连接处于半关闭状态，因为虽然主动关闭方已经停止发送数据，被动关闭方仍然可以继续发送
3. 第三次：
   1. 当被动关闭方也完成了数据发送，它会发送另一个FIN标志的TCP段，表示它也完成了数据传输，并准备关闭连接
4. 第四次：
   1. 主动关闭方会回复一个ACK标志的TCP段，确认它已经收到了FIN段
   2. 在这一步完成后，连接被彻底关闭

TIME_WAIT状态

1. 值得注意的是，在最后一个ACK发送后，主动关闭方通常会进入一个称为TIME_WAIT的状态，持续一段时间（通常是2倍的最大段生存时间，MSL）
2. 这个等待时间确保了最后一个ACK确实被对方收到，如果没有收到，对方会重新发送FIN段

为什么需要四次挥手

1. 全双工通信：
   1. TCP是全双工协议，这意味着在一个TCP连接中，数据可以在两个方向上同时传输
   2. 因此，每个方向的连接都需要单独关闭。所以双方都必须发送一个FIN标志来关闭各自的方向，以及发送一个ACK来确认对方的FIN
2. 可靠数据传输：
   1. 通过使用四次挥手，TCP确保了在关闭连接之前，双方都完成了所有未完成的数据传输
   2. 例如，当一个方向的连接关闭后，另一方向仍然可以继续发送数据，直到也准备好关闭
3. 避免旧连接的重启：
   1. 通过在最后一个ACK发送后的时间等待（TIME_WAIT）阶段，TCP确保了最后一个确认已被接收，并且旧的重复段不会与新的连接混淆
   2. 这防止了潜在的连接混乱和数据错误
4. 防止数据丢失：
   1. 既然两个方向的连接是分别关闭的，其中一个方向的FIN并不意味着双方都不再发送数据
   2. 因此，需要四次挥手来确保双方都有机会完成其剩余的数据传输

详解TIME_WAIT状态

1. 当TCP连接的一方A完成它的数据发送并接收到对方B的FIN（表明对方B已经完成了数据发送）并发送了确认的ACK后，A会进入TIME_WAIT状态
   1. 换句话说，TIME_WAIT出现在关闭连接的四次挥手过程的最后阶段
2. TIME_WAIT状态通常持续两倍的最大段生存时间（MSL, Maximum Segment Lifetime）。在大多数系统中，MSL为2分钟，因此TIME_WAIT通常持续4分钟
3. 有这个状态的目的：
   1. TIME_WAIT状态确保关闭连接的另一端B收到了A对其FIN段的确认ACK。如果B没有收到此ACK，B会重新发送FIN段，A在TIME_WAIT状态下可以继续确认
   2. TIME_WAIT也保证了在连接关闭后，来自该连接的旧重复段在网络中已经消失。这确保了之后建立的新连接不会受到旧连接的影响，这对于使用相同的源和目的IP/端口对的新连接尤其重要
   3. 在高连接速率的服务器上，大量的TIME_WAIT状态可能导致端口资源的短时耗尽。
      这是因为每个<源IP, 源端口, 目标IP, 目标端口>组合需要在TIME_WAIT时间窗口内保持唯一性
      解决这个问题的方法之一是在需要的时候启用SO_REUSEADDR套接字选项
   4. 加入当一个TCP连接收到FIN并发送ACK后，立即关闭并释放资源？
      如果最后一个ACK丢失，那么关闭连接的另一端将重新发送FIN，这将在新的连接中产生一个未经请求的FIN，导致错误

流控制

概述

1. TCP的流控制（Flow Control）是一种确保数据在发送和接收方之间高效传输的机制
2. 流控制有助于防止快速发送方压倒慢速接收方，造成网络拥塞和数据丢失

详解

1. 滑动窗口机制：
   1. 发送窗口: 发送方使用一个窗口来控制其一次可以发送多少数据。
      这个窗口大小取决于接收方的窗口大小和网络拥塞
   2. 接收窗口: 接收方的接收窗口大小告诉发送方它一次可以接收多少数据
      窗口太小，效率低
      窗口太大，可能超出接收方的处理能力，导致数据丢失
2. 窗口调整：
   1. 接收方可以通过在ACK中携带的窗口大小字段来动态地通知发送方其可用的窗口大小
   2. 如果接收方的缓冲区被填满，它可以通知发送方减小窗口，甚至将窗口设置为零，停止发送
3. 丢包和超时的影响：
   1. 发送方需要等待对其发送的每个段的确认
   2. 如果确认超时或丢失，发送方可能需要减小窗口大小，并重新传输未确认的段
4. 慢开始和拥塞避免：
   1. 接收方的流控制，TCP还实现了拥塞控制，它与网络中的其他流量和路由器缓冲区的可用空间有关
   2. 慢开始和拥塞避免算法共同工作，逐渐增加发送窗口大小，直到找到网络当前能够承受的最佳速率
5. 持续计时器：
   1. 如果接收方窗口变为零，它可能会在稍后的时间点打开
   2. 持续计时器定期提示发送方查询接收方的窗口大小。如果窗口打开，则继续发送；否则，继续等待
6. Silly Window Syndrome（SWS）的防止：
   1. SWS是指接收方频繁通知发送方有一个很小的窗口可用，例如一个字节
   2. 为了防止这种低效的情况，接收方通常会等待有足够的空间可用后再通知发送方

拥塞控制

简述

1. TCP的拥塞控制是一组算法，用来确保TCP的稳定和高效运行
2. 当网络中的某个部分变得拥堵时，TCP的拥塞控制算法可以防止部分或整个网络被淹没，并有助于实现更公平的带宽分配

慢启动

1. TCP连接开始时，拥塞窗口（cwnd）设置为一个较小的值，然后每确认一个段（ACK），拥塞窗口就增加一个段的大小，成指数增长
2. 慢开始的目的是让TCP连接不会突然发送大量的数据，导致网络拥塞

拥塞避免

1. 一旦达到阈值（ssthresh），增长速率从指数变为线性
2. 每经过一个RTT（往返时延），窗口大小增加一个段。这样的增长方式会缓慢逼近网络的实际容量

快速重传

1. 当接收方连续三次重复确认相同的数据段（三个重复ACK），发送方就会假定该段后的第一个数据段丢失，并立即重新传输那个丢失的段

快速恢复

1. 与快速重传一起工作，使连接能够在重新传输丢失的段后快速恢复到拥塞避免阶段，而不是回到慢开始阶段

拥塞窗口减少

1. 如果接收方超时未确认段（Timeout），或者接收到三个重复ACK，发送方就会减小拥塞窗口大小
2. 此时通常会设置ssthresh为当前cwnd的一半，并将cwnd重置为1，回到慢开始阶段

拥塞通知

1. 如果网络设备检测到拥塞，可以在IP包头中设置ECN位，以通知接收方和发送方网络出现拥塞，从而降低发送速率

其他控制算法

1. 除了基本的拥塞控制算法，还有一些其他的拥塞控制算法，如TCP Reno, TCP Vegas, BBR等，各有不同的特性和适用场景

错误检测

概述

1. TCP通过序列号和确认机制确保数据的可靠传输
2. 失序、丢失或错误的数据将被重新传输

校验和

1. TCP头和数据都包括一个校验和字段，用于检测数据是否在传输过程中被损坏
2. 发送方会计算TCP头和数据的校验和，并将其放在TCP段的校验和字段中
3. 接收方收到TCP段后，也会计算校验和
   1. 如果计算出的校验和与段中的校验和字段不匹配，则该段被认为是错误的，并被丢弃

序号

1. 每个TCP段都包括一个序号，表示该段中的第一个字节的序号
2. 通过序号，接收方可以确定接收到的段的顺序
   1. 如果某个段丢失，也可以通过期望的序号和接收到的序号来检测

确认

1. 接收方通过发送带有ACK标志的段来确认已接收的数据
   1. 确认号表示接收方期望收到的下一个字节的序号
2. 如果发送方未收到确认，则可以假定数据段已丢失，并重新发送

重传超时

1. 如果发送方在一段时间内未收到特定段的确认，则会重新发送该段
   1. 这个超时时间可能是动态计算的，基于之前的往返时间（RTT）

流控制

1. 通过使用滑动窗口机制，接收方可以控制发送方的发送速率，确保其不会超过自己的处理能力
2. 如果窗口大小为零，发送方将停止发送，等待窗口大小增加

快速重传

1. 如果接收方连续三次收到相同序号的段，它会立即发送确认
2. 发送方可以侦测到这三个重复确认，并立即重新发送丢失的段，而不是等待超时

拥塞控制

1. 这不仅是错误恢复机制，还是防止错误发生的机制
   1. 通过控制数据在网络中的流量，拥塞控制有助于防止网络拥堵，从而防止丢包

关闭连接

1. TCP提供了一种四次挥手的机制来关闭连接，确保双方都能完成数据传输

选项字段

1. TCP头部的选项字段可以用于各种可选的错误检测和恢复功能，例如SACK（选择性确认）

TCP段

概述

1. TCP数据被封装成“段”，每个段都有一个包头，包括源和目标端口、序列号、确认号、窗口大小等

TCP头部

1. 源端口（Source Port）和目的端口（Destination Port）: 每个字段都占16位，用于标识源和目的进程
2. 序列号（Sequence Number）: 32位字段，表示本段数据的第一个字节在整个字节流中的序号
3. 确认号（Acknowledgment Number）: 32位字段，表示接收方期望收到的下一个字节的序号
4. 数据偏移（Data Offset）: 4位字段，表示TCP头部的长度。因为头部长度可变，所以这个字段是必需的
5. 保留（Reserved）: 3位保留字段，必须设为零
6. 控制标志（Control Flags）: 9位字段，包括URG, ACK, PSH, RST, SYN, FIN等标志，用于控制TCP的特定功能
7. 窗口大小（Window Size）: 16位字段，用于流控制，表示接收方可接受的字节数
8. 校验和（Checksum）: 16位字段，用于错误检测
9. 紧急指针（Urgent Pointer）: 16位字段，与URG标志一起使用，指示紧急数据的位置
10. 选项（Options）: 可选字段，长度可变，用于某些可选功能，如最大段大小（MSS）、窗口缩放、时间戳等

数据部分

1. 数据部分包含了应用程序传输的实际数据
   1. 其长度可以为零（例如，纯ACK段）或者最多可达到16位的最大值，减去头部的长度

状态

图示

概述

1. TCP的状态指的是对应套接字（socket）的状态

   1. 在Linux系统中，每个TCP套接字的状态保存在内核的数据结构中
   2. 特别是在sock和inet_sock结构中。这些结构为每个套接字提供了基本的和特定于网络协议的信息

2. TCP连接在其生命周期中会经历多个状态，包括

3. LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, CLOSED等

LISTEN

1. LISTEN是TCP连接建立过程中的一个状态。在服务器端，一个进程通常首先绑定到一个特定的地址和端口，然后开始在这个端口上监听客户端的连接请求。当进程处于这个监听状态时，该进程的套接字处于LISTEN状态

SYN-SENT

1. 当一个TCP连接的主动方（即客户端）想要与另一台机器上的服务端建立连接时，它会发送一个包含SYN（Synchronize）标志位的TCP段，并进入SYN-SENT状态
2. 含义：
   1. 客户端发送了一个SYN标志位，并在此标志位中提供了其初始序列号
   2. 一旦进入SYN-SENT状态，客户端就等待服务端响应。服务端的响应应该是一个包含SYN和ACK标志位的TCP段
3. 可能的状态转换：
   1. 如果客户端收到一个包含SYN和ACK标志位的段（并且ACK确认了客户端的SYN），客户端会发送一个ACK确认段给服务端，并进入ESTABLISHED状态，此时连接建立完成
   2. 如果在特定的超时时间内没有收到服务端的响应，客户端可能会重新发送SYN段，或者放弃连接尝试，并将套接字置为关闭状态
   3. 如果收到一个包含RST（Reset）标志的段，表示服务端拒绝了连接。客户端将退出SYN-SENT状态，并将套接字置为关闭状态
   4. 在SYN-SENT状态中，应用程序还可以选择取消连接尝试

SYN-RECEIVED

1. 在三次握手的过程中，当服务器收到来自客户端的第一个SYN（同步）报文段，并向客户端发送了SYN和ACK（确认）报文段后，就会进入这个状态
   1. SYN-RECEIVED状态在服务器端是一个临时状态，它代表服务器已经同意了连接请求，并且已经发送了确认
   2. 这个状态下，服务器正在等待客户端的最后一个ACK报文段来完成握手过程
2. 在SYN-RECEIVED状态下，如果服务器没有收到来自客户端的ACK报文段，可能会有以下几种情况：
   1. 服务器可能会重新发送SYN+ACK报文段，直到收到客户端的ACK报文段或达到重试次数限制
   2. 如果超过了一定的重试次数，服务器可能会关闭连接，并返回到LISTEN状态

ESTABLISHED

1. 当三次握手成功完成后，连接的双方都会进入ESTABLISHED状态。
   1. 在客户端，它会在发送最后一个ACK确认段后进入该状态
   2. 在服务端，它会在收到这个ACK段后进入该状态
2. 含义：
   1. 双方都准备好发送和接收数据。数据可以在两个方向上无阻碍地流动
   2. TCP确保数据的可靠传输，它会检测丢失的数据段并重新传输它们，并确保数据段的正确顺序
   3. 在ESTABLISHED状态下，TCP会实施流量控制，以确保发送方不会淹没接收方的缓冲区
   4. TCP还会监视网络的拥塞情况，并相应地调整其传输速度
3. 可能的状态转换：
   1. 任何一方都可以开始正常的连接终止过程
   2. 如果在数据传输期间出现问题（例如，连接丢失或另一方崩溃），TCP将尝试恢复连接或终止它
   3. 如果连接在很长时间内没有活动，某些操作系统可能会选择自动关闭它

FIN-WAIT-1

1. TCP（传输控制协议）连接在终止过程中会经过一系列的状态，其中FIN-WAIT-1状态是其中的一个
2. 四次挥手：
   1. TCP连接的终止通常是通过所谓的“四次挥手”过程完成的
   2. 在这个过程中，连接的两端（通常被称为“客户端”和“服务器”）都发送和接收FIN（结束）和ACK（确认）报文来协商连接的关闭
3. FIN-WAIT-1状态通常是TCP连接关闭过程的第一步
   1. 当一个TCP连接中的一方想要关闭连接时，它会发送一个FIN报文，并进入FIN-WAIT-1状态
   2. 在FIN-WAIT-1状态中，该端点等待远程端点对其发送的FIN报文的确认。远程端点收到FIN报文后，会发送一个ACK报文来确认
4. 可能的状态转换：
   1. 如果收到了FIN报文的ACK确认，则转移到FIN-WAIT-2状态，等待远程端点的FIN报文
   2. 如果同时收到了FIN报文和ACK确认，则可以直接转移到TIME-WAIT状态
5. 注意事项：
   1. 在FIN-WAIT-1状态中，TCP端点仍然可以接收数据，但不能再发送新的数据
   2. FIN-WAIT-1状态的持续时间可能因网络延迟和其他因素而有所不同

FIN-WAIT-2

1. 第一次挥手：
   1. 主动关闭连接的一方（我们称为A端）发送一个FIN标志的数据包，请求关闭连接。此时，A端进入FIN-WAIT-1状态
2. 第二次挥手：
   1. 被动关闭连接的一方（称为B端）收到FIN请求后，返回ACK标志的数据包作为确认，并可能发送自己的FIN数据包关闭自己到A端的连接
   2. 如果B端立即确认关闭，A端收到这个ACK后A端进入FIN-WAIT-2状态。如果B端还有未发送的数据，可能会继续发送，并稍后才关闭连接
3. 第三次挥手：
   1. A端等待B端的FIN数据包，此时A端已经进入了FIN-WAIT-2状态。所以A端将不再发送数据，但仍然接收数据直到B端关闭其连接
4. 第四次挥手：
   1. 一旦A端收到B端的FIN数据包，它将发送最后的ACK确认，并进入TIME-WAIT状态
   2. 在等待一段时间后（通常是2倍的MSL，最大报文生存时间），A端将关闭连接，以确保最后的ACK被B端接收
5. 注意：
   1. 在某些情况下，FIN-WAIT-2状态可能会持续较长时间，特别是当B端持续发送数据或延迟关闭连接时
      1. 因为TCP协议没有规定FIN-WAIT-2状态的超时机制，所以理论上，A端可能会一直停留在这个状态，直到B端发送FIN请求
   2. 如果A端在FIN-WAIT-2状态下崩溃或重启，那么与B端的连接可能永远不会正常关闭，从而可能造成资源泄漏等问题

CLOSING

1. CLOSING状态表示连接正在终止，但尚未完全关闭。它是一个相对罕见的状态，只有在特定的关闭情况下才会出现
2. 进入这个状态的情况：
   1. 主机A发送FIN报文，进入FIN-WAIT-1状态
   2. 主机B几乎同时也发送FIN报文，但尚未收到主机A的FIN报文
   3. 主机A收到主机B的FIN报文，但主机B尚未收到主机A的FIN报文的确认（ACK）
   4. 主机A发送FIN的ACK，进入CLOSING状态
3. 状态转移：
   1. 此时，双方都在等待对方的FIN报文的确认
   2. 一旦双方都收到对方的FIN报文的确认，连接就可以转移到TIME-WAIT状态，最终关闭
4. 重要性：
   1. CLOSING状态虽然罕见，但它体现了TCP协议设计的健壮性。即使在双方几乎同时关闭连接的情况下，TCP协议也能确保可靠的关闭连接

TIME-WAIT

1. 当TCP连接被关闭时，双方都会发送和接收FIN（结束）标志
   1. 假设一方（主动关闭方，或“客户端”）发送了最后一个ACK（确认）标志，那么它会进入TIME-WAIT状态
2. TIME-WAIT目的：
   1. 在TIME-WAIT状态中，客户端会等待一段时间以确保最后一个ACK被对方（被动关闭方，或“服务器”）正确接收
      如果服务器没有收到这个ACK，它会重新发送FIN，客户端在TIME-WAIT状态下就能再次回应ACK
   2. 通过等待一段时间，客户端可以确保网络中的任何延迟数据包都在连接重新使用之前消失
      这有助于防止下一个使用相同套接字地址的连接误收到这些旧数据包
3. TIME-WAIT时长：
   1. TIME-WAIT状态通常持续2个MSL（最大段生存时间）
      1. 在许多系统中，这相当于1到4分钟。MSL定义了数据包在网络中的最大生存时间
4. TIME-WAIT与端口耗尽：
   1. 由于TIME-WAIT状态持续的时间较长，所以在高负载的系统中，大量的套接字可能会卡在TIME-WAIT状态
   2. 这可能会导致端口耗尽，因为新的连接可能无法使用已被占用的套接字地址
   3. 某些系统提供了用于控制TIME-WAIT状态行为的内核参数或套接字选项，以便在这种情况下进行调整

CLOSE-WAIT

1. 当一方（假设是客户端）完成数据传输并决定关闭连接时，它会发送一个 FIN (结束) 标志给另一方（假设是服务器）
2. 服务器收到这个 FIN 消息后，首先发送一个 ACK (确认) 来确认已经收到 FIN
   1. 此时，从服务器的角度来看，服务器的 TCP 连接状态就会变成 CLOSE-WAIT
3. 在 CLOSE-WAIT 状态，服务器等待应用程序关闭其端的连接
   1. 也就是说，底层的 TCP 栈已经知道了连接应该被关闭，但是它正在等待上层的应用程序（例如，HTTP 服务器）来决定何时实际地关闭它

LAST-ACK

1. 进入LAST-ACK过程：
   1. 当一个TCP连接的一方想要关闭连接时，它会发送一个FIN标志的TCP段，请求关闭连接
   2. 被动关闭端（另一方）收到FIN后，会发送一个ACK表示已收到，并发送一个自己的FIN请求关闭连接
   3. 主动关闭端收到对方的ACK和FIN后，会进入LAST-ACK状态，并发送一个最终的ACK表示同意关闭连接
2. LAST-ACK状态行为：
   1. 在LAST-ACK状态中，主动关闭端等待对方确认自己的最后一个ACK
   2. 此时，连接的终止正在进行中，但还没有完全完成。主动关闭端无法发送更多的数据，只能接收
3. 退出LAST-ACK状态：
   1. 当主动关闭端收到对方对自己最后一个ACK的确认后，它将退出LAST-ACK状态并进入CLOSED状态
   2. 此时，TCP连接被成功终止，资源被释放

CLOSED

1. 在TCP协议中，CLOSED状态表示连接完全关闭的状态

   1. 这是TCP连接的初始和最终状态

2. 进入CLOSED状态的方式：

   1. 刚创建的套接字处于CLOSED状态，直到应用程序调用了连接或监听操作
   2. 一方可以通过调用close或shutdown系统调用来关闭连接
      这将触发四次挥手的过程。在完成所有必要的终止步骤后，连接将进入CLOSED状态
   3. 如果一方接收到另一方的关闭请求（即FIN标志），它也会进入关闭连接的过程，并最终进入CLOSED状态
   4. 连接也可能由于错误或超时而被关闭
      例如，如果在建立连接的过程中出现超时或错误，连接可能会直接进入CLOSED状态

3. CLOSED状态的行为：

   1. 在此状态下，端点不接受任何传入的连接请求
   2. 应用程序可以通过调用特定的系统调用来开始连接或监听过程，从而使端点离开CLOSED状态
   3. 尝试在CLOSED状态下发送数据会导致错误

4. CLOSED的状态转移：

   1. 如果端点想要接受新的连接请求，它必须从CLOSED状态转到LISTEN状态
   2. 如果端点想要主动建立新的连接，它必须从CLOSED状态转到SYN-SENT状态