访问统计报告不能准确记录多线程下载流量

核心提示：问题 访问统计报告不能准确记录多线程下载流量 解决方案 这个是由于多线程下载软件的原理来决定的 假定一个文件有10MB，分成10个进程下载 第一个线程是从文件头部开始下载，访问统计报告不能准确记录多线程下载流量，即1~1024KB 第二个线程从第2MB开始下载即，1025~2048KB 以此类推， 虽然只走传输了一

问题 
访问统计报告不能准确记录多线程下载流量　

解决方案 
这个是由于多线程下载软件的原理来决定的
假定一个文件有10MB，分成10个进程下载
第一个线程是从文件头部开始下载，即1~1024KB
第二个线程从第2MB开始下载即，1025~2048KB
以此类推，共10个线程

第一个线程下载时候，下载软件会告诉web服务器，从文件起始下载
但并不告诉web服务器下载的终点在哪里。所以web服务器认为客户端要下载整个文件。
这个时候，web server的日志中留下的是整个文件的大小。
但是，当下载完成1024KB后，下载软件会主动停止连接
包括IIS、apache(Unix平台最流行的WEB服务器平台)在内的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服务器无法统计
 

评分