壓縮冗餘資訊

語言: CN / TW / HK

我們傳輸的大量資訊都是少量資訊的簡單組合(yet another 冪律?)。

任何資訊均如此。對於文字資訊,有固定的短語,俚語,名言警句,對於多媒體,有正規化化前奏,BGM,名人舞姿,常見鏡頭,體現在資料包中就是一些 0,1 組合成的固定位元片段。

把這些片段甄別出來,為其關聯唯一短 ID,部署在內容的中間轉發節點上,事情將變得高尚。

轉發資料包時,用資料包的任意子串匹配這些片段(諸如 Leetcode “求最長子串”,練熟了還是有用的。),一旦命中,即可將較長子串替換成較短 ID,相當於僅傳輸字典索引,時間換空間,大大降低傳輸量,從而節省頻寬。

圖中那張“共享的 ‘內容 -> ID’ 對映表”可通過離線/線上學習獲得,也可人工配置。

說起線上學習,可以維護一個 LRU 連結串列,儲存最 Hot 的 Top N 片段。

最後說優化,還是那句話,所有優化都需要注入新資訊,優化匹配演算法的資訊來自現實世界。

打個比方,緊接著“當我避開你的溫柔後”的大概率是“淚開始墜落”。或者可為每個區域,甚至每個使用者維護一個字典,現實世界具有相同特徵的 entry 傳輸的資料重複度也偏高。比如說涉及浙江溫州的資料傳輸,專門建立一個皮鞋相關的字典,是高尚的。

這種傳輸優化可用於樸素的 CDN 動態加速,也可用於樸素的 CDN 靜態加速回源,但注意,一定要樸素,不然得不償失,但最能打的場景還是隧道傳輸加速了。

前兩週我提到過,統計複用率足夠高時,端到端傳輸優化很難閉環,單流結果不再由單流行為決定,大多數端到端演算法被認為不靠譜,不如降低傳送量,從而提高通過率,最大程度減少重傳時延。進一步說,如果大家都這麼做,世界又將重新變得高尚。

傳統 TCP/IP 網路早被 CDN 蓋了一個內容層,鑑於此,本文說的這類樸素的內容層,從不識別內容,只識別“一段具有特徵的位元流”,將其編碼成更短的位元流,就算賺到,細節可能還包括高效的匹配演算法和編碼方案。

至於古時候儲存介質(竹簡,石頭)和傳輸介質(馬車)都很貴的時候,書面語總比口語惜字如金,也是這個意思。白話文被寫下來的行為在宋朝之後普及,因為宋朝之後大範圍普及了紙,或者還有稍許活字印刷術。

超過 20 ms 的傳輸在平時上網中就很少見,絕大多數內容都是通過 CDN 接入,而 CDN 排程機制基本上不會排程到太遠的地方,因此果真要做長傳,一定要控制丟包率,如果丟包率不能控制,就選擇抗丟包的演算法,比如 BBR。降低丟包還有一個方法將是少發資料,發得少丟得少。就是本文。

浙江溫州皮鞋溼,下雨進水不會胖。