关于 802.11 协议

万次阅读 2016-08-10 15:11:31

一．802.11成帧封装实现 3 1.1控制帧 3 1.1.1 一般的帧控制位 3 1.1.2 RTS（请求发送） 4 1.1.3 CTS （允许发送） 5 原文出处：...

1.1.5 PS-Poll （省电模式一轮询） 7

1.2 数据帧 8

1.2.1 Frame Control （帧控制） 8

1.2.2 Duration（持续时间） 8

1.4 帧发送以及连接与身份认证状态 43

1.5.4 Spectralink 语音优先性 48

1.5.5 帧的分段与重组 49

1.5.6 帧格式 50

1.5.7 Frame Control 位 50

1.5.8 Duration/ID 位 54

1.5.9 Address 位 55

1.5.10 Basic Service Set ID (BSSID) 55

1.5.11 顺序控制位 56

1.5.12 帧主体 56

1.5.13 帧检验序列（FCS ） 57

1.6 802.11对上层协议的封装 57

1.7.4 多种速率支持（Multirate Support ） 63

1.8 帧的处理与桥接 64

1.8.1 无线介质到有线介质（802.11至以太网） 65

1.8.2 有线介质至无线介质（Wired Medium to Wireless Medium ） 66

4.1 Wireshark 关于802.11无线局域网的过滤器 72

4.2 802.11无线局域网缩写词及中文含义 73

正文

一．802.11成帧封装实现

以太网的帧封装十分简单，只要为帧加上同步信号、一些地址信息，以及在结尾加上检验码即可。相对而言，802.11的帧封装就比较复杂，因为无线介质必须将有线网络所没有的帧类型，以及各式管理功能纳入考虑。

802.11帧主要有三种类型。数据帧好比 802.11的驮马，负责在工作站之间传输数据。数据帧可能会因为所处的网络环境不同而有所差异。控制帧通常与数据帧搭配使用，负责区域的清空、信道的取得以及载波监听的维护，并于收到数据时予以正面的应答，借此促进工作站间数据传输的可靠性。管理帧负责监督，主要用来加入或退出无线网络，以及处理接入点之间连接的转移事宜。

1.1控制帧

控制帧主要在协助数据帧的传递。它们可用来监督无线介质的访问（但非介质本身），以及提供MAC层次的可靠性。

1.1.1 一般的帧控制位

为控制帧均使用相同的 Frame Control（帧控制）位，如图1-1所示。

　　　　　　　　　　图1-1：控制帧中的Frame Control 位

Protocol（协议版本）

在图1-1 中，协议版本的值为 0 ，因为这是目前绝无仅有的版本。未来可能会出其他新的版本。

| Type（类型）

控制帧的类型识别码为 01。定义上，所有控制帧均使用此识别码。

| Subtype（次类型）

此位代表发送控制帧的次类型。

| ToDS 与FromDS bit

控制帧负责处理无线介质的访问，因此只能够由无线工作站产生。传输系统并不会收送控制帧，因此这两个 bit必然为 0 。

| More Fragments（尚有片段）bit

控制帧不可能被切割，这个 bit必然为 0 。

| Retry（重试）bit

控制帧不像管理或数据帧那样，必须在序列中等候重送，因此这个 bit必然为0 。

| Power Management （电源管理）bit

此bit用来指示、完成当前的帧交换过程后，发送端的电源管理状态。

| More Data（尚有数据）bit

More Data bit 只用于管理数据帧，在控制帧中此 bit必然为0 。

| Protected Frame（受保护帧）bit

控制帧不会经过加密。因此对控制帧而言，Protected Frame bit 必然为 0。

| Order（次序）bit

控制帧是基本帧交换程序（atomic frame exchange operation ）的组成要件，因此必须依序发送。所以这个 bit必然为 0 。

1.1.2 RTS（请求发送）

RTS帧可用来取得介质的控制权，以便传输「大型」帧。至于多大称之大型：是由网卡驱动程式中的 RTS threshold（门限）来定义。介质访问权只能保留给单点传播（unicast）帧使用，而广播（broadcast）与组播（multicast ）帧只须发送便是了。RTS 帧的格式如图 1-2所示。

就和所有控制帧一样，RTS 帧只包含标头。帧主体中并未包含任何数据，标头之后即为FCS （帧检查码）。

　　　　　　　　　　图1-2：RTS帧

RTS的MAC标头由四个位构成：

| Frame Control（帧控制）

Frame Control位并没有任何特殊之处。帧的 subtype（次类型）位设定为 1011，代表 RTS帧。除此之外，它与其他的控制帧具备相同位。（在 802.11规格书中，最高效 bit乃是最后一个bit，因此在 subtype 位中，第 7 个bit代表最高效 bit。）

| Duration （持续时间）

RTS帧会试图预定介质使用权，供帧交换程序使用，因此 RTS 帧发送者必须计算 RTS帧结束后还需要多少时间。图 1-3说明了整个交换过程，总共需要三个 SIFS、一个CTS、最后的ACK，加上发送第一个帧或帧片段所需要的时间。（fragmentation burst 〔片段宣泄期〕会使用后续的帧片段来更新 Duration 位。）传输所需要的微秒数经过计算后会置于 Duration 位。假使计算的结果不是整数，就会被修正为下一个整数微秒。

　　　　　　　　　　图1-3：RTS帧的Duration 位

Address 1 位；Receiver Address （接收端地址）

接收大型帧的工作站的地址。

Address -2 位：Transmitter Address （发送端地址）

RTS帧的发送端的地址。

1.1.3 CTS （允许发送）

CTS帧有两种目的，其格式如图 1-4 所示。起初，CTS帧仅用于应答 RTS帧，如果之前没有RTS出现，就不会产生 CTS 。后来，CTS帧被 802.11g 防护机制用来避免干扰较旧的工作站。

　　　　　　　　图1-4：CTS帧

CTS帧的 MAC标头由三个位构成：

| Frame Control( 帧控制)

帧的subtype（次类型）位被设定为 1100，代表 CTS 帧。

| Duration （持续时间）

用来应答 RTS 时，CTS帧的发送端会以 RTS 帧的 duration 值作为持续时间的计算基准。RTS会为整个 RTS-CTS-frame-ACK 交换过程预留介质使用时间。不过当 CTS 帧被发送出后，只剩下其他未帧或帧片段及其回应待传。CTS帧发送端会将 RTS 帧的duration 值减去发送CTS帧及其后短帧间隔所需的时间，然后将计算结果置于 CTS 的Duration 位。图 1-5显示了 CTS duration 与RTS diratopm的关系。

　　　　　　　　　　图1-5二CTS的持续时间

| Address 1 位：Receiver Address （接收端地址）

CTS帧的接收端即为之前 RTS帧的发送端，因此 MAC会将 RTS帧的发送端地址复制到CTS帧的接收端地址。802.11g保护操作所使用的 CTS 帧会被发送给发出 RTS 的工作站，而且只用来设定 NAV。

1.1.4 ACK （应答）

ACK帧（图 1-6 ）就是 MAC以及任何数据传输（包括一般传输 RTS/CTS交换之前的帧、帧片段）所需要的正面应答（positive acknowledgment）。服务质量扩展功能放宽了个别数据帧必须各自得到应答的要求。

　　　　　　　　　　图1-6：ACK帧

ACK帧的 MAC标头由三个位构成：

| Frame Control（帧控制）

帧的subtype（次类型）位被设定为 1101，代表 ACK帧。

| Duration （持续时间）

依照ACK信号在整个帧交换过程中位居何处，duration 的值可以有两种设定方式。在完整的数据帧及一连串帧片段的最后一个片段中，duration 会被设定为 0。数据发送端会将 Frame Control（帧控制）位中的 More Fragments（尚有片段）bit设定为 0，表示数据传输已经结束。

如果More Fragments bit 为0 ，表示整个传输已经完成，没有必要再延长对无线信道的控制权，因此会将 duration 设定为 0 。

如果More Fragments bit为1 ，表示尚有帧片段仍在发送中。此时Duration 位的用法和 CTS帧中的Duration 位相同。发送ACK以及短帧间隔所需要的时间，将由最近帧片段所记载的duration 中减去。如果不是最后一个 ACK帧，duration 的计算方式类似 CTS duration 的计算方式。事实上，802.11的规格书将 ACK帧中的duration 设定称为虚拟 CTS。

| Address 1 位：Receiver Address （接收端地址）

接收端地址是由所要应答的发送端帧复制而来。技术上而言，它是由所要应答帧的Address 2 位复制而来。应答主要是针对数据帧、管理帧以及 PS-Poll帧。

　　　　　　　　　　图1-7：非最终ACK帧的Duration 位

1.1.5 PS-Poll （省电模式一轮询）

当一部移动工作站从省电模式中苏醒，便会发送一个 PS-Poll帧给接入点，以取得任何暂存帧。PS-Poll帧的格式如图 1-8 所示。

　　　　　　　　　　图1-8：PS-Poll帧

PS-Poll帧的 MAC标头由四个位构成：

| Frame Control（帧控制）

帧的subtype（次类型）位被设定为 1010，代表 PS-Poll帧。

| AID（连接识别码）

PS-Poll帧将会以 MAC标头的第三与第四 bit来代表连接识别码（association ID）。连接识别码是接入点所指定的一个数值，用以区别各个连接。将此识别码置入帧，可让接入点找出为其（移动工作站）所暂存的帧。

| Address 1 位：BSSID

此位包含发送端目前所在 BSS 的BSSID ，此BSS 建立自目前所连接的 AP。

| Address 2 位：Transmitter Address （发送端地址）

此为PS-Poll帧之发送端的 MAC地址

在PS-Poll帧中并未包含 duration 信息，因此无法更新 NAV。不过，所有收到 Ps-Poll帧的工作站，都会以短帧间隔加上发送 ACK信号所需要的时间来更新 NAV。此一自动调整机制使得接入点在发送 ACK信号时，比较不会与移动接入点发生碰撞。

【连接识别码（AID）在PS-Poll帧中，Duration/ID位是连接识别码，而非虚拟载波侦测功能所使用的数值。当移动工作站与接入点连接时，接入点会从1-2,007范围内指派一个值来做为连接识别码（AID）。】

1.2 数据帧

数据帧会将上层协议的数据置于帧主体加以传递。图 1-9 显示了数据帧的基本结构。会用到哪些位，取决于该数据帧所属的类型。

图1-9 基本的数据帧

不同类型的数据帧可根据功能加以分类。其中一种方式，是将数据帧区分为竞争式服务及免竞争服务两种数据帧。只能在免竞争期间出现的帧，就不可能在IBSS（独立型基本服务组合）中使用。另一种区分方式，则是对携带数据与提供管理功能的帧加以区别。表1-1 显示了数据帧的分类方式。

表 4-1：数据帧的各种分类方式

1.2.1 Frame Control （帧控制）

Frame Control（帧控制）位各个 bit都可能影响到MAC标头其他位的解读方式。最值得注意的是那些地址位，它们的意义将因ToDS 及FromDSbit 的值而异。

1.2.2 Duration（持续时间）

Duration （持续时间）位用来记载网络分配矢量（NAV）的值。访问介质的时间限制是由NAV所指定。数据帧之 Duration 位的设定，必须依循四项规范：

1. 免竞争期间所传递的任何帧，必须将Duration 位设定为32768 。此规范适用于免竞争期间所传递的任何数据帧。

2. 目的地为广播或组播地址的帧（Address 1 位设定了群组 bit），其持续时间为 0。此类帧并非基本交换过程的一部分，接收端也不会加以应答，因此竞争式介质访问可以在广播或组播数据帧结束后立即开始。NAV在帧交换过程中是用来保护传输介质。既然广播或组播帧之后不会有来自链路层的应答，因此没有必要为后续帧锁住介质使用权。

3. 如果Frame Control位中的More Fragments bit 为0，表示该帧已无其余片段。最后的帧片段只须为本身的应答预订介质使用权，之后就可以恢复竞争式访问了。Duration位会被设定为发送一个短帧间隔及片段应答所需要的时间。整个过程如图 1-10 所示。倒数第二个片段的Duration 位，会为最后一个片段锁住介质使用权。

图1-10：最终片段的Duration 设定

4. 如果Frame Control位的More Fragmentsbit被设定为 1，表示其后还有帧片段。因此， Duration 位便会被设定为发送两个应答、加上三个短帧间隔及下一个帧片段所需要的时间。为非最终片段设定NAN 的方式本质上与 RTS 相同，所以亦称为虚拟RTS 。

图1-11：非最终片段的Duration 设定

1.2.3 地址与DS Bit

地址位的编号与功能取决于设定了哪个 DS（分布式系统）bit，因此所使用的网络类型会间接影响到地址位的用法。表 1-2 列出了地址位在数据帧中的各种用法。只有无线桥接器才会使用第四个地址位，因此比较少见。

表 1-2：地址位在数据帧中的用法

Address 1 代表帧接收端的地址。在某些情况下，接收端即为目的地，但不总是这样。目的地是指负责处理帧中网络层封包的工作站；而接收端则是负责将无线电解码为 802.11帧的工作站。如果Address 1 被设为广播或组播地址，则必须同时检查 BSSID （基本服务组合识别码）。工作站只会应答来自同一个基本服务集（basic service set，简称 BSS ）的广播或组播信息；至于来自其他不同 BSS 者则加以忽略。Address 2 是发送端的地址，用来发送应答信息。发送端就是源地址。源地址是指产生帧中网络层协议封包的工作站；而发送端则是负责将帧发送至无线链路。Address 3 位则是供接入点与分布式系统过滤之用，不过该位的用法，取决于所使用的网络类型。

由于IBSS 并未使用接入点，因此不会涉及分布式系统。发送端即为帧的源，而接收端即为帧的目的地。每个帧都会记载 BSSID ，因此工作站可以检查广播与组播信息。只有隶属同一个 BSS的工作站，才会处理该广播或组播信息。在 IBSS 中，BSSID 是由随机数产生器随机产生的。

BSSID

每个BSS都会被赋予一个BSSID，它是一个长度为48个bit的二进制识别码，用来辨识不同的BSS。BSSID的主要优点是，它可作为过滤之用。虽然不同的802.11网络彼此间可能重叠，但即使如此也不应该让相互重叠的网络收到彼此的链路层广播。

在 infrastructure BSS（基础架构型基本服务集）中，BSSID 就是建立该 BSS 的接入点上无线接口的MAC地址。而IBSS（独立型基本服务组合）则必须建立BSSID。方能产生网络。

为了让所建立的地址尽量不致重复，BSSID有46个bit是随机产生的。其所产生的BSSID，会将Universal/Local bit设定为1，代表这是一个区域地址，至于vidual/Group bit则会设定为0。两个不同的IBSS，如果要产生相同的BSSID，它们所产生的46bit数必须完全相同。

有一个BSSID会被保留不用，就是所有bit均设定为1的BSSID，又称为广播型BSSID。使用广播型BSSID的帧，可以不被MAC中任何的BSSID filter所过滤。BSSID的广播只有在移动式工作站送出probe request（检测要求），试图找出有哪些网络可以加入时才会用到。probe帧要能够检测现存的网络，就不能被 BSSID filter过滤掉probe帧是惟一允许使用广播型BSSID的帧。

802.11对源与发送端以及目的地与接收端有明确的区分。将帧送至无线介质的发送端，不见得就是帧的产生者。目的地址与接收端地址同样有此区别。接收端可能只是中介目的地，而帧只有到达目的地，才会由较上层的协议加以处理。

图1-12 展示了一个简单的网络，其中有某个无线用户端通过 802.11网络连接至服务器。用户端将帧发送给服务器时，地址位的用法如表 1-2 第二列所示。

图1-12：将帧发送至服务器时，地址位的用法

如果帧的目的地位于分布式系统，则用户端既是源亦是发送端。至于无线帧的接收端则是接入点，不过该接入点只是个中介目的地。当帧送到接入点时，该帧会经分布式系统转送给服务器。因此，接入点是接收端，而服务器才是最后的目的地。在基础架构型网络里，接入点会以其无线接口的地址建立相应的BSS ，这就是为什么接收端地址（Address 1）会被设定为 BSSID 的原因。

当服务器应答用户端时，帧会通过接入点发送给用户端，如图 1-13 所示。这种情况相当于表1-2 的第三列。

图1-13：帧来自分布式系统时，地址位的用法

由于帧产生自服务器，所以服务器的 MAC地址即为该帧的来源地址（简称 SA）。当帧通过接入点转送出去时，接入点将会以自己的无线接口做为发送端地址（简称TA）。如同前一个例子，接入点的接口地址就是 BSSID 。帧最后会被送至用户端，此时用户端既是目的地又是接收端。

表1-2 的第四列展示了地址位在无线分布式系统（wireless distribution system 简称 WDS）中的用法。无线分布式系统有时也称为无线桥接器。如图1-14 所示，两条有线网络通过扮演无线桥接器角色的接入点彼此相连。从用户端送至服务器的帧会经过 802.11 WDS 。该无线帧的源与目的地址，依然对应到用户端与服务器的地址。不过，这些帧还是会区分无线接口上帧的发送端与接收端。对于由用户端送至服务器的帧而言，发送端就是用户端这边的接入点，而接收端就是服务器这边的接入点。将来源地与发送端分开的好处是，当服务器这边的接入点送出必要的 802.11应答给对方接入点时，不会干扰到有线链路层。

图1-14：无线分布式系统

1.2.4 数据帧的次类型

802.11具有数种不同类型的数据帧。要使用何种帧，取决于服务是属于竞争式或免竞争式服务。基于效率上的考虑，免竞争帧中可以加入其他功能。只要改变帧的次类型，免竞争期间的数据帧即可用来应答其他帧，由此便可省去帧间隔以及一一应答所带来的负担。以下是常见的数据帧次类型：

| Data（数据）

子类型为 Data的帧，只有在竞争访问期间才会传输。这类简单的帧只有一个目的，亦即在工作站间发送帧主体。

| Null （空）

Null 帧看起来有点奇怪。它是由 MAC标头与 FCS 标尾所组成。在传统的以太网中，Null帧无非就是额外的负担；在 802.11网络中，移动工作站会利用 Null 帧来通知接入点省电状态的改变。当工作站进入休眠状态，接入点必须开始为之暂存帧。如果该移动式工作站没有数据要通过分布式系统传输，也可以使用 Null 帧，同时将 Frame Control（帧控制）位的 Power Management（电源管理）bit设定为1。接入点不可能进入省电模式，因此不会发送 Null 帧。Null 帧的用法，如图1-15 所示。此外尚有一些在免竞争期间使用的帧类型。不过，免竞争服务在实际上并不常见。

图1-15：次类型为Null 的数据帧

1.2.5 数据帧的封装

数据帧的形式取决于网络的形式。帧究竟属于哪种类型，完全取决于subtype（子类型）位，而与其他位是否出现在帧中无关。

1.2.5.1 IBSS帧

在IBSS 中，所使用的 address 位有三种，如图 1-16 所示。第一个地址代表接收端，同时也是IBSS 网络中的目的地址。第二个地址是源地址。在这些地址之后，伴随而来的是 IBSS 的BSSID 。当无线 MAC收到一个帧时，首先会去检查 BSSID ，只有BSSID 与工作站相同的帧，才会交由上层协议加以处理。

图1-16：IBSS 数据帧

IBSS 数据帧的子类型不是 data 就是 Null ；后者只是用来告知目前的电源管理状态。

1.2.5.2 发送自接入点（From AP ）的帧

图1-17 显示了由接入点发送给移动工作站的帧格式。和所有数据帧一样，第一个位代表无线网络中接收该帧的接收端，亦即该帧的目的地。第二个位存放了发送端的地址。在基础网络中，发送端地址即为接入点（AP）上无线接口的地址，同时也是BSSID 。最后，该帧会记载帧的源MAC地址。区分源与发送端之所以必要，是因为 802.11 MAC 会将应答送给帧的 Transmitter(发送端AP)，而较上层的协议会将应答送给帧的 source （来源地）。

图1-17：发送自接入点的数据帧

在802.11的规格书中并未明文禁止接入点发送 Null 帧，不过这么做并没有任何意义。因为接入点禁止使用省电程序，所以接入点只会应答来自工作站的 Null 帧，而不会在应答中使用 Null 帧。

实际上，在竞争式访问期间，接入点会使用 Data帧，而在免竞争期间则是使用包含 CF-Poll功能的帧。

1.2.5.3 发送至接入点（To AP ）的帧

图1-18 显示了，在 infrastructure （基础架构型）网络里，移动工作站发送给所连接接入点的帧格式。接收端地址（RA）为 BSSID 。在基础网络里，BSSID 即为接入点的 MAC地址。送至接入点的帧，其源／发送端地址（SA/TA ）得自无线工作站的网络接口。接入点并未进行地址过滤的动作，而是使用第三个地址(DA ），将数据转送至位于分布式系统的适当位置。

图1-18：发送至接入点的数据帧

发送至分布式系统（Ds）的帧其 ToDS bit 会被设定为 1，而 FromDS bit会被设定为 0 。在基础网络中，移动工作站不能扮演中枢协调者（point coordinato）的角色，因此不能发送含有CF-Poll（免竞争一轮询）功能的帧。

1.2.5.4 WDS 中的帧

当接入点被部署成无线桥接器（或者 VUDS ）时，就会用到四个地址位，如图 1-19 所示。和其他数据帧一样，WDS帧会使用第一个地址（RA）代表 receiver （接收端），第二个地址（TA）代表Transmitter（发送端）MAC层会使用这两个地址送出应答以及控制流量，例如 RTS 、CTS以及ACK帧。另外两个地址位（SA与DA）则是用来记载帧的 source（源）以及 destination（目的）地址，并且将之与无线链路所使用的地址区别开来。

图1-19：WDS帧

在无线桥接链路中，通常不会存在移动工作站，也不会使用免竞争期间。接入点禁止进入省电模式，因此 power management （电源管理）bit必然设定为 0 。

1.2.5.5 经加密的帧

受到链路层安全协议保护的帧并不算新的帧类型。当帧经过加密处理，Frames Control （帧控制）位的 Protected Frame bit会被设定为 1 ，至于帧主体，则是以加密标头起头，这取决于所使用的何种协议。

1.3 管理帧

在802.11规格书中，管理所占据的篇幅最多。各式各样的管理帧，为的只是提供对有线网络而言相当简单的服务。对有线网络而言，识别一部工作站并非难事，毕竟控制中心与工作站之间必须通过布线方能建立连接。有时候，集线器的插座面板可加速网络的构建，不过重点还是在于：建立新的连接时，可通过人员进行身份认证。

无线网络必须建立一些管理机制，方能提供类似的功能。802.11将整个过程分解为三个步骤。寻求连接的移动工作站，首先必须找出可供访问的无线网络。在有线网络中，这个步骤相当于在墙上找出适当的网孔。其次，网络系统必须对移动工作站进行身份认证，才能决定是否让工作站与网络系统关联。在有线网络方面，身份认证是由网络系统本身提供。如果必须通过网线才能够取得信号，那么能够使用网线至少算得上是一种认证过程。最后，移动工作站必须与接入点建立关联，这样才能访问有线网络，这相当于将网线插到有线网络系统。

1.3.1 管理帧的结构

802.11管理帧的基本结构如图 1-20 所示。所有管理帧的 MAC标头都一样，这与帧的子类型无关。管理帧会使用信息元素（带有数字标签的数据区块）来与其他系统交换数据。

　　　　　　　　　　图1-20：管理帧的基本结构

1.3.1.1 地址位

和其他帧一样，第一个地址位是给帧的目的地址使用的。有些管理帧主要用来维护个别 BSS特有的属性。为了限制广播或组播管理帧所造成的副作用，收到管理帧之后，工作站必须加以验证，虽然不是所有实现均会进行这一 BSSID 过滤程序。只有在广播或组播帧来自工作站目前所连接的BSSID ，才会被送至 MAC管理层。惟一的例外是 Beacon帧，毕竟它是用来宣布 802.11网络的存在。BSSID 是以大家所熟悉的方式来指定的。接入点会以本身无线网络接口的MAC地址作为BSSID 。移动工作站会采纳目前所连接的接入点的 BSSID 。位于 IBSS 的工作站则会使用 BSS建立之初随机产生的 BSSID 。惟一的例外是：寻找特定网络的工作站，可以在所发出的帧中指定该特定网络的 BSSID ，或者使用广播型 BSSID 来寻找邻近所有的网络。

1.3.1.2 计算持续时间

管理帧使用 Duration （持续时间）位的方式和其他帧没有两样：

1. 免竞争期间所发送的任何帧，均会将持续时间设为32,768。

2. 竞争式访问期间，利用DCF 所发送的帧会通过 Duration位防止别人访问介质。确保基本帧交换程序得以完成。

a.如果是广播或组播帧（目的地地址为群组地址），则持续时间会设定为 0。广播与组播帧无须得到应答，因此 NAV 无须防止别人访问介质。

b.如果不是最终片段，则持续时间会设为三个 SIFS期间加上下一个片段及其应答所需要的微秒数。

c.最终帧片段的持续时间会设定为一个应答加上一个 SIFS 所需要的时间。

1.3.1.3 帧主体

管理帧十分具有弹性。帧主体中大部份的数据，如果使用长度固定的位，就称为固定式位；如果位长度不定，就称为信息元素（information element ）。所谓信息元素，是指长度不定的数据区块。每个数据区块均会标注上类型编号与大小，各种信息元素的数据位都有特定的解释方式。新版的802.11规格书允许定义新的信息元素；根据旧版规格书所实现的产品可忽略这些新元素。实际上，硬件一般采取回溯相容（backward-compatible）原则，因此较旧的产品通常无法加入根据新标准所建立的网络。还好，新功能通常可以予以停用，以便兼容性。

除了探讨这些作为基本元件的固定式与信息元素，本节还会说明这些基本元件如何构成管理帧。802.11强制规定了这些信息元素的排列次序，不过并非所有元素均属于要。本书将以特定的顺序说明这些基本元件，论及各个次类型时，也会特别标明哪些元素比较少见，哪些元素彼此互不相容。

1.3.2 长度固定的管理帧元件

在管理帧中，可能出现的长度固定位有十种。长度固定的位一般简称为位，以便与长度不定的信息元素有所区别。位本身并无标头可与帧主体其他部份区别。因为长度与次序固定，因此不需要以位标头作为界定。

Authentication Algorithm Number位

Authentication Algorithm Number （身份认证算法编号）位占用了两个字节，如图 1-21 所示。此位代表连接发生之前 802.11层次（802.11-level）的最初认证程序所使用的认证类型。此位值的允许范围列于表 1-3。目前只定义了两种值。其他值保留给未来版本使用。

　　　　　　图1-21 ：Authentication Algorithm Number（身份认证演算法编号）位

表1-3：Authentication Algorithm Number（身份认证算法编号）位的允许值

Authentication Transaction Sequence Number 位

身份认证过程分为好几个步骤，其中包含由接入点所发出的质询口令（challenge），以及试图关联的移动工作站所做出的应答。如图 1-22 所示Authentication Transaction Sequence Number（身份认证交易顺序编号）位是由两个字节所构成，用以追踪身份认证的进度。此位值介于1 到65,535直接，其值不可为 0 。

图1-22：Authentication Transaction Sequence Number（身份认证交易顺序编号）位

Beacon interval位

每隔一段时间就会发出的Beacon（信标）信号，用来宣布 802.11网络的存在。Beacon帧中除了包含BSS 参数的信息，也包含接入点暂存帧的信息，因此移动工作站必须仔细聆听Beacons 信号。Beacon interval （信标间隔）位的长度有 16个bit，用来设定 Beacon信号之间相隔多少时间单位。时间单位通常缩写为 TU，代表 1,024 微秒（microseconds），相当于一毫秒。有些文件中会以千一微秒（kilo-microseconds ）［注］来表示时间单位。Beacon interval位通常会被设定为 100 个时间单位，相当于每 100 毫秒或0.1 秒发送一次 Beacon信号。

［注］千一微秒（kilo-microseconds）是相当奇怪的组合，因为它以2的乘方来计算Kilo，而以较为常见的1/1000来表示micro。

　　　　　　图1-23：Beacon Interval （信标间隔）寺阑位

Capability information 位

图1-24 所示为长度 16个bit的Capability Information 性能信息位，发送Beacon信号的时候，它被用来通知各方，该网络具备哪种性能。Capability information 位也可以使用在 Probe Request 与Probe Response 帧。在本位中，每个 bit各自代表一个旗标，对应到网络所具备的某种特殊功能。工作站会使用这些公告数据来判断自己是否支持该 BSS 所有的功能。没有实现性能公告中所有功能的工作站，就无法加入该 BSS 。

　　　　　　　　图1-24：Capability Information（性能信息）位

l ESS/IBSS（扩展服务集/独立型塞本服务集）

这两个bit旗标彼此互斥（mutually exclusive）。接入点会将 ESS 位设定为 1，而将 IBSS 布位设定为 0，表示接入点属于基础网络的一部分。IBSS 中的工作站则会将 ESS 位设定为 0 ，而将IBSS 位设定为 1 。

| Privacy（私密性）

将Privacy bit 设定认1 ，代表需要使用 WEP以维持机密性。在基础网络中，发送端为接入点。在IBSS 里，Beacon信号必须由 IBSS 当中某部工作站负责。

| short Preamble （短同步信号）

802.11b 规格新增此位的目的，是为了支持高速直接序列扩频物理层( high-rate DSSS PHY）。将之设定为 1 ，代表此网络目前使用短同步信号（short preamble ）。0 代表不使用此选项，并且在该 BSS 中禁止使用短同步信号。802.11g 规定使用短同步信号，因此在依循 802.11g 标准所建置的网络中，此位必然设定为 1 。

| PBCC （分组二进制卷积编码）

802.11b 规格新增此位的目的，是为了支持高速直接序列扩频物理层(high-rate DSSS PHY）。将之设定为1 ，代表此网络目前使用的分组二进制卷积编码（packet binary convolution coding)调变机制，或是802.11g PBCC 调变机制。0 代表不使用此选项，并且在该 BSS 中禁止使用分组二进制卷积编码。

| Channel Agility（机动信道转换）

这一位加入802.11b 规格的目的，是为了支持高速直接序列扩频物理层(high-rate DSSS PHY）。将之设定为 1 ，代表此网络使用机动信道转换（Channel Agility）选项。0 代表不使用此选项，并且在该 BSS 中禁止使用机动信道转换。

| Short Slot Time （802.llg ）

此bit若设定为 1 ，代表使用 802.11所支持的较短的时槽。

| DSSS-OFDM （802.lIg ）

此bit若设定为 1 ，代表使用 802.11g 的DSSS-OFDM 帧构建（frame construction）选项。

| Contention-free polling（免竞争轮询）bit

工作站与接入点使用这两个 bit(CF-Ppllable 与CF-Poll Request) 当作标签。这些标签的意义如表1 一4 所示。

表1-4：Capability Information（性能信息）位中 polling bit所代表的意义

Current AP Address 位

移动工作站可以使用图 1-25 所示的 Current AP Address （目前接入点的地址）位来表明目前所连接的接入点的 MAC地址。这个位的用途是便于连接（association ）与重新连接（reassociation ）的进行。工作站会借此发送上一次所连接的接入点的地址。当工作站打算与不同的接入点建立连接时，此位可用来转换连接，以及取回所有暂存的帧。

　　　　　　图1-25：Current AP Address （目前接入点的地址）位

Listen interval 位

为了节省电池的电力，工作站可以暂时关闭 802.11网络接口的天线。当工作站处于休眠状态，接入点必须为之暂存帧。休眠中的工作站会定期醒来聆听往来信息，以判断是否有帧暂存于基站。当工作站与接入点连接时，会将 Listen Interval（聆听间隔）记录下来。所谓 Listen Interval，其实就是以 Beacon interval（信标间隔）为单位所计算出的休眠时间。图 1-26 所示的Listen Interval ，让移动工作站得以要求接入点必须为它暂存帧多久的时间。聆听间隔越久，接入点就必须使用更多记忆体来暂存帧。接入点可以藉此项功能估计所需资源，以决定是否拒绝资源密集（resource-intensive）的连接。第八章会进一步描述 Listen Interval。

　　　　　　　　图1-26 ：Listen Interval（聆听间隔）位

Association ID 位

图1-27 所示为长度 16bit的Association ID（连接识别码）位。当工作站与接入点连接时，就会被赋予一个连接识别码，用以协助控制与管理功能。虽然连接识别码可用 bit数为 14个bit，不过只有1-2007可以使用。为了与 MAC标头的Duration/ID位相容，最高效的两个 bit均被设定为1。

　　　　　　　　图1-27：Association ID（连接识别码）位

Timestamp位

图1-28 所显示的 Timestamp （时戳）位，可用来同步 BSS 中的工作站 BSS 的主计时器会定期发送目前已作用的微秒数。当计数器到达最大值时，便会从头开始计数。（对一个长度 64bit、可计数超过 580,000 年的计数器而言，很难会遇到有从头开始计数的一天。）

　　　　　　　　图1-28：Timestamp （时戳）位

Reason Code位

当对方不适合加入网络时，工作站会送出 Disassociation（解除关联）或 Deauthentication（解除身份认证）帧作为应答。这些帧当中包含一个长度 16bit的Reason Code（原因代码）位，表示对方的做法有误，如图 1-29 所示。表 1-5 列出了产生原因代码的理由。要完全了解原因代码的用法，必须对各种帧以及 802.11工作站的状态有所了解。

　　　　　　图1-29：Reason Code（原因代码）位

Status Code 位

状态代码用来表示某项过程成功或失败。Status Code （状态代码）位，如图 1-30 所示。如果某项过程成功，该位的值就会被设定为0 ，否则设为非零值。表1-6 列出了标准的状态代码。

　　　　　　　　图1-30：Status Code（状态代码）位

表4-6：状态代码

1.3.3 管理帧的信息元素

信息元素（information element ）是管理帧的组成元件，其长度不定。信息元素通常包含一个Element ID（元素识别码）位、一个 Length（长度）位以及一个长度不定的位，如图 1-31所示。Element ID 编号的标准值如表 1-7 所示。

　　　　　　　　　　图1-31：一般管理帧的信息元素

表1-7：信息元素

1.3.3.1 服务集标识（Service Set Identity（SSID））

网络管理人员通常比较喜欢跟文字、数字或名称打交道，而不是48个bit的MAC地址。广义的802.11 网络不是扩展式服务集（extended service set ），就是独立型基本服务集（independent BSS ）。如图1-32 所示的 SSID，让网管人员为服务集(service set) 指定识别码。试图加入网络的工作站可以扫描目前区域所有网络，然后以特定的SSID加入。共同组成扩展式服务区域（extended service area ）的所有基本服务区域（basic service areas ）都会使用相同的SSID。

　　　　　　　　图1-32：SSID（服务组合识别码）信息元素

有些文件将SSID 视为网络名称，因为网管人员通常以字串来指定 SSID。其实，SSID 不过是由字节所形成的字串，用来标示所属网络的 BSSID 。有些产品要求此字串必须是以 null（即0 ）结尾的 ASCII 字串，虽然标准对此并无特别规范。

SSID的长度介于 0 至32字节之间。如果完全不加指定，此种特例称为 broadcast SSID ； broadcast SSID 只用于 Probe Request 帧，工作站可以藉此找出该区域中所有的 802.11网络。

1.3.3.2 支持速率（Supported Rates）

无线局域网络支持数种标准速率。802.11网络可以使用 Supported Rates（所支持的速率）信息元素指定其所支持的速率。当移动工作站试图加入网络，会先检视该网络所使用的数据速率。有些速率是强制性的，每部工作站都必须支持，有些则是选择性的。

图1-33：Supported Rates（所支持的速率）信息元素

Supported Rates 信息元素如图 1-33 所示。它是由一串字节所构成。每个字节会使用七个低效bit来代表数据速率；最高效 bit则是用来表示该数据速率是否为强制性。如果是强制性速率，最高效 bit为1 ；非强制性速率则为 0 。此信息元素最多可涵括八种速率。随着各种数据速率的增加，目前已将 Extended Supported Rates（扩展支持速率）元素标准化，以便处理八种以上的速率。

在802.11规格书最初的版本中，是以这七个 bit对数据速率进行编码，而数据速率为 500 kbps的倍数。新的技术，特别是 ETSI的HIPERLAN ，必须以不同的方式来解读。当这七个 bit用来编码数据速率时，每种编码均为500 kbps 的倍数，那么可编码的最高数据速率为63.5 Mbps。无线网络的进展，使得这个速率在不久的将来即可实现。因此，IEEE 在802.11b 中改用简单的标记来代表所支持的速率。先前已经标准化的速率，则根据 500 kbps倍数予以标记，不过未来的标准可能会有所更动。目前使用的标准值如表1-8 所示。

表1_8 ：数据速率标记

图1-33显示了如何同时编码两种数据速率。除了支持强制性的 2Mbps 服务，也支持选择性的11Mbps 服务。

1.3.3.3 跳频参数组合（PH Parameter Set）

跳频参数组合信息元素如图 1-34 所示，其中包含了加入 802.11跳频（frequency-hopping）网络所需要的参数。在FH Parameter Set中有四个特别针对 802.11跳频式网络的位。

　　　　　　　　图1-34：PH Parameter Set（跳频参数集合）信息元素

Dwell Time （停留时间）

802.11 FH 网络会在信道与信道间跳跃。停留在每个信道上的时间称为 dwell time（停留时间）。停留时间是以时间单位（time units 简称 TUs ）来表示。

Hop Set（跳频组合）

802.11跳频物理层定义了若干跳频模式（hopping patterns）。此位的长度为一个字节，代表所使用的跳频模式组合。

Hop Pattern（调频模式）

工作站从跳频组合中挑出一种跳频模式。此位的长度亦为一个字节，代表所使用的跳频模式。

Hop Index（跳频索引）

每种跳频模式均包含一组跳频顺序。此位的长度为一个字节，代表目前位于跳频顺序的哪一点上。

1.3.3.4 直接序列参数集合（DS Parameter Set）

802.11直接序列（Direct-sequence）网络只有一个参数：网络所使用的信道数。高速直接序列网络使用相同的信道，因此可以使用相同的参数集合。信道数以一个字节进行编码，如图1-35 所示。

　　　　图1-35：DS Parameter Set（直接序列参数集合）信息元素

1.3.3.5 数据待传信息（Traffic Indication Map（TIM ））

接入点会为处于休睡状态的工作站暂存帧。每隔一段时间，接入点就会尝试传递这些暂存帧给休眠中的工作站。如此安排的理由是，启动发送器比启动接收器所耗费的电力还要多。802.11的设计者预见未来将会有以电池供电的移动工作站；定期发送暂存帧给工作站的这个决定，主要是为了延长设备的电池使用时间。将 TIM（数据待传指示信息）信息元素送到网络上，指示有哪些工作站需要接收待传数据，只是此过程的一部分。

　　　　　　图1-36 ：Traffic Indication Map（数据待传指示信息）信息元素

TIM 的内容是虚拟 bit对映（virtual bitmap），这是由 2,008 个bit所组成的逻辑结构。每个bit分别对映到一个连接识别码（Association ID）。当某个识别码有数据暂存时，相应的 bit就会设成 1 ，否则会设成 0。

DTIM Count（DTIM计数）

此位的长度为一个字节，代表下一个 DTIM（数据待传指示传递信息）帧发送前，即将发送的Beacon帧数。DTIM帧用来表示所暂存的广播与组播帧即将被发送。并非所有

Beacon帧均为 DTIM帧。

DTIM Period（DTIM期闲）

此位的长度为一个字节，代表两个 DTIM帧之间的 Beacon interval数。0 值目前保留未用。DTIM会由此期间倒数至 0。

Bitmap Control（bit对映控制）与 Partial Virtual Bitmap（部分虚拟 bit对映）

Bitmap Control （bit对映控制）位可进一步划分为两个次位。Bit 0用来表示连接识别码0 的待传状态，主要是保留给组播使用。其他七个bit则是保留给 Bitmap Offset（bit对映偏移）次位使用。

为了节省频宽，可以通过 Bitmap Offset次位，只发送一部分的虚拟 bit对映。Bitmap Offset 是相对于虚拟 bit对映的开头处。利用 Bitmap Offset次位及 Length位，802.11工作站可以推断虚拟 bit对映有哪些部分包括在内。

1.3.3.6 免竞争参数集合（CF Parameter Set）

CF Parameter Set（免竞争参数组合）

信息元素出现在支持免竞争接入点所发送的 Beacon帧中。免竞争服务并非必要，因此留待第九章讨论。

1.3.3.7 IBSS 参数集合（IBSS Parameter Set ）

IBSS 目前只有一个参数，即 ATIM window （数据待传指示通知信息间隔期间），如图1-37所示。此位只用于 IBSS Beacon 帧，用来表示 IBSS 中ATIM帧之间相隔时间单位数量。

　　　　　　　　图1-37：IBSS 参数集合信息元素

1.3.3.8 国家（Country）

802. 11 规格书原本是针对主要工业化国家现有的管制规定所设计。为了避免每新增一个国家就得重新修订规格，因此在规格书中加入新的规定，让网络能够提供管制规范给新加入的工作站。这一机制的核心，就是 Country 信息元素，如图 1-38 所示。

图1-38 ：Country 信息元素

在type/length 信息元素标头之后的是国家识别码（country identifier），之后是一系列由三个字节所构成的限制描述符（three-byte descriptor ）。每组限制描述均注明特定频段，它们彼此不会重覆，因为每个特定频率只会有一个最大允许功率。

Country String（国家字串，三个字节）

由三个字符所构成的 ASCII 字串，代表工作站的使用国家。前两个字符即 ISO 国码（例如US代表美国）。有些国家对室内与室外有不同的管制规定，第三个字符即是用来区别两者。如果室内外的管制规定相同，第三个字符则为空白。如果只想指定室内或室外管制规定，可以分别将第三个字符设为 I 或O。

First Channel Number （第一信道编号，一个字节）

第一信道编号即是符合功率限制的最低信道。

Number of Channels（信道数，一个字节）

符合功率限制的频段大小，是由信道数来指定。信道大小随 PHY而有所不同。

Maximum Transmit Power（最大传输功率，一个字节）

最大传输功率，以 dBm为单位。

Pad （补零码，一个字节；可有可无）

信息元素所使用的字节必须刚好是偶数。如果信息元素的长度恰为奇数，就必须用一个字节补零。

1.3.3.9 Hopping Pattern Parameters（跳频模式参数）与 Hopping Pattern Table （跳频模式表）

是根据设计当时的管制规定所制定。这两个元素可以用来制定新的跳频模式，以便符合其他国家的管制规定。如此一来，若要采用不同的跳频物理层，就不需要进一步修订规格书了。

1.3.3.10 请求（Request）

在Probe Request 帧中，Request 信息元素（图 1-39 ）用来向网络查询特定的信息元素。Request 信息元素本身具备 type/length 标头，以及一连串所要查询的信息元素编号。

　　　　　　　　图1-39：Request 信息元素

1.3.3.11 质询口令（Challenge Text）

802.11所定义的共享密钥身份认证系统。会要求移动工作站必须成功解码一段加密过的质询口令。这段质询口令的发送系通过 Challenge Text（质询口令）信息元素，如图 1-4o 所示。

　　　　　　　　图1-40：Challenge Text （盘问口令）信息元素

1.3.3.12 功率限制（Power Constraint）

Power Constraint（功率限制）信息元素让网络得以向工作站传达其所允许的最大传输功率。

除了管制上的最大值，另外还有实际使用上的最大值。此信息元素只有一个位，长度为一个字节，其中所记录的整数值，乃是管制上的最大值减去实际使用上的最大值，以 dBm为单位。例如，假设管制上允许的最大功率为 10 dBm，但是此信息元素值为 2 ，那么此工作站就会将本身的最大传输功率设为 8 dBm （图 1-41 ）。

　　　　　　　　图1-41：Power Constraint （功率限制）信息元素

1.3.3.13 功率性能（Power Capability）

802.11 工作站通常以电池供电，在无线电波的性能上无法与接入点相提并论。另外部分原因是，移动工作站通常不需要像接入点那样以高功率进行传输。Power Capability（功率性能）信息元素让工作站得以报告本身最低与最高的传输功率，以 dBm为单位（图 1-42 ）。

　　　　　　　　图1 _42：Power Capability（功率性能）信息元素

1.3.3.14 发射功率控制要求（TPC Request ）

Transmit Power Control（发射功率控制，简称 TPC ）Request 信息元素用来要求无线电波链路管理信息。此信息元素并无其他附属数据，因此长度位必然为 0 (图 1-43) 。

　　　　　　图1-43：TPC Request 信息元素

1.3.3.15 发射功率控制报告（TPC Report）

知道整个链路的衰减情况，可以帮助工作站了解该如何调整传输功率。TPC Report信息元素散见于各种管理帧，由两个长度各为一字节的位所构成（图 1-44 ）。第一个位代表传输功率，亦即包含此信息元素帧的传输功率，以 dBm为单位。第二个位代表链路边际(link margin) ，亦即工作站所提出的安全边际值，同样以 dBm为单位。工作站将会根据这两个值来调整本身的传输功率。

　　　　　　　　　　图1-44：TPC Report信息元素

1.3.3.16 所支持信道（Supported Channels）

Supported Channels（所支持的信道）信息元素与 Country 信息元素类似，用来记载所支持的子频段。在标头之后的是一系列子频段的描述符（sub-band descriptor ）。每组子频段描述符由第一信道编号，亦即所支持子频段中的最低信道，以及子频段的信道数所组成（图 1-45 ）。举例来说，如果装置只支持信道 40至52，那么第一信道编号即为 40，信道数则为 12。

　　　　　　　　图1-45 ：Supported Channels（所支持的信道）信息元素

1.3.3.17 信道切换宣告（Channel Switch Announcement ）

802.11h 为网络加入了动态切换信道的能力。为了警告网络中的工作站即将变换信道，可以在管理帧中加入如图 1-46 所示的Channel Switch Announcement （信道切换宣布）信息元素。

　　　　　　　　图1-46：Channel Switch Announcement （信道切换宣布）信息元素

Channel Switch Mode（信道切换模式）

当信道改变，通讯会突然中断。如果此位设定为 1 ，已连接的工作站就会停止发送帧，直到信道切换完成。如果设定为 0，则帧的发送就不受限制。

New Channel Number （新信道编号〉

切换后的新信道编号。目前，此位的值尚不需要超过 255 。

Channel Switch Count （信道切换计时）

信道切换可以预先排定时程。此位记载再过多少 Beacon帧间隔后进行信道切换。信道切换会在发送 Beacon帧之前进行。非 0 值代表等待多少个 Beacon间隔；0 值代表信道切换可以立刻进行，无须多作警告。

1.3.3.18 Measurement Request （测量要求）与 Measurement Report（测量报告）

信息元素对于信道与功率设定的监控而言，定期进行信道测量十分重要。为了让工作站能够提出测量要求与接收测量报告，因此定义了这两种信息元素。

1.3.3.19 禁声（Quiet）

开发动态选频的理由之一是为了避免与特定的军事雷达技术彼此干扰。要找出是否有雷达或其他干扰源存在，接入点可以使用 Quite信息元素，暂时关闭该信道，以改善测量的质量，如图1-47 所示。

　　　　　　　　　　图1-47 ：Quiet信息元素

在标头之后有四个位：

Quiet Count（禁声计时）

禁声期可以预先排定时程。此位记载再过多少 Beacon间隔后开始进入禁声期。它的运作方式类似 Channel Switch Count 位。

Quiet Period（禁声期）

禁声期也可以预先排定周期。如果此位值为 0 ，代表没有预先排定的禁声期。非 0 值代表每段禁声期间相距多少 Beacon间隔。

Quiet Duration（禁声持续时闲）

禁声期不见得要持续一整个 Beacon间隔时间。此位用来指定禁声期打算持续多少个单位时间。

Quiet Offset（禁声偏移时间）

禁声期不见得始于某个 Beacon间隔。此位用来指定 Beacon间隔开始后经过多少单位时间后开始进入下一个禁声期。这个值必须小于 Beacon间隔时间。

1.3.3.20 IBSS 动态选项（IBSS DFS ）

在基础型网络里，是由接入点负责动态选频。至于独立型网络，则必须指定由谁进行动态选频（dynamic frequency selection，简称 DFS）算法。在 IBSS 中负责动态选频的工作站可以在管理帧中传递 IBSS DFS 信息元素，如图 1-48 所示。

图1-48 ：IBSS Dynamic Frequency Selection (DFS) 信息元素

紧跟在标头之后的是负责管理 DFS信息之工作站的 MAC地址，以及测量间隔。之后就是一系列的信道对映表，用来报告在每个信道监测到什么东西。信道对映表由一个信道编号，以及一个对映字节所构成，其中包含下列位：

BSS （一个bit）

如果在测量期间侦测到来自其他网络的帧，则此 bit会被设定。

OFDM Preamble（一个 bit）

如果侦测到802.11a 的短调整序列(short training sequence ），但其余的帧并未追随其后，则此 bit会被设定。HIPERLAN/2 网络采用的是一样的同步信号，但显然使用不同的帧结构。

unidentified Signal（一个 bit）

当所接收到的信号功率颇高，但无法分辨此信号究竟来自另一个 802.11网络（因此要设定BSS bit）、另外一个 OFDM 网络（因此要设定 OFDM Preamble bit）或是一个雷达信号（因此要设定 Radar bit），则此 bit就会被设定。标准当中并没有明确规范功率必须高到何种程度，才可以设定本 bit。

Radar （一个 bit）

如果在测量期间监测到雷达信号，则此 bit会被设定，必须监测哪些雷达系统，由管制当局定义，而非 802.11任务小组。

Unmeasured（一个bit）

如果未曾测量该信道，则此 bit会被设定。如果未曾测量，当然也就监测不到任任何东西，因此上述四个 bit均会被设定为 0 。

1.3.3.21 扩展物理层（ERP）

802.11g 定义了扩展速率物理层（extended rate PHY，简称ERP）。为了兼容早期产品，另外定义了ERP信息元素，如图 4-49 所示。在最初的定义里，它相当于一个字节中的三个 bit旗标。

Non-ERP present （无 ERP信息）

当比较老旧、非802.11g 的工作站与网络连接，就会设定此 bit。如果监测到相邻网络无法使用 802.11g ，也会设定此 bit。

Use Protection（使用防护机制）

当网络中出现无法以802.11g 数据速率运作的工作站，此防护 bit就会被设定为1 。如此一来就可以兼容比较老旧的工作站。

Barker Preamble Mode（Barker 同步信号模式）

如果连接到网络的工作站没有能力使用第十二章所描述的短同步信号模式，则此 bit就会被设定。

　　　　　　　　图1-49：ERP信息元素

1.3.3.22 强健安全网络（Robust Security Network （RSN））

既然802.111 大幅改善了安全性，因此有必要开发一种方式，让工作站之间得以彼此交换安全性信息。用来达成此一目标的主要工具即是 Robust Security Network（强健安全网络，简称RSN）信息元素，如图 4-50 所示。其中包含几种可能变动的成份，在某些情况下，就算不计标头，RSN信息元素也有可能超出信息元素 255 个字节的限制。

Version（版本）

Version 属于必要位。802.111 定义了版本 1 。0 则保留未用，版本 2 以上则尚未定义。

Group cipher suite（群组密码锁集合）

紧跟版本编号之后的是 group cipher suite（群组密码锁节后）描述符。接入点必须从中选择一种相容于所有已连接工作站的群组密码锁，以便保护广播与组播帧。同时间只允许选择一种群组密码锁。

　　　　　　　　　　图1-50 ：Robust Security Network (RSN)信息元素

密码锁集合选项(cipher suite selector) 的长度为四个字节，由厂商的 OUl 以及代表密码锁的编号所组成。标准化的密码锁集合如表 1-9 所示。（未出现在该表的值，代表保留未用。）802.11i所使用的 OUI 为00-OF-AC，为 802.11工作小组所拥有。

表1-9：密码锁集合

Pairwgse Cipher Suites (count＋list) 〔成对密码锁集合（计数＋列表）〕

除了群组密码锁集合，必然要有一些用来保护单点传播帧的成对密码锁集合。它是由两个字节的计数，以及一系列其所支持的密码锁描述符所组成。密码锁集合选项(cipher suite selector ）可以设定为 0 ，代表只支持群组密码锁集合。除了信息元素的大小之外，支持多少成对密码锁并无限制。

Authentication and Key Management (AKM) suites (count ＋list) 〔身份认证与密钥管理集合（计数＋列表）〕

和成对密码锁集合选项(pairwise cipher suite selector) 一样，目前也存在好几种身份认证类型。它是由计数，以及一系列四个字节的识别码所构成。和密码锁集合一样，由四个字节所构成的识别码，包含了一个 OUl 以及一组类型编号。标准的身份认证类型，

如表4-10 所示。

表4-10 ：份认证与密钥管理组合

RSN Capabilities（RSN性能）

此位的长度为两个字节，由四个旗标构成，用来描述发送端的能力，其后的 bit保留未用，必须设定为 0。

Pre-authentication（事先身份认证）

接入点可以设定此bit，代表它可以和网络中其他接入点进行事先身份认证，以便安全地转移连接事宜。否则，此 bit会被设定为 0 。

No Pairwise（无成对密钥）

如果工作站除了较牢靠的单点传播密钥（unicast key ），也支持手动设定的 WEP密钥，以做为广播数据之用，则此 bit就会被设定。虽然工作站支持但除非绝对必要，否则不会使用这种配置设定。

Pairwise Replay Counter （成对重演计数器）与 Group Replay Counter （群组重演计数器）

在逐渐浮出台面的服务质量扩展功能中，每个优先程度可以拥有好几个不同的重演计数器。这些bit用来描述工作站所支持的重演计数器数量。

PMK list（count＋list) 〔PMK列表（计数＋列表）〕

如果接入点快取成对主钥（pairwise master key ），就可以在接入点间进行快速换手。工作站可以在进行连接时提供接入点一串主钥，如此就可以免除费时的身份认证程序。

1.3.3.23 扩展支持速率（Extended Supported Rate）

Extended Supported Rates 信息元素的作用和图 1-33 的Supported Rates 元素没有两样，不过它允许信息元素的内容超过 25多个字节。

1.3.3.24 Wi-Fi Protected Access （Wi-Fi访问保护，简称 WPAI）

Wi-Fi访问保护从 802.11i 中抽出部分功能并稍做修改，目的是为了尽快将 TKIP推到市场上。它相当于图 1-50 的Robust Security Network 信息元素，不过做了以下变动：

• 元素识别码（element ID）为 221，而非 48。

• WPA 特有的 00:50:F2:01 标记被安插于版本位之前。

• 使用微软（00:50:F2）而非 802.11 工作小组的 OUI。

• 此信息元素只支持一种密码锁集合〈cipher suite〉以及一种身份认证组合

（authentication suite）。不过，有些 WAP 实作并未遵照此项限制。

• 使用 TKIP（而非 CCMP）做为预设的密码锁。

• WPA 不支持事先身份认证，因此 preauthentication capabilities bit 必然设定为0。

1.3.4 管理帧的类型

管理帧的主体所包含的固定位与信息元素是用来运送信息。管理帧有好几种分别负责链路层各种维护功能。

1.3.4.1 Beacon （信标）帧

Beacon帧是相当重要的维护机制，主要用来宣告某个网络的存在。定期发送的信标，可让移动工作站得知该网络的存在，从而调整加入该网络所必要的参数。在基础型网络里，接入点必须负责发送 Beacon帧。Beacon帧所及范围即为基本服务区域。在基础型网络里，所有沟通都必须通过接入点，因此工作站不能距离太远，占则便无法接收到信标。

图1-51依序显示了 Beacon帧所使用的各个位。信标并不全然会用到所有位。选择性位只有在用到时才一会出现。只有在使用跳频(frequency hopping ，简州FH）或直接序列（direct-sequence，简称DS）物理层技术时，才会用到 FH与DS参数组合。任何时候只能使用一种物理层，因此 FH与DS参数组合是彼此互斥的。

CF参数组合只用于支持 PCF 的接入点所产生的帧中，至于是否支持 PCF并非强制 PCF的TIM 只用于接入点所产生的 Beacon帧中，因为只有接入点才会暂存帧。如果有特定国家的跳频扩展元素，则必然随附在 Country 信息元素之后。不过，跳频网络至今已不常见，同样地，若是出现 IBSS DFS 元素，则其必然位于 Quiet与TPC Report元素之间。

　　　　　　　　图1-51：Beacon（信标）帧

1.3.4.2 探测请求（Probe Request）

移动工作站将会利用 Probe Request （探测请求）帧，扫描所在区域内目前有哪些 802.11网络。Probe Request 帧的格式如图 1-52 所示。所有位均为必要。

　　　　　　　　图1-52：Probe Request （探测请求）帧

Probe Request 帧包含两个位：SSID以及 Supported Rates（移动工作站所支持的速率）。收到Probe Request 帧的工作站会据此判定对方能否加入网络。为了相处愉快，移动工作站必须支持网络所要求的所有数据速率，并以 SSID表明所欲加入的网络。SSID可设定为特定网络的SSID，或设定为任何相容网络的 SSID。允许网卡加入任何网络的驱动程式，将会在 Probe Requests中使用 broadcast SSID （广播形式的服务集合识别码）。

1.3.4.3 探测响应（Probe Response）

如果Probe Request 帧所探测的网络与之相容，该网络就会以 Probe Response 帧应答。送出最后一个 Beacon帧的工作站，必须负责应答所收到的探测信息。在基础架构型网络里，负责应答的工作站即为接入点。在 IBSS 当中，工作站会彼此轮流发送 Beacon信号。发送 Beacon信号的工作站必须负责发送 Probe Response帧，直到下一个 Beacon被发送出来。Probe Response帧的格式如图 1-53 所示。其中某些位彼此互斥；此规则同样适用于 Probe Response以及 Beacon帧。

　　　　　　　　图1-53：Probe Response（探测响应）帧

Probe Response帧中包含了 Beacon帧的所有参数，移动工作站可据以调整切入网络所需要的参数。Probe Response帧可以剔除 TIM 元素，因为此时工作站尚未建立连接，因此不必知道哪些连接在接入点中有暂存帧。

1.3.4.4 IBSS 的数据待传指示通知信息（AT I M ）帧

HISS 中没有接入点，因此无法仰赖接入点暂存帧。IBSS 中的工作站如果为处于休眠状态的接收者暂存帧，就会在递送期间送出一个 ATIM帧，通知对方有信息待阵，如图 1-54 所示。

　　　　　　　　　　图1-54：ATIM帧

1.3.4.5 解除关联和解除认证（Disassociation与Deauthentication）

Disassociation（解除关联）帧用来终结一段关联关系，而 Deauthentication（解除认证）帧则用来终结一段认证关系。两者均包含一固定位，Reason Code（原因代码），如图 1-55 所示。当然，Frame Control位彼此不同，因为不同类型的管理帧拥有不同的次类型。802.11改版并不需要改变这一格式，但几次修订均加入了新的原因代码。

　　　　　　图1-55：Disassociation（解除关联）与Deauthentication（解除认证）帧

1.3.4.6 关联请求（Association Request）

一旦移动工作站找到相容网络并且通过身份认证，便会发送 Association Request（关联请求）帧，试图加入网络。Association Request帧的格式如图 1 一56所示。

　　　　　　　　图1-56：Association Request（关联请求）帧

Capability Information（性能信息）位用来指出移动工作站所欲加入的网络类型。在接受连接要求之前，接入点会验证 Capability Information 、SSID 以及（Extended）Supported Rated等位是否符合网络参数。此外，接入点也会记录工作站所使用的 Listen Interval（聆听间隔；即移动工作站每隔多久聆听一次 Beacon帧，以监视 TIM 信息）。支持频谱管理的工作站具备power（功率）与 channel（信道）性能信息元素，支持安全防护的工作站则具备 RSN信息元素。

1.3.4.7 重新关联请求（Reassociation Request）

位于相同扩展服务区域，但在不同基本服务区域之间游走的移动工作站，若要再次使用分布式系统，必须与网络重新关联。如果工作站暂时离开接入点所涵盖的范围，之后要重新加入的时候，也必须重新关联。如图 1-57 所示。

　　　　　　　　图1-57 ：Reassociation Request（重新关联请求）帧

association Request （关联请求）与 Reassociation Request（重新关联请求）之间的差别在于，后者包含移动工作站目前所关联之接入点的地址。拥有这项信息可让新旧接入点彼此联系，以及交接关联数据。交接项目包括先前关联之接入点所暂存的帧。

1.3.4.8 关联响应与重新关联响应（Association Response 与Reassociation Response）

当移动工作站试图关联接入点时，接入点会回覆一个 Association Response（关联响应）或Reassociation Response（重新关联响应）帧，如图小 58所示。两者之间的差别，在于 Frame Control位所记载的 subtype 位。所有位均属必要。在应答的过程中，接入点会指定一个 Association ID （关联识别码），至于指定的方式则因实作而异。

　　　　　　　　　　图1-58：(Re)Association Response （〔重新〕关联响应）帧

1.3.4.9 认证（Authentication）

802.11网络发展初期，工作站是使用共享密钥以及图4-59 所示的 Authentication帧进行身份认证。到了 802.11i，共享密钥身份认证虽然仍保留在标准当中，但却无法与新的安全机制相容。如果工作站使用共享密钥身份认证，将不允许使用较为牢靠的安全性协议。

　　　　　　　　　　图1-59：Authentication（身份认证）帧

不同的身份认证算法可以同时存在。Authentication Algorithm Number（身份认证演算法编号）位用于选择演算法。整个认证程序可能包含好几个步骤（与所使用的算法有关），因此认证的过程中每个帧都有其序号。Status Code 与Challenge Text 的用法因算法而异。

1.3.4.10 Action

802.11h 加入了 Action 帧的支持，用来触发测量动作。

1.4 帧发送以及连接与身份认证状态

所能发送的帧类型，依连接状态与身份认证状态而有所不同。工作站可能已经认证或未经认证，也可能己经连接或尚未连接。这两个变数的组合有三种可能状态，结果构成了 802.11的网络发展层级：

1. 初始状态；未经认证且尚未关联

2. 已经认证但尚未关联

3. 已经认证且已经关联

每种状态分别对应到 802.11连接的发展阶段。一开始，移动工作站处于状态 1 ，只有进入状态3 才可以通过传输系统发送数据。（IBSS 不包含接入点，也无须进行关联，因此只会停留在状态2。）802.11帧传输的整体状态图，如图 1-60 所示。

　　　　　　　　图1-60：802.11整体状态图

1.4.1 帧等级

帧可以被划分为三种等级。在状态 1 可以传递第 1 级帧；在状态 2 可以发送第 1 与2 级帧；在状态3 则可以传递第 1 、2 与多级帧。

第1 级帧

第1 级帧可以在任何状态中传递，它让802.11的工作站得以进行基本作业。在IBSS 当中，控制帧主要用来依循 CSMA/CA 规则，以及发送帧。工作站也会使用第 1 级帧来找寻基础型网络，并与之进行身份认证。表 1-11 列出了属于第 1 级的各种帧。

表1-11 ：第 1 级帧

第2 级帧

工作站只有在经过身份认证之后，方能够发送第 2 级帧，而且第 2 级帧只能使用于状态 2与状态3。2 级帧主要用来管理关联。关联或重新关联成功后，工作站就会进入状态 3 ；如果关联失败，则工作站依然处于状态 2。工作站收到未经认证的作站所传来的第 2 级帧时，就会应答一个Deauthentication（解除认证）帧，将对方推回状态 1 。表 1-12 列出了所有的第 2 级帧。

表1-12 ：第 2 级帧

第3 级帧

第3 级帧的使用时机，是在工作站认证成功并与接入点关联之后”一旦工作站进入状态3，就可以使用分布式系统服务，也可以和接入点范围以外的对象进行通讯。在状态 3，工作站还可以利用PS-Poll帧享受接入点所提供的省电服务。表手 1-13列出了不同类型的第 3 级帧。

表1-13 ：第多级帧

如果所收到的帧，来自一部已经验证但尚未关联的工作站，接入点就会应答一个Disassociation（解除关联）帧，迫使工作站回到状态 2 。如果发出帧的工作站尚未经过验证，则接入点会应答一个 Deauthentication（解除认证）帧，迫使工作站回到状态 1 。

二、802.11网络协议细节

1.5 利用DCF进行竞争式访问

大部分的传输均采用 DCF（分布式协调功能），DCF提供了类似以太网的标准竞争式服务。DCF允许多部独立的工作站彼此互动，无须通过中央管控，因此可以运用于 IBSS 网络或基础型网络。

试图传送任何数据之前，工作站必须检查介质是否处于闲置状态。若处于忙碌状态，工作站必须延迟访问，并利用指数型退避（orderly exponential backoff ）算法来避免碰撞发生。

我们可从802.11 MAC 的规则中归纳出一组常使用的基本规则，其他额外规则的应用则视状况而定。在所有使用 DCF的传输当中，将会运用到两项基本原则：

1. 如果介质闲置时间长于 DIFS，便可立即进行传输。载波监听同时可通过物理与虚拟（NAV）方式进行。

a. 如果之前的帧接收无误，介质至少必须空出一段 DIFS 时间。

b. 如果之前的传输出现错误，介质至少必须空出一段 EIFS 时间。

2．如果介质处于忙碌状态，工作站必须等候至频道再度闲置。802.11 称之为访问延期。一旦访问延期，工作站会等候介质闲置一段 DIFS时间，同时准备指数型退避访问程序。

在特定状况下，会应用到一些额外的规则。其中有一些规则取决于”线上”的特殊状况，与之前传送的结果有关。

2.1. 错误复原（error recovery）属于传送端的责任。传送端预期每个帧均应收到应答信息，而且必须负责重传，直到传送成功为止。

a. 只有收到正面应答讯息，才表示传送成功。基本交换操作必须完成才算成功。如果某个预期的应答迟迟未到，传送端即会认定其已丢掉，必须加以重送。

b. 所有单点传播数据必须得到应答。（因此，即使无线电波链路本质上属于广播介质，相较于广播数据，单点传播数据基本上还是具备较高的服务质量。）

c. 只要传送失败，重传计数器就会累计，然后重新加以传送。传送失败有可能是因为访问介质失败，也可能是因为得不到应答。不论如何，重传时会等待一段较长时间。

2.2 ．涉及多个帧的传送，可以在传输过程的每个步骤更新 NAV。当所收到的介质预定时间比目前的NAV还长时，工作站即会更新 NAV。设定NAV的方式是以个别的帧为基准。

2.3 ．以下的帧类型可在SIFS 之后传输，因此优先程度较高：应答（acknowledgment）、RTS/CTS交换程序中的 CTS ，以及分段程序中的帧片段。

a ．一旦传送出第一个帧，工作站就会取得频道的控制权。以后帧及其回应均可使用SIFS进行传送，以锁定频道不被其他工作站使用。

b ．传送中，后续帧会将 NAV更新成该介质预计使用的时间。

2.4 ．如果较高层的封包长度超过所设定的门限，必须使用扩展帧格式。

a ．长度超过 RTS门限的封包，必须使用 RTS/CTS交换程序。

b ．长度超过分段门限的封包，必须加以分段。

1.5.1 DCF 与错误复原

错误监听与更正是由起始基本帧交换过程的工作站来决定。一旦监听到错误，该工作站必须负责重传。错误监听必须由传送端负责。有时候传送端可根据应答的有无，推论帧是否已经漏失。只要帧被重传，重传器就会累计。

每个帧或帧片段就会分别对应到一个重传计数器。工作站本身具有两个重传计数器：短帧重传计数器与长帧重传计数器。长度小于 RTS门槛值的帧视为短帧；长度超过该门槛值的数据则为长帧。根据帧的长度，将会分别对应到长短帧重传计数器。帧重传计数由 0 算起，只要帧传送失败即加以累计。

短帧重传计数器会在下列情况发生时归零：

| 之前传送的 RTS 得到CTS的应答时

| 之前传送的未分段帧得到 MAC层的应答时

| 收到广播或组播的帧时

长帧重传计数器会在下列情况发生时归零：

| 之前传送的帧大于 RTS门限值，并且得到 MAC层的应答时

| 收到广播或组播的帧时

除了响应的重传计数器，MAC会赋予每个帧片段最长的『存活期』。传送出第一个帧片段之后，存活计数器随即启动。一旦超过存活时间，该帧便会被丢弃，因此不会重传其余的帧片段。当然，上层协议也可能监听到数据漏失予以重传。不过当上层协议（如 TCP）重传数据，实际上传给802.11MAC的乃是新的帧，所有重传计数器也会归零重新计算。

1.5.2 使用重传计数器

和大部分其他的网络协议一样，802.11是通过重传机制来提供可靠性。数据传送是通过基本次序，整个过程必须完成才算传送成功。当工作站传送帧时，必须得到接收端的应答，否则便认为传送失败。若传送失败则与该帧或帧片段响应的重传计数器累加。如果达到重传限制，该帧随即被丢弃，并将此状况告知上层协议。

之所以要有短帧和长帧，其中一个原因是为了让网络管理人员利用不同长度的帧来调整网络的稳定性。长帧需要较多的缓存空间，所以两种不同重传限制的一个潜在应用，就是放宽长帧的重传限制，以减少所需要的缓存空间。

1.5.3 DCF 与延迟

当帧传送完成并且经过一段 DIFS时间，工作站便会试图传送之前拥塞的数据。DIFS之后所紧接的一段时间，称为竞争期间或退避期间。此期间可进一步分割为时槽(slot)。时槽长度因介质而异。速度较高的物理层会使用较短的时槽。工作站会随机挑选某个时槽，等候该时槽到来以便访问介质。所有时槽的选择机会均等。当多部工作站同时试图传送数据，挑到第一个时槽（亦即取得最小随机号码）的工作站可以优先传送。根据 802.11标准，所有这些时槽号码不应有所差异。唯一值得注意的例外，详见本章稍后有关『spectralink 语音优先性』的相关说明。

1.5.4 Spectralink 语音优先性

要在无线网络上支持语音应用必须面临的挑战之一，就是语音对于网络服务品质的敏感性，远高于数据方面的应用。假设某图形有 1500个bit组的数据迟延了十分之一秒，那就令人无法忍受了。

要在IP 网络上提供高质量的服务已经相当困难。换成无线局域网络，那更是难上加难。以无线局域网络设计语音网络时，工程师遇到的主要问题在于，无线局域网络对所有数据均一视同仁。假设有一个短语音帧和一个长数据帧，此时无线局域网络并不会特别偏爱哪个帧。Spectralink是一家802.11手持电话制造商，该公司制定了一组特殊的协议延伸功能，称为Spectralink 语音优先性（Spectralink Voice Priority，简称 SVP ），该网络更适合用来传输语音。基站与手机当中均包含SVP 元件，让语音享有高于数据的优先性，同时在基站中管理语音通话过程。不论是从基站下行或者自手机上行的语音通话，均由 SVP 协助管理。

要支持SVP ，基站必须以零延后机制传递语音帧。选取延后时槽的时候，支持SVP 的基站并未依循 802.11标准，而是选择编号为零的时槽。竞争无线介质的时候，取得零延后时槽的语音帧将具备实质的优先性，因为数据帧所取得的时槽编号必定大于零。严格来讲，采用零延后机制的工作站已经不算相容于 802.11，因为它以固定的方式强迫取得特定的延后时槽。（不过，为了维持高度负载时的网络稳定性，重传的语音帧必须依循延后规则。）通过零延后机制，支持SVP 的基站可以确保语音帧能够优先访问介质。同时，这类基站也必须能够追踪语音帧，以及提供优先队列的处置。SVP 要求语音帧必须被置于传送队列的最前面。基站可以用不同的方式来提供传输队列，重要的是其所提供的功能，必须将语音帧移置传送队列的最前面。有些基站可能只有一个传送队列，此时语音帧会被置于队列的最前面。有些基站会使用多个传送队列，其中将会由一个队列专门用来传送高优先的语音帧。

如同以太网，每当传输失败时，便会从一个范围中挑选出退避时间。图1.7 以DSSS（直接序列展频）物理层为列，显示当传送次数增加，竞争期间随之增长的情况。不同物理层会使用不同大小的延后时间，不过原则是相同的。竞争期间的大小通常是 2 的指数倍数减 1 （例如11， 61，127 ，255 ）。每当重传计数器累增，竞争期间即以移至下一个 2 的指数倍数。竞争期间的大小受到物理层的限制。例如，DS物理层限制竞争期间最多 1021个传输时槽。

当竞争期间达到最大极限时，就会维持在该数字，直到被重新设定。允许使用较长的竞争期间，可以在多部工作站同时试图访问介质时，保持 MAC验算法的稳定，就算负载极大。当帧传送成功，竞争期间即被重设为最小值，如果到达重传计数器上限，该帧则随即被丢弃。

　　　　　　　　　　图 1-7：DSSS(直接序列展频)的竞争期间

1.5.5 帧的分段与重组

来自较上层的封包，以及某些较大的管理帧，可能必须经过分段，无线频道才有办法加以传输。当干扰存在时，分段封包同时有助于提升可靠性。利用帧的分段，无线局域网络的工作站可将干扰局限于较小的帧片段，而非较大的帧。由此降低可能受干扰的数据量，帧分段可以提高整体的有效传输量。干扰可能有不同来源。虽然并非全部，还是有些微波炉会对2.4GHZ 网络造成干扰。从交流电振幅升起到下降这段时间，电磁管会产生电磁辐射，因此会有一半时间受到微波的干扰。

注 1：在美国，家电产品使用 60HZ 交流电，因此在每 16 毫秒的周期中，微波炉所造成的干扰有 8 毫秒。其他国家使用 50HZ 交流电，因此在每 20 毫秒周期中大约有 10 毫秒会受到干扰。

当上层封包超过网络管理人员所设定的分割门限，就会进行帧的分割。帧控制信息用来指示是否还有其他帧片段待接收。构成整个帧的所有帧片段通常会在所谓的片段宣泄期传输，如图1-8 所示，其中包含了一个 RTS/CTS交换过程，因为 fragementation 与RTS/CTS门限通常会设定为相同的数值。此图同时显示了如何以 NAV与SIFS的组合来控制介质的访问。

　　　　　　　　　　图 1-8：片段宣泄期（fragmentation burst）

帧片段与其应答之间以 SIFS区隔，因此工作站在分段宣泄期（fragmentation burst ）会一直持有频道的掌控权。NAV可确保其他工作站在此 fragmentation burst 期间不致使用该频道。正如任何的RTS/CTS交换，RTS与CTS 会将NAV设定成从预定时间到第一个帧片段结束。其后的帧片段会彼此串通。每个帧片段都会设定 NAV，继续掌握介质的使用权，直到下一个帧的应答结束。图中，fragment0 设定了 NAV，并继续掌握介质直到 ACK 1 ，而 Fragment 1也设定了NAV，并继续掌控介质直到 ACK 2 ，依此类推。当最后一个帧片段及其应答送出时，NAV即会设定为 0，代表介质即将在”片段宣泄期”完成之后释放。

1.5.6 帧格式

因为无线数据链路所带来的挑战，MAC被迫采用了许多特殊的功能，其中包括使用四个地址位。并非每个帧都会用到所有的地址位，这些地址位的值，也会因为MAC帧种类的不同而有所差异。图1-9 展示了一般的 802.11 MAC帧。本节所有图示均依循 IEEE 802.11 的格式。位的传送顺序由左至右，最高效 bit将会最后出现。

　　　　　　　　　　　　图 1-9：一般的 802.11 MAC 帧

802.11 MAC 帧并未包含以太网帧的某些典型功能，其中最显著的是type/length 位以及preamble（同步信号）。Preamble属于物理层，而封装细节（如 type 与length ）则出现在 802.11帧所携带的标头（header）中。

1.5.7 Frame Control 位

所有帧的开头均是长度两个元组的 Frame Control （帧控制）位，如图 1-10 所示。Frame Control 位包括以下次位：

Protocol 位

协议版本位由两个 bit构成，用以显示该帧所使用的 MAC版本。目前，802.11 MAC 只有一个版本；它的协议编号为 0 。未来IEEE 如果推出不同于原始规格的 MAC版本，才会出现其他版本的编号。到目前为止，802.11 改版尚不需用到新的协议编号。

　　　　　　　　　　　　　　图 1-10：Frame control 位

Type 与 Subtype 位

类型与次类型位用来指定所使用的帧类型。为了抵抗噪声与提升可靠性，802.11 MAC 内建了一些管理功能，有些功能之前已经提过，如RTS/CTS与应答。表1-1 显示了 type 与subtype位跟帧类型的对应关系。

如表1-1 所示，最高效 bit会最先出现，恰好与图 1-10 相反。因此，Type次位是 frame control位的第三个 bit之后跟着第二个 bit（b3 b2 ），而 Subtype 次位则是第七个 bit之后跟着第六、第五以及第四个 bit（b7 b6 b5 b4）。

表1 表 1-1：Type与Subtype 位的值与名称：

表1 表 1-1：控制帧Type与Subtype 位的值与名称

表1 表 1-1：数据帧Type与Subtype 位的值与名称

表1 表 1-1：管理帧Type与Subtype 位的值与名称

TO DS与From DSbit

这两个bit用来指示帧的目的地是否为传输系统。在基础网络里，每个帧都会设定其中一个DS bit 。你可以根据表 1-2 来解读这两个 bit。

表2 表 1-2 ：To DS 与From DSbit所代表意义：

More fragments bit

此bit的功能类似 IP 的More fragmentsbit。若较上层的封包经过 MAC分段处理，最后一个片段除外，其他片段均会将此 bit设定为 1 。大型的数据帧以及某些管理帧可能需要加以分段；除此之外的其他帧则会将此 bit设定为0 。实际上，大多数数据帧均会以最大的以太网长度进行传送，不过帧分段并不常用。

Retry bit

有时候可能需要重传帧。任何重传的帧会将此 bit设定为 1 ，以协助接收端剔除重复的帧。

Power management bit

802.11网卡通常以 PC Card 的型式出现，主要用于以电池供电的膝上型或手持式电脑。为了提高电池的使用时间，通常可以关闭网卡以节省电力。此 bit用来指出传送端在完成目前的基本帧交换之后是否进入省电模式。1 代表工作站即将进入省电模式，而 0 则代表工作站会一直保持在清醒状态。基站必须行使一系列重要的管理功能，所以不允许进入省电模式，因此基站所传送的帧中，此 bit必然为 0 。

More data bit

为了服务处于省电模式的工作站，基站会将这些由”传输系统”接收而来的帧加以暂存。基站如果设定此 bit，即代表至少有一个帧待传给休眠中的工作站。

Protected Frame bit

相对于有线网络，无线传输本质上就比较容易遭受拦截。如果帧受到链路层安全协议的保护，此bit会被设定为 1 ，而且该帧会略有不同。之前，Protected Frame bit 被称为 WEP bit。

Orderbit

帧与帧片段可依序传送，不过发送端与接收端的 MAC必须付出额外的代价。一旦进行”严格依序”传送，此 bit被设定为 1。

1.5.8 Duration/ID 位

Duration/ID 位紧跟在frame control 位之后。此位有许多功用，有三种可能的形式，如图1-11 所示。

　　　　　　　　　　　　　　图 1-11：Duration/ID 位

1.5.8.1 Duration ：设定NAV

当第15个bit被设定为0 时，Duration/ID 位就会被用来设定 NAV。此数值代表目前所进行的传输预计使用介质多少微秒。工作站必须监视所收到的任何帧头，并据以更新 NAV。任何超出预计使用介质时间的数值均会更新 NAV，同时阻止其他工作站访问介质。

1.5.8.2 免竞争期间所传送的帧

在免竞争期间（contention-free period ，简称 CFP），第 14个bit为0 而第15个bit为1。其他所有bit均为0 ，因此 duration/ID 位的值为 32768 。这个数值被解读为 NAV。它让没有收到Beacon（信标）帧『注』的任何工作站，得以公告免竞争期间，以便将 NAV更新为适当的数值，避免干扰到免竞争传输。

注 Beacon 帧是管理帧的次类型（subtype），因此字首以大写表示。

1.5.8.3 PS-Poll帧

在PS-Poll（省电模式－轮询）帧中，第 14与第 15个bit会被同时设定为1。移动式工作站可以关闭天线以达到省电目的。休眠中的工作站必须定期醒来。为确保不致丢失任何帧，从休眠状态醒来的工作站必须送出一个 PS-Poll帧，以便从基站取得之前暂存的任何帧。此外，醒来的工作站会在 PS-Poll 帧中加入连接识别码（association ID，简称 AID），以显示其所隶属的BSS 。AID 包含在 PS-Poll帧中，其值介于 1-2,007。而介于 2,008-16,383 的值目前保留并未使用。

1.5.9 Address 位

一个802.11帧最多可以包含四个地址位。这些位地址位均经过编号，因为随着帧类型不同，这些位的作用也有所差异。基本上，Address 1 代表接收端，Address 2 代表传送端，Address 3 位被接收端拿来过虑地址。举例而言，在基础网络里，第三个地址位会被接收端用来判定该帧是否属于其所连接网络。『注』

注：802.11 规定工作站应该忽略那些不属于相同 BSSID 的帧，不过大多数产品并未正确实现 BSSID 过虑功能，还是会将接收到的所有帧传给上层协议。

802.11所使用的定位模式，乃是依循其他 IEEE 802 网络所使用的格式，包括以太网。地址位本身的长度有 48个bit。如果传送给实际介质的第一个 bit为0，该地址位代表单一工作站（单点传播[unicast] ）。如果第一个 bit为1 ，该地址代表一组实际工作站，称为组播（多点传播[multicast] ）地址。如果所有 bit均为1 ，该帧即属广播（broadcast），因此会传送给连接至无线介质的所有工作站。

这些长度 48个bit的地址位有各种不同的用途：

| 目的地址

和以太网一样，目的地址（Destination address ）是长度 48个bit的IEEE MAC 识别，码，代表最后的接收端，亦即负责将帧交付上层协议处理的工作站。

| 源地址

此为长度 48个bit的IEEE MAC 识别码，代表传输的来源。每个帧只能来自单一工作站，因此Individual/Group bit 必然为0 ，代表来源地址（Source address ）为单一工作站。

| 接收端地址

此为长度 48个bit的IEEE MAC 识别码，代表负责处理该帧的无线工作站。如果是无线工作站，接收端地址即为目的地址。如果帧的目的地址是与基站相连的以太网结点，接收端即为基站的无线界面，而目的地址可能是连接到以太网的一部路由器。

| 传送端地址

此为长度 48个bit的IEEE MAC 识别码，代表将帧传送至无线介质的无线界面。传送端地址通常只用于无线桥接。

1.5.10 Basic Service Set ID (BSSID)

要在同一个区域划分不同的局域网络，可以为工作站指定所要使用的 BSS （基本服务集）。在基础网络里，BSSID （基本服务集标识）即是基站无线界面所使用的 MAC地址。而对等（Ad hoc ）网络则会产生一个随机的 BSSID ，并将Universal/Localbit 设定为1，以防止与其他官方指定的MAC地址产生冲突。

要使用多少地址位，取决于帧类型。大部分的数据帧会用到三个位：来源、目的以及 BSSID 。数据帧中，地址位的编号与排列方式取决于帧的传送路径。大部分的传输只会用到三个地址，这解释了为什么在帧格式中，四个地址位都有其中三个位相邻的。

1.5.11 顺序控制位

此位的长度为 16个bit，用来重组帧片段以及丢弃重复帧。它由4 个bit的fragment number（片段编号）位以及 12个bit的sequence number （顺序编号）位所组成，如图 1 －12所示。控制帧未使用顺序编号，因此并无sequence control 位。

　　　　　　　　　　　　图 1-12：Sequence Control 位

当上层帧交付 MAC传送时，会被赋予一个 sequence number （顺序编号）。此位的作用，相当于已传帧的计数器取 4096的模（modulo）。此计数器由 0 起算，MAC每处理一个上层封包就会累加 1。如果上层封包被切割处理，所有帧片段都会具有相同的顺序编号。如果时重传帧，则顺序编号不会有任何改变。

帧片段之间的差异在于 fragment number （片段编号）。第一个片段的编号为 0 。其后每个片段依序累加 1 。重传的片段会保有原来的 sequence number 协助重组。

具备QoS 延伸功能的工作站对 sequence control 位的解读稍有不同，因为这类工作站必须同时维护多组传送队列。

1.5.12 帧主体

帧主体（Frame Boby ）亦称为数据位，负责在工作站间传送上层数据（payload）。在最初制定的规格中，802.11帧最多可以传送 2304个bit组的上层数据。（实际上必须能够容纳更多的数据，以便将安全性与 QoS 相关标头纳入）802.2 LLC 标头具有 8 个bit组，最多可以传送2296 个bit组的网络协议数据。防止分段必须在协议层加以处理。在IP 网络中，Path MTU Discovery（路径最大传输单位查询；RFC1191）将可避免大于 1500个bit组的帧传递。

802.11与其他链路层技术不同之处，表现在两个比较显著的方面。首先，在802.11帧中并无任何上层协议的标记可供区别。上层协议是以额外标头 type 位加以标记，同时将其作为 802.11所承载数据的开始。其次，802.11通常不会将帧填补至最小长度。802.11所使用的帧并不大，随着芯片与电子技术的进展，目前已经没有填补的必要。

1.5.13 帧检验序列（FCS ）

和以太网一样，802.11帧也是以帧检验序列（frame check sequence ，简称 FCS ）作为结束。FCS 通常被视为循环冗余码（cyclic redundancy check,简称 CRC），因为底层的数学运算相同。FCS 让工作站得以检查所收到的帧的完整性。FCS的计算范围涵盖 MAC标头里所有位以及帧主体。虽然 802.3 与802.11计算 FCS 的方法相同，不过 802.11所使用的 MAC 标头与802.3 的不同，因此基站必须重新计算 FCS 。

当帧送至无线界面时，会先计算 FCS ，然后再由 RF或IR 链路传送出去。接收端随后会为所收到的帧计算 FCS ，然后与记录在帧中的 FCS 做比较。如果两者相符，该帧极有可能在传输过程中并未受损。

在以太网上，如果帧的FCS 有误，则随即予以丢弃，否则就会传送给上层协议处理。在802.11网络上，通过完整性检验的帧还需接收端送出应答。例如，接收无误的数据帧必须得到正面应答，否则就必须重传。对于未能通过 FCS 检验的帧，802.11并未提供负面应答机制；在重传之前，工作站就必须等候应答超时。

1.6 802.11对上层协议的封装

和所有其他的 802 链路层一样，802.11可以传输各种不同的网络层协议。和以太网不同的是，802.11是以802.2 的逻辑链路控制封装来携带上层协议。图 1-13 显示了如何以 802.2LLC封装来携带 IP 封包。如该图所示，802.1H与RFC 1042 所使用的『MAC标头』长度为 12个bit组，其内容为以太网上的『源 MAC地址』与『目的 MAC地址』，或者前面所提到的长标头（long 802.11MAC header ）。

　　　　　　　　　　　　　　图 1-13：802.11 里的 IP 封装

传输时，用来封装 LLC 数据的方式有两种。其中一种是 RFC 1042 所描述的方式，另外一种则是802.1H所规范的方式。两种标准各自有其别名。RFC 1042 有时候被称为 IETF 封装，而802.1H有时候则被称为隧道式封装（tunnel encapsulation）.

这两种方式极为相似，如图 1-13所示。此图最上方为以太网帧，它具有 MAC标头（源与目的MAC地址），类型代码（type code ），内嵌封包（embedded packet ）以及帧检验等位。

在IP 领域里，Type code 不是代表IP 的本身的OX0800（十进制的 2048），就是代表地址解析协议（简称 ARP）的 OX0806（十进制的 2054）。

RFC 1042 与802.1H均衍生自 802.2 的子网络访问协议（sub-network access protocol ，简称SNAP ）。MAC地址会被复制到封装帧（encapsulation frame）的开头，然后插入 SNAP标头。SNAP 标头一开始是目的服务访问点（destination service access point,简称DSAP）与源服务访问点（source service access point, 简称SSAP）。然后是一个控制位。和高阶数据链路控制（high-level data link control, 简称HDLC）及其衍生协议一样，此控制位会被设定为 0x03，代表未编号信息（unnumbered information，简称UI）,对应到IP datagram 所谓的尽力传送（best-effert delivery）范畴。SNAP 所置入的最后一个位是组织代码（organizationally unique identifier ，简称 OUI）。起初，IEEE 希望用一个 bit组的服务访问点（service access point ）来涵盖网络协议编号，不过后来证明这种看法过于乐观。因此，SNAP 只得从原来的以太网帧复制一份类型代码（type code ）。802.11H 与RFC 1042 之间的唯一差异，在于其使用的 OUI。

有些产品可以让使用者在两种封装标准间进行切换，虽然这种功能并不常见。以 Microsoft操作系统而言，AppleTalk 与IPX 协议组预设使用 802.1H，其他协议则使用 RFC 1042 。目前大部分接入点均依循 Microsoft的做法，不再提供封装方式的切换选项。事实上，由于 Microsoft所采用的封装方式得到广泛的支持，因此 Wi-Fi联盟的认证测试计划亦将它包含在内。

1.7 竞争式数据服务

为了增加可靠性，802.11纳入了许多额外的功能。这些功能导致某些规则上的混淆，因而无法判断何时该允许使用何种类型的帧。这些额外的功能也让网络管理人员更难预测，有哪些帧会来往于所检视的网络中。本节的目的在澄清，802.11局域网络中负责运送数据的基本交换过程。（大部分的管理帧只会公告给该区域中相关的对象，信息的传递纯粹是单向的。）

本节所陈述的是基本交换程序，也就是说数据的交换过程必须视为单一整体。举例而言，单点传播数据必须得到应答以确保数据传送无误。虽然整个数据的交换过程包含两个帧，但数据交换本身只算第一过程。只要有一方失误，整个过程就必须重新来过。802.11 定义了两组截然不同的基本交换程序。其一为 DCF，用于竞争服务。第二种交换方式为 PCF，用于免竞争服务（contention-free service）。免竞争服务所使用的帧交换方式不仅错综复杂，而且还难以理解。有鉴于商业化产品很少实现免竞争服务，其交换过程不再赘述。

DCF说使用的帧交换方式在 802.11 MAC 中占有决定性的地位。根据 DCF的规定，所有的产品都必须提供尽力的传递功能。为了实现竞争式 MAC，处于作用状态的工作站都必须处理每个帧的 MAC标头。整个帧交换过程，始终某部工作站在 DIFS之后取得闲置介质的使用权。

1.7.1 广播与组播数据或管理帧

广播与组播帧的交换过程最为简单，因为这些帧无须应答。这两种帧也可以视为群组帧，

因为其接收对象不限于单一工作站。帧封装（framing ）与定位（addressing ）在 802.11中较为复杂，适用此规则的帧类型如下所示：

| 广播数据帧会在 Address1位中填入广播地址

| 组播数据帧会在 Address1位中填入组播地址

| 广播管理帧会在 Address1位中填入广播地址（Beacon、Probe Request 以及IBSS ATIM帧）

组播帧无法加以分段，也无须得到应答。整个基本交换过程只牵涉到一个帧，根据竞争式访问控制规则加以传递。传送结束后，所有工作站必须等待一段 DIFS时间，然后在竞争期间倒数随机产生的延迟时间。

因为帧的交换过程只牵涉到一个帧，所以将 NAV（网络分配矢量）设定为 0。既然此后已无其他帧，也就不必使用虚拟载波监听锁住介质，来防止其他工作站的访问。传送该帧之后，所有工作站均会等候一段 DIFS时间，然后通过竞争期间开始为任何遭延迟的帧进行倒数。整个交换过程，详见图 1-14 。

　　　　　　　　　　图 1-14：广播/组播数据以及广播管理的基本帧交换过程

因环境而异，组播帧可能会遇到低劣的服务质量，因为这些帧没有得到任何应答。因此，有些工作站可能会遗漏广播或组播数据。不过MAC并未内建任何机制可用以重传广播或组播帧。

1.7.2 单点传播帧

在802.11标准中，针对个别工作站所传送的帧称为直接数据（direct data ）。本书中使用较通俗的字眼，称之为单点传播（unicast）。单点传播帧必须得到应答以确保可靠性，亦即可借助各种机制来改善传输效率。本节所描述的交换过程适用于任何单点传播帧，因此也适用于管理帧与数据帧。实际上，这些过程通常只见于数据帧。

1.7.2.1 单一帧（最后一个片段）及其正面应答

两部工作站之间的传输可靠性建立在简单的正面应答上。单点传播数据帧必须得到正面应答，否则该帧即会被认定已经丢失。单一帧及其回应是最基本的例子，如图 1-15 所示。

　　　　　　　　　　　　图 1-15：单一帧及其正面回应

此帧会利用 NAV 为本身、应答及 SIFS 预定介质使用权。设定较长的 NAV，是为了替整个交换程序锁住虚拟载波，以保证接收端可以传送应答。因为此交换程序是以 ACK 做为结束，所以没有必要再锁住虚拟载波，因此该 ACK 中 NAV 会被设定为 0。

1.7.2.2 帧分段

包括IP 在内，一些较上层的网络协议或多或少都会用到帧分段。在网络层进行分段的缺点是，接收端必须加以重组；如果帧在传输过程中遗失，整个封包就必须重传。在链路层使用分段机制可以提升速度，亦即以较小的 MTU在转运点（hop ）间传送数据。

　　　　　　　　　　图 1-16：帧分段

此外，802.11可以利用帧分段来避免干涉。无线点播干扰通常会以瞬间而高能量的尖波形式出现，而且经常与 AC电源线同步。将帧加以分段，可保护大部分帧不遭受损害。基本分段机制如图1-16 所示。

最后两个帧和之前的交换过程没有两样，NAV的设定也完全相同。不过，倒数第二个帧之前所有帧均会使用 NAV,为下一个帧锁住介质。第一个数据帧会将 NAV的时间设定至足以涵盖ACK1, 下一个帧片段及其回应（ACK2）。为了表示其为帧片段，MAC会将帧标头控制位的 More Fragmentsbit 设定为1。最后一个回应（ACK3）除外，其余回应都会继续为下一个数据片段及其回应延长锁住介质的时间。后续的数据帧会继续延长 NAV以涵盖后续的回应，直到最后一个数据帧才会将 More Fragmentsbit设定为 0 ，而最后一个回应（ACK3）则会将 NAV设定为 0 。帧片段的数目并无限制，不过虚空总长度必须短于 PHY对交换过程所做的限制。

帧分段是由 MAC的fragmentation threshold(切割门限) 参数所控制。大部分的网卡驱动程序都允许使用者设定此参数。任何超过分段门限的帧都会被加以分段，分段方式因实际情况而异。调高分段门限意味着帧的传输负担较小，不过帧丢掉和损害的成本较高，因为将会有较多的数据必须丢弃与重传。调低分段门限意味着传输负担较重，不过在面临较恶劣的环境时，这种做法可以提供较佳的稳定性。

1.7.2.3 RTS/CTS

为保证介质使用权以及数据传输不被中断，工作站可使用 RTS/CTS的交换方式。图 1-17说明了整个过程。RTS/CTS交换的做法和帧分段一开始没有什么两样，只是RTS 帧并未携带任何数据。RTS/CTS中的 NAV可让CTS完成工作，而 CTS 则可用来为数据帧保留使用权。

RTS/CTS 可用在所有的帧交换、非帧交换或介于两者之间。和帧分段一样，RTS/CTS 是由启动程序中的门限值来控制的。超过该门限的帧由 RTS/CTS 先行清空介质，而较小的帧则直接传送。

　　　　　　　　　　　　图 1-17：以 RTS/CTS 锁住介质

1.7.2.4 RTS/CTS 与帧分段

实际上，RTS/CTS交换过程通常与帧分段并行，如图1-18所示。虽然经过分段，帧片段还是有一定的长度，因此可受惠与 RTS/CTS过程所确保的介质独家使用权，免与隐藏节点的竞争。有些厂商将帧分段门限与 RTS/CTS门限的预设值设成一样。

　　　　　　　　　　　　　　图 1-18：RTS/CTS 与帧分段

1.7.3 省电程序

在RF系统中，放大器是最耗电的元件，由它负责将发送出的信号放大，以及将所收到的信号放大到可处理的水平。802.11工作站可以关闭无线电波收发器，并且定期进入休眠状态，以维持最长的电池使用时间。在这段期间，接入点会为每部处于休眠状态的工作站暂存帧。若有暂存帧，接入点会在后续的 Beacon帧中告知工作站。由省电状态唤醒的工作站可以使用 PS-Poll帧取得这些暂存帧。

接收到PS-Poll帧的接入点，可以立即采取回应，也可以等到环境许可，比较空闲时再予以应答。有时候，采用哪种 PS-Poll回应决定自接入点所采用的芯片组的厂商。有些芯片组厂商同时支持两种模式，有些则只支持一种。802.11只要求支持一种方式即可，因此两种做法均符合标准要求。

1.7.3.1 立即应答

接入点可以对 PS-Poll（省电模式－轮询）帧立即作出应答。经过一段 SIFS(短帧间隔)时间，接入点即可传送帧。如图 1-19 所示，PS-Poll帧隐含了一 NAV。PS-Poll帧的Duration/ID位中包含了Association ID（连接识别码），因此接入点可以判断有哪些帧是为该工作站所暂存的。不过， MAC规格书要求所有收到 PS-Poll的工作站都必须更新 NAV，将NAV的值设定为一个 SIFS加上一个ACK的时间。虽然此 NAV对数据帧而言过短，但接入点会取得介质使用权，而所有工作站都会为了这个数据帧而延后访问介质。但数据帧传送结束时，NAV随即更新以反映数据帧标头中的数值。

　　　　　　　　　　　　图 1-19：立即的 PS-Poll 回应

如果暂存的帧过大，则必须进行分段。图 1-20 说明了帧分段情况下的 PS-Poll立即应答。和其他工作站一样，接入点的分段门限通常可由使用者来设定。

　　　　　　　　　　　　图 1-20：帧分割情况下的 PS-Poll 立即回应

1.7.3.2 延迟应答

除了立即应答，接入点可以先回复一个简单应答。这种做法称为延迟应答（deferred response），因为接入点虽然回应了访问暂存帧的要求，但未并立即采取实际的发送行动。使用延迟应答的优点之一，在于接入点方面的软件较易实现，因为应答信息可以通过芯片组立即传送，至于数据则可以先予以暂存，然后依正常过程传输。

通过PS-Poll要求帧的工作站必须保持清醒，直到该帧传输完成。不过，在竞争式服务期间，接入点可能在任何时间传递帧。此时工作站不能返回省电模式，除非接收到一个Beacon帧，其中对应该工作站的 TIM （数据待传）bit已被清除。

图1-21 说明了整个过程。在此图中，工作站刚由省电模式转变为活动模式，同时注意到接入点已经为它暂存了帧。于是工作站会发出 PS-Poll给接入点，要求接收这些暂存帧。不过，接入点可能会选择延迟应答，因此只回传了一个 ACK。到目前为止，接入点已经回应了工作站的暂存帧访问要求，并且承诺将在某个时间点加以传送。工作站必须处于活动模式等候，也许经过几次基本帧交换之后，接入点就会送出工作站所要的数据。虽然在图 1-21 中并未显示，不过暂存帧还是由可能遭到分段的。

　　　　　　　　　　　　图 1-21：PS-Poll 延迟回应的范例

收到数据帧之后，工作站还是必须停留在清醒状态，直到下一个 Beacon 帧被传送出来。Beacon帧只是用来提醒，是否有为某部工作站暂存的帧，没有办法告知实际的帧数量。一旦工作站收到的 Beacon帧中显示已无暂存帧，便可断定已经完成暂存帧的接收，然后返回省电模式。

1.7.4 多种速率支持（Multirate Support ）

能够以不同速度工作的网络技术必须具备一种机制，可以协调出一种收发端彼此均可接受的数据率。速度协商对工作站而言尤其方便。工作站可以经常变化速率，以便回应无线电环境的快速变动。但工作站间的距离改变，速度也会随之变动。工作站必须能够适应随时变动的环境，必要时更改传输速率。和一些其他协议功能一样，802.11标准并未规范该如何选择传输速率。标准只是提出一般原则，在实际上厂商享有相当大的自由。其中，有些规则适用于所有工作站：

1. 每部工作站均保有一份速率清单，其中记录工作站与所连接BSS均支持的所有速率。（所谓BSS，通常相当于一部接入点，不过较新的产品可以让使用者依虚拟接入点自订速率。）高于速率组合的传输速率是不允许用来传送帧的。

2. 每个BSS必须负责维护一组基本速率，即打算加入此BSS的工作站所必须支持的速率清单。任何传送至群组接收地址的帧必须以基本速率传送，确保所有工作站均可正确解读。

3. 用来起始帧交换的控制帧，如 RTS 与CTS ，必须以基本速率组合中的一种速率进行传输。这一规则可以确保必须以CTS 回应RTS 帧的工作站，能够以相同速率工作。

控制帧可以用于回溯相容模式（backwards-compatiblity），又称为防护（protection）模式；防护模式是为了避免新旧工作站间彼此干扰，因为较旧的工作站或许只支持较慢的调制技术，新式工作站却可以使用较快的调制方式。如果所在地区有些工作站不支持较新的调制方式，则必须以较旧的调制方式传输防护帧（Protection frame）。

4. 发送给特定工作站的帧，会在 Address 1 位记载单点传播目的地址。单点传播帧（Unicast frame）可以使用目的端支持的任一速率传送。至于数据速率的选择方式， 802.11标准并未加以规范。

免竞争期间所使用的帧可以带有多重目的；如果帧中包含 ACK，就是用来应答之前的帧传送者而不是帧接收者。传送端必须确保该帧以接收端及目的端工作站均支持的速率传送。

5. ACK或CTS 之类的应答帧必须以基本速率组合所包含的速率传送，但不能高于这次传输所使用的起始帧。应答帧必须使用与起始帧相同的调制方式（DSSS 、CCK或OFDM ）。

1.7.4.1 选速与降速

市面上所有 802.11界面均支持某种降速机制，可以适应不同网络环境选择所使用的数据率。速率选择主要在决定一张网卡该在何时升速以提高链路质量。802.11标准并未规范工作站如何决定是否降速（或升速），因此速率选择如何实现，留给芯片厂商自行决定。几乎所有芯片组均有自己一套选择机制，因此，大多数 802.11界面的工作方式均有所不同。速率选择可以通过程序控制，一般是由驱动界面的程序所控制。速率选择机制可以公国驱动程序或者软件升级。

最常用来判断何时应该变速的算法，其实是通过一些不是那么严谨的信号品质量测量。信号质量可以直接就信噪比（signal-to-noise ratio ）加以测量，或者间接观察有多少帧需要重传。

直接测量信噪比，可以针对最近一个帧的瞬间信号质量，或者就最近一段期间所接收到之一定数量的帧取平均数。有些芯片组会直接测量信噪比，不过随后会将之转换为相应的”信号质量”（signal quality ）。当信号质量变差，芯片就会以降速来适应。

至于间接测量，则是监测瞬间或平均漏失多少帧，然后予以适度补偿。采用间接测量的算法，简单来讲就是：如果帧已经丢失且帧重传计数器已经用尽，那就降速至下一档，然后重试一遍；反复进行以上步骤直到帧送出，或者一直尝试到最低速率都无法成功传递为止。采用间接信号品质量测的芯片组或许会稍微修改上述算法，避免耗费过多时间在物理层所支持的所有速率间逐次降速。尤其近来的芯片组均支持不少的速率，在较低速率上反复重试将会相当费时。

1.8 帧的处理与桥接

无线接入点的核心，其实就是桥接器，负责在无线与有线介质之间转换帧。虽然 802.11并未限制非得使用哪种有线介质技术，放弃以太网不用的接入点还真没见过。

　　　　　　　　　　　　图 1-22：在无线与有线介质之间转换帧

大多数接入点在设计上就是扮演802.11与以太网之间的桥梁，因此，了解帧在两种介质之间的传递方式就相当重要。如图1-22 所示。

1.8.1 无线介质到有线介质（802.11至以太网）

当接入点的无线界面接收到准备传送至有线网络的帧，接入点就必须在两种介质间桥送帧。非正式来讲，以下是接入点必须进行的一系列工作：

1. 当接入点接收到一个帧，首先会检测该帧基本上是否完整。接下来，接入点会针对所使用的物理层，检视物理层标头，然后验证802.11帧上的帧检验码。

2. 验证帧接收无误后，接入点就会继续检视是否应该进一步处理该帧。

a. 传送至接入点的帧，会将接入点的 MAC 地址（即 BSSID）摆在 802.11 MAC 标头的 Address 1 位。不符该接入点 BSSID 的帧应予以丢弃。（有些产品并未实现此步骤。）

b. 802.11 MAC 接着监测且移出重复的帧。产生重复帧的原因很多，不过最常见的情况是 802.11 应答信息在传送过程中丢失或有所损毁。为了简化上层协议的工作，因此由 802.11 MAC 负责剔除重复的帧。

3. 一旦接入点判定需要进一步处理该帧，就必须予以解密，因为该帧会受到链路层安全算法的保护。

4. 成功解密之后，接入点即检视该帧是否为帧片段，需要进一步重组。完整性保护（integrity protection）针对重组后完整帧，而不是个别的帧片段。

5. 如果经过步骤2a的BSSID检验，判定接入点必须桥送该帧，较复杂的802.11 MAC 标头就会被转换为较简单的以太网 MAC 标头。

a. 记录在 802.11 MAC 标头之 Address 3 位里的目的地址，会被复制到以太网的目的地址。

b. 记录在 802.11 MAC 标头之 Address 2 位里的源地址，会被复制到以太网的源地址。

c. 从 802.11 Data 位里的 SNAP 标头，将（Type）类型代码复制到以太网帧里的 Type 位。如果该以太网帧亦使用 SNAP，就复制整个 SNAP 标头。

d. 顺序信息主要供帧片段重组之用，不过当帧被桥送之后即予以丢弃。

e. 如果有标准的服务质量处理程序，即在此进行无线与有线的 Qos 对应。不过到目前为止，用来表示服务质量的形式，通常就是在有线帧中使用 802.1p优先性等级 bit，或者其他的控制形式。

6. 重新计算帧检验码。以太网与802.11使用相同的算法来计算FCS ，不过802.11帧多出一些位，同时为FCS 所保护。

7. 所产生的新帧交付以太网界面传送。

1.8.2 有线介质至无线介质（Wired Medium to Wireless Medium ）

将帧从接入点有线端桥接至无线介质的过程刚好相反：

1. 验证以太网 FCS 后，接入点首先会检视是否需要进一步处理所接收到的帧，亦即检视该帧的目的地址是否属于目前与接入点连接的工作站。

2. 将SNAP 标头附加于以太网帧的数据之前。上层封包是以SNAP 标头进行封装，而其Type位是自以太网帧里的类型代码复制而来。如果该以太网帧亦使用SNAP ，则复制整个SNAP 标头。

3. 对帧的传送进行调度。802.11包含复杂的省电过程，将帧置于传送序列之前，接入点可能会将帧暂存于缓存区。

4. 一旦帧被置于序列待传，就会被赋予一个顺序编号。如有必要，所产生的数据可以用完整性检验值加以保护。如果帧需要分段，则会根据事先设定好的分段门限进行分段。分段帧时，将会在Sequence Control 位指定片段编号。

5. 如果帧需要保护，则对帧（或每个帧片段）的本体加密。

6. 802.11 MAC 标头是根据以太网 MAC 标头产生。

a.将以太网的目的地址复制到 802.11 MAC标头的 Address 1 位。

b.将 BSSID 置于 MAC 标头的 Address 2，以做为无线介质上之帧的发送者。

c.将帧的源地址复制到 MAC 标头的 Address 3 位。

d.将其他位填入 802.11 MAC 标头。也就是把预计传送时间填入 Duration 位，并把适当的旗标填入 Frame Control 位。

7. 重新计算帧检验码。以太网与802.11使用相同的算法来计算FCS ，不过802.11帧多出一些位，同时为FCS 所保护。

8. 所产生的新帧交付802.11界面传送。

1.8.3 服务质量延伸功能

服务质量延伸功能会影响帧的传输顺序，但并不会改变帧行径 802.11 MAC 的基本路径。

802.11e 服务质量延伸功能并非只使用单一传输序列，而是在上述有线至无线桥接程序中的第 4、5 、7 步骤采用多组传输序列。这些步骤会根据优先次序进行帧处理；而优先次序取决于帧的内容以及配置设定中预先指定的优先性分级规则。

三、CSMA/CD

在以太网中，所有的节点共享传输介质。如何保证传输介质有序、高效地为许多节点提供传输服务，就是以太网的介质访问控制协议要解决的问题。

CSMA/CD（Carrier Sense Multiple Access/Collision Detect）即载波监听多路访问/冲突检测机制。在传统的共享以太网中，所有的节点共享传输介质。如何保证传输介质有序、高效地为许多节点提供传输服务，就是以太网的介质访问控制协议要解决的问题。

1.9 基本概念

CSMA/CD是英文carrier sense multiple access/collision detected 的缩写，可把它翻成”载波监听多路访问/冲突检测”，或”带有冲突检测的载波侦听多路访问”。

所谓载波监听（carrier sense），意思就是以太网络上的各个工作站在发送数据前，都要监听总线上有没有数据正在传输。若有数据传输（称总线为忙），则不发送数据，需要等待；若无数据传输（称总线为空），可以立即发送准备好的数据。

所谓多路访问（multiple access)，意思就是以太网络上的各个工作站在发送数据时，共同使用一条总线，且发送数据是广播式的。

所谓冲突（collision），意思就是，若以太网上有两个或两个以上工作站同时发送数据，在总线上就会产生信号的冲突；多个工作站都同时发送数据，在总线上就会产生信号的冲突，哪个工作站接收到的数据都辨别不出真正的信息。这种情况称冲突或者碰撞。

为了减少冲突发生的影响，工作站在发送数据过程中还要不停地检测自己发送的数据，检测自己传输过程中有没有其他工作站在发送数据，在传输过程中与其它工作站的数据发生冲突，这就是冲突检测（collision detected）。

1.10 基本算法

CSMA/CD是带有冲突检测的CSMA，其基本思想是：当一个节点要发送数据时，首先监听信道；如果信道空闲就发送数据，并继续监听；如果在数据发送过程中监听到了冲突，则立刻停止数据发送，等待一段随机的时间后，重新开始尝试发送数据。

CSMA/CD媒体访问控制方法的工作原理，可以概括如下：

先听后说，边听边说；

一旦冲突，立即停说；

等待时机，然后再说；

听，即监听、检测之意；说，即发送数据之意。

上面几句话在发送数据前，先监听总线是否空闲。若总线忙，则不发送。若总线空闲，则把准备好的数据发送到总线上。在发送数据的过程中，工作站边发送边检测总线，查看是否自己发送的数据有冲突。若无冲突则继续发送直到发完全部数据；若有冲突，则立即停止发送数据，但是要发送一个加强冲突的JAM信号，以便使网络上所有工作站都知道网上发生了冲突，然后，等待一个预定的随机时间，且在总线为空闲时，再重新发送未发完的数据。

CSMA/CD是标准以太网、快速以太网和千兆以太网中统一采用的介质争用处理协议（但在万兆以太网中，由于采用的是全双工通信，所以不再采用这一协议）。之所以称之为”载波侦听”（”载波”就是承载信号的电磁波），而不是称之为”介质侦听”，那是因为如果介质上正在有载波存在，则证明介质处于忙的状态（因为信号或者数据不是直接传输的，而是通过电磁载波进行的）；如果没有载波存在，则介质是空闲状态。也就是通过载波的检测，可以得知介质的状态，而不能直接来侦听介质本身得出其空闲状态。

【说明】其实这里侦听的应该是”信道”，而不是”介质”本身，因为在一条传输介质中，可能包含有多条信道，用于不同的传输链路。

1.11 原理介绍

在CSMA中，由于信道传播时延的存在，即使通信双方的站点都没有侦听到载波信号，在发送数据时仍可能会发生冲突，因为他们可能会在检测到介质空闲时同时发送数据，致使冲突发生。尽管CSMA可以发现冲突，但它并没有先知的冲突检测和阻止功能，致使冲突发生频繁。

一种CSMA的改进方案是使发送站点在传输过程中仍继续侦听介质，以检测是否存在冲突。如果两个站点都在某一时间检测到信道是空闲的，并且同时开始传送数据，则它们几乎立刻就会检测到有冲突发生。如果发生冲突，信道上可以检测到超过发送站点本身发送的载波信号幅度的电磁波，由此判断出冲突的存在。一旦检测到冲突，发送站点就立即停止发送，并向总线上发一串阻塞信号，用以通知总线上通信的对方站点，快速地终止被破坏的帧，可以节省时间和带宽。这种方案就是CSMA/CD，已广泛应用于局域网中。

CSMA/CD是一种争用型的介质访问控制协议。它起源于美国夏威夷大学开发的ALOHA网所采用的争用型协议，并进行了改进，使之具有比ALOHA协议更高的介质利用率。主要应用于现场总线Ethernet中。另一个改进是，对于每一个站而言，一旦它检测到有冲突，它就放弃它当前的传送任务。换句话说，如果两个站都检测到信道是空闲的，并且同时开始传送数据，则它们几乎立刻就会检测到有冲突发生。它们不应该再继续传送它们的帧，因为产生冲突的数据是无法分辨出原始信息的，这时继续发送只会产生数据垃圾而已；相反一旦检测到冲突之后，它们应该立即停止传送数据。快速地终止发送被损坏的帧可以节省时间和带宽，避免造成资源浪费。

CSMA/CD控制方式的优点是：

原理比较简单，技术上易实现，网络中各工作站处于平等地位，不需集中控制，不提供优先级控制。但在网络负载增大时，发送时间增长，发送效率急剧下降。

CSMA/CD应用在 OSI 的第二层数据链路层。

它的工作原理是：发送数据前，先侦听信道是否空闲；若空闲，则立即发送数据。若信道忙碌，则等待一段时间至信道中的信息传输结束后再发送数据；若在上一段信息发送结束后，同时有两个或两个以上的节点都提出发送请求，则判定为冲突。若侦听到冲突，则立即停止发送数据，等待一段随机时间，再重新尝试。

其原理简单总结为：先听后发，边发边听，冲突停发，随机延迟后重发

CSMA/CD采用IEEE 802.3标准。

它的主要目的是：提供寻址和媒体存取的控制方式，使得不同设备或网络上的节点可以在多点的网络上通信而不相互冲突。

有人将CSMA/CD的工作过程形象的比喻成很多人在一间黑屋子中举行讨论会，参加会议的人都是只能听到其他人的声音。每个人在说话前必须先倾听，只有等会场安静下来后，他才能够发言。人们将发言前监听以确定是否已有人在发言的动作成为”载波侦听”；将在会场安静的情况下每人都有平等机会讲话成为”多路访问”；如果有两人或两人以上同时说话，大家就无法听清其中任何一人的发言，这种情况称为发生”冲突”。发言人在发言过程中要及时发现是否发生冲突，这个动作称为”冲突检测”。如果发言人发现冲突已经发生，这时他需要先大喊一声再停止讲话，然后随机后退延迟，再次重复上述过程，直至讲话成功。如果失败次数太多，他也许就放弃这次发言的想法。通常尝试16次后放弃。

CSMA/CD控制方式的优点是：原理比较简单，技术上易实现，网络中各工作站处于平等地位，不需集中控制，不提供优先级控制。但在网络负载增大时，发送时间增长，发送效率急剧下降。

【经验之谈】这里其实还有一个细节问题，那就是站点要多长时间才能检测到有冲突发生。理论上多数人认为是一倍于数据信号传播时延，认为在一个完整的数据帧载波信号传播过程中没有遇到冲突，就认为没有冲突发生。但事实上这是不正确的，而是要两倍于传播时延，因为可能就在一个传播时延结束时对方站点也开始了数据传输，这时同样会遇到冲突，而且冲突信号要传送到原来发送数据的站点时也需要一个传播时延，所以结果就是需要两倍于传播时延。

1.12 协议过程

控制规程

控制规程的核心问题：解决在公共通道上以广播方式传送数据中可能出现的问题（主要是数据碰撞问题）

控制过程包含四个处理内容：侦听、发送、检测、冲突处理

（1）侦听：

通过专门的检测机构，在站点准备发送前先侦听一下总线上是否有数据正在传送（线路是否忙）？

若”忙”则进入后述的”退避”处理程序，进而进一步反复进行侦听工作。

若”闲”，则根据一定算法原则（”X坚持”算法）决定如何发送。

（2）发送：

当确定要发送后，通过发送机构，向总线发送数据。

（3）检测：

数据发送后，也可能发生数据碰撞。因此，要对数据边发送，边检测，以判断是否冲突了。

（4）冲突处理：

当确认发生冲突后，进入冲突处理程序。有两种冲突情况：

① 侦听中发现线路忙

② 发送过程中发现数据碰撞

① 若在侦听中发现线路忙，则等待一个延时后再次侦听，若仍然忙，则继续延迟等待，一直到可以发送为止。每次延时的时间不一致，由退避算法确定延时值。

② 若发送过程中发现数据碰撞，先发送阻塞信息，强化冲突，再进行侦听工作，以待下次重新发送（方法同①）。

1.13 性能指标

CSMA/CD哥哥参数指标可以概括如下：

性能指标：信道利用率、吞吐量、介质利用率

CSMA/CD的主要影响因素：传播时延、工作站数。

①CSMA/CD对站点个数不是很敏感，对实际的输入负载比较敏感。

②CSMA/CD对传播时延α比较敏感。

③CSMA/CD冲突不可避免。

④CSMA/CD的介质利用率随α的上升下降较快。

⑤CSMA/CD适合通信量不大，交互频繁的场合

⑥对于CSMA/CD帧越长，吞吐量越大，要求帧具有最小长度，当有许多短消息时，带宽浪费严重。

⑦CSMA/CD在轻负载时提供最短延迟，但对重负载敏感。

主要参数：

时间片512比特时间

帧间间隔9．6微秒

尝试极限16

退避极限10

人为干扰长32比特

最大帧长1518字节

最小帧长64字节

地址字段长48比特

1.14 退避算法

2.2中两种冲突情况都会涉及一个共同算法——退避算法。

①退避算法：当出现线路冲突时，如果冲突的各站点都采用同样的退避间隔时间，则很容易产生二次、三次的碰撞。因此，要求各个站点的退避间隔时间具有差异性。这要求通过退避算法来实现。

截断的二进制指数退避算法（退避算法之一）：

当一个站点发现线路忙时，要等待一个延时时间M，然后再进行侦听工作。延时时间M以以下算法决定：

M = 0 ~ (2^k – 1) 之间的一个随机数乘以512比特时间（例如对于10Mbps以太网，为51.2微秒），k为冲突（碰撞）的次数，M的最大值为1023，即当k=10及以后M始终是0~1023之间的一个随机值与51.2的乘积，当k增加到16时，就发出错误信息。

② 特殊阻塞信息：是一组特殊数据信息。在发送数据后发现冲突时，立即发送特殊阻塞信息（连续几个字节的全1，一般为32-48位），以强化冲突信号，使线路上站点可以尽早探测得到冲突的信号，从而减少造成新冲突的可能性。

③ 冲突检测时间>=2α: α表示网络中最远两个站点的传输线路延迟时间。该式表示检测时间必须保证最远站点发出数据产生冲突后被对方感知的最短时间。在2α时间里没有感知冲突，则保证发出的数据没有产生冲突。（只要保证检测2α时间，没有必要整个发送过程都进行检测）

④ X-坚持的CSMA算法：当在侦听中发现线路空闲时，不一定马上发送数据，而采用X-坚持的CSMA算法决定如何进行数据发送：

算法特点

– 非坚持的CSMA：线路忙，等待一段时间，再侦听；不忙时，立即发送；减少冲突，信道利用率降低：

– 1坚持的CSMA：线路忙，继续侦听；不忙时，立即发送；提高信道利用率，增大冲突：

– p坚持的CSMA：线路忙，继续侦听；不忙时，根据p概率进行发送，另外的1-p概率为继续侦听（p是一个指定概率值）；有效平衡，但复杂：

⑤ 控制流程图：

⑥ CSMA控制规程的特征

① 简单

② 具有广播功能

③ 平均带宽： f = F / n

④ 绝对平等，无优先级

⑤ 低负荷高效，高负荷低效

⑥ 延时时间不可预测

⑦ 传输速率与传输距离为一定值

1.15 算法应用

二进制指数退避算法是按”后进先出”（Last In First Out，LIFO）的次序控制的，即未发生冲突或很少发生冲突的数据帧具有优先发送的概率；而发生过多次冲突的数据帧，发送成功的概率更少。

二进制指数退避算法的规则如下：

对每个帧，当第一次发生冲突时，设置参数L=2。退避重发时间在0或者1个时隙中随机抽取一个再重发。

当帧再次冲突时，退避时间参数的最大值加倍，即是原来L值2的2次方。退避重发时间在0～3（=22-1）个时隙中随机抽取一个再重发。

当冲突n次，由此时的退避时间参数的最大值为最初L值的2^n倍。退避重发时间在0～（2n-1）个时隙中随机抽取一个再重发。可以设置一个最大重传次数，超过此值，不再重发，并报告出错。一般是第10次冲突之后，随机数的时间间隙数就固定在1023上，不再增加了。16次冲突后，就会放弃努力，并且给发送数据的站点返回一个错误报告。

从以上可以看出，退避时间参数值都是参数初始值的2的n次方倍，这也是取名为”二进制指数”退避算法的原因。此算法的效果是不冲突或少冲突的帧重发的机会多，冲突多的帧重发的机会少。

由上述分析可知，为了确保发送数据站点在传输时能及时检测到可能存在的冲突，数据传输时延至少要两倍于信号传播时延（两倍传播时延=一个帧从一个站点开始到达另一个站点所需的一个传播时延+冲突信号到达发送数据的站点所需的一个传播时延），其目的就是不要让数据在全部传输完才收到有冲突发生的信号，这样既浪费了时间，又浪费了带宽。

由此可以得CSMA/CD总线网络中最短帧长的计算关系式如下所示：

最短数据帧长（bit）= 2×数据传输速率（b/s）×两站点间的距离/200（m/μs）

CSMA/CD网络上进行传输时，必须按下列五个步骤来进行：

（1）传输前侦听

（2）如果忙则等待

（3）传输并检测冲突

（4）如果冲突发生，重传前等待

（5）重传或夭折

CSMA/CD 曾经用于各种总线结构以太网（bus topology Ethernet）和双绞线以太网(twisted-pair Ethernet)的早期版本中。

四、附录

4.1 Wireshark 关于802.11无线局域网的过滤器

Type value		Type description	Subtype value	Subtype description	Wireshark display filter
0	Management		0	Association Request	wlan.fc.type_subtype == 0x00
0	Management		1	Association Response	wlan.fc.type_subtype == 0x01
0	Management		10	Reassociation Request	wlan.fc.type_subtype == 0x02
0	Management		11	Reassociation Response	wlan.fc.type_subtype == 0x03
0	Management		100	Probe Request	wlan.fc.type_subtype == 0x04
0	Management		101	Probe Response	wlan.fc.type_subtype == 0x05
0	Management		0110-0111	Reserved
0	Management		1000	Beacon	wlan.fc.type_subtype == 0x08
0	Management		1001	ATIM	wlan.fc.type_subtype == 0x09
0	Management		1010	Disassociation	wlan.fc.type_subtype == 0x0A
0	Management		1011	Authentication	wlan.fc.type_subtype == 0x0B
0	Management		1100	Deauthentication	wlan.fc.type_subtype == 0x0C
0	Management		1101	Action	wlan.fc.type_subtype == 0x0D
0	Management		1110-1111	Reserved

Type value	Type description		Subtype value	Subtype description	Wireshark display filter
1	Control		0000-0111	Reserved
1	Control		1000	Block Ack Request	wlan.fc.type_subtype == 0x18
1	Control		1001	Block Ack	wlan.fc.type_subtype == 0x19
1	Control		1010	PS-Poll	wlan.fc.type_subtype == 0x1A
1	Control		1011	RTS	wlan.fc.type_subtype == 0x1B
1	Control		1100	CTS	wlan.fc.type_subtype == 0x1C
1	Control		1101	ACK	wlan.fc.type_subtype == 0x1D
1	Control		1110	CF-end	wlan.fc.type_subtype == 0x1E
1	Control		1111	CF-end + CF-ack	wlan.fc.type_subtype == 0x1F


Type value	Type description		Subtype value	Subtype description	Wireshark display filter
10	Data		0	Data	wlan.fc.type_subtype == 0x20
10	Data		1	Data + CF-ack	wlan.fc.type_subtype == 0x21
10	Data		10	Data + CF-poll	wlan.fc.type_subtype == 0x22
10	Data		11	Data +CF-ack +CF-poll	wlan.fc.type_subtype == 0x23
10	Data		100	Null	wlan.fc.type_subtype == 0x24
10	Data		101	CF-ack	wlan.fc.type_subtype == 0x25
10	Data		110	CF-poll	wlan.fc.type_subtype == 0x26
10	Data		111	CF-ack +CF-poll	wlan.fc.type_subtype == 0x27
10	Data		1000	QoS data	wlan.fc.type_subtype == 0x28
10	Data		1001	QoS data + CF-ack	wlan.fc.type_subtype == 0x29
10	Data		1010	QoS data + CF-poll	wlan.fc.type_subtype == 0x2A
10	Data		1011	QoS data + CF-ack + CF-poll	wlan.fc.type_subtype == 0x2B
10	Data		1100	QoS Null	wlan.fc.type_subtype == 0x2C
10	Data		1101	Reserved	wlan.fc.type_subtype == 0x2D
10	Data		1110	QoS + CF-poll (no data)	wlan.fc.type_subtype == 0x2E
10	Data		1111	Qos + CF-ack (no data)	wlan.fc.type_subtype == 0x2F
11	Reserved		0000-1111	Reserved

开放空间损耗（以dB为单位）＝32.5+20[log10(频率，以GHz为单位)＋log10(距离，以米为单位)]

开放空间损耗受到两种因素的影响：”信号的频率”与”覆盖的距离”。频率越高或距离越长，衰减就越严重。

4.2 802.11无线局域网缩写词及中文含义

ACK (acknowledgment)	应答
AID (association identifier)	关联识别码
AP (accss point)	访问点
ATIM (announceent traffic indication message)	广播传输指示消息
BSA (basic service area)	基本服务区
BSS (basic service set)	基本服务集
BSSID (basic service set identification)	基本服务集识别码
CCA (clera channel assessment)	干净信道评价
CCK (complemenetary code keying)	补码键控
CF (contention free)	无竞争
CFP (contention-free period)	无竞争期
CID (connection identifier)	连接标识符
CP (contention period)	竞争期
CRC (cyclic redundancy code)	循环冗余码
CS (carrier serse)	载波侦听
CTS (clear to send)	允许发送
CW (contention window)	竞争窗口
DA (destination address)	目的地址
DBPSK (differential binary phase shift keying)	差分二进制相移键控
DCE (data communication equipment)	数据通信设备
DCF (distributed coordination function)	分布式协调功能
DCLA (direct current level adjustment)	直接电平调整
DIFS (distributed (coordination function)interframe space)	分布式（协调功能）帧间间隔
DLL (data link layer)	数据链路层
DP (desensitization)	减敏现象
DQPSK (differential quadrature phase shift keying)	差分正交相移键控
DS (ditribution system)	分发系统
DSAP (destination service access point)	目的服务访问点
DSM (distribution system medium）	发系统媒介
DSS (distribution system service)	分发系统服务
DSSS (direct sequence spread spectrum)	直接序列扩频
DTIM (delivery traffic indication message)	交付传输指示信息
ED (energy detection)	能量检测
EIFS (extended interframe space)	扩展帧间间隔
EIRP (equivalent isotropically radiated power)	等效全向辐射功率
ERS (extended rate set)	扩展速率集
ESA (extended service area)	扩展服务域
ESS (extended service set)	扩展服务集
FC (frame control)	帧控制
FCS (frame check sequence)	帧校验序列
FER (frame error ratio)	帧差错率
FH (frequency hopping)	跳帧
FHSS (frequency-hopping spread spectrum)	跳帧扩频
FIFO (first in first out)	先进先出
GFSK (Gaussian frequency shift keying)	高斯频移键控
HEC (Header Error Check)	头部差错校验
HR/DSSS (High Rate direct sequence spreadd spectrum using the Long Preamble and header)	使用长前导和长头部的高速直接序列扩频
HR/DSSS/short (High Rate direct sequence spreadd spectrum using the optional Short Preamble and header mode)	使用可选的短前导和短头部的高速直接序列扩频
HR/DSSS/PBCC (High Rate direct sequence spreadd spectrum using the optional packet
binary convolutional coding mode and the Long Preamble and header)	使用可选分组二进制卷积编码方式和长前导和长头部的高速直接序列扩频
HR/DSSS/PBCC/short (High Rate direct sequence spreadd spectrum using the optional packet binary convolutional coding mode and the optional Short Preamble and header)	使用可选分组二进制卷积编码方式和可选短前导和短头部的高速直接序列扩频

IBSS (independent basic service set)	独立基本服务集
ICV (integrity check calue)	完整性检验值
IDU　(inteface data unit)	接口数据单元
IFS (interframe space)	帧间间隔
IMP (intermodulation)	互调保护
IR (infrared)	红外线（的）
ISM (industrial,scientific.and medical)	工业　科学　医疗
IV (initialization vector)	初始化矢量
LAN (local area network)	局域网
LLC (logical link control)	逻辑链路控制
LME (layer management entity)	层管理实体
LRC (long retry count)	长重发计数器
LSB (least significant bit)	最低位比特
MAC (medium access control)	媒介访问控制
MDF (management-defined field)	管理定义域
MIB (management information base)	管理信息库协议层管理实体
MMPDU (MAC management protocol data unit)	媒介访问控制管理协议数据单元
MPDU (MAC protocol data unit)	媒介访问控制协议数据单元
MSB(most significant bit)	最高位比特
MSDU(MAC service data unit)	媒介访问控制服务数据单元
N/A(not applicable)	不可用
NAV(network allocation vector)	网络分配矢量
PC(point coordinator)	集中协调器
PCF(point coordination function)	集中协调功能
PDU(protocol data unit)	协调数据单元
PHY(physical [layer])	物理层
PHY-SAP(physical layer service access point)	物理层服务访问点
PIFS(point [coordination function] interframe space)	集中协调功能帧间间隔
PLCP(physical layer convergence protocol)	物理层收敛协议
PLME(physical layer management entity)	物理层管理实体
PMD(physical edium dependent)	物理媒介依赖
PMD-SAP(physical medium dependent service access point)	物理媒介依赖服务访问点
PN(pseudo-noise [code sequence])	随机噪声（码序列）
PPDU(PLCP protocol data unit)	物理层收敛协议协议数据单元
ppm(paresper million)	百万分率，百万分之……
PPM(pulse position modulation)	脉冲相位调制
PRNG(pseudo-random number generator)	随机号码发生器
PS(power save [mode])	节能（模式）
PSDU(PLCP SDU)	物理层收敛协议服务数据单元
RA(receiver address)	接收地址
RF(radio frequency)	射频
RTS(request to send)	请求发送（发送请求）
RSSI(received signal strength indication)	接收信号强度指示
RX(receive or receiver)	接收或者接收机
SA(source address)	源地址
SAP(service access point)	服务访问点
SDU(service data unit)	服务数据单元
SFD(start frame delimiter)	开始帧分隔符
SLRC(station long retry count)	站点长和和重传计数器
SIFS(short interframe space)	短帧间间隔
SME(station management entity)	站点管理实体
SMT(station management)	站点管理
SQ(signal quality [PN code correlation strength])	信号质量（PN码相关长强度）
SRC(short retry count)	短重传计数器
SS(station service)	站点服务
SSAP(source service access point)	源服务访问点
SSID(service set identifier)	服务集识别码
SSRC(station short retry count)	站点短和重传计数器
STA(station)	站点
TA(transmitter address)	发送地址
TBTT(target beacon transmission time)	目标信标发送间隔时间
TIM(traffic indication map)	传输指示图
TSF(timing synchronization funcgion)	定时同步功能
TU(time unit)	时间单位
TX(transmit or transmitter)	发送或者发送机
TXE(transmit enable)	发送使能
UCT(unconditional transition)	无条件转移
WAN(wide area network)	广域网
WDM(wireless distribution media)	无线分发媒介
WDS(wireless distribution system)	无线分布式系统
WEP(wired equivalent privacy)	有线等效加密
WM(wireless medium)	无线媒介

原文出处：http://blog.sinthink.cn/2016/02/13/%E5%85%B3%E4%BA%8E-802-11-%E5%8D%8F%E8%AE%AE/

由衷的感谢原文作者，在此致以真诚的谢意！

收起

展开全文

80211

原创 | 分布式事务科普（终结篇）

千次阅读 2020-04-11 10:08:00

一条Update的SQL，则需要全局事务XID获取（与TC通讯）、before image（解析SQL，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些...

 
 点击上方“朱小厮的博客”，选择“设为星标” 
 后台回复"高效Java"领取《Effective Java第三版》 
 当当优惠码：V54PW7，可减￥30 
 欢迎跳转到本文的原文链接：https://honeypps.com/architect/introduction-of-distributed-transaction/ 
  
 《分布式事务科普》是我在YiQing期间整理的一篇科普型文章，内容共计两万五千字左右，应该算是涵盖了这个领域的大多数知识点。篇幅较长，遂分为上下两篇发出。上篇为《分布式事务科普——初识篇》：ACID、事务隔离级别、MySQL事务实现原理、CAP、BASE、2PC、3PC等（昨天已经发出，有需要的同学可以跳转）。下篇为《分布式事务科普——终结篇》，详细讲解分布式事务的解决方案：XA、AT、TCC、Saga、本地消息表、消息事务、最大努力通知等。 
 分布式事务科普 
 随着业务的快速发展、业务复杂度越来越高，传统单体应用逐渐暴露出了一些问题，例如开发效率低、可维护性差、架构扩展性差、部署不灵活、健壮性差等等。而微服务架构是将单个服务拆分成一系列小服务，且这些小服务都拥有独立的进程，彼此独立，很好地解决了传统单体应用的上述问题，但是在微服务架构下如何保证事务的一致性呢？本文首先从事务的概念出来，带大家先回顾一下ACID、事务隔离级别、CAP、BASE、2PC、3PC等基本理论（参考上篇《分布式事务科普——初识篇》），然后再详细讲解分布式事务的解决方案：XA、AT、TCC、Saga、本地消息表、消息事务、最大努力通知等。 
 分布式事务解决方案 
 在引入分布式事务前，我们最好先明确一下我们是否真的需要分布式事务。有可能因为过度设计致使微服务过多，从而不得不引入分布式事务，这个时候就不建议你采用下面的任何一种方案，而是把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。 
 常见的分布式事务方案有：XA、AT、TCC、Saga、本地消息表、MQ消息事务、最大努力通知等。 
 X/Open DTP模型与XA 
 X/Open，即现在的open group，是一个独立的组织，主要负责制定各种行业技术标准。官网地址：http://www.opengroup.org/。X/Open组织主要由各大知名公司或者厂商进行支持，这些组织不光遵循X/Open组织定义的行业技术标准，也参与到标准的制定。 
 DTP全称是Distributed Transaction Process，即分布式事务模型。在DTP本地模型实例中包含3个部分：AP、TM和RM，如下图所示。其中，AP 可以和TM 以及 RM 通信，TM 和 RM 互相之间可以通信。 
 
  AP（Application Program，应用程序）：AP定义事务边界（定义事务开始和结束）并访问事务边界内的资源。
 
 RM（Resource Manager，资源管理器）：RM管理着某些共享资源的自治域，比如说一个MySQL数据库实例。在DTP里面还有两个要求，一是RM自身必须是支持事务的，二是RM能够根据全局（分布式）事务标识（GTID之类的）定位到自己内部的对应事务。
 
 TM（Transaction Manager，事务管理器）：TM能与AP和RM直接通信，协调AP和RM来实现分布式事务的完整性。负责管理全局事务，分配全局事务标识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
 
 AP和RM之间则通过RM提供的Native API 进行资源控制，这个没有进行约API和规范，各个厂商自己实现自己的资源控制，比如Oracle自己的数据库驱动程序。 
 DTP模型里面定义了XA接口，TM 和 RM 通过XA接口进行双向通信（这也是XA的主要作用， 除此之外，XA还对两阶段提交协议进行了部分优化），例如：TM通知RM提交事务或者回滚事务，RM把提交结果通知给TM。XA 的全称是eXtended Architecture，它是一个分布式事务协议，它通过二阶段提交协议保证强一致性。 
 
 其过程大致如下： 
  第一阶段：TM请求所有RM进行准备，并告知它们各自需要做的局部事务（Transaction Branch）。RM收到请求后，如果判断可以完成自己的局部事务，那就持久化局部事务的工作内容，再给TM肯定答复；要是发生了其他情况，那给TM的都是否定答复。在发送了否定答复并回滚了局部事务之后，RM才能丢弃持久化了的局部事务信息。
 
 第二阶段：TM根据情况（比如说所有RM Prepare成功，或者，AP通知它要Rollback等），先持久化它对这个全局事务的处理决定和所涉及的RM清单，然后通知所有涉及的RM去提交或者回滚它们的局部事务。RM们处理完自己的局部事务后，将返回值告诉TM之后，TM才可以清除掉包括刚才持久化的处理决定和RM清单在内的这个全局事务的信息。
 
 基于XA协议实现的分布式事务是强一致性的分布式事务，典型应用场景如JAVA中有关分布式事务的规范如JTA（Java Transaction API）和JTS（Java Transaction Service）中就涉及到了XA。 
 XA 协议通常实现在数据库资源层，直接作用于资源管理器上。因此，基于 XA 协议实现的分布式事务产品，无论是分布式数据库还是分布式事务框架，对业务几乎都没有侵入，就像使用普通数据库一样。 
 不过XA的使用并不广泛，究其原因主要有以下几类： 
  性能，如：阻塞性协议，增加响应时间、锁时间、死锁等因素的存在，在高并发场景下并不适用。
 
 支持程度，并不是所有的资源都支持XA协议；在数据库中支持完善度也有待考验，比如MySQL 5.7之前都有缺陷（MySQL 5.0版本开始支持XA，只有当隔离级别为SERIALIZABLE的时候才能使用分布式事务）。
 
 运维复杂。
 
 Seata与AT模式 
 AT（Automatic Transaction）模式是基于XA事务演进而来，核心是对业务无侵入，是一种改进后的两阶段提交，需要数据库支持。AT最早出现在阿里巴巴开源的分布式事务框架Seata中，我们不妨先简单了解下Seata。 
 Seata简介 
 Seata（Simple Extensible Autonomous Transaction Architecture，一站式分布式事务解决方案）是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。 
 
 Seata 内部定义了 3个模块来处理全局事务和分支事务的关系和处理过程，如上图所示，分别是 TM、RM 和 TC。其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。 Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。 Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。 Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚 
 
  Transaction Coordinator（TC）：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
 
 Transaction Manager（TM）：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
 
 Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
 
 参照上图，简要概括整个事务的处理流程为： 
  TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播；
 
 RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；
 
 TM要求TC提交或回滚XID的相应全局事务。
 
 TC在XID的相应全局事务下驱动所有分支事务以完成分支提交或回滚。
 
 Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。这个小节我们主要来讲述一下AT模式的实现方式，TCC和Saga模式在后面会继续介绍。 
 AT模式 
 Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，那它们之间有什么不同呢？ 
 我们都知道 XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，这也是它没有在互联网公司流行的重要因素。 
 
 基于 XA 协议以上的问题，Seata 另辟蹊径，既然在依赖数据库层会导致这么多问题，那我们就从应用层做手脚，这还得从 Seata 的 RM 模块说起，前面也说过 RM 的主要作用了，其实 RM 在内部做了对数据库操作的代理层。如上图所示，在使用 Seata 时，我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，主要是解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，并将 undo log 日志插入 undo_log 表中，保证每条更新数据的业务 SQL都有对应的回滚日志存在。 
 这样做的好处就是，本地事务执行完可以立即释放本地事务锁定的资源，然后向 TC 上报分支状态。当 TM 决议全局提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成；当 TM 决议全局回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后执行回滚日志完成回滚操作。 
 
 如上图（左），XA 方案的 RM 是放在数据库层的，它依赖了数据库的 XA 驱动程序。而上图（右），Seata 的 RM 实际上是已中间件的形式放在应用层，不用依赖数据库对协议的支持，完全剥离了分布式事务方案对数据库在协议支持上的要求。 
 AT模式下是如何做到对业务无侵入，又是如何执行提交和回滚的呢？ 
 第一阶段 
 参照下图，Seata 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志（undo log），利用本地事务的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个本地事务中提交。这样可以保证任何提交的业务数据的更新一定有相应的回滚日志存在，最后对分支事务状态向 TC 进行上报。基于这样的机制，分支的本地事务便可以在全局事务的第一阶段提交，马上释放本地事务锁定的资源。 
 
 第二阶段 
 如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），第二阶段可以非常快速地结束，参考下图。 
 
 如果决议是全局回滚，RM收到协调器发来的回滚请求，通过XID和Branch ID找到相应的回滚日志记录，通过回滚记录生成反向的更新SQL并执行，以完成分支的回滚，参考下图。 
 
 讲到这里，关于AT模式大部分问题我们应该都清楚了，但总结起来，核心也只解决了一件事情，就是ACID中最基本、最重要的 A（原子性）。但是，光解决A显然是不够的：既然本地事务已经提交，那么如果数据在全局事务结束前被修改了，回滚时怎么处理？ACID 的 I（隔离性）在Seata的AT模式是如何处理的呢？ 
 Seata AT 模式引入全局锁机制来实现隔离。全局锁是由 Seata 的 TC 维护的，事务中涉及的数据的锁。 
 写隔离 
 参考官网（https://seata.io/en-us/docs/overview/what-is-seata.html）的资料，写隔离的要领如下： 
  第一阶段本地事务提交前，需要确保先拿到全局锁 。
 
 拿不到全局锁，不能提交本地事务。
 
 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
 
 以一个示例来说明。两个全局事务tx1和tx2，分别对a表的m字段进行更新操作，m的初始值1000。tx1先开始，开启本地事务拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁，本地提交释放本地锁。tx2后开始，开启本地事务拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁，tx1全局提交前，该记录的全局锁被 tx1持有，tx2需要重试等待全局锁 。 
 
 tx1 第二阶段全局提交，释放全局锁 。tx2拿到全局锁提交本地事务。 
 如果tx1的第二阶段全局回滚，则tx1需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。 
 参考下图，此时如果tx2仍在等待该数据的全局锁，同时持有本地锁，则tx1的分支回滚会失败。分支的回滚会一直重试，直到tx2的全局锁等锁超时，放弃全局锁并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。 
 
 因为整个过程全局锁在tx1结束前一直是被tx1持有的，所以不会发生脏写的问题。 
 读隔离 
 在数据库本地事务隔离级别为读已提交（READ COMMITTED）或以上的基础上，Seata（AT模式）的默认全局隔离级别是读未提交（READ UNCOMMITTED）。如果应用在特定场景下，必需要求全局的读已提交，目前Seata的方式是通过SELECT FOR UPDATE语句的代理。 
 SELECT FOR UPDATE语句的执行会申请全局锁 ，如果全局锁被其他事务持有，则释放本地锁（回滚SELECT FOR UPDATE语句的本地执行）并重试。这个过程中，查询是被阻塞 住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。 
 
 全局锁是由 TC 也就是服务端来集中维护，而不是在数据库维护的。这样做有两点好处：一方面，锁的释放非常快，尤其是在全局提交的情况下收到全局提交的请求，锁马上就释放掉了，不需要与 RM 或数据库进行一轮交互；另外一方面，因为锁不是数据库维护的，从数据库层面看数据没有锁定。这也就是给极端情况下，业务降级提供了方便，事务协调器异常导致的一部分异常事务，不会阻塞后面业务的继续进行。 
 AT模式基于本地事务的特性，通过拦截并解析 SQL 的方式，记录自定义的回滚日志，从而打破 XA 协议阻塞性的制约，在一致性、性能、易用性三个方面取得一定的平衡：在达到确定一致性（非最终一致）的前提下，即保障一定的性能，又能完全不侵入业务。在很多应用场景下，Seata的AT模式都能很好地发挥作用，把应用的分布式事务支持成本降到极低的水平。 
 不过AT模式也并非银弹，在使用之前最好权衡好以下几个方面： 
  隔离性。隔离性不高，目前只能支持到接近读已提交的程度，更高的隔离级别，实现成本将非常高。
 
 性能损耗。一条Update的SQL，则需要全局事务XID获取（与TC通讯）、before image（解析SQL，查询一次数据库）、after image（查询一次数据库）、insert undo log（写一次数据库）、before commit（与TC通讯，判断锁冲突），这些操作都需要一次远程通讯RPC，而且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写SQL都会增加这么多开销,粗略估计会增加5倍响应时间（二阶段虽然是异步的，但其实也会占用系统资源，网络、线程、数据库）。
 
 全局锁。Seata在每个分支事务中会携带对应的锁信息，在before commit阶段会依次获取锁（因为需要将所有SQL执行完才能拿到所有锁信息，所以放在commit前判断）。相比XA，Seata 虽然在一阶段成功后会释放数据库锁，但一阶段在commit前全局锁的判定也拉长了对数据锁的占有时间，这个开销比XA的prepare低多少需要根据实际业务场景进行测试。全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。Seata在回滚时，需要先删除各节点的undo log，然后才能释放TC内存中的锁，所以如果第二阶段是回滚，释放锁的时间会更长。Seata的引入全局锁会额外增加死锁的风险，但如果实现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。
 
 TCC 
 关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中，TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司，其注册了TCC商标。 
 TCC分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖资源管理器（RM）对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。 
 TCC 模型认为对于业务系统中一个特定的业务逻辑，其对外提供服务时必须接受一些不确定性，即对业务逻辑初步操作的调用仅是一个临时性操作，调用它的主业务服务保留了后续的取消权。如果主业务服务认为全局事务应该回滚，它会要求取消之前的临时性操作，这就对应从业务服务的取消操作。而当主业务服务认为全局事务应该提交时，它会放弃之前临时性操作的取消权，这对应从业务服务的确认操作。每一个初步操作，最终都会被确认或取消。 
 因此，针对一个具体的业务服务，TCC 分布式事务模型需要业务系统提供三段业务逻辑： 
  Try：完成所有业务检查，预留必须的业务资源。
 
 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要Try操作成功，Confirm必须能成功。另外，Confirm操作需满足幂等性，保证分布式事务有且只能成功一次。
 
 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。
 
 
 TCC分布式事务模型包括三部分： 
  主业务服务（Main Server）：主业务服务为整个业务活动的发起方、服务的编排者，负责发起并完成整个业务活动。
 
 从业务服务（Service）：从业务服务是整个业务活动的参与方，负责提供TCC业务操作，实现Try、Confirm、Cancel三个接口，供主业务服务调用。
 
 事务管理器（Transaction Manager）：事务管理器管理控制整个业务活动，包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的Confirm操作，在业务活动取消时调用所有从业务服务的Cancel操作。
 
 
 上图所展示的是TCC事务模型与DTP事务模型的对比图，看上去这两者差别很大。聪明的读者应该可以从图中的着色上猜出些端倪，其实这两者基本一致：TCC模型中的主业务服务相当于DTP模型中AP，从业务服务相当于DTP模型中的RM，两者也都有一个事务管理器；TCC模型中从业务服务器所提供的Try/Commit/Cancel接口相当于DTP模型中RM提供的Prepare/Commit/Rollback接口。 
 所不同的是DTP模型中Prepare/Commit/Rollback都是由事务管理器调用，TCC模型中的Try接口是由主业务服务调用的，二阶段的Commit/Cancel才是由事务管理器调用。这就是TCC事务模型的二阶段异步化功能，从业务服务的第一阶段执行成功，主业务服务就可以提交完成，然后再由事务管理器框架异步的执行各从业务服务的第二阶段。这里牺牲了一定的隔离性和一致性的，但是提高了长事务的可用性。 
 下面我们再来了解一下一个完整的TCC分布式事务流程： 
  主业务服务首先开启本地事务。
 
 主业务服务向事务管理器申请启动分布式事务主业务活动。
 
 然后针对要调用的从业务服务，主业务活动先向事务管理器注册从业务活动，然后调用从业务服务的 Try 接口。
 
 当所有从业务服务的 Try 接口调用成功，主业务服务提交本地事务；若调用失败，主业务服务回滚本地事务。
 
 若主业务服务提交本地事务，则TCC模型分别调用所有从业务服务的Confirm接口；若主业务服务回滚本地事务，则分别调用 Cancel 接口；
 
 所有从业务服务的Confirm或Cancel操作完成后，全局事务结束。
 
 用户接入TCC，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。下面，我们从一个简答的例子来熟悉一下TCC的具体用法。 
 以“扣钱”场景为例，在接入TCC前，对A账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入TCC之后，用户就需要考虑如何将原来一步就能完成的扣钱操作拆成两阶段，实现成三个方法，并且保证Try成功Confirm一定能成功。 
 如下图所示，一阶段Try方法需要做资源的检查和预留。在扣钱场景下，Try要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结A账户的转账资金。Try方法执行之后，账号A余额虽然还是100，但是其中30元已经被冻结了，不能被其他事务使用。 
 
 二阶段Confirm执行真正的扣钱操作。Confirm会使用Try阶段冻结的资金，执行账号扣款。Confirm执行之后，账号A在一阶段中冻结的30元已经被扣除，账号A余额变成 70 元 。 
 如果二阶段是回滚的话，就需要在Cancel方法内释放一阶段Try冻结的30元，使账号A的回到初始状态，100元全部可用。 
 在TCC模型中，事务的隔离交给业务逻辑来实现。其隔离性思想就是通过业务的改造，在第一阶段结束之后，从底层数据库资源层面的加锁过渡为上层业务层面的加锁，从而释放底层数据库锁资源，放宽分布式事务锁协议，将锁的粒度降到最低，以最大限度提高业务并发性能。 
 以上面的例子举例，账户A上有100元，事务tx1要扣除其中的30元，事务tx2也要扣除30元，出现并发。在第一阶段的Try操作中，需要先利用数据库资源层面的加锁，检查账户可用余额，如果余额充足，则预留业务资源，扣除本次交易金额。一阶段结束后，虽然数据库层面资源锁被释放了，但这笔资金被业务隔离，不允许除本事务之外的其它并发事务动用。 
 补偿性事务 
 TCC第一阶段的Try或者第二阶段的Confirm/Cancel在执行过程中，一般都会开启各自的本地事务，来保证方法内部业务逻辑的ACID特性。这里Confirm/Cancel执行的本地事务是补偿性事务。 
 补偿性事务是一个独立的支持ACID特性的本地事务，用于在逻辑上取消服务提供者上一个ACID事务造成的影响，对于一个长事务(long-running transaction)，与其实现一个巨大的分布式ACID事务，不如使用基于补偿性的方案，把每一次服务调用当做一个较短的本地ACID事务来处理，执行完就立即提交。 
 TCC第二阶段Confirm/Cancel执行的补偿性事务用于取消Try阶段本地事务造成的影响。因为第一阶段Try只是预留资源，之后必须要明确的告诉服务提供者，这个资源到底要还需不需要。下一节中所要讲述的Saga也是一种补偿性的事务。 
 TCC异常控制 
 在有了一套完备的 TCC 接口之后，是不是就真的高枕无忧了呢？答案是否定的。在微服务架构下，很有可能出现网络超时、重发，机器宕机等一系列的异常情况。一旦遇到这些 情况，就会导致我们的分布式事务执行过程出现异常，最常见的主要是空回滚、幂等、悬挂。因此，在TCC接口设计中还需要处理好这三个问题。 
 Cancel接口设计时需要允许空回滚。在Try接口因为丢包时没有收到，事务管理器会触发回滚，这时会触发Cancel接口，这时Cancel执行时发现没有对应的事务 XID或主键时，需要返回回滚成功。让事务服务管理器认为已回滚，否则会不断重试，而Cancel又没有对应的业务数据可以进行回滚。 
 幂等性的意思是对同一个系统使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。因为网络抖动或拥堵可能会超时，事务管理器会对资源进行重试操作，所以很可能一个业务操作会被重复调用，为了不因为重复调用而多次占用资源，需要对服务设计时进行幂等控制，通常我们可以用事务XID或业务主键判重来控制。 
 悬挂的意思是Cancel比Try接口先执行，出现的原因是Try由于网络拥堵而超时，事务管理器生成回滚，触发Cancel接口，而最终又收到了Try接口调用，但是Cancel比Try先到。按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的Try接口不应该执行，否则会产生数据不一致，所以我们在Cancel空回滚返回成功之前先记录该条事务 XID或业务主键，标识这条记录已经回滚过，Try接口先检查这条事务XID或业务主键如果已经标记为回滚成功过，则不执行Try的业务操作。 
 总结 
 XA两阶段提交是资源层面的，而TCC实际上把资源层面二阶段提交上提到了业务层面来实现，有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能低下问题。TCC也没有AT模式中的全局行锁，所以性能也会比AT模式高很多。不过，TCC模式对业务代码有很大的侵入性，主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。 
 Saga 
 Saga 算法（https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf）于 1987 年提出，是一种异步的分布式事务解决方案。其理论基础在于，其假设所有事件按照顺序推进，总能达到系统的最终一致性，因此 Saga需要服务分别定义提交接口以及补偿接口，当某个事务分支失败时，调用其它的分支的补偿接口来进行回滚。 
 在Saga模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。 
 
 分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。 
 Saga模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。 
 Saga模式不保证事务的隔离性，在极端情况下可能出现脏写。比如在分布式事务未提交的情况下，前一个服务的数据被修改了，而后面的服务发生了异常需要进行回滚，可能由于前面服务的数据被修改后无法进行补偿操作。一种处理办法可以是“重试”继续往前完成这个分布式事务。由于整个业务流程是由状态机编排的，即使是事后恢复也可以继续往前重试。所以用户可以根据业务特点配置该流程的事务处理策略是优先“回滚”还是“重试”，当事务超时的时候，服务端会根据这个策略不断进行重试。 
 由于Saga不保证隔离性，所以我们在业务设计的时候需要做到“宁可长款，不可短款”的原则，长款是指在出现差错的时候站在我方的角度钱多了的情况，钱少了则是短款，因为如果长款可以给客户退款，而短款则可能钱追不回来了，也就是说在业务设计的时候，一定是先扣客户帐再入帐，如果因为隔离性问题造成覆盖更新，也不会出现钱少了的情况。 
 Saga模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供TCC要求的接口，也可以使用Saga模式。 
 Saga模式所具备的优势有：一阶段提交本地数据库事务，无锁，高性能；参与者可以采用事务驱动异步执行，高吞吐；补偿服务即正向服务的“反向”，易于理解、易于实现；不过，Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。 
 一个好的分布式事务应用应该尽可能满足： 
  提高易用性、即降低业务改造成本。
 
 性能损耗低。
 
 隔离性保证完整。但如同CAP，这三个特性是相互制衡的，往往只能满足其中两个，我们可以搭配AT、TCC和Saga来画一个三角约束：
 
 
 本地消息表 
 本地消息表最初是由eBay架构师Dan Pritchett在一篇解释 BASE 原理的论文《Base：An Acid Alternative》（https://queue.acm.org/detail.cfm?id=1394128）中提及的，业界目前使用这种方案是比较多的，其核心思想是将分布式事务拆分成本地事务进行处理。 
 方案通过在事务主动发起方额外新建事务消息表，事务发起方处理业务和记录事务消息在本地事务中完成，轮询事务消息表的数据发送事务消息，事务被动方基于消息中间件消费事务消息表中的事务。 
 下面把分布式事务最先开始处理的事务方称为事务主动方，在事务主动方之后处理的业务内的其他事务称为事务被动方。事务的主动方需要额外新建事务消息表，用于记录分布式事务的消息的发生、处理状态。 
 
 参考上图，我们不妨来聊一聊本地消息表的事务处理流程。 
 事务主动方处理好相关的业务逻辑之后，先将业务数据写入数据库中的业务表（图中步骤1），然后将所要发送的消息写入到数据库中的消息表（步骤2）。注意：写入业务表的逻辑和写入消息表的逻辑在同一个事务中，这样通过本地事务保证了一致性。 
 之后，事务主动方将所要发送的消息发送到消息中间件中（步骤3）。消息在发送过程中丢失了怎么办？这里就体现出消息表的用处了。在上一步中，在消息表中记录的消息状态是“发送中”，事务主动方可以定时扫描消息表，然后将其中状态为“发送中”的消息重新投递到消息中间件即可。只有当最后事务被动方消费完之后，消息的状态才会被设置为“已完成”。 
 重新投递的过程中也可能会再次失败，此时我们一般会指定最大重试次数，重试间隔时间根据重试次数而指数或者线性增长。若达到最大重试次数后记录日志，我们可以根据记录的日志来通过邮件或短信来发送告警通知，接收到告警通知后及时介入人工处理即可。 
 前面3个步骤可以避免“业务处理成功，消息发送失败”或者“消息发送成功，业务处理失败”这种棘手情况的出现，并且也可以保证消息不会丢失。 
 事务被动方监听并消费消息中间件中的消息（步骤4），然后处理相应的业务逻辑，并把业务数据写入到自己的业务表中（步骤5），随后将处理结果返回给消息中间件（步骤6）。 
 步骤4-6中可能会出现各种异常情况，事务被动方可以在处理完步骤6之后再向消息中间件ACK在步骤4中读取的消息。这样，如果步骤4-6中间出现任何异常了都可以重试消费消息中间件中的那条消息。这里不可避免的会出现重复消费的现象，并且在前面的步骤3中也会出现重复投递的现象，因此事务被动方的业务逻辑需要能够保证幂等性。 
 最后事务主动方也会监听并读取消息中间件中的消息（步骤7）来更新消息表中消息的状态（步骤8）。 
 步骤6和步骤7是为了将事务被动方的处理结果反馈给事务主动方，这里也可以使用RPC的方式代替。如果在事务被动方处理业务逻辑的过程中发现整个业务流程失败，那么事务被动方也可以发送消息（或者RPC）来通知事务主动方进行回滚。 
 基于本地消息表的分布式事务方案就介绍到这里了，本地消息表的方案的优点是建设成本比较低，其虽然实现了可靠消息的传递确保了分布式事务的最终一致性，其实它也有一些缺陷： 
  本地消息表与业务耦合在一起，难以做成通用性，不可独立伸缩。
 
 本地消息表是基于数据库来做的，而数据库是要读写磁盘IO的，因此在高并发下是有性能瓶颈的。
 
 （欢迎关注公众号：朱小厮的博客） 
 消息事务 
 消息事务作为一种异步确保型事务，其核心原理是将两个事务通过消息中间件进行异步解耦。 
 消息事务的一种实现思路是通过保证多条消息的同时可见性来保证事务一致性。但是此类消息事务实现机制更多的是用在 consume-transform-produce（Kafka支持）场景中，其本质上还是用来保证消息自身事务，并没有把外部事务包含进来。 
 还有一种思路是依赖于 AMQP 协议（RabbitMQ支持）来确保消息发送成功。AMQP需要在发送事务消息时进行两阶段提交，首先进行 tx_select 开启事务，然后再进行消息发送，最后执行 tx_commit 或tx_rollback。这个过程可以保证在消息发送成功的同时，本地事务也一定成功执行。但事务粒度不好控制，而且会导致性能急剧下降，同时也无法解决本地事务执行与消息发送的原子性问题。 
 不过，RocketMQ事务消息设计解决了上述的本地事务执行与消息发送的原子性问题。在RocketMQ的设计中，broker和producer的双向通信能力使得broker天生可以作为一个事务协调者存在。而RocketMQ本身提供的存储机制，则为事务消息提供了持久化能力。RocketMQ 的高可用机制以及可靠消息设计，则为事务消息在系统在发生异常时，依然能够保证事务的最终一致性达成。 
 RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示： 
 
 下面我们来了解一下这个设计的整体流程。 
 首先，事务发起方发送一个Prepare消息到MQ Server中（对应于上图中Step 1和Step 2），如果这个Prepare消息发送失败，那么就直接取消操作，后续的操作也都不再执行。如果这个Prepare消息发送成功了，那么接着执行自身的本地事务（Step 3）。 
 如果本地事务执行失败，那么通知MQ Server回滚（Step 4 - Rollback），后续操作都不再执行。如果本地事务执行成功，就通知MQ Server发送确认消息（Step 4 - Commit）。 
 倘若 Step 4中的Commit/Rollback消息迟迟未送达到MQ Server中呢？MQ Server会自动定时轮询所有的 Prepare 消息，然后调用事务发起方事先提供的接口（Step 5），通过这个接口反查事务发起方的上次本地事务是否执行成功（Step 6）。 
 如果成功，就发送确认消息给 MQ Server；失败则告诉 MQ Server回滚消息（Step 7）。 
 事务被动方会接收到确认消息，然后执行本地的事务，如果本地事务执行成功则事务正常完成。如果事务被动方本地事务执行失败了咋办？基于 MQ 来进行不断重试，如果实在是不行，可以发送报警由人工来手工回滚和补偿。 
 
 上图是采用本地消息表方案和采用RocketMQ事务消息方案的对比图，其实，我们不难发现RocketMQ的这种事务方案就是对本地消息表的封装，其MQ内部实现了本地消息表的功能，其他方面的协议基本与本地消息表一致。 
 RocketMQ 事务消息较好的解决了事务的最终一致性问题，事务发起方仅需要关注本地事务执行以及实现回查接口给出事务状态判定等实现，而且在上游事务峰值高时，可以通过消息队列，避免对下游服务产生过大压力。 
 事务消息不仅适用于上游事务对下游事务无依赖的场景，还可以与一些传统分布式事务架构相结合，而 MQ 的服务端作为天生的具有高可用能力的协调者，使得我们未来可以基于MQ提供一站式轻量级分布式事务解决方案，用以满足各种场景下的分布式事务需求。 
 最大努力通知 
 最大努力通知型（Best-effort Delivery）是最简单的一种柔性事务，适用于一些最终一致性时间敏感度低的业务，且被动方处理结果不影响主动方的处理结果。典型的使用场景：如支付通知、短信通知等。 
 以支付通知为例，业务系统调用支付平台进行支付，支付平台进行支付，进行操作支付之后支付平台会尽量去通知业务系统支付操作是否成功，但是会有一个最大通知次数。如果超过这个次数后还是通知失败，就不再通知，业务系统自行调用支付平台提供一个查询接口，供业务系统进行查询支付操作是否成功。 
 最大努力通知方案可以借助MQ（消息中间件）来实现，参考下图。 
 
 发起通知方将通知发给MQ，接收通知方监听 MQ 消息。接收通知方收到消息后，处理完业务回应ACK。接收通知方若没有回应ACK，则 MQ 会间隔 1min、5min、10min 等重复通知。接受通知方可调用消息校对接口，保证消息的一致性。 
 分布式事务的取舍 
 严格的ACID事务对隔离性的要求很高，在事务执行中必须将所有的资源锁定，对于长事务来说，整个事务期间对数据的独占，将严重影响系统并发性能。因此，在高并发场景中，对ACID的部分特性进行放松从而提高性能，这便产生了BASE柔性事务。柔性事务的理念则是通过业务逻辑将互斥锁操作从资源层面上移至业务层面。通过放宽对强一致性要求，来换取系统吞吐量的提升。另外提供自动的异常恢复机制，可以在发生异常后也能确保事务的最终一致。 
 柔性事务需要应用层进行参与，因此这类分布式事务框架一个首要的功能就是怎么最大程度降低业务改造成本，然后就是尽可能提高性能（响应时间、吞吐），最好是保证隔离性。 
 当然如果我们要自己设计一个分布式事务框架，还需要考虑很多其它特性，在明确目标场景偏好后进行权衡取舍，这些特性包括但不限于以下： 
  业务侵入性（基于注解、XML，补偿逻辑）；
 
 隔离性（写隔离/读隔离/读未提交，业务隔离/技术隔离）；
 
 TM/TC部署形态（单独部署、与应用部署一起）；
 
 错误恢复（自动恢复、手动恢复）；
 
 性能（回滚的概率、付出的代价,响应时间、吞吐）；
 
 高可用（注册中心、数据库）；
 
 持久化（数据库、文件、多副本一致算法）；
 
 同步/异步（2PC执行方式）；
 
 日志清理(自动、手动)；
 
 ......
 
 分布式事务一直是业界难题，难在于CAP定理，在于分布式系统8大错误假设 ，在于FLP不可能原理 ，在于我们习惯于单机事务ACID做对比。无论是数据库领域XA，还是微服务下AT、TCC、Saga、本地消息表、事务消息、最大努力通知等方案，都没有完美解决分布式事务问题，它们不过是各自在性能、一致性、可用性等方面做取舍，寻求某些场景偏好下的权衡。 
  
 欢迎跳转到本文的原文链接：https://honeypps.com/architect/introduction-of-distributed-transaction/ 
 想知道更多？扫描下面的二维码关注我 
  
 后台回复”加群“获取公众号专属群聊入口 
 当当优惠码福利来一波！当当全场自营图书5折，用优惠码：V54PW7（长按复制），满200（原价400）再减30，相当于170=400，四折多一点。使用渠道：当当小程序或当当APP。使用时间：4/10-4/23。 
  
 【精彩推荐】 
  Paxos、Raft不是一致性算法嘛？
 
 越说越迷糊的CAP
 
 面试官居然问我Raft为什么会叫做Raft!
 
 面试官给我挖坑：URI中的//有什么用
 
 网关Zuul科普
 
 网关Spring Cloud Gateway科普
 
 分布式事务科普——初识篇
 
 >>> 字节跳动社招内推入口 <<< 
 >>> 字节跳动校招内推入口 <<< 
 朕已阅

收起

展开全文

Polkadot(波卡链)白皮书

万次阅读 2019-05-16 18:34:55

Polkadot：畅想一种异构的多链架构草案1 Gavin Wood博士以太坊&Parity 创始人 GAVIN@PARITY.IO 摘要：现有的区块链架构都存在诸多问题，不仅仅是从实用性角度所说的扩展性（extensibilty）和伸缩性...

Polkadot：畅想一种异构的多链架构

草案1

Gavin Wood博士

以太坊&Parity 创始人

GAVIN@PARITY.IO

摘要：现有的区块链架构都存在诸多问题，不仅仅是从实用性角度所说的扩展性（extensibilty）和伸缩性（scalability）的问题。我们认为，问题源于把共识架构中两个很重要的部分：一致性（canonicality）和有效性（validity）绑定得太紧密了。这篇文章介绍了一种异构的多链架构，能从本质上把两者拆开。

为了分离这两者，且能保持最小化的绝对安全性（security）和传输性（transport）等基本功能，我们将介绍一种原生的支持内核可扩展（core extensibilty）的可行性方法。对于可伸缩性（scalability）的问题，我们通过对这两个问题分而治之的思路解决，通过非信任节点的激励机制，弱化他们的内生绑定关系。

本架构的异构本质，支持众多高度差异化的共识系统在非信任（trustless）、完全去中心化的联邦内交互操作，允许去信任（trust-free）地相互访问各区块链。

我们提出一种方式，支持向后兼容一个或多个现有的网络，比如以太坊等。我们相信这个系统能够提供一种有用的底层组件，能够实用性地支持全球商业级别的可伸缩性（scalability）和隐私性（privacy）。

1 前言

这篇论文的意图只是一个技术版本的概要，旨在用一些原则来描述将要开发的这个区块链示例，解释这个可能方向的合理性。它罗列了诸多区块链技术方面的具体改善措施，以及在此开发阶段所能够提供的尽可能多的细节。

它并不是要写成一个形式化证明的说明书。它并不完整，也不是最终版本。它并不是为了覆盖框架非核心的模块，例如API、依赖、语言和用法等。这只是概念性实验，都很可能会修改提到的参数。为了响应社区的意见和评论，会新增、重定义、删除各组件。通过实验性的证据和原型，给出关于什么会有效、什么不会的信息，也很可能修正本论文中大部分内容。

这篇论文包含了一个关于协议和一些想法的核心描述，可能会被用来解决多个方面的问题。它将是能够用来在概念验证阶段开展一系列工作的核心描述。一个最终的“1.0版本”会基于这个协议，再添加一些变得可证明而且决定包含到项目中来的想法。

1.1 历史

2016年10月09日：0.1.0-proof1
2016年10月20日：0.1.0-proof2
2016年11月01日：0.1.0-proof3
2016年11月10日：0.1.0

2 介绍

区块链已经承诺了它的伟大意义，能够应用于包括物联网（IOT）、金融、治理、身份管理、去中心化互联网和资产追踪等多个领域。然而抛开这些技术承诺和大话，我们还没有看到现有技术下，出现重大的关于现实世界的应用部署。我们相信这是因为现有技术的5个关键缺陷：

伸缩性（Scalability）：全球范围内花费了多少计算、带宽和存储的资源，来处理单个交易？峰值情况下能处理多少交易？

隔离性（Isolatability）：多参与方对于应用的差异化需求，能否在同一个框架下接近最优程度地满足？

开发性（Developability）：工具的工作效果有多好？APIs是否已满足开发者的需求？教程资料是否可用？是否集成权力？

治理性（Governance）：网络是否保留了能够随着时间进化和适应的灵活性？制定决策能否高度地包容、合理和透明，来提供去中心化系统的高效领导力。

应用性（Applicability）：技术是否真的解决了用户的刚性需求？是否需要其他的中间件来嫁接真实的应用？

当前的工作，我们主要面向前两个问题：伸缩性和隔离性。也就是说，我们相信Polkadot架构可以在这两个方面，提供有意义的改进。

当前，例如Parity以太坊客户端这样的高性能区块链实现，已经可以在消费级高速硬件上每秒处理超过3000笔的交易。然而显示世界的区块链网络却限制在30笔交易每秒的情况下。这种限制主要是源于目前同步（synchronous）的共识机制，需要充分的计算缓冲时间来安全地处理，也就加重了其必须对于慢速硬件的支持。这归咎于其底层的共识架构：状态转换机，或者这种让所有参与方校对和执行交易的方式，在本质上将其逻辑绑定在了共识一致性（canonicalisation）的设计上，或者需要让所有参与方都同意所有的可能性、有效性和历史。

这种说法即适用于类似比特币和以太坊这样的工作量证明（POW）系统，也适用于NXT和比特股这样的权益证明（POS）系统，他们都本质上受制于同一个障碍，但这些共识算法却是个能让区块链成功的简单策略。然而，在一个协议里紧密捆绑这两个结构，我们也就捆绑了多个不同风险偏好、不同伸缩性需求、不同隐私需求的角色和应用。一种特征满足不了所有人的需求。因为这种场景，产生了很多次的广泛呼吁，但网络只能倾向于更保守，服务于少数人，最终导致在创新能力、性能和适应性方面的失败，非常戏剧化。

有一些系统例如公证通（Factom），整个地去除了状态转换机。然而大多数应用场景都需要依赖一个共享的状态机，来支持状态转换的功能。去除它只是隐藏了问题，却没有给出真正替代性的解决方案。

现在看起来清楚了，因此一个合理的方向是：像路由对于可伸缩去中心化计算平台那样，解耦共识组件和状态转换组件。而且不出意外的话，这也是Polkadot解决伸缩性问题的策略。

2.1 协议、实现、网络

和比特币、以太坊一样，Polkadot希望一开始的时候只是个网络协议，并且是运行这一协议的主要公有网络（目前假设）。Polkadot倾向于是个免费和开放的项目，协议在一个知识共享的许可证上制定，代码托管在FLOSS许可证下。这个项目以一种开放的状态开发，接收各方面有用的捐助。一个微意见提交系统（RFCs），但不像Python改进议程那样，会提供一种公众协作参与协议修改和升级的方式。

我们对Polkadot协议的初始实现，将称为Parity Polkadot Platform，会包含协议的完整实现和API接口。像其他Parity的区块链实现一样，PPP会设计成通用目的的区块链技术栈，并不限定于公有网络、私有网络或联盟网络。目前为止的开发已经被包括英国政府在内的几方资助。

但是，这篇论文还是在公有网络的场景下。我们在公有网络下预见的功能，是一个完整设想（比如私有或联盟网）的子集。另外在这个场景下，可以清晰地描述和讨论Polkadot的所有方面。这也是说读者需要知道，在非公有（有权限的）场景下，一些特定的机制（比如和其他公有网络的交互）并不直接和Polkadot相关。

2.2 前人工作

从状态转换中解耦底层的共识，已经私下讨论了两年，在以太坊的最早期的时候Max Kaye就提议过。

一个更复杂的可伸缩方案叫做Chain fibers，这要回溯到2014年6月，在那年底也发表了。它创造了一个关于单个中继链（relay-chain）和多个同构链，可以透明地跨链执行的先例。退相干性（Decoherence）通过交易延迟（latency）来实现，这就使需要更长时间，来处理需要协调系统多个部分的交易。Polkadot借鉴了很多它的架构以及随后跟很多人的讨论，虽然跟它的设计和规定也很不一样。

然而目前并没有运行在生产环境下的系统可以和Polkadot相比，有的也只是提出了些相关性功能，很少有本质层面的细节。这些提议可以归纳为：丢弃或减少状态机全局相关性的系统、试图通过同构分片提供全局相关性的单例状态机系统、目标仅是异构性（heterogeneity）的系统。

2.2.1 没有全局状态的系统

公证通（Factom）演示了个没有有效性的一致性系统，能够高效地记载数据。由于没有全局状态和其带来扩展性问题，它可以被看做是一个可伸缩的方案。然而前面也提到了，严格上来说它只解决了很少的问题。

Tangle是个关于共识系统的概念性尝试。不把交易排序再打包到区块中，而是通过串联的共识得出一个全局的一致性状态改变排序，它在很大程度上抛弃了高度结构化的排序想法，而是推出一个有向无环图，后续的有依赖的交易通过明确的指向，来帮助前面的交易达成一致。对于任意的状态改变，这个依赖图就会很快地变得无法处理，然而对于更简单的UTXO模型，立即就变得合理了。因为系统总是松散地连贯，而且交易通常是相互独立的，大规模的全局并发变得非常自然。使用UTXO模型确实可以让Tangle定位成价值转移的货币系统，而并没有其他的更多通用和可扩展的功能。因为没有了全局依赖性，而和其他系统的交互又需要确定性地知道其状态，这种方法就变得不切实际了。

2.2.2 异构链系统

侧链是个支持比特币主链和附属链之间去信任交互的提案。但并没有任何和侧链进行富（rich）交互的具体规定：交互被限定在允许和侧链之间相互托管对方的资产，也就是行话所说的双向锚定（two-way peg）。最终也是为了做个框架，通过锚定比特币链和其他链，允许在比特币协议之外进行外部交易，为比特币添加附属的外围功能。从这方面讲，侧链系统更多着眼于可扩展性而不是可伸缩性。

根本上将，侧链确实没有关于有效性的条款，从一条链（比如比特币）的代币转到另一条链上，安全性只是寄希望于侧链能否激励矿工来一致性地验证交易。比特币网络的安全性无法简单地在其他链上起作用。进而一个确保比特币矿工联合挖矿（复制他们的一致性算力到侧链上），并且同时验证侧链交易的协议也被提出来了。

Cosmos是个延续侧链思路提出来的多链系统，替换中本聪的PoW共识算法为Jae Know的Tendermint共识算法。本质上，它包含多个使用独立Tendermint实例的区块链（在空间zone中运行），和一个使用去信任通信的中心（hub）链。跨链通信仅限于转移数字资产（也就是代币），而不是任意信息，然而这种跨链通信是可以返回数据和路径的，比如给发送人通知转账的状态。

和侧链一样，空间链上验证人的经济激励问题也没有解决。一般的假设是每个空间链会各自持有通胀增发的支付代币。设计仍然还比较早期，现阶段的也缺乏在全局有效性上建立可伸缩一致性的经济手段细节。然而相比于那些需要强耦合的系统，为了空间链和中心链间的松耦合性，需要给空间链的参数添加更多灵活性。

2.2.3 Casper

目前关于Casper和Polkadot之间，还没有完整的讨论和比较，即使是公平和彻底（也不准确）地描述两者。Casper是正在重塑PoS的共识算法，它研究如何让参与方在最终会确定的分叉上押注。本质上，需要考虑即使是长程攻击的情况下，也要保证应对网络分叉的健壮性，还需考虑基础以太坊模型上的可伸缩性。因此，在本质上Casper协议的目标比Polkadot和以往项目要复杂的多，也偏离了基础的区块链模型。它仍然还没有做出来，不知道将来如何运作，也不知道最终会开发出来的样子。

然而Casper和Polkadot都代表了有趣的新一代协议，对于以太坊的争论，本质上也是他们的终极目标和实现路径上的差异。Casper是以太坊基金会主导的一个项目，只是被设计用来作为PoS协议的替代，没有从本质上打造可伸缩区块链的意愿。关键还需要一次硬分叉来升级，而不能时可扩展的，因此所有的以太坊客户端和用户都需要升级，否则就得留在原来的前途不明朗的分叉上。因此，这类协议在去中心化系统上的部署会很困难，需要紧密的协调。

Polkadot在几方面上不同；首先而且也是最重要的，Polkadot将被设计成完全可扩展和可伸缩的区块链开发、部署和交互测试平台。他将被设计为面向未来的、可以吸收最新的可用区块链技术的平台，且不需要过于复杂的去中心化协调和硬分叉。我们已经预见到了几个应用场景，例如高度加密的联盟链和低区块时间的高频链等，它们不太可能在近期的以太坊上实现。它们最终和以太坊之间的耦合度也会很低，以太坊上也没有支持两者间非信任交互的想法。

简言之，尽管Casper/以太坊2.0和Polkadot有一些相似点，我们相信从本质上它们最终的目标是不一样的，并非竞争，在可预见的将来，两个协议会大概率地并存。

3 概要

Polkadot是一个可伸缩的异构多链系统。这意味着不像以往那些专注于不同程度潜在应用功能的单个区块链实现，Polkadot本身被设计成不提供任何内在的功能应用。Polkadot提供了中继链（relay-chain），在其上可以存在大量的可验证的、全局依赖的动态数据结构。我们称这些平行的结构化的区块链为平行链（parachains），尽管也不要求它们必须是一条链。

换句话说，Polkadot会被设计成一个独立链的集合（例如包含以太坊、以太坊经典、域名币、比特币），除了两个非常重要的点：

合并的安全性
去信任的跨链交易性

这两点也是我们称Polkadot为可伸缩的原因。从原则上，一个问题在Polkadot上被彻底解决了：可以向外扩展，会有非常大数量的平行链。尽管每个平行链在各方面都通过不同的网络模式进行平行管理，但这个系统却有可伸缩的能力。

Polkadot提供了一个尽量简单的架构，把大部分的复杂性都放在了中间件上。这是个刻意的决定，为了试图减少开发的风险，使必备的软件可以在短时间内开发出来，还能对安全性和健壮性持有信心。

3.1 Polkadot的哲学

Polkadot需要提供一个绝对坚实的基座，来在其之上建设下一代共识系统，覆盖从生产级别的成熟设计到初期想法的所有风险。通过对安全性、隔离性、通信能力提供强有力的保证，Polkadot能够允许平行链从一系列特性中选择适合它们自己的。的确，我们预见了各种实验性的经过考虑的区块链特性。

我们看到，传统的高市值区块链（例如比特币和Zcash）、低市值的概念性区块链和接近零手续费的测试网，是并存在一起的。我们看到，全加密的暗黑联盟链和高功能性的开放区块链（例如以太坊）也并存在一起，甚至还为之提供服务。我们看到，实验性的新虚拟机区块链，比如主观时间计费的Wasm区块链，在将难度计算问题从类似以太坊的区块链方式，修改成类似比特币的区块链方式。

为了管理区块链升级，Polkadot将内生支持某种形式的治理结构，很可能基于现有的稳定政治体系，会有一个两院结构，类似于Yellow Paper Council。底层权益代币持有者作为最高权力机构，会有全民投票控制权。为了反映用户的需求、开发人员的需求，我们期望建立一个合理的两院结构，采纳用户的意见（由绑定的验证人决定）、主要客户端开发者和生态系统玩家的意见。代币持有者会保留最高的合法权，可以形成一个最高法庭来参政、议政、替换或解散这个架构，还有那些我们不怀疑的最终需求。

借用一句马克吐温的谚语：“政府和尿布都得经常换，而且理由都一样”。

然而在大范围共识的机制下组织参政会很琐碎，更多关于替换和新增的质的改变，希望既不是通过非自动的弱法令（例如通过块高度和新协议的形式化证明文档的哈希）来达到一致性，也不是通过在核心共识算法中包含一个高效的高级语言，来改变他自身可能需要改变的各个方面。后者是一个最终目标，然而为了落实一个合理的开发路线图，更可能选择前者。

Polkadot看重的主要原理和规则有：

最小：Polkadot需要有尽可能少的功能性。

简单：只要他们可以推给中间件、放在平行链、或用下面要讲的一种优化手段，就不在基础协议里添加多余的复杂性。

通用：没必要在平行链中添加任何要求、约束或限制；Polkadot需要成为共识系统开发的基石，要尽量通过给模型加入最具适应度的扩展和优化。

健壮：Polkadot需要提供一个稳定的基础层。为了经济稳定性，需要采用分散的方法，来降低高额奖励这个攻击向量可能引发的问题。

4 Polkadot的参与方

有四个基本的角色在维持Polkadot网络：收集人（collator）、钓鱼人（fisherman）、提名人（nominator）、验证人（validator）。在Polkadot的一个可能实现里，最后一个角色有可能会被拆分成两个：基础验证人和可用保证人（guarantor），将会在6.5.3节讨论。

图1. Polkadot四个角色的交互

4.1 验证人

验证人有最高权限，帮助在Polkadot网络里打包新区块。验证人需要抵押足够多的押金，因为我们允许其他有资金的提名人推举一个或多个可以代表他们的验证人，所以验证人一部分的押金并不是他们自己所拥有的，而是属于提名人的。

一个验证人必须在高可用和高带宽的机器上运行一个中继链的客户端。每个区块上，节点都必须准备接收一个已提交的平行链上的新区块。这个过程涉及接受、验证、再发布候选区块。验证人的任命是确定性的，但实际上也很难预测。因为不能期望验证人拥有所有平行链的全同步数据，所以他们希望把这个提议平行链新区块的工作指派给第三方，也就是收集人。

不同的验证人小组一旦都确定性地批准了自己所属平行链的新块，他们就必须开始批准中继链自身的区块。这包括更新交易队列的状态（也就是从一个平行链的出队列转移到另一个平行链的入队列）、处理已批准的中继链的交易集合、批准最终的区块、吸收平行链的最终改变。

在我们选择的共识算法下，会惩罚一个没有履行他们职责的验证人。最开始如果不是有意的错误，就只是会扣留他们的奖励，但如果是重复的错误会扣减他们的押金（通过烧毁），例如双向签名（double-signing）或合谋提供一个非法区块等可证明的恶意行为，会导致他们丧失全部的押金（烧毁一小部分，大部分奖励给信息提供方和诚实的验证人）。

在某种程度上，验证人和目前PoW区块链的矿池相似。

4.2 提名人

提名人是一个拥有权益的群体，他们把安全性押金委托给验证人。他们没有更多的角色，除了通过有风险地投放资本来表示：他们信任某个特定的验证人（或群体）可以代表他们维护整个网络。按照他们的入金比例，他们也会受到和验证人总押金同样比例的奖励和扣减。

和下面的收集人一样，提名人和目前PoW网络的矿工相似。

4.3 收集人

交易收集人是帮助验证人制造有效的平行链区块的群体。他们会运行一个特定平行链的全节点，这也意味着他们有全部的必要信息，可以打包新块并执行交易，就跟目前PoW区块链的矿工一样。在正常情况下，他们会收集并执行交易，并创建一个”未密封”（unsealed）的区块，再加上一个零知识证明一起提交给一个或多个当前负责提议（proposing）该平行链区块的验证人。

关于收集人、提名人、验证人的精确关系可能还会修改。起初，我们希望收集人和验证人能够紧密合作，因为可能只有一些（甚至一个）交易量很小的平行链。最初的客户端实现会包含一个RPC接口，来支持一个平行链的收集人节点把可证明的有效平行链区块，无条件地提供给一个（中继链）验证人节点。由于维持所有的全同步平行链的成本越来越高，所以我们设计了附加的结构，有助于分离独立的、经济驱动的、和其他的参与者。

最终，我们希望看到收集人群体为了更多手续费，竞争性地去收集信息。在一段时间内，为了持续增长的份额收益奖励，这些收集人可能只服务于特定的验证人群体。或者自由职业（freelance）的收集人也可以简单地创建一个市场，提供有效的平行链区块，而不是获得立即支付的竞争性份额奖励。同样地，去中心化的提名人群体也会允许多个有抵押的参与者来协调和分担验证人的职责。这种能力保证了参与的开放度，有助于成为更加去中心化的系统。

4.4 钓鱼人

不像其他的两个参与方，钓鱼人并不直接和区块打包的过程相关。他们是独立的“赏金猎人“，激励他们的是一次性的大额奖励。

准确地说，由于钓鱼人的存在，我们才能减少恶意行为的发生，即使发生希望也只是因为私钥不小心泄露了，而不是故意的恶意企图。起这个名字的出发点是考虑到他们期望收益的频率和最终奖励的大小。

钓鱼人只要及时举报并证明至少一个有抵押的参与方存在非法行为，他们就能获得奖励。非法行为包括对两个有相同父块的不同区块进行签名，或在平行链上批准一个无效区块。为了预防由于私钥泄露给钓鱼人所导致的过渡奖励，钓鱼人上报关于单个验证人的非法消息签名的基础奖励是从最小开始的，这个奖励会随着其他钓鱼人上报更多的非法签名而逐渐增加。依据我们基本的安全性假设：至少三分之二的验证人是诚实的，渐近线将设置在66%。

钓鱼人某种程度上和目前区块链系统的全节点相似，他们所需要的资源相对较少，也没必要承诺稳定的在线时间和大的带宽。钓鱼人有如此大的不同，所以他们只需要提交很少的押金。这个押金用于预防浪费验证人计算时间和计算资源的女巫攻击。它是立即可以提现的，很可能不会比等值的几个美金更多，但如果监测到一个不当行为的验证人，可能会收获很大的奖励。

5 设计综述

本章试图给出一个系统的全局完整描述。对系统更加深入的解释会在接下来的一章中给出。

图2：Polkadot的概括性原理图。它展示了收集人收集并且广播用户的交易，也广播候选区块给钓鱼人和验证人。展示了用户提交一个交易，先转移到平行链外部，然后通过中继链再转移到另一个平行链，成为一个可以被那里的账户执行的交易。

5.1 共识

在中继链上，Polkadot通过一个现代的异步（asynchronous）拜占庭容错（BFT）算法达成对有效区块的相互共识。算法受简单的Tendermint和HoneyBadgerBFT启发。后者在有任意网络缺陷的架构下，只要满大部分验证人是诚实的，就能提供了一种高效的容错算法。

也许一个权限证明（PoA）模式的网络就足够了，然而Polkadot是个可以在全开放和公开的场景下部署的网络，不需要信任任何特殊的组织和当权者来维护它，因此我们需要一种管理验证人群体并且激励他们守法的方法。我们选择使用以PoS为基础的共识算法。

5.2 权益证明

我们假设网络可以度量每个账户有多少权益（stake）。为了更轻松地和现有系统对比，我们把度量单位称为“代币”（tokens）。不幸的是由于它仅仅能作为对账户简单的价值度量，也没有任何个性化，因此多种原因使这个术语并不那么理想化。

通过一个被提名的权益证明（Nominated Proof-of-Stake NPos）结构，我们猜想验证人的选举不会很频繁（很可能是一个季度一次，最多一天一次）。通过按比例分配的增发出来的代币（很可能大约10%，最多每年100%）和收集到的交易手续费来进行激励。虽然货币增发一般都会造成通胀，但因为所有代币持有者都有公平参与的机会，所以代币持有者的资产不会随着时间而遭受损失，他们会很开心地参与到该共识机制中来。全网权益证明的开展所需的抵押必须达到一个特定的最小比例。会根据市场机制，达到有效的代币增发这个目标。

验证人严重依赖他们抵押进来的权益。现存验证人的押金会从他们离职的时候开始，要再保留更长时间（也许3个月左右）。这么长的押金冻结期是为了还能惩罚将来的不当行为，直到区块链周期性的检查点到来。不当行为会遭到例如减少奖励等的惩罚，如果是故意破坏网络的完整性，验证人将会损失部分或全部的权益，转移给其他验证人、信息提供者或全部权益持有者（通过烧毁）。例如一个验证人试图同时批准不同分叉上的两个分支（有时也被称为短程攻击），就会被后面的方法鉴别并遭到惩罚。

检查点锁定器（checkpoint latch）能规避长程“无权益抵押”（nothing-at-stake）攻击，防止比一般长度更长的高度危险的链重构（chain-reorganistation）发生。为了保证最新开始同步的客户端不会被误导进错误的链，网络会出现定期的“硬分叉”（最长也就是验证人的押金冻结期），把最近检查点区块的哈希值硬编码（hard-code）进客户端。将来通过逐步递减有限链的长度（finite chainlength），或周期性地重置创世块（genesis-block），这种方法会运行得很好。

5.3 平行链和收集人

每个平行链将给中继链提供同样的安全性保证：平行链的区块头会被包含进中继链的区块中，还还跟着一些确认信息，用来保证不会发生链重构或双重花费（double-spending）。类似于比特币侧链和联合挖矿的安全性保证，Polkadot也强力保证平行链状态交易的有效性。会依据密码学算法，把验证人随机地分成很多个组。一条平行链对应一组，甚至每个块的组也都可能不一样。这个设置意味着中继链至少也要和平行链的出块时间一样短。本文不讨论分组的特定决定方式，可能要么是围绕类似RanDAO的提交-披露（commit-reveal）框架，要么结合平行链前一个区块的密码学哈希值。

这样的验证人组需要提供平行链的候选块，还要保证它们是有效的（否则损失押金）。有效性围绕两个重要的点：第一，它是内生有效的，所有的状态转换被公正地执行，包括引用的外部数据也被公正执行（比如交易）。第二，参与方需要可以简便地访问候选块的任何外部数据，例如外部交易等，然后就可以下载这些数据并手工执行候选块。验证人可以提交没有包含任何外部交易数据的空块（null），如果他们这样做，就要承受奖励减少的风险。他们和收集人在平行链的一个流言（gossip）协议上工作，收集人把交易收集到块里，并且要提供一个非交互的零知识证明（noninteractive zero-knowledge），用来证明本子块的父块是有效的（为该工作收取任何手续费）。

防止垃圾（spam）数据的方法留给了平行链协议自身：中继链本质上不规定“计算资源计量”和“交易费”。本质上也不强制平行链规定相关协议（尽管权益持有者不太可能愿意接纳一个没有提供合理机制的平行链）。这里明确地说明了并不会都像以太坊的手续费规则，也可以类似比特币的区块链手续费模型，或其他任何还没有提出来的垃圾预防模型。

Polkadot的中继链本身将很可能存在一个类似以太坊的账户和状态模型，可能是EVM的衍生版本。因为中继链节点将需要做大量的其他计算，将会通过提高手续费尽量减小交易吞吐量，我们的模型还会包含块大小的限制。

5.4 跨链通信

Polkadot最关键的部分是跨链通信。因为在平行链间可以存在某种信息通道，我们才说Polkadot是可伸缩的多链系统。在Polkadot中，通信可以很简单：一个平行链中的执行交易的时候（依据那条链的逻辑），可以给第二条平行链或中继链转发一个交易。目前生产环境中的区块链外部交易，都只能是完全异步的，他们并没有给它的来源方返回任何信息的原生能力。

图3：一个基本的原理图，展示了路由已提交的交易（“提交”）的主要逻辑

为了保证最小的实现复杂度、最小的风险和最小的平行链架构束缚，这些跨链交易和目前标准的外部交易没有区别。这些交易会有个来源方字段，用来辨别平行链的身份，还有个可以是任意长度的地址。跨链交易需支付的手续费，并不像目前的比特币或以太坊系统那样，而是必须通过来源平行链和目的平行链的谈判逻辑来管理。一个在以太坊的Serenity版本中提出的改进提案，会是一个简单管理这种跨链资源支付的方法，尽管我们假设其他人会提出更先进的方法。

跨链交易的问题可以用一个简单的队列机制解决，这个队列用梅克尔树（Merkle tree）来保证数据真实。中继链的任务是把交易从来源平行链的出队列转移到目的平行链的入队列。已转发的交易会在中继链上被引用，而不是中继链自身的交易。为了预防一个平行链往另一个平行链发送垃圾交易，规定在在前一个块结束后，发送每一个交易时，目标平行链的入队列不能太大。如果区块处理完后，入队列太大，那么目的平行链会被看做是饱和了，接下来的几个块里就不会再路由交易给它，直到入队列降到临界值以下。这些队列在中继链上管理，允许各平行链相互决定他们的饱和度大小。如果再往停滞的目标链发送交易，这样就可以同步地报告失败了（因为不存在返回路径，如果第二个交易也是同样的原因失败了，它可能也不会给来源调用者发送回复，这就需要用到一些其他的恢复方法）。

5.5 Polkadot和以太坊

归功于以太坊的图灵完备特性，至少在简单的可论证的安全性边界内，我们期望Polkadot和以太坊有丰富的交互可能性。简而言之，我们预想到了，从Polkadot出来的交易，可以让验证人先签名，然后再喂给以太坊，在那里通过一个交易转发（transaction-forwarding）合约来解释和执行。反方向，我们也预想到了，从以太坊上的一个“外向合约”（break-out contract）中的特殊格式日志，可以快速地证明一个消息是否真的要被转发。

5.5.1 从Polkadot到以太坊

通过选择一个拜占庭容错算法，验证人经由授权投票产生的一系列权益持有者组成，我们能够获得一个安全的共识机制，用不经常更改的合适数量的验证人。在一个总共有144个验证人的系统内，4s出块时间和900个块的最终性（允许举报、惩罚、修复类似双向投票的恶意行为），一个区块的有效性可以合理地考虑为用最少97个签名证明（144的三分之二再加一）,然后跟着的是60分钟无风险注入的验证时间。

以太坊可以包含一个控制和维护144个签名的“内向合约”（break-in contract），由于椭圆曲线数字签名的验签操作只要花费EVM 3000 gas的计算量，而且因为我们只希望验证操作发生在大多数的验证人里（而不是全体），以太坊确认一个从Polkadot来的指令的基础花费不会超过300,000 gas——仅仅是区块550万gas限制的6%。增加验证人的数量（只有在处理数十个区块链的时候才必要）不可避免地会增加成本，然而很明显可以期望到随着以太坊技术的成熟和架构的改进，交易吞吐量会随着时间而增加。另一个事实是不是所有的验证人都会参与（例如只有最高押金的验证人才会做这个任务）这种结构的限制会比较合理。

假设这些验证人每天轮换（更保守的、更可能接收的是每周，甚至每月），网络给维持这个以太坊转接桥的成本大约是540,000 gas每天，或者按照当前的gas价格，45美金一年。一个通过转接桥的基本转发交易会花费大约$0.11；当然另外的合约计算会耗费更多。通过缓存和捆绑多个交易，内向的交易花费可以简单地分担，减少每个交易的花费。如果一次转发需要凑够20个交易，那么转发一笔基本交易的花费会降低到大约$0.01。

在这个模型中，Polkadot的验证人节点除了签名消息之外只需要再做很少的事情。为了能够把交易路由到以太坊网络里，我们假设任何一个验证人需要属于以太坊网络，更可能的只需提供很少的奖励给第一个在网络上转发消息的人（奖励会支付给交易发起人）。

5.5.2 从以太坊到Polkadot

使用一个叫做日志的概念，把交易从以太坊上转发到Polkadot上。当一个以太坊合约希望派生出一个交易给Polkadot上面的某一个平行链，它只需简单地调用一个特殊的“外向合约”就好。那个外向合约会索取任何必须的费用，然后生成一个日志打印指令，以便于通过梅克尔树和有块头哈希来证明它的存在。

在下面的两个情况中，可以非常简单地证明有效性。原则上，唯一的要求是每个Polkadot节点都要运行一个全同步的标准以太坊节点。然而这本身就是非常重的依赖。一个更轻量的方法是提供一个简单的证明，仅需要包含正确执行该交易所必须知晓的以太坊的那部分状态树，然后再检查日志的有效性。这种类似简单支付验证（SPV-like）的证明不需要提供大量的信息。更方便的是，验证人可能完全不需要自己运行节点，Polkadot内的押金系统能支持第三方参与者来提交块头，因为其他第三方（也就是所说的钓鱼人）也可能提供一个他们块头是无效的证明（具体地说就是状态根和回执根是错误的），所以这些人也冒着损失他们押金的风险。

在一个类似以太坊这样的无最终确定性（non-finalising）的PoW网络上，不可能存在最终可证明的一致性。为了适应这个，程序需要依赖一定的块确认数量，或者直到那个依赖的交易已经在链内某一特定深度了。在以太坊上，这个深度从最脆弱的1个块（网络都还不完全知道）延伸至1200个块（从Frontier上线到以太可交易）。在Homestead的稳定版本上，大部分交易所选择了120个块这个数字，我们也可能会选择相近的参数。

所以我们可以想象Polkadot这边的以太坊接口有一些简单的功能：可以接受以太坊网络的新块头，并能验证它的PoW，可以结合一个有足够深度的块头（还有Polkadot内转发的相应信息），来验证从以太坊那边的外向合约打印出来的特定日志的证明，还可以接收关于之前收到的但还没有确定的块头里包含无效的回执根的证明。

需要有一个转发激励机制，才能够真正地在Polkadot网络里得到以太坊块头的数据（还有任何关于有效性和一致性的SPV证明）。这可能设计成只是个简单的支付行为（由在以太坊那边收集的手续费资助），转给任何能够提供一个有效块头的人。为了能够应对分叉，验证人需要保留最近几千个块的信息，要么由协议原生支持，要么通过中继链上的合约。

5.5.3 Polkadot和比特币

Polkadot和比特币的交互是非常有挑战性的：从两边的网络角度考虑，一个所谓的“双向锚定”架构会非常有用。然而由于比特币的局限性，如何提供一种安全性的锚定个是非常艰难的任务。可以使用类似以太坊的流程，从比特币转发一个交易到Polkadot：由一个受Polkadot验证人控制的“外向地址”（break-out address）来托管转账过来的代币（和附属的数据）。可以通过结合一个确认期，来激励先知（oracles）提供SPV证明，先知们通过标识一个非一致性的区块，来证明一笔交易存在双花的可能。任何在外向地址里托管的比特币原则上也被相同的验证人群体控制。

问题是如何保证这些比特币，是被轮换的验证人集合所控制的。相比于以太坊那样可以根据在合约内任意组合签名规则的方法，比特币的局限性就更多了，大部分的比特币客户端只接受最多3方的多重签名。扩充至36个或者大家希望的最高至上千个的终极提议，在现有的比特币协议里还不可能实现。一个选择是修改比特币的协议来支持这个功能，然而硬分叉在比特币的世界里非常难以安排和讨论。另一个可能性是使用门限（threshold）签名的方法，用密码学的结构来构造一个被被多个私钥片段共同控制的公钥地址，要制造一个有效的签名需要这些人的大部分或全部人都参与。不幸的是，和比特币的ECDSA相比，门限签名计算起来非常耗资源，而且是多项式级别的复杂度（polynomial complexity）。

由于入金的安全根本性由有抵押的验证人决定，所以另一个选择是减少多重签名的私钥持有人数量至只有重度质押的验证人才能参与，这样门限签名就变得可行了（或者最糟糕的情况，也可能直接用比特币的原生多重签名）。由于要预防验证人的非法行为，这个方法会降低可托管的比特币总量。然而这是一个优雅的妥协，可以简单地设置能够安全地在两个网络里的转移的基金总额上限（验证人攻击失败可能会受到的押金损失，和攻击成功可能的会收到的比特币潜在收益对比）

因此，我们认为在现有的比特币框架下，开发出一个能够在两个网络间安全转移比特币的平行链是不现实的，尽管如此，比特币的持有者还可以在不确定的将来协调这些工作。

6 协议细节

本协议可以大致分为三个部分：共识机制、平行链接口、跨链交易路由系统。

6.1 中继链操作

中继链会类似以太坊，也是基于状态的，包含一个账户信息到状态存储的映射关系，其中信息主要包含余额和交易计数器（防止重放）。把账户系统放在这里的目标是：记录每个身份在系统里控制了多少权益。但还有一些值得注意的差异：

不能通过交易部署合约；这是为了让中继链尽量缺乏功能性，不支持公开部署合约。
没有资源计数器（gas）；因为公众能够调用的一些功能是固定的，gas记录系统的原理就不适用了。因此在所有功能中，会使用一个更通用的手续费标准，这样就能更高效地执行那些动态代码，交易格式也会更简单。
会有一些包含特殊功能的默认合约，他们管理交易的自动执行和网络消息的输出。

中继链会有一个基于EVM的虚拟机，但为了最大程度地简化会做很多修改。它会有一些内置合约（类似于地址在1-4之间的那些以太坊合约）运行平台的特定功能，包括共识合约、验证人合约、平行链合约。

如果不用EVM，很有可能会选择Web-Assembly（Wasm）；这样的话，所有结构还是相似的，但是这些基于Wasm的内置合约使用的是通用功能的语言，而不再是EVM上面的那些带有很多限制的不成熟语言。

还可能借鉴目前以太坊上衍生出来的其他方面的概念，例如在Serenity版本中提出来一些改变，比如为了能在一个块里并行执行那些没有状态冲突的交易，将交易的回执格式简化等。

Polkadot有可能会部署一个类似于Serenity的纯净（pure）区块链系统，它不包含链的任何基础协议。但我们觉得这会带来更多的复杂性和开发不确定性，所以不太值得在目前阶段就去实现这么一个更高效且简介的伟大协议。

为了管理共识机制，需要很多小片儿的功能：验证人集合、验证人机制、平行链等。这些都可以放在一个整体的协议中。然而为了实现模块化，我们会把这些描述成中继链的合约。这意味着他们都是中继链共识机制管理的对象（类似面向对象语言），但不一定是类似EVM的字节码，也不一定能通过账户系统寻址。

6.2 权益合约

这个合约管理着验证人集合：

哪些账户是验证人；
哪些在短期内可以变成验证人；
哪些账户为了提名验证人而质押了权益
每个人的属性，包括余额、可接受的押金比例、地址列表、会话（session）身份

它让账户在想成为验证人的时候可以来注册（需满足某些要求）、也可以提名某用户、在想退出验证人角色的时候还可以来退出。它自身还包含了一些用于验证和达成一致性的功能。

6.2.1 权益代币的流动性

通常我们希望能从网络中把尽可能多的权益代币都抵押进来，因为这关系到抵押权益的总市值和网络的安全性。这可以很简单地通过货币增发和收益分发来激励验证人。然而，这么做会出现一个问题：如果代币都被抵押在权益合约里，用于防止作恶，那么如何保证代币在一定程度上的基本流动性，进而支持价格发现呢？

一种方法是提供一个前向衍生合约来管理由抵押代币衍生出来的二级代币。但这在非信任的情况下很难实现。这些衍生代币无法等值交易，原因就和欧元区的不同政府发行的债券一样：抵押的代币有可能被扣减而价值降低。至于欧洲政府，他们还可能会违约。对于由验证人质押而来的代币，要考虑到验证人的恶意行为可能会遭到惩罚的情况。

基于我们的原则，我们选择了一种更简单的方案：不能把所有的代币都质押进来。这意味着一部分（可能20%）代币会被强制保持可流通的状态。尽管从安全的角度上讲，这个方案不完美，但也没有从根本上影响网络的安全。相比于100%的质押，也将只可能没收80%的权益作为赔款。

我们还将会使用一个反向拍卖机制来公平地决定质押代币和流通代币的比例。有兴趣成为验证人的代币持有者可以给权益合约提交一个请求，说明他们希望支付的最小比例。每次会话（会话可能每个小时算一次）开始的时候，系统会根据每个意向验证人的押金和支出比例来填满验证人的插槽。一个可能的算法是从提交押金的验证人中，选择那些押金满足如下条件的人：押金不高于“总押金目标/插槽数量”且不低于“次低押金”的一半。如果不够填满这些插槽，那么我们会迅速降低这个“次低押金”来满足条件。

6.2.2 提名

用户可以把手中的权益代币非信任地交给一个已激活的验证人，让他们来履行验证人的职责。提名通过一个“批准-投票”系统来完成。每个准提名人可以给权益合约提交一个声明，指出他们信任的可以履行职责的一个或多个验证人的身份。

在每个会话期间，提名人的押金会散布给一个或多个代表他们的验证人。这些验证人的押金是等额分配的。提名人的押金用于验证人承担他们的责任，将能够获得利息或承受相应的扣减。

6.2.3 押金没收/烧毁

验证人的某些行为会导致惩罚性地没收他们的押金。如果押金降低到允许的最小值，会话就会提前结束，另一个会话开始。一个不完整的将导致惩罚的行为列表：

属于一条平行链的验证人小组，却不为该平行链的区块提供合法性验证；
签名了该平行链一个不合法的区块；
不去处理出口队列中被投票为已生效的消息；
不参与到共识流程中；
在中继链两个竞争性的分叉上同时签名。

有些行为会威胁到网络的完整性（例如签名不合法的平行链区块，或者签名多个分叉），为了驱逐这些验证人，会没收他们的押金。另外还有一些不那么严重的行为（例如不参与到共识流程中）或者那些无法清晰判别的行为（例如处于一个低效的小组），只会导致一小部分的押金被处罚。在后一种情况中，可以采用一个二级小组的搅拌功能来让恶意节点遭受到比正常节点更多的惩罚。

因为实时同步每条平行链的区块是个非常大的工作，所以在某些情况下（多叉签名和不合法签名），验证人无法很方便地检测到自身的不当行为。在这里有必要指出验证人之外的一些参与方也可以举报这些非法行为，并从中获得奖励，但他们和钓鱼人还不太一样。

因为有些情况非常严重，我们希望可以很简单地从没收的押金里支付奖金。我们通常倾向于使用烧毁代币的方法进行重分配，而不是采用批量转账的方法。烧币可以从整体上增加代币的价值，也就可以补偿整个网络而不仅是涉及到的特定几方。这主要是作为安全防范机制，只有非常恶劣的行为才会到会非常大金额的惩罚。

很重要的一点是奖金必须足够高才能让网络觉得验证工作是值得做的，当然也不能比成本高太多，否则会招致那些足够有钱的、精心策划的国际级别的犯罪黑客攻击那些不幸的验证人，迫使他们做出非法行为。

规定的奖金也不能比恶意验证人的押金高太多，否则会不正当地激励非法行为：验证人为了奖金自己举报自己。解决方法是要么直接限制成为一个验证人的最小押金量，要么间接教育提名人：如果验证人押金太少，他们可能没有足够的动机来遵守规则。

6.3 平行链的注册

这个模块用于记录系统中的每个平行链。它是个相对简单的类似数据库的结构，管理着每条链的静态信息和动态信息。

静态信息包括链的索引（一个整数）和验证协议的标识。协议标识用于区分不同的平行链，只有这样，验证人才能运行正确的验证算法，然后提交合法的候选块。一个最初的概念验证版本会关注于如何把一个新的验证算法放在客户端中，这样每增加一个新种类的区块链，就需要一次硬分叉。然而在保证严格和高效的情况下，还是有可能不用通过硬分叉就能让验证人知晓新验证算法。一个可能的实现方法就是用一种确定的、本地编译的、平台无关的语言来描述平行链的验证算法，例如WebAssembly等。为了验证这种方法的可行性，我们还要做更多的调查，毕竟如果能够避免硬分叉还是会有很大优势的。

动态信息涉及交易路由系统，比如必须对平行链的的入口队列进行全局共识（在下一节讨论）。

必须通过全民公投才能注册新的平行链。这本来可以直接内部管理，但通过一个外部的全民公投合约会更好，因为这个合约还可以用于更多其他场景的治理。关于平行链投票注册系统的具体参数（例如法定人数、多数派的比例）会用形式化证明做成一个不常更新的“主宪法”系统，当然初始阶段也可能只是用传统的方法。具体的公式不在本文的讨论范围内，例如占2/3的多数派通过，并且全系统1/3的代币都参与了投票才算通过。

还有一些暂停和删除平行链的操作。我们希望永远不要暂停一个平行链，但这个设计是为了能应对平行链的一些紧急情况。最明显的情况是由于验证人运行了平行链的多种客户端实现，导致可能无法对某区块达成共识。我们也鼓励验证人使用多种客户端实现，以便能尽早检测到这类事情，防止押金被扣减。

因为暂停操作是个紧急措施，所以会采用验证人动态投票的方式，而不是通过全民公投。对于重启操作，可能直接通过验证人投票，也可能通过全民公投来完成。

删除操作平行链只能通过全民公投来进行，而且要提供一个宽松的平滑退出过渡期，能让它们成为一个独立的区块链或变成其他共识系统的一部分。这个期限可能是几个月，而且最好由平行链根据自身的需求来制定。

6.4 打包中继链区块

区块打包的过程本质上是共识的过程，也是把基本的数据变得有意义的过程。在一个PoW链里，打包有一个同义词叫挖矿。在本方案里，它涉及收集验证人对于区块有效性、可用性、一致性的签名，这些区块包括中继链区块和它所包含的全部平行链的区块。

底层的BFT共识算法也不是当前的工作范围。我们不描述它，而是使用一种原语描述一种由共识推动的状态机。最终我们希望能受到一些现有共识算法的启发：Tangaora（Raft的BFT变体）、Tendermint和HoneyBadgerBFT。共识算法需要并发地对多条平行链达成共识。假设一旦共识达成，我们就可以不可辩驳地记录哪些人参与了其中。我们也可以在协议内把不正当行为的人缩小到一个小组中，里面仅包含哪些恶意参与者，这样就可以在惩罚时可以降低附带伤害。

以签名声明形式存在的这些证明、中继链的状态树根和交易树根一起存储在中继链的块头里。

对于中继链区块和平行链区块的打包过程是在同一个共识生成机制中，两类块共同组成了中继链的内容：平行链并不是由他们的小组隔离地进行“提交”之后再被收集的。这虽然导致中继链的流程更加复杂，但也让我们可以在一个阶段里就完成整个系统的共识，能够将延迟最小化，并且能支持更加复杂的数据可用性，这在路由流程中将会很有用。

可以用一个简单的表格（二维的）来建模每个参与方的共识机。每个参与方都有一系列以签名形式存在的来源于其他参与方的信息，描述着每个平行链的候选块和中继链的候选块。这些信息有两部分数据：

可用性：对于出口队列里这个块的已提交交易，验证人是否有足够的信息才能在下一个块正确地验证平行链的候选块？他们可以投1（知道）或0（不确定）。当他们投了1，他们就承诺在后续的投票中也要这么投票。后面的投票和这个不对应会导致惩罚。

有效性：平行链的区块是否有效，是否包含了引用的所有的外部数据（比如交易）？这和验证人对平行链的投票相关。他们可以投1（有效）、-1（无效）或0（不确定）。只要他们投了非0，他们就承诺在后续的投票中也要这么投票。后面的投票和这个不对应会导致惩罚。

所有验证人都必须投票；在上面的规则限制下，还可以重新提交投票。共识流程可以像很多标准BFT共识算法那样来建模，每个平行链是并行的。除了有很小的概率把少数恶意参与者都被分配到了同一个平行链小组之外，共识算法在整体上还是能支撑网络，最坏的情况也不过只是出现一个或多个平行链因空块而死锁的情况（还有一个回合做出惩罚）

判断一个独立区块是否有效的基本规则（允许全部的验证人作为一个整体达成共识，然后这些平行链区块就成为中继链上具有一致性的数据引用）：

需要有至少三分之二的验证人投票“是”，并且没人投“否”。
需要超过三分之一的验证人对出口队列消息的可用性与否投票“是”。

对于有效性而言，如果至少有一个“是”且至少有一个“否”投票，一个特殊的条件就开启了，整个验证人就必须投票决定是否有恶意参与者，或者是否产生了意外的分叉。除了有效和无效之外，还支持投第三种票，等效于同时投了“是”和“否”，表示这个节点有相互冲突的意见。这可能是因为节点所有者运行的多种客户端实现而产生了分歧，也预示着平行链协议可能存在不清楚的地方。

当所有验证人的票都被记录过后，发现赢的那个意见少于一定数量的票（详细参数最多可能是一半，也许更少），那就可以假设平行链发生了意外的硬分叉，这个平行链的共识就会被自动暂停。否则，我们假设就是有恶意行为发生，并惩罚那些给输的那个意见投了“是”票的验证人。

结论是只有足够的签名票数才能达成一致性，然后中继链的区块就打包完成了，开始打包下一个区块。

6.5 中继链区块打包的改进

打包区块的方法确保着系统的正常运行，因为每条平行链的关键信息都要由超过三分之一的验证人来保证可用性，所以它并不能很好地伸缩。这意味着随着更多平行链的增加，每个验证人的工作也会增加。

在开放的共识网络中，如何保证数据的可用性还是个有待解决的问题，然而还是有一些方法可以缓解验证人节点的性能瓶颈。一个简单的方案是：其实验证人们只是负责验证数据的可用性，那他们就没必要自己真正地存储、通信和复制数据。第二个方案是数据隔离，这个方案很可能和收集人如何组织数据相关，网络可以对收集人有一定的利息或收入激励，让他们保证提供给验证人的数据是可用的。

然而，这个方案也许可以带来一点伸缩性，但仍没有解决根本问题。因为添加更多平行链通常需要增加验证人，网络资源的消耗（主要是带宽）以链总数的平方的速度增长，长期来看这是不可持续的。

最终，我们可能会思考对于保证共识网络安全的根本限制，网络对带宽的需求增长速度是验证人数乘以消息总进入数。我们不能信任那些将数据分开在不同节点存储的共识网络，因为这会将数据和运算分离。

6.5.1 延迟性介绍

简化这个规则的方法是先了解即时性的概念。33%+1的验证人最终（eventually）需要对数据的有效性进行投票，而不是立刻（immediately）投票，我们可以更好地利用数据指数级传播的特性，来帮助应对数据通信的峰值。一个合理的等式（尽管未证明）：

（1）延迟 = 验证人数 * 区块链数

在目前的模型下，系统的规模只有随着链的个数而伸缩，才能保证数据的分布式运算；因为每个链至少需要一个验证人，对于可用性投票的复杂度，我们把它降到了只和验证人个数呈线性关系。现在验证人数可以和链个数同样增长了，我们终结了：

（2）延迟 = 数量2

这意味着随着系统增长，网络内带宽和延迟性的增长是可知的，但达到最终确定性所需的区块数目仍然是以平方增长。这个问题将会继续困扰我们，也可能迫使我们打造一个“非平层”（non-flat）的架构，也就是会有很多按层级结构排列的Polkadot链，通过一个树形的结构来路由消息。

6.5.2 公众参与

微意见（micro-complaints）系统是一种可以促进公众参与的方式。可以有一些类似于钓鱼人的外部参与方来监管验证人。他们的任务是找到提供了非可用数据的验证人。他们可以给其他的验证人提交一个微意见。这个方案需要用PoW或押金机制来防止女巫攻击，否则它会让整个系统失效。

6.5.3 可用性保证人

最终的一个方案是从验证人里提名出第二个小组作为可用性保证人（Availability Guarantors）。他们也需要和普通验证人那样交押金，而且有可能来源于同一个组（会在一个长周期里选择他们，至少也是一个会话）。和普通验证人不同的是，他们不需要在各条平行链间切换，而只需要形成一个单一的小组，监管所有重要跨链数据的可用性。

这个方案还有个优势是能缓解验证人数和链个数之间的等式关系。链个数可以最终增长（与原始链的验证人小组一起），然而各参与方仍可以保持次线性增长或常量增长，尤其是那些参与数据可用性验证的人。

6.5.4 收集人设置

系统需要保证的一个重要方面是：合理地选择那些制造平行链区块的收集人。如果一条平行链由某个收集人控制了，那么外部数据是否可用就会变得不那么明显，这个人就可以比较简单地发动攻击。

为了尽可能地广泛分配收集人，我们可以用伪随机的方法来人工衡量平行链区块的权重。在第一个示例中，我们希望验证人倾向于选择权重更大的候选块，这是共识机制的一个重要部分。我们也必须激励验证人找到最大权重的候选块，验证人可以把他们的奖励按比例分配给这些候选块。

在共识系统里，为了确保收集人的区块被选中的机会是平等的，我们用一个连接所有收集人的随机数生成器来决定每个候选块的权重。例如用收集人的地址和一些密码学安全的伪随机数做异或（XOR）运算来决定最优的块（获胜票）。这给了每个收集人（更准确地说是每个收集人地址）随机公平地打败别人的机会。

验证人通过女巫攻击来生成一个最接近于获胜票的地址，为了阻止这种情况，我们会给收集人的地址加上一些惰性。一个很简单的方法是需要他们的地址有基本的余额，另一个更优雅的方式是综合考虑地址的余额来计算获胜的概率。这里还没有完成建模，我们很可能会让很少余额的人也可以成为收集人。

6.5.5 区块超重

如果一个验证人集合被攻击了，他们可能会生成一个虽然有效但要花费大量时间来执行的区块。这个问题来源于一些特定的难解数据题，比如大质数因式分解难题等，验证人小组可能需要非常长的时间才能解出答案，如果有人知道一些捷径，他们的候选块就有巨大的获胜优势。如果一个收集人知道那个信息，而其他人都在忙着计算老的块，那么他就有很大的优势让他的候选块获胜。我们称这种叫超重（overweight）块。

为了防止验证人提交这些大幅超出普通区块的超重块，我们需要添加一些警告：因为执行一个区块要花费的时间是相对的（根据它超重的程度），所以最终可能的投票结果会有三种：第一种是这个区块绝对没有超重，超过2/3的验证人声明他们可以在一定时间内算完（例如出块时间的50%）；另一种是这个区块绝对超重了，超过2/3的验证人声明他们无法在限定的时间内执行完这个区块；再一种就是意见分歧基本持平，这种情况下我们会做一些惩罚。

为了保证验证人能预测他们提交的区块是否超重，他们可能需要公布自己在每个块上的执行表现。经过一段时间后，他们就可以通过和其他节点的比较来评估自己处理器的性能。

6.5.6 收集人保险

还有一个问题留给了验证人：为了检查收集人区块的有效性，他们不能像PoW网络那样，而是必须自己计算里面的交易。恶意收集人可以填充非法或超重的区块给验证人，通过让他们受害（浪费他们的资源）来获取大量的潜在机会成本。

为了预防这个，我们为验证人提供了一个简单的策略。第一：发给验证人的平行链候选块必须要用有钱的中继链账户签名，如果不这么做，验证人会立即丢弃这个块。第二：会用组合算法（或乘法）对这些候选块进行排序，因素包括高于一定限额的账户余额、收集人过去成功提交的区块数（除去那些有惩罚的）、和获胜票的接近程度。这里的限额应该等于提交非法块的惩罚金。

为了警示收集人不要发送非法或超重的交易给验证人，任何验证人都可以在下一个区块中打包一个交易，指出那个非法的区块，并将那个收集人部分或全部的余额都转给那个受害的验证人。这种交易的优先级高于其他交易，使得收集人不能在惩罚之前转走他的余额。惩罚金额可能是动态决定的，也很可能是验证人区块奖励的一部分。为了阻止验证人任意没收收集人的钱，收集人可以对验证人的决定进行上诉，成立一个由验证人随机组成的陪审团，并交一些押金。如果陪审团发现验证人是合理的，那这笔押金就给陪审团了。如果是不合理的，押金退回给该收集人，而验证人要受到惩罚（因为验证人是核心角色，惩罚会比较重）。

6.6 跨链交易路由

跨链交易路由是中继链和其验证人的核心功能。这里管理着主要的逻辑：一个提交的交易（简言之为“提交”）是如何从一个来源（source）平行链的出口被强制地路由到另一个目标（destination）平行链里，而且无需任何信任人。

我们很小心地选择了上面的词语；在来源平行链里，我们无需一个明确约束这个提交的交易。我们模型里的唯一约束是：平行链必须尽力按照全部的出口能力打包，这些提交就是他们区块执行的结果。

我们用一个先进先出（FIFO）的队列组织这些提交。作为路由基准（routing base）的队列个数可能在16个左右。这个数字代表着我们可以直接支持的平行链性能，而不用采用多相（multi-phase）路由。Polkadot一开始会支持这种直接路由，然而我们也可能会采用一种多相路由操作（超路由hyper-routing）作为将来系统伸缩的方式。

我们假设所有参与方都知道下两个区块n，n+1的验证人分组情况。概括而言，路由系统有如下阶段：

收集人s：合约成员中的验证人V[n][S]。
收集人s：FOR EACH 小组s：确保合约里有至少一个验证人V[n][S]。
收集人s：FOR EACH 小组s：假设出口[n-1][s][S]是可用的（上个区块里所有对S提交的数据）
收集人s：为S构造候选块b：（b.header,b.ext, b.proof, b.receipt, b.egress）。
收集人s：发送证明信息proof[S] = (b.header, b.ext, b.proof,b.receipt, b.egress)。
收集人s：确保外部交易数据b.ext已经对于其他收集人和验证人可用了。
收集人s：FOR EACH 小组s：发送出口信息egress[n][S][s]= (b.header, b.ext, b.receipt, b.egress)给下个区块的接收方小组的验证人V[n+1][s]。
验证人v：预连接下一个区块的同一个组的成员：让N = Chain[n+1][V]；连接所有的验证人使Chain[n+1][v] = N。
验证人v：收集这个块所有的入口数据：FOR EACH 小组s：检索出口egress[n-1][s][Chain[n][V]]，从其他验证人v获得使Chain[n][v] = Chain[n][V]。可能是通过随机性地选择其他验证人的证明数据。
验证人v：为下个块接收候选块的出口数据：FOR EACH 小组s，接收egress[n][s][N]。对区块出口的有效性投票；在意向验证人间重新发布使Chain[n+1][v] = Chain[n+1][V]。
验证人v：等待共识。

egress[n][from][to]代表：在区块n里，从来源from平行链到目标to平行链的当前出口队列信息。收集人s是属于平行链S的。验证人V[n][s]是平行链s在区块n时的验证人小组。相反地，Chain[n][s]是验证人v在区块n所属的平行链。block.egress[to]是从平行链区块block发送给目标平行链to的出口队列。

收集人因为希望能够采纳他们出的块，所以收集（交易）手续费作为激励，并保证下一个区块的目标小组成员都能知晓当前块的出口队列。验证人的激励是达成中继链区块的共识，所以他们并不关心最终采纳哪个收集人的区块。一个验证人原则上可以勾结一个收集人，合谋减少采纳其他收集人的概率，然而因为平行链的验证人是随机分配的，所以这也很难得逞，而且还可能会遭到手续费减免，最终影响共识流程。

6.6.1 外部数据可用性

如果要在一个去中心化的系统里完成分布式的全部流程，一个长年的遗留问题是：如何确保一条平行链的外部数据都是可用的。这个问题的核心原因是：不可能生成一个关于可用性与否的非交互式证明。在一个拜占庭容错的系统内，我们需要依赖外部数据才能验证任意交易的有效性。假设我们能容忍的最多的拜占庭节点数为n，我们一共至少需要n+1个节点才能证明数据的可用性。

Polkadot是个希望可以伸缩的系统，这带来了一个问题：如果必须由一个固定比例的验证人来证明数据的有效性，并且假设他们真会存储这些数据来用于判断，那么我们如何避免随着系统的增长而带来的对带宽/存储空间等需求的增长。一个可能的答案是成立一个验证人小组（就是保证人），他们的数目随着Polkadot整体的增长而线性增长。这在6.5.3里提到了。

我们还有第二个技巧。收集人有内在的激励去确保所有数据的可用性，否则他们就不能再生产后续区块了，也就不能再获得手续费了。收集人也可以形成一个小组，成员复杂多样（因为平行链验证人成员的随机性），很难进入。允许最近的收集人（可能是最近几千个块）对某条平行链区块的外部数据发起挑战，来获取一点验证人的奖励。

验证人必须联系这些有明显进攻行为的小组，这些小组会举证、获取并返回数据给收集人，或者直接通过证明数据的非可用性来升级事态（作为原告方直接拒绝提供数据记录，不当行为的验证人会直接断开连接），并联系更多的验证人一起去测试。在后一种情况中，收集人的押金会被退回。

一旦超过法定个数的验证人都证明交易的非可用性，验证人小组就可以解散了，非法行为的收集人小组会被惩罚，区块被回退。

6.6.2 路由“提交”

每条平行链的头部都包含一个出口树根（egress-trie-root）。这个树根包含了一个路由信息的格子列表，每个格子里都有一个串行（concatenated）结构的出口提交。可以在平行链的验证人之间提供梅克尔树证明，这样就能证明某条平行链的区块对应着另一条平行链的出口队列。

在开始处理平行链区块之前，每条平行链指定区块的出口队列会被并入我们区块的入口队列。假设密码学安全的伪随机数（CSPR）能用来保证公平地对平行链区块进行配对。收集人计算新队列，并根据平行链的逻辑抽干出口队列。

入口队列的内容会被明确地写入平行链区块。这么做有两个目的：第一，平行链可以独立地进行非信任同步，而不用依赖其他链。第二，如果整个入口队列无法在一个块内处理完，那么这种方法可以简化数据逻辑；验证人和收集人可以继续处理下面的区块而不用再做数据引用了。

如果平行链的入口队列超过了区块处理的阈值，那么在中继链上就会被标记为已满，在队列清空之前不会再接收新的消息。使用梅克尔树来证明收集人在平行链区块里的操作是可信的。

6.6.3 弊端

这个架构的小瑕疵是可能发生后置炸弹攻击（post-bomb attach）。所有的平行链给另一个平行链发送最大数量的提交，这会瞬间塞满目标链的入口队列，不造成任何伤害地进行了Dos攻击。

正常情况下，假设有对于N条平行链和一系列正常同步的非恶意的收集人和验证人，那么总共需要N x M个验证人，每条平行链L个收集人，每个块可能的数据路径（data path）有：

验证人：M-1+L+L：M-1代表平行链集合里的其他验证人，第一个L代表每个收集人提供了一个平行链候选块，第二个L代表下一个块的全部收集人需要放入出口队列的前块数据。（后一种情况可能会更糟，因为收集人之间会分享这些数据）。

收集人：M+kN：M代表和每个平行链区块相关的验证人的连接数，kN代表着下一个区块播种（seeding）到每个平行链验证人小组的出口队列的负载（很可能是一些很受喜爱的收集人）。

因此，每个节点数据路径的可能性随系统的复杂度的增长而线性增长。这也是合理的，当系统伸缩到上百上千个平行链的时候，通信的延迟也会变大，进而降低复杂度的增长速度。在这种情况下，会用一个多级的路由算法来减少峰值期的数据路径，但需引入缓存和交易延迟。超方路由（Hyper-cube Routing）是一种可以建立在上面描述的基础路由方法上的一种新机制。对节点来说，他们的连接数从需跟平行链和节点小组数一起增长，变成了只跟平行链个数的对数增长。这样就可能需要经过多个平行链的队列才能最终传送“提交”。

路由本身是简单和确定性的。我们从限制入口/出口队列的格子数开始；平行链的总数目是routing-base（b），这个数字会随着平行链的改变而修正，增长为routing-exponent（e）。在这个模型下，我们的消息总量以O(be)增长，而数据路径保持为常量，延迟（或传递需要的块数）以O(e)增长。

我们的路由模型是一个e维的超方体，每个立方体的面有b种可能位置。对于每个块，我们围绕一个轴来路由消息。为了保证最坏情况下的e个块的传递延时，我们用round-robin fashion来轮换每个轴。

作为平行链处理的一部分，只要给定当前的块高度（路由维度），入口队列里外部范围的消息就会立即路由给合适的出口队列的格子。这个过程需要在传送路由上发送更多数据，然而这会是个问题，也许可以通过一些替代性的数据负载发送方式解决，比如只包含一个引用，而不是在提交树（post-trie）里包含全负载。

一个拥有4条平行链的超方路由系统示例，b = 2、e = 2：

阶段0，对于每个消息M：

sub0：如果 Mdest∈ {2，3} ，那么sendTo（2），否则保留
sub1：如果 Mdest∈ {2，3} ，那么sendTo（3），否则保留
sub2：如果 Mdest∈ {0，1} ，那么sendTo（0），否则保留
sub3：如果 Mdest∈ {0，1} ，那么sendTo（1），否则保留

阶段1，对于每个消息M：

sub0：如果 Mdest∈ {1，3} ，那么sendTo（1），否则保留
sub1：如果 Mdest∈ {0，2} ，那么sendTo（0），否则保留
sub2：如果 Mdest∈ {1，3} ，那么sendTo（3），否则保留
sub3：如果 Mdest∈ {0，2} ，那么sendTo（2），否则保留

这里的两个维度很容易看做是目标索引的前两位（bits）。第二个块处理低序的位。一旦全部发生（任意顺序），提交就会被路由。最大化随机性（Serendipity）。一个对基本提议的修改是把验证人数固定为c2-c个，每个小组c-1个验证人。摒弃原来每个区块时都在平行链间松散地分配验证人的方案，而改成对于每个平行链小组，在下一个区块时，会分配每个验证人到唯一的不同平行链小组。这导致了两个区块之间的不可变性，对于任意配对的平行链，都会有两个验证人调换他们的职责。然而我们不能用这个来确保绝对的可用性（单个验证人可能时常掉线，即使是非恶意的），但可以优化这个方案。

这个方案也会有后遗症。平行链需要重组验证人集合。进而验证人的数量会被绑定在平行链数量的平方级别，从很少开始最终快速增长，在50条平行链时就会变得无法承受。这些都不是什么本质问题，对于第一个问题，本来也需要频繁重组验证人集合，无论验证人集合的数量多少。当集合数很少的时候，多个验证人可能被分配到同一条平行链，那么对于全部平行链影响的因素是常量的。对于在很多平行链时的需要很多验证人的问题，可以用在6.6.3里讨论的这个多阶段的超方路由机制来缓解。

6.7 平行链的验证

验证人抵押了大量的保证金，他们的主要目标就是校验平行链区块是否有效，包括但不限于：状态转换、囊括外部交易、执行等待在入口队列的提交、执行出口队列的最终状态。这个过程本身是比较简单的。验证人一旦完成了前一个区块的打包，他们就可以自由地为后面的几轮共识准备平行链的候选块。

验证人一开始通过平行链收集人（下面介绍）或他的某个副验证人找到一个平行链区块。平行链候选块的数据包含区块头、前块头、外部数据输入（对于以太坊和比特币，这些数据被称为交易，然而他们也可能是任意结构、任意目的）、出口队列数据、状态转换有效性的内部证明数据（对于以太坊，这可能是用来执行每个交易的很多状态/存储树节点）。实验性的证据显示对于目前的以太坊区块，这个数据集最多有几百K字节（KiB）。

如果校验没有完成，验证人会尝试从前一个块的转换中获取相关信息，从前一个块的验证人开始，之后到所有签名了这个数据的验证人。

一旦一个验证人接收到了这么一个候选块，他们就在本地验证它。验证过程包含在平行链这个大类的验证人模块里，这个需要共识的软件模块必须写在所有的Polkadot实现里（原则上可以在多个实现里共享一个C ABI的库，但这会降低安全性，因为他们只是单一实现的引用）。

这个过程会提取前块头，然后用刚达成共识的中继链区块中记录的哈希值来检验。一旦父块头的有效性得到了验证，就会调用平行链类中特定的验证函数。这是个会接收很多数据项（大概就是目前给出的几种）的函数，返回值是对于区块是否有效的简单判断。

大多数这种验证函数都将首先检查头部的数据项，这些数据都可以直接从父块衍生出来（例如父块哈希、高度）。之后为了处理交易或提交，他们会尽力填充内部数据结构。对于以太坊这样的区块链，需要执行全部的交易才能往梅克尔树填充这么大量的数据。其他类型的区块链可能有其他的处理措施。

一旦完成验证，入口提交和外部交易（或代表的其他）都会根据链的规则而被固定。（一个可能的默认方式是需要所有入口提交都在服务外部交易之前处理，然而这应该由平行链的逻辑决定）。通过这个规定，一系列的出口提交都会被创建，而且确实符合收集人的候选块要求。最终会一起检查合理填充的块头和候选块头。

验证人完成了对候选块的校验后，就对块头哈希进行投票，并发送必要的验证信息给小组里的其他副验证人。

6.7.1 平行链收集人

平行链收集人不需要交押金，他们完成的是类似目前区块链网络里矿工的任务。他们属于特定的平行链。为了开展工作，他们必须要有完全同步的中继链和平行链。

完全同步的精确含义取决于平行链的种类，尽管它们都包含平行链入口队列的当前状态。在以太坊这个例子中，它还至少要有最近一些块的梅克尔树数据库，但也可能包含非常多的其他数据结构，例如证明账户存在的Bloom过滤器、遗传（familial）信息、日志输出、和对应高度区块的分叉回退表单。

为了保持两条区块链的同步，他们必须维护一个交易池来“钓取”（fish）交易，并接收公网上正确验证的交易。有了链和交易池，收集人就可以为每个块的被选验证人（由于同步了中继链所以知道他们身份）打包新的候选块，再附属一些必要信息（例如从节点网络来的有效性证明等），然后提交给验证人。

他们收集所有交易的手续费作为回报。这里有很多经济激励手段。在一个激烈竞争的市场中，如果收集人有富余的话，还可以跟平行链验证人分享手续费，以激励他们打包特定收集人的区块。同样地，一些收集人可能提高所需支付的手续费，使区块对于验证人更有吸引力。在这种情况下，正常的市场机制会使那些更高手续费的交易跳过队列，并能更快地打包到链里。

6.8 网络设计

以太坊和比特币等传统区块链中的网络设计需求一般比较简单。所有的交易和区块都未受引导地用gossip广播。同步模块中牵涉到的东西会更多一点，以太坊就可以根据不通类别做出不同的响应，但现实中这更多是节点的策略，而不是协议本身的内容。

以太坊基于devp2p协议改进了目前的网络协议，支持在单一节点连接中进行多个子协议的多路复用，因此同时支持多个p2p协议，但以太坊的协议仍然相对比较初级，而且它还没有完成例如支持QoS等重要功能。当初创造一个无所不在的“web3”协议的愿望基本上失败了，只剩下从以太坊众筹出来的几个项目。

Polkadot的需求更加根本。相比于一个完整的统一网络，Polkadot有很多种参与方，每方都有不同的需求，参与方需要有很多不同的网络信道来交换数据。从本质上讲，这意味着需要一个能支持更加层级化的网络结构的协议。另外为了促进更多新类型的区块链来扩展网络，也需要有一个新的层级结构。

对于网络协议更深层面的探讨不在本论文范围内，我们需要更多的需求分析。我们可以把网络参与者分为两类（中继链、平行链），每个都有三小类。每条平行链的参与方之间相互通信，而不和其他链通信：

中继链参与方
验证人：P，为每条平行链分割成多个子集P[s]
可用性保证人：A（在基础协议里由验证人代替）
中继链客户端：M（每条平行链的成员）
平行链参与方：
平行链收集人：C[0]，C[1]，…
平行链钓鱼人：F[0]，F[1]，…
平行链客户端：S[0]，S[1]，…
平行链轻客户端：L[0]，L[1]，…

通常我们认为网络成员和他们的设置间会发生如下几种通信：

P | A<-> P | A：为了达成共识，验证人/保证人必须连接。
P[s]<-> C[s] | P[s]：每个作为平行链成员的验证人会和其他成员连接来发现区块并分享区块，例如收集人。
A <->P[s] | C | A：每个可用性保证人将需要从验证人那里收集签过名的共识相关的跨链数据；收集人可以广播给保证人来优化对他们区块的共识。一旦完成，数据会广播给其他保证人来促进共识。
P[s]<-> A | P[s’]：平行链验证人将需要从前一个验证人或可用性保证人集合收集额外的输入数据。
P[s]<-> A：当需举报时，钓鱼人公告给任何参与方。
M <-> M| P | A：中继链客户端输出数据给验证人和保证人。
S[s]<-> S[s] | P[s] | A：平行链客户端输出数据给验证人和保证人。
L[s]<-> L[s] | S[s]：平行链轻客户端从全客户端获取数据。

如果为了保证高效的传输，那种每个节点无差异的平层网络（类似以太坊devp2p）就不再适应了。协议里很可能扩展引入一个合理的节点选择和发现机制，还可能计划一些前瞻性的算法，保证节点的顺序在适当时候是“偶然”连接的。

各类不同参与方节点的具体策略会不一样：对于一个能伸缩的多链系统，收集人要么需要持续地重新连接被选的验证人，要么连接一个验证人小组来保证他们永不断线，即使大多数时间他们对于自己是无用的。收集人也会保持和可用性保证人集合的一个或多个稳定连接，来确保需要共识数据的快速传播。

可用性保证人将保持相互连接，还要保持与验证人（为了共识和需共识的平行链数据）、一些收集人（为了平行链数据）、一些钓鱼人和一些全节点（为了缺失的信息）的稳定连接。验证人倾向于寻找其他验证人，特别是那些在同一个小组里的，还有那些可以提供平行链区块的收集人。

钓鱼人和一般中继链或平行链客户端会倾向于和验证人或保证人保持一个连接，但和他们相似的很多节点却不这么做。平行链轻客户端除了连接其他轻客户端外，也会连接一个平行链全客户端。

6.8.1 节点轮换的问题

在基础协议的预案里，每个块的验证人小组随机变换，验证人被随机分配去验证某条平行链的交易。如何在不相关的节点间传递数据会是一个问题，这就必须依赖一个全分布式并且连接良好的节点网络，才能保证所需的跳跃距离（最坏的延迟）只按照网络规模（一个类似的Kademlia的协议会有帮助）的log级别增长，要么就必须延长区块时间，来支持必要的连接谈判，建立能够满足该节点当前通信需求的节点集合连接。

这些都不是好的方案：强迫变成更长的出块时间会让网络无法支持一些特定的程序或区块链。即使是一个完美公平的网络连接也会导致带宽浪费，因为要推送大量数据给不相关的节点，所以会影响到网络的伸缩功能。

然而这些方向都会促进问题的解决，一个可以降低延迟的优化方案是降低平行链验证人集合的易变性，在一段区块后才重新分配（比如15个区块，如果是4s的区块时间，那么只需要每分钟才重新连接），或者一段时间内只轮换一个验证人（例如如果有某条平行链分配了15个验证人，那么平均情况是一分钟内才全部轮换）。通过提高平行链局部的可预测性，来降低节点轮换的次数，并仍然保证连接的优势，我们就可以保证节点间连接的随机性。

6.8.2 通往高效网络协议的路径

最高效和合理的开发方向是专注于改造一个现有协议而不是自己从头开发一个。我们将会探讨的几个点对点协议包括：以太坊的devp2p、IPFS的libp2p、GNU的GNUnet。关于这些协议的全面介绍、以及其中关于如何打造一个能支持特定结构的模块化节点网络、动态节点转换、可扩展子协议等内容，本文也不做过多介绍，但这会是实现Polkadot的重要一步。

7 协议的可实践性

7.1 跨链交易支付

我们去除了以太坊那样的计算资源统计的gas机制，这虽然带来了更多的自由和简便性，但也引出了重要的问题：没有了gas，一条平行链如何防止其他平行链逼迫他们做运算？然而我们可以依赖“交易提交”的入口队列缓存来阻止一条链给另一条链塞满交易数据，我们还没有提供其他相同效果的防垃圾机制。

这是个更高层面的待解决问题。由于链可以在“交易提交”中附属任何数据，我们需要保证在开始之前就支付计算费用。类似于以太坊Serenity版本中的一个提案，我们可以想象平行链有一个“内向”（break-in）合约来给验证人提供保证，付费换取特定数量的计算资源预分配。这些资源可能用类似gas的机制来度量，但也可能用完全不一样的概念模型，比如主观计算时间模型或类似比特币的一般计费模型。

无论“内向”合约定义什么价值模型，我们都不能简单假设链下调用器对他们是可用的，所以这个方案的用处也不大。然而我们可以想象在来源链里的第二个“外向”（break-out）合约。这两个合约形成一个桥梁，相互认识并且提供等值交换（相互之间的权益代币可以用来支付结算）。调用其他链意味着要用这个桥梁做代理，可以通过谈判来协商如何支付目标平行链的计算资源消耗。

7.2 添加链

添加一个平行链是相对比较便宜的操作，但并不免费。平行链越多意味着每个平行链的验证人就越少，更多的验证人又意味着每人的押金也会变少。通过钓鱼人缓解了强迫一条平行链的问题。由于共识机制本身的问题，增长中的验证人集合本质上导致了更高的延迟。将来每条平行链都可能给不幸的验证人造成很大的验证算法负担。

因此，验证人和/或其他权益持有者将会对添加一条新链来定价。这个链的市场要么是如下两种：

对网络没有净贡献的链（通过锁币或烧毁权益代币的方式，比如联盟链、Doge链、特定应用链）；
通过提供一些别的地方没有的功能，能给网络带来更多价值的链（例如隐私性、内部伸缩性、内置服务）

我们最终会激励社区的权益持有者来添加子链——通过经济手段或根据给中继链添加功能的意愿程度。

可预期的是刚添加进来的新链会有一个短暂的移除期，这就允许新链可以先试验，无需任何妥协和长期价值风险。

8 结论

我们提出了一个异构多链协议的可能方向，它是可伸缩的且能够向后兼容目前已存在的区块链网络。在这个协议下，各参与方为了自身利益共同创造了一个完整系统，它可以用非常自由的方式来扩展，而且没有目前那些普通区块链对用户的固有成本。我们给出了这个架构的大体轮廓，包括需要的参与方角色、他们的经济激励模型和他们需要做的操作。我们已经弄清楚了一个基本的设计，并讨论了它的优势和限制；我们未来的方向就是消除这些限制，向完全可伸缩的区块链方案迈进。

8.1 遗漏的材料和开放问题

网络设计一般都是从协议实现中分离出来的。还没有完全讨论网络如何从这种实验性的条件中恢复。网络需要一个确定性的非零时间，他们从中继链分叉中恢复过来应该也不是个大问题，然而需要小心地集成入共识协议中。

本文也没有具体探讨押金的没收和对应的奖励规则。目前我们假设提供的是赢者全拿（winner-takes-all）的奖励原则：但可能给钓鱼人最好的激励。一个短周期的提交-披露流程支持很多钓鱼人来索取赏金，进而达到一个更公平的奖励分配制度，但这个举报恶意行为的流程也将会引入更大的延迟。

8.2 鸣谢

感谢那些帮助发表这篇框架性文章的校对者。特别提下Peter Czaban、Ken Kappler、Robert Habermeier、 Vitalik Buterin、 Reto Trinkler 和Jack Petersson。感谢那些贡献想法的人，特别提下MarekKotewicz 和Aeron Buchanan。感谢其他所有提供过帮助的人。所有的错误仍都是我的。

本文其中一部分的工作，包括对共识算法的初始调查，是由英国政府的Innovate UK项目资助。

收起

展开全文

《区块链革命》读书笔记1可信的协议 & 引导未来：区块链经济七大设计原则
2018-07-03 20:00:49
更多内容欢迎戳进：我的个人博客序一区块链的核心是分布式而不是去中心。去中心是一个过程而不是一个结果，区块链是弱中心化的、分中心化的区块链是分布式账本，而分布式账本不一定是区块链。区块链在工程技术方面还...
收起
区块链
分布式事务科普（终结篇）
2020-04-17 21:20:00
点击上方"IT牧场"，选择"设为星标"技术干货每日送达！《分布式事务科普》是我在YiQing期间整理的一篇科普型文章，内容共计两万五千字左右，应该算是涵盖...
收起
Beej网络编程指南《一》
2021-10-14 20:16:52
Beej网络编程指南《一》 1简介嘿！套接字编程让你失望了吗？这东西是不是有点太难从手册页上弄清楚了？你想做很酷的互联网编程，但是你没有时间费力地穿过一堆结构，试图弄清楚在连接（）之前是否必须调用bind（）...
收起
linux windows
Polkadot（波卡链）：白皮书-畅想一种异构的多链架构
万次阅读 2018-03-29 18:38:04
摘要：现有的区块链架构都存在诸多问题，不仅仅是从实用性角度所说的扩展性（extensibilty）和伸缩性（scalability）的问题。我们认为，问题源于把共识架构中两个很重要的部分：一致性（canonicality）和有效性...
收起
虚拟机--第一章走进java--（抄书）
千次阅读 2018-12-08 20:56:34
第一章走近java 世界上并没有完美的程序，但我们并不因此而沮丧，因为写程序本来就是一个不断追求完美的过程。 1.1概述 java不仅仅是一门编程语言，还是一个由一系列计算机软件和规范形成的技术体系，这个技术体系...
收起
深入理解Java虚拟机读书笔记五、高效并发
2021-05-18 19:45:00
文章目录高效并发一、Java内存模型与线程1、概述2、硬件的效率与一致性3、Java内存模型3.1　主内存与工作内存3.2　内存间交互操作3.3　对于volatile型变量的特殊规则3.4　原子性、可见性与有序性3.5　先行发生原则4...
收起
Java的内存模型主内存与工作内存先行发生原则
华为一研发谈好新东家、离职后，对方不录用了：索赔80万、判赔11.7万
2021-08-04 00:03:15
????????关注后回复“进群”，拉你进程序员交流群????????程序员求职面试（ID：CoderJob）整理内容参考自：中国裁判文书网日前，中国裁判文书网官网披露了一则民事判决书...
收起
consul 项目管理 graphviz
JBIL：一种区块链自治规则与国家法律的衔接框架
千次阅读 2019-05-10 10:30:12
一、基本概念和意图（一）区块链自治规则 “区块链自治规则”是指建立在区块链上的去中心化自治组织系统的运行方式和策略安排等规则，为了叙述方便，简称为此。区块链自治规则是由计算机代码实现，由区块链协议...
收起
对赌协议的经典案例分析
万次阅读 2017-04-26 16:07:50
　对赌协议就是收购方（包括投资方）与出让方（包括融资方）在达成并购（或者融资）协议时，对于未来不确定的情况进行一种约定。如果约定的条件出现，投资方可以行使一种权利；如果约定的条件不出现，融资方则行使一...
收起
基于RTP协议的IP电话QoS监测及提高策略
千次阅读 2017-06-20 15:24:40
基于RTP协议的IP电话QoS监测及提高策略本文转自 http://jxic.jiangxi.gov.cn/Html/2008321143656-1.html 1. 概述随着Internet和多媒体技术的飞速发展，Internet已由早期的单一数据传输网向...
收起
因使用盗版软件赔偿 869 万元：CIO被开除、罚 15 万元
2021-04-02 00:59:43
在2015年2月的第一次审计中并没有发现使用违法软件的事实，后在2016年5月的第二次审计中才发现了圣戈班玻璃公司的侵权行为。圣戈班玻璃公司应支付的审计费应仅限于2016年5月份的审计费的一半。圣戈班玻璃公司之所以...
收起
xhtml 共识算法 jira bitcoin
深入理解Java虚拟机读书笔记
2020-02-14 16:07:10
如内存中有一个32bit的整数123456，虚拟机有能力分辨出它是指向一个123456的内存地址的引用类型还是一个数值为123456的整数 2.Java内存区域与内存溢出异常 Java内存区域（运行时数据区域）和内存模型（JMM） ...
收起
jvm 内核多线程内存管理内存结构
JVM 读书笔记
2018-12-29 15:18:54
一、JVM运行时数据区程序计数器 Java虚拟机栈本地方法栈 Java堆方法区运行时常量池二、对象是否存活分析引用计数法可达性分析算法三、垃圾收集算法标记-清除算法复制算法标记-整理算法分...
收起
深入理解JVM读书笔记
2019-07-03 19:02:00
第一部分走进Java 第1章走进java 1.1 概述 1.2 java技术体系 java程序设计语言、java虚拟机、java API类库统称为JDK，JDK是用于支持java程序开发的最小环境 java API类库中的java SE API子集和java 虚拟机...
收起
从调试数据分析USB通信协议——UVC摄像头【UVC类设备】(五)
万次阅读 多人点赞 2018-01-06 15:11:25
有了上面一圈的了解，设备描述符这些东西，小编这里不想再去一行行分析了，小编这里只贴几张图，具体的分析，读者可以自己去看看了。注：既然去查了，干脆就还是放在这里吧。小编我去查了一下下面的
收起
UVC USB
周鸿祎：写区块链最好的一篇文章
2018-02-28 10:52:52
以下正文：这组词序并没有任何意义，真正让它们有价值的地方在于，这个词序是由一个被称为 MetaMask 的软件专门为我一个人生产的。用密码学（cryptography）术...
收起
被裁的38岁互联网人：10年赔偿18万、半年花光、他打算送快递
2020-11-28 15:21:45
这个想法在他脑海里缠绵了3个月，尽管他清楚，一旦回到自己的老家——山东鲁东某山区县城，意味着从事10年的互联网DBA（数据库管理员）生涯宣告终结，但他觉得自己非走不可。找工作8个月毫无进展，之前投递简历的...
收起
深入理解Java虚拟机--读书笔记
2018-03-06 09:41:00
一个对象的回收需要经历两次标记过程，如果可达性分析后没有与GC Roots相连接的引用链，会被第一次标记并进行一次筛选，筛选有没有必要执行finalize()方法（当对象没有覆盖finalize方法，或者finalize被执行过， ...
收起
《深入理解Java虚拟机》读书笔记十二
2019-03-21 16:20:00
由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲。每个处理器都有自己的高速...
收起
纽约时报杂志关于区块链最好的一篇深度报道
2018-03-14 10:49:00
最近，奇虎360创始人周鸿祎发布朋友圈，转载纽约时报杂志文章《骗子、假先知们一夜暴富背后：区块链是回归互联网本来意义的唯一希望》，并评论说这篇文章是迄今为止我所认为的最深入浅出的、最明明白白的一篇文章，...
收起
《深入理解Java虚拟机》读书笔记7
2018-08-01 06:18:46
一、Java内存模型 Java内存模型（Java Memory Model, JMM），用来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果。主要目标是定义程序中各个共享变量的访问规则。...
收起
币圈资管早知道 | 香港虚拟资产交易所监管条例公告书附录详读：V & VI
2019-11-21 11:16:21
附录在公告书中占了四分之三的篇幅，可见其中内容的细化和重要性。前期关于附录的I~IV部分（I.释义；II.守则及指引；III财务稳健性；IV.营运），可以参考这篇文章：占了公告书四分之三篇幅的是什么？今天我们接着...
收起
数字货币交易所数字经济

合伙创业协议书标准模板

关于 802.11 协议

一．802.11成帧封装实现

1.1控制帧

1.1.1 一般的帧控制位

1.1.2 RTS（请求发送）

1.1.3 CTS （允许发送）

1.1.4 ACK （应答）

1.1.5 PS-Poll （省电模式一轮询）

1.2 数据帧

1.2.1 Frame Control （帧控制）

1.2.2 Duration（持续时间）

1.2.3 地址与DS Bit

1.2.4 数据帧的次类型

1.2.5 数据帧的封装

1.2.5.1 IBSS帧

1.2.5.2 发送自接入点（From AP ）的帧

1.2.5.3 发送至接入点（To AP ）的帧

1.2.5.4 WDS 中的帧

1.2.5.5 经加密的帧

1.3 管理帧

1.3.1 管理帧的结构

1.3.1.1 地址位

1.3.1.2 计算持续时间

1.3.1.3 帧主体

1.3.2 长度固定的管理帧元件

1.3.3 管理帧的信息元素

1.3.3.1 服务集标识（Service Set Identity（SSID））

1.3.3.2 支持速率（Supported Rates）

1.3.3.3 跳频参数组合（PH Parameter Set）

1.3.3.4 直接序列参数集合（DS Parameter Set）

1.3.3.5 数据待传信息（Traffic Indication Map（TIM ））

1.3.3.6 免竞争参数集合（CF Parameter Set）

1.3.3.7 IBSS 参数集合（IBSS Parameter Set ）

1.3.3.8 国家（Country）

1.3.3.9 Hopping Pattern Parameters（跳频模式参数）与 Hopping Pattern Table （跳频模式表）

1.3.3.10 请求（Request）

1.3.3.11 质询口令（Challenge Text）

1.3.3.12 功率限制（Power Constraint）

1.3.3.13 功率性能（Power Capability）

1.3.3.14 发射功率控制要求（TPC Request ）

1.3.3.15 发射功率控制报告（TPC Report）

1.3.3.16 所支持信道（Supported Channels）

1.3.3.17 信道切换宣告（Channel Switch Announcement ）

1.3.3.18 Measurement Request （测量要求）与 Measurement Report（测量报告）

1.3.3.19 禁声（Quiet）

1.3.3.20 IBSS 动态选项（IBSS DFS ）

1.3.3.21 扩展物理层（ERP）

1.3.3.22 强健安全网络（Robust Security Network （RSN））

1.3.3.23 扩展支持速率（Extended Supported Rate）

1.3.3.24 Wi-Fi Protected Access （Wi-Fi访问保护，简称 WPAI）

1.3.4 管理帧的类型

1.3.4.1 Beacon （信标）帧

1.3.4.2 探测请求（Probe Request）

1.3.4.3 探测响应（Probe Response）

1.3.4.4 IBSS 的数据待传指示通知信息（AT I M ）帧

1.3.4.5 解除关联和解除认证（Disassociation与Deauthentication）

1.3.4.6 关联请求（Association Request）

1.3.4.7 重新关联请求（Reassociation Request）

1.3.4.8 关联响应与重新关联响应（Association Response 与Reassociation Response）

1.3.4.9 认证（Authentication）

1.3.4.10 Action

1.4 帧发送以及连接与身份认证状态

1.4.1 帧等级

二、802.11网络协议细节

1.5 利用DCF进行竞争式访问

1.5.1 DCF 与错误复原

1.5.2 使用重传计数器

1.5.3 DCF 与延迟

1.5.4 Spectralink 语音优先性

1.5.5 帧的分段与重组

1.5.6 帧格式

1.5.7 Frame Control 位

1.5.8 Duration/ID 位

1.5.8.1 Duration ：设定NAV

1.5.8.2 免竞争期间所传送的帧

1.5.8.3 PS-Poll帧

1.5.9 Address 位

1.5.10 Basic Service Set ID (BSSID)

1.5.11 顺序控制位