Akamai Martin Horčička：最新網路優化技術及程式語言分析
- 2019 年 11 月 22 日
- 筆記
在LiveVideoStackCon深圳站開場之前，我們邀請到了Akamai公司的研發經理Martin Horčička來接受我們的採訪，採訪中Martin向我們分享了他早期關於UNIX相關的OS、網路和開發的工作以及對於近幾年程式語言發展的看法。除此之外Martin還提供了關於multi-connection和P2P的一些技巧，最後，Martin還談到了Akamai最近的項目在基於UDP的安全傳輸協議做一些優化。
文 / 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規範，以至於可以更加集中在某些具體目標。
