求教：TFTP通讯如何穿透NAT type3或4类型的路由器
应用场景：云端服务器运行一个软件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包的数据格式是一样的。 http不香吗？ 正常ftp协议也是这么做，要个额外的数据端口。但你会发现ftp基本上路由器都可以通过，因为ftp很有名，路由器内部都有专门的操作，自己替你处理这些。配置选项一般叫ftp alg，默认都开着。
你这个是用的tftp协议，不够岀名，所以常见的路由器都没给它开口子，哈哈
老老实实用http吧。tftp这些都不是设计成在公网中使用的 udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果{:smile:} tftpd 还真没见过 在非局域网用的 Momo 发表于 2022-6-23 21:58
udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果
(引用自4楼)
如果不是自己公司内部可控的网络环境，趁早改了吧。
老老实实用http最省心。
你不可能知道客户的网络是啥样，他们的网管听不听得懂"nat穿透"都是问题。
wxws 发表于 2022-6-23 22:02
tftpd 还真没见过 在非局域网用的
(引用自5楼)
就是UDP通讯，完全可以用在广域网，只是要考虑路由器的NAT穿透类型 redroof 发表于 2022-6-23 22:48
如果不是自己公司内部可控的网络环境，趁早改了吧。
老老实实用http最省心。
你不可能知道客户的网络是啥 ...
(引用自6楼)
多谢你的建议，我会认真考虑后决定是否转换，谢谢！ Momo 发表于 2022-6-23 22:50
多谢你的建议，我会认真考虑后决定是否转换，谢谢！
(引用自8楼)
没吃过亏，没见过复杂网络环境的，就不算正规产品。
用tftp比通常的http有什么好处呢？对你的客户来说？
正规产品需要nat穿透的，通常都是音视频传输，聊天传文件之类的，为了节约服务器资源，作为一种加速手段来用。但如果这样试了失败，那么仍然可以变回传统的服务器中转的方法。
要相信，总有一些客户的网络环境是完全无法做nat穿透的。 UDP是不可靠的数据报协议，如果非要使用不可，应用程序中要有加持（增加确认和重传机制）。
再者，外网穿透也是麻烦事。 本帖最后由 redroof 于 2022-6-23 23:23 编辑
sunliezhi 发表于 2022-6-23 23:12
UDP是不可靠的数据报协议，如果非要使用不可，应用程序中要有加持（增加确认和重传机制）。
再者，外网穿透 ...
(引用自10楼)
只是普通传点数据，为什么要折腾这个不可靠的内网穿透呢？
正常用http传了，啥毛病都没，100%网络都能过。用udp内网穿透，最多80%情况下能用(我不确定这个比例，也可能更低)，剩下的人呢？这些客户都不要了？或者给这些人再做个常规的传输方式？
不是专业的点对点音视频传输，完全没必要去费这个事做内网穿透优化。
内网穿透只是个优化，有他没他都得能用。某些客户的网络就是无法穿透的。 redroof 发表于 2022-6-23 23:21
只是普通传点数据，为什么要折腾这个不可靠的内网穿透呢？
正常用http传了，啥毛病都没，100%网络都能过 ...
(引用自11楼)
少量数据确实没必要这么麻烦去优化速度，没必要。 举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担很重，而且http对设备端也略显臃肿，我们都是M0级别的芯片还要跑个LwIP，所以目前UDP也算是合理的选择。
当然，这个应用MQTT可能更合适，不过MQTT更臃肿，我们另外一个产品系列在用。 Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)
你这不是在打脸最近的盖革计联网方案吗？ 你提的不足，全占了。 1设备向服务器69发wr请求
2服务器找到个空端口，并打开接收准备
3服务器将端口号 通过1的链路反馈给 设备
4设备通过新端口访问服务器
这样就不存在 打洞了。 不明白lz.为什么真正传输时要服务器主动来联 设备？ Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)
一秒一次也就几万 QPS 吧，你数据库都能顶得住的话 HTTP 服务器来说根本不是事，除非你是用来传音视频有实时性要求 Momo 发表于 2022-6-23 23:40
举一个应用场景：数万台设备，上传报文频率不确定，每包数据几十个字节，这个情况下http传输对服务器的负担 ...
(引用自13楼)
正常用法的udp也行啊，永远是设备端主动连服务器就行。
为什么要反连？反连要靠内网穿透，正常用法不需要。 yplin27 发表于 2022-6-24 07:54
一秒一次也就几万 QPS 吧，你数据库都能顶得住的话 HTTP 服务器来说根本不是事，除非你是用来传音视频有 ...
(引用自17楼)
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外开销挺多，因为它是无状态的，每个请求都要带一大堆header。但是这些额外开销恰好保证了可以存在成品的全套负载均衡器，而且可以对你的后端服务器透明。所以你只要花钱就行，完全不受单机性能限制，想要多少qps都能做到。
如果是自定义的tcp或者udp，成品负载均衡器能做的事情就少的多，没有足够经验的人就很难自己写出超高qps的系统了。 redroof 发表于 2022-6-23 18:35
正常ftp协议也是这么做，要个额外的数据端口。但你会发现ftp基本上路由器都可以通过，因为ftp很有名，路由 ...
(引用自3楼)
那像楼主这样的应用，用FTP行不行的？？ 以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半天传不完. 用scp抓到本地服务器, 秒传. 再从本地服务器tftp下文件, 秒传
从此不再想tftp跑公网的事儿了 albert_w 发表于 2022-6-24 18:14
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半 ...
(引用自21楼)
原因其实很简单，这也是udp最简单的实现方法。因为udp没有流控，不知道对方缓冲区够不够，所以最简单的做法就是发一包等一下回答。收到回答才能发下一包。
跨国的网络延迟很高，发一包等一下回答就慢死了。
tcp不怕延迟，只要窗口够大，就能用满网速 redroof 发表于 2022-6-24 18:40
原因其实很简单，这也是udp最简单的实现方法。因为udp没有流控，不知道对方缓冲区够不够，所以最简单的做 ...
(引用自22楼)
嗯, 算了一下应该就是这个原因.当时以为是有错包, 今天看了下, 就没校验这功能... albert_w 发表于 2022-6-24 18:50
嗯, 算了一下应该就是这个原因.当时以为是有错包, 今天看了下, 就没校验这功能......
(引用自23楼)
ping一下，看看延迟，然后算算你的文件多大，tftp一包是512字节。文件大小除以512再乘以ping延迟，就是总的需要的时间。
在局域网里就没事，反正通常都是低于毫秒的延迟，一秒钟够一千个来回了，也就是512k的数据。几兆的系统就十秒左右就够。
如果是国外250毫秒延迟，一秒钟就只能传2k了。也就是500秒1兆 redroof 发表于 2022-6-24 08:34
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外 ...
(引用自19楼)
正好请教一下：我的应用要求设备需要保持长连接，也就是说服务区和设备端随时都有可能有数据要主动发给对方，用UDP我只需要设备端定期发心跳包即可维持路由器的NAT通道，同时在服务器端保活，如果是http时不时要维持长连接才行？如果是这样，服务器在数万台（按5万台算吧）TCP长连接时资源消耗怎么样？目前我设备大约3万台左右，用UDP感觉已经到了极限了，当然服务器性能也渣，阿里云的ECS 四核8G，下一步准备开多一台服务器分担部分设备，因为主机性能再往上走性价比就不够了，宁愿两台主机并行处理。
至于楼上提到的钓鱼项目，那个设备量级真的太少，比较性不高。 wxws 发表于 2022-6-24 04:49
1设备向服务器69发wr请求
2服务器找到个空端口，并打开接收准备
3服务器将端口号 通过1的链路反馈给...
(引用自15楼)
是的，这是个好办法，不过我们用了一个现成的tftp服务器端软件，所以做不了第3步，如果现在这个方案不行的话，我就打算自己写服务器端，你说的这个方法我们已经在自定义下载协议上采用，是可以这么干的。 albert_w 发表于 2022-6-24 18:14
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半 ...
(引用自21楼)
TFTP本来就不能用来传大文件，我们用来传个固件，不超过100KB的数据，越简单越好。 Momo 发表于 2022-6-24 22:16
正好请教一下：我的应用要求设备需要保持长连接，也就是说服务区和设备端随时都有可能有数据要主动发给对 ...
(引用自25楼)
你用单机对付几万设备？那每个设备的数据量肯定很小吧？或者很久才传一次数据？
有超多的设备要保持长连接，udp就是最合适的方法了。但是偶尔要下载固件之类的话，临时用tcp做才最快。因为udp没流控 Momo 发表于 2022-6-24 22:18
是的，这是个好办法，不过我们用了一个现成的tftp服务器端软件，所以做不了第3步，如果现在这个方案不行 ...
(引用自26楼)
其实在单个udp连接上完全可以传输任意多个你自己的数据流，无非是在数据里加点描述信息而已。完全没必要削足适履去用tftp。
这种一看就是没被某些网络环境坑过的人，哈哈哈 UDP通道上主要跑随机发生的小尺寸数据，偶尔利用UDP升级一下固件，至于为什么用TFTP，主要是配合客户需求以及对历史产品兼容。
redroof 发表于 2022-6-24 08:34
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉，哈哈。http的额外 ...
(引用自19楼)
你这个很专业啊，不得不感慨一下，因为我之前在一家负载均衡厂商做研发，哈哈。
页:
[1]