Dimensione massima del pacchetto per una connessione TCP

197

Qual è la dimensione massima del pacchetto per una connessione TCP o come posso ottenere la dimensione massima del pacchetto?

networking  tcp 
— Alexa
fonte
24
TCP è basato su stream. C'è un motivo specifico per cui ti preoccupi dei singoli pacchetti?
— Matti Virkkunen,
27
Poiché i livelli sottostanti sono basati su pacchetti ... Implementazione tipica -> Livello 1 - Ethernet PHY, Livello 2 - Ethernet MAC (Definizione pacchetto MAC, Livello 3 - Protocollo Internet (Definizione pacchetto IP), Livello 4 - TCP (Protocollo controllo trasmissione ) - Utilizza il servizio basato su pacchetti al di sotto di esso.
2
Non esiste un "pacchetto TCP". Esistono segmenti TCP , la cui lunghezza è descritta da una parola a 32 bit, e sono contenuti all'interno o tra i pacchetti IP , la cui lunghezza è descritta in 16 bit. Ci sono anche frame Ethernet, che contengono tutte queste cose. Di quale di queste cose stai chiedendo? In ogni caso, se stai usando TCP, non devi preoccuparti di nessuno di loro in alcun modo: TCP e IP si occupano di tutto per te.
— Marchese di Lorne,

Risposte:

178

La limitazione assoluta sulla dimensione del pacchetto TCP è 64K (65535 byte), ma in pratica è molto più grande della dimensione di qualsiasi pacchetto che vedrai, perché gli strati inferiori (ad es. Ethernet) hanno dimensioni di pacchetto inferiori.

L'MTU (Maximum Transmission Unit) per Ethernet, ad esempio, è di 1500 byte. Alcuni tipi di reti (come Token Ring) hanno MTU più grandi e alcuni tipi hanno MTU più piccoli, ma i valori sono fissi per ogni tecnologia fisica.

— Etere
fonte
15
"Ma i valori sono fissi per ogni tecnologia fisica" - questo non è vero. Ethernet aveva un MTU massimo di 1500, ma potevi usarne uno inferiore. Con l'avvento dei frame jumbo, non esiste un limite massimo specificato e il massimo varia a seconda dell'hardware e del driver.
— WhirlWind
4
@Whirl: vero, sono configurabili, ma generalmente non lo sono; "configurabile" è soggettivo perché si dovrebbe scavare nel kernel per farlo. Non è qualcosa che si possa armeggiare a livello di applicazione, che è dove l'OP sembra essere.
— Ether
3
@HiroProtagonist: 1500 è un massimo, quindi avere 600 non è sorprendente.
— Nicolas Raoul,
30
perché è 64 K (65535 byte) la limitazione? Perché l'attributo Dimensioni finestra nell'intestazione TCP è solo 16 bit. Volevo solo menzionarlo, potrei aiutare qualcuno qualche volta ..... ottima risposta tra @Ether!
— Cacho Santa,
2
Inoltre, è possibile potenziarlo utilizzando il ridimensionamento delle finestre. In tal caso il massimo è 1 GiB
— Martin Melka,
86

Questa è un'eccellente domanda e mi ci imbatto molto al lavoro in realtà. Ci sono molte risposte "tecnicamente corrette" come 65k e 1500. Ho lavorato molto scrivendo interfacce di rete e usando 65k è stupido, e 1500 possono anche farti avere grossi problemi. Il mio lavoro si svolge su molti hardware / piattaforme / router diversi e, a dire il vero, il posto in cui inizio è di 1400 byte. Se hai BISOGNO di più di 1400 puoi iniziare a salire di livello, probabilmente puoi andare a 1450 e talvolta a 1480'ish? Se hai bisogno di più di quello, ovviamente devi dividere in 2 pacchetti, di cui ci sono diversi modi ovvi di fare ..

Il problema è che stai parlando di creare un pacchetto di dati e scriverlo via TCP, ma ovviamente ci sono dati di intestazione attaccati e così via, quindi hai un "bagaglio" che ti porta a 1500 o oltre .. e anche un molto hardware ha limiti inferiori.

Se lo "spingi" puoi ottenere alcune cose davvero strane. Dati troncati, ovviamente, o dati rilasciati che ho visto raramente. Anche i dati danneggiati raramente, ma certamente accadono.

— Nektarios
fonte
Perché le richieste GET hanno una media di circa 600 byte?
10
Intendi 64K, non 65K. Non so che cosa intendi con "il posto in cui inizio è 1400 byte". Non devi preoccuparti delle dimensioni dei pacchetti nell'API TCP. Si occupa di determinare e osservare il percorso MTU. Non c'è motivo per cui non puoi scrivere 2G in uno send()se è conveniente.
— Marchese di Lorne,
19
Il tuo 1480'ishdovrebbe essere 1460. L'intestazione IP e l'intestazione TCP occupano almeno 20 byte ciascuna (a meno che non vengano utilizzati campi di intestazione facoltativi) e quindi il massimo per Ethernet (non Jumbo frame) è 1500 - 20 -20 = 1460.
— Eugene Beresovsky,
2
Ho visto tramite WireShark che un server invia pacchetti di grandi dimensioni (oltre 1400 byte) e il client lo riceve smontato come pochi pacchetti di 1400 byte massimo. chi è responsabile dello smontaggio del pacchetto? @Nektario ...?
— Inbaly,
2
@EugeneBeresovsky bene con le intestazioni opzionali che è + fino a 40 byte in più, ma è variabile quindi 1420 sembrerebbe il limite. con il suggerimento del 1400 si ottiene una piccola imbottitura. andrò con 1408 poiché è divisibile per 128
— Garet Claborn il
22

A livello di applicazione, l'applicazione utilizza TCP come protocollo orientato al flusso. Il TCP a sua volta ha segmenti e estrae i dettagli dell'utilizzo di pacchetti IP inaffidabili.

TCP si occupa di segmenti anziché di pacchetti. Ogni segmento TCP ha un numero di sequenza contenuto in un'intestazione TCP. I dati effettivi inviati in un segmento TCP sono variabili.

C'è un valore per getockopt che è supportato su alcuni SO che puoi usare chiamato TCP_MAXSEG che recupera la dimensione massima del segmento TCP (MSS). Tuttavia, non è supportato su tutti i sistemi operativi.

Non sono sicuro di cosa stia cercando di fare, ma se si desidera ridurre le dimensioni del buffer utilizzato, è possibile esaminare anche: SO_SNDBUF e SO_RCVBUF.

— Brian R. Bondy
fonte
Mi chiedo se è possibile utilizzare TCP come coda di messaggi se è possibile adattare tutti i messaggi all'interno di un pacchetto TCP di grandi dimensioni?
— CMCDragonkai,
4

Non ci sono pacchetti nell'API TCP.

Ci sono pacchetti nei protocolli sottostanti spesso, come quando TCP è fatto su IP, a cui non ti interessa, perché non hanno nulla a che fare con l'utente, tranne per le ottimizzazioni delle prestazioni molto delicate che probabilmente non ti interessano (secondo la formulazione della domanda).

Se chiedi qual è il numero massimo di byte che puoi send()in una chiamata API, questo dipende dall'implementazione e dalle impostazioni. Solitamente chiameresti send () per blocchi di un massimo di diversi kilobyte e sarai sempre pronto affinché il sistema rifiuti di accettarlo totalmente o parzialmente, nel qual caso dovrai gestire manualmente la suddivisione in blocchi più piccoli per inserire i tuoi dati nel API TCP send ().

— Pavel Radzivilovsky
fonte
8
TCP ha pacchetti, nonché un'intestazione del pacchetto, parte del quale si sovrappone all'intestazione IP. Solo perché non dovresti vedere che non significa che non esiste. TCP viene sempre eseguito su IP. Non puoi farlo senza IP perché le intestazioni si sovrappongono.
— WhirlWind
23
@WhirlWind TCP ha segmenti. IP ha pacchetti.
— Marchese di Lorne,
1
TCP ha segmenti (o chiamali pacchetti, va bene). L'API TCP non ha pacchetti.
— Pavel Radzivilovsky,
13
@NathanLong Il danno è che causi inutili confusioni. TCP ha segmenti, UDP ha datagrammi, IP ha pacchetti, Ethernet ha frame, ...
— Marchese di Lorne il
1
@Chexxor Quindi quale lingua userai per descrivere i segmenti TCP all'interno dei pacchetti IP all'interno dei frame Ethernet? Non è necessario confondere il problema usando lo stesso termine per cose diverse, quando gli autori di queste cose hanno fatto molti problemi per usare termini diversi.
— Marchese di Lorne,
3

In generale, questo dipenderà dall'interfaccia utilizzata dalla connessione. Probabilmente puoi usare un ioctl () per ottenere l'MTU, e se è ethernet, di solito puoi ottenere la dimensione massima del pacchetto sottraendo la dimensione dell'intestazione hardware da quella, che è 14 per ethernet senza VLAN.

Questo è solo il caso se l'MTU è almeno così grande in tutta la rete. TCP può utilizzare il rilevamento MTU percorso per ridurre il valore MTU effettivo.

La domanda è: perché te ne importa?

— mulinello
fonte
6
Questo ti darà solo la dimensione massima del pacchetto sul primo link. Per quanto ne so, a qualsiasi altro nodo lungo il percorso è consentito non apprezzare i pacchetti di grandi dimensioni e potrebbe essere suddiviso in qualsiasi punto del percorso.
— Matti Virkkunen,
Sì, è vero ... quindi la tua domanda è buona - perché dovresti volerlo?
— WhirlWind
Voglio trasmettere video / immagini su una connessione LAN
— Alexa,
1
Poiché TCP è orientato al flusso, perché è importante?
— WhirlWind
3

Se utilizzi macchine Linux, "ifconfig eth0 mtu 9000 up" è il comando per impostare l'MTU per un'interfaccia. Tuttavia, devo dire che il grande MTU ha alcuni aspetti negativi se la trasmissione di rete non è così stabile e potrebbe usare più memorie nello spazio del kernel.

— DAG
fonte
3

Sembra che la maggior parte dei siti Web su Internet utilizzi 1460 byte per il valore di MTU. A volte è il 1452 e se sei su una VPN scenderà ancora di più per le intestazioni IPSec.

Le dimensioni predefinite della finestra variano fino a un massimo di 65535 byte. Uso http://tcpcheck.com per esaminare i miei valori IP di origine e per verificare quali altri fornitori di Internet stanno utilizzando.

— David McCulloch
fonte
2

Una soluzione può essere quella di impostare l'opzione socket TCP_MAXSEG ( http://linux.die.net/man/7/tcp ) su un valore "sicuro" con la rete sottostante (es. Impostato su 1400 per essere sicuro su Ethernet) e quindi utilizzare un buffer di grandi dimensioni nell'invio della chiamata di sistema. In questo modo ci possono essere meno chiamate di sistema che sono costose. Il kernel dividerà i dati in modo che corrispondano a MSS.

In questo modo è possibile evitare dati troncati e l'applicazione non deve preoccuparsi di piccoli buffer.

— hashtpaa
fonte
2

La dimensione del pacchetto per un'impostazione TCP nel protocollo IP (Ip4). Per questo campo (TL), sono allocati 16 bit, di conseguenza la dimensione massima del pacchetto è 65535 byte: dettagli del protocollo IP

— Ziegfried
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.