Video akışında TCP ve UDP

Ağ programlama sınavımdan yeni geldim ve bize sordukları sorulardan biri şuydu: "Video akışı yapacaksanız, TCP veya UDP kullanır mısınız? Hem depolanan video hem de canlı video akışları için bir açıklama yapın" . Bu soruya sadece depolanan video için TCP ve canlı video için UDP'nin kısa bir cevabını beklediler, ancak bunu eve giderken düşündüm ve canlı video akışı için UDP kullanmak ille de daha mı iyi? Demek istediğim, bunun için bant genişliğine sahipseniz ve bir futbol maçı veya bu konuda konser yayınladığınızı söylerseniz, gerçekten UDP kullanmanız gerekir mi?

Diyelim ki, bu konseri yayınlarken veya TCP'yi kullanarak her neyse paketleri kaybetmeye başlıyorsunuz (sizinle gönderen arasındaki bazı ağlarda kötü bir şey oldu) ve bir dakika boyunca hiçbir paket alamıyorsunuz. Video akışı duracak ve dakika geçtikten sonra paketler tekrar geçmeye başlayacak (IP sizin için yeni bir yol buldu). O zaman olan şey, TCP'nin kaybettiğiniz dakika içinde yeniden iletmesi ve size canlı akışı göndermeye devam etmesidir. Bir varsayım olarak, bant genişliği akıştaki bit hızından daha yüksektir ve ping çok yüksek değildir, bu nedenle kısa bir süre içinde, kaybettiğiniz bir dakika sizin için akış için bir arabellek görevi görecektir. , paket kaybı tekrar olursa fark etmezsiniz.

Şimdi, bunun iyi bir fikir olmayacağı bazı cihazları düşünebilirim, örneğin video konferanslar gibi, her zaman akışın sonunda olmanız gereken , çünkü bir görüntülü sohbet sırasındaki gecikme korkunç ama Bir futbol maçı veya bir konser sırasında akışın bir dakika gerisinde olmanın ne önemi var? Ayrıca, tüm verileri alacağınız garantilidir ve daha sonra herhangi bir hata olmadan geldiğinde daha sonra görüntülemek için kaydetmek daha iyi olacaktır.

Yani bu beni soruma getiriyor. Canlı akış için TCP kullanmanın bilmediğim sakıncaları var mı? Ya da gerçekten, eğer bant genişliğine sahipseniz, ağ için "daha hoş" olduğu için (akış kontrolü) TCP'ye gitmeniz gerekir mi?

Canlı video için TCP kullanmanın sakıncaları:

1. Tipik olarak canlı video akış araçları, TCP akışı göz önünde bulundurularak tasarlanmamıştır. TCP kullanıyorsanız, işletim sistemi her istemci için onaylanmamış kesimleri arabelleğe almalıdır. Bu, özellikle canlı etkinlikler durumunda istenmeyen bir durumdur; Muhtemelen eşzamanlı müşteri listeniz, olayın tekilliğinden dolayı uzundur. Önceden kaydedilmiş video yayınlarında genellikle bununla ilgili bir sorun yoktur çünkü izleyiciler yeniden oynatma etkinliklerini kademelendirirler; bu nedenle TCP, istek üzerine videoyu yeniden oynatmak için daha uygundur.
2. IP çok noktaya yayın, büyük izleyiciler için video bant genişliği gereksinimlerini önemli ölçüde azaltır; TCP, IP multicast kullanımını engeller ancak UDP, IP multicast için çok uygundur.
3. Canlı video, normalde bir kameradan kaydedilen sabit bant genişliğine sahip bir akışdır; önceden kaydedilmiş video akışları diskten çıkar. TCP'nin kayıp-geri çekilme dinamikleri, kaynak akışları sabit bir bant genişliğindeyken (bir canlı olayda olduğu gibi) canlı video sunmayı zorlaştırır. Bir kameradan diski arabelleğe alırsanız, öngörülemeyen ağ olayları ve değişken TCP gönderme / geri alma hızları için yeterli arabelleğiniz olduğundan emin olun. UDP, ağ taşıma katmanı düşüşlerini umursamadığından, UDP bu uygulama için size çok daha fazla kontrol sağlar.

Bilginize, ağları tanımlarken lütfen "paketler" kelimesini kullanmayın. Ağlar "paketler" gönderir.

ama bir futbol maçı veya bir konser sırasında akışın bir dakika gerisinde olmanın ne önemi var?

Bazı futbol taraftarlarına oldukça fazla. Dijital video akışlarında kodlama (veya her neyse) nedeniyle birkaç saniyelik gecikmelerin, dünya kupası maçları gibi yüksek profilli etkinlikler sırasında, erkeklerin tezahüratlarını ve inlemelerini duyduğunuzda çok can sıkıcı olabileceği belirtildi. Onlara neden olan oyun hamlelerini görmeden önce yandaki kapı (beklenmedik bir analog programı izleyen)

Sporla çok ilgilenen biri için (ve bunlar dijital TV için ödeme yapan en büyük grup, en azından burada Almanya'da), canlı bir video akışında bir dakika geride olmanın tamamen kabul edilemez olacağını düşünüyorum. d bunun olmadığı yerde rakibinize geçin).

Genellikle bir video akışı biraz hataya dayanıklıdır. Bu nedenle, bazı paketler kaybolursa (örneğin, yol boyunca bazı yönlendiricilerin aşırı yüklenmesi nedeniyle), içeriği yine de düşük kalitede görüntüleyebilecektir.

Canlı yayınınız TCP / IP kullanıyorsa, daha yeni verileri işlemeye devam etmeden önce bırakılan paketleri beklemek zorunda kalır .

Bu iki kat kötü:

• Eski veri yeniden iletilen olmak (zaten bu yüzden değersiz gösterilir ve bir çerçeve için muhtemelen) ve
• Yeni veri kadar gelmesi edemez sonra eski veri yeniden iletilmiştir

Amacınız olabildiğince güncel bilgileri görüntülemekse (ve bir canlı yayın için, çerçeveleriniz biraz daha kötü görünse bile genellikle güncel olmak istiyorsanız), o zaman TCP size karşı çalışacaktır.

Kaydedilen bir akış için durum biraz farklıdır: muhtemelen çok daha fazla arabelleğe alacaksınız (muhtemelen birkaç dakika!) Ve kayıp paketler nedeniyle bazı yapaylıklar yerine verilerin yeniden iletilmesini tercih edeceksiniz. Bu durumda TCP iyi bir eşleşmedir (elbette bu UDP'de uygulanabilir, ancak TCP'nin canlı akış durumunda olduğu kadar dezavantajı yoktur).

UDP aktarımına uygun ve diğerleri TCP aktarımına uygun bazı kullanım durumları vardır.

Kullanım durumu, video için kodlama ayarlarını da belirler. Futbol maçı yayınlarken odak kalitedir ve video konferans için odak noktası gecikmedir.

Müşterilerinize video sunmak için çok noktaya yayın kullanırken UDP kullanılır.

Çok noktaya yayın gereksinimi, yayın sunucusu ile müşteri arasında pahalı bir ağ donanımıdır. Pratikte bu, şirketinizin ağ altyapısına sahip olması durumunda, canlı video akışı için UDP ve çok noktaya yayını kullanabileceğiniz anlamına gelir. Bu durumda bile, video paketlerini işaretlemek ve öncelik sırasına koymak için hizmet kalitesi de uygulanır, böylece paket kaybı olmaz.

Çoklu yayın, yayın yazılımını basitleştirecektir çünkü ağ donanımı, paketleri müşterilere dağıtmayı idare edecektir. Müşteriler çok noktaya yayın kanallarına abone olur ve ağ, paketleri yeni aboneye yönlendirmek için yeniden yapılandırılır. Varsayılan olarak tüm kanallar tüm müşteriler tarafından kullanılabilir ve en uygun şekilde yönlendirilebilir.

Bu iş akışı, yetkilendirme sürecini zorlaştırır. Ağ donanımı, abone olan kullanıcıları diğer kullanıcılardan ayırmaz. Yetkilendirmeye yönelik çözüm, video içeriğini şifrelemek ve abonelik geçerli olduğunda oynatıcı yazılımında şifre çözmeyi sağlamaktır.

Tek noktaya yayın (TCP) iş akışı, sunucunun istemcinin kimlik bilgilerini kontrol etmesine ve yalnızca geçerli aboneliklere izin vermesine olanak tanır. Hatta yalnızca belirli sayıda eşzamanlı bağlantıya izin verin.

Çoklu yayın internet üzerinden etkinleştirilmemiştir.

İnternet üzerinden video iletimi için TCP kullanılmalıdır. UDP kullanıldığında, geliştiriciler paketin yeniden iletimini yeniden uygular, örneğin. Bittorrent p2p canlı protokolü.

"TCP kullanıyorsanız, işletim sistemi her istemci için onaylanmamış segmentleri arabelleğe almalıdır. Bu, özellikle canlı olaylarda istenmeyen bir durumdur".

Bu tampon bir şekilde mevcut olmalıdır. Aynı durum oyuncu tarafındaki jitter tamponu için de geçerlidir. Buna "soket arabelleği" denir ve sunucu yazılımı, bu arabelleğin ne zaman dolduğunu bilebilir ve canlı akışlar için uygun video karelerini atabilir. Tek noktaya yayın / TCP yöntemini kullanmak daha iyidir çünkü sunucu yazılımı uygun çerçeve bırakma mantığını uygulayabilir. UDP durumunda rastgele eksik paketler kötü bir kullanıcı deneyimi yaratacaktır. bu videodaki gibi: http://tinypic.com/r/2qn89xz/9

"IP çok noktaya yayın, geniş kitleler için video bant genişliği gereksinimlerini önemli ölçüde azaltır"

Bu, özel ağlar için geçerlidir, Multicast internet üzerinden etkinleştirilmemiştir.

"TCP çok fazla paket kaybederse, bağlantı kesilir; bu nedenle, UDP ağ taşıma katmanının düşmesini önemsemediği için UDP size bu uygulama için çok daha fazla kontrol sağlar."

UDP ayrıca tüm çerçevelerin veya çerçeve gruplarının kaldırılmasıyla ilgilenmez, bu nedenle kullanıcı deneyimi üzerinde daha fazla kontrol sağlamaz.

"Genellikle bir video akışı biraz hataya dayanıklıdır"

Kodlanmış video hataya dayanıklı değildir . Güvenilir olmayan aktarım üzerinden iletildiğinde, video kabına iletme hatası düzeltmesi eklenir. Buna iyi bir örnek, uydu video yayınında kullanılan, çeşitli ses, video, EPG vb. Akışları taşıyan MPEG-TS kapsayıcıdır. Uydu bağlantısı çift yönlü iletişim olmadığından bu gereklidir, yani alıcı kayıp paketlerin yeniden iletilmesini talep edemez.

Mevcut çift yönlü iletişiminiz olduğunda, verileri yalnızca paket kaybı olan istemcilere yeniden iletmek, daha sonra tüm istemcilere gönderilen akışta ileri-hata düzeltme ek yükünü dahil etmek her zaman daha iyidir.

Her durumda kayıp paketler kabul edilemez. Bant genişliğinin engellendiği istisnai durumlarda atlanan çerçeveler uygundur.

Eksik paketlerin sonucu şuna benzer yapılardır:

Bazı kod çözücüler, kritik yerlerde paket eksik akışları kesebilir.

Yeni p2p canlı protokolü Bittorent Live'a bakmanızı tavsiye ederim .

Akışa gelince, UDP kullanmak daha iyidir, çünkü öncelikle sunuculardaki yükü azaltır, ancak çoğunlukla çok noktaya yayın ile paket gönderebildiğiniz için, her bağlı istemciye göndermekten daha kolaydır.

Değişir. Yayınladığınız içerik ne kadar kritik? Kritik ise TCP kullanın. Bu, bant genişliğinde, video kalitesinde (gecikmeyle başa çıkmak için daha düşük bir kalite kullanmanız gerekebilir) ve gecikmede sorunlara neden olabilir. Ancak içeriğe ulaşmanızın garantili olması gerekiyorsa kullanın.

Aksi takdirde, akış kritik değilse UDP iyi olmalıdır ve UDP daha az ek yüke sahip olma eğiliminde olduğu için tercih edilir.

İnternette canlı etkinlikler sunmanın en büyük sorunlarından biri 'ölçeklendirmedir' ve TCP iyi ölçeklenmez. Örneğin, isteğe bağlı film oynatmanın aksine, canlı bir futbol maçını ışınlarken izleyen insan sayısı kolayca 1000 kat daha fazla olabilir. Böyle bir senaryoda TCP kullanmak, CDN'ler (içerik dağıtım ağları) için bir ölüm cezasıdır.

TCP'nin iyi ölçeklenmemesinin birkaç ana nedeni vardır:

1. TCP'nin en büyük değiş tokuşlarından biri, gönderen ve alıcı arasında ulaşılabilen verim değişkenliğidir. İnternet üzerinden video akışı yapılırken, video paketlerinin İnternet üzerinden birden çok yönlendiriciden geçmesi gerekir, bu yönlendiricilerin her biri farklı hız bağlantılarıyla bağlanır. TCP algoritması, TCP penceresi küçük olarak başlar, ardından paket kaybı tespit edilene kadar büyür, paket kaybı bir tıkanıklık işareti olarak kabul edilir ve TCP, tıkanıklığı önlemek için pencere boyutunu büyük ölçüde azaltarak yanıt verir. Böylece, etkili verimi anında azaltır. Şimdi istemciye 6-7 yönlendirici atlamalarını kullanan TCP iletimi olan bir ağ hayal edin (çok normal bir senaryo), eğer ara yönlendiricilerin herhangi biri herhangi bir paketi kaybederse, bu bağlantı için TCP aktarım hızını düşürecektir. Aslında, yönlendiriciler arasındaki trafik akışı kum saatine benzer bir şekli izler; ara yönlendiricilerden biri arasında daima yukarı ve aşağı gong yapın. Etkili hale getirmek, en iyi çaba gerektiren UDP'ye kıyasla çok daha düşük.

2. Bildiğiniz gibi, TCP, onay tabanlı bir protokoldür. Örneğin, bir göndericinin 50ms uzakta olduğunu söyleyelim (yani, iki puan arasında gecikme). Bu, bir paketin bir alıcıya gönderilmesi ve alıcıya bir alındı ​​bildirimi göndermesi için geçen sürenin 100 ms olacağı anlamına gelir; bu nedenle, UDP tabanlı iletime kıyasla mümkün olan maksimum verim zaten yarıya inmiştir.

3. TCP, çok noktaya yayını veya yeni ortaya çıkan çok noktaya yayın AMT standardını desteklemez. Bu, CDN'lerin paketleri çoğaltarak ağ trafiğini azaltma fırsatına sahip olmadığı anlamına gelir - birçok istemci aynı içeriği izlerken. Bu, CDN'lerin (Akamai veya Level3 gibi) canlı yayınlar için TCP ile uyumlu olmaması için yeterince büyük bir nedendir.

TCP UDP tartışmasını okurken mantıksal bir kusur fark ettim. Bir dakikalık bir gecikmeye neden olan ve bir dakikalık bir arabelleğe dönüştürülen bir TCP paket kaybı, aynı kaybı yaşarken tam bir dakika düşen UDP ile ilişkilendirilemez. Daha adil bir karşılaştırma aşağıdaki gibidir.

TCP, bir paket kaybı yaşar. TCP'nin paketleri matematiksel olarak mükemmel paketleri yayınlama girişimiyle yeniden gönderirken video durdurulur. Video bir dakika ertelenir ve eksik paket hedefini oluşturduktan sonra kaldığı yerden devam eder. Hepimiz bekliyoruz ama tek bir pikseli bile kaçırmayacağımızı biliyoruz.

UDP bir paket kaybı yaşar. Video akışı sırasında bir saniye için ekranın bir köşesi biraz bulanıklaşıyor. Kimse fark etmiyor ve gösteri kayıp paketleri aramadan devam ediyor.

Akışı olan her şey, UDP'den en fazla faydayı sağlar. TCP'de bir dakikalık gecikmeye neden olan paket kaybı, UDP'de bir dakikalık gecikmeye neden olmaz. Çoğu sistemin, paket açlığı çekerken işleri tıkayan birden fazla çözünürlük akışı kullandığını düşünürsek, UDP kullanmak daha da mantıklıdır.

Akış sırasında UDP FTW.

Bant genişliği bit hızından çok daha yüksekse, tek noktaya yayın canlı video akışı için TCP'yi öneririm.

Durum 1: Art arda paketler birkaç saniyelik bir süre boyunca kaybolur. => canlı video, aktarım katmanı (TCP veya UDP) ne olursa olsun istemci tarafında duracaktır. Ağ kurtarıldığında: - TCP kullanılırsa, istemci video oynatıcı ilk paket kaybolduğunda akışı yeniden başlatmayı (zaman kayması) VEYA tüm geç paketleri bırakmayı ve zaman kayması olmadan video akışını yeniden başlatmayı seçebilir. - UDP kullanılıyorsa, istemci tarafında herhangi bir seçenek yoktur, video herhangi bir zaman kayması olmadan canlı olarak yeniden başlatılır. => TCP eşit veya daha iyi.

Durum 2: Bazı paketler rastgele bir şekilde ağda kaybolur. - TCP kullanılırsa, bu paketler hemen yeniden iletilir ve doğru bir jitter tamponu ile video akışı kalitesi / gecikmesi üzerinde hiçbir etkisi olmaz. - UDP kullanılıyorsa, video kalitesi düşük olacaktır. => TCP çok daha iyi

Video akışı için bant genişliği muhtemelen sistemdeki kısıtlamadır. Çoklu yayını kullanarak, kullanılan yukarı akış bant genişliği miktarını büyük ölçüde azaltabilirsiniz. UDP ile paketlerinizi bağlı tüm terminallere kolayca çoklu yayınlayabilirsiniz. Ayrıca güvenilir bir çok noktaya yayın protokolü de kullanabilirsiniz, biri Pragmatik Genel Çok Noktaya Yayın (PGM), bu konuda hiçbir şey bilmiyorum ve sanırım kullanımında yaygın değil.

Diğer tüm nedenlerin yanı sıra, UDP çok noktaya yayını kullanabilir. 1000'lerce TCP kullanıcısını desteklemek, hepsi aynı veriyi iletmek bant genişliğini boşa harcar. Ancak, TCP'yi kullanmanın bir başka önemli nedeni daha vardır.

TCP, güvenlik duvarlarından ve NAT'lardan çok daha kolay geçebilir. NAT ve operatörünüze bağlı olarak, UDP delik delme ile ilgili sorunlar nedeniyle bir UDP akışını bile alamayabilirsiniz.

Tüm 'UDP kullan' cevapları açık bir ağ varsayar ve 'yapabildiğiniz kadar doldurun' yaklaşımı. Kaybolan bir tür olan eski tarz kapalı bahçe özel ses / video ağları için idealdir.

Gerçek dünyada, iletiminiz güvenlik duvarlarından geçecek (bu çok noktaya yayını ve bazen de udp'yi düşürecektir), ağ başkaları daha önemli ($$$) uygulamalarla paylaşılır, bu nedenle kötüye kullananları pencere ölçeklendirme ile cezalandırmak istersiniz .

Mesele bu, zaman meselesinden çok bir içerik meselesi. TCP protokolü, teslim edilmeyen bir paketin kontrol edilmesini, doğrulanmasını ve yeniden teslim edilmesini gerektirir. UDP bu gereksinimi kullanmaz. Bu nedenle, bir video gibi UDP kullanarak milyonlarca paket içeren bir dosya gönderdiyseniz, paketlerden bazıları teslimat sırasında eksikse, büyük olasılıkla gözden kaçacaktır.