雖然 HTTP 協(xié)議既簡單又簡捷，但隨著時(shí)代的發(fā)展，其功能使用上捉襟見肘的疲態(tài)已經(jīng)凸顯。本章我們將講解基于 HTTP 新增的功能的協(xié)議。

一、基于HTTP的協(xié)議

在建立 HTTP 標(biāo)準(zhǔn)規(guī)范時(shí)，制訂者主要想把 HTTP 當(dāng)作傳輸 HTML文檔的協(xié)議。隨著時(shí)代的發(fā)展，Web 的用途更具多樣性，比如演化成在線購物網(wǎng)站、SNS（Social Networking Service，社交網(wǎng)絡(luò)服務(wù)）、企業(yè)或組織內(nèi)部的各種管理工具，等等。
而這些網(wǎng)站所追求的功能可通過 Web 應(yīng)用和腳本程序?qū)崿F(xiàn)。即使這些功能已經(jīng)滿足需求，在性能上卻未必最優(yōu)，這是因?yàn)?HTTP 協(xié)議上的限制以及自身性能有限。
HTTP 功能上的不足可通過創(chuàng)建一套全新的協(xié)議來彌補(bǔ)?？墒悄壳盎?HTTP 的 Web 瀏覽器的使用環(huán)境已遍布全球，因此無法完全拋棄HTTP。有一些新協(xié)議的規(guī)則是基于 HTTP 的，并在此基礎(chǔ)上添加了新的功能。

二、消除HTTP瓶頸的SPDY

Google 在 2010 年發(fā)布了 SPDY（取自 SPeeDY，發(fā)音同 speedy），其開發(fā)目標(biāo)旨在解決 HTTP 的性能瓶頸，縮短 Web 頁面的加載時(shí)間（50%）。

• SPDY- The Chromium Projects
  http://www.chromium.org/spdy/

1、HTTP的瓶頸

在 Facebook 和 Twitter 等 SNS 網(wǎng)站上，幾乎能夠?qū)崟r(shí)觀察到海量用戶公開發(fā)布的內(nèi)容，這也是一種樂趣。當(dāng)幾百、幾千萬的用戶發(fā)布內(nèi)容時(shí)，Web 網(wǎng)站為了保存這些新增內(nèi)容，在很短的時(shí)間內(nèi)就會發(fā)生大量的內(nèi)容更新。
為了盡可能實(shí)時(shí)地顯示這些更新的內(nèi)容，服務(wù)器上一有內(nèi)容更新，就需要直接把那些內(nèi)容反饋到客戶端的界面上。雖然看起來挺簡單的，但 HTTP 卻無法妥善地處理好這項(xiàng)任務(wù)。
使用 HTTP 協(xié)議探知服務(wù)器上是否有內(nèi)容更新，就必須頻繁地從客戶端到服務(wù)器端進(jìn)行確認(rèn)。如果服務(wù)器上沒有內(nèi)容更新，那么就會產(chǎn)生徒勞的通信。
若想在現(xiàn)有 Web 實(shí)現(xiàn)所需的功能，以下這些 HTTP 標(biāo)準(zhǔn)就會成為瓶頸。

• 一條連接上只可發(fā)送一個(gè)請求。
• 請求只能從客戶端開始?？蛻舳瞬豢梢越邮粘憫?yīng)以外的指令。
• 請求 / 響應(yīng)首部未經(jīng)壓縮就發(fā)送。首部信息越多延遲越大。
• 發(fā)送冗長的首部。每次互相發(fā)送相同的首部造成的浪費(fèi)較多。
• 一條連接上只可發(fā)送一個(gè)請求。
  
  圖：以前的 HTTP 通信

Ajax 的解決方法

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML技術(shù)）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操作，以達(dá)到局部 Web 頁面替換加載的異步通信手段。和以前的同步通信相比，由于它只更新一部分頁面，響應(yīng)中傳輸?shù)臄?shù)據(jù)量會因此而減少，這一優(yōu)點(diǎn)顯而易見。
Ajax 的核心技術(shù)是名為 XMLHttpRequest 的 API，通過 JavaScript 腳本語言的調(diào)用就能和服務(wù)器進(jìn)行 HTTP 通信。借由這種手段，就能從已加載完畢的 Web 頁面上發(fā)起請求，只更新局部頁面。
而利用 Ajax 實(shí)時(shí)地從服務(wù)器獲取內(nèi)容，有可能會導(dǎo)致大量請求產(chǎn)生。另外，Ajax 仍未解決 HTTP 協(xié)議本身存在的問題。

Comet 的解決方法

一旦服務(wù)器端有內(nèi)容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應(yīng)。這是一種通過延遲應(yīng)答，模擬實(shí)現(xiàn)服務(wù)器端向客戶端推送（Server Push）的功能。
通常，服務(wù)器端接收到請求，在處理完畢后就會立即返回響應(yīng)，但為了實(shí)現(xiàn)推送功能，Comet 會先將響應(yīng)置于掛起狀態(tài)，當(dāng)服務(wù)器端有內(nèi)容更新時(shí)，再返回該響應(yīng)。因此，服務(wù)器端一旦有更新，就可以立即反饋給客戶端。
內(nèi)容上雖然可以做到實(shí)時(shí)更新，但為了保留響應(yīng)，一次連接的持續(xù)時(shí)間也變長了。期間，為了維持連接會消耗更多的資源。另外，Comet也仍未解決 HTTP 協(xié)議本身存在的問題。

SPDY的目標(biāo)

陸續(xù)出現(xiàn)的 Ajax 和 Comet 等提高易用性的技術(shù)，一定程度上使 HTTP得到了改善，但 HTTP 協(xié)議本身的限制也令人有些束手無策。為了進(jìn)行根本性的改善，需要有一些協(xié)議層面上的改動。處于持續(xù)開發(fā)狀態(tài)中的 SPDY 協(xié)議，正是為了在協(xié)議級別消除 HTTP所遭遇的瓶頸。

2、SPDY的設(shè)計(jì)與功能

SPDY 沒有完全改寫 HTTP 協(xié)議，而是在 TCP/IP 的應(yīng)用層與運(yùn)輸層之間通過新加會話層的形式運(yùn)作。同時(shí)，考慮到安全性問題，SPDY 規(guī)定通信中使用 SSL。
SPDY 以會話層的形式加入，控制對數(shù)據(jù)的流動，但還是采用 HTTP建立通信連接。因此，可照常使用 HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 報(bào)文等。

使用 SPDY 后，HTTP 協(xié)議額外獲得以下功能。

• 多路復(fù)用流
  通過單一的 TCP 連接，可以無限制處理多個(gè) HTTP 請求。所有請求的處理都在一條 TCP 連接上完成，因此 TCP 的處理效率得到提高。
• 賦予請求優(yōu)先級
  SPDY 不僅可以無限制地并發(fā)處理請求，還可以給請求逐個(gè)分配優(yōu)先級順序。這樣主要是為了在發(fā)送多個(gè)請求時(shí)，解決因帶寬低而導(dǎo)致響應(yīng)變慢的問題。
• 壓縮 HTTP 首部
  壓縮 HTTP 請求和響應(yīng)的首部。這樣一來，通信產(chǎn)生的數(shù)據(jù)包數(shù)量和發(fā)送的字節(jié)數(shù)就更少了。
• 推送功能
  支持服務(wù)器主動向客戶端推送數(shù)據(jù)的功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請求。
• 服務(wù)器提示功能
  服務(wù)器可以主動提示客戶端請求所需的資源。由于在客戶端發(fā)現(xiàn)資源之前就可以獲知資源的存在，因此在資源已緩存等情況下，可以避免發(fā)送不必要的請求。

3、SPDY消除 Web 瓶頸了嗎

希望使用 SPDY 時(shí)，Web 的內(nèi)容端不必做什么特別改動，而 Web 瀏覽器及 Web 服務(wù)器都要為對應(yīng) SPDY 做出一定程度上的改動。有好幾家 Web 瀏覽器已經(jīng)針對 SPDY 做出了相應(yīng)的調(diào)整。另外，Web 服務(wù)器也進(jìn)行了實(shí)驗(yàn)性質(zhì)的應(yīng)用，但把該技術(shù)導(dǎo)入實(shí)際的 Web 網(wǎng)站卻進(jìn)展不佳。
因?yàn)?SPDY 基本上只是將單個(gè)域名（ IP 地址）的通信多路復(fù)用，所以當(dāng)一個(gè) Web 網(wǎng)站上使用多個(gè)域名下的資源，改善效果就會受到限制。
SPDY 的確是一種可有效消除 HTTP 瓶頸的技術(shù)，但很多 Web 網(wǎng)站存在的問題并非僅僅是由 HTTP 瓶頸所導(dǎo)致。對 Web 本身的速度提升，還應(yīng)該從其他可細(xì)致鉆研的地方入手，比如改善 Web 內(nèi)容的編寫方式等。

三、使用瀏覽器進(jìn)行全雙工通信的WebSocket

利用 Ajax 和 Comet 技術(shù)進(jìn)行通信可以提升 Web 的瀏覽速度。但問題在于通信若使用 HTTP 協(xié)議，就無法徹底解決瓶頸問題。WebSocket網(wǎng)絡(luò)技術(shù)正是為解決這些問題而實(shí)現(xiàn)的一套新協(xié)議及 API。
當(dāng)時(shí)籌劃將 WebSocket 作為 HTML5 標(biāo)準(zhǔn)的一部分，而現(xiàn)在它卻逐漸變成了獨(dú)立的協(xié)議標(biāo)準(zhǔn)。WebSocket 通信協(xié)議在 2011 年 12 月 11 日，被 RFC 6455 - The WebSocket Protocol 定為標(biāo)準(zhǔn)。

1、WebSocket 的設(shè)計(jì)與功能

WebSocket，即 Web 瀏覽器與 Web 服務(wù)器之間全雙工通信標(biāo)準(zhǔn)。其中，WebSocket 協(xié)議由 IETF 定為標(biāo)準(zhǔn)，WebSocket API 由 W3C 定為標(biāo)準(zhǔn)。仍在開發(fā)中的 WebSocket 技術(shù)主要是為了解決 Ajax 和 Comet里 XMLHttpRequest 附帶的缺陷所引起的問題。

2、WebSocket協(xié)議

一旦 Web 服務(wù)器與客戶端之間建立起 WebSocket 協(xié)議的通信連接，之后所有的通信都依靠這個(gè)專用協(xié)議進(jìn)行。通信過程中可互相發(fā)送JSON、XML、HTML或圖片等任意格式的數(shù)據(jù)。
由于是建立在 HTTP 基礎(chǔ)上的協(xié)議，因此連接的發(fā)起方仍是客戶端，而一旦確立 WebSocket 通信連接，不論服務(wù)器還是客戶端，任意一方都可直接向?qū)Ψ桨l(fā)送報(bào)文。
下面我們列舉一下 WebSocket 協(xié)議的主要特點(diǎn)。

• 推送功能
  支持由服務(wù)器向客戶端推送數(shù)據(jù)的推送功能。這樣，服務(wù)器可直接發(fā)送數(shù)據(jù)，而不必等待客戶端的請求。
• 減少通信量
  只要建立起 WebSocket 連接，就希望一直保持連接狀態(tài)。和 HTTP 相比，不但每次連接時(shí)的總開銷減少，而且由于 WebSocket 的首部信息
  很小，通信量也相應(yīng)減少了。

為了實(shí)現(xiàn) WebSocket 通信，在 HTTP 連接建立之后，需要完成一次“握手”（Handshaking）的步驟。

• • 握手·請求
    為了實(shí)現(xiàn) WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服務(wù)器通信協(xié)議發(fā)生改變，以達(dá)到握手的目的。
    
    Sec-WebSocket-Key 字段內(nèi)記錄著握手過程中必不可少的鍵值。Sec-WebSocket-Protocol 字段內(nèi)記錄使用的子協(xié)議。
    子協(xié)議按 WebSocket 協(xié)議標(biāo)準(zhǔn)在連接分開使用時(shí)，定義那些連接的名稱。
• • 握手·響應(yīng)
    對于之前的請求，返回狀態(tài)碼 101 Switching Protocols 的響應(yīng)。
    
    Sec-WebSocket-Accept 的字段值是由握手請求中的 SecWebSocket-Key 的字段值生成的。
    成功握手確立 WebSocket 連接之后，通信時(shí)不再使用 HTTP 的數(shù)據(jù)幀，而采用 WebSocket 獨(dú)立的數(shù)據(jù)幀。
    
• WebSocket API
  JavaScript 可調(diào)用“The WebSocket
  API”（http://www.w3.org/TR/websockets/，由 W3C 標(biāo)準(zhǔn)制定）內(nèi)提供的 WebSocket 程序接口，以實(shí)現(xiàn) WebSocket 協(xié)議下全雙工通信。
  以下為調(diào)用 WebSocket API，每 50ms 發(fā)送一次數(shù)據(jù)的實(shí)例。

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
setInterval(function() {
if (socket.bufferedAmount == 0)
socket.send(getUpdateData());
}, 50);
};

四、期盼已久的 HTTP/2.0

目前主流的 HTTP/1.1 標(biāo)準(zhǔn)，自 1999 年發(fā)布的 RFC2616 之后再未進(jìn)行過改訂。SPDY 和 WebSocket 等技術(shù)紛紛出現(xiàn)，很難斷言 HTTP/1.1仍是適用于當(dāng)下的 Web 的協(xié)議。
負(fù)責(zé)互聯(lián)網(wǎng)技術(shù)標(biāo)準(zhǔn)的 IETF（Internet Engineering Task Force，互聯(lián)網(wǎng)工程任務(wù)組）創(chuàng)立 httpbis（Hypertext Transfer Protocol Bis，http://datatracker.ietf.org/wg/httpbis/）工作組，其目標(biāo)是推進(jìn)下一代 HTTP——HTTP/2.0 在 2014 年 11 月實(shí)現(xiàn)標(biāo)準(zhǔn)化。

1、HTTP/2.0特點(diǎn)

HTTP/2.0 的目標(biāo)是改善用戶在使用 Web 時(shí)的速度體驗(yàn)。由于基本上都會先通過 HTTP/1.1 與 TCP 連接，現(xiàn)在我們以下面的這些協(xié)議為基礎(chǔ)，探討一下它們的實(shí)現(xiàn)方法。

• SPDY
• HTTP Speed ＋ Mobility
• Network-Friendly HTTP Upgrade

HTTP Speed ＋ Mobility 由微軟公司起草，是用于改善并提高移動端通信時(shí)的通信速度和性能的標(biāo)準(zhǔn)。它建立在 Google 公司提出的 SPDY與 WebSocket 的基礎(chǔ)之上。
Network-Friendly HTTP Upgrade 主要是在移動端通信時(shí)改善 HTTP 性能的標(biāo)準(zhǔn)。

2、HTTP/2.0 的 7 項(xiàng)技術(shù)及討論

HTTP/2.0 圍繞著主要的 7 項(xiàng)技術(shù)進(jìn)行討論，現(xiàn)階段（2012 年 8 月 13日），大都傾向于采用以下協(xié)議的技術(shù)。但是，討論仍在持續(xù)，所以不能排除會發(fā)生重大改變的可能性。

注：HTTP Speed ＋ Mobility 簡寫為 Speed ＋ Mobility，Network-Friendly HTTP Upgrade 簡寫為 Friendly。

五、Web 服務(wù)器管理文件的 WebDAV

WebDAV（Web-based Distributed Authoring and Versioning，基于萬維網(wǎng)的分布式創(chuàng)作和版本控制）是一個(gè)可對 Web 服務(wù)器上的內(nèi)容直接進(jìn)行文件復(fù)制、編輯等操作的分布式文件系統(tǒng)。它作為擴(kuò)展 HTTP/1.1的協(xié)議定義在 RFC4918。
除了創(chuàng)建、刪除文件等基本功能，它還具備文件創(chuàng)建者管理、文件編輯過程中禁止其他用戶內(nèi)容覆蓋的加鎖功能，以及對文件內(nèi)容修改的版本控制功能。

使用 HTTP/1.1 的 PUT 方法和 DELETE 方法，就可以對 Web 服務(wù)器上的文件進(jìn)行創(chuàng)建和刪除操作?？墒浅鲇诎踩约氨憬菪缘瓤紤]，一般不使用。

1、擴(kuò)展 HTTP/1.1 的 WebDAV

針對服務(wù)器上的資源，WebDAV 新增加了一些概念，如下所示。

• 集合（Collection）：是一種統(tǒng)一管理多個(gè)資源的概念。以集合為單位可進(jìn)行各種操作。也可實(shí)現(xiàn)類似集合的集合這樣的疊加。
• 資源（Resource）：把文件或集合稱為資源。
• 屬性（Property）：定義資源的屬性。定義以“名稱 = 值”的格式執(zhí)行。
• 鎖（Lock）：把文件設(shè)置成無法編輯狀態(tài)。多人同時(shí)編輯時(shí)，可防止在同一時(shí)間進(jìn)行內(nèi)容寫入。

2、WebDAV 內(nèi)新增的方法及狀態(tài)碼

WebDAV 為實(shí)現(xiàn)遠(yuǎn)程文件管理，向 HTTP/1.1 中追加了以下這些方法。

• PROPFIND ：獲取屬性
• PROPPATCH ：修改屬性
• MKCOL ：創(chuàng)建集合
• COPY ：復(fù)制資源及屬性
• MOVE ：移動資源
• LOCK ：資源加鎖
• UNLOCK ：資源解鎖

為配合擴(kuò)展的方法，狀態(tài)碼也隨之?dāng)U展。

• 102 Processing ：可正常處理請求，但目前是處理中狀態(tài)
• 207 Multi-Status ：存在多種狀態(tài)
• 422 Unprocessible Entity ：格式正確，內(nèi)容有誤
• 423 Locked ：資源已被加鎖
• 424 Failed Dependency ：處理與某請求關(guān)聯(lián)的請求失敗，因此不再維持依賴關(guān)系
• 507 Insufficient Storage ：保存空間不足
• • WebDAV 的請求實(shí)例
    下面是使用 PROPFIND 方法對http://www.example.com/file 發(fā)起獲取屬性的請求。

PROPFIND /file HTTP/1.1
Host: www.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: 219
<?xml version="1.0" encoding="utf-8" ?>
<D:propfind xmlns:D="DAV:">
<D:prop xmlns:R="http://ns.example.com/boxschema/">
<R:bigbox/>
<R:author/>
<R:DingALing/>
<R:Random/>
</D:prop>
</D:propfind>

• • WebDAV 的響應(yīng)實(shí)例
    下面是針對之前的 PROPFIND 方法，返回http://www.example.com/file 的屬性的響應(yīng)。

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"
Content-Length: 831
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response xmlns:R="http://ns.example.com/boxschema/">
<D:href>http://www.example.com/file</D:href>
<D:propstat>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Johnson</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the DingALing property.
</D:responsedescription>
</D:propstat>
</D:response>
<D:responsedescription> There has been an access violation error.
</D:responsedescription>
</D:multistatus>

為何 HTTP 協(xié)議受眾如此廣泛
本章講解了幾個(gè)與 HTTP 相關(guān)聯(lián)的協(xié)議使用案例。為什么 HTTP 協(xié)議受眾能夠如此廣泛呢？
過去，新編寫接入互聯(lián)網(wǎng)的系統(tǒng)或軟件時(shí)，還需要同時(shí)編寫實(shí)現(xiàn)與必要功能對應(yīng)的新協(xié)議。但最近，使用 HTTP 的系統(tǒng)和軟件占了絕大多數(shù)。
這有著諸多原因，其中與企業(yè)或組織的防火墻設(shè)定有著莫大的關(guān)系。防火墻的基本功能就是禁止非指定的協(xié)議和端口號的數(shù)據(jù)包通過。因此如果使用新協(xié)議或端口號則必須修改防火墻設(shè)置。
互聯(lián)網(wǎng)上，使用率最高的當(dāng)屬 Web。不管是否具備訪問 FTP 和SSH 的權(quán)限，一般公司都會開放對 Web 的訪問。Web 是基于 HTTP協(xié)議運(yùn)作的，因此在構(gòu)建 Web 服務(wù)器或訪問 Web 站點(diǎn)時(shí)，需事先設(shè)置防火墻 HTTP（80/tcp）和 HTTPS（443/tcp）的權(quán)限。
許多公司或組織已設(shè)定權(quán)限將 HTTP 作為通信環(huán)境，因此無須再修改防火墻的設(shè)定?？梢?HTTP 具有導(dǎo)入簡單這一大優(yōu)勢。而這也是基于 HTTP 服務(wù)或內(nèi)容不斷增加的原因之一。
還有一些其他原因，比如，作為 HTTP 客戶端的瀏覽器已相當(dāng)普遍，HTTP 服務(wù)器的數(shù)量已頗具規(guī)模，HTTP 本身就是優(yōu)異的應(yīng)用等