三次握手

• 第一次：客户端发送请求连接的报文；SYN=1，表请求建立连接的报文；seq,序列号，随机。

• 第二次：服务端发送请求连接和同意连接的报文；ACK=1，表示确认号有用；ack=x+1，表示服务端希望客户端发送的下一个报文的序列号；seq，随机。

• 第三次：客户端发送同意连接的报文，seq为x+1；

• 开始数据连接后，如果客户端需要发送数据，他的序列号应该为seq=x+1；如果服务端需要发送数据，他的序列号应该为seq=y+1.（因为服务端在接收报文后，没有在发确认报文，客户端也就不知道下一个报文的序列号）

• 问题：三次握手中如果第一个报文丢失？

  客户端会重发第一个报文，因为客户端没有收到第二个确认（请求）报文；

  服务端不做任何操作。

• 问题：三次握手中如果第二个报文丢失？

  客户端会重发第一个报文，因为客户端没有收到服务端第二个确认（请求）报文；

  服务端会重发第二个报文，因为服务端没有收到客户端的第三个确认报文。

• 问题：三次握手中如果第三个报文丢失？

  客户端不做任何操作，因为客户端发送的第三个报文是确认报文，只要本端发送出去就行了；

  服务端会重发第二个报文，因为服务端没有收到客户端的第三个确认报文，然后客户端重发第三个报文

• 问题：三次握手为什么一定要是三次，能不能用两次来建立？

  不可以，因为网络延时问题，服务端没有接收客户端的确认报文，会重新发送；那么这时，第二次发送的第二个报文到了客户端，建立连接；数据发送完成后，断开连接，突然第一次发送的报文到了，又会建立一次连接，会占用链路资源。

四次挥手

MSL：一个数据报文在网络中存在的最长时间（2分钟），为了防止报文的丢失，客户端和服务端会等待2MSL，再关闭数据传输的连接。

第一次：客户端发送请求断开连接的报文；FIN=1，表示断开连接。seq，基于数据传输中客户端发送的最后一个报文。

第二次：服务端发送同意断开连接的确认报文，seq，基于数据传输的最后一个报文。seq，基于数据传输中服务端发送的最后一个报文。

第三次：服务端发送请求断开连接的报文；seq，因为连接断开，所以seq随机。ack=u+1，因为对于服务端来说，连接已经断开，为了防止第二个报文网络延时/丢失，所以会加上ACK=1，ack=u+1。

第四次：客户端发送同意断开连接的确认报文；

问题：如果第一报文丢失？
客户端重发第一个报文，服务端再重发第二个报文，客户端没有接收到第二个报文。
- 问题：如果第二报文丢失？
客户端重发第一个报文，服务端再重发第二个报文，客户端没有接收到第二个报文。

问题：如果第三报文丢失？
服务端重发第三个报文，客户端再发送第四个报文

问题：如果第四报文丢失？
服务端重发第三个报文，客户端再发送第四个报文

问题：为什么不将第二第三次合拼？
因为数据的传输是双向的，有可能客户端数据传输完毕，而服务端数据没有。