網絡原理-HTTP

應用層自定義協議

自定義協議是指根據特定需求設計的通信規則，用于設備或系統間的數據交換。其核心在于定義數據結構、傳輸方式及處理邏輯。

協議結構示例

典型的自定義協議包含以下部分：

頭部（Header）：標識協議版本、數據長度、校驗碼等元信息。
載荷（Payload）：實際傳輸的數據內容，格式可自定義（如鍵值對、二進制流）。
尾部（Footer）：可選部分，用于標記數據包結束或附加校驗。

自定義協議的流程

根據需要明確信息

根據需求，明確要傳輸什么信息。也就是明確客戶端和用戶端之間要請求和響應的具體信息是什么。

約定好信息組織的格式

行文本的方式:

//一個響應用多行組成，每一行是一個商家
商家id，商家名稱，商家地址\n

通過xml格式來約定：

xml是成對的標簽構成的鍵對值結構，是一種用于存儲和傳輸數據的標記語言。可讀性好但數據冗余信息太多了，會消耗太多的帶寬。

<request><userId>1000</userId><position>75E75N</position>
</request>
<response><shop><id>1</id><name>楊國福</name><image>1.jpg</image><rank>5.0</rank><sendprice>5</sendprice></shop>
</response>

通過json網絡數據格式（主流方式）

是一種輕量級的數據交換格式，采用文本格式存儲和傳輸數據。其結構基于鍵值對和有序列表，易于人閱讀和編寫，也便于機器解析和生成。可讀性好，但相比xml來說依然還有冗余。

{"request": {"userId": 1000,"position": "75E75N"},"response": {"shop": {"id": 1,"name": "楊國福","image": "1.jpg","rank": 5.0,"sendprice": 5}}
}

protobuf

基于二進制編碼，體積小，速度快，支持數據的高效序列化和反序列化。但可讀性差，冗余最小。

syntax = "proto3";message Person {string name = 1;int32 id = 2;repeated string emails = 3; // 重復字段（類似數組）
}

其他

在應用層協議中除了自定義協議的情況下，還有一些大佬已經現成搞好的協議，如：FTP文件傳輸，SSH遠程操作主機，HTTP協議等，還接下里我們將重點取講解HTTP協議，

HTTP（超文本傳輸協議）

HTTP是一種用于傳輸超文本（如HTML）的應用層協議，是萬維網（WWW）數據通信的基礎。它基于客戶端-服務器模型，通過請求-響應機制（一對一）實現資源交換。是當下主流使用的一種應用層協議，像我們平常打開一個網站就是通過HTTP協議來傳輸數據的。

"超?本"的含義,就是傳輸的內容不僅僅是?本(?如html,css這個就是?本),還可以是?些其他的資源,?如圖?,視頻,?頻等?進制的數據。

工作過程

當我們在瀏覽器中輸??個"?址",此時瀏覽器就會給對應的服務器發送?個HTTP請求.對?服務器收到這個請求之后,經過計算處理,就會返回?個HTTP響應。

在實際過程中可能不止一個HTTP請求。響應的交互過程。

HTTP協議格式

需要搭配Fiddler工具（抓包工具）主要用于捕獲、分析和修改HTTP/HTTPS流量，適用于Web開發、測試及網絡安全分析。（這里就不介紹Fiddler工具的使用）。

1.?HTTP 請求格式

請求行（Request Line）[?法]+[url]+[版本]
請求頭（Header）請求的屬性,冒號分割的鍵值對;每組屬性之間使?\n分隔;遇到空?表?Header部分結束
空行（CRLF）
請求體（Body，可選）Body允許為空字符串.如果Body存在,則在Header中會有?個 Content-Length屬性來標識Body的?度

2. HTTP 響應格式
狀態行（Status Line）[版本號]+[狀態碼]+[狀態碼解釋]
響應頭（Header）請求的屬性,冒號分割的鍵值對;每組屬性之間使?\n分隔;遇到空?表?Header部分結束
空行（CRLF）
響應體（Body，可選）Body允許為空字符串.如果Body存在,則在Header中會有?個 Content-Length屬性來標識Body的?度;如果服務器返回了?個html??,那么html??內容就是在body中

總結

HTTP請求(Request)

認識URL

URL（Uniform Resource Locator，統一資源定位符）是互聯網上用于定位資源（如網頁、圖片、文件等）的地址，就像資源的 “唯一坐標”，能讓瀏覽器或其他工具準確找到并獲取它。

URL的基本格式

協議類型:[//服務器地址[:端口號]][/資源層級 UNIX 文件路徑]文件名[?查詢字符串][#片段標識符]

URL的完整格式

協議類型:[//[訪問資源需要的憑證信息@]服務器地址[:端口號]][/資源層級 UNIX 文件路徑]文件名[?查詢字符串][#片段標識符]

URL參數介紹

URL組成參數詳解

以下是基于您提供的內容，以表格形式呈現的URL參數部分詳解。表格嚴格遵循您的原始內容，未做任何修改，僅進行格式化處理。

參數部分	格式示例	含義與作用	常見形式 / 說明
協議類型（Scheme）	http://、https://	指定客戶端與服務器通信的協議規則，決定資源傳輸方式和安全機制	- 常見協議：http（非加密網頁傳輸）、https（加密傳輸，用于隱私場景），可以省略，省略后默認為?`http://。`
[訪問資源需要的憑證信息 @]	user:password@	可選，用于向服務器提供身份驗證的用戶名和密碼	現在的?站進??份認證?般不再通過URL進?了.?般都會省略
服務器地址（Host）	www.example.com、192.168.1.1	標識資源所在的服務器，用于定位目標服務器	- 形式：域名（需 DNS 解析為 IP）或直接 IP 地址（如114.114.114.114 是 URL 中定位服務器的核心標識
[: 端口號]	:8080、:443	服務器上區分不同服務的數字標識（0-65535）	- 默認端口可省略：http默認 80、https默認 443、ftp默認 21 示例：https://example.com:8080表示通過 8080 端口訪問 HTTPS 服務
[/ 資源層級 UNIX 文件路徑]	/blog/2023/articles/	資源在服務器上的存儲路徑，類似本地文件系統的層級結構	- 以 “/” 分隔目錄層級，對應服務器上的文件夾結構<br>- 用于定位資源所在的具體目錄（如子文件夾）
文件名	index.html、photo.jpg	具體資源的名稱，通常包含文件擴展名	- 常見類型：網頁文件（.html）、圖片（.jpg/.png）、文檔（.pdf）等-省略時，服務器可能默認返回index.html等首頁文件（由服務器配置決定）
[? 查詢字符串]	?keyword=url&page=1	客戶端向服務器傳遞的額外參數，用于動態篩選或查詢資源	本質是?個鍵值對結構.鍵值對之間使?&分隔.鍵和值之間使?=分隔.
[# 片段標識符]	#section3	用于定位資源內部的具體位置	- 以 “#” 開頭，對應網頁中的錨點（如<a id="section3">）<br>- 瀏覽器會直接跳轉到該位置，不會將此部分發送給服務器

典型URL示例解析

https://admin:pass123@api.example.com:8443/v1/data?type=user#permissions

協議類型：https:// 表示加密傳輸
憑證信息：admin:pass123@ 提供基礎認證憑據（高風險，僅演示）
服務器地址：api.example.com 指向API服務域名
端口號：:8443 使用非標準HTTPS端口
資源路徑：/v1/data 表示API版本及數據端點
查詢參數：?type=user 篩選用戶類型數據
片段標識：#permissions 跳轉到權限相關章節

URLencode

?是一種將 URL 中不符合規范的字符轉換為特定格式的編碼方式，目的是確保 URL 能被正確傳輸和解析。因為 URL 的某些字符（如空格、特殊符號等）可能被瀏覽器或服務器誤解，或在傳輸中出現歧義，所以需要通過編碼統一格式。

保留字符不編碼
URL 中有一部分字符是 “保留字符”，具有特殊含義（如?: / ? # [ ] @ ! $ & ' ( ) * + , ; =?等），若需作為普通字符使用則需編碼，否則不編碼。

非保留字符不編碼
字母（a-z、A-Z）、數字（0-9）以及部分符號（- _ . ~）屬于 “非保留字符”，無需編碼，直接保留原樣。

其他字符需編碼
除上述兩類外的字符（如空格、中文、特殊符號等），需轉換為?%XX?格式（XX?為該字符的 ASCII 碼十六進制表示）。

示例

在瀏覽器中搜索小黑++

https://www.sogou.com/web?query=%E5%B0%8F%E9%BB%91%2B%2B&_asf=www.sogou.com&_ast=&w=01019900&p=40040100&ie=utf8&from=index-nologin&s_from=index&sourceid=9_01_03&sessiontime=1755002253615 HTTP/1.1

我們會發現這個值%E5%B0%8F%E9%BB%91%2B%2B&通過 urldecode我們會發先這是小黑++的意思。

認識"?法"(method)

HTTP 協議定義了多種請求方法，每種方法對應不同的操作類型，用于客戶端向服務器請求資源或對資源進行操作。

常用的方法：GET,POT,PUT,DELETE

GET 方法

用于從服務器獲取資源。這是最常用的方法，當在瀏覽器中輸入網址訪問網頁，或通過鏈接跳轉頁面時，瀏覽器通常使用 GET 方法向服務器請求資源。

GET 請求的特點：

首行里面的第一個部分就是 GET
URL 里面的 query string 可以為空，也可以不為空
header 有若干個鍵值對結構
body 一般是空的

GET 請求示例：?搜狗首頁請求

POST 方法

用于向服務器提交數據，通常用于創建新資源。比如用戶注冊、登錄時提交表單數據，或者上傳文件等操作，常使用 POST 方法。

POST 請求的特點：

首行第一個部分就是 POST
URL 里面的 query string 一般是空的
header 里面有若干個鍵值對
body 一般不為空（body 的具體數據格式，由 header 中的 Content-Type 來描述；body 的具體數據長度，由 header 中的 Content-Length 來描述

這里的POST請求就不示例了可以自己在可以登錄得網站上自己操作。

GET 和 POST 的區別

語義不同:GET?般?于獲取數據,POST?般?于提交數據.
GET的body?般為空,需要傳遞的數據通過querystring傳遞,POST的querystring?般為空,需要傳遞的數據通過body傳遞
GET請求?般是冪等的,POST請求?般是不冪等的.(如果多次請求得到的結果和一次請求得到的結果?樣,就視為請求是冪等的).
GET可以被緩存,POST不能被緩存.(這?點也是承接冪等性)

認識請求"報頭"(header)

header 的整體的格式也是"鍵值對"結構. 每個鍵值對占??.鍵和值之間使?分號分割

Host

必不可少的報頭，指定請求的目標服務器的域名和端口號（若端口號為默認值 80 或 443，端口號可省略）。例如，Host: www.sogou,com，服務器根據這個報頭確定客戶端請求的具體網站，因為一臺服務器可能托管多個網站。

Content-Length

指明請求體的長度（字節數），服務器根據此長度來準確讀取請求體中的數據。例如，Content - Length: 100?表示請求體的大小為 100 字節。

Content-Type

當請求包含數據（如 POST 請求提交表單數據）時，此報頭指定請求體中數據的類型。

常?選項:

application/x-www-form-urlencoded: form 表單提交的數據格式.此時body的格式形如:

title=test&content=hello

multipart/form-data: form 表單提交的數據格式(在form標簽中加上 enctyped="multipart/form-data" .通常?于提交圖?/?件.body格式形如:

 Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3Trw------WebKitFormBoundaryrGKCBY7qhFd3TrwA 
Content-Disposition: form-data; name="text" 
title ------WebKitFormBoundaryrGKCBY7qhFd3TrwA 
Content-Disposition: form-data; name="file"; filename="chrome.png" 
Content-Type: image/png 
PNG ... content of chrome.png ... ------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

application/json: 數據為json格式.body格式形如:

{"username":"123456789","password":"xxxx","code":"jw7l","uuid":"d110a05ccde64b16

正?中的內容格式和header中的Content-Type密切相關

User-Agent（簡稱 UA）

包含發出請求的客戶端應用程序的相關信息，如瀏覽器類型、版本、操作系統等。

Referer

表?這個??是從哪個??跳轉過來的。

注意：?如果直接在瀏覽器中輸入 URL 或直接通過收藏夾訪問頁面時，是沒有 Referer 的

Cookie

Cookie 中存儲了?個字符串,這個數據可能是客?端(??)??通過JS寫?的,也可能來?于服務器 (服務器在HTTP響應的header中通過Set-Cookie字段給瀏覽器返回數據)

以登錄為例

登錄成功后Cookie會保存一個set-Cookie數據在本地，給用戶一個令牌，再接下來訪問頁面的或下次訪問頁面過程中都會帶上這個令牌，瀏覽器會在 HTTP 請求頭中自動包含這個 Cookie，發送給服務器，表示此時是一個登錄的狀態，最終再返回服務器，同時Cookie令牌也會過期，比如說長時間不操作一個網站，此時令牌過期就會回到登錄狀態，提高安全性。而Cookie中的這些相關數據都是由程序員決定的。

HTTP響應詳解

認識"狀態碼"(statuscode)

狀態碼表?訪問?個??的結果.(是訪問成功,還是失敗,還是其他的?些情況...)，以下將介紹常用的狀態碼。

200OK

這是?個最常?的狀態碼,表?訪問成功

404NotFound

沒有找到資源，列入在瀏覽器中輸?www.sogou.com/index2.html就會看到這樣的響應

403Forbidden

表?訪問被拒絕.有的??通常需要??具有?定的權限才能訪問(登陸后才能訪問).如果??沒有登陸直接訪問,就容易?到403

405 Method Not Allowed

表示訪問的服務器不能支持請求中的方法或者不能使用該請求中的方法

500Internal Server Error

服務器出現內部錯誤.?般是服務器的代碼執?過程中遇到了?些特殊情況(服務器異常崩潰)會產?這個狀態碼

504GatewayTimeout

當服務器負載?較?的時候,服務器處理單條請求的時候消耗的時間就會很?,就可能會導致出現超時的情況

302Movetemporarily

表示臨時重定向

在登陸??中經常會?到302.?于實現登陸成功后?動跳轉到主?.

301 Moved Permanently

表示永久重定向，當瀏覽器收到這種響應時，后續的請求都會被自動改成新的地址

認識響應"報頭"(header)

響應報頭的基本格式和請求報頭的格式基本?致

響應中的Content-Type常?取值有以下?種:?

t ext/html :body數據格式是HTML?
te xt/css :body數據格式是CSS?
a pplication/javascript :body數據格式是JavaScript?
a pplication/json :body數據格式是JSON

正?中的內容格式和header中的Content-Type密切相關就不詳情介紹了可自己使用Fiddler工具去觀察。

通過 form 表單構造 HTTP 請求

form 是 HTML 中的一個表單標簽，可以用于給服務器發送 GET 或者 POST 請求。

form 的重要參數：

action：用來構造 HTTP 請求的 URL 是什么
method：用來構造 HTTP 請求的方法（form 只支持 GET 或 POST 方法）

input 的重要參數在 form 標簽中的含義：

type：表示輸入框的類型（text 表示文本、password 表示密碼、submit 表示提交按鈕）
name：表示構造出的 HTTP 請求的 query string 的 key
value：表示 input 標簽的值（對于 type 為 submit 類型來說，value 就對應了按鈕上顯示的文本）
input 標簽的內容：表示 query string 的 value

通過 ajax 構造 HTTP 請求

還可以通過 ajax 的?式來構造HTTP請求.并且功能更強?

HTTPS

是在HTTP協議的基礎上引?了?個加密層（SSL). HTTP協議內容都是按照?本的?式明?傳輸的.這就導致在傳輸過程中出現?些被篡改的情況,比如說我們常常在瀏覽器下載軟件的時候明明下的不是這個軟件可是下載完就變了，這就是篡改了下載的地址信息。

因此在互聯網上明文傳輸是一件非常可怕的事情。因此要在HTTP基礎上進行加密。

加密"是什么

加密就是把明?(要傳輸的信息)進??系列變換,?成密?. 解密就是把密?再進??系列變換,還原成明?。在這個加密和解密的過程中,往往需要?個或者多個中間的數據,輔助進?這個過程,這樣的數據稱為密鑰。

加密的?式

對稱加密

對稱加密其實就是通過同?個"密鑰",把明?加密成密?,并且也能把密?解密成明?。使用單一密鑰，計算量相對較小，適合對大量數據進行加密處理，能高效地完成加密和解密操作。但是每個服務端需要去對于多個客服端，都是用一個密鑰的話，就會很容易竊取到該密鑰并進行篡改。因此我們針對不同的客戶端要采用不同的密鑰。

非對稱加密

非對稱加密使用一對密鑰，即公鑰和私鑰。公鑰可以公開，任何人都可以使用公鑰對數據進行加密；而私鑰則由用戶自己秘密保存，只有擁有私鑰的人才能對使用相應公鑰加密的數據進行解密。當發送方要向接收方傳輸數據時，發送方使用接收方的公鑰對明文進行加密，然后將密文發送給接收方。接收方收到密文后，使用自己的私鑰進行解密，恢復出原始明文。相比對稱加密，非對稱加密的計算量較大，加密和解密過程需要更多的時間和計算資源。因此，它不太適合對大量數據進行直接加密。

但是這里依然存在問題，我們如何獲取公鑰呢獲取公鑰如何判斷這個公鑰是不是黑客偽造的呢。