如图1所示，以便于了解内部流程如何影响流经Tor中继的客户端流量。[1]
1 TCP连接（connection）的多路复用。Tor中的所有中继使用成对TCP连接进行通信，即每个中继与彼此通信的每个中继形成单个TCP连接。 由于一对继电器可能同时为多个电路（circuit）传送数据，因此该对之间的所有电路都通过其单个TCP连接进行多路复用。 每个电路可以承载用户可能正在访问的多个服务或流（stream）的流量。 TCP在多路复用连接时提供可靠性，在中继之间按顺序传送数据包，以及可能不公平的内核级拥塞控制[47]。 了解连接，电路和流这三者的不同对于理解Tor非常重要。
2 TCP连接输入。 Tor使用libevent处理内核TCP缓冲区的输入和输出。 Tor使用libevent注册要读取的套接字，并配置通知回调函数。 当数据到达内核TCP输入缓冲区时（figure 1a），libevent通过其轮询接口了解活动套接字，并异步执行相应的回调（figure 1b）。 执行时，读取回调使用令牌桶确定读取资格。
令牌桶用于限速连接。 Tor按照配置的带宽限制以1秒的间隔填充桶，同时在读取数据时从桶中移除令牌，尽管目前正在探索改变该间隔以提高性能[53]。 有一个全局读取存储区限制了从所有连接读取的带宽，以及一个单独的存储区，用于基于每个连接进行限制（figure 1c）。 如果全局存储桶或其连接存储桶为空，则连接可能会忽略读取事件。 实际上，每连接令牌桶仅用于边缘（非中继）连接。 连接限制通过惩罚噪声连接（例如批量传输）来减少网络拥塞，并且通常会带来更好的性能[17]。
当TCP输入缓冲区符合读取条件时，循环（RR）调度机制用于读取每个连接中16 KiB和18个全局令牌桶大小中较小的一个（figure 1d）。 这种限制是为了公平起见，因此单个连接不能消耗单个读取上的所有全局令牌。 然而，最近的研究表明，输入/输出调度会导致不公平的资源分配[54]。 从TCP缓冲区读取的数据放在每个连接的应用程序输入缓冲区中进行处理（figure 1e），具体来说，在数据到达连接输入缓冲器之后，立即将单元重新排列到它们各自的电路队列中（按FIFO顺序），在那里它们等待进一步处理。这也是用于确保匿名的加密操作的地方。正如之前的工作所表明的那样，这些操作并不是性能瓶颈[61]。因此可以在这里安全地忽略它们。
3 流量控制。 Tor使用端到端流量控制算法来帮助保持稳定的电池流过电路。客户端和出口继电器构成电路的边缘：每个都是穿过Tor网络的数据的入口和出口点。边缘使用称为窗口的单元计数器跟踪电路和流的数据流。入口边缘在发送信元时递减相应的流和电路窗口，当其流窗口达到零时停止从流中读取，并且当电路窗口达到零时停止从电路上复用的所有流中读取。在从出口边缘接收到SENDME确认信元时，Windows递增并且恢复读取。
默认情况下，电路窗口初始化为1000个单元（500 KiB），流窗口为500个单元（250 KiB）。在出口边缘接收100个信元（50 KiB）后，电路SENDME被发送到入口边缘，允许入口边缘读取，打包和转发100个附加信元。在接收50个小区（25 KiB）之后发送流SENDME并允许另外50个小区。窗口大小会对性能产生重大影响，最近的工作提出了一种动态计算它们的算法[7]。
4 细胞处理和排队。 数据在到达连接输入缓冲区时立即被处理（figure 1f），并且每个单元根据其通过电路的方向加密或解密。 然后将单元切换到与下一跳相对应的电路上，并放入电路的先进先出（FIFO）队列（figure 1g）。 单元在电路队列中等待，直到电路调度器选择它们进行写入。
5 调度。 当连接的输出缓冲区中有可用空间时，继电器决定选择多个多路复用电路中的哪一个进行写入。 虽然历史上这是使用循环法完成的，但最近在Tor [52]中引入了新的指数加权移动平均（EWMA）调度程序，并且目前默认使用（figure 1h）。 EWMA记录它为每个电路调度的数据包数量，随着时间的推移呈指数衰减数据包计数。 调度程序在从具有最低数据包计数的电路中选择的时间写入一个单元，然后更新计数。 衰减意味着最近发送的数据包对计数的影响更大，而突发流量不会显着影响调度优先级。
6 连接输出。 已选择并写入连接输出缓冲区的单元（figure 1i）会激活为该连接注册libevent的write事件。 一旦libevent确定可以写入TCP套接字，就会异步执行写回调（figure 1j）。 与连接输入类似，中继检查全局写入桶和每个连接写入桶的令牌。 如果存储桶不为空，则连接符合写入条件（figure 1k），并且允许再次写入每个连接的16 KiB和1 8全局令牌桶大小（figure 1l）。 数据被写入内核级TCP缓冲区（figure 1m）并发送到下一跳。
参考文献：
[1] Jansen R, Syverson P, Hopper N. Throttling tor bandwidth parasites[C]//Presented as part of the 21st {USENIX} Security Symposium ({USENIX} Security 12). 2012: 349-363.
[47] REARDON, J., AND GOLDBERG, I. Improving Tor using a TCPover-DTLS tunnel. In Proceedings of the 18th USENIX Security Symposium (2009).
[17] DINGLEDINE, R. Research problem: adaptive throttling of Tor clients by entry guards. https://blog.torproject. org/blog/research-problem-adaptivethrottling-tor-clients-entry-guards.
[54] TSCHORSCH, F., AND SCHEUERMANN, B. Tor is Unfair–and What to Do About It, 2011.
[7] ALSABAH, M., BAUER, K., GOLDBERG, I., GRUNWALD, D., MCCOY, D., SAVAGE, S., AND VOELKER, G. DefenestraTor: Throwing out Windows in Tor. In Proceedings of the 11th International Symposium on Privacy Enhancing Technologies (2011).
[52] TANG, C., AND GOLDBERG, I. An Improved Algorithm for Tor Circuit Scheduling. In Proceedings of the 17th ACM Conference on Computer and Communications Security (2010), pp. 329–339.
[61]Reardon, Joel, and Ian Goldberg. “Improving Tor using a TCP-over-DTLS tunnel.” Proceedings of the 18th conference on USENIX security symposium. USENIX Association, 2009.
