qos

服务质量QoS（Quality of Service）用于评估服务方满足客户服务需求的能力。通过配置QoS，对企业的网络流量进行调控，避免并管理网络拥塞，减少报文的丢失率，同时也可以为企业用户提供专用带宽或者为不同的业务（语音、视频、数据等）提供差分服务。 网络带宽： 网络带宽是指在单位时间（一般指的是1秒钟）内能传输的数据量。 网络时延： 传输时延：一个数据位从发送方到达接收方所需要的时间。该时延取决于传输距离和传输介质，与带宽无关。 串行化时延：指发送节点在传输链路上开始发送报文的第一个比特至发完该报文的最后一个比特所需的时间。该时延取决于链路带宽以及报文大小。 处理时延：指路由器把报文从入接口放到出接口队列需要的时间。它的大小跟路由器的处理性能有关。 队列时延：指报文在队列中等待的时间。它的大小跟队列中报文的大小和数量、带宽以及队列机制有关。 抖动： 丢包： 丢包率是指在网络传输过程中丢失报文占传输报文的百分比。丢包可用于衡量网络的可靠性。 丢包（packetloss）可能在所有环节中发生，例如： 处理过程：路由器在收到报文的时候可能由于CPU繁忙，无法处理报文而导致丢包； 排队过程：在把报文调度到队列的时候可能由于队列被装满而导致丢包； 传输过程：报文在链路上传输的过程中，可能由于种种原因（如链路故障等）导致的丢包。 少量的丢包对业务的影响并不大，例如，在语音传输中

目前总结出webrtc用于提升QOS的方法有： 1、NACK 2、FEC 3、PACER 4、降帧率 5、降码率 也许还有其他，待后续知识更新后，补充。 一、NACK原理介绍 接收端根据收到报文的丢包情况，把丢包的SEQ记录在RTCP报文里面，发给发送端，请求重发。 若在JB时长内，收到重发数据，就补上了。 二、FEC原理介绍 FEC是发送端在发送的时候，将之前的旧包也打包到新包里面，若接收端有丢包，就用新包里面冗余的旧包恢复数据。 说到这里大家可能认为这就是RFC2198冗余嘛。但是在webrtc里面，这不是简单的RFC2198冗余。 RFC2198冗余带宽占有量是倍增，简单冗余，对网络差的情况是恶化。FEC是有一套算法，仅冗余部分关键帧。 三、PACER原理介绍 PACER，是网络报文平滑策略。根据RTCP反馈的环路延时和丢包，对当前网络有个预判。然后把要发送的报文拆分成小包，按照一定的节奏慢慢发。 四、降帧率原理介绍 降帧率也是根据RTCP反馈的环路延时和丢包，对当前网络有个预判。当判断出当前网络质量比较差，通过不断的降低帧率，减少带宽的占用量。 五、降码率原理介绍 同理，降码率同样是根据RTCP反馈的环路延时和丢包，对当前网络有个预判。当判断出当前网络质量比较差，通过不断的降低码率，减少带宽的占用量。 这五种方法实现的细节，待续。。。。。 文章来源: webrtc

https://blog.csdn.net/bc_vnetwork/article/details/53221061 QOS的配置 使系统支持qos的配置： 1.修改neutron-server的neutron.conf配置 # vim /etc/neutron/neutron.conf service_plugins = neutron.services.qos.qos_plugin.QoSPlugin 2.修改neutron-server的ml2_conf.ini配置 # vim /etc/neutron/plugins/ml2/ml2_conf.ini [ml2] extension_drivers=qos 3.修改ovs-agent配置 # vim /etc/neutron/plugins/ml2/ml2_conf.ini [agent] extensions=qos 4.配置policy.json使所用用户都有使用qos策略的权利（以下配置均为默认，可不配置） # vim /etc/neutron/policy.json "get_policy": "rule:regular_user", "create_policy": "rule:regular_user", "update_policy": "rule:regular_user", "delete_policy":

MQTT介绍： http://mqtt.org 服务器端 https://mosquitto.org/download/ PHP客户端 https://github.com/bluerhinos/phpMQTT MQTT QOS等级订阅和发布的关系 https://www.jianshu.com/p/ebe4b2c0461d qos ＝ 0：仅发一次，不管是否能收到 qos ＝ 1：没返回一直发，可能有重复接收（接收到消息可能未传递给客户端） qos ＝ 2：保证必须收到，并且不重复（使用MSG_ID保证不重复接收） 也就是服务器只会按pub和sub两者qos等级最小的那个qos规则来发送消息。 pub时指定的qos是服务器肯定按此规则接收，但是最终订阅者不一定。 sub时指定的qos表示订阅者可以接收的最高消息等级，也就是可能收到更低等级的消息。 遇到的问题 消息发布 <?php require("../phpMQTT.php"); $server = '127.0.0.1'; // 服务器IP $port = 1883; // 服务器端口 $username = ''; // 用户名 $password = ''; // 密码 $client_id = 'pub_' . uniqid(); $mqtt = new Bluerhinos\phpMQTT($server,

CN2 全称为中国电信下一代承载网，英文Chinatelecom Next Carrier Network，缩写为CNCN，进一步缩写为CN2。 CN2线路的优势在哪里 CN2作为“精品网络项目”被提出来，其技术构造是远远领先于电信原有网络的，极为先进的QOS保证网络的畅通性，具体可参考资料。当然除了先进的技术，其昂贵的价格和对大量网络资源的独占性也是重要的原因，资料。普通家庭宽带用户用不上CN2线路，哪怕加几倍的钱也不一定能用上，而接入CN2线路机房的VPS，价格卖得比其他线路的高很多。用户少，服务器少，分配的独享资源多，这样就能保证绝大多数情况下CN2线路的流畅性。 三种承载网络的对比 提到CN2，我们还不得不提到老一代的163骨干网，而CN2本身又分为两种类型，所以，我们在这里把这三者逐一对比一下： 普通163: 就是电信用户最经常遇到的电信线路，等级最低，省级/出国/国际骨干节点都以202.97开头，全程没有59.43开头的CN2节点。在出国线路上表现为拥堵，丢包率高。 CN2 GT: CN2里属于Global Transit的产品(又名GIS-Global Internet Service)，在CN2里等级低，省级/出国节点为202.97开头，国际骨干节点有2～4个59.43开头的CN2节点。在出国线路上拥堵程度一般，相对于163骨干网的稍强，相比CN2 GIA

<?xml version="1.0" encoding="UTF-8"?> <configuration> <property name="LOG_PATTERN" value="[ %-5level] [%date{yyyy-MM-dd HH:mm:ss}] %logger{96} [%line] - %msg%n"/> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern> ${LOG_PATTERN} </pattern> <charset>UTF-8</charset> </encoder> </appender> <appender name="FILE-INFO" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_PATH}/info.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_PATH}/info-%d{yyyyMMdd}.log.%i </fileNamePattern>

在Rabbitmq有大量的unack,会极度影响Rabbitmq的性能,因为这些消息消费不出去,反复消费回退刷盘,设置消费者端的qos就可以避免这个问题. 未设置QOS = 1 设置QOS = 1 产生unack的原因:在队列里面取消息消费,在消费者端认为这个消息异常,会反复的回退在消费(一般有消费逻辑),这时候极度影响性能,可以根据TTL去处理(不建议,因为后续的消息会被误过期)或者根据死信队列.根据消息的类型可以定制消息是否删除,是否进入死信,进入死信那个队列. 来源： CSDN 作者： Michael_曾浩 链接： https://blog.csdn.net/qq_29778131/article/details/52537136

https://www.jianshu.com/p/47e45367e524 前言 在Swift4.0版本中GCD的常用方法还是有比较大的改动，这里做个简单的整理汇总。 GCD的队列 队列是一种遵循先进先出（FIFO）原则的数据结构，是一种特殊的线性表。 主队列 全局队列 串行队列 并行队列 同步 X 并行同步 串行同步 并行同步 异步 串行异步 并行异步 串行异步 并行异步 X 表示禁止这么使用，—— 表示不建议这么使用。 1. 主队列 主队列默认是串行的，另外主队列不能结合同步函数( sync )使用，会造成线程死锁。 override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view, typically from a nib. let mainQueue = DispatchQueue.main mainQueue.sync { print("造成当前线程：\(Thread.current)死锁") } } 同时主队列中不应该添加耗时的任务，因为系统的UI相关事务都是在主线程队列中完成的，大量大耗时操作可能会造成卡顿，应该避免。 主队列最常用的方法是当子线程需要通知主线程做一些UI上面的操作时，结合子线程使用： let queue =

1.目的 在互联网中，我们会向网络运营商申请指定额度的带宽。实际传输时，由于网络QoS达不到要求，实际的传输带宽可能达不到标称值。本次测试在局域网环境中使用模拟工具模拟不同QoS下的网络条件，得出不同QoS网络下传输带宽 2.网络QoS指标 网络的QoS通常用以下指标衡量： 丢包率：由于网络拥塞，传输错误等造成的数据包丢失概率 延时：数据包发送到对端再返回到发送端的时长 延时抖动：衡量延时变化的程度 本次测试值模拟丢包率和延时与传输带宽的关系。 注:本文中的丢包率指的是在传输速率小于最大传输带宽时的丢包率。 3.测试方案 本次测试分两个阶段进行： 在丢包率为0的情况下，测试不同延时下的传输速率； 调整丢包率与延时，测试不同延时与丢包率组合下的传输速率。 4.测试环境 测试使用两位服务器： Server A：10.10.168.151 Server B：10.10.168.153 两台Server之间通过千兆以太网连接（带宽为1000Mbps）； 两台服务器上部署iperf，用于向网络加流量，并统计传输速率；其中Server A上运行iperf server端（iperf -s），Server B上运行iperf client端（iperf -c 10.10.168.151 -t 100000 -i2）。数据流量方向是：server B → server A。iperf

I am studying the MQTT protocol and it seems that there is a contradiction in the very first lines of the specs: The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless , bi-directional connections. Its features include: [...] Three qualities of service for message delivery: "At most once", where messages are delivered according to the best efforts of the operating environment. Message loss can occur . This level could be used, for example, with ambient sensor data where it does not matter if an individual reading is lost as the next one will be published