求教：TFTP通讯如何穿透NAT type3或4类型的路由器

Momo · 发表于 2022-6-23 16:20:25

应用场景：云端服务器运行一个软件tftpd64.exe，提供 TFTP服务，设备端在局域网，需要通过put向服务器写文件。
问题描述：设备（嵌入式设备）先通过69端口向服务器发起WR请求，服务器通过随机端口（例如56351）向设备恢复ACK报文，由于设备端局域网路由器是NAT类型3的原因，导致这个报文被路由器拒绝，因此服务器收到ICMP 端口不可达的错误，设备端写文件失败。

解决办法：
（1），要求客户更换路由器，NAT必须支持Restricted Cone NAT，此方案非优选，而且客户不一定配合。
（2），服务器端设定一个端口范围，例如（65500~65509），设备端每次在发WR请求时，先向这个端口范围各发一包数据打洞，一般洞的有效期能持续2-3分钟（有些路由器可能更久），然后再发WR到69。

请教：
（1），上述方法2算不算正规方法？目前测试貌似能用，不知道会不会有其他问题？
（2），在设备局域网运行tftpd64 Client程序，向同一个服务器发起wr请求，可以正常上传文件，服务器端wireshark抓到的数据包流程相同，但是嵌入式设备在发起WR请求后，服务器的ACK就被端口不可达了。则是因为路由器NAT type的原因吗？如果是，同样的端口，服务器下发给PC这边时不会出现“端口不可达”而只有嵌入式这边会？我比较了WR包的数据格式是一样的。

三世执戟 · 发表于 2022-6-23 17:18:37

http不香吗？

redroof · 发表于 2022-6-23 18:35:51

正常ftp协议也是这么做，要个额外的数据端口。但你会发现ftp基本上路由器都可以通过，因为ftp很有名，路由器内部都有专门的操作，自己替你处理这些。配置选项一般叫ftp alg，默认都开着。
你这个是用的tftp协议，不够岀名，所以常见的路由器都没给它开口子，哈哈
老老实实用http吧。tftp这些都不是设计成在公网中使用的

Momo · 发表于 2022-6-23 21:58:49

udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果

wxws · 发表于 2022-6-23 22:02:36

tftpd 还真没见过在非局域网用的

redroof · 发表于 2022-6-23 22:48:47

Momo 发表于 2022-6-23 21:58
udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果
(引用自4楼)

如果不是自己公司内部可控的网络环境，趁早改了吧。
老老实实用http最省心。
你不可能知道客户的网络是啥样，他们的网管听不听得懂"nat穿透"都是问题。

Momo · 发表于 2022-6-23 22:49:40

wxws 发表于 2022-6-23 22:02
tftpd 还真没见过在非局域网用的
(引用自5楼)

就是UDP通讯，完全可以用在广域网，只是要考虑路由器的NAT穿透类型

Momo · 发表于 2022-6-23 22:50:59

redroof 发表于 2022-6-23 22:48
如果不是自己公司内部可控的网络环境，趁早改了吧。
老老实实用http最省心。
你不可能知道客户的网络是啥 ...
(引用自6楼)

多谢你的建议，我会认真考虑后决定是否转换，谢谢！

redroof · 发表于 2022-6-23 23:02:20

Momo 发表于 2022-6-23 22:50
多谢你的建议，我会认真考虑后决定是否转换，谢谢！
(引用自8楼)

没吃过亏，没见过复杂网络环境的，就不算正规产品。
用tftp比通常的http有什么好处呢？对你的客户来说？
正规产品需要nat穿透的，通常都是音视频传输，聊天传文件之类的，为了节约服务器资源，作为一种加速手段来用。但如果这样试了失败，那么仍然可以变回传统的服务器中转的方法。
要相信，总有一些客户的网络环境是完全无法做nat穿透的。

sunliezhi · 发表于 2022-6-23 23:12:57

UDP是不可靠的数据报协议，如果非要使用不可，应用程序中要有加持（增加确认和重传机制）。
再者，外网穿透也是麻烦事。

redroof · 发表于 2022-6-23 23:21:50

本帖最后由 redroof 于 2022-6-23 23:23 编辑

sunliezhi 发表于 2022-6-23 23:12
UDP是不可靠的数据报协议，如果非要使用不可，应用程序中要有加持（增加确认和重传机制）。
再者，外网穿透 ...
(引用自10楼)

只是普通传点数据，为什么要折腾这个不可靠的内网穿透呢？
正常用http传了，啥毛病都没，100%网络都能过。用udp内网穿透，最多80%情况下能用(我不确定这个比例，也可能更低)，剩下的人呢？这些客户都不要了？或者给这些人再做个常规的传输方式？
不是专业的点对点音视频传输，完全没必要去费这个事做内网穿透优化。
内网穿透只是个优化，有他没他都得能用。某些客户的网络就是无法穿透的。

sunliezhi · 发表于 2022-6-23 23:28:02

redroof 发表于 2022-6-23 23:21
只是普通传点数据，为什么要折腾这个不可靠的内网穿透呢？
正常用http传了，啥毛病都没，100%网络都能过 ...
(引用自11楼)

少量数据确实没必要这么麻烦去优化速度，没必要。

Momo · 发表于 2022-6-23 23:40:31

举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担很重，而且http对设备端也略显臃肿，我们都是M0级别的芯片还要跑个LwIP，所以目前UDP也算是合理的选择。

当然，这个应用MQTT可能更合适，不过MQTT更臃肿，我们另外一个产品系列在用。

wxws · 发表于 2022-6-24 04:33:50

Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)

你这不是在打脸最近的盖革计联网方案吗？你提的不足，全占了。

wxws · 发表于 2022-6-24 04:49:09

1  设备向服务器69发wr请求
2  服务器找到个空端口，并打开接收准备
3  服务器将端口号通过1的链路反馈给设备
4  设备通过新端口访问服务器

这样就不存在打洞了。

wxws · 发表于 2022-6-24 04:53:04

不明白lz.为什么真正传输时要服务器主动来联设备？

yplin27 · 发表于 2022-6-24 07:54:40

Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)

一秒一次也就几万 QPS 吧，你数据库都能顶得住的话 HTTP 服务器来说根本不是事，除非你是用来传音视频有实时性要求

redroof · 发表于 2022-6-24 08:16:44

Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)

正常用法的udp也行啊，永远是设备端主动连服务器就行。
为什么要反连？反连要靠内网穿透，正常用法不需要。

redroof · 发表于 2022-6-24 08:34:43

yplin27 发表于 2022-6-24 07:54
一秒一次也就几万 QPS 吧，你数据库都能顶得住的话 HTTP 服务器来说根本不是事，除非你是用来传音视频有 ...
(引用自17楼)

其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外开销挺多，因为它是无状态的，每个请求都要带一大堆header。但是这些额外开销恰好保证了可以存在成品的全套负载均衡器，而且可以对你的后端服务器透明。所以你只要花钱就行，完全不受单机性能限制，想要多少qps都能做到。
如果是自定义的tcp或者udp，成品负载均衡器能做的事情就少的多，没有足够经验的人就很难自己写出超高qps的系统了。

xinyou · 发表于 2022-6-24 18:06:33

redroof 发表于 2022-6-23 18:35
正常ftp协议也是这么做，要个额外的数据端口。但你会发现ftp基本上路由器都可以通过，因为ftp很有名，路由 ...
(引用自3楼)

那像楼主这样的应用，用FTP行不行的？？

albert_w · 发表于 2022-6-24 18:14:33

以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半天传不完. 用scp抓到本地服务器, 秒传. 再从本地服务器tftp下文件, 秒传

从此不再想tftp跑公网的事儿了

redroof · 发表于 2022-6-24 18:40:47

albert_w 发表于 2022-6-24 18:14
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半 ...
(引用自21楼)

原因其实很简单，这也是udp最简单的实现方法。因为udp没有流控，不知道对方缓冲区够不够，所以最简单的做法就是发一包等一下回答。收到回答才能发下一包。
跨国的网络延迟很高，发一包等一下回答就慢死了。
tcp不怕延迟，只要窗口够大，就能用满网速

albert_w · 发表于 2022-6-24 18:50:38

redroof 发表于 2022-6-24 18:40
原因其实很简单，这也是udp最简单的实现方法。因为udp没有流控，不知道对方缓冲区够不够，所以最简单的做 ...
(引用自22楼)

嗯, 算了一下应该就是这个原因. 当时以为是有错包, 今天看了下, 就没校验这功能...

redroof · 发表于 2022-6-24 19:48:46

albert_w 发表于 2022-6-24 18:50
嗯, 算了一下应该就是这个原因. 当时以为是有错包, 今天看了下, 就没校验这功能... ...
(引用自23楼)

ping一下，看看延迟，然后算算你的文件多大，tftp一包是512字节。文件大小除以512再乘以ping延迟，就是总的需要的时间。
在局域网里就没事，反正通常都是低于毫秒的延迟，一秒钟够一千个来回了，也就是512k的数据。几兆的系统就十秒左右就够。
如果是国外250毫秒延迟，一秒钟就只能传2k了。也就是500秒1兆

Momo · 发表于 2022-6-24 22:16:38

redroof 发表于 2022-6-24 08:34
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外 ...
(引用自19楼)

正好请教一下：我的应用要求设备需要保持长连接，也就是说服务区和设备端随时都有可能有数据要主动发给对方，用UDP我只需要设备端定期发心跳包即可维持路由器的NAT通道，同时在服务器端保活，如果是http时不时要维持长连接才行？如果是这样，服务器在数万台（按5万台算吧）TCP长连接时资源消耗怎么样？目前我设备大约3万台左右，用UDP感觉已经到了极限了，当然服务器性能也渣，阿里云的ECS 四核8G，下一步准备开多一台服务器分担部分设备，因为主机性能再往上走性价比就不够了，宁愿两台主机并行处理。

至于楼上提到的钓鱼项目，那个设备量级真的太少，比较性不高。

Momo · 发表于 2022-6-24 22:18:20

wxws 发表于 2022-6-24 04:49
1  设备向服务器69发wr请求
2  服务器找到个空端口，并打开接收准备
3  服务器将端口号通过1的链路反馈给  ...
(引用自15楼)

是的，这是个好办法，不过我们用了一个现成的tftp服务器端软件，所以做不了第3步，如果现在这个方案不行的话，我就打算自己写服务器端，你说的这个方法我们已经在自定义下载协议上采用，是可以这么干的。

Momo · 发表于 2022-6-24 22:20:03

albert_w 发表于 2022-6-24 18:14
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半 ...
(引用自21楼)

TFTP本来就不能用来传大文件，我们用来传个固件，不超过100KB的数据，越简单越好。

redroof · 发表于 2022-6-25 08:38:00

Momo 发表于 2022-6-24 22:16
正好请教一下：我的应用要求设备需要保持长连接，也就是说服务区和设备端随时都有可能有数据要主动发给对 ...
(引用自25楼)

你用单机对付几万设备？那每个设备的数据量肯定很小吧？或者很久才传一次数据？
有超多的设备要保持长连接，udp就是最合适的方法了。但是偶尔要下载固件之类的话，临时用tcp做才最快。因为udp没流控

redroof · 发表于 2022-6-25 08:50:04

Momo 发表于 2022-6-24 22:18
是的，这是个好办法，不过我们用了一个现成的tftp服务器端软件，所以做不了第3步，如果现在这个方案不行 ...
(引用自26楼)

其实在单个udp连接上完全可以传输任意多个你自己的数据流，无非是在数据里加点描述信息而已。完全没必要削足适履去用tftp。
这种一看就是没被某些网络环境坑过的人，哈哈哈

Momo · 发表于 2022-6-25 21:03:04

UDP通道上主要跑随机发生的小尺寸数据，偶尔利用UDP升级一下固件，至于为什么用TFTP，主要是配合客户需求以及对历史产品兼容。

zdg102 · 发表于 2022-10-7 21:43:43

redroof 发表于 2022-6-24 08:34
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外 ...
(引用自19楼)

你这个很专业啊，不得不感慨一下，因为我之前在一家负载均衡厂商做研发，哈哈。

求教：TFTP通讯如何穿透NAT type3或4类型的路由器

论坛广告: >>