Entendendo Protocolos de Comunicao e Transmisso de Dados - Parte I

Autor: Leonardo Furtado

Objetivos: Reference Model OSI e TCP/IP Protocol Suite: Uma viso geral Protocolos de Transporte: Apresentando o TCP

Ultimamente tenho notado um interesse incomum de nossos usurios por procedimentos, conceitos, e, principalmente, comandos do Cisco IOS que podero ser utilizado para concluir determinadas tarefas. Mas o que mais tem me chamado a ateno que este interesse est sempre voltado para o processo mais prtico possvel inerente configurao destes componentes, onde o usurio pouco se dedica na compreenso de elementos e conceitos importantes, que por sua vez formam a base para o aprimoramento do conhecimento tcnico e a assimilao da tecnologia em seu aspecto tcnico/terico. Particularmente eu observo que o problema em dedicarmos o nosso tempo tentando aprender novos comandos ou como configurar certos componentes, ao mesmo tempo que no observando adequadamente as funcionalidades, terminologia, e o contedo terico relacionados estes, que o usurio acaba no aprendendo a tecnologia de forma sistemtica. Quando no aprendemos a base terica para assegurarmos o perfeito entendimento sobre um determinado componente tecnolgico, simplesmente estamos limitando ou estreitando as possibilidades de aprendermos adequadamente estas e futuras tecnologias. H inmeros exemplos por a afora: Usurios e administradores de redes preocupados em configurar um QoS para "melhorar a banda da Internet l no trabalho" sem ao menos possuir conhecimentos sobre o formato do frame Ethernet, campos, o IP header, TCP header, UDP header, como funciona o processo de comunicao TCP/IP entre dois hosts, etc. Pergunto-me: Que utilidade isto representa? Para que reservar banda, classificar pacotes, identificar aplicaes, marcar e reservar recursos, priorizar transmisses, enfileirar pacotes representando aplicaes mais crticas, etc, quando o administrador de rede sequer conhece a estrutura do prprio IP header e suas funes? Eis a o motivo pelo qual estou publicando este artigo no CiscoTrainingBR.com. Como de praxe, este artigo ter uma abordagem bem prtica e descomplicada, portanto sugiro para que vocs visitem os links recomendados (a maioria so RFCs) para que possam estudar as questes de forma mais tcnica, ou melhor, terica de acordo com os seus interesses. Duas observaes muito importantes!! Devido a natureza desta srie de artigos sobre protocolos de comunicao, extremamente recomendado a leitura de todas as partes. Isto recomendado porque os protocolos de comunicao e respectivos processos sero "quebrados" e divididos em vrias partes (artigos) e, sendo assim, a total compreenso destes conceitos depender da leitura completa da srie. Caso voc no consiga visualizar alguma imagem contida neste artigo, atualize (refresh) o artigo (pgina) para corrigir este problema.

Reference Model OSI e TCP/IP Protocol Suite: Uma viso geral Aqui no perderemos muito tempo, pois fundamentos sobre o RM-OSI so aplamente difundidos em praticamente toda e qualquer forma de treinamento disponvel no mercado atualmente. Acredito que pelo menos 90% dos visitantes do CiscoTrainingBR.com possui o mnimo de conhecimentos sobre o OSI, suas camadas, funes bsicas, e a descrio de alguns componentes comumente encontrados em cada uma destas camadas. A figura abaixo ilustra e compara os dois modelos de referncia.

Simplesmente no h diferenas entre o OSI e o modelo proposto para a suite de protocolos TCP/IP: as camadas OSI correspondentes no modelo TCP/IP podem ser seguramente mapeadas; no aspecto funcionalidade tambm no h diferenas. Descrevendo melhor cada uma destas camadas: Application: De uma forma geral, esta camada onde reside os componentes acessados diretamente pelos usurios e tambm onde temos a presena de algumas aplicaes e servios bem populares no ambiente Internet. Por exemplo, SMTP (e-mail), FTP, Telnet, SSH, HTTP, SNMP, so clssicos e praticamente conhecidos por todos. Em outras palavras, esta camada representa os processos de rede para as aplicaes em execuo pelo usurio. Presentation: Representao de dados e formatao de cdigo. O objetivo desta camada fazer com que os dados recebidos via rede possam ser utilizados pela aplicao em execuo pelo usurio, e tambm garante que os dados da aplicao do usurio possam ser transmitidos pela rede, em um formato que poder ser interpretado e utilizado pelo outro host, aquele para o qual desejamos estabelecer a comunicao. Exemplos: JPEG, GIF, MPEG, ASCII, etc. Session: Esta camada estabelece, mantm, e gerencia a sesses entre aplicaes. H inmeros exemplos de servios bem conhecidos nesta camada, como por exemplo o NetBIOS e RPC. Windows networking possui diversos componentes que fazem uso extenso das funes desta camada. Transport: Esta camada responsvel pela transmisso dos dados em data streams, oferecendo opes para a entrega confivel dos dados e mecanismos para a preveno e tratamento de eventuais congestionamentos da rede (TCP, RTP, SPX), e tambm a entrega "best-effort" e sem mecanismos para sequenciao e janelamento das transmisses (UDP). Network: Esta camada determina o melhor caminho que um pacote dever percorrer entre a sua origem e destino, sendo tambm responsvel pelo endereamento lgico da rede (IP, IPX...) e notificao de erros (ICMP). Roteadores e diversos protocolos de roteamento atuam diretamente nesta camada. Data Link: Esta camada responsvel por receber os dados das camadas superiores e prepar-los para a transmisso no meio fsico, e vice-versa. Tambm responsvel por identificao de erros, topologia da rede, e controle de fluxo. Por exemplo: Ethernet 802.3, Ethernet ARPA, 802.2, 802.5, Frame Relay, HDLC, etc. Bridges e Switches, e tambm alguns protocolos de comunicao (ARP, NetBEUI) atuam nesta camada. Physical: Esta camada prov as funes fsicas, mecnicas, eltricas, e processuais, para a ativao e manuteno do meio fsico entre os sistemas de comunicao. Exemplo: EIA/TIA 568A/B, IEEE 802.3, e diversas outras especificaes possuem componentes nesta camada. Repetidores, hubs, concentradores, conectores, cabos, interfaces fsicas, multiplexadores, sinalizao analgica e digital, e diversos outros fazem parte desta camada. Obviamente h muito mais poeira debaixo deste tapete, e acredito que a grande maioria dos usurios do site possui bons conhecimentos sobre este tema. Ao invs de focalizar no que reside em cada camada, o objetivo real deste artigo ilustrar melhor a comunicao entre os componentes e como frames e protocolos diversos participam em uma rede TCP/IP certamente temos a um tpico pouco explorado pela maioria das publicaes disponveis, j que a maioria ainda prefere ir direto ao assunto e discutir comandos e coisas deste tipo. Cada camada do RM-OSI referente a um processo de comunicao em um host, se comunica com a camada correspondente residindo no processo de comunicao em outro host, considerando que ambos hosts desejam se comunicar. Isto o que chamamos de "peer-to-peer communication", pois, por exemplo, os dados enviados pela camada Application em um host s podero ser devidamente recebidos e interpretados na camada de mesmo nome residindo no

outro host, dentro deste processo de comunicao, e o mesmo ocorre para as demais camadas. Explicaremos isto com detalhes na sequncia deste artigo.Na verdade, cada camada do RM-OSI solicita e presta servios para as suas camadas vizinhas, originando naquilo que chamamos de Protocol Data Unit (PDU), e estes PDUs o que na verdade permite ou viabiliza a comunicao peer-to-peer entre as camadas correspondentes residindo em ambos hosts. A figura abaixo ilustra este procedimento:

A figura acima ilustra o processo de comunicao "peer-to-peer" entre camadas correspondentes de dois hosts envolvidos em uma transmisso de dados. Observe que os dados enviados pela camada Application (Aplicao) do Host 1 s podero ser devidamente interpretados pela camada (Application) correspondente do Host 2. tambm importante saber identificar o PDU referente ao processo de comunicao, como o caso do Data, Segment, Packet ou Datagram, Frame, e Bits. Isto significa que importante saber isolar apropriadamente cada componente do processo de comunicao, pois isto facilita o troubleshooting e tambm organiza as questes processuais inerentes a comunicao entre dois hosts. Por exemplo, suponhamos que a comunicao entre dois hosts no esteja funcionando adequadamente: o que fazer? Sair digitando comandos ou organizar uma linha de pensamento e dividir o troubleshooting em partes menores, porm mais eficazes e melhor gerenciveis, para a identificao do componente faltoso? Testando o cabo da rede com um teste de continuidade estaramos garantindo que o meio fsico encontra-se em boas condies e, utilizando-se algo mais avanado (como um bom Scanner), poderamos no somente validar a continuidade do cabo, mas tambm certificar de que caractersticas eletromecnicas referentes ao meio fsico em questo encontram-se em conformidade com a norma correspondente (ex: atenuao, rudo, potncia, comprimento do cabo, etc). Estando tudo OK, pode-se afirmar que o conjunto "bits" do processo de comunicao est funcionando em perfeita ordem. Seguindo adiante, verificaramos Speed/Duplex, estatsticas da interface Ethernet, frame type, erros, ARP, bridging/switching (recursos de bridges/switches), etc, eliminando qualquer suspeita para o conjunto "Frame" do processo de comunicao supracitado. Enfim, ao seguir este modelo, poderemos testar devidamente cada camada e garantir que cada componente est respeitando as especificaes e normas, alm de estarem devidamente funcionais para o caso. Na verdade quando dois hosts esto envolvidos em uma transmisso, o processo 100% transparente para o usurio: cabe ao analista de suporte ou administrador da rede verificar onde est o problema. Suponhamos ainda que voc tenha verificado que o cabo est OK, e a interface est UP/UP e recebendo frames normalmente. Adicionalmente, no h erros Ethernet associados interface (FCS, runt/giant, etc); qual seria o prximo passo? De acordo com o modelo sugerido, o prximo passo seria verificar a poro "Network" (Rede), correto? Isto significa: verificao do endereamento IP, rotas,

notificao de erros, etc. Este modelo representa a prtica recomendada para um troubleshooting bem sucedido, embora para analistas mais experientes o mecanismo poder ser executado de forma bem mais simplificada, como por exemplo um Telnet para a porta TCP ou UDP referente aplicao que est apresentando problemas executaria um teste completo em todas as camadas do modelo OSI, encurtando ainda mais o processo. Obviamente o ideal seria testar cada camada separadamente e garantir que o problema pode ser encontrado rapidamente sem que ao mesmo tempo voc fique perdido durante o troubleshooting. Eu diria que o pior problema, o mais chato, quando todos os testes so bem sucedidos (camada fsica OK, Data-Link OK, Network OK, Transport OK, Session/Presentation/Application OK) mas mesmo assim h problemas na rede. Nestes casos a ltima alternativa seria a monitorao completa do processo de comunicao atravs de 2 ou mais sensores "Sniffer" para uma depurao minuciosa de cada pacote transmitido/recebido, pois provvel que o problema esteja na prpria aplicao (um sistema "com problemas"). Esclarecendo ainda mais a questo PDU e comunicao peer-to-peer, temos a seguinte ilustrao:

No exemplo acima, o Host 1 deseja efetuar uma conexo Telnet para o Host2 (host2.ciscotrainingbr.com): 1. O usurio aciona o "telnet.exe" informando como destino o "host2.ciscotrainingbr.com". Este comando acionar a interface Telnet localizada na camada de Aplicao (Application layer) para que o telnet.exe possa transmitir o seu payload para a camada abaixo. Na camada Apresentao (Presentation layer), o sistema certificar de que o formato a ser transmitido pela rede esta em conformidade com a aplicao telnet.exe em execuo pela remetente, assegurando, portanto, a transmisso deste payload para que o mesmo possa ser transportado pela rede. Na camada Sesso (Session), havendo algum componente diretamente responsvel pelo processo de comunicao, mais especificamente a criao, manuteno e gerenciamento das sesses envolvendo a aplicao sendo executada pelo usurio, ocorrer a insero da sua poro de dados, passando-se todo este conjunto para a camada abaixo (Transporte). Na camada Transporte (Transport layer), o sistema utilizar o protocolo de transporte apropriado para que os dados possam ser transmitidos pela rede. O protocolo a ser utilizado (ex: TCP, UDP, RTP) na verdade solicitado pela prpria aplicao, que durante o processo de encapsulamento do PDU informou camada Transporte sobre o protocolo de transporte e porta de destino. O protocolo solicitado, ento, atribuir esta porta de destino (ex: Telnet = TCP porta 23), uma porta de origem, e informaes adicionais inerentes ao prprio protocolo de transporte a ser utilizado. A funo da porta de origem e permitir a multiplexao de diversas transmisses utilizando-se o mesmo mecanismo de transporte, pois assim o sistema poder encaminhar os dados para os processos requisitantes apropriadamente. Por exemplo, um nico host poderia estar executando Telnet para diversas mquinas, e atravs das portas de origem informadas no segmento do PDU ser possvel identificar, logo aps o recebimento de um pacote, qual das sesses Telnet em execuo pelo usurio dever receber o referido pacote. Na camada Rede (Network layer) o sistema observar o melhor caminho para efetuar a entrega. Observe que mesmo utilizando um protocolo de transporte, as transmisses envolvendo a suite TCP/IP transportada, na verdade, pelo protocolo IP, pois o IP quem proporciona as informaes tais como endereos de origem e destino, fragmentao, etc. s observar o processo de encapsulamento para entender bem este processo, pois somente IP rotevel... o TCP ou UDP no podem trafegar "sozinhos" pela rede sem o auxlio do IP. Havendo

2.

3.

4.

5.

problemas durante o trajeto do pacote pela rede, conforme mostraremos mais adiante, a camada Network do equipamento que constatou o problema se encarregar de acionar o ICMP para informar o remetente sobre o problema. Tratando-se de hosts, o computador consultar a sua prpria tabela de roteamento para determinar por onde encaminhar o pacote: para um host localizado na mesma subrede, via uma interface especfica, ou via seu default gateway (default route). 6. Chegando na camada Enlace de Dados (Data-Link layer), o sistema encapsular o PDU para um frame compatvel com o meio fsico utilizado pelo equipamento. Por exemplo, tratando-se de Ethernet o encapsulamento poder ser um frame Ethernet 802.3, 802.2, ARPA (Ethernet II) e, tratando-se de um link de WAN, isto podera ser HDLC, PPP, etc. Esta camada tambm precisar de informaes adicionais, como por exemplo o endereo fsico do destinatrio, pois na verdade a entrega dos frames ocorre na camada 2, e no na camada 3. neste aspecto que entra o ARP. Aps este processo, os dados so passados para a camada Fsica (Physical) que por sua vez lida apenas com os bits e funes j descritas anteriormente.

Esta abordagem simples, porm direta, sobre encapsulamento dos dados e PDUs, encerra basicamente esta parte de nosso artigo. Considero fundamental para que profissionais da rea conheam adequadamente as funes bsicas envolvendo redes de computadores, protocolos de comunicao, e transmisso de dados. O que foi mostrado at agora a coisa mais bsica e fundamental possvel sobre transmisso de dados entre dois hosts, e somente aps compreender bem este processo que poderemos prosseguir com a apresentao de conceitos mais avanados. Transmission Control Protocol (TCP, RFC 793) O Transmission Control Protocol, que neste artigo trataremos pelo nome TCP, responsvel por efetuar entregas/transmisses confiveis, e que oferece uma srie de mecanismos para atribuir a confiabilidade destas transmisses ao mesmo tempo em que tratando adequadamente do fluxo de trfego, evitando-se congestionamentos. O TCP um protocolo que funciona no estilo "sliding-window", e para que uma transmisso possa ser iniciada, os hosts envolvidos precisam estabelecer alguns critrios para que isto possa ser viabilizado confiavelmente e dentro de propores que possam satisfazer ambos remetente e destinatrio. A verdade que o TCP foi criado para corrigir algumas deficiencias apresentadas pelo protocolo IP, agregando-se mais robustez e complexidade, porm garantindo que transmisses mal sucedidas ou no confirmadas pelo receptor possam ser retransmitidas apropriadamente. O TCP possui as seguintes caractersticas: Streams: Os dados enviados pelo TCP so organizados em streams de bytes. Entrega confivel: O TCP utiliza sequence numbers para coordenar as transmisses de dados enviados e recebidos, e prontamente os retransmitir caso constatar que pores de uma transmisso foram perdidas. Adaptativo: O TCP normalmente "aprender" as condies de operao da rede, e automaticamente ajustar o seu funcionamento para que as suas transmisses possam ocorrer sem sobrecarregar o meio fsico. Controle de Fluxo: Este mecanismo previne que os dados transmitidos jamais sobrecarregaro os hosts receptores. Por exemplo, possvel que um host possa ter condies de transmitir dados mais rapidamente do que o host que os estar recebendo, e este mecanismo funcionar como uma espcie de slowdown, previnindo que o sender sobrecarregue o buffer de recebimento de pacotes das mquinas destinatrias.

Estas so basicamente as diferenas entre o TCP e o IP, no tocante performance e confiabilidade das transmisses. claro que o TCP sozinho no poder efetuar as transmisses, e para tal depender sempre do IP. Em adio s caractersticas j citadas sobre o TCP, temos ainda as seguintes: Modo de operao Full Duplex: O TCP opera sempre em modo full duplex, onde, contextualmente falando, emprega duas sesses TCP trafegando em direes opostas, e funcionando como dois byte streams totalmente independentes. fato que no h um mecanismo TCP que associar os dados dentro dos byte streams trafegando em direes opostas, e a caracterstica assimtrica deste protocolo s visvel durante o incio e o trmino de uma transmisso, pois neste caso o protocolo TCP poder enviar dados em uma direo, mas no no sentido inverso, e vice-versa. Sequence Numbers: O TCP utiliza 32 bits para sequence number que contam os bytes dentro de cada transmisso, e cada pacote TCP contm o nmero indicando o sequence number inicial, e um outro nmero, o acknowledgement number, que representa o ltimo byte recebido de seu vizinho durante uma transmisso em particular. atravs deste mecanismo que a funo "sliding-window" implementada e funcional. Cada host envolvido em uma transmisso TCP dever controlar e monitorar seus prprios sequence numbers e tambm os

sequence numbers do peer remoto, e os sequence numbers referentes as transmisses e recebimentos so totalmente independentes. Flags: O TCP utiliza uma srie de "flags" para o gerenciamento das conexes. Por exemplo, durante o estabelecimento de uma conexo, o TCP acionar o flag SYN, recebendo de seu peer remoto o ACK/SYN, e por ltimo respondendo este com um ACK. Ao trmino de uma conexo, so empregados FIN e ACK; ou ainda durante a quebra de uma conexo (por motivos diversos, aplicao, firewall, etc) utiliza-se o RST. Cada um destes flags ocupa um nico byte. Window Size e Buffering: Em cada host envolvido em uma transmisso TCP, haver uma rea para armazenamento (buffer) dos dados transmitidos pela rede antes que os mesmos encontrarem-se disponveis para a aplicao que os solicitou. Isto permite que haja transferncias de uma certo calibre enquanto as prprias aplicaes ou recursos do sistema esto ocupados desempenhando outras tarefas. Isto o que chamamos de "buffering". Ja o mecanismo "windowing" utilizado para evitar a sobrecarga deste buffer mantido pelos hosts envolvidos na transmisso. Em cada pacote TCP transmitido pela rede, h um campo chamado "Window Size" que informa a quantidade de dados que podero ser transmitidos para este buffer. Se este nmero atingir a zero, o peer remoto no poder enviar dados at que haja espao novamente neste buffer e o host remoto receba um pacote anunciando um Window Size diferente de zero. Isto particularmente interessante pois o host remetente estar sempre informando a quantidade de dados que poder receber de seu host (peer) remoto. Todavia, em alguns casos o buffer disponvel involuntariamente pequeno, especialmente em situaes onde aplicaes "tagarelas" consomem recursos excessivamente. Costuma-se recomendar, nestes casos, o aumento do buffer no prprio host, mas o prprio protocolo TCP um gargalo, pois o mesmo no pode suportar um Window Size muito grande. Nestas condies a rede tida como "elephant" (Long Fat Network - LFN). O RFC 1072 discute o LFN. Round-Trip Time Estimation: Devido a prpria natureza deste protocolo, em garantir as entregas confiveis, torna-se necessrio estimar o tempo de resposta para cada pacote transmitido, ou seja, quando um host transmite um pacote, o mesmo aguarda pela confirmao desta transmisso (acknowledgement) por um certo perodo de tempo. Suponhamos que o host no recebeu tal confirmao dentro do prazo esperado, e, consequentemente, o pacote dever ser retransmitido. A questo disto tudo quanto tempo o host dever esperar antes de concluir que uma transmisso foi perdida, devendo, portanto, retransmit-la? Em redes rpidas, como Ethernet, poucos microseconds sero necessrios para a verificao desta confirmao. Quando transmisses estiverem ocorrendo em redes naturalmente mais lentas, tais como links de WAN de baixa capacidade ou transmisses via satlite, este "prazo" seria concedido em conformidade com a latncia natural destes meios de transmisso. Mas tudo isto ainda no respondeu a nossa pergunta: Esperar pela confirmao.... por quanto tempo? Praticamente todas as implementaes modernas do TCP procuram por esta resposta atravs da troca de pacotes de dados e monitorando as confirmaes para que se possa estimar adequadamente quanto tempo dever representar este prazo para a tal confirmao. Este processo chamado Round-Trip Time (RTT) estimation, e considerado um dos parmetros sobre performance mais importantes negociados entre dois hosts durante uma transmisso TCP.

O que foi citado at aqui ajuda bastante a entender o TCP. Informaes mais especficas e a abordagem de elementos mais complexos deste protocolos podero ser compreendidos melhor atravs da apresentao do TCP Header e a descrio de seus campos e funes:

Explicando cada um destes campos: Source Port (16 bits ): A porta de origem. Conforme mencionei anteriormente, o TCP suporta a "multiplexao" de diversas transmisses, onde uma porta de origem atribuda para cada conexo. Isto permite o TCP rotear o recebimento dos pacotes para os processos correspondentes em execuo no host remetente. Destination Port (16 bits): Representando a porta de destino. Sequence Number (32 bits): O sequence number do primeiro octeto de dados em um segmento, exceto quando SYN flag encontrar-se presente. Caso o SYN flag encontrar-se presente, o sequence number ser o initial sequence number (ISN) e o primeiro octeto de dados ser o ISN+1. Acknowledgement Number (32 bits): Caso o bit de controle ACK estiver presente, este valor ser o prximo valor de sequence number que o sender espera receber. Uma vez que a conexo estiver sido estabelecida, o acknowledgement number ser sempre enviado. Data Offset (4 bits): Em comprimentos de 32 bits dentro do TCP Header, isto indicar onde os dados iniciam no segmento. O prprio TCP Header, mesmo aqueles contendo as opes, dever ser um nmero integral de 32 bits de comprimento. Reserved (6 bits): Reservado, dever ser zero. Control Bits (6 bits): Temos o seguinte: o URG (Urgent Pointer): Indica uma condio de "urgncia" para que os dados possam ser transmitidos imediatamente. o ACK (Acknowledgement): Confirmao do recebimento de um segmento TCP. o PSH (Push): Este flag informa a pilha de protocolos para que os dados sejam transmitidos imediatamente, pois a conexo foi estabelecida apropriadamente e est na hora de transmitir os dados! o RST (Reset (connection)): Este flag muito comum quando a conexo encerrada brutalmente, de forma no intencional ou comandada pelo usurio. Por exemplo, ao utilizarmos um servio para um host protegido por um firewall, e o nosso endereo IP de origem no nos permite acessar aquela destination port, muito provvel que o firewall responder com este flag. Note, entretanto, que alguns firewalls so configurados para no responder nada, justamente para no sugerir o que est sendo filtrado ou protegido, o que timo para dificultar scanning/footprinting. o SYN (Synchronize (sequence numbers)): Este flag utilizado durante o estabelecimento de uma conexo TCP. o FIN: No h mais dados sendo transmitidos pelo sender; a conexo dever ser encerrada.

Window (16 bits): Indica o nmero de octetos, comeando com aquele indicado no campo acknowledgement, que o sender est disposto a receber. Checksum (16 bits): O campo checksum, de 16 bits de comprimento, o complemento da soma de todas as pores 16 bits do cabealho (header) e texto. O checksum protege o que chamamos de "pseudo-header" (96 bits), que consiste nos campos Source Address, Destination Address, Protocol, TCP Length. Observe que alguns destes campos NO fazem parte do TCP Header propriamente dito, da o termo "pseudo-header". Esta proteo proporcionada pelo checksum sobre este "pseudo-header" o resultado de uma cooperao entre alguns campos do TCP Header e IP Header, previnindo-se segmentos roteados incorretamente. Estas informaes so transportadas dentro do IP e so transferidas para a interface TCP/Rede, ou "TCP no IP". O TCP Length o comprimento do TCP Header mais a poro de dados mostrados em octetos. Urgent Pointer (16 bits): Este campo interpretado somente em segmentos com o bit de controle "URG" ativado. Este campo apontar para o sequence number do octeto onde seguem os dados "urgentes". Options (varivel): De comprimento varivel, e em mltiplos de 8 bits de comprimento, este campo informa as opes, todas elas includas no checksum. Os "options" atualmente atribudos nas implementaes TCP incluem: (0 - End of Option list; 1 - No Operation; 2 - Maximum Segment Size). Talvez o option mais popular seja o MSS (Maximum Segment Size) , que enviado durante o estabelecimento de uma conexo (SYN). Administradores de rede e analistas de suporte que trabalham muito com VPN em ambientes broadband certamente sabem muito bem

do que isto se trata, ou ser que aqui neste site, nenhum de nossos leitores/visitantes, jamais teve um problema envolvendo PMTUD/MSS ???? Padding (varivel): O padding serve para certificar-se de que o TCP Header terminar, em seu comprimento, e que os dados inciaro-se, tambm em comprimento, de 32 bits. Este campo composto por zeros.

Ok. Com a descrio das funes bsicas do TCP Header e tambm sobre a funcionalidade bsica deste protocolo, eu poderei neste momento mostrar em termos prticos como tudo isto funciona. No exemplo abaixo, temos o estabelecimento de uma conexo TCP entre dois hosts; o chamado "three-way handshake":

O "three-way handshake" o processo utilizado para viabilizar o estabelecimento de uma conexo TCP entre dois hosts. Este processo iniciado normalmente por um host, e respondido adequadamente pelo outro host, durante este processo de comunicao. Durante o estabelecimento de sesses entre computadores, comum termos algumas anormalidades, e as mais frequentes so aquelas que chamamos de "half-open connections". Uma half-open connection ocorre quando um dos hosts terminou ou abortou a conexo com o seu peer sem o consentimento deste, ou ento se a conexo entre ambos perdeu o sincronismo devido motivos quaisquer (geralmente envolvendo "quebra" de recursos, tais como buffers, memria, entre outros). Quando este cenrio ocorre, a conexo sofre um "reset" quando h a tentativa de transmisso em qualquer direo. importante conhecer bem os estados de conexo envolvidos no TCP: CLOSED: A conexo est "fechada". Esta geralmente a condio da conexo quando um host deseja se comunicar com um outro host. LISTEN: O host est "escutando" uma porta referente uma aplicao. Esta a condio de um host esperando por conexes em um de seus servios (ex: Telnetd, SSHd, etc). SYN-SENT: O host inicia a transmisso, mas primeiramente procura configurar a conexo atravs da sincronizao e estabelecimento da sesso. SYN-RECEIVED: O host destinatrio, at ento em "LISTEN", reconhece o SYN recebido de seu peer. O host destinatrio tambm far o envio do SYN, informando o ISN do host remetente e tambm o seu prprio ISN. ESTABLISHED: O host remetente reconhece o seu sequence number, informado pelo host destinatrio, e confirma a conexo, estabelecendo-a completamente.

Em adio estes, temos ainda: RESET: Ocorre quando a conexo terminada ou abortada por um dos hosts envolvidos na conexo. o caso dos chamados "half-open connections". FIN: Ocorre quando uma conexo terminada "naturalmente", ou seja, um dos hosts informa o desejo em encerrar a conexo pois no h mais dados para serem transmitidos.

O objetivo principal do three-way handshake no somente estabelecer a conexo propriamente dita, mas evitar que haja duplicaes dos processos de iniciao das conexes, e isto ocorre em funo da implementao do controle "RESET". As seguintes condies so possveis: Se o estado de conexo for "no sincronizado" (ex: SYN-SENT, SYN-RECEIVED), o host retornar ao estado "LISTEN" aps o recebimento de um "RESET". Se o estado da conexo for "synchronized"

(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), o host abortar a conexo e informar o usurio. Um exemplo: Suponhamos que um SYN duplicado chegue ao host destinatrio (nomeado Host 2): Este host no poder saber se este SYN duplicado ou referente um SYN j transmitido pelo host remetente (nomeado Host 1), portanto responder este SYN normalmente. O Host 1 detectar que o campo ACK est incorreto e, portanto, retornar com um RST (RESET), alm de um sequence number. O Host 2, ao receber o RST, retornar ao estado LISTEN. Agora... como funciona o "FIN"? Isto poder ocorrer de trs formas: 1. 2. 3. O usurio comanda o TCP para terminar a a conexo ("CLOSE") O TCP remoto inicia atravs do envio do sinal de controle "FIN" Ambas partes terminam a conexo simultneamente.

A seguinte ordem apresentada para casos onde ambos hosts finalizam a conexo: ESTABLISHED: Ambos hosts encontram-se como "ESTABLISHED" FIN-WAIT-1: Um dos hosts comanda o trmino da conexo (CLOSE) CLOSE-WAIT: O TCP remoto recebe a ordem, e notifica o remetente. Neste estgio, o seu estado de conexo "CLOSE-WAIT". FIN-WAIT-2: O host remetente permanece neste estgio, aguardando por uma notificao adicional por parte do TCP remoto. LAST-ACK: O TCP remoto envia o seu "CLOSE" TIME-WAIT: O TCP remetente recebe o CLOSE e permanece em TIME-WAIT, ao mesmo tempo em que confirma (ACK) o comando CLOSE do TCP remoto. CLOSED: O TCP remoto encerra a conexo. Logo aps isto, o TCP remetente tambm encerra a conexo.

J em situaes onde o FIN ocorre normalmente, como a maioria dos casos: ESTABLISHED ESTABLISHED ESTABLISHED: Ambos hosts em "ESTABLISHED" FIN-WAIT-1: Os hosts encerram a conexo CLOSING: Ambos hosts confirmam o encerramento da conexo, atravs da troca de sequence e acknowledgement numbers TIME-WAIT e CLOSED: A conexo encerrada.

Ao contrrio do "three-way handshake", o encerramento de uma conexo TCP ocorre em 4 fases, algo, contextualmente falando, "four-way FIN"! Agora tentarei ilustrar isto da melhor forma possvel: Cenrio 1: Uma conexo SSH entre dois hosts O servidor SSH, executando o SSHd, encontra-se em "LISTEN" (ou "listening") para a porta TCP 22, que representa o servio SSHd. Ao digitarmos o comando netstat -a em um host, por exemplo, teramos como constatar esta condio: [root@portal-srv lfurtado]# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *:ssh *:*

State LISTEN

Como voc pode perceber, o host (local address) est escutando a porta do SSH (sabemos que a porta 22), aguardando conexes (LISTEN) do protocolo TCP para esta porta (SSH), orindas de qualquer dispositivo remoto (*.*). Agora faremos uma ilustrao para este cenrio:

Antes de mais nada, o cenrio acima considera somente o TCP, portanto nenhuma referncia ser feita para o IP ou instrues de camada 2. Aqui trataremos apenas do TCP. Para compreender bem a ilustrao acima, basta que voc preste ateno nas cores e aonde as mesmas esto assinaladas. Por exemplo, o campo "Source Port" do TCP Header no equipamento "Host" est assinalado em "AZUL", que por sinal o mesmo verdadeiro para o campo "Destination Port" no equipamento "Server (SSHd)". Observe como a informao a exatamente a mesma, ou seja, a porta de origem (1591), do Host 1, dever ser a porta de destino a ser utilizada pelo equipamento "Server" quando o mesmo transmitir dados para o "Host". J a porta de destino no Host (22, SSH) dever ser a porta de origem no "Server" quando o mesmo transmitir dados para o "Host". Observe ainda os flags, mais especificamente o SYN e ACK, pois ambos so utilizados durante o estabelecimento de conexes TCP entre dois hosts. Mais uma vez, estude estes campos e nmeros, e verifique as cores conforme mostrado acima, pois assim voc poder compreender melhor como o processo funciona. No caso acima, tirado de um exemplo real, todo o handshake ocupou 3 frames, combinando exatamente com o que chamamos de "three-way handshake". A partir da, haver o inicio da transmisso propriamente dito, pois a conexo j foi estabelecida entre os equipamentos. Durante a transmisso, o options flag "PUSH" no equipamento "Host" assinalaria para a pilha de protocolos para que a transmisso dos dados fosse iniciada imediatamente. Caso voc queira observar um trace completo em uma sesso TELNET entre um equipamento e um roteador Cisco, clique no link abaixo. Este trace inclui o estabelecimento de uma sesso de usuario no VTY de um Cisco router, a digitao de um usurio e senha, e os comandos "show ip route" e "exit". Eu recomendo seriamente o acompanhamento deste trace, pois assim voc poder estudar o estabelecimento de conexo, troca de dados e transmisses, e o encerramento da conexo. Sniffer Trace - Conexo Telnet entre um usurio e um Cisco router http://www.ciscotrainingbr.com/courses/text/snif3.pdf

Referncias e Material de Apoio Estes links eu recomendo para aqueles que desejam aprofundar-se no TCP. TRANSMISSION CONTROL PROTOCOL ftp://ftp.rfc-editor.org/in-notes/rfc793.txt Known TCP Implementation Problems ftp://ftp.rfc-editor.org/in-notes/rfc2525.txt TCP Performance Implications of Network Path Asymmetry ftp://ftp.rfc-editor.org/in-notes/rfc3449.txt Inappropriate TCP Resets Considered Harmful ftp://ftp.rfc-editor.org/in-notes/rfc3360.txt Limited Slow-Start for TCP with Large Congestion Windows ftp://ftp.rfc-editor.org/in-notes/rfc3742.txt TCP Problems with Path MTU Discovery ftp://ftp.rfc-editor.org/in-notes/rfc2923.txt Esta parte, dedicada ao RM-OSI e protocolo TCP, est concluda. Na sequncia teremos detalhes do protocolo UDP e IP, abrangendo ainda mais o tema abordado por esta srie de artigos.