@tongbufu 价格这么实惠，是哪个运营商？

@roundgis 啊哈，英式楼层编号方式，地面是第 0 层

在服务器那边用命令 journalctl -u ssh 看看对应时段的报错是什么，这样应该更容易排查

Gitee 连自家都屏蔽：
/t/956169

更何况是普通用户呢

或许下次出现同样情况时，可以顺手做个 ping 、tcping 、dig （或者 nslookup ），然后对比着看看有什么不同

举个夸张点的例子，可能就容易明白多了

在公司的工作电脑利用 SSH + rsync 往生产环境服务器传错文件，1 分钟后发现大事不好立马恢复回去，但已经造成经济损失，公司想要追责，能不能查出是谁在何时覆盖了什么版本的文件？
已知工作电脑和生产环境服务器都有监控软件

答案是：当然可以，监控软件直接就记录在案了呢

然后，想要把锅推给“传输过程中有可能被破解了，有可能以前传文件的时候被人破解了文件名和文件内容，现在再次传输的时候遭到篡改”，想一想就明白不可能：
1 、只要密钥不泄露，SSH 加密传输本身就没法破解（现阶段的情况下，不谈以后量子计算机时代）
2 、若真的遭到篡改，比如 SSH 密钥变更，那么监控软件也能记录下来，除非干这事的就是网管本人，或者入侵者顺手删了或篡改了监控日志
3 、如果真有入侵者，那就说明出现了密钥泄露之类的高危事件，并且泄露的正好就包括了该员工的 credential 。

显然，就算想推卸责任，该员工仍然逃不过安全检查，其他人也需要进入 security 排查过程，因为这是人为错误，并不是工具本身有安全风险。

wifi 连接出现连通性故障的时候，realme 有可能用了手机数据连出去，所以 realme 手机需要关掉移动数据时再测才稳妥
iQOO 不清楚会不会这样

我自己用 Windows 11 + VS2022 试了下，没法复现错误，最终输出是 1
在 FreeBSD 14 + Clang 16 试了下，也是没问题，最终输出还是 1
Linux 就不试了，前面已经有人测试过

个人建议，不要死磕 CLion 控制台，而是改用常规环境。
鬼知道 CLion and/or 它自带的 MinGW 是不是有 bug 。

尤其像这次，正常命令行环境运行测试程序没任何问题，CLion 控制台一用就出错，那只能是 CLion 的锅。

至于常规环境，例如：
Windows: MSVC 最新版，直接用 Visual Studio 即可
Linux: 编译器 GCC 或 Clang 均可，IDE 随意
BSD: 编译器用系统自带的，IDE 随意
macOS: Apple Clang

尤其是 Windows ，用 Visual Studio 反倒最稳妥

还有第 12 行也是一样

建议好好检查下空格状况

第九行那个 scanf ，双引号内有个空格，但你原贴给出的代码，这一行的双引号内没空格

@37Y37 哈哈，现在我觉得，似乎随手写的 demo 比起认真写的正式项目更有可能受到认可

如果无法忍受 hyper-v 的性能损失（对于玩游戏有不良影响），那么正确的做法不是换 Mac （ Docker 启动都要好几秒），而是专门用一台电脑运行 Linux 。

我也不喜欢在 Windows 客户版系统开启 Hyper-V ，也不是很喜欢在 Windows 安装虚拟机（多出 N 个虚拟网卡，很不爽），所以最后还是装了一台非 Windows 、非 MAC 的电脑

等等，为什么要用 new 直接创建呢？最后还得手动 delete 。
不如用 std::vector 或者 std::make_unique<char[]>(数据长度)
这两个好多了

std::vector 已经有人发了，那么 make_unique 的用法是：

size_t data_size{2701131776};
std::unique_ptr<char[]> raw_data_ptr = std::make_unique<char[]>(data_size);
char* raw_data = raw_data_ptr.get();

在我的 Windows 11 + VS2022 测了下，很成功，没任何报错。

另外呢，直接用 malloc 、new 创建的空间，按照 C 语言留下来的“惯例”，是需要手动初始化的。
通常会用 memset 初始化为零，用 std::fill 也可以。

如果改用 std::vector 或者 std::make_unique ，就可以跳过这一步，它们都会自动初始化。

@amorphobia 这么大的 VLA ，存在爆栈的可能性吧（视乎编译器做法而定）

“隐式声明与实际调用的时候参数对不上”

不是对不上，而是因为 C 语言的特性。

在其它编程语言当中（比如 C++、Java 、C# ），int system()；表示该函数不接受参数传入。

但 C 语言不同，int system(); 表示参数情况未知，是个笼统的声明。
而 int system(void) 才是其它编程语言 int system()；的意思。

这里有比较详细的说明，在页面尾部 Note 那一节，句子以“Unlike in C++”开头：
https://en.cppreference.com/w/c/language/function_declaration

京东 PCDN 暂时收起来没坏处，如果电信的人上来，就把今天 PT 的记录给他们看，这样他们应该就能交差了，宽带也不会被封停

@basncy
双倍发包有效，那就可以庆幸当地运营商做的并不是很长时间的阻断，而是几秒钟的阻断，或者几秒内的超高丢包。双倍发包在这种情况下才能够起效，使得重传机制能够回到可接受的等待时间。

至于 KCPTube ，像这种立马就新建连接的情况，应该就是没配置 mux_tunnel 参数的缘故。使用了 mux_tunnel 后就会自动建立多条 UDP 连接，共享使用，这样就不会再观察到每接受一个连接就自动建立一个新连接。好处是，可以降低延迟；坏处就是一条路受阻，同路承载的各个 session 就会感知到受阻（这就是去年困扰我情况）


顺便多说一个有关 KCP 的“冗余”发包。
所有的可靠 UDP 拥有重传机制，KCP 也不例外。KCP 特别之处在于，它会在规定时间内收不到确认号的情况下就直接发送重传包，而这个规定时间非常短，短到只有“去程+回程”的总时间，若收不到，那就在（去程+回程）×1.5 的时间后重新来一次。而网络抖动总会造成去程、回程的时间有所浮动，于是就造成第一个重传包经常“过早”就发了出去，第二个重传包也很容易就发了出去。但 KCP 并不会主动地在去程+回程总时间未到的情况下就事先发包

这就是大家说的“冗余包耗费额外流量”的来由，奇怪的是各个 KCP 代码使用者其实是可以观察到这一点的，但没人讲出来，依然还在笼统地用着“浪费 10%-20%”这种模糊的说法，以及“狂发冗余包”这样的印象。其实极端起来 KCP 是可以浪费 25%-40%的（大多数转发工具制作者不至于用到这么极端的配置参数），也可以把浪费降低到 10%以内（抗丢包能力相对没那么好）

@basncy
请先搞清楚这两件事：丢包、阻断
这两个的程度区别很大的

UDP 出现丢包很正常，所以才会有那么多协议和算法给 UDP 做可靠传输，也因此你认为我”认为跨国 udp 不会丢包“完全不成立。如果我认为跨国 UDP 不会丢包，直接用 raw UDP 就行了，根本不可能使用、制作兜底工具。

阻断（某段时间内 100%丢包）就严重得多，连都连不上。

这不是发不发冗余包的问题，而是重传机制也无能为力的问题。划重点，重传机制，发生丢包了就必须重传，阻断的情况下无论怎么重传都没用。能够做的要么继续等，要么跳跃前事先探测，免得选中受阻端口。


然后是谁跟你说的“kcp 是每条 tcp session 独享一条 udp 连接”？
须知道，是否每条 TCP session 独享一条 UDP 连接，那是 kcp 代码使用者说了算。KCP 代码本身并没有限死必须一条 TCP 对应一条 UDP 。
在本例当中，我是多条 TCP session 共享个位数的 UDP 连接，并不是一对一独享。
KCPTube 既可以每条 TCP session 独享一条 UDP 连接，也可以多条 TCP session 共享同一条 UDP 连接，我并未限定必须一对一。

@wangyucn 本质上没什么区别，如果说有区别，那就是心跳检测提前做
普通的心跳检测：只负责当前链路。
跳跃前事先检查：利用心跳检测提前测试下一个链路（端口）。
换个说法就是，跳跃前来一个 handshake ，成功了再转移。

至于“中间负责 UDP NAT 的设备 allocate 新端口处理不过来”，在我的家宽应该不是这样，我家软路由已经获取到双栈公网 IP ，发起测试的机器就是软路由本身，不需要 NAT 。而且，无论 IPv4 还是 IPv6 都有同样的现象。

中间某设备或许跟不上，也有可能是“反向墙”的轻微版，因为最重要的一点是，国内连接完全不受影响。

这个黑盒子实在猜不透，以往不少人的研究认为，中间那堆设备是旁路机器，但能够实施 UDP 阻断（或时间段丢包）的只能是直连设备。再结合其他人对于 UDP 的 QoS 帖子，实在搞不清楚到底是运营商主动而为还是某设备给直连设施发指令