还有第 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 帖子，实在搞不清楚到底是运营商主动而为还是某设备给直连设施发指令

@hello2023 真是抱歉，上传错版本了，现在已经把正确的文件传到了 Github

现在有 chatgpt ，翻译起来容易多了

至于哪个语言用作主要语言，视乎受众而定，主要面对华人就用中文然后附近英文文档链接，要不然就英文文档附加中文版链接

要是懂其他语言，比如日语、韩语，也可以一起写上

@diangongnan 可能触发了反向墙（详情在另一个帖子回复了），不少人在 BT 下载时也会遇到这种事，这就远比 QoS 烦得多

@diangongnan 4K 视频 + 10 秒换端口，在运营商那边来看的话，很可能就是短时间内大流量+出现大量连接，触发的不仅仅是 QoS ，而是反向墙。
BT 下载就很容易触发反向墙，特点正好是大量连接+大量流量。

反向墙的特点就是凡是境外地址的连接全都阻断，国内连接没影响。

可能流量大的情况下过于频繁跳跃端口，会遭遇像 BT 下载那样的反向墙

@xmh51 我认为 x02 那个人说得对，更大可能性就是人情社区与城市独来独往生活方式的对撞。

我是见过村民们的类似行为，多年以前每次回家人老家就遇到了，一见面就跟我们讲不同村民及其外地子女的八卦，包括从对方行为习惯、出行规律、作息时间去“合理”推测他们在干嘛，然后下结论说“是个好/坏人”，要不要跟对方交往。至于“佐证”，问就是“xxx 也是这么说的”，然后再加点自己的“观察”——我见到他们确实就那个时间点出去买 aaa 干 yyy ，一定就是那样。

看得出就是以讹传讹、同温层回音室那种放大效应。

也就最近十年左右，外地租客多了，他们的这种行为才少了点。

至于讨论区的那么多怀疑者，如果他们自己正好不幸地成了村民们口中的谈资、一出门就被人指指点点甚至见面就骂，我不信一年半载后他们还能够无所谓、继续保持乐观心态。

@canyue7897 还好暂时没遇到过所有端口阻断（除非是开着 BT ，连接太多触发反向墙），这个 QoS 有时实在很怪，比如我 2 分钟内连续 3 次测试，见到的端口阻断数会越来越多（但未必重叠），过 5 分钟再测，又全通了

而这段期间，同 IP 地址其他端口的 UDP 服务没受到影响，并且其它 IP 地址依旧保持畅通

然而如果

个人猜测，可能一段时间内少量 UDP 端口大流量就会先触发普通的 QoS ，如果是一段范围的 UDP 流量过多可能就触发范围级 QoS ，要是 UDP 流量大且端口过多就触发反向墙（就像开着 BT 那样）

不过这背后的实现确实是个黑盒，我猜也未必猜得对

@Livid 有个名叫 OrochiZ 的账号连续骂人

怎么一堆人指责 OP 、认为 OP 疑似有精神障碍，都没看到 OP 清清楚楚写着“划门”吗？
还是选择性失明？
更何况 OP 后续还补充了“门上面的漆全被划掉”。

我一个旁观的都越看越觉得不妥。
有必要请那些认为 OP 有精神障碍的，重点解释下“划门”是什么情况。

倒是第二页有几个特别认真的回复，显得有用得多