Sebelumnya, menganalisis kemungkinan konfigurasi server standar di Digital Ocean dari sudut pandang streaming WebRTC, kami mencatat bahwa satu server dapat melayani hingga 2.000 penonton. Dalam kehidupan nyata, sering ada kasus ketika satu server tidak cukup.
Katakanlah penggemar kegembiraan di Jerman menonton balap kuda waktu nyata di Australia. Karena balap kuda tidak hanya olahraga berkuda, tetapi juga kemenangan besar, dengan taruhan dilakukan tepat waktu, video harus dikirim dengan penundaan sesedikit mungkin.
Contoh lain. Sebuah perusahaan global, salah satu pemimpin di pasar FCMG dengan anak perusahaan di Eropa, Rusia dan Asia Tenggara, menyelenggarakan webinar untuk melatih manajer penjualan dengan terjemahan dari kantor pusat di Mediterania. Pemirsa harus melihat dan mendengar presenter secara langsung.
Contoh-contoh ini menggabungkan persyaratan: mengirimkan aliran media ke sejumlah besar pemirsa dengan latensi rendah. Untuk melakukan ini, Anda perlu menggunakan jaringan pengiriman konten - CDN.
Perhatikan bahwa teknologi klasik pengiriman aliran menggunakan HLS tidak cocok, karena dapat memberikan penundaan hingga 30 detik, dan ini sangat penting untuk pertunjukan waktu nyata. Bayangkan bahwa kuda sudah mencapai garis finish, hasilnya diterbitkan di situs, dan para penggemar masih memeriksa balapan. Kekurangan ini dirampas dari teknologi WebRTC, yang dapat memberikan penundaan dalam 1 detik, dengan saluran komunikasi modern ini mungkin terjadi bahkan antar benua.
Pertama, mari kita lihat bagaimana menggunakan CDN yang paling sederhana untuk mengirimkan aliran WebRTC, dan kemudian skala itu.
Struktur CDN
Server dalam CDN dapat melakukan salah satu dari peran berikut:
- Origin adalah server untuk menerbitkan stream media. Mendistribusikan stream ke server lain, juga dapat mendistribusikan ke pelanggan.
- Transcoder - server yang didedikasikan untuk transcoding stream. Mengambil aliran dari server Asal dan mendistribusikan aliran yang ditranskode ke Edge. Kami akan berurusan dengan peran ini di bagian selanjutnya.
- Edge - server yang dirancang untuk mendistribusikan streaming ke pelanggan. Dibutuhkan stream dari server Origin atau Transcoder, tidak mendistribusikan stream ke server CDN lainnya.
Anda bisa menerbitkan aliran WebRTC dan RTMP ke server Asal, atau menangkap aliran dari sumber lain melalui RTMP, RTSP dan metode lain yang mungkin.
Pelanggan dapat memutar stream dari server Edge melalui WebRTC, RTMP, RTSP, HLS
Antara server CDN, diinginkan untuk streaming melalui WebRTC untuk mengurangi latensi.
CDN statis sepenuhnya dijelaskan pada tahap konfigurasi. Faktanya, pengaturan CDN statis mirip dengan pengaturan penyeimbang beban: semua penerima tercantum dalam pengaturan server sumber arus.
Misalnya, kami memiliki server Origin di Frankfurt, satu Edge di New York dan satu di Singapura
Dalam hal ini, Origin mengonfigurasi sesuatu seperti ini:
<loadbalancer mode="roundrobin" stream_distribution="webrtc"> <node id="1"> <ip>edge1.thestaticcdn.com</ip> <wss>443</wss> </node> <node id="2"> <ip>edge2.thestaticcdn.com</ip> <wss>443</wss> </node> </loadbalancer>
Inilah masalah pertama dengan CDN statis: untuk menambahkan Edge server baru ke CDN tersebut, atau untuk menghapus server dari CDN, Anda perlu mengubah pengaturan dan memulai kembali semua server Origin.
Streaming yang diterbitkan pada Asal disiarkan ke semua server yang tercantum dalam pengaturan Edge. Keputusan tentang server Edge mana yang akan dihubungkan oleh pelanggan juga dibuat pada server Origin. Ini adalah masalah kedua: jika tidak ada penonton atau sangat sedikit, misalnya, di Singapura pada sore hari, dan di New York di tengah malam, aliran sungai masih disiarkan ke Edge 1. Lalu lintas dihabiskan diam-diam, dan sama sekali tidak gratis.
CDN dinamis dapat menyelesaikan dua masalah ini.
Jadi, kami ingin mengonfigurasi CDN tanpa memulai ulang semua server Origin, dan kami tidak ingin melakukan streaming ke server Edge tersebut di mana tidak ada pelanggan. Dalam hal ini, Anda tidak perlu menyimpan seluruh daftar server CDN di suatu tempat di pengaturan. Setiap server itu sendiri harus membuat daftar seperti itu, dan untuk ini, ia harus mengetahui status server lain saat ini pada waktu tertentu.
Idealnya, dalam pengaturan itu harus cukup untuk menentukan titik masuk, server dari mana CDN dimulai. Pada titik entri ini, setiap server pada saat permulaan harus mengirim permintaan dan menerima daftar node CDN dan daftar aliran yang diterbitkan sebagai tanggapan. Jika titik masuk tidak tersedia, server harus mengharapkan pesan dari server lain.
Server harus mengirim perubahan apa pun ke statusnya ke server lain di CDN.
CDN paling sederhana: di pusat Eropa
Jadi, mari kita coba mengkonfigurasi dan menjalankan CDN dinamis. Misalkan, sebagai permulaan, kita perlu mendistribusikan streaming video ke pemirsa Eropa, sementara hingga 5.000 pengguna harus didukung. Misalkan sumber arus juga di Eropa.
Kami menyebarkan tiga server di pusat data Eropa. Kami akan menggunakan Flashphoner WebCallServer (server video streaming WebRTC) sebagai elemen untuk membangun CDN.
Pengaturan:
cdn_enabled=true cdn_ip=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
Perpesanan antara node CDN dinamis terjadi melalui Websocket, dan, tentu saja, Secure Websocket juga didukung.
Di dalam CDN, stream disiarkan melalui WebRTC. Sebagai aturan, UDP digunakan sebagai transportasi, tetapi Anda dapat beralih ke TCP jika Anda perlu memastikan kualitas siaran dengan saluran yang tidak terlalu baik antar server. Sayangnya, dalam hal ini penundaan meningkat.
Kami me-restart server, membuka contoh Two Way Streaming pada o-eu1 , menerbitkan video siklik dengan penghitung waktu mundur dari 10 menit hingga 0
Buka contoh Player di e-eu1 , mainkan stream
Dan lakukan hal yang sama pada e-eu2
CDN berhasil! Seperti yang dapat Anda lihat di tangkapan layar, waktu dalam video bertepatan di sisi penerbitan dan di pemirsa hingga satu detik, terima kasih WebRTC dan saluran yang baik.
Lebih jauh di mana-mana: menghubungkan Amerika
Sekarang kami akan mengirimkan streaming kepada pemirsa di benua Amerika, dan kami tidak akan melupakan publikasi.
Tanpa menonaktifkan bagian Eropa dari CDN, kami menyebarkan tiga server di pusat data Amerika
Pengaturan:
cdn_enabled=true cdn_ip=o-us1.flashponer.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=origin
cdn_enabled=true cdn_ip=e-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
cdn_enabled=true cdn_ip=e-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=edge
Kami me-restart server Amerika, kami memeriksa publikasi
dan reproduksi
Pada saat yang sama, segmen Eropa terus bekerja. Periksa untuk melihat apakah pelanggan Amerika akan melihat aliran yang diterbitkan dari Eropa. Kami menerbitkan aliran test_eu di o-eu1
dan mainkan di e-us1
Dan itu juga berhasil! Adapun keterlambatan, dalam screenshot kami lagi mengamati kebetulan waktu dalam video di sisi penerbitan dan di pemirsa hingga satu detik.
Harap perhatikan bahwa stream yang diterbitkan pada server Origin lain tidak dapat diputar langsung dari server Origin secara default, tetapi jika Anda membutuhkannya, Anda dapat mengonfigurasinya seperti ini
cdn_origin_to_origin_route_propagation=true
Untuk dilanjutkan
Jadi, kami menggunakan CDN sederhana dan kemudian berhasil menskalakannya ke dua benua, menerbitkan dan memainkan aliran WebRTC latensi rendah. Pada saat yang sama, kami tidak mengubah parameter streaming selama pemutaran, yang dalam kehidupan nyata sangat diperlukan: semua pemirsa memiliki saluran yang berbeda, dan untuk menjaga kualitas siaran, perlu, misalnya, untuk menurunkan resolusi atau bitrate. Ini akan kita lakukan di bagian selanjutnya ...
Referensi
CDN streaming WebRTC latensi rendah adalah jaringan pengiriman konten berbasis Web Call Server.