HTTP網(wǎng)絡(luò)協(xié)議（六）
19~20課
19.HTTPS
安全這種東西是相對的土居，盡可能提高安全性
HTTP（HyperText Transfer Protocol Secure）,譯為：超文本傳輸安全協(xié)議
常稱為HTTP over TLS枣购、HTTP over SSL、HTTP Secure
由網(wǎng)景公司于1994年首次提出
HTTPS的默認(rèn)端口號是443（HTTP是80）
現(xiàn)在在在瀏覽器輸入http://www.baidu.com
會自動(dòng)重定向到https://www.baidu.com
SSL/TLS
-HTTPS是在HTTP的基礎(chǔ)上使用SSL/TLS來加密保文擦耀，對竊聽和中間人攻擊提供合理的防護(hù)
-SSL/TLS也可以用在其他協(xié)議上棉圈，比如
FTP —> FTPS
SMTP —-> SMTPS
TLS（Transport Layer Secure）,譯為：傳輸層安全協(xié)議
-前身是SSL（Secure Sockets Layer）,譯為：安全套接層
歷史版本信息
SSL1.0:因?yàn)榇嬖趪?yán)重的安全漏洞，從未公開過
SSL2.0:1995年埂奈，已于2011年棄用（RFC_6176）
SSL3.0:1996年迄损，已于2015年棄用（RFC_7568）
TLS1.0:1999年（RFC_2246）
TLS1.1:2006年（RFC_4346）
TLS1.2:2008年（RFC_5246）
TLS1.3:2018年（RFC_8446）
SSL/TLS — 工作在哪一層
應(yīng)用層和傳輸層之間
OpenSSL
OpenSSL是SSL/TLS協(xié)議的來源實(shí)現(xiàn)，始于1998年账磺，支持Windows芹敌、Mac、Linux等平臺
Linux垮抗、Mac一般自帶OpenSSL
WIndows下安裝OpenSSL :https://
常用的命令
生成私鑰：openssl genrsa -out mj.key
生成公鑰：openssl rsa -in my.key -public -out mj.pem
可以使用OpenSSL構(gòu)建一套屬于自己的CA氏捞，自己給自己頒發(fā)證書，稱為“自簽名證書”
HTTPS的成本
證書的成本
加解密計(jì)算（消耗更多CPU資源冒版，降低訪問速度液茎。比HTTP訪問稍微慢一點(diǎn)）
降低訪問速度
有些企業(yè)的做法是，包含敏感數(shù)據(jù)的請求才使用HTTPS，其他保留使用HTTP
HTTPS的通信過程
總的可以分為三大階段
1.TCP的三次握手
2.TLS的連接
3.HTTP的請求和響應(yīng)
TLS1.2的連接
大概有10大步驟(省略了ACK步驟）
1.Client Hello
-TLS的版本
-支持加密的組件（Cipher Suite）等
加密組件是指所使用的加密算法及密鑰長度等
-一個(gè)隨機(jī)數(shù)（Client Random）
2.Server Hello
-TLS的版本號
-選擇的加密組件
是從接收到的客戶端加密組件列表中挑選出來的
3.Certificate
-服務(wù)器的公鑰證書（被CA簽名過的）
4.Server Key Exchange
-用以實(shí)現(xiàn)ECDHE算法的其中一種參數(shù)（Server Params）
ECDHE是一種密鑰交換算法
為了防止偽造捆等，Server Params經(jīng)過了服務(wù)器私鑰簽名
5.Sever Hello Done
-告知服務(wù)端：協(xié)商部分結(jié)束了
-到目前為止：客戶端和服務(wù)器之間通過明文共享了
Client Random滞造、Server Random、 Server Params
-而且栋烤，客戶端也已經(jīng)拿到了服務(wù)器的公鑰證書谒养，接下來，客戶端會驗(yàn)證證書的真實(shí)性
6.Client Key Exchange
-用以實(shí)現(xiàn)ECDHE算法的另一個(gè)參數(shù)（Client Params）
-目前為止明郭，客戶端和服務(wù)器都擁有了ECDHE算法需要兩個(gè)參數(shù)：Server Param买窟、Client Params
-客戶端，服務(wù)器都可以
使用ECDHE算法根據(jù)Server Params薯定、Client Params 計(jì)算出一個(gè)新的隨機(jī)密鑰串：Pre-master secret
然后結(jié)合Client Random始绍、Server Random、Pre-master secret 生成主密鑰
最后利用主密鑰衍生出其他密鑰：客戶端發(fā)送用的會話密鑰话侄，服務(wù)端阿松的會話密鑰等
7.Change Cipher Spec
告知服務(wù)器：之后的通信會采用計(jì)算出來的會話密鑰進(jìn)行加密
8.Finished
-包含連接至今全部保文的整體校驗(yàn)值（摘要）亏推，加密之后發(fā)給服務(wù)器
-這次握手協(xié)商是否成功，要以服務(wù)器是否能夠正確解密該保文
9.10Change Cipher Spec满葛、Finished
-到此為止径簿，客戶服務(wù)器都驗(yàn)證加密解密沒問題，握手正式結(jié)束
-后面開始傳輸加密的HTTP請求和加密了
20.SPDY_QUIC_HTTP2+HTTP3
TLS1.2連接
ECDHE密鑰加密算法
HTTP協(xié)議的不足（HTTP/1.1）
-同一時(shí)間嘀韧，一個(gè)連接智能對應(yīng)一個(gè)請求
針對同一個(gè)域名，大多數(shù)瀏覽器允許最多6個(gè)并發(fā)連接
-允許客戶端主動(dòng)發(fā)起請求
一個(gè)請求只能對應(yīng)一個(gè)響應(yīng)
-同一個(gè)回話的多次請求中缠捌，頭消息會被重復(fù)傳輸
通常會給每個(gè)傳輸增加500-800字節(jié)的開銷
如果使用Cookie, 增加的開銷有時(shí)會達(dá)到上千字節(jié)
SPDY
SPDY（speedy的縮寫）锄贷，是基于TCP的應(yīng)用層協(xié)議，它強(qiáng)制要求使用SSL/TLS
2009年11月曼月，Google宣布將SPDY作為提高網(wǎng)絡(luò)速度的內(nèi)部項(xiàng)目
SPDY與HTTP的關(guān)系
SPDY并不用于取代HTTP谊却，它只是修改了HTTP請求與響應(yīng)的傳輸方式
SPDY與HTTP的關(guān)系
SPDY并不用于取代HTTP，它只是修改了HTTP請求與響應(yīng)的傳輸方式
只需要增加一個(gè)SPDY層哑芹，現(xiàn)有的所有服務(wù)端應(yīng)用均不用做任何修改
SPDY是HTTP/2的前身
2015年9月炎辨，Google宣布移除對SPDY的支持，用到HTTP/2
HTTP/2
HTTP/2聪姿，于2015年5月以RFC_7540正式發(fā)表
根據(jù)W3Techs的數(shù)據(jù)碴萧，截至2019年6月，全球有36.5%的網(wǎng)站支持了HTTP/2
不強(qiáng)求使用SSL/TLS末购，但商業(yè)使用中基本都是用了SSL/TLS安全層
HTTP1.1和HTTP/2速度對比
HTTP/2在底層傳輸做了很多的改進(jìn)和優(yōu)化破喻，但在語意上完全與HTTP/1.1兼容
比如請求方法（如GET、POST）盟榴、Status Code曹质、各種Headers等都沒有改變
因此，想要升級到HTTP/2（只是應(yīng)用層面的東西）
-開發(fā)者不需要修改任何代碼
-只需要升級服務(wù)器配置、升級瀏覽器
底層操作系統(tǒng)內(nèi)核就不好改羽德，需要微軟修改windows內(nèi)核代碼几莽，太難了（TCP IP）
HTTP/2的特性- 二進(jìn)制格式
-HTTP/2采用二進(jìn)制格式傳輸數(shù)據(jù)，而非HTTP1.1的文本格式
-二進(jìn)制格式在協(xié)議的解析和優(yōu)化擴(kuò)展上帶來很多優(yōu)勢和可能
數(shù)據(jù)流：已建立的連接內(nèi)的雙向字節(jié)流宅静，可以承載一條或多條消息
-所有通信都在一個(gè)TCP連接上完成银觅，此連接可以承載任意數(shù)字的雙向數(shù)據(jù)流
消息：于邏輯HTTP請求或響應(yīng)消息對應(yīng)，由一些列幀組成
幀：HTTP/2通信的最小單位坏为，每個(gè)幀都包含幀頭（會標(biāo)識出當(dāng)前幀所屬的數(shù)據(jù)流）
來自不同數(shù)據(jù)流的幀可以交錯(cuò)發(fā)送究驴，然后在根據(jù)每個(gè)幀頭的數(shù)據(jù)流標(biāo)識符重新組裝
HTTP/2的特性 - 多路復(fù)用（Multipxing）
-客戶端和服務(wù)器可以將HTTP消息分解為互不依賴的幀，然后交錯(cuò)發(fā)送匀伏，最后再在另一端把它們重新組裝起來
-并行交錯(cuò)地發(fā)送多個(gè)請求洒忧，請求之間互不影響
-并行交錯(cuò)地發(fā)送多個(gè)響應(yīng)，響應(yīng)之前互不干擾
-使用一個(gè)連接并行發(fā)送多個(gè)請求和響應(yīng)
-不必在為繞過HTTP/1.1限制而做很多工作
比如把image sprites够颠、合
并CSS\CS熙侍、內(nèi)嵌CSS\JS\Base64圖片、域名分片等
精靈圖片
image sprites(也叫做CSS Sprites), 將多張小圖合并成一張大圖
最后通過CSS結(jié)合小圖的位置履磨，尺寸進(jìn)行精準(zhǔn)定位
HTTP/2的特性 - 優(yōu)先級
HTTP/2標(biāo)準(zhǔn)允許每個(gè)數(shù)據(jù)流都有一個(gè)關(guān)聯(lián)的權(quán)重和依賴關(guān)系
-可以向每個(gè)數(shù)據(jù)流分配一個(gè)介于1～256之間的整數(shù)
-每個(gè)數(shù)據(jù)流與其他數(shù)據(jù)流之間可以存在顯示依賴關(guān)系
每個(gè)客戶端可以構(gòu)建和傳遞“優(yōu)先級樹”蛉抓，表明他傾向于如何接受響應(yīng)
服務(wù)器可以使用此消息通過CPU、內(nèi)存剃诅、和其他資源的分配設(shè)定數(shù)據(jù)流處理的優(yōu)先級
-再資源數(shù)據(jù)可用之后巷送，確保高優(yōu)先級響應(yīng)以最快方式傳輸至客戶端
盡可能先給父數(shù)據(jù)流分配資源
同級數(shù)據(jù)流（共享相同父項(xiàng)）應(yīng)按其權(quán)重比例分配資源
HTTP/2的特性 - 頭部壓縮
HTTP/2的使用HPACK壓縮請求頭和響應(yīng)頭
-可以極大減少頭部，進(jìn)而提高性能
早期版本的HTTP/2和SPDY使用zlib壓縮
-早期將所傳輸頭數(shù)據(jù)的大小減少85%～88%
-但在2021年夏天矛辕，被攻擊導(dǎo)致會話劫持
-后被更安全的HPACK取代
HTTP/2的特性 - 服務(wù)器推送（Server Push）
服務(wù)器可以對一個(gè)客戶端請求發(fā)送多個(gè)響應(yīng)
-除了最初請求的響應(yīng)外笑跛，服務(wù)器還可以向客戶端推送額外資源，而無需客戶端額外明確的請求
HTTP/2的問題 - 對頭阻塞（Head of line blocking）
QUIC
HTTP/2的問題 - 握手延遲
QUIC 0ms 可以辦到0RTT建立連接
RTT（Round trip time）: 往返時(shí)延聊品，可以簡單理解為通信一來一回的時(shí)間
HTTP/3
Google 覺得HTTP/2仍不夠快飞蹂，于是有了HTTP/3
-HTTP/3由Google開發(fā)，棄用了TCP協(xié)議翻屈，改為使用基于UDP協(xié)議的QUIC協(xié)議實(shí)現(xiàn)
-QUIC（Quic UDP Internet Connections）,譯為快速UDP網(wǎng)絡(luò)連接陈哑，由Google開發(fā)，在2013年實(shí)現(xiàn)
-于2018年從HTTP-over-QUIC改為HTTP/3
![Bull pptx] - PowerPoint.JPG](https://upload-images.jianshu.io/upload_images/1623463-93a14572e15c71ff.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
HTTP/3 - 疑問
HTTP/3基于UDP伸眶，如何保證可靠傳輸惊窖？
-由QUIC來保證，它來編寫可靠傳輸代碼赚抡。只要有一層保證可靠傳輸就可以了爬坑。
假設(shè)UDP層丟了數(shù)據(jù)，QUIC層會告訴服務(wù)端涂臣，丟失了哪一部分請重發(fā)
-為何Google不開發(fā)一個(gè)新的不同于TCP盾计、UDP的傳輸層協(xié)議售担？
1.目前世界上的網(wǎng)絡(luò)設(shè)備基本只認(rèn)識TCP、UDP（UDP沒有傳輸阻塞的問題署辉，QUIC可靠部分就由Google處理好啦）
2.如果要修改傳輸層族铆，意味著操作系統(tǒng)的內(nèi)核也要修改
3.另外，由IETF標(biāo)準(zhǔn)化的許多TCP新特性都因缺乏廣泛支持而沒有得到廣泛的部署或使用
4.因此哭尝，想要開發(fā)并應(yīng)用一個(gè)新的傳輸層協(xié)議哥攘，是極其困難的一件事情
HTTP/3的特性 - 連接遷移
TCP基于4要素（源IP、源接口材鹦、源IP逝淹、目標(biāo)端口）
-切換網(wǎng)絡(luò)時(shí)，至少會有一個(gè)要素發(fā)生變化桶唐，導(dǎo)致連接發(fā)生變化
-當(dāng)連接發(fā)生變化時(shí)栅葡，如果還使用原來的TCP連接，則會導(dǎo)致連接失敗尤泽，就得等原來的連接超時(shí)后重新建立連接
-所以我們有時(shí)候發(fā)現(xiàn)切換到一個(gè)新網(wǎng)絡(luò)時(shí)欣簇，即使新網(wǎng)絡(luò)狀況良好，但內(nèi)容還是需要加載很久
-如果實(shí)現(xiàn)得很好坯约，當(dāng)檢測到網(wǎng)絡(luò)變化時(shí)立刻建立新的TCP連接熊咽，即使這樣，建立新的連接還是需要幾百浩渺的時(shí)間闹丐。
QUIC的連接不受4要素的影響横殴，當(dāng)4要素發(fā)生變化時(shí)，原連接依然維持
-QUIC連接不以4要素的影響妇智，當(dāng)4要素發(fā)生變化時(shí)滥玷，原連接依然維持
-即使IP或者端口發(fā)生變化，只要connection ID沒有變化巍棱，那么連接依然可以維持
-比如
當(dāng)設(shè)備連接到Wi-Fi時(shí)，將進(jìn)行中的下載從蜂窩網(wǎng)絡(luò)連接轉(zhuǎn)移到更快速的Wi-Fi連接
當(dāng)Wi-Fi連接不再可用時(shí)嗎蛋欣，將連接轉(zhuǎn)移到蜂窩網(wǎng)絡(luò)連接
HTTP/3的問題 - 操作系統(tǒng)內(nèi)核航徙、CPU負(fù)載
據(jù)Google和FaceBook稱，于基于TLS的HTTP/2相比陷虎，它們大規(guī)模部署QUIC需要近2倍的CPU使用量
-Linux內(nèi)核的UDP部分沒有得到像TCP那樣的優(yōu)化到踏，因?yàn)閭鹘y(tǒng)上沒有使用UDP進(jìn)行如此高速的的信息傳輸
-TCP和TLS有硬件加速，而這對于UDP很罕見尚猿，對于QUIC則基本不存在
隨著時(shí)間的推移窝稿，相信這個(gè)問題會逐步得到改善
