搜索
bottom↓
回复: 30

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

[复制链接]

出0入59汤圆

发表于 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包的数据格式是一样的。

出0入0汤圆

发表于 2022-6-23 17:18:37 | 显示全部楼层
http不香吗?

出0入198汤圆

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

出0入59汤圆

 楼主| 发表于 2022-6-23 21:58:49 | 显示全部楼层
udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果

出0入228汤圆

发表于 2022-6-23 22:02:36 来自手机 | 显示全部楼层
tftpd 还真没见过 在非局域网用的

出0入198汤圆

发表于 2022-6-23 22:48:47 来自手机 | 显示全部楼层
Momo 发表于 2022-6-23 21:58
udp在特定用途还是有他的优势的。
明天推送一版升级出去看看效果

(引用自4楼)

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

出0入59汤圆

 楼主| 发表于 2022-6-23 22:49:40 | 显示全部楼层
wxws 发表于 2022-6-23 22:02
tftpd 还真没见过 在非局域网用的
(引用自5楼)

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

出0入59汤圆

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

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

出0入198汤圆

发表于 2022-6-23 23:02:20 来自手机 | 显示全部楼层
Momo 发表于 2022-6-23 22:50
多谢你的建议,我会认真考虑后决定是否转换,谢谢!
(引用自8楼)

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

出0入4汤圆

发表于 2022-6-23 23:12:57 | 显示全部楼层
UDP是不可靠的数据报协议,如果非要使用不可,应用程序中要有加持(增加确认和重传机制)。
再者,外网穿透也是麻烦事。

出0入198汤圆

发表于 2022-6-23 23:21:50 来自手机 | 显示全部楼层
本帖最后由 redroof 于 2022-6-23 23:23 编辑
sunliezhi 发表于 2022-6-23 23:12
UDP是不可靠的数据报协议,如果非要使用不可,应用程序中要有加持(增加确认和重传机制)。
再者,外网穿透 ...

(引用自10楼)


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

出0入4汤圆

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

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

出0入59汤圆

 楼主| 发表于 2022-6-23 23:40:31 | 显示全部楼层
举一个应用场景:数万台设备,上传报文频率不确定,每包数据几十个字节,这个情况下http传输对服务器的负担很重,而且http对设备端也略显臃肿,我们都是M0级别的芯片还要跑个LwIP,所以目前UDP也算是合理的选择。

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

出0入228汤圆

发表于 2022-6-24 04:33:50 来自手机 | 显示全部楼层
Momo 发表于 2022-6-23 23:40
举一个应用场景:数万台设备,上传报文频率不确定,每包数据几十个字节,这个情况下http传输对服务器的负担 ...
(引用自13楼)

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

出0入228汤圆

发表于 2022-6-24 04:49:09 来自手机 | 显示全部楼层
1  设备向服务器69发wr请求
2  服务器找到个空端口,并打开接收准备
3  服务器将端口号 通过1的链路反馈给 设备
4  设备通过新端口访问服务器

这样就不存在 打洞了。

出0入228汤圆

发表于 2022-6-24 04:53:04 来自手机 | 显示全部楼层
不明白lz.为什么真正传输时要服务器主动来联 设备?

出0入148汤圆

发表于 2022-6-24 07:54:40 来自手机 | 显示全部楼层
Momo 发表于 2022-6-23 23:40
举一个应用场景:数万台设备,上传报文频率不确定,每包数据几十个字节,这个情况下http传输对服务器的负担 ...
(引用自13楼)

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

出0入198汤圆

发表于 2022-6-24 08:16:44 来自手机 | 显示全部楼层
Momo 发表于 2022-6-23 23:40
举一个应用场景:数万台设备,上传报文频率不确定,每包数据几十个字节,这个情况下http传输对服务器的负担 ...
(引用自13楼)

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

出0入198汤圆

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

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

出0入0汤圆

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

那像楼主这样的应用,用FTP行不行的??

出0入42汤圆

发表于 2022-6-24 18:14:33 | 显示全部楼层
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半天传不完. 用scp抓到本地服务器, 秒传. 再从本地服务器tftp下文件, 秒传

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

出0入198汤圆

发表于 2022-6-24 18:40:47 来自手机 | 显示全部楼层
albert_w 发表于 2022-6-24 18:14
以前内部测试, 文件服务器在国外, 中间有VPN专线.
试过客户端走tftp直接从国外抓文件, 想死的心都有了, 半 ...

(引用自21楼)

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

出0入42汤圆

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

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

出0入198汤圆

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

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

出0入59汤圆

 楼主| 发表于 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,下一步准备开多一台服务器分担部分设备,因为主机性能再往上走性价比就不够了,宁愿两台主机并行处理。

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

出0入59汤圆

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

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

出0入59汤圆

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

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

出0入198汤圆

发表于 2022-6-25 08:38:00 来自手机 | 显示全部楼层
Momo 发表于 2022-6-24 22:16
正好请教一下:我的应用要求设备需要保持长连接,也就是说服务区和设备端随时都有可能有数据要主动发给对 ...
(引用自25楼)

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

出0入198汤圆

发表于 2022-6-25 08:50:04 来自手机 | 显示全部楼层
Momo 发表于 2022-6-24 22:18
是的,这是个好办法,不过我们用了一个现成的tftp服务器端软件,所以做不了第3步,如果现在这个方案不行 ...
(引用自26楼)

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

出0入59汤圆

 楼主| 发表于 2022-6-25 21:03:04 | 显示全部楼层
UDP通道上主要跑随机发生的小尺寸数据,偶尔利用UDP升级一下固件,至于为什么用TFTP,主要是配合客户需求以及对历史产品兼容。

出0入85汤圆

发表于 2022-10-7 21:43:43 来自手机 | 显示全部楼层
redroof 发表于 2022-6-24 08:34
其实http才是最方便的可以搭岀超高QPS的协议。
对不熟悉现代大数据框架的人有点反直觉,哈哈。http的额外 ...

(引用自19楼)

你这个很专业啊,不得不感慨一下,因为我之前在一家负载均衡厂商做研发,哈哈。
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子论坛 -- 东莞阿莫电子网站 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2023-1-27 23:23

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表