自己的 mi5s 开发版刚刚装上，效果非常棒！！

apk 文件标题就是小米 5s，而且 5s 用的摄像头也是和 pixel 同一款，看来 5s 要升值了:)

@wangyucn

运营商绝对是故意 udp-qos 的，主要限制 p2p, 不然 bt/emule 会把他们整疯的。

@wangyucn

这个深度检测我觉得是多虑了。运营商的 qos 和流量区分完全是依赖与硬件设备提供商，他们没有自主开发深度检测的能力(大流量下用 cpu 做 spi 不现实，都是硬件 asic 做)。等到整个产业链都开始针对 faketcp 时，可能 ipv4/udp-qos 这些都不存在了。

@wangyucn

"我以后可能会模拟一个从外部看起来完全和 tcp 一样、无法封杀的协议。模拟重传和拥塞控制但是支持实时乱序到达。 "

这个不用自己实现，直接在 faketcp 上加个 sctp 就行，什么 multihoming, multistreaming, out-of-order delivery 都有，sctp 内核态与用户态实现都有现成的。webrtc 就搞了个 sctp over udp, 咱只需改成 sctp over faketcp 就好

@t123yh

syn,ack,seq 这些还是要装得像一些，不然过不了防火墙。不能总是用同一个 seq 啊，否则太容易识别了

可是我觉得在第二层收包会带来性能问题啊，因为这个肯定需要遍历所有收到的 IP 包，不管目的地是否是 faketcp，而如果只是普通 IP 包的话，iptables 会再次遍历剩下的 IP 包。iptables 是内核实现，遍历速度应该比用户态快很多吧。

尤其是部署在路由器上的时候，双重遍历应该会带来很大压力吧。

新内核上好像有个 ebpf 接口，配合 pcap 应该能在内核态进行 filter，如果你坚持在第二层处理的话可以利用这个加速一下。

@wangyucn

没必要在 2 层与 3 层同时作业， 建议单独开一个 tun/tap 设备，添加一个内网地址 192.168.254.254 之类的，再利用 ip_forward 和 iptables masquerade，可以在第 3 层完成所有动作。

感觉 icmp 隧道比 faketcp 效果还是差很多的，尤其是 nat 设备会让 icmp 很快超时，而 faketcp 连接可以保留很长一段时间。建议楼主砍掉 icmp,专注 faketcp。

这个非常有意义，曾经有一样的想法但觉得实现起来很麻烦。想知道楼主怎么实现的？

如果要伪装成 tcp，必然需要实现一个用户态 tcp 状态机，难道要借用内核 tcp 代码？

还有，感觉项目名称不准确。这个项目核心在于 fake-tcp/icmp 头部包装隧道，而 payload 可以是 udp，也可以是 tun/tap，对吧？鉴于 icmp-tunnel 这东西早就有人实现， 建议改为 faketcp-tunnel

@techyan
今天上海联通到上海电信 ping 120m, 绕道北京,真是奇芭到家了

@zrj766 为啥这么大个事，没有任何新闻报道呢？