當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

计算机网络 | 应用层：HTTP协议详解

發布時間：2024/4/11 编程问答 33 豆豆

生活随笔收集整理的這篇文章主要介紹了计算机网络 | 应用层：HTTP协议详解小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

自定制協議

協議，即是約定，是計算機網絡中進行數據交換而建立的規則、標準或約定的集合。
對于我們自己編寫的應用程序，知名協議未必能夠滿足我們的需求，所以我們應該結合自己應用的特點，來定制一個更合適的協議。

如何自定制協議呢？簡單來說，就是根據數據的格式和描述信息，來指定一個序列化（加密），反序列化（解析）的過程。

序列化：將多個數據對象按照指定的協議進行組織成為持久化存儲/數據傳輸的二進制數據串
反序列化：將二進制數據串通過指定的協議進行解析得到各個的數據對象

源端通過自己定義的協議，將數據按照某種方法進行序列化成二進制數據串。對端接受數據時，只有按照這個協議反序列化才能解析出原來的數據。

常用的序列化方法：結構體二進制序列化，json序列化，protobuf序列化等

雖然我們可以自己定義協議，但是計算機界有一句話，“不要重復造輪子”，已經有很多大佬制定了一些非常實用的協議供我們直接實用，例如HTTP,FTP等，所以若非必要，可以直接使用這些協議。

這里就主要介紹HTTP協議。

HTTP協議

HTTP協議，即超文本傳輸協議，是用于從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。下面就來介紹HTTP的組成與特性

HTTPS協議，現在幾乎使用的都是HTTPS，HTTPS基于HTTP協議，通過SSL或TLS提供加密處理數據，其實就是披著SSL外殼的HTTP協議，其本質還是HTTP。

URL

一提到HTTP協議，少不了的就是最重要的URL
URL：即統一資源定位符，用于在網絡中定位某臺主機上的某一個資源，也就是我們通常所說的網址。
那么是怎么通過URL來定位資源的呢？
URL由以下幾部分組成
協議://用戶名:密碼@服務器ip地址:服務器端口/文件路徑?查詢字符串#片段標識符

協議：請求需要使用的協議，現在通常為http,https
用戶名密碼：認證用戶的用戶名密碼，為了安全一般都不會顯示。
服務器地址：這里通常都不會是ip地址，而是域名，通過域名解析服務器就能夠得到服務器的ip地址。
服務器端口:http協議的端口默認是80，但也可以選擇其他的，默認是不顯示的。
文件路徑：即請求的資源在服務器上的路徑
查詢字符串：客戶端請求中的額外參數，由key=value的鍵值對組成，以&作為分隔符
片段標識符：html的標簽id，可以直接跳轉到頁面的某個位置

更詳細的可以參考這篇博客
快速搞懂URL的構成

這里就拿b站舉例子

同時對于?,#,/,:等特殊字符，會通過urlencode的方式進行轉義。轉義的規則如下:
將需要轉碼的字符轉為16進制，然后從右到左，取4位(不足4位直接處理)，每2位做一位，前面加上%，編碼成%XY格式

HTTP協議的特點

1. HTTP是無連接：
無連接的含義是限制每次連接只處理一個請求。服務端處理客戶端的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。

2. HTTP是靈活的：
只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。通過頭部中的Content-Type來標記正在傳輸的類型

3. HTTP是無狀態的
無狀態是指對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態，即我們給服務器發送 HTTP 請求之后，服務器會根據請求給我們發送數據過來，但是發送完后不會記錄任何信息。
無狀態是一把雙刃劍，如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。而如果服務器不需要先前信息時，它的應答就較快。

HTTP協議版本

HTTP協議有四個版本，分別是0.9、1.0、1.1、2.0。現在大部分用的都是1.1版本

0.9版本：這時的http協議沒有標準格式，僅用于傳輸html（超文本標記語言）數據，而且只有get方法。并且連接方式為短連接
短連接：建立連接，發送一個請求，得到相應后關閉連接

1.0版本:1.0版本正式規定了HTTP協議格式，并且增加了多重請求方法，并且支持不同文件格式的數據流，同時部分應用商已經開始使用長連接（受限制的長連接）
1.0定義了三種請求方法： GET, POST 和 HEAD方法。
長連接：一次連接可以發送多條請求

1.1版本：增加了更多的請求方法和頭部描述信息，并支持了長連接和管線化傳輸。
1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法
管線化傳輸：可以連續發送多個請求，只需要按順序響應就行，不需要響應后才發下一個請求。
但是還存在約束條件，響應的順序必須與請求的順序保持一致，通過隊列實現，如果不一致則在隊首阻塞。

2.0版本：采用二進制流傳輸，并且進行多路復用，允許服務端主動推送數據
多路復用：響應順序可以與請求的順序不一致，因為頭部中標識了對應的請求信息。提高了信道的利用率

3.0版本：
在3.0版本中HTTP采取了革命性的變化，其將網絡協議從TCP切換至QUIC (Quick UDP Internet Connections), 快速 UDP 互聯網連接。 PS:QUIC是基于UDP協議的。

QUIC協議主要解決了兩個問題

線頭阻塞問題：基于TCP的HTTP2.0的多路復用機制，盡管從邏輯上來說，不同的流之間相互獨立，不會相互影響，但在實際傳輸方面，數據還是要一幀一幀的發送和接收，一旦某一個流的數據有丟包，則同樣會阻塞在它之后傳輸的流數據傳輸。而基于UDP的QUIC協議則可以更為徹底地解決這樣的問題，讓不同的流之間真正的實現相互獨立傳輸，互不干擾。

切換網絡時的連接保持：當前移動端的應用環境，用戶的網絡可能會經常切換，比如從辦公室或家里出門，WiFi斷開，網絡切換為移動網絡。基于TCP的協議，由于切換網絡之后，IP會改變，因而之前的連接不可能繼續保持。而基于UDP的QUIC協議，則可以內建與TCP中不同的連接標識方法，從而在網絡完成切換之后，恢復之前與服務器的連接。

HTTP協議格式

這里我用fiddler來抓取瀏覽器中http的數據進行分析

HTTP請求

HTTP響應

從上面抓取的數據分析，HTTP主要有以下四個部分組成，首行，頭部，空行，正文，并且請求和響應報文細節上都不同。
第一行為首行，緊接著是頭部，之后通過一個空行間隔，接下來的則是正文
下面一一分析。

首行

請求首行

[請求方法][URL][協議版本]\r\n
如：

請求方法

共有GET,、POST 、HEAD、OPTIONS、PUT、PATCH、DELETE、TRACE 、CONNECT 等方法。

各種請求的功能

GET：請求指定的頁面信息，并返回實體主體。
HEAD：類似于 GET 請求，只不過返回的響應中沒有具體的內容，用于獲取報頭
POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT：從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE：請求服務器刪除指定的頁面。
CONNEC：HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。
OPTIONS ：允許客戶端查看服務器的性能。
TRACE：回顯服務器收到的請求，主要用于測試或診斷。
PATCH：是對 PUT方法的補充，用來對已知資源進行局部更新。

響應首行

[協議版本][響應狀態碼][響應狀態碼描述]\r\n
如：

響應狀態碼

響應狀態碼：表示對于本次請求，服務端做出的響應結果。
例如我們常見的404

1**：信息，服務器收到請求，需要請求者繼續執行操作
2**：成功，操作被成功接收并處理。常見：200
3**：重定向，需要進一步的操作以完成請求。常見：301（永久重定向）、302（臨時重定向）
4**：客戶端錯誤，請求包含語法錯誤或無法完成請求。常見：400（請求錯誤）、404（資源不存在）
5**：服務器錯誤，服務器在處理請求的過程中發生了錯誤。常見：500（服務器內部錯誤）、502（代理請求失敗/無效響應）、504（代理請求超時）

狀態碼描述：對狀態碼的描述信息，可自定義。

頭部

請求頭部：描述本次請求的關鍵字段信息，由key:value形式的鍵值對組成，并且每個鍵值對以\r\n作為結尾
如：

響應頭部：描述本次響應的關鍵字段信息，由key:value形式的鍵值對組成，并且每個鍵值對以\r\n作為結尾
如：

HTTP常用的Header

Content-Type: 數據類型;
Content-Length: 正文的長度 ;
Transfer-Encoding:實體正文的傳輸方式;
Expires:緩存過期時間;
Referer: 當前頁面是從哪個頁面跳轉過來的;
Location: 3xx重定向的新地址;
Host: 客戶端告知服務器,所請求的資源是在哪個主機的哪個端口上;
User-Agent: 聲明用戶的操作系統和瀏覽器版本信息;
Set-Cookie：客戶端通過Set-cookie向客戶端傳遞的信息，會被保存在客戶端瀏覽器的cookie文件中;
Cookie: 客戶端上保存的數據，客戶端每次通信時從cookie文件中讀取數據，并通過cookie字段向服務端傳遞信息（用于維持客戶端狀態信息）
Session:服務端為客戶端創建的會話，會話信息中描述了客戶端的身份認證信息和狀態信息，保存在服務端，可以通過cookie將session id返回給客戶端，客戶端每次通信都會通過cookie傳輸帶有自己session的id。

Cookie與Session

因為HTTP是無狀態的，但在實際情況中，我們還是需要保持狀態的
那么如何讓HTTP來保持狀態呢，答案就是借助Cookie和Session。
舉個例子，正好明天就是618,618作為一個大型的購物節，在一天的不同時間段，不同店鋪中，會有著許多不同的活動，為了達到最大折扣，我們通常會在一天內多次進入如淘寶、京東等購物網站進行購物，但是因為HTTP是無狀態的，所以它并不會記錄我們的任何信息，所以我們在每次訪問時都需要重新登陸來確認用戶的身份，這是一種很麻煩的事情。所以大佬們為HTTP加入了Cookie來幫助其維持狀態，在每次通信后，會將服務端的一些臨時驗證信息保存在客戶端的cookie文件中。這樣下次通信時，就可以通過讀取cookie中保存的驗證信息，將其傳遞給服務端，來維持客戶端的狀態，這樣就可以避免多次登錄。

但是Cookie的使用不夠安全，因為Cookie保存在客戶端(瀏覽器）。而如果將這些重要的信息保存在本地，則很容易就會被腳本、爬蟲等截取，造成不必要的損失，所以Cookie需要搭配Session使用。

Session其實就是服務端為客戶端創建的會話，其中描述了客戶端的身份認證信息和狀態信息，并且將其保存在服務端。服務端每次通信結束后都會將Session id（本次會話的ID）保存在客戶端的Cookie中，客戶端在下次通信時通過Cookie將保存的Session id傳遞給服務端，這樣服務端就可以通過對應的Session id來查找到客戶端的身份認證信息和狀態信息，來為客戶端維持狀態，這樣就可以避免重復登錄。并且因為Cookie和Session分別保存在客戶端和服務端，保證了一定的安全性。

Cookie與session的區別是什么？
Cookie保存在客戶端上，是一些臨時存儲的數據，用于持續與服務端進行信息傳遞的一種手段。

Session保存在服務端上，是一種會話的控制，會話信息中包含客戶端的身份狀態信息，通過Cookie傳遞Session id來查找到對應的身份狀態信息，來實現狀態維持。

空行

空行即為\r\n，用于間隔頭部和正文。因為頭部的每一個鍵值對以\r\n結束，所以一旦連續接受到兩個\r\n的時候就代表著頭部的接收結束。

正文

請求正文

客戶端提交的數據

如上面的：

響應正文

服務端響應的實體資源
如：

這里顯示為亂碼的原因是因為這里用的是https協議，該協議會對響應的內容加密，中間者無法直接查看明文內容

總結

以上是生活随笔為你收集整理的计算机网络 | 应用层：HTTP协议详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：高级数据结构与算法 | 二叉搜索树（Bi
下一篇：计算机网络 | 传输层：UDP与TCP