- HTTP请求方法
- HTTP消息头
- HTTP请求头
- HTTP响应头
- HTTP cookie机制和实现原理
HTTP请求方法
超文本传输协议（HTTP, HyperText Transfer Protocol）是一种无状态的协议，它位于OSI七层模型的传输层。HTTP客户端会根据需要构建合适的HTTP请求方法，而HTTP服务器会根据不同的HTTP请求方法做出不同的响应。
1. HTTP版本与HTTP请求方法
在HTTP的发展过程中，出现了很多HTTP版本，其中的大部分协议都是向下兼容的。在进行HTTP请求时，客户端在请求时会告诉服务器它采用的协议版本号，而服务器则会在使用相同或者更早的协议版本进行响应。
HTTP/0.9
这是HTTP最早大规模使用的版，现已过时。在这个版本中 只有GET一种请求方法，在HTTP通讯也没有指定版本号，也不支持请求头信息。该版本不支持POST等方法，因此客户端向服务器传递信息的能力非常有限。HTTP/0.9的请求只有如下一行：
GET www.itbilu.com
HTTP/1.0
这个版本是第一个在HTTP通讯中指定版本号的协议版本，HTTP/1.0至今仍被广泛采用，特别是在代理服务器中。
HTTP/1.0支持：GET、POST、HEAD三种HTTP请求方法。
HTTP/1.1
HTTP/1.1是当前正在使用的版本。该版本默认采用持久连接，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以便降低线路负载，提高传输速度。
HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五种HTTP请求方法。
HTTP/2
这个版本是最新发布的版本，于今年5月（2015年5月）做HTTP标准正式发布。HTTP/2通过支持请求与相应的多路重用来减少延迟，通过压缩HTTP头字段将协议开销降到最低，同时增加了对请求优先级和服务器端推送的支持。
2. HTTP请求方法介绍
HTTP/1.1协议中共定义了8种HTTP请求方法，HTTP请求方法也被叫做“请求动作”，不同的方法规定了不同的操作指定的资源方式。服务端也会根据不同的请求方法做不同的响应。
GET
GET请求会显示请求指定的资源。一般来说GET方法应该只用于数据的读取，而不应当用于会产生副作用的非幂等的操作中。
GET会方法请求指定的页面信息，并返回响应主体，GET被认为是不安全的方法，因为GET方法会被网络蜘蛛等任意的访问。
HEAD
HEAD方法与GET方法一样，都是向服务器发出指定资源的请求。但是，服务器在响应HEAD请求时不会回传资源的内容部分，即：响应主体。这样，我们可以不传输全部内容的情况下，就可以获取服务器的响应头信息。HEAD方法常被用于客户端查看服务器的性能。
POST
POST请求会 向指定资源提交数据，请求服务器进行处理，如：表单数据提交、文件上传等，请求数据会被包含在请求体中。POST方法是非幂等的方法，因为这个请求可能会创建新的资源或/和修改现有资源。
PUT
PUT请求会身向指定资源位置上传其最新内容，PUT方法是幂等的方法。通过该方法客户端可以将指定资源的最新数据传送给服务器取代指定的资源的内容。
DELETE
DELETE请求用于请求服务器删除所请求URI（统一资源标识符，Uniform Resource Identifier）所标识的资源。DELETE请求后指定资源会被删除，DELETE方法也是幂等的。
CONNECT
CONNECT方法是HTTP/1.1协议预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。
OPTIONS
OPTIONS请求与HEAD类似，一般也是用于客户端查看服务器的性能。 这个方法会请求服务器返回该资源所支持的所有HTTP请求方法，该方法会用'*'来代替资源名称，向服务器发送OPTIONS请求，可以测试服务器功能是否正常。JavaScript的XMLHttpRequest对象进行CORS跨域资源共享时，就是使用OPTIONS方法发送嗅探请求，以判断是否有对指定资源的访问权限。 允许
TRACE
TRACE请求服务器回显其收到的请求信息，该方法主要用于HTTP请求的测试或诊断。
HTTP/1.1之后增加的方法
在HTTP/1.1标准制定之后，又陆续扩展了一些方法。其中使用中较多的是 PATCH 方法：
PATCH
PATCH方法出现的较晚，它在2010年的RFC 5789标准中被定义。PATCH请求与PUT请求类似，同样用于资源的更新。二者有以下两点不同：
- 但
PATCH一般用于资源的部分更新，而PUT一般用于资源的整体更新。 - 当资源不存在时，
PATCH会创建一个新的资源，而PUT只会对已在资源进行更新。
HTTP消息头
1. HTTP消息头分类
在HTTP消息头中，有些是客户端特有的，有些是服务端所特有的，也有些是消息头是通用的。按HTTP消息头出现的上下文环境，有以下分类：
1.1 通用头
HTTP消息头中，有些既适用于客户端的请求头，也适用于服务端的响应头，与HTTP消息体内最终传输的数据是无关的，只适用于要发送的消息。这些消息头由于HTTP协议版本的不同可能会有所区别，在HTTP/1.1中，这些消息头有：Cache-Control:、Connection:、Date:、 Pragma:、Trailer:、Transfer-Encoding:、Upgrade:、 Via:、Warning:。
1.2 请求头
HTTP 请求头为所请求的资源或请求本身，提供了更为精确的描述信息。其中有些缓存相关头描述了缓存信息，这些头会改变GET请求时获取资源的方式，如：If-Modified-Since。有些消息头描述了用户偏好，如： Accept-Language和Accept-Charset表示客户端所使用语言及编码方式、User-Agent表示客户端的代理方式。
新增加的请求头不能在旧的HTTP版本中使用，但是，如果服务器和客户端都能对相关头进行处理，就可以在请求中使用。在这种情况下，客户端不应该假定服务器有对相关头的处理能力。未知的请求头被处理为实体头。
1.3 响应头
HTTP 响应头为响应消息提供了更多信息。如，关于资源位置的描述Location:，关于务器本身的描述使用Server:
新增加的响应头不能在旧的HTTP版本中使用，但是，如果服务器和客户端都能对相关头进行处理，就可以在响应中使用。在这种情况下，服务器不应该假定客户端有对相关头的处理能力。未知的响应头被处理为实体头。
1.4 实体头
HTTP 实体头提供了关于消息体的描述。如，消息体的长度Content-Length:，消息体的MIME类型Content-Type:。新的实体头可以旧HTTP版本中使用。
HTTP消息头也可以按缓存与百缓存的处理方式分分类：
1.5 端到端（End-To-End）头
End-To-End头信息必须发送到消息的最终接收人，即：接收请求消息的服务器或接收响应消息的客户端。这些头信息意味着中间代理必须重发未修改的内容，也必须存储缓存。
End-To-End头在一个路由器连接的两种物理网络中使用，即：OSI的应用层和运输层。
1.6 逐跳（Hop-By-Hop）头
Hop-By-Hop头被单一的传输层连接使用，Hop-By-Hop头标识传输内容不得通过代理或缓存转发。这些头信息有：Connection:、Keep-Alive:、Proxy-Authenticate:、Proxy-Authorization:、 TE:、Trailers:、Transfer-Encoding:、Upgrade:。注意，只有Hop-By-Hop头可能会设置使用Connection: 通用头。
2. 一些有用的请求头
众多的HTTP请求头中，有几个是特别有用且应当正确设置的。如果你要创建HTTP请求，如，创建XMLHttpRequest或一个延时写入并通过XPCOM发送自定义的HTTP请求时，这时确保正确写入请求头就非常重要，进行这些操作时，用户使用浏览器一般自动写入请求头。
2.1 控制所访问资源的语言
大多数用户所使用的浏览器客户端，如：Firefox，都允许用户设置所偏好的语言，设置后浏览器会在发送请求时添加一个Accept-Language: 头信息。而服务器，在收到HTTP请求时，也可以根据这个头信息返回对应语言的资源。
2.2 有条件GET请求
缓存是提高网站访问速度的重要方式，当使用XMLHttpRequest进行部分页面数据的刷新时，使用If-Modified-Since：头信息会告诉服务器，访问更新过的内容，可以有效的提高访问效率。
3. 一些有用的响应头
正确的配置网站服务器，是保证网站性能和安全的关键。在众多的HTTP响应头中，有几个响应头是比较重要性且应当配置在服务器中。
3.1 框架（frame）控制
几个跨站脚本（XSS）攻击，就是利用第三方框架（frame或iframe）。现代浏览器已经支持CSPframe-ancestors指令，在服务器端将其设置为"none"，可以有效访止浏览器在框架内显示该资源，使用它的关键资源（如：表单数据或关键信息）可以有效减少XSS攻击风险。注意，这个响应头并不是缓解XSS风险的唯一途径，也可通过一些内容安全策略实现。
3.2 数据压缩
最大限度地减少传输的数据量，可以有效加速了网页的显示。虽然可以通Gulp等工具，将静态文件数据压缩。但如果要压缩传输数据，那么必须在Web服务器级别进行相关配置。设置后，客户端会发送一个Accept-Encoding:头，告诉服务器所接受的编码方式；而服务器也会响应一个Content-Encoding:头，告诉客户端所使用的压缩方式。
注：Nginx服务器可以通过配置Gzip实现数据压缩。
3.3 缓存控制
HTTP缓存是提高网站访问速度另一种有效方式，它可防止同一未修改资源被多次访问。正确的配置服务器的响应头，可以使用户代理（浏览中器）充分缓存数据。
配置缓存时，需要设置以下项：
- 任何静态资源都应该提供了一个
Expires:响应头。这样，资源可以用户代理达到它自身限制前（如：达到缓存大小限制），充分的缓存数据。 - 任何动态资源都应该提供了一个
Cache-control:响应头。理论上讲，所有安全的HTTP方法(GET、HEAD)甚至幂等方法(DELETE、PUT)，都可以配置缓存，但在实际使用中会有一些问题。
3.4 设置MIME类型
MIME类型响应头Content-type会告诉客户端传输文档的类型，扩展名在文档的网络传中已经失去意义。正确配置服务器此项设置，对文件传输非常重要，用户代理客户端经常通过MIME类型判断文档的打开方式或获取资源后的默认动作。
HTTP请求头
常用的HTTP请求头
| 协议头 | 说明 | 示例 | 状态 |
|---|---|---|---|
| Accept | 可接受的响应内容类型（Content-Types）。 |
Accept: text/plain |
固定 |
| Accept-Charset | 可接受的字符集 | Accept-Charset: utf-8 |
固定 |
| Accept-Encoding | 可接受的响应内容的编码方式。 | Accept-Encoding: gzip, deflate |
固定 |
| Accept-Language | 可接受的响应内容语言列表。 | Accept-Language: en-US |
固定 |
| Accept-Datetime | 可接受的按照时间来表示的响应内容版本 | Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT | 临时 |
| Authorization | 用于表示HTTP协议中需要认证资源的认证信息 | Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE== | 固定 |
| Cache-Control | 用来指定当前的请求/回复中的，是否使用缓存机制。 | Cache-Control: no-cache |
固定 |
| Connection | 客户端（浏览器）想要优先使用的连接类型 | Connection: keep-alive
|
固定 |
| Cookie | 由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie |
Cookie: $Version=1; Skin=new; |
固定：标准 |
| Content-Length | 以8进制表示的请求体的长度 | Content-Length: 348 |
固定 |
| Content-MD5 | 请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果 | Content-MD5: oD8dH2sgSW50ZWdyaIEd9D== | 废弃 |
| Content-Type | 请求体的MIME类型 （用于POST和PUT请求中） | Content-Type: application/x-www-form-urlencoded | 固定 |
| Date | 发送该消息的日期和时间（以RFC 7231中定义的"HTTP日期"格式来发送） | Date: Dec, 26 Dec 2015 17:30:00 GMT | 固定 |
| Expect | 表示客户端要求服务器做出特定的行为 | Expect: 100-continue |
固定 |
| From | 发起此请求的用户的邮件地址 | From: user@itbilu.com |
固定 |
| Host | 表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。 | Host: www.itbilu.com:80
|
固定 |
| If-Match | 仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。 | If-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" | 固定 |
| If-Modified-Since | 允许在对应的资源未被修改的情况下返回304未修改 | If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT | 固定 |
| If-None-Match | 允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标记 | If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd" | 固定 |
| If-Range | 如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体 | If-Range: "9jd00cdj34pss9ejqiw39d82f20d0ikd" | 固定 |
| If-Unmodified-Since | 仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。 | If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT | 固定 |
| Max-Forwards | 限制该消息可被代理及网关转发的次数。 | Max-Forwards: 10 |
固定 |
| Origin | 发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个Access-Control-Allow-Origin的消息头，表示访问控制所允许的来源）。 |
Origin: http://www.itbilu.com |
固定: 标准 |
| Pragma | 与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。 | Pragma: no-cache |
固定 |
| Proxy-Authorization | 用于向代理进行认证的认证信息。 | Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2== | 固定 |
| Range | 表示请求某个实体的一部分，字节偏移以0开始。 | Range: bytes=500-999 |
固定 |
| Referer | 表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。 |
Referer: http://itbilu.com/nodejs | 固定 |
| TE | 浏览器预期接受的传输时的编码方式：可使用回应协议头Transfer-Encoding中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为0的块之后还接收到一些额外的字段。 |
TE: trailers,deflate |
固定 |
| User-Agent | 浏览器的身份标识字符串 | User-Agent: Mozilla/…… |
固定 |
| Upgrade | 要求服务器升级到一个高版本协议。 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | 固定 |
| Via | 告诉服务器，这个请求是由哪些代理发出的。 | Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1) | 固定 |
| Warning | 一个一般性的警告，表示在实体内容体中可能存在错误。 | Warning: 199 Miscellaneous warning | 固定 |
HTTP响应头
常用的HTTP响应头
| 响应头 | 说明 | 示例 | 状态 |
|---|---|---|---|
| Access-Control-Allow-Origin | 指定哪些网站可以跨域源资源共享 |
Access-Control-Allow-Origin: * |
临时 |
| Accept-Patch | 指定服务器所支持的文档补丁格式 | Accept-Patch: text/example;charset=utf-8 | 固定 |
| Accept-Ranges | 服务器所支持的内容范围 | Accept-Ranges: bytes |
固定 |
| Age | 响应对象在代理缓存中存在的时间，以秒为单位 | Age: 12 |
固定 |
| Allow | 对于特定资源的有效动作; | Allow: GET, HEAD |
固定 |
| Cache-Control | 通知从服务器到客户端内的所有缓存机制，表示它们是否可以缓存这个对象及缓存有效时间。其单位为秒 | Cache-Control: max-age=3600 |
固定 |
| Connection | 针对该连接所预期的选项 | Connection: close |
固定 |
| Content-Disposition | 对已知MIME类型资源的描述，浏览器可以根据这个响应头决定是对返回资源的动作，如：将其下载或是打开。 | Content-Disposition: attachment; filename="fname.ext" | 固定 |
| Content-Encoding | 响应资源所使用的编码类型。 | Content-Encoding: gzip |
固定 |
| Content-Language | 响就内容所使用的语言 | Content-Language: zh-cn |
固定 |
| Content-Length | 响应消息体的长度，用8进制字节表示 | Content-Length: 348 |
固定 |
| Content-Location | 所返回的数据的一个候选位置 | Content-Location: /index.htm |
固定 |
| Content-MD5 | 响应内容的二进制 MD5 散列值，以 Base64 方式编码 | Content-MD5: IDK0iSsgSW50ZWd0DiJUi== | 已淘汰 |
| Content-Range | 如果是响应部分消息，表示属于完整消息的哪个部分 | Content-Range: bytes 21010-47021/47022 | 固定 |
| Content-Type | 当前内容的MIME类型 |
Content-Type: text/html; charset=utf-8 | 固定 |
| Date | 此条消息被发送时的日期和时间(以RFC 7231中定义的"HTTP日期"格式来表示) | Date: Tue, 15 Nov 1994 08:12:31 GMT | 固定 |
| ETag | 对于某个资源的某个特定版本的一个标识符，通常是一个 消息散列 | ETag: "737060cd8c284d8af7ad3082f209582d" | 固定 |
| Expires | 指定一个日期/时间，超过该时间则认为此回应已经过期 | Expires: Thu, 01 Dec 1994 16:00:00 GMT | 固定: 标准 |
| Last-Modified | 所请求的对象的最后修改日期(按照 RFC 7231 中定义的“超文本传输协议日期”格式来表示) | Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT | 固定 |
| Link | 用来表示与另一个资源之间的类型关系，此类型关系是在RFC 5988中定义 | Link: ; rel="alternate" |
固定 |
| Location | 用于在进行重定向，或在创建了某个新资源时使用。 | Location: http://www.itbilu.com/nodejs | 固定 |
| P3P | P3P策略相关设置 | P3P: CP="This is not a P3P policy! | 固定 |
| Pragma | 与具体的实现相关，这些响应头可能在请求/回应链中的不同时候产生不同的效果 | Pragma: no-cache |
固定 |
| Proxy-Authenticate | 要求在访问代理时提供身份认证信息。 | Proxy-Authenticate: Basic |
固定 |
| Public-Key-Pins | 用于防止中间攻击，声明网站认证中传输层安全协议的证书散列值 | Public-Key-Pins: max-age=2592000; pin-sha256="……"; | 固定 |
| Refresh | 用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。 | Refresh: 5; url=http://itbilu.com | |
| Retry-After | 如果某个实体临时不可用，那么此协议头用于告知客户端稍后重试。其值可以是一个特定的时间段(以秒为单位)或一个超文本传输协议日期。 |
|
固定 |
| Server | 服务器的名称 | Server: nginx/1.6.3 |
固定 |
| Set-Cookie | 设置HTTP cookie |
Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 | 固定: 标准 |
| Status | 通用网关接口的响应头字段，用来说明当前HTTP连接的响应状态。 | Status: 200 OK |
|
| Trailer | Trailer用户说明传输中分块编码的编码信息 |
Trailer: Max-Forwards |
固定 |
| Transfer-Encoding | 用表示实体传输给用户的编码形式。包括：chunked、compress、 deflate、gzip、identity。 |
Transfer-Encoding: chunked | 固定 |
| Upgrade | 要求客户端升级到另一个高版本协议。 | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 | 固定 |
| Vary | 告知下游的代理服务器，应当如何对以后的请求协议头进行匹配，以决定是否可使用已缓存的响应内容而不是重新从原服务器请求新的内容。 | Vary: * |
固定 |
| Via | 告知代理服务器的客户端，当前响应是通过什么途径发送的。 | Via: 1.0 fred, 1.1 itbilu.com (nginx/1.6.3) | 固定 |
| Warning | 一般性警告，告知在实体内容体中可能存在错误。 | Warning: 199 Miscellaneous warning | 固定 |
| WWW-Authenticate | 表示在请求获取这个实体时应当使用的认证模式。 | WWW-Authenticate: Basic |
固定 |
HTTP Cookie实现机制
Cookie是进行网站用户身份，实现服务端Session会话持久化的一种非常好方式。Cookie最早由Netscape公司开发，现在由 IETF 的RFC 6265标准备对其规范，已被所有主流浏览器所支持。
1. 为什么需要Cookie？
HTTP是一种无状态的协议，客户端与服务器建立连接并传输数据，数据传输完成后，连接就会关闭。再次交互数据需要建立新的连接，因此，服务器无法从连接上跟踪会话，也无法知道用户上一次做了什么。这严重阻碍了基于Web应用程序的交互，也影响用户的交互体验。如：在网络有时候需要用户登录才进一步操作，用户输入用户名密码登录后，浏览了几个页面，由于HTTP的无状态性，服务器并不知道用户有没有登录。
Cookie是解决HTTP无状态性的有效手段，服务器可以设置或读取Cookie中所包含的信息。当用户登录后，服务器会发送包含登录凭据的Cookie到用户浏览器客户端，而浏览器对该Cookie进行某种形式的存储（内存或硬盘）。用户再次访问该网站时，浏览器会发送该Cookie（Cookie未到期时）到服务器，服务器对该凭据进行验证，合法时使用户不必输入用户名和密码就可以直接登录。
本质上讲，Cookie是一段文本信息。客户端请求服务器时，如果服务器需要记录用户状态，就在响应用户请求时发送一段Cookie信息。客户端浏览器保存该Cookie信息，当用户再次访问该网站时，浏览器会把Cookie做为请求信息的一部分提交给服务器。服务器检查Cookie内容，以此来判断用户状态，服务器还会对Cookie信息进行维护，必要时会对Cookie内容进行修改。
2. Cookie的类型
Cookie总时由用户客户端进行保存的（一般是浏览器），按其存储位置可分为：内存式Cookie和硬盘式Cookie。
内存式Cookie存储在内存中，浏览器关闭后就会消失，由于其存储时间较短，因此也被称为非持久Cookie或会话Cookie。
硬盘式Cookie保存在硬盘中，其不会随浏览器的关闭而消失，除非用户手工清理或到了过期时间。由于硬盘式Cookie存储时间是长期的，因此也被称为持久Cookie。
3. Cookie的实现原理
Cookie定义了一些HTTP请求头和HTTP响应头，通过这些HTTP头信息使服务器可以与客户进行状态交互。
客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。
下面是一个实现Cookie机制的，简单的HTTP请求过程：
1. 客户端请求服务器
客户端请求IT笔录网站首页，请求头如下：
GET / HTTP/1.0 HOST: itbilu.com
2. 服务器响应请求
Cookie是一种key=value形式的字符串，服务器需要记录这个客户端请求的状态，因此在响应头中包一个Set-Cookie字段。响应头如下：
HTTP/1.0 200 OK Set-Cookie: UserID=itbilu; Max-Age=3600; Version=1 Content-type: text/html ……
3. 再次请求时，客户端请求中会包含一个Cookie请求头
客户端会对服务器响应的Set-Cookie头信息进行存储。再次请求时，将会在请求头中包含服务器响应的Cookie信息。请求头如下
GET / HTTP/1.0 HOST: itbilu.com Cookie: UserID=itbilu
转自：https://itbilu.com/other/relate/page-2.html