计算机网络-5-10-TCP运输连接管理

TCP的运输连接管理

TCP是面向连接的通信，运输连接是用来传送TCP报文的，TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接有三个阶段，即：建立连接，数据传送，连接释放，运输连接的管理就是使运输连接和释放都能正常的进行。在TCP连接中主要解决以下问题：

要使每一方都能确认对方的存在。
要允许双方协商一些参数（如最大窗口值，是否使用窗口扩大选项和时间戳选项以及服务质量等）。
能够对运输实体资源进行合理的分配（如缓存大小，连接表中的项目等）。

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

TCP的连接建立

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

假定主机A运行的是TCP客户程序，而B运行的是TCP服务程序，最初两端的连接处于CLOSE(关闭) 状态，在本例中A主动打开连接，B被动打开连接。

TCP握手过程描述：

一开始,B的TCP服务器进程先创建传输控制块TCB（Transmission Control Block），准备接受客户进程的连接请求，然后服务器就处于LISTEN（监听）状态，等待客户的连接请求，如果有，就做出响应。
A的TCP客户进程也是首先创立传输控制模块TCB，然后在建立连接的时候，向服务器B发送连接请求报文段，这时候首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定：SYN报文段（SYN=1的报文段）不能携带数据，但是要消耗掉一个序列号，这时候，TCP客户端进程进入SYN-SENT同步已发送状态。
B收到连接请求的报文段，如果同意建立连接，则向A发送确认，在确认报文段SYN位=1，ACK位为1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y，注意，这个报文段也不能携带数据，但是同样要消耗一个序列号。这时候TCP服务器进程处于SYN-RCVD（同步收到）状态。
TCP客户进程收到B的确认后，还要给B给出确认，确认报文段的ACK=1确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍然是seq=x+1，这时候，TCP连接已经建立连接，客户端A进入ESTABLISHED(已建立连接状态)，
B收到A的确认报文后，也进入ESTABLISHED状态。

上面给出的连接过程叫做三次报文握手，注意，在图中，当B发送给A的报文段，也可以拆分成两个报文段，可以先发送确认报文段（ACK=1,ack=x+1）,然后再发送一个同步报文段（SYN=1，seq=y）,这样的过程就变成了四报文握手，但效果是一样的。

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

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

现假定出现一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B发出确认，新的连接就建立了。

由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。

采用三报文握手的办法，可以防止上述现象的发生。例如在刚才的异常情况下，A 不会

向B的确认发出确认。B 由于收不到确认，就知道A并没有要求建立连接。

TCP连接释放

TCP连接释放比较复杂，我们仍然结合双方状态的改变来阐明连接释放的过程。

数据传输结束后，通信的双方都可释放连接。现在 A 和 B 都处于 ESTABLISHED 状态（图5-29）。A 的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u，它等于前面已传送过的数据的最后一个字节的序号加 1。这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意，TCP 规定，FIN 报文段即使不携带数据，它也消耗掉一个序号。

B服务器收到连接释放的报文段后立即发出确认，确认号为ack=u+1，而这个报文段自己的序号为v，等于B前面已传过的数据的最后一个字节+1，然后服务器就进入CLOSE-WAIT(关闭等待)状态，TCP服务器进程这时候通知高层应用进程，因而从客户端A到服务器端B这个连接就释放了，这时候的TCP连接窗台处于半关闭状态（HALF-CLOSE），A已经没有数据发送给B了，但是B要使发数据，A仍然要接受，也就说，从B到A的方向的连接仍未关闭，这个状态可能还要持续一段时间。 A收到来自B的确认后，就进入FIN-WAIT2(终止等待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（时间等待状态），注意，现在的TCP并没有断开连接，而是必须经过时间等待计时器设置的2MSL(max segment lifetime),A才能进入CLOSED状态，时间MSL叫做最长报文段寿命，RFC标准建议为2min。为什么要设立时间等待状态必须为2MSL呢？
1. 为了保证客户端发送额最后一个ACK报文段能够到达B，这个ACK报文段有可能会丢失，因而使用LAST-ACK状态的B收不到对已发送FIN+ACK报文的确认，B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，重新启动AMSL计时器。最后知道A和B都进入CLOSED状态。
2. 防止上面提到的已失效的连接请求报文段出现在本连接中，A在发完最后一个ACK报文段的时候，再经过2MSL时间，就可以是本连接持续的时间内产生的所有报文段都从网络中协消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求文。
除了时间等待计时器之外，还应该设有保活计时器（keep-live timer），有这样的一个场景：客户端已经主动与服务器建立了TCP连接，但是后来客户端的主机突然出现了故障，显然，服务器以后就不能在也接收到客户端的数据了，因此，服务器就没有必要浪费资源继续与出现故障的客户端继续保持相连。这就需要使用保活计时器，服务器每收到一次客户端请求的数据，就重新重置保活计数器，时间的设置通常是两小时，若两小时内没有收到客户端的数据，服务器就发送一个探测报文段，以后每隔75s发送一个，若一连发送10个探测报文段后仍然没有相应，服务器就认为该客户端出现了故障，就关闭这个连接。

TCP的有限状态机)

为了更清晰地看出 TCP 连接的各种状态之间的关系，图 5-30 给出了 TCP 的有限状态机。图中每一个方框即 TCP 可能具有的状态。每个方框中的大写英文字符串是 TCP 标准所使用的 TCP 连接状态名。状态之间的箭头表示可能发生的状态变迁。箭头旁边的字，表明引起这种变迁的原因，或表明发生状态变迁后又出现什么动作。请注意图中有三种不同的箭头。粗实线箭头表示对客户进程的正常变迁。粗虚线箭头表示对服务器进程的正常变迁。另一种细线箭头表示异常变迁。