前几天看到一篇博客，提到php所在服务器在大并发情况下，频繁创建TCP短连接，而其所在服务器的2MSL时间过长，导致没有端口可用，系统无法创建TCP socket，而大量报错。博主在后面给的解决方案是减少2MSL的时间，尽快清除TIME_WAIT状态的TCP连接，回收端口。同时，文章结尾写了不用长连接的理由，但这真的是最好的解决办法吗？有其他办法可以更好的做法吗？

类似经历
之所以多这篇文章兴趣这么高，是因为在前段时间，末学也经历了一件类似的优化历程，先简短的描述下我们的服务器架构。如图

一款webgame 粗略架构图

想必看到这幅架构图的同学，都比较熟悉吧，也比较简单。“最前面”的nginx 反代负责与玩家的http请求通讯，这里是长连接。在其与后端游戏大区通讯时，使用了短连接，也就是意味着，每处理用户的一个http请求，都要重新与后端的nginx建立一次TCP(http)请求，后端nginx处理完之后就关闭。后端的nginx与php在同一台服务器上，通讯配置如下：

在这个架构图中，反代承担这承上启下的作用，前面是用户，后面是web app服务器，长连接用户，短连接后端。若用户数在1W人，1W人与反代的连接，在反代服务器上都用80端口。但这1W人的每一个请求，反代都要重新使用服务器的端口与后端nginx的80创建tcp socket，来处理请求。若2MSL时间为1分钟以上，同时，玩家两次请求间隔很短，想我们游戏的服务器，两次请求间隔大约5秒(甚至2-3秒)。那么反代的端口，5秒用1W个，10秒2W，15秒3W，20秒4W，25秒5W，30秒6W！！！，前面已经用掉的端口还没被回收掉。那么将会有很多的用户请求被nginx反代接收之后，因没有端口资源而无法与后端nginx创建tcp连接。。。以游戏的其中一个大区为例：

关于这个问题，末学在新浪微博上请教过其他大牛，其中tengine负责人淘叔度前辈以及@120斤的大青蛙前辈告诉我，nginx将在1.1.4版本开始支持ngx_http_upstream_keepalive，3月1号左右，是1.1.16 dev版本，我们的运维团队稍微由于几天，之后在部分小区的服务器上适用了1.1.16，效果不错，Nginx反代上与目标服务器的80端口的TCP连接中处于ESTABLISHED状态的非常多，TIME_WAIT的几乎没有，很稳定。我们几乎计划为了这个性能的提升，决定用dev版了。接着nginx1.2Stable version也出来了，那么也就用这个版本了。至于反代上nginx与后端app server建立TCP连接个数,也就是端口数(满载情况下，维持ESTABLISHED状态)的为nginx worker_processes * ((upstream1 server * keepalive参数数量) + (upstream2 server * keepalive参数数量) + …)，并不多。

如上，端口占用数少了，那么还有其他有点吗？先看一副 socket创建，监听、数据接收发送、关闭与客户端连接的socket流程图：

如上图，nginx反代跟后端nginx的形式跟php-fpm与mysqld socket的模型一样的。
nginx反代跟php-fpm 相对来说，就是客户端，这种做法，他们的每个新socket 请求的发起，都会跟着左边的流程走一遍，一遍又一遍。。。。每次的socket创建，端口等资源申请，与服务端的三次握手，关闭时的四次握手，端口的回收。。。。
改用长连接之后，如下图：

只有php-fpm(或者nginx反代)的子进程分别与mysqld创建1次TCP连接，之后都是send、recv数据的事情了，端口占用也是为数不多的几个(每个fpm子进程将与mysqld维持一个TCP长连接)。

同样，后端服务器的nginx与php-fpm的通讯也是如此，只是请求两没有反代那么大。区别就是IP地址是回环地址127.0.0.1。
既然是回环地址，那么两个服务都是在同一台机器上跑的，既然是同一台机器，为何不用进程间通讯的socket-unix domain socket呢？
socket是神马？摘抄一段描述：

Socket 可以被定义描述为两个应用通信通道的端点。一个 Socket 端点可以用 Socket 地址来描述， Socket 地址结构由 IP 地址，端口和使用协议组成( TCP or UDP )。http协议可以通过socket实现，socket在传输层上实现。从这个角度来说，socket介于应用层和传输层之间。但是socket作为一种进程通信机制，操作系统分配唯一一个socket号，是依赖于通信协议的，但是这个通信协议不仅仅是 tcp或udp，也可以是其它协议。

在同一台服务器上，用tcp socket与unix domain socket有什么区别？
如图所示，对于进程间通讯的两个程序，unix domain socket的流程不会走到TCP 那层，直接以文件形式，以stream socket通讯。如果是TCP socket,则需要走到IP层。

对于非同一台服务器上，TCP socket走的就更多了。

至于localhost\127.0.0.1以及网络IP他们之间的区别，无意中找到一篇博客写的是以mysql作为验证，来说明localhost不走TCP/IP层，跟127.0.0.1不一样。末学认为他理解错了。他的理由如下

(以下截图均在linux上，windows的没有unix domain socket)
mysql连接本机时，不加-h参数：

mysql连接本机时，加-h参数且值是localhost：

mysql连接本机时，加-h参数且值是127.0.0.1：

那位同学从mysql工具的使用方法、与结果的区别，来理解推导localhost与127.0.0.1的区别，这从方向上就存在问题，我更相信，这是mysql这个程序自己的行为，遇到-h参数没加，或者-h参数的值不是IP形式，且my.cnf里指定mysql的socket路径时，则直接使用unix domain socket来连接服务器，当然，这也是我的猜测，没有去验证，大家听听就好，别相信。

鉴于末学对以上的理解，将服务器的架构配置变更如下

至此，优化还为完毕，若php-fpm与mysql使用mysql_pconnect的话，那么php-fpm的子进程生成模式最好用static模式，若为dynamic模式，可能会出现mysql连接数被占满的情况，这也跟mysql服务的连接超时时间有关，适当调整也容易避免。
不过，我们目前还没用mysql_pconnect，主要原因是我们的代码中，有些事务处理开启之后，对于代码的失败处理，忘记写回滚语句，在短连接的情况下，这个连接的销毁，哪怕客户端没提交ROLLBACK或者COMMIT指令，mysql会自动回滚之前的事务。但使用长连接之后，不同请求会使用同一个MYSQL连接句柄，每个事务开启都会禁用MYSQL的自动提交，即SET AUTOCOMMIT=0语句，这语句会提交之前的事务。对于我们代码忘记写回滚，而直接返回结果的情况下，这是会出大问题的，也是我们目前唯一没有使用MYSQL_pconnect的原因。(计划近期找到没有写回滚语句的代码，修复，继续使用mysql_pconnect)

其实还有，我们php-fpm使用了APC来缓存php file，以及 变量数据等，这些也是有优化的地方(如果有时间的话，则待续)。

回过头来再理解下文章开头那位同学给的解决办法，我仍不能从他给的理由中，理解长连接的缺点，哪怕是解决了TIME_WAIT的问题，但每次创建TCP socket ,连接到服务器时三次握手，关闭TCP socket时的四次握手 这些也是开销。当然，缩短2MSL的时间，也是更好利用服务器资源的一个好方法。

最后，我们调整优化的服务器架构图如下：

好像有点偏离这篇文章的标题了，其实我更想说我不能理解为啥nginx跟php-fpm给的默认配置中，都是TCP socket通讯的，为啥不默认给unix domain socket的默认配置呢？如果说为了方便非同一台服务器时的情况，但给的默认IP也是回环地址呀。
而且，nginx给默认配置中，对于uri请求中的php文件的处理，匹配规则还是老的，之前发生因为NGINX与PHP的配置而导致的安全问题，虽然不是nginx的错，但nginx也可给出更严谨的范例，但仍没有。

值得欣慰的是，在UBUNTU 12.4中，nginx的默认配置有了很大的改进，不管是匹配uri的规则，还是nginx与php-fpm的交互方式：

PS：末学只是个web程序员，这些只是末学学习研究如上知识的总结，理解上难免有错，各位请海涵。

建议继续学习：

1. 推荐一些socket工具，TCP、UDP调试、抓包工具    (阅读：9480)
2. 推荐一些socket工具，TCP、UDP调试、抓包工具    (阅读：7334)
3. 用unix socket加速php-fpm、mysql、redis的连接    (阅读：6601)
4. 浅析linux kernel network之socket创建    (阅读：5766)
5. web socket 心跳包的实现方案    (阅读：4978)
6. python中的socket代理    (阅读：4866)
7. netstat和web主机socket文件分析    (阅读：4490)
8. 使用socket.io和node.js搭建websocket应用    (阅读：4403)
9. php socket为什么这么慢，直到超时    (阅读：3963)
10. php实现的thrift socket server    (阅读：3699)