下圖列舉了當下存在的一些常見的直播場景。
秀場直播是國內最早出現的直播形式，在各個直播平台上是比較常見的。
遊戲直播，像鬥魚、虎牙、戰旗等直播平台都是比較典型的遊戲直播平台，遊戲直播對位元速率要求比較高，**人數也多，所以它也是流量貢獻最大的直播形式。
答題直播是今年年初左右出現的新型直播形式，每場直播的時間不長，突發流量比較高。
3~5秒延時對於多數常見的直播形式一般問題不大, 但是對於某些場景效果會很差。
對於連麥場景影響是最明顯的, 連麥超過1秒，對話可能就沒辦法維持下去了。現在一般直播平台的連麥直播需求都會借助第三方的連麥服務，然後再推給直播cdn廠商。
在答題直播場景下, 一般都要求在一段時間內使用者提交答案，如果有各別使用者延遲比較大，這樣對使用者是不公平的。雖然直播平台仍然使用flv的傳輸形式完成答題直播，但是基本都會採用sei插幀等方法來解決時間同步問題, 需要平台的端和直播cdn做一些配合來完成。
從對業務的支援層面來看, 僅僅有rtmp、flv這種3~5秒延時以上的直播形式已經不夠了, 需要對更低延遲的直播業務進行支援。從技術的角度來看，國內常用的flv、rtmp這種直播手段，本身是adobe自己的標準, 而且很快會停止對flash的維護, 另一方面webrtc技術的興起，chrome、safari等瀏覽器也都進行了支援，因此也需要對新的技術有一些調研和準備。
基於對於這些問題的思考, 阿里雲cdn也開展了對低延時直播技術的研發。
在做短延時直播專案的時候，我們在技術選型上做了一些思考。
首先，是必須要相容已有直播業務和技術棧，因為阿里雲直播cdn系統已經有了很多客戶，短延時直播需要從現有直播的業務上慢慢衍生, 可以讓客戶在短延時和常規直播手段進行切換, 這也是處於業務穩定性的考慮。
第二，對於直播來講, 秒開是乙個很重要的指標，我們後面詳細展開。當然卡頓也是重要的指標，因為webrtc在移動端擁塞控制和重傳方面有一些處理，所以卡頓率方面不會比tcp差。
第三，對齊到webrtc會是最終的結果, 畢竟使用者能夠使用h5就可以直接推流或者**直播, 更方便客戶的接入和使用。但由於完整的支援webrtc要解決加解密、打洞、音訊格式等問題, 所以前期考慮只使用webrtc中的一部分技術，完整支援webrtc會是二期的工作。
已有的業務，無論是、大小檔案、點播、直播，這些都是在tcp通訊基礎上實現的，所以短延時直播在開展的時候我們就思考了tcp的可能性。
之前有乙個彩票直播業務的客戶, 因為客戶擔心使用者懷疑刮獎的時效性, 所以對延時要求就非常苛刻, 客戶的端進行延遲優化, 延遲也可以做到1秒內。
所以，一開始我們有了這樣乙個結論，網路正常的情況下，使用現有的rtmp、flv進行分發，延遲也可以做到1秒以內。
基於這些考慮，我們最終採用了以下的方案。webrtc是當下短延時流**的傳輸比較熱門的技術, 所以在實現短延時直播的同時會考慮使用webrtc相關的一些技術。原有的rtmp, flv, hls這些使用tcp，新增阿里自研私有artp短延時方案，最終會支援webrtc，artp和webrtc使用udp傳輸。
在研發之前，我們會對各項部署做一些思考。
這樣下來對於直播秒開的體驗來說就會很差，所以在實現低延時直播方案時針對這個問題需要進行優化處理, 去掉一些不必要的環節。
前面講過使用tcp傳輸的時候，網路抖動出現堆積時，需要丟幀，但是一定是丟完整的幀，不能丟片段。那為什麼rtp場景下為什麼沒有這個問題？以h264為例，rtp在封裝的時候，如果nal單元小於mtu，那麼我們認為乙個rtp包可以完整封裝乙個nal單元的，如果出現丟幀，那麼我們認為缺少的是乙個完整的nal單元，對後面nal單元解析是沒有問題的，不會出現資料錯亂。
如果乙個nal單元大於乙個mtu的時候，假設乙個nal單元需要三個rtp包封裝，不管丟到哪乙個還是全部丟掉，接收端都可以標識出這個nal單元，不會影響其他nal單元的解析。
h264和aac資料會在內部先進行切片，放到平滑傳送佇列再傳送給對端，同時重傳包也會進入平滑傳送佇列, 並且會放到平滑傳送佇列的隊首位置。
fec是靠冗餘傳輸，來提高容錯率。關鍵幀10%冗餘率, 非關鍵幀5%，根據丟包判斷出網路狀況，動態調整冗餘度。
tengine是阿里開源的伺服器軟體, 阿里雲cdn的檔案、點播、直播功能都是在其基礎上進行開發，而在短延時直播功能的實現我們也是把開源的webrtc的庫進行了一些改造。選擇tengine來做主要原因也是因為對其非常的熟悉，而且在其基礎上也積累了很多配套的技術，包括配置下發管理、日誌收集、業務處理等。
最後，我們來看下實際的資料情況。
目前短延時直播功能是在一些地區進行了部署和驗證，還沒到全網鋪開的階段。
秒開資料比原來flv訪問提公升很大, udp互動省去了三次握手環節。錯誤率和延遲都有了較大的提公升。這裡目前只對比了下行，從已經灰度的一些節點來看，上行卡頓資料要優於原有rtmp的推流。
對於cdn要做的另乙個事情就是優化傳輸，其實無論對於檔案加速還是流**加速，傳輸永遠都是最重要的，cdn這個分發網路本身就是為了優化傳輸而存在。
從實踐來看，udp傳輸比原來的tcp傳輸對資源消耗要多，而且重傳、封包、fec冗餘計算等都會額外增加計算量，在多程序模式下可能還會遇到記憶體資源的過多消耗。
閱讀原文
Polymer Google的下一代Web UI庫
由原palm webos開發enyo框架的團隊加盟google後打造。基於shadow dom,custom elements,mdv等最新瀏覽器特性，支援web components，代表了下一代web框架的方向 一切皆元件，儘量減少 量，儘量減少框架限制。當然，這也意味著google現在有三個相...
對下一代網路的思考
今天下午在學校聽了乙個講座，是關於下一代網際網路的，講演者是來自新加坡南洋理工大學的乙個副教授，因為自己對網路比較感興趣，去聽了一下，呵呵，這個或許是我碩士研究生生涯最後乙個講座。這位副教授來頭不少，在沒有開始正式講演之前，主持人念了很長一段頭銜，不過還好，報告還是如期舉行。報告是以ppt形式出現的...
下一代社群FAQ的變化。
下一代社群faq的變化。1 faq的審核權 faq的審核者將不僅僅侷限為斑竹，各個社群的陪審員們也可以審核。各個社群的陪審員們指滿足以下條件，使用者的karma表現靈好 使用者在該社群累計所得專家分在1萬分以上。滿足這些條件的使用者，系統會定時把他增加到陪審團中去，陪審員不是終身制的，系統會定時取消...