你如果用梯子, 很可能就是走的 apple 服务器中转, 那么断线也是很正常的, 毕竟 apple 的服务器都在国外.
但是如果是 p2p 的话, 就很稳, 不过 p2p 对打洞条件有要求

@lanlandezei 程序里有自动创建 iptables 规则的，你可以在 nat 表里找到
还有，interval 不用设置太高，半个小时更新一次都没问题，毕竟用的公共服务器

@lanlandezei 有需要可以自行编译

https://github.com/Alozxy/trav

@q197 更进一步研究抓包发现，在 TCP 协议下，无论是连接 peers 还是连接 tracker ，使用的本地端口都是 socket 随机指定的，而不是设置里的监听端口，在这种情况下 nat 外的端口也是不固定的，所以两个 peers 自动打洞成功的概率可以忽略不计。
但是作为对比，UDP 协议下，无论是μtp 还是 udp tracker ，使用的本地端口都是设置里的监听端口，这种情况下才有可能实现上一楼中说的情况，但是这要求必须是μtp + udp tracker ，实际使用中 udp tracker 其实是很少的。
但是如果下载的不是私有种子，那么就和之前说的一样，可以使用 DHT 或者 PEX 协议接受μtp 入站连接，[BEP_0055]( https://www.bittorrent.org/beps/bep_0055.html)也规定了一部分打洞扩展。
以上实验皆基于 qbittorrent

@q197 其实即便 tacker 记录的是 external port ，两个 nat1 的 peers 也很难连上，主要就是因为 nat 的映射时间太短，而 tracker 汇报的间隔很长，所以只有两个 peers 同时在 nat 映射打开的时候连接对方才行，这个概率真的很随缘。不过如果真是这种情况，只需要一个 peer 主动一直打开映射就一定能被其他 peer 连上，可以说能简化很多。

@hello365 -td 是你 tcp 包的目的端口,也就是你 vps 上的端口,你说的那个是 nat 防火墙上的 external port,这个是 nat 防火墙自动分配的

@isad 不好意思,我写错了,应该是: 除非"你"把 peers 传输协议设置为仅μtp --> 除非"别人"把 peers 传输协议设置为仅μtp
因为大部份 BT 客户端默认情况都是基于 TCP 的 BT 协议优先,这个是没有问题的

@hello365 你勾选 Use proxy for peer connections 相当于是把 BT 协议和 μtp 协议代理到 mitmproxy 里, 大概 mitmproxy 处理不了这两个协议汇报错吧.

@hello365 我这个实践里,vps 仅用于获取本地客户端在 nat 防火墙外的 external port, 而不是用来架代理的. mitmproxy 是和客户端一样搭建在本地的,所以源 ip 依然是你本地的 ip.
至于你说的,相当于通过 vps 代理下载. 相关教程很多就不赘述了

@isad DHT 我测试了一下,qbittorrent 会使用设置中的监听端口,通过 udp 发送 dht 查询消息. 但是具体到连接 peers 进行下载的时候,除非你把 peers 传输协议设置为仅μtp, 否则还是会优先使用 tcp 进行连接. 由于 tcp 和 udp 的 nat 映射不一样, 所以连接性依然不是很理想. 即使设置为仅μtp, 也同样只能在 nat1 下接受入站连接.
不过话说回来,既然使用 DHT,就意味着在下载公网的种子,其实只要有速度,连接性好不好也不是很重要了,毕竟公网种子不强制要求上传.

@binhb 6 和 10 表示读写的扇区数量,乘以扇区大小即总读写量

/proc/diskstats
https://www.kernel.org/doc/Documentation/ABI/testing/procfs-diskstats

应该不是被墙了吧,如果被墙了不是应该无论什么运营商都用不了吗?
我觉得应该是运营商屏蔽了,但是想不通运营商为什么要这么干

之前看过 linus 的这段代码,第二种写法的好处是使用二维指针**p 可以保存当前节点的前一个节点的指针信息,而这个正好是删除某个节点的必要信息.
我记得 linus 说第二种的好处是不用特地处理头节点后第一个节点为待删除节点的情况,抽象性比较高

如果一边端口受限另一边对称 nat,并且对称 nat 是端口递增的, 那么可以通过手动发包的方法打洞
比如说对称 nat 一侧,和打洞服务器通信时,防火墙映射的外网端口为 n,那么真正打洞时,防火墙映射的外网端口就是 n+x(x 不一定为 1,因为内网可能还有其他客户端),这时候端口受限 nat 一侧的客户端就可以手动发包访问 n+x 号端口,就可以用该端口完成打洞.
至于 x,一般比较小,可以通过遍历的方式进行发包

@geekvcn 但是现在的直播网站大部份都有 p2p 上传,而且因为是浏览器 webrtc 的功能,一般用户不会关闭,这种如果也算 PCDN 的话那岂不是我看个直播就有断网风险?

@altchen
@Leonard
如果只是客户端自己拉的本地黑名单当然是可以,但是如果发送人不在联系人里就不提示,imessage 好像是可以这样的,tg 不知道为什么没有实现.
我觉得主要原因是很多外国 IM 都是以短信为模型,短信的特点就是使用系统通讯录+可以随意给任何人发消息.而国内的 IM 都是每个 app 自己维护一个通讯录

@pcbl
tg 你不给通讯录权限也可以用啊,这时候就是以会话为单位进行管理的
不过我说的的确不够严谨,的确可以通过本地黑名单来过滤消息