本文为CoryXie原创译文，转载及有任何问题请联系cory.xie#gmail.com。
本章展示数据和信息如何在超高速上通过的一种高层次的描述。请阅读协议层一章关于低层次协议的细节。本章提供设备架构概述信息，设备框架一章会对此进一步展开。所有实现者应该阅读本章了解超高速的关键概念。
4.1 实现者观点 【Implementer Viewpoints】
超高速是与USB 2.0非常相似的，它提供了一个USB主机和连接的USB设备之间的通讯服务。该通讯模型保持了USB 2.0分层结构及通讯流的基本组成部分（即，点到点，同样的传输类型，等等）。请参阅Universal Serial Bus Specification, Revision 2.0第5章中USB 2.0通讯流的更多信息。
本章介绍数据和控制信息是如何在超高速主机及其所连接的超高速设备之间通讯（与USB 2.0）的差异。为了了解超高速数据流，下面的概念是有用的：
- 通讯流模型（Communication Flow Models）：第4.2节介绍了通讯如何在主机和设备之间通过超高速总线流动。
- 超高速协议综述（SuperSpeed Protocol Overview）：第4.3节给出了一个超高速协议的高层次概述，并将它与USB 2.0协议作比较。
- 总体传输描述（Generalized Transfer Description）：第4.4节提供了数据传输如何在超高速工作的概述，以后各节定义每个传输类型的操作限制。
- 设备通知（Device Notifications）：第4.4.9提供了概述了设备通知，一种允许设备异步通知设备上的事件或状态给其主机的特性。
- 可靠性与高效率：第4.4.10和4.4.11节总结了在超高速中可确保可靠性和提高效率的信息和机制。
4.2 超高速通讯流 【SuperSpeed Communication Flow】
超高速保留了熟悉的概念和机制，以及对端点，管道，和传输类型的支持。参照Universal Serial Bus Specification, Revision 2.0的细节。正如USB2.0，最终数据的消费者/生产者是端点。
端点的特性（最大数据包大小，突发长度等）在端点描述符和超高速端点伴侣描述符中报告。正如USB 2.0，端点使用寻址三剑客（设备地址，端点号，方向）来标识。
所有超高速设备必须至少实现默认的控制管道（端点0）。默认控制管道是在Universal Serial Bus Specification,Revision 2.0定义的控制管道。
4.2.1 管道 【Pipes】
超高速管道是在设备上的一个端点和主机上软件之间的一个关联。管道代表通过内存缓冲区在主机软件和设备上的端点之间的搬移数据的能力，并拥有在Universal Serial Bus Specification, Revision 2.0中定义的相同行为。主要区别是，当一个非超高速同步端点正忙时，它返回一个未准备好【Not Ready】（NRDY）响应，并且当它想再次提供服务时必须发送一个端点就绪【Endpoint Ready】（ERDY）通知。主机会按照在传输类型的限制范围内，在下一个可用的机会上重新调度事务交易（transaction）。
4.3 超高速协议概述 【SuperSpeed Protocol Overview】
正如在USB 3.0架构概述一章所提到的，超高速协议被设计成能够利用双重单工（dual-simplex）物理层的优势。所有的USB 2.0传输类型都被超高速协议支持。USB 2.0协议和超高速协议的差异被首先讨论，接着对超高速中使用的数据包进行简要说明。
4.3.1 与USB 2.0的差异 【Differences from USB 2.0】
超高速在框架层级是向后兼容USB 2.0的。然而，USB 2.0和超高速协议还是有一些根本性的差异：
- USB 2.0使用三部分事务交易（令牌，数据和握手），而超高速对这相同的三部分的使用是不相同的。对于输出（OUTs），令牌被列入数据包；而对于输入（INs），令牌则被握手所取代。
- USB 2.0不支持突发（bursting）而超高速支持连续突发（continuous bursting）。
- USB 2.0是一个半双工广播（broadcast）总线，而超高速是双重单工（dual-simplex）单播（unicast）总线，这就允许同时进行IN和OUT事务交易。
- USB 2.0使用轮询模型，而超高速使用异步通知。
- USB 2.0没有流（Streaming）的能力，而超高速支持对批量端点的流（Streaming）。
- USB 2.0没有提供机制来允许具有同步（isochronous）传输能力的设备来在服务间隔之间进入低功耗USB总线状态。超高速允许具有同步（isochronous）传输能力的设备在服务间隔之间自动进入低功耗链路状态。超高速主机可以传送PING包到目标同步设备，以便允许时间，在启动同步传输之前，将路径转换回到活动功率状态。
- 如果系统进入更低的系统电源状态，USB 2.0没有提供机制来让设备告知主机设备可以容忍多少延迟。因此，一个主机可能不能进入更低系统电源状态，因为可能会影响设备的性能（由于它缺乏一个对设备的电源策略的理解）。USB 3.0提供了一种机制，让超高速设备使用延迟容忍消息（Latency Tolerance Messaging）告知主机其对延迟的容忍。主机可以使用这些信息来建立一个系统电源策略，将设备的延迟容忍考虑在内。
- USB 2.0以固定的1 ms/125 μs间隔传输SOF/uSOF。取决于主机和系统软件的实现，设备驱动程序可能会在有限的小的调整区间内更改该间隔。USB 3.0增加了设备机制来发送总线间隔调整消息（Bus Interval Adjustment Message），被主机用来调整其125微秒总线间隔，高达+ / -13.333微秒。此外，主机可能会在一个总线间隔边界附近宽松的时序窗口（relaxed timing window）内发送同步时间戳包【Isochronous Timestamp Packet】（ITP）。
- USB 2.0的电源管理，包括链路电源管理，总是由主机直接发起。超高速支持链路级的电源管理，可由链路的任何一端启动。因此，每一个链路可以独立地在空闲（idle）时进入低功耗状态，而在需要通讯时退出。
- USB 2.0只在每个事务交易的端到端层级处理事务交易错误检测和恢复以及流量控制。超高速将这些功能在端到端和链路层级进行了拆分。
4.3.1.1 比较USB 2.0和超高速事务交易 【Comparing USB 2.0 and SuperSpeed Transactions】
超高速双重单工（dual-simplex）物理层允许信息同时在两个方向通行。超高速协议允许的发射器在收到握手之前发送多个数据包。对于OUT传输，在USB 2.0令牌中提供的信息被整合在数据包头中，因此不需要一个单独的令牌。对于IN传输，握手被发送到设备来请求数据。该设备可能会要么返回数据回应，要么返回一个STALL握手，或返回一个未准备好（NRDY）握手来推迟传输直到该设备已准备就绪。
USB 2.0广播数据包到所有已使能的下行端口。每一个设备都需要解码每个数据包的地址三剑客（设备地址，端点，方向）以确定它是否需要作出回应。超高速单播数据包，下游方向数据包被在主机和目标设备的直接路径上发送，而上游方向的数据包在在设备和主机之间的直接路径上发送。超高速数据包包含路由信息，被集线器使用，以确定数据包需要遍历（traverse）哪些下行端口来到达设备。有一个例外：同步时间戳包（ITP）是多播到所有活动端口的。
USB 2.0风格的轮训已被异步通知替换。超高速事务交易由主机发起，通过由主机发送一个请求后，紧接着一个设备响应。如果设备可以满足该请求，那么就要么接受或发送数据。如果端点停止（halted），设备应响应一个STALL握手。如果它由于缺乏缓冲空间或数据，不能满足请求，它回应一个未准备好【Not Ready】（NRDY）来告诉它的主机在这个时候无法处理请求。当设备可以满足请求时，它将会发送一个端点就绪【Endpoint Ready】（ERDY）到主机，届时主机将重新调度事务交易。
对转移到对包进行单播和有限的多播，加上异步通知，允许没有活动地传递数据包的链路被放置到低功耗状态。上游和下游端口合作，把链路放置到低功耗状态，并且集线器将向上游传导。允许链路伙伴控制自己的独立链路功耗状态，以及集线器传导在其任意的下游端口上看到的最高链路功耗状态到其上游端口，使得总线迅速进入可允许的最低功耗状态。
4.3.1.2 介绍超高速包 【Introduction to SuperSpeed Packets】
超高速包以一个16字节的头开始。有些包只包括一个头。所有的头都以数据包类型（Packet Type）信息开始，用来决定如何处理包。头被一个16位CRC校验码（CRC-16）保护，并以2个字节的链路控制字结束。 根据不同的类型（Type），大多数包包含路由信息（路由字串，Route String）和设备寻址三剑客（设备地址，端点号和方向）。路由字串是用来引导主机发送的数据包在直接路径上通过拓扑。由设备的发送的数据包被隐式路由，因为集线器始终将从任何下游端口看到的包转发到其上游端口。有四种基本类型的数据包：链路管理包（Link Management Packets），事务交易包（Transaction Packets），数据包（Data Packets），以及同步时间戳包（Isochronous Timestamp Packets）：
- 链路管理包（LMP）的只穿越的一对直接连接的端口，并且主要用于管理该链路。
- 事务交易包（TP）遍历直接连接主机和设备的路径上的所有链路。它是用来控制数据包流，配置设备和集线器等。请注意事务交易包没有数据有效载荷。
- 数据包（DP）遍历直接连接主机和设备的路径上的所有链路。数据包由两部分组成：类似TP的数据包头【Data Packet Header】（DPH）；以及数据包有效载荷【Data Packet Payload】（DPP），它由数据块，加上为确保数据的完整性的32位CRC（CRC-32）组成。
- 同步时间戳包【Isochronous Timestamp Packet】（ITP）是由主机发送的到所有活动链路的多播包。
4.4 总体传输描述 【Generalized Transfer Description】
每个发送到一个接收器的非同步（non-isochronous）数据包都由握手确认（被称为ACK事务交易包）。然而，由于超高速有独立的发送和接收通道这样的事实，在发送发送下一个数据包之前，发射器不必等待每个数据包明确的握手。
超高速保留了所有的基本数据流以及USB 2.0定义的传输概念，包括传输类型，管道和基础数据流模型。本节对与USB 2.0的差别进行了讨论，从协议层级开始，接着是传输类型限制。
USB 2.0规范采用了串行的事务交易模型。这实际上是说在开始下一个事务交易前，主机启动并完成一个事务交易（令牌总线，数据，握手）。分割的事务交易也遵循同样的模型，因为它们由完全的高速事务交易（令牌，数据，握手）组成，这些事务交易用与所有其他事务交易同样的模型完成。
超高速使用独立的发送和接收通道，提高了USB 2.0事务交易协议。其结果是，超高速USB交易协议基本上是一种分割事务交易（split transaction）协议，允许多个输出（OUT）"总线交易"以及最多一个输入（IN）"总线交易"同时在总线上活动。设备响应事务交易的顺序是固定以每个端点为基础的（例如，如果一个端点接收到三个数据包（DPs），该端点必须以这些数据包DPs被接收到的顺序，为每个数据包返回一个ACK TP）。设备响应发送到设备上的不同的端点的ACK或数据包DPs的顺序，是设备实现相关的，软件不能期望他们会以任何特定的顺序出现/完成。分割事务交易协议可基于信号比特率较好地扩展（跨多个事务交易，到多个功能端点），因为它不受传播延迟影响。
USB 2.0协议在继续到下一个调度的端点的总线事务交易之前，需要完成当前完整的事务交易{令牌总线，数据，握手}。所有的主机事务交易本质上都是在USB 2.0总线上的广播。与此相反，超高速协议不广播任何包（除了ITPs），并且包只遍历到达预定接收者的必要的链路。主机通过发送握手或者数据来开始事务交易，设备响应数据或者握手。如果设备没有数据可用或者不能接受数据，就会回应一个包说明其不能这么做。之后，当设备准备好接受或者发送数据时，就会发送一个通知给主机，指示其准备好恢复事务交易。此外，超高速提供将链路转换进入或者退出特定的低功耗状态的能力。进入更低的功耗状态要么是通过软件控制，或者在被软件使能后由硬件自动控制。提供了机制，可供主机和设备之间路径上所有的链路从非活动功耗状态自动转换进入活动功耗状态。
设备在端点描述符中报告每个端点的最大包大小。该大小只表示数据有效载荷长度，并不包括链路和协议层的任何开销。超高速带宽分配类似于USB 2.0。
4.4.1 数据突发 【Data Bursting】
数据突发（Data Bursting）通过消除了每个包的基础上的对确认的等待时间增强了有效性。超高速设备上的每个端点显示在它必须等待一个明确的握手之前，它可以发送/接收（称为最大数据突发大小）的数据包数量。 最大数据突发大小是各个端点的能力;主机从与此端点相关的超高速端点伴侣描述符来确定一个端点的最大数据突发大小（参考第9.6.7）。
主机可以动态地以每次交易的基础上改变突发大小，最大达到配置的最大突发大小。主机可能会使用不同大小的突发的例子包括，但不限于，一个主机上的公平策略以及对于中断流的重试。当端点是输出（OUT）时，主机可以很容易地控制突发长度（接收器必须始终能够管理事务交易突发大小）。当一个输入（IN）端点，主机可以在每次交易的基础上通过发送到设备的确认包的一个字段对端点限制突发大小。
4.4.2 输入传输 【IN Transfers】
主机和设备应遵守传输类型和端点特性的限制。 主机通过发送一个确认包（IN）到设备发起一次传输。这个确认包包含了将包路由到预想的端点的寻址信息。主机告诉设备它可以发送的数据包的数量，以及预计从设备接收到的第一个数据包的序列号。作为回应，端点会以适当的序列号发送数据包回主机。确认包还暗含地确认，以前的数据包被成功收到。
请注意，即使主机需要为每个接收到的数据包发送确认包，设备仍然可以发送被请求数量的数据包，而不必等待任何确认包。
超高速输入（IN）事务交易协议中如图4-1所示。一个超高速总线上的输入（IN）传输由一个或多个IN事务交易组成，并在出现下列任何情况之一时完成：
- 所有的传输数据成功被接收。
- 端点用比端点的最大数据包大小要小的数据包响应。
- 端点回应一个错误。
4.4.3 OUT Transfers
主机和设备应遵守传输类型和端点特性的限制。 主机通过发送一个突发的数据包到设备发起一次传输。每个数据包包含了将包路由到预想的端点的寻址信息。它也包括数据包的序列号。对于非同步事务交易，设备返回一个确认包，包括下一个数据包的序列号，并暗含地确认当前的数据包。
请注意，即使设备需要为每个接收到的数据包发送确认包，主机仍然可以发送最大突发大小数量的数据包，而不必等待确认包。
超高速输出（OUT）事务交易协议中如图4-2所示。一个超高速总线上的输出（OUT）传输一个或多个OUT事务交易组成，并在出现下列任何情况之一时完成：
- 所有的传输数据成功被接收。
- 主机发送一个比端点的最大数据包大小要小的数据包。
- 端点回应一个错误。
4.4.4 电源管理和性能【Power Management and Performance】
对不活动定时器以及设备驱动的链路电源管理的使用，提供了非常具有挑战性的电源管理能力。当主机发送一个位于一个集线器后面，并且其端口所在的链路处于非活动状态时，包不能穿透该链路，直到其返回到活动状态。对于IN事务交易的情形，主机不能开始另外一个IN事务交易，直到当前的一个完成。这一行为的效果可能对性能具有严重的影响。
为了在电源管理和好的性能之间平衡，使用了推后的概念（对于输入INs和输出OUTs两者）。当主机发起了一个事务交易，遇到处于非活动状态的链路，一个推后的响应被集线器发送，用来告诉主机这条特别路径现在处于推后管理状态，并且主机应该继续调度其他的事务交易。此外，集线器发送一个推后的请求给设备，通知它有一个事务交易被尝试。这一机制通知了主机由于电源管理增加了延时，并且允许主机缓和了由于链路电源管理导致的性能影响。
4.4.5 控制传输 【Control Transfers】
控制传输的目的和特性与Universal Serial Bus Specification, Revision 2.0的第5.5节中所定义的相同。本规范的协议层一章描述用于完成控制传输的数据包，总线事务，以及事务交易序列。本规范设备框架一章定义对设备使用的完整的标准命令代码。
每个设备必须实现默认控制管道作为消息管道。这条管道用于设备初始化和管理。这条管道用来访问设备描述符
并向设备提请求来管理其行为（在设备侧层级）。控制传输必须坚持同样的在Universal Serial Bus Specification, Revision 2.0定义的要求。
超高速系统会作出"最大努力"，以支持控制传输在主机和设备之间传送。如同USB 2.0一样，功能和客户端软件不能为控制传输请求特定的带宽。
4.4.5.1 控制传输包大小 【Control Transfer Packet Size】
控制端点有固定的最大控制传输的数据有效载荷为512字节，最大突发大小为1。这些极大值适用于所有在控制传输的数据阶段的数据事务交易。请参阅第8.12.2节的超高速控制传输的Setup和Status阶段情况的详细信息。
超高速设备必须报告其设备描述符的bMaxPacketSize字段的值为09H。解码控制管道的默认最大数据包大小的规则在第9.6.1节给出。默认控制管道必须最多支持32个序列号值 （即使用 [0-31] 范围内的序列值）。
对于设备到主机和主机到设备的数据阶段的数据传输和完成的要求， 总体上USB 2.0和超高速之间没有更改（参考Universal Serial Bus Specification, Revision 2.0的第5.5.3节）。
4.4.5.2 Control Transfer Bandwidth Requirements
设备无法指示需要的控制管道带宽。主机平衡所有控制管道以及在这些管道上的未完成的事务交易的总线访问要求，以在客户端软件和在设备上的功能之间提供"最佳努力"传送。这一策略与USB 2.0的策略是相同的。
超高速要求总线带宽被保留可供控制传输使用的情况如下：
- 一个控制传输的事务交易可能会被调度与其他任何已定义的传输类型功能端点的事务交易重合。
- 控制传输没有得到比其他尽力优先事务交易更好的优先权。
- 如果有多个端点的控制和批量传输未完成，不同的控制传输的端点以主机控制器实现相关的公平的访问策略被选择服务。
- 当一个控制端点传送了一个流量控制事件（定义见第8.10.1节），主机会将端点从活动的调度端点中删除。从设备收到就绪通知后，主机将恢复到该端点的传输。
这些要求允许一台主机和设备之间的控制传输定期以"最大努力"在超高速总线上搬移数据。Universal Serial Bus Specification, Revision 2.0的第5.5.4节定义的系统软件的"酌情行事"的行为，也同样适用于超高速控制传输。
4.4.5.3 控制传输数据序列 【Control Transfer Data Sequences】
超高速保留了Universal Serial Bus Specification, Revision 2.0第5.5.5节定义的控制传输的消息格式和总体阶段顺序。超高速协议定义了一些控制传输的Setup和Status阶段的变化。然而，Universal Serial Bus Specification, Revision 2.0第5.5.5节定义的所有常规的顺序要求和错误恢复情形，都可以直接映射到超高速协议中来。
4.4.6 批量传输 【Bulk Transfers】
批量传输的目标和特性与Universal Serial Bus Specification, Revision 2.0规范5.8节定义的类似。本规范的8.12.1节描述用来完成批量传输的详细的包，总线事务，以及事务序列。批量传输类型是以支持想要以极大的时间可变性，传输可以使用任意可用的超高速带宽，进行相当大量数据通讯的设备为目的的。一个超高速批量功能端点提供如下：
- 以带宽可用为基础访问超高速总线。
- 可保证的数据传输，但是没有带宽和延迟的保证。
超高速保留下面的批量管道特性：
- 批量管道通讯流没有数据内容结构的限制
- 批量管道是一个流管道，并且，因此，对于任意的管道实例，总是有通讯流进出主机。如果应用要求双向批量通讯流，必须使用两个批量管道（一个IN一个OUT）。
标准的USB批量管道提供了搬移一序列（stream）数据的能力。超高速增加了流（Streams）的概念，提供了协议层对于多个流（multi-stream）模型的支持。
4.4.6.1 批量传输数据包大小 【Bulk Transfer Data Packet Size】
批量传输端点应在其端点描述符中设置最大的数据包负载大小为1024字节。它还指定端点可以接受或者发送到超高速总线的突发大小。对于批量端点允许的突发大小应在1至16范围。所有超高速批量端点应当支持 [0-31]范围内的序列值。
主机必须支持任何超高速批量端点。主机应当支持所有批量突发大小。主机确保没有突发事务交易的任何数据包的数据有效载荷被发送到大于最大数据包大小的端点【译注：此句不太明确！】。此外，它不会发送多余报告的最大突发大小的数据包。
批量功能端点必须始终传输数据字段小于或等于1024字节的数据负载。如果批量传输有比之更多的数据，在突发事务交易的所有数据的有效载荷必须为1024字节长度，除了突发的最后一个数据有效载荷，它可能包含剩余数据。批量传输可能跨越多个总线事务交易。当端点进行下列操作之一时，批量传输完成时：
- 已经传输了如预期数量的数据。
- 传输了一个数据负载小于1024字节的数据包。
- 用STALL响应
4.4.6.2 批量传输端口要求 【Bulk Transfer Bandwidth Requirements】
与USB2.0一样，批量概念端点无法直视其需要的批量管道带宽。批量事务交易在超高速总线上直视以带宽可用为基础。超高速提供了对于客户软件和设备概念之间批量数据的"最大努力"的传送。在超高速总线上搬移控制传输比搬移批量事务交易优先级更高。当有多个端点的批量传输没有完成，主机将按照公平访问策略来给各个端点提供事务交易机会，这是依赖于主机实现的。
所有的等待与系统中的批量传输一起竞争使用系统的可用带宽。一个端点和其客户软件不能假设对于批量传输的特定服务比率。对于软件客户和其端点可用的总线时间可以随着其他设备的被插入和拔出系统而被改变，或者随着批量传输被请求到其他的功能端点而改变。客户软件不能假设批量和控制传输之间的顺序；也就是说，在某些情形下，批量传输可能被再控制传输之前被传送。
主机可以对于批量端点使用1到被报告的最大值的突发大小，来更有效地利用可用带宽。例如，可能有比可用带宽更多的批量传输，因此一个主机可以使用一个策略，每个事务交易使用更小的数据突发，来为所有未完成的批量数据流提供公平服务。
当一个批量端点传送了一个流量控制事件（定义见第8.10.1节），主机会将端点从活动的调度端点中删除。从设备收到就绪通知后，主机将恢复到该端点的传输。
4.4.6.3 批量传输数据序列 【Bulk Transfer Data Sequences】
批量事务交易使用在第8.10.2节中定义的标准突发序列达到可靠的数据传送。批量端点被一个适当的控制传输 （SetConfiguration，SetInterface，ClearEndpointFeature）初始化为最初的发送或接收的序列号和突发大小（参考第8.12.1.2节和第8.12.1.3节）。同样，主机当它成功完成了上述适当的控制传输之后，对批量端点也假定初始的发送或接收序列号以及突发大小。
超高速批量管道的停止（Halt）情形与为USB 2.0定义的影响批量端点相同的一面。从停止情形恢复也与USB 2.0相同（参考Universal Serial Bus Specification, Revision 2.0第5.8.5节）。批量管道停止情形包括对事务交易的STALL握手响应，或耗尽主机由于在传输错误时事务交易的重试策略。
4.4.6.4 批量流 【Bulk Streams】
标准的USB批量管道代表在主机和设备间通过主机内存缓冲区和设备的端点间搬移单数据流（FIFO）的数据的能力。超高速流提供对多流（multi-stream）模型的协议级别的支持，并利用"流式"管道通信模式（参考Universal Serial Bus Specification, Revision 2.0第5.3.2节）。 流使用主机和设备间的流协议（Stream Protocol）来管理。每个流都被分配一个流识别码（Stream ID）（SID）。
流协议（Stream Protocol）定义了一个握手，允许设备或者主机来建立与一个端点相关联的当前流ID【Current Stream (CStream) ID】。主机使用CStream ID来选择将被用来在管道上做后续数据传输的命令或操作特定的端点缓冲区【Endpoint Buffer(s)】。设备用CStream ID来选择将被使用到的功能数据缓冲区【Function Data buffer(s)】。
图4-3的例子代表一个输入批量管道，这里建立起了大量的流（Streams）。在主机内存中与每个流（Stream）相关的是一个或者多个端点缓冲区（Endpoint Buffers）来接收流数据（Stream data）。在设备端，也有一个相应的特定于命令或者功能的数据，会被传输到主机。
当设备有对特定的流可用的数据时（如图中的G），它就用发送ERDY加上CStream ID作为标签，并且主机会开始发送加有CStream ID标签的IN ACK TP到设备。设备会通过返回与CStream ID相关的功能数据，并且也是加上CStream ID为标签。当主机接收到数据，就用CStream ID来选择一组端点缓冲区（Endpoint Buffers）用来接收数据。
当功能数据被耗尽，设备终结该流（参考8.12.1.4节）。主机也被允许终结流，如果它用完了端点缓冲区的话。流可以被用来，例如，支持大容量设备命令排队（mass storage device command queuing）所需要的乱序（out-of-order）数据传输。
一个标准的批量端点有单组端点缓冲区（Endpoint Buffers）与之相关联。流扩展了一个端点可以访问的主机缓冲区个数，从1直到65533。在主机缓冲区和Stream ID之间有一个1:1的映射。
设备类定义的方法被用来协调主机用来选择端点缓冲区的流标识（Stream IDs），以及设备用来选择与特定的流相关联功能数据。典型地，这是通过带外机制（out-of-band mechanism）（例如，另一个端点）来完成的，该机制用来在主机和设备之间传递有效的流标识（Stream IDs）。
对于当前流（Current Stream）的选择可以被主机或者设备发起，在任一情况下，流协议（Stream Protocol）都提供了一个可以让选择被拒绝的方法。例如，主机可以拒绝一个由设备发起的选择，如果它没有可用的端点缓冲区可用。或者设备也可以拒绝由主机发起的流选择，如果它没有可用的功能数据。设备类定义什么时候一个流可以被主机或者设备选择，以及当一个流被拒绝时将会有的动作（参考第8.12.1.4节）。
制造商和设备类定义的算法组合，决定流如何在设备上被调度。流协议提供了用于启动，停止以及切换流的方法（参考第8.12.1.4节）。
流协议定义的机制允许设备或者主机来对流进行流量控制。这些机制与标准的批量流量控制部分重叠（overlap）。
主机可以启动或者停止一个流。例如，主机将会在其用完缓冲空间时停止流。当主机控制器通知设备这一情形时，设备可以切换到另一个流，或者等待并在主机接收到更多缓冲区时继续该相同的流。
流协议也提供了一个机制，允许主机在调度缓冲区（Endpoint Buffers）被加入到管道时，异步地通知设备。这在由于主机用完调度缓冲区而必须终结流，而设备还有功能数据要传输的情形有用；没有这种机制，设备可能必须周期性地重启该流（影响功耗管理），或者必须要一个长延时的带外方法（out-of-band method）。
由于流是基于一个标准的批量管道运行，一个错误就会让管道暂停（halt），停止所有的活动。排除暂停情形是通过控制管道的软件干预达到的，就像标准的批量管道一样。
最后，流极大地增加了批量管道的功能性。同时也具有最小化的影响，即在主机和设备端支持该特性的附加硬件要求。
4.4.7 中断传输 【Interrupt Transfers】
中断传输的目标和特性与Universal Serial Bus Specification, Revision 2.0规范5.7节定义的类似。超高速中断传输类型意图支持需要高可靠性方法以固定的服务间隔来通信小量数据的设备。本规范的协议层一章（Protocol Layer）详细描述用来完成中断传输的包，总线事务，以及事务序列的细节。一个超高速中断端点名义上提供如下：
- 可保证的最大服务间隔。
- 可保证的在下一个服务间隔内对于传输尝试的重试。
对一个中断达到而言，中断传输在每个服务间隔都会得到尝试。带宽被保留，以保证每个服务间隔一次的传输尝试。一旦一个传输成功，直到下一个服务间隔之前，不会再进行传输尝试。如果端点响应一个未准备就绪通知（not ready notification），或者一个确认，指示其不能接受更多包，那么主机不会尝试另一次传输，直到它接收到一个准备就绪通知（ready notification）。主机接着必须在接收到该通知后两个服务间隔内对该端点提供服务。所请求的服务间隔被在其端点描述符中描述。
超高速保留下面的中断管道特性：
- 中断管道通讯流没有数据内容结构的限制
- 中断管道是一个流管道，并且，因此， 总是单向的。
4.4.7.1 中断传输包大小 【Interrupt Transfer Packet Size】
中断传输端点要指定其可以在超高速总线上接受或传输的最大数据包负载大小。对于支持突发大小大于1的中断端点，唯一允许的最大的数据包负载大小为1024字节；对于突发大小等于1的中断端点，最大的数据包负载大小可以在1到1024之间任意大小。中断端点的最大突发大小是3。所有超高速中断端点应当支持 [0-31]范围内的序列值。
超高速中断端点只意图以固定的服务间隔搬移小量数据。超高速协议不要求中断事务交易具有最大大小。
主机必须支持超高速中断端点。主机应当支持所有允许的中断包大小和突发大小。主机确保没有突发事务交易的任何数据包的数据有效载荷被发送到大于最大数据包大小的端点【译注：此句不太明确！】。此外，它不应该发送多于报告的最大突发大小的数据包。
中断端点必须始终传输数据字段小于或等于端点的最大包大小的数据负载。如果中断传输有比最大包大小更多的数据，在突发事务交易的所有数据的有效载荷必须为最大包大小字节长度，除了突发的最后一个数据有效载荷，它可能包含剩余数据。中断传输可能跨越多个总线事务交易。当端点进行下列操作之一时，中断传输完成时：
- 已经传输了如预期数量的数据。
- 传输了一个数据负载小于最大包大小字节的数据包。
- 用STALL响应
4.4.7.2 中断传输带宽要求 【Interrupt Transfer Bandwidth Requirements】
周期端点在超高速总线上可以分配到80％总可用带宽。 中断管道通过其端点端点描述符指定其所需的服务间隔限定。中断端点可以指定所需的时间为2^（bInterval - 1）× 125微秒，其中bInterval 的范围是1到16（包括）。USB系统软件在配置期间将利用这一信息，以确定一个可以支持的周期。系统提供的周期可以短于设备预期的周期，端到由超高速定义的最短总线周期（125微秒，也称为总线间隔）。请注意，总线上的错误可阻止中断交易在总线上成功被传送，结果超过所需的周期。
超高速中断端点每个服务间隔可以搬移最多三个最大大小的数据包（3 × 1024个字节）。中断传输通过在每个服务间隔访问中断端点来在USB上搬移数据。对于中断端点，除了访问端点并请求中断传输之外，主机没有办法确定是否端点可以源发/接收数据。当被主机访问时，如果一个中断输入（IN）端点没有中断数据需要传输，或中断输出（OUT）端点接受缓冲区不足以接收数据时，它用流量控制响应作为回应。
端点只在有中断数据时提供中断数据，以避免出现软件客户端被错误地通知传输完成。零长度的数据有效载荷是有效的传输，并且可能对一些实现有用。主机可以在任何服务间隔内任意时间点访问端点。中断端点不应假设固定间距的事务交易尝试。中断端点只可以假设它会在服务间隔限定内收到一个事务交易尝试。错误可以阻止服务间隔内数据成功交换，主机无须在同一服务间隔重试事务交易，只需要在下一个服务间隔内重试事务交易。
4.4.7.3 中断传输数据顺序 【Interrupt Transfer Data Sequences】
中断事务交易使用在第8.10.2节中定义的标准突发序列达到可靠的数据传送。中断端点被一个适当的控制传输 （SetConfiguration，SetInterface，ClearEndpointFeature）初始化为最初的发送或接收的序列号和突发大小（参考第8.12.1.2节和第8.12.1.3节）。同样，主机当它成功完成了上述适当的控制传输之后，对中断端点也假定初始的发送或接收序列号以及突发大小。
超高速中断管道的停止（Halt）情形与为USB 2.0定义的影响中断端点相同的一面。从停止情形恢复也与USB 2.0相同（参考Universal Serial Bus Specification, Revision 2.0第5.8.5节）。中断管道停止情形包括对事务交易的STALL握手响应，或耗尽主机由于在传输错误时事务交易的重试策略。
4.4.8 等时传输 【Isochronous Transfers】
超高速等时传输的目标与Universal Serial Bus Specification, Revision 2.0规范5.6节定义的类似。正如USB 2.0，超高速等时传输类型的目的是支持流，以执行具有错误容忍性，在固定服务间隔范围内的周期传输。超高速不传输如USB 2.0的帧开始（start of frames），但是时序信息会被通过等时时间戳包【Isochronous Timestamp Packets (ITPs)】传输到设备。本规范的协议层一章（Protocol Layer）详细描述用来完成等时传输的包，总线事务，以及事务序列的细节。同时该部分也会描述时序信息是如何传递到设备的。超高速等时传输提供如下：
- 对于在超高速总线上的事务交易具有固定延迟的可保证带宽
- 通过管道的可保证的数据率，只要数据被提供给管道
对于等时端点，等时事务交易在每个服务间隔都会被尝试。被超高速总线允许的等时端点被保证他们在总线上所请求的带宽。主机可以在服务间隔的任意时间对特定的设备端点请求数据或者发送数据到设备。端点所请求的服务间隔在端点描述符中描述。超高速等时传输类型被设计为以相同的平均速率生产和消费数据，即源发及接收数据。超高速等时管道是流式管道，并且总是单向的。端点描述符识别是否一个等时管道的通信流是进还是出主机。如果设备要求双向等时通信流，必须使用两个等时管道，一个方向一个。
每当有一个等时传输需要在不活动的链路上传送时，超高速电源管理可能干扰等时传输。结果所造成的时延可能导致数据不能再服务间隔内到达。为了克服这一问题，超高速定义了PING 以及 PING_RESPONSE机制（参考8.5.7节）。在发起一次等时传输之前，主机可以发送一个PING到设备。设备使用PING_RESPONSE包作为响应，告诉主机在从主机到设备的所有链路都是活动的。
