三次握手
- 一句话概括三次握手的必要性？
客户端和服务端都要确认对方可发送，可接收。 - 两次握手为什么不行？
第二次握手：当服务端收到建立连接请求后，发送ack+syn包，即完成了第二次握手（此时，服务端仅是发送了ack+syn包，并不知道会不不会被正确接受到）
因此，两次握手会出现如下问题。
- 第二次握手后服务端就建立连接（需要分配内存等资源），但是发出的ack+syn 丢失，客户端不能建立连接，服务端一直处于等待状态。造成资源浪费。
- 第二次握手后服务端就建立连接，那么客户端发送了连接请求，但是请求在网络堵塞了，客户端又发送了一次连接请求，第二次请求被服务端接收以后，第一次连接请求也到达了服务端，造成旧连接被响应。
- 第三次握手可以携带数据，也可以不携带数据。
四次挥手
- 一句话概括四次挥手的必要性？
客户端和服务端均确认自己无数据可发送，无数据需接受，并且断开信号被接收后，才可断开。 - 三次挥手为什么不行？
当服务端第二次发送FIN时，则服务端处于无数据可接收，无数据可发送的状态。服务端需要确保断开信号FIN 被客户端接收到，才能断开，因此需要第四次握手。否则，客户端一直处于等待状态。客户端接收到FIN时，需要确保断开信号ACK 被服务端接收，因此延时2MSL。 - 等待2MSL 后断开的作用？
等待2MSL后断开，确保服务端接收到最后一次ACK。如果不延迟2MSL就立即断开而后又发送了一个新请求，恰恰断开信号ACK又未被服务端接收。服务端会重复发送FIN, 等待最后一次ACK，但是客户端此时只会发新请求syn包，服务端会认为请求码错误。重置连接。确保ACK被接收到，才能避免后续连接不会被影响。 - 确保最后一次ACK被接收，为何不是等待1MSL?
1MSL 是报文最大生命周期。等待时间确保 当最后一次ACK未被接收时，服务端重新发送的FIN会被客户端再次接收识别。2MSL 已够用，更长的等待时间也不必要。
|
