QUIC全稱Quick UDP Internet Connection，由命名可以看出，QUIC協(xié)議是一種基于UDP的低時延的互聯(lián)網(wǎng)傳輸層協(xié)議。
TCP全稱Transmission Control Protocol，TCP協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。
單從協(xié)議棧結(jié)構(gòu)可以分析出，QUIC實際屬于HTTP/2、TLS、UDP的結(jié)合。
①、QUIC于2012年開始實施部署；
②、在2013年時，被公布于眾；
③、2015年中，提交草案于IETF開始標準化之路；
④、2016年QUIC工作組正式成立；
⑤、2018年末，HTTP/3問世；
⑥、2021年中，IETF基于RFC 9000對其進行了標準化，使其真正全球化。
①、相對于UDP，它提供了可靠傳輸；
②、相對于TCP，它擁有更短的連接建立時間，QUIC握手過程詳解見下圖；
③、更加出色的擁塞控制；
④、更加出色的多路復(fù)用；
⑤、具有前向糾錯能力；
⑥、鏈接遷移。
1、QUIC在網(wǎng)絡(luò)安全方面可謂是用心良苦，它完全以加密形式通信，未加密的通信是完全被禁止的。在這一點上仁者見仁，智者見智，主要取決于開發(fā)者們的需求。
2、QUIC在建立安全連接的時間上可以說是完全碾壓TCP+TLS，其主要原因是QUIC發(fā)送打開連接的同時，響應(yīng)數(shù)據(jù)包中還包含后續(xù)需要使用的加密數(shù)據(jù)包的數(shù)據(jù)。也不需要建立TCP連接，只需通過其他數(shù)據(jù)包協(xié)商安全協(xié)議。對比見下圖：
TCP+TLS幾乎需要長達300ms的建立連接時間，而QUIC建立連接時間遠低于此。
3、在網(wǎng)絡(luò)擁塞控制方面，QUIC也是下足了功夫，不僅支持TCP協(xié)議中的Cubic擁塞控制算法，同時也支持其他5種擁塞控制算法，它們分別是Reno、PCC、BBR、CubicBytes、Reno，由于支持多種不同算法，而增加了改造的靈活性。除此之外，QUIC在應(yīng)用層也對其做了大量的優(yōu)化，且擁有完善的數(shù)據(jù)包同步機制，這也為通信穩(wěn)定性、傳輸效率性、流暢性奠定了基礎(chǔ)。
4、多路復(fù)用方面，QUIC可以復(fù)用多個stream，同時其中一個stream的丟包并不會影響其他stream，這也說明了在QUIC中，每個stream是相對獨立的。這下算是徹底解決了TCP協(xié)議中隊頭阻塞問題。
5、正是由于QUIC是基于UDP協(xié)議，所以它在弱網(wǎng)環(huán)境中表現(xiàn)相對于TCP要強得多。
四、結(jié)論
QUIC協(xié)議對比TCP協(xié)議，主要最優(yōu)化在于以下幾點：一是增加多種擁塞控制算法；二是增加了時間戳選項，可有效提高RTT的測量精準性；三是大大降低建立連接時間；四是增加SACK，優(yōu)化判斷丟包的精準性，有效提高數(shù)據(jù)重傳效率。
TCP協(xié)議對比QUIC協(xié)議，主要優(yōu)勢在于：一是TCP滑動窗口能夠同時兼顧流量控制及保序；二是TCP擁有更加簡潔的協(xié)議頭，但又不失可靠性。
總而言之，QUIC協(xié)議與TCP協(xié)議各有千秋，在數(shù)據(jù)吞吐上，QUIC協(xié)議毫無疑問更加優(yōu)秀，但是在資源占用方面，TCP協(xié)議又是優(yōu)于QUIC協(xié)議。所以無論是TCP協(xié)議還是QUIC協(xié)議，它們都是在特定環(huán)境下不可替代的存在，我相信在未來的互聯(lián)網(wǎng)世界中，它們是可以共存的。
今天的分享就到這里啦，EBYTE每一天都致力于更好的助力物聯(lián)化、智能化、自動化的發(fā)展，提升資源利用率，更多產(chǎn)品更多資料，感興趣的小伙伴可以登錄我們的億佰特官網(wǎng)和企業(yè)公眾號（微信號：cdebyte）進行了解，也可以直接撥打400電話咨詢技術(shù)專員！
相關(guān)閱讀：
