像所有的網(wǎng)絡(luò)傳輸協(xié)議一樣，應(yīng)用層能感知到的丟包有可能產(chǎn)生于應(yīng)用層之下的所有層。
對(duì)于藍(lán)牙BLE而言，進(jìn)一步細(xì)化從機(jī)到主機(jī)的數(shù)據(jù)傳輸場(chǎng)景(假設(shè)使用的是Notify方式傳輸)，其數(shù)據(jù)傳輸路徑為：
1、從機(jī)的應(yīng)用層產(chǎn)生數(shù)據(jù)。
2、從機(jī)將數(shù)據(jù)從Host上位機(jī)轉(zhuǎn)交給Controller下位機(jī)。
3、從機(jī)Controller通過(guò)調(diào)制器，將數(shù)據(jù)在連接事件的射頻Tx階段發(fā)出。
4、主機(jī)Controller同時(shí)開(kāi)啟射頻Rx階段，接收無(wú)線(xiàn)電波并通過(guò)解調(diào)器還原數(shù)字信號(hào)。
5、主機(jī)將數(shù)據(jù)從Controller下位機(jī)轉(zhuǎn)交給Host上位機(jī)。
6、主機(jī)的應(yīng)用層接收數(shù)據(jù)。
根據(jù)上面的流程，進(jìn)一步分析一下可能產(chǎn)生數(shù)據(jù)丟包的環(huán)節(jié)。
在步驟2中，Host調(diào)用HCI函數(shù)將數(shù)據(jù)提交給Controller發(fā)送之前，會(huì)先將數(shù)據(jù)存放在Controller的數(shù)據(jù)緩沖區(qū)中，不同的藍(lán)牙芯片這個(gè)緩沖區(qū)的大小不同，比如Ti CC2541的射頻緩沖區(qū)只有4個(gè)PDU(4*20字節(jié))的大小。在緩沖區(qū)存滿(mǎn)后繼續(xù)調(diào)用HCI的Notify等函數(shù)會(huì)返回緩存區(qū)滿(mǎn)狀態(tài)位標(biāo)識(shí)。這是第一個(gè)有可能產(chǎn)生丟包的位置，若緩沖區(qū)滿(mǎn)且開(kāi)發(fā)者沒(méi)有對(duì)此狀態(tài)位進(jìn)行校驗(yàn)，則應(yīng)用層產(chǎn)生的數(shù)據(jù)會(huì)在傳遞給鏈路層之前丟失。
在步驟3、4中，從機(jī)的Controller在連接事件的Tx階段，會(huì)通過(guò)射頻依次發(fā)送緩沖區(qū)數(shù)據(jù)，并在下一個(gè)Rx階段根據(jù)捕獲和解析對(duì)端主機(jī)的數(shù)據(jù)包，從其鏈路層報(bào)頭中讀取NESN來(lái)確認(rèn)其在上一個(gè)Tx階段發(fā)送的數(shù)據(jù)包是否被對(duì)端主機(jī)鏈路層正確接收。由于鏈路層數(shù)據(jù)包序列號(hào)校驗(yàn)機(jī)制(SN和NESN)和重傳機(jī)制的存在，基本可以保證數(shù)據(jù)在物理層和鏈路層階段不會(huì)產(chǎn)生丟包，這跟互聯(lián)網(wǎng)的傳輸層TCP協(xié)議校驗(yàn)數(shù)據(jù)包序列和完整性基本類(lèi)似。
之所以上面用“基本”二字，是因?yàn)檫@里還是存在第二個(gè)有可能產(chǎn)生丟包的位置。由于BLE中使用的CRC校驗(yàn)是弱CRC，其只能保障傳輸字節(jié)的全部偶數(shù)位和部分奇數(shù)位不產(chǎn)生錯(cuò)誤，并無(wú)法保證所有數(shù)據(jù)在傳輸過(guò)程中不出錯(cuò)。那么一個(gè)可能性極小的場(chǎng)景是：CRC弱校驗(yàn)通過(guò)，但實(shí)際上NESN出現(xiàn)了錯(cuò)誤，而將本來(lái)應(yīng)該是0的位識(shí)別成了1，或者相反。而這個(gè)位差錯(cuò)讓本來(lái)應(yīng)該是錯(cuò)誤的序列號(hào)交替變成了正確的。
在步驟5中，主機(jī)將數(shù)據(jù)從Controller向上派發(fā)到Host，并轉(zhuǎn)到應(yīng)用層觸發(fā)回調(diào)通知。這里是第三個(gè)可能產(chǎn)生丟包的地方。原因同步驟2，但這里還有一點(diǎn)小區(qū)別，就是notify跟indicate的區(qū)別(反向傳輸中的write with/without response也是同理)，其本質(zhì)區(qū)別是數(shù)據(jù)接收成功的判斷標(biāo)志是以鏈路層確認(rèn)為準(zhǔn)還是以應(yīng)用層確認(rèn)為準(zhǔn)。前者是notify采用的方式，而后者是indicate采用的方式。可見(jiàn)如果采用notify做數(shù)據(jù)傳輸，鏈路層到應(yīng)用層這一步依然是有丟包的可能，比如鏈路層的數(shù)據(jù)傳輸速率大于應(yīng)用層的回調(diào)函數(shù)中對(duì)數(shù)據(jù)處理的速率，導(dǎo)致Host中數(shù)據(jù)緩沖區(qū)持續(xù)增長(zhǎng)，當(dāng)緩沖區(qū)滿(mǎn)后，主機(jī)的Controller將丟棄無(wú)法繼續(xù)保存的數(shù)據(jù)，并不會(huì)通知對(duì)端設(shè)備重傳。
而indicate方式下，每一個(gè)數(shù)據(jù)包的成功確認(rèn)都是以應(yīng)用層回調(diào)處理執(zhí)行完成為標(biāo)志，而通常數(shù)據(jù)的邏輯處理是一個(gè)耗時(shí)的操作，并且由于數(shù)據(jù)是在連接事件內(nèi)接受到，但同一個(gè)連接事件在開(kāi)始的時(shí)候主從機(jī)兩端的數(shù)據(jù)就已經(jīng)準(zhǔn)備好，由于連接事件的持續(xù)事件極短，在這段時(shí)間內(nèi)Controller的所有工作都集中在射頻的發(fā)射上，而不會(huì)從Host上位機(jī)接受數(shù)據(jù)和響應(yīng)，甚至有的藍(lán)牙芯片會(huì)有選項(xiàng)在這段時(shí)間內(nèi)直接掛起CPU，以防止其他中斷信號(hào)同步到達(dá)，干擾到射頻數(shù)據(jù)的發(fā)送效率。所以在indicate方式下，一個(gè)數(shù)據(jù)包至少要橫跨兩個(gè)甚至更多的連接事件時(shí)長(zhǎng)才可以確認(rèn)到達(dá)，從而發(fā)送下一個(gè)數(shù)據(jù)包，這就是有響應(yīng)的數(shù)據(jù)發(fā)送方式比無(wú)響應(yīng)要慢的原因。
最后一點(diǎn)，由于Android操作系統(tǒng)封裝了藍(lán)牙低層驅(qū)動(dòng)和實(shí)現(xiàn)，以上的6個(gè)步驟即使都正確完成，也只是意味著B(niǎo)luez或者Bluedroid這一層正確拿到了數(shù)據(jù)，但App要接收到這些數(shù)據(jù)還存在一個(gè)從操作系統(tǒng)到App的數(shù)據(jù)派發(fā)過(guò)程，indicate的數(shù)據(jù)確認(rèn)是在App得到數(shù)據(jù)派發(fā)并執(zhí)行完成回調(diào)后確認(rèn)，但notify會(huì)在Bluedroid接受到數(shù)據(jù)后即完成鏈路層確認(rèn)。而B(niǎo)luedroid向App的數(shù)據(jù)派發(fā)又存在一個(gè)緩沖區(qū)，當(dāng)藍(lán)牙連接而App沒(méi)有運(yùn)行的情況下緩沖區(qū)滿(mǎn)依然會(huì)產(chǎn)生丟包。(Android好像很難模擬這種情況，iOS在通過(guò)調(diào)試器終止App進(jìn)程的時(shí)候經(jīng)常會(huì)造成藍(lán)牙連接鏈路不同步斷開(kāi))
