Primeiro, um pouco de contexto: o TCP tem um conceito chamado tamanho máximo de segmento (MSS). Esse é o maior segmento (de dados) que a pilha TCP aceitará. Ele é anunciado ao par remoto no segmento SYN quando a conexão é estabelecida. A decodificação do pacote a seguir 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 com um host em uma rede local, o STCP usa um valor de 1460. Depois de adicionar toda a sobrecarga do protocolo, você obtém um quadro Ethernet de 1518 bytes – o tamanho máximo do quadro Ethernet. Para conexões feitas com hosts em segmentos não locais, o STCP usa um valor derivado do parâmetro min_mss. Usar o valor padrão min_mss resultará em um valor MSS de 536. Esse 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 – “O tamanho máximo do segmento TCP e tópicos relacionados”.
Hoje em dia, é provável que todos os seus roteadores possam lidar com um tamanho maior. Portanto, você pode aumentar o mínimo do STCP de 536 para algo maior. A questão principal é quanto maior. O perigo de torná-lo muito grande é a fragmentação. O pior cenário, mas o mais fácil de diagnosticar, é que o roteador opte por descartar o segmento TCP em vez de fragmentá-lo. Nesse caso, você poderá estabelecer uma conexão, mas ao transferir dados, a conexão falhará. Um rastreamento no host de envio mostrará várias retransmissões de segmentos TCP grandes até que a conexão expire. O rastreamento também pode mostrar mensagens ICMP de destino inacessível do roteador que está descartando o segmento. Se o roteador optar por fragmentar o segmento, provavelmente dará ao processo de fragmentação uma prioridade baixa, o que pode resultar em uma redução na taxa de transferência. Além disso, 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 esse é o caso é executando um rastreamento packet_monitor no módulo. Se os segmentos TCP chegarem como fragmentos, você saberá que ocorreu fragmentação.
Os três quadros Ethernet a seguir representam um segmento TCP fragmentado em três partes. É possível identificar que o primeiro quadro é um fragmento porque o valor Flg/Frg é 2000. O 2 indica que o bit More Fragments está definido e o 000 é o deslocamento do fragmento; neste caso, 0 indica que é o primeiro fragmento. O monitor de pacotes realmente sinaliza os próximos dois quadros como fragmentos. O valor Flg/Frg no quadro 2 é 2048, novamente o 2 indica que o bit More Fragments está definido e o 48 é o deslocamento (em múltiplos de 8 bytes) dos dados no datagrama IP original. O terceiro quadro tem um Flg/Frag de apenas 90, ou mais precisamente 0090. Como o bit More Fragments é 0, sabemos que este é o último fragmento. Sabemos que todos esses quadros pertencem juntos porque todos têm o mesmo valor de IP ID, 2e87. O comprimento dos dados no primeiro quadro é 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 de aumentar o valor MSS é que ele aumenta para todas as conexões TCP. Não é possível aumentá-lo para apenas um ou alguns destinos. Portanto, é necessário testar cuidadosamente essa alteração para avaliar seu efeito em todas as suas conexões.
Você pode ver o valor atual do MSS e alterá-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 na verdade é 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, qual é o aumento que você pode obter ao aumentar o valor do MSS? Devido à prevalência de conexões VPN, que adicionam bytes de sobrecarga, não recomendo definir o valor máximo de 1480 (MSS TCP real de 1460). Sugiro algo um pouco menor, digamos 1220 (MSS real de 1200) bytes. Supondo que você esteja enviando 10 megabytes de dados usando segmentos de 536 bytes, serão necessários 18657 quadros, número total de bytes – incluindo sobrecarga (preâmbulo Ethernet de 8 bytes + cabeçalho Ethernet de 14 bytes + cabeçalho IP de 20 bytes + cabeçalho TCP de 20 bytes + trailer Ethernet de 4 bytes + 12 bytes efetivos 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 de 10.650.052, ou um pouco mais de 9% menor. No entanto, tenha em mente que o valor MSS é uma indicação do maior segmento que será aceito, não há exigência de que o host de envio realmente envie segmentos tão grandes. No entanto, supondo que ele o faça e que não haja outros gargalos, você acaba de obter um aumento de 9% na taxa de transferência.
Podemos fazer alguma coisa no lado do UDP?
O UDP não possui o conceito de tamanho máximo de segmento, portanto, não há parâmetro para ajustá-lo.