目录
说一下TCP的三次握手？
官方回答：
客户端发送SYN ( seq=x ）报文给服务器端，进入SYN_SEND 状态。
服务器端收到SYN 报文， 回应一个SYN (seq =y ） 和ACK ( ack=x+ I ）报文，进入SYN RECV 状态。
客户端收到服务器端的SYN 报文， 回应一个ACK ( ack=y+ 1 ）报文，进入Established 状态
为什么要三次握手？两次行不行？四次呢？
非官方解释三次握手
第一次握手：客户端发送网络包，服务端收到了。服务端得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。客户端得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。服务端得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号
不使用「两次握手」和「四次握手」的原因：
- 「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
- 「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
TCP 在建立连接时要进行三次握手，在断开连接时要进行四次挥手，这是由于TCP的半关闭造成的。因为TCP 连接是全双工的（即数据可在两个方向上同时传递），所以在进行关闭时对每个方向都要单独进行关闭，这种单方向的关闭叫作半关闭。在二方完
成它的数据发送任务时，就发送一个FIN 来向另一方通告将要终止这个方向的连接。
TCP四次挥手的过程？
- 客户端应用进程调用断开连接的请求，向服务器端发送一个终止标志位FIN = 1，seq=u 的消息，表示在客户端关闭链路前要发送的数据已经安全发送完毕，可以开始关闭链路操作，并请求服务器端确认关闭客户端到服务器的链路操作。此时客户端处于
FIN-WAIT-l 状态。
服务器在收到这个FIN 消息后返回一个ACK=l,ack=u+ 1 ,seq=v 的消息给客户端，表示接收到客户端断开链路的操作请求，这时TCP 服务器端进程通知高层应用进程释放客户端到服务器端的链路服务器处于CLOSE - WAIT 状态，即半关闭状态。客户端在收到消息后处于FIN - WAIT- 2 状态
服务器端将关闭链路前需要发送给客户端的消息发送给客户端，在等待该数据发送完成后， 发送一个终止标志位FIN = l ,ACK= l ,seq=w,a ck= u+ 1 的消息给客户端，表示关闭链路前服务器需要向客户端发送的消息已经发送完毕，请求客户端确认关闭从服务器到客户端的链路操作， 此时服务器端处于LAS 下A C K 状态，等待客户端最终断开链路。
客户端在接收到这个最终FI N 消息后，发送一个ACK = l ,seq=u + l ,ack=w+ I 的消息给服务器端，表示接收到服务器端的断开连接请求并准备断开服务器端到客户端的链路。此时客户端处于TIM-WA IT 状态， TCP 连接还没有释放，然后经过等待计时器
( 2MSL ）设置的时间后，客户端将进入CLOSE 状态。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
为什么客户端最后还要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
- 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器
- 防止类似与"三次握手"中提到了的"已经失效的连接请求报文段"出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文