歡迎訪問網易雲社區,瞭解更多網易技術產品運營經驗。 安全
在當下的互聯網產品中,短視頻、線上 KTV、線上多媒體互動等場景可謂是愈來愈多。此類產品很是依賴價值創造者,好比美女主播,小視屏製做者,音樂製做人等等,爲價值提供者創造一個優質的用戶體驗對這些互聯網產品來講顯得尤其重要。
那麼,如何才能保障這一點呢?下面咱們就從價值提供者生產並傳播價值 (上傳數據) 的用戶體驗方面來聊一聊。
如上圖所示,這應該是當下不少 APP都面臨的問題,上傳失敗、上傳慢,致使了在用戶體驗上不盡如人意,從宏觀層次來看咱們能夠把緣由大體歸結以下:
服務器
移動端網絡多種多樣, wifi、2g、3g、4g,相比於 PC端,移動互聯網較爲顯著的一個特色就是環境很不穩定,丟包比較嚴重,這就直接致使了客戶端與服務端的連通率較低,致使文件上傳下載速度很慢、成功率較低。網絡
另外一點是移動端網絡和 PC端網絡都必需要面對的問題——廣域網高延時。從網易雲對象存儲分佈於各個區域布點機房之間的延時監控能夠了解到,華北、西北、西南等區域節點到杭州機房的延時基本是 30ms~50ms左右,到了晚上網絡繁忙時,有時延時每每會達到百 ms級別,丟包率也會相應變高。架構
國內網絡環境還有一個典型的問題就是電信、聯通南北分隔,還有諸多小運營商的網絡問題。國外和跨境訪問就更不必說了,不管是國內訪問國外仍是國外訪問國內基本只能乾着急,延時丟包高到嚇人。
深刻到技術層面來看,技術人員都清楚這是由於互聯網的根基——偉大的 TCP協議在此類移動、廣域網絡環境下顯得有些捉襟見肘了。正以下圖所示,咱們面臨的是一條質量極差的底層 TCP數據傳輸通道,丟包 ( High loss rate))和高延時 ( High RTT) 使得這條數據傳輸通道變得又窄又擁擠。
併發
網易雲做爲一流的存儲服務提供商(這是咱們的目標),爲網易集團內部和諸多合做夥伴提供了優質的對象存儲以及基於存儲的上下行數據傳輸加速等增值服務,一站式地爲企業解決了移動互聯網時代非結構數據的管理難題。
在國內、國外和跨境上傳難、上傳慢等是咱們在與各行各業的互聯網產品對接時它們所共同反映的問題。爲此,從2014年初開始,網易雲就着手打造統一的解決方案來幫助產品克服這一難題,目前,咱們也已有了很是完善的解決方案。下面先來看一下咱們取得的一些成果:運維
網易雲提供的解決方案幫助產品在傳輸速度和上傳成功率上都取得了不錯的提高效果,獲得了用戶確定。( 上圖是採用全國各級進行基調測試而獲得的客觀數據 )tcp
企業只須要使用 SDK(Android、iOS、Web PC),就能夠在短期內全方位解決各類上傳不了、上傳慢、安全上傳等問題,讓產品用戶擁有一流的上傳體驗。
而若是有企業想要本身去構建一套客戶上傳系統,就會涉及到方方面面的投入:
○ 靠譜的上傳協議:支持文件分片、斷點上傳、流式上傳、安全上傳(HTTPS)
○ 上傳服務端系統:支持高併發、高吞吐(設計大量數據交互的服務端實際每每是很困難的)
○ 全平臺的 SDK:包括移動端 Android、iOS; Web端;PC端
○ 大量資源投入等: 包括大量的人力資源(開發、運維)、各個地區邊緣節點,國內外的專線資源等等
這麼多的投入,資本耗費起碼也得數百萬。而使用網易雲,企業能夠零成本接入上傳系統,和網易的合做夥伴站在一樣的技術起跑線上去打造產品。高併發
接下來就來和你們分享下咱們在技術上是如何打造上述上傳解決方案的。
咱們在資源、架構、系統優化等方面的投入都很是之多,其中,主要的優化工做包括:
○ 邊緣布點工具
○ TCP協議調優測試
○ 應用層協議優化
○ 移動端上傳優化
○ 路由優化系統
客戶端到基站主要是 High Loss Rate,即高丟包率問題;基站到數據中心之間主要是 High RTT 高延時問題。
咱們的解決思路是一分爲二。爲了解決後半部分網絡的高延時問題,咱們將邊緣節點服務器部署到離用戶最近的地方,結合高速專線等方式快速地將用戶數據上傳到數據中心。
目前,網易雲對象存儲直傳加速網絡已經覆蓋了國內的華中、華北、華南、華東、西南、西北幾個大區;國外主要包括美國、日本、東南亞、歐洲等區域,其餘區域覆蓋也在不斷完善中。
下圖爲國內覆蓋的區域:
在國外,咱們使用 aws機房的節點進行覆蓋,經過國外高速專線接入國內機房。
邊緣節點與數據中心 ( NOS中心機房)之間的網絡是掌握在網易雲本身手里的,因此優化首先就是克服掉廣域網的高延時問題。咱們在邊緣節點和中心機房之間創建了長鏈接池,而且對 TCP鏈接作了必定的參數調優,好比 tcpslowstartafteridle、tcp_wmem 等等。這樣作避免了每次上傳數據的慢啓動過程,保障一片數據只須要通過一次 RTT便可發送到數據中心 (理論上的最優效果)。
如下爲線上基調測試北京節點優化前和優化後邊緣節點到中心機房的統計 (邊緣節點到中心機房的時間,包含寫 NOS),能夠看到優化後,相比於杭州 BGP邊緣節點到杭州中心機房 (同機房),北京 AWS與之基本相差一個 RTT 30ms左右。
傳統標準的對象存儲服務(AWS S3 基本是事實標準) 原生就是爲服務端進行設計的,包括系統設計及其提供的接口等都並不能很好地適應移動網絡的需求。其中最重要的一點是傳統(也是標準的) 對象存儲的存儲接口是不能支持斷點續傳的,其分塊上傳協議也主要是針對用戶上傳大文件的場景(最小分塊大小爲 5M)。
就當前移動互聯網的應用場景而言,爲了給用戶提供更好的體驗,包括語音、圖片和視頻等資源通常都是在確保不影響用戶體驗的基礎上進行大幅度的數據壓縮,其上傳文件的大小每每都不會超過 1M,最小分塊 5M徹底派不上用場。
因此,必須爲直傳設計一套通用的協議以支持移動端上傳,咱們主要考慮了以下兩個基本的設計目標:
斷點續傳:支持小文件短期內的斷點續傳,支持大文件較長時間的斷點續傳。
流式上傳:支持大小文件的流式上傳,即在不知道最終文件大小的狀況下進行一部分一部分的流式上傳,好比支持邊錄邊傳。
以下爲核心接口 PostPart
POST /${bucketName}/${objectName}?offset=${Offset}&complete=${Complete}&context={context}&version=1.0 HTTP/1.1 Content-Length: ${length} Content-Type: ${contentType} x-nos-token: ${token} <data of body>
○ offset 爲上傳數據在整個文件中的偏移
○ x-nos-token 爲上傳令牌
○ complete 標識是最後一個文件分片數據
○ context 爲服務端返回的標識,用於斷點續傳場景下惟一標識這次文件上傳
爲了應對移動端網絡的高丟包率,除了設計如上專用於分片上傳的協議以外,咱們還作了如下幾點優化:
在移動端網絡環境下,爲了提升文件上傳的成功率,客戶端每每會把文件進行切片。好比 1M的文件以 16K做爲一個分片,一個分片一個分片進行上傳。
傳統的 HTTP 1.1 請求的模式 (即當前大部分用戶使用的方式)爲以下的 no pipelining模式。每一次分片上傳都是等待一次 RTT以後纔可以進行上傳。在廣域網環境下,好比海外的用戶上傳到杭州,下一次分片上傳必須得等待上一次分片上傳完成,也就是好幾百 ms的時間以後才能進行下一分片的上傳。
顯然在廣域網環境下傳統的 HTTP non pipeling協議模式是不太合適的。當前,網易雲的 SDK 支持 Http pipeling模式,在默認狀況下使用 Http pipling模式進行上傳。充分利用了客戶端的上傳帶寬,同時也使得上傳速度對客戶端分塊大小不是很敏感。
網易雲在實驗環境下,使用樹莓派 + Facebook Augmented Traffic Control (FaceBook開源的網絡環境模擬工具,其主要用來測試 FaceBook社交網絡在一些弱網絡環境的表現) 對 pipeline進行了一輪測試,以下爲測試效果。且其在實際線上的表現也很是好,可以在服務端和網絡優化的基礎上再獲得近一倍的速度提高。
國內:
國外:
完成一次 tcp 3次握手的時間基本在上百 ms的時間,因此 NOS Andriod SDK 、iOS SDK等 SDK上維護了與上傳節點的鏈接池,避免每一次上傳以前鏈接創建的時間消耗。
另外,廣域網系統也在不斷地調整的過程當中。爲了得到最佳的上傳效果,咱們構建了一個閉環系統,使用基調動態跟蹤廣域網最佳路由,找到最優策略。
線上基調隨機路由數據=>統計各路由質量=>生產最佳系統路由=>更新線上路由
除了直傳加速服務,網易雲對象存儲服務在典型的數據資源,好比圖片、音視頻、反垃圾等方面還作了其餘的多樣的服務生態,一站式解決互聯網時代非結構數據管理難題,助力企業高效起步。
○ s豐富的圖片處理
○ 原生支持視頻點播
○ 視頻截圖、轉碼服務
○ 易盾一鍵反垃圾
○ 事件通知
○ 豐富的訪問控制
免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐
更多網易技術、產品、運營經驗分享請點擊。
相關文章:
【推薦】 【0門檻】PR稿的自我修養
【推薦】 30分鐘,讓你完全明白Promise原理