Prima un po' di background, il TCP ha un concetto chiamato dimensione massima del segmento (MSS). Questo è il segmento più grande (di dati) che lo stack TCP accetterà. Viene pubblicizzato al peer remoto nel segmento SYN quando la connessione viene stabilita. La seguente decodifica dei pacchetti mostra il segmento SYN con l'opzione TCP MSS evidenziata. Tutte le opzioni TCP hanno lo stesso formato, 1 byte per il numero dell'opzione, 2 in questo caso, 1 byte per la lunghezza totale dell'opzione (4) e il valore dell'opzione, in questo caso 5b4 hex o 1460 decimale.
packet_monitor -interface #sdlmux.m16.11-3 -hex_dump -numeric -time_stamp -verbo +se -pkt_hdr -filter -host 10.64.77.50 dir icmp type + tcp hh:mm:ss.ttt dir len proto source destination src port ds +t port type 10:11:56.751 Xmit Ether Dst 00:23:54:52:18:6e Src 00:00:a8:43:52:22 Type 0800 +(IP) IP Ver/HL 45, ToS 0, Len 2c, ID be0b, Flg/Frg 0, TTL 3c, Prtl 6 Cksum dcdd, Src a404d80, Dst a404d32 TCP from 10.64.77.128.55911 to 10.64.77.50.telnet seq 1305537174, ack n.a., window 8192, 4 data bytes, flags Syn. X/Off 06, Flags 02, Cksum 815d, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0...4...8...C... 0 2 4 5 b4 <<<4
Per una connessione effettuata ad un host su una rete locale, STCP utilizza un valore di 1460. Una volta aggiunto tutto l'overhead del protocollo si ottiene un frame Ethernet di 1518 byte - la dimensione massima del frame Ethernet. Per le connessioni effettuate ad host su segmenti non locali, STCP usa un valore derivato dal parametro min_mss. Utilizzando il valore predefinito min_mss si ottiene un valore MSS di 536. Questo valore è la dimensione minima che tutte le apparecchiature di rete basate su IP, cioè i router devono essere disposti ad inoltrare senza frammentazione IP, la specifica che ha stabilito 536 come minimo è stata scritta nel 1983 in RFC 879 - "The TCP Maximum Segment Size and related Topics".
Oggi è probabile che tutti i vostri router siano in grado di gestire una dimensione maggiore. È quindi possibile aumentare il minimo STCP da 536 a qualcosa di più grande. Quanto più grande è la domanda chiave. Il pericolo nel renderlo troppo grande è la frammentazione. Lo scenario peggiore, ma il più facile da diagnosticare, è che il router scelga di scartare il segmento TCP invece di frammentarlo. In questo caso si sarà in grado di stabilire una connessione, ma quando si trasferiscono i dati la connessione si interrompe. Una traccia sull'host di invio mostrerà le ritrasmissioni multiple di segmenti TCP di grandi dimensioni fino al times out della connessione. La traccia può anche mostrare messaggi ICMP di destinazione irraggiungibili dal router che sta scartando il segmento. Se il router sceglie di frammentare il segmento, probabilmente darà al processo di frammentazione una bassa priorità, questo potrebbe in realtà comportare una riduzione della velocità di trasmissione. Anche la probabilità di perdere il segmento a causa di corruzione o congestione aumenta con il numero di frammenti. Il modo più semplice per capire se questo è il caso è quello di eseguire una traccia packet_monitor sul modulo. Se i segmenti TCP arrivano come frammenti si sa che si è verificata una frammentazione.
I seguenti tre frame Ethernet rappresentano un segmento TCP frammentato in tre parti. Si può dire che il primo frame è un frammento perché il valore Flg/Frg è 2000. Il 2 indica che il bit More Fragments è impostato e il 000 è l'offset del frammento, in questo caso 0 indica che è il primo frammento. Il Packet monitor in realtà segnala i 2 fotogrammi successivi come frammenti. Il valore Flg/Frg nel frame 2 è 2048, anche in questo caso il 2 indica che il bit More Fragments è impostato e il 48 è l'offset (in multipli di 8 byte) dei dati nel datagramma IP originale. Il terzo frame ha un Flg/Frag di soli 90, o più precisamente 0090. Poiché il bit More Fragments è 0 sappiamo che questo è l'ultimo frammento. Sappiamo che tutti questi frame appartengono tutti insieme perché hanno tutti lo stesso valore di ID IP, 2e87. La lunghezza dei dati nel primo frame è un'indicazione del valore MSS che dovrebbe essere impostato, in questo caso 556.
15:52:27.081 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2000, TTL 3f, Prtl 6 Cksum 1422, Src c0a86432, Dst a404d80 TCP from 192.168.100.50.32781 to 10.64.77.128.ftp-data seq 568258166, ack 840605671, window 5440, 556 data bytes, flags Ack. X/Off 05, Flags 10, Cksum d149, Urg-> 0000 offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 60 d a 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * <<12345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len 254, ID 2e87, Flg/Frg 2048, TTL 3f, Prtl 6 Cksum 13da, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments*, 576 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 10 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 20 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 30 39 30 d a 31 32 33 34 35 36 37 38 39 30 31 32 * 90<<123456789012 40 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 50 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 60 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 70 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456
15:52:33.793 Rcvd Ether Dst 00:00:a8:43:52:22 Src 00:12:3f:82:57:10 Type 0800 +(IP) IP Ver/HL 45, ToS 8, Len f8, ID 2e87, Flg/Frg 90, TTL 3f, Prtl 6 Cksum 34ee, Src c0a86432, Dst a404d80 TCP from 192.168.100.50. to 10.64.77.128. *fragments., 228 bytes data offset 0 . . . 4 . . . 8 . . . C . . . 0…4… 8…C… 0 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890 10 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 * 1234567890123456 20 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 * 7890123456789012 30 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 * 3456789012345678 40 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 50 35 36 37 38 39 30 d a 31 32 33 34 35 36 37 38 * 567890<<12345678 60 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 * 9012345678901234 70 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 * 5678901234567890
Il problema dell'aumento del valore MSS è che lo aumenta per tutte le connessioni TCP. Non è possibile aumentarlo solo per una o poche destinazioni. Pertanto è necessario testare attentamente questo cambiamento per valutarne l'effetto su tutte le connessioni.
Potete vedere il valore MSS attuale e modificarlo con i seguenti due comandi:
analyze_system -request_line 'list_stcp_params min_mss' -quitOpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
maximum tcp segment size [500-1480] (min_mss) 556
ready 10:52:07analyze_system -request_line 'set_stcp_param min_mss 1480' -quit OpenVOS Release 17.0.1as, analyze_system Release 17.0.1asCurrent process is 357, ptep 8FA86000, Noah_Davids.SysAdmin
Changing maximum tcp segment size (min_mss)from 556 to 1480ready 10:52:24
Il nome del parametro, min_mss, implica che è il valore MSS ma in realtà è il valore MSS più la lunghezza dell'intestazione TCP di 20 byte. Per l'esempio di cui sopra si dovrebbe impostare il valore min_mss a 556+20 o 576.
Quanto si può ottenere aumentando il valore MSS? A causa della prevalenza di connessioni VPN che aggiungono byte di overhead, non consiglio di impostare il valore massimo di 1480 (TCP MSS effettivo di 1460). Suggerisco qualcosa di un po' più piccolo, diciamo 1220 (MSS effettivi 1200) byte. Supponendo di inviare 10 megabyte di dati utilizzando segmenti da 536 byte, saranno necessari 18657 frame, il numero totale di byte - incluso l'overhead (8 byte Ethernet preambolo + 14 byte di intestazione Ethernet + 20 byte di intestazione IP + 20 byte di intestazione TCP + 4 byte di rimorchio Ethernet + 12 byte effettivi per il gap inter-frame Ethernet) sarà di 11.455.246 byte. Se si utilizzano segmenti da 1200 byte, saranno necessari 8334 frame con un numero totale di byte 10.650.052 o poco più del 9% in meno. Tuttavia, tenete presente che il valore MSS è una pubblicità del segmento più grande che verrà accettato, non è necessario che l'host di invio invii effettivamente segmenti così grandi. Tuttavia, supponendo che lo faccia e che non ci siano altri colli di bottiglia si ha appena ottenuto un boot del 9% nel throughput.
Possiamo fare qualcosa dal punto di vista dell'UDP?
L'UDP non ha il concetto di dimensione massima del segmento, quindi non c'è un parametro per regolarlo.