发表于

相关名词

  • DNS（Domain Name System）域名系统: 域名和IP地址映射关系
  • LocalDNS : 本地DNS服务器，一般是ISP（Internet Service Provider）提供。ISP，即是互联网服务提供商(比如电信、联通和移动三大电信运营商)；对于不同运营商间的互联互通，一般是采用BGP peering（对等）的方式进行
  • 地址解析协议，即ARP（Address Resolution Protocol）是将IP地址转换为MAC地址（TCP/IP数据链路层协议）；DNS协议则是将域名转换为IP地址（TCP/IP应用层协议）
  • ICANN 互联网名称与数字地址分配机构（The Internet Corporation for Assigned Names and Numbers）,全世界域名的最高管理机构。
  • CNNIC：中国互联网络信息中心（China Internet Network Information Center，CNNIC）是经国家主管部门批准，于1997年6月3日组建的管理和服务机构，行使国家互联网络信息中心的职责。
  • 可逆DNS（rDNS，reverse DNS）是一种把一个IP地址分解成一个域名的方法，正像域名系统（DNS）把域名分解成关联的IP地址。

DNS解析流程

  • 不考虑每部分DNS缓存的情况下，DNS解析流程大致如下：
  1. 【递归查询】用户机器（比如浏览器）-> 本地DNS服务器
  2. 【迭代查询】本地DNS服务器 -> DNS根服务器(返回域服务器)
  3. 【迭代查询】本地DNS服务器 -> 域服务器(返回DNS服务器列表)
  4. 【迭代查询】本地DNS服务器(选择一个DNS服务器) -> DNS服务器(返回域名对应的IP)（或返回其他权限服务器的IP地址，取决于域名的解析配置）
  5. 本地DNS服务器 -> 权限服务器（可选步骤，取决于上一步的返回）
  6. 用户机器（根据IP发送请求访问）

  • https://devconnected.com/how-to-flush-dns-cache-on-linux/

  • 浏览器等各个部分一般会缓存DNS记录一段时间

  • 本地DNS服务器（LocalDNS）使用迭代查询的方式请求；请求发起方（浏览器）使用递归查询的方式请求

  • 递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机

  • 迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询。

  • 通俗地说，递归就是把一件事情交给别人，如果事情没有办完，哪怕已经办了很多，都不要把结果告诉我，我要的是你的最终结果，而不是中间结果；如果你没办完，请你找别人办完。
    迭代则是我交给你一件事，你能办多少就告诉我你办了多少，然后剩下的事情就由我来办。

域名的管理

  • .com等国际顶级域名的管理机构是ICANN；.cn等国内域名的管理机构是CNNIC

  • 用whois可以查询域名的相关信息

  • 域名具有管理密码和转移密码，域名转移密码又称为授权码（Authorization code）或 域名EPP代码（EPP Key）

  • 域名其实是具有一定的层次结构的，从上到下依次为：根域名、顶级域名（top level domain，TLD）、二级域名、（三级域名）
    先来讲讲顶级域名（TLD），即最高层级的域名。简单说，就是网址的最后一个部分。比如，网址www.baidu.com 的顶级域名就是 .com。ICANN 的一项主要工作，就是规定哪些字符串可以当作顶级域名。

  • ICANN 自己不会去管理这些顶级域名，因为根本管不过来。想想看，顶级域名有1000多个，每个顶级域名下面都有许多批发商，如果每个都要管，就太麻烦了。ICANN 的政策是，每个顶级域名都找一个托管商，该域名的所有事项都由托管商负责。ICANN 只与托管商联系，这样管理起来就容易多了。举例来说，.cn 国家顶级域名的托管商就是中国互联网络信息中心（CNNIC），它决定了 .cn 域名的各种政策。

  • 由于 ICANN 管理着所有的顶级域名，所以它是最高一级的域名节点，被称为根域名（root domain）。在有些场合，www.xxx.com 被写成 www.xxx.com.，即最后还会多出一个点。这个点就是根域名。

  • 理论上，所有域名的查询都必须先查询根域名，因为只有根域名才能告诉你，某个顶级域名由哪台服务器管理。事实上也确实如此，ICANN 维护着一张列表（根域名列表），里面记载着顶级域名和对应的托管商。

DNS服务器类别

权威 DNS

  • 权威 DNS 指域名在域名注册商处所设置的 DNS 服务器地址。该地址决定了该域名的解析管理权（新增，删除，修改等）。比如 DNSPod 的权威服务器：*.dnspod.net, * dnsv3.com 等。当域名设置权威服务器并设置了解析记录后，客户端请求域名时，权威服务器将返回该域名的对应的解析记录信息。

Local DNS

  • Local DNS 是 DNS 查询中的第一个节点。Local DNS 作为客户端与 DNS 域名服务器的中间人。客户端发送 DNS 查询时，Local DNS 将使用缓存的数据进行响应，或者将向根域名服务器发送请求，接着向根域名服务器发送另一个请求，然后向权威 DNS 发送最后一个请求。收到来自包含已请求 IP 地址的权威 DNS 服务器的响应后，Local DNS 将向客户端发送响应。

  • 在此过程中，Local DNS 将缓存从权威 DNS 服务器收到的信息。当一个客户端请求的域名 IP 地址是另一个客户端最近请求的 IP 地址时，Local DNS 可绕过与域名服务器进行通信的过程，并仅从第二个客户端的缓存中为第一个客户端提供所请求的记录。

公共 DNS

  • 公共DNS，指面向所有互联网用户的全球公共递归域名解析服务。和仅使用本地 LocalDNS 的传统解析服务相比，公共解析服务，一般具备更加“快速”、“稳定”、“安全”互联网访问。

DNS常用命令

  • dig、 host、nslookup、traceroute、whois

解惑

域名提供商和电信服务提供商之间DNS的关系？

  1. 域名提供商(域名注册商)（ICANN等授权的管理机构）；电信服务提供商（ISP）
  2. ISP的DNS：LocalDNS
  3. 域名提供商的DNS （腾讯、阿里云等），将自己的dns服务的ip直接在各个ISP中进行登记，使得ISP的DNS服务能转发过来查找，得到域名对应的ip
  4. 域名并不依赖平台，比如阿里万网只是个注册商，注册完域名后有相应的转移密码。转移密码有多种用途，比如可以在多个DNS服务商托管域名解析（有的域名注册商不一定有对应的DNS服务，而且在多个DNS服务商解析可以起到容灾作用）

运营商DNS和公共DNS

  • 如何不特意去设置，我们用的就是运营商DNS（由DHCP分配）
  • 目前国内电信运营商通过使用DNS劫持和DNS污染的方法，干扰用户正常上网，使得用户无法访问众多国外常用服务，因此可以使用公共DNS

自己创建的域名怎么让其他dns服务器解析

  • 除非用户自行设置指定你的dns服务公网ip，否则只有成为认证通过的注册服务商才行
  • 比如阿里云域名的解析生效，第一步是 阿里云 DNS 必须首先生效，然后等待世界各地 Local DNS 生效，可以通俗的理解为各大电信运营管理的 DNS 需要及时同步 阿里云 DNS 解析记录，才能最终生效。 网站是否能访问，直接相关的是 Local DNS， 阿里 云解析都是实时生效的，一般只需几秒即可同步到各地 Local DNS 上，但各地 Local DNS 均有缓存机制，解析的最终生效取决于各运营商刷新时间。

DNS解析相关疑问

  • DNS协议是应用层的协议，解析过程发生在用户态。
  • DNS协议既使用了UDP，也使用了TCP，使用的端口号都为 53。大多数情况下 DNS 都使用 UDP 进行传输。
  • DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议；DNS区域传输的时候使用TCP协议
  • 举个例子：浏览器返回某个HTTP服务
    1. 浏览器调用“DNS解析模块”发出UDP请求得到域名的ip（DNS 应用层）
    2. 浏览器调用TCP（内核系统调用）发出HTTP请求（TCP 传输层）
    3. TCP通过ARP协议得到mac地址 （ARP 数据链路层）
  • “DNS解析模块” 是在哪里实现的？
    1. 程序自行解析实现（从/etc/resolv.conf中取出本地dns server地址列表， 发送DNS请求(UDP报文)并获得结果）
    2. 调用到c标准库的getaddrinfo或getnameinfo函数
      • 要想知道getaddrinfo是如何查询信息的，可以用strace工具，追踪getaddrinfo函数 在执行时打开了哪些文件
      • resolv.conf是各种操作系统域名系统解析器（DNS Resolver）的配置文件。每当一个程序需要通过域名来访问Internet上面的其它主机时，需要利用Resolver库函数将域名转换成对应的IP，然后才可进行访问。
      • 域名系统解析器（DNS Resolver）并非一个可执行程序，而是C语言的一系列库函数，用于解析resolv.conf获取域名对应的IP。
    3. 操作系统中并不存在“DNS 查询”这个系统调用; 不同程序可能采用不同的策略获取名字对应的 IP 地址

dns-resolver相关

Reference

发表于 
1. jsonp、jsonpCallback  jsonp跨域时可以自定义的两个参数
2. jsonp: 回掉函数名的参数名，默认callback，服务端通过它来获取到回调函数名
3. jsonpCallback: 回调函数名，默认jquery自动生成
4. 指定jsonpCallback时可以将回掉函数写在ajax外面做其他操作，不指定时不能这样做，只能在success里做操作

一般jquery跨域用到的两个方法为：$.ajax 和$.getJSON

最后，仔细安静下来，细读 json 官方文档后发现这么一段：

JSON数据是一种能很方便通过JavaScript解析的结构化数据。如果获取的数据文件存放在远程服务器上（域名不同，也就是跨域获取数据），则需要使用jsonp类型。使用这种类型的话，会创建一个查询字符串参数 callback=? ，这个参数会加在请求的URL后面。服务器端应当在JSON数据前加上回调函数名，以便完成一个有效的JSONP请求。如果要指定回调函数的参数名来取代默认的callback，可以通过设置$.ajax()的jsonp参数。

其实jquery跨域的原理是通过外链

发表于

  • 最近定位一个问题，花了不少时间。事后回想起来挺低级的，在此记录一下。

问题

  • spring i18n, 在windows和mac生效，在linux不生效。

原因

  1. 资源文件的名字为小写（message_zh_hant.proprties）
  2. 而文件读取时包含大写（message_zh_Hant.proprties）（这里不得不吐槽一下，spring无论请求参数传的是大写还是小写，最终都会转成大写去读文件，而且这么简单的功能，代码写得及其复杂，浪费了不少时间去debug）
  3. windows和mac大小写不敏感，所以能读取文件成功，而linux则大小写敏感，则读取不成功（说好的Java跨平台呢？但跨平台包括处理这种不兼容的问题？似乎很难界定。）

总结

  • windows和mac文件名对大小写不敏感，而linux则大小写敏感；
  • 即使使用Java编写代码，特殊的场景还是需要考虑各平台的兼容问题。

发表于

一直想部署一个私有服务，平常在外的时候可以为自己提供服务。
私有服务的好处是，可以根据自己的需求，开发程序，提供个人定制化的服务

服务器的选择

  1. 阿里云、腾讯云等
    • 优点：使用方便，只要有网络就可以连上
    • 缺点：有持续产生的费用，对于个人服务来说，平常几乎都是闲置，性价比很低
  2. 自建服务器
    • 优点：总体成本低，购买服务器后，后续只有有电有网就行，无需其他额外成本
    • 缺点：需要外网能访问（需要绑定外网ip或者代理接入转发）
  • 本着能省就省的原则，最终还是采用了方案2 ：上淘宝买一个一百多块的小型服务器！

如何使外网环境能访问到服务器

  • 服务器有了之后，通过网线连接到家庭网络即可正常上网了，那么外网环境怎么访问呢？
    通过一番研究之后，最终决定通过在服务器上部署ngrok代理来实现，不知道啥是ngrok的自行搜索即可

编程语言选择

  • 本人平常工作都是使用Java，但经过一番考虑之后，我最终选择了Go作为开发语言
  1. 想学习，通过实践熟悉
  2. 足够轻量，打包成一个二进制文件即可，特别适合这种低配版服务器

前端终端选择

  • 平常在外都是使用android的手机，但是作为后端开发，本人只会android的hello world。
    有考虑使用网页，但是现在前端很卷了，用传统的html+js开发，以我的水平开发出来，至少前期体验也一般。

  • 经过一番考虑，就在决定直接通过个人的微信公众号来作为前端，在公众号后台配置自己的服务器地址即可

微信通知的实现

  • 平常自己有一些个性定时任务，需要通知消息到自己，使用微信来通知是最好的，毕竟大家目前都是微信的重度用户了。

  • 但现在微信对公众号的通知限制越来越多了，最后我选择通过发送邮件的方式来实现。在微信配置QQ邮箱接收邮件通知即可。

服务架构

外网环境下如何进行服务部署更新

  • 平常在家庭网络下，开发Go程序，本地编译打包成二进制文件，上传到服务器更新程序即可
    在外网环境下，使用花生壳等端口映射软件即可。我使用花生壳映射端口后，就可以通过ssh登录到家里的服务器，接下来就可以为所欲为了。

部署流程

结论总结

  • 家庭网络 + 小型服务器 + Go程序 + ngrok + 微信公众号 + 邮箱通知 + 花生壳

Reference

发表于
  • O这个符号的意思是“忽略重要项以外的内容”，读音同Order。O（n2）的含义就是“算法的运行时间最长也就是n2的常数倍”，准确的定义请参考相关专业书籍。重点在于，通过这种表示方法，我们可以直观地了解算法的时间复杂度
  • 当我们知道选择排序的时间复杂度为O（n2）、快速排序的时间复杂度为O（nlogn）时，很快就能判断出快速排序的运算更为高速。二者的运行时间根据输入n产生的变化程度也一目了然。

一、链表

二、数组

三、栈

四、队列

五、哈希表

六、堆

  • 堆是一种图的树形结构，被用于实现“优先队列”（priority queues）
  • 优先队列是一种数据结构，可以自由添加数据，但取出数据时要从最小值开始按顺序取出
  • 如果需要频繁地从管理的数据中取出最小值，那么使用堆来操作会非常方便。

七、二叉查找树

  • 二叉查找树（又叫作二叉搜索树或二叉排序树）是一种数据结构，采用了图的树形结构
  • 二叉查找树有两个性质。第一个是每个结点的值均大于其左子树上任意一个结点的值。
  • 有很多以二叉查找树为基础扩展的数据结构，比如“平衡二叉查找树”。这种数据结构可以修正形状不均衡的树，让其始终保持均衡形态，以提高查找效率。
  • 种子结点数可以自由设定，并且形状均衡的树便是B树。

图

  • 由顶点和连接每对顶点的边所构成的图形就是图。
  • 这个值叫作边的“权重”或者“权”，加了权的图被称为“加权图”。没有权的边只能表示两个顶点的连接状态，而有权的边就可以表示顶点之间的“连接程度”
  • 有向图、无向图

广度优先搜索

  • 广度优先搜索会优先从离起点近的顶点开始搜索。
  • 候补顶点是用“先入先出”（FIFO）的方式来管理的，因此可以使用“队列”这个数据结构。
  • 广度优先搜索的特征为从起点开始，由近及远进行广泛的搜索。因此，目标顶点离起点越近，搜索结束得就越快。

深度优先搜索

  • 深度优先搜索会沿着一条路径不断往下搜索直到不能再继续为止，然后再折返，开始搜索下一条候补路径。
  • 此处，候补顶点是用“后入先出”（LIFO）的方式来管理的，因此可以使用“栈”这个数据结构。
  • 广度优先搜索选择的是最早成为候补的顶点，因为顶点离起点越近就越早成为候补，所以会从离起点近的地方开始按顺序搜索；而深度优先搜索选择的则是最新成为候补的顶点，所以会一路往下，沿着新发现的路径不断深入搜索。

贝尔曼-福特算法

  • 贝尔曼-福特（Bellman-Ford）算法是一种在图中求解最短路径问题的算法。最短路径问题就是在加权图指定了起点和终点的前提下，寻找从起点到终点的路径中权重总和最小的那条路径。
  • 贝尔曼也因为提出了该算法中的一个重要分类“动态规划”而被世人所熟知。

狄克斯特拉算法

  • 狄克斯特拉（Dijkstra）算法也是求解最短路径问题的算法，使用它可以求得从起点到终点的路径中权重总和最小的那条路径路径。

A*算法

  • A（A-Star）算法也是一种在图中求解最短路径问题的算法，由狄克斯特拉算法发展而来。狄克斯特拉算法会从离起点近的顶点开始，按顺序求出起点到各个顶点的最短路径。也就是说，一些离终点较远的顶点的最短路径也会被计算出来，但这部分其实是无用的。与之不同，A就会预先估算一个值，并利用这个值来省去一些无用的计算。

Reference

  • [我的第一本算法书] - 宫崎修一 石田保辉

发表于

思考维度

  • 事前, 事中, 事后
  • 从三个维度 预防，及时发现，止损 三个出发
  • what when why who how
  • 5W3H(what、when、why、who、where、how、how much、how feel)
  • 金字塔思维: 主治：思维混乱，分不清主次重点 - 提高逻辑性和条理性; 总-分-总 过去-现在-将来 第一-第二-第三.
  • STAR 法则: 主治：不知道如何表达 - 讲述故事的绝佳手段; 情境(situation)、任务(task)、行动(action)、结果(result)
  • SMART 原则: 主治：不知道如何着手做目标管理 - 制定目标的黄金准则; 目标具体(Specific)、可度量(Measurable)、可实现(Attainable)、现实性(Realistic)、时限(Time bound)
  • PDCA 循环： 主治：工作计划性差, 自律性弱 - 过程管理: 持续反馈->持续改进 ；计划（plan）、执行（do）、 检查（check）、调整（Adjust）
  • 四象限法则: 主治：时间分配不合理- 尽量在做最重要的事情;

结构化思维

  1. 表达要有逻辑(所有的逻辑关系都在这四种顺序之内)
  • 演绎（因果）顺序
  • 时间（步骤）顺序
  • 空间（结构）顺序
  • 程度（重要性）顺序
  1. 做事要有套路
  • 5W2H:Why、Who、When、Where、What、How 和 How much
  1. 建立中心
  • 定义清楚要解决的问题，要明确目标
    • 自上而下:适用于问题比较明确的情况，我们只需要找到问题的核心要素即可，然后进行展开即可。
    • 自下而上:对于问题不够明确的情况，我们需要对多种杂乱的内容，进行分类、剪枝、归纳汇总成一个中心。
  • 抽象层次越高，要解决的问题域越宽，外延越大
  1. 结构化分解
  • 分解的策略就是我们上文提到的四种逻辑顺序，即演绎顺序、时间顺序、空间顺序和程度顺序
  • 在做空间分解的时候，要注意满足 MECE（Mutually Exclusive Collectively Exhaustive，相互独立，完全穷尽）原则

合理安排自己的时间

  1. 每天提前一小时醒来
  2. 每天提前 15 分钟到公司
  3. 下班前花 15 分钟总结
  4. 减少玩手机的时候
  5. 把时间切割成小块
  6. 碎片化时间利用
  7. 给休息生活留出时间
  • 抽象思维：帮助我们快速抽取面对问题的关键要素和本质，可以是其他能力的“元能力”
  • 分层思维：帮助我们拆解问题，分而治之，划清问题和职责边界
  • 归纳思维：帮助我们从个性问题中抽象出问题的一般规律和得出共同结论
  • 结构化思维：帮助我们沉淀自己的知识树，逐步系统性的思考问题

深度工作总结

  • 如果你无法学习，就无法成功
  • 无干扰状态下保持专注
  • 高质量工作产出=时间×专注度
  • 转移工作、注意力残留 -> 专注、深度工作
  • 深度工作并非是我们的经济中唯一有价值的技能，不培养这种能力也有可能做得很好，但是不需要深度工作的职业会越来越少。
  • 最小阻力原则
  • 忙碌代表生产能力（Busyness as Proxy for Productivity）：在工作中，对于生产能力和价值没有明确的指标时，很多知识工作者都会采用工业时代关于生产能力的指标，以可视的方式完成很多事情。
  • 支持深度工作往往要抵制新的高科技
  • 当工作中没有明确目标时，围绕浮浅工作的表面忙碌会成为一种本能
  • 工作其实比休闲时光更容易带来享受？
  • 意志力是有限的
  • 培养深度工作的习惯，关键在于越过良好的意图，在工作生活中加入一些特别设计的惯例和固定程序，使得进入并保持高度专注状态消耗的意志力最小化。！！！！！
  • 选定你的深度哲学（节奏哲学）、并习惯化
  • 恰当展开协作可以提升你在职业生活中深度工作的质量
  • 这种隔音办公室与宽阔公共空间的组合，形成了中心辐射型的创新建筑结构，在这里偶遇的意外发现和与世隔绝的深度思考都能实现。
  • 专注于少量“极端重要的目标”
  • 引领性指标
  • 专注于极度重要目标上的深度工作状态时间
  • 4DX框架下的4种原则 ！！！
  • 在整个4DX的实验过程中，目标的明晰性，辅以引领性指标计分板提供的简单但却难以回避的反馈，促使我达到了此前从未实现的深度状态。
  • 定期放松大脑！！工作日结束的时候，在第二天早晨到来之前，屏蔽掉对工作问题的担忧。
  • 定期休息大脑可以提升深度工作的质量。工作时，努力工作。完成时，就放松下来。
  • 不要不断分心，而要不断专注
  • 设定一个几乎不可能的时间期限；深度工作需要专注的强度远远超出了大部分知识工作者的舒适区。
  • 有成果的冥想
  • 远离社交媒体
  • 在晚上或周末到来之前就确定要做的事情是十分重要的。（避免陷入其他无效的诱惑）
  • 人的智力系统可以进行长时间的高强度活动：它不像人的手脚一样会疲倦。除睡觉以外，它只需要变化，而不是停止。！！！
  • 如果你想抵御娱乐网站对你时间和精力的诱惑，那么就给大脑找一些高质量的替代活动。这样不仅可以使我们避免分心，保持专注的能力，同时还有可能实现本内特的宏伟目标：体验到何为生活，而不仅仅是生存。
  • 减少浮浅工作在我们日程中的分量，而不是将其消除
  • 一天的每一分钟都要做好计划（笔记本）
  • 深度工作要求你尊重自己的时间。要做到真正尊重时间，下面这一条建议是个很不错的开端：提前决定你一天的每一分钟要做什么工作。
  • 5点半之前结束工作。固定日程生产力。
  • 变得不容易联系到；文档化

Reference

发表于

边缘服务

  • 边缘服务的网络质量很重要，覆盖不好会有弱网问题

网络相关命令

  • dig命令 ：

    • 一个域名可以有两种类型的指向，如果一个 域名指向 称为一个 记录 （Record）的话，那么就有两种 记录类型 （Record Type），分别是：
      A记录 ：指向一个IP地址 （地址记录）
      CNAME ：指向一个其他的域名（别名记录）
      NS : 名字服务器记录(理解为dns服务器 )

  • linux查看网络路由跳转
    traceroute www.baidu.com

  • 查看路由表
    route -n（netstat -rn）

  • nslookup

使用tcp长连通信 （个人总结）

  • 一般都是直接用ip端口的方式；一般情况下域名都是公共的，很少会为了某些业务暴露端口，所以一般直接ip端口直接连应用（边缘服务器？？）
  • 使用ip端口相连会有部分用户连不上的问题，比如只有北京的外网ip，用户在广州，可能会连接不稳定（没走专线）
  • 非tcp长连，普通的http请求走域名（或cdn），返回用户一个就近的ip，进入这个ip之后，之后的通信都是内网通信（运营商内网，专线，CDN专线等）
  • 所以一般使用tcp长连，需要很多个边缘节点ip，分布在各个地方的机房，并配合合适的调度策略（根据机器的负载情况）（腾讯im有大量的边缘服务？）
  • 如果没足够的边缘机器（部署几个重要的边缘服务，其他的降级走http（域名），不走长连？？）
  • 注意NAT的使用
    • 解Bug之路-NAT引发的性能瓶颈
    • 使用同一个NAT地址的机器，timestamp是不能保证同步的(即使一致也没用，per-host PAWS机制的存在会导致问题)。
      • TCP长连接服务，最好服务上有外网ip，否则直接用NAT转发，容易造成问题

边缘计算机器

  • 边缘计算机器（Edge Computing Machine，ECM）通过将计算能力从中心节点下沉到靠近用户的边缘节点，为您提供低时延、高可用、低成本的边缘计算服务。
  • CDN俗称“边缘节点服务”。可用于网站加速、将源站内容分发至最接近用户的节点，使用户可就近取得所需内容，提高用户访问的响应速度和成功率。解决因分布、带宽、服务器性能带来的访问延迟问题，适用于站点加速、点播、直播等场景。
  • 还有边缘节点服务（Edge Node Service, ENS）提供基于CDN的边缘弹性基础设施，使您可以将计算、转发等业务下沉至边缘。降低响应时延和带宽成本、减轻中心集群压力，适用于“中心+边缘”架构模型下的各类业务。

使用websocket

BGP AnyCast

  • 时延敏感度高的内容服务业务（比如这里说的长连接服务）

    • 针对https/tcp等对时延敏感的协议（涉及多次握手的协议），由于用户位置流动，而数据中心相对固定，因此会随着用户的移动，体验可能出现严重下降。
    • 基于以上背景，可在全球有相关业务的地址位置部署小型数据中心，所有小型数据中心和总部数据中心保持长期稳定的TCP会话连接。当相对于总部的远端用户访问服务时，TCP连接实际是发送至用户当地的小型数据中心，从而降低了访问延时，提高了用户体验度。
    • 在全球大规模部署多个节点时，为了确保用户能就近访问所在地的数据中心，可把所有小型数据中心的IP采用相同地址，通过BGP发布至Internet。
    • 当用户访问服务时，DNS解析会返回此小型数据中心的IP，然后用户运营商会根据就近原则路由用户数据到最近的小型数据中心，从而达到了上面所述的优化延迟的目的。

  • AnyCast适用于无连接的UDP，以及有连接的TCP协议；基于AnyCast的特性——就近原则，很大程度上提升了客户端的响应速度。

  • AnyCast缺点

    • AnyCast严重依赖于BGP的选路原则，在整个Internet网络拓扑复杂的情况下，可能导致次优路由选择

  • BGP AnyCast 的部署成本比较大，基本由一定规模的公司才会实施这一套方案（比如阿里云、腾讯云等），并以云服务的形式提供给其他企业使用。

  • 以腾讯云为例

    • Anycast 公网加速（Anycast Internet Acceleration，AIA）是一个覆盖多地的动态加速网络，可以大幅提升您业务的公网访问体验。AIA 不同于其他应用层加速服务，它能实现 IP 传输的质量优化和多入口就近接入，减少网络传输的抖动、丢包，最终提升云上应用的服务质量，扩大服务范围，精简后端部署。

  • 疑惑：在AnyCast网络中多个主机用同一个IP，这岂不是IP地址冲突了？

    1. 首先，每一个节点主机处在不同的地理位置，相互之间不在同一个广播域内。所以把所有主机配置成相同的IP地址并不会引起我们日常所见的IP地址冲突；
    2. 其次，在仅仅配置相同IP之外，还需要借助BGP协议进行地址宣告，通过BGP，各个站点向Internet宣告相同的AnyCast IP地址。

  • 最佳实践

背景说明
某游戏公司，BACKEND 服务集群在首尔。该公司不希望部署多套逻辑和数据层，从而降低成本，但又希望全球的客户能够接入，需要全局漂移 IP 作为访问的唯一入口，并可做全局的就近分配、动态流量分配、故障剔除。

痛点说明
该游戏公司由客户自建的 IDC 和中小型公有云厂商不具备网络跨地域调度能力，更无 Anycast 能力，显然无法满足客户需求。易被如下问题困扰：

区分多个外网 IP，每个地域都部署集群，维护多个逻辑层，数据层跨地域读写，一致性和实时性较差。
只能寄希望于运营商链路质量。首尔某运营商网络故障导致 A、U 等多家服务商 BGP 网络异常，部分地区无法访问，该游戏的用户流失严重。
DDoS 攻击流量集中在一个 IP 上，影响巨大。

方案说明
针对客户需求，腾讯云帮助客户实现以下方案，方案示意图如下：

方案重点如下：

使用 Anycast 的 EIP，该 IP 同时在多地 Anycast，实现多地同服。
用户后端集中维护一套集群，然后绑定 Anycast 类型的 EIP。该 EIP 借助腾讯云内网和 POP 点，多地发路由。
客户不用感知网络路径的选择，无需手动指定 IP 的发布位置，流量就近完成了全局负载均衡，从最优的地域进出，后端得到简化。同时，客户的 IP 得到收敛，无需每个地域配一个 IP 和 DNS 规则，在备案和管理上得到简化。
传输质量得到提高。
多个 IP 发布地，实现了多路径，增加了网络的容错能力。此外，就近接入后走的是专线传输，比公网传输更可靠、更低延时，提升了玩家的体验。

BGP AnyCast 原理要点

  • 任播(Anycast)，又称为选播、泛播或任意播

  • 利用一个（多个） as号码在不同的地区广播相同的一个ip段。
    利用bgp的寻路原则，短的as path 会选成最优路径（bgp寻路原则之n），从而优化了访问速度。
    其实bgp anycast是不同服务器用了相同的ip地址。

  • Anycast技术也存在一定的局限性:
    使用Anycast中的共享单播地址不能作为客户端发起请求，因为请求的响应不一定能返回到发起的Anycast单播地址。因此，目前Anycast仅适合一些特定的上层协议，从目前的实际应用来看， Anycast最广泛的应用是DNS的部署。

  • IP Anycast＋BGP的部署必须使用能够运行BGP的设备与其他自治域进行路由交换，通常使用的设备是路由器或三层交换机。然后将目标主机直接接入路由器或通过负载均衡设备将多台主机接入路由器

  • 在IP Anycast＋BGP整体部署之前应多方面考虑各种因素，着重考虑自治域号申请、IP地址规划等问题

  • Anycast IP，则是集Multicast和Unicast特性于一身的特殊IP地址类型

  • Anycast实质上是一种网络技术，它借助于网络中动态路由协议实现服务的负载均衡和冗余，从实现类型上分，可以分为subnet Anycast和Global Anycas: Subnet Anycast是指所有目的主机都位于同一网段，此方式仅提供负载均衡和冗余，对安全度提升没有实质效果; Global Anycast是指目的主机处于不同网段，可能处于不同城市，甚至分布在全球各地，在实际应用中Global Anycast中目标主机的部署除地理位置的考虑外，多接入不同自治域的网络中。

  • 当使用Anycast的目标主机接入到不同自治域时，因为难以使用某一自治域的IP地址，所以通常使用Anycast的共享单播地址拥有独立的自治域号，并通过BGP协议与不同自治域网络交换路由，即IP Anycast＋BGP。

  • 在实际应用中，任播 (Anycast) 是一种网络寻址和路由的策略。Anycast 采用将一个单播地址分配到处于 Internet 中多个不同物理位置的主机上，发送到这个主机的报文被网络路由到路由协议度量的最近的目标主机上。
    例如：在 IP 网络上通过一个 Anycast 地址标识一组提供特定服务的主机，同时服务访问方并不关心提供服务的具体是哪一台主机（比如：DNS 或者镜像服务），访问该地址的报文可以被 IP 网络路由到这一组目标中的任何一台主机上。

  • 使用anycast，数据传输路径：client -> anycast ip -> 内网ip -> 内网机器

Reference

发表于

推流协议

  • 虽然 RTMP 在直播领域不是特别流行，但是在推流服务，也就是“主播”到“服务器”这个方向上 RTMP 居于主导地位，目前国内的视频云服务都是以 RTMP 为主要推流协议（由于直播 SDK 第一个功能模块就是主播推流，所以也被称为是 RTMP SDK）。

播放协议

  • 目前常见的直播协议包括：RTMP、 FLV、HLS 和 WebRTC。

  • RTMP：RTMP 协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧拆分，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。

  • FLV：FLV 协议由 Adobe 公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种简洁，在延迟表现和大规模并发方面都很成熟，唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端 App 直播协议却异常合适。

  • HLS：苹果推出的解决方案，将视频分成5秒 - 10秒的视频小分片，然后用 m3u8 索引表进行管理，由于客户端下载到的视频都是5秒 - 10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS 的一般延迟在10秒 - 30秒左右）。相比于 FLV， HLS 在 iPhone 和大部分 Android 手机浏览器上的支持非常给力，所以常用于 QQ 和微信朋友圈的 URL 分享。

  • WebRTC：名称源自网页即时通信（Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年06月01日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。快直播正是用的 WebRTC 协议，它是标准直播在超低延迟播放场景下的延伸，比传统直播协议延迟更低，为观众提供毫秒级的极致直播观看体验。 能够满足一些对延迟性能要求更高的特定场景需求，例如在线教育、体育赛事直播、在线答题等。

RTC技术（WebRTC）

  • https://zhuanlan.zhihu.com/p/377100294

  • RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的RTC技术一般指的是WebRTC技术，已经被 W3C 和 IETF 发布为正式标准。

  • 解决什么问题

    • 直播中我们关心的几个点：延迟、质量、成本等。 传统rtmp直播痛点：TCP，延迟高、拥塞导致卡顿问题较多（质量问题）。 互联网网络复杂、延时敏感、实时音视频流畅度及清晰度较低以和运营成本较高等。 没有一项技术能兼顾并解决直播中的所有问题，RTC是时延、流畅、质量、成本等的平衡，成为技术选型落地的模型。

RTC VS RTMP

  • RTC (UDP) VS RTMP (TCP)

  • RTMP只是TCP上的一个标准协议，所以接入是一个标准体系，推流端可以是OBS这种直播软件工具，也可自开发rtmp推流工具，播放端可以是Flash播放器（Adobe 2020 12月份已经弃用）、服务端有技术成熟的CDN技术和设施进行分发、Native的播放器或者flv.js/hls.js这种开源播放器组件，遵循rtmp、flv、hls标准即可，接入成本比较低。而一个完善的RTC服务应用，需要从推流端、服务端、到拉流端，一整套完整的全链路闭环技术。

  • RTC+RTMP

    • 互动连麦+服务端转推rtmp至CDN，CDN分发给观众。

RTC的应用场景

  • 视频会议、在线教育小班课、大班课、1v1视频连麦、多人视频连麦互动、语音聊天室、在线面试、在线医疗、云游戏、智能家居、在线签约、在线K歌等，遍地开花。 比如Zoom、腾讯会议、钉钉会议、微信音视频聊天

RTC服务提供商

  • 声网、腾讯云音视频、即构、阿里云RTC、华为云RTC、微吼VRTC、网易云信RTC、Ucloud RTC、融云RTC、拍乐云等。

腾讯云音视频

  • https://cloud.tencent.com/document/product/267/70440
  • 在开播端，基于实时音视频 TRTC 来实现，通过 TRTC 协议完成主播推流。仅需1个TRTC应用 + 1个推流域名，即可把主播的直播流推流至云端。在观众端，默认情况下，使用 CDN 方式进行拉流观看， CDN 观看费用较低。如果主播端有 PK 需求，直接互相播放对方的流即可。

即构

声网

发表于

JavaCV

常用命令

  • FFmpeg常用命令汇总+文档汇总：https://www.jianshu.com/p/f07f0be088d0

  • ffplay命令播放媒体

    • 播放本地文件 : ffplay -window_title "test time" -ss 2 -t 10 -autoexit test.mp4
    • 播放网络流: ffplay -window_title "rtmp stream" rtmp://202.69.69.180:443/webcast/bshdlive-pc

怎样快速的转换FLV视频为MP4格式

  • https://www.zhihu.com/question/65224766/answer/252226264

  • 单个文件，就用如下命令：
    ffmpeg -i "input.flv" -c copy "output.mp4"

  • 如果是整个文件夹中的所有flv文件需要批量转成mp4，那么使用以下命令：
    for %i in (*.flv) do ffmpeg -i "%i" -c copy "%~ni.mp4"

  • flv/mp4文件的合并有时候通过某些下载工具得到的flv/mp4文件是多段的，比如B站视频上下载一集40分钟左右的纪录片实际上是8个小片段，这时候可以新建一个txt文本文件，把你需要合并的flv/mp4和这个txt放在同一个文件夹里面，然后把需要合并的flv/mp4文件的名字按照顺序写在txt文件中并保存，格式如下：

    file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[00].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[01].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[02].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[03].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[04].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[05].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[06].mp4'
file '【国家地理】COSMOS系列【熟肉-对后十一集修复】 (P10. 气候变化)[07].mp4'

    ffmpeg -f concat -safe 0 -i files.txt -c copy output.mp4即可得到一个完整的mp4文件

rtmp推流

名词概念

  • FFmpeg的名称来自MPEG视频编码标准，前面的“FF”代表“Fast Forward”
  • 解复用(demux)，表示从一路输入中分离出多路流(视频、音频、字幕等)。
    把不同的流从某种容器中解析出来，这种行为叫做解复用(demux)
  • 编解码器(Codec)：以帧为单位实现压缩数据和原始数据之间的相互转换的
  • 复用(mux)：把不同的流按照某种容器的规则放入容器，这种行为叫做复用（mux）
  • 码率和帧率是视频文件的最重要的基本特征，对于他们的特有设置会决定视频质量。如果我们知道码率和时长那么可以很容易计算出输出文件的大小。
  • 帧率：帧率也叫帧频率，帧率是视频文件中每一秒的帧数，肉眼想看到连续移动图像至少需要15帧。
  • 码率：比特率(也叫码率，数据率)是一个确定整体视频/音频质量的参数，秒为单位处理的位数，码率和视频质量成正比，在视频文件中中比特率用bps来表达。
  • https://zhuanlan.zhihu.com/p/117523405

FFMPEG 中I帧、B帧、P帧、PTS、DTS

  • https://www.jianshu.com/p/2cfc19b4938c
  • I帧表示关键帧，又称intra picture，I帧画面完整保留，解码时只需要本帧数据就可以完成（因为包含完整画面）。
  • P帧前向预测编码帧 又称predictive-frame，表示的是这一帧跟之前的一个关键帧（或P帧）的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。（也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据）
  • B帧双向预测内插编码帧 又称bi-directional interpolated prediction frame，是双向差别帧，也就是B帧记录的是本帧与前后帧的差别，换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时CPU会比较累。
  • 因此，I帧和P帧的解码算法比较简单，资源占用也比较少，I帧只要自己完成就行了，至于P帧，也只需要解码器把前一个画面缓存一下，遇到P帧时就使用之前缓存的画面就行。如果视频流只有I和P，解码器可以不管后面的数据，边读边解码，线性前进。如果视频流还有B帧，则需要缓存前面和当前的视频帧，待后面视频帧获得后，再解码。

ffmpeg/ffplay/ffprobe区别

  • ffmpeg:
    Hyper fast Audio and Video encoder
    超快音视频编码器（类似爱剪辑）
  • ffplay:
    Simple media player
    简单媒体播放器
  • ffprobe:
    Simple multimedia streams analyzer
    简单多媒体流分析器

播放软件推荐：VLC

  • 要播放视频直播流，或者测试一个直播视频地址是否可以使用。这里推荐 VLC 媒体播放器。功能强大且跨平台。支持 Windows、Mac OS、Linux、Android、iOS。
    官网地址：http://www.videolan.org/
    打开播放器，选择菜单中“媒体”->“打开网络串流…”。在弹出页面中填入视频地址即可。
  • windows 录屏软件Captura – TODO
  • FFmpeg最全教程：https://cloud.tencent.com/developer/article/1773248
  • FFmpeg jar 库，无需安装 –TODO javacv
  • ​ffprobe 是一个多媒体流分析工具。它从多媒体流中收集信息，并且以人类和机器可读的形式打印出来。它可以用来检测多媒体流的容器类型，以及每一个多媒体流的格式和类型。它可以作为一个独立的应用来使用，也可以结合文本过滤器执行更复杂的处理。

发表于

视频直播的实现原理

  • 网络协议-流媒体协议
  • 首先，网络协议将编码好的视频流，从主播端推送到服务器，在服务器上有个运行了同样协议的服务端来接收这些网络包，从而得到里面的视频流，这个过程称为接流。
  • 服务端接到视频流之后，可以对视频流进行一定的处理，例如转码，也即从一个编码格式，转成另一种格式。因为观众使用的客户端千差万别，要保证他们都能看到直播。流处理完毕之后，就可以等待观众的客户端来请求这些视频流，观众的客户端请求的过程称为拉流。
  • 如果有非常多的观众，同时看一个视频直播，那都从一个服务器上拉流，压力太大了，因而需要一个视频的分发网络（CDN），将视频预先加载到就近的边缘节点，这样大部分观众看的视频，是从边缘节点拉取的，就能降低服务器的压力。
  • 当观众的客户端将视频流拉下来之后，就需要进行解码，也即通过上述过程的逆过程，将一串串看不懂的二进制代码，再转变成一帧帧生动的图片，在客户端播放出来，这样你就能看到直播视频啦。

基本概念

转码

  • 转码是将视频码流转换成另一个视频码流的过程，是一种离线任务。通过转码，可以改变原始码流的编码格式、分辨率和码率等参数，从而适应不同终端和网络环境的播放。使用转码功能可以实现：
    • 适配更多终端：将原始视频转码成拥有更强终端适配能力的格式，使视频资源能够在更多设备上播放。
    • 适配不同带宽：将视频转换成流畅、标清、高清或超清输出，用户可根据当前网络环境选择合适码率的视频播放。
    • 节省带宽：采用更先进的编码方式转码，在不损失原始画质的情况下显著降低码率，节省播放带宽。

视频编码

  • H.265是新的编码协议，也即是H.264的升级版。H.265标准保留H.264原来的某些技术，同时对一些相关的技术加以改进。
  • 视频编码：指通过特定的压缩技术，将某个视频格式的文件转换成另一种视频格式文件的方式。常见的音频视频编码有MPEG系列与H.26X系列。

容器

  • https://blog.csdn.net/lxc1014/article/details/45666281
  • mp4,rmvb,mkv,avi从形式上来说首先都是视频文件的扩展名，其次它们也是视频文件的封装格式（即容器）， mp4是MPEG-4标准的第14部分所制定的容器标准。所谓容器，就是把编码器生成的多媒体内容（视频，音频，字幕，章节信息等）混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条（当然这种情况下有的播放器会话比较长的时间临时创建索引），而且如果你不自己去手动另外载入音频就没有声音。

普通直播

  • 直播类应用在产品功能上基本是这两类：
    • 1、直播的基础功能：连麦互动直播（支持多码率、多协议）等非功能性需求。— 流相关服务
    • 2、应用本身的个性化功能：比如答题场景中的发题目、作答、公布答案等。— 长连接相关服务

多人连麦/PK/聊天

  • 直播多人连麦技术简介
  • 直播连麦技术对比-互动直播调研必看
    • 基于WebRTC和RTMP结合的方案
    • 基于RTC的方案(声网、即构)
    • anyRTC直播方案
  • 直播连麦技术方案对比及测试方法
    • SD-RTN™:这是声网的连麦架构，直播连麦的鼻祖。基于UDP，主播端、连麦端、观众端都在基于SD-RTN™进行实时通信，大大降低延时。主播端和连麦端也可以转码到CDN推流。
    • RTMP改进方案:基于TCP协议，基本思路是：主播接受连麦嘉宾的视频，在本地合图；主播和连麦嘉宾的视频同时传到服务端合图，然后通过CDN推到观众端。
    • WebRTC改进:主播和连麦嘉宾，基于WebRTC进行“视频会议”，将“视频会议”在服务端合图后推到CDN进行分发。

传统直播形式

  • 一个主播推流，广播给直播间所有的观众。一个直播间对应一个主播，并且仅有一路推拉流。
  • 基于协议RTMP做的单路直播互动。该模式下主播一个人表演，其他观众根据IM系统跟主播进行文字互动。
  • 总结：主播端推一路流，观众端CDN拉一路流。

连麦直播形式

  • 两个主播（另一个主播可能是观众）推流，广播给直播间所有观众。
  • 基于UDP做的多路实时互动直播。该模式下主播跟观众除了基于IM系统沟通外，还可以进行音视频互动，极大的方便了观众，互动效果更直观，更能有效吸引用户。

1基于RTMP协议优化方案

  • 主播A和主播B之间通过原有的推拉流路径去拉取对方的流内容。也就是说，主播A在推流同时，拉取主播B的流，主播B推流的同时拉取主播A的流。对于两个主播来说互为对方的观众。此时对于直播间内的其他观众而言，是分别拉取主播A和主播B的流，并展示出来。
  • 在此基础上可以进一步对主播两路流做混流，这样观众端只需要拉一路流。
  • 混流：可以在服务端做，也可以在其中一个主播的客户端做混流再推流（对主播设备性能有一定要求）

2基于P2P协议方案

  • 此方案的实现方式是，主播A和主播B之间通过P2P协议进行音视频连接，正常情况下能够保证较低的延迟，保证主播A和主播B之间的互动。主播A在自己的流内容基础上加入主播B的流内容，统一推向服务端。此时直播间内仅有一路流，并且其他观众也只需要拉取这一路流内容。
  • 此方案的优点是显而易见的，主播AB之间的延迟降低，交互体验好，观众保持原有逻辑不变，拉取直播间固定流地址。但是缺点是：主播A在连麦过程中需要承担两路推流一路拉流的压力，即拉取主播B的流内容，将自己的流内容推给主播B，将主播A和主播B的流内容推给服务端；主播A的网速压力和性能压力将会巨大，同时主播AB之间一对一的连接也导致扩展性较差，无法满足2人以上的业务场景需求。

3基于多人视频通话系统方案 （目前主流）

  • 此方案的实现方式是将主播A和主播B的视频交互交由第三方处理，目前比较成熟的技术有视频会议系统和Google开源的WebRTC系统。在此架构下，主播A与主播B的流合成处理上传都是由这个交互系统完成。此方案对于方案2来说减轻了主播端的压力，并且采用UDP协议传输方式降低延迟。同时也兼容多人连接交互。
  • 此方案缺点是对服务端开发量大，要求高。

第三方支持

推流

混流

  • 混流就是把多路音视频流合成单流。准确的说，混流应该叫做混音（音频流）混画（视频流）混流的过程包括解码、混流、编码和推流四个部分。混流这个环节包括做动冲，目的是把多路流进行画面对齐和音画同步，同时通过缓冲对抗网络抖动，以便混合成一路流以后能够达到良好的效果。在混流的过程中，难点是如何对抗网络抖动等不确定因素。

不混流的优势和劣势

  • 不混流的优势

    • 延迟低：不用混流，节省了混流消耗的时间，显著地降低了延迟
    • 成本低： 如果是在服务端进行混流，将会耗费计算资源。考虑到服务端计算资源比较昂贵，如果不用混流，将会节省宝贵的计算资源，显著地降低成本。虽然拉多流比起拉单流会消耗更多的带宽成本，但是拉多流节省计算资源成本，整体而言，成本是降低了。
    • 灵活性:在观众端，业务侧可以比较灵活的操控多路流，来满足多样化的业务需求。比如画中画大小画面相互切换，和对半分屏画面左右调换等效果，来提高观众端的用户体验。

  • 不混流的劣势

    • 拉多流会消耗更多的带宽。多路流被从服务端推到CDN, 然后观众端从CDN拉多流，都会耗费比较多的带宽成本。对于带宽成本占了运营成本显著，的确是需要慎重考量的。

  • 混流的优势

    • 成本：可以分为计算资源成本和带宽成本。由于预先做混流，因此计算资源成本会上去，但是由于只拉单流，因此带宽成本会下来。
    • 可录制：如果业务上有录制音视频流的需求，以备监管抽查或者观众回放的话，那么需要进行混流。如果不进行混流的话，录制的时候只能录制到其中一个路音视频流，也就是只能看到其中一个主播的画面。要录制全画面的话，必须要进行混流。
    • 易传播：如果业务上有通过音视频流地址链接(HLS)进行转发传播的需求，那么也需要进行混流，因为地址链接只会指向一路音视频流。如果不混流，使用转发的地址链接就只会播放出一个主播的音视频流。

  • 混流的劣势

    • 高延迟：由于在做混流的过程中，需要做抖动缓冲和实时转码等计算处理，将会耗费时间，从而造成额外的延迟。
    • 不灵活：由于观众端拉单流观看，多路音视频流已经被混合成单流，所以观众端无法再灵活地对多流进行操控，比如切换画中画的主次画面。
    • 服务器计算成本高：由于混流需要额外的计算资源，这里会导致额外的运营成本。

  • 服务端混流的优势

    • 低延迟
    • 计算资源可控
    • 网络带宽资源可控
    • 可控可扩展

  • 服务端混流的劣势

    • 服务器计算成本高
    • 服务端压力大

  • 混流工具: FFmpeg

    • 混流命令: ./ffmpeg -i “背景图” -i “rtmp://输入流1” -i “rtmp://输入流2” -filter_complex “nullsrc=size=1600x720 [base];[0:v] scale=1600x720 [main]; [1:v] crop=320:180:0:0 [photo1];[2:v] crop=320:180:0:0 [photo2];[base][main] overlay=x=0:y=0 [temp];[temp][photo1] overlay=x=1280:y=0 [temp1];[temp1][photo2] overlay=x=1280:y=180 [temp2]” -c:v libx264 -r 50 -bufsize 10M -f flv “rtmp://推流地址”
    • 录制命令: ./ffmpeg -i rtmp://混流地址 test.mp4

  • 基于FFmpeg混流及录制rtmp直播流

混音

  • 实时音频的混音在视频直播中的技术原理和实践总结
  • 混音，顾名思义，就是把两路或者多路音频流混合在一起，形成一路音频流。实时音频混音，指的只是音频流的混合。
  • 混音的逻辑可以在终端设备上实现，也可以在服务器上实现，因此可以分为终端混音和云端混音。终端混音一般应用于背景配音，音乐伴奏等场景。云端混音可以是云端混流的一部分，主要目的是利用云端的计算能力去做多路音视频流的音画对齐，还有降低下行带宽成本；也可以做纯粹的云端混音，来实现合唱直播等场景的需求。

实现例子1

  • 火爆的直播应用，你了解背后的技术架构吗？:https://mp.weixin.qq.com/s/2ucFww9MEdsKbMO8Wepg1A
  • 音视频流采用了腾讯云的直播解决方案，而业务数据流（活动、题目、答案、弹幕、红包等）则采用了自研的长连接方案。

产品功能

  • 直播类应用在产品功能上基本是这两类：
    • 1、直播的基础功能：连麦互动直播（支持多码率、多协议，多主播同框）、美颜特效、弹幕、IM聊天、点赞、屏幕共享等功能性需求，以及防盗链、涉黄涉政鉴别等非功能性需求。
    • 2、应用本身的个性化功能：比如答题场景中的发题目、作答、公布答案，电商场景中的商品展示、一键下单购买，网红直播场景中的礼物打赏。

面临的技术挑战

  • 音视频处理及传输：涉及音视频编码、实时美颜、视频推流、CDN加速分发、终端适配和播放，流量统计等诸多技术点
  • 高带宽压力：按照标清视频的标准，观看直播的码流至少为1Mbps，如果100W用户在线，光视频流的出口带宽能达到976.56G bps。1条弹幕可达到130字节，1秒要滚屏20条弹幕，如果需要同时推送给100W用户，弹幕的出口带宽也将达到19.37G bps.
  • 低延迟性要求：直播场景下如何整合视频流和业务数据流，做到声音、主播画面和题目同步，以保证用户体验

音视频处理及传输的方案选型

  • 第三方支持方案：音视频处理及传输，可以使用腾讯云的直播解决方案。主持人侧：通过演播室的专业摄像设备，搭载腾讯云提供的obs推流软件，即可进行视频录制和推流。用户侧：APP端集成腾讯云的SDK，动态拿到推流地址后即可观看直播。

业务数据流的方案选型

  • 业务数据是指除音视频以外的，和答题应用场景相关的数据（比如题目、答案、弹幕、红包等）。腾讯云提供了两种可选方案：
    • 1、题目预先设置好，直接由腾讯云的SDK通过音视频通道下发，打入直播流中。
    • 2、让题目先通过腾讯云的IM通道快速送达观众端APP，在观众端先缓存下来，等待播放器通知了预期的 NTP 时间戳之后，再把题目显示出来。
  • 自研业务数据流通道。这样视频流和业务数据流会分两个通道下发，因为业务流相对视频流的数据量很小，只要能保证业务逻辑的处理速度和业务数据的下行速度，“音-画-题”的延迟是可以接受的。毕竟当时已经是4G时代，如果用户侧的网速不行，视频流可能都无法正常观看了。

长连接、高性能的网关服务器

  • （支持100W用户同时在线，20W并发答题，弹幕实时推送等要求），我们的技术选型是：Netty、ProtoBuf、WebSocket，选型理由：
  • 1、Netty：Netty是当时最流行的高性能和异步NIO框架，直播答题的业务场景中，涉及到题目下发、弹幕、下红包雨等非常多的推送场景，而且一场答题活动中，客户端和服务端的通信频繁，长连接比短连接在性能上更优。
  • 2、ProtoBuf：作为客户端和服务端的数据交换格式，PB是一种效率和兼容性都很优秀的二进制数据传输格式，在码流和序列化速度上明显优于JSON、XML、hessian等主流格式，同时支持向前向后兼容以及各种主流语言。
  • 3、WebSocket：是 HTML5 一种新的协议，用来实现客户端与服务器端的长连接通讯。
    • 为什么使用WebSocket不使用TCP呢？TODO

基于TCP长连接的通信架构

  • 上面的通信架构用于业务数据流的传输，流程如下：
    • 1、客户端使用websocket与服务端进行通讯，用户进入答题直播间时建立连接，退出直播间时断开连接。
    • 2、Nginx对websocket做负载均衡。
    • 3、TCP网关基于netty实现，用于维持长连接和转发业务请求，不负责具体的业务逻辑，它和下层业务系统（答题系统）通过RPC接口进行交互，主要考虑后续其他业务可以复用TCP网关层，所以将业务下沉。客户端和网关之间通过心跳机制保证连接的有效性以及检测僵尸连接。
    • 4、消息推送（比如弹幕、下发题目、公布答案等诸多场景）由下层业务（答题系统）通过MQ通知TCP网关，再由TCP网关推送给客户端。

长连接通信中的数据传输格式定义

  • 客户端请求消息的格式
  • 客户端响应消息的格式

直播架构简单总结:

  • 1、音视频编码和传输，这些基础性的直播功能，除非公司有钱有实力，否则建议直接用腾讯云或者阿里云的解决方案（斗鱼、蘑菇街这些知名的直播应用都还用的腾讯云）。
  • 2、架构设计重点放在应用本身，根据直播应用的用户量级和业务特性先确定通信架构（长连接还是短链接，或者两者混用）。

实现例子2

  1. 开发成本高、周期长
    • 实时音视频技术栈包含音视频编解码、音视频前后处理、信令、网络传输、高并发、高可用、系统监控、多个平台的终端开发，技术储备和开发成本是非常大的挑战。
  2. 弱网环境下的音视频质量
    • 现实的网络环境非常复杂、用户使用中小网络运营商的服务，存在着非常多的不确定性，或多或少的丢包、不确定的网络延时和抖动。
  3. 终端极致的性能要求
    • 多人同屏视频连麦的直播间，面对终端有限的算力、内存，实时音视频终端软件架构的设计会对通信的质量、时延都带来影响。

  • 一套互动直播相亲交友程序源码主播端到观众端有下面几个步骤：

    • 1、视音频信号实时采集；
    • 2、经过预处理和音视频编码；
    • 3、封装发送到CDN源站；
    • 4、播放端从CDN边缘拉到数据；
    • 5、然后进行解码；
    • 6、经过音视频同步之后；
    • 7、给观众展现出来。

  • 互动直播相亲交友系统的主要技术难点在于：

    • 1）低延迟互动：保证主播和互动观众之间能够实时互动，两者之间就像电话沟通，因此必须保证两者能在秒级以内听到对方的声音，看到对方的视频；
    • 2）音画同步：互动直播中对音画同步的需求和单向直播中类似，只不过互动直播中的延迟要求更高，必须保证在音视频秒级传输情况下的秒级同步。
    • 3）音视频实时合成：其他观众需要实时观看到对话结果，因此需要在客户端或者服务端将画面和声音实时合成，然后以低成本高品质的方式传输观众端。

实现实例3

  • 会议系统

  • https://www.juhe.cn/news/index/id/1568

  • 缺点：

    • 会议系统很大程度上依赖专线服务，成本过高；
    • 会议系统很多不能在服务器做转码合成视频，对主播设备依赖过大。因为合图视频主要是由主播端编码、推送到CDN，一部分需要主播设备比较高端，另外需要主播网络比较好，否则依然解决不了连麦问题

  • RTC技术（WebRTC）

扩展

其他

  • 播放网络视频，通常解析库我们可以有多个选择，如FFMPEG，Daniulive SDK 或者 vitamio。
  • [H5 直播流播放器 Jessibuca]

Reference