石頭人面試HTTP之http協議2.0/SPDY

前言

小夥伴們在面試過程當中會遇到一些HTTP/網絡TCP/IP相關問題

我大概收集整理了下

1. http1.1時如何複用Tcp鏈接
2. 經過什麼作到併發請求
3. 介紹Http2.0
4. 一個 TCP 鏈接能夠對應幾個 HTTP 請求

這些問題咱們均可以在如下文章中找到答案

http存在問題

1. 無狀態協議

   解決：cookie

2. 每次請求，從新鏈接，增長開銷

   解決：keep-alive

3. 一條鏈接只能發一個請求

   解決：管線化

4. 請求只能從客戶端開始

   解決：SPDY/comet/websocket

5. 請求/響應首部未壓縮 解決：SPDY

SPDY

爲了提升http性能 SPDY以會話層形式加入 HTTP —> SPDY(會話層) -> SSL -> TCP ... 實現如下功能

1. 多路複用（一個TCP連接能夠處理多個http請求）
2. 請求賦予優先級
3. 壓縮http首部
4. 服務端推送 （可主動給客戶端推送數據）
5. 服務端提示 （可提示客戶端請求資源）

keep-alive（持久化連接）

利用 tcp 握手揮手 任意一端沒有提出斷開，則保持鏈接狀態 一個TCP連接能夠處理多個http請求

管線化（請求併發)

依賴持久化連接 管線化技術 可實現併發請求

多個HTTP請求發送能夠一塊兒發送

cookie（狀態管理）

根據 從 服務器端發送的響應報文 set-cookie 首部字段信息，通知客戶端保存 cookie 客戶端再次請求時，自動在請求報文中加入cookie發出

comet

服務器端有更新，不會等待請求，而是直接返回響應，延遲應答模式

客戶端請求，服務端響應掛起，有內容更新時返回，

缺點：爲了保留響應，一次鏈接時間變長，消耗資源

websocket

服務端和客戶端創建通訊鏈接，以後可互相發送數據

本文重點不在websocket，不會詳細講解

http2.0

改善用戶使用web速度體驗,基於 SPDY 設計

http1.1 存在問題

1. 隊頭堵塞

http1.1即使是經過管道同時發送了多個請求，服務端也是按請求的順序依次給出響應的；而客戶端在未收到以前所發出全部請求的響應以前，將會阻塞後面的請求(排隊等待)，這稱爲"隊頭堵塞"

解決 ： 多路複用

多路複用

http2.0雖然依然遵循請求-響應模式，但客戶端發送多個請求和服務端給出多個響應的順序不受限制，這樣既避免了"隊頭堵塞"，又能更快獲取響應。在複用同一個TCP鏈接時，服務器同時(或前後)收到了A、B兩個請求，先回應A請求，但因爲處理過程很是耗時，因而就發送A請求已經處理好的部分， 接着迴應B請求，完成後，再發送A請求剩下的部分

二進制格式

HTTP1.x 採用文本格式

HTTP2.0 採用二進制格式

方便且健壯

header 壓縮

基於 SPDY

服務端推送

基於 SPDY

負載均衡優化HTTP

TCP鏈接複用

TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端TCP鏈接上：

主要利用負載均衡 技術，

1. 客戶端請求，
2. 負載均衡設備收到請求後，檢測服務器是否存在空閒長連接，不存在則服務器創建新連接，
3. http響應完成後，負載均衡設備和客戶端之間關閉連接，但和服務器保持連接，
4. 其餘客戶端發送http請求時，可直接使用這個空閒連接，避免新建tcp連接

下一章

石頭人面試HTTP之請求&響應&緩存