@Zy143L 简单的说：可能会出现端口号冲突问题（如果您的系统不报错，那就一切 OK ）

因为端口监听默认是“独占”模式。程序没有设置 SO_REUSEADDR 、SO_REUSEPORT 的时候，这个端口只能被先监听占用的程序使用，因此就无法在上面继续打洞了。（会出现经典的 [Errno 48] Address already in use ）

因此一般情况下，是 Natter 打洞+防火墙的转发规则，将打洞端口转发到局域网的 NAS 服务器上（或者本机的其他端口）。

防火墙转发规则不会导致端口号冲突，因此先设好转发再在此端口打洞，这种“监听”是 OK 的。

@Tink 谢谢~
@twl007 学习学习
@mikeluckybiy 之前在 /t/878703 评论区讨论过 hhhh
@ihipop 所以 Natter 采用的是长连接，这个程序需要保持在后台运行状态，重拨号前端口就不会变了。

另外考虑到重新拨号后，端口变化的解决方法...其实有一种暴力的方式，就是不停并发创建新连接，直到选到自己想要的端口号上。后续会评估这个方案的可行性。

已开源： https://v2ex.com/t/879549
@Wenpo @jackzhou0 @Argon @hanguofu @zhengrt @Tink

@Tink 不是 frp 。
frp 的流量是要全部经过服务器的。
这个方案，保持连接只是为了维持 NAT 的端口映射关系，流量不会过服务器。

服务器并非必要选择，只要知道外部端口并维持连接即可。
目前在考虑支持 tcp 的 public stun 服务器借助打洞，不过自己服务器的行为更可控一些。

@hanguofu 因为一般情况下光猫防火墙会阻止外部的传入 TCP （即使是 NAT1 ）。桥接一劳永逸。
手动关闭光猫防火墙，并设置 DMZ 也可以达到同样的效果。

@Wenpo
@jackzhou0

简单介绍一下原理吧。

假设运营商给了我 NAT IP：100.64.12.34
利用 Socket 端口重用的特性，监听 TCP 端口 100.64.12.34:1234 的同时，由这个端口，向我的腾讯云服务器建立一条 TCP 连接。
服务器告诉本地，你的公网地址是 203.0.113.10:14500 ，并且服务器保持这个连接不关闭。（这很重要）
只要这条连接维持下去，任意地址访问 203.0.113.10:14500 ，最终都会转发到 100.64.12.34:1234 去。
一旦这条连接断开，那么转发规则就会失效。

方案可行前提是：NAT1 ，并且没有 TCP 防火墙（一般改桥接即可）。

首先，STUN 测试一般使用的是 UDP ，而 Port Forwarding Tester 网站上端口检查是 TCP ，不是同一种协议。
其次，NAT1 (Full cone NAT) 是可以通过类似打洞的方式，在公网上开放自己 TCP 端口的，并且运行 http/https 服务。
我正在做这个实验，在中国移动的家宽上已经成功实现。
有空会把方案开源出来。

https://ip.sb ? 有 api

站长也是 v 友
/t/381820

这还能收回？大概是运营商搞 BRAS 升级时配置错了。打电话投诉一下就好。

测试：公司有自签名根证书，确实能拦截到别人的 https 请求啊

@Vegetable Python 之父中国分父是吧

我猜可能是专辑封面的问题。
IINA 对于音乐专辑封面展示并不是一张静态图片，而是以 mjpeg 的视频流显示的，按 ⌘I 可以看到。

@microxiaoxiao
@52coder
各位说的对，正确做法还是循环赋值。
只是想说明一下 -1 也能出正确结果的原因。

这里做个提示吧：非标准行为，大家不要学我哦～

#15 @52coder
#42 @microxiaoxiao

补充一下，恰巧在全填 -1 的情况下，memset 可以正常工作。memset(arr,-1,sizeof(int)*10) 没问题
-1 的补码为全 1 ，因此不管是多少 bit 的有符号类型，值都是 -1 。
另外一个特例，就是 0 （全 0 ）。

换成另外的数字，比如 memset(arr, 1, sizeof(int)*10) 就要出事故了 hhh

@xxfye
根据 SEQ 是可以判断连接，但是需要上下文。
传入连接，peer 发来一个 SYN ，这是第一条报文，前面没有相关的 SEQ ，那么是怎么判断目的地的呢？

我觉得大家缺的不是公网 IP ，而是开放端口。
假如运营商全程 NAT1 ，并且提供端口映射服务，可以解决 99% 的问题并且节省公网 IPv4 。

没有用过 NAT4444 ，但是可以推测出这种方案是无法接受传入连接的。
假公网是两层 Fullcone NAT ，然而 Fullcone NAT 本身没有要求转换前后端口号一致。
假公网内外 IP 显示一致，所以可以推测出可能是这样的方案：
　　用户 1-5 ，共用 IP 123.45.67.89：
　　　　用户 1 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:10000-19999 ）
　　　　用户 2 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:20000-29999 ）
　　　　用户 3 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:30000-39999 ）
　　　　用户 4 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:40000-49999 ）
　　　　用户 5 （ 123.45.67.89:1-65535 ）映射（ 123.45.67.89:50000-59999 ）

映射方法应该和普通的 NAT 类似，只不过进出都是同一个 IP ，并且不能接受传入（无法从外部映射回去）