Notas de Aula de TCP/IP


(última atualização: 11 de abril de 2001)

Estas são notas de aula de TCP/IP, redigidas por Ricardo Ueda Karpischek, e podem ser encontradas no endereço http://www.ime.usp.br/~ueda/ldoc/notastcp.html. Elas têm um caráter prático, e trazem aproximadamente o conteúdo que de hábito seguimos ao dar cursos. A apresentação despojada pretende facilitar uma rápida assimilação. As notas estão entrelaçadas com exemplos práticos baseados em comandos habitualmente encontrados em plataformas Unix-like (como o Linux) e também no Windows. Recomendamos que esses exemplos sejam repetidos muitas vezes até que o uso dos comandos torne-se habitual.

Estas notas podem ser livremente consultadas. Elas podem também ser livremente reproduzidas eletrônicamente ou através de impressão em papel, desde que mantida a integridade do documento. Oportunamente disponibilizaremos estas notas sob os termos precisos de alguma licença apropriada para documentação livre.

Obs. Nos exemplos práticos, realçamos o texto digitado colocando-o em negrito. No Unix, alguns dos comandos utilizados por vezes residem em diretórios que não constam do PATH default (tipicamente /sbin ou /usr/sbin).

Seções

Cada seção é composta por um sumário seguido de notas e eventualmente questões. As notas esclarecem e completam o sumário, mas não são exaustivas.

Notas

1. Introdução ao IP

Endereços IPv4 Cabeçalho (Header) IP Distribuição mundial dos IPs

Notas

1.1 O TCP/IP

O TCP/IP é a coleção de protocolos desenvolvida para e utilizada pela Internet. O TCP/IP pode também ser utilizado como padrão de rede por infraestrutruras desconectadas da Internet mundial, como por exemplo uma pequena rede local doméstica, a LAN de uma pequena empresa ou ainda uma grande WAN corporativa.

O TCP/IP é independente de plataforma, e foi implementado em inúmeros tipos diferentes de computadores e sistemas operacionais, desde handhelds até mainframes. O TCP/IP vem se afirmando como o padrão de fato de comunicação digital no mundo todo, em detrimento de outros padrões que em maior ou menor grau apresentam equivalência funcional com ele.

Nestas notas estaremos nos referindo à versão 4 do IP (Internet Protocol), também chamado IPv4. As exigências da Internet levaram ao desenvolvimento de uma nova versão do IP, que está sendo utilizado na Internet 2. Essa nova versão é o IPv6 (ou IPng). Falaremos do IPv4 em todas as suas "camadas", desde os meios físicos mais comuns ("link": ethernet, RS-232, SLIP, PPP) até os protocolos de aplicação ("application": HTTP, SMTP, POP, etc), passando também pelas camadas de rede ("network": IP) e de transporte ("transport": TCP e UDP).

1.2 Endereços IP

O IPv4 utiliza endereços numéricos de 32 bits que para maior comodidade são escritos na forma de 4 octetos, como por exemplo 200.231.191.10. Um endereço IPv4 é muito frequentemente chamado de também de número IP ou simplesmente de IP. Cada octeto corresponde a 8 bits do endereço, e pode portanto variar de 0 a 255.

O endereço permite que um participante de uma rede IP possa ser identificado perante os demais, enviar ou receber dados. O endereço de um participante pode ser manualmente consultado através do comando ifconfig (winipcfg no Windows 9x, ou ipconfig no NT). Por exemplo:

  $ ifconfig
  eth0  Link encap:Ethernet HWaddr 00:80:48:EB:06:CD
        inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
        UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:100
        Interrupt:11 Base address:0xff80

  lo    Link encap:Local Loopback
        inet addr:127.0.0.1 Mask:255.0.0.0
        UP LOOPBACK RUNNING MTU:3924  Metric:1
        RX packets:2189 errors:0 dropped:0 overruns:0 frame:0
        TX packets:2189 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:0

Observe que o endereço é um atributo da interface. No exemplo temos duas interfaces numa mesma máquina, a saber, a eth0 (placa de rede ethernet) com endereço 192.168.0.1, e a lo (loopback, uma interface que não corresponde a um dispositivo físico e que pode servir para a comunicação IP interna da máquina, isto é, quando o cliente e o servidor estão na mesma máquina), com endereço 127.0.0.1.

No exemplo o comando ifconfig está também informando o tamanho máximo de pacotes configurado para cada interface (MTU, ou Maximum Transfer Unit), o endereço de broadcast e a máscara. Para o conceito de máscara, veja as notas sobre roteamento IP. O conceito de endereço de broadcast foi criado para aplicações que necessitassem atingir todas as máquinas de uma determinada rede. Entretanto, ao nível do TCP/IP, aplicações desse tipo são inexistentes (ou quase). É importante não confundir broadcast IP com outros broadcasts, alguns deles muito usados, como por exemplo aquele implementado pelo ARP ou por serviços de resolução de nomes do netbios. Esses outros broadcasts não tem qualquer relação com o endereço de broadcast indicado acima.

Uma interface passa a ter um endereço IP a partir do momento em que alguém atribui um endereço IP a ela. Isso via de regra é realizado pelos procedimentos de boot da máquina, que consultam os arquivos de configuração do sistema ou solicitam um endereço a algum servidor especializado da rede local. Em conexões PPP discadas, o endereço é obtido como fruto da negociação com o servidor do provedor de acesso.

O comando ifconfig permite atribuir manualmente um endereço a uma dada interface (no windows a atribuição do endereço à interface deve ser feita nas propriedades do TCP/IP associada àquela interface). No dois exemplos que seguem atribuímos o endereço 192.168.0.2 à interface eth0, sendo que no segundo caso explicitamos qual é a máscara. Quando a máscara é omitida, ela é deduzida da classe do endereço da rede (veja a nota Outorga de IPs e classes de endereços).

  # ifconfig eth0 192.168.0.2
  # ifconfig eth0 192.168.0.2 netmask 255.255.255.0

O endereço IP que se atribui a uma interface não pode ser escolhido ao acaso. Em virtude do modo com que o IP é roteado, só se podem utilizar endereços IP com o mesmo endereço de rede da rede local à qual o computador estiver fisicamente conectado. Além disso, o mesmo endereço não pode estar sendo utilizado ao mesmo tempo em duas interfaces, cada uma numa máquina diferente.

Além do endereço IP, a interface normalmente necessitará de rotas associadas a ela para poder operar, por isso o comando ifconfig acima em geral seria seguido de um ou mais comandos de criação de rotas, como os exemplos que seguem abaixo, e que serão melhor compreendidos em conjunto com as notas sobre rotas IP.

  # route add -net 192.168.0.0 netmask 255.255.255.0 eth0
  # route add default gw 192.168.0.1

1.3 Pacotes IP

A comunicação numa rede IP é realizada através do envio e recebimento de pacotes. Um pacote é uma sequência de bytes, dos quais os 20 primeiros compõe o cabeçalho (header) IP. No IPv4 o tamanho máximo de um pacote é 65535 bytes, mas em geral eles são bem menores (um valor típico é 1500).

version (4) header length (4)
TOS (8)
total length (16)
identification (16)
flags (3)
fragment offset (13)
TTL (8)
protocol (8)
header checksum (16)
source address (32)
destination address (32)
options (if any)

O cabeçalho IP

Um mesmo e único meio físico (por exemplo o cabo serial que liga o seu handheld ao desktop, ou um cabo coaxial interligando as placas de rede de 15 máquinas de uma rede local de um pequeno escritório, ou alternativamente os cabos "par trançado" e o hub interligando essas mesmas placas) pode ser compartilhado por vários participantes de uma rede IP porque cada um, ao realizar a transmissão de um pacote, aloca esse meio físico com exclusividade por apenas alguns instantes (por exemplo alguns milissegundos), liberando-o em seguida para poder ser usado por outros participantes.

A título de ilustração, vejamos um exemplo real de um cabeçalho IP, obtido através do programa tcpdump. A cada dígito hexadecimal correspondem 4 bits. Assim, o primeiro dígito 4 indica que os primeiros 4 bits do cabeçalho (campo Version) são 0100, o dígito 5 seguinte indica que o 4 bits seguintes (campo Header length) são 0101, e assim por diante:

# tcpdump -i eth0 -l -n -x port 25
tcpdump: listening on eth0
14:17:51.950111 192.168.0.9.1100 > 192.168.0.1.25: P 1043394526:1043394554(28)...
                         4500 0044 9481 0000 4006 64d8 c0a8 0009
                         c0a8 0001 044c 0019 3e30 efde 679c eea4
                         5018 37ff 03b9 0000 7263 7074 2074 6f3a
                         203c 7565 6461

O cabeçalho é portanto "4500 0044 9481 0000 4006 64d8 c0a8 0009 c0a8 0001". Analisemos cada um dos campos:

1.4 O comando ping

O comando ping envia para um endereço indicado pacotes ICMP do tipo ECHO REQUEST, que ao serem recebidos pelo destinatário são respondidos com pacotes ICMP do tipo ECHO REPLY:

  $ ping 200.231.191.10
  PING 200.231.191.10 (200.231.191.10): 56 data bytes
  64 bytes from 200.231.191.10: icmp_seq=0 ttl=64 time=2.0 ms
  64 bytes from 200.231.191.10: icmp_seq=1 ttl=64 time=0.9 ms
  64 bytes from 200.231.191.10: icmp_seq=2 ttl=64 time=0.9 ms
  64 bytes from 200.231.191.10: icmp_seq=3 ttl=64 time=0.8 ms
  64 bytes from 200.231.191.10: icmp_seq=4 ttl=64 time=0.9 ms

O ping é a primeira ferramenta a ser utilizada para se constatar a existência ou não de conectividade física com uma outra máquina. Por exemplo: ao não conseguirmos consultar no browser as páginas de um site determinado (vamos supor, http://www.ietf.org), uma primeira providência poderia ser "pingar" o respectivo servidor:

  $ ping www.ietf.org

Note que não indicamos ao ping um endereço IP numérico, mas sim um nome. Como veremos nas notas referentes a DNS, neste caso o ping realiza previamente a consulta do registro "A" associado ao nome.

1.5 O Comando traceroute

Na Internet, quando enviamos um pacote a um servidor longínquo, esse pacote percorrerá uma sequência de gateways antes de atingir o seu destino. Cada gateway é um participante da Internet, e suas interfaces possuem endereços IP a elas atribuídos. Podemos listar a sequência de gateways que intermediam a nossa comunicação (envio de pacotes) a uma dada máquina através do comando traceroute (no windows o comando traceroute teve o seu nome alterado para tracert):

  # traceroute www.kernel.org
  traceroute to zeus.kernel.org (209.10.41.242), 30 hops max, 40 byte packets
   1 cisco1.ibpinetsp.com.br (200.231.191.1) 160.938 ms
   2 ibpinetsp-S9-1-0-2-dist01.spomb.embratel.net.br (200.228.255.153) 338.660 ms
   3 ebt-A1-2-1-dist05.spo.embratel.net.br (200.246.244.230) 398.733 ms
   4 ebt-P10-0-core03.spo.embratel.net.br (200.230.0.138) 398.722 ms
   5 ebt-P12-0-0-intl02.spo.embratel.net.br (200.230.0.101) 298.678 ms
   6 Hssi9-1-0.SR1.BLM1.ALTER.NET (157.130.22.89) 1218.773 ms
   7 502.ATM2-0.XR2.EWR1.ALTER.NET (152.63.22.22) 1248.486 ms
   8 192.at-1-1-0.TR2.NYC8.ALTER.NET (152.63.20.238) 1179.730 ms
   9 124.at-6-0-0.TR2.SAC1.ALTER.NET (152.63.6.14) 1259.654 ms
  10 296.ATM7-0.XR2.SJC1.ALTER.NET (152.63.51.53) 1339.775 ms
  11 192.ATM5-0.GW9.SJC2.ALTER.NET (152.63.52.237) 1369.743 ms
  12 globix-oc3.customer.alter.net (157.130.204.190) 1239.730 ms
  13 pos1-2-core2.sjc1.globix.net (209.10.12.53) 1229.761 ms
  14 pos5-0-0-aggr1.sjc1.globix.net (209.10.3.30) 1119.753 ms
  15 zeus.kernel.org (209.10.41.242) 1179.713 ms

Assim, os pacotes inicialmente atingiram o 200.231.191.1. Este, por não ser o destino final, repassou-os para o 200.228.255.153, este para o 200.246.244.230 e assim por diante. Esse repasse é em geral denominado forward.

A técnica utilizada pelo traceroute baseia-se em fazer variar o TTL dos pacotes. No cabeçalho IP há um campo TTL (Time To Live). Toda vez que um pacote atravessa um gateway intermediário, o seu TTL é decrementado de uma unidade. Se nessa operação o TTL zerar, então o pacote é descartado e aquele gateway gera um pacote destinado ao originador do pacote descartado notificando o ocorrido. Nesse pacote notificador consta no campo do IP do remetente o IP do gateway onde o descarte ocorreu. Assim, o procedimento do traceroute consiste em gerar pacotes com o TTLs 1, 2, 3, e assim por diante, que provocarão o recebimento de notificações de descarte do primeiro, segundo, terceiro gateways, e assim por diante, até ser atingido o destino indicado como argumento do traceroute.

O traceroute permite descobrir a topologia de uma rede distante. Como isso pode ser uma informação importante para realizar ataques, muitos administradores de redes evitam que esses pacotes de notificação sejam gerados ou saiam da infraestrutura local para a Internet. Se tentarmos rodar o traceroute indicando como argumento uma máquina de uma infraestrutura que siga esse critério administrativo (e que é recomendável do ponto de vista de segurança), conseguiremos traçar apenas um trecho inicial da rota.

1.6 RTT e banda

Os tempos apresentados pelo ping e pelo traceroute são chamados RTT (round trip time). Esses tempos estão associados à banda dos links de comunicação, e em alguns casos é possível inferir a capacidade de um link a partir do RTT. Essa inferência é realizada pelo comando bing. Ele não costuma estar presente nativamente na maior parte dos sistemas operacionais, mas pode ser obtido na Internet. Note que se subtrairmos os RTTs de dois gateways adjacentes mas distantes vários "hops" de nós obteremos o RTT do link através do qual estão conectados. Dessa maneira, o bing é capaz de inferir a capacidade de um link do qual estamos separados por vários gateways. O bing pode ser encontrado em http://web.cnam.fr/reseau/bing.html.

Questões

1.1 Suponha que você esteja em casa conectado ao seu provedor de acesso, e não esteja conseguindo ler no browser uma página web. Quais testes você realizaria para tentar diagnosticar uma ausência de conectividade física entre você e o servidor remoto?

1.2 Que teste você realizaria na sua casa no seu micro doméstico para tentar confirmar qual é a capacidade do link que o seu provedor de acesso diz ter com a Embratel?

1.3 Recentemente foi anunciado o lançamento do primeiro hotel lunar para o ano 2008. Quais alterações num primeiro momento você sugeriria ao nível do mecanismo de retransmissão e de janelas do TCP a fim de viabilizar o acesso Internet para os hóspedes (sugestão: a partir da velocidade da luz, calcule o tempo necessário para a Terra enviar o ack de um pacote enviado pela Lua). Avalie se o mesmo problema ocorre com satélites geoestacionários ou com satélites de baixa altitude, como os previstos pelo projeto Guerra nas Estrelas.

1.4 Como você faria para descobrir qual é o TTL (time to live) dos pacotes gerados pelo seu computador e enviados para a Internet? (sugestão: cheque a documentação do tcpdump).

2. Introdução ao TCP

Canal TCP Aplicações TCP populares

Notas

2.1 O Protocolo TCP

Na sua grande maioria, os serviços utilizados na Internet baseiam-se num protocolo de transporte construído sobre o IP, que se chama TCP (Transfer Control Protocol).

Suponha que usemos o Netscape (por exemplo) para visitar o URL http://altavista.digital.com. O Netscape receberá então do Altavista uma página HTML, ou seja, um texto (sequência de caracteres) eventualmente iniciado assim:

  <html><head><base href="http://jump.altavista.com/" target="_top">
  <meta http-equiv=Refresh content=300>

  <title> AltaVista - Search</title>
  <META name="description"
  content="AltaVista.com provides the most comprehensive search
  experience on the Web."> 
  <META name="keywords" content="search, searches, ...
  ...

Essa página terá tipicamente vários kilobytes e a sua tranferência do Altavista para o Netscape será feita atraves do envio de vários pacotes, cada um carregando uma parte (segmento) da página. Assim, no servidor é necessário "picotar" a página, e, no cliente, reordenar os segmentos no texto original. Todo esse trabalho é feito pelo TCP.

Cada pacote carrega neste caso as informações necessárias à remontagem. Elas estão presentes no cabeçalho TCP, que tem 20 bytes e segue imediatamente o cabeçalho IP.

source port (16)
destination port (16)
sequence number (32)
acknowledgment number (32)
header length (4)
reserved (6)
flags (6)
window size (16)
TCP checksum (16)
urgent pointer (16)
options (if any)

O cabeçalho TCP

Voltemos ao exemplo dado acima ao analisarmos o cabeçalho IP, e completemos a exposição analisando agora o cabeçalho TCP:

# tcpdump -i eth0 -l -n -x port 25
tcpdump: listening on eth0
14:17:51.950111 192.168.0.9.1100 > 192.168.0.1.25: P 1043394526:1043394554(28)...
                         4500 0044 9481 0000 4006 64d8 c0a8 0009
                         c0a8 0001 044c 0019 3e30 efde 679c eea4
                         5018 37ff 03b9 0000 7263 7074 2074 6f3a
                         203c 7565 6461

O cabeçalho TCP é "044c 0019 3e30 efde 679c eea4 5018 37ff 03b9 0000". Analisemos cada um dos campos:

2.2 O comando telnet

O comando telnet estabelece uma conexão TCP com um servidor dado numa porta dada. Ele pode ser visto como um cliente TCP genérico, através do qual é possível estabelecer um "diálogo" (envio e recebimento de bytes no formato do protocolo de aplicação por ele implementado, como HTTP ou SMTP) com um servidor TCP.

Muitos protocolos TCP assemelham-se ao "diálogo" que se estabelece entre um operador e uma interface de linha de comandos como os shells do Unix. Isso permite que os serviços que implementam esses protocolos possam ser testados manualmente através de um cliente como o telnet. Vejamos como utilizá-lo telnet para fazer o download de uma página web da mesma forma que o Netscape faria:

  $ telnet altavista.digital.com 80
  Trying 204.152.190.65...
  Connected to altavista.digital.com.
  Escape character is '^]'.
  GET / 1.0

  <html><head><title>AltaVista - Search</title> ...
  ...

O Altavista responde ao nosso comando GET (repare que é necessário pressionar ENTER duas vezes ao terminar a linha GET / 1.0) enviando a página HTML default do servidor. O caractere "/" corresponde ao path ("caminho") da raiz do servidor. Normalmente os URLs contém um path explícito, por exemplo http://www.internic.net/regist.html. Neste caso, o comando GET, que é definido pelo protocolo HTTP, teria que indicar o path /regist.html:

  $ telnet www.internic.net 80
  Trying ...
  Connected to www.internic.net.
  Escape character is '^]'.
  GET /regist.html 1.0

  <html>

  <head>
  <meta http-equiv="Content-Type" content="text/html; ...
  ...

À medida em que o servidor remoto envia o texto HTML aos pedaços (cada um num pacote), o layer de TCP/IP local vai reordenando-os e entregando a sequência de bytes assim obtida à aplicação que solicitou a conexão, e que no nosso caso é o telnet. O telnet exibe então na sua saída aquilo que recebeu, e vemos o texto HTML rolar à nossa frente, completo e íntegro da página. No Linux, o layer de TCP/IP está presente no kernel do sistema operacional. No windows ele compõe uma DLL separada, a winsock (ou wsock32).

2.3 TCP, mecanismo de transporte genérico

Uma vez que o TCP cria um mecanismo de envio e recebimento de sequências de bytes (chamadas streams), ele pode ser utilizado por quaisquer serviços que se possam implementar dessa maneira: envio e recebimento de emails, compartilhamento de discos e impressoras, transferência de arquivos, bate-papo ("chat"), acesso a bancos de dados SQL, etc. De fato, sobre o mecanismo básico oferecido pelo TCP, foram sendo definidos inúmeros protocolos de aplicação para a implantação desses serviços e outros ainda.

A fim de ilustrar isso, vejamos como o TCP é utilizado para envio (deliver) de emails de forma análoga àquela usada para o download de uma página web. Nesse caso estaremos utilizando o telnet para criar uma conexão TCP e, esta, para realizar uma transação SMTP:

  $ telnet 200.231.191.10 25
  Trying 200.231.191.10...
  Connected to 200.231.191.10.
  Escape character is '^]'.
  220 mailhost.ibpinetsp.com.br ESMTP Sendmail 8.9.3...
  HELO bahia@ibpinetsp.com.br
  250 bahia@ibpinetsp.com.br, pleased to meet you
  mail from: <ueda@ibpinet.net>
  250 <ueda@ibpinet.net>... Sender ok
  rcpt to: <fmarinho@ibpinet.net>
  250 <fmarinho@ibpinet.net>... Recipient ok
  data
  354 Enter mail, end with "." on a line by itself
  Subject: teste, por favor ignore

  Teste, por favor ignore.
  .
  250 RAA00951 Message accepted for delivery
  quit

As linhas enviadas pelo servidor iniciam-se com algum número (220, 250, etc), que funciona como diagnóstico para o cliente analisar se o comando foi bem-sucedido ou não. Truncamos algumas das linhas ao transcrevê-las para simplificar a sua leitura. A transação acima é idêntica àquela que é realizada por qualquer cliente SMTP (Eudora, Outlook, etc), exceto talvez por não termos incluído um cabeçalho completo para o email. De fato, alguns servidores SMTP recusariam este email em virtude da ausência do cabeçalho. O "cabeçalho" no caso é o do email, e não o dos pacotes. Um tal cabeçalho poderia ser (as linhas que terminam com ... foram truncadas):

From domreg@mts2.internic.net  Sat Jun 24 00:59:37 2000
Return-Path: 
Received: from localhost by hal.home.unet (8.9.3/1.34)
        id AAA00887; Sat, 24 Jun 2000 00:59:36 GMT
Delivered-To: UEDA@IME.USP.BR
Received: from 143.107.45.12
        by localhost with POP3 (fetchmail-5.0.0)
        for ueda@home.unet (single-drop); Fri, 23 Jun 2000 ...
Received: (qmail 28680 invoked from network); 23 Jun 2000 ...
Received: from mts2.internic.net (198.41.1.234)
  by bidu.ime.usp.br with SMTP; 23 Jun 2000 04:10:08 -0000
Received: (from domreg@localhost)
        by mts2.internic.net (8.9.3/8.9.1) id AAA17405;
        Fri, 23 Jun 2000 00:09:40 -0400 (EDT)
From: Domain Registration Role Account 
Message-Id: <200006230409.AAA17405@mts2.internic.net>
Subject: Re: ...
Date: Fri, 23 Jun 2000 00:09:40 -0400 (EDT)
Reply-To: hostmaster@internic.net
To: UEDA@IME.USP.BR
X-Mailer: fastmail [version 2.4 PL24]
Status: O
X-Status: 
X-Keywords:
X-UID: 1494

Note que as linhas "Received:" registram a rota (não a rota IP, mas a rota dos servidores SMTP) que o email seguiu desde a sua criação. No caso, ele foi inicialmente recebido pelo mts2.internic.net a partir de um cliente da própria máquina. Em seguida o mts2 transferiu-o ao computador bidu.ime.usp.br (porque ele é o servidor MX do domínio ime.usp.br, veja as notas sobre DNS). Em seguida ele foi baixado via POP pelo fetchmail e transferido para uma caixa postal.

2.4 O conceito de conexão

Tanto no exemplo do download de uma página web através do cliente telnet quanto no exemplo do envio de um email, criamos aquilo que se chama de conexão TCP, ou também canal virtual TCP, ou circuito virtual TCP.

A conexão TCP pode ser vista como sendo análoga a um pipe entre dois processos conectando a saída do primeiro à entrada do segundo. Pipes desse tipo são familiares às pessoas que já utilizaram algum shell Unix ou o COMMAND.COM do MS-DOS. Seguem dois exemplos, o primeiro para um shell Unix, e o segundo para o MS-DOS:

    $ ps ax | grep netscape
    C:\> TYPE AUTOEXEC.BAT | MORE

A conexão TCP que criamos para envio de um email liga por assim dizer a "saída" do telnet com a "entrada" do sendmail (que é um programa que está rodando no servidor smtp 200.231.191.10). Ela conecta também a "saída" do sendmail à "entrada" do telnet. Dessa forma, uma diferença da conexão TCP com os pipes acima é o fato dela ser bidirecional.

A conexão TCP cria para as aplicações nas duas pontas a ilusão de que existe um meio físico exclusivo para o diálogo entre elas, um "canal" ou "circuito" exclusivo. Esse canal ou circuito, como vimos anteriormente, é na verdade simulado através de pacotes que compartilham o meio físico com outras máquinas e outras aplicações, e é por este motivo que a conexão TCP é chamada de canal ou circuito virtual.

Note que naquilo que ela possui de concreto, a "conexão" TCP reduz-se às estruturas de dados que são mantidas em cada uma das pontas, e que servem para o layer TCP de cada máquina gerar e enviar os pacotes a partir dos dados que a aplicação repassa a ela, e a reconstruir a sequência de bytes enviadas pela outra ponta e a partir do conteúdo dos pacotes que vão sendo recebidos. Assim, se, por exemplo, um gateway intermediário entre o cliente e o servidor for desligado e ligado novamente em seguida, nenhum prejuízo ocorrerá para a conexão exceto talvez um atraso no envio de pacotes, pois aquele gateway intermediário não armazenava nenhuma informação de estado sobre a conexão.

2.5 As portas TCP

No exemplo em que fizemos o download de uma página através do cliente telnet, indicamos a ele o número 80 como parâmetro. No exemplo do envio de email, indicamos 25 ao invés de 80. Esses números são chamados de "portas", e nesses casos (80 e 25) tratam-se das portas default em que os serviços HTTP e SMTP atendem.

Um mesmo computador numa rede IP pode atender simultâneamente vários serviços diferentes (por exemplo pode ser ao mesmo tempo servidor HTTP e SMTP). Quando um pacote de um cliente atinge-o solicitando uma conexão, é necessário que esse pacote carregue a informação de a qual serviço conectar. Isso está especificado no campo destination port do cabeçalho IP. Esse campo possui 16 bits.

Assim, o termo "porta" nesse contexto não refere um dispositivo físico como uma porta serial, mas um número presente no header TCP, e que orienta o layer de TCP/IP a respeito da aplicação à qual aquele pacote se destina.

Muitos dos números de portas estão já associados a serviços. Além dos dois vistos temos por exemplo o POP3 (110), TELNET (23), NNTP (119), e várias outras dezenas. Essa associação é importante porque o cliente ao gerar os pacotes necessita saber de antemão qual é a porta em que o serviço atende. Não obstante, em muitas implementações de clientes e servidores TCP é possível alterar a porta default. Nesse caso, entretanto, o cliente continua necessitando saber de antemão a porta em que o servidor atende aquele serviço.

2.6 A porta TCP do cliente

Uma inspeção no formato do cabeçalho TCP nos mostra que além do número da porta do destinatário que, como vimos, no servidor está associado ao serviço, existe também um campo de número da porta do remetente do pacote. Assim, quando um cliente toma a iniciativa de abrir uma conexão TCP com, digamos, um servidor web, ele terá que suprir nesse campo um número de porta local. Para que servirá ele?

Um mesmo computador pode estar sendo, ao mesmo tempo, cliente de vários servidores TCP. Assim, os pacotes de retorno precisam carregar informação suficiente para identificar em cada caso a qual conexão os dados que ele carrega se referem. Isso só é possível se houver também uma porta alocada no cliente, porque no caso de um mesmo cliente criar duas conexões diferentes num mesmo serviço de um mesmo servidor (por exemplo duas instâncias do Netscape, cada uma carregando uma página diferente do Yahoo) nem os IPs e nem a porta do servidor (80) seriam suficientes para distinguir a qual instância do Netscape se refere cada um dos pacotes que chegassem.

De fato, antes de um cliente TCP iniciar uma conexão, ele solicita ao layer TCP/IP algum número de porta TCP local que esteja disponível, e que durante a existência daquela conexão estará associado àquela conexão de forma única. Assim, toda conexão TCP é identificada, tanto no cliente quanto no servidor por uma única quádrupla de parâmetros: IP de origem, IP de destino, porta de origem, porta de destino. Para esses pedidos de portas dinâmicas, o layer de de TCP/IP sempre aloca portas "altas" (acima de 1024). Os serviços TCP por sua vez utilizam sempre portas "baixas" (abaixo de 1024), exceto o Xwindows (6000) e eventualmente outros serviços não standard, como por exemplo muitos servidores SQL.

2.7 O comando netstat

O comando netstat exibe uma série de informações de estado relativas ao TCP/IP. Em particular, ele exibe as conexões TCP em curso, caracterizando-as através da quádrupla IP de origem, IP de destino, porta de origem, porta de destino:

  $ netstat -n -t
  Active Internet connections (w/o servers)
  Proto Recv-Q Send-Q Local Address         Foreign Address    State
  tcp        0      0 200.231.191.110:1023  143.107.45.19:22   ESTABLISHED
  tcp        0      0 192.168.0.1:2345      192.168.0.1:1056   ESTABLISHED
  tcp        0      0 192.168.0.1:1056      192.168.0.1:2345   ESTABLISHED

Obs. em muitos comandos oriundos de plataformas Unix-like, a opção -n pode ser utilizada para evitar a resolução reversa de endereços no display da resposta.

A coluna State exibe o estado da conexão. Com a opção -a, o comando netstat exibe também as portas TCP locais que estão aceitando conexões (estado LISTEN):

  $ netstat -n -t -a

Note que a conexão TCP tem sempre uma parte passiva (aquela onde a porta associada ao serviço foi alocada por uma apllicação como um servidor web que a colocou em modo listen) e uma parte ativa (que alocou uma porta local dinâmica e tomou a iniciativa de conectar na porta remota colocada em listen). A parte passiva é quem oferece o serviço e, portanto, o servidor. A parte ativa é quem usa o serviço e, portanto, o cliente. Além dos estados ESTABLISHED e LISTEN, vários outros podem ocorrer. Os mais relevantes são:

2.8 Um panorama breve dos serviços TCP

Existe uma grande quantidade de protocolos de aplicação TCP, e outros novos vão sendo criados à medida em que se vão tornando necessários. Ao longo dos anos, alguns protocolos firmaram-se como padrões largamente utilizados no mundo todo, o que não impediu que alguns deles fossem sendo lentamente substituídos por outros mais apropriados às necessidades das pessoas e chegassem mesmo a ser abandonados. Seguem alguns desses protocolos com rápidos comentários:

É de se notar também que serviços muito populares e que não foram originalmente implementados para utilizar o TCP como mecanismo de transporte acabaram migrando para o TCP/IP. Os casos mais notáveis são os serviços de compartilhamento de recursos da Novell e da Microsoft.

2.9 Clientes TCP populares

Como vimos, um cliente TCP é um software (um "programa"). Vejamos alguns exemplos de clientes TCP de largo uso, de hoje e de ontem...

2.10 Servidores TCP largamente utilizados

Como vimos, um servidor TCP é um software (um "programa"). Em sistemas Unix-like, esses programas às vezes são chamados "daemons", e por causa disso os seus nomes com certa frequência são o nome do protocolo com a letra "d" acrescentada (e.g. httpd, ftpd, talkd, etc). Vejamos alguns exemplos de clientes TCP de largo uso, de hoje e de ontem...

Questões

2.1 Levante quais são os comandos do protocolo POP3, indicando qual foi o documento que você consultou (de preferência o RFC com a versão mais recente do protocolo).

2.2 Dois web servers diferentes (por web server entendemos aqui um produto de sotware como o IIS ou o Apache) podem rodar num mesmo computador de forma simultânea?

2.3 Porque um mesmo computador pode oferecer vários serviços TCP diferentes (http, ftp, pop, etc) de forma simultânea? Descubra na Internet um computador atendendo conexões em mais de uma porta.

2.4 Quais são os comandos previstos pelo HTTP e pelo FTP para reiniciar o download de um arquivo já parcialmente baixado?

2.5 Suponha que a sua caixa postal no provedor contenha um email de 25 megabytes que você não consegue baixar no cliente de email porque a ligação telefônica cai antes da transferência se completar. Explique como você faria usando o cliente telnet para deletar esse email da caixa postal a fim de conseguir baixar os outros.

2.6 O que é um URL? Quais protocolos podem ser especificados através de um URL? quais portas?

2.7 Explique o conceito de janela TCP. Você sabe qual é o tamanho máximo de uma janela na implementação de TCP/IP da plataforma que você usa?

2.8 Mostre como a partir da banda http é possível estimar o total de hits e o máximo de usuários ativos de um sistema de webmail free como o netaddress.

2.9 Explique o que aconteceria se você configurasse o seu cliente de email (Eudora, Outlook) para usar o servidor smtp de um provedor diferente daquele em que você está conectando.

2.10 Explique porque é conveniente que o seu cliente de email (Eudora, Outlook, etc) use o relay do provedor ao invés de realizar o deliver do email diretamente para o destinatário final.

2.11 Estime a banda necessária para o cliente de um sistema centralizado de vigilância que transfira para a central um quadro por minuto, obtido através de uma câmera convencional utilizada em PCs.

3. DNS

DNS como tabela Prática no uso do nslookup O DNS é uma base distribuída Relação entre os protocolos TCP mais usados e o DNS Procedimentos para o registro de nomes Resolução reversa O cache do DNS

Notas

3.1 O DNS

A identificação de cada participante numa rede IP e o roteamento de pacotes para ele baseia-se como vimos nos endereços IP numéricos de 32 bits. Entretanto, é mais cômodo utilizarmos nomes (e.g. altavista.digital.com) para identificar endereços na Internet do que números, mas para isso ser possível é necessário existir um mecanismo de tradução de nomes para endereços numéricos. Esse mecanismo é o DNS (Domain Name System).

O DNS pode ser entendido de forma bastante simples como sendo uma tabela muito, muito grande, mas similar às que estamos acostumados a lidar quando compomos uma planilha ou quando lidamos com bases relacionais. O formato dessa tabela seria algo semelhante ao que segue:

name NS MX A
ibm.com ns.watson.ibm.com, ns.almaden.ibm.com ns.watson.ibm.com 204.146.81.99, 198.133.16.99, 198.133.17.99, 204.146.80.99
linuxtoday.com NS1.INTERNET.COM NS3.INTERNET.COM mail.linuxtoday.com 63.236.72.248
www.linuxtoday.com 63.236.72.248
overdrive.iworld.com 63.236.72.248

Além das colunas indicadas, há outras que omitimos para facilitar a visualização. A tabela na sua totalidade não está fisicamente presente em nenhum computador do mundo, mas sim subdividida por muitos e muitos milhares de servidores de nomes. Quando uma entidade, uma empresa, ou uma pessoa registra um domínio na Internet (por exemplo "globo.com", "usp.br", linux.org", etc), ela torna-se a "autoridade" responsável por todas os linhas da tabela DNS derivadas desse domínio (isto é, aquelas onde o nome refere esse domínio, como por exemplo "www.linux.org" no caso do domínio linux.org).

É importante observar que o administrador de um domínio pode definir a sua própria política de criação de nomes para esse domínio. É hábito que todo domínio (e.g. linuxtoday.com) possua um nome "www" associado ao endereço do servidor web (e.g. "www.linuxtoday.com"), mas a associação do nome "www" ao serviço HTTP é convencional e não compulsória. Se se desejar associar ao nome ftp.linuxtoday.com um registro A apontando para o endereço IP do servidor web, então o URL http://ftp.linuxtoday.com poderá ser usado para acessar as páginas do site linuxtoday. Outros nomes comumente utilizados (além do "www") são "ftp", "mail", "mailhost", "ns", "smtp", "pop", etc

Assim, vemos no exemplo acima que a IBM estabeleceu na Internet dois servidores de nomes (o ns.watson.ibm.com, ns.almaden.ibm.com) que são os responsáveis por todos os nomes terminados em "ibm.com". De forma análoga, os servidores de nomes do domínio linuxtoday.com são NS1.INTERNET.COM e NS3.INTERNET.COM. No momento em que alguém preenche o campo de endereço do Netscape com o URL http://www.linuxtoday.com, um query terá que ser feito a um desses dois servidores a fim de se obter o endereço IP associado ao nome www.linuxtoday.com. Esse endereço é o registro A, que na nossa tabela estão na coluna A, e no caso citado é 63.236.72.248.

3.2 As raízes do DNS

De que maneira alguém fica sabendo que os servidores de nomes responsáveis pelo domínio ibm.com são os citados acima? O DNS é um sistema hierárquico, que redistribui a responsabilidade pelos nomes, e que parte de uma determinada raiz. Todo query de nomes começa nessa raiz e vai descendo na hierarquia. Assim, é necessário conhecer de antemão quem é a raiz ou, na verdade quem são as raízes, pois a raiz está espelhada em vários computadores diferentes. As raízes são indicadas no arquivo named.root, do qual segue um trecho inicial:

;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  "
;       configuration file of BIND domain name servers).
;
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
;
;
; formerly NS.INTERNIC.NET
;
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
;

Vemos nele os endereços das raízes do DNS (no trecho constam o 198.41.0.4 e o 128.0.9.107) ou, mais precisamente, dos hints, ou seja, das máquinas para as quais os servidores de nomes do mundo todo solicitarão a lista atual das raízes do DNS toda vez que forem reinicializados. As raízes repassam a autoridade dos nomes para outros servidores, e esses para outros, e assim por diante. Por exemplo: as raízes repassam a autoridade sobre o domínio .br para a FAPESP. Assim, se alguém na Internet quiser saber qual é o registro A associado ao nome www.usp.br, terá que obter junto às raízes quem é o responsável pelo .br, junto a esse responsável (isto é, os nameservers da FAPESP) terá que obter quem é o responsável pelo domínio .usp.br e, finalmente, junto a esse último responsável (isto é, os nameservers da USP), obter o endereço associado ao nome www.usp.br.

Note que não há nada que privilegie as atuais raízes do DNS além do fato de que, por um consenso histórico, todos os servidores de nomes utilizem exatamente essas raízes. Tecnicamente nada impede alguém de criar uma raiz independepende que delegue a autoridade sobre os diferentes domínios (.br, .com, etc) para computadores diferentes daqueles que são atualmente os que recebem essa delegação. E, de fato, tem surgido na Internet algumas iniciativas para criar raízes independentes, como o "Super Root" (http://www.superroot.net/).

3.3 Procedimentos para registro de nomes

A estrutura hierárquica do DNS faz com que o registro de um domínio (isto é, a inclusão de mais um domínio na tabela DNS global) só pode ser feito junto à entidade responsável pelo domínio hierarquicamente acima do que se deseja registrar. O domínio .br está sob a responsabilidade da FAPESP (Fundação de Amparo à Pesquisa do Estado de São Paulo), e por isso o registro de nomes que terminem em .br como .com.br ou .org.br deve ser feito junto a ela. Historicamente o registro de nomes foi sempre feito através do envio de formulários pelo correio eletrônico, mas recentemente a FAPESP criou uma interface web para o registro e a manutenção de nomes (http://registro.br).

Empresas, entidades e pessoas jurídicas no Brasil via de regra registram nomes .br ou alternativamente .com ou .org ou .net. Os domínio .com, .org e .net não estão sob a autoridade da FAPESP, e o registro de domínios nesse caso deve ser feito junto à Internic (http://www.internic.net) ou mais precisamente junto aos "registrars" que ela credenciou. Esses registrars oferecem interfaces web através das quais o domínio pode ser registrado.

Quais são as exigências para o registro de um domínio? Isso depende da entidade responsável, e em geral envolve o pagamento de taxas. No Brasil, as normas para registro de domínios são determinadas pelo Comitê Gestor (http://www.cg.org). Além disso, todo domínio precisa ter um contato administrativo e um contato técnico (isto é pessoas que respondam por esse domínio).

3.4 O comando nslookup

As aplicações TCP/IP como o ping ou o ftp costumam fazem queries DNS através de serviços de API disponibilizados pelo sistema operacional ou por bibliotecas do sistema. Assim, um comando como ping altavista.digital.com envolve uma etapa prévia, e que corresponde ao query do endereço IP associado ao nome altavista.digital.com. O comando nslookup por sua vez é um cliente standalone do DNS, que pode ser utilizado para realizar queries manualmente. A familiaridade com o nslookup é importante para as pessoas que necessitam diagnosticar problemas de rede ou fazer registro e manutenção de domínios.

Seguem vários exemplos de uso no modo "não-interativo" (o nslookup possui também um modo de operação "interativo" que oferece maiores recursos). No primeiro exemplo incluímos a resposta completa do nslookup, que inicia-se com a identificação do nameserver consultado. Nas demais, omitimos essa identificação para despoluir o texto.

Qual é o endereço associado ao nome www.ibm.com?

  $ nslookup www.ibm.com
  Server:  hal.home.unet
  Address:  192.168.0.1

  Name:    www.ibm.com
  Addresses:  204.146.81.99, 198.133.16.99, 198.133.17.99, 204.146.80.99

Qual é o nome associado ao endereço 204.146.81.99?

  $ nslookup 204.146.81.99

  Name:    www.ibm.com
  Address:  204.146.81.99

Qual é o nameserver do domínio 146.204.in-addr.arpa? (esse é um domínio artificial utilizado para cadastrar no DNS os reversos dos IPs iniciados com 204.146).

  $ nslookup -query=ns 146.204.in-addr.arpa

  Non-authoritative answer:
  146.204.in-addr.arpa    nameserver = NS1.US.PRSERV.NET
  146.204.in-addr.arpa    nameserver = NS01.CA.US.IBM.NET

  Authoritative answers can be found from:
  NS1.US.PRSERV.NET       internet address = 165.87.194.244
  NS01.CA.US.IBM.NET      internet address = 165.87.201.244

Qual é o servidor MX (responsável pelo recebimento de email) do domínio ibm.com?

  $ nslookup -query=mx ibm.com

  ibm.com preference = 0, mail exchanger = ns.watson.ibm.com
  ibm.com nameserver = ns.watson.ibm.com
  ibm.com nameserver = ns.almaden.ibm.com
  ns.watson.ibm.com       internet address = 198.81.209.2
  ns.almaden.ibm.com      internet address = 198.4.83.35

Quais são os servidores de nome do domínio .br?

  $ nslookup -query=ns br

  Non-authoritative answer:
  br      nameserver = NS.DNS.br
  br      nameserver = NS-EXT.VIX.COM
  br      nameserver = NS3.NIC.FR
  br      nameserver = NS2.DNS.br
  br      nameserver = NS1.DNS.br

  Authoritative answers can be found from:
  NS.DNS.br       internet address = 143.108.23.2
  NS-EXT.VIX.COM  internet address = 204.152.184.64
  NS3.NIC.FR      internet address = 192.134.0.49
  NS2.DNS.br      internet address = 200.19.119.99
  NS1.DNS.br      internet address = 200.255.253.234

Qual é o conteúdo do registro SOA do domínio internic.net?

  $ nslookup -query=soa internic.net

  internic.net
          origin = ops.internic.net
          mail addr = markk.internic.net
          serial = 2000051000
          refresh = 3600 (1H)
          retry   = 3600 (1H)
          expire  = 432000 (5D)
          minimum ttl = 86400 (1D)

Qual é o endereço associado ao nome www.internic.net?

  $ nslookup -query=a www.internic.net

  Name:    rs.internic.net
  Address:  198.41.0.6
  Aliases:  www.internic.net

Qual é o endereço associado ao nome www.ietf.org?

  $ nslookup -query=a www.ietf.org

  Name:    www2.ietf.org
  Address:  4.17.168.6
  Aliases:  www.ietf.org

3.5 O cache do DNS

O nslookup não fará todas as etapas do query descritas anteriormente (query inicial à raiz e passos subsequentes descendo na hierarquia de nomes até atingir o ponto desejado). Ele utilizará o serviço de um servidor especializado, que realizará todos aquelas etapas. Por vezes quando se configura manualmente os parâmetros de TCP/IP de um computador, indica-se a ele um ou mais "servidores de nomes". Por exemplo, quando se assina um contrato de acesso discado à Internet, o provedor pode solicitar que essa configuração seja feita manualmente (muitas vezes ela é realizada de forma automática a cada conexão telefônica). Em sistemas Unix-like, esse(s) servidor(es) especializados constam no arquivo /etc/resolv.conf (no Windows, ele(s) está(ão) nas propriedades do TCP/IP, tab "DNS").

Esse servidor especializado cacheia na sua memória as respostas dos queries DNS realizados pelos clientes (como o nslookup, ou clientes TCP como softwares de correio eletrônico ou browsers). A existência desse cache é fundamental para diminuir o tráfego provocado pela consulta de nomes na Internet, e também para acelerar a comunicação, que dessa forma não dependerá, a cada momento em que um query de nomes é feito, de um processo que acrescenta um delay inicial na comunicação.

Por outro lado, isso cria uma dificuldade relativa à reconfiguração dos nameservers responsáveis pelos domínios. Suponha por exemplo que se pretenda alterar o endereço 63.236.72.248 associado ao nome www.linuxtoday.com. O administrador dos nameservers NS1.INTERNET.COM NS3.INTERNET.COM pode alterar o registro A associado a esse nome nesses servidores, mas não pode alterar aquilo que está cacheado em dezenas ou centenas de servidores de nomes ao longo do mundo.

É por esse motivo que se associa a cada registro DNS um tempo de expiração configurável. Ele determina o tempo após o qual um registro expira num cache DNS. Qualquer query subsequente àquele registro provocará um novo acesso ao servidor responsável por aquele registro (no nosso exemplo um dos servidores NS1.INTERNET.COM NS3.INTERNET.COM).

Dessa forma, a alteração das tabelas de um servidor de nomes deve ser precedida de uma reconfiguração dos tempos de expiração dos respectivos registros. Se o tempo de expiração de um registro for, digamos, uma semana, então uma semana antes da alteração das tabelas o tempo de expiração desse registro deve ser reconfigurado para, digamos, uma hora. Vencido o prazo de uma semana, pode-se proceder à alteração das tabelas pois quaisquer cópias desse registro cacheadas em servidores de nomes ao longo do mundo expirará nos próximos 60 minutos e não provocará malfuncionamentos por um período prolongado. Veremos mais sobre esse tempo de expiração ao comentarmos o registro SOA.

3.6 Descrição breve dos tipos de registros

Vejamos agora de forma um pouco mais detalhada o papel dos registros principais do DNS:

Obs. O comando nslookup costuma ser nativo nas plataformas Unix-like. O Windows não traz nativamente nenhum equivalente ao nslookup.

Questões

3.1 Explique o que é o domínio in-addr.arpa.

3.2 Como você faria através do cliente nslookup para saber se um dado domínio já foi ou não registrado por alguém?

3.3 Ao nível do DNS, o que é necessário para (a) criar um novo domínio na Internet e (b) trocar a hospedagem de um domínio já existente.

3.4 Suponha que o nome da sua empresa já tenha sido registrado na Internet, mas não pela sua empresa. Como você procederia para entrar em contato com a pessoa (física ou jurídica) que fez o registro e possui a autoridade sobre ele?

3.5 Explique o que aconteceria se você configurasse o seu computador doméstico para usar o servidor DNS de um provedor diferente daquele em que você está conectando.

3.6 Localize na Internet algum software que permita a você rodar diretamente no seu micro doméstico um servidor de nomes e dessa forma não necessitar daquele oferecido pelo provedor de acesso.

3.7 Como você faria para descobrir em que lugar do mundo está hospedado o site de um seu rival comercial?

3.8 Por que através do DNS é possível obter o servidor smtp associado a um dado domínio mas não o pop?

3.9 Visite as páginas do Comitê Gestor da Internet Brasil e levante o que é necessário pelas regras atuais para o registro de domínios .com.br e .org.br. Explique o que são domínios pessoais.

3.9 Qual é a diferença entre DNS primário e secundário? (você pode explicar isso do ponto de vista do NIC, que somente outorga a autoridade sobre um domínio após a configuração do primário e do secundário, ou do ponto de vista do bind, relativo à configuração de um servidor primário ou de um seu espelho, o secundário).

3.10 Quando você especifica um URL como http://altavista.digital.com ao Netscape e pressiona o ENTER, qual será o tipo de consulta que ele terá que fazer ao DNS (isto é, qual tipo de registro associado a qual nome)? Idem para o caso do servidor SMTP do seu provedor quando ele vai fazer o deliver de um email seu para o endereço fmarinho@ibpinert.net. Diga quais serão nos dois casos as máquinas entre as quais será criado o canal virtual TCP e quais serão as portas utilizadas.

3.11 O que é WHOIS?

4. O Algoritmo de roteamento IP

  • Roteamento na LAN ethernet: ARP
  • Uso do comando arp
  • Roteamento na WAN: o gateway para as outras redes
  • A Tabela de rotas e o comando route
  • O conceito de máscara (netmask)
  • As duas notações para máscaras
  • A rota default
  • Exemplo simples de 2 redes interligadas
  • Exemplo de ligação à Internet de uma LAN e máscara /24
  • O caso de pacotes com endereços de origem incorretos
  • Conceito de source routing
  • Protocolos de anúncio de rotas
  • ARP como artifício para o roteamento (proxy-arp)
  • ARP spoofing e clusters
  • Conceito de broadcast IP
  • A interface loopback

    Notas

    4.1 Rotas IP

    De que maneira um pacote atinge o seu destino na Internet? A Internet e a forma com que cada pacote é encaminhado ao seu destino podem ser comparadas ao sistema viário de uma cidade ou de um país. Em cada ponto onde houver bifurcações, sinaliza-se qual saída deve ser escolhida a partir do destino que se pretende atingir: Ibirapuera à esquerda, Santos à direita, Ponte da Freguesia do Ó em frente, etc.

    De forma análoga, cada participante de uma rede IP possui uma tabela informando qual interface deve ser utilizada para o envio do pacote, dependendo do seu destino. No Windows, podemos exibi-la com o comando ROUTE PRINT. Nas plataformas Unix-like, o comando poderá ser netstat -r ou route.

      $ route -n
      route -n
      Kernel IP routing table
      Destination   Gateway       Genmask         Flags Metric Ref Use Iface
      200.231.191.1 0.0.0.0       255.255.255.255 UH    0      0     0 ppp0
      192.168.0.1   0.0.0.0       255.255.255.255 UH    0      0     0 eth0
      192.168.0.0   0.0.0.0       255.255.255.0   U     0      0     0 eth0
      127.0.0.0     0.0.0.0       255.0.0.0       U     0      0     0 lo
      0.0.0.0       200.231.191.1 0.0.0.0         UG    0      0     0 ppp0
    

    Na tabela acima vemos que se o destino for 200.231.191.1, deve ser utilizada a interface ppp0, que no caso corresponde fisicamente à porta serial onde o modem está operando. Por outro lado, se o destino for da forma 192.168.0.X onde X é qualquer octeto, então vemos pela terceira rota que deverá ser utilizada a interface eth0, ou seja, a placa de rede ethernet. A diferença entre uma rota para um destino único ou para múltiplos destinos é determinada pela máscara.

    A máscara indica quais bits são significativos no respectivo destino. Na tabela acima, a primeira rota está dizendo que todos os bits são significativos e, a terceira, que apenas os primeiros três octetos (os primeiros 24 bits) são significativos. Se, vamos supor, os primeiros 28 bits fossem significativos, a máscara seria 255.255.255.240. A máscara 255.255.255.0 pode alternativamente ser indicada na forma "/24" (e a máscara 255.255.255.240 na forma "/28", etc).

    A porção significativa do campo de destino costuma ser chamada de "endereço da rede" e, o restante, "endereço do host". Assim, no exemplo acima temos que o endereço da rede é 192.168.0.0 com máscara 255.255.255.0. A terceira rota é dita a rota para a "rede local". A última rota, com destino 0.0.0.0 e máscara 0.0.0.0 é a chamada "rota default", porque satisfaz qualquer destino, ou seja, qualquer pacote cujo roteamento não possa ser enquadrado nas rotas anteriores irá enquadrar-se na rota default.

    No nosso exemplo a rota default indica um "gateway". Existirá um gateway sempre que o destino não estiver diretamente acessível. A tabela de rotas não indica um gateway para o destino 192.168.0.2. Isso significa que esse IP é diretamente acessível no segmento ethernet local, e portanto podemos gerar um pacote com um cabeçalho ethernet (MAC) indicando como destinatário o endereço de hardware do 192.168.0.2 (ver as notas sobre ARP). Se existisse uma rota para o network 192.168.1.0/24 indicando como gateway o IP 192.168.0.1, então todo pacote dirigido para, vamos supor, 192.168.1.1, traria no seu cabeçalho IP o destino 192.168.1.1 mas no cabeçalho ethernet indicaria como destinatário o endereço de hardware associado ao 192.168.0.2.

    Isso reforça um fato importante, e que é que, no IP, cada participante conhece apenas o "caminho" para os participantes que lhe são imediatamente acessíveis. Alguns desses participantes que são imediatamente acessíveis funcionam como gateways para outras redes, mas o caminho que os pacotes realizam a partir desses gateways é-nos desconhecido.

    A tabela de rotas é construída automaticamente pelos procedimentos de boot da máquina. Ela pode também ser dinamicamente alterada pelo recebimento de pacotes de anúncios de rotas nas diversas interfaces da máquina. Esse tema pertence a um capítulo amplo do TCP/IP, o dos protocolos de roteamento, que não são cobertos por estas notas, e que são mais pertinentes aos técnicos responsáveis por backbones de médio e grande porte.

    4.2 Outorga de IPs e classes de endereços

    O princípio de funcionamento do roteamento IP faz com que os endereços IPv4 sejam distribuídos aos blocos. Por exemplo: a Universidade de São Paulo dispõe dos endereços da forma 143.107.X.Y. Ela repassou para o Instituto de Matemática os endereços da forma 143.107.45.X, para o Instituto Astronômico e Geofísico os endereços da forma 143.107.114.X, e assim por diante. Cada interface que conecte fisicamente uma unidade (como as citadas) à infraestrutura central da Universidade roteia os IPs daquela interface, e portanto existe apontando para ela uma rota com máscara 255.255.255.0.

    Esse exemplo localizado estende-se para toda a Internet. Ao longo do estabelecimento da Internet, o intervalo total de endereços IPv4 foi sendo dividido em blocos e concedido aos pedaços a instituições e a empresas, sendo que em alguns casos, essa instituição ou empresa podia ser a responsável pelo backbone principal da Internet de um país inteiro. Foi dessa forma que o Brasil recebeu parte da rede 200 (IPs da forma 200.X.Y.Z), e estes são os endereços utilizados pela maior parte da Internet brasileira atualmente.

    Note que isso faz com que não seja possível configurar o endereço IP de uma interface com um número escolhido ao acaso. Uma pessoa na Europa (por exemplo) não pode configurar um seu computador com um endereço IP como 143.107.45.12, porque as rotas ao longo da Internet conduzem para o Brasil os pacotes cujo destino é 143.107.45.12. Aquela pessoa que na Europa utilizou esse endereço será capaz de enviar pacotes para qualquer servidor web da Internet (por exemplo) mas os pacotes de resposta gerados pelo servidor jamais atingirão o computador que iniciou a comunicação.

    A outorga de endereços em blocos faz com que parte dos endereços fiquem ociosos, e agrava o atual problema do escasseamento dos endereços IP. Esse escasseamento, que é reflexo da impossibilidade do uso de endereços de 32 bits para uma rede efetivamente mundial, foi um dos motivos que levou ao desenvolvimento da versão 6 do protocolo IP (IPv6 ou IPng), onde foram adotados endereços de 128 bits. Recentemente a Universidade de Stanford "devolveu" os 16 milhões de endereços que haviam sido outorgados a ela anos atrás, numa época em que a Internet era muito menor, e em que foram concedidos endereços "classe A" para várias universidades e empresas.

    Obs. (1) o intervalo de endereços IP está subdividido em cinco classes:

    Obs. (2) A subdivisão dos networks exigida pelo escasseamento do intervalo de endereços IP tornou muito relativa a importância prática do conceito de classe. Na prática chega a ser comum o uso dos termos "classe B" ou "classe C" não para indicar algum dos networks citados acima, mas sim networks quaisquer que usem as respectivas máscaras (255.255.0.0 e 255.255.255.0).

    Questões

    4.1 Explique o conceito de netmask e cite as duas formas típicas com que se costuma especificar netmasks.

    4.2 Escreva usando qualquer linguagem de programação (ou pseudo-código) o algoritmo de roteamento IP, pressupondo que a tabela de rotas esteja devidamente representada numa estrutura de dados conveniente.

    5. Dê exemplos de networks das classes A, B e C. Diga quais são os nemasks associados a eles e quantos endereços cada um comporta. Explique porque é algoritmicamente fácil de identificar a classe de um network.

    5. O tcpdump

    Notas

    5.1 O tcpdump

    O tcpdump é uma ferramenta importante para a administração de redes e para uma maior familiarização com o TCP/IP. Ele foi desenvolvido originalmente para sistemas Unix-like, mas possui um porte para Windows, chamado windump. A finalidade do tcpdump é capturar os pacotes que passam por uma interface. Os cabeçalhos desses pacotes são exibidos no console, um por linha:

      $ tcpdump -i eth0 -l -n
      13:57:56.876424 192.168.0.1.1044 > 192.168.0.2.23: S 3767238723:3767238723(0) win 32120  (DF)
      13:57:56.878184 192.168.0.2.23 > 192.168.0.1.1044: S 1049035122:1049035122(0) ack 3767238724 win 32736 
      13:57:56.878370 192.168.0.1.1044 > 192.168.0.2.23: . ack 1 win 32120 (DF)
      13:57:56.881182 192.168.0.1.1044 > 192.168.0.2.23: P 1:28(27) ack 1 win 32120 (DF)
      13:57:56.900704 192.168.0.2.23 > 192.168.0.1.1044: . ack 28 win 32709 (DF)
      13:57:57.115026 192.168.0.2.23 > 192.168.0.1.1044: P 1:13(12) ack 28 win 32709 (DF)
    

    Os pacotes acima referem-se a uma conexão TELNET. Observe que a máquina 192.168.0.1 enviou (primeira linha) um pacote para a máquina 192.168.0.2. As portas envolvidas são 1044 (cliente) e 23 (servidor). O caractere "P" que vemos na quarta linha significa que nesse pacote a flag PUSH do cabeçalho TCP está ativa. Outras flags comuns são "S" (como vemos nas duas primeiras linhas), "F" (flag FYN, sinalizadora do final da conexão) ou "R" (reset). A flag PUSH foi prevista para evitar delays de bufferização no envio ou repasse dos dados recebidos para a aplicação, no entanto as implementações de TCP/IP ou ignoram essa flag ou setam-na sempre.

    O "S" significa que a flag SYN está ativa, isto é trata-se de um pedido de sincronização, o que indica início de uma conexão. A sincronização significa o informe do sequence number inicial. É através do sequence number (um inteiro de 32 bits como podemos ver no cabeçalho TCP) que o TCP/IP sabe a posição de cada segmento dentro do stream. O sequence number inicial não é zero, mas costuma ser uma função do relógio da máquina, a fim de diminuir a probabilidade de na reutilização de uma porta já desalocada o recebimento acidental de pacotes referentes a uma conexão anterior que utilizou aquela porta provoque erros.

    O par de números separados por dois pontos (":") informa o trecho do stream ao qual corresponde o segmento carregado pelo pacote. Assim, vemos que a quarta linha corresponde a um segmento de 27 bytes. A rigor o tcpdump não consegue inferir a posição desse segmento dentro do stream justamente porque o sequence number inicial é desconhecido, exceto, é claro, no caso em que o tcpdump capturou os pacotes de sincronização dessa conexão e memorizou esses sequence numbers (veja esses números iniciais na primeira e segunda linhas).

    Cada pacote TCP carrega ainda um acknowledge informando até qual posição o strem proveniente da outra ponta já foi recebido. É a ausência desse acknowledge que provoca no TCP a retransmissão de pacotes em intervalos de tempo exponencialmente crescentes. Na linha 5 vemos um "28", que indica o acknowledge dos 27 bytes recebidos.

    Finalmente, cada segmento informa ao outro lado o tamanho da janela admitido naquele ponto da comunicação. Assim, vemos na quinta linha que o participante informa ter já recebido 27 bytes e sinaliza que poderão ser enviados mais 32709 antes que a aplicação seja blocada pelo aguardo de um acknowledge dos segmentos enviados ou ao menos de uma parte deles.

    O tcpdump é a ferramenta utilizada para analisar e estudar as principais características e protocolos do TCP/IP pelo livro TCP/IP Illustrated de W. R. Stevens, que em geral é considerado a principal referência da área atualmente. O título Illustrated deve-se justamente ao fato do tcpdump apresentar como que uma imagem dos protocolos em funcionamento. Ao longo destas notas estaremos utilizando-o algumas vezes com essa finalidade.

    Na medida em que ele realiza captura de pacotes e dos seus dados, o tcpdump pode também ser utilizado também para espionar tráfego alheio. Não obstante, a sua finalidade principal é administrativa, mesmo porque os recursos do tcpdump são limitados. Ele não é capaz, por exemplo, de realizar a montagem dos pacotes TCP a fim construir a sequência de bytes gerada pelo cliente e/ou pelo servidor, e a sua capacidade para extrair o conteúdo da área de dados dos pacotes é relativamente limitada.

    6. Network Programming

    Prática com NP Métodos para atendimento a múltiplas conexões Tour pela implementação de TCP/IP do Linux Exercício prático: Mala direta

    Notas

    6.1 Um servidor TCP minimal

    Um melhor conhecimento do TCP/IP depende de alguma experiência com programação. O código que segue corresponde a um servidor TCP escrito na linguagem PERL. Ele pode ser rodado em plataformas Unix-like ou Windows sem alterações (desde que seja utilizado o interpretador PERL original, escrito por Larry Wall). Os números de linha não fazem parte do programa. As linhas que se iniciam com o caractere '#' são comentários. A APIs de programação TCP/IP do PERL reproduz a API de Berkeley, que é seguida por muitas implementações de TCP/IP e muitas linguagens de programação, e por isso esses exemplos poderão ser transportados com facilidade para outros ambientes.

    Na linha 16 é alocado um descritor de comunicação (socket). Ele é inicializado para operar com TCP (outra alternativa seria UDP) ouvindo conexões na porta 3456. Por simplicidade não estamos consistindo os valores de retorno das chamadas da API de sockets. Elas poderiam sinalizar erros (por exemplo no caso da porta 3456 já estar alocada por outra aplicação).

    A linha 21 apresentará uma mensagem de start-up no console e o loop infinito das linhas 23-49 inicialmente aguarda um pedido de conexão (linha 25), e em seguida apresenta no console o pedido aceito (linha 29). No loop 38-46 o servidor lê o socket associado ao cliente e executa os comandos time e quit. Note que durante a execução do loop 38-46 o servidor estará impossibilitado de aceitar uma segunda conexão simultânea (para isso seria necessário fazer um novo chamado do serviço accept).

    Uma vez disparado esse servidor, é necessário conectá-lo através de um cliente TCP, que poderá ser o telnet, o cliente dado logo a seguir ou mesmo um browser web (neste caso qual seria o URL a ser utilizado?).

    01 #!/usr/bin/perl
    02 #
    03 # tcpsrv2: simple TCP server with command loop
    04 # usage: perl tcpsrv2
    05 #
    06 
    07 use Socket;
    08 
    09 sub logmsg {
    10     print "$0: @_ at ", scalar localtime, "\n";
    11 }
    12 
    13 $port = 3456;
    14 $proto = getprotobyname('tcp');
    15 
    16 socket(Server, PF_INET, SOCK_STREAM, $proto);
    17 setsockopt(Server, SOL_SOCKET, SO_REUSEADDR,pack("l", 1));
    18 bind(Server, sockaddr_in($port, INADDR_ANY));
    19 listen(Server,SOMAXCONN);
    20 
    21 logmsg "server started on port $port";
    22 
    23 while (1) {
    24 
    25     $paddr = accept(Client,Server);
    26     ($port,$iaddr) = sockaddr_in($paddr);
    27     $name = gethostbyaddr($iaddr,AF_INET);
    28 
    29     logmsg "connection from $name [",
    30             inet_ntoa($iaddr), "]
    31             at port $port";
    32 
    33     select(Client);
    34     $| = 1;
    35     print Client "Hello there, $name\r\n";
    36 
    37     $f = 0;
    38     while ($f == 0) {
    39         $_ = ;
    40         if ($_ =~ /time/) {
    41             print Client ( scalar localtime ) . "\r\n";
    42         }
    43         elsif ($_ =~ /quit/) {
    44             $f = 1;
    45         }
    46     }
    47 
    48     close(Client);
    49 }
    

    6.2 Um cliente TCP minimal

    Esse exemplo difere do exemplo do servidor por não colocar o socket em "listen". Não obstante, assim como no caso do servidor, o socket é configurado para operar com TCP numa porta local, que no caso é deixada à escolha do layer de TCP/IP (veja o "0" na linha 25). Na linha 26 empacotamos numa estrutura binária o endereço e a porta remotos para, na linha 35, conectarmos. Na linha 41 enviamos o comando especificado na chamada do script, e no loop seguinte lemos e enviamos para o console a resposta do servidor.

    01 #!/usr/bin/perl
    02 #
    03 # tcpcl - generic TCP client
    04 # --------------------------
    05 #
    06 # usage: perl tcpcl host port command
    07 # example: perl tcpcl altavista.digital.com 80 "GET /"
    08 #
    09
    10 use Socket;
    11 use Sys::Hostname;
    12
    13 $them = $ARGV[0];
    14 $port = $ARGV[1];
    15
    16 $AF_INET = 2;
    17 $SOCK_STREAM = 1;
    18 $sockaddr = 'S n a4 x8';
    19
    20 $hostname = hostname();
    21 ($name,$aliases,$proto) = getprotobyname('tcp');
    22 ($name,$aliases,$port) = getservbyname($port,'tcp') unless $port =~ /^\d+$/;
    23 ($name,$aliases,$type,$len,$thisaddr) = gethostbyname($hostname);
    24 ($name,$aliases,$type,$len,$thataddr) = gethostbyname($them);
    25 $this = pack($sockaddr, $AF_INET, 0, $thisaddr);
    26 $that = pack($sockaddr, $AF_INET, $port, $thataddr);
    27
    28 # Make the socket filehandle.
    29 socket(S, $AF_INET, $SOCK_STREAM, $proto);
    30
    31 # Give the socket an address.
    32 bind(S, $this);
    33
    34 # Call up the server.
    35 connect(S,$that);
    36
    37 # Set socket to be command buffered.
    38 select(S); $| = 1; select(STDOUT);
    39
    40 # send the command and read the output
    41 print(S "$ARGV[2]\r\n");
    42 sleep(1);
    43 while (<S>) {
    44     print;
    45 }
    46 close(S);
    

    6.3 Um cliente/servidor UDP minimal

    O código que segue é ao mesmo tempo um cliente e um servidor UDP, e foi pensado para ser utilizado num teste em sala de aula. Nas linhas 10-15 um socket é alocado e configurado para operar com UDP na porta local 3456. No loop das linhas 20-25 envia-se um pacote UDP para cada um dos destinos especificados na linha de comandos. Note que em virtude de no UDP não existir o conceito de conexão, o destino dos pacotes não está implícito no socket, mas precisa ser explicitado a cada transmissão (linha 24).

    No loop das linhas 31-39 aguarda-se algum pacote de qualquer um dos participantes, até um máximo igual ao número de destinatários na linha de comandos. O "select" usado na linha 31 aguarda um evento num conjunto de descritores (com um timeout de 10 segundos), e que no caso foi construído para conter apenas o socket UDP que estamos utilizando. A cada pacote UDP recebido, o select retornará e na linha 36 exibiremos a mensagem recebida naquele pacote.

    01 #!/usr/bin/perl
    02 #
    03 # udpmsg: simple UDP client and server
    04 # usage: udpmsg host1 host2 ...
    05 #
    06
    07 use Socket;
    08 use Sys::Hostname;
    09
    10 $iaddr = gethostbyname(hostname());
    11 $proto = getprotobyname('udp');
    12 $port = 3456;
    13 $paddr = sockaddr_in(3456, $iaddr); # 0 means let kernel pick
    14 socket(SOCKET, PF_INET, SOCK_DGRAM, $proto);
    15 bind(SOCKET, $paddr);
    16
    17 sleep(3);
    18 $| = 1;
    19 $count = 0;
    20 for $host (@ARGV) {
    21     $count++;
    22     $hisiaddr = inet_aton($host);
    23     $hispaddr = sockaddr_in($port, $hisiaddr);
    24     send(SOCKET, "hello", 0, $hispaddr);
    25 }
    26
    27 $rin = '';
    28 vec($rin, fileno(SOCKET), 1) = 1;
    29
    30 # timeout after 10.0 seconds
    31 while ($count && select($rout = $rin, undef, undef, 10.0)) {
    32
    33     if (defined($hispaddr = recv(SOCKET, $msg, 10, 0))) {
    34         ($port, $hisiaddr) = sockaddr_in($hispaddr);
    35         $host = gethostbyaddr($hisiaddr, AF_INET);
    36         printf "%-12s $msg\n", $host;
    37         $count--;
    38     }
    39 }
    

    6.4 Atendimento baseado em select

    Os mecanismos principais de funcionamento dos softwares de comunicação são elementos que devem ser conhecido pelo profissional de Internet, mesmo que não seja um desenvolvedor de software, pois isso é importante para a avaliação de um produto ou de uma solução. Vimos nas notas anteriores a estrutura geral de um servidor TCP e de um cliente TCP. Veremos agora de forma mais detalhada o modo através do qual um mesmo servidor atende múltiplas conexões numa mesma porta (vamos supor, a porta default do serviço HTTP, ou seja, a 80).

    Vimos no exemplo do servidor TCP que através da referência a um descritor, o serviço accept recebe uma conexão de um cliente e devolve à aplicação um segundo descritor, através do qual a comunicação com aquele cliente é realizada. Assim, para ser capaz de atender múltiplas conexões, um servidor (o termo servidor aqui refere um software como o IIS ou o Apache, e não um computador) precisa manter múltiplos descritores de comunicação, um para cada cliente que esteja sendo atendido (ao mesmo tempo em que mantém aquele primeiro, para o accept de novas conexões).

    Nas formas mais simples de I/O, a escrita ou a leitura de dados num descritor é blocante, ou seja, paralisa o processo se aquele descritor não estiver apto naquele momento para realizar a operação. Por exemplo: numa escrita, o processo bloca se o buffer de saída já estiver cheio ou na leitura o processo bloca se o buffer de entrada estiver vazio. Numa modalidade de atendimento múltiplo, o I/O não pode ser blocante porque enquanto se aguarda o recebimento de dados num descritor, o servidor poderia estar processando os dados já recebidos num outro descritor.

    As APIs de programação oferecem em geral duas possíveis soluções para esse problema: uma é a possibilidade da operação ser não blocante, e a outra é o recurso de sinalizar à aplicação um determinado evento ou estado em algum descritor. No primeiro caso teriamos por exemplo que um serviço de escrita que normalmente blocaria retorna com um diagnóstico de falha que a aplicação deverá tratar. No segundo, a aplicação é avisada que um determinado descritor está apto para que seja realizada nele uma operação de leitura ou de escrita. Em ambiente Unix, esse segundo caso é tradicionalmente implementado de forma síncrona através de um system call chamado select. O Winsock implementou uma variante assíncrona do select cuja sinalização é realizada através do recebimento pela aplicação de um evento (no sentido próprio que esse termo possui no ambiente windows).

      01 $rin = '';
      02 for ($n=0,$i=0; $i<$MAXCL; ++$i) {
      03     if ($CL[$i] ne "") {
      04         ++$n;
      05         vec($rin,fileno("CL$i"),1) = 1;
      06     }
      07 }
      08 if ($n > 0) {
      09     $nfound = select($rout=$rin,undef,undef,$TICK);
      10 }
      11 else {
      12     select(undef,undef,undef,$TICK);
      13 }
    

    O exemplo acima é parte do programa uplink (http://www.ime.usp.br/~ueda/uplink/). Nas linhas 1-10 é construído o "conjunto" $rin de todos os descritores de comunicação ativos (um para cada cliente conectado). Ao final dele, a variável $n contém o total de clientes conectados. Se esse total for positivo, então na linha 9 executamos o select, que retorna ou avisando que algum dos descritores indicados possui dados para leitura ou, após um timeout indicado pela variável $TICK.

    Num outro ponto do programa vemos como o select é utilizado para detetar um pedido de conexão pendente. Nesse caso, o bloco referente ao if deverá executar o accept e incluir o descritor obtido no vetor CL referido acima na linha 3.

        $rin = '';
        vec($rin,fileno(Server),1) = 1;
        if (select($rout=$rin,undef,undef,0) > 0) {
    

    Obs. A linguagem perl não é a mais apropriada para entender-se o funcionamento do select porque nela esse mesmo nome (select) refere também um outro serviço que tem uma semântica independente, o que pode causar alguma confusão.

    6.5 Atendimento baseado em fork

    A técnica que vimos acima é não é de uso muito frequente. Em geral, servidores que atendem múltiplas conexões fazem-no através do disparo de uma instância para cada cliente. Essa instância pode ser um subprocesso ou um thread. No Unix, a criação de um subprocesso é feita através do system call fork. Os livros de network programming trazem vários exemplos de como isso pode ser feito. Segue abaixo um exemplo simples adaptado de um software real:

      01 /* child will deal with the new connection */
      02 if ((child=fork()) < 0)
      03     tlog("fork error\n");
      04
      05 /* to avoid zombies */
      06 else if (child == 0) {
      07 
      08     /* makes an orphan */
      09     if ((child=fork()) < 0)
      10         tlog("could not make an orphan\n");
      11
      12     /* child will forward messages */
      13     else if (child == 0) {
      14         close(lsock);
      15         forward();
      16         exit(0);
      17     }
      18 
      19     /* parent is wait-ing us */
      20     exit(0);
      21 }
      22
      23 /* waits the first child die */
      24 else
      25     wait(NULL);
    

    No momento em que o kernel atende a chamada do fork na linha 2, passam a existir dois processos ao invés de um. Os dois são idênticos e estão executando o mesmo código no mesmo ponto (isto é, em ambos acabamos de retornar da chamada do fork). No caso do processo original, o fork retorna um valor maior que zero, e que é o PID (process ID) do subprocesso. No caso do subprocesso, o fork retorna o valor zero. O subprocesso possui uma cópia exata da mesma área de memória de dados que o processo original, o que inclui cópias dos mesmos descritores de comunicação que o processo original estava mantendo abertos.

    Nesse nosso exemplo são realizados na verdade dois disparos de subprocessos (nas linhas 6 e 9). Isso se faz para evitar o surgimento de zumbis. O processo que atende a conexão será na verdade "neto" do processo original e não "filho". O atendimento da conexão será feito por uma função especializada chamada na linha 15, finda a qual o processo será encerrado. Se o atendimento fosse feito pelo "filho", na sua terminação o processo original seria sinalizado e teria que requisitar o status de retorno desse "filho" (enquanto ele não o fizer o "filho" será um "zumbi"). Haveria outras maneiras menos dispendiosas de se evitar zumbis, mas seriam um pouco mais complexas, e se o serviço for de baixa demanda pode ser interessante optar pela solução mais simples.

    Note que o fork implica no disparo de um processo, o que via de regra é um procedimento dispendioso para o sistema operacional, pois implica na atualização das estruturas de dados de controle de processos e de descritores de comunicação, e na alocação e cópia de áreas de memória para dados eventualmente grandes (a área de memória usada para armazenar o código do programa é compartilhada entre o processo e o subprocesso, mas as áreas de dados são independentes). Assim, o atendimento de conexões múltiplas baseado no fork pode ser pouco recomendado em serviços de alta demanda, a não ser quando o desenvolvedor opta por fazer com que o subprocesso esteja já disparado antes do pedido de conexão ser recebido. Essa é a técnica implementada (por exemplo) pelo Apache.

    6.6 Atendimento baseado em threads múltiplos

    Uma nova instância de um servidor poderia ser um thread ao invés de um processo. A diferença entre um thread e um processo é que os vários threads disparados por um mesmo processo compartilham uma mesma e única área de dados, e portanto a criação de um thread não implica na alocação e inicialização da área de dados do subprocesso, o que torna o disparo de um thread potencialmente mais barato para o sistema operacional do que o disparo de um processo. O quão mais barato será depende de fato do sistema operacional utilizado.

    Um servidor TCP multithread será dessa forma algo intermediário entre as duas técnicas exemplificadas nas notas anteriores. Assemelha-se ao uso do select por manter todos os descritores de comunicação numa mesma área de dados, e assemelha-se ao fork por criar várias instâncias do servidor. Vejamos um exemplo elementar baseado em pthreads (Posix Threads):

      /*
    
      Simple multi-threaded TCP server
    
      */
    
      #include <stdio.h>
      #include <pthread.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <sys/socket.h>
      #include <netinet/in.h>
      #include <unistd.h>
      #include <string.h>
    
      /* sockets for each client connection */
      #define MAX 10
      int cl[MAX];
    
      void *dialog(void *arg) {
          int c,n;
          char s[80];
    
          c = *((int *)arg);
          *((int *)arg) = -1;
          sprintf(s,"hello, I am thread number %d\n",c);
          for (n=0; n<5; ++n) {
              write(cl[c],s,strlen(s));
              sleep(1);
          }
          close(cl[c]);
          cl[c] = -1;
          return(NULL);
      }
    
      int main(void) {
          pthread_t th[MAX];
          int i,l,new,len;
          struct sockaddr_in laddr, cli_addr;
        
          /* initialize sockets */
          for (i=0; i<MAX; ++i)
              cl[i] = -1;
    
          /* alloc listen socket */
          if ((l = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
              fprintf(stderr,"can't alloc listen socket\n");
              exit(1);
          }
        
          /* make l listen on port 3456 */
          memset(&laddr,0,sizeof(laddr));
          laddr.sin_family = AF_INET;
          laddr.sin_addr.s_addr = htonl(INADDR_ANY);
          laddr.sin_port = htons(3456);
          if (bind(l,(struct sockaddr *)&laddr,sizeof(laddr))<0) {
              fprintf(stderr,"can't bind listen socket\n");
              exit(1);
          }
          listen(l,5);
    
          /* server loops forever */
          while (1) {
    
              /* locate free client socket */
              for (new=-1; new<0; ) {
                  for (i=0; (i<MAX) && (cl[i]>=0); ++i);
                  if (i < MAX)
                      new = i;
                  else
                      sleep(1);
              }
    
              /* wait for connection */
              len = sizeof(cli_addr);
              cl[new] = accept(l,(struct sockaddr *)&cli_addr,&len);
              if (cl[new] < 0)
                  fprintf(stderr,"error while accept-ing\n");
    
              /* fire up thread to control the new client */
              else {
                  pthread_create(th+new,NULL,dialog,(void *)&new);
                  pthread_detach(th[new]);
              }
    
              /* wait thread initialize */
              while (new >= 0)
                  sleep(1);
          }
      }
    
    

    A função dialog encarrega-se do atendimento de cada cliente. A cada novo pedido de conexão, um thread é criado através da chamada do serviço pthread_create. O thread inicialmente seta a variável new (recebida por referência) para -1, em seguida envia cinco vezes uma mensagem de boas-vindas para o cliente e encerra sua execução. Note que o tamanho do vetor cl (cujas entradas são os descritores de comunicação comos clientes) limita o máximo de clientes ativos. Enquanto nenhum descritor estiver livre, o loop de localização de descritores livres (aquele identificado pelo comentário "locate free client socket") não termina.

    O código acima está completo. Para rodá-lo, basta salvá-lo num arquivo (vamos supor: mts.c), compilá-lo e dispará-lo do shell. Supondo que a plataforma possua suporte a Posix threads e que a implementação de Posix threads esteja na biblioteca pthread a compilação e o disparo do servidor seriam assim:

        $ cc -o mts mts.c -lpthread
        $ ./mts &
    

    6.7 SMTP e SPAM

    O correio eletrônico sempre foi e continua sendo um dos serviços mais importantes da Internet (talvez o mais importante). Essa sua importância, aliada à sua inerente complexidade, tornam o correio eletrônico um foco de atenções importante para o profissional que lida com a Internet. Já citamos ao longo destas notas que o protocolo utilizado para o despacho de emails na Internet é o SMTP. O SMTP, como tivemos já a oportunidade de exemplificar (veja a nota TCP, mecanismo de transporte genérico), é de fato um protocolo de roteamento de emails, que faz com que a partir do seu remetente, ele seja transferido de um servidor para outro, até atingir a caixa postal almejada.

    Antes que a Internet se tornasse uma rede comercial, a operação típica de um servidor SMTP assemelhava-se ao de uma agência de correio, no sentido em que qualquer pessoa pode depositar nela correspondência para ser despachada. Uma pessoa no Brasil podia iniciar o envio de um email para o Japão transferindo-o para um servidor SMTP nos Estados Unidos (por exemplo). Este servidor por sua vez verificaria que o destinatário final não era da infraestrutura local, e portanto re-rotearia o email para o seu destino final. Dessa forma ele faria o papel de intermediário (relay) sem ter nada a ver com aquela mensagem (isto é, sem ter parte nem com o originador e nem com o destinatário).

    Essa forma de funcionamento dos servidores SMTP facilitou a ação dos chamados spammers, ou seja, as pessoas que enviam emails não solicitados (via de regra malas diretas para a divulgação de produtos ou serviços). Facilitava também a falsificação de emails, visto que o SMTP não inclui nenhum mecanismo de autenticação (assim como o serviço tradicional de correio também não inclui).

    Por esses motivos, a operação típica dos servidores SMTP da Internet vem mudando nos últimos anos, e tendendo sempre a limitar cada vez mais os clientes que podem realizar transações SMTP num dado servidor, e os cabeçalhos que eles podem gerar. Atualmente (agosto de 2000), os servidores SMTP operando no Brasil em geral aceitam conexões TCP apenas de clientes da infraestrutura local (identificados pelo IP de origem), caso em que o servidor opera como relay (intermediário), ou destinados a caixas postais locais, caso em que o servidor opera como destino final da mensagem. No primeiro caso, alterações recentes tem proibido o cliente de gerar um header com um campo From indicando um endereço eletrônico que não corresponda alguma caixa postal da infraestrutura local.

    6.8 Nota sobre arquivos atachados

    Arquivos atachados em emails são codificados como texto e incluídos no corpo do email com marcas indicadoras do início e final do attachment, a fim de que o destinatário seja capaz de extrair o arquivo. Assim, o envio dos attachments é realizado pelo próprio SMTP e faz parte da transação SMTP que exemplificamos anteriormente. Vejamos um email completo, com header e corpo incluindo um arquivo atachado pequeno chamado right.gif (um ícone):

    From ueda@ime.usp.br  Tue Aug  1 17:29:18 2000
    Return-Path: 
    Received: from hal by hal.home.unet (8.9.3/1.34)
            id RAA00916; Tue, 1 Aug 2000 17:29:18 GMT
    Date: Tue, 1 Aug 2000 14:29:18 -0300 (EST)
    From: Ricardo Ueda Karpischek 
    X-Sender: ueda@hal.home.unet
    To: ueda@listas
    Subject: teste com attachment
    Message-ID: 
    MIME-Version: 1.0
    Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811840-1193269629-965150958=:906"
    Status: O
    X-Status: 
    X-Keywords:
    X-UID: 1871
    
      This message is in MIME format.  The first part should be readable text,
      while the remaining parts are likely unreadable without MIME-aware tools.
      Send mail to mime@docserver.cac.washington.edu for more info.
    
    ---1463811840-1193269629-965150958=:906
    Content-Type: TEXT/PLAIN; charset=US-ASCII
    
    
    teste
    
    
    
    ---1463811840-1193269629-965150958=:906
    Content-Type: IMAGE/GIF; name="right.gif"
    Content-Transfer-Encoding: BASE64
    Content-ID: 
    Content-Description: 
    Content-Disposition: attachment; filename="right.gif"
    
    R0lGODlhFAAWAKEAAP///8z//wAAAAAAACH+TlRoaXMgYXJ0IGlzIGluIHRo
    ZSBwdWJsaWMgZG9tYWluLiBLZXZpbiBIdWdoZXMsIGtldmluaEBlaXQuY29t
    LCBTZXB0ZW1iZXIgMTk5NQAh+QQBAAABACwAAAAAFAAWAAACK4yPqcsd4pqA
    UU1az8V58+h9UtiFomWeSKpqZvXCXvZsdD3duF7zjw/UFQAAOw==
    ---1463811840-1193269629-965150958=:906--
    
    

    Observe a linha que marca o início do arquivo atachado, e que se repete ao seu final. Observe que ela consta também do header do email. Repare que o attachment possui um cabeçalho com informações sobre o arquivo. Finalmente, o arquivo é incluído no corpo do email após a sua conversão para um formato que utiliza apenas caracteres ASC "visíveis". No caso, foi utilizada a conversão BASE64. Uma conclusão importante que se pode tirar dessa descrição é que problemas envolvendo attachments, por exemplo quando o destinatário não consegue extrair os arquivos, são da alçada do software que gerou o attachment e do software que tentou extrair o attachment. Problemas desse tipo não são causados pelos servidores SMTP intermediários, mas sim por falha de algum dos clientes de email (o do remetente ou o do destinatário).

    6.9 Serviços standalone e serviços inetd

    Em plataformas Unix-like existe um servidor especial chamado inetd. Ele é responsável pelo atendimento a múltiplos serviços, mas não pela implementação desses serviços. A implementação precisa estar presente em outros servidores (programas) especializados que são disparados pelo inetd via fork seguido de um exec. De fato, vimos numa nota anterior que o serviço de disparo de um sobprocesso no Unix é o fork. Entretanto, nesse caso o subprocesso é uma cópia do processo original, e roda o mesmo código. Se o subprocesso tiver que rodar um código diferente, obtido a partir de um arquivo executável no filesystem, a chamada do fork, no cado do subprocesso, deve ser seguida da chamada do exec.

    A finalidade do inetd é concentrar o atendimento de muitos serviços num único servidor. Com isso obtém-se alguma economia de recursos, se os serviços forem de baixa demanda. Obtém-se também um mecanismo comum de autorização baseada no endereço ou nomes dos clientes, que é acionado pelo inetd antes do disparo do servidor especializado. O mais conhecido desses mecanismos é o tcp wrapper de Wietse Venema. Serviços que em geral são atendidos pelo inetd são o TELNET, os serviços "r" (RSH, RCP, etc) e POP. Serviços que às vezes são atendidos pelo inetd são o FTP e o SMTP. Os serviços que o inetd atende e a ativação do wrapper para cada um deles estão relacionados no arquivo /etc/inetd.conf.

    Alguns servidores (por exemplo o apache, ao menos nas suas versões mais antigas) oferecem a alternativa do seu atendimento poder ser feito por ele mesmo (nesse caso diz-se que ele é um servidor "standalone") ou via inetd. Do ponto de vista da arquitetura de um servidor ou do atendimento de um serviço, o que se deve ter em vista quando se usa ou não o inetd é que, além do já dito (ou seja, que o inetd concentra vários serviços num único servidor que está associado a um wrapper), é que o fork-exec faz com que múltiplas cópias de um mesmo programa não compartilhem a mesma área de memória para o código, e portanto o consumo total de recursos no caso de serviços de demanda elevada é maior.

    Questões

    6.1 Localize no servidor de ftp da Microsoft a especificação da API Winsock.

    6.2 Escreva usando qualquer linguagem de programação um proxy web minimal.

    6.3 Suponha que a sua empresa utilize um cliente TCP windows (por exemplo o cliente de um sistema administrativo) numa rede privada, e que se pretenda agora utilizá-lo na Internet. Quando esse software foi desenvolvido não se previu mecanismos de criptografação, e você não deseja que as informações trafeguem abertas na Internet. Mostre como se pode fazer com que as chamadas dos serviços da winsock.dll que esse cliente realiza sejam capturadas por uma outra DLL que criptografará as informações enviadas e descriptografará as recebidas, eventualmente sem necessidade de alterar os fontes do cliente e/ou recompilá-lo.

    6.4 Qual é a diferença entre o select da API C do Unix e o select oferecido pelo Winsock?

    6.5 Qual é a diferença entre os espaços de nomes de descritores da API de sockets do Unix e do Winsock 1.1? Que consequências isso tem para quem porta softwares de Unix para Windows?

    6.6 Quantos sockets uma mesma aplicação pode alocar na plataforma em que você trabalha?

    6.7 Suponha que você esteja projetando um computador de bordo para ser colocado nas viaturas de uma frota. Suponha que você opte por utilizar Linux neles. Quais componentes do Linux seriam necessários para que esse computador fosse capaz de conectar num provedor Internet através de um telefone celular e rodar um software de aplicação para enviar e/ou receber informações para/de uma central de controle? (neste caso naturalmente o desejável é minimizar o uso de memória, e portanto encontrar o conjunto mínimo de componentes de software)

    6.8 Você conhece alguma implementação de TCP/IP para Windows versão 3? e para MS-DOS?

    6.9 Descreva como operaria um programa que se baseasse no comando VRFY do SMTP para tentar checar se um dado endereço eletrônico existe, sem tentar enviar um email para ele.

    6.10 Descreva em linhas gerais como deve operar um software que se proponha a copiar para o seu HD todas as páginas de um servidor web da Internet. Descubra algum software na Internet que realize essa operação.

    6.11 Descreva em linhas gerais como deve operar um software que se proponha a submeter um formulário de forma automática, sem necessidade de preenchê-lo manualmente através do browser.

    7. Estudo de caso: RS-232

    A interface RS-232 A camada de enlace (Link Level) Modems

    Notas

    7.1 IP em comunicação serial

    A comunicação serial é um palco especialmente interessante para esmiuçarmos o funcionamento do TCP/IP em virtude da sua simplicidade. Uma boa compreensão de como o IP opera neste caso facilita o entendimento de como uma VPN funciona.

    Em PCs encontramos tipicamente portas seriais RS-232 operando em velocidades como 9600, 19200 ou 115200 bits por segundo. O protocolo RS-232 transfere os bits um a um através do pino TX. Ele apresentará uma tensão de -3 a -15 volts (contra a terra) para codificar um bit 0 e uma tensão de +3 a +15 volts para codificar um bit 1. Quando a porta não está transmitindo, o pino TX permanece no estado lógico 0. A transmissão de um byte começa com a transmissão do start bit (1), em seguida transmitem-se todos os bits do byte e após eles a paridade e o stop bit. O chaveamento entre o final da transmissão de um bit e o início da transmissão do bit seguinte não é sinalizado, mas é sincronizado pelo receptor com base na comum velocidade configurada nas duas pontas.

    O papel do hardware reduz-se ao esquema descrito no parágrafo anterior. Bem, como é que o conceito de pacote IP irá então encaixar-se dentro dessa modalidade de comunição? Naturalmente é necessário estabelecer alguma convenção de sinalização de início e/ou de final de pacote. A primeira dessas convenções a ser criada foi o SLIP (serial line IP).

    O SLIP é bastante simples. Um byte 0xC0 ("END") indica final de pacote. Se um pacote contiver o byte 0xC0 no seu cabeçalho ou na área de dados, então ele é transmitido como o par 0xDB 0xDC. E, se um pacote contiver o byte 0xDB ("ESC"), então ele é transmitido como o par 0xDB 0xDD. Esta codificação é feita pelo kernel do Linux no módulo drivers/net/slip.c. Vejamos o trecho de código C correspondente:

      /* SLIP protocol characters. */
      #define END          0300         /* indicates end of frame       */
      #define ESC          0333         /* indicates byte stuffing      */
      #define ESC_END      0334         /* ESC ESC_END means END 'data' */
      #define ESC_ESC      0335         /* ESC ESC_ESC means ESC 'data' */
    
    caracteres especiais do SLIP (drivers/net/slip.h)

      int
      slip_esc(unsigned char *s, unsigned char *d, int len)
      {
            unsigned char *ptr = d;
            unsigned char c;
    
            /*
             * Send an initial END character to flush out any
             * data that may have accumulated in the receiver
             * due to line noise.
             */
    
            *ptr++ = END;
    
            /*
             * For each byte in the packet, send the appropriate
             * character sequence, according to the SLIP protocol.
             */
    
            while (len-- > 0) {
                    switch(c = *s++) {
                     case END:
                            *ptr++ = ESC;
                            *ptr++ = ESC_END;
                            break;
                     case ESC:
                            *ptr++ = ESC;
                            *ptr++ = ESC_ESC;
                            break;
                     default:
                            *ptr++ = c;
                            break;
                    }
            }
            *ptr++ = END;
            return (ptr - d);
      }
    
    preparação do pacote para transmissão SLIP (drivers/net/slip.c)

    Atualmente o SLIP é preterido em favor do PPP. As vantagens mais visíveis do PPP são o suporte à autenticação e à configuração automática de alguns parâmetros (no SLIP, os endereços IP precisam ser previamente conhecidos pelo cliente), o suporte a múltiplos protocolos (e não apenas ao IP). Em contrapartida, ele provoca um maior consumo de banda de controle do que o SLIP.

    Questões

    7.1 Quais são os tamanhos dos headers IP e TCP num link que trafega SLIP comprimido?

    7.2 Crie um link SLIP entre duas máquinas windows (ou uma windows e uma unix). Descreva a pinagem do cabo que você utilizou, e se foi necessário adicionar algum device driver no windows. Descreva como você criou as rotas em cada uma das máquinas.

    7.3 Vimos que um PC que atenda conexões discadas necessita para cada cliente simultâneo uma linha telefônica, um modem e uma porta serial. Quantas seriais você acha que um PC pode suportar (eventualmente através da adição de algum hardware extra)?

    7.4 Ao longo de uma conexão discada (por exemplo quando de casa você utiliza o seu provedor de acesso) os modems podem renegociar o protocolo de modulação, e eventualmente fazendo cair a velocidade de transferência. Cite um modo simples de se saber durante o uso se ocorre renegociação entre os modems.

    7.5 Na última Copa do Mundo praticamente todas agências de notícias recebiam fotografias tiradas no campo através de câmaras fotográficas digitais, e enviadas imediatamente por meios eletrônicos. Suponha que um repóter fotográfico disponha de uma câmara digital convencional, um notebook e um telefone celular. Quanto tempo depois dele tirar uma fotografia ela poderá estar disponível na redação a fim de ser disponibilizada via web?

    7.6 Algumas plataformas podem utilizar uma porta paralela como dispositivo de roteamento IP. Quantos bytes por segundo podem ser tranferidos por um tal dispositivo?

    7.7 Compare o consumo típico de recursos de comunicação (isto é, tempo de transmissão) da transmissão de um documento por fax, email ou algum serviço de impressão.

    8. TCP/IP e segurança

    Elementos básicos

    Notas

    8.1 Observações gerais sobre segurança em TCP/IP

    A segurança de redes é evidentemente um tema que transcende o TCP/IP, e envolve desde questões relacionados com os princípios físicos, eletromagnéticos ou ópticos de funcionamento da comunicação, até a chamada "engenharia social", que estuda (por exemplo) o comportamento das pessoas em relação à escolha ou ao uso de senhas. Naturalmente não pretendemos aqui abordar todas essas questões, mas apenas fazer algumas observações práticas no tocante à forma com que os temas da segurança e do TCP/IP se entrelaçam. De fato, a análise ou o planejamento de uma política de segurança em redes IP dependem de um conhecimento sólido de TCP/IP.

    Na prática, muitas ou talvez a maior parte dos problemas de segurança que ocorrem na Internet (como invasão de máquinas com destruição ou roubo de informações), é consequência direta da existência de bugs de software que são explorados pelo atacante. Nesse sentido, todo conhecimento que o profissional puder ter a nível de programação será útil para a sua capacitação. Não obstante, a atitude do profissional de Internet frente a bugs de software é fundamentalmente o estar ciente de todos os componentes de software em uso (produtos e respectivas versões), e atento aos eventos inesperados logados pela máquina e aos anúncios de problemas de segurança descobertos nesses componentes, a fim de rapidamente proceder ao upgrade deles. Isso constitui naturalmente um encargo específico da administração de sistemas, e por isso não iremos abordá-lo.

    No que concerne diretamente ao TCP/IP (em todas as suas camadas), pode-se dizer que a segurança gira sempre em torno de dois eixos básicos, que são o isolamento físico e o suporte a criptografação nos protocolos.

    Assim, quando pensamos em utilizar um switch que impeça o broadcast de pacotes ethernet para todas as interfaces da LAN a fim de precaver-nos contra sniffers, estamos isolando. Quando implantamos um firewall para bloquear as portas ou os IPs que não oferecem serviços à Internet, estamos isolando. Quando dividimos a rede privada em duas metades, uma exclusiva para uso interno e outra mista, com máquinas que oferecem serviços para a rede interna e para a Internet, estamos isolando. Quando bloqueamos a entrada de emails com attachments para evitar a entrada de viruses que exploram debilidades de segurança de alguns clientes de correio eletrônico, estamos isolando. Quando dividimos os serviços por várias máquinas a fim de não somarmos as debilidades de segurança de todos eles num único ponto, estamos isolando.

    Por outro lado, quando utilizamos um servidor web seguro no lugar de um não seguro num site de comércio eletrônico, estamos criptografando. Quando substituimos o telnet pelo ssh como protocolo para abrir sessões remotas, ou o ftp pelo ssh, estamos criptografando, assim como quando implantamos uma VPN através de um túnel TCP com criptografação nas duas pontas. A criptografação prescinde do isolamento físico, e opta por tornar inútil a captura da informação.

    São especializações particularmente importantes para a área de segurança a filtragem de pacotes e todas as formas de autenticação. É também pertinente às questões de segurança os protocolos para sincronização de relógios, como o NTP, para o qual existe muitos servidores na Internet. Sem eles, torna-se complicado rastrear eventos ao longo de várias máquinas, pois os logs que elas geram apresentarão timestamps dessincronizados.

    8.2 Filtragem de pacotes

    A filtragem de pacotes consiste em aplicar ao roteamento de pacotes regras de descarte que impeçam a entrada ou a saída de pacotes dirigidos ou provenientes de determinados endereços ou portas. De fato, vimos ao comentar o roteamento IP que este baseia-se na aplicação de regras aos dados de cabeçalho de cada pacote IP. Bem, a filtragem consiste em adicionar regras que ao invés de servirem para escolher a interface de envio de pacote, prestam-se a determinar se um pacote será efetivamente roteado ou meramente descartado. Note que no momento em que o pacote vai ser roteado, ele é um buffer na memória da máquina. Descartar esse pacote significa meramente liberar esse buffer para ser reutilizado.

    A filtragem de pacotes pode ser realizada por um equipamento especializado (um "firewall"), pelo roteador que opera como gateway da rede corporativa com a Internet, ou por alguma máquina intermediária. A filtragem de pacotes frequentemente é feita pela mesma máquina que implementa a tradução de endereços para possibilitar às máquinas da rede interna o acesso aos serviços da Internet. Vejamos um caso prático baseado no Linux.

      # ipfwadm -F -a accept -m -S 192.168.0.0/16
      # ipfwadm -I -P tcp -a acc -S 0.0.0.0/0 -D 192.168.0.1/32 80
      # ipfwadm -I -P tcp -a acc -S 0.0.0.0/0 -D 192.168.0.1/32 53
      # ipfwadm -I -P tcp -a acc -S 0.0.0.0/0 -D 192.168.0.1/32 25
      # ipfwadm -I -P tcp -a rej -S 0.0.0.0/0 -D 192.168.0.0/16 1:1023
    

    Essa sequência de comandos inclui, nesta ordem, cinco regras de filtragem de pacotes. A interface de rede ethernet está configurada com o IP 192.168.0.1. A primeira regra realiza a tradução de endereços (mascaramento, ou "nat") aplicando-a a todos os pacotes provenientes do network 192.168.0.0/16. A segunda faz com que os pacotes dirigidos para a máquina local na porta TCP 80 (HTTP) sejam aceitos. Similarmente, as duas seguintes abrem as portas 53 (DNS) e 25 (SMTP). A quinta faz com que todos os pacotes TCP dirigidos para a rede local em quaisquer portas TCP de 1 a 1023 sejam rejeitados. Assim, a um pacote dirigido à porta 80 será aplicada antes a regra de aceite (a segunda), mas a um pacote dirigido à porta 110, será aplicada a regra de rejeição (a quinta).

    Note que essas regras não bloquearão as portas altas dos clientes (acima de 1024). Isso é necessário para que os clientes da rede interna consigam abrir conexões com servidores da Internet.

    Obs. Em versões recentes do Linux o comando ipfwadm passou a ser chamado ipfwadm-wrapper.

    8.3 Autenticação

    De modo geral, autenticar consiste em provar a identidade. Assim, quando nos identificamos perante um servidor dizendo que somos o usuário fulano, o servidor espera que provemos isso mostrando que conhecemos um segredo que apenas o usuário fulano conhece (uma senha). Essa é a forma mais comum de autenticação, e está presente em vários protocolos TCP, como por exemplo o FTP, o POP e o TELNET:

      $ telnet 192.168.0.2
      Trying 192.168.0.2...
      Connected to 192.168.0.2.
      Escape character is '^]'.
    
      Red Hat Linux release 4.2 (Biltmore)
      Kernel 2.0.36 on an alpha
      login: ueda
      Password: 
      [ueda@alf ueda]$ 
    

    Em muitos casos, a autenticação faz uso de uma base de dados centralizada que possui a tabela de todos os usuários e as suas senhas, ou então "assinaturas" das suas senhas. Neste caso, faz-se necessário existir um protocolo de autenticação que defina a forma da comunicação entre a máquina que está autenticando o usuário e a máquina que contém a base de dados de autenticação. Esses protocolos estão implementados na forma de serviços baseados em TCP/IP: o NIS, que centraliza as informações de login em redes Unix, o RADIUS, utilizado para centralizar informações de autenticação PPP em provedores de acesso e também os serviços de autenticação próprios do compartilhamento de recursos do Windows, que podem operar sobre TCP/IP.

    Uma autenticação bem-sucedida provoca a concessão de privilégios para aquele que autenticou-se. Esse privilégio pode consistir na capacidade de ler uma caixa postal (no caso do protocolo POP), ou de rotear pacotes através do provedor de acesso (no caso do PPP), ou de abrir uma sessão de comandos num computador remoto (no caso do TELNET ou do SSH), ou de fazer upload ou download de arquivos (no caso do FTP).

    Assim, é fácil entender a relação direta da autenticação nas suas diversas formas com a segurança de redes. A obtenção de privilégios pode ser um primero passo para uma ação criminosa, e por isso a autenticação deve estar cercada por muitos cuidados na definição dos protocolos. Ao longo da história do TCP/IP os cuidados dispensados à autenticação nos diversos protocolos nem sempre previram os problemas que no futuro surgiriam (a Internet originalmente era uma rede acadêmica utilizada por pesquisadores, e posteriormente tornou-se uma rede comercial de uso generalizado).

    8.4 Tráfego de senhas in-clear

    Vários protocolos que utilizam o TCP como transporte incluem mecanismos de autenticação que envolvem o envio do cliente para o servidor de um username e de um password. Como sabemos, o cliente envia dados ao servidor escrevendo-os no seu descritor de comunicação (socket), e o layer de TCP/IP do cliente envia esses dados sequencialmente ao servidor na área de dados de um ou mais pacotes.

    No caso de no envio do username e do password não ser realizado nenhum tipo de criptografação (neste caso diz-se que oo envio é feito in-clear), então eles poderão ser capturados em máquinas intermediárias através do uso de sniffers. Ao longo da história do TCP/IP, vários dos protocolos que envolvem autenticação foram criados sem nenhum suporte para a criptografação dos dados de autenticação. Os mais utilizados desses protocolos são o POP3, o FTP e o TELNET. O HTTP também inclui um mecanismo de autenticação com envio de dados in-clear, mas ele é muito pouco utilizado (os sites que autenticam usuários, como por exemplo lojas online, em geral implementam outros mecanismos de autenticação, ao nível da aplicação).

    O uso destes protocolos deve preferencialmente ser limitado a infraestruturas internas, a fim de que dados de autenticação corram um risco menor de serem capturados. Várias alternativas ao TELNET e ao FTP foram sendo criadas nos últimos anos. Aquela que vem aos poucos estabelecendo-se como padrão, principalmente para administração remota de máquinas e sites, é o SSH. Não existe hoje uma alternativa padronizada para o caso de download de emails, entretanto vários sistemas de webmail criptografam os dados enviados e recebidos através do HTTPS.

    Questões

    8.1 O que é autenticação?

    8.2 Localize na Internet um software que rodando na sua máquina seja capaz de capturar o stream TCP de uma conexão (http, smtp, pop, etc) realizada por uma outra máquina da LAN. Explique porque um software como esses é uma ferramenta de trabalho para quem lida com network prrogramming.

    8.3 A pessoa que trabalha na mesa ao lado da sua é capaz de capturar os dados do seu cartão de crédito quando você realiza uma compra num servidor seguro?

    8.4 Por que a distribuição dos diferentes serviços TCP (web, ftp, email) por várias máquinas pode contribuir para tornar uma rede mais segura?

    8.5 Explique de que forma é possível a um wrapper UDP determinar o IP remoto.

    8.6 Suponha que uma empresa multinacional deseje que todos os seus funicionários utilizem endereços eletrônicos com um único domínio (por exemplo: empresa.com), ao invés de domínios em hierarquias diferentes (ou seja, empresa.com, empresa.com.br, empresa.com.tw, etc). Explique o que é preferível ao nível de segurança: permitir que os funcionários ao longo do mundo acessem um servidor POP corporativo único, ou realizar o forward a partir do servidor smtp central dos emails para outros servidores smtp distribuídos pelos vários escritórios mundo afora.

    8.7 O que é um sniffer?

    8.8 Suponha que você seja o responsável na sua empresa pela definição das normas de segurança da rede corporativa. Quais serviços de informação da Internet você exigiria que o pessoal técnico responsável consultasse periodicamente?

    8.9 Baixe da Internet o SSLeay (implementação free do SSL) e escreva uma aplicação com um cliente e um servidor elementares como os que testamos em sala de aula (a própria distribuição do SSLeay traz alguns exemplos).

    8.10 O que é WORM?

    9. UDP

    Os protocolos de transporte IP

    UDP

    Notas

    9.1 O Protocolo UDP

    Em sua vasta maioria, os serviços disponíveis na Internet baseiam-se em TCP, que por incluir o suporte à retransmissão e ordenação dos pacotes recebidos, garante a entrega da sequência de bytes enviada por cada uma das partes, sem lacunas e na mesma ordem. O TCP é por esse motivo dito reliable.

    Em muitas situações práticas, entretanto, essa propriedade (a de ser reliable) pode ser desnecessária ou mesmo indesejada. O exemplo mais comum de tais situações é o broadcast de áudio ou de vídeo. Numa transmissão de rádio ou de TV, a retransmissão de pacotes provocaria atrasos cumulativos indesejados, pois a simultaneidade (por exemplo no caso de eventos esportivos) é mais importante do que a apresentação escrupulosa de todos e cada um dos quadros.

    No TCP/IP os serviços que não necessitam ser reliable utilizam UDP. O UDP também baseia-se no roteamento oferecido pelo IP, ou seja, o pacote IP pode carregar tanto um pacote TCP quanto um pacote UDP (também chamado datagrama). Observe que no cabeçalho IP há um campo indicando o protocolo subjacente, o código do TCP é 6 e o do UDP é 17.

    source port (16)
    destination port (16)
    length (16)
    checksum (16)

    O cabeçalho UDP

    De forma semelhante ao TCP, o UDP também inclui o conceito de porta. Cada serviço UDP está associado a uma porta fixa, e o cliente ao enviar pacotes para aquela porta necessita alocar uma porta UDP local. Não obstante, o UDP dispensa o conceito de conexão, havendo apenas envios independentes (cada um correspondente a uma mensagem de no máximo 65535 bytes) de uma origem UDP (IP e porta) para um destino UDP.

    Obs. Se o tamanho da mensagem UDP (acrescido dos cabeçalhos UDP e IP) superar o tamanho máximo de pacotes (MTU) suportado pela interface, esse pacote será fragmentado. O conceito de fragmentação não está sendo coberto nestas notas, ele é um feature ao nível do IP, e não deve ser confundido com a divisão feita pelo TCP de um stream de bytes numa sequência de segmentos. A fragmentação do IP consiste em quebrar em várias partes um pacote cujo tamanho supera o MTU da interface de envio. Ela pode ocorrer em qualquer pacote IP suficientemente grande, seja ele UDP ou TCP.

    O comando netstat pode exibir os descritores UDP locais:

      $ netstat -n -u -a
      Active Internet connections (servers and established)
      Proto Recv-Q Send-Q Local Address    Foreign Address   State
      udp        0      0 192.168.0.1:53   0.0.0.0:*
      udp        0      0 127.0.0.1:53     0.0.0.0:*
      udp        0      0 0.0.0.0:37       0.0.0.0:*
    

    No caso vemos as portas 37 (serviço time) e 53 (DNS). A mensagem "Active Internet Connections" faz parte da saída default do netstat, que também pode exibir conexões TCP. Nesse nosso exemplo não se tratam de conexões, mas apenas das portas locais aptas para recebimento de pacotes UDP.

    9.2 UDP e multicast

    O UDP é também utilizado para implementar serviços "multicast". O TCP pressupõe apenas dois participantes. No caso de uma transmissão com uma origem e muitos destinos, um mecanismo de transporte do tipo um-para-muitos é necessário. O TCP/IP prevê o conceito de roteamento um-para-muitos, mas os recursos que ele oferece para isso não chegaram a ser um padrão efetivamente usado na Internet. Em contrapartida, é possivel implantar serviços do tipo um-para-muitos ao nível da aplicação, e em casos assim utiliza-se UDP.

    Neste caso, a aplicação que origina a mensagem envia-a para o nó seguinte, este (onde a mesma aplicação está rodando) explode-a para outros, estes outros para mais outros, e assim por diante, a fim de que todos os destinatários sejam atingidos. Note que o roteamento nesse caso só pode ser feito em infraestruturas privadas, por não se tratar do roteamento IP standard, mas depender da existência de uma aplicação específica rodando em cada um dos nós intermediários.

    O multicast pode ser comparado ao SMTP. Uma única transação SMTP pode transferir um email uma única vez do seu remetente para o servidor SMTP imediato, mas especificando múltiplos destinatários. Esse servidor que a recebe por sua vez explode-a em vários "envelopes", cada um contendo os todos destinatários de um mesmo domínio, e realiza uma nova transação de envio para cada envelope, destinada ao MX do domínio em questão. Cada envelope por sua vez, ao ser recebido no SMTP definitivo, faz com que a mensagem seja explodido por todas as caixas postais nele especificadas.

    Questões

    9.1 Por que se diz que TCP é "reliable" e UDP é "best-effort"?

    9.2 Use o tcpdump e o netstat para saber se um serviço de broadcast da Internet que você conhece (estação de rádio, TV, pointcast, etc) utiliza UDP ou TCP.

    9.3 Crie um protocolo UDP ou TCP minimal para sincronização de relógios (isto é, o cliente obtém do servidor o horário atual e acerta o seu relógio a partir desse dado obtido), e implemente o cliente e o servidor usando a plataforma e a linguagem de programação de sua preferência.

    9.4 O que é multicast? multicast sobre IP é "reliable"?

    9.5 Estime a banda do link de um cliente de um sistema de broadcast de informações de mercado, que atualize uma tela de 80 linhas e 24 colunas com uma tabela de cotações à razão de uma atualização a cada segundo.

    10. Redes privadas

    TCP/IP numa rede privada

    Conexão de uma rede privada à Internet Proxy servers VPN

    Notas

    10.1 Internet, internets, intranets e extranets

    O termo "internet", ao mesmo tempo que denota a rede mundial que estamos acostumados a utilizar para enviar emails, acessar o Altavista, comprar livros, etc, é também um termo genérico que significa "rede de redes IP". Se montarmos por exemplo três pequenas LANs corporativas, cada uma utilizando IP, e as interligarmos com linhas telefônicas, teremos criado uma rede de redes IP (ainda que minúscula), que pode ser chamada de "internet". Douglas Comer costuma utilizar o termo "Internet" (com "I" maiúsculo) para denotar a rede mundial, e o termo "internet" (com "i" minúsculo) para denotar genericamente uma rede de redes IP. Essa convenção entretanto não é necessariamente seguida por todas as pessoas.

    O termo "intranet" denota uma rede IP, eventualmente com os mesmos serviços oferecidos pela "Internet" (SMTP, HTTP, etc), mas para fins internos (por exemplo correio eletrônico interno de uma empresa, sistema de informações interno, etc). Note que do ponto de vista de TCP/IP, o termo "intranet" não acrescenta nada, visto que ele quer qualificar apenas o conteúdo da comunicação, e não os mecanismos utilizados por ela.

    O termo "extranet" por sua vez denota uma "intranet" oferecida para um público externo à corporação, mas restrito. Seria o caso por exemplo onde uma empresa abre o acessa à sua intranet ou a parte dela para uma outra empresa. Assim como o termo "intranet", o termo "extranet" também não acrescenta nada ao TCP/IP entendido tecnicamente.

    10.2 Redes Privadas

    A situação típica para uma empresa ou organização que se conecte à Internet é a de possuir uma rede privada (que chamaremos de "rede interna") oferecendo serviços internos (um servidor de disco, um servidor de base de dados, etc) e um link com a Internet para que a partir da rede interna seja possível utilizar serviços da Internet (envio de emails, acesso a páginas web, etc). Essa empresa ou organização poderá também oferecer serviços para a Internet, como por exemplo um servidor de nomes respondendo pelos nomes da empresa ou organização (algo como www.empresa.com), um servidor SMTP operando como o MX para os domínios da empresa ou organização e um servidor web.

    Esse tipo de situação cria uma certa quantidade de problemas típicos que o profissional que trabalha com Internet deve conhecer. Os mais comuns são:

    10.3 Endereços reservados para redes Privadas

    A exaustão do espaço de endereçamento IP da Internet tornou conveniente a reserva de alguns endereços para uso em redes privadas. Esses endereços são:

            10.0.0.0        -   10.255.255.255
            172.16.0.0      -   172.31.255.255
            192.168.0.0     -   192.168.255.255
    

    Como são eles utilizados na prática? suponha que uma empresa implante uma rede IP para uso interno. Se essa rede estiver totalmente isolada da Internet, então em princípio ela pode utilizar quaisquer endereços IPv4 para configurar as interfaces. Em geral entretanto as redes privadas não estão totalmente isoladas da Internet, e dispõe no mínimo de uma conexão discada, e nesse caso não poderemos utilizar IPs já outorgados para outros.

    Como é difícil ou talvez impossível obter para essa rede endereços IP "oficiais" (roteáveis), pode-se optar pelo uso desses networks reservados para redes privadas, pois garante-se que esses endereços não estão em uso na Internet. Ou seja, não existe na Internet nenhum servidor web configurado com IP 172.16.14 e nenhum servidor SMTP com endereço 10.5.6.7.

    Assim, é importante nesses casos utilizar esses endereços reservados. Para dar um exemplo, uma rede privada pequena poderia utilizar o endereço de rede 192.168.1.0 com máscara 255.255.255.0. O administrador irá então configurar as interfaces das máquinas com IPs da forma 192.168.1.X. Essas máquinas poderão estar fisicamente conectadas à Internet, mas não poderão ser atingidas por pacotes originados na Internet. De fato, os roteadores da Internet não saberão encontrar endereços que não foram oficialmente outorgados a ninguém, e que inclusive podem estar sendo utilizados simultâneamente em muitas redes privadas diferentes ao longo do mundo.

    Se entretanto a rede possuir ao menos um IP "oficial", as máquinas configuradas com IPs de rede interna poderão acessar a Internet como clientes através do mecanismo de mascaramento (nat) indicando essa máquina que possui o IP oficial como gateway.

    10.4 NAT - Network Address Translation (mascaramento)

    Como vimos anteriormente, uma máquina IP cujas interfaces estejam configuradas com endereços reservados para redes privadas não pode participar da Internet porque não existirão as rotas de retorno. O mascaramento soluciona parcialmente este problema, desde que exista ao menos uma interface (dentre todas as máquinas da rede privada, que chamaremos de "rede interna") um IP "oficial" (isto é, roteável).

    O mascaramento consiste em utilizar a máquina com o IP oficial como gateway para a Internet, configurando-a para substituir o endereço do remetente no cabeçalho IP de cada pacote por ela repassado para a Internet pelo seu próprio endereço oficial. Dessa maneira, os pacotes gerados pelo servidor acessado poderão ser regularmente roteados de volta até atingir o gateway. Quando isso acontece, o gateway destroca o endereço de destino desses pacotes (que neste momento é o seu próprio) colocando no seu lugar o endereço do remetente original. Assim, do ponto de vista do servidor externo, o acesso foi gerado pelo gateway e não pelo cliente com o IP de rede interna.

    Ao receber um pacote da Internet, como procede o gateway para determinar se esse pacote é dirigido para ele mesmo ou se deve ser re-roteado? Isso é feito através da alocação, no gateway, de uma porta exclusiva para cada conexão TCP gerada por um cliente da rede interna. Uma tabela é mantida associando essa porta única com o IP e a porta de origem da conexão. Assim, os pacotes gerados pelo cliente ao passarem pelo gateway terão tanto o IP de origem quanto a porta de origem trocados. No momento em que a conexão é encerrada aquela porta alocada no gateway fica livre para ser reutilizada. Para evitar um esgotamento das portas no gateway, implementa-se também a liberação das portas de conexões que tenham permanecido sem atividade por um certo tempo (por exemplo dez minutos).

    O mascaramento tem várias limitações. Uma delas é que o cliente da rede interna nunca pode ser a parte passiva da conexão (isto é, aquela que mantém a porta em listen) porque o seu IP não é roteável (isso até certo ponto pode ser considerado bom do ponto de vista de segurança). Essa deficiência pode eventualmente ser contornada pelo uso de mapeadores de portas. Uma outra limitação é que alguns protocolos não operam corretamente com o mascaramento, ou só operam corretamente se o gateway mascarador tiver um suporte específico para esses protocolos. Um desses protocolos é o FTP. O FTP utiliza duas conexões TCP, uma para comandos e outra para dados. A conexão de comandos é estabelecida primeiro. É através dela que usamos os comandos PROMPT, ASC, etc. Por vezes conseguimos conectar um servidor ftp e executar comandos como ASC mas não comandos como DIR ou GET. Esse sintoma via de regra indica a existência de um gateway mascarador onde o suporte para FTP não existe ou não está ativado.

    10.5 Proxies e HTTP

    Um Proxy é alguém (um computador) que se faz passar por um outro (computador). O modo mais simples de se entender isso é no contexto de circuito virtual, que no caso do TCP/IP são circuitos ou canais ou conexões TCP.

    Um canal TCP tem sempre exatamente duas extremidades, uma ativa, que tomou a iniciativa (chamada cliente) e a outra passiva, que aguardava a solicitação do cliente (o servidor).

    Há situações onde o cliente não pode ou não deseja identificar-se como tal. Isso ocorre quando ele está numa rede protegida por um firewall, ou quando ele não possui um endereço IP "oficial" da Internet.

    Pois bem, num caso como esse, o cliente solicita a uma outra máquina que se faça passar por cliente. Essa outra máquina fará portanto o papel de intermediário. Ela abrirá o canal TCP com o servidor, mas redirecionará todo o tráfego proveniente do servidor para o cliente oculto, e todo tráfego proveniente do cliente oculto será redirecionado para o servidor.

    O recurso de poder usar um proxy em geral necessita estar previsto no cliente. Por exemplo, os browsers web costumam ter na sua configuração o servidor proxy como um ítem (no Netscape veja o menu Options/Network Preferences/Proxies).

    Apesar de serem noções bastante diferentes, é difícil entender porque usar um Proxy é diferente de mascarar IP, pois a funcionalidade de ambos é semelhante. Para se compreender a distinção, é necessário ter uma boa noção de como é a implementação do TCP/IP numa máquina, e os vários papéis que tipicamente são desempenhados pelo "layer" TCP/IP e pelas aplicações.

    No contexto de circuitos virtuais, no caso do proxy existem efetivamente dois canais TCP, um entre cliente e proxy, e outro entre proxy e servidor. No caso do mascaramento de IP, só há um canal TCP, e o gateway mascarador simplesmente troca nos frames os os endereços e as portas do remetente ou do destinatário, dependendo do caso, a fim de que o servidor pense que o cliente é o gateway.

    Isso significa, por exemplo, que no caso do mascaramento, o gateway comporta-se apenas como um roteador de pacotes, enquanto no caso do proxy ele remonta (no caso de TCP) o stream que o cliente envia antes de retransmiti-lo ao servidor, e vice-versa, tendo portanto um overhead maior.

    Proxies são comumente utilizados para HTTP e, neste caso, além de operar como intermediário, o proxy também pode cachear as páginas web obtidas no seu winchester. Dessa forma, uma segunda requisição de uma mesma página não irá baixá-la novamente do servidor remoto, mas irá recuperá-la do winchester. Alguns proxies adicionam recursos muitos úteis, como por exemplo a possibilidade de se realizar buscas nas páginas cacheadas.

    10.6 VPNs

    O entendimento da operação do TCP/IP em comunicação serial e do conceito de canal virtual torna imediato o entendimento da noção de VPN, ou ao menos de uma das suas modalidades.

    Vimos nas notas sobre comunicação serial que para se fazer com que duas máquinas se comunicassem via IP bastou existir um mecanismo que transportasse bytes de uma para outra. Sobre esse mecanismo podemos implementar um software que realize o envio ou o recebimento de pacotes através do SLIP ou do PPP. Bem, um canal TCP é um mecanismo de envio de bytes entre dois computadores. Assim, um canal TCP que atravesse parte da Internet pode ser utilizado para encapsular SLIP ou PPP (por exemplo).

    Nesse caso, os pacotes referentes ao canal TCP utilizado para o encapsulamento (e que chamaremos de túnel) transportam na sua área de dados a mesma sequência de bytes que seria trocada num link SLIP ou PPP, e que no caso incluirá os cabeçalhos dos pacotes encapsulados. Assim, será gerado um overhead de comunicação pois teremos cabeçalhos duplicados.

    Por outro lado, o encapsulamento cria algumas vantagens. Uma primeira vantagem é que as aplicações que criam o túnel podem incluir filtros que criptografem e/ou comprimam os dados que estão sendo enviados por ele. Se repararmos nos exemplos dados de servidor e cliente TCP minimais, veremos que não há dificuldade nisso, pois basta anteceder a chamada dos serviços de envio ou de recebimento com a desses filtros. Dessa maneira podemos adicionar criptografação ao nível do IP atingindo dessa forma todos os serviços de rede utilizados, mesmo aqueles que originalmente não previam suporte para criptografação.

    Uma segunda vantagem é que o roteamento do tráfego encapsulado independe do roteamento da Internet (estamos supondo que o túnel utiliza a Internet), visto que o roteamento da Internet atua sobre os cabeçalhos dos pacotes da conexão TCP usada como túnel, e não sobre os cabeçalhos encapsulados. Estes são manipulados apenas pelas aplicações que lêem e escrevem nas duas pontas do túnel. Essas aplicações criam interfaces virtuais nas máquinas em que estão operando, associam a elas IPs, adicionam rotas nessas máquinas apontando para essas interfaces virtuais, e passam a operar como gateways nas extremidades do túnel. Dessa forma, é possível criar uma rede IP privada com uma estrutura de roteamento independente da Internet, mas utilizando a Internet como carrier, o que é vantajoso em termos de custo operacional.

    Questões

    10.1 Explique porque não é posível acessar da Internet um servidor web de uma rede interna que usa IPs do network 10.0.0.0 e conecta-se à Internet através de um gateway mascarador.

    10.2 Descreva em linhas gerais como você atribuiria os números IP e configuraria as rotas dos gateways de uma WAN interligando uma matriz com duas filiais através de LPCDs.

    10.3 Descreva em linhas gerais como você implantaria uma BBS oferecendo um serviço de correio eletrônico a uma cidade pequena, sem dispor de uma conexão dedicada com a Internet (os seus clientes terão que poder enviar emails para a Internet e receber emails da Internet).

    10.4 Explique como utilizar DNS dinâmico para implantar uma VPN interligando duas LANs através da Internet usando acesso discado (DNS dinâmico é um serviço para mapeamento dinâmico de um nome num IP, ele é dinâmico no sentido em que o mapeamento pode mudar rapidamente, sem depender da expiração típica de 24 horas dos caches DNS, na Internet há quem ofereça gratuitamente o serviço de DNS dinâmico, como o www.justlinux.com, e outros que vendem o serviço).

    10.5 Qual é o RFC que define os networks reservados para redes privadas? Termos vulgarmente utilizados como "IP falso" ou "IP inválido" são referidos por esse RFC?

    10.6 Estime por alto a ordem de grandeza dos links de uma WAN para produção gráfica, que precise trafegar imagens em alta resolução dos setores de produção (estúdios fotográficos ou artísticos) até os setores industriais (sugestão: o tamanho em bytes de uma fotografia é função da resolução e do número de cores. Quando se trabalha com 16 milhões de cores, por exemplo, cada pixel consome três bytes, portanto uma imagem de 2000x2000 pixels consumiria 12.000.000 de bytes sem compressão).

    11. Estudo de caso: ethernet

    Ethernet

    Notas

    11.1 IP implementado em ethernet: ARP

    Cada placa de rede ethernet existente no mundo possui um endereço de hardware único de 48 bits. Esse endereço costuma-se escrevê-lo na forma de 6 octetos separados por ":", como por exemplo E9:17:02:07:45:B4. Note que os octetos são representados na base 16, e não na base 10, como no caso do IP. No Linux, pode-se exibir esse endereço através do comando ifconfig (no Windows 9x utilize o winipcfg).

      $ ifconfig eth0
      eth0  Link encap:Ethernet HWaddr 00:80:48:EB:06:CD
            inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
            UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:100
            Interrupt:11 Base address:0xff80
    

    Os participantes de uma LAN ethernet comunicam-se utilizando esses endereços de hardware. Os pacotes que um PC envia a um outro para por exemplo, realizar uma impressão remota, são encabeçados por um header ethernet onde consta o endereço de hardware do destinatário (neste caso, a máquina onde a impressora está fisicamente conectada).

    Dessa forma, a própria placa de rede ethernet é capaz de filtrar, dentre todos os pacotes que circulam no meio físico (cabo), aqueles a ela destinados. Estes ela repassa ao sistema operacional para serem processados, os demais são descartados.

    Isso cria um problema inicial na comunicação interna numa LAN, pois a identificação que temos do computador do qual desejamos utilizar algum serviço (e.g. impressão) será seu nome ou o seu número IP. Dessa maneira, da mesma forma que existe um serviço para resolver nomes para IPs (o DNS), é necessário haver, apenas a nível local, um mecanismo que resolva IPs para endereços de hardware. Esse mecanismo é o ARP (address Resolution Protocol). O tcpdump permite-nos monitorar o ARP em operação:

      # tcpdump arp
      tcpdump: listening on eth0
      13:12:43.676371 arp who-has 192.168.0.2 tell 192.168.0.1
      13:12:43.677065 arp reply 192.168.0.2 is-at 8:0:2b:e2:c4:ed
    

    As linhas contendo arp who-has são queries ARP. Por exemplo, a máquina 192.168.0.1 quer saber qual é o endereço de hardware associado ao IP 192.168.0.2. Ela faz, então, um broadcast no ethernet perguntando qual é esse endereço de hardware. Esse broadcast foi capturado e apresentado pelo tcpdump na linha arp who-has. Ele corresponde a um pacote ethernet que no campo de endereço (de hardware) de destino especifica um valor especial que faz com que todas as placas de rede repassem o pacote ao sistema operacional. Bem, aquela única máquina cuja interface possuir o endereço 192.168.0.2 irá, ao processar o query ARP, gerar um pacote de resposta informando o seu endereço de hardware, que no caso é a linha is-at como vemos acima.

    Obs. (1) A opção -e do tcpdump incluirá em cada descrição de pacote os endereços de hardware envolvidos.

    Obs. (2) Um computador pode ser programado para responder requests ARP referentes a endereços IP que não estão mapeados nas suas interfaces. Essa técnica chama-se proxy-arp e é utilizada como um artifício simples para criar gateways para máquinas que se conectam numa LAN ethernet (vamos supor: um notebook) através da porta serial de algum dos participantes. Nesse caso, esse notebook receberia um endereço IP com o mesmo network number dos endereços utilizados na LAN. Assim, quando alguém na LAN quiser enviar pacotes para o notebook, fará um broadcast ARP mas o notebook não o poderá responder, visto que o broadcast não o atinge. O gateway no entanto responde o request ARP na qualidade de proxy, recebe o pacote na sua interface ethernet, aplica a tabela de rotas e realiza o forward do pacote para a porta serial, encaminhando-o dessa forma para o notebook.

    Questões

    11.1 Explique como usar proxy-arp para incluir um filtro de pacotes numa rede IP pré-existente com um único gateway para a Internet cuja porta ethernet está diretamente plugada ao único hub da LAN, sem alterar a configuração TCP-IP nem das máquinas da LAN e nem do gateway.

    11.2 Suponha que uma auditoria técnica concluiu que você é responsável por um ataque realizado contra o servidor da Intranet da empresa, em virtude de terem sido encontrados nos logs do servidor registros de tentativas de invasão indicando como origem o número IP do computador que fica na sua mesa, e que somente você utiliza. Baseado no funcionamento do ARP, explique como você argumentaria, em sua defesa, que os registros encontrados nos logs não são prova conclusiva de que você foi o autor do ataque.

    11.3 É possível criar uma rede doméstica para testes, composta por apenas duas máquinas com interfaces TP sem utilizar um hub? Qual é a diferença entre o cabo que você utilizaria nesse caso e um cabo normal para conectar uma máquina ao hub?

    11.4 O que é CSMA?

    12. Noções sobre roteadores

    Finalidades do roteador

    13. Multidomínio

    Modos de se determinar o domínio de destino Modo com que o multidomínio opera em cada protocolo Hospedagem e alocação de IPs

    Notas

    13.1 Multidomínio

    Um mesmo computador pode hospedar vários domínios diferentes. Isso é fundamental para a economia de recursos na Internet. Vários sites pequenos (muitas dezenas) podem estar hospedados numa única máquina. Isso significa que essa máquina irá responsabilizar-se pelo serviço de nomes desses domínios e/ou pelo recebimento de emails das caixas postais desses domínios e/ou pela hospedagem das caixas postais desses domínios (que serão disponibilizadas via POP) e/ou pela hospedagem de páginas web ou de arquivos disponibilizados por ftp por esses domínios.

    A possibilidade técnica de se poder compartilhar um mesmo hardware por vários domínios depende de uma previsão ao nível dos protocolos de aplicação. Basicamente, o protocolo de aplicação deve definir que a solicitação de um determinado serviço deva vir acompanhada de uma identificação do domínio no qual o cliente está interessado.

    Assim, vemos por exemplo que o SMTP possui essa previsão. De fato, na transação SMTP o cliente informa o endereço eletrônico completo do destinatário (e.g. ueda@ime.usp.br). Assim, se utilizarmos um mesmo computador para o recebimento de emails de mais de um domínio diferente, bastará que o programador tenha feito o software (o servidor SMTP) de forma a organizar as caixas postais no disco da máquina dividindo-as por domínio, a fim de não confundir a caixa postal de usuários homônimos de domínios diferentes.

    Semelhantemente, o DNS também possui essa previsão, visto que o query DNS carrega o nome relativamente ao qual estamos interessados, e portanto um mesmo computador pode ser o servidor de nomes de muitos domínios diferentes.

    Atualmente o HTTP possui suporte para multidomínio. Nos exemplos simples que inicamos nestas notas esse suporte não está evidente, mas de fato o query HTTP pode incluir uma linha Host que informa qual é o domínio no qual o cliente está interessado. Podemos visualizar isso através da captura de um query HTTP gerado pelo Netscape. No caso, estamos utilizando-o para visitar o URL http://www.linuxdoc.org. O query gerado segue (as linhas que terminam com ... foram truncadas).

    GET / HTTP/1.0
    If-Modified-Since: Tue, 18 Jul 2000 15:39:42 GMT; length=19222
    Connection: Keep-Alive
    User-Agent: Mozilla/4.51 [en] (X11; I; Linux 2.2.5-22 i586; Nav)
    Host: www.linuxdoc.org
    Accept: image/gif, image/x-xbitmap, image/jpeg, ...
    Accept-Encoding: gzip
    Accept-Language: en
    Accept-Charset: iso-8859-1,*,utf-8
    
    

    Obs. O query HTTP termina com uma linha em branco. É por isso que numa das primeiras notas deste documento indicamos que após o comando GET é necessário pressionar ENTER duas vezes, dessa maneira o servidor remoto toma conhecimento de que o query é composto unicamente pela linha GET.

    É importante perceber que em todos os casos discutidos estamos compartilhando um mesmo endereço IP para múltiplos domínios. Assim, se por exemplo as páginas dos domínios a.com e b.com estiverem hospedados num mesmo servidor HTTP, então os nomes www.a.com e www.b.com estarão associados pelo DNS a registros A que apontarão para um mesmo IP. Isso significa entre outras coisas que o acesso às páginas web desses domínios nunca poderá ser feito via endereço numérico (algo como http://1.2.3.4). Significa também que a hospedagem de um domínio na Internet não exige como prerequisito a alocação de um IP exclusivo para aquele domínio.

    Por outro lado, dois protocolos largamente utilizados na Internet mas que não possuem suporte para multidomínio são o POP e o FTP. No caso do POP, pode-se contornar o problema fazendo com que na configuração do cliente de email (Eudora, Outlook, etc) conste o domínio da caixa postal, que deverá então ser configurada como (por exemplo) ueda@ime.usp.br e não apenas ueda. Isso fará com que na transação POP o cliente envie ao servidor através do comando USER a informação suficiente para ele identificar a caixa postal. No caso do FTP, o problema pode ser parcialmente solucionado oferecendo a cada hóspede um diretório, que deverá constar de qualquer URL de ftp daquele hóspede.

    Em qualquer caso no entanto é possível também resolver o problema do compartilhamento de uma mesma máquina por vários domínios associando a cada um um endereço IP exclusivo. Essa técnica chama-se IP aliasing e depende de suporte específico no sistema operacional.

    13.2 IP Aliasing

    O mapeamento de mais de um endereço IP numa mesma interface física chama-se IP aliasing. No Linux o modo de fazê-lo resume-se a configurar uma nova interface virtual para cada novo endereço adicionado. Se tivermos por exemplo uma interface eth0 já configurada com o endereço 192.168.0.1 e quisermos mapear nela também o endereço 192.168.0.3, então configuraremos a interface eth0:0 usando o ifconfig:

      # ifconfig eth0:0 192.168.0.3
      # ifconfig
      eth0    Link encap:Ethernet  HWaddr 00:80:48:EB:06:CD
              inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:91 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              Interrupt:11 Base address:0xff80
    
      eth0:0  Link encap:Ethernet  HWaddr 00:80:48:EB:06:CD
              inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              Interrupt:11 Base address:0xff80
    

    Observe que o endereço de hardware da interface eth0:0 é exatamente o mesmo da interface eth0 (visto serem fisicamente a mesma placa de rede). Isso significa, entre outras coisas, que requests ARP aos IPs 192.168.0.1 e 192.168.0.3 serão respondidos com o mesmo endereço de hardware.

    O mecanismo de IP aliasing é largamente utilizado em servidores compartilhados por múltiplos domínios. Quando se contrata a hospedagem de um domínio e nessa hospedagem há a concessão de um endereço IP exclusivo para aquele domínio, esse endereço terá que estar mapeado numa interface física, e como uma mesma máquina e uma mesma interface são compartilhados por (eventualmente) dezenas de domínios, todos os endereços estarão mapeados numa mesma interface física.

    Um software com suporte para IP aliasing deve testar para cada conexão o IP de destino que o cliente indicou, e em seguida assumir a identidade própria associada a esse IP. Essa operação é muito frequentemente realizada por servidores web como o Apache. O código que segue implementa essa operação:

    /*
    
    Código para detecção da IP de destino que o cliente está
    conectando.
    
    Este programa foi desenvolvido a partir da análise do fonte do
    NCSA httpd.
    
    */
    
    #include <netinet/in.h>
    #include <stdio.h>
    
    main(argc,argv)
    int argc;
    char *argv[];
    {
        struct sockaddr_in serv_addr;
    
        int rc;
        long my_addr;
        int serv_addr_len;
        unsigned char dot1,dot2,dot3,dot4;
    
        serv_addr_len = sizeof(serv_addr);
        rc = getsockname(0,(struct sockaddr *)&serv_addr,&serv_addr_len);
        if (rc == 0) {
            my_addr = ntohl(serv_addr.sin_addr.s_addr);
            dot4 = my_addr & 0x000000ff;
            dot3 = (my_addr >> 8) & 0x0000ff;
            dot2 = (my_addr >> 16) & 0x00ff;
            dot1 = my_addr >> 24;
            printf("%u.%u.%u.%u",dot1,dot2,dot3,dot4);
        }
        else {
            printf("unknown\n");
        }
    }
    

    Questões

    13.1 Explique como um servidor web multidomínio faz para determinar a qual domínio virtual refere-se uma dada conexão. Cite os serviços de API (sockets) utilizados pelo servidor nesse caso.

    13.2 Em que condições um mesmo computador pode hospedar os sites web de diferentes domínios virtuais associando a todos os nomes um registro A apontando para um único IP?

    13.3 Visite as páginas de algum grande hospedeiro de sites na Internet e conclua quantos domínios por máquina ele hospeda.

    13.4 Por que está errado, no sentido estrito, pensar que hospedar um domínio significa conceder um IP? Explique o erro dessa idéia ao nível do DNS e SMTP pelo menos.

    13.5 Quantas conexões TCP você acha que um grande servidor consegue manter abertas simultâneamente?

    13.6 Quantos hits por segundo você acha que um servidor http consegue atender?

    13.7 Se na sua empresa existir um servidor web interno, realize um teste para levantar quantas vezes por segundo ele consegue atender o pedido de leitura de uma página estática pequena. Para realizar esse teste você pode fazer um pequeno programa com um loop que a cada iteração realize um pedido ou utilizar algum programa pronto, como o ftp://ftp.lysator.liu.se/pub/unix/ptester.

    13.8 Suponha que você venda hospedagem de sites com o compartilhamento de IPs. Nesse caso como teriam que ser os URLs de FTP dos arquivos disponibilizados para download pelos clientes?

    14. Notas breves sobre hardware

    Notas

    14.1 Hardwares e SO's de uso comum na Internet

    Em virtude dos protocolos de uso mais comum na Internet serem standard, e contarem com múltiplas implementações independentes, qualquer hardware para o qual exista uma implementação de TCP/IP e dos serviços que se pretenda oferecer é, em princípio, apto para operar como um servidor na Internet. E, de fato, pode-se encontrar na Internet servidores baseados nos mais variados hardwares, sistemas operacionais e softwares de aplicação, realizando mais ou menos as mesmas tarefas: PCs comuns das mais variadas procedências, servidores especializados baseados em Intel, máquinas RISC, computadores de bolso, mainframes, etc.

    Em algumas situações, características muito específicas de uma plataforma ou outra podem ter um papel decisivo num processo de escolha, não obstante isso é pouco comum, ao menos no que tange aos critérios estritamente técnicos. Tais características poderiam ser por exemplo: disponibilidade de um determinado barramento na plataforma (ISA, PCI, MCA, VME, etc), capacidade máxima ou tipo de memória suportada, possibilidade ou facilidade de se adicionar grande quantidade de discos, alta capacidade de processamento (isso em geral implicará no uso de máquinas com várias CPUs), alta tolerância a falhas (isso pode eventualmente tornar conveniente o uso de clusters com várias máquinas redundantes, ou seja, a falha de uma não acarreta descontinuidade do serviço), suporte a algum determinado software do mercado, etc.

    Ainda dentro dessa linha, algo a que deve ser dar atenção mas que em geral acaba não sendo objeto de suficiente cuidado, são as condições de refrigeração das máquinas e do ambiente, e a sinalização do esgotamento das baterias que os no-breaks devem enviar aos computadores, a fim de que eles realizem os procedimentos de shutdown e evitem dessa forma danos nas mídias. Em algumas instalações, a possibilidade de assaltos, incêndios ou de inundações, e a facilidade do transporte das máquinas em geral ou em situações de contingência pode ser também um fator relevante.

    Não obstante, os critérios puramente técnicos serão em geral insuficientes para se decidir por um ou outro padrão de hardware ou de sistema operacional a ser utilizado num servidor Internet. Na prática, o responsável terá que eleger alguns outros critérios e basear neles a sua escolha. Entre esses critérios, o mais objetivo em geral será a experiência anterior dos profissionais envolvidos, que em geral já possuirão uma capacitação para trabalhar com determinadas linhas de produtos de hardware ou de software, tanto ao nível da configuração e manutenção das máquinas, quanto ao nível dos procedimentos de aquisição ou mesmo de importação, conhecimento das revendas e dos serviços de suporte disponíveis, contatos com outros profissionais da área, experiência no desenvolvimento de softwares, etc. Um segundo critério, que em muitos casos poderá preponderar em relação ao anterior, é o impacto que a escolha terá ou poderá ter nas vendas e/ou os acordos comerciais que a escolha terá que acatar. Um terceiro critério que dependendo do caso poderá ser mais importante ou menos importante, é o custo dos equipamentos e dos softwares.

    Na falta de informações ou de projeções, as estatísticas de uso e de vendas de cada linha de hardware ou de sistema operacional poderão ser úteis, principalmente se se referirem ao nicho visado, mas em geral devem ser analisadas com bastante cuidado. Tecnicamente, qualquer hardware ou sistema operacional que esteja vivo no mercado, ainda que o seu market share seja pequeno, será sempre um candidato viável. Além disso, a história da Informática ou da tecnologia em geral está cheia de malogros e sucessos inesperados.

    O profissional deve ainda estar atento ao jogo do mercado, a fim de não se deixar influenciar indevidamente. Por vezes baseamo-nos numa escolha de outrém: se a empresa X ou a entidade Y optou por esta ou por aquela linha de equipamentos, então farei isso também. Na prática, no entanto, as escolhas, mesmo em ambientes muito conceituados, podem não se dever a critérios técnicos ou econômicos objetivos, mas sim a preferências pessoais mais ou menos vagas, ou a doações, ou até mesmo a razões impublicáveis. Nesse particular, vale ressaltar que quanto menor for a vivência dos profissionais envolvidos, maior será também o papel e a influência do marketing nos processos de escolha de uma plataforma (seja o marketing direto feito sobre os clientes, ou seja aquele feito através da mídia, especializada ou não, na forma de anúncios ou de artigos).

    Feitas essas observações, em que tentamos expor de forma ampla a questão da escolha de uma plataforma, iremos apresentar uma lista de hardwares e de sistemas operacionais de uso comum na Internet. Está muito longe de ser completa e não traz estatísticas de uso ou de vendas, mas será útil como ilustração breve do panorama da área.

    A evolução histórica da Internet fez com que fossem sempre particularmente comuns nela máquinas e sistemas operacionais mais ou menos ligados ao Unix e ao BSD, como por exemplo alguns computadores e sistemas da Digital e da Sun. A atual popularidade do Linux é um dos efeitos visíveis dessa evolução. Por outro lado, os padrões mais populares nascidos para operar em redes corporativas privadas em arquitetura Intel (Novell e os sistemas da Microsoft), em virtude da sua grande base instalada (e, portanto, da grande quantidade de profissionais envolvidos com elas), também adaptaram-se para utilizar o TCP como mecanismo de transporte e tornaram-se de uso comum na Internet nos últimos anos. De forma mais específica podemos destacar:

    14.2 Um caso simples de um servidor Internet

    A fim de dar um exemplo mais detalhado, vejamos uma especificação bastante simples de um servidor construído para operar na Internet. A escolha do hardware ou do software poderia ser outra, naturalmente.

    Estamos imaginando que nossa máquina operará como um servidor HTTP, SMTP e POP de baixa demanda. Imaginamos que o total de informações oferecidas via HTTP (isto é, as páginas web, arquivos e eventualmente alguma base de dados associada) não ultrapasse ao todo algumas dezenas de megabytes. A conexão dessa máquina com a Internet será através de um link de (por exemplo) 128 kilobits por segundo. Imaginamos que não haverá mais do que poucas dezenas de caixas postais. Nessa descrição com certeza seria possível encaixar a maior parte dos domínios presentes hoje na Internet.

    Uma típica máquina baseada em Intel do mercado atenderá com folga à demanda submetida ao nosso servidor. Os menores discos do mercado, cuja capacidade gira hoje em torno de 10 gigabytes, armazenarão com grande folga o sistema operacional, as aplicações, os logs de operação, as páginas e arquivos, e as caixas postais. O padrão de disco, num caso desses, é irrelevante, poderia ser ATA ou SCSI (compare a típica taxa de transferência de um disco atual, normalmente da ordem de 10 megabytes por segundo, com a velocidade do link). Uma máquina com esse perfil via de regra operará bastante bem com um total de memória RAM a partir de 64M.

    A conexão desse servidor com a Internet em geral não será feita diretamente, mas sim através de um roteador, que nos casos mais simples funciona meramente como um tradutor de meios físicos. Ele possui uma porta síncrona que se conecta ao modem da linha de dados contratada (LPCD) e uma porta ethernet que pode ser plugada num hub ou diretamente no servidor através de um cabo TP cruzado. Assim, nosso servidor precisa de uma porta ethernet, que é o padrão de LAN "de fato" do mercado. Através dessa mesma porta ethernet, ou talvez através de uma segunda porta ethernet, o servidor pode comunicar-se com uma eventual rede interna. Para a rede interna, ele pode oferecer os serviços POP, relay SMTP e eventualmente proxy HTTP ou ainda mascaramento IP (NAT) e/ou filtragem de pacotes.

    Suponhamos que o sistema operacional utilizado seja alguma das variantes do Linux, como o Red Hat. Nesse caso, todos os serviços desejados estão presentes nativamente no sistema operacional e o servidor poderá entrar em operação logo após a instalação, com relativamente poucas customizações. O serviço HTTP será realizado pelo Apache, o SMTP pelo sendmail, o mascaramento e a filtragem de pacotes são recursos presentes ao nível do kernel, e o POP possui um servidor específico ativado via inetd.

    15. Repertório de comandos

    Os comandos abaixo estão na sintaxe própria do Linux. Em alguma medida essa sintaxe poderá ser usada de forma inalterada na maior parte dos outros sistemas Unix-like ou no Windows.

    16. Os RFCs

    Esta nota deveria talvez ser a primeira deste documento, visto que os RFCs são justamente os standards que definem o TCP/IP. Não obstante, por se tratar de textos que necessitam ter grande precisão técnica, preferimos falar deles ao final. Os RFCs podem ser obtidos no IETF (http://www.ietf.org), inclusive um índice. Muitos outros sites entretanto oferecem os RFCs na Internet,e alguns deles com ferramentas de busca e uma estruturação por temas. Os RFCs não incluem apenas especificações técnicas do TCP/IP (e.g. RFC 821 (SMTP), RFC 1939 (POP3), RFC 1661 (PPP), etc), mas também bibliografias, opiniões e comentários, textos de caráter informativo, como perguntas e respostas sobre a Internet (RFC 2664), glossários (RFC 1208, RFC 1983 RFC 2828), etc. Qualquer pessoa pode criar um novo protocolo e propô-lo para ser incluído no TCP/IP sob a forma de um novo RFC. O procedimento para fazê-lo está descrito no site do IETF.

    17. Bibliografia breve

    [1] Comer, D. Internetworking with TCP-IP vol. I, Prentice Hall. Excelente introdução ao TCP-IP. O volumes II e III (principalmente o II) envelheceram muito.

    [2] Stevens, W. R. TCP-IP Illustrated, vol. I, Addison Wesley, 1994. É geralmente considerado o melhor livro de TCP-IP disponível atualmente. O Volume II descreve a implementação de TCP/IP do BSD e interessará apenas aos especialistas. O volume III também é de interesse relativo, exceto pela abordagem feita do HTTP.

    [3] Claus Rugani Töpke, Provedor Internet, Makron, 1999. Um livro objetivo e muito bem escrito.

    [4] Garfinkel, S., and Spafford, E. Practical Unix Security, O'Reilly, 1991. Excelente livro, fácil de ler e com bastante conteúdo. Esse e/ou outros títulos de Eugene Spafford estão publicados também em português.