ref: https://javascript.plainenglish.io/what-is-http-3-and-why-does-it-matter-cb7d7b4b600f
這篇文章簡單的敘述何謂 HTTP/3，主要探討 HTTP/3 到底跟 HTTP/1, HTTP/2 的差異是什麼
HTTP/3，也可以稱為 HTTP ove QUIC，這對過往的 HTTP 來說帶來了巨大的改變，因為 HTTP/{1,2} 都是基於 TCP 來傳輸封包，而 HTTP/3 則是仰賴 QUIC (Google 於 2012 所開發的協定，底層基於 UDP)。
TCP 目前普遍被使用到各式各樣的網路應用程中，而 TCP 本身的設計到今日來看也是有不少為人詬病的地方，譬如說 TCP 當初發明的時空背景與當前網路環境已經不同，譬如網際網路中的頻寬大小等
所以後續也有不少的演算法想要針對 TCP 來進行改善，譬如 Congestion Control 相關就有不少演算法可以選擇。
另外一個更直接簡單的就是直接跳過 TCP，直接使用 UDP 做為底層傳輸協定並且於應用層級重新打造一個如 TCP 一樣可信賴的傳送方式，這也是 QUIC 這個協定的基本概念。
透過 QUIC 的幫助，作者提到 HTTP/3 能夠得到下列的好處
Faster request multiplexing
HTTP/2 以前， 瀏覽器每次都只能對 Server 發送一個 Request，這導致網頁讀取速度緩慢，而 HTTP/2 則試圖改善這個機制，不過 TCP 本身的設計就不是針對這類型的使用
譬如眾多封包中只要有一個失敗， TCP 本身就會針對所有發送的 Request 去進行一個重送的動作來確保封包傳輸正常。
HTTP/3 因為不再使用 TCP 為底層協定而是 UDP，所以當上述情況發生時，也只需要針對失敗的 Request 進行重送即可，也因為此協定帶來的好處， HTTP/3 的表現會相較於之前版本來得更快更穩。
Faster Encryption
HTTP/3 允許最初的 HTTP Request 以加密的形式去傳送。過往傳統的 HTTPS 封包傳輸過程中，最初的握手階段交換資訊時，這些還是基於非加密的形式，要等到握手完畢後才可以能力將接下來的資料進行加密。
而 QUIC 本身可以針對 Initial Connection 進行 TLS 的處理，這使得 HTTP/3 於加密方面可以更順利也更簡單。
文章後半部分提到關於目前 HTTP/3 實作的部分，有興趣的人可以參考參考原文
udp傳輸 在 Re: [問題] 傳輸層(UDP)的問題- 看板TransCSI - 批踢踢實業坊 的八卦
※ 引述《stator (別急著吃棉花糖)》之銘言：
: ※ 引述《Asbarla (木頭)》之銘言：
: : (B)、(C)、(D)
: : UDP是Connectionless(非連線型)的非可靠資料傳輸協定。
: : =>應該是(D)刪去
: 感謝A大這麼熱心的解說
: : 它並不會運用確認機制來保證資料是否正確的被接收、不需要重傳遺失的資料，
: : 資料的接收可不必按順序進行、也不提供回傳機制來控制資料流的速度。
: : =>(B)刪去
: : 而且流量管制(flow control)是TCP才有的
: : =>(C)刪去
: : 但是TCP和UDP segment中都有checksum
: ^^^^^^^^^^^
: : 作用是資料傳送出去時，發送端會對資料做一個checksum 1補數的動作，
: : 然後將checksum value放入UDP checksum field裡面，當接收端收到封包後，
: : 會在對資料進行checksum，再比對value是否一致，或結果不一致則代表資料"errors"，
: : 並要求對方重傳。
: ^^^^^^^^^^^^^^^^^^
: 這邊您在上一段有說到UDP不需要重傳資料，但在這一段寫到UDP有checksum value
: 接收端比對不一致要求重傳，這樣不知是否有相衝突呢??
: : 所以(A)可以選
: : 小弟剛起床可能思緒不清，
: : 如果有誤煩請各位大大見諒並指教，
: : 謝謝。
: 還是謝謝A大能為小弟解惑
不好意思我只是路人K，以下是CCNA(網路證照書籍)+Wiki
先看WIKI:UTP 的 Checksum
The main purpose of checksum is error detection.It guarantees that message
arrived at correct destination.To verify checksum,the receiver must extract
this fields from IP Header .12-byte psuedo header is used to compute checksum.
K的中文翻譯:checksum的主要目的是錯誤偵測.她保照訊息抵達在正確目的.
後面翻譯省略(關連小)
再看ccna的書籍擷取之(基豐出版社何旅良 審校)
--------------------------------------------------------------------------
TCP/IP傳輸層特色
==========================================================================
功能: 說明
--------------------------------------------------------------------------
使用PORT之多工 |讓接收端的主機可以根據port將資料送到正確的應用程式
|之功能
--------------------------------------------------------------------------
錯誤復原(可靠度) |以序號和ACK標頭欄位進行編號及回應資料
|之程序處理。
--------------------------------------------------------------------------
使用視窗進行流量控管 |使用視窗大小來保護緩衡區即遶送設備之處理程序
--------------------------------------------------------------------------
連線之建立及終止 |用來初始化port、序號和ACK欄位之處理程序。
--------------------------------------------------------------------------
有序資料傳送及資料分段 |將來自上層的連續位元組串流分割為資料段以便傳送到
|接收端設備，並以相同順序提交回上層之處理程序
!! 其中只有第一項是UDP支援的,而表格內所有項目TCP都可支援
===========================================================================
thanks for watch right now , and...
OKAY~ 根據wiki還有書本上得聯集得知 錯誤復原有待商榷
黃色字體的序號和ACK只有tcp有 however UTP是沒序號跟ACK的
所以結論是UTP沒有錯誤復原但是但是!!!她有目標地點確認的功能
以上乃paper推論
上面大大的講法說實在我沒看過或學過但WIKI有詳細資料可參考^^
嗯...錯誤管理UTP是的確做到了 可選(A)
但一般講的錯誤復原到沒有做到，這可能是問題上要看清楚的部分@@
而醬一路說來UTP 的check sum 沒辦法做TCP ACK 和序號的錯誤復原功能
OK! 路上小心
路人K睡了
附張美女圖:https://img.cnmo-img.com.cn/189/188043.jpg
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.73.44
※ 編輯: k101646 來自: 61.230.73.44 (05/16 01:23)
※ 編輯: k101646 來自: 61.230.73.44 (05/16 01:24)
※ 編輯: k101646 來自: 61.230.73.44 (05/16 01:34)
... <看更多>