@systemcall 没啥用，就明天把境外互联网掐掉，大陆变成互联网孤岛，照样有人互相攻击。Mozi BotNet 至少前年开发者就被抓了，去年年底国内活跃终端数约 1.5W ，占比 50% 。很多僵尸网络是传染模式，设备替换的速度远远跟不上中招的速度。

@onice 是的，重要的是做好防护。别人开门门口放安检机，内部还有人监视，屋里面值钱的东西都锁起来。作死的门缝一看就是金银财宝，门推一下就开了，肯定完蛋啊。

@EdmondGUO 定期更新的白设备相对好一点，如果信心不足或者是黑群晖建议还是外面套一层 VPN ，先连 VPN 再连群晖会安全点。

@laozhoubuluo 更正一下 M2 数据，三月末最新是 281.46 万亿 ，2022 年末全国人口 14 亿 1175 万，所以人均 M2 应该为 199369 元。好像之前的数据少了一个数量级，我说怎么怎么算都不对。不过不影响结论。

因为有时候会通过 XFF 等第三方头透传内网 IP 导致出问题，最省事的改法应该是去掉 HTTP_CF_CONNECTING_IP 可以覆盖 REMOTE_ADDR 的逻辑，只信任底层上报的 IP 地址即 REMOTE_ADDR 。

前几年没和运营商合作的高星酒店基本上就这个模式，流服务器一般是基于 tvheadend 的定制方案或者厂家基于 ffmpeg 等自己开发的。现在求新一点的就是把交换机+网线换成 OLT+ONU+ODN 了，顺便把酒店内各个专网整合到 OLT 上了。
技术上没啥问题，唯一一点就是酒店大概率不会被查（但也不完全合法，所以现在很多都是直接加钱和运营商合作来搞），但您做大一点被举报、被查的风险就很高。几个熟人住一栋楼内部搞一搞只要都不说现在没啥风险，做大了还收钱那出任何问题都可能会被威胁举报甚至直接被举报。

@tool2d 没啥用，企业用 IP 更惊人。一个低级别专线分配 /30 ，四个 IP 只有一个被真正用，剩下的都是开销。搞这个不如搞新增少于 /24 的专线全部基于区域分配大网段，一个区域的用户共享一个网关。一个地址收 100 还要求很贵的套餐主要是因为一个地方一般只有一个运营商能给提供此类服务（当地移动专线太贵，加完钱还是比移动专线便宜），跟即使是非低价旅游团仍然强迫购物本质上没啥区别。

@yolee599 不一定，很多专网实际上是不允许和互联网互通的，因此随着网络规模增大于是所有的 ABC 类地址都被用作接入设备了。专网内看到一个美国国防部地址实际上不是指向美国国防部而是指向某个省的一个设备很正常。

@xxfye 绝大部分国内运营商没有提供给 CGN 用户映射公网端口的机制。其实要是能打通到 CGN 的 UPNP + 一定数量的固定端口分配和宽松的连接数限制（例如 10000 连接数 + 100 个映射端口）也能满足比较折腾的人的需求。

@my2492 云、专线之类的都是吃地址大户，既然家宽那边有地址肯定尽量从家宽拿，毕竟除了几块 CGN 单板之外没成本。

不光要谈总量，还要谈分配啊。中国 M2 最新数据是 273.81 万亿，人均 1955785 元，为啥很多人连一万块钱都掏不出来呢？
开一条专线默认一个 /30 ，实际上就一个 IP 可以用，剩下三个根据 IP 协议就浪费了。
有业务默认买一段 IP ，实际上肯定是按照后续几年甚至十几年规划的，因为 IP 的成本远低于来回折腾的成本。
改内网也要投入各种资源，CGN 设备之类的也要钱。如果预期用不了几年那还不如继续维持现有机制。
十块钱一个月的宽带确实很难提供公网 IP ，因为连公网 IP 最低售价都很难涵盖。一百一个月的宽带不给也确实不合理，价格已经能覆盖成本了，当然毕竟国内运营商行业竞争有限所以才能出来高套餐还得加高价才能获取公网 IP 的政策（一个公网 IP 正常售价也就是 10-20 元，换言之北京移动那个价格算正常价格，100 以上纯属抢钱）

有的设备会通过硬件协助转发，需要通过专有命令控制甚至就不太能控制。
建议直接桥接之后挂自己路由器。

1. 建议还是改了，毕竟有单独的路由器。一般来说少 NAT 几次肯定是好事，而且本版用户一般的路由器肯定比光猫 NAT 好，配置更灵活。比如之前我测试华为某个光猫写静态路由指向 LAN 侧地址看着生效了实际不生效。
2. 端口映射或者开个 VPN 拨号进来。前者方便开销小，后者安全性高不少。看业务安全性决定。
3. 正常思路是非标端口。不过现在有个 Alt-Svc ，配合境外低速主机可以利用一下加速资源加载。

@MagmaBlock 光猫确实存在 NAT 性能不好导致连接数多了就卡问题。近几年的新光猫性能强还带 NAT 加速会缓解不少，不过十个人一起用的话还真不好说。

@luomao 算不到钱可以算（开发 /测试 /产品）人天，懂的管理人员能自动换算成钱，但是数据没有换成钱直观好看就是了。
核心是让管理人员看到技术改造投资物超所值，毕竟即使您直属领导能看懂技术价值，但再往上走很多领导不一定有这么敏锐的技术视角能把技术价值直接转换成业务价值，这就需要您在述职报告里面帮他转换一下，不管是省钱还是省人天。

不少部级别的网络都没有卫星授时 NTP ，这个确实现在对于客户甚至机房运维来说比较新鲜，毕竟很多外包运维都不太挣钱且加班很猛，这种运维就不要对他们有太高的技术要求了。遇上这种只能是有互联网的配置互联网 NTP ，接不了的就指向交换机追求相对一致性或者索性自生自灭了。

不过递归 DNS 设备采购成本不高，UPS 电池反倒是贵不少。这两个不搞只能理解为机房运维销售不会运作或者客户除了维保费一分钱不愿意多掏了。

做业务+技术路线也是个发展路线，不过我理解这句话意思应该是在汇报里面体现业务价值，例如如下修改。

1. 通过建设开放平台，实现内部开发对接流程均在开发平台实现，使得开发间提高沟通效率且对接方式有据可查。本平台上线至今已经实现 XXX 个需求全线上对接，上线后需求上线周期平均缩短 X 天（ XX %），根据团队平均时薪 XXX 元计算上线至今已节约成本 XXX 万元，预计随着开发进一步熟悉开放平台，预计 2023 年度需求上线周期平均较 2022 年平台上线前缩短 X 天（ XX %），每年可节省成本 XXXX 万元。
2. 通过实现 K8S 平台云原生改造，增加平台承载力，推进 DevOps 建设。当前云原生版本相较于原有单体版本资源占用下降 XX% ，承载峰值流量能力上升 XX%，同时支持动态扩缩容可以根据当前业务情况动态增减，从而避免手工预测流量的不准确性，降低公有云采购成本 XX%。通过 K8S 改造实现部署环境与开发环境完全一致，进一步加强开发自测有效性，实现测试团队发现 Bug 率降低 X% ，根据历史数据推算可降低因 Bug 带来的经济损失 XX 万元。同时由于开发自测的有效性，因此测试团队本年度无需根据需求数量增长而新增测试人员，可进一步降低人员成本 XX 万元。

如果上述数据大多数都比较好看，都写到晋级述职里面，那绝对不会被批 "没有呈现业务价值" 。
如果上述绝大多数的数据都 <= 0 ，那么在目前的经济形势下就不是考虑公司业务发展的问题了，那就是考虑下家怎么找的问题了。

不知道是国际统一的标准化版本，还是之前上海电信测试的溯源版本。
前者喜大普奔，后者限制有点大了。

这个主要看互联网大厂对 HTTP/3 的推进，毕竟如果大家都换 HTTP/3 完了相关业务流量都被不合理的 QoS 策略卡掉那投诉率要上天，所以在快速更换 HTTP/3 的前提下运营商迫于投诉压力可能能调整一些比较极端的限制另外进一步推进扩容降低 QoS 概率。
当然能做到的最好结果也就是临近省份内部互通近似于 TCP 水平，境内互通不会遭受极端 QoS 策略例如流量稍大一点直接完蛋。至于境内完全达到 TCP 水平甚至国际层面有什么改善纯属想太多。

1. COBOL 在国内几乎只有银行还在用而且没有新应用，既有应用也在慢慢的被 Java 等语言重写，而且 COBOL 的底层环境也不符合国产化要求，没有企业会去投入一个注定没有未来的项目。
2. COBOL 的系统想求稳的基本上不会接受国产化改造这种有很大业务运行风险的改造，能接受的业务大概率也能接受重新招标一套新系统替换或者用 Java 重写的方案。
3. 即使 1 和 2 都不是问题，想找同时懂 COBOL 和云数据库的可能都不是钱的问题，是找得到找不到一个团队的问题。

@TerranceL 是的，管理和沟通成本高到超出了对于不少人可行的 "父母家宽带提速+设置备份集群" 的模式了，甚至前者还可以给父母提供些点播片源和数据备份服务之类的。
另外几百 GB 数据加密成本都够一壶，更别提加密（除流算法之外）导致文件体积上涨的问题了。

可以这么想，要开发一套操作系统出来基本上就是投钱的问题，投十个亿给靠谱团队做一套完整的图形化操作系统没啥问题，只是还得花几倍几倍的钱投入生态，毕竟信创搞了这么些年，从用户来看生态还是远远不如 Windows 的。
但是 CPU 嘛，设计制造的坎就要多的多了，从底层的材料科学到上层的所谓光刻机，这些肯定不是百亿量级能解决的问题了。

@edis0n0 要考虑个问题，Linux 的驱动优化不一定比 Windows 好，更别提有些好的驱动因为 License 问题无法打包进 Linux 的问题。

@sadfQED2 理论来说可以基于传输数据量大小吧，网游的数据包数量和占用带宽和视频业务完全不是一个级别。

@Damn 希望以后 HTTP/3 推广能解决对 UDP 的不合理 QoS 吧，现在有些大厂的应用已经支持 HTTP/3 了。

重启 Apache 一般也就是十秒左右，对于虚拟主机来说用户感知很小，也就是网页卡了刷一下就恢复了。
想解决一直点的话限制个次数和时间完全可以解决，比如一台服务器五分钟之内只能重启一次，一个用户一个小时之内只能重启三次这样。

最不费脑子的就是买两台交换机，完了和光猫在一起的交换机单独起一个 IPTV 的 VLAN ，剩下的互联网口起另一个 VLAN ，完了到 IPTV 房间的交换机做一个 Trunk ，另一台交换机配置相同。
这样移动 IPTV 机顶盒的时候同时移动交换机，完了软件上变更和光猫交换机的 TRUNK 口到使用 IPTV 那个屋子的接口就行（如果懒的改配置可以无力调整线路，一样）。