有部分网友提到上篇文章ZeroMQ性能分析，没有提供测试代码，想要自己验证测试结果；本篇文章，主要介绍代码层面，如何使用ZeroMQ。测试样例有python版本、C/C++版本。
根据官方介绍，ZeroMQ是支持多语言，也就是说，它支持在多种不同语言的进程之间实现通讯。我们想要验证的场景是，生产者-消费者模型，一个生产者，多个消费者，ZeroMQ是否支持这种模型、数据共享性能如何，这也是常见的编程模型。
这个图的表达有一定的误差，例如生产者是进程，将任务队列替换成ZeroMQ，并且ZeroMQ内部也没有队列，图仅可用于示意。从尽快出验证结果的[……]
最近一段时间都在做方案设计，有一模块会使用开源组件，根据有关同事经验，开源组件在某些场景下会出现coredump，考虑到这种不稳定性因素、以及后续不同组件版本符号之间的冲突，要把影响降到最低。选择采用多进程方案来实现，就需要使用到IPC技术。
努力回想操作系统教材上进程间通讯方式的概念，常见的IPC方式包括，管道、消息队列、共享内存、本地socket，而业界比较知名的可用于进程间通信的组件有ZMQ，也得到同事们的一致推崇。而我们的场景下，进程间共享的数据最大为32MB。
ZeroMQ是一种基于消息队列的多线程底层网络[……]
近期主要关注实时音视频的弱网优化技术，重点分析WebRTC的相关技术实现，主要包括抗拥塞、抗丢包，会通过一系列文章来分享我的学习所得，本次介绍拥塞控制算法GCC(Google Congestion Contrl) 原理与实现。
GCC 作为官方的拥塞控制算法，被广泛应用在实时音视频领域，包括腾讯会议、Agora、华为WeLink等VoIP音视频产品中。主要用来估计带宽，根据可用带宽控制当前的发送速度，减少传输链路发生拥塞的概率，尽可能降低传输链路带来的延时。
网络拥塞产生的原因，网络传输链路所承载的数据量超过了它所能处理的极限，传输延时增大，产生丢包、抖动。进而导致实时通讯中音视频[……]
作为工程师日常除了写代码，也要写很多文档，例如 项目方案、接口文档、项目总结。我们都习惯了与代码打交道，在word上写文字，需要手动修改文字格式，缺乏写代码的畅快感。用MarkDown来写文档，既能享受写代码的乐趣，也能写出格式清晰的文章。
Markdown是一种标记语言，支持大多数html语法，纯文本，兼容性极强，不存在格式不兼容问题。可转换成HTML、PDF、WORD文档；标记语法可读性很强。
只需要在文本前面加上 # 即可，根据#个数的不同，可以增加二级标题、三级标题、四级标题、五级标题和六级标题，总共六级，类似word里面的标题个数。同意设置比word里面逐个改[……]
上篇文章介绍 WebTC 原生demo 在Android 平台下编译方法，本次对原生demo AppRTC 的音视频弱网抗性进行分析，音频测试采用POLQA设备测试不同网络环境下的MOS分变化；视频测试采用自研方法计算卡顿率。弱网条件包括，丢包、延时、带宽限制。
丢包会导致语音卡顿，人耳主观感受就是吐字不清，这对于VoIP通话、在线会议都是不可接受，分析原生demo 在不同丢包率下的MOS分变化。
最近工作上频繁需要与异地同事交流，会使用到远程桌面，使用中发现视频画面非常卡，严重影响使用。画面卡顿直接原因是丢帧，间接原因是产生了丢包。
我们双方都是在公司网络下使用，网络质量一切正常。经过测试验证，我与北京本地的同事使用远程协助没有问题，和杭州的同事使用就出现问题。直观感受是杭州同事这边的网络问题。杭州同事直接ping www.smiletoyou.cn ，ping结果正常，没有丢包、rtt也比较平稳。
直接查看IP，发现杭州同事的出口IP是xx 云，实际使用中除了三大运营商之外，这种xx云出口统一认为是小运营商。基于国内的网络环境，小运营商用户统一用小运营商服务器覆[……]