本章了解知识点
- HTTP是如何使用TCP连接的
- TCP连接的时延、瓶颈以及存在的障碍
- HTTP的优化，包括行连接、Keep-alive、管道化连接
- 管理连接时应该以及不应该做的事情。
4.1 TCP连接
世界上几乎所有的HTTP通信都是由TCP/IP承载的，TCP/IP是全球计算机及网络设备都在使用的一种常用的分组交换网络分层协议集。
关于TCP/IP的介绍大家可以去其它博客学习，或者去看《TCP/IP详卷》这本书。
4.2HTTP连接的处理
我们从HTTP的Connection首部开始介绍，这是HTTP连接管理中一个很容易被误解，但又很重要的部分。然后会介绍一些HTTP连接优化技术。
4.3.1常备误解的Connection首部
HTTP允许在客户端和最终的源端服务器之间存在一连串HTTP中间实体（代理、告诉缓存等）。可以从客户端开始，琢跳的将HTTP报文经过这些中间设备，转发到源端服务器上去。
Connection首部字段具备如下两个作用：
1，控制不再转发给代理的首部字段
2，管理持久连接
在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不再转发给代理的首部字段（即Hop-by-hop首部）。
2，管理持久连接
HTTP/1.1版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。
HTTP/1.1之前的HTTP版本的默认连接都是非常持久连接。为此，如果想在旧版本的HTTP协议上维持持续连接，则需要指定Connection首部字段的值为Keep-Alive。如上图1所示，客户端发送请求给服务器时，服务器端会象上图2那样加上首部字段Keep-Alive及首部字段Connection后返回响应。
4.3.2串行事务处理时延
如果只对连接进行简单的管理，TCP的性能时延可能会叠加起来。比如，加入有一个包含了3个嵌入图片的Web页面。浏览器需要发起4个HTTP事务来显示此页面：一个用于顶层的HTML页面，3个用于嵌入的图片。如果每个事务都需要（串行的建立）一跳新的连接，那么连接的时延和慢启动时延就会叠加起来
串行加载的另一个缺点是，有些浏览器在对象加载完毕之前无法获知对象的尺寸，二期她们可能需要尺寸信息来决定将对象放在屏幕的什么位置上，所以在加载了足够多对象之前，无法再屏幕上显示任何内容。在这种情况下，可能浏览器串行装在对象的进度很正常，但用户面对的却是一个空白的屏幕，对装载进度一无所知。
还有几种现存和新兴的方法可以提高HTTP的连接性能。
4.4并行连接
HTTP允许客户端打开多条连接，并行的执行多个HTTP事务
4.4.1并行连接可能会提到页面的加载速度
包含嵌入对象的组合页面如果能（通过并行连接）克服单条连接的空载时间和带宽的限制，加载速度会有所提高。时延可以重叠起来。如果单条连接没有充分利用客户端英特网带宽，可以将未用带宽分配来装载其他对象。
4.4.2并行连接并不一定更快
1.客户端的带宽不足
2.复杂的web页面可能会有数十或数百个内嵌对象，客户端可能可以打开数百个连接，但web服务器通常要同时处理很多其他用户的请求，所以很少有web服务器希望出现这样的情况，这会造成服务器性能的严重下降。
实际上，浏览器确实使用了并行连接，但他们会将并行连接的数量限制一个较小的值
（通常4个）。服务器可以随意关闭来自特定客户端的超量连接。
4.5持久连接
允许HTTP设备在事务处理结束之后将TCP连接保持在打开状态，以便未来的HTTP请求重用现存的连接。在事务处理结束之后仍然保持在打开状态的TCP连接被称为持久连接。非持久连接会在每个事务结束之后关闭。持久连接会在不同事务之间保持打开状态，直到客户端或服务器决定将其关闭。
重用已对目标服务器打开的空闲持久连接，就可以表面缓慢的连接建立阶段。而且已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快速的进行数据传输。
4.5.1 HTTP/1.+keep-alive连接
keep-alive链接的一些性能有点，串行连接的4个HTTP事务请求和在一条持久连接上实现同样事务所需的时间进行了比较。省去了连接和关闭连接的开销
4.5.2 Keep-alive操作
keep-alive已经不再使用了，而且当前的HTTP/1.1规范中也没有对它的说明了。
但是浏览器和服务器对keep-alive握手使用的仍然相当广泛。
实现HTTP/1.0 keep-alive连接的客户端仍然可以通过Connection：keep-alive首部请求将一条连接保持打开状态。
如果服务器愿意在为下一条请求将连接状态保持在打开状态就在响应中包含相同的首部。如果响应中没有Connection：Keep-Alive首部出现，表示服务器不支持keep-alive，会在发回响应报文后关闭连接。
4.5.4 Keep-Alive选项
keep-alive首部是请求将连接保持在活跃状态。发出eep-alive请求之后，客户端和服务器端并不一定会同一进行keep-alive会话。他们可以在任意时刻关闭空闲的keep-alive链接。并可随意限制keep-alive链接所处理事务的数量。
可以用keep-alive通用首部中指定的、由逗号分隔的选项来调节keep-alive的行为
keep-avlive首部完全是可选的，但只有在提供Connection：keep-alive时才能使用它。
这里有个keep-alive响应首部的例子，还会为另外5个事务保持连接打开的状态，或者将打开状态保持到连接空闲了2分钟后
4.5.5 Keep-Alive连接的限制和规则
4.5.6 keep-alive和哑代理
1.Connection首部和盲中继
问题出在代理上——尤其是哪些不理解Connection首部，而且不知道在沿着转发链路将其发送之前，应该将该首部删除的代理。很多老的或简单的代理都是盲中继，它们不对Connection首部进行特殊的处理。
Connection首部是个诼跳首部，只适用于单条传输链路，不应该沿着链路向下传输。
2.代理和逐跳首部
现代的代理都绝对不能转发Connection首部和所有名字出现在Connection值中的首部。因此，如果一个代理收到了一个Connection：keep-alive首部，是不应该转发Connection首部，或所有名为keep-alive的首部的。
还有几个不能作为Connection首部值列出，也不能被代理转发或者作为缓存响应使用的首部。
4.5.7插入proxy-Connection
