tayga可以完成NAT64转换。 这看起来是在打一场非常大的仗。 一般来说，可以直接安装在yum/apt-get源代码上的软件是可靠的软件，我也信任tayga。 功能和性能都很好。 所以我也不去看那个代码，就这样拿来主义用了。
但是，tayga的大规模同时测试没有达到预期。 它竟然是一个使用单队列tun网卡的单进程单线程程序，其结构是大循环的。 tayga继续从tun字符设备读取IPv6或IPv4消息，进行6-4/4-6转换，然后将其发送回该tun字符设备。
看到这样的场景，我的老毛病又犯了。
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /和我多年前的做法一样。 但其实最终只是堆了一堆垃圾。 这就是我。 明明不懂编程却能进行表达的编程。 看代码会修改，但只会修改一点。 有时我会自豪。
多年后，我戏弄了自己。
实际上，可以通过仅用配置横向扩展性能来表示级别，而无需更改一行代码。 由于幼稚的消失，现在为了扩展老虎的同时处理能力，我的做法看起来多少没有工作量。
用多个线程分别执行大循环。
必须将大的动态池划分为n个段，或者干脆准备n个独立的池。 http://www.Sina.com/http://www.Sina.com /其中，多路径路由配置如下：
IP-6 route add 64: ff9b :/96 (nexthopviafe 8033603360991 d : BC 54336048233605 f1 dev NAT 64-13 nexthopviafe 8033603360991 d :48233605 F2 dev NAT 64 ) 603360991 d :991 BC 3360482360 . nexthopviafe 8033603360 .360
IP route add $ dynamic-pool _ from _ conf-1 dev NAT 64-1 IP route add $ dynamic-pool _ from _ conf-2 dev NAT 64-2 . IP rrou
这种配置一定比我修改的多线程多队列tun网卡的tayga版本更好。 每个tayga实例的配置是独立的，因此可以在不锁定的情况下访问共享资源。
我是多么自信地熟悉UNIX的设计哲学。 把小部件组合起来而不是写大程序，对于像我这样不会编程的人来说似乎再好不过了，但我的行为多次都与此相反。 我多么肤浅幼稚。
是时候揭露我曾经的愚蠢了。
从5、6年前开始，我就夸耀自己对OpenXXX一无所知，将OpenXXX改为多线程，并夸耀2.6.32版内核支持tun多队列、reuseport等特性由于有很多理由证明OpenXXX的单进程单线程大循环结构是愚蠢的，我也有充分的理由对此进行修改。
在对OpenXXX进行更改之前，以前的方案是启动多个OpenXXX实例，对该网卡进行bridge/bonding，然后发布唯一的虚拟网卡。 我不知道什么执念让我必须做这种看起来只是漂亮的事，至今也不知道。
不谈老故事，现在让我们来看看OpenXXX高性能扩展的正确做法。 其实那个手册已经有提示了：
远程随机
when multiple--远程地址/portsarespecified，orifconnectionprofilesarebeingused，initiallyrandomizetheorderofthe
listasakindofbasicload-balancing measure。
因为可以在一个群集的不同计算机上启动不同的OpenXXX实例，所以不能将它们移动到一台计算机上做什么呢？ 只需接收不同的端口并区分不同的虚拟网段。
这样，在服务器端，ifconfig将展示多个tun/tap网卡。 这有什么不好呢？ 如果您确实认为这不好，例如，如果您想使用相同的配置式，那么多个tun/tap网卡被分配给同一虚拟IP地址有什么不对的吗？ 您只需要通过每个实例的client-connect脚本或插件，将client携带的IP段添加到路由表中。
是IP route add $ ipnet _ from _ this _ client dev $ tun _ of _ this _ instance哦。 如果您想达到相同的监听端口，请支持使用端口。 或者，请使用LD_Port，Oh，no！ 这里又有不好的味道了，就此打住吧。
写这一段的目的不仅是嘲笑我自己是多么愚蠢，而且是想揭露把简单的事情极端复杂化的过程。 随着我个人的成长，我必须明白这是多么不合理。
而且，五六年前的那个时候，我觉得我随时都了解用多队列tun分配给每个线程一个fd。的内涵。 这是一个讽刺。
结论是什么？上锁访问全局数据结构。
浙江的鞋湿了，下雨下水也不胖。