?🎁個人主頁:我們的五年
🔍系列專欄:Linux網絡編程
🌷追光的人,終會萬丈光芒
🎉歡迎大家點贊👍評論📝收藏?文章
?
Linux網絡編程筆記:
https://blog.csdn.net/djdjiejsn/category_12885098.html
前言:
前面講了HTTP的請求,響應格式。但是里面的知識點還沒有細講。報文里面的內容沒有講。這篇就是對HTTP的詳細講解。
目錄
1.簡單信息
1.1HTTP的基本信息:
1.2URL網址:
2.請求格式:
2.1基本格式:?
3.請求方法:
3.1GET方法:
3.2POST方法:
3.3PUT方法:
3.4HEAD方法:
3.5DELETE方法:
3.6OPTIONS方法:
4.HTTP響應狀態碼(了解):
4.1:1開頭的狀態碼
4.2:2開頭的狀態碼
4.3:3開頭的狀態碼
4.3:4開頭的狀態碼
?4.3:5開頭的狀態碼
5.重定向:
6.報頭header
6.2關于session
6.3關于connection
1.簡單信息
1.1HTTP的基本信息:
HTTP的英文是:(HyperText? Transfer? Protocol)超文本傳輸協議首字母的縮寫。
超文本可以添加鏈接,有了鏈接,就可以從一個網站到另一個網站,可以傳輸圖片,視頻,音頻,
超文本(Hypertext)是一種通過鏈接將文本的不同部分或不同文本之間相互連接的文本結構。
超文本最重要的部分就是鏈接功能了。
HTTP協議就是定義了瀏覽器(客戶端Client)和服務器(服務端Server)的協議。HTTP是瀏覽器和服務器之間通信的基礎。客戶端給服務器發送請求,然后服務器收到以后,對請求進行處理,然后給客服端回響應。響應的可能是服務器上的資源(GET方法),或者提交資源(POST方法)……
HTTP是無連接的,無狀態的協議,每次請求都要建立新的連接,服務器也不會保存客戶端的信息。對于網站讓我們登錄進去可以,就認識我們了,以后每次請求都認識我們了,是服務器里面cookie的功勞。
1.2URL網址:
然后URL網址的基本信息,之前也講過了,Encode,DeCode,下面的圖講的也是非常的清楚。
關于Encode,DeCode就可以去看這篇文章:
【Linux網絡編程】:URL(encode),HTTP協議,telnet工具-CSDN博客
2.請求格式:
基本的格式這篇文章也講了:(點擊進入就可以)
【Linux網絡編程】:URL(encode),HTTP協議,telnet工具-CSDN博客
2.1基本格式:?
基本格式就是是這樣,然后就是講里面的具體參數了。
請求報頭Header會有一個參數Content-Length來標識請求正文的長度。
空行后面的內容就是請求正文。
3.請求方法:
請求方法有很多種,用了區分請求是要干什么,服務器要知道客戶端要干什么才有后面的。
雖然請求有很多種,但是每種不可能都執行,大部分都是不允許的,比如向服務器上次資源(百度網盤,這種服務方向的除外),基本的是不允許隨便上傳,或者再向寫文章,在抖音上產視頻,也只是開放了部分的資源。部分接口。在合理,正常功能內上傳資源,刪除資源肯定是沒問題了。
下面的表格由Kimi生成。
序號 | 請求方法 | 描述 |
---|---|---|
1 | GET | 請求指定的頁面信息,并返回實體主體。通常用于獲取數據,不會對數據進行更改。 |
2 | HEAD | 類似于GET請求,但只返回HTTP報頭,不返回文檔主體。常用于檢查資源是否存在或獲取資源的元數據。 |
3 | POST | 向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中,可能會導致新的資源的建立和/或已有資源的修改。 |
4 | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。如果資源不存在,可能會創建新的資源。 |
5 | DELETE | 請求服務器刪除指定的頁面或資源。 |
6 | CONNECT | 把請求連接轉換到透明的TCP/IP通道,通常用于代理服務器或建立HTTPS連接。 |
7 | OPTIONS | 返回服務器支持的HTTP方法。常用于跨域資源共享(CORS)的預檢請求。 |
8 | TRACE | 回顯服務器收到的請求,主要用于測試或診斷。 |
9 | PATCH | 對資源進行部分修改,實體中包含一個表,表中說明與該URI所表示的原內容的區別。 |
10 | MOVE | 請求服務器將指定的頁面移至另一個網絡地址。 |
11 | COPY | 請求服務器將指定的頁面拷貝至另一個網絡地址。 |
12 | LINK | 請求服務器建立鏈接關系。 |
13 | UNLINK | 請求服務器斷開鏈接關系。 |
14 | WRAPPED | 允許客戶端發送經過封裝的請求。 |
15 | Extension-method | 在不改動協議的前提下,可增加另外的方法。 |
3.1GET方法:
🍟作用:用于請求URL的指定資源。
🍟示例:GET(請求方法)? ? ? ? ? ? ?/index.html(URL)? ? ? ? ? ? ? HTTP/1.1(HTTP版本)。(請求行,要請求的就是服務器下面的iindex.html,當然可以對這個路徑進行解析,在開頭增加目錄)。
🍟特性:指定資源經服務器端解析后返回響應內容。
3.2POST方法:
🍟用途:用于傳輸實體的主體,通常用于提交表單數據。
🍟示例:POST? ? ? ? ? ? ? ? ? ?submit.cgi? ? ? ? ? ? ? ? ? ? ? ?HTTP/1.1
🍟特性:可以發送大量的數據給服務器,并且數據包含在請求體中。
3.3PUT方法:
🍟用途:用于傳輸文件,將請求報文主體中的文件保存到請求 URL 指定的位置。
🍟示例:PUT? ? ? ? ? ? ? ? ? ? ? /example.html? ? ? ? ? ? ? ? ? ? ? ? HTTP/1.1
🍟特性:不太常用,但在某些情況下,如 RESTful API 中,用于更新資源。
3.4HEAD方法:
🍟用途:與 GET 方法類似,但不返回報文主體部分,僅返回響應頭。
🍟示例:HEAD /index.html HTTP/1.1
🍟特性:用于確認 URL 的有效性及資源更新的日期時間等。
3.5DELETE方法:
🍟用途:用于刪除文件,是 PUT 的相反方法。
🍟示例:DELETE? ? ? ? ? ? ? ? ? ? ? ? ?/example.html? ? ? ? ? ? ? ? ? ? ? ? HTTP/1.1
🍟特性:按請求 URL 刪除指定的資源。
3.6OPTIONS方法:
🍟用途:用于查詢針對請求 URL 指定的資源支持的方法。
🍟示例:OPTIONS? ? ? ? ? ?*? ? ? ? ? ? ? ? ? ? ? ? ?HTTP/1.1
🍟特性:返回允許的方法,如 GET、POST 等。
4.HTTP響應狀態碼(了解):
雖然定了規定的狀態碼,但是各個瀏覽器器直接沒有好好的遵循。各個瀏覽器之間是競爭關系,狀態碼也各不一樣。對于對于狀態碼瀏覽器來說,狀態碼也沒那么重要。
所以在不同的瀏覽器之間,相同的狀態碼表示不同的信息。
前端工作人員可能也不會嚴格遵循,畢竟還要做兼容性檢查。不同狀態碼也能被解釋。
4.1:1開頭的狀態碼
1xx(信息性狀態碼):請求已被接受,正在繼續處理。
具體的看下表:
100,主要是在上傳大型文件的時候,表示服務器已經接受到了,正在處理。
狀態碼 | 狀態 | 說明 |
---|---|---|
100 | 繼續 | 請求者應當繼續提出請求。服務器已收到請求的第一部分,正在等待其余部分。 |
101 | 切換協議 | 請求者已要求服務器切換協議,服務器已確認并準備切換。 |
102 | 繼續執行 | 由WebDAV擴展的狀態碼,代表處理將被繼續執行。 |
103 | 早期提醒 | 利用服務器思考時間來傳遞內容,當瀏覽器向服務器發出請求時等待回應時,由邊緣網絡線發送頁面載入提示給瀏覽器。 |
4.2:2開頭的狀態碼
2xx(成功狀態碼):請求已成功被服務器處理。
狀態碼 | 狀態 | 說明 |
---|---|---|
200 | 成功 | 服務器已成功處理了請求,通常表示服務器提供了請求的網頁。 |
201 | 已創建 | 請求成功并且服務器創建了新的資源。 |
202 | 已接受 | 服務器已接受請求,但尚未處理。 |
203 | 非授權信息 | 服務器已成功處理了請求,但返回的信息可能來自另一來源。 |
204 | 無內容 | 服務器成功處理了請求,但沒有返回任何內容。 |
205 | 重置內容 | 服務器成功處理了請求,但沒有返回任何內容,要求客戶端重置視圖。 |
206 | 部分內容 | 服務器成功處理了部分GET請求。 |
207 | 多種狀態 | 由WebDAV狀態碼,代表之后的消息體將是一個XML消息,且可能依照之前子請求數量不同,含一系列獨立的響應代碼 |
4.3:3開頭的狀態碼
3xx(重定向狀態碼):客戶端需要進一步操作才能完成請求
狀態碼 | 狀態 | 說明 |
---|---|---|
300 | 多種選擇 | 針對不同請求,服務器可執行多種操作。 |
301 | 永久移動 | 請求的網頁已永久移動到新位置。 |
302 | 資源已找到(臨時移動) | 告訴客戶端,請到另一處URL獲取需要的資源。 |
303 | 查看其他位置 | 請求者應當對不同的位置使用單獨的GET請求來獲取資源。 |
304 | 資源未修改 | 自從上次請求后,網頁未做過修改。 |
305 | 使用代理 | 請求者只能使用代理訪問所請求的資源。 |
307 | 臨時重定向 | 服務器臨時重定向請求到另一個URL。 |
308 | 永久重定向 | 請求的資源永久移動,客戶端應使用新URL |
4.3:4開頭的狀態碼
請求有錯誤,客戶端可能需要修改請求
狀態碼 | 狀態 | 說明 |
---|---|---|
400 | 請求錯誤 | 請求有語法錯誤。 |
401 | 未授權 | 請求未授權。 |
403 | 禁止 | 服務器拒絕執行。 |
404 | 未找到 | 請求的資源不存在。 |
405 | 方法不允許 | 請求方法不被允許。 |
406 | 不接受 | 服務器無法提供請求的資源。 |
407 | 需要代理認證 | 需要代理服務器認證。 |
408 | 請求超時 | 請求超時。 |
409 | 沖突 | 請求與資源的當前狀態沖突。 |
410 | 已刪除 | 請求的資源已被永久刪除。 |
411 | 需要長度 | 服務器拒絕處理當前請求,因為請求的內容長度未定義。 |
412 | 先決條件失敗 | 服務器在驗證請求的頭字段中給出的先決條件時,未能滿足其中的一個或多個。 |
413 | 負載過大 | 請求提交的實體數據大小超過了服務器愿意或能夠處理的范圍。 |
414 | URI過長 | 請求的URI長度超過了服務器能夠解釋的長度。 |
415 | 不支持的媒體類型 | 請求中提交的實體并不是服務器中所支持的格式。 |
416 | 范圍不符合 | 請求的范圍不符合。 |
417 | 期望失敗 | 在請求頭Expect中指定的預期內容無法被服務器滿足。 |
422 | 不可處理的實體 | 請求格式正確,但服務器無法處理。 |
429 | 請求過多 | 客戶端在給定的時間內發送了過多的請求 |
?4.3:5開頭的狀態碼
5xx(服務器錯誤狀態碼):服務器在處理請求時發生了錯誤
狀態碼 | 狀態 | 說明 |
---|---|---|
500 | 內部服務器錯誤 | 服務器內部錯誤。 |
501 | 未實現 | 服務器無法處理請求。 |
502 | 錯誤網關 | 無效的網關。 |
503 | 服務不可用 | 服務器暫時不可用。 |
504 | 網關超時 | 網關超時。 |
505 | HTTP版本不支持 | 服務器不支持請求的HTTP版本 |
5.重定向:
重定向有兩種,一種是臨時重定向,還有一種是永久重定向。不管是永久重定向還有臨時重定向,都是和報頭中的location有關的,當請求的URL需要重定向到新的URL時,header就會帶location信息。
比如下面就是302臨時重定向,錯誤碼描述是Found,然后需要重定向到https://www.new-url.com。(這里)
HTTP/1.1? ? ? ?302? ? ? ? ?Found\r\n
Location: https://www.new-url.com\r\n
6.報頭header
報文里面可能下面以下信息,也可以一個都沒有,比如有正文body,但是沒有Content,瀏覽器一樣可以解釋,瀏覽器還是很厲害的。
然后就是我們可以根據請求的資源區分是什么類型的文本,HTML還是TXT,還是其他的。
Content-Type: 數據類型(text/html 等)。
Content-Length: Body 的長度。
Host: 客戶端告知服務器, 所請求的資源是在哪個主機的哪個端口上;User-Agent: 聲明用戶的操作系統和瀏覽器版本信息;
referer: 當前頁面是從哪個頁面跳轉過來的;
Location: 搭配 3xx 狀態碼使用, 告訴客戶端接下來要去哪里訪問;
Cookie: 用于在客戶端存儲少量信息. 通常用于實現會話(session)的功能;
6.1關于cookie:
cookie會保存我們的信息,比如我們登陸一個網站,輸入了用戶名,密碼。下次訪問這個網站的時候,就直接把這些信息加到HTTP請求里面。我們就不需要進行登錄了,然后就可以查看這些信息了,當然這些信息我們解析不出來是什么。
6.2關于session
session的話,就是防止我們的信息泄露,再保存了cookie信息的時候,只用代號進行傳輸,當然代號也可以被盜走,但至少我們具體的用戶名,信息不會盜走。也就是可能黑客可以登錄盜走的QQ,但是沒有辦法知道密碼,進行改密碼。
6.3關于connection
?這個就表示連接的信息:需要長連接還是短連接。HTTP1.1版本默認使用長連接,即報頭沒有connection信息的時候,就是和服務器建立長的連接。HTTP1.0使用的是短連接,要長連接需要再報頭中加入Connection: keep-alive。
HTTP/1.1:在 HTTP/1.1 協議中,默認使用持久連接。當客戶端和服務器都不明確指定關閉連接時,連接將保持打開狀態,以便后續的請求和響應可以復用同一個連接。
HTTP/1.0:在 HTTP/1.0 協議中,默認連接是非持久連接。如果希望在 HTTP/1.0上實現持久連接,需要在請求頭中顯式設置 Connection: keep-alive。