TCP 的三次握手和四次挥手

一、UDP

用户数据报协议UDP 只在IP 的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及差错检测的功能。

1.1 UDP 的主要特点

1. UDP 是无连接的，即发送数据之前不需要建立连接（当然，发送数据结束时也没有连接可释放），因此减少了开销和发送数据之前的时延。

2. UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数）。

3. UDP 是面向报文的。发送方的UDP 对应用程序交下来的报文，在添加首部后就向下交付IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP 多长的报文，UDP 就照样发送，即一次发送一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP 把它交给IP层后，IP 层在传送时可能要进行分片，这会降低IP 层的效率。反之，若报文太短，UDP 把它交给IP 层后，会使IP 数据报的首部的相对长度太大，这也降低了IP 层的效率。

4. UDP 没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。很多的实时应用（如IP 电话、实时视频会议等）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP 正好适合这种要求。

5. UDP 支持一对一、一对多、多对一和多对多的交互通信。

6. UDP 的首部开销小，只有8个字节，比TCP 的20个字节的首部要短。

虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多的源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都无法正常接收。因此，不使用拥塞控制功能的UDP 有可能会引起网络产生严重的拥塞问题。

还有一些使用UDP 的实时应用，需要对UDP 的不可靠的传输进行适当的改进，以减少数据的丢失。在这种情况下，应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。

二、TCP

TCP 是TCP/IP 体系中非常复杂的一个协议。

2.1 TCP 最主要的特点

1. TCP 是面向连接的运输层协议。这就是说，应用程序在使用TCP 协议之前，必须先建立TCP 连接。在传送数据完毕后，必须释放已经建立的TCP 连接。也就是说，应用进程之间的通信好像在“打电话”：通话前要先拨号建立连接，通话结束后要挂机释放连接。
2. 每一条TCP 连接只能有两个端点(endpoint)，每一条TCP 连接只能是点对点的（一对一）。
3. TCP 提供可靠交付的服务。通过TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达。
4. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP 的缓存后，就可以做自己的事，而TCP 在合适的时候把数据发送出去。在接收时，TCP 把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
5. 面向字节流。

TCP中的“流”(stream) 指的是流入到进程或从进程流出的字节序列。

虽然应用程序和TCP 的交互是一次一个数据块（大小不等），但TCP 把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP 并不知道所传送的字节流的含义。TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP 共10个数据块，但接收方的TCP 可能只用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

2.2 TCP 的连接建立

假定主机A 运行的是TCP 客户程序，而B 运行TCP 服务器程序。最初两端的TCP 进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP 进程所处的状态。请注意，A 主动打开连接，而B 被动打开连接。

B 的TCP 服务器进程先创建传输控制块 TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。如有，即作出响应。

A 的TCP 客户进程也是首先创建传输控制模块TCB，然后向B 发出连接请求报文段，这时首部中的同步位SYN = 1，同时选择一个初始序号seq = x。

TCP规定，SYN报文段（即SYN = 1的报文段）不能携带数据，但要消耗掉一个序号。

这时，TCP 客户进程进入SYN-SENT（同步已发送）状态。

B 收到连接请求报文段后，如同意建立连接，则向A 发送确认。在确认报文段中应把SYN 位和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状态。

上面给出的连接建立过程叫做三次握手(three-way handshake)。

2.3 为什么A 还要发送一次确认？

这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。

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

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

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

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A 不会向B的确认发出确认。B 由于收不到确认，就知道A 并没有要求建立连接。

2.4 TCP的连接释放

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

数据传输结束后，通信的双方都可释放连接。现在A 和B 都处于ESTABLISHED状态。A 的应用进程先向其TCP 发出连接释放报文段，并停止再发送数据，主动关闭TCP 连接。

A 把连接释放报文段首部的终止控制位FIN 置1，其序号seq =u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A 进入FIN-WAIT-1（终止等待1）状态，等待B 的确认。

TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。

B 收到连接释放报文段后即发出确认，确认号是ack = u + 1，而这个报文段自己的序号是v，等于B 前面已传送过的数据的最后一个字节的序号加1。然后B 就进入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。现假定B 的序号为w（在半关闭状态B可能又发送了一些数据）。B 还必须重复上次已发送过的确认号ack = u + 1。这时B 就进入LAST-ACK（最后确认）状态，等待A 的确认。

A 在收到B 的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK 置1，确认号ack = w + 1，而自己的序号是seq = u + 1，

TCP规定，前面发送过的FIN报文段要消耗一个序号。

然后进入到TIME-WAIT（时间等待）状态。

请注意，现在TCP 连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL 后，A 才进入到CLOSED 状态。

时间MSL 叫做最长报文段寿命(Maximum Segment Lifetime)，RFC 793 建议设为2 分钟。但这完全是从工程上来考虑，对于现在的网络，MSL = 2 分钟可能太长了一些。因此TCP 允许不同的实现可根据具体情况使用更小的MSL值。

因此，从A 进入到TIME-WAIT 状态后，要经过4分钟才能进入到CLOSED 状态，才能开始建立下一个新的连接。当A 撤销相应的传输控制块TCB 后，就结束了这次的TCP 连接。

2.5 为什么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 在TIME-WAIT 状态不等待一段时间，而是在发送完ACK 报文段后立即释放连接，那么就无法收到B 重传的FIN + ACK 报文段，因而也不会再发送一次确认报文段。这样，B 就无法按照正常步骤进入CLOSED 状态。

第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个ACK 报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B 只要收到了A 发出的确认，就进入CLOSED 状态。同样，B 在撤销相应的传输控制块TCB 后，就结束了这次的TCP 连接。我们注意到，B 结束TCP 连接的时间要比A 早一些。

上述的TCP 连接释放过程是四次握手。

本文内容来源于《计算机网络(第7 版) 谢希仁编著》第5 章运输层。