Трябва ли да използвам TCP или UDP? [затворено]

Приложението ми трябва да изпраща видео данни кадър по кадър от сървъра към клиента. Колебая се дали да използвам TCP или UDP.

От моя тест открих следните резултати:

TCP: Много лесен за изпълнение.

UDP: За да изпратя рамка (около 50 KB) на клиента, ако създам 1 UDP пакет за всеки кадър, тогава изпращането винаги губи кадри. Така че трябва да разделя всеки кадър на много UDP пакети. Това прави моя алгоритъм много по-сложен, тъй като UDP протоколът може да загуби пакети и пакетите могат да бъдат доставени неправилно. Освен това, ако дължината на данните във всеки UDP пакет е голяма, те лесно се губят.

Аз имам някои въпроси:

  1. Трябва ли да използвам TCP или UDP за този тип приложение.

  2. Ако искам да използвам UDP за по-бързо предаване, как да определя подходящата дължина на данните във всеки пакет, която няма да се загуби лесно по време на предаване? (това може би принадлежи на честотната лента на мрежата)?

  3. От вашия опит можете ли да прецените с колко процента TCP е по-бърз UDP?

Съжалявам за толкова много въпроси в публикация, но трябва да знам повече подробности, преди да реша дали да използвам TCP или UDP в моето приложение.


tcp udp
person TTGroup    schedule 18.06.2012    source източник
comment
skullbox.net/tcpudp.php , udp обикновено се използва за аудио и видео, така че вероятно за вашето приложение би било по-подходящо   -  person theBigChalk    schedule 18.06.2012

Отговори (3)


arrow_upward
3
arrow_downward

Във вашия случай бих използвал TCP освен ако действително нямате практически опит с фрагментирането и повторното сглобяване на UDP пакети ръчно и сте готови да поддържате допълнителните разходи, въведени във вашия код (като например да имате повторно сглобяване на буфер и контролиране на забавянето, което това предполага).

Освен това трябва да вземете под внимание целевата мрежа. Дали е само localhost, LAN, WAN или дори интернет. Колкото по-малко контрол имате върху мрежата, толкова по-голямо е въздействието на предпочитането на TCP по отношение на времена за двупосочно пътуване, латентност, загуба на пакети и т.н. Под контрол имам предвид горни граници или оценки на броя на пресечените мрежови сегменти (#маршрутизатори), броя на различни конфигурации (QoS, ограничител на честотната лента, MTU, ...) и т.н.

Като правило, UDP е страхотен, когато всички данни, необходими за един миг (дефинирани по-долу), се побират в един пакет (MTU гарантирано е 1280 в IPv6). Мигът е кратка моментна снимка във времето, нещо, което обикновено има продължителност на живота като време за отиване и връщане. UDP също е страхотен за разговори, при които както заявката, така и отговорът са малки обекти.

Така че в този смисъл азбих използвал UDP за нещо като DNS (кратко запитване, кратък отговор) или данни за финансови транзакции (има само толкова много в рамките на жизнения цикъл от 1 време за отиване и връщане), или метаданни на протокола, като хешове на номера или идентичност на участващи клиенти (заявка/отговор кратък и има само няколко в рамките на времето за двупосочно пътуване).

Надявам се това да помогне.

Редактиране:
За да отговорите на вашите въпроси

  1. UDP (ограниченията са изброени по-горе)
  2. IPv6 offers path mtu detection, you'd simply use the PMTU, for IPv4 you'd have to roll your own:
    • set the IP_DONTFRAG socket option
    • изпрати пакет, който бихте предположили, че преминава
    • помислете за прост протокол, който да позволи на получателя да ви каже дали пакетът е получен напълно
    • ако не -> намалете размера, ако да -> увеличете размера
    • след няколко пинг-понга имате сигурна оценка за PMTU (разбира се, вече можете да изпращате данни за полезния товар)
  3. UDP ще превъзхожда значително TCP, ако естеството на мрежата е стабилно и остава стабилно. (Обратно) TCP няма да спечели, когато естеството на мрежата продължава да се променя (вариации в латентността, променяща се вероятност за загуба на пакети и т.н.) Но, на същата бележка, UDP няма strong> победи, когато мрежовите сегменти са много далеч един от друг и QoS се използва в някои от междинните сегменти (QoS, което е конфигурирано да предпочита повече или по-малко известни TCP услуги пред „други“ неща.

За някои цифри и вдъхновение трябва да разгледате udt.

person hroptatyr    schedule 18.06.2012
comment
Какво? Бихте използвали UDP за финансова информация, но TCP за поточно видео, което има ограничения в реално време? Това е много назад спрямо най-добрите практики. - person Oleksi; 18.06.2012
comment
Не, азбих използвал UDP и в този случай, при условие че имам контрол над кодека. И мисля, че в сравнение с финансовите данни видео стриймингът е много по-спокоен по отношение на латентността, стига да остане постоянен. - person hroptatyr; 18.06.2012

arrow_upward
5
arrow_downward

Тъй като приложението ви предава поточно видео, вероятно искате UDP. Една огромна разлика между TCP и UDP (в този случай) е, че UDP не се опитва да възстанови изгубени пакети, както прави TCP. Не искате видеото да се презарежда всеки път, когато се пропусне кадър, защото това ще отнеме много време, вместо това UDP просто ще пропусне загубени кадри. (Ако щракнете с десния бутон върху видеоклип в Youtube, можете да видите броя на изпуснатите пакети по време на поточно предаване на видеоклип)

person pennetti    schedule 18.06.2012
comment
Извинения, не знам какъв е процентът, но можете да погледнете stackoverflow.com/questions/47903/ за малко повече информация относно разликата в скоростта. - person pennetti; 18.06.2012

arrow_upward
0
arrow_downward

Освен видео/аудио стрийминг UDP се използва за приложения с ниска латентност, които имат кратки съобщения.

person Ivan Voroshilin    schedule 03.03.2014