HTTP/1.0

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

HTTP/1.1

• Keep-alive TCP connection
• HTTP pipelinig

HTTP/1.1

HTTP/1.1

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

HTTP/2

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

QUIC

• QUIC == Quick UDP Internet Connection
  

QUIC小檔案

• QUIC不是首字母縮略字，而是本身就是協議名稱
• 由Google團隊於2013年提出
  • 以UDP傳輸機制作為基礎，在應用層加入功能
  • 在QUIC層實做出原本TCP有但UDP沒有的功能
• 2018年IETF將QUIC定為HTTP/3的傳輸協議標準，並加入TLS1.3的加密技術

• 連線建立 Connection Establishment
• 多路複用 Multiplexing
• 封包遺失恢復 Loss Recovery
• 流量控制 Flow Control
• 連線遷徙 Connection Migration

連線建立

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

多路複用

因為使用的是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被錯誤的放大，拉長之後封包重傳的反應時間

封包遺失修復

• 發送端在傳送封包時，改用唯一而且嚴格遞增unique packet number，藉此判斷收到的ACK是來自初始封包或者是重傳封包
• 接收端則是藉由封包內的 Stream ID 和 Stream Offset 的值，辨認封包是屬於哪一個 Stream，再依照每個封包的 Offset 將資料照順序重組。

• QUIC
  • 連線的識別方式改為採用一個64bit的獨特ID
  • 即使新發送封包的來源 IP 位址不同，接收端也可以透過 Connection ID 順利的識別新封包所歸屬的連線。
  • 原本正在傳遞中，存有舊 IP 的封包，也一樣也可以透過 Connection ID 來識別，正確的被接收端接收。