HTTP权威指南第四章(1)

HTTP链接管理

本文涉及的内容主要有:

• HTTP是如何使用TCP进行链接的

• HTTP链接的限制,包括时延/瓶颈存在的障碍

• 如何优化HTTP链接和显示.

因为我的缘由,本文只到HTTP链接优化的并行链接部分.其余部分得要往后再说了.本文不会对TCP/IP进行过多的阐述,最多只能到大概能讲两个协议是如何交互的程度.因为是抄书加上本人自做聪明的一些理解,请各位发现错误的时候,有时间能够说一声.

一:TCP链接

TCP/IP协议是一种经常使用的分组交换网络分层协议.客户端经过创建与服务器的链接,从而交换报文.报文永远不会丢失,受损或者失序¹.

HTTP链接实际上就是创建一条TCP链接管道,然后经过TCP提供的可靠的比特传输管道 进行交互,一端填入的字节会以原有的顺序正确地传送到另外一端.而这种传送,是经过分段来实现的.

以传送报文为例,链接过程是这样的:

1. HTTP应用程序打开一条TCP链接,并以流的形式将报文数据按序传输.

2. TCP链接将数据分为小数据块,称做"段"

3. 段被封装到IP分组中经过网络进行传输.

每一个TCP段都由IP分组承载,在IP地址之间发送.其分组包括:

• 一个IP分组首部

• 一个TCP段首部

• 一个TCP数据块

为了保持TCP链接的正确运行,TCP用的是端口来实现.每一个端口对应一个应用程序,每一个IP地址对应一个计算机.要经过四个值:源IP地址/目标IP地址/源端口/目标端口来识别一个TCP链接.因此,每一个链接的四个值不能重合(这实际上会致使性能问题,后面会说起)

1.1.TCP套接字

为了操纵TCP链接,操做系统提供了一系列TCP编程接口.下面就是套接字API提供的主要接口了．其隐藏了全部细节．

套接字API调用	描述
s = socket(<parameters>)	创建一个新的套接字(未命名/未关联)
bind(s,<localIP:port>)	为套接字赋予端口和本地IP
connect(s, remote IP:port)	创建与远程服务器和端口的链接
listen(s,...)	标识一个本地套接字,使其能够合法地接受链接
s2 = accept(s)	等待他人创建到本地端口的链接
result = read(s, buffer, n)	尝试从套接字向缓冲区读取n个字节
data = write(s, buffer, n)	尝试从缓冲区向套接字写入n个字节
close(s)	彻底关闭TCP链接
shutdown(s)	关闭TCP链接的一端(输入或者输出)
getsocketopt()	读取某个内部套接字配置选项的值
setsocketopt()	修改某个内部套接字配置选项的值

套接字API隐藏了全部细节:全部底层网络协议的握手细节/TCP数据流/IP分组之间的分段和重装等等.

二:TCP性能的考虑

因为HTTP协议位于TCP协议的上层,HTTP事务的性能大部分取决于TCP通道的性能．下面会列出几个TCP的某些基本性能特色，用于辅助咱们理解HTTP的链接优化特性.若是对提高TCP的性能要考虑的细节不感兴趣,能够跳过...

2.1.HTTP事务的时延

HTTP事务在DNS查询/创建链接/传输请求和响应报文这四个部分存在时延.与其相比,真正的HTTP事务处理时间很短.产生时延的主要缘由有如下几点:

• 客户端须要经过URI来肯定Web服务器的IP地址和端口号.而若是最近没有访问该站点,则经过DNS解析系统可能须要花数十秒的时间查询IP地址.²

• 客户端会发送一条TCP链接请求,并等待服务器应答.因此每一个新的TCP链接都会存在链接创建时延.虽然值很小,可是若是事务数以百计的话,就很可观了.

• 创建链接之后,客户端发送请求/服务器处理请求和响应报文等,都须要时间

这些时延的影响因素不少:硬件速度,网络,服务器的负载等等,甚至TCP协议的复杂性也会产生影响.

2.2.性能聚焦区域

常见的TCP相关时延有:

• TCP链接创建握手

• TCP慢启动拥塞控制

• 数据汇集的Nagle算法

• 用于捎带确认的TCP延迟确认算法

• TIME_WAIT的时延和端口耗尽

下面这部分的内容针对的是高性能HTTP软件编写,但一我自己水平不够,二这一等级的性能优化并不老是须要.若是愿意,请继续往下读.

2.3.TCP链接创建握手

创建一条新的TCP链接时,TCP软件会交换一系列IP分组,沟通与链接有关的参数.若是链接只用于传输少许数据,则会严重下降HTTP的性能.其创建握手的步骤是:

1. 向服务器发送小的TCP分组,其中设置一个特殊的SNY标记,说明这是链接请求.

2. 服务器接受链接,计算链接参数,并返回一个SNY和ACK标记都被置位的TCP分组,说明接受链接请求.

3. 客户端发送一条确认信息,通知其链接创建成功.该部分容许客户端发送数据.

这些分组由TCP/IP软件管理,只是会致使建立TCP链接时,存在时延.因为一个事务不会交换太多数据,而屡次握手会.因此小的HTTP事务可能在建立TCP链接的时候花费大量时间.为此,后面会讨论如何重用现存链接来减小该类型的时延.

2.4.延迟确认

TCP实现了本身的确认机制保证数据成功传输.这个机制的工做过程是这样的:

1. 赋予每一个TCP段一个序列号和完整性校验和,发送出去.

2. 服务器收到之后,发送一个小的确认分组

3. 客户端如何没有在指定时间内收到确认分组,则认为分组已经损坏,并从新发送数据.

因为确认报文很小,能够将返回的确认信息与数据分组结合.而延迟确认就是:HTTP服务器会在一个特定时间内将输出确认存储到缓冲区中,寻找能够捎带确认的输出数据分组.如;若是没有,则单独发送.

这与HTTP具备双峰特征的请求--应答行为结合,致使捎带确认的可能性下降.这种回传分组不老是那么多,因此该算法会引入至关大的时延.根据平台的差别,能够调整或者禁用该算法.

P.S.对TCP配置进行的任意修改,都要绝对保证应用程序不会引起这些算法所要避免的问题.

2.5.TCP慢启动

TCP数据传输的性能还取决于链接的使用期(age ).TCP链接会随时间进行自我"调谐",性能会从最初的限制到提升传输速度.这被称为TCP慢启动(slow start ),用于防止过载和拥塞.

但这种行为限制了一个TCP端点在任意时刻能够传输的分组数量.发送的分组数量限制是随着时间和一次次成功接受分组而减小的(就是说,分组数量愈来愈多).这叫作打开拥塞窗口.

因为这种特性的存在,新链接的传输速度老是比较慢的,因而引入了重用先存链接的工具,这就是稍后介绍的持久链接.

2.6.Nagle算法

TCP有一个数据流端口,能够放入任意大小的数据.可是若是发送大量包含少许数据的分组,则会致使性能严重降低.³

而Negle算法则试图在发送一个分组以前,绑定大量TCP数据,以提升网络的效率.该算法鼓励发送全尺寸的段(LAN上是1500字节,www上是几百字节).只有其余分组都被确认之后,该算法才会容许发送非全尺寸的分组 ;若是其余分组仍在传输中,那一部分数据就会缓存起来;只有积累的尺寸足够,或者有挂起分组被确认的时候,其才会将缓存的数据发送出去.

该算法会引起多种性能问题:

• 小的HTTP报文可能没法塞满全尺寸分组,会一直等待其余数据而致使时延.

• 该算法会阻止数据发送,直到有确认分组到达;但确认分组自身因为延迟确认算法会致使时延.

因此,HTTP程序员会在栈中设置参数TCP_NODELAY禁用该算法.但这须要保证写入大块数据!

2.7.TIME_WAIT积累与端口耗尽

这是严重的性能问题,会影响性能基准.虽然较少出现,可是遇到性能基准问题时,一般是这个问题.且结果特别糟糕.

当某个TCP链接关闭时,内存中会维持一个小控制块,记录最近的TCP链接的端口号和IP,会维持一段时间(2分钟左右),一般是所估计的最大分段使用期的两倍(成为2MSL).

可是,如今高速路由的出现致使重复分组几乎不可能在关闭链接的几分钟以后,出如今服务器上.因此,有的操做系统会改小这个值.但要当心:分组确实会被赋值,若是来自以前的复制分组插入链接值相同的新TCP流,则会破坏TCP数据.

在性能基准环境下,这个2MSL的链接关闭延迟会成为大问题.因为:

• 测试的机子只有几台,IP数量受限

• 服务器在默认端口上监听,端口号也受限了.

假设只有一台测试用机器,这样四个值(源IP地址/目标IP地址/源端口/目标端口)就只有一个值是可变的了.因为可用的端口数量有限,链接率(每秒链接的次数)就会固定在一个较低的次数.要修正该问题,有如下方法:

• 是增长客户端负载生成及其的数量

• 循环使用虚拟IP地址

可是,若是在大量链接处于打开状态的状况,或者处于等待状态的链接分配大量控制块的状况,会致使操做系统的速度大降.

---

3、HTTP链接的处理

正常状况下,HTTP链接过程当中存在一串HTTP中间实体(代理/高速缓存等等),而中间实体之间会交流一些信息,这些信息就存放在Connection首部中.这在等下会说起;除此以外,HTTP的事务处理一般是串行进行,因此存在性能延时的叠加.这也是咱们要考虑的问题.

3.1.Connection首部

两个相邻的HTTP应用层程序会在共享的一条链接中应用一组选项,而Connection首部则有一个用逗号分割的链接标签 列表,指定了不会给其余链接的选项.好比,使用Connection: close指定发送完下一跳报文后关闭的链接.

Connection首部承载的标签有三种:

• HTTP首部字段名.列出只与当前链接相关的字段

• 任意标签名,用于描述使用的非标准选项

• close,关闭链接

因为Connection首部能够避免对本地首部的无心转发,因此将逐跳首部名放入其中被称做"对首部的保护".Connection首部及其列举字段都会在转发时被删除.

3.2.串行事务处理

若是使用串行事务处理,TCP的性能时延会叠加起来.假设加载一个包含了三张图片的Web页面,发起4个HTTP事务来显示页面,且每一个事务都须要一个新的链接,则会叠加链接时延和慢启动时延.

这种时延除了实际上的等待时间,还有心理上的⁴.同时加载多幅图片会比较好.除此以外,若是浏览器在对象加载完成以前没法知晓对象尺寸,同时须要尺寸信息决定如何排版.这时候若是加载对象数量不够,就不会显示任何东西.可能加载进度正常,可是用户只能看着白屏大怒.

如今,有四种方法能够提升HTTP的链接性能.

• 并行链接:经过多条TCP链接发起HTTP请求.

• 持久链接:经过重用TCP链接,消除链接和关闭时延

• 管道化链接:共享TCP链接发起并发的HTTP请求.

• 复用的链接:交替传送请求和响应报文.(实验中)

---

4、并行链接

该方法容许客户端打开多条链接,并行地执行多个HTTP事务.包含嵌入对象的组合页面若是能够克服单条链接的空载时间和带宽限制,就能够重叠时延.若是带宽够大,就可能够将未用带宽进行分配.时延并非不存在,可是会使得其大部分重叠.

4.1.局限

并行链接的速度并不老是更快 .这有两个缘由:

• 用户的带宽不足.若是带宽足够小,则不得不花费大部分时间来传送数据.这时 若是链接的服务器速度较快,则带宽会迅速耗尽.

• 若是多个对象竞争优先的带宽,则会致使每一个对象的速度都慢下来.

• 打开大量链接会消耗大量内存,对于服务器和客户端都是.因此,浏览器会限制并行链接的总数,而服务器会随意关闭来自特定客户端的超量链接.

P.S.安慰剂

用户一般以为并行链接更快,由于:用户看得见加载的进展.

---

1. 实际上,若是计算机或者网络崩溃,链接会断开,但这种时候对通知两端通讯中断. ↩
2. 浏览器会存储一个DNS缓存,保存最近访问的站点的IP地址.因此若是是常常访问的网站,能够当即完成查询. ↩
3. 这种行为称做"发送端傻窗口综合症",有违社会公序良俗,应该立法禁止之.('_') ↩
4. 即便同时加载多幅图片比较慢,人们心理上也会以为快一些... ↩