目錄

HTTP協(xié)議

HTTP協(xié)議的工作過程

首行

請求頭（header）

HOST

Content-Length?編輯

User-Agent（簡稱UA）

Referer

Cookie

空行

正文（body）

HTTP響應(yīng)詳解

狀態(tài)碼

報(bào)文格式

HTTP響應(yīng)格式

如何構(gòu)建HTTP請求

form

Ajax（阿加克斯）

Postman

HTTPS

加密

對稱加密

非對稱加密

證書

---

HTTP協(xié)議

HTTP (全稱為 "超文本傳輸協(xié)議") 是一種應(yīng)用非常廣泛的應(yīng)用層協(xié)議。HTTP往往是基于傳輸層的 TCP 協(xié)議實(shí)現(xiàn)的。(HTTP1.0，HTTP1.1，HTTP2.0均為TCP，HTTP3 基于 UDP 實(shí)現(xiàn)) 目前我們主要使用的還是 HTTP1.1 和 HTTP2.0（本文基于HTTP1.1來介紹）。我們平時(shí)打開一個(gè)網(wǎng)站, 就是通過 HTTP 協(xié)議來傳輸數(shù)據(jù)的。

當(dāng)我們在瀏覽器中輸入一個(gè) 搜狗搜索的 "網(wǎng)址" (URL) 時(shí)，瀏覽器就給百度的服務(wù)器發(fā)送了一個(gè) HTTP 請求，搜狗的服務(wù)器返回了一個(gè) HTTP 響應(yīng)。

這個(gè)響應(yīng)結(jié)果被瀏覽器解析之后，就展示成我們看到的頁面內(nèi)容。(這個(gè)過程中瀏覽器可能會給服務(wù)器發(fā)送多個(gè) HTTP 請求，服務(wù)器會對應(yīng)返回多個(gè)響應(yīng)，這些響應(yīng)里就包含了頁面 HTML，CSS，JavaScript，圖片，字體等信息)。

HTTP協(xié)議的工作過程

當(dāng)我們在瀏覽器中輸入一個(gè) "網(wǎng)址"，此時(shí)瀏覽器就會給對應(yīng)的服務(wù)器發(fā)送一個(gè)HTTP 請求，對方服務(wù)器收到這個(gè)請求之后, 經(jīng)過計(jì)算處理, 就會返回一個(gè)HTTP響應(yīng)。

HTTP協(xié)議的交互詳細(xì)過程，可以借助第三方工具來看到，被稱作“抓包”工具。抓包工具有很多，我們在這里使用Fiddler（費(fèi)德樂）。

?Fiddler本質(zhì)是一個(gè)代理程序，可能和別的代理程序沖突，使用的時(shí)候要關(guān)閉別的代理程序。

想要正確抓包，還需要開啟https功能，需要手動啟用一下https并且安裝證書~

雙擊這個(gè)需要抓包的網(wǎng)頁，進(jìn)入到raw中，我們查看這個(gè)http請求最原始的效果。點(diǎn)擊View in Notepad可以在記事本中打開。

當(dāng)前的http請求，其實(shí)是一個(gè)行文本格式的數(shù)據(jù)。相比于tcp這種二進(jìn)制格式來說，更加方便用戶直接觀察。

HTTP請求可以認(rèn)為是四個(gè)部分：

首行

首行里有HTTP的方法、URL、版本號

方法有很多，但是實(shí)際開發(fā)中，最常見的就是兩個(gè)方法：GET、POST。

如果是GET請求，沒有body。但是如果是POST請求，一般都有body。并且POST的body是程序員自定義的內(nèi)容。而POST最典型的就是登錄，登錄跳轉(zhuǎn)的時(shí)候會涉及到POST，另一個(gè)就是上傳文件。

GET和POST之間的典型區(qū)別：

1.GET可以給服務(wù)器傳遞一些信息，GET傳遞的信息一般都是放在query string，POST傳遞消息一般都是在body（也可以完全使用GET提交，使用POST獲取，大多是使用習(xí)慣上的區(qū)別）

2.GET請求一般都是用于從服務(wù)器獲取數(shù)據(jù)，POST一般是用于給服務(wù)器提交數(shù)據(jù)。

3.GET通常會被設(shè)計(jì)成冪等，POST則不需要。（每次輸入的都是同樣的數(shù)據(jù)，那么輸出的結(jié)果每次也都一樣就是冪等）

4.GET可以被緩存，POST則一般不能被緩存（就是把請求的結(jié)果保存下來，下次請求就不必真請求了，直接取緩存結(jié)果了）

URL：

對于一個(gè)網(wǎng)址：https://www.baidu.com/

URL，也就是唯一資源定位符，標(biāo)識互聯(lián)網(wǎng)上的唯一的資源的位置，也就是這個(gè)資源在哪個(gè)服務(wù)器的哪個(gè)目錄下的哪個(gè)文件。

URL最關(guān)鍵的四個(gè)部分：

1.域名/IP

2.端口號

3.帶層次的路徑

4.查詢字符串

同時(shí)，一個(gè)URL的幾個(gè)部分是可以省略的，以百度來說，https://www.baidu.com/

省略了端口，此時(shí)瀏覽器會提供默認(rèn)端口，http默認(rèn)是80，https默認(rèn)是443。

URL 中的可省略部分

協(xié)議名: 可以省略，省略后默認(rèn)為 http://。

ip 地址 / 域名: 在 HTML中可以省略(比如 img, link, script, a 標(biāo)簽的 src 或者 href 屬性)。省略后表示服務(wù)器的 ip / 域名與當(dāng)前 HTML 所屬的 ip / 域名一致.

端口號: 可以省略。省略后如果是 http 協(xié)議，端口號自動設(shè)為 80；如果是 https 協(xié)議，端口號自動設(shè)為 443。

帶層次的文件路徑: 可以省略，省略后相當(dāng)于 / 。有些服務(wù)器會在發(fā)現(xiàn) / 路徑的時(shí)候自動訪問 /index.html

查詢字符串: 可以省略

片段標(biāo)識: 可以省略

HTTP/1.1： HTTP的版本號，這里是1.1

請求頭（header）

請求頭中包含了許多內(nèi)容：

HOST

大概描述了服務(wù)器所在的地址和端口，HOST這里的地址和端口，用來描述最終要訪問的目標(biāo)。

這個(gè)內(nèi)容大概率和URL是一樣的，也可能不同~

Content-Length

User-Agent（簡稱UA）

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0

UA描述了瀏覽器和操作系統(tǒng)的版本，現(xiàn)在的UA主要用于區(qū)分PC端網(wǎng)頁和移動端網(wǎng)頁~

Referer

當(dāng)前頁面的來源，如果直接通過地址欄輸入地址或者是直接點(diǎn)擊收藏夾都沒referer。

Cookie

這是非常重要的header屬性，本質(zhì)上是瀏覽器給網(wǎng)頁提供的本地存儲數(shù)據(jù)的機(jī)制。因?yàn)榫W(wǎng)頁默認(rèn)是不允許訪問計(jì)算機(jī)的硬盤的，cookie瀏覽器對于訪問硬盤做出了明確的限制，并且通過鍵值對的方式來組織數(shù)據(jù)~

Cookie是從哪來的？

Cookie中的數(shù)據(jù)來自服務(wù)器，服務(wù)器會通過HTTP響應(yīng)的報(bào)頭部分來決定瀏覽器的Cookie要存什么。

Cookie是在哪存的？

存在硬盤，Cookie在存的時(shí)候，是按照瀏覽器+域名維度來進(jìn)行細(xì)分的。不同的瀏覽器各自存各自的Cookie，同一個(gè)瀏覽器的不同的域名，對應(yīng)不同的Cookie。并且Cookie的內(nèi)容不光是鍵值對，還有過期時(shí)間，有很多網(wǎng)站，登陸一次后可以自動記憶登錄狀態(tài)，這可能是基于Cookie來實(shí)現(xiàn)~

Cookie要到哪去？

當(dāng)瀏覽器保存好Cookie之后，后續(xù)再給服務(wù)器發(fā)送請求的時(shí)候，就會自動帶上這樣的Cookie~

Cookie就像是服務(wù)器在瀏覽器中搞的寄存處一樣~

空行

正文（body）

正文中的內(nèi)容格式和 header 中的 Content-Type 密切相關(guān)。

1) application/x-www-form-urlencoded

2) multipart/form-data

3) application/json

HTTP響應(yīng)詳解

狀態(tài)碼

狀態(tài)碼描述了這次的響應(yīng)結(jié)果。

常見的狀態(tài)碼：

200 OK? ?

這是一個(gè)最常見的狀態(tài)碼，表示訪問成功。

404 Not Found

沒有找到資源。

瀏覽器輸入一個(gè) URL，目的就是為了訪問對方服務(wù)器上的一個(gè)資源。如果這個(gè) URL 標(biāo)識的資源不存在，那么就會出現(xiàn) 404。

例如，在瀏覽器中輸入 www.sogou.com/index.html，此時(shí)就在嘗試訪問 sogou 上的 /index.html 這個(gè)資源。如果輸入正確，則可以正確訪問到。但是如果輸入錯(cuò)誤，比如 www.sogou.com/index2.html，就會看到 404 這樣的響應(yīng)。

403?Forbidden

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

405 Method Not Allowed

前面我們已經(jīng)學(xué)習(xí)了 HTTP 中所支持的方法，有GET、POST、PUT、DELETE等。但是對方的服務(wù)器不一定都支持所有的方法(或者不允許用戶使用一些其他的方法)。

500 Internal Server Error

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

504 Gateway Timeout

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

302 Move temporarily

臨時(shí)重定向：302這樣的相應(yīng)報(bào)文中，會在leader里帶有一個(gè)Location屬性，通過這個(gè)屬性來描述要跳轉(zhuǎn)到哪個(gè)新的地址。

舉個(gè)例子，當(dāng)我們申請了一個(gè)域名后，過段時(shí)間需要更換域名，此時(shí)訪問老域名通過重定向就能夠訪問老域名自動跳轉(zhuǎn)到新的域名~

這么多狀態(tài)碼可以分成幾類：

2開頭：成功

3開頭：重定向

4開頭：客戶端錯(cuò)誤

5開頭：服務(wù)器錯(cuò)誤

報(bào)文格式

HTTP響應(yīng)格式

相應(yīng)的格式和請求的格式基本相同，具體的內(nèi)容有些許不同。

響應(yīng)報(bào)頭：響應(yīng)報(bào)頭的基本格式和請求報(bào)頭的格式基本一致. 類似于 Content-Type , Content-Length 等屬性的含義也和請求中的含義一致。

Content-Type 響應(yīng)中的 Content-Type 常見取值有以下幾種:

text/html : body 數(shù)據(jù)格式是 HTML

text/css : body 數(shù)據(jù)格式是 CSS

application/javascript : body 數(shù)據(jù)格式是 JavaScript

application/json : body 數(shù)據(jù)格式是 JSON

響應(yīng)正文：正文的具體格式取決于 Content-Type。

1) text/html

2) text/css

3) application/javascript

4) application/json

如何構(gòu)建HTTP請求

form

可以通過form標(biāo)簽來構(gòu)造一個(gè)HTTP GET請求。

我們構(gòu)建的這個(gè)請求沒有特殊的需求，只是訪問百度的主頁。之后咱們自己寫服務(wù)器代碼就可以根據(jù)需要來獲取url中的query string，從而完成不同的功能。

通過抓包可以獲取到raw文本，我們構(gòu)建的http請求除了首行之外剩下的部分都是瀏覽器自己添加的。

也可以構(gòu)造一個(gè)HTTP POST請求。

對于form構(gòu)造的post請求來說，body里面的數(shù)據(jù)格式和query string是非常相似的，也是鍵值對結(jié)構(gòu)，鍵值對之間使用&來分割，鍵和值之間使用=來分割。

要注意，form標(biāo)簽只能構(gòu)造GET和POST，無法構(gòu)造PUT、DELETE、OPTIONS等方法的請求。

Ajax（阿加克斯）

這是瀏覽器提供的一種通過js構(gòu)造http請求的方式。Ajax全稱Asynchronous Javascript And XML，也就是異步JavaScript和XML。

簡單地說，通過Ajax發(fā)起http請求，不必等待服務(wù)器相應(yīng)回來，就可以立刻往下執(zhí)行，當(dāng)服務(wù)器的響應(yīng)回來后再通過瀏覽器反饋到代碼中。

使用Ajax技術(shù)網(wǎng)頁應(yīng)用能夠快速地將增量更新呈現(xiàn)在用戶界面上，而不需要重載（刷新）整個(gè)頁面，這使得程序能夠更快地回應(yīng)用戶的操作。

和form相比，Ajax功能更強(qiáng)：

1.支持PUT、DELETE等方法。

2.Ajax發(fā)送的請求可以靈活設(shè)置header。

3.Ajax發(fā)送的請求的body也是可以靈活設(shè)置的。

我們主要通過jquery提供的Ajax來在代碼中使用Ajax，這個(gè)api針對原生的api封裝過，所以使用起來比較簡單。

通過jquery cdn來獲取到ajax源碼后引入到j(luò)s中，然后就看可以開始Ajax代碼的編寫了。

jquery中，$是一個(gè)特殊的全局對象，jquery的api都是以$的方式來引出的。在這里Ajax的參數(shù)就是一個(gè)js對象，是大括號表示的鍵值對。于是我們開始運(yùn)行一下這個(gè)代碼：

注意！這個(gè)代碼直接執(zhí)行只能看到構(gòu)造的請求，無法獲取到正確的響應(yīng)~

因?yàn)榘l(fā)送給百度的服務(wù)器后，服務(wù)器沒有正確處理我們的請求，就會出現(xiàn)無法獲取到響應(yīng)，之后我們能自己寫服務(wù)器后，就可以自己給自己的服務(wù)器發(fā)請求，就能夠處理了。

雖然JS本身不能直接控制操作系統(tǒng)的線程，但是瀏覽器在實(shí)現(xiàn)Ajax的時(shí)候在內(nèi)部使用了多線程。

Postman

還有一個(gè)更加方便的構(gòu)造http請求的方式，使用Postman。

可以通過手動構(gòu)造的方式來完成構(gòu)造，在Params添加相關(guān)的信息，點(diǎn)擊Send就能把構(gòu)建好的http請求發(fā)送到服務(wù)器上。

同時(shí)也可以通過一鍵構(gòu)造，可以生成構(gòu)造請求的代碼，方便咱們在自己的程序中集成~

HTTPS

HTTPS 也是一個(gè)應(yīng)用層協(xié)議。是在 HTTP 協(xié)議的基礎(chǔ)上引入了一個(gè)加密層。因?yàn)镠TTP 協(xié)議內(nèi)容都是按照文本的方式明文傳輸?shù)?#xff0c;這就導(dǎo)致在傳輸過程中出現(xiàn)一些被篡改的情況。

于是HTTP+安全層（SSL/TLS）就成為了HTTPS。

網(wǎng)絡(luò)上如果都是明文傳輸數(shù)據(jù)，是非常危險(xiǎn)的~所以就需要加密才能保證安全。

加密

加密就是把明文（要傳輸?shù)男畔?#xff09;進(jìn)行一系列變換，生成密文。解密就是把密文再進(jìn)行一系列變換，還原成明文。

在這個(gè)加密和解密的過程中，往往需要一個(gè)或者多個(gè)中間的數(shù)據(jù)，輔助進(jìn)行這個(gè)過程，這樣的數(shù)據(jù)稱為密鑰。

對稱加密

進(jìn)行安全傳輸，核心就是“加密”。加密其中一種最有效的辦法，叫做“對稱加密”。與其類似的叫做“非對稱加密”。

一個(gè)簡單的對稱加密：按位異或。 假設(shè)明文a = 1234，密鑰 key = 8888，則加密 a ^ key 得到的密文 b 為 9834。然后針對密文 9834 再次進(jìn)行運(yùn)算 b ^ key，得到的就是原來的明文 1234。

同一個(gè)密鑰，既可以用來加密，也可以用來解密。所以也叫做對稱密鑰。

對稱加密的前提是，密鑰不能被黑客知道。

由于黑客不知道密鑰是什么，所以即使黑客截獲了加密的數(shù)據(jù)也得不到解密后的數(shù)據(jù)。

但是服務(wù)器同時(shí)會服務(wù)很多個(gè)客戶端，這些客戶端都需要有不同的密鑰。

比較理想的做法，就是能在客戶端和服務(wù)器建立連接的時(shí)，雙方協(xié)商確定這次的密鑰是什么。

但是如果黑客從一開始就入侵了路由器，豈不是最開始黑客就能獲取到密鑰了？加密還有什么意義呢？所以我們需要再最開始雙方協(xié)商密鑰是什么的時(shí)候就把密鑰給加密。

此時(shí)我們需要用到“非對稱加密”。

非對稱加密

非對稱加密要用到兩個(gè)密鑰，一個(gè)叫做 "公鑰", 一個(gè)叫做 "私鑰"。

公鑰和私鑰是配對的，最大的缺點(diǎn)就是運(yùn)算速度非常慢，比對稱加密要慢很多。所以往往只是第一次商定密鑰的時(shí)候使用非對稱加密。

公鑰是公開的，私鑰是不公開的。

• 客戶端在本地生成對稱密鑰, 通過公鑰加密, 發(fā)送給服務(wù)器.
• 由于中間的網(wǎng)絡(luò)設(shè)備沒有私鑰, 即使截獲了數(shù)據(jù), 也無法還原出內(nèi)部的原文, 也就無法獲取到對稱密鑰
• 服務(wù)器通過私鑰解密, 還原出客戶端發(fā)送的對稱密鑰. 并且使用這個(gè)對稱密鑰加密給客戶端返回的響應(yīng)數(shù)據(jù).
• 后續(xù)客戶端和服務(wù)器的通信都只用對稱加密即可. 由于該密鑰只有客戶端和服務(wù)器兩個(gè)主機(jī)知道, 其他主機(jī)/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒有意義.?

服務(wù)器生成一對公鑰私鑰，客戶端從服務(wù)器拿到公鑰，黑客也能拿到。

客戶端通過公鑰給對稱密鑰加密，黑客獲取到加密過后的秘鑰卻沒有私鑰，所以無法解開。

服務(wù)器拿到加密后的密文后，通過私鑰解開，這樣就得到了對稱密鑰。

此時(shí)客戶端和服務(wù)器就可以使用這個(gè)對稱密鑰來進(jìn)行后續(xù)數(shù)據(jù)傳輸了。

接下來的問題又來了：

客戶端如何獲取到公鑰?

客戶端如何確定這個(gè)公鑰不是黑客偽造的?如果黑客把公鑰私鑰的獲取過程全都替換了，該怎么辦？

證書

通過如上的方式黑客依然能夠獲取到通信的信息。

解決中間人攻擊的關(guān)鍵，關(guān)鍵在于這個(gè)公鑰是服務(wù)器的真實(shí)公鑰~

此時(shí)，證書就出現(xiàn)了?？梢岳斫獬墒且粋€(gè)結(jié)構(gòu)化的字符串，里面包含了以下信息: 證書發(fā)布機(jī)構(gòu)，證書有效期，公鑰 證書所有者，簽名等等~

當(dāng)客戶端獲取到這個(gè)證書之后，會對證書進(jìn)行校驗(yàn)(防止證書是偽造的)。于是客戶端向服務(wù)器請求公鑰的時(shí)候，不單單請求一個(gè)公鑰，而是把整個(gè)證書都請求過來。

判定證書的有效期是否過期

判定證書的發(fā)布機(jī)構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu))。

驗(yàn)證證書是否被篡改: 從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰，對簽名解密，得到一個(gè) hash 值(稱為數(shù)據(jù)摘要), 設(shè)為 hash1，然后計(jì)算整個(gè)證書的 hash 值，設(shè)為 hash2。對比 hash1 和 hash2 是否相等，如果相等，則說明證書是沒有被篡改過的。

HTTP和HTTPS到這里就差不多能夠解決遇到的問題了，當(dāng)然，HTTP和HTTPS是非常復(fù)雜的，短短一文肯定講不清。但是能夠理解上文已經(jīng)有進(jìn)步了~