#!/bin/sh
iptables -t mangle -F POSTROUTING
tc qdisc del dev br-lan root 2> /dev/null > /dev/null
tc qdisc add dev br-lan root handle 1: htb default 2
tc class add dev br-lan parent 1: classid 1:1 htb rate $((3072))kbps
tc class add dev br-lan parent 1:1 classid 1:2 htb rate $((3072*6/10))kbps ceil $((3072*6/10))kbps prio 0
tc qdisc add dev br-lan parent 1:2 handle 2: sfq perturb 10
tc filter add dev br-lan parent 1: prio 20 protocol ip handle 2 fw flowid 1:2
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.100-192.168.8.199 -j RETURN
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.100-192.168.8.199 -j MARK --set-mark 2
tc class add dev br-lan parent 1:1 classid 1:3 htb rate $((3072*4/10))kbps ceil $((3072*10/10))kbps prio 1
tc qdisc add dev br-lan parent 1:3 handle 3: sfq perturb 10
tc filter add dev br-lan parent 1: prio 10 protocol ip handle 3 fw flowid 1:3
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j RETURN
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j MARK --set-mark 3
好久没玩这种了有点生疏，不知道这个从 tomato 改的规则能否适应 openwrt ，是否在 prio 优先级设定是否有错。这个仍然属于限速不是 QOS ，而且它针对下行的 br-lan ，却不是真正有效的上行方向 pppoe-wan 。
基本思路
1.将一条带宽按 6/10 的比例分配给访客 --dst-range 192.168.8.100-192.168.8.199 ，拥有高优先级 prio 0,最多只能使用 6/10 的带宽，
2.按 5/10~10/10 的比例分配给办公 --dst-range 192.168.8.200-192.168.8.205 ，拥有低优先级 prio 1,有 4/10 的保障带宽，有机会获得 100%的带宽
3.sfq 保障了网络在极端拥挤情况，仍然能获得一定的带宽
然后开始互相抢夺。
可以用这些命令观察效果
iptables -t mangle -vnL POSTROUTING
tc -s -d class show dev br-lan
tc -s -d qdisc show dev br-lan
这是个 QOS 话题，而不是限速，这两个词只能说有一定联系，却有非常多的不同点。
缺少很多关键信息，家用 /企业，带宽多宽。
典型的家用带宽最大的问题
1.并发数超标连接被抑制，比如迅雷。会出现实际上下行流量都有极大空余，网络却连网页也打不开。
2.上行严重拥塞丢包，导致下行异常。网络上流行什么设置总流量的 80%来避免这个问题，实际这种把 1 根大水管切成 2 条小水管依然每条小水管还有 80%拥塞问题。
3.QOS 和限速的区别，QOS 能改变 PFIFO 先进先出队列，变成有优先级的插队先出。这样就可以让浏览网页这种操作有一种低延迟刷刷刷的感觉，而让看 P2P 流量出现高延迟丢包情况。这是一种优先保障级服务。
市面上有这种限速算法实现的只见过 routeros 的 PCQ ，对于 openwrt 来说也可以用 shell 脚本进行插值。
但显然有点把问题复杂化，还是得首先明确带宽有多宽。然后按(访客+办公)实施限速，通常就是将办公用静态 DHCP 指定一个 IP 范围，将访客用于通用的 DHCP 范围。然后针对这两个 IP 池进行分别限速，这 2 个限速之和，特别是上行流量基于总带宽的 80~90%附近。不要用做数学减法来看待流量分配，让终端 IP 自己互相抢夺有限的带宽，实现自足分配。所谓的限速往往造成流量不能 100%的利用。现在都搞动态 QOS ，让谁都有机会 100%的获得所有带宽，无视任何 P2P 的存在。
当然这种是纯理论化，突际到了 tplink 这种所谓的企业级可以带 512 个 IP ，面对 20mbps/60mbps 的企业光纤也无可奈何。所以可以实现 QOS 是上策而不是限速。
当然这个年代还仅只能提供 500KB/s 的带宽，我觉得只能应急用用啊。谁没有个 4G/5G 啊。。。
性别女？一定会招来一堆狼。。。上 souler
不过像我这种上了岁数不像年轻时那么喜欢认识人了。有一种和谁都聊得来又相忘 soul 的感觉。不过如果仅是无聊找不到人说话，通过它来打发时间，甚至加了一个又一个的天南海北的网友也仅是因人而异。
哈哈完全不懂在说什么，看看专业的 stunnel 是怎么服务器端验证客户端证书再通讯，目前也仅会配置 level 2 。这个软件很多参数有些超前包括 qqmail 都不能支持 tls1.3
verify = LEVEL
verify the peer certificate
This option is obsolete and should be replaced with the verifyChain and verifyPeer options.
level 0
Request and ignore the peer certificate.
level 1
Verify the peer certificate if present.
level 2
Verify the peer certificate.
level 3
Verify the peer against a locally installed certificate.
level 4
Ignore the chain and only verify the peer certificate.
default
No verify.
verifyChain = yes | no
verify the peer certificate chain starting from the root CA
For server certificate verification it is essential to also require a specific certificate with checkHost or checkIP.
The self-signed root CA certificate needs to be stored either in the file specified with CAfile, or in the directory specified with CApath.
default: no
verifyPeer = yes | no
verify the peer certificate
The peer certificate needs to be stored either in the file specified with CAfile, or in the directory specified with CApath.
default: n
搜索一下 stunnel ，平时用的一个方法就是将 qqmail 转换成普通的 tcp 25 供 smtp 调用。把普通的变成加密的也是它擅长的，可以找到很多实例。
反正 android 手机单个 vps 全程 vpn 没用,打开定位时依然是附近的人，据说本拉登就是这么被猪队友坑的。
tor 不好用吧，另外一种就是国外的 mesh 社区网络但不清楚匿名性如何。有时候更宁愿把数据通过两台服务器或者多个端口负载，不知道机器是否有能力对这些零乱的数据进行拼凑。
我的那台 bu201 当时一项就是做 1 米的自由落体测试，里面用的东芝盘带一个晃动软件。也许这也是个特种硬盘才有的特性。
平时关机都是用快捷方式 shutdown -s -t 0 -f 。我怕死还是关机保险。毕竟连突然断电整盘报废都遇到了。
之前公司的电脑随便找了块角铁，绑了根电线搭在机箱外壳，只能说针对静电现象还是有效果的。
其它的老房子铁水管搭过 。
呵呵呵呵呵呵呵呵，公司的网络已经建好三年，可是经常受到网络小白的推责，比如扫描枪不会操作要触发两次，也扯到跟无线网络有关，不知道什么跟什么。
知道什么叫不尊重他的成果
我会因为别人是网络小白，连故障原因都判断不清楚，去在一万平方场地重建网络，开玩笑。
置疑他的水平
老板找来移动专业人员，又找来
erp 实施方的硬件人员本来就是用来判断到底是他们的软件有问题还是公司的网络有问题。结果完全凭经验不凭数据，进来就是服务器 io 不行，io ？网线超过 60 米有损耗？三层交换多 vlan 有性能问题。实际上 mssql 查询返回结果能几百 kb ，最多也就产品图片 4MB/s 。
这种状态玻璃心做怪，能花钱解决的事情花钱去呗，我给他省什么钱。买新服务器+新 ap+大量布点，越是会忽悠越是会花钱，爱情的天秤理论谁付出的多，谁心才流血。
说到底是谁做事的问题，这是来工作量啊！开会的时候说话简单，做事的人才知道难度在哪里，特别是那种三天两头翻来覆去做的事情。建议还是先了解事情要怎么做，再争论。
挺漂亮的要内容有内容要配色有配色。还以为真正的 txt 上线，那真的是 abc+那种什么图，在 txt 里还能如何表现。
我们公司就
erx(openwrt)+huawei s5720s li 52p pwr(所谓的弱三层 vlan+acl 控制功能蛮多的，华为的东西就是文档齐全看文档都会了+固件更新勤快当前的都更新 33 个补丁了，上面还有两个大版本更新。。。)+uap ac(openwrt)
网络结构越简单越好，网管交换机也有助于发现网络异常。
看来你们的经验都是一种理想化的，可能从来没经历过因为电而导致的硬盘挂，重则整盘挂，轻则单分区出现坏道。是不是另年头 SSD 都不坏了，我竟然建议财务购买机械硬盘。。。这时候该如何分辩什么区域有坏道。
方便，不要跟方便难过，正常的装系统 2 小时至少。。。高重要的电脑都要经历系统备份再重装，是备份在硬盘的其它分区快，还是网络磁盘，还是不可靠的移动硬盘。
这么多年，习惯了 系统分区+QQ 这种需要备份的软件安装分区+第三分区，至少也要双分区。一个作为另外一个的备份分区。
做在交换机的 vlan 流控(仅仅只是个限速)和在路由上行方向的流控效果是不一样的，openwrt 的 CONNMARK 可以将上行标记带到下行流量。而且按照 tcp 握手过程，更早出去的上行流量也带来了更早的下行流量。
也许可以尝试一下 openwrt 里的 qos-scripts 。
这是 QOS 的话题。
描述中的什么设备能做到两个直播间能平均使用，不相互影响。指的是使用 200M/180M 这根宽带?
没玩过直播，不知道并发数是直接来源于入口，还是反向到相应的平台。
对于 QOS 来说,市面上宣传有这功能的有 ros/爱快 /高恪,但是 QOS 的优先级实现是非常有针对性的配置,也许得找人家帮你配置好.
用 180M 来保障 2 台电脑+4 个手机的上行+120 台电脑,我觉得是小菜一碟.
对于 openwrt htb 算法来说
1.它的 class 可以用来将大水管分成各种小水管,并且通过 ceil 来限制上限
2.它有 prio 优先级,可以保障 6 个终端的 IP 高优先级出列,或者更精确的服务端口.
3.然后就是如何理解通过的流量饱合程度造成的延迟变化,当时是按照 ADSL 线路 60%的流量低延迟,80%延迟可以接受.来相应的设定 rate 保障值
#$TC class add dev $UDEV parent 1:1 classid 1:2 htb rate $((UPLINK*8/10))kbps ceil $((UPLINK*9/10))kbps
#$TC class add dev $UDEV parent 1:1 classid 1:10 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 0
#$TC class add dev $UDEV parent 1:1 classid 1:20 htb quantum 1514 rate $((UPLINK*1/10))kbps ceil $((UPLINK))kbps prio 2
#$TC class add dev $UDEV parent 1:2 classid 1:30 htb quantum 1514 rate $((UPLINK*3/100))kbps ceil $((UPLINK*90/100))kbps prio 3
#$TC class add dev $UDEV parent 1:2 classid 1:40 htb quantum 1514 rate $((UPLINK*5/100))kbps ceil $((UPLINK*85/100))kbps prio 4
类似这种基于 ip 的优先级实现.QOS 通过对各种小水管通过的流量饱合程度来解决延迟问题.它在同样的一个带宽可以造成高优先级 19ms,低优先级接近 600ms 的延迟.
以下只是一个示例,现在不用这种基于 ip 的实现,对于 iptables 来说规则越多越耗 cpu,性能也相应的变低.
#!/bin/sh
iptables -t mangle -F POSTROUTING
tc qdisc del dev br0 root 2> /dev/null > /dev/null
tc qdisc add dev br0 root handle 1: htb default 119
tc class add dev br0 parent 1: classid 1:1 htb rate $((3072))kbps
tc class add dev br0 parent 1:1 classid 1:2 htb rate $((3072*6/10))kbps ceil $((3072*6/10))kbps
IP=101;while [ $IP -le 125 ];do
tc class add dev br0 parent 1:2 classid 1:$IP htb rate $((3072*1/10))kbps ceil $((3072*1/4))kbps prio 4
tc qdisc add dev br0 parent 1:$IP handle $IP: sfq perturb 10
tc filter add dev br0 parent 1: prio 20 protocol ip handle $IP fw flowid 1:$IP
iptables -t mangle -A POSTROUTING -d 192.168.8.$IP -j MARK --set-mark $IP
iptables -t mangle -A POSTROUTING -d 192.168.8.$IP -j RETURN;let "IP+=1";done
tc class add dev br0 parent 1:1 classid 1:3 htb rate $((3072*5/10))kbps ceil $((3072*10/10))kbps prio 0
tc qdisc add dev br0 parent 1:3 handle 3: sfq perturb 10
tc filter add dev br0 parent 1: prio 10 protocol ip handle 3 fw flowid 1:3
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j RETURN
iptables -t mangle -I POSTROUTING -m iprange --dst-range 192.168.8.200-192.168.8.205 -j MARK --set-mark 3
职场还是个非常复杂的地方，年初就将朋友圈对公司所有的同事关闭。
曾经就因为在朋友圈说公司被老板约谈 2 次。。。语言这种东西不同人理解起来，处于不同位置都会听起来有严重歧义。
今天老板又赞扬了一下，上星期也赞扬了一下，其实有时候明明自己挺爱公司的怎么听到他的说话怪怪的。比如今年比去年有更好的改变，也不是忽攸你之类的。哈哈，我们老板还算开明，什么话都敢说。但有时候听着听着我也觉得像套路。所以朋友圈这种地方真不应该对同事开放。有时候开会的时候都不知道为什么才说一句话，突然被大批一通，就是长期被人告密造成的。。。不得不说有些人的存在看起来没什么能力，脏事坏事她都干了，连带办公室说话风吹草动也传到老板那。。。她们就是这样存在的，大内密探。
然后发的牢骚就一丁一点被积累，说一句话就感觉不知道为啥被批一通。。。职场啊。干的不爽就炒了老板。。。
Select Language