Page 188 - Web性能权威指南

发现减少资源数量或者将它们合并为更少的请求，反而能带来更大的好处。

DNS 查询和 TCP 慢启动导致的额外消耗对高延迟客户端的影响最大。换
句话说，移动（3G、4G）客户端经常是受过度域名分区影响最大的！

11.5 度量和控制协议开销

HTTP 0.9 当初就是一个简单的只有一行的 ASCII 请求，用于取得一个超文本文
档，这样导致的开销是最小的。HTTP 1.0 增加了请求和响应首部，以便双方能够
交换有关请求和响应的元信息。最终，HTTP 1.1 把这种格式变成了标准：服务器
和客户端都可以轻松扩展首部，而且始终以纯文本形式发送，以保证与之前 HTTP
版本的兼容。

今天，每个浏览器发起的 HTTP 请求，都会携带额外 500~800 字节的 HTTP 元数
据：用户代理字符串、很少改变的接收和传输首部、缓存指令，等等。有时候，500~
800 字节都少说了，因为没有包含最大的一块：HTTP cookie。现代应用经常通过
cookie 进行会话管理、记录个性选项或者完成分析。综合到一起，所有这些未经压
缩的 HTTP 元数据经常会给每个 HTTP 请求增加几千字节的协议开销。

RFC 2616（HTTP 1.1）没有对 HTTP 首部的大小规定任何限制。然而，实际
中，很多服务器和代理都会将其限制在 8 KB 或 16 KB 之内。

HTTP 首部的增多对它本身不是坏事，因为大多数首部都有其特定用途。然而，由
于所有 HTTP 首部都以纯文本形式发送（不会经过任何压缩），这就会给每个请
求附加较高的额外负荷，而这在某些应用中可能造成严重的性能问题。举个例子，
API 驱动的 Web 应用越来越多，这些应用需要频繁地以序列化消息（如 JSON）的
形式通信。在这些应用中，额外的 HTTP 开销经常会超过实际传输的数据静荷一个
数量级：
$> curl --trace-ascii - -d'{"msg":"hello"}' http://www.igvita.com/api

== Info: Connected to www.igvita.com
=> Send header, 218 bytes ➊
POST /api HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 ...
Host: www.igvita.com
Accept: */*
Content-Length: 15 ➋

HTTP 1.x ｜ 173