在两台计算机之间使用 HTTP 协议通信时，在一条通信线路上必定有 一端是客户端，另一端则是服务器端。
仅从一条通信路线来说，服务器端和客户端的角色是 确定的，而用 HTTP 协议能够明确区分哪端是客户端，哪端是服务器 端。
报文的传送方式由首部字段来决定，不同的首部字段代表不同的含义与功能。
对于前端开发者来说，掌握一些常用的首部字段的含义是很有必要的。
具体headers含义可参考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers
http协议无状态的原因： 这是为了 更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设 计成如此简单的。如果让服务器管理全部客户端状态， 服务器则会负担很大压力
但是有时候我们又需要记录用户的状态，这时候就引入了Cookie的技术。
Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
Cookie 会根据从 服务器 端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出 去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一 个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。
HTTP 协议使用 URI 定位互联网上的资源。
HTTP 协议使用 URI 让客户端定位到资源
GET 方法用来请求 访问已被 URI 识别的资源 。
指定的资源经服务器 端解析后返回响应内容。
POST 方法用来传输实体的主体
虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。
获得报文首部，用于确认 URI 的有效性及资源更新的日期时间等。
用来查询针对请求 URI 指定的资源支持的方法
PUT 方法用来传输文件。
要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置
但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。
用来删除文件。
但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。
通过请求头中的Max-Forwards填入数值，每经过一个服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最后接收到请求的服务器端则返回状态码 200 OK 的响应。
客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。
TRACE方法容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常不会用到。
CONNECT 方法的格式
CONNECT 代理服务器名:端口号 HTTP版本
以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使 这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的 情况多了起来。 比如，使用浏览器浏览一个包含多张图片的 HTML页面时，在发送 请求访问 HTML页面资源的同时，也会请求该 HTML页面里包含的 其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断 开，增加通信量的开销。
（ 网络的发展， 从容量小的文本传输->包含大量图片的HTML页面，图片的请求、资源的请求都会导致TCP的连接建立和断开，增加通信的开销 ）
注意，Connection: Keep-Alive首部只是请求将连接保持在活跃状态。即使服务器和客户端都同意建立持久连接了，它们仍可以在任意时刻关闭空闲的keep-alive连接，且可随意限制keep-alive连接所处理事务的数量。我们可以通过Keep-Alive选项调节它们的行为:
用法 ：Keep-Alive: name[=value][, name=[value]]...
完全可选，但 只有在包含了Connection: Keep-Alive首部的情况下才可使用它 。
参数timeout ：在Keep-Alive响应首部中发送，告诉客户端服务器估计会在打开状态保持到连接空闲多长时间后关闭连接。
参数max ：在Keep-Alive响应首部中发送，告诉客户端服务器还会为另外几个http事务将连接保持在打开状态。
注意，这两个参数值仅仅是估计，并非承诺。
说明服务器最多还会为另外5个事务保持连接在打开状态，或者将打开状态保持到连接空闲了2两分钟后关闭。
HTTP/1.1逐渐停止了对keep-alive连接的支持，用persistent连接替代了它。
一个web页面中内嵌的图片通常都来自同一个Web站点，而且相当一部分的超链接都指向同一个站点。如果初始化了一个持久连接，我们就可以通过此连接发起更多目标服务器相同的请求。
HTTP/1.1的新特性，允许在持久连接上可选地使用请求管道。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在髙时延网络条件下，这样做可以降低网络的环回时间，提高性能。
管道化连接有如下几条限制：
参考资料：