介紹
利用HTML5的新接口例如
ArrayBuffer
、
Blob
等可以在前端進行zip操作并且可以将zip後的檔案上傳到伺服器。本調研主要關注zip方案的zip效率以及整體上傳效率。
工具
- zip方案來自 http://gildas-lormeau.github.io/zip.js/ 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圖檔時的請求資料：
- Connecting：846ms
- Sending：47.3s
例如以下是一個wif環境中上傳50K圖檔時的請求資料：
- Connecting：5ms
- Waiting：24ms
例如以下是一個wif環境中上傳300K圖檔時的請求資料：
- Connecting：4ms
- Sending：189ms
- Waiting：22ms
從資料可以看出，
Waiting
并不是純伺服器端處理時間，它與網速有直接關系，wifi下的
Waiting
時間是接近真實的伺服器端處理時間的。
但同時
Waiting
時間與檔案大小是無關的，無論50K還是1.2M都基本一緻。
初步猜想
Waiting
包括一部分浏覽器處理檔案上傳的時間，否則在15K/S的上傳速度下，50K檔案的
Sending
時間不應該是0。
此外，
Sending
時間與AJAX中progress監控的時間保持一緻。
綜上所述，2G環境下基本可以将
Sending
+
Waiting
視為總的前端上傳時間，伺服器端真實處理時間基本在ms級别。
3G
| 48273 | 85866 | - | |
| 66510 | 102841 | ||
| 56889 | 85837 |
與2G類型，3G網絡環境下，ZIP方案依舊在批量小圖檔的上傳中保持一定的優勢，包括多請求并發方案。但是一旦圖檔大小達到100K左右就不再具有優勢。
WIFI
| 2091 | 2663 | 5821 | |
| 1499 | 1871 | 4271 | |
| 641 | 1418 | 3061 |
WIFI環境下ZIP不具備優勢，相反，當檔案增大時打包時間的比例會很大，是以整體速度反而變慢。
結論
- ZIP方案适用于網絡速度較低（例如2G/3G）以及檔案較小（小于100K）時的批量上傳場景；
- 2G/3G環境下并發請求仍然能獲得比較大的上傳優勢；（在2G/3G環境下可以結合ZIP以及并發請求來進一步提供上傳速度）