HTTP協議揭秘：探尋互聯網的背后密碼、探秘數據傳輸的奧秘
HTTP（超文本傳輸協議：Hypertext Transfer Protocol）是一種用于在Web上傳輸數據的協議，它是互聯網上最重要的應用層協議之一。從誕生至今，HTTP一直扮演著連接世界的通信橋梁的角色，在互聯網的發展和普及中發揮著重要作用。本文將帶您深入了解HTTP協議的起源、工作原理、常見特點以及它對現代Web的影響。
一、起源與發展
HTTP協議最早由蒂姆·伯納斯-李（Tim Berners-Lee）在1989年創建，作為連接萬維網（World Wide Web）上文檔的一種通信協議。起初，HTTP的目標是在客戶端和服務器之間傳輸超文本文檔（HTML）和超鏈接（Hyperlink）。隨著互聯網的蓬勃發展，HTTP也在不斷演進和完善。
在1991年，HTTP的第一個正式版本HTTP/0.9問世，其功能非常簡單，只能傳輸純文本的HTML文檔。而后，在1996年，HTTP/1.0發布，引入了更多功能，支持傳輸多種格式的資源，如圖片、樣式表和腳本文件。然而，隨著Web應用和互聯網的規模不斷擴大，HTTP/1.0的性能表現出現了瓶頸。為了解決HTTP/1.0的性能問題HTTP/1.1在1997年發布，引入了持久連接、管道化請求、Host頭字段等特性，顯著提升了網頁加載速度和用戶體驗。
時至今日，HTTP協議持續發展，最新的版本是HTTP/2（2015年發布）和HTTP/3（2022年發布），它們進一步優化了性能、安全性和并行處理能力，逐漸成為主流的HTTP協議版本。
二、工作原理
HTTP是一種無狀態的協議，每個請求都是獨立的，服務器不保留與之前請求的狀態信息。HTTP使用客戶端-服務器模式，客戶端發送請求，服務器處理請求并返回響應。
HTTP通信過程遵循以下步驟：
- 建立連接： 客戶端（通常是Web瀏覽器）向服務器發起TCP連接，并建立起雙向通信通道。
- 發送請求： 客戶端發送HTTP請求到服務器，請求包含請求行（請求方法、URL和HTTP版本）、請求頭和請求體（對于POST等有內容的請求）。
- 處理請求： 服務器接收并解析請求，根據請求的內容執行相應的操作，可能包括讀取數據庫、處理業務邏輯等。
- 發送響應： 服務器將處理結果封裝為HTTP響應，響應包含響應行（狀態碼、狀態文本和HTTP版本）、響應頭和響應體。
- 關閉連接： 服務器發送完響應后，關閉TCP連接，請求-響應過程完成。
三、特點與影響
HTTP協議具有以下特點，這些特點對現代Web應用和互聯網產生了深遠的影響：
- 無連接和無狀態： HTTP是無連接的，每個請求和響應都是獨立的。它也是無狀態的，服務器不保存客戶端的狀態信息，每次請求都是無關的，這有利于實現可伸縮性和靈活性。
- 靈活性： HTTP的靈活性使得它可以傳輸各種類型的資源，如文本、圖片、視頻等，使Web應用呈現豐富多樣的內容。
- 基于請求-響應模型： HTTP的請求-響應模型使得客戶端可以向服務器請求數據或操作，并獲取服務器的響應。這種模型促進了客戶端與服務器之間的交互和通信。
- 分層架構： HTTP的分層架構允許通過代理服務器和緩存來優化網絡傳輸，提高性能和響應速度。
- 狀態碼： HTTP的狀態碼提供了對請求處理結果的說明，例如200表示成功，404表示未找到，500表示服務器錯誤等。這些狀態碼對于診斷和調試Web應用非常有用。
四、協議組成
HTTP協議是一種規范，其樣本通常以請求和響應的形式呈現。下面是HTTP協議的一個樣本，分別展示了HTTP請求和HTTP響應的格式。
HTTP請求樣本：
GET /hanko HTTP/1.1
Host: www.hanko.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.5
Connection: keep-alive- 第一行是請求行，包含請求方法（GET）、請求的資源路徑（/hanko）和HTTP協議版本（HTTP/1.1）。
- 接下來是請求頭，包含了請求的一些附加信息，如Host（請求的目標主機）、User-Agent（客戶端的瀏覽器信息）、Accept（客戶端接受的響應內容類型）等。
當年阿里面試問到了http頭connection為keep-alive是什么意思？
當HTTP請求頭中的Connection字段設置為keep-alive時，它表示客戶端希望與服務器建立持久連接。持久連接允許在同一個TCP連接上發送多個HTTP請求和響應，而不是每個請求都建立一個新的TCP連接，從而減少了連接的建立和關閉開銷，提高了性能和效率。
除了keep-alive之外，HTTP請求頭中的Connection字段還可以包含其他值，用途如下：
- close： 當Connection設置為close時，表示客戶端或服務器希望在發送完當前的請求和響應后關閉TCP連接，即不使用持久連接。
- Upgrade： 用于HTTP升級。當Connection設置為Upgrade時，表示客戶端希望升級到其他協議，如WebSocket。
- Connection-Token： 自定義的Connection標記，可以用于傳遞額外的信息或指示特定的處理方式。
雖然名為"keep-alive"，但HTTP的持久連接（keep-alive）并不是真正意義上的一直保持連接。實際上，HTTP的持久連接是一種在單個TCP連接上可以發送多個HTTP請求和響應的機制，從而避免了每次請求都重新建立新的TCP連接，從而減少了連接的建立和關閉的開銷。
HTTP響應樣本：
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Server: Apache/2.4.41 (Ubuntu)
Date: Wed, 20 Jul 2023 12:34:56 GMT
<!DOCTYPE html>
<html>
<head>
<title>Example Page</title>
</head>
<body>
<h1>Hello, World!</h1>
<p>This is an example page.</p>
</body>
</html>- 第一行是響應行，包含HTTP協議版本（HTTP/1.1）、狀態碼（200）和狀態文本（OK）。
- 接下來是響應頭，包含了響應的一些附加信息，如Content-Type（響應內容類型）、Content-Length（響應內容長度）、Server（服務器信息）等。
- 響應頭與響應體之間有一個空行，表示響應頭結束，接下來是響應體，即實際返回給客戶端的內容。在本例中，響應體是一個簡單的HTML頁面。
1、請求頭
常見的請求頭：
- Host： 指定請求的目標主機名和端口號。
- User-Agent： 指定發送請求的用戶代理，通常是瀏覽器標識。
- Accept： 指定客戶端可以接受的響應內容類型，如文本、圖片、JSON等。
- Accept-Language： 指定客戶端可以接受的自然語言，用于國際化。
- Authorization： 用于身份驗證，包含認證信息。
- Cookie： 用于在客戶端和服務器之間傳遞會話信息。
2、響應頭
常見的響應頭：
- Content-Type： 指定響應內容的類型，如text/html、application/json等。
- Content-Length： 指定響應內容的長度，單位為字節。
- Location： 用于重定向，指定新的URL地址。
- Set-Cookie： 用于在客戶端設置Cookie，用于維持會話狀態。
- Cache-Control： 指定響應的緩存策略，如no-cache、max-age等。
3、狀態碼
HTTP狀態碼是HTTP協議中用于表示服務器對請求的處理結果的數字代碼。狀態碼由三位數字組成，每個狀態碼表示不同的處理結果。HTTP狀態碼主要分為五類，分別以不同的數字開頭，每類狀態碼具有特定的含義。以下是常見的HTTP狀態碼及其含義：
1xx（Informational）： 表示請求已被接收，繼續處理。
- 100 Continue：服務器已接收到請求的頭部，并且客戶端應繼續發送請求的其余部分。
2xx（Successful）： 表示請求已成功被服務器接收、理解和處理。
- 200 OK：請求成功，服務器已成功處理請求。
- 201 Created：請求成功，并在服務器上創建了新的資源。
- 204 No Content：請求成功，但響應不包含實體主體內容，用于成功的DELETE請求等。
3xx（Redirection）： 表示需要進一步的操作以完成請求。
- 301 Moved Permanently：請求的資源已永久移動到新的URL，客戶端應該使用新URL重新請求。
- 302 Found：請求的資源已臨時移動到新的URL，客戶端應繼續使用原始URL。
- 304 Not Modified：客戶端通過條件式請求的資源未修改，可直接使用緩存的版本。
4xx（Client Error）： 表示客戶端發生錯誤，無法完成請求。
- 400 Bad Request：請求錯誤，服務器無法理解請求。
- 401 Unauthorized：請求需要身份驗證，客戶端需要提供有效的認證信息。
- 403 Forbidden：服務器理解請求，但拒絕執行請求。
- 404 Not Found：請求的資源不存在，服務器未找到請求的URL。
5xx（Server Error）： 表示服務器發生錯誤，無法完成請求。
- 500 Internal Server Error：服務器內部錯誤，無法完成請求。
- 502 Bad Gateway：服務器作為網關或代理，從上游服務器收到無效響應。
- 503 Service Unavailable：服務器暫時不可用，通常由于過載或維護。
4、請求方法
- GET：用于請求獲取指定資源。
- POST：用于提交數據給服務器，如提交表單數據。
- PUT：用于更新指定資源的內容。
- DELETE：用于刪除指定資源。
- HEAD：類似于GET請求，但只獲取響應頭信息，不獲取響應體。
- OPTIONS：用于獲取目標資源支持的通信選項。
- PATCH：用于對資源進行局部更新。
5、Http版本
HTTP（Hypertext Transfer Protocol）協議經過多次版本的演進和改進，目前主要有以下幾個主要版本：
- HTTP/0.9： HTTP的最早版本，于1991年發布。它是一個非常簡單的協議，僅支持傳輸HTML文本，沒有請求頭和響應頭，也沒有狀態碼。它主要用于傳輸超文本文檔（HTML）和超鏈接（Hyperlink）。
- HTTP/1.0： 于1996年發布，相比HTTP/0.9，HTTP/1.0引入了請求頭和響應頭的概念，允許傳輸多種類型的資源，如圖片、樣式表和腳本文件。HTTP/1.0的特點是每個請求都需要單獨建立連接，導致效率較低。
- HTTP/1.1： 于1997年發布，是HTTP協議的一個重要版本。HTTP/1.1引入了持久連接、管道化請求、Host頭字段等特性，顯著提升了網頁加載速度和用戶體驗。持久連接允許在同一個連接上發送多個請求和響應，避免了每次請求都需要重新建立連接的開銷。
- HTTP/2： 于2015年發布，是HTTP協議的最新主要版本。HTTP/2進一步優化了性能、安全性和并行處理能力。它引入了二進制協議，允許多個請求和響應同時在同一個連接上傳輸，消除了請求阻塞的問題。HTTP/2還支持頭部壓縮和服務器推送等特性，進一步減少了數據傳輸的開銷。
- HTTP/3： 最新版本，于2022年6月6日標準化為RFC9114。會拋棄使用TCP，通過UDP上使用QUIC來承載應用層數據。
6、Cookie
HTTP Cookie（簡稱Cookie）是HTTP協議中的一種機制，用于在客戶端（通常是Web瀏覽器）和服務器之間傳遞會話信息和狀態數據。Cookie主要用于記錄用戶的一些狀態信息，以便服務器在后續請求中識別用戶或維持用戶的會話狀態。
工作原理：
- 服務器設置Cookie： 服務器在HTTP響應中的Set-Cookie頭部中設置Cookie信息，并將Cookie發送給客戶端。例如：
Set-Cookie: session_id=1234567890; path=/; domain=example.com; expires=Sun, 20-Jul-2025 12:00:00 GMT; secure; HttpOnly- 客戶端保存Cookie： 客戶端（Web瀏覽器）收到服務器設置的Cookie后，會將Cookie保存在本地。在以后的請求中，客戶端會在請求頭的Cookie字段中攜帶該Cookie信息。
- 客戶端發送Cookie： 客戶端在發送HTTP請求時，會將保存的Cookie信息包含在請求頭的Cookie字段中，發送給服務器。
- 服務器讀取Cookie： 服務器收到請求后，可以從請求頭的Cookie字段中讀取客戶端發送的Cookie信息，并根據其中的數據來識別用戶或維持會話狀態。
Cookie屬性：
Cookie可以包含多個屬性，用于指定其行為和有效期。常見的Cookie屬性包括：
- Name和Value： 表示Cookie的名稱和對應的值。
- Domain： 指定Cookie的作用域，指定了哪些域名可以訪問該Cookie。
- Path： 指定Cookie的作用路徑，指定了哪些URL路徑可以訪問該Cookie。
- Expires和Max-Age： 指定Cookie的有效期，Expires指定一個具體的過期時間，Max-Age指定從當前時間開始的有效期秒數。
- Secure： 表示Cookie只能通過HTTPS連接傳輸，用于保證Cookie的安全性。
- HttpOnly： 表示Cookie僅限于通過HTTP或HTTPS傳輸，不能被JavaScript等腳本訪問，用于防止XSS攻擊。
用途：
Cookie在Web應用中有許多用途，其中一些常見的包括：
- 記錄用戶的登錄狀態，實現用戶認證和會話管理。
- 存儲用戶的個性化設置和偏好。
- 跟蹤用戶的瀏覽行為，用于分析用戶行為和推薦相關內容。
- 在購物網站中，用于保存購物車信息和交易狀態。
7、URL長度
URL長度的限制由瀏覽器規定的，而不是HTTP協議。以下是一些瀏覽器對http中url長度的限制大小。
當然大家會說我是搞開發的，我不用瀏覽器那么長度限制嗎？比如用apache-httpclient，我試httpclient也同樣是有長度限制的，過長就返回400錯誤了。
