HTTP超文本传输协议-HTTP/1.1[08.连接]

8.连接

8.1 持续连接.

8.1.1 目的

在持续连接之前,为获取每一URL都建立了独立的TCP 连接,这就加重了HTTP服务器的负担,易引起INTERNET阻塞.嵌入式图片与其它相关数据通常使用户在短时间内对同一服务器提交多个请求.目前已有 针对这些性能问题的分析以及原型实施的结果[26],[30]. 实施的具体过程和对实际HTTP/1.1(RFC 2068)的测试均显示了良好的结果[39]. 对其他方法也有了初步探究,如T/TCP [27]. 持续HTTP 连接有着诸多的优点: --- 通过建立与关闭较少的连接,不仅节省了路由器与主机(客户机,服务器,代理服务器,网关,隧道或高速缓冲存储机)的CPU时间,还节省了主机用于TCP协 议控制块的内存. --- HTTP请求与应答可以进入连接流水线. 流水线方式使得客户无须挨个等待应答即发起多个请求,从而更充分的利用了单个的TCP连接,减少了崩溃时间. --- 在减少TCP连接中数据包个数的同时,使TCP有了充裕的时间来确定网络的拥塞状况,缓解了网络拥塞. --- 因为无须在创建TCP连接握手上耗费时间,而使连续请求造成的延迟现象得到改善. --- 由于出错不会导致TCP连接的关闭,HTTP可以更好的实现自我完善.使用较新版HTTP的用户会乐于尝试一些新功能,与旧版服务器通信时,则会在接到出 错报告后用旧模式重试. HTTP的实现应当采用持续连接.

8.1.2 总体操作

HTTP/1.1 与早期HTTP 版本的一个显著区别在于持续连接是任何HTTP连接的缺省方式.也就是说,除非另有指定,客户机总应当假定服务器会保持持续连接,即便在接到服务器的出错 应答时也应如此. 持续连接提供了一种可以由客户机或服务器发信号终止TCP连接的机制.终止连接的信号利用了"连接"报头域(14.10节).一旦出现了终止连接的信号, 客户机便不可再向此连接提出任何新请求.

8.1.2.1 谈判

除非请求的连接报头域中包括了"终止连接"的符号,HTTP/1.1服务器总可以假定HTTP/1.1 客户机想要维持持续连接.如果服务器想在发出应答后立即终止连接,它应当发送一个含有终止要求的连接报头域. 无论是客户机或服务器发起终止连接,这都是本次连接的最后一个请求. 除非经明确指出,客户机与服务器不应假定低版HTTP会自动采用持续连接方式.请参见19.6.2节关于与HTTP/1.0客户机后向兼容性的有关内容. 为了维持持续连接,连接中的报文都必须有如4.4节所述的自定义报文长度(即不是由连接终止定义的长度).

8.1.2.2 流水线

支持持续连接的客户机可以以流水线方式发送请求(即无须等待应答而发送多个请求).服务器则必须将其应答按接到请求的顺序发出. 建立连接后立即采用持续连接与流水线方式的客户机应作好初次流水线尝试失败后重试的准备,而不可在持续连接尚未确定时就连续发送请求.客户机还必须为服务 器在发出所有应答之前就结束连接的情况作好重发请求的准备. 客户机不应该用非等幂方法或非等幂方法序列(参见9.1.2节)连发请求.否则,过早终止的传输层连接会导致不确定的结果.

8.1.3 代理服务器

使代理服务器正确地实现14.10节所规定的连接报头域的属性是非常关键的. 代理服务器必须独立于它所连接的客户机,原服务器(或其它代理服务器)而发出持续连接的信号.每一持续连接仅针对传输层链接. 代理服务器不可与一台HTTP/1.0客户机建立HTTP/1.1持续连接(请参见RFC 2068 [33] 中关于HTTP/1.0客户机上实现"维持活跃态"报头问题的探讨及资料)

8.1.4 实际的考虑

服务器通常有一个时限值,超过一定时间即不再维系处于非活跃态的连接.代理服务器会选一个较高的值,因为客户机很可能会与同一服务器建立多个连接.持续连 接方式的采用对于客户机与服务器的时限均未提出任何要求.当客户机或服务器希望超时终止时,它应按规范终止传输连接.客户端与服务器端应始终注意对方是否 终止了连接,并适当的予以应答.若客户机或服务器未能及时检测到对方已终止了连接,将会造成不必要的网络资源浪费. 客户机,服务器,或代理服务器可能在任意时刻终止传输连接.比如,客户机可能正想发出新的请求,而此时服务器却决定关闭"闲置"的连接.在服务器看来,连 接是在闲置状况下被关闭的, 而客户机却以为请求在进行中. 这表明客户机,服务器与代理服务器必须有能力从非同步的连接终止事件中恢复.只要请求序列是等幂的(参见9.1.2节),客户端软件就应自动重新发起传输 层连接并重传被废弃的请求序列.对非等幂方法或序列不可自动重试,但用户代理可以向手工操作员提供重发请求的机会.用户代理软件对应用程序基于句法理解的 确认可以用来代替人工方式.若重试失败,则不应允许再试. 服务器在每次连接中只要有可能,总应至少应答一个请求.除非出于网络或客户端的故障,服务器不应在传送应答的中途断开连接. 使用持续连接的客户机应限制与某一服务器同时连接的个数.单用户客户机不应与任一服务器或代理服务器保持两个以上的连接.代理服务器与其它服务器或代理之 间应维护2*N个连接,其中N是同时在线的用户数.设定这一规则是为了改进HTTP应答时间且避免拥塞.

8.2 报文传输要求、

8.2.1 持续连接与流量控制

HTTP/1.1服务器应当保持持续连接并使用TCP的流量控制机制来解决临时过载,而不是在终止连接后指望客户端的重试.后一方法会恶化网络阻塞.

8.2.2 监视连接中出错状态的报文

发送报文正文的HTTP/1.1(或更新)客户机应在传输请求的同时监视连接是否处于出错状态.若客户机发现了错误,它应当立即停止正文的传送.若正文是 以块编码方式发送的(3.6节),可以用一长度为零的块和空报尾来提前标记报文结束.若正文前有"内容长度"报头,则客户机必须关闭连接.

8.2.3 100号状态的用途

100号状态的目的在于帮助那些发送含有请求正文的请求报文的客户机在发送请求正文之前推测服务器看到请求报头后是否愿意接收请求.有些时候,如果服务器 不看正文就弃置报文的话,客户机对正文的发送就多此一举了. 对HTTP/1.1 客户机的要求: --- 若客户机在发送请求正文之前等候100(继续)应答,则它必须发送填有"100--继续"期望的"期待请求"报头域(14.20节). --- 若客户机不需要发送请求正文,则它不得发送填有"100--继续"期望的"期待请求"报头域(14.20节). 由于存在旧的实现方法,协议允许出现诸如客户机发出了"期望:100-继续" 却没接到417(期望失败)或100(继续)状态的混乱局面存在.因此,当客户机将这一报头域发给它从未接到100(继续)状态的原服务器(通常是通过代 理)时, 客户机不应在发送请求正文前无限期地等待. 对HTTP/1.1原服务器的要求: --- 在接到"期望"请求报头域填有"100-继续"期望的请求时,原服务器必须以100(继续)状态应答并继续读入数据流,或者以终止状态码应答.原服务器在 发送100(继续)应答之前不得等待.若以终止状态码应答,它既可关闭传输层连接,也可继续读入数据而丢弃请求的剩余部分.但此时它不得按客户机所请求的 方式运行. --- 如请求报文不含填有"100-继续"的"期望"报头域,原服务器不应发送100(继续)应答.当请求来自HTTP/1.0(或更早)客户机时也不得发送 100(继续)应答.对此规定有一例外:为了与RFC 2068兼容,服务器对于未含填有"100-继续"的"期望"报头域的PUT或POST 请求可以应答100(继续)状态.这一例外的目的在于尽量减少由100(继续)状态的未申明等待引起的客户机处理延迟,仅适用于HTTP/1.1请求,和 其它HTTP 版本的请求无关. --- 若已经接到相应请求的部分或全部请求正文,原服务器可以免发100(继续)应答. --- 一旦请求正文被收到处理,发出100(继续)应答的原服务器除非过早切断传输层连接,否则最终必须发送终止状态码. --- 若原服务器接到不含填有"100-继续"的"期望"报头域的请求,该请求含有请求正文,而服务器又在从传输层连接读入正文之前就应答了终止状态码,则服务 器不应在读完全部请求或客户机终止连接前关闭连接. 否则,客户机可能无法可靠地接收应答报文.然而,这一要求在阐释中不应阻止服务器防卫拒绝服务的攻击或有严重缺陷的客户程序. 对代理服务器的要求: --- 若代理服务器接到包含填有"100-继续"的"期望"报头域的请求,且代理服务器要么知道下一站服务器遵循HTTP/1.1或更高版协议,要么不知下一站 服务器的HTTP版本,则它必须连同"期望"报头域一起转发此请求. --- 若且代理服务器知道下一站服务器版本是HTTP/1.0或更低,则它不得转发此请求,而应应答以417(期望失效)状态. --- 代理服务器应当维护一高速缓存,以记录新近访问到的下一站点服务器的HTTP版本号. --- 若接到的请求来自于版本是HTTP/1.0(或更低)的客户机,不含填有"100-继续"的"期望"报头域的请求,则代理服务器不得转发100(继续)应 答. 这一要求可覆盖1xx应答转发的一般规则(参见10.1节).

8.2.4 服务器过早关闭连接时客户机的行为

如果HTTP/1.1 客户机发出一条含有请求正文但不含填有"100-继续"的"期望"报头域的请求,并且客户机直接与HTTP/1.1原服务器相连,在从服务器处接到任何状 态信息之前就发现连接被关闭,那么客户机应当重试请求.在重试时,客户机何以采用如下所述的"二进制指数后退算法"以确保获得可靠应答: 1. 向服务器发起一新连接. 2. 发送请求的报头. 3. 初始化变量R为通往服务器的往返时间的估计值(比如基于建立连接的时间),或在无法估计往返时间时设为一常数值5秒. 4. 计算T=R*(2**N),N为此前重试请求的次数. 5. 等待服务器发来的出错应答或是T秒(两者中时间较短的). 6. 若没等到出错应答,T秒后发送请求正文. 7. 若客户机发现连接被提前终止,转到第1步,直到请求被接受,接到出错应答,或是用户因不耐烦而终止了重试进程. 在任意环节上,客户机如果接到出错状态, --- 不应再继续, 并且 --- 如完成请求报文的发送则应终止连接