[[395724]]

有個讀者在微信上問我：百度網(wǎng)盤的秒傳功能是如何實現(xiàn)的?

這個問題我其實有想過，我猜測大概是前端計算一個文件的哈希值(比如MD5)發(fā)送給后端，網(wǎng)盤服務(wù)器判斷是否存在這個文件，如果存在就直接在后端完成文件的“轉(zhuǎn)存”，直接告訴前端：上傳成功。

不過這是我自己猜測的，到底對不對，一直也沒有去驗證過。

我把我的猜測告訴了他，結(jié)果他問了一句：如果發(fā)生哈希沖突了怎么辦呢?。

我想了一下又說：那就多加幾個哈希!

不過百度網(wǎng)盤到底是怎么做的呢?這位讀者既然問到了，我就趁機花了幾分鐘研究了一下，算是解答了這個疑惑，增加了知識。

MD5 沖突

首先，只用一個哈希值，已經(jīng)有事實證明是會發(fā)生沖突的，而不只是理論上。

比如我在知乎上找到了一個例子，下面兩段不同的數(shù)據(jù)，只相差兩個字節(jié)：

分別計算md5，結(jié)果是一樣的：

所以，如果只用一個哈希值就判定是同一個文件，那就比較容易會出現(xiàn)張冠李戴的情況。

甚至，有人還基于此提出一種哈希碰撞攻擊：如果我知道一個文件的md5值，但拿不到這個文件，我通過數(shù)學(xué)計算，構(gòu)造一個相同md5的文件，那豈不是就把那個文件直接給我轉(zhuǎn)存過來了?如果是一個私密的文件呢?那不出事了!

百度網(wǎng)盤的做法

那百度網(wǎng)盤是咋做的呢?

首先上傳一個稍微大一點的文件(小文件有計算哈希的功夫早就傳完了)，使用瀏覽器F12大法，看一下它的網(wǎng)絡(luò)請求：

可以看到，百度網(wǎng)盤對文件進行了分塊傳輸，這也是目前業(yè)界比較流行的做法，對大文件進行分塊，如果網(wǎng)絡(luò)不好斷開了，下次只需要傳輸剩下的分塊就行了，做到了斷點續(xù)傳。

不過注意看，在上面分塊的中間，插入了一個叫rapidupload接口的請求，從名字你也可以猜出來了，這個接口肯定跟它的“秒傳”功能有關(guān)系

來看一下請求的參數(shù)，是一個Form表單，有這么幾個字段：

content-length: 文件長度

content-md5: 文件的MD5

slice-md5: 文件切片的MD5

看到這里你估計猜到了，肯定是這三個參數(shù)聯(lián)合判斷，同時滿足條件才算是同一個文件!

來看下服務(wù)器響應(yīng)了什么：

秒傳成功了!

那如果上傳一個后端肯定不存在的文件會是返回什么呢?我構(gòu)造了一個做測試：

看到了吧，404!說明后端沒這個文件，那就老老實實傳吧!

接著，我想看一下這個切片md5，百度網(wǎng)盤是怎么在切的。

通過網(wǎng)絡(luò)通信中的Initiator功能，可以定位到是哪里的JS代碼在發(fā)生請求：

通過調(diào)用堆棧，看到了叫rapidUpload這個函數(shù)，再上下一跟進，找到了這個切片MD5計算的地方：

其實就是對文件的前262144個字節(jié)，也就是256KB進行計算。如果文件比這還小，那就用不著秒傳了。

但奇怪的是，我扣取了文件的前256個字節(jié)，計算出來的md5，和它接口中上傳的參數(shù)并不一致!

這讓我疑惑了好幾分鐘，難道事情沒這么簡單?

我又打了斷點在計算的位置，發(fā)現(xiàn)它計算的跟我計算的又是一樣的，但通過網(wǎng)絡(luò)發(fā)出去以后就變了，真是薛定諤的MD5，奇怪了!

不過，程序不是量子力學(xué)，它不會騙人，很快我就找到了問題所在：百度網(wǎng)盤可能擔(dān)心自己的路數(shù)被發(fā)現(xiàn)，對文件的MD5和切片MD5都進行了加密!

這就是加密函數(shù)：

一些簡單的字符串處理而已。

好了，現(xiàn)在可以回答前面讀者的問題了：

百度網(wǎng)盤上傳時，如果是超過256KB的文件，將計算整個文件的MD5和文件前256KB內(nèi)容的MD5，并對兩個MD5值加密后請求后端執(zhí)行秒傳。后端通過兩個MD5和長度信息判斷是否存在該文件，如果存在則完成秒傳。

這樣做，雖然理論上也不能保證不會發(fā)生哈希碰撞，但通過這種方式，至少將概率降低了許多。

最后給大家留一個思考題：后端拿到MD5后，怎么判斷后端是否有這個MD5呢? 這可是大廠經(jīng)常愛考的一個面試題哦，來開動腦筋想一下!

本文轉(zhuǎn)載自微信公眾號「 編程技術(shù)宇宙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 編程技術(shù)宇宙公眾號。