分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.youkuaiyun.com/jiangjunshow
也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!
人们非常关心下载速度,对于使用非包月宽带以及使用付费CDN的用户而言,这是典型的拿钱买时间的行为,我支付的费用越高,希望的下载速度越快,所使用的累积带宽越大。关于各种测速方法也是汗牛充栋了,本文介绍一下TCP传输的测速。
网设备的pps线速都是超高的,如果你想优化那些设备的转发表,路由查找等逻辑,那是没找对地方,如今都是线卡硬件快速转发,交换网络处理都是纳秒级的,如果想优化路由转发等,那就去华为做光猫的部门谋份职位吧,那里会让你大展才华(绝非广告!)。再次重申,中间网络设备的处理时延主要是指排队时延。
知道了上述的因素,那么我们如果想测量一条TCP连接的数据传输速率,该怎么办呢?
理论非常简单但却很苍白!总数据量除以时间。然而问题是,我在哪个层面上去测量速率,我需要什么样的精度。如果说我想知道我的主机的处理速率,那么时间就是指本机的处理时延,数据量就是在该时延内通过的数据量,更一般的,如果我想知道一个文件从一个WEB服务器上下载下来的速率,我就需要用总文件大小除以下载完成需要的时间,这部分时间包括上述三种时延的总和。
这就涉及到了打点采样的问题了,本质上是两个问题,第一,在哪里开始打点采样,在哪里结束打点采样,第二,如何采样。
问题是当前速率真的就是用固定采样间隔的数据量除以时间间隔这么简单吗?非也!事实上,大部分的下载工具以及浏览器使用的都是移动指数平均算法,据我所知,早期的IE没有使用该算法,而是使用瞬时采样值直接除以时间这种,你会看到用早期的IE下载文件,剩余时间的抖动特别大,一会儿是几分钟,一会儿就是几小时。
公式我就不写了,挺麻烦的,一提到数学公式,懂的人不答理你,不懂的人说你装,也挺头大。
一般而言,像HTTP协议这样的,响应头里都会有文件的大小字节数,应用程序收到这么多字节就结束打点采样,就能统计到下载这么多数据所使用的时间。这完全是像HTTP协议这样的应用层协议的功劳,它告诉了我足够的信息。
在内核协议栈里面统计这些就难了!因为内核看到的只有一条TCP流,除非收到FIN,否则不知道什么时候会结束,也不会在一开始就知道后续数据的传输量...
TCP协议栈层面的瞬时速度是指导TCP发送策略本身用的,我们知道TCP是一个把全世界都卷进来的反馈系统(把它看作全世界范围的受蝴蝶效应影响的混沌系统也行),它需要网络的反馈来指导它未来的行为。之前我曾经不厌其烦的说ACK时钟如何影响TCP对拥塞的感应等等,诚然那些并没有错,但是在本文中,我们上升一个层面,来看一下ACK所确认的数据量和RTT的共同作用。这个作用所反应的就是TCP传输速率。我们需要一个速率可以代表一个趋势,然后用这个趋势去指导TCP拥塞窗口的调整,这就需要平滑掉该速率的噪点,于是又一次我们遇到了移动指数平均!
我们先看一下瞬时速度怎么测量。
TCP速率概述
首先,TCP速率受到多方面时延的影响,其中包括:1.本机以及对端机器的处理时延
这部分指的是发送端和接收端主机由于操作系统调度,中断,网卡数据包调度等处理引入的时延,基本属于操作系统的范畴,如果一个TCP数据包可以发送(窗口足够容纳),但是由于此时CPU被操作系统切换到了另外一个进程造成了延迟,或者说该数据包确实已经被发送了,但是由于网卡性能很低,需要将数据包的内容逐字节的拷贝,这也会引入额外的延迟,这部分时间就应该算到主机处理时延中。2.中间网络设备的处理时延
这是中间设备的“主机处理时延”,与端主机的处理时延类似,所不同的是,这部分时延大多数是排队时延,相比较排队时延,路由器或者交换机的处理时延可以忽略,当前骨干网设备的pps线速都是超高的,如果你想优化那些设备的转发表,路由查找等逻辑,那是没找对地方,如今都是线卡硬件快速转发,交换网络处理都是纳秒级的,如果想优化路由转发等,那就去华为做光猫的部门谋份职位吧,那里会让你大展才华(绝非广告!)。再次重申,中间网络设备的处理时延主要是指排队时延。
3.中间网络的传输时延
这部分就不多说了,我们知道,光速很快,但也是有个值的,也就是说,光从一个地方到达另一个地方也是需要时间的,因此数据在载波中通过介质从一个主机到达另一个主机或者中间节点也是需要时间的,这部分时间就是网络传输时间,它主要受到串扰,折射率,光色散等物理因素的影响。知道了上述的因素,那么我们如果想测量一条TCP连接的数据传输速率,该怎么办呢?
理论非常简单但却很苍白!总数据量除以时间。然而问题是,我在哪个层面上去测量速率,我需要什么样的精度。如果说我想知道我的主机的处理速率,那么时间就是指本机的处理时延,数据量就是在该时延内通过的数据量,更一般的,如果我想知道一个文件从一个WEB服务器上下载下来的速率,我就需要用总文件大小除以下载完成需要的时间,这部分时间包括上述三种时延的总和。
这就涉及到了打点采样的问题了,本质上是两个问题,第一,在哪里开始打点采样,在哪里结束打点采样,第二,如何采样。
应用层下载测速
1.瞬时速度的移动指数平均
打开浏览器,下载一个文件,各种下载工具或者浏览器自带的下载器上会显示一个下载速度以及剩余时间,这些值是怎么得到的呢?非常简单,下载工具或者浏览器本身也是一个应用程序,它可以在内部进行数据采样,比如固定间隔打点,然后统计这段间隔收到的数据量,二者相除得到速率,至于是剩余时间,一般通过协议获取,比如HTTP协议的响应中一般会有该信息,然后用剩余大小除以当前速率就是剩余时间。就是这么简单!问题是当前速率真的就是用固定采样间隔的数据量除以时间间隔这么简单吗?非也!事实上,大部分的下载工具以及浏览器使用的都是移动指数平均算法,据我所知,早期的IE没有使用该算法,而是使用瞬时采样值直接除以时间这种,你会看到用早期的IE下载文件,剩余时间的抖动特别大,一会儿是几分钟,一会儿就是几小时。
公式我就不写了,挺麻烦的,一提到数学公式,懂的人不答理你,不懂的人说你装,也挺头大。
2.平均速度的精确测量
上面说的是瞬时速度的测量方法,如果想统计一次下载的平均速度呢?事实上更简单,这个统计由于是下载完成后做的,因此此时我已经有了足够的信息去计算这个平均速度,下载文件的总大小我是有的,总时间我可以通过HTTP协议统计出来,二者相除就是最终答案。一般而言,像HTTP协议这样的,响应头里都会有文件的大小字节数,应用程序收到这么多字节就结束打点采样,就能统计到下载这么多数据所使用的时间。这完全是像HTTP协议这样的应用层协议的功劳,它告诉了我足够的信息。
在内核协议栈里面统计这些就难了!因为内核看到的只有一条TCP流,除非收到FIN,否则不知道什么时候会结束,也不会在一开始就知道后续数据的传输量...
协议栈传输测速
前段时间遇到一个需求,说是能不能在网卡层面统计到达某一个端口的流量,我说不能...我没有撒谎,即便能做到,我也不想做。1.瞬时速度的移动指数平均
下载工具的瞬时速度是让人看的,人们更关注通过这个瞬时速度计算出来的剩余时间,让人们有个预期,好安排在一部电影下载完成之前是不是有时间去楼下便利店买几罐啤酒。TCP要这个速度有什么用呢?TCP协议栈层面的瞬时速度是指导TCP发送策略本身用的,我们知道TCP是一个把全世界都卷进来的反馈系统(把它看作全世界范围的受蝴蝶效应影响的混沌系统也行),它需要网络的反馈来指导它未来的行为。之前我曾经不厌其烦的说ACK时钟如何影响TCP对拥塞的感应等等,诚然那些并没有错,但是在本文中,我们上升一个层面,来看一下ACK所确认的数据量和RTT的共同作用。这个作用所反应的就是TCP传输速率。我们需要一个速率可以代表一个趋势,然后用这个趋势去指导TCP拥塞窗口的调整,这就需要平滑掉该速率的噪点,于是又一次我们遇到了移动指数平均!
我们先看一下瞬时速度怎么测量。
可以使用和用户态的方法一样的算法,固定间隔内统计收到的数据量,但是在协议栈,我们有更好的算法,这是因为我们可