关上灯、蒙上头、闭眼做事，“小包性能”好不好，你怎么知道？

为啥总有人说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路由器本身的处理能力够强，同时局端支持，那么很多小包就可以集中发送，这样对于玩游戏这些即时性要求较强的操作，压缩会提高游戏的操作效率。