![\"qual](\"https:\/\/statics.mylandingpages.co\/static\/aaanxdmf26c522mpaaaaz2wwe7ppkact\/image\/6654503b3b3848aabb05893278d4fce6.webp\")
<\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
A camada de transporte utiliza um espec\u00edfico unidade de dados de protocolo<\/a> para gerenciar a comunica\u00e7\u00e3o de ponta a ponta. Ao usar o Transmission Control Protocol (TCP), esta unidade \u00e9 conhecida como Segmento. Por outro lado, o User Datagram Protocol (UDP) emprega um datagrama. Estas unidades distintas facilitam a troca de dados entre redes. Por exemplo, o TCP \u00e9 respons\u00e1vel por aproximadamente 55% de tr\u00e1fego em redes m\u00f3veis, enquanto o UDP compreende cerca de 45%<\/a>. \u00c9 importante distinguir este termo de rede de um Distribui\u00e7\u00e3o de energia Unidade<\/a>, que desempenha uma fun\u00e7\u00e3o diferente em sistemas el\u00e9tricos.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/ul>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n A camada de transporte ocupa uma posi\u00e7\u00e3o crucial na arquitetura de rede. No modelo Open Systems Interconnection (OSI), ele reside na Camada 4, diretamente acima da camada de rede e abaixo da camada de sess\u00e3o. Da mesma forma, no modelo TCP\/IP implementado mais amplamente, a camada de transporte fica entre a camada de Internet e a camada de aplica\u00e7\u00e3o. Esse posicionamento permite preencher a lacuna entre a entrega de dados no n\u00edvel da rede e a comunica\u00e7\u00e3o espec\u00edfica do aplicativo.<\/p>\n <\/p>\n <\/p>\n A camada de transporte assume responsabilidades significativas para garantir uma comunica\u00e7\u00e3o ponta a ponta eficaz entre aplica\u00e7\u00f5es executadas em hosts diferentes. Ele suporta entrega processo a processo<\/a>, permitindo que v\u00e1rios aplicativos compartilhem uma \u00fanica conex\u00e3o de rede. Esta camada executa multiplexa\u00e7\u00e3o e demultiplexa\u00e7\u00e3o, usando n\u00fameros de porta<\/a> para direcionar os dados para o processo de inscri\u00e7\u00e3o correto. Tamb\u00e9m divide os dados das camadas superiores em segmentos (para TCP) ou datagramas (para UDP) e adiciona os cabe\u00e7alhos necess\u00e1rios. Al\u00e9m disso, a camada de transporte lida com detec\u00e7\u00e3o de erros, retransmiss\u00e3o e sequenciamento para manter uma comunica\u00e7\u00e3o confi\u00e1vel. Ele coordena o controle de fluxo para evitar que o receptor fique sobrecarregado, gerenciando as taxas de transmiss\u00e3o de dados para evitar que um remetente r\u00e1pido sobrecarregue o buffer de dados do receptor.<\/p>\n <\/p>\n <\/p>\n <\/p>\n A Unidade de dados de protocolo (PDU)<\/a> representa a unidade fundamental de troca entre entidades que se comunicam atrav\u00e9s de um protocolo de rede espec\u00edfico. Os profissionais de rede utilizam PDUs ao trabalhar com pilhas de protocolos multicamadas e gerenciar intera\u00e7\u00f5es de protocolo. Os protocolos de rede, especialmente aqueles desenvolvidos em modelos de refer\u00eancia em camadas, como os modelos OSI ou TCP\/IP, definem suas unidades de troca de dados. Por exemplo, um pacote serve como PDU para IP, que rege as intera\u00e7\u00f5es entre hosts identificados por endere\u00e7os IP na camada de rede. As PDUs normalmente consistem em um cabe\u00e7alho de protocolo, contendo dados espec\u00edficos, como endere\u00e7os de destino e origem, e uma carga \u00fatil, que \u00e9 a informa\u00e7\u00e3o real transmitida.<\/p>\n <\/p>\n <\/p>\n A camada de transporte requer seu pr\u00f3prio unidade de dados de protocolo espec\u00edfica<\/a> para gerenciar as complexidades da comunica\u00e7\u00e3o processo a processo. Ao contr\u00e1rio da camada de rede, que se concentra na entrega de host para host, a camada de transporte deve garantir que os dados cheguem \u00e0 aplica\u00e7\u00e3o correta nesse host. Isto requer informa\u00e7\u00f5es adicionais dentro da PDU, como n\u00fameros de porta, para identificar aplica\u00e7\u00f5es espec\u00edficas. A PDU tamb\u00e9m carrega informa\u00e7\u00f5es de confiabilidade, controle de fluxo e gerenciamento de conex\u00e3o, dependendo do protocolo de transporte escolhido.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Um segmento TCP representa a unidade fundamental de transmiss\u00e3o de dados dentro do Protocolo de Controle de Transmiss\u00e3o. Cada segmento consiste em um cabe\u00e7alho e uma carga \u00fatil. O cabe\u00e7alho carrega metadados essenciais para transmiss\u00e3o. Seu tamanho normalmente varia de 20 bytes a um m\u00e1ximo de 60 bytes se campos opcionais, como carimbos de data\/hora ou confirma\u00e7\u00f5es seletivas, forem inclu\u00eddos. O Tamanho M\u00e1ximo do Segmento (MSS) define a maior quantidade de dados, excluindo o cabe\u00e7alho, que um segmento TCP pode transportar. Este \u00e9 um conceito da Camada 4 influenciado diretamente pela Unidade M\u00e1xima de Transmiss\u00e3o (MTU) da rede subjacente da Camada 2. Os engenheiros de rede calculam o MSS como <\/p>\n <\/p>\n O objetivo principal do segmento TCP unidade de dados de protocolo<\/a> \u00e9 fornecer confi\u00e1vel, ordenado e corrigido por erros<\/a> transmiss\u00e3o de dados entre aplicativos. Ele organiza dados para transmiss\u00e3o segura entre um servidor e um cliente. Isso garante a integridade dos dados, independentemente da quantidade de informa\u00e7\u00f5es trocadas. O segmento TCP garante que os dados sejam recebidos sem erros e na ordem correta<\/a> por meio de mecanismos como detec\u00e7\u00e3o de erros, retransmiss\u00e3o de pacotes e sequenciamento.<\/p>\n <\/p>\n <\/p>\n <\/p>\n O cabe\u00e7alho do segmento TCP inclui campos cruciais para identificar as aplica\u00e7\u00f5es em comunica\u00e7\u00e3o. UM Porta de origem de 16 bits<\/a> campo identifica o n\u00famero da porta do aplicativo do remetente. Da mesma forma, um Campo Porta de destino de 16 bits<\/a> identifica o n\u00famero da porta do aplicativo do receptor. Esses n\u00fameros de porta permitem multiplexa\u00e7\u00e3o e demultiplexa\u00e7\u00e3o, garantindo que os dados cheguem ao processo correto no host de destino.<\/p>\n <\/p>\n <\/p>\n Os n\u00fameros de sequ\u00eancia s\u00e3o vitais para a entrega solicitada. UM Campo N\u00famero de sequ\u00eancia de 32 bits<\/a> atribui um n\u00famero exclusivo a cada byte de dados. Este n\u00famero indica o n\u00famero do byte do primeiro byte no segmento. Ajuda a remontar segmentos fora de ordem. O Campo N\u00famero de confirma\u00e7\u00e3o de 32 bits<\/a> indica o pr\u00f3ximo n\u00famero de sequ\u00eancia esperado do remetente. Isto confirma o recebimento dos bytes anteriores e est\u00e1 presente quando o sinalizador ACK \u00e9 definido.<\/p>\n <\/p>\n <\/p>\n O cabe\u00e7alho TCP cont\u00e9m v\u00e1rios sinalizadores de controle, cada um servindo uma fun\u00e7\u00e3o espec\u00edfica. Estes incluem:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/ul>\n <\/p>\n <\/p>\n <\/p>\n O TCP garante uma transfer\u00eancia confi\u00e1vel de dados por meio de uma combina\u00e7\u00e3o de confirma\u00e7\u00f5es, tempos limite e mecanismos de retransmiss\u00e3o. Cada segmento inclui um campo de soma de verifica\u00e7\u00e3o para detectar corrup\u00e7\u00e3o. Se um segmento estiver corrompido, o TCP de destino o descarta, tratando-o como perdido. O TCP usa confirma\u00e7\u00f5es para confirmar a entrega bem-sucedida de segmentos de dados. Segmentos ausentes, atrasados \u200b\u200bou corrompidos s\u00e3o retransmitidos. Isso ocorre quando o remetente recebe tr\u00eas confirma\u00e7\u00f5es duplicadas, conhecidas como Retransmiss\u00e3o r\u00e1pida<\/a>, ou quando um temporizador de retransmiss\u00e3o expira, conhecido como Retransmiss\u00e3o ap\u00f3s RTO. Protocolos em pipeline como Go-Back-N e repeti\u00e7\u00e3o seletiva<\/a> tamb\u00e9m lida com dados perdidos ou corrompidos e pacotes de confirma\u00e7\u00e3o, aumentando ainda mais a confiabilidade.<\/p>\n <\/p>\n <\/p>\n O TCP emprega mecanismos sofisticados para controle de fluxo e gerenciamento de congestionamento. O controle de fluxo limita o n\u00famero de segmentos n\u00e3o confirmados com base no tamanho da janela de recep\u00e7\u00e3o anunciada (RWND) do receptor. Os dados m\u00e1ximos em voo s\u00e3o os m\u00ednimos do RWND e da janela de congestionamento (CWND). Para gerenciamento de congestionamento, o TCP usa um algoritmo de controle de congestionamento<\/a> incorporando Aumento-Aditivo\/Diminui\u00e7\u00e3o-Multiplicativo (AIMD)<\/a> e in\u00edcio lento. A janela de congestionamento (CWND) regula a taxa de envio, limitando o n\u00famero total de pacotes n\u00e3o reconhecidos em tr\u00e2nsito. O in\u00edcio lento ajuda os fluxos TCP a atingirem rapidamente a capacidade do link, aumentando exponencialmente o CWND. Uma vez atingido um limite de in\u00edcio lento, o fluxo passa a evitar congestionamentos e o AIMD assume o controle, levando a um crescimento linear do CWND.<\/p>\n <\/p>\n <\/p>\n Os segmentos TCP facilitam o estabelecimento da conex\u00e3o por meio de um handshake triplo. Um cliente inicia uma abertura ativa enviando um segmento SYN com seu n\u00famero de sequ\u00eancia inicial. O servidor reconhece o SYN do cliente e envia seu pr\u00f3prio SYN em um \u00fanico segmento. Por fim, o cliente reconhece o SYN do servidor, estabelecendo a conex\u00e3o. O t\u00e9rmino da conex\u00e3o envolve um aperto de m\u00e3o de quatro vias<\/a>. Um aplicativo realiza um fechamento ativo enviando um segmento FIN, indicando que n\u00e3o h\u00e1 mais dados para enviar. A outra extremidade recebe o FIN, reconhece-o e passa um fim de arquivo para sua aplica\u00e7\u00e3o. Posteriormente, esse aplicativo fecha seu soquete, fazendo com que seu TCP envie um FIN. O sistema que executou o fechamento ativo recebe e reconhece este FIN final, concluindo o encerramento.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Um datagrama UDP representa um protocolo de camada de transporte simples e orientado a mensagens<\/a>. Inclui verifica\u00e7\u00e3o de integridade por meio de uma soma de verifica\u00e7\u00e3o para o cabe\u00e7alho e a carga \u00fatil. No entanto, n\u00e3o oferece garantias de entrega de mensagens ao protocolo da camada superior. A camada UDP n\u00e3o ret\u00e9m nenhum estado das mensagens depois de envi\u00e1-las, levando \u00e0 sua designa\u00e7\u00e3o ocasional como 'Protocolo de Datagrama N\u00e3o Confi\u00e1vel'. Qualquer confiabilidade de transmiss\u00e3o desejada deve ser implementada no n\u00edvel da aplica\u00e7\u00e3o.<\/p>\n <\/p>\n Os datagramas UDP possuem v\u00e1rias caracter\u00edsticas principais:<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/ul>\n <\/p>\n <\/p>\n O User Datagram Protocol (UDP) serve como um protocolo de comunica\u00e7\u00e3o escolhido especificamente para aplica\u00e7\u00f5es sens\u00edveis ao tempo. Estes incluem jogos, reprodu\u00e7\u00e3o de v\u00eddeo ou pesquisas de Sistema de Nomes de Dom\u00ednio (DNS)<\/a>. Sua comunica\u00e7\u00e3o mais r\u00e1pida decorre de n\u00e3o perder tempo formando uma conex\u00e3o firme com o destino antes de transferir os dados. UDP \u00e9 usado principalmente para estabelecer conex\u00f5es de baixa lat\u00eancia e toler\u00e2ncia a perdas<\/a> entre aplicativos na internet. Ele prioriza a velocidade, permitindo a transfer\u00eancia de dados antes que a parte receptora forne\u00e7a um acordo. Isso o torna ben\u00e9fico para comunica\u00e7\u00f5es urgentes, como VoIP, pesquisas de DNS e reprodu\u00e7\u00e3o de v\u00eddeo ou \u00e1udio.<\/p>\n <\/p>\n <\/p>\n <\/p>\n O cabe\u00e7alho do datagrama UDP cont\u00e9m campos essenciais para identificar as aplica\u00e7\u00f5es em comunica\u00e7\u00e3o. UM O campo Porta de Origem identifica a porta do remetente<\/a> quando presente. Se n\u00e3o for usado, ser\u00e1 definido como zero. O campo Porta de Destino identifica a porta do receptor e \u00e9 um campo obrigat\u00f3rio. Esses n\u00fameros de porta permitem que a camada de transporte direcione o datagrama para o processo de aplica\u00e7\u00e3o correto no host de destino.<\/p>\n <\/p>\n <\/p>\n O campo Comprimento especifica o comprimento total do cabe\u00e7alho UDP e dos dados em bytes. O comprimento m\u00ednimo \u00e9 de 8 bytes, que \u00e9 o tamanho do pr\u00f3prio cabe\u00e7alho. O m\u00e1ximo te\u00f3rico \u00e9 65.535 bytes, mas IPv4 limita o comprimento dos dados a 65.507 bytes<\/a>. Para jumbogramas IPv6, o campo de comprimento ser\u00e1 zero se o comprimento total exceder 65.535 bytes. O campo Checksum pode ser usado para verifica\u00e7\u00e3o de erros. \u00c9 opcional no IPv4 e obrigat\u00f3rio na maioria dos casos no IPv6. Se n\u00e3o for utilizado, cont\u00e9m todos os zeros.<\/p>\n <\/p>\n <\/p>\n <\/p>\n O UDP permite a comunica\u00e7\u00e3o sem conex\u00e3o, permitindo que os remetentes transmitam pacotes de dados (datagramas) diretamente aos destinat\u00e1rios. Isso \u00e9 feito sem primeiro estabelecer uma conex\u00e3o dedicada ou realizar um handshake. Isso significa que nenhuma confirma\u00e7\u00e3o \u00e9 necess\u00e1ria, facilitando o fluxo de dados ininterrupto. UDPs sobrecarga m\u00ednima<\/a> decorre de v\u00e1rias op\u00e7\u00f5es de design. Ele usa uma estrutura de pacote simples, que reduz o tempo de processamento e os recursos necess\u00e1rios tanto para o remetente quanto para o destinat\u00e1rio. Ao contr\u00e1rio do TCP, o UDP n\u00e3o implementa controle de fluxo para regular as taxas de transfer\u00eancia de dados. Tamb\u00e9m carece de recupera\u00e7\u00e3o de erros; O UDP n\u00e3o retransmite pacotes perdidos nem trata da corre\u00e7\u00e3o de erros. Os aplicativos que usam UDP s\u00e3o respons\u00e1veis \u200b\u200bpor gerenciar a integridade dos dados e retransmiss\u00f5es, se necess\u00e1rio. Esta omiss\u00e3o de mecanismos de confiabilidade torna o UDP mais r\u00e1pido e simples.<\/p>\n <\/p>\n <\/p>\n O UDP \u00e9 um protocolo sem conex\u00e3o que prioriza a velocidade<\/a>. N\u00e3o estabelece conex\u00e3o formal nem verifica o recebimento de dados. Ele simplesmente envia dados como datagramas individuais sem aperto de m\u00e3o, semelhante ao envio de um cart\u00e3o postal. Essa abordagem leva a uma entrega n\u00e3o confi\u00e1vel, pois n\u00e3o garante a entrega, o pedido ou a corre\u00e7\u00e3o de erros. Ao considerar velocidade versus confiabilidade, datagramas menores s\u00e3o mais confi\u00e1veis, pois t\u00eam menos probabilidade de serem perdidos, corrompidos ou reordenados<\/a>. Eles tamb\u00e9m s\u00e3o menos propensos a fragmenta\u00e7\u00e3o, quedas ou atrasos. Datagramas maiores s\u00e3o mais eficientes e r\u00e1pidos devido ao transporte de mais carga \u00fatil por unidade a\u00e9rea, o que reduz a contagem de pacotes e a carga de processamento. No entanto, datagramas maiores s\u00e3o menos confi\u00e1veis, pois s\u00e3o mais propensos a perdas, corrup\u00e7\u00e3o, reordenamento, congestionamento de rede, lat\u00eancia e instabilidade. Eles tamb\u00e9m consomem mais largura de banda e recursos.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Segmentos TCP e datagramas UDP apresentam diferen\u00e7as fundamentais de design<\/a>, impactando diretamente sua confiabilidade, velocidade e sobrecarga. Prioridades TCP integridade de dados garantida<\/a>. Ele garante a entrega confi\u00e1vel de dados e retransmite dados perdidos. O TCP usa n\u00fameros de sequ\u00eancia para garantir a remontagem dos dados na ordem correta. Ele executa verifica\u00e7\u00e3o robusta de erros com somas de verifica\u00e7\u00e3o no cabe\u00e7alho e nos dados. Al\u00e9m disso, o TCP incorpora mecanismos integrados para evitar o congestionamento da rede. Por outro lado, o UDP n\u00e3o rastreia nem reenvia pacotes, levando a uma potencial perda de dados. Ele tamb\u00e9m n\u00e3o consegue rastrear ou reordenar os dados, o que pode ser problem\u00e1tico para o processamento sequencial. O UDP carece de mecanismos para desacelerar a transmiss\u00e3o durante congestionamentos.<\/p>\n <\/p>\n Os recursos abrangentes do TCP contribuem para maior lat\u00eancia devido ao seu handshake de tr\u00eas vias e reconhecimentos constantes. Tamb\u00e9m incorre em maior sobrecarga com um cabe\u00e7alho maior de 20 a 60 bytes<\/a>, consumindo mais largura de banda. O TCP consome muitos recursos, exigindo mais mem\u00f3ria e processamento para estado de conex\u00e3o, temporizadores e n\u00fameros de sequ\u00eancia. Um pacote perdido no TCP pode atrasar pacotes subsequentes no fluxo, um fen\u00f4meno conhecido como bloqueio head-of-line. O UDP, no entanto, oferece uma abordagem mais r\u00e1pida, simples e eficiente<\/a>. Seu cabe\u00e7alho fixo de 8 bytes resulta em sobrecarga muito baixa.<\/p>\n <\/p>\nKey Takeaways<\/h2>\n
<\/p>\n
Compreendendo a camada de transporte e sua unidade de dados de protocolo<\/h2>\n
![\"Compreendendo](\"https:\/\/statics.mylandingpages.co\/static\/aaanxdmf26c522mpaaaaz2wwe7ppkact\/image\/f8cde866ed4347078f7c19a0bd2bb8d5.webp\")
<\/p>\nO papel da camada de transporte na rede<\/h3>\n
Posi\u00e7\u00e3o nos Modelos OSI e TCP\/IP<\/h4>\n
Responsabilidades essenciais para comunica\u00e7\u00e3o ponta a ponta<\/h4>\n
Introdu\u00e7\u00e3o \u00e0 unidade de dados do protocolo da camada de transporte<\/h3>\n
O que \u00e9 uma unidade de dados de protocolo?<\/h4>\n
Por que a camada de transporte precisa de uma PDU espec\u00edfica<\/h4>\n
O segmento TCP: uma unidade de dados de protocolo confi\u00e1vel<\/h2>\n
Definindo o Segmento TCP<\/h3>\n
Caracter\u00edsticas de um segmento TCP<\/h4>\n
MTU - IPHeader - TCPHeader<\/code>. Por exemplo, com uma MTU Ethernet de 1.500 bytes, um cabe\u00e7alho IP de 20 bytes e um cabe\u00e7alho TCP de 20 bytes, o MSS passa a ter 1.460 bytes. Os valores MSS comuns incluem 512 bytes para redes mais antigas e 1460 bytes, que \u00e9 o padr\u00e3o na maioria das redes Ethernet\/IP.<\/p>\nObjetivo da unidade de dados do protocolo de segmento TCP<\/h4>\n
Principais componentes de um cabe\u00e7alho de segmento TCP<\/h3>\n
N\u00fameros de porta de origem e destino<\/h4>\n
N\u00fameros de sequ\u00eancia e reconhecimento<\/h4>\n
Sinalizadores de controle e tamanho da janela<\/h4>\n
<\/p>\n
O campo Tamanho da janela, um Valor de 16 bits<\/a>, \u00e9 crucial para o controle de fluxo. Especifica a quantidade de dados que o receptor est\u00e1 disposto a aceitar, evitando que um remetente r\u00e1pido sobrecarregue um receptor mais lento. Esse valor pode ser dimensionado para at\u00e9 1 GB ou mais com a op\u00e7\u00e3o Escala de janela.<\/li>\nFun\u00e7\u00f5es habilitadas pela unidade de dados do protocolo de segmento TCP<\/h3>\n
Transfer\u00eancia confi\u00e1vel de dados e recupera\u00e7\u00e3o de erros<\/h4>\n
Controle de fluxo e gerenciamento de congestionamento<\/h4>\n
Estabelecimento e rescis\u00e3o de conex\u00e3o<\/h4>\n
O datagrama UDP: uma unidade de dados de protocolo sem conex\u00e3o<\/h2>\n
Definindo o Datagrama UDP<\/h3>\n
Caracter\u00edsticas de um datagrama UDP<\/h4>\n
<\/p>\n
Objetivo da unidade de dados do protocolo de datagrama UDP<\/h4>\n
Principais componentes de um cabe\u00e7alho de datagrama UDP<\/h3>\n
N\u00fameros de porta de origem e destino<\/h4>\n
Campos de comprimento e soma de verifica\u00e7\u00e3o<\/h4>\n
Fun\u00e7\u00f5es habilitadas pela unidade de dados do protocolo de datagrama UDP<\/h3>\n
Comunica\u00e7\u00e3o sem conex\u00e3o e sobrecarga m\u00ednima<\/h4>\n
Velocidade acima da confiabilidade<\/h4>\n
Comparando as unidades de dados do protocolo da camada de transporte: segmento vs. datagrama<\/h2>\n
![\"Comparando](\"https:\/\/statics.mylandingpages.co\/static\/aaanxdmf26c522mpaaaaz2wwe7ppkact\/image\/09b83e1b8d674ab1ae19fe9c4b4599c1.webp\")
<\/p>\nDiferen\u00e7as fundamentais no design da unidade de dados de protocolo<\/h3>\n
Compara\u00e7\u00e3o de confiabilidade, velocidade e custos indiretos<\/h4>\n