深入浅出web服务
对于没有做过web开发的人来说，web开发涉及到的名词似乎特别多，apache。nginx，cgi，php，http，cookie。session。这一大坨东西究竟是什么，这里我们就从网络的层面去理清楚这些东西。
1. 什么是HTTP
对于web来说贯穿始终的东西就是HTTP，那么什么是HTTP？官方说法就是Hyper Text Transfer Protocol，从这个名字上面还推断，HTTP是一种协议。而且是一种应用层协议，其相应的传输层协议TCP。
所以说究竟。HTTP就是建立在TCP基础上的一种应用层协议。
所以简单点说，就是client发起连接，然互通过tcp发过来一个数据报，server处理以后再回复一个数据报。并关闭连接。这样一次http请求就结束了。
所以最初的http模型是一次请求相应一次连接。也就是我们常常看到的，http无状态的特点。
1.1 数据报的格式
依据上面说的过程。就须要在server和client之间规定一种格式，两方都依照这样的格式来解包，http规定的协议格式例如以下：
用不论什么一个抓包工具都能看到一个包的全貌，比方头部字段名会包含Accept, Accept-Encoding, Accept-language, cache-control, connection, cookie, host, user-agent等。
而服务器回复的数据报一定含有一个status code。包头包括cache-control, connection, content-encoding, content-type, date, pragma, server, setcookie, transfer-encoding等字段。
后面会挑几个有意思的字段进行说明。
1.2 HTTP之COOKIE
先说cookie。cookie是用来做什么的呢？我们知道http协议本身是说每一次请求都是无状态的。即两次请求之间没有不论什么逻辑上的关联，http server不知道第二次请求和第一次请求是否来自同一个client。可是作为一个web应用无状态是肯定不满足需求的。一个最典型的样例就是用户的登录态，我们不能要求每次用户想要获取一个页面的时候都又一次登录，所以须要一些机制来记录这些状态，cookie和session是最主要的解决方式。
cookie是由浏览器来管理的，其一般保存在client内存中，所以生命周期为浏览器会话期间，关闭浏览器以后。cookie会自己主动消失。
当然假设cookie设置了过期时间。也会由浏览器同步在磁盘其中。
在每次http请求的过程其中，浏览器会依照一定的原则选择一部分cookie放在http包头其中发给webserver。
所以cookie过长导致的直接结果就是http包体过大，因此http协议对cookie的长度是有限制的。
怎样改动cookie呢？我们常常能看到用js或者php来改动cookie的sample code。用js来改动cookie是比較直观的，由于cookie由浏览器来管理，js也是由浏览器来解析的。可是为什么php作为server side的script也能改动cookie呢？就是由于http回包中的set-cookie这个字段，通过这个字段能够告诉浏览器须要改动cookie的哪些字段。
既然提到cookie，就一起说一下session。
session也是为了实现状态保存而设计的机制。不过它是存在server端的而已。
session能够看做是server端的一个hash表，默认是以文件的形式存储的，这个hash表的key就是session id。session id会保存在cookie其中，所以每次server解开http包以后，依据cookie中的session id就能够在hash表中数据。那么问题就来了，假设用户在浏览器禁掉了cookie。是不是就找不到session了呢？当然不是，不过禁掉cookie还有非常多其它的方式能够将其拼在http包其中传回来呀，能够放在包头的其它字段里比方说get參数。也能够放在包体其中，比如post參数，这样的事情是不能难倒程序猿的
1.3 HTTP之长/短连接
在http1.0其中是没有connection这个字段的，由于在http1.0其中还是一次请求相应一次连接的，即在server发出相应以后会主动断开连接。这样会
而在http1.1版本号中添加了connection这个字段，而且默认值是keep-alive。它另一个值是close。
keep-alive就是告诉对方这次请求的方式是长连接。即发送对应包以后不要断开连接，即使是错误响应也不要断开连接。
举个样例：
Request
- connection: keep-alive表示这次请求过后请不要断开连接
- connection: close表示这次请求后请断开连接
Response
- connection: keep-alive这次请求以后我不会断开连接
- connection: close 这次请求以后我会断开连接。
所以说究竟request和response其中仅仅要有一个close，就意味着这次请求以后连接会断开。
当第一个request和response对都是keep-alive的时候。一个长连接就建立了。这个时候客户端就能够採用pipeline的方式向server来发包了。pipeline方式指的是client无需等待回应而持续性的发送请求，server会依照request的顺序来回复。
长连接带来了新的问题。
1.3.1 超时保护
假设连接建立以后一直处于inactive的状态怎么办？浪费了server一个fd和client的port。所以须要有超时保护机制，比如在nginx其中能够配置其keepalive_timeout的值。http协议并没有规定server和client的超时时间。能够由开发人员随意指定。
1.3.2 分包协议
在短连接模式的时候。因为每次server响应后直接关闭连接，所以client的短仅仅须要推断EOF来推断response包是否结束。而对于keep alive模式，继续用这样的方式会极大减少效率。所以引入了content-length和transfer-encoding两个字段。
1.4 HTTP之数据报结束符
当客户端请求一个server的静态资源时。server清楚响应的消息长度。所以能够用content-length字段告诉client响应数据的长度。
然而假设请求的是一个动态网页，server预先是不可能知道对应包的长度。所以能够才用transfer-encoding: trunked模式来传递数据，即一边产生数据一边发送。一次对应由多个trunk构成，终于由一个长度为0的trunk标记结束。每一个trunk是一个数据块。在trunk头标记了当前数据块的长度。
2. 什么是Apache和Nginx
假设他们作为http server（当然还有其它的feature），比較简单地理解就是他们是对http协议的一种实现，比如nginx的HTTP模块基本就是依照HTTP协议的RFC文档，把各种情况cover一遍。简单点说。即解包->过滤->转包->过滤->拼包。下图是nginx的一个简要示意图。
3. 一般的web架构是如何的
上图是一个常见的web架构，由反向代理server。httpserver组成。httpserver又分成nginx进程和php进程。
首先，暴露给用户的是一个反向代理server。反向代理的存在有几个作用，一是负载均衡。反向代理server收到数据包以后会依照一定的负载均衡算法转发到真正的业务server上面去，还有一个作用是防止攻击。它会依照一定的规则过滤掉非常多不合法的请求，从而减少业务机的负载，由于其仅仅是简单地转发，没有真正的业务逻辑，所以即使黑客攻击到了这一层也没有太大的危害。同一时候反向代理server也能够缓存一些静态的资源。进一步减少业务机的负载。
nginx作为httpserver，在整个架构中主要负责hold连接。并不做请求的真正处理，在上图中被画成了一个方块。但其本身也是多进程的结构。
假如对同一台机器上面配置了8个nginx worker。每一个worker配置的连接数是1024，那么这台机器hold连接的能力大概是8*1024。
nginx worker和php-fpm的通信方式是通过socket来通信的，所以说nginx和php-fpm能够部署在同一台机器上也能够部署在不同的机器上。
php-fpm是php的一个插件，如今已经集成到了php的核心代码中，是fast-cgi的一种实现。其进程结构和nginx基本类似，都是由一个master进程和多个worker进程构成的。fastcgi规定每过来一个请求，都从进程池里挑选一个进程。来载入并运行一段php脚本，脚本结束以后将进城归还给进程池。所以php-fpm说究竟就是一个进程管理器，正如其名字所看到的（FastCGI Process Manager）。
php-fpm对于其worker进程数的配置由两种static和dynamic。若配置成static表示在fpm启动的时候由master直接fork出max_children的worker数，而且在执行其中这个数字是不变的。
而dynamic则表示依据详细的请求动态的fork worker进程，最大值为max_children。那么，这个max_children该怎样配置呢？假设worker数过少，那么php-fpm收到nginx的数据请求时发现进程池里面已经没有进程了，直接就会拒绝服务，导致此次http请求以502告终。
假设max_children配置过多的话，会占用多余的系统资源，尤其是在static情况下。所以比較适中的办法就是将这个值先配得大一些，然后去观察active的进程数。最后选择一个合适的值。
我们能够看到在fastcgi模式下。一个进程是相应一个请求的，假如说在一台机器上我们配置了300个fastcgi进程，那么其能同一时候处理的最大请求数就是300个，是远远小于nginx的接入能力的。
假设php有一些堵塞调用（如文件上传下载等），当前进程不能处理其它的请求，所以说php-fpm在在这套架构里是瓶颈，怎样在此提高性能是一个值得探讨的问题。
当浏览器出现一个错误页或者白页的时候。有可能是不论什么一个环节出现故障
。这就要慢慢的查了。
