HTTP、PHP-FPM、与握手协议

摘要：一般产生的原因是系统没有主动关闭连接如连接资源没有关闭关于网络链路中追踪异常用到的运维命令以下显示的和端口均为假数据中查看的状态参数说明已使用的所有协议套接字总量正在使用正在侦听的套接字数量。其值等于已分配已建立已申请到的套接字数量。

用户输入url如http:www.baidu.com到浏览器，浏览器如chrom需要将其解析为ip地址才知道需要到哪里去访问哪个服务器。浏览器解析DNS步骤如下

搜索浏览器自身的dns缓存，这个缓存缓存时间短，缓存数目有限。

搜索操作系统的dns缓存

读取host文件的dns映射(一般做本地开发映射都是修改这个文件来达到拦截浏览器请求到本地服务器的目的，从而使本地可以成功映射服务器地址)

先本地网卡配置里的dns服务器发起域名解析请求，这里好像还有一套运营商的处理流程就不在展开了。

下面好像还有一些流程，由于基本不会执行到这一步，一般所以dns运营商的dns服务器都会搞定的。

解析失败，以上任何一步成功都会返回一个成功的ip地址

浏览器以一个随机的端口享这个ip地址的特定端口(默认80)发起著名的TCP3次握手。关于一个http请求是如何到达nginx服务的流程大致如下：

握手完成后的浏览器和服务器就可以愉快地发送http请求了，具体在nginx上流程如下：

对于一个PHP的web程序来说，web服务器（如：nginx）要想与它通信需要通过CGI协议。当一个web请求触达web服务器时，web服务器会创建一个CGI进程,CGI进程将web的请求按照固定的格式进行解析，然后写入标准输入(STDIN)和环境变量中，然后PHP启动的CGI解析器会从标准输入(STDIN)和环境变量中读取http请求的数据，所以$_SERVER才会有数据，然后做出相应的逻辑处理，然后将处理结果放入标准输出(STDOUT)，CGI进程从STDOUT中读取响应数据然后传输给浏览器，这样服务端就完成了一次http请求。

上面是CGI的实现流程，但是使用CGI协议的服务器在用户每次访问服务器的时候都需要fork/销毁CGI进程，必然照成多余的系统开销，所以FASTCGI就是为了解决这个问题的。

FastCGI会创建一个常驻的master进程和多个worker进程，master进程负责管理和为worker进程反派任务，worker进程负责内部嵌入了CGI解析器用于解释php代码。

PHP-FPM是一个FastCGI进程管理器，在LNMP体系中就是由它来实现FastCGI协议的。同样，它也会创建一个常驻的master进程和多个worker进程，master进程负责监听端口和接收来自nginx的请求，指派任务给worker进程。worker进程的负责解释php代码。PHP-FPM可以通过配置预先启动一定数量的worker进程，这样当http请求触达时就可以更快速的响应。

nginx与PHP-FPM之间的通信一般通过其ngx_http_fastcgi_module模块来实现。其中fastcgi_pass用于设置fastcgi服务器的IP地址;fastcgi_param设置传入fastcgi服务器的参数。这个模块出现的配置问题一般集中在这一块。

相对于并发状态下出现的问题，一般也都集中在fastcgi服务器上，具体表现为fastcgi服务器为了应对大量的http请求必须不停的fork新的worker进程，这时就需要考虑服务器可支持的最大链接数和最大打开文件数（可通过ulimit -n查看）以及php-fpm配置里的最低开启worker数和最高开启worker数的限制。高性能服务器可以在这个方向上调优。

在四次挥手断开连接中,发起socket主动关闭的一方 socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),TIME_WAIT状态下的socket不能被回收使用.

具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket, 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务.

TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。一般产生的原因是系统没有主动关闭连接,如mysql连接资源没有关闭

(以下显示的IP和端口均为假数据)

cat /proc/net/sockstat

netstat -na | awk "/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}"

tcpdump -n port 3306

11:38:45.693382 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [F.], seq 123, ack 144, win 227, options [nop,nop,TS val 3000355 ecr 2997359], length 0 # MySQL发送fin包给我
11:38:45.740958 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 124, win 229, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # 我回复ack给它
11:38:45.740960 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [F.], ack 125, win 231, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # MySQL发送fin包给客户端
11:38:45.740965 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 125, win 229, options [nop,nop,TS val 3000360 ecr 3000355], length 0 # 客户端回复ack给我
......

src > dst: flags data-seqno ack window urgent options
# 发生了 3次握手
11:38:15.679863 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [S], seq 4065722321, win 29200, options [mss 1460,sackOK,TS val 2997352 ecr 0,nop,wscale 7], length 0
11:38:15.679923 IP 172.18.0.3.3306 > 172.18.0.5.38822: Flags [S.], seq 780487619, ack 4065722322, win 28960, options [mss 1460,sackOK,TS val 2997352 ecr 2997352,nop,wscale 7], length 0
11:38:15.679936 IP 172.18.0.5.38822 > 172.18.0.3.3306: Flags [.], ack 1, win 229, options [nop,nop,TS val 2997352 ecr 2997352], length 0

传送门