OpenWrt开启Software/Hardware Flow Offloading后iOS通知推送延迟问题的溯源及一点解决办法
实际上这个问题是我在将路由器刷成OpenWrt后偶然发现的。本来自使用的路由器是AX3 Pro,但是使用一段时间后发现这个路由器对IPv6的分配策略上有着不小的问题:本地运营商下发了/60的前缀后,此路由器并不会自动将此段地址切割以供二级路由使用,导致二级路由只能分配到/64的IPv6地址,无法继续下发地址,虽然在二级路由上可以使用NAT技术使下挂设备使用IPv6网络,但是这样显然违背了IPv6设计的初衷;其次,AX3 Pro默认将IPv6防火墙完全打开,同时无法在管理页面将此防火墙关闭,导致无法从公网访问到路由器后面的IPv6设备,这也明显阻碍了从外界管理内网设备的需求。所以,只能无奈舍弃这款路由器而选择可以刷入OpenWrt的路由器(OpenWrt对于IPv6及相关设置的支持良好),选择了搭载MT7621+MT7615的路由器解锁SSH权限并刷入了OpenWrt系统。
图1 MT7621官方数据参数
刷入系统几天后,偶然在一次聊天中发现iOS的消息通知推送有了延迟,通知框最迟的时候显示的是将近十分钟前的消息。于是用另一台设备发送测试消息,发现只要设备空闲超过两分钟,iOS的通知消息便有了明显的延迟。起初怀疑是官方的OpenWrt版本使用的都是开源驱动,对第三方设备的支持并不那么良好,于是自己拉取源码,修改编译选项将开源驱动换为MTK官方的闭源驱动编译出固件,再次刷入后发现问题仍然存在,但是后来换成完全基于MTK官方驱动且可以完全调用MT7621的硬件加速功能的Padavan系统后就不再存在消息延迟的问题。这个问题很令人感到困惑,本以为是驱动造成的问题,但是同样使用了闭源驱动,两个系统却有不一样的表现,只能是OpenWrt可能在某些关于网络的实现上有问题,但具体是哪里的问题,实在是不太好发现。于是在各个有关网络的论坛内搜索有没有类似的情况出现,终于在这个帖子内找到了遇到过类似问题的人: iPhone 推送通知延迟,这种情况出现在只连接 WIFI 的情况下。并且下面有网友给出了一种可能的解决办法。
图2 相似问题的帖子
图3 网友给出可能的解决方案
图4 自编译固件Turbo ACC管理页面
这里涉及到一些Apple设备的通知消息推送的机制,Apple设备的推送服务和主程序是独立的,每次Apple设备启动系统后,推送服务便创建一条与以下网段: 17.249.0.0/1617.252.0.0/1617.57.144.0/2217.188.128.0/1817.188.20.0/23
之中任一推送服务器的TCP长连接(事实上Apple Inc.拥有17.0.0.0/8一整条A类网段…),并每隔十分钟发送一次心跳包以Keep Alive。
图5 APNS使用的协议与端口
以上帖子是最接近解决问题的方法了,其他帖子甚至只有“同道中人”在反馈问题甚至没有任何可靠的解决方法。按照上面给出的方法在OpenWrt管理页面中关闭软/硬件加速,经过一段时间测试,确实消除了推送延迟的问题,但关闭此选项却带来了更大的问题:网速的极大下降。上面提到的MT7621参数表可以看出这颗CPU虽然有着双核四线程,主频仅有0.88GHz,但内置的硬件加速功能却可以带动上下同时1Gbps的网络流量。原厂固件一般搭配专用的闭源驱动来驱动这一功能
如果觉得《OpenWrt开启Software/Hardware Flow Offloading后iOS通知推送延迟问题的溯源及一点解决办法》对你有帮助,请点赞、收藏,并留下你的观点哦!