http断点续传原理

这周完成了一个断点续传的功能。

咱们的游戏里加载地图的逻辑简化而言是这样：

1.首先用本地的md5文件校验地图文件（不少文件）是否完整。（中间有不少步骤，任何步骤失败都认为地图不完整）

2.若是完整，直接加载地图。

3.若是不完整，须要经过一个http协议请求后台服务器传回完整的地图。

 

如今要增长一个断点续传的功能。也就是地图下载过程当中，若是断网，丢包之类，重启游戏地图会继续下载，而不是从新下载。给服务器减小流量。

要解决这个问题，要了解如下问题：

1.正常的http请求流程。

2.http分段请求的原理。

3.具体地图下载流程的处理。

 

1.http请求的流程　

客户端发送的请求被封装成请求报文。

请求报文的内容里面包括请求方法，请求地址，http协议版本，请求首部。其中的请求方法就是所谓的Get，Post，Put，Header，Delete，Options，Trace，Connect这些。这里咱们无需详细了解。

服务器收到请求之后，会以响应报文的形式发回客户端。响应报文里面包括了http协议版本，状态码，状态码的缘由短语，响应首部，请求的实体主体。

状态码会标记服务端是否正常处理，是个重要的参数。

咱们来看下载地图的请求。

由于是须要直接请求实体，固然是用Get方法。另外只须要知道Url就行。网络正常的状况下，服务端会返回状态码200。而返回的实体就是地图文件，一般是一个压缩文件.zip，用二进制模式写到一个文件，再用ziplib之类解压。

 

2.http分段请求的原理

那么断点续传怎么作呢。在客户端发起的请求报文里，请求首部里面有个可选参数Range，用来标识只请求实体的一部分。

格式形如：Range: bytes=500-999，请求500bytes到999bytes。Range: bytes=500-，请求500bytes开始到结束的部分。

那么断点续传其实就是知道上一次传输的终点，把它做为Range参数的起点，发起请求。

若是请求首部带有Range参数，那么服务器正常状况会返回状态码206和请求的部分实体。

 

3.具体地图下载流程的处理

地图下载的具体逻辑。我这里这样处理：

服务器返回的实体内容写到一个临时文件，命名为temp.zip。若是下载完整了，就会把名字改掉，改成map_id.zip。若是不完整就不会更名了。

因此每次发起请求前，判断是否须要断点续传，只须要判断存不存在temp.zip便可。

1.首先用本地的md5文件校验地图文件（不少文件）是否完整。（中间有不少步骤，任何步骤失败都认为地图不完整）

2.若是完整直接使用本地地图。

3.若是不完整，判断是否存在temp.zip文件。

4.若是存在，请求头部带有Range参数，起点是temp文件的大小。

5.若是不存在，默认的请求头部，请求完整的文件。

 

中间有一些细节问题。可能和具体的实现框架有关。想象一次研发测试流程：

1.启动游戏，第一次下载是一次完整下载，下载的过程当中断网（下载过程有个回调，回调参数有标识进度的process，在这里打断点，而后断网），把收到的实体（应该是一部分）写到temp.zip。

2.把网接回，再启动游戏，判断是否有temp.zip，有temp.zip，因此将temp.zip的文件大小做为Range参数的起点，发起部分请求。把收到的实体写入temp.zip，可是此次的写入起点是文件的末尾。把文件更名为map_id.zip。

这两个状况都是写在一个函数里的，那么怎么判断temp.zip文件是否已是完整的地图文件呢？要不要更名了呢？

我这边的框架里面，服务器返回的实体res里面有个error参数，经过这个参数就能知道本次返回的实体，是否是客户端请求的所有实体（包括完整的请求和部分的请求）。

也就是说若是res里面的error是true，那么最后是不会走到更名那步的。下一次请求仍是会走断点续传。反之error是false，那么说明本次请求返回的实体已经完整，最后会走到更名那步。

 

另一个问题。若是服务器上的文件内容变动了，咱们还从旧文件的断点位置请求，这样就会出错了。

这个问题，能够考虑请求首部的If-Range参数和响应首部的ETAG参数。也就是说要客户端记录传回文件的ETAG，下一次请求把此ETAG做为If-Range参数。那么服务器会根据ETAG判断文件是否更新。

若是有更新，会走全量下载，返回状态码200。若是没有更新，会走部分下载，返回状态码206。

也能够用其余方法，好比你们约定好，服务器那边地图改变了，地图就换一个名字（用时间戳作地图名字后缀），那么客户端这边请求的名字就会变了。不须要考虑If-Range参数。也没必要在客户端记录ETAG。

 

引用：

1.《图解http》