Akamai Martin Horčička：最新網絡優化技術及程式設計語言分析

文 / Martin Horčička

整理 / LiveVideoStack

LiveVideoStack： Martin 你好，能否向LiveVideoStack的讀者介紹下自己，以及你目前主要的工作以及關注的技術方向？

Martin Horčička： 大家好，我是 Akamai 公司QUIC 團隊的研發經理，團隊位于捷克的布拉格，目前主要負責提供 QUIC 協定實施，以便将它內建到 Akamai 軟體中，支援內建、部署和性能調優，除此之外我們還在為QUIC進行優化、改進和改善、調整網絡協定。

除了維護Chromium軟體相容性，支援新的 Google QUIC 版本以外，我們目前還在優化CPU使用率方面開展工作。 這是一種提高重新連接配接的 QUIC 性能的機制，當然最引人注目可是IETF QUIC的支援。 我們預計IETFQUIC的工作将成為我們2020年最重要的一組任務。

LiveVideoStack：從你的工作經曆可以看到，從最初的UNIX系統管理者到軟體開發工程師再到研發經理，職位的變動對你來說有哪些不同的感受？ 職位越高是否意味着不會再從事基層的編碼工作？

Martin Horčičk： 在ISP從事系統和網絡管理以及作業系統測試，再跨到軟體開發也許是個很長的過程，但我覺得是值得的，實際上這艱難的道路增進的我個人的基本軟體技能、網絡知識，更何況的是我從中可以深度了解客戶的特殊要求及從不同的角度看待事情。 所有我 的工作其實都圍繞着軟體開發，是以才會最終走向軟體開發的職業道路。

近期我接觸基本編碼的機會也逐漸減少，說實話我偶爾也會想起那段時光。 另一方面，我保持專注在架構層面，我同時參與多個有趣的項目，我參與制定公司的技術方向，最重要的是我可以與許多非常有才華的同僚合作。

LiveVideoStack：你曾使用C，Python，Perl，Shell和Java程式設計語言進行軟體開發，作為一名資深的軟體開發工程師，你如何看待近幾年程式設計語言的發展？

Martin Horčička： 作為過去9年C++的使用者，我發現程式設計語言的發展終于開始穩步地前進。 過去，C++開始的時候遇到缺乏标準，很難推進。 現在，C++定期更新，進度問題也轉移到使用它的公司組織，因為他們需要去适應經常變更。 不過，C++仍然存在一些固有的問題，主要是其複雜性和使用者對于如何很好地使用它（例如，有或無例外處理）的意見中的碎片化。 我個人覺得"batteriesincluded"的概念，可從Python獲得很豐富的存儲庫與語言，但我相信有些人不一定同意我這一點。

每當我看到新的程式設計語言開發，新的想法進行測試時感覺很興奮。 在我看來，在不需到ISO标準的情況下對他們有益。 另一方面，他們也許會受到某家公司的控制。 不管怎樣，我希望能盡快見證C++的接班者。

LiveVideoStack：在此之前你有大量的時間專注在Giga（一種新的基于UDP的專有傳輸協定）上，我們知道QUIC也是基于UDP的低延遲時間的網際網路傳輸層協定，是什麼原因讓你放棄Giga轉而從事QUIC方面的工作？

Martin Horčička:： Giga是我們首次進入基于 UDP 的傳輸協定領域的産品。 我們更希望用FEC取代常用的基于重新傳輸的資料包丢失恢複機制。 漸漸地，我們逐漸認識到FEC本身并不是一個解決方案，生産環境中的網絡有許多難題，我們需要在傳輸協定研發方面做出更仔細的推進。 在這個項目裡，我們領悟了很多珍貴的經驗。

後來，Akamai 收購了一家丹麥公司Octoshape，他們是提供視訊流加速解決方案的。 與他們合作後，他們帶來了另一個 UDP 的協定，更加有意思的傳輸和應用程式層融合。 它為我們公司引入了一些傳輸層決策中對播放的視訊比特率的感覺能力。 當Google宣布有意在IETF下對QUIC進行标準化時，我們正在考慮如何合并我們兩個基于UDP的協定。 此協作機會将使得我們的優化從專有領域轉移到未來的标準。 是以，我們把重點轉移到QUIC上，并逐漸終止了舊協定。

LiveVideoStack：基于UDP的QUIC常用來和基于TCP的SPDY比較，這些協定和技術都是為解決資料傳輸問題而存在，你如何看待網絡上QUIC終将替代TCP的說法？ QUIC與TPC在你看來更像是一種什麼關系？

MartinHorčička： 盡管 SPDY 演變為HTTP/2，被視為 HTTP/1.1 的後繼者，但我們不能說它取代了 HTTP/1.1。 考慮到TCP比HTTP更普遍。 衆所周知，TCP在大多數條件下工作出色，得到廣泛支援，運作效率也很高。 QUIC 最初旨在作為一個實驗平台，從該平台将最成功的功能內建到主流協定中。 例如，我們可以看到 QUIC 加密如何通過0-RTT 連接配接啟發 TLS 1.3。 我相信，這種趨勢将繼續以某種形式，當然TCP将繼續緩慢演進，也會從QUIC實驗結果中受益。

LiveVideoStack:QUIC協定相較于TCP協定有諸多優點，例如效率高，速度快，占資源少，在QUIC實作時還有哪些需要優化的地方？

Martin Horčička： 根據我們的統計資料，QUIC 在某些情況下比TCP 表現更好，而在另一些情況下，QUIC 的表現未必勝出。 到目前為止，QUIC 需要的資源（尤其是CPU）明顯多于 TCP 。 從CDN的角度來看，我們更考慮實用性，使用QUIC時當它可以帶來顯然的利益，不然的話采用TCP。 我相信進一步的改進和優化将逐漸減少 QUIC 的資源使用，一定可以增加QUIC的使用場景，但我認為TCP一定會存在。

從優化的方向上，我應該強調在OS核心中，網卡中支援UDP，支援QUIC實施。 我們非常需要定案QUIC規範，以至于可以更加集中在某些具體目标。

————————————————

版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：

https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/103209457

「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。