炸裂！萬(wàn)字長(zhǎng)文拿下HTTP 我在字節(jié)跳動(dòng)等你！
本文將從以下幾個(gè)方面進(jìn)行分享。其中包括HTTP發(fā)展史，HTTP緩存代理機(jī)制，常用的web攻擊，HTTP和HTTPS的流量識(shí)別，網(wǎng)絡(luò)協(xié)議學(xué)習(xí)的工具推薦以及高頻HTTP與HTTPS的高頻面試題題解等，開(kāi)工。
1989年，蒂姆·伯納斯 - 李（Tim Berners-Lee）在論文中提出可以在互聯(lián)網(wǎng)上構(gòu)建超鏈接文檔，并提出了三點(diǎn).
URI：統(tǒng)一資源標(biāo)識(shí)符?；ヂ?lián)網(wǎng)的唯一ID
HTML：超文本文檔
HTTP:傳輸超文本的文本傳輸協(xié)議
1 HTTP應(yīng)用在哪兒
學(xué)習(xí)一門(mén)知識(shí)，采用五分鐘時(shí)間看看這個(gè)知識(shí)是干啥的可能會(huì)更加有目的性。HTTP可謂無(wú)處不在，這里例舉出幾個(gè)。
2 HTTP是什么
HTTP(hypertext transport protocol)翻譯過(guò)來(lái)為"超文本傳輸協(xié)議"，文本可以理解為簡(jiǎn)單的字符文字組合，也可以理解為更為復(fù)雜的音頻或者圖像等。那么將這個(gè)詞語(yǔ)拆分為三個(gè)部分。
"超文本"和"文本"相比多了一個(gè)字"超"，這樣看來(lái)比文本豐富，因?yàn)樗梢詫⒍喾N文本/圖像等進(jìn)行混合，更重要的是可以從一個(gè)文本跳轉(zhuǎn)到另一個(gè)文本(文本連接)。
"傳輸"，傳輸?shù)倪^(guò)程中需要溝通，溝通即可能一對(duì)一溝通也可能一對(duì)多溝通(進(jìn)行內(nèi)容協(xié)商)，無(wú)論怎么樣，參加溝通的人數(shù)>1，想盡一切一切辦法更快更好的完成相應(yīng)的任務(wù)。
"協(xié)議"，無(wú)規(guī)矩不成方圓，做機(jī)密項(xiàng)目之前需要簽署保密協(xié)議，找工作要簽"三方協(xié)議"，三方協(xié)議是學(xué)校，公司，和個(gè)人組成的協(xié)議，都是為了讓大家受一定的約束，違反了即有相應(yīng)的懲罰。
3 不同版本的HTTP
HTTP/0.9
當(dāng)時(shí)網(wǎng)絡(luò)資源匱乏，0.9版本相對(duì)簡(jiǎn)單，采用純文本格式，且設(shè)置為只讀，所以當(dāng)時(shí)只能使用"Get"的方式從服務(wù)器獲得HTML文檔，響應(yīng)以后則關(guān)閉。如下圖所示
GET /Mysite.html
響應(yīng)中只包含了文檔本身。響應(yīng)內(nèi)容無(wú)響應(yīng)頭，無(wú)錯(cuò)誤碼，無(wú)狀態(tài)碼，可以說(shuō)是"裸奔"。
<HTML>
Hello world
</HTML>
HTTP/1.0
此時(shí)HTTP/0.9請(qǐng)求過(guò)程如下
應(yīng)用層的HTTP建立在傳輸層的TCP之上并運(yùn)用TCP可靠性等特性，先三次握手建立連接
客戶(hù)端請(qǐng)求建立連接(此時(shí)只有GET)
服務(wù)端響應(yīng)請(qǐng)求，數(shù)據(jù)以 ASCII 字符流返回給客戶(hù)端
傳輸完成，斷開(kāi)連接。
HTTP1.0
隨著時(shí)代的進(jìn)步，僅僅文本的傳輸無(wú)法滿足需求，更多情況需要采用圖文的方式才能生動(dòng)的表達(dá)出自己的觀點(diǎn)。隨著1995年開(kāi)發(fā)出Apache，同時(shí)其他的多媒體等技術(shù)發(fā)展迅速，從而進(jìn)一步的促使HTTP新功能的出現(xiàn)。HTTP1.0在1996年誕生，增加了一下幾個(gè)方面：
之前只有Get方法，現(xiàn)在增加Post(加參數(shù))，Head方法
加入?yún)f(xié)議版本號(hào)，同時(shí)添加文件處理類(lèi)型
加入HTTP Header，讓HTTP處理請(qǐng)求更加靈活
增加響應(yīng)狀態(tài)碼，標(biāo)記出錯(cuò)的原因
提供國(guó)際化(不同語(yǔ)言)支持
典型的請(qǐng)求過(guò)程
GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML>
一個(gè)包含圖片的頁(yè)面
<IMG SRC="/image.gif">
</HTML>
HTTP1.0通信過(guò)程
HTTP /1.1
1995年是不平凡的一年，網(wǎng)景公司和微軟開(kāi)啟瀏覽器大戰(zhàn)，誰(shuí)都想當(dāng)老大。1999年HTTP/1.1發(fā)布并成為標(biāo)準(zhǔn)，寫(xiě)入RFC，以為以后不管是網(wǎng)關(guān)還是APP等，只要你要使用HTTP，就得遵守這個(gè)標(biāo)準(zhǔn)。
繼續(xù)增加了PUT等方法
允許持久連接
隨著文件越來(lái)越大，圖片等信息越來(lái)越復(fù)雜，如果每一次上傳下載文件都需要建立連接斷開(kāi)連接的過(guò)程將增加大量的開(kāi)銷(xiāo)。為此，提出了持久連接，也就是一次TCP連接可以具有多個(gè)HTTP請(qǐng)求。當(dāng)然持久連接是可選擇的，如果考慮關(guān)閉，只需要使用Connecttion:close關(guān)閉即可。長(zhǎng)連接如下圖所示
強(qiáng)制要求Host頭
我們知道，在電商系統(tǒng)中，經(jīng)常會(huì)因?yàn)榇黉N(xiāo)活動(dòng)導(dǎo)致流量飆升，為了緩解流量，其中有種方法即加緩存或者加服務(wù)器。如果是單臺(tái)服務(wù)器負(fù)載過(guò)大，數(shù)據(jù)庫(kù)可能分庫(kù)分表。數(shù)據(jù)結(jié)構(gòu)算法中分而治之方法亦是如此。那么HTTP中，同樣的道理，如果文件太大，就大文件切分為小文件塊發(fā)送。
HTTP /2
HTTP/1.1的出現(xiàn)，幾年間出來(lái)大量牛掰的互聯(lián)網(wǎng)公司，發(fā)展實(shí)在是太快，但是HTTP1.1中這幾點(diǎn)成為詬病
原因1 TCP自帶慢啟動(dòng)
顧名思義，"慢啟動(dòng)"從0到1循循漸進(jìn)。轎車(chē)啟動(dòng)不會(huì)按下按鈕就直接起飛，而是緩慢調(diào)節(jié)到適合的速度。這不是挺好的？為什么會(huì)帶來(lái)性能問(wèn)題呢。我們知道一個(gè)頁(yè)面有靜態(tài)數(shù)據(jù)，動(dòng)態(tài)頁(yè)面，很多小文件在加載的過(guò)程中就會(huì)直接發(fā)起請(qǐng)求，這樣導(dǎo)致太多的請(qǐng)求都會(huì)經(jīng)歷慢啟動(dòng)過(guò)程，花費(fèi)時(shí)間太多。
原因2 多條TCP連接帶寬競(jìng)爭(zhēng)
帶寬固定，多條TCP連接同時(shí)發(fā)起競(jìng)爭(zhēng)帶寬資源，由于各個(gè)TCP連接之間沒(méi)有通信機(jī)制，也無(wú)法得知哪些資源優(yōu)先級(jí)更高，從而導(dǎo)致想快速下載的資源反而延遲下載。
原因3 頭部阻塞
阻塞，在網(wǎng)絡(luò)編程中，我們采用異步，多路復(fù)用(epoll)方式盡量讓cpu少等待多干事。在HTTP1.1中，雖然大家共用了一條TCP通道，但是第一個(gè)請(qǐng)求沒(méi)有結(jié)束，第二請(qǐng)求就可能阻塞等待，也就是說(shuō)不能同時(shí)發(fā)送接收數(shù)據(jù)。那么一個(gè)網(wǎng)頁(yè)很多數(shù)據(jù)文件，如果能夠同時(shí)發(fā)出請(qǐng)求，讓部分?jǐn)?shù)據(jù)文件能夠得到響應(yīng)并預(yù)處理，這樣就大大的利用了帶寬和cpu的資源。基于這些因素，在HTTP2中出現(xiàn)了新的方案
如何解決頭部阻塞呢？
HTTP是一問(wèn)一答的模式，大家都在這個(gè)隊(duì)列排隊(duì)導(dǎo)致堵塞，那就多個(gè)隊(duì)列并發(fā)進(jìn)行，也就是"對(duì)同一個(gè)域名發(fā)起多個(gè)長(zhǎng)連接"。舉個(gè)例子，在火車(chē)站排隊(duì)買(mǎi)票的時(shí)候，如果只有一個(gè)窗口可用，大家只能苦等，多開(kāi)幾個(gè)窗口就可緩解這個(gè)問(wèn)題。
這個(gè)時(shí)候用戶(hù)數(shù) * 并發(fā)數(shù)(上限6-8)已經(jīng)不錯(cuò)得效果，但是互聯(lián)網(wǎng)速度太快，火車(chē)站就這么大，窗口也就這么多，怎么辦，建新的火車(chē)站進(jìn)行分流(大部分城市都有什么東站 西站)。在這里叫做"域名分片"，使用多個(gè)域名，這些域名指向同一服務(wù)器。
HTTP/3
HTTP/2看似很完美了吧，但是Google輪子哥可不服，其他人在研究HTTP/2的時(shí)候，它們就在琢磨QUIC。那QUIC有啥牛掰的地方呢
QUIC是Google開(kāi)發(fā)的一個(gè)基于UDP且能像TCP一樣具有可靠性特點(diǎn)的協(xié)議。具備像HTTP/2一樣的應(yīng)用數(shù)據(jù)二進(jìn)制分幀傳輸。其主要解決的問(wèn)題有兩個(gè)。
進(jìn)一步解決線頭阻塞問(wèn)題。通過(guò)獨(dú)立不同流，讓各個(gè)流之間實(shí)現(xiàn)相互獨(dú)立傳輸，互不干擾
切換網(wǎng)絡(luò)時(shí)的連接保持。wifi和3G/4G經(jīng)常需要來(lái)回切換?；赥CP的協(xié)議，會(huì)因?yàn)榫W(wǎng)絡(luò)的切換導(dǎo)致IP地址的改變。而基于UDP的QUIC協(xié)議，及時(shí)切換也可以恢復(fù)之前與服務(wù)器的連接。(這里推薦大家可以去看看MPTCP)
4 HTTP報(bào)文詳解
客戶(hù)端與服務(wù)端進(jìn)行交互的信息為報(bào)文?？蛻?hù)端為請(qǐng)求報(bào)文，服務(wù)端為響應(yīng)報(bào)文。我們先用wireshark抓一個(gè)博客看看
GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip
請(qǐng)求報(bào)文
請(qǐng)求報(bào)文通常由三部分組成：
起始行：描述請(qǐng)求或者響應(yīng)的基本信息
頭部字段集合：key-value形式說(shuō)明報(bào)文
消息正文：實(shí)際傳輸諸如圖片等信息。具體如下圖試試
1 請(qǐng)求方法：一共有八種方法選擇，如下圖所示。采用不同的方法獲取不同的資源
說(shuō)一下非常常見(jiàn)的幾種請(qǐng)求方法
Get：從服務(wù)器中取資源?？梢哉?qǐng)求圖片，視頻等
HEAD:和Get類(lèi)似，但是從服務(wù)器請(qǐng)求的資源不會(huì)返回請(qǐng)求的實(shí)體數(shù)據(jù)，只會(huì)返回響應(yīng)頭
POST/PUT：對(duì)應(yīng)于GET，向服務(wù)器發(fā)送數(shù)據(jù)
2 URI
統(tǒng)一資源標(biāo)識(shí)符(Uniform Resource Identifier),嚴(yán)格來(lái)說(shuō)不等于網(wǎng)址，它包含URL和URN，可是URL太出名了以致于URL="網(wǎng)址"。無(wú)論開(kāi)發(fā)，測(cè)試運(yùn)維配置都離不開(kāi)URI,所以好好掌握。
網(wǎng)絡(luò)層的IP主要目的是解決路由和尋址?，F(xiàn)在的IP地址按照"."分割，總共2的32次方大約42億。對(duì)于計(jì)算機(jī)來(lái)說(shuō)比較方便，但是對(duì)于人類(lèi)來(lái)說(shuō)還是不容易記憶，此時(shí)出現(xiàn)DNS了，他把IP地址映射為我們平時(shí)常見(jiàn)的"redis.org"，按照"."分割域名，從左到右級(jí)別越高，最右邊為"頂級(jí)域名"。如下圖所示
好了，現(xiàn)在TCP提供可靠(數(shù)據(jù)不丟失)且字節(jié)流(數(shù)據(jù)完整性)，而且也有方便我們記憶的域名，但是互聯(lián)網(wǎng)資源千萬(wàn)種，也不知道訪問(wèn)什么(圖片，文字，視頻一大堆)，這個(gè)時(shí)候URI(統(tǒng)一資源標(biāo)識(shí)符)出現(xiàn)了，那長(zhǎng)啥樣？
協(xié)議名:HTTP協(xié)議，另外還有ftp等協(xié)議。告知訪問(wèn)資源時(shí)使用什么協(xié)議。
緊接著是分隔符:"://"
主機(jī)名：標(biāo)記互聯(lián)網(wǎng)主機(jī)，可以是IP也可以是域名，如果不寫(xiě)端口則使用默認(rèn)端口，例如HTTP為80，HTTPS為443.
登錄認(rèn)證信息：登錄主機(jī)時(shí)的用戶(hù)名密碼(不建議，直接告訴了別人你的隱私信息)
主機(jī)名：此處可以是域名也可以是IP，如果不寫(xiě)端口號(hào)則是默認(rèn)端口。比如HTTP默認(rèn)端口為80，HTTPS默認(rèn)端口為443
資源所在位置：資源在主機(jī)上的位置，使用“/”分隔多級(jí)目錄，在這里是“/en/download.html”。注意，必須"/"開(kāi)頭
參數(shù)：用"?"開(kāi)始，表示額外的請(qǐng)求要求。通常使用"key=value"的方式存在，如果多個(gè)"key=value"則使用"&"相連。
看幾個(gè)例子
http://nginx.org/en/download.html
file:///E:/Demo/index/
這里注意是三個(gè)"http:///"，因?yàn)榍懊?://"作為分隔符，資源路徑按照"/"開(kāi)頭。
既然規(guī)則這么多，對(duì)于接收方而言需要完成的解析也需要遵守規(guī)則，全球用戶(hù)很多使用HTTP，每個(gè)國(guó)家地區(qū)所使用語(yǔ)言不同，HTTP為了能對(duì)其進(jìn)行統(tǒng)一處理，引入了URI編碼，方法比較簡(jiǎn)單，將非ASCII或者特殊字符全部轉(zhuǎn)換為十六進(jìn)制字節(jié)值，同時(shí)在前面加入"%"。比如空格被轉(zhuǎn)換為"%20","中國(guó)"就編碼為"%E4%B8%AD%E5%9B%BD%0A"。
3 請(qǐng)求體
響應(yīng)報(bào)文
狀態(tài)行----服務(wù)器響應(yīng)的狀態(tài)
<1> 版本號(hào)：使用的HTTP什么版本
<2> 狀態(tài)碼：不同數(shù)字代表不同的結(jié)果，就如我們?cè)诰幋a時(shí)，通過(guò)返回不同的值代表不同的語(yǔ)義。
狀態(tài)碼一共分為5類(lèi)。
1××：處于中間狀態(tài)，還需后續(xù)操作
2××：成功收到報(bào)文并正確處理
"200 OK"
最常見(jiàn)的成功狀態(tài)碼，表示一切正常，客戶(hù)端獲得期許的處理結(jié)果。如果不是Head請(qǐng)求，那么在響應(yīng)頭中通常會(huì)有body數(shù)據(jù)。
"204 No Content"
這個(gè)的含義和"200"很相似，不同之處在于它的響應(yīng)頭中沒(méi)有body數(shù)據(jù)。
"206 Partial Content"
是 HTTP 分塊下載或斷點(diǎn)續(xù)傳的基礎(chǔ)，在客戶(hù)端發(fā)送“范圍請(qǐng)求”、要求獲取資源的部分?jǐn)?shù)據(jù)時(shí)出現(xiàn)，它與 200 一樣，也是服務(wù)器成功處理了請(qǐng)求，但 body 里的數(shù)據(jù)不是資源的全部，而是其中的一部分。狀態(tài)碼 206 通常還會(huì)伴隨著頭字段“Content-Range”，表示響應(yīng)報(bào)文里 body 數(shù)據(jù)的具體范圍，供客戶(hù)端確認(rèn)，例如“Content-Range: bytes 0-99/5000”，意思是此次獲取的是總計(jì) 5000 個(gè)字節(jié)的前 100 個(gè)字節(jié)。
3××：重定向到其他資源位置
"301 Moved Permanently"
“永久重定向”，意思是本地請(qǐng)求的資源以及不存在，使用新的URI再次訪問(wèn)。
“302 Found”
“Moved Temporarily”，“臨時(shí)重定向”，臨時(shí)則所請(qǐng)求的資源暫時(shí)還在，但是目前需要用另一個(gè)URI訪問(wèn)。
301 和 302 通過(guò)在字段Location中表明需要跳轉(zhuǎn)的URI。兩者最大的不同在于一個(gè)是臨時(shí)改變，一個(gè)是永久改變。舉個(gè)例子，有時(shí)候需要將網(wǎng)站全部升級(jí)為HTTPS，這種永久性改變就需要配置永久的"301"。有時(shí)候晚上更新系統(tǒng)，系統(tǒng)暫時(shí)不可用，可以配置"302"臨時(shí)訪問(wèn)，此時(shí)不會(huì)做緩存優(yōu)化，第二天還會(huì)訪問(wèn)原來(lái)的地址。
“304 Not Modified”
運(yùn)用于緩存控制。它用于 If-Modified-Since 等條件請(qǐng)求，表示資源未修改，可以理解成“重定向已到緩存的文件”（即“緩存重定向”）。
4××：請(qǐng)求報(bào)文有誤，服務(wù)器無(wú)法處理
"400 Bad Request”
通用錯(cuò)誤碼，表示請(qǐng)求報(bào)文有錯(cuò)誤，但是這個(gè)錯(cuò)誤過(guò)于籠統(tǒng)。不知道是客戶(hù)端還是哪里的錯(cuò)誤，所以在實(shí)際應(yīng)用中，通常會(huì)返回含有明確含義的狀態(tài)碼。
“403 Forbidden”
注意了，這一個(gè)是表示服務(wù)器禁止訪問(wèn)資源。原因比如涉及到敏感詞匯、法律禁止等。當(dāng)然，如果能讓客戶(hù)端有一個(gè)清晰的認(rèn)識(shí)，可以考慮說(shuō)明拒絕的原因并返回即可。
“404 Not Found”
這可能是我們都知道且都不想看到的狀態(tài)碼之一，它的本意是想要的資源在本地未找到從而無(wú)法提供給服務(wù)端，但是現(xiàn)在，只要服務(wù)器"耍脾氣"就會(huì)給你返回 404，而我們也無(wú)從得知后面到底是真的未找到，還是有什么別的原因，
"405 Method Not Allowed"
獲取資源的方法好幾種，我們可以對(duì)某些方法進(jìn)行限制。例如不允許 POST 只能 GET；
"406 Not Acceptable"
客戶(hù)端資源無(wú)法滿足客戶(hù)端請(qǐng)求的條件，例如請(qǐng)求需要中文但只有英文；
"408 Request Timeout"
請(qǐng)求超時(shí)，服務(wù)器等待了過(guò)長(zhǎng)的時(shí)間；
"409 Conflict"：
多個(gè)請(qǐng)求發(fā)生了沖突，可以理解為多線程并發(fā)時(shí)的競(jìng)態(tài)；
413 Request Entity Too Large：
請(qǐng)求報(bào)文里的 body 太大；
414 Request-URI Too Long：請(qǐng)求行里的 URI 太大；
429 Too Many Requests：客戶(hù)端發(fā)送了太多的請(qǐng)求，
通常是由于服務(wù)器的限連策略；
431 Request Header Fields Too Large：請(qǐng)求頭某個(gè)字
段或總體太大；
5××：服務(wù)器錯(cuò)誤，服務(wù)器對(duì)請(qǐng)求出的時(shí)候發(fā)生內(nèi)部錯(cuò)誤。
“500 Internal Server Error”
和400 類(lèi)似，屬于一個(gè)通用的錯(cuò)誤碼，但是服務(wù)器到底是什么錯(cuò)誤我們不得而知。其實(shí)這是好事，盡量少的將服務(wù)器資源暴露外網(wǎng)，盡量保證服務(wù)器的安全。
“502 Bad Gateway”
通常是服務(wù)器作為網(wǎng)關(guān)或者代理時(shí)返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問(wèn)后端服務(wù)器時(shí)發(fā)生了錯(cuò)誤，但具體的錯(cuò)誤原因也是不知道的。
“503 Service Unavailable”
表示服務(wù)器當(dāng)前很忙，暫時(shí)無(wú)法響應(yīng)服務(wù)，我們上網(wǎng)時(shí)有時(shí)候遇到的“網(wǎng)絡(luò)服務(wù)正忙，請(qǐng)稍后重試”的提示信息就是狀態(tài)碼 503。
503 是一個(gè)“臨時(shí)”的狀態(tài)，
暫時(shí)比較忙，稍后提供服務(wù)。在響應(yīng)報(bào)文中的“Retry-After”字段，指示客戶(hù)端可以在多久以后再次嘗試發(fā)送請(qǐng)求。
4 請(qǐng)求體
上面大部分都是涉及到header部分，還有非常重要的body，everybody
頭字段注意事項(xiàng)
<1> 字段名不區(qū)分大小寫(xiě)，例如“Host”也可以寫(xiě)成“host”，但首字母大寫(xiě)的可讀性更好；
<2> 字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不能使用下劃線"_"。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正確的字段名；
<3> 字段名后面必須緊接著“:”，不能有空格，而":"后的字段值前可以有多個(gè)空格；
<4> 字段的順序是沒(méi)有意義的，可以任意排列不影響語(yǔ)義；
<5> 字段原則上不能重復(fù)，除非這個(gè)字段本身的語(yǔ)義允許，例如 Set-Cookie。
HTTP的body常常被分為這幾種的類(lèi)別
<1> text:超文本text/html,純文本text/plain
<2> audio/video:音視頻數(shù)據(jù)
<3> application: 可能是文本，也可能是二進(jìn)制，交給上層應(yīng)用處理
<4> image: 圖像文件。image/png等
但是帶寬一定，數(shù)據(jù)大了通?？紤]使用壓縮算法進(jìn)行壓縮，在HTTP中使用Encoding type表示，常用的壓縮方式有下面幾種
<1> gzip:
一種數(shù)據(jù)格式，默認(rèn)且目前僅使用deflate算法壓縮data部分
<2> deflate:
deflate是一種壓縮算法，是huffman編碼的一種加強(qiáng)
<3> br:
br通過(guò)變種的LZ77算法、Huffman編碼以及二階文本建模等方式進(jìn)行數(shù)據(jù)壓縮，其他壓縮算法相比，它有著更高的壓塑壓縮效率
使用相應(yīng)的壓縮方法在帶寬一定的情況下確實(shí)有不錯(cuò)的效果，但是gzip等主要針對(duì)文件壓縮效果不錯(cuò)，但是對(duì)視頻就不行了。這個(gè)時(shí)候是不是可以使用數(shù)據(jù)結(jié)構(gòu)中常用的分而治之，大化小再合并的方式呢，
ok，在報(bào)文中使用"Transer-Encoding:chunked"表示，代表body部分?jǐn)?shù)據(jù)是分塊傳輸的。另外在body中存在一個(gè)content-length字段表示body的長(zhǎng)度，兩者不能共存，另外很多時(shí)候是流式數(shù)據(jù)，body中沒(méi)有指明content-length，這個(gè)時(shí)候一般就是chunked傳輸了。
現(xiàn)在可以通過(guò)采用分塊的方式增強(qiáng)帶寬的利用率，那他的編碼規(guī)則如何呢
<1> 每一個(gè)分塊包含長(zhǎng)度和數(shù)據(jù)塊
<2> 長(zhǎng)度頭按照CRLF結(jié)束
<3> 數(shù)據(jù)塊在長(zhǎng)度快后，且最后CRLF結(jié)尾
<4> 使用長(zhǎng)度0表示結(jié)束，"0\r\n\r\n"
我們還是看圖加深印象
分塊解決了咋們一部分問(wèn)題，但是有的時(shí)候我們想截?cái)喟l(fā)送怎么辦呢。在HTTP中提供了使用字段“Accept - Ranges: bytes”，明確告知客戶(hù)端：“我是支持范圍請(qǐng)求的”。那么Range范圍是怎樣的呢，Range從0開(kāi)始計(jì)算，比如Range:0-5則讀取前6個(gè)字節(jié)，服務(wù)器收到了這個(gè)請(qǐng)求，將如何回應(yīng)呢
<1> 合法性檢查。比如一共只有20字節(jié)，但是請(qǐng)求range：100-200。此時(shí)會(huì)返回416----"范圍請(qǐng)求有誤"
<2> 范圍正常，則返回216，表示請(qǐng)求數(shù)據(jù)知識(shí)一部分
<3> 服務(wù)器端在相應(yīng)投資端增加Content-Range,格式"bytes x-y/length"。
敲黑板：斷點(diǎn)續(xù)傳怎么操作？
<1> 查看服務(wù)器是否支持范圍請(qǐng)求并記錄文件大小
<2> 多個(gè)線程分別負(fù)責(zé)不同的range
<3> 下載同時(shí)記錄進(jìn)度，即使因?yàn)榫W(wǎng)絡(luò)等原因中斷也沒(méi)事，Range請(qǐng)求剩余即可
現(xiàn)在我們通過(guò)MIME-TYPE和Encoding-type可以知道body部分的類(lèi)型，下一步將是對(duì)內(nèi)容進(jìn)行協(xié)商。HTTP中，請(qǐng)求體中使用Accept告訴服務(wù)端需要什么類(lèi)型數(shù)據(jù)(我能處理哪些類(lèi)型數(shù)據(jù))，響應(yīng)頭中使用Content表明發(fā)送了什么類(lèi)型數(shù)據(jù)，具體如下圖所示
好了，為了各個(gè)國(guó)家民族順利友好的溝通和明確的區(qū)分。HTTP請(qǐng)求頭中使用"type-subtype"，注意此時(shí)分隔符是"-"。比如en-GB表示英式英語(yǔ)，zh-CN表示常用的漢語(yǔ)，那對(duì)于客戶(hù)端而言，它通過(guò)Accept-Language來(lái)標(biāo)記自己可以理解的自然語(yǔ)言，對(duì)應(yīng)的服務(wù)端使用Content-Language表明實(shí)體數(shù)據(jù)使用的語(yǔ)言類(lèi)型，如下圖所示。
Cookie機(jī)制
HTTP是無(wú)狀態(tài)、無(wú)記憶的，Cookie機(jī)制的出現(xiàn)讓其有記憶功能，是怎么個(gè)實(shí)現(xiàn)呢
從上圖我們可以知道Cookie是由瀏覽器負(fù)責(zé)存儲(chǔ)，并不是操作系統(tǒng)負(fù)責(zé)，我們換個(gè)瀏覽器打開(kāi)同樣的網(wǎng)頁(yè)，服務(wù)就認(rèn)不出來(lái)了。
Cookie常見(jiàn)的應(yīng)用一個(gè)是身份識(shí)別，一個(gè)是廣告追蹤，比如我們?cè)谠L問(wèn)網(wǎng)頁(yè)視頻或者圖片的時(shí)候，廣告商會(huì)悄悄給我們Cookie打上標(biāo)記，方便做關(guān)聯(lián)分析和行為分析，從而給我推薦一些相關(guān)內(nèi)容。
HTTP代理
之前介紹的都是一問(wèn)一答的情景，但是在大部分的情況下都會(huì)存在多臺(tái)服務(wù)器進(jìn)行通信服務(wù)。其中比較常見(jiàn)的就是在請(qǐng)求方與應(yīng)答方中間增加一個(gè)中間代理。
代理作為中間位置，相對(duì)請(qǐng)求方為服務(wù)端，相當(dāng)于后端服務(wù)端為請(qǐng)求方。代理常見(jiàn)的功能為負(fù)載均衡。在負(fù)載均衡中需要區(qū)分正向代理與反向代理，其中也就會(huì)涉及調(diào)度算法，比如輪詢(xún)，一致性哈希等。
那么問(wèn)題來(lái)了，代理作為隱藏身份，相當(dāng)于隱藏了真實(shí)的客戶(hù)端與服務(wù)端，那在是不是
5 HTTPS
好人占多數(shù)，壞人也不少?？傆行┮銐氖拢?yàn)镠TTP是明文，所以需要想辦法保護(hù)明文，從而出現(xiàn)了https。
安全是什么
機(jī)密性
對(duì)信息進(jìn)行保密，只能可信的人可以訪問(wèn)(讓我想起時(shí)間管理者)。
完整性
數(shù)據(jù)在傳輸過(guò)程中內(nèi)容不被"篡改"。雖然機(jī)密性對(duì)數(shù)據(jù)進(jìn)行保密了，但是有上策也有下策(hack)
身份認(rèn)證
證明自己的身份是本人，保證其消息發(fā)給可信的人
不可否認(rèn)
君子一言駟馬難追，說(shuō)話算數(shù)，說(shuō)過(guò)的話做過(guò)的事要有所保證
HTTPS
從上圖我們知道HTTPS無(wú)非是在傳輸層和應(yīng)用層中間加了一層TLS，正是TLS緊跟當(dāng)代密碼學(xué)的步伐，盡全力的保障用戶(hù)的安全。老規(guī)矩，我們用wireshark看看長(zhǎng)什么樣子。
可以看出在交互的過(guò)程中多了不少新東西，了解TLS,TLS由SSL握手協(xié)議，SSL修改密碼規(guī)范協(xié)議，SSL警報(bào)協(xié)議，SSL記錄協(xié)議組成。
SSL握手協(xié)議：
相對(duì)于三次握手
記錄協(xié)議
記錄為T(mén)LS發(fā)送接收數(shù)據(jù)的基本單位。它的自協(xié)議需要通過(guò)記錄協(xié)議發(fā)出。如果多個(gè)紀(jì)錄數(shù)據(jù)則可以一個(gè)TCP包一次性發(fā)出。
警報(bào)協(xié)議
類(lèi)似HTTP狀態(tài)碼，通過(guò)反饋不同的消息進(jìn)行不同的策略。
變更密碼規(guī)范協(xié)議
告訴對(duì)方，從此刻開(kāi)始，后續(xù)的數(shù)據(jù)將使用加密算法進(jìn)行加密再傳輸。
對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密
對(duì)稱(chēng)加密
對(duì)稱(chēng)加密，顧名思義，加密方與解密方使用同一鑰匙(秘鑰)。具體一些就是，發(fā)送方通過(guò)使用相應(yīng)的加密算法和秘鑰，對(duì)將要發(fā)送的信息進(jìn)行加密；對(duì)于接收方而言，使用解密算法和相同的秘鑰解鎖信息，從而有能力閱讀信息。
非對(duì)稱(chēng)加密
在對(duì)稱(chēng)加密中，發(fā)送方與接收方使用相同的秘鑰。那么在非對(duì)稱(chēng)加密中則是發(fā)送方與接收方使用的不同的秘鑰。其主要解決的問(wèn)題是防止在秘鑰協(xié)商的過(guò)程中發(fā)生泄漏。比如在對(duì)稱(chēng)加密中，小藍(lán)將需要發(fā)送的消息加密，然后告訴你密碼是123balala,ok,對(duì)于其他人而言，很容易就能劫持到密碼是123balala。那么在非對(duì)稱(chēng)的情況下，小藍(lán)告訴所有人密碼是123balala,對(duì)于中間人而言，拿到也沒(méi)用，因?yàn)闆](méi)有私鑰。所以，非對(duì)稱(chēng)密鑰其實(shí)主要解決了密鑰分發(fā)的難題。如下圖
其實(shí)我們經(jīng)常都在使用非對(duì)稱(chēng)加密，比如使用多臺(tái)服務(wù)器搭建大數(shù)據(jù)平臺(tái)hadoop，為了方便多臺(tái)機(jī)器設(shè)置免密登錄，是不是就會(huì)涉及到秘鑰分發(fā)。再比如搭建docker集群也會(huì)使用相關(guān)非對(duì)稱(chēng)加密算法。
混合加密
非對(duì)稱(chēng)加密算法，大多數(shù)是從數(shù)學(xué)問(wèn)題演變而來(lái)，運(yùn)算速度較慢?；旌霞用芩^取長(zhǎng)補(bǔ)短。通信過(guò)程中使用RSA等解決密鑰交換問(wèn)題，然后使用隨機(jī)數(shù)產(chǎn)生的在對(duì)稱(chēng)算法中的會(huì)話密鑰，最后使用加密。對(duì)方使用私鑰解密得到的密文取出會(huì)話秘鑰，這樣就實(shí)現(xiàn)了密鑰交換。
通過(guò)混淆加密等方式完成了機(jī)密性任務(wù)，作為Hack只需要偽造發(fā)布公鑰或者作為之間人竊聽(tīng)密文。但是我們知道安全是四要素，還需要保證數(shù)據(jù)的完整性，身份認(rèn)證等。
摘要
摘要算法可以理解為一種特殊的"單向"加密算法，無(wú)密鑰，不可逆。在平時(shí)項(xiàng)目中，應(yīng)該大家都是用過(guò)MD5，SHA-1。但是在TLS中使用SHA-2。
假設(shè)小A轉(zhuǎn)賬5000給小C，小A加上SHA-2摘要。網(wǎng)站計(jì)算摘要并對(duì)比，如果一致則完整可信。
此時(shí)小B想修改小A給的money，這個(gè)時(shí)候網(wǎng)站計(jì)算摘要就會(huì)發(fā)現(xiàn)不一樣，不可信
HTTPS請(qǐng)求建立連接過(guò)程
注意：
首先通過(guò)非對(duì)稱(chēng)加密建立通信過(guò)程
在握手階段，為什么使用3個(gè)隨機(jī)數(shù)，一方面防止「隨機(jī)數(shù) C」被猜出，另一方增加Session key隨機(jī)性
Client發(fā)出支持的「對(duì)稱(chēng)/非對(duì)稱(chēng)加密」算法
server返回選用的「對(duì)稱(chēng)/非對(duì)稱(chēng)加密」算法
Client對(duì)算法進(jìn)行確認(rèn)
Server對(duì)算法進(jìn)行確認(rèn)
根據(jù)wireshak結(jié)果，對(duì)TLS進(jìn)一步剖析。TCP三次握手建立連接，作為禮貌，Client先打招呼"Client Hello"。里面包含了Client的版本號(hào)、所支持的密碼套件和隨機(jī)數(shù)，如下圖所示
Server端表示尊重，回復(fù)"Server Hello",同時(shí)進(jìn)行版本校對(duì)，給出隨機(jī)數(shù)(Server Random)，從Client算法列表中選擇一個(gè)密碼套件，在這里選擇的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。
這里的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什么意思呢
密碼套件選擇橢圓曲線加RSA、AES、SHA256
雙方通過(guò)證書(shū)驗(yàn)證身份。因?yàn)楸緳C(jī)服務(wù)器選用了ECDHE算法，為了實(shí)現(xiàn)密鑰交換算法，它會(huì)發(fā)送證書(shū)后把橢圓曲線的公鑰（Server Params）連帶"Server Key Exchange"消息發(fā)送出去。
意思是，剛才混合加密套件比較復(fù)雜，給你個(gè)算法參數(shù)，好好記住，別弄丟了。
隨后服務(wù)端回復(fù)"hello done"告知打招呼完畢
打完招呼完畢后，客戶(hù)端對(duì)證書(shū)進(jìn)行核實(shí)。然后根據(jù)密碼套件也生成橢圓曲線的公鑰，用"Client Key Exchange"消息發(fā)給服務(wù)器
此時(shí)客戶(hù)端和服務(wù)端都有了密鑰交換的兩個(gè)參數(shù)(Client Params、ServerParams），然后通過(guò) ECDHE 算法算出了一個(gè)新的值，叫“Pre-Master”
有了主密鑰和會(huì)話密鑰，客戶(hù)端發(fā)送“Change Cipher Spec”和“Finished”消息，最后將所有消息加上摘要發(fā)送給服務(wù)器驗(yàn)證。
服務(wù)器同樣發(fā)送“Change Cipher Spec”和“Finished”消息，握手結(jié)束，開(kāi)始進(jìn)行HTTP請(qǐng)求與響應(yīng)
4 初探域名
我們知道域名的出現(xiàn)讓我們更容易記憶，按照"."分割，越靠近右邊級(jí)別越高。域名本質(zhì)是一個(gè)名字空間系統(tǒng)，采用多級(jí)域名的方式區(qū)分不同的國(guó)家，公司等，作為一種身份的標(biāo)識(shí)。
根域名服務(wù)器（Root DNS Server）：管理頂級(jí)域名服務(wù)器，返回“com”“net”“cn”等頂級(jí)域名服務(wù)器的 IP 地址；
頂級(jí)域名服務(wù)器（Top-level DNS Server）：管理各自域名下的權(quán)威域名服務(wù)器，比如
com 頂級(jí)域名服務(wù)器可以返回 apple.com 域名服務(wù)器的 IP 地址；
權(quán)威域名服務(wù)器（Authoritative DNS Server）：管理自己域名下主機(jī)的 IP 地址，比如apple.com 權(quán)威域名服務(wù)器可以返回 www.apple.com 的 IP 地址**
6 HTTP特點(diǎn)小結(jié)
寫(xiě)到這里，說(shuō)它簡(jiǎn)單是假的，簡(jiǎn)單的東西通常更具有擴(kuò)展的可能性。根據(jù)需求的變更，越來(lái)越復(fù)雜。
1：靈活且易擴(kuò)展，他的頭部字段很多都是可定制且可擴(kuò)展
2：應(yīng)用廣泛。各個(gè)領(lǐng)域都有涉及。"跨平臺(tái)，跨語(yǔ)言"
3：無(wú)狀態(tài)。沒(méi)有記憶功能，少功能即少占用資源。另外無(wú)狀態(tài)更容易搭建集群，通過(guò)負(fù)載均衡將請(qǐng)求轉(zhuǎn)發(fā)到任意一臺(tái)服務(wù)器。缺點(diǎn)是無(wú)法支持需要連續(xù)步驟的"事務(wù)"操作。我們知道TCP協(xié)議有11種狀態(tài)，不同狀態(tài)代表通信過(guò)程中不同的含義。同樣操作系統(tǒng)中的進(jìn)程也有執(zhí)行，就緒，活動(dòng)阻塞等多種狀態(tài)。但是HTTP全程都是"懵逼"無(wú)狀態(tài)。比如小華請(qǐng)求服務(wù)器獲取視頻X，服務(wù)器覺(jué)得可行就發(fā)給小華。小華還想獲取視頻Y，這時(shí)服務(wù)器不會(huì)記錄之前的狀態(tài)，也就不知道這兩個(gè)請(qǐng)求是否是同一個(gè)，所以小華還得告訴服務(wù)器自己的身份。
4：明文。優(yōu)點(diǎn)是能讓開(kāi)發(fā)人員通過(guò)wireshark工具更直觀的調(diào)試。缺點(diǎn)即裸奔互聯(lián)網(wǎng)，沒(méi)隱私可言。
5:可靠傳輸。HTTP為應(yīng)用層協(xié)議，基于TCP/IP，而TCP為“可靠”傳輸協(xié)議，因此HTTP能在請(qǐng)求應(yīng)答中"可靠"傳輸數(shù)據(jù)。
6：應(yīng)用層協(xié)議。應(yīng)用層協(xié)議很多，其中常用的郵件協(xié)議SMTP，上傳下載文件ftp，默認(rèn)端口22/23，SSH遠(yuǎn)程登錄(XSHELL)。這些應(yīng)用層協(xié)議都太專(zhuān)一，而HTTP通過(guò)各種頭部字段，實(shí)體數(shù)據(jù)的組合，并綜合緩存代理等功能，不得不說(shuō)是網(wǎng)絡(luò)中的冠希哥。
7 HTTP識(shí)別(還原)
這里說(shuō)的識(shí)別，通過(guò)代碼層面(libpcap封裝)實(shí)現(xiàn)HTTP的識(shí)別，也能進(jìn)一步體現(xiàn)TCP/IP協(xié)議棧的分層特性。先看回憶一下IP頭部格式。
注意頭部中的協(xié)議字段，如果此字段值為0x0600則為T(mén)CP分組。當(dāng)知道了是TCP分組后，是不是可以通過(guò)TCP頭部中端口(80)就可以判斷為HTTP呢，不能的，很多情況都會(huì)使用動(dòng)態(tài)端口的方式進(jìn)行部署。此時(shí)可以通過(guò)HTTP中的關(guān)鍵字進(jìn)行判斷。如果為HTTP，再通過(guò)頭部字段中的"Content-type"，charset等確認(rèn)文本信息，編碼方式，最后采用解碼算法進(jìn)行還原。
8 HTTPS(密文)識(shí)別
方法一也是比較直接的方法是直接通過(guò)抓包工具，插件配置即可。這里想給大家分享另一種思路和在Linux持續(xù)捕包的方法。
數(shù)據(jù)集采集
使用python的dpkt庫(kù)(pip install dpkt即可)，dpkt庫(kù)方便對(duì)每一層協(xié)議進(jìn)行拆解，同時(shí)也能進(jìn)行流的拆分以及特征的提取。下面舉一個(gè)通過(guò)無(wú)頭瀏覽的方式自動(dòng)化采集流量(ps如果需要較大規(guī)模的流量采集則可以考慮使用docker集群的方式)
根據(jù)所提特征生成npz(實(shí)際上是numpy提供的數(shù)組存儲(chǔ)方式)
使用開(kāi)源skearn庫(kù)進(jìn)行模型訓(xùn)練并識(shí)別預(yù)測(cè)，此處假設(shè)使用SVM(僅使用默認(rèn)參數(shù))
識(shí)別結(jié)果(參數(shù)進(jìn)行適度調(diào)整定會(huì)更好的效果)
9 HTTP面試題測(cè)試
希望大家看完本文，下面的這些面試是不是可以秒殺了
Get和Post區(qū)別
HTTP與HTTPS區(qū)別
HTTP通信過(guò)程
游覽器輸入一個(gè)地址。到頁(yè)面展示中間經(jīng)歷了哪些步驟？
cookies機(jī)制和session機(jī)制的區(qū)別：
HTTP請(qǐng)求報(bào)文與響應(yīng)報(bào)文格式
一次完整的HTTP請(qǐng)求所經(jīng)歷的7個(gè)步驟
HTTP優(yōu)化方案
不同版本的HTTP區(qū)別
HTTP優(yōu)點(diǎn)缺點(diǎn)
URI和URL的區(qū)別
如何判斷是否為http
HTTP 1.1引入分塊傳輸編碼提供了以下幾點(diǎn)好處
長(zhǎng)連接與短連接的區(qū)別，以及應(yīng)用場(chǎng)景
常見(jiàn)web攻擊
站內(nèi)跳轉(zhuǎn)和外部重定向有何區(qū)別
HTTP的keep-alive是干什么的？
關(guān)于Http 2.0 你知道多少？
講講304緩存的原理
HTTP與RPC異同
從傳輸協(xié)議來(lái)說(shuō)
RPC既可以基于TCP也可以基于HTTP協(xié)議，但是HTTP通常都是基于HTTP
從性能消耗來(lái)說(shuō)
RPC可以基于thrift實(shí)現(xiàn)高效二進(jìn)制傳輸。HTTP大部分通過(guò)json實(shí)現(xiàn)，無(wú)論從字節(jié)大小還是序列化耗時(shí)都比t'hrift耗時(shí)
從負(fù)載均衡來(lái)說(shuō)
RPC基本上自帶負(fù)載均衡策略，而HTTP需要配置Nginx實(shí)現(xiàn)。
嘮嗑
文章不知不久肝到這么長(zhǎng)了，也終于體會(huì)到各位大佬寫(xiě)文的不容易，不想被「白嫖」，文末點(diǎn)個(gè)「在看」吧，讓我們一起「看世界」。
巨人的肩膀
https://www.chainnews.com/articles/401950499827.htm
https://developer.mozilla.org/zhCN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://blog.csdn.net/liaynling/article/details/86743432
http://www.webkaka.com/tutorial/server/2015/021013/
http://ningg.top/introduction-of-https/
https://www.jianshu.com/p/b61695e6b473
《圖解HTTP》
《透視HTTP》
本文授權(quán)轉(zhuǎn)載自公眾號(hào)“我是程序員小賤”，作者L的存在
-END-
推薦閱讀
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！
下載文檔
