• http
• https

HTTP

TIP

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。。 HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

HTTP工作原理 HTTP三点注意事项：

HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。 HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

其中，1,2,3表示请求行，4请求体，5请求体。

HTTP状态码

常见状态码：

2开头 （请求成功）表示成功处理了请求的状态代码

• 200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
• 201 （已创建） 请求成功并且服务器创建了新的资源。
• 202 （已接受） 服务器已接受请求，但尚未处理。
• 203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
• 204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
• 205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
• 206 （部分内容） 服务器成功处理了部分 GET 请求。

3开头（请求被重定向）表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

• 300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent)选择一项操作，或提供操作列表供请求者选择。
• 301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD请求的响应）时，会自动将请求者转到新位置。
• 302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
• 303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
• 304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
• 305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
• 307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4开头 （请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。

• 400 （错误请求） 服务器不理解请求的语法。
• 401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
• 403 （禁止） 服务器拒绝请求。
• 404 （未找到） 服务器找不到请求的网页。
• 405 （方法禁用） 禁用请求中指定的方法。
• 406 （不接受） 无法使用请求的内容特性响应请求的网页。
• 407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
• 408 （请求超时） 服务器等候请求时发生超时。
• 409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
• 410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
• 411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
• 412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
• 413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
• 414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
• 415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
• 416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
• 417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。

5开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

• 500 （服务器内部错误） 服务器遇到错误，无法完成请求。
• 501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
• 502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
• 503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
• 504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
• 505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

GET&POST

HTTP 请求方法

HTTP 1/2

TIP

https://www.cnblogs.com/heluan/p/8620312.html 二、HTTP的基本优化

影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。

带宽：如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。

延迟：

浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。

DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用DNS缓存结果来达到减少这个时间的目的。

建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

三、HTTP1.0和HTTP1.1的一些区别

TIP

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

四、HTTPS与HTTP的一些区别

TIP

HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。

HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。 五、SPDY：HTTP1.x的优化

2012年google如一声惊雷提出了SPDY的方案，优化了HTTP1.X的请求延迟，解决了HTTP1.X的安全性，具体如下：

降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。

请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。

header压缩。前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。

基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。

服务端推送（server push），采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。SPDY构成图：

SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议(将HTTP1.x的内容封装成一种新的frame格式)，同时可以使用已有的SSL功能。

六、HTTP2.0性能惊人

TIP

HTTP/2: the Future of the Internet https://link.zhihu.com/?target=https://http2.akamai.com/demo 是 Akamai 公司建立的一个官方的演示，用以说明 HTTP/2 相比于之前的 HTTP/1.1 在性能上的大幅度提升。 同时请求 379 张图片，从Load time 的对比可以看出 HTTP/2 在速度上的优势。

七、HTTP2.0：SPDY的升级版

TIP

HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方，如下：

HTTP2.0和SPDY的区别：

HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS

HTTP2.0 消息头的压缩算法采用 HPACK http://http2.github.io/http2-spec/compression.html，而非 SPDY 采用的 DEFLATE http://zh.wikipedia.org/wiki/DEFLATE

八、HTTP2.0和HTTP1.X相比的新特性

TIP

新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。

多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

九、HTTP2.0的升级改造

TIP

前文说了HTTP2.0其实可以支持非HTTPS的，但是现在主流的浏览器像chrome，firefox表示还是只支持基于 TLS 部署的HTTP2.0协议，所以要想升级成HTTP2.0还是先升级HTTPS为好。

当你的网站已经升级HTTPS之后，那么升级HTTP2.0就简单很多，如果你使用NGINX，只要在配置文件中启动相应的协议就可以了，可以参考NGINX白皮书，NGINX配置HTTP2.0官方指南 https://www.nginx.com/blog/nginx-1-9-5/。

使用了HTTP2.0那么，原本的HTTP1.x怎么办，这个问题其实不用担心，HTTP2.0完全兼容HTTP1.x的语义，对于不支持HTTP2.0的浏览器，NGINX会自动向下兼容的。

十、附注

TIP

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行； 具体如图：

服务器推送到底是什么？ 服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。具体如下：

普通的客户端请求过程：

服务端推送的过程：

为什么需要头部压缩？ 假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：HTTP/2 头部压缩技术介绍

HTTP2.0多路复用有多好？ HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。 HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

十一、参考

TIP

HTTP/2.0 相比1.0有哪些重大改进？ 深入研究：HTTP2 的真正性能到底如何 HTTP/2 头部压缩技术介绍

SPDY

TIP

SPDY（读作“SPeeDY”）是Google开发的基于TCP的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。

CGI

TIP

公共网关接口（Common Gateway Interface，CGI）是Web 服务器运行时外部程序的规范，按CGI 编写的程序可以扩展服务器功能。CGI 应用程序能与浏览器进行交互，还可通过数据API与数据库服务器等外部数据源进行通信，从数据库服务器中获取数据。格式化为HTML文档后，发送给浏览器，也可以将从浏览器获得的数据放到数据库中。几乎所有服务器都支持CGI，可用任何语言编写CGI，包括流行的C、C ++、VB 和Delphi 等。CGI分为标准CGI和间接CGI两种。标准CGI使用命令行参数或环境变量表示服务器的详细请求，服务器与浏览器通信采用标准输入输出方式。间接CGI又称缓冲CGI，在CGI程序和CGI接口之间插入一个缓冲程序，缓冲程序与CGI接口间用标准输入输出进行通信

CGI（Common Gateway Interface）公共网关接口，是外部扩展应用程序与 Web 服务器交互的一个标准接口。服务器端与客户端进行交互的常见方式多，CGI 技术就是其中之一。根据CGI标准，编写外部扩展应用程序，可以对客户端浏览器输入的数据进行处理，完成客户端与服务器的交互操作。CGI规范定义了Web服务器如何向扩展应用程序发送消息，在收到扩展应用程序的信息后又如何进行处理等内容。对于许多静态的HTML网页无法实现的功能，通过 CGI可以实现，比如表单的处理、对数据库的访问、搜索引擎、基于Web的数据库访问等等。使用CGI实现客户端与服务器的交互有以下几个标准步骤，具体步骤如下： （1）Web 客户端的浏览器将URL的第一部分解码与Web服务器相连。 （2）Web 浏览器将URL的其余部分提供给服务器。 （3）Web 服务器将URL转换成路径和文件名。 （4）Web 服务器发送 HTML 和别的组成请求页面的文件给客户。一旦页面内容传送完， 这个连接自动断开。 （5）在客户端，HTML脚本提示用户做动作或输入。当用户响应后，客户请求Web服务器建立一个新的连接。 （6）Web 服务器把这些信息和别的进程变量传送给由HTML以URL的形式指定CGI程序。 （7）CGI 根据输入作出响应，把响应结果传送给 Web 服务器。 （8）Web 服务器把响应的数据传给客户，完成后关闭连接。 服务器端 CGI 程序接收信息有三种途径：环境变量、命令行和标准输入。其中环境变量是指 CGI 定义一组环境变量，通过环境变量可传递数据。服务器收到来自浏览器的数据，调用 CGI 脚本，CGI 脚本将收到的数据转换成环境变量并从中取出所需要的内容。< form >标签的 METHOD 属性来决定具体使用哪一种方法。在“METHOD=GET”时，向 CGI 传递表单编码信息的是通过命令来进行的。表单编码信息大多数是通过环境变量 QUERY_STRING 来传递的。若“METHOD=POST”，表单信息通过标准输入来读取。还有一种不使用表单就可以向 CGI 传送信息的方法，那就是把信息直接附在 URL 地址后面，信息和URL 之间用问号（?）来进行分隔。GET 方法是对数据的一个请求，被用于获得静态文档。GET 方法通过将发送请求信息附加在 URL 后面的参数。当 GET 方法被使用时，CGI 程序将会从环境变量 QUERY_STRING获取数据。为了正确的响应客户端发来的请求，CGI 必须对 QUERY_STRING 中的字符串进行分析。当用户需要从服务器获取数据，但服务器上的数据不得改变时，应该用 GET 方法；但是如果请求中的字符串超过了一定长度，通常是 1024 字节，那么这时，只能用 POST 方法。POST 方法：浏览器将通过填写表单将数据传给服务器时一般采用POST 方法。在发送的数据超过 1024 字节时必须采用 POST 方法。当 POST 方法被使用时，Web 服务器向CGI 程序的标准输入 STDIN 传送数据。环境变量 CONTENT_LENGTH 存放着发送的数据长度。CGI 程序必须检查环境变量 REQUEST_METHOD 以确定有没有采用了 POST 方法，并决定是否要读取标准输入STDIN

FastCGI

TIP

由于CGI解释器的反复加载会使CGI性能低下，FastCGI可以将CGI解释器保持在内存中， 提高性能 相关地址：https://fastcgi-archives.github.io 2. Fastcgi特点：

性能 简单，容易移植 语言无关 进程隔离 通用性，主流WebServer都支持，nginx、apache都支持 支持分布式计算，FastCGI提供远程运行应用程序的功能，这对于分发负载和管理外部Web站点非常有用（这点待验证是否好用，我希望的能支持异步处理）

3. 原理

简单来说，利用后面说的spawn-fcgi（fastcgi的管理程序）启动fastcgi，支持启动多实例，并通过socket进行数据绑定 WebServer（如：nginx）在收到请求后，根据配置中配置要转发的fastcgi地址，发到固定的地址，例如：fastcgi绑定的是127.0.0.1：8088 fastcgi Accept并处理数据后，将响应数据通过Socket返回给WebServer，并断开连接，这时表示一次处理完成

管理程序 -- spawn-fcgi 下载地址：http://redmine.lighttpd.net/projects/spawn-fcgi/wiki -f 指定调用 FastCGI的进程的执行程序位置 -a 绑定到 地址addr。 -p 绑定到 端口 port。 -s 绑定到 unix domain socket -C 指定产 生的FastCGI的进程数， 默认为 5。 （ 仅用 于PHP） -P 指定产 生的进程的PID文件路径。 -F 指定产 生的FastCGI的进程数（ C的CGI用 这个） 例子：./spawn-fcgi -a 127.0.0.1 -p 8088 -F 500 -f cgi（启动500个cgi程序，监听的端口为8088，绑定地址为127.0.0.1） 4. nginx如何配置

fastcgi_pass fastcgi_pass address; address为后端的fastcgi server的地址 可用位置：location,if in location fastcgi_index fastcgi_index name; fastcgi默认的主页资源 示例：fastcgi_index index.php; fastcgi_param fastcgi_param parameter value [if_not_empty]; 设置传递给FastCGI服务器的参数值，可以是文本，变量或组合

5. 阻塞与非阻塞模式 fastcgi示例 -- 阻塞模式

#include "fcgi_stdio.h"
#include <stdlib.h>

void main(void)
{
    int count = 0;
    while(FCGI_Accept() >= 0)
        printf("Content-type: text/html\r\n"
               "\r\n"
               "<title>FastCGI Hello!</title>"
               "<h1>FastCGI Hello!</h1>"
               "Request number %d running on host <i>%s</i>\n",
                ++count, getenv("SERVER_NAME"));
}

fastcgi示例 -- 生产者，消费者模式（可实现非阻塞） 非阻塞的实现，将会话状态与requests进行binding即可 ZEN_Message_Queue_Deque<ZEN_MT_SYNCH, uint32_t> t_que(100000);

// 这步非常关键，因为FCGX_Accept_r中的数据流绑定是直接和request的ptr进行绑定的 // 所以在未处理完数据的前提下，requests的生命周期要和会话的生命周期一致

FCGX_Request requests[1000];
uint32_t use_idx[1000];

void *do_session(void *arg)
{
    int ret = 0;

    while (1)
    {
        uint32_t idx = 0;
        ret = t_que.try_dequeue(idx);

        if (ret != 0)
        {
            // no data sleep 1ms
            usleep(1000);
            continue;
        }

        FCGX_Request &request = requests[idx];
        std::string out = "Content-type:application/json\r\n\r\n";
        Json::Value root;
        root["ret"] = 1000;
        root["t_id"] = (int)gettid();
        out.append(root.toStyledString());
        FCGX_FPrintF(request.out, out.c_str());
        FCGX_Finish_r(&request);
        use_idx[idx] = 0;
    }

    return NULL;
}

int get_free()
{
    static uint32_t idx = 0;

    for (; idx < 1000; idx ++)
    {
        if (use_idx[idx] == 0)
        {
            use_idx[idx] = 1;
            return idx;
        }
    }

    return -1;
}

int main(int argc, char **argv)
{
    pthread_t pthread_id;
    int iThreadNum = 10;

    for (int index = 0; index != iThreadNum; ++ index)
    {
       pthread_create(&pthread_id, NULL, do_session, NULL);
    }

    memset(use_idx, 0, sizeof(use_idx));
    int ret = FCGX_Init();

    if (ret != 0)
    {
        printf("init fail\n");
        return -1;
    }

    while (1)
    {
        int idx = get_free();

        if (idx < 0)
        {
            continue;
        }

        FCGX_Request &request = requests[idx];
        ret = FCGX_InitRequest(&request, 0, 0);

        if (ret != 0)
        {
            printf("init fail\n");
            return -1;
        }

        ret = FCGX_Accept_r(&request);

        if (ret < 0)
        {
            continue;
        }

        t_que.enqueue(idx);
    }

    return 0;
}

作者：动静之逸 链接：https://www.jianshu.com/p/c8d65fb1941d 来源：简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Nginx

TIP

https://www.cnblogs.com/wcwnina/p/8728391.html Nginx的产生 没有听过Nginx？那么一定听过它的"同行"Apache吧！Nginx同Apache一样都是一种WEB服务器。基于REST架构风格，以统一资源描述符(Uniform Resources Identifier)URI或者统一资源定位符(Uniform Resources Locator)URL作为沟通依据，通过HTTP协议提供各种网络服务。

然而，这些服务器在设计之初受到当时环境的局限，例如当时的用户规模，网络带宽，产品特点等局限并且各自的定位和发展都不尽相同。这也使得各个WEB服务器有着各自鲜明的特点。

Apache的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多优点：稳定、开源、跨平台等等。它出现的时间太长了，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。它不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。

这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。

俄罗斯的工程师Igor Sysoev，他在为Rambler Media工作期间，使用C语言开发了Nginx。Nginx作为WEB服务器一直为Rambler Media提供出色而又稳定的服务。

然后呢，Igor Sysoev将Nginx代码开源，并且赋予自由软件许可证。

由于：

Nginx使用基于事件驱动架构，使得其可以支持数以百万级别的TCP连接 高度的模块化和自由软件许可证使得第三方模块层出不穷（这是个开源的时代啊~） Nginx是一个跨平台服务器，可以运行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操作系统上 这些优秀的设计带来的是极大的稳定性 所以，Nginx火了！

Nginx的用武之地 Nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器；同时也是一个IMAP、POP3、SMTP代理服务器；Nginx可以作为一个HTTP服务器进行网站的发布处理，另外Nginx可以作为反向代理进行负载均衡的实现。

关于代理 说到代理，首先我们要明确一个概念，所谓代理就是一个代表、一个渠道；

此时就涉及到两个角色，一个是被代理角色，一个是目标角色，被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程；如同生活中的专卖店~客人到adidas专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是adidas厂家，目标角色就是用户。

正向代理 说反向代理之前，我们先看看正向代理，正向代理也是大家最常接触的到的代理模式，我们会从两个方面来说关于正向代理的处理模式，分别从软件方面和生活方面来解释一下什么叫正向代理。

在如今的网络环境下，我们如果由于技术需要要去访问国外的某些网站，此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的，此时大家可能都会用一个操作FQ进行访问，FQ的方式主要是找到一个可以访问国外网站的代理服务器，我们将请求发送给代理服务器，代理服务器去访问国外的网站，然后将访问到的数据传递给我们！

上述这样的代理模式称为正向代理，正向代理最大的特点是客户端非常明确要访问的服务器地址；服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端；正向代理模式屏蔽或者隐藏了真实客户端信息。来看个示意图（我把客户端和正向代理框在一块，同属于一个环境，后面我有介绍）：

总结来说：正向代理，"它代理的是客户端，代客户端发出请求"，是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。 客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。如图。

正向代理的用途： （1）访问原来无法访问的资源，如Google （2） 可以做缓存，加速访问资源 （3）对客户端访问授权，上网进行认证 （4）代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理 明白了什么是正向代理，我们继续看关于反向代理的处理方式，举例如我大天朝的某宝网站，每天同时连接到网站的访问人数已经爆表，单个服务器远远不能满足人民日益增长的购买欲望了，此时就出现了一个大家耳熟能详的名词：分布式部署；也就是通过部署多台服务器来解决访问人数限制的问题；某宝网站中大部分功能也是直接使用Nginx进行反向代理实现的，并且通过封装Nginx和其他的组件之后起了个高大上的名字：Tengine，有兴趣的童鞋可以访问Tengine的官网查看具体的信息：http://tengine.taobao.org/。那么反向代理具体是通过什么样的方式实现的分布式的集群操作呢，我们先看一个示意图（我把服务器和反向代理框在一块，同属于一个环境，后面我有介绍）：

通过上述的图解大家就可以看清楚了，多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx扮演的就是一个反向代理角色。

客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。

反向代理，"它代理的是服务端，代服务端接收请求"，主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息。

反向代理的作用： （1）保证内网的安全，通常将反向代理作为公网访问地址，Web服务器是内网 （2）负载均衡，通过反向代理服务器来优化网站的负载

项目场景 通常情况下，我们在实际项目操作时，正向代理和反向代理很有可能会存在在一个应用场景中，正向代理代理客户端的请求去访问目标服务器，目标服务器是一个反向单利服务器，反向代理了多台真实的业务处理服务器。具体的拓扑图如下：

二者区别 截了一张图来说明正向代理和反向代理二者之间的区别，如图。

在正向代理中，Proxy和Client同属于一个LAN（图中方框内），隐藏了客户端信息；

在反向代理中，Proxy和Server同属于一个LAN（图中方框内），隐藏了服务端信息；

实际上，Proxy在两种代理中做的事情都是替服务器代为收发请求和响应，不过从结构上看正好左右互换了一下，所以把后出现的那种代理方式称为反向代理了。

负载均衡 我们已经明确了所谓代理服务器的概念，那么接下来，Nginx扮演了反向代理服务器的角色，它是以依据什么样的规则进行请求分发的呢？不用的项目应用场景，分发的规则是否可以控制呢？

这里提到的客户端发送的、Nginx反向代理服务器接收到的请求数量，就是我们说的负载量。

请求数量按照一定的规则进行分发到不同的服务器处理的规则，就是一种均衡规则。

所以~将服务器接收到的请求按照规则分发的过程，称为负载均衡。

负载均衡在实际项目操作过程中，有硬件负载均衡和软件负载均衡两种，硬件负载均衡也称为硬负载，如F5负载均衡，相对造价昂贵成本较高，但是数据的稳定性安全性等等有非常好的保障，如中国移动中国联通这样的公司才会选择硬负载进行操作；更多的公司考虑到成本原因，会选择使用软件负载均衡，软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。

Nginx支持的负载均衡调度算法方式如下：

weight轮询(默认，常用)：接收到的请求按照权重分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值(weight)，用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。 ip_hash（常用）：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。 fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是Nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块。 url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在Nginx作为静态服务器的情况下提高缓存效率。同样要注意Nginx默认不支持这种调度算法，要使用的话需要安装Nginx的hash软件包。 几种常用web服务器对比

对比项(服务器)	Apache	Nginx	Lighttpd
Proxy代理	非常好	非常好	一般
Rewriter	好	非常好	一般
Fcgi	不好	好	非常好
热部署	不支持	支持	不支持
系统压力	很大	很小	比较小
稳定性	好	非常好	不好
安全性	好	一般	一般
静态文件处理	一般	非常好	好
反向代理	一般	非常好	一般

TIP

HTTP POST & GET

TIP

1.GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头＜request-line＞中），以?分割URL和传输数据，多个参数用&连接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

POST提交：把提交的数据放置在是HTTP包的包体＜request-body＞中。上文示例中红色字体标明的就是实际的传输数据

因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变

2.传输数据的大小：

首先声明,HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。 而在实际开发中存在的限制主要有：

GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

因此对于GET提交时，传输数据就会受到URL长度的限制。

POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都有各自的配置。

3.安全性：

POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码

状态码

TIP

当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。 HTTP状态码的英文为HTTP Status Code。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。

1xx：指示信息--表示请求已接收，继续处理。 2xx：成功--表示请求已被成功接收、理解、接受。 3xx：重定向--要完成请求必须进行更进一步的操作。 4xx：客户端错误--请求有语法错误或请求无法实现。 5xx：服务器端错误--服务器未能实现合法的请求。

常见状态代码、状态描述的说明如下。

200 OK：客户端请求成功。 400 Bad Request：客户端请求有语法错误，不能被服务器所理解。 401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。 403 Forbidden：服务器收到请求，但是拒绝提供服务。 404 Not Found：请求资源不存在，举个例子：输入了错误的URL。 500 Internal Server Error：服务器发生不可预期的错误。 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，举个例子：HTTP/1.1 200 OK（CRLF）。