可以吐槽两年增长 245%的话年均增幅是 86%吗……
但是 38T 到 45T 增长比较小就是了
五年间平均每年增长 32%，这样的话看着还可以。
当然，出口是出口，实际感受可能是另一个问题就是了。

https://www.rfc-editor.org/rfc/rfc6455
看文档。不要 base64 ，完全是副作用。
看起来你没有发送一个完整的帧，而且前半个不知道是什么东西。调试 ws 的话最好从握手结束就开始，因为每个 frame 或者 msg 有长度。

很久很久以前用过 dd-wrt ，后来是 openwrt ，再后来就是用 centos7 （现在是 rocky9 ）从头开始搭路由。
旁路由还是算了，甚至从来都没尝试过，看结构就不优雅。
需要什么功能自己动手做就是了。
现在是两条宽带，双出双进双栈，然后下面用的 ubnt 的 ap 。
问题就是各种需要自己动手（但是除非大改结构不会整个挂掉，本身大改结构的话也经常需要整个重启），以及没有图形界面（需要这种东西吗）
自己做个动态故障转移，四十多条隧道呢怎么可能会断网，除非物理出口整个被掐了。
自主可控确实很舒坦，最近把 cfst 也自己用 bash 重写了一个。

icmp_seq=1518 ？
序列号到了 1518 ？还是包大小 1518 ？
所以 3.x 下面链路 mtu 是多少……

@bg226316 校内流量一般是免费的吧？那部分可以走学校的端口出去。你查论文什么的很可能也需要走学校的 ip 段才有权限。
这么简单的东西不需要装 op ，一般的 linux 甚至 windows 都可以，mac 应该也可以但是我没有实操过
mosdns 可以在解析的层面优先 v4 或者 v6 ，但是如果纯 v6 的话，99%会出奇怪的问题，现在的网络还远远没有到可以脱离 v4 的程度
当然如果能用 v6 钻隧道出去在外边有可靠的中转机再走 v4 那是可以的

找个电脑（最好是路由器）同时连接 cpe 和学校内网，然后大家把网关指向这个电脑。
（所以说最好是路由器，可以直接下发）
这个电脑（路由器）的默认网关在 cpe 上，但是学校免费 ip 段走学校的网口。
学校的免费 ip 段通常是固定的。至于 v6 ，用 cpe 还是校园网看你喜好了。

目视可及的话首选无线网桥
有条件甩光纤的话也可以光纤

@thereone 主备实现不难，关键是意义在哪儿……如果旁路由这些都能干了，他还安心当个旁路由吗……为什么不直接升级为主路由呢，网络更简单清晰。当然，如果作为主路由备份是为了过渡到主路由的话，我双手赞成。

多线场景是极限自定义的场景。只有作为主路由，才好充分利用多条宽带的能力。因为流量是双向流过的，才好建立 conntrack 。
简单的说，如果有个 vps ，然后自己有两条宽带 a 和 b ，再乘上 v4 和 v6 ，就变成 4 条线路了。
这一点旁路由完全没办法决定自己出去的直连数据包从哪里出去……如果要同时用两条不同的线路和远端建立两条链路做主备，旁路由最多最多只能一个 v4 一个 v6 然后让主路由写路由表了吧。
但是在主路由上直接搞的话，一切都可能实现。
以及前面说过的，端口映射，也需要在主路由上有相对复杂的配置，这一点旁路由很可能是个干扰。
再考虑 v6 的话，旁路由就更难受了。

其实就是说，当网络结构越来越复杂的时候，旁路由需要越来越多地与主路由交互。这时候就更显得旁路由多余甚至有点难受了。
当然重复一下观点，作为学习练手，或者由于条件所限使用旁路由是很合适的。除此之外长期稳定使用特别是重度使用的话，建议直接做在主路由上。

@thereone 双向经过一个设备的话可以用（有点复杂的） conntrack 解决。单向经过的话就没什么好办法了。

@thereone 来回路径不一致可能还是小事，端口映射确实可能会出问题：
假设内网用户是 192.168.100.200 ，主路由 192.168.100.1 ，旁路由 192.168.100.9
映射（包括各种映射）了 8888 端口到外网端口 198.51.100.100:8888 。
此时有来自 203.0.113.2 的用户访问了你的公网端口，然后他给你发了一个包。
203.0.113.2:12345->198.51.100.100:8888
进行 nat 以后，通过主路由转发到了客户机，到这里还没问题。
然后客户机需要给他回包：
192.168.100.200:8888->203.0.113.2:12345
这时候这个包首先被发送到旁路由。这个时候说不定（看策略）就被走其他路径“劫走”了，
然后可能通过 vps 的出口发给了对端的机器，对端看起来数据包是这样的：
192.0.2.33:27428->203.0.113.2:1234
这数据包哪儿来的……于是就扔掉了，通信失败。

单点故障的场合，不认为家庭环境有那么多需要热备的，要坏的话主路由一样会坏，主路由更需要热备吧……光猫也可能坏，怎么热备呢？局方给你套个 SDH 大圈圈吗……不可能的吧……连链路都只有一条的说……
虚拟链路的话……就只有一条吗……就算只有一条，主路由一样可以临时禁用（如果这是希望的结果的话）。不要默认旁路由容易坏，更不要默认特殊功能的设备就容易坏。如果设置正确、运维得当是没问题的。当然，如果是刚上手的学习阶段，还是可以用旁路由练手的。

接下来就是性能，转发性能确实比不上硬件但是在家用场合下可以忽略。2023 年了，就算还在用 j1900 ，nat 性能会成为问题吗？小包转发确实有可能会没法千兆线速，但是家庭网络您在干啥会有那么多小包？家庭网络最大的 cpu 开销，一是 pppoe ，二才是加解密。pppoe 是个跟不上时代的古董协议，特别耗费资源。再说，升级个设备其实也没多少钱，考虑下宽带费用电费可能还有其他按月计价的费用……设备成本可是可以摊销的。

透明网桥我实现过，整体上还不错但是有点其他问题，现在 broute 表都被拿掉了，以后不知道该怎么搞。可是那也是条件所限拿不到路由的时候才用的，拿得到路由的话用路由舒服多了。企业应用也一样，管理设备要串行接入网络的话要物理操作要断网，但是路由指过去的话就可以远程操作，也可以屏蔽，还可以部分应用。

至于配置方便程度就更不要说了，拿着主路由权限可以下发各种东西，你要给多少设备设置网关啊？我家的电脑×n 、手机×n 、pad 、电视、虚拟机×n ，都要一个个爬上去设置 dns 吗……我家下发的 dns 的 ip 都是一样的，但是会根据策略拉到不同的服务，返回的东西也可能不一样，这些用旁路由……不是做不到，而是，还是算了。

最后，多线上联（不同运营商多条宽带）这一条，旁路由被薄纱。

作为入门的话，旁路由或许还好啦
或者某些条件受限，比如路由器房东的 /搞坏网络会被老婆要求跪主板，那也就旁路由吧
时间长了还是主路由的好，流量自然流过，对下游设备完全透明，能实现的东西也更多
不稳定？最大的可能是操作不当，我家核心路由不停电都不重启的
性能？ n100 来一个，路由场景没有什么 hold 不住（过剩了）
至于网络分层……运行在 ip 层有什么行，完全可以。

所以，“多数用户”到底是谁啊。

最后那句倒是很同意。

@hadoop 和无公网 ip 的家宽没区别的感觉，跨网一定程度上会被 QoS

一般来说搬家搞丢了可以免费要回来吧。

@admin13579 大炮打的所谓“境外反动网站”是 github 。
以下内容转载自 wikipedia https://zh.wikipedia.org/wiki/%E5%A4%A7%E7%82%AE_(%E7%BD%91%E7%BB%9C%E6%94%BB%E5%87%BB%E5%B7%A5%E5%85%B7)


大炮的第一个目标是 GreatFire 运营的“依附的自由”相关项目， 首次攻击是对 GreatFire 运营在内容分发网络上的镜像站点，出现在 2015 年 3 月 14 日。之后 GreatFire 报告大规模的攻击出现在 3 月 17 日。对镜像站点的攻击在 3 月 25 日终止。

之后在 3 月 26 日，被 GreatFire 用于托管反审查项目的 GitHub 也受到攻击。
参见：对 GitHub 的审查和封锁 § DDoS 攻击

多次技术报告显示，对 GitHub 的攻击的方式是采用了 HTTP 劫持，通过向百度注入恶意的 JavaScript 代码，其功能是每隔 2 秒加载一次 GreatFire 或其运营的纽约时报中文网镜像站点的账号主页，以使从中国大陆以外访问百度网站及广告的流量转换为 DDoS 攻击发送至目标。对 GreatFire 运营的镜像站点也使用了了类似的方法。百度已否认自身产品存在安全问题。

这次攻击导致 GitHub 在全球范围内的访问速度下降。

根据系统状态消息页面的显示，已于 3 月 31 日停止了网络攻击，该日凌晨 0:09 （ UTC ）已经稳定。GitHub 在其 Twitter 与微博予以了证实。至此，此网络攻击共持续了五天。Google 的研究人员观测到 HTTP 劫持在 4 月 7 日终止。