HTTP 1.0/1.1是最为人所知的网际网路通讯协定，然而，该标准最后一次修订是在十几年前，面对当前庞大的网页应用需求，它有那些不合时宜的地方呢?

WWW的运作，基本上，是倚靠名为HTTP(HyperText Transfer Protocol)的通讯协定，此协定的第一版为 HTTP/1.0，但在 1999 年做了一些改进之后，制定该协定规格的 IETF，将此改版命名为HTTP/1.1。而1999年问世的HTTP /1.1协定，可以说是主宰了整个Internet的流量至今，而且，成为了 Internet 最重要的应用层通讯协定之一。

　　但即使 HTTP有着如此的重要性，而且伴随着Web 的应用持续不断的壮大，几乎可以说它就是 Internet 的主角了，但是它本身并非毫无缺点，事实上它 的缺点还挺明显的。HTTP就跟许多取得主宰性地位的协定一样，其之所以能取得支配性的地位，不在其协定本身设计之优势，而是有着其他的时空因素。 HTTP简单易用、伴随着Web的快速成长而成长，最终得到了今天的地位。

　　但这组沿用许久未改版的协定，也因为网路生态的改变，而使其缺点影响层面愈来愈大，这些缺点主要集中在效能部份。因为HTTP主宰了Internet 的流量，因此，任何一点效能问题，都足以产生巨大的影响。

　　在制定、设定HTTP时，可能也没料想到今天应用的荣景。以今日浏览器所浏览的网页来说，其中伴随着的各种档案不仅数量多，而且档案长度也大，和十几年前的情况相比又大有所不同了。

　　HTTP既有版本的问题

　 　综观这十几年来的应用，HTTP被观察出那些传输效率上的缺点呢?首先，要先指出来，传输效率的不彰不见得单靠频宽的扩增就能够解决。的确，今日的频宽 和十几年前也是大幅成长、无法相提并论，因此，网路的基础设施足以支持大档案的应用。但是，增加频宽可以降低传输大档案的时间，却无法解决HTTP协定本 质上所造成的“延迟(latency)”。

　　HTTP 底层的协定是TCP，因此，当HTTP的客户端想要取得一个档案资源时，就必须在一个TCP连线上发出请求。HTTP是一个基于“请求-回应”的协定，也是说，总是由客户端发出请求，而伺服器端对应一个回应。

　　在HTTP的伺服器端收到请求资讯后，会开始处理该请求，在完成请求的处理之后，开始回传回应的内容。当HTTP伺服器端在处理请求时，整个TCP连线其实处于一个闲置的情况，此外，客户端所能做的事也只有等待。

　 　而且，通常一个要能够在浏览器中浏览完整的网页内容，这中间涉及许多的档案需要透过HTTP去取得，而单一个TCP连线只能同时间处理一个档案，为此， 浏览器通常都会同时建立多个连线，以利更快的取得多个档案的内容。否则，以HTTP的天性，必须逐一等待伺服器传输完前一个档案后，才能够再继续取得下一 个档案。

　　面对传输效率不佳的状况

　　在最早的HTTP/1.0协定中，每次发出一个HTTP的请求都需要重新建立一个TCP连线，当该请求的回应内容传输完毕之后，该TCP连线即会被切断，而这是一个非常没有效率的事情，怎么说呢?

　 　第一个原因，是TCP在建立连线时，连线的两方需要完成一个所谓3-Way Handshaking的动作，这会造成不小的延迟。对于一些每建立一个 TCP连线，就会持续使用很长一段时间的应用来说，这个初始建立连线的延迟一点也不重要。例如，透过telnet协定连往BBS站时，只会建立一个TCP 连线，却可以使用很长一段时间，这段建立连线所造成的延迟，就不影响整个大局。

　　但是，对基于“请求-回应”模式的HTTP来说，如果透过HTTP回传的档案不够大时，例如一个只有几十 KB的HTML档案，它可能不需要太多时间就可以完成传输，那么花在建立TCP连线上的延迟，占整体的比例就会高出很多。

　　在HTTP/1.0中更糟的是，一旦完成传输后，就会切断TCP连线，之后倘若要请求另一个档案，又必须重新建立一个全新的TCP连线，这使得每次都需要反覆不断花费高昂的代价，在建立 TCP 连线之上，但每个TCP连线，却又可能只传输少许的资料，就又被切断了。

　　为此，在HTTP/1.1中，增加了让连线“保持存活(Keep Alive)”的标头(header)，让客户端及伺服器端可以协调重复运用同一个TCP连线，每当客户端接收完来自伺服器端的回应内容后，可以继续在同一 TCP 连线里发出下一个请求。

　　但这样的设计可以让情况好转，但并没有办法完全解决，因为这个“保持存活”的情况，若是客户端在一段时间内，并没有继续在TCP连线中发出下一个请求，此TCP连线亦会被切断。

　 　让我们想想网页浏览的行为模式，通常都是在载入完诸多档案完毕后，使用者开始花时间浏览。在载入诸多档案时，“保持存活”的特性，可以避免重新建立太多 TCP连线，但是当使用者在浏览网页时，浏览器常不会再发送太多的请求至伺服器端，此时，先前已建立的TCP连线就会被切断。等待使用者再连结到下一个网 页时，浏览器仍然必须重新建立若干个全新的TCP连线。

　　建立TCP连线的额外负担当中，除了上述的3-Way Handshaking之外，还有一个部分，就是 TCP 的“缓起步( slow start)”特性。

　 　TCP本身是一个具有流量控制(flow control)，以及拥塞控制(congestion control)能力的协定，因此，它会试着估算单 位时间内要传输多少资料量最有效率。当频宽本身不足时，若是单位时间内试着传输太多的资料量至另一端，但却无法即时传输完成，就会造成拥塞。另一方面，若 是频宽充足，但却传输的太少，又会造成效率不彰、无法善用频宽的情况。

　　因此，TCP的演算法会尽量优化此事，而缓起步正是其演算法中的一环。TCP会逐步视情况扩展单位时间内所传输的资料量，但在网路连线刚建立之际，它会试着从很小的传输量开始尝试，这使得在连线刚建立的初期，无法善用实际上可能十分充足的频宽。

　　会产生很多短命的TCP连线

　 　就和 3-Way Handshaking 一样，对于那种生命期很短的TCP连线来说，所造成的延迟影响比例就相对高出许多。但HTTP协定本身，就 倾向于制造出诸多生命期很短的TCP连线，因此，我们可以说，因为 HTTP 的天性，使得这些延迟产生出比较大的负面效应。

　　此外，同 时间多个TCP连线并行传输的情况，也可能让 TCP 演算法在做流量及拥塞控制时的估算失准，造成了无法在 TCP 之上进行高效传输的结果。而每个客 户端都会同时和伺服器端建立多个 TCP 连线的行为，也使得伺服器必须配置更多的网路连线资源来处理，例如占用更多的sockets及作业系统中的资 源。而为了处理更多的连线请求，在多执行绪或程序的资源负担，也变得更重。

　　所以总的来看，同时间多连线及短生命期倾向的TCP连线，正 是HTTP在效率上打折扣的原因。而这样的观察，也正一步一步的导引着、触发着 HTTP改版的契机，其中影响最深远的，莫过于 Google 的 SPDY了。而有了SPDY协定，才催生了之后改版的HTTP/2。

　　在这一回里，我们谈了旧有HTTP的问题，而在下一回，我将介绍HTTP/2的内容，以及所做的改进，是如何的解决旧有HTTP的毛病。