Якщо говорити про те, "що швидше", - принаймні два дуже різні аспекти: пропускна здатність та затримка.
Якщо говорити про пропускну здатність - контроль потоку TCP (як зазначено в інших відповідях), є надзвичайно важливим і робити все, що можна порівняти з UDP, хоча це, безумовно, можливо, був би великий головний біль (tm). Як результат - використання UDP, коли вам потрібна пропускна здатність , рідко кваліфікується як хороша ідея (якщо ви не хочете отримати несправедливу перевагу перед TCP).
Однак якщо говорити про затримки - вся справа зовсім інша. У той час як за відсутності втрати пакетів TCP та UDP поводяться надзвичайно схоже (будь-які відмінності, якщо такі є, маргінальні) - після втрати пакета весь малюнок різко змінюється.
Після будь-якої втрати пакету TCP чекатиме повторної передачі щонайменше 200 мс (1 сек на абзац 2.4 RFC6298, але практичні сучасні реалізації, як правило, скорочують її до 200 мс). Більше того, із TCP, навіть ті пакети, які дісталися до хостового пункту призначення, не будуть доставлені у вашу програму, поки не буде отриманий відсутній пакет (тобто, весь зв’язок затримається на ~ 200 мс) - BTW, цей ефект, відомий як Head-of Блокування рядків, притаманне всім надійним упорядкованим потокам, будь то TCP або надійним + замовленим UDP. Щоб зробити ще гірше - якщо повторно переданий пакет також буде втрачений, тоді ми будемо говорити про затримку ~ 600 мс (через так звану експоненціальну мітку, 1-а повторна передача - 200 мс, а друга - 200 * 2 = 400 мс). Якщо наш канал має 1% втрати пакетів (що непогано за сьогоднішніми стандартами), і у нас гра з 20 оновленнями в секунду - такі 600 затримок трапляться в середньому кожні 8 хвилин. А оскільки 600 мс більш ніж достатньо, щоб вас вбили в швидкій грі - ну, це дуже погано для ігрового процесу. Саме ці ефекти саме тому, що гамедеви часто віддають перевагу UDP перед TCP.
Однак, використовуючи UDP для зменшення затримок - важливо усвідомити, що просто "використання UDP" недостатньо для значного поліпшення затримки, все стосується того, ЯК ви використовуєте UDP. Зокрема, хоча бібліотеки RUDP зазвичай уникають цього "експоненціального переходу" та використовують коротший час повторної передачі - якщо вони використовуються як "надійний упорядкований" потік, їм все одно доведеться страждати від блокування прямого рядка (так у випадку подвійного втрата пакету, замість цього 600мс ми отримаємо близько 1,5 * 2 * RTT - або для досить непоганих RTT 80мс, це затримка ~ 250 мс, що є поліпшенням, але все ж можна зробити краще). З іншого боку, якщо ви використовуєте методи, обговорені в http://gafferongames.com/networked-physics/snapshot-compression/ та / або http: // ithare. , можливо виключити блокування Head-of-Line повністю (тому для подвійної втрати пакету для гри з 20 оновленнями в секунду затримка становитиме 100 мс незалежно від RTT).
І як бічна примітка - якщо у вас є доступ лише до TCP, але немає UDP (наприклад, у браузері, або якщо ваш клієнт стоїть за одним із 6-9% негарних брандмауерів, що блокують UDP) - начебто є спосіб реалізуйте UDP-over-TCP, не несучи занадто багато затримок, дивіться тут: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (обов'язково читайте коментарі теж (!)).