TCP三次握手与四次挥手

TCP是主机对主机层的传输协议，提供可靠地连接服务协议，采用三次握手建立一个连接
TCP三次握手
第一次握手：客户端发送SYN包（SYN=X）到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN(ACK=X+1)，同时自己也发送一个SYN包（SYN=Y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK（ACK=Y+1），此包发送完毕，客户端和服务器进入ESTABLISHEN状态，完成三次握手。

握手过程中传送的包里不含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方任何一方主动关闭连接之前，TCP连接都被一直保持下去。

采用三次握手原因：防止失效的连接请求报文段突然又传送到主机B，因而产生错误。
这里失效的连接文段是指 ：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输，考虑这一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟到达主机B，主机B以为主机A又发起新的连接，于是主机B统一连接，并向主机A发回确认，此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。
采用两次握手不行，可能失效，三次握手刚刚好，四次握手甚至更多次没有必要。
四次挥手
与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次挥手”
第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了（当然，在fin包之前发送的数据，如果没有收到ACK确认报文，主动关闭方依然会重发这些数据），但是，此时主动关闭方还可以接受数据；
第二次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发送数据了；
第三次挥手：被动关闭方发送一个FIN后，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发送数据了；
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，四次挥手完成。
需要四次挥手原因：TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭.
关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接.当一端收到一个FIN,它必须通知应用层TCP连接已终止了这个方向的数据传送,发送FIN通常是应用层进行关闭的结果.

主动断开的一方为什么要进入TIME_WAIT状态
原因：
1、可靠地实现TCP全双工连接的终止
TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK，如果A端不维持TIME_WAIT状态，而是处于CLOSED状态，那么A端将相应RST分节，B端收到后将此分节解释成一个错误（Java中会抛出connectionreset的SocketException）。
因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持在TIME_WAIT状态。
2、允许老的segment在网络中消逝
TCP segment 可能由于路由器异常而“迷途”，TCP发送端可能因确认超时而重发这个segment，迷途的segment在路由器修复后也会被送到最终目的地，这个迟到的迷途segment到达时可能会引起问题，在关闭“前一个连接”之后，马上又重新建立一个相同的IP和端口之间的“新连接”，前一个连接的迷途重复分组在前一个连接终止后到达，而被新连接收到了，为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自就连接重复分组已经在网络中消逝。