il riconoscimento da parte di TCP non garantisce che i dati siano stati consegnati

11

In RFC 793 c'è una parte sul riconoscimento dei segmenti TCP:

Quando il TCP trasmette un segmento contenente dati, inserisce una copia in una coda di ritrasmissione e avvia un timer; quando viene ricevuto il riconoscimento per tali dati, il segmento viene eliminato dalla coda. Se la conferma non viene ricevuta prima che scada il tempo, il segmento viene ritrasmesso.

Un riconoscimento da parte di TCP non garantisce che i dati siano stati consegnati all'utente finale , ma solo che il TCP ricevente si è preso la responsabilità di farlo.

Questo è interessante. Nel nostro NOC, spesso risolviamo i problemi di connettività tra la nostra rete e la rete client esterna e ogni volta che annusiamo il traffico su un firewall e vediamo i bit SYN e ACK inviati e ricevuti in entrambe le direzioni, assumiamo che la connettività sia stabilita e il problema non abbia nulla da fare con la rete.

Ma ora questo RFC mi ha fatto pensare: cos'altro dovrei controllare (senza impostare Wireshark) se viene stabilita una connessione TCP ma gli utenti continuano a riscontrare problemi di connettività?

— kamokoba
fonte

5

Il significato di questa frase è semplicemente il significato letterale inglese della frase: il fatto che il driver di rete abbia ricevuto i dati (e abbia riconosciuto la ricezione) non garantisce che l'utente finale riceva i dati. Ad esempio, potrebbe esserci un bug nel server web. Per quanto riguarda la tua domanda di chiusura: l'unico modo per capire se l'utente finale ha ricevuto i dati è chiamarli e chiederli.

— Jörg W Mittag,

24

Questa parte della RFC riguarda il passaggio della responsabilità al sistema operativo o qualunque sia la fase successiva del processo. Si occupa fondamentalmente della separazione degli strati.

Un riconoscimento da parte di TCP non garantisce che i dati siano stati consegnati all'utente finale, ma solo che il TCP ricevente si è preso la responsabilità di farlo.

Ci ho sempre pensato in questo modo:

Il sistema operativo potrebbe arrestarsi in modo anomalo tra l'invio di ACK e il raggiungimento dei dati dal processo client ("client" qui significa client del sistema operativo, non "client di rete")
Il processo client potrebbe essere difettoso o in crash, o solo molto più lento del previsto per aggirare la gestione dei suoi dati in entrata, o addirittura leggerlo solo in circostanze non ovvie
Se il client invia i dati in seguito, forse a un file su disco, il file potrebbe non essere stato ancora scritto o scaricato
Se il client invia i dati in avanti tramite TCP, il TCP del lato remoto potrebbe non aver trasmesso i dati, ricevuto un ACK o il processo remoto ha consumato correttamente i dati

Tutto ciò che sta dicendo è che si tratta di un riconoscimento di livello 3 ("Sento i tuoi byte") non di un riconoscimento di livello superiore . Consideriamo ad esempio la differenza tra TCP ACK, SMTP 250 OKdopo che il gateway di posta dell'hop successivo accetta un messaggio, un messaggio di ricezione del messaggio (ad es. Per RFC 3798 ), un pixel di tracciamento del messaggio aperto, una nota di ringraziamento di un PA, e una risposta che dice "Sì, lo farò".

Un altro esempio concreto sarebbe una stampante:

Deve ACK i dati prima di sapere cosa contiene la fine (potrebbe trattarsi di un file Postscript che inizia con una libreria inclusa più grande della finestra di trasmissione TCP)
Potrebbe contenere una query sullo stato ("hai carta?", Che può ovviamente eseguire)
Potrebbe contenere un comando di stampa ("stampa questo", che potrebbe non riuscire, se la carta è esaurita)

Vorrei suggerire che se gli utenti visualizzano e inviano ACK ma continuano a riscontrare problemi di connettività, è molto più probabile che vi siano problemi di congestione, sistema operativo o applicazione rispetto a qualsiasi cosa strettamente correlata alla rete.

Per diagnosticare suggerisco di cercare ritrasmissioni, piuttosto che gli ACK in particolare.

— jonathanjo
fonte

Un altro punto elenco: anche se il processo client funziona correttamente, potrebbe non aver ancora letto i dati.

— Barmar,

1

Il processo client (se sembra pigro o perverso) potrebbe semplicemente non chiamare mai recv()il socket, nel qual caso i dati ricevuti rimarrebbero indefinitamente nel buffer di ricezione del socket TCP.

— Jeremy Friesner,

Grazie ad entrambi, aggiornato per suggerire che il processo client può essere lento, errato, instabile.

— Jonathanjo,

Non è possibile fare affidamento su ACK per assicurarsi che l'applicazione abbia elaborato l'input, è necessario implementare un livello applicazione ACK o Verifica. Per dirlo in un altro contesto. Per le reti di controllo industriale che utilizzano TSN con uno stack IP sul lato client, TCP ACK non è sufficiente a garantire che le variabili di processo siano state bloccate. Cioè, non è possibile fare affidamento su TCP ACK per mettere il sistema in uno stato sicuro o riparabile, è necessario avere la conferma da un servizio a livello di applicazione che è sicuro tenere la mano nella macchina.

— crasic

10

Dal punto di vista della RFC, "l'utente finale" è l'applicazione. Non c'è garanzia che l'applicazione abbia ottenuto i dati, solo che il processo TCP li ha ricevuti.

Dal punto di vista del NOC, la rete funziona e i dati hanno raggiunto l'host finale. Presumibilmente, questo è tutto ciò che ti interessa.

— Ron Trunk
fonte

0

Puoi vederlo in questo modo.

Sei M.Smith e vuoi inviare una lettera a M.Toto (le persone sono il livello applicazione).

Per inviare la lettera, vai all'ufficio postale locale A che invierà la lettera a M. Ufficio postale locale B (gli uffici postali sono il livello TCP).

Tutto potrebbe andare bene tra te, l'ufficio postale A e l'ufficio postale B - B invierà un ACK all'ufficio postale A. Ma nulla garantisce che la lettera arriverà a M.Toto. Tutto potrebbe succedere tra l'ufficio postale B e M. Totò.

Questo è fondamentalmente ciò che dice RFC.

— toto
fonte