URI作為HTTP請求的定位標識符，本質(zhì)是應(yīng)用層對資源的抽象地址。從通信模型看，它經(jīng)歷了多層封裝：用戶輸入URI后，瀏覽器先解析出協(xié)議、主機和路徑；DNS將主機名解析為IP地址；TCP層建立連接；最終HTTP報文發(fā)出時，URI被放在請求行的第二字段。HTTP/1.1要求URI不超過8000字符，過長的URI可能被服務(wù)器拒絕。另外URI中的查詢參數(shù)在傳輸時會被URL編碼，這增加了字節(jié)開銷，但又是必須的合規(guī)操作。

1. OSI/RM 分層視角

• 應(yīng)用層（HTTP）

Request-URI 是 HTTP 請求行（Request-Line）的核心組成部分，格式為：GET /api/data?user=123 HTTP/1.1

其中 /api/data?user=123 即 Request-URI，包含：路徑（/api/data）：標識服務(wù)器上的資源位置；查詢參數(shù)（?user=123）：傳遞附加信息（編碼在 URI 中）；片段標識符（#section，不發(fā)送到服務(wù)器）：客戶端本地使用。

• 傳輸層（TCP）

URI 中的 主機名（Host） 通過 DNS 解析為 IP 地址，建立 TCP 連接（默認端口 80/443）。例如：https://example.com/api → DNS 解析為 93.184.216.34:443 → 建立 TLS over TCP 連接。

• 網(wǎng)絡(luò)層（IP）

TCP 分段封裝為 IP 數(shù)據(jù)包，目標地址為 DNS 解析出的 IP。

2. 核心通信功能

資源尋址：URI 唯一標識服務(wù)器上的資源（如文件、API 端點），服務(wù)器根據(jù)路徑映射到物理/邏輯資源。

示例：/images/logo.png → Web 服務(wù)器映射到文件系統(tǒng)的 /var/www/images/logo.png。 

請求路由：反向代理（如 Nginx）根據(jù) URI 路徑將請求轉(zhuǎn)發(fā)到后端服務(wù)：

nginx

location /api/ {

    proxy_pass http://backend-server;

}

參數(shù)傳遞：查詢字符串（Query String）以鍵值對傳遞參數(shù)：

GET /search?q=keyword&page=2 → 服務(wù)器解析 q 和 page 參數(shù)。

協(xié)議協(xié)商：URI Scheme（http://、https://）決定是否啟用 TLS 加密。

3. 關(guān)鍵通信約束

• 長度限制

瀏覽器：約 2000 字符（舊版 IE 僅 2083）。

服務(wù)器：Nginx 默認 8096 字符，Apache 默認 8190。

超長 URI 可能被截斷或返回 414 URI Too Long。

• 編碼規(guī)則

URI 必須進行 Percent-Encoding（百分號編碼）以傳輸特殊字符：

空格 → %20，中文字符 → %E4%B8%AD。

未編碼的非法字符（如空格）會導致協(xié)議解析錯誤。

• Host 頭分離

在 HTTP/1.1 后，主機名從 URI 移至 Host 頭部：GET /index.html HTTP/1.1

Host: www.example.com

實現(xiàn)單 IP 多域名托管（虛擬主機）。

4. 與通信效率的關(guān)系

• 冗余 vs 可讀性

URI 是人類可讀的語義化標識，但增加了傳輸開銷（尤其長參數(shù)），需權(quán)衡設(shè)計。優(yōu)化方案： 對長參數(shù)使用 POST + Body（如 JSON）。

• 緩存機制

完整 URI（含參數(shù)）作為緩存鍵值：api/data?user=1 和 api/data?user=2 會被分別緩存。

• CDN 分發(fā)

CDN 節(jié)點按 URI 緩存資源，相同 URI 請求命中邊緣節(jié)點，減少源站壓力。

5. URI vs URL vs URN

URI（統(tǒng)一資源標識符）：廣義資源標識（含 URL 和 URN）。

URL（統(tǒng)一資源定位符）：包含訪問機制的 URI（如 http://）。

URN（統(tǒng)一資源名稱）：永久資源名（如 urn:isbn:0451450523），無定位功能。

通信中的 Request-URI 本質(zhì)是 URL：它同時提供 資源名稱 和 訪問方式。