关于四次挥手的事儿

1.基本名词解释：
1）MSL时间
MSL就是最大分节生命期，这是一个IP数据包能在互联网上生存的最长时间，超过这个时间IP数据包将在网络中消失。MSL在RFC1122上建议是2分钟，而源自berkeley的TCP实现传统上使用30秒。

2）TIME_WAIT状态维持时间
是两个MSL时间长度，也就是在1-4分钟，Windows操作系统就是4分钟。

3）用于统计当前各种状态的连接的数量的命令
CLOSED：无连接是活动的或正在进行
LISTEN：服务器在等待进入呼叫
SYN_RECV：一个连接请求已经到达，等待确认
SYN_SENT：应用已经开始，打开一个连接
ESTABLISHED：正常数据传输状态
FIN_WAIT1：应用说它已经完成
FIN_WAIT2：另一边已同意释放
ITMED_WAIT：等待所有分组死掉
CLOSING：两边同时尝试关闭
TIME_WAIT：另一边已初始化一个释放
LAST_ACK：等待所有分组死掉

2．关于客户端主动关闭连接：
进入TIME_WAIT状态的一般情况下是客户端，大多数服务器端一般执行被动关闭，服务器不会进入TIME_WAIT状态。当在服务器端关闭某个服务再重新启动时，服务器是会进入TIME_WAIT状态的。

大多数服务器端一般执行被动关闭，服务器不会进入TIME_WAIT状态。
服务端为了解决这个TIME_WAIT问题，可选择的方式有三种：

1) 保证由客户端主动发起关闭（即做为B端）
2) 关闭的时候使用RST的方式
3) 对处于TIME_WAIT状态的TCP允许重用

服务端提供在服务时，一般监听一个端口就够了。例如Apach监听80端口。
客户端则是使用一个本地的空闲端口（大于1024），与服务端的Apache的80端口建立连接。
当通信时使用短连接，并由服务端主动关闭连接时，主动关闭连接的服务端会产生TIME_WAIT状态的连接。
由于都连接到服务端80端口，服务端的TIME_WAIT状态的连接会有很多个。
假如server一秒钟处理1000个请求，那么就会积压240秒*1000=24万个TIME_WAIT的记录，服务有能力维护这24万个记录。

举例：
1）.客户端连接服务器的80服务，这时客户端会启用一个本地的端口访问服务器的80，访问完成后关闭此连接，立刻再次访问服务器的80，这时客户端会启用另一个本地的端口，而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。

2).客户端连接服务器的80服务，这时服务器关闭80端口，立即再次重启80端口的服务，这时可能不会成功启动，原因也是服务器的连接还处于TIME_WAIT状态。服务端提供服务时，一般监听一个端口就够了。例如Apach监听80端口。
客户端则是使用一个本地的空闲端口（大于1024），与服务端的Apache的80端口建立
连接。当通信时使用短连接，并由客户端主动关闭连接时，主动关闭连接的客户端会产生TIME_WAIT状态的连接，一个TIME_WAIT状态的连接就占用了一个本地端口。这样在TIME_WAIT状态结束之前，本地最多就能承受6万个TIME_WAIT状态的连接，就无端口可用了。
客户端与服务端进行短连接的TCP通信，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生4000个左右的TIME_WAIT socket，后续的短连接就会产生address already in use : connect的异常。