Recent Posts

• 2020-01-13

  TCP拥塞控制之ABC(Appropriate Byte Counting)

  ABC 的来源我们知道，TCP 发送端的数据发送速度受到本端拥塞窗口(cwnd)和对端通告的接收窗口(rwnd)的限制，只有同时在这两个窗口内的待发送数据才允许被发送到网络中。其中对端接收窗口是由对端接收缓冲区确定的，由于本文主要关注拥塞窗口，因此不考虑接收窗口的影响(视为接收窗口很大很大)。而拥塞窗口的大小则是由不停的拥塞控制算法计算而来。经典的拥塞控制算法都至少包含慢启动(Slow Start)和拥塞避免(Congestion Avoid)两个阶段。通常我们这样描述这两个阶段的窗口增加...

• 2020-01-01

  一个 TCP 接收缓冲区问题的解析

  本文是作为一个 TCP 发送缓冲区问题的解析的姊妹篇存在的，在 TCP 中，接收缓冲区比发送缓冲区更为重要和复杂，原因就是，接收缓冲区和 TCP 通告的窗口也息息相关。问题模型Clinet 与 Server 之间建立一条 TCP 连接，Server 通过 SO_RCVBUF 选项设置连接的接收缓冲区为 2048 字节。Clinet 每隔 100 ms 通过 send() 一个载荷长度很小(2 字节)的 TCP 报文，但 Server 端不调用 recv()，这意味着 Server 收到的 ...

• 2019-12-20

  一个 TCP 发送缓冲区问题的解析

  最近遇到一个问题，简化模型如下：Client 创建一个 TCP 的 socket，并通过 SO_SNDBUF 选项设置它的发送缓冲区大小为 4096 字节，连接到 Server 后，每 1 秒发送一个 TCP 数据段长度为 1024 的报文。Server 端不调用 recv()。预期的结果分为以下几个阶段：Phase 1. Server 端的 socket 接收缓冲区未满，所以尽管 Server 不会 recv()，但依然能对 Client 发出的报文回复 ACK;Phase 2. Ser...

• 2019-12-07

  Dive into eBPF (4): map-用户空间与内核空间沟通的桥梁

  本文是来回答 Dive into eBPF(2)中提到的第3个问题，即： Q3:用户空间和内核空间的程序是如何通过 map 进行通信的 ?为什么用户空间要和内核空间程序通信呢？答案是：我们将内核程序灌入内核并运行，很多时候还需要从内核提取信息出来，而 map 则是 eBPF 提供的一套通信机制。如下图所示，map 是一个驻留在内核空间的K-V数据库，内核程序将运行的结果存入数据库，而用户程序则通过系统调用将结果读回。接下来依然通过 sockex1 这个例程来看看 map 是如何工作的？m...

• 2019-12-02

  Dive into eBPF (3): 虚拟机程序执行的时机

  在 Dive into eBPF(2)中，我们通过例子了解了 eBPF 程序是如何被 load 到内核的，而本文将回答上一篇文章中的第 2 个问题，即： Q2: 内核指令何时执行，执行的上下文是什么?先给出答案：eBPF 程序指令都是在内核的特定 Hook 点执行，不同类型的程序有不同的钩子，有不同的上下文将指令 load 到内核时，内核会创建 bpf_prog 存储指令，但只是第一步，成功运行这些指令还需要完成以下两个步骤： 将 bpf_prog 与内核中的特定 Hook 点关联起来...