Redes, endereços, nomes e serviços - introdução

Introdução

A utilização de redes de computadores faz hoje parte da cultura geral. A explosão da utilização da "internet" tem aqui um papel fundamental, actualmente quando se fala de computadores está implicito que os mesmos estão ligados a uma rede. Muitos utilizadores consideram completamente inutil um computador sem ligação à "internet".

Embora as aplicações sejam cada vez mais voltadas para os utilizadores e dispensem cada vez mais o conhecimento sobre os principios de funcionamento, a existencia destes conhecimentos tem um papel fundamental numa utilização segura e eficaz das redes.

O que se designa por "internet" é na realidade um conjunto de redes e computadores que se encontram interligados a nível mundial, os meios usados para garantir esta interligação são muito diversos, recorrendo às redes públicas de comunicações, baseadas em cabos electricos ou ópticos, terrestres ou submarinos e ligações via rádio terrestres ou via-satélite.

Com tecnologias de transmissão tão diversas é necessário um elo comum que permita a transferência de dados entre qualquer equipamento ligado à "internet", esse elo é o protocolo de rede, no caso da "internet" designado por "Internet Protocol" e abreviado para IP. Uma das missões importantes de um protocolo de rede é portanto assegurar a transferêmcia de dados entre redes que usam tecnologias de transmissão diferentes.

Endereçamento

Uma das primeiras preocupações quando pensamos numa rede é a forma de identificar cada uma das máquinas que estão ligadas. É um problema identico ao que acontece quando pretendemos enviar uma carta a alguém ou telefonar a alguém, necessitamos, respectivamente, do endereço do destinatário ou do número do telefone.

Desde logo uma caracteristica fundamental de um endereço é ser único, isso pode ser um grande problema numa rede global como a "internet", não podemos usar simplesmente o endereço que nos apetecer.

O formato dos endereços de rede depende do protocolo de rede, actualmente o mais divulgado é o IP versão 4, este protocolo utiliza apenas 4 octetos (conjuntos de 8 bits que permitem representar números de 0 a 255) para identificar cada destino.

Este número de octetos é muito reduzido para a expansão actual da "internet", não existem endereços suficientes para a quantidade de máquinas que lhe estão ligadas. O problema é ainda agravado pela necessidade de delegar em entidades nacionais a atribuição de novos endereços o que implica reservar uma determinada quantidade para cada uma dessas entidades.

Esta é uma das razões pela qual foi desenvolvido o IP versão 6, entretanto foram encontradas outras soluções para a escasses de endereços e o IPv6 não é ainda muito usado.

Na tabela seguinte apresentam-se alguns endereços para outros tantos protocolos de rede:

Seja qual for o protocolo de rede, tal como acontece quando se envia uma carta a alguém, os dados transferidos pela rede devem conter dois endereços: origem e destino. Isto é fundamental por duas razões:

1. O destinatário pode querer responder, ou simplesmente confirmar que os dados chegaram.
2. Se a transferência dos dados não é bem sucedida, a rede deve avisar o remetente de tal facto.

A maioria dos esquemas de endereçamento suportam dois tipos de endereços de destino:

• UNICAST - endereço que identifica um único nó de destino.
• MULTICAST - endereço que identifica um conjunto de nós de destino.

Os endereços "multicast" têm diversas utilidades pois permitem difundir informação para vários nós de uma forma expedita e rápida. Um endereço "multicast" muito comum é o endereço de "broadcast" que corresponde a todos os nós existentes numa dada rede.

Algumas redes suportam ainda endereços "ANYCAST" que, tal como os endereços "MULTICAST" identificam vários nós, contudo apenas obrigam a rede a entregar os dados a um dos nós do conjunto.

Modelo cliente-servidor

Este é o modelo que serve de referência à maioria das comunicações em rede, baseia-se no conceito de prestação de um serviço e define um diálogo típico de pedido-resposta:

• Servidor - aplicação passiva que aguarda o contacto pelo cliente, uma vez contactado, recebe o pedido de serviço, executa o serviço e devolve ao cliente uma resposta.
• Cliente - aplicação que toma a iniciativa, contacta o servidor, envia-lhe o pedido e aguarda pela resposta.

Deste modelo podemos tirar algumas conclusões imediatas:

1. O cliente é em muitos casos manuseado directamente pelo utilizador.
2. O cliente tem de conhecer previamante o endereço do servidor.
3. O servidor não necessita de saber previamente o endereço do cliente.

O principal problema que se levanta é a necessidade de os clientes conhecerem previamente o endereço do servidor. A questão é que as aplicações clientes são manuseadas directamente pelos utilizadores que teriam de fornecer o endereço do servidor.

Nomes de máquinas

Para um humano os endereços de rede não têm qualquer significado e não se pode exigir a um utilizador que os tenha sempre presentes. Se isso já é impraticável para o IPv4, imagine-se para o IPv6.

Devido à dificuldade de os utilizadores lidarem com endereços de rede, foi desenvolvida uma alternativa que é o nome de máquina. Consiste em "baptizar" as máquinas dando-lhes nomes mais ou menos fáceis de fixar, depois é necessário um mecanismo que efectue a tradução automática. Estes nomes de máquinas equivalem por isso a endereços e como tal têm de manter a caracteristica de serem únicos.

Os clientes (aplicações) recebem do utilizador o nome da máquina onde está o servidor e utilizam o referido "mecanismo automático" para obter o respectivo endereço de rede. Esta operação de obtenção do endereço de rede apartir do nome da máquina designa-se por "resolução do nome".

DNS - "Domain Name System"

Se numa rede local, com algumas dezenas de máquinas a implementação de um mecanismo de resolução de nomes é simples e pode ter várias abordagens, na "internet" torna-se muito complicada devido à quantidade de máquinas envolvidas. Se existisse uma base de dados contendo um registo para cada máquina ligada à "internet" ela seria enorme e a pesquisa sobre ela muito morosa.

A solução adoptada consiste na distribuiçãao desta base de dados segundo nomes que se designa por domínios, para facilitar ainda mais a resolução, os domínios estão organizados em forma hierárquica, esta base de dados e respectivos serviços têm a designação "Domain Name System" (DNS).

Por uma questão de tolerância a falhas, cada domínio tem pelo menos dois servidores de nomes onde reside a base de dados que contém os mapeamentos "nome<->IP" para todas as máquinas desse domínio. Como foi referido os domínios estão organizados em forma hierárquica, assim cada domínio pode conter vários subdomínios com os seus respectivos servidores de nomes, cada domínio tem também de conhecer os endereços dos servidores de nomes dos subdomínios que contem.

A resolução dos nomes é realizada de forma descendente desde os chamados domínios de topo, todos os servidores de nomes têm de conhecer os endereços dos servidores de nomes dos domínios de topo.

Os domínios de topo são:

• com, edu, gov, int, mil, net e org
• códigos de duas letras correspondentes a países (ISO3166)
• arpa

Tantos os servidores de nomes como os clientes guardam durante algum tempo, em "cache" local, as resoluções que vão realizando, isto aumenta bastante a eficiência do sistema. Quando um servidor de nomes recebe um nome de máquina para resolver podem verificar-se várias situações:

• A resolução está em "cache" - resposta imediata.
• O nome é do domínio local - resposta imediata.
• O nome é de outro domínio, o servidor contacta outros servidores de nomes e responde.
• O nome é de outro domínio, o servidor responde ao cliente enviando-lhe o endereço do servidor de nomes a contactar.

Para identificar inequivocamente uma máquina, ao nome da máquina devem ser concatenados os sucessivos domínios, separados por um ponto, até chegar ao domínio de topo. Por exemplo o nome "alvega" identifica a máquina com nome "alvega" no domínio local, o nome "alvega.dei.isep.ipp.pt" identifica a máquina com nome "alvega" que se encontra no domínio "dei", do domínio "isep", do domínio "ipp", do domínio de topo "pt".

Os nomes de máquinas simples, sem a sucessão de domínios até ao topo, dizem-se "não qualificados" e têm um significado que depende do local onde nos encontramos, um nome de máquina com a sucessão de domínios até ao topo diz-se "qualificado" e tem o mesmo significado em qualquer ponto da "internet".

O serviço de nomes DNS não se limita a resolver nomes de máquinas, dando outras indicações, por exemplo como enviar correio-electrónico para esse domínio (identificação das máquinas que recebem correio-electrónico). Outra caracteristica importante do DNS é a possibilidade de definir nomes alternativos, conhecidos habitualmente por "aliases". Nas bases de dados DNS, cada máquina, além do nome "normal", pode ter um ou mais nomes alternativos, os nomes alternativos são tratados exactamente da mesma forma, tanto o nome normal como os alternativos, quando resolvidos produzem o endereço de rede da máquina.

Os nomes alternativos são muito úteis porque existem certos nomes de máquina que representam serviços disponibilizados. Por exemplo "www" para servidores "web", "ftp", "mail", etc. Recorrendo a nomes alternativos é possível instalar vários serviços na mesma máquina e usar estes nomes representativos que acabam por apontar todos para o mesmo endereço de rede. Os nomes alternativos são também bastante úteis para os administradores pois quando querem transferir um serviço de uma máquina para outra basta mudar o "alias" e não é necessário alterar os nomes das máquinas que é bastante mais complicado.

Na realidade uma dada máquina pode nem sequer ter conhecimento que tem determinados nomes alternativos, todo se passa a nível dos servidores DNS.

Resolução de nomes NetBIOS - WINS

A especificação NetBIOS, usada em redes locais, possui os seus próprios mecanismos de resolução de nomes.

Ao contrário do sistema DNS, o sistema de nomes NetBIOS é totalmente dinâmico, os nós podem usar o nome que bem entenderem, contudo esse nome tem de ser aceite pela rede ("name registration").

O registo de um nome na rede envolve o envio de um pedido em "broadcast" contendo o nome a registar, se já existe na rede um nó com o mesmo nome, este "protesta" e o registo não é aceite.

A resolução de nomes NetBIOS consiste no envio de um pedido com o nome a resolver ("name query") em "broadcast" para a rede. A nó que possui esse nome responde, ficando-se a conhecer o endereço a que corresponde o nome.

Este mecanismo de resolução de nomes tem a grande vantagem de dispensar qualquer tipo de administração ou configuração prévia, mas apresenta algumas desvantagens:

• Tráfego em "broadcast" - a emissão de pacotes em "broadcast" tende a sobrecarregar as redes já que não pode ser filtrado pelos dispositivos de comutação.
• Limite do alcance do "broadcast" - a emissão em "broadcast" está limitada a uma rede, isto significa que se as máquinas estão em redes diferentes a resolução de nomes NetBIOS não funciona.
• Falta de administração - embora a ausência de administração seja um vantagem em muitos ambientes, em certas situações pode causar problemas de conflitos de nomes com nós que exercem funções criticas.

Para resolver estes problemas a Microsoft desenvolveu o serviço WINS ("Windows Internet Name Service"), baseado nos RFC1001 e RFC1002. O principio é simples: substituir o papel dos "broadcast" para a rede por envios "unicast" para um nó especial onde funciona o servidor WINS.

O servidor WINS mantém uma base de dados com os nós activos, os nós registam-se usando o pedido "name registration", o servidor consulta a sua base de dados para saber se o nome está disponível, em caso afirmativo aceita o pedido e adiciona o novo nome à base de dados.

Periodicamente os nós enviam pedidos "name refresh", caso contrário são eliminados da base de dados. Alguns servidores WINS permitem a existência de nomes permanetes cujo registo apenas é aceite para endereços IP preestabelecidos, desta forma podem evitar-se conflitos com nomes de servidores críticos.

A resolução de um nome consiste agora no envio de um pedido "name query" para o servidor WINS que para responder usa a sua base de dados.

A utilização de um servidor WINS resolve os problemas apontados, deixa de ser usado o "broadcast" e por isso a resolução de nomes funciona mesmo quando os nós se encontram em redes diferentes.

Para que a resolução WINS funcione é contudo necessário manter uma condição: todos os nós têm de usar o mesmo servidor WINS.

Os servidores WINS da Microsoft suportam ainda mecanismos de replicação que, para efeitos de redundância, permitem manter vários servidores desse tipo perfeitamente sincronizados.

De referir ainda que, mesmo usando o serviço WINS, os nós NetBIOS continuam a usar "broadcast" para a eventualidade de existirem na rede nós que não usam o mesmo servidor WINS. Os nós NetBIOS registam sempre o seu nome em todas as redes a que estão ligados ("broadcast") e em todos os servidores WINS que conhecem.

O tipo de nó NetBIOS ("NetBIOS node type") define o comportamento na resolução de nomes:

• B-Node (valor 1) Broadcast - apenas usa "broadcast"
• P-Node (valor 2) Peer - apenas usa WINS
• M-Node (valor 4) Mixed - primeiro "broadcast" e depois WINS
• H-Node (valor 8) Hybrid - primeiro WINS e depois "broadcast"

Actualmente o tipo de nó mais usado é H-Node, deste modo apenas é usado "broadcast" se a resolução pelos servidores WINS falha. A forma de configurar o tipo de nó varia muito com a versão do sistema operativo, alguns sistemas operativos permitem ainda usar a resolução DNS para nomes NetBIOS, ou mesmo servidores DHCP.

Serviços

Como foi já indirectamente referido, cada máquina, pode ter em funcionamento simultaneo vários servidores de diferentes de tipos. Por outro lado cada máquina pode ter múltiplos clientes em funcionamento.

Uma vez que a ligação à rede é geralmente única, há necessidade de definir um mecanismo lógico que permita separar e evitar interferências entre as diferentes comunicações em curso através da ligação física. Este tipo de operação é vulgarmente designado por multiplexagem.

A solução adoptada consiste na atribuíção de um número de identificação (tipicamente um número inteiro positivo de 16 bits), assim os dados que chegam a uma máquina têm associados a sí um identificador numérico, já no interior da máquina, este identificador é usado para fazer chegar os dados à aplicação correcta, por exemplo um servidor.

Este processo é usado em diversos níveis, permite por exemplo que uma máquina use vários protocolos de rede. Nos protocolos de rede estes identificadores são conhecidos por "portos" ("ports"). Esta designação tem haver com comparar a máquina com um país, sendo por isso os portos locais de chegada possíveis. Em portugues, além da designação "porto" pode usar-se a designação "porta".

Qualquer aplicação que utiliza e rede, seja um cliente ou um servidor, tem de usar uma porta, dado o seu posicionamento, uma aplicação servidora tem de usar um número de porta "bem definido". Esta necessidade deriva do facto de o primeiro contacto num diálogo segundo o modelo cliente-servidor ser do cliente para o servidor. Para efectuar este contacto o cliente necessita não apenas do endereço da máquina onde o servidor se encontra, mas também do número de porto onde o servidor escuta os dados.

Para cada tipo de servidor/serviço está estabelecido um número de porto fixo, tanto o servidor como o cliente sabem qual é esse número. O servidor porque é nesse porto que tem de receber o pedido e o cliente porque é para esse porto que tem de enviar o pedido. Os utilizadores não necessitam de conhecer estes números de porto, eles estão implicitos pela aplicação cliente que é usada.

Alguns números de porto frequentemente utilizados no primeiro contacto cliente-servidor são:

Por exemplo um servidor TELNET escuta os pedidos dos clientes no porto 23. Por seu lado os clientes TELNET enviam os pedidos para o porto 23 da máquina que o utilizador pretende. Deste modo quando se usa um cliente TELNET apenas temos de indicar o nome do servidor, o número de porto está implicito. Caso o utilizador o pretenda, a maioria dos clientes TELNET permite que se utilize outros portos para além do 23.

O referido não implica que um servidor TELNET tenha obrigatoriamente de usar o porto 23, simplesmente se usar outro porto, a menos que os utilizadores tenham conhecimento de qual o número do porto usado, nunca vão conseguir contactar esse servidor.

URL ("Uniform Resource Locator")

Os URL são um subconjunto dos URI ("Uniform Resource Identifier"), um URL é um "string" formatado que permite identificar o acesso a um dado recurso. A definição de URI é mais lata já que trata apenas da identificação de um recurso.

Os URL têm a seguinte forma:

• "ACESSO:" - identifica o método de acesso, pode ser um identificador do protocolo de aplicação a usar (http:, ftp:, telnet:, ...), ou outro tipo de identificador. Por exemplo "file:" significa o sistema de ficheiros local. Se omitido será usado o método que foi usado anteriormente (acesso relativo) ou um método de acesso por omissão (normalmente os "browsers" usam "http:", ou tentam sucessivamente vários métodos).
• "//NOME-DO-SERVIDOR" - identifica o nome da máquina na qual se encontra o recurso, ou o respectivo endereço. Pode ser omitido em acesso relativo, o que significa usar a máquina que foi usada anteriormente. Por razões obvias este elemento é omitido quando o método de acesso é "file:".
• "/CAMINHO" - identifica o caminho e o nome do recurso. Se omitido será usado um recurso por omissão, normalmente definido no servidor (para o método de acesso "http:" o valor habitual é "/index.html"). Para vários métodos de acesso este componente não faz sentido, como por exemplo "telnet:". A barra inicial pode ser omitida, nesse caso o caminho tem como ponto de partida o caminho usado anteriormente.

O termo "acesso relativo" insere-se no contexto do hipertexto (ex.:html), no qual os recursos (documentos) contêm ligações a outros recursos, num documento deste tipo um URL relativo têm como ponto de partida a localização do documento corrente.

Dependendo dos métodos de acesso, cada um dos componentes pode suportar várias extensões, por exemplo "//NOME-DO-SERVIDOR" pode ter a seguinte forma:

• UTILIZADOR@ ou UTILIZADOR:PASSWORD@ - identifica o nome do utilizador e opcionalmente a respectiva "password". É usado por exemplo com o método de acesso "ftp:". Neste método de acesso, quando este elemento é omitido é usado o utilizador "anonymous".
• :PORTO - identifica o número de porto a usar, normalmente este elemento não é usado e o número de porto é ditado pelo "método de acesso", por exemplo para "http:", será usado o porto 80.

O componente "/CAMINHO" pode ter formatos muito diversos, para o acesso a ficheiros (file:, ftp:, http:, ...) identifica uma sequência de directórios e nome do ficheiro. Se for identificado um directório em lugar de um ficheiro será fornecida uma listagem do conteúdo do directório (para acesso "http:" os servidores podem devolver o ficheiro "index.html" ou "index.htm").

UNC ("Universal Naming Convention")

O UNC é uma notação muito usada pela Microsoft, no contexto das rede NetBIOS, para identificar recursos na rede (note-se que as barras são descendentes, estilo MS-DOS):

• "\\NOME-DE-MAQUINA" - identifica a máquina, trata-se do nome NetBIOS, embora a maioria dos ambientes da Microsoft aceite a utilização de nomes DNS, ou mesmo endereços IP. Este elemento do UNC é obrigatório, se for usado isoladamente identifica apenas a máquina.
• "\NOME-DA-PARTILHA" - identifica o recurso que está a ser partilhado, tipicamente um directório ou uma impressora.
• "\FICHEIRO" - tratando-se de um directório, é possível especificar sub-directórios e nomes de ficheiros.

Pilhas de protocolos - TCP/IP

Em ambiente Unix o ficheiro "/etc/services" contém informação sobre os números de porto e serviços estabelecidos para cada um deles:

#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
# are included, only the more common ones.
#
#	from: @(#)services	5.8 (Berkeley) 5/9/91
#	$Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $
#
tcpmux		1/tcp
echo		7/tcp
echo		7/udp
discard		9/tcp
discard		9/udp
systat		11/tcp
daytime		13/tcp
daytime		13/udp
netstat		15/tcp
qotd		17/tcp
msp		18/tcp
msp		18/udp
chargen		19/tcp
ftp-data	20/tcp
ftp		21/tcp
fsp		21/udp
ssh		22/tcp
ssh		22/udp
telnet		23/tcp

Pode observar-se no extracto que cada linha inicia-se com um nome de serviço, segue-se um número de porto e respectivo protocolo, no caso "udp" ou "tcp". A realidade é que o protocolo IP não define números de porta, estes são definidos pelos protocolos "udp" e "tcp" que são usados pelas aplicações, por exemplo clientes e servidores, este conjunto de protocolos é conhecido por TCP/IP.

A figura seguinte ilustra um conjunto de protocolos (incluindo a pilha TCP/IP) a funcionar no interior de uma máquina ligada a uma rede local tipo "ethernet".

Podem observar-se vários pontos de multiplexagem que culminam, no caso "internet" com a definição de números de porta, quer para o protocolo "udp", quer para o protocolo "tcp".

Cada nível usa um formato especifico (PDU - "Protocol Data Unit") que contém os dados a transportar e informação de controlo específica desse protocolo. Durante a emissão de dados (sentido descendente na pilha de protocolos), cada camada "passa" à camada inferior os seus PDU. Na camada inferior, o PDU recebido da camada superior é interpretado como dados abstractos aos quais vai ser adicionada nova informação de controlo. Este mecanismo é normalmente conhecido por encapsulamento e pode ser observado na figura seguinte:

Aplicação de Rede a usar o porto UDP 8123					DADOS
User Datagram Protocol (UDP)				Informação de controlo UDP (Port=8123)	DADOS
Internet Protocol (IP)			Informação de controlo IP (Type=17)	DADOS
Ethernet II		Informação de controlo Ethernet II (E-TYPE=800)	DADOS			FCS

O protocolo "tcp" ("Transmission Control Protocol") é orientado à conexão, sendo adequado para serviços em que a fiabilidade é importante e serviços que implica a existência de um diálogo prolongado entre cliente e servidor (sessão).

O protocolo "udp" ("User Datagram Protocol") não é orientado à conexão, os dados são enviados em blocos independentes entre sí. É adequado para serviços cuja fiabilidade não é muito importante e em que o diálogo cliente-servidor se resume ao envio de um único pedido e devolução de uma única resposta.

Além dos protocolos IP, UDP e TCP, a pilha TCP/IP contempla ainda alguns protocolos auxiliares, um deles é ICMP ("Internet Control Message Protocol"). Ao contrário dos anteriores o ICMP não é usado para transportar dados das aplicações de rede, tal como o nome indica, trata-se do envio de mensagens de controlo.

Algumas das principais mensagens ICMP são:

• "DESTINATION UNREACHEABLE" - esta mensagem é devolvida ao remetente, quando a informação não chega ao destino. Esta mensagem ICMP indica ainda a razão pela qual isso aconteceu, algumas importantes são:
  • NETWORK - não foi possível fazer chegar os dados à rede em que o destinatário se encontra.
  • HOST - não foi possível fazer chegar os dados à máquina destinatária.
  • PROTOCOL - os dados chegaram ao destino, mas o destinatário não suporta o protocolo de transporte usado (TCP, UDP, ...).
  • PORT - os dados chegaram ao destino, mas não existe nenhuma aplicação para receber os dados no número de porto que foi especificado como destino.
• "TIME EXCEEDED" - esta mensagem é devolvida ao remetente por um encaminhador ("router"), quando o "tempo de vida" de um "datagrama" IP chega a zero.
  Entre os elementos que constituem a informação de controlo IP consta um campo de 8 bits, chamado "tempo máximo de vida", este campo é inicializado pelo emissor com o valor apropriado (1 a 255) e é decrementado sempre que o datagrama IP é transferido de uma rede para outra (passa por um encaminhador). Quando chega a zero o "datagrama" é bloqueado e é enviada ao remetente esta mensagem ICMP. Esta é uma medida de controlo importante que evita que determinados erros por parte dos encaminhadores possam levar a que um "datagrama" circule eternamente na rede com as consequências que se pode imaginar.
  O comando "traceroute" ("tracert" em MS-Windows) tira partido deste mecanismo para determinar o caminho que um "datagrama" segue para chegar a um dado endereço de destino. O comando envia sucessivamente "datagramas" com tempos de vida crescentes: 1, 2, 3, 4, ...
  Os "datagramas" enviados com o valor 1 originarão "TIME EXCEEDED" por parte do primeiro encaminhador, os "datagramas" enviados com tempo de vida = 2 originam a mesma mensagem do segundo encaminhados e assim sucessivamente. Quando o tempo de vida é suficiente para o "datagrama" chegar ao destino será recebida a mensagem DESTINATION UNREACHEABLE - PORT que leva o "traceroute" a parar de enviar "datagramas".
• "ECHO" e "ECHO REPLY" - estas mensagens servem para testar a conectividade, para tal procede-se ao envio da mensagem "ECHO" para o destino a testar e o destinatário deve responder com "ECHO REPLY".
  O comando "ping" disponível em vários sistemas utiliza estas mensagens. As mensagens "ECHO" são númeradas e podem ter o tamanho que se pretender, o que é importante num teste de conectividade (o facto de os "datagramas" de um dado tamanho chegarem ao destino não implica que para tamanhos diferentes se passe o mesmo)

Alguns documentos relacionados:

• IPv4
• UDP
• TCP
• Ethernet
• IPv6
• DNS