因为工作单位对软件正版化的要求很高。虽然我喜欢用 smartgit，也只能舍弃了。

目前只装了 git bash，卸载掉 smartgit，免去这方面的烦恼。这篇文章记录在 windows 下的命令行操作的一些备忘。

在没有配置 .bashrc 里的快捷命令的时候，我使用下面的命令，先填自己的信息，再做其他操作。主要用处是 pull 和 push 代码。

ssh-agent bash
ssh-agent -s

ssh-add.exe /d/kelu/git    # 填密钥

可以根据下面步骤 2 里的内容，以后就不需要这么麻烦了。

1. 查看我的 git 配置

   git config --list
   

2. 创建一个 .bashrc 文件，用于git缩写。

   touch ~/.bashrc
   

   然后你的用户目录下就会多了这个文件。用 notepad 编辑，将常用的 alias 命令放进去。

   alias ga="git add ."
   alias gs="git status"
   alias gm="git commit -m"
   alias gd="git diff --cached"
   alias gl="git log --stat"
   alias gr="git branch -r"
   alias grl="git log --pretty=oneline --graph -n 5"
   alias gpush='ssh-agent bash -c "ssh-add $HOME/.ssh/xxx;git push"'
   alias gp='ssh-agent bash -c "ssh-add $HOME/.ssh/xxx;git pull"'
   

   效果如下：

   

3. git log 乱码

   如下，在git bash的界面中右击空白处，弹出菜单，选择选项->文本->本地Locale，设置为zh_CN，而旁边的字符集选框选为UTF-8。然后重启 git bash，就可以显示中文了。

   

4. 查看远端分支信息：

   git remote -v
      
   origin  git@xxx.git (fetch)
   origin  git@xxx.git (push)
   

   分支相关操作

   git branch -r 		# 查看远程分支
   

   查看远程某个分支的提交历史

   git fetch origin
   git log origin/branch-name
      
   # 我常用的命令，看某个分支最近 5 次的提交，用图形化的方式展示出来
   git log --pretty=oneline --graph -n 5 origin/04-master
   

5. 分支merge 的操作在图形界面里操作，因为还涉及审核等流程。

6. 查看某个提交的细节：

   git log --pretty=oneline 	# 查看提交 hash 值
   git show <hash> 					# 查看具体的修改内容
      
   

7. 拉取远程所有分支到本地：

   git checkout --track origin/dev   
   ....
      
   git branch     # 分支列表
   

8. 切换分支

   git checkout testing 	# 切换分支
   git checkout -b iss53 # 新建并切换到分支
   

参考资料

• Git Bash终端中文输出显示乱码解决方案

1. Window -> Preferences 菜单，点击进入。
2. General -> Appearance -> Colors and Fonts
3. Basic -> Text Font

最近在使用 chatgpt 进行学习，这篇文章记录使用的过程备忘和一些注意点。

另外，这篇文章默认你身处海外，如果国内则不适用，相关网络问题略去不表。

一、chatgpt 3.5

使用步骤分为两步：

1. 准备海外的手机号
2. 邮箱注册

由于 openai 的运营策略，免费版的chatgpt3.5根据服务器的负载情况，有可能出现每几个对话就有断线，需要刷新页面重连。当然也有很大可能和你使用的网络有关系。一开始配置不好，我的也经常断开，后来调整了一些，几个小时也没有断的。

最近听说同一个 ip 登录多个账号，也有可能导致无法访问甚至账号禁用，还请注意：

1. 准备海外手机号

首先，登录一个国外临时手机号购买网站：https://sms-activate.org/

点击右上角的注册：

输入邮箱、设置密码完成账号注册。

注册成功后，在账号中，点击右上角的充值。

选择支付宝进行充值：

输入金额：0.2美元，点支付。（近期改变了策略，似乎需要2美元）

然后进入支付宝扫码付款页面，扫码支付即可。

自动汇率换算支付人民币：

支付成功后，回到账号后台，点击左侧的OpenAI（或者在服务搜索中搜索OpenAI）。

买一个手机号

ps，图中的英格兰，其实和Guernsey共用44打头的号码。

购买后，账号页面右侧，可以看到你购买的手机号：

关于这个国外手机号说三点：

• 这是一个临时手机号，有效时长20分钟
• 20分钟内如果没有收到验证码，可以点右侧的叉号，退订，费用还会返还。（注：一般在ChatGPT注册页面发出验证码后一分钟左右便可以收到验证码。收不到验证短信可以在20分钟到期前退订，三分钟以上收不到验证码建议就不用再等了）
• 如遇到无法登录的情况，请打开谷歌浏览器的无痕窗口进行登录，一般会很快登录账号。

另外保留这个显示国外手机号的页面处于打开状态即可，便于第三个步骤中快速回来查收验证短信。

2. 邮箱注册

打开ChatGPT的官方网站：https://openai.com/

点击API。

点击注册按钮：

输入邮箱，并点击继续：

打开邮箱，点击OpenAI发来的验证邮件，点击验证按钮。

选择手机号国别，并输入第二步中购买的手机号码，点击发送验证短信（send code）：

然后返回到第二步中购买手机号的页面，查收短信：(一般一分钟左右可以收到短信）

输入验证码即可。验证后，恭喜你已获得一个ChatGPT账号。

3.了解ChatGPT后台

登录后首先是账户概览（overview）:

可以看到ChatGPT提供的主要功能：

• 文字生成、编辑
• 代码生成、编辑、及解释
• AI图片生成
• 微调：为自己的使用训练ChatGPT
• 嵌入：用于搜索、分类、对比文本

4. 工具文档

其次是ChatGPT的文档介绍。你可以理解为ChatGPT的使用说明书。

比如，里面涵盖了ChatGPT各种功能的使用指南介绍。

5.示例

这里包含了ChatGPT应用的各种示例，也可以理解为一个工具FAQ。

注意这里可以选择不同的应用场景来试用ChatGPT:

点击“try it now”, 进入ChaGPT工具使用界面。

在对话框中输入指令，开始使用ChatGPT工具。

二、chatgpt 4.0

1. ChatGPT 与 ChatGPT plus 的区别

Plus为升级版，使用免费版本的时候，经常会遇到隔几分钟就要刷新一次的情况，服务器拥挤导致无法使用的问题。Plus版本则很少出现。

Plus是需要付费的，每个月20美元，普通版本是免费的。

Plus为开发人员构建应用程序和服务的 API。

Plus版本可以拥有使用GPT4.0的权限.

2. ChatGPT 3.5 与ChatGPT 4.0 的区别

上图是OPAN AI网站的解释，一共三个方面。

• 4.0拥有更多的参数，给出的答案更具有参考性（实际体验过程中，因为要结合更多的数据，所以导致会话反而变慢）
• 可以识别图片
• 提供更长的上下文（这一点解决了GPT3.5的痛点）

3. 是否推荐升级GPT4.0

如果你是作为一个运营人，会经常涉及到一些文案的工作，建议可以去升级4.0。

如果你只是偶尔使用一下，3.5的开源就可满足你，也不必再去瞎折腾。

4. 升级流程

如果你有开户地为美国或非中国地区的信用卡，可以直接升级。

否则可以参考如下流程：

1. 欧易平台购买 USDT
2. 提现到 Depay 钱包
3. 兑换成美刀充进 Depay 信用卡
4. 购买 ChatGPT Plus

4.1 USDT充值的欧易账户申请

由于Depay不支持人民币直接充值，因此需要利用交易所平台来完成人民币至USDT再兑换为USD美元的过程。

在Depay账户中获得USD美元后，再进行充值。这里简单介绍一下USDT：它是一种名为泰达币的虚拟货币，与USD挂钩，因此安全性无需担忧。

注册欧易账户后，下载并安装其APP。如果在安装过程中系统提示安全风险，无需担忧，因为虚拟货币相关的应用通常会引发误报。从官方网站下载的应用是安全的，可以忽略此提示。

安装成功后，打开欧易App，点击首页——选择购买币种——快速购买——选择USDT——至少购买23USDT（约合200元人民币）——支持使用支付宝、微信或银行卡进行购买。

4.2 申请虚拟信用卡 Depay

ChatGPT要求使用美国信用卡，而国内的双币卡和全币卡均无法使用。对于没有美国信用卡的国内用户，可以选择知名的Depay美国虚拟信用卡。

注册Depay账户，可以使用电子邮件或手机号，如果未收到验证码，请检查垃圾邮件箱。注册成功后，下载并安装Depay App。

苹果手机需要登录海外Apple账户，安卓手机可以直接下载apk文件进行安装。安装完成后，使用刚刚注册的账户和密码登录Depay。

4.3 申请首张虚拟信用卡

点击界面左上角的“申请卡”以开通虚拟信用卡。在开卡时可以选择0开卡费或10USDT开卡费。0开卡费的卡需要完成KYC认证，即上传身份证（国内身份证可用）进行认证。建议选择0开卡费的卡以长期使用。

开通虚拟信用卡后，可以将USDT充值到Depay。下一章节将详细介绍这一步骤，需使用前述注册的欧易账户进行USDT充值。

4.4 充值USDT至钱包

• 打开Depay App钱包，找到钱包——USDT——充币，复制你的充值地址。请务必确认屏幕上显示的是TRC20主网。千万不要复制错了充值地址。

  

• 打开前述第2步注册的欧易App，在首页中找到资产选项。然后，选择提币——USDT——链上提币。在提币地址处填入Depay钱包的充值地址。

  在提币网络选项中，务必选择TRC20（千万不能选错，否则无法到账）。提币数量选择大于23USDT的数字即可，足够充值1个月的ChatGPT Plus会员费用。提交提币请求，等待到账。

  

• 当欧易成功提现至Depay后，请打开Depay App钱包，然后选择“兑换”选项。将所有的USDT都兑换成USD美元。

  

• 完成将所有USDT兑换成USD美元后，在Depay App首页中点击“To Card”选项，将兑换得到的美元存入虚拟信用卡中。至此，Depay充值的全部流程就完成了。

4.5 开通ChatGPT Plus

在第4步向其中充值了20多美元。足够订阅1个月的ChatGPT Plus服务。

现在，登录ChatGPT后，可以在左下角找到升级至Plus的选项——”Upgrade to Plus”。点击该选项，按照提示输入您的虚拟信用卡信息进行支付，即可成功开通ChatGPT Plus。

三、chatgpt api

你可能会遇到一些国内的chatgpt的套壳网站，要求输入api keys，拥有不需要使用任何翻墙就可以直接与chatgpt对话的能力。

原理是调用了chatgpt账户的api接口，它允许任何企业或个人在他们自己的应用程序、网站、产品和服务中使用 ChatGPT 功能，并且是最新的训练模型，$0.002/1K tokens的价格看起来也似乎非常诱人。链接：https://platform.openai.com/account/api-keys

按照步骤二 chatgpt 4.0 中完成付款信息填写：

OpenAI 官方针对每一个新注册的账户，提供$18免费token使用额度。不过需要注意的是，免费额度有时间限制，过期了额度就作废。

收费标准是 $0.002/1K tokens，大概 750 词。虽然1k个token看起来很多。但其实，发送一段供API响应的文本可能就会花费不少token。据观察，基本问1个问题就要耗费100~200个token，算起来其实不少的，尤其在连续会话中，为了保持对话的连续性，必须每次都要回传历史消息，并且输入都要算 token 数算钱的，满打满算，按量付费其实也不便宜。

按照一般的经验来看，在英语中“一个 token 通常对应大约 4 个字符”，而1个汉字大致是2~2.5个token。

举一个官方的说明例子可能更直观一些：根据 OpenAI 官方文档，“ChatGPT is great!”这组单词就需要六个 token—— 它的 API 将其分解为“Chat”、“G”、“PT”、“is”、“great”和“!”。

如果想查询一串指定的文本到底需要耗费多少个token，官方有提供一个免费查询计算器：

四、bing

直接访问 http://www.bing.com/new：

登陆即可。只要能访问到这个界面，微软账号不需区分国内国外都可直接使用聊天功能。

五、Google Bard

Google 在两年前推出了可以进行多轮对话的 AI 模型 LaMDA，并在 2022 年推出了 AI Test Kitchen，一个面向开发者和研究者的，以帮助他们学习、演练和使用人工智能技术的平台。

Bard 则是基于 LaMDA 和 AI Test Kitchen 相结合开发而来的轻量级优化版本，它能与用户协作，帮助提高工作效率，例如规划生日派对、起草邀请函、创建赞成反对名单或理解复杂主题等。

值得注意的是，目前 Bard 测试范围限制了仅支持美国，其他国家地区还得等待！也就是说，你现在必须要有美国的 IP 才能申请。

在官网排队申请中：https://bard.google.com。

申请完成后界面如下，目前我觉得的还是有点白痴：

六、文心一言

排队中界面如下：https://yiyan.baidu.com/welcome

通过后的界面如下：

参考资料

• ChatGPT注册教程攻略：解决手机无法接收验证码问题
• 收藏：如何注册Chat GPT以及10个使用技巧（Chat GPT的完整使用教程）

原文：http://arthurchiao.art/blog/traffic-control-from-queue-to-edt-zh/

译者序

本文组合翻译了 Google 2018 年两篇分享中的技术部分，二者讲的同一件事情，但层次侧重不同：

• Netdev 2018: Evolving from AFAP: Teaching NICs about time， 视角更宏观，因果关系和历史演进讲地较好；
• OCT 2018: From Queues to Earliest Departure Time，更技术和细节一些。

另外翻译过程中适当补充了一些与 Linux/Cilium/BPF 相关的内容。

由于译者水平有限，本文不免存在遗漏或错误之处。如有疑问，请查阅原文。

以下是译文。

1 网络起源

如果能对网络协议和网卡之间的契约（contract between protocols and NICs） 做出些许改动，就能解决很多问题。解释清这一点需要从历史讲起。

1.1 技术需求与网络起源

时间回到起点。如果你在上世纪 70 年代说“网络”这个词，那它大概长这下面这样：

Fig. IBM 3790 Controller (1974)

这是当时 IBM 新发布的网络架构，称为 SNA（Systems Network Architecture）， 可以看到其中有很多打印机和终端，这就是当时所谓的网络。

左上角是一台 IBM 小型机（mainframe），它非常昂贵，只有高端企业才买得起。而另一方面， IBM 想把小型机打入更广阔市场，这就意味着他们需要把小型机推销给一些小客户， 比如那些只有几个分支机构的银行。 要实现这个目标，在技术上就需要实现分支机构和总部互连，但这一点在当时是做不到的： 当时的计算机都是围绕数据中心模型设计的，昂贵的外设都环绕在计算机附近，距离不过百尺。

因此，为了解决远程互连问题，他们设计了一些远程控制器，能驱动显示控制器（display controller）， 这样客户的分支机构只需要安装相对便宜的显示终端，就能和总部的小型机连通，成本也就下来了。 比如上图中，小型机的成本就可以被 12 个分支机构平摊；此后，大量的银行、金融机构和零售商开始购买 IBM 小型机。

这就是网络（network）最初的样子， 这一时期（70 年底早期和中期）各种网络协议互相竞争，但可以分为两类：

1. 政府资助研究项目：英国的 NPL 网络、美国的 ARPANET（互联网的前身）、法国的 CYCLADES 等；
2. 计算机厂商私有：IBM 的 SNA、DEC 的 DECnet 等。

1.2 私有协议和厂商锁定

计算机厂商开发计算机网络（computer network）的目的其实非常简单：

1. 通过卖设备（小型机和远程终端等）给企业客户赚钱；
2. 通过私有协议锁定客户（lock-in customers），卖更多设备给他们赚更多钱。

计算机厂商的首要目的是卖硬件，不希望客户用竞争对手的产品，因此首先要做的是在产品上锁定客户。 如果你认为网络的出发点是连接全世界，让每个人的每个设备都能彼此自由通信，那就太理想主义了； 网络的起源没有这么高尚，而是纯商业行为：每个计算机厂商都希望客户购买自己的网络设备， 并且只能和自己厂的设备通信，其他厂商的设备一概不能连接。

1.3 早期厂商网络方案的问题

私有协议和厂商锁定导致的几个后果：

1. 研发显示器、打印机、读卡器等等这些外设（peripheral devices）的 工程师主导了网络设计，这一点对后世影响深远。

   对此时的厂商来说，外设和功能才是重要的，网络只是一个从属地位。 因此，我们会看到网络协议中包含很多直接与设备相关的东西，非常怪异，例如与打印机 通信时，需要考虑到它打印和弹出纸张的速度，可能是一条命令发送过去，然后传输 协议里规定等待两秒（等待打印过程），设计的非常傻（那时也没有多少内存可用， 内存非常稀缺和昂贵）。

2. 通信链路非常慢（300bps/2.4Kbps/56Kbps），导致协议被过度简化。

   有钱的金融客户使用的可能才只是 2.4Kbps，如果真的非常非常有钱，才会考虑 56Kbps，这是当时的上限。由此导致的两个设计：

   • 尽量减小头开销（header），头越小越好；
   • 协议要精简/简化，不要太啰嗦。例如，避免明确回复对方说 “包我收到了”，而是假设在大多数情况下，包都能在 timeout 之前正常被设备接收。

3. 由于以上两点，需要针对不同设备/控制器型号有不同的数据包封装格式。

不难猜到，这种架构和产品并不成功。 我们关注的不应该是什么人或什么设备在使用网络（what’s using the network）， 而是如何使得网络可用和好用（making the network usable）。 由此引出今天的事实标准 —— TCP/IP 协议 —— 的诞生。

1.4 TCP/IP 协议模型

TCP/IP 的设计吸取了以上教训。这里主要强调三点：

1. Simplicity：加到协议里的东西必须是有用、清晰、无异议的；
2. Expressive abstractions：网络模型（抽象）必须有很强的表达能力，能用于解决不同的实际问题；
3. Implementable contracts：协议层之间的契约可实现，不能过于理论导致落地困难。

TCP/IP 最大的特点是没有对周边（应用类型、协议效率、网络结构等）做出限制。 有些东西理论上很美好，但实现起来会巨复杂，和当初设想的完全不一样； TCP/IP 架构组的每个人都亲自实现过协议，在 ARPANET 工作过，经验丰富，因此避免了很多之前已经出现过的问题。 最后，他们只设计了两个主要协议，构成了如今的 TCP/IP 模型：

• IP：网络层协议
• TCP：传输层协议

1.4.1 IP：尽力而为传输（best effort delivery）

IP 层传输的是接口到接口的小消息（interface to interface small messages）。

IP（Internete Procotol）是不可靠的（unreliable）尽力而为传输（best effort delivery）。

计算机厂商的私有网络方案和 IP 方案是竞争关系，因此他们看到这个方案时会说：你们这个 IP 方案只有传输数据包的功能，我们的方案还能做 XX、YY、ZZ …，但我要强调的是，这些并不属于 best effort 的范畴： 网络层应该只有唯一功能，那就是传输数据包（deliver packets）， 如果你给一个包它无法传输，那唯一原因应该是它正在传输其他包，其中的竞争条件需要你等待。 “尽力而为”并不是什么都做，而是聚焦在一个功能点，尽最大职责把这个功能做好。

“尽力”的另一层意思是可能会有失败，因此需要想好应对方案。这就轮到 TCP 层出场了。

1.4.2 TCP：最终可靠传输（eventual delivery）

TCP 与 IP 层之间的契约：

• IP 层尽力而为，
• TCP 在 IP 的基础上实现最终的可靠通信。

最终可靠性很重要，因为我们不知道什么时候会失败，因此需要 重试等机制来保证传输结果最终是成功的。

1.4.3 小结

TCP/IP 的成功并不是因为它们规定了什么，而是它们没规定什么： 没有对上层应用、协议效率、网络结构、代码实现做出任何假设。 在设计方案时，做出某些假设、前提、限制很容易，但以后想把其中一些限制去掉时， 就很难甚至不可能了，因此前期的设计非常重要。

网络有了，接下来进入本文正题：网络传输过程中的流量控制。

2 网络传输

2.1 技术需求：越快越好（或尽可能快，AFAP）

网络传输的需求是尽可能快（as fast as possible），这一点是显然的。

那我们看看 TCP 发送机制中，哪些因素会制约发送速率。

2.2 TCP 发送机制：只限制发送多少，未限制发送多快

TCP 的设计机制是可靠传输，它限制了发送多少 （how much is sent），但没有限制发送多快（how fast）。 理解这一点非常重要。越快越好是天然需求，既然 TCP 机制没对发送速率做出限制，那 发送端就自然就出现了“尽可能快”（AFAP）这样一种事实发送机制 （即所谓的 “work conserving”）。

那么，怎么实现 AFAP 呢？一般是通过所谓的流量整形/整流（traffic shaping）。

2.3 基于 queue 做流量整形

实际中，流量整形通常通过 device output queue（设备发送队列）实现；

• 最快发送速率就是队列的 drain rate；
• 传输中的最大数据量（inflight data） 由 RX window 或 queue length 决定。

下面具体看怎么做整流。

2.3.1 流量整形器（shaper）原理：以 token bucket queue 为例

如下图所示，原理比较简单：

Fig. 通过多个 token bucket queue 实现一个 shaper

1. 主机的出向流量（egress traffic）经过一个分类器（classifier）进行分类；

   这里的 egress 流量一般都来自 socket buffer，可能是主机自己的流量，也可能是里面 VM/container 的流量。

2. 分类之后的流量分别放到不同的 queue（缓冲队列），各 queue 的发送速率限制可能是不同的；

3. 某个调度器（scheduler）负责统一调度以上所有 queue 的发包，将包从 queue 中取出放到主机网卡的 TX queue 中；

4. 网卡将 TX queue 中包无差别地发送出去。

中间的三件套：

1. 分类器（classifier）
2. 缓冲队列（queue）
3. 调度器（scheduler）

就组成了一个流量整形器或称整流器（shaper）。

2.3.2 AFAP shaper 历史贡献：支撑 TCP/IP 在过去 25 年速度 10000x

以上这种 AFAP shaper 在过去 25 年支撑了 TCP/IP 从 10Mbps 演进到 100Gbps， 速度快了一万倍，几乎完美贴合摩尔定律：

Fig. 以太网 25 年的带宽变化，从 10Mbps 增大到了 100Gbps

在这 25 年里，“多快”取决于 queue 的 drain rate，因此发送速率上限取决于主机侧（local）； 对于网线来说，限制是在上游（发送端主机是上游，交换机、路由器、接收端等等是下游）。 当希望发送更快时，只需要将网卡及网线从 100Mbps 换成 1000Mbps，非常简单直接。 主机外面的东西不用担心，自然会有人和技术能支撑主机的线速发送（下面会讨论）。

2.3.3 面临的问题：延迟和丢包

刚才提到，这种机制的前提是发送瓶颈在主机端，因此主机发送多快都没关系， 不用担心会把主机外面的什么设备或网络路径打爆。 这就意味着，主机端（更准确地说是此时的瓶颈）有时 —— 甚至是长时间 —— 运行在 100% 的。 更具体地说，你可能用的是线速 10Gbps 的网卡，但主机上的应用流量太大了， 导致以上 shaper 长时间把速度限制在 10Gbps，超过 queue 的包只能丢弃了。 排队论（queuing theory）也从数学上告诉我们，这是不稳定的（e.g. for M/D/1）：

Fig. 根据排队论，实际带宽接近瓶颈带宽时，延迟将急剧上升

因为这种情况下的到达速率持续大于离开速率，队列爆了。 离开速率是网卡线速，没法调整了，因此只能调整到达速率，也就是从源头控制发包。

2.3.4 缓解/避免丢包的方式（2012 年之前）

这个问题比较棘手，因为实际上不止是主机侧，在网络传输路上上多个地方都有 buffer queue， 有些地方并不受你控制：

• 可能是在距离你 9 跳之外的某个 buffer 非常小的交换机；
• 或者是某个 ISP 与家庭的 buffer 非常小的连接处

因为他们都尽量用便宜的交换机。

如果满足以下几个条件之一，延迟/丢包就可以避免：

1. 带宽与延迟乘积（bw * delay，BDP，也就是正在传输中的数据量） 非常小；

   这一点在 1995 年之前是成立的，因为早期的内存非常昂贵，带宽也非常低（几 KB/s），因此这个乘积非常小。这种情况下没有大 queue 也不会丢包。

2. 每个网络瓶颈处都有一个大缓冲区路由器（fat-buffered router）；

   1995 年之后，路由器厂商开始制造大量的大内存（大缓冲区）路由器，（交换机）内存很便宜，交换机厂商也借此赚了不少钱。 如果每个可能的瓶颈点都放了 buffer 很大的路由器，能支撑很大 inflight BDP，也可以解决丢包问题。

3. 服务器到置顶交换机（hosts to TORs）的速度比交换机之间（fabric）要慢。

   这一点类似通信厂商：拉开接入带宽（access bw）和交换带宽（fabric bw）的差距。 例如，接入是 10Gbps，路由器之间的交换带宽是 100Gbps；或者接入 40Gbps，交换 400Gbps。 这种情况下服务器 AFSP 并不会有问题，因为上面有更快的交换网络（实际上是一个 fat pipe）。

第 2 点和第 3 点的缺点是会带来额外延迟（下游的路由器上）， 例如 Gbps 级别的路由器可能就会带来秒级的延迟。但这还不是最糟糕的， 最糟糕的是2012 年之后，即使愿意忍受更大的延迟也无法避免丢包了， 因为摩尔定律失速了，这也意味着主机侧 AFAP 模型（主机全速发送，不需要考虑外面的瓶颈和延迟）走到头了。

2.3 带宽摩尔定律失速（2012 年之后）

技术层面上，从摩尔定律看以太网的发展，明显能看到两段曲线：

• 早期（2000 年之前）：每 12 个月带宽就能翻一番，明显快于标准摩尔定律的 18 个月；

• 后期：需要 24 个月，也就是慢于标准摩尔定律，这种增长方式已经不可持续了；

  如果你年纪够大的话，应该记得 计算机世界在 2000~2005 年发生了根本性变化： 之前我们已经习惯了处理器每 18 个月性能翻一番，但到了 2003 年 Intel 突然告诉我们下一代奔腾处理器不能快一倍了 ——甚至实际上还会慢一点， 然后通过多核来提升整体性能：给你 2 个或 4 个核。受限于物理限制，我们无法做 到更快了，此后提升应用整体性能的方式就是多核并行。

Fig. 真实以太网演进速率与摩尔定律理论速率

这种不可持续性打破了园区网和数据中心网络建设的传统模型（“fabric 带宽永远比 access 带宽高一个数量级”）， 因为更高的带宽上不去了，或者能上去一些但是成本太高了，最后的结果就是 服务器的网卡带宽（access bw）追平了交换机之间的互联带宽（fabric bw）。 这样一来，交换机就不再能 buffer 大量的服务器包了，尤其是多个主机访问同一个目的端、命中通过一个交换机端口的时候。 不管是数据中心网络还是边缘网络都面临这个典型问题。

单核摩尔定律的突然终结深刻影响了网络和计算，但对网络的影响更大。

• 这打破了之前的带宽层级（bandwidth hierarchy）模型， 我们无法造出速度永远比网卡快一个数量级的交换机了。
• 原来单核或但主机能完成的事情，现在必须分散到大量机器上来并行处理，这给交换网络造成了巨大挑战。 之前只需要原地升级 CPU 就能解决，不需要动网络，该怎么连接到 fabric 的还是怎么连， 现在只能分发到多个 CPU、机器上去。

网络模型发生了本质变化。

3 Google 网络团队的一些创新

以上讨论意味着，基于缓冲队列（queue）的机制已经不符合当前网络现状了， 不能再简单基于网卡的最大工作速率来发包。

3.1 思路转变：从基于 queue 到基于 time

Google 的解决思路是：感知网络瓶颈，以瓶颈处的最大发送速率发送数据包（determine what’s AFAP at the bottleneck and run at that rate）。做到这一点，依赖的最重要 因素不再是 queue，而是时间（time）。

3.2 一些已发表论文

应用分散到多台机器并行计算再将结果汇总，这样跟之前的单机运算为主模型完全不同， 对网络的影响非常大，对网络影响和问题数量是成倍的，例如我们在我们的 fabric 中遇 到的问题，在 jupiter paper 中讨论了一些。

如果中间丢包太严重了，就只能将流量管理前移到主机上。此时网络可能已经是无缓冲区 交换机了，因为你在发送大量随机流量，而多个突然流量重叠时，交换机根本没有能力缓冲。 此时，你唯一有能力缓冲也有能力控制的，就是发送端主机。

因此我们做的工作就是在源点主机，这些文章都是一个主题：让我们回到源点来解决问题： 哪里是瓶颈，瓶颈决定了 AFAP；不能拥塞 TOR，它已经在全速工作了。需要知道下游 的一些状态，来控制本地发送速率，以避免给下游造成过大压力。

Google 近些年所做的一些工作：

• HULL (NSDI’12) – Less is more: trading a little bandwidth for ultra-low latency

  Traditional measures of network goodness—goodput, quality of service, fairness—are expressed in terms of bandwidth. Network latency has rarely been a primary concern because delivering the highest level of bandwidth essentially entails driving up latency—at the mean and, especially, at the tail. Recently, however, there has been renewed interest in latency as a primary metric for mainstream applications. In this paper, we present the HULL (High-bandwidth Ultra-Low Latency) architecture to balance two seemingly contradictory goals: near baseline fabric latency and high bandwidth utilization.

  用到了：

  • Phantom Queues that deliver congestion signals before network links are fully utilized and queues form at switches
  • DCTCP, a recently proposed congestion control algorithm
  • Packet pacing to counter burstiness caused by Interrupt Coalescing and Large Send Offloading

  Our implementation and simulation results show that by sacrificing a small amount (e.g., 10%) of bandwidth, HULL can dramatically reduce average and tail latencies in the data center.

• BwE (Sigcomm’15) – Flexible, Hierarchical Bandwidth Allocation for WAN

• FQ/pacing (IETF88’13) – TSO, fair queuing, pacing: three’s a charm

• Timely (Sigcomm’15) – RTT-based congestion control for the datacenter

• BBR (CACM v60’17) – Congestion-based congestion control，中文版

• Carousel (Sigcomm’17) – Scalable traffic shaping at end hosts

4 从基于队列到基于时间戳：qdisc/EDT 详解

本节从技术层面介绍和分析两种模型。

4.1 基于 queue 的整流器

更多关于 tc qdisc 的内容： （译）《Linux 高级路由与流量控制手册（2012）》第九章：用 tc qdisc 管理 Linux 网络带宽

Fig. 通过多个 token bucket queue 实现一个 shaper

原理前面介绍过了。存在的问题：

• CPU 和内存开销：可能很大
• 需要同时满足网络带宽策略和拥塞控制需求，例如 TCP
  • Pace packets
  • Provide backpressure
  • Avoid HOL blocking

4.1.1 示例一：HTB

Fig. HTB shaper 原理

问题：

1. CPU 开销随 queue 数量线性增长；
2. 多个 CPU 共享多个 queue，导致 CPU 之间的同步（锁/竞争）开销。

4.1.2 示例二：FQ/Pacing

Fig. FQ/pacing shaper 原理

性能开销问题和上面的 HTB 一样。

4.1.3 小结

如果去掉 queue，就可以避免上面两项开销：我们的思路是把时间 （time）作为一个基础元素，同样能实现整流目的，但所需开销非常低。

为此，引入了 EDT（earliest departure time）模型：

• 给每个包设置一个 EDT 时间戳，控制何时发送这个包；
• 在网卡前或网卡中执行调度机制（enforcement mechanism），根据时间戳控制 egress 发包。

Carousel 正是这样一种机制。

4.2 Carousel：基于 EDT 的整流器

Fig. 传统基于 queue 的流量整形器 vs. 新的基于 EDT 的流量整形器

如上图所示，核心理念：用两项简单工作替换原来缓慢、脆弱、级联的排队系统：

1. 给每个包（skb）打上一个 Earliest Departure Time (EDT) 时间戳；

2. 用一个时间轮调度器（timing-wheel scheduler）代替原来 网卡前或网卡中的发包缓冲队列（queue）。

   时间轮模型，可参考 Hashed and Hierarchical Timing Wheels, Varghese & Lauck, SOSP 87.

下面再展开介绍一下。

4.2.1 原理及特点

Fig. Design

1. 调度复杂度：O(1)，待发送的包都是按时间戳排好序的；
2. 调度器能直接给 socket 反压，控制 socket 发送速率；
3. 每个 CPU 一个 shaper，无锁，开销低。

4.2.2 Life of a packet in Carousel

Fig. Life of packet in Carousel

4.2.3 与基于 queue 的 shaper 的对比

timing wheel 能完成 queue 的功能，它不仅能做的事情更多，并且做的更快：

1. 插入和删除操作都是 O(1)，复杂度和 queue 一样，但是开销更低，
   • cache friendly (no pointer chains)
   • RCU friendly (single slot to update) Driver (or NIC) gets to choose ‘event horizon’ (wheel length) so can do BQL-like tuning for long enough to fill wire but short enough to not blow away caches.
2. Packets that would be sent after event horizon can get TSQ-like callback when they can be sent or get an ETooFar. This replaces TSQ and fixes problem of many simultaneous writers generating huge queues.
3. It also puts hard bounds # of active output bytes, increasing probability of L3 cache hits for systems that can DMA from L3.

4.2.4 qdisc 功能变化

有了 EDT， qdisc 能做的事情更多，同时开销也更低了： qdisc 变成了一个纯计算模块，不再需要维护内部队列了（intermediate queues），

• driver gets to see all packets in its event horizon so can easily do informed interrupt mitigation, lazy reclaim, (wifi) endpoint aggregation…
• sender learns packet send time on send() and can handle deadlines, seek alternatives, do phase correction…

In essence, timing wheel is an in-memory representation of how packets will appear on wire. It can represent almost any causal scheduling policy.

(Policies like ‘Maximize Completion Rate’ are impossible to express with rates but easy with timestamps so we can finally make transactions ‘fair’ without stupidly slowing everything down.)

4.3 小结

• 主机侧的网络模型应该从 AFAP 切换到 EDT 了；
• EDT 比 AFAP queue 更加高效和简洁；
• 基于 EDT 不仅能实现传统基于 queue 的 shaper 的各种调度策略，而且还能实现更多新的调度策略。

5 Linux EDT 支持与实践（译注）

较新的内核版本已经支持。

5.1 Cilium pod egress 限速

Cilium 用了 EDT 做容器 egress 限速：

• (译) 为容器时代设计的高级 eBPF 内核特性（FOSDEM, 2021）
• (译) 为 K8s workload 引入的一些 BPF datapath 扩展（LPC, 2021）