【讀書筆記】圖解 HTTP Chapter 09 基於 HTTP 的功能追加協議

當初在制定 HTTP 協議,主要是希望把 HTTP 當作傳輸 HTML 文件的協議,但根據時代演變,網站的用途越來越多樣,像是購物網站、SNS 等(社交網路服務 Social Networking Service),HTTP 協議即使已經滿足需求,但加上本身協議的限制和自身效能的限制,就效能來看不一定是最好的。

因為現在網路瀏覽器的使用已經佈及全世界,已經完全沒辦法離開 HTTP,因此在其他功能上的不足,會需要建立全新的協議來彌補。

基於 HTTP 協議

當初在制定 HTTP 協議,主要是希望把 HTTP 當作傳輸 HTML 文件的協議,但根據時代演變,網站的用途越來越多樣,像是購物網站、SNS 等(社交網路服務 Social Networking Service),HTTP 協議即使已經滿足需求,但加上本身協議的限制和自身效能的限制,就效能來看不一定是最好的。

因為現在網路瀏覽器的使用已經佈及全世界,已經完全沒辦法離開 HTTP,因此在其他功能上的不足,會需要建立全新的協議來彌補。

消除 HTTP 瓶頸的 SPDY

Google 在 2010 年發佈了 SPDY,開發宗旨是要解決 HTTP 的效能瓶頸,縮短頁面的載入時間。

http://www.chromium.org/spdy/

HTTP 的瓶頸

在 SNS 網站上,可以看到海量的用戶所發佈的內容,這使網站需要短時間的大量更新內容,為了盡量顯示內容,伺服器內容有更新就馬上回靠到客戶端的頁面上,但這項任務對於 HTTP 來說卻相當困難,因為需要頻繁地從客戶端到伺服端進行確認,如果伺服器上的內容沒更新,就會有多餘的傳輸動作。

希望網站實現所需要的功能,HTTP 目前遇到下面的瓶頸:

  • 一條連接只能發送一個請求
  • 請求只能從客戶端開始,客戶端不能接收除了響應以外的指令
  • 請求 / 響應首部未經壓縮就發送,首部訊息越多延遲越大
  • 發送冗長的首部,每次互相發送相同首部造成的浪費較多。

AJAX 解決方法

AJAX 是一種利用 JavaScript 和 DOM 的做,已達到局部網站頁面替換的非同步手段,和以前同步通訊相比,由於他只更新頁面的一部份,響應傳輸量會因此減少。

AJAX 的核心技術是 XMLHttpRequest 的 API ,透過 JavaScript 的呼叫就可以讓伺服器進行 HTTP 通訊,利用 AJAX 從伺服器取得內容,有可能導致大量請求產生,還是沒辦法解決 HTTP 根本的問題。

Comet 解決方法

只要伺服器有更新,Comet 不會讓請求等待,而是直接給客戶端響應,這是透過一個延遲應答,模擬伺服器向客戶端推播的功能。

伺服器收到請求,處理完就會馬上回傳響應,但為了實現推播的功能,Comet 會掛起一個連結,當伺服器更新的時候再回傳響應,因此在伺服端有更新就可以立即回傳給客戶端。

在內容上雖然可以做到實際的更新,但為了保留響應,一次連續時間也變成,過程中消耗的效能也更多,所以 Comet 也沒有解決 HTTP 協議存在的問題。

SPDY 的設計與功能

處於持續開發狀態中的 SPDY 協議,就是為了消除 HTTP 所遭遇的瓶頸。

SPDY 沒有改寫 HTTP 協議,而是在 TCP/IP 的應用層與傳輸層之間通過新加會一層形式,同時考慮到安全性,SPDY 規定在通訊中必須使用 SSL。SPDY 以會議層的形式加入,控制對資料的流動,但還是採用了 HTTP 建立通訊的連接,可照常使用 HTTP 的方法等。

使用 SPDY 可以獲得以下功能:

  • 多路復用流
    透過單一 TCP 連接,可以無限制處理多個 HTTP 請求,所有請求都在一條 TCP 完成,效率因此提高。
  • 賦予請求優先順序
    SPDY 不僅無限制地處理請求,還能分配優先順序,因此解決了頻寬導致的響應變慢的問題。
  • 壓縮 HTTP 首部
    壓縮 HTTP 首部,讓封包數量和字串數變少。
  • 推播功能
    支援伺服器向客戶端推波資料,因此伺服器可發送資料,也不需要等客戶端的請求。
  • 伺服器提示服務
    伺服器可以主動提示客戶端所需要的資料,因此客戶端發現資料之前就可以知道其存在,因此在緩存的狀況下可以避免發送不需要的請求。

SPDY 消除 Web 的瓶頸了嗎

希望使用 SPDY 時,希望網站的內容不要做特別的變動,而網站的瀏覽器和伺服器都要為對應的 SPDY 做一定程度的變動,有很多瀏覽器廠商針對 SPDY 做了相對應的調整,但進展不太好。

因為 SPDY 只是將單個域名(IP 位置)的通訊多路復用,所以當一個網站使用多個域名資料的狀況下,改善效果就會被受到限制。

SPDY 確實可以消除 HTTP 的瓶頸,但很多網站的問題不僅僅是因為 HTTP 的瓶頸所導致的,對網站效能的提升應該從其他可鑽研的地方下手。

使用瀏覽器進行全雙工的 WebSocket

利用 AJAX 和 Comet 的通訊技術可以提升網站的瀏覽速度,但如果使用 HTTP 協議就無法徹底解決問題,而 WebSocket 就是為了解決這些問題而實現的新協議及 API。

WebSocket 的設計與功能

WebSocket 就是網站瀏覽器和伺服器之間的全雙工通訊標準。當中 WebSocket 協議由 IETF 所提供,由 W3C 訂定標準,仍在開發中的 WebSocket 技術主要為了解決 AJAX 和 Comet 之中 XMLHttpRequest 附帶的缺陷所引起的問題。

WebSocket 協議

一旦伺服器和客戶端之間建立起 WebSocket 協議的通訊,之後的通訊都是靠這個協議在進行,通訊過程可以發送任何格式的資料。由於是建立在 HTTP 基礎上的協議,因此發起端還是客戶端,只要 WebSocket 連接到了,無論伺服器還是客戶端,任何一方都可以直接向對方發起 HTTP 報文。

主要特點:

  • 推播功能:
    支援由伺服器對客服端推送資料的推播功能,這樣伺服端就可以直接發送資料,而不用等客戶端的請求。

  • 減少通訊量
    只要建立連接後,就會希望持續下去,和 HTTP 比,不但每次連接的消耗變小,而且因為 WebSocket 的首部訊息很少,通訊量也相對變小了。

    為了做 WebSocket 通訊,在 HTTP 連結建立之後,還需要完成一次握手(Handshaking)的步驟。

    • 握手。請求:為了實現 WebSocket 通訊,需要 HTTP 的 Upgrade 首部字串,告訴伺服器產生改變,已達到握手的目的。

      • Sec-WebSocket-Key字串裡紀錄握手過程必須的鍵值。
      • Sec-WebSocket-Protocol 記錄使用的子協議。子協議按 WebSocket 協議標準在連結分開時使用,定義那些連接的名稱。
    • 握手。響應:對於之前的請求,返回狀態碼 101 的響應。

      • Sec-WebSocket-Accept 的字串是由請求中的Sec-WebSocket-Key的字串產生。

        成功建立 WebSocket 連接後,通訊就不再使用 http 資料幀。

    • WebSocket API:JavaScript 可呼叫「The WebSocket API」來實現 WebSocket 協議下的全雙工通訊。

期盼已久的 HTTP/2.0

  • http 2.0 的特點:http 2.0 的目標是改善用戶在網站上的使用速度體驗。
    • SPDY
    • HTTPSpeed + Mobility(Speed + Mobility):微軟公司發起,用於提升移動裝置的通訊速度和性能,他建立在 SPDY 與 WebSocket 的基礎。
    • Network-Friendly HTTP Upgrade(Friendly):主要是改善 HTTP 效能的標準。
  • HTTP/2.0 的七項紀錄與討論
    • 壓縮:SPDY、Friendly
    • 多路復用:SPDY
    • TLS 義務化:Speed + Mobility
    • 協商:Speed + Mobility, Friendly
    • 客戶端拉曳、伺服端推播:Speed + Mobility
    • 流量控制:SPDY
    • WebSocket:Speed + Mobility

Web 伺服器管理文件的 WebDAV

WebDAV 是一個可對伺服器上的內容進行文件的複製、編輯等操作的分布式文件系統,除了新增、刪除文件等基本功能,還對文件建立者管理、文件編輯過程中禁止其他用戶內容覆蓋的加鎖功能,以及對文件內容修改的版本控制功能。

使用 http/1.1 的 put 和 delete 方法,就對伺服器上的文件進行新增和刪除,但基於安全和便利性,一般不使用。

擴展 http/1.1 的 WebDAV

  • 集合:是一種統一管理資源的概念
  • 資源:把文件或集合稱為資源
  • 屬性:定義資源的屬性
  • 鎖:把文件設置為無狀態,多人編輯可以防止同一時間寫入。

WebDAV 內新增的方法及狀態碼

為了實踐遠端文件管理,在 http 1.1 中也新增了以下這些方法:

  • PROPFIND:獲取屬性。
  • PROPPATCH:修改屬性。
  • MKCOL:建立集合。
  • COPY:複製資源及屬性。
  • MOVE:移動資源。
  • LOCK:資源加鎖。
  • UNLOCK:資源解鎖。

為了配合拓展,狀態碼也隨之新增:

  • 102:可正常處理請求,但處理中。
  • 207:存在多種狀態。
  • 422:格式正確,內容有誤。
  • 423:資源已被加鎖。
  • 424:處理與請求關聯的請求失敗,因此不再維持依賴關係。
  • 507:保存空間不足。

為什麼不一直用 HTTPS 就好?其實只要與個人資訊相關等敏感資料再做加密通訊就好,除了上述缺點外,節約開銷也是重點。
資料來源:《圖解 HTTP》 上野宣 人民郵電出版社
筆記純屬推廣及分享,如有侵權,請告知。
Please advise to remove immediately if any infringement caused.

【讀書筆記】JavaScript Design Pattern Chapter01 介紹 【讀書筆記】圖解 HTTP Chapter 08 確認訪問用戶身份認證

評論

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×