每個人都可以很喜歡每個人，但喜歡治不了病，喜歡買不了東西，喜歡不能當(dāng)飯吃，喜歡很廉價…

一、HTTP協(xié)議

1.URL

1.1 URL的組成

1.
在之前的文章中我們實現(xiàn)了一個網(wǎng)絡(luò)版本的計算器，在那個計算器中揉合了協(xié)議定制以及序列化反序列化的內(nèi)容，我們當(dāng)時也自己定制了一套協(xié)議標(biāo)準(zhǔn)，比如請求和響應(yīng)的格式應(yīng)該是什么？如何讀到一個完整的報文？支持的運(yùn)算符有什么？等等我們都有自己的標(biāo)準(zhǔn)。
那么有沒有其他大佬針對應(yīng)用層的某些使用場景，已經(jīng)提前給我們寫好了協(xié)議軟件呢？有，這個協(xié)議就是http協(xié)議，我們當(dāng)時的協(xié)議僅僅是針對計算場景所設(shè)計的，而http協(xié)議主要是針對web場景所設(shè)計的。
雖然到現(xiàn)在我們還沒真正的接觸http協(xié)議的具體內(nèi)容，但我們現(xiàn)在已經(jīng)可以知道，http中一定有網(wǎng)絡(luò)套接字編程，序列化反序列化，以及http要進(jìn)行的自己的業(yè)務(wù)邏輯，而這三個方面實際和我們當(dāng)時的計算器相同，都是分別對應(yīng)OSI上三層模型，分別是會話，表示，應(yīng)用，http的業(yè)務(wù)邏輯一般主要是電子郵件的發(fā)送，遠(yuǎn)程登陸，文件傳輸?shù)取?/mark>

2.
URL聽著比較高級，但他其實就是我們平常所說的網(wǎng)址，紅色下劃線是域名，這個域名等價于ip，用于標(biāo)識一臺主機(jī)在全網(wǎng)中的唯一性，域名實際還會做解析，解析之后就是服務(wù)器的ip地址，用域名不用ip主要是因為域名用起來方便，域名會和特定的ip地址做映射，域名后面的就是訪問資源的路徑，/是web根目錄，這個根目錄可以是linux下的任意一個目錄，/后面的erridjsis是向服務(wù)器請求的資源，?后面的是請求資源時所匹配的參數(shù)。https是在http的基礎(chǔ)上增加了一層加密層，這個協(xié)議后面會講。
在url里面我們并沒有看到port，這是怎么回事呢？其實是因為瀏覽器自動忽略了服務(wù)器的端口號，但真正在發(fā)送url進(jìn)行請求的時候，還要將端口號填充到url里面，那瀏覽器怎么知道自己要訪問的服務(wù)器的端口號是多少呢？瀏覽器其實是通過我們的協(xié)議來知曉服務(wù)器的端口號的，一般http協(xié)議對應(yīng)服務(wù)器的端口號是80，https對應(yīng)的服務(wù)器的端口號是443.
服務(wù)器端口號大部分情況下都可以省略，因為協(xié)議和端口號是強(qiáng)綁定的！所有的網(wǎng)絡(luò)服務(wù)都有對應(yīng)的明確的端口號，這些是已經(jīng)確定好的。

3.
而我們所有的網(wǎng)絡(luò)行為無外乎就兩種，一種是通過http協(xié)議從服務(wù)器拿下來對應(yīng)的資源，一種是通過http協(xié)議向服務(wù)器上傳你本地的資源。
你在網(wǎng)絡(luò)中看到的音頻，視頻，網(wǎng)頁，圖片等等，都是服務(wù)器上的文件資源，客戶端看到的這些資源實際就是服務(wù)器對應(yīng)返回的響應(yīng)結(jié)果，因為文件資源的種類很多，文件后綴就很多，但這些文件的傳輸HTTP協(xié)議都能搞定，比如音樂，視頻等文件都能傳輸，所以HTTP叫做超文本傳輸協(xié)議，不僅僅只能傳文本，還能傳其他很多種類的文件資源。
像我們平常刷抖音，聽網(wǎng)易云實際就是抖音的服務(wù)器將他內(nèi)部的視頻傳輸?shù)轿覀兛蛻舳?，或是網(wǎng)易云的服務(wù)器將音樂傳輸?shù)轿覀兊目蛻舳?，而我們遠(yuǎn)程登錄，在瀏覽器中搜索某些東西等行為就是將信息提交到遠(yuǎn)端服務(wù)器，將賬號密碼或搜索的關(guān)鍵字提交給服務(wù)器。

1.2 urlencode && urldecode

1.
在url中像// ? : @ #等字符已經(jīng)被當(dāng)作特殊意義處理了，所以如果你要搜索的內(nèi)容中出現(xiàn)了這些特殊意義的字符，則他們會被編碼化也就是urlencode化，除這些已經(jīng)被使用的特殊字符外，漢字也會被urlencode化。
一般來說網(wǎng)頁URL只能使用英文，數(shù)字，還有一些特定的字符等可以不經(jīng)過編碼直接用于URL，其他的字符都必須先經(jīng)過urlencode編碼才能用于URL，否則傳給服務(wù)器的request URL會包含亂碼，服務(wù)器無法正確識別URL，自然就無法確定你要訪問什么樣的資源，這樣就會出現(xiàn)錯誤。
可以看到在百度和必應(yīng)搜索引擎上?的左邊有一個search字段(百度的是s)，這個字段代表的是服務(wù)器要提供的特定的服務(wù)是什么，當(dāng)然對于搜索引擎來說服務(wù)當(dāng)然是搜索search啦，?右面的是以&作為分隔的name=value的一個個的鍵值對的參數(shù)形式，你搜索的時候可能只輸入了一串關(guān)鍵字符串，但實際形成的URL中會添加很多的參數(shù)，?右邊的就是微軟或百度在搜索時，服務(wù)器需要的對應(yīng)的參數(shù)，需要的參數(shù)還是比較多的，我們認(rèn)識的其中一個參數(shù)就是wd=XX%XX%XX%，這其實就是我們搜索內(nèi)容編碼化后的樣子，除了這個外，還可能包括用戶端的編碼格式等等一系列的信息，這些參數(shù)信息都是搜索引擎公司所需要的。

2.
如何urlencode和urldecode呢？首先需要將轉(zhuǎn)碼的字符先轉(zhuǎn)為16進(jìn)制的表示形式，然后從右到左取4位，將4位再以2位為一組分為兩位，這兩位可以記作XY，然后前面再加上%，這樣就變成了%XY的格式。
encode的工作瀏覽器幫我們做了，那decode的工作還需要我們自己做嗎？一般情況下是不需要的，但不排除你是從0開始寫服務(wù)器的，并且我還是學(xué)C++的，寫的就是服務(wù)器，這種情況下是需要自己做decode的工作的，因為C++不會直接完成decode的工作，其他的后端語言python java是可以直接完成decode的工作，我們也不用擔(dān)心，直接上網(wǎng)搜一下C++ URL decode的源碼即可，直接copy一份，拿來復(fù)用就行，不需要我們自己做這個工作。

3.
網(wǎng)上也有很多在線的url編碼工具，可以進(jìn)行我們輸入字符的編碼和解碼，大家可以玩一玩這些工具。

URL解碼編碼工具

2.HTTP協(xié)議格式

2.1 http請求和響應(yīng)的格式

1.
http請求分為請求行，請求報頭，空行，請求報文這4個部分，其中請求行又以空格作為分隔符，由請求方法 url 協(xié)議版本三部分組成，http這里最常用的兩個請求方法就是GET和POST，后者可以保證用戶數(shù)據(jù)的私密性，這個我們后面會講，常用的協(xié)議版本是1.1，除1.1外還有1.0版本。
request的Header報頭中是以行為單位的http請求的各種屬性，每行都是由name 冒號 空格 value \r\n組成，接下來是空行，空行之后就是正文內(nèi)容body，請求正文可以為空，如果你只單純的想從服務(wù)器上拿資源到本地的話，請求正文可以為空，如果你想向服務(wù)器上提交一些內(nèi)容，比如提交賬號和密碼進(jìn)行登錄，又或是提交一些搜索時需要的關(guān)鍵字進(jìn)行相關(guān)網(wǎng)絡(luò)內(nèi)容的搜索，這些信息就可以放在請求正文body中。
http響應(yīng)分為狀態(tài)行，響應(yīng)報頭，空行，響應(yīng)報文這四個部分，其中狀態(tài)行又以協(xié)議版本，狀態(tài)碼，狀態(tài)碼描述組成，常見的狀態(tài)碼有200 404 502等等，響應(yīng)報頭的格式和請求報頭一樣，內(nèi)容包含響應(yīng)內(nèi)容的各種屬性，接下來是空行，之后就是響應(yīng)正文，相應(yīng)正文就是客戶端請求的資源內(nèi)容，所以響應(yīng)正文內(nèi)容可以是html網(wǎng)頁，圖片，視頻，音頻等各種資源。

2.
http協(xié)議也會遇到我們當(dāng)時定制網(wǎng)絡(luò)版本計算器協(xié)議時所遇到的問題，比如你怎么保證讀到一個完整的請求或響應(yīng)報文呢？
其實很簡單，因為首行和報頭都是以行作為分隔符的，所以只要while循環(huán)一直按行讀取，直到讀取到空行為止，這樣就讀取完了首行和報頭，而報頭中會有一個字段Content-Length表示正文內(nèi)容的長度，則讀取空行結(jié)束后，我們只需要再讀取Content-Length長度個字節(jié)的內(nèi)容即可讀取一個完整的報文。

3.
http的請求和響應(yīng)怎么做到序列化和反序列化呢？這個問題也很簡單，http并沒有使用json protobuf xml等方案來實現(xiàn)序列化和反序列化，因為根本沒那個必要！如果要進(jìn)行序列化，則從第一行開始，將首行 報頭 空行 正文等內(nèi)容，以\r\n作為分隔將每行字符串進(jìn)行拼接，拼接成一個大字符串，然后直接發(fā)送即可。反序列化則按照以\r\n作為分隔符，讀取每個小字符串的內(nèi)容即可。
所以http的序列化和反序列化實際就是通過特殊字符\r\n來將每個內(nèi)容分隔開來的。
如果正文的內(nèi)容是圖片 音頻 視頻等文件，則他的序列化和反序列化工作一般不考慮，直接按照二進(jìn)制發(fā)送就行。

2.2 通過代碼來進(jìn)行驗證

2.2.1 打印出http請求報文（了解一下request的各個字段）

1.
下面是http服務(wù)器的代碼，服務(wù)器的代碼和最開始我們寫TCP套接字編程的代碼沒太大區(qū)別，首先服務(wù)器初始化時，要傳遞一個回調(diào)函數(shù)func，這個函數(shù)是http的業(yè)務(wù)邏輯處理函數(shù)，并且服務(wù)器運(yùn)行后，孫子進(jìn)程執(zhí)行的函數(shù)也發(fā)生了改變，我們讓父進(jìn)程負(fù)責(zé)會話管理，監(jiān)聽來自客戶端的連接請求并受理，而孫子進(jìn)程負(fù)責(zé)給客戶端提供對應(yīng)的http服務(wù)，執(zhí)行HandlerHttp方法。
在HandlerHttp里面，首先要保證讀取一個完整的請求報文，但今天我們不做這個工作了，這個工作做起來比較麻煩，需要套一堆的while循環(huán)進(jìn)行判斷，我們大概率是直接能讀取到一個完整的http請求的。
所以直接從sockfd里面讀取http請求，將內(nèi)容放到buffer里面，讀取成功的話，則將buffe內(nèi)容拷貝到req結(jié)構(gòu)體中的_inbuffer字段里面，然后就可以回調(diào)_func(req, resp)函數(shù)，將req中的內(nèi)容進(jìn)行http處理，然后得到一個resp結(jié)構(gòu)體，最后我們再把resp中的_outbuffer內(nèi)容返回給客戶端即可，至于req的parse方法，現(xiàn)在可以先不管，這個方法是后面進(jìn)行某些實驗時使用的，而func的邏輯也很簡單，我們就直接打印出http的請求內(nèi)容，先不構(gòu)建http響應(yīng)什么的，看看完整的http請求的廬山真面目。

2.
上面就是我們所寫的http服務(wù)器，那http的客戶端呢？我們沒有寫瀏覽器的客戶端啊。其實不用擔(dān)心，我們有現(xiàn)成的http客戶端，就是瀏覽器，我們可以用本主機(jī)的瀏覽器來發(fā)送http請求到云服務(wù)器上，而我們在云服務(wù)器上寫的代碼完成的http請求處理工作其實很簡單，就是單純的把http請求內(nèi)容打印出來而已。
所以在輸入Web地址的一欄中，我們可以用ip+端口號的方式來訪問我們的云服務(wù)器，只要一訪問，vscode的命令行就會打印出http請求的內(nèi)容。內(nèi)容包括首行 報頭 空行 以及正文，當(dāng)然今天我們僅僅只是訪問了一下服務(wù)器，沒有向服務(wù)器提交什么信息，所以請求正文自然為空，什么都沒有。

3.
瀏覽器作為客戶端請求服務(wù)器，請求是多線程的請求，所以我們的服務(wù)器會一次收到很多的http request。
請求報頭中包含了Host，也就是訪問的服務(wù)器的ip地址和端口號，主要是因為客戶端在發(fā)送請求給服務(wù)器的時候，中間可能還存在代理服務(wù)器，代理服務(wù)器需要知道自己轉(zhuǎn)發(fā)消息應(yīng)該發(fā)給誰，而Host就是告訴代理服務(wù)器請求應(yīng)該繼續(xù)轉(zhuǎn)發(fā)給誰。
Cache-Control表示客戶端要求服務(wù)器對請求的資源進(jìn)行重新獲取，而不應(yīng)該從自己服務(wù)器內(nèi)部的緩存位置中返回任何數(shù)據(jù)，意味著客戶端需要最新的資源。
Upgrade-Insecure-Requests為1的時候表示客戶端告知服務(wù)器，客戶端想要升級到安全連接HTTPS，替換原本不安全的HTTP，如果服務(wù)器支持HTTPS，則會將請求重定向到HTTPS地址，如果服務(wù)器不支持HTTPS，則自動忽略該請求報頭字段。
（使用ip地址+端口號的方式訪問服務(wù)器時，默認(rèn)使用的協(xié)議是HTTP，如果需要使用HTTPS則需要在ip地址前面加上https://如果服務(wù)器支持HTTPS協(xié)議，瀏覽器會發(fā)起https連接請求，如果不支持，則會出現(xiàn)連接錯誤。）
User-Agent表示客戶端信息，包括客戶端主機(jī)的操作系統(tǒng)版本信息，瀏覽器內(nèi)核版本信息等等。我用我的電腦和手機(jī)分別訪問了云服務(wù)器，所以兩個操作系統(tǒng)版本分別為x64架構(gòu)的win10和基于linux的Android 13操作系統(tǒng)。
Accept表示客戶端接受的文件類型，包括多種格式，有圖片，html網(wǎng)頁等等。
Accept-Encoding表示如果文檔過大時，瀏覽器可接受的壓縮格式。
Accept-Language表示瀏覽器支持什么樣的編碼和語言格式。

4.
瀏覽器請求時，默認(rèn)的請求方法是GET，如果請求時請求資源的路徑?jīng)]有指定，則服務(wù)器會默認(rèn)返回web server的首頁，也就是web根目錄下的index.html首頁，通常情況下一個網(wǎng)站只有一個index.html作為此網(wǎng)站的首頁，一個服務(wù)器可以存在多個網(wǎng)站，每個網(wǎng)站會分配不同的端口號。
http在請求時，還會交換bs(browser server)通信雙方的協(xié)議版本，因為客戶端的版本可能由于未及時更新導(dǎo)致和服務(wù)器的協(xié)議版本不兼容，為了保證服務(wù)器返回的響應(yīng)報文的協(xié)議版本和客戶端保持一致，所以服務(wù)器需要知曉browser的協(xié)議版本。
通過http請求的User-Agent字段，還可以理解一個生活現(xiàn)象，我們用電腦瀏覽器搜索微信進(jìn)行下載時，瀏覽器會主動給我們推送pc版本的微信，用手機(jī)瀏覽器搜索微信進(jìn)行下載時，瀏覽器會主動推送Android版本的微信，這是為什么呢？因為瀏覽器的服務(wù)器會收到http請求，而http請求的User-Agent字段包含了客戶端的操作系統(tǒng)版本信息，通過OS版本信息，瀏覽器就可以給我們推薦響應(yīng)版本的微信app了

5.
上面我們提到過index.html網(wǎng)站的首頁信息，許多人可能不了解這個東西，我們可以通過wget爬一下百度網(wǎng)站的首頁信息，cat打印一下index.html，可以看到前端的一些html代碼。

2.2.2 硬編碼響應(yīng)一個html網(wǎng)頁（給瀏覽器返回一個html網(wǎng)頁）

1.
上面僅僅只是打印了http請求的內(nèi)容，下面我們構(gòu)建http響應(yīng)，讓服務(wù)器給瀏覽器返回一個靜態(tài)的html網(wǎng)頁，再談?wù)揾tml網(wǎng)頁之前先來介紹一個本地測試的工具telnet，該工具可以遠(yuǎn)程登陸我們的服務(wù)器，進(jìn)行TCP連接，連接成功后，可以在命令行中手動構(gòu)建http請求，測試服務(wù)器返回的http響應(yīng)結(jié)果是否正確。
安裝telnet的指令分別為sudo yum install -y telnet-server和sudo yum install -y telnet.*
安裝成功后，輸入ctrl+]，按下回車就可以得到telnet的命令行，得到命令行之后，繼續(xù)按下回車，然后開始構(gòu)建HTTP請求的請求行并按下回車，然后服務(wù)器就會返回該請求行對應(yīng)的響應(yīng)內(nèi)容。

2.
響應(yīng)報文我們先硬編碼寫一個html網(wǎng)頁，然后把這個字段加到響應(yīng)報文里面，服務(wù)器讀取該報文之后就會解釋為一個網(wǎng)頁并給我們呈現(xiàn)出來。如果你不知名UTF-8的編碼，則瀏覽器解釋時可能會出現(xiàn)亂碼的情況。

出現(xiàn)亂碼也不要慌，只要在html里面指明編碼規(guī)則為UTF-8即可，并且通過telnet本地測試也可以得到響應(yīng)報文內(nèi)容。

下面就是服務(wù)器返回的一個網(wǎng)頁響應(yīng)。

3.
實際上瀏覽器是很智能的，就算我們的響應(yīng)內(nèi)容不包含報頭字段，例如Content-Length，瀏覽器依舊也可以識別文件類型，并進(jìn)行完整的讀取。不過我們不依賴瀏覽器這樣的行為，而是自己主動構(gòu)建出完整的響應(yīng)報文，這樣是比較好的。

2.2.3 服務(wù)器與網(wǎng)頁分離（web根目錄wwwroot）

1.
上面請求服務(wù)器的時候，什么路徑都不帶，所以返回的就應(yīng)該是網(wǎng)站首頁，但如果我想訪問web根目錄下的某個路徑下的資源呢？那直接硬編碼返回html網(wǎng)頁的方式就不可行了，我們需要一個真正的存放網(wǎng)頁的web根目錄。
而這個鼎鼎大名的web根目錄實際也就是服務(wù)器中的一個普通目錄而已，只不過這個目錄存放的是網(wǎng)站的各種資源文件，包括HTML CSS JS 圖片文件等等，當(dāng)用戶訪問網(wǎng)站的某個頁面時，web服務(wù)器就會從web根目錄開始查找對應(yīng)的資源文件。

下面代碼我們做了請求行的解析，將method url http_version等信息解析出來放到req結(jié)構(gòu)體的字段中，在構(gòu)建響應(yīng)報文的時候，我們將這些信息打印出來看一下。
如果請求路徑只有一個/，則直接返回網(wǎng)站首頁./wwwroot/index.html

2.
從打印結(jié)果可以看到，當(dāng)訪問web根目錄下的某個路徑的文件資源的時候，path路徑就是該文件資源的路徑，而當(dāng)url為/時，path路徑就變?yōu)?/wwwroot/index.html，也就是網(wǎng)站的首頁。
所謂的web根目錄其實就是在進(jìn)行url請求時，http協(xié)議自動給我們拼接的前綴./wwwroot，這個目錄就是web根目錄，同時也是網(wǎng)站的首頁。

2.2.4 首頁中增加跳轉(zhuǎn)鏈接（重新發(fā)起http請求）

1.
如果想要將一個HTML文件返回給瀏覽器實際也很簡單，我們只需要以讀取文件的方式，將HTML文件內(nèi)容讀取到響應(yīng)正文respbody里面即可，然后將respbody字符串拼接到resp中的outbuffer字段里面即可，實際就是多了個文件操作。
而在首頁中增加跳轉(zhuǎn)鏈接也很簡單，設(shè)置href加路徑即可，當(dāng)我們在首頁中點(diǎn)擊鏈接時，其實就是重新又向服務(wù)器發(fā)起該鏈接對應(yīng)資源的請求，如果你點(diǎn)擊a，則服務(wù)器會重新給你返回a網(wǎng)頁的資源，重新在瀏覽器端顯示出來。

2.2.5 首頁中增加圖片（服務(wù)器讀取圖片文件內(nèi)容時，必須以二進(jìn)制讀取到緩沖區(qū)中）

1.
除將HTML文件返回給瀏覽器外，我們也可以將圖片文件返回給瀏覽器，兩者本質(zhì)是相同的，因為在Linux下一切皆文件！別跟我說你是音頻 視頻 網(wǎng)頁 還是什么亂七八糟的東西，我linux服務(wù)器不管這些，我只認(rèn)文件，無論是什么到linux這里全都是文件，所以無論返回給瀏覽器什么，其實無非都是把文件內(nèi)容按照二進(jìn)制的方式先讀取到緩沖區(qū)中，然后調(diào)用socket接口將緩沖區(qū)的內(nèi)容發(fā)送回瀏覽器而已，本質(zhì)都是相通的。

2.
所以用戶看到的一個網(wǎng)頁，可能是經(jīng)過多個資源組合而成的！例如我們現(xiàn)在所看到的網(wǎng)頁是由多個HTML文件組成，包括體育新聞，金融新聞，首頁HTML文件，以及圖片文件.jpg，每次發(fā)送HTTP請求時，請求資源的類型都不一樣，那我們怎么知道請求的資源類型是什么呢？

3.
其實道理很簡單，答案就藏在請求資源的后綴里，我們可以從path路徑內(nèi)容中倒著查找，以.作為分隔符將后綴字符串切割出來，放到請求結(jié)構(gòu)體req的suffix字段里面，然后我們就可以把這個字段轉(zhuǎn)成Content-Type: text/html\r\n等這樣的類型，根據(jù)切分出來的suffix字段進(jìn)行窮舉類型，是什么類型我們就將該類型尾插到Content-Type: 中，然后將此字段尾插到響應(yīng)結(jié)構(gòu)體resp中的outbuffer里面。

3.HTTP中細(xì)節(jié)探究

3.1 HTTP的請求方法（GET和POST）

1.
HTTP的請求方法有很多，但我們只要了解兩個最常用的就夠了，一個是GET獲取資源，一個是POST上傳資源，GET方法通常用于請求服務(wù)器發(fā)送一些信息，這GET方法的主要限制是URL的長度。大多數(shù)瀏覽器和服務(wù)器都對URL的長度有限制些信息（參數(shù)）是通過URL的查詢字符串部分發(fā)送的。
一般向服務(wù)器提交數(shù)據(jù)的時候，前端都是通過form表單的方式來提交，瀏覽器會自動將form表單中的內(nèi)容轉(zhuǎn)換為GET或POST方法下的http請求中的某個字段，下面是表單提交的路徑和方法，一旦輸入內(nèi)容點(diǎn)擊登錄后，頁面會自動跳轉(zhuǎn)到/a/b/c.py目錄.

2.
GET方法比較尷尬，用戶提交的信息直接拼接到url的后面了，誰都能夠看到，私密性不夠好。
而POST方法會將用戶提交的參數(shù)信息保存到請求正文里面，然后提交給服務(wù)器，用戶是看不到的，私密性比GET更好一些。
但值得注意的是GET和POST只是在私密性上有所不同，兩者都是不安全的，網(wǎng)上某些人說POST方法比GET方法更安全，這種說法是錯誤的，想要使網(wǎng)絡(luò)通信安全，則必須加密(HTTPS)。
一般如果不要求私密性，想要用URL給服務(wù)器傳參，參數(shù)必須是簡潔的KV式的參數(shù)，這樣從場景可以使用GET方法。如果傳參內(nèi)容過長，則可以使用POST方法來傳，因為請求正文可以很大，例如上傳簡歷，文件什么的，都可以使用POST，也比GET方法更私密一些。

3.
我們提交給服務(wù)器指定的路徑，有什么意義呢？
意義非常重大，服務(wù)器可以通過解析url的值，如果是POST方法則先以?進(jìn)行分隔得到左邊的path，通過path服務(wù)器會提供對應(yīng)的服務(wù)，例如一開始我們講述URL的時候，可以看到百度和微軟搜索時的URL中？的左邊都是search，代表服務(wù)器會提供搜索的服務(wù)，又或是csdn網(wǎng)址中的md，article等等，這些不同的path表示服務(wù)器會提供不同對應(yīng)的服務(wù)。
所以提交路徑的意義就是進(jìn)行HTTP服務(wù)器的功能路由，通過解析url中？的左半部分，讓服務(wù)器提供對應(yīng)服務(wù)。

3.2 HTTP的狀態(tài)碼和Header（Location配合3XX狀態(tài)碼進(jìn)行重定向）

1.
最常見的狀態(tài)碼就是404(not found)客戶端錯誤，表示在服務(wù)器中找不到客戶端所請求的資源路徑，除此之外就是503 502等狀態(tài)碼，學(xué)校的垃圾服務(wù)器崩的時候，我們會經(jīng)常見到這樣的狀態(tài)碼，原因就是服務(wù)器過載或者正在進(jìn)行維護(hù)所導(dǎo)致的，http請求數(shù)量過多，服務(wù)器響應(yīng)不過來，無法同時建立那么多的TCP連接，所以會報很多503這樣的狀態(tài)碼錯誤。

2.
需要額外說明一下的是重定向錯誤碼，重定向其實就是你點(diǎn)擊網(wǎng)站請求服務(wù)器的時候，服務(wù)器返回了307狀態(tài)碼并附帶了新的url，此時客戶端又會再次請求新的url，跳轉(zhuǎn)到另一個網(wǎng)站中。

3.
重定向可分為臨時重定向和永久重定向，狀態(tài)碼分別為302和301，兩者主要區(qū)別在于重定向次數(shù)的不同，
臨時重定向：在請求新的URL后，在新的URL上瀏覽器不會認(rèn)為該URL是請求資源的最終位置，所以還可以繼續(xù)進(jìn)行新的連續(xù)多次的重定向。
永久重定向：在請求新的URL后，瀏覽器會認(rèn)為新的URL就是請求資源的最終位置，則之后不會再進(jìn)行重定向，所以永久重定向只能重定向一次。
比301和302更標(biāo)準(zhǔn)一些的是307和308，307符合HTTP標(biāo)準(zhǔn)，是實現(xiàn)臨時重定向的更標(biāo)準(zhǔn)的一種方式，308是更符合HTTP1.1標(biāo)準(zhǔn)的一種永久重定向的方式。

4.
想要實現(xiàn)重定向其實也很簡單，我們只要將http響應(yīng)的狀態(tài)行中的狀態(tài)碼設(shè)置為307，狀態(tài)碼描述為Temporary Redicet，同時在http響應(yīng)報頭中增加Location字段后面跟著要重定向到的網(wǎng)站，將此響應(yīng)結(jié)構(gòu)體返回，如果再次訪問43.143.22.45:8080，則會直接跳轉(zhuǎn)到我的csdn賬號首頁，不是原來的網(wǎng)頁了。

輸入我的服務(wù)器地址和端口號之后，可以看到網(wǎng)頁重定向到了我的csdn首頁

3.3 長連接（keep-alive）

1.
我們知道一張網(wǎng)頁是可能由多種元素構(gòu)成的，則一張完整的網(wǎng)頁則一定需要經(jīng)過瀏覽器多次的HTTP請求才能獲取到，瀏覽器會將每次請求到的多個內(nèi)容進(jìn)行渲染組合，最后形成完整的一張網(wǎng)頁。
我們知道HTTP是基于TCP的，所以如果頻繁發(fā)起HTTP請求，則勢必會頻繁創(chuàng)建TCP連接，這樣的網(wǎng)絡(luò)傳輸就有點(diǎn)低效，但他的好處就是簡單，不用做多余的工作，HTTP1.0標(biāo)準(zhǔn)就是這么做的。
后來隨著網(wǎng)絡(luò)資源的增多以及用戶對網(wǎng)絡(luò)傳輸?shù)男室笞兏撸灶l繁創(chuàng)建TCP連接這樣的方式就不太好，進(jìn)而推出了HTTP1.1版本，它允許客戶端和服務(wù)器在一條TCP連接上進(jìn)行多個HTTP的請求和響應(yīng)，減少網(wǎng)絡(luò)資源的消耗，提高服務(wù)器的性能和響應(yīng)速度。

2.
在HTTP1.0中，長連接是可選的，需要通過在請求和響應(yīng)頭中設(shè)置Connection: keep-alive來啟用，而在HTTP1.1中，長連接是默認(rèn)啟用的，除非顯示的在請求和響應(yīng)頭中設(shè)置Connection: close來關(guān)閉長連接。
但實際上，在HTTP/2和HTTP/3中還引入了多路復(fù)用的技術(shù)，長連接在這些協(xié)議中反而變得不重要了，因為我們有更為高效的解決方案了。

3.4 周邊會話保持（cookie和session）

1.
會話保持嚴(yán)格意義上不是HTTP天然具有的，是后面使用時，發(fā)現(xiàn)需要會話保持從而加上的。
HTTP協(xié)議是無狀態(tài)的，也就是說HTTP協(xié)議不會記錄自己歷史所發(fā)送過的請求，但我們常見的一種網(wǎng)絡(luò)現(xiàn)象是，如果我登陸過了某個網(wǎng)站，下次在登陸的時候，網(wǎng)站是能夠記住我的，我無須再次輸入賬號和密碼，這和無狀態(tài)的http協(xié)議有點(diǎn)對不上啊。
首先需要明白一點(diǎn)的是，不要孤立的看待http協(xié)議，http就是一個協(xié)議，他是要被瀏覽器所使用的，雖然你http是無狀態(tài)的，你每次發(fā)起http請求，瀏覽器都會去請求，但瀏覽器會有自己相關(guān)的信息緩存策略，因為用戶是需要http有狀態(tài)的，用戶需要有自己的瀏覽歷史狀態(tài)，否則每次訪問網(wǎng)站都需要登錄，在一個網(wǎng)站內(nèi)跳轉(zhuǎn)也需要登錄，這太影響用戶體驗了。
用戶查看新的網(wǎng)頁是常規(guī)操作，如果在一個網(wǎng)站中發(fā)生了新的網(wǎng)頁跳轉(zhuǎn)，新的頁面是無法識別是哪一個用戶的，需要用戶重新登錄，為了讓用戶一經(jīng)登錄就可以按照自己的身份，在整個網(wǎng)站中訪問任意的網(wǎng)頁，瀏覽器做出了緩存策略。
（例如我的edge瀏覽器中就有瀏覽器幫我緩存的圖像和文件等信息）

2.
瀏覽器使用http協(xié)議是如何做到周邊會話保持的呢？
通過cookie文件來實現(xiàn)，當(dāng)發(fā)起第一次遠(yuǎn)程登錄請求時，瀏覽器會將我們的賬號密碼等信息保存在本地的一個cookie文件中，往后只要再次訪問這個網(wǎng)站，瀏覽器會再次發(fā)起http請求，同時將保存的cookie信息推送至服務(wù)器，無須用戶再次輸入賬號密碼重新登錄。
cookie信息可分為文件級cookie和內(nèi)存級cookie兩種，如果是內(nèi)存級cookie，則cookie的生命周期隨瀏覽器進(jìn)程，當(dāng)我們把瀏覽器關(guān)閉之后，cookie信息會自動銷毀，重新打開瀏覽器登錄網(wǎng)站時，則需要再次輸入賬號和密碼，如果是文件級cookie，則cookie不受瀏覽器關(guān)閉的影響，或電腦開關(guān)機(jī)重啟的影響，因為他存在于磁盤外設(shè)上。
cookie是文件還是內(nèi)存級別，這是在瀏覽器里面可以配置的。

3.
上面的方法還存在一些問題，常見的病毒分為蠕蟲病毒和木馬病毒，蠕蟲病毒以直接攻擊主機(jī)為目標(biāo)，攻擊內(nèi)存或CPU，讓計算機(jī)的資源吃的很緊，以至于你什么都干不了，而木馬病毒并不會直接攻擊你的主機(jī)，他希望你的主機(jī)越健康越好，主要目的是通過開啟某些后門，盜取你主機(jī)上的cookie文件，從內(nèi)部瓦解。
所以有可能你第一次登錄網(wǎng)站后，瀏覽器自動保存了cookie文件到你的本地主機(jī)上，往后你每次登錄都不需要輸入密碼和賬號，只需要讓瀏覽器推送cookie信息進(jìn)行登錄即可。如果黑客在你的電腦上植入了木馬病毒，并盜取了你的cookie文件，那黑客用自己的瀏覽器來推送cookie信息到服務(wù)器，服務(wù)器會誤認(rèn)非法用戶hacker就是用戶本身，此時黑客就有可能使用你的身份從事某些違反犯罪活動，對社會產(chǎn)生較大的影響。

4.
為了解決上面的問題，需要引用session的概念，即瀏覽器不去保存用戶的私密信息到本地上，而是將這樣的信息保存在服務(wù)器上，服務(wù)器主機(jī)內(nèi)部會形成一個session文件，此文件內(nèi)部用于保存登錄網(wǎng)站時所需要的賬號密碼等信息，一個服務(wù)器內(nèi)部一定會有很多的session文件，因為不止你一個人訪問此網(wǎng)站，所以在服務(wù)器內(nèi)部session文件都會有唯一的標(biāo)識叫做session id，標(biāo)識服務(wù)器內(nèi)部當(dāng)前session文件的唯一性。而瀏覽器的cookie文件負(fù)責(zé)保存session id，當(dāng)下一次進(jìn)行登錄時，瀏覽器會向服務(wù)器推送保存session id的cookie文件，服務(wù)器會比對當(dāng)前發(fā)送過來的session id是否在服務(wù)器內(nèi)部也同樣存在一份，如果存在則表示登錄成功，返回響應(yīng)。通過這樣的方式來實現(xiàn)http的周邊會話保持。
但黑客有沒有可能盜取session id呢？是有可能的，但用戶信息的泄露問題已經(jīng)大大改善了，以前我們作為平頭老百姓，沒有辦法保護(hù)我們自己主機(jī)上的私密信息，但現(xiàn)在我們把信息保存在那些大型公司的服務(wù)器上了，讓那些大公司間接的保護(hù)我們的私密信息，大公司肯定比我們平頭老百姓有實力啊，他們有自己專業(yè)的網(wǎng)絡(luò)攻防團(tuán)隊。
但瀏覽器誤認(rèn)黑客是用戶本身這樣的問題是解決不了的，我們只能配合其他策略來緩解這樣的問題，例如ip異常登錄警告，迫使雙方下線，使得原來的session id失效，重新進(jìn)行登錄 重新生成新的session id，以及源IP溯源查找非法用戶等策略，一旦黑客拿到session id，我們可以配合其他策略讓用戶和服務(wù)器同時下線，這樣黑客拿到的session id就是無效的id，當(dāng)用戶重新上線時，再讓服務(wù)器生成新的session id，通過這樣的方式來緩解黑客惡意登錄普通用戶賬號的問題。

5.
多說一點(diǎn)題外話，除了上面那種ip異常登錄的方式外，如果很長時間你沒聯(lián)系過的用戶突然給你發(fā)消息了，騰訊會甄別這個用戶的安全性，檢測到我們的賬號可能存在安全問題，讓我們重新登錄，或者你與上一次登錄的時間間隔過長，你的賬號也可能存在異常，此時騰訊也會強(qiáng)制你下線，讓你重新登錄，使得原有session id失效，生成新的session id。
那些網(wǎng)站服務(wù)器其實也沒那么弱，他們也并不是只會傻傻的等別人來攻擊，白帽子工程師也會在網(wǎng)站中形成一些陷阱讓黑帽子來踩，這樣的陷阱稱為口袋，一旦黑客踩到陷阱，則黑客的ip等相關(guān)信息會全部暴露在網(wǎng)站中，維護(hù)網(wǎng)站的公司中的安全團(tuán)隊可以通過源ip溯源的方式抓到hacker

6.
上面說了一大堆，你怎么證明你所說的是正確的呢？服務(wù)器是怎么做到把你輸入的賬號密碼等信息寫入到cookie中呢？又怎么證明http后續(xù)請求時會攜帶cookie信息呢？

當(dāng)我們在響應(yīng)報頭header中添加了Set-Cookie字段時，從瀏覽器中保存的網(wǎng)站信息中就可以看到cookie數(shù)據(jù)，設(shè)置cookie內(nèi)容的同時，也可以設(shè)置cookie的持續(xù)時間Max-Age

當(dāng)服務(wù)器返回的響應(yīng)報頭中添加了Set-Cookie字段后，下一次瀏覽器在向服務(wù)器發(fā)起請求時，請求報頭中會自動攜帶Cookie信息，此信息用于服務(wù)器鑒權(quán)，如果cookie信息正確，則登錄成功，否則登錄失敗。

4.基本工具

4.1 postman（API測試工具）

1.
postman是一款測試和調(diào)試Web API的工具，可以支持發(fā)送http請求和檢查測試服務(wù)器的http響應(yīng)，具有可視化查看內(nèi)容的功能，主要用于測試和調(diào)試Web API，API一般指網(wǎng)絡(luò)通信時，應(yīng)用程序之間進(jìn)行通信和數(shù)據(jù)交換的標(biāo)準(zhǔn)接口。

除了用postman獲取某些網(wǎng)站信息外，我們也可以使用telnet+url+port的方式獲取某些網(wǎng)站的信息。

獲取成功后，postman會給我們返回一個可視化查看響應(yīng)內(nèi)容的窗口，其中有美化 原始 預(yù)覽等查看類型。

用postman也可以獲取自己web server服務(wù)器的信息內(nèi)容，檢查自己服務(wù)器的相應(yīng)內(nèi)容是否正常，通?？梢杂脕碚{(diào)試測試我們的服務(wù)器功能。

postman也可以構(gòu)建http請求發(fā)送給服務(wù)器，例如可以在請求正文body中添加表單form，發(fā)送至服務(wù)器，從服務(wù)器的響應(yīng)內(nèi)容可以看到請求正文中確實包含了encode的張三和hello world

4.2 fiddler（本地抓包工具）

1.
fiddler是一個本地抓包工具，也可以用于捕獲和分析HTTP的請求和響應(yīng)，可以查看請求和響應(yīng)的頭部 正文等信息，F(xiàn)iddler還提供了一些高級功能，如重放請求、修改請求和響應(yīng)、自定義腳本等。（這些高級功能我也不會用，我用他也就只能調(diào)試檢測一下我的web server的響應(yīng)內(nèi)容而已）

下面是fiddler抓到的我的服務(wù)器的http響應(yīng)，可以查看到請求的cookie，host等信息

下面是服務(wù)器打印出來的內(nèi)容

2.
fiddler是一個主要抓http包的本地抓包工具，更多的是為了程序員進(jìn)行本地測試的，還有一個軟件wireshark，這個軟件主要是針對傳輸層協(xié)議UDP和TCP的，postman不是抓包工具，他只是一個API測試工具，用于構(gòu)建http請求和可視化查看http響應(yīng)。

3.
fiddler的角色其實就是中間代理服務(wù)器，所以fiddler抓到的http包的url都是非常完整的，包括前綴 ip 端口 請求資源路徑等，因為作為中間代理服務(wù)器需要轉(zhuǎn)發(fā)來自客戶端的請求，則必須知道更為詳細(xì)的信息，以便于將完整的信息轉(zhuǎn)發(fā)至服務(wù)器。

二、HTTPS協(xié)議

1.基本概念的鋪設(shè)

1.1 HTTPS的引入 && 什么是加密？（有加密，也一定有解密）

1.
在HTTP協(xié)議中，無論是GET方法還是POST方法都是不安全的，只不過POST方法相比GET方法更私密一些，但也僅此而已了，想要安全則必須有加密的參與。
HTTP協(xié)議中網(wǎng)絡(luò)數(shù)據(jù)的傳輸全部都是明文的，安全性很低，20年前我們國家網(wǎng)絡(luò)剛興起的時候，當(dāng)時大部分?jǐn)?shù)據(jù)都是明文傳輸，由于各種安全問題的產(chǎn)生，所以在近十年HTTP協(xié)議大部分都被換成了https協(xié)議，但HTTPS協(xié)議被引入并不代表HTTP協(xié)議不用了！某些場景下還會繼續(xù)使用http協(xié)議。

2.
在原有的http協(xié)議層和傳輸層之間設(shè)計了一層軟件層，這層軟件層就是加密層ssl/tls，當(dāng)數(shù)據(jù)傳輸時若沒有經(jīng)過加密層，則默認(rèn)使用的是http協(xié)議，如果數(shù)據(jù)傳輸經(jīng)過了加密層，則使用的是https協(xié)議，這層軟件層被設(shè)計到傳輸層了，不再應(yīng)用層，所以，我下面畫的圖其實是有問題的，應(yīng)該把ssl和tls畫到傳輸層里面。
http協(xié)議的服務(wù)器匹配的端口號是80，https協(xié)議的服務(wù)器匹配的端口號是443，通過端口號我們就可以區(qū)分協(xié)議是否經(jīng)過了加密。
需要明確的是http和https只是在技術(shù)上有交集，但在應(yīng)用層兩者是完全不同的協(xié)議。
（作為一個后端開發(fā)程序員，其實只要知道HTTPS就可以了，做網(wǎng)安 網(wǎng)絡(luò)攻防的人才需要對HTTPS的原理進(jìn)行深入學(xué)習(xí)，我學(xué)個皮毛就夠了）

3.
加密就是把明文(要傳輸?shù)男畔?進(jìn)行一系列變換得到密文，解密就是把密文經(jīng)過一些列變換還原成明文，在加密和解密過程中通常需要一個或多個數(shù)據(jù)來輔助加密和解密過程的進(jìn)行，這樣的數(shù)據(jù)稱為密鑰。例如下面數(shù)據(jù)的傳輸過程中，client要發(fā)送a明文，隨后他使用key作為密鑰對a明文進(jìn)行異或加密得到密文b，將密文發(fā)送給server，server接收到密文之后，也使用密鑰key對密文進(jìn)行異或，得到原始數(shù)據(jù)a=100，這樣的一個傳輸過程我們稱為加密和解密。
值得注意的是，拉長時間線和成本線來考慮的話，只要是加密那一定是能解密的，大不了窮舉嘛，只不過可能需要的成本很高，時間人力物力財力等。
所以我們可以這樣定義加密，通過密鑰對明文進(jìn)行一系列的變化，同時還能夠通過密鑰進(jìn)行解密的通信過程，我們稱為加密通信。

1.2 網(wǎng)絡(luò)通信中的運(yùn)營商角色 && 為什么要加密？（明文傳輸可能會受到中間人攻擊）

1.
在中國大陸地區(qū)使用互聯(lián)網(wǎng)時，許多的局域網(wǎng)網(wǎng)絡(luò)請求都必須經(jīng)過運(yùn)營商的網(wǎng)絡(luò)設(shè)備才能到達(dá)目標(biāo)服務(wù)器，主要是因為中國政府實施了一系列的互聯(lián)網(wǎng)監(jiān)管措施，要求所有的互聯(lián)網(wǎng)服務(wù)提供商ISP(Internet Service Provider)和互聯(lián)網(wǎng)內(nèi)容提供商ICP(Internet Content Provider)必須遵守相關(guān)的監(jiān)管規(guī)定和技術(shù)要求。
常見的監(jiān)管措施包括實名制、防火長城、DNS污染、IP封鎖、HTTPS攔截、流量限制等，為了實施這些監(jiān)管措施，中國三大運(yùn)營商會在全國部署各種網(wǎng)絡(luò)設(shè)備，如防火墻、代理服務(wù)器、路由器等，用戶在局域網(wǎng)中發(fā)送的網(wǎng)絡(luò)請求會被運(yùn)營商的設(shè)備攔截和過濾，或者重定向到運(yùn)營商的服務(wù)器進(jìn)行處理（違規(guī)的HTTP或HTTPS請求，用戶主機(jī)使用違規(guī)的DNS服務(wù)器，一些VPN和代理請求可能會被運(yùn)營商攔截重定向到自己的服務(wù)器進(jìn)行處理）
需要注意的是，也有特殊情況，有些局域網(wǎng)會使用虛擬專用網(wǎng)絡(luò)（VPN）等工具來繞過運(yùn)營商的限制，從而直接訪問目標(biāo)服務(wù)器，此外一些國際互聯(lián)網(wǎng)公司在中國境內(nèi)也部署了自己的服務(wù)器和網(wǎng)絡(luò)設(shè)備，以提供更加穩(wěn)定和快速的服務(wù)（這些國際公司都是符合中國法律規(guī)定的，訪問這些國際互聯(lián)網(wǎng)公司的服務(wù)器一般不需要經(jīng)過運(yùn)營商的設(shè)備）。

2.
局域網(wǎng)用戶需要連接到廣域網(wǎng)才能訪問互聯(lián)網(wǎng)資源，所以局域網(wǎng)的請求一般經(jīng)過路由器路由后，會將請求發(fā)送至運(yùn)營商的網(wǎng)絡(luò)，由運(yùn)營商將請求發(fā)送到廣域網(wǎng)中。
大家應(yīng)該聽過臭名昭著的"運(yùn)營商劫持"吧，比如我在瀏覽器上下載一個千千動聽播放器，但點(diǎn)擊下載的時候，鏈接就變?yōu)榱薗Q瀏覽器，這其實就是運(yùn)營商在從中作梗，他替我們把請求發(fā)送至千千動聽服務(wù)器，但運(yùn)營商在返回時，自動給我們返回成QQ瀏覽器的下載鏈接，這其實就是騰訊給運(yùn)營商錢了，運(yùn)營商幫助他們做產(chǎn)品的推廣，增加QQ瀏覽器的用戶量，被金錢蒙蔽住了雙眼。

3.
運(yùn)營商劫持我們的數(shù)據(jù)其實還好，沒有什么安全問題，就是惡心我們一下，但如果中間人劫持了信息呢？因為http是明文傳送的，明文數(shù)據(jù)會經(jīng)過路由器，代理服務(wù)器，通信服務(wù)運(yùn)營商等多個結(jié)點(diǎn)，如果信息在傳輸過程中被中間人劫持并且進(jìn)行篡改，雙方還不會察覺到，這樣就很危險，所以我們要對傳輸?shù)男畔⑦M(jìn)行加密。HTTPS就是在HTTP的基礎(chǔ)上進(jìn)行了加密，進(jìn)一步保證網(wǎng)絡(luò)傳輸數(shù)據(jù)的安全。

1.3 對稱加密和非對稱加密

1.
常見的加密方式有對稱加密和非對稱加密兩種。
使用同一個密鑰作為信息的加密和解密，這種加密方法稱為對稱加密，也成為單密鑰加密，常見的算法有DES、3DES、AES、TDEA、Blowfish、RC2等，這些算法都是公開的，計算量較小，加密速度快，加密效率高。上面我們舉得一個例子中，使用按位異或^進(jìn)行加密和解密，這其實就是一種對稱加密。

2.
非對稱加密需要兩個密鑰來進(jìn)行加密和解密，一個是公鑰，一個是私鑰，用公鑰加密則只能用私鑰解密，用私鑰加密則只能用公鑰解密，常見的非對稱加密算法有RSA，DSA，ECDSA，非對稱加密的算法強(qiáng)度復(fù)雜，安全性高，但最大的缺點(diǎn)就是運(yùn)算速度非常慢，比對稱加密要慢很多。

1.4 數(shù)據(jù)摘要和數(shù)據(jù)指紋（不是加密，常用來進(jìn)行數(shù)據(jù)對比）

1.
數(shù)據(jù)摘要和數(shù)據(jù)指紋是一回事，其原理就是對一段文本使用單向散列函數(shù)(hash函數(shù))生成一串固定長度的數(shù)字摘要，hash函數(shù)是不可逆的，因為映射時會使用隨機(jī)值，并且不同的值還可能存在哈希碰撞，則一段文本經(jīng)過特定的hash算法散列后，極大概率下不會和其他文本重疊，并且無法通過生成的散列值來逆推出原始文本。
常見的摘要算法有MD5、SHA1、SHA256、SHA512等，兩個不同的信息經(jīng)過hash散列后的散列值可能相同，但概率極低，就像人類的指紋在科學(xué)上是有相同的概率的，但在現(xiàn)實中遇到兩個完全相同的指紋，這幾乎是不可能的，就像兩段不同的文本在經(jīng)過同一hash函數(shù)散列后得到的散列值一樣，兩個散列值完全相同這幾乎是不可能的。

2.
值得注意的是數(shù)據(jù)摘要算法不是加密，因為如果是加密，則必須有解密的過程，顯然我們無法從散列值會推到原始文本，所以他不是加密。
數(shù)據(jù)摘要通常用來進(jìn)行數(shù)據(jù)對比，把兩段非常大的文本都經(jīng)過同一散列方法進(jìn)行散列，通過比對兩個散列值是否相同來判斷這兩段文本是否相同，因為比較兩個散列值要更輕松一些。
只要你稍微變化一下文章的內(nèi)容，經(jīng)過hash算法生成的散列值就會有很大的改變。

3.
理想的哈希算法可以讓不同文本計算出的散列值發(fā)生碰撞的概率降至極低。
下面給大家舉兩個使用hash算法進(jìn)行數(shù)據(jù)對比的栗子。
大家應(yīng)該知道百度網(wǎng)盤秒傳的功能吧，在用戶看來他自己如果向百度網(wǎng)盤傳了一個電影，從用戶感知角度來講，可能只需要不到1s的時間就把電影傳上去了，但實際上不是用戶傳上去一個電影，而是百度網(wǎng)盤本身就有這個電影，試想一下如果中國那么多的用戶都向百度網(wǎng)盤上傳一個戰(zhàn)狼2電影，那百度網(wǎng)盤不就存放了很多相同的文件嗎？百度可沒那么傻，他不會存儲這樣多余重復(fù)的文件，而只會存儲一份這樣的文件。
所以實際的秒傳根本就沒有傳到百度網(wǎng)盤，而是將你所傳的文件使用hash算法生成散列值，并且百度服務(wù)器也會把他自己數(shù)據(jù)庫中的戰(zhàn)狼2電影生成一個散列值，兩者使用相同的hash算法，對比兩個散列值是否相同，如果相同則不上傳用戶的電影文件，不相同則上傳，如果你要看戰(zhàn)狼2的話，則百度直接把他自己數(shù)據(jù)庫中的戰(zhàn)狼2電影傳輸給你即可。

4.
除此之外，當(dāng)我們訪問服務(wù)器進(jìn)行某些網(wǎng)站的登錄時，我們會輸入賬號和密碼，而這些信息都會保存到服務(wù)器的數(shù)據(jù)庫當(dāng)中，如果直接把密碼放到數(shù)據(jù)庫中，一旦數(shù)據(jù)泄露則會帶來巨大的后果，因為密碼都是明面的，所以涉及到密碼這樣的字段最好使用hash算法進(jìn)行數(shù)據(jù)摘要，這樣即使數(shù)據(jù)泄露，不法分子也無法根據(jù)數(shù)據(jù)摘要逆推出密碼是什么。
而我們自己登錄的時候，還是道理相同，將自己的密碼形成數(shù)據(jù)摘要與數(shù)據(jù)庫中的數(shù)據(jù)摘要進(jìn)行對比，相同則登錄成功，否則失敗。

2.HTTPS工作過程探究（解決數(shù)據(jù)被監(jiān)聽或被篡改的問題）

2.1 只使用對稱加密

1.
如果通信雙方都持有同一個密鑰X，并且只有通信雙方知道這個密鑰X，則通信一定是安全的，除非黑客破解密鑰，但我們假設(shè)黑客無法破解密鑰。
但實際上下面的方案存在著一個很大的問題，你怎么保證客戶端和服務(wù)器使用的是同一個密鑰呢？所以服務(wù)器就必須把密鑰傳到客戶端，讓客戶端知曉對稱密鑰X，但傳輸密鑰是明文傳還是密文傳呢？明文傳肯定不行，因為明文傳，黑客劫持后不就知道密鑰是什么了嗎？那如果加密傳的話，有需要新的密鑰來進(jìn)行加密，這樣就變成了雞生蛋，蛋生雞的問題了。
所以只使用對稱加密是不行的，因為無法保證密鑰傳遞給對方的安全性！

2.2 只使用非對稱加密

1.
服務(wù)器形成非對稱加密的公鑰和私鑰，當(dāng)客戶端發(fā)起第一次密鑰協(xié)商握手時，服務(wù)器將自己的公鑰推送給客戶端，則下次客戶端發(fā)送信息時，可以使用公鑰對明文進(jìn)行加密，然后將密文傳輸給服務(wù)器，傳輸過程一定是安全的，因為中間人只能劫持公鑰，而當(dāng)前密文只能由服務(wù)器的私鑰才能解開。
但當(dāng)服務(wù)器發(fā)送密文給客戶端時，這個過程就會出問題了，因為密鑰加密的明文可以使用公鑰進(jìn)行解密，而全世界人民都有公鑰，那服務(wù)器還加密了個寂寞啊，中間人輕輕松松就知道服務(wù)器發(fā)送的消息是什么了。

2.3 雙方都使用非對稱加密

1.
所以更進(jìn)一步的做法就是客戶端和服務(wù)器都使用非對稱加密，第一次密鑰協(xié)商握手時，客戶端將自己的公鑰推送給服務(wù)器，服務(wù)器接收后，服務(wù)器把自己的公鑰也響應(yīng)給客戶端，此后當(dāng)客戶端要發(fā)送消息時，就使用服務(wù)器的公鑰來進(jìn)行加密，服務(wù)器收到后用自己的私鑰進(jìn)行解密，當(dāng)服務(wù)器發(fā)送消息時，就使用客戶端的公鑰來進(jìn)行加密，客戶端收到后用自己的私鑰進(jìn)行解密。

2.
但這樣的方案效率很低，因為非對稱加密很慢，他的算法強(qiáng)度復(fù)雜度高，一次非對稱加密就已經(jīng)很慢了，使用兩次非對稱加密那就會更耗時，網(wǎng)絡(luò)傳輸?shù)男示蜁艿汀?br> 并且實際上還存在著一定的安全問題，這個安全問題后面會講。

2.4 非對稱加密+對稱加密

1.
我們先來解決兩個非對稱加密效率低的問題，后面在解決其依舊存在的安全問題。
如果要解決效率問題，服務(wù)器可以形成一對非對稱密鑰對，在客戶端發(fā)起第一次密鑰協(xié)商ssl握手時，服務(wù)器將自己的公鑰推送至客戶端，客戶端獲得公鑰后，自己通過對稱加密算法進(jìn)行明文的加密，同時使用公鑰將對稱密鑰key進(jìn)行加密發(fā)送給服務(wù)器，這個過程即使中間人劫持了數(shù)據(jù)也無法進(jìn)行解密，因為只有服務(wù)器的私鑰才能解密，所以當(dāng)服務(wù)器解密之后就能拿到對稱密鑰key了，之后客戶端和服務(wù)器通信就可以使用對稱密鑰key來進(jìn)行通信了，而對稱加密的加密速度快同時加密效率高，這樣就可以解決方案3效率低的問題了。

2.5 解決中間人一開始就進(jìn)行攻擊的問題

2.5.1 引入CA證書

1.
實際上面那種非對稱+對稱加密的方案已經(jīng)很接近答案了，但他其實還存在一種問題，中間人不等客戶端和服務(wù)器雙方安全的將對稱密鑰傳輸后在進(jìn)行攻擊，而是在一開始就發(fā)起攻擊呢？
當(dāng)服務(wù)器推送自己公鑰給客戶端時，中間人此時直接劫持響應(yīng)報文，將響應(yīng)報文中的公鑰替換成中間人自己的公鑰，來個貍貓換太子呢？那客戶端使用中間人的公鑰進(jìn)行對稱密鑰X的加密發(fā)送回服務(wù)器時，中間人依舊就可以巧妙的先用自己的私鑰進(jìn)行解密，先讀取到對稱密鑰X，然后再拿服務(wù)器的公鑰S將對稱密鑰X進(jìn)行加密，然后偽裝成客戶端把加密后的對稱密鑰X發(fā)回給服務(wù)器，至此中間人其實已經(jīng)拿到了自己最想要的東西了，但客戶端和服務(wù)器卻依舊無法察覺到，所以中間人擁有對稱密鑰X之后，那就可以隨意篡改或監(jiān)聽數(shù)據(jù)，并且客戶端和服務(wù)器都是不知曉的，一切盡在中間人的掌握之中。

2.
上面問題的產(chǎn)生主要是因為，客戶端無法辨別收到的公鑰是否就是服務(wù)器發(fā)送過來的，因為這個公鑰有可能是中間人發(fā)送過來的，所以為了解決這樣的問題，需要先引入CA證書。
服務(wù)器在使用HTTPS之前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書中包含證書申請者信息，以及CA公鑰信息，當(dāng)服務(wù)器申請CA認(rèn)證時，公鑰會包含在數(shù)字證書里面，以證明公鑰的權(quán)威性，而私鑰則由服務(wù)器自己保存好。在申請CA證書前，需要準(zhǔn)備好公司的相關(guān)信息，例如公司的營業(yè)執(zhí)照，合法人信息等來確定服務(wù)器所在公司的合法性。

3.
申請證書時需要在特定平臺申請，此時會生成一對兒密鑰對兒，即公鑰和私鑰，公鑰會隨著CSR文件一起發(fā)給CA機(jī)構(gòu)進(jìn)行權(quán)威認(rèn)證，私鑰服務(wù)器自己保留，用于后續(xù)的網(wǎng)絡(luò)通信，主要是用于交換客戶端生成的對稱密鑰

4.
我們在網(wǎng)絡(luò)訪問時，可能也會遇到這樣的情況，這種情況一般就是網(wǎng)站的CA證書可能過期了，或者網(wǎng)站沒有申請CA認(rèn)證，瀏覽器不信任該類網(wǎng)站。

2.5.2 理解數(shù)據(jù)簽名（對數(shù)據(jù)摘要使用CA私鑰進(jìn)行非對稱加密）

1.
數(shù)據(jù)簽名實際就是先對數(shù)據(jù)(CA公鑰)進(jìn)行hash散列函數(shù)，形成散列值，然后對散列值使用CA認(rèn)證的私鑰進(jìn)行加密，這樣就得到了數(shù)據(jù)簽名，將數(shù)據(jù)簽名附加到數(shù)據(jù)上就得到了真正意義上的CA認(rèn)證證書，而數(shù)據(jù)簽名最大的意義就是防止有人篡改公鑰，先前存在的問題不就是中間人將服務(wù)器發(fā)送的公鑰篡改為中間人自己的公鑰了嗎？
服務(wù)器在第一次密鑰協(xié)商握手時，發(fā)送的是數(shù)字證書，而不僅僅是公鑰信息，當(dāng)客戶端收到數(shù)字證書后會驗證證書的真假，驗證方式為把證書拆分成簽名和數(shù)據(jù)兩部分，使用證書中的公鑰對數(shù)字簽名進(jìn)行解密得到散列值，然后對證書中的數(shù)據(jù)(CA公鑰)使用相同的hash散列函數(shù)也得到一個散列值，比較兩個散列值是否相同，如果相同則說明證書中的公鑰沒有被中間人篡改過，如果不同則說明中間人一定篡改了證書中的公鑰。
（CA證書數(shù)據(jù)=簽名+數(shù)據(jù)，簽名=CA公鑰+hash散列+CA私鑰加密，數(shù)據(jù)=CA公鑰。）

2.
簽名其實就是公鑰先做hash得到散列值，然后再用服務(wù)端的私鑰進(jìn)行加密得到的密文簽名，而數(shù)據(jù)其實就是公鑰，如果中間人將證書的公鑰更改為他自己的客戶端的話，那么當(dāng)客戶端用中間人的公鑰去解密簽名時，一定是解不開的，就算解開了，將公鑰使用hash散列后，與解密后的簽名一對比，這一定是不相同的，所以中間人更改證書的公鑰是不行的。如果想要更改簽名，那也沒什么意義，因為中間人用證書的公鑰將簽名解密之后，僅僅得到的是公鑰hash之后的散列值，更改散列值有什么意義呢？
所以當(dāng)我們在非對稱傳遞服務(wù)器公鑰的過程中，引入了CA證書，那么就能夠保證服務(wù)器傳遞公鑰的正確性，從而讓客戶端在接收到公鑰后，使用公鑰來加密傳遞對稱密鑰。

3.
永遠(yuǎn)記住，由于中間人不可能擁有CA認(rèn)證的私鑰，只有服務(wù)器才會有這個私鑰，那么中間人對證書做的任何修改，就都是非法的，客戶端可以立馬察覺到證書的非法性。
至于證書的整體掉包，中間人做這個工作也沒啥意義，除了沒意義之外，還有風(fēng)險，畢竟證書里面有各種服務(wù)器認(rèn)證信息，黑客把自己的各種位置信息都暴露嗎？他可沒那么傻。

2.5.3 非對稱加密+對稱加密+證書認(rèn)證

1.
在方案四中增加證書認(rèn)證就可以解決安全問題了。
即讓客戶端具有辨別公鑰是否合法的能力，如果公鑰合法，則就可以使用公鑰傳遞對稱密鑰至服務(wù)器，服務(wù)器使用私鑰解密拿到對稱密鑰后，就可以使用對稱密鑰快速高效的和客戶端進(jìn)行網(wǎng)絡(luò)通信了。

在瀏覽器中，我們可以從隱私搜索和服務(wù)一欄中找到瀏覽器內(nèi)置的各種認(rèn)證機(jī)構(gòu)所認(rèn)證的證書。

我隨便點(diǎn)開了一個證書，在證書的詳細(xì)信息中可以看到公鑰信息，以及sha256哈希算法生成的數(shù)據(jù)指紋(數(shù)據(jù)摘要)。

下面是完整的證書認(rèn)證+非對稱加密+對稱加密 通信的完整流程，需要注意的是服務(wù)器返回的是包含公鑰以及其他各種信息的數(shù)字證書。

2.5.4 常見問題

1.為什么摘要內(nèi)容在?絡(luò)傳輸?shù)臅r候?定要加密形成簽名?

防止中間人對證書進(jìn)行篡改。使用CA私鑰加密后，如果中間人篡改證書中的明文內(nèi)容或簽名或公鑰，則客戶端使用CA公鑰解密后一定能察覺到。

2.為什么簽名不直接加密，?是要先hash形成摘要?

摘要的長度要比原始文本較小，而文本長度小的話，加密和解密的速度也就會變快，這樣可以提升加密文本的傳輸效率。
同時某些加密算法對加密文本的長度是有要求的，不能過長。

3.如何成為中間?(了解即可)？

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

到了這里，關(guān)于【Linux】應(yīng)用層協(xié)議：HTTP和HTTPS的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！