The Great Cannon (GC) differs from the GFW: as we will show, the GC is an in-path system, capable of not only injecting traffic but also directly suppressing traffic, acting as a full “man-in-the-middle” for targeted flows. The GC does not actively examine all traffic on the link, but only intercepts traffic to (or presumably from) a set of targeted addresses. It is plausible that this reduction of the full traffic stream to just a (likely small) set of addresses significantly aids with enabling the system to keep up with the very high volume of traffic: the GC’s full processing pipeline only has to operate on the much smaller stream of traffic to or from the targeted addresses. In addition, in contrast to the GFW, the GC only examines individual packets in determining whether to take action, which avoids the computational costs of TCP bytestream reassembly. The GC also maintains a flow cache of connections that it uses to ignore recent connections it has deemed no longer requiring examination.
巨 炮和GFW是不同的设备：就像我们后面会展示的，巨炮是在路径上的系统，不仅能干扰通信还能掐断通信，对于目标通信来说巨炮就像个中间人一样。巨炮并不主 动检查链路上的所有通信，只是拦截目的地是（或来自于）目标集合的地址的通信。将全部通信流减少为（似乎很小）的地址集合可能会显著提升系统对于非常大量 流量的追踪能力：巨炮的完全进程管道只需要操作大大减少的目的地是或者来自于目标地址的通信流。补充一点，与GFW相反，巨炮对数据包进行检查的时候只决 定是否行动，避免在TCP字节流重组上消耗计算资源。巨炮也维护着一个连接流缓存，用来忽略被认为不需要进行检查的连接。
The GC however also shares several features with the GFW. Like the GFW, the GC is also a multi-process cluster, with different source IP addresses handled by distinct processes. The packets injected by the GC also have the same peculiar TTL side-channel as those injected by the GFW, suggesting that both the GFW and the GC likely share some common code. Taken together, this suggests that although the GC and GFW are independent systems with different functionality, there are significant structural relationships between the two.
11/26 首页 上一页 9 10 11 12 13 14 下一页 尾页
|
