在本文中，我們將深入探討萬維網(wǎng)數(shù)據(jù)通信的基礎(chǔ) - HTTP。

什么是超文本？

HTTP（超文本傳輸協(xié)議）的命名源于“超文本”。

那么，什么是超文本？

想象一下由超鏈接組成的文本、圖像和視頻的混合物。這些鏈接充當(dāng)我們從一個(gè)超文本集合跳轉(zhuǎn)到另一個(gè)集合的門戶。HTML（超文本標(biāo)記語言）就是超文本的一個(gè)典型示例。

HTML是一個(gè)純文本文件。它包含許多標(biāo)簽，這些標(biāo)簽定義了到圖像、視頻等的鏈接。瀏覽器解釋這些標(biāo)簽后，將看似普通的文本文件轉(zhuǎn)換為充滿文本和圖像的網(wǎng)頁。

HTTP/1.1、HTTP/2和HTTP/3

自從1989年誕生HTTP 0.9以來，HTTP經(jīng)歷了重大變革。讓我們回顧一下每個(gè)HTTP版本解決的問題。下圖展示了關(guān)鍵的改進(jìn)。

?HTTP/1.0在1996年最終定稿并正式記錄下來。該版本有一個(gè)重要限制：對同一服務(wù)器的每個(gè)請求都需要單獨(dú)的TCP連接。?HTTP/1.1在1997年推出。它引入了“持久連接”的概念，意味著可以保持TCP連接以進(jìn)行重用。盡管有這一改進(jìn)，HTTP/1.1無法解決“HOL（Head-of-Line）阻塞”問題。簡而言之，當(dāng)瀏覽器的所有并行請求槽都被占滿時(shí)，后續(xù)請求必須等待前面的請求完成，這就是HOL阻塞。?HTTP/2.0于2015年發(fā)布，旨在解決HOL阻塞問題。它實(shí)現(xiàn)了“請求多路復(fù)用”（request multiplexing）的策略，以消除應(yīng)用層的HOL阻塞。如下圖所示，HTTP/2.0引入了HTTP“流”的概念。這種抽象允許將不同的HTTP交換復(fù)用到同一TCP連接中，無需按順序發(fā)送每個(gè)流。但是，HOL阻塞仍可能發(fā)生在傳輸（TCP）層。?HTTP/3.0于2020年發(fā)布了一份草案，作為HTTP/2.0的繼任者，它將TCP替換為QUIC作為底層傳輸協(xié)議。這有效地消除了傳輸層的HOL阻塞。QUIC基于UDP。它在傳輸層引入了流作為一級(jí)公民。QUIC流共享相同的QUIC連接，無需額外的握手或慢啟動(dòng)來創(chuàng)建新的流。QUIC流可以獨(dú)立傳輸。這意味著在大多數(shù)情況下，一個(gè)流中的數(shù)據(jù)包丟失不會(huì)影響其他流。

HTTP頭部

HTTP頭部在客戶端和服務(wù)器之間發(fā)送和接收數(shù)據(jù)時(shí)起著關(guān)鍵作用。它們?yōu)檫@些實(shí)體提供了一種結(jié)構(gòu)化的方式來傳遞有關(guān)請求或響應(yīng)的重要元數(shù)據(jù)。這些元數(shù)據(jù)可以包含各種信息，例如發(fā)送的數(shù)據(jù)類型、長度、壓縮方式等。

HTTP頭部由多個(gè)字段組成，每個(gè)字段具有特定的作用和含義?，F(xiàn)在我們對HTTP頭部有了一定的了解，讓我們深入探討一些特定的HTTP字段。

HTTP字段

當(dāng)我們向服務(wù)器發(fā)送HTTP請求時(shí)，有一些常見的字段起著至關(guān)重要的作用。讓我們逐個(gè)剖析一些字段。

?Host：這是服務(wù)器的域名。?Content-Length：請求或響應(yīng)頭部中的這個(gè)字段在數(shù)據(jù)傳輸中起著至關(guān)重要的作用。它明確地指示請求或響應(yīng)主體的大小（以字節(jié)為單位）。這有助于接收方理解當(dāng)前消息何時(shí)結(jié)束，并可能為下一個(gè)消息做準(zhǔn)備，特別是在多個(gè)HTTP消息通過同一連接發(fā)送的情況下。?Connection：該字段在HTTP持久連接中至關(guān)重要，其中一個(gè)TCP連接用于發(fā)送和接收多個(gè)HTTP請求和響應(yīng)。我們將詳細(xì)討論這個(gè)。?Content-type：該字段告訴客戶端接收到的數(shù)據(jù)的格式。?Content-encoding：該字段指示用于數(shù)據(jù)的壓縮格式。例如，如果客戶端看到'gzip'編碼，它知道需要解壓縮數(shù)據(jù)。

HTTP GET與HTTP POST

HTTP協(xié)議定義了各種方法或“動(dòng)詞”來對Web資源執(zhí)行不同的操作。常用的方法包括GET、POST、PUT和DELETE，通常用于讀取、創(chuàng)建、更新和刪除資源。較少使用的方法包括HEAD、CONNECT、OPTIONS、TRACE和PATCH，我們在之前的“API設(shè)計(jì)”問題中已經(jīng)介紹過。

一個(gè)常見的面試問題是：“GET和POST有什么區(qū)別？”讓我們深入了解它們的定義。

HTTP GET：該方法通過URL從服務(wù)器檢索資源，不會(huì)產(chǎn)生其他影響。由于GET請求通常沒有有效載荷主體，因此可以對網(wǎng)頁進(jìn)行書簽、共享和緩存。

HTTP POST：該方法基于有效載荷主體與資源進(jìn)行交互。交互方式因資源類型而異。例如，如果我們在購買了一臺(tái) iPhone 14 后留下了一條評論，并單擊“提交”，將發(fā)送帶有評論的POST請求到服務(wù)器。雖然HTTP協(xié)議本身對POST請求的消息主體大小沒有定義限制，但實(shí)際上，瀏覽器和服務(wù)器通常會(huì)施加自己的限制。

理解GET和POST的特性

HTTP方法具有一些屬性，定義了它們與服務(wù)器資源交互的方式。其中兩個(gè)屬性是它們是否“非變異”和“冪等”。

非變異方法不會(huì)改變?nèi)魏畏?wù)器資源。相反，冪等方法無論重復(fù)多少次，都會(huì)產(chǎn)生相同的結(jié)果。

HTTP GET：GET方法檢索數(shù)據(jù)而不會(huì)引起更改，因此是非變異的。此外，重復(fù)GET請求不會(huì)改變結(jié)果，因此是冪等的。

HTTP POST：與GET不同，POST方法發(fā)送的數(shù)據(jù)可以修改服務(wù)器資源，因此可能是可變異的。此外，如果我們重復(fù)POST請求，它可能會(huì)創(chuàng)建額外的資源，因此是非冪等的。

然而，重要的是要注意，實(shí)際行為可能取決于服務(wù)器如何實(shí)現(xiàn)這些方法。雖然標(biāo)準(zhǔn)建議特定行為，但開發(fā)人員有時(shí)會(huì)以非標(biāo)準(zhǔn)的方式使用這些方法。例如，GET方法可能用于刪除數(shù)據(jù)（使其既可變異又非冪等），或者POST方法可能用于檢索數(shù)據(jù)（使其非變異和潛在冪等）。

有一個(gè)臭名昭著的例子是一個(gè)博客作者使用GET來執(zhí)行帖子刪除操作，假設(shè)沒有人會(huì)訪問該博客。但是當(dāng)Google抓取該博客時(shí)，所有帖子都被刪除了！

此外，值得注意的是，無論是GET還是POST，它們本身并不安全，無法防止信息泄露。GET參數(shù)在URL中可見，而POST主體雖然在URL中不可見，但如果沒有加密仍然可以被攔截。為了確保安全的數(shù)據(jù)傳輸，建議使用HTTPS，這是我們將在后面更詳細(xì)地討論的一個(gè)主題。

HTTP Keep-Alive與TCP keepalive

我們已經(jīng)討論過HTTP如何使用“Connection: Keep-Alive”來啟動(dòng)持久連接。還記得在TCP問題中提到的TCP keepalive機(jī)制嗎？它們是否相同？不，它們完全不同：

?HTTP Keep-Alive與HTTP持久連接相關(guān)，它在應(yīng)用層運(yùn)行。?TCP keepalive在傳輸層工作，在數(shù)據(jù)交換空閑期間保持TCP連接活動(dòng)。

讓我們深入了解。

HTTP Keep-Alive

除了HTTP/3以外，HTTP都構(gòu)建在TCP之上。建立HTTP連接需要進(jìn)行3次TCP握手。在發(fā)送HTTP請求并接收到響應(yīng)后，TCP連接斷開。

以這種方式向同一服務(wù)器發(fā)送多個(gè)請求非常低效。重用相同的TCP連接是否更好？這就是HTTP Keep-Alive的目的。它保持TCP連接，直到任一方請求斷開連接。

HTTP/1.1默認(rèn)啟用了HTTP Keep-Alive。

HTTP Keep-Alive減少了打開和關(guān)閉TCP連接的開銷。當(dāng)與HTTP/2結(jié)合使用時(shí)，效果更好。HTTP/2引入了“流”的概念。

流允許我們同時(shí)發(fā)送多個(gè)請求，而無需等待服務(wù)器的響應(yīng)。更重要的是，這些請求和響應(yīng)可以按照任意順序處理，這在僅使用HTTP Keep-Alive時(shí)是不可能的。

下面的對比圖顯示了HTTP Keep-Alive和HTTP/2流之間的區(qū)別。通常，我們等待第一個(gè)響應(yīng)返回后才發(fā)送第二個(gè)請求。但是使用HTTP/2流，我們可以同時(shí)發(fā)送多個(gè)請求，而無需等待第一個(gè)響應(yīng)，服務(wù)器可以按任意順序響應(yīng)。

為什么這很重要？這個(gè)特性對于避免“HOL（Head-of-Line）阻塞”非常關(guān)鍵。在HTTP的早期版本中，如果服務(wù)器處理一個(gè)請求的時(shí)間很長，后續(xù)的請求必須等待，導(dǎo)致延遲。但是使用HTTP/2流，每個(gè)請求是獨(dú)立的。即使服務(wù)器處理一個(gè)請求的時(shí)間較長，它仍然可以響應(yīng)其他請求。響應(yīng)可以在準(zhǔn)備就緒時(shí)立即返回，即使這意味著它們的順序與原始請求不同。

TCP keepalive

TCP keepalive與HTTP Keep-Alive無關(guān)。在TCP連接中，雙方保持在已建立狀態(tài)，直到一方結(jié)束連接。如果一方不通知另一方而斷開連接，剩余的一方將不知道。TCP keepalive通過在沒有數(shù)據(jù)交換時(shí)定期發(fā)送探測來解決這個(gè)問題。我們在之前的TCP問題中討論過。下面的圖表應(yīng)該對此有所復(fù)習(xí)。