[EMAIL PROTECTED] wrote
>Ola,
>
>Eu li uns txt sobre tcp/ip e me surgiram algumas duvidas. Se alguem tive
>saco pra me ajuda! :)
>
>1) O protocolo que eu uso eh o "TCP/IP". O IP eh para roteamento, porem
> o OSPF faz parte do IP ? E o RIP ? Como eu sei qual dos dois eu estou
> usando para roteamento itnernos ? (me refiro a roteamento interno, pq
> li que ele so serve para roteamento interno, certo) ?
O protocolo IP � o respons�vel pela entrega de pacotes pela Internet. Ele n�o
controla roteamento, ele apenas segue o roteamento existente. O protocolo TCP
funciona sobre o IP -- ou seja, o pacote TCP vem como "carga" do pacote IP --
e � o que garante uma conex�o confi�vel, com pacotes sendo entregues na ordem
e sem percas.
Ele faz isso contando os bytes que foram enviados e, dessa maneira, se uma
ponta da conex�o detecta que lhe faltam bytes, ela pede a retransmiss�o.
(Tecnicamente, a retransmiss�o � autom�tica, a n�o ser que o outro lado j�
avise que recebeu).
Os protocolos RIP e OSPF, assim como alguns outros, s�o os respons�veis por
controle de roteamento, tanto � n�vel interno como na Internet. � poss�vel
utilizar todos (eu acho) na Internet, mas creio que protocolos mais avan�ados
que um simples RIP sejam os usados na Internet, como BGP e EGP.
>2) Como eu sei se eu to usando o RIP ou o OSPF na minha rede ? Ow eu tenho
>que
> usar os dois juntos ?
Se voc� n�o sabe qual est� usando, � porque n�o esta usando nenhum. Se voc�
estiver usando algum, � porque configurou o routed (que usa o RIP) ou o gated
(que usa qualquer um) e a� saberia qual protocolo est� usando.
Mas, como eu disse, esses protocolos s�o usados para manuten��o de tabelas de
roteamento. Usu�rios finais, mesmo aqueles com mais de uma conex�o uplink
(usu�rios multihomed) n�o precisam usar isso, a n�o ser que administrem
enormes redes internas.
>3) O broadcast eh endere�ado 255.255.255.255 certo ? E o multicast 224.0.0.5
>e
> 224.0.0.6 certo ? O multicast eh uma especie de "broadcast" para
> roteadores, ok ?
Multicast � um tipo especial de endere�o que significa "entregue para todos".
Ao contr�rio de uma conex�o unicast comum, em que existe um e apenas um
destino, um pacote multicast � entregue � todos os destinos que fa�am parte
do grupo multicast. Um grupo multicast � controlado pelo protocolo IGMP.
>4) As mascaras de rede servem para "dividir" redes! Sao endere�oes de 32
>bits
> xxx.xxx.xxx.xxx certo ? Quando vc tem 255.255.255.0 vc tem 254 endere�os
>para uso,
> o xxx.xxx.xxx.255 para broadcast, e o ???.???.???.??? para multicast!
>Quem seria esses
> ???.???.???.??? 224.0.0.5 ou 224.0.0.6 ou nenhum deles ? seria
> xxx.xxx.xxx.0 ?
>
> O xxx.xxx.xxx.0 serve pra q ? =]
Justamente para isso. Uma m�scara de rede (netmask) � o que diz quantos bits
s�o usados para identificar a rede e quantos s�o usados para identificar uma
m�quina naquela rede.
Normalmente n�s vemos as m�scaras na forma 255.255.255.0 ou semelhantes, mas �
muito mais f�cil usar apenas o n�mero de bits. Por exemplo, a m�scara
255.255.255.0 � cont�m 24 bits 1, enquanto que a m�scara 255.255.255.192
cont�m 26.
Uma rede identificada por 24 bits de seu endere�o deixa outros 8 bits para a
identifica��o de uma m�quina, certo? S�o 32 bits no total. Ent�o, tendo 8
bits, voc� tem exatamente 256 endere�os poss�veis.
S� que, desses 256 endere�os, o primeiro � reservado para ser o "endere�o da
rede", enquanto que o �ltimo � reservado para "o endere�o de broadcast"
(broadcast n�o � o mesmo que multicast). Esses dois endere�os especiais s�
fazem sentido para os n�s que perten�am �quela rede. Qualquer um de fora os
ver� como endere�os comuns.
O que voc� diz como x.x.x.255 e x.x.x.0 s�o os endere�os de broadcast e da
rede, respectivamente, para uma rede comum definida por 24 bits (m�scara
255.255.255.0). Uma rede com n�mero de bits diferentes iria ter esses
endere�os diferentemente. Por exemplo, meu IP na rede aqui da resid�ncia �
172.30.28.5 e n�s temos 16 bits (m�scara 255.255.0.0). Portanto, o endere�o
de rede � 172.30.0.0 e o broadcast � 172.30.255.255.
Endere�os de multicast n�o fazem parte de redes. Eles t�m seu alcance definido
de maneira diferente e, se me perguntasse, diria que feia. De acordo com o
campo TTL (Time To Live) do pacote IP, define-se se um pacote multicast deve
ser roteado ou n�o. N�o vou entrar nos detalhes, mas o fato � que um
roteamento multicast n�o � t�o simples quanto o roteamento unicast. Al�m do
que o multicast sobre IPv4 n�o � obrigat�rio. Quase ningu�m usa.
At� onde eu me lembre, o endere�os multicast pertencentes � rede 224.0.0.0/24
s�o definidos como "locais" e o 224.0.0.1 � o endere�o "todo mundo". Ent�o,
se voc� fizer um ping em 224.0.0.1, em teoria, todos os n�s que tenham
multicast habilitado deveriam responder. *Em teoria*
Disso tudo que eu expliquei, somente a parte dos bits de rede continua v�lido
para IPv6. Com o IPv6 n�o existem mais broadcast, endere�os de rede, m�scaras
de rede; os endere�os multicast s�o definidos de outra maneira totalmente
diferente e passam a ser obrigat�rios.
>O cabe�alho do IP eh:
>
>Bytes:
Voc� quis dizer "bits" :-)
>0 4 8 16 24 31
[corta]
>09:24:57.520132 Barns.3116 > hadrion.int.1521: . ack 1460 win 17520 (DF)
> 4500 0028 8714 4000 8006 c31c c0a8 97b7
> c0a8 9796 0c2c 05f1 d343 250f f688 e411
> 5010 4470 d5ba 0000 2020 2020 2020
>
>Cada numero separado por espa�o seria um byte ? Ow cada numero seria um
>byte ?
Um byte = 8 bits = dois d�gitos hexadecimais. Logo, como cada grupo entre os
espa�os tem 4 d�gitos, conclu�mos que se tratam de dois bytes e 16 bits.
>
>4500 == versao do protocolo ?
N�o. A vers�o � 4, a prioridade � 5 e o r�tulo de fluxo � 0.
>Entao eu imaginei que a vers�o eh 69, porem nao existe o 69 no meu
> /etc/protcols! Entao onde eu
>estou errando ? =]
Vers�o do protocolo IP n�o � o protocolo. O 4 v�m de IP vers�o 4 (IPv4).
>8) O que eh um rotulo de fluxo ? O que eh Limite de Saltos ?
O Limite de Saltos (hop limit) tamb�m � conhecido como Tempo de Vida (TTL).
Cada roteador que retransmite o pacote decrementa o TTL de 1. Se um roteador
perceber que o TTL � 0, ele n�o ir� retransmitir o pacote. Ao inv�s disso,
ele envia um erro ICMP � origem dizendo que o tempo de vida expirou. Isso
evita que erros de roteamento causem que pacotes sejam reenviados de um
roteador � outro, de maneira c�clica. O m�ximo que pode acontecer � que os
pacotes sejam reenviados, mas apenas por alguns ciclos. Depois o ciclo �
terminado.
>9) N�o deveria existir no pacote os ID sequence ? Os numeros de sequencia
>do protoclo ?
> Para poder se manter confiabilidade e sequencia ? Onde eles estao ?
Isso est� no pacote TCP, que v�m depois do pacote IP.
>10) Com o -xx o tcpdump me mostra o cabe�alho! Qual op��o pra que ele mostre
>os dados tmb ? =]
O -x tamb�m. Basta voc� seguir o n�mero de bytes. Um cabe�alho IP tem 14
bytes, um TCP tem n�o-sei-quantos. Depois desse tanto de bytes, voc� ver� os
dados carregados pelo pacote.
>11) ttl = eh o numero de maquinas que ele pacote podera passar antes de
>ser expirado, ta certo ?
Sim. Ent�o voc� j� sabia o que era o hoplimit.
> tos = type of service! Muito bunito o nome, geralmente ele eh 0x10 em
>decimal 16! Mas e dai ?
N�o lembro de cor o que cada TOS significa. Mas geralmente ele indica ao
roteador se ele deve preferir uma transmiss�o mais r�pida ou, por exemplo,
uma com maior banda. Para telnet ou SSH, por exemplo, voc� prefereria menor
lat�ncia, mas para uma transfer�ncia de arquivos, � prefer�vel que a banda
seja maior.
> Quem eh esse tipo de servi�o ?? Onde eu encontro a lista de
> numero/servi�o ? So com esses
> numeros em hexa eu nao sei qual servi�o cada um representa! :P
Refira-se ao RFC que define o protocolo IP. N�o sei o n�mero.
> ack que inferno sao isso ? Quando se abre uma conex�o tcp sempre se
>manda um syn, recebe do
> servidor um syn ack e por fim se manda um ack para estabelecar a conex�o
>certo ? Entao o que
> quer dizer isso ? Que eu tenho 1460 conex�es abertas ??
SYN, ACK, FIN, PSH e RST s�o "flags" do TCP, que servem para indicar para o
outro lado que se passa. Uma conex�o TCP � aberta com tr�s pacotes: primeiro
um lado envia um pacote com SYN sem ACK, indicando que deseja abrir a
conex�o; o destino ent�o vai enviar um SYN com ACK indicando que a conex�o
foi aceita. Para confirmar, a origem vai ter que enviar pelo menos um ACK.
Durante a transmiss�o normal de dados, os pacotes v�m marcados com PSH,
indicando dados. O lado receptor deve confirmar que recebeu direitinho os
dados com pacotes marcados com ACK e a seq��ncia de bytes.
Uma conex�o � terminada com um pacote FIN, confirmada por um FIN com ACK. E
uma conex�o recusada (Connection refused) � um pacote com RST enviado como
resposta a um pacote com SYN.
> win = sao usados para checar "integridade de checada do pacote" nao
>? Por exemplo eu defino
> que o meu win vai ser de 5. Entao eu mando 5 pacotes direto sem esperar
>resposta se chegou ou
> n�o e no quinto eu confiro, certo ? Mas e se o segundo se perder eu
>vou acabar esperando os
> ate o quinto para remandar o 2,3,4,5 ? Ow vem uma msg de erro e eu
> recome�o antes de chegar
> ao quinto ?
Win � a janela de dados dispon�vel. O kernel aloca alguns kilobytes de mem�ria
para cada conex�o aberta, de modo que ele possa receber os dados fora de
ordem, se necess�rio. Al�m disso, como o kernel n�o se interessa aos dados,
ele tem apenas que estoc�-los at� que o programa que abriu a conex�o leia os
dados.
Por�m, a leitura n�o � imediata. O programa geralmente leva um tempo para ler
os dados depois que eles foram recebidos pelo kernel. O kernel avisa o outro
lado que o programa n�o est� lendo t�o r�pido pelo tamanho da janela
dispon�vel. Imagine que a janela seja de 1024 bytes e voc� transmite 256. O
buffer cont�m ainda 768 bytes � isso que indicar� a janela numa pr�xima
transmiss�o, enquanto o programa n�o ler os 256 bytes que j� foram recebidos.
> DF = esse eu nao fa�o nem ideia do que eh! O que seria ? :)
Nem eu.
--
Thiago Macieira - UFOT Registry number: 1001
[EMAIL PROTECTED]
ICQ UIN: 1967141 PGP: 0x8F2978D5 and 0xEA9037A5 (PGP 2.x)
Registered Linux user #65028
Assinantes em 17/03/2002: 2239
Mensagens recebidas desde 07/01/1999: 158500
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
