Per cominciare, un po' di contesto: il protocollo TCP prevede un concetto chiamato "dimensione massima del segmento" (MSS). Si tratta del segmento (di dati) più grande che lo stack TCP è in grado di accettare. Tale valore viene comunicato al peer remoto nel segmento SYN al momento dello stabilimento della connessione. La seguente decodifica del pacchetto 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 (in questo caso 2), 1 byte per la lunghezza totale dell'opzione (4) e il valore dell'opzione, in questo caso 5b4 esadecimale 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 stabilita con un host su una rete locale, STCP utilizza un valore pari a 1460. Una volta aggiunto tutto l'overhead del protocollo, si ottiene un frame Ethernet di 1518 byte, ovvero la dimensione massima consentita per un frame Ethernet. Per le connessioni stabilite con host su segmenti non locali, STCP utilizza un valore derivato dal parametro min_mss. L'utilizzo del valore predefinito di min_mss determinerà un valore MSS pari a 536. Questo valore rappresenta la dimensione minima che tutte le apparecchiature di rete basate su IP, ovvero i router, devono essere in grado di inoltrare senza frammentazione IP; la specifica che ha stabilito 536 come valore minimo è stata redatta nel 1983 nella RFC 879 – “The TCP Maximum Segment Size and related Topics”.
Oggi è probabile che tutti i vostri router siano in grado di gestire dimensioni maggiori. Potete quindi aumentare il valore minimo STCP da 536 a un valore più elevato. La domanda chiave è: di quanto aumentarlo? Il rischio di impostare un valore troppo elevato è la frammentazione. Lo scenario peggiore, ma anche il più facile da diagnosticare, è che il router scelga di scartare il segmento TCP invece di frammentarlo. In questo caso sarete in grado di stabilire una connessione, ma durante il trasferimento dei dati la connessione fallirà. Una traccia sull'host mittente mostrerà più ritrasmissioni di segmenti TCP di grandi dimensioni fino al timeout della connessione. La traccia potrebbe anche mostrare messaggi ICMP di destinazione irraggiungibile provenienti dal router che sta scartando il segmento. Se il router sceglie di frammentare il segmento, probabilmente assegnerà una bassa priorità al processo di frammentazione, il che potrebbe effettivamente comportare una riduzione della velocità effettiva. Inoltre, la probabilità di perdere il segmento a causa di danneggiamento o congestione aumenta con il numero di frammenti. Il modo più semplice per capire se questo è il caso è eseguire una traccia packet_monitor sul modulo. Se i segmenti TCP arrivano come frammenti, si sa che si è verificata la frammentazione.
I tre frame Ethernet seguenti rappresentano un segmento TCP frammentato in tre parti. Si può capire che il primo frame è un frammento perché il valore Flg/Frg è 2000. Il 2 indica che il bit «More Fragments» è impostato e lo 000 è l'offset del frammento; in questo caso, lo 0 indica che si tratta del primo frammento. Il monitor dei pacchetti contrassegna effettivamente i due frame 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 pari a 90, o più precisamente 0090. Poiché il bit More Fragments è 0, sappiamo che questo è l'ultimo frammento. Sappiamo che tutti questi frame appartengono allo stesso 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 questo viene applicato a tutte le connessioni TCP. Non è possibile aumentarlo solo per una o poche destinazioni. Pertanto, è necessario testare attentamente questa modifica per valutarne l'effetto su tutte le connessioni.
È possibile visualizzare il valore MSS corrente e modificarlo utilizzando i due comandi seguenti:
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, suggerisce che si tratti del valore MSS, ma in realtà corrisponde al valore MSS sommato alla lunghezza dell'intestazione TCP, pari a 20 byte. Nell'esempio sopra riportato, il valore di min_mss andrebbe impostato a 556+20, ovvero 576.
Quindi, quale miglioramento si può ottenere aumentando il valore MSS? Data la diffusione delle connessioni VPN, che aggiungono byte di overhead, non consiglio di impostare il valore massimo di 1480 (MSS TCP effettivo di 1460). Suggerisco un valore leggermente inferiore, ad esempio 1220 byte (MSS effettivo 1200). Supponendo di inviare 10 megabyte di dati utilizzando segmenti da 536 byte, saranno necessari 18657 frame; il numero totale di byte – compreso l'overhead (preambolo Ethernet di 8 byte + intestazione Ethernet di 14 byte + intestazione IP di 20 byte + intestazione TCP di 20 byte + trailer Ethernet di 4 byte + 12 byte effettivi per l'intervallo tra i 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 pari a 10.650.052, ovvero poco più del 9% in meno. Tuttavia, tieni presente che il valore MSS indica il segmento più grande che verrà accettato, ma non è obbligatorio che l'host mittente invii effettivamente segmenti di quelle dimensioni. Tuttavia, supponendo che lo faccia e che non ci siano altri colli di bottiglia, si ottiene un aumento del 9% nella velocità effettiva.
Possiamo fare qualcosa dal lato UDP?
Il protocollo UDP non prevede il concetto di dimensione massima del segmento, pertanto non esiste alcun parametro per regolarla.