TCP的运输连接管理
TCP的运输连接管理
TCP 是面向连接的协议，运输连接是用来传送 TCP 报文的。TCP 运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在TCP连接建立过程中要解决以下三个问题:
- 要使每一方能够确知对方的存在。
- 要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)。
- 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
三次握手：建立连接
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的 TCP 进程都处 CLOSED(关闭)状态。
- A主动打开连接，而B被动打开连接。
- B的TCP服务器进程创建传输控制块TCB，准备接受客户进程的连接请求，进入监听(Listen)状态。
- A的TCP客户端进程创建传输控制块TCB。
- A向B请求建立连接时，发出连接请求报文段，首部中同步位 SYN=1，选择初始序号 seq=x。TCP客户进程进入SYN-SENT(同步已发送)状态。
- B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中携带 SYN=1，ACK=1，ack=x+1，seq=y。服务器进程进入SYN-RCVD(同步收到)状态。
- TCP客户进程收到B的确认后，向B发出确认。携带 ACK=1，ack=y+1，seq=x+1。TCP连接已经建立，A 进入 ESTABLISHED (已建立连接)状态。
- 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。
SYN报文段不能携带数据，但要消耗一个序号。
确认报文段也不能携带数据，但同样要消耗掉一个序号。也可以把SYN=1，ACK=1拆成两个报文段，这样变成四报文握手，效果一样。
ACK报文段可以携带数据。但如果不携带数据则不消耗序号。
1 | Q：为什么 A 最后还要发送一次确认呢? |
“已失效的连接请求报文段”是指，在 A 发出连接请求后，因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求，并且收到了确认，建立了连接。数据传输完毕后，就释放了连接。
A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B，没有“已失效的连接请求报文段”。
现假定出现一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。
这是一个早已失效的报文段，但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。假定不采用三报文握手，那么只要 B 发出确认，新的连接就建立了。
由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向B发送数据。但 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
采用三报文握手的办法，可以防止上述现象的发生。例如在刚才的异常情况下，A 不会向 B 的确认发出确认。B 由于收不到确认，就知道 A 并没有要求建立连接。
四次分手：断了联系
数据传输结束后，通信的双方都可释放连接。
- A 和 B 都处于 ESTABLISHED 状态。
- A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。连接释放报文段首部终止控制位 FIN=1，seq=u，它等于前面已传送过的数据的最后一个字节的序号加 1。A进入 FIN-WAIT-1(终止等待1) 状态，等待 B 的确认。
- B 收到连接释放报文段后即发出确认，确认号是 ack=u+1，而这个报文段自己的序号是 v，等于 B 前面已传送过的数据的最后一个字节的序号加 1。
- 进入 CLOSE-WAIT(关闭等待) 状态。
- TCP 服务器进程通知高层应用进程，此时从 A 到 B 这个方向的连接已释放，TCP连接处于 半关闭(half-close) 状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。
- A 收到 B 的确认后，进入 FIN-WAIT-2(终止等待2) 状态，等待 B 发出的连接释放报文段。
- 若 B 已经没有要向A发送的数据，其应用进程就通知 TCP 释放连接。
- B 发出的连接释放报文段 FIN=1，seq=w (半关闭状态下 B 可能又发送了一些数据)。
- B 还必须重复上次已发送过的确认号 ack=u+1。B进入 LAST-ACK(最后确认) 状态，等待A的确认。
- A 收到 B 的连接释放报文段后，对此发出确认。
- 在确认报文段中，ACK=1，ack=w+1，seq=u+1，然后进入 TIME-WAIT(时间等待) 状态。
- 此时 TCP连接还没有释放掉，必须经过 2MSL 后，A才进入到 CLOSED状态。
- MSL叫做最长报文段寿命(Maximum Segment Lifetime)，RFC793建议设为2分钟。但 TCP 允许不同实现自定义。因此，从A进入到 TIME-WAIT状态后，要经过
2MSL才能进入到 CLOSED状态，才能开始建立下一个新的连接。 - 当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。
- B 收到 A 发出的确认后，才进入 CLOSED状态，在 B 撤销 PCB 后，本次 TCP 连接才算结束。
B 结束 TCP 连接的时间要比 A 早一些，因为 A 要等待 2MSL。
1 | 为什么A在TIME-WAIT状态必须等待2MSL的时间? |
1 | 1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失， |
TCP与UDP的首部
UDP 的首部
TCP 的首部
TCP 与 UDP 的对比
| TCP | UDP |
|---|---|
| 用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及差错检测的功能 | |
| 面向连接，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。 | 无连接的，即发送数据之前不需要建立连接，发送数据之后也不需要断开连接，因此减少了开销和发送数据之前的时延。 |
| 提供可靠交付，通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。 | 尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表 |
| 面向字节流。TCP中的“流”(stream)指的是流入到进程或从进程流出的字节序列。 | UDP是面向报文的 |
| 滑动窗口，流量控制，拥塞控制，停止等待协议，连续ARQ协议 | 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对实时应用是很重要的。吞吐量只受限于数据生成速率，传输速率以及机器性能 |
| 每一条TCP连接只能有两个端点(endpoint)，每一条TCP连接只能是点对点的(一对一) | 支持一对一、一对多、多对一和多对多的交互通信。 |
| 首部至少20个字节 | 首部开销小，只有8个字节 |
| TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。 | 提供全双工通信 |
参考
- 《计算机网络》第七版，谢希仁。
