反向代理连接数上限为什么是65535

无论是Nginx还是百度开源的BFE，或是其它四层/七层流量代理，都会存在Socket连接数上限问题。

此连接数上限问题，指的是七层流量代理与后端服务建立的连接，而非七层流量代理与客户端建立的连接。

由于客户端与服务端建立连接，客户端需要占用一个端口号，这个端口号由系统分配，在Linux系统下，最大可用端口号为65535。

对于七层流量代理与后端服务间的通信而言，七层流量代理属于客户端，因此七层流量代理与后端服务建立的连接数是有限的。

如果是长连接，那么连接数理论上上限为65535。但由于一些系统进程会占用一部分端口号（如22端口），因此上限会少于65535。

这种不可修改的缺陷只能通过“低配置多实例”去增大连接数上限。

对于长连接而言，会有连接数上限问题，那么对于短连接是否就不存在这个问题了呢？

短链接，即创建连接后发起一次请并等待响应后就立即关闭的连接。但由于TCP协议存在四次挥手过程，因此，连接关闭后并不会马上释放端口，这个过程有个时间窗口，Linux下这个时间窗口默认大小为120秒。这么长的时间窗口，请求量达到546QPS以上就很容易导致无可用端口。

要理解这个问题，我们首先要理解TCP协议的四次挥手过程：

1、客户端向服务端发送标识FIN=1的数据包，告诉服务端，客户端不会再有会话数据发送，此时客户端的状态为FIN_WAIT_1；

2、服务端收到FIN请求后，向客户端发送ACK应答数据包，客户端收到ACK后状态变为FIN_WAIT_2，服务端状态为CLOSE_WAIT；

3、服务端向客户端发送标识FIN=1的数据包，告诉客户端，服务端不会再有会话数据发送。发送成功后，服务端状态为LAST_ACK；

4、客户端收到FIN请求后向服务端发送ACK应答数据包，此后客户端状态为TIME_WAIT，服务端收到ACK后，状态变为CLOSED，客户端等待2MSL后变为CLOSED。

从四次挥手过程可以看出，客户端的TIME_WAIT状态会持续2MSL才会变成CLOSED。

MSL（Maximum Segment Lifetime）即报文最大生存时间，是任何报文在网络上存活的最长时间，超过这个时间报文将被丢弃。因此，在2MSL时间内，该连接占用的端口将处于空闲且不可被使用状态。在Linux系统下，MSL默认值为60秒，2MSL即120秒。

为什么TIME_WAIT要维持2MSL时长呢？

1、第4次挥手是客户端发送ACK到服务端，如果发送完成后客户端就直接就关闭连接，如果网络抖动导致服务端未收到ACK，服务端就不会关闭连接。而等待2MSL时长期间，服务端没有收到应答就会继续发送FIN请求。

2、如果不等待2MSL，客户端关闭连接后端口就可能会被重用，如果再次用这个端口建立与服务器的连接，前后两个连接四元组（src ip+port,dec ip+port）相同，服务端就会认为是前一个连接，数据包会产生干扰。