Come posso formulare la latenza di comunicazione in TCP / IP?

Ho difficoltà a derivare un modello / equazione matematica per stimare la latenza di andata e ritorno tra due nodi che comunicano tramite TCP / IP. I nodi si scambiano dati in base al protocollo HTTP. In questo modello, i fattori più importanti da studiare sono la distanza fisica tra due nodi nella rete, il numero di hop intermedi, la larghezza di banda, il ritardo di elaborazione ad ogni hop. Ho cercato sul web ma non ho trovato nulla in questo senso, piuttosto ho trovato qualcosa sulle reti di commutazione dei circuiti e sul protocollo UDP. Posso personalizzarli per adattarli al TCP?

Questo è un processo molto complicato, quindi formulare un'equazione che potrebbe essere utile per prevedere accuratamente RTT è estremamente difficile. Nella migliore delle ipotesi, direi che potresti creare un modello che utilizza un sacco di medie per ogni fase, che potresti modificare se ti capita di "conoscere meglio" per una situazione particolare è il più vicino possibile. Questo è qualcosa che sto attualmente studiando in modo da poterti dire quello che so finora (da zero, a partire dallo strato fisico):

• Vedi le mie domande su Electronics SE; Ritardo di codifica di Ethernet e relazione con la frequenza del cavo e la velocità dell'elettricità (propagazione del segnale?) Attraverso il rame per ritardo di comunicazione . Dal momento che useresti velocità standardizzate (100 Mbps, 1 Gbps, 10 Gbps ecc.), Non trattare la fibra o il rame in modo diverso. Il "ritardo" verso il basso è quasi ugualmente uguale, ma il rame non può trasportare un segnale così evidente. Ho questa domanda sul sito di Physics SE, a cui conosco la risposta ora. Devo solo trovare il tempo per sistemare le cose, quindi tienilo d'occhio se sei interessato (posterò alcune altre domande relative all'uso della fibra a cui ora conosco la risposta quando ne avrò la possibilità ).

• Molto più ritardo verrà aggiunto dai dispositivi alla fine di un collegamento. Non esiste un modo standard per dire "oh 2 switch lungo un percorso è ritardo Xms, 4 switch è 2 * Xms, 2 router è Yms ... ecc.". Supponendo che tu stia usando per esempio 1Gpbs e i dispositivi nel percorso in avanti alla frequenza di linea, sappiamo che è 1000000000bps, quindi l'interfaccia fisica funziona a una velocità di codifica fissa (che varia da 1 nanosecondo per bit fino a qualunque sia il massimo del lo schema di codifica dei simboli in uso è, ad esempio 10b )

• Esistono tre tipi principali di ritardo (a livello fisico) che è necessario conoscere e considerare; Ritardo di serializzazione, ritardo di codifica, ritardo di propagazione (e ritardo di elaborazione, ritardo di accodamento, ritardo di codifica e decodifica, ma questi sono al di sopra del livello fisico ma devono essere menzionati!). Questi sono ragionevolmente ben documentati su Internet, VoIP: un'analisi approfondita , la diapositiva 13 qui , carica su Google Scholar e molti altri.

• Mentre spostiamo lo stack di protocollo, lavorerei sul presupposto che il MAC di destinazione si trova in ogni tabella di camma degli switch e, a livello IP, il MAC di destinazione nelle tabelle ARP. Il ritardo aggiuntivo indotto da questi processi di individuazione si verifica solo per il primo pacchetto in un flusso in modo che possano essere aggirati aumentando i timeout e inviando ARP gratuiti ecc.

• Man mano che si arriva al livello dell'applicazione, questo diventerà davvero difficile perché dipende dal server (ad esempio) che elabora la richiesta, che sarà soggetta a ritardo di interruzione. Il numero di interrupt necessari per elaborare la richiesta e gli switch di contesto dovuti al carico è imprevedibile.

Vorrei davvero aiutarti con la tua domanda, purtroppo questo è tutto ciò che ho tempo per ora. Aggiornerò questa risposta forse più tardi stasera o domani, volevo pubblicare quello che ho finora.

Nel frattempo, la maggior parte delle persone tende a lavorare con la figura per il ritardo su uno strato fisico di rame / fibra di circa 0,6 * c (C = velocità della luce). Inoltre, devi pensare allo scambio TCP di ACK ogni pacchetto X, che differisce se stai usando SACK per esempio, e se stai usando jumbo frame e / o dimensioni MSS più grandi (ora anche MTU deve essere preso in considerazione!) , se stai inviando altri ACK intermedi (se il volume di dati trasferiti ti interessa). Devi anche tener conto del famigerato prodotto di ritardo della larghezza di banda e non fare la stupida errata interpretazione che ho fatto di quella pagina. Ho iniziato a fare vari semplice (e molto brutto) calcolatrici dati qui. Ancora una volta un lavoro in corso proverò ad aggiornarli presto. Ho intenzione di aggiungere un calcolatore simile a quello che stai cercando di fare. Ho anche fatto alcuni calcolatori di luce e fibre se sei interessato, ma ancora una volta, non c'è tempo! Non ho ancora iniziato a caricarli. Proverò al più presto ad aggiornare ancora una volta questa risposta, nei prossimi giorni.

PS Ho dimenticato di menzionare QoS! Se QoS è in gioco in qualsiasi punto del percorso, sarà davvero difficile riuscire a convincere RTT!

(Voglio sottolineare che altri hanno pubblicato risposte eccellenti su come funzionano i ritardi e cosa li provoca. Ma l'OP ha chiesto informazioni sulla modellazione; Un modello di base è semplice e basta inserire numeri di esempio. Se vuoi sapere perché i ritardi sono quello che sono, quindi vedi le risposte di tutti gli altri: ^)

La latenza di rete è semplicemente il tempo di transito da un punto finale all'altro punto finale, che intercorre tra N hop .

Quindi hai N segmenti (hop) con nodi intermedi N-1. Ogni nodo ha un ritardo (l'effetto cumulativo di diverse cose su quel nodo, come ritardo coda, ritardi di elaborazione, ecc.) E ogni segmento ha un ritardo di transito. Complessivamente sono 2N - 1 variabili indipendenti. Quindi è seg1 + nodo1 + seg2 ... + nodo (N-1) + segN Un hop, è solo = seg1, due speranze è seg1 + node1 + seg2, ecc.

Successivamente devi definire quali sono tutti quei pezzi. Quindi potresti costruire una rete modello con una rete CATV, un collegamento satellitare, un collegamento in fibra ottica, un Ethernet, ecc. Per ognuna di queste tecnologie devi cercare informazioni di esempio.

I ritardi di transito sarebbero approssimativamente la dimensione dei dati divisa per la velocità di trasmissione del segmento. Se hai bisogno di un modello più accurato, devi aggiungere il ritardo del volo - approssimativamente la lunghezza del segmento, diviso per la velocità del flusso di dati (approssimativa della velocità della luce.) È importante se hai un collegamento satellitare coinvolto; Il su e giù per il satellite geosincrono è significativo.

I ritardi su ciascun nodo dovranno essere stimati in base all'apparecchiatura che si sta inserendo nel modello.

Se si desidera la latenza dell'applicazione, (ad esempio il ritardo fino all'inizio del flusso di dati di un trasferimento FTP), si crea contando quante volte entra in gioco la latenza della rete. Ad esempio, un handshake TCP a 3 vie aggiunge una latenza di rete tripla, e così via fino a raggiungere l'applicazione.

È possibile stimare la latenza di andata e ritorno eseguendo un'acquisizione di pacchetti su entrambi i lati, quindi misurare il ritardo tra le richieste in uscita dalla macchina monitorata e le risposte in risposta. Ad esempio, se si contrassegna il momento in cui un SYN è uscito sul computer remoto, quindi è stato segnato il momento in cui è arrivata la risposta SYN + ACK, la differenza darebbe un buon ballpark della latenza del round trip TCP.

Tieni presente che questo sarà maggiore della vera latenza di rete e quanto maggiore dipende da quanto sia pesantemente caricato entrambi i computer.

Il ritardo tra due host dipenderà da diversi fattori:

• Ritardo di propagazione
• Ritardo di serializzazione
• Ritardo di accodamento / buffering

Il ritardo di propagazione è il tempo impiegato fisicamente dai pacchetti per spostarsi tra due posizioni. La velocità della luce in fibra è di circa 200000 km / s. La Svezia dove vivo è di circa 1570 km, quindi sarebbe 7,85 ms, ma in realtà è più perché questa è la distanza attraverso la vista degli uccelli.

Il ritardo di serializzazione è il tempo necessario per serializzare il pacchetto attraverso il supporto fisico, ovvero le interfacce sul dispositivo di rete. Se si dispone di una connessione a 2 Mbit e si sta inviando un pacchetto di 1500 byte che sarebbe 6 ms per serializzare il pacchetto (12000/2000000).

Il ritardo di accodamento / buffering è quanto tempo il pacchetto deve rimanere in una coda / buffer prima di essere inviato sull'interfaccia. A seconda della velocità dell'interfaccia e di come vengono utilizzati i buffer di grandi dimensioni, questo potrebbe essere il prossimo niente o un ritardo significativo.

Quindi ci sarebbero alcuni ritardi sugli host per generare i pacchetti e far sì che l'applicazione li gestisca. Esistono applicazioni per misurare il ritardo HTTP. Le persone non accettano molto ritardo sui siti Web prima di rinunciare a loro, quindi è un fattore importante.