网络流量实时速率是如何计算的？
首先我们要知道网络流量实时带宽是如何计算出来的，我们先拿接口流入流量来举例子。
通过SNMP的ifInOctets键值，我们可以获取到接口流入数据量的累计总量。那么如果我们想要计算流入流量的带宽速率，只需要固定一个时间间隔（比如30s），在前后分别获取一次累计总量，再计算差值，即可得出30s的流入数据量总量。这时候就是一个简单的速度计算了，数据总量差值/时间间隔，就是这段时间内的流入流量的平均带宽速率。这也和瞬时速率同理，只要时间间隔越短，越能代表瞬时速率。
那么我们就可以获得计算公式：
为什么要用Counter64来获取网络流量数据？
首先讲讲Counter32的问题在哪里吧。
上文我们提到，计算网络流量速率是通过获取累计总量的差值来计算的。于是就有一个很明显的问题：这是一个累计值，只要设备在使用就会导致这个值无限的累加，而计算机处理数据是有最大位长限制的。那如果达到该怎么办呢？就会将这个值清零再重新进行累加。这样就有一个最大值，达到最大值时就会清零重新进行计算。
而Counter32呢，这个最大值为(2^32-1)Byte，也就是超过4GB时就会进行清零。
当我们端口速率过大的时候，这个最大值显然是不够用了。当累计值被清零，而计算程序不知道时，就会导致计算速率不准确、异常。举个例子：
假设我们的业务量端口速率有2Gbps，也就是250MB/s，在16s左右时，累计值就会被清零。如果速率计算程序的时间间隔大于16s，则会造成数据计算异常。
诚然，将时间间隔修改成16s内，甚至10s，或许可以解决问题。但终究是治标不治本的方案。而且时间间隔这么短也会加大网络的开销，因为要频繁通过SNMP获取信息。假如端口的数量一多，更是会造成其他的开销增大。
我拿我的业务举例子，当时间间隔设置为30s的时候，流量速率显然是异常的。而设置为10s，则是正常的（其实也不完全正常）。
问题在哪不言而喻：Counter32的最大值太小，不够用。
而Counter64则是用于解决这个问题的。Counter64的最大值为(2^64-1)Byte，也就是16EB。就算是千兆口24小时跑满，也需要4000多年才能跑完。以目前的发展情况来看，16EB是完全足够用的，不需要担心。
所以只要将Counter32更换为Counter64就能解决问题。
如何更换Counter64来获取网络流量数据？
在SNMP中，更换到Counter64，键值以及OID也会发生变化：
流入流量：
| * | Counter32 | Counter64 |
|---|---|---|
| 键值 | ifInOctets | ifHCInOctets |
| OID | 1.3.6.1.2.1.2.2.1.10 | 1.3.6.1.2.1.31.1.1.1.6 |
流出流量：
| * | Counter32 | Counter64 |
|---|---|---|
| 键值 | ifOutOctets | ifHCOutOctets |
| OID | 1.3.6.1.2.1.2.2.1.16 | 1.3.6.1.2.1.31.1.1.1.10 |
计算公式也可以换一下了~
