详解HTTP协议

1、HTTP简介

1.HTTP

HTTP:超文本传输协议，是一种通讯协议；容许超文本标记文档从Web服务器传送到客户端的浏览器中。

简单：传输html文件的协议。

Web：是一种基于超文本和HTML的、全球性的、动态交互的、跨平台的分布式图形信息系统。

http是无状态协议，这保证了它的高效。Cookie和Section的出现使http在保持高效的状况下，可以记住状态；

2.URI与URL

• URI可分为URL，URN或同时具有locators 和 names特性的东西；
• URN的做用就好像一我的的名字，URL就像这我的的地址；
• 换句话说：URN肯定了东西的身份，URL提供了找到它的方式；

URL是URI的一种，不是全部的URI都是URL；URI惟一地标识了身份，URL给出了访问机制（http/ftp/telnet等）

2、状态码

1xx：接收的请求正在处理

2xx：请求正常处理完毕

状态码	状态码英文名称	描述
200	OK	请求已成功，请求所但愿的响应头或数据体将随此响应返回
202	Accepted	已接受，已经接受请求，但未处理完成
204	No Content	请求处理成功，可是返回的响应报文中不包含实体的主体部分
206	Partial Content	该状态码表示客户端进行了范围请求， 而服务器成功执行了这部分的 GET 请求。 响应报文中包含由 Content-Range 指定范围的实体内容。

3xx：重定向

状态码	状态码英文名称	描述
301	Moved Permanently	永久重定向，请求的资源已被永久的移动到新的URI，返回信息会包括新的URI，浏览器会自动定向到新的URI。从此任何新的请求都会使用新的URI（好比某的网站域名已更改，访问旧网址会自动跳转到网址）
302	Found	暂时重定向，与301相似。但资源只是临时被移动，客户端应继续使用原有的URI
303	See Other	该状态码表示因为请求对应的资源存在着另外一个 URI， 应使用 GET 方法定向获取请求的资源。与302区别在于303但愿用户使用GET访问新的URI，而302能够使用POST访问新的URI
304	Not Modified	该状态码表示客户端发送附带条件时（If-Match， If-ModifiedSince等）， 服务器端容许请求访 问资源， 但未知足附带的条件。 此时返回，304 状态码， 不包含任何响应 的主体部分。另外一种理解：所请求的资源没有更改，能够使用缓存

4xx：客户端错误

状态码	状态码英文名称	描述
400	Bad Request	客户端请求报文语法错误，服务器没法理解
401	Unauthorized	表示发送的请求须要有经过HTTP认证（BASIC 认证、 DIGEST 认证） 的认证信息
403	Forbidden	服务器理解客户端的请求，可是拒绝执行此请求
404	Not Found	服务器没法根据客户端的请求找到资源（网页）

5xx：服务器错误

状态码	状态码英文名称	描述
500	Internal Server Error	服务器端内错误或 Web 应用存在bug或某些临时的故障，致使没法完成请求
502	Bad Gateway	充当网关或代理的服务器，从远端服务器接收到了一个无效的请求
503	Service Unavailable	代表服务器暂时处于超负载或正在进行停机维护， 如今没法 处理请求

3、HTTP首部

1.HTTP请求和响应报文

1.1HTTP请求报文

1.2.HTTP响应报文

可见HTTP报文一共有四种首部字段（请求头）：请求首部字段、响应首部字段、通用首部字段、实体首部字段；

1.3.示例

在chrome的开发者调试工具当中，从请求报文和响应报文分各抽出了一部分，造成了三部分：

General：

Request Headers：

Response Headers：

2.请求首部字段

2.1.Accept

做用：浏览器端能够接受的媒体类型；

若想要给显示的媒体类型增长优先级， 则使用 q来额外表示权重值，用分号（;）进行分隔。权重值 q 的范围是 0~1（可精确到小数点后 3 位） ，且1为最大值。不指定权重 q 值时，默认权重为 q=1.0。

当服务器提供多种内容时，将会首先返回权重值最高的媒体类型。

2.2.Accept-Charset

做用：用来通知服务器用户代理（浏览器）支持的字符集及字符集的相对优先顺序。

图Accept-Charset字段中的值：

Accept-Charset： iso-8859-5, unicode-1-1;q=0.8

中的unicode-1-1;q=0.8是一个总体，表示unicode编码优先级为0.8，小于默认的iso编码优先级（默认q=1）；不要觉得分号（；）为分割符，其实逗号（，）才是分割符

2.3.Accept-Encoding

做用：用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。 可一次性指定多种内容编码。

Accept-Encoding: gzip, deflate

常见的编码方式有：gzip、compress、deflate、identity。

2.4.Accept-Language

做用：用来告知服务器浏览器可以接收的语言 ，以及相对优先级。

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

上述值表示：优先请求中文版，其次是英文版；

2.5.Host

Host: www.hackr.jp

若服务器未设定主机名，Host为空值便可。

2.6.If-Match

形如If--xxx这种样式的请求首部字段，均可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

上图表示：只有当If-Match的字段值跟Etag值匹配一致时，服务器才会接收请求。

2.7.If-Modified-Since

上图表示：若是在If-Modified-Since字段指定的日期时间后，资源发生了更新，服务器会接收请求，此时返回状态码200；不然会拒绝接收请求返回304（由于资源都没更新过，不须要从新请求），与响应头Last-Modified是一对；

2.8.If-None-Match

只有在 If-None-Match 的字段值与 ETag 值不一致时， 可处理该请求。 与 If-Match 首部字段的做用相反；

2.9.If-Range

首部字段 If-Range 属于附带条件之一。 它告知服务器若指定的 If-Range 字段值（ETag 值或者时间） 和请求资源的 ETag 值或时间相一致时， 则做为范围请求处理。 反之， 则返回全体资源。

下面咱们思考一下不使用首部字段 If-Range 发送请求的状况。 服务器端的资源若是更新， 那客户端持有资源中的一部分也会随之无效，固然，范围请求做为前提是无效的。这时，服务器会暂且以状态码 412:Precondition Failed 做为响应返回， 其目的是催促客户端再次发送请求。这样一来，与使用首部字段 If-Range 比起来，就须要花费两倍的功夫。

2.10.Referrer

做用：告诉服务器我是从哪一个页面的连接过来的，服务器籍此能够得到一些信息用于处理；

Referer: http://www.hackr.jp/index.htm

2.11.User-Agent

做用：告诉HTTP服务器，客户端使用的操做系统和浏览器的名称和版本；

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/2010010

不少时候咱们会经过该字段来判断浏览器类型，从而进行不一样的兼容性设计。

3.响应首部字段

3.1.Age

首部字段 Age 能告知客户端，源服务器在多久前建立了响应。字段值的单位为秒。

3.2.ETag

首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式作惟一性标识的方式。服务器会为每份资源分配对应的 ETag值。
另外， 当资源更新时，ETag 值也须要更新。生成 ETag 值时，并无统一的算法规则，而仅仅是由服务器来分配。

与响应头If-None-Match是一对；

3.3.Location

使用首部字段 Location 能够将响应接收方引导至某个与请求 URI 位置不一样的资源。 基本上，该字段会配合 3xx ： Redirection 的响应， 提供重定向的URI。

4.通用首部字段

4.1.Cache-Control

a.请求首部中Cache-Control的指令：

b.响应首部中Cache-Control的指令：

Cache-Control各指令详解：

• public指令：客户端和代理服务器（CDN）能够缓存；

• Private指令：只有客户端能够缓存；

• no-store指令：真正意义上的全部内容都不缓存；

• no-cache指令：正确来讲该指令仍是会使用缓存，只不过使用前要确认其新鲜程度（协商缓存）；

• **s-maxage = x指令 **:代理服务器请求源站缓存后的X秒内再也不发出请求，只对CDN缓存（CDN指的是拥有源服务器资源的多个分布式服务器）有效；

Cache-Control: s-maxage=604800 //（单位 ： 秒）

此外，当使用 s-maxage 指令后，则直接忽略对 Expires 首部字段及max-age 指令的处理。 即优先级为：S-maxage > Max-age > Expires

• Max-age = x指令：请求缓存后的X秒内再也不发起请求。

Cache-Control: max-age=604800 //（单位： 秒）

当客户端发送的请求中包含max-age指令时： 若是断定指定的时间比缓存资源的缓存时间数值更大，那么客户端就接收缓存的资源。另外，当指定 max-age 值为 0（指定时间更小），那么缓存服务器一般须要将请求转发给源服务器。

当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再做确认，而直接把 max-age 数值做为保存为缓存的资源的最长时效。

应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的状况时，会优先处理 max-age 指令，而忽略掉 Expires 首部字段。

4.2.Connection

有两个做用：

• 控制再也不转发给代理的首部字段：

如图中，Connection的值为Upgrade表示不将Upgrade这个首部发给代理；

• 管理持久链接：

a.当Connection ： close 时：

表明一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP链接会关闭（四次挥手）。当客户端再次发送Request，须要从新创建TCP链接（三次握手）。

b.当Connection：Keep-Alive 时：

此时，当一个网页打开完成后（已经创建TCP链接），客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭，若是客户端再次访问这个服务器，会继续使用这条已经创建的链接；

4.3.Via

使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径：

5.实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

5.1.Content-Type

做用：说明报文内对象的媒体类型；

Content-Type: text/html; charset=UTF-8

5.2.Expires

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器（代理服务器）在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在Expires 字段值指定的时间以前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

源服务器不但愿缓存服务器对资源缓存时， 最好在 Expires 字段内写入与首部字段 Date 相同的时间值。

可是，当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。

5.3.Last-Modified

首部字段 Last-Modified 指明资源最终修改的时间。 与请求头If-Modified-Since是一对；

Last-Modeified: Wed, 23 May 2012 09:59:55 GMT

6.为 Cookie 服务的首部字段

Cookie的工做机制是用户识别及状态管理。Web 网站为了管理用户的状态会经过 Web 浏览器，把一些数据临时写入用户的计算机内。接着当用户访问该Web网站时，可经过通讯方式取回以前发放的Cookie;

调用 Cookie 时，因为可校验 Cookie 的有效期，以及发送方的域、路径、协议等信息，因此正规发布的 Cookie 内的数据不会因来自其余Web 站点和攻击者的攻击而泄露。

为 Cookie 服务的首部字段：

6.1.Set-Cookie字段

当服务器准备开始管理客户端的状态时，会事先告知各类信息。

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path

**Set-Cookie 字段的属性 **

• expires 属性：

Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。 这一般限于浏览器应用程序被关闭以前。

另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在能够显式删除 Cookie 的方法。但可经过覆盖已过时的 Cookie，实现对客户端 Cookie 的实质性删除操做。

• domain 属性：

经过 Cookie 的 domain 属性指定的域名可作到与结尾匹配一致。 好比，当指定 example.com 后，除 example.com 之外， www.example.com或 www2.example.com 等均可以发送 Cookie。

所以， 除了针对具体指定的多个域名发送 Cookie 之 外，不指定domain 属性显得更安全。

• secure 属性：

Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全链接时，才能够发送 Cookie。

发送 Cookie 时，指定secure属性的方法以下所示：

Set-Cookie: name=value; secure

以上例子仅当在https://www.example.com/（HTTPS）安全链接的状况下才会进行 Cookie 的回收。也就是说， 即便域名相同，http://www.example.com/（HTTP） 也不会发生 Cookie 回收行为。

当省略 secure 属性时，不论 HTTP 仍是 HTTPS，都会对 Cookie 进行回收。

• HttpOnly 属性：

Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本没法得到 Cookie。 其主要目的为防止跨站脚本攻击（Cross-sitescripting， XSS） 对 Cookie 的信息窃取。

发送指定 HttpOnly 属性的 Cookie 的方法以下所示。

Set-Cookie: name=value; HttpOnly

经过上述设置，一般从Web页面内还能够对 Cookie 进行读取操做。但使用 JavaScript 的 document.cookie 就没法读取附加 HttpOnly 属性后的Cookie的内容了。 所以，也就没法在 XSS 中利用 JavaScript 劫Cookie 了。

6.2.Cookie字段

首部字段 Cookie 会告知服务器，当客户端想得到 HTTP 状态管理支持时， 就会在请求中包含从服务器接收到的 Cookie。 接收到多个Cookie 时，一样能够以多个 Cookie 形式发送。

Cookie: status=enable

4、HTTP请求方法

HTTP/1.1 的经常使用方法 ：

1.GET

GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。

举例：

GET方法也能够用来提交表单和其余数据：

http://localhost/login.php?username=aa&password=1234

从上面的请求URL中，很容易就能辨认出表单提交的内容。HTTP0.9的时候只有GET方法，因此GET方法既能获取数据，也能提交数据，只不过提交的数据是拼接在URL后的不能提交太多且不安全；提交大量数据时使用POST方法。

2.POST

• POST方法功能与GET方法相似，是GET方法的延伸，主要用于向服务器提交数据量较大的用户表单数据；

• 提交的数据放在请求报文的主体中，保证了提交数据的安全；这样就克服了GET方法提交的数据量过小和不能保密的缺点。

• POST方法的主要目的并非获取响应主体的内容；

3.PUT

• PUT方法用来传输文件。 就像 FTP 协议的文件上传同样， 要求在请求报文的主体中包含文件内容， 而后保存到请求URI指定的位置。

• PUT方法和POST很类似，最大的不一样是：PUT是幂等的，POST是不幂等的。 即建立文件使用POST更新文件使用PUT；

幂等：幂等操做的特色是其任意屡次执行所产生的影响均与一次执行的影响相同；

• 可是， 鉴于·HTTP/1.1 的 PUT 方法自身不带验证机制， 任何人均可以上传文件 , 存在安全性问题， 所以通常的 Web 网站不使用该方法。

4.HEAD

HEAD 方法只获取响应报文首部，不返回报文主体部分。 用于确认URI （超连接）的有效性及资源更新的日期时间等。 例如：

5.DELETE

• DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。

• 可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同样不带验证机制，因此通常的 Web 网站也不使用 DELETE 方法。(怎么可能让人随便rm -rf) 举例：

6.OPTIONS

OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。

示例：

7.TRACE

• 客户端经过 TRACE 方法能够查询发送出去的请求是怎样被加工修改/ 篡改的。 这是由于， 请求想要链接到源目标服务器可能会经过代理中转， TRACE 方法就是用来确认链接过程当中发生的一系列操做。

• 可是， TRACE 方法原本就不怎么经常使用， 再加上它容易引起XST（Cross-Site Tracing， 跨站追踪） 攻击， 一般就更不会用到了。

• 发送请求时， 在 Max-Forwards 首部字段中填入数值， 每通过一个服务器端就将该数字减 1， 当数值恰好减到 0 时， 就中止继续传输， 最后接收到请求的服务器端则返回状态码200 OK的响应。

示例：

//请求
TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2

响应：
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024

TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2（返回响应包含请求内容）

8.CONNECT

CONNECT 方法要求在与代理服务器通讯时创建隧道， 实现用隧道协议进行 TCP 通讯。 主要使用 SSL（Secure Sockets Layer， 安全套接层） 和 TLS（Transport Layer Security， 传输层安全） 协议把通讯内容加 密后经网络隧道传输。

//格式
CONNECT 代理服务器名:端口号 HTTP版本

//例子
//请求
CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host: proxy.hackr.jp

//响应
HTTP/1.1 200 OK（以后进入网络隧道）

5、HTTP状态管理

Cookie和Session，实现了HTTP的状态管理，Cookie是在客户端的，Session是在服务器的。

1.Cookie

HTTP 是无状态协议（高效率，不记仇），它不对以前发生过的请求和响应的状态进行管理。也就是说，没法根据以前的状态进行本次的请求处理。

假设要求登陆认证的 Web 页面自己没法进行状态的管理（不记录已登陆的状态） ，那么每次跳转新页面不是要再次登陆，就是要在每次请求报文中附加参数来管理登陆状态。

保留无状态协议这个特征的同时又要解决相似的矛盾问题，因而引入了Cookie技术。Cookie 技术经过在请求和响应报文中写入Cookie信息来控制客户端的状态。

• Cookie其实是一小段文本信息。客户端请求服务器，若是服务器须要记录该用户状态，就向客户端浏览器颁发一个Cookie；
• 客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。

在一个网站地址栏输入：

javascript:alert(document.cookie)

能够弹出该网站的Cookie信息：

Cookie 会根据从服务器端发送的响应报文内的一个叫作 Set-Cookie 的首部字段信息， 通知客户端保存Cookie。当下次客户端再往该服务器发送请求时， 客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务器端发现客户端发送过来的Cookie后， 会去检查到底是从哪个客户端发来的链接请求， 而后对比服务器上的记录， 最后获得以前的状态信息。

第一次：没有 Cookie 信息状态下的请求

• 请求报文（没有 Cookie 信息的状态）

• **响应报文（服务器端生成 Cookie 信息） **

第二次：存有 Cookie 信息状态的请求

• **请求报文（自动发送保存着的 Cookie 信息） **

2.Session

• Session是另外一种记录客户状态的机制，保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上；
• 客户端浏览器再次访问时只须要从该Session中查找该客户的状态就能够了；

Cookie和Session很是类似，Cookie至关于客户端持有的通行证，Session至关于服务器上的通行名册。

保存Session ID的方式

• Cookie
• URL重写
• 隐藏表单

Session的有效期

• Session超时失效：被动失效，若是超过规定时间没有再次访问服务器，Session将失效；
• 程序调用HttpSession.invalidate()：主动失效；
• 服务器进程被中止；

3.Token

Token的引入

Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并做出相应提示，在这样的背景下，Token便应运而生。

Token的定义

Token是服务端生成的一串字符串，以做客户端进行请求的一个令牌，当第一次登陆后，服务器生成一个Token便将此Token返回给客户端，之后客户端只需带上这个Token前来请求数据便可，无需再次带上用户名和密码。最简单的token组成:uid(用户惟一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成必定长的十六进制字符串，能够防止恶意第三方拼接token请求服务器)。

使用Token的目的

Token的目的是为了减轻服务器的压力，减小频繁的查询数据库，使服务器更加健壮。

Session管理及Cookie应用

• 步骤 1：客户端把用户 ID 和密码等登陆信息放入报文的实体部分，一般是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS通讯来进行 HTML表单画面的显示和用户输入数据的发送。

• 步骤 2：服务器会发放用以识别用户的 Session ID。经过验证从客户端发送过来的登陆信息进行身份认证， 而后把用户的认证状态与Session ID 绑定后记录在服务器端。

  向客户端返回响应时，会在首部字段Set-Cookie 内写入 SessionID（如 PHPSESSID=028a8c…） 。

  为防止Session ID 被第三方盗走，服务器端须要对其进行有效性管理；而且为减轻跨站脚本攻击（XSS） 形成的损失，建议事先在 Cookie内加上 httponly 属性。

• 步骤 3： 客户端接收到从服务器端发来的 Session ID 后，会将其做为Cookie 保存在本地。下次向服务器发送请求时，浏览器会自动发送Cookie，因此 Session ID 也随之发送到服务器。服务器端可经过验证接收到的 Session ID 识别用户和其认证状态。

4.Cookie与Session的区别

• 存放位置不一样：Cookie存放在客户端，Session保存在服务器端；
• 安全性（隐私策略）不一样：Cookie存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探或修改Cookie的内容；而Session存储在服务器端，对客户端来讲是透明的；若是想要使用Cookie须要对其进行加密；
• 有效期上的不一样：设置Cookie很大的过时时间，Cookie就能被浏览器保存很长时间；而服务器会按期清理超时的Session ID避免出现过大压力；可是Session依赖于相似Session ID这样的Cookie，而Cookie对Session ID过时时间默许为-1。因此只要关闭了浏览器，即一次会话结束后，该Session就失效了；
• 对服务器形成的压力不一样：Session是保存在服务器端的，每一个用户都产生一个Session，假如并发访问的用户十分多，会产生十分多的Sssion，耗费大量的内存；而Cookie保存在客户端，不太占用服务器的资源；

6、HTTP协议的身份认证

• BASIC认证（基本认证）
• DIGEST（摘要认证）
• SSL客户端认证
• FormBase认证（基于表单认证）

1.BASIC认证

BASIC 认证的认证步骤 ：

• 步骤 1：当请求的资源须要BASIC认证时，服务器会随状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC）及Request-URI安全域字符（realm）。

• 步骤 2： 接收到状态码 401 的客户端为了经过 BASIC 认证， 须要将用户 ID 及密码发送给服务器。 发送的字符串内容是由用户 ID 和密码构成， 二者中间以冒号（:） 链接后，再通过 Base64 编码处理。

  假设用户 ID 为 guest，密码是 guest，链接起来就会造成 guest:guest 这样的字符串。 而后通过 Base64 编码，最后的结果便是Z3Vlc3Q6Z3Vlc3Q=。 把这串字符串写入首部字段 Authorization 后，
  发送请求。

• 步骤 3： 接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。 如验证经过， 则返回一条包含 Request-URI资源的响应。

BASIC 认证虽然采用Base64编码方式，但这不是加密处理。不须要任何附加信息便可对其解码。换言之，因为明文解码后就是用户 ID和密码，在 HTTP 等非加密通讯的线路上进行 BASIC 认证的过程当中，若是被人窃听，被盗的可能性极高。 所以并不经常使用。

2.DIGEST 认证

为弥补·BASIC认证存在的弱点， 从 HTTP/1.1 起就有了 DIGEST 认证。 DIGEST 认证一样使用质询 / 响应的方式
（challenge/response），但不会像 BASIC 认证那样直接发送明文密码。

所谓质询响应方式是指， 一开始一方会先发送认证要求给另外一方， 接着使用从另外一方那接收到的质询码计算生成响应码。 最后将响应码返回给对方进行认证的方式。

由于发送给对方的只是响应摘要及由质询码产生的计算结果，因此比起 BASIC 认证，密码泄露的可能性就下降了。

**DIGEST 认证的认证步骤: **

• 步骤 1：请求需认证的资源时，服务器会随着状态码 401:Authorization Required，返 回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce） 。
  首部字段 WWW-Authenticate 内必须包含 realm 和 nonce 这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。

  nonce 是一种每次随返回的 401 响应生成的任意随机字符串。该字符串一般推荐由 Base64 编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。

• 步骤 2： 接收到 401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。

  首部字段 Authorization 内必须包含 username、 realm、 nonce、 uri 和response 的字段信息。其中，realm 和 nonce 就是以前从服务器接收到的响应中的字段。

• 步骤 3： 接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。 认证经过后则返回包含 Request-URI 资源的响应。而且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。

DIGEST 认证提供了高于BASIC认证的安全等级，可是和 HTTPS 的客户端认证相比仍旧很弱。 DIGEST 认证提供防止密码被窃听的保护机制，但并不存在防止用户假装的保护机制 。所以使用范围不大。

3.SSL 客户端认证

从使用用户ID和密码的认证方式方面来说，只要两者的内容正确便可认证是本人的行为。但若是用户 ID 和密码被盗，就颇有可能第三者冒充。利用 SSL客户端认证则能够避免该状况的发生。

SSL客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登陆的客户端。

SSL 客户端认证的认证步骤 :

为达到 SSL客户端认证的目的 须要事先将客户端证书分发给客户端，且客户端必须安装此证书。

• 步骤 1：接收到须要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。
• 步骤 2：用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

• 步骤 3： 服务器验证客户端证书验证经过后方可领取证书内客户端的165公开密钥， 而后开始HTTPS加密通讯。

SSL 客户端认证采用双因素认证 :

• 在多数状况下，SSL客户端认证不会仅依靠证书完成认证，通常会和基于表单认证组合造成一种双因素认证（Two-factorauthentication） 来使用。

• 换言之，第一个认证因素的 SSL客户端证书用来认证客户端计算机，另外一个认证因素的密码则用来肯定这是用户本人的行为。

• 使用 SSL客户端认证须要用到客户端证书。而客户端证书须要支付必定费用才能使用。

4.基于表单认证

• 基于表单的认证方法并非在HTTP协议中定义的；
• 使用由Web应用程序各自实现基于表单的认证方式；
• 经过Cookie和Session的方式来保持用户的状态（具体见上）；

也就是常见的登陆：

输入已事先登陆的用户 ID（一般是任意字符串或邮件地址） 和密码等登陆信息后，发送给Web应用程序，基于认证结果来决定认证是否成功。

7、HTTP的长链接与短链接

HTTP协议是基于请求/响应模式的，所以只要服务端给了响应，本次HTTP请求就结束了；HTTP的长链接和短链接本质上是TCP的长链接和短链接；

1.短链接

完成一次通讯以后，客户端主动断开TCP链接；

HTTP/1.0中，默认使用的是短链接。也就是说，浏览器和服务器每进行一次HTTP操做，就创建一次链接（三次握手），结束就中断（四次挥手）；

2.长链接

完成一次通讯以后，客户端不主动断开 TCP链接，而是复用该TCP链接；

HTTP/1.1起，默认使用长链接，用以保持链接特性。此时通用首部字段中的Connection字段值为：Keep-Alive；

长链接适用于频繁地传输数据的客户端和服务器，为了防止过多的TCP链接影响服务器性能，须要对长时间不用的链接进行释放；

8、代理、网关与隧道

HTTP 通讯时，除客户端和服务器之外，还有一些用于通讯数据转发的应用程序，例如代理、网关和隧道。它们能够配合服务器工做。

这些应用程序和服务器能够将请求转发给通讯线路上的下一站服务器，而且能接收从那台服务器发送的响应再转发给客户端。

1.代理

代理服务器：

代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

代理服务器的基本行为就是接收客户端发送的请求后转发给其余服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。

持有资源实体的服务器被称为源服务器，从源服务器返回的响应通过代理服务器后再传给客户端。

每次经过代理服务器转发请求或响应时，会追加写入 Via 首部信息。

使用代理服务器的理由：

利用缓存技术（稍后讲解）减小网络带宽的流量，组织内部针对特定网站的访问控制（墙），以获取访问日志为主要目的，等等。

代理使用方法：

代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另外一种是是否会修改报文。

• **缓存代理 **

代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就能够不从源服务器那里获取资源，而是将以前缓存的资源做为响应返回。

• **透明代理 **

转发请求或响应时，不对报文作任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

2.网关

网关是转发其余服务器通讯数据的服务器，接收从客户端发送来的请求时，它就像本身拥有资源的源服务器同样对请求进行处理。有时客户端可能都不会察觉，本身的通讯目标是一个网关。

网关的工做机制和代理十分类似。可是Web网关在一侧使用HTTP协议，在另外一侧使用另外一种协议（好比FTP、SMTP）。

• （HTTP/）服务器端网关：经过HTTP协议与客户端对话，经过其余协议与服务器通讯；
• （/HTTP）客户端网关：经过其余协议与客户端对话，经过HTTP协议与服务器通讯；

常见的网关类型：

• （HTTP/*）服务器端Web网关；

• （HTTP/HTTPS）服务器端安全网关：即客户端用HTTP与网关通讯，网关用HTTPS与服务器通讯；

• （HTTPs/HTTP）客户端安全加速器网关：即客户端用HTTPs与网关通讯，网关用HTTP与服务器通讯；

  也就是安全网关，将经过网关的不安全的HTTP转换为安全的HTTPS;

• 资源网关：客户端经过HTTP链接到应用程序的服务器，服务器并不回送文件，而是将请求经过网关API发送给运行在服务器上的应用程序，应用程序将请求资源会送给客户端。这样的客户端多是一些网络摄像头，电子识别系统等；

利用网关能提升通讯的安全性，由于能够在客户端与网关之间的通讯线路上加密以确保链接的安全。好比，网关能够链接数据库，使用SQL语句查询数据。另外，在 Web 购物网站上进行信用卡结算时，网关能够和信用卡结算系统联动。

3.隧道

隧道可按要求创建起一条与其余服务器的通讯线路，届时使用 SSL等加密手段进行通讯。隧道的目的是确保客户端能与服务器进行安全的通讯。

隧道自己不会去解析 HTTP 请求。也就是说，请求保持原样中转给以后的服务器。隧道会在通讯双方断开链接时结束。

经过隧道的传输，能够和远距离的服务器安全通讯。隧道自己是透明的，客户端不用在乎隧道的存在。

9、HTTP缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减小对源服务器的访问，所以也就节省了通讯流量和通讯时间。

缓存服务器是代理服务器的一种，并归类在缓存代理类型中。换句话说，当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。

缓存服务器的优点在于利用缓存可避免屡次从源服务器转发资源。所以客户端可就近从缓存服务器上获取资源， 而源服务器也没必要屡次处理相同的请求了。

1.缓存的有效期限

即使缓存服务器内有缓存，也不能保证每次都会返回对同资源的请求。由于这关系到被缓存资源的有效性问题。
当赶上源服务器上的资源更新时，若是仍是使用不变的缓存，那就会演变成返回更新前的“旧”资源了。

即便存在缓存，也会由于客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效， 缓存服务器将会再次从源服务器上获取“新”资源。

2.客户端的缓存

缓存不只能够存在于缓存服务器内，还能够存在客户端浏览器中。以Internet Explorer 程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）；

浏览器缓存若是有效，就没必要再向服务器请求相同的资源了，能够直接从本地磁盘内读取；

另外，和缓存服务器相同的一点是， 当断定缓存过时后， 会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。

10、HTTP缓存的工做方式（强制缓存与协商缓存）

1.场景一

让服务器与浏览器约定一个文件过时时间——Expires

在Expires没有过时的状况下，客户端（浏览器）发出请求时，直接使用HTTP本地缓存并返回状态码200，这种HTTP工做方式称为强制缓存；

2.场景二

让服务器与浏览器在约定文件过时时间Expires的基础上，再加一个文件最新修改时间的对比——Last-Modified与if-Modified-Since

• 状况1：若是Expires没有过时，浏览器直接使用HTTP本地缓存，即采用强制缓存；
• 状况2：若是Expires过时了，那么浏览器在请求服务器的时候，就带上了文件最新修改时间，这个字段是在请求头里面加上了If-Modified-Since字段，其实该字段的值就是上次请求时服务器返回的Last-Modified字段的值；服务器会把请求头里文件的最新修改时间If-Modified-Since的值与服务器上的文件最新修改时间Last-Modified的值进行比较：
  • 若是If-Modified-Since 不等于Last-Modified，说明浏览器缓存的资源（f.js）发生改变，服务器就会去查找最新的f.js，同时再次返回Expires、f.js、Last-Modified，返回的状态码为200;
  • 若是If-Modified-Since 等于Last-Modified，说明浏览器缓存的资源（f.js）没有发生改变，浏览器能够继续使用HTTP本地缓存，此时服务器返回状态码304；这种方式称为协商缓存

3.场景三

让服务器在过时时间Expires+Last-Modified的基础上，增长一个文件惟一标识Etag与If-None-Match配成一对使用；除此以外，Expires不稳定，再加入一个Max-age来加以替代（Max-age优先级更高）；

• 在60s内，浏览器再也不向服务器发起请求，直接使用本地缓存这与Expires类似。
• 60s后：浏览器带上If-Modified-Since和If-None-Match（也就是上次服务器返回的Etag值）发起请求，服务器会对比If-None-Match与服务器端的Etag值，这时即便浏览器也提供了If-Modified-Since也不会再与Last-Modified进行对比，由于Etag的优先级比Last-Modified高（更精准）；
  • 若是If-None-Match不等于Etag，说明f.js文件已被修改，服务器就会返回最新的f.js和全新的Etag与Max-age（好比60），固然也会顺便把Expires与Last-Modified返回（尽管没用）；返回的状态码为200；
  • 若是If-None-Match等于Etag，说明f.js文件没有被修改，这时服务器返回的状态码为304，告诉浏览器继续使用原来的本地缓存。这种方式属于协商缓存；

有了Last-Modified为何还要用Etag呢？

你可能会以为使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为何还须要Etag呢？HTTP1.1中Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

• 一些文件也许会周期性的更改，可是他的内容并不改变(仅仅改变的修改时间)，这个时候咱们并不但愿客户端认为这个文件被修改了，而从新GET；
• 某些文件修改很是频繁，好比在秒如下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改没法判断（好比淘宝每ms都会更新数据）；
• 某些服务器不能精确的获得文件的最后修改时间；

这时，利用Etag可以更加准确的控制缓存，由于Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的惟一标识符。 Last-Modified与ETag是能够一块儿使用的，服务器会优先验证ETag，一致的状况下，才会继续比对Last-Modified，最后才决定是否返回304。

4.强制缓存与协商缓存

强制缓存：直接使用HTTP本地缓存，此时服务器返回状态码200；

协商缓存：向服务器确认HTTP本地缓存的资源是否发生变化，没变化后再使用HTTP本地缓存，此时服务器返回状态码304；资源发生变化直接返回最新资源，状态码为200；能够这样理解凡是返回304状态码，都属于协商缓存；

强缓存和协商缓存的区别：

缓存	获取资源形式	状态码	发送请求到服务器
强缓存	从缓存读取	200（From Cache）	否，直接从缓存读取
协商缓存	从缓存读取	304（Not Modified）	是，经过服务器告知浏览器缓存是否可用

请求头Cache-Control的值为no - cache时表示浏览器会先向服务器确认缓存的新鲜度，再决定是否使用缓存，属于协商缓存。

5.缓存改进方案

上述的缓存方案存在一个问题：当Expires或Max-age没有过时时，浏览器没法主动确认本地缓存是否发生变化；

5.1.md5/hash缓存

经过不缓存html，为静态文件添加MD5或者hash标识，解决浏览器没法跳过缓存过时时间主动感知文件变化的问题；具体过程为：第一次加载静态文件时，某位置指定加载f-hash1.js，第二次加载静态文件时同一个位置指定加载f-hash2.js，此时浏览器就会从新向服务器请求数据了；

5.2.CDN缓存（最经常使用）

CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，经过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，下降网络拥塞，提升用户访问响应速度和命中率；

好比能够把CDN理解为各个城市的快递分发站点，源服务器看做快递总仓库；

CDN缓存工做方式：

• 第一次缓存：

• 后续请求：

CDN节点会代替服务器处理浏览器的请求，会有几种状况：

• 状况一：CDN节点缓存的文件还没过时，因而返回304给浏览器，浏览器这次请求被拦截（协商缓存）；
• 状况二：CDN节点发现本身缓存的文件过时了，为了保险起见本身发送请求给服务器成功拿回了最新的数据，而后再交还给浏览器；

能够发现，CDN缓存问题与HTTP缓存是同样的。只不过CDN缓存不过时浏览器始终被拦截，没法拿到最新的文件；另外的不一样点在于CDN至关于一个平台能够手动登陆更新缓存，这也就变相解决了不能控制HTTP本地缓存的问题。

6.浏览器操做对HTTP缓存的影响

用户操做	Expires/Cache-Control	Last-Modified/Etag
地址栏回车	有效	有效
页面连接跳转	有效	有效
新开窗口	有效	有效
前进、后退	有效	有效
F5刷新	无效	有效
Ctrl + F5刷新	无效	无效

由上表可知：对于Last-Modified和Etag字段来讲，只有在进行Ctrl + F5强制刷新时，这两个字段对缓存是否有效的控制才会失效。即强制刷新后，浏览器不会使用本地缓存，而是直接向服务器发起请求。

11、内容协商机制

指客户端和服务器端就响应的资源内容进行交涉，而后提供给客户端最为合适的资源。内容协商会以响应资源的语言，字符集，编码方式等做为判断的基准。

有三种方式：

• 客户端驱动

由客户端发起请求，服务器发送可选项列表，客户端做出选择后在发送第二次请求；

• 服务器驱动

服务器检查客户端的请求头部集并决定提供哪一个版本的页面；

• 透明协商

某个中间设备（一般是缓存代理）表明客户端进行协商；

1.服务器驱动

服务器驱动内容协商：请求首部集；

• Accept：告知服务器发送何种媒体类型；
• Accept-Language：告知服务器发送何种语言；
• Accept-Charset：告知服务器发送何种字符集；
• Accept-Encoding：告知服务器采用何种编码；

服务器驱动内容协商：实体首部集；

• Content-Type
• Content-Language
• Content-Type
• Content-Encoding

与请求首部集一一对应；

12、断点续传和多线程下载

HTTP是经过在Header里两个参数实现的，客户端发出请求时对应的是Range，服务器端响应时对应的是Content-Range，若是续存成功返回206，若是文件有变更返回200和新文件的内容；

1.Range

用于请求头中，指定第一个字节的位置和最后一个字节的位置，格式为：

//格式（左开右闭）
Range:(unit = first byte pos) - [last byte pos]

//示例
Range: bytes=5001-10000

接收到附带 Range 首部字段请求的服务器，会在处理请求以后返回状态码为 206 Partial Content 的响应。 没法处理该范围请求时，则会返回状态码 200 OK 的响应及所有资源。

断点续传过程

• 1.客户端下载一个1024K的文件，已经下载了其中的512K。

• 2.网络中断，客户端请求续传，所以须要在HTTP头中申明本次须要续传的片断： Range:bytes=512000~这个头通知服务器端从文件的512K位置开始传输文件；

• 3.服务器收到断点续传请求，从文件的512K开始传输，而且在HTTP头中增长：

  Content-Range:bytes 512000-/1024000

  而且此时服务端返回的HTTP状态码应该是206 Partial Content，而不是200；

十3、HTTPS

HTTPS使用的是TSL协议（SSL是TSL协议的一种）；

1.HTTPS的功能

• 内容加密
  • 非对称密钥加密：传输公钥时可能被截获并掉包，解决方案：使用第三方机构颁发的证书加密公钥（根据服务器地址等多个信息生成，没法被第三方伪造），浏览器收到后使用证书机构颁发的公钥进行解密（前提是浏览器要信任同一个证书颁发机构）解密结果与用证书生成的规则再生成一个签名对比一致就是真证书；
  • 对称密钥加密：中间人随意截获
• 身份认证
  • 数字证书
• 数据完整性

2.HTTPS的使用成本

HTTPS是一个大趋势

• 证书费用以及更新维护

  • 证书如今不贵，也有免费的；

• HTTPS下降用户访问速度

  • 通过合理的优化（好比SPDY）和部署甚至能够比HTTP1.0快，不过这也是成本之一就是了；

• 消耗CPU资源，须要增长大量机器

  • 须要屡次计算

3.HTTPS对性能的影响

• 协议交互所增长的网络RTP（往返时延）
• 加解密相关计算的耗时

网络耗时：
HTTP只须要经过TCP的三次握手就能创建HTTP链接：

而HTTPS除了TCP的三次握手外，甚至还须要耗费额外的7个RTP进行验证

关于302自动跳转，这是由于，好比访问百度，咱们输入网址全称而是输入baidu.com，因此会自动跳转至HTTPS，这自己也须要耗时；

而且跳转后，URI不同了，浏览器要与服务器从新经过三次握手创建TCP链接；

以后还要进行TLS协商，好比密钥交换算法，对称加密算法，内容一致性校验算法，证书签名算法等等；浏览器获取到证书后，也须要校验证书的有效性，好比证书是否过时，是否撤销等等；

接着，浏览器首先获取证书里的CA域名若是该CA域名没有命中缓存，浏览器须要解析域名的DNS，这个DNS解析至少耗费一个RTP；

DNS解析到IP以后就要完成三次握手，创建CA站点的TCP链接，这又耗费一个RTP；

再接着浏览器发送OCSP请求，获取响应耗费一个RTP；

关于OCSP：在线证书状态协议，它是维护服务器和其余网络资源安全性的两种广泛模式之一，另一个叫作CRL证书注销列表；当用户试图访问一个服务器的时候，在线证书状态协议发送一个对于证书状态信息的请求，服务器会回复一个有效、过时、未知的响应；协议规定了服务器和客户端应用程序通讯的语法；在线证书协议给了用户到期证书一个宽限期，这样用户就能够在更新证书前的一段时间继续访问服务器，因此这里就须要发起一个对于证书状态的请求，也须要消耗一个RTP

最后就是TLS彻底握手阶段2，这个阶段主要进行密钥协商，耗时一个RTP；随后进行应用层的TCP数据通讯。

计算耗时

• 浏览器计算耗时；
• 服务器计算耗时；

4.HTTPS常见问题

• HTTPS须要安装证书

• 大型网站好比百度，从HTTP升级为HTTPS比较困难（不能由于升级而下降用户体验这样就本末倒置了）

• HTTPS并不能解决全部安全问题（好比XSS攻击，木马等），只是能更加安全的传输数据

5.影响HTTP网络请求的因素

• 带宽
• 延迟
  • 一条链接上只可发送一个请求；
  • 请求只能从客户端开始，客户端不能够接收除响应之外的指令；
  • 请求/响应头部不经压缩就发送，每次互相发送相同的头部形成的浪费不少；
  • 非强制压缩发送；

十4、WebSocket

能够理解为WebSocket是为了让HTTP支持长链接而打的一个大补丁；

WebSocket是一个持久化的HTTP，而HTTP自己是非持久化的以下图所示：（虽然有Keep-Alive）

1.WebSocket的握手

请求：

响应：

Upgrade：表示升级为WebSocket

2.WebSocket的做用

HTTP的瓶颈

请求只能从客户端发起，客户端不能够接收除了响应以外的指令；当客户端须要监听服务器上的内容时，在HTTP中有一些优化处理方式，经常使用的用：Ajax轮询，Long Poll

• Ajax轮询

原理为，客户端每隔几秒就发送一次请求，询问服务器到底有没有新消息；如有服务器返回新消息，没有就返回提示信息，如此循环：

• Long Poll长轮询

与Ajax轮询原理类似，客户端先发出请求，直到服务器上有新数据返回以前，都再也不发送请求，如此循环：

缺陷：两种方式都很是消耗资源，Ajax轮询须要服务器有很快地处理速度；Long Poll须要服务器有很大容量；

• 异常状况

WebSocket解决上上述问题

首先使用HTTP协议通知服务器升级到WebSocket协议，随后在WebSocket协议中，服务器端是能够主动推送数据给客户端的，详细过程：

WebSocket的特色

相比于HTTP的长链接，WebSocket具备如下特色

• 真正的全双工方式：服务器能够主动推送，HTTP的长链接仍然是客户端主动发起请求的；

• 减小通讯量：不须要重复传输HTTP Header等信息；

• 持久性链接：只要进行一次HTTP链接，二者就能建立持久的WebSocket链接；

十5、SPDY

SPDY是HTTP的加强，在向下兼容的状况下，在TLS层上新增一层会话层SPDY，使用这个会话层来实现SPDY协议，也就是说现有的服务格式均不用改变吗；SPDY是对HTTP的一个更好的实现和支持；

1.HTTP的缺陷

• 单路链接，请求低效：最大的弊端所在：每一个TCP链接只能对应一个HTTP请求；也就是每一个HTTP请求只能请求一个资源；浏览器只能经过创建多个链接来解决低效问题。
• 对请求严格的先进先出：若是中间的某个请求处理时间比较长的话，就会阻塞后面的请求；
• 只容许由客户端主动发起请求：客户端只能接收服务器发出的响应，服务器没法主动推送信息；
• HTTP的头部冗余：HTTP的头在一个会话里是反复传送的，中间的冗余信息好比：User-Agent、Host的等不须要重复发送的信息也在不断地重复发送，浪费带宽和资源；

2.SPDY的改进

因此基于HTTP的上述缺陷，SPDY进行了如下改进：

• 多路复用请求优化：SPDY规定在一个SPDY链接内能够有无限个并行的请求，即多个并发的请求共用一个TCP会话；只须要创建一个TCP链接就能够传送网页上的全部资源；减小了时延，节省了资源，把TCP链接的效率发挥到了最高；
• 能够设置请求的优先级：没必要遵照HTTP那样的先进先出，而是能够优先传输CSS这些更重要的资源，而后再传输网站图标这样不过重要的资源。
• 支持服务器推送功能：能够实现预加载，好比浏览器请求了style.css，服务器就会主动把style.js推送给浏览器。这样浏览器请求style.js是就能够直接使用本地缓存了；这 与WebSocket不一样在于，这是资源的主动推送；
• SPDY压缩了HTTP头：舍弃了没必要要的Header头，能够节省多余数据形成的等待时间，占据的带宽等；
• 强制使用SSL传输协议：客户端所有的请求都要通过SSL加密后才能传输；

直观的影响

对于前端工程师而言，页面优化永远是一个课题。有了SPDY的请求优化，能够将请求顺序从新编排，这样很大程度上缓解了页面加载时图片请求带来的影响；减小了HTTP的请求；

十6、HTTP2.0

上面所讲的SPDY后来被谷歌放弃了，转而成为了HTTP2.0的前身，基于SPDY的核心改造升级开发出了HTTP2.0。因此二者有比较多类似的地方：

1.HTTP2.0性能加强的核心：二进制分帧

在HTTPS的基础上新增了二进制分帧层：Binary Framing，在该层上HTTP2.0会将全部的传输信息分割成更小的消息和帧，并对其采用二进制格式的编码；

以下图所示：

• 请求头信息被封装进了HEADERS frame中，请求报文主体被封装进了DATA frame中；
• HTTP2.0的通讯都在一个链接上完成，这个链接能够承载任意数量的双向数据流。每一个数据流都以消息的形式发送，而消息由一个或多个帧组成。这些帧能够乱序发送，而后再根据每一个帧首部的流标识符从新组装。

2.HTTP2.0首部压缩

HTTP2.0在服务器端和客户端使用首部表来跟踪和存储以前发送的键值对，对于相同的数据再也不经过每次请求和响应发送，通信期间几乎不会改变通用的键值对，好比：Host、User-agent等只须要发送一次；若是这个请求不包含首部，那么首部的开销就变为0字节了，此时首部都自动使用以前发送请求的首部；

以下图所示，Request # 2中只须要在HEADERS frame里发送:path这个变化的头部便可，其余头部信息直接沿用Request #1的请求头；或者说新增或变化的头部信息会被追加到新的首部表中，如图中的Request #2。它在HTTP2.0的链接存续期内是始终存在的，由客户端和服务器端共同地渐进地更新；

3.HTTP2.0多路复用

多路复用这也是继承于SPDY协议的，HTTP2.0全部的通讯都在一个TCP链接上完成。HTTP2.0把HTTP通讯的基本单位缩小为一个一个的帧，这些帧对应于逻辑流里面的信息，并行的在同一个TCP链接上双向交换；

TCP链接性能的关键在于低延迟。大多数HTTP链接的时间都很短，并且是突发性的，而TCP只在长时间传输链接，传输大块数据的时候效率是最高的；HTTP2.0经过让全部的数据流公用一个TCP链接能够更有效地使用TCP链接，让高带宽也能真正地服务于HTTP的性能提高上。

但连接多资源的优点

• 能够减小服务器创建大量连接的压力，内存占用更少，链接吞吐量变大了。

• 因为TCP链接减小而使网络拥塞情况得以改观；

• 慢启动时间减小，拥塞和丢包恢复速度更快；

也就是说，资源合并减小请求的方式，对于HTTP2.0来讲是没有效果，只会开发者无用的工做量而已。因此当HTTP2.0普及以后，像雪碧图呀，文件合并等就没有多大意义了。

4.并行双向字节流的请求和响应

简单点说就是能够乱序发送，在HTTP2.0上客户端和服务器能够把HTTP数据的消息分解为互不依赖的数据帧，而后乱序发送，最后在接收端把这些乱序帧从新组合起来。如图所示，同一个链接有多个不一样方向的数据流在传输，因此客户端能够一边乱序地发送数据帧，也能够接收服务器的响应；服务器端也是如此都是双向的。

因此：把HTTP消息分解为独立的帧交错发送，而后在另外一端从新组装是HTTP2.0一项很重要的加强；

这一特性会发生连锁反应带来巨大的性能提高：

• 并行交错地发送请求，请求之间互不影响；
• 并行交错地发送响应，响应之间互不干扰；
• 只是用一个链接便可并行发送多个请求和响应；
• 消除没必要要的延迟，减小页面加载的时间；

5.请求优先级

HTTP2.0的这一特性也是继承于SPDY，服务器处理不一样的流采起不一样的优先策略；

• 高优先级的流都应该优先发送；
• 优先级不是绝对的；
• 不一样优先级混合也是必须的；

6.服务器推送

毕竟HTTP2.0的核心是从SPDY的基础上衍生而来的；服务器能够对客户端的一个请求发送多个响应，即除了对最初请求的响应以外服务器还能够额外向服务器推送其余资源，而无需客户端明确请求；如图所示：客户端请求了html文件，服务器就会把js与css文件推送给客户端：

十7、WebDAV协议

WebDAV（Web-based Distributed Authoring and Versioning，基于万维网的分布式创做和版本控制）是一个可对 Web 服务器上的内容直接进行文件复制、编辑等操做的分布式文件系统（可在线修改文件的网盘）。

除了建立、删除文件等基本功能，它还具有文件建立者管理、文件编辑过程当中禁止其余用户内容覆盖的加锁功能， 以及对文件内容修改的版本控制功能。

使用 HTTP/1.1 的 PUT 方法和 DELETE 方法， 就能够对 Web 服务器上的文件进行建立和删除操做。 但是出于安全性及便捷性等考虑，通常不使用。

1.WebDAV 内新增的方法及状态码

WebDAV 为实现远程文件管理，向 HTTP/1.1 中追加了如下这些方法。

方法	用途
PROPFIND	获取属性
PROPPATCH	修改属性
MKCOL	建立集合
COPY	复制资源及属性
MOVE	移动资源
LOCK	资源加锁
UNLOCK	资源解锁

新增状态码：

状态码	含义
102 Processing	可正常处理请求，但目前是处理中状态
207 Multi-Status	存在多种状态
422 UnprocessibleEntity	格式正确，内容有误
423 Locked	资源已被加锁
424 FailedDependency	处理与某请求关联的请求失败，所以再也不维持依赖关系
507 InsufficientStorage	保存空间不足

**WebDAV 的请求实例 **

下面是使用 PROPFIND 方法对 http://www.example.com/file 发起获取属性的请求 :

PROPFIND /file HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 219

//...请求主体

**WebDAV 的响应实例 **

下面是针对以前的 PROPFIND 方法， 返回http://www.example.com/file 的属性的响应。

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 831

//...响应主体

不过能够使用FTP替代它；

十8、HTTP3.0

1.HTTP2.0的问题

• 队头阻塞：因为只创建一个TCP链接，一旦出现某次传输出现丢包，就要等待重传，严重阻碍了其余数据的传输；
• 创建链接的握手延迟大：HTTPS和HTTP2.0除了创建TCP握手以外，还要创建TSL安全传输，这就出现了两次握手延迟；对于短链接来讲，影响没法被移除，这些都是TCP的历史遗留问题；

2.QUIC的特性

• 0 RTP：两层意思，创建UDP链接和创建TSL安全链接大多数状况只须要0 RTP；

• 没有队头阻塞的多路复用

当TCP链接中传输的数据流stream2中出现丢包时，在发送端没有重传丢失的包以前跟在stream2后面的stream3/4就被阻塞住了；

然而UDP链接中，数据流彼此间没有依赖关系，即便stream2出现丢包，也不影响其余stream数据的传输；

• 前向纠错（Front Error Collection）

每一个数据包除了它自己的数据以外，还包括了部分其余包的内容，所以少许的丢包能够经过其余包的冗余数据直接组装，而无需重传；这种方法虽然牺牲了每一个数据包可发送数据的上限，可是减小了由于丢包致使的数据重传（更浪费时间）；若是丢失的包过多，就只能经过重传来解决。

QUIC融合了UDP协议的速度性能和TCP的安全和可靠，大大优化了互联网传输数据的体验。

3.HTTP协议总结

• HTTP1.0/1.1：有链接没法复用、队头阻塞、协议开销大和安全因素等多个缺点；

• HTTP2.0：经过多路复用、二进制流、头部压缩等技术极大地提高了性能，可是仍是存在问题；

• HTTP3.0：QUIC是基于UDP实现的，是HTTP3.0的底层支持协议。该协议基于UDP又吸取了TCP的精华，实现了既快又可靠的链接；

十9、Web安全

1.概述

平常生活中的”安全“

• 为何登陆的时候常常要求咱们输入一个验证码？
• 在一个网站上长时间没有操做，为何Session会失效？

1.1.WASC的定义

全程Web Application Security Consortium：是一个由安全专家、行业顾问和诸多组织的表明组成的国际团体，负责为WWW（万维网）制定广为人知的应用安全标准。

1.2.六类Web应用安全威胁

名称	中文名	做用
Authentication	验证	用来确认某用户、服务或是应用身份的攻击手段
Authorization	受权	用来决定是否某用户、服务或是应用具备执行请求动做必要权限的攻击手段
Client-Side-Attacks	客户侧攻击	用来扰乱或是探测Web站点用户的攻击手段
Command Execution	命令执行	在Web站点上执行远程命令的攻击手段（好比SQL注入）
Information Disclosure	信息泄露	用来获取Web站点具体系统信息的攻击手段
Logical Attacks	逻辑性攻击	用来扰乱或是探测Web应用逻辑流程的攻击手段

1.3.OWASP的定义

全称Open Web Application Security Project，该组织致力于发现和解决不安全Web应用的根本缘由；它们最重要的项目之一是Web应用的十大安全隐患

总结了目前Web应用最常受到的十种攻击手段，而且按照攻击发生的几率进行了排序（如下为2017年的数据）：

排名	漏洞种类	详情
A1	注入	将不受信任的数据做为命令或查询的一部分发送到解析器时，会产生注入：SQL注入、NoSQL注入、OS注入和LDAP注入缺陷。
A2	失效的身份认证	经过错误的使用应用程序的身份认证和会话管理功能，攻击者可以破译密码、密钥或会话令牌
A3	敏感数据泄露	许多Web程序和API都没法正确保护敏感数据，攻击者可经过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃等犯罪行为
A4	XML外部实体（XXE）	许多较早的或配置错误的XML处理器评估的XML文件中的外部实体引用。攻击者可利用外部实体窃取内部文件、执行远程代码
A5	失效的访问控制	未对经过身份验证的用户实施恰当的访问控制
A6	安全配置错误	安全配置错误是最多见的安全问题，这一般是因为不安全的默认配置、不完整的临时配置、开源云错误等形成
A7	跨站脚本（XSS）	XSS让攻击者可以在受害者的浏览器中执行脚本，并劫持用户会话、破坏网站或将用于重定向到恶意站点
A8	不彻底的反序列化	不安全的反序列化会致使远程代码执行
A9	使用含有已知漏洞的组件	组件如库、框架和其余软件模块拥有和应用程序相同的权限
A10	不足的日志记录和监控	不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者可以进一步攻击系统、保持持续性、篡改、提取或销毁数据

2.验证机制

验证机制是Web应用程序中最简单的一种安全机制，也是防护恶意攻击的核心机制；

2.1.典型的身份验证模式

验证技术

• 基于HTML表单的验证
• 多元机制，如组合密码；
• 客户端SSL证书

弱密码

许多Web应用程序没有或不多对用户密码强度进行控制；

暴力破解

登陆功能的公开性会诱使攻击者试图猜想用户名和密码，从而得到访问应用程序的权力；

暴力破解-安全措施

• 验证码技术：最多见和有效的应对方式，须要注意几个问题：

  • 验证码是否真实有用

  • 验证码的复杂度：从最开始的数字，到数字字母组合，再到谷歌奇形怪状的字母；

  • 应对当前的”打码“事业盛行：使用专门平台的”打码“服务器进行破解；对此出现了点击型的验证码、滑动型的验证码、问答型的验证码等更高级的验证码；

• Cookie和会话检测：有些应用程序会设置一个Cookie，如failedlogin = 0；尝试登陆失败，递增该值，达到某个上限，检测到这个值并拒绝再次处理登陆；

  • 这样也不安全，只要客户端的Cookie在到达服务器端前被截获，就能被篡改；

• 双因子认证：双因子认证的核心是综合What you know（我的密码）和What you have（手机）来达到双重认证效果；（较安全经常使用）

3.会话管理机制

• 绝大多数Web应用程序中，会话管理机制是一个基本的安全组件。会话管理机制在应用程序执行登陆功能时尤其重要，由于：它能够在用户经过请求提交它们的证书后，持续向应用程序保证任何特定用户身份的真实性；

• 因为会话管理机制所发挥的关键做用，它们就成为了针对应用程序的恶意攻击的主要目标；

• 若攻击者可以破坏应用程序的会话管理，他就能轻易避开其实施的验证机制，不须要用户证书便可假装成其余应用程序用户。

3.1.会话管理存在的漏洞

• 会话令牌生成漏洞：好比采用常见的算法生成，容易被人猜出算法名称进行反编译破解；

• 令牌可预测：好比隐含序列，事件依赖；

• 会话终止攻击：会话结束后，Cookie没有真正意义上被删除，下次验证还有效；

• 会话劫持攻击：好比网络嗅探、XSS攻击等方式获取用户的会话令牌；

3.2.会话管理漏洞的防护

令牌传输安全

• 令牌只能经过HTTPS传送；
• 若是使用HTTP cookie传送令牌（大多数状况下）应该将Cookie字段标记为Secure，以防止用户浏览器经过HTTP传送它们；

增长软硬会话过时

• 软会话过时：它指的是用户在必定的时间内与应用系统没有交互，则会话过时也就是咱们常说的Session失效；
• 硬会话过时：它指的是用户登陆到系统中通过必定的时间后，无论用户作什么，该会话都会过时（网吧上网时间到了，强制下机）；

二10、常见的网络攻击

1.SQL注入攻击

1.1.SQL注入原理

• 几乎每一个Web应用都须要使用数据库来保存操做所须要的各类信息；
• 因此Web程序是常常会创建用户提交数据的SQL语句；
• 最严重的状况下，攻击者可利用SQL注入，读取甚至修改数据库中保存的全部数据；
• 用户能够提交一段数据库查询代码，根据程序返回结果，得到某些他想得知的数据；

这就是所谓的SQL Injection，即SQL注入；好比：

账户名中输入的‘or’1 = 1会被识别为SQL操做指令；

1.2.SQL注入危害

• 探知数据库的具体结构，为进一步攻击准备；
• 泄露数据，尤为是机密信息、帐户信息等；
• 取得更高权限，用来修改数据甚至是内部结构；

1.3.SQL注入防护

参数化查询

• 参数化查询是对SQL注入根本性的防护策略，也叫作预处理语句，在创建一个包含用户输入的SQL语句时分为两步：

  • 指定查询结构，用户输入预留占位符；
  • 指定占位符内容；

  好比使用问号?看成占位符，这样即便输入了SQL语句这样也不会被认为是数据SQL的一部分，而是用户输入内容。

字符串过滤

使用正则表达式过滤传入的参数

2.跨域脚本攻击（XSS）

跨站脚本攻击（Cross Site Scripting），XSS（CSS已被占用因此叫XSS）是一种常常出如今Web应用中的计算机安全漏洞；

它容许Web用户恶意地将代码植入到提供给其余用户使用的页面中，其余用户在观看网页时，恶意脚本就会执行；

2.1.XSS攻击原理

• 这类攻击一般经过注入HTML或JS等脚本发动攻击；
• 攻击成功后，攻击者能够获得私密网页内容和Cookie等；
• 最近几年XSS攻击已成为最流行的攻击方式；

2.2.XSS攻击危害

• 盗取各种用户帐号：如机器登陆帐号、用户网银帐号、各种管理员帐号；
• 控制数据：包括读取、篡改、添加、删除企业敏感数据的能力；
• 盗窃企业重要的具备商业价值的资料；
• 非法转帐；
• 强制发送网站挂木马；
• 控制受害者机器，让该用户成为"肉机"，向其余网站发起攻击；

2.3.XSS攻击真实案例

Myspace XSS攻击事件

• 2005年，一名叫作samy的用户发现了Myspace（社交网站）的XSS漏洞，他在用户资料页面插入了一些javascript脚本；
• 若是一个用户查看了他的用户资料，这段脚本就会被执行；
• 脚本包括两方面：一是把Samy加为好友，二是将上面说的脚本复制到受害者本身的用户资料页面中；
• 因而，全部查看受害者用户资料的用户也会成为受害者；
• 一个基于存储式XSS攻击的蠕虫迅速扩散，几个小时内，Samy收到了近百万个好友的申请；
• 为此，Myspace被迫关站，修复反XSS过滤机制而且从全部用户的资料中删除含有恶意脚本的内容；

2.4.XSS分类

针对XSS的攻击方式不一样，能够把XSS分为以下三大类：

• 反射式XSS
• 存储式XSS
• 基于DOM的XSS

反射式XSS

也称为非永久性XSS，目前最流行的XSS攻击；它出如今服务器直接服务器直接使用客户端提交的数据，如URL的数据、HTML表单中提交的数据，而且没有对数据进行无害化处理；若是提交的数据中含有HTML控制字符而没有被正确处理，那么一个简单的XSS攻击就会发生。

典型的反射式攻击方式可经过一个邮件或中间网站，诱饵是一个看起来可信任的站点的连接，其中包含XSS攻击脚本，好比社交群中常发的游戏活动、赌博、美女连接等。若是信任的网站没有正确处理这个脚本，用户点击后就会致使浏览器执行含有恶意攻击的脚本。

存储式XSS

也称为永久性XSS，危害更大。攻击将攻击脚本上传到Web服务器上，使得全部访问该页面的用户都面临信息泄露的可能，其中也包括了Web服务器的管理员；

存储式XSS多发生在最终显示给其余用户的位置包含：

• 我的信息字段，如姓名、地址、电子邮件、电话等；
• 文档、上传文件及其余数据的名称；
• 提交给应用程序管理员的反馈或问题；
• 向其余应用程序用户传送的消息、注释、问题等；
• 在用户之间共享的上传文件内容；

典型的存储式XSS攻击过程

• 我拥有一个Web站点，该站点容许用户发布信息/浏览已发布信息；
• 你注意到个人站点具备存储式的XSS漏洞；
• 因而你发布一个热点信息，利用该漏洞获取用户信息，吸引其余用户纷纷阅读；
• 任何其余人浏览该信息，其绘画Cookies或其余信息都会被你盗走；

基于DOM的XSS攻击

反射式XSS攻击和存储式XSS攻击都是经过服务器提取用户提交的数据，而且以不安全的方式将其返回给用户；基于DOM的攻击仅仅经过JavaScript的方式执行；

也就是说这种攻击常发生在应用程序每次返回相同的静态页面（HTML文件），并经过客户端的js文件动态生成信息，并不会与服务器交互获取该js文件的时候；

2.5.XSS攻击载荷

会话令牌

• XSS攻击对广泛的方式；
• 截取一名受害者的会话令牌（Token）,劫持他的会话，进而做为受害者的身份来使用应用程序，执行任意操做并占有该用户的帐号；

虚拟置换

• 这种攻击须要在一个Web应用程序页面注入恶意数据，从而向应用程序的用户传送误导性信息；

• 包括简单的向站点注入HTML，或者使用脚本注入精心设计的内容；

  好比在淘宝的搜索结果页面中注入一个连接，受害者点击后跳转到一个和淘宝很像的钓鱼网页，登陆时账户信息就被泄露了；

• 攻击者实际上没有修改保存在服务器上的内容，而是利用程序处理并显示用户提交的输入方面的缺陷实现置换；

注入木马

• 在一个明显的攻击中，攻击者注入的功能向用户显示一个木马登陆表单，要求他们像攻击者控制的服务器提交他们本身的证书。

2.6.XSS防护措施

输入验证

• 在输入的过程当中，若是应用程序有向后端提交处理的数据，应对这些数据进行严格的确认；
• 好比：数据不能太长；
• 数据仅包含某组合法字符；
• 数据与一个特殊的正则表达式匹配（好比手机号）；
• 根据应用程序但愿在每一个字段中收到的数据类型，尽量限制性地对姓名、电子邮件地址、帐号等应用不一样的确认规则；

输出编码

• 若是应用程序将某位用户或第三方提交的数据复制到它的响应中，那么应用程序应对这些数据进行HTML编码，以净化可能的恶意字符；
• HTML编码指用对应的HTML实体替代字面量字符。这样作可确保浏览器安全处理可能为恶意的字符，把它们看成HTML文档的内容而非结构处理；
• 常常形成问题的字符的HTML编码：
  • ” -> &quot
  • ' -> &#x27
  • < -> &lt
  • > -> &gt
  • / -> x2F

应用程序之因此结合使用输入确认（次要）与输出净化（首要），缘由在于这种方法可以提供两层防护：若是其中一层被攻破，另外一层还能提供一些保护；

3.CSRF攻击

CSRF（Cross-site Request Forgery）跨站请求伪造，也被称为One Click Attack或者Session riding一般缩写为CSRF或者XSRF，是一种对网站的恶意利用；

尽管听起来像跨站脚本（XSS），但它与XSS很是不一样，而且攻击方式几乎相左；

3.1.CSRF攻击原理

• XSS利用站点内的信任用户（受害者），而CSRF经过假装来自受信任用户的请求来利用受信用的网站；

• 经过社会学的手段（如经过电子邮件发送一个连接）来蛊惑受害者进行一些敏感性的操做，如修改密码、修改E-mail、转帐等，而受害者还不知道他已经中招；

3.2.CSRF攻击危害

• CSRF的破坏力依赖于受害者的权限；
• 若是受害者只是个普通用户，则一个成功的CSRF攻击会危害用户的数据以及一些功能；
• 若是受害者具备管理员权限，则一个成功的CSRF攻击甚至会威胁到整个网站的安全；
• 与XSS攻击相比，CSRF攻击每每不太流行，所以对其进行防范的资源也至关稀少，和难以防范；
• 故被认为比XSS更具危险性，因此CSRF在业内有个响当当的名字——沉睡的巨人

3.3.CSRF攻击的特色

• 攻击通常发起在第三方网站，而不是被攻击的网站。被攻击的网站没法防止攻击发生。
• 攻击利用受害者在被攻击网站的登陆凭证，冒充受害者提交操做；而不是直接窃取数据。
• 整个过程攻击者并不能获取到受害者的登陆凭证，仅仅是“冒用”。
• 跨站请求能够用各类方式：图片URL、超连接、CORS、Form提交等等。部分请求方式能够直接嵌入在第三方论坛、文章中，难以进行追踪。

CSRF一般是跨域的，由于外域一般更容易被攻击者掌控。可是若是本域下有容易被利用的功能，好比能够发图和连接的论坛和评论区，攻击能够直接在本域下进行，并且这种攻击更加危险。（好比博客留言）

3.4.CSRF攻击的过程

• 受害者登陆a.com，并保留了登陆凭证（Cookie）；
• 攻击者引诱受害者访问了b.com；
• b.com 向 a.com （服务器）发送了一个请求：a.com/act=xx。浏览器会默认携带a.com发放的Cookie；
• a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误觉得是受害者（a.com的用户）本身发送的请求；
• a.com以受害者的名义执行了act=xx；
• 攻击完成，攻击者在受害者不知情的状况下，冒充受害者，让a.com执行了本身定义的操；

3.5.CSRF攻击预防

CSRF一般从第三方网站发起，被攻击的网站没法防止攻击发生，只能经过加强本身网站针对CSRF的防御能力来提高安全性。

上文中讲了CSRF的两个特色：

• CSRF（一般）发生在第三方域名。
• CSRF攻击者不能获取到Cookie等信息，只是使用。

针对这两点，咱们能够专门制定防御策略，以下：

• 阻止不明外域的访问
  • 同源检测
  • Samesite Cookie
• 提交时要求附加本域才能获取的信息
  • CSRF Token
  • 双重Cookie验证
  • 增长确认操做
  • 从新认证

增长确认操做

• 好比转帐功能，当用户调用API进行转装的时候，弹出一个对话框，例如：你确认转账200元吗？即在浏览器上进行敏感操做时增长确认操做，确保是用户所为；

从新认证

• 在作一些重要敏感的操做时，要求用户从新输入密码进入二次验证，只有正确了才进行操做；这种作法显然更安全，但对于用户来讲不是特别友好——毕竟是增长了异一步操做；
• 因此安全和易用性，有时候不得不作出取舍；

使用Token*

CSRF的一个特征是，攻击者没法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。

而CSRF攻击之因此可以成功，是由于服务器误把攻击者发送的请求当成了用户本身的请求。那么咱们能够要求全部的用户请求都携带一个CSRF攻击者没法获取到的Token。服务器经过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也能够防范CSRF的攻击。

验证过程

• 服务器端：在用户刚登录的时候，产生一个新的不可预知的CSRF Token，而且把此Token存放在用户的session中。
• 在任何一个须要保护的表单中（转帐，该密码），增长一个隐藏的字段来从服务器端获取和存放这个Token；
• 提交请求的时候，在服务器端检查提交的Token与用户Session中的Token是否一致，若是一致，继续处理请求，不一致或者没有的话，就返回一个错误的信息给用户。
• 在用户退出或者Session过时的时候，用户信息（包括CSRF Token）从Session中移除而且销毁Session。

参考资料：大话HTTP协议、《图解HTTP》、前端安全系列之二：如何防止CSRF攻击？