Perché i dati non vengono trasferiti durante la 3a parte dell'handshake a 3 vie TCP? ad es.tcpip Handshake a 3 vie
(da A a B) SYN
(B ad A) ACK + SYN
(da A a B) ACK .... il motivo per cui i dati non posso essere trasferiti insieme a questo ACK?
Ho sempre pensato che fosse necessario mantenere la fase di creazione della sessione separata dalla fase di trasferimento dei dati in modo che i dati reali no vengano trasferiti fino a quando entrambe le estremità della sessione hanno concordato i numeri di sequenza e le opzioni di sessione, specialmente da i pacchetti in arrivo possono provenire da una sessione totalmente diversa, precedente, che si verifica solo per avere gli stessi endpoint.
Tuttavia, a seguito di ulteriori indagini, non sono del tutto certo che la trasmissione di dati con i pacchetti di handshake non sia consentita. La sezione sulla creazione connessione TCP nel mio Internetworking con TCP/IP libro contiene il seguente frammento:
A causa del protocollo di progettazione, è possibile inviare i dati con i numeri di sequenza iniziali nel segmenti di handshake. In questi casi, il software TCP deve contenere i dati fino al completamento dell'handshake. Una volta stabilita una connessione, il software TCP può rilasciare i dati trattenuti e consegnarli rapidamente ad un programma applicativo in attesa.
Poiché è certamente possibile costruire un pacchetto TCP con SYN (o ACK) e dati, questo potrebbe essere ammessi. Io ho mai visto visto che in natura, ma, ancora una volta, non ho mai visto un lemure nano peloso in natura, anche se sono sicuro che esistono.
È possibile che sia il software socket che impedisce l'uscita dei dati prima che la sessione sia completamente stabilita, ma TCP sembra considerarlo valido. Sembra che tu possa inviare dati con un pacchetto SYN-ACK (fase 2 della creazione della connessione) poiché hai il numero di sequenza e le opzioni dell'altra estremità. Allo stesso modo, sembra possibile anche inviare i dati con il pacchetto fase 3 ACK.
Il motivo per cui il software TCP mantiene i dati fino a quando l'handshake è completamente completo è probabilmente dovuto al motivo sopra menzionato - solo una volta che entrambe le estremità hanno concordato i numeri di sequenza si può essere certi che i dati non provengano da un sessione precedente.
Internetworking with TCP/IP Volume 1 Principles, Protocols and Architecture, 3rd edition, Douglas E. Comer, ISBN 0-13-216987-8.
Ti chiedi se tali dati non superino i filtri di ispezione deep packet che non aspettano dati nell'handshake iniziale! – caf
non vedo il motivo per cui non poteva ... Il protocollo specifica che la connessione è stabilita * dopo * B riceve l'ACK, però. – Borealid