在上次实验中（零成本自建企业级SD-WAN！用Panabit手搓iWAN实战），我们使用Panabit初步完成了iWAN隧道的搭建，不过也遗留了几个问题。
首先，为什么两端的内网互通时，中间传输分明经过了隧道，但为啥显示一跳就到了？经过查询，发现有说法是iWAN隧道为点对点封装，中间路径不可见，现象对得上，但引入了一个新的疑问，那就是跟配置隧道时的【二层转发】还有什么区别？
关于二层转发，需要升级专业版才能支持，这么一来，我们就测试不了了。与此同时，官方介绍iWAN还支持Segment Routing，这个也需要专业版授权才能支持，看来iWAN的测试要止步于站点互通了。
其次，查资料的时候发现，iWAN对比专线、IPsec VPN和L2TP VPN，均有一定的优势；尤其是在连接速度和传输效率方面。
这两个也好测试，直接抓包就能看出来。
首先，报文特征非常明显，都是UDP端口8000，没有使用其他端口。从协商过程来看，貌似是经过一次握手就完成了隧道协商，也就是最上面的两个报文，请求报文的数据长度为53字节，响应报文的数据长度为50字节；之后的报文间隔都是固定的2秒，应该是进入了保活阶段，并且报文的数据长度都是统一的52字节。
根据官方iWAN隧道技术白皮书介绍，iWAN只需要一次交互即可完成隧道建立，跟我们看到的情况一致；但对比时说传统VPN隧道需要几十次交互，有点夸张了。
当然，我们在配置时并没有启用加密，但是从报文封装来看，是对报文做了处理的。
我们的ping包原始长度为64字节，其实内层数据长度只有48字节，加上封装的长度为16字节的ICMP报文头，长度才达到64字节。实际上，ICMP报文头外层还封装了20字节的IP报文头，这时报文长度就达到了84字节，也就是iWAN封装前的报文长度；加上iWAN封装的8字节报文头，正好是数据报文长度92字节。而iWAN隧道接口默认的MTU为1420字节，实际传输效率能达到1420/1482=95.8%，确实挺高的。
根据官方iWAN隧道技术白皮书介绍，在后续版本里，Panabit还会继续压缩IP报文头，以继续减少额外报文头的大小，从而大幅度提升传输效率。但是其在稳定性对比中提到，iWAN轻安全，主要是依赖仅进行完整性校验实现的，如果对8字节报文头再进行压缩，性能提升不会很明显，安全性却会降得更低。
在未启用加密的情况下测试一下传输带宽，最高能够达到2.32 Gbps，平均也有1.85 Gbps。咱就说，白嫖免费版SD-WAN的用户里面，有几个出口带宽达到2 Gbps的？
看完了未启用加密的情况，我们再看看启用加密的数据。
首先，看协商过程，第一轮隧道协商的握手报文都增加了3字节，应该是增加启用加密的字段；之后的保活报文间隔依然是固定的2秒，且报文的数据长度都是统一的52字节。
从ping包的封装长度来看，内层的数据报文长度依旧是92字节。咋回事？不是说了加密吗？
我们再看看传输带宽是否有变化？
加密后的带宽还是有变化的，最高带宽为1.63 Gbps，平均带宽为1.52 Gbps，相比于未启用加密时，性能降低大约18 %。不过话说回来，白嫖免费版SD-WAN的用户里面，出口带宽达到1.5 Gbps的也不多吧？
观察后台的系统资源利用率，发现CPU利用率还没有正常打流时高，看来Panabit还手下留情了；如果放开的话，不知道能跑到多少呢。
所以，在实际使用中，你会选择开启加密吗？