(Hypertext Markup Language,简称为 HTML)、可扩展的标记语言（ extensible Markup Language,简称为 XML)、 Java脚本对象符号（JavaScrip Object Notation,简称为 JSON) 等； 另一类是二进制文件， 如联合图像专家组 （Joint Photographic Experts Group, 简 称为 JPEG或 JPG) 等。 其中， 纯文本文件的熵值一般较低 （即， 纯文本文件用了较 多的存储空间存放了较少的信息）。 相关技术中， 对于网络文件， 通常是采用全文传输的。 但是， 对于同一个统一资 源定位符 （Uniform Resource Locator, 简称为 URL) 地址来说， 通常短时间内其内容 变化是很小的， 因此， 该全文传输会导致很多冗余信息传输到客户端 ， 从而增加传输 流量并延长传输时间。 发明内容 本发明提供了一种网络文件传输方法及系统， 以至少解决相关技术中全文传输将 很多冗余信息传输到客户端， 增加传输流量并延长传输时间的问题。 根据本发明的一个方面， 提供了一种网络文件传输方法， 包括： 客户端向服务器 发送携带有第一网络文件标识的网络文件请求 消息， 其中， 网络文件请求消息用于客 户端向服务器请求获取网络文件当前的内容， 第一网络文件标识用于指示客户端已获 取的网络文件的内容； 客户端接收到来自服务器的差分文件， 其中差分文件存储有网 络文件当前的内容与客户端已获取的网络文件 的内容的差值； 客户端将差分文件与客 户端已获取的网络文件的内容进行合成， 得到网络文件当前的内容。 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之后， 还包 括： 客户端接收到来自服务器的第二网络文件标识 ， 其中， 第二网络文件标识用于指 示网络文件当前的内容。 在客户端接收到来自服务器的第二网络文件标 识之后， 还包括： 在后续的客户端 向服务器请求获取网络文件当前的内容的情况 下， 客户端向服务器发送携带有第二网 络文件标识的网络文件请求消息。 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之后， 还包 括： 服务器在自身缓存中未找到第一网络文件标识 指示的客户端已获取的网络文件的 内容； 服务器向客户端发送网络文件当前的内容。 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之后， 还包 括： 服务器确定网络文件当前的内容的长度小于差 分文件的长度； 服务器向客户端发 送网络文件当前的内容。 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之后， 还包 括： 服务器确定网络文件当前的内容与客户端已获 取的网络文件的内容相同； 服务器 向客户端发送携带有原因值 304的网络文件响应消息， 其中原因值 304用于指示网络 文件当前的内容未变化。 客户端接收到来自服务器的差分文件包括： 客户端接收到来自服务器的通过 HTTP标准的 GZIP压缩的差分文件。 根据本发明的另一个方面，提供了一种网络文 件传输系统，包括客户端和服务器， 其中客户端包括： 第一发送模块， 设置为向服务器发送携带有第一网络文件标识 的网 络文件请求消息， 其中， 网络文件请求消息用于客户端向服务器请求获 取网络文件当 前的内容， 第一网络文件标识用于指示客户端已获取的网 络文件的内容； 第一接收模 块， 设置为接收来自服务器的差分文件， 其中差分文件存储有网络文件当前的内容与 客户端已获取的网络文件的内容的差值； 合成模块， 设置为将差分文件与客户端已获 取的网络文件的内容进行合成， 得到网络文件当前的内容。 客户端还包括： 第二接收模块， 设置为接收到来自服务器的第二网络文件标识 ， 其中， 第二网络文件标识用于指示网络文件当前的内 容。 客户端还包括： 第二发送模块， 设置为在后续的向服务器请求获取网络文件当 前 的内容的情况下， 向服务器发送携带有第二网络文件标识的网络 文件请求消息。 服务器还包括： 第一确定模块， 设置为确定在自身缓存中未找到第一网络文件 标 识指示的客户端已获取的网络文件的内容； 第三发送模块， 设置为向客户端发送网络 文件当前的内容。 服务器还包括： 第二确定模块， 设置为确定网络文件当前的内容的长度小于差 分 文件的长度； 第四发送模块， 设置为向客户端发送网络文件当前的内容。 本发明中， 通过传输存储有网络文件当前内容与客户端已 获取的网络文件的内容 的差值的差分文件， 解决了全文传输将很多冗余信息传输到客户端 的问题， 进而减少 了传输流量并缩短了传输时间。 附图说明 此处所说明的附图用来提供对本发明的进一步 理解， 构成本申请的一部分， 本发 明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在附图 中： 图 1是根据本发明实施例的网络文件传输方法的� �程图； 图 2是根据本发明实施例的基本原理示意图； 图 3是根据本发明实施例的服务器处理客户端新� �求的流程图； 图 4是根据本发明实施例的增加标识和删除标识� �组成结构框图； 图 5是根据本发明优选实施例一的冗余内容用增� �标识和删除标识进行替换的示 意图一； 图 6是根据本发明优选实施例二的冗余内容用增� �标识和删除标识进行替换的示 意图二； 图 7是根据本发明优选实施例三的冗余内容用增� �标识和删除标识进行替换的示 意图三； 图 8是根据本发明实施例的网络文件传输系统的� �构框图； 图 9是根据本发明优选实施例的网络文件传输系� �的结构框图一； 图 10是根据本发明优选实施例的网络文件传输系� ��的结构框图二； 图 11是根据本发明优选实施例的网络文件传输系� ��的结构框图三； 图 12是根据本发明优选实施例的网络文件传输系� ��的结构框图四。 具体实施方式 需要说明的是， 在不冲突的情况下， 本申请中的实施例及实施例中的特征可以相 互组合。 下面将参考附图并结合实施例来详细说明本发 明。 本发明实施例提供了一种网络文件传输方法， 图 1是根据本发明实施例的网络文 件传输方法的流程图， 包括如下的步骤 S102至步骤 S106。 步骤 S102, 客户端向服务器发送携带有第一网络文件标识 的网络文件请求消息， 其中， 网络文件请求消息用于客户端向服务器请求获 取网络文件当前的内容， 第一网 络文件标识用于指示客户端已获取的网络文件 的内容。 步骤 S104, 客户端接收到来自服务器的差分文件， 其中差分文件存储有网络文件 当前的内容与客户端已获取的网络文件的内容 的差值。 步骤 S106, 客户端将差分文件与客户端已获取的网络文件 的内容进行合成， 得到 网络文件当前的内容。 相关技术中， 全文传输会导致很多冗余信息从服务器传输到 客户端， 从而增加传 输流量并延长传输时间。 本发明实施例中， 仅仅传输存储有网络文件当前内容与客户 端已获取的网络文件的内容的差值的差分文件 ， 从而可以减少传输流量并缩短传输时 间。 优选地， 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之 后， 还包括： 客户端接收到来自服务器的第二网络文件标识 ， 其中， 第二网络文件标 识用于指示网络文件当前的内容。 本优选实施例中， 通过第二网络文件标识， 可以保 证后续的网络文件传输仅仅传输差分文件， 从而可以减少传输流量并缩短传输时间。 优选地， 在客户端接收到来自服务器的第二网络文件标 识之后， 还包括： 在后续 的客户端向服务器请求获取网络文件当前的内 容的情况下， 客户端向服务器发送携带 有第二网络文件标识的网络文件请求消息。 优选地， 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之 后， 还包括： 服务器在自身缓存中未找到第一网络文件标识 指示的客户端已获取的网 络文件的内容； 服务器向客户端发送网络文件当前的内容。 考虑到服务器因为时间太 久已经没有第一网络文件标识指示的网络文件 的内容的缓存， 本优选实施例中， 通过 直接向客户端发送网络文件当前的内容， 可以保证网络文件正确、 可靠地传输。 优选地， 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之 后， 还包括： 服务器确定网络文件当前的内容的长度小于差 分文件的长度； 服务器向 客户端发送网络文件当前的内容。 考虑到网络文件因为变化过多而导致网络文件 当前 的内容的长度小于差分文件的长度， 本优选实施例中， 通过直接向客户端发送长度小 的网络文件当前的内容， 可以减少传输流量并缩短传输时间。 优选地， 在客户端向服务器发送携带有第一网络文件标 识的网络文件请求消息之 后，还包括： 服务器确定网络文件当前的内容与客户端已获 取的网络文件的内容相同； 服务器向客户端发送携带有原因值 304的网络文件响应消息， 其中原因值 304用于指 示网络文件当前的内容未变化。 考虑到网络文件长时间未变化的情况， 本优选实施例 中， 通过直接向客户端发送标准的 HTTP原因值 304 (304的意思是： Not Modified), 可以减少传输流量并缩短传输时间。 优选地， 客户端接收到来自服务器的差分文件包括： 客户端接收到来自服务器的 通过 HTTP标准的 GZIP压缩的差分文件。 本优选实施例中， 通过 HTTP标准的 GZIP 压缩差分文件并传输， 可以减少传输流量并缩短传输时间。 为达到上述目的， 本发明的技术方案是这样实现的： 客户端向服务器请求某一个 URL:A对应的网络文件 Contentl ,服务器将该网络文 件发送给客户端， 同时将该文件的文件标识 Markl告诉客户端。 一段时间之后， 客户端认为可能 URL:A对应的网络文件的内容发生变化了， 就第 二次请求服务器发送同一个 URL:A对应的新的网络文件 Content2。在请求中， 它把之 前获得的文件标识 Markl 告诉服务器。 服务器根据 Markl 就可以知道客户端拥有 Contentl。 如果当第二次请求到来时， URL:A对应的网络文件的内容都还没有发生改变� �� 那 么服务器就以标准的 HTTP原因值 304回复客户端。下一次客户端再来请求 URL:A对 应的新的网络文件时， 仍然会带上 Markl。 如果当第二次请求到来时， URL:A对应的网络文件的内容已经变成了 Content2， 服务器就比较 Content2和 Contentl的不同， 生成差分文件 Deltal发送给客户端， 同时 将 Content2对应的文件标识 Mark2告诉客户端。 客户端根据 Contentl和 Deltal得到 新文件 Content2。 下一次客户端再来请求 URL:A对应的新的网络文件时， 将会带上 Mark2。 重复上述过程。 在差分文件 Deltal的传输过程中， 仍然可以用 HTTP标准的 GZIP压缩传输。 只 是说被 GZIP 压缩的对象—— HTTP 正文里的内容——是差分文件 Deltal , 而不是 Content2。 如果服务器收到了 Markl却没有找到 Contentl的内容（比如说因为时间太久， 服 务器已经没有 Content 1的缓存）， 就直接把 Content2和 Mark2传给客户端。 下面将结合实例对本发明实施例的实现过程进 行详细描述。 图 2是根据本发明实施例的基本原理示意图， 如图 2所示， 201是目前服务器上 最新文件； 202是服务器缓存中的旧文件； 204是客户端缓存中的旧文件； 202和 204 的内容是一致的。 客户端将 204的文件标识 Markl发给服务器请求获得 201。 服务器 首先根据 Markl在自己的缓存中找到 202，然后将 201和 202做比较生成差分文件 203， 之后将 203连同 201的文件标识 Mark2—起发送给客户端， 客户端根据 204和 203合 成 205， 205的内容和 201—致。这样客户端就获得了服务器上的最新 文件。 当下次请 求最新文件时， 客户端会将 Mark2发给服务器， 让它在自己的缓存中找 201的内容参 与比较， 其余流程同前。 图 3是根据本发明实施例的服务器处理客户端新� �求的流程图， 如图 3所示， 当 服务器收到的请求中没有带上文件标识的处理 流程时， 服务器会直接将最新文件 Contentl和 Contentl的文件标识 Markl返回给客户端。这种情况经常发生在客户� ��第 一次请求服务器某个 URL对应的网络文件的时候，包括如下的步骤 S302至步骤 S306。 步骤 S302， 当服务器收到的请求中带有文件标识 Markl , 服务器上最新文件仍然 为 Contentl时， 服务器会将标准的 HTTP原因值 304返回给客户端。 步骤 S304, 当服务器收到的请求中， 带有文件标识 Markl , 服务器上最新文件已 经更新为 Content2， 服务器能在缓存中找到 Markl对应的文件内容 Contentl时， （需 要注意的是， 服务器应该维护一个长度为 n的缓存 "窗口"， 把时间上最新的 n份旧文 件及其文件标识存储于"窗口"中， 以文件标识为关键字， 便于查找。）服务器把差分文 件 Deltal连同 Content2的文件标识 Mark2发送给客户端。 但是， 如果文件 Deltal的 长度大于文件 Content2的长度， 应该直接将最新文件 Content2和相关文件标识 Mark2 返回给客户端。 步骤 S306, 当服务器收到的请求中带有文件标识 Markl , 服务器上最新文件已经 更新为 Content2， 服务器不能在缓存中找到 Markl对应的文件内容 Contentl时， 服务 器会直接将最新文件 Content2和 Content2的文件标识 Mark2返回给客户端。 本发明是这样定义差分文件的： 差分文件默认约定使用 UTF-8编码， 但可由服务 端和客户端约定换用任何其他适合的编码格式 。默认使用 UTF-8编码是出于通用性的 考虑，但考虑到减少文件占用的存储空间的需 要， 也可约定对于某个 URL对应的网络 文件及其差分文件使用其他适合的编码格式， 使占用的存储空间最小。 （可事先约定， 也可在 HTTP GET请求的包头中或者是在 URL的参数中指定编码格式） 例如， 内容 中大量出现汉字的文件， 约定双方使用 GB2312编码更为合适， 这是因为 UTF-8中一 个汉字占用 3个字节， 而 GB2312中一个汉字只占用 2个字节。 差分文件由两类标识及其参数组成。 两类标识分别是增加标识和删除标识。 如图 4所示， 增加标识中写明新内容插入的地址 （以字节计算）， 在标识后面直接跟上需添 加的内容。删除标识中写明被删除内容的起始 地址， 以及被删除内容的长度。 （均以字 节计算）。 可以这样定义增加标识和删除标识： 增加标识 =增加标识头 + 新内容插 入的地址 + 新增的内容； 删除标识 =删除标识头 +被删除内容的起始地址 +被删 除内容的长度。 需要注意的是： a) 上述新内容插入的地址和被删除内容的起始地 址均是以 Markl 对应的旧文件

Content 1文件作为坐标的。 b)本发明建议标识不使用 TIN结构，虽然 TIN结构在解析方面的性能非常优秀， 但是它占用的存储空间较大。 本发明建议标识使用定长的结构。 c) 如果增加标识中新内容插入的坐标是 0， 即在 Contentl起始位置插入新内容， 可省掉这个增加标识。 将需添加的内容直接放在差分文件的起始位置 ， 解析差分文件 时默认将需添加的内容从坐标 0开始插入。 d) 如果删除标识指示的删除内容是指从删除标识 中的起始地址开始到 Contentl 文件结尾的所有内容全部删除。 可以省掉删除标识中的被删除内容的长度， 但必须将 这个删除标识置于差分文件的结尾。 这样， 解析差分文件时默认将从这个删除标识中 的起始地址开始到 Contentl文件结尾的所有内容全部删除。 如果删除标识指示的是要 将 Contentl的所有内容全部删除， 删除标识还可以省掉起始地址（因为起始地址 为 0) 和被删除内容的长度， 只保留一个删除标识头， 但必须将这个删除标识置于差分文件 的结尾。 e)增加标识和删除标识均以编码格式中， 在纯文本文件中不可能出现的非文字编 码作为开头，来与普通内容做区分，例如，可 以使用美国信息互换标准代码（American Standard Code for Information Interchange, 简称为 ASCII) 编码中的" 25 EM纸尽"作为 增加标识头， 以" 24 CAN作废"作为删除标识头。 解析差分文件时读到 25就知道是增 加标识， 读到 24就知道是删除标识。 f) 差分算法设计如下： 设增加标识的长度是 m字节 （不算增加标识后面的新增内容的字节数）， 删除标 识的长度是 n字节。 旧文件是 Contentl , 新文件是 Content2。扫描 Contentl , Content2, 找到内容相同的子字串 ^S i， ^S 2 , ... ...， （寻找子字串 S¾， S ， ， 的文本比较算 法并不属于本发明的范畴， 建议使用目前常用的算法， 例如 M.D. Mcllroy 在 《An Algorithm for DifFerrential File Comparison))一文中提出的算法）。 本发明是要从 ^S ¾，

^S 2 , ... ...， 中选择出适合进行本发明差分运算的 ^S i， ^S 2 , ......， S _N ( _Ν <=Ν' ), 即： 找到可以从 Cont _en t2中省略， 不需要再次传输到客户端的冗余字串。 我们定义^是 ^S i， ^S 2 , ... ...， 中第一个适合进行差分运算的子字串。 我们按照 下述 （一） 的方法从 ^S i， ^S 2 , ... ...， 中找到。 ^s !i ^s i， ^S ^， ... ...， 中的某一个字 串， | |代表 的字串长度 （以字节计算）。

(一）， ^S 只要满足以下三个条件中的任何一个， 就是我们要寻找的 。 根据 Content2， Contentl 在 ^S P ^S +l之间内容的不同， 存在如下述实例一至三 所示的三种不同情况。 实例一 图 5是根据本发明优选实施例一的冗余内容用增� �标识和删除标识进行替换的示 意图一， 如图 5所示， Content2 (文件 2)在 ^S 禾口 ^S +1之间新增内容 P， Content 1 (文 件 1 ) 在 和 +1之间无内容： 在这种情况下， P需要被增加， 但必须满足 | ^S |>m， 我们才能用一个增加标识来 指示在 ^s 的后面需要进行插入操作， 否则是不划算的， ^s 就不是我们要寻找的 。 图 5中虚线方框代表 ⁵ !1 iP ^S i+l， 点划线方框代表 Content2相对 Contentl新增的 内容 P， 而阴影块就代表使用增加标识后， 差分文件比 Cont _en t2节省的存储空间。 实例二 图 6是根据本发明优选实施例二的冗余内容用增� �标识和删除标识进行替换的示 意图二， 如图 6所示， 0¾^ 2在 禾口 +1之间无内容， Contentl在 ^S 禾口 ^S +1之间 有内容 V： 在这种情况下， V需要被删除。 但必须满足 |V|> n， 我们才能用一个删除标识来指 示在 ^S 的后面需要进行删除操作。 否则是不划算的， ^S 就不是我们要寻找的 。 图 6中虚线方框代表 ⁵ !1和 ⁵ ^+1， 点划线方框代表 Content2相对 Contentl应删除 的内容 V， 而阴影实心块就代表使用删除标识后， 差分文件比 Cont _en t2节省的存储空 间。 实例三 图 7是根据本发明优选实施例三的冗余内容用增� �标识和删除标识进行替换的示 意图三， 如图 7所示， Content2在 ^S 禾口 ^S +1之间新增内容 P， Contentl在 ^S 禾口 ^S ii+1 之间有内容 V： 这种情况是优选实施例一和优选实施例二的混 合情况， 只要满足 （| ^S | + |V| ) >(m+n)即可。我们先用一个增加标识来指示在 ^S 的后面需要进行插入操作， 再用一个 删除标识来指示在 ^S 的后面需要进行删除操作。如果不满足上述条 件， 替换就是不划 算的， ^S 就不是我们要寻找的 。 需要注意的是， 不满足上述三种情况的 ⁵ !1将被放 弃， 继续寻找满足条件的 ^S i。

(二）， 如果找不到符合 （一） 的 ， 应该这么做： 将 Cont _en t2直接放在差分文件的起始位置， 省略增加标识。 参考前述 C ) 中的说明： 将需添加的内容直接放在差分文件的起始位置 ， 解析差 分文件时默认将需添加的内容从坐标 0开始插入。 然后， 使用一个删除标识来指示 Contentl应该被删除。 参考前述 d) 中的说明： 如果删除标识指示的是要将 Contentl的所有内容全部删 除， 删除标识可以省掉起始地址 （因为起始地址为 0) 和被删除内容的长度， 只保留 一个删除标识头， 但必须将这个删除标识置于差分文件的结尾。 需要注意的是， 这样做， 生成的差分文件与 Cont _en t2相比只多 1个字节 （即删除 标识头占用的那个字节）。

(三），如果找到了符合（一）的 。因为 是第一段内容相同的字串，所以在 的前面可能存在三种情况：

0) 6 2在 ⁵ 1之前有内容 P， Contentl在^之前无内容， 则将 P直接放在差分文 件的起始位置， 省略增加标识。 这样做， 并没有增加冗余字节。

0) 6 2在 ⁵ 1之前无内容， Contentl在^之前有内容 V， 则使用一个删除标识来 指示 V应该被删除。 这样做， 极端情况下有可能增加冗余字节， 但冗余字节不会超过 (n - 1 ) 个 （当 V只有 1个字节时）。

Content2在^之前有内容 P， Contentl在^之前有内容 V， 则将 P直接放在差分 文件的起始位置， 省略增加标识； 然后使用一个删除标识来指示 V应该被删除。 这样 做， 极端情况下有可能增加冗余字节， 但冗余字节不会超过 （n - 1 ) 个。

(四）， 继续寻找第 n段满足 （一） 中条件的 S„ (n>=2), 因为是第 n段， 所以不 需要考虑 之前的情况， 只考虑之后的情况， 处理同 （一）。 找到 后， 需要更新与 相关的增加 /删除标志， 因为此时才能确定在的后面需要添加的内容和 被删除的内容长 度。

(五）， 如果 是最后一个满足 （一） 中条件的子字串， 并且如果 后面需要使 用一个删除标识，则根据前述 d)中的说明，可以省略删除标识里的被删除内� ��的长度， 但必须将这个删除标识置于差分文件的结尾。 在非极端情况下， 根据上述算法生成的差分文件， 相对 Cont _en t2占用的存储空间 更小。 在极端条件下， 差分文件可能比 Cont _en t2最多冗余 （n - 1 ) 个字节。 实例 以下是一个实现本发明的实例， 本实例的处理对象主要是通过网络传输的 XML 文件 /JSON文件等等 （这些文件格式常用于调用网络 API获得的结果的表示， 例如微 博、 团购网站的网络 API等， 因此本实例具有实用价值）： 差分文件具有以下特征：

( 1 ) 约定本实例中的差分文件默认使用 UTF-8编码， 但可由服务端和客户端约 定换用任何其他适合的编码格式。 (2) 本实例一共定义有 2种增加标识和 3种删除标识。

(3 )定义第一种增加标识使用 UTF-8编码中的 25 EM纸尽（25 EM纸尽是 ASCII 字符中的一个控制字符， 但是， ASCII字符在 UTF-8编码中的表示与其在 ASCII字符 表中的表示是一样的）作为增加标识头。 以 25开头的增加标识后跟的新内容插入的地 址以 2个字节表示。 (4) 定义第二种增加标识使用 19 DC3 设备控制 3作为增加标识头， 但是以 19 开头的增加标识后跟的新内容插入的地址以 3个字节表示。

( 5 )定义第一种删除标识使用 24 CAN作废 作为删除标识头。 以 24开头的删除 标识后跟的被删除内容的起始地址以 2个字节表示， 被删除内容的长度以 2个字节表 示。 ( 6 ) 定义第二种删除标识使用 18 DC2 设备控制 2作为删除标识头。 但是以 18 开头的删除标识后跟的被删除内容的起始地址 以 3个字节表示， 被删除内容的长度以 3个字节表示。

( 7 ) 定义第三种删除标识使用 17 DC1 设备控制 1作为删除标识头。 但是以 17 开头的删除标识后跟的被删除内容的起始地址 以 3个字节表示， 被删除内容的长度以

2个字节表示。 综上， 在作为坐标的旧文件 Contentl的长度不超过 64K时使用 （3 ) 定义的增加 标识和 （5 )定义的删除标识。 在 Contentl的长度大于 64K、 小于 16M时使用 （4 )定 义的增加标识和（6)、 ( 7 )定义的删除标识（根据被删除内容的长度是 /否超过 64Κ选 择使用 （6 ) I ( 7 ) 定义的删除标识）。 其中， 文件标识具有以下特征： 本实例使用网络文件的 CRC16校验码作为它的文件标识。客户端传给服� ��器的旧 文件 Contentl的文件标识 Markl可以使用以下两种方法的任意一种获得： 服务器生成，告诉客户端。例如，服务器在生 成 Contentl时计算出文件标识 Markl， 将此标识附带在 HTTP GET回复的包头中 （或者附带在回复正文中） 发给客户端。 服务器和客户端用相同算法各自算出相同的标 识。 例如， 服务器在生成 Contentl 时计算出文件标识 Markl , 但只是自己使用， 不传递给客户端。 客户端与服务器使用 同一种 CRC16算法， 因此能够根据收到的网络文件 Contentl 的内容算出相同的文件 标识 Markl。 服务器缓存"窗口"具有如下特征： 本实例中，服务器为每个 URL对应的网络文件都单独维护了一个长度为 n的缓存 "窗口"， 把时间上最新的 n份旧文件及其文件标识存储于"窗口"中， 以文件标识为关 键字。 "窗口 "装满后， 向着时间上最新的方向"滑动" （即： 按照先进先出策略丢弃最 旧文件， 放入最新文件）。 服务器收到客户端通过 HTTP GET请求的包头 （或者 URL 的参数） 带来的旧文件的文件标识后， 在"窗口"中以文件标识为关键字查找缓存的旧 文件。 其他应注意的处理包括： 服务器需比较如下文件的大小： 生成的差分文件 Deltal ; 最新的网络文件 Content2; Deltal经过 GZIP压缩后的文件； Content2经过 GZIP压 缩后的文件。 比较后选择最小的一个发送给客户端， 并在 HTTP回复的包头中予以说 明 （可以利用回复的包头中 GZIP使用的 Content-Encoding字段予以说明）。 客户端根 据包头里的说明得知自己收到的是这 4个文件中的哪一个。 如果某个 URL对应的网络文件 Content2的内容主要是汉字组成， 可以将通过这 个 URL传递的网络文件及其差分文件的编码格式约 定为 GB2312。 需要注意的是， 虽然编码改变了， 但由于 ASCII字符在 GB2312编码中的表示与 其在 ASCII字符表中的表示是一样的， 所以增加 /删除标识头仍然使用 25... ...等字符。 同理， 如果 UTF-8编码不能保证差分文件占用存储空间最少� �� 本实例就要选择能 够使差分文件占用存储空间更少的编码格式。 需要说明的是， 在附图的流程图示出的步骤可以在诸如一组计 算机可执行指令的 计算机系统中执行， 并且， 虽然在流程图中示出了逻辑顺序， 但是在某些情况下， 可 以以不同于此处的顺序执行所示出或描述的步 骤。 本发明实施例还提供了一种网络文件传输系统 ， 该系统可以用于实现上述网络文 件传输方法。 图 8是根据本发明实施例的网络文件传输系统的� �构框图， 如图 8所示， 包括客户端 82和服务器 84， 其中客户端 82包括： 第一发送模块 821、 第一接收模块 822和合成模块 823， 下面对其结构进行详细描述。 第一发送模块 821， 设置为向服务器 84发送携带有第一网络文件标识的网络文件 请求消息， 其中， 网络文件请求消息用于客户端 82向服务器 84请求获取网络文件当 前的内容，第一网络文件标识用于指示客户端 82已获取的网络文件的内容； 第一接收 模块 822， 设置为接收来自服务器 84的差分文件， 其中差分文件存储有网络文件当前 的内容与客户端 82已获取的网络文件的内容的差值； 合成模块 823， 连接至第一接收 模块 822， 设置为将差分文件与客户端 82已获取的网络文件的内容进行合成， 得到网 络文件当前的内容。 图 9是根据本发明优选实施例的网络文件传输系� �的结构框图一， 如图 9所示， 客户端 82还包括： 第二接收模块 824， 设置为接收到来自服务器 84的第二网络文件 标识， 其中， 第二网络文件标识用于指示网络文件当前的内 容。 图 10是根据本发明优选实施例的网络文件传输系� ��的结构框图二，如图 10所示， 优选地， 客户端 82还包括： 第二发送模块 825， 连接至第二接收模块 824， 设置为在 后续的向服务器 84请求获取网络文件当前的内容的情况下， 向服务器 84发送携带有 第二网络文件标识的网络文件请求消息。 图 11是根据本发明优选实施例的网络文件传输系� ��的结构框图三，如图 11所示， 服务器 84还包括： 第一确定模块 841， 设置为确定在自身缓存中未找到第一网络文件 标识指示的客户端已获取的网络文件的内容； 第三发送模块 842， 连接至第一确定模 块 841， 设置为向客户端 82发送网络文件当前的内容。 图 12是根据本发明优选实施例的网络文件传输系� ��的结构框图四，如图 12所示， 服务器 84还包括： 第二确定模块 843， 设置为确定网络文件当前的内容的长度小于差 分文件的长度； 第四发送模块 844， 连接至第二确定模块 843， 设置为向客户端 82发 送网络文件当前的内容。 需要说明的是，装置实施例中描述的网络文件 传输系统对应于上述的方法实施例， 其具体的实现过程在方法实施例中已经进行过 详细说明， 在此不再赘述。 综上所述， 根据本发明的上述实施例， 提供了一种网络文件传输方法及系统， 包括： 客户端向服务器发送携带有第一网络文件标识 的网络文件请求消息， 其中， 网络文件请求消息用于客户端向服务器请求获 取网络文件当前的内容， 第一网络文 件标识用于指示客户端已获取的网络文件的内 容； 客户端接收到来自服务器的差分 文件， 其中差分文件存储有网络文件当前的内容与客 户端已获取的网络文件的内容 的差值； 客户端将差分文件与客户端已获取的网络文件 的内容进行合成， 得到网络 文件当前的内容。 本发明中， 通过传输存储有网络文件当前内容与客户端已 获取的 网络文件的内容的差值的差分文件， 解决了全文传输将很多冗余信息传输到客户端 的问题， 进而减少了传输流量并缩短了传输时间。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通 用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装 置所组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现 ， 从而， 可以将它们存储在存储装置中由计算装置来执 行， 或者将它们分别制作成各个集成 电路模块， 或者将它们中的多个模块或步骤制作成单个集 成电路模块来实现。这样， 本发明不限制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的 技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所 作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。