目前視訊直播類app經典加速架構如下圖所示：
圖1 視訊直播類app經典加速架構
經典加速架構中，推流階段使用cdn就近接入實作推流加速，使用者播放拉流階段也可以使用cdn來做加速。由于cdn節點分布的廣泛性與邊緣性確定了客戶能夠就近接入與緩存。同直連源站相比，通過cdn加速直播推拉流取得了非常顯著的加速效果。
盡管已經采用了cdn加速，直播類app仍然經常出現通路慢、卡頓等問題，導緻大量使用者投訴，其主要原因是目前架構中存在以下幾方面問題：
假設使用者a從移動4g切換到家中聯通的wifi網絡，仍然按照原先的cdn節點進行加速會出現跨isp排程，通路品質差的悲劇事件。
下面通過推流階段2個場景說明改進方案如何確定排程到最佳cdn節點：
step 1： 使用者手機上local dns配置不準确，域名解析階段為域名dn傳回的是cdn節點b的ip_b，而非最優的cdn節點ip ip_a。
step 2： 推流的終端應用需要向cdn節點發起鑒權請求，cdn節點在收到鑒權請求後，需要提取終端的公網ip_c，然後除了轉發鑒權相關資訊到視訊源站之外，還必須帶上推流終端的公網ip_c 給源站。
step 3： 源站收到鑒權資訊和終端ip後，首先做鑒權工作，然後源站利用推流的域名dn和推流終端公網ip ip_c向httpdns伺服器發起請求，擷取最優的cdn節點ip_a，并将ip_a回傳給推流終端，告知推流終端ip_a是最佳接入節點
step 4： 終端推流時可以直接向cdn ip_a推流，或者等到發現出現卡頓、慢時切換到ip_a
step 1： 假設之前移動4g網絡下最佳cdn節點是ip_b，使用者網絡制式切換成聯通wifi後，最佳節點換成了ip_a。網絡切換後，終端第一步仍然向cdn節點ip_b推流，此時會鑒權失敗。
step 2： 重複場景1的step 2到step 4，推流終端最終可以找到最佳cdn節點ip_a并通過ip_a推流。
請注意，使用者網絡制式切換時，本架構能夠自動找出最優節點并順利切換到最優節點。
其他因排程問題導緻拉流、推流階段慢、卡頓的問題都可以通過上述方案解決。
接口簡單統一
無需對接多家httpdns
各地域使用同一個ip位址提供服務