由于每个主机只能同时发起6个连接而导致的资源错列
当然，天下没有免费的午餐，域名分区也不例外：每个新主机名都要求有一次额外的DNS查询，每多一个套接字都会多消耗两端的一些资源，而更糟糕的是，站点作者必须手工分离这些资源，并分别把它们托管到多个主机上。
实践中，域名分区经常会被滥用，导致几十个TCP流都得不到充分利用，其中很多永远也避免不了TCP慢启动，最坏的情况下还会降低性能。此外，如果使用的是HTTPS，那么由于TLS握手导致的额外网络往返，会使得上述代价更高。此时，请大家注意如下几条：
首先，把TCP利用好；
浏览器会自动为你打开6个连接；
资源的数量、大小和响应时间都会影响最优的分区数目；”
客户端延迟和带宽会影响最优的分区数目；
域名分区会因为额外的DNS查询和TCP慢启动而影响性能。
域名分区是一种合理但又不完美的优化手段。请大家一定先从最小分区数目（不分区）开始，然后逐个增加分区并度量分区后对应用的影响。现实当中，真正因同时打开十几个连接而提升性能的站点并不多，如果你最终使用了很多分区，那么你会发现减少资源数量或者将它们合并为更少的请求，反而能带来更大的好处。
DNS查询和TCP慢启动导致的额外消耗对高延迟客户端的影响最大。换句话说，移动（3G、4G）客户端经常是受过度域名分区影响最大的！
度量和控制协议开销HTTP 0.9当初就是一个简单的只有一行的ASCII请求，用于取得一个超文本文档，这样导致的开销是最小的。HTTP 1.0增加了请求和响应首部，以便双方能够交换有关请求和响应的元信息。最终，HTTP 1.1把这种格式变成了标准：服务器和客户端都可以轻松扩展首部，而且始终以纯文本形式发送，以保证与之前HTTP版本的兼容。
今天，每个浏览器发起的HTTP请求，都会携带额外500～800字节的HTTP元数据：用户代理字符串、很少改变的接收和传输首部、缓存指令，等等。有时候，500～800字节都少说了，因为没有包含最大的一块：HTTP cookie。现代应用经常通过cookie进行会话管理、记录个性选项或者完成分析。综合到一起，所有这些未经压缩的HTTP元数据经常会给每个HTTP请求增加几千字节的协议开销。
HTTP首部的增多对它本身不是坏事，因为大多数首部都有其特定用途。然而，由于所有HTTP首部都以纯文本形式发送（不会经过任何压缩），这就会给每个请求附加较高的额外负荷，而这在某些应用中可能造成严重的性能问题。举个例子，API驱动的Web应用越来越多，这些应用需要频繁地以序列化消息（如JSON）的形式通信。在这些应用中，额外的HTTP开销经常会超过实际传输的数据净荷一个数量级：
“$> curl --trace-ascii - -
d'{"msg":"hello"}'
http://”