nginx和php-fpm 是使用 tcp socket 还是 unix socket ？ - demo - CSDN博客
nginx和php-fpm 是使用 tcp socket 还是 unix socket ？
tcp socket
允许通过网络进程之间的通信，也可以通过loopback进行本地进程之间通信。
unix socket
允许在本地运行的进程之间进行通信。
从上面的图片可以看，unix socket减少了不必要的tcp开销，而tcp需要经过loopback，还要申请临时端口和tcp相关资源。但是，unix socket高并发时候不稳定，连接数爆发时，会产生大量的长时缓存，在没有面向连接协议的支撑下，大数据包可能会直接出错不返回异常。tcp这样的面向连接的协议，多少可以保证通信的正确性和完整性。
如果是在同一台服务器上运行的nginx和php-fpm，并发量不超过1000，选择unix socket，因为是本地，可以避免一些检查操作(路由等)，因此更快，更轻。
如果我面临高并发业务，我会选择使用更可靠的tcp socket，以负载均衡、内核优化等运维手段维持效率。
nginx和php-fpm 使用unix socket
将sock文件放在/dev/shm目录下，使用的内存读写更快。
# cd /dev/shm
touch php7.0-fpm.sock
chown www-data:www-data php7.0-fpm.sock
chmod 777 php7.0-fpm.sock
php-fpm 配置
# vi /etc/php/7.0/fpm/pool.d/www.conf
listen= /dev/shm/php7.0-fpm.sock
listen.owner = www-data
listen.group = www-data
nginx server块配置
location ~* \.php$ {
fastcgi_pass unix:/dev/shm/php7.0-fpm.
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_
提高nginx和php-fpm使用的 unix socket稳定性(单机能力有限)
1.修改内核参数
net.unix.max_dgram_qlen = 4096
net.core.netdev_max_backlog = 4096
net.core.somaxconn = 4096
2.提高backlog
backlog默认位128，1024这个值最好换算成自己正常的QPS。
nginx.conf
listen 80 default backlog=1024
php-fpm.conf
listen.backlog = 1024
3.增加sock文件和php-fpm实例
在/dev/shm新建一个sock文件，在nginx中通过upstream魔抗将请求负载均衡到两个sock文件，
并且将两个sock文件分别对应到两套php-fpm实例上。
我的热门文章nginx 和 php-fpm 通信使用unix socket还是TCP，及其配置
时间： 07:59:44
&&&& 阅读：116
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&
nginx和fastcgi的通信方式有两种，一种是TCP的方式，一种是unix socke方式。两种方式各有优缺点，这里先给出两种的配置方法，然后再对性能、安全性等做出总结。
TCP是使用TCP端口连接127.0.0.1:9000
Socket是使用unix domain socket连接套接字/dev/shm/php-cgi.sock（很多教程使用路径/tmp，而路径/dev/shm是个tmpfs，速度比磁盘快得多）,在服务器压力不大的情况下，tcp和socket差别不大，但在压力比较满的时候，用套接字方式，效果确实比较好。
TCP配置方式
TCP通信配置起来很简单，三步即可搞定
第一步，编辑 /etc/nginx/conf.d/你的站点配置文件（如果使用的默认配置文件，修改/etc/nginx/sites-available/default）
将fastcgi_pass参数修改为127.0.0.1:9000，像这样：
1234567location ~ \.php$ {&&&&&&index index.php index.html index.htm;&&&&&&include /etc/nginx/fastcgi_params;&&&&&&fastcgi_pass 127.0.0.1:9000;&&&&&&fastcgi_index index.php;&&&&&&include fastcgi_params;&}&第二步，编辑php-fpm配置文件&/etc/php5/fpm/pool.d/www.conf将listen参数修改为127.0.0.1:9000，像这样：
listen=127.0.0.1:9000
&第三步，重启php-fpm，重启nginx
unix socket配置方式
unix socket其实严格意义上应该叫unix domain socket，它是*nix系统进程间通信（IPC）的一种被广泛采用方式，以文件（一般是.sock）作为socket的唯一标识（描述符），需要通信的两个进程引用同一个socket描述符文件就可以建立通道进行通信了。
Unix domain socket 或者 IPC socket是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。与管道相比，Unix domain sockets 既可以使用字节流和数据队列，而管道通信则只能通过字节流。Unix domain sockets的接口和Internet socket很像，但它不使用网络底层协议来通信。Unix domain socket 的功能是POSIX操作系统里的一种组件。Unix
domain sockets 使用系统文件的地址来作为自己的身份。它可以被系统进程引用。所以两个进程可以同时打开一个Unix domain sockets来进行通信。不过这种通信方式是发生在系统内核里而不会在网络里传播。
配置需要五步
第一步，决定你的socket描述符文件的存储位置。
可以放在系统的任意位置，如果想要更快的通信速度，可以放在/dev/shm下面，这个目录是所谓的tmpfs，是RAM可以直接使用的区域，所以，读写速度都会很快。
决定了文件位置，就要修改文件的权限了，要让nginx和php-fpm对它都有读写的权限，可以这样：
123sudo touch /dev/shm/fpm-cgi.socksudo chown www-data:www-data&/dev/shm/fpm-cgi.socksudo chmod 666&/dev/shm/fpm-cgi.sock&第二步，修改php-fpm配置文件/etc/php5/fpm/pool.d/www.conf将listen参数修改为/dev/shm/fpm-cgi.sock，像这样：
listen=/dev/shm/fpm-cgi.sock
&将listen.backlog参数改为-1，内存积压无限大，默认是128，并发高了之后就会报错
123&; Set listen(2) backlog. A value of ‘-1‘ means unlimited.&; Default Value: 128 (-1 on FreeBSD and OpenBSD)&listen.backlog = -1&第三步，修改nginx站点配置文件将fastcgi_pass参数修改为unix:/dev/shm/fpm-cgi.sock，像这样：
location~\.php${
&&&&&&indexindex.phpindex.htmlindex.htm;
&&&&&&include/etc/nginx/fastcgi_params;
&&&&&&fastcgi_passunix:/dev/shm/fpm-cgi.sock;
&&&&&&fastcgi_indexindex.php;
&&&&&&includefastcgi_params;
第四步，修改/etc/sysctl.conf 文件，提高内核级别的并发连接数（这个系统级的配置文件我也不是特别熟悉，参考的是：《》）
sudoecho‘net.core.somaxconn
= 2048‘&&/etc/sysctl.conf
sudosysctl-p
第五步， 重启nginx和php-fpm服务（最好先重启php-fpm再重启nginx）
两种通信方式的分析和总结
从原理上来说，unix socket方式肯定要比tcp的方式快而且消耗资源少，因为socket之间在nginx和php-fpm的进程之间通信，而tcp需要经过本地回环驱动，还要申请临时端口和tcp相关资源。
当然还是从原理上来说，unix socket会显得不是那么稳定，当并发连接数爆发时，会产生大量的长时缓存，在没有面向连接协议支撑的情况下，大数据包很有可能就直接出错并不会返回异常。而TCP这样的面向连接的协议，多少可以保证通信的正确性和完整性。
当然以上主要是半懂不懂的理论分析加主观臆测，具体的差别还是要通过测试数据来说话，以后有空，会进行这方面的测试。从网上别人博客的测试数据，我的理论分析差不多是对的。至于你选择哪种方式，我只能说“鱼和熊掌不可兼得也”，通过高超的运维和配置技巧，在性能和稳定性上做一个平衡吧。
说说我的选择
其实，如果nginx做要做负载均衡的话，根本也不要考虑unix socket的方式了，只能采用TCP的方式。现在我的小站没有那么高的并发量，所以就用unix socket了，以后如果有了高并发业务，再进行一些参数调整即可应付，如果真要是无法支撑，那只能做负载均衡了，到时候自然会选择TCP方式。
http://xieminis.me/?p=216 &
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&原文：http://blog.csdn.net/pcyph/article/details/
教程昨日排行
&&国之画&&&& &&&&&&
&& &&&&&&&&&&&&&&
鲁ICP备号-4
打开技术之扣，分享程序人生！配置 php-fpm.d/www.conf
# vi /etc/php-fpm.d/www.conf
; listen = 127.0.0.1:9000 注释
listen = /dev/shm/fpm-fcgi. 添加
/dev/shm 目录为
虚拟内存文件系统，具有闪电般的速度。
可以通过 df -h | grep tmpfs 查看属于 tmpfs 的磁盘目录。
配置 nginx.conf
# /etc/nginx/nginx.conf
# fastcgi_pass
127.0.0.1:9100;
fastcgi_pass unix:/dev/shm/fpm-fcgi.
重启 service php-fpm reload，service nginx reload。
http://wiki.nginx.org/PHPFcgiExample#Using_a_Unix_Socket
转载请注明出处。本文地址：
? 分类列表
? 优化/技巧内容列表
? 热门标签
? 本文目录前几天看到，提到php所在服务器在大并发情况下，频繁创建TCP短连接，而其所在服务器的2MSL时间过长，导致没有端口可用，系统无法创建TCP socket，而大量报错。博主在后面给的解决方案是减少2MSL的时间，尽快清除TIME_WAIT状态的TCP连接，回收端口。同时，文章结尾写了不用长连接的理由，但这真的是最好的解决办法吗？有其他办法可以更好的做法吗？
类似经历
之所以多这篇文章兴趣这么高，是因为在前段时间，末学也经历了一件类似的优化历程，先简短的描述下我们的服务器架构。如图
一款webgame 粗略架构图
想必看到这幅架构图的同学，都比较熟悉吧，也比较简单。“最前面”的nginx 反代负责与玩家的http请求通讯，这里是长连接。在其与后端游戏大区通讯时，使用了短连接，也就是意味着，每处理用户的一个http请求，都要重新与后端的nginx建立一次TCP(http)请求，后端nginx处理完之后就关闭。后端的nginx与php在同一台服务器上，通讯配置如下：
upstream server1 {
&&&&server& 10.10.10.1&& max_fails=2& fail_timeout=30s;& #app1
&&&&server& 10.10.10.2&& max_fails=2& fail_timeout=30s;& #app2
location ~ \.php$ {
&&&&root&&&&&&&&&&
&&&&fastcgi_pass&& 127.0.0.1:9000;
&&&&fastcgi_index& index.
&&&&fastcgi_param& SCRIPT_FILENAME& /scripts$fastcgi_script_name;
&&&&include&&&&&&&
; The address on which to accept FastCGI requests.
; Valid syntaxes are:
'ip.add.re.ss:port'&&&
- to listen on a TCP socket to a specific addres
'port'&&&&&&&&&&&&&&&&
- to listen on a TCP socket to all addresse
'/path/to/unix/socket'
- to listen on a unix socket.
; Note: This value is mandatory.
listen = 127.0.0.1:9000
在这个架构图中，反代承担这承上启下的作用，前面是用户，后面是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连接。。。以游戏的其中一个大区为例：
关于这个问题，末学在上请教过其他大牛，其中负责人以及前辈告诉我，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来连接服务器，当然，这也是我的猜测，没有去验证，大家听听就好，别相信。
鉴于末学对以上的理解，将服务器的架构配置变更如下
upstream server1 {
&&&&&&&&keepalive 10
&&&&&&&&server 10.10.8.97& max_fails=2 fail_timeout=30s;& #app1
&&&&&&&&server 10.10.8.99& max_fails=2 fail_timeout=30s;& #app2
&&&&&&&&server 10.10.8.85& max_fails=2 fail_timeout=30s;& #app3
location ~ ^([^.]+\.php)($|/.*) {
&&&&fastcgi_pass unix:/var/run/php5-fpm.
&&&&fastcgi_index index.
&&&&include
; Note: This value is mandatory.
listen = /var/run/php5-fpm.sock
至此，优化还为完毕，若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的错，但nginx也可给出更严谨的范例，但仍没有。
值得欣慰的是，在UBUNTU 12.4中，nginx的默认配置有了很大的改进，不管是匹配uri的规则，还是nginx与php-fpm的交互方式：
#location ~ \.php$ {
#&&&&&& fastcgi_split_path_info ^(.+\.php)(/.+)$;&&&
#&&&&&& # NOTE: You should have
&cgi.fix_pathinfo = 0;&
in php.ini
#&&&&&& # With php5-cgi alone:
#&&&&&& fastcgi_pass 127.0.0.1:9000;&&&
#&&&&&& # With php5-fpm:
#&&&&&& fastcgi_pass unix:/var/run/php5-fpm.&&&
#&&&&&& fastcgi_index index.
PS：末学只是个web程序员，这些只是末学学习研究如上知识的总结，理解上难免有错，各位请海涵。
本文已收录于以下专栏：
相关文章推荐
nginx和fastcgi的通信方式有两种，一种是TCP的方式，一种是unix socke方式。两种方式各有优缺点，这里先给出两种的配置方法，然后再对性能、安全性等做出总结。
tcp socket允许通过网络进程之间的通信，也可以通过loopback进行本地进程之间通信。unix socket允许在本地运行的进程之间进行通信。分析
从上面的图片可以看，unix socke...
type TCPAddr  //表示TCP终端地址
type TCPAddr struct {
Zone string // IPv...
1、首先安装nginx
sudo apt-get install nginx
2、安装php和php5-fpm模块
sudo apt-get install nginx php5-fpm
创建scoket文件 UNIX Domain
Socket IPC
/c/linux-c-programming/ch37...
转自：http://blog.csdn.net/ace_fei/article/details/6412069
socket API原本是为网络通讯设计的，但后来在socket的框架上发展出一种IP...
http://blog.csdn.net/wlh_flame/article/details/6358795#
找了大半...
UNIX Domain Socket是在socket架构上发展起来的用于同一台主机的进程间通讯（IPC），它不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将...
By 1. unix域的数据报服务是否可靠2. STREAM 和 DGRAM 的主要区别3. SO_SNDBUF 和 SO_REVBUF4. 缓冲队列的长度
UNIX Domain Socket是在socket架构上发展起来的用于同一台主机的进程间通讯（IPC），它不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答等，只是将应用...
他的最新文章
讲师：刘文志
讲师：陈伟
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)安装nginx1.12 加php，php-fpm配置使用unix socket | 中国美德美文分享