為什么我們需要HTTP/2？

　　HTTP 1.0/1.1是最為人所知的網(wǎng)際網(wǎng)路通訊協(xié)定，然而，該標準最后一次修訂是在十幾年前，面對當前龐大的網(wǎng)頁(yè)應用需求，它有那些不合時(shí)宜的地方呢?

　　WWW 的運作，基本上，是倚靠名為HTTP(HyperText Transfer Protocol)的通訊協(xié)定，此協(xié)定的第一版為HTTP/1.0，但在 1999 年做了一些改進(jìn)之后，制定該協(xié)定規格的 IETF，將此改版命名為HTTP/1.1。而1999年問(wèn)世的HTTP/1.1協(xié)定，可以說(shuō)是主宰了整個(gè)Internet的流量至今，而且，成為了 Internet 最重要的應用層通訊協(xié)定之一。

　　但即使HTTP有著(zhù)如此的重要性，而且伴隨著(zhù)Web 的應用持續不斷的壯大，幾乎可以說(shuō)它就是 Internet 的主角了，但是它本身并非毫無(wú)缺點(diǎn)，事實(shí)上它的缺點(diǎn)還挺明顯的。HTTP就跟許多取得主宰性地位的協(xié)定一樣，其之所以能取得支配性的地位，不在其協(xié)定本身設計之優(yōu)勢，而是有著(zhù)其他的時(shí)空因素。HTTP簡(jiǎn)單易用、伴隨著(zhù)Web的快速成長(cháng)而成長(cháng)，最終得到了今天的地位。

　　但這組沿用許久未改版的協(xié)定，也因為網(wǎng)路生態(tài)的改變，而使其缺點(diǎn)影響層面愈來(lái)愈大，這些缺點(diǎn)主要集中在效能部份。因為HTTP主宰了Internet 的流量，因此，任何一點(diǎn)效能問(wèn)題，都足以產(chǎn)生巨大的影響。

　　在制定、設定HTTP時(shí)，可能也沒(méi)料想到今天應用的榮景。以今日瀏覽器所瀏覽的網(wǎng)頁(yè)來(lái)說(shuō)，其中伴隨著(zhù)的各種檔案不僅數量多，而且檔案長(cháng)度也大，和十幾年前的情況相比又大有所不同了。

　　HTTP既有版本的問(wèn)題

　　綜觀(guān)這十幾年來(lái)的應用，HTTP被觀(guān)察出那些傳輸效率上的缺點(diǎn)呢?首先，要先指出來(lái)，傳輸效率的不彰不見(jiàn)得單靠頻寬的擴增就能夠解決。的確，今日的頻寬和十幾年前也是大幅成長(cháng)、無(wú)法相提并論，因此，網(wǎng)路的基礎設施足以支持大檔案的應用。但是，增加頻寬可以降低傳輸大檔案的時(shí)間，卻無(wú)法解決HTTP協(xié)定本質(zhì)上所造成的“延遲(latency)”。

　　HTTP 底層的協(xié)定是TCP，因此，當HTTP的客戶(hù)端想要取得一個(gè)檔案資源時(shí)，就必須在一個(gè)TCP連線(xiàn)上發(fā)出請求。HTTP是一個(gè)基于“請求-回應”的協(xié)定，也是說(shuō)，總是由客戶(hù)端發(fā)出請求，而伺服器端對應一個(gè)回應。

　　在HTTP的伺服器端收到請求資訊后，會(huì )開(kāi)始處理該請求，在完成請求的處理之后，開(kāi)始回傳回應的內容。當HTTP伺服器端在處理請求時(shí)，整個(gè)TCP連線(xiàn)其實(shí)處于一個(gè)閑置的情況，此外，客戶(hù)端所能做的事也只有等待。

　　而且，通常一個(gè)要能夠在瀏覽器中瀏覽完整的網(wǎng)頁(yè)內容，這中間涉及許多的檔案需要透過(guò)HTTP去取得，而單一個(gè)TCP連線(xiàn)只能同時(shí)間處理一個(gè)檔案，為此，瀏覽器通常都會(huì )同時(shí)建立多個(gè)連線(xiàn)，以利更快的取得多個(gè)檔案的內容。否則，以HTTP的天性，必須逐一等待伺服器傳輸完前一個(gè)檔案后，才能夠再繼續取得下一個(gè)檔案。

　　面對傳輸效率不佳的狀況

　　在最早的HTTP/1.0協(xié)定中，每次發(fā)出一個(gè)HTTP的請求都需要重新建立一個(gè)TCP連線(xiàn)，當該請求的回應內容傳輸完畢之后，該TCP連線(xiàn)即會(huì )被切斷，而這是一個(gè)非常沒(méi)有效率的事情，怎么說(shuō)呢?

　　第一個(gè)原因，是TCP在建立連線(xiàn)時(shí)，連線(xiàn)的兩方需要完成一個(gè)所謂3-Way Handshaking的動(dòng)作，這會(huì )造成不小的延遲。對于一些每建立一個(gè)TCP連線(xiàn)，就會(huì )持續使用很長(cháng)一段時(shí)間的應用來(lái)說(shuō)，這個(gè)初始建立連線(xiàn)的延遲一點(diǎn)也不重要。例如，透過(guò)telnet協(xié)定連往BBS站時(shí)，只會(huì )建立一個(gè)TCP連線(xiàn)，卻可以使用很長(cháng)一段時(shí)間，這段建立連線(xiàn)所造成的延遲，就不影響整個(gè)大局。

　　但是，對基于“請求-回應”模式的HTTP來(lái)說(shuō)，如果透過(guò)HTTP回傳的檔案不夠大時(shí)，例如一個(gè)只有幾十 KB的HTML檔案，它可能不需要太多時(shí)間就可以完成傳輸，那么花在建立TCP連線(xiàn)上的延遲，占整體的比例就會(huì )高出很多。

　　在HTTP/1.0中更糟的是，一旦完成傳輸后，就會(huì )切斷TCP連線(xiàn)，之后倘若要請求另一個(gè)檔案，又必須重新建立一個(gè)全新的TCP連線(xiàn)，這使得每次都需要反覆不斷花費高昂的代價(jià)，在建立 TCP 連線(xiàn)之上，但每個(gè)TCP連線(xiàn)，卻又可能只傳輸少許的資料，就又被切斷了。

　　為此，在HTTP/1.1中，增加了讓連線(xiàn)“保持存活(Keep Alive)”的標頭(header)，讓客戶(hù)端及伺服器端可以協(xié)調重復運用同一個(gè)TCP連線(xiàn)，每當客戶(hù)端接收完來(lái)自伺服器端的回應內容后，可以繼續在同一 TCP 連線(xiàn)里發(fā)出下一個(gè)請求。

　　但這樣的設計可以讓情況好轉，但并沒(méi)有辦法完全解決，因為這個(gè)“保持存活”的情況，若是客戶(hù)端在一段時(shí)間內，并沒(méi)有繼續在TCP連線(xiàn)中發(fā)出下一個(gè)請求，此TCP連線(xiàn)亦會(huì )被切斷。

　　讓我們想想網(wǎng)頁(yè)瀏覽的行為模式，通常都是在載入完諸多檔案完畢后，使用者開(kāi)始花時(shí)間瀏覽。在載入諸多檔案時(shí)，“保持存活”的特性，可以避免重新建立太多TCP連線(xiàn)，但是當使用者在瀏覽網(wǎng)頁(yè)時(shí)，瀏覽器常不會(huì )再發(fā)送太多的請求至伺服器端，此時(shí)，先前已建立的TCP連線(xiàn)就會(huì )被切斷。等待使用者再連結到下一個(gè)網(wǎng)頁(yè)時(shí)，瀏覽器仍然必須重新建立若干個(gè)全新的TCP連線(xiàn)。

　　建立TCP連線(xiàn)的額外負擔當中，除了上述的3-Way Handshaking之外，還有一個(gè)部分，就是 TCP 的“緩起步( slow start)”特性。

　　TCP本身是一個(gè)具有流量控制(flow control)，以及擁塞控制(congestion control)能力的協(xié)定，因此，它會(huì )試著(zhù)估算單位時(shí)間內要傳輸多少資料量最有效率。當頻寬本身不足時(shí)，若是單位時(shí)間內試著(zhù)傳輸太多的資料量至另一端，但卻無(wú)法即時(shí)傳輸完成，就會(huì )造成擁塞。另一方面，若是頻寬充足，但卻傳輸的太少，又會(huì )造成效率不彰、無(wú)法善用頻寬的情況。

　　因此，TCP的演算法會(huì )盡量?jì)?yōu)化此事，而緩起步正是其演算法中的一環(huán)。TCP會(huì )逐步視情況擴展單位時(shí)間內所傳輸的資料量，但在網(wǎng)路連線(xiàn)剛建立之際，它會(huì )試著(zhù)從很小的傳輸量開(kāi)始嘗試，這使得在連線(xiàn)剛建立的初期，無(wú)法善用實(shí)際上可能十分充足的頻寬。

　　會(huì )產(chǎn)生很多短命的TCP連線(xiàn)

　　就和 3-Way Handshaking 一樣，對于那種生命期很短的TCP連線(xiàn)來(lái)說(shuō)，所造成的延遲影響比例就相對高出許多。但HTTP協(xié)定本身，就傾向于制造出諸多生命期很短的TCP連線(xiàn)，因此，我們可以說(shuō)，因為 HTTP 的天性，使得這些延遲產(chǎn)生出比較大的負面效應。

　　此外，同時(shí)間多個(gè)TCP連線(xiàn)并行傳輸的情況，也可能讓 TCP 演算法在做流量及擁塞控制時(shí)的估算失準，造成了無(wú)法在 TCP 之上進(jìn)行高效傳輸的結果。而每個(gè)客戶(hù)端都會(huì )同時(shí)和伺服器端建立多個(gè) TCP 連線(xiàn)的行為，也使得伺服器必須配置更多的網(wǎng)路連線(xiàn)資源來(lái)處理，例如占用更多的sockets及作業(yè)系統中的資源。而為了處理更多的連線(xiàn)請求，在多執行緒或程序的資源負擔，也變得更重。

　　所以總的來(lái)看，同時(shí)間多連線(xiàn)及短生命期傾向的TCP連線(xiàn)，正是HTTP在效率上打折扣的原因。而這樣的觀(guān)察，也正一步一步的導引著(zhù)、觸發(fā)著(zhù) HTTP改版的契機，其中影響最深遠的，莫過(guò)于 Google 的SPDY了。而有了SPDY協(xié)定，才催生了之后改版的HTTP/2。

　　在這一回里，我們談了舊有HTTP的問(wèn)題，而在下一回，我將介紹HTTP/2的內容，以及所做的改進(jìn)，是如何的解決舊有HTTP的毛病。