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通知推送延迟问题的溯源及一点解决办法》对你有帮助，请点赞、收藏，并留下你的观点哦！
