一、HTTP 请求内容
由于最新的 http2，并没有被各大浏览器广泛使用，所以本文是基于 http/1.1 所编写的。同时经过检测我们也发现，chrome 等浏览器也正是使用 http/1.1 版本的。
关于 http/1.1 协议的详情，可查看官方文档
我们打开 chrome 的 network，点击任何一条 request 请求，即可发现，每个 http headers 都包含以下部分:Genaral，Response Headers，
General(不属于 headers，只用于收集请求 url 和响应的 status 等信息)
Request Headers(请求 headers)
Response Headers(响应 headers)
Request Payload(请求参数)
二、HTTP Headers 分类
在 http heanders 中，为了方便，分为以下几类：Genaral headers(和上面说的 General 不同，这个只是为了方便统计)，Request Headers，Response Headers，Entity Headers(也是为了方便统计)。
1、Genaral headers: 同时适用于请求和响应消息，但与最终消息主体中传输的数据无关的消息头。2、Request Headers: 包含更多有关要获取的资源或客户端本身信息的消息头。3、Response Headers：包含有关响应的补充信息，如其位置或服务器本身（名称和版本等）的消息头 4、Entity Headers：包含有关实体主体的更多信息，比如主体长 (Content-Length) 度或其 MIME 类型(用于响应 header 中)。
1、Genaral headers
Cache-Control——控制缓存的行为；详情 Connection——决定当前的事务完成后，是否会关闭网络连接；详情 Date——创建报文的日期时间；详情 Keep-Alive——用来设置超时时长和最大请求数；详情 Via——代理服务器的相关信息；详情 Warning——错误通知；详情 Trailer——允许发送方在分块发送的消息后面添加额外的元信息；详情 Transfer-Encoding——指定报文主体的传输编码方式；详情 Upgrade——升级为其他协议；
2、Request headers
Accept——客户端可以处理的内容类型；详情 Accept-Charset——客户端可以处理的字符集类型；详情 Accept-Encoding——客户端能够理解的内容编码方式；详情 Accept-Language——客户端可以理解的自然语言；详情 Authorization——Web 认证信息；详情 Cookie——通过 Set-Cookie 设置的值；详情 DNT——表明用户对于网站追踪的偏好；详情 From——用户的电子邮箱地址；详情 Host——请求资源所在服务器；详情 If-Match——比较实体标记（ETag）；详情 If-Modified-Since——比较资源的更新时间；详情 If-None-Match——比较实体标记（与 If-Match 相反）；详情 If-Range——资源未更新时发送实体 Byte 的范围请求；详情 If-Unmodified-Since——比较资源的更新时间（与 If-Modified-Since 相反）；详情 Origin——表明了请求来自于哪个站点；详情 Proxy-Authorization——代理服务器要求客户端的认证信息；详情 Range——实体的字节范围请求；详情 Referer——对请求中 URI 的原始获取方；详情 TE——指定用户代理希望使用的传输编码类型；详情 Upgrade-Insecure-Requests——表示客户端优先选择加密及带有身份验证的响应；详情 User-Agent——浏览器信息；详情
3、Response Headers
Accept-Ranges——是否接受字节范围请求；详情 Age——消息对象在缓存代理中存贮的时长，以秒为单位；详情 Clear-Site-Data——表示清除当前请求网站有关的浏览器数据（cookie，存储，缓存）；详情 Content-Security-Policy——允许站点管理者在指定的页面控制用户代理的资源；详情 Content-Security-Policy-Report-Only—— 详情 ETag——资源的匹配信息；链接描述 Location——令客户端重定向至指定 URI；详情 Proxy-Authenticate——代理服务器对客户端的认证信息；详情 Public-Key-Pins——包含该 Web 服务器用来进行加密的 public key（公钥）信息；详情 Public-Key-Pins-Report-Only——设置在公钥固定不匹配时，发送错误信息到 report-uri；详情 Referrer-Policy——用来监管哪些访问来源信息——会在 Referer 中发送；详情 Server——HTTP 服务器的安装信息；详情 Set-Cookie——服务器端向客户端发送 cookie；详情 Strict-Transport-Security——它告诉浏览器只能通过 HTTPS 访问当前资源；详情 Timing-Allow-Origin——用于指定特定站点，以允许其访问 Resource Timing API 提供的相关信息；详情 Tk——显示了对相应请求的跟踪情况；详情 Vary——服务器缓存的管理信息；详情 WWW-Authenticate——定义了使用何种验证方式去获取对资源的连接；详情 X-XSS-Protection——当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面；详情
4、Entity Headers
Allow——客户端可以处理的内容类型，这种内容类型用 MIME 类型来表示；详情 Content-Encoding——用于对特定媒体类型的数据进行压缩；详情 Content-Language——访问者希望采用的语言或语言组合；详情 Content-Length——发送给接收方的消息主体的大小；详情 Content-Location——替代对应资源的 URI；详情 Content-Range——实体主体的位置范围；详情 Content-Type——告诉客户端实际返回的内容的内容类型；详情 Expires——包含日期 / 时间，即在此时候之后，响应过期；详情 Last-Modified——资源的最后修改日期时间；详情
三、HTTP 具体应用
1、Cookie
HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时自动被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
Cookie 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。
a、创建过程
服务器发送的响应报文包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中。
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: PHPSESSID=kq8v6iujarsgflkeq7shmai9c7
客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: PHPSESSID=kq8v6iujarsgflkeq7shmai9c7
b、分类
会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。持久性 Cookie：指定一个特定的过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。安全 Cookie：指定 HttpOnly，这样 cookie 不能使用 JavaScript 经由 Document.cookie 属性，来防范跨站脚本攻击（XSS）。HTTPS Cookie: 指定 Secure，只有在请求使用 SSL 和 HTTPS 协议的时候才会被发送到服务器。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;HttpOnly
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;Secure
2、缓存
降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存在地理位置上也有可能比源服务器来得近，例如浏览器缓存。
实现方法:1、让代理服务器进行缓存；2、让客户端浏览器进行缓存
a、使用 Cache-Control 来控制缓存
禁止进行缓存。no-store 规定不能对请求或响应的任何一部分进行缓存
Cache-Control:
强制确认缓存。no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效才将能使用该缓存对客户端的请求进行响应。
Cache-Control: no-cache
缓存过期机制。
max-age 指令出现在请求报文中，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。max-age 指令出现在响应报文中，表示缓存资源在缓存服务器中保存的时间。或者使用 Expires
// 请求中
Cache-Control: max-age=31536000
// 响应中，优先处理 max-age
Cache-Control: max-age=31536000
Expires: Wed, 04 Jul 2012 08:26:05 GMT
缓存验证可以将缓存资源的值放入 request header 的 If-None-Match 首部，服务器收到该请求后，判断缓存资源的 值和资源的最新 值是否一致，如果一致则表示缓存资源有效，返回 304 Not Modified。并在 response header 中戴上 ETag 值
// 请求
If-None-Match: W/”646-RJRVaOjMluW+SOAL0EThThA2lnM”
// 响应
ETag: W/”646-RJRVaOjMluW+SOAL0EThThA2lnM”
后续待更 …