TFTP 使用不关心丢包的 UDP 传输，它是怎么保证数据的完整性的？ - 知乎有问题，上知乎。知乎作为中文互联网最大的知识分享平台，以「知识连接一切」为愿景，致力于构建一个人人都可以便捷接入的知识分享网络，让人们便捷地与世界分享知识、经验和见解，发现更大的世界。73被浏览<strong class="NumberBoard-itemValue" title="1分享邀请回答1添加评论分享收藏感谢收起新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
大富大贵, 积分 10327, 距离下一级还需 9673 积分
论坛徽章:0
本帖最后由 iw1210 于
16:34 编辑
发现当客户端连续向服务器发送许多UDP数据包时，服务器不能收到所有包。 如何解决UDP丢包问题？增大服务器端的UDP的接收缓冲和客户端的UDP发送缓冲么？怎么做啊~
白手起家, 积分 9, 距离下一级还需 191 积分
论坛徽章:0
你们服务器端是不是 采用的是 收包-》 处理 -》再收包的方式？
还是有专门的线程收包？
增大缓冲是一种治标不治本的办法，因为收包速度不够快的时候 缓冲区早晚还是会满，依旧会丢包
丰衣足食, 积分 616, 距离下一级还需 384 积分
论坛徽章:3
飘过拿分~~~
大富大贵, 积分 10327, 距离下一级还需 9673 积分
论坛徽章:0
huanglei3220 发表于
你们服务器端是不是 采用的是 收包-》 处理 -》再收包的方式？
还是有专门的线程收包？
专门一个线程收包
白手起家, 积分 9, 距离下一级还需 191 积分
论坛徽章:0
本帖最后由 huanglei3220 于
17:12 编辑
那就要想办法提高收包速度了。比如：
收包的方式能不能优化？（阻塞 ，非阻塞 等）
是否可以提高收包线程的优先级？
还有客户端发包方式是怎样？ 是一直大数据量还是短时会有大量的包？只有这种情况下增大缓存是有意义的
如果是多客户端 那还要考虑是不是要分布式处理 ，做负载均衡了
这只是思路 具体的做法可以百度谷歌啊
巨富豪门, 积分 38223, 距离下一级还需 1777 积分
论坛徽章:4
udp 1000 qps到头.
家境小康, 积分 1922, 距离下一级还需 78 积分
论坛徽章:0
从应用层协议上解决。
白手起家, 积分 136, 距离下一级还需 64 积分
论坛徽章:0
UDP的丢包可以自定义协议来解决，比如在发送完数据后，接受端发一个“ACK（自定义的字段）“，发送端接受到后才能发送后面的数据，也就是发送一个数据确认一个数据的方式。
小富即安, 积分 3425, 距离下一级还需 1575 积分
论坛徽章:3
发一个确认一个反而慢。
这里可以异步，比如有100个包要发，可以20个一发，根据回复情况进行补发。
大富大贵, 积分 10327, 距离下一级还需 9673 积分
论坛徽章:0
linux_c_py_php 发表于
udp 1000 qps到头.
大侠，说说qps到底是啥意思啊，在网上搜了一下也没有说清楚的~
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备号 北京市公安局海淀分局网监中心备案编号：22
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处数加&大数据分析及展现
数加&大数据应用
管理与监控
阿里云办公
培训与认证
域名与网站(万网)
数加&人工智能
数加&大数据基础服务
互联网中间件
开发者工具
云服务器 ECS
&&&&&&&&&使用 iPerf 测试并排查 UDP 丢包问题
使用 iPerf 测试并排查 UDP 丢包问题
更新时间： 16:54:07
现象描述使用高速通道打通同一个地域（Region）下的两台 VPC 网络类型的 ECS 实例后，通过 iPerf 测试两台实例内网之间 UDP 丢包率，测试带宽达到 50 Mbps 以上时出现了丢包现象，且随着带宽的增加，丢包率出现增长趋势。如下图：
问题分析假设两台网络类型的 ECS 实例的私有 IP 为 VPC ECS A(192.168.104.235) 与 ECS B(10.182.83.13)，并用 Netcat（NC）监听并发送 UDP 数据封包，则网络类型的 ECS 实例 A 与实例 B 通信链路图如下：
其数据流走向为：
ECS A(192.168.104.235)-& NC 1(100.105.59.3)-& VGW(10.141.166.253)-& NC 2(100.105.59.9)-& ECS B(10.182.83.13)
我们需要对其链路进行排查分析，找出丢包的最终原因。
注意：由于只看到了源 Netcat (即 NC 1) 和目的 Netcat (即 NC 2) 之前的通信，抓包排查要避免误区，即随意判断是 Netcat (NC) 之间的直接通信丢包。
排查时会发现源端 eth0 的抓包发给了 VGW，但是在目的端抓包发现外壳封装了目的 NC 2 IP，如示例：
[Time ] 17:32:07.130844
Point: `input ` [ETHER] 24:4c:07:33:0e:02 -& 00:04:37:28:00:65, eth_type: 0x0800 [IPv4 ] 100.105.59.3 -& 10.141.166.253 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0xfe47 [UDP
] sport: 46703, dport: 250, size: 1514, chksum: 0x0000 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 1878597, tos: 0, tof: 0 [IPv4 ] 192.168.104.235 -& 10.182.83.13 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e [UDP
] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
[Time ] 17:32:07.130854
Point: `output` [ETHER] 24:4c:07:33:0e:02 -& 00:04:37:28:00:65, eth_type: 0x0800 [IPv4 ] 100.105.59.3 -& 100.105.59.9 proto: 17, ver: 04, ihl: 05, len: 1534, ident: 59824,R: 0, DF: 1, MF: 0, offset: 0, ttl: 60, chksum: 0x0000 [UDP
] sport: 46703, dport: 250, size: 1514, chksum: 0x0000 [VxLan] debug_flag: 0, vlan_tag: 0, payload_type: 0, version: 1, tunnel_id: 2125861, tos: 0, tof: 0 [IPv4 ] 192.168.104.235 -& 10.182.83.13 proto: 17, ver: 04, ihl: 05, len: 1498, ident: 55469,R: 0, DF: 1, MF: 0, offset: 0, ttl: 64, chksum: 0xd50e [UDP
] sport: 36687, dport: 5001, size: 1478, chksum: 0xa0aa
确认数据包通过 VGW 后，开始统计抓包信息:
ECS A 通过 iPerf 打 UDP 流量：iperf -c 10.182.83.13 -u -b 600mECS B 通过 iPerf 接收：iperf -u -s
在实例内部抓包。
ECS A：sudo tcpdump -w ~/client.pcap -n -i eth0 src host
192.168.104.25 and src port 1234ECS B：sudo tcpdump -w ~/server.pcap -n -i eth0 src host
192.168.104.25 and src port 1234
在两个 NC eth0 处抓包。
NC 1：sudo houyi-tcpdump -w /apsara/i-6we6pnh19n2q7srkgomd.pcap -nnK -i eth0 udp and src inner_port 1234 and dst inner_host 10.182.83.13NC 2：sudo houyi-tcpdump -B 4096 -w /apsara/i-6we53i9h3ducbju5rmuw.pap -nn -i eth0
udp -K and src inner_host 192.168.104.235 and src inner_port 1234
在 ASW 和 LSW 部署流统。
100.105.59.3:46728 -& 10.141.166.253:250
注意:由于目的端包外壳自动封装了目的 NC 1 IP，所以 VGW 端数据包的报文格式为：100.105.59.3:46728 -& 100.105.59.9:250。
根据抓包结果分析。
ECS A 丢包/发包：171/510203 NC 1 eth0 发包：510204 ASW 和 LSW 流统计出包：510204 NC 2 eth0 收包：510204 ECS B 收包：510204，capture 507442， dropped by kernel 2162
以上分析定位到实例协议栈丢包，通过调整实例内部 UDP Buffer Sizes 来调整网络栈（Stack），默认的 UDF Buffer Size 为 8 KB），您可以调整至
/proc/sys/net/core/rmem_default #默认的接收数据包内存大小 /proc/sys/net/core/rmem_max #最大的接收数据包内存大小调整后测试 UDP 丢包情况。
如果问题还未能解决，您可以到免费咨询，或联系阿里云。
云服务器（Elastic Compute Service，简称 ...
专有网络VPC（Virtual Private Cloud）是用...
阿里云关系型数据库（Relational Database Se...
本文导读目录
以上内容是否对您有帮助？
更新不及时
缺少代码/图片示例
太简单/步骤待完善
更新不及时
缺少代码/图片示例
太简单/步骤待完善
感谢您的打分，是否有意见建议想告诉我们？
感谢您的反馈，反馈我们已经收到脚踏实地，追求卓越
解决UDP丢包问题的经验
月初参与了一个关于图像网络传输的小项目，图像采集端用的FPGA，每秒采集接近20MB数据，将大块的数据分割成一个个包，每个包加上图像编号和包的序号等信息，使用UDP协议发送出去。我的任务是写一个接收端（Windows下），将一个个包拼凑起来，并将二进制的图像数据转换成可视的RGB图像。
这是我第一次用UDP协议做有用的事，书本上阐述的UDP的丢包特性终于成了实实在在的问题摆在我面前。我写的第一个版本的程序，20M的数据丢失了近一半。在解决问题的路上，这篇文章给了我很大帮助。
我首先尝试增大接受缓冲区的大小，马上就有效果了，丢包率降低到10%以下。第二个改进是使用多线程。在我的单线程的版本中，当一整幅图像接收完毕后便将数据写入到文件中，这个操作很耗费时间，当有新的数据过来时，程序依然在执行写入操作，来不及接受新过来的数据，因此而造成丢包。我开辟了一个新的线程负责将数据写入到文件，原来的线程只负责接收数据。当接收数据的线程收到一副图像的最后一个包时，马上置位相应变量，另一个线程不断检查该变量，条件满足时将数据写入到文件。其实这种轮询的方式也很耗费CPU资源，最好的办法是用事件（Event）来同步，不过这个版本的结果就很完美了，基本上没有丢失包，我就没有继续改进了。
下面是我的源代码：
bool IsNewImageReceived = false;
uint32_t GetImageNo(char data[PACKSIZ]);
uint16_t GetBlockNo(char data[PACKSIZ]);
static HANDLE g_hMutex = INVALID_HANDLE_VALUE;
HANDLE hThread = INVALID_HANDLE_VALUE;
DWORD WINAPI Thread_fcn(LPVOID lpParameter);
int main()
int nRecvBuf = 38400 * 1024;
if (setsockopt(s, SOL_SOCKET, SO_RCVBUF, (const char *)&nRecvBuf, sizeof(int)) == -1) {
printf("Set receive buffer size failed\n");
exit(EXIT_FAILURE);
hThread = CreateThread(NULL, 0, Thread_fcn, NULL, 0, NULL);
g_hMutex = CreateMutex(NULL, FALSE, L"Mutex");
for (;;) {
if ((recvfrom(s, packetData, PACKSIZ, 0, (struct sockaddr *)&si_other, &slen)) == SOCKET_ERROR) {
printf("recvfrom() failed with error code : %d", WSAGetLastError());
exit(EXIT_FAILURE);
uint32_t imageno = GetImageNo(packetData);
WaitForSingleObject(g_hMutex, INFINITE);
if (imageno != curr_imageno) {
prev_imageno = curr_
curr_imageno =
swap(ptr_write, ptr_read);
IsNewImageReceived = true;
pack_cnt++;
ReleaseMutex(g_hMutex);
uint16_t blockno = GetBlockNo(packetData);
uint32_t offset = (blockno - 1) * BLKSIZ;
memcpy(ptr_read+offset, packetData + 12, BLKSIZ);
closesocket(s);
WSACleanup();
DWORD WINAPI Thread_fcn(LPVOID lpParameter)
for (;;) {
WaitForSingleObject(g_hMutex, INFINITE);
if (IsNewImageReceived) {
IsNewImageReceived = false;
pack_cnt = 0;
stringstream
ss && prev_
string filename = path + string("image") + ss.str() + string(".raw");
ReleaseMutex(g_hMutex);
ofstream fout(filename.c_str(), ofstream::binary);
if (!fout) {
cerr && "Failed to open file!" &&
fout.write(ptr_write, FILESIZ);
fout.close();
memset(ptr_write, 0, FILESIZ);
ReleaseMutex(g_hMutex);
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！一般都怎么处理
[问题点数：40分，结帖人u]
本版专家分：0
结帖率 97.62%
CSDN今日推荐
本版专家分：0
本版专家分：0
本版专家分：0
结帖率 97.62%
本版专家分：0
本版专家分：0
结帖率 97.62%
匿名用户不能发表回复！|
CSDN今日推荐}