#tcp

最近做了一些 TCP 连接观测相关的项目，又到了一个节奏点上了。这里趁着这个机会，做一些总结，同时描述一下 tcp close 过程中的一些疑惑。

在一些场景下，对服务的调用观测是很有价值的。笔者最近实践了使用tcp_close对服务主被调信息的观测，在这里作一下记录。

搞项目。

观测服务的请求调用需求是客观存在的。一般是需要观测服务的主动发起的调用信息，但是偶尔也会遇到需要观测服务被调用信息的需求。但是一般待采集的服务都是挂载在LVS下面的。这就势必涉及到LVS预设的工作模式下，一般都是FULLNET，需要的real client ip的信息获取方式。
笔者通过调研，实现了一种通过BPF来观测挂载在LVS下的RS被调用TCP连接信息的方式。本文中关于toa的操作及代码定义均引用自Huawei/TCP_option_address。

在这里对文章题目作一些说明。笔者想了很长时间也无法给这篇文章想个恰当的表意题目。实际上使用ebpf来进行服务观测是有在进行的，比如获取目前l1s上的常见的四元组。但是本文不是介绍这部分可观测实践的。文章希望阐述的场景是：采集请求触发里的一些信息（诸如trace及其他header等）并和服务请求下游的传输层五元组(protocol, src-ip, src-port, dst-ip, dst-port)进行关联。这也是最近工作中实际遇到的问题。

基于ebpf的丰富的特性能够获取服务很多的信息，不同特性的组合更是可以达到极强的数据整合能力。比如通过uprobe便捷的获取业务信息后，结合kprobe来获取系统调用里的内容，可以获取一般侵入式可观测代码无法获取的内容。笔者最近遇到的一个实际问题是：获取服务A的接口/a响应后，向下游B发起的请求时，所使用的传输层五元组，同时带上结合一些/a触发时的一些内容，比如caller_fun或者traceId。
这里值得说明的是，用户态请求的是一个域名。域名的解析是在golang的http里完成的。但是请注意，golang发起tcp请求时，local port设置的是0，然后由内核态的tpc处理来选择一个空闲的port作为socket里的lport。这部分的信息通过代码的埋点显然是无法获取的（详情可参考TCP连接中客户端的端口号是如何确定的？）。
下面介绍下实现效果及思路。

关于bpftrace使用的介绍，可以参见：bpftrace 无侵入遍历golang链表，关于ebpf来进行数据采集的实践，可以参见ebpf采集mysql请求信息及ebpf对应用安全的思考。