我们也检查了GFW和巨炮是否可能共享相同的注入设备[14]，但是没有找到证明这一点的证据。
特 别是，我们从一个给定的TCP源端口发送被设计为会触发巨炮注入行为的请求，后面跟上一个被设计为会触发GFW注入行为的请求。我们在几个源端口上重复实 验，结果发现GFW和巨炮注入的包都展示出了相似的奇特TTL旁路信道，这表示两个系统之间共享代码，但我们没有发现GFW和巨炮（注入的数据包）的 TTL值之间有明显的关联。
The GC appears to be co-located with the GFW
巨炮明显和GFW的物理位置一致
We used the same TTL technique to localize the GC on the path between our test system and the Baidu server. We found that for our path, the GC acted on traffic between hop 17 and hop 18, the same link we observed as responsible for the GFW. We also observed that unlike the GFW, we could trigger the GC using “naked” requests (i.e., requests sent in isolation, with no previous TCP SYN as required for standard communication). Acting on “naked” requests implies that the GC’s content analysis is more primitive (and easily manipulated), but does offer significant performance advantages, as the GC no longer needs to maintain complex state concerning connection status and TCP bytestream reassembly.
18/26 首页 上一页 16 17 18 19 20 21 下一页 尾页
|
