运输层之 运输连接管理

每篇一句：自以为历经沧桑，其实刚刚蹒跚学步；自以为悟出了生存竞争的秘密，其实还远没有竞争的资格。  ——《三体 III ：死神永生》

运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。运输连接有三个阶段，即：连接建立. 数据传送 和 连接释放

TCP 的连接采用客户服务器方式。主动发起连接建立的应用进程叫做 客户，而被动等连接建立的应用进程叫做 服务器。

 

TCP 的连接建立

TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 个报文段。下图是 三报文握手 建立 TCP 连接的过程。

假定主机 A 运行 TCP 客户程序，主机 B 运行 TCP 服务器程序。最初两端的 TCP 进程都处于 COLSED ( 关闭 ) 状态。

一开始，B 的 TCP 服务器进程先创建 传输控制块 TCB ( 存储了每一个连接中的重要信息，如TCP 连接表，指向发送和接收缓存的指针等等 ) ，准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN ( 收听 ) 状态，等待客户的连接请求。

A 的 TCP 客户进程也是首先创建 传输控制模块 TCB。然后，在打算建立 TCP 连接时，向 B 发送连接请求报文段，这时首部中的同步位 SYN = 1，同时选择一个初始序号 seq = x ( SYN = 1 的报文段不能携带数据，但 会消耗一个序号)。这时，TCP 客户进程进入 SYN-SENT ( 同步已发送 ) 状态。

B 收到连接请求报文段后，如同意则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位置为 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。这个报文段也不能携带数据，但 同样要消耗一个序号。这时服务器进程进入 SYN-RVCD ( 同步收到 ) 状态。

TCP 客户进程收到 B 确认后，还要向 B 给出确认。确认报文段的 ACK 置为 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。ACK 报文段可以携带数据，但 如果不携带数据则不消耗序号。在这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，连接已建立，A 进入 ESTABLISHED ( 已建立连接 ) 状态。

当 B 收到 A 的确认后，也进入 ESTBLISHED 状态。

上面的连接建立过程叫做 三报文握手 ( 三次握手 )。 B 发送给 A 的报文段，也开拆分成两个报文段。可以先发送一个确认报文段 ( ACK = 1, ack = x + 1)， 然后在发送一个同步报文段 (SYN = 1, seq = y)。这样就变成了 四报文握手。但效果一样。

至于 A 最后还要发送一次确认，是为了防止已失效的连接请求报文段突然又传送到了 B，因而产生错误。

所谓的 “已失效的连接请求报文段“是这样产生的。一种正常情况是，A 发出连接请求，但因连接请求报文段丢失而未收到确认。于是 A 重新发送了一次连接请求。后来收到了确认，建立了连接。数据传输完后，就释放了连接。A 共发送了两个两个连接请求报文段，其中第一个丢失，第二个到达了 B，没有 “已失效的连接请求报文段”。

如果 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点滞留了，以致延误到连接释放后的某个时间才到达 B。B 收到后误以为这是 A 又一次发出新的连接请求。于是向 A 发出确认报文段，同意建立连接。
假定不采用报文握手，这样新的连接就建立了，但是 A 并没有发出建立建立连接的请求，并不会理睬 B 的确认，也不会发送数据。但 B 确一直等待 A 发送数据，就会浪费大量资源。

 

TCP 的连接释放

数据传输结束后，通信的双方都可释放连接。如图 5-29，现在 A 和 B 都处于 ESTBLISHED 状态。

A 的应用进程先向其 TCP 发出连接释放报文段，并停止发送数据，主动关闭 TCP 连接。连接释放报文段首部的终止控制位 FIN 置为 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1 ( 终止等待1 ) 状态，等待 B 的确认。FIN 报文段 即使不携带数据，也要消耗一个序号

B 收到连接 释放报文段后即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v，等于 B 前面已传送过的数据的最后一个字节的序号加 1。然后 B 就进入了 CLOSED-WAIT ( 关闭等待 ) 状态。从 A 到 B 这个方向的连接就释放了，这时 TCP 的连接处于半关闭状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，B 到 A 这个方向的连接并未关闭。

A 收到 B 的确认后，就进入 FIN-WAIT-2 ( 终止等待2 ) 状态，等待 B 发出的连接释放报文段。

若 B 没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。现假定 B 的序号为 w ( 在半关闭状态下可能又发送了些数据 )。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入了 LAST-ACK ( 最后确认 ) 状态，等待 A 的确认。

A 在收到 B 的连接释放报文段后，必须对此发出确认。在确认报文段中把 ACK 置为 1，确认号 ack = w + 1，而自己的序好是 seq = u + 1。然后进入到 TIME-WAIT ( 时间等待 ) 状态。再经过时间等待计时器 ( TIME-WAIT timer) 设置的时间 2MSL ( MSL：最长报文段寿命 ) 后，A 才进入到 CLOSED 状态。

A 在 TIME-WAIT 状态必须等待 2MSL 的时间有两个理由：

• 为保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段可能丢失，使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认。B 会超时重传这个 FIN + ACK 报文段，而 A 在 2MSL 时间内收到这个重传的 FIN + ACK 报文段。接着 A 重传了一次，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。
• 防止 “已失效的连接请求报文段” 出现在连接中。A 在发送完最后一个 ACK 报文段后，再经过 2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失。

上述的 TCP 连接释放过程是 四报文握手 ( 四次握手 )

TCP 还设有一个 保活计时器。如果客户端发生故障，服务器就不能收到客户发来的数据。服务器使用保活计时器，每收到一次客户的数据，就重新设置保活计时器，时间设置通常为 2 小时。若两小时内没有收到客户的数据，服务器就发送一个探测报文段，每隔 75 秒发送一次。若一连 10 次都没有响应，服务器就认为客户端出现故障，关闭这个连接。

 

TCP 的有限状态机

为理解 TCP 连接的各种状态之间的关系。下图给出了TCP 的有机状态机。

图中的三种箭头：

• 粗实线箭头：客户进程的正常变迁
• 粗虚线箭头：服务器进程的正常变迁
• 细线箭头：异常变迁

写在最后

如果有任何问题或建议，欢迎交流学习。