Quanto A Arquitetura Tcp/ip Assinale A Alternativa Que Apresenta

Arquitetura TCP/IP: o que realmente importa na prática

Quanto a arquitetura TCP/IP, a maioria dos materiais didáticos apresenta isso como um conjunto de camadas bonitas e bem separadas. A realidade é mais bagunçada. O modelo TCP/IP original da RFC 1122 tem quatro camadas, mas hoje em dia as pessoas falam de cinco, sete, ou às vezes não falam de camada nenhuma e vão direto para o que funciona. Se você está estudando para prova, preste atenção no que a banca quer. Se você vai implementar algo que precisa sobreviver, o modelo teórico é útil mas insuficiente. Em questões de concurso ou certificação, a pergunta costuma buscar três coisas: a ordem das camadas, o protocolo emblemático de cada nível, e a capacidade de distinguir entre transporte orientado a conexão e não orientado. A alternativa correta normalmente é aquela que coloca TCP na camada de transporte, IP na camada de internet, e reconhece que a camada de enlace lida com quadros e endereçamento MAC. Eu já vi gente errar porque a banca mistura o modelo OSI com o TCP/IP de propósito. Isso é armadilha clássica. O modelo OSI tem sete camadas. O TCP/IP tem quatro. Se a questão fala em "camada de sessão" ou "camada de apresentação" no contexto TCP/IP, a resposta provavelmente é essa combinação errada. A camada de aplicação no TCP/IP engloba o que o OSI separou em três camadas diferentes. Não tente encaixar sessões e apresentação onde elas não existem.

Outro ponto que as bancas adoram cobrar é a diferença entre o conceito de pacote, segmento, frame e bit. Cada camada tem seu PDU (Protocol Data Unit). Na rede, você tem pacotes IP. No transporte, segmentos TCP ou datagramas UDP. No enlace, quadros Ethernet. Se a alternativa confundir esses nomes, desconfie. Um caso que me marcou foi quando precisei debugar uma aplicação que transmitia dados corretamente na minha máquina mas falhava em outra rede. O problema era MSS (Maximum Segment Size). A caixa de entrada do roteador tinha um MTU menor que o padrão 1500, e o TCP estava enviando segmentos que precisavam ser fragmentados. A fragmentação IP não era permitida pelo caminho. A solução foi ajustar o MSS via `tcp_mss_clamp` no Linux para forçar um tamanho compatível com o caminho. Isso é algo que nenhum material didático ensina, mas aparece em produção todo dia. O que poucos entendem sobre a arquitetura TCP/IP é que a camada de internet é puramente best-effort. O IP não garante entrega, não ordena pacotes, não verifica integridade além do header checksum. Tudo isso fica para o TCP ou para a aplicação. Se uma alternativa disser que o IP garante confiabilidade, está errada. E se disser que o IP faz controle de fluxo, também está errada. Controle de fluxo e correção de erros são funções do transporte, não da rede.

Outro ponto contra-intuitivo: a arquitetura TCP/IP original não definia uma camada física. A RFC fala explicitamente que o modelo é agnóstico em relação à tecnologia de enlace e física. Então questões que colocam "cabo de fibra" ou "WiFi" como camadas distintas dentro do TCP/IP estão confundindo o modelo com o OSI ou com implementações específicas. Na prática, se você precisa escolher uma alternativa sobre arquitetura TCP/IP, procure a que menciona: (1) TCP e UDP na camada de transporte, (2) IP na camada de internet, (3) a capacidade de múltiplos protocolos de enlace coexistirem, e (4) a natureza connectionless do IP. Qualquer alternativa que atribua confiabilidade ao IP, que separe sessão e apresentação, ou que trate física como camada do modelo TCP/IP, é a errada. O modelo segue um princípio simples que as bancas gostam de testar: cada camada fornece serviços para a camada acima e recebe serviços da camada abaixo. A camada de rede fornece roteamento e endereçamento lógico. A de transporte fornece confiabilidade opcional. A de enlace fornece entrega hop-a-hop. A de aplicação é tudo que não se encaixa nos outros níveis. Se a alternativa inverter essa dependência, está errada.