三歪熬夜寫了一篇HTTP總結(jié)
還記得我當時學(xué)習(xí)的時候，HTTP就只有三個版本，分別是HTTP1.0、HTTP1.1、HTTP/2
現(xiàn)在回過頭看HTTP/3也出了有一年多的時間了。
在我眼里，我覺得HTTP/3還是一個很新的東西，還沒這么快落地，但可以去了解一波。畢竟已經(jīng)是2018年就出來的東西了，現(xiàn)在已經(jīng)是2020年了。
https://www.zhihu.com/question/302412059
Quic(QuickUDP Internet Connections)是一種新的傳輸方式，與TCP相比，它減少了延遲。表面上，Quic非常類似于在UDP上實現(xiàn)的TCP+TLS+HTTP/2
這篇文章也不是來講HTTP/3的，主要來回顧一下HTTP究竟有哪些知識點是值得注意和重點學(xué)習(xí)的，主要內(nèi)容包括：
什么是HTTP
HTTP各個版本的特點
HTTPS
HTTP電子書，有興趣的同學(xué)可以瀏覽一波。共有「30」頁
什么是HTTP
HTTP協(xié)議是客戶端和服務(wù)器交互的一種通迅的格式
所謂的交互實際上就是「請求」和「響應(yīng)」。三歪叫你一聲（請求），你回復(fù)了三歪（響應(yīng)），這就是「交互」。
所謂的「協(xié)議」實際上就是雙方約定好的「格式」，讓雙方都能看得懂的東西而已。
我們學(xué)習(xí)HTTP的時候，最開始肯定學(xué)的是「請求」和「響應(yīng)」的格式以及相關(guān)字段是怎么樣的。
貌似我們隨便打開個網(wǎng)站，看下HTTP的請求和響應(yīng)的信息都非常多，可能會覺得很難。（這么多的東西，誰記得住啊….)
一般的開發(fā)也不會完全記住里邊的所有信息，這個是很正常的。不懂沒關(guān)系，我們把對應(yīng)的信息「復(fù)制粘貼」到搜索引擎，自然就有很多的教程「告訴」你，這個信息是什么意思。
所以，在初學(xué)的時候需要知道HTTP的請求和響應(yīng)頭原來是長這個樣子的，理解「響應(yīng)」和「請求」是什么意思，「猜測」客戶端在請求的時候會把什么信息給服務(wù)器，服務(wù)器在響應(yīng)的時候把什么信息給客戶端。
在這個過程中，我們會學(xué)到Request Method這個字段，現(xiàn)在盛行的RESTful就是充分利用這個字段的「含義」
GET：請求資源
POST：創(chuàng)建資源
PUT：更新資源
DELETE：刪除資源
也會學(xué)到Status Code這個字段，這個字段的返回值能很快定位出服務(wù)端「響應(yīng)」給我們返回了什么狀態(tài)，我們經(jīng)常會用到這個狀態(tài)值來判斷這次的請求是否存在問題，如果存在問題可能是由什么原因造成的。
說白了，在初學(xué)HTTP的時候其實就是在學(xué)HTTP「請求」和「響應(yīng)」的字段含義，這塊也不用完全把所有的「字段」給記下來，只要用到的時候會知道查就OK了。
HTTP各個版本的特點
截止到目前為止，現(xiàn)在HTTP有以下的版本：
HTTP1.0
HTTP1.1
HTTP/2
HTTP/3
學(xué)習(xí)這些版本的時候，我們可以看看「新版本」的到底解決了什么問題。目前來說，大多數(shù)都是在使用HTTP 1.1和HTTP/2
HTTP1.0默認是短連接，每次與服務(wù)器交互，都需要新開一個連接。
HTTP1.1版本：
最主要的是默認持久連接。只要客戶端服務(wù)端任意一端沒有明確提出斷開TCP連接，就一直保持連接，可以發(fā)送多次HTTP請求。
其次就是斷點續(xù)傳（Chunked transfer-coding）。利用HTTP消息頭使用分塊傳輸編碼，將實體主體分塊傳輸。
HTTP/2版本：
在
HTTP1.1提出了管線化(pipelining)理論，但是默認都是關(guān)閉的。而HTTP/2允許同時通過單一的TCP連接發(fā)起多個的請求和響應(yīng)消息不再以文本的方式傳輸，采用二進制分幀層，對頭部進行了壓縮，支持流的控制
HTTP/3版本：
HTTP1.x和HTTP/2底層都是TCP，而HTTP/3底層是UDP。使用HTTP/3能夠減少RTT「往返時延」（TCP三次握手，TLS握手）
HTTPS
HTTP協(xié)議默認是「明文」的，那就是說，如果在交互的過程中被「挾持」了，那傳輸?shù)男畔?strong style="font-size:inherit;color:rgb(233,105,0);">暴露」或者「篡改」
安全問題在網(wǎng)絡(luò)上還是很重要的，現(xiàn)在大部分的網(wǎng)站都是用的HTTPS協(xié)議
HTTPS是基于TLS上實現(xiàn)的，我這里就不贅述對稱和非對稱加密的例子了。直接來看看HTTPS的過程是怎么樣的。
首先，我們要認清一點：在網(wǎng)絡(luò)上，只要是客戶端和服務(wù)端在交互，那就有可能被挾持。而客戶端是需要確切地知道服務(wù)端是不是真實的，所以我們需要CA（公信機構(gòu)）來幫客戶端認定服務(wù)端是真實的。
服務(wù)端在使用HTTPS前，需要去認證的CA機構(gòu)申請一份數(shù)字證書。數(shù)字證書里包含有證書持有者、證書有效期、服務(wù)器公鑰等信息。
CA機構(gòu)也有自己的一份公私鑰，在發(fā)布數(shù)字證書之前，會用自己的私鑰對這份數(shù)字證書進行加密。
等到客戶端請求服務(wù)器的時候，服務(wù)端返回證書給客戶端。
客戶端用CA的公鑰對證書解密（因為CA是工信機構(gòu)，會內(nèi)置到瀏覽器或操作系統(tǒng)中，所以客戶端會有公鑰）。這個時候，客戶端會判斷這個證書是否可信/有無被篡改。
解釋：證書被CA機構(gòu)的私鑰解密，然后客戶端用CA證書的公鑰解密。這種私鑰加密，公鑰解密我們一般用來做數(shù)字簽名（看有無被篡改）
客戶端發(fā)現(xiàn)證書是可信，然后解密出服務(wù)器的公鑰?？蛻舳松梢粋€對稱加密的隨機Key，并用證書內(nèi)的公鑰進行加密，發(fā)送給服務(wù)端。
服務(wù)端收到消息，用自己的私鑰解密，拿到客戶端隨機生成的Key，加密數(shù)據(jù)后返回給客戶端。
客戶端收到消息，就可以用之前生成的Key來解密服務(wù)端返回的數(shù)據(jù)了。
三歪再簡單解釋一下：
首先客戶端跟服務(wù)器之間的交互，客戶端需要知道服務(wù)端是不是真實的。因為客戶端與服務(wù)端之間的通訊都有可能被「挾持」。所以需要有一個公信機構(gòu)CA來讓客戶端知道服務(wù)端是真實的。
CA機構(gòu)將服務(wù)端的公鑰信息用自己的私鑰加密，客戶端用CA機構(gòu)的公鑰解密。保證CA證書是沒有被篡改，是真實的。
客戶端拿到CA證書，就能解析到服務(wù)端的公鑰?？蛻舳松梢粋€Key作為對稱加密的秘鑰，用服務(wù)端的公鑰加密傳給服務(wù)端。
服務(wù)端用自己的私鑰解密客戶端的數(shù)據(jù)，得到對稱加密的秘鑰。
后續(xù)就可以通過對稱加密的秘鑰愉快發(fā)送/接收消息了。
總結(jié)
HTTP/2和HTTPS在面試的時候還是經(jīng)常會考的，我在校招面試的時候就被問到過。如果對這兩個知識點還不是很了解的同學(xué)，我建議得掌握起來。
現(xiàn)在已經(jīng)工作有一段時間了，為什么還來寫HTTP呢，原因有以下幾個：
我是一個對排版有追求的人，如果早期關(guān)注我的同學(xué)可能會發(fā)現(xiàn)，我的GitHub、文章導(dǎo)航的
read.me會經(jīng)常更換?，F(xiàn)在的GitHub導(dǎo)航也不合我心意了（太長了），并且早期的文章，說實話排版也不太行，我決定重新搞一波。我的文章會分發(fā)好幾個平臺，但文章發(fā)完了可能就沒人看了，并且圖床很可能因為平臺的防盜鏈就掛掉了。又因為有很多的讀者問我：”你能不能把你的文章轉(zhuǎn)成PDF啊？“
我寫過很多系列級的文章，這些文章就幾乎不會有太大的改動了，就非常適合把它們給”持久化“。
基于上面的原因，我決定把我的系列文章匯總成一個PDF/HTML/WORD/epub文檔。說實話，打造這么一個文檔花了我不少的時間。為了防止白嫖，關(guān)注我的公眾號回復(fù)「888」即可獲取。
HTTP電子書，有興趣的同學(xué)可以瀏覽一波。共有「30」頁
??各類知識點總結(jié)
下面的文章都有對應(yīng)的原創(chuàng)精美PDF，在持續(xù)更新中，可以來找我催更~
掃碼或者微信搜Java3y?免費領(lǐng)取原創(chuàng)思維導(dǎo)圖、精美PDF。在公眾號回復(fù)「888」領(lǐng)取，PDF內(nèi)容純手打有任何不懂歡迎來問我。
原創(chuàng)電子書
原創(chuàng)思維導(dǎo)圖
 |
|
