歡迎訪問 RTC 開發者社群，與更多WebRTC、實時音視訊開發者交流經驗。
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 版本的資訊：
將幀加密解密加入媒體頻道中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仍不夠成熟
這是Mozilla在去年一直以來都堅持的態度，不僅僅在斯德哥爾摩的面對面會議中提出過，還在近期在 Lyon 舉行的 TPAC 會議中提到了。那些不同意的人表示，QUIC小組的主席（一個Mozilla員工）致力於在Q4完成標準文件，其它小組（包括 WebRTC）不應該繼續等下去，因此WebRTC應不應該採取QUIC成為了一個棘手的問題。也有人認為，QUIC 已經被應用了起來，所以如果 WebRTC 小組不作出決定，那麼他們將自己來分別著手解決。（這樣的爭論也發生在 SVC condec 上）
我個人認為：
QUIC是未來，我們可以推遲它，但是無法避免。WebRTC也曾有過相同經歷。
直接放棄RTP將會讓很多現存的WebRTC基礎設施受到影響。QUIC背後的團隊起初花費了很多時間設計技術選型，使得QUIC可以幫現在的傳輸技術得到更大的優化，並且讓這項技術得到更快更廣泛的採用。我相信他們也在 QUIC 應用於實時傳輸方面做出了同樣的努力。
最後給希望開發實時音視訊App，或希望學習 WebRTC 的開發者推薦一些博文與資料