引言：对于HTTP属性的一些整理，数据请求和响应就不再贴图，随意找个网站打开调试工具都可以看得到。注：HTTP版本1.1
TCP连接接
传输控制协议，是互联网连接协议集的一种
通用头 General-Header
Request URL
请求的地址 可以进行参数和锚的传递
Request Method
请求方法：
GET 请求指定的页面信息，并返回实体主体
POST 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。Post请求可能会导致新的资源的建立和/或已有资源的修改。
HEAD 类似于Get请求，只不过返回的响应中没有具体的内容，用于获取报头。
OPTIONS 允许客户端查看服务器的性能。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE 请求服务器删除指定的页面。
TRACE 回显服务器收到的请求，主要用于测试或者诊断。
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
Status Code
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
Remote Address
请求的远程地址 例如：182.140.130.25:80
Referrer Policy
当产生Http请求时，浏览器会给这些请求头加上表示来源的Referrer字段。
No Referrer：任何情况下都不发送Referrer信息；
No Referrer When-downgrade：仅当发生协议降级(如HTTPS页面引入HTTP资源，从HTTPS页面跳到HTTP等)时不发送Referrer信息。这个规则是现在大部分浏览器默认所采用的。
Origin Only：发送只包含host部分的Referrer。弃用这个规则，无论是否发生协议降级，无论是本站链接还是站外链接，都会发送Referrer信息，但是之包含协议+host部分(不包含具体的路径及参数等信息)。
Origin When Cross-origin：仅在发生跨域访问时发送只包含host的Referrer，同域下还是完整的。它与Origin Only的区别是多判断了是否Cross-origin。需要注意的是协议、域名和端口都一致，才会被浏览器认为是同域。
Unsafe URL：无论是否发生协议降级，无论是本站链接还是站外链接，统统都发送Referrer信息。正如其名，这是最宽松而最不安全的策略。
CSP 响应头设置：Content-Security-Policy: referrer no-referrer|no-referrer-when-downgrade|origin|origin-when-cross-origin|unsafe-url;
CSP 的指令和指令值之间以空格分割，多个指令之间用英文分号分割。
通过 <meta> 标签也可以指定 Referrer 策略，同样很简单：
<meta name="referrer" content="no-referrer|no-referrer-when-downgrade|origin|origin-when-crossorigin|unsafe-url">
<a href="http://example.com" referrer="no-referrer|origin|unsafe-url">xxx</a>
这种方式作用的只是这一个链接。并且，<a> 标签可用的 Referrer 策略只有三种：不传、只传 host 和都传。另外，这样针对单个链接设置的策略优先级比 CSP 和 <meta> 要高。
需要注意的是：经过我的测试，目前并没有哪个浏览器实现了对 referrer
属性的支持。现阶段，如果要针对单个链接去掉 Referrer，还是推荐使用下面这种支持度更好的写法：
<a href="http://example.com" rel="noreferrer">xxx</a>
响应头 Response Headers
HTTP/1.1 200 OK
一旦收到请求，服务器（向客户端）发回一个状态行
HTTP/1.1 代表http协议的版本这里是指目前最流行的1.1版本
200 OK指服务器返回客服端响应状态。(前面有解释比较常用的几个状态所代表的含义)
Date
Date头域表示消息发送的时间，缓存在评估相应的新鲜度时要用到，时间的格式由RFC822定义。
例如:Date: Thu, 11 Jul 2015 15:33:24 GMT。
Age
当代理服务器用自己缓存的实体去响应请求时，用该头部表明该实体从产生到现在经过多长时间了。
Content-Type
内容类型，是指服务器向客户端传输的数据类型。决定文件接受方将以什么形式、什么编码读取这个文件。
列出几个常用数据类型：
text/plain//无格式正文
text/html//html格式的正文
text/css//CSS样式的标记
image/jpeg//.jpg格式图片
image/png//.png格式图片
image/gif//.gif格式图片
image/svg+xml//svg格式图片
audio/mp4//mp4格式音频
video/mp4//mp4格式视频
application/javascript//服务器端处理js文件的mime类型
application/pdf//服务器端处理pdf文件的mime类型
application/zip//服务器端处理zip的mime类型
application/json//服务器端处理JSON数据的mime类型
application/msword//Word文档格式
application/atom+xml//Atom XML聚合格式
multipart/form-data//需要在表单中进行文件上传时，就需要使用该格式
Connection
连接 值有两个keep-alive和close 默认为keep-alive
Content-Length
内容长度
Content-Encoding
传输内容编码指服务器是用什么样的方式处理数据传输到客户端，客户端以什么样的方式反向处理来得到原始数据。
值：
deflate//一种压缩算法，使用LZ77和哈弗曼进行编码，指的是在RFC1950说明的zlib格式。
compress//
gzip//一种格式，也是对deflate进行的封装.(最常用)
Transfer-Encoding
值为chunked
是一个 HTTP 头部字段，字面意思是「传输编码」。实际上，HTTP 协议中还有另外一个头部与编码有关：Content-Encoding（内容编码）。Content-Encoding 通常用于对实体内容进行压缩编码，目的是优化传输，例如用 gzip 压缩文本文件，能大幅减小体积。内容编码通常是选择性的，例如 jpg / png 这类文件一般不开启，因为图片格式已经是高度压缩过的，再压一遍没什么效果不说还浪费 CPU。
而 Transfer-Encoding 则是用来改变报文格式，它不但不会减少实体内容传输大小，甚至还会使传输变大，那它的作用是什么呢？本文接下来主要就是讲这个。我们先记住一点，Content-Encoding 和 Transfer-Encoding 二者是相辅相成的，对于一个 HTTP 报文，很可能同时进行了内容编码和传输编码。
HTTP 运行在 TCP 连接之上，自然也有着跟 TCP 一样的三次握手、慢启动等特性，为了尽可能的提高 HTTP 性能，使用持久连接就显得尤为重要了。为此，HTTP 协议引入了相应的机制。
HTTP/1.0 的持久连接机制是后来才引入的，通过 Connection: keep-alive 这个头部来实现，服务端和客户端都可以使用它告诉对方在发送完数据之后不需要断开 TCP 连接，以备后用。HTTP/1.1 则规定所有连接都必须是持久的，除非显式地在头部加上 Connection: close。所以实际上，HTTP/1.1 中 Connection 这个头部字段已经没有 keep-alive 这个取值了，但由于历史原因，很多 Web Server 和浏览器，还是保留着给 HTTP/1.1 长连接发送 Connection: keep-alive 的习惯。
浏览器重用已经打开的空闲持久连接，可以避开缓慢的三次握手，还可以避免遇上 TCP 慢启动的拥塞适应阶段。
由于 Content-Length 字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没那么好获得，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。
我们在做 WEB 性能优化时，有一个重要的指标叫 TTFB（Time To First Byte），它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。大部分浏览器自带的 Network 面板都可以看到这个指标，越短的 TTFB 意味着用户可以越早看到页面内容，体验越好。可想而知，服务端为了计算响应实体长度而缓存所有内容，跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，也能知道实体的边界。
Transfer-Encoding 正是用来解决上面这个问题的。历史上 Transfer-Encoding 可以有多种取值，为此还引入了一个名为 TE 的头部用来协商采用何种传输编码。但是最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。
分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF（\r\n），也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。
前面说过 Content-Encoding 和 Transfer-Encoding 二者经常会结合来用，其实就是针对 Transfer-Encoding 的分块再进行 Content-Encoding。
(这一大段是其他作者关于Transfer-Encoding、Content-Encoding、Content-Length、Connection的相互理解。文章最后有链接)
Last-Modified
当浏览器第一次请求某一个URL时，服务器的返回状态是200，内容是客户端请求的资源，同时有一个Last-Modified的属性标记此文件在服务器端最后被修改的时间
例如：Last-Modified : Fri , 12 May 2006 18:53:33 GMT
当浏览器第二次请求URL时，根据HTTP协议的规定，浏览器会向服务器发送If-Modified-Since报头，询问该时间之后文件是否有被修改过：If-Modified-Since:Fri , 12 May 2006 18:53:33 GMT
如果服务器端的资源没有变化，则自动返回HTTP 304(Not changed)状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。
Cache-Control
它用于指定所有缓存机制在整个请求/响应链中必须服从的指令。这些指令指定用于阻止缓存对请求或响应造成不利干扰的行为。这些指令通常覆盖默认缓存算法。缓存指令是单向的，即请求中存在一个指令不意味着响应中将存在同一个指令。
常见的值
public//所有内容都将被缓存(客户端和代理服务器都可缓存)
private//默认值，内容只缓存到私有缓存中(仅客户端可以缓存，代理服务器不可缓存)
no-cache//必须先与服务器确认返回的响应是否被更改，然后才能使用该响应来满足后续对同一个网址的请求。因此，如果存在合适的验证令牌 (ETag)，no-cache 会发起往返通信来验证缓存的响应，如果资源未被更改，可以避免下载。
no-store//所有内容都不会被缓存到缓存或 Internet 临时文件中
must-revalidation/proxy-revalidation//如果缓存的内容失效，请求必须发送到服务器/代理以进行重新验证
max-age=xxx (xxx is numeric)//缓存的内容将在 xxx 秒后失效, 这个选项只在HTTP 1.1可用, 并如果和Last-Modified一起使用时, 优先级较高
Expires
头部字段提供一个日期和时间，响应在该日期和时间后被认为失效。
例如：Expires:Thu, 22 Jun 2017 10:03:50 GMT
失效的缓存条目通常不会被缓存（无论是代理缓存还是用户代理缓存）返回，除非首先通过原始服务器（或者拥有该实体的最新副本的中介缓存）验证。（注意：cache-control max-age 和 s-maxage 将覆盖 Expires 头部。）
Expires 字段接收以下格式的值：“Expires: Sun, 08 Nov 2009 03:37:26 GMT”。如果查看内容时的日期在给定的日期之前，则认为该内容没有失效并从缓存中提取出来。反之，则认为该内容失效，缓存将采取一些措施。
Server
web server
服务器程序软件名称和版本
常见值为nginx Apache等
Vary
值为Accept-Encoding
告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题
当浏览器发出一个请求时，会包含一些HTTP头信息，服务器会根据这些头信息决定返回什么样的东西（这是一个移动客户端吗？它能否处理压缩内容？它是否需要特定的语言支持？）。
直接访问是好的，但现在网络使用了中间高速缓存（cache）和内容分发网络（CDN）。这就产生了一个问题，缓存如何使用头信息决定返回什么？它能否复制服务器端的决策逻辑？
设想有两个客户，一个使用的旧浏览器不支持压缩，一个使用新的浏览器支持压缩，如果他们都请求同一个网页，那么取决于谁先请求，压缩或非压缩版本便存储在CDN上。这样问题就出现了，旧浏览器请求常规网页但获得缓存的压缩版本，而新浏览器会获得缓存的非压缩版本但尝试去“解压”它。无论哪种方式都是坏消息。解决方法是，源服务器回送“Vary: Accept-Encoding”。
现在的中间CDN会存储独立的缓存条目，一个是Accept-encoding: gzip ，而如果你没有发送header，则存储另一个。
请求头 Request Headers
Accept
表示浏览器支持的MIME类型
例如：application/json, text/javascript, /; q=0.01
Accept-Encoding
浏览器支持的压缩类型
例如：gzip, deflate
Accept-Language
浏览器支持的语言类型，并且优先支持靠前的语言类型
例如：zh-CN,zh;q=0.8
Connection
当浏览器与服务器通信时对于长连接如何进行处理：close/keep-alive
Cookie
向服务器返回cookie，这些cookie是之前服务器发给浏览器的
Host
请求的服务器URL
例如：www.baidu.com
Referer
该页面的来源URL
例如：http://www.baidu.com/
User-Agent
用户使用的客户端的一些必要信息，比如操作系统、浏览器及版本、浏览器渲染引擎等。
例如：Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36
X-Requested-With
判断是否为ajax请求如果没有该属性则说明为传统请求
Cache-Control
指定请求和响应遵循的缓存机制
Pragma
值为no-cache
意义与Cache-control相同 禁止缓存的指令。
获取响应头全部以及响应参数
$.ajax({
type : "get" ,
url : "https://www.zhihu.com/question/20795144",
success : function (data, status, xhr) {
//获取响应头全部参数信息
alert(xhr.getAllResponseHeaders());
alert(xhr.getResponseHeader("Date"));
}
});
参考链接：
HTTP简介：http://www.cnblogs.com/ranyonsue/p/5984001.html
Referrer Policy：https://imququ.com/post/referrer-policy.html
Date：http://blog.csdn.net/xifeijian/article/details/46460631
content-type：http://baike.baidu.com/link?url=tnRXRpiJON2kcva3SMXts6hFqa55-FSbTH7IN8FbQPp4DgpXp4NPZxc8zuVTIuKPcIrc7xMP5XXldOM-FL5lZpkdTPJ-mG_fk7g-I5qi6b7
content-type：http://blog.csdn.net/blueheart20/article/details/45174399
Transfer-Encoding：https://imququ.com/post/transfer-encoding-header-in-http.html
Content-Encoding：http://guojuanjun.blog.51cto.com/277646/667067/
http://baike.baidu.com/link?
Cache-Control和Expires：http://baike.baidu.com/link?url=itzaYOBiXX82BU7Ly9fP1wbQ03RZxFMUItaewhdaNuQAyc9gD6KNKX0xTJCQdA6aMMd7GBWJ4MdWSVLGoT-UFO1ArMtJVFQK7JdDgLT0eri
Vary：Accept-Encoding：http://blog.csdn.net/dazhi_100/article/details/50061297
偶然发现的常用对照表也许对你有帮助：
http://tool.oschina.net/commons?type=5
http://www.cnblogs.com/Joans/p/3956490.html
网友评论