很多用戶以及互聯(lián)網(wǎng)開發(fā)、桌面應用開發(fā)者很可能難以理解，因為TCP/IP是最為人熟知的網(wǎng)絡通信協(xié)議。但這是無線通信技術應用中的現(xiàn)實。
這個問題難以簡單地回答，因為它是綜合權衡多方因素之后的結論。篇幅所限，我們就用盡可能簡短的方式來說清楚這個問題。
IP協(xié)議是一種連續(xù)傳輸固定格式數(shù)據(jù)包的協(xié)議。IP協(xié)議針對有線網(wǎng)絡設計，有線網(wǎng)絡的特點是信道質(zhì)量穩(wěn)定，數(shù)據(jù)率非常高, 適合傳輸大量數(shù)據(jù)。圖1給出了IP數(shù)據(jù)包的格式，標明了包內(nèi)部各個字段的字節(jié)長度。
可以看出，一個IP數(shù)據(jù)包至少包含20個字節(jié)的固定包頭，用于IP協(xié)議控制和尋址。這部分內(nèi)容對于實際傳輸?shù)挠脩魯?shù)據(jù)來說是沒有用處的，因此這個包頭的字節(jié)長度代表了傳輸一定量的有效數(shù)據(jù)所需付出的代價，也稱為開銷(overhead)。數(shù)據(jù)包中除了包頭以外的有效用戶數(shù)據(jù)被稱為凈載(payload)。開銷大小可以通過如下公式計算：
? ? ? ?overhead = 1 - payload長度 ／ 數(shù)據(jù)包總長度
這是一個百分比值。顯然，overhead值越低，那么通信的效率越高。
然而有了IP協(xié)議還不能直接通信，還要配合使用更上一層的TCP協(xié)議。TCP協(xié)議的數(shù)據(jù)包同樣有20個字節(jié)的包頭，這樣在一個完整的TCP/IP數(shù)據(jù)包里就包含了20+20=40個字節(jié)的包頭。
對于TCP/IP協(xié)議來說這個包頭長度并不是什么大問題。因為一個TCP/IP數(shù)據(jù)包最大長度可以達到64,000個字節(jié)，相比這么大的數(shù)據(jù)包長度，overhead = 0.06%, 幾乎可以忽略不計，通信效率可以說相當高。
但是無線環(huán)境情況完全不同。無線信道的特點是信道質(zhì)量非常不穩(wěn)定，無線射頻信號會發(fā)生衰減和反射，導致傳輸中錯誤概率相當高。這樣無線數(shù)據(jù)包的長度就不能太長，否則一旦發(fā)生錯誤，重傳的代價非常高，很容易堵塞整個傳輸信道。例如，64,000個字節(jié)中，只要有一個bit出錯，那么所有64,000個字節(jié)全部要重新傳一遍。這樣太可怕了。所以無線通信協(xié)議普通都采用短數(shù)據(jù)包的形式。短包的大小到底多長，是根據(jù)不同的射頻頻率、調(diào)制編碼方式、符號速率、使用環(huán)境的要求等共同決定的。例如，IEEE 802.15.1(藍牙)標準規(guī)定數(shù)據(jù)包長度為251個字節(jié)，IEEE 802.15.4(Zigbee)規(guī)定數(shù)據(jù)包長度僅為127個字節(jié)，LoRa數(shù)據(jù)包長度最大234個字節(jié)。
圖2是802.15.4 Zigbee協(xié)議的數(shù)據(jù)包結構
可以計算出Zigbee數(shù)據(jù)包的overhead約為 1- 102/133 = 23.3%.
圖3是802.15.1藍牙數(shù)據(jù)包的結構，
可以計算出藍牙數(shù)據(jù)包的overhead = 1 - 246/265 = 7.1%
如果我們要在802.15.1和802.15.4標準上傳輸TCP/IP數(shù)據(jù)包的話，那么每個數(shù)據(jù)包的傳輸開銷就不再是可以忽略不計，而是嚴重影響效率了：
IP over IEEE 802.15.1： overhead = 1 - 206/266 = 22.5%
IP over IEEE 802.15.4: ?overhead = 1 - 62/133 = 53.3%
因為每個數(shù)據(jù)包都要付出這樣的代價，這樣的數(shù)字已經(jīng)難以接受了。這些數(shù)字意味著什么？打個比方，假設中國電信賣給你10M的寬帶，但你實際只能用4M，而中國電信是按10M來收費的，那你恐怕就要去投訴了。
那難道就沒有辦法改進這個問題了嗎？有，答案是6LowPAN。一些聰明的IP協(xié)議的擁躉找到了優(yōu)化的辦法：壓縮包頭。如果能夠把40個字節(jié)的包頭壓縮到很短，那效率不就可以提高了嗎？在6LowPAN的標準里，20個字節(jié)在最理想情況下可以被壓縮到2個字節(jié)。如此一來，開銷的問題就顯得不那么嚴重了。圖4中給出了6LowPAN數(shù)據(jù)包的結構。
那是否這就是我們所需要的完美解決方案呢？
沒那么簡單。6LowPAN仍然有自己的局限性。
1. 能夠壓縮的前提是在同一種物理連接的無線局部網(wǎng)絡內(nèi)部，比如同一個藍牙網(wǎng)絡內(nèi)，或者同一個LoRa網(wǎng)絡，并且限在一跳(hop)之內(nèi)。如果要向不在同一網(wǎng)絡內(nèi)的設備發(fā)送數(shù)據(jù)，比如一個藍牙網(wǎng)絡中的設備向一個LoRa設備發(fā)送數(shù)據(jù)，那么這個方法就失去作用了。
2. IPv6協(xié)議要求數(shù)據(jù)包最小的長度為1280個字節(jié)，而顯然無線網(wǎng)絡中的數(shù)據(jù)包是達不到這個要求的。因此在無線網(wǎng)絡中傳輸時 6LowPAN協(xié)議棧需要人為地進行分片和填充以適合IP網(wǎng)絡的要求。這在同一無線技術網(wǎng)絡中還容易實現(xiàn)，但是在包含了多種無線技術網(wǎng)絡環(huán)境中這個工作就變得很復雜，要付出很多額外的開銷。
因此，在解決這些問題之前，6LowPAN和IPv6要在無線通信網(wǎng)絡中得到普及，還有很長的路要走。
