為啥總有人說iN在販賣焦慮呢？其實這件事就是一個“知道”和“不知道”的事情。

前幾天和家里人在吃水果，iN娘就說一個蘋果比另外一個蘋果甜好多。然后iN就開始問老媽會不會覺得一瓶NFC果汁會比另外一瓶NFC果汁甜呢？

NFC是英文Not From Concentrate的縮寫，中文稱為“非濃縮還原汁”，是將新鮮原果清洗后壓榨出果汁，經瞬間殺菌后直接灌裝（不經過濃縮及復原），完全保留了水果原有的新鮮風味。

老媽回答就是“并沒有，都是一個味道的”。

那這個問題就有意思了，水果不能保持每個都一樣甜，用一堆每個都不一樣甜的水果壓榨出的果汁直接罐裝后味道就統一了？這件事是不是有蹊蹺？

到老媽那邊的回答就是——果汁就是健康的，閉眼喝就得了，哪需要管那么多？

對話結束。

但今天看到這樣的一個留言：

也是一個閉著眼用就得了的感覺。

關上燈、蒙上頭、閉眼做事，哪管實際情況什么樣，其實這就是很多家庭用戶最終會面臨的網絡問題，像不像NFC果汁？看不到生產過程，看不明白配方，最終喝到的奇怪的統一味道的果汁，但消費者自己還真的沒覺得奇怪。

原因就在于對數據的不透明。

很不好意思的是，iN自己是可以看到日常使用網絡設備的小包情況的。

在Router OS的路由器上很簡單的就可以看到統計結果。一段時間內數據收發的分類統計列表是可以完全展現出來。這樣對于我們分析問題也就有了事實上的依據。

今天咱們就來聊聊小包是什么，以及小包是如何占用網速的。還有就是如何避免掉小包造成的影響。

先說下什么是“小包”。實際上小包（Small Packet）并沒有太嚴謹的定義，它是指網絡通信中傳輸的數據包的大小相對較小的數據單元。這里的“小包”通常是相對于網絡中傳輸的大數據量而言的。小包的大小通常由網絡協議、設備和應用程序決定，但通常是指數據包的大小在幾個字節到幾百字節之間。

在網絡通信中，數據通常被分割成數據包進行傳輸。小包可能會產生一些額外的網絡開銷，因為在處理和傳輸小包時，網絡設備和協議通常會增加一些額外的頭部信息，例如IP頭、TCP/UDP頭等。這些額外的頭部信息會占用帶寬并增加網絡的負載，從而影響網絡傳輸的效率和速度。

小包在某些情況下可能會導致網絡性能下降，例如在高負載或高延遲網絡環境下，處理大量小包可能會增加網絡的延遲和開銷。

同時，小包不僅僅是在路由器的WAN口上存在，在內網LAN網橋中，小包也會普遍存在。

我們在討論以太網的時候都會引入MTU和MRU的概念，MTU是網絡最大傳輸單元；MRU是網絡最大接收單元。如果大于了MTU，數據包就會被拆分。如果小呢？不好意思，就會占用整個MTU的大小進行傳輸。

所以說MTU是什么呢？其實就是一輛運貨的卡車，數據包盡量裝滿MTU的尺寸，在網絡上傳輸效率才不會“虧”。

當你在日常生活中看到一輛大卡車只運輸一點貨物的時候，會不會替司機心疼一下油費和時間呢？

如果看到小包的行為，實際上你也要心疼一下自己的帶寬。結構一下前面的截圖：

在一個單位時間內，路由器發出了328825948個數據包，接收了649535073個數據包。

其中小于64個字節的小包發出了29462個接收了28111個，這些數據基本上和上面一輛大卡車運一輛小摩托一樣可以視為空載了。

不過這些極小的小包量很少，只占有29462/328825948=0.00008959755%千萬分之八點九。對路由器的性能影響可以忽略不計。

低于127個字節，大于等于65個字節的小包發送了45791773個，接收了19022515個，這是典型的小包數據，一般的來說，設備的狀態信息，例如小米生態里面各種設備向服務器報告自身狀態大多是用這種小包通訊的。再有一些例如微信、QQ等軟件的通訊心跳包耶在這個范圍內。

從比例上來說發出的小包占據發出數據的13.9%，接收的小包占據接收量的2.9%，對于我們經常看視頻或者下載來說這些小包數據的影響并不大。但是發送數據達到13.9%再結合通常光纖寬帶的上行帶寬只有50Mbps就已經構成了一定的影響。

大于等于128個字節小于255個字節的數據包，發送了196113054個，接收了51064280個。分別占據了發送和下載的59.6%和7.8%。這些小包數據大多來自于APP的狀態信息和游戲操作數據。它們的處理效果決定了你在家玩游戲卡不卡。這是一個很典型的小包處理需求。尤其是一些在線游戲的數據包，往往都會以UDP的形式發送到服務器中，小包處理的能力關系到游戲的操作流暢與否。

大于等于256個字節小于511個字節的半K包發送了13274809個，接收了16974495個。這個區間段的數據只占發送和接收的4%和2.6%，實際上是屬于高不成低不就的數據范圍，一般的情況下，很少有程序會用到這個尺度的數據包。給大家帶來的影響并不大。

大于等于512個字節小于1023個字節的數據包發送了10312251個，接收了11539605個分別占據3.1%和1.7%和前面的包的概念是一樣的，還是半K包，在傳輸大量數據的時候用不夠用，而在傳輸少量的數據的時候用不完。

然后就是大于等于1024字節小于MTU的數據包了，發送了63304599個/接收了550906067。這是我們在看視頻、下載文件的時候會用到的數據包。一般的來說，這些數據包中大部分的長度是等于MTU的，一個大的數據包會被拆分為多個長度和MTU相同的數據包，最后余數余下一個小數據包會隨機填充到隊列里。這時候我們就可以看到發出的占比為19.23%接收的數據包為84.8%。例如iN的使用場景中，視頻電話、文件下載、流媒體等一系列的大數據流量都是會用到這個等級的大包。

大于等于1519的數據包為0，這是因為iN的MTU被設置為了1518，因此凡是大于1518的數據包都被拆分，我們在統計數據中也就看不到1519以上的數據包出現了。

我們來做一張統計圖：

這樣看起來就更直觀一些了吧？這回不是蒙上頭干事情了吧？

我們會發現我們發出去數據（藍色）的小包實際上還是蠻多的。而下載的數據（綠色）大部分會以大包來承載。

iN在家里在玩游戲、看視頻，基本上在家的操作是和大家沒太多區別的，小包的效率高低實際上會決定我們玩游戲的手感好壞。

怎么解決小包發送的效率問題呢？實際上，我們可以通過壓縮技術將網絡中的小包盡量多的壓縮到一個傳輸單元中進行釋放。這就有點貨車裝貨的概念了，雖然車廂里面并不是相同規格的貨物，但依舊要盡量裝滿，力爭發一趟車運送更多的貨。

還記得之前的文章給大家提到的Router OS中的Profile設置嗎？

在協議中勾選使用壓縮（Use Compression），如果你的ROS路由器本身的處理能力夠強，同時局端支持，那么很多小包就可以集中發送，這樣對于玩游戲這些即時性要求較強的操作，壓縮會提高游戲的操作效率。