Table of contents
基础概念
了解 Web
- WWW（World Wide Web，万维网）的 3 项构建技术：HTML、HTTP、URL WWW 这一名称，是 Web 浏览器当年用来浏览超文本的客户端应用程序的名称，现在则用来表示这一系列的集合，也可简称为 Web。
- HTML（HyperText Markup Language，超文本标记语言）
- HTTP（HyperText Transfer Protocol，超文本传输协议） 当年 HTTP 协议的出现主要是为了解决文本传输的难题。由于协议本身非常简单，于是在此基础上设想了很多应用方法并投入了实际使用。现在 HTTP 协议已经超出了 Web 这个框架的局限，被运用到了各种场景里。
- URL（Uniform Resource Locator，统一资源定位符）
- URI（Uniform Resource Identifier，统一资源标识符）
RFC2396 分别对这 3 个单词进行了如下定义：
- Uniform 规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案（如，http: 或 ftp: ）也更容易。
- Resource 资源的定义是『可标识的任何东西』。不仅是文档文件，图像或服务（例如当天的天气预报）等能够区别于其他类型的，全部可作为资源。另外，资源不仅可以是单一的，也可以是多数的集合体。
- Identifier 表示可标识的对象。也称为标识符。
综上所述，URI 就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源时所使用的协议类型名称。例如，采用 HTTP 协议时，协议方案就是 http；除此之外，还有 ftp、mailto、telnet、file 等。URI用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置）。可见，URL 是 URI 的子集。
RFC（Request for Comments，征求修正意见书）。由于不遵守 RFC 标准实现就无法进行 HTTP 协议通信，所以基本上客户端和服务器端都会以 RFC 为标准来实现 HTTP 协议。但也存在某些应用程序因客户端或服务器端的不同，而未遵照 RFC 标准，反而将自成一套的『标准』扩展的情况。
网络基础
通常使用的网络（包括互联网）是在 TCP/IP 协议族的基础上运作的，而 HTTP 属于它内部的一个子集。
TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分为一下 4 层：应用层、传输层、网络层和数据链路层。
利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则从链路层往上走。发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首消去。这种把数据信息包装起来的做法称为封装（encapsulate）。
与 HTTP 关系密切的协议：IP、TCP 和 DNS
待补充 P10-15
HTTP 协议
HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端没有接收到请求之前不会发送响应。
请求报文与响应报文
请求报文
GET /index.htm HTTP/1.1
Host: www.example.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16
name=qiaoin&age=24
- GET 表示请求访问服务器的类型，称为方法（method）
- /index.htm 指明了请求访问的资源对象，也叫请求 URI（request-URI）
- HTTP/1.1 HTTP 的版本号，用来提示客户端使用的 HTTP 协议功能
- Host、Connection、Content-Type、Content-Length 等 为可选的请求首部字段
- 空行 CR + LF
- 内容实体
响应报文
HTTP/1.1 200 OK
Date: Mon, 28 May 2018 13:56:49 GMT
Content-Length: 362
Content-Type: text/html
<html>
......
- HTTP/1.1 表示服务器对应的 HTTP 版本
- 200 OK 表示请求的处理结果的状态码（status code）和原因短语（reason-phrase）
- 显示创建响应的日期时间，是首部字段（header field）内的一个属性
- 可选的响应首部字段
- 空行 CR + LF
- 资源实体的主体（entity body）
HTTP 方法
- GET 获取资源：当前网络请求中，绝大部分使用的是 GET 方法。
- POST 传输实体主体：虽然用 GET 方法也可以传输实体主体，但一般不用 GET 方法进行传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相近，但 POST 的主要目的并不是获取响应的主体内容。
- PUT 传输文件：要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。但是，鉴于 HTTP、1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，因此一般的 Web 网站不使用该方法。若配合 Web 应用程序的验证机制，或架构设计采用 REST（Representational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。
- HEAD 获得报文首部：HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的时间等。
- DELETE 删除文件：DELETE 方法用来删除文件，是与 PUT 相反的方法。同样 DELETE 方法本身不带验证机制。
- OPTIONS 询问支持的方法：用来查询针对请求 URI 指定的资源支持的方法。
- TRACE 追踪路径：服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪），因此更不会去使用它。
- CONNECT 要求用隧道协议连接代理：要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
CONNECT 代理服务器名：端口号 HTTP 版本
GET 和 POST 的区别
HTTP 状态码
状态码的职责是当客户端向服务器发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器是正常处理了请求，还是出现了错误。状态码如 200 OK，以 3 位数字和原因短语组成。数字的第一位指定了响应的类别，后两位无分类。响应类别有以下 5 种。
| 类别 | 原因短语 | |
|---|---|---|
| 1XX | Informational（信息性状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |
- 1XX 信息
- 100 Continue 表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应
- 2XX 成功
2XX 的响应结果表明请求被正常处理了。
- 200 OK 表示客户端发来的请求在服务器端被正常处理了
- 204 No Content 表示服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而不需要返回数据时使用
- 206 Partial Content 表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文种给你包含由 Content-Range 指定范围的实体内容
- 3XX 重定向
3XX 响应结果表明浏览器需要执行某些特殊的处理以正确完成请求。
- 301 Moved Permanently 永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI
- 302 Found 临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问
- 303 See Other 和 302 Found 状态码有着相同的功能，但 303 状态码明确表示客户端应当采用 GET 方法获取资源，这点与 302 状态码有区别 ::: warning 注意 虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。 :::
- 304 Not Modified 如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码
- 307 Temporary Redirect 临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法
- 4XX 客户端错误
4XX 的响应结果表明客户端是发生错误的原因所在。
- 400 Bad Request 请求的报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待此状态码
- 401 Unauthorized 需要进行 HTTP 认证（BASIC 认证、DIGEST 认证）
- 403 Forbidden 请求被拒绝。服务器没有必要给出详细的拒绝理由
- 404 Not Found 服务器上没有所请求的资源
- 5XX 服务器错误
5XX 的响应结果表明服务器本身发生错误。
- 500 Internal Server Error 服务器在执行请求时发生了错误，也可能是 Web 应用存在的 bug 或某些临时的故障
- 503 Server Unavailable 服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求
HTTP 首部
HTTP 协议的请求和响应报文中必定包含 HTTP 首部，首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。有 4 种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。各首部字段及其含义如下。
通用首部字段
| 首部字段名 | 说明 |
|---|---|
| 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-Modified-Since | 比较资源的更新时间 |
| If-None-Match | 比较实体标记（与 If-Match 相反） |
| If-Range | 资源未更新时发送实体 Byte 的范围请求 |
| If-Unmodified-Since | 比较资源的更新时间（与 If-Modified-Since 相反） |
| 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 | 实体主体的大小（单位：字节） |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定义的 47 中首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定义的首部字段，它们的使用频率也很高。
具体应用
Cookie & Session P25 P34 P37 P132 P177
用单台主机实现多个域名 P66
通信数据转发程序：代理、网关、隧道 P67
保存资源的缓存 P71
HTTPS
HTTP 有以下安全性问题：
- 使用明文进行通信（不加密），内容可能会被窃听；
- 不验证通信方的身份，有可能遭遇伪装；
- 无法证明报文的完整性，有可能已遭篡改。
这些问题不仅在 HTTP 上出现，其他未加密的协议中也会存在这类问题。
1、SSL 是怎么建立安全通信线路的？ 2、SSL 如何使用证书确认通信方？
HTTP + 加密 + 认证 + 完整性保护 = HTTPS
为了统一解决上述这些问题，需要在 HTTP 上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure）
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 HTTPS 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。
SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应 用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是 当今世界上应用最为广泛的网络安全技术。
加密
- 对称密钥加密 —— 也称为共享密钥加密（Common-Key Encryption），加密的加密和解密使用同一密钥
- 优点：运算速度快
- 缺点：密钥容易被获取
- 非对称密钥加密 —— 也称为公开密钥加密（Public-Key Encryption），使用一对密钥用于加密和解密，分别为公开密钥和私有密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密
- 优点：更为安全
- 缺点：运算速度慢
- HTTPS 采用混合加密方式 HTTPs 采用混合的加密机制，使用公开密钥加密用于传输对称密钥来保证安全性，之后使用对称密钥加密进行通信来保证效率。（下图中的 Session Key 就是对称密钥）
证书
通过使用证书来对通信方进行验证。数字证书认证机构处在客户端与服务器双方都可信赖的第三方机构的立场上。见 P150 配图。
- 服务器把自己的公开密钥登录至数字证书认证机构（服务器的公开密钥）；
- 数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并颁发公钥证书（数字证书认证机构的私有密钥）；
- 数字证书认证机构的公开密钥已事先植入到浏览器里了（多数浏览器在发布新版本时，会事先在内部植入常用认证机关的公开密钥）（数字证书认证机构的公开密钥）；
- 客户端拿到服务器的公钥证书之后，使用数字证书认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性（数字证书认证机构的公开密钥 + 服务器的公开密钥）；
- 使用服务器的公开密钥对报文进行加密后发送（服务器的公开密钥）
- 服务器用私有密钥对报文进行解密（服务器的私有密钥）
完整性保护
SSL 提供报文摘要功能来进行完整性保护。
HTTP 也提供了 MD5 报文摘要功能，但是却不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生篡改。
HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。
HTTPS 的缺点
- 与纯文本通信相比，加密通信会消耗更多的 CPU 及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要进行信息隐藏时，才会加密，以节约资源
- 需要支付证书授权的高费用
Web 的攻击技术
TODO 之后对某一项技术具体感兴趣时再来补充 <2018-05-29 Tue>
跨站脚本攻击
SQL 注入攻击
跨站点请求伪造
拒绝服务攻击
版权声明
本作品采用知识共享署名 4.0 国际许可协议进行许可，转载时请注明原文链接。