Http 请求到底有多慢

与写p2p程序的同事商量了一下，文件下载时怎样去衔接p2p下载和向服务器下载数据的这两种方式，经过商量之后，决定用一个文件来保存整个文件的分片信息，比如每一片表示1400个字节，那么用一个byte数组来保存这些文件片的下载信息，0表示该文件片没有被下载，1 表示已经被下载了，这是p2p和http向服务器请求文件这两种方式的一个公共的文件。

p2p程序从byte数组的0位置开始下载，接收到之后存储文件内容并且将byte[0] 赋值为1，以此类推，知道p2p下不起走为止，或是p2p的下载速度低于多少kb/s为止。

http怎样与p2p衔接呢？这个公共的byte数组中可以检查出p2p到底下载到了哪里！ 就是从这个数组的最后开始向前检索，知道遇见第一个1，姑且把这个位置叫做p2pEnd，在0到p2pEnd之间去搜索没有下载的文件片，p2pEnd到byte.length 之间是没有被下载过的文件片。那么对这两段要怎样处理呢？

第一段：0--p2pEnd：挨个检索，可以根据byte数组的脚本计算中需要下载的文件片是哪段文件片，公式如下：

start = i*1400

end = start + 1399 

是的，通过Http的Get方法去获取这1400个字节的文件片段，需要在http头结点中设置header属性Range即可！

这里有一个坑！ 比如我请求的是1400到2799这1400个字节，当我接收的时候可能返回1147个字节。具体是怎么一回事，我也不太清楚，反正在程序中的话，可以检测本此http请求是否返回了正确的文件片长度。如果不正确的话，继承本次的Range请求，直到获得正确的文件长度为止。等到检索完从0到p2pEnd 时，p2p下载的漏洞基本上就补好了。

第二段：p2pEnd--byte.length :对于这段长度，我们可以采用整体下载的方式，为啥不想之前给p2p下载补漏洞的方式呢？也就是说，为啥不1400个字节就请求一次呢？答案是http一应一答相当地废时！ 经过测试，本来带宽可以达到150kb/s的快带，用1400字节一个个地下载的话，下载速度超不多20kb/s，多数时候在10kb/s以下。所有为了弥补这个缺陷，对于p2pEnd之后的文件片段，就一次性放在httpGet的Range中，如Range:bytes=p2pEnd*1400 - (mContentLenght -1)

对于该HttpGet的回应，也有一点技巧，为的就是给byte数组赋值，掌握哪个文件片被下载了，这里给用于接收http response的inputsStream.read(buff)的buff byte数组，其长度不能大于1400！ 方便在每次接收数据之后就去给byte数组赋值，大致可以这样！ byte[mReceivedLength / 1400] = 1 ，由于每次接收的长度不大于1400，所有每次接收的字节不可能有1400个字节的跨度，也就是说，不可能对byte数组越角标赋值，所以下载一个就向byte数组中写入已经下载的标记，并且赋值10次或20次就把byte数组中的数据保存到配置文件中去，以便保存最新的下载记录，如果不小心断网了或断点了，下次下载文件的时候可以从这个配置文件中去获取，当前的文件下载到了哪里，应该从哪里开始去更新下载的文件。