为了防止 已失效的链接请求报文突然又传送到了服务端，因而产生错误。　　客户端发出的连接请求报文并未丢失，而是在某个网络节点长时间滞

正确答案是C三次握手面试时不能笼统的说第一次、第二次、第三次，而是要从编程的角度也就是TCP协议说明实现的方法，要理解标识位和状态位的变化。第一次握手([SYN],Seq=x)客户端发送一个SYN标记的包，Seq初始序列号x，发送完成后客户端进入SYN_SEND状态。第二次握手([SYN,ACK],Seq=y,ACK=x+1)服务器返回确认包(ACK)应答，同时还要发送一个SYN包回去。ACK=x+1,表示确认收到(客户端发来的Seq值+1)，Seq=y,表示让客户端确认是否能收到。发送完成后服务端进入SYN_RCVD状态。第三次握手([ACK],ACK=y+1)客户端再次发送确认包(ACK),ACK=y+1,表示确认收到服务器的包（服务端发来的Seq值+1）。客户端发送完毕后，进入ESTABLISHED状态，服务端接收到这个包，也进入ESTABLISHED状态,TCP握手结束

正确答案是C我们假设由client提出关闭，则：第一次：FIN（client发给server）第二次：ACK（server发给client）第三次：FIN（server发给client）第四次：ACK（client发给server）

因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。

这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。