Recent Posts

• 2023-09-08

  tcp-brutal: 似控非控的拥塞控制算法

  TCP 拥塞控制算法的本质是限制自身的发送速率，以缓解整个网络的拥堵. 如果参与网络的终端都践行这套规则. 那么谁也不会吃亏.但问题是，一个参与者或许可以通过破坏规则而获利(抢占其他参与者的带宽), 而如果每个参与者都不遵守规则，后果就是所有人都占不到便宜.目前还可以庆幸的是，尽管互联网上已经有形形色色的规则破坏者, 但它们的流量很小, 尚且动摇不了整个公平的根基…本文的主题是 tcp-brutal 拥塞控制算法, 项目地址在这里 本质上来说, 它也是规则破坏者的一员一句话描述 tcp-b...

• 2023-06-30

  ONOS 事件子系统

  本文先介绍ONOS事件子系统的实现原理, 再介绍如何在自己的服务中利用它实现业务的解耦。为什么需要它ONOS的事件子系统可以理解为消息总线，各个服务都可以利用它提供的订阅-发布特性与其他服务进行消息通信。假如没有这套机制，比如服务A想通知服务B一个消息。A就需要显式地调用B暴露的接口, 并且这个过程还只能在A的上下文执行，且它还是同步而不是异步的。这还只是两个服务的情况，这时再加入一个服务C也想收到这个消息，就需要修改服务A的实现，这实在不优雅。实现原理Event 与 Event Sink...

• 2023-04-16

  理解 RACK 的原理和实现

  在 RACK 之前, TCP 的快速恢复采用对 DupACK 进行计数作为进入条件, 当计数超过 DupThresh 时, 触发快速恢复流程.但这种方法对 application-limited 的应用来说并不可靠, 因为这类应用不会持续发送数据, 而 DupACK 需要报文触发才能生成,这就导致一旦报文丢失, DupACK 不会增加, 最终发送方触发 RTO 超时重传流程, 而非快速恢复.可以把 RTO 超时重传理解为是”急刹车”, 快速恢复则是”点踩刹车”，前者代价高，后者代价低RAC...

• 2023-04-02

  理解 sack reordering distance

  在不使能 SACK 时, 发送端在收到默认 3 个 DupAcks , 就会立即触发快速重传和快速恢复.这一点使用下面的 packetdrill 很轻松验证:// author. @switch-router.gitee.io+0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0+0 bind(3, ..., ...) = 0+0 listen(3...

• 2023-03-15

  TCP 窗口最大值为什么是1GiB

  这个看上去理所当然的问题可能并没有那么简单… 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...