QUIC 將會是 WebRTC 的未來麼？
本文轉載自WebRTC中文網，文章翻譯自 Dr.Alex 的部落格
QUIC 自從2013年為人所知，最近兩年一直是討論的熱門話題。原因是，QUIC作為傳輸層協議發揮了TCP、UDP的優點，添加了加密，速度倍增，其它方面也有改進，使得裝置上部署速度和更新速度較之前都有提升。
你可能認為傳輸層協議應該與在它上面執行的App分開設計，QUIC的歷史與HTTP/2有千絲萬縷的聯絡，並且QUIC上的HTTP/2幾乎是同時發展的。關於IETF103，QUIC工作組實際上需要正在進行的工作侷限於單一使用情況。這項技術很熱門，並有很多公司投入了大量資金，這就是為什麼如今有多種實施方式。
QUIC背後的主要參與者當然是網路公司，還有CDN。Akamai是此技術的一個重度參與者，並且其中許多員工都是規範和說明的制定者。
通常網路上的媒體會被分為兩個生態系統：廣播和實時。在廣播領域裡，大多數分佈是基於檔案和HTPP的。在實時領域裡，大多數通訊是基於RTP（RTSP/RTCP/STRP/WebRTC…）。
這裡有一個關於RTP和QUIC的問題需要額外討論：我們應該用RTP作為實時媒體，還是應該放棄它，因為RTP中的某些機制對於QUIC中的某些機制來說是多餘的？如果我們使用RTP，我們應該如何規劃架構，並且基於這些協議應該如何規劃多路傳輸？如果我們放棄它，我們如何管理不在QUIC中的媒體機制？
事實上，許多組織和個人都很對於通過 QUIC 傳輸（實時）媒體感興趣，並且開始著手去做了。QUIC 小組也有任何理由繼續遲疑。
下面是一些我們知道的一些舉措，可能有更多。
A. 來自ORTC，一些人已經實現了早期的QUIC傳輸和QUIC流，程式碼可以在Chromium程式碼庫找到。目標是隻讓資料傳輸，而不包括媒體。
B. 為了在媒體棧中提供更靈活的pipeline，就像在斯德哥爾摩的一次會議提出的一樣，Google團隊正在推動WebRTC中更多的模組類來允許人們使用自己的編解碼器，加密方式，媒體和網路傳輸方式。
這裡有一些關於下一代 WebRTC 版本的資訊：
ofollow,noindex">支援新增與視訊幀層第一個包不同的RTP擴充套件
將幀加密解密加入媒體頻道中C. RMCAT工作組的主席，負責處理頻寬評估和擁堵控制的問題，和來自callstats.io的另一位成員，一同在做direct-media-over-QUIC與RTP-over-QUIC 。
D. AVTCORE工作組，負責管理與RTP有關的一切，正在研究QUIC多路傳輸，以及其它RTP需要支援的協議。
E. TAPS工作組正在關注如何如何支援QUIC為它們的傳輸協議之一。
這些工作組各自的目標不同，並且在同一個分組裡可能還有更多的分支。QUIC的使用情況數量等於UDP和TCP的使用情況數量之和。當然了，對於每個人來說，他們的use case才應該是最重要的。
1.0為止不再增加新特性
這是包括Apple在內的許多公司的明確立場。不同的人對此有不同的理由。W3C工作組正在結束目前章程的進度，但是一些計劃的延期執行和simulcast所需的 APIs使得simulcast測試變得困難。就像近期在Lyon的一次會議上提到的：“Simulcast目前最大的難題，像一座高山。不僅需要考慮難度，更大的疑問是需要花費我們多少時間。”對於W3C員工和主席來說，這是一個主要的擔憂。Apple和其它的供應商也想穩定webrtc1.0版本，還有一些供應商表示，正在研究包括QUIC在內的其它方面。
QUIC簡單，但不夠成熟
在2018整年都在WebRTC小組中處於Mozilla位置，主要在Stockholm的期中面對面會議中表示，還有兩週之前在Lyon的TPAC會議。那些不同意的人表示，QUIC小組的主席，一個Mozilla員工，致力於Q4標準檔案，其它小組不應該等待太久，因此WebRTC應不應該採取QUIC是一個很棘手的問題。
多方組織似乎達成了認同，QUIC上的媒體需要一個不可靠的模式，至今還沒有產生在表格上。最新的單向QUIC流同樣破壞了某些部分。
我個人的想法更細緻，但是我很謹慎：
QUIC是未來，我們可以延遲，但是不能避免它。WebRTC也一樣。
直接放棄RTP將會對很多現存的WebRTC架構產生影響。IMHO是個太野蠻的方法。QUIC背後的團隊起初花費了很多時間將設計投入現實使用測試，因此QUIC對於現今基於UDP的結構是個加強，並且速度更快。我相信他們處理實時媒體的時候也用到了同樣的方法。在此，我希望應該把WebRTC媒體伺服器開發者的反饋納入考慮。
注意WebRTC1.0沒有離去，所以你還是可以產生和使用RTP流，SCTP流。
結論：
在WebRTC中，當提到QUIC時有很多選擇。如果你採取上面提到的不同的選擇，你也會得到不同的結果。
IETF和W3C中，你可以隨時提出自己的意見，沒有想法會被埋沒。你的意見會被聽取，閱讀。
你需要與其他人團結起來，達成認同，這是一個耗時的任務，需要非技術方面的技能。你需要使人信服，你的想法不但有效，並且值得他們花時間來研究。你需要使人信服，你提出的觀點比他們的好，這意味著你首先要花時間瞭解他們想要的和不想要的，在最終觀點中，將此加入考慮範圍之內，這樣就可以迎合別人的興趣。這更像是一個交流問題。
如果你的範圍太狹窄，就不能與更多人達成認同。如果你能不妥協，也是一樣。如果你請求他人花時間幫助你，他們不會的。對於大多數人來說，他們已經沒有足夠的時間來處理他們該做的事了。
交流失敗的一個明顯標誌沒人理會你的郵件和問題。只有編輯和主席有責任回答。然而，在不同平臺提出的問題（Github,郵件，會議），顯示出了他們的興趣導向和與主席達成認同的可能性。