BLE通信由兩種設備類(lèi)型構成—— Client和Server。
Server提供數據服務(wù)，所以一般來(lái)說(shuō)設備是Server，手機是Client。Server和Client通過(guò)ATT PDU進(jìn)行交互，Server通過(guò)characteristic對數據進(jìn)行封裝。多個(gè)characteristic組成一個(gè)Service，一個(gè)Service是一個(gè)獨立的服務(wù)單元，或者說(shuō)service是一個(gè)基本的BLE應用。如果某個(gè)service是一個(gè)藍牙聯(lián)盟定義的標準服務(wù)，也可以稱(chēng)其為profile，比如HID/心率計/體溫計/血糖儀等，都是標準藍牙服務(wù)，因此都有相應的profile規格書(shū)。
一. characteristic
一個(gè)characteristic包含三種條目：characteristic聲明，characteristic的值以及characteristic的描述符（可以有多個(gè)描述符）：
1.1 Characteristic declaration
就是每個(gè)characteristic的分界符。解析時(shí)一旦遇到characteristicdeclaration，就可以認為接下來(lái)又是一個(gè)新的characteristic了，同時(shí)characteristic declaration還將包含value的讀寫(xiě)屬性等。
1.2 Characteristic value
就是數據的值了，這個(gè)比較好理解就不再說(shuō)了。
1.3 Characteristic descriptor
就是數據的額外信息。比如溫度的單位是什么，數據是用小數表示還是百分比表示等之類(lèi)的數據描述信息。CCCD是一種特殊的characteristicdescriptor，當characteristic具有notify或者indicate操作功能時(shí)，那么必須為其添加相應CCCD，以方便client來(lái)使能或者禁止notify或者indicate功能。
不管是characteristic declaration，characteristic value還是characteristic descriptor，實(shí)現的時(shí)候，我們都是用attribute來(lái)表達的，也就是說(shuō)，他們每一個(gè)都是一個(gè)attribute，attribute可以用下圖來(lái)表示：
二. Attribute
2.1 Attribute handle
Attribute句柄。Client要訪(fǎng)問(wèn)Server的Attribute，都是通過(guò)這個(gè)句柄來(lái)訪(fǎng)問(wèn)的，也就是說(shuō)ATT PDU一般都包含handle的值。用戶(hù)在軟件代碼添加characteristic的時(shí)候，系統會(huì )自動(dòng)按順序地為相關(guān)attribute生成句柄。
2.2 Attribute type
Attribute類(lèi)型。在BLE中我們使用UUID來(lái)定義數據的類(lèi)型，UUID是128 bit的，所以我們有足夠的UUID來(lái)表達萬(wàn)事萬(wàn)物。其中有一個(gè)UUID非常特殊，它被藍牙聯(lián)盟采用為官方UUID，這個(gè)UUID如下所示：0000xxxx-0000-1000-8000-00805F9B34FB, 由于這個(gè)UUID眾所周知，藍牙聯(lián)盟將自己定義的attribute或者數據只用16bit UUID來(lái)表示，比如0x1234，其實(shí)它也是128bit，完整表示為：
00001234-0000-1000-8000-00805F9B34FB = 16 bit UUID 0x1234
Attribute type一般是由service和characteristic規格來(lái)定義，站在藍牙協(xié)議棧角度來(lái)看，ATT層定義了一個(gè)通信的基本框架，數據的基本結構，以及通信的指令，而GATT層就是前文所述的service和characteristic，GATT層用來(lái)賦予每個(gè)數據一個(gè)具體的內涵，讓數據變得有結構和意義。換句話(huà)說(shuō)，沒(méi)有GATT層，低功耗藍牙也可以通信起來(lái)，但會(huì )產(chǎn)生兼容性問(wèn)題以及通信的低效率。
2.3 Attribute value
就是數據真正的值，0到512字節長(cháng)。
2.4 Attribute permissions
Attribute的權限屬性，權限屬性不會(huì )直接在空中包中體現，而是隱含在A(yíng)TT命令的操作結果中。目前主要有如下四種權限屬性：
●Open，直接可以讀或者寫(xiě)
●No Access，禁止讀或者寫(xiě)
●Authentication，需要配對才能讀或者寫(xiě)，由于配對有多種類(lèi)型，因此authentication又衍生多種子類(lèi)型，比如帶不帶MITM，有沒(méi)有LESC
●Authorization，跟open一樣，不過(guò)server返回attribute的值之前需要應用先授權，也就是說(shuō)應用可以在回調函數里面去修改讀或者寫(xiě)的原始值。
●Signed，簽名后才能讀或者寫(xiě)，這個(gè)用得比較少。
Client和Server之間是通過(guò)ATT PDU來(lái)通信的，ATT PDU主要包括4類(lèi)：讀，寫(xiě)，notify和indicate。如果一個(gè)命令需要response，那么會(huì )在相應命令后面加上request；如果一個(gè)命令只需要ACK而不需要response，那么它的后面就不會(huì )帶request。這里要特別強調一點(diǎn)，BLE所有命令都是“必達”的，也就是說(shuō)每個(gè)命令發(fā)出去之后，會(huì )立馬等ACK信息，如果收到了ACK包，發(fā)起方認為命令完成；否則發(fā)起方會(huì )一直重傳該命令直到超時(shí)導致BLE連接斷開(kāi)。換句話(huà)說(shuō)，只要你的BLE沒(méi)有斷開(kāi)，那么你之前發(fā)送的數據包，不管它是用什么ATT PDU來(lái)發(fā)送的，它肯定被對方收到了。我估計很多人對此會(huì )產(chǎn)生疑問(wèn)，因為他們經(jīng)常碰到丟包的情況，其實(shí)大家經(jīng)常碰到的“丟包”，不是空中把包丟了或者包在空中被干擾了，而是大家發(fā)送的代碼寫(xiě)得有問(wèn)題，導致你要發(fā)送的包沒(méi)有被安全送達到協(xié)議棧射頻FIFO中，所以以后大家碰到丟包情況，請先檢查你的代碼，保證你的數據包正確完整安全地送達到協(xié)議棧射頻FIFO中，只要數據包放到了協(xié)議棧射頻FIFO中，藍牙協(xié)議棧就能保證該數據包“必達”對方。既然每個(gè)ATT命令都必達對方，那么還需要request做什么？如果一個(gè)命令帶有request后綴，那么發(fā)起方就可以收到命令的response包，這個(gè)response包在應用層是有回調事件的，而前述的ACK包在應用層是沒(méi)有回調事件的。所以采用request/response方式，應用層可以按順序地發(fā)送一些數據包，這個(gè)在很多應用場(chǎng)合是非常有用的。相反，如果你對應用層數據包的順序沒(méi)有要求，那么就可以不使用request/response形式。另外Request/response有一個(gè)副作用：大大降低通信的吞吐率，因為request/response必須在不同的連接間隔中出現，也就是說(shuō)，你在間隔1中發(fā)送了一個(gè)request命令，那么response包必須在間隔2或者稍后間隔中回復，而不能在間隔1中回復，這就導致兩個(gè)連接間隔最多只能發(fā)一個(gè)數據包，而不帶request后綴的ATT命令就沒(méi)有這個(gè)問(wèn)題，在同一個(gè)連接間隔中，你可以同時(shí)發(fā)多個(gè)數據包，這樣將大大提高數據的吞吐率。
常用的帶request的命令：所有read命令，writerequest，indication等，而常用的不帶request的命令有write command，notification等。
