Primeiro um pequeno histórico, o TCP tem um conceito chamado tamanho máximo do segmento (MSS). Este é o maior segmento (de dados) que a pilha TCP aceitará. Ele é anunciado para o ponto remoto no segmento SYN quando a conexão é estabelecida. A seguinte decodificação do pacote mostra o segmento SYN com a opção TCP MSS destacada. Todas as opções TCP têm o mesmo formato, 1 byte para o número da opção, 2 neste caso, 1 byte para o comprimento total da opção (4) e o valor da opção, neste caso 5b4 hexadecimal ou 1460 decimal.
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
Para uma conexão feita a um host em uma rede local, a STCP usa um valor de 1460. Uma vez que você acrescenta em todas as despesas gerais de protocolo, você acaba com um quadro Ethernet de 1518 bytes - o tamanho máximo do quadro Ethernet. Para conexões feitas a hosts em segmentos não locais, o STCP usa um valor derivado do parâmetro min_mss. O uso do valor padrão min_mss resultará em um valor MSS de 536. Este valor é o tamanho mínimo que todos os equipamentos de rede baseados em IP, ou seja, roteadores devem estar dispostos a encaminhar sem fragmentação de IP, a especificação que estabeleceu 536 como mínimo foi escrita em 1983 na RFC 879 - "The TCP Maximum Segment Size and related Topics".
Hoje é provável que todos os seus roteadores possam lidar com um tamanho maior. Portanto, você pode elevar o mínimo STCP de 536 para algo maior. O quanto maior é a questão-chave. O perigo de torná-lo muito grande é a fragmentação. O pior cenário, mas o mais fácil de diagnosticar, é que o roteador optará por descartar o segmento TCP ao invés de fragmentá-lo. Neste caso, você será capaz de estabelecer uma conexão, mas ao transferir dados a conexão falhará. Um traço no host de envio mostrará múltiplas retransmissões de grandes segmentos TCP até que o tempo de conexão se esgote. O rastreamento também pode mostrar mensagens inalcançáveis de destino ICMP do roteador que está descartando o segmento. Se o roteador optar por fragmentar o segmento, provavelmente dará baixa prioridade ao processo de fragmentação, isto pode realmente resultar em uma redução da taxa de transferência. Também a probabilidade de perder o segmento devido a corrupção ou congestionamento aumenta com o número de fragmentos. A maneira mais fácil de saber se este é o caso é executando um rastreamento de monitor de pacotes no módulo. Se os segmentos TCP entrarem como fragmentos, você sabe que ocorreu fragmentação.
Os três quadros Ethernet seguintes representam um segmento TCP fragmentado em três partes. Pode-se dizer que o primeiro frame é um fragmento porque o valor Flg/Frg é 2000. O 2 indica que o bit Mais Fragmentos está definido e o 000 é o deslocamento do fragmento, neste caso 0 indica que é o primeiro fragmento. O monitor de pacotes na verdade sinaliza os próximos 2 quadros como fragmentos. O valor Flg/Frg no quadro 2 é 2048, novamente o 2 indica que o bit Mais Fragmentos está definido e o 48 é o offset (em múltiplos de 8 bytes) dos dados no datagrama IP original. O terceiro frame tem um Flg/Frag de apenas 90, ou mais precisamente 0090. Como o bit Mais Fragmentos é 0, sabemos que este é o último fragmento. Sabemos que todos estes frames pertencem juntos porque todos eles têm o mesmo valor de IP ID, 2e87. O comprimento dos dados no primeiro frame é uma indicação do valor MSS que deve ser definido, neste 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
O problema com o aumento do valor do MSS é que ele o aumenta para todas as conexões TCP. Não se pode aumentá-lo para apenas um ou alguns destinos. Portanto, você precisa testar cuidadosamente esta mudança para avaliar seu efeito em todas as suas conexões.
Você pode ver o valor atual do MSS e modificá-lo com os dois comandos a seguir:
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
O nome do parâmetro, min_mss, implica que é o valor MSS, mas é realmente o valor MSS mais o comprimento do cabeçalho TCP de 20 bytes. Para o exemplo acima, você definiria o valor min_mss como 556+20 ou 576.
Então, quanto de impulso você pode obter ao aumentar o valor do MSS? Devido à prevalência das conexões VPN que adicionam bytes de sobrecarga, não recomendo definir o valor máximo de 1480 (TCP MSS real de 1460). Eu sugiro algo um pouco menor, digamos 1220 (MSS 1200 real) bytes. Supondo que você esteja enviando 10 megabytes de dados usando segmentos de 536 bytes, serão necessários 18657 quadros, o número total de bytes - incluindo overhead (preâmbulo Ethernet de 8 bytes + cabeçalho Ethernet de 14 bytes + cabeçalho IP de 20 bytes + cabeçalho TCP de 20 bytes + reboque Ethernet de 4 bytes + um efetivo 12 bytes para o intervalo entre quadros Ethernet) será de 11.455.246 bytes. Se você estiver usando segmentos de 1200 bytes, serão necessários 8334 quadros com um número total de bytes 10.650.052 ou um pouco mais de 9% menor. Entretanto, tenha em mente que o valor do MSS é um anúncio do maior segmento que será aceito, não há nenhuma exigência de que o anfitrião remetente realmente envie segmentos tão grandes. Entretanto, supondo que sim e que não haja outros gargalos de garrafa, você acaba de receber uma bota de 9% na taxa de transferência.
Podemos fazer alguma coisa do lado da UDP?
A UDP não tem o conceito de tamanho máximo do segmento, portanto não há parâmetro para ajustá-lo.