App Proxy Provider与Packet Tunnel Provider的核心区别是什么？

首先直接澄清核心误解：默认配置下的Packet Tunnel Provider 完全不等同于 App Proxy Provider，理解偏差主要是混淆了Packet Tunnel Provider两种运行模式的适用场景。

二者的核心差异可以从三个维度区分：

• 处理的数据层级不同
  • Packet Tunnel Provider 操作的是IP层原始数据包，无论运行在哪种路由模式下，拿到的都是未经过系统协议栈处理的完整IP报文，需要自行实现TCP/UDP协议的封装、解封装、连接状态维护等底层逻辑。
  • App Proxy Provider 操作的是传输层及以上的应用数据流，系统已经完成了TCP握手、UDP报文拼接、传输层重传等底层网络处理，仅需要对已经成型的字节流做转发即可，无需接触IP层报文。
• 路由匹配逻辑不同

  Packet Tunnel providers可运行在目标IP模式或源应用模式下，后者是单应用VPN的实现形式之一，另一种实现形式就是App Proxy Provider。
  默认路由模式为NETunnelProviderRoutingMethodDestinationIP。
  结合文档说明可以明确：

  • Packet Tunnel Provider 默认的NETunnelProviderRoutingMethodDestinationIP模式是按照目标IP地址匹配路由，所有符合目标网段规则的全设备流量都会进入隧道，和应用归属完全无关，属于常规的全局/网段级VPN实现。
  • 只有当Packet Tunnel Provider 切换到NETunnelProviderRoutingMethodSourceApplication模式时，才会按照源应用匹配路由，仅转发指定应用的流量，这才是和App Proxy Provider场景重合的单应用VPN实现。
  • App Proxy Provider 天生仅支持按应用粒度匹配路由，无法实现按IP网段的全局/部分流量转发。
• 能力边界不同
  • Packet Tunnel Provider 灵活性更高，可支持自定义隧道协议、IP包修改、非TCP/UDP流量（如ICMP）处理、全局/单应用/多应用流量管控等复杂需求，但开发成本高，网络栈底层逻辑的实现容错率低，容易出现性能和兼容性问题。
  • App Proxy Provider 开发成本更低，系统屏蔽了底层网络细节，仅需要处理应用层数据流转发，但灵活性受限，无法接触IP层内容，也无法处理非TCP/UDP协议的流量，仅适用于单应用代理场景。

内容的提问来源于stack exchange，提问作者Jorn Rigter