Tutorial Sobre TCP

Tutorial sobre TCP/IP
TCP:Transmission Control Protocol

IP: Internet Protocol

Protocolos: Simplesmente um conjunto de regras bem definidas que definem uma ação a ser executada (parece definição de
algoritmo mas na verdade pode ate ser encarado como um). Assim, protocolos em computação, e em especial a redes, define
como computadores podem se comunicar entre si.
Todo computador conectado em rede necessita de uma identificação, sendo assim, já de posse dessa identificação,
o protocolo tem por papel primordial estabelecer a conexão mais confiável e duradoura possível entre computadores. Dessa
forma, se define: como enviar e receber e-mails, como me identifico a outro computador, quanto tempo devo esperar para
que você me envie um conjunto de informações, com que intervalo um conjunto de informações deve ser espaçado a fim de
se obter a conexão mais confiável possível, como começar e como terminar uma conexão, etc.
Intranet: Intranet é o novo conceito para redes de acesso discado mas não vinculado diretamente ao que conhecemos como
Internet. Tal como um provedor de acesso à Internet, a Intranet conecta clientes a suas redes corporativas internas. Encare
uma Intranet como servidora dela mesma, ou seja, você pode acessá-la sem mesmo ter uma conta com um provedor
Internet, contudo, o acesso limita-se apenas a rede privada e, de forma alguma, você poderia, por exemplo, visitar paginas
em outros locais alem da qual foi pre-programada pela empresa. As diferenças residem ai, no resto, temos todas as
características de uma rede qualquer: serviços WWW, ftp e o que mais a empresa venha a necessitar para atender seus
clientes. Um bom exemplo a dar a respeito é sobre os serviços de Home Banking do Banco Itau (Isso não é propaganda
heim?); você conecta-se, por acesso discado, do seu modem, a rede interna de serviços privados do Banco Itau e usufrui dos
serviços de um caixa on-line.
Extranet: Extranet é uma variante da Intranet, ou seja, podemos defini-la como sendo uma interligação entre Intranets por
meio da Internet. Dessa forma, uma Intranet pode se comunicar a outra bastando apenas a sua interligacao por meio da
Internet o que, nesse caso, envolveria um provedor de acesso discado. Pense comigo: uma empresa com varias filiais
precisando de comunicação urgente com uma outra localizada a vários milhares de quilômetros; a comunicação por acesso
puramente discado, Intranet a Intranet seria inviável; usa-se, então, um provedor de acesso local para a interligação entre as
duas filiais.
Introdução
Ao contrario do que muita gente possa pensar, TCP/IP não é o único protocolo utilizado em comunica em redes,
tanto é que ao mesmo nível de um IP, por exemplo, existe o x.25 e, ao TCP, o UDP. E algo mais que algumas pessoas
possam fazer confusão é a respeito do que cada um faz, ou seja, TCP define um papel um tanto diferente do IP e vice-versa,
cada qual com um papel especifico mas com sobrevivência mutua e sempre "ajudado" por protocolos semelhantes. Na
realidade podemos ate mesmo estudar os dois protocolos separadamente.
O TCP/IP foi adotado como padrão em todo mundo como meio de comunicação com a Internet. Algumas empresas
podem implementar seus próprios protocolos de comunicação em redes internas, se quiserem, mas para a comunicação com
a Internet deverão adaptar seus equipamentos a fim de operar em TCP/IP.
O TCP/IP foi primeiramente desenvolvido como um projeto particular que atendesse aos serviços do Governo
Americano em especial as Forcas Armadas. No tempo da Guerra Fria, não era possível um nível de comunica satisfatório
entre bases comandadas, então foi necessário a criação de um nível de transmissão de informações mais adequado.
Logicamente existiam as transmissões puramente físicas com dados trafegando por meio de pulsos elétricos tal qual um
barramento transfere dados entre periféricos. Pensar em algo como isso naqueles tempos era no mínimo ridículo. Como me
comunicar dessa forma com uma base militar a algumas centenas ou milhares de quilômetros? Levando em conta alguns
conceitos de eletrônica, o sinal se perderia ou se anularia facilmente nesse meio, os fios.
Mesmo levando em conta que fosse possível tal meio de comunica, as informações não são enviadas como em um
protcolo por TCP/IP, ou seja, por pacotes. É tudo enviado de uma vez só. Se a transmissão por algum motivo fosse
interrompida todo o processo iria falhar e a informação não chegaria ao destino final. Desastroso.
Alem de permitir uma conexão mais confiável em redes, o TCP/IP permitia transmissões bem mais arrojadas do
que aquelas realizadas em modo puramente físico, ou seja, unicamente por transmissão em pulsos. Assim, uma transmissão
puramente física só poderia ser realizada somente por dois usuários por vez e se quisesse enviar mais informações a outros
computadores não seria possível ou então dever-se-ia fechar uma das conexões para que a informação pudesse chegar em
dois locais. Levando em conta que naquele tempo a comunicação era primordial entre vários lugares ao mesmo tempo, esse
modo de transmissão não era o mais indicado. Pelo TCP/IP (outros protocolos permitiam isso também) era possível
comunicação entre vários computadores ao mesmo tempo e isso atendia as pretensões da época.
Nesse tempo, os cientistas tiveram a idéia de transmissão por pacotes, ou seja, somente partes da informação que
deveria ser transmitida seriam enviadas. Assim, uma mensagem não corria o risco de se perder no meio da transmissão e
mesmo uma conexão mal realizada não seria de toda inútil.
Bem ,alguém poderia estar se perguntando: "Tudo bem, entendi o que você quis dizer, mas se usa qualquer
protocolo para meios de comunica através de pacotes segmentados, isso também implica um meio físico de transmissão e
nesse meios os dados trafegam normalmente como pulsos elétricos também." -- Ok, você esta certo, não ha. diferenças em
como a informação chega ao destino, ha. sim no modo como ela é enviada. Como será explicado mais adiante, o IP
segmenta a informação em vários pacotes e esse pacotes são tratados meramente como pulsos elétricos quando transmitidos
e quando chegam ao computador destino, mas o TCP (o responsável pelo recebimento) implementa um método seguro de
transmissão, isso porque se o que se queria ser enviado não chegou ao destino de forma completa, uma nova conexão pode
ser restabelecida sem prejuízo do que já havia sido feito.
Creio que você já deve ter ouvido falar no GetRight não? Ótimo programa. Isso seria um bom exemplo para dar a
você: quando uma conexão termina por qualquer motivo com o meio de origem, o que envia os dados, uma nova conexo
pode ser estabelecida sem prejuízo dos dados que estavam sendo recebidos, ou seja, pode ser reinicializada de onde se parou
sem problemas. Assim funciona o meio de transmissão de pacotes e acho que você já pegou o espírito da coisa sobre a
importância desse protocolo.
O protocolo TCP/IP implantou um novo conceito arrojado no modo de transmissão mundial entre redes mesmo as
heterogêneas (Sistemas Operacionais diferentes) e qualquer Sistema que tenha por pretensão conectar o usuário em rede
mundial Internet deve ter tais protocolos instalados Bom, era isso que eu queria falar a você como introdução. Agora vamos
a parte técnica da coisa.
Conceitos Técnicos
Antes de começar, um esclarecimento: Um provedor de acesso a internet funciona por concessão de uma outra
grande rede maior. Assim, seu provedor nada mais é do que uma rede conectada a outra maior e você, quando conectado ao
seu provedor e fazendo parte dele como um host, é um micro-host em toda a essa rede maior. Essa grande rede maior é
chamada de backbone (espinha-dorsal em ingles) e é nela onde estão conectadas as redes menores que oferecem serviços,
as provedoras. É o nível mais alto das redes. Os backbones nacionais são: RNP, Embratel, Unysis, Global One, IBM e
Banco Rural. Creio que são os únicos ate o momento. Esse são os de nível mais alto no Brasil, mas existem os backbones
estaduais também (na realidade podem ser considerados como centros de roteamento aos backbones nacionais): ANSP - SP;
Rede Bahia - BA; Rede Catarinense - SC; Rede Internet Minas - MG; Rede Paraibana de Pesquisa - PB; Rede Rio - RJ;
Rede Pernambuco de Informática - PE; Rede Norte-riograndense de Informática - RN e Rede Tchê - RS.
Sendo assim, a sua provedora é seu backbone pessoal, que se liga ao backbone do estado onde esta localizada que
por sua vez é conectada ao de maior nível, os backbones nacionais. Se seu estado não possui backbone provavelmente sua
provedora utiliza um backbone de outro estado ou então de algum instituto de tecnologia próprio que possa fazer pelo
menos um roteamento satisfatório.
Quando estabelecemos uma comunicação com nosso provedor de acesso a internet, por exemplo, nos é atribuído
um numero de identificação na rede. Esse numero de identificação é o IP. Um numero IP nada mais é do um numero de 32
bits segmentado em quatro partes, portanto com oito bits, formando um byte. Ao total teríamos 4 bytes. Se você recebe por
exemplo 11001000.11111001.11011111.1110010 esse numero define você no mundo inteiro, ou seja, seu computador é
único na internet naquele momento e você é perfeitamente identificado por ele. Assim como um numero de telefone, não
existem dois números IP conectados ao mesmo tempo a não ser, obvio, que seja pertencente a uma rede interna (que não
possua acesso a Internet).
Algo interessante a se dizer sobre essa identificação é que, como foi dito, são um conjunto de bits e como tal é
representado por números binários. O mesmo numero acima traduzido para tabela decimal ficaria: 200.249.223.114. Isso é
importante notar, porque um numero como esse não é dado a você em formato decimal mas sim binário e depois convertido
graças ao servidor ou servidores DNS. Outra coisa interessante a ser dita a respeito é que números IP nunca ultrapassam o
patamar de numero 256. Assim, você nunca ira ver nada como 200.286, isso não é possível. Simplesmente porque a tabela
de conversão atinge somente 256 possibilidades numéricas (de 0 a 255). Portanto, o Maximo que você ira ver será 255 como
numero identificador de um dos segmentos do quarteto decimal. Na realidade poderíamos dizer 253 possibilidades porque o
numero 0 é destinado a processos especiais e 255 não pode ser atribuído a números IP de hosts, eles possuem outra
finalidade (a mascara de sub-rede). Maiores detalhes sobre isso na seção "HIERARQUIA DE REDES".
Outro fato que eu acredito muitas pessoas façam confusão é a respeito do host. Um host nada mais é do que um
computador conectado em rede (em uma rede interna ele também pode ser chamado de nó). Vamos citar um exemplo de
provedora, a ELOGICA. Quando você disca para lá e você é conectado, eles te fornecem um numero IP, ok. Para a
ELOGICA você nada mais é do que um computador conectado na rede dela, meramente um numero de identificação.
Como identifico um host? simples. Um endereço IP é dividido em duas partes: uma destinada a identifica da rede e
a outra identificando o host, ou seja o micro que pertence a essa rede e se conectou a ela. Voltando ao exemplo acima: se
nos temos 200.249.223.114 os dois primeiros bytes desse numero (lembre-se da definição mais acima, para não ficar
perdido) são destinados a rede, então: 200.249 é a rede a qual me conectei. Ok. Os outros dois últimos bytes definem o host:
223.114. Então, para ficar fácil, eu sou um micro chamado de host com identificação 223.114 conectado na rede 200.249.
Mais outra coisa deve ser dita: acho que você já ouviu falar em sub-rede, claro. Pois é, uma sub-rede nada mais é
do que uma rede hierarquicamente inferior em relação a uma rede maior. Geralmente, os números que identificam a sub-
rede são referidos ao terceiro byte da cadeia do IP, assim o mesmo numero 200.249.223.114 pode definir uma sub-rede de
identificação 223. Como você pode ver, uma rede pode ter varias sub-redes menores cada uma interdependente entre si mas
dependente em relação a rede maior.
(*Esse conceito de identificação de sub-redes envolve detalhes maiores e você ira obter melhores informações na seção
"HIERARQUIA DE REDES"*)
Voltando ao exemplo da ELOGICA: ela possui varias sub-redes cada uma com um papel diferente mas de
importância suma dentro de toda a rede. Para a ELOGICA foi concedido o numero 200.249.XXX como identificador da
rede em geral. Dentro dessa rede maior, a ELOGICA criou vários outros departamentos menores cada um com um serviço
especifico. Assim, poderíamos ter 200.249.223; 200.249.238; 200.249.219; 200.249.218, etc. Cada uma dessas sub-redes
com uma função especifica. Se você por exemplo, se conecta a rede e recebe: 200.249.219.15 então você é um host de
numero 15 dentro da sub-rede 219 na rede 200.249.
(*Infelizmente desconheço o menor e o maior nível de rede concedido a ELOGICA porque, como é uma rede classe C,
apenas o segundo byte não informa a sub-rede verdadeira. Assim outras redes também podem ter 200.249.XXX como
identificador, o que vai diferenciar ai seria o terceiro byte, justamente o que define uma rede dessa classe.*)
O conjunto de sub-redes da ELOGICA segue abaixo:
 200.249.238.2 bbs.ELOGICA.com.br
 200.249.238.3 PE.ELOGICA.com.br
 200.249.238.4 ceiun01.ELOGICA.com.br
 200.249.238.9 irc.ELOGICA.com.br
 200.249.238.11 os390.ELOGICA.com.br
 200.249.238.15 dominus.ELOGICA.com.br
 200.249.238.16 oxente.ELOGICA.com.br
 200.249.238.17 clovis.ELOGICA.com.br.238.249.200.in-addr.arpa
 200.249.238.18 host238-18.ELOGICA.com.br
Observe que os servidores principais se concentram na sub-rede 238. Isso não significa que um host de um usuário
não possa entrar e ser identificado como pertencente a sub-rede 238. De fato, esses são endereços fixos e pertencem aos
servidores que atendem serviços tais como o IRC mais acima ou o de e-mail (se não me engano o responsável ai seria o
ceiun01). Mas observe que mais abaixo (os dois últimos hosts) encontramos números de hosts comuns, ou seja, são de
usuários conectados no momento.
Um outro exemplo:
Nessa sub-rede de agora, a 223 não ouve nenhum servidor anunciado, apenas usuários conectados. Outras sub-
redes foram verificadas mas não houve nenhuma nova inclusão de servidores, parece que todo o serviço se concentra na
sub-rede 238. De fato, como será visto no próximo capitulo, sub-redes superiores a 224 são destinadas a serviços especiais e
ficam destinadas aos servidores.
Hierarquia de Redes
Como havia dito antes, a ELOGICA não obteve um numero de rede do nada. A ela foi concedido um numero de
rede que é: 200.249.XXX. O fato de ter colocado os caracteres X é porque a ELOGICA não é única no mundo com
identificação 200.249. De fato, assim como ela, a NETPE (uma outra provedora aqui de PE) também recebeu 200.249 como
identificação. Ambas são redes classe C e são varias pelo mundo. O que vai diferenciar as duas será o terceiro byte da
cadeia do IP. Uma organização mundial chamada IETF (Internet Engineering Task Force, ou Força Tarefa de Engenharia
da Internet) é quem outorga esses números a quem a solicita.
As redes são divididas hierarquicamente no mundo, assim nos temos rede de maior tamanho e aquelas menores.
Essa definição de maior ou menor atende o simples fato da possibilidade de um numero maior ou menor de hosts
conectados. Assim nos temos: Redes classe A, B e C.
Redes classe A: São as redes de maior numero de hosts conectados e somente pouquíssimos órgãos ao redor do
mundo possuem o privilegio de possuir um endereço de rede situado na classe A (diga-se de passagem, não existem mais
endereços dessa classe disponíveis a novos cadastros, a não ser que alguém se descadastre). De fato, não é qualquer
organização no mundo que possui esse privilegio e é apenas concedido a Universidades e organismos Governamentais. A
quantidade de endereços disponíveis a esse nível é pequena, atinge números de 1 a 126. Observe que não utilizei os
caracteres X pra identificar um outro nível, isso não é necessário em classes do tipo A, porque o primeiro byte já é suficiente
para a identificação de toda a rede. Já deu pra perceber portanto que essas redes são muito poucas mas atende o maior
numero possível de hosts conectados: 16.777.215. No mundo inteiro somente existe 126 redes classe A com demanda de
aproximadamente 16 milhões de hosts. Então nos poderíamos ter: 1.0.0.1 ate 126.255.255.254. Esses dezesseis milhões de
hosts reflete o numero de possibilidades possíveis entre os três últimos bytes do quarteto. Assim, se fizermos uma analise
combinatória desses termos chegaríamos no numero em questão. Bom, uma pergunta poderia surgir: "Ok, redes desse tipo
são realmente grandes mas não entendi como ficou essa ultima parte, e quanto aos outros endereços? Por que não foram
incluídos? - Os outros endereços de rede não foram incluídos fique são o resultado da analise combinatória entre os outros
possíveis hosts. Levando em conta que possuímos ainda os três últimos bytes da cadeia do IP, teríamos 256 possibilidades
diferentes em um byte da cadeia do IP.
Se temos 256 possibilidades entre cada um dos três últimos bytes da cadeia do IP então faca o seguinte: eleve 256
ao cubo. O que você vai obter é exatamente 16.777.216 como resultado. Uma pergunta interessante poderia surgir: "Certo,
mas em outra parte do tutorial você afirma que o numero 0 e o 255 não podem ser atribuídos a números IP porque possuem
outras funções" - Não é bem assim. O que afirmei é que números de hosts não podem ter esses números e quando me refiro
a host me refiro a um micro conectado e não um servidor de rede. Dessa forma, uma rede pode se utilizar de todas as
possibilidades desde que não seja atribuído aqueles valores a hosts.
Rede tipo B: Essas são as redes intermediarias e possuem endereços de rede de 128 a 16.384. Redes desse tipo são
identificadas pelos dois primeiros bytes. São possíveis portanto um numero de redes dessa classe da ordem de 16.256. Faca
as contas: se você já sabe que a rede ira começar em 128 e terminara em 191 (o próximo nível da hierarquia das redes
começara em 192) , basta subtrair 128 de 192, o resultado você multiplica por 256. Assim, você ira obter 16.384. Por
exemplo: o resultado que você obteve foi 64 já que o primeiro byte do nível iria de 128 a 192 e o segundo de 0 a 255.
Assim, como exemplo, poderíamos ter: 128.0.0.1 ate 191.255.255.254. O numero de hosts disponíveis nessa classe eu acho
que você já sabe como calcular: 256 elevado ao quadrado (são os dois últimos bytes restantes). Teríamos então 65.536. Esse
é o numero possível de hosts conectados nessa classe. No mundo temos então 16.256 redes classe B com um Maximo de
65.536 hosts conectados.
Uma pergunta poderia surgir: "Você começou a contar esta rede a partir de 128, a rede anterior não terminou em
126? Onde esta o numero 127?" - O numero 127 não se destina a identificar redes publicas. De fato, esse numero é
destinado a testes de loopback em uma rede. Um loopback nada mais é do que a conexão que a rede faz com ela mesma
para testes internos, configurações, etc. Isso não é exclusivo de redes e tanto é que loopbacks existem quando queremos
verificar a velocidade de trafego numa comunicação paralela ou serial por exemplo. Dessa forma, uma rede que comece
com 127 não é uma rede que conecte hosts. É um teste interno apenas. Então se você vir 127.0.0.1, por exemplo, isso é um
numero de loopback.
Rede tipo C: Essas são as menores e são as mais numerosas em todo mundo. Provavelmente a sua provedora de
acesso a Internet usa uma rede tipo C. Endereços de rede vão de 192 ate 2.097.152. No mundo são possíveis, então, algo em
torno de 2 milhões de redes com apenas 254 hosts conectados (que é o ultimo byte). Os endereços de rede ficariam então:
192.0.0.1 a 224.255.255.254. Como provavelmente sua provedora não possui apenas 254 usuários cadastrados, ela com
certeza dividiu a sua rede em redes menores cada uma comportando 254 usuários. Isso ira acontecer sempre a medida que a
demanda por acessos a novos usuários aumentar, ou seja, se uma rede classe C já não atende mais a demanda, ela pode ser
aumentada com a inclusão de novas sub-redes. Para se chegar a esse numero de 2 milhões o calculo é o mesmo do que já foi
feito acima, ou seja, redes classe C são identificadas pelos três primeiros bytes então faça somente o 256 elevado ao cubo e
vc achara o valor, certo? Bastante errado.
Ao contrario das outras redes, uma rede classe C possui mais restrições. Uma rede classe C começa do numero 192,
ok. Mas não termina em 256! De fato, ela termina no numero 224. Isso acontece porque números superiores a 224 são
destinados a serviços especiais (com protocolos diferentes) e não são incluídos como identificador de rede. Assim nos
teríamos apenas 32 possibilidades no primeiro byte (de 192 ate 224). Os dois bytes seguintes continuariam da mesma forma,
ou seja, não existem restrições e continuariam com 256 possibilidades. Então nos teríamos: 32 x 256 x 256 = 2.097.152. E
assim nos temos o numero de redes disponíveis nessa classe. Na verdade o numero de redes disponíveis é isso menos uma
rede: a 192.168 que é feita quando queremos construir nossa rede particular. Se algum dia você quiser montar sua rede
provavelmente ira nomear seus hosts como: 192.168.0.1; 192.168.0.2.... ate o fim do numero de maquinas disponíveis. Se
chegar na maquina de numero 24, por exemplo, era poderá ser conhecia como: 192.168.2.4.
Outro item a ser comentado é sobre o que se chama de mascara da sub-rede. Isso nada mais é do que a
determinação da classe a qual uma rede pertence. Assim nos poderíamos ter:
 Classe A: 255.0.0.0
 Classe B: 255.255.0.0
 Classe C: 255.255.255.0
Parece desnecessário? Pois é, realmente nos damos a olhar a primeira vista e pensar que não é necessário um tipo
de identificação de redes desse tipo. Bastaria olhar o numero do primeiro byte e isso já seria suficiente p/ saber a que classe
a rede pertence. Isso a nossos olhos é ótimo mas para uma maquina, a que ira analisar pedidos, por exemplo, isso não é
suficiente. Precisamos informar a ela que a rede é do tipo C, A ou B e isso é feito pela mascara da sub-rede (também
chamada de netmask). É necessário esse tipo de informação porque uma rede de amplo espectro, uma classe A, por
exemplo, pode ser dividida em redes classe B que por sua vez pode ser subdividida em redes classe C.
Por exemplo, você pode ter uma rede classe A mas achou muito grande e resolveu dividi-la em varias redes B, no
final você quis varias tipo C, ok, sem problemas. Mas quando você fez isso, você automaticamente criou redes verdadeiras e
não apenas subsividoes. Assim a menor divisão que você fez foi em 20 vezes. Não se deu por satisfeito e resolveu criar
redes menores dentro daquelas 20, vamos supor 5. Cada uma dessas divisões não é tratada como um mero host, por
exemplo, é uma rede inteira. Sendo assim, você precisa informar que aquela subdivisão das 20, as outras 5 redes, não são
hosts e sim redes classe C. E, na verdade, quando se chega a um ponto como esse, nem mesmo uma simples "olhada" nos
números é suficiente para informar que tipo de rede é e fatalmente você ira precisar se certificar disso por meio do netmask.
Isso é importante porque sem essas informações não é possível o roteamento de dados. É necessário manter o nível de
hierarquia das redes.
Se você tem, por exemplo, um numero de rede como: 125.142.75.6 isso parece ser uma rede classe A. Quem pode
garantir? Uma "olhada" nesse numero não é suficiente pra termos certeza. Essa pode ser a nossa divisão de redes que
fizemos nas linhas acima ou então uma rede A verdadeira. Sendo assim, é extremamente necessário informar que essa rede
não é uma rede A e sim uma classe C dentro de uma A. Dependendo di sistema em uso, podemos definir simplesmente pelo
netmask. 255.255.255.0 é suficiente pra informar que essa é uma rede C.
Espero que tenha sido esclarecedor essas informações. É muito importante o conhecimento desses tópicos se quiser
saber mais sobre construção de redes.
Conceitos Técnicos
O protocolo IP possui outras determinações alem de identificar você na rede: ele transforma a informação a ser
enviada em pequenos pacotes cada um contendo em torno de 512 bytes (alguns autores se divergem quanto ao tamanho dos
pacotes, alguns chegam a admitir 200 bytes). Esses pacotes recebem o nome de datagrams e em cada um desses pacotes é
alocada a informação do computador de origem e de destino. Que informação é essa? o numero IP. Assim, se por exemplo
você estabelece uma conexão com algum servidor tipo ftp, junto de cada pacote vai o seu numero IP, para que o servidor
saiba para quem esta enviando os dados, além do próprio numero IP do servidor para que possa ser localizado, lógico.
A respeito do tamanho dos pacotes eles podem ser facilmente percebidos: experimente fazer um upload por e-mail
de um arquivo qualquer de, digamos, 137 kb. Na janela informativa de status da operação você ira perceber que aquele
pacote de 137 kb aumentou para algo em torno de 188 kb. Esse arquivo de 137 kb foi segmentado em varias partes de mais
ou menos 512 bytes cada e foi anexado um cabeçalho informativo feito pelo IP (explicado mais adiante) contendo
informações do computador de origem e de destino. Essa informações adicionais, colocadas em cada pacote, constituem
alguns kbytes a mais em tudo e foi por isso que aumentou para 188 kb.
Um dado interessante a respeito é que algumas aplicações cliente (leia-se programas que recebem exclusivamente
dados) como um mIRC por exemplo, anexa os dois protocolos em seu meio e é perfeitamente configurável o tamanho de
cada pacote, ou seja, você poderia enviar pacotes de dados com 512 ou 200 bytes sem problemas. Contudo, pacotes maiores
são mais confiáveis e é sempre aconselhável você utilizar pacotes de 512 bytes. Também não vamos exagerar e colocar
pacotes de 1024 bytes. Absurdo. É possível? é. Mas não é uma boa idéia.
Uma característica interessante da rede é que os dados transformados em pacotes podem se perder no caminho da
transmissão. Nos primórdios do TCP/IP, essas informações não se perdiam tão facilmente mas com o crescente
congestionamento da rede, um ou outro pacote pode se perder no caminho ou no mínimo chegar na ordem errada. Isso
ocorre primeiramente porque qualquer coisa enviado através de rede deve passar pelo meio físico e nesse meio essas
"coisas" nada mais são do que sinais elétricos provenientes de um meio digital. Assim, um pacote de informações são vários
pulsos de interrupção numa corrente continua.
Assim, os pacotes são enviados sequencialmente mas não é garantida a sucessão correta, assim um pacote de
numero 20 pode chegar na frente do 15. Ai então entra o TCP responsável pelo recebimento dos pacotes que chegam. Esse
protocolo tem sua maior função no reordenamento dos pacotes. Assim, se um pacote enviado pelo IP se perde no caminho,
o TCP manda novo pedido ao computador que estava enviando a informação a fim de ser restabelecido o processo e o envio
novamente do mesmo pacote ou então, se todos os pacotes conseguiram chegar, po-los na ordem correta. Esse pedido
geralmente é feito pelo protocolo ICMP (parte do IP que trata de controle de erros, explicado mais adiante) o qual é enviado
em um pacote menor do que 512 bytes informando que um pacote chegou de forma inadequada ou não chegou.
Perceba que a informação não chega inteira mas segmentada em centenas ou milhares de pacotes, dependendo do
tamanho do que se quer enviar. Então como o TCP ao receber o pacote sabe em que ordem ele deve ficar? Nesse caso entra
o TCP de origem. O TCP do computador de origem fornece um numero seqüencial a cada pacote segmentado pelo IP.
Assim, quando os pacotes chegam no destino, o TCP de destino se incumbe de "ver" esses números e po-los na ordem
correta e não na ordem em que chegam. Já pensou se não fosse assim? Quando uma pagina html fosse "aberta" no seu
navegador ficaria tudo desorganizado, porque o seu TCP os receberia e os ordenaria do modo como chegassem.
Outro protocolo que acredito que poucas pessoas possam conhecer ou se conhecem tem certa duvida é o UDP. O
UDP (User Datagram Protocol) possui as mesmas qualificações que o protocolo TCP e exerce a nível de rede a mesma
coisa. A diferença real se resume no fato de que qualquer conexão realizada por UDP é bastante falha e insegura. Enquanto
o TCP fornece um numero seqüencial a cada pacote a fim de serem reorganizados na ordem correta, o UDP envia os pacotes
a esmo, ou seja, sem seqüência. Quando esse pacotes chegam no destino fica meio difícil a conexão. Mas ai fica a pergunta:
para que diabos serve o UDP então? Bom, se você tem certeza que possui uma conexão confiável e sabe que os pacotes não
irão se perder no meio do caminho ou então que chegarão na ordem correta, o UDP pode ser a sua escolha. Nesse caso não
se perderia tempo na reordenação de pacotes.
Um exemplo prático de quando se usa o UDP? quando se nuka alguém ou quando se da o chamado death ping.
Ninguém vai se preocupar em enviar alguma coisa a vitima na ordem correta. O objetivo do nuke eu creio que você já
conheça. Então pode ser uma boa pedida já que o envio é mais rápido, se bem que nuke alem de ser condenável é um pouco
antigo e diversas formas de proteção já foram feitas. Bom, então alguém poderia se perguntar: "mas e como fica o IP?".
Bom, o IP fica na mesma, ou seja, ele, a nível de rede, continua a exercer a mesma função de antes e não é porque foi
incluído o UDP que ele não vai ser usado. Isso não implica. O TCP ai foi substituído meramente para se acelerar o processo
ou com algum outro propósito como o do nuke ou death ping.
Os Servidores
Bom, resolvi incluir esse adido como parte integrante desse tutorial a respeito de modos de transmissão em redes
por ser um assunto que, acredito, muita gente ainda faça bastante confusão.
Como havia dito em outra parte do texto, IP são números de 32 bits segmentados em quatro partes cada uma
contendo oito bits, um byte portanto. Quando você faz uma comunicação remota com um computador qualquer em especial
os que atendem serviços, os chamados servidores, o IP fornece um numero de identificação que recebe o nome de IP como
simples alusão ao serviço que ele faz. Não só o numero de identificação do seu próprio host mas também do servidor que
atendera os pedidos. Então, quando você faz a solicitação de um pedido qualquer a um servidor como o ftp por exemplo,
junto a ele vai o seu IP e o IP do servidor. Lembre-se que o processo IP "quebra" qualquer informação em pequenos pacotes
conhecidos como datagrams. Então como é feita a comunicação? Bastante simples: vamos supor que você esteja no seu
navegador, um Netscape por exemplo, e você quer acessar uma pagina qualquer. Então você descreve uma url e aponta o
browser nesse pedido. O IP então entra em ação. Ele agrupa esse pedido num único pacote contendo os Ips de identificação
e manda ao servidor que atendera os pedidos.
(*Eu não sei como funciona um servidor como um Windows® NT, por exemplo, então vou descrever como se processa tudo
em uma maquina padrão POSIX, um Linux por exemplo. Embora o NT esteja incluído nesse padrão também, eu não sei
como o serviço é atendido por lá.*)
Esse pacote chegando por lá é recebido por algo como se fosse um grande secretario geral de um grande
departamento. O responsável nesse caso seria o que é chamado em servidores UNIX de daemon, mais conhecido como
inetd (não vou entrar em detalhes sobre isso, acredito que ira fugir bastante do assunto em questão). Esse "secretario geral"
atende todos os pedidos que chegam, mas desvia o serviço a um servidor especifico que no nosso exemplo será o httpd
(outro daemon) . Nesse caso, o serviço que o inetd fez foi somente "avisar" ao pacote que ele por si não faz o serviço, mas
avisa quem é o responsável, o httpd. Então, chegado o pedido, o httpd verifica em seus arquivos (novamente nomes de
arquivos não são importantes ao entendimento do assunto, isso é uma questão especifica a assuntos em UNIX e não é
preciso entrar em detalhes sobre isso) onde se encontra, por exemplo, uma pagina qualquer. Encontrando essa pagina, o
httpd a organiza e segmenta em pacotes e envia ao computador que fez o pedido, o cliente.
Os pacotes recém chegados no computador de origem são colocados em sua ordem correta e a aplicação cliente, o
Netscape, ira se encarrega de mostrar o conteúdo da pagina que foi organizada.
Portas de Comunicação
Esse é outro assunto bastante difundido na internet e temido por muita gente. Mas antes, merece uma descrição
detalhada:
Tal como os números IP, números de portas são formados por bits. As portas são atendidas em números que vão de
0 a 65534 (na verdade o mais correto seria de 1 a 65535. Ate agora não vi nenhum servidor que atendesse em portas de
numero 0). Números de portas de comunica são formadas por seqüência de 16 bits dividido em duas partes cada uma com
um byte portanto e separados por pontos de divisão como em um numero IP.
Como havia dito, números de portas vão de 0 a 65535, são muitas portas portanto e cada uma destinada a alguma
conexão qualquer. Lembre-se que a cada dia são inventados novos serviços que se utilizam do protocolo TCP/IP como meio
e esses novos serviços, vamos citar como exemplo o ICQ, precisam de uma dessas portas disponíveis para conexão.
"Qualquer uma?" -- Sim, qualquer uma. Não ha. um padrão para as portas serem abertas com o mesmo numero anterior. O
Sistema Operacional se encarregara de escolher uma porta adequada não necessariamente igual a anterior.
Números de porta inferiores a 1024 são destinadas ao computador que atende determinado serviço. Voltando ao
exemplo anterior, o dos servidores: observe que esse pedido é sempre atendido na porta 80 (porta padrão de serviços http),
contudo, nada impede que essa porta seja atendida em outro numero. Em relação a isso, tal pratica é muito corriqueira, ou
seja, numa Intranet, por exemplo, é bastante comum o administrador da rede reservar um numero maior a um serviço
especial que não possa ser acessado assim tão facilmente. Nesse ultimo exemplo, vamos supor que o administrador tenha
ficado receoso porque algumas pessoas estão conseguindo acessar um determinado serviço que, embora deva ficar sempre
no ar porque atende a certas pessoas, não deve ser acessível a todos. Então ele pode muito bem mudar a porta padrão do
serviço - vamos supor um telnet que atende na porta 23 - para algo em torno de 56263. Bem, o administrador é realmente
uma pessoa responsável e muda todos os dias o endereço da porta de forma a que ninguém possa acessá-lo assim tão
facilmente, dessa forma se tornando bastante difícil a alguém o acesso a esse serviço. Essa é uma pratica bastante difundida
em servidores particulares visando a segurança de toda a rede, mas não pode ser usada em servidores permanentes como um
provedor de acesso a intenet. Nesse caso , a medida mais correta é inabilitar o serviço inteiro já que não se pode avisar a
todos os usuários que o numero da porta mudou de numero.
Alguém pode estar se perguntando: "Ok, entendi o que você quis dizer. Mas vamos supor que o meu programa
cliente, o que envia o pedido, vamos supor um telnet, queira se comunicar com um servidor telnet remoto. Não saberia ele a
porta correta de comunica?" -- BBBem, não é assim tão simples. Já pensou se tudo fosse assim? Simplesmente eu saberia
onde qualquer serviço é atendido e todo o trabalho do administrador vai por água a baixo com todas aquelas mudanças de
números. Na verdade, o seu telnet envia o pedido e o inetd o repassa ao telned. Mas acontece uma coisa: se eu mudar o
endereço de porta do telnet para outro numero qualquer, o inetd não saberá o numero a não ser que eu o informe. O pedido
vai ser atendido? Nesse caso não. Mas se você indicar a porta correta onde o serviço esta disponível, a comunicação será
estabelecida. Então, você teria de apontar o numero correto ao seu cliente telnet e este enviaria o numero ao servidor
remoto. Simples? Pois é, é assim que as coisas funcionam e a segurança é mantida.
Algo importante que não foi explicado anteriormente é que um dos papeis que o TCP exerce nesse monte de
protocolos é que ele fornece o numero da porta a ser atendida. Assim, me utilizando do cliente telnet, o TCP fornece o
numero da porta. Mas quem envia é o IP.
Confundiu? Vamos dizer assim: O IP é responsável na rede pela transmissão de pacotes, como você já sabe. Em
cada pacote vai o IP de destino e de origem (isso esta meio repetitivo mas é necessário). Isso é como se fosse um envelope
onde no corpo externo da carta vai o endereço para onde quero enviar, o destinatário, e de onde foi mandado, o remetente.
Dentro do envelope vai uma carta. Nessa carta são fornecidos os endereços de portas onde o serviço é atendido. É
interessante dizer que o IP não sabe o numero da porta, isso é papel do TCP ou do próprio UDP. Nem o UDP nem o TCP
sabem para onde vão, ou seja, eles não sabem quais são os números IP.
Bom, ok. Mas e quanto aos números de portas acima de 1024? Bem, essas são destinadas apenas a comunica entre
programas que se utilizam de TCP/IP. Como havia dito mais acima, vamos citar o exemplo do ICQ. Ótimo programa.
Quando você estabelece uma comunicação com os servidores que conectam você ao ICQ, automaticamente é aberta uma
porta de comunica. Se você executar qualquer PortScan para rastreamento de portas abertas, você ira verificar que uma
porta, sempre acima de 1024, foi aberta.
Você pode verificar agora mesmo se alguma porta de comunicação foi aberta no seu micro. Simplesmente no
prompt do seu MS-DOS digite:netstat -an. Algo como o que segue abaixo vai aparecer:
Route Table
Active Connections
Proto Local Address Foreign Address State

TCP 127.0.0.1:1041 0.0.0.0 LISTENING
TCP 127.0.0.1:1041 127.0.0.1:110 ESTABLISHED
TCP 200.215.169.67:1034 200.215.160.63:110 TIME_WAIT
TCP 200.215.169.67:1040 200.215.160.63:110 TIME_WAIT
TCP 200.215.169.67:137 0.0.0.0:0 LISTENING
UDP 200.215.169.67:138 0.0.0.0:0 LISTENING
UDP 200.215.169.67:139 0.0.0.0:0 LISTENING
Podemos interpretar isso assim:
Proto: é o protocolo utilizado para transportar o serviço, nesse caso foi utilizado o TCP, mas poder poderia ter sido
utilizado o UDP sem problemas, quer dizer, ate certo ponto e dependendo do serviço.
Local Address: É o numero de porta local ode foi estabelecida a conexão. Observe que foram todas acima de 1024.
Exceções foram vistas mas serão explicadas.
Foreign Address: É o endereço de porta remoto onde a conexão foi estabelecida. Foi colocado o nome do protocolo que
atende o serviço, o pop3. Poderia ter sido colocado o numero de porta sem problemas, nesse caso ficaria 110.
State: Define o estado em que a conexão se encontra no momento. Desses estados, três foram efetuados:
listening: isso é a espera de conexão que ainda não foi estabelecida. No momento em que foi executado o netstat, a porta
estava sendo ouvida.
Established: Essa não precisa de muita definição, a conexão foi efetuada com sucesso nas portas em questão e o programa
cliente esta recebendo dados de forma normal.
Time Wait: O servidor parou momentaneamente de enviar dados e no momento em que o comando netstat foi executado
isso estava ocorrendo.
Observe as portas que foram estabelecidas no computador local: 1041, 1034, 1040, 137, 138, 139. Como você pode
verificar foram estabelecidas conexões nas portas menores a 1024, como 137, 138, 139. Essas portas atendem serviços
portanto. Vamos a elas:
A porta 139 na realidade é apenas um bug encontrado nas versões Windows® anteriores a OSR2 e pode ser
fechada pelo usuário com programas específicos ou pelo renomeamento de um driver de dispositivo virtual que nesse caso é
o vnbt.386. Os efeitos provocados pelo mau uso dessa porta já são bastante divulgados: isso causa uma pane geral nos
sistemas Windows® e mesmo os NTs mais antigos ainda sofrem com esse problema. Não é um nuke propriamente dito
porque os efeitos são diferentes. Na realidade aproveita-se a falha que o Windows® possui em atender serviços marcados
como urgente (os chamados OOB ou out-of-band). O Windows® da preferência a pacotes marcados dessa forma e relega a
segundo plano as outras conexões que você possui. O efeito é o termino da sua conexão TCP/IP.
Isso significa que alguém poderia tentar usar seu micro com alguma forma de hacking? Provavelmente não. Digo
provavelmente porque a porta 139 é usada ainda como brincadeira por muita gente metida a hacker mas que nada mais
fazem do que cancelar uma conexão TCP/IP e travar a maquina de um usuário inocente (existem exceções). Brincadeira de
criança. Essa porta, portanto, não atende serviços a não ser o de enviar resposta ao pacote OOB.
As portas 137 e 138 são reservadas ao NetBios (Network Input/Output System) do Windows®. Na verdade não é
exclusividade dos sistemas Windows® e pode ser implementado em qualquer maquina. O NetBios foi desenvolvido pela
IBM como forma de servir o micro cliente como host servidor em alguns casos específicos. Assim, alguém usando um
Windows® 95 poderia disponibilizar essas duas portas para permitir serviços como acesso a uma impressora compartilhada
por exemplo. Mas é altamente recomendável que estas portas estejam fechadas. Se você não é usuário de uma rede interna
de algum departamento e ninguém usa seu micro como host servidor temporário para, por exemplo, compartilhar sua
impressora então não ha. nenhum motivo para permanecer com essas portas abertas. O usuário dessa configuração de portas
precisa urgentemente de uma re-configuracao do Windows®. Verifique em seu micro, caso use Windows®, se você esta
com algum serviço compartilhador de redes como o NetBios. Se está, não permita nenhum compartilhamento então. Isso
constitui-se de uma forma de hacking realmente e não é usada por crianças que adoram nukar o usuário inocente, hackers
que possuem conhecimento dessas portas abertas (e tem conhecimento da técnica) podem acessar seu micro da forma como
quiserem já que essas portas são atendentes de serviços ao contrario da porta 139. O Windows® usando o NetBios vai
permitir acesso nesse caso.
Essa descrição acima (do NetBios) não se constitui de uma falha dos sistemas Windows® propriamente dita - é
inclusive anunciada pela Microsoft. É sim uma má configuração do usuário que, por algum descuido, permitiu essa forma
de conexão.
Mas as três portas se encontravam em modo listening o que quer dizer que nenhuma conexão foi estabelecida, o
que não significa que não possa ser feito.
Agora poderia sobrevir uma duvida: "Ok, essas três portas foram estabelecidas e estavam em modo listening mas e
quanto ao endereço do host? Por que não foi informado nada?" - Bom, é simples. As portas estavam abertas apenas, todas as
três, mas nenhum host externo, naquele momento, estava tentando acessá-las Exatamente por isso não foi informado
nenhum IP de identificação remoto. Possivelmente, quando alguém tentasse firmar uma conexão, o IP seria fornecido.
As outras portas maiores, acima de 1024 foram estabelecidas normalmente no computador local sem problemas. O
que acontece é o seguinte: Como expliquei mais acima a respeito de uma conexão telnet, o programa cliente informa a porta
na qual devera ser estabelecida a conexão mas não informa a porta local. Isso será feito depois e quem o fará é o seu
Sistema Operacional. Assim, o computador remoto, o servidor envia um pacote qualquer de volta ao computador de origem
(lembre-se que ele sabe qual o IP de origem) e somente depois disso a porta é aberta. Será que isso seria motivo de
preocupação de alguém? Acredito que, infelizmente, a maioria das pessoas ainda teme essas portas abertas quando dão o
comando netstat. Na verdade não ha. o que se preocupar. As portas são estabelecidas temporariamente e depois que a
conexão é terminada a porta se fecha, a não ser aquelas que são conhecidas, como o bug do Windows® da porta 139 e/ou as
137 e 138. Se isso não acontecesse ninguém receberia informação de lugar nenhum. Assim, uma porta origem e destino
devem ser abertas.
Uma outra duvida que poderia surgir a respeito: "Ok, as portas são fechadas, mas e durante a minha conexão, as
portas estão abertas e não possuem conexão com portas tão altas, qualquer pessoa com um scaneador de portas conseguiria
descobrir facilmente onde estou conectado." -- Calma, não é bem assim. Uma porta só atende um serviço de cada vez e não
consegue estabelecer conexão em dois pontos simultaneamente. Assim, qualquer um que tentasse estabelecer qualquer
comunicação com seu computador primeiro teria de esperar a porta aberta parar de ser solicitada para depois atender outra
coisa. Ou seja, para poder scanear as suas portas de comunicação primeiro o serviço teria de cancelar a conexão que havia
estabelecido antes, o que não é possível , e segundo lhe enviar um pacote informando a porta que esta aberta. Assim, deu
para entender como o scaneador de portas funciona: ele fica perturbando o computador remoto com pacotes aleatórios de
dados (ai entraria o UDP, porque não é necessário nenhuma reorganização de pacotes) funcionando como uma espécie de
ping esperando pelas resposta.
TCP/IP em Camadas
Uma rede TCP/IP é dividida apenas em quatro camadas (não confunda com divisão de redes
em camadas OSI, isso já é aplicado a construção de redes desde o andamento e construção dela em um
escritório, por exemplo ate o ponto final, em outra localidade. Divisão em camadas por TCP/IP não
envolve os conceitos de construção desde a origem real ate o final). A divisão das redes TCP/IP é como
se segue (Esse modelo de rede TCP/IP foi feito pensando-se na origem em relação ao destino):
Aplicação
Transporte
Rede
Físico
Físico: Esse é o próprio meio físico da rede ou , em outras palavras, é onde as coisas acontecem de fato. Assim,
qualquer comunicação entre micros deverão passar pelo meio físico. Nessas camada estão incluídas todos os dispositivos
físicos de sua rede: cabos, placas da rede, enfim todo hardware usado em comunicação em redes esta incluído nessa camada.
Em relação a esse nível, todos os dados são tratados como pulsos elétricos, ou seja, interrupções na corrente continua do
micro.
Rede: Essa camada é a responsável pelo roteamento dos pacotes entre os hosts, ou seja, tem por função encontrar
o caminho mais curto e confiável entres os computadores. É exercida pelo protocolo IP. A nível de redes especificamente,
(não apenas a TCP/IP podemos incluir ainda nessa camada um outro protocolo conhecido como X.25) esse nível é ainda
responsável pelo envio dos pacotes.
Transporte: Essa camada já exclui o protocolo que transporta o serviço, ou seja, ai esta incluído o TCP e/ou o
UDP. Assim, essa camada é a responsável pelos pacotes criados pelo IP da camada anterior. É obrigação da camada de
transporte oferecer a comunicação mais confiável entre os hosts de uma rede e tentar a todo custo enviar dados da forma
mais clara e limpa possível. Caso algum pacote se perda na rede, por exemplo, é obrigação dessa camada enviar novo
pedido a fim de ser restabelecida a conexão correta novamente. Para não evitar confusão nessa camada: o nível mais acima,
o de rede, cria os pacotes e os envia mas lembre-se que o TCP é quem tem por obrigação fornecer uma maneira de colocar
esses pacotes na ordem correta. Assim, o TCP aloca essas informações em cada pacote e o IP o envia. Quando esses pacotes
chegam ao destino, o TCP desse destino é quem vai colocá-los em ordem de acordo com o que o TCP de origem fez.
Aplicação: Aqui se incluem as aplicações processadas (os programas). Assim, quando você faz um pedido a fim
de receber uma pagina html, o seu navegador processa os pacotes que chegam (ai entrar o TCP) e forma a pagina para que
você possa ver. Isso não ocorre apenas com o destino, ou seja, para que você recebesse essas informações um outro
programa teve de ser processado para que as informações chegassem a você.

Tutorial Sobre TCP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tutorial Sobre TCP

Enviado por

Direitos autorais:

Formatos disponíveis

Tutorial sobre TCP/IP

TCP:Transmission Control Protocol

O conjunto de sub-redes da ELOGICA segue abaixo:

Proto Local Address Foreign Address State

Podemos interpretar isso assim:

Você também pode gostar