一、MTU基礎概念??
1. ??MTU定義??
??????????最大傳輸單元（MTU）?? 指單次數據傳輸中允許的最大字節數，包含協議頭部（3字節）和有效載荷（最多517字節）。BLE默認MTU為??23字節??（有效載荷20字節），但可通過協商提升至設備支持的最大值（如512字節）。
??2. 協商目的??
- 效率優化??：增大MTU可減少分包次數，提升傳輸速率（例如MTU=244時理論速度可達63KB/s，而默認僅5KB/s）。
- 保障??兼容性：設備能力差異（如舊手機僅支持23字節，新設備支持128+字節）需通過協商確定共同支持的MTU。
??二、MTU協商流程??
??步驟1：連接建立??
- BLE設備（中心設備/Central）與外圍設備（Peripheral）建立連接后，默認采用23字節MTU。
??步驟2：發起MTU請求??
- ??發起方??：通常由中心設備（如手機APP）通過L2CAP層發送? ??ATT_MTU_Request?? 命令，包含期望的MTU值（如185字節）。
- ??請求格式??：
Opcode: Exchange MTU Request (0x02) Client Rx MTU: [請求值] # 例如185
??步驟3：設備響應??
- 外圍設備收到請求后，回復? ??ATT_MTU_Response?? ：
- 若支持請求值，返回相同或更大的MTU；
- 若不支持，返回自身支持的最大值（如23字節）。
- ??響應格式??：
Opcode: Exchange MTU Response (0x03) Server Rx MTU: [響應值] # 例如23
??步驟4：協商結果生效??
- ??最終MTU??：取請求值（
Client Rx MTU）與響應值（Server Rx MTU）中的??較小值??作為新MTU。示例：手機請求185字節，設備響應23字節? →? 最終MTU=23字節。
??步驟5：數據傳輸優化??
- 應用層根據協商后的MTU調整數據包大小，避免分包傳輸。
??三、關鍵影響因素??
1. ??設備能力限制??
- 舊款手機/老芯片（如藍牙4.2）默認支持23字節，2020年后設備普遍支持≥128字節。
- iOS設備通常支持185字節，安卓可支持247字節（需協議棧支持）。
2. ??協議棧實現差異??
- ??自動協商??：iOS/Android系統層可能自動觸發MTU請求（如iOS的
peripheral:didUpdateValueForCharacteristic:回調）。 - ??手動觸發??：開發者可通過API（如Android的
requestMtu()）主動請求。
??3. 傳輸參數聯動??
MTU需與??連接間隔??（Connection Interval）協同優化：
- 短間隔（如7.5ms） + 大MTU → 高吞吐量；
- 長間隔（如100ms） + 小MTU → 低功耗。
??四、注意事項??
??1. 兼容性處理??
- 在APP端檢測設備藍牙版本（4.2以下需保持默認MTU）。
- 協商失敗時降級至23字節，避免連接中斷。
2. ??性能權衡??
過大的MTU可能因數據包重傳增加延遲，建議根據場景平衡：
- ??實時控制??（如鍵盤鼠標）：小MTU（23-64字節）；
- ??固件升級??：大MTU（128-247字節）。
??3. 調試工具??
- 使用??BLE嗅探器??（BLE Sniffer）抓包分析
ATT_MTU_Request/Response字段。
??五、MTU協商與傳輸效率關系??
| ??MTU大小?? | ??有效載荷?? | ??理論速率（15ms間隔）?? |
|---|---|---|
| 23字節 | 20字節 | ≈5 KB/s |
| 128字節 | 125字節 | ≈33 KB/s |
| 247字節 | 244字節 | ≈65 KB/s |
注：速率計算假設每連接事件傳輸4個數據包。
??總結??：MTU協商是BLE連接后動態優化傳輸效率的核心機制，需結合設備能力、協議棧特性及應用場景綜合設計。實際開發中，建議優先通過系統API自動協商，并在關鍵業務（如OTA升級）前手動請求最大支持值以提升性能。
