Quando si parla di "ciò che è più veloce" - ci sono almeno due aspetti molto diversi: rendimento e latenza.
Se si parla di throughput - il controllo del flusso di TCP (come menzionato in altre risposte), è estremamente importante e fare qualcosa di paragonabile a UDP, sebbene certamente possibile, sarebbe un grosso mal di testa (tm). Di conseguenza, l'utilizzo di UDP quando è necessario il throughput , raramente si qualifica come una buona idea (a meno che non si desideri ottenere un vantaggio sleale su TCP).
Tuttavia, se si parla di latenze , il tutto è completamente diverso. Mentre in assenza di perdita di pacchetti TCP e UDP si comportano in modo estremamente simile (qualsiasi differenza, se presente, essendo marginale) - dopo la perdita del pacchetto, l'intero modello cambia drasticamente.
Dopo qualsiasi perdita di pacchetti, TCP attenderà la ritrasmissione per almeno 200 ms (1 secondo al paragrafo 2.4 di RFC6298, ma le implementazioni moderne e pratiche tendono a ridurlo a 200 ms). Inoltre, con TCP, anche quei pacchetti che hanno raggiunto l'host di destinazione - non saranno consegnati alla tua app fino a quando non viene ricevuto il pacchetto mancante (ovvero, l'intera comunicazione è ritardata di ~ 200ms) - A proposito, questo effetto, noto come Head-of -Line Blocking, è inerente a tutti i flussi ordinati affidabili, siano essi TCP o affidabili + UDP ordinati. A peggiorare le cose: se si perde anche il pacchetto ritrasmesso, si parlerà di un ritardo di ~ 600 ms (a causa del cosiddetto backoff esponenziale, il primo ritrasmesso è 200 ms e il secondo è 200 * 2 = 400 ms). Se il nostro canale ha una perdita di pacchetti dell'1% (che non è male per gli standard di oggi), e abbiamo un gioco con 20 aggiornamenti al secondo - tali ritardi di 600ms si verificano in media ogni 8 minuti. E poiché 600 ms sono più che sufficienti per farti uccidere in un gioco frenetico - beh, è piuttosto male per il gameplay. Questi effetti sono esattamente il motivo per cui i Gamedev preferiscono spesso UDP su TCP.
Tuttavia, quando si utilizza UDP per ridurre le latenze, è importante rendersi conto che il semplice "utilizzo di UDP" non è sufficiente per ottenere un sostanziale miglioramento della latenza, è tutto su COME si utilizza UDP. In particolare, mentre le librerie RUDP di solito evitano quel "backoff esponenziale" e usano tempi di ritrasmissione più brevi - se sono usate come stream "affidabili ordinati", devono comunque soffrire di Head-of-Line Blocking (quindi nel caso di un doppio perdita di pacchetti, invece di quei 600ms otterremo circa 1,5 * 2 * RTT - o per un RTT abbastanza buono da 80ms, è un ritardo di ~ 250ms, che è un miglioramento, ma è ancora possibile fare di meglio). D'altra parte, se si utilizzano le tecniche discusse in http://gafferongames.com/networked-physics/snapshot-compression/ e / o http: // ithare. , È possibile eliminare completamente il blocco Head-of-Line (quindi per una perdita a doppio pacchetto per un gioco con 20 aggiornamenti / secondo, il ritardo sarà di 100 ms indipendentemente da RTT).
E come nota a margine - se ti capita di avere accesso solo a TCP ma senza UDP (come nel browser o se il tuo client è dietro uno dei 6-9% dei brutti firewall che bloccano UDP) - sembra che ci sia un modo per implementare UDP-over-TCP senza incorrere in troppe latenze, vedere qui: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (assicurarsi di leggere anche i commenti (!)).