admin管理员组文章数量:1565841
2024年3月17日发(作者：)
干扰问题
1.降低物理数据传输率；
降低AP的数据传输速率并不能达到预期的效果。数据包滞空时间变得更长，
这意味着需要花费更多的时间进行接收，因此掉包的几率更大。这反而让他们对
周期性干扰更为敏感。这一解决办法基本上没什么效果，这导致所有共用这一
AP的用户都受到了影响。
2.减少受干扰AP的传输功率；
这需要减少共用同一个AP的设备的数量，这样做可以提高性能。但是降低
了传输功率也会降低信号的接收强度。这就变成了降低数据传输率，同时wifi
覆盖将出现漏洞。这些漏洞需要使用更多的AP进行填补。可以想象，增加AP
的数量将会导致更多的干扰。
3.调整AP的信道分配。
干扰通常都具有间歇性和变化无常的特点，由于可供改变的信道数量有限，
这一技术反而会带来更多的问题。AP改变信道需要连接的客户端断开连接，重
新进行连接。
在设备使用相同的信道或是无线电频率传输和接收wifi信号时，这些设备会
彼此干扰，这种干扰称为通信到干扰。
希望：更强的信号和更少的干扰。
预测wifi系统性能如何的通用单位是信噪比（SNR）。SNR显示了接收信号
的强度与底噪的差值。通常在高SNR的情况下，极少出现误码，吞吐量也较高。
但是随着干扰的出现，还需要考虑信号与干扰和噪声比（SINR）。
SINR是信号与干扰之间的差值。高SINR意味着碰上跟高的数据传输率和更
强的频谱性能。为了取得高SINR值，wifi系统个必须要增强信号增益或是减少
干扰。
/*****************************************************************************/
UDP丢包问题
1.发送频率过高导致丢包
很多人会不理解发送速度过快为什么会产生丢包，原因就是UDP的SendTo
不会造成线程阻塞，也就是说，UDP的SentTo不会像TCP中的SendTo那样，直
到数据完全发送才会return回调用函数，它不保证当执行下一条语句时数据是否
被发送。（SendTo方法是异步的）这样，如果要发送的数据过多或者过大，那么
在缓冲区满的那个瞬间要发送的报文就很有可能被丢失。至于对“过快”的解释，
作者这样说：“A few packets a second are not an issue; hundreds or thousands may
be an issue.”（一秒钟几个数据包不算什么，但是一秒钟成百上千的数据包就不
好办了）。 要解决接收方丢包的问题很简单，首先要保证程序执行后马上开始监
听（如果数据包不确定什么时候发过来的话），其次，要在收到一个数据包后最
短的时间内重新回到监听状态，其间要尽量避免复杂的操作（比较好的解决办法
是使用多线程回调机制）。
2.报文过大丢包
至于报文过大的问题，可以通过控制报文大小来解决，使得每个报文的长度
小于MTU。以太网的MTU通常是1500 bytes，其他一些诸如拨号连接的网络MTU
值为1280 bytes，如果使用speaking这样很难得到MTU的网络，那么最好将报
文长度控制在1280 bytes以下。
3.发送方丢包
发送方丢包：内部缓冲区（internal buffers）已满，并且发送速度过快（即
发送两个报文之间的间隔过短）； 接收方丢包：Socket未开始监听； 虽然UDP
的报文长度最大可以达到64 kb，但是当报文过大时，稳定性会大大减弱。这是
因为当报文过大时会被分割，使得每个分割块（翻译可能有误差，原文是
fragmentation）的长度小于MTU，然后分别发送，并在接收方重新组合
（reassemble），但是如果其中一个报文丢失，那么其他已收到的报文都无法返
回给程序，也就无法得到完整的数据了。
版权声明：本文标题：gwifi干扰和udp丢包问题 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://www.elefans.com/dianzi/1710651229a276483.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论