Matthew Kaufman 谈 Skype 为何放弃点对点网络

  • Jonathan Allen
  • 臧秀涛

2013 年 6 月 26 日

话题:架构

Skype 决定从点对点网络切换为基于服务器的网络。在美国国家安全局泄密事件发生后,这一决定吸引了人们的眼球。Skype 的首席架构师 Matthew Kaufman 在最近的一封邮件中解释了这种改变的必要性。

Skype 过去使用的是点对点网络。这在公司尚小时可以降低成本。随着公司的壮大,可能要担当“超级节点(supernode)”的用户数也大致以相同的频率在增长。因为时值配备宽带连接的桌面时代,所以超级节点上额外的负载相当小。遗憾的是,大部分机器都是运行相同版本 Skype 的 Windows 系统,一个 bug 可能会导致大部分 Skype 网络出现问题。Matthew 指出,

客户端一个导致程序崩溃的 bug 致使整个 Skype 网络中断,已经证明了这一问题,而且不止一次,而是两次……事后要将网络引导回来非常麻烦,而且耗时很长,这也是 Skype 切换到基于服务器的“专用超级节点”的部分原因……我们控制的超级节点,每个主机可以处理的客户端数比原来高了几个数量级,而且这些节点位于受保护的数据中心内,并且一直运行,运行的代码也不像完整的客户端那样复杂。(这一转变甚至在微软收购 Skype 很久之前就开始了,当时还是 Silverlake 控制的时代。)

对于带宽有限、电池电量有限以及使用的操作系统不同的客户端,点对点的设计也带来了很多问题。

过去几年,使用手机或平板的用户越来越多,这些设备有的基于 iOS,有的基于 Android,还有的基于 Windows Phone 或 Windows RT,该类用户所占比例也从原来只占很小的一部分发展为举足轻重的一部分。这些设备存在很多不同:依靠电池运行;有时使用 WiFi,但又经常使用昂贵的 2G 或 3G 数据网络,花钱多,耗电也多;而且基本上大部分时间是“离线”的。在 iOS 设备上,如果应用试图进行太多后台处理,或者使用过多内存,它们会被杀掉并从内存中移除。在 Windows RT 和 Windows 8 上,如果应用不在前台,每 15 分钟才能得到几秒钟的 CPU 执行时间,而且如果应用想一直加载,也有内存限制。当 Skype 应用被从内存卸载后,也就无法再接收来电或即时消息,这样用处就没那么大了。

如果打算在移动设备上使用 Skype,尤其是在联系人很多或即时消息会话很多的情况下,用户会发现设备很快就变成了暖手宝,而且该应用可能比其他任何知名的应用耗电都快。这是因为,直到最近每个 Skype 客户端还是我们的点对点网络上一个完整的节点……它会和联系人中的每个节点定期交换数据包(多半是通过 3G 广播)以维护在线状态信息,也会和即时消息会话中的每个人交换数据包以维护会话的同步等。

WinRT 的情况更糟。WinRT 在将后台应用送入睡眠状态之前只分配数秒处理时间。对点对点的设计而言,发送方和接收方必须同时运行,如果双方碰巧都在后台,那通信的可能性就非常小了。

我们如何为用户解决这一问题呢?答案是服务器。大量服务器、而且越来越多的服务器都运行在 Windows Azure 云基础设施中。至于即时消息的发送,我们整合了交付 Skype 消息和 Windows Messenger 消息的后端服务,这样接收方离线的情况下也可以交付消息。我们还带来了过滤垃圾信息和删除恶意 URL 等不错的功能。对于电话呼叫,我们已经有专用的超级节点,我们还提供了额外的服务,以便在接收端处于睡眠状态时仍能成功呼叫,这里需要一个推送通知来唤醒客户端。随着时间的推移,我们会将越来越多的服务移到 Skype 云中,并最大程度地减少大家想玩的移动设备的内存和 CPU 需求, 最大程度地延长电池使用时间。

查看英文原文:Matthew Kaufman on why Skype is Dropping Peer-to-Peer

架构