本文收錄于 計算機網路,歡迎訂閱,
目錄
- 1、認識Http
- 1.1、什么是Http
- 1.2、什么是超文本
- 1.3、萬維網
- 2、HTTP報文格式
- 2.1、HTTP請求報文格式
- 2.2、HTTP回應報文格式
- 3、使用Cookie在服務器上記錄用戶資訊
- 3.1、Cookie概念
- 3.2、具體程序
- 4、HTTP1.0和HTTP1.1
- 4.1、HTTP1.0
- 4.2、HTTP1.1
- 4.3、HTTP/1.1 和 HTTP/1.0 的區別
- 5、HTTPS
- 5.1、HTTPS概念
- 5.2、HTTPS 的加密方式
- 5.3、HTTP 與 HTTPS 有哪些區別
- 5.4、HTTP 與 HTTPs 的作業方式【建立連接的程序】
1、認識Http
1.1、什么是Http
我們在瀏覽器的地址中輸入某個網站的域名后,就可以訪問該網站的內容,這個就是萬維網WWW應用,其相關的應用層協議為超文本傳送協議HTTP (HyperText Transfer Protocol),

HTTP定義了瀏覽器(即萬維網客戶行程))怎樣向萬維網服務器請求萬維網檔案,以及萬維網服務器怎樣把萬維網檔案傳送給瀏覽器,HTTP 是一個應用層協議,它使用 TCP 連接進行可靠的傳送,
1.2、什么是超文本
在互聯網早期的時候,我們輸入的資訊只能保存在本地,無法和其他電腦進行互動,我們保存的資訊通常都以文本即簡單字符的形式存在,文本是一種能夠被計算機決議的有意義的二進制資料包,而隨著互聯網的高速發展,兩臺電腦之間能夠進行資料的傳輸后,人們不滿足只能在兩臺電腦之間傳輸文字,還想要傳輸圖片、音頻、視頻,甚至點擊文字或圖片能夠進行超鏈接的跳轉,那么文本的語意就被擴大了,這種語意擴大后的文本就被稱為超文本(Hypertext),
1.3、萬維網
概述
- 萬維網 WWW (World Wide Web) 并非某種特殊的計算機網路,
- 萬維網是一個大規模的、聯機式的資訊儲藏所,
- 萬維網用鏈接的方法能非常方便地從互聯網上的一個站點訪問另一個站點,從而主動地按需獲取豐富的資訊,
- 這種訪問方式稱為“鏈接”,
萬維網的作業方式
- 萬維網以客戶 - 服務器方式作業,
- 瀏覽器就是在用戶計算機上的萬維網客戶程式,萬維網檔案所駐留的計算機則運行服務器程式,因此這個計算機也稱為萬維網服務器,
- 客戶程式向服務器程式發出請求,服務器程式向客戶程式送回客戶所要的萬維網檔案,
- 在一個客戶程式主視窗上顯示出的萬維網檔案稱為頁面 (page),

2、HTTP報文格式
2.1、HTTP請求報文格式
HTTP是面向文本的,其報文中的每一個欄位都是一些ASCII碼串,并且每個欄位的長度都是不確定的,HTTP 請求報文由請求行、請求頭部行、空行和物體主體 4 個部分組成,
1、請求行
HTTP請求報文中的“請求行”是由“請求方法”、“URL”和“協議版本”3個欄位組成的,它們之間均以空格進行分隔,這部分是必不可少的,在請求行的最后有一個回車控制符和一個換行控制符(一起以“CRLF”表示),使下面的請求頭部資訊在下一行顯示,
2、請求頭部行
HTTP請求頭部包括一系列的“請求頭”和它們所對應的值,指出允許客戶端向服務器傳遞請求的附加資訊以及客戶端自身的資訊,當打開一個網頁時,瀏覽器要向網站服務器發送一個HTTP請求頭,然后網站服務器根據HTTP請求頭的內容生成當次請求的內容并發送給瀏覽器,這就是HTTP請求報文中的“請求頭”的作用,
3、空行
最后一個請求頭之后是一個空行,發送回車符和換行符,通知服務器以下不再有請求頭;
4、物體主體行
請求報文中“物體主體”部分通常是不用的,它不能在GET方法中使用,僅在POST方法中用于向服務器提供一些用戶憑據資訊(通常不用),

2.2、HTTP回應報文格式
HTTP 回應報文由狀態行、回應頭部、空行 和 物體主體 4 個部分組成,
1、狀態行
狀態行由 HTTP 協議版本欄位、狀態碼和狀態碼的描述文本 3 個部分組成,他們之間使用空格隔開,
2、回應頭部
回應頭向客戶端提供一些額外資訊,比如誰在發送回應、回應者的功能,甚至與回應相關的一些特殊指令,這些頭部有助于客戶端處理回應,并在將來發起更好的請求,回應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate,對回應頭域的擴展要求通訊雙方都支持,如果存在不支持的回應頭域,一般將會作為物體頭域處理,
3、空行
最后一個回應頭部之后是一個空行,發送回車符和換行符,通知服務器以下不再有回應頭部,
4、物體主體
服務器回傳給客戶端的文本資訊,

3、使用Cookie在服務器上記錄用戶資訊
3.1、Cookie概念
早期的萬維網應用非常簡單,僅僅是用戶查看存放在不同服務器上的各種靜態的檔案,因此HTTP被設計為—種無狀態的協議,這樣可以簡化服務器的設計,
現在,用戶可以通過萬維網實作各種復雜的應用,如網上購物、電子商務等,這些應用往往需要萬維網服務器能夠識別用戶,
Cookie提供了一種機制使得萬維網服務器能夠“記住”用戶,而無需用戶主動提供用戶標識資訊,也就是說,Cookie是一種對無狀態的HTTP進行狀態化的技術,
3.2、具體程序
- 1、用戶主機中的瀏覽器向萬維網服務器發送HTTP請求,
- 2、萬維網服務器為該客戶生成一個唯一的Cookie識別碼,并以此為索引在服務器的后端資料庫中創建一個專案,用來記錄該用戶訪問該網站的各種資訊,
- 3、萬維網服務器向用戶主機中的瀏覽器發送HTTP回應,回應體中攜帶設定的Cookie識別碼,
- 4、用戶主機中的瀏覽器從檔案中讀取Cookie,
- 5、用戶主機中的瀏覽器向萬維網服務器發送HTTP請求,并攜帶讀取的Cookie識別碼,
- 6、萬維網服務器根據Cookie識別碼就可以識別出該用戶,并回傳該用戶的個性化網頁,
- 7、萬維網服務器向用戶主機中的瀏覽器發送HTTP回應,

4、HTTP1.0和HTTP1.1
4.1、HTTP1.0
HTTP/1.0采用非持續連接方式,在該方式下,每次瀏覽器要請求一個檔案都要與服務器建立TCP連接,當收到回應后就立即關閉連接,
- 每請求一個檔案就要有兩倍的RTT的開銷,若一個網頁上有很多參考物件(例如圖片等),那么請求每一個物件都需要花費2RTT的時間,
- 為了減小時延,瀏覽器通常會建立多個并行的TCP連接同時請求多個物件,但是,這會大量占用萬
維網服務器的資源,特別是萬維網服務器往往要同時服務于大量客戶的請求,這會使其負擔很重,
4.2、HTTP1.1
HTTP/1.1采用持續連接方式,在該方式下,萬維網服務器在發送回應后仍然保持這條連接
使同一個
客戶(瀏覽器)和該服務器可以繼續在這條連接上傳送后續的HTTP請求報文和回應報文,這并不局限于傳送同一個頁面上參考的物件,而是只要這些檔案都在同一個服務器上就行,
- 為了進一步提高效率,HTTP/1.1的持續連接還可以使用流水線方式作業,即瀏覽器在收到HTTP的回應報文之前就能夠連續發送多個請求報文,這樣的一個接一個的請求報文到達服務器后,服務器就發回一個接一個的回應報文,這樣就節省了很多個RTT時間,使TCP連接中的空閑時間減少,提高了下載檔案的效率,
請求一個萬維網檔案所需要的時間:

4.3、HTTP/1.1 和 HTTP/1.0 的區別
主要區別如下:
-
快取處理: 在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 來做快取判斷的標準,而 HTTP/1.1 請求頭中添加了更多與快取相關的欄位,從而支持更為靈活的快取策略,例如 Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供選擇的快取頭來控制快取策略,
-
節約帶寬: 當客戶端請求某個資源時,HTTP/1.0 默認將該資源相關的整個物件傳送給請求方,但很多時候可能客戶端并不需要物件的所有資訊,而在 HTTP/1.1 的請求頭中引入了 range 頭域,它允許只請求部分資源,其使得開發者可以多執行緒請求某一資源,從而充分的利用帶寬資源,實作高效并發,
-
錯誤通知的管理: HTTP/1.1 在 1.0 的基礎上新增了 24 個錯誤狀態回應碼,例如 414 表示客戶端請求中所包含的 URL 地址太長,以至于服務器無法處理;410 表示所請求的資源已經被永久洗掉,
-
Host 請求頭: 早期 HTTP/1.0 中認為每臺服務器都系結一個唯一的 IP 地址并提供單一的服務,請求訊息中的 URL 并沒有傳遞主機名,而隨著虛擬主機的出現,一臺物理服務器上可以存在多個虛擬主機,并且它們共享同一個 IP 地址,為了支持虛擬主機,HTTP/1.1 中添加了 host 請求頭,請求訊息和回應訊息中應宣告這個欄位,若請求訊息中缺少該欄位時服務端會回應一個 404 錯誤狀態碼,
-
長連接: HTTP/1.0 默認瀏覽器和服務器之間保持短暫連接,瀏覽器的每次請求都需要與服務器建立一個 TCP 連接,服務器完成后立即斷開 TCP 連接,HTTP/1.1 默認使用的是持久連接,其支持在同一個 TCP 請求中傳送多個 HTTP 請求和回應,此之前的 HTTP 版本的默認連接都是使用非持久連接,如果想要在舊版本的 HTTP 協議上維持持久連接,則需要指定 Connection 的首部欄位的值為 Keep-Alive,
5、HTTPS
5.1、HTTPS概念
HTTPS(Hypertext Transfer Protocol Secure:超文本傳輸安全協議)是一種透過計算機網路進行安全通信的傳輸協議,HTTPS 經由 HTTP 進行通信,但利用 SSL/TLS 來加密資料包,HTTPS 開發的主要目的,是提供對網站服務器的身份認證,保護交換資料的隱私與完整性,
HTTPS 默認作業在 TCP 協議443埠,它的作業流程一般如以下方式:
- 1、TCP 三次同步握手
- 2、客戶端驗證服務器數字證書
- 3、DH 演算法協商對稱加密演算法的密鑰、hash 演算法的密鑰
- 4、SSL 安全加密隧道協商完成
- 5、網頁以加密的方式傳輸,用協商的對稱加密演算法和密鑰加密,保證資料機密性;用協商的hash演算法進行資料完整性保護,保證資料不被篡改,
5.2、HTTPS 的加密方式
HTTPS 采用對稱加密和非對稱加密相結合的方式,首先使用 SSL/TLS 協議進行加密傳輸,為了彌補非對稱加密的缺點,HTTPS 采用證書來進一步加強非對稱加密的安全性,通過非對稱加密,客戶端和服務端協商好之后進行通信傳輸的對稱密鑰,后續的所有資訊都通過該對稱秘鑰進行加密解密,完成整個 HTTPS 的流程,
5.3、HTTP 與 HTTPS 有哪些區別
- 1、HTTP 是超文本傳輸協議,資訊是明文傳輸,存在安全風險的問題,HTTPS 則解決 HTTP 不安全
的缺陷,在 TCP 和 HTTP 網路層之間加入了 SSL/TLS 安全協議,使得報文能夠加密傳輸,
- 2、HTTP 連接建立相對簡單, TCP 三次握手之后便可進行 HTTP 的報文傳輸,而 HTTPS 在 TCP
三次握手之后,還需進行 SSL/TLS 的握手程序,才可進入加密報文傳輸,
-
3、HTTP 的埠號是 80,HTTPS 的埠號是 443,
-
4、HTTPS 協議需要向 CA(證書權威機構)申請數字證書,來保證服務器的身份是可信的

5.4、HTTP 與 HTTPs 的作業方式【建立連接的程序】
HTTP
HTTP(Hyper Text Transfer Protocol: 超文本傳輸協議) 是一種簡單的請求 - 回應協議,被用于在 Web 瀏覽器和網站服務器之間傳遞訊息,HTTP 使用 TCP(而不是 UDP)作為它的支撐運輸層協議,其默認作業在 TCP 協議 80 埠,HTTP 客戶機發起一個與服務器的 TCP 連接,一旦連接建立,瀏覽器和服務器行程就可以通過套接字介面訪問 TCP,客戶機從套接字介面發送 HTTP 請求報文和接收 HTTP 回應報文,類似地,服務器也是從套接字介面接收 HTTP 請求報文和發送 HTTP 回應報文,其通信內容以明文的方式發送,不通過任何方式的資料加密,當通信結束時,客戶端與服務器關閉連接,
HTTPS
HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)是以安全為目標的 HTTP 協議,在 HTTP 的基礎上通過傳輸加密和身份認證的方式保證了傳輸程序的安全性,其作業流程如下:
① 客戶端發起一個 HTTPS 請求,并連接到服務器的 443 埠,發送的資訊主要包括自身所支持的演算法串列和密鑰長度等;
② 服務端將自身所支持的所有加密演算法與客戶端的演算法串列進行對比并選擇一種支持的加密演算法,然后將它和其它密鑰組件一同發送給客戶端,
③ 服務器向客戶端發送一個包含數字證書的報文,該數字證書中包含證書的頒發機構、過期時間、服務端的公鑰等資訊,
④ 最后服務端發送一個完成報文通知客戶端 SSL 的第一階段已經協商完成,
⑤ SSL 第一次協商完成后,客戶端發送一個回應報文,報文中包含一個客戶端生成的隨機密碼串,稱為 pre_master_secre,并且該報文是經過證書中的公鑰加密過的,
⑥ 緊接著客戶端會發送一個報文提示服務端在此之后的報文是采用pre_master_secre 加密的,
⑦ 客戶端向服務端發送一個 finish 報文,這次握手中包含第一次握手至今所有報文的整體校驗值,最終協商是否完成取決于服務端能否成功解密,
⑧ 服務端同樣發送與第 ⑥ 步中相同作用的報文,已讓客戶端進行確認,最后發送 finish 報文告訴客戶端自己能夠正確解密報文,
當服務端和客戶端的 finish 報文交換完成之后,SSL 連接就算建立完成了,之后就進行和 HTTP 相同的通信程序,唯一不同的是在 HTTP 通信程序中并不是采用明文傳輸,而是采用對稱加密的方式,其中對稱密鑰已經在 SSL 的建立程序中協商好了,

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/327942.html
標籤:其他
上一篇:安信可 ESP32-S3 模組上驅動攝像頭 OV2640,實作遠程拍照并 HTTP 傳輸到阿里云物件存盤OSS,并顯示在微信小程式上。(深度好文,全部開源)
下一篇:漫畫:什么是 “時間管理” ?
