文件批量上传ZIP方案调研

介绍

利用HTML5的新接口例如ArrayBuffer、Blob等可以在前端进行zip操作并且可以将zip后的文件上传到服务器。本调研主要关注zip方案的zip效率以及整体上传效率。

工具

• zip方案来自 http://gildas-lormeau.github.io/zip.js/；
• 使用Network Link Conditioner模拟各种网络环境：2G/3G/wifi等；

维度

• 网络环境:2G & 3G & wifi
• 图片大小:50K & 100K & 300K
• 并发数：1 & 3（仅针对NOZIP方案）
• 图片数量：30

方案

ZIP方案：上传前采用前端ZIP方法将所有文件打包成一个文件后使用AJAX上传，需记录打包时间和上传时间；
NOZIP方案：采用并行1或3个AJAX请求的方式批量上传所有的图片；

数据

2G

使用Network Link Conditioner模拟2G环境，上传速度在15K/S左右，每个请求建立连接的时间在1s左右；

方案	50K	100K	300K
ZIP	82285	146951	498930
NOZIP1	168294	236620	592867
NOZIP3	96198	156123	499195

2G网络中只保持1个请求的情况下，ZIP方案具有绝对的优势，尤其在图片大小小于100K时。

2G网络中同时开启3个请求的情况下，当图片大小小于100K时ZIP方案有比较明显的优势，但是随着图片尺寸的增加这种优势逐渐消失。
ZIP方案的优势在于将N个请求合并成1个，因此有效减少了每个请求中除去上传数据之外的额外时间，例如连接建立等。

对于非ZIP方案而言，在图片尺寸较小时，每个请求中非图片上传的时间占更大的比例，因此ZIP方案的优势得以突显，而随着图片尺寸的增加，每个请求中非图片上传时间的比例也在下降，因此ZIP方案没有明显优势。

此外，与串行请求相比，在2G环境中使用并行请求仍然能获得优势，例如在串行时NOZIP方案上传30张50K图片耗时约181878ms，与3个请求并行相比慢了约1倍。原因在于并行时请求建立连接以及服务器端的处理都是并发的，而不像串行时所有前端和后端的处理均为线性。

请求数据：

通过Chrome开发者工具看到的每个请求包括：

• DNS Lookup: Time spent performing the DNS lookup. You want to minimize DNS look ups.
• Connecting: Time it took to establish a connection, including TCP handshakes/retries, DNS lookup, and time connecting to a proxy or negotiating a secure-socket layer (SSL).
• Sending: Time spent sending the request.
• Waiting: Time spent waiting for the initial response.
• Receiving: Time spent receiving the response data.

以上的解释似乎都理所应当，但查看实际的数据时仍然会有令人困惑之处，主要集中在Sending和Waiting。

例如以下是一个2G环境中上传50K图片时的请求数据：

• DNS Lookup：0
• Connecting：850ms
• Sending：0
• Waiting：5.54s
• Receiving：0

例如以下是一个2G环境中上传1.2M图片时的请求数据：

• DNS Lookup：0
• Connecting：846ms
• Sending：47.3s
• Waiting：5.54s
• Receiving：0

例如以下是一个wif环境中上传50K图片时的请求数据：

• DNS Lookup：0
• Connecting：5ms
• Sending：0
• Waiting：24ms
• Receiving：0

例如以下是一个wif环境中上传300K图片时的请求数据：

• DNS Lookup：0
• Connecting：4ms
• Sending：189ms
• Waiting：22ms
• Receiving：0

从数据可以看出，Waiting并不是纯服务器端处理时间，它与网速有直接关系，wifi下的Waiting时间是接近真实的服务器端处理时间的。
但同时Waiting时间与文件大小是无关的，无论50K还是1.2M都基本一致。
初步猜想Waiting包括一部分浏览器处理文件上传的时间，否则在15K/S的上传速度下，50K文件的Sending时间不应该是0。
此外，Sending时间与AJAX中progress监控的时间保持一致。

综上所述，2G环境下基本可以将Sending + Waiting视为总的前端上传时间，服务器端真实处理时间基本在ms级别。

3G

方案	50K	100K	300K
ZIP	48273	85866	-
NOZIP1	66510	102841	-
NOZIP3	56889	85837	-

与2G类型，3G网络环境下，ZIP方案依旧在批量小图片的上传中保持一定的优势，包括多请求并发方案。但是一旦图片大小达到100K左右就不再具有优势。

WIFI

方案	50K	100K	300K
ZIP	2091	2663	5821
NOZIP1	1499	1871	4271
NOZIP3	641	1418	3061

WIFI环境下ZIP不具备优势，相反，当文件增大时打包时间的比例会很大，因此整体速度反而变慢。

结论

• ZIP方案适用于网络速度较低（例如2G/3G）以及文件较小（小于100K）时的批量上传场景；
• 2G/3G环境下并发请求仍然能获得比较大的上传优势；（在2G/3G环境下可以结合ZIP以及并发请求来进一步提供上传速度）

---

by 百度FEX