Http協議發展簡史以及常見面試題解析

作者：laker 2021-01-14 05:12:19

超文本傳輸協議(HTTP)是Internet上最普遍和廣泛采用的應用程序協議之一：它是客戶端和服務器之間的通用語言，可實現現代Web。

本文轉載自微信公眾號「Java大廠面試官」，作者laker 。轉載本文請聯系Java大廠面試官公眾號。

什么是HTTP協議
HTTP協議發展簡史
- HTTP 0.9 單行協議
- HTTP 1.0 構建擴展性
- HTTP 1.1 標準化協議
- HTTP 2.0 更高性能的協議
問題
1.http1.1長連接keep-alive和http2.0的多路復用有什么區別?
2.什么是流水線(管道機制)?
3.現代瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開?
4.一個 TCP 連接可以對應幾個 HTTP 請求?
5.一個 TCP 連接中 HTTP 請求發送可以一起發送么(比如一起發三個請求，再三個響應一起接收)?

什么是HTTP協議

超文本傳輸協議(HTTP)是Internet上最普遍和廣泛采用的應用程序協議之一：它是客戶端和服務器之間的通用語言，可實現現代Web。從簡單的一個關鍵字和文檔路徑開始，它不僅成為瀏覽器的選擇協議，而且幾乎成為所有與Internet連接的軟件和硬件應用程序的選擇協議。

HTTP具有四個版本:

HTTP / 0.9
HTTP / 1.0
HTTP / 1.1
HTTP / 2.0

時至今日，常用的版本是HTTP / 1.1，未來的發展版本是HTTP / 2.0。

HTTP協議發展簡史

HTTP 0.9 單行協議

HTTP協議的第一個簡單實現，僅支持獲取網頁。一開始都沒有版本號，為了區分其他版本，后來被稱為0.9。HTTP / 0.9非常簡單：請求由一行組成，并以唯一的方法GET開頭，后跟資源的路徑。

GET /mypage.html 
 
<HTML> 
A very simple HTML page 
</HTML>

從1991年開始，HTTP就有了自己的生命，并在接下來的幾年中迅速發展。

緣分吶❤️，我也是1991年破殼。

核心功能：

簡單的客戶端-服務器，請求-響應協議。
支持的方法：只有GET。
ASCII協議，通過TCP / IP鏈接運行。
設計用于傳輸超文本文檔(HTML)。
每次請求后，服務器和客戶端之間的連接都會關閉。
沒有HTTP標頭(無法傳輸其他內容類型文件)，沒有狀態/錯誤代碼，沒有URL，沒有版本控制

這個我表示我生活在現代，目前我所經歷的都沒碰到過。。。直接跳過，不研究👄

HTTP 1.0 構建擴展性

HTTP / 0.9協議非常有限，瀏覽器和服務器都迅速增加擴展性，使其變的更加通用。

1996年5月，HTTP工作組(HTTP-WG)發布了RFC 1945，此版本添加了許多補充數據字段，稱為規范的標頭。這允許其他信息在客戶端和服務器之間以及請求和后續頁面之間傳遞。

GET /mypage.html HTTP/1.0 
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1) 
 
200 OK 
Date: Tue, 15 Nov 1994 08:12:31 GMT 
Server: CERN/3.0 libwww/2.17 
Content-Type: text/html 
<HTML> 
A page with an image 
  <IMG SRC="/myimage.gif"> 
</HTML>

核心功能：

提供的標頭字段包括有關請求和響應的豐富元數據(HTTP版本號，狀態代碼，內容類型)
響應：不限于超文本(Content-Type標頭提供了傳輸普通HTML文件以外的文件的功能，例如腳本，樣式表，媒體)
支持的方法：GET，HEAD，POST
請求可能包含多個換行符分隔的標頭字段。
響應對象以響應狀態行為前綴。
響應對象具有自己的一組由換行符分隔的標頭字段。
每次請求后，服務器和客戶端之間的連接都會關閉。

nginx默認還是http1.0協議，剛好前幾天碰到個問題【1.0不支持分塊傳輸】，具體可參見：

nginx 下載文件 upstream sent invalid chunked response while reading upstream 錯誤

HTTP 1.1 標準化協議

HTTP / 1.1標準解決了早期版本中的許多協議歧義，并引入了許多關鍵的性能優化：

保持活動連接
分塊編碼傳輸
字節范圍請求
附加緩存機制
傳輸編碼
請求流水線(管道機制)

如今，大多數瀏覽器都支持1.0和1.1的實現，新瀏覽器默認使用1.1，但是如果有需要的話，還可以回退到早期版本。RFC定義明確指出的一件事是，HTTP協議的所有實現都應向后兼容。也就是說，實現HTTP /1.1規范的瀏覽器應該能夠從服務器接收1.0響應。相反，服務器端的1.1實現也應該能夠響應來自1.0瀏覽器的請求。

將HTTP轉變為正式的IETF Internet標準的工作與圍繞HTTP / 1.0的文檔編制工作并行進行，大約持續了四年時間：1995年至1999年。

實際上，第一個正式的HTTP / 1.1標準是在RFC 2068，于1997年1月正式發布，距HTTP / 1.0發布大約六個月。然后，兩年半之后的1999年6月，許多改進和更新被納入該標準，并以RFC 2616的形式發布。

GET /static/img/header-background.png HTTP/1.1 
Host: developer.cdn.mozilla.net 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0 
Accept: */* 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate, br 
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header 
 
200 OK 
Age: 9578461 
Cache-Control: public, max-age=315360000 
Connection: keep-alive 
Content-Length: 3077 
Content-Type: image/png 
Date: Thu, 31 Mar 2016 13:34:46 GMT 
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT 
Server: Apache 
 
(image content of 3077 bytes)

核心功能：

可以重用連接，從而節省了多次重新打開連接的時間。
添加了流水線，允許在完全傳輸第一個請求的答案之前發送第二個請求，從而降低了通信延遲。
現在也支持分塊編碼傳輸。
已經引入了其他緩存控制機制。
引入了內容協商，包括語言，編碼或類型，并使客戶端和服務器可以就最適當的內容達成共識。
現在可以在同一IP地址托管不同域的功能允許服務器托管。

HTTP / 1.1更改了HTTP協議的語義，默認情況下使用長連接。這意味著，除非另有說明(通過Connection: close標頭)，否則服務器應默認保持連接打開。

但是，此功能也已反向移植到HTTP / 1.0，并通過Connection: Keep-Alive標頭啟用。因此，如果您使用的是HTTP / 1.1，從技術上講，您不需要 Connection: Keep-Alive標頭，但是許多客戶端仍然選擇提供它。

自2005年以來，可用于網頁的API集大大增加，其中一些API創建了針對特定目的的HTTP協議擴展，主要是新的特定HTTP標頭：

服務器發送的事件，服務器可以將偶爾的消息推送到瀏覽器。
WebSocket，可以通過升級現有的HTTP連接來設置的新協議。

這里可以參考我之前寫的系統設計基礎長輪詢、WebSocket、服務器發送事件(SSEs)協議

HTTP / 1.0和HTTP / 1.1之間的短鏈接、長連接區別

在這里插入圖片描述

上圖右邊HTTP1.1通過建立長連接，中間的幾次 TCP握手都省掉了

HTTP管道傳輸和多個并行連接

由于Keep-Alive標頭的行為，HTTP流水線，多個連接和更多改進已得到實現。

在這里插入圖片描述

HTTP 2.0 更高性能的協議

多年以來，網頁變得更加復雜，甚至成為獨立的應用程序。顯示的視覺媒體數量，增加交互性的腳本的數量和大小也有所增加：通過明顯更多的HTTP請求傳輸更多的數據。HTTP / 1.1連接需要以正確的順序發送請求。從理論上講，可以使用幾個并行連接(通常在5到8之間)，從而帶來相當大的開銷和復雜性。例如，HTTP管道已成為Web開發中的一種資源負擔。

在2010年代上半年，Google通過實施實驗性協議SPDY展示了一種在客戶端和服務器之間交換數據的替代方法。這引起了同時使用瀏覽器和服務器的開發人員的興趣。SPDY定義了響應能力的提高，并解決了傳輸數據重復的問題，是HTTP / 2協議的基礎。

HTTP / 2協議與HTTP / 1.1版本有幾個主要區別：

它是二進制協議，而不是文本。不再可以手動讀取和創建它。盡管有這個障礙，現在仍可以實施改進的優化技術。
它是一個多路復用協議。可以在同一連接上處理并行請求，從而消除了HTTP / 1.x協議的順序和阻塞約束。
壓縮頭文件。由于這些請求在一組請求中通常很相似，因此消除了重復和傳輸數據的開銷。
它允許服務器通過稱為服務器推送的機制，在需要之前在客戶端緩存中填充數據。

請求和響應如何并行發生

上面的照片顯示了請求和響應如何并行發生。還顯示了如何將多個請求/響應拆分為單獨的幀，并以異步方式一一發送。

正式標準化后，在2015年5月，HTTP / 2取得了很大的成功。到2016年7月，所有網站有8.7%已在使用它，占所有請求68%以上。高流量的網站采用速度最快，大大節省了數據傳輸開銷和后續預算。

由于HTTP / 2不需要適應網站和應用程序，因此這種快速的采用率很可能是：使用HTTP / 1.1或HTTP / 2對它們是透明的。使用最新的服務器與最新的瀏覽器進行通信就足以啟用它：僅需要有限的一組組即可觸發采用，并且隨著舊版瀏覽器和服務器版本的更新，使用量自然增加了，而無需使用其他Web開發人員的努力。

Http2.0必須建立在TLS的基礎上，也就是必須是Https的請求。

問題

1.http1.1長連接keep-alive和http2.0的多路復用有什么區別?

http1.1 keep-alive 是不關閉 TCP 連接，也就是長連接;
- 在不使用管道機制的情況下，交互是單工的，即客戶端必須要等前一個請求的響應返回之后，新的請求才能發過去。
- 在使用管道機制的情況下，請求發送可以非阻塞，但是響應返回必須依然嚴格按照請求的順序。

http2.0多路復用則是基于流的，那么在傳輸的時候，無論請求還是響應，只要邏輯上允許就可以傳輸，如果兩個請求沒有依賴關系可以不必等待前一個返回而直接發送，雖說用的是同一條連接。

2.什么是流水線(管道機制)?

默認情況下，HTTP 請求是按順序發出的。下一個請求只有在當前請求收到應答過后才會被發出。由于會受到網絡延遲和帶寬的限制，在下一個請求被發送到服務器之前，可能需要等待很長時間。

流水線是在同一條長連接上發出連續的請求，而不用等待應答返回。這樣可以避免連接延遲。理論上講，性能還會因為兩個 HTTP 請求有可能被打包到一個 TCP 消息包中而得到提升。就算 HTTP 請求不斷的繼續，尺寸會增加，但設置 TCP 的 MSS(Maximum Segment Size) 選項，仍然足夠包含一系列簡單的請求。

并不是所有類型的 HTTP 請求都能用到流水線：只有 idempotent 方式，比如 GET、HEAD、PUT 和 DELETE 能夠被安全的重試：如果有故障發生時，流水線的內容要能被輕易的重試。

今天，所有遵循 HTTP/1.1 的代理和服務器都應該支持流水線，雖然實際情況中還是有很多限制：一個很重要的原因是，目前沒有瀏覽器默認啟用這個特性。

問題RFC 2616 中規定了：

一個支持持久連接的客戶端可以在一個連接中發送多個請求(不需要等待任意請求的響應)。收到請求的服務器必須按照請求收到的順序發送響應。

至于標準為什么這么設定，我們可以大概推測一個原因：由于 HTTP/1.1 是個文本協議，同時返回的內容也并不能區分對應于哪個發送的請求，所以順序必須維持一致。比如你向服務器發送了兩個請求 GET/query?q=A 和 GET/query?q=B，服務器返回了兩個結果，瀏覽器是沒有辦法根據響應結果來判斷響應對應于哪一個請求的。

Pipelining 這種設想看起來比較美好，但是在實踐中會出現許多問題：

一些代理服務器不能正確的處理 HTTP Pipelining。
正確的流水線實現是復雜的。
Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設客戶端在這個連接連續向服務器發送了幾個請求。按照標準，服務器應該按照收到請求的順序返回結果，假設服務器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結束才能響應。

所以現代瀏覽器默認是不開啟 HTTP Pipelining 的。

由于這些原因，流水線已經被更好的算法給代替，如multiplexing多路復用，已經用在 HTTP/2。

HTTP1.X鏈接管理

左邊短鏈接
中間長連接
右邊管道機制

在這里插入圖片描述

3.現代瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開?

其實看了上面的內容的話就知道答案了，現代瀏覽器默認是HTTP1.1協議，保持長連接是不會斷開的，那么我們來驗證下：Chrom瀏覽器F12,2次訪問一個網站的結果：第一次：

第二次：

結果分析：

初始化連接和 SSL 開銷消失了，說明使用的是同一個 TCP 連接

4.一個 TCP 連接可以對應幾個 HTTP 請求?

一個 TCP 連接是可以發送多個 HTTP 請求的。

從問題3的截圖就可以證明了。

5.一個 TCP 連接中 HTTP 請求發送可以一起發送么(比如一起發三個請求，再三個響應一起接收)?

HTTP/1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求，意思是說：兩個請求的生命周期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接里不能重疊。

雖然 HTTP/1.1 規范中規定了 Pipelining 來試圖解決這個問題，但是這個功能在瀏覽器中默認是關閉的。原因的話問題2已經闡述過了，

HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求。

參考：

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

http://qnimate.com/what-is-multiplexing-in-http2/

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Connection_management_in_HTTP_1.x

https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0

https://blog.csdn.net/ywlmsm1224811/article/details/96436768

責任編輯：武曉燕來源： Java大廠面試官

Http 協議面試