企業(yè)在打造一款互聯(lián)網(wǎng)產(chǎn)品時，用戶體驗的優(yōu)劣往往會直接牽扯到產(chǎn)品的成敗。
而在當(dāng)下的互聯(lián)網(wǎng)產(chǎn)品中，短視頻、線上 KTV、線上多媒體互動等場景可謂是越來越多。此類產(chǎn)品非常依賴價值創(chuàng)造者，比如美女主播，小視屏制作者，音樂制作人等等，為價值提供者創(chuàng)造一個優(yōu)質(zhì)的用戶體驗對這些互聯(lián)網(wǎng)產(chǎn)品來說顯得尤為重要。
那么，如何才能保障這一點呢？下面我們就從價值提供者生產(chǎn)并傳播價值 (上傳數(shù)據(jù)) 的用戶體驗方面來聊一聊。
如上圖所示，這應(yīng)該是當(dāng)下很多 APP都面臨的問題，上傳失敗、上傳慢，導(dǎo)致了在用戶體驗上不盡如人意，從宏觀層次來看我們可以把原因大致歸結(jié)如下：
Mobile
移動端網(wǎng)絡(luò)多種多樣, wifi、2g、3g、4g，相比于 PC端，移動互聯(lián)網(wǎng)較為顯著的一個特點就是環(huán)境很不穩(wěn)定，丟包比較嚴(yán)重，這就直接導(dǎo)致了客戶端與服務(wù)端的連通率較低，導(dǎo)致文件上傳下載速度很慢、成功率較低。
Long journey
另一點是移動端網(wǎng)絡(luò)和 PC端網(wǎng)絡(luò)都必須要面對的問題——廣域網(wǎng)高延時。從網(wǎng)易云對象存儲分布于各個區(qū)域布點機房之間的延時監(jiān)控可以了解到，華北、西北、西南等區(qū)域節(jié)點到杭州機房的延時基本是 30ms～50ms左右，到了晚上網(wǎng)絡(luò)繁忙時，有時延時往往會達(dá)到百 ms級別，丟包率也會相應(yīng)變高。
You are in china
國內(nèi)網(wǎng)絡(luò)環(huán)境還有一個典型的問題就是電信、聯(lián)通南北分隔，還有諸多小運營商的網(wǎng)絡(luò)問題。國外和跨境訪問就更不必說了，無論是國內(nèi)訪問國外還是國外訪問國內(nèi)基本只能干著急，延時丟包高到嚇人。
深入到技術(shù)層面來看，技術(shù)人員都清楚這是因為互聯(lián)網(wǎng)的根基——偉大的 TCP協(xié)議在此類移動、廣域網(wǎng)絡(luò)環(huán)境下顯得有些捉襟見肘了。正如下圖所示，我們面臨的是一條質(zhì)量極差的底層 TCP數(shù)據(jù)傳輸通道，丟包 （ High loss rate)）和高延時 （ High RTT） 使得這條數(shù)據(jù)傳輸通道變得又窄又擁擠。
網(wǎng)易云提供解決方案
網(wǎng)易云作為一流的存儲服務(wù)提供商（這是我們的目標(biāo)），為網(wǎng)易集團(tuán)內(nèi)部和諸多合作伙伴提供了優(yōu)質(zhì)的對象存儲以及基于存儲的上下行數(shù)據(jù)傳輸加速等增值服務(wù)，一站式地為企業(yè)解決了移動互聯(lián)網(wǎng)時代非結(jié)構(gòu)數(shù)據(jù)的管理難題。
在國內(nèi)、國外和跨境上傳難、上傳慢等是我們在與各行各業(yè)的互聯(lián)網(wǎng)產(chǎn)品對接時它們所共同反映的問題。為此，從2014年初開始，網(wǎng)易云就著手打造統(tǒng)一的解決方案來幫助產(chǎn)品克服這一難題，目前，我們也已有了非常完善的解決方案。下面先來看一下我們?nèi)〉玫囊恍┏晒?/p>
加速效果明顯
網(wǎng)易云提供的解決方案幫助產(chǎn)品在傳輸速度和上傳成功率上都取得了不錯的提升效果，得到了用戶肯定。( 上圖是采用全國各級進(jìn)行基調(diào)測試而得到的客觀數(shù)據(jù) )
接入便利
企業(yè)只需要使用 SDK(Android、iOS、Web PC)，就可以在短時間內(nèi)全方位解決各種上傳不了、上傳慢、安全上傳等問題，讓產(chǎn)品用戶擁有一流的上傳體驗。
而如果有企業(yè)想要自己去構(gòu)建一套客戶上傳系統(tǒng)，就會涉及到方方面面的投入：
- 靠譜的上傳協(xié)議：支持文件分片、斷點上傳、流式上傳、安全上傳（HTTPS）
- 上傳服務(wù)端系統(tǒng)：支持高并發(fā)、高吞吐（設(shè)計大量數(shù)據(jù)交互的服務(wù)端實際往往是很困難的）
- 全平臺的 SDK：包括移動端 Android、iOS； Web端；PC端
- 大量資源投入等： 包括大量的人力資源（開發(fā)、運維）、各個地區(qū)邊緣節(jié)點，國內(nèi)外的專線資源等等
這么多的投入，資本耗費起碼也得數(shù)百萬。而使用網(wǎng)易云，企業(yè)可以零成本接入上傳系統(tǒng)，和網(wǎng)易的合作伙伴站在同樣的技術(shù)起跑線上去打造產(chǎn)品。
技術(shù)大揭秘
接下來就來和大家分享下我們在技術(shù)上是如何打造上述上傳解決方案的。
我們在資源、架構(gòu)、系統(tǒng)優(yōu)化等方面的投入都非常之多，其中，主要的優(yōu)化工作包括：
- 邊緣布點
- TCP協(xié)議調(diào)優(yōu)
- 應(yīng)用層協(xié)議優(yōu)化
- 移動端上傳優(yōu)化
- 路由優(yōu)化系統(tǒng)
邊緣布點與TCP優(yōu)化
客戶端到基站主要是 High Loss Rate，即高丟包率問題；基站到數(shù)據(jù)中心之間主要是 High RTT 高延時問題。
我們的解決思路是一分為二。為了解決后半部分網(wǎng)絡(luò)的高延時問題，我們將邊緣節(jié)點服務(wù)?部署到離用戶最近的地方，結(jié)合高速專線等方式快速地將用戶數(shù)據(jù)上傳到數(shù)據(jù)中心。
目前，網(wǎng)易云對象存儲直傳加速網(wǎng)絡(luò)已經(jīng)覆蓋了國內(nèi)的華中、華北、華南、華東、西南、西北幾個大區(qū)；國外主要包括美國、日本、東南亞、歐洲等區(qū)域，其他區(qū)域覆蓋也在不斷完善中。
下圖為國內(nèi)覆蓋的區(qū)域：
![Uploading 6_737445.png . . .]
在國外，我們使用 aws機房的節(jié)點進(jìn)行覆蓋，通過國外高速專線接入國內(nèi)機房。
![Upload 7.png failed. Please try again.]
邊緣節(jié)點與數(shù)據(jù)中心 ( NOS中心機房)之間的網(wǎng)絡(luò)是掌握在網(wǎng)易云自己手里的，所以優(yōu)化首先就是克服掉廣域網(wǎng)的高延時問題。我們在邊緣節(jié)點和中心機房之間建立了長連接池，并且對 TCP連接做了一定的參數(shù)調(diào)優(yōu)，比如 tcpslowstartafteridle、tcp_wmem 等等。這樣做避免了每次上傳數(shù)據(jù)的慢啟動過程，保障一片數(shù)據(jù)只需要經(jīng)過一次 RTT即可發(fā)送到數(shù)據(jù)中心 (理論上的最優(yōu)效果)。
以下為線上基調(diào)測試北京節(jié)點優(yōu)化前和優(yōu)化后邊緣節(jié)點到中心機房的統(tǒng)計 （邊緣節(jié)點到中心機房的時間，包含寫 NOS），可以看到優(yōu)化后，相比于杭州 BGP邊緣節(jié)點到杭州中心機房 (同機房)，北京 AWS與之基本相差一個 RTT 30ms左右。
![Uploading 8_761716.png . . .]
應(yīng)用層協(xié)議優(yōu)化
傳統(tǒng)標(biāo)準(zhǔn)的對象存儲服務(wù)（AWS S3 基本是事實標(biāo)準(zhǔn)) 原生就是為服務(wù)端進(jìn)行設(shè)計的，包括系統(tǒng)設(shè)計及其提供的接口等都并不能很好地適應(yīng)移動網(wǎng)絡(luò)的需求。其中最重要的一點是傳統(tǒng)(也是標(biāo)準(zhǔn)的) 對象存儲的存儲接口是不能支持?jǐn)帱c續(xù)傳的，其分塊上傳協(xié)議也主要是針對用戶上傳大文件的場景（最小分塊大小為 5M）。
就當(dāng)前移動互聯(lián)網(wǎng)的應(yīng)用場景而言，為了給用戶提供更好的體驗，包括語音、圖片和視頻等資源一般都是在確保不影響用戶體驗的基礎(chǔ)上進(jìn)行大幅度的數(shù)據(jù)壓縮，其上傳文件的大小往往都不會超過 1M，最小分塊 5M完全派不上用場。
所以，必須為直傳設(shè)計一套通用的協(xié)議以支持移動端上傳，我們主要考慮了如下兩個基本的設(shè)計目標(biāo)：
- 斷點續(xù)傳：支持小文件短時間內(nèi)的斷點續(xù)傳，支持大文件較長時間的斷點續(xù)傳。
- 流式上傳：支持大小文件的流式上傳，即在不知道最終文件大小的情況下進(jìn)行一部分一部分的流式上傳，比如支持邊錄邊傳。
如下為核心接口 PostPart
- offset 為上傳數(shù)據(jù)在整個文件中的偏移
- x-nos-token 為上傳令牌
- complete 標(biāo)識是最后一個文件分片數(shù)據(jù)
- context 為服務(wù)端返回的標(biāo)識，用于斷點續(xù)傳場景下唯一標(biāo)識此次文件上傳
移動端上傳優(yōu)化
為了應(yīng)對移動端網(wǎng)絡(luò)的高丟包率，除了設(shè)計如上專用于分片上傳的協(xié)議之外，我們還做了以下幾點優(yōu)化：
HTTP PipeLine
在移動端網(wǎng)絡(luò)環(huán)境下，為了提高文件上傳的成功率，客戶端往往會把文件進(jìn)行切片。比如 1M的文件以 16K作為一個分片，一個分片一個分片進(jìn)行上傳。
傳統(tǒng)的 HTTP 1.1 請求的模式 （即當(dāng)前大部分用戶使用的方式）為如下的 no pipelining模式。每一次分片上傳都是等待一次 RTT之后才能夠進(jìn)行上傳。在廣域網(wǎng)環(huán)境下，比如?外的用戶上傳到杭州，下一次分片上傳必須得等待上一次分片上傳完成，也就是好幾百 ms的時間之后才能進(jìn)行下一分片的上傳。
顯然在廣域網(wǎng)環(huán)境下傳統(tǒng)的 HTTP non pipeling協(xié)議模式是不太合適的。當(dāng)前，網(wǎng)易云的 SDK 支持 Http pipeling模式，在默認(rèn)情況下使用 Http pipling模式進(jìn)行上傳。充分利用了客戶端的上傳帶寬，同時也使得上傳速度對客戶端分塊大小不是很敏感。
網(wǎng)易云在實驗環(huán)境下，使用樹莓派 + Facebook Augmented Traffic Control （FaceBook開源的網(wǎng)絡(luò)環(huán)境模擬工具，其主要用來測試 FaceBook社交網(wǎng)絡(luò)在一些弱網(wǎng)絡(luò)環(huán)境的表現(xiàn)） 對 pipeline進(jìn)行了一輪測試，如下為測試效果。且其在實際線上的表現(xiàn)也非常好，能夠在服務(wù)端和網(wǎng)絡(luò)優(yōu)化的基礎(chǔ)上再得到近一倍的速度提升。
- 國內(nèi)：
國外：
連接池管理
完成一次 tcp 3次握手的時間基本在上百 ms的時間，所以 NOS Andriod SDK 、iOS SDK等 SDK上維護(hù)了與上傳節(jié)點的連接池，避免每一次上傳之前連接建立的時間消耗。
路由優(yōu)化系統(tǒng)
另外，廣域網(wǎng)系統(tǒng)也在不斷地調(diào)整的過程中。為了獲得最佳的上傳效果，我們構(gòu)建了一個閉環(huán)系統(tǒng)，使用基調(diào)動態(tài)跟蹤廣域網(wǎng)最佳路由，找到最優(yōu)策略。
線上基調(diào)隨機路由數(shù)據(jù)=>統(tǒng)計各路由質(zhì)量=>生產(chǎn)最佳系統(tǒng)路由=>更新線上路由
更多精彩
除了直傳加速服務(wù)，網(wǎng)易云對象存儲服務(wù)在典型的數(shù)據(jù)資源，比如圖片、音視頻、反垃圾等方面還做了其他的多樣的服務(wù)生態(tài)，一站式解決互聯(lián)網(wǎng)時代非結(jié)構(gòu)數(shù)據(jù)管理難題，助力企業(yè)高效起步。
- 豐富的圖片處理
- 原生支持視頻點播
- 視頻截圖、轉(zhuǎn)碼服務(wù)
- 易盾一鍵反垃圾
- 事件通知
- 豐富的訪問控制
點擊了解網(wǎng)易云基礎(chǔ)服務(wù)（蜂巢）對象存儲服務(wù)
