基本介紹
協定定義,協定內容,協定目標,詳細內容,語義改進,存在問題,專家評議,
協定定義
IETF會讓所有網際網路通路默認選擇的方式來引入加密，網際網路專家們將新一代加密協定稱為“HTTP 2.0”。
HTTP 2.0
HTTP 2.0協定內容
協定目標
異步連線多路復用；
最佳化Web套用交付層（HTTP 2.0）
最佳化Web套用交付層（HTTP 2.0）頭部壓縮；
請求/回響管線化；
保持與HTTP 1.1語義的向後兼容性也是該版本的一個關鍵目標。SPDY是一種HTTP兼容協定，由Google發起，Chrome、Opera、Firefox以及Amazon Silk等瀏覽器均已提供支持。HTTP實現的瓶頸之一是其並發要依賴於多重連線。HTTP管線化技術可以緩解這個問題，但也只能做到部分多路復用。此外，已經證實，由於存在中間干擾，瀏覽器無法採用管線化技術。SPDY在單個連線之上增加了一個幀層，用以多路復用多個並發流。幀層針對HTTP類的請求回響流進行了最佳化，因此運行在HTTP之上的套用，對套用開發者而言只要很小的修改甚至無需修改就可以運行在SPDY之上。SPDY對當前的HTTP協定有4個改進：
多路復用請求；
對請求劃分優先權；
壓縮HTTP頭；
伺服器推送流（即Server Push技術）；
SPDY試圖保留HTTP的現有語義，所以cookies、ETags等特性都是可用的。
詳細內容
節選：
特別是，HTTP/1.0隻允許每一個請求綁定到一個給定的連線上。 HTTP/1.1流水線只能部分地解決了並發的請求，並從線頭的阻塞受到影響。 因此，需要進行多次請求客戶端通常使用多個連線到伺服器，以減少等待時間。
此外，HTTP/1.1的報頭欄位經常重複和冗長，其中，除了產生更多或更大的網路數據包，可能會導致小的初始TCP擁塞視窗來快速填充。當多個請求在一個新的TCP連線進行， 可能會導致過度的延遲。
該文通過定義一個基礎連線的HTTP的語義最佳化的映射來解決這些問題。 具體地，它允許對請求和回響訊息交織在同一連線上，並使用高效率的編碼的HTTP報頭欄位。 它還允許請求的優先權，讓更多的重要的要求更快速的完成，進一步提高了性能。
所得到的協定被設計為更友好的網路，因為較少的TCP連線都可以使用，在比較HTTP/1.x。 這意味著與其他流和長壽命的連線，而這又導致了更有效地利用可用的網路容量競爭少。
最後，這種封裝也可以通過使用二進制訊息取景使信息更具擴展性的處理。
1.1檔案組織：
在HTTP/2.0規範被分成三個部分：開始HTTP/2.0（ 第3節 ），它涵蓋了如何一個HTTP/2.0連線啟動；成幀層（ 第4節 ），其中復用單一的TCP連線成各個獨立的幀類別，以及一個HTTP層（ 第8節 ），它指定了表達機制使用成幀層的HTTP互動。 雖然一些成幀層概念是從HTTP的隔離，建立一個通用成幀層一直沒有一個目標。 成幀層是針對HTTP協定和伺服器推送的需求。
1.2約定和術語：
中的關鍵字“必須”，“必須不”，“要求”，“應”，“不應”，“應該”，“不應該”，“建議”，“或許”，該檔案中“可選”如中解釋RFC 2119 [RFC2119]。
所有數值都是以網路位元組順序。 值是無符號，除非另有說明。 提供在十進制或十六進制文該值（如適用）。 十六進制文字的前綴為0X從十進制文本區分開來。
術語：
客戶端：端點發起HTTP連線。
連線：兩個端點之間傳輸級連線。
連線錯誤：對HTTP/2.0的連線錯誤。
端點：連線的客戶端或伺服器。
框架：通信的HTTP/2.0連線中的最小單元，包括根據幀類型結構的位元組的報頭和可變長度的序列。
同行：一個端點。 當討論一個特定的端點，“對等”指的是遙控器來討論的首要議題端點。
接收器：正在接收幀的端點。
發件人：被傳送的幀的端點。
伺服器：端點而沒有主動的HTTP連線。
流：幀在跨越一個虛擬通道的雙向流動的HTTP/2.0連線內。
流錯誤：個別HTTP/2.0流中的一個錯誤。
2， HTTP/2.0協定介紹：
HTTP/2.0提供的HTTP語義最佳化的運輸。
一個HTTP/2.0連線通過一個TCP連線（上面運行的應用程式級協定[TCP] ）。 客戶端是TCP連線發起者。
該文檔描述了使用由三個部分組成的邏輯結構的HTTP/2.0協定：成幀，溪流，和應用程式映射。 這種結構提供了主要作為一種輔助手段，規範，實現可以自由從該結構發散是必要的。
2.1的HTTP框架：HTTP/2.0提供HTTP語義的有效序列化。 HTTP請求和回響編碼為長度前綴的幀（見第4.1節 ）。
HTTP標頭欄位被壓縮成一系列包含頭塊碎片幀（參見4.3節 ）。
2.2 HTTP復用：HTTP/2.0提供了在單個連線上復用HTTP請求和回響的能力。 多個請求或回響可以同時在一個連線上使用流（傳送第5節 ）。 為了保持獨立的流，流控制和優先權是必要的。
2.3的HTTP語義：HTTP/2.0定義HTTP請求和回響如何映射到流（參見8.1節 ），並引入了新的互動模式，伺服器推送（第8.2節 ）。
3， 啟動HTTP/2.0：HTTP/2.0使用相同的“http”和“https”開頭使用HTTP/1.1的URI方案。 HTTP/2.0共享相同的默認連線埠號：80為“http”的URI和443為“https”開頭的URI。
通過這對於HTTP/2.0支持的手段被確定為不同的“http”和“https”開頭的URI。 發現為“HTTP”中的URI描述第3.2節 。 發現為“https”開頭的URI中說明第3.3節 。
3.1 HTTP/2.0版本識別：該文檔中定義的協定是使用字元串“HTTP/2.0”標識。 這種識別是用在HTTP/1.1 Upgrade頭域，在TLS的套用層協定協商的擴展 [TLSALPN]欄位，和其他地方的協定識別是必需的。
談判“HTTP/2.0”表示使用該文檔中描述的交通，保全，取景和訊息語義。
[ rfc.comment.1 ：編者註：請移除本節之前，這份檔案的最終版該發布的其餘部分]
最後，公布的RFC只有實現可以認同自己是“HTTP/2.0”。
實施例和文本貫穿該文檔的其餘部分使用“HTTP/2.0”作為唯一的編輯便利的問題。 草稿版本的實現必須不識別使用這個字元串。 唯一的例外規則是包含在連線頭中的字元串建立HTTP/2.0連線後，立即通過客戶端傳送的（參見3.5節 ）；的八位這個固定長度的序列不發生變化。
版本的協定草案的實現必須字元串“ - 草稿”和相應的草案號碼添加到標識符分隔設定之前（'/'）。 例如，草案，IETF-httpbis-http2-03使用的是字元串“HTTP-draft-03/2.0”標識。
這是基於這些版本的草案不兼容的實驗，而不是必須用不同的標識符替換字元串“草案”。 例如，一個實驗實施分組基於心情的編碼基於草案-IETF-httpbis-http2-07可能將自身標識為“HTTP-emo-07/2.0”。請注意，任何標籤必須符合所定義的“令牌”語法第3.2.6節的[HTTP-P1] 。
3.2 啟動HTTP/2.0為“http”的URI：如果客戶端發出請求到一個“http”的URI，沒有關於對HTTP/2.0的支持先驗知識使用HTTP升級機制（第6.7節的[HTTP-P1] ）。 客戶端發出，其中包括一個Upgrade頭域識別HTTP/2.0 HTTP/1.1請求。 在HTTP/1.1請求必須包含正好一個HTTP2 -設定（ 第3.2.1節 ）頭欄位。
例如：GET / default.htm的HTTP/1.1
連線方式：升級，HTTP2 - 設定
升級：HTTP/2.0
HTTP2-設定：HTTP/2.0設定的<base64url編碼payload>
包含一個實體正文的請求必須在其全部被傳送之前，客戶端可以傳送HTTP/2.0幀。 這意味著大量請求實體可以阻止使用的連線，直到它被完全傳送。
如果有後續請求的初始請求的並發性是很重要的，一個小小的請求可以被用來執行升級到HTTP/2.0，需支付額外的往返費用。
不支持HTTP/2.0的伺服器可以回響請求，就好像Upgrade頭域缺席：
HTTP/1.1 200 OK
內容長度：243
Content-Type：text / html類型
支持HTTP/2.0的伺服器可以接受一個101（切換協定）回響升級。 因此終止了101回響的空行後，伺服器就可以開始傳送HTTP/2.0幀。 這些框架必須包括發起升級請求的回響。
HTTP/1.1 101交換協定
連線方式：升級
升級：HTTP/2.0
[HTTP/2.0連線...
由伺服器傳送的第一個HTTP/2.0幀是一個設定框（ 6.5節 ）。 在收到101回響，客戶端傳送一個連線頭（ 3.5節 ），其中包括一個設定框。
在升級之前，傳送的HTTP/1.1請求分配流標識符1並分配儘可能高的優先權。 流1半隱式從封閉向伺服器的客戶端，因為該請求被完成HTTP/1.1請求。 起的HTTP/2.0連線後，流1被用於反應。
3.2.1 HTTP2 -設定頭欄位：即從升級到HTTP/1.1 HTTP/2.0請求必須完全包括一個HTTP2，設定頭欄位。 該HTTP2 -設定標頭欄位是包括設定支配的HTTP/2.0連線，由於預期該伺服器接收到升級的要求提供逐跳頭欄位。 伺服器必須拒絕嘗試升級，如果這個頭域不存在。
HTTP2 -設定= token68
該HTTP2-設定標頭欄位的內容是一個有效載荷設定幀（ 第6.5節 ），編碼為base64url字元串（即，在所描述的URL和檔案名稱安全Base64編碼第5節的[RFC4648] ，與任何尾隨'='字元省略）。 該ABNF[RFC5234]生產token68是定義在2.1節的[HTTP-P7] 。
客戶端必須包含值以下設定（ 第6.5.1節 ）：
SETTINGS_MAX_CONCURRENT_STREAMS
SETTINGS_INITIAL_WINDOW_SIZE作為一個逐跳頭域， 連線頭域必須包括HTTP2 -設定的值除了升級到HTTP/2.0何時升級 。
伺服器解碼和解釋這些值，因為它會任何其他設定框。 在升級要求提供這些值確保協定不需要進行上述設定的默認值，並給出了一個客戶端一個機會，之前接受任何幀從伺服器提供的其他設定。
3.3 啟動HTTP/2.0為“https”開頭的URI：
如果客戶端發出請求到一個“https”開頭的URI沒有關於對HTTP/2.0的支持先驗知識採用TLS [TLS12]與套用層協定協商的擴展 [TLSALPN]。
一旦TLS協商完成後，客戶端和伺服器傳送一個連線頭（ 3.5節 ）。
3.4 開始HTTP/2.0與前置知識：
客戶端可以知道某個特定的伺服器通過其他方式支持HTTP/2.0。 客戶端可以立即傳送HTTP/2.0幀至已知支持HTTP/2.0伺服器，連線頭（後第3.5節 ）。 這既影響了“http”的URI的解析度；支持HTTP/2.0的伺服器都必須支持的協定談判中的TLS [TLSALPN]為“https”開頭的URI。
對於HTTP/2.0的支持之前是不是一個強烈的信號，一個給定的伺服器將支持HTTP/2.0為將來的連線。這是可能的伺服器的配置來改變或配置，以在群集的伺服器實例之間的差異。 攔截代理（又名“透明”的代理）是變化的另一個來源。
3.5 HTTP/2.0連線接頭：當建立一個TCP連線和決心HTTP/2.0將使用兩個對等的，每個端點必須傳送一個連線頭為最終確認，並建立了HTTP/2.0連線的初始設定。
客戶端連線頭開始的24個位元組，這在十六進制表示法是一個序列：
505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
（字元串PRI * HTTP/2.0 \ r \n \ r \ NSM \ r \ n \ r \ n）的 。 該序列後跟一個設定框（6.5節 ）。 客戶端立即收到的101切換回響協定（表示成功升級），或作為一個TLS連線的第一個應用程式數據八位位組傳送客戶端的連線頭。 如果開始對協定的伺服器支持先驗知識的HTTP/2.0連線，客戶端連線頭在連線建立傳送。
·客戶端連線頭是這樣選擇的HTTP/1.1或HTTP/1.0伺服器和中介機構的很大比例並不試圖進一步處理框架。 請注意，這並不解決所關注的問題 。
伺服器連線頭只包含一個的設定框（ 6.5節 ），必須在伺服器發來的HTTP/2.0連線的第一幀。
為了避免不必要的等待時間，允許客戶端傳送客戶端的連線頭，無需等待接收伺服器的連線頭之後立即傳送額外的幀到伺服器。 但是要注意，該伺服器連線頭是很重要的設定框架可能包括參數必然改變了客戶端如何有望與伺服器進行通信。 在收到設定框，在客戶端有望兌現建立的任何參數。
客戶端和伺服器必須終止TCP連線，如果不是同行不以一個有效的連線頭。 一個GOAWAY框架（ 第6.8節 ，如果它是明確表示，對不使用HTTP/2.0）可以省略。
4， HTTP框架：
一旦HTTP/2.0建立連線，端點就可以開始交換幀。
4.1 幀格式：所有的框架開始一個8位元組的頭，緊跟著的0和16.383個八位位組之間的有效載荷。
對於保留的2位欄位。 這些位的語義是不確定的和傳送時該位必須保持未設定（0）和接收時必須被忽略。
長度：幀有效載荷的長度表示為一個無符號14位整數。 的8個位元組的幀頭中不包含這個值。
類型：8位類型的框架。 幀類型決定了幀頭和有效載荷的其餘部分被解釋。 實現必須忽略不受支持或無法識別類型的幀。
標誌：一個8位欄位保留幀類型特定的布爾標誌。
旗被分配到特定的表示幀類型語義。 那些沒有定義的語義為特定幀類型標誌必須被忽略，並且傳送時必須保持未設定（0）。
記：對於保留的1位欄位。 該位的語義是不確定的，傳送和接收時必須被忽略時，該位必須保持未設定狀態（0）。
流標識符：A 31-bit流標識符（見第5.1.1節 ）。 值0被用於與該連線作為一個整體相聯，而不是一個單獨的流的幀保留。
幀有效載荷的結構和內容是完全依賴幀類型。
4.2 幀大小：一幀的有效載荷的最大尺寸由幀類型不同而不同。 一幀的絕對最大大小為2 -1（16.383）位元組。 所有的實現應能接收和處理的最小幀截至最大尺寸。
某些幀類型，如中國平安 （參見6.7節 ），施加允許的有效載荷數據量的額外限制。 同樣，另外的大小限制可以通過特定的應用程式的用途進行設定（見第9節 ）。
如果幀大小超過任何已定義的限制，或者是太小，無法包含強制性的幀數據，端點必須傳送一個FRAME_SIZE_ERROR錯誤。 在影響連線級狀態幀幀大小錯誤必須被視為一個連線錯誤（ 第5.4.1節）。
4.3 報頭壓縮和解壓：在HTTP/2.0標頭欄位是一個名稱 - 值對與一個或多個相關聯的值。 他們是在HTTP請求和回響訊息，以及伺服器推送操作中使用（參見8.2節 ）。
頭列表是有序的排列，在套用層的零個或多個頭部欄位的集合。 當在一個連線上傳輸，一個頭列表序列化為使用標題塊的HTTP報頭壓縮 [壓縮]。 序列化的頭塊被分成一個或多個位元組的序列，稱為頭塊碎片，和標頭（有效載荷內傳輸6.2節 ），PUSH_PROMISE（ 6.6節 ）或延續（ 第6.10節 ）幀。
該Cookie首部欄位 [COOKIE]是由HTTP映射特殊處理，請參閱第8.1.3.3 。
一種接收終端通過連線各個片段重新組合的頭塊，然後解壓縮塊來重構報頭組。
一個完整的頭塊組成之一：
·單排針或PUSH_PROMISE每個分別與END_HEADERS或END_PUSH_PROMISE標誌設定框，或
·一排針或PUSH_PROMISE幀與END_HEADERS或END_PUSH_PROMISE標誌清零和一個或多個點連續的幀，其中最後延幀具有END_HEADER標誌集。
頭塊必須被傳送作為幀的連續序列，以及任何其他類型，或者通過任何其他流的無交插幀。 在序列的最後一幀接針或延幀必須有END_HEADERS標誌設定。 在序列的最後一幀PUSH_PROMISE或延幀必須有END_PUSH_PROMISE或END_HEADERS標誌設定（分別）。
頭塊碎片只能作為傳送的有效載荷HEADERS ， PUSH_PROMISE或存續的幀。 排針 ， PUSH_PROMISE和延幀傳輸數據，可以通過修改一個接收器保持壓縮上下文。 一個端點接收接針 ， PUSH_PROMISE或延幀必須重新裝配頭塊和執行解壓縮，即使幀將被丟棄。 接收器必須終止與連線錯誤（連線第5.4.1節類型） COMPRESSION_ERROR ，如果它沒有解壓縮一個頭塊。
語義改進
HTTP 2.0(草案)相對於HTTP 1.1在減少網路延遲而不中斷HTTP語義方面提出了一系列的改進。
其中一個重要的改進便是HTTP 2.0引入二進制框架，這是HTTP 1.1所不兼容的。既然是用在瀏覽器和伺服器上，那么對於用戶來講“不可見”也是可以理解的。另一個改進是支持多個並發的HTTP請求取代此前僅支持單一請求模式。
存在問題
導致RTT的因素有：信號傳播延遲(光在光纖和銅介質導線中傳播速度是不同的)、網路伺服器端以及用戶端路由器跨越的數量、路由器是否擁堵以及路由器自身容量等。這些都不是Web用戶或伺服器端可以控制的。
專家評議
很多專家指出，大規模的網際網路監聽之所以能得逞，部分原因在於監聽很容易進行。該研究的參與者、都柏林聖三一學院的計算機科學家史蒂芬·法雷爾表示，IETF計畫加強電子郵件和即時訊息傳輸的安全性，這兩者是網路監聽的主要目標。存在著對這些信息進行加密的協定，但步驟繁瑣，加密所需要的協定也常被錯誤地設定，而且其在不同的電子郵件服務商之間不起作用。法雷爾指出：“我們能做得更好，使設定更簡單而且可核實。”
法雷爾表示，要做到這一點還面臨一些困難，網際網路網頁的靜止部分被隱藏或存儲在距用戶更近的本地伺服器上，隱藏的內容一般處於“未加密”狀態，這使它能被找出；而加密則會使每頁內容變得獨一無二。
法雷爾指出：“如果你加密，你就使得其更難收藏。而且，我們如何在獲得安全性時兼顧收藏的好處呢？這是我們正在研究的問題。”
IETF主席亞里·阿爾科也表示，任何人都不應懷抱有幻想，期待這種技術很快能實現。
