谁说要两个股东才能注册的

了解下： 一人有限责任公司
非个体户和个人独资企业

《中华人民共和国公司法》第五十七条规定：“本法所称一人有限责任公司，是指只有一个自然人股东或者一个法人股东的有限责任公司。”

都写几年 c++了，修炼点内功心法，你现在要提高就系统的体系的看书，而不是看各种教程。
经典那几本书撸一遍吧，看你兴趣在哪块选择自己感兴趣的看起来，计算机原理，数据，架构，网络，设计，然后再付诸实践理解为什么这样设计。

当然逆向学习，从优秀代码阅读，反思，举一反三，在落实实践也可以，效率会比上面高，但是理解并不一定透彻。

如果 c++要成为高手，只能成为时间的朋友了，很多坑没写个三五六七八年是遇不到的，也淌不过去的。我一般选择 c 或者 rust 。

@vsyf 你的理解大致没错 不过有些细节：
1. rdp 如果应用在云桌面，是个很好的方案，因为画面变动少，可以获得很好的画质。 但是游戏、视频这类一秒变动 24fps/60fps 的在使用 rdp 就会延迟明显卡顿，换句话说就不丝滑了
- 如果传输裸图像，那么带宽会巨高，而且裸图像传输时间也很长
- 如果传输压缩的图像（比如 mjpeg ） 涉及到 cpu 编码，cpu 编码+传输延迟太高，如果选择硬件加速，那得各种微调
- 云桌面一般首先会设计 buffer 保证画面质量和避免撕裂等抵消网络波动，鼠标点击类，文字类操作超过 200ms 也不是特别影响

2. 如果使用 264 ，那就玩的花了，首先有现成的硬件电路可以提供支持，Intel/nvidia/amd 都有独立的硬件管线，其次如果 windows 从抓帧 dx11 ，dxgi 等 api 也是从 gpu 走的，理论上可以显存->电路不出 gpu 完成 264encode ，再其次，P 帧就是差异帧，在不变化的时候帧很小，变相也节省了延迟,低变化甚至比显示器延迟更低 @cheng6563

@houzhenghong 一般这类实现都是 infinite GOP

在正常情况下只有第一帧 I 帧后面全是 P 帧

@zsxzy 表述可能有问题，应该叫无限 GOP, 相关参数 以 nvidia 举例子 NVENC_INFINITE_GOPLENGTH

RDP 是云桌面
串流是云游戏

侧重不同，你细品

云桌面追求的是画质，客户端渲染，画质接近 native ，清晰可见 缺点是输入延迟较高，适合网页，办公等

串流一般是云游戏，低、极低延迟，讲究操作跟手，一般采用全硬件加速编解码（包括硬件色彩转换），典型有采用 264 265 + udp 这种，极限情况下延迟可以做到 20ms （ native 都有 10ms 延迟包括显示器）， 缺点是画质比较低可能受网络波动影响，所以会采用无 I 帧无 B 帧 全 P 帧这种 + DRC （动态分辨率） 在保证延迟的前提下画质可能损失

撇开技术，时间和精力也是很重要的资源。 最优平衡是：把钱花到自己能承担的且不受影响的最高，以换取时间和精力的平衡性。
如果是我：
1. 服务器+企业级硬盘（ SAS ）+raid10
2. 买 NAS ，一体式 nas 的最大优势是省钱省时间省精力。
3. 存算分离，纯 nas 为啥要存算分离？ 普通 nas+docker 可以满足较多低敏感业务，如果是要高性能可靠性的计算存储分离： 买存储服务器+HBA/SAN
4. 建议提升单盘容量的方法： 一步到位买大点。

数据无价，这个有两方面的解读：
1. 当你数据丢失后你发现，数据也没有那么重要
2. 当你数据丢失后，你发现数据太 tm 重要了

如果是 2 ，该花的钱还是得花，要不然企业花冤大头的钱买 SAS 干啥？

cpu 约等于阉割。

>vmwre 可以直原生接拉 k8s 并具备虚拟化的 cni,需要了解 NSX ，DRS ，VMotion 等相关层，对基本原理和相关技能要求很高。
https://docs.vmware.com/tw/VMware-vSphere/8.0/rn/vmware-vsphere-with-tanzu-80-release-notes/index.html


>容器化部署和二进制部署，是不是二进制部署会更加可靠
我认为是的，套娃只会增加不可靠性，取决于你是玩还是生产，生产建议 3master 以上+二进制，私有云方面见过阿里云小飞天（非完整），ack 相关套件 master 那几个核心组件也是二进制部署的

看 op 似乎是非大规模生产集群
kubeadm 一把梭，不管是升级，改配置，更新证书都方便。

@fan88
完全通过稳定可靠的物理线路，花费几乎是数万每月，除了商用基本没可能。
完全通过技术，不花钱靠着各种神仙技巧在千军万马过独木桥中从普通出口获得优势，这也行不通，获得的几乎是暴力 qos ，而且也不安全。

其实最完美的方案 @wangyucn 大神在 #12 已经给出来了：
1. 选一条尚可的线路：比如 iplc nat ，通过 udp2raw 套上 faketcp ，抵抗 isp 的 qos ，然后再套上 udpspeeder 通过 fec 基本可以抵消高峰时间跳 ping 丢包，高峰期的简单 qos 同时在高峰期共享带宽不足抢带宽上获得优势，基本就已经达到了完美的效果，非常平衡，而且可以根据线路优化参数获得更好的延迟/带宽/流量消耗。

我之前的方案是：某影机场 vip5+proxy-chain 落地机，兼顾安全性和链路性能，但是代价是延迟高，稳定性也不能保障，即使是很贵的机场也总有不稳定的情况

@wangyucn 不知道理解对不对
按照出口带宽的现象推测：普通 ip 标准出口的带宽资源是有限的，除了 vip 线路其他共享一个带宽池，在超售带宽的前提下选择性丢包。 hy2 这类的拥塞协议应该是通过多倍发包策略获得更多机会也别再大流量下有更好的表现

udp qos 或者掐断应该是面向墙内一些 isp 自己的策略，推测是防止 udp 反射之类的 ddos 流量

套壳大概总结：
1. 选个稳定线路，通过 faketcp 避免 udp qos
2. 选个不稳定线路通过 udp over quic 等自带拥协议的用激进流控策略获得低延迟+大流量稳定性。

@wangyucn #6 感谢大神，听上去最佳时间似乎是：
找个 cn2gie/9939/iplc 的跳板，然后用 udp2raw faketcp/auth-none/cipe-none 用来避免 isp 的 qos

如果直连 faketcp 普通 ip 走 chinanet 即使是 tcp 还有通常无差别暴力丢包，和 tcp qos

@MFWT 求教 wg 流量如何套在 ss 中？ 大部分机场没有 udp 线路？

@davin 同求个 感谢 eHlqa3h6QGdtYWlsLmNvbQ==

有了 chatgpt 后转语言难度直线下跌。

不管是 c++还是 rust ，不懂就看看源码
多写，多趟几个坑，就熟悉了。

前提还是基本功打好。

今年的 m3 pro 被阉割过了
内存位宽疑似阉割至 64bit （通道总带宽 150G ） m2 pro 200G
且核架构是 m3 标准版的架构

这代 m3 得买 max 64G ， 否则 m1 max / m2 max

就是因为经常有人讨论，加 const 是不是最佳实践
才会出现 rust 这种完全不信任程序员的语言。。。

@Evovil 看错题目了 ，你说的是 k8s-egress ？