不是GRE比IPSec更好，而是这个组合在大多数企业站点间互联场景下功能覆盖最完整。组播支持、动态路由、NAT穿越能力、性能开销——这几个维度一拉平，答案就很清楚了。
在IPSec VPN隧道场景下，tcpdump只能看到ESP包，无法定位应用层延迟异常是加密开销还是网络丢包。本文从内核架构层面分析两者的能力边界，给出基于场景的决策框架，并附上性能开销实测数据与验证结论。
隧道建立后小包正常、大文件拉胯，iperf3测速只有标称带宽的30%。排查一圈发现不是设备性能问题，是GRE头+IPSec头+双层IP头加起来把MTU撑爆了，内核被迫在隧道里做分片，性能直接崩掉。
perf/gprof/Valgrind三者的overhead、准确性、多线程支持有本质差异。延迟敏感服务和高并发服务的选型策略完全不同，本文给出决策矩阵和取舍权重。
跨国出口流量定位：如何从traceroute的IP序列追溯到BGP路由决策，当traceroute显示跨国延迟高时，大部分人盯着TTL递增的IP地址发呆。真正有效的定位方法是把traceroute当作BGP路由表的查询入口——每一跳IP背后都对应AS边界和BGP决策点，理解这些才能判断流量为什么走了当前这条路径，而不是你以为的那条。
