**：
http是應用層協議，是基於tcp底層協議而來。
tcp的機制限定，每建立乙個連線需要3次握手，斷開連線則需要4次揮手。
http協議採用「請求-應答」模式，http1.0下，http1.1非keep-alive模式下，每個請求都要新建乙個連線，完成之後立即斷開連線。如果有新的請求，則要重新建立請求連線（http協議為無連線的協議）。
這樣不免造成了網路傳輸資料一定的延遲，2023年推出http1.1，雖然可以通過設定延遲時間，讓連線延遲關閉。但仍然有線頭阻塞，max-connection最大連線限制了並行請求數量等痛點，難以應對日益增長的大資料實時傳輸。
新一代http2.0協議應運而生，提高http應對高併發場景下的資料傳輸能力。
雜談：http1.1 與 http2.0 知多少？
pipelining管道化
提出管道化方案解決連線延遲，服務端可設定keep-alive來讓連線延遲關閉時間，但因為瀏覽器自身的max-connection最大連線限制，同乙個網域名稱 (host) 下的請求連線限制（同域下谷歌瀏覽器是一次限制最多6個連線），只能通過多開網域名稱來實現，這也就是我們的靜態資源選擇放到cdn上或其它網域名稱下，來提高資源載入速度。
pipelining方案需要前後端支援，但絕大部分的http**器對pipelining的支援並不友好。
只支援get/head
pipelining只支援get/head方式傳送資料，不支援post等其它方式傳輸。
頭部資訊冗餘
http是無狀態的，客戶端/服務端只能通過head的資料維護獲取狀態資訊，這樣就造成每次連線請求時都會攜帶大量冗餘的頭部資訊，頭部資訊包括cookie資訊等。
超文字協議
http1.x是超文字協議傳輸。超文字協議傳輸，傳送請求時會找出資料的開頭和結尾幀的位置，並去除多餘空格，選擇最優方式傳輸。如果使用了https，那麼還會對資料進行加密處理，一定程度上會造成傳輸速度上的損耗。
線頭阻塞
pipelining通過延遲連線關閉的方案，雖然可同時發起對服務端的多個請求，但服務端的response依舊遵循fifo（first in first out)規則 依次返回。
舉個例子客戶端傳送了1、2、3、4四個請求，如果1沒返回給客戶端，那麼2，3，4也不會返回。這就是所謂的線頭阻塞。高併發高延遲的場景下阻塞明顯。
http1.x傳輸優化方法
多個資源合併成乙個請求連線，如前端spriting雪碧圖，js/css壓縮成乙個檔案等
inlining內聯的方式，採用inline css/inline js等併入html中，減少對css/js檔案的請求
cdn資源多網域名稱**，靜態資源分布儲存在多個域下。
以上三種三種方法雖然能使http1.x協議傳輸速度提高，但也有對應的不足。
如雪碧圖，將多個小圖合併成一張大圖，降低多張小圖請求的高延遲，但是如果我只想要兩個icon小圖，卻需要載入一整張大圖，就會造成資源冗餘。合併的js/css檔案也有類似的問題。
內聯的方式，會讓我們的**變得難以維護，讓html檔案變得更大，**混合嚴重。
多網域名稱下可緩解max-connection，但不同域會讓cookie資訊無法彼此共享。
了解完http1.1的痛點，接下來就是我們新一代的http協議http2.0
前身spdy
spdy是2023年谷歌推出的是基於ssl/tls的傳輸協議，spdy有降低延遲，多路復用，頭部壓縮，服務端推送等特點，這些特點也稱為了後續http2.0的功能基石，http2.0是spdy/3 draft的優化版。
http2.0 與 spdy的區別：
http2.0 頭部壓縮採用hpack， 而spdy採用deleft。
http2.0 理論上支援明文http傳輸，而spdy強制使用https。
多路復用
（乙個域只要乙個tcp連線）實現真正的併發請求，降低延時，提高了頻寬的利用率。
頭部壓縮
客戶端/服務端進行漸進更新維護，採用hpack壓縮，節省了報文頭占用流量。
相同的頭部資訊不會通過請求傳送，延用之前請求攜帶的頭部資訊。
新增/修改的頭部資訊會被加入到head中，兩端漸進更新。
兩端會共同維護乙個head list，每次請求時都會進行檢查。
該list包括：
static (既定的頭部資訊)
dynamic (自定義的頭部資訊)
請求優先順序
每個流都有自己的優先級別，客戶端可指定優先順序。並可以做流量控制。因為http2.0的傳世允許請求併發，但是應用場景中我們要處理一些主要檔案的優先順序權重，以及資源模組依賴等。所以我們可通過設定優先順序來提高主要檔案的權重，使其優先載入請求。
服務端推送
請求不是來自客戶端「明確」的請求，是從服務端push_promise幀中提供。例如我們載入index.html, 我們可能還需要index.js, index.css等檔案。傳統的請求只有當拿到index.html，解析html中對index.js/index.css的引入才會再請求資源載入，但是通過服務端資料，可以提前將資源推送給客戶端，這樣客戶端要用到的時候直接呼叫即可，不用再傳送請求。
二進位制協議
http2.0 傳輸協議採用二進位制協議，區別與http1.x的超文字協議。更易於幀，資料報的傳送接收。http2.0是執行在tcp連線上的應用層協議，接受伺服器或傳送請求時，會自動將頭部資訊/request body分成head幀和data幀。
客戶端/服務端傳送/接收資料時，會將資料打散亂序傳送，接收資料時接收一端再通過streamid標識來將資料合併。
http2.0環境要求
http2.0理論上支援明文http傳輸，但因為其前身spdy是在tls上，他們的主人google 和 firefox 都支援tls架構，所以需要搭建http2.0 + tls成了標準。
nginx > 1.10
openssl > 1.0.2
ca證書
HTTP1 1與HTTP2 0的區別
http協議 http，人稱超文字傳輸協議，它是在應用層上的協議，與它對接的傳輸層的協議剛是tcp。為什麼不用udp呢，因為udp是不可靠的，而tcp是可以保證請求返回的順序的，這一點很重要。現在網際網路上用到的基本都是http協議。協議嘛，它就是一種規則，具體什麼規則在這裡我就不介紹了，主要討論一...
http 2 0與http 1 1的區別
http 2是http協議自1999年http1.1發布後的首個更新 主要基於spdy協議 2.0 採用二進位制 而不是文字格式 完全多路復用 而不是有序並阻塞的 只需要乙個連線即可實現並行 使用報頭壓縮 http 2降低了開銷 http 2讓伺服器可以將響應主動 推送 到客戶端快取中 為啥2.0 ...
http2 0 相對於 http1 1的優勢
1.http2.0完全是多路復用的,只需乙個連線就可實現並行 可以將不同的請求夾雜在一起,只需乙個連線就能載入乙個頁面。2.可以讓伺服器將響應主動推動到客戶端快取中 3.壓縮報頭，降低了開銷 http1.1不支援頭部壓縮,所以產生了spdy和http2.0協議,spdy使用的是通用的deflate演...