摘要:HTTP Live Streaming(縮寫是HLS)是一個由蘋果公司提出的基于HTTP的流媒體網絡傳輸協議。今天主要以HLS協議為中心講述它的一些原理。
HLS協議簡介
HTTP Live Streaming(縮寫是HLS)是一個由蘋果公司提出的基于HTTP的流媒體網絡傳輸協議。是蘋果公司QuickTime X和iPhone軟件系統的一部分。它的工作原理是把整個流分成一個個小的基于HTTP的文件來下載,每次只下載一些。當媒體流正在播放時,客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源,允許流媒體會話適應不同的數據速率。在開始一個流媒體會話時,客戶端會下載一個包含元數據的extended M3U (m3u8)playlist文件,用于尋找可用的媒體流。
HLS只請求基本的HTTP報文,與實時傳輸協議(RTP)不同,HLS可以穿過任何允許HTTP數據通過的防火墻或者代理服務器。它也很容易使用內容分發網絡來傳輸媒體流。
蘋果公司把HLS協議作為一個互聯網草案(逐步提交),在第一階段中已作為一個非正式的標準提交到IETF。但是,即使蘋果偶爾地提交一些小的更新,IETF卻沒有關于制定此標準的有關進一步的動作。
HLS整體架構
上面是HLS整體架構圖,可以看出,總共有三個部分:Server,CDN,Client.
HLS協議規定要求
1.視頻的封裝格式是TS。
2.視頻的編碼格式為H264,音頻編碼格式為MP3、AAC或者AC-3。
3.除了TS視頻文件本身,還定義了用來控制播放的m3u8文件(文本文件)。
為什么蘋果要提出HLS這個協議,其實他的主要是為了解決RTMP協議存在的一些問題。比如RTMP協議不使用標準的HTTP接口傳輸數據,所以在一些特殊的網絡環境下可能被防火墻屏蔽掉。但是HLS由于使用的HTTP協議傳輸數據,不會遇到被防火墻屏蔽的情況(該不會有防火墻連80接口都不放過吧)。
另外于負載,RTMP是一種有狀態協議,很難對視頻服務器進行平滑擴展,因為需要為每一個播放視頻流的客戶端維護狀態。而HLS基于無狀態協議(HTTP),客戶端只是按照順序使用下載存儲在服務器的普通TS文件,做負責均衡如同普通的HTTP文件服務器的負載均衡一樣簡單。
另外HLS協議本身實現了碼率自適應,不同帶寬的設備可以自動切換到最適合自己碼率的視頻播放。其實HLS最大的優勢就是他的親爹是蘋果。蘋果在自家的IOS設備上只提供對HLS的原生支持,并且放棄了flash。Android也迫于平果的“淫威”原生支持了HLS。這樣一來flv,rtmp這些Adobe的視頻方案要想在移動設備上播放需要額外下點功夫。當然flash對移動設備造成很大的性能壓力確實也是自身的問題。
但HLS也有一些無法跨越的坑,比如采用HLS協議直播的視頻延遲時間無法下到10秒以下,而RTMP協議的延遲最低可以到3、4秒左右。所以說對直播延遲比較敏感的服務請慎用HLS。
HLS的請求流程:
1 http請求m3u8 的 url。
2 服務端返回一個m3u8的播放列表,這個播放列表是實時更新的,一般一次給出5段數據的url。
3 客戶端解析m3u8的播放列表,再按序請求每一段的url,獲取ts數據流。
RSA實現細節
密鑰生成
首先要使用概率算法來驗證隨機產生的大的整數是否質數,這樣的算法比較快而且可以消除掉大多數非質數。假如有一個數通過了這個測試的話,那么要使用一個精確的測試來保證它的確是一個質數。
除此之外這樣找到的p和q還要滿足一定的要求,首先它們不能太靠近,此外p-1或q-1的因子不能太小,否則的話N也可以被很快地分解。
此外尋找質數的算法不能給攻擊者任何信息,這些質數是怎樣找到的,尤其產生隨機數的軟件必須非常好。要求是隨機和不可預測。這兩個要求并不相同。一個隨機過程可能可以產生一個不相關的數的系列,但假如有人能夠預測出(或部分地預測出)這個系列的話,那么它就已經不可靠了。比如有一些非常好的隨機數算法,但它們都已經被發表,因此它們不能被使用,因為假如一個攻擊者可以猜出p和q一半的位的話,那么他們就已經可以輕而易舉地推算出另一半。
此外密鑰d必須足夠大,1990年有人證明假如p大于q而小于2q(這是一個很經常的情況)而,那么從N和e可以很有效地推算出d。此外e = 2永遠不應該被使用。
運算速度
由于進行的都是大數計算,使得RSA最快的情況也比DES慢上好幾倍,無論是軟件還是硬件實現。速度一直是RSA的缺陷。一般來說只用于少量數據加密。RSA的速度比對應同樣安全級別的對稱密碼算法要慢1000倍左右。
比起DES和其它對稱算法來說,RSA要慢得多。實際上Bob一般使用一種對稱算法來加密他的信息,然后用RSA來加密他的比較短的對稱密碼,然后將用RSA加密的對稱密碼和用對稱算法加密的消息送給Alice。
這樣一來對隨機數的要求就更高了,尤其對產生對稱密碼的要求非常高,因為否則的話可以越過RSA來直接攻擊對稱密碼。
密鑰分配
和其它加密過程一樣,對RSA來說分配公鑰的過程是非常重要的。分配公鑰的過程必須能夠抵擋一個從中取代的攻擊。假設Eve交給Bob一個公鑰,并使Bob相信這是Alice的公鑰,并且她可以截下Alice和Bob之間的信息傳遞,那么她可以將她自己的公鑰傳給Bob,Bob以為這是Alice的公鑰。Eve可以將所有Bob傳遞給Alice的消息截下來,將這個消息用她自己的密鑰解密,讀這個消息,然后將這個消息再用Alice的公鑰加密后傳給Alice。理論上Alice和Bob都不會發現Eve在偷聽他們的消息。今天人們一般用數字認證來防止這樣的攻擊。
RSA缺點
1)產生密鑰很麻煩,受到素數產生技術的限制,因而難以做到一次一密。
2)安全性,RSA的安全性依賴于大數的因子分解,但并沒有從理論上證明破譯RSA的難度與大數分解難度等價,而且密碼學界多數人士傾向于因子分解不是NP問題。
3)速度太慢,由于RSA 的分組長度太大,為保證安全性,n 至少也要 600 bits以上,使運算代價很高,尤其是速度較慢,較對稱密碼算法慢幾個數量級;且隨著大數分解技術的發展,這個長度還在增加,不利于數據格式的標準化。
RSA的安全性
首先,我們來探討為什么RSA密碼難于破解?
在RSA密碼應用中,公鑰KU是被公開的,即e和n的數值可以被第三方竊聽者得到。破解RSA密碼的問題就是從已知的e和n的數值(n等于pq),想法求出d的數值,這樣就可以得到私鑰來破解密文。從上文中的公式:d ≡e-1 (mod((p-1)(q-1)))或de≡1 (mod((p-1)(q-1))) 我們可以看出。密碼破解的實質問題是:從Pq的數值,去求出(p-1)和(q-1)。換句話說,只要求出p和q的值,我們就能求出d的值而得到私鑰。
當p和q是一個大素數的時候,從它們的積pq去分解因子p和q,這是一個公認的數學難題。比如當pq大到1024位時,迄今為止還沒有人能夠利用任何計算工具去完成分解因子的任務。因此,RSA從提出到現在已近二十年,經歷了各種攻擊的考驗,逐漸為人們接受,普遍認為是目前最優秀的公鑰方案之一。
然而,雖然RSA的安全性依賴于大數的因子分解,但并沒有從理論上證明破譯RSA的難度與大數分解難度等價。即RSA的重大缺陷是無法從理論上把握它的保密性能如何。
此外,RSA的缺點還有:A)產生密鑰很麻煩,受到素數產生技術的限制,因而難以做到一次一密。B)分組長度太大,為保證安全性,n 至少也要 600 bits 以上,使運算代價很高,尤其是速度較慢,較對稱密碼算法慢幾個數量級;且隨著大數分解技術的發展,這個長度還在增加,不利于數據格式的標準化。因此,使用RSA只能加密少量數據,大量的數據加密還要靠對稱密碼算法。
實例描述
在這篇科普小文章里,不可能對RSA算法的正確性作嚴格的數學證明,但我們可以通過一個簡單的例子來理解RSA的工作原理。為了便于計算。在以下實例中只選取小數值的素數p,q,以及e,假設用戶A需要將明文“key”通過RSA加密后傳遞給用戶B,過程如下:
(1)設計公私密鑰(e,n)和(d,n)。
令p=3,q=11,得出n=p×q=3×11=33;f(n)=(p-1)(q-1)=2×10=20;取e=3,(3與20互質)則e×d≡1 mod f(n),即3×d≡1 mod 20。
d怎樣取值呢?可以用試算的辦法來尋找。試算結果見下表:
通過試算我們找到,當d=7時,e×d≡1 mod f(n)同余等式成立。因此,可令d=7。從而我們可以設計出一對公私密鑰,加密密鑰(公鑰)為:KU =(e,n)=(3,33),解密密鑰(私鑰)為:KR =(d,n)=(7,33)。
(2)英文數字化。
將明文信息數字化,并將每塊兩個數字分組。假定明文英文字母編碼表為按字母順序排列數值,即:
則得到分組后的key的明文信息為:11,05,25。
(3)明文加密
用戶加密密鑰(3,33) 將數字化明文分組信息加密成密文。由C≡Me(mod n)得:
因此,得到相應的密文信息為:11,31,16。
(4)密文解密。
用戶B收到密文,若將其解密,只需要計算,即:
用戶B得到明文信息為:11,05,25。根據上面的編碼表將其轉換為英文,我們又得到了恢復后的原文“key”。
你看,它的原理就可以這么簡單地解釋!
當然,實際運用要比這復雜得多,由于RSA算法的公鑰私鑰的長度(模長度)要到1024位甚至2048位才能保證安全,因此,p、q、e的選取、公鑰私鑰的生成,加密解密模指數運算都有一定的計算程序,需要仰仗計算機高速完成。
評論
查看更多