Java【網絡原理】（4）HTTP協議

1.前言

2.正文

2.1自定義協議

2.2HTTP協議

2.2.1抓包工具

2.2.2請求響應格式

2.2.2.1URL

2.2.2.2urlencode

2.2.3認識方法

2.2.3.1GET與POST

2.2.3.2PUT與DELETE

2.2.4請求頭關鍵屬性

3.小結

1.前言

哈嘍大家好啊，今天來繼續給大家帶來Java中網絡原理的學習，本節主要學習的是HTTP協議，在講HTTP協議之前還會補充一個知識點（自定義協議），本節學完后就是HTTPS的學習了，那么廢話不多說讓我們開始吧。

2.正文

2.1自定義協議

在平時寫代碼的時候，咱們往往跟應用層打交道，應用層中涉及到的網絡通訊協議，很多都是程序員自己定制的。那么到底如何自定義協議呢？

自定義協議，分成兩個階段：

根據需求, 明確傳輸哪些信息
約定好信息組織的格式.

其中有許多組織信息的格式，主要包含以下四種：

設計協議時，數據組織格式直接影響可讀性、傳輸效率、解析復雜度。以下通過生活化案例，對比四種常見格式：行文本、XML、JSON、Protobuf。

1. 行文本格式

特點：用簡單分隔符（如逗號、豎線）組織數據，適合結構簡單的場景。
類比：快遞單上的信息——用空格或橫線分隔收件人、電話、地址。

示例：用戶登錄協議
login|user123|e10adc3949ba59abbe56e057f20f883e|mobile
字段解釋：

login：命令類型（登錄）

user123：用戶名

e10adc...：MD5加密后的密碼

mobile：設備類型

優點：

體積小，解析簡單（直接按分隔符拆分）。

適合嵌入式設備或性能受限的場景。

缺點：

擴展性差（新增字段需調整解析邏輯）。

無數據類型區分（所有內容都是字符串）。

2. XML格式

html 和 xml 都是成對的標簽構成的鍵值對結構~
html 標簽內容都是固定的。大佬們約定好的，你不能亂寫，也不能創建新的標簽（現在 html5 允許自定義標簽了）xml 標簽內容是自定義的。

特點：通過標簽嵌套表示數據，適合復雜結構化數據。
類比：書本目錄——用章節標題和子標題分層組織內容。

示例：訂單數據傳輸
<order><id>1001</id><customer><name>張三</name><phone>13800138000</phone></customer><items><item><product_id>P100</product_id><quantity>2</quantity></item><item><product_id>P200</product_id><quantity>1</quantity></item></items>
</order>
優點：

結構清晰，支持嵌套和復雜數據類型。

可讀性強（標簽自帶語義）。

缺點：

冗余標簽多，體積大（傳輸效率低）。

解析復雜。

現在xml使用的已經很少了，主要是下面的json。

3. JSON格式

特點：輕量級的鍵值對結構，兼顧可讀性和簡潔性。
類比：表格簡歷——用“字段名:值”清晰展示信息。

示例：用戶消息推送
{"type": "message","sender": "user123","receiver": "user456","content": "晚上一起吃飯嗎？","timestamp": 1629780000,"extras": {"emotion": "開心","priority": 1}
}
優點：

語法簡潔（比XML體積小）。

天然支持嵌套對象和數組。

廣泛支持（幾乎所有編程語言都有解析庫）。

適用場景：

RESTful API 接口（90%的互聯網API使用JSON）。

前端與后端數據交互。

4. Protobuf（Protocol Buffers）（C++用的比較多）

特點：二進制編碼，高性能，需預定義數據結構（.proto文件）。
類比：密碼本——收發雙方需提前約定編碼規則，傳輸時用二進制壓縮。

優點：

體積極小（比JSON小3-10倍）。

解析速度極快（無需反射，直接內存映射）。

強類型約束（減少數據錯誤）。

缺點：

可讀性差（二進制不可直接閱讀）。

需預編譯生成代碼（開發流程稍復雜）。

總結一下：

行文本 (最原始)
xml(比較原始,可讀性好,冗余較多)
json(主流的方式,可讀性好,冗余一般)
protobuf(高性能場景下使用的方式,可讀性差,冗余最小)

格式體積可讀性解析速度適用場景
行文本 最小低快簡單配置、傳感器數據
XML 大高慢復雜企業級系統
JSON 中等高中等 Web API、前后端交互
Protobuf 最小低最快高性能通信、IoT、微服務

格式	體積	可讀性	解析速度	適用場景
行文本	最小	低	快	簡單配置、傳感器數據
XML	大	高	慢	復雜企業級系統
JSON	中等	高	中等	Web API、前后端交互
Protobuf	最小	低	最快	高性能通信、IoT、微服務

下文就要展開我們的重點HTTP協議了。?

2.2HTTP協議

HTTP是一問一答模式的協議，客戶端發來一個請求，服務器就返回一個響應，請求和響應一一對應。對于HTTP協議的學習我們需要借助抓包工具來進行。

2.2.1抓包工具

抓包工具是什么呢？是用來干什么的呢？

1. 什么是抓包？

抓包（Packet Capture）指捕獲網絡傳輸中的數據包，并對其進行分析的過程。

就像在快遞運輸線上安裝監控攝像頭，記錄每個包裹的來源、目的地和內容。

2. 為什么需要抓包？

有以下幾個場景：

調試網絡問題：定位連接超時、丟包等問題。

分析協議行為：查看HTTP請求、DNS解析等細節。

安全審計：檢測惡意流量（如DDoS攻擊、數據泄露）。

性能優化：分析網絡延遲、帶寬占用。

3. 抓包工具的工作原理

網卡混雜模式：

默認情況下，網卡只接收目標地址是自己的數據包。

開啟混雜模式后，網卡會捕獲流經它的所有數據包（包括其他設備的流量）。

協議解析與過濾：

抓包工具根據協議規范（如TCP/IP、HTTP）解析二進制數據包，提取可讀信息。

支持按協議類型、IP地址、端口號等條件過濾數據。

存儲與展示：

數據包可保存為文件（如.pcap格式），供后續分析。

工具提供可視化界面，展示數據包的層次結構和字段內容。

講完了什么是抓包，接下來介紹兩個抓包工具：

1.Wireshark

官網：Wireshark · Go Deephttps://www.wireshark.org/

核心功能：

多協議支持：解析超過2000種協議（如HTTP、TCP、DNS、ICMP）。

深度分析：展示數據包的每一層（從物理層到應用層）。

過濾與統計：支持復雜過濾語法，提供流量統計圖表。

2.Fiddler

官網：Web Debugging Proxy and Troubleshooting Tools | Fiddlerhttps://www.telerik.com/fiddler

核心功能：

HTTP/HTTPS代理：攔截所有經過代理的Web請求。

請求/響應修改：實時修改請求參數、響應內容。

性能分析：統計頁面加載時間、資源大小。

自動化腳本：通過Fiddler Script自定義處理邏輯。

二者對比：

?

對比維度 Wireshark Fiddler
協議支持 所有網絡層協議（TCP/IP、ICMP、ARP等）主要HTTP/HTTPS，部分FTP、WebSocket
抓包層級 底層（原始數據包）應用層（HTTP請求/響應）
操作系統 跨平臺（Windows、macOS、Linux）僅Windows（經典版）
性能影響 高（捕獲所有流量）低（僅代理流量）
簡而言之：wireshark抓很多協議，使用門檻較高。而fiddler專門抓HTTP，功能簡單，使用也簡單。

對比維度	Wireshark	Fiddler
協議支持	所有網絡層協議（TCP/IP、ICMP、ARP等）	主要HTTP/HTTPS，部分FTP、WebSocket
抓包層級	底層（原始數據包）	應用層（HTTP請求/響應）
操作系統	跨平臺（Windows、macOS、Linux）	僅Windows（經典版）
性能影響	高（捕獲所有流量）	低（僅代理流量）

這里我們往后就使用fiddler。

2.2.2請求響應格式

這里我們通過fiddler來抓一個請求與響應：

請求：

首行：請求方法 URL 版本號
請求頭（header）：鍵值對結構，每一行是一個鍵值對，鍵和值之間使用：空格分割，HTTP 請求頭中的鍵有哪些取值，對應的值又有哪些取值，都是由標準約定的。
空行：用來標識header結束了。
正文（body）：部分請求有正文，部分沒有（像上面這個就沒有）。

響應：

首行
響應頭：也是鍵值對
空行：表示header部分結束/
正文?

下文我們要講解寫請求與相應的關鍵屬性。?

2.2.2.1URL

URL（Uniform Resource Locator，統一資源定位符）是互聯網上資源的唯一地址，用于定位網頁、圖片、API 等資源。
類比：就像現實中的“快遞地址”，告訴瀏覽器如何找到目標資源。

一個典型的 URL 格式如下：
https://www.example.com:8080/path/to/page?name=John&age=30#section1
分解為以下核心部分：
[協議]://[域名]:[端口]/[路徑]?[查詢參數]#[錨點]
協議：定義客戶端與服務器之間的通信規則。
域名：將 IP 地址（如?192.168.1.1）轉換為易記的名稱。
端口：標識服務器上的具體服務（類似“門牌號”）。
路徑：指定服務器上的資源位置（類似文件路徑）。
查詢參數：向服務器傳遞附加參數，格式為?key=value。
錨點：定位頁面內的特定位置（不會發送到服務器）。

2.2.2.2urlencode

為了給大家更好展示urlencode是什么，這里附上實際例子，我在瀏覽器搜索你好。

可以看到：

https://www.sogou.com/web?query=%E4%BD%A0%E5%A5%BD&_ast=1745143368&_asf=www.sogou.com&w=01029901&p=40040100&dp=1&cid=&s_from=result_up&sourceid=5_01_03&sessiontime=1745143614785

我們去實際抓包：

可以看到搜多的字符串均被轉義。

URL編碼（Percent-Encoding）是一種將特殊字符和非ASCII字符轉換為安全格式的機制，確保URL在互聯網中正確傳輸和解析。

為什么需要URL編碼？

URL 中本身就有一些特殊符號，代表不同的特殊含義。query string 的內容都是程序員自定義的萬一 query string 里也包含了特殊含義的符號咋辦？所以就需要URL編碼

urlencode 把數據的二進制內容,每個字節取出來十六進制表示,前面加上%

2.2.3認識方法

方法	安全	冪等	典型場景
GET	??	??	獲取資源
POST	??	??	創建資源或觸發操作
PUT	??	??	替換整個資源
DELETE	??	??	刪除資源
PATCH	??	??*	部分更新資源
HEAD	??	??	獲取響應頭信息
OPTIONS	??	??	查詢支持的請求方法
TRACE	??	??	調試（通常禁用）
CONNECT	??	??	建立代理隧道（如 HTTPS）

tips：PATCH 的冪等性需由具體實現保證。?

下文講解幾個最常見的方法?

2.2.3.1GET與POST

HTTP 協議中，GET?和?POST?是最常用的兩種方法，它們在用途、數據傳輸方式、安全性等方面有顯著區別。

GET：通過 URL 傳遞參數

格式：http://example.com/api?name=Alice&age=30

特點：

參數可見，適合非敏感數據（如搜索關鍵字）。

參數會被瀏覽器歷史記錄、服務器日志記錄。

POST：通過請求體傳遞參數

格式：參數封裝在請求體中，支持多種格式（如 JSON、表單數據）。

特點：

參數不可見，適合敏感數據（如密碼、支付信息）。

支持復雜數據結構（如文件上傳）。

兩個典型場景：

登錄。
上傳 =>請求帶有正文的，正文就是保存了當前上傳的數據的內容上述請求中，圖片本身是二進制的，通過特殊方式進行轉碼（base64 編碼，把二進制轉成文本）其實 body 也是可以直接填二進制數據 ~

GET與POST對比：

語義上，二者可以混著用，GET與POST沒有本質區別。
攜帶數據的方式上，POST也可以帶有query string，GET也可以帶有body
GET常被設計成冪等，POST無要求。
GET常認為能被緩存（冪等情況下），而POST不行。

特性 GET POST
用途獲取資源（查詢數據）提交數據（創建或修改資源）
參數位置 URL 查詢字符串（?key=value）請求體（Body）
數據長度限制 受限（URL 長度通常 ≤2048 字符）理論上無限制（取決于服務器配置）
緩存可被瀏覽器緩存不可緩存
冪等性 冪等（多次請求結果相同）非冪等（多次請求可能產生不同結果）
安全性 參數明文暴露在 URL 中（需 HTTPS）參數在請求體中（仍需 HTTPS 加密）
書簽/分享 可保存為書簽或分享鏈接不可直接保存或分享

特性	GET	POST
用途	獲取資源（查詢數據）	提交數據（創建或修改資源）
參數位置	URL 查詢字符串（`?key=value`）	請求體（Body）
數據長度限制	受限（URL 長度通常 ≤2048 字符）	理論上無限制（取決于服務器配置）
緩存	可被瀏覽器緩存	不可緩存
冪等性	冪等（多次請求結果相同）	非冪等（多次請求可能產生不同結果）
安全性	參數明文暴露在 URL 中（需 HTTPS）	參數在請求體中（仍需 HTTPS 加密）
書簽/分享	可保存為書簽或分享鏈接	不可直接保存或分享

2.2.3.2PUT與DELETE

直接開講：

PUT 方法

用途：完整替換資源（客戶端需提供資源的全部新數據）。

特點：

冪等性：多次請求效果相同（重復替換結果一致）。

安全性：非安全操作（修改資源）。

數據位置：請求體中傳遞完整的資源內容。

DELETE 方法

用途：刪除指定資源。

特點：

冪等性：多次刪除同一資源效果相同（刪除后資源不再存在）。

安全性：非安全操作（修改資源）。

數據位置：通常無需請求體，通過 URL 標識資源。

特性 PUT DELETE
目的替換資源（全量更新）刪除資源
冪等性 ??（多次替換結果一致） ??（多次刪除結果一致）
請求體 需要（包含完整新數據）通常不需要
典型狀態碼 200 OK / 201 Created 204 No Content / 200 OK

特性	PUT	DELETE
目的	替換資源（全量更新）	刪除資源
冪等性	??（多次替換結果一致）	??（多次刪除結果一致）
請求體	需要（包含完整新數據）	通常不需要
典型狀態碼	200 OK / 201 Created	204 No Content / 200 OK

這樣，方法中重要的“增刪改查”已經講解完畢。?

2.2.4請求頭關鍵屬性

這邊也是各重頭戲，講到請求頭中各種關鍵屬性，可能跟前文會有所重復，但為了內容完整還是一并寫出。

1. 鍵值對結構
定義：HTTP 頭部以?鍵: 值?的形式組織，鍵與值之間用冒號分隔。（RFC標準文檔）

作用：提供標準化、可擴展的元數據傳遞方式。
示例：
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Content-Type: application/json
注意事項：

鍵不區分大小寫（如?content-type?與?Content-Type?等效）。

多個值可用逗號分隔（如?Accept: text/html, application/json）。
2. Host
定義：指定請求的目標域名和端口（HTTP/1.1 強制要求）。

作用：

區分同一服務器上的多個網站（虛擬主機）。

幫助反向代理或負載均衡器正確路由請求。
示例：
Host: example.com:8080
場景：

訪問?http://example.com?和?http://anotherexample.com?時，服務器通過?Host?頭返回不同內容。
3. Content-Length
定義：表示請求體或響應體（body）的字節長度（十進制數字）。

作用：

服務器/客戶端明確需讀取的數據量，避免粘包問題。

對于?POST?或?PUT?請求，必須準確計算。
示例：
Content-Length: 1024
注意事項：

若使用分塊傳輸（Transfer-Encoding: chunked），無需設置此頭。
4. Content-Type
定義：指示請求體或響應體的媒體類型（MIME 類型）。

作用：

告知服務器如何解析請求體（如 JSON、表單數據）。

指導客戶端（如瀏覽器）如何渲染響應內容。

常見類型：

類型

用途

text/html

HTML 網頁

application/json

JSON 數據

application/x-www-form-urlencoded

表單提交（鍵值對）

multipart/form-data

文件上傳
示例：
Content-Type: application/json; charset=utf-8
5. User-Agent
定義：標識客戶端（如瀏覽器、爬蟲）的類型和版本，里面表示了用戶使用的設備的瀏覽器和操作系統的情況。

作用：

服務器適配不同客戶端（如返回移動端頁面）。

統計用戶設備分布或檢測惡意爬蟲。
示例：
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.1 Mobile/15E148 Safari/604.1
6. Referer
定義：表示當前請求的來源頁面 URL。即這個頁面是從哪個頁面跳轉來的。

作用：

分析流量來源（如廣告點擊統計）。

防盜鏈（限制圖片僅允許從特定網站加載）。
示例：
Referer: https://www.google.com/
注意事項：

隱私模式下或某些瀏覽器可能不發送此頭。
7. Cookie
定義：cookie 就是瀏覽器允許網頁在本地硬盤存儲數據的一種機制，而不是讓網頁代碼直接訪問文件系統（避免風險），而是做了一層抽象。Cookie 這里是按照鍵值對的方式來存儲數據的，瀏覽器中可以直接看到當前頁面保存的 cookie 有哪些的。瀏覽器保存了這些 cookie 之后，就會在后續給服務器發送請求的時候，把這些 cookie 鍵值對放到請求 cookie header 中傳輸給服務器。

作用：

會話管理（如用戶登錄狀態）。

個性化設置（如語言偏好、主題）。
示例：
Cookie: sessionId=abc123; theme=dark