@KCheshireCat 但愿能找到改进措施。
----------
下面是脑洞：
仔细考虑后，即使利用 libnetfilter_queue 做出一个，抛开稳定性、吞吐量不谈，
我感觉按延迟也不靠谱， ack 的时间受目标服务器负载的影响，不能说明问题；
主动学习数据包长度、 ttl 值 也难免误伤，
恐怕还要解析数据包内容
一般也就是内容有固定特征的 302 redirect 、 meta-refresh 、 javascript 啥的。

字符串黑名单过滤之。

思路有了，项目起名叫 WFG 不错。 XD

awesome idea ， but.....
看 issue ，疑似有误伤，求解惑。
不知可否在其他发行版复现这个问题

@ovear 我似乎理解你说的意思，就是元素为 chan 的 slice 。
一开始就是这么弄的， 然后发现 2 个问题：
新开的 goroutine 需要获取一个 chan 用来收消息；
一个收消息的 goroutine 可能随时退出，然后这个 slice 大小只增不减。

@jarlyyn

对，就是一个 go routine 负责从外部读取一些东西塞 chan ，
其他一组 go routine 需要取 chan ，
这组 go routine 随时有新增和退出。

如果不用 mutex 。。。

@SuperFashi
就是一个 goroutine 从网络或者标准输入或其他地方得到了一个消息，
需要将其发给一组 goroutine 。

这场景应该是比较常见吧。

@gam2046 比如说网关 A 是 192.168.1.1 ，网关 B 是 192.168.1.2 ，目标服务器 ip 是 1.2.3.4 ， 你可以试试
ip route add 1.2.3.4 nexthop via 192.168.1.1 weight 1 nexthop via 192.168.1.2 weight 1

如果想负载均衡所有，可能会发现 default route 不能这么玩，可以利用
0.0.0.0/1 加上 128.0.0.0/1 两条，效果相当于 0.0.0.0/0

实际问题是数据包大量地不按顺序到达，吞吐量上不去。

如果谁能写个 kernel module 。。。魔改 tcp 收发部分，缓存数据包，以加一些延迟的代价换取带宽叠加和 failover 。。。

@gam2046
我记得 windows 上可行的叠加方式，最简单的就是加几千条静态路由。。。
多年前试过，很简单，就是提前做好个批处理，运行，等几分钟。。。

高级一点的，就是路由器上 MultiWAN 那种，按连接负载均衡 failover ，
这些技术都相当成熟，最近想到个点子，借助$$redir + haproxy 可以玩的很 high 。

而我最终想要的是 packet level 的，聚合多个 tunnel 的带宽
实践操作起来可能因为 带宽延迟不匹配 -> tcp out of order
大幅降速到接近不可用。。。

@gam2046 我看了无数的 blog 和论坛， 总算了解了按连接负载均衡的可靠方式，

然而聚合到单条 tcp 连接上，可行性还是个谜。

刚看完 go 语言入门，正在动手。。。/doge
一开始可是打算写 linux kernel module 的，后来觉得目标不能定的太大。

楼主自己浪费了若干天时间，如果可以为 N 多用户提升效率，
应该也是很有成就感的吧。。。

即使弃坑了，既然提出了一个好点子， 万一有人接手呢

还有自定义窗口分组、 排序规则， 甚至允许鼠标拖拽动态调整分组和排序，
只要已有的窗口没关，顺序别乱跳。。。
考虑下如何最便于操作。

比如打开 N 个相同窗口比如 putty ， 可以被自动分一组，
在这个界面按一个字母进入一个子层级，可以继续按字母键选择。
还有，窗口标题要搞醒目些。。。

对了，这是个 win10 内置功能的扩展，还是可以支持 win7 啊？
---------------------------------

话说这里不是 iv2ex 么

借地讨论：

利用多个宽带能不能聚合带宽到一条 tcp 连接。
比如同时蹭 3 个网，建 3 个连接到 vps 上。

@Blazings 记得 win10 的这个界面没有 ABCDEFG 的提示的。

如果楼主指的是按对应字母切换到对应窗口，
这东西也挺实用啊，
按窗口数目多寡，每次操作都能节约个 0.5~5 秒的。

建议： 别 ABCD 这么排，应该
QWER
ASDFG

这么排

终结了么


dnat 改目标地址
snat 改源地址

作为路由器，只需要 dnat （因为客户端有路由 via 本机）或者 dnat 的一种特殊形式 masquerade 。
作为跳板，需要 dnat 和 snat 两条命令

如果能搞成 rtmfp 的，无论 iplevel multicast 还是 application level multicast 都能彻底解决带宽问题。

然而我没试成功，只搞成 rtmp 的，也是因为没有需求，这就几十人内部用

延迟要求高不高？ 我搭过一个简单的，用的
ffmpeg + nginx-rtmp + flowplayer ，延迟大概 1 秒左右

服务端的带宽问题，也弄成了其他服务器从第一个服务器接收后转发，延迟增加 1 秒左右，这样可以堆服务器数量支持更多用户

有兴趣 @我，可以分享出来。
简陋的半成品，不收钱

sync 仅可以同步操作系统内存中的缓存数据。

硬盘（或 raid 卡）内部的缓存， 没听说过操作系统可以控制的。
专业的 raid 卡带电池，就是为了避免掉电时丢失缓存中的数据。
企业级 ssd 一般内置一个大电容，作用类似。
因为这个缓存对操作系统透明，而且各厂商实现方式可能区别较大，主要是没听说过这个缓存有相关接口暴露给 OS 的。

一般操作系统可以控制的缓存，是指系统内存作为文件系统读写的缓存。

比如说死机了，可能内存中未写入磁盘的数据丢失，但是硬盘没掉电，硬盘的缓存仍然同步完成；
再比如说断电了，内存中的数据丢失，硬盘掉电导致硬盘自身的缓存中的数据也丢失，此时 raid 卡的 fbwc 和 bbwc 啥的， ssd 的“电池” 就起作用了。

@ragnaroks 360 公司太伟大了，连 1%的用户都考虑到了。赶紧装一个， 从此再也不怕恶意脚本了！ （滑稽脸）


不过 linux 作服务器也不是 1%啦， 是 90%多吧。

@jason19659 对对对，就是这个意思。
不过杀伤力不够强， 万一人家有快照呢？
不如留木马靠谱，受害者发现之前可能 vps 账号已经被 ban 了。