访问统计报告不能准确记录多线程下载流量
Top : Prim@Hosting : Web服务
文章编号: |
 |
000679 |
评分: |
 |
5.0 / 5.0 (总投票2)
|
阅览次数: |
 |
1931 |
|
这个是由于多线程下载软件的原理来决定的
假定一个文件有10MB,分成10个进程下载
第一个线程是从文件头部开始下载,即1~1024KB
第二个线程从第2MB开始下载即,1025~2048KB
以此类推,共10个线程
第一个线程下载时候,下载软件会告诉web服务器,从文件起始下载
但并不告诉web服务器下载的终点在哪里。所以web服务器认为客户端要下载整个文件。
这个时候,web server的日志中留下的是整个文件的大小。
但是,当下载完成1024KB后,下载软件会主动停止连接
包括IIS、Apache在内的web服务器,日志都只在获取文件的一瞬间记录下文件总大小
而不会关心客户端是否在传输到一半就停止
因此,web服务器中,唯一的一条记录,就是下载软件下载了整10MB个文件。
同样,第二个进程开始,下载软件会告诉web服务器,从第1025KB下载
但是,并不告诉web服务器下载终点什么时候结束。
因此,web服务器认为客户端要下载的大小是10MB减去1MB等于9MB,即下载客户端要下载9MB的内容
当下载软件完成第二个1024KB后,就会自动中断掉下载
此时web服务器并不知道客户端故意中断下载,因此,log中还是下载了9MB的记录。
同理,后边成生的log是8MB。。7MB。。
上边说的是在理想情况下。当实际下载时候,某些进程先完成,某些进程后完成。
那么其中没完成的部分,又会再次被切分成多线程下载。
因此,所谓的10线程,是指最多一共启动10个线程
某一时刻,可能只有9个线程在工作
在文件下载将近完成的时候,将只有一个线程工作。
因此,针对多线程软件的灵活性,并由于web服务器的log记录方式的局限,
web服务器无法准确统计多线程下载软件的流量。
虽然只走传输了一个文件,但不同的多线程下载软件,在不同的网络条件下
会产成不通的日志布局,因此web服务器无法统计
|