本文首先会 HTTP 的特点和优缺点，而后会具体介绍 HTTP 长连贯和短连贯的连贯治理，通过浏览本文可能对 HTTP 连贯有个深刻的意识。 通过后面的 HTTP 系列文章，想必大家曾经晓得 HTTP 协定的基本知识，理解它的报文构造，申请头、响应头等细节。
HTTP 的特点
所以接下来先是聊聊 HTTP 协定的特点、长处和毛病。既要看到它好的一面，也要正视它不好的一面，只有全方位、多角度理解 HTTP，能力实现“取长补短”，更好地利用 HTTP。
灵便可扩大
首先，HTTP 协定是一个“灵便可扩大”的传输协定。
HTTP 协定最后诞生的时候就比较简单，本着凋谢的精力只规定了报文的根本格局，比方用空格分隔单词，用换行分隔字段，“header+body”等，报文里的各个组成部分都没有做严格的语法语义限度，能够由开发者任意定制。
所以，HTTP 协定就随着互联网的倒退一起成长起来了。在这个过程中，HTTP 协定逐步减少了申请办法、版本号、状态码、头字段等个性。而 body 也不再限于文本模式的 TXT 或 HTML，而是可能传输图片、音频视频等任意数据，这些都是源于它的“灵便可扩大”的特点。
而那些 RFC 文档，实际上也能够了解为是对已有扩大的“抵赖和标准化”，实现了“从实际中来，到实际中去”的良性循环。
也正是因为这个特点，HTTP 能力在三十年的历史长河中“耸立不倒”，从最后的低速试验网络倒退到当初的遍布寰球的高速互联网，始终保持着旺盛的生命力。
牢靠传输
第二个特点，HTTP 协定是一个“牢靠”的传输协定。
这个特点不言而喻，因为 HTTP 协定是基于 TCP/IP 的，而 TCP 自身是一个“牢靠”的传输协定，所以 HTTP 天然也就继承了这个个性，可能在申请方和应答方之间“牢靠”地传输数据。
它的具体做法与 TCP/UDP 差不多，都是对理论传输的数据（entity）做了一层包装，加上一个头，而后调用 Socket API，通过 TCP/IP 协定栈发送或者接管。
不过咱们必须正确地了解“牢靠”的含意，HTTP 并不能 100% 保证数据肯定可能发送到另一端，在网络忙碌、连贯品质差等顽劣的环境下，也有可能收发失败。“牢靠”只是向使用者提供了一个“承诺”，会在上层用多种手段“尽量”保证数据的残缺送达。
当然，如果遇到光纤被意外挖断这样的极其状况，即便是神仙也不能发送胜利。所以，“牢靠”传输是指在网络根本失常的状况下数据收发必然胜利，借用运维里的术语，大略就是“3 个 9”或者“4 个 9”的水平吧。
应用层协定
第三个特点，HTTP 协定是一个应用层的协定。
这个特点也是不言自明的，但却很重要。
在 TCP/IP 诞生后的几十年里，尽管呈现了许多的应用层协定，但它们都仅关注很小的应用领域，局限在很少的利用场景。例如 FTP 只能传输文件、SMTP 只能发送邮件、SSH 只能近程登录等，在通用的数据传输方面“齐全不能打”。
所以 HTTP 凭借着可携带任意头字段和实体数据的报文构造，以及连贯管制、缓存代理等不便易用的个性，一呈现就“技压群雄”，迅速成为了应用层里的“明星”协定。只有不太奢求性能，HTTP 简直能够传递所有货色，满足各种需要，称得上是一个“万能”的协定。
套用一个网上风行的段子，HTTP 齐全能够用开玩笑的口气说：“不要误会，我不是针对 FTP，我是说在座的应用层各位，都是垃圾。”
申请 – 应答
第四个特点，HTTP 协定应用的是申请 – 应答通信模式。
这个申请 – 应答模式是 HTTP 协定最基本的通信模型，艰深来讲就是“一发一收”“有来有去”，就像是写代码时的函数调用，只有填好申请头里的字段，“调用”后就会收到回答。
申请 – 应答模式也明确了 HTTP 协定里通信单方的定位，永远是申请方先发动连贯和申请，是被动的，而应答方只有在收到申请后能力回答，是被动的，如果没有申请时不会有任何动作。
当然，申请方和应答方的角色也不是相对的，在浏览器 – 服务器的场景里，通常服务器都是应答方，但如果将它用作代理连贯后端服务器，那么它就可能同时表演申请方和应答方的角色。
HTTP 的申请 – 应答模式也恰好符合了传统的 C/S（Client/Server）零碎架构，申请方作为客户端、应答方作为服务器。所以，随着互联网的倒退就呈现了 B/S（Browser/Server）架构，用轻量级的浏览器代替轻便的客户端利用，实现零保护的“瘦”客户端，而服务器则摈弃公有通信协议转而应用 HTTP 协定。
此外，申请 – 应答模式也完全符合 RPC（Remote Procedure Call）的工作模式，能够把 HTTP 申请解决封装成近程函数调用，导致了 WebService、RESTful 和 gPRC 等的呈现。
无状态
第五个特点，HTTP 协定是无状态的。这个所谓的“状态”应该怎么了解呢？
“状态”其实就是客户端或者服务器里保留的一些数据或者标记，记录了通信过程中的一些变动信息。
你肯定晓得，TCP 协定是有状态的，一开始处于 CLOSED 状态，连贯胜利后是 ESTABLISHED 状态，断开连接后是 FIN-WAIT 状态，最初又是 CLOSED 状态。
这些“状态”就须要 TCP 在外部用一些数据结构去保护，能够简略地设想成是个标记量，标记以后所处的状态，例如 0 是 CLOSED，2 是 ESTABLISHED 等等。
再来看 HTTP，那么比照一下 TCP 就看进去了，在整个协定里没有规定任何的“状态”，客户端和服务器永远是处在一种“无知”的状态。建设连贯前两者互不知情，每次收发的报文也都是相互独立的，没有任何的分割。收发报文也不会对客户端或服务器产生任何影响，连贯后也不会要求保留任何信息。
“无状态”形象地来说就是“没有记忆能力”。比方，浏览器发了一个申请，说“我是小明，请给我 A 文件。”，服务器收到报文后就会检查一下权限，看小明的确能够拜访 A 文件，于是把文件发回给浏览器。接着浏览器还想要 B 文件，但服务器不会记录方才的申请状态，不晓得第二个申请和第一个申请是同一个浏览器发来的，所以浏览器必须还得反复一次本人的身份才行：“我是方才的小明，请再给我 B 文件。”
咱们能够再比照一下 UDP 协定，不过它是无连贯也无状态的，程序发包乱序收包，数据包收回去后就不论了，收到后也不会程序整顿。而 HTTP 是有连贯无状态，程序发包程序收包，依照收发的程序治理报文。
但不要忘了 HTTP 是“灵便可扩大”的，尽管规范里没有规定“状态”，但齐全可能在协定的框架里给它“打个补丁”，减少这个个性。
其余特点
除了以上的五大特点，其实 HTTP 协定还能够列出十分多的特点，例如传输的实体数据可缓存可压缩、可分段获取数据、反对身份认证、反对国际化语言等。但这些并不能算是 HTTP 的根本特点，因为这都是由第一个“灵便可扩大”的特点所衍生进去的。
小结
- HTTP 是灵便可扩大的，能够任意增加头字段实现任意性能；
- HTTP 是牢靠传输协定，基于 TCP/IP 协定“尽量”保证数据的送达；
- HTTP 是应用层协定，比 FTP、SSH 等更通用性能更多，可能传输任意数据；
- TTP 应用了申请 – 应答模式，客户端被动发动申请，服务器被动回复申请；
- HTTP 实质上是无状态的，每个申请都是相互独立、毫无关联的，协定不要求客户端或服务器记录申请相干的信息。
HTTP 的连贯治理
HTTP 的连贯治理也算得上是个“陈词滥调”的话题了，你肯定已经据说过“短连贯”“长连贯”之类的名词，明天让咱们一起来把它们弄清楚。
短连贯
HTTP 协定最后（0.9/1.0）是个非常简单的协定，通信过程也采纳了简略的“申请 – 应答”形式。
它底层的数据传输基于 TCP/IP，每次发送申请前须要先与服务器建设连贯，收到响应报文后会立刻敞开连贯。
因为客户端与服务器的整个连贯过程很短暂，不会与服务器放弃长时间的连贯状态，所以就被称为“短连贯”（short-lived connections）。晚期的 HTTP 协定也被称为是“无连贯”的协定。
短连贯的毛病相当严重，因为在 TCP 协定里，建设连贯和敞开连贯都是十分“低廉”的操作。TCP 建设连贯要有“三次握手”，发送 3 个数据包，须要 1 个 RTT；敞开连贯是“四次挥手”，4 个数据包须要 2 个 RTT。
而 HTTP 的一次简略“申请 – 响应”通常只须要 4 个包，如果不算服务器外部的解决工夫，最多是 2 个 RTT。这么算下来，节约的工夫就是“3÷5=60%”，有三分之二的工夫被节约掉了，传输效率低得惊人。
单纯地从实践上讲，TCP 协定你可能还不太好了解，我就拿打卡考勤机来做个形象的比喻吧。
假如你的公司买了一台打卡机，放在前台，因为这台机器比拟贵，所以专门做了一个爱护罩盖着它，公司要求每次上下班打卡时都要先关上盖子，打卡后再盖上盖子。
可是偏偏这个盖子十分牢固，关上敞开要费很大力量，打卡可能只有 1 秒钟，而开关盖子却须要四五秒钟，大部分工夫都节约在了毫无意义的开关盖子操作上了。
可想而知，平时还好说，一到上下班的点在打卡机前就会排起长队，每个人都要反复“开盖 – 打卡 – 关盖”的三个步骤，你说焦急不焦急。
在这个比喻里，打卡机就相当于服务器，盖子的开关就是 TCP 的连贯与敞开，而每个打卡的人就是 HTTP 申请，很显然，短连贯的毛病重大制约了服务器的服务能力，导致它无奈解决更多的申请。
长连贯
针对短连贯暴露出的毛病，HTTP 协定就提出了“长连贯”的通信形式，也叫“长久连贯”（persistent connections）、“连贯保活”（keep alive）、“连贯复用”（connection reuse）。
其实解决办法也很简略，用的就是“老本均摊”的思路，既然 TCP 的连贯和敞开十分耗时间，那么就把这个工夫老本由原来的一个“申请 – 应答”均摊到多个“申请 – 应答”上。
这样尽管不能改善 TCP 的连贯效率，但基于“分母效应”，每个“申请 – 应答”的有效工夫就会升高不少，整体传输效率也就进步了。
这里我画了一个短连贯与长连贯的比照示意图。在短连贯里发送了三次 HTTP“申请 – 应答”，每次都会节约 60% 的 RTT 工夫。而在长连贯的状况下，同样发送三次申请，因为只在第一次时建设连贯，在最初一次时敞开连贯，所以节约率就是“3÷9≈33%”，升高了差不多一半的工夫损耗。显然，如果在这个长连贯上发送的申请越多，分母就越大，利用率也就越高。
持续用方才的打卡机的比喻，公司也感觉这种重复“开盖 – 打卡 – 关盖”的操作太“反人类”了，于是颁布了新规定，早上关上盖子后就不必关上了，能够自在打卡，到上班后再关上盖子。
这样打卡的效率（即服务能力）就大幅度晋升了，原来一次打卡须要五六秒钟，当初只有一秒就能够了，上下班时排长队的现象一去不返，大家都开心。
连贯相干的头字段
因为长连贯对性能的改善成果十分显著，所以在 HTTP/1.1 中的连贯都会默认启用长连贯。不须要用什么非凡的头字段指定，只有向服务器发送了第一次申请，后续的申请都会反复利用第一次关上的 TCP 连贯，也就是长连贯，在这个连贯上收发数据。
当然，咱们也能够在申请头里明确地要求应用长连贯机制，应用的字段是 Connection，值是“keep-alive”。
不过不论客户端是否显式要求长连贯，如果服务器反对长连贯，它总会在响应报文里放一个“Connection: keep-alive”字段，通知客户端：“我是反对长连贯的，接下来就用这个 TCP 始终收发数据吧”。
不过长连贯也有一些小毛病，问题就出在它的“长”字上。
因为 TCP 连贯长时间不敞开，服务器必须在内存里保留它的状态，这就占用了服务器的资源。如果有大量的闲暇长连贯只连不发，就会很快耗尽服务器的资源，导致服务器无奈为真正有须要的用户提供服务。
所以，长连贯也须要在失当的工夫敞开，不能永远放弃与服务器的连贯，这在客户端或者服务器都能够做到。
在客户端，能够在申请头里加上“Connection: close”字段，通知服务器：“这次通信后就敞开连贯”。服务器看到这个字段，就晓得客户端要被动敞开连贯，于是在响应报文里也加上这个字段，发送之后就调用 Socket API 敞开 TCP 连贯。
服务器端通常不会被动敞开连贯，但也能够应用一些策略。拿 Nginx 来举例，它有两种形式：
- 应用“keepalive_timeout”指令，设置长连贯的超时工夫，如果在一段时间内连贯上没有任何数据收发就被动断开连接，防止闲暇连贯占用系统资源。
- 应用“keepalive_requests”指令，设置长连贯上可发送的最大申请次数。比方设置成 1000，那么当 Nginx 在这个连贯上解决了 1000 个申请后，也会被动断开连接。
另外，客户端和服务器都能够在报文里附加通用头字段“Keep-Alive: timeout=value”，限定长连贯的超时工夫。但这个字段的约束力并不强，通信的单方可能并不会恪守，所以不太常见。
队头阻塞
看完了短连贯和长连贯，接下来就要说到驰名的“队头阻塞”（Head-of-line blocking，也叫“队首阻塞”）了。
“队头阻塞”与短连贯和长连贯无关，而是由 HTTP 根本的“申请 – 应答”模型所导致的。
因为 HTTP 规定报文必须是“一发一收”，这就造成了一个先进先出的“串行”队列。队列里的申请没有轻重缓急的优先级，只有入队的先后顺序，排在最后面的申请被最优先解决。
如果队首的申请因为解决的太慢耽搁了工夫，那么队列里前面的所有申请也不得不跟着一起期待，后果就是其余的申请承当了不应有的工夫老本。 还是用打卡机做个比喻。
下班的工夫点上，大家都在排队打卡，可这个时候偏偏最后面的那个人遇到了打卡机故障，怎么也不能打卡胜利，急得满头大汗。等找人把打卡机修好，前面排队的所有人全早退了。
性能优化
因为“申请 – 应答”模型不能变，所以“队头阻塞”问题在 HTTP/1.1 里无奈解决，只能缓解，有什么方法呢？
公司里能够再多买几台打卡机放在前台，这样大家能够不必挤在一个队伍里，扩散打卡，一个队伍偶然阻塞也不要紧，能够更换到其余不阻塞的队伍。
这在 HTTP 里就是“并发连贯”（concurrent connections），也就是同时对一个域名发动多个长连贯，用数量来解决品质的问题。
但这种形式也存在缺点。如果每个客户端都想本人快，建设很多个连贯，用户数×并发数就会是个天文数字。服务器的资源基本就扛不住，或者被服务器认为是歹意攻打，反而会造成“拒绝服务”。
所以，HTTP 协定倡议客户端应用并发，但不能“滥用”并发。RFC2616 里明确限度每个客户端最多并发 2 个连贯。不过实践证明这个数字切实是太小了，泛滥浏览器都“忽视”规范，把这个下限进步到了 6~8。起初订正的 RFC7230 也就“因势利导”，勾销了这个“2”的限度。
但“并发连贯”所压迫出的性能也跟不上高速倒退的互联网无止境的需要，还有什么别的方法吗？
公司倒退的太快了，员工越来越多，上下班打卡成了火烧眉毛的大问题。前台空间无限，放不下更多的打卡机了，怎么办？那就多开几个打卡的中央，每个楼层、办公区的入口也放上三四台打卡机，把人进一步分流，不要都往前台挤。
这个就是“域名分片”（domain sharding）技术，还是用数量来解决品质的思路。
HTTP 协定和浏览器不是限度并发连贯数量吗？好，那我就多开几个域名，比方 shard1.chrono.com、shard2.chrono.com，而这些域名都指向同一台服务器 www.chrono.com，这样理论长连贯的数量就又下来了，真是“美滋滋”。不过切实是有点“上有政策，下有对策”的滋味。
小结
这一讲中咱们学习了 HTTP 协定里的短连贯和长连贯，简略小结一下明天的内容：
- 晚期的 HTTP 协定应用短连贯，收到响应后就立刻敞开连贯，效率很低；
- HTTP/1.1 默认启用长连贯，在一个连贯上收发多个申请响应，进步了传输效率；
- 服务器会发送“Connection: keep-alive”字段示意启用了长连贯；
- 报文头里如果有“Connection: close”就意味着长连贯行将敞开；
- 过多的长连贯会占用服务器资源，所以服务器会用一些策略有选择地敞开长连贯；
- “队头阻塞”问题会导致性能降落，能够用“并发连贯”和“域名分片”技术缓解。
原文：https://www.cnblogs.com/huans…