Akamai Martin Horčička：最新网络优化技术及编程语言分析

在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规范，以至于可以更加集中在某些具体目标。