一浪默、前言

只有光頭才能變強(qiáng)

HTTP博文回顧：

• PC端：HTTP就是這么簡(jiǎn)單
• PC端：HTTP面試題都在這里
• 微信公眾號(hào)端：HTTP就是這么簡(jiǎn)單
• 微信公眾號(hào)端：HTTP面試題都在這里

本文力求簡(jiǎn)單講清每個(gè)知識(shí)點(diǎn)牡直，希望大家看完能有所收獲

二、HTTP協(xié)議的今生來(lái)世

最近在看博客的時(shí)候纳决，發(fā)現(xiàn)有的面試題已經(jīng)考HTTP/2了碰逸，于是我就順著去了解一下。

到現(xiàn)在為止阔加，HTTP協(xié)議已經(jīng)有三個(gè)版本了：

• HTTP1.0
• HTTP1.1
• HTTP/2

下面就簡(jiǎn)單聊聊他們?nèi)叩膮^(qū)別饵史，以及整理一些必要的額外知識(shí)點(diǎn)。

2.1HTTP版本之間的區(qū)別

2.1.1HTTP1.0和HTTP1.1區(qū)別

HTTP1.0和HTTP1.1最主要的區(qū)別就是：

• HTTP1.1默認(rèn)是持久化連接胜榔！

在HTTP1.0默認(rèn)是短連接：

image

簡(jiǎn)單來(lái)說(shuō)就是：每次與服務(wù)器交互胳喷，都需要新開一個(gè)連接！

image

image

試想一下：請(qǐng)求一張圖片夭织，新開一個(gè)連接厌蔽，請(qǐng)求一個(gè)CSS文件，新開一個(gè)連接摔癣，請(qǐng)求一個(gè)JS文件奴饮，新開一個(gè)連接。HTTP協(xié)議是基于TCP的择浊，TCP每次都要經(jīng)過(guò)三次握手戴卜，四次揮手，慢啟動(dòng)...這都需要去消耗我們非常多的資源的琢岩！

在HTTP1.1中默認(rèn)就使用持久化連接來(lái)解決：建立一次連接投剥，多次請(qǐng)求均由這個(gè)連接完成！(如果阻塞了担孔，還是會(huì)開新的TCP連接的)

image

相對(duì)于持久化連接還有另外比較重要的改動(dòng)：

• HTTP 1.1增加host字段
• HTTP 1.1中引入了Chunked transfer-coding江锨，范圍請(qǐng)求，實(shí)現(xiàn)斷點(diǎn)續(xù)傳(實(shí)際上就是利用HTTP消息頭使用分塊傳輸編碼糕篇，將實(shí)體主體分塊傳輸)
• HTTP 1.1管線化(pipelining)理論啄育，客戶端可以同時(shí)發(fā)出多個(gè)HTTP請(qǐng)求，而不用一個(gè)個(gè)等待響應(yīng)之后再請(qǐng)求
  • 注意：這個(gè)pipelining僅僅是限于理論場(chǎng)景下拌消，大部分桌面瀏覽器仍然會(huì)選擇默認(rèn)關(guān)閉HTTP pipelining挑豌！
  • 所以現(xiàn)在使用HTTP1.1協(xié)議的應(yīng)用，都是有可能會(huì)開多個(gè)TCP連接的！

參考資料：

• https://www.cnblogs.com/gofighting/p/5421890.html

2.1.2HTTP2基礎(chǔ)

在說(shuō)HTTP2之前氓英，不如先直觀比較一下HTTP2和HTTP1.1的區(qū)別：

• https://http2.akamai.com/demo

image

上面也已經(jīng)說(shuō)了侯勉，HTTP 1.1提出了管線化(pipelining)理論，但是僅僅是限于理論的階段上铝阐，這個(gè)功能默認(rèn)還是關(guān)閉了的址貌。

管線化(pipelining)和非管線化的區(qū)別：

image

image

HTTP Pipelining其實(shí)是把多個(gè)HTTP請(qǐng)求放到一個(gè)TCP連接中一一發(fā)送，而在發(fā)送過(guò)程中不需要等待服務(wù)器對(duì)前一個(gè)請(qǐng)求的響應(yīng)徘键；只不過(guò)练对，客戶端還是要按照發(fā)送請(qǐng)求的順序來(lái)接收響應(yīng)！

就像在超市收銀臺(tái)或者銀行柜臺(tái)排隊(duì)時(shí)一樣啊鸭，你并不知道前面的顧客是干脆利索的還是會(huì)跟收銀員/柜員磨蹭到世界末日（不管怎么說(shuō)锹淌，服務(wù)器（即收銀員/柜員）是要按照順序處理請(qǐng)求的匿值，如果前一個(gè)請(qǐng)求非常耗時(shí)（顧客磨蹭）赠制，那么后續(xù)請(qǐng)求都會(huì)受到影響。

• 在HTTP1.0中挟憔，發(fā)送一次請(qǐng)求時(shí)钟些，需要等待服務(wù)端響應(yīng)了才可以繼續(xù)發(fā)送請(qǐng)求。
• 在HTTP1.1中绊谭，發(fā)送一次請(qǐng)求時(shí)政恍，不需要等待服務(wù)端響應(yīng)了就可以發(fā)送請(qǐng)求了，但是回送數(shù)據(jù)給客戶端的時(shí)候达传，客戶端還是需要按照響應(yīng)的順序來(lái)一一接收
• 所以說(shuō)篙耗，無(wú)論是HTTP1.0還是HTTP1.1提出了Pipelining理論，還是會(huì)出現(xiàn)阻塞的情況宪赶。從專業(yè)的名詞上說(shuō)這種情況宗弯，叫做線頭阻塞（Head of line blocking）簡(jiǎn)稱：HOLB

2.1.3HTTP1.1和HTTP2區(qū)別

HTTP2與HTTP1.1最重要的區(qū)別就是解決了線頭阻塞的問題！其中最重要的改動(dòng)是：多路復(fù)用 (Multiplexing)

• 多路復(fù)用意味著線頭阻塞將不在是一個(gè)問題搂妻，允許同時(shí)通過(guò)單一的 HTTP/2 連接發(fā)起多重的請(qǐng)求-響應(yīng)消息蒙保，合并多個(gè)請(qǐng)求為一個(gè)的優(yōu)化將不再適用。
  • (我們知道：HTTP1.1中的Pipelining是沒有付諸于實(shí)際的)欲主，之前為了減少HTTP請(qǐng)求邓厕，有很多操作將多個(gè)請(qǐng)求合并，比如：Spriting(多個(gè)圖片合成一個(gè)圖片)扁瓢，內(nèi)聯(lián)Inlining(將圖片的原始數(shù)據(jù)嵌入在CSS文件里面的URL里）详恼，拼接Concatenation(一個(gè)請(qǐng)求就將其下載完多個(gè)JS文件)，分片Sharding(將請(qǐng)求分配到各個(gè)主機(jī)上)......

使用了HTTP2可能是這樣子的：

image

HTTP2所有性能增強(qiáng)的核心在于新的二進(jìn)制分幀層(不再以文本格式來(lái)傳輸了)引几，它定義了如何封裝http消息并在客戶端與服務(wù)器之間傳輸单雾。

image

看上去協(xié)議的格式和HTTP1.x完全不同了，實(shí)際上HTTP2并沒有改變HTTP1.x的語(yǔ)義，只是把原來(lái)HTTP1.x的header和body部分用frame重新封裝了一層而已

image

HTTP2連接上傳輸?shù)拿總€(gè)幀都關(guān)聯(lián)到一個(gè)“流”硅堆。流是一個(gè)獨(dú)立的屿储，雙向的幀序列可以通過(guò)一個(gè)HTTP2的連接在服務(wù)端與客戶端之間不斷的交換數(shù)據(jù)。

image

實(shí)際上運(yùn)輸時(shí)：

image

HTTP2還有一些比較重要的改動(dòng)：

• 使用HPACK對(duì)HTTP/2頭部壓縮
• 服務(wù)器推送
  • HTTP2推送資料：https://segmentfault.com/a/1190000015773338
• 流量控制
  • 針對(duì)傳輸中的流進(jìn)行控制(TCP默認(rèn)的粒度是針對(duì)連接)
• 流優(yōu)先級(jí)（Stream Priority）它被用來(lái)告訴對(duì)端哪個(gè)流更重要渐逃。

2.2HTTP2總結(jié)

HTTP1.1新改動(dòng)：

• 持久連接
• 請(qǐng)求管道化
• 增加緩存處理（新的字段如cache-control）
• 增加Host字段够掠、支持?jǐn)帱c(diǎn)傳輸?shù)?/li>

HTTP2新改動(dòng)：

• 二進(jìn)制分幀
• 多路復(fù)用
• 頭部壓縮
• 服務(wù)器推送

參考資料：

• HTTP2 GitBook電子書(中文版)：https://legacy.gitbook.com/book/ye11ow/http2-explained/details
• HTTP/2.0 相比1.0有哪些重大改進(jìn)？https://www.zhihu.com/question/34074946
• HTTP/2 新特性淺析：https://segmentfault.com/a/1190000002765886
• HTTP2學(xué)習(xí)資料：https://imququ.com/post/http2-resource.html
• HTTP2簡(jiǎn)介和基于HTTP2的Web優(yōu)化：http://caibaojian.com/toutiao/6641
• http2原理入門：https://blog.qingf.me/?p=600
• HTTP/2 對(duì)現(xiàn)在的網(wǎng)頁(yè)訪問茄菊，有什么大的優(yōu)化呢疯潭？體現(xiàn)在什么地方？https://www.zhihu.com/question/24774343/answer/96586977
• HTTP/2筆記之流和多路復(fù)用：http://www.blogjava.net/yongboy/archive/2015/03/19/423611.aspx

2.3HTTPS再次回顧

之前在面試的時(shí)候被問到了HTTPS面殖，SSL這樣的知識(shí)點(diǎn)竖哩，也沒答上來(lái)，這里也簡(jiǎn)單整理一下脊僚。

首先還是來(lái)解釋一下基礎(chǔ)的東東：

• 對(duì)稱加密：
  • 加密和解密都是用同一個(gè)密鑰
• 非對(duì)稱加密：
  • 加密用公開的密鑰相叁，解密用私鑰
  • (私鑰只有自己知道，公開的密鑰大家都知道)
• 數(shù)字簽名：
  • 驗(yàn)證傳輸?shù)膬?nèi)容是對(duì)方發(fā)送的數(shù)據(jù)
  • 發(fā)送的數(shù)據(jù)沒有被篡改過(guò)
• 數(shù)字證書（Certificate Authority）簡(jiǎn)稱CA
  • 認(rèn)證機(jī)構(gòu)證明是真實(shí)的服務(wù)器發(fā)送的數(shù)據(jù)辽幌。

3y的通訊之路：

• 遠(yuǎn)古時(shí)代：3y和女朋友聊天傳輸數(shù)據(jù)之間沒有任何的加密增淹，直接傳輸
  • 內(nèi)容被看得一清二楚，毫無(wú)隱私可言
• 上古時(shí)期：使用對(duì)稱加密的方式來(lái)保證傳輸?shù)臄?shù)據(jù)只有兩個(gè)人知道
  • 此時(shí)有個(gè)問題：密鑰不能通過(guò)網(wǎng)絡(luò)傳輸(因?yàn)闆]有加密之前乌企，都是不安全的)虑润，所以3y和女朋友先約見面一次，告訴對(duì)方密碼是多少加酵，再對(duì)話聊天拳喻。
• 中古時(shí)期：3y不單單要跟女朋友聊天，還要跟爸媽聊天的哇(同樣不想泄漏了自己的通訊信息)猪腕。那有那么多人冗澈，難道每一次都要約來(lái)見面一次嗎？(說(shuō)明維護(hù)多個(gè)對(duì)稱密鑰是麻煩的码撰！)--->所以用到了非對(duì)稱加密
  • 3y自己保留一份密碼渗柿，獨(dú)一無(wú)二的(私鑰)。告訴3y女朋友脖岛，爸媽一份密碼(這份密碼是公開的朵栖，誰(shuí)都可以拿--->公鑰)。讓他們給我發(fā)消息之前柴梆，先用那份我告訴他們的密碼加密一下陨溅，再發(fā)送給我。我收到信息之后绍在，用自己獨(dú)一無(wú)二的私鑰解密就可以了门扇！
• 近代：此時(shí)又出現(xiàn)一個(gè)問題：雖然別人不知道私鑰是什么雹有，拿不到你原始傳輸的數(shù)據(jù)，但是可以拿到加密后的數(shù)據(jù)臼寄，他們可以改掉某部分的數(shù)據(jù)再發(fā)送給服務(wù)器霸奕，這樣服務(wù)器拿到的數(shù)據(jù)就不是完整的了。
  • 3y女朋友給3y發(fā)了一條信息”3y我喜歡你“吉拳，然后用3y給的公鑰加密质帅，發(fā)給3y了丑蛤。此時(shí)不懷好意的人截取到這條加密的信息吁系，他破解不了原信息。但是他可以修改加密后的數(shù)據(jù)再傳給3y猾浦×堆可能3y拿到收到的數(shù)據(jù)就是”3y你今晚跪鍵盤吧“
• 現(xiàn)代：拿到的數(shù)據(jù)可能被篡改了魄揉，我們可以使用數(shù)字簽名來(lái)解決被篡改的問題。數(shù)字簽名其實(shí)也可以看做是非對(duì)稱加密的手段一種拭宁，具體是這樣的：得到原信息hash值洛退，用私鑰對(duì)hash值加密，另一端用公鑰解密红淡，最后比對(duì)hash值是否變了不狮。如果變了就說(shuō)明被篡改了降铸。(一端用私鑰加密在旱，另一端用公鑰解密，也確保了來(lái)源)
• 目前現(xiàn)在：好像使用了數(shù)字簽名就萬(wàn)無(wú)一失了推掸，其實(shí)還有問題桶蝎。我們使用非對(duì)稱加密的時(shí)候，是使用公鑰進(jìn)行加密的谅畅。如果公鑰被偽造了登渣，后面的數(shù)字簽名其實(shí)就毫無(wú)意義了。講到底：還是可能會(huì)被中間人攻擊~此時(shí)我們就有了CA認(rèn)證機(jī)構(gòu)來(lái)確認(rèn)公鑰的真實(shí)性毡泻！

對(duì)于數(shù)字簽名和CA認(rèn)證還是不太了解參考一下

• 阮一峰：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
• 什么是數(shù)字簽名和證書胜茧？http://www.reibang.com/p/9db57e761255

回到我們的HTTPS，HTTPS其實(shí)就是在HTTP協(xié)議下多加了一層SSL協(xié)議(ps:現(xiàn)在都用TLS協(xié)議了)

image

HTTPS采用的是混合方式加密：

image

過(guò)程是這樣子的：

image

image

• 用戶向web服務(wù)器發(fā)起一個(gè)安全連接的請(qǐng)求
• 服務(wù)器返回經(jīng)過(guò)CA認(rèn)證的數(shù)字證書仇味，證書里面包含了服務(wù)器的public key(公鑰)
• 用戶拿到數(shù)字證書呻顽，用自己瀏覽器內(nèi)置的CA證書解密得到服務(wù)器的public key
• 用戶用服務(wù)器的public key加密一個(gè)用于接下來(lái)的對(duì)稱加密算法的密鑰，傳給web服務(wù)器
  • 因?yàn)橹挥蟹?wù)器有private key可以解密丹墨，所以不用擔(dān)心中間人攔截這個(gè)加密的密鑰
• 服務(wù)器拿到這個(gè)加密的密鑰廊遍，解密獲取密鑰，再使用對(duì)稱加密算法贩挣，和用戶完成接下來(lái)的網(wǎng)絡(luò)通信

image

所以相比HTTP喉前，HTTPS 傳輸更加安全

• （1） 所有信息都是加密傳播没酣，黑客無(wú)法竊聽。
• （2） 具有校驗(yàn)機(jī)制卵迂，一旦被篡改裕便，通信雙方會(huì)立刻發(fā)現(xiàn)。
• （3） 配備身份證書见咒，防止身份被冒充闪金。

參考資料：

• 數(shù)字簽名、數(shù)字證書论颅、SSL哎垦、https是什么關(guān)系？https://www.zhihu.com/question/52493697/answer/131015846
• 淺談SSL/TLS工作原理：https://zhuanlan.zhihu.com/p/36981565
• HTTPS:https://tech.upyun.com/article/192/HTTPS%E7%B3%BB%E5%88%97%E5%B9%B2%E8%B4%A7%EF%BC%88%E4%B8%80%EF%BC%89%EF%BC%9AHTTPS%20%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3.html
• 網(wǎng)站HTTP升級(jí)HTTPS完全配置手冊(cè)：https://www.cnblogs.com/powertoolsteam/p/http2https.html

三恃疯、總結(jié)

我只是在學(xué)習(xí)的過(guò)程中漏设，把自己遇到的問題寫出來(lái)，整理出來(lái)今妄，希望可以對(duì)大家有幫助郑口。如果文章有錯(cuò)的地方，希望大家可以在評(píng)論區(qū)指正盾鳞，一起學(xué)習(xí)交流~

參考資料：

• 《圖解HTTP》

如果文章有錯(cuò)的地方歡迎指正犬性，大家互相交流。習(xí)慣在微信看技術(shù)文章腾仅，想要獲取更多的Java資源的同學(xué)乒裆，可以關(guān)注微信公眾號(hào):Java3y。為了大家方便推励，剛新建了一下qq群：742919422鹤耍，大家也可以去交流交流。謝謝支持了验辞！希望能多介紹給其他有需要的朋友

文章的目錄導(dǎo)航：

• https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang