TCP vs UDP pada aliran video

Saya baru saja pulang dari ujian saya dalam pemrograman jaringan, dan salah satu pertanyaan yang mereka ajukan kepada kami adalah "Jika Anda akan melakukan streaming video, apakah Anda akan menggunakan TCP atau UDP? Berikan penjelasan untuk video yang disimpan dan streaming video langsung" . Untuk pertanyaan ini mereka hanya mengharapkan jawaban singkat dari TCP untuk video yang disimpan dan UDP untuk video langsung, tetapi saya memikirkannya dalam perjalanan pulang, dan apakah lebih baik menggunakan UDP untuk streaming video langsung? Maksud saya, jika Anda memiliki bandwidth untuk itu, dan mengatakan Anda streaming pertandingan sepak bola, atau konser dalam hal ini, apakah Anda benar-benar perlu menggunakan UDP?

Katakanlah bahwa saat Anda streaming konser ini atau apa pun yang menggunakan TCP, Anda mulai kehilangan paket (sesuatu yang buruk terjadi di beberapa jaringan antara Anda dan pengirim), dan selama satu menit penuh Anda tidak mendapatkan paket apa pun. Aliran video akan berhenti, dan setelah satu menit berlalu, paket mulai melewati lagi (IP menemukan rute baru untuk Anda). Apa yang kemudian akan terjadi adalah bahwa TCP akan mengirimkan ulang begitu Anda hilang dan terus mengirimkan streaming langsung kepada Anda. Sebagai asumsi, bandwidth lebih tinggi daripada bit-rate pada streaming, dan ping tidak terlalu tinggi, jadi dalam waktu singkat, satu menit Anda kehilangan akan bertindak sebagai buffer untuk streaming Anda, dengan begitu , jika kehilangan paket terjadi lagi, Anda tidak akan menyadarinya.

Sekarang, saya dapat memikirkan beberapa peralatan di mana ini bukan ide yang baik, seperti misalnya konferensi video, di mana Anda harus selalu berada di akhir streaming, karena penundaan selama obrolan video hanya mengerikan, tetapi selama pertandingan sepak bola, atau konser, apa bedanya jika Anda hanya satu menit di belakang streaming? Plus, Anda dijamin mendapatkan semua data dan akan lebih baik menyimpannya untuk dilihat nanti saat data masuk tanpa kesalahan.

Jadi ini membawa saya ke pertanyaan saya. Apakah ada kekurangan yang tidak saya ketahui tentang penggunaan TCP untuk streaming langsung? Atau haruskah benar, bahwa jika Anda memiliki bandwidth untuk itu, Anda harus menggunakan TCP karena "lebih baik" ke jaringan (kontrol aliran)?

Kelemahan menggunakan TCP untuk video langsung:

1. Biasanya peralatan streaming video langsung tidak dirancang dengan mempertimbangkan streaming TCP. Jika Anda menggunakan TCP, OS harus menyangga segmen yang tidak diakui untuk setiap klien. Ini tidak diinginkan, terutama dalam kasus acara langsung; mungkin daftar klien simultan Anda panjang karena singularitas acara. Para pemeran video prarekam biasanya tidak terlalu bermasalah dengan hal ini karena pemirsa mengatur ulang aktivitas pemutaran ulang mereka; oleh karena itu TCP lebih sesuai untuk memutar ulang video-on-demand.
2. Multicast IP secara signifikan mengurangi kebutuhan bandwidth video untuk audiens besar; TCP mencegah penggunaan multicast IP, tetapi UDP sangat sesuai untuk multicast IP.
3. Video langsung biasanya merupakan aliran bandwidth konstan yang direkam dari kamera; aliran video pra-rekam keluar dari disk. Dinamika loss-backoff TCP mempersulit penayangan video langsung ketika sumber streaming berada pada bandwidth yang konstan (seperti yang akan terjadi untuk siaran langsung). Jika Anda melakukan buffer ke disk dari kamera, pastikan Anda memiliki cukup buffer untuk kejadian jaringan yang tidak dapat diprediksi dan kecepatan pengiriman / mundur TCP variabel. UDP memberi Anda lebih banyak kontrol untuk aplikasi ini karena UDP tidak peduli dengan penurunan lapisan transport jaringan.

FYI, jangan gunakan kata "paket" saat menjelaskan jaringan. Jaringan mengirim "paket".

tetapi selama pertandingan sepak bola, atau konser, apa bedanya jika Anda hanya satu menit di belakang streaming?

Bagi beberapa penggemar sepak bola, cukup. Telah dikatakan bahwa penundaan bahkan beberapa detik yang ada dalam streaming video digital karena encoding (atau apa pun) dapat sangat mengganggu ketika, selama acara-acara penting seperti pertandingan piala dunia, Anda dapat mendengar sorak-sorai dan erangan dari para pria. sebelah (yang sedang menonton program analog yang tidak diinginkan) sebelum Anda bisa melihat gerakan permainan yang menyebabkannya.

Saya pikir bagi seseorang yang sangat peduli tentang olahraga (dan mereka adalah kelompok pelanggan terbesar yang membayar untuk TV digital, setidaknya di sini di Jerman), ketinggalan satu menit dalam streaming video langsung sama sekali tidak dapat diterima (Seperti, mereka ' d beralih ke pesaing Anda di mana ini tidak terjadi).

Biasanya aliran video agak toleran terhadap kesalahan. Jadi, jika beberapa paket hilang (karena beberapa router di sepanjang jalan kelebihan beban, misalnya), maka masih dapat menampilkan konten, tetapi dengan kualitas yang berkurang.

Jika live streaming Anda menggunakan TCP / IP, maka itu akan dipaksa untuk menunggu paket yang dibatalkan sebelumnya dapat melanjutkan pemrosesan data yang lebih baru.

Itu sangat buruk:

• data lama akan dikirim ulang (itu mungkin untuk bingkai yang sudah ditampilkan dan karena itu tidak berharga) dan
• data baru tidak bisa tiba sampai setelah data lama itu kembali ditransmisikan

Jika tujuan Anda adalah untuk menampilkan informasi yang paling mutakhir (dan untuk live-stream Anda biasanya ingin selalu up-to-date, meskipun bingkai Anda terlihat sedikit lebih buruk), TCP akan bekerja melawan Anda.

Untuk aliran yang direkam situasinya sedikit berbeda: Anda mungkin akan melakukan buffering lebih banyak (mungkin beberapa menit!) Dan lebih suka data dikirim ulang daripada memiliki beberapa artefak karena paket yang hilang. Dalam hal ini TCP adalah pasangan yang cocok (ini masih dapat diterapkan di UDP, tentu saja, tetapi TCP tidak memiliki banyak kekurangan seperti untuk kasus streaming langsung).

Ada beberapa kasus penggunaan yang cocok untuk transport UDP dan yang lainnya cocok untuk transport TCP.

Kasus penggunaan juga menentukan pengaturan pengkodean untuk video. Saat menyiarkan pertandingan sepak bola, fokus pada kualitas dan untuk konferensi video fokus pada latensi.

Saat menggunakan multicast untuk mengirimkan video ke pelanggan Anda, maka UDP digunakan.

Persyaratan untuk multicast adalah perangkat keras jaringan yang mahal antara server penyiaran dan pelanggan. Dalam praktiknya, ini berarti jika perusahaan Anda memiliki infrastruktur jaringan, Anda dapat menggunakan UDP dan multicast untuk streaming video langsung. Bahkan kemudian quality-of-service juga diterapkan untuk menandai paket video dan memprioritaskannya sehingga tidak terjadi packet loss.

Multicast akan menyederhanakan perangkat lunak penyiaran karena perangkat keras jaringan akan menangani pendistribusian paket ke pelanggan. Pelanggan berlangganan saluran multicast dan jaringan akan mengkonfigurasi ulang untuk merutekan paket ke pelanggan baru. Secara default semua saluran tersedia untuk semua pelanggan dan dapat dirutekan secara optimal.

Alur kerja ini menimbulkan kesulitan pada proses otorisasi. Perangkat keras jaringan tidak membedakan pengguna yang berlangganan dari pengguna lain. Solusi untuk otorisasi adalah dengan mengenkripsi konten video dan mengaktifkan dekripsi di perangkat lunak pemutar jika langganan valid.

Alur kerja Unicast (TCP) memungkinkan server untuk memeriksa kredensial klien dan hanya mengizinkan langganan yang valid. Bahkan mengizinkan hanya sejumlah koneksi simultan.

Multicast tidak diaktifkan melalui internet.

Untuk mengirimkan video melalui internet, TCP harus digunakan. Ketika UDP digunakan, pengembang akhirnya mengimplementasikan ulang transmisi paket, misalnya. Protokol langsung p2p Bittorrent.

"Jika Anda menggunakan TCP, OS harus menyangga segmen yang tidak diakui untuk setiap klien. Ini tidak diinginkan, terutama dalam kasus acara langsung".

Buffer ini harus ada dalam beberapa bentuk. Hal yang sama berlaku untuk buffer jitter di sisi pemain. Ini disebut "buffer soket" dan perangkat lunak server dapat mengetahui saat buffer ini penuh dan membuang bingkai video yang sesuai untuk streaming langsung. Lebih baik menggunakan metode unicast / TCP karena perangkat lunak server dapat menerapkan logika penurunan bingkai yang tepat. Paket acak yang hilang dalam kasus UDP hanya akan menciptakan pengalaman pengguna yang buruk. seperti di video ini: http://tinypic.com/r/2qn89xz/9

"IP multicast secara signifikan mengurangi persyaratan bandwidth video untuk audiens besar"

Ini berlaku untuk jaringan pribadi, Multicast tidak diaktifkan melalui internet.

"Perhatikan bahwa jika TCP kehilangan terlalu banyak paket, koneksi akan mati; dengan demikian, UDP memberi Anda lebih banyak kontrol untuk aplikasi ini karena UDP tidak peduli dengan penurunan lapisan transport jaringan."

UDP juga tidak peduli dengan menjatuhkan seluruh frame atau group-of-frame sehingga tidak memberikan kendali lebih atas pengalaman pengguna.

"Biasanya aliran video agak toleran terhadap kesalahan"

Video yang dikodekan tidak toleran terhadap kesalahan. Ketika dikirim melalui transportasi yang tidak dapat diandalkan maka koreksi kesalahan maju ditambahkan ke wadah video. Contoh yang baik adalah wadah MPEG-TS yang digunakan dalam siaran video satelit yang membawa beberapa aliran audio, video, EPG, dll. Ini diperlukan karena tautan satelit bukanlah komunikasi dupleks, yang berarti penerima tidak dapat meminta transmisi ulang paket yang hilang.

Ketika Anda memiliki komunikasi dupleks yang tersedia, selalu lebih baik untuk mengirim ulang data hanya ke klien yang mengalami kehilangan paket, kemudian memasukkan overhead koreksi kesalahan-penerusan dalam aliran yang dikirim ke semua klien.

Bagaimanapun, paket yang hilang tidak dapat diterima. Frame yang dilepas tidak masalah dalam kasus luar biasa saat bandwidth terhalang.

Hasil dari paket yang hilang adalah artefak seperti ini:

Beberapa decoder dapat merusak aliran paket yang hilang di tempat-tempat kritis.

Saya sarankan Anda untuk melihat protokol live p2p baru Bittorent Live .

Untuk streaming, lebih baik menggunakan UDP, pertama karena menurunkan beban pada server, tetapi sebagian besar karena Anda dapat mengirim paket dengan multicast, ini lebih sederhana daripada mengirimnya ke setiap klien yang terhubung.

Tergantung. Seberapa kritis konten yang Anda streaming? Jika kritis gunakan TCP. Ini dapat menyebabkan masalah dalam bandwidth, kualitas video (Anda mungkin harus menggunakan kualitas yang lebih rendah untuk menangani latensi), dan latensi. Tetapi jika Anda membutuhkan konten untuk dijamin sampai di sana, gunakanlah.

Jika tidak, UDP akan baik-baik saja jika aliran tidak kritis dan lebih disukai karena UDP cenderung memiliki overhead yang lebih sedikit.

Salah satu masalah terbesar dalam menayangkan siaran langsung di Internet adalah 'skala', dan TCP tidak berskala dengan baik. Misalnya, saat Anda menyiarkan langsung pertandingan sepak bola - berlawanan dengan pemutaran film sesuai permintaan - jumlah orang yang menonton dapat dengan mudah mencapai 1000 kali lebih banyak. Dalam skenario seperti itu menggunakan TCP adalah hukuman mati untuk CDN (jaringan pengiriman konten).

Ada beberapa alasan utama mengapa TCP tidak berskala dengan baik:

1. Salah satu tradeoff terbesar dari TCP adalah variabilitas throughput yang dapat dicapai antara pengirim dan penerima. Saat streaming video melalui Internet, paket video harus melintasi beberapa router melalui Internet, masing-masing router ini terhubung dengan koneksi kecepatan yang berbeda. Algoritma TCP dimulai dengan jendela TCP off kecil, kemudian tumbuh sampai packet loss terdeteksi, packet loss dianggap sebagai tanda kemacetan dan TCP menanggapinya dengan secara drastis mengurangi ukuran jendela untuk menghindari kemacetan. Dengan demikian pada gilirannya mengurangi throughput efektif dengan segera. Sekarang bayangkan jaringan dengan transmisi TCP menggunakan 6-7 router hop ke klien (skenario yang sangat normal), jika salah satu router perantara kehilangan paket apa pun, TCP untuk link tersebut akan mengurangi kecepatan transmisi. Nyatanya, arus lalu lintas antar router mengikuti bentuk jam pasir; selalu naik dan turun di antara salah satu router perantara. Merender efektif melalui menempatkan jauh lebih rendah dibandingkan dengan upaya terbaik UDP.

2. Seperti yang mungkin sudah Anda ketahui, TCP adalah protokol berbasis pengakuan. Katakanlah misalnya pengirim berjarak 50 ms (yaitu latensi dengan dua poin). Ini berarti waktu yang dibutuhkan paket untuk dikirim ke penerima dan penerima untuk mengirim pengakuan adalah 100ms; sehingga throughput maksimum yang mungkin dibandingkan dengan transmisi berbasis UDP sudah setengahnya.

3. TCP tidak mendukung multicasting atau standar baru multicasting AMT. Artinya, CDN tidak memiliki kesempatan untuk mengurangi lalu lintas jaringan dengan mereplikasi paket-ketika banyak klien menonton konten yang sama. Itu sendiri adalah alasan yang cukup besar bagi CDN (seperti Akamai atau Level3) untuk tidak menggunakan TCP untuk streaming langsung.

Saat membaca debat TCP UDP, saya melihat kesalahan logis. Kehilangan paket TCP yang menyebabkan penundaan satu menit yang diubah menjadi buffer satu menit tidak dapat dikaitkan dengan penurunan UDP satu menit penuh sementara mengalami kerugian yang sama. Perbandingan yang lebih adil adalah sebagai berikut.

TCP mengalami kehilangan paket. Video dihentikan saat TCP mengirim ulang paket dalam upaya untuk mengalirkan paket yang sempurna secara matematis. Video tertunda selama satu menit dan melanjutkannya setelah paket yang hilang mencapai tujuannya. Kita semua menunggu tapi kita tahu kita tidak akan melewatkan satu piksel pun.

UDP mengalami kehilangan paket. Untuk sedetik selama streaming video, sudut layar menjadi sedikit buram. Tidak ada yang memperhatikan dan pertunjukan berlanjut tanpa mencari paket yang hilang.

Apa pun yang mengalir mendapatkan manfaat paling banyak dari UDP. Kehilangan paket yang menyebabkan keterlambatan satu menit ke TCP tidak akan menyebabkan keterlambatan satu menit ke UDP. Mempertimbangkan bahwa sebagian besar sistem menggunakan beberapa aliran resolusi yang membuat segala sesuatunya menjadi blok saat kelaparan untuk paket, lebih masuk akal untuk menggunakan UDP.

UDP FTW saat streaming.

Jika bandwidth jauh lebih tinggi daripada bitrate, saya akan merekomendasikan TCP untuk streaming video langsung unicast.

Kasus 1: Paket berurutan hilang selama beberapa detik. => video langsung akan berhenti di sisi klien apa pun lapisan transportnya (TCP atau UDP). Saat jaringan pulih: - jika TCP digunakan, pemutar video klien dapat memilih untuk memulai kembali streaming pada paket pertama yang hilang (timeshift) ATAU untuk menghapus semua paket yang terlambat dan untuk memulai kembali streaming video tanpa timeshift. - jika UDP digunakan, tidak ada pilihan di sisi klien, video restart langsung tanpa timeshift. => TCP sama atau lebih baik.

Kasus 2: Beberapa paket secara acak dan sering hilang di jaringan. - jika TCP digunakan, paket-paket ini akan segera dikirim ulang dan dengan buffer jitter yang benar, tidak akan berdampak pada kualitas / latensi streaming video. - jika UDP digunakan, kualitas video akan buruk. => TCP jauh lebih baik

Untuk video streaming bandwidth kemungkinan besar menjadi kendala pada sistem. Menggunakan multicast, Anda dapat sangat mengurangi jumlah bandwidth upstream yang digunakan. Dengan UDP Anda dapat dengan mudah melakukan multicast paket Anda ke semua terminal yang terhubung. Anda juga bisa menggunakan protokol multicast yang andal, salah satunya disebut Pragmatic General Multicast (PGM), saya tidak tahu apa-apa tentang itu dan saya kira itu tidak tersebar luas dalam penggunaannya.

Selain semua alasan lainnya, UDP dapat menggunakan multicast. Mendukung 1000 pengguna TCP, semua transmisi data yang sama akan menghabiskan bandwidth. Namun, ada alasan penting lainnya untuk menggunakan TCP.

TCP dapat dengan lebih mudah melewati firewall dan NAT. Tergantung pada NAT dan operator Anda, Anda bahkan mungkin tidak dapat menerima aliran UDP karena masalah dengan pembuatan lubang UDP.

Semua jawaban 'gunakan UDP' mengasumsikan jaringan terbuka dan pendekatan 'isilah sebanyak yang Anda bisa'. Baik untuk jaringan audio / video khusus taman tertutup bergaya lama, yang agak menghilang.

Di dunia nyata, transmisi Anda akan melalui firewall (yang akan menjatuhkan multicast dan terkadang udp), jaringan dibagikan dengan aplikasi lain yang lebih penting ($$$), jadi Anda ingin menghukum pelaku penyalahgunaan dengan penskalaan jendela.

Ini masalahnya, ini lebih merupakan masalah konten daripada masalah waktu. Protokol TCP mengharuskan paket yang tidak terkirim harus diperiksa, diverifikasi, dan dikirim ulang. UDP tidak menggunakan persyaratan ini. Jadi jika Anda mengirim file yang berisi jutaan paket menggunakan UDP, seperti video, jika beberapa paket hilang saat pengiriman, kemungkinan besar paket tersebut akan dihapus.