TCP之连接管理（三次握手、四次挥手）

TCP连接管理机制（三次握手、四次挥手）

1）三次握手可以形象的记为

客户端说:我要和你建立连接

服务器端说：可以，什么时候建立连接

客户端回答：就现在

2）为什么要三次握手而不是一次或者两次？一次或两次握手会出现什么情况？

TCP是一个面向连接的协议，而面向连接是为了保证传输的可靠性

如果只是一次"握手"，客户端发出请求建立连接的报文之后，就认为建立连接了，于是就要发出数据。但是请求连接的报文若是在网络中丢失或者是到达服务器端后，服务器无法建立连接，这样发送的数据就不能保证可靠性。

若是两次"握手"，1）客户端发出的请求连接的报文在网络中没有丢失，服务器端发出的同意建立连接的报文也正常发送到客户端，于是连接建立成功，皆大欢喜。

2）客户端发出的请求连接的报文在网络中没有丢失，服务器端就不会发出同意建立连接的报文，于是连接没有建立，这样不影响双方，最多只是重新进行连接

看了前两种情况，是不是觉得两次"握手"也是可以的，但是，还有一种情况是

3）客户端发出的请求连接的报文在网络中没有丢失，服务器端发出的同意建立连接的报文却在网络中丢失，这时，客户端没有收到收到服务器端的确认报文，认为连接没有建立成功，而服务器端却认为连接建立成功了，有一个前提是维护连接是要花费成本的，而服务器端花费了成本却维护了一个无效的连接，这就导致资源的浪费，而且服务器端是一对多个客户端，对资源的需求很大，维护这样一个连接是很奢侈的

若是三次握手的话，服务器端发出的同意连接的报文丢失的话，客户端没有接收到报文，两端就认为连接没有建立成功，对两端没有影响。当客户端接收到服务器端的同意连接的报文时，向服务器端发出对服务器端同意连接的报文响应时，服务器端接收到报文后，两端连接建立成功。若该报文丢失的话，服务器端没有接收到时，服务器端认为没有建立成功，只是客户端花费成本维护连接，而客户端是一对一连接服务器的，对资源的要求没有服务器端要求高，影响不是很大。造成这种情况的原因是网络中没有绝对可靠的传输，因为最近接收到的消息是没法进行确认的。

四次挥手

客户端的连接断开：客户端发起断开连接的请求后，服务器端进行发送同意报文；

服务器的连接断开：然后服务器端又发送请求，客户端发送确认断开连接的请求报文。

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.

为什么要等待2MSL时间，因为MSL是TCP报文的最大生存时间，为了保证在两个传输方向上的尚未被接受或迟到的报文段都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的）,同时也在理论上保证最后一个报文可靠到达（假设最后一个ACk丢失，那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK）

CLOSE_WAIT

当客户端向服务器发送断开连接的请求时，服务器端向客户端发送确认报文进入CLOSE_WAIT。进入到CLOSE_WAIT后说明服务器准备关闭连接，当服务器真正调用close关闭连接时，会向客户端发送FIN，此时，服务器进入LAST_ACK状态，等待最后一个ACK到来（这个ACK是客户端确认接收到了FIN）

CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。