一、Http報(bào)文格式

具有約定格式的數(shù)據(jù)塊

請(qǐng)求報(bào)文 request

• 狀態(tài)行：本次請(qǐng)求的請(qǐng)求方式（post get）資源路徑url ?http 協(xié)議的版本號(hào)，中間用空格劃分

本次請(qǐng)求的請(qǐng)求方式（post get）資源路徑url ?http 協(xié)議的版本號(hào)，中間用空格劃分

• 請(qǐng)求頭：requestHeaders，用戶代理信息cookie信息，客戶端所接受的數(shù)據(jù)編碼格式信息
• 請(qǐng)求正文：requestBody 數(shù)據(jù)

• post中以key-value 的形式存儲(chǔ)
• get中這個(gè)部分是沒(méi)有的

紅框：固定空白行，HTTP約定了數(shù)據(jù)在傳輸?shù)臅r(shí)候請(qǐng)求頭和請(qǐng)求正文必須空出一行，用來(lái)判定請(qǐng)求頭的內(nèi)容是否被讀取完了

當(dāng)客戶端發(fā)送請(qǐng)求之后根據(jù)請(qǐng)求頭中的狀態(tài)行是post還是get做出響應(yīng)，然后把結(jié)果返回給客戶端，

響應(yīng)報(bào)文 response?

• 狀態(tài)行：http協(xié)議以及版本，狀態(tài)碼，statecode 中間用空格隔開
• 響應(yīng)頭：發(fā)送響應(yīng)的時(shí)間，回應(yīng)數(shù)據(jù)的格式，數(shù)據(jù)的長(zhǎng)度等
• 響應(yīng)正文：響應(yīng)具體的數(shù)據(jù)，responseBody?

由固定的傳輸格式形成了http協(xié)議，http是基于TCP傳輸?shù)膽?yīng)用層協(xié)議，http只是約定了數(shù)據(jù)的格式，傳輸還是要靠TCP

二、HTTP協(xié)議進(jìn)化史

Http1.0

????????Http1.0版本有個(gè)致命的問(wèn)題，TCP的鏈接無(wú)法復(fù)用，每次建立一個(gè)Http 請(qǐng)求，都需要建立一個(gè)TCP鏈接，TCP鏈接是需要3次握手的

Http1.1

????????Http1.1為了解決這個(gè)問(wèn)題約定了47種headers，其中包括了Connection:keep-alive 允許TCP鏈接數(shù)據(jù)發(fā)送完了之后繼續(xù)存活一段時(shí)間，允許一段時(shí)間內(nèi)繼續(xù)復(fù)用這個(gè)鏈接，多次請(qǐng)求共用這次鏈接，具體復(fù)用時(shí)間長(zhǎng)短由服務(wù)器控制，一般在15s 左右，這個(gè)keep-alive相當(dāng)于線程池的keepAliveTime 當(dāng)線程工作完成之后，線程存活一段時(shí)間，從而讓發(fā)出的請(qǐng)求盡早的得到響應(yīng)，跟這里同一個(gè)道理；
????????除此之外還引入了更多的緩存策略，比如Entity tag, lf-Unmodified-Since, If-Match,cache-control。所以在這個(gè)版本可以更加靈活的控制緩存數(shù)據(jù)；
????????還引入了range 這個(gè)headers 字段，允許只請(qǐng)求服務(wù)器資源的某一個(gè)部分，來(lái)達(dá)到帶寬優(yōu)化的問(wèn)題，當(dāng)客戶端有了一部分資源之后只需要向服務(wù)器請(qǐng)求剩下的資源即可，這就是文件斷點(diǎn)續(xù)傳的基礎(chǔ)
????????Http1.1是對(duì)Http1.0功能的擴(kuò)展以及對(duì)已知問(wèn)題的優(yōu)化
存在的問(wèn)題：

• *對(duì)于不同域名數(shù)據(jù)傳輸依舊是需要重新建立新的TCP連接，或者同一個(gè)域名在15s以后無(wú)法復(fù)用，斷開了，接下來(lái)的請(qǐng)求也是需要重新創(chuàng)建連接
• Http所有傳輸內(nèi)容都是明文，http無(wú)法驗(yàn)證對(duì)方身份，無(wú)法保證數(shù)據(jù)的安全性
• http請(qǐng)求報(bào)文當(dāng)中header部分?jǐn)y帶的數(shù)據(jù)內(nèi)容過(guò)大，比如cookie 數(shù)據(jù)，這樣在一定程度上增加了傳輸?shù)某杀?/li>

HTTPS

????????它的網(wǎng)絡(luò)模型就是HTTP+SSL

也就是在http上面套了一層可以處理加密信息的模塊，服務(wù)端和客戶端的傳輸都可以通過(guò)SSL 來(lái)檢測(cè)和校驗(yàn)

SSL 如何加密跟解密的？

1. 客戶端向服務(wù)器端發(fā)送請(qǐng)求，此時(shí)客戶端還會(huì)把它所支持加密的協(xié)議算法種類以及版本發(fā)送給服務(wù)端，服務(wù)端接收到請(qǐng)求之后會(huì)從客戶端支持的加密協(xié)議中選擇一個(gè)合適的，并且向客戶端確認(rèn)，之后的會(huì)話通過(guò)這種方式來(lái)加密
2. 于此同時(shí)還會(huì)把服務(wù)器的公鑰證書發(fā)送給客戶端，這個(gè)證書包含了公鑰，頒發(fā)機(jī)構(gòu)，過(guò)期時(shí)間等一些信息，采用了https協(xié)議的服務(wù)器，必須有一套數(shù)字證書的，這套證書可以自己制作，也可以向組織申請(qǐng)
3. 客戶端在收到這個(gè)證書之后進(jìn)行有效的驗(yàn)證，這個(gè)驗(yàn)證是由SSL 來(lái)完成的，首先驗(yàn)證證書的公鑰是否有效，然后頒發(fā)機(jī)構(gòu)，證書的過(guò)期時(shí)間。如果證書有異常，就會(huì)彈出一個(gè)安全警告。如果證書有效，此時(shí)就會(huì)生成一個(gè)隨機(jī)數(shù)，也就是本次會(huì)話密鑰，然后用公鑰來(lái)加密，為了安全，不能讓第三方知道本次會(huì)話密鑰，當(dāng)服務(wù)端通過(guò)數(shù)字證書的私鑰才能夠去解密，才能拿到本次會(huì)話的數(shù)據(jù)內(nèi)容
4. 把加密后的會(huì)話密鑰傳送給服務(wù)端
5. 服務(wù)端使用私鑰來(lái)解密會(huì)話密鑰，服務(wù)端拿到會(huì)話密鑰之后，就將想給返回客戶端的response 進(jìn)行加密
6. 將加密后的response返回給客戶端
7. 客戶端通過(guò)之前生成的會(huì)話密鑰進(jìn)行解密

存在的問(wèn)題：

????????由于加密導(dǎo)致傳輸慢，這個(gè)可以接受，畢竟互聯(lián)網(wǎng)安全才是第一位的

免費(fèi)簽發(fā)證書機(jī)構(gòu) Let’a Encrypt?

SPDY?

????????基于TCP的應(yīng)用層協(xié)議
????????目標(biāo)是為了優(yōu)化http協(xié)議的性能，通過(guò)數(shù)據(jù)壓縮以及多路復(fù)用，以及請(qǐng)求優(yōu)先級(jí)等多種技術(shù)縮短接口的等待時(shí)間，并且提高了數(shù)據(jù)傳輸?shù)陌踩?#xff0c;是對(duì)http協(xié)議的增強(qiáng)，綜合了http和https
特性：

• 多路復(fù)用TCP通道，減少TCP連接握手的時(shí)間，降低http的高延時(shí)，提供了網(wǎng)絡(luò)的響應(yīng)速度
• 允許請(qǐng)求設(shè)置優(yōu)先級(jí)，重要的請(qǐng)求可以得到優(yōu)先的響應(yīng)，比如在開發(fā)線程池組件的時(shí)候給每個(gè)任務(wù)設(shè)置優(yōu)先級(jí)
• 對(duì)http請(qǐng)求報(bào)文的headers數(shù)據(jù)進(jìn)行壓縮，http1.0和http1.1可能出現(xiàn)重復(fù)和冗余的數(shù)據(jù)并且在1.1的時(shí)候只能壓縮body的數(shù)據(jù)，spdy 可以對(duì)headers 進(jìn)行強(qiáng)有力的壓縮，能夠在一定程度上提高傳輸?shù)男?/li>
• 同樣基于SSL的安全傳輸，也能提高數(shù)據(jù)傳輸?shù)目煽啃?/li>

使用SPDY 的大廠：阿里，同時(shí)在使用https

缺點(diǎn)：

????????只能使用文本格式的數(shù)據(jù)傳輸

HTTP 2.0

在SPDY 基礎(chǔ)上開發(fā)了2.0，對(duì)http協(xié)議的又一次加強(qiáng)升級(jí)

• 對(duì)數(shù)據(jù)報(bào)文重新定義了數(shù)據(jù)傳輸格式，摒棄了文本傳輸，采用了二進(jìn)制格式，文本格式在各個(gè)平臺(tái)的多樣性，二進(jìn)制只有0和1的組合。變成了一個(gè)個(gè)的數(shù)據(jù)幀，這些數(shù)據(jù)幀可以在不同的通道中交錯(cuò)的發(fā)送
• TCP 通道多路復(fù)用
• 支持降級(jí)成明文傳輸，SPDY 強(qiáng)制使用SSL/TLS
• 都對(duì)header 部分進(jìn)行了壓縮，http2.0采用HPACK專有算法進(jìn)行壓縮消息頭

????????增加了二進(jìn)制分幀層，在分幀層上面http2.0會(huì)將所有的傳輸信息，分為更小單位的消息體，稱為幀，Frame ，http1.1 1.0的消息頭都會(huì)被封裝到header frame 里面，而body部分會(huì)被封裝到Date Frame 里面。http2.0可以在共享TCP鏈接基礎(chǔ)上同時(shí)的發(fā)送請(qǐng)求和響應(yīng)，請(qǐng)求發(fā)送的時(shí)候會(huì)將數(shù)據(jù)幀交錯(cuò)的發(fā)送出去，原本一種請(qǐng)求在一個(gè)TCP 鏈接里面，在http2.0里面原本的數(shù)據(jù)被拆分成多個(gè)數(shù)據(jù)幀，這些數(shù)據(jù)幀可以在不同的TCP通道中交錯(cuò)的發(fā)送，通過(guò)這種技術(shù)http2.0性能得到極大的提高

http2.0速度的極大提升主要是因?yàn)閿?shù)據(jù)編碼格式的重新定義，多路復(fù)用，還有請(qǐng)求頭數(shù)據(jù)的壓縮
http2.0使用的大廠 阿里 騰訊 百度

Http3.0（還未商用）

????????最大改變使用UDP 作為傳輸協(xié)議

• 由于TCP 是面向連接的，每次連接需要3次握手，因此http存在高延遲的問(wèn)題，UDP是無(wú)連接的，不需要三次握手
• 優(yōu)化了失敗重傳
• 流量控制

在Android P上已經(jīng)禁止了明文傳輸，在網(wǎng)絡(luò)優(yōu)化時(shí)可以采用SPDY 和http2.0或者h(yuǎn)eaders 字段做斷點(diǎn)續(xù)創(chuàng)緩存控制，鏈接保持以提高網(wǎng)絡(luò)的響應(yīng)速度