UDP无连接,Go中DialUDP仅绑定默认远端地址便于Write,而WriteToUDP才符合UDP本质;固定目标用DialUDP,动态目标必须用ListenUDP+WriteToUDP;接收须用ReadFromUDP,且所有可靠性机制需自行实现。

DialUDP 只是帮你绑定了一个默认远端地址,方便后续用 Write;而真正灵活、符合 UDP 本质的发送方式,是用 WriteToUDP 直接指定目标。
用 DialUDP 发送:适合固定目标的简单场景
当你只往同一个地址(比如本地测试服务 "127.0.0.1:8080")发数据时,DialUDP 最省事。它返回的 *net.UDPConn 支持直接调用 Write,不用每次传地址。
- 必须用
net.ResolveUDPAddr("udp", "host:port")解析地址;net.ParseIP("localhost")会返回nil,这是常见 panic 源头 -
DialUDP的第二个参数(本地地址)传nil表示让系统自动选端口和网卡 - 发送成功 ≠ 对方收到:UDP 不保证送达,
Write返回nil err只代表数据交给了内核协议栈 - 如果目标端口没监听,Linux 下会触发 ICMP “port unreachable”,下次
Write可能返回connection refused
addr, _ := net.ResolveUDPAddr("udp", "127.0.0.1:8080")
conn, _ := net.DialUDP("udp", nil, addr)
defer conn.Close()
conn.Write([]byte("ping"))
用 WriteToUDP 发送:才是 UDP 的正确打开方式
只要目标不固定(比如广播、多播、动态 IP、或同一客户端要发给多个服务),就该跳过 DialUDP,直接用 ListenUDP 创建连接,再用 WriteToUDP 指定每次的目标地址。
- 本地监听地址可设为
&net.UDPAddr{Port: 0},让系统随机分配空闲端口(适合客户端角色) -
WriteToUDP的第二个参数是*net.UDPAddr,必须非 nil;传错格式(如 IPv6 地址配 IPv4 端口)会导致invalid argument - 缓冲区大小建议设为
1500(以太网 MTU)或4096,太小会截断,太大浪费内存 - 别在循环里反复
ResolveUDPAddr—— 解析 DNS 或字符串是开销,应提前做或缓存
conn, _ := net.ListenUDP("udp", &net.UDPAddr{Port: 0})
defer conn.Close()
dst, _ := net.ResolveUDPAddr("udp", "192.168.1.100:9999")
conn.WriteToUDP([]byte("hello"), dst)
接收端必须用 ReadFromUDP,不能用 Read
服务端监听后拿到的是裸 *net.UDPConn,它的 Read 方法不可用(会 panic),因为没绑定远端地址;必须用 ReadFromUDP,它同时返回数据长度 n 和发送方地址 addr,这两者缺一不可。
本文档主要讲述的是android rtsp流媒体播放介绍;实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频,的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助;感兴趣的朋友可以过来看看
-
buffer[:n]才是有效内容,buffer全长不是数据长度 - 如果只处理单包、不回包,可以忽略
addr;但只要需要响应,就必须拿这个addr传给WriteToUDP - 错误
read udp: i/o timeout常见于设置了SetReadDeadline但没重置,循环中记得检查err并continue
容易被忽略的底层事实
UDP 在 Go 里没有“连接状态”概念。所谓“已连接的 UDP socket”只是操作系统层面的优化(限制只能跟某个地址通信),Go 的 *net.UDPConn 本身不维护任何状态。这意味着:
-
DialUDP后调用WriteToUDP会报错(地址冲突);反过来,ListenUDP后调用Write也会报错(没默认远端) - 没有“连接中断”事件——你永远不知道对方是否下线,只能靠业务层心跳或超时机制判断
- 别试图把 TCP 的思路套过来:没有
CloseWrite,没有SetKeepAlive,没有连接池









