在之前的一篇文章《云原生NPM与传统NPM的差异》中，我们了解到，传统NPM通过对物理设备的网络流量进行镜像，可以统计出网络层面的各种指标，也可以分析出网络延迟、带宽、重传等性能相关的指标。但是在实际工作中发现，网络层面的异常信息只是第一步，定位到产生异常的服务和原因，才能真正解决问题。本篇我们将讲述如何在云原生NPM中获取网络数据及相关网络指标的计算方法，以及如何将网络与具体应用进程进行关联，从而有助于快速地定位到可疑点。
1、设计数据结构
该结构描述了一条TCP网络连接（本篇只关注TCP连接的应用）的主要信息，以该数据结构为基础，可以得到以应用/进程为视角的网络状态。除此之外，还可以增加其它字段，如错误报文数、重传报文数、乱序报文数，等等。
2、获取字段值
- ClientIP, ServerIP, ClientPort, ServerPort
网络连接的四元组。从捕获的网络报文中可以解析出IP和Port信息。TCP连接有三次握手的过程，第一次握手的时候由客户端发起syn请求，根据这个信息可以确定Client。
- BytesReceived, BytesSent, PacketsReceived, PacketsSent
对服务端接收和发送的报文数、字节数进行统计。因为服务端接收就等于客户端发送，所以只需要统计一个方向的数据即可。
Rtt, Crt, Art, Ptt这几个与时间相关的性能指标无法直接从网络报文中获取，需要通过一些算法计算，计算方法如下图所示：
对于旁路抓包，该图中隐含了一个重要信息：传统的NPM抓包位置要么靠近client, 要么靠近server。而云原生中的NPM要么位于client，要么位于server。这个抓包位置的变化，导致性能指标的计算方法略有区别。
- Rtt (round trip time)
计算时要区分该连接的目标地址是否为本机地址，如果是，意味着该连接是远端访问本地的一个服务，按照上图中server角色来计算：T(ack) – T(synack)；否则，按client角色来计算：T(synack) – T(syn) - Crt (client response time)
按client角色来计算：T(http-get) – T(ack) Art (application response time)
按 server 角色来计算: T(http-response) – T(http-get)Ptt (payload transaction time)
按client 或 server角色都可以，数据传输的总时间。
剩下的两个字段，PID和UID，分别表示进程ID和用户ID，这两个字段的值无法在网络包中获取，需要从操作系统中获取。下图是linux系统下运行 netstat -nopt 的输出。
从中可以看到一条连接的四元组信息，还有PID和进程名。
到此，我们已经获取了本文开头结构中的所有字段的值。很多的应用日志框架都会默认输出PID信息，因此，通过PID还可以将网络指标与应用的日志进行关联，为相关的故障诊断提供更丰富的上下文信息。
3、结尾
通过对网络数据的分析，可以计算出一些与网络质量相关的关键指标，用于定位与网络相关的故障根因。TCP协议栈本身是一个比较复杂的系统，内部11种状态之间的转换与开销对于外部来说是一个完全的黑盒，但是对于定位问题有时却很关键。那如何观测这些关键信息呢？后续文章将介绍如何使用eBPF来采集内核中的网络指标，敬请期待。
