USB 協議分析（含基本協議和 USB 請求和裝置列舉）
1. 物理特性
1.1 引腳
一條USB傳輸線分別由地線、電源線、D+和D-四條線構成，D+和D-是差分輸入線，它使用的是3.3V的電壓(與CMOS的5V電平不同)，而電源線和地線可向裝置提供5V電壓，最大電流為500mA(可以在程式設計中設定)。
| 引腳標號 | 訊號名稱 | 纜線顏色 |
| 1 | Vcc | 紅 |
| 2 | Data- (D-) | 白 |
| 3 | Data+ (D+) | 綠 |
| 4 | GND | 黑 |
USB裝置可以直接和HOST通訊，或者通過Hub和Host通訊。一個USB系統中僅有一個USB 主機，裝置包括USB功能裝置和USB HUB，最多支援127個裝置。物理連線指的是USB傳輸線。在USB 2.0系統中要求使用遮蔽雙絞線。
1.2 USB 訊號（差分訊號）
使用差分訊號進行資料傳輸，有效的降低外接帶來的干擾。
1.3 USB 訊號編碼（NRZI）
USB 資料傳輸的傳輸使用反向不歸零編碼進行傳送（NRZI）
反向不歸零編碼方式可以保證資料的完整性，而且不要求傳輸過程中由獨立的時鐘訊號。
1.4 USB 位元組序
LSB 先發，MSB 後
1.5 USB 裝置檢測
USB1.0和USB1.1支援1.5Mb/s的低速模式和12Mb/bs的全速模式。在USB2.0以上支援480Mb/s的高速模式。
當 USB 裝置接入系統時刻，系統通過檢測 USB 上的 D+或者D- 線上的上拉電阻的方式來識別低速
對於高速裝置，和全速裝置一樣，在D+上存在上拉電阻，對於高速裝置的的識別，主機先把高速裝置檢測為全速裝置，然後再通過“Chirp 序列”的匯流排握手機制來識別高速和全速裝置。
2. 通訊協議
USB 協議中：
域組成了包，不同的域，組成了不同型別的包（Token、Data、HandShake）。
多個包一起組成了一個事務（SetUp事務，IN 事務，OUT 事務）
多個事務，進而組成了不同型別的傳輸（控制傳輸，中斷傳輸，批量傳輸，同步傳輸）
2.1 包組成（Packets Content）
包（Packet）是USB系統中資訊傳輸的基本單元，所有資料都是經過打包後在總線上傳輸的。資料在 USB總線上的傳輸以包為單位，包只能在幀內傳輸。高速USB匯流排的幀週期為125us，全速以及低速 USB 匯流排的幀週期為 1ms。幀的起始由一個特定的包（SOF 包）表示，幀尾為 EOF。EOF不是一個包，而是一種電平狀態，EOF期間不允許有資料傳輸。
包是USB總線上資料傳輸的最小單位，不能被打斷或干擾，否則會引發錯誤。若干個資料包組成一次事務傳輸，一次事務傳輸也不能打斷，屬於一次事務傳輸的幾個包必須連續，不能跨幀完成。一次傳輸由一次到多次事務傳輸構成，可以跨幀完成。
USB包由五部分組成，即同步欄位（SYNC）、包識別符號欄位（PID）、資料欄位、迴圈冗餘校驗欄位（CRC）和包結尾欄位（EOP），包的基本格式如下圖：
2.1.1 PID 域
不同的 PID 標識了不同型別的 USB 包。由四位識別符號 + 四位識別符號反碼構成。
這裡只用（PID0~4）,PID4~7是PID0~4的取反，用來校驗 PID
根據 USB2.0 的 Spec 描述：
可以看出，由 PID 主要將 USB 的包分為了 4 類：
1. 令牌包（Token） :
0x01：輸出(OUT)啟動一個方向為主機到裝置的傳輸，幷包含了裝置地址和標號。
0x09：輸入(IN) 啟動一個方向為裝置到主機的傳輸，幷包含了裝置地址和標號。
0x05：幀起始(SOF)表示一個幀的開始，並且包含了相應的幀號。
0x0d：設定(SETUP)啟動一個控制傳輸，用於主機對裝置的初始化。
2. 資料包（Data） :
0x03：偶資料包(DATA0)。
0x0b：奇資料包(DATA1)。
0x07：高速裝置的 PID 的同步包
0x0f ：高速裝置分離包，高頻寬的同步事務
3. 握手包（HandShake）:
0x02：確認接收到無誤的資料包(ACK)。
0x0a：無效（NAK），接收(傳送)端正在忙而無法接收(傳送)資訊。
0x0e：錯誤（STALL），端點被禁止或不支援控制管道請求。
0x06：無響應（NYET）。
4. 特殊類：
前導包，錯誤包，分裂事務和 PING 測試
PID 資料傳輸方向
IN Device->Host
OUT Host->Device
SETUP Host->Device
PING Device->Host
2.1.2 Address 地址域
地址域有兩部分組成：
【 7bits 的裝置地址 ADDR + 4 bits 的端點地址 ENDP】
可以知道，USB 系統最大支援連結 127 個裝置，每個裝置最多 32 個端點。
這個 ENDP 只用在 IN/OUT/SETUP令牌包中。
2.1.3 Frame Number 幀號域
當USB令牌包的 PID 為 SOF時候，其資料欄位必須為11位的幀序列號。
幀號佔11位，主機每發出一個幀，幀號都會自加1，當幀號達到0x7FF時，將歸零重新開始計數。對於同步傳輸有重要意義。
2.1.4 Data 資料域
僅存在於 DATA 資訊包，根據不同的傳輸型別，擁有不同大小的位元組（0--1023位元組）
2.1.5 CRC域
用於進行資料的 CRC 校驗
2.2 包型別（Packets Type）
2.2.1 令牌包（Token）
根據域的 PID 描述，令牌包有4種：
令牌包有四種：
- OUT： 通知裝置將要輸出一個數據包
- IN： 通知裝置返回一個數據包
- SETUP： 只用在控制傳輸中，也是通知裝置將要輸出一個數據包，與OUT令牌的區別是：只使用DATA0資料包，且只能發到device的控制端點
- SOF： 在每幀開始時以廣播的形式傳送，針對USB全速裝置，主機每1ms/125us產生一個幀，USB主機會對當前幀號進行統計，每次幀開始時通過SOF包傳送幀號。
輸入包（IN）、輸出包（OUT）和設定包（SETUP）的格式都是一樣的：
SYNC + PID + ADDR(7 bits) + ENDP(4bits) + CRC5(五位的校驗碼)
幀起始包（SOF）的格式：
SYNC + PID + 11位FRAM + CRC5(五位的校驗碼)
SOF包由Host傳送給Device
對於full-speed匯流排，每隔1.00 ms ±0.0005 ms傳送一次；
對於high-speed匯流排，每隔125 μs ±0.0625 μs傳送一次；
2.2.2 資料包（Data）
分為DATA0包和DATA1包，當USB傳送資料的時候，如果一次傳送的資料長度大於相應端點的容量時，就需要把資料包分為好幾個包，分批發送，DATA0包和DATA1包交替傳送，即如果第一個資料包是DATA0，那第二個資料包就是DATA1。但也有例外情況，在同步傳輸中(四類傳輸型別中之一)，所有的資料包都是為DATA0，格式如下：
SYNC + PID + 0~1023位元組 + CRC16
2.2.3 握手包（Handshake）
結構最為簡單的包，格式如下：
SYNC + PID
- ACK： 傳輸正確完成
- NAK： 裝置暫時沒有準備好接收資料，或沒有準備好傳送資料
- STALL： 裝置不能用於傳輸
- NYET/ERR： 僅用於高速傳輸，裝置沒有準備好或出錯
2.3 事務（Transaction）
在USB上資料資訊的一次接收或傳送的處理過程稱為事務處理（Transaction）。一個事務由一系統packet組成，具體由哪些packet組成，它取決於具體的事務。
USB 事務分為3類：
| 事務 | 描述 |
|---|---|
| SetUp 事務 | 主機用來向裝置傳送控制命令 |
| Data IN 事務 | 主機用來從裝置讀取資料 |
| Data OUT 事務 | 主機用來向裝置傳送資料 |
2.3.1 SetUp 事務
•【正常】的設定事務處理
•【裝置忙時】的設定事務處理
•【裝置出錯】的設定事務處理
2.3.2 IN 事務
輸入事務處理：表示USB主機從總線上的某個USB裝置接收一個數據包的過程。
•【正常】的輸入事務處理
•【裝置忙】時的輸入事務處理
•【裝置出錯】時的輸入事務處理
2.3.3 OUT 事務
輸出事務處理：表示USB主機把一個數據包輸出到總線上的某個USB裝置的過程。
•【正常】的輸出事務處理
•【裝置忙時】的輸出事務處理
•【裝置出錯】的輸出事務處理
2.4 傳輸（Transfer）
在USB的傳輸中，定義了4種傳輸型別：
• 控制傳輸 (Control Transfer)
• 中斷傳輸 (Interrupt Transfer)
• 批量傳輸 (Bulk Transfer)
• 同步傳輸 (Isochronous)
2.4.1 控制傳輸 (Control Transfer)
控制傳輸由2～3個階段組成：
1) 建立階段(Setup)
2) 資料階段（無資料控制沒有此階段）(DATA)
3) 狀態階段(Status)
每個階段都由一次或多次（資料階段）事務傳輸組成（Transaction）。
控制資料由USB系統軟體用於配置裝置(在列舉時)，其它的驅動軟體可以選擇使用control transfer實現具體的功能，資料傳輸是不可丟失的。
1) 建立階段(Setup)
主機從USB裝置獲取配置資訊，並設定裝置的配置值。建立階段的資料交換包含了SETUP令牌封包、緊隨其後的DATA0資料封包以及ACK握手封包。它的作用是執行一個設定（概念含糊）的資料交換，並定義此控制傳輸的內容(即：在Data Stage中IN或OUT的data包個數，及傳送方向，在Setup Stage已經被設定)。
2) 資料階段(DATA)
資料傳輸階段：用來傳輸主機與裝置之間的資料。根據資料階段的資料傳輸的方向，控制傳輸又可分為3種類型：
A) 控制讀取（讀取USB描述符）
B) 控制寫入（配置USB裝置）
C) 無資料控制
A) 控制讀取
是將資料從裝置讀到主機上，讀取的資料USB裝置描述符。該過程如下圖的【Control Read】所示。對每一個數據信息包而言，首先，主機會發送一個IN令牌資訊包，表示要讀資料進來。然後，裝置將資料通過DATA1/DATA0資料資訊包回傳給主機。最後，主機將以下列的方式加以響應：當資料已經正確接收時，主機送出ACK令牌資訊包；當主機正在忙碌時，發出NAK握手資訊包；當發生了錯誤時，主機發出STALL握手資訊包。
B) 控制寫入
是將資料從主機傳到裝置上，所傳的資料即為對USB裝置的配置資訊，該過程如下的圖【Control Wirte】所示。對每一個數據信息包而言，主機將會送出一個OUT令牌資訊包，表示資料要送出去。緊接著，主機將資料通過DATA1/DATA0資料資訊包傳遞至裝置。最後，裝置將以下列方式加以響應：當資料已經正確接收時，裝置送出ACK令牌資訊包；當裝置正在忙碌時，裝置發出NAK握手資訊包；當發生了錯誤時，裝置發出STALL握手資訊包。
3) 狀態階段（Status）
狀態階段：用來表示整個傳輸的過程已完全結束。
狀態階段傳輸的方向必須與資料階段的方向相反，即原來是IN令牌封包，這個階段應為OUT令牌封包；反之，原來是OUT令牌封包，這個階段應為IN令牌封包。
對於【控制讀取】而言，主機會送出OUT令牌封包，其後再跟著0長度的DATA1封包。而此時，裝置也會做出相對應的動作，送ACK握手封包、NAK握手封包或STALL握手封包。
相對地對於【控制寫入】傳輸，主機會送出IN令牌封包，然後裝置送出表示完成狀態階段的0長度的DATA1封包，主機再做出相對應的動作：送ACK握手封包、NAK握手封包或STALL握手封包。
2.4.2 批量傳輸 (Bulk Transfer)
用於傳輸大量資料，要求傳輸不能出錯，但對時間沒有要求，適用於印表機、儲存裝置等。
批量傳輸是可靠的傳輸，需要握手包來表明傳輸的結果。若資料量比較大，將採用多次批量事務傳輸來完成全部資料的傳輸，傳輸過程中資料包的PID 按照 DATA0-DATA1-DATA0-…的方式翻轉，以保證傳送端和接收端的同步。
一次批量傳輸（Transfer）由 1 次到多次批量事務傳輸（Transaction）組成。
USB 允許連續 3次以下的傳輸錯誤，會重試該傳輸，若成功則將錯誤次數計數器清零，否則累加該計數器。超過三次後，HOST 認為該端點功能錯誤（STALL），放棄該端點的傳輸任務。（重傳機制）
翻轉同步：傳送端按照 DATA0-DATA1-DATA0-…的順序傳送資料包，只有成功的事務傳輸才會導致 PID 翻轉，也就是說傳送端只有在接收到 ACK 後才會翻轉 PID，傳送下一個資料包，否則會重試本次事務傳輸。同樣，若在接收端發現接收到到的資料包不是按照此順序翻轉的，比如連續收到兩個 DATA0，那麼接收端認為第二個 DATA0 是前一個 DATA0 的重傳。（重傳機制）
它通過在硬體級執行“錯誤檢測”和“重傳”來確保host與device之間“準確無誤”地傳輸資料，即可靠傳輸。它由三種包組成(即IN事務或OUT事務)：
1) token
2) data
3) handshake
For IN Token (即：IN Transaction)
• ACK: 表示host正確無誤地接收到資料
• NAK: 指示裝置暫時不能返回或接收資料 (如：裝置忙)
• STALL:指示裝置永遠停止，需要host軟體的干預 (如：裝置出錯)
For OUT Token (即：OUT Transaction)
如果接收到的資料包有誤，如：CRC錯誤，Device不傳送任何handshake包
• ACK: Device已經正確無誤地接收到資料包，且通知Host可以按順序傳送下一個資料包
• NAK: Device 已經正確無誤地接收到資料包，且通知Host重傳資料，由於Device臨時狀況(如buffer滿)
• STALL: 指示Device endpoint已經停止，且通知Host不再重傳
Bulk讀寫序列：
即由一系統IN事務或OUT事務組成。
2.4.3 中斷傳輸 (Interrupt Transfer)
中斷傳輸由IN或OUT事務組成。
中斷傳輸在流程上除不支援PING 之外，其他的跟批量傳輸是一樣的。他們之間的區別也僅在於事務傳輸發生的端點不一樣、支援的最大包長度不一樣、優先順序不一樣等這樣一些對使用者來說透明的東西。主機在排定中斷傳輸任務時，會根據對應中斷端點描述符中指定的查詢間隔發起中斷傳輸。中斷傳輸有較高的優先順序，僅次於同步傳輸。
同樣中斷傳輸也採用PID翻轉的機制來保證收發端資料同步。下圖為中斷傳輸的流程圖。
中斷傳輸方式總是用於對裝置的查詢，以確定是否有資料需要傳輸。因此中斷傳輸的方向總是從USB裝置到主機。
DATA0或DATA1中的包含的是中斷資訊，而不是中斷資料。
2.4.4 同步傳輸 (Isochronous)
它由兩種包組成：
1) token
2) data
同步傳輸不支援“handshake”和“重傳能力”，所以它是不可靠傳輸。
同步傳輸是不可靠的傳輸，所以它沒有握手包，也不支援PID翻轉。主機在排定事務傳輸時，同步傳輸有最高的優先順序。同步傳輸適用於必須以固定速率抵達或在指定時刻抵達，可以容忍偶爾錯誤的資料上。實時傳輸一般用於麥克風、喇叭、UVC Camera等裝置。實時傳輸只需令牌與資料兩個資訊包階段，沒有握手包，故資料傳錯時不會重傳。
3. USB 請求（用於控制傳輸）
標準的USB裝置請求命令是用在控制傳輸中的“初始設定步驟”裡的資料包階段(即DATA0，由8個位元組構成)。
也就是說，是控制傳輸的建立階段（SetUP）的 DATA0 的 8 個位元組。
命令共有11個，大小都是8個位元組，具有相同的結構，由5個欄位構成(欄位是標準請求命令的資料部分)，結構如下(括號中的數字表示位元組數，首字母bm,b,w分別表示點陣圖、位元組，雙位元組)：
bmRequestType(1) + bRequest(1) + wvalue(2) + wIndex(2) + wLength(2)
|
表1、USB命令的結構 |
||||
|
偏移量 |
域 |
長度（位元組） |
值 |
描述 |
|
0 |
bmRequestType |
1 |
點陣圖 |
請求特徵：
|
|
1 |
bRequest |
1 |
值 |
命令型別編碼值（見表2） |
|
2 |
wValue |
2 |
值 |
根據不同的命令，含義也不同 |
|
4 |
wIndex |
2 |
索引或偏移 |
根據不同的命令，含義也不同，主要用於傳送索引或偏 移 |
|
6 |
wLength |
2 |
如有資料傳送階段，此為資料位元組數。 |
|
其中 bRequest 為命令編碼值，含意見表2：
|
表2、USB標準命令的編碼值 |
|
|
bRequest |
Value |
|
GET_STATUS |
0 |
|
CLEAR_FEATURE |
1 |
|
為將來保留 |
2 |
|
SET_FEATURE |
3 |
|
為將來保留 |
4 |
|
SET_ADDRESS |
5 |
|
GET_DESCRIPTOR |
6 |
|
SET_DESCRIPTOR |
7 |
|
GET_CONFIGURATION |
8 |
|
SET_CONFIGURATION |
9 |
|
GET_INTERFACE |
10 |
|
SET_INTERFACE |
11 |
|
SYNCH_FRAME |
12 |
對應的11種的命令，其他的域的含義對照表為：
|
表3、USB的11種標準命令 |
||||||
|
命令 |
bmRequestType |
bRequest |
wValue |
wIndex |
wLength |
Data |
|
Clear_Feature |
00000000B |
CLEAR_FEATURE |
特性選擇符 |
零 |
零 |
無 |
|
Get_Configuration |
10000000B |
GET_CONFIGURATION |
零 |
零 |
一 |
配置值 |
|
Get_Descriptor |
10000000B |
GET_DESCRIPTOR |
描述表種類(高位元組，見表5）和索引（低位元組） |
零或語言標誌 |
描述表長 |
描述表 |
|
Get_Interface |
10000001B |
GET_INTERFACE |
零 |
介面號 |
一 |
可選設定 |
|
Get_Status |
10000000B |
GET_STATUS |
零 |
零（返回裝置狀態） |
二 |
裝置, |
|
Set_Address |
00000000B |
SET_ADDRESS |
裝置地址 |
零 |
零 |
無 |
|
Set_Configuration |
00000000B |
SET_CONFIGURATION |
配置值（高位元組為0，低位元組表示要設定的配置值） |
零 |
零 |
無 |
|
Set_Descriptor |
00000000B |
SET_DESCRIPTOR |
描述表種類（高位元組，見表5）和索引（低位元組） |
零或語言標誌 |
描述表長 |
描述表 |
|
Set_Feature |
00000000B |
SET_FEATURE |
特性選擇符(1表示裝置，0表示端點） |
零 |
零 |
無 |
|
Set_Interface |
00000001B |
SET_INTERFACE |
相關推薦USB 協議分析（含基本協議和 USB 請求和裝置列舉）1. 物理特性 1.1 引腳 一條USB傳輸線分別由地線、電源線、D+和D-四條線構成，D+和D-是差分輸入線，它使用的是3.3V的電壓(與CMOS的5V電平不同)，而電源線和地線可向裝置提供5V電壓，最大電流為500mA(可以在程式設計中設定)。 引腳標號 訊號 轉：【Java並發編程】之十六：深入Java內存模型——happen-before規則及其對DCL的分析（含代碼）無需 bit 對象引用 說了 final 緩存 機器 通過 round 轉載請註明出處：http://blog.csdn.net/ns_code/article/details/17348313 happen—before規則介紹 Java語言中有一個“先行發生 Python全棧day18（叠代器協議和for循環工作機制）內部 highlight next 計算 內置函數 如何 異常 初始 一次循環 一，什麽是叠代和遞歸 遞歸和叠代都是循環的一種。 簡單地說，遞歸是重復調用函數自身實現循環。叠代是函數內某段代碼實現循環，而叠代與普通循環的區別是：循環代碼中參與運算的變量同時是保存結果 USB協議學習（1）最近在工作中，要求學習USB的通訊協議來解決一個USB與測試版連線不成功的小問題。之前未接觸過任何關於USB的知識，相當於現在什麼都是重新學習，現打算記錄一下自己的學習經驗與過程。 在剛接觸USB協議前，我是先閱讀了圈圈大神的《圈圈教你玩USB》前兩章作為入門的鋪墊。圈圈大 【轉】USB 協議分析 設定USB地址 和 配置-字串描述符USB協議深入分析 設定USB地址 前面已經解釋主控器怎麼樣傳送裝置描述符下來，然後裝置返回相應的裝置描述符。下一步主控器的動作是做什麼呢？由於在USB總線上的裝置有很多，為了區分不同的裝置通訊，就需要給每個裝置分配一個地址，這跟網路中的IP ARP協議分析（一）一、ARP概述 網路中所有的協議（HTTP、URL、FTP、TELNET、TCP、UDP、ARP ······）都包含在TCP/IP協議棧中，從使用上來看：其中大部分協議都是大家平常上網所接觸到的，不知道你們是否留意過；從安全上來看：其中最不安全的協議就是ARP協議（在功能 基於某知名招聘網站的上海財務崗位資料分析（含excel視覺化）1.前言： 之前博主在學習PYTHON的爬蟲，正好有一個很要好的朋友向我詢問上海財務崗位的招聘資訊，便爬取了XX網當時上海財務崗的招聘資訊。 爬蟲採用了PYTHON2.7。其實博主是很看好PYTHON3.4，無奈相關的包並沒有全方面完美支援，網上的教程也面向的是2.7，於是乎 Wireshark之FTP協議分析（一）最近專案需求，需要抓取並還原網路中通過ftp傳輸的檔案。故對ftp協議進行了簡單學習，總結如下。 1. ftp協議概述 這部分內容我參考的百度文庫的一篇文件： 裡面講的很詳細。在此對重點的部分進行總結一下。 1）ftp服務端的用到兩個埠20和21。 2）FTP使 SPSS進行logistic迴歸分析（含示例）今天做數學建模2017B的時候用到了logistics分析來估計任務是否完成，給大家分享一下 二元logistics迴歸分析適用於因變數的結果只有兩個的情況，例如任務的完成與否（0或1），通過對任務是否完成的影響因素可以估計出任務為完成或未完成的預測概率。 例如2017B中對任務是否完成 Struts2-057/CVE-2018-11776兩個版本RCE漏洞分析（含EXP）0x01 前言 2018年8月22日，Apache Strust2釋出最新安全公告，Apache Struts2存在遠端程式碼執行的高危漏洞（S2-057/CVE-2018-11776），該漏洞由Semmle Security Research team的安全研究員Man YueMo發現。該漏洞是由於在St Wireshark之FTP協議分析（二）以實際抓包來分析ftp協議，加深理解。 環境： win7電腦+linux裝置，linux裝置為ftp服務端，win7電腦通過WinSCP的ftp主動方式（我得版本winscp預設是被動方式，需要從高階選項修改）來連線ftp服務端。 過程： 電腦（192.168.3.2 排序演算法的穩定性分析（含java程式碼）首先，排序演算法的穩定性大家應該都知道，通俗地講就是能保證排序前2個相等的數其在序列的前後位置順序和排序後它們兩個的前後位置順序相同。在簡單形式化一下，如果Ai = Aj，Ai原來在位置前，排序後Ai還是要在Aj位置前。 其次，說一下穩定性的好處。排序演算 演算法 歸併排序的複雜度分析（含圖解流程和Master公式）圖解流程 整體流程如下： 細節流程： 第一步： 第二步： 第三步： 第四步： 第五步： 第六步： 第七步： 第八步： 實驗五 網路層與鏈路層協議分析（PacketTracer）一、實驗目的： 通過本實驗，進一步熟悉PacketTracer的使用，學習路由器與交換機的基本配置，加深對網路層與鏈路層協議的理解。二、實驗內容：4.1 路由器交換機的基本配置開啟下面的實驗檔案，按提示完成實驗。——路由器的一些基本配置R1>show version此 Linux下使用Wireshark進行抓包分析（含SIP和RTP包）遇到需要在Linux下抓包分析的問題，便用到了wireshark，非常強大的抓包分析軟體，直接在系統裡面安裝，然後使用明亮抓包即可！ 我這裡用的是 server版，執行安裝： install wireshark 安裝成功後使用命令進行抓包： tshark -i e USB協議分析USB裝置邏輯結構 在USB裝置的邏輯組織中，包含裝置、配置、介面和端點4個層次。裝置通常有一個或多個配置，配置通常有一個或多個介面，介面通常有零個或多個端點。 USB裝置描述符 當我們把USB裝置（例如USB滑 RTSP再學習 -- RTSP協議分析（轉載）最近一直在看 RTSP，但是RTSP協議是個啥？還沒有搞清楚。首先流媒體百度百科上有這樣一段，從基本的名字上或多或少可以理解一下這些傳輸協議的區別。這很重要！！傳輸協議1、RSVP：資源預留協議2、RT VC訪問西門子S7-200的串列埠協議分析（實測通過）讀命令： PLC地址為2號,讀取VD300的值為0x0960 1. PC發讀取命令： 68 1B 1B 68 02 00 6C 32 01 00 00 00 00 000E 00 00 04 01 12 0A 10 06 00 01 00 01 84 00 09 60D5 【Java併發程式設計】之十六：深入Java記憶體模型——happen-before規則及其對DCL的分析（含程式碼）happen—before規則介紹 Java語言中有一個“先行發生”（happen—before）的規則，它是Java記憶體模型中定義的兩項操作之間的偏序關係，如果操作A先行發生於操作B，其意思就是說，在發生操作B之前，操作A產生的影響都能被操作B觀察到，“影響 Qt收費嗎？QT的三個授權協議分析（轉）關於Qt的三種協議以及是否收費，有以下引文： 引文一： 最近一直在學習 Qt。Qt 有兩個許可證：LGPL 和商業協議。這兩個協議在現在的 Qt 版本中的程式碼是完全一致的（潛在含義是，Qt 的早期版本，商業版的 Qt 通常包含有一些開源版本所沒有的庫，比如 | |||