《图解HTTP》

本书非常适合初学之进行HTTP协议的学习，逻辑清晰，配图生动，本文会对关键部分进行不配图的摘录，方便读者进行复习或初学者进行简单了解。

1 了解Web及网络基础

1.1 使用HTTP协议访问web

Web页面不能凭空显示，根据Web浏览器中指定的URL，Web浏览器从Web服务器端获取文件资源（resource）等信息，从而显示出Web页面
像这种通过发送请求获取服务器资源的Web浏览器等，都可以成为客户端（client）
Web使用一种名为HTTP（HyperText Transfer Protocol），超文本传输协议的协议作为规范，完成从客户端到服务器等一系列运作流程
可以说，web是建立在HTTP协议上通信的

1.2 HTTP的诞生

1.2.1 为知识共享而规划Web

从前互联网只属于少数人，此时HTTP诞生，为了共享知识
最初设计理念：借助多文档之间的相互关联形成的超文本（HyperText），连成可以互相参阅的万维网（World Wild Web）
已经提出的WWW构建技术
- SGML
- HTML
- HTTP
- URL

1.2.2 Web成长时代

1.2.3 驻足不前的HTTP

HTTP/0.9 没有作为正式标准被建立，HTTP1.0之前版本的意思
HTTP/1.0 1996年5月正式被公布，记载于RFC1945，广泛应用
HTTP/1.1

1.3 网络基础TCP/IP

为了理解HTTP，有必要事先了解一下TCP/IP协议族。

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

因为本书为《图解HTTP》，因此仅做了需要学习本协议需要掌握的TCP/IP协议族概要，具体可以参阅我的另一篇博客：《TCP/IP》

1.3.1 TCP/IP协议族

计算机与网络设备需要通信，双方就必须基于相同的方法。不同的硬件，操作系统之间的通信，所有的一切都需要一种规则，我们把这种规则称为协议。

协议中存在各式各样的内容，从电缆规格到IP选定方法，寻找异地用户方法，Web页面需要做的处理等…

像这样把与互联网相关联的协议集合起来总称为TCP/IP。有说法认为这是TCP和IP两种协议，我比较倾向于这是在通信过程中需要使用到的协议族的统称。

1.3.2 TCP/IP的分层管理

本书中说按照TCP/IP协议族按层次分为自顶向下4层：应用层、传输层、网络层和数据联络层。经过校内计算机网络课程的学习应该是五层：应用层、传输层、网络层、数据联络层和物理层。

分层的好处：某处需要改变设计时，仅需要替换变动的层，不需要整体改动，设计也会相对简单，只需要考虑分派给自己的任务。分层不多做赘述。

1.3.3 TCP/IP通信传输流

发送端从应用层往下走，接收端则从下层往上走

应用层：生成HTTP数据（报文）
传输层：添加TCP首部
网络层：添加IP首部形成IP报文
链路层：添加以太网首部形成MAC帧
物理层：在物理媒介上传输
发送层在层与层之间传输数据时，每经过一层必定会被打上一个该层所属的首部信息。反之，接收端在层与层之间传输数据时，每经过一层，就会把对应的首部消去。这种把数据包装起来的做法称为封装（encapsulate）

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

1.4.1 负责传输的IP协议

IP（Internet Protocol）：几乎所有网络系统都会用到IP协议
IP地址指明了被分配到的地址，MAC地址指网卡所属的固定地址，IP地址可以和MAC地址进行配对
IP地址可以变换，但MAC地址基本上不会更改
使用ARP（Address Resolution Proto）协议凭借MAC地址进行通信
IP间通信依赖MAC地址，网络上通信双方在同一个内网（LAN）内的情况很少，通常是通过多台计算机和网络设备的中转才能连接到对方，进行中转时，会利用下一台中转设备的MAC地址来搜索下一个中转目标。这时会采用ARP协议，用于解析地址，根据通信方的IP地址就可以反查出对应的MAC地址
没有人可以全面掌握互联网中的传输情况：路由选择

1.4.2 确保可靠性的TCP协议

TCP位于传输层，提供可靠的字节流服务
把大数据块分割成以报文段为单位的数据包进行管理
TCP协议能够确认数据最终是否送达到对方（三次握手，四次挥手）

1.5 负责域名解析的DNS服务

提供域名到IP地址之间的解析服务
计算机既可以被赋予IP地址，也可以被赋予主机名和域名
DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务

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

举例说明：

想浏览一个页面
通过DNS解析IP地址
生成对目标Web服务器的HTTP请求报文
客户端TCP把HTTP报文分割成报文段然后可靠传输
网络层IP搜索对方的地址，一边中转一遍传送
服务器端TCP重组到达的报文段
服务器端HTTP对Web服务器请求的内容进行处理
结果也利用TCP/IP回传给客户端

1.7 URI和URL

1.7.1 统一资源标识符

URL（Uniform Resource Locator）：表示某一互联网资源
URI（Uniform Resource Identifier）：表示了资源的地点
- 登陆信息
- 服务器地址
- 服务器端口号
- 带层次的文件路径
- 查询字符串
- 片段标识符
URL是URI的子集

RFC：制定HTTP协议技术标准的文档
（Request for Comments，征求修正意见书）

2 简单的HTTP协议

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

HTTP和TCP/IP协议族呢爹众多其他协议相同，都用于客户和服务器之间的通信

请求访问的一端称为客户端，而提供资源响应的称为服务端

使用HTTP协议就可以明确区分哪一段是客户端，哪一段是服务端

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

请求必定由客户端发出，而由服务器端回复响应，书上还有一些具体通信的例子，在此不举例

2.3 HTTP是不保存状态的协议

无状态（stateless）协议：不对请求和响应之间的通信状态进行保存
为了更快处理大量事务，确保协议的可伸缩性
随着Web发展，需要保存用户的状态（如：购物网站）
引入Cookie技术，有了Cookie再用HTTP协议通信，就可以管理状态了。

2.4 请求URI定位资源

HTTP使用URI定位互联网上的资源，正是因为URI的特定功能，在互联网上任意位置的资源都能访问到。

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

GET：获取资源（CGI（Common Gateway Interface ，通用网关接口）返回执行后的输出）
POST：传输实体主体（目的不是获取响应的主体内容）
PUT：传输文件一般Web不用，因为不带自身验证机制，任何人都可以上传（REST架构or配合Web应用程序的验证机制才开放使用PUT）
HEAD：获得报文首部（一般用于确认URI资源的有效性和更新的日期等）
DELETE：删除文件（与PUT相反）
TRACE：追踪路径（让Web服务器将之前的请求通信环回给客户端的方法，不常用，容易引发XST（Cross-Site Tracing），跨站攻击）
CONNECT：要求用隧道协议连接代理（实现用隧道协议进行TCP通信，主要是用SSL和TLS协议把通信内容加密后经过网络隧道传输）

2.6 使用方法下达命令

都用大写字母

2.7 持久连接节省通信量

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。
每次请求都会造成无谓的TCP连接建立和断开，增加通信量的开销。

2.7.1 持久连接

为解决TCP连接问题，HTTP/1.1和一部分HTTP/1.0想出了持久连接，称为HTTP keep-alive或者HTTP connection reuse 方法。（面经）
特点：只要任意一段没有明确提出断开连接，就会保持TCP连接状态
减少TCP重复建立和断开造成的额外开销，减轻了服务器的负载
在HTTP/1.1中，所有的连接默认都是持久连接，但在HTTP/1.0中并未标准化（面经）
除了服务器端，客户端也需要支持持久连接

2.7.2 管线化

持久连接使得多数请求以管线化（pipelining）方式发送成为可能，从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后不用等待响应亦可发送下一个请求
相比挨个连接，用的持久连接可以让请求更快结束，而管线化技术比持久连接更加快，请求的次数越多，时间差就越明显

2.8 使用Cookie的状态管理

HTTP是无状态的协议
- 不必保存状态，减少CPU和内存的消耗
- 正因为简单，才能被应用在各种场景里
如果要求登陆认证的Web页面本身无法进行状态的管理，每次刷新页面需要
- 再次登陆
- 在请求报文中附加参数来管理登陆状态
保留无状态的特征，又要解决类似的矛盾问题，引入了Cookie技术。

Cookie技术

通过在请求和响应报文中写入Cookie信息来控制客户端的状态
Cookie会根据从服务端发送的根据响应报中的Set-Cookie的首部字段信息，通知客户端保存Cookie
下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值发送出去
客户端收到Cookie后会检查究竟从哪个客户端发来的连接请求，然后对比服务器上的记录得到之前的状态信息。

没有Cookie时：客户端向服务器发送一个请求报文，服务端生成Cookie记住是向谁发送的，在响应报文中添加Cookie后返回，客户端会保存Cookie

存有Cookie后：客户端会在请求报文中添加Cookie发送给服务端，服务端进行Cookie的检查后进行响应，这样服务器就能分清客户端是谁

3 HTTP报文内的HTTP信息

3.1 HTTP报文

用于HTTP协议交互的信息被称为HTTP报文，本身是由多行数据构成的字符串文本

HTTP报文

报文首部（客户/服务端需要处理的请求/响应的内容及属性）
空行（CR+LF）（回车符+换行符）
报文主体（应该发送的数据）
客户端：请求报文
服务端：响应报文

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

1-请求报文

报文首部
- 请求行：包含用于请求的方法、URI、HTTP版本
- 请求首部字段
- 通用首部字段
- 实体首部字段
- 其他

2-响应报文

报文首部
- 状态行：包含表示请求和相应的各种条件和属性的各类首部
- 响应首部字段
- 通用首部字段
- 实体首部字段
- 其他

3.3 编码提升传输速率

HTTP在传输数据：

按照数据原貌直接传输：
通过编码提升传输速率：需要依靠计算机完成，因此消耗更多CPU等资源

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

报文：HTTP通信中的基本单位，由8位组字节流组成，通过HTTP通信传输
实体：作为请求或响应的有效载荷被传输，由实体首部和实体主体组成
通常，报文主体等于实体主体。

当传输中进行编码操作时，实体主体的内容发生变化，导致和报文主体产生差异。

3.3.2 压缩传输的内容编码

以邮件发送为例，为了让邮件的容量变小，我们可能会先用ZIP压缩文件之后再添加附件进行发送。HTTP协议中有一种被称为内容编码的功能也能进行类似的操作。
内容编码必须指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由服务端接受并负责解码

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

HTTP通信过程中，请求编码实体资源尚未完全传输完成之前，浏览器无法显示请求页面。

在传输大容量数据时，通过把数据分割成多块，可以让浏览器逐步显示页面

HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可以在通信时按照某种编码方式传输，但只定义作用于分块传输编码中（面经）

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

发送邮件时，我们可以在邮件里写入文字并添加多份附件。这是因为采用了MIME（Multipurpose Internet Mail Extensions 多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频多个不同类型的数据。

例如图片等二进制数据都是以ASCII码字符串编码的方式指明，就利用MIME来表述标记数据类型。在MIME扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳不同类型的数据。

相应HTTP报文中可以有多种类型的实体

multipart/form-data（Web表单文件上传时使用）
multipart/byteranges（状态码206（Partial Content 部分内容）响应报文包含了多个范围的内容时使用）
使用多部分对象集合时，需要在首部字段里加上Content-type字段
使用boundary字符串来划分多部分对象集合指明的各类实体
每个部分类型都可以含有首部字段，另外可以嵌套使用多部分对象集合

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

从前互联网不好的时候，碰见网络中断就须从头开始下载。

为解决此问题需要可恢复机制

要实现该功能就需要指定下载的实体范围，这样的请求叫做范围请求（Range Request）

针对范围请求，相应会返回状态码为206的响应报文。另外，对于多重范围的范围请求，响应会在首部字段Content-Type标明 multipart/byteranges 后返回响应报文。

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

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

同一个Web网站有可能存在多分同样内容，比如Google英文和中文版

当浏览器的默认语言为英文or中文，访问URI也会显示对应的英语班或中文版的Web页面

服务器判断的首部字段：

Accept
Accept-Charset （字符集）
Accept-Encoding （编码方式）
Accept-Language （可接受语言）
Content-Language （内容语言）

内容协商技术的类型：

服务器驱动协商：以请求的首部字段为参考（以浏览器发送的信息作为判定的依据）
客户端驱动协商：用户从浏览器选择的可选项列表中手动选择（比如按照OS的类型或浏览器类型，自行切换PC版页面或者手机版页面）
透明协商：服务器端和客户端各自进行内容协商的一种方法

4 返回结果的HTTP状态码

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

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

状态码的指责时当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是否正常处理请求，以三维数字和原因短语组成

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

4.2 2XX 成功

200 OK

表示从客户端发来的请求在服务器端被正常处理了

204 No Content

表示请求已经成功处理，但响应报文中不含实体的主体部分，也不允许返回任何实体主体

一般只需要从客户端往服务器发送信息，而服务器不需要发送新信息内容的情况下使用

206 Partial Content

表示客户端进行了范围请求，服务器成功执行请求。
（包含Content-Range字段指定的实体内容）

4.3 3XX 重定向

301 Moved Permanently

永久性重定向

表示请求的资源被分配了新的URI，应该按照响应报文的Location字段重新找到它

302 Found

临时性重定向

表示请求的资源被分配了新的URI，希望用户本次能使用新的URI访问

304 Not Modified

表示客户端发送带条件的请求时，服务器端允许请求访问资源，但存在未满足条件的情况。
（与重定向无关）

307 Temporary Redirect

临时重定向

与 302 Found 有相同的含义

4.4 4XX 客户端错误

400 Bad Request

表示请求报文中存在语法错误，需要修改请求的内容

401 Unauthorized

表示发送的请求需要有通过HTTP认证的认证信息

若之前已经进行过1次请求，则表示用户认证失败

返回含有401的响应必须包含适用于被请求字段的 WWW-Authenticate 首部质询用户信息

403 Forbidden

表示对资源的访问被拒绝，或是未获得文件系统的访问授权（从未授权的IP试图访问）

404 Not Found

服务器上无法找到请求的资源。也可以在服务器端拒绝请求且不想说明理由的时候使用

4.5 5XX 服务器错误

500 Internal Server Error

表示服务器端在执行请求时发生了错误，也有可能是Web应用存在bug或临时故障

503 Service Unavailable

表示服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求
一般会被写入 Retry-After 字段来指明解除以上状况需要的时间

5 与HTTP协作的Web服务器

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

HTTP/1.1 规范允许一台HTTP服务器搭建多个Web站点，即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已经具有多台服务器

互联网上，域名通过DNS服务映射到IP地址（域名解析）之后访问目标网站。可见，当请求发送到服务器时，已经是以IP地址形式访问

所以，如果一台服务器内托管了两个域名，收到请求时就需要弄清究竟要访问那个域名

在相同的IP地址下，由于虚拟主机可以寄存多个不同主机名和域名的Web网站，因此在发送HTTP请求时，必须在HOST首部内完整的指定主机名或域名的URI

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

HTTP通信时除了客户端和服务端，还有用于数据转发的应用程序，例如代理、网关和隧道。
这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接受从那台服务器发送的响应再转发给客户端

代理：中间商
网关：服务器2号
隧道：保持连接

5.2.1 代理

接受客户端发送的请求后转发给其他的服务器，不改变请求的URI，直接发送给前方拥有字段的目标服务器
每次通过代理服务器转发请求或响应时，会追加写入 Via 首部信息
通过设置组织内部的代理服务器可以做到对特定URI访问的控制

使用理由：

利用缓存技术减少网络带宽的流量
组织内部针对特定网站的访问控制
……

两种代理基准分类：

缓存代理
预先将资源的副本保存在代理服务器上，当代理在此收到对相同资源的请求时，就可以不从源u武器获取资源，而是将之前的缓存资源作为响应返回
透明代理
转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理
反之，对报文的内容进行加工的代理被称为非透明代理

5.2.2 网关

与代理机制相似，且能使通信线路上的服务器提供非HTTP协议服务。
利用网关能提高通信的安全性，因为可在客户端与网关之间的通信线路上加密以保证连接的安全。
例如：网关可以连接数据库，使用SQL查询语句；购物网站信用卡结算等

5.2.3 隧道

隧道可以按要求建立起一条与其他服务器的通信线路，届时使用SSL等加密手段进行通信。
隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会解析HTTP请求，保持原样中转给之后的服务器，会在双方断开链接时结束
隧道本身是透明的，客户端不用在意隧道的存在。通过隧道，可以和远距离服务器安全通信

5.3 保存资源的缓存

缓存是指代理服务器或客户端本地保存的资源副本，利用缓存可以减少对源服务器的访问，因此也就节省了通信流量和通信时间
缓存服务器的优势在于利用缓存可以避免多次从源服务器转发资源，不用多次处理相同的请求

5.3.1 缓存的有效期限（服务器缓存）

缓存有效性问题：缓存服务器会向源服务器确认资源的有效性，若判定缓存失败，缓存服务器将会再次从源服务器上获取新资源

5.3.2 客户端缓存

缓存不仅可以存在缓存服务器，还可以存在客户端浏览器中，客户缓存被称为临时网络文件（Temporary Internet File）
缓存有效就不必向服务器请求相同的资源
缓存过期会向源服务器确认资源的有效性，若判断浏览器缓存失败，浏览器会再次请求新资源

HTTP出现之前，有很多其他协议

FTP（File Transfer Protocol）文件传输协议
NNTP（Network News Transfer Protocol）电子会议室内传输消息的协议
Archie（搜索anonymous FTP公开的文件信息的协议）

6 HTTP首部

HTTP协议的请求和响应报文中比必定包含HTTP首部。本章介绍首部结构以及各字段用法

6.1 HTTP报文首部

HTTP报文结构：

报文首部：在客户端和服务器处理时起至关重要作用的信息
空行（CR+LF）
报文主体：所需要的用户和资源的信息

请求报文

报文首部
- 请求行：包含用于请求的方法、URI、HTTP版本
- 请求首部字段
- 通用首部字段
- 实体首部字段
- 其他

响应报文

报文首部
- 状态行：包含表示请求和相应的各种条件和属性的各类首部
- 响应首部字段
- 通用首部字段
- 实体首部字段
- 其他

6.2 HTTP首部字段

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

HTTP首部字段是构成HTTP报文的要素之一，使用首部字段事为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

6.2.2 HTTP首部字段结构

HTTP首部字段由首部字段名和字段值构成，中间用冒号：分割

Content-Type : txt/html

单个HTTP字段首部也可以有多个值

Keep-Alive : timeout=15, max=100

若首部字段重复了，看浏览器的内部处理逻辑，有些会优先第一次出现的，有些会优先最后出现的

6.2.3 4种HTTP首部字段类型

通用首部字段：请求和响应报文双方都会使用的首部
请求首部字段：补充了请求的附加内容、客户端信息、相应内容相关优先级等信息
相应首部字段：补充了相应的附加内容、也会要求客户端附加额外的内容信息
实体首部字段：针对请求报文和响应报文的实体部分用的首部。补充了字段内容更新时间等与实体有关的信息

6.2.4 HTTP/1.1 首部字段一览

通用首部字段：

首部字段名	说明
Cache-Control	控制缓存的行为
Connection	逐跳首部、连接的管理
Date	创建报文的日期时间
Pragma	报文指令
Trailer	报文末段的首部一览
Transfer-Encoding	指定报文主体的传输编码方式
Upgrade	升级为其他协议
Via	代理服务器的相关信息
Warning	错误通知

请求首部字段

首部字段名	说明
Accept	用户代理可以处理的媒体类型
Accept-Charset	优先的字符集
Accept-Encoding	优先的内容编码
Accept-Language	优先的语言
Authorization	Web认证信息
Expect	期待服务器的特定行为
From	用户的电子邮箱地址
Host	请求字段所在的服务器
If-Match	比较实体标记（ETag）
If-None-Match	比较实体标记（与If-Match相反）
If-Modified-Since	比较资源的更新时间
If-Unmodified-Since	比较资源的更新时间（与If-Modified-Since）
If-Range	资源未更新时发送实体Byte的范围请求
Max-Forwards	最大传输逐跳数
Proxy-Authorization	代理服务器要求客户端的认证信息
Range	实体的字节范围请求
Referer	对请求中URI的原始获取方
TE	传输编码的优先级
User-Agent	HTTP客户端程序的信息

响应首部字段

首部字段名	说明
Accept-Ranges	是否接受字节范围请求
Age	推算资源创建经过时间
Etag	资源的匹配信息
Location	令客户端重定向至指定URI
Proxy-Authenticate	代理服务器对客户端的认证信息
Retry-After	对再次发起请求的时机要求
Server	HTTP服务器的安装信息
Vary	代理服务器缓存的管理信息
WWW-Authenticate	服务器对客户端的认证信息

实体首部字段

首部字段名	说明
Allow	资源可支持的HTTP方法
Content-Encoding	实体主体适用的编码方式
Content-Language	实体主体的语言
Content-Length	实体主体的大小（Byte）
Content-Location	代替对应资源的URI
Content-MD5	实体主体的报文摘要
Content-Range	实体主体的位置范围
Content-Type	实体主体的媒体类型
Expires	实体主体过期的日期时间
Last-Modified	资源的最后修改日期时间

6.2.5 非HTTP/1.1首部字段

在HTTP协议通信中使用到的首部字段不限于RFC2616中定义的47种，还有Cooke、Set-Cookie和Content-Disposition等在其他的RFC中定义的首部字段，使用率也很高

6.2.6 End to end 首部和 Hop-by-hop 首部

HTTP首部字段将定义成缓存代理和非缓存代理的行为，分成两种类型

端到端首部（End to end header）
分在此类别中的首部会转发给请求/响应对应的最终接受目标，且必须保存在缓存生成的响应中，另外规定他必须被转发。
逐跳首部（Hop-by-hop header）
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
  分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再转发。HTTP/1.1和之后的版本中，如果要用到hop-by-hoy首部，需要提供Connect首部字段。
  除了这八个字段，其他都属于端到端首部。

6.3 6.4 6.5 6.6 关于四种首部字段的具体不做赘述

6.7 为Cookie服务的首部字段

管理服务器和客户端之间状态的Cookie虽然没有编入标准化HTTP/1.1 d的 RFC2616中，但在Web网站得到了广泛的应用。Cookie的工作机制是用户识别及状态管理。

Web网站为了管理用户的状态会把一些数据临时写入用户的计算机内，接着当用户访问该Web网站时，可以通过通信方式取回之前发放的Cookie。

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

为Cookie服务的首部字段

首部字段名	说明	首部类型
Set-Cookie	开始状态管理所使用的Cookie信息	响应首部字段
Cookie	服务器接收到的Cookie信息	请求首部字段

Set-Cookie字段的属性

首部字段名	说明	首部类型
Set-Cookie	开始状态管理所使用的Cookie信息	响应首部字段
Cookie	服务器接收到的Cookie信息	请求首部字段

属性	说明
NAME=VALUE	赋予COokie的名称和其值（必需）
expires=DATE	Cookie的有效期（不明确则为浏览器关闭前）
path=PATH	将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domain=域名	作为Cookie适用对象的域名（若不指定则默认为创建Cookie的服务器的域名）
Secure	仅在HTTPS安全通信时才会发送Cookie
HttpOnly	加以限制，使Cookie不能被JavaScript脚本所访问

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

7 确保 Web 安全的 HTTPS

在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。

使用 HTTPS 通信机制可以有效地防止这些问题。

7.1 HTTP 的缺点

HTTP主要有这些不足，列举如下：

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

这些问题不仅仅是在HTTP上出现，其他未加密的协议也会存在这类问题。
还有某些特定Web服务器和特定的Web浏览器在实际应用中存在的不足，或是语言漏洞

7.1.1 通信使用明文可能会被窃听

由于HTTP本身不具备加密的功能，所以也无法做到对通信整体进行加密。即 HTTP 报文使用明文（指未经加密过的报文）方式发送

TCP/IP是可能被窃听的网络

按 TCP/IP 协议族的工作机制，通信内容在所有的通信线路上都可能遭到窥视
即使报文加密后，加密之后的报文信息本身还是会被看到的
窃听只要收集在互联网上流动的数据包（帧），使用抓包工具or嗅探器工具

通信加密
通过SSL（Secure Socket Layer，安全套接字层）或
TLS（Transport Layer Security，安全层传输协议）的组合使用，加密HTTP的通信内容。

用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。（面经）

内容加密
对HTTP协议传输的内容本身进行加密（报文主体），通信的本身不加密。

诚然，为了做到有效的内容加密，前提是要求客户端和服务器同时具备加密和解密机制

由于该方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险

7.1.2 不验证通信方的身份就可能遭遇伪装

HTTP协议中的请求和响应不会对通信方进行确认。也就是说存在服务器是否为发送请求中URI真正指定的主机，返回的响应又是否真的返回到提出请求的客户端等类似问题。

任何人都可以发起请求
服务器只要接受到请求，不管对方是谁都会返回一个响应，隐患如下：

无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已经伪装的Web服务器（假server）
无法确定响应返回到的客户端是否是按真实意图接受相应的那个客户端。有可能是已伪装的客户端（假client）
无法确定正在通信的双方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限（权利问题）
无法判定请求是来自何方、出自谁手（假身份问题）
即使是无意义的请求也会照单全收，无法阻止海量请求下的Dos攻击（Denial of Service，拒绝服务攻击）

查明对手的证书
虽然使用HTTP协议无法确认通信方，但如果使用SSL则可以。SSL不仅提供了加密处理，还使用了一种被称为证书的手段，可用于确定方。

证书由值得信任的第三方机构办法，用以证明服务器和客户端是实际存在的。伪造证书非常困难，因此只要能够确定通信方持有的证书，就可以判断通信房的真实意图。

客户端持有证书及可以完成个人身份的确认，也可以用于对Web网站的认证环节。

7.1.3 无法证明报文的完整性，可能已遭篡改

接收到的内容可能有误
由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收到之前的这但时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
攻击人会随意篡改请求和响应，而让客户端与服务器之间的通信看上去仍旧是正常的。

如何防止篡改
其中常用的是 MD5 和 SHA-1 等散列值校验的方法，以及用来确认文件的数字签名方法。提供文件下载的Web网站也会提供相应的 PGP 创建的数字签名及MD5算法生成的散列值。

PGP是用来证明创建文件的数字签名，MD5是由单向函数生成的散列值

可是如果PGP和MD5本身被改写，用户没有办法意识到，为了防止这些弊端，有必要用HTTPS

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

7.2.1 HTTP 加上加密处理和认证以及完整性保护后即是HTTPS

如果在HTTP协议通信过程中使用未经加密的明文，比如信用卡卡号，如果这条线路遭到窃听，那么信用卡号就暴露了，因此需要在HTTP上再加入加密处理和认证等机制。我们把添加了加密及认证机制的HTTP称为HTTPS（HTTP Secure）

竟在会在Web登陆页面和购物结算界面等使用HTTPS通信（https://）

公钥私钥签名之间的区别
公钥是公开的，私钥是私有的，所以Alice给Bob发消息，就要使用Bob公开的公钥来做加密，Bob再用自己的私钥进行解密即可。简单来说，公钥加密，私钥解密。
数字签名刚好相反，比如大家想对Alice的签名进行验证，那么大家能获取的就是Alice公开的公钥，而签名则由Alice用自己的私钥进行签名。简单来说，私钥签名，公钥验证
（面经）

7.2.2 HTTPS 是身披SSL外壳的HTTP

HTTPS只是HTTP通信接口部分用SSL和TLS协议代替而已。
通常HTTP直接和TCP通信，当使用SSL时，则演变成HTTP先和SSL通信，再又SSL和TCP通信了。简而言之，所谓HTTPS，就是身体SSL协议外壳的HTTP。

采用SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护。SSL是独立于HTTP的协议，所以不光HTTP协议，其他运行在应用层的SMTP和Telnet等剧可以配合SSL协议使用。

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

SSL采用公开密钥加密的处理方式，近代的加密方法中加密算法是公开的，而密钥是保密的。
加密和解密都会用到密钥，没有密钥就没法对密码解密，反过来，只要持有密钥就可以解密。

共享密钥加密的困境
加密和解密用同一个密钥的方式称为共享密钥加密，也被叫做对称密钥加密，以此方式加密时也必须将密钥发送给对方，如果通信被监听那么密钥就可能会落入攻击者之手。

使用两把密钥的公开密钥加密
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，另一把叫做公开密钥。
发送密文的一方使用对方的公开密钥进行加密，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥。

HTTPS采用混合加密机制
HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。如果密钥可以实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密比共享密钥加密慢。

在交换密钥缓解使用公开密钥加密方式，之后的建立通信报文交换阶段利用共享密钥加密方式。

7.2.4 证明公开密钥正确性的证书

公开密钥加密方法还是存在一些问题的，也就是无法证明公开密钥本身就是货真价实的公开密钥。

为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。数字证书认证机构处于客户端和服务器双方都可以信赖的第三方机构的立场上。

业务流程：

服务器把自己的公开密钥登陆到数字证书认证机构
数字证书认证机构用自己的私有密钥向服务器的公钥署数字签名并颁发公钥证书
客户端拿到服务器的公钥证书后用数字证书认证机构的公钥来确认服务器公钥的真实性
客户端使用服务器的公钥对报文进行加密发送
服务器用服务器的私钥进行解密

用以确认客户端的客户端证书
客户端证书用于客户端认证，用来证明服务器正在通信的对方始终是预料之内的客户端。

想要获取证书，用户需要自行安装客户端证书，但要付费
让层次不同的用户自行安装证书，非常困难
现状：安全性极高的认证机构可以颁发客户端证书但仅仅用于特殊业务
例如：网银用客户端证书，登陆时不仅仅需要用户输入ID和密码，还要求用户的客户端证书，以确定用户是否从特定的终端访问网银（U盾）
问题：客户端证书只能证明客户端实际存在，但只要有了安装了客户端证书的计算机的使用权限，就等于拥有了客户端证书的使用权限

7.2.5 HTTPS 的安全通信机制

流程：解释

服务器和客户端协商决定加密组件
服务器向客户端发送公开密钥证书
客户端确定证书的有效性并取出公钥
客户端生成一个随机数并用公钥加密后发送给服务器，同时通过加密组件生成master-secret
服务器私钥解密后也通过加密组件生成master-secret
开始加密通信
- 共享密钥加密的密钥
- 报文校验码的密钥
- 生成CBC的初始向量：服务器->客户端、客户端->服务器六份信息

SSL 和 TLS
HTTPS使用SSL和TLS两个协议，SSL1.0在设计之初被发现出问题，就没有实际投入使用。SSL2.0也被发现存在问题，所以很多浏览器直接废除了协议版本。

SSL速度
因为需要服务器、客户端双方加密以及解密处理，因此会消耗CPU和内存等硬件资源。SSL通信部分因为要对通信进行处理，所以时间上又延长了。
使用HTTP相比，网络负载会慢2到100倍。针对速度变慢，会使用SSL加速器这种硬件来改善问题，仅仅在SSL处理时发挥SSL加速器的功效，以分担负载。
如果每次通信都加密，会消耗相当多的资源，平摊到每一台计算机上时，能够处理的请求数量也必定随之减少。特别是每当那些访问量较多的Web网站在进行加密处理时，他们所承担的负载不容小觑。

HTTP