前言

前面我們介紹了網(wǎng)絡 TCP/IP 五層模型中的各個層，在這五層中，應用層是和我們程序員息息相關的，需要我們程序員寫出代碼來實現(xiàn)，前面我們只是簡單講了應用層中的自定義協(xié)議，雖然自定義協(xié)議顯得很靈活可以根據(jù)需求隨時更改，但是在實際生活中自定義的協(xié)議使用的還是少數(shù)。在應用層中常見的協(xié)議就是 HTTP 協(xié)議，今天我將為大家分享關于 HTTP 協(xié)議相關的知識。

什么是 HTTP

HTTP，全稱為超文本傳輸協(xié)議（Hypertext Transfer Protocol），是一種應用層協(xié)議，用于在網(wǎng)絡中傳輸超文本（如 HTML）。它是在互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議，所有的www文件都必須遵守這個標準。HTTP是客戶端瀏覽器或其他程序與Web服務器之間的應用層通信協(xié)議。在Internet上的Web服務器上存放的都是超文本信息，HTTP客戶端通過發(fā)送請求獲取服務器上的文本信息。HTTP協(xié)議工作于TCP/IP協(xié)議棧的的應用層，用于從網(wǎng)站的服務器中檢索信息，請求被（今后稱為被HTTP客戶）發(fā)送到服務器。

HTTP 誕生于 1991 年，目前已經(jīng)發(fā)展成為最主流的一種應用層協(xié)議。從開始的 HTTP 0.9 用于個人/機構主頁開始，經(jīng)過 HTTP 1.0 門戶網(wǎng)站和 HTTP 1.1版本用于搜索引擎和社交網(wǎng)絡到 HTTP 2.0 ，再到今天的 HTTP 3，HTTP 經(jīng)過了很多版本的迭代，其中 HTTP 1.1 是我們目前最主要使用的，所以本篇博客我也將以 HTTP 1.1 為例為大家分享關于 HTTP 相關的知識。

HTTP 往往是基于傳輸層的 TCP 協(xié)議實現(xiàn)的（HTTP 1.0、HTTP 1.1、 HTTP 2.0 均為 TCP，HTTP 3基于 UDP 實現(xiàn)）。

我們在平時生活中訪問網(wǎng)站就是通過 HTTP 協(xié)議來進行數(shù)據(jù)的傳輸?shù)摹?/p>

當我們在瀏覽器輸入一個百度網(wǎng)址（URL）的時候，瀏覽器會向百度的服務器發(fā)送一個 HTTP 服務器請求，然后百度服務器會返回一個 HTTP 響應。瀏覽器會將這個響應進行解析，然后就以上面的方式呈現(xiàn)在我們眼前。（這個響應里面包含了 HTML、CSS、JavaScript、圖片、文字等信息）

理解 HTTP 請求和響應格式

跟前面的 TCP/IP 協(xié)議不同，HTTP 的報文格式需要劃分為 請求報文和響應報文 來分析，因為 HTTP 的請求和響應的報文格式是不相同的。

要想學習 HTTP 的請求和響應格式，就需要首先得到 HTTP 的請求和響應數(shù)據(jù)包，通過前面為大家分享的 HTTP 抓包工具 Fiddler 這個代理工具來抓取到 HTTP 的請求和響應數(shù)據(jù)包。

HTTP 的請求格式

HTTP 的請求格式大致分為四個部分：首行、請求頭（header）、空行、正文（body）

1. 首行

HTTP 的首行分為三個部分，每個部分用空格分隔開。

第一個部分 GET 叫做請求的“方法”（method），方法不止有 GET 還有像 POST 等的方法這里我們先簡單知道，后面再為大家詳細分享。

第二個部分就是 URL（唯一資源定位符），用來描述一個資源在網(wǎng)絡上的位置。URL 不只是在 HTTP 中會使用，URL 在其他很地方也都會用到。

• 協(xié)議方案：這部分定義了網(wǎng)頁使用的網(wǎng)絡服務類型，例如http或https。

• 登錄信息：用戶輸入的用戶名和密碼。現(xiàn)在一般用不到這個了。

• 服務器地址：這部分定義了網(wǎng)站的域名，例如www.aspxfans.com。在URL中，也可以使用IP地址作為域名。

• 服務器端口號：這部分定義了主機上的端口號。端口不是URL必須的部分，如果省略端口部分，將采用默認端口。對于 HTTP 請求，端口號默認是 80 端口；對于 HTTPS 協(xié)議，端口號默認是 443 端口。

• 虛擬目錄部分：這部分從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。

• • 雖然這里的寫法是目錄的形式，但是在服務器是不一定是以目錄的方式存儲資源的。數(shù)據(jù)可能是硬盤資源，也可能是內存的數(shù)據(jù)，也可能是通過網(wǎng)路訪問其他服務器拿到的數(shù)據(jù)，還可能是 CPU 計算出來的數(shù)據(jù)。

• 查詢字符串：這部分包含了一些參數(shù)，這些參數(shù)可以用來傳遞一些額外的信息。

• • 查詢字符串是以 ？開始的鍵值對結構的數(shù)據(jù)，鍵和值之間用 = 連接，可以有多個鍵值對，不同的鍵值對之間使用 & 連接。這個 query string 是程序員自定義的用來補充相關的查詢請求，并且這個 query string 也會通過 urlencode 轉碼。舉個例子：我搜索c++，搜索欄中的首行 query string 部分的%2B%2B就是++的轉碼，因為這些特殊符號可能會與其他標識符產(chǎn)生歧義，經(jīng)過轉碼的字符就是用%來標識的。

• 

• 片段標識符：這部分定義了一個鏈接到網(wǎng)頁的特定部分，通常用于指向頁面的特定內容或導航點。

首行中的第三個部分就是 HTTP 的版本號。

2. 請求頭

HTTP 請求頭是一個鍵值對結構的數(shù)據(jù)，里面含有很多的鍵值對，每個鍵值對獨占一行，鍵和值之間通過冒號加空格: 連接，并且這些鍵值對都是屬于“標準規(guī)定”的，要求我們這樣寫。這些鍵值對具體的含義，后面為大家詳細介紹。

3. 空行

這里空行是請求頭的結束標記。

這里我們看到在抓取到的百度請求數(shù)據(jù)包的末尾是有一個空行的。這就是請求頭的結束標志。

4. 正文（body）

HTTP數(shù)據(jù)包中的正文（Body）通常指的是請求或響應的消息體，它包含了實際傳輸?shù)臄?shù)據(jù)內容。在HTTP請求中，正文通常包含了客戶端要發(fā)送給服務器的數(shù)據(jù)，例如表單數(shù)據(jù)、JSON數(shù)據(jù)等。在HTTP響應中，正文通常包含了服務器返回給客戶端的數(shù)據(jù)，例如HTML頁面、JSON數(shù)據(jù)等。

HTTP正文是由一些字節(jié)組成的，可以是任何類型的數(shù)據(jù)，包括文本、二進制數(shù)據(jù)等。在HTTP協(xié)議中，正文使用Content-Type頭部來指定其數(shù)據(jù)的類型和編碼方式。常見的Content-Type類型包括text/html、application/json等。

需要注意的是，HTTP請求和響應的正文是可選的，它們不是每個HTTP數(shù)據(jù)包都必須包含的部分。如果正文不存在，則請求或響應的消息體將為空。

這里我們抓取到的 HTTP 請求數(shù)據(jù)包中就沒有正文部分。

HTTP 的響應格式

HTTP 的響應數(shù)據(jù)包也是分為四個部分：首行、響應頭（header）、空行、正文（body）。

1. 首行

HTTP 響應報文的首行也是分為三個部分：HTTP 版本號、狀態(tài)碼、狀態(tài)碼描述。

• HTTP 版本號：描述了該 HTTP 響應報文用的是哪個 HTTP 版本。
• 狀態(tài)碼：描述了服務器對客戶端請求的處理結果。狀態(tài)碼分為5類，每一類有不同的意義。
• 
• 狀態(tài)碼描述：狀態(tài)信息是對應狀態(tài)碼的簡單文字描述，它向客戶端提供了可以理解的、對應狀態(tài)碼的文字描述。例如，“OK”對應狀態(tài)碼200，“Not Found”對應狀態(tài)碼404，“Internal Server Error”對應狀態(tài)碼500等。
  

2. 響應頭

這里的響應頭也是一些鍵值對，鍵和值之間通過冒號和空格: 連接，每個鍵值對獨占一行，并且這些鍵值對也是“標準規(guī)定”的。

3. 空行

這里的空行也是響應頭的結束標志。

4. 正文（body）

這里的正文和 HTTP 請求報文的正文是類似的。

首行

首行中的 method 方法有很多種。

雖然請求中的方法有很多，但是 GET 和 POST 這兩個方法的使用占了日常使用的八成，所以這篇文章我們主要學習 GET 和 POST 這兩種方法。

GET 和 POST 方法有什么區(qū)別

GET 是最常用的 HTTP 方法. 常用于獲取服務器上的某個資源。在瀏覽器中直接輸入 URL, 此時瀏覽器就會發(fā)送出一個 GET 請求。另外, HTML 中的 link, img, script 等標簽, 也會觸發(fā) GET 請求。GET 請求會將要傳給服務器的數(shù)據(jù)加到 URL 的 query string 中。POST 方法多用于提交用戶輸入的數(shù)據(jù)給服務器(例如登陸頁面)。
POST 方法則會將要傳給服務器的數(shù)據(jù)放入到正文（body）中。

但是不一定 GET 方法要傳給服務器的數(shù)據(jù)就一定放在 query string 中不能放在 正文（body）中，GET 方法的傳輸給服務器的數(shù)據(jù)也是可以放在 正文（body）中的，只要客戶端和服務端都遵守相同的規(guī)則就可以了，雖然 GET 方法的傳給服務器的數(shù)據(jù)可以放在正文（body）中，但還是建議大家放在query string 中。

這里我在導航欄輸入 www.baidu.com 的時候，其實就是發(fā)送的 GET 方法的請求。

而我登錄 gitee 的時候就是 HTTP 發(fā)送的 POST 方法的請求數(shù)據(jù)包。

但是有時候也會出現(xiàn) Fiddler 沒有抓取到 HTTP 數(shù)據(jù)包的情況，就是當我多次訪問一個網(wǎng)站的時候，可能就不會抓取到這個 HTTP 請求數(shù)據(jù)包，這是為什么呢？這是因為剛剛的這個訪問網(wǎng)站的請求命中了瀏覽器的緩沖，當發(fā)生這種情況的時候，其實瀏覽器不會向服務器發(fā)送 HTTP 請求。

瀏覽器顯示的網(wǎng)頁其實都是從服務器這里下載的 HTML，因為 HTML 的內容可能會很多，體積比較大，通過網(wǎng)絡加載的話，消耗的時間就會很多，所以為了加快訪問速度，瀏覽器會有自己的緩存，將之前加載過的頁面，保存在本地硬盤中，當下次訪問這個網(wǎng)站的時候就可以直接從本地磁盤讀取數(shù)據(jù)，所以也就會導致本次訪問不會向服務器發(fā)送 HTTP 請求數(shù)據(jù)包。

假設我要上傳一個文件的時候，那么此時就會向服務器發(fā)送一個 POST 方法的請求數(shù)據(jù)包，并且這個數(shù)據(jù)包的正文部分是這樣的。

這種就是，圖片本來是二進制數(shù)據(jù)，當把圖片這個二進制數(shù)據(jù)放入 HTTP 請求的時候，往往需要進行 base64 轉碼，base64 轉碼就是針對二進制數(shù)據(jù)進行重新編碼，確保編碼之后的數(shù)據(jù)就是純文本的數(shù)據(jù)。

這些 HTTP 請求的初心就是為了表示不同的“語義”，但是在實際的使用過程中，這出初心已經(jīng)漸漸被遺忘了，這些方法的使用更加隨意了，所以就導致現(xiàn)在的 GET 和 POST 方法實際上是沒有任何區(qū)別的。

針對 GET 方法和 POST 方法的區(qū)別的一些錯誤看法

1. GET 請求能傳遞的數(shù)據(jù)有上限,POST 傳遞的數(shù)量沒有上限。

這個說法其實是一個“歷史遺留”，早期版本的瀏覽器，因為硬件資源特別匱乏，所以瀏覽器就對 URL 的長度進行了限制，因為 GET 方法通常是將傳輸給服務器的數(shù)據(jù)加在 URL 的 query string 中，所以當用 GET 方法要傳給服務器的數(shù)據(jù)較多的時候就會導致 URL 會很長。

但是實際上，RFC 標準文檔 并沒有明確規(guī)定 URL 能有多長，而且現(xiàn)在由于技術的進步，URL 也可以很長，甚至可以用 URL 來傳遞一些圖片等。所以這個說法是錯誤的。

2. GET 請求傳遞數(shù)據(jù)不安全，POST 請求傳遞數(shù)據(jù)更安全。

為什么會這樣說呢？因為在使用 GET 請求登錄的時候，會將用戶名和密碼放入 URL 中，進一步顯示在瀏覽器的地址欄當中，這樣別人不就能輕易看到了嗎？而 POST 更安全就說的是因為 POST 會將用戶名和密碼放入 body 中，這樣就不會顯示在瀏覽器搜索欄中，那么此時就是安全的了。但是這個說法是錯誤的，這個說法只能忽悠小白。什么叫做安全？安全就只是不將用戶名和密碼顯示在搜索欄中嗎？那可不是，所謂安全就是這個請求包不會被輕易的被黑客給截取到，就算被截取到了黑客也需要花出大于該數(shù)據(jù)本身的價值來破解這個數(shù)據(jù)包。不管是 GET 請求的數(shù)據(jù)包還是 POST 數(shù)據(jù)的數(shù)據(jù)包，當數(shù)據(jù)包被截取到了，知道這個請求數(shù)據(jù)包的首行和正文（body）部分都是輕而易舉的。

所以為了解決這個傳輸數(shù)據(jù)的過程中被黑客截取到然后可以直接知道你數(shù)據(jù)的內容的問題，就采取了對用戶名和密碼進行加密的措施，這樣就算你獲取到了這個請求數(shù)據(jù)包，因為用戶名和密碼是經(jīng)過加密的，黑客是不容易破解的。

3. GET 只能給服務器傳輸文本數(shù)據(jù)，POST 可以給服務器傳輸文本和二進制數(shù)據(jù)。

請求數(shù)據(jù)包的正文（body）部分可以放文本數(shù)據(jù)也可以放二進制數(shù)據(jù)，為什么會有這個說法呢？其實這個說法還是基于第一個說法的，就是因為被誤以為 GET 方法傳輸給服務器的數(shù)據(jù)只能寫入 URL 的 query string 中，而 URL 中的數(shù)據(jù)往往是文本數(shù)據(jù)，但是 GET 方法傳輸給服務器的數(shù)據(jù)是可以寫入 正文（body）部分的，所以 GET 方法也是可以傳輸二進制數(shù)據(jù)的。

GET 方法和 POST 方法的區(qū)別的說法有一定的道理但不嚴謹?shù)恼f法

1. GET 方法是冪等的，POST 方法是非冪等的。

什么是冪等和非冪等呢？

冪等是指同一個系統(tǒng)，同樣的參數(shù)條件，一次請求和多次同樣重復的請求對資源的影響一樣。例如，一次插入請求插入一條數(shù)據(jù)，多次插入請求產(chǎn)生的影響也是多一條數(shù)據(jù)，那么就是冪等的。

非冪等是指同一個系統(tǒng)，同樣的參數(shù)條件，一次請求和多次同樣重復的請求對資源的影響不一樣。例如，用戶重復操作，如用戶提交請求進行創(chuàng)建訂單操作，由于網(wǎng)絡問題，導致頁面一直在轉，用戶重新點擊創(chuàng)建訂單按鈕，就會產(chǎn)生同樣的訂單在數(shù)據(jù)庫中創(chuàng)建了兩條，這就是非冪等的。

為什么說 GET 方法是冪等的，POST 方法是非冪等的呢？因為在 RFC 標準文檔中有這樣一個建議：建議 GET 請求的數(shù)據(jù)是冪等的。但是這只是一個建議，并不是硬性要求，所以這個說法不嚴謹。

2. GET請求可以被瀏覽器緩存，POST 方法不可以被瀏覽器緩存。

這個說法雖然有一定的正確性，但并不嚴謹。這是因為GET和POST請求本身都可以被緩存，只是瀏覽器在處理這兩種請求時的行為和機制有所不同。

對于GET請求，瀏覽器會緩存GET請求的響應結果，以便在后續(xù)相同的請求時直接使用緩存的響應，而不需要再次向服務器發(fā)送請求。這是由于GET請求是冪等的，即多次發(fā)送相同的GET請求將獲得相同的結果，不會對資源產(chǎn)生任何額外的影響。

然而，對于POST請求，瀏覽器通常不會緩存響應結果。這是因為在大多數(shù)情況下，POST請求用于提交數(shù)據(jù)或執(zhí)行更新操作，每次請求的結果可能會有所不同。瀏覽器為了確保每次POST請求都會向服務器發(fā)送最新的數(shù)據(jù)和產(chǎn)生最新的結果，不會緩存POST請求的響應結果。

然而，這并不意味著POST請求絕對不會被緩存。實際上，一些瀏覽器或代理服務器可能會對POST請求進行緩存，特別是在某些情況下，例如當使用緩存代理時。此外，一些Web應用程序也可能通過編程方式實現(xiàn)POST請求的緩存。

因此，這個說法“GET請求可以被瀏覽器緩存，POST 方法不可以被瀏覽器緩存”雖然在一定程度上反映了瀏覽器對GET和POST請求的處理機制，但并不適用于所有情況。在具體的上下文中，需要考慮瀏覽器的行為、Web應用程序的實現(xiàn)以及其他因素來評估這個說法的準確性。

3. GET 請求可以被瀏覽器收藏，POST 請求的數(shù)據(jù)不能被收藏。

這個說法也是不嚴謹?shù)摹嶋H上，GET請求和POST請求都可以被瀏覽器收藏，但它們在收藏過程中有一些區(qū)別。

對于GET請求，瀏覽器會將請求的URL和參數(shù)一起保存下來，以便用戶可以在以后直接點擊該URL來重新加載頁面或獲取數(shù)據(jù)。這種方式很常見，例如在瀏覽器書簽中保存網(wǎng)頁URL。當用戶點擊該URL時，瀏覽器會發(fā)送一個GET請求到服務器，然后服務器會返回相應的網(wǎng)頁內容。因此，GET請求可以被瀏覽器收藏。

對于POST請求，瀏覽器不會直接保存請求的URL和參數(shù)，因為POST請求是向服務器發(fā)送數(shù)據(jù)的請求方式。瀏覽器將POST請求的數(shù)據(jù)包含在請求體中，而不是URL中。但是，用戶可以在瀏覽器中手動復制和粘貼POST請求的URL和參數(shù)，或者使用開發(fā)者工具來查看和復制POST請求的內容。因此，雖然瀏覽器不會自動收藏POST請求的數(shù)據(jù)，但用戶仍然可以手動將其保存下來。

需要注意的是，瀏覽器收藏的GET請求URL可能包含敏感信息，例如身份驗證令牌或密碼等。為了保護用戶的隱私和安全，這些信息應該通過POST請求或其他安全機制發(fā)送到服務器。

Header

Header 中的鍵值對是有很多的，但是這里我們主要挑選幾個來介紹。

Host

Host：表示服務器主機的地址和端口。這里的內容通常在 URL 中也有體現(xiàn)，但是如果使用代理的情況下 Host 的內容和 URL 中的內容可能就不一樣了。

Content-length

Content-length：表示 body 中的數(shù)據(jù)長度。

Content-length 有什么用，因為 HTTP 是基于 TCP 的，TCP 在傳輸?shù)倪^程中可能會出現(xiàn)粘包的問題，如果使用同一個 TCP 連接傳輸多個 HTTP 數(shù)據(jù)包的時候，這樣多個 HTTP 數(shù)據(jù)包就會在接收緩沖區(qū)當中挨著等待，接收方在接收這些 HTTP 數(shù)據(jù)包的時候就需要清楚 HTTP 數(shù)據(jù)包的邊界，對于 GET 這種一般沒有 body 部分的數(shù)據(jù)包就需要使用 空行 來作為分隔符；而對于 POST 來說，一般是有 body 部分的，所以就需要通過 空行和 Content-length 來區(qū)分不同的數(shù)據(jù)包。

只有請求中有 body 部分的時候，才會有 Content-length 和 Content-type 這兩個鍵值對。

Content-type

Content-type：表示 body 中數(shù)據(jù)的格式。

body 中數(shù)據(jù)格式的種類是有很多的：
請求：

1. JSON
2. form 表單格式
3. form-data 的格式

這種數(shù)據(jù)格式就是一種 json 數(shù)據(jù)格式。

當 Content-type 是以下這種形式的時候就表示是 form 表單格式。

form 表單就相當于把 GET 的 query string 給搬到 body 中。

而 form-data 格式通常是在上傳文件的時候會涉及到，但上傳文件的時候也不一定都是 form-data 格式，也可能是 form 表單格式。

響應：

1. HTML
2. CSS
3. JS
4. JSON
5. 圖片

通常在 Fiddler 中抓取到的藍色的就屬于是 HTML 格式的數(shù)據(jù)包；紫色就是 CSS、綠色是 JavaScript、黑色是 JSON。

HTML CSS JS 用來構成網(wǎng)頁的主體。

1. HTML 表示頁面的骨架（頁面上有啥東西）
2. CSS 表示頁面的樣式（頁面長啥樣）
3. JavaScript 表示頁面的行為

交給服務器的 Content-type 不同，服務器的處理數(shù)據(jù)邏輯也是不同的，服務器返回處理的數(shù)據(jù)的時候也需要表明 Content-type，瀏覽器也會根據(jù)不同的 Content-type 做出不同的處理。

User-Agent（簡稱 UA ）

通過上面的抓包，觀察 User-Agent 我們可以看到幾個很常見的消息：Windows NT 10.0；win64；x64 這表示的是我們使用的主機的相關信息，而 Chrome/118.0.0.0 則表示的是我們使用的瀏覽器的版本號。通過這兩個信息我們大概可以知道 User-Agent 表示的就是與當前瀏覽器相關的信息。

為什么 HTTP 數(shù)據(jù)包中會出現(xiàn)這個 UA 呢？其實在很早之前，那時候瀏覽器剛剛發(fā)展，最開始瀏覽器網(wǎng)頁就只是單純的文字，并沒有什么圖片，并且瀏覽器的相關功能也很簡單，但是隨著瀏覽器的發(fā)展，瀏覽器上開始能顯示圖片以及一些聲音信息了，那么有些人就會選擇更新瀏覽器版本，但是在新瀏覽器普及的過程中，普及的過程是緩慢的，所以就會出現(xiàn)舊瀏覽器和新瀏覽器并存的情況，那么當用戶訪問的時候，服務器應該返回有圖片的網(wǎng)頁還是無圖片的網(wǎng)頁呢？如果返回有圖片的數(shù)據(jù)，那么就瀏覽器就不支持這個功能，但是如果返回一個沒有圖片的網(wǎng)頁，那么新版本瀏覽器更新又有什么用呢？所以這時候 UA 就發(fā)揮作用了，服務器可以根據(jù)請求中 UA 反應的瀏覽器版本來返回不同的網(wǎng)頁。

但是現(xiàn)在其實 UA 就沒那么關鍵了。因為現(xiàn)在不同版本的瀏覽器功能幾乎是差不多的，現(xiàn)在的 UA 主要是用來辨別你是 PC 端還是移動端的，雖然可以用來辨別是 PC 端還是移動端，但是返回的網(wǎng)頁其實跟這個 UA 無關。這個 UA 是用來統(tǒng)計數(shù)據(jù)的。現(xiàn)在的前端開發(fā)，有“響應式網(wǎng)頁”編程的技術，同一個 HTML 可以兼容不同的設備。

Referer

Referer 描述了當前網(wǎng)頁面是從哪個頁面跳轉過來的。直接在搜索欄中輸入 URL 是沒有 Referer 的。

Referer是HTTP請求中的header部分，當瀏覽器向web服務器發(fā)送請求時，一般會帶上Referer，告訴服務器該網(wǎng)頁是從哪個頁面鏈接過來的，服務器因此可以獲得一些信息用于處理。

Referer主要有兩個作用：

1. 防盜鏈：只允許我本身的網(wǎng)站訪問本身的圖片服務器，假如域名是www.google.com，那么圖片服務器每次取到Referer來判斷一下域名是不是www.google.com，如果是就繼續(xù)訪問，不是就攔截。
2. 防止惡意請求：對于某些風險較高的文件類型，可使用Referer使得該類型文件只能來自我所指定的網(wǎng)站。

很多搜索引擎中的廣告都是需要廣告商給搜索引擎這個公司出廣告費的，有的廣告費就是根據(jù)這個廣告掛在搜索引擎多長時間計費的，而大多數(shù)廣告費則是根據(jù)這個點擊次數(shù)來計費的。那么搜索引擎或者廣告商是如何判斷某個點擊是從哪個網(wǎng)站點擊的呢？這里就需要用到 HTTP 數(shù)據(jù)包中的 Referer 了，通過 HTTP 數(shù)據(jù)包中的 Referer 就可以知道這個點擊來自哪個頁面。

但是是否會出現(xiàn)一個現(xiàn)象：這個 HTTP 數(shù)據(jù)包中的 Referer 會被惡意修改，修改成其他公司，從而導致最終的廣告費都給了它們呢？其實是有可能的。在很早之前，因為進行網(wǎng)絡數(shù)據(jù)的傳輸就需要經(jīng)過網(wǎng)絡運行商的交換機/路由器，那么這些網(wǎng)絡運行商就可以將經(jīng)過它們交換機/路由器的數(shù)據(jù)中的 Referer 進行修改，從而是他們最終成為受益者，并且這個現(xiàn)象在當時是非常猖獗的，因為當時互聯(lián)網(wǎng)剛發(fā)展，相關的法律還沒有完善，所以這些搜索引擎公司并不能拿這些網(wǎng)絡運營商什么辦法。所以這些搜索引擎就決定在技術上進行修改，對這些HTTP 數(shù)據(jù)包進行加密，這樣網(wǎng)絡運營商就不能輕易修改其中的 Referer 了。

Cookie

HTTP的cookie是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，通常由服務器使用HTTP響應頭Set-Cookie發(fā)送到瀏覽器。當瀏覽器再次向同一服務器發(fā)起請求時，會默認攜帶這些 Cookie，并發(fā)送到服務器上。

類似于一些信息：上次登錄時間、上次訪問時間、用戶身份信息、累計訪問次數(shù)等這些信息都會存儲在瀏覽器的 Cookie 中，并且在下一次訪問這個網(wǎng)站的時候會將這個 Cookie 一起發(fā)送過去。

因為這些數(shù)據(jù)都是臨時的，隨時都可能會改變，所以這些數(shù)據(jù)還是存在瀏覽器最合適，其實更容易想到的是將這些數(shù)據(jù)保存在我們的本地文件中，但是這樣是不行的，為了保證安全性，瀏覽器會禁止網(wǎng)站直接訪問你本地的文件，所以也就導致網(wǎng)頁代碼無法直接生成一個硬盤文件來存儲數(shù)據(jù)了。所以為了保證安全性，又能保存數(shù)據(jù)，就引入了 Cookie，Cookie 也是按照硬盤文件的形式保存數(shù)據(jù)的，但是瀏覽器對這個文件進行了封裝，網(wǎng)頁只能往 Cookie 中存放鍵值對。

Cookie 往往是從服務器返回的數(shù)據(jù)（也可以是自己生成的）；Cookie 存儲在瀏覽器所在的本地計算機中，并且是按照域名為維度來存儲的，每個域名都有自己的 Cookie ，彼此之間互不影響；Cookie 中的鍵值對是程序員自定義的；后續(xù)在請求這個服務器的時候，就會把 Cookie 中的內容自動帶入到請求中，然后發(fā)給服務器，服務器通過這個 Cookie 中的內容做出一些邏輯上的處理。文章來源地址http://www.zghlxwxcb.cn/news/detail-755317.html

到了這里，關于【計算機網(wǎng)絡】HTTP 協(xié)議的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！