datocp

自从财务人员变成拥有 1%股权，包括给了那些员工股权，竟然遇到我还提起省成本问题。。。
有次老板说起财务人员有多为公司着想，作为员工，有啥感受。只觉得社保按最低档。。。
合同早就按基本工资了，然后加班竟然是按基本工资算的，我不加班的原因是加班了和平时差不多。。。有些岗位人员就会倒逼公司加班按全额计算，招不到人公司也顺从不同人的要求。当然到了辞退，那就是白纸黑字了。。。

制造业因为卷，
2 年前开始 3 班倒，
慢慢的有些岗位开始变性，就是从之前 17 点下班，变成 19 点，给是给加班费了，有些 20 点。
今年开始清除普工因为照顾孩子，只能 17 点下班。

卷起来以后，很多规则会变的，所以我也不喜欢卷王，特别有些干脆就是在那等加班费的，老板都不心疼，关我屁事。制造业就那点钱，想卷的人多的是。但是清除那批 17 点的，你觉得以后是什么场景 ？

好公司又休假又有工资才算，现在的除了法定假不上班不给钱。。。

这些年客户都是连带保密合同，至于这个保密到什么层次。不像人家大厂可能看了一眼柜子，就有人透过监控约谈了。

所谓的公司核心机密到底是啥，上了飞书，方便是方便，是否符合客户保密要求不得而知。很多商业信息没做张冠李戴就飞书了，昨天看人家老板是亚洲首富，多少商业信息就被 AI 搜集了。

自己搞传统存储的特点，人家嫌弃不能在线编辑，至于方便和保密安全，哪个重要，鬼知道！！！

最近买了个磊科 N60 pro 都半个月了，还没试着换掉 erx ，大部分 iptables/ipset 也已经转换完闭。

没有千兆，没有双线怎么说这事。搜索 openwrt qos ，老是推荐 sqm 。这玩意早些年测试的时候之所以垃圾，局域网没法生成 dscp 标记没法分流，更为可怕的是它那超级垃圾的每包匹配非常耗 cpu 资源。学习了 tomato connmark save restore 结构，实现的就是包标记到连接标记的转换，非常节约 cpu 资源。

描述的另外一个问题就是单线 pppoe 基于 tun 这种耗 cpu 能否跑满千兆，之前测试的时候 mtk7621 在 br-wan 接口也是轻松带 qos 跑满千兆。嘿嘿，这么多年了公司还在用 100mbps 移动专线。。。

这种只能自己学习 qos 标记/双线标记是否耗 cpu 资源，因为 cpu 被耗导致呑吐能力下降。如果没有这方面的知识，那只能买性能更好的 cpu ，靠 cpu 堆呑吐性能。

应该优先测试 iptables limit+tcp-reset ，这个基本是秒级的断开连接回应。平时会这样给内网丢包。

-A BLOCK_CHECK -p tcp -j REJECT --reject-with tcp-reset
-A BLOCK_CHECK -j REJECT --reject-with icmp-net-unreachable

AI 了一下，认为是上传方向 syn tcp 重传导致的并发数暴涨。

解决方案包括设定，这些参数得小心测试，当年将一个参数有 65 降为 60 就影响 ios 的在线更新。

# 1. 扩大连接跟踪表上限，防止表满断网
sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_buckets=131072

# 2. 极致缩短建立连接和关闭连接的超时时间（单位：秒）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_sent=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_syn_recv=10
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=15
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=15

# 3. 大幅缩短正常通行的 TCP 连接在无流量时的存活时间（默认 5 天，改为 10 分钟）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600

# 4. 优化 TCP Keepalive 保活探测，死连接快速释放
sysctl -w net.ipv4.tcp_keepalive_time=180
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=3

进行上传方向 syn 限制，limit 这个模块还是非常温和的，不会是那种断开的感觉

# 全局限制转发的 TCP SYN 并发速率
iptables -I FORWARD -p tcp --syn -m limit --limit 150/s --limit-burst 200 -j ACCEPT
# 超额的直接通过 tcp-reset 熔断，强制客户端释放连接
iptables -I FORWARD -p tcp --syn -j REJECT --reject-with tcp-reset

清空，从来没试过，也没必要
# 1. 假设丢包在晚上发生，在丢包期间的 20:30, 21:30, 22:30 分别暴力清空一次连接跟踪表
30 20,21,22 * * * conntrack -F

# 2. 在丢包预计结束的时间点（例如 23:05 ），彻底清空一次连接表，让网络瞬间满血复活
5 23 * * * conntrack -F


看起来对于 openwrt ，这些方法都是可以应用的。

600 秒。。。

有点看不懂入站还是出站，
不是限制速度而是丢弃?

一般对于 openwrt 来说。connmark 表会受 tcp/udp 消亡时间影响，目前自己设置的网络最高的一个是 600ms 。这些会导致并发数不断的累积，直到触碰到它的上限。这个上限，比如 256MB 的 erx 刚刚这个月从 16384 改为 32768 。这是路由硬件的限制，据说受制于内存。至于触碰到 ISP 的上限，那还是使用 4/8M ADSL 时。

网络不通确实会导致一些异常问题，比如内网一些 PLC 设备连接外部的 auth 网站，给它网络它的并发下降到 20 以内。不给它网络全部发起的是 dns 查询，竟然每 ip 高达 1400+查询并发出现在主路由 connmark 表上。最后只能在接入交换机上屏蔽。

即然你已经发现了，不同地级的人根本没有权限问这个问题。只能投诉，有用嘛?一般不会这么不聪明，有流量刚好匹配这个策略，会导致网络 100%丢包，这不是给自己找投诉。