當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

炸裂！万字长文拿下HTTP！

發(fā)布時(shí)間：2025/3/16 编程问答 23 豆豆

生活随笔收集整理的這篇文章主要介紹了炸裂！万字长文拿下HTTP！小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

本文將從以下幾個(gè)方面進(jìn)行分享。其中包括HTTP發(fā)展史，HTTP緩存代理機(jī)制，常用的web攻擊，HTTP和HTTPS的流量識(shí)別，網(wǎng)絡(luò)協(xié)議學(xué)習(xí)的工具推薦以及高頻HTTP與HTTPS的高頻面試題題解等，開工。

提綱

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í)一門知識(shí)，采用五分鐘時(shí)間看看這個(gè)知識(shí)是干啥的可能會(huì)更加有目的性。HTTP可謂無(wú)處不在，這里例舉出幾個(gè)。

HTTP應(yīng)用場(chǎng)景

2 HTTP是什么

HTTP(hypertext transport protocol)翻譯過來(lái)為"超文本傳輸協(xié)議"，文本可以理解為簡(jiǎn)單的字符文字組合，也可以理解為更為復(fù)雜的音頻或者圖像等。那么將這個(gè)詞語(yǔ)拆分為三個(gè)部分。

超文本傳輸協(xié)議

"超文本"和"文本"相比多了一個(gè)字"超"，這樣看來(lái)比文本豐富，因?yàn)樗梢詫⒍喾N文本/圖像等進(jìn)行混合，更重要的是可以從一個(gè)文本跳轉(zhuǎn)到另一個(gè)文本(文本連接)。

"傳輸"，傳輸?shù)倪^程中需要溝通，溝通即可能一對(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)的懲罰。

三方協(xié)議

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)求過程如下

應(yīng)用層的HTTP建立在傳輸層的TCP之上并運(yùn)用TCP可靠性等特性，先三次握手建立連接
客戶端請(qǐng)求建立連接(此時(shí)只有GET)
服務(wù)端響應(yīng)請(qǐng)求，數(shù)據(jù)以 ASCII 字符流返回給客戶端
傳輸完成，斷開連接。

HTTP 0.9

HTTP1.0

隨著時(shí)代的進(jìn)步，僅僅文本的傳輸無(wú)法滿足需求，更多情況需要采用圖文的方式才能生動(dòng)的表達(dá)出自己的觀點(diǎn)。隨著1995年開發(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í)添加文件處理類型
加入HTTP Header，讓HTTP處理請(qǐng)求更加靈活
增加響應(yīng)狀態(tài)碼，標(biāo)記出錯(cuò)的原因
提供國(guó)際化(不同語(yǔ)言)支持

典型的請(qǐng)求過程

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通信過程

HTTP1.0

HTTP /1.1

1995年是不平凡的一年，網(wǎng)景公司和微軟開啟瀏覽器大戰(zhàn)，誰(shuí)都想當(dāng)老大。1999年HTTP/1.1發(fā)布并成為標(biāo)準(zhǔn)，寫入RFC，以為以后不管是網(wǎng)關(guān)還是APP等，只要你要使用HTTP，就得遵守這個(gè)標(biāo)準(zhǔn)。

繼續(xù)增加了PUT等方法
允許持久連接

隨著文件越來(lái)越大，圖片等信息越來(lái)越復(fù)雜，如果每一次上傳下載文件都需要建立連接斷開連接的過程將增加大量的開銷。為此，提出了持久連接，也就是一次TCP連接可以具有多個(gè)HTTP請(qǐng)求。當(dāng)然持久連接是可選擇的，如果考慮關(guān)閉，只需要使用Connecttion:close關(guān)閉即可。長(zhǎng)連接如下圖所示

長(zhǎng)連接

強(qiáng)制要求Host頭

我們知道，在電商系統(tǒng)中，經(jīng)常會(huì)因?yàn)榇黉N活動(dòng)導(dǎo)致流量飆升，為了緩解流量，其中有種方法即加緩存或者加服務(wù)器。如果是單臺(tái)服務(wù)器負(fù)載過大，數(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)。轎車啟動(dòng)不會(huì)按下按鈕就直接起飛，而是緩慢調(diào)節(jié)到適合的速度。這不是挺好的？為什么會(huì)帶來(lái)性能問題呢。我們知道一個(gè)頁(yè)面有靜態(tài)數(shù)據(jù)，動(dòng)態(tài)頁(yè)面，很多小文件在加載的過程中就會(huì)直接發(fā)起請(qǐng)求，這樣導(dǎo)致太多的請(qǐng)求都會(huì)經(jīng)歷慢啟動(dòng)過程，花費(fèi)時(shí)間太多。

原因2 多條TCP連接帶寬競(jìng)爭(zhēng)

帶寬固定，多條TCP連接同時(shí)發(fā)起競(jìng)爭(zhēng)帶寬資源，由于各個(gè)TCP連接之間沒有通信機(jī)制，也無(wú)法得知哪些資源優(yōu)先級(jí)更高，從而導(dǎo)致想快速下載的資源反而延遲下載。

原因3 頭部阻塞

阻塞，在網(wǎng)絡(luò)編程中，我們采用異步，多路復(fù)用(epoll)方式盡量讓cpu少等待多干事。在HTTP1.1中，雖然大家共用了一條TCP通道，但是第一個(gè)請(qǐng)求沒有結(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是一問一答的模式，大家都在這個(gè)隊(duì)列排隊(duì)導(dǎo)致堵塞，那就多個(gè)隊(duì)列并發(fā)進(jìn)行，也就是"對(duì)同一個(gè)域名發(fā)起多個(gè)長(zhǎng)連接"。舉個(gè)例子，在火車站排隊(duì)買票的時(shí)候，如果只有一個(gè)窗口可用，大家只能苦等，多開幾個(gè)窗口就可緩解這個(gè)問題。

這個(gè)時(shí)候用戶數(shù) * 并發(fā)數(shù)(上限6-8)已經(jīng)不錯(cuò)得效果，但是互聯(lián)網(wǎng)速度太快，火車站就這么大，窗口也就這么多，怎么辦，建新的火車站進(jìn)行分流(大部分城市都有什么東站西站)。在這里叫做"域名分片"，使用多個(gè)域名，這些域名指向同一服務(wù)器。

HTTP/3

HTTP/2看似很完美了吧，但是Google輪子哥可不服，其他人在研究HTTP/2的時(shí)候，它們就在琢磨QUIC。那QUIC有啥牛掰的地方呢

QUIC是Google開發(fā)的一個(gè)基于UDP且能像TCP一樣具有可靠性特點(diǎn)的協(xié)議。具備像HTTP/2一樣的應(yīng)用數(shù)據(jù)二進(jìn)制分幀傳輸。其主要解決的問題有兩個(gè)。

進(jìn)一步解決線頭阻塞問題。通過獨(dú)立不同流，讓各個(gè)流之間實(shí)現(xiàn)相互獨(dú)立傳輸，互不干擾

切換網(wǎng)絡(luò)時(shí)的連接保持。wifi和3G/4G經(jīng)常需要來(lái)回切換。基于TCP的協(xié)議，會(huì)因?yàn)榫W(wǎng)絡(luò)的切換導(dǎo)致IP地址的改變。而基于UDP的QUIC協(xié)議，及時(shí)切換也可以恢復(fù)之前與服務(wù)器的連接。(這里推薦大家可以去看看MPTCP)

4 HTTP報(bào)文詳解

客戶端與服務(wù)端進(jìn)行交互的信息為報(bào)文。客戶端為請(qǐng)求報(bào)文，服務(wù)端為響應(yīng)報(bào)文。我們先用wireshark抓一個(gè)博客看看

報(bào)文層次結(jié)構(gòu)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)求方法：一共有八種方法選擇，如下圖所示。采用不同的方法獲取不同的資源

HTTP請(qǐng)求方法詳解

說(shuō)一下非常常見的幾種請(qǐng)求方法

Get：從服務(wù)器中取資源。可以請(qǐng)求圖片，視頻等

HEAD:和Get類似，但是從服務(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ú)論開發(fā)，測(cè)試運(yùn)維配置都離不開URI,所以好好掌握。

網(wǎng)絡(luò)層的IP主要目的是解決路由和尋址。現(xiàn)在的IP地址按照"."分割，總共2的32次方大約42億。對(duì)于計(jì)算機(jī)來(lái)說(shuō)比較方便，但是對(duì)于人類來(lái)說(shuō)還是不容易記憶，此時(shí)出現(xiàn)DNS了，他把IP地址映射為我們平時(shí)常見的"redis.org"，按照"."分割域名，從左到右級(jí)別越高，最右邊為"頂級(jí)域名"。如下圖所示

域名體系

好了，現(xiàn)在TCP提供可靠(數(shù)據(jù)不丟失)且字節(jié)流(數(shù)據(jù)完整性)，而且也有方便我們記憶的域名，但是互聯(lián)網(wǎng)資源千萬(wàn)種，也不知道訪問什么(圖片，文字，視頻一大堆)，這個(gè)時(shí)候URI(統(tǒng)一資源標(biāo)識(shí)符)出現(xiàn)了，那長(zhǎng)啥樣？

URI格式

協(xié)議名:HTTP協(xié)議，另外還有ftp等協(xié)議。告知訪問資源時(shí)使用什么協(xié)議。

緊接著是分隔符:"://"

主機(jī)名：標(biāo)記互聯(lián)網(wǎng)主機(jī)，可以是IP也可以是域名，如果不寫端口則使用默認(rèn)端口，例如HTTP為80，HTTPS為443.

登錄認(rèn)證信息：登錄主機(jī)時(shí)的用戶名密碼(不建議，直接告訴了別人你的隱私信息)

主機(jī)名：此處可以是域名也可以是IP，如果不寫端口號(hào)則是默認(rèn)端口。比如HTTP默認(rèn)端口為80，HTTPS默認(rèn)端口為443

資源所在位置：資源在主機(jī)上的位置，使用“/”分隔多級(jí)目錄，在這里是“/en/download.html”。注意，必須"/"開頭

參數(shù)：用"?"開始，表示額外的請(qǐng)求要求。通常使用"key=value"的方式存在，如果多個(gè)"key=value"則使用"&"相連。

看幾個(gè)例子

http://nginx.org/en/download.html

file:///E:/Demo/index/

這里注意是三個(gè)"///"，因?yàn)榍懊?#34;://"作為分隔符，資源路徑按照"/"開頭。

既然規(guī)則這么多，對(duì)于接收方而言需要完成的解析也需要遵守規(guī)則，全球用戶很多使用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í)，通過返回不同的值代表不同的語(yǔ)義。

狀態(tài)碼一共分為5類。

1××：處于中間狀態(tài)，還需后續(xù)操作

2××：成功收到報(bào)文并正確處理

"200 OK"

最常見的成功狀態(tài)碼，表示一切正常，客戶端獲得期許的處理結(jié)果。如果不是Head請(qǐng)求，那么在響應(yīng)頭中通常會(huì)有body數(shù)據(jù)。

"204 No Content"

這個(gè)的含義和"200"很相似，不同之處在于它的響應(yīng)頭中沒有body數(shù)據(jù)。

"206 Partial Content"

是 HTTP 分塊下載或斷點(diǎn)續(xù)傳的基礎(chǔ)，在客戶端發(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ù)的具體范圍，供客戶端確認(rèn)，例如“Content-Range: bytes 0-99/5000”，意思是此次獲取的是總計(jì) 5000 個(gè)字節(jié)的前 100 個(gè)字節(jié)。

3××：重定向到其他資源位置

"301 Moved Permanently"

“永久重定向”，意思是本地請(qǐng)求的資源以及不存在，使用新的URI再次訪問。

“302 Found”

“Moved Temporarily”，“臨時(shí)重定向”，臨時(shí)則所請(qǐng)求的資源暫時(shí)還在，但是目前需要用另一個(gè)URI訪問。

301 和 302 通過在字段Location中表明需要跳轉(zhuǎn)的URI。兩者最大的不同在于一個(gè)是臨時(shí)改變，一個(gè)是永久改變。舉個(gè)例子，有時(shí)候需要將網(wǎng)站全部升級(jí)為HTTPS，這種永久性改變就需要配置永久的"301"。有時(shí)候晚上更新系統(tǒng)，系統(tǒng)暫時(shí)不可用，可以配置"302"臨時(shí)訪問，此時(shí)不會(huì)做緩存優(yōu)化，第二天還會(huì)訪問原來(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ò)誤過于籠統(tǒng)。不知道是客戶端還是哪里的錯(cuò)誤，所以在實(shí)際應(yīng)用中，通常會(huì)返回含有明確含義的狀態(tài)碼。

“403 Forbidden”

注意了，這一個(gè)是表示服務(wù)器禁止訪問資源。原因比如涉及到敏感詞匯、法律禁止等。當(dāng)然，如果能讓客戶端有一個(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"

客戶端資源無(wú)法滿足客戶端請(qǐng)求的條件，例如請(qǐng)求需要中文但只有英文；

"408 Request Timeout"

請(qǐng)求超時(shí)，服務(wù)器等待了過長(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：客戶端發(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 類似，屬于一個(gè)通用的錯(cuò)誤碼，但是服務(wù)器到底是什么錯(cuò)誤我們不得而知。其實(shí)這是好事，盡量少的將服務(wù)器資源暴露外網(wǎng)，盡量保證服務(wù)器的安全。

“502 Bad Gateway”

通常是服務(wù)器作為網(wǎng)關(guān)或者代理時(shí)返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問后端服務(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”字段，指示客戶端可以在多久以后再次嘗試發(fā)送請(qǐng)求。

4 請(qǐng)求體

上面大部分都是涉及到header部分，還有非常重要的body，everybody

頭字段注意事項(xiàng)

<1> 字段名不區(qū)分大小寫，例如“Host”也可以寫成“host”，但首字母大寫的可讀性更好；

<2> 字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不能使用下劃線"_"。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正確的字段名；

<3> 字段名后面必須緊接著“:”，不能有空格，而":"后的字段值前可以有多個(gè)空格；

<4> 字段的順序是沒有意義的，可以任意排列不影響語(yǔ)義；

<5> 字段原則上不能重復(fù)，除非這個(gè)字段本身的語(yǔ)義允許，例如 Set-Cookie。

HTTP的body常常被分為這幾種的類別

<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通過變種的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ù)是分塊傳輸?shù)摹Ａ硗庠赽ody中存在一個(gè)content-length字段表示body的長(zhǎng)度，兩者不能共存，另外很多時(shí)候是流式數(shù)據(jù)，body中沒有指明content-length，這個(gè)時(shí)候一般就是chunked傳輸了。

現(xiàn)在可以通過采用分塊的方式增強(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"

我們還是看圖加深印象

chunked分塊

分塊解決了咋們一部分問題，但是有的時(shí)候我們想截?cái)喟l(fā)送怎么辦呢。在HTTP中提供了使用字段“Accept - Ranges: bytes”，明確告知客戶端：“我是支持范圍請(qǐng)求的”。那么Range范圍是怎樣的呢，Range從0開始計(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ò)等原因中斷也沒事，Range請(qǐng)求剩余即可

現(xiàn)在我們通過MIME-TYPE和Encoding-type可以知道body部分的類型，下一步將是對(duì)內(nèi)容進(jìn)行協(xié)商。HTTP中，請(qǐng)求體中使用Accept告訴服務(wù)端需要什么類型數(shù)據(jù)(我能處理哪些類型數(shù)據(jù))，響應(yīng)頭中使用Content表明發(fā)送了什么類型數(shù)據(jù)，具體如下圖所示

好了，為了各個(gè)國(guó)家民族順利友好的溝通和明確的區(qū)分。HTTP請(qǐng)求頭中使用"type-subtype"，注意此時(shí)分隔符是"-"。比如en-GB表示英式英語(yǔ)，zh-CN表示常用的漢語(yǔ)，那對(duì)于客戶端而言，它通過Accept-Language來(lái)標(biāo)記自己可以理解的自然語(yǔ)言，對(duì)應(yīng)的服務(wù)端使用Content-Language表明實(shí)體數(shù)據(jù)使用的語(yǔ)言類型，如下圖所示。

字符集和編碼

Cookie機(jī)制

HTTP是無(wú)狀態(tài)、無(wú)記憶的，Cookie機(jī)制的出現(xiàn)讓其有記憶功能，是怎么個(gè)實(shí)現(xiàn)呢

從上圖我們可以知道Cookie是由瀏覽器負(fù)責(zé)存儲(chǔ)，并不是操作系統(tǒng)負(fù)責(zé)，我們換個(gè)瀏覽器打開同樣的網(wǎng)頁(yè)，服務(wù)就認(rèn)不出來(lái)了。

Cookie常見的應(yīng)用一個(gè)是身份識(shí)別，一個(gè)是廣告追蹤，比如我們?cè)谠L問網(wǎng)頁(yè)視頻或者圖片的時(shí)候，廣告商會(huì)悄悄給我們Cookie打上標(biāo)記，方便做關(guān)聯(lián)分析和行為分析，從而給我推薦一些相關(guān)內(nèi)容。

HTTP代理

之前介紹的都是一問一答的情景，但是在大部分的情況下都會(huì)存在多臺(tái)服務(wù)器進(jìn)行通信服務(wù)。其中比較常見的就是在請(qǐng)求方與應(yīng)答方中間增加一個(gè)中間代理。

代理

代理作為中間位置，相對(duì)請(qǐng)求方為服務(wù)端，相當(dāng)于后端服務(wù)端為請(qǐng)求方。代理常見的功能為負(fù)載均衡。在負(fù)載均衡中需要區(qū)分正向代理與反向代理，其中也就會(huì)涉及調(diào)度算法，比如輪詢，一致性哈希等。

正向代理與反向代理

那么問題來(lái)了，代理作為隱藏身份，相當(dāng)于隱藏了真實(shí)的客戶端與服務(wù)端，那在是不是

5 HTTPS

好人占多數(shù)，壞人也不少。總有些要搞壞事，因?yàn)镠TTP是明文，所以需要想辦法保護(hù)明文，從而出現(xiàn)了https。

安全是什么

安全四要素

機(jī)密性

對(duì)信息進(jìn)行保密，只能可信的人可以訪問(讓我想起時(shí)間管理者)。

完整性

數(shù)據(jù)在傳輸過程中內(nèi)容不被"篡改"。雖然機(jī)密性對(duì)數(shù)據(jù)進(jìn)行保密了，但是有上策也有下策(hack)

身份認(rèn)證

證明自己的身份是本人，保證其消息發(fā)給可信的人

不可否認(rèn)

君子一言駟馬難追，說(shuō)話算數(shù)，說(shuō)過的話做過的事要有所保證

HTTPS

HTTP和HTTPS

從上圖我們知道HTTPS無(wú)非是在傳輸層和應(yīng)用層中間加了一層TLS，正是TLS緊跟當(dāng)代密碼學(xué)的步伐，盡全力的保障用戶的安全。老規(guī)矩，我們用wireshark看看長(zhǎng)什么樣子。

TLS

可以看出在交互的過程中多了不少新東西，了解TLS,TLS由SSL握手協(xié)議，SSL修改密碼規(guī)范協(xié)議，SSL警報(bào)協(xié)議，SSL記錄協(xié)議組成。

TLS組成

SSL握手協(xié)議：

相對(duì)于三次握手

記錄協(xié)議

記錄為TLS發(fā)送接收數(shù)據(jù)的基本單位。它的自協(xié)議需要通過記錄協(xié)議發(fā)出。如果多個(gè)紀(jì)錄數(shù)據(jù)則可以一個(gè)TCP包一次性發(fā)出。

警報(bào)協(xié)議

類似HTTP狀態(tài)碼，通過反饋不同的消息進(jìn)行不同的策略。

變更密碼規(guī)范協(xié)議

告訴對(duì)方，從此刻開始，后續(xù)的數(shù)據(jù)將使用加密算法進(jìn)行加密再傳輸。

對(duì)稱加密與非對(duì)稱加密

對(duì)稱加密

對(duì)稱加密，顧名思義，加密方與解密方使用同一鑰匙(秘鑰)。具體一些就是，發(fā)送方通過使用相應(yīng)的加密算法和秘鑰，對(duì)將要發(fā)送的信息進(jìn)行加密；對(duì)于接收方而言，使用解密算法和相同的秘鑰解鎖信息，從而有能力閱讀信息。

對(duì)稱加密

非對(duì)稱加密

在對(duì)稱加密中，發(fā)送方與接收方使用相同的秘鑰。那么在非對(duì)稱加密中則是發(fā)送方與接收方使用的不同的秘鑰。其主要解決的問題是防止在秘鑰協(xié)商的過程中發(fā)生泄漏。

比如在對(duì)稱加密中，小藍(lán)將需要發(fā)送的消息加密，然后告訴你密碼是123balala,ok,對(duì)于其他人而言，很容易就能劫持到密碼是123balala。那么在非對(duì)稱的情況下，小藍(lán)告訴所有人密碼是123balala,對(duì)于中間人而言，拿到也沒用，因?yàn)闆]有私鑰。所以，非對(duì)稱密鑰其實(shí)主要解決了密鑰分發(fā)的難題。如下圖

非對(duì)稱加密

其實(shí)我們經(jīng)常都在使用非對(duì)稱加密，比如使用多臺(tái)服務(wù)器搭建大數(shù)據(jù)平臺(tái)hadoop，為了方便多臺(tái)機(jī)器設(shè)置免密登錄，是不是就會(huì)涉及到秘鑰分發(fā)。再比如搭建docker集群也會(huì)使用相關(guān)非對(duì)稱加密算法。

混合加密

非對(duì)稱加密算法，大多數(shù)是從數(shù)學(xué)問題演變而來(lái)，運(yùn)算速度較慢。混合加密所謂取長(zhǎng)補(bǔ)短。通信過程中使用RSA等解決密鑰交換問題，然后使用隨機(jī)數(shù)產(chǎn)生的在對(duì)稱算法中的會(huì)話密鑰，最后使用加密。對(duì)方使用私鑰解密得到的密文取出會(huì)話秘鑰，這樣就實(shí)現(xiàn)了密鑰交換。

混合加密

通過混淆加密等方式完成了機(jī)密性任務(wù)，作為Hack只需要偽造發(fā)布公鑰或者作為之間人竊聽密文。但是我們知道安全是四要素，還需要保證數(shù)據(jù)的完整性，身份認(rèn)證等。

摘要

摘要算法可以理解為一種特殊的"單向"加密算法，無(wú)密鑰，不可逆。在平時(shí)項(xiàng)目中，應(yīng)該大家都是用過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)求建立連接過程

HTTP握手過程

注意：

首先通過非對(duì)稱加密建立通信過程

在握手階段，為什么使用3個(gè)隨機(jī)數(shù)，一方面防止「隨機(jī)數(shù) C」被猜出，另一方增加Session key隨機(jī)性

Client發(fā)出支持的「對(duì)稱/非對(duì)稱加密」算法

server返回選用的「對(duì)稱/非對(duì)稱加密」算法

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ù)，如下圖所示

Client Hello

Server端表示尊重，回復(fù)"Server Hello",同時(shí)進(jìn)行版本校對(duì)，給出隨機(jī)數(shù)(Server Random)，從Client算法列表中選擇一個(gè)密碼套件，在這里選擇的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。

cipher Suite

這里的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什么意思呢

密碼套件選擇橢圓曲線加RSA、AES、SHA256

雙方通過證書驗(yàn)證身份。因?yàn)楸緳C(jī)服務(wù)器選用了ECDHE算法，為了實(shí)現(xiàn)密鑰交換算法，它會(huì)發(fā)送證書后把橢圓曲線的公鑰（Server Params）連帶"Server Key Exchange"消息發(fā)送出去。

Server Key Exchange

意思是，剛才混合加密套件比較復(fù)雜，給你個(gè)算法參數(shù)，好好記住，別弄丟了。

ServerHelloDone

隨后服務(wù)端回復(fù)"hello done"告知打招呼完畢

打完招呼完畢后，客戶端對(duì)證書進(jìn)行核實(shí)。然后根據(jù)密碼套件也生成橢圓曲線的公鑰，用"Client Key Exchange"消息發(fā)給服務(wù)器

Client Key Exchange

此時(shí)客戶端和服務(wù)端都有了密鑰交換的兩個(gè)參數(shù)(Client Params、ServerParams），然后通過 ECDHE 算法算出了一個(gè)新的值，叫“Pre-Master”

有了主密鑰和會(huì)話密鑰，客戶端發(fā)送“Change Cipher Spec”和“Finished”消息，最后將所有消息加上摘要發(fā)送給服務(wù)器驗(yàn)證。

服務(wù)器同樣發(fā)送“Change Cipher Spec”和“Finished”消息，握手結(jié)束，開始進(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é)

寫到這里，說(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)。沒有記憶功能，少功能即少占用資源。另外無(wú)狀態(tài)更容易搭建集群，通過負(fù)載均衡將請(qǐng)求轉(zhuǎn)發(fā)到任意一臺(tái)服務(wù)器。缺點(diǎn)是無(wú)法支持需要連續(xù)步驟的"事務(wù)"操作。我們知道TCP協(xié)議有11種狀態(tài)，不同狀態(tài)代表通信過程中不同的含義。

同樣操作系統(tǒng)中的進(jìn)程也有執(zhí)行，就緒，活動(dòng)阻塞等多種狀態(tài)。但是HTTP全程都是"懵逼"無(wú)狀態(tài)。比如小華請(qǐng)求服務(wù)器獲取視頻X，服務(wù)器覺得可行就發(fā)給小華。小華還想獲取視頻Y，這時(shí)服務(wù)器不會(huì)記錄之前的狀態(tài)，也就不知道這兩個(gè)請(qǐng)求是否是同一個(gè)，所以小華還得告訴服務(wù)器自己的身份。

4：明文。優(yōu)點(diǎn)是能讓開發(fā)人員通過wireshark工具更直觀的調(diào)試。缺點(diǎn)即裸奔互聯(lián)網(wǎng)，沒隱私可言。

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é)議都太專一，而HTTP通過各種頭部字段，實(shí)體數(shù)據(jù)的組合，并綜合緩存代理等功能，不得不說(shuō)是網(wǎng)絡(luò)中的冠希哥。

7 HTTP識(shí)別(還原)

這里說(shuō)的識(shí)別，通過代碼層面(libpcap封裝)實(shí)現(xiàn)HTTP的識(shí)別，也能進(jìn)一步體現(xiàn)TCP/IP協(xié)議棧的分層特性。先看回憶一下IP頭部格式。

IP頭部

注意頭部中的協(xié)議字段，如果此字段值為0x0600則為TCP分組。當(dāng)知道了是TCP分組后，是不是可以通過TCP頭部中端口(80)就可以判斷為HTTP呢，不能的，很多情況都會(huì)使用動(dòng)態(tài)端口的方式進(jìn)行部署。

此時(shí)可以通過HTTP中的關(guān)鍵字進(jìn)行判斷。如果為HTTP，再通過頭部字段中的"Content-type"，charset等確認(rèn)文本信息，編碼方式，最后采用解碼算法進(jìn)行還原。

8 HTTPS(密文)識(shí)別

方法一也是比較直接的方法是直接通過抓包工具，插件配置即可。這里想給大家分享另一種思路和在Linux持續(xù)捕包的方法。

數(shù)據(jù)集采集

使用python的dpkt庫(kù)(pip install dpkt即可)，dpkt庫(kù)方便對(duì)每一層協(xié)議進(jìn)行拆解，同時(shí)也能進(jìn)行流的拆分以及特征的提取。下面舉一個(gè)通過無(wú)頭瀏覽的方式自動(dòng)化采集流量(ps如果需要較大規(guī)模的流量采集則可以考慮使用docker集群的方式)

Read_pcap

根據(jù)所提特征生成npz(實(shí)際上是numpy提供的數(shù)組存儲(chǔ)方式)
使用開源skearn庫(kù)進(jìn)行模型訓(xùn)練并識(shí)別預(yù)測(cè)，此處假設(shè)使用SVM(僅使用默認(rèn)參數(shù))

SVM

識(shí)別結(jié)果(參數(shù)進(jìn)行適度調(diào)整定會(huì)更好的效果)

識(shí)別結(jié)果

9 HTTP面試題測(cè)試

希望大家看完本文，下面的這些面試是不是可以秒殺了

Get和Post區(qū)別
HTTP與HTTPS區(qū)別
HTTP通信過程
游覽器輸入一個(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)景
常見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大部分通過json實(shí)現(xiàn)，無(wú)論從字節(jié)大小還是序列化耗時(shí)都比t'hrift耗時(shí)

從負(fù)載均衡來(lái)說(shuō)

RPC基本上自帶負(fù)載均衡策略，而HTTP需要配置Nginx實(shí)現(xiàn)。

巨人的肩膀

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》

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

以上是生活随笔為你收集整理的炸裂！万字长文拿下HTTP！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：。。。。。。想不通的ADO.NET。
下一篇： ASP无法上传大文件的解决方法