HTTP/HTTPS協(xié)議詳解

這篇具有很好參考價值的文章主要介紹了HTTP/HTTPS協(xié)議詳解。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

目錄

?一. HTTP詳解

?1.1 概念

?1.2 HTTP的協(xié)議格式

1.2.1 HTTP請求體格式：

1.2.2 HTTP響應(yīng)體格式：

?1.3 HTTP請求方法

?1.4 認(rèn)識請求報頭

?1.5 HTTP請求過程?

?1.6?認(rèn)識狀態(tài)碼

二. HTTPS詳解

?2.1 HTTPS簡介

?2.2 HTTPS加密過程

TCP/UDP是位于傳輸層的一種協(xié)議，而HTTP/HTTPS是位于應(yīng)用層的的一中協(xié)議；

?一. HTTP詳解

?1.1 概念

HTTP 協(xié)議一般指 HTTP（超文本傳輸協(xié)議），超文本傳輸協(xié)議（英語：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議，是因特網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)傳輸協(xié)議，所有的 WWW 文件都必須遵守這個標(biāo)準(zhǔn)。HTTP 是為 Web 瀏覽器與 Web 服務(wù)器之間的通信而設(shè)計的，但也可以用于其他目的，HTTP 是一個基于 TCP/IP 通信協(xié)議來傳遞數(shù)據(jù)的（HTML 文件、圖片文件、查詢結(jié)果等）。

?1.2 HTTP的協(xié)議格式

想要更好的看清HTTP的格式，我們可以通過抓包工具來解析，這里我推薦大家使用Fiddler進(jìn)行抓包，親測好用，下載鏈接：

Fiddler | Web Debugging Proxy and Troubleshooting Solutions (telerik.com)https://www.telerik.com/fiddler我們通過訪問百度來進(jìn)行抓包，打開 Fiddler 我們可以看到：

1.2.1 HTTP請求體格式：

?我們通過 Fiddler 來打開請求體可以看到：

1.2.2 HTTP響應(yīng)體格式：

?我們通過 Fiddler 來打開響應(yīng)體可以看到：

其實我們不難發(fā)現(xiàn)，HTTP響應(yīng)的Body里就是HTML的本體，瀏覽器拿到了這個響應(yīng)，也就拿到了HTML里面的所以信息，就可以顯示了；

?1.3 HTTP請求方法

根據(jù) HTTP 標(biāo)準(zhǔn)，HTTP 請求可以使用多種請求方法；

序號方法描述

1 GET 請求指定的頁面信息，并返回實體主體。

2 HEAD 類似于 GET 請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報頭

3 POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中。POST 請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。

4 PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。

5 DELETE 請求服務(wù)器刪除指定的頁面。

6 CONNECT HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

7 OPTIONS 允許客戶端查看服務(wù)器的性能。

8 TRACE 回顯服務(wù)器收到的請求，主要用于測試或診斷。

9 PATCH 是對 PUT 方法的補充，用來對已知資源進(jìn)行局部更新。

這里最常用的就是 GET 和 POST 方法了；通俗點說 GET 就是從服務(wù)器里拿了什么數(shù)據(jù)，POST 就是往服務(wù)器里提交了什么數(shù)據(jù)，在我們?nèi)粘Ｊ褂弥?，絕大部分情況下我們都是GET，只有少部分會 POST ,舉一個最常見的例子，我們登錄或者上傳文件的時候就是最常見的 POST 請求，GET 的 Body 一般為空，而 POST 的 Body 一般不為空，但是這個也不是絕對的；GET 是可緩存的，而 POST 不能；

序號	方法	描述
1	GET	請求指定的頁面信息，并返回實體主體。
2	HEAD	類似于 GET 請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報頭
3	POST	向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中。POST 請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
5	DELETE	請求服務(wù)器刪除指定的頁面。
6	CONNECT	HTTP/1.1 協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
7	OPTIONS	允許客戶端查看服務(wù)器的性能。
8	TRACE	回顯服務(wù)器收到的請求，主要用于測試或診斷。
9	PATCH	是對 PUT 方法的補充，用來對已知資源進(jìn)行局部更新。

?1.4 認(rèn)識請求報頭

1）Host：表示服務(wù)器主機(jī)的地址和端口.

2）Content-Length：表示 body 中的數(shù)據(jù)長度.

?

3）Content-Type：表示請求的 body 中的數(shù)據(jù)格式

4）User-Agent (簡稱 UA)：表示瀏覽器/操作系統(tǒng)的屬性

5）Referer：表示這個頁面是從哪個頁面跳轉(zhuǎn)過來的.

6）Cookie：Cookie 中存儲了一個字符串, 這個數(shù)據(jù)可能是客戶端(網(wǎng)頁)自行通過 JS 寫入的, 也可能來自于服務(wù)器(服務(wù)器在 HTTP 響應(yīng)的 header 中通過 Set-Cookie 字段給瀏覽器返回數(shù)據(jù)）；

關(guān)于Cookie的幾個點：

1. Cookie 從哪里來？

是從服務(wù)器來的，當(dāng)我們的瀏覽器訪問服務(wù)器的時候，服務(wù)器就會在HTTP響應(yīng)中，通過 Set-Cookie 字段，把Cookie的鍵值對返回給瀏覽器，瀏覽器收到這個數(shù)據(jù)，就會保存到瀏覽器的本地存儲；

2. Cookie到哪里去？

會在下次請求的時候把Cookie再帶給服務(wù)器；

3.?Cookie有什么用？

是瀏覽器本地存儲數(shù)據(jù)的機(jī)制；

?1.5 HTTP請求過程?

HTTP請求過程實際上是一問一答的方式，就是瀏覽器向服務(wù)器發(fā)起請求，服務(wù)器會返回請求對應(yīng)的數(shù)據(jù)包給瀏覽器；

?1.6?認(rèn)識狀態(tài)碼

1）200 OK

這是一個最常見的狀態(tài)碼, 表示訪問成功，這里通過抓包可以看見；

?2）404 Not Found
404表示沒有找到資源，比如我們在百度的網(wǎng)址后面加個abc子目錄，這里就會提示沒有找到資源，因為百度的服務(wù)器上面沒有你想要的東西，所以服務(wù)器不能返回給你想要的數(shù)據(jù)；

3）?403 Forbidden

表示訪問被拒絕. 有的頁面通常需要用戶具有一定的權(quán)限才能訪問(登陸后才能訪問). 如果用戶沒有登陸，直接訪問, 就容易見到 403，通俗點來說就是你沒有訪問的權(quán)限；

4）500 Internal Server Error
服務(wù)器出現(xiàn)內(nèi)部錯誤. 一般是服務(wù)器的代碼執(zhí)行過程中遇到了一些特殊情況(服務(wù)器異常崩潰)會產(chǎn)生這個狀態(tài)碼；

5）504 Gateway Timeout
當(dāng)服務(wù)器負(fù)載比較大的時候, 服務(wù)器處理單條請求的時候消耗的時間就會很長, 就可能會導(dǎo)致出現(xiàn)超時的情況；

6）302 Move temporarily

臨時重定向（下次要不要繼續(xù)重定向，這是不確定的）

重定向：就是訪問舊的地址，被自動引導(dǎo)到一個新的地址上；

舉個例子：假設(shè)我有一個用了好長時間的手機(jī)號碼，我現(xiàn)在想換個新的號碼，但是別人不知道我換了新的號碼，所以就設(shè)置了一下，別人撥打我的舊手機(jī)號碼時候，我讓他自動跳轉(zhuǎn)到新的號碼，這樣我就可以接到電話了；
?

7）301 Moved Permanently

永久重定向（一直都重定向了，以后都重定向了）

二. HTTPS詳解

?2.1 HTTPS簡介

其實 HTTP 和 HTTPS 沒有太大的本質(zhì)區(qū)別，他們可以說是一對孿生兄弟，只不過 HTTPS在 HTTP 的基礎(chǔ)上進(jìn)行了加密；

?2.2 HTTPS加密過程

?1）對稱加密

首先，客戶端生成一個密鑰key，通過key對所發(fā)送的數(shù)據(jù)進(jìn)行加密，然后發(fā)送到服務(wù)器端，服務(wù)器端接收到之后，進(jìn)行解密，再返回響應(yīng)的響應(yīng)給客戶端，這一切看似平靜祥和，但是如果中間出現(xiàn)一個黑客，在你轉(zhuǎn)發(fā)的路由節(jié)點對這個key進(jìn)行截獲，也是輕而易舉的事情，那么數(shù)據(jù)的安全性就得不到保障了；所以這里又引入了非對稱加密；

2）非對稱加密

非對稱加密要用到兩個密鑰, 一個叫做 "公鑰", 一個叫做 "私鑰"；

公鑰和私鑰是配對的. 最大的缺點就是運算速度非常慢，比對稱加密要慢很多；
通過公鑰對明文加密, 變成密文
通過私鑰對密文解密, 變成明文

對于非對稱加密的工作流程是這樣的：

1.客戶端的目的的是想要自己的對稱密鑰key安全的傳輸給服務(wù)器；

2.首先客戶端向服務(wù)器端索要公鑰，然后服務(wù)器端把公鑰返回給客戶端，此時如果中間有黑客劫持的話，他也得到了公鑰pub；

3.客戶端使用pub對key進(jìn)行加密，再發(fā)送給服務(wù)器端，但是此時黑客并不能截獲這個key，因為這個key是被pub加密過的，只有服務(wù)器的私密pri才可以解開；

4.服務(wù)器端使用私密pri進(jìn)行解密，得到了客戶端發(fā)來的key；

3）證書加密

對于上述的非對稱加密，看似是安全了，其實還是存在漏洞的，假設(shè)中間有黑客想要攔截數(shù)據(jù)，在第一步的過程中，服務(wù)器端返回公鑰給客戶端，黑客通過自己生成一對非對稱密鑰，把自己的公鑰返回給客戶端，這樣一來，數(shù)據(jù)的安全性又得不到保障了；這里也就引入了證書加密進(jìn)行安全的保障；證書這個東西是具有權(quán)威的官方機(jī)構(gòu)下發(fā)的，黑客對此也束手無策，因此這樣保證了安全性；

4）總結(jié)整個過程：

步驟1：客戶端向服務(wù)器發(fā)送 HTTPS 請求

當(dāng)客戶端需要從服務(wù)器獲取數(shù)據(jù)時，它會向服務(wù)器發(fā)送一個 HTTPS 請求。這個請求包括請求的 URL、HTTP 請求頭和請求體；

步驟2：服務(wù)器將公鑰證書發(fā)送給客戶端

當(dāng)服務(wù)器接收到 HTTPS 請求后，它會將公鑰證書發(fā)送給客戶端，公鑰證書中包含了服務(wù)器的公鑰、服務(wù)器的域名、證書頒發(fā)機(jī)構(gòu)、證書有效期等信息，客戶端接收到證書后，會從中提取出服務(wù)器的公鑰；

步驟3：客戶端驗證服務(wù)器的證書

客戶端接收到服務(wù)器的證書后，會對其進(jìn)行驗證，以確保該證書是由可信任的證書頒發(fā)機(jī)構(gòu)頒發(fā)的，并且證書中的域名和服務(wù)器的實際域名一致，如果證書驗證失敗，客戶端會中斷連接。如果驗證通過，客戶端會生成一個用于會話的對稱密鑰；

步驟4：客戶端生成一個用于會話的對稱密鑰

客戶端生成一個用于會話的對稱密鑰。對稱密鑰是一種加密方式，它使用相同的密鑰進(jìn)行加密和解密。這個密鑰只存在于客戶端和服務(wù)器之間，因此被稱為“對稱”。

步驟5：客戶端使用服務(wù)器的公鑰對對稱密鑰進(jìn)行加密，并將加密后的密鑰發(fā)送給服務(wù)器

客戶端使用服務(wù)器的公鑰對對稱密鑰進(jìn)行加密，并將加密后的密鑰發(fā)送給服務(wù)器。在這個過程中，客戶端和服務(wù)器都知道對稱密鑰，但是只有客戶端知道對稱密鑰的值。

步驟6：服務(wù)器使用私鑰對客戶端發(fā)送的加密密鑰進(jìn)行解密，得到對稱密鑰

服務(wù)器使用私鑰對客戶端發(fā)送的加密密鑰進(jìn)行解密，得到對稱密鑰。由于私鑰只在服務(wù)器端保存，因此只有服務(wù)器才能解密客戶端發(fā)送的加密密鑰，并得到對稱密鑰的值；

步驟7：服務(wù)器和客戶端使用對稱密鑰進(jìn)行加密和解密數(shù)據(jù)傳輸

服務(wù)器和客戶端使用對稱密鑰進(jìn)行加密和解密數(shù)據(jù)傳輸。這個對稱密鑰只存在于客戶端和服務(wù)器之間，因此對數(shù)據(jù)的加密和解密只有客戶端和服務(wù)器可以進(jìn)行；

文章來源地址http://www.zghlxwxcb.cn/news/detail-451258.html