第六章传输控制.pdfVIP

第六章传输控制

第五章关注减少与数据操作有关的开销，主要是数据拷贝。本章关注减少数据包处理过

程中的控制开销，包括中断处理、系统调用、进程上下文切换等。

6.1为什么会有控制开销

第五章用web服务器发送文件作为例子，让我们看到在响应get请求的过程中涉及到了

哪些拷贝过程。本章用一个处理大量客户请求的web服务器作为例子，说明在这个服务器

中涉及到了哪些控制开销。

我们来看一下GET请求的服务过程：……

根据上面的叙述，这里的控制开销包括了一次中断处理和两个系统调用。其实这个描述

还是比较粗的，控制开销还不止这些。下面我们看一下不同的代码组织方式还会带来什么样

的控制开销。

代码组织和进程切换

首先看一下网络代码，网络代码是用于处理数据包的代码。我们知道网络功能是按层次

组织的，如果采用简单的结构化，即每一层实现为一个进程，则处理一个数据包要涉及进程

切换。一次进程调度的典型时间是几百微秒，远远高于一个数据包的到来时间（包长/链路

速率），因此这种代码组织方式的控制开销极大。

如果将所有层实现为一个进程，则数据包处理过程中不涉及进程切换，其控制开销是最

小的。目前，大多数网络代码采用的是这种整体化结构。

下面再看web服务器的代码组织方式。前面针对web处理的描述只是关于一个客户的，

我们现在考虑一个服务于几千个并发客户的大型web服务器。

在一个极端上，每个进程服务一个客户，并发度最大（当客户1正在等待磁盘读时，客

户2可以发送网络包），代价是进程调度开销很高。

在另一个极端上，一个进程服务所有客户，这里没有进程切换，但是这个进程必须自己

调度客户来最大化并发度。

一种折中的方法是将客户划分成组，每个组由一个进程处理。

可见，如果应用代码和网络代码组织得很差的话，可能导致相当大的控制开销。这里主

要考虑是权衡调度开销和并发度。

Web服务器中的控制开销

图6.2给出了web服务器中涉及的控制开销。由于本章关注传输控制开销，因此图中忽

略了和数据传输有关的方面，用了一个简化的架构图，重点关注网络适配器与CPU之间、

应用和内核之间、各种应用级进程之间与控制有关的相互作用。为简单起见，图中只画了一

个CPU和一个适配器。

适配器和CPU之间存在中断处理开销；应用和内核之间存在系统调用开销。

不同的内核子系统之间存在进程切换开销（在等待磁盘I/O时，可以继续处理到来的包）。

如果网络代码组织得不好，协议栈内部也存在进程切换开销。

应用层上如果每个客户作为一个进程，或者一组客户由一个进程处理，则存在应用级进

程之间的切换开销。这里不同的组织方式关系到调度开销与并发度的权衡。

如果所有客户由一个应用进程处理，应用进程需要自己调度客户，为此需要知道之前启

动的I/O操作（如读文件、等待收包）是否结束了。许多操作系统为此目的提供了一个系统

调用，在图6.2中笼统地称它为FindActive()，返回已经完成I/O操作的描述符。

从这张图可以清楚地看到，控制开销包括进程切换、系统调用和中断处理三种。

本章考虑的控制开销

本章主要关注进程切换、系统调用和中断处理三种开销，这三种开销的数量级如下：进

程切换几百微秒，系统调用几十微秒，中断处理几微秒。这些数字意味着什么呢？如果在一

个10Gbps的以太网链路上传输最小长度（64字节）的包，则每隔51.2ns会到来一个包。

很显然，我们必须想方设法降低控制开销。特别是，随着CPU的速度越来越高，与进

程切换、系统调用和中断处理相关的开销并没有显著降低（因为这些开销与访存有很大关系）。

下面我们就来介绍如何解决图6.2中描述的瓶颈。

6.2避免网络代码中的调度开销

前面讲到，进程切换开销与代码组织很有关系，所以我们从代码组织入手。

我们首先考虑网络代码的组织，我们看一下现代计算机系统是怎么组织协议栈代码的。

UNIX将所有协议代码作为……

目前普遍认为两次上下文切换的开销是很高的，能不能减少上下文切换的次数呢？可以，

这就是在用户空间实现协议栈。

在用户空间实现协议

用户级协议实现的基本思想是，协议处理与应用在同一个进程中，可以通过upcall进行

通信。

在用户空间实现协议栈有许多好处，……。最早提出用户空间协议栈是为了解决协议栈

定制、维护等问题，在高速网络出现之后，用户空间协议栈更多地