 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 5466 |
| 一个好用的、纯软件的扩展屏方案 分享发现 • kuanat • 176 天前 • 最后回复来自 kuanat | 2 |
| V2EX 是否会考虑增加专栏功能？ V2EX • kuanat • 213 天前 • 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验
13 Go 编程语言 • kuanat • 128 天前 • 最后回复来自 GeekGao
|
43 |
kuanat 最近回复了
5 天前 回复了 17681880207 创建的主题 › 程序员 › macOS VS Code 窗口透明怎么实现？ |
技术层面窗口透明是合成器（ compositor ）的功能，应用自己并不能决定自己是否透明。或者换个思路，窗口合成器提供给应用一个抽象的渲染区域，这个区域出现在屏幕的什么地方，以多少透明度显示都是要窗口合成器控制的。
所以需要一个能控制窗口合成器行为的应用，插件起到了告诉这个应用把什么颜色当作透明色的作用。楼上 issue 链接里的插件就是这样。
所以需要一个能控制窗口合成器行为的应用，插件起到了告诉这个应用把什么颜色当作透明色的作用。楼上 issue 链接里的插件就是这样。
5 天前 回复了 godFree 创建的主题 › Android › 求助 安卓 apk 逆向相关问题 |
frida-trace 看调用栈。
6 天前 回复了 creeeeezy 创建的主题 › NAS › 请教网络聚合失败的问题 |
@shika #26
balance-rr 还有 tlb/alb 都不需要特定交换机支持，具体可以看 linux bonding 的文档。
但这个行为确实与交换机有关，当启用 balance-rr 的时候，在交换机看来多个端口对应设备的 MAC 地址在反复切换，交换机会有异常的表现。一般来说管理功能越高级的越可能出问题，傻瓜型的往往没有影响。
balance-rr 还有 tlb/alb 都不需要特定交换机支持，具体可以看 linux bonding 的文档。
但这个行为确实与交换机有关，当启用 balance-rr 的时候，在交换机看来多个端口对应设备的 MAC 地址在反复切换，交换机会有异常的表现。一般来说管理功能越高级的越可能出问题，傻瓜型的往往没有影响。
6 天前 回复了 creeeeezy 创建的主题 › NAS › 请教网络聚合失败的问题 |
6 天前 回复了 creeeeezy 创建的主题 › NAS › 请教网络聚合失败的问题 |
OP 描述的现象的实质与单链路和多链路没有关系，我这里简单解释一下，就以 OP 的环境为例，L2 交换机没有端口聚合的功能。
L2 交换机的工作原理是根据 MAC 将数据包发送到特定的物理端口上，物理端口对应设备的 MAC 是通过记忆或者 arp 协议来更新的。L2 链路聚合会使聚合的 NIC 设备共享相同的 MAC 。
设想客户端 MacBook 通过 smb 协议访问 Win/Linux 资源，这是个单链路的请求，到达交换机端口的时候，不同交换机可能有不同处理方式，不管怎么样，都只会通过一个口到达 Win/Linux 。
由于 Win 不支持 round robin 的平衡模式，所以返回数据一样只会走聚合链路中的一个。这是常说的单链路无法超过单一接口最大速率的情况。Linux bonding 的区别在于，返回数据（包）会轮流经由两个网卡发送，所以可以同时利用两个 NIC 的带宽。当这些数据包到达交换机的时候，又会被交换到客户端的那一个端口上。
能够实现这个效果的原理就在于 linux bonding balance-rr 这个实现。其他的负载平衡方式主要看 hash 参数，也有些自适应的模式能达到类似效果。更底层的原因是 linux 网络栈是内核实现，来源不同的包只要具有相同的元组就可以被内核转交给应用程序正常处理，而应用程序构造的数据包交由内核之后，经由什么途径发出与应用程序无关。
这个实现对交换机没有要求，如果交换机可以对两个端口做聚合会更好一些，这样就不需要反复更新 MAC 与端口的绑定。可能存在的问题是乱序，即顺序包经由两个 NIC 到达交换机时先后顺序错乱了。双 NIC 聚合可能还好，数量越多 rr 模式越可能产生乱序。
PS
上面说得可能有些抽象，如果有 socket 编程经验可能更容易理解一些。
关键点是网络栈是内核实现，协议/IP/端口这些都是属于内核的，而不是属于某个应用的，同样也不属于某个网络设备。应用只能通过 bind 之类的方法获得 IP 端口的使用权，内核收到的数据包，把内部应用层的部分交给应用程序。应用程序处理完毕后，发出的数据包实际还要回内核，由内核包装上外层协议并完成路由（一般说的四表五链），最终到达网络设备 NIC 的时候，再做 L2 层封装上 MAC 等等发送出去。
所以本质上应用层面上的单链路是否经由物理层面的单通道发送是不相关的两件事，正因为这种架构上的解耦，最终才能够实现单链路带宽翻倍的效果，同时还不需要特定的交换机支持。
L2 交换机的工作原理是根据 MAC 将数据包发送到特定的物理端口上，物理端口对应设备的 MAC 是通过记忆或者 arp 协议来更新的。L2 链路聚合会使聚合的 NIC 设备共享相同的 MAC 。
设想客户端 MacBook 通过 smb 协议访问 Win/Linux 资源，这是个单链路的请求，到达交换机端口的时候，不同交换机可能有不同处理方式，不管怎么样，都只会通过一个口到达 Win/Linux 。
由于 Win 不支持 round robin 的平衡模式，所以返回数据一样只会走聚合链路中的一个。这是常说的单链路无法超过单一接口最大速率的情况。Linux bonding 的区别在于，返回数据（包）会轮流经由两个网卡发送，所以可以同时利用两个 NIC 的带宽。当这些数据包到达交换机的时候，又会被交换到客户端的那一个端口上。
能够实现这个效果的原理就在于 linux bonding balance-rr 这个实现。其他的负载平衡方式主要看 hash 参数，也有些自适应的模式能达到类似效果。更底层的原因是 linux 网络栈是内核实现，来源不同的包只要具有相同的元组就可以被内核转交给应用程序正常处理，而应用程序构造的数据包交由内核之后，经由什么途径发出与应用程序无关。
这个实现对交换机没有要求，如果交换机可以对两个端口做聚合会更好一些，这样就不需要反复更新 MAC 与端口的绑定。可能存在的问题是乱序，即顺序包经由两个 NIC 到达交换机时先后顺序错乱了。双 NIC 聚合可能还好，数量越多 rr 模式越可能产生乱序。
PS
上面说得可能有些抽象，如果有 socket 编程经验可能更容易理解一些。
关键点是网络栈是内核实现，协议/IP/端口这些都是属于内核的，而不是属于某个应用的，同样也不属于某个网络设备。应用只能通过 bind 之类的方法获得 IP 端口的使用权，内核收到的数据包，把内部应用层的部分交给应用程序。应用程序处理完毕后，发出的数据包实际还要回内核，由内核包装上外层协议并完成路由（一般说的四表五链），最终到达网络设备 NIC 的时候，再做 L2 层封装上 MAC 等等发送出去。
所以本质上应用层面上的单链路是否经由物理层面的单通道发送是不相关的两件事，正因为这种架构上的解耦，最终才能够实现单链路带宽翻倍的效果，同时还不需要特定的交换机支持。
10 天前 回复了 hengyoush123 创建的主题 › 分享创造 › kyanos 一个可以查看网络数据在内核中耗时的命令行工具，迎来 1.4.0 版本更新 |
eBPF ftw!
赞一个！
赞一个！
13 天前 回复了 RiverRay 创建的主题 › 分享创造 › 发现了一款超有意思的 AI whisper 语音输入法 哈哈 |
妙哉！
14 天前 回复了 wjpauli 创建的主题 › Amazon Web Services › 求助： AWS 的 SES 不给出 Sandbox？ |
这个审核很迷，年初帮朋友做个项目申请没过就改用第三方的了。然后过了大概半年突然发邮件说违规把 ses 停了，又过了几天说封错了，结果 ses 权限就莫名其妙开了。
Select Language