Perché UDP con affidabilità (implementato a livello di applicazione) non è un sostituto di TCP?

TCP fornisce affidabilità a livello di trasporto mentre UDP no. Quindi, UDP è veloce. Tuttavia, un protocollo a livello di applicazione può implementare un meccanismo affidabile durante l'utilizzo di UDP.

In questo senso, perché UDP con affidabilità (implementato a livello di applicazione) non è un sostituto di TCP nel caso in cui UDP sia più veloce di TCP mentre abbiamo bisogno di affidabilità?

TCP è più veloce che puoi fare qualcosa con le sue proprietà di affidabilità. Se hai solo bisogno, diciamo, del sequenziamento e del rilevamento degli errori, UDP può essere fatto per funzionare perfettamente. Questa è la base per la maggior parte dei protocolli in tempo reale come voce, streaming video ecc., In cui il ritardo e il jitter sono più importanti della correzione di errori "assoluti".

Fondamentalmente, TCP afferma che i suoi flussi possono essere affidati alla fine. La velocità dipende da vari timer, velocità, ecc. Il tempo impiegato per risolvere gli errori può essere imprevedibile, ma le operazioni di base sono le più rapide possibile quando non ci sono errori. Se un sistema conosce qualcosa sui possibili errori, potrebbe essere in grado di fare qualcosa che non è possibile con TCP. Ad esempio, se gli errori a bit singolo sono particolarmente probabili, è possibile utilizzare la codifica per la correzione degli errori per quegli errori di bit: tuttavia, questo è molto meglio implementato nel livello di collegamento. Come altro esempio, se sono comuni brevi scoppi di perdita di pacchetti interi, è possibile risolvere questo problema con una trasmissione multipla senza attendere la perdita, ma ovviamente questo è costoso in termini di larghezza di banda. O in alternativa, rallenta la velocità fino a quando la probabilità di errore è trascurabile: costosa anche in larghezza di banda. Alla fine,

In termini di implementazione, scopriresti che i secoli di programmatori investiti in TCP lo renderanno più veloce di qualsiasi cosa generale che potresti permetterti di fare, oltre che più affidabile nei casi oscuri.

TCP fornisce: un metodo onnipresente di connessione (essenziale laddove i sistemi di comunicazione non hanno alcun controllo comune) fornendo un flusso di byte affidabile, ordinato, (e deduplicato), bidirezionale, con finestre, con controllo della congestione su reti multi-hop a distanza arbitraria.

Se un'applicazione non richiede l'ubiquità (il tuo software funziona su entrambi i lati) o non ha bisogno di tutte le funzionalità di TCP, molte persone usano proficuamente altri protocolli, spesso su UDP. Gli esempi includono TFTP (minimalista, con gestione degli errori davvero inefficiente, QUIC progettato per ridurre le spese generali (ancora contrassegnato come sperimentale) e librerie come lidgren, che ha un controllo accurato su quali funzioni di affidabilità sono richieste. [Grazie ai commentatori. ]

UDP con affidabilità può davvero essere un sostituto di TCP. Ne abbiamo già un esempio: si chiama QUIC .

Da Wikipedia:

Tra le altre applicazioni, QUIC migliora le prestazioni delle applicazioni Web orientate alla connessione che attualmente utilizzano TCP. Lo fa stabilendo un numero di connessioni multiplex tra due endpoint tramite User Datagram Protocol (UDP).

Il vantaggio dell'utilizzo di UDP rispetto alla creazione di un nuovissimo protocollo a livello di trasporto è che i router e altri dispositivi di rete lo comprendono già.

È possibile utilizzare UDP per implementare la funzionalità TCP a livello dell'applicazione (affidabilità, adattabilità). Puoi anche usare TCP in primo luogo a meno che qualcosa che la tua applicazione non abbia davvero bisogno non possa essere fatto con TCP. Se implementate queste funzioni da soli, molto probabilmente finirete molto peggio che con TCP. L'overhead aggiunto riduce anche l'efficienza complessiva.

TCP non è lento: richiede solo una stretta di mano prima di trasmettere e la finestra di trasmissione si adatta al canale. Può modellare molto bene il suo throughput sul canale di trasmissione e adattarsi ai cambiamenti durante il flusso, cosa che UDP non può fare (da solo).

Tuttavia, i protocolli sopra il livello di trasporto sono fuori tema qui.

Su una rete pulita sono abbastanza equivalenti. Ci sono casi in cui TCP si bloccherà per periodi (qualcuno ha mai visto un blocco dello schermo HTTP al caricamento?) Ma non consegnerà immondizia o confonderà pacchetti e raramente si arrenderà completamente.

UDP può dare al livello applicativo un maggiore controllo sul traffico a scapito di un sacco di lavoro.

La risposta alla tua domanda è, a volte è fatta così. I giochi che richiedono bassa latenza spesso fanno esattamente questo. È molto più lavoro, ma la capacità di controllare esattamente quanti pacchetti eccezionali si possono avere e quanto spesso vengono riprovati ne vale spesso la pena.

Quindi, nel complesso, la differenza è che TCP è un'implementazione molto buona per scopi generici, ma ci sono scopi specifici che UDP può fare che TCP fa molto male o per niente, ad esempio:

• Non mollare MAI (con TCP la connessione a volte si blocca e devi interrompere la connessione e riavviarla)
• Invio di un flusso rapido di pacchetti che non richiedono risposte e non ti dispiace perdere alcuni occasionalmente (dove è importante solo il pacchetto più recente, tutti gli altri possono essere scartati) - pensa agli aggiornamenti di posizione del gioco - potresti ottenere un po ' "Salta" anziché ogni passaggio, ma ottieni lo stesso risultato in modo più rapido e affidabile.
• Gestire le reti iffy analizzando i drop dei pacchetti e modificando dinamicamente la frequenza e la velocità con cui riprovare, forse anche la dimensione massima del pacchetto.

Ma in generale non ne vale la pena, TCP è piuttosto ottimale, quindi perché andare a tutto il lavoro extra e aggiungere una (grande) possibilità di aggiungere bug e difetti di sicurezza?

UDP non è veloce perché è UDP. TCP non è lento perché è TCP.

Entrambi i protocolli sono progettati con determinate garanzie e il TCP grezzo ha più garanzie di UDP grezzo.

E la regola empirica è: il prezzo delle garanzie è la prestazione .

Non c'è nulla che ti proibisca di implementare garanzie TCP su UDP. Ma poi ottieni più garanzie e quindi devi pagare il prezzo. Pertanto si riducono le prestazioni a TCP o peggio (a causa del sovraccarico UDP). A meno che tu non conosca una migliore implementazione TCP, il che è improbabile. E se lo fai allora (si spera) lo sveli e rendiamo il TCP standard più veloce. E siamo tornati da dove siamo partiti. :)

Puoi giocare anche con quelle garanzie. Modificalo leggermente, modificalo leggermente. E poi finisci con un protocollo come QUIC che è su UDP ed è molto simile a TCP + TLS. In molti casi è più veloce di TCP (anche se secondo questo articolo latenza fino al 5% e buffering fino al 15% che IMO non è un grosso problema) ma in alcuni scenari (ad esempio rete affidabile o nessuna necessità di crittografia) in realtà è più lento (vedi una spiegazione qui ).

Puoi anche indebolire quelle garanzie e quindi ha più senso. Ad esempio, supponiamo che tu stia trasmettendo in streaming e quindi i vecchi pacchetti non sono interessanti. Solo il più recente. Ma la congestione è ancora importante. Quindi prendi alcune garanzie da TCP, ma non tutte. E sì, le persone lo fanno effettivamente (ad esempio giochi in tempo reale). Ciò offre prestazioni migliori a scapito di alcune garanzie.

La tua idea sarebbe buona nello spazio profondo.

La risposta corretta è "dipende" e "perché ciò danneggerebbe la rete nel suo insieme". TCP / IP è molto gentile con le reti e si adatta automaticamente alla velocità corretta per essere veloce ma non generare tonnellate di pacchetti di ritorno ICMP.

Quando un router con RAM insufficiente riceve improvvisamente un sacco di qualsiasi tipo di pacchetto - diciamo da Tsunami, Bittorrent o FDT - lo rilascia e restituisce al mittente un piccolo pacchetto di non riconoscimento. Ora il tuo server UDP deve tracciare e ritrasmettere quella parte manualmente. Alcuni router ISP danno forma a Bittorrent così tanti da ferire lo Tsunami?

Il protocollo Tsunami utilizza UDP con un canale di controllo in TCP. http://tsunami-udp.sourceforge.net/ Ho trovato uno studio che mostra che è più lento di una cosa chiamata FDT.

Il leggendario protocollo FDT (Fast Data Transfer) del CERN è in grado di saturare qualsiasi rete utilizzando più flussi TCP. Probabilmente è più veloce, perché causa meno ritrasmissioni dello Tsunami, che inonda la rete con così tanto UDP, alcuni di essi non riescono a superare completamente.

UDP viene utilizzato da applicazioni inaffidabili: streaming audio, input / aggiornamento giochi, "ping" è in realtà ICMP ma non è garantito, Bittorrent, mosh ssh è incredibilmente reattivo, telefonia VOIP, multicast, DNS viene inviato su UDP AFAIK. Tutto ciò a cui non importa il dispari pacchetto mancante e può "recuperare" all'istante.

TCP / IP è stata davvero l'invenzione killer che ha permesso agli sviluppatori di app di impostare e dimenticare. Un socket è una coppia di indirizzi IP e porte ed è stato progettato per essere configurato e rimanere per ore, giorni, persino settimane senza ricollegarsi. Email, web, IRC e letteralmente tutte le app killer usano TCP. Ma puoi ottenere strane pause nel download che improvvisamente vanno più veloci ... e nello spazio profondo le connessioni potrebbero andare in timeout rendendo i trasferimenti in stile Tsunami migliori per i trasferimenti di file interstellari - potresti essere su qualcosa lì !!

La prova è nelle osservazioni finali di questo estratto di studio scientifico, che menziona la crescente distanza che sto facendo riguardo a: spazio profondo Da: https://uscholar.univie.ac.at/get/o:300623.pdf

Senza congestione, le prestazioni di FDT e GridFTP con TCP sono superiori a Tsunami e UDT. Il throughput più elevato di FDT è di 2,34 Gb / s con un RTT da 1 ms ma diminuisce rapidamente dopo 100 ms rispetto a GridFTP, che funziona meglio di FDT quando il collegamento RTT è più lungo di 100 ms. È interessante notare che il rendimento dello Tsunami non è diminuito all'aumentare della RTT, dimostrando che ha il controllo della congestione più efficace con l'aumento della RTT.

Poi di nuovo ... c'è in realtà un protocollo spaziale che assomiglia molto alla posta elettronica che sarebbe meglio per lo spazio. Le app non devono preoccuparsi di valori di timeout come per sempre.

TCP! = UDP + Affidabilità

TCP non è semplicemente UDP con maggiore affidabilità. TCP offre più funzionalità oltre all'affidabilità. Puoi leggerli in molti RFC.

Ognuna di queste funzionalità "potrebbe" essere implementata a livello di applicazione. Alla fine diventa un punto in cui inizi a reinventare la ruota.

Per citare alcune funzionalità TCP ha ...

• Creazione e chiusura delle connessioni: esegue l'handshake e le chiusure delle connessioni

• Controllo del flusso: assicura che il mittente e il destinatario trasmettano a velocità in cui entrambi possono gestire la velocità dei dati.

• Controllo della congestione end-to-end: consente ai nodi end di limitare il loro throughput in base alle perdite. Informazioni su avvio lento, prevenzione della congestione e recupero rapido.

Nella mia esperienza, UDP viene utilizzato quando la velocità è una preoccupazione per l'affidabilità. È possibile aggiungere un certo livello di affidabilità a livello di applicazione che non è affidabile al 100% come TCP. Ad esempio, se si desidera ancora prestazioni veloci, è possibile implementare la correzione degli errori in avanti (FEC) in cui si trasmettono i dati più di una volta. Ottieni comunque buone prestazioni e un certo livello di affidabilità (nota una certa affidabilità TCP) senza tutte le chat chit avanti e indietro per perdere i pacchetti. Il problema è che aumenta l'utilizzo della rete ma può essere adatto per applicazioni in tempo reale come giochi o streaming.