头图

应用响应时延背后 深藏的网络时延

应用异常时,基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手,很多无头案。应用团队有日志和追踪,对于自认为的不可能不合理的事情都会甩给基础设施团队,又由于基础设施团队现有的监控数据缺乏应用的观测视角,通常成为一切「不是我的问题」超自然现象的终极背锅侠,其中以网络团队尤为严重。

01|响应时延

服务为什么响应慢???首先,我们需要一种方式来度量何为响应慢,参考 Google 在 SRE Handbook 中提到过4 个黄金信号及 Weave Cloud 提出来的 RED 方法,都存在度量的指标(Latency/Duration),后文统称为响应时延。

Latency 表达的是服务处理某个请求所需要的时间,站在的是服务端视角Duration 表达的是每个请求所花费的时间,站在的是客户端视角
总结下来,不论站在什么视角,响应时延表达的都是处理一个请求所花费的时间,可以用来表征服务响应慢的度量指标,但若要定位为什么响应慢还需要进一步剖解响应时延:

系统时延:系统转发请求/响应的时延消耗
网络时延:包含查询 DNS 时延及网络处理的时延
应用时延:从不同视角来看,包含客户端应用处理时延 + 服务端应用处理时延

图片
响应时延拆解

确定度量指标后,接下就可以分析服务响应慢的原因,此时可以利用分布式链路追踪能力来快速来定界瓶颈点,例如可利用 DeepFlow 的分布式追踪能力来快速定界瓶颈点在应用、系统还是网络。

图片
分布式链路追踪-火焰图

完成瓶颈点定界后,则需要去查找根因。对于应用或者系统的问题,可以利用性能剖析(profile)继续追查根因,而对应网络时延的分析,其中 DNS 时延分析是相对简单的,只需要关注请求的响应时延即可,但网络处理时延瓶颈的定位却缺少了分析的工具,接下来将主要聚焦讨论网络传输时延如何分析。

图片
性能剖析-火焰图

02|网络时延

参考 AWS 中的定义网络时延是指网络通信中的延时,网络时延显示了数据通过网络传输所需的时间。讨论网络时延如何,也是需要可度量的指标,AWS 也指定了使用“首字节时间”和“往返时间”等指标来衡量网络时延,这两个指标是可以适用于所有网络协议的传输时延的度量,但实际应用 80% 都使用的 TCP 协议,对于 TCP 协议是需要更细粒度的度量指标,下文通过图文的形式,详细的介绍目前可用的度量指标及用法。

TCP 协议是面向连接的传输层通信协议,对其详细的通信过程分析,时延可分为三大类:

1) 建连时产生的时延

  1. 完整的建连时延包含客户端发出 SYN 包到收到服务端回复的 SYN+ACK 包,并再次回复 ACK 包的整个时间。建连时延拆解开又可分为客户端建连时延与服务端建连时延
  2. 客户端建连时延为客户端收到 SYN+ACK 包后,回复 ACK 包的时间
  3. 服务端建连时延为服务端收到 SYN 包后,回复 SYN+ACK 包的时间

2) 数据通信时产生的时延,可拆解为客户端等待时延+数据传输时延

  1. 客户端等待时延为建连成功后,客户端首次发送请求的时间;为收到服务端的数据包后,客户端再发起数据包的时间
  2. 数据传输时延为客户端发送数据包到收到服务端回复数据包的时间
  3. 在数据传输时延中还会产生系统协议栈的处理时延,称为系统时延

3) 断连时产生的时延:因为断连的时延并不影响到应用的响应时延,因此并不会单独统计此部分使用

图片
TCP 网络时延解剖

度量的网络时延的指标已经拆解好了,接下来讨论在哪里采集指标,网络的报文将在客户端,各种虚拟和物理网络与服务端之间穿梭,因此可报文穿梭的位置点来采集,后续统称为统计位置。当然统计位置越多,定位网络的瓶颈路径越快,但是统计位置多则随之带来的计算量也是成倍增加,企业在有成本压力时,建议在重要节点进行采集即可,比如 K8s Pod 虚拟网卡、K8s Node 网卡、云服务器网卡、网关(如 LVS/Nginx 等)网卡、硬件防火墙/负载均衡器前后......

图片
统计位置

分析到这,基本已经清晰网络时延的详细的度量指标了,回过头结合响应时延再讨论下如何查看网络时延对其的影响,基本可以分两种情况讨论:

a) 应用发起请求为短连接:此时分析网络时延需要查看 DNS 时延 + 建连时延 + 客户端等待时延 + 数据传输时延 + 系统时延,则可快速定位时延发生的具体原因了。

  • DNS 时延高,结合统计位置,则可回答是网络传输时延高还是DNS服务响应慢
  • 建连时延高,结合客户端建连时延 + 服务端建连时延 + 统计位置,则可回答是网络传输时延高还是客户端系统回复慢还是服务端处理建连响应慢
  • 客户端等待时延高,结合统计位置,则可回答是网络传输时延高还是客户端请求发送延迟
  • 数据传输时延高,结合统计位置,则可回答是网络传输时延高还是服务端响应慢
  • 系统时延高,结合统计位置,则可回答网络传输时延高还是服务端协议栈处理慢

b) 应用发起请求为长连接:因为长连接是保持长期活动的 HTTP 连接,不需要考虑 DNS 查询与建连的时延消耗,只需要关注客户端等待时延 + 数据传输时延 + 系统时延即可

03|案例分析

限于笔者时间限制又想早点将应用响应时延背后深藏的网络时延剖解分享给大家,本文不继续补充实际案例,将在一周后分享在某xx智能终端公司的如何结合 DeepFlow 在服务响应慢时,网络团队在存在可观测性的时延数据时,如何硬气回怼。

04|什么是 DeepFlow

DeepFlow[1] 是一款开源的高度自动化的可观测性平台,是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术,创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制,帮助开发者提升埋点插码的自动化水平,降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口,开发者可以快速将其融入到自己的可观测性技术栈中。
GitHub 地址:https://github.com/deepflowys/deepflow
访问 DeepFlow Demo[2],体验高度自动化的可观测性新时代。

05|参考文档

[1] DeepFlow: https://github.com/deepflowys/deepflow

[2] DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/

云杉网络(北京云杉世纪网络科技有限公司)是中国领先的软件定义网络(SDN)实践创新企业,从2011年12月...

25 声望
707 粉丝
0 条评论
推荐阅读
落地 eBPF 可观测性之 DeepFlow Agent 性能揭秘
DeepFlow 基于 eBPF 实现了零插桩(Zero Code)的云原生应用可观测性,能够在不改代码、不改启动参数、不重启进程的前提下实现分布式追踪。这是一种全新的技术手段,因此不少用户在选型和落地 DeepFlow 的过程中...

云杉网络

封面图
突破难关:Docker镜像和容器的区别以及构建的最佳实践
Docker 可谓是开启了容器化技术的新时代,现在无论大中小公司基本上都对容器化技术有不同程度的尝试,或是已经进行了大量容器化的改造。伴随着 Kubernetes 和 Cloud Native 等技术和理念的普及,也大大增加了业务...

张晋涛4阅读 1.1k

封面图
TCP 三次握手,给我长脸了噢
之前有个小伙伴在技术交流群里咨询过一个问题,我当时还给提供了点排查思路,是个典型的八股文转实战分析的案例,我觉得挺有意思,趁着中午休息简单整理出来和大家分享下,有不严谨的地方欢迎大家指出。

程序员小富4阅读 575

封面图
蚂蚁安全科技 Nydus 镜像加速实践
蚂蚁安全科技 Nydus 镜像加速实践原创 曦栖 金融级分布式架构文|蚂蚁集团 ZOLOZ 团队使用全球领先安全科技,为用户和机构提供安全、便捷的安全风控解决方案。本文 6386 字 阅读 12 分钟背景简介ZOLOZ[1]是蚂蚁集...

SOFAStack1阅读 3.8k

封面图
“当高启强遇到陈书婷”与TCP协议
大家是否经常听别人提起TCP协议的三次握手和四次挥手呢?🤔是否看过很多相关的文章都没看懂或是没记住呢🤷‍?看过我上篇的小伙伴都应该知道TCP协议是属于传输层中的协议,没有看过的请移步这里👉“老默我想吃鱼了”与...

法医4阅读 636

封面图
Github-访问受限解决办法
前言最近发现自己的macbook 使用chrome连接github一直连接不上,于是网上找解决办法,记录下来分享给大家。操作1、获取github.com的IP打开网站websites.ipaddress.com/github.com`复制里面的ip2、打开iTerm2命令...

Awbeci阅读 6.6k

LeanCloud 云引擎支持预览环境
云引擎最近支持了 预览环境,可以自动将 Pull request 部署到一个新的环境,每个预览环境有单独的域名,让开发者在线上测试过后再合并 PR。

LeanCloud1阅读 1.4k

封面图

云杉网络(北京云杉世纪网络科技有限公司)是中国领先的软件定义网络(SDN)实践创新企业,从2011年12月...

25 声望
707 粉丝
宣传栏