USB协议在OSI模型中的分层归类及Hub工作原理咨询

Hey there, let's break down your questions step by step—first the OSI mapping for USB, then how USB hubs work and that address confusion you're having.

First off, it’s important to note that USB was never designed to fit the OSI model’s rigid 7-layer structure—it’s a purpose-built bus protocol, so direct 1:1 mappings are messy. That said, we can align parts of it to OSI layers, and your current mapping has a few key misalignments:

• Layer 7 (Application): Your note about application-specific drivers/protocols is partially right, but USB has standardized application-layer protocols called USB classes (like HID for keyboards/mice, Mass Storage for drives, or Audio). These sit atop the USB core stack, so they do map here—but it’s not just "additional drivers" but standardized communication rules for device types.
• Layer 6 (Presentation): You linked this to the OS, but USB doesn’t have a dedicated presentation layer. Data formatting (like byte-order conversion or endpoint-specific encoding) is handled within lower USB layers, and OS abstraction sits above the USB stack, not as a direct OSI layer match. This layer doesn’t cleanly map to USB.
• Layer 5 (Session): Power modes and configuration are part of USB’s device management (enumeration, suspend/resume), but USB doesn’t have a distinct session layer. These functions span what we’d call transport and core stack logic, so no direct OSI layer here.
• Layer 4 (Transport): Splitting data into frames is not the transport layer’s job—that’s Layer 2. USB’s transport layer handles different transfer types (control, bulk, interrupt, isochronous) and manages data flow between the host and device endpoints. Your mapping here is swapped with Layer 2.
• Layer 3 (Network): You equated endpoints to client addresses, but that’s incorrect. Endpoints are logical channels on a single device—USB uses device addresses (1-127, assigned during enumeration) to identify individual devices on the bus. This device addressing is the closest match to OSI’s network layer, not endpoints.
• Layer 2 (Link): Your notes about CRC5 for tokens and CRC16 for data packets are spot-on! This is exactly the USB Link layer, which handles framing, error checking, and token management. Correct here.
• Layer 1 (Physical): Differential signals (D+/D-), NRZI encoding, and connectors—this is 100% aligned with USB’s physical layer. Perfect.

Overall, USB’s closest OSI mappings are:

• Physical (Layer 1) → USB Physical Layer
• Link (Layer 2) → USB Link Layer
• Transport (Layer 4) → USB Transfer Layer
• Application (Layer 7) → USB Class Protocols

Layers 3, 5, and 6 don’t have direct equivalents in USB’s stack.

Let’s clear up how USB hubs work—they’re not like Ethernet switches, and your two-address idea doesn’t apply here:

How USB Hubs Actually Work #

USB is a host-centric bus: every single communication is initiated and mediated by the host (your computer). There is no peer-to-peer communication between USB devices. Hubs act as:

1. Bus repeaters: They amplify the USB signal to extend the bus length and support more devices.
2. Port managers: They track which devices are connected to each downstream port, and relay traffic between the host and the correct device.

Unlike Ethernet switches (which route packets between ports independently), hubs don’t make routing decisions. When the host sends a packet, the hub forwards it only to the port where the target device is connected (or all ports during device enumeration). Responses from devices are sent back up through the hub to the host—devices never send data directly to each other.

Addressing on USB: No Dual Addresses Needed #

Your thought about MAC-like and IP-like addresses comes from Ethernet’s peer-to-peer, multi-hop model, which doesn’t exist in USB:

• USB uses device addresses (1-127) assigned by the host during enumeration. Each device gets a unique address on the entire bus.
• Endpoints (0-15 per device) are logical channels for specific types of communication (e.g., a keyboard’s interrupt endpoint for key presses). When the host sends data, it includes both the device address and endpoint number to target exactly the right channel on the right device.

There’s no need for a "direct partner" or "target" address because all traffic flows through the host. The host knows exactly which device/endpoint to communicate with, and hubs just pass that traffic along to the correct port.

内容的提问来源于stack exchange，提问作者Jonas Müller