程式研究社110成發-HTTP/3

Posted on Edited on In

程式研究社110成發-HTTP/3

HTTP/3

HyperText Transport Protocol v.3

  • HTTP歷史＆問題
  • HTTP/3-QUIC

HTTP history

HTTP/1.0

  • TCP在每次的請求、回應進行交握
  • response後即斷開

Note:
在HTTP/1之前還有HTTP/0.9的存在，但因為只支援GET方法，一次能傳輸的資料有限，且已被廢除，故在這邊不提及
HTTP/1 是現行超文本傳輸協議中最舊的版本，他會在每一次的傳輸中進行交握，內容傳輸完成後即斷開TCP連線
雖然可以保障伺服器的資源，但對於內容豐富的網站傳輸時間就會比較久
再加上TCP的擁塞控制，會讓仔入速度更加的緩慢

Note:
最左邊的那張就是Http1得傳輸情形，client端提出一次request前，都得先進行一次三向交握，server端傳完內容斷線又得建立一次4項的分手訊息，如此一來一往十分的浪費時間，故
我們有沒有辦法能向中間跟右邊的圖一樣
建立一個TCP連線，傳完所有request
甚至是一次傳送多個request呢

HTTP/1.1

  • Keep-alive TCP connection
  • HTTP pipelinig

HTTP/1.1


Note:
Keep-alive TCP connection 允許用戶端重複使用已建立TCP連線、可以減少初始連結的交握次數、減少因多個requests產生的slow start造成的影響
HTTP piplinig
允許多個requests同時送出，而傳輸過程中不需先等待伺服器的回應
一個包含有許多影象的網頁檔案的多個請求和應答可以在一個連線中傳輸，但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連線
HTTP1.1允許requests重複利用已建立的TCP連線，這樣的機制可以減少交握的次數，以及受到TCP慢啟動機制的影響

HTTP/1.1

  • 雖然TCP可重複利用，但伺服器收到多個requests還是必須排序來傳輸
    • ＦＩＦＯ
    • HTTP的隊頭阻塞問題 Head-of-line blocking

Note:
雖然TCP允許重複利用但在伺服器端每一個請求與回覆都還是要逐一個執行
若其中有一個http的處理時間太長，就會使得後面的風包無法被傳出或是處理，這就是所謂的http對頭阻塞問題
為解決這部分的問題，http/2變加入了「資料流」的概念，藉由控制各個封包的優先權，來實現一次傳送多個資料的

HTTP/2

  • 資料流stream的概念產生
  • 在同個TCP上允許多路復用 multiplexing
  • 以上解決了傳輸的效率問題
  • 還是有tcp 隊頭阻塞的問題
    • 一個封包發生錯誤，需等待重傳造成全部的傳輸線路停止

問題 HTTP/1 HTTP/1.1 HTTP/2
TCP single handshake v 解決 解決
http 隊頭阻塞 v v 解決
TCP隊頭阻塞 v v v
TCP重傳歧異 v v v

HTTP/3

QUIC

  • QUIC == Quick UDP Internet Connection

QUIC小檔案

  • QUIC不是首字母縮略字，而是本身就是協議名稱
  • 由Google團隊於2013年提出
    • 以UDP傳輸機制作為基礎，在應用層加入功能
    • 在QUIC層實做出原本TCP有但UDP沒有的功能
  • 2018年IETF將QUIC定為HTTP/3的傳輸協議標準，並加入TLS1.3的加密技術
    Note:
    Loss Recovery, Congestion Control
    • 加入多路複用、降低連線交握的延遲、解決重傳歧異和支持 Connection Migration 的功能

![](https://i.imgur.com/xMaBncy.png =600x)

  • 連線建立 Connection Establishment
  • 多路複用 Multiplexing
  • 封包遺失恢復 Loss Recovery
  • 流量控制 Flow Control
  • 連線遷徙 Connection Migration
    Note:
    流量控制的部分跟TCP大致相同，在建立stream時就會去設定傳輸時可允許的最大頻寬

連線建立


在初始的連結交握，就同時進行金鑰的交換
（相較TCP是先進行交握再進行TLS加密）

Note:
相較http/2是依序建立TCP交握和TLS的加密cipher交換，Quic會在第一次的RTT就會進行秘藥的交換


Note:
詳細的交握過程
最左邊是首次進行交握，中間是0-RTT
server config服務端長期的ＤＨ供藥
certification chain
singnature of server config
source address token
（下頁是TCP+TLS1.2, TCP+TLS1.3 和Ｑuic的比較）

多路複用

因為使用的是UDP，UDP會把每一個封包視為相等（就算掉了也不知道），這個方法剛好可以解決TCP自HTTP/1以來一直未解決的隊頭阻塞問題。

封包遺失修復

  • RTT(Round Trip Time)：一個連接的往返時間，即數據發送時刻到接收到確認的時刻的差值；
  • RTO(Retransmission Time Out)：重傳超時時間，即從數據發送時刻算起，超過這個時間便執行重傳, RTO協議實現值最小1s
  • 現行
    • 發送端在發出的每一個封包上帶有一個標記sequence number，接收端收到封包後會回傳帶有對應編號的ACK封包給發送端，代表封包已被接收
    • 若發送端未收到ACK封包(RTO)，就會啟動重傳的機制
    • 重傳歧異問題
      • 啟動重傳機制時，發送端發送的封包的sequence number是一樣的！！
      • 發送端在拿到編號N封包的回傳ACK時，將無法判斷這個帶有編號N的ACK，是接收端收到初始封包還是重傳封包的ACK
      • 影響TCP擁塞控制演算法對RTT的取樣，並有可能會使RTO被錯誤的放大，拉長之後封包重傳的反應時間
  • QUIC
    • 發送端在傳送封包時，改用唯一而且嚴格遞增unique packet number，藉此判斷收到的ACK是來自初始封包或者是重傳封包
    • 接收端則是藉由封包內的 Stream ID 和 Stream Offset 的值，辨認封包是屬於哪一個 Stream，再依照每個封包的 Offset 將資料照順序重組。

Connection Migration

  • 現行：
    • 目前TCP連線需要來源IP、來源port、目標IP、目標port四個參數來區分收到的TCP是哪一個連線
    • 當client從WIFI網路遷移到4G網路時，原本的連線就已失效
  • QUIC
    • 連線的識別方式改為採用一個64bit的獨特ID
    • 即使新發送封包的來源 IP 位址不同，接收端也可以透過 Connection ID 順利的識別新封包所歸屬的連線。
    • 原本正在傳遞中，存有舊 IP 的封包，也一樣也可以透過 Connection ID 來識別，正確的被接收端接收。

Sum up

簡單來說,QUIC可以

  • 在一個RTT中，同時達成交握＆加密傳輸，若先前有連過伺服，則可直接開始進行資料傳輸

  • 在multiplexing中，不會因為單個stream發生錯誤造成全部傳輸終止,解決HOL問題

  • 解決重傳歧異問題

  • 解決連線遷移需重新交握問題

  • Chrome 和Firefox皆已支援使用QUIC的協議

  • Uber 有做過實驗文章，比較有無QUIC的影響

  • 理論上，應該會比較快，但有些ISP對UDP的支援不友善，可能會瘋狂丟包，所以載入速度非常的…

本文網址

https://hackmd.io/@yen0224/http3

Resource