WebRTC 默认使用加密协议 SRTP 传输数据，抓包时看不到明文，不便于排查问题。

一种方法是下载开发版浏览器关闭加密选项，需要通讯的对端支持；

另一种方法是打开浏览器的 debug 选项，dump SRTP 解密后的 RTP 数据，下面先介绍这种方法。

1. dump RTP 明文

以 Windows 为例，关闭所有浏览器实例后，cmd下使用下面的选项打开浏览器，浏览器路径换成你的。

"C:\Program Files\Google\Chrome\Application\chrome.exe" --enable-logging --v=1 --force-fieldtrials=WebRTC-Debugging-RtpDump/Enabled/

• 其他平台打开日志的方法类似，详见 https://support.google.com/chrome/a/answer/6271282#zippy=%2Cwindows%2Cmac%2Clinux （移动平台待补充），Windows上的日志路径是 %LOCALAPPDATA%\Google\Chrome\User Data，也可以使用环境变量 CHROME_LOG_FILE 或选项例如 --log-file="C:\\tmp\\testchrome.log" 指定。Windows上cmd和PowerShell语法不同，上面的命令是在cmd下运行的。

• 打开试验性选项RTP dump （来源 https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/g3doc/field-trials.md ，浏览器所有选项文档 https://peter.sh/experiments/chromium-command-line-switches/ ）。

记得几年前有次需要写个简单的脚本，开始用的Python碰到中文编码问题，而且Python2和3规则不同，折腾了之后改用Ruby分分钟就搞定了，感觉Ruby的开发效率更高，几乎没有“令人惊讶”的设计；Python以缩进表示层级有时也带来不便，其他语言可以用clang-format自动格式化，也能保持风格的一致。

Python在AI的生态很好，最近写这块程序碰到bytes和str转换时字符编码的问题，平常也时常碰到乱码的困惑，比如打开文件或者浏览网页乱码，尝试换一下编码就ok了，但是没有深究原理。这次彻底把字符编码弄清楚了。

下面说下常见的编码，ASCII, latin-1, Unicode, UTF-8(UTF-16/32)，这几种在Python中常见。

WebRTC 是2011年谷歌开源的媒体框架，可以在浏览器中进行实时音视频通信，它是为P2P通信设计的，开发者也可以自己搭建服务器作为通信的一端。在下面这些网络条件限制严格的场景下不能直接建立通信，需要借助中转服务器TURN（Traversal Using Relays around NAT）转发。

1. 一端是对称型NAT，另一端是端口限制锥形NAT或者也是对称型NAT，无法建立P2P。这个工具可以检测自己网络的NAT类型 https://github.com/aarant/pynat
2. 对网络出口限制严格的环境，比如银行、政府单位，要求访问的外网IP地址需要加到其网关白名单。可以独立部署TURN服务器，将TURN的公网IP地址加到白名单。
3. 对安全要求极端严格的防火墙，不允许UDP通信，甚至只允许TLS over 443端口的流量。（来源 https://security.stackexchange.com/a/196330 ）

TURN 流程分析

协议分为三部分

1. 在TURN服务器上创建传输资源，称为 allocation
2. indication 方式传输数据
3. channel 方式传输数据

要注意的是，这两种传输数据的方式是并列关系。三部分的流程时序图如下（可右键打开，放大查看文本格式），client参考WebRTC代码，server参考pion/turn代码。

由于RTMP规范不在RFC官网上，为方便查看，转自 https://github.com/melpon/rfc/blob/master/rtmp.md，同 Adobe 官方标准 https://www.adobe.com/content/dam/acom/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf

Copyright Adobe Systems Incorporated                    H. Parmar, Ed.
                                                    M. Thornburgh, Ed.
                                                                 Adobe
                                                     December 21, 2012

Adobe’s Real Time Messaging Protocol

Abstract

This memo describes Adobe’s Real Time Messaging Protocol (RTMP), an application-level protocol designed for multiplexing and packetizing multimedia transport streams (such as audio, video, and interactive content) over a suitable transport protocol (such as TCP).

电水壶用了大半年，某天早晨起床后倒杯水，看到水中有一些杂质，开始以为是水质有问题，后来看了水壶中飘着一层薄膜状的东西，是烧水之后才出现的，水壶底和内壁上有一些刮痕状的东西，应该是水垢。回顾起中学化学的知识，查了一些资料，对水垢的来龙去脉做下记录，以后可以更好地处理生活上的问题。

水垢形成的主要过程

1, 空气中的$\ce{CO2}$与水结合形成$\ce{H2CO3}$，落到地面。

今年是共产党建党一百周年，清明节去了趟毛主席纪念堂瞻仰伟人，献了三束白菊花，从毛主席侧边经过，过道大概离他两米距离，他安详地躺在玻璃水晶棺内，头发还是黑色的，身长比印象中小些。那会天安门广场就在紧锣密鼓地布置七一建党100周年纪念场地了。

2021年6月重新整理后在部门做的分享 https://mp.weixin.qq.com/s/4dFdz0H0mjpemDflKbTdmQ

=============

FEC名为前向纠错（Forward Error Correction），用于恢复丢失的信息。看了很多介绍FEC的文章把矩阵和伽罗瓦域混在一块讲，大大提升了理解的难度。其实两者可以独立看待，我明白后有一种醍醐灌顶的感觉，伽罗瓦域（又名有限域）理论是连接连续数学和计算机落地实现时的桥梁，后文会详细说明。

本文分三部分介绍。

1. 第一部分背景介绍，面向所有人，尽量讲解得通俗易懂，希望读者至少能看懂本文要解决什么问题。
2. 第二部分面向学过高数的同学，讲解FEC怎么解方程来恢复数据的。
3. 第三部分面向数学、计算机专业等学过群论的同学，讲解FEC在用计算机解方程时碰到的问题及如何用群论优美地解决的。

1. 背景介绍

大家用过微信的视频通话，有时网络不佳会感觉卡顿，视频是由“一幅幅图像”组成的（真实情况更复杂，这里为了降低理解的门槛简化说明），如果某一幅图像在传输过程中丢失接收者可能感觉卡顿。

微信通话