Jump The Great Firewall【step16 优化丢包率】

一、为何会丢包

经过博主长期使用的经验所得,使用UDP协议在互联网上传输数据时,存在一定的丢包率。尤其是在晚间繁忙时段,丢包率更为明显,那么我们如何进行优化来降低丢包率呢?

二、如何解决

  1. 服务器端与客户端同时进行校验,在一定时间内如果发现有丢包时,发送一条新的消息通知对方重新发送该条消息
  2. 服务器端与客户端在发送消息时,每次都将一条消息发送多次

我们先来看下第一种方案:这种方案属于最传统的方式,不过该方法有一个缺点。当网络状况非常差时,发出去的请求重发消息也可能会丢失,因此对端可能会再次请求丢失的那个请求重发的报文。与TCP类似,这将导致整个网络变的更差。

让我们来看下第二种方案:对于每一条消息,两端都进行了多次的发送,理论上整体带宽将被降低。在网络状况不好的情况下,假设一条消息我们发送5次,实际上并不会这么巧合的这5次都被丢包了。因此我更倾向于这个方案,在实际测试过程中我们发现带宽并没有降低,反而下载文件的速度比以前更稳定了。

三、如何实现

    1. 首先修改最底层的发包函数write_c

      ssize_t write_c(client_t* client, const void* buf, size_t count) {
          unsigned char i;
          unsigned char successed = 0;
          for (i = 0; i < qtun->multi_send; ++i) {
              if (qtun->use_udp) {
                  if (sendto(qtun->remotefd, buf, (int)count, 0, (struct sockaddr*)&client->addr, sizeof(client->addr)) >= 0)
                      ++successed;
              } else {
                  const char* ptr = buf;
                  size_t left = count;
                  while (left) {
                      ssize_t written = write(client->fd, ptr, (unsigned int)left);
                      if (written == 0)
                          return 0;
                      else if (written == -1) {
                          if (errno == EAGAIN || errno == EWOULDBLOCK) continue;
                          return -1;
                      }
                      ptr  += written;
                      left -= written;
                  }
                  ++successed;
              }
          }
          return count;
      }

      这里我们根据配置文件中的multi_send参数来决定要发送多少次,在TCP模式中multi_send参数总是为1

    2. 我们定义一个msg_state_t结构来保存每一个收到的消息
      typedef struct {
          unsigned int   ident;
          unsigned short idx;
          unsigned char  used;
      } msg_state_t;
      
    3. 在client_t结构中我们总是记录MSG_MAX_TTL条收到的消息id
          msg_state_t        recv_msgs[MSG_MAX_TTL];
      
    4. 在收到一条消息时,我们需要优先检查对应client_t结构中的recv_msg表内是否已记录了该消息的序号,如果该表中已包含了该消息的序号,则需要将该消息丢掉

四、增强安全性

为了增强安全性,在新版本中qtun默认禁止局域网内与其他主机通信,通过在配置文件中指定use_local_forward标志来开机局域网内的通信。具体的实现方法为:在server_process函数中检查数据包的源地址与目的地址是否都为当前局域网内的,如果都是当前局域网内的数据包,则直接进行丢包

            if (!qtun->use_local_forward &&
                check_ip_by_mask(ipHdr->saddr, qtun->localip, qtun->netmask) &&
                check_ip_by_mask(ipHdr->daddr, qtun->localip, qtun->netmask)) {
                return;
            }

五、完整代码

完整代码可到step16中查看

版本号:1.1.0

日期:2015-06-13

时间: 2024-10-01 07:44:37

Jump The Great Firewall【step16 优化丢包率】的相关文章

TCP BBR算法的带宽敏感性以及高丢包率下的优化

bbr算法比较简单也比较容易理解,所有关于它的优化也就同样不复杂了.        请注意,任何优化都只针对特定场景的,根本不存在一种放任四海而皆准的算法.我们分析Google的测试报告时,比较容易被忽视的是其bbr算法的部署场景.如果可以完美复现Google的B4网络,那么测试结果应该就跟Google是一致的,但不得不说,bbr算法内置了很多的参数(目前的版本中是写死的),Google方面有没有调整这些参数是未知的.我们先看一下bbr算法是怎么利用空余带宽的.        bbr算法最终会稳

zabbix使用fping监控任意两个节点之间的网络质量、丢包率和响应时间

zabbix使用fping监控任意两个节点之间的网络质量.丢包率和响应时间 之前的博文 使用zabbix3.0.4的ICMP Ping模版实现对客户端网络状态的监控 https://www.cnblogs.com/reblue520/p/6832059.html 只能监控zabbix server到zabbix_agent之间的网络情况,不能监控任意两点间的网络情况 此次的方法可以监控任意两点之间的网络情况 需求: mysql主从之间同步经常会延迟,为了查看是否网络问题,先添加两个节点之间的网络

使用mtr测试网络丢包率和平均延时的脚本实例

mtr(a network diagnostic tool)是一个神奇的指令,能按要求对路由中所有节点进行批量测试.简单敲一个"mtr qq.com"将会有意外收获! 当需要进行产品级的网络测试时,可在服务器上运行一段时间的mtr测试形成报告.如下脚本: #!/bin/bash# 测试网络丢包率和平均延时,注意变量clr和cdt的赋值,不同版本的mtr对应的字段位置不同# 脚本在CentOS 6.2 Linux 2.6.32-220.el6.x86_64 mtr v0.75 上测试通过

无线路由器wds桥接技术+丢包率

半根毛线http://www.cnblogs.com/hsd-/ 今天下午鼓捣了一下无线路由的wds桥接 算是计算机网络的作业 码来分享一下 1.首先设置主路由 我的主路由是斐讯4线 路由ip为192.168.2.1 就是简单的路由配置 在此不赘述 2.其次是副路由 副路由的ip为192.168.2.2  注意副路由ip应该与主路由的ip在一个频段 选择信道应当与主路由相同 3.勾选wds功能 大部分的路由器都有 4.点击扫描 找到主路由 连接 密钥为主路由的密码 5.查看是否wds设置成功 6

让zabbix监控路由器丢包率和网络延迟

克隆zabbix自带的Template ICMP Ping模板 在这里我做一个到 202.96.209.5上海DNS 的网络延迟模板 分别修改监控项的键值icmppingloss[202.96.209.5] icmpping[202.96.209.5] icmppingsec[202.96.209.5] 4. 创建监控项    icmppingloss 对应的是网络丢包率 icmppingsec  是网络延迟 相应主机添加自己克隆的这个模板可以就可以了

用ping命令简单的测试 延时、抖动、丢包率

在DOS命令状态下输入 :ping 202.105.135.211 -t (连续的对该IP地址执行Ping命令,直到被用户以Ctrl+C中断)就会得到下面的结果:Pinging 202.105.135.211 with 32 bytes of data:Reply from 202.105.135.211: bytes=32 time=93ms TTL=42Reply from 202.105.135.211: bytes=32 time=86ms TTL=42Reply from 202.10

AR8033 1000M模式下ping包丢包率过大分析与解决

1 现象 近期对一款基于QCA方案.有线Phy为AR8033.WiFi双频且支持iEEE802.11AC的WLAN产品进行了深度验证,发现有线口同部分PC机直连时,WiFi终端ping 该PC机时总是丢包,有时高达20%:但通过交换机再接PC机时,又不会丢包.一直以为是偶现,所以未引起重视,反正跑流性能与稳定性都没有任何影响.后来新购了一批千兆有线口的便携机进行配套验证时,发现每台都是如此,ping包丢得一塌涂地.在WLAN设备和PC机上分别开启抓包工具,可以看到设备已发包,但PC机未收到报文:

WireShark 查看UDP码流的丢包率

1.用wireshark抓包之后,右击,点decode as,转化为RTP 2. 点show all streams 3.分析 原文地址:https://www.cnblogs.com/Johar/p/10241546.html

ping测试丢包率

测试环境:Centos 6.4 增加参数:-i 例如: #ping -i 0.01 172.16.3.1 则每隔0.01秒ping一次