隨后，杜思奇介紹了蜻蜓技術(shù)架構(gòu)的方案。目前，蜻蜓FM的數(shù)據(jù)分發(fā)方案是對于動態(tài)內(nèi)容大部分的API，并且采用國內(nèi)的BGP直連。對于國內(nèi)，蜻蜓FM確定了直接使用BGP直連的方案更為簡單一點(diǎn)，而對于國外，國內(nèi)BGP在國外覆蓋非常不給力，有些地區(qū)建設(shè)連接非常困難，因此蜻蜓FM在國外使用了動態(tài)API加速。在靜態(tài)內(nèi)容方面，音頻圖片和大部分頁面，采用了云存儲和CDN來進(jìn)行傳輸。

此外，在演講中，杜思奇透露了蜻蜓對于CDN方面的評估指標(biāo)，從上到下重要性依次降低，對直播行業(yè)來說最重要就是打開成功率。對于蜻蜓FM，也就是首音時長，實(shí)際操作中他們會將其折合成秒放率，就首音市場在一秒以內(nèi)的概率。
 
此外，杜思奇說，蜻蜓上個月與8家國內(nèi)的CDN廠商合作進(jìn)行了集中評估。這次評估主要是劃了一定比例的真實(shí)用戶，測試在真實(shí)場景下產(chǎn)生真實(shí)的日志。通過事后分析，蜻蜓發(fā)現(xiàn)打開成功率是有一定的區(qū)分度的，但大量的應(yīng)該說當(dāng)時看到最主要的打開成功率差異來自于蜻蜓客戶端的異常請求，但是有些CDN廠商它的默認(rèn)自帶了一個容錯的技能，幫蜻蜓做了一個容錯的修復(fù)，最好和最差打開成功率并沒有太大的區(qū)別。
 
杜思奇表示，在這次評估中最有區(qū)別的是秒放率，對于首音的優(yōu)化，在單次請求包括DES解析，建立連接和發(fā)送請求，收到填滿playbuffer。不僅僅是首包就能解決，這個是最簡單的單次請求的模型，每個播放器請求播放都有差異，開始播放發(fā)送不止一個請求，比如說技術(shù)人員會發(fā)現(xiàn)IOS系統(tǒng)播放器會發(fā)三個請求，當(dāng)時他們覺得挺有意思的，如果廠商在這個地方?jīng)]有針對性的優(yōu)化很可能會出現(xiàn)一個性能重疊。
 
最后，杜思奇表示，除了CDN內(nèi)部優(yōu)化外，他們在CDN外部也會有一些優(yōu)化。比如說客戶端會在網(wǎng)絡(luò)改變之后測速，測的是用戶端到邊緣節(jié)點(diǎn)的訪問速度，如果CDN節(jié)點(diǎn)分布比較少，或者CDN節(jié)點(diǎn)健康狀態(tài)比較差這個節(jié)點(diǎn)就會被發(fā)現(xiàn)，他們會為每一個音頻算一個入口，同一個音頻走同一個入口出去的話能工增加緩存利用率，減少回源。