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 acao a ser executada
(parece definicao de algoritmo mas na verdade pode ate ser encarado como um). Assim, protocolos em
computacao, e em especial a redes, define como computadores podem se comunicar entre si.
Todo computador conectado em rede necessita de uma identificacao, sendo assim, já de posse
dessa identificacao, o protocolo tem por papel primordial estabelecer a conexao mais confiavel e
duradoura possivel 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
informacoes, com que intervalo um conjunto de informacoes deve ser espacado a fim de se obter a
conexao mais confiavel possivel, como começar e como terminar uma conexao, 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, voce pode acessa-la
sem mesmo ter uma conta com um provedor Internet, contudo, o acesso limita-se apenas a rede privada e,
de forma alguma, voce 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 caracteristicas 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 servicos privados do Banco
Itau e usufrui dos servicos 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 varios milhares de quilometros; a comunicacao 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 nao é o unico protocolo utilizado em
comunicao em redes, tanto é que ao mesmo nivel de um IP, por exemplo, existe o x.25 e, ao TCP, o UDP.
E algo mais que algumas pessoas possam fazer confusao é 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
sobrevivencia mutua e sempre "ajudado" por protocolos semelhantes. Na realidade podemos ate mesmo
estudar os dois protocolos separadamente.
O TCP/IP foi adotado como padrao em todo mundo como meio de comunicacao com a Internet.
Algumas empresas podem implementar seus proprios protocolos de comunicacao em redes internas, se
quiserem, mas para a comunicacao com a Internet deverao adaptar seus equipamentos a fim de operar em
TCP/IP.
O TCP/IP foi primeiramente desenvolvido como um projeto particular que atendesse aos
servicos do Governo Americano em especial as Forcas Armadas. No tempo da Guerra Fria, nao era
possivel um nivel de comunicao satisfatorio entre bases comandadas, entao foi necessario a criacao de um
nivel de transmissao de informacoes mais adequado. Logicamente existiam as transmissoes puramente
fisicas com dados trafegando por meio de pulsos eletricos tal qual um barramento transfere dados entre
perifericos. Pensar em algo como isso naqueles tempos era no minimo ridiculo. Como me comunicar
dessa forma com uma base militar a algumas centenas ou milhares de quilometros? Levando em conta
alguns conceitos de eletronica, o sinal se perderia ou se anularia facilmente nesse meio, os fios.
Mesmo levando em conta que fosse possivel tal meio de comunicao, as informacoes nao sao
enviadas como em um protcolo por TCP/IP, ou seja, por pacotes. É tudo enviado de uma vez so. Se a
transmissao por algum motivo fosse interrompida todo o processo iria falhar e a informacao nao chegaria
ao destino final. Desastroso.
Alem de permitir uma conexao mais confiavel em redes, o TCP/IP permitia transmissoes bem
mais arrojadas do que aquelas realizadas em modo puramente fisico, ou seja, unicamente por transmissao
em pulsos. Assim, uma transmissao puramente fisica so poderia ser realizada somente por dois usuarios
por vez e se se quisesse enviar mais informacoes a outros computadores nao seria possivel ou entao
deveria-se fechar uma das conexoes para que a informação pudesse chegar em dois locais. Levando em
conta que naquele tempo a comunicacao era primordial entre varios lugares ao mesmo tempo, esse modo
de transmissao nao era o mais indicado. Pelo TCP/IP (outros protocolos permitiam isso tambem) era
possivel comunicacao entre vários computadores ao mesmo tempo e isso atendia as pretensoes da epoca.
Nesse tempo, os cientistas tiveram a ideia de transmissao por pacotes, ou seja, somente partes da
informacao que deveria ser transmitida seriam enviadas. Assim, uma mensagem nao corria o risco de se
perder no meio da transmissao e mesmo uma conexao mal realizada nao seria de toda inutil.
Bem ,alguem poderia estar se perguntando: "Tudo bem, entendi o que você quis dizer, mas se se
usa qualquer protocolo para meios de comunicao atraves de pacotes segmentados, isso tambem implica
um meio fisico de transmissao e nesse meios os dados trafegam normalmente como pulsos eletricos
tambem." -- Ok, você esta certo, nao ha diferencas em como a informação chega ao destino, ha sim no
modo como ela é enviada. Como sera explicado mais adiante, o IP segmenta a informação em varios
pacotes e esse pacotes sao tratados meramente como pulsos eletricos quando transmitidos e quando
chegam ao computador destino, mas o TCP (o responsavel pelo recebimento) implementa um metodo
seguro de transmissao, isso porque se o que se queria ser enviado nao chegou ao destino de forma
completa, uma nova conexao pode ser restabelecida sem prejuizo do que já havia sido feito.
Creio que você já deve ter ouvido falar no GetRight nao? Otimo programa. Isso seria um bom
exemplo para dar a você: quando uma conexao termina por qualquer motivo com o meio de origem, o que
envia os dados, uma nova conexo pode ser estabelecida sem prejuizo dos dados que estavam sendo
recebidos, ou seja, pode ser reinicializada de onde se parou sem problemas. Assim funciona o meio de
transmissao de pacotes e acho que você já pegou o espirito da coisa sobre a importancia desse protocolo.
O protocolo TCP/IP implantou um novo conceito arrojado no modo de transmissao mundial
entre redes mesmo as heterogeneas (Sistemas Operacionais diferentes) e qualquer Sistema que tenha por
pretensao conectar o usuario em rede mundial Internet deve ter tais protocolos instalados Bom, era isso
que eu queria falar a você como introducao. Agora vamos a parte tecnica da coisa.
Conceitos Técnicos
Antes de comecar, um esclarecimento: Um provedor de acesso a internet funciona por concessao
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 estao conectadas as redes menores que oferecem servicos, as provedoras. É o nivel mais alto
das redes. Os backbones nacionais sao: RNP, Embratel, Unysis, Global One, IBM e Banco Rural. Creio
que sao os unicos ate o momento. Esse sao os de nivel mais alto no Brasil, mas existem os backbones
estaduais tambem (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 nivel, os backbones nacionais. Se seu estado nao
possui backbone provavelmente sua provedora utiliza um backbone de outro estado ou entao de algum
instituto de tecnologia proprio que possa fazer pelo menos um roteamento satisfatorio.
Quando estabelecemos uma comunicacao com nosso provedor de acesso a internet, por exemplo,
nos é atribuido um numero de identificacao na rede. Esse numero de identificacao é 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 teriamos 4 bytes. Se voce recebe por exemplo 11001000.11111001.11011111.1110010 esse
numero define voce no mundo inteiro, ou seja, seu computador é unico na internet naquele momento e
voce é perfeitamente identificado por ele. Assim como um numero de telefone, não existem dois numeros
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 identificacao é que, como foi dito, sao um conjunto de bits
e como tal é representado por numeros binarios. O mesmo numero acima traduzido para tabela decimal
ficaria: 200.249.223.114. Isso é importante notar, porque um numero como esse nao é dado a voce em
formato decimal mas sim binario e depois convertido gracas ao servidor ou servidores DNS. Outra coisa
interessante a ser dita a respeito é que numeros IP nunca ultrapassam o patamar de numero 256. Assim,
voce nunca ira ver nada como 200.286, isso não é possivel. Simplesmente porque a tabela de conversao
atinge somente 256 possibilidades numericas (de 0 a 255). Portanto, o maximo que voce ira ver sera 255
como numero identificador de um dos segmentos do quarteto decimal. Na realidade poderiamos dizer 253
possibilidades porque o numero 0 eh destinado a processos especiais e 255 não pode ser atribuido a
numeros IP de hosts, eles possuem outra finalidade (a mascara de sub-rede). Maiores detalhes sobre isso
na secao "HIERARQUIA DE REDES".
Outro fato que eu acredito muitas pessoas facam confusao é a respeito do host. Um host nada
mais é do que um computador conectado em rede (em uma rede interna ele tambem pode ser chamado de
nó). Vamos citar um exemplo de provedora, a ELOGICA. Quando voce disca para la e você é conectado,
eles te fornecem um numero IP, ok. Para a ELOGICA voce nada mais é do que um computador
conectado na rede dela, meramente um numero de identificacao.
Como identifico um host? simples. Um endereco IP é dividido em duas partes: uma destinada a
identificao 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 definicao mais acima, para nao ficar perdido) sao destinados a rede, entao: 200.249 é a rede
a qual me conectei. Ok. Os outros dois ultimos bytes definem o host: 223.114. Entao, para ficar facil, eu
sou um micro chamado de host com identificacao 223.114 conectado na rede 200.249.
Mais outra coisa deve ser dita: acho que voce já ouviu falar em sub-rede, claro. Pois é, uma sub-
rede nada mais é do que uma rede hierarquicamente inferior em relacao a uma rede maior. Geralmente, os
numeros que identificam a sub-rede sao referidos ao terceiro byte da cadeia do IP, assim o mesmo
numero 200.249.223.114 pode definir uma sub-rede de identificacao 223. Como voce pode ver, uma rede
pode ter varias sub-redes menores cada uma interdependente entre si mas dependente em relacao a rede
maior.
(*Esse conceito de identificacao de sub-redes envolve detalhes maiores e voce ira obter melhores
informacoes na secao "HIERARQUIA DE REDES"*)
Voltando ao exemplo da ELOGICA: ela possui varias sub-redes cada uma com um papel
diferente mas de importancia 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 varios
outros departamentos menores cada um com um servico especifico. Assim, poderiamos ter 200.249.223;
200.249.238; 200.249.219; 200.249.218, etc. Cada uma dessas sub-redes com uma funcao especifica. Se
você por exemplo, se conecta a rede e recebe: 200.249.219.15 entao voce é um host de numero 15 dentro
da sub-rede 219 na rede 200.249.
(*Infelizmente desconheco o menor e o maior nivel de rede concedido a ELOGICA porque, como eh uma
rede classe C, apenas o segundo byte não informa a sub-rede verdadeira. Assim outras redes tambem
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 nao significa que um
host de um usuario nao possa entrar e ser identificado como pertencente a sub-rede 238. De fato, esses
sao enderecos fixos e pertencem aos servidores que atendem servicos tais como o IRC mais acima ou o de
e-mail (se nao me engano o responsavel ai seria o ceiun01). Mas observe que mais abaixo (os dois
ultimos hosts) encontramos numeros de hosts comuns, ou seja, sao de usuarios conectados no momento.
Um outro exemplo:
Nessa sub-rede de agora, a 223 nao ouve nenhum servidor anunciado, apenas usuarios
conectados. Outras sub-redes foram verificadas mas nao houve nenhuma nova inclusao de servidores,
parece que todo o servico se concentra na sub-rede 238. De fato, como sera visto no proximo capitulo,
sub-redes superiores a 224 são destinadas a servicos 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 identificacao 200.249. De fato, assim como ela, a NETPE (uma outra
provedora aqui de PE) tambem recebeu 200.249 como identificacao. Ambas são redes classe C e são
varias pelo mundo. O que vai diferenciar as duas sera 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)
eh quem outorga esses numeros a quem a solicita.
As redes são divididas hierarquicamente no mundo, assim nos temos rede de maior tamanho e
aquelas menores. Essa definicao 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 pouquissimos
orgaos ao redor do mundo possuem o privilegio de possuir um endereco de rede situado na classe A
(diga-se de passagem, não existem mais enderecos dessa classe disponiveis a novos cadastros, a não ser
que alguem se descadastre). De fato, não eh qualquer organizacao no mundo que possui esse privilegio e
eh apenas concedido a Universidades e organismos Governamentais. A quantidade de enderecos
disponiveis a esse nivel é pequena, atinge numeros de 1 a 126. Observe que não utilizei os caracteres X
pra identificar um outro nivel, isso não eh necessario em classes do tipo A, porque o primeiro byte jah eh
suficiente para a identificacao de toda a rede. Já deu pra perceber portanto que essas redes são muito
poucas mas atende o maior numero possivel de hosts conectados: 16.777.215. No mundo inteiro somente
existe 126 redes classe A com demanda de aproximadamente 16 milhoes de hosts. Entao nos poderiamos
ter: 1.0.0.1 ate 126.255.255.254. Esses dezesseis milhoes de hosts reflete o numero de possibilidades
possiveis entre os tres ultimos bytes do quarteto. Assim, se fizermos uma analise combinatoria desses
termos chegariamos no numero em questao. 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 enderecos? Por que
não foram incluidos? - Os outros enderecos de rede não foram incluidos poque são o resultado da analise
combinatoria entre os outros possiveis hosts. Levando em conta que possuimos ainda os tres ultimos
bytes da cadeia do IP, teriamos 256 possibilidades diferentes em um byte da cadeia do IP.
Se temos 256 possibilidades entre cada um dos tres ultimos bytes da cadeia do IP entao faca o
seguinte: eleve 256 ao cubo. O que voce vai obter é exatamente 16.777.216 como resultado. Uma
pergunta interessante poderia surgir: "Certo, mas em outra parte do tutorial voce afirma que o numero 0 e
o 255 não podem ser atribuidos a numeros IP porque possuem outras funcoes" - Não eh bem assim. O que
afirmei eh que numeros de hosts não podem ter esses numeros 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 atribuido aqueles valores a hosts.
Rede tipo B: Essas são as redes intermediarias e possuem enderecos de rede de 128 a 16.384.
Redes desse tipo são identificadas pelos dois primeiros bytes. São possiveis portanto um numero de redes
dessa classe da ordem de 16.256. Faca as contas: se voce já sabe que a rede ira comecar em 128 e
terminara em 191 (o proximo nivel da hierarquia das redes começara em 192) , basta subtrair 128 de 192,
o resultado voce multiplica por 256. Assim, voce ira obter 16.384. Por exemplo: o resultado que voce
obteve foi 64 jah que o primeiro byte do nivel iria de 128 a 192 e o segundo de 0 a 255. Assim, como
exemplo, poderiamos ter: 128.0.0.1 ate 191.255.255.254. O numero de hosts disponiveis nessa classe eu
acho que voce já sabe como calcular: 256 elevado ao quadrado (são os dois ultimos bytes restantes).
Teriamos entao 65.536. Esse é o numero possivel de hosts conectados nessa classe. No mundo temos
entao 16.256 redes classe B com um maximo de 65.536 hosts conectados.
Uma pergunta poderia surgir: "Voce comecou 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 eh destinado a testes de loopback em uma rede. Um loopback nada mais
eh do que a conexao que a rede faz com ela mesma para testes internos, configuracoes, etc. Isso não eh
exclusivo de redes e tanto eh que loopbacks existem quando queremos verificar a velocidade de trafego
numa comunicacao paralela ou serial por exemplo. Dessa forma, uma rede que comece com 127 não eh
uma rede que conecte hosts. Eh um teste interno apenas. Entao se voce vir 127.0.0.1, por exemplo, isso eh
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. Enderecos de rede vao de 192 ate 2.097.152. No
mundo são possiveis, entao, algo em torno de 2 milhoes de redes com apenas 254 hosts conectados (que
eh o ultimo byte). Os endereços de rede ficariam entao: 192.0.0.1 a 224.255.255.254. Como
provavelmente sua provedora não possui apenas 254 usuarios cadastrados, ela com certeza dividiu a sua
rede em redes menores cada uma comportando 254 usuarios. Isso ira acontecer sempre a medida que a
demanda por acessos a novos usuarios aumentar, ou seja, se uma rede classe C jah não atende mais a
demanda, ela pode ser aumentada com a inclusao de novas sub-redes. Para se chegar a esse numero de 2
milhoes o calculo eh o mesmo do que jah foi feito acima, ou seja, redes classe C são identificadas pelos
tres primeiros bytes entao 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 restricoes. Uma rede classe C
comeca do numero 192, ok. Mas não termina em 256! De fato, ela termina no numero 224. Isso acontece
porque numeros superiores a 224 são destinados a servicos especiais (com protocolos diferentes) e não
são incluidos como identificador de rede. Assim nos teriamos apenas 32 possibilidades no primeiro byte
(de 192 ate 224). Os dois bytes seguintes continuariam da mesma forma, ou seja, não existem restricoes e
continuariam com 256 possiblidades. Entao nos teriamos: 32 x 256 x 256 = 2.097.152. E assim nos temos
o numero de redes disponiveis nessa classe. Na verdade o numero de redes disponiveis eh isso menos
uma rede: a 192.168 que eh feita quando queremos construir nossa rede particular. Se algum dia voce
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 disponiveis. Se chegar na maquina de numero 24, por exemplo, era podera ser
conhecia como: 192.168.2.4.
Outro item a ser comentado eh sobre o que se chama de mascara da sub-rede. Isso nada mais
eh do que a determinacao da classe a qual uma rede pertence. Assim nos poderiamos ter:
• Classe A: 255.0.0.0
• Classe B: 255.255.0.0
• Classe C: 255.255.255.0
Parece desnecessario? Pois eh, realmente nos damos a olhar a primeira vista e pensar que não eh
necessario um tipo de identificacao de redes desse tipo. Bastaria olhar o numero do primeiro byte e isso
jah seria suficiente p/ saber a que classe a rede pertence. Isso a nossos olhos eh otimo mas para uma
maquina, a que ira analisar pedidos, por exemplo, isso não eh suficiente. Precisamos informar a ela que a
rede eh do tipo C, A ou B e isso eh feito pela mascara da sub-rede (tambem chamada de netmask). Eh
necessario esse tipo de informcao 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, voce pode ter uma rede classe A mas achou muito grande e resolveu dividi-la em
varias redes B, no final voce quis varias tipo C, ok, sem problemas. Mas quando voce fez isso, voce
automaticamente criou redes verdadeiras e não apenas subsividoes. Assim a menor divisao que voce 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 divisoes não eh tratada como um mero host, por exemplo, eh uma rede inteira. Sendo
assim, voce precisa informar que aquela subdivisao 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
numeros eh suficiente para informar que tipo de rede é e fatalmente voce ira precisar se certificar disso
por meio do netmask. Isso eh importante porque sem essas informacoes não eh possivel o roteamento de
dados. Eh necessario manter o nivel de hierarquia das redes.
Se voce 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 eh suficiente pra termos certeza. Essa
pode ser a nossa divisao de redes que fizemos nas linhas acima ou entao uma rede A verdadeira. Sendo
assim, é extremamente necessario informar que essa rede não eh 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
eh suficiente pra informar que essa eh uma rede C.
Espero que tenha sido esclarecedor essas informacoes. Eh muito importante o conhecimento
desses topicos se quiser saber mais sobre construcao de redes.
Conceitos Técnicos
O protocolo IP possui outras determinacoes alem de identificar voce na rede: ele transforma a
informacao 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 informacao do computador de origem e de
destino. Que informacao é essa? o numero IP. Assim, se por exemplo voce estabelece uma conexao 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, alem do proprio numero IP do servidor para que possa ser localizado, logico.
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
operacao voce 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 informacoes do computador de
origem e de destino. Essa informacoes adcionais, 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 aplicacoes cliente (leia-se programas que
recebem exclusivamente dados) como um mIRC por exemplo, anexa os dois protocolos em seu meio e é
perfeitamente configuravel o tamanho de cada pacote, ou seja, voce poderia enviar pacotes de dados com
512 ou 200 bytes sem problemas. Contudo, pacotes maiores sao mais confiaveis e é sempre aconselhavel
voce utilizar pacotes de 512 byes. Tambem nao vamos exagerar e colocar pacotes de 1024 bytes.
Absurdo. É possivel? é. Mas nao é uma boa ideia.
Uma cartacteristica interessante da rede é que os dados transformados em pacotes podem se
perder no caminho da transmissao. Nos primordios do TCP/IP, essas informacoes nao se perdiam tao
facilmente mas com o crescente congestionamento da rede, um ou outro pacote pode se perder no
caminho ou no minimo chegar na ordem errada. Isso ocorre primeiramente porque qualquer coisa enviado
atraves de rede deve passar pelo meio fisico e nesse meio essas "coisas" nada mais sao do que sinais
eletricos provenientes de um meio digital. Assim, um pacote de informacoes sao varios pulsos de
interrupcao numa corrente continua.
Assim, os pacotes sao enviados sequencialmente mas nao é garantida a sucessao correta, assim
um pacote de numero 20 pode chegar na frente do 15. Ai entao entra o TCP responsavel pelo recebimento
dos pacotes que chegam. Esse protocolo tem sua maior funcao 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 informacao a fim de ser reestabelecido o processo e o envio novamente do mesmo pacote ou
entao, se todos os pacotes conseguiram chegar, po-los na ordem correta. Esse pedido geralmente eh 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 nao
chegou.
Perceba que a informacao nao chega inteira mas segmentada em centenas ou milhares de
pacotes, dependendo do tamanho do que se quer enviar. Entao 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 sequencial a cada pacote segmentado pelo IP. Assim, quandos os pacotes chegam no destino,
o TCP de destino se incumbe de "ver" esses numeros e po-los na ordem correta e nao na ordem em que
chegam. Já pensou se nao 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 qualificacoes que o protocolo TCP
e exerce a nivel de rede a mesma coisa. A diferenca real se resume no fato de que qualquer conexao
realizada por UDP é bastante falha e insegura. Enquanto o TCP fornece um numero sequencial a cada
pacote a fim de serem reorganizados na ordem correta, o UDP envia os pacotes a esmo, ou seja, sem
sequencia. Quando esse pacotes chegam no destino fica meio dificil a conexao. Mas ai fica a pergunta:
para que diabos serve o UDP entao? Bom, se voce tem certeza que possui uma conexao confiavel e sabe
que os pacotes nao irao se perder no meio do caminho ou entao que chegarao na ordem correta, o UDP
pode ser a sua escolha. Nesse caso nao se perderia tempo na reordenacao de pacotes.
Um exemplo paratico de quando se usa o UDP? quando se nuka alguem ou quando se da o
chamado death ping. Ninguem vai se preocupar em enviar alguma coisa a vitima na ordem correta. O
objetivo do nuke eu creio que você já conheca. Entao pode ser uma boa pedida já que o envio é mais
rapido, se bem que nuke alem de ser condenavel eh um pouco antigo e diversas formas de protecao jah
foram feitas. Bom, entao alguem poderia se perguntar: "mas e como fica o IP?". Bom, o IP fica na
mesma, ou seja, ele, a nivel de rede, continua a exercer a mesma funcao de antes e nao é porque foi
incluido o UDP que ele nao vai ser usado. Isso não implica. O TCP ai foi substituido meramente para se
acelerar o processo ou com algum outro proposito como o do nuke ou death ping.
Os Servidores
Bom, resolvi incluir esse adido como parte integrante desse tutorial a respeito de modos de
transmissao em redes por ser um assunto que, acredito, muita gente ainda faça bastante confusao.
Como havia dito em outra parte do texto, IP sao numeros de 32 bits segmentados em quatro
partes cada uma contendo oito bits, um byte portanto. Quando voce faz uma comunicacao remota com um
computador qualquer em especial os que atendem servicos, os chamados servidores, o IP fornece um
numero de identificacao que recebe o nome de IP como simples alusao ao serviço que ele faz. Nao so o
numero de identificacao do seu proprio host mas tambem do servidor que atendera os pedidos. Entao,
quando voce faz a solicitacao 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 informacao em pequenos
pacotes conhecidos como datagrams. Entao como é feita a comunicacao? Bastante simples: vamos supor
que voce esteja no seu navegador, um Netscape por exemplo, e voce quer acessar uma pagina qualquer.
Entao voce descreve uma url e aponta o browser nesse pedido. O IP entao entra em açao. Ele agrupa esse
pedido num unico pacote contendo os Ips de identificacao e manda ao servidor que atendera os pedidos.
(*Eu nao sei como funciona um servidor como um Windows® NT, por exemplo, entao vou descrever
como se processa tudo em uma maquina padrao POSIX, um Linux por exemplo. Embora o NT esteja
incluido nesse padrao tambem, eu nao sei como o servico é atendido por la.*)
Esse pacote chegando por la é recebido por algo como se fosse um grande secretario geral de um
grande departamento. O responsavel nesse caso seria o que é chamado em servidores UNIX de daemon,
mais conhecido como inetd (nao vou entrar em detalhes sobre isso, acredito que ira fugir bastante do
assunto em questao). Esse "secretario geral" atende todos os pedidos que chegam, mas desvia o sercvico a
um servidor especifico que no nosso exemplo sera o httpd (outro daemon) . Nesse caso, o servico que o
inetd fez foi somente "avisar" ao pacote que ele por si nao faz o servico, mas avisa quem é o responsavel,
o httpd. Entao, chegado o pedido, o httpd verifica em seus arquivos (novamente nomes de arquivos nao
sao importantes ao entendimento do assunto, isso é uma questao especificca a assuntos em UNIX e nao é
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 recem chegados no computador de origem sao colocados em sua ordem correta e a
aplicacao cliente, o Netscape, ira se encarrega de mostrar o conteudo 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 descricao detalhada:
Tal como os numeros IP, numeros de portas sao formados por bits. As portas sao atendidas em
numeros que vao de 0 a 65534 (na verdade o mais correto seria de 1 a 65535. Ate agora nao vi nenhum
servidor que atendesse em portas de numero 0). Numeros de portas de comunicao sao formadas por
sequencia de 16 bits dividido em duas partes cada uma com um byte portanto e separados por pontos de
divisao como em um numero IP.
Como havia dito, numeros de portas vao de 0 a 65535, sao muitas portas portanto e cada uma
destinada a alguma conexao qualquer. Lembre-se que a cada dia sao inventados novos servicos que se
utilizam do protocolo TCP/IP como meio e esses novos servicos, vamos citar como exemplo o ICQ,
precisam de uma dessas portas disponiveis para conexao. "Qualquer uma?" -- Sim, qualquer uma. Nao ha
um padrao para as portas serem abertas com o mesmo numero anterior. O Sistema Operacional se
encarregara de escolher uma porta adequada nao necessariamente igual a anterior.
Numeros de porta inferiores a 1024 sao destinadas ao computador que atende determinado
servico. Voltando ao exemplo anterior, o dos servidores: observe que esse pedido é sempre atendido na
porta 80 (porta padrao de servicos http), contudo, nada impede que essa porta seja atendida em outro
numero. Em relacao a isso, tal pratica é muito corriqueira, ou seja, numa Intranet, por exemplo, é bastante
comum o administrador da rede reservar um numero maior a um servico especial que nao possa ser
acessado assim tao facilmente. Nesse ultimo exemplo, vamos supor que o administrador tenha ficado
receoso porque algumas pessoas estao conseguindo acessar um determinado servico que, embora deva
ficar sempre no ar porque atende a certas pessoas, nao deve ser acessivel a todos. Entao ele pode muito
bem mudar a porta padrao do servico - vamos supor um telnet que atende na porta 23 - para algo em torno
de 56263. Bem, o administrador é realmente uma pessoa responsavel e muda todos os dias o endereco da
porta de forma a que ninguem possa acessa-lo assim tao facilmente, dessa forma se tornando bastante
dificil a alguem o acesso a esse servico. Essa é uma pratica bastante difundida em servidores particulares
visando a seguranda de toda a rede, mas nao pde ser usada em servidores permanentes como um proevdor
de acesso a intenet. Nesse caso , a medida mais correta é inabilitar o servico inteiro já que nao se pode
avisar a todos os usuarios que o numero da porta mudou de numero.
Alguem pode estar se perguntando: "Ok, entendi o que voce quis dizer. Mas vamos supor que o
meu progama cliente, o que envia o pedido, vamos supor um telnet, queira se comunicar com um servidor
telnet remoto. Nao saberia ele a porta correta de comunicao?" -- BBBem, nao é assim tao simples. Já
pensou se tudo fosse assim? Simplesmente eu saberia onde qualquer servico é atendido e todo o trabalho
do administrador vai por agua a baixo com todas aquelas mudancas de numeros. Na verdade, o seu telnet
envia o pedido e o inetd o repassa ao telned. Mas acontece uma coisa: se eu mudar o endereco de porta do
telnet para outro numero qualquer, o inetd nao sabera o numero a nao ser que eu o informe. O pedido vai
ser atendido? Nesse caso nao. Mas se voce indicar a porta correta onde o servico esta disponivel, a
comunicacao sera estabelecida. Entao, voce 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 seguranca é
mantida.
Algo importante que nao 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 é responsavel na rede pela transmissao de pacotes, como
você já sabe. Em cada pacote vai o IP de destino e de origem (isso esta meio repetitivo mas é necessario).
Isso é como se fosse um envelope onde no corpo externo da carta vai o endereço para onde quero enviar,
o destinatario, e de onde foi mandado, o remetente. Dentro do envelope vai uma carta. Nessa carta sao
fornecidos os enderecos de portas onde o servico é atendido. É interessante dizer que o IP nao sabe o
numero da porta, isso é papel do TCP ou do proprio UDP. Nem o UDP nem o TCP sabem para onde vao,
ou seja, eles nao sabem quais sao os numeros IP.
Bom, ok. Mas e quanto aos numeros de portas acima de 1024? Bem, essas sao destinadas apenas
a comunicao entre programas que se utilizam de TCP/IP. Como havia dito mais acima, vamos citar o
exemplo do ICQ. Otimo programa. Quando voce estabelece uma comunicacao com os servidores que
conectam voce ao ICQ, automaticamente é aberta uma porta de comunicao. Se voce executar qualquer
PortScan para rastreamento de portas abertas, voce ira verificar que uma porta, sempre acima de 1024, foi
aberta.
Voce pode verificar agora mesmo se alguma porta de comunicacao 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 servico, nesse caso foi utilizado o TCP, mas poder
poderia ter sido utilizado o UDP sem problemas, quer dizer, ate certo ponto e dependendo do servico.
Local Address: É o numero de porta local ode foi estabelecida a conexao. Observe que foram todas
acima de 1024. Excecoes foram vistas mas serao explicadas.
Foreign Address: É o endereco de porta remoto onde a conexao foi estabelecida. Foi colocado o nome
do protocolo que atende o servico, o pop3. Poderia ter sido colocado o numero de porta sem problemas,
nesse caso ficaria 110.
State: Define o estado em que a conexao se encontra no momento. Desses estados, tres foram efetuados:
listening: isso é a espera de conexao que ainda nao foi estabelecida. No momento em que foi executado o
netstat, a porta estava sendo ouvida.
Established: Essa nao precisa de muita definicao, a conexao foi efetuada com sucesso nas portas em
questao 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 voce pode verificar foram estabelecidas conexoes nas portas menores a 1024, como 137, 138,
139. Essas portas atendem servicos portanto. Vamos a elas:
A porta 139 na realidade é apenas um bug encontrado nas versoes Windows® anteriores a OSR2
e pode ser fechada pelo usuario com programas especificos ou pelo renomeamento de um driver de
dispositivo virtual que nesse caso é o vnbt.386. Os efeitos provocados pelo mau uso dessa porta já sao
bastante divulgados: isso causa uma pane geral nos sistemas Windows® e mesmo os NTs mais antigos
ainda sofrem com esse problema. Nao é um nuke propriamente dito porque os efeitos sao diferentes. Na
realidade aproveita-se a falha que o Windows® possui em atender servicos marcados como urgente (os
chamados OOB ou out-of-band). O Windows® da preferencia a pacotes marcados dessa forma e relega a
segundo plano as outras conexoes que você possui. O efeito é o termino da sua conexao TCP/IP.
Isso siginifica que alguem poderia tentar usar seu micro com alguma forma de hacking?
Provavelmente nao. 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 conexao TCP/IP e travar a maquina
de um usuario inocente (existem exceçoes). Brincadeira de criança. Essa porta, portanto, nao atende
servicos a nao ser o de enviar resposta ao pacote OOB.
As portas 137 e 138 sao reservadas ao NetBios (Network Input/Output System) do Windows®.
Na verdade nao é 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 especificos. Assim, alguem usando um Windows® 95 poderia disponibilizar essas duas
portas para permitir servicos como acesso a uma impressora compartilhada por exemplo. Mas é altamente
recomendavel que estas portas estejam fechadas. Se voce nao é usuario de uma rede interna de algum
departamento e ninguem usa seu micro como host servidor temporario para, por exemplo, compartilhar
sua impressora entao nao ha nenhum motivo para permanecer com essas portas abertas. O usuario dessa
configuracao de portas precisa urgentemente de uma re-configuracao do Windows®. Verifique em seu
micro, caso use Windows®, se voce esta com algum servico compartilhador de redes como o NetBios. Se
está, nao permita nenhum compartilhamento entao. Isso constitui-se de uma forma de hacking realmente e
nao é usada por criancas que adoram nukar o usuario inocente, hackers que possuem conhecimento dessas
portas abertas (e tem conhecimento da tecnica) podem acessar seu micro da forma como quiserem jah que
essas portas sao atendentes de servicos ao contrario da porta 139. O Windows® usando o NetBios vai
permitir acesso nesse caso.
Essa descricao acima (do NetBios) nao se constitui de uma falha dos sistemas Windows®
propriamente dita - é inclusive anunciada pela Microsoft. É sim uma má configuracao do usuario que, por
algum descuido, permitiu essa forma de conexao.
Mas as tres portas se encontravam em modo listening o que quer dizer que nenhuma conexao foi
estabelecida, o que nao significa que nao possa ser feito.
Agora poderia sobrevir uma duvida: "Ok, essas tres portas foram estabelecidas e estavam em
modo listening mas e quanto ao endreço do host? Por que nao foi informado nada?" - Bom, é simples. As
portas estavam abertas apenas, todas as tres, mas nenhum host externo, naquele momento, estava tentando
acessa-las Exatamente por isso nao foi informado nenhum IP de identificação remoto. Possivelmente,
quando alguem tentasse firmar uma conexao, o IP seria fornecido.
As outras portas maiores, acima de 1024 foram estabecidas normalmente no computador local
sem problemas. O que acontece é o seguinte: Como expliquei mais acima a respeito de uma conexao
telnet, o programa cliente informa a porta na qual devera ser estabelecida a conexao mas nao informa a
porta local. Isso sera feito depois e quem o fara é o seu Sistema Operacional. Assim, o computador
remoto, o servidor envia um pacote qualquer de volta ao computador de origem (lember-se que ele sabe
qual o IP de origem) e somente depois disso a porta é aberta. Sera que isso seria motivo de preocupacao
de alguem? Acredito que, infelizmente, a maioria das pessoas ainda temem essas portas abertas quando
dao o comando netstat. Na verdade nao ha o que se preocupar. As portas sao estabelecidas
temporariamente e depois que a conexao é terminada a porta se fecha, a nao ser aquelas que sao
conhecidas, como o bug do Windows® da porta 139 e/ou as 137 e 138. Se isso nao acontecesse ninguem
receberia informacao de lugar nenhum. Assim, uma porta origem e destino devem ser abertas.
Uma outra duvida que poderia surgir a respeito: "Ok, as portas sao fechadas, mas e durante a
minha conexao, as portas estao abertas e nao possuem conexao com portas tao altas, qualquer pessoa com
um scaneador de portas conseguiria descobrir facilmente onde estou conectado." -- Calma, nao é bem
assim. Uma porta so atende um servico de cada vez e nao consegue estabelecer conexao em dois pontos
simultaneamente. Assim, qualquer um que tentasse estabelecer qualquer comunicacao 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 comunicacao primeiro o servico teria de cancelar a conexao
que havia estabelecido antes, o que nao é possivel , 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 aleatorios de dados (ai entraria o UDP, porque nao é necessrio nenhuma
reorganizacao de pacotes) funcionando como uma especie de ping esperando pelas resposta.
TCP/IP em Camadas
Uma rede TCP/IP eh dividida apenas em quatro camadas (não confunda com divisao de redes
em camadas OSI, isso jah eh aplicado a construcao de redes desde o andamento e construcao dela em um
escritorio, por exemplo ate o ponto final, em outra localidade. Divisao em camadas por TCP/IP não
envolve os conceitos de construcao desde a origem real ate o final). A divisao das redes TCP/IP eh como
se segue (Esse modelo de rede TCP/IP foi feito pensando-se na origem em relacao ao destino):
Aplicação
Transporte
Rede
Físico
Fisico: Esse é o proprio meio fisico da rede ou , em outras palavras, é onde as coisas
acontecem de fato. Assim, qualquer comunicacao entre mcros deverao pessar pelo meio fisico. Nessas
camada esto incluidas todos os dispositivos fisicos de sua rede: cabos, placas da rede, enfim todo
hardware usado em comunicacao em redes esta incluido nessa camada. Em relacao a esse nivel, todos os
dados sao tratados como pulsos eletricos, ou seja, interrupcoes na corrente continua do micro.
Rede: Essa camada é a responsavel pelo roteamento dos pacotes entre os hosts, ou seja, tem
por funcao encontrar o caminho mais curto e confiavel entres os computadores. Eh exercida pelo
protocolo IP. A nivel de redes espcificicamente, (não apenas a TCP/IP podemos incluir ainda nessa
camada um outro protocolo conhecido como X.25) esse nivel eh ainda responsavel pelo envio dos
pacotes.
Transporte: Essa camada jah inclue o protocolo que transporta o servico, ou seja, ai esta
incluido o TCP e/ou o UDP. Assim, essa camada eh a responsavel pelos pacotes criados pelo IP da
camada anterior. Eh obrigacao da camada de transporte oferecer a comunicacao mais confiavel entre os
hosts de uma rede e tentar a todo custo enviar dados da forma mais clara e limpa possivel. Caso algum
pacote se perda na rede, por exemplo, eh obrigacao dessa camada enviar novo pedido a fim de ser
restabecida a conexao correta novamente. Para não evitar confusao nessa camada: o nivel mais acima, o
de rede, cria os pacotes e os envia mas lembre-se que o TCP eh quem tem por obrigacao fornecer uma
maneira de colocar esses pacotes na ordem correta. Assim, o TCP aloca essas informacoes em cada
pacote e o IP o envia. Quando esses pacotes chegam ao destino, o TCP desse destino eh quem vai coloca-
los em ordem de acordo com o que o TCP de origem fez.
Aplicação: Aqui se incluem as aplicacoes processadas (os programas). Assim, quando voce
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 voce possa ver. Isso não ocorre apenas com o destino, ou seja,
para que voce recebesse essas informacoes um outro programa teve de ser processado para que as
informacoes chegassem a voce.

Tutorial Sobre TCP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tutorial Sobre TCP

Uploaded by

Copyright:

Available Formats

Tutorial sobre TCP/IP

TCP:Transmission Control Protocol

Podemos interpretar isso assim:

You might also like