Resumo

  • A opção MSS no SYN informa a maior carga TCP que quem a enviou aceita receber; cada direção tem seu próprio teto e nenhum mecanismo escolhe um valor comum.
  • O emissor combina o teto remoto com o tamanho permitido por IP e desconta as opções realmente presentes em cada pacote para obter seu limite efetivo.
  • MSS não é MTU do caminho, janela de recepção, moldura da aplicação nem previsão do tamanho de todos os segmentos observados.

O anúncio atravessava a conexão

O RFC 793 definiu Maximum Segment Size como a opção TCP tipo 2, comprimento 4. Seus 16 bits comunicavam o máximo de recepção do TCP que enviava o segmento com SYN. A posição no handshake convidava a palavra “negociação”, mas a direção dizia outra coisa.

Se A anuncia 1460, B não deve enviar a A uma carga TCP maior que 1460. Se B anuncia 1200 no SYN-ACK, esse segundo número limita A→B. Os valores podem divergir porque memória, interfaces e políticas divergem. Não há uma rodada que compare propostas e produza um vencedor.

O RFC 879 tornou essa distinção explícita em 1983: MSS era um announcement, frequentemente chamado por engano de negotiation. O protocolo não pede que uma ponta fale pela capacidade da outra. Cada receptor declara apenas o limite sob seu controle.

Uma coluna operacional “MSS negociado” apaga essa procedência. Sem autor e direção, 1460 pode ser aplicado ao fluxo errado, e uma assimetria legítima pode parecer defeito.

A conta histórica do 536

O mínimo IPv4 de recepção e remontagem era um datagrama de 576 octetos. Subtraindo 20 do cabeçalho IPv4 fixo e 20 do TCP fixo, sobravam 536 octetos de dados TCP. RFC 879 esclareceu que MSS conta dados, não cabeçalhos.

SYN e FIN ocupam posições no espaço de sequência, mas não entram nessa contagem. A carga de dados, o segmento completo e o avanço da sequência são grandezas relacionadas, não intercambiáveis.

O RFC 1122 exigiu suporte ao envio e recebimento da opção. Se ela não chegasse no estabelecimento, o emissor aplicaria 536. O atual RFC 9293 preserva 536 para IPv4 e define 1220 para IPv6, partindo do mínimo 1280 menos 40 de IPv6 e 20 de TCP.

Ausência da opção não significa capacidade ilimitada. O padrão conservador preenche uma lacuna. Também não mede o caminho atual: 536 e 1220 não são metas universais de desempenho.

O emissor ainda precisava fazer a própria conta

RFC 1122 e RFC 9293 separam o SendMSS recebido do MSS efetivo de envio. Este deve obedecer ao menor limite entre a capacidade de recepção remota e o maior tamanho que IP permite transmitir, considerando os cabeçalhos do pacote.

O receptor pode aceitar 9000 sem que o caminho transporte o datagrama. Um caminho amplo pode aceitar 9000 sem autorizar o emissor a ultrapassar os 1200 declarados pelo receptor. A primeira evidência pertence ao host; a segunda, ao contexto de rede.

Path MTU Discovery estuda como o emissor revisa o limite do caminho usando mensagens e sondas. MSS fornece a outra entrada do cálculo. O artigo existente sobre PMTUD tratou a adaptação ao elo estreito e excluiu um tutorial de MSS; aqui o objeto é a declaração direcional do destino.

Segmentos reais podem ser menores por dados insuficientes, janelas, congestionamento, retransmissões, opções ou agendamento. Um payload pequeno não comprova sozinho um clamp nem revela a intenção de quem anunciou MSS.

Cabeçalho variável não cabia numa promessa fixa

Opções IP e TCP variam entre pacotes. Durante anos, implementações discutiram se o receptor deveria descontar antecipadamente todos os bytes que talvez aparecessem. O RFC 6691 colocou a responsabilidade onde estava o conhecimento.

O valor anunciado deve subtrair apenas os cabeçalhos fixos de IP e TCP do MTU efetivo. Ao construir um pacote real, o emissor reduz os dados pelo tamanho das opções realmente incluídas. O receptor no SYN não conhece as combinações futuras; um valor fixo tampouco as representa.

Se o receptor reservar espaço e o emissor descontar de novo, os pacotes ficam curtos demais. Se ninguém descontar, ficam longos demais e podem fragmentar ou cair. A conta correta acontece uma vez, por quem conhece o pacote presente.

RFC 6691 rejeitou a premissa de um exemplo antigo do RFC 879 que retirava diretamente uma opção IP Security do MSS anunciado. Uma errata verificou o alinhamento aritmético daquele exemplo, mas a regra posterior mostrou que a subtração estava na etapa errada. RFC 9293 consolidou a regra atual.

Uma errata proposta ao RFC 1122 alegou dupla subtração de opções IP. Ela foi rejeitada; as notas distinguem espaço reservado pelo próprio IP e opções fornecidas por TCP. O status faz parte da evidência.

Ser conservador demais também deixa rastro

RFC 6691 alerta que um MSS baixo pode impedir que PMTUD aproveite um caminho maior. A conexão funciona, porém com mais pacotes e mais overhead. Uma mitigação silenciosa pode virar perda permanente de capacidade.

Já interfaces com MTU variável não devem anunciar apenas o melhor caso. Compressão de cabeçalhos pode voltar temporariamente ao formato completo para resincronizar, inclusive numa retransmissão. O documento recomenda usar o menor MTU efetivo para produzir um limite repetível.

Nos jumbogramas IPv6, o valor 65535 é tratado como infinito, e PMTUD determina o máximo real. É um escape do campo de 16 bits, não uma prova de caminho infinito.

Registro não é captura

O registro TCP da IANA mantém tipo 2, comprimento 4, como Maximum Segment Size e referencia RFC 9293. Isso preserva a gramática. Não revela valores de sistemas, reescritas intermediárias, MTU ou entrega.

RFC 9293 substituiu RFC 793, 879 e 6691 e os requisitos TCP de RFC 1122. A consolidação manteve a arquitetura: o receptor fala de si; o emissor combina a fala com IP; o custo variável fica com quem monta cada pacote.

MSS é um teto com origem e direção. Guardar dois anúncios e dois cálculos efetivos é mais fiel que inventar um único acordo.

Essa disciplina também impede uma inferência comum em retrospecto: dois valores iguais não provam caminho simétrico, buffers idênticos ou uma negociação bem-sucedida. Podem apenas refletir a mesma convenção local em dois sistemas diferentes.

Fontes e limites

As fontes provam especificações, revisões e registro. Não medem adoção, defaults atuais, frequência de clamp, capacidade de uma rota ou causa de um incidente.