理解fq_codel之概述

fq_codel这个新的机制进入内核已经有一段时间了，主要是在Linux的Wi-Fi子系统中使用。但是目前好像并没有像样的中文的介绍。正好之前参与开源组织合作开发Airtime fairness(ATF)的时候，有比较深入的去了解它的大致原理，这里试着缕一缕它的大致逻辑。

目录

I. fq-codel 的由来

II. fq-codel的基本原理

---

I. fq-codel 的由来

如果不做些search，可能很多人根本不知道fq-codel代表的是什么意思。fq-codel代表的就是the flow queue control delay，中文翻译出来味道就变了，所以不做翻译。

为什么我们需要fq_codel,它要解决什么问题？

想象一下，你现在在你的手机上干三件事，第一个通过百度云App下载不可描述的岛国小片片，第二个你在和好基友微信语音聊天，第三个，聊天的同时还会开个浏览器查询下和好基友聊到的岛国明星。这时候对于你家里的路由器AP来说，就有三个数据流要发往你的手机，一个是百度云上下载的片的数据，一个是好基友回复的一段语音，还有就是你百度一下的岛国明星，百度返回给你的一系列不可描述的网站地址，然而遵循一般的先到先发的原则(FIFO)，很有可能你下载的小片片下载速率很高，每时每刻都有数据到达AP, 于是堵在发送队列前头，占据了很多的发送带宽。如果这个等待发送的数据队列足够长（对应的buffer足够大），对于微信语音和网站的返回数据这些对时间敏感，数据量其实不大，但是非常影响用户体验的数据流，就会被卡住发不出去，除非排队排到自己。这样对你来说就是感觉延迟很大，半天等不到基友的回复和网站的返回。更糟的情况可能是，如果运气不好，后两种数据流来的时候队列满了，那么很有可能基友的回复和网站的返回的数据都会被丢掉，这样微信还需要替你的基友重发一下，百度也会重新发送搜索的结果，又是一坨从远端过来的等待时间，运气再差点的话，又会遇到同样的问题，周而复始。

这种问题叫bufferbloat，fq_codel就是要致力于解决bufferbloat的问题，改善round-time times(RTT)，甚至提高整体吞吐率. fq_codel对于实时性要求高的，数据包不大的应用特别nice，比如VOIP，在线游戏。

更多的详情参考wiki：

https://en.wikipedia.org/wiki/Bufferbloat

---

# fq-codel的基本原理

思考一下上面的那个简单例子，倘若能有什么方法能够适当调整发包的顺序，将基友的语音数据和百度返回的数据提前，那么是不是整个体验就会好得多。基本思路就是这样，but How？

在讲原理之前，首先要明白fq-codel中flow的概念，一个flow是于tuple5和随机数关联的概念。tuple5代表了源/目的 地址，源/目的 端口，以及协议类型五个元素。这样子每一个从远端发往你手机上的应用的数据都可以按tuple5划分成唯一的flow。

先前说了fq-codel其实是the flow queue control delay，进一步说就是flow queue + codel算法的结合。

简单来说就是将数据按照flow区分开来，把数据缓存在该flow的queue之中，同时引入DRR(Deficit Round Robin) 调度机制。Deficit以字节数为单位，可以理解为是一个关于该flow是否可以发送的阈值判断，除非有大于0的deficit，否则这个flow缓存的数据不能够发送。

发往同一设备的flow组成一个队列，每次调度的时候，如果队列头的flow的deficit小于0，会放到队列尾部并回补固定的Deficit，然后继续iterate该队列直到找到deficit大于0的flow进行发送，并更新deficit(减掉发送字节数)，flow也会被从队列头调度走。(为了方便描述，具体的调度算法会有些出入，等待被调度flow的队列由new，old两个flow队列)

如果某个flow缓存的数据时间过长，就要依照codel的算法drop；如果缓存需要的总的buffer用完或者缓存的总的packets大于一定阈值，缓存最多数据的flow里面的skb也会被drop, 直到有可用buffer或者缓存总packets小于阈值为止。更多的内容会在后续文章详述，如果有的话 :) 。

具体来讲，按照上面的例子就是，当数据到达AP，被分成三条flow，由于deficit的原因，比如初始值300，每次回补300。开始的时候下载小片片的flow在队头，如果它发送一次就消耗了400字节，deficit变成-100，在接下来的调度中，其他两个flow由于包比较小，消耗不到300，只有200，deficit变成100；当小片片的flow的再次到达时，由于deficit为-100，它不会被调度，只能重新排队到队尾，回补300，deficit变成200，而接下来的两次调度中其他两个flow会被发送，deficit会变成-100。这就意味着实时性小包被发送的次数是大包的两倍。但是即使这样，也不代表大包没有机会被发送，在后续的调度中它也会被调度到。

这样子每个flow都不可能一直发送数据，让其他flow干等，按照发送字节数去调度，最大限度保证了，实时性的小包能更早被发送出去。所以这个deficit也不能设置很大。

这种基于发送字节数的DRR是不是蛮巧妙？

欢迎指正。