百度網盤如何大文件實現秒傳?


百度網盤上傳時,如果是超過256KB的文件,將計算整個文件的MD5和文件前256KB內容的MD5,並對兩個MD5值加密后請求后端執行秒傳。后端通過兩個MD5和長度信息判斷是否存在該文件,如果存在則完成秒傳。

有個讀者在微信上問我:百度網盤的秒傳功能是如何實現的?

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

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

我把我的猜測告訴了他,結果他問了一句:如果發生哈希沖突了怎么辦呢?。

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

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

MD5 沖突

首先,只用一個哈希值,已經有事實證明是會發生沖突的,而不只是理論上。

比如我在知乎上找到了一個例子,下面兩段不同的數據,只相差兩個字節:

分別計算md5,結果是一樣的:

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

甚至,有人還基於此提出一種哈希碰撞攻擊:如果我知道一個文件的md5值,但拿不到這個文件,我通過數學計算,構造一個相同md5的文件,那豈不是就把那個文件直接給我轉存過來了?如果是一個私密的文件呢?那不出事了!

百度網盤的做法

那百度網盤是咋做的呢?

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

可以看到,百度網盤對文件進行了分塊傳輸,這也是目前業界比較流行的做法,對大文件進行分塊,如果網絡不好斷開了,下次只需要傳輸剩下的分塊就行了,做到了斷點續傳。

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

來看一下請求的參數,是一個Form表單,有這么幾個字段:

content-length: 文件長度

content-md5: 文件的MD5

slice-md5: 文件切片的MD5

看到這里你估計猜到了,肯定是這三個參數聯合判斷,同時滿足條件才算是同一個文件!

來看下服務器響應了什么:

秒傳成功了!

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

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

接着,我想看一下這個切片md5,百度網盤是怎么在切的。

通過網絡通信中的Initiator功能,可以定位到是哪里的JS代碼在發生請求:

通過調用堆棧,看到了叫rapidUpload這個函數,再上下一跟進,找到了這個切片MD5計算的地方:

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

但奇怪的是,我扣取了文件的前256個字節,計算出來的md5,和它接口中上傳的參數並不一致!

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

我又打了斷點在計算的位置,發現它計算的跟我計算的又是一樣的,但通過網絡發出去以后就變了,真是薛定諤的MD5,奇怪了!

不過,程序不是量子力學,它不會騙人,很快我就找到了問題所在:百度網盤可能擔心自己的路數被發現,對文件的MD5和切片MD5都進行了加密!

這就是加密函數:

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

好了,現在可以回答前面讀者的問題了:

百度網盤上傳時,如果是超過256KB的文件,將計算整個文件的MD5和文件前256KB內容的MD5,並對兩個MD5值加密后請求后端執行秒傳。后端通過兩個MD5和長度信息判斷是否存在該文件,如果存在則完成秒傳。

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

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

 

原文:https://developer.51cto.com/art/202104/659651.htm


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2024 CODEPRJ.COM