4.1 TCP连接
下面是Httpwatch抓的访问网站的流程
完整图如下
协议栈
一个TCP连接需要4个值，不同的连接4个值中至少需要有一个不同。
TCP Sock编程
4.2 TCP性能分析
一些可能使HTTP事务延迟的因素：
1. DNS从URI得到IP地址和端口（DNScache可以减少此阶段的时间消耗）；
2. TCP连接建立时间；
3. Client发送HTTP
Request时间，Server接收Request及处理的时间；
4. Server返回HTTP
response的时间；
可以在HttpWatch抓到的图中的找到对应的部分：
与TCP相关的影响HTTP性能的因素：
1. TCP连接的握手延迟
对HTTP开发者来说，这部分是不可见的。
对于小的HTTP事务，connect的时间可能占50%或者更多。上图中connect的时间是最大的。
2. TCP确认的延迟
TCP的滑动窗口协议会导致确认延迟（通常是100-200ms），因为协议希望对收到的最大序号包进行确认，以提高效率。
3. TCP的slow-start控制
避免问题：为了防止Internet突然过载和拥塞，TCP连接允许的最大流量是逐步递增的。
例如：某个HTTP事务有大量数据要发送，不能一次发送所有包。必须是先发送1个包，等待确认；然后可以发送2个包，等待确认；之后可以发送4个包……。称为“打开拥挤窗口”。
4. Nagle算法和TCP_NODEAY
避免问题：TCP数据流接口允许写入任何长度的数据，甚至1字节，但TCP和IP头至少要40字节（不算可选字段），这样就降低了网络性能。Nagle算法尽量把数据捆绑成一个大包，以提升网络性能。
对延迟的影响：
1) 小的HTTP消息，不会填满一个包，就会产生等待；
2) Nagle算法会拦截发送数据，直到确认包回来，但是确认包本身有延迟；
5. TIME_WAIT延迟和端口消耗
TCP任意一端会维护一个小的控制块，用来记录近来刚刚关闭的IP和port。这些信息保存时间是2MSL=2minutes。以保证相同的new
TCP连接不会在此时间内创建。
避免问题：old TCP连接发的包还未到达另一端，new TCP连接又开始发送数据了，这样旧的数据就可能插入到了new
TCP连接的数据中，导致数据被破坏。
这就导致在2M时间内可以建立的连接数量是有限的。主要是在一些基准测试的情况下，资源有限，需要注意。例如只有有限的Client
IP地址连接到Server。
4.3 HTTP连接处理
Connection Header（下图蓝色方框内容）
它能携带3种不同类型的标签(token):
1) 只与此连接（当有多个中间实体时，两个实体之间的连接）相关的首部，图中：meter；
2) 描述此连接的非标准选项，图中：bill-my-credit-card；
3) 值Close，说明在使用完后关闭连接，图中：close；
由于他只述当前连接，所以在逐跳hop转发前必须删除。
串行事务处理时延(request和response组成一个事务)
例如：浏览一个含有3个嵌入式图片的网页需要4个HTTP事务（1个HTML，3个image）
缺点：
1) 每个事务都要进行连接，connection和slow-start时延会叠加；
2) 浏览器在加载完图像前无法获知对象尺寸，因此不能确定页面的布局，也就无法在屏幕上显示任何东西(可以通过在HTML中增加图片尺寸参数解决)；
提高HTTP连接性能的方法
4.4 Parallel Connections 并行
如上图所示，客户端可同时打开多条连接，并行执行多个HTTP事务。注意：建立每个连接的4个要素不能完全相同。
减少时延的效果如下图
并行连接的局限：
1) 每条连接都有connection和slow-start时延；
2) 当带宽有限时，资源竞争会比较严重，性能提升就很小；
3) 大量的连接会消耗内存资源。浏览器通常将并行连接总数限制在4个；
有时候并行连接是让人们心里感觉变快了。
4.5 Persistent Connections 持久
站点局部性（site locality）：初始化了（建立连接）对某服务器的HTTP请求的应用程序很可能会在不久的将来对那台服务器发起更多请求。
因此HTTP/1.1和HTTP1.0+(增强版)允许在事务结束之后TCP连接保持打开状态，称为持久连接。这样下次再进行事务处理时就没有了建立TCP连接相关的时延了。
持久连接降低了时延和连接建立的开销，减少了连接建立的数量，改善了并行连接的局限。但是引入了管理持久连接的工作，要避免出现大量空闲持久连接。
所以持久连接和并行连接配合使用应该是最高效的方式。
持久连接的两种类型：
1) HTTP/1.0+的keep-alive连接
Keep-alive实现操作
即使有keep-alive首部，Client和Server也可以不同意进行keep-alive会话，并且它们可以在任意时刻关闭空闲的keep-alive连接。
可以通过选项来调节keep-alive的行为：
l timeout：response首部中，估计Server希望连接保持活跃状态的时间；
l max：response首部中，估计Server希望多少个事务保持此连接的活跃状态；
l 用于诊断调试的属性，语法name=[value]；
上图例子说明Server会为另外5个事务保持连接打开状态，或者保持到连接空闲2分钟后。
keep-alive的限制和规则：
l 不是默认的，Client必须通过keep-alive首部激活；
l keep-alive首部必须和希望保持持久连接的报文一起发送；
l Client通过response中是否含有Connection：keep-alive判断Server是否会关闭连接；
l 只有在“实体的长度”不需要通过“连接关闭”就能确定的情况下才能使用keep-alive。也就是说实体的主体部分必须有正确的Content-Length、多部件的媒体类型，或者用分块编码传输方式；
l Proxies和网关必须执行Connection首部规则，同时必须在转发或缓存报文前将Connection首部删除；
l 不应该与不确定是否支持Connection首部的Server建立keep-alive连接；
l 从技术上讲，从HTTP/1.0设备收到Connection：keep-alive应该忽略；
l Clients必须做好重发request的准备，当连接在收到全部response前就关闭时。除非重发的request会产生副作用。
keep-alive和哑代理
盲中继（blind relay）：只是将字节从一个连接转发到另一个连接。它存在的问题如下图：
所以代理不能转发Connection首部和出现在Connection值中的首部。
通过插入Proxy-Connection来解决盲中继的方法：
但是，这种方案只能解决Client和Server之间只有一个代理的情况。在存在多层次的代理情况下上述问题仍会出现。
实际网络中出现“不可见”代理情况很常见，这些代理可能是防火墙、拦截缓存、反向代理加速器。它们对浏览器是不可见的，所以浏览器不会向它们发送Proxy-Connection首部。
2) HTTP/1.1的persistent
在默认情况下是激活的（HTTP1.0+的keep-alive默认不激活）。除非特别指明，否则HTTP/1.1假定所有连接都是永久链接。所以要在事务结束后关闭连接必须在报文（包括request和reponse）中显示添加Connection：close首部。
HTTP/1.1的persistent的局限和规则：
l 发送了Connection：close首部后，Client就无法在那条连接上发送更多的request了；
l 如果Client不想发生其他request，就应该在最后一个request时发送close；
l 只有报文有正确的、自定义报文长度时（例如：正确的Content-Length或者分块传输编码方式），连接才能持久保持；
l HTTP/1.1的代理必须能够分别管理Client和Server的持久连接（每个连接只适用于一跳传输）；
l HTTP/1.1的代理Server不应该与HTTP/1.0的Client建立持久连接；
l 注意：HTTP/1.1设备可以在任何时候关闭连接，尽管有时候不应该；
l HTTP/1.1应用程序必须能够从异步的关闭中恢复。Client应该重试这条请求，只要不存在可能累积起来的副作用；
l 在Client