HTTP——學習筆記（8）

HTTP中的一些協議內容會限制某些網站的功能使用

好比，Facebook這類的社交網站，須要實時地觀察到海量用戶公開發布的內容，而HTTP中的如下標準就會成爲瓶頸：

一條鏈接上只可發送一個請求

請求只能從客戶端開始。客戶端不能夠接受除響應之外的指令

請求/響應首部未經壓縮就發送。首部信息越多延遲越大

發送冗長的首部。每次互相發送相同的首部形成的浪費較多

可任意選擇數據壓縮格式。非強制壓縮發送。

 

針對以上問題有幾種解決方法：

AJAX解決方法：

利用javascript和DOM達到局部web頁面替換加載的異步通訊手段，因爲只更新一部分頁面，響應中傳輸的數據量會所以而減小。

缺點：這種方法會致使大量請求發生，並且這個方法只是減小了數據的請求量，HTTP自己的問題並無解決

Comet解決方法：

服務器端接收到請求，會將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。

缺點：鏈接的持續時間變長，會消耗更多的資源，並且也沒有解決HTTP自己存在的問題

 

SPDY協議解決辦法：

在TCP/IP的應用層與運輸層之間經過新加會話層的形式運做。考慮到安全性，SPDY規定通訊中使用SSL。

SPDY以會話層的形式加入，控制對數據的流動，但仍是採用HTTP創建通訊鏈接。因此POST，GET方法仍是有效的

加入SPDY後新增功能：

　　多路複用流：全部請求的處理都在一條TCP鏈接上完成，所以TCP的處理效率獲得提升

　　賦予請求優先級：給請求分配優先等級，在發送請求時解決了因帶寬低而致使響應變慢的問題

　　壓縮HTTP首部：以前HTTP協議也能夠壓縮，可是在SPDY中強制壓縮了

　　推送功能：支持服務器主動向客戶端推送數據的功能，沒必要等待客戶端的請求

　　服務器提示功能：服務器能夠主動提示客戶端請求所需資源

 

WebSocket協議解決辦法：

web瀏覽器與web服務器之間全雙工通訊標準

特色:

支持服務器端和客戶端雙向通訊，服務器端不用等待客戶端的請求

一旦創建起WEBSOCKET鏈接就一直保持鏈接狀態，而且websocket的首部信息不多，減小了通訊量

在發送請求的首部字段中加入Upgrade字段，進行websocket的握手，以後雙方再也不使用HTTP的數據幀而使用websocket獨立的數據幀進行通訊

 

HTTP2.0中的解決辦法：

HTTP2.0中加入瞭如下技術以提升通訊時的速度和性能

SPDY

HTTP Speed + Mibility

Network-FriendlyHTTP Upgrade

後二者主要是針對移動端的通訊時的速度和性能