摘要

随着GPT-4的发布，AI的风越吹越旺。GPT-4可以回答问题，可以写作，甚至可以基于一张草图生成html代码搭建一个网站。即构社区的一位开发者@倪同学就基于目前在研究的WebRTC QOS技术点对GPT-3.5跟GPT-4进行一场实验，ChatGPT会取代程序员还是成为最强辅助？

以下为@倪同学的博文。

ChatGPT取代程序员还是给程序员加Buff？

这两周，AI新闻一个接着一个，3月23日，Google开放了内测已久的AI对话服务Bard，Google强调，这是一款定位为用户提供创意之源的产品，可生成写作草稿或生活中的聊天机器人。早在一周前3月15日凌晨，OpenAi距发布GPT-3.5后四个月发布了升级版模型GPT-4，据发布会说，GPT-4可支持图片输入，角色扮演，写作能力更强了。紧接着3月16日百度发布了文心一言，一共有五大功能：文学创作、商业文案创作、数理逻辑推算、中文理解、多模态生成。

随着近日各大厂商AI产品的接连发布，
AI取代人工
这个话题持续在发酵。AI大幅解放人的生产力或是将冲击一大批职业？

博主近期在输出WebRTC相关的技术博客，不如向AI提问看他有什么见解。

和大部分人一样，博主都还没拿到Bard跟文心一言的内测资格。得知NewBing用的是GPT-4的模型，下面就着
WebRTC通过哪些QOS技术提升音视频通话质量
，向GPT-3.5和Newbing（GPT-4）分别提问，看看他们的答案有何差异。

如下图，技术科普类问题都难不倒GPT-3.5和GPT-4，我就该问题继续深挖让它们举实例说明：

NewBing(GPT-4)

GPT-3.5给出的结果

NewBing(GPT-4)直接给出了具体操作实例

GPT-3.5给出的结果（有些空泛）

GPT-4和GPT-3.5对比结论

通过实验，我们比较了同一问题两个版本的回答。在普通的文本处理当中，GPT-4和GPT-3.5的区别可能比较小，但是当问题足够具体和复杂时，GPT-4就会比GPT-3.5更精准、更有创意，而且能够处理用户更细微的指令。

当然，本篇内容不是要讨论GPT-3.5跟GPT-4的具体差别，而是程序员如何利用ChatGPT提升工作效率，加上最强Buff。以下我将以个人开发经验为音视频开发者分享《
WebRTC的QOS如何提升音视频质量》。

WebRTC技术概述

WebRTC 通过一系列的QOS 技术来提升音视频通话质量: 抗丢包策略(NACK、 FEC), 拥塞控制策略(TWCC/REMB), SVC或多视轨, 视频质量自适应策略， Pacer、JitterBuffer等.

总体QOS架构如下图所示：

图 1

1
丢包恢复策略

1.1 NACK

NACK(Negative Acknowledgment)相较于ACK是通过"非到达确认"进行选择性重传的机制。基本原理是发送端对数据进行缓存，接收端通过到达包连续性检测丢包，结合rtt 和乱序情况在合适的时机向发送端发起重传请求。

图 2

如图所示,Receiver在收到报文4之后发现报文2、3未到达，暂时将报文2、3放入丢失nack列表。在超过一定乱序阈值(通过乱序直方图计算得到，假设这里是2，那么收到包4可认为包2丢失)，或者超过一定抖动时间(根据rtt计算)，向Sender请求重传丢失的报文2、3。 Receiver的请求通过RTP FB 发送给Sender, 具体NACK 请求格式参考RFC4585。Sender 在收到NACK请求后重新发送报文2、3。

值得注意的是
，NACK 策略丢包恢复效果取决于重传请求时机。一是rtt的计算(webrtc 默认rtt是100ms)，一是乱序阈值计算。重传请求节奏控制不好容易造成重传风暴，加重拥塞导致拉流出现卡顿。

参考：
https://www.rfc-editor.org/rfc/rfc4585.html#page-34

1.2
FEC

FEC(Forward Error Correction),前向纠错, 在数据传输和存储中普遍用于数据纠错。WebRTC中也使用了该技术进行丢包恢复。

webrtc实现该冗余功能，有三种方式：

1.2.1、RED

将前面的报文直接打入到新包里面，在接收端解析主包和冗余包。

图 3

如图，后面的报文直接包含前面报文，所以当其中某个报文丢失了，可以通过其相邻报文直接恢复。这种方式缺点是抗连续丢包效果差，但是实现简单。

Opus In-band FEC 正是使用这种方式进行纠错： 将重要信息以较低的比特率再次编码之后添加到后续数据包中，opsu 解码器根据收包情况决定是否利用当前包携带的冗余包进行丢包恢复。

Opus In-band FEC 详细参考：
https://datatracker.ietf.org/doc/html/rfc6716#section-2.1.7

RED 详细介绍参考：
https://www.rfc-editor.org/rfc/rfc2198.html

1.2.2、ULPFEC

在多个数据包之间使用 XOR 来生成此冗余信息，并能够在需要时在接收方恢复丢失的数据包。 ULPFEC 能够通过选择受保护的字节数并应用 XOR 的先前数据包的数量，为不同的数据包提供不同级别的保护。

图 4

如图，FEC packet 1 保护L0级报文A、B。 FEC packet 2 及保护L0级的A、B, 也保护L1级报文C、D。

参考：
https://www.rfc-editor.org/rfc/rfc5109.html

1.2.3、FLEXFEC

较ULPFEC，FLEXFEC可以灵活选择1D行异或、列异或以及2D行列异或，增加网络抗丢包能力。

1-D 行异或纠错

图 5

1-D 列异或纠错

图 6

2-D 行列异或纠错

图 7

FLEXFEC 虽然相比前面两个有更强的恢复能力，行列交错丢包比如图7中(1、2、5、6)丢失就会出现无法纠错的情况。

WebRTC 用到FEC策略整体丢包恢复能力都偏弱，业界普遍应用Reed-Solomon FEC 进行丢包恢复，Reed-Solomon FEC(K + N : K个数据包 N个FEC包)可以真正恢复分组内任意 <=N 个丢包。

FLEXFEC 详细实现可以参考：
https://www.rfc-editor.org/rfc/rfc8627.html

2 带宽评估及码率控制

2.1 REMB-GCC

图 8

图8是REMB-GCC 架构图，基本思想是通过接收端评估带宽， 然后通过RTCP REMB 将带宽反馈给发送端。 发送端结合丢包率计算一个带宽结果As,和RMEB的结果Ar, 取min(As, Ar)作为最终带宽结果。

2.2 SendSide BWE

图 9

跟
REMB-GCC
相比，TFB-GCC 主要区别在于大部分带宽计算都转移到发端计算，滤波器的实现不再用Kalman 滤波 而是变成
TrendLine 滤波器
。

发送端发送的包需在扩展头带： Transport-wide sequence number.

接收端定期发送Transport-wide feedback报文，通知发送端和接收端接收报文的相关信息，包括报文到达时间、报文到达时间、报文格式等信息。发送端收到Transport-wide feedback 报文之后，根据报文携带的信息进行延迟滤波计算(Trandline).

Transport-wide feedback 报文格式参考：
https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01

2.3 速率控制

图 10

图 11

根据过载检测器产生的信号 s，驱动如图10所示的有限状态机来调整码率。

GCC 算法原理详细参考：
https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf

3
SVC
、多视轨

3.1
SVC

SVC (Scalable Video Coding，可适性视频编码或可分级视频编码) 是传统 H.264/MPEG-4 AVC 编码的延伸，可提升更大的编码弹性，并具有时间可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability) 及质量可适性 (SNR/Quality/Fidelity Scalability) 三大特性。

WebRTC 中h264 不支持svc 编码，Vp8 仅支持Temporal Scalability, VP9 和AV1 支持时间可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability)。

图12

上面是时间可适应示意图。假设图例中显示的图层以30 fps的帧速率显示。如果我们移除所有L2层的图片，剩下层（L0和L1）仍然可以成功解码，并且产生一个15fps的视频。如果我们进一步删除所有的L1图像，那么剩下的L0层依然可以被解码并产生一个7.5fps的视频, 所以即便是出现丢包，相比不可分级编码可明显提升弱网视频流畅度。

图 13

如图12，L0基层为分辨率最小编码数据，级别越高，分辨率越高。当实际应用中需要较低分辨率时，只需丢弃高Level层级数据进行解码。

针对不同的带宽条件用户和以及不同设备性能的用户可以灵活调整分辨。

SVC 扩展参考：
http://ip.hhi.de/imagecom_G1/assets/pdfs/Overview_SVC_IEEE07.pdf

SVC 与 H264 结合参考：
https://www.itu.int/rec/T-REC-H.264-201704-I

3.2 多视轨

目前主流浏览器都支持unified-plan sdp, 我们可以在sdp协商的时候添加多个视轨，业务上比较常见的就是添加两条视轨(类似于SVC的Spatial Scalability)，复用相同DTLS 传输通道。

图 14

图12 典型利用WebRTC 支持多视轨特性编码一大一小两条流的出帧示意图。

支持多视轨(大小流) 可以让接收端在下行带宽受限的情况下动态切换到可以支持的分辨率，提升弱网体验。

多视轨(大小流)在对网络丢包及带宽受限情况的适应不如SVC 灵活，但是多视轨实现简单，编码、解码性能消耗较低，在实际的业务场景中得到广泛应用。

多视轨需要支持Unified Plan SDP 协商, 参考WebRTC 相关说明：
https://webrtc.github.io/webrtc-org/web-apis/chrome/unified-plan/

4 视频质量调整策略

在网络传输质量变差(上行带宽不足)、CPU占有率过高，编码器编码质量QP值过大等情况下，WebRTC会通过降质量来保障视频通话。降质量策略主要分降帧率(即清晰优先模式)和降分辨率(即流畅优先模式)，通过MediaStreamTrack Content Hints 来设置。

清晰优先模式
WebRTC 在编码的时候更注重视频细节，在出现上述情况需要降质量时，会通过降低帧率、保持分辨率不变来保障拉流用户的主观感受。对于推流端做屏幕分享内容是PPT或者拉流用户大屏显示的业务场景尤为重要。

流畅优先模式
推流端在需要降质量的时候优先降低分辨率、保持一定的帧率来保障拉流用户的流畅体验。

在带宽或CPU资源等不再受限时，WebRTC会根据降质量偏好设置逆向提升视频质量。

使用者应该根据自己的业务场景进行适当设置，才能在极端情况下保证主观体验不至于太差。

5 Pacer

WebRTC 的Pacer 模块主要是让需要发送的包根据评估的网络带宽尽量均匀的分布在每个发送时间窗口发出，起到平滑发包、避免网络拥塞的作用。

假设有一条 5Mbps 和 30fps 的视频流。 在理想情况下，每个帧大小约为 21kB，打包成 18 个 RTP 数据包。 按照一秒时间窗口统计的平均比特率是 5Mbps，但在更短的时间范围内，它可以被视为每 33 毫秒突发 167Mbps。 此外，视频编码器在突然移动的情况下会超过目标帧率，尤其是在处理屏幕共享时，帧比目标尺寸大 10 倍甚至 100 倍很常见。 这些数据包如果编码完成马上发出去会导致几个问题: 网络拥塞、缓冲区膨胀、甚至数据包丢失。 大多数会话都有不止一条媒体流，可能同时包含音频流、视频流、数据流。 如果你一次性将一个帧放在一条传输通道发送，这些数据包需要 100 毫秒才能发出，这可能阻止了任何音频数据包及时发送出去。 Pacer通过有一个缓冲区来解决这个问题。 媒体包在其中排队，然后使用漏桶算法将它们调整到网络上。 缓冲区包含所有媒体轨道的独立 fifo 流，例如 音频可以优先于视频 - 可以以循环方式发送相同优先级的流，以避免任何一个流阻塞其他流。

图 15

6 JitterBuffer

图 16

WebRTC 接收端收到RTP包后，放到PacketBuffer 进行缓存和排序。如上图，在收到Mark(帧结束)标志之后，从后往前开始组帧。组完一帧会放到该帧所在GOP的缓存里面，根据帧间参考顺序进行调整，当帧间参考关系建立好之后就会放到解码器进行解码。可以认为Jitter 主要先后做包排序、帧排序、GOP排序。之所以要进行着一系工作是因为网络本身存在一定的抖动、甚至有丢包，如果有丢包还得等丢包恢复才能完整组帧，所以导致帧到达时间跟发送时间存在一定抖动。Jitter buffer 的存在就很好的解决这个问题，能够在拉流端对待解码数据进行平滑处理，保证我们渲染出来视频是平滑、流畅的。

7 关键帧请求

视频流通常是以1个关键帧+ N个增量帧的方式发送，这些增量帧依赖于先前的帧进行解码和显示。如果因为一些原因导致sps/pps 丢失、 组包错误等，如果不采取任何补救措施，就很难继续解码视频流，视频就会卡主, 直到下个关键帧。很多时候为了编码稳定GOP设置很大，这个时候意味着长时间卡顿或者黑屏。

图 17

如图接收端因为丢包不能恢复导致Frame 9 组帧失败，后面即使能组帧成功也无法解码，此时需要从发送端请求一个I帧解码刷新当前视频流。

WebRTC通过RTCP报文向发送端请求发送关键帧，关键帧请求RTCP报文格式比较简单，在
RFC4585
（RTP/AVPF）以及
RFC5104
（AVPF）规定了两种不同的关键帧请求报文格式：Picture Loss Indication (PLI)、Full Intra Request (FIR)。从目前的实现看WebRTC 在收到PLI或者FIR之后，都是让编码器编码输出关键帧，然后发送给接收端。

PLI 报文格式参考：
https://www.rfc-editor.org/rfc/rfc4585.html#page-36

FIR参考：
https://www.rfc-editor.org/rfc/rfc5104.html

QOS技术总结：

本文简单介绍了WebRTC中所使用到的Qos技术，这些技术从不同的角度去提升Qos质量。包括通过
NACK、FEC
技术对丢包进行恢复，解决丢包导致的音、视频卡顿。通过
带宽评估和拥塞控制
技术调整编码和发送码率来自动适应网络带宽的变化情况。通过SVC、多视轨技术保障不同网络质量的拉流的用户差异的视频质量。 而
Pacer、JitterBuffer
分别在发送端和接收端提升音视频的平滑、流畅度。
关键帧请求
对极端网络抖动之后的快速视频恢复起了重要作用。WebRTC 利用这些技术协同作用，提升整体的Qos 质量，需要了解技术细节最好的方式还是去阅读WebRTC源码。

WebRTC 的Qos技术对提升整体音视频质量效果显著、但WebRTC的这些技术还是存在有很多可以优化的地方。音视频厂商ZEGO即构自研的WebRTC网关对这些策略都做了一定的优化：包括自研带宽评估算法、NACK算法、大小流等。

所以，如果你的业务需要一款稳定可靠的音视频服务，可以试试即构实时音视频RTC服务。

点击跳转
ZEGO即构实时音视频服务
了解更多WebRTC最佳实践内容。

背景:

当前身份缓存对象顾名思义就是:当前登录的用户身份对象,那它解决了什么问题呢?其实在我们日常开发过程中经常能用的到几乎是必备的,就比如我给某个表插入数据时需要创建人或者一些权限的访问,都得用到当前身份缓存对象,当然啦今天的博客就是因为我们公司研发部门刚成立不久所以导致很多项目不完善,我在开发过程中就遇到了没有当前身份缓存对象的问题,开发极其不方便啊哈哈,所以我打算自己整一个,所以就有了今天的这篇文章,希望在对屏幕前的你也有所帮助!!

思路:

我们登录后一些必要的用户数据存到Token中,我们只需要在请求头中拿到Token并将它解析出来,再通过数据库查询出来即可,做的好一点可以配合上Redis,但是不用Redis也无伤大雅,当然也会遇到一些小问题,比如HttpContext对象如何获取,我在这里的解决方案是,定义一个静态类然后在请求管道中拿到服务容器,再通过服务容器拿到IHttpContextAccessor
服务,再点出HttpContext,再拿到请求头,是不是很简单,那我们就直接步入正题吧!!!各位看官献丑了哈哈哈哈

正题:

1.创建静态类ServiceLocator获取服务容器:

在这里解释一下为什么不直接注入IHttpContextAccessor服务再通过构造函数获取,因为这过程中会有遇到一个问题,在静态类中是不能有构造函数的,如果是直接把这个服务容器拿过来就可以完美的解决这个问题,先不着急在下面会体现(第三和第五点)

1 public static classServiceLocator2 {3         public static IApplicationBuilder?Builder;4     }

2.在请求管道中赋值

1 var app =builder.Build();2 ServiceLocator.Builder = app;

3.创建HttpContext类并通过IHttpContextAccessor服务获取HttpContext

1         /// <summary>
2         ///Http上下文对象3         /// </summary>
4         public static HttpContext HttpContext => ServiceLocator.Builder!
5 .ApplicationServices6             .GetRequiredService<IHttpContextAccessor>()7             .HttpContext;

4.创建Jwt帮助类,代码如下:

1  public static classJwtHelper2 {3         /// <summary>
4         ///解密Token成字典5         /// </summary>
6         /// <returns></returns>
7         public static Dictionary<string, string> GetTokenValue(stringtoken)8 {9             var st = newJwtSecurityTokenHandler().ReadJwtToken(token);10             var claims =st.Claims.ToList();11             var res = new Dictionary<string, string>();12             claims.ForEach(d =>
13 {14 res.Add(d.Type, d.Value);15 });16             returnres;17 }18 
19     }

5.创建当前身份缓存对象帮助类并将Token中信息解析,并查询响应

1  public static classCurUserInfoHelper2 {3         /// <summary>
4         ///当前身份缓存对象5         /// </summary>
6         public static SysUserOutputWebDto? CurUserInfo =>GetCurUserInfo();7 
8         /// <summary>
9         ///获取当前用户身份缓存对象10         /// </summary>
11         /// <returns></returns>
12         public staticSysUserOutputWebDto GetCurUserInfo()13 {14             var result = newSysUserOutputWebDto();15             var httpContext =HttpContextHelper.HttpContext;16             var headrs =httpContext.Request.Headers;17             var authorization = headrs["Authorization"];18             string token = authorization!;19             if (token.Contains("Bearer"))20 {21                 string[] tokenStr = authorization.ToString().Split(' ');22                 token = tokenStr[1];23 }
　　　　　　　　　//解密24             var claims =JwtHelper.GetTokenValue(token);25             var userId = claims["UserID"];26             if (!string.IsNullOrEmpty(userId))27 {28                 //非构造函数式注入服务
29                 var serviceScope = ServiceLocator.Builder!.ApplicationServices.CreateScope();30                 var sysUserEntityBL = serviceScope.ServiceProvider.GetService(typeof(ISysUserEntityBL)) asISysUserEntityBL;31 
32                 var sysUser = sysUserEntityBL!.GetSinge(d => d.Id ==userId);33                 result = sysUser.AsOutputWebDto();//Entity转换为输出型Dto
34 }35             returnresult;36 }37 
38     }

6.直接使用即可

1 var curUser =CurUserInfoHelper.CurUserInfo;

效果如下图:

结尾:

今天的内容承接上篇Jwt加密篇,如果过程中有不清楚或者中断的地方可以回顾下上篇文章,也欢迎私信请教,或者在评论区探讨,本人还是个初入职场的小白如有不足的地方也希望大佬们能及时指出,好啦今天的内容就到这里了哦,如果对你有帮助就点个攒支持一下吧嘻嘻

最近阅读了elasticsearch的官方文档，学习了它的很多特性，发现elasticsearch和mysql有很多地方类似，也有很多地方不同。这里做一个对比，帮助大家加深对elasticsearch的理解。

routing_factor = num_routing_shards / num_primary_shards
shard_num = (hash(_routing) % num_routing_shards) / routing_factor

my-index-000001/_doc/1?routing=user1&refresh=true

{
  "profile": true,
  "query" : {
    "match" : { "message" : "GET /search" }
  }
}

eval，一个我曾经避之不及的函数，最近我对它产生了一点新的感触：eval有时候也可以用，有奇效。

一般在使用js进行开发时，是不建议使用eval这类函数的。在JavaScript中，eval可以计算传入的字符串，将其当作js代码来执行。因为它可执行js代码的特性，有可能被第三方利用，传入恶意js代码执行，因此这个函数存在安全风险。再加上eval执行的速度低于普通的js程序，因此在日常开发中，它的使用准则是“能不用就不用”、“代码中使用eval是很丑陋的一件事”。

但是这次在做拉线功能时，我“不得不”使用了它。

拉线由于数据量小，可以通过矢量渲染的方式渲染到地图上，但是通过geoserver获取的坐标数据和样式数据是分离的，且没有样式名能将二者关联起来。
样式数据里面规定每组筛选条件对应一组样式值（线段的颜色、宽度，面的颜色、透明度），以以下这段样式数据为例：

{
  "Description": {
      "Title": "hidetitle"
  },
  "Filter": {
      "And": {
          "PropertyIsGreaterThanOrEqualTo": {
              "PropertyName": "rsrp_rate",
              "Literal": "0"
          },
          "Not": {
              "PropertyIsNull": {
                  "PropertyName": "eci"
              }
          },
          "PropertyIsEqualTo": {
              "PropertyName": "geo_type",
              "Literal": "cell"
          },
          "PropertyIsLessThanOrEqualTo": {
              "PropertyName": "rk",
              "Literal": "3"
          },
          "PropertyIsLessThan": {
              "PropertyName": "rsrp_rate",
              "Literal": "0"
          }
      }
  },
  "PolygonSymbolizer": {
      "Fill": {
          "SvgParameter": [
              "#f56e3f",
              "0.15"
          ]
      },
      "Stroke": {
          "SvgParameter": [
              "#f56e3f",
              "4"
          ]
      }
  },
  "Name": "cell1-3 and rate 0-20"
},

它的涵义是：
当满足
(rsrp_rate >= 0 && ect !== null && geo_type === 'cell' && rk <= 3 && rsrp_rate < 0)
的条件时，面填充颜色使用#f56e3f、透明度为0.15，线段颜色使用#f56e3f、宽度为4。

如果使用常规方式去进行拉线数据值和样式数据的计算匹配，无疑会很繁琐，执行筛选所需要的时间也会很长，这种结果无疑是“丑陋”的。但是如果使用eval，就会有奇效。

我可以先将样式数据进行处理成类似

{ operator: '>=', name: 'rsrp_rate', value: 0 }

这样的结构，并存入数组，这个数组里存放的都是and关系的筛选条件。

然后从拉线数据里获取每个指标的值indexValue，进行如下拼装：

let dataItem = { operator: '>=', name: 'rsrp_rate', value: 0 };
let filterValue = dataItem.value;
let indexValue = lineData[dataItem.name]; // 此处lineData中存储着单个拉线的指标值
eval('filterValue' + dataItem.operator + 'indexValue') ;
// 上方这行代码在编译后执行的是: filterValue >= indexValue

利用eval可以将传入的字符串当作js语句执行的特性，我就可以得到一个条件判断结果，代码相对而言也简洁很多，使用eval，反尔让代码变得优雅，大大提高了数据匹配的效率和代码的可维护性。

总之，这段开发经历，让我对eval有了新的认识。

golang pprof 监控系列(1) —— go trace 统计原理与使用

服务监控系列文章

服务监控系列视频

关于go tool trace的使用，网上有相当多的资料，但拿我之前初学golang的经验来讲，很多资料都没有把go tool trace中的相关指标究竟是统计的哪些方法，统计了哪段区间讲解清楚。所以这篇文章不仅仅会介绍go tool trace的使用，也会对其统计的原理进行剖析。

golang版本 go1.17.12

先简单说下go tool trace 的使用场景，在分析延迟性问题的时候，go tool trace能起到很重要的作用，因为它会记录各种延迟事件并且对其进行时长分析，连关键代码位置也能找出来。

关于trace的实战案例，之前有出过一个视频(
一次系统延迟分析案例
)，欢迎浏览

接着我们简单看下golang 里如何使用trace 功能。

go trace 使用

package main

import (
	_ "net/http/pprof"
	"os"
	"runtime/trace"
)

func main() {
	f, _ := os.Create("trace.out")
	defer f.Close()
	trace.Start(f)
	defer trace.Stop()
  ......
}

使用trace的功能其实比较容易，用trace.Start 便可以开启trace的事件采样功能，trace.Stop 则停止采用，采样的数据会记录到trace.Start 传来的输出流参数里，这里我是将一个名为trace.out 的文件作为输出流参数传入。

采样结束后便可以通过 go tool trace trace.out命令对采样文件进行分析了。

go tool trace 命令默认会使用本地随机一个端口来启动一个http服务，页面显示如下:

接着我会分析下各个链接对应的统计信息以及背后进行统计的原理，好的，接下来，正戏开始。

统计原理介绍

平时在使用prometheus对应用服务进行监控时，我们主要还是采用埋点的方式，同样，go runtime内部也是采用这样的方式对代码运行过程中的各种事件进行埋点，最后读取 整理后的埋点数据，形成我们在网页上看的trace监控图。

// src/runtime/trace.go:517
func traceEvent(ev byte, skip int, args ...uint64) {
	mp, pid, bufp := traceAcquireBuffer()
    .....
}

每次要记录相应的事件时，都会调用traceEvent方法，ev代表的是事件枚举，skip 是看栈帧需要跳跃的层数，args 在某些事件需要传入特定参数时传入。

在traceEvent 内部同时也会获取到当前事件发生时的线程信息，协程信息，p运行队列信息，并把这些信息同事件一起记录到一个缓冲区里。

// src/runtime/trace/trace.go:120 
func Start(w io.Writer) error {
	tracing.Lock()
	defer tracing.Unlock()
	if err := runtime.StartTrace(); err != nil {
		return err
	}
	go func() {
		for {
			data := runtime.ReadTrace()
			if data == nil {
				break
			}
			w.Write(data)
		}
	}()
	atomic.StoreInt32(&tracing.enabled, 1)
	return nil
}

在我们启动trace.Start方法的时候，同时会启动一个协程不断读取缓冲区中的内容到strace.Start 的参数中。

在示例代码里，trace.Start 方法传入名为trace.out文件的输出流参数,所以在采样过程中，runtime会将采集到的事件字节流输出到trace.out文件，trace.out文件在被读取出的时候 是用了一个叫做Event的结构体来表示这些监控事件。

// Event describes one event in the trace.
type Event struct {
	Off   int       // offset in input file (for debugging and error reporting)
	Type  byte      // one of Ev*
	seq   int64     // sequence number
	Ts    int64     // timestamp in nanoseconds
	P     int       // P on which the event happened (can be one of TimerP, NetpollP, SyscallP)
	G     uint64    // G on which the event happened
	StkID uint64    // unique stack ID
	Stk   []*Frame  // stack trace (can be empty)
	Args  [3]uint64 // event-type-specific arguments
	SArgs []string  // event-type-specific string args
	// linked event (can be nil), depends on event type:
	// for GCStart: the GCStop
	// for GCSTWStart: the GCSTWDone
	// for GCSweepStart: the GCSweepDone
	// for GoCreate: first GoStart of the created goroutine
	// for GoStart/GoStartLabel: the associated GoEnd, GoBlock or other blocking event
	// for GoSched/GoPreempt: the next GoStart
	// for GoBlock and other blocking events: the unblock event
	// for GoUnblock: the associated GoStart
	// for blocking GoSysCall: the associated GoSysExit
	// for GoSysExit: the next GoStart
	// for GCMarkAssistStart: the associated GCMarkAssistDone
	// for UserTaskCreate: the UserTaskEnd
	// for UserRegion: if the start region, the corresponding UserRegion end event
	Link *Event
}

来看下Event事件里包含哪些信息：
P 是运行队列，go在运行协程时，是将协程调度到P上运行的，G 是协程id，还有栈id StkID ，栈帧 Stk，以及事件发生时可以携带的一些参数Args，SArgs。
Type 是事件的枚举字段，Ts是事件发生的时间戳信息，Link 是与事件关联的其他事件，用于计算关联事件的耗时。

拿计算系统调用耗时来说，系统调用相关的事件有GoSysExit,GoSysCall 分别是系统调用退出事件和系统调用开始事件，所以GoSysExit.Ts - GoSysCall.Ts 就是系统调用的耗时。

特别提示: runtime 内部用到的监控事件枚举在src/runtime/trace.go:39 位置 ，而 在读取文件中的监控事件用到的枚举是 在src/internal/trace/parser.go:1028 ，虽然是两套，但是值是一样的。

很明显Link 字段不是在runtime 记录监控事件时设置的，而是在读取trace.out里的监控事件时，将事件信息按照协程id分组后 进行设置的。同一个协程的 GoSysExit.Ts - GoSysCall.Ts 就是该协程的系统调用耗时。

接下来我们来挨个分析下trace页面的统计信息以及背后的统计原理。

View trace是每个事件的时间线构成的监控图
，在生产环境下1s都会产生大量的事件，我认为直接看这张图还是会让人眼花缭乱。 所以还是跳过它吧，从Goroutine analysis开始分析。

Goroutine analysis

go tool trace最终引用的代码位置是在go/src/cmd/trace 包下，main函数会启动一个http服务，并且注册一些处理函数，我们点击Goroutine analysis 其实就是请求到了其中一个处理函数上。
下面这段代码是注册的goroutine的处理函数点击Goroutine analysis 就会映射到 /goroutines 路由上。

// src/cmd/trace/goroutines.go:22
func init() {
	http.HandleFunc("/goroutines", httpGoroutines)
	http.HandleFunc("/goroutine", httpGoroutine)
}

让我们点击下 Goroutine analysis

进入到了一个显示代码调用位置的列表，列表中的每个代码位置都是事件EvGoStart 协程开始运行时的位置，其中N代表 在采用期间 在这个位置上有N个协程开始过运行。

你可能会好奇，是怎样确定这10个协程是由同一段代码执行的？runtime在记录协程开始执行的事件EvGoStart 时，是会把栈帧也记录下来的，而栈帧中包含函数名和程序计数器(PC)的值，在Goroutine analysis 页面 中就是协程就是按PC的值进行分组的。 以下是PC赋值的代码片段。

// src/internal/trace/goroutines.go:176
case EvGoStart, EvGoStartLabel:
			g := gs[ev.G]
			if g.PC == 0 {
				g.PC = ev.Stk[0].PC
				g.Name = ev.Stk[0].Fn
			}

我们再点击第一行链接 nfw/nfw_base/fw/routine.(*Worker).TryRun.func1 N=10 ,这里点击第一行的链接将会映射到 /goroutine 的路由上(注意路由已经不是s结尾了)，由它的处理函数进行处理。点击后如图所示:

现在看到的就是针对这10个协程分别的系统调用，阻塞，调度延迟，gc这些统计信息。

接着我们从上到下挨个分析:
Execution Time 是指着10个协程的执行时间占所有协程执行的比例
。
接着是用于分析网络等待时间，锁block时间，系统调用阻塞时间 ，调度等待时间的图片，这些都是分析系统延迟，阻塞问题的利器。 这里就不再分析图了，相信网上会有很多这种资料。

然后来看下 表格里的各项指标:

Execution

是协程在采样这段时间内的执行时间。

记录的方式也很简单，在读取event事件时，是按时间线从前往后读取，每次读取到协程开始执行的时间时，会记录下协程的开始执行的时间戳(时间戳是包含在Event结构里的)，读取到协程停顿事件时，则会把停顿时刻的时间戳减去开始执行的时间戳 得到 一小段的执行时间，将这小段的时间 累加到该协程的总执行时间上。

停顿则是由锁block，系统调用阻塞，网络等待，抢占调度造成的。

Network wait

顾名思义，网络等待时长， 其实也是和Execution类似的记录方式，首先记录下协程在网络等待时刻的时间戳，由于event是按时间线读取的，当读取到unblock事件时，再去看协程上一次是不是网络等待事件，如果是的话，则将当前时刻时间戳减去 网络等待时刻的时间戳，得到的这一小段时间，累加到该协程的总网络等待时长上。

Sync block，Blocking syscall,Scheduler wait

这三个时长 计算方式和前面两张也是类似的，不过注意下与之相关联的事件的触发条件是不同的。

Sync block 时长是由于 锁 sync.mutex ，通道channel，wait group，select case语句产生的阻塞都会记录到这里。 下面是相关代码片段。

// src/internal/trace/goroutines.go:192
case EvGoBlockSend, EvGoBlockRecv, EvGoBlockSelect,
			EvGoBlockSync, EvGoBlockCond:
			g := gs[ev.G]
			g.ExecTime += ev.Ts - g.lastStartTime
			g.lastStartTime = 0
			g.blockSyncTime = ev.Ts

Blocking syscall 就是系统调用造成的阻塞了。

Scheduler wait 是协程从可执行状态到执行状态的时间段，注意协程是可执行状态时 是会放到p 运行队列等待被调度的，只有被调度后，才会真正开始执行代码。 这里涉及到golang gpm模型的理解，这里就不再展开了。

后面两栏就是GC 占用total时间的一个百分比了，golang 的gc相关的知识也不继续展开了。

各种profile 图

还记得最开始分析trace.out生成的网页时，Goroutine analysis 下面是什么吗？是各种分析延迟相关的profile 图，数据的来源和我们讲Goroutine analysis 时分析单个Goroutine 的等待时间的指标是一样的，不过这里是针对所有goroutine而言。

Network blocking profile (⬇)
Synchronization blocking profile (⬇)
Syscall blocking profile (⬇)
Scheduler latency profile (⬇)

关于golang 的这个trace工具，还允许用户可以自定义监控事件 ，生成的trace网页里，User-defined tasks，User-defined regions 就是记录用户自定义的一些监控事件，这部分的应用等到以后再讲了。

Minimum mutator utilization 是一个看gc 对程序影响情况的曲线图，这个等以后有机会讲gc时再详细谈谈了。

关于trace的实战案例，之前有出过一个视频(
一次系统延迟分析案例
)，欢迎浏览。