《图解HTTP》
一、了解web及网络基础
1.1 使用HTTP协议访问Web
Web 使用一种名为 HTTP（HyperText Transfer Protocol， 超文本传输协议1） 的协议作为规范， 完成从客户端到服务器端等一系列运作流程。
1.2 HTTP诞生
1989 年 3 月 CERN（欧洲核子研究组织） 的蒂姆 • 伯纳斯 - 李（Tim BernersLee）博士提出了一种能让远隔两地的研究者们共享知识的设想，蒂姆 • 伯纳斯 - 李也成为万维网之父。
1.3 网络技术TCP/IP
TCP/IP协议族
分层管理：
TCP/IP 协议族里重要的一点就是分层。 TCP/IP 协议族按层次分别分为以下 4 层： 应用层、 传输层、 网络层和数据链路层。
1.4 与HTTP关系密切的协议：IP、TCP、DNS
（1）IP 协议：
的作用是把各种数据包传送给对方。 而要保证确实传送到对方那里， 则需要满足各类条件。 其中两个重要的条件是 IP 地址和 MAC地址（Media Access Control Address） 。
（2）TCP：
按层次分， TCP 位于传输层， 提供可靠的字节流服务 。为了准确无误地将数据送达目标处， TCP 协议采用了三次握手（three-way handshaking） 策略。
三次握手：
（3）DNS 服务 ：
DNS（Domain Name System） 服务是和 HTTP 协议一样位于应用层的协议。 它提供域名到 IP 地址之间的解析服务。
1.6 各种协议与HTTP协议之间的关系
1.7 URI和URL
URI（Uniform Resource Identifier ，统一资源标识符）、URL（Uniform Resource Locattor，统一资源定位符）
URI 用字符串标识某一互联网资源， 而 URL 表示资源的地点（互联网上所处的位置） 。 可见 URL 是 URI 的子集。
二、简单的HTTP协议
2.1 HTTP用于客户端和服务器之间的通信
在两台计算机之间使用 HTTP 协议通信时， 在一条通信线路上必定有一端是客户端， 另一端则是服务器端。
2.3 HTTP是不保存状态的协议
HTTP/1.1 虽然是无状态协议， 但为了实现期望的保持状态功能， 于是引入了 Cookie 技术。 有了 Cookie 再用 HTTP 协议通信， 就可以管理状态了。
2.4 请求URI定位资源
HTTP 协议使用 URI 定位互联网上的资源。 正是因为 URI 的特定功能， 在互联网上任意位置的资源都能访问到。
2.5 告知服务器意图的HTTP方法
（1）GET：获取资源
（2）POST：传输实体主体
（3）PUT：传输文件
（4）HEAD：获得报文首部
（5）DELETE：删除文件
（6）OPTIONS：询问支持的方法
（7）TRACE：追踪路径
（8）CONNECT：要求用隧道协议连接代理
表 2-1： HTTP/1.0 和 HTTP/1.1 支持的方法 
LINK 和 UNLINK 已被 HTTP/1.1 废弃， 不再支持。
2.7持久连接节省通信量
2.8 使用cookie的状态管理
HTTP 是无状态协议， 它不对之前发生过的请求和响应的状态进行管理。 也就是说， 无法根据之前的状态进行本次的请求处理。
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。 
三、HTTP报文内的HTTP信息
3.1 HTTP报文
用于HTTP交互的信息被称为HTTP报文。请求端（客户端） 的HTTP 报文叫做请求报文， 响应端（服务器端） 的叫做响应报文。
3.2 请求报文及响应报文的结构
图： 请求报文（上） 和响应报文（下） 的实例
四、返回结果的HTTP状态码
4.1 状态码告知从服务器端返回的请求结果
4.2 2XX 成功
（1）200：OK
（2）202：No Content
（3）206：Partial Content
4.3 3XX重定向
3XX表明浏览器需要执行某些特殊的处理以正确处理请求。
（1）301：Moved Permanently
永久性重定向。 该状态码表示请求的资源已被分配了新的 URI， 以后应使用资源现在所指的 URI。
（2）302：Found
临时性重定向。 该状态码表示请求的资源已被分配了新的 URI， 希望用户（本次） 能使用新的 URI 访问。
（3）303：See Other
（4）304：Not Modified
该状态码表示客户端发送附带条件的请求 2 时， 服务器端允许请求访问资源， 但未满足条件的情况。 304 状态码返回时， 不包含任何响应的主体部分。 304 虽然被划分在 3XX 类别中， 但是和重定向没有关系。
（5）307：Temporary Redirect
临时重定向。 该状态码与 302 Found 有着相同的含义。
4.4 4XX 客户端错误
（1）400 Bad Request：请求报文中存在语法错误；
（2）401 Unauthorized：该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证） 的认证信息。
（3）403 Forbidden：请求的资源被服务器拒绝；
（4）404 Not Found：服务器上无法找到资源；
4.5 5XX服务器错误
5XX的响应结果表明服务器本身发生错误
（1）500 Internal Server Error：服务器端在执行请求时发生了错误。
（2）503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护， 现在无法处理请求。
五、与HTTP协作的Web服务器
5.1 用单台虚拟主机实现多个域名
5.2 通信数据转发程序 ： 代理、 网关、通道
（1）代理：代理是一种有转发功能的应用程序， 它扮演了位于服务器和客户端“中间人”的角色， 接收由客户端发送的请求并转发给服务器， 同时也接收服务器返回的响应并转发给客户端。
（2）网关：网关是转发其他服务器通信数据的服务器， 接收从客户端发送来的请求时， 它就像自己拥有资源的源服务器一样对请求进行处理。 有时客户端可能都不会察觉， 自己的通信目标是一个网关。
（3）隧道：隧道是在相隔甚远的客户端和服务器两者之间进行中转， 并保持双方通信连接的应用程序。
六、HTTP首部
（1）HTTP 请求报文
下面的示例是访问 http://hackr.jp 时， 请求报文的首部信息。
在响应中， HTTP 报文由 HTTP 版本、 状态码（数字和原因短语） 、HTTP 首部字段 3 部分构成。
6.3 HTTP/1.1 通用首部字段
通用首部字段是指， 请求报文和响应报文双方都会使用的首部。（1）Cache-Control：通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。
| Cache-Control: private, max-age=0, no-cache |
（2）Connection：
- 控制不再转发给代理的首部字段
| Connection: 不再转发的首部字段名 |
- 管理持久连接
| Connection: close |
HTTP/1.1 版本的默认连接都是持久连接。 为此， 客户端会在持久连接上连续发送请求。 当服务器端想明确断开连接时， 则指定Connection 首部字段的值为 Close。
（3）Date：表明创建 HTTP 报文的日期和时间。
（4）Pragma ：Pragma 是 HTTP/1.1 之前版本的历史遗留字段， 仅作为与 HTTP/1.0的向后兼容而定义 。
（5）Trailer：首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。
（6）Transfer-Encoding ：首部字段 Transfer-Encoding 规定了传输报文主体时采用的编码方式。
（7）Upgrade ：用于检测HTTP协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。
（8） Via：使用首部字段 Via 是为了追踪客户端与服务器之间的请求和响应报文的传输路径。
七、确保web安全的HTTPS
7.1 HTTP的缺点
- 通信使用明文（不加密），内容可能会被窃取；
- 不验证通信方的身份，因此有可能遭遇伪装；
- 无法证明报文的完整性，所以有可能以遭篡改。
通信加密：
一种方式就是将通信加密。 HTTP 协议中没有加密机制， 但可以通过和 SSL（Secure Socket Layer， 安全套接层） 或TLS（Transport Layer Security， 安全层传输协议） 的组合使用，加密 HTTP 的通信内容。
用 SSL建立安全通信线路之后， 就可以在这条线路上进行 HTTP通信了。 与 SSL组合使用的 HTTP 被称为 HTTPS（HTTPSecure， 超文本传输安全协议） 或 HTTP over SSL。
内容的加密
还有一种将参与通信的内容本身加密的方式。 由于 HTTP 协议中没有加密机制， 那么就对 HTTP 协议传输的内容本身加密。 即把HTTP 报文里所含的内容进行加密处理。
7.2 HTTP+ 加密 + 认证 + 完整性保护=HTTPS
HTTPS 并非是应用层的一种新协议。 只是 HTTP 通信接口部分用 SSL （ Secure Socket Layer ） 和 TLS （ Transport Layer Security ） 协议代替而已。
- 使用两把密钥的公开密钥加密
公开密钥加密使用一对非对称的密钥。 一把叫做私有密钥（private key） ， 另一把叫做公开密钥（public key） 。 顾名思义， 私有密钥不能让其他任何人知道， 而公开密钥则可以随意发布， 任何人都可以获得。使用公开密钥加密方式， 发送密文的一方使用对方的公开密钥进行加密处理， 对方收到被加密的信息后， 再使用自己的私有密钥进行解密。 利用这种方式， 不需要发送用来解密的私有密钥， 也不必担心密钥被攻击者窃听而盗走。
- HTTPS 采用混合加密机制
八、确定访问用户身份的认证
HTTP使用的认证方式：
- BASIC认证（基本认证）
- DIGEST（摘要认证）
- SSL客户端认证
- FormBase认证（基于表单的认证）
BASIC 认证虽然采用 Base64 编码方式， 但这不是加密处理。 不需要任何附加信息即可对其解码。 换言之， 由于明文解码后就是用户 ID和密码， 在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中， 如果被人窃听， 被盗的可能性极高。
另外， 除此之外想再进行一次 BASIC 认证时， 一般的浏览器却无法实现认证注销操作， 这也是问题之一。
BASIC 认证使用上不够便捷灵活， 且达不到多数 Web 网站期望的安全性等级， 因此它并不常用。 
DIGEST 认证提供了高于 BASIC 认证的安全等级， 但是和 HTTPS 的客户端认证相比仍旧很弱。 DIGEST 认证提供防止密码被窃听的保护机制， 但并不存在防止用户伪装的保护机制。
SSL客户端认证是借由 HTTPS 的客户端证书完成认证的方式。 凭借客户端证书（在 HTTPS 一章已讲解） 认证， 服务器可确认访问是否来自已登录的客户端。
- 认证多半为基于表单认证
- Session 管理及 Cookie 应用