作者：乐昂霖，单位：中国移动智慧家庭运营中心

随着学术交流、即时游戏、移动端实时音频等高度依赖网络使用的场景愈发丰富，对网络在不同场景下的加速需求催生了场景宽带。从本质上来说，场景宽带就是为普通的网络提供了一系列加速服务，本文将浅谈网络加速服务需求出现的底层原因。

Part 01●QoS服务●

国内的运营商网络一般都会提供QoS。QoS指的是网络利用各种基础技术，以提供更好的服务能力来支持特定的网络通信。它是一种网络安全机制，旨在解决网络延迟和阻塞等问题。简单来说，当网络拥堵时，运营商会优先处理重要的流量包，而将一些不重要的包丢弃。具体丢弃哪些包则取决于使用场景和运营商的策略。

(资料图)

对于受到QoS限制的用户而言，可能会出现以下表现：网速降低、丢包、ping值不稳定。在这种情况下，细分场景用户往往希望进一步获取更好的网络质量以满足场景使用，例如更高的带宽、更少的丢包和更低的延迟。

需要注意的是，QoS并不区分TCP和UDP。对于UDP来说，除了常规的QoS限制，还可能存在更严格的限制，甚至在某些极端情况下会屏蔽UDP。这主要是因为UDP的无连接、无状态、支持广播和最大努力传输等特性使得网络运营商控制UDP的成本较高。

Part 02●游戏场景下TCP与UDP的区别●

通常情况下，为了确保游戏的实时性，使用UDP进行网络传输是常见的做法。例如，在射击游戏中，当角色在行走时遇到网络卡顿，画面会卡住，但当恢复后，画面中的角色已经跳到下一个位置，仿佛跳帧了一般。这是UDP的特性，它尽最大努力进行传输，允许丢包。

相比之下，如果使用TCP，当网络卡顿时，你会发现游戏画面暂停，角色像卡在幻灯片上一样逐帧向前移动。这是因为TCP是面向连接的，丢失的包会被重传，确认后才会继续进行。当然，游戏中不仅仅使用UDP、TCP，更高层的协议如HTTP也可能被使用，这完全取决于游戏对延迟的要求。

Part 03●TCP与UDP的场景选择●

那么在不同的使用场景中究竟是使用UDP还是TCP呢？

如果是客户端间歇性发起无状态查询，并且偶尔的延迟是可以接受的（例如查询学术论文、参考信息等），那么可以考虑使用HTTP/HTTPS。

如果客户端和服务器都可以独立发包，但偶尔的延迟是可以容忍的（例如在线纸牌游戏、许多MMO游戏），那么可以考虑使用TCP长连接。

如果客户端和服务器都可以独立发包，并且无法容忍延迟（例如大多数多人动作游戏、一些MMO游戏、直播互动等），那么考虑使用UDP。

在访问一些国外学术网站、游戏服务器时，直接连接效果可能不佳，因此需要使用场景宽带来实现优化效果。以游戏为例，因为游戏通常使用UDP进行传输，而普通的运营商网络对UDP会产生较大的干扰，所以场景宽带需要对游戏客户端与代理服务器之间的连接进行一些处理。

Part 04●UDP协议的QoS问题●

每次UDP套接字发送数据包时，源端口会随机变化。如果一个设备频繁发送UDP包，会在短时间内产生大量的五元组（源IP地址、源端口、目标IP地址、目标端口、协议）。传统的状态防火墙和状态NAT会使用一个五元组来跟踪一个连接。如果连接数量过多，会给保存状态的设备带来巨大压力。

这种压力主要体现在两个方面：存储压力和处理器压力。

存储压力指的是设备需要配置大量内存来保存大量连接。

处理器压力指的是设备在数据包到达时需要花费更多时间匹配连接。

由于UDP协议的无状态特性，没有任何报文指示何时创建或销毁连接，设备必须能够自行老化已创建的UDP连接，并在权衡中做出决策。如果老化时间过短，会破坏通信频率较低的UDP连接。如果老化时间过长，将会导致无效的UDP连接消耗大量内存，为DDoS攻击提供攻击面。攻击者只需构造不同的UDP五元组的报文通过状态设备，由于UDP报文没有连接创建或销毁的控制信息，状态设备不得不对待所有新到达的五元组，并为它们创建连接并指定相同的老化时间。

而TCP协议与此完全不同，由于具有syn、fin、rst等控制信息，状态设备可以为不同状态的TCP连接指定不同的老化时间，ESTABLISHED状态的连接老化时间明显更长。这使得使用TCP实施同样攻击更加困难。为什么快速构造不同的TCP五元组无法达到UDP的效果呢？如果盲目使用不同源端口发送syn，没有真正的对端回应的情况下，这种连接状态将很快老化（在10秒甚至更短的时间内）。如果构造大量使用不同端口的真实TCP连接，那么除了给状态设备带来伤害外，攻击者自己也必须付出巨大代价来维持这些连接。你发起一个TCP连接，为了让状态设备保存该连接，你也必须保存该连接。除非通过大量的反射主机同时发起真实连接，否则在单台或少量主机上，这种攻击很难成功。对于无状态设备来说，我们不再需要担心五元组连接的保持。

但是UDP短时间内构造大量五元组仍会影响无状态设备的包分类算法的正常运行。基于包分类算法的优先级队列和缓存管理几乎都是基于五元组计算的，UDP的特性会使无状态设备难以对其进行流量控制。结果就是，即使UDP流量挤满各级队列和缓存，也无法准确识别出来。即便是BBR（Bottleneck Bandwidth and Round-trip propagation time）遇到UDP流量，也只能降低pacing rate，别无他法。

普通的运营商网络对TCP更友好，对UDP不友好，但同样无法深度检测TCP连接的真实性。一个简单的例子是将正常TCP数据的协议字段改为UDP。这样做会导致通信出现问题，甚至无法进行有效的传输：

if (iph->protocol == IPPROTO_TCP) {iph->protocol = IPPROTO_UDP;ip_send_check(iph);udph->check = 0;} else if (iph->protocol == IPPROTO_UDP) {iph->protocol = IPPROTO_TCP;ip_send_check(iph);}

Part 05●结语●

到这里，已经从底层角度基本说明了为什么在学术、游戏、实时音频等场景下会催生进一步的网络加速服务需求了。而加速服务的主要难在两点：其一，是如何处理客户端到加速器服务器之间的UDP连接；其二，是如何让游戏客户端去连接这个加速器（一般游戏客户端是没有设置代理服务器的功能的）。而场景宽带也正是旨在解决特定场景下以上所述的这些问题，为特定网络应用场景提供更流畅、快速的网络体验，在未来构筑更多元化、优质的网络服务。