Quando un pacchetto di rete TCP sarà frammentato a livello di applicazione?

Question

Quando un pacchetto TCP sarà frammentato a livello di applicazione? Quando un pacchetto TCP viene inviato da un'applicazione, il destinatario a livello di applicazione riceverà mai il pacchetto in due o più pacchetti? In tal caso, quali condizioni causano la divisione del pacchetto. Sembra che un pacchetto non sarà frammentato fino a raggiungere il limite Ethernet (al livello di rete) di 1500 byte. Ma quella frammentazione sarà trasparente al destinatario sul livello dell'applicazione poiché il livello di rete riassemblerà i frammenti prima di inviare il pacchetto al livello successivo, giusto?

Answer 1

Sarà diviso quando colpisce un dispositivo di rete con un MTU inferiore quindi la dimensione dei pacchetti. La maggior parte dei dispositivi ethernet è 1500, ma può essere spesso più piccola, 1492 se quella Ethernet passa su PPPoE (DSL) a causa delle informazioni di routing aggiuntive, ancora più basse se viene aggiunto un secondo livello come Condivisione connessione Internet di Windows. E dialup è normalmente 576!

In generale, tuttavia, è necessario ricordare che TCP non è un protocollo di pacchetto.Utilizza pacchetti al livello più basso per trasmettere su IP, ma per quanto riguarda l'interfaccia per qualsiasi stack TCP, è un protocollo di flusso e non ha bisogno di fornire una relazione 1: 1 ai pacchetti fisici inviati o ricevuti (ad esempio, la maggior parte delle pile conserverà i messaggi fino a quando un certo periodo di tempo è scaduto, o ci sono abbastanza messaggi per massimizzare la dimensione del pacchetto IP per il MTU specificato)

Ad esempio se si inviano due "pacchetti" (chiama la tua funzione di invio due volte), il programma ricevente potrebbe ricevere solo 1 "pacchetto" (lo stack TCP ricevente potrebbe combinarli insieme). Se stai impiantando un protocollo di tipo messaggio su TCP, dovresti includere un'intestazione all'inizio di ogni messaggio (o qualche altro meccanismo di intestazione/piè di pagina) in modo che il lato ricevente possa dividere il flusso TCP in singoli messaggi, sia quando un messaggio viene ricevuto in due parti o quando vengono ricevuti più messaggi come blocco.

Answer 2

Se un pacchetto da 3000 byte entra in una rete Ethernet con una dimensione MTU predefinita di 1500 (per ethernet), sarà frammentato in due pacchetti di ogni 1500 byte di lunghezza. Questa è l'unica volta in cui riesco a pensare.

Wireshark è la soluzione migliore per controllare questo. L'ho usato per un po 'e sono totalmente impressionato

Answer 3

Se un pacchetto supera il massimo MTU di un dispositivo di rete, verrà suddiviso in più pacchetti. (Nota la maggior parte delle apparecchiature è impostata su 1500 byte, ma questa non è una necessità.)

La ricostruzione del pacchetto deve essere completamente trasparente per le applicazioni.

Answer 4

Corretto - il modo più informativo per vedere questo sta usando Wireshark, uno strumento inestimabile. Prenditi il ​​tempo necessario per scoprirlo - mi ha salvato più volte e dà un buon controllo della realtà

Answer 5

Diversi segmenti di rete possono avere valori MTU diversi. In tal caso può verificarsi la frammentazione. Per ulteriori informazioni, vedere TCP Maximum segment size

Questa (de) frammentazione avviene nel livello TCP. Nel livello dell'applicazione non ci sono più pacchetti. TCP presenta un flusso di dati contigui all'applicazione.

Answer 6

A livello di applicazione ci sono un numero qualsiasi di motivi per cui l'intero 1500 byte non può mostrare una lettura. Vari fattori nel sistema operativo interno e nello stack TCP possono far sì che l'applicazione ottenga alcuni byte in una chiamata di lettura, e alcuni nella successiva. Sì, lo stack TCP deve riassemblare il pacchetto prima di inviarlo, ma ciò non significa che la tua app riuscirà a ottenere tutto in un colpo (è LICKELY lo otterrà in una lettura, ma non è GARANTITO a prendilo in una lettura).

TCP tenta di garantire la consegna in ordine di byte, con controllo degli errori, re-invia automaticamente, ecc. Pensala come una pipa a livello di app e non impantanarti troppo su come lo stack lo invia effettivamente sulla rete.

Answer 7

La frammentazione deve essere trasparente per un'applicazione TCP. Tieni presente che TCP è un protocollo di streaming: ottieni un flusso di dati, non pacchetti! Se si sta costruendo l'applicazione in base all'idea di pacchetti di dati completi, si avranno problemi a meno che non si aggiunga un livello di astrazione per assemblare interi pacchetti dallo stream e quindi passare i pacchetti all'applicazione.

Answer 8

Un "livello applicazione" un pacchetto TCP (beh, segmento veramente, il TCP a livello proprio non noto dai pacchetti) non è mai frammentato, poiché non esiste. Il livello dell'applicazione è il punto in cui i dati vengono visualizzati come un flusso di byte, consegnati in modo affidabile e in ordine.

Se ci stai pensando diversamente, probabilmente ti stai avvicinando a qualcosa nel modo sbagliato. Tuttavia, questo non vuol dire che potrebbe non esserci uno strato al di sopra di questa, ad esempio, una sequenza di messaggi recapitati su questo affidabile, in-order, da estendere.

Answer 9

La domanda presuppone che non sia vero: TCP non consegna i pacchetti ai suoi endpoint, piuttosto, invia un flusso di byte (ottetti). Se un'applicazione scrive due stringhe in TCP, può essere consegnata come una stringa all'altra estremità; allo stesso modo, una stringa può essere consegnata come due (o più) stringhe sull'altra estremità.

RFC 793, Sezione 1.5:

"Il TCP è in grado di trasferire un flusso continuo di ottetti in ogni direzione tra i suoi utenti imballaggio un numero di ottetti in segmenti per la trasmissione attraverso la sistema internet. "

Le parole chiave essendo flusso continuo di ottetti (byte).

RFC 793, Sezione 2.8:

"Non c'è alcuna relazione necessaria tra le funzioni push ei segmento confini I dati in un particolare segmento possono essere il risultato di una singola chiamata SEND , per intero. o parte o di più chiamate SEND. "

L'intera sezione 2.8 è pertinente.

Answer 10

This pagina è una buona fonte di informazioni su alcuni dei problemi che altri hanno sollevato, vale a dire la necessità di incapsulamento dei dati su un protocollo applicativo in base al protocollo applicativo Non abbastanza autorevole nel senso che descrivi ma ha esempi e è originario di alcuni grandi nomi nella programmazione di rete.