目錄

HTTP協(xié)議

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

首行

請(qǐng)求頭（header）

HOST

Content-Length?編輯

User-Agent（簡(jiǎn)稱(chēng)UA）

Referer

Cookie

空行

正文（body）

HTTP響應(yīng)詳解

狀態(tài)碼

報(bào)文格式

HTTP響應(yīng)格式

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

form

Ajax（阿加克斯）

Postman

HTTPS

加密

對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密

證書(shū)

---

HTTP協(xié)議

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

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

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

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

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

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

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

想要正確抓包，還需要開(kāi)啟https功能，需要手動(dòng)啟用一下https并且安裝證書(shū)~

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

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

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

首行

首行里有HTTP的方法、URL、版本號(hào)

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

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

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

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

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

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

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

URL：

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

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

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

1.域名/IP

2.端口號(hào)

3.帶層次的路徑

4.查詢(xún)字符串

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

省略了端口，此時(shí)瀏覽器會(huì)提供默認(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 / 域名一致.

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

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

查詢(xún)字符串: 可以省略

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

HTTP/1.1： HTTP的版本號(hào)，這里是1.1

請(qǐng)求頭（header）

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

HOST

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

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

Content-Length

User-Agent（簡(jiǎn)稱(chēng)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)頁(yè)和移動(dòng)端網(wǎng)頁(yè)~

Referer

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

Cookie

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

Cookie是從哪來(lái)的？

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

Cookie是在哪存的？

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

Cookie要到哪去？

當(dāng)瀏覽器保存好Cookie之后，后續(xù)再給服務(wù)器發(fā)送請(qǐng)求的時(shí)候，就會(huì)自動(dòng)帶上這樣的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é)果。

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

200 OK? ?

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

404 Not Found

沒(méi)有找到資源。

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

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

403?Forbidden

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

405 Method Not Allowed

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

500 Internal Server Error

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

504 Gateway Timeout

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

302 Move temporarily

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

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

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

2開(kāi)頭：成功

3開(kāi)頭：重定向

4開(kāi)頭：客戶(hù)端錯(cuò)誤

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

報(bào)文格式

HTTP響應(yīng)格式

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

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

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

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請(qǐng)求

form

可以通過(guò)form標(biāo)簽來(lái)構(gòu)造一個(gè)HTTP GET請(qǐng)求。

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

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

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

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

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

Ajax（阿加克斯）

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

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

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

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

1.支持PUT、DELETE等方法。

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

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

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

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

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

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

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

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

Postman

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

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

同時(shí)也可以通過(guò)一鍵構(gòu)造，可以生成構(gòu)造請(qǐng)求的代碼，方便咱們?cè)谧约旱某绦蛑屑蓗

HTTPS

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

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

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

加密

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

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

對(duì)稱(chēng)加密

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

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

同一個(gè)密鑰，既可以用來(lái)加密，也可以用來(lái)解密。所以也叫做對(duì)稱(chēng)密鑰。

對(duì)稱(chēng)加密的前提是，密鑰不能被黑客知道。

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

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

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

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

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

非對(duì)稱(chēng)加密

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

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

公鑰是公開(kāi)的，私鑰是不公開(kāi)的。

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

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

客戶(hù)端通過(guò)公鑰給對(duì)稱(chēng)密鑰加密，黑客獲取到加密過(guò)后的秘鑰卻沒(méi)有私鑰，所以無(wú)法解開(kāi)。

服務(wù)器拿到加密后的密文后，通過(guò)私鑰解開(kāi)，這樣就得到了對(duì)稱(chēng)密鑰。

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

接下來(lái)的問(wèn)題又來(lái)了：

客戶(hù)端如何獲取到公鑰?

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

證書(shū)

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

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

此時(shí)，證書(shū)就出現(xiàn)了。可以理解成是一個(gè)結(jié)構(gòu)化的字符串，里面包含了以下信息: 證書(shū)發(fā)布機(jī)構(gòu)，證書(shū)有效期，公鑰 證書(shū)所有者，簽名等等~

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

判定證書(shū)的有效期是否過(guò)期

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

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

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