udp不通过(udp不通怎么解决)

1.软文推荐

2.软文推荐

3.软文推荐

目录： 1、UDP连接失败是怎么回事啊 我都上不去了 2、UDP连接错误是什么意思啊？ 3、无法通过udp端口5730 实况10没法联 怎么办 4、UDP报文收不到问题排查 5、UDP端口不通，网络状态无法查看。 UDP连接失败是怎么回事啊 我都上不去了

问题多发生在有路由NAT的情况下，实际上很多人跳过NAT后就可以正常游戏了。但是毕竟网吧、公司都不会为一个人服务吧，而且我自己的问题更严重，跳过NAT问题依旧。眼见TX办事不力，XE泛滥的又不是时候，估计TX没空搭理这事儿，只能自己想办法解决了

要解决这个问题方便的方法，就是在连续2-3次出现UDP连接错误后，关掉modem或者路由器再重新打开(就是重新启动网络链接)，然后一切就恢复正常了。UDP连接错误是什么意思啊？

;     UDP(User Datagram Protocol) 用户数据报协议 (RFC 768)

      用户数据报协议(UDP)是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。 UDP 协议基本上是 IP 协议与上层协议的接口。 UDP 协议适用端口分别运行在同一台设备上的多个应用程序。

      由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 UDP 的“端口号”完成的。例如，如果一个工作站希望在工作站 128.1.123.1 上使用域名服务系统，它就会给数据包一个目的地址 128.1.123.1 ，并在 UDP 头插入目标端口号 53 。源端口号标识了请求域名服务的本地机的应用程序，同时需要将所有由目的站生成的响应包都指定到源主机的这个端口上。 UDP 端口的详细介绍可以参照相关文章。

      与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。

      UDP 适用于不需要 TCP 可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。 UDP 是传输层协议，服务于很多知名应用层协议，包括网络文件系统(NFS)、简单网络管理协议(SNMP)、域名系统(DNS)以及简单文件传输系统(TFTP)。

      协议结构

      Source Port — 16位。源端口是可选字段。当使用时，它表示发送程序的端口，同时它还被认为是没有其它信息的情况下需要被寻址的答复端口。如果不使用，设置值为0。

      Destination Port — 16位。目标端口在特殊因特网目标地址的情况下具有意义。

      Length — 16位。该用户数据报的八位长度，包括协议头和数据。长度最小值为8。

      Checksum — 16位。IP 协议头、UDP 协议头和数据位，最后用0填补的信息假协议头总和。如果必要的话，可以由两个八位复合而成。

      Data — 包含上层数据信息。

      UDP的特点：

      UDP协议使用IP层提供的服务把从应用层得到的数据从一台主机的某个应用程序传给网络上另一台主机上的某一个应用程序。

      UDP协议有如下的特点：

      1、UDP传送数据前并不与对方建立连接，即UDP是无连接的，在传输数据前，发送方和接收方相互交换信息使双方同步。

      2、UDP不对收到的数据进行排序，在UDP报文的首部中并没有关于数据顺序的信息(如TCP所采用的序号)，而且报文不一定按顺序到达的，所以接收端无从排起。

      3、UDP对接收到的数据报不发送确认信号，发送端不知道数据是否被正确接收，也不会重发数据。

      4、UDP传送数据较TCP快速，系统开销也少。

      从以上特点可知，UDP提供的是无连接的、不可靠的数据传送方式，是一种尽力而为的数据交付服务。

无法通过udp端口5730 实况10没法联 怎么办

玩游戏的时候开防火墙了吗？把防火墙关了，或者在防火墙里把这个端口打开试试！

UDP报文收不到问题排查

同事说告警报文没办法接收了, 程序同时向本机发送UDP告警和另外一台机器发送UDP报文,结果显示,本机UDP是正常收到的,远程的机器收不到UDP报文的.

程序同时发送到本地应用和远程应用的,虽然是不同的IP和端口,但是是同一个逻辑,所以程序的本身的问题可能性比较小,先测试下是否为网络问题:

首先,我们来看下这个1472是怎么来的,在以太网环境中,以太网的帧的body大小为46字节到1500字节之间,本次是处于IPV4的环境,IP包头大小为20个字节,所以还剩下1480字节;UDP的协议的报文头长度为8个字节,所以剩下的udp的包体长度为1480-8 = 1472个字节,具体展示如下图:

格式如下:

上述告警意思是因为我们环境下网卡的MTU设置为1500个字节,如下:

因为发送的UDP报文长度大于可以传输的安全长度1472个字节,这不代表不能发送,只是因为大于了帧的最大传输长度,所以在IP层需要进行分包,一旦网络环境不好,分包产生了丢失问题,会造成IP的组包失败,从而导致UDP的报文丢失.

还可以通过 netstat -su 进行监控:

既然MTU太小了,那么尝试修改下两端的MTU最大值,MTU是取整个路由的MTU最小值,我们尝试把两端的MTU增大下:

两端MTU增加后,仍然会报错,那么可能的原因是中间路由设备设置的MTU比较小,查看下,由于主机上没有traceroute命令来跟踪,尝试使用另外一个命令:

类似于traceroute,可以追踪路由,结束后打印MTU值.

还可以带个端口,测试这个UDP端口.

在实际环境中,由于中间很多路由都看不到,而且让中间的所有路由都改MTU值不是太现实.

在MTU为1500字节的情况下,如果发送的UDP报文大于MTU,比如发送8000个字节,如果包缓存足够,且分包按照正确的顺序到来,通过recvfrom(9000) 还是可以收到一个完整的UDP包的. 如果IP分片丢失,校验失败,包就会丢弃.recvfrom(9000)将阻塞.

为防止socket缓冲区溢出造成的问题,特意增加了socket的缓冲区.

cat /proc/sys/net/core/rmem_default 和 cat /proc/sys/net/core/rmem_max 可以查看socket缓冲区的缺省值和最大值。

可以通过 echo xxx /proc/sys/net/core/rmem_default 的方法来临时修改,也通过更改/etc/sysctl.conf文件添加以下配置来修改:

修改完成后记得运行以下命令来生效:

但是在本次仍然没起到效果.

最终解决方法是绕过了这个问题,直接改了接口,不采用UDP发送了,而是采用文件采集形式.

这是一次不成功的经验,有这方面经验的朋友,可以留言交流下还有什么原因造成这种问题.

UDP端口不通，网络状态无法查看。

你公司应该封了UDP端口了，现在有些公司是封UDP的。本地连接——属性——TCP/IP——高级——选项——筛选