-
什么是quic？ quic解決了什么問題？HTTP和QUIC
QUIC ：Quick UDP Internet Connections；是一種新的默認加密的互聯網通信協議，它提供了許多改進，旨在加速HTTP通信，同時使其變得更加安全，其最終目的是在web上代替TCP和TLS協議
可以看到發起http請求時涉及到tcp三次握手、TLS/SSL的秘鑰交互。TCP三次握手+TLS握手 大約會消耗4~5RTT；
HTTP是承載於tcp， tcp收到報文時如果出現亂序，是不會將報文送到對應的socket buffer，而是緩存下來知道丟棄的報文到達！！
所以： 隊頭報文阻塞后續到達的報文提交到應用層的速率，這是tcp擁塞流量控制導致！
linux 操作系統是一個網絡操作系統，tcp的核心 擁塞控制在內核里面，如果需要升級tcp擁塞控制算法，比較麻煩！
可以看到quic去掉TCP TLS多次握手，QUIC只需要一次握手，大約花費一個RTT就可以建立連接；
- 0~1RTT連接。QUIC的連接將版本協商、加密、和傳輸握手交織在一起以減少連接建立延遲
- 加密認證的報文。QUIC把TLS(1.3)等效加密，幾乎每個UDP包都加密，報文body都經過加密，從頭到腳幾乎無死角，對證書也有一些壓縮優化，每一個加密包獨立認證。這個特性對直播來說，在客戶端的防盜鏈、盜播、劫持上是有好處
- 連接遷移。傳統NAT遇到的問題，比如小區運營商切換端口，導致設備端判斷不了新的連接標識，需要重聯。而QUIC使用公共包頭和連接ID，可以在網絡切換的時候不重連，從室內到室外，在理論上可以做到連接不斷網
- 改進的擁塞控制。這是QUIC最重要的一個特性，TCP的擁塞控制包含了四個算法：慢啟動，擁塞避免，快速重傳，快速恢復。QUIC 協議當前默認使用TCP協議的Cubic擁塞控制算法，同時也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等擁塞控制算法。同時QUIC擁有完善的數據包同步機制，在應用層做了很多網絡擁塞控制層面的優化，能有效降低數據丟包率，有助降低復雜網絡下的直播卡頓率，提升傳輸效率，使得推流更流暢。
- 無隊頭阻塞的多路復用。QUIC 的多路復用，在一條 QUIC 連接上可以發送多個請求 (stream)，一個連接上的多個請求(stream)之間是沒有依賴的。比如說這個packet丟失，不會影響其他的stream；也就是沒有TCP的收包亂序
- 向前糾錯。QUIC采用向前糾錯(FEC)方案，即每個數據包除了本身的數據以外，會帶有其他數據包的部分數據，在少量丟包的情況下，可以使用其他數據包的冗余數據完成數據組裝而無需重傳，從而提高數據的傳輸速度； 讀研時，從事芯片基帶開發 用到過RS信道編碼
剛剛微軟開源了quic 的 c 實現 msquic：https://github.com/Microsoft/msquic
開始研究一波
從網上得知目前HTTP協議的優缺點，雖然寫過httpserver 但是主要是寫底層架構接口！ 一個http的從定向， 一個http+tcp代理
目前http發展如下：內容來自互聯網
- HTTP/1.0最初實現了可用性。對每個請求都需要TCP三次握手建立單獨鏈路。
- HTTP/1.1優化了傳輸效率。新增keep-alive特性使多個請求可以復用同一條TCP鏈路(TCP keep-alive是傳輸層特性，防止NAT路由斷開連接)；它支持持續連接.通過這種連接,就有可能在建立一個TCP連接后,發送請求並得到回應,然后發送更多的請求並得到更多的回應.通過把建立和釋放TCP連接的開銷分攤到多個請求上,則對於每個請求而言,由於TCP而造成的相對開銷被大大地降低了
-
1.1存在的缺陷
- 隊頭堵塞導致：雖然通過持久性連接得到改善，但是每一個請求的服務端響應依然需要按照順序排隊，如果前面的響應處理較為耗費時間，那么同樣非常耗費性能。
HTTP2.0
HTTP/1.0一次只允許在一個TCP連接上發起一個請求，HTTP/1.1使用的流水線技術也只能部分處理請求並發，仍然會存在隊列頭阻塞問題。為了解決以上的問題2.0應運而生
- 在 HTTP/1.1 協議中瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制。超過限制數目的請求會被阻塞。
- 而 HTTP/2 的多路復用(Multiplexing) 則允許同時通過單一的 HTTP/2 連接發起多重的請求-響應消息。因此 HTTP/2 可以很容易的去實現多流並行而不用依賴建立多個 TCP 連接，HTTP/2 把 HTTP 協議通信的基本單位縮小為一個一個的幀，這些幀對應着邏輯流中的消息。並行地在同一個 TCP 連接上雙向交換消息。
- HTTP/2在 應用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個二進制分幀層。在不改動 HTTP/1.x 的語義、方法、狀態碼、URI 以及首部字段的情況下, 解決了HTTP1.1 的性能限制，改進傳輸性能，實現低延遲和高吞吐量。在二進制分幀層中， HTTP/2 會將所有傳輸的信息分割為更小的消息和幀（frame）,並對它們采用二進制格式的編碼 ，其中 HTTP1.x 的首部信息會被封裝到 HEADER frame，而相應的 Request Body 則封裝到 DATA frame 里面。
- 假設一個頁面要發送三個獨立的請求，一個獲取css，一個獲取js，一個獲取圖片jpg。如果使用HTTP1.1就是串行的，
- 但是如果使用HTTP2.0，就可以在一個連接里，客戶端和服務端都可以同時發送多個請求或回應，而且不用按照順序一對一對應
- HTTP2.0的缺陷
- 因為還是基於TCP協議的原因，基於連接的TCP協議在往返時
- 當其中一個數據包遇到問題，TCP連接需要等待整個包完成重傳之后才能繼續進行，雖然HTTP2.0通過多個stream，使得邏輯上一個tcp連接上的並行內容，進行多路數據的傳輸，涉及到TCP 收包是否亂序的問題！！！