- 综合排序
- 最热优先
- 最新优先
- 来自专栏腾讯云网络专家服务
服务器外网丢包怎么办？
如果您发现本地ping腾讯云服务器有异常，访问服务器存在连接耗时增大或无法连接等问题。
5.3K100发布于 2020-11-04 - 来自专栏星星
购买腾讯云服务器后，外网访问丢包，如何解决？
腾讯云 (tencent.com)的时候，对于网络方面，一就是考虑带宽，二就是考虑服务器所在的地理位置与大部分用户访问云服务器所在的位置；那么当我们的用户或者是自己在访问云服务器的时候，进行ping发现有丢包 地理位置问题 国内用户访问国内云服务器场景 如果服务器在国内，用户也在国内，并且带宽没有超限，机器性能正常，但是有丢包情况，这个时候需要使用MTR工具进行异常丢包的测试信息收集 1542554531907-5bdbd634-0149-4306-834a-3061f1db5db5.png] 收集好相关的测试信息后，可以根据下面的链接进行简单的分析网络延迟及丢包 云服务器 使用 MTR 分析网络延迟及丢包 - 故障处理 - 文档中心 - 腾讯云 (tencent.com) 如果客户端到服务器端，MTR测试信息前三跳没有丢包，但是到云服务器IP 的最后一跳有丢包，这时候就可以提供你收集好的正反向测试截图以及文本测试信息（这里我们信息给全了，也方便人家快速给我们处理），提交工单处理即可。
18.3K91发布于 2021-09-10 - 来自专栏FreeSWITCH中文社区
模拟丢包测试
今天，帮客户调试一个FreeSWITCH媒体问题，需要模拟丢包测试一下。 首先，FreeSWITCH在公网上，客户端在NAT环境中。我们先用客户端呼叫9196。呼通后可以听到自己的回音。 FreeSWITCH解决这类NAT问题的办法就是等待客户端给它发送RTP包。收到后便能“学习”到客户端的外网IP地址和端口号。 Auto Changing port from 192.168.7.6:50432 to 112.238.196.224:50432 好了，知道了客户端的IP和端口以后，我们就可以用iptables模拟丢包了 表示，所有发往IP 112.238.196.224和端口50432的包，8%的直接丢掉不发。 上面的例子是模拟FreeSWITCH发送时丢包。 在实际使用中，有时也会模拟FreeSWITCH接收端丢包，可以用类似如下的命令来实现： iptables -A INPUT -p udp —src 112.238.196.224 —sport 50432
3.5K22发布于 2020-12-21 - 来自专栏FunTester
网络丢包与 HTTP 性能
丢包的那些事儿 丢包，顾名思义，就是网络传输中数据包“丢了”，没能顺利到达目的地。 HTTP 协议跑在 TCP/IP 协议栈上，丢包可能发生在网络层，比如路由器忙不过来直接丢包，或者传输层，比如 TCP 重传机制出了岔子。 丢包如何卡住吞吐量 丢包不仅拖慢速度，还让吞吐量“吃瘪”。TCP 的拥塞控制算法把丢包当网络拥堵的信号，立马缩小发送窗口，数据发送速度直线下降。重传还得占用带宽，挤占有效数据的“地盘”。 比如，QUIC 能只重传丢包的流，不影响其他流，还用 0-RTT 连接建立减少初始延迟，面对丢包更“抗揍”。 故障测试丢包率的最佳实践 故障测试中，设置丢包率得“量体裁衣”，结合业务场景和云厂商的承诺。主流云厂商（比如阿里云、AWS）通常保证丢包率低于 0.1%，高端服务甚至低到 0.01%。
1.3K10编辑于 2025-04-27 - 来自专栏网络工程师笔记
流量丢包如何定位解决？
后台回复“网络工程师”获取计算机网络资料 1 故障现象 丢包率是衡量网络质量的指标之一，可是我们在网络中经常会遇到数据丢包的问题，平时生活中我们看视频发现有卡顿画面不清晰的是否很大一部分原因是丢包了， 那么如何解决网络丢包问题呢？ 4 总结 如何解决丢包的问题呢？ 可能是接口链路的问题，流量是否超过接口带宽； 第二种是数据链路层的问题，确认是否存在二层环路导致广播风暴； 第三种网络层的问题，确认是否存在路由配置问题，是否存在ARP表项错误； 在处理流量丢包时
4.4K40发布于 2021-05-17 - 来自专栏云服务使用个人总结
dropwatch 工具分析网络丢包
activated.Issue Ctrl-C to stop monitoring1 drops at skb_queue_purge+18 (0xffffffff92a42868)........案例一iptables 导致丢包
3.1K60编辑于 2022-08-25 - 来自专栏用户10998956的专栏
蓝牙信标丢包率分析
造成“丢包”（即接收不到部分广播包）的原因是多方面的，主要可以从以下几个层面来解释：一、 核心原因：蓝牙扫描的“被动监听”机制手机上的标准蓝牙扫描（特别是在App层面）是被动、非连续的。 · 扫描去重：系统层或SDK层可能会对短时间内收到的相同UUID、相同Major/Minor的信标广播包进行去重，以避免应用层收到过多重复数据，这也会让您感觉“包变少了”。四、 协议与应用层因素1. 您的应用程序绝对不能依赖“收到每一个包”。正确的设计应该是：· 基于信号强度（RSSI）和“最近收到包的时间”来判断距离和存在。 · 使用移动平均、卡尔曼滤波等算法来平滑RSSI值，避免因单次丢包或RSSI跳动导致判断失误。· 设置合理的超时时间（例如，3-5秒没收到包才认为信标已远离）。 结论您观察到的“丢包”是预期内的正常现象，而非故障。这是由于无线通信的不确定性、手机系统的功耗管理策略以及蓝牙协议本身的工作机制共同导致的。在实际应用中，20%甚至更高的丢包率都是常见的。
8310编辑于 2026-03-19 - 来自专栏玉龙小栈
HCIE数通丢包排错思路。
HCIE面试中有一道项目题，网络中发生丢包行为的排查思路和具体实施方法: 回答总体思路： 1、 先确定是否发生丢包以及哪些设备访问的时候会发生丢包； 当发现设备访问某一网段时有丢包，可以先在多台设备上去 ping 目的网段的周围的多个网段（类似于诊断六那样），用于确定是何种流量丢包还是所有流量都会丢包； 如果是具体一种流量丢包的话可以确定为做了路由策略或者策略路由（类似诊断六，带源不能通，不带源就行） ； 如果是多种流量都丢包，造成的原因就可能很多，物理层、数据链路层、网络层以及策略路由都有可能； 2、判断丢包位置； 方法有两种： 第一种：使用 ping 和 tracert 一段一段测试，先 ping 网关，然后是网关的下一跳，一直到目的地址，或者用 tracert 跟踪可以确定具体在哪一跳丢包；这种方法简单，但较为粗糙一些，因为丢包可能是间歇性的，需要多次ping 和tracert，测试多次。 如果端口a入方向和端口b 出方向 Passed 计数大致相等，说明此处无丢包。
3.6K42发布于 2021-02-24 - 来自专栏流媒体音视频
WebRTC丢包重传大解密
目录 概述 NACK 问题一、数据包真丢了，会一直重传吗？ 问题二、重传次数不到最大限制次数，就会一直等待吗？ 问题三、当大量丢包时，会全部重传吗？ 概述 WebRTC之所以可以优秀的完成音视频通讯，和它本身的丢包重传机制是密不可分的，今天我们就来看看其中的奥秘。 本文以M76版本展开，如果你的工程是基于其他版本开发的，也可以参考。 NACK 说到丢包重传就不得不提到NACK技术，那么NACK是什么呢。 ACK表示通知对方我收到了你发给我的数据包，NACK表示通知对方我没有收到你发给我的数据包。 那么问题来了，为什么会导致对方明明发送了响应的数据包，而我没有收到呢？ 问题三、当大量丢包时，会全部重传吗？ 答案是否定的。因为WebRTC不仅限制了重传包的次数，而且还限制了重传包的个数。WebRTC每次要求重传包的个数默认是1000个。
4.4K20发布于 2021-06-29 - 来自专栏火丁笔记
SYN丢包的几个例子
如果出现 SYN 丢包，那么将导致严重的性能问题，如果没有严重到完全连不上，那么在延迟时间上会表现出明显的时间特征，比如：1秒，3秒，7秒，15秒，31秒，具体可以参考：「SYN和RTO」，本文不说这个 ，就说说哪些情况会出现 SYN 丢包。 过小的 unres_qlen 设置： 关于此原因的描述，我直接摘录蘑菇街技术博客中的相关描述，可惜的是相关文章现在已经下线了，大家有兴趣的可以访问国外网站通过 archive.org 来浏览。
2.4K20编辑于 2021-12-14 - 来自专栏网络技术联盟站
交换机丢包问题定位
诊断工具 display工具 二层转发丢包故障 定位思路 定位步骤 三层单播转发丢包故障 定位思路 定位步骤 诊断工具 display命令行 ? 二层转发丢包故障 定位思路 ? 第一步：判定丢包设备 1.根据流量转发路径，在流量的入接口和出接口分别配置流量统计。 ? 2.查看入接口和出接口的流量统计，以确认是否在本设备产生丢包。 如果出接口流量统计值与入接口流量统计值相等，则说明非本设备丢包；如果出接口流量统计值小于入接口流量统计值，则本设备丢包。 ? 三层单播转发丢包故障 定位思路 ? 第一步：确认丢包点 确认是否交换机产生丢包，依然采用流量统计的方法，参见“二层转发丢包”流量统计相关部分，此处不再赘述。 第三步：检查端口和链路 第四步：检查出端口是否存在拥塞 第三步、第四步与“二层转发丢包”相关部分一致，此处不再赘述。
5.1K20发布于 2020-05-26 - 来自专栏FreeSWITCH中文社区
记一次丢包分析
笔者当场就吃惊了，明明局域网内通信，为何视频有10%的丢包。 ? 然后笔者首先验证的是第四种，应用内丢包。这里先说一下笔者的测试场景: 192.168.0.103是FreeSWITCH的ip。192.168.0.102是软电话的ip。 很明显，FreeSWITCH已经将包发出了，但是抓包中却没有。可以排除应用内丢包了。 分析到这里，貌似只有“UDP buffer size不足”这个原因比较可疑了。 分析到这里，笔者开始怀疑，是不是通话根本没有丢包，但是tcpdump由于自己的原因没有抓到包，因此“显示的丢包”。 不知道大家在抓包结束后，有没有观察过tcpdump的输出。反正笔者是从来没有注意过。 经过测试，wireshark确实没有“丢包”了。 ? ? tcpdump默认的buffer大小为2MB，这对于抓取视频包来说远远不够，因此，加上-B很有必要。
4.2K30发布于 2020-12-21 - 来自专栏隐身
怎么排查linux系统网络丢包
要排查Linux系统网络丢包问题，可以按照以下步骤进行： 1. 确认网络丢包问题是否存在。可以使用ping命令测试网络连接并查看是否出现丢包情况。 可以通过/sys/class/net/<网络设备>/statistics目录查看网络设备的统计信息，例如查看接收包的丢弃数量。如果出现了大量的丢弃，可能需要调整内核参数。 5.
4.6K10编辑于 2023-12-12 - 来自专栏全栈程序员必看
UDP发送大型文件_不丢包
先上图 1：如果对文件要求不高的话 ，可以使用UDP，UDP在实际测试中，丢包还是听验证的，但是效率高 2：如果文件必须完整，还是使用TCP 。 ，我也是这样想的 ，素不知线下的网络的环境 有多差，当时一个业务员和我说，要是能实现手机发送文件给设备就好了，毕竟大家都是用手机的，不然太浪费时间了 ，因为当时用的是腾讯的Im来实现即时通讯的，利用外网来发送文件 ， 那么问题就来了 ，这么大 ，要多久才能发完 ，那就用局域网来发送文件吧 ，第一个想到的就是UDP来实现 ，测试中发现DUP丢包问题特别明显，当时死活都找不到原因 ，后来把发送的次数和接受的次数对比打印了一下 丢包 } if (dataPacket !
6K20编辑于 2022-09-14 - 来自专栏网络虚拟化
vpp遇到接口丢包如何解决？
源码：/src/plugins 二、VPP丢包统计分析 下面我们言归正传，介绍VPP的丢包统计分析。 在show interface 统计接口流量的时候，应该关注哪些统计字段呢？ 在dpdk插件中统计字段的描述如下所示：vpp/src/plugins/dpdk/device/format.c 其中 tx 方向的丢包：tx errors ；rx 方向的丢包 rx missed 分别对应了 ）、tx error（发送侧丢包）丢包； 在对以上三个统计量进行展开介绍之前有必要介绍一下DPDK对数据包的处理流程。 rx_nombuf rx_nombuf记录在读取数据包时分配mbuf错误的次数，一般情况下不会影响网卡的丢包（imissed、ierrors）。该变量的维护在rx_recv_pkts中。 如何解决丢包问题： imissed 收包侧丢包 如上所述imissed表示从网卡到内存写入数据包时的丢包个数，因此需要从以下2个方面进行调试： 1、判读PCIe是否存在瓶颈 因为报文从网卡到系统是经过PCIe
4.6K10编辑于 2023-03-30 - 来自专栏云计算运维
linux 系统 UDP 丢包问题分析思路
如果看到对应的数字在不断增长，就说明网卡有丢包。 如果有少量的丢包很可能是预期的行为，比如丢包率（丢包数量/接收报文数量）在万分之一甚至更低。 网卡或者驱动丢包 如果 ethtool -S eth0 中有 rx_***_errors 那么很可能是网卡有问题，导致系统丢包，需要联系服务器或者网卡供应商进行处理。 Linux 系统丢包 linux 系统丢包的原因很多，常见的有：UDP 报文错误、防火墙、UDP buffer size 不足、系统负载过高等，这里对这些丢包原因进行分析。 当然，也可以在应用层做重试、去重保证可靠性 如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失 如果系统负载过高，UDP 丢包是没有有效解决方案的。
8.1K42发布于 2021-08-27 - 来自专栏CU技术社区
Linux 系统 UDP 丢包问题分析思路
如果看到对应的数字在不断增长，就说明网卡有丢包。 如果有少量的丢包很可能是预期的行为，比如丢包率（丢包数量/接收报文数量）在万分之一甚至更低。 网卡或者驱动丢包 之前讲过，如果 ethtool -S eth0 中有 rx_***_errors 那么很可能是网卡有问题，导致系统丢包，需要联系服务器或者网卡供应商进行处理。 Linux 系统丢包 linux 系统丢包的原因很多，常见的有：UDP 报文错误、防火墙、UDP buffer size 不足、系统负载过高等，这里对这些丢包原因进行分析。 当然，也可以在应用层做重试、去重保证可靠性 如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失 如果系统负载过高，UDP 丢包是没有有效解决方案的。
17.3K31发布于 2020-06-03 - 来自专栏全栈程序员必看
一个客户的丢包问题
网络丢包是我们在使用ping对目站进行询问时，数据包由于各种原因在信道中丢失的现象。ping使用了ICMP回送请求与回送回答报文。 网络丢包的原因主要有物理线路故障、设备故障、病毒***、路由信息错误等，下面我们结合具体情况进行说明。 由物理线路引起的丢包现象还有很多，如光纤连接问题，跳线没有对准设备接口，双绞线及RJ-45接头有问题等。 设备故障 设备故障主要是指设备硬件方面的故障，不包含软件配置不当造成的丢包。 但此类丢包属于正常情况下的丢包，是意料之中的，不会对网络造成影响。
1.7K40发布于 2021-08-10 - 来自专栏IT创事记
人工智能，不许网络再丢包
在丢包率为0.1%的传统以太网中，我们生活安然，并无不适。而现在，人工智能（AI）带来的数据量激增改变了这一切。 那些以太网曾经看来微不足道的“苟且”开始变得如鲠在喉，它让人们越来越无法忍受。 一项实测支持的业务观察显示，因为AI业务带动的数据量高速增长，0.1%的以太网丢包率会导致AI的计算力损失约50%——面向AI，在计算和存储领域已经取得突破之后，这一现实让网络设备供应商感受到了前所未有的压力 针对这一问题，华为网络产品线总裁胡克文认为，面向AI的未来，网络设备应该做到“强制性”的零丢包。 每家ICT厂商都是努力做着同一件事情，生产出这类适应AI需求的网络设备，全球范围概莫能外。 CloudEngine 16800发布现场 这款业界首款面向AI时代的计算中心交换机，可以借助其实时学习训练能力和独创的iLossLess智能无损交换算法，在以太网中实现零丢包机制，并实现流量模型的自适应自优化 和解决丢包问题一样，华为将问题“交还”给了AI，期待自动驾驶网络能够彻底改变运维人员面对的窘境。
2K20编辑于 2022-06-17 - 来自专栏腾讯技术工程官方号的专栏
内核调试技巧--systemtap定位丢包原因
作者：wqiangwang，腾讯 TEG 后台开发工程师 内核收发包，可能会由于backlog队列满、内存不足、包校验失败、特性开关如rpf、路由不可达、端口未监听等等因素将包丢弃。 在内核里面，数据包对应一个叫做skb(sk_buff结构)。当发生如上等原因丢包时，内核会调用***kfree_skb***把这个包释放（丢掉）。 builtin_return_address(0)记录下了调用kfree_skb的函数地址并传给location参数，因此可以利用systemtap kernel.trace来跟踪kfree_skb获取丢包函数 考虑到该丢包函数可能调用了子函数，子函数继续调用子子函数，如此递归。为了揪出最深层的函数，本文通过举例几个丢包场景，来概述一种通用方法，来定位丢包原因及精确行号。 总结，丢包精确定位行的方法： 1、 drop_watch先定位函数。 2、 使用pp()定位行。必要的时候，编写一些脚本，直接抄写内核代码或者调用stap库就可以了。 3、 递归重复步骤1和2。
4.2K30发布于 2021-04-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号