Overhead generale della creazione di una connessione TCP

Question

Mi piacerebbe conoscere il costo generale della creazione di una nuova connessione, rispetto a UDP. So che TCP richiede uno scambio iniziale di pacchetti (l'handshake a 3 vie). Quali sarebbero gli altri costi? Ad esempio c'è una sorta di magia nel kernel necessaria per impostare i buffer, ecc.?

La ragione per cui sto chiedendo è che posso mantenere aperta una connessione esistente e riutilizzarla secondo necessità. Tuttavia, se c'è un piccolo sovraccarico, la ricomposizione ridurrebbe la complessità.

Answer 1

Rispetto alla latenza dello scambio di pacchetti, tutti gli altri costi come i tempi di configurazione del kernel sono insignificanti.

Answer 2

Una volta che un pacchetto UDP è stato scaricato sul filo, lo stack del protocollo UDP è libero di dimenticarsene completamente. Con TCP, c'è almeno il dettaglio della connessione (sorgente/destinazione e IP sorgente/dest), il numero di sequenza, la dimensione della finestra per la connessione, ecc ... Non è un'enorme quantità di dati, ma si aggiunge rapidamente a un server occupato con molte connessioni.

E poi c'è anche l'handshake a 3 vie. Alcuni braindead (e/o sistemi maligni) possono abusare del processo (cercare "syn flood"), o semplicemente rilasciare la connessione alla loro estremità, lasciando il sistema in attesa di una risposta o di un avviso ravvicinato che non arriverà mai. Il lato positivo è che con TCP il sistema farà del suo meglio per assicurarsi che il pacchetto arrivi dove deve. Con UDP, non ci sono garanzie.

Answer 3

OPZIONE 1: Il costo generale della creazione di una connessione TCP sono:

1. Creare connessione socket
2. Invia dati
3. Abbattere connessione socket

Fase 1: Richiede uno scambio di pacchetti, quindi è ritardato a & dalla latenza della rete più il tempo di servizio del server di destinazione. Nessun utilizzo significativo della CPU su entrambi i box è coinvolto.

Passaggio 2: dipende dalla dimensione del messaggio.

Passaggio 3: IIRC, invia semplicemente un pacchetto 'closing now', senza attendere l'ack di destinazione, quindi nessuna latenza coinvolta.

OPZIONE 2: Costi di UDP: *

1. creare l'oggetto UDP
2. Invia dati
3. Chiudi Oggetto UDP

Fase 1: richiede una configurazione minima, nessun problema di latenza , molto veloce.

Passaggio 2: prestare attenzione al formato, non è possibile ritrasmettere in UDP poiché non interessa se il pacchetto è stato ricevuto da qualcuno o meno. Ho sentito che più grande è il messaggio, maggiore è la probabilità che i dati vengano ricevuti danneggiati e che una regola generale è che perderai una certa percentuale di messaggi oltre i 20 MB.

Passaggio 3: lavoro minimo, tempo minimo.

OPZIONE 3: Utilizzo ZeroMQ Invece

si sta confrontando TCP ad UDP con l'obiettivo di ridurre il tempo di riconnessione. C'È UN BEL COMPROMESSO: zoccoli ZeroMQ.

ZMQ consente di impostare un socket di pubblicazione in cui non interessa se qualcuno ascolta (come UDP) e dispone di più listener su quel socket. Questo NON è un socket UDP, è un'alternativa a entrambi questi protocolli.

Vedere: ZeroMQ.org per dettagli.

È molto veloce e tollerante ai guasti e sta aumentando l'utilizzo nel settore finanziario per tali motivi.