读《图解HTTP》总结--第九章
基于HTTP的功能追加協議
????雖然HTTP協議即簡單又簡捷,但隨著時代的發展,其功能使用上捉襟見肘的疲態已經凸顯。本篇主要講解基于HTTP新增的功能的協議。
9.1 ?基于HTTP的協議
????在建立HTTP標準規范時,制定者主要想把HTTP當作傳輸HTML文檔的協議。隨著時代的發展,Web的用途更具多樣性,比如演化成在線購物、SNS、企業或者組織內部的各種管理工具。等等。而這些網站所追求的功能可通過Web應用和腳本程序實現。及時這些功能已經滿足需求,在性能上卻未必最優,這是因為HTTP協議上的限制以及自身能有限。HTTP功能上的不足可通過創建一套全新的協議來彌補。可是目前基于HTTP的Web瀏覽器的使用環境已遍布全球,因此無法完全拋棄HTTP。有一些新協議的規則是基于HTTP的,并在此基礎上添加了新功能。
9.2 ?消除HTTP瓶頸的SPDY
????Google在2010年發布了SPDY(取自SPeeDy),其開發目標旨在解決HTTP的性能瓶頸,縮短Web頁面的加載時間(50%).SPDY - The Chromium Projects.http://www.chromiunm.org/spdy/
9.2.1 HTTP的瓶頸
????在Facebook和Twitter等SNS網站上,幾乎能夠實時觀察到海量用戶公開發布的內容,這也是一種樂趣。當幾百、幾千萬的用戶發布內容時,Web網站為了保存這些新增的內容,在很短的時間內就會發生大量的內容更新。為了盡可能實時地顯示這些更新的內容,服務器上一有內容更新,就需要直接把那些內容反饋到客戶端的界面上。雖然看起來挺簡單的,但HTTP卻無法妥善地處理好這項任務。使用HTTP協議探知服務器上是否有內容更新,就必須頻繁地從客戶端到服務器端進行確認。如果服務器上沒有內容更新,那么就會產生徒勞的通信。若想在現有Web實現所需的功能.以下這些HTTP標準就會成為瓶頸：
????·一條連接上只可發送一個請求。
????·請求只能從客戶端開始,客戶端不可以接收除響應以外的指令。
????·請求/響應首部未經壓縮就發送。首部信息越多延遲越大
????·發送冗長的首部,每次互相發送相同的首部造成的浪費較多
????·可任意選擇數據壓縮格式。非強制壓縮發送。
Ajax的解決方法
????Ajax(Asynchronous JavaScript and XML,異步JavaScript與XML技術)是一種有效利用JavaScript和DOM(Document Object Model,文檔對象模型)的操作,以達到局部Web頁面替換加載的異步通信手段。和以前的同步通信相比,由于它只更新一部分頁面,響應中傳輸的數據了會因此而減少,這一點優點顯而易見。Ajax的核心技術是名為XMLHttpRequest的API,通過JavaScript腳本語言的調用就能和服務器進行HTTP通信。借由這種手段,就能從而加載完畢的Web頁面上發起請求,只更新局部頁面。而利用Ajax實現地從服務器獲取內容,有可能會導致大量請求產生。另外Ajax仍未解決HTTP協議本身存在的問題。
Comet的解決方法
????一旦服務器端內容有更新了,Comet不會讓請求等待,而是直接給客戶端返回響應。這是一種通過延遲應答,模擬實現服務器向客戶端推送(Server Push )的功能。通常,服務器端接收到請求,在處理完畢后就會立即返回響應,但為了實現推送功能,Comet會先將響應置于掛起狀態,當服務器端內有內容更新時,再返回該響應。因此,服務器端一旦有更新,就可以立即反饋給客戶端。
????內容上雖然可以做到實時更新,但為了保留響應,一次連接的持續時間也變長了。期間,為了維持連接會消耗更多的資源。另外,Comet也仍未解決HTTP協議本身存在的問題。
SPDY的目標
????陸續出現的Ajax和Comet等提高易用性的技術,一定程度上使HTTP得到了改善,但HTTP協議本身的限制也令人有些束手無策。為了進行根本性的改善,需要有一些協議層面上的改動。處理持續開發狀態中的SPDY協議,正是為了在協議級別消除HTTP所遭遇的瓶頸。
9.2.2 SPDY的設計與功能
????SPDY沒有完全改寫HTTP協議,而是在TCP/IP的應用層與運輸層之間通過新加會話層的形式運作,同時,考慮到安全性問題,SPDY規定通信中使用SSL。SPDY以會話層的形式加入,控制對數據的流動,但還是采用HTTP建立通信連接。因此,可照常使用HTTP的GET和POST等方法,Cookie以及HTTP報文等。
????使用SPDY后,HTTP協議額外獲得以下功能。
????·多路復用流
????通過單一的TCP連接,可以無限制處理多個HTTP請求。所有請求的處理都在一條TCP連接上完成,因此TCP的處理效率得到提高。
????·賦予請求優先級
????SPDY不僅可以無限制地并發處理請求,還可以請求逐個分配優先順序。這樣主要是為了在發送多個請求時,解決因帶寬低而導致響應變慢的問題。
????·壓縮HTTP首部
????壓縮HTTP請求和響應的首部。這樣一來,通信產生的數據包流量和發送的字節數就更少了。
????·推送功能
????支持服務器主動向客戶端推送數據功能。這樣,服務器可直接發送數據,而不必等待客戶端的請求。
????·服務器提示功能
????服務器可以主動提示客戶端請求所需的資源。由于在客戶端發現資源之前就可以獲知資源的存在，因此在資源已緩存等情況下,可以避免發送不必要的請求。
9.2.3 SPDY消除Web瓶頸了嗎
????希望使用SPDY時,Web內容端不必做什么特別改動,而Web瀏覽器及Web服務器都要為對應SPDY做出一定程度上的改動。有好幾家Web瀏覽器已經針對SPDY做出了響應的調整。另外,Web服務器也進行了實驗性質的應用。但把該技術導入實際Web網站卻進展不佳。因為當SPDY基本上只是將單個域名(IP地址)的通信多路復用,所以當一個Web網站上使用多個域名下的資源,改善效果就會受到限制。SPDY的確是一種可有效消除HTTP瓶頸的技術,但很多Web網站存在的問題并非僅僅由HTTP瓶頸所導致。對Web網站本身的速度提升,還應該從其他可細致鉆研的地方入手,比如改善Web內容的編寫方式等。
9.3 ?使用瀏覽器進行全雙工通信的WebSocket
????利用Ajax和Comet技術進行通信可以提升Web的瀏覽速度。但問題在于通信若使用HTTP協議,就無法徹底解決瓶頸問題。WebSocket網絡技術正是為解決這些問題而實現的一套新協議及API。當時籌劃將WebSocket作為HTML5標準的一部分,而現在他卻逐漸變成了獨立的協議標準。WebSocket通信協議在2011年12月11日,被RFC-6455-The WebSocket Protocol定為標準。
9.3.1 WebSocket的設計與功能
????Websocket,即Web瀏覽器與Web服務器之間全雙工通信標準。其中,WebSocket協議由IETF定為標準,WebSocket API由W3C定為標準。仍在開發中的WebSocket技術是為了解決Ajax和Comet里XMLHttpRequest附帶的缺陷所引起的問題。
9.3.2 ?WebSocket 協議
????一旦Web服務器與客戶端之間建立起WebSocket協議的通信連接,之后所有的通信都依靠這個專用協議進行。通信過程中可互相發送JSON、XML、HTML或圖片等任意格式的數據。由于是建立在HTTP基礎上的協議,因此連接的 發起方仍是客戶端,而一旦確立WebSocket通信連接,不論服務器還是客戶端,任意一方都可直接向對方發送報文。WebSocket協議的主要特點如下：
????·推送功能
???? 支持由服務器向客戶端推送數據的推送請求功能。這樣,服務器可直接發送數據,而不必等待客戶端的請求。
????·減少通信量
????只要建立起WebSocket連接,就希望一直保持連接狀態。和HTTP相比,不但每次連接時的總開銷減少,而且由于WebSocket的首部信息很小,通信量也相應減少。為了實現WebSocket通信,在HTTP連接建立后,需要完成一次"握手(HandShaking)"的步驟
握手·請求
????為了實現WebSocket通信,需要用到HTTP的Upgrade首部字段,告知服務器通信協議發生改變,以達到握手的目的。Sec-WebSocket-Key字段內記錄著握手記錄過程中必不可少的鍵值，Sec-WebSocket-Protocol字段內記錄使用的子協議。子協議按WebSocket協議標準在連接分開使用時,定義那些連接的名稱。
握手·響應
????對于之前的請求,返回狀態碼101 Switching Protocol的響應。Sec-WebSocket-Accept的字段值是由握手請求中的Sec-WebSocket-Key的字段值生成的,成功握手確立WebSocket連接之后,通信時不在使用HTTP的數據幀,而采用WebSocket獨立的數據幀。
WebSocket ?API?
????JavaScript可調用"The WebSocket API"(http://www.w3.org/TR/websocket/,由W3C標準制訂)內提供的WebSocket程序接口,以實現WebSocket協議下全雙工通信。以下為調用WebSocket?API，每50ms發送一次數據的實例?。
9.4 ?期盼已久的HTTP/2.0
????目前主流的HTTP/1.1標準,自1999年發布的RFC2616之后在未進行過改訂。SPDY和WebSocket登技術紛紛出現,很難斷言HTTP/1.1仍是適用于當下的Web協議。負責互聯網技術的IETF(Internet Engineering Task Force，互聯網工程任務組)創立httpbis工作組,其目標是推進下一代HTTP-----HTTP/2.0在2014年11月實現標準化。
HTTP/2.0的特點
????HTTP/2.0的目標是改善用戶在使用Web時的速度體驗。由于基本上都會先通過HTTP/1.1與TCP連接,現在我們以下面的這些協議為基礎,探討一下他們的實現方法。
????·SPDY
????·HTTP Speed +Mobility
????·Network-Friendly HTTP Upgrade
????HTTP Speed+ Mobility由微軟公司起草,是用于改善并提高移動端通信時的通信速度和性能標準。它建立在Google公司提出的SPDY與WebSocket的基礎之上。
????Network-Friendly HTTP Upgrade主要在移動端通信時改善HTTP性能的標準。
HTTP/2.0的7項技術及討論
????HTTP圍繞著主要的7項技術進行討論,現階段(2012年8月13日)，大都傾向于采用以下協議的技術。但是,討論仍在持續,所以不能排除會發生重大改變的可能性。
表9-1 ：
| 壓縮 | SPDY 、Friendly |
| 多路復用 | SPDY |
| TLS義務化 | Speed +Mobility |
| 協商 | Speed +Mobility , Friendly |
| 客戶端拉拽(Client Pull)/服務器推送(Server push ) | Speed +Mobility |
| 流量控制 | SPDY |
| WebSocket | Speed +Mobility |
9.5 ?Web服務器管理文件的WebDAV
????WebDAV(Web-based Distributed Authoring and Versioning，基于萬維網的分布式創作和版本控制)是一個可對Web服務器上的內容直接進行文件復制、編輯等操作的分布式文件系統。它作為擴展HTTP/1.1的協議定義在RFC4918.除了創建、刪除文件等基本功能,他還具備文件創建管理者管理、文件編輯過程中禁止其他用戶內容覆蓋的加鎖功能,以及對文件內容修改的版本控制功能。使用HTTP/1.1的PUT方法和DELETE方法,就可以對Web服務器上的文件進行創建和刪除操作。可是出于安全性及便捷性等考慮,一般不使用。
9.5.1 擴展HTTP/1.1的WebDAV
????針對服務器上的資源,WebDAV新增加了一些概念。如下圖
????集合(Collection)：是一種統一管理多個資源的概念。以集合為單位進行各種操作。也可實現類似集合的集合這樣的疊加。
????資源(Resource)：把文件或集合稱為資源。
????屬性(Property):定義資源的屬性。定義以"名稱=值"的格式執行
????鎖(Lock) :把文件設置成無法編輯狀態。多人同時編輯時,可防止在同一時間進行內容寫入。
9.5.2 WebDAV內新增的方法及狀態碼
????WebDAV為實現遠程文件管理,向HTTP/1.1中追加了以下這些方法以及擴展了狀態碼。
表9-2 追加的方法：
| PROPFIND | 獲取屬性 |
| PROOPPATCH | 修改屬性 |
| MKDOL | 創建集合 |
| MOVE | 移動資源 |
| LOCK | 資源加鎖 |
| UNLOCK | 資源解鎖 |
表9-3 擴展的狀態碼
| 102 Processing | 可正常處理請求,但目前處理中狀態 |
| 207 Multi-Status | 存在多種狀態 |
| 422 Unprocessible Entity | 格式正確,內容有誤 |
| 423 ?Locked | 資源已被加鎖 |
| 424 Failed Dependency | 處理與某請求關聯的請求失敗,因此不再維持依賴關系 |
| 507 Insufficient Storage | 保存空間不足 |
WebDAV 的請求實例(下面是使用PROPFIND方法對http://www.example.com/file發起獲取屬性的請求)
WebDAV 的響應實例(下面是針對之前PROPFIND方法的響應)
PS:為何HTTP協議受眾如此廣泛
????本篇講解了幾個與HTTP相關聯的協議使用案例。為什么HTTP協議受眾能夠如此廣泛？過去,新編寫接入互聯網的系統或軟件時,還需要同時編寫實現與必要功能對應的新協議。但最近,使用HTTP的系統和軟件占了絕大多數。這有著諸多的原因,其中與企業或組織的防火墻設定有著莫大的關系。防火墻的基本功能就是禁止非指定的協議和端口號的數據包通過，因此如果使用新協議或端口號則必須修改防火墻設置。
????互聯網上,使用率最高的當屬Web。不管是否具備訪問FTP和SSH的權限,一般公司都會開放對Web的訪問。Web是基于HTTP協議運作的,因此在構建Web服務器或訪問Web站點是。需要事先設置防火墻HTTP(80/tcp)和HTTPS(443/tcp)的權限。許多公司或組織已設定權限將HTTP作為通信環境,因此無須再修改防火墻的設定。可見HTTP具有導入簡單這一大優勢。而這也是基于HTTP服務或內容不斷增加的原因之一。還有一些其它原因,比如，作為HTTP客戶端的瀏覽器已相當普遍,HTTP服務器的數量已頗具規模,HTTP本身就是優異的應用等。
轉載于:https://blog.51cto.com/top99/1869052
總結
以上是生活随笔為你收集整理的读《图解HTTP》总结--第九章的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【风马一族_php】NO4_php基础知
- 下一篇： 腾讯云大数据套件Hermes-MR索引插