《图解HTTP与HTTPS》

作者: 雾中探雪 | 来源:发表于2021-03-11 14:35 被阅读0次

一、网络基础

Web使用名为HTTP（HyperText Transfer Protocol，超文本传输协议）的协议作为规范，完成从客户端到服务器端等一系列运作流程，而协议是指规则的约定。也可以说Web是建立在HTTP协议上通信的。

1.1 网络基础TCP/IP

通常使用的网络是TCP/IP协议族的基础上运作的，而HTTP属于它内部的一个子集。

1.1.1 TCP/IP协议族

计算机与网络设备要相互通信，双方就必须要基于相同的方法。TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按照层次分别分为以下4层：应用层、传输层、网络层和数据链路层。

应用层

TCP/IP协议族内预存了各类通用的应用服务。比如FTP【文件传输协议】和DNS【域名系统】就是其中两类，当然HTTP协议也在该层。

传输层

传输层对上层应用层提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP【Transmission Control Protocol 传输控制协议】和UDP【User Data Protocol 用户数据报协议】

网络层

网络层用于处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径到达对方计算机，并把数据包传给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层

用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC【网络适配器俗称网卡】及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。

1.1.2 TCP/IP通信传输流

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端从下层往上走。

用HTTP举例子来说明：首先作为发送端的客户端在应用层发出一个想看某个Web页面的HTTP请求：

接着，为了传输方便，在传输层【TCP协议】把从应用层处接收到的数据【HTTP请求报文】进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。

在网络层【IP协议】增加作为通信目的地的MAC地址转发给链路层。

接受端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的HTTP请求。

整个流程图如下：

1.2 域名解析DNS服务

DNS【Domain Nmae System】服务是和HTTP协议一样位于应用层协议。它提供域名到IP地址之间的解析服务。

1.3 各个协议与HTTP协议关系

通过下面一张图，看各个协议在HTTP协议通信中发挥的哪些作用？假设想浏览http://hackr.jp/xss/Web页面

二、简单的HTTP协议

本部分在主要讲述HTTP协议结构，主要使用的是HTTP/1.1

2 .1 通过请求+响应的交换达到通信

看一个具体例子如下：

起始行的Get表示请求访问服务器的类型，称为方法。随后的字符串/index.html指明了请求访问的资源对象。最后的HTTP/1.1 代表HTTP的版本号，用来提示客户端使用的HTTP协议功能。综合来看，请求内容的意思是：请求访问某台HTTP服务器上的/index.html页面的资源。

请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

响应报文基本由协议版本、状态码和原因短语，以及可选的响应首部字段和实体主体构成。

2.2 HTTP是不保存状态的协议

HTTP是一种不保存状态即无状态的协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说HTTP这个级别，协议对于发送过的请求或者响应都不做持久化的处理。下面有一种图便于理解

HTTP1.1 虽然是无状态的协议，但是为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie，就可以管理状态啦【稍后讲述到】

2.3 HTTP请求方法

2.3.1 GET

GET方法用来请求访问已被URI识别的资源。指定的资源经过服务器端解析后返回响应内容。也就是说如果请求的资源是文本，那就保存原样返回，如果是CGI【通用网关接口】那样的程序，则返回经过执行后的输出结果。

2.3.2 POST

POST方法用来传输实体的主体

虽然用GET也可以传输实体的主体，但是一般不用，POST的主要目的并不是获取响应的主体内容。

2.3.3 PUT

PUT方法主要是用来传输文件。

就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。但是HTTP 1.1的PUT方法自身不带验证机制，任何人都可以上传文件，存在安全问题。架构采用REST【表征状态转移】标准的同类Web网站，就可以会开放使用PUT方法。

使用PUT方法的请求-响应的例子

2.3.4 HEAD

HEAD：获得报文首部

HEAD方法和GET方法一样，只是不返回报文主体部分。用于确认URI的有效性及资源更新的日期时间等。

使用HEAD方法的请求-响应的例子

2.3.5 DELETE

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

使用DELETE方法的请求-响应的例子

2.3.6 OPTIONS

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

使用OPTIONS方法的请求-响应的例子

2.3.7 TRACE**

TRACE方法是让Web服务器将之前的请求通信环回给客户端的方法。

客户端通过TRACE方法可以查询发送出去的请求是怎样被加工修改的。这是因为请求想要连接到源目标服务器可能会通过代理中转，TRACE方法就是用来确认连接过程中的发生一系列的操作。

2.3.8 CONNECT

CONNECT要求用隧道协议连接代理

CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要是使用SSL【安全套接字】和TLS【传输层安全】协议把通信内容加密后经网络隧道传输。

CONNECT方法格式如下：

使用 CONNECT 方法的请求·响应的例子

2.4 Cookie的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了 Cookie 技术。Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

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

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

2、第二次【存有Cookie信息状态】的请求

上面展示的是了发生Cookie交互的情景，HTTP请求报文和响应报文的内容如下：

请求报文【没有Cookie信息的状态】
响应报文【服务器端生成Cookie信息】
请求报文【自动发送保存着的Cookie信息】

三、HTTP报文信息

3.1 HTTP报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。

HTTP 报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。

3.2 请求报文和响应报文

3.2.1 请求报文

3.2.2 响应报文

四、HTTP状态码

HTTP 状态码负责表示客户端 HTTP 请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。

4.1 状态码告知服务器返回的请求结果

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

状态码的类别

4.2 2XX成功

2XX 的响应结果表明请求被正常处理了。

4.2.1 200 OK

在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。比如，使用 GET 方法时，对应请求资源的实体会作为响应返回；而使用 HEAD 方法时，对应请求资源的实体首部不随报文主体作为响应返回（即在响应中只返回首部，不会返回实体的主体部分）。

4.2.2 204 No Content

该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如，当从浏览器发出请求处理后，返回 204 响应，那么浏览器显示的页面不发生更新。

4.2.3 206 Partial Content

该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

4.3 3XX重定向

3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

4.3.1 301 Moved Permanently

永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI。也就是说，如果已经把资源对应的 URI保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。
4.3.2 302 Found

临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。和 301 Moved Permanently 状态码相似，但 302 状态码代表的资源不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的URI 将来还有可能发生改变。比如，用户把 URI 保存成书签，但不会像 301 状态码出现时那样去更新书签，而是仍旧保留返回 302 状态码的页面对应的 URI。

4.3.3 303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源。

303 状态码和 302 Found 状态码有着相同的功能，但 303 状态码明确表示客户端应当采用 GET 方法获取资源，这点与 302 状态码有区别。

4.3.4 304 Not Modified

该状态码表示客户端发送附带条件的请求 2 时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

4.4 4XX客户端错误

4XX 的响应结果表明客户端是发生错误的原因所在。

4.4.1 400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

4.4.2 401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示用户认证失败。

4.4.3 403 Forbidden

该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。

4.4.4 404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

4.5 5XX服务器错误

5XX 的响应结果表明服务器本身发生错误。

4.5.1 500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。

4.5.2 503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入RetryAfter 首部字段再返回给客户端。

五、HTTP首部

5.1 HTTP报文首部

HTTP 协议的请求和响应报文中必定包含 HTTP 首部，首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。

HTTP 请求报文

在请求中，HTTP 报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。

下面的示例是访问http://hackr.jp时，请求报文的首部信息

HTTP 响应报文

在响应中，HTTP 报文由 HTTP 版本、状态码（数字和原因短语）、HTTP 首部字段 3 部分构成。

以下示例是之前请求访问 hackr.jp/ 时，返回的响应报文的首部信息。

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。

5.2 HTTP首部字段

5.2.1 HTTP首部字段传递重要信息

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首

部字段，它能起到传递额外重要信息的作用。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

5.2.2 HTTP首部字段结构

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:” 分隔。

首部字段名: 字段值 
复制代码

例如，在 HTTP 首部中以 Content-Type 这个字段来表示报文主体的对象类型。

Content-Type: text/html
复制代码

就以上述示例来看，首部字段名为 Content-Type，字符串 text/html 是字段值。

5.2.3 4种HTTP首部字段类型

HTTP 首部字段根据实际用途被分为以下 4 种类型。

通用首部字段（General Header Fields）：请求报文和响应报文两方都会使用的首部。
请求首部字段（Request Header Fields）：从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信信息、响应内容相关优先级等信息。
响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段（Entity Header Fields）：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

5.2.4 HTTP/1.1 首部字段一览

1. 通用首部字段

2. 请求首部字段

3. 响应首部字段

4. 实体首部字段

5.3 HTTP/1.1 通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。

5.3.1 Cache-Control

通过指定首部字段 Cache-Control 的指令，就能操作缓存的工作机制。

指令的参数是可选的，多个指令之间通过“,”分隔。首部字段 Cache-Control 的指令可用于请求及响应时。

Cache-Control: private, max-age=0, no-cache 
复制代码

Cache-Control 指令一览

缓存请求指令

缓存响应指令

public 指令

Cache-Control: public 
复制代码

当指定使用 public 指令时，则明确表明其他用户也可利用缓存。

private 指令

Cache-Control: private 
复制代码

当指定 private 指令后，响应只以特定的用户作为对象，这与 public指令的行为相反。缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。

no-cache 指令

Cache-Control: no-cache 
复制代码

使用 no-cache 指令的目的是为了防止从缓存中返回过期的资源。客户端发送的请求中如果包含 no-cache 指令，则表示客户端将不会接

收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发给源服务器。

no-store 指令

Cache-Control: no-store 
复制代码

当使用 no-store 指令 1 时，暗示请求（和对应的响应）或响应中包含机密信息。

指定缓存期限和认证的指令

s-maxage 指令

Cache-Control: s-maxage=604800（单位 ：秒）
复制代码

s-maxage 指令的功能和 max-age 指令的相同，它们的不同点是 s-maxage 指令只适用于供多位用户使用的公共缓存服务器 2。也就是

说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。

max-age 指令

Cache-Control: max-age=604800（单位：秒）
复制代码

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。

另外，当指定 max-age 值为 0，那么缓存服务器通常需要将请求转发给源服务器。当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而 max-age 数值代表资源保存为缓存的最长时间。

min-fresh 指令

Cache-Control: min-fresh=60（单位：秒） 
复制代码

min-fresh 指令要求缓存服务器返回至少还未过指定时间的缓存资源。比如，当指定 min-fresh 为 60 秒后，过了 60 秒的资源都无法作为响应返回了。

max-stale 指令

Cache-Control: max-stale=3600（单位：秒）
复制代码

使用 max-stale 可指示缓存资源，即使过期也照常接收。如果指令未指定参数值，那么无论经过多久，客户端都会接收响应；如果指令中指定了具体数值，那么即使过期，只要仍处于 max-stale指定的时间内，仍旧会被客户端接收。

only-if-cached 指令

Cache-Control: only-if-cached 
复制代码

使用 only-if-cached 指令表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新

加载响应，也不会再次确认资源有效性。若发生请求缓存服务器的本地缓存无响应，则返回状态码 504 Gateway Timeout。

5.3.2 Connection

Connection 首部字段具备如下两个作用。

控制不再转发给代理的首部字段
管理持久连接

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

在客户端发送请求和服务器返回响应内，使用 Connection 首部字段，可控制不再转发给代理的首部字段（即 Hop-by-hop 首部）。

** 管理持久连接 **

5.3.3 Via

使用首部字段 Via 是为了追踪客户端与服务器之间的请求和响应报文的传输路径。首部字段 Via 不仅用于追踪报文的转发，还可避免请求

回环的发生。所以必须在经过代理时附加该首部字段内容。

5.4 请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

5.4.1 Accept

Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用 type/subtype 这种形式，一次指定多种媒体类型。

5.4.2 Accept-Charset

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字

段 Accept 相同的是可用权重 q 值来表示相对优先级。

5.4.3 Accept-Encoding

5.5 响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段，用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等

信息。

5.5.1 Accept-Ranges

Accept-Ranges: bytes 
复制代码

首部字段 Accept-Ranges 是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。可指定的字段值有两种，可处理范围请求时指定其为 bytes，反之则指定其为 none。

5.5.2 Age

Age: 600 
复制代码

首部字段 Age 能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。若创建该响应的服务器是缓存服务器，Age 值是指缓存后的响应再次发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age

5.5.3 Location

使用首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。几乎所有的浏览器在接收到包含首部字段 Location 的响应后，都会强制性地尝试对已提示的重定向资源的访问。

5.6 实体首部字段

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

5.6.1 Allow

Allow: GET, HEAD 
复制代码

首部字段 Allow 用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码

405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回。

5.6.2 Content-Type

Content-Type: text/html; charset=UTF-8 
复制代码

首部字段 Content-Type 说明了实体主体内对象的媒体类型。和首部字段 Accept 一样，字段值用 type/subtype 形式赋值。

5.6.3 Expires

Expires: Wed, 04 Jul 2020 08:26:05 GMT 
复制代码

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在

Expires 字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求

资源。

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

5.6.4 Last-Modified

Last-Modified: Wed, 23 May 2020 09:59:55 GMT 
复制代码

首部字段 Last-Modified 指明资源最终修改的时间。一般来说，这个值就是 Request-URI 指定资源被修改的时间。但类似使用 CGI 脚本进

行动态数据处理时，该值有可能会变成数据最终修改时的时间。

5.7 为Cookie服务的首部字段

5.7.1 Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2020 07:26:31
复制代码

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

Set-Cookie字段值

5.7.2 Cookie

Cookie: status=enable 
复制代码

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

Cookie 时，同样可以以多个 Cookie 形式发送。

上面讲述了很多理论的知识，大家坚持坚持，当你很累的时候，是在走上坡的路，加油坚持！！！

六、HTTPS-确保Web安全

6.1 HTTP的缺点

HTTP主要有以下不足：

无法证明报文的完整性，所以有可能已遭篡改
通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，因此有可能遭遇伪装

6.2 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访问 HTTPS 通信有效的 Web 网站时，浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。

6.2.1 HTTPS是身披SSL外壳的HTTP

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

在采用 SSL后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

SSL是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL协议使用。可以说 SSL是当今世界上应用最为广泛的网络安全技术。

6.2.2 相互交换密钥的公开密钥加密技术

SSL采用一种叫做公开密钥加密（Public-key cryptography）的加密处理方式。

加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也

就失去了意义。

1. 共享密钥加密的困境

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

密钥发送出现的问题：

2. 使用两把密钥的公开密钥加密

公开密钥加密方式很好地解决了共享密钥加密的困难。

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

3. HTTPS采用混合加密机制

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

所以应充分利用两者各自的优势，将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

4. 证明公开密钥正确性的证书

公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

为了解决上述问题，可以使用由数字证书认证机构（CA，CertificateAuthority）和其相关机关颁发的公开密钥证书。

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。来介绍一下数字证书认证机构的业务流程。首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的，因此，多数浏览器开发商发布

版本时，会事先在内部植入常用认证机关的公开密钥。

5. HTTPS 的安全通信机制

为了更好地理解 HTTPS，我们来观察一下 HTTPS 的通信步骤。

步骤 1：客户端通过发送 Client Hello 报文开始 SSL通信。报文中包含客户端支持的 SSL的指定版本、加密组件（Cipher Suite）列表（所

使用的加密算法及密钥长度等）。

步骤 2：服务器可进行 SSL通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。

步骤 3：之后服务器发送 Certificate 报文。报文中包含公开密钥证书。

步骤 4：最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL握手协商部分结束。

步骤 5： SSL第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master

secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。

步骤 6：接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。

步骤 7：客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确

解密该报文作为判定标准。

步骤 8：服务器同样发送 Change Cipher Spec 报文。

步骤 9：服务器同样发送 Finished 报文。

步骤 10：服务器和客户端的 Finished 报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到 SSL的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。

步骤 11：应用层协议通信，即发送 HTTP 响应。

步骤 12：最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP的通信。

下面是对整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书（服务器证书）建立 HTTPS 通信的整个过程。

拓展1：SSL 速度慢吗？

HTTPS 也存在一些问题，那就是当使用 SSL时，它的处理速度会变慢。

SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。

和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL通信，因此整体上处理通信量不可避免会增加。

另一点是 SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地

消耗服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍 SSL的计算速度。仅在 SSL处理时发挥 SSL加速器的功效，以分担负载。

拓展2：为什么不一直使用 HTTPS？

既然 HTTPS 那么安全可靠，那为何所有的 Web 网站不一直使用HTTPS ？

其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。

特别是每当那些访问量较多的 Web 网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都

进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。

要进行 HTTPS 通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不

同。通常，一年的授权需要数万日元（现在一万日元大约折合 600人民币）。钱钱钱呀，嘿嘿嘿

七、确认访问用户身份的认证

某些 Web 页面只想让特定的人浏览，或者干脆仅本人可见。为达到这个目标，必不可少的就是认证功能。下面我们一起来学习一下认证

机制。

HTTP 使用的认证方式

BASIC认证【基本认证】
DIGEST认证【摘要认证】
SSL客户端认证
FormBase认证【基于表单认证】

7.1 BASIC认证

BASIC 认证（基本认证）是从 HTTP/1.0 就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是 Web 服务器与通信

客户端之间进行的认证方式。

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

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

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

BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户 ID和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中，如果被人窃听，被盗的可能性极高。

BASIC 认证使用上不够便捷灵活，且达不到多数 Web 网站期望的安全性等级，因此它并不常用。

7.2 DIGEST 认证

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

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

步骤 1：请求需认证的资源时，服务器会随着状态码 401Authorization Required，返回带 WWW-Authenticate 首部字段的响应。

该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。

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

步骤 3：接收到包含首部字段 Authorization 请求的服务器，会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。

并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。

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

DIGEST 认证和 BASIC 认证一样，使用上不那么便捷灵活，且仍达不到多数 Web 网站对高度安全等级的追求标准。因此它的适用范围也

有所受限。

7.3 SSL客户端认证

SSL客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书（在 HTTPS 一章已讲解）认证，服务器可确认访问是否

来自已登录的客户端。

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

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

步骤 1：接收到需要认证资源的请求，服务器会发送 CertificateRequest 报文，要求客户端提供客户端证书。

步骤 2：用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

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

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

在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证（稍后讲解）组合形成一种双因素认证（Two-factor authentication）来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为

另一个因素，与其组合使用的认证方式。

换言之，第一个认证因素的 SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。

7.4 基于表单认证

基于表单的认证方法并不是在 HTTP 协议中定义的。客户端会向服务器上的 Web 应用程序发送登录信息（Credential），按登录信息的验

证结果认证。这个不做深讲。

八、基于HTTP的功能追加协议

8.1 消除HTTP瓶颈的SPDY

Google 在 2010 年发布了 SPDY（取自 SPeeDY，发音同 speedy），其开发目标旨在解决 HTTP 的性能瓶颈，缩短 Web 页面的加载时间

（50%）。

8.1.1 HTTP的瓶颈

为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的，

但 HTTP 却无法妥善地处理好这项任务。

使用 HTTP 协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。

8.1.2 SPDY消除 Web 瓶颈了吗

希望使用 SPDY 时，Web 的内容端不必做什么特别改动，而 Web 浏览器及 Web 服务器都要为对应 SPDY 做出一定程度上的改动。有好

几家 Web 浏览器已经针对 SPDY 做出了相应的调整。另外，Web 服务器也进行了实验性质的应用，但把该技术导入实际的 Web 网站却

进展不佳。因为 SPDY 基本上只是将单个域名（ IP 地址）的通信多路复用，所以当一个 Web 网站上使用多个域名下的资源，改善效果就会受到限制。

SPDY 的确是一种可有效消除 HTTP 瓶颈的技术，但很多 Web 网站存在的问题并非仅仅是由 HTTP 瓶颈所导致。对 Web 本身的速度提升，还应该从其他可细致钻研的地方入手，比如改善 Web 内容的编写方式等。

8.2 使用浏览器进行全双工通信的WebSocket

利用 Ajax 和 Comet 技术进行通信可以提升 Web 的浏览速度。但问题在于通信若使用 HTTP 协议，就无法彻底解决瓶颈问题。WebSocket网络技术正是为解决这些问题而实现的一套新协议及 API。

8.2.1 WebSocket的设计与功能

WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准。其中，WebSocket 协议由 IETF 定为标准，WebSocket API 由 W3C 定为标准。仍在开发中的 WebSocket 技术主要是为了解决 Ajax 和 Comet里 XMLHttpRequest 附带的缺陷所引起的问题。

8.2.2 WebSocket协议与特点

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片等任意格式的数据。

下面我们列举一下 WebSocket 协议的主要特点。

1. 推送功能

支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。

2. 减少通信量

只要建立起 WebSocket 连接，就希望一直保持连接状态。和 HTTP 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应减少了。

8.3 期盼已久的 HTTP/2.0

目前主流的 HTTP/1.1 标准，自 1999 年发布的 RFC2616 之后再未进行过改订。SPDY 和 WebSocket 等技术纷纷出现，很难断言 HTTP/1.1仍是适用于当下的 Web 的协议。

HTTP/2.0 围绕着主要的 7 项技术进行讨论，现阶段（2012 年 8 月 13日），大都倾向于采用以下协议的技术。但是，讨论仍在持续，所以

不能排除会发生重大改变的可能性。

九、Web的攻击技术

9.1 针对Web的攻击技术

简单的 HTTP 协议本身并不存在安全性问题，因此协议本身几乎不会成为攻击的对象。应用 HTTP 协议的服务器和客户端，以及运行在服

务器上的 Web 应用等资源才是攻击目标。

9.1.1 HTTP不具备必要的安全功能

开发者需要自行设计并开发认证及会话管理功能来满足 Web应用的安全。而自行设计就意味着会出现各种形形色色的实现。结

果，安全等级并不完备，可仍在运作的 Web 应用背后却隐藏着各种容易被攻击者滥用的安全漏洞的 Bug。

9.1.2 在客户端即可篡改请求

在 HTTP 请求报文内加载攻击代码，就能发起对 Web 应用的攻击。通过 URL查询字段或表单、HTTP 首部、Cookie 等途径把攻击代码传

入，若这时 Web 应用存在安全漏洞，那内部信息就会遭到窃取，或被攻击者拿到管理权限。

9.1.3 针对Web应用的攻击模式

对Web应用的攻击模式有以下两种

主动攻击
被动攻击

主动攻击

主动攻击（active attack）是指攻击者通过直接访问 Web 应用，把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的资源进行攻击，因此攻击者需要能够访问到那些资源。

主动攻击模式里具有代表性的攻击是 SQL注入攻击和 OS 命令注入攻击。

被动攻击

利用用户的身份攻击企业内部网络

利用被动攻击，可发起对原本从互联网上无法直接访问的企业内网等网络的攻击。只要用户踏入攻击者预先设好的陷阱，在用户能够访问到的网络范围内，即使是企业内网也同样会受到攻击。

9.2 因会话管理疏忽引发的安全漏洞

会话管理是用来管理用户状态的必备功能，但是如果在会话管理上有所疏忽，就会导致用户的认证状态被窃取等后果。

9.2.1 会话劫持

会话劫持（Session Hijack）是指攻击者通过某种手段拿到了用户的会话 ID，并非法使用此会话 ID 伪装成用户，达到攻击的目的。

具备认证功能的 Web 应用，使用会话 ID 的会话管理机制，作为管理认证状态的主流方式。会话 ID 中记录客户端的 Cookie 等信息，服务

器端将会话 ID 与认证状态进行一对一匹配管理。

下面列举了几种攻击者可获得会话 ID 的途径。

通过非正规的生成方法推测会话 ID
通过窃听或 XSS 攻击盗取会话 ID
通过会话固定攻击（Session Fixation）强行获取会话

9.2.2 会话固定攻击

对以窃取目标会话 ID 为主动攻击手段的会话劫持而言，会话固定攻击（Session Fixation）攻击会强制用户使用攻击者指定的会话 ID，属于被动攻击。

9.3 密码破解

密码破解攻击（Password Cracking）即算出密码，突破认证。攻击不仅限于 Web 应用，还包括其他的系统（如 FTP 或 SSH 等），本节将会讲解对具备认证功能的 Web 应用进行的密码破解。

密码破解有以下两种手段。

通过网络的密码试错
对已加密密码的破解（指攻击者入侵系统，已获得加密或散列处理的密码数据的情况）- 除去突破认证的攻击手段，还有 SQL注入攻击逃避认证，跨站脚本，攻击窃取密码信息等方法。
通过网络进行密码试错

9.4 DoS攻击

DoS 攻击（Denial of Service attack）是一种让运行中的服务呈停止状态的攻击。有时也叫做服务停止攻击或拒绝服务攻击。DoS 攻击的对象不仅限于 Web 网站，还包括网络设备及服务器等。

主要有以下两种 DoS 攻击方式。

集中利用访问请求造成资源过载，资源用尽的同时，实际上服务也就呈停止状态。
通过攻击安全漏洞使服务停止。

其中，集中利用访问请求的 DoS 攻击，单纯来讲就是发送大量的合法请求。服务器很难分辨何为正常请求，何为攻击请求，因此很难防

止 DoS 攻击。

多台计算机发起的 DoS 攻击称为 DDoS 攻击（Distributed Denial ofService attack）。DDoS 攻击通常利用那些感染病毒的计算机作为攻击者的攻击跳板。

总结

上面大致讲完了图解HTTP的基本内容，以及HTTPS如何演变过来的。