如何让server避免2MSL

　　1.首先根据TCP协议，主动发起关闭的一方会进入TIME_WAIT状态，持续2MSL.
　　
　　对于基于TCP的HTTP协议，如果关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240000个TIME_WAIT的记录，维护这些状态给Server带来很大的负担，并且由于TIME_WAIT状态占用的一些端口由于还没有被释放可能还会导致服务器端口不够用。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的TCP连接请求，判断系统中是否有一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
　　2.TIME_WAIT 状态到底会占用什么？
　　被占用的是一个五元组：（协议，本地IP，本地端口，远程IP，远程端口）。对于 Web 服务器，协议是 TCP，本地 IP 通常也只有一个，本地端口默认的 80 或者 443。只剩下远程 IP 和远程端口可以变了。如果远程 IP 是相同的话，就只有远程端口可以变了。这个只有几万个，所以当同一客户端向服务器建立了大量连接之后，会耗尽可用的五元组导致问题。
　　在高并发短连接的server端，当server处理完client的请求后立刻close socket此时会出现TIME_WAIT状态然后如果client再并发2000个连接，此时部分连接就连接不上了。
　　3.如何消除大量TCP短连接引发的TIME_WAIT?
　　1）可以改为长连接，但代价较大，长连接太多会导致服务器性能问题，而且PHP等脚本语言，需要通过proxy之类的软件才能实现长连接；
　　2）修改ipv4.ip_local_port_range，增大可用端口范围，但只能缓解问题，不能根本解决问题；
　　3）客户端程序中设置socket的SO_LINGER选项；
　　4）客户端机器打开tcp_tw_recycle和tcp_timestamps选项；
　　5）客户端机器打开tcp_tw_reuse和tcp_timestamps选项；
　　6）客户端机器设置tcp_max_tw_buckets为一个很小的值
　　So_linger的作用
　　struct linger {
　　int l_onoff; /* 0 = off, nozero = on */
　　int l_linger; /* linger time */
　　};
　　其取值和处理如下：
　　1、设置 l_onoff为0，则该选项关闭，l_linger的值被忽略，等于内核缺省情况，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据；
　　2、设置 l_onoff !=0 && l_linger = 0，则套接口关闭时TCP将断开连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态；
　　3、设置 l_onoff != 0 && l_linger != 0，当套接口关闭时内核将拖延一段时间（由l_linger决定）。
　　1、 若设置了SO_LINGER（亦即linger结构中的l_onoff域设为非零），并设置了零超时间隔，则closesocket()不被阻塞立即执行，不论是否有排队数据未发送或未被确认。这种关闭方式称为 “强制”或“失效”关闭 ，因为套接口的虚电路立即被复位，且丢失了未发送的数据。在远端的recv()调用将以WSAECONNRESET出错。
　　2、 若设置了SO_LINGER并确定了非零的超时间隔，则closesocket()调用阻塞进程，直到所剩数据发送完毕或超时。这种关闭称为 “优雅”或“从容”关闭 。请注意如果套接口置为非阻塞且SO_LINGER设为非零超时，则closesocket()调用将以WSAEWOULDBLOCK错误返回。
　　3、 若在一个流类套接口上设置了SO_DONTLINGER（也就是说将linger结构的l_onoff域设为零），则closesocket()调用立即返回。但是，如果可能，排队的数据将在套接口关闭前发送。请注意，在这种情况下WINDOWS套接口实现将在一段不确定的时间内保留套接口以及其他资源，这对于想用所以套接口的应用程序来说有一定影响。
　　TCP要保证在所有可能的情况下使得所有的数据都能够被投递。当你关闭一个socket时，主动关闭一端的socket将进入TIME_WAIT状态，而被动关闭一方则转入CLOSED状态，这的确能够保证所有的数据都被传输。当一个socket关闭的时候，是通过两端互发信息的四次握手过程完成的，当一端调用close()时，就说明本端没有数据再要发送了。这好似看来在握手完成以后，socket就都应该处于关闭CLOSED状态了。但这有两个问题，首先，我们没有任何机制保证最后的一个ACK能够正常传输，第二，网络上仍然有可能有残余的数据包(wandering duplicates)，我们也必须能够正常处理。
　　通过正确的状态机，我们知道双方的关闭过程如下:
　　假设最后一个ACK丢失了，服务器会重发它发送的最后一个FIN，所以客户端必须维持一个状态信息，以便能够重发ACK；如果不维持这种状态，客户端在接收到FIN后将会响应一个RST，服务器端接收到RST后会认为这是一个错误。如果TCP协议能够正常完成必要的操作而终止双方的数据流传输，就必须完全正确的传输四次握手的四个节，不能有任何的丢失。这就是为什么socket在关闭后，仍然处于 TIME_WAIT状态，因为他要等待以便重发ACK。