TCP简述
TCP协议是面向连接的、可靠的、基于字节流的传输层通信协议。其中最出名的就是三次握手和四次挥手
什么是三次握手
三次握手的建立。连接必须先由一方主动发起，另一方被动接受的
简单来说就是
- 首先客户端给服务端发送一个请求，请求连接
服务端接收到客户端发来的请求,回一个，“我已收到你发来的请求，我同意发起连接”
客户端接收到服务端的请求,回一个,“好的，我已经收到你的同意的信号了”
然后就开始传输数据了
为什么是三次握手而不是两次或四次握手？
因为TCP是可靠传输协议，两次握手的话，可能会出先死锁的情况。
比如，当C端要向S端发送请求，第一次请求连接，S端收到后，发送同意请求，回复“我同意连接”，因为是两次握手，所以S端已经打开了连接并且可以向C端发送数据，。此时，如果S端发送的同意请求丢失了，C端并不知道S端收到了我的建立连接的请求，所以会忽略S端发来的数据，S端发送的数据没有得到C端的响应，就会一直发送。这样就造成了死锁的情况。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
什么是四次挥手
所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。
简单描述下
客户端向服务端发送关闭连接请求，“请求关闭连接”
服务端收到请求，并回“我收到了，给我时间准备一下”
当服务端准备好了，又回客户端“我准备好了关闭连接了”
客户端接收服务端到这一次的请求后，回复“那我们关闭连接吧” 等待2MSL,关闭，服务端收到后也关闭连接
为什么客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
