试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。

客户A与服务器B建立连接。
三次握手主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
“已失效的连接请求报文段”是这样产生的：
1.考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立的连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。
2.假定现出现了一种异常情况。A发出的第一个连接请求报文段没有丢失，而是在某些网络节点长时间滞留了，以致厌恶到连接释放以后的某个时间才到达B.但B受到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。但其实A并没有发出新的连接请求，因此不回理睬B的确认，也不会像B发送数据。而B却以为新的运输链接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
因此，采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求连接。

希望可以帮到你！

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

7-06

因为IP数据报的首部的总长度字段为16bit，因此IP数据报最大长度为216-1=65535字节(即64KB)，再减去IP首部(20字节)和TCP首部(20字节)，则为T