Caps 1 e 2 - Tradução PDF

Machine Translated by Google
Capítulo 1 Redes de computadores e a Internet
A Internet de hoje é indiscutivelmente o maior sistema de engenharia já criado pela humanidade, com centenas de milhões de
computadores conectados, links de comunicação e switches; com bilhões de usuários que se conectam
via laptops, tablets e smartphones; e com uma série de novas “coisas” conectadas à Internet, incluindo consoles de jogos,
sistemas de vigilância, relógios, óculos, termostatos, balanças corporais e carros. Dado que a Internet é tão grande e tem tantos
componentes e usos diversos, há alguma esperança de entender como ela funciona? Existem princípios orientadores e
estrutura que podem fornecer uma base para a compreensão de um sistema tão grande e complexo? E se assim for, é possível
que realmente
poderia ser interessante e divertido aprender sobre redes de computadores? Felizmente, a resposta para todas essas perguntas
é um retumbante SIM! De fato, nosso objetivo neste livro é fornecer a você uma visão moderna
introdução ao campo dinâmico de redes de computadores, dando-lhe os princípios e insights práticos
você precisará entender não apenas as redes de hoje, mas também as de amanhã.
Este primeiro capítulo apresenta uma ampla visão geral das redes de computadores e da Internet. Nosso objetivo aqui é
pinte um quadro amplo e defina o contexto para o restante deste livro, para ver a floresta através das árvores.
Cobriremos bastante terreno neste capítulo introdutório e discutiremos muitas das partes de uma rede de computadores, sem
perder de vista o quadro geral.
Estruturaremos nossa visão geral das redes de computadores neste capítulo da seguinte maneira. Depois de introduzir alguns
terminologia e conceitos básicos, examinaremos primeiro os componentes básicos de hardware e software que compõem uma
rede. Começaremos na borda da rede e examinaremos os sistemas finais e os aplicativos de rede em execução na rede.
Em seguida, exploraremos o núcleo de uma rede de computadores, examinando os links e os switches que transportam os
dados, bem como as redes de acesso e os meios físicos que
conectar sistemas finais ao núcleo da rede. Aprenderemos que a Internet é uma rede de redes e
aprenda como essas redes se conectam umas com as outras.
Depois de concluir esta visão geral da borda e do núcleo de uma rede de computadores, adotaremos uma visão mais ampla e
abstrata na segunda metade deste capítulo. Examinaremos atraso, perda e throughput de dados em uma rede de computadores
e forneceremos modelos quantitativos simples para throughput e atraso de ponta a ponta: modelos que levam em consideração
atrasos de transmissão, propagação e enfileiramento. Em seguida, apresentaremos alguns
dos principais princípios arquitetônicos em redes de computadores, ou seja, camadas de protocolo e modelos de serviço.
Também aprenderemos que as redes de computadores são vulneráveis a muitos tipos diferentes de ataques; vamos pesquisar
alguns desses ataques e considere como as redes de computadores podem se tornar mais seguras. Por fim,
encerraremos este capítulo com um breve histórico das redes de computadores.
1.1 O que é a Internet?
Neste livro, usaremos a Internet pública, uma rede específica de computadores, como nosso principal veículo de
discutindo redes de computadores e seus protocolos. Mas o que é a Internet? Existem algumas maneiras de responder a
essa pergunta. Primeiro, podemos descrever as porcas e parafusos da Internet, ou seja, o básico
componentes de hardware e software que compõem a Internet. Em segundo lugar, podemos descrever a Internet em
termos de uma infraestrutura de rede que fornece serviços para aplicativos distribuídos. Vamos começar com
a descrição prática, usando a Figura 1.1 para ilustrar nossa discussão.
1.1.1 Uma Descrição Porcas e Parafusos
A Internet é uma rede de computadores que interconecta bilhões de dispositivos de computação em todo o mundo.
Não muito tempo atrás, esses dispositivos de computação eram principalmente PCs de mesa tradicionais,
estações de trabalho Linux e os chamados servidores que armazenam e transmitem informações como páginas da Web e e-mail.
mensagens. Cada vez mais, no entanto, “coisas” não tradicionais da Internet, como laptops, smartphones, tablets,
TVs, consoles de jogos, termostatos, sistemas de segurança doméstica, eletrodomésticos, relógios, óculos,
carros, sistemas de controle de tráfego e muito mais estão sendo conectados à Internet. De fato, o termo rede de
computadores está começando a soar um pouco desatualizado, dados os muitos dispositivos não tradicionais que estão
sendo conectados à Internet. No jargão da Internet, todos esses dispositivos são chamados de hosts ou sistemas finais. Por alguns
estimativas, em 2015 havia cerca de 5 bilhões de dispositivos conectados à Internet, e o número aumentará
chegar a 25 bilhões até 2020 [Gartner 2014]. Estima-se que em 2015 havia mais de 3,2 bilhões de usuários de Internet
em todo o mundo, aproximadamente 40% da população mundial [ITU 2015].
Figura 1.1 Algumas partes da Internet
Os sistemas finais são conectados entre si por uma rede de links de comunicação e comutadores de pacotes.
Veremos na Seção 1.2 que existem muitos tipos de enlaces de comunicação, que são
diferentes tipos de mídia física, incluindo cabo coaxial, fio de cobre, fibra ótica e espectro de rádio.
Links diferentes podem transmitir dados em taxas diferentes, com a taxa de transmissão de um link medida em
bits/segundo. Quando um sistema final tem dados para enviar para outro sistema final, o sistema final emissor
segmenta os dados e adiciona bytes de cabeçalho a cada segmento. Os pacotes de informações resultantes,
conhecidos como pacotes no jargão das redes de computadores, são então enviados pela rede para o sistema
final de destino, onde são remontados nos dados originais.
Um comutador de pacotes pega um pacote que chega em um de seus links de comunicação de entrada e o encaminha
pacote em um de seus links de comunicação de saída. Os comutadores de pacotes vêm em muitas formas e sabores,
mas os dois tipos mais proeminentes na Internet de hoje são roteadores e comutadores de camada de enlace. Ambos os
tipos de switches encaminham pacotes para seus destinos finais. Os switches da camada de enlace são normalmente
usados em redes de acesso, enquanto os roteadores são normalmente usados no núcleo da rede. A sequência de comunicação
links e comutadores de pacotes atravessados por um pacote do sistema final de envio para o final de recebimento
sistema é conhecido como uma rota ou caminho através da rede. Cisco prevê que o tráfego IP global anual passará
21
o limite zettabyte (10 bytes) até o final de 2016 e atingirá 2 zettabytes por ano até 2019
[Cisco VNI 2015].
As redes de comutação de pacotes (que transportam pacotes) são de muitas maneiras semelhantes às redes de transporte
de rodovias, estradas e cruzamentos (que transportam veículos). Considere, por exemplo, uma fábrica que
precisa mover uma grande quantidade de carga para algum armazém de destino localizado a milhares de quilômetros de
distância. Na fábrica, a carga é segmentada e carregada em uma frota de caminhões. Cada um dos caminhões viaja
independentemente pela rede de rodovias, estradas e cruzamentos até o destino
armazém. No armazém de destino, a carga é descarregada e agrupada com as demais cargas provenientes do mesmo
embarque. Assim, de muitas maneiras, os pacotes são análogos a caminhões,
links são análogos a rodovias e estradas, comutadores de pacotes são análogos a interseções e terminam
os sistemas são análogos aos edifícios. Assim como um caminhão percorre uma rede de transporte, um pacote percorre
uma rede de computadores.
Os sistemas finais acessam a Internet por meio de provedores de serviços de Internet (ISPs), incluindo ISPs residenciais
como empresas de TV a cabo ou telefônicas locais; ISPs corporativos; ISP universitários; ISPs que fornecem acesso
Wi-Fi em aeroportos, hotéis, cafés e outros locais públicos; e ISPs de dados celulares, fornecendo acesso móvel a
nossos smartphones e outros dispositivos. Cada ISP é em si uma rede de comutadores de pacotes
e links de comunicação. Os ISPs fornecem uma variedade de tipos de acesso à rede para os sistemas finais,
incluindo acesso residencial de banda larga, como modem a cabo ou DSL, rede local de alta velocidade
acesso e acesso sem fio móvel. Os ISPs também fornecem acesso à Internet para provedores de conteúdo,
conectando sites da Web e servidores de vídeo diretamente à Internet. A Internet tem tudo a ver com conectar sistemas
finais uns aos outros, portanto, os ISPs que fornecem acesso aos sistemas finais também devem estar interconectados.
Esses ISPs de nível inferior são interconectados por meio de ISPs de nível superior nacionais e internacionais, como
Level 3 Communications, AT&T, Sprint e NTT. Um ISP de nível superior consiste em roteadores de alta velocidade
interconectados com links de fibra ótica de alta velocidade. Cada rede ISP, seja de nível superior ou inferior, é
gerenciado de forma independente, executa o protocolo IP (veja abaixo) e está em conformidade com determinados nomes e endereços
convenções. Examinaremos os ISPs e sua interconexão mais de perto na Seção 1.3.
Sistemas finais, comutadores de pacotes e outras partes da Internet executam protocolos que controlam o envio
e recebimento de informações na Internet. O Protocolo de Controle de Transmissão (TCP) e o
Protocolo de Internet (IP) são dois dos protocolos mais importantes da Internet. O protocolo IP especifica o formato dos pacotes que
são enviados e recebidos entre roteadores e sistemas finais. Os principais protocolos da Internet são conhecidos coletivamente
como TCP/IP. Começaremos a examinar os protocolos neste capítulo introdutório. Mas isso é apenas um começo -
grande parte deste livro trata de protocolos de rede de computadores!
Dada a importância dos protocolos para a Internet, é importante que todos concordem sobre o que cada um
todo protocolo faz, para que as pessoas possam criar sistemas e produtos que interoperem. É aqui que os padrões entram em jogo.
Os padrões da Internet são desenvolvidos pela Internet Engineering Task Force
(IETF) [IETF 2016]. Os documentos de padrões da IETF são chamados de solicitações de comentários (RFCs). RFCs começaram
como solicitações gerais de comentários (daí o nome) para resolver o projeto de rede e protocolo
problemas enfrentados pelo precursor da Internet [Allman 2011]. Os RFCs tendem a ser bastante técnicos e detalhados. Eles
definem protocolos como TCP, IP, HTTP (para a Web) e SMTP (para e-mail). Existem atualmente mais de 7.000 RFCs. Outros órgãos
também especificam padrões para componentes de rede, a maioria
principalmente para links de rede. O IEEE 802 LAN/MAN Standards Committee [IEEE 802 2016], por exemplo, especifica os padrões
Ethernet e WiFi sem fio.
1.1.2 Uma Descrição dos Serviços
Nossa discussão acima identificou muitas das peças que compõem a Internet. Mas também podemos
descrevem a Internet de um ângulo totalmente diferente, ou seja, como uma infraestrutura que fornece serviços para
aplicativos. Além dos aplicativos tradicionais, como e-mail e navegação na Web, os aplicativos da Internet incluem aplicativos móveis
para smartphones e tablets, incluindo mensagens pela Internet, mapeamento com informações de tráfego rodoviário em tempo real,
streaming de música da nuvem, streaming de filmes e televisão, redes sociais on-line redes, videoconferência, jogos com várias
pessoas e sistemas de recomendação baseados em localização. Os aplicativos são chamados de aplicativos distribuídos, pois
envolvem vários sistemas finais que trocam dados entre si. É importante ressaltar que os aplicativos da Internet são executados
em sistemas finais - eles não são executados nos comutadores de pacotes no núcleo da rede. Embora os comutadores de pacotes
facilitem a troca de dados entre os sistemas finais, eles não se preocupam com o aplicativo que é a fonte ou
sumidouro de dados.
Vamos explorar um pouco mais o que entendemos por infraestrutura que fornece serviços para aplicativos. Para
Para tanto, suponha que você tenha uma nova e empolgante ideia para um aplicativo de Internet distribuído, que pode beneficiar
muito a humanidade ou simplesmente torná-lo rico e famoso. Como você pode ir sobre
transformar essa ideia em um aplicativo de Internet real? Como os aplicativos são executados em sistemas finais, você precisará
escrever programas que sejam executados nos sistemas finais. Você pode, por exemplo, escrever seus programas em Java,
C ou Python. Agora, como você está desenvolvendo um aplicativo de Internet distribuído, os programas em execução nos diferentes
sistemas finais precisarão enviar dados uns aos outros. E aqui chegamos a
uma questão central — que leva à forma alternativa de descrever a Internet como uma plataforma para aplicativos. Como
um programa executado em um sistema final instrui a Internet a fornecer dados para outro programa executado em outro sistema
final?
Os sistemas finais conectados à Internet fornecem uma interface de soquete que especifica como um programa em execução
em uma extremidade, o sistema solicita à infraestrutura da Internet que entregue dados a um programa de destino específico
rodando em outro sistema final. Essa interface de soquete de Internet é um conjunto de regras que o programa de envio deve
seguir para que a Internet possa entregar os dados ao programa de destino. Nós vamos discutir o
A interface do soquete da Internet é detalhada no Capítulo 2. Por enquanto, vamos recorrer a uma analogia simples, que
usaremos com frequência neste livro. Suponha que Alice queira enviar uma carta para Bob usando o serviço postal.
Alice, é claro, não pode simplesmente escrever a carta (os dados) e jogá-la pela janela. Em vez disso, o
o serviço postal exige que Alice coloque a carta em um envelope; escreva o nome completo, endereço e CEP de Bob no centro
do envelope; selar o envelope; coloque um selo no canto superior direito do envelope; e, finalmente, coloque o envelope em uma
caixa de correio oficial do serviço postal. Assim, o serviço postal
tem sua própria “interface de serviço postal”, ou conjunto de regras, que Alice deve seguir para ter o serviço postal
entregar sua carta para Bob. De maneira semelhante, a Internet possui uma interface de soquete que o programa que
envia os dados deve seguir para que a Internet entregue os dados ao programa que os receberá.
O serviço postal, é claro, oferece mais de um serviço aos seus clientes. Ele fornece entrega expressa, confirmação de
recebimento, uso comum e muitos outros serviços. De forma semelhante, a Internet
fornece vários serviços para suas aplicações. Ao desenvolver um aplicativo de Internet, você também deve
escolha um dos serviços da Internet para sua aplicação. Descreveremos os serviços da Internet em
Capítulo 2.
Acabamos de dar duas descrições da Internet; um em termos de seus componentes de hardware e software, o outro
em termos de infraestrutura para fornecer serviços a aplicativos distribuídos. Mas talvez você ainda esteja confuso sobre o que é a
Internet. O que são comutação de pacotes e TCP/IP? O que são roteadores? Que tipos de links de comunicação estão presentes
na Internet? O que é um aplicativo distribuído? Como um termostato ou balança corporal pode ser conectado à Internet?
Se você se sente um pouco sobrecarregado com tudo isso agora, não se preocupe - o objetivo deste livro é apresentá-
lo tanto ao
porcas e parafusos da Internet e os princípios que governam como e por que ela funciona. Explicaremos esses termos e
questões importantes nas seções e capítulos seguintes.
1.1.3 O que é um protocolo?

Agora que temos uma idéia do que é a Internet, vamos considerar outra palavra da moda importante em
redes de computadores: protocolo. O que é um protocolo? O que um protocolo faz?
Uma Analogia Humana
Provavelmente é mais fácil entender a noção de um protocolo de rede de computadores considerando primeiro algumas analogias
humanas, já que nós humanos executamos protocolos o tempo todo. Considere o que você faz quando
quer perguntar a alguém qual é a hora do dia. Uma troca típica é mostrada na Figura 1.2. O protocolo humano (ou boas maneiras,
pelo menos) determina que primeiro se ofereça uma saudação (o primeiro “Oi” na Figura 1.2) para iniciar a comunicação com
outra pessoa. A resposta típica a um “Hi” é uma mensagem “Hi” retornada. Implicitamente, então, uma resposta cordial “Oi” é uma
indicação de que se pode prosseguir e perguntar qual é a hora do dia.
Uma resposta diferente ao “Oi” inicial (como “Não me incomode!” ou “Não falo inglês” ou algum
resposta não imprimível) pode
Figura 1.2 Um protocolo humano e um protocolo de rede de computador
indicam falta de vontade ou incapacidade de se comunicar. Nesse caso, o protocolo humano seria não
pergunte a hora do dia. Às vezes, não se obtém resposta alguma para uma pergunta e, nesse caso, normalmente
desiste de perguntar as horas àquela pessoa. Observe que em nosso protocolo humano, existem mensagens específicas
enviamos e ações específicas que tomamos em resposta às mensagens de resposta recebidas ou outros eventos (como nenhuma resposta dentro
de um determinado período de tempo). Claramente, as mensagens transmitidas e recebidas e as ações tomadas quando essas mensagens são
enviadas ou recebidas ou outros eventos ocorrem, desempenham um papel central em um ser humano.
protocolo. Se as pessoas executam protocolos diferentes (por exemplo, se uma pessoa tem boas maneiras, mas a outra não, ou se uma
entende o conceito de tempo e a outra não), os protocolos não interagem
e nenhum trabalho útil pode ser realizado. O mesmo é verdadeiro na rede - são necessárias duas (ou mais) entidades comunicantes
executando o mesmo protocolo para realizar uma tarefa.
Vamos considerar uma segunda analogia humana. Suponha que você esteja em uma aula de faculdade (um curso de rede de computadores
classe, por exemplo!). O professor está falando monotonamente sobre protocolos e você está confuso. O professor pára para perguntar: “Alguma
pergunta?” (uma mensagem que é transmitida e recebida por todos os alunos que não estão dormindo). Você levanta a mão (transmitindo uma
mensagem implícita ao professor). Seu professor reconhece você com um sorriso, dizendo “Sim. . .” (uma mensagem transmitida incentivando
você a perguntar ao seu
pergunta - os professores adoram receber perguntas) e você então faz sua pergunta (isto é, transmite sua mensagem ao professor). Seu professor
ouve sua pergunta (recebe sua mensagem de pergunta) e
respostas (transmite uma resposta para você). Mais uma vez, vemos que a transmissão e o recebimento de mensagens e um conjunto de ações
convencionais executadas quando essas mensagens são enviadas e recebidas estão no centro desse protocolo de perguntas e respostas.
Protocolos de rede
Um protocolo de rede é semelhante a um protocolo humano, exceto que as entidades que trocam mensagens e realizam ações são
componentes de hardware ou software de algum dispositivo (por exemplo, computador, smartphone, tablet, roteador ou outro
dispositivo com capacidade de rede). Toda atividade na Internet que envolve duas ou mais entidades remotas em comunicação é regida por um
protocolo. Por exemplo, implementado em hardware
protocolos em dois computadores conectados fisicamente controlam o fluxo de bits no “fio” entre as duas placas de interface de rede; protocolos
de controle de congestionamento em sistemas finais controlam a taxa na qual os pacotes
são transmitidos entre o remetente e o destinatário; os protocolos nos roteadores determinam o caminho de um pacote da origem ao
destino. Os protocolos estão sendo executados em toda parte na Internet e, consequentemente, muito disso
livro é sobre protocolos de rede de computadores.
Como um exemplo de um protocolo de rede de computador com o qual você provavelmente está familiarizado, considere o que
acontece quando você faz uma solicitação a um servidor Web, ou seja, quando você digita a URL de uma página da Web em
seu navegador da Web. O cenário é ilustrado na metade direita da Figura 1.2. Primeiro, seu computador enviará uma mensagem de solicitação
de conexão ao servidor Web e aguardará uma resposta. O servidor Web eventualmente receberá sua mensagem de solicitação de
conexão e retornará uma mensagem de resposta de conexão. Sabendo que agora pode solicitar o documento da Web, seu computador envia o
nome da página da Web que deseja obter desse servidor da Web em uma mensagem GET. Finalmente, o servidor Web retorna a página Web
(arquivo) para o seu computador.

Dados os exemplos humanos e de rede acima, a troca de mensagens e as ações executadas quando essas
mensagens são enviadas e recebidas são os principais elementos que definem um protocolo:
Um protocolo define o formato e a ordem das mensagens trocadas entre dois ou mais
entidades comunicantes, bem como as ações realizadas na transmissão e/ ou recebimento de uma mensagem
ou outro evento.
A Internet e as redes de computadores em geral fazem uso extensivo de protocolos. Diferentes protocolos são
usados para realizar diferentes tarefas de comunicação. Ao ler este livro, você aprenderá que alguns protocolos são
simples e diretos, enquanto outros são complexos e intelectualmente profundos.
Dominar o campo da rede de computadores é equivalente a entender o que, por que e como dos protocolos de
rede.
1.2 A Borda da Rede
Na seção anterior, apresentamos uma visão geral de alto nível da Internet e dos protocolos de rede. Agora vamos nos aprofundar um
pouco mais nos componentes de uma rede de computadores (e da Internet, em particular). Começamos nesta seção na borda de
uma rede e examinamos os componentes com os quais
estamos mais familiarizados - ou seja, os computadores, smartphones e outros dispositivos que usamos diariamente
base. Na próxima seção, passaremos da borda da rede para o núcleo da rede e examinaremos a comutação
e roteamento em redes de computadores.
Lembre-se da seção anterior que, no jargão de redes de computadores, os computadores e outros dispositivos
conectados à Internet são muitas vezes referidos como sistemas finais. Eles são referidos como sistemas finais
porque eles ficam na borda da Internet, conforme mostrado na Figura 1.3. Os sistemas finais da Internet incluem computadores de
mesa (por exemplo, PCs de mesa, Macs e Linux), servidores (por exemplo, servidores Web e de e-mail) e dispositivos móveis (por
exemplo, laptops, smartphones e tablets). Além disso, um número crescente de “coisas” não tradicionais está sendo anexado à
Internet como sistemas finais (consulte o Histórico de Caso
recurso).
Os sistemas finais também são chamados de hosts porque hospedam (ou seja, executam) programas de aplicativos, como um
programa de navegador da Web, um programa de servidor da Web, um programa de cliente de e-mail ou um programa de servidor de e-mail.
Ao longo deste livro, usaremos o

Figura 1.3 Interação do sistema final
HISTÓRICO DE CASO
A INTERNET DAS COISAS
Você consegue imaginar um mundo em que quase tudo esteja conectado sem fio à Internet?
Um mundo em que a maioria das pessoas, carros, bicicletas, óculos, relógios, brinquedos, equipamentos hospitalares,
sensores domésticos, salas de aula, sistemas de vigilância por vídeo, sensores atmosféricos, prateleiras de lojas
produtos e animais de estimação estão conectados? Este mundo da Internet das Coisas (IoT) pode realmente ser apenas
ao virar da esquina.
Segundo algumas estimativas, em 2015 já havia 5 bilhões de coisas conectadas à Internet, e
o número pode chegar a 25 bilhões até 2020 [Gartner 2014]. Essas coisas incluem nossos smartphones,
que já nos seguem em nossas casas, escritórios e carros, relatando nossa localização geográfica.
locais e dados de uso para nossos ISPs e aplicativos de Internet. Mas além do nosso
smartphones, uma grande variedade de “coisas” não tradicionais já estão disponíveis como produtos. Por exemplo,
existem dispositivos vestíveis conectados à Internet, incluindo relógios (da Apple e muitos outros) e óculos. Os óculos
conectados à Internet podem, por exemplo, carregar tudo o que vemos na nuvem, permitindo que compartilhemos nossas
experiências visuais com pessoas de todo o mundo em tempo real. Existem coisas conectadas à Internet já disponíveis
para a casa inteligente, incluindo
Termostatos conectados à Internet que podem ser controlados remotamente a partir de nossos smartphones e
balanças corporais conectadas à Internet, que nos permitem revisar graficamente o progresso de nossas dietas a partir de
nossos smartphones. Existem brinquedos conectados à Internet, incluindo bonecas que reconhecem e interpretam a fala
de uma criança e respondem adequadamente.
A IoT oferece benefícios potencialmente revolucionários aos usuários. Mas ao mesmo tempo também existem
enormes riscos de segurança e privacidade. Por exemplo, os invasores, por meio da Internet, podem invadir dispositivos
IoT ou servidores que coletam dados de dispositivos IoT. Por exemplo, um invasor pode sequestrar uma boneca
conectada à Internet e falar diretamente com uma criança; ou um invasor pode hackear
em um banco de dados que armazena informações pessoais de saúde e atividade coletadas de dispositivos vestíveis
dispositivos. Essas preocupações de segurança e privacidade podem minar a confiança do consumidor
necessárias para que as tecnologias alcancem todo o seu potencial e podem resultar em
adoção [FTC 2015].
termos hosts e sistemas finais de forma intercambiável; ou seja, host = sistema final. Às vezes, os hosts são divididos em duas
categorias: clientes e servidores. Informalmente, os clientes tendem a ser PCs móveis e de mesa, smartphones e assim por diante,
enquanto os servidores tendem a ser máquinas mais poderosas que armazenam e distribuem páginas da Web, transmitem vídeos,
retransmitem e-mails e assim por diante. Hoje, a maioria dos servidores dos quais recebemos resultados de pesquisa, e-mail,
páginas da Web e vídeos reside em grandes centros de dados. Por exemplo, o Google tem de 50 a 100 data centers, incluindo
cerca de 15 grandes centros, cada um com mais de 100.000 servidores.
1.2.1 Redes de Acesso
Tendo considerado os aplicativos e sistemas finais na “borda da rede”, vamos considerar a rede de acesso - a rede que conecta
fisicamente um sistema final ao primeiro roteador (também conhecido como
o “roteador de borda”) em um caminho do sistema final para qualquer outro sistema final distante. A Figura 1.4 mostra vários
tipos de acesso
Figura 1.4 Redes de acesso
redes com linhas grossas e sombreadas e as configurações (residencial, empresarial e wireless móvel de área ampla) em
quais são usados.
Acesso residencial: DSL, cabo, FTTH, dial-up e satélite

Nos países desenvolvidos, a partir de 2014, mais de 78 por cento dos domicílios têm acesso à Internet, com
Coréia, Holanda, Finlândia e Suécia lideram o caminho com mais de 80 por cento dos domicílios
ter acesso à Internet, quase tudo através de uma conexão de banda larga de alta velocidade [ITU 2015]. Dado esse
uso generalizado de redes de acesso doméstico, vamos começar nossa visão geral das redes de acesso considerando
como as casas se conectam à Internet.
Hoje, os dois tipos mais comuns de acesso residencial de banda larga são linha de assinante digital (DSL) e cabo. Uma
residência normalmente obtém acesso à Internet DSL da mesma companhia telefônica local
(telco) que fornece seu acesso telefônico local com fio. Assim, quando DSL é usado, a telco de um cliente também é sua
ISP. Conforme mostrado na Figura 1.5, o modem DSL de cada cliente usa a linha telefônica existente (fio de cobre de
par trançado, que discutiremos na Seção 1.2.2) para trocar dados com um multiplexador de acesso à linha de assinante
digital (DSLAM) localizado no local da operadora de telecomunicações. escritório central (CO). O modem DSL da casa
pega os dados digitais e os converte em tons de alta frequência para transmissão por fios telefônicos para o CO; os sinais
analógicos de muitas dessas casas são traduzidos de volta para o formato digital no DSLAM.
A linha telefônica residencial transporta dados e sinais telefônicos tradicionais simultaneamente, que são codificados em
diferentes frequências:
Um canal downstream de alta velocidade, na banda de 50 kHz a 1 MHz
Um canal upstream de velocidade média, na banda de 4 kHz a 50 kHz
Um canal telefônico bidirecional comum, na banda de 0 a 4 kHz
Essa abordagem faz com que o único link DSL apareça como se houvesse três links separados, de modo que uma
chamada telefônica e uma conexão com a Internet possam compartilhar o link DSL ao mesmo tempo.
Figura 1.5 Acesso à Internet DSL
(Descreveremos essa técnica de multiplexação por divisão de frequência na Seção 1.3.1.) No lado do cliente, um divisor separa
os sinais de dados e telefone que chegam à casa e encaminha o sinal de dados para
o modem DSL. No lado da telco, no CO, o DSLAM separa os dados e sinais de telefone e envia os dados para a Internet. Centenas ou
mesmo milhares de residências se conectam a um único DSLAM
[Dischinger 2007].
Os padrões DSL definem várias taxas de transmissão, incluindo 12 Mbps downstream e 1,8 Mbps
upstream [ITU 1999] e 55 Mbps downstream e 15 Mbps upstream [ITU 2006]. Como as taxas downstream e upstream são
diferentes, o acesso é considerado assimétrico. As taxas reais de transmissão downstream e upstream alcançadas podem
ser menores que as taxas mencionadas acima, pois o
O provedor de DSL pode limitar intencionalmente uma tarifa residencial quando o serviço escalonado (diferentes tarifas, disponíveis em
preços diferentes) são oferecidos. A taxa máxima também é limitada pela distância entre a casa e o CO, a bitola da linha de par
trançado e o grau de interferência elétrica. Os engenheiros projetaram expressamente o DSL para distâncias curtas entre a casa e
o CO; geralmente, se a residência não estiver localizada dentro de 5 a 10 milhas do CO, a residência deve recorrer a uma forma alternativa
de Internet
acesso.
Enquanto o DSL faz uso da infra-estrutura de telefonia local existente da empresa de telecomunicações, o acesso à Internet a
cabo faz uso da infra-estrutura de televisão a cabo existente da empresa de televisão a cabo. Uma residência obtém
acesso à Internet por cabo da mesma empresa que fornece a sua televisão por cabo. Conforme ilustrado na Figura
1.6, a fibra ótica conecta a extremidade principal do cabo às junções no nível do bairro, a partir das quais o cabo coaxial tradicional
é usado para alcançar casas e apartamentos individuais. Cada junção de bairro normalmente suporta de 500 a 5.000 residências.
Como tanto o cabo de fibra quanto o cabo coaxial são empregados neste sistema, muitas vezes ele é chamado de coaxial de fibra
híbrida (HFC).
Figura 1.6 Uma rede de acesso híbrida fibra-coaxial
O acesso à Internet via cabo requer modems especiais, chamados de modems a cabo. Tal como acontece com um modem DSL, o cabo
O modem normalmente é um dispositivo externo e se conecta ao PC doméstico por meio de uma porta Ethernet. (Vamos
discuta a Ethernet em detalhes no Capítulo 6.) No head end do cabo, o sistema de terminação do modem a cabo (CMTS)
desempenha uma função semelhante ao DSLAM da rede DSL - transformando o sinal analógico enviado dos modems a cabo em muitos
lares downstream de volta para digital formatar. Modems a cabo dividem o
rede HFC em dois canais, um downstream e um canal upstream. Assim como no DSL, o acesso é
normalmente assimétrico, com o canal downstream normalmente alocado a uma taxa de transmissão mais alta do que o canal
upstream. O padrão DOCSIS 2.0 define taxas downstream de até 42,8 Mbps e
taxas upstream de até 30,7 Mbps. Como no caso das redes DSL, a taxa máxima alcançável pode não ser alcançada devido a taxas de
dados contratadas mais baixas ou deficiências de mídia.
Uma característica importante do acesso à Internet via cabo é que ele é um meio de transmissão compartilhado. Em particular,
todo pacote enviado pelo head end viaja downstream em cada link para cada home e todo pacote enviado por um home viaja no canal
upstream até o head end. Por esse motivo, se vários usuários estiverem baixando simultaneamente um arquivo de vídeo no canal
downstream, a taxa real na qual
cada usuário recebe seu arquivo de vídeo será significativamente menor do que a taxa agregada de downstream do cabo. Por outro lado,
se houver apenas alguns usuários ativos e todos eles estiverem navegando na Web, cada um dos usuários poderá realmente receber
páginas da Web na taxa completa de downstream do cabo, porque os usuários raramente solicitarão
uma página da Web exatamente ao mesmo tempo. Como o canal upstream também é compartilhado, um canal distribuído
protocolo de acesso múltiplo é necessário para coordenar as transmissões e evitar colisões. (Vamos discutir isso
colisão com algum detalhe no Capítulo 6.)
Embora as redes DSL e a cabo representem atualmente mais de 85% do acesso residencial de banda larga nos Estados Unidos, uma
tecnologia promissora que fornece velocidades ainda mais altas é a fibra até a residência (FTTH) [FTTH Council 2016]. Como o nome
sugere, o conceito de FTTH é simples – fornece um caminho de fibra ótica do CO diretamente para casa. Muitos países hoje - incluindo
os Emirados Árabes Unidos,
Coréia, Hong Kong, Japão, Cingapura, Taiwan, Lituânia e Suécia - agora têm domicílios
taxas de penetração superiores a 30% [FTTH Council 2016].
Existem várias tecnologias concorrentes para distribuição óptica do CO para as residências. A rede de distribuição óptica mais
simples é chamada de fibra direta, com uma fibra saindo do CO para cada residência.
Mais comumente, cada fibra que sai do escritório central é, na verdade, compartilhada por muitas residências; não é até que a fibra chegue
relativamente perto das residências que ela é dividida em fibras individuais específicas do cliente. Existem duas arquiteturas de rede
de distribuição óptica concorrentes que realizam essa divisão: óptica ativa
redes (AONs) e redes ópticas passivas (PONs). AON é essencialmente Ethernet comutada, que é
discutido no Capítulo 6.
Aqui, discutimos brevemente o PON, que é usado no serviço FIOS da Verizon. A Figura 1.7 mostra o FTTH usando a arquitetura de
distribuição PON. Cada residência possui um terminador de rede óptica (ONT), que é conectado por fibra óptica dedicada a um
divisor de vizinhança. O divisor combina uma série de
casas (normalmente menos

Figura 1.7 Acesso à Internet FTTH
de 100) em uma única fibra óptica compartilhada, que se conecta a um terminador de linha óptica (OLT) no CO da telco.
A OLT, fornecendo conversão entre sinais ópticos e elétricos, conecta-se à Internet por meio de um roteador telco.
Em casa, os usuários conectam um roteador doméstico (normalmente um roteador sem fio) ao
ONT e acesse a Internet através deste roteador doméstico. Na arquitetura PON, todos os pacotes enviados da OLT para
o divisor são replicados no divisor (semelhante a um cabeçote de cabo).
O FTTH pode potencialmente fornecer taxas de acesso à Internet na faixa de gigabits por segundo. No entanto, a
maioria dos ISPs FTTH oferece ofertas de taxas diferentes, com as taxas mais altas naturalmente custando mais dinheiro. O
a velocidade média de downstream dos clientes FTTH dos EUA foi de aproximadamente 20 Mbps em 2011 (em
comparação com 13 Mbps para redes de acesso a cabo e menos de 5 Mbps para DSL) [FTTH Council 2011b].
Duas outras tecnologias de rede de acesso também são usadas para fornecer acesso à Internet para residências.
Em locais onde DSL, cabo e FTTH não estão disponíveis (por exemplo, em algumas áreas rurais), um link de satélite pode
ser usado para conectar uma residência à Internet em velocidades superiores a 1 Mbps; StarBand e HughesNet
são dois desses provedores de acesso via satélite. O acesso dial-up através de linhas telefônicas tradicionais é baseado
no mesmo modelo que DSL - um modem doméstico se conecta por uma linha telefônica a um modem no ISP.
Comparado com DSL e outras redes de acesso de banda larga, o acesso dial-up é terrivelmente lento a 56 kbps.
Acesso na empresa (e em casa): Ethernet e WiFi
Em campi corporativos e universitários, e cada vez mais em ambientes domésticos, uma rede local (LAN) é usada para
conectar um sistema final ao roteador de borda. Embora existam muitos tipos de tecnologias LAN, a Ethernet é de longe a
tecnologia de acesso mais prevalente em redes corporativas, universitárias e domésticas. Como
mostrado na Figura 1.8, os usuários de Ethernet usam fio de cobre de par trançado para se conectar a um switch
Ethernet, uma tecnologia discutida em detalhes no Capítulo 6. O switch Ethernet, ou uma rede desse tipo
Figura 1.8 Acesso Ethernet à Internet
switches interconectados, por sua vez, é conectado à Internet maior. Com acesso Ethernet, os usuários
normalmente têm 100 Mbps ou 1 Gbps de acesso ao switch Ethernet, enquanto os servidores podem ter 1 Gbps ou até
mesmo 10 Gbps de acesso.
Cada vez mais, no entanto, as pessoas estão acessando a Internet sem fio a partir de laptops, smartphones, tablets,
e outras “coisas” (veja a barra lateral anterior sobre “Internet das Coisas”). Em uma configuração de LAN sem fio,
os usuários sem fio transmitem/recebem pacotes de/para um ponto de acesso conectado à rede da empresa
(provavelmente usando Ethernet com fio), que por sua vez está conectada à Internet com fio. Um usuário de LAN sem fio
normalmente deve estar a algumas dezenas de metros do ponto de acesso. Acesso LAN sem fio baseado em IEEE
A tecnologia 802.11, mais conhecida coloquialmente como WiFi, está agora em quase todos os lugares -
universidades, escritórios comerciais, cafés, aeroportos, residências e até mesmo em aviões. Em muitas cidades, pode-se ficar na rua
canto e estar dentro do alcance de dez ou vinte estações base (para um mapa global navegável de estações base 802.11
que foram descobertas e registradas em um site da Web por pessoas que gostam muito de
fazer essas coisas, consulte [wigle.net 2016]). Conforme discutido em detalhes no Capítulo 7, o 802.11 hoje oferece uma
taxa de transmissão compartilhada de mais de 100 Mbps.
Embora as redes de acesso Ethernet e WiFi tenham sido inicialmente implantadas em ambientes corporativos
(corporativos, universitários), recentemente elas se tornaram componentes relativamente comuns de redes domésticas.
Muitas residências combinam acesso residencial de banda larga (ou seja, modems a cabo ou DSL) com esses
tecnologias LAN sem fio para criar redes domésticas poderosas [Edwards 2011]. A Figura 1.9 mostra uma rede
doméstica típica. Essa rede doméstica consiste em um laptop em roaming e em um PC com fio; uma estação base (o
ponto de acesso sem fio), que se comunica com o PC sem fio e outros dispositivos sem fio em casa; um modem a
cabo, fornecendo acesso de banda larga à Internet; e um roteador, que
interconecta a estação base e o PC estacionário com o modem a cabo. Esta rede permite que os membros da
família tenham acesso à Internet em banda larga com um membro em roaming do
cozinha para o quintal para os quartos.
Figura 1.9 Uma rede doméstica típica
Acesso sem fio de área ampla: 3G e LTE
Cada vez mais, dispositivos como iPhones e dispositivos Android estão sendo usados para enviar mensagens, compartilhar fotos em
redes sociais, assista a filmes e transmita música durante a corrida. Esses dispositivos empregam a mesma infraestrutura sem
fio usada para telefonia celular para enviar/receber pacotes por meio de uma estação base operada pelo provedor de rede celular.
Ao contrário do WiFi, um usuário só precisa estar dentro de algumas dezenas de
quilômetros (ao contrário de algumas dezenas de metros) da estação base.
As empresas de telecomunicações fizeram enormes investimentos na chamada tecnologia sem fio de terceira geração (3G), que
oferece acesso à Internet sem fio de área ampla com comutação de pacotes a velocidades superiores a 1 Mbps. Mas tecnologias
de acesso de área ampla ainda mais rápidas - uma quarta geração (4G) de rede de área ampla
redes sem fio — já estão sendo implantadas. LTE (para “Long-Term Evolution”—candidato ao Bad Acronym of the Year Award)
tem suas raízes na tecnologia 3G e pode atingir taxas superiores a 10
Mbps. Taxas downstream LTE de muitas dezenas de Mbps foram relatadas em implantações comerciais.
Abordaremos os princípios básicos de redes sem fio e mobilidade, bem como WiFi, 3G e LTE
tecnologias (e mais!) no Capítulo 7.
1.2.2 Mídia Física
Na subseção anterior, demos uma visão geral de algumas das mais importantes redes de acesso
tecnologias na Internet. Ao descrevermos essas tecnologias, também indicamos a mídia física
usado. Por exemplo, dissemos que o HFC usa uma combinação de cabo de fibra e cabo coaxial. Dissemos que DSL e Ethernet
usam fio de cobre. E dissemos que as redes de acesso móvel usam o espectro de rádio. Em
Nesta subseção, fornecemos uma breve visão geral desses e de outros meios de transmissão que são comumente
usado na Internet.
Para definir o que se entende por meio físico, reflitamos sobre a breve vida de um bit. Considere um bit viajando de um sistema
final, através de uma série de links e roteadores, para outro sistema final. Este pobre pedaço é chutado e transmitido muitas e
muitas vezes! O sistema final de origem primeiro transmite o bit e, logo em seguida, o primeiro roteador da série recebe o bit; o
primeiro roteador então transmite o bit e logo em seguida o segundo roteador recebe o bit; e assim por diante. Assim, nosso bit,
ao viajar da origem ao destino, passa por uma série de pares transmissor-receptor. Para cada par transmissor-receptor, o bit é
enviado pela propagação de ondas eletromagnéticas ou pulsos ópticos através de um meio físico. O meio físico pode assumir
muitas formas e formas e não precisa ser do mesmo
tipo para cada par transmissor-receptor ao longo do caminho. Exemplos de mídia física incluem fio de cobre de par trançado,
cabo coaxial, cabo de fibra ótica multimodo, espectro de rádio terrestre e espectro de rádio por satélite. A mídia física se
enquadra em duas categorias: mídia guiada e mídia não guiada. com guia
mídia, as ondas são guiadas ao longo de um meio sólido, como um cabo de fibra ótica, um par trançado de cobre
fio ou um cabo coaxial. Com mídia não guiada, as ondas se propagam na atmosfera e no espaço sideral, como em uma LAN
sem fio ou em um canal de satélite digital.
Mas antes de entrarmos nas características dos vários tipos de mídia, vamos dizer algumas palavras sobre sua
custos. O custo real do link físico (fio de cobre, cabo de fibra ótica e assim por diante) costuma ser relativamente
menor em comparação com outros custos de rede. Em particular, o custo de mão-de-obra associado à instalação
do link físico podem ser ordens de grandeza superiores ao custo do material. Por esta razão,
muitos construtores instalam par trançado, fibra ótica e cabo coaxial em todos os cômodos de um prédio. Mesmo que apenas um
meio seja usado inicialmente, há uma boa chance de que outro meio possa ser usado em um futuro próximo e, portanto,
economiza-se dinheiro por não ter que colocar fios adicionais no futuro.
Fio de Cobre de Par Trançado
O meio de transmissão guiado mais barato e mais comumente usado é o fio de cobre de par trançado.
Por mais de cem anos tem sido usado por redes telefônicas. Na verdade, mais de 99% dos
conexões com fio do monofone para a central telefônica local usam fio de cobre de par trançado. A maioria de nós já viu par
trançado em nossas casas (ou nas de nossos pais ou avós!) e ambientes de trabalho. O par trançado consiste em dois fios de
cobre isolados, cada um com cerca de 1 mm de espessura, dispostos em um padrão espiral regular. Os fios são trançados
juntos para reduzir a interferência elétrica de pares semelhantes próximos. Normalmente, vários pares são agrupados em um
cabo envolvendo o
pares em um escudo protetor. Um par de fios constitui um único link de comunicação. Par trançado não blindado (UTP) é
comumente usado para redes de computadores dentro de um edifício, ou seja, para LANs. As taxas de dados para LANs que
usam par trançado atualmente variam de 10 Mbps a 10 Gbps. As taxas de dados que podem ser alcançadas dependem da
espessura do fio e da distância entre o transmissor e o receptor.
Quando a tecnologia de fibra óptica surgiu na década de 1980, muitas pessoas menosprezaram o par trançado por causa de sua
taxas de bits relativamente baixas. Algumas pessoas até achavam que a tecnologia de fibra ótica substituiria completamente
par trançado. Mas o par trançado não desistiu tão facilmente. Tecnologia moderna de par trançado, como categoria
6a, pode atingir taxas de dados de 10 Gbps para distâncias de até cem metros. No final, o par trançado emergiu como a
solução dominante para redes LAN de alta velocidade.
Conforme discutido anteriormente, o par trançado também é comumente usado para acesso residencial à Internet. Vimos
que a tecnologia de modem dial-up permite acesso a taxas de até 56 kbps em par trançado. Também vimos que
A tecnologia DSL (linha de assinante digital) permite que usuários residenciais acessem a Internet a dezenas de Mbps por
par trançado (quando os usuários moram perto do escritório central do ISP).
Cabo coaxial
Como o par trançado, o cabo coaxial consiste em dois condutores de cobre, mas os dois condutores são concêntricos em
vez de paralelos. Com esta construção e isolamento e blindagem especiais, o cabo coaxial pode
alcançar altas taxas de transmissão de dados. O cabo coaxial é bastante comum em sistemas de televisão a cabo. Como
vimos anteriormente, os sistemas de televisão a cabo foram recentemente acoplados a modems a cabo para fornecer
usuários residenciais com acesso à Internet a taxas de dezenas de Mbps. Na televisão a cabo e no acesso à Internet a
cabo, o transmissor muda o sinal digital para uma banda de frequência específica e o sinal analógico resultante é
enviado do transmissor para um ou mais receptores. O cabo coaxial pode ser usado como um meio compartilhado
guiado. Especificamente, vários sistemas finais podem ser conectados diretamente ao cabo, com cada um dos sistemas
finais recebendo tudo o que é enviado pelos outros sistemas finais.
Fibra ótica
Uma fibra óptica é um meio fino e flexível que conduz pulsos de luz, com cada pulso representando um
pedaço. Uma única fibra óptica pode suportar taxas de bits tremendas, até dezenas ou até centenas de gigabits por
segundo. Eles são imunes à interferência eletromagnética, têm atenuação de sinal muito baixa de até 100 quilômetros e
são muito difíceis de tocar. Essas características fizeram da fibra ótica o meio preferido de transmissão guiada de longa
distância, particularmente para links no exterior. Muitas das redes telefônicas de longa distância nos Estados Unidos e
em outros lugares agora usam fibra ótica exclusivamente. A fibra ótica também é predominante no backbone da
Internet. No entanto, o alto custo dos dispositivos ópticos - como
transmissores, receptores e comutadores—impediu sua implantação para transporte de curta distância, como em uma LAN
ou em casa em uma rede de acesso residencial. As velocidades de link padrão da operadora óptica (OC)
variam de 51,8 Mbps a 39,8 Gbps; essas especificações costumam ser chamadas de OC-n, em que a velocidade do link é
igual a n ÿ 51,8 Mbps. Os padrões em uso hoje incluem OC-1, OC-3, OC-12, OC-24, OC-48, OC 96, OC-192, OC-768.
[Mukherjee 2006, Ramaswami 2010] fornecem cobertura de vários aspectos da rede óptica.
Canais de Rádio Terrestre
Os canais de rádio transportam sinais no espectro eletromagnético. Eles são um meio atraente porque
eles não requerem instalação de fio físico, podem penetrar paredes, fornecer conectividade a um usuário móvel,
e pode potencialmente transportar um sinal por longas distâncias. As características de um canal de rádio dependem
significativamente do ambiente de propagação e da distância pela qual um sinal deve ser transportado.
As considerações ambientais determinam a perda de caminho e o desvanecimento da sombra (que diminuem a força do
sinal à medida que o sinal viaja por uma distância e ao redor/através de objetos obstrutivos), desvanecimento de vários caminhos
(devido à reflexão de sinal de objetos interferentes) e interferência (devido a outras transmissões e
sinais eletromagnéticos).
Os canais de rádio terrestres podem ser classificados em três grandes grupos: os que operam em distâncias muito curtas (por
exemplo, com um ou dois metros); aquelas que operam em áreas locais, normalmente abrangendo de dez a algumas centenas de
metros; e as que atuam na área ampla, com dezenas de quilômetros. Dispositivos pessoais como fones de ouvido sem fio,
teclados e dispositivos médicos operam em distâncias curtas; o
as tecnologias de LAN sem fio descritas na Seção 1.2.1 usam canais de rádio de área local; as tecnologias de acesso celular usam
canais de rádio de área ampla. Discutiremos os canais de rádio em detalhes no Capítulo 7.
Canais de rádio por satélite
Um satélite de comunicação conecta dois ou mais transmissores/receptores de micro-ondas terrestres, conhecidos como
estações terrestres. O satélite recebe transmissões em uma banda de frequência, regenera o sinal
usando um repetidor (discutido abaixo) e transmite o sinal em outra frequência. Dois tipos de
satélites são usados em comunicações: satélites geoestacionários e satélites de órbita terrestre baixa (LEO) [Wiki
Satellite 2016].
Os satélites geoestacionários permanecem permanentemente acima do mesmo ponto na Terra. Essa presença estacionária é
alcançada colocando o satélite em órbita a 36.000 quilômetros acima da superfície da Terra. Esta enorme distância da estação
terrestre através do satélite de volta à estação terrestre introduz um atraso de propagação de sinal substancial de 280
milissegundos. No entanto, links de satélite, que podem operar em velocidades de centenas de Mbps, são frequentemente
usados em áreas sem acesso a DSL ou acesso à Internet via cabo.
Os satélites LEO são colocados muito mais perto da Terra e não permanecem permanentemente acima de um ponto na Terra.
Eles giram em torno da Terra (assim como a Lua) e podem se comunicar uns com os outros, bem como com as estações
terrestres. Para fornecer cobertura contínua a uma área, muitos satélites precisam ser colocados em órbita. Atualmente, existem
muitos sistemas de comunicação de baixa altitude em desenvolvimento. A tecnologia de satélite LEO pode ser usada para
acesso à Internet em algum momento no futuro.

1.3 O Núcleo da Rede
Tendo examinado a borda da Internet, vamos agora nos aprofundar mais no núcleo da rede - a malha
de comutadores de pacotes e enlaces que interligam os sistemas finais da Internet. A Figura 1.10 destaca o núcleo
da rede com linhas grossas e sombreadas.
Figura 1.10 O núcleo da rede
1.3.1 Comutação de Pacotes
Em uma aplicação de rede, os sistemas finais trocam mensagens entre si. As mensagens podem conter
qualquer coisa que o designer do aplicativo desejar. As mensagens podem executar uma função de controle (por exemplo, o “Hi”
mensagens em nosso exemplo de handshake na Figura 1.2) ou podem conter dados, como uma mensagem de e-mail, uma imagem
JPEG ou um arquivo de áudio MP3. Para enviar uma mensagem de um sistema final de origem para um sistema final de destino, a
origem divide as mensagens longas em pedaços menores de dados conhecidos como pacotes. Entre a origem e o destino,
cada pacote trafega por links de comunicação e comutadores de pacotes (para os quais existem dois tipos predominantes,
roteadores e comutadores da camada de enlace). Os pacotes são transmitidos por
cada link de comunicação a uma taxa igual à taxa de transmissão total do link. Portanto, se um sistema final de origem ou um
comutador de pacotes está enviando um pacote de L bits por um link com taxa de transmissão de R bits/s, o tempo para transmitir o
pacote é de L/ R segundos.
Transmissão Store-and-Forward
A maioria dos comutadores de pacotes usa transmissão de armazenar e encaminhar nas entradas dos links. Armazenar e encaminhar
transmissão significa que o comutador de pacotes deve receber o pacote inteiro antes de começar a transmitir o primeiro bit do pacote
para o link de saída. Para explorar a transmissão armazenar e encaminhar com mais detalhes, considere uma rede simples
que consiste em dois sistemas finais conectados por um único roteador, conforme mostrado
na Figura 1.11. Um roteador normalmente terá muitos links incidentes, já que seu trabalho é comutar um pacote de entrada
para um link de saída; neste exemplo simples, o roteador tem a tarefa bastante simples de transferir
um pacote de um link (de entrada) para o único outro link anexado. Neste exemplo, a fonte tem três
pacotes, cada um consistindo em L bits, para enviar ao destino. No instantâneo de tempo mostrado na Figura 1.11, a origem
transmitiu parte do pacote 1 e a frente do pacote 1 já chegou ao roteador. Como o roteador emprega armazenamento e
encaminhamento, neste instante, o roteador não pode transmitir os bits que recebeu; em vez disso, ele deve primeiro
armazenar em buffer (isto é, “armazenar”) os bits do pacote. Só depois do
roteador recebeu todos os bits do pacote, ele pode começar a transmitir (ou seja, “encaminhar”) o pacote para o link de saída.
Para entender melhor a transmissão armazenar e encaminhar, vamos agora calcular o tempo decorrido desde o momento em que a
origem começa a enviar o pacote até que o destino tenha recebido o pacote inteiro. (Aqui vamos ignorar o atraso de propagação -
o tempo que leva para os bits percorrerem
o fio próximo à velocidade da luz - que será discutido na Seção 1.4.) A fonte começa a transmitir no tempo 0; no tempo L/R
segundos, a fonte transmitiu todo o pacote e todo o
o pacote foi recebido e armazenado no roteador (já que não há atraso de propagação). No tempo L/R segundos, uma vez que o
roteador acabou de receber o pacote inteiro, ele pode começar a transmitir o pacote para o
link de saída para o destino; no tempo 2L/R, o roteador transmitiu todo o pacote e o
todo o pacote foi recebido pelo destino. Assim, o atraso total é 2L/R. Se o
Figura 1.11 Comutação de pacotes de armazenamento e encaminhamento
em vez disso, comuta os bits encaminhados assim que eles chegam (sem primeiro receber o pacote inteiro), então o
o atraso total seria L/R , pois os bits não são retidos no roteador. Mas, como discutiremos na Seção 1.4, os roteadores precisam
receber, armazenar e processar todo o pacote antes de encaminhá-lo.
Agora vamos calcular o tempo que decorre desde que a fonte começa a enviar o primeiro pacote
até que o destino tenha recebido todos os três pacotes. Como antes, no tempo L/ R, o roteador começa a encaminhar
o primeiro pacote. Mas também no tempo L/R a fonte começará a enviar o segundo pacote, pois acabou de enviar o primeiro pacote
inteiro. Assim, no tempo 2L/R, o destino recebeu o primeiro pacote e o roteador recebeu o segundo pacote. Da mesma forma, no tempo
3L/R, o destino recebeu os dois primeiros pacotes e o roteador recebeu o terceiro pacote. Finalmente, no tempo 4L/R, o destino recebeu
todos os três pacotes!
Vamos agora considerar o caso geral de envio de um pacote da origem ao destino por um caminho
consistindo em N links, cada um com taxa R (portanto, existem N-1 roteadores entre a origem e o destino).
Aplicando a mesma lógica acima, vemos que o atraso fim-a-fim é:
de ponta a ponta = NLR (1.1)
Agora você pode tentar determinar qual seria o atraso para P pacotes enviados por uma série de N links.
Atrasos na fila e perda de pacotes
Cada switch de pacote tem vários links anexados a ele. Para cada link anexado, o comutador de pacotes tem um
buffer de saída (também chamado de fila de saída), que armazena os pacotes que o roteador está prestes a enviar para esse link. Os
buffers de saída desempenham um papel fundamental na comutação de pacotes. Se um pacote que chega precisa ser
transmitido para um link, mas encontra o link ocupado com a transmissão de outro pacote, o pacote que chega deve esperar no buffer de
saída. Assim, além dos atrasos de armazenamento e encaminhamento, os pacotes sofrem atrasos de enfileiramento do buffer de
saída. Esses atrasos são variáveis e dependem do nível de congestionamento na rede.

Como a quantidade de espaço do buffer é finita, um
Figura 1.12 Comutação de pacotes
O pacote que chega pode descobrir que o buffer está completamente cheio com outros pacotes aguardando transmissão. Nesse caso,
ocorrerá perda de pacotes - o pacote que chega ou um dos pacotes já enfileirados será descartado.
A Figura 1.12 ilustra uma rede simples de comutação de pacotes. Como na Figura 1.11, os pacotes são representados por placas
tridimensionais. A largura de um slab representa o número de bits no pacote. Nesta figura, todos os pacotes têm a mesma largura e,
portanto, o mesmo comprimento. Suponha que os hosts A e B estejam enviando pacotes para o host E. Os hosts A e B primeiro
enviam seus pacotes por links Ethernet de 100 Mbps para o primeiro roteador. O roteador então direciona esses pacotes para o link
de 15 Mbps. Se, durante um curto intervalo de tempo, a taxa de chegada de pacotes ao roteador (quando convertidos em bits por segundo)
exceder 15 Mbps, ocorrerá congestionamento no roteador à medida que os pacotes enfileirarem-se no buffer de saída do link antes de
serem transmitidos para o link.
Por exemplo, se os hosts A e B enviarem, cada um, uma rajada de cinco pacotes consecutivos ao mesmo tempo, a maioria desses
pacotes passará algum tempo esperando na fila. A situação é, de facto, inteiramente
análoga a muitas situações do dia-a-dia - por exemplo, quando esperamos na fila por um caixa de banco ou esperamos
frente a um pedágio. Examinaremos esse atraso de fila com mais detalhes na Seção 1.4.
Tabelas de encaminhamento e protocolos de roteamento
Anteriormente, dissemos que um roteador pega um pacote que chega em um de seus links de comunicação anexados e encaminha
esse pacote para outro de seus links de comunicação anexados. Mas como o roteador determina para qual link ele deve encaminhar o
pacote? O encaminhamento de pacotes é realmente feito de maneiras diferentes em diferentes tipos de redes de computadores. Aqui,
descrevemos brevemente como isso é feito na Internet.

Na Internet, todo sistema final tem um endereço chamado endereço IP. Quando um sistema final de origem deseja enviar um
pacote para um sistema final de destino, a origem inclui o endereço IP do destino no cabeçalho do pacote. Assim como os endereços
postais, esse endereço tem uma estrutura hierárquica. Quando um pacote chega a um roteador na rede, o roteador examina uma
parte do endereço de destino do pacote e o encaminha para um roteador adjacente. Mais especificamente, cada roteador tem uma
tabela de encaminhamento que mapeia os endereços de destino (ou partes dos endereços de destino) para os links de saída
desse roteador.
Quando um pacote chega a um roteador, o roteador examina o endereço e procura em sua tabela de encaminhamento,
usando este endereço de destino, para encontrar o link de saída apropriado. O roteador então direciona o pacote
para este link de saída.
O processo de roteamento de ponta a ponta é análogo a um motorista de carro que não usa mapas, mas prefere pedir informações.
Por exemplo, suponha que Joe esteja dirigindo da Filadélfia para a 156 Lakeside Drive em Orlando, Flórida. Joe primeiro dirige
até o posto de gasolina de seu bairro e pergunta como chegar ao 156 Lakeside.
Dirija em Orlando, Flórida. O atendente do posto de gasolina extrai a parte da Flórida do endereço e diz
Joe que ele precisa entrar na rodovia interestadual I-95 South, que tem uma entrada logo ao lado do posto de gasolina. Ele também
diz a Joe que, assim que entrar na Flórida, ele deve perguntar a outra pessoa lá. Joe então pega a I-95 South até chegar a
Jacksonville, Flórida, quando pede informações a outro atendente de posto de gasolina. O atendente extrai a parte de
Orlando do endereço e diz a Joe que ele deve continuar na I-95 até Daytona Beach e depois perguntar a outra pessoa. Em Daytona
Beach, outro atendente de posto de gasolina também extrai a parte de Orlando do endereço e diz a Joe que ele deve pegar a I-4
diretamente para Orlando. Joe pega a I-4 e desce na saída de Orlando. Joe vai até outro atendente de posto de gasolina e, desta
vez, o atendente extrai a parte do endereço de Lakeside Drive e diz a Joe a estrada que ele deve seguir para chegar a
Lakeside Drive. Assim que Joe chega à Lakeside Drive, ele pergunta a uma criança em um
bicicleta como chegar ao seu destino. O garoto extrai a parte 156 do endereço e aponta para a casa. Joe finalmente chega ao
seu destino final. Na analogia acima, os frentistas de postos de gasolina e as crianças em bicicletas são análogos aos roteadores.
Acabamos de aprender que um roteador usa o endereço de destino de um pacote para indexar uma tabela de
encaminhamento e determinar o link de saída apropriado. Mas essa declaração levanta ainda outra questão: como as
tabelas de encaminhamento são definidas? Eles são configurados manualmente em cada roteador ou a Internet
usar um procedimento mais automatizado? Essa questão será estudada em profundidade no Capítulo 5. Mas, para abrir seu
apetite aqui, observaremos agora que a Internet possui vários protocolos de roteamento especiais que são usados para definir
automaticamente as tabelas de encaminhamento. Um protocolo de roteamento pode, por exemplo, determinar o menor
caminho de cada roteador para cada destino e use os resultados do caminho mais curto para configurar o encaminhamento
tabelas nos roteadores.
Como você realmente gostaria de ver a rota de ponta a ponta que os pacotes seguem na Internet? Nós agora convidamos
você pode sujar as mãos interagindo com o programa Trace-route. Basta visitar o site
www.traceroute.org, escolha uma fonte em um determinado país e trace a rota dessa fonte até seu computador. (Para uma
discussão sobre Traceroute, consulte a Seção 1.4.)

1.3.2 Comutação do Circuito
Existem duas abordagens fundamentais para mover dados através de uma rede de links e switches: comutação de circuitos e
comutação de pacotes. Tendo abordado as redes de comutação de pacotes na subseção anterior, agora voltamos
nossa atenção para as redes de comutação de circuitos.
Em redes comutadas por circuitos, os recursos necessários ao longo de um caminho (buffers, taxa de transmissão do link) para
fornecem comunicação entre os sistemas finais são reservados para a duração da comunicação
sessão entre os sistemas finais. Em redes de comutação de pacotes, esses recursos não são reservados; as mensagens de uma
sessão usam os recursos sob demanda e, como consequência, podem ter que esperar (ou seja, fila) para acessar um link de
comunicação. Como uma analogia simples, considere dois restaurantes, um que
exige reservas e outro que não exige nem aceita reservas. Para o restaurante que exige reservas, temos que passar pelo
incômodo de ligar antes de sair de casa.
Mas quando chegamos ao restaurante podemos, em princípio, sentar-nos imediatamente e pedir a nossa refeição.
Para o restaurante que não exige reservas, não precisamos nos preocupar em reservar mesa. Mas
quando chegamos ao restaurante, podemos ter que esperar por uma mesa antes de nos sentarmos.
As redes telefônicas tradicionais são exemplos de redes de comutação de circuitos. Considere o que acontece quando uma
pessoa deseja enviar informações (voz ou fax) para outra por meio de uma rede telefônica.
Antes que o remetente possa enviar as informações, a rede deve estabelecer uma conexão entre o
remetente e o destinatário. Esta é uma conexão genuína para a qual os switches no caminho entre o remetente e o destinatário
mantêm o estado de conexão para essa conexão. No jargão da telefonia, isso
conexão é chamada de circuito. Quando a rede estabelece o circuito, ela também reserva uma constante
taxa de transmissão nos links da rede (representando uma fração da capacidade de transmissão de cada link) durante a conexão.
Uma vez que uma determinada taxa de transmissão foi reservada para este remetente para
conexão do receptor, o remetente pode transferir os dados para o destinatário na taxa constante garantida .
A Figura 1.13 ilustra uma rede de comutação de circuitos. Nesta rede, os quatro switches do circuito são interligados por
quatro links. Cada um desses links possui quatro circuitos, de modo que cada link pode suportar quatro conexões simultâneas.
Os hosts (por exemplo, PCs e estações de trabalho) são conectados diretamente
a um dos interruptores. Quando dois hosts desejam se comunicar, a rede estabelece uma extremidade dedicada
conexão ponta a ponta entre os dois hosts. Assim, para que o Host A se comunique com o Host B, o
rede deve primeiro reservar um circuito em cada um dos dois links. Neste exemplo, o dedicado fim-a-fim
conexão usa o segundo circuito no primeiro link e o quarto circuito no segundo link. Porque cada um
link tem quatro circuitos, para cada link usado pela conexão ponta a ponta, a conexão recebe um quarto de
a capacidade total de transmissão do link durante a conexão. Assim, por exemplo, se cada link
entre comutadores adjacentes tem uma taxa de transmissão de 1 Mbps, então cada comutador de circuito ponta a ponta
conexão obtém 250 kbps de taxa de transmissão dedicada.

Figura 1.13 Uma rede simples de comutação de circuitos composta por quatro switches e quatro links
Em contraste, considere o que acontece quando um host deseja enviar um pacote para outro host por meio de uma
rede de comutação de pacotes, como a Internet. Assim como na comutação de circuitos, o pacote é transmitido por uma série
de links de comunicação. Mas, diferente da comutação de circuitos, o pacote é enviado para a rede sem reservar nenhum
recurso de link. Se um dos links estiver congestionado porque outros pacotes precisam ser transmitidos pelo link ao mesmo
tempo, o pacote terá que esperar em um buffer no
lado de envio do link de transmissão e sofre um atraso. A Internet faz o seu melhor esforço para entregar
pacotes em tempo hábil, mas não oferece nenhuma garantia.
Multiplexação em redes comutadas por circuito
Um circuito em um link é implementado com multiplexação por divisão de frequência (FDM) ou multiplexação por divisão
de tempo (TDM). Com o FDM, o espectro de frequência de um link é dividido entre as conexões estabelecidas no link.
Especificamente, o link dedica uma banda de frequência a cada conexão durante a conexão. Em redes telefônicas, esta banda
de frequência normalmente tem uma largura de 4 kHz
(ou seja, 4.000 hertz ou 4.000 ciclos por segundo). A largura da banda é chamada, não surpreendentemente, de
largura de banda. As estações de rádio FM também usam FDM para compartilhar o espectro de frequência entre 88 MHz e
108 MHz, com cada estação sendo alocada em uma banda de frequência específica.
Para um link TDM, o tempo é dividido em quadros de duração fixa e cada quadro é dividido em um tempo fixo.
número de intervalos de tempo. Quando a rede estabelece uma conexão através de um link, a rede dedica
um intervalo de tempo em cada quadro para esta conexão. Esses slots são dedicados para uso exclusivo dessa
conexão, com um time slot disponível para uso (em cada quadro) para transmitir os dados da conexão.
Figura 1.14
Com FDM, cada circuito obtém continuamente uma fração da largura de banda. Com o TDM, cada circuito obtém toda a largura
de banda periodicamente durante breves intervalos de tempo (ou seja, durante os slots).
A Figura 1.14 ilustra FDM e TDM para um link de rede específico com suporte para até quatro circuitos. Para FDM, o domínio da
frequência é segmentado em quatro bandas, cada uma com largura de banda de 4 kHz. Para TDM, o domínio do tempo
é segmentado em quadros, com quatro intervalos de tempo em cada quadro; cada circuito recebe o mesmo slot dedicado nos
quadros TDM rotativos. Para TDM, a taxa de transmissão de um circuito é igual à taxa de quadros multiplicada pelo número
de bits em um slot. Por exemplo, se o link transmite 8.000 quadros por segundo e cada slot consiste em 8 bits, a taxa de
transmissão de cada circuito é de 64 kbps.
Os defensores da comutação de pacotes sempre argumentaram que a comutação de circuitos é um desperdício porque o
os circuitos dedicados ficam ociosos durante os períodos de silêncio. Por exemplo, quando uma pessoa em uma ligação
telefônica para de falar, os recursos ociosos da rede (faixas de frequência ou slots de tempo nos links ao longo da
rota da conexão) não podem ser utilizados por outras conexões em andamento. Outro exemplo de como esses
recursos podem ser subutilizados, considere um radiologista que usa uma rede de comutação de circuitos para acessar
remotamente uma série de radiografias. O radiologista estabelece uma ligação, solicita uma imagem, contempla o
imagem e, em seguida, solicita uma nova imagem. Os recursos de rede são alocados para a conexão, mas não são usados (ou
seja, são desperdiçados) durante os períodos de contemplação do radiologista. Proponentes da comutação de pacotes
também gosto de apontar que estabelecer circuitos de ponta a ponta e reservar capacidade de transmissão de ponta a
ponta é complicado e requer um software de sinalização complexo para coordenar a operação dos comutadores ao longo
do caminho de ponta a ponta.
Antes de terminarmos nossa discussão sobre comutação de circuitos, vamos trabalhar com um exemplo numérico que deve
lançar mais informações sobre o tema. Vamos considerar quanto tempo leva para enviar um arquivo de 640.000 bits do Host
A para o Host B em uma rede de comutação de circuitos. Suponha que todos os enlaces da rede usem TDM com 24 slots e
tenham uma taxa de bits de 1,536 Mbps. Suponha também que sejam necessários 500 ms para estabelecer um circuito de ponta
a ponta antes que o Host A possa começar a transmitir o arquivo. Quanto tempo leva para enviar o arquivo? Cada circuito
tem uma taxa de transmissão de (1,536 Mbps)/24=64 kbps, então leva (640.000 bits)/(64 kbps)=10 segundos para
transmitir o arquivo. A esses 10 segundos adicionamos o tempo de estabelecimento do circuito, dando 10,5 segundos para
enviar o arquivo. Observe que o tempo de transmissão é independente do número de links: O tempo de transmissão seria de
10 segundos se o circuito ponta a ponta passasse por um link ou cem links. (O real
atraso de ponta a ponta também inclui um atraso de propagação; consulte a Seção 1.4.)
Comutação de pacotes versus comutação de circuitos
Tendo descrito a comutação de circuitos e a comutação de pacotes, vamos comparar as duas. Os críticos da comutação de
pacotes frequentemente argumentam que a comutação de pacotes não é adequada para serviços em tempo real (por exemplo,
chamadas telefônicas e chamadas de videoconferência) por causa de seus atrasos de ponta a ponta variáveis e imprevisíveis (devido
principalmente a atrasos de fila variáveis e imprevisíveis). ). Os defensores da comutação de pacotes argumentam que (1) ela oferece
melhor compartilhamento da capacidade de transmissão do que a comutação de circuitos e (2) é mais simples, mais
eficiente e menos dispendioso de implementar do que a comutação de circuitos. Uma discussão interessante sobre pacotes
comutação versus comutação de circuitos é [Molinero-Fernandez 2002]. De um modo geral, as pessoas que não gostam de se
preocupar com reservas em restaurantes preferem a comutação de pacotes à comutação de circuitos.
Por que a comutação de pacotes é mais eficiente? Vejamos um exemplo simples. Suponha que os usuários compartilhem um link de
1 Mbps. Suponha também que cada usuário alterne entre períodos de atividade, quando um usuário gera dados a uma taxa constante
de 100 kbps, e períodos de inatividade, quando um usuário não gera dados. Suponha ainda que um usuário esteja ativo apenas 10%
do tempo (e esteja bebendo café durante os 90 restantes).
por cento do tempo). Com a comutação de circuitos, 100 kbps devem ser reservados para cada usuário o tempo todo. Por
exemplo, com TDM comutado por circuito, se um quadro de um segundo for dividido em 10 intervalos de tempo de 100 ms cada,
cada usuário receberá um intervalo de tempo por quadro.
Assim, o link comutado por circuito pode suportar apenas 10 (=1 Mbps/100 kbps) usuários simultâneos. Com a comutação de pacotes,
a probabilidade de um usuário específico estar ativo é 0,1 (ou seja, 10%). Se houver 35 usuários, a probabilidade de haver 11 ou
mais usuários ativos simultaneamente é de aproximadamente 0,0004.
(O Problema P8 do dever de casa descreve como essa probabilidade é obtida.) Quando há 10 ou menos usuários ativos
simultaneamente (o que acontece com probabilidade 0,9996), a taxa agregada de chegada de dados é
menor ou igual a 1 Mbps, a taxa de saída do link. Assim, quando há 10 ou menos usuários ativos, os pacotes dos usuários fluem
através do link essencialmente sem demora, como é o caso da comutação de circuitos. Quando
houver mais de 10 usuários ativos simultaneamente, então a taxa agregada de chegada de pacotes excede a capacidade de saída
do link e a fila de saída começará a crescer. (Ele continua a crescer até que a taxa de entrada agregada caia abaixo de 1 Mbps,
ponto em que a fila começará a diminuir de comprimento.)
Porque a probabilidade de ter mais de 10 usuários ativos simultaneamente é minúscula neste
Por exemplo, a comutação de pacotes fornece essencialmente o mesmo desempenho que a comutação de circuitos, mas
enquanto permite mais de três vezes o número de usuários.
Vamos agora considerar um segundo exemplo simples. Suponha que haja 10 usuários e que um usuário de repente
gera mil pacotes de 1.000 bits, enquanto outros usuários permanecem inativos e não geram
pacotes. Na comutação de circuito TDM com 10 slots por quadro e cada slot composto por 1.000 bits, o usuário ativo pode usar
apenas seu intervalo de tempo por quadro para transmitir dados, enquanto os nove slots restantes
em cada quadro permanecem ociosos. Serão 10 segundos antes que todos os um milhão de bits de dados do usuário ativo tenham
sido transmitido. No caso de comutação de pacotes, o usuário ativo pode enviar continuamente seus pacotes na taxa de enlace total
de 1 Mbps, desde que não haja outros usuários gerando pacotes que precisem ser multiplexados com os pacotes do
usuário ativo. Neste caso, todos os dados do usuário ativo serão transmitidos
dentro de 1 segundo.
Os exemplos acima ilustram duas maneiras pelas quais o desempenho da comutação de pacotes pode ser superior ao da comutação
de circuitos. Eles também destacam a diferença crucial entre as duas formas de compartilhar a taxa de transmissão de um link
entre vários fluxos de dados. A comutação de circuito pré-aloca o uso do
link de transmissão, independentemente da demanda, com tempo de link alocado, mas desnecessário, sem uso. Pacote
a comutação, por outro lado, aloca o uso do link sob demanda. A capacidade de transmissão do link será compartilhada pacote a
pacote apenas entre os usuários que possuem pacotes que precisam ser transmitidos
a ligação.
Embora a comutação de pacotes e a comutação de circuitos sejam predominantes nas telecomunicações atuais
redes, a tendência certamente foi na direção da comutação de pacotes. Mesmo muitos dos circuitos de hoje
as redes telefônicas comutadas estão migrando lentamente para a comutação de pacotes. Em particular, as redes telefônicas
costumam usar comutação de pacotes para a dispendiosa porção internacional de uma chamada telefônica.
1.3.3 Uma rede de redes
Vimos anteriormente que os sistemas finais (PCs, smartphones, servidores Web, servidores de e-mail e assim por diante) se
conectam à Internet por meio de um ISP de acesso. O ISP de acesso pode fornecer conectividade com ou sem fio, usando uma
variedade de tecnologias de acesso, incluindo DSL, cabo, FTTH, Wi-Fi e celular. Observe que o ISP de acesso não precisa ser
uma empresa de telecomunicações ou cabo; em vez disso, pode ser, por exemplo, uma universidade
(fornecendo acesso à Internet para alunos, funcionários e professores) ou uma empresa (fornecendo acesso para seus
funcionários). Mas conectar usuários finais e provedores de conteúdo a um ISP de acesso é apenas uma pequena parte da solução do
quebra-cabeça de conectar os bilhões de sistemas finais que compõem a Internet. Para completar isso
quebra-cabeça, os próprios ISPs de acesso devem estar interligados. Isso é feito criando uma rede de redes — entender essa
frase é a chave para entender a Internet.
Ao longo dos anos, a rede de redes que forma a Internet evoluiu para uma estrutura muito complexa. Grande parte dessa
evolução é impulsionada pela economia e pela política nacional, e não por considerações de desempenho. Para entender a estrutura
de rede da Internet de hoje, vamos construir gradualmente uma série de estruturas de rede, com cada nova estrutura sendo uma
melhor aproximação do complexo
Internet que temos hoje. Lembre-se que o objetivo maior é interligar os ISPs de acesso para que
todos os sistemas finais podem enviar pacotes entre si. Uma abordagem ingênua seria fazer com que cada acesso
O ISP conecta-se diretamente com todos os outros ISP de acesso. Esse design de malha é, obviamente, muito caro para os ISPs de
acesso, pois exigiria que cada ISP de acesso tivesse um link de comunicação separado para cada um dos
as centenas de milhares de outros ISPs de acesso em todo o mundo.
Nossa primeira estrutura de rede, Network Structure 1, interconecta todos os ISPs de acesso com um único
ISP de trânsito. Nosso ISP de trânsito global (imaginário) é uma rede de roteadores e links de comunicação que não apenas abrange o
globo, mas também possui pelo menos um roteador perto de cada uma das centenas de milhares de acessos
ISP. Obviamente, seria muito caro para o ISP global construir uma rede tão extensa. Para ser rentável, naturalmente cobraria cada um
dos ISPs de acesso pela conectividade, com o preço refletindo (mas não necessariamente diretamente proporcional) a quantidade de tráfego
que um ISP de acesso troca com o ISP global. Uma vez que o ISP de acesso paga o ISP de trânsito global, o ISP de acesso é
considerado um cliente e o ISP de trânsito global é considerado um provedor.
Agora, se alguma empresa constrói e opera um ISP de trânsito global que seja lucrativo, então é natural que outras empresas construam
seus próprios ISPs de trânsito global e concorram com o ISP de trânsito global original.
Isso leva à Estrutura de Rede 2, que consiste nas centenas de milhares de ISPs de acesso e
vários ISPs de trânsito global. Os ISPs de acesso certamente preferem a Estrutura de rede 2 à Estrutura de rede 1, pois agora
podem escolher entre os provedores de trânsito globais concorrentes em função de seus preços e serviços. Observe, no entanto, que os
próprios ISPs de trânsito global devem se interconectar: Caso contrário, os ISPs de acesso conectados a um dos provedores de trânsito
global não seriam capazes de se comunicar com os ISPs de acesso conectados a outros provedores de trânsito global.
A estrutura de rede 2, recém descrita, é uma hierarquia de dois níveis com provedores de trânsito global residindo no
camada superior e ISPs de acesso na camada inferior. Isso pressupõe que os ISPs de trânsito global não são apenas capazes de se aproximar
de cada ISP de acesso, mas também consideram economicamente desejável fazê-lo. Na realidade, embora alguns ISPs tenham uma
cobertura global impressionante e se conectem diretamente com muitos provedores de acesso
ISPs, nenhum ISP tem presença em todas as cidades do mundo. Em vez disso, em qualquer região, pode haver um ISP regional ao qual
os ISPs de acesso da região se conectam. Cada ISP regional então se conecta a
ISPs de nível 1. Os ISPs Tier-1 são semelhantes ao nosso (imaginário) ISP de trânsito global; mas os ISPs de nível 1, que realmente
existem, não estão presentes em todas as cidades do mundo. Há aproximadamente uma dúzia de ISPs de nível 1,
incluindo Level 3 Communications, AT&T, Sprint e NTT. Curiosamente, nenhum grupo sanciona oficialmente
status de nível 1; como diz o ditado - se você tiver que perguntar se é membro de um grupo, provavelmente não é.
Voltando a essa rede de redes, não apenas existem vários ISPs de nível 1 concorrentes, mas também vários ISPs regionais concorrentes
em uma região. Nessa hierarquia, cada ISP de acesso paga ao ISP regional ao qual se conecta, e cada ISP regional paga ao ISP de nível
1 ao qual se conecta. (Um ISP de acesso
também pode se conectar diretamente a um ISP de nível 1, caso em que paga o ISP de nível 1). Assim, há cliente
relação de provedor em cada nível da hierarquia. Observe que os ISPs de nível 1 não pagam ninguém, pois estão no topo da hierarquia. Para
complicar ainda mais as coisas, em algumas regiões, pode haver um ISP regional maior (possivelmente abrangendo um país inteiro) ao
qual os ISPs regionais menores nessa região
conectar; o ISP regional maior então se conecta a um ISP de nível 1. Por exemplo, na China, há acesso
ISPs em cada cidade, que se conectam a ISPs provinciais, que por sua vez se conectam a ISPs nacionais, que finalmente
conectar-se a ISPs de nível 1 [Tian 2012]. Referimo-nos a essa hierarquia multicamada, que ainda é apenas uma estrutura grosseira
aproximação da Internet de hoje, como Estrutura de Rede 3.
Para construir uma rede que se pareça mais com a Internet de hoje, devemos adicionar pontos de presença
(PoPs), multi-homing, peering e pontos de troca de Internet (IXPs) para a rede hierárquica
Estrutura 3. Os PoPs existem em todos os níveis da hierarquia, exceto no nível inferior (provedor de acesso). Um PoP é
simplesmente um grupo de um ou mais roteadores (no mesmo local) na rede do provedor onde os ISPs do cliente podem
se conectar ao ISP do provedor. Para que uma rede de cliente se conecte ao PoP de um provedor, ela pode alugar um link
de alta velocidade de um provedor de telecomunicações terceirizado para conectar diretamente um de seus roteadores
a um roteador no PoP. Qualquer ISP (exceto para ISPs de nível 1) pode optar por multi-home, ou seja,
conectar-se a dois ou mais ISPs provedores. Assim, por exemplo, um ISP de acesso pode multi-home com dois
ISPs, ou pode ser multi-home com dois ISPs regionais e também com um ISP de nível 1. Da mesma forma, um ISP
regional pode ser multi-home com vários ISPs de nível 1. Quando um ISP faz multi-homes, ele pode continuar a enviar e
receber pacotes na Internet mesmo se um de seus provedores apresentar uma falha.
Como acabamos de aprender, os ISPs clientes pagam seus provedores ISPs para obter interconectividade global com a
Internet. O valor que um ISP de cliente paga a um ISP de provedor reflete a quantidade de tráfego que ele troca com o
provedor. Para reduzir esses custos, um par de ISPs próximos no mesmo nível da hierarquia pode fazer peering, ou seja,
eles podem conectar suas redes diretamente entre si para que todo o tráfego entre eles passe pelo
conexão direta em vez de intermediários upstream. Quando dois ISPs fazem peering, geralmente é livre de liquidação,
ou seja, nenhum ISP paga o outro. Conforme observado anteriormente, os ISPs de nível 1 também fazem peering uns
com os outros, sem liquidação. Para uma discussão legível sobre peering e relacionamentos cliente-provedor, consulte
[Van der Berg 2008]. Nessa mesma linha, uma empresa terceirizada pode criar um Internet Exchange Point (IXP), que é
um ponto de encontro onde vários ISPs podem se conectar. Um IXP normalmente está em um
edifício autônomo com seus próprios interruptores [Ager 2012]. Existem mais de 400 IXPs na Internet hoje
[Lista IXP 2016]. Referimo-nos a esse ecossistema — composto por ISPs de acesso, ISPs regionais, ISPs de nível 1,
PoPs, multihoming, peering e IXPs — como Estrutura de rede 4.
Finalmente chegamos à Estrutura de Rede 5, que descreve a Internet de hoje. A Estrutura de rede 5, ilustrada na Figura
1.15, se baseia na Estrutura de rede 4 adicionando redes de provedores de conteúdo.

Atualmente, o Google é um dos principais exemplos dessa rede de provedores de conteúdo. No momento em que este livro
foi escrito, estima-se que o Google tenha de 50 a 100 centros de dados distribuídos na América do Norte, Europa, Ásia,
América do Sul e Austrália. Alguns desses data centers abrigam mais de cem mil servidores, enquanto outros data centers
são menores, acomodando apenas centenas de servidores. Os centros de dados do Google são todos
interconectados por meio da rede privada TCP/IP do Google, que se estende por todo o mundo, mas ainda assim
separado da Internet pública. É importante ressaltar que a rede privada do Google transporta apenas tráfego de/para
servidores do Google. Conforme mostrado na Figura 1.15, a rede privada do Google tenta “contornar” os níveis superiores
da Internet fazendo peering (sem acordo) com ISPs de nível inferior, conectando-se diretamente com
eles ou conectando-se com eles em IXPs [Labovitz 2010]. No entanto, como muitos ISPs de acesso ainda só podem ser
alcançados por meio de redes de nível 1, a rede do Google também se conecta ao nível 1
ISPs e paga a esses ISPs pelo tráfego que troca com eles. Ao criar sua própria rede, um conteúdo
O provedor não apenas reduz seus pagamentos para ISPs de nível superior, mas também tem maior controle de como seus
serviços são entregues aos usuários finais. A infra-estrutura de rede do Google é descrita em maior
detalhes na Seção 2.6.
Em resumo, a Internet de hoje — uma rede de redes — é complexa, consistindo em cerca de uma dúzia de ISPs de nível 1 e centenas
de milhares de ISPs de nível inferior. Os ISPs são diversos em sua cobertura, com alguns
abrangendo vários continentes e oceanos, e outros limitados a regiões geográficas estreitas. Os ISPs de nível inferior se conectam aos
ISPs de nível superior e os ISPs de nível superior se interconectam entre si. Usuários e provedores de conteúdo são clientes de ISPs de
nível inferior, e ISPs de nível inferior são clientes de nível superior
ISP. Nos últimos anos, os principais provedores de conteúdo também criaram suas próprias redes e se conectaram
diretamente em ISPs de nível inferior sempre que possível.
Figura 1.15 Interconexão de ISPs

1.4 Atraso, perda e taxa de transferência em redes de comutação de pacotes
Na Seção 1.1 , dissemos que a Internet pode ser vista como uma infraestrutura que fornece serviços para aplicativos distribuídos
executados em sistemas finais. Idealmente, gostaríamos que os serviços de Internet fossem capazes de mover tantos dados quanto
quiséssemos entre quaisquer dois sistemas finais, instantaneamente, sem qualquer perda de
dados. Infelizmente, este é um objetivo elevado, que é inatingível na realidade. Em vez disso, as redes de computadores
necessariamente restringem a taxa de transferência (a quantidade de dados por segundo que pode ser transferida) entre os sistemas finais,
introduzem atrasos entre os sistemas finais e podem, na verdade, perder pacotes. Por um lado, é lamentável que as leis físicas
da realidade introduzam atrasos e perdas, bem como restrinjam o rendimento. Por outro lado, como as redes de computadores
têm esses problemas, há muitas questões fascinantes sobre como lidar com os problemas - questões mais do que suficientes para
preencher um curso sobre redes de computadores e motivar milhares de teses de doutorado! Nesta seção, começaremos a examinar
e quantificar atrasos, perdas e
throughput em redes de computadores.
1.4.1 Visão geral do atraso em redes de comutação de pacotes
Lembre-se de que um pacote começa em um host (a origem), passa por uma série de roteadores e termina sua jornada em
outro host (o destino). À medida que um pacote viaja de um nó (host ou roteador) para o
nó subseqüente (host ou roteador) ao longo desse caminho, o pacote sofre vários tipos de atrasos em cada nó ao longo do caminho.
O mais importante desses atrasos são os atrasos de processamento nodal, filas
atraso, atraso de transmissão e atraso de propagação; juntos, esses atrasos se acumulam para dar um atraso nodal total. O
desempenho de muitos aplicativos da Internet — como pesquisa, navegação na Web, e-mail, mapas, mensagens instantâneas e
voz sobre IP — é bastante afetado pelos atrasos da rede. Para adquirir
uma compreensão profunda de comutação de pacotes e redes de computadores, devemos entender a natureza e
importância desses atrasos.
Tipos de atraso
Vamos explorar esses atrasos no contexto da Figura 1.16. Como parte de sua rota ponta a ponta entre a origem e o destino, um
pacote é enviado do nó upstream através do roteador A para o roteador B. Nosso objetivo é caracterizar o atraso nodal no
roteador A. Observe que o roteador A tem um link de saída levando ao roteador B.
Esse link é precedido por uma fila (também conhecida como buffer). Quando o pacote chega ao roteador A do nó upstream, o
roteador A examina o cabeçalho do pacote para determinar o link de saída apropriado para
o pacote e, em seguida, direciona o pacote para este link. Neste exemplo, o link de saída do pacote é aquele que leva ao roteador B.
Um pacote pode ser transmitido em um link somente se não houver outro pacote no momento
sendo transmitido no link e se não houver nenhum outro pacote precedendo-o na fila; se o link for
Figura 1.16 O atraso nodal no roteador A
atualmente ocupado ou se houver outros pacotes já enfileirados para o link, o pacote recém-chegado entrará na fila.
Atraso de processamento
O tempo necessário para examinar o cabeçalho do pacote e determinar para onde direcionar o pacote faz parte do atraso
de processamento. O atraso de processamento também pode incluir outros fatores, como o tempo necessário para verificar
erros de nível de bit no pacote que ocorreram na transmissão dos bits do pacote do upstream
nó para o roteador A. Os atrasos de processamento em roteadores de alta velocidade geralmente são da ordem de
microssegundos ou menos. Após esse processamento nodal, o roteador direciona o pacote para a fila que antecede o link para
roteador B. (No Capítulo 4 estudaremos os detalhes de como um roteador opera.)
Atraso na Fila
Na fila, o pacote experimenta um atraso de fila enquanto espera para ser transmitido no link. A duração do atraso na fila
de um pacote específico dependerá do número de pacotes que chegaram antes
que estão na fila e aguardando transmissão no link. Se a fila estiver vazia e nenhum outro pacote estiver sendo transmitido
no momento, o atraso de fila do nosso pacote será zero. Por outro lado, se o tráfego for intenso e muitos outros pacotes
também estiverem esperando para serem transmitidos, o atraso na fila será longo. Nós
veremos em breve que o número de pacotes que um pacote que chega pode esperar encontrar é uma função do
intensidade e natureza do tráfego que chega à fila. Na prática, os atrasos de enfileiramento podem ser da ordem
de microssegundos a milissegundos.
Atraso de Transmissão
Assumindo que os pacotes são transmitidos por ordem de chegada, como é comum em redes comutadas por pacotes,
nosso pacote pode ser transmitido somente após todos os pacotes que chegaram antes dele
foram transmitidos. Denotar o comprimento do pacote por L bits, e denotar a taxa de transmissão de
o link do roteador A para o roteador B por R bits/s. Por exemplo, para um link Ethernet de 10 Mbps, a taxa é R=10 Mbps; R=100
Mbps. Ethernet de 100 Mbps, a taxa é a quantidade de O atraso de transmissão é L/ R. Para um link
tempo necessária para empurrar (isto é, transmitir) todos os bits do pacote para o link.
Os atrasos de transmissão são tipicamente da ordem de microssegundos a milissegundos na prática.
Atraso de propagação
Depois que um bit é inserido no link, ele precisa se propagar para o roteador B. O tempo necessário para se propagar desde o início
do link até o roteador B é o atraso de propagação. O bit se propaga na velocidade de propagação do link. A velocidade de
propagação depende do meio físico do link (isto é, fibra ótica, fio de cobre de par trançado e assim por diante) e está na faixa
de
2ÿ108 metros/seg a 3ÿ108 metros/seg
que é igual ou um pouco menor que a velocidade da luz. O atraso de propagação é a distância entre
dois roteadores divididos pela velocidade de propagação. Ou seja, o atraso de propagação é d/ s, onde d é a distância entre
o roteador A e o roteador B e s é a velocidade de propagação do link. Depois que o último bit do pacote se propaga para o nó B,
ele e todos os bits anteriores do pacote são armazenados no roteador B. Todo o processo continua com o roteador B agora
realizando o encaminhamento. Em redes de longa distância, os atrasos de propagação são da ordem de milissegundos.
Comparando o atraso de transmissão e propagação
Explorando o atraso de propagação e o atraso de transmissão
Os recém-chegados ao campo da rede de computadores às vezes têm dificuldade em entender a diferença entre atraso de
transmissão e atraso de propagação. A diferença é sutil, mas importante. O
atraso de transmissão é a quantidade de tempo necessária para o roteador enviar o pacote; é uma função do comprimento do pacote
e da taxa de transmissão do link, mas não tem nada a ver com a distância entre os dois roteadores. O atraso de propagação, por
outro lado, é o tempo que um bit leva para se propagar de um roteador para o próximo; é uma função da distância entre os dois
roteadores, mas nada tem a ver com o comprimento do pacote ou a taxa de transmissão do link.
Uma analogia pode esclarecer as noções de atraso de transmissão e propagação. Considere uma rodovia com
uma cabine de pedágio a cada 100 quilômetros, conforme Figura 1.17. Você pode pensar nos segmentos da rodovia
entre os pedágios como links e os pedágios como roteadores. Suponha que os carros trafeguem (ou seja, se propaguem) na rodovia a
uma velocidade de 100 km/h (ou seja, quando um carro sai de um pedágio, ele acelera instantaneamente para 100 km/h e
mantém essa velocidade entre os pedágios). Suponha que 10 carros, viajando juntos como uma caravana, sigam um ao outro em uma
ordem fixa. Você pode pensar em cada carro como um pedaço e na caravana como um pacote. Suponha também que cada
Figura 1.17 Analogia da caravana
serviços de pedágio (ou seja, transmite) um carro a uma taxa de um carro a cada 12 segundos e que é tarde da noite para que os carros
da caravana sejam os únicos carros na rodovia. Finalmente, suponha que sempre que o primeiro carro
da caravana chega a uma portagem, espera à entrada os outros nove carros chegarem e
alinhados atrás dele. (Assim, toda a caravana deve ser armazenada no pedágio antes de começar a ser encaminhada.) O tempo
necessário para o pedágio empurrar toda a caravana para a rodovia é
(10 carros)/(5 carros/minuto)=2 minutos . Este tempo é análogo ao atraso de transmissão em um roteador. O
O tempo necessário para um carro viajar da saída de um pedágio até o próximo é de 100 km/(100 km/hora) =
1 hora. Este tempo é análogo ao atraso de propagação. Portanto, o tempo de

quando a caravana é parada em frente a uma cabine de pedágio até que a caravana seja parada em frente à próxima cabine de pedágio
é a soma do atraso de transmissão e atraso de propagação - neste exemplo, 62 minutos.
Vamos explorar um pouco mais essa analogia. O que aconteceria se o tempo de atendimento no pedágio de uma caravana fosse
maior que o tempo que um carro leva para passar entre os pedágios? Por exemplo, suponha agora que os carros viajam a uma taxa
de 1.000 km/hora e o posto de pedágio atende os carros a uma taxa de um carro por minuto. Então, o atraso de viagem entre duas cabines
de pedágio é de 6 minutos e o tempo para servir uma caravana é de 10 minutos. Em
neste caso, os primeiros carros da caravana chegarão à segunda portagem antes dos últimos carros da caravana
caravana sai do primeiro pedágio. Essa situação também ocorre em redes de comutação de pacotes - os primeiros bits em uma
um pacote pode chegar a um roteador enquanto muitos dos bits restantes no pacote ainda estão esperando para serem
transmitidos pelo roteador anterior.
Se uma imagem fala mais que mil palavras, então uma animação deve falar mais que um milhão de palavras. O site deste livro fornece
um applet Java interativo que ilustra bem e contrasta o atraso de transmissão
e atraso de propagação. O leitor é altamente encorajado a visitar esse applet. [Smith 2009] também fornece uma discussão bastante
legível sobre propagação, enfileiramento e atrasos de transmissão.
Se deixarmostrans
dd, d proc fila
, , e d denotam o processamento, enfileiramento, transmissão e propagação
suporte
atrasos, então o atraso nodal total é dado por
dnodal=dproc+dqueue+dtrans+dprop
A contribuição desses componentes de atraso pode variar significativamente. Por exemplo, d podesuporte
ser insignificante (por
exemplo, alguns microssegundos) para um link conectando dois roteadores na mesma universidade
campus; no entanto, d ésuporte

centenas de milissegundos para dois roteadores interconectados por um geoestacionário
link de satélite e pode ser o termo dominante em d . Da mesma

nodal forma, d pode
trans variar de insignificante a
significativo. Sua contribuição é normalmente insignificante para taxas de transmissão de 10 Mbps e superiores
(por exemplo, para LANs); no entanto, pode levar centenas de milissegundos para grandes pacotes de Internet enviados por
links de modem dial-up de baixa velocidade. O atraso de procedimento , muitas vezes é insignificante; no entanto, fortemente
processamento d influencia o throughput máximo de um roteador, que é a taxa máxima na qual um roteador pode
encaminhar pacotes.
1.4.2 Atraso na Fila e Perda de Pacote
O componente mais complicado e interessante do atraso nodal é o atraso de fila, d . Na verdade, o atraso
fila na fila é tão
importante e interessante em redes de computadores que milhares de artigos e
numerosos livros foram escritos sobre isso [Bertsekas 1991; Daigle 1991; Kleinrock 1975, Kleinrock 1976; Ross 1995].
Damos aqui apenas uma discussão intuitiva e de alto nível sobre o atraso na fila; o leitor mais curioso pode querer
folhear alguns dos livros (ou até mesmo eventualmente escrever uma tese de doutorado sobre
o sujeito!). Ao contrário dos outros três atrasos (ou seja, d de proc , dtrans , e d ), o atraso na fila pode variar
suporte
pacote para pacote. Por exemplo, se 10 pacotes chegarem em uma fila vazia ao mesmo tempo, o primeiro
o pacote transmitido não sofrerá nenhum atraso de fila, enquanto o último pacote transmitido sofrerá um atraso de fila
relativamente grande (enquanto espera que os outros nove pacotes sejam transmitidos). Portanto, quando
caracterizando o atraso na fila, normalmente são usadas medidas estatísticas, como o atraso médio na fila, a variação
do atraso na fila e a probabilidade de que o atraso na fila exceda algum valor especificado.
Quando o atraso na fila é grande e quando é insignificante? A resposta a essa pergunta depende da taxa de chegada
do tráfego na fila, da taxa de transmissão do link e da natureza do tráfego que chega, ou seja, se o tráfego chega
periodicamente ou em rajadas. Para obter alguma percepção
aqui, vamos denotar a taxa média na qual os pacotes chegam à fila (a está em unidades de pacotes/s).
Lembre-se de que R é a taxa de transmissão; ou seja, é a taxa (em bits/s) na qual os bits são empurrados para fora do
fila. Suponha também, para simplificar, que todos os pacotes consistem em L bits. Então, a taxa média na qual os bits
chegam à fila é La bits/s. Por fim, suponha que a fila seja muito grande, de modo que possa conter
essencialmente um número infinito de bits. A razão La/ R, chamada de intensidade de tráfego, muitas vezes desempenha um papel
papel importante na estimativa da extensão do atraso na fila. Se La/ R > 1, então a taxa média na qual os bits chegam à
fila excede a taxa na qual os bits podem ser transmitidos da fila. Nisso
situação infeliz, a fila tenderá a aumentar sem limites e o atraso na fila se aproximará
infinidade! Portanto, uma das regras de ouro na engenharia de tráfego é: Projete seu sistema para que o tráfego
intensidade não é maior que 1.
Agora considere o caso La/ R ÿ 1. Aqui, a natureza do tráfego que chega impacta o atraso na fila. Por exemplo, se os pacotes
chegarem periodicamente — ou seja, um pacote chegar a cada segundo L/ R —, todos os pacotes chegarão a uma fila
vazia e não haverá atraso na fila. Por outro lado, se os pacotes chegarem em rajadas, mas periodicamente, pode haver um
atraso médio de enfileiramento significativo. Por exemplo, suponha
N pacotes chegam simultaneamente a cada (L/ R)N segundos. Então o primeiro pacote transmitido não tem atraso de fila; o
segundo pacote transmitido tem um atraso de fila de segundos L/ R ; e mais geralmente, o enésimo (nÿ1) pacote transmitido tem
um para você calcular o atraso médio de fila neste exemplo.
atraso de fila de L/ R segundos. Deixamos como exercício
Os dois exemplos de chegadas periódicas descritos acima são um pouco acadêmicos. Normalmente, a chegada
processo para uma fila é aleatório; ou seja, as chegadas não seguem nenhum padrão e os pacotes são espaçados por períodos
de tempo aleatórios. Neste caso mais realista, a quantidade La/ R geralmente não é suficiente para caracterizar completamente as
estatísticas de atraso de fila. No entanto, é útil para obter uma compreensão intuitiva
compreensão da extensão do atraso na fila. Em particular, se a intensidade do tráfego for próxima de zero, as chegadas de
pacotes serão poucas e distantes entre si e é improvável que um pacote que chegue encontre outro pacote na fila. Portanto, o
atraso médio de fila será próximo de zero. Por outro lado, quando o
a intensidade do tráfego for próxima de 1, haverá intervalos de tempo em que a taxa de chegada excederá a capacidade de
transmissão (devido a variações na taxa de chegada de pacotes), e uma fila se formará nesses períodos de tempo; quando
a taxa de chegada for menor que a capacidade de transmissão, o comprimento da fila diminuirá.
No entanto, à medida que a intensidade do tráfego se aproxima de 1, o comprimento médio da fila fica cada vez maior. O
A dependência qualitativa do atraso médio na fila com a intensidade do tráfego é mostrada na Figura 1.18.
Um aspecto importante da Figura 1.18 é o fato de que conforme a intensidade do tráfego se aproxima de 1, o atraso médio na
fila aumenta rapidamente. Um pequeno aumento percentual na intensidade resultará em um aumento percentual muito maior no
atraso. Talvez você tenha experimentado esse fenômeno na estrada. Se
você dirige regularmente em uma estrada normalmente congestionada, o fato de que a estrada é normalmente
Figura 1.18 Dependência do atraso médio na fila da intensidade do tráfego
congestionado significa que sua intensidade de tráfego é próxima a 1. Se algum evento causar um tráfego ainda ligeiramente maior que
quantidade normal de tráfego, os atrasos podem ser enormes.
Para realmente ter uma boa noção do que são os atrasos nas filas, você é encorajado a visitar novamente o site do livro didático, que
fornece um applet Java interativo para uma fila. Se você definir a chegada do pacote
taxa alta o suficiente para que a intensidade do tráfego exceda 1, você verá a fila aumentar lentamente com o tempo.
Perda de Pacote
Em nossas discussões acima, assumimos que a fila é capaz de conter um número infinito de pacotes. Na realidade, uma fila que precede
um link tem capacidade finita, embora a capacidade de enfileiramento dependa muito do projeto e do custo do roteador. Como a
capacidade da fila é finita, os atrasos dos pacotes realmente não se aproximam do infinito quando a intensidade do tráfego se aproxima de 1.
Em vez disso, um pacote pode chegar e encontrar uma fila cheia.
Sem lugar para armazenar tal pacote, um roteador descartará esse pacote; ou seja, o pacote será perdido. Este estouro em uma fila pode
ser visto novamente no applet Java para uma fila quando a intensidade do tráfego é maior
do que 1.
Do ponto de vista do sistema final, uma perda de pacote parecerá com um pacote que foi transmitido para o núcleo da rede, mas nunca
emergiu da rede no destino. A fração de pacotes perdidos aumenta à medida que a intensidade do tráfego aumenta. Portanto, o
desempenho em um nó geralmente é medido não apenas em termos de atraso, mas também em termos de probabilidade de perda de
pacotes. Como discutiremos nos capítulos subseqüentes, um pacote perdido pode ser retransmitido de ponta a ponta para garantir que
todos os dados sejam finalmente transferidos da origem para o destino.
1.4.3 Atraso ponta a ponta

Nossa discussão até este ponto se concentrou no atraso nodal, ou seja, o atraso em um único roteador. Vamos agora considerar o
atraso total da origem ao destino. Para entender esse conceito, suponha que haja
N-1 roteadores entre o host de origem e o host de destino. Suponhamos também, por enquanto, que
que a rede não está congestionada (para que os atrasos nas filas sejam insignificantes), o atraso de processamento em cada
roteador e no host de origem é d proc , a taxa de transmissão de cada roteador e do host de origem
é R bits/s e a propagação em cada link é d . Os atrasos nodais sesuporte

acumulam e fornecem um atraso de ponta a ponta,
dendÿend=N(dproc+dtrans+dprop) (1.2)
onde, novamente, onde L dtrans=L/R,

é o tamanho do pacote. Observe que a Equação 1.2 é uma generalização de
Equação 1.1, que não levou em conta os atrasos de processamento e propagação. Deixamos para você generalizar a Equação 1.2
para o caso de atrasos heterogêneos nos nós e para a presença de um atraso médio de fila em cada nó.
Traceroute
Usando o Traceroute para descobrir caminhos de rede e medir o atraso da rede
Para ter uma ideia prática do atraso de ponta a ponta em uma rede de computadores, podemos usar o programa Traceroute.
Traceroute é um programa simples que pode ser executado em qualquer host da Internet. Quando o usuário especifica um nome
de host de destino, o programa no host de origem envia vários pacotes especiais para esse destino. À medida que esses
pacotes avançam em direção ao destino, eles passam por uma série de roteadores. Quando um roteador recebe um desses
pacotes especiais, ele envia de volta à origem uma mensagem curta que contém o nome e o endereço do roteador.
Mais especificamente, suponha que existam N-1 roteadores entre a origem e o destino. Então o
a origem enviará N pacotes especiais para a rede, com cada pacote endereçado ao destino final. Esses N pacotes especiais
são marcados de 1 a N, com o primeiro pacote marcado como 1 e o último marcado como N. Quando o enésimo roteador recebe o
enésimo pacote marcado com n, o roteador não encaminha o pacote para seu destino, mas envia uma mensagem de volta à fonte.
Quando o
host de destino recebe o enésimo pacote, ele também retorna uma mensagem para a origem. A fonte registra o tempo
decorrido entre o envio de um pacote e o recebimento do correspondente
mensagem de retorno; ele também registra o nome e o endereço do roteador (ou do host de destino) que retorna a mensagem. Dessa
maneira, a origem pode reconstruir a rota seguida pelos pacotes que fluem da origem para o destino, e a origem pode determinar os
atrasos de ida e volta para todos os roteadores intervenientes.
Na verdade, o traceroute repete o experimento descrito três vezes, de modo que a origem realmente envia 3 • N pacotes ao destino.
O RFC 1393 descreve o Traceroute em detalhes.
Aqui está um exemplo da saída do programa Traceroute, onde a rota estava sendo traçada a partir do
host fonte gaia.cs.umass.edu (na Universidade de Massachusetts) para o host cis.poly.edu (na
Universidade Politécnica do Brooklyn). A saída possui seis colunas: a primeira coluna é o valor n descrito acima, ou seja, o
número do roteador ao longo da rota; a segunda coluna é o nome do roteador; a terceira coluna é o endereço do roteador (no formato
xxx.xxx.xxx.xxx); as três últimas colunas
são os atrasos de ida e volta para três experimentos. Se a origem receber menos de três mensagens de um determinado roteador
(devido à perda de pacotes na rede), o Traceroute colocará um asterisco logo após o roteador
número e relata menos de três tempos de ida e volta para esse roteador.
1 cs-gw (128.119.240.254) 1,009 ms 0,899 ms 0,993 ms
2 128.119.3.154 (128.119.3.154) 0,931 ms 0,441 ms 0,651 ms
3 -border4-rt-gi-1-3.gw.umass.edu (128.119.2.194) 1,032 ms 0,484 ms

0,451ms
4 -acr1-ge-2-1-0.Boston.cw.net (208.172.51.129) 10.006 ms 8.150 ms 8.460

EM
5 -agr4-loopback.NewYork.cw.net (206.24.194.104) 12.272 ms 14.344 ms

13,267ms
6 -acr2-loopback.NewYork.cw.net (206.24.194.62) 13,225 ms 12,292 ms

12,148ms
7 -pos10-2.core2.NewYork1.Level3.net (209.244.160.133) 12.218 ms 11.823

ms 11,793 ms
8 -gige9-1-52.hsipaccess1.NewYork1.Level3.net (64.159.17.39) 13.081 ms

11,556 ms 13,297 ms
9 -p0-0.polyu.bbnplanet.net (4.25.109.122) 12.716 ms 13.052 ms 12.786 ms
10 cis.poly.edu (128.238.32.126) 14.080 ms 13.035 ms 12.802 ms
No rastreamento acima existem nove roteadores entre a origem e o destino. A maioria desses roteadores
têm um nome, e todos eles têm endereços. Por exemplo, o nome do roteador 3 é border4-rt-gi
1-3.gw.umass.edu e seu endereço é 128.119.2.194 . Observando os dados fornecidos para esse mesmo roteador, vemos que na
primeira das três tentativas o atraso de ida e volta entre a origem e o roteador
foi de 1,03 ms. Os atrasos de ida e volta para as duas tentativas subsequentes foram 0,48 e 0,45 ms. Esses
atrasos de ida e volta incluem todos os atrasos discutidos, incluindo atrasos de transmissão, propagação
atrasos, atrasos no processamento do roteador e atrasos nas filas. Como o atraso na fila varia com o tempo,
o atraso de ida e volta do pacote n enviado para um roteador n às vezes pode ser maior do que o atraso de ida e volta do pacote n+1
enviado para o roteador n+1. De fato, observamos esse fenômeno no exemplo acima: os atrasos no roteador 6 são maiores que os atrasos
no roteador 7!
Quer experimentar o Traceroute por si mesmo? É altamente recomendável que você visite http://www.traceroute.org,
que fornece uma interface da Web para uma extensa lista de fontes para rastreamento de rota.
Você escolhe uma origem e fornece o nome do host para qualquer destino. O programa Traceroute então faz todo o trabalho. Existem
vários programas de software gratuitos que fornecem uma interface gráfica para
Traceroute; um dos nossos favoritos é o PingPlotter [PingPlotter 2016].
Sistema final, aplicativo e outros atrasos
Além dos atrasos de processamento, transmissão e propagação, pode haver atrasos significativos adicionais nos sistemas finais.
Por exemplo, um sistema final que deseja transmitir um pacote para um servidor compartilhado
meio (por exemplo, como em um cenário WiFi ou modem a cabo) pode propositadamente atrasar sua transmissão como parte de seu
protocolo para compartilhar o meio com outros sistemas finais; consideraremos esses protocolos em detalhes em
Capítulo 6. Outro atraso importante é o atraso de empacotamento de mídia, que está presente em aplicativos de Voz sobre IP (VoIP).
No VoIP, o lado remetente deve primeiro preencher um pacote com fala digitalizada codificada antes de passar o pacote para a
Internet. Este tempo para preencher um pacote - chamado de atraso de empacotamento - pode ser significativo e afetar a qualidade
percebida pelo usuário de uma chamada VoIP. Esta questão será ainda
explorado em um problema de lição de casa no final deste capítulo.
1.4.4 Taxa de transferência em redes de computadores
Além do atraso e da perda de pacotes, outra medida crítica de desempenho em redes de computadores é a taxa de transferência de ponta
a ponta. Para definir a taxa de transferência, considere a transferência de um arquivo grande do Host A para o Host B através de uma rede
de computadores. Essa transferência pode ser, por exemplo, um grande videoclipe de um par para outro em um
Sistema de compartilhamento de arquivos P2P. A taxa de transferência instantânea em qualquer instante de tempo é a taxa (em bits/seg) em
qual Host B está recebendo o arquivo. (Muitos aplicativos, incluindo muitos sistemas de compartilhamento de arquivos P2P, exibem a taxa
de transferência instantânea durante os downloads na interface do usuário - talvez você tenha observado isso
antes!) Se o arquivo consistir em F bits e a transferência levar T segundos para o Host B receber todos os F bits, então o throughput médio
da transferência de arquivo é F/ T bits/s. Para algumas aplicações, como telefonia via Internet, é desejável ter um atraso baixo e uma
taxa de transferência instantânea consistentemente acima de algum limite (por exemplo, mais de 24 kbps para algumas aplicações de
telefonia via Internet e mais de 256 kbps para algumas aplicações de vídeo em tempo real). Para outras aplicações, incluindo as que
envolvem transferências de arquivos, atraso
não é crítico, mas é desejável ter o maior rendimento possível.

Para obter mais informações sobre o importante conceito de taxa de transferência, vamos considerar alguns exemplos. A Figura 1.19(a) mostra
dois sistemas finais, um servidor e um cliente, conectados por dois enlaces de comunicação e um roteador. Considere a taxa de transferência
de uma transferência de arquivo do servidor para o cliente. Seja R denotando a taxa de s
o link entre o servidor e o roteador; e R denotam a taxa do link entre o croteador e o
cliente. Suponha que os únicos bits enviados em toda a rede sejam aqueles do servidor para o cliente.
Agora perguntamos, nesse cenário ideal, qual é a taxa de transferência do servidor para o cliente? Para responder a esta pergunta, nós
pode pensar em bits como fluidos e links de comunicação como tubos. Claramente, o servidor não pode bombear bits através de seu link a uma taxa
s
superior a R bps; e o roteador não pode encaminhar c
bits a uma taxa superior a R bps. Se Rs<Rc, então os bits bombeados pelo servidor
“fluirão” diretamente pelo roteador e chegarão ao cliente em um
taxa de R bps, Rc<Rs,

s fornecendo uma taxa de transferência des R bps. Se, por outro lado, o roteador não for capaz de encaminhar os bits tão
rapidamente quanto os recebe. Neste caso, os bits só sairão do roteador na taxa R c,
c de R . (Observe também que, se os bits continuarem a chegar ao roteador na taxa R

fornecendo uma taxa de transferência de ponta a ponta s,
e continue a deixar o roteador em R c, o backlog de bits no roteador esperando
Figura 1.19 Taxa de transferência para uma transferência de arquivo do servidor para o cliente
pois a transmissão ao cliente crescerá cada vez mais - uma situação muito indesejável!) Assim, para este simples
transferência é min{R , c s ou seja, é a taxa de transmissão do enlace gargalo. rede de dois links, a taxa de
R },
Tendo determinado a taxa de transferência, podemos agora aproximar o tempo necessário para transferir um grande arquivo de F bits do servidor
para o cliente como F/min{R , R }. Para um exemplos específico,

c suponha que você esteja baixando um arquivo MP3
arquivo de F=32 milhões de bits, o servidor tem uma taxa de transmissão de Rs = 2 Mbps, e você tem um link de acesso
de Rc=1 Mbps. O tempo necessário para transferir o arquivo é de 32 segundos. Claro, essas expressões para
throughput e tempo de transferência são apenas aproximações, pois não levam em conta armazenamento e encaminhamento e
atrasos de processamento, bem como problemas de protocolo.
A Figura 1.19(b) agora mostra uma rede com N links entre o servidor e o cliente, com R1,R2,…, RN. taxas de transmissão dos
links N sendo
Aplicando a mesma análise da rede de dois links, descobrimos que a taxa de transferência para uma transferência de arquivo do servidor para
o cliente é min {R1,R2,…, RN} , qual

é mais uma vez a taxa de transmissão do link gargalo ao longo do caminho entre o servidor e o cliente.
Agora considere outro exemplo motivado pela Internet de hoje. A Figura 1.20(a) mostra dois sistemas finais, um servidor e um
cliente, conectados a uma rede de computadores. Considere a taxa de transferência para uma transferência de arquivo de
o servidor para o cliente. O servidor está conectado à rede com um link de acesso de taxa R e o s
cliente está conectado à rede com um link de acesso de taxa R . Agora suponha
c que todos os links no
núcleo da rede de comunicação tem taxas de transmissão muito altas, muito mais altas que R e R . s c
De fato, hoje, o núcleo da Internet está superprovisionado com links de alta velocidade que sofrem pouco congestionamento.
Suponha também que os únicos bits sendo enviados em toda a rede são aqueles do servidor para o cliente. Como o núcleo da
rede de computadores é como um tubo largo neste exemplo, a taxa em

=
quais bits podem fluir da origem ao destino é novamente o mínimo de R e R s c , ou seja, taxa de transferência
min{R , sR }. cPortanto, o fator limitante para throughput na Internet de hoje é normalmente o acesso
rede.
Para um exemplo final, considere a Figura 1.20(b) na qual existem 10 servidores e 10 clientes conectados ao núcleo da rede de
computadores. Neste exemplo, ocorrem 10 downloads simultâneos, envolvendo 10 pares cliente-servidor. Suponha que esses
10 downloads sejam o único tráfego na rede no momento atual. Conforme mostrado na figura, há um link no núcleo que é
percorrido por todos os 10 downloads.
Denote R para a taxa de transmissão deste link R. Vamos supor que todos os links de acesso ao servidor tenham o
mesma taxa R s, todos os links de acesso do cliente têm a mesma taxa Rc , e as taxas de transmissão de todos os links em
o núcleo - exceto o link comum de taxa R - são muito maiores que R s, R c , e R. Agora perguntamos, o que
são as taxas de transferência dos downloads? Claramente, se a taxa do link comum, R, for grande - digamos um
cem vezes maior que R e R - então a taxas de transferência

c para cada download será novamente
min{R , sR }. cMas e se a taxa do link comum for da mesma ordem que R e R ? Qual será a vazão neste
s caso?
c Vamos dar uma
olhada em um exemplo específico. Suponha que Rs = 2 Mbps, Rc = 1 Mbps,

R=5 Mbps e o
Figura 1.20 Taxa de transferência de ponta a ponta: (a) O cliente baixa um arquivo do servidor; (b) 10
clientes baixando com 10 servidores
link comum divide sua taxa de transmissão igualmente entre os 10 downloads. Então o gargalo para cada download
não está mais na rede de acesso, mas agora é o link compartilhado no núcleo, que fornece apenas 500 kbps de throughput
para cada download. Assim, a taxa de transferência de ponta a ponta para cada download agora é reduzida para 500
kbps.
Os exemplos da Figura 1.19 e da Figura 1.20(a) mostram que o throughput depende das taxas de transmissão dos
enlaces pelos quais os dados fluem. Vimos que, quando não há nenhum outro tráfego intermediário, a taxa de
transferência pode ser simplesmente aproximada como a taxa mínima de transmissão ao longo do caminho entre
origem e destino. O exemplo da Figura 1.20(b) mostra que, de forma mais geral, o throughput depende não apenas
das taxas de transmissão dos enlaces ao longo do caminho, mas também do tráfego intermediário.
Em particular, um link com uma alta taxa de transmissão pode, no entanto, ser o link de gargalo para uma transferência de
arquivo se muitos outros fluxos de dados também estiverem passando por esse link. Examinaremos o throughput em
redes de computadores mais de perto nos problemas do dever de casa e nos capítulos subseqüentes.
1.5 Camadas de protocolo e seus modelos de serviço
De nossa discussão até agora, é evidente que a Internet é um sistema extremamente complicado. Vimos que há muitas
peças na Internet: vários aplicativos e protocolos, vários tipos de sistemas finais, comutadores de pacotes e vários tipos
de mídia em nível de link. Dada essa enorme complexidade, há alguma esperança de organizar uma arquitetura de
rede, ou pelo menos nossa discussão sobre arquitetura de rede? Felizmente, a resposta para ambas as perguntas é sim.
1.5.1 Arquitetura em Camadas
Antes de tentar organizar nossos pensamentos sobre a arquitetura da Internet, vamos procurar uma analogia humana.
Na verdade, lidamos com sistemas complexos o tempo todo em nossa vida cotidiana. Imagine se alguém lhe pedisse para
descrever, por exemplo, o sistema de companhias aéreas. Como você encontraria a estrutura para descrever esse sistema
complexo que tem agentes de emissão de passagens, despachantes de bagagem, pessoal de portão, pilotos, aviões,
controle de tráfego aéreo e um sistema mundial de roteamento de aviões? Uma maneira de descrever esse sistema pode ser
descrever a série de ações que você executa (ou outras pessoas realizam por você) quando voa em uma companhia aérea.
Você compra sua passagem, despacha suas malas, vai até o portão e, eventualmente, é embarcado no avião. O avião decola e é
encaminhado ao seu destino. Depois que seu avião pousar, você desembarca no portão e pega suas malas. Se a viagem
foi ruim, você reclama do voo para a bilheteira (não ganha nada pelo seu esforço). Este cenário
é mostrado na Figura 1.21.
Figura 1.21 Fazendo uma viagem de avião: ações

Figura 1.22 Camadas horizontais da funcionalidade da companhia aérea
Já podemos ver algumas analogias aqui com redes de computadores: você está sendo enviado da origem ao destino pela
companhia aérea; um pacote é enviado do host de origem para o host de destino no
Internet. Mas esta não é exatamente a analogia que buscamos. Estamos procurando alguma estrutura na Figura 1.21.
Observando a Figura 1.21, notamos que existe uma função de bilhética em cada extremidade; há também uma função de
bagagem para passageiros já com passagem e uma função de portão para passageiros com passagem e bagagem despachada.
Para os passageiros que passaram pelo portão (ou seja, passageiros com passagem, bagagem despachada e passagem pelo
portão), há uma função de decolagem e pouso e, durante o voo, há uma função de roteamento do avião. Isso sugere que
podemos olhar para a funcionalidade em
Figura 1.21 na horizontal , conforme mostra a Figura 1.22.
A Figura 1.22 dividiu a funcionalidade da companhia aérea em camadas, fornecendo uma estrutura na qual podemos
discutir viagens aéreas. Observe que cada camada, combinada com as camadas abaixo dela, implementa alguns
funcionalidade, algum serviço. Na camada de emissão de bilhetes e abaixo, é realizada a transferência de uma pessoa de balcão
de companhia aérea para balcão de companhia aérea. Na camada de bagagem e abaixo, é realizada a transferência de bagagem
para bagagem de uma pessoa e malas. Observe que a camada de bagagem fornece esse serviço apenas para uma
pessoa já com bilhete. Na camada do portão, é realizada a transferência do portão de embarque para o portão de chegada de
uma pessoa e malas. Na camada de decolagem/aterrissagem, é realizada a transferência de pista para pista de pessoas e
suas malas. Cada camada fornece seu serviço (1) executando determinadas ações dentro dessa camada (por exemplo, na
camada do portão, carregando e descarregando pessoas de um avião) e (2) usando os serviços da camada diretamente abaixo dela
(por exemplo, na camada de portão, usando o serviço de transferência de passageiros pista a pista da camada de decolagem/
aterrissagem).
Uma arquitetura em camadas nos permite discutir uma parte específica e bem definida de um sistema grande e complexo.
Essa simplificação em si tem um valor considerável por fornecer modularidade, tornando muito mais fácil alterar a
implementação do serviço fornecido pela camada. Desde que a camada forneça o mesmo serviço para a camada acima dela e use
os mesmos serviços da camada abaixo dela, o restante do sistema permanece inalterado quando a implementação de uma
camada é alterada. (Observe que alterar o

a implementação de um serviço é muito diferente de alterar o próprio serviço!) Por exemplo, se as funções do portão
fossem alteradas (por exemplo, para que as pessoas embarquem e desembarquem por altura), o restante do sistema aéreo
permaneceria inalterado, pois a camada do portão ainda oferece a mesma função (carregar e descarregar pessoas); ele
simplesmente implementa essa função de uma maneira diferente após a alteração. Para
sistemas grandes e complexos que estão em constante atualização, a capacidade de alterar a implementação de um serviço
sem afetar outros componentes do sistema é outra vantagem importante da camada.
Camadas de protocolo
Mas chega de companhias aéreas. Vamos agora voltar nossa atenção para os protocolos de rede. Para fornecer estrutura
ao projeto de protocolos de rede, os projetistas de rede organizam os protocolos — e o hardware e software de rede que
implementam os protocolos — em camadas. Cada protocolo pertence a uma das camadas, assim como
cada função na arquitetura da linha aérea na Figura 1.22 pertencia a uma camada. Estamos novamente interessados nos
serviços que uma camada oferece à camada acima - o chamado modelo de serviço de uma camada. Assim como no
caso de nossa companhia aérea, cada camada fornece seu serviço (1) executando determinadas ações dentro dessa
camada e (2) usando os serviços da camada diretamente abaixo dela. Por exemplo, os serviços prestados
pela camada n pode incluir entrega confiável de mensagens de uma borda da rede para a outra. Isso pode ser
implementado usando um serviço de entrega de mensagens ponta a ponta não confiável da camada n-1 ,e
adicionando a funcionalidade da camada n para detectar e retransmitir mensagens perdidas.
Uma camada de protocolo pode ser implementada em software, em hardware ou em uma combinação dos dois.
Os protocolos da camada de aplicação – como HTTP e SMTP – são quase sempre implementados em software nos sistemas
finais; assim como os protocolos da camada de transporte. Como a camada física e as camadas de enlace de dados são
responsáveis por lidar com a comunicação em um link específico, eles são normalmente implementados em uma placa de
interface de rede (por exemplo, placas de interface Ethernet ou WiFi) associada a um determinado link. A camada de rede
geralmente é uma implementação mista de hardware e software. Observe também que, assim como as funções em
a arquitetura em camadas da companhia aérea foram distribuídos entre os vários aeroportos e centros de controle de vôo que
compõem o sistema, assim também é um protocolo de camada n distribuído entre os sistemas finais, comutadores de
pacotes e outros componentes que compõem a rede. Ou seja, muitas vezes há um pedaço de um protocolo da camada n
em cada um desses componentes de rede.
A camada de protocolo tem vantagens conceituais e estruturais [RFC 3439]. Como vimos, as camadas fornecem uma
maneira estruturada de discutir os componentes do sistema. A modularidade facilita a atualização do sistema
componentes. Mencionamos, no entanto, que alguns pesquisadores e engenheiros de rede são veementemente
oposição à estratificação [Wakeman 1992]. Uma desvantagem potencial das camadas é que uma camada pode
duplicar a funcionalidade da camada inferior. Por exemplo, muitas pilhas de protocolo fornecem recuperação de erros
Figura 1.23 A pilha de protocolos da Internet (a) e o modelo de referência OSI (b)
tanto por link quanto de ponta a ponta. Uma segunda desvantagem potencial é que a funcionalidade em uma camada pode precisar de
informações (por exemplo, um valor de registro de data e hora) que está presente apenas em outra camada; isso viola o objetivo de separação
de camadas.
Quando tomados em conjunto, os protocolos das várias camadas são chamados de pilha de protocolos. A pilha de protocolos da Internet
consiste em cinco camadas: as camadas física, de enlace, de rede, de transporte e de aplicação.
mostrado na Figura 1.23(a). Se você examinar o sumário, verá que organizamos este livro de maneira grosseira usando as camadas
da pilha de protocolos da Internet. Adotamos uma abordagem de cima para baixo, primeiro cobrindo a camada de aplicativo e depois descendo.
Camada de aplicação
A camada de aplicativo é onde residem os aplicativos de rede e seus protocolos de camada de aplicativo. O
A camada de aplicação da Internet inclui muitos protocolos, como o protocolo HTTP (que fornece
solicitação e transferência de documentos), SMTP (que fornece a transferência de mensagens de e-mail) e FTP (que fornece a transferência
de arquivos entre dois sistemas finais). Veremos que determinada rede
funções, como a tradução de nomes amigáveis para sistemas finais da Internet como www.ietf.org para um endereço de rede de 32 bits, também
são feitas com a ajuda de um protocolo de camada de aplicativo específico, ou seja, o
sistema de nome de domínio (DNS). Veremos no Capítulo 2 que é muito fácil criar e implementar nossos próprios novos protocolos de
camada de aplicação.
Um protocolo de camada de aplicativo é distribuído por vários sistemas finais, com o aplicativo em um sistema final usando o protocolo para
trocar pacotes de informações com o aplicativo em outro sistema final. Vamos nos referir a esse pacote de informações na camada de
aplicativo como uma mensagem.
Camada de transporte
A camada de transporte da Internet transporta mensagens da camada de aplicativos entre os terminais de aplicativos. Na
Internet, existem dois protocolos de transporte, TCP e UDP, e qualquer um deles pode transportar mensagens da camada
de aplicação. O TCP fornece um serviço orientado à conexão para seus aplicativos. Este serviço inclui
entrega garantida de mensagens da camada de aplicação ao destino e controle de fluxo (ou seja,
correspondência de velocidade do remetente/receptor). O TCP também divide mensagens longas em segmentos mais
curtos e fornece um mecanismo de controle de congestionamento, de modo que uma fonte reduz sua taxa de
transmissão quando a rede está congestionada. O protocolo UDP fornece um serviço sem conexão para seus aplicativos.
Este é um serviço simples que não oferece confiabilidade, controle de fluxo e controle de congestionamento. Neste livro,
nos referiremos a um pacote da camada de transporte como um segmento.
Camada de rede
A camada de rede da Internet é responsável por mover pacotes da camada de rede conhecidos como datagramas de um
host para outro. O protocolo da camada de transporte da Internet (TCP ou UDP) em um host de origem passa um
segmento da camada de transporte e um endereço de destino para a camada de rede, exatamente como você daria
ao serviço postal uma carta com um endereço de destino. A camada de rede então fornece o serviço de
entregar o segmento para a camada de transporte no host de destino.
A camada de rede da Internet inclui o famoso protocolo IP, que define os campos do datagrama e também como os sistemas
finais e roteadores agem nesses campos. Existe apenas um protocolo IP e todos os componentes da Internet que
possuem uma camada de rede devem executar o protocolo IP. A camada de rede da Internet
também contém protocolos de roteamento que determinam as rotas que os datagramas seguem entre as fontes e
destinos. A Internet tem muitos protocolos de roteamento. Como vimos na Seção 1.3, a Internet é uma rede de redes
e, dentro de uma rede, o administrador da rede pode executar qualquer protocolo de roteamento desejado. Embora
a camada de rede contenha tanto o protocolo IP quanto vários protocolos de roteamento, ela geralmente é chamada
simplesmente de camada IP, refletindo o fato de que o IP é a cola que une a Internet.
Camada de Link
A camada de rede da Internet roteia um datagrama através de uma série de roteadores entre a origem e o destino.
Para mover um pacote de um nó (host ou roteador) para o próximo nó na rota, a rede
camada depende dos serviços da camada de enlace. Em particular, em cada nó, a camada de rede passa o datagrama
para a camada de enlace, que entrega o datagrama ao próximo nó ao longo da rota. Neste próximo nó, a camada de
enlace passa o datagrama até a camada de rede.
Os serviços fornecidos pela camada de enlace dependem do protocolo específico da camada de enlace empregado no
enlace. Por exemplo, alguns protocolos da camada de enlace fornecem entrega confiável, desde o nó transmissor, em
um enlace, até o nó receptor. Observe que esse serviço de entrega confiável é diferente do serviço de entrega confiável
do TCP, que fornece entrega confiável de um sistema final para outro. Exemplos de camada de enlace
Os protocolos incluem Ethernet, WiFi e o protocolo DOCSIS da rede de acesso a cabo. Como os datagramas geralmente precisam
percorrer vários links para viajar da origem ao destino, um datagrama pode ser manipulado
por diferentes protocolos da camada de enlace em diferentes enlaces ao longo de sua rota. Por exemplo, um datagrama pode
ser tratado por Ethernet em um link e por PPP no próximo link. A camada de rede receberá um diferente
serviço de cada um dos diferentes protocolos da camada de enlace. Neste livro, vamos nos referir aos pacotes da camada de enlace como
quadros.
Camada física
Enquanto o trabalho da camada de enlace é mover quadros inteiros de um elemento de rede para um elemento de rede adjacente
elemento, o trabalho da camada física é mover os bits individuais dentro do quadro de um nó para o próximo. Os protocolos nesta camada
são novamente dependentes do link e dependem ainda mais do meio de transmissão real do link (por exemplo, fio de cobre de par
trançado, fibra óptica monomodo). Por exemplo, a Ethernet tem muitos protocolos de camada física: um para fio de cobre de par
trançado, outro para cabo coaxial,
outro para fibra, e assim por diante. Em cada caso, um bit é movido pelo link de uma maneira diferente.
O Modelo OSI
Tendo discutido detalhadamente a pilha de protocolos da Internet, devemos mencionar que ela não é a única pilha de protocolos
existente. Em particular, no final da década de 1970, a Organização Internacional de Padronização (ISO) propôs que as redes de
computadores fossem organizadas em sete camadas, chamadas de Sistemas Abertos.
Modelo de interconexão (OSI) [ISO 2016]. O modelo OSI tomou forma quando os protocolos que se tornariam os protocolos da
Internet estavam em sua infância e eram apenas um dos muitos diferentes conjuntos de protocolos em desenvolvimento; na verdade, os
inventores do modelo OSI original provavelmente não tinham a Internet em mente ao criá-lo. No entanto, a partir do final da década de
1970, muitos cursos universitários e de treinamento adotaram o mandato da ISO e organizaram cursos em torno do modelo de sete
camadas. Por causa de sua
impacto inicial na educação em rede, o modelo de sete camadas continua a persistir em alguns livros didáticos e cursos de treinamento
em rede.
As sete camadas do modelo de referência OSI, mostradas na Figura 1.23(b), são: camada de aplicação, camada de
apresentação, camada de sessão, camada de transporte, camada de rede, camada de enlace de dados e camada física. O
a funcionalidade de cinco dessas camadas é praticamente a mesma de suas contrapartes da Internet com nomes semelhantes.
Assim, vamos considerar as duas camadas adicionais presentes no modelo de referência OSI — a camada de apresentação e a camada
de sessão. O papel da camada de apresentação é fornecer serviços que permitem que os aplicativos de comunicação interpretem o
significado dos dados trocados. Esses serviços incluem compactação de dados e criptografia de dados (que são autoexplicativos), bem
como descrição de dados (que libera os aplicativos de se preocuparem com o formato interno no qual os dados são representados/
armazenados - formatos que podem diferir de um computador para outro ). A camada de sessão fornece delimitação e sincronização da
troca de dados, incluindo os meios para construir um esquema de verificação e recuperação.

O fato de a Internet não ter duas camadas encontradas no modelo de referência OSI levanta algumas questões interessantes:
os serviços fornecidos por essas camadas não são importantes? E se um aplicativo
precisa de um desses serviços? A resposta da Internet para essas duas perguntas é a mesma — cabe ao desenvolvedor do aplicativo.
Cabe ao desenvolvedor do aplicativo decidir se um serviço é importante e se
o serviço é importante, cabe ao desenvolvedor do aplicativo criar essa funcionalidade no aplicativo.
1.5.2 Encapsulamento
A Figura 1.24 mostra o caminho físico que os dados percorrem na pilha de protocolos de um sistema final emissor, para cima e para
baixo nas pilhas de protocolos de um switch de camada de enlace interveniente
Figura 1.24 Hosts, roteadores e switches da camada de enlace; cada um contém um conjunto diferente de camadas,
refletindo suas diferenças de funcionalidade
e roteador e, em seguida, suba a pilha de protocolos no sistema final receptor. Como discutiremos mais adiante neste livro, roteadores e
comutadores da camada de enlace são ambos comutadores de pacotes. Semelhante aos sistemas finais, roteadores e switches de
camada de enlace organizam seu hardware e software de rede em camadas. Mas roteadores e camada de enlace
os switches não implementam todas as camadas na pilha de protocolos; eles normalmente implementam apenas o
camadas inferiores. Conforme mostrado na Figura 1.24, os switches da camada de enlace implementam as camadas 1 e 2;
os roteadores implementam as camadas 1 a 3. Isso significa, por exemplo, que os roteadores da Internet são capazes de
implementar o protocolo IP (um protocolo da camada 3), enquanto os switches da camada de enlace não são. Veremos mais tarde que
embora os switches da camada de enlace não reconheçam endereços IP, eles são capazes de reconhecer
endereços da camada 2, como endereços Ethernet. Observe que os hosts implementam todas as cinco camadas; isso é
consistente com a visão de que a arquitetura da Internet coloca muito de sua complexidade nas bordas da rede.
A Figura 1.24 também ilustra o importante conceito de encapsulamento. No host de envio, uma mensagem
da camada de aplicação (M na Figura 1.24) é passada para a camada de transporte. No caso mais simples, a camada
de transporte pega a mensagem e anexa informações adicionais (chamadas de camada de transporte
informações de cabeçalho,t H na Figura 1.24) que serão usadas pela camada de transporte do lado do receptor. A
mensagem da camada de aplicação e as informações do cabeçalho da camada de transporte juntas constituem o transporte
segmento de camada. O segmento da camada de transporte encapsula a mensagem da camada de aplicação. As
informações adicionadas podem incluir informações que permitem que a camada de transporte do lado do receptor entregue o
mensagem até o aplicativo apropriado e bits de detecção de erro que permitem ao receptor determinar se os bits na
mensagem foram alterados na rota. A camada de transporte então passa pelo segmento
à camada de rede, que adiciona informações de cabeçalho da camada de rede (H nan Figura 1.24) , como endereços de
sistema final de origem e destino, criando um datagrama de camada de rede. O datagrama é então passado para a
camada de enlace, que (é claro!) adicionará suas próprias informações de cabeçalho da camada de enlace e criará um
quadro de camada de enlace. Assim, vemos que em cada camada, um pacote possui dois tipos de campos: campos de
cabeçalho e um campo de carga útil. A carga normalmente é um pacote da camada acima.
Uma analogia útil aqui é o envio de um memorando entre escritórios de uma filial corporativa para outra por meio do serviço
postal público. Suponha que Alice, que está em uma filial, queira enviar um memorando para Bob,
que está em outra filial. O memorando é análogo à mensagem da camada de aplicação. Alice coloca o memorando em um
envelope interno com o nome e o departamento de Bob escritos na frente do envelope.
O envelope entre escritórios é análogo a um segmento da camada de transporte — contém informações de cabeçalho
(nome de Bob e número do departamento) e encapsula a mensagem da camada de aplicação (o memorando).
Quando a sala de correspondência da filial remetente recebe o envelope entre escritórios, ela coloca o envelope
entre escritórios dentro de outro envelope, que é adequado para envio pelo serviço postal público.
A sala de correspondência remetente também escreve o endereço postal das filiais remetente e receptora no
envelope postal. Aqui, o envelope postal é análogo ao datagrama - ele encapsula o segmento da camada de transporte (o
envelope entre escritórios), que encapsula a mensagem original (o memorando). O serviço postal entrega o envelope
postal na sala de correspondência da filial receptora. Lá, o processo de desencapsulamento é iniciado. A sala de
correspondência extrai o memorando interno e o encaminha para Bob.
Finalmente, Bob abre o envelope e remove o memorando.
O processo de encapsulamento pode ser mais complexo do que o descrito acima. Por exemplo, uma mensagem grande
pode ser dividida em vários segmentos da camada de transporte (que podem ser divididos em vários datagramas da
camada de rede). Na extremidade receptora, tal segmento deve então ser
reconstruída a partir de seus datagramas constituintes.

1.6 Redes Sob Ataque
Atualmente, a Internet tornou-se uma missão crítica para muitas instituições, incluindo grandes e pequenas empresas,
universidades e agências governamentais. Muitas pessoas também dependem da Internet para muitas de suas atividades profissionais,
sociais e pessoais. Bilhões de “coisas”, incluindo vestíveis e dispositivos domésticos, estão atualmente conectados à Internet. Mas por
trás de toda essa utilidade e empolgação, há um lado sombrio, um lado em que os “bandidos” tentam causar estragos em nossas vidas
diárias, danificando nossos computadores conectados à Internet, violando nossa privacidade e tornando inoperáveis os serviços de Internet
nos quais nós
depender.
O campo da segurança de rede é sobre como os bandidos podem atacar redes de computadores e sobre como nós, futuros especialistas
em redes de computadores, podemos defender redes contra esses ataques, ou melhor ainda, projetar novas arquiteturas que sejam
imunes a esses ataques. em primeiro lugar. Dada a frequência e variedade de ataques existentes, bem como a ameaça de novos e mais
destrutivos ataques futuros, a segurança de rede tornou-se um tópico central no campo de redes de computadores. Uma das
características deste livro é que ele traz as questões de segurança de rede para o primeiro plano.
Como ainda não temos experiência em redes de computadores e protocolos de Internet, começaremos aqui examinando alguns dos
problemas relacionados à segurança mais predominantes atualmente. Isso abrirá nosso apetite por discussões mais substanciais nos
próximos capítulos. Portanto, começamos aqui simplesmente perguntando: o que pode dar errado? Como as redes de computadores
são vulneráveis? Quais são alguns dos tipos de ataques mais comuns atualmente?
Os bandidos podem colocar malware em seu host pela Internet
Conectamos dispositivos à Internet porque queremos receber/enviar dados de/para a Internet. Esse
inclui todos os tipos de coisas boas, incluindo postagens no Instagram, resultados de pesquisa na Internet, streaming de música,
videoconferências, streaming de filmes e assim por diante. Mas, infelizmente, junto com todas essas coisas boas, vêm coisas maliciosas
– coletivamente conhecidas como malware – que também podem entrar e infectar nossos dispositivos.
Depois que o malware infecta nosso dispositivo, ele pode fazer todos os tipos de coisas desonestas, incluindo excluir nossos arquivos e
instalação de spyware que coleta nossas informações privadas, como números de previdência social, senhas e teclas digitadas, e as envia
(pela Internet, é claro!) de volta para os bandidos. Nosso host comprometido também pode estar registrado em uma rede de milhares de
dispositivos comprometidos de forma semelhante, conhecidos coletivamente como botnet, que os criminosos controlam e aproveitam
para distribuição de e-mail de spam ou distribuição
ataques de negação de serviço (que serão discutidos em breve) contra hosts-alvo.

Grande parte do malware existente hoje é autorreplicante: uma vez que infecta um host, desse host ele busca entrar em outros hosts pela
Internet e, nos hosts recém-infectados, busca entrar em ainda mais hosts. Dessa maneira, o malware autorreplicante pode se espalhar
exponencialmente rápido. O malware pode se espalhar em
na forma de um vírus ou worm. Os vírus são malwares que requerem alguma forma de interação do usuário para infectar o dispositivo do
usuário. O exemplo clássico é um anexo de e-mail contendo um código executável malicioso. Se um usuário receber e abrir esse anexo, ele
inadvertidamente executará o malware no dispositivo.
Normalmente, esses vírus de e-mail são autorreplicantes: uma vez executado, o vírus pode enviar uma mensagem idêntica com
um anexo malicioso idêntico para, por exemplo, todos os destinatários do catálogo de endereços do usuário. Worms são malwares que
podem entrar em um dispositivo sem nenhuma interação explícita do usuário. Por exemplo, um usuário pode estar executando um
aplicativo de rede vulnerável para o qual um invasor pode enviar malware. Em alguns
casos, sem qualquer intervenção do usuário, o aplicativo pode aceitar o malware da Internet e executá-lo, criando um worm. O worm no
dispositivo recém-infectado varre a Internet, procurando por outros hosts que executam o mesmo aplicativo de rede vulnerável. Quando
encontra outros hosts vulneráveis, ele envia um
cópia de si mesmo para esses hosts. Hoje, o malware é difundido e caro para se defender. Enquanto você trabalha neste livro, nós o
encorajamos a pensar sobre a seguinte questão: O que o computador pode
designers de rede fazem para defender dispositivos conectados à Internet contra ataques de malware?
Os bandidos podem atacar servidores e infraestrutura de rede
Outra ampla classe de ameaças à segurança são conhecidas como ataques de negação de serviço (DoS). Como o nome sugere, um
ataque DoS torna uma rede, host ou outra parte da infraestrutura inutilizável por legítimos
Usuários. Servidores Web, servidores de e-mail, servidores DNS (discutidos no Capítulo 2) e redes institucionais podem estar sujeitos a
ataques DoS. Ataques DoS na Internet são extremamente comuns, com milhares de DoS
ataques que ocorrem todos os anos [Moore 2001]. O site Digital Attack Map permite visualizar os principais ataques DoS diários em todo
o mundo [DAM 2016]. A maioria dos ataques DoS na Internet se enquadra em uma das três categorias:
Ataque de vulnerabilidade. Isso envolve o envio de algumas mensagens bem elaboradas para um aplicativo ou sistema operacional
vulnerável em execução em um host de destino. Se a sequência correta de pacotes for enviada para um aplicativo ou
sistema operacional vulnerável, o serviço pode parar ou, pior ainda, o host pode travar.
Inundação de largura de banda. O invasor envia uma enxurrada de pacotes para o host visado — tantos pacotes que o link
de acesso do alvo fica obstruído, impedindo que pacotes legítimos cheguem até ele.
o servidor.
Inundação de conexão. O invasor estabelece um grande número de conexões TCP semi-abertas ou totalmente abertas (as
conexões TCP são discutidas no Capítulo 3) no host de destino. O host pode ficar tão atolado com essas conexões falsas que para de
aceitar conexões legítimas.
Vamos agora explorar o ataque de inundação de largura de banda com mais detalhes. Relembrando nossa análise de atrasos e perdas
Conforme discutido na Seção 1.4.2, é evidente que, se o servidor tiver uma taxa de acesso de R bps, o invasor precisará enviar tráfego a
uma taxa de aproximadamente R bps para causar danos. Se R for muito grande, uma única fonte de ataque pode não ser capaz de
gerar tráfego suficiente para prejudicar o servidor. Além disso, se todos os

tráfego emana de uma única fonte, um roteador upstream pode ser capaz de detectar o ataque e bloquear todo o tráfego dessa fonte
antes que o tráfego se aproxime do servidor. Em um ataque DoS distribuído (DDoS) ,
ilustrado na Figura 1.25, o invasor controla várias fontes e faz com que cada fonte destrua o tráfego no alvo. Com essa abordagem,
a taxa de tráfego agregada em todas as fontes controladas precisa ser
aproximadamente R para paralisar o serviço. Ataques DDoS aproveitando botnets com milhares de
hosts são uma ocorrência comum hoje [DAM 2016]. Os ataques DDos são muito mais difíceis de detectar e defender do que
um ataque DoS de um único host.
Incentivamos você a considerar a seguinte pergunta enquanto trabalha neste livro: O que os projetistas de redes de computadores
podem fazer para se defender contra ataques DoS? Veremos que diferentes defesas são
necessários para os três tipos de ataques DoS.
Figura 1.25 Um ataque distribuído de negação de serviço
Os bandidos podem farejar pacotes
Muitos usuários hoje acessam a Internet por meio de dispositivos sem fio, como laptops conectados por Wi-Fi ou computadores de mão
dispositivos com conexões celulares à Internet (abordados no Capítulo 7). Embora o acesso onipresente à Internet seja
extremamente conveniente e permita novos aplicativos maravilhosos para usuários móveis, ele também cria uma grande vulnerabilidade
de segurança - colocando um receptor passivo nas proximidades do transmissor sem fio, que
receptor pode obter uma cópia de cada pacote transmitido! Esses pacotes podem conter todos os tipos de informações
confidenciais, incluindo senhas, números de previdência social, segredos comerciais e mensagens pessoais privadas. Um receptor
passivo que registra uma cópia de cada pacote que passa é chamado de pacote
farejador.
Os sniffers também podem ser implantados em ambientes com fio. Em ambientes de transmissão com fio, como em muitas LANs
Ethernet, um farejador de pacotes pode obter cópias de pacotes de transmissão enviados pela LAN. Como descrito
na Seção 1.2, as tecnologias de acesso a cabo também transmitem pacotes e, portanto, são vulneráveis a sniffing.
Além disso, um criminoso que obtém acesso ao roteador de acesso de uma instituição ou link de acesso à Internet pode implantar um
sniffer que faz uma cópia de todos os pacotes que vão para/da organização. Os pacotes farejados podem então ser analisados offline
para informações confidenciais.
O software de detecção de pacotes está disponível gratuitamente em vários sites da Web e como produtos comerciais. Professores
ensinando um curso de rede são conhecidos por atribuir exercícios de laboratório que envolvem escrever um pacote
sniffing e programa de reconstrução de dados da camada de aplicativo. De fato, os laboratórios Wireshark [Wireshark 2016]
associados a este texto (consulte o laboratório introdutório Wireshark no final deste capítulo) usam exatamente esse sniffer de pacote!
Como os farejadores de pacotes são passivos - isto é, eles não injetam pacotes no canal - eles são
difícil de detectar. Portanto, quando enviamos pacotes para um canal sem fio, devemos aceitar a possibilidade de que algum malfeitor
possa estar gravando cópias de nossos pacotes. Como você deve ter adivinhado, algumas das melhores defesas contra a detecção
de pacotes envolvem criptografia. Examinaremos a criptografia conforme ela se aplica a
segurança de rede no Capítulo 8.
Os bandidos podem se disfarçar como alguém em quem você confia
É surpreendentemente fácil (você terá o conhecimento necessário para fazê-lo logo à medida que prosseguir com este texto!) que irá
devidamente encaminhar o pacote para o seu destino. Imagine o receptor desavisado (digamos, um roteador da Internet) que
recebe esse pacote, considera o endereço de origem (falso) verdadeiro e executa algum comando embutido no conteúdo
do pacote (digamos, modifica sua tabela de encaminhamento). A capacidade de injetar pacotes na Internet com um
endereço de origem falso é conhecido como falsificação de IP e é apenas uma das muitas maneiras pelas quais um usuário pode
se disfarçar de outro usuário.
Para resolver esse problema, precisaremos de autenticação de ponto final, ou seja, um mecanismo que nos permita determinar com
certeza se uma mensagem se origina de onde pensamos. Mais uma vez, encorajamos você a pensar em como isso pode ser feito para
aplicativos e protocolos de rede à medida que avança
os capítulos deste livro. Exploraremos os mecanismos para autenticação de ponto final no Capítulo 8.
Ao fechar esta seção, vale a pena considerar como a Internet se tornou um lugar tão inseguro em primeiro lugar. A resposta, em
essência, é que a Internet foi originalmente projetada para ser assim, com base na
modelo de “um grupo de usuários mutuamente confiáveis ligados a uma rede transparente” [Blumenthal 2001] — um modelo no qual
(por definição) não há necessidade de segurança. Muitos aspectos da Internet original
arquitetura refletem profundamente essa noção de confiança mútua. Por exemplo, a capacidade de um usuário enviar um
pacote para qualquer outro usuário é o padrão, em vez de um recurso solicitado/concedido, e a identidade do usuário é
aceita pelo valor nominal declarado, em vez de ser autenticada por padrão.
Mas a Internet de hoje certamente não envolve “usuários que confiam mutuamente”. No entanto, os usuários de hoje ainda
precisam se comunicar quando não confiam necessariamente uns nos outros, podem querer se comunicar
anonimamente, podem se comunicar indiretamente por meio de terceiros (por exemplo, caches da Web, que estudaremos em
Capítulo 2, ou agentes auxiliares de mobilidade, que estudaremos no Capítulo 7), e podem desconfiar do hardware, software
e até mesmo do ar através do qual eles se comunicam. Agora temos muitos desafios relacionados à segurança diante
de nós à medida que avançamos neste livro: devemos buscar defesas contra sniffing, mascaramento de endpoint, ataques
man-in-the-middle, ataques DDoS, malware e muito mais. Devemos ter em mente que a comunicação entre usuários
mutuamente confiáveis é a exceção e não a regra. Bem-vindo ao mundo das redes de computadores modernas!
1.7 História das Redes de Computadores e da Internet
As Seções 1.1 a 1.6 apresentaram uma visão geral da tecnologia de redes de computadores e da Internet. Você deve
saber o suficiente agora para impressionar sua família e amigos! No entanto, se você realmente quer ser um grande sucesso
no próximo coquetel, você deve polvilhar seu discurso com petiscos sobre o
história fascinante da Internet [Segaller 1998].
1.7.1 O desenvolvimento da comutação de pacotes: 1961–1972
O campo das redes de computadores e a Internet de hoje remontam ao início dos anos 1960,
quando a rede telefônica era a rede de comunicação dominante no mundo. Lembre-se da Seção 1.3 de que a rede telefônica
usa comutação de circuitos para transmitir informações de um emissor para um receptor — uma escolha apropriada, visto
que a voz é transmitida a uma taxa constante entre o emissor e o receptor. Dada a crescente importância dos computadores
no início dos anos 1960 e o advento dos computadores de tempo compartilhado, talvez fosse natural considerar como
conectar os computadores para que pudessem ser compartilhados entre si.
usuários distribuídos geograficamente. O tráfego gerado por esses usuários provavelmente era intermitente - intervalos
de atividade, como o envio de um comando a um computador remoto, seguidos por períodos de inatividade enquanto
se esperava uma resposta ou enquanto contemplava a resposta recebida.
Três grupos de pesquisa ao redor do mundo, cada um sem saber do trabalho do outro [Leiner 1998], começaram
a inventar a comutação de pacotes como uma alternativa eficiente e robusta à comutação de circuitos. O primeiro publicado
o trabalho em técnicas de comutação de pacotes foi o de Leonard Kleinrock [Kleinrock 1961; Kleinrock 1964], então
estudante de pós-graduação no MIT. Usando a teoria das filas, o trabalho de Kleinrock demonstrou elegantemente a
eficácia da abordagem de comutação de pacotes para fontes de tráfego em rajadas. Em 1964, Paul Baran [Baran 1964]
no Rand Institute começou a investigar o uso de comutação de pacotes para voz segura em redes militares, e no
National Physical Laboratory na Inglaterra, Donald Davies e Roger Scantlebury também estavam desenvolvendo
suas ideias sobre comutação de pacotes. .
O trabalho no MIT, Rand e NPL lançou as bases para a Internet de hoje. Mas a Internet também tem um
longa história de uma atitude vamos-construir-e-demonstrar que também remonta à década de 1960. JCR
Licklider [dezembro de 1990] e Lawrence Roberts, ambos colegas de Kleinrock no MIT, lideraram o programa de ciência
da computação na Agência de Projetos de Pesquisa Avançada (ARPA) nos Estados Unidos.
Roberts publicou um plano geral para a ARPAnet [Roberts 1967], a primeira rede de computadores com comutação de
pacotes e um ancestral direto da Internet pública de hoje. No Dia do Trabalho em 1969, a primeira comutação de pacotes
foi instalado na UCLA sob a supervisão de Kleinrock, e três comutadores de pacotes adicionais foram instalados
logo depois, no Stanford Research Institute (SRI), UC Santa Barbara e na Universidade de Utah
(Figura 1.26). O incipiente precursor da Internet tinha quatro nós no final de 1969. Kleinrock lembra o primeiro uso da
rede para realizar um login remoto da UCLA para o SRI, travando o
sistema [Kleinrock 2004].
Em 1972, a ARPAnet havia crescido para aproximadamente 15 nós e recebeu sua primeira demonstração pública por
Robert Kahn. O primeiro protocolo host-to-host entre os sistemas finais da ARPAnet, conhecido como rede
protocolo de controle (NCP), foi concluído [RFC 001]. Com um protocolo de ponta a ponta disponível, os aplicativos
agora podem ser escritos. Ray Tomlinson escreveu o primeiro programa de e-mail em 1972.
1.7.2 Redes Proprietárias e Internetworking: 1972–1980
A ARPAnet inicial era uma rede única e fechada. Para se comunicar com um host ARPAnet, era necessário estar
realmente conectado a outro IMP ARPAnet. No início e meados da década de 1970, outras redes autônomas de
comutação de pacotes além da ARPAnet surgiram: ALOHANet, uma rede de microondas que liga
universidades nas ilhas havaianas [Abramson 1970], bem como o pacote de satélite da DARPA [RFC 829]
Figura 1.26 Uma troca de pacote inicial
e redes de pacotes de rádio [Kahn 1978]; Telenet, uma rede comercial de comutação de pacotes da BBN
baseada na tecnologia ARPAnet; Cyclades, uma rede francesa de comutação de pacotes iniciada por Louis Pouzin
[Pense em 2012]; Redes de compartilhamento de tempo como Tymnet e a rede GE Information Services, entre
outras, no final dos anos 1960 e início dos anos 1970 [Schwartz 1977]; SNA da IBM (1969–1974), que se
equiparou ao trabalho da ARPAnet [Schwartz 1977].
O número de redes foi crescendo. Com uma visão retrospectiva perfeita, podemos ver que era hora de desenvolver
uma arquitetura abrangente para conectar redes. Trabalho pioneiro em
redes de interconexão (sob o patrocínio da Agência de Projetos de Pesquisa Avançada de Defesa
(DARPA)), essencialmente criando uma rede de redes, foi feito por Vinton Cerf e Robert Kahn [Cerf 1974]; o termo internetting
foi cunhado para descrever este trabalho.
Esses princípios arquitetônicos foram incorporados no TCP. As primeiras versões do TCP, no entanto, eram bem diferentes
do TCP atual. As primeiras versões do TCP combinavam uma entrega confiável de dados em sequência via retransmissão
do sistema final (ainda parte do TCP atual) com funções de encaminhamento (que hoje são executadas pelo IP). As
primeiras experiências com o TCP, combinadas com o reconhecimento da importância de um serviço de transporte ponta
a ponta não confiável, não controlado por fluxo para aplicações como voz em pacotes, levaram à separação do IP do
TCP e ao desenvolvimento do protocolo UDP. as três chaves
Os protocolos da Internet que vemos hoje - TCP, UDP e IP - estavam conceitualmente em vigor no final do século
1970.
Além da pesquisa DARPA relacionada à Internet, muitas outras atividades importantes de networking estavam em
andamento. No Havaí, Norman Abramson estava desenvolvendo o ALOHAnet, uma rede de rádio baseada em pacotes que
permitiu que vários locais remotos nas ilhas havaianas se comunicassem entre si. o ALOHA
protocolo [Abramson 1970] foi o primeiro protocolo de acesso múltiplo, permitindo que usuários geograficamente
distribuídos compartilhem um único meio de comunicação de transmissão (uma frequência de rádio). Metcalfe e Boggs
baseado no trabalho do protocolo de acesso múltiplo de Abramson quando eles desenvolveram o protocolo Ethernet [Metcalfe
1976] para redes de transmissão compartilhada com base em fio. Curiosamente, o protocolo Ethernet de Metcalfe e Boggs
foi motivado pela necessidade de conectar vários PCs, impressoras e discos compartilhados [Perkins 1994]. Vinte e cinco
anos atrás, bem antes da revolução do PC e da explosão das redes, Metcalfe e Boggs estavam lançando as bases para as
atuais PC LANs.
1.7.3 A Proliferação de Redes: 1980–1990
No final da década de 1970, aproximadamente duzentos hosts estavam conectados à ARPAnet. No fim
da década de 1980 o número de hosts conectados à Internet pública, uma confederação de redes procurando
muito parecido com a Internet de hoje, chegaria a cem mil. A década de 1980 seria uma época de crescimento tremendo.
Grande parte desse crescimento resultou de vários esforços distintos para criar redes de computadores ligando universidades
junto. A BITNET forneceu e-mail e transferência de arquivos entre várias universidades do Nordeste. CSNET
(rede de ciência da computação) foi formada para conectar pesquisadores universitários que não tinham acesso à
ARPAnet. Em 1986, a NSFNET foi criada para fornecer acesso aos centros de supercomputação patrocinados pela NSF.
Começando com uma velocidade de backbone inicial de 56 kbps, o backbone da NSFNET estaria rodando a 1,5 Mbps
até o final da década e serviria como um backbone principal ligando as redes regionais.
Na comunidade ARPAnet, muitas das peças finais da arquitetura atual da Internet estavam se encaixando. 1º de janeiro
de 1983 viu a implantação oficial do TCP/IP como o novo protocolo de host padrão para
ARPAnet (substituindo o protocolo NCP). A transição [RFC 801] do NCP para o TCP/IP foi um evento marcante — todos os
hosts foram obrigados a transferir para o TCP/IP a partir daquele dia. No final da década de 1980, importantes
extensões foram feitas para o TCP para implementar o controle de congestionamento baseado em host [Jacobson 1988]. O
DNS, usado para mapear entre um nome de Internet legível por humanos (por exemplo, gaia.cs.umass.edu) e seu nome de 32 bits
Endereço IP, também foi desenvolvido [RFC 1034].
Paralelamente a esse desenvolvimento da ARPAnet (que foi em grande parte um esforço dos EUA), no início dos anos
1980, os franceses lançaram o projeto Minitel, um plano ambicioso para trazer redes de dados para
todos estão em casa. Patrocinado pelo governo francês, o sistema Minitel consistia em uma
rede de comutação de pacotes (baseada no conjunto de protocolos X.25), servidores Minitel e terminais baratos
com modems embutidos de baixa velocidade. O Minitel se tornou um enorme sucesso em 1984, quando o governo
francês distribuiu um terminal Minitel gratuito para cada família francesa que desejasse um. Os sites do Minitel incluíam sites
gratuitos - como um site de lista telefônica - bem como sites privados, que cobravam uma taxa baseada no uso de cada
usuário. No auge, em meados da década de 1990, oferecia mais de 20.000 serviços, desde home banking até bancos de
dados de pesquisa especializados. O Minitel estava em grande parte dos lares franceses 10 anos antes de a maioria dos
americanos ter ouvido falar da Internet.
1.7.4 A explosão da Internet: década de 1990
A década de 1990 foi iniciada com uma série de eventos que simbolizavam a evolução contínua e a comercialização
iminente da Internet. ARPAnet, o progenitor da Internet, deixou de existir. Em 1991, a NSFNET suspendeu suas restrições
ao uso da NSFNET para fins comerciais. NSFNET
seria desativada em 1995, com o tráfego de backbone da Internet sendo transportado por redes comerciais
Provedores de Serviços de Internet.
O principal evento da década de 1990 seria o surgimento do aplicativo World Wide Web, que
trouxe a Internet para as casas e empresas de milhões de pessoas em todo o mundo. A Web serviu como
uma plataforma para permitir e implantar centenas de novos aplicativos que consideramos normais hoje, incluindo
pesquisa (por exemplo, Google e Bing), comércio na Internet (por exemplo, Amazon e eBay) e redes sociais (por
exemplo, Facebook).
A Web foi inventada no CERN por Tim Berners-Lee entre 1989 e 1991 [Berners-Lee 1989], com base em ideias originadas
em trabalhos anteriores sobre hipertexto da década de 1940 por Vannevar Bush [Bush 1945] e desde a década de 1960 por
Ted Nelson [Xanadu 2012]. Berners-Lee e seus associados desenvolveram versões iniciais de HTML, HTTP, um servidor
Web e um navegador – os quatro componentes principais da Web. No final de 1993 existiam cerca de duzentos servidores
Web em funcionamento, sendo este conjunto de servidores

apenas um prenúncio do que estava por vir. Nessa época, vários pesquisadores estavam desenvolvendo
Navegadores da Web com interfaces GUI, incluindo Marc Andreessen, que junto com Jim Clark, formou
Mosaic Communications, que mais tarde se tornou a Netscape Communications Corporation [Cusumano 1998; Quitner
1998]. Em 1995, estudantes universitários usavam navegadores Netscape para navegar na Web diariamente. Mais ou menos nessa
época, empresas — grandes e pequenas — começaram a operar servidores da Web e fazer transações comerciais pela Web. Em
1996, a Microsoft começou a fabricar navegadores, o que deu início à guerra dos navegadores.
entre Netscape e Microsoft, que a Microsoft ganhou alguns anos depois [Cusumano 1998].
A segunda metade da década de 1990 foi um período de tremendo crescimento e inovação para a Internet, com grandes
corporações e milhares de startups criando produtos e serviços de Internet. No final do milênio, a Internet suportava centenas de
aplicativos populares, incluindo quatro aplicativos matadores
formulários:
E-mail, incluindo anexos e e-mail acessível pela Web
A Web, incluindo navegação na Web e comércio na Internet
Mensagens instantâneas, com listas de contatos
Compartilhamento de arquivos ponto a ponto de MP3s, iniciado pelo Napster
Curiosamente, os dois primeiros aplicativos matadores vieram da comunidade de pesquisa, enquanto os dois últimos foram
criados por alguns jovens empreendedores.
O período de 1995 a 2001 foi uma montanha-russa para a Internet nos mercados financeiros. Antes mesmo de serem lucrativas,
centenas de startups da Internet fizeram ofertas públicas iniciais e começaram a ser negociadas no mercado de ações. Muitas
empresas foram avaliadas em bilhões de dólares sem ter fluxos de receita significativos. As ações da Internet caíram em
2000-2001 e muitas startups fecharam.
No entanto, várias empresas emergiram como grandes vencedoras no espaço da Internet, incluindo Microsoft, Cisco,
Yahoo, e-Bay, Google e Amazon.
1.7.5 O Novo Milênio
A inovação em redes de computadores continua em ritmo acelerado. Avanços estão sendo feitos em todas as frentes, incluindo
implantações de roteadores mais rápidos e maiores velocidades de transmissão tanto nas redes de acesso quanto nos backbones
de rede. Mas os seguintes desenvolvimentos merecem atenção especial:
Desde o início do milênio, temos visto uma implantação agressiva de banda larga
Acesso à Internet para residências - não apenas modems a cabo e DSL, mas também fibra até a residência, conforme discutido
na Seção 1.2. Esse acesso à Internet de alta velocidade preparou o terreno para uma variedade de aplicativos de vídeo,
incluindo a distribuição de vídeo gerado pelo usuário (por exemplo, YouTube), streaming sob demanda de filmes e programas
de televisão (por exemplo, Netflix) e multi- videoconferência pessoal (por exemplo, Skype,
Facetime e Google Hangouts).
A crescente onipresença de redes Wi-Fi públicas de alta velocidade (54 Mbps e superior) e acesso à Internet
de velocidade média (dezenas de Mbps) por meio de redes de telefonia celular 4G não apenas permite
permanecer constantemente conectado em movimento, mas também permite novos aplicativos específicos de
localização, como Yelp, Tinder, Yik Yak e Waz. O número de dispositivos sem fio conectados à Internet ultrapassou
o número de dispositivos com fio em 2011. Esse acesso sem fio de alta velocidade preparou o cenário para o
rápido surgimento de computadores de mão (iPhones, Androids, iPads e assim por diante), que desfrutar de
acesso constante e sem restrições à Internet.
As redes sociais online – como Facebook, Instagram, Twitter e WeChat (extremamente populares na China) –
criaram enormes redes de pessoas na Internet. Muitas dessas redes sociais são amplamente usadas para
mensagens e compartilhamento de fotos. Muitos internautas hoje “vivem” principalmente em uma ou mais redes
sociais. Por meio de suas APIs, as redes sociais online criam plataformas para novos aplicativos em rede e
jogos distribuídos.
Conforme discutido na Seção 1.3.3, os provedores de serviços on-line, como Google e Microsoft,
implantaram suas próprias redes privadas extensas, que não apenas conectam seus data centers
distribuídos globalmente, mas também são usadas para contornar a Internet o máximo possível por meio de peering.
diretamente com ISPs de nível inferior. Como resultado, o Google fornece resultados de pesquisa e
acesso a e-mail quase instantaneamente, como se seus datacenters estivessem funcionando no próprio computador.
Muitas empresas de comércio na Internet agora estão executando seus aplicativos na “nuvem” – como no EC2
da Amazon, no Application Engine do Google ou no Azure da Microsoft. Muitas empresas e universidades
também migraram seus aplicativos de Internet (por exemplo, e-mail e hospedagem na Web) para a nuvem.
As empresas de nuvem não apenas fornecem ambientes de computação e armazenamento escaláveis para
aplicativos, mas também fornecem aos aplicativos acesso implícito a suas redes privadas de alto desempenho.
1.8 Resumo
Neste capítulo, cobrimos uma quantidade enorme de material! Examinamos as várias peças de hardware e software que
compõem a Internet em particular e as redes de computadores em geral. Começamos na borda da rede, olhando para os
sistemas e aplicativos finais e para o serviço de transporte
fornecidos aos aplicativos executados nos sistemas finais. Também examinamos as tecnologias de camada de enlace
e meios físicos normalmente encontrados na rede de acesso. Em seguida, mergulhamos mais fundo na rede, no núcleo da rede,
identificando a comutação de pacotes e a comutação de circuitos como as duas abordagens básicas para transportar dados
por meio de uma rede de telecomunicações, e examinamos os pontos fortes e fracos de cada abordagem. Também
examinamos a estrutura da Internet global, descobrindo que o
Internet é uma rede de redes. Vimos que a estrutura hierárquica da Internet, composta por
e ISPs de nível inferior, permitiu escalar para incluir milhares de redes.
Na segunda parte deste capítulo introdutório, examinamos vários tópicos centrais no campo das redes de computadores.
Primeiro examinamos as causas de atraso, taxa de transferência e perda de pacotes em uma rede comutada por pacotes.
Desenvolvemos modelos quantitativos simples para atrasos de transmissão, propagação e enfileiramento, bem como para
throughput; faremos uso extensivo desses modelos de atraso na lição de casa
problemas ao longo deste livro. Em seguida, examinamos as camadas de protocolo e os modelos de serviço, os
principais princípios de arquitetura em redes aos quais também nos referiremos ao longo deste livro. Também pesquisamos
alguns dos ataques de segurança mais prevalentes no dia da Internet. Terminamos nossa introdução ao
rede com uma breve história de redes de computadores. O primeiro capítulo em si constitui um mini
curso de redes de computadores.
Então, nós realmente cobrimos uma quantidade enorme de terreno neste primeiro capítulo! Se você está um pouco
sobrecarregado, não se preocupe. Nos capítulos seguintes, revisitaremos todas essas ideias, abordando-as em
muito mais detalhes (isso é uma promessa, não uma ameaça!). Neste ponto, esperamos que você saia deste capítulo com uma
uma intuição ainda em desenvolvimento para as peças que compõem uma rede, um domínio ainda em desenvolvimento
do vocabulário de networking (não tenha vergonha de voltar a este capítulo) e um desejo cada vez maior de aprender mais sobre
networking. Essa é a tarefa que temos pela frente no restante deste livro.
Mapeando este livro
Antes de iniciar qualquer viagem, você deve sempre dar uma olhada em um roteiro para se familiarizar com as principais
estradas e entroncamentos que temos pela frente. Para a viagem que estamos prestes a embarcar, o máximo
destino é uma compreensão profunda do como, o quê e o porquê das redes de computadores. Nosso roteiro é
a sequência dos capítulos deste livro:
1. Redes de Computadores e Internet 2.

Camada de Aplicação
3. Camada de
Transporte 4. Camada de Rede:
Plano de Dados 5. Camada de Rede:
Plano de Controle 6. A Camada
de Enlace e LANs 7. Redes Sem Fio e Móveis
8. Segurança em Redes de Computadores

9. Redes Multimídia
Os capítulos 2 a 6 são os cinco capítulos principais deste livro. Você deve observar que esses capítulos estão
organizados em torno das quatro camadas superiores do protocolo de cinco camadas da Internet. Observe ainda que nossa jornada
começa no topo da pilha de protocolos da Internet, ou seja, a camada de aplicação, e vai funcionar
para baixo. A lógica por trás dessa jornada de cima para baixo é que, uma vez que entendemos os aplicativos, podemos
entender os serviços de rede necessários para oferecer suporte a esses aplicativos. Podemos então, por sua
vez, examinar as várias maneiras pelas quais tais serviços podem ser implementados por uma arquitetura de rede.
Cobrir os aplicativos logo no início fornece motivação para o restante do texto.
A segunda metade do livro - Capítulos 7 a 9 - amplia três tópicos extremamente importantes (e um tanto
independentes) em redes de computadores modernas. No Capítulo 7, examinamos redes sem fio e móveis, incluindo
LANs sem fio (incluindo WiFi e Bluetooth), redes de telefonia celular
(incluindo GSM, 3G e 4G) e mobilidade (em redes IP e GSM). O Capítulo 8, que aborda a segurança em redes de
computadores, examina primeiro os fundamentos da criptografia e da segurança de rede e, em seguida, examinamos
como a teoria básica está sendo aplicada em uma ampla gama de contextos da Internet. O último capítulo, que aborda
redes multimídia, examina aplicações de áudio e vídeo, como
Telefone pela Internet, videoconferência e streaming de mídia armazenada. Também veremos como um pacote
A rede comutada pode ser projetada para fornecer qualidade de serviço consistente para aplicativos de áudio
e vídeo.
Problemas e perguntas sobre o dever de casa
Perguntas de revisão do capítulo 1
SEÇÃO 1.1
R1. Qual é a diferença entre um host e um sistema final? Liste vários tipos diferentes de sistemas finais. Um servidor Web é
um sistema final?
R2. A palavra protocolo é freqüentemente usada para descrever relações diplomáticas. Como a Wikipédia descreve
o protocolo diplomático?
R3. Por que os padrões são importantes para os protocolos?
SEÇÃO 1.2
R4. Liste seis tecnologias de acesso. Classifique cada um como acesso doméstico, acesso corporativo ou acesso sem fio
de área ampla.
R5. A taxa de transmissão HFC é dedicada ou compartilhada entre os usuários? As colisões são possíveis em um
canal HFC downstream? Por que ou por que não?
R6. Liste as tecnologias de acesso residencial disponíveis em sua cidade. Para cada tipo de acesso, forneça a taxa
downstream anunciada, a taxa upstream e o preço mensal.
R7. Qual é a taxa de transmissão das LANs Ethernet?
R8. Quais são algumas das mídias físicas que a Ethernet pode executar?
R9. Modems dial-up, HFC, DSL e FTTH são todos usados para acesso residencial. Para cada uma dessas tecnologias de
acesso, forneça uma faixa de taxas de transmissão e comente se a
a taxa de transmissão é compartilhada ou dedicada.
R10. Descreva as tecnologias de acesso à Internet sem fio mais populares atualmente. Compare-os e contraste-os.
SEÇÃO 1.3
R11. Suponha que haja exatamente uma comutação de pacotes entre um host de envio e um host de recebimento.
As taxas de transmissão entre o host de envio e o switch e entre o switch e o
host receptor são R e R 1 2, respectivamente. Supondo que o switch use armazenamento e encaminhamento
comutação de pacotes, qual é o atraso total de ponta a ponta para enviar um pacote de comprimento L? (Ignore
filas, atraso de propagação e atraso de processamento.)
R12. Que vantagem uma rede de comutação de circuitos tem sobre uma rede de comutação de pacotes?
Quais vantagens o TDM tem sobre o FDM em uma rede comutada por circuito?
R13. Suponha que os usuários compartilhem um link de 2 Mbps. Suponha também que cada usuário transmita
continuamente a 1 Mbps ao transmitir, mas cada usuário transmita apenas 20% do tempo. (Veja o
discussão sobre multiplexação estatística na Seção 1.3 .)
a. Quando a comutação de circuitos é usada, quantos usuários podem ser suportados?
b. Para o restante deste problema, suponha que a comutação de pacotes seja usada. Por que essencialmente
não haverá atraso na fila antes do enlace se dois ou menos usuários transmitirem ao mesmo tempo?
Por que haverá um atraso de fila se três usuários transmitirem ao mesmo tempo?
c. Encontre a probabilidade de um determinado usuário estar
transmitindo. d. Suponha agora que haja três usuários. Encontre a probabilidade de que, a qualquer momento,
todos os três usuários estejam transmitindo simultaneamente. Encontre a fração de tempo durante a qual a fila
cresce.
R14. Por que dois ISPs no mesmo nível hierárquico costumam se emparelhar? Como um IXP ganha dinheiro?
R15. Alguns provedores de conteúdo criaram suas próprias redes. Descreva a rede do Google.
O que motiva os provedores de conteúdo a criar essas redes?
SEÇÃO 1.4
R16. Considere enviar um pacote de um host de origem para um host de destino por uma rota fixa. Liste os
componentes de atraso no atraso de ponta a ponta. Quais desses atrasos são constantes e quais
são variáveis?
R17. Visite o miniaplicativo Transmission Versus Propagation Delay no site associado.

Entre as taxas, atraso de propagação e tamanhos de pacotes disponíveis, encontre uma combinação para a qual o
remetente termine a transmissão antes que o primeiro bit do pacote chegue ao receptor. Encontre outra combinação
para a qual o primeiro bit do pacote chegue ao receptor antes que o remetente termine
transmitindo.
R18. Quanto tempo leva para um pacote de comprimento de 1.000 bytes se propagar por um link de distância de
2.500 km, velocidade de propagaçãode 2,5ÿ108 m/s e taxa de transmissão de 2 Mbps? Mais geralmente, como
quanto tempo um pacote de comprimento L leva para se propagar por um link de distância d, velocidade de
propagação s e taxa de transmissão R bps? Esse atraso depende do tamanho do pacote? Esse atraso depende
da taxa de transmissão?
R19. Suponha que o Host A queira enviar um arquivo grande para o Host B. O caminho do Host A para o Host B
tem três links, de taxas R1=500 kbps, R2=2 Mbps e R3=1 Mbps.
a. Supondo que não haja outro tráfego na rede, qual é a taxa de transferência para a transferência de arquivos? b. Suponha
que o arquivo tenha 4 milhões de bytes. Dividindo o tamanho do arquivo pela taxa de transferência, aproximadamente quanto
quanto tempo levará para transferir o arquivo para o Host B?
c. Repita (a) e (b), mas agora com R reduzido 2para 100 kbps.
R20. Suponha que o sistema final A queira enviar um arquivo grande para o sistema final B. Em um nível muito alto,
descreva como o sistema final A cria pacotes a partir do arquivo. Quando um desses pacotes chega a um roteador, quais
informações no pacote o roteador usa para determinar o link para o qual o pacote é encaminhado? Por que a comutação
de pacotes na Internet é semelhante a dirigir de uma cidade a outra e pedir informações ao longo do caminho?
R21. Visite o miniaplicativo Queuing and Loss no site complementar. Qual é a taxa máxima de emissão e a taxa
mínima de transmissão? Com essas taxas, qual é a intensidade do tráfego?
Execute o applet com essas taxas e determine quanto tempo leva para ocorrer a perda de pacotes. Em seguida, repita o
experimento uma segunda vez e determine novamente quanto tempo leva para ocorrer a perda de pacotes. Os valores
são diferentes? Por que ou por que não?
SEÇÃO 1.5
R22. Liste cinco tarefas que uma camada pode executar. É possível que uma (ou mais) dessas tarefas possam ser
executadas por duas (ou mais) camadas?
R23. Quais são as cinco camadas na pilha de protocolos da Internet? Quais são as principais
responsabilidades de cada uma dessas camadas?
R24. O que é uma mensagem da camada de aplicação? Um segmento da camada de transporte? Um datagrama de
camada de rede? Um quadro de camada de link?
R25. Quais camadas na pilha de protocolos da Internet um roteador processa? Quais camadas um switch de camada
de link processa? Quais camadas um host processa?
SEÇÃO 1.6
R26. Qual é a diferença entre um vírus e um worm?
R27. Descrever como uma botnet pode ser criada e como ela pode ser usada para um ataque DDoS.
R28. Suponha que Alice e Bob estejam enviando pacotes um ao outro por uma rede de computadores.
Suponha que Trudy se posicione na rede para que ela possa capturar todos os pacotes enviados por
Alice e enviar o que ela quiser para Bob; ela também pode capturar todos os pacotes enviados por Bob e enviar o que quiser
para Alice. Liste algumas das coisas maliciosas que Trudy pode fazer com isso
posição.
problemas
P1. Projete e descreva um protocolo em nível de aplicativo a ser usado entre um caixa eletrônico e o computador
centralizado de um banco. Seu protocolo deve permitir a verificação do cartão e senha de um usuário, o saldo da
conta (que é mantido no computador centralizado)
a ser consultado, e uma retirada de conta a ser feita (ou seja, dinheiro desembolsado para o usuário).
Suas entidades de protocolo devem ser capazes de lidar com o caso muito comum em que não há
dinheiro suficiente na conta para cobrir a retirada. Especifique seu protocolo listando as mensagens trocadas
e a ação executada pelo caixa eletrônico ou pelo computador centralizado do banco na transmissão e
recebimento de mensagens. Esboce o funcionamento do seu protocolo para o caso de saque simples e sem
erros, usando um diagrama semelhante ao do
Figura 1.2 . Declare explicitamente as suposições feitas por seu protocolo sobre o serviço de transporte de ponta a
ponta subjacente.
P2. A Equação 1.1 fornece uma fórmula para o atraso de ponta a ponta do envio de um pacote de comprimento
L por N enlaces de taxa de transmissão R. Generalize essa fórmula para enviar P desses pacotes de volta para
de volta nos links N.
P3. Considere um aplicativo que transmite dados a uma taxa constante (por exemplo, o remetente gera
uma unidade de dados de N bits a cada k unidades de tempo, em que k é pequeno e fixo). Além disso, quando
esse aplicativo for iniciado, ele continuará em execução por um período de tempo relativamente longo. Responda a
seguintes questões, justificando brevemente a sua resposta:
a. Uma rede de comutação de pacotes ou uma rede de comutação de circuitos seria mais apropriada para
esta aplicação? Por que?
b. Suponha que uma rede de comutação de pacotes seja usada e o único tráfego nessa rede
vem dos aplicativos descritos acima. Além disso, suponha que a soma das taxas de dados do aplicativo seja
menor que as capacidades de cada link. É necessária alguma forma de controle de congestionamento? Por
que?
P4. Considere a rede comutada por circuito na Figura 1.13 . Lembre-se de que existem 4 circuitos em cada
link. Rotule os quatro interruptores A, B, C e D, indo no sentido horário.
a. Qual é o número máximo de conexões simultâneas que podem estar em andamento em

qualquer momento nesta rede?
b. Suponha que todas as conexões estejam entre os switches A e C. Qual é o número máximo de
conexões simultâneas que podem estar em andamento?
c. Suponha que queremos fazer quatro conexões entre os switches A e C e outras quatro conexões entre os
switches B e D. Podemos rotear essas chamadas pelos quatro links para acomodar todas as oito conexões?
P5. Revise a analogia carro-caravana na Seção 1.4 . Considere uma velocidade de propagação de 100 km/h.
a. Suponha que a caravana percorra 150 km, começando em frente a um pedágio, passando por um segundo
pedágio e terminando logo após um terceiro pedágio. Qual é o atraso de ponta a ponta?
b. Repita (a), agora assumindo que há oito carros no trailer em vez de dez.
P6. Este problema elementar começa a explorar o atraso de propagação e o atraso de transmissão, dois conceitos
centrais em redes de dados. Considere dois hosts, A e B, conectados por um único link de
taxa R bps. Suponha que os dois hosts estejam separados por m metros e suponha que o
a velocidade de propagação ao longo do link é de s metros/seg. O host A deve enviar um pacote de tamanho L bits para
Hospedeiro B.
Explorando o atraso de propagação e o atraso de transmissão
a. Expresse o atraso de propagação, d b. suporte , em termos de m e s.
Determine o tempo de transmissão do pacote, d trans , em termos de L e R.
c. Ignorando os atrasos de processamento e enfileiramento, obtenha uma expressão para o atraso de ponta a ponta.
d. Suponha que o Host A comece a transmitir o pacote no último bit do t=0 t= . Na hora d trans , onde está
pacote.
e. Suponha que d seja t=dtrans , onde está o primeiro bit do pacote?

suporte maior que d . No tempo
trans
f. Suponha que d seja t=dtrans , onde está o primeiro bit do pacote?

suporte menor que d . No tempo
trans
s=2,5ÿ108 L=120
, bits , e encontre
R = 56 kbps.
a distância m de modo que d seja igual a
g. Suponha suporte
d trans
.
P7. Neste problema, consideramos o envio de voz em tempo real do Host A para o Host B através de uma rede de
comutação de pacotes (VoIP). O Host A converte a voz analógica em um fluxo de bits digital de 64 kbps em tempo real.
O Host A então agrupa os bits em pacotes de 56 bytes. Existe um link entre os Hosts A e B; isso é
taxa de transmissão é de 2 Mbps e seu atraso de propagação é de 10 ms. Assim que o Host A reúne um
pacote, ele o envia para o Host B. Assim que o Host B recebe um pacote inteiro, ele converte os bits do pacote em
um sinal analógico. Quanto tempo decorre desde que um bit é criado (a partir do sinal analógico original no Host A) até que o
bit seja decodificado (como parte do sinal analógico no Host B)?
P8. Suponha que os usuários compartilhem um link de 3 Mbps. Suponha também que cada usuário exija 150 kbps
ao transmitir, mas cada usuário transmite apenas 10% do tempo. (Veja a discussão do pacote
comutação versus comutação de circuitos na Seção 1.3 .)
a. Quando a comutação de circuitos é usada, quantos usuários podem ser suportados? b.
Para o restante deste problema, suponha que a comutação de pacotes seja usada. Encontre a probabilidade
que um determinado usuário está transmitindo.
c. Suponha que haja 120 usuários. Encontre a probabilidade de que, a qualquer momento, exatamente n usuários
estão transmitindo simultaneamente. (Dica: Use a distribuição binomial.) d. Encontre a
probabilidade de haver 21 ou mais usuários transmitindo simultaneamente.
P9. Considere a discussão na Seção 1.3 sobre comutação de pacotes versus comutação de circuitos, na qual é fornecido
um exemplo com um link de 1 Mbps. Os usuários estão gerando dados a uma taxa de 100 kbps quando ocupados, mas estão
ocupados gerando dados apenas com probabilidade p=0,1 . Suponha que o link de 1 Mbps seja
substituído por um link de 1 Gbps.
a. Qual é N, o número máximo de usuários que podem ser suportados simultaneamente sob
comutação de circuitos?
b. Agora considere a comutação de pacotes e uma população de M usuários. Dê uma fórmula (em
termos de p, M, N) para a probabilidade de que mais de N usuários estejam enviando dados.
P10. Considere um pacote de comprimento L que começa no sistema final A e percorre três links até um sistema
final de destino. Esses três links são conectados por dois comutadores de pacotes. Seja d, s eu
eu ,
e
eu
i=1,2,3
R denotam o comprimento, a velocidade de propagação e a taxa de transmissão do enlace i, para .O
a comutação de pacotes atrasa cada pacote em d . Assumindo que não há atrasos nas filas, em termos de , R,
proc
eu eu eu
d, s , e L, qual é o atraso total de ponta a ponta para o pacote? Suponha agora que o pacote é
(i=1,2,3)
os três links é2,5ÿ108m/s, as2taxas
três links são Mbps,deo transmissão dede
pacote atraso todos os 1.500 bytes, a velocidade de propagação em todos
processamento do switch é de 3 ms, o comprimento do primeiro link é
5.000 km, o comprimento do segundo link é de 4.000 km e o comprimento do último link é de 1.000 km.
Para esses valores, qual é o atraso de ponta a ponta?
problema acima, suponha que e . Além disso,R1=R2=R3=R

suponha que odproc=0 P11.de
comutador Nopacotes não armazene e reencaminhe
pacotes, mas, em vez disso, transmita imediatamente cada bit que recebe antes de esperar que o pacote inteiro
chegue. Qual é o atraso de ponta a ponta?
P12. Um comutador de pacotes recebe um pacote e determina o link de saída para o qual o pacote deve ser
encaminhado. Quando o pacote chega, um outro pacote está na metade do caminho sendo transmitido
neste link de saída e outros quatro pacotes estão esperando para serem transmitidos. Os pacotes são transmitidos
por ordem de chegada. Suponha que todos os pacotes tenham 1.500 bytes e a taxa de link seja de 2 Mbps.
Qual é o atraso de fila para o pacote? De maneira mais geral, qual é o atraso na fila quando
todos os pacotes têm comprimento L, a taxa de transmissão é R, x bits do pacote atualmente sendo transmitido
foram transmitidos e n pacotes já estão na fila?

P13.
a. Suponha que N pacotes cheguem simultaneamente a um link no qual nenhum pacote esteja atualmente
sendo transmitido ou enfileirado. Cada pacote tem comprimento L e o link tem taxa de transmissão R.
Qual é o atraso médio na fila para os N pacotes?
b. Agora suponha que N tais pacotes cheguem ao enlace a cada LN/ R segundos. Qual é o atraso médio
de fila de um pacote?
P14. Considere o atraso de fila em um buffer de roteador. Deixe- me denotar a intensidade do tráfego; I=La/R .
isto é, suponha que o atraso na fila assuma a forma IL/R(1ÿI) para I<1 .
a. Forneça uma fórmula para o atraso total, ou seja, o atraso na fila mais o atraso na transmissão
atraso.
b. Trace o atraso total como uma função de L/ R.
P15. Seja a a taxa de pacotes que chegam a um link em pacotes/seg, e ÿ denote a taxa de transmissão do link em
pacotes/s. Com base na fórmula para o atraso total (ou seja, o atraso na fila
mais o atraso de transmissão) obtido no problema anterior, obtenha uma fórmula para o atraso total
em termos de a e µ.
P16. Considere um buffer de roteador precedendo um link de saída. Neste problema, você usará o método de Little
formula, uma fórmula famosa da teoria das filas. Seja N o número médio de pacotes no buffer mais o pacote sendo
transmitido. Seja a a taxa de pacotes que chegam ao enlace.
Seja d o atraso total médio (ou seja, o atraso na fila mais o atraso na transmissão) experimentado por um
pacote. A fórmula de Little é de 10 pacotes, e o N=aÿd . Suponha que, em média, o buffer contenha
atraso médio na fila de pacotes é de 10 ms. A taxa de transmissão do link é de 100 pacotes/s. Usando a fórmula
de Little, qual é a taxa média de chegada de pacotes, supondo que não haja perda de pacotes?
P17.
a. Generalize a Equação 1.2 na Seção 1.4.3 para taxas de processamento heterogêneas,

taxas de transmissão e atrasos de propagação.
b. Repita (a), mas agora também suponha que haja um atraso médio de fila d em cada fila
nó.
P18. Execute um Traceroute entre origem e destino no mesmo continente em três
diferentes horas do dia.
Usando o Traceroute para descobrir caminhos de rede e medir o atraso da rede
a. Encontre a média e o desvio padrão dos atrasos de ida e volta em cada um dos três
horas.
b. Encontre o número de roteadores no caminho em cada uma das três horas. Os caminhos mudaram durante
alguma das horas?
c. Tente identificar o número de redes ISP pelas quais os pacotes Traceroute passam da origem ao destino.
Roteadores com nomes semelhantes e/ou endereços IP semelhantes devem ser
considerados como parte do mesmo ISP. Em seus experimentos, os maiores atrasos ocorrem nas interfaces
de peering entre ISPs adjacentes?
d. Repita o procedimento acima para uma origem e destino em diferentes continentes. Compare o
resultados intracontinentais e intercontinentais.
P19.
a. Acesse o site www.traceroute.org e realize traceroutes a partir de duas cidades diferentes em

França para o mesmo host de destino nos Estados Unidos. Quantos links são iguais
nos dois traceroutes? A ligação transatlântica é a mesma?
b. Repita (a), mas desta vez escolha uma cidade na França e outra na Alemanha.
c. Escolha uma cidade nos Estados Unidos e execute traceroutes para dois hosts, cada um em uma cidade diferente
na China. Quantos links são comuns nos dois traceroutes? Os dois traceroutes divergem antes de
chegar à China?
P20. Considere o exemplo de throughput correspondente à Figura 1.20(b) . Agora suponha que
há M pares cliente-servidor em vez de 10. Denote links R, links de s, R c , e R para as taxas do servidor
cliente e link de rede. Suponha que todos os outros links tenham capacidade abundante e que haja
não há outro tráfego na rede além do tráfego gerado pelos M pares cliente-servidor. Deduza uma expressão geral para a
taxa de transferência em termos de R s, R c , R e M.
P21. Considere a Figura 1.19(b) . Agora suponha que existam M caminhos entre o servidor e o cliente k(k=1,…,M). Não há
compartilhando qualquer link. O caminho consiste emdois caminhos

N links com taxas de transmissão R1k,R2k,…,RNk . Se o servidor
só pode usar um caminho para enviar dados ao cliente, qual é o
taxa de transferência máxima que o servidor pode atingir? Se o servidor pode usar todos os M caminhos para enviar dados,
qual é o throughput máximo que o servidor pode atingir?
P22. Considere a Figura 1.19(b) . Suponha que cada enlace entre o servidor e o cliente tenha uma probabilidade de
perda de pacotes p, e que as probabilidades de perda de pacotes para esses enlaces sejam independentes. Qual é a
probabilidade de um pacote (enviado pelo servidor) ser recebido com sucesso pelo receptor? Se um pacote for perdido
no caminho do servidor para o cliente, o servidor retransmitirá o pacote.
Em média, quantas vezes o servidor retransmitirá o pacote para que o cliente receba o pacote com sucesso?
P23. Considere a Figura 1.19(a) . Suponha que sabemos que o link gargalo ao longo do caminho do servidor para o cliente
é o primeiro link com taxa de R bits/s. Suponha que enviemos

s um par de pacotes de volta
para voltar do servidor para o cliente e não há outro tráfego neste caminho. Assuma cada
pacote de tamanho L bits, e ambos os links têm o mesmo atraso de propagação d . suporte
a. Qual é o tempo entre chegadas do pacote no destino? Ou seja, quanto tempo decorre desde a chegada do último
bit do primeiro pacote até o último bit do segundo pacote
chega?
b. Agora assuma que o segundo link é o link gargalo (ou seja, ). É possível que o Rc<Rs
segundo pacote fique na fila de
entrada do segundo link? Explicar. Agora suponha
que o servidor envie o segundo pacote T segundos após o envio do primeiro pacote. Qual deve ser o tamanho
de T para garantir que não haja fila antes do segundo link? Explicar.
P24. Suponha que você gostaria de entregar com urgência dados de 40 terabytes de Boston para Los Angeles.
Você tem disponível um link dedicado de 100 Mbps para transferência de dados. Você prefere transmitir os dados por meio
deste link ou usar a entrega noturna da FedEx? Explicar.
P25. Suponha que dois hosts, A e B, estejam separados por 20.000 quilômetros e conectados por um link direto de R=2
Mbps. Suponha que a velocidade de propagação no link seja de 2,5ÿ108 metros/seg.
a. Calcule o produto largura de banda-atraso, Rÿdprop .

b. Considere enviar um arquivo de 800.000 bits do Host A para o Host B. Suponha que o arquivo seja
enviado continuamente como uma grande mensagem. Qual é o número máximo de bits que estará no
link em um determinado momento?
c. Forneça uma interpretação do produto largura de banda-atraso. d. Qual
é a largura (em metros) de um bit no link? É maior que um campo de futebol? e. Deduza uma expressão
geral para a largura de um bit em termos da velocidade de propagação s, a
taxa de transmissão R, e o comprimento do link m.
P26. Referindo-se ao problema P25, suponha que possamos modificar R. Para qual valor de R a largura de um bit é
tão longa quanto o comprimento do link?
P27. Considere o problema P25, mas agora com um link de R=1 Gbps.
a. Calcule o produto largura de banda-atraso, b. Rÿdprop .
Considere enviar um arquivo de 800.000 bits do Host A para o Host B. Suponha que o arquivo seja enviado
continuamente como uma grande mensagem. Qual é o número máximo de bits que estará no link em um
determinado momento?
c. Qual é a largura (em metros) de um bit no link?
P28. Consulte novamente o problema P25.
a. Quanto tempo leva para enviar o arquivo, supondo que seja enviado continuamente?
b. Suponha agora que o arquivo seja dividido em 20 pacotes com cada pacote contendo 40.000 bits.
Suponha que cada pacote seja confirmado pelo receptor e o tempo de transmissão de um pacote de
confirmação seja desprezível. Por fim, suponha que o remetente não possa enviar um pacote até que o
anterior seja confirmado. Quanto tempo leva para enviar
o arquivo?
c. Compare os resultados de (a) e (b).
P29. Suponha que haja um link de microondas de 10 Mbps entre um satélite geoestacionário e sua estação base na
Terra. A cada minuto, o satélite tira uma foto digital e a envia para a estação base.
Assuma uma velocidade de propagação de 2,4ÿ108 metros/seg.
a. Qual é o atraso de propagação do link?

Rÿdprop
b. Qual é o produto largura de banda-atraso, ? c. Seja xo
tamanho da foto. Qual é o valor mínimo de x para o link de microondas

estar transmitindo continuamente?
P30. Considere a analogia da viagem aérea em nossa discussão sobre camadas na Seção 1.5, adição , ea
de cabeçalhos a unidades de dados de protocolo à medida que eles fluem pela pilha de protocolos. Existe uma
noção equivalente de informações de cabeçalho que são adicionadas aos passageiros e bagagens conforme eles descem
na pilha de protocolos da companhia aérea?
P31. Em redes modernas de comutação de pacotes, incluindo a Internet, o host de origem segmenta mensagens
longas da camada de aplicação (por exemplo, uma imagem ou um arquivo de música) em pacotes menores
e envia os pacotes para a rede. O receptor então remonta os pacotes de volta em
a mensagem original. Referimo-nos a este processo como segmentação de mensagem. A Figura 1.27 ilustra o
transporte ponta a ponta de uma mensagem com e sem segmentação de mensagem. Considere um
8ÿ106
mensagem com comprimento de bits que deve ser enviada da origem ao destino na Figura 1.27 .
Suponha que cada enlace na figura tenha 2 Mbps. Ignore atrasos de propagação, enfileiramento e processamento.
a. Considere enviar a mensagem da origem ao destino sem mensagem

segmentação. Quanto tempo leva para mover a mensagem do host de origem para a primeira comutação
de pacotes? Tendo em mente que cada switch usa pacotes de armazenamento e encaminhamento
comutação, qual é o tempo total para mover a mensagem do host de origem para o destino
hospedar?
b. Agora suponha que a mensagem seja segmentada em 800 pacotes, com cada pacote tendo 10.000 bits
de comprimento. Quanto tempo leva para mover o primeiro pacote do host de origem para o primeiro
switch? Quando o primeiro pacote está sendo enviado do primeiro switch para o segundo switch,
o segundo pacote está sendo enviado do host de origem para o primeiro switch. Em que instante o
segundo pacote será totalmente recebido no primeiro comutador?
c. Quanto tempo leva para mover o arquivo do host de origem para o host de destino quando
segmentação de mensagem é usada? Compare este resultado com sua resposta na parte (a) e
Comente.
Figura 1.27 Transporte de mensagens fim-a-fim: (a) sem segmentação de mensagens; (b) com
segmentação de mensagem
d. Além de reduzir o atraso, quais são os motivos para usar a segmentação de mensagens? e.
Discuta as desvantagens da segmentação de mensagens.
P32. Experimente o applet Message Segmentation no site do livro. Os atrasos no applet correspondem aos atrasos
do problema anterior? Como os atrasos de propagação de link afetam o atraso fim-a-fim geral para comutação
de pacotes (com segmentação de mensagens) e para comutação de mensagens?
P33. Considere o envio de um grande arquivo de F bits do Host A para o Host B. Há três links (e duas chaves) entre
A e B, e os links não estão congestionados (ou seja, sem atrasos de fila). Anfitrião A
segmenta o arquivo em segmentos de S bits cada e adiciona 80 bits de cabeçalho a cada segmento,
formar pacotes disso L=80 + S bits. Cada link tem uma taxa de transmissão de R bps. Encontre o valor de S
minimiza o atraso de mover o arquivo do Host A para o Host B. Desconsidere o atraso de propagação.
P34. O Skype oferece um serviço que permite fazer uma chamada telefônica de um PC para um
telefone comum. Isso significa que a chamada de voz deve passar tanto pela Internet quanto por um
rede telefônica. Discuta como isso pode ser feito.
Laboratório Wireshark
“Diga-me e eu esqueço. Mostre-me e eu me lembro. Envolva-me

e eu entendo.”
provérbio chinês
Muitas vezes, a compreensão dos protocolos de rede pode ser muito aprofundada ao vê-los
em ação e brincando com eles - observando a sequência de mensagens
trocadas entre duas entidades de protocolo, aprofundando os detalhes da operação do protocolo,
fazendo com que os protocolos executem certas ações e observando essas ações e suas
consequências. Isso pode ser feito em cenários simulados ou em um ambiente de
rede real, como a Internet. Os applets Java no site do livro na Web adotam a primeira abordagem.
Nos laboratórios do Wireshark, usaremos a última abordagem. Você executará aplicativos de
rede em vários cenários usando um computador em sua mesa, em casa ou em um laboratório.
Você observará os protocolos de rede em seu computador, interagindo e trocando
mensagens com entidades de protocolo executando em outro lugar na Internet. Assim, você e sua
computador será parte integrante desses laboratórios ao vivo. Você observará — e aprenderá —
fazendo.
A ferramenta básica para observar as mensagens trocadas entre as entidades do protocolo

em execução é chamada de packet sniffer. Como o nome sugere, um sniffer de pacotes copia
passivamente (fareja) as mensagens enviadas e recebidas pelo seu computador; ele também exibe
o conteúdo dos vários campos de protocolo dessas mensagens capturadas. Uma captura de tela de
o sniffer de pacotes Wireshark é mostrado na Figura 1.28. O Wireshark é um sniffer de pacotes

gratuito que roda em computadores Windows, Linux/Unix e Mac.
Figura 1.28 Uma captura de tela do Wireshark (captura de tela do Wireshark reimpressa por
permissão da Wireshark Foundation.)
Ao longo do livro, você encontrará laboratórios do Wireshark que permitem explorar vários dos protocolos
estudados no capítulo. Neste primeiro laboratório do Wireshark, você obterá e instalará uma cópia do
Wireshark, acessará um site da Web e capturará e examinará o protocolo
mensagens sendo trocadas entre seu navegador da Web e o servidor da Web.
Você pode encontrar detalhes completos sobre este primeiro laboratório do Wireshark (incluindo instruções sobre como
obtenha e instale o Wireshark) no site http://www.pearsonhighered.com/cs

recursos/.
UMA ENTREVISTA COM…

Leonard Kleinrock
Leonard Kleinrock é professor de ciência da computação na Universidade da Califórnia, Los

Angeles. Em 1969, seu computador na UCLA tornou-se o primeiro nó da Internet. Sua criação de
os princípios de comutação de pacotes em 1961 tornaram-se a tecnologia por trás da Internet. Ele recebeu seu
BEE do City College of New York (CCNY) e seu mestrado e doutorado em engenharia elétrica pelo MIT.
O que fez você decidir se especializar em tecnologia de rede/Internet?
Como estudante de doutorado no MIT em 1959, olhei em volta e descobri que a maioria dos meus colegas estava
fazendo pesquisas na área de teoria da informação e teoria da codificação. No MIT, havia o grande pesquisador
Claude Shannon, que lançou esses campos e já havia resolvido a maioria dos problemas importantes. Os
problemas de pesquisa que ficaram eram difíceis e de menor
consequência. Então decidi me lançar em uma nova área que ninguém mais havia pensado.
Lembre-se que no MIT eu estava cercado por muitos computadores, e ficou claro para mim que logo
essas máquinas precisariam se comunicar umas com as outras. Na época, não havia efetivo
forma de fazê-lo, então decidi desenvolver a tecnologia que permitisse

redes de dados confiáveis sejam criadas.
Qual foi seu primeiro emprego na indústria de informática? O que isso implica?
Fui à sessão noturna da CCNY de 1951 a 1957 para meu bacharelado em eletricidade
Engenharia. Durante o dia, eu trabalhava primeiro como técnico e depois como engenheiro em uma pequena
empresa de eletrônicos industriais chamada Photobell. Enquanto estava lá, introduzi a tecnologia digital em sua
linha de produtos. Essencialmente, estávamos usando dispositivos fotoelétricos para detectar a presença de certos
itens (caixas, pessoas, etc.) e o uso de um circuito conhecido na época como multivibrador biestável era
exatamente o tipo de tecnologia de que precisávamos para trazer o processamento digital para esse campo de detecção.
Esses circuitos são os blocos de construção dos computadores e passaram a ser conhecidos como
flip-flops ou interruptores no vernáculo de hoje.
O que estava passando pela sua cabeça quando você enviou a primeira mensagem de host para host (da UCLA para
Instituto de Pesquisa de Stanford)?
Francamente, não tínhamos ideia da importância daquele evento. Não havíamos preparado uma mensagem
especial de significado histórico, como fizeram tantos inventores do passado (Samuel Morse com “O que Deus fez.” ou
Alexander Graham Bell com “Watson, venha aqui! Eu quero você.” ou Neal Amstrong com “Esse é um pequeno
passo para um homem, um grande salto para a humanidade.”) Esses caras eram
inteligente! Eles entendiam de mídia e relações públicas. Tudo o que queríamos fazer era acessar o computador SRI.
Então digitamos o “L”, que foi recebido corretamente, digitamos o “o” que foi recebido e depois digitamos o “g”
que causou o travamento do computador host do SRI! Então, virou
que nossa mensagem foi a mais curta e talvez a mensagem mais profética de todos os tempos, ou seja,
“Olha!” como em "Eis que!"
No início daquele ano, fui citado em um comunicado de imprensa da UCLA dizendo que, uma vez que a rede
estivesse funcionando, seria possível obter acesso a utilitários de computador de nossas casas e escritórios com a mesma
facilidade com que obtemos acesso à eletricidade e à conectividade telefônica. Então, minha visão naquela época era
que a Internet seria onipresente, sempre ligada, sempre disponível, qualquer pessoa com qualquer dispositivo poderia
se conectar de qualquer local e seria invisível. No entanto, nunca imaginei que minha mãe de 99 anos usaria a Internet
— e de fato ela usou!
Qual é a sua visão para o futuro do networking?
A parte fácil da visão é prever a própria infraestrutura. Prevejo que veremos uma implantação considerável
de computação nômade, dispositivos móveis e espaços inteligentes. De fato, a disponibilidade de dispositivos de
computação e comunicação leves, baratos e de alto desempenho (além da onipresença da Internet)
permitiu que nos tornássemos nômades.
A computação nômade refere-se à tecnologia que permite aos usuários finais que viajam de um lugar para outro
obter acesso a serviços de Internet de maneira transparente, não importa para onde eles viajem e não importa qual
dispositivo eles carregam ou acessam. A parte mais difícil da visão é prever os aplicativos e serviços, que consistentemente
nos surpreendem de formas dramáticas (e-mail, tecnologias de busca, World Wide Web, blogs, redes sociais, geração
de usuários e compartilhamento de músicas, fotos, e vídeos, etc.). Estamos à beira de uma nova classe de surpreendentes
aplicativos móveis inovadores entregues em nossos dispositivos portáteis.
O próximo passo nos permitirá sair do submundo do ciberespaço para o mundo físico dos espaços inteligentes.
Nossos ambientes (mesas, paredes, veículos, relógios, cintos e assim por diante) ganharão vida com a tecnologia, por
meio de atuadores, sensores, lógica, processamento, armazenamento, câmeras,
microfones, alto-falantes, monitores e comunicação. Essa tecnologia incorporada permitirá que nosso ambiente forneça
os serviços IP que desejamos. Quando eu entrar em uma sala, a sala saberá que entrei. Serei capaz de me comunicar
com meu ambiente naturalmente, como no inglês falado; meu
solicitações gerarão respostas que apresentarão páginas da Web para mim a partir de exibições na parede, por meio do meu
óculos, como fala, hologramas e assim por diante.
Olhando um pouco mais longe, vejo um futuro de rede que inclui os seguintes componentes-chave adicionais. Vejo
agentes de software inteligentes implantados na rede cuja função é minerar dados, agir com base nesses dados,
observar tendências e realizar tarefas de forma dinâmica e adaptável. Vejo muito mais tráfego de rede gerado não tanto
por humanos, mas por esses dispositivos incorporados e esses agentes de software inteligentes. Vejo grandes
coleções de sistemas auto-organizados controlando essa vasta e rápida rede. Eu vejo grandes quantidades
de informações piscando
através desta rede instantaneamente com esta informação passando por enorme processamento e filtragem. A
Internet será essencialmente um sistema nervoso global generalizado. Vejo todas essas coisas e muito mais à
medida que avançamos no século XXI.
Que pessoas te inspiraram profissionalmente?
De longe, era Claude Shannon, do MIT, um pesquisador brilhante que tinha a capacidade de relacionar suas
ideias matemáticas com o mundo físico de maneiras altamente intuitivas. Ele estava na minha tese de doutorado
comitê.
Você tem algum conselho para os alunos que estão entrando no campo de redes/Internet?
A Internet e tudo o que ela permite é uma nova e vasta fronteira, cheia de desafios incríveis. Há espaço para
grandes inovações. Não fique limitado pela tecnologia atual. Estenda a mão e imagine o que poderia ser e, em
seguida, faça acontecer.
Capítulo 2 Camada de Aplicação
Os aplicativos de rede são a razão de ser de uma rede de computadores — se não pudéssemos conceber nenhum aplicativo útil,
não haveria necessidade de infraestrutura de rede e protocolos para suportá-los.
Desde o início da Internet, vários aplicativos úteis e divertidos foram criados.
Esses aplicativos têm sido a força motriz por trás do sucesso da Internet, motivando as pessoas em
lares, escolas, governos e empresas para tornar a Internet parte integrante de seu cotidiano
Atividades.
Os aplicativos da Internet incluem os clássicos aplicativos baseados em texto que se tornaram populares na década de 1970 e
1980: e-mail de texto, acesso remoto a computadores, transferência de arquivos e grupos de notícias. Eles incluem o aplicativo
matador de meados da década de 1990, a World Wide Web, abrangendo navegação na Web, pesquisa e comércio eletrônico.
Eles incluem mensagens instantâneas e compartilhamento de arquivos P2P, os dois aplicativos matadores introduzidos no final
do milênio. No novo milênio, aplicativos novos e altamente atraentes continuam a surgir, incluindo voz sobre IP e videoconferência,
como Skype, Facetime e Google
Pontos de encontro; vídeo gerado pelo usuário, como YouTube e filmes sob demanda, como Netflix; multijogador
jogos online como Second Life e World of Warcraft. Durante esse mesmo período, vimos o surgimento de uma nova geração
de aplicativos de redes sociais – como Facebook, Instagram, Twitter e WeChat – que criaram redes humanas atraentes
sobre a rede da Internet ou roteadores e links de comunicação. E, mais recentemente, junto com a chegada do smartphone,
houve uma profusão de aplicativos móveis baseados em localização, incluindo check-in popular, namoro e tráfego rodoviário.
aplicativos de previsão (como Yelp, Tinder, Waz e Yik Yak). Claramente, não houve desaceleração de novos e empolgantes
aplicativos da Internet. Talvez alguns dos leitores deste texto criem a próxima geração de aplicativos matadores da Internet!
Neste capítulo, estudamos os aspectos conceituais e de implementação de aplicativos de rede. Começamos definindo os
principais conceitos da camada de aplicativos, incluindo serviços de rede exigidos por aplicativos, clientes e servidores,
processos e interfaces da camada de transporte. Examinamos vários aplicativos de rede em detalhes, incluindo a Web, e-
mail, DNS, distribuição de arquivos ponto a ponto (P2P) e streaming de vídeo.
(O Capítulo 9 examinará mais detalhadamente os aplicativos de multimídia, incluindo streaming de vídeo e VoIP.) Em seguida,
abordaremos o desenvolvimento de aplicativos de rede, tanto em TCP quanto em UDP. Em particular, estudamos o soquete
interface e percorrer alguns aplicativos cliente-servidor simples em Python. Também fornecemos várias atribuições divertidas
e interessantes de programação de soquetes no final do capítulo.

A camada de aplicação é um lugar particularmente bom para começar nosso estudo de protocolos. É um terreno familiar.
Estamos familiarizados com muitos dos aplicativos que dependem dos protocolos que estudaremos. Isso nos dará uma
boa noção do que são os protocolos e nos apresentará muitas das mesmas questões que veremos novamente quando
estudarmos os protocolos de transporte, rede e camada de enlace.

2.1 Princípios de Aplicações de Rede
Suponha que você tenha uma ideia para um novo aplicativo de rede. Talvez este aplicativo seja um grande serviço à humanidade,
ou agrade seu professor, ou lhe traga uma grande riqueza, ou simplesmente seja divertido de desenvolver.
Seja qual for a motivação, vamos agora examinar como você transforma a ideia em um mundo real
aplicativo de rede.
No centro do desenvolvimento de aplicações de rede está a escrita de programas que rodam em diferentes sistemas finais.
e se comunicar uns com os outros através da rede. Por exemplo, na aplicação Web existem dois
programas distintos que se comunicam entre si: o programa do navegador em execução no host do usuário
(desktop, laptop, tablet, smartphone e assim por diante); e o programa do servidor Web em execução no host do servidor
Web. Como outro exemplo, em um sistema de compartilhamento de arquivos P2P, há um programa em cada host que
participa da comunidade de compartilhamento de arquivos. Nesse caso, os programas nos vários hosts podem ser semelhantes
ou idêntico.
Assim, ao desenvolver seu novo aplicativo, você precisa escrever um software que será executado em vários sistemas
finais. Este software pode ser escrito, por exemplo, em C, Java ou Python. Importante, você não
precisam escrever software que rode em dispositivos de núcleo de rede, como roteadores ou switches de camada de enlace.
Mesmo se você quisesse escrever um software aplicativo para esses dispositivos de núcleo de rede, não seria capaz de fazê-lo.
Como aprendemos no Capítulo 1 e mostrado anteriormente na Figura 1.24, os dispositivos do núcleo da rede não funcionam
na camada de aplicação, mas sim nas camadas inferiores — especificamente na camada de rede e abaixo dela.
Esse projeto básico — ou seja, confinar o software aplicativo aos sistemas finais — conforme mostrado na Figura 2.1, facilitou
o rápido desenvolvimento e implantação de uma vasta gama de aplicativos de rede.
Figura 2.1 A comunicação para uma aplicação de rede ocorre entre sistemas finais na camada
de aplicação
2.1.1 Arquiteturas de aplicativos de rede

Antes de mergulhar na codificação de software, você deve ter um amplo plano de arquitetura para seu aplicativo. Lembre-se
de que a arquitetura de um aplicativo é distintamente diferente da arquitetura de rede (por exemplo, o
arquitetura da Internet de cinco camadas discutida no Capítulo 1). Do ponto de vista do desenvolvedor de aplicativos, a
arquitetura de rede é fixa e fornece um conjunto específico de serviços aos aplicativos. A arquitetura do aplicativo, por outro
lado, é projetada pelo desenvolvedor do aplicativo e dita como o aplicativo é estruturado nos vários sistemas finais.
Ao escolher a arquitetura do aplicativo, um desenvolvedor de aplicativo provavelmente usará um dos dois paradigmas
arquitetônicos predominantes usados em aplicativos de rede modernos: a arquitetura cliente-servidor ou a arquitetura
ponto a ponto (P2P).
Em uma arquitetura cliente-servidor, há um host sempre ativo, chamado servidor, que atende a solicitações de muitos
outros hosts, chamados clientes. Um exemplo clássico é o aplicativo Web para o qual um servidor Web sempre ativo solicita
solicitações de navegadores em execução em hosts clientes. Quando um servidor Web recebe uma solicitação de um
objeto de um host cliente, ele responde enviando o objeto solicitado ao host cliente.
Observe que com a arquitetura cliente-servidor, os clientes não se comunicam diretamente uns com os outros; para
por exemplo, no aplicativo Web, dois navegadores não se comunicam diretamente. Outra característica de
a arquitetura cliente-servidor é que o servidor tem um endereço fixo e conhecido, chamado de endereço IP
(que discutiremos em breve). Como o servidor tem um endereço fixo e conhecido e como o servidor está sempre ligado, um
cliente sempre pode entrar em contato com o servidor enviando um pacote para o endereço IP do servidor.
Algumas das aplicações mais conhecidas com arquitetura cliente-servidor incluem Web, FTP, Telnet,
e correio eletrônico. A arquitetura cliente-servidor é mostrada na Figura 2.2(a).
Freqüentemente, em um aplicativo cliente-servidor, um host de servidor único é incapaz de acompanhar todas as solicitações
dos clientes. Por exemplo, um site popular de rede social pode rapidamente ficar sobrecarregado se tiver apenas um
servidor cuidando de todas as suas solicitações. Por esse motivo, um data center, que abriga um grande número de
hosts, é freqüentemente usado para criar um poderoso servidor virtual. Os serviços de Internet mais populares, como
motores de busca (por exemplo, Google, Bing, Baidu), comércio na Internet (por exemplo, Amazon, eBay, Alibaba), e-
mail baseado na Web (por exemplo, Gmail e Yahoo Mail), redes sociais (por exemplo, Facebook, Instagram, Twitter e
WeChat) — emprega um ou mais centros de dados. Conforme discutido na Seção 1.3.3, o Google tem de 30 a 50 centros
de dados distribuídos ao redor do mundo, que lidam coletivamente com pesquisa, YouTube, Gmail e outros serviços.
Um data center pode ter centenas de milhares de servidores, que devem ser alimentados e
mantido. Além disso, os provedores de serviços devem pagar custos recorrentes de interconexão e largura de banda para
enviar dados de seus data centers.
Em uma arquitetura P2P, há uma dependência mínima (ou nenhuma) de servidores dedicados em data centers. Em vez de
o aplicativo explora a comunicação direta entre pares de hosts conectados intermitentemente, chamados
pares. Os pares não são de propriedade do provedor de serviços, mas sim desktops e laptops controlados pelos usuários, com
a maioria dos
Figura 2.2 (a) Arquitetura cliente-servidor; (b) Arquitetura P2P

pares que residem em residências, universidades e escritórios. Porque os pares se comunicam sem passar
através de um servidor dedicado, a arquitetura é denominada peer-to-peer. Muitos dos aplicativos mais populares e com tráfego
intensivo de hoje são baseados em arquiteturas P2P. Esses aplicativos incluem compartilhamento de arquivos
(por exemplo, BitTorrent), aceleração de download assistida por pares (por exemplo, Xunlei) e telefonia e vídeo pela Internet
conferência (por exemplo, Skype). A arquitetura P2P é ilustrada na Figura 2.2(b). Mencionamos que algumas aplicações possuem
arquiteturas híbridas, combinando elementos cliente-servidor e P2P. Por exemplo, para
Em muitos aplicativos de mensagens instantâneas, os servidores são usados para rastrear os endereços IP dos usuários, mas as
mensagens de usuário para usuário são enviadas diretamente entre os hosts do usuário (sem passar por servidores intermediários).
Um dos recursos mais atraentes das arquiteturas P2P é sua autoescalabilidade. Por exemplo, em um aplicativo de
compartilhamento de arquivos P2P, embora cada par gere carga de trabalho solicitando arquivos, cada par também
adiciona capacidade de serviço ao sistema distribuindo arquivos para outros pares. As arquiteturas P2P também são econômicas,
pois normalmente não requerem infra-estrutura de servidor significativa e largura de banda do servidor (em contraste com
projetos de clientes-servidor com datacenters). No entanto, os aplicativos P2P enfrentam desafios de segurança, desempenho e
confiabilidade devido à sua estrutura altamente descentralizada.
2.1.2 Comunicação dos Processos
Antes de criar seu aplicativo de rede, você também precisa de um entendimento básico de como os programas, executados em
vários sistemas finais, se comunicam entre si. No jargão dos sistemas operacionais, não são os programas, mas os processos que
se comunicam. Um processo pode ser pensado como um programa que está sendo executado dentro de um sistema final. Quando os
processos estão sendo executados no mesmo sistema final, eles podem
comunicam entre si com comunicação entre processos, usando regras que são regidas pelo sistema operacional do sistema final.
Mas neste livro não estamos particularmente interessados em como os processos em
o mesmo host se comunica, mas em como os processos executados em hosts diferentes (com sistemas operacionais potencialmente
diferentes) se comunicam.
Processos em dois sistemas finais diferentes se comunicam trocando mensagens entre si.
a rede de computadores. Um processo de envio cria e envia mensagens para a rede; um recebimento
processo recebe essas mensagens e possivelmente responde enviando mensagens de volta. A Figura 2.1 ilustra que os
processos que se comunicam entre si residem na camada de aplicação da pilha de protocolos de cinco camadas.
Processos cliente e servidor
Um aplicativo de rede consiste em pares de processos que enviam mensagens entre si por meio de uma rede.
Por exemplo, no aplicativo da Web, um processo de navegador do cliente troca mensagens com um servidor da Web
processo. Em um sistema de compartilhamento de arquivos P2P, um arquivo é transferido de um processo em um ponto para
um processo em outro ponto. Para cada par de processos em comunicação, normalmente rotulamos um dos dois processos como
o cliente e o outro processo como o servidor. Com a Web, um navegador é um processo cliente e um servidor Web é um
processo servidor. Com o compartilhamento de arquivos P2P, o par que está baixando o arquivo é rotulado como o cliente e o
par que está fazendo o upload do arquivo é rotulado como o servidor.
Você deve ter observado que em alguns aplicativos, como no compartilhamento de arquivos P2P, um processo pode ser cliente e
servidor. De fato, um processo em um sistema de compartilhamento de arquivos P2P pode carregar e baixar arquivos.
No entanto, no contexto de qualquer sessão de comunicação entre um par de processos, podemos
ainda rotula um processo como o cliente e o outro processo como o servidor. Definimos o cliente e o servidor
processos da seguinte forma:
No contexto de uma sessão de comunicação entre um par de processos, o processo que inicia a comunicação (ou seja, contata
inicialmente o outro processo no início da sessão) é rotulado como o cliente. O processo que espera ser contatado para iniciar
a sessão é o servidor.
Na Web, um processo de navegador inicializa o contato com um processo de servidor Web; portanto, o processo do navegador é
o cliente e o processo do servidor Web é o servidor. No compartilhamento de arquivos P2P, quando o Peer A pede ao Peer B para
enviar um arquivo específico, o Peer A é o cliente e o Peer B é o servidor no contexto desta sessão de comunicação
específica. Quando não houver confusão, às vezes também usaremos a terminologia “lado do cliente e lado do servidor de um
aplicativo”. No final deste capítulo, analisaremos um código simples para os lados cliente e servidor de aplicativos de rede.
A interface entre o processo e a rede de computadores
Conforme observado acima, a maioria dos aplicativos consiste em pares de processos em comunicação, com os dois processos
em cada par enviando mensagens um para o outro. Qualquer mensagem enviada de um processo para outro deve ir
através da rede subjacente. Um processo envia mensagens e recebe mensagens do
rede por meio de uma interface de software chamada soquete. Vamos considerar uma analogia para nos ajudar a entender
processos e soquetes. Um processo é análogo a uma casa e sua tomada é análoga à sua porta. Quando
um processo deseja enviar uma mensagem para outro processo em outro host, ele empurra a mensagem para fora de sua porta
(soquete). Este processo de envio assume que existe uma infraestrutura de transporte do outro lado de sua porta que
transportará a mensagem até a porta do processo de destino. Assim que a mensagem chega ao host de destino, ela passa pela
porta do processo receptor (socket) e o processo receptor age na mensagem.
A Figura 2.3 ilustra a comunicação de soquete entre dois processos que se comunicam pela Internet.
(A Figura 2.3 assume que o protocolo de transporte subjacente usado pelos processos é o protocolo TCP da Internet.) Conforme
mostrado nesta figura, um soquete é a interface entre a camada de aplicativo e o
camada de transporte dentro de um host. Também é conhecido como Application Programming Interface (API)
entre o aplicativo e a rede, pois o socket é a interface de programação com a qual os aplicativos de rede são construídos. O
desenvolvedor do aplicativo tem controle de tudo no lado da camada de aplicativo do soquete, mas tem pouco controle sobre o
lado da camada de transporte do soquete. O único controle
que o desenvolvedor de aplicativos tem no lado da camada de transporte é (1) a escolha do protocolo de transporte e
(2) talvez a capacidade de corrigir alguns parâmetros da camada de transporte, como buffer máximo e máximo
tamanhos de segmentos (a serem abordados no Capítulo 3). Depois que o desenvolvedor do aplicativo escolhe um protocolo
de transporte (se houver uma opção disponível), o aplicativo é criado usando os serviços da camada de transporte fornecidos por
esse protocolo. Exploraremos soquetes com mais detalhes na Seção 2.7.
Processos de endereçamento
Para enviar correio postal para um determinado destino, o destino precisa ter um endereço.
Da mesma forma, para que um processo em execução em um host envie pacotes para um processo em execução em outro
host, o processo receptor precisa ter um endereço.
Figura 2.3 Processos de aplicativo, soquetes e protocolo de transporte subjacente
Para identificar o processo receptor, duas informações precisam ser especificadas: (1) o endereço do host e (2) um identificador que
especifica o processo receptor no host de destino.
Na Internet, o host é identificado por seu endereço IP. Discutiremos os endereços IP em detalhes em
Capítulo 4. Por enquanto, tudo o que precisamos saber é que um endereço IP é uma quantidade de 32 bits que podemos considerar
como uma identificação exclusiva do host. Além de saber o endereço do host para o qual uma mensagem é destinada, o
processo de envio também deve identificar o processo de recebimento (mais especificamente, o soquete de recebimento) em execução
no host. Esta informação é necessária porque, em geral, um host pode estar executando muitos
aplicativos de rede. Um número de porta de destino serve a esse propósito. Aplicativos populares foram
números de porta específicos atribuídos. Por exemplo, um servidor Web é identificado pela porta número 80. Um processo de servidor de
correio (usando o protocolo SMTP) é identificado pela porta número 25. Uma lista de portas bem conhecidas
números para todos os protocolos padrão da Internet podem ser encontrados em www.iana.org. Examinaremos os números de porta em detalhes
no Capítulo 3.
2.1.3 Serviços de transporte disponíveis para aplicativos
Lembre-se de que um soquete é a interface entre o processo de aplicação e o protocolo da camada de transporte.
O aplicativo no lado de envio envia mensagens por meio do soquete. Do outro lado do soquete, o protocolo da camada de transporte tem a
responsabilidade de enviar as mensagens para o soquete do
processo de recebimento.
Muitas redes, incluindo a Internet, fornecem mais de um protocolo de camada de transporte. Ao desenvolver um aplicativo, você deve
escolher um dos protocolos de camada de transporte disponíveis. Como você faz essa escolha? Provavelmente, você estudaria os serviços
fornecidos pelos protocolos de camada de transporte disponíveis e, em seguida, escolheria o protocolo com os serviços que melhor atendessem
às necessidades de seu aplicativo. O
A situação é semelhante à escolha de trem ou avião para viajar entre duas cidades. Você tem que escolher um ou outro, e cada meio de transporte
oferece serviços diferentes. (Por exemplo, o trem oferece embarque e desembarque no centro da cidade, enquanto o avião oferece um tempo de
viagem mais curto.)
Quais são os serviços que um protocolo da camada de transporte pode oferecer aos aplicativos que o invocam? Pudermos
classifique amplamente os possíveis serviços em quatro dimensões: transferência confiável de dados, taxa de transferência, temporização,
e segurança.
Transferência de dados confiável
Conforme discutido no Capítulo 1, os pacotes podem se perder em uma rede de computadores. Por exemplo, um pacote pode estourar um buffer
em um roteador ou pode ser descartado por um host ou roteador após ter alguns de seus bits corrompidos. Para muitos aplicativos - como
correio eletrônico, transferência de arquivos, acesso remoto ao host, transferências de documentos da Web e aplicativos financeiros - a
perda de dados pode ter consequências devastadoras (no
último caso, para o banco ou para o cliente!). Assim, para dar suporte a essas aplicações, algo deve ser feito para garantir que os dados enviados
por uma ponta da aplicação sejam entregues de forma correta e completa para a outra ponta da aplicação. Se um protocolo fornece um
serviço de entrega de dados garantido, diz-se que fornece transferência de dados confiável. Um serviço importante que um protocolo da
camada de transporte pode potencialmente fornecer a um aplicativo é a transferência de dados confiável entre processos. quando um transporte
protocolo fornece esse serviço, o processo de envio pode apenas passar seus dados para o soquete e saber com
total confiança de que os dados chegarão sem erros no processo de recebimento.
Quando um protocolo da camada de transporte não fornece transferência de dados confiável, alguns dos dados enviados pelo
processo de envio pode nunca chegar ao processo de recebimento. Isso pode ser aceitável para aplicativos tolerantes a perdas,
principalmente aplicativos multimídia, como áudio/vídeo de conversação, que podem tolerar certa quantidade de perda de dados. Nesses
aplicativos multimídia, a perda de dados pode resultar em uma pequena falha no áudio/vídeo — não uma deficiência crucial.
Taxa de transferência
No Capítulo 1 , introduzimos o conceito de taxa de transferência disponível, que, no contexto de uma sessão de
comunicação entre dois processos ao longo de um caminho de rede, é a taxa na qual o envio
processo pode entregar bits para o processo receptor. Porque outras sessões estarão compartilhando a largura de banda
ao longo do caminho da rede e, como essas outras sessões vão e vêm, a taxa de transferência disponível pode flutuar com o
tempo. Essas observações levam a outro serviço natural que um transporte
protocolo de camada poderia fornecer, ou seja, taxa de transferência disponível garantida em alguma taxa especificada. Com tamanha
um serviço, o aplicativo pode solicitar uma taxa de transferência garantida de r bits/s e o protocolo de transporte garantirá que a taxa de
transferência disponível seja sempre de pelo menos r bits/s. Tal serviço de taxa de transferência garantida atrairia muitos
aplicativos. Por exemplo, se um aplicativo de telefonia via Internet codifica voz a 32 kbps, ele precisa enviar dados para a rede e fazer
com que os dados sejam entregues ao
recebendo aplicação a esta taxa. Se o protocolo de transporte não puder fornecer essa taxa de transferência, o aplicativo precisará
codificar em uma taxa mais baixa (e receber taxa de transferência suficiente para sustentar essa taxa de codificação mais baixa) ou
pode ter que desistir, pois receber, digamos, metade da taxa de transferência necessária é de pouco ou nenhum uso para este
aplicativo de telefonia via Internet. Os aplicativos que têm requisitos de taxa de transferência são considerados aplicativos
sensíveis à largura de banda. Muitos aplicativos multimídia atuais são sensíveis à largura de banda,
embora alguns aplicativos multimídia possam usar técnicas de codificação adaptáveis para codificar voz ou vídeo digitalizado a uma taxa
que corresponda à taxa de transferência atualmente disponível.
Embora os aplicativos sensíveis à largura de banda tenham requisitos de taxa de transferência específicos, os aplicativos elásticos podem
use o máximo ou o mínimo de throughput que estiver disponível. Correio eletrônico, transferência de arquivos,
e as transferências da Web são todas aplicações elásticas. Claro, quanto mais rendimento, melhor. Existe um ditado que diz que
ninguém pode ser muito rico, muito magro ou ter muito rendimento!
Tempo
Um protocolo da camada de transporte também pode fornecer garantias de tempo. Tal como acontece com as garantias de
throughput, as garantias de tempo podem vir de várias formas. Um exemplo de garantia pode ser que cada bit que o remetente injeta no
soquete chegue ao soquete do receptor não mais do que 100 ms depois. Tal serviço seria atraente para aplicativos interativos em
tempo real, como telefonia pela Internet, ambientes virtuais, teleconferência e jogos multijogador, todos os quais exigem restrições
de tempo apertadas em
entrega de dados, a fim de ser eficaz. (Veja o Capítulo 9, [Gauthier 1999; Ramjee 1994].) Longos atrasos na telefonia via Internet,
por exemplo, tendem a resultar em pausas anormais na conversa; em um multijogador
jogo ou ambiente interativo virtual, um longo atraso entre realizar uma ação e ver a resposta
do ambiente (por exemplo, de outro player no final de uma conexão de ponta a ponta) torna o aplicativo menos realista. Para aplicações
não em tempo real, o atraso mais baixo é sempre preferível ao atraso mais alto, mas nenhuma restrição rígida é colocada nos
atrasos de ponta a ponta.
Segurança
Por fim, um protocolo de transporte pode fornecer a um aplicativo um ou mais serviços de segurança. Por exemplo, no host de envio,
um protocolo de transporte pode criptografar todos os dados transmitidos pelo processo de envio e, em
o host receptor, o protocolo da camada de transporte pode descriptografar os dados antes de entregá-los ao
processo de recebimento. Tal serviço forneceria confidencialidade entre os dois processos, mesmo que o
os dados são de alguma forma observados entre os processos de envio e recebimento. Um protocolo de transporte também pode
fornecer outros serviços de segurança além da confidencialidade, incluindo integridade de dados e ponto final
autenticação, tópicos que abordaremos em detalhes no Capítulo 8.
2.1.4 Serviços de transporte fornecidos pela Internet
Até este ponto, consideramos os serviços de transporte que uma rede de computadores poderia fornecer em geral. Vamos agora ser
mais específicos e examinar o tipo de serviço de transporte fornecido pela Internet. A Internet (e, mais geralmente, as redes
TCP/IP) disponibiliza dois protocolos de transporte para
aplicações, UDP e TCP. Quando você (como desenvolvedor de aplicativos) cria um novo aplicativo de rede para a Internet, uma das
primeiras decisões que você deve tomar é se deve usar UDP ou TCP. Cada um de
esses protocolos oferecem um conjunto diferente de serviços para os aplicativos de chamada. A Figura 2.4 mostra os requisitos
de serviço para alguns aplicativos selecionados.
Serviços TCP
O modelo de serviço TCP inclui um serviço orientado a conexão e um serviço confiável de transferência de dados.
Quando um aplicativo invoca o TCP como seu protocolo de transporte, o aplicativo recebe ambos
serviços do TCP.
Serviço orientado à conexão. O TCP faz com que o cliente e o servidor troquem informações de controle da camada de
transporte entre si antes que as mensagens no nível do aplicativo comecem a fluir. Esse chamado procedimento de
handshaking alerta o cliente e o servidor, permitindo que eles se preparem para um ataque violento de pacotes. Após a fase
de handshaking, diz-se que existe uma conexão TCP entre os soquetes

Figura 2.4 Requisitos de aplicativos de rede selecionados
dos dois processos. A conexão é uma conexão full-duplex em que os dois processos podem enviar mensagens um ao
outro pela conexão ao mesmo tempo. Quando o aplicativo terminar
enviando mensagens, ele deve interromper a conexão. No Capítulo 3 , discutiremos detalhadamente o serviço orientado à
conexão e examinaremos como ele é implementado.
Serviço confiável de transferência de dados. Os processos de comunicação podem confiar no TCP para entregar
todos os dados enviados sem erro e na ordem correta. Quando um lado do aplicativo passa um fluxo de bytes para
um soquete, ele pode contar com o TCP para entregar o mesmo fluxo de bytes ao soquete receptor, sem bytes ausentes
ou duplicados.
O TCP também inclui um mecanismo de controle de congestionamento, um serviço para o bem-estar geral da Internet
e não para o benefício direto dos processos de comunicação. O mecanismo de controle de congestionamento do
TCP limita um processo de envio (cliente ou servidor) quando a rede está congestionada entre
remetente e destinatário. Como veremos
FOCO NA SEGURANÇA
PROTEGENDO TCP
Nem o TCP nem o UDP fornecem qualquer criptografia - os dados que o processo de envio passa para seu soquete
são os mesmos dados que trafegam pela rede até o processo de destino. Então, para
por exemplo, se o processo de envio enviar uma senha em texto não criptografado (ou seja, não criptografada) para
seu soquete, a senha em texto não criptografado percorrerá todos os links entre o remetente e o destinatário,
podendo ser detectada e descoberta em qualquer um dos links intermediários. Porque a privacidade e outras seguranças
questões tornaram-se críticas para muitas aplicações, a comunidade da Internet desenvolveu um
aprimoramento para TCP, chamado Secure Sockets Layer (SSL). TCP aprimorado com SSL não apenas
faz tudo o que o TCP tradicional faz, mas também fornece serviços críticos de segurança processo a processo, incluindo
criptografia, integridade de dados e autenticação de ponto final. Ressaltamos que o SSL não é um terceiro protocolo de
transporte da Internet, no mesmo nível do TCP e do UDP, mas sim um aprimoramento do TCP, sendo os aprimoramentos
implementados na camada de aplicação. Em
em particular, se um aplicativo deseja usar os serviços de SSL, ele precisa incluir o código SSL (bibliotecas e classes
altamente otimizadas existentes) nos lados cliente e servidor do aplicativo. O SSL tem sua própria API de soquete
que é semelhante à tradicional API de soquete TCP. Quando um aplicativo usa SSL, o processo de envio passa dados de
texto não criptografado para o soquete SSL; O SSL no host de envio criptografa os dados e passa os dados criptografados
para o soquete TCP. Os dados criptografados trafegam pela Internet até o soquete TCP no processo de recebimento. O
o soquete de recebimento passa os dados criptografados para SSL, que descriptografa os dados. Por fim, o SSL passa
os dados de texto não criptografado por meio de seu soquete SSL para o processo de recebimento. Cobriremos o SSL em
alguns detalhes no Capítulo 8.
No Capítulo 3, o controle de congestionamento TCP também tenta limitar cada conexão TCP à sua parcela justa de
largura de banda da rede.
Serviços UDP
O UDP é um protocolo de transporte leve e sem frescuras, que fornece serviços mínimos. O UDP é sem conexão, então não há
handshaking antes que os dois processos comecem a se comunicar. UDP fornece um não confiável
serviço de transferência de dados - isto é, quando um processo envia uma mensagem para um soquete UDP, o UDP não oferece
nenhuma garantia de que a mensagem chegará ao processo receptor. Além disso, as mensagens que chegam ao processo de recebimento
podem chegar fora de ordem.
O UDP não inclui um mecanismo de controle de congestionamento, portanto, o lado de envio do UDP pode bombear dados para
a camada abaixo (a camada de rede) como bem entender. (Observe, no entanto, que a taxa de transferência real de ponta a ponta
pode ser menor que essa taxa devido à capacidade de transmissão limitada dos links intervenientes ou devido ao congestionamento).
Serviços não fornecidos pelos protocolos de transporte da Internet
Organizamos os serviços de protocolo de transporte em quatro dimensões: transferência confiável de dados, taxa de transferência, tempo
e segurança. Quais desses serviços são fornecidos pelo TCP e pelo UDP? Já observamos que o TCP fornece transferência de dados
confiável de ponta a ponta. E também sabemos que o TCP pode ser facilmente aprimorado na camada de aplicativo com SSL para fornecer
serviços de segurança. Mas em nossa breve descrição do TCP e
UDP, notavelmente faltava qualquer menção de throughput ou garantias de tempo - serviços não fornecidos pelos protocolos de
transporte da Internet de hoje. Isso significa que aplicativos sensíveis ao tempo, como telefonia via Internet, não podem ser executados na
Internet atual? A resposta é claramente não - a Internet hospeda aplicativos sensíveis ao tempo há muitos anos. Esses aplicativos
geralmente funcionam muito bem porque

eles foram projetados para lidar, na medida do possível, com essa falta de garantia. Bem
investigue vários desses truques de projeto no Capítulo 9. No entanto, o projeto inteligente tem suas limitações quando o
atraso é excessivo ou o throughput de ponta a ponta é limitado. Em resumo, a Internet de hoje muitas vezes pode
fornecer serviço satisfatório para aplicativos sensíveis ao tempo, mas não pode fornecer nenhum tempo ou taxa de transferência
garantias.
A Figura 2.5 indica os protocolos de transporte usados por alguns aplicativos populares da Internet. Vemos que e-mail, acesso
de terminal remoto, Web e transferência de arquivos usam TCP. Esses aplicativos escolheram
TCP principalmente porque o TCP fornece transferência de dados confiável, garantindo que todos os dados cheguem ao seu
destino. Como os aplicativos de telefonia pela Internet (como o Skype) geralmente toleram algumas perdas, mas exigem uma
taxa mínima para serem eficazes, os desenvolvedores de aplicativos de telefonia pela Internet geralmente preferem executar
seus aplicativos em UDP, contornando assim o mecanismo de controle de congestionamento do TCP e as sobrecargas de
pacotes. Mas como muitos firewalls são configurados para bloquear (a maioria dos tipos de) tráfego UDP, os aplicativos de
telefonia via Internet geralmente são projetados para usar o TCP como backup se a comunicação UDP falhar.
Figura 2.5 Aplicações populares da Internet, seus protocolos de camada de aplicação e seus protocolos de transporte
subjacentes
2.1.5 Protocolos da Camada de Aplicação
Acabamos de aprender que os processos de rede se comunicam enviando mensagens para sockets. Mas como essas
mensagens são estruturadas? Quais são os significados dos vários campos nas mensagens? Quando os processos enviam
as mensagens? Essas questões nos levam ao domínio dos protocolos da camada de aplicação. Um protocolo de camada
de aplicativo define como um aplicativo processa,
rodando em sistemas finais diferentes, passam mensagens uns para os outros. Em particular, um protocolo de camada
de aplicação define:
Os tipos de mensagens trocadas, por exemplo, mensagens de solicitação e mensagens de resposta
A sintaxe dos vários tipos de mensagem, como os campos na mensagem e como os campos são delineados
A semântica dos campos, ou seja, o significado das informações nos campos
Regras para determinar quando e como um processo envia mensagens e responde a mensagens
Alguns protocolos da camada de aplicação são especificados em RFCs e, portanto, são de domínio público. Para
Por exemplo, o protocolo da camada de aplicativos da Web, HTTP (o HyperText Transfer Protocol [RFC 2616]), está disponível
como um RFC. Se um desenvolvedor de navegador seguir as regras do HTTP RFC, o navegador poderá recuperar páginas da
Web de qualquer servidor da Web que também tenha seguido as regras do HTTP RFC. Muitos outros protocolos da camada
de aplicação são proprietários e intencionalmente não estão disponíveis no domínio público. Por exemplo, o Skype usa
protocolos de camada de aplicativo proprietários.
É importante distinguir entre aplicativos de rede e protocolos de camada de aplicativo. Um
o protocolo da camada de aplicação é apenas uma parte de uma aplicação de rede (embora seja uma parte muito importante
da aplicação do nosso ponto de vista!). Vejamos alguns exemplos. A Web é um aplicativo cliente-servidor que permite
aos usuários obter documentos de servidores Web sob demanda. O aplicativo da Web consiste em muitos componentes,
incluindo um padrão para formatos de documento (isto é, HTML), Web
navegadores (por exemplo, Firefox e Microsoft Internet Explorer), servidores da Web (por exemplo, servidores Apache e
Microsoft) e um protocolo de camada de aplicativo. O protocolo da camada de aplicativos da Web, HTTP,
define o formato e a sequência de mensagens trocadas entre o navegador e o servidor Web. Assim, o HTTP é apenas
uma parte (embora importante) do aplicativo da Web. Como outro exemplo, um aplicativo de e-mail da Internet também
possui muitos componentes, incluindo servidores de correio que hospedam as caixas de correio dos usuários;
clientes de e-mail (como o Microsoft Outlook) que permitem aos usuários ler e criar mensagens; a
padrão para definir a estrutura de uma mensagem de e-mail; e protocolos da camada de aplicação que definem como
as mensagens são transmitidas entre servidores, como as mensagens são transmitidas entre servidores e clientes de e-mail
e como o conteúdo dos cabeçalhos das mensagens deve ser interpretado. O principal protocolo da camada de aplicação
para correio eletrônico é SMTP (Simple Mail Transfer Protocol) [RFC 5321]. Assim, o principal protocolo da camada
de aplicação do e-mail, o SMTP, é apenas uma parte (embora importante) da aplicação de e-mail.
2.1.6 Aplicações de rede abordadas neste livro
Novos aplicativos de domínio público e proprietários da Internet estão sendo desenvolvidos todos os dias. Em vez de cobrir
um grande número de aplicativos da Internet de maneira enciclopédica, optamos por nos concentrar em um pequeno número
de aplicativos que são difundidos e importantes. Neste capítulo, discutimos cinco
aplicações importantes: a Web, correio eletrônico, streaming de vídeo do serviço de diretório e P2P
formulários. Discutiremos primeiro a Web, não apenas porque é um aplicativo extremamente popular, mas também porque
seu protocolo de camada de aplicativo, HTTP, é direto e fácil de entender. Em seguida, discutimos o correio eletrônico, o
primeiro aplicativo matador da Internet. O e-mail é mais complexo do que a Web no

sentido que ele faz uso não de um, mas de vários protocolos da camada de aplicação. Depois do e-mail, abordamos o DNS,
que fornece um serviço de diretório para a Internet. A maioria dos usuários não interage diretamente com o DNS; em vez disso,
os usuários invocam o DNS indiretamente por meio de outros aplicativos (incluindo a Web, transferência de arquivos e
correio eletrônico). O DNS ilustra bem como uma parte da funcionalidade principal da rede (nome da rede para rede
tradução de endereço) pode ser implementada na camada de aplicação na Internet. Em seguida, discutimos os aplicativos
de compartilhamento de arquivos P2P e concluímos nosso estudo de aplicativos discutindo o streaming de vídeo sob demanda,
incluindo a distribuição de vídeo armazenado em redes de distribuição de conteúdo. No Capítulo 9, abordaremos

os aplicativos multimídia com mais profundidade, incluindo voz sobre IP e videoconferência.
2.2 A Web e o HTTP
Até o início da década de 1990, a Internet era usada principalmente por pesquisadores, acadêmicos e estudantes universitários
para fazer login em hosts remotos, transferir arquivos de hosts locais para hosts remotos e vice-versa, receber e enviar notícias e
receber e enviar correio eletrônico. . Embora essas aplicações fossem (e continuem a
ser) extremamente útil, a Internet era essencialmente desconhecida fora do meio acadêmico e de pesquisa
comunidades. Então, no início da década de 1990, um novo e importante aplicativo entrou em cena - o World Wide
Web [Berners-Lee 1994]. A Web foi o primeiro aplicativo da Internet que chamou a atenção do público em geral. Mudou
drasticamente, e continua a mudar, como as pessoas interagem dentro e fora de seus ambientes de trabalho. Ele elevou a Internet
de apenas uma das muitas redes de dados para essencialmente a única rede de dados.
Talvez o que mais atrai os usuários seja o fato de a Web operar sob demanda. Os usuários recebem o que querem, quando
querem. Isso é diferente do rádio e da televisão tradicionais, que forçam os usuários a sintonizar quando o provedor de
conteúdo disponibiliza o conteúdo. Além de estar disponível sob demanda, a Web tem muitos outros recursos
maravilhosos que as pessoas adoram e apreciam. É extremamente fácil para qualquer pessoa disponibilizar informações na
Web - todos podem se tornar um editor a um custo extremamente baixo. Hiperlinks e mecanismos de busca nos ajudam a navegar
por um oceano de informações.
Fotos e vídeos estimulam nossos sentidos. Formulários, JavaScript, applets Java e muitos outros dispositivos nos permitem
interagir com páginas e sites. E a Web e seus protocolos servem como uma plataforma para o YouTube, e-mail baseado
na Web (como o Gmail) e a maioria dos aplicativos de Internet móvel, incluindo
Instagram e Google Maps.
2.2.1 Visão geral do HTTP
O protocolo de transferência de hipertexto (HTTP), o protocolo da camada de aplicativos da Web, está no centro do
Rede. É definido em [RFC 1945] e [RFC 2616]. O HTTP é implementado em dois programas: um programa cliente e um
programa servidor. O programa cliente e o programa servidor, executando em extremidades diferentes
sistemas, conversam entre si trocando mensagens HTTP. HTTP define a estrutura desses
mensagens e como o cliente e o servidor trocam as mensagens. Antes de explicar o HTTP em detalhes,
deve revisar alguma terminologia da Web.
Uma página da Web (também chamada de documento) consiste em objetos. Um objeto é simplesmente um arquivo — como um
arquivo HTML, uma imagem JPEG, um applet Java ou um videoclipe — que pode ser acessado por um único URL. Mais Web
as páginas consistem em um arquivo HTML básico e vários objetos referenciados. Por exemplo, se uma página da Web
contém texto HTML e cinco imagens JPEG, a página da Web possui seis objetos: o arquivo HTML básico mais as cinco imagens.
O arquivo HTML básico faz referência a outros objetos na página com os URLs dos objetos.
Cada URL tem dois componentes: o nome do host do servidor que hospeda o objeto e o nome do caminho do objeto. Por exemplo,
o URL
http:// www.someSchool.edu/ someDepartment/ picture.gif
tem www.someSchool.edu como nome de host e /someDepartment/ picture.gif como nome de caminho. Como os
navegadores da Web (como o Internet Explorer e o Firefox) implementam o lado do cliente do HTTP, no contexto da Web,
usaremos as palavras navegador e cliente de forma intercambiável. Os servidores da Web, que implementam o lado do
servidor do HTTP, abrigam objetos da Web, cada um endereçável por uma URL.
Servidores Web populares incluem Apache e Microsoft Internet Information Server.
O HTTP define como os clientes Web solicitam páginas Web de servidores Web e como os servidores transferem páginas
Web para clientes. Discutiremos a interação entre cliente e servidor em detalhes mais tarde, mas o
A ideia é ilustrada na Figura 2.6. Quando um usuário solicita uma página da Web (por exemplo, clica em um hiperlink), o
navegador envia mensagens de solicitação HTTP para os objetos da página ao servidor. O servidor
recebe as solicitações e responde com mensagens de resposta HTTP que contêm os objetos.
O HTTP usa o TCP como seu protocolo de transporte subjacente (em vez de rodar sobre o UDP). o HTTP
primeiro cliente inicia uma conexão TCP com o servidor. Uma vez estabelecida a conexão, o navegador
e os processos do servidor acessam o TCP por meio de suas interfaces de soquete. Conforme descrito na Seção 2.1, no lado
do cliente, a interface socket é a porta entre o processo cliente e a conexão TCP; no lado do servidor é a porta entre o processo
do servidor e a conexão TCP. O cliente envia mensagens de solicitação HTTP para sua interface de soquete e recebe
mensagens de resposta HTTP de seu
interface de soquete. Da mesma forma, o servidor HTTP recebe mensagens de solicitação

Figura 2.6 Comportamento de solicitação-resposta HTTP
de sua interface de soquete e envia mensagens de resposta para sua interface de soquete. Uma vez que o cliente envia um
mensagem em sua interface socket, a mensagem está fora das mãos do cliente e está “nas mãos” do TCP.
Lembre-se da Seção 2.1 que o TCP fornece um serviço confiável de transferência de dados para o HTTP. Isso implica que
cada mensagem de requisição HTTP enviada por um processo cliente eventualmente chega intacta ao servidor; da mesma
forma, cada mensagem de resposta HTTP enviada pelo processo do servidor eventualmente chega intacta ao cliente. Aqui
vemos uma das grandes vantagens de uma arquitetura em camadas - o HTTP não precisa se preocupar com dados perdidos
ou com os detalhes de como o TCP se recupera de perdas ou reordenamento de dados dentro da rede. Esse é o trabalho
do TCP e dos protocolos nas camadas inferiores da pilha de protocolos.
É importante observar que o servidor envia os arquivos solicitados aos clientes sem armazenar nenhuma informação
de estado sobre o cliente. Se um determinado cliente solicitar o mesmo objeto duas vezes em um período de alguns
segundos, o servidor não responde dizendo que acabou de entregar o objeto ao cliente; em vez disso, o servidor reenvia o
objeto, pois esqueceu completamente o que fez anteriormente. Como um servidor HTTP não mantém informações sobre os
clientes, o HTTP é considerado um protocolo sem estado. Nós também comentamos
que a Web utiliza a arquitetura de aplicação cliente-servidor, conforme descrito na Seção 2.1. Um servidor Web está sempre
ligado, com um endereço IP fixo, e atende solicitações de potencialmente milhões de diferentes
navegadores.
2.2.2 Conexões Não Persistentes e Persistentes
Em muitos aplicativos da Internet, o cliente e o servidor se comunicam por um longo período de tempo, com o cliente fazendo
uma série de solicitações e o servidor respondendo a cada uma delas. Dependendo do aplicativo e de como o aplicativo está
sendo usado, a série de solicitações pode ser feita consecutivamente, periodicamente em intervalos regulares ou intermitentemente.
Quando essa interação cliente-servidor está ocorrendo
TCP, o desenvolvedor de aplicativos precisa tomar uma decisão importante - cada solicitação/resposta deve
par deve ser enviado por uma conexão TCP separada ou todas as solicitações e suas respostas correspondentes devem
ser enviadas pela mesma conexão TCP? Na primeira abordagem, diz-se que o aplicativo usa conexões não persistentes;
e na última abordagem, conexões persistentes. Para obter uma compreensão profunda desse problema de design, vamos
examinar as vantagens e desvantagens de persistência
conexões no contexto de um aplicativo específico, ou seja, HTTP, que pode usar tanto conexões não persistentes quanto
conexões persistentes. Embora o HTTP use conexões persistentes em seu modo padrão, clientes e servidores HTTP
podem ser configurados para usar conexões não persistentes.
HTTP com conexões não persistentes

Vamos percorrer as etapas de transferência de uma página da Web do servidor para o cliente no caso de conexões
não persistentes. Vamos supor que a página consista em um arquivo HTML básico e 10 imagens JPEG e que todos os 11
desses objetos residam no mesmo servidor. Além disso, suponha que a URL para o arquivo HTML base
é
http:// www.someSchool.edu/ someDepartment/ home.index
Aqui está o que acontece:
1. O processo do cliente HTTP inicia uma conexão TCP com o servidor www.someSchool.edu em
número da porta 80, que é o número da porta padrão para HTTP. Associado à conexão TCP,
haverá um soquete no cliente e um soquete no servidor.
2. O cliente HTTP envia uma mensagem de solicitação HTTP ao servidor por meio de seu soquete. O pedido
a mensagem inclui o nome do caminho /someDepartment/ home .index . (Discutiremos as mensagens HTTP com
mais detalhes abaixo.)
3. O processo do servidor HTTP recebe a mensagem de solicitação por meio de seu soquete, recupera o objeto
/ someDepartment/ home.index de seu armazenamento (RAM ou disco), encapsula o objeto em uma mensagem de
resposta HTTP e envia a mensagem de resposta ao cliente por meio de seu soquete.
4. O processo do servidor HTTP diz ao TCP para fechar a conexão TCP. (Mas o TCP não encerra a conexão até que
tenha certeza de que o cliente recebeu a resposta
mensagem intacta.)
5. O cliente HTTP recebe a mensagem de resposta. A conexão TCP termina. O

mensagem indica que o objeto encapsulado é um arquivo HTML. O cliente extrai o arquivo de
a mensagem de resposta, examina o arquivo HTML e encontra referências aos 10 objetos JPEG.
6. As primeiras quatro etapas são repetidas para cada um dos objetos JPEG referenciados.
À medida que o navegador recebe a página da Web, ele exibe a página para o usuário. Dois navegadores diferentes podem
interpretar (ou seja, exibir para o usuário) uma página da Web de maneiras um pouco diferentes. HTTP não tem nada a ver
com a forma como uma página da Web é interpretada por um cliente. As especificações HTTP ([RFC 1945] e [RFC 2616])
definem apenas o protocolo de comunicação entre o programa cliente HTTP e o servidor HTTP
programa.
As etapas acima ilustram o uso de conexões não persistentes, onde cada conexão TCP é fechada depois que o servidor envia
o objeto — a conexão não persiste para outros objetos. Observe que cada conexão TCP transporta exatamente uma mensagem
de solicitação e uma mensagem de resposta. Assim, neste exemplo, quando um usuário solicita a página da Web, são geradas
11 conexões TCP.
Nas etapas descritas acima, fomos intencionalmente vagos sobre se o cliente obtém os 10
JPEGs em 10 conexões TCP seriais ou se alguns dos JPEGs são obtidos em conexões TCP paralelas. De fato, os
usuários podem configurar navegadores modernos para controlar o grau de paralelismo. Em seus modos padrão, a
maioria dos navegadores abre de 5 a 10 conexões TCP paralelas, e cada uma dessas conexões
lida com uma transação de solicitação-resposta. Se o usuário preferir, o número máximo de paralelos
as conexões podem ser definidas para uma, caso em que as 10 conexões são estabelecidas em série. Como veremos
no próximo capítulo, o uso de conexões paralelas reduz o tempo de resposta.
Antes de continuar, vamos fazer um cálculo de fundo de envelope para estimar a quantidade de tempo que
decorre desde quando um cliente solicita o arquivo HTML base até que o arquivo inteiro seja recebido pelo cliente.
Para isso, definimos o tempo de ida e volta (RTT), que é o tempo que um pequeno pacote leva para ir do cliente ao
servidor e retornar ao cliente. O RTT inclui atrasos de propagação de pacotes, atrasos de enfileiramento de
pacotes em roteadores e switches intermediários e atrasos de processamento de pacotes. (Estes atrasos foram
discutido na Seção 1.4.) Agora considere o que acontece quando um usuário clica em um hiperlink. Como mostrado em
Figura 2.7, isso faz com que o navegador inicie uma conexão TCP entre o navegador e o servidor Web; isso
envolve um “aperto de mão de três vias” — o cliente envia um pequeno segmento TCP ao servidor, o servidor confirma
e responde com um pequeno segmento TCP e, finalmente, o cliente confirma de volta ao servidor. As duas primeiras
partes do handshake de três vias levam um RTT. Depois de completar o
primeiras duas partes do handshake, o cliente envia a mensagem de requisição HTTP combinada com a terceira
parte do handshake de três vias (a confirmação) na conexão TCP. Assim que a mensagem de solicitação chegar
em
Figura 2.7 Cálculo do verso do envelope para o tempo necessário para solicitar e receber um arquivo HTML
o servidor, o servidor envia o arquivo HTML para a conexão TCP. Esta solicitação/resposta HTTP come
outro RTT. Assim, aproximadamente, o tempo total de resposta é dois RTTs mais o tempo de transmissão no
servidor do arquivo HTML.
HTTP com conexões persistentes
Conexões não persistentes têm algumas deficiências. Primeiro, uma nova conexão deve ser
estabelecidos e mantidos para cada objeto solicitado. Para cada uma dessas conexões, os buffers TCP devem ser alocados e as
variáveis TCP devem ser mantidas no cliente e no servidor. Isso pode sobrecarregar significativamente o servidor da Web, que
pode estar atendendo a solicitações de centenas de clientes diferentes
simultaneamente. Em segundo lugar, como acabamos de descrever, cada objeto sofre um atraso de entrega de dois RTTs - um
RTT para estabelecer a conexão TCP e um RTT para solicitar e receber um objeto.
Com conexões persistentes HTTP 1.1, o servidor deixa a conexão TCP aberta após enviar um
resposta. Solicitações e respostas subseqüentes entre o mesmo cliente e servidor podem ser enviadas
a mesma conexão. Em particular, uma página da Web inteira (no exemplo acima, o arquivo HTML básico e as 10 imagens) pode
ser enviada por uma única conexão TCP persistente. Além disso, várias páginas da Web que residem no mesmo servidor
podem ser enviadas do servidor para o mesmo cliente por meio de uma única conexão TCP persistente. Essas requisições de
objetos podem ser feitas back-to-back, sem esperar por respostas a pendências.
solicitações (pipelining). Normalmente, o servidor HTTP fecha uma conexão quando não é usado por um determinado tempo (um
intervalo de tempo limite configurável). Quando o servidor recebe as solicitações back-to-back, ele envia os objetos back-to-
back. O modo padrão de HTTP usa conexões persistentes com pipelining. Maioria
recentemente, o HTTP/2 [RFC 7540] baseia-se no HTTP 1.1, permitindo que várias solicitações e respostas sejam
intercaladas na mesma conexão e um mecanismo para priorizar solicitações e respostas de mensagens HTTP nessa conexão.
Vamos comparar quantitativamente o desempenho de não persistentes e
conexões persistentes nos problemas de lição de casa dos Capítulos 2 e 3. Você também é encorajado a ver [Heidemann 1997;
Nielsen 1997; RFC 7540].
2.2.3 Formato de Mensagem HTTP
As especificações HTTP [RFC 1945; RFC 2616; RFC 7540] incluem as definições dos formatos de mensagem HTTP.
Existem dois tipos de mensagens HTTP, mensagens de solicitação e mensagens de resposta,
ambos são discutidos abaixo.
Mensagem de solicitação HTTP

Abaixo, fornecemos uma mensagem de solicitação HTTP típica:
GET / somedir/ page.html HTTP/ 1.1

Host: www.someschool.edu
Conexão: fechar
Agente de usuário: Mozilla/ 5.0
Aceitar-idioma: fr
Podemos aprender muito observando atentamente esta mensagem de solicitação simples. Em primeiro lugar, vemos que o
A mensagem é escrita em texto ASCII comum, de modo que seu ser humano comum com conhecimento de informática possa
lê-la. Em segundo lugar, vemos que a mensagem consiste em cinco linhas, cada uma seguida por um retorno de carro e uma
alimentação de linha. A última linha é seguida por um retorno de carro adicional e alimentação de linha. Embora este particular
mensagem de solicitação tiver cinco linhas, uma mensagem de solicitação pode ter muito mais linhas ou apenas uma linha.
A primeira linha de uma mensagem de solicitação HTTP é chamada de linha de solicitação; as linhas subseqüentes são
chamadas de linhas de cabeçalho. A linha de solicitação tem três campos: o campo de método, o campo de URL e o campo HTTP
campo de versão. O campo do método pode assumir vários valores diferentes, incluindo GET, POST, HEAD, PUT e
DELETE . A grande maioria das mensagens de solicitação HTTP usa o método GET . O método GET é utilizado quando o
navegador solicita um objeto, sendo o objeto solicitado identificado na URL
campo. Neste exemplo, o navegador está solicitando o objeto /somedir/ page.html . A versão é autoexplicativa; neste exemplo,
o navegador implementa a versão HTTP/1.1.
Agora vamos ver as linhas de cabeçalho no exemplo. A linha de cabeçalho Host: www.someschool.edu especifica o host
no qual o objeto reside. Você pode pensar que esta linha de cabeçalho é desnecessária, pois
já existe uma conexão TCP estabelecida com o host. Mas, como veremos na Seção 2.2.5, as informações
fornecido pela linha de cabeçalho do host é exigido pelos caches de proxy da Web. Incluindo a Conexão:
feche a linha de cabeçalho, o navegador está dizendo ao servidor que não quer se preocupar com persistente
conexões; ele quer que o servidor feche a conexão após enviar o objeto solicitado. O usuário
agent: a linha de cabeçalho especifica o agente do usuário, ou seja, o tipo de navegador que está fazendo a solicitação ao
servidor. Aqui, o agente do usuário é o Mozilla/5.0, um navegador Firefox. Essa linha de cabeçalho é útil porque o servidor
pode realmente enviar diferentes versões do mesmo objeto para diferentes tipos de agentes de usuário. (Cada um de
as versões são endereçadas pelo mesmo URL.) Finalmente, o cabeçalho Accept-language: indica que o usuário prefere
receber uma versão francesa do objeto, se tal objeto existir no servidor;
caso contrário, o servidor deve enviar sua versão padrão. O cabeçalho Accept-language: é apenas um dos muitos cabeçalhos
de negociação de conteúdo disponíveis em HTTP.
Tendo visto um exemplo, vejamos agora o formato geral de uma mensagem de solicitação, conforme mostrado em
Figura 2.8. Vemos que o formato geral segue de perto nosso exemplo anterior. Você deve ter notado,
no entanto, que após as linhas de cabeçalho (e o retorno de carro adicional e alimentação de linha) existe uma “entidade
corpo." O corpo da entidade está vazio com o método GET , mas é usado com o método POST . Um HTTP
cliente geralmente usa o método POST quando o usuário preenche um formulário, por exemplo, quando um usuário fornece
palavras de pesquisa para um mecanismo de pesquisa. Com uma mensagem POST , o usuário ainda está solicitando uma página da
Web do servidor, mas o conteúdo específico da página da Web
Figura 2.8 Formato geral de uma mensagem de solicitação HTTP
dependem do que o usuário digitou nos campos do formulário. Se o valor do campo do método for POST , o corpo da , então o
entidade contém o que o usuário inseriu nos campos do formulário.
Seríamos negligentes se não mencionássemos que uma solicitação gerada com um formulário não usa necessariamente
o método POST . Em vez disso, os formulários HTML geralmente usam o método GET e incluem os dados inseridos (em
os campos do formulário) no URL solicitado. Por exemplo, se um formulário usa o método GET , possui dois campos e
as entradas para os dois campos são macacos e bananas , então a URL terá a estrutura
www.somesite.com/ animalsearch?monkeys&bananas . Em sua navegação diária na Web, você provavelmente notou URLs
estendidos desse tipo.
O método HEAD é semelhante ao método GET . Quando um servidor recebe uma solicitação com o método HEAD , ele responde
com uma mensagem HTTP, mas deixa de fora o objeto solicitado. Aplicativo
os desenvolvedores costumam usar o método HEAD para depuração. O método PUT é frequentemente usado em conjunto com
ferramentas de publicação na Web. Ele permite que um usuário carregue um objeto para um caminho específico (diretório) em um determinado
Servidor web. O método PUT também é usado por aplicativos que precisam fazer upload de objetos para servidores Web.
O método DELETE permite que um usuário ou um aplicativo exclua um objeto em um servidor Web.
Mensagem de resposta HTTP

Abaixo, fornecemos uma mensagem de resposta HTTP típica. Esta mensagem de resposta pode ser a resposta a
a mensagem de solicitação de exemplo que acabamos de discutir.
HTTP/ 1.1 200 OK
Conexão: fechar
Data: Terça, 18 de agosto de 2015 15:44:04 GMT
Servidor: Apache/ 2.2.3 (CentOS)
Última modificação: terça-feira, 18 de agosto de 2015 15:11:03 GMT
Comprimento do conteúdo: 6821
Tipo de conteúdo: texto/ html
(dados dados dados dados dados...)
Vamos dar uma olhada cuidadosa nesta mensagem de resposta. Ele tem três seções: uma linha de status inicial, seis
linhas de cabeçalho e, em seguida, o corpo da entidade. O corpo da entidade é a essência da mensagem - ele contém o
próprio objeto solicitado (representado por dados dados dados dados dados ... ). A linha de status tem três campos: o campo
da versão do protocolo, um código de status e uma mensagem de status correspondente. Neste exemplo, a linha de status
indica que o servidor está usando HTTP/1.1 e que está tudo OK (ou seja, o servidor encontrou e está enviando o objeto solicitado).
Agora vamos olhar para as linhas de cabeçalho. O servidor usa a linha de cabeçalho Connection: close para informar ao
cliente que vai fechar a conexão TCP após o envio da mensagem. A linha de cabeçalho Date: indica a hora e a data em que a
resposta HTTP foi criada e enviada pelo servidor. Observe que esta não é a hora em que o objeto foi criado ou modificado pela última
vez; é o momento em que o servidor recupera o objeto de seu sistema de arquivos, insere o objeto na mensagem de resposta e
envia a resposta
mensagem. A linha de cabeçalho Server: indica que a mensagem foi gerada por um Apache Web
servidor; é análogo ao User-agent: linha de cabeçalho na mensagem de solicitação HTTP. o último
Modificado: a linha do cabeçalho indica a hora e a data em que o objeto foi criado ou modificado pela última vez. O
Última modificação: o cabeçalho, que abordaremos em breve com mais detalhes, é crítico para o cache de objetos, tanto no cliente
local quanto em servidores de cache de rede (também conhecidos como servidores proxy). O comprimento do conteúdo:
linha de cabeçalho indica o número de bytes no objeto que está sendo enviado. A linha de cabeçalho Content-Type: indica que o
objeto no corpo da entidade é um texto HTML. (O tipo de objeto é oficialmente indicado pelo
Content-Type: cabeçalho e não pela extensão do arquivo.)
Tendo visto um exemplo, vamos agora examinar o formato geral de uma mensagem de resposta, que é
mostrado na Figura 2.9. Este formato geral da mensagem de resposta corresponde ao exemplo anterior de uma mensagem de
resposta. Digamos algumas palavras adicionais sobre códigos de status e suas frases. O Estado
o código e a frase associada indicam o resultado da solicitação. Alguns códigos de status comuns e frases associadas
incluem:
200 OK: Solicitação bem-sucedida e as informações são retornadas na resposta.
301 Moved Permanently: O objeto solicitado foi permanentemente movido; a nova URL é
especificado em Location : cabeçalho da mensagem de resposta. O software cliente será automaticamente

recuperar o novo URL.
400 Bad Request: Este é um código de erro genérico que indica que a solicitação não pôde ser compreendida
pelo servidor.
Figura 2.9 Formato geral de uma mensagem de resposta HTTP
404 Not Found: O documento solicitado não existe neste servidor.
505 Versão HTTP não suportada: a versão do protocolo HTTP solicitada não é suportada pelo servidor.
Como você gostaria de ver uma mensagem de resposta HTTP real? Isso é altamente recomendado e muito fácil
pendência! Primeiro Telnet em seu servidor Web favorito. Em seguida, digite uma mensagem de solicitação de uma linha
para algum objeto que está hospedado no servidor. Por exemplo, se você tiver acesso a um prompt de comando, digite:
Usando o Wireshark para investigar o protocolo HTTP

telnet gaia.cs.umass.edu 80
GET / kurose_ross/ interactive/ index.php HTTP/ 1.1
Host: gaia.cs.umass.edu
(Pressione o retorno de carro duas vezes depois de digitar a última linha.) Isso abre uma conexão TCP para a porta 80 do
host gaia.cs.umass.edu e, em seguida, envia a mensagem de solicitação HTTP. Você deve ver uma mensagem de resposta que
inclui o arquivo HTML básico para os problemas de lição de casa interativos deste livro. Se
você preferir apenas ver as linhas de mensagem HTTP e não receber o objeto em si, substitua GET por HEAD .
Nesta seção, discutimos várias linhas de cabeçalho que podem ser usadas em mensagens de solicitação e resposta HTTP.
A especificação HTTP define muito mais linhas de cabeçalho que podem ser inseridas por navegadores, servidores Web e
servidores de cache de rede. Cobrimos apenas um pequeno número da totalidade das linhas de cabeçalho. Abordaremos mais alguns
abaixo e outro pequeno número quando discutirmos
cache da Web de rede na Seção 2.2.5. Uma discussão altamente legível e abrangente do protocolo HTTP, incluindo seus cabeçalhos
e códigos de status, é fornecida em [Krishnamurthy 2001].
Como um navegador decide quais linhas de cabeçalho incluir em uma mensagem de solicitação? Como uma Web
servidor decide quais linhas de cabeçalho incluir em uma mensagem de resposta? Um navegador irá gerar cabeçalho
linhas como uma função do tipo e versão do navegador (por exemplo, um navegador HTTP/1.0 não gerará nenhuma linha de cabeçalho
1.1), a configuração do usuário do navegador (por exemplo, idioma preferencial) e se o navegador possui atualmente um cache ,
mas possivelmente desatualizada, versão do objeto. Os servidores da Web se comportam de maneira semelhante: existem diferentes
produtos, versões e configurações, todos influenciando quais linhas de cabeçalho são incluídas nas mensagens de resposta.
2.2.4 Interação Usuário-Servidor: Cookies
Mencionamos acima que um servidor HTTP não tem estado. Isso simplifica o projeto do servidor e permite que os engenheiros
desenvolvam servidores Web de alto desempenho que podem lidar com milhares de conexões TCP simultâneas. No entanto, muitas
vezes é desejável que um site da Web identifique os usuários, seja porque o servidor deseja restringir o acesso do usuário ou
porque deseja servir conteúdo em função da identidade do usuário. Para
Para esses propósitos, o HTTP usa cookies. Os cookies, definidos em [RFC 6265], permitem que os sites rastreiem os usuários.
A maioria dos principais sites comerciais da Web usa cookies atualmente.
Conforme mostrado na Figura 2.10, a tecnologia de cookies tem quatro componentes: (1) uma linha de cabeçalho de cookie na
mensagem de resposta HTTP; (2) uma linha de cabeçalho de cookie na mensagem de solicitação HTTP; (3) um arquivo de cookie mantido no
sistema final do usuário e gerenciado pelo navegador do usuário; e (4) um banco de dados back-end no site.
Usando a Figura 2.10, vamos ver um exemplo de como os cookies funcionam. Suponha que Susan, que sempre
acessa a Web usando o Internet Explorer de seu PC doméstico, entra em contato com a Amazon.com pela primeira vez.
Suponhamos que no passado ela já tenha visitado o site eBay. Quando a solicitação chega ao servidor da Web da Amazon, o
servidor cria um número de identificação exclusivo e uma entrada em seu banco de dados de back-end que é indexado pelo número
de identificação. O servidor da Web da Amazon responde a
O navegador de Susan, incluindo na resposta HTTP um cabeçalho Set-cookie:, que contém o número de identificação.
Por exemplo, a linha de cabeçalho pode ser:
Definir-cookie: 1678
Quando o navegador de Susan recebe a mensagem de resposta HTTP, ele vê o cabeçalho Set-cookie:. O navegador anexa uma
linha ao arquivo de cookie especial que ele gerencia. Esta linha inclui o nome do host
do servidor e o número de identificação no cabeçalho Set-cookie:. Observe que o arquivo de cookie
já tem uma entrada para o eBay, já que Susan visitou esse site no passado. Como Susan continua a
navegar no site da Amazon, cada vez que ela solicita uma página da Web, seu navegador consulta seu arquivo de cookie,
extrai seu número de identificação para este site e coloca uma linha de cabeçalho de cookie que
Figura 2.10 Mantendo o estado do usuário com cookies
inclui o número de identificação na solicitação HTTP. Especificamente, cada uma de suas solicitações HTTP para o
O servidor Amazon inclui a linha de cabeçalho:
Biscoito: 1678
Dessa forma, o servidor da Amazon pode rastrear a atividade de Susan no site da Amazon. Apesar de
O site da Amazon não necessariamente conhece o nome de Susan, ele sabe exatamente quais páginas o usuário 1678 visitou, em
que ordem e em que horários! A Amazon usa cookies para fornecer seu serviço de carrinho de compras - a Amazon pode manter
uma lista de todas as compras pretendidas por Susan, para que ela possa pagar por elas
coletivamente no final da sessão.
Se Susan retornar ao site da Amazon, digamos, uma semana depois, seu navegador continuará a colocar a linha de cabeçalho
Cookie: 1678 nas mensagens de solicitação. A Amazon também recomenda produtos para Susan com base em páginas da Web
que ela visitou na Amazon no passado. Se Susan também se registrar na Amazon—
fornecendo nome completo, endereço de e-mail, endereço postal e informações de cartão de crédito - a Amazon pode então incluir
essas informações em seu banco de dados, associando assim o nome de Susan com seu número de identificação (e todas as páginas
que ela visitou no site no passado !). É assim que a Amazon e outros sites de comércio eletrônico fornecem “compras com um clique” —
quando Susan opta por comprar um item durante uma visita subsequente,
ela não precisa digitar novamente seu nome, número de cartão de crédito ou endereço.
A partir desta discussão, vemos que os cookies podem ser usados para identificar um usuário. Na primeira vez que um usuário visita
um site, ele pode fornecer uma identificação de usuário (possivelmente seu nome). Durante as sessões subsequentes, o
navegador passa um cabeçalho de cookie para o servidor, identificando assim o usuário para o servidor.
Os cookies podem, portanto, ser usados para criar uma camada de sessão do usuário em cima do HTTP sem estado. Por exemplo,
quando um usuário efetua login em um aplicativo de e-mail baseado na Web (como o Hotmail), o navegador envia informações de
cookies ao servidor, permitindo que o servidor identifique o usuário durante toda a sessão do usuário com o aplicativo.
Embora os cookies muitas vezes simplifiquem a experiência de compras na Internet para o usuário, eles são controversos
porque também podem ser considerados como uma invasão de privacidade. Como acabamos de ver, usando uma combinação de
cookies e informações de conta fornecidas pelo usuário, um site da Web pode aprender muito sobre um usuário e potencialmente
vender essas informações a terceiros. Cookie Central [Cookie Central 2016] inclui informações extensas sobre a
controvérsia do cookie.
2.2.5 Cache da Web
Um cache da Web - também chamado de servidor proxy - é uma entidade de rede que atende a solicitações HTTP no
nome de um servidor Web de origem. O cache da Web possui seu próprio armazenamento em disco e mantém cópias de
objetos solicitados neste armazenamento. Conforme mostrado na Figura 2.11, o navegador de um usuário pode ser configurado para
que todas as solicitações HTTP do usuário sejam primeiro direcionadas ao cache da Web. Depois que um navegador é configurado,
cada solicitação do navegador para um objeto é primeiro direcionada para o cache da Web. Por exemplo, suponha que um navegador esteja
solicitando o objeto http:// www.someschool.edu/ campus.gif . Aqui está o que acontece:
1. O navegador estabelece uma conexão TCP com o cache da Web e envia uma solicitação HTTP para o objeto ao cache da
Web.
2. O cache da Web verifica se há uma cópia do objeto armazenada localmente. Em caso afirmativo, o cache da Web retorna
o objeto em uma mensagem de resposta HTTP para o navegador do cliente.
Figura 2.11 Clientes solicitando objetos por meio de um cache da Web
3. Se o cache da Web não tiver o objeto, o cache da Web abre uma conexão TCP com a origem
servidor, ou seja, para www.someschool.edu . O cache da Web então envia uma solicitação HTTP para o objeto na conexão
TCP do cache para o servidor. Depois de receber esta solicitação, o servidor de origem
envia o objeto dentro de uma resposta HTTP para o cache da Web.
4. Quando o cache da Web recebe o objeto, ele armazena uma cópia em seu armazenamento local e envia uma cópia, dentro
de uma mensagem de resposta HTTP, para o navegador do cliente (através da conexão TCP existente
entre o navegador do cliente e o cache da Web).
Observe que um cache é um servidor e um cliente ao mesmo tempo. Quando recebe pedidos de e
envia respostas para um navegador, é um servidor. Quando envia solicitações e recebe respostas de um servidor de origem, é um
cliente.
Normalmente, um cache da Web é adquirido e instalado por um ISP. Por exemplo, uma universidade pode instalar um cache na
rede do campus e configurar todos os navegadores do campus para apontar para o cache. Ou um major
ISP residencial (como Comcast) pode instalar um ou mais caches em sua rede e pré-configurar seu
navegadores enviados para apontar para os caches instalados.
O cache da Web foi implantado na Internet por dois motivos. Primeiro, um cache da Web pode reduzir substancialmente o tempo de
resposta para uma solicitação do cliente, principalmente se a largura de banda do gargalo entre o cliente
e o servidor de origem é muito menor que a largura de banda do gargalo entre o cliente e o cache. Se houver uma conexão de
alta velocidade entre o cliente e o cache, como geralmente ocorre, e se o cache tiver o objeto solicitado, o cache poderá entregar
o objeto rapidamente ao cliente. Em segundo lugar, como ilustraremos em breve com um exemplo, os caches da Web podem
reduzir substancialmente o tráfego no link de acesso de uma instituição à Internet. Ao reduzir o tráfego, a instituição (por exemplo,
uma empresa ou uma universidade) não precisa atualizar a largura de banda com tanta rapidez, reduzindo custos. Além disso,
os caches da Web podem

reduzir substancialmente o tráfego da Web na Internet como um todo, melhorando assim o desempenho de todos
os aplicativos.
Para obter uma compreensão mais profunda dos benefícios dos caches, vamos considerar um exemplo no contexto de
Figura 2.12. Esta figura mostra duas redes – a rede institucional e o restante da Internet pública. A rede
institucional é uma LAN de alta velocidade. Um roteador na rede institucional e um roteador na Internet são conectados
por um link de 15 Mbps. Os servidores de origem estão conectados à Internet, mas estão localizados em todo o mundo.
Suponha que o tamanho médio do objeto seja de 1 Mbits e que a taxa média de requisição dos navegadores da instituição
aos servidores de origem seja de 15 requisições por segundo. Suponha que as mensagens de solicitação HTTP
sejam desprezíveis e, portanto, não gerem tráfego nas redes ou no link de acesso (do roteador institucional para o
roteador da Internet). Suponha também que a quantidade de tempo que leva desde quando
o roteador no lado da Internet do link de acesso na Figura 2.12 encaminha uma solicitação HTTP (dentro de um
datagrama IP) até receber a resposta (normalmente dentro de muitos datagramas IP) em dois segundos em
média. Informalmente, nos referimos a este último atraso como o “atraso da Internet”.
Figura 2.12 Gargalo entre uma rede institucional e a Internet
O tempo de resposta total - ou seja, o tempo desde a solicitação de um objeto pelo navegador até o recebimento do
objeto - é a soma do atraso da LAN, o atraso de acesso (ou seja, o atraso entre os dois roteadores) e
a demora da internet. Vamos agora fazer um cálculo bem grosseiro para estimar esse atraso. A intensidade do tráfego em
a LAN (consulte a Seção 1.4.2) é
(15 solicitações/s)ÿ(1 Mbits/solicitação)/(100 Mbps)=0,15
Considerando que a intensidade do tráfego no link de acesso (do roteador da Internet para o roteador da instituição) é
(15 solicitações/seg)ÿ(1 Mbits/solicitação)/(15 Mbps)=1
Uma intensidade de tráfego de 0,15 em uma LAN geralmente resulta em, no máximo, dezenas de milissegundos de atraso; portanto, nós
pode negligenciar o atraso da LAN. No entanto, conforme discutido na Seção 1.4.2, à medida que a intensidade do tráfego se aproxima
1 (como é o caso do link de acesso na Figura 2.12), o atraso em um link torna-se muito grande e cresce sem limites. Assim, o tempo
médio de resposta para atender às requisições será da ordem de
minutos, se não mais, o que é inaceitável para os usuários da instituição. Claramente algo deve ser feito.
Uma solução possível é aumentar a taxa de acesso de 15 Mbps para, digamos, 100 Mbps. Isso reduzirá a intensidade do tráfego no link
de acesso para 0,15, o que se traduz em atrasos insignificantes entre os dois roteadores.
Nesse caso, o tempo total de resposta será de aproximadamente dois segundos, ou seja, o atraso da Internet. Mas isso
solução também significa que a instituição deve atualizar seu link de acesso de 15 Mbps para 100 Mbps, um custo
proposição.
Agora considere a solução alternativa de não atualizar o link de acesso, mas sim instalar um cache da Web
na rede institucional. Esta solução é ilustrada na Figura 2.13. As taxas de acesso — a fração de solicitações atendidas por um cache —
geralmente variam de 0,2 a 0,7 na prática. Para fins ilustrativos, vamos supor que a cache forneça uma taxa de acerto de 0,4 para esta
instituição. Como os clientes e o cache estão conectados à mesma LAN de alta velocidade, 40% das solicitações serão atendidas quase
imediatamente, digamos, em 10 milissegundos, pelo cache. No entanto, os 60% restantes das solicitações ainda precisam ser
atendidos pelos servidores de origem. Mas com apenas 60% dos objetos solicitados passando pelo link de acesso, a intensidade do
tráfego no link de acesso é reduzida de 1,0 para 0,6.
Normalmente, uma intensidade de tráfego inferior a 0,8 corresponde a um pequeno atraso, digamos, dezenas de milissegundos, em um intervalo de 15
ligação Mbps. Esse atraso é insignificante em comparação com o atraso de dois segundos da Internet. Dado estes
considerações, o atraso médio, portanto, é
0,4ÿ(0,01 segundos)+0,6ÿ(2,01 segundos)
que é apenas um pouco maior que 1,2 segundos. Assim, esta segunda solução fornece um custo ainda menor
tempo de resposta que a primeira solução, e não exige que a instituição

Figura 2.13 Adicionando um cache à rede institucional
para atualizar seu link para a Internet. A instituição, é claro, precisa adquirir e instalar um cache da Web. Mas esse custo é baixo
– muitos caches usam software de domínio público executado em PCs baratos.
Por meio do uso de redes de distribuição de conteúdo (CDNs), os caches da Web desempenham cada vez mais um papel
papel importante na Internet. Uma empresa de CDN instala muitos caches distribuídos geograficamente
através da Internet, localizando assim grande parte do tráfego. Existem CDNs compartilhados (como Akamai e Limelight) e CDNs
dedicados (como Google e Netflix). Discutiremos CDNs com mais detalhes
na Seção 2.6.
O GET condicional
Embora o armazenamento em cache possa reduzir os tempos de resposta percebidos pelo usuário, ele introduz um novo problema
— a cópia de um objeto que reside no cache pode estar obsoleta. Em outras palavras, o objeto alojado no servidor Web pode ter
sido modificado desde que a cópia foi armazenada em cache no cliente. Felizmente, o HTTP tem um mecanismo que
permite que um cache verifique se seus objetos estão atualizados. Esse mecanismo é chamado de GET condicional.
Uma mensagem de solicitação HTTP é chamada de mensagem GET condicional se (1) a mensagem de solicitação usa o
GET e (2) a mensagem de solicitação inclui uma linha de cabeçalho If-Modified-Since:.
Para ilustrar como o GET condicional opera, vamos ver um exemplo. Primeiro, em nome de um
navegador solicitante, um cache proxy envia uma mensagem de solicitação para um servidor Web:
GET / fruta/ kiwi.gif HTTP/ 1.1
Host: www.exotiquecuisine.com
Em segundo lugar, o servidor Web envia uma mensagem de resposta com o objeto solicitado para o cache:
HTTP/ 1.1 200 OK
Data: sábado, 3 de outubro de 2015 15:39:29
Servidor: Apache/ 1.3.0 (Unix)
Última modificação: quarta-feira, 9 de setembro de 2015 09:23:24
Tipo de conteúdo: imagem/ gif
(dados dados dados dados dados...)
O cache encaminha o objeto para o navegador solicitante, mas também armazena o objeto localmente. É importante ressaltar
que o cache também armazena a data da última modificação junto com o objeto. Terceiro, uma semana depois, outra
o navegador solicita o mesmo objeto por meio do cache e o objeto ainda está no cache. Como esse objeto pode ter sido
modificado no servidor Web na última semana, o cache executa uma verificação atualizada emitindo um GET condicional.
Especificamente, o cache envia:
GET / fruta/ kiwi.gif HTTP/ 1.1
Host: www.exotiquecuisine.com
Se modificado desde: quarta-feira, 9 de setembro de 2015 09:23:24
Observe que o valor da linha de cabeçalho If-modified-since: é exatamente igual ao valor do
Last-Modified: linha de cabeçalho que foi enviada pelo servidor há uma semana. Este GET condicional está dizendo ao
servidor para enviar o objeto somente se o objeto tiver sido modificado desde a data especificada.
Suponha que o objeto não tenha sido modificado desde 9 de setembro de 2015 09:23:24. Então, quarto, o servidor Web envia
uma mensagem de resposta para o cache:

HTTP/ 1.1 304 não modificado

Data: sábado, 10 de outubro de 2015 15:39:29
Servidor: Apache/ 1.3.0 (Unix)
(corpo de entidade vazio)
Vemos que em resposta ao GET condicional, o servidor Web ainda envia uma mensagem de resposta, mas não
inclui o objeto solicitado na mensagem de resposta. Incluir o objeto solicitado apenas desperdiçaria largura de
banda e aumentaria o tempo de resposta percebido pelo usuário, especialmente se o objeto for grande. Observação
que esta última mensagem de resposta tem 304 Not Modified na linha de status, que informa ao cache que ele pode
prosseguir e encaminhar sua cópia em cache (do cache do proxy) do objeto para o navegador solicitante.
Isso encerra nossa discussão sobre HTTP, o primeiro protocolo da Internet (um protocolo de camada de aplicativo)
que estudamos em detalhes. Vimos o formato das mensagens HTTP e as ações executadas pelo cliente e servidor
Web conforme essas mensagens são enviadas e recebidas. Também estudamos um pouco da aplicação da Web
infraestrutura, incluindo caches, cookies e bancos de dados de back-end, todos vinculados de alguma forma a
o protocolo HTTP.
2.3 Correio Eletrônico na Internet
O correio eletrônico existe desde o início da Internet. Foi o aplicativo mais popular
quando a Internet estava em sua infância [Segaller 1998], e tornou-se mais elaborada e poderosa ao longo dos anos. Ele continua
sendo um dos aplicativos mais importantes e utilizados da Internet.
Assim como o correio postal comum, o e-mail é um meio de comunicação assíncrono - as pessoas enviam e leem mensagens quando
lhes é conveniente, sem ter que coordenar com os horários de outras pessoas. Ao contrário do correio postal, o correio eletrônico é
rápido, fácil de distribuir e barato. O e-mail moderno tem muitos recursos poderosos, incluindo mensagens com anexos, hiperlinks,
texto formatado em HTML e
fotos incorporadas.
Nesta seção, examinamos os protocolos da camada de aplicação que estão no centro do e-mail da Internet. Mas antes de
entrarmos em uma discussão aprofundada desses protocolos, vamos dar uma olhada em alto nível no sistema de correio da Internet
e seus principais componentes.
A Figura 2.14 apresenta uma visão de alto nível do sistema de correio da Internet. Vemos neste diagrama que ele tem três
componentes principais: agentes de usuário, servidores de correio e o SMTP (Simple Mail Transfer Protocol).
Agora descrevemos cada um desses componentes no contexto de um remetente, Alice, enviando uma mensagem de e-
mail para um destinatário, Bob. Os agentes do usuário permitem que os usuários leiam, respondam, encaminhem, salvem e
escrevam mensagens. Microsoft Outlook e Apple Mail são exemplos de agentes de usuário para e-mail. quando Alice é
terminar de redigir sua mensagem, seu agente de usuário envia a mensagem para seu servidor de correio, onde o
a mensagem é colocada na fila de mensagens de saída do servidor de correio. Quando Bob deseja ler uma mensagem, seu agente
de usuário recupera a mensagem de sua caixa de correio em seu servidor de correio.
Os servidores de e-mail formam o núcleo da infraestrutura de e-mail. Cada destinatário, como Bob, tem uma caixa de correio
localizada em um dos servidores de correio. A caixa de correio de Bob gerencia e

Figura 2.14 Uma visão de alto nível do sistema de e-mail da Internet
mantém as mensagens que lhe foram enviadas. Uma mensagem típica começa sua jornada no agente do usuário do remetente, viaja para o
servidor de correio do remetente e viaja para o servidor de correio do destinatário, onde é
depositado na caixa de correio do destinatário. Quando Bob deseja acessar as mensagens em sua caixa de correio, o servidor de correio que
contém sua caixa de correio autentica Bob (com nomes de usuário e senhas). servidor de correio de Alice
também deve lidar com falhas no servidor de correio de Bob. Se o servidor de Alice não puder entregar correspondência ao servidor de Bob,
O servidor de Alice mantém a mensagem em uma fila de mensagens e tenta transferi-la posteriormente.
As novas tentativas geralmente são feitas a cada 30 minutos ou mais; se não houver sucesso após vários dias, o servidor remove a mensagem
e notifica o remetente (Alice) com uma mensagem de e-mail.
O SMTP é o principal protocolo da camada de aplicação para o correio eletrônico da Internet. Ele usa o serviço confiável de transferência
de dados do TCP para transferir mensagens do servidor de correio do remetente para o servidor de correio do destinatário. Assim como a
maioria dos protocolos da camada de aplicativos, o SMTP tem dois lados: um lado do cliente, que é executado no servidor de correio do remetente,
e um lado do servidor, que é executado no servidor de correio do destinatário. Os lados cliente e servidor do SMTP são executados em todos os
servidores de correio. Quando um servidor de correio envia correio para outros servidores de correio, ele age como
um cliente SMTP. Quando um servidor de correio recebe correio de outros servidores de correio, ele age como um servidor SMTP.
2.3.1 SMTP
O SMTP, definido no RFC 5321, está no centro do correio eletrônico da Internet. Conforme mencionado acima, o SMTP
transfere mensagens dos servidores de correio dos remetentes para os servidores de correio dos destinatários. O SMTP é muito mais
antigo que o HTTP. (O SMTP RFC original data de 1982, e o SMTP já existia muito antes disso.) Embora
O SMTP tem inúmeras qualidades maravilhosas, como evidenciado por sua onipresença na Internet; no entanto, é uma tecnologia
herdada que possui certas características arcaicas. Por exemplo, restringe o corpo (não
apenas os cabeçalhos) de todas as mensagens de correio para ASCII simples de 7 bits. Essa restrição fazia sentido no início dos
anos 80, quando a capacidade de transmissão era escassa e ninguém enviava grandes anexos por e-mail ou grandes arquivos
de imagem, áudio ou vídeo. Mas hoje, na era da multimídia, a restrição ASCII de 7 bits é um pouco chata
— requer que os dados multimídia binários sejam codificados em ASCII antes de serem enviados por SMTP; e requer que a
mensagem ASCII correspondente seja decodificada de volta para binário após o transporte SMTP. Lembrar
da Seção 2.2 que o HTTP não exige que os dados multimídia sejam codificados em ASCII antes da transferência.
Para ilustrar a operação básica do SMTP, vamos percorrer um cenário comum. Suponha que Alice queira enviar a Bob uma
mensagem ASCII simples.
1. Alice invoca seu agente de usuário para e-mail, fornece o endereço de e-mail de Bob (por exemplo,
bob@someschool.edu ), compõe uma mensagem e instrui o agente do usuário a enviar o
mensagem.
2. O agente do usuário de Alice envia a mensagem para seu servidor de correio, onde ela é colocada em uma fila de mensagens.
3. O lado cliente do SMTP, rodando no servidor de correio de Alice, vê a mensagem na fila de mensagens. Ele abre uma
conexão TCP para um servidor SMTP, rodando no servidor de correio de Bob.
4. Depois de algum handshaking SMTP inicial, o cliente SMTP envia a mensagem de Alice para o TCP
conexão.
5. No servidor de correio de Bob, o servidor SMTP recebe a mensagem. servidor de correio de Bob então
coloca a mensagem na caixa de correio de Bob.
6. Bob invoca seu agente de usuário para ler a mensagem conforme sua conveniência.
O cenário é resumido na Figura 2.15.
É importante observar que o SMTP normalmente não usa servidores de correio intermediários para enviar mensagens, mesmo
quando os dois servidores de correio estão localizados em extremos opostos do mundo. Se o servidor de Alice estiver em Hong
O servidor de Kong e Bob está em St. Louis, o TCP

Figura 2.15 Alice envia uma mensagem para Bob
connection é uma conexão direta entre os servidores de Hong Kong e St. Louis. Em particular, se Bob's
servidor de correio está inoperante, a mensagem permanece no servidor de correio de Alice e aguarda uma nova
tentativa - a mensagem não é colocada em algum servidor de correio intermediário.
Vamos agora examinar mais de perto como o SMTP transfere uma mensagem de um servidor de envio de
correio para um servidor de recebimento de correio. Veremos que o protocolo SMTP tem muitas semelhanças com
protocolos usados para interação humana face a face. Primeiro, o cliente SMTP (em execução no host do servidor de
email de envio) faz com que o TCP estabeleça uma conexão com a porta 25 no servidor SMTP (em execução no
host do servidor de email de recebimento). Se o servidor estiver inativo, o cliente tentará novamente mais tarde. Uma
vez que essa conexão é estabelecida, o servidor e o cliente executam algum handshaking na camada de aplicativo -
assim como os humanos geralmente se apresentam antes de transferir informações de um para outro, os clientes e
servidores SMTP se apresentam antes de transferir informações. Durante esta fase de handshaking SMTP, o cliente
SMTP indica o endereço de e-mail do remetente (a pessoa que gerou a mensagem) e o endereço de e-mail do
destinatário. Uma vez que o cliente SMTP e o servidor tenham se apresentado, o cliente envia
a mensagem. O SMTP pode contar com o serviço confiável de transferência de dados do TCP para levar a mensagem
ao servidor sem erros. O cliente então repete esse processo na mesma conexão TCP se tiver outro
mensagens para enviar ao servidor; caso contrário, ele instrui o TCP a fechar a conexão.
Vamos agora dar uma olhada em um exemplo de transcrição de mensagens trocadas entre um cliente SMTP (C)
e um servidor SMTP (S). O hostname do cliente é crepes.fr e o hostname do servidor é hamburger.edu . As linhas de
texto ASCII prefaciadas com C: são exatamente as linhas que o cliente envia para seu
O soquete TCP e as linhas de texto ASCII precedidas de S: são exatamente as linhas que o servidor envia para seu
soquete TCP. A transcrição a seguir começa assim que a conexão TCP é estabelecida.
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Olá crepes.fr, prazer em conhecê-lo
C: CORREIO DE: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Remetente ok
C: RCPT PARA: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Destinatário ok

C: DADOS
S: 354 Digite e-mail, termine com ”.” em uma linha por si só
C: Você gosta de ketchup?
C: Que tal picles?

C: .
S: 250 Mensagem aceita para entrega

C: DESISTIR
S: 221 hamburger.edu fechando conexão
No exemplo acima, o cliente envia uma mensagem (“ Você gosta de ketchup? Que tal picles? ”) do servidor de
correio crepes.fr para o servidor de correio hamburger.edu . Como parte do diálogo,
o cliente emitiu cinco comandos: HELO (uma abreviação de HELLO), MAIL FROM , RCPT PARA , DADOS ,
e DESISTIR . Esses comandos são auto-explicativos. O cliente também envia uma linha composta por um único ponto, que
indica o fim da mensagem ao servidor. (No jargão ASCII, cada mensagem termina com
CRLF.CRLF , onde CR e LF representam retorno de carro e alimentação de linha, respectivamente.) O servidor emite
respostas para cada comando, com cada resposta tendo um código de resposta e alguma explicação (opcional) em inglês.
Mencionamos aqui que o SMTP usa conexões persistentes: Se o servidor de e-mail remetente tiver várias mensagens para
enviar ao mesmo servidor de e-mail receptor, ele poderá enviar todas as mensagens
na mesma conexão TCP. Para cada mensagem, o cliente inicia o processo com um novo MAIL
FROM: crepes.fr , designa o fim da mensagem com um ponto isolado e emite QUIT somente após o envio de todas as
mensagens.
É altamente recomendável que você use o Telnet para realizar um diálogo direto com um servidor SMTP. Pendência
esse assunto
servidor telnetName 25
em que serverName é o nome de um servidor de correio local. Ao fazer isso, você está simplesmente estabelecendo uma conexão
TCP entre seu host local e o servidor de correio. Depois de digitar esta linha, você deve
receba imediatamente a resposta 220 do servidor. Em seguida, emita os comandos SMTP HELO , CORRESPONDÊNCIA
DE , RCPT PARA , DADOS , CRLF.CRLF , e DESISTIR nos momentos apropriados. Também é altamente
recomendado que você faça a Tarefa de Programação 3 no final deste capítulo. Nessa tarefa,
você criará um agente de usuário simples que implementa o lado cliente do SMTP. Isso permitirá que você envie um e-
mensagem de e-mail para um destinatário arbitrário por meio de um servidor de e-mail local.
2.3.2 Comparação com HTTP
Vamos agora comparar brevemente o SMTP com o HTTP. Ambos os protocolos são usados para transferir arquivos de um host para
outro: o HTTP transfere arquivos (também chamados de objetos) de um servidor Web para um cliente Web (normalmente um
navegador); O SMTP transfere arquivos (ou seja, mensagens de e-mail) de um servidor de e-mail para outro servidor de e-mail.
Ao transferir os arquivos, o HTTP e o SMTP persistentes usam conexões persistentes. Assim, os dois protocolos possuem
características comuns. No entanto, existem diferenças importantes. Primeiro, o HTTP é principalmente um protocolo pull - alguém
carrega informações em um servidor da Web e os usuários usam o HTTP para extrair as informações.
informações do servidor conforme sua conveniência. Em particular, a conexão TCP é iniciada pela máquina que deseja receber o
arquivo. Por outro lado, o SMTP é basicamente um protocolo de envio — o servidor de envio de correio envia o arquivo para o
servidor de recebimento de correio. Em particular, a conexão TCP é iniciada pela máquina que deseja enviar o arquivo.
Uma segunda diferença, à qual aludimos anteriormente, é que o SMTP exige que cada mensagem, incluindo o
corpo de cada mensagem, para estar no formato ASCII de 7 bits. Se a mensagem contiver caracteres que não sejam de 7 bits
ASCII (por exemplo, caracteres franceses com acentos) ou contém dados binários (como um arquivo de imagem), então a
mensagem deve ser codificada em ASCII de 7 bits. Os dados HTTP não impõem essa restrição.
Uma terceira diferença importante diz respeito a como um documento que consiste em texto e imagens (junto com possivelmente
outros tipos de mídia) é tratado. Conforme aprendemos na Seção 2.2, o HTTP encapsula cada objeto em sua própria mensagem de
resposta HTTP. O SMTP coloca todos os objetos da mensagem em uma mensagem.
2.3.3 Formatos de mensagens de correio
Quando Alice escreve uma carta comum para Bob, ela pode incluir todos os tipos de cabeçalho periférico.
informações no início da carta, como o endereço de Bob, o endereço do remetente dela e a data.
Da mesma forma, quando uma mensagem de e-mail é enviada de uma pessoa para outra, um cabeçalho contendo periféricos
as informações precedem o corpo da própria mensagem. Essas informações periféricas estão contidas em uma série de linhas de
cabeçalho, definidas na RFC 5322. As linhas de cabeçalho e o corpo da mensagem são
separados por uma linha em branco (ou seja, por CRLF ). A RFC 5322 especifica o formato exato para linhas de cabeçalho de correio,
bem como suas interpretações semânticas. Assim como no HTTP, cada linha de cabeçalho contém texto legível, consistindo
em uma palavra-chave seguida por dois pontos e um valor. Algumas das palavras-chave são obrigatórias e
outros são opcionais. Cada cabeçalho deve ter uma linha de cabeçalho De: e uma linha de cabeçalho Para:; um cabeçalho
pode incluir um assunto: linha de cabeçalho, bem como outras linhas de cabeçalho opcionais. É importante notar que
essas linhas de cabeçalho são diferentes dos comandos SMTP que estudamos na Seção 2.4.1 (mesmo que
eles contêm algumas palavras comuns, como “de” e “para”). Os comandos nessa seção faziam parte do protocolo de handshaking SMTP;
as linhas de cabeçalho examinadas nesta seção fazem parte da mensagem de correio
em si.
Um cabeçalho de mensagem típico se parece com isto:
De: alice@crepes.fr
Para: bob@hamburger.edu
Tema: Em busca do sentido da vida.
Após o cabeçalho da mensagem, segue uma linha em branco; então o corpo da mensagem (em ASCII) segue. Você deve
use o Telnet para enviar uma mensagem para um servidor de correio que contém algumas linhas de cabeçalho, incluindo o
Assunto: linha de cabeçalho. Para fazer isso, emita telnet serverName 25, conforme discutido na Seção 2.4.1.
2.3.4 Protocolos de acesso de correio
Depois que o SMTP entrega a mensagem do servidor de correio de Alice para o servidor de correio de Bob, a mensagem é colocada na
caixa de correio de Bob. Ao longo desta discussão, presumimos tacitamente que Bob lê seu e-mail efetuando login no host do
servidor e, em seguida, executando um leitor de e-mail que é executado nesse host. Até o início dos anos 1990, essa era a maneira
padrão de fazer as coisas. Mas hoje, o acesso ao correio usa um cliente-servidor
arquitetura—o usuário típico lê e-mail com um cliente que executa no sistema final do usuário, por exemplo, em um PC de escritório,
um laptop ou um smartphone. Ao executar um cliente de e-mail em um PC local, os usuários desfrutam de um rico conjunto de
recursos, incluindo a capacidade de visualizar mensagens multimídia e anexos.
Dado que Bob (o destinatário) executa seu agente de usuário em seu PC local, é natural considerar colocar um servidor de correio em seu
PC local também. Com essa abordagem, o servidor de correio de Alice dialogaria diretamente com o PC de Bob. Há um problema com
essa abordagem, no entanto. Lembre-se de que um servidor de correio gerencia

caixas de correio e executa os lados cliente e servidor do SMTP. Se o servidor de correio de Bob residisse em seu local
PC, então o PC de Bob teria que ficar sempre ligado, e conectado à Internet, para receber novas correspondências, que podem chegar
a qualquer momento. Isso é impraticável para muitos usuários da Internet. Em vez disso, um usuário típico executa um agente de
usuário no PC local, mas acessa sua caixa de correio armazenada em um servidor de correio compartilhado sempre ativo. Este
servidor de correio é compartilhado com outros usuários e normalmente é mantido pelo ISP do usuário (por exemplo, universidade
ou empresa).
Agora vamos considerar o caminho que uma mensagem de e-mail percorre quando é enviada de Alice para Bob. Acabamos de aprender
que em algum ponto ao longo do caminho a mensagem de e-mail precisa ser depositada no servidor de correio de Bob. Isso poderia ser
feito simplesmente fazendo com que o agente do usuário de Alice enviasse a mensagem diretamente para o servidor de correio de Bob. E
isso poderia ser feito com o SMTP — na verdade, o SMTP foi projetado para enviar e-mails de um host para outro. No entanto, normalmente
o agente do usuário do remetente não dialoga diretamente com o e-mail do destinatário.
servidor. Em vez disso, conforme mostrado na Figura 2.16, o agente de usuário de Alice usa SMTP para enviar a mensagem de e-mail
para seu servidor de e-mail, então o servidor de e-mail de Alice usa SMTP (como um cliente SMTP) para retransmitir a mensagem
de e-mail para o servidor de e-mail de Bob. Por que o procedimento em duas etapas? Principalmente porque sem retransmitir através
Servidor de correio de Alice, o agente do usuário de Alice não tem nenhum recurso para um destino inacessível
Figura 2.16 Protocolos de e-mail e suas entidades de comunicação
servidor de e-mail. Tendo Alice primeiro depositando o e-mail em seu próprio servidor de correio, o servidor de correio de Alice pode
tentar repetidamente enviar a mensagem para o servidor de correio de Bob, digamos a cada 30 minutos, até que o servidor de correio de
Bob se torne operacional. (E se o servidor de correio de Alice estiver inoperante, ela poderá reclamar com o administrador do sistema!) O
SMTP RFC define como os comandos SMTP podem ser usados para retransmitir uma mensagem entre vários servidores SMTP.
Mas ainda falta uma peça no quebra-cabeça! Como um destinatário como Bob, executando um agente de usuário em seu PC local, obtém
suas mensagens, que estão armazenadas em um servidor de correio dentro do ISP de Bob? Observe que o agente do usuário de Bob não
pode usar o SMTP para obter as mensagens porque a obtenção das mensagens é uma operação pull,
Considerando que o SMTP é um protocolo push. O quebra-cabeça é completado com a introdução de um acesso especial ao correio
protocolo que transfere mensagens do servidor de correio de Bob para seu PC local. Atualmente, existem vários protocolos populares de acesso
a correio, incluindo Post Office Protocol—Versão 3 (POP3), Internet Mail Access Protocol (IMAP) e HTTP.
A Figura 2.16 fornece um resumo dos protocolos usados para correio da Internet: SMTP é usado para transferir correio do servidor
de correio do remetente para o servidor de correio do destinatário; O SMTP também é usado para transferir correio do agente do usuário do
remetente para o servidor de correio do remetente. Um protocolo de acesso a correio, como POP3, é usado para transferir correio do servidor
de correio do destinatário para o agente do usuário do destinatário.
POP3
POP3 é um protocolo de acesso a correio extremamente simples. É definido em [RFC 1939], que é curto e bastante legível. Como o protocolo
é tão simples, sua funcionalidade é bastante limitada. O POP3 começa quando o agente do usuário (o cliente) abre uma conexão TCP
com o servidor de correio (o servidor) na porta 110. Com o TCP

conexão estabelecida, o POP3 passa por três fases: autorização, transação e atualização.
Durante a primeira fase, autorização, o user agent envia um nome de usuário e uma senha (em branco) para autenticar o usuário.
Durante a segunda fase, transação, o agente do usuário recupera as mensagens; também durante esta fase, o agente do
usuário pode marcar mensagens para exclusão, remover marcas de exclusão e obter
estatísticas de correio. A terceira fase, atualização, ocorre após o cliente emitir o comando quit , encerrando a sessão POP3;
neste momento, o servidor de correio exclui as mensagens que foram marcadas para exclusão.
Em uma transação POP3, o agente do usuário emite comandos e o servidor responde a cada comando
com uma resposta. Existem duas respostas possíveis: +OK (às vezes seguido de dados do servidor para o cliente),
usado pelo servidor para indicar que o comando anterior estava correto; e -ERR indicam que algo , usado pelo servidor para
estava errado com o comando anterior.
A fase de autorização possui dois comandos principais: user <username> e pass <password> .
Para ilustrar esses dois comandos, sugerimos que você Telnet diretamente em um servidor POP3, usando a porta
110 e emita esses comandos. Suponha que mailServer seja o nome do seu servidor de correio. Você verá algo como:
telnet mailServer 110
+OK servidor POP3 pronto

usuário bob
+OK
passar fome
+OK usuário logado com sucesso
Se você digitar um comando errado, o servidor POP3 responderá com uma mensagem -ERR .
Agora vamos dar uma olhada na fase de transação. Um agente de usuário usando POP3 geralmente pode ser configurado (pelo
usuário) para “baixar e excluir” ou “baixar e manter”. A seqüência de comandos emitidos por um agente do usuário POP3
depende de qual desses dois modos o agente do usuário está operando.
modo e-excluir, o agente do usuário emitirá a lista , retr , e excluir comandos. Como um exemplo,
suponha que o usuário tenha duas mensagens em sua caixa de correio. No diálogo abaixo, C: (representando
cliente) é o agente do usuário e S: (que significa servidor) é o servidor de correio. A transação será algo como:
C: lista
S: 1 498
S: 2 912
S: .
C: retr 1
S: (blá blá...
S: ..............
S: .......... blá)
S: .
C: deletar 1
C: retr 2
S: (blá blá...
S: ..............
S: .......... blá)
S: .
C: Dele 2
C: sair
S: +OK servidor POP3 encerrando
O agente do usuário primeiro pede ao servidor de correio para listar o tamanho de cada uma das mensagens
armazenadas. O agente do usuário recupera e exclui cada mensagem do servidor. Observe que após a fase de autorização, o
agente de usuário empregou apenas quatro comandos: list , retr , deletar , e desista . A sintaxe para estes
está definido no RFC 1939. Após o processamento do comando quit , o servidor POP3 entra na fase de
atualização e remove as mensagens 1 e 2 da caixa de correio.
Um problema com esse modo de download e exclusão é que o destinatário, Bob, pode ser nômade e pode
querer acessar suas mensagens de correio de várias máquinas, por exemplo, seu PC do escritório, seu PC
doméstico e seu computador portátil. O modo de download e exclusão particiona as mensagens de correio de
Bob nessas três máquinas; em particular, se Bob primeiro ler uma mensagem em seu PC do escritório, ele
não poderá reler a mensagem de seu portátil em casa mais tarde à noite. No modo download-and-keep,
o agente do usuário deixa as mensagens no servidor de correio depois de baixá-las. Nesse caso, Bob pode reler
mensagens de diferentes máquinas; ele pode acessar uma mensagem do trabalho e acessá-la novamente mais tarde no
semana de casa.
Durante uma sessão POP3 entre um agente de usuário e o servidor de correio, o servidor POP3 mantém alguns
informações de estado; em particular, ele rastreia quais mensagens do usuário foram marcadas como excluídas.
No entanto, o servidor POP3 não carrega informações de estado nas sessões POP3. Essa falta de
informações de estado nas sessões simplifica muito a implementação de um servidor POP3.
IMAP
Com acesso POP3, uma vez que Bob tenha baixado suas mensagens para a máquina local, ele pode criar
pastas e mova as mensagens baixadas para as pastas. Bob pode excluir mensagens, mover mensagens entre pastas e
pesquisar mensagens (pelo nome do remetente ou assunto). Mas esse paradigma - ou seja, pastas e mensagens na máquina
local - representa um problema para o usuário nômade, que prefere manter uma hierarquia de pastas em um servidor remoto que
pode ser acessado de qualquer computador. Isso não é possível com POP3—o protocolo POP3 não fornece nenhum meio para
um usuário criar
pastas e atribuir mensagens a pastas.
Para resolver este e outros problemas, foi inventado o protocolo IMAP, definido em [RFC 3501] . Como o POP3, o IMAP é um
protocolo de acesso ao correio. Ele tem muito mais recursos do que o POP3, mas também é significativamente mais
complexo. (E, portanto, as implementações do lado do cliente e do servidor são significativamente mais complexas.)
Um servidor IMAP associará cada mensagem a uma pasta; quando uma mensagem chega pela primeira vez ao servidor, ela é
associada à pasta INBOX do destinatário. O destinatário pode mover a mensagem para uma nova pasta criada pelo usuário, ler
a mensagem, excluí-la e assim por diante. O protocolo IMAP fornece
comandos para permitir que os usuários criem pastas e movam mensagens de uma pasta para outra. O IMAP também fornece
comandos que permitem aos usuários pesquisar pastas remotas em busca de mensagens que correspondam a critérios específicos.
Observe que, ao contrário do POP3, um servidor IMAP mantém as informações de estado do usuário nas sessões IMAP - por
por exemplo, os nomes das pastas e quais mensagens estão associadas a quais pastas.
Outra característica importante do IMAP é que ele possui comandos que permitem que um agente do usuário obtenha
componentes de mensagens. Por exemplo, um agente de usuário pode obter apenas o cabeçalho de uma mensagem ou apenas
uma parte de uma mensagem MIME com várias partes. Este recurso é útil quando há uma conexão de baixa largura de
banda (por exemplo, um link de modem de baixa velocidade) entre o agente do usuário e seu servidor de correio. Com um
conexão de baixa largura de banda, o usuário pode não querer baixar todas as mensagens em sua caixa de correio,
especialmente evitando mensagens longas que possam conter, por exemplo, um áudio ou videoclipe.
E-mail baseado na Web
Cada vez mais usuários estão enviando e acessando seus e-mails por meio de seus navegadores da Web. O Hotmail introduziu o
acesso baseado na Web em meados da década de 1990. Agora, o e-mail baseado na Web também é fornecido pelo Google,
Yahoo!, assim como quase todas as grandes universidades e corporações. Com esse serviço, o agente do usuário é um navegador
da Web comum e o usuário se comunica com sua caixa de correio remota via HTTP. Quando um
destinatário, como Bob, deseja acessar uma mensagem em sua caixa de correio, a mensagem de e-mail é enviada do servidor
de correio de Bob para o navegador de Bob usando o protocolo HTTP em vez do protocolo POP3 ou IMAP.
Quando um remetente, como Alice, deseja enviar uma mensagem de e-mail, a mensagem de e-mail é enviada de seu navegador
para seu servidor de e-mail por HTTP em vez de SMTP. O servidor de correio de Alice, no entanto, ainda envia e recebe
mensagens de outros servidores de correio usando SMTP.

2.4 DNS—O serviço de diretório da Internet
Nós, seres humanos, podemos ser identificados de várias maneiras. Por exemplo, podemos ser identificados pelos nomes que
aparecem em nossas certidões de nascimento. Podemos ser identificados pelos nossos números de segurança social.
Podemos ser identificados pelos números de nossas carteiras de motorista. Embora cada um desses identificadores possa ser
usado para identificar pessoas, dentro de um determinado contexto, um identificador pode ser mais apropriado do que outro. Por exemplo, o
os computadores do IRS (a infame agência de cobrança de impostos nos Estados Unidos) preferem usar números de previdência
social de tamanho fixo em vez de nomes de certidões de nascimento. Por outro lado, as pessoas comuns preferem nomes de
certidões de nascimento mais mnemônicos do que números de previdência social. (De fato, você pode imaginar dizer: “Oi.
Meu nome é 132-67-9875. Por favor, conheça meu marido, 178-87-1146.”)
Assim como os humanos podem ser identificados de várias maneiras, os hosts da Internet também podem. Um identificador para um host é seu
nome de anfitrião. Nomes de host—como www.facebook.com, www.google.com ,
gaia.cs.umass.edu — são mnemônicos e, portanto, apreciados pelos humanos. No entanto, os nomes de host
fornecem pouca ou nenhuma informação sobre o local na Internet do host. (A
nome do host como www.eurecom.fr , que termina com o código do país .fr , nos diz que o host é
provavelmente na França, mas não diz muito mais.) Além disso, como os nomes de host podem consistir em caracteres
alfanuméricos de comprimento variável, eles seriam difíceis de processar pelos roteadores. Por esses motivos, os hosts
também são identificados pelos chamados endereços IP.
Discutimos endereços IP com algum detalhe no Capítulo 4, mas é útil dizer algumas palavras breves sobre eles agora. Um
endereço IP consiste em quatro bytes e possui uma estrutura hierárquica rígida. Um endereço IP
parece 121.7.106.83 , onde cada ponto separa um dos bytes expressos em decimal
notação de 0 a 255. Um endereço IP é hierárquico porque, conforme examinamos o endereço da esquerda para a direita, obtemos
informações cada vez mais específicas sobre onde o host está localizado na Internet (isto é, dentro de qual rede, na rede de
redes). Da mesma forma, quando examinamos um endereço postal de baixo para cima, obtemos informações cada vez mais
específicas sobre a localização do destinatário.
2.4.1 Serviços prestados pelo DNS
Acabamos de ver que existem duas maneiras de identificar um host - por um nome de host e por um endereço IP.
As pessoas preferem o identificador de nome de host mais mnemônico, enquanto os roteadores preferem tamanho fixo, hierarquicamente
endereços IP estruturados. Para conciliar essas preferências, precisamos de um serviço de diretório que
traduz nomes de host em endereços IP. Esta é a principal tarefa do sistema de nome de domínio (DNS) da Internet. O DNS é
(1) um banco de dados distribuído implementado em uma hierarquia de servidores DNS e (2) um
protocolo da camada de aplicação que permite que os hosts consultem o banco de dados distribuído. Os servidores DNS são frequentemente
Máquinas UNIX executando o software Berkeley Internet Name Domain (BIND) [BIND 2016]. O protocolo DNS é executado
em UDP e usa a porta 53.
O DNS é comumente empregado por outros protocolos de camada de aplicativo, incluindo HTTP e SMTP para
traduzir nomes de host fornecidos pelo usuário em endereços IP. Como exemplo, considere o que acontece quando um
navegador (ou seja, um cliente HTTP), em execução no host de algum usuário, solicita a URL
www.someschool.edu/ index.html . Para que o host do usuário possa enviar uma solicitação HTTP
mensagem para o servidor Web www.someschool.edu , o host do usuário deve primeiro obter o endereço IP do
www.someschool.edu . Isto se faz do seguinte modo.
1. A mesma máquina do usuário executa o lado do cliente do aplicativo DNS.

2. O navegador extrai o nome do host, nome do host www.someschool.edu para , da URL e passa o
o lado do cliente do aplicativo DNS.
3. O cliente DNS envia uma consulta contendo o nome do host para um servidor DNS.
4. O cliente DNS eventualmente recebe uma resposta, que inclui o endereço IP do nome do host.
5. Depois que o navegador recebe o endereço IP do DNS, ele pode iniciar uma conexão TCP com o processo do
servidor HTTP localizado na porta 80 desse endereço IP.
Vemos neste exemplo que o DNS acrescenta um atraso adicional — às vezes substancial — aos aplicativos da Internet que
o utilizam. Felizmente, como discutimos abaixo, o endereço IP desejado geralmente é armazenado em cache em um
servidor DNS “próximo”, o que ajuda a reduzir o tráfego de rede DNS, bem como o atraso médio do DNS.
O DNS fornece alguns outros serviços importantes além de traduzir nomes de host em endereços IP:
Aliasing de host. Um host com um nome de host complicado pode ter um ou mais nomes alternativos. Para
Por exemplo, um nome de host como relay1.west-coast.enterprise.com poderia ter, digamos, dois
aliases como enterprise.com e www.enterprise.com . Nesse caso, o nome de host relay1.west-coast.enterprise.com
é considerado um nome de host canônico. Nomes de host de alias, quando presentes, são tipicamente mais mnemônicos
do que nomes de host canônicos. O DNS pode ser invocado por um aplicativo para obter o nome de host canônico para
um nome de host de alias fornecido, bem como o endereço IP

do anfitrião.
Aliasing do servidor de correio. Por razões óbvias, é altamente desejável que os endereços de e-mail sejam mnemônicos.
Por exemplo, se Bob tiver uma conta no Yahoo Mail, o endereço de e-mail de Bob pode ser tão simples quanto
bob@yahoo.mail . No entanto, o nome do host do servidor de e-mail do Yahoo é mais complicado e muito menos
mnemônico do que simplesmente yahoo.com (por exemplo, o nome do host canônico pode ser algo como
relay1.west-coast.yahoo.com ). O DNS pode ser invocado por um aplicativo de correio para obter o nome de host canônico
para um nome de host de alias fornecido, bem como o endereço IP do host.
Na verdade, o registro MX (veja abaixo) permite que o servidor de correio de uma empresa e o servidor Web tenham endereços idênticos
(aliases) nomes de host; por exemplo, o servidor Web e o servidor de correio de uma empresa podem ser chamados
enterprise. com .
Distribuição de carga. O DNS também é usado para executar a distribuição de carga entre os servidores replicados, como
servidores Web replicados. Sites ocupados, como cnn.com , cada , são replicados em vários servidores, com
servidor rodando em um sistema final diferente e cada um com um endereço IP diferente. Para replicado
Servidores da Web, um conjunto de endereços IP é, portanto, associado a um nome de host canônico. O banco de
dados DNS contém esse conjunto de endereços IP. Quando os clientes fazem uma consulta DNS para um nome mapeado
para um conjunto de endereços, o servidor responde com todo o conjunto de endereços IP, mas alterna a ordem dos
endereços em cada resposta. Como um cliente geralmente envia sua mensagem de solicitação HTTP para o endereço IP
listado primeiro no conjunto, a rotação de DNS distribui o tráfego entre os servidores replicados. A rotação de DNS também
é usada para e-mail para que vários servidores de e-mail possam ter o mesmo nome de alias. Além disso, empresas de
distribuição de conteúdo, como a Akamai, usaram o DNS de forma mais sofisticada
maneiras [Dilley 2002] de fornecer distribuição de conteúdo da Web (consulte a Seção 2.6.3).
O DNS é especificado em RFC 1034 e RFC 1035 e atualizado em vários RFCs adicionais. É um sistema complexo, e nós
apenas abordamos os aspectos-chave de sua
PRINCÍPIOS NA PRÁTICA
DNS: FUNÇÕES CRÍTICAS DE REDE ATRAVÉS DO PARADIGMA CLIENTE-SERVIDOR
Como HTTP, FTP e SMTP, o protocolo DNS é um protocolo de camada de aplicativo, pois (1) é executado entre
sistemas finais em comunicação usando o paradigma cliente-servidor e (2) depende de um protocolo de transporte
ponta a ponta subjacente para transferir Mensagens DNS entre a comunicação
sistemas finais. Em outro sentido, porém, a função do DNS é bem diferente da Web, da transferência de arquivos e
dos aplicativos de e-mail. Ao contrário desses aplicativos, o DNS não é um aplicativo com o qual um usuário interage
diretamente. Em vez disso, o DNS fornece uma função central da Internet - ou seja, traduzir nomes de host em seus
endereços IP subjacentes, para aplicativos de usuário e outros softwares
na internet. Observamos na Seção 1.2 que grande parte da complexidade da arquitetura da Internet está localizada nas
“bordas” da rede. O DNS, que implementa o nome crítico para
processo de conversão de endereço usando clientes e servidores localizados na borda da rede, é mais um exemplo
dessa filosofia de design.
operação aqui. O leitor interessado deve consultar essas RFCs e o livro de Albitz e Liu [Albitz 1993]; veja também o artigo
retrospectivo [Mockapetris 1988], que fornece uma boa descrição do que e por quê do DNS, e [Mockapetris 2005].
2.4.2 Visão geral de como funciona o DNS
Apresentamos agora uma visão geral de alto nível de como o DNS funciona. Nossa discussão se concentrará no hostname-to-
Serviço de tradução de endereços IP.
Suponha que algum aplicativo (como um navegador da Web ou um leitor de e-mail) em execução no host de um usuário
precise traduzir um nome de host em um endereço IP. O aplicativo invocará o lado do cliente do DNS, especificando
o nome do host que precisa ser traduzido. (Em muitas máquinas baseadas em UNIX, gethostbyname() é a chamada de função
que um aplicativo chama para executar a tradução.) O DNS no host do usuário assume o controle, enviando uma
mensagem de consulta à rede. Todas as mensagens DNS de consulta e resposta são enviadas em datagramas UDP
para a porta 53. Após um atraso, variando de milissegundos a segundos, o DNS no endereço do usuário
host recebe uma mensagem de resposta DNS que fornece o mapeamento desejado. Este mapeamento é então passado para
o aplicativo de chamada. Assim, do ponto de vista do aplicativo de chamada no host do usuário, o DNS é uma caixa preta que
fornece um serviço de tradução simples e direto. Mas, na verdade, a caixa preta que implementa o serviço é
complexa, consistindo em um grande número de servidores DNS distribuídos ao redor do globo, bem como um protocolo de
camada de aplicativo que especifica como os servidores DNS e os hosts de consulta

comunicar.
Um design simples para DNS teria um servidor DNS que contém todos os mapeamentos. Nesse projeto centralizado, os
clientes simplesmente direcionam todas as consultas para um único servidor DNS, e o servidor DNS responde diretamente
aos clientes que fazem a consulta. Embora a simplicidade desse design seja atraente, ele é inadequado para a Internet de
hoje, com seu vasto (e crescente) número de hosts. Os problemas com um design centralizado incluem:
Um único ponto de falha. Se o servidor DNS travar, toda a Internet também cairá!
Volume de trafego. Um único servidor DNS teria que lidar com todas as consultas DNS (para todas as
solicitações HTTP e mensagens de e-mail geradas por centenas de milhões de hosts).
Banco de dados centralizado distante. Um único servidor DNS não pode estar “próximo” de todos os clientes que
fazem a consulta. Se colocarmos o único servidor DNS na cidade de Nova York, todas as consultas da Austrália
devem viajar para o outro lado do globo, talvez por links lentos e congestionados. Isso pode levar a atrasos significativos.
Manutenção. O único servidor DNS teria que manter registros para todos os hosts da Internet. Esse banco de dados
centralizado não apenas seria enorme, mas também teria que ser atualizado com frequência para dar conta de cada
novo host.
Em resumo, um banco de dados centralizado em um único servidor DNS simplesmente não escala. Consequentemente,
o DNS é distribuído por design. Na verdade, o DNS é um exemplo maravilhoso de como um banco de dados distribuído pode
ser implementado na Internet.
Um banco de dados distribuído e hierárquico
Para lidar com a questão da escala, o DNS utiliza um grande número de servidores, organizados de forma
hierárquica e distribuídos ao redor do mundo. Nenhum servidor DNS único possui todos os mapeamentos para
todos os hosts na Internet. Em vez disso, os mapeamentos são distribuídos pelos servidores DNS. Em uma primeira
aproximação, existem três classes de servidores DNS — servidores DNS raiz, DNS de domínio de nível superior (TLD)
servidores e servidores DNS autorizados — organizados em uma hierarquia conforme mostrado na Figura 2.17. Para
entender como essas três classes de servidores interagem, suponha que um cliente DNS queira determinar o IP
endereço para o nome do host www.amazon.com . Para um primeiro
Figura 2.17 Parte da hierarquia dos servidores DNS
aproximação, ocorrerão os seguintes eventos. O cliente primeiro contata um dos servidores raiz,
que retorna endereços IP para servidores TLD para o domínio de nível superior com . O cliente então contata um
desses servidores TLD, que retorna o endereço IP de um servidor autorizado para amazon.com . Finalmente,
o cliente entra em contato com um dos servidores autorizados para amazon.com , que retorna o endereço IP para
o nome do host www.amazon.com . Em breve examinaremos esse processo de pesquisa de DNS com mais detalhes. Mas vamos
primeiro dê uma olhada nessas três classes de servidores DNS:
Servidores DNS raiz. Existem mais de 400 servidores de nomes raiz espalhados por todo o mundo. A Figura 2.18 mostra os
países que possuem servidores de nomes raiz, com países com mais de dez sombreados escuros. Esses servidores de
nomes raiz são gerenciados por 13 organizações diferentes. A lista completa de servidores de nomes raiz, juntamente com as
organizações que os gerenciam e seus endereços IP, pode ser encontrada
em [Servidores Raiz 2016]. Os servidores de nomes raiz fornecem os endereços IP dos servidores TLD.
Servidores de domínio de nível superior (TLD). Para cada um dos domínios de nível superior — domínios de nível superior,
como com, org, net, edu e gov, e todos os domínios de nível superior do país, como uk, fr, ca e jp — existe um servidor TLD
(ou cluster de servidor). A empresa Verisign Global Registry Services mantém
os servidores TLD para o domínio de primeiro nível com , e a empresa Educause mantém o TLD
servidores para o domínio de nível superior edu . A infra-estrutura de rede que suporta um TLD pode ser grande e
complexo; consulte [Osterweil 2012] para obter uma boa visão geral da rede Verisign. Consulte [lista de TLDs de 2016] para
obter uma lista de todos os domínios de nível superior. Os servidores TLD fornecem os endereços IP para servidores DNS autoritativos.
Figura 2.18 Servidores raiz DNS em 2016
Servidores DNS autoritativos. Toda organização com hosts acessíveis publicamente (como servidores da Web e
servidores de email) na Internet deve fornecer registros DNS acessíveis publicamente que mapeiam os nomes desses
hosts para endereços IP. O servidor DNS autoritativo de uma organização hospeda esses registros DNS. Uma
organização pode optar por implementar seu próprio servidor DNS autorizado para manter esses registros;
alternativamente, a organização pode pagar para ter esses registros armazenados em um servidor DNS autorizado de
algum provedor de serviços. A maioria das universidades e grandes empresas implementam e mantêm seu próprio
servidor DNS autoritativo primário e secundário (backup).
A raiz, o TLD e os servidores DNS autoritativos pertencem todos à hierarquia dos servidores DNS, conforme mostrado em
Figura 2.17. Existe outro tipo importante de servidor DNS chamado servidor DNS local. Um servidor DNS local não
pertence estritamente à hierarquia de servidores, mas é central para a arquitetura DNS. Cada ISP — como um ISP
residencial ou um ISP institucional — tem um servidor DNS local (também chamado de servidor de nomes padrão). Quando
um host se conecta a um ISP, o ISP fornece ao host os endereços IP de um ou mais de seus servidores DNS locais
(normalmente por meio de DHCP, que é discutido em
Capítulo 4). Você pode determinar facilmente o endereço IP do seu servidor DNS local acessando as janelas de status
da rede no Windows ou UNIX. O servidor DNS local de um host geralmente está “próximo” do host. Para um
ISP institucional, o servidor DNS local pode estar na mesma LAN que o host; para um ISP residencial, é
normalmente separados do host por não mais do que alguns roteadores. Quando um host faz uma consulta DNS, a consulta
é enviada para o servidor DNS local, que atua como proxy, encaminhando a consulta para o servidor DNS
hierarquia, como discutiremos com mais detalhes abaixo.
Vamos dar uma olhada em um exemplo simples. Suponha que o host cse.nyu.edu deseja o endereço IP de
gaia.cs.umass.edu . Suponha também que o servidor DNS local da NYU para cse.nyu.edu seja chamado
dns.nyu.edu e que um servidor DNS autorizado para gaia.cs.umass.edu é chamado
dns.umass.edu . Conforme mostrado na Figura 2.19, o host cse.nyu.edu primeiro envia uma consulta DNS
mensagem para seu servidor DNS local, dns.nyu.edu . A mensagem de consulta contém o nome do host a ser
traduzido, ou seja, gaia.cs.umass.edu . O servidor DNS local encaminha a mensagem de consulta para um servidor DNS
raiz. O servidor DNS raiz anota o sufixo edu e retorna ao servidor DNS local um
lista de endereços IP para servidores TLD responsáveis por edu . O servidor DNS local reenvia a consulta
mensagem para um desses servidores TLD. O servidor TLD anota o sufixo umass.edu e responde com o endereço IP
do servidor DNS autorizado da Universidade de Massachusetts,
ou seja, dns.umass.edu . Finalmente, o servidor DNS local reenvia a mensagem de consulta diretamente para
dns.umass.edu , que responde com o endereço IP de gaia.cs.umass.edu . Observe que neste
Por exemplo, para obter o mapeamento de um nome de host, foram enviadas oito mensagens DNS: quatro consultas
mensagens e quatro mensagens de resposta! Em breve veremos como o cache de DNS reduz esse tráfego de consulta.
Nosso exemplo anterior assumiu que o servidor TLD conhece o servidor DNS autorizado para o
nome de anfitrião. Em geral, isso nem sempre é verdade. Em vez disso, o servidor TLD
Figura 2.19 Interação dos vários servidores DNS

pode conhecer apenas um servidor DNS intermediário, que por sua vez conhece o servidor DNS autorizado para o nome do
host. Por exemplo, suponha novamente que a Universidade de Massachusetts tenha um servidor DNS para o
universidade, chamada dns.umass.edu . Suponha também que cada um dos departamentos da Universidade de
Massachusetts tenha seu próprio servidor DNS e que cada servidor DNS departamental tenha autoridade para todos
anfitriões no departamento. Neste caso, quando o servidor DNS intermediário, dns.umass.edu , recebe um
consulta para um host com um nome de host terminando com cs.umass.edu, ele retorna para dns.nyu.edu o IP
endereço de dns.cs.umass.edu , que é autoritário para todos os nomes de host que terminam com cs.umass.edu .
O servidor DNS local dns.nyu.edu então envia a consulta ao servidor DNS autorizado, que retorna o mapeamento
desejado ao servidor DNS local, que por sua vez retorna o mapeamento ao host solicitante. Neste caso, um total de 10
mensagens DNS são enviadas!
O exemplo mostrado na Figura 2.19 faz uso de consultas recursivas e iterativas. A consulta enviada de cse.nyu.edu
para dns.nyu.edu é uma consulta recursiva, pois a consulta pergunta
dns.nyu.edu para obter o mapeamento em seu nome. Mas as três consultas subsequentes são iterativas, pois todas as
respostas são retornadas diretamente para dns.nyu.edu . Em teoria, qualquer consulta de DNS pode ser iterativa ou
recursivo. Por exemplo, a Figura 2.20 mostra uma cadeia de consulta DNS para a qual todas as consultas são recursivas.
Na prática, as consultas geralmente seguem o padrão da Figura 2.19: a consulta do host solicitante ao servidor DNS local é
recursiva e as consultas restantes são iterativas.
Cache de DNS
Nossa discussão até agora ignorou o cache do DNS, um recurso extremamente importante do sistema DNS. Na verdade,
o DNS explora extensivamente o cache do DNS para melhorar o desempenho do atraso e reduzir o número de mensagens
DNS
Figura 2.20 Consultas recursivas no DNS
ricocheteando na Internet. A ideia por trás do cache DNS é muito simples. Em uma cadeia de consulta, quando um servidor
DNS recebe uma resposta DNS (contendo, por exemplo, um mapeamento de um nome de host para um IP
endereço), ele pode armazenar em cache o mapeamento em sua memória local. Por exemplo, na Figura 2.19, cada vez que
o servidor DNS local dns.nyu.edu recebe uma resposta de algum servidor DNS, ele pode armazenar em cache qualquer
informação contida na resposta. Se um par de nome de host/endereço IP for armazenado em cache em um servidor
DNS e outra consulta chegar ao servidor DNS para o mesmo nome de host, o servidor DNS poderá fornecer o endereço IP
desejado, mesmo que não seja autoritativo para o nome de host. Como os hosts e os mapeamentos entre nomes de host e
endereços IP não são permanentes, os servidores DNS descartam as informações armazenadas em cache após um período de tempo
(muitas vezes definido para dois dias).
Como exemplo, suponha que um host apricot.nyu.edu consulte dns.nyu.edu para obter o endereço IP de
o nome do host cnn.com . Além disso, suponha que algumas horas depois, outro host da NYU, digamos,
também consulta dns.nyu.edu com o mesmo nome de host. Por causa do cache, o local kiwi.nyu.edu ,
O servidor DNS poderá retornar imediatamente o endereço IP de cnn.com para este segundo solicitante
host sem ter que consultar nenhum outro servidor DNS. Um servidor DNS local também pode armazenar em cache o IP
endereços de servidores TLD, permitindo assim que o servidor DNS local ignore os servidores DNS raiz em uma cadeia de
consulta. Na verdade, por causa do cache, os servidores raiz são ignorados para quase todas as consultas de DNS, exceto uma
fração muito pequena.
2.4.3 Registros e mensagens de DNS
Os servidores DNS que juntos implementam o banco de dados distribuído DNS armazenam registros de recursos (RRs), incluindo
RRs que fornecem mapeamentos de nome de host para endereço IP. Cada mensagem de resposta DNS carrega um ou mais
registros de recursos. Nesta e na próxima subseção, fornecemos uma breve visão geral do DNS
registros e mensagens de recursos; mais detalhes podem ser encontrados em [Albitz 1993] ou no DNS RFCs [RFC 1034; RFC
1035].
Um registro de recurso é uma tupla de quatro que contém os seguintes campos:
(Nome, Valor, Tipo, TTL)
TTL é o tempo de vida do registro de recurso; determina quando um recurso deve ser removido de um
cache. Nos registros de exemplo fornecidos abaixo, ignoramos o campo TTL . O significado de Nome e Valor
depende do tipo :
Se Type=A , Name é um nome de host e Value é o endereço IP do nome de host. Assim, um registro Tipo A fornece o
mapeamento padrão de nome de host para endereço IP. Como um exemplo,
(relay1.bar.foo.com, 145.37.93.126, A) é um registro Tipo A.
Se Type=NS , Name é um domínio (como foo.com ) e Value é o nome do host de um

servidor DNS autoritativo que sabe como obter os endereços IP dos hosts no domínio. Esse
O registro é usado para rotear consultas de DNS mais adiante na cadeia de consulta. Por exemplo, (foo.com,
dns.foo.com, NS) é um registro do tipo NS.
Se Type=CNAME , Value é um nome de host canônico para o alias hostname Name . este registro
pode fornecer aos hosts de consulta o nome canônico para um nome de host. Por exemplo, (foo.com,
relay1.bar.foo.com, CNAME) é um registro CNAME.
Se Type=MX , Value é o nome canônico de um servidor de e-mail que possui um alias hostname Name .
Por exemplo, (foo.com, mail.bar.foo.com, MX) é um registro MX. Os registros MX permitem que os nomes de host dos
servidores de correio tenham aliases simples. Observe que, ao usar o registro MX, uma empresa pode ter o mesmo nome de
alias para seu servidor de correio e para um de seus outros servidores (como seu servidor Web). Para obter o nome
canônico para o servidor de correio, um cliente DNS consultaria um MX

registro; para obter o nome canônico para o outro servidor, o cliente DNS consultaria o CNAME
registro.
Se um servidor DNS for autorizado para um nome de host específico, o servidor DNS conterá um registro Tipo A para o nome
do host. (Mesmo que o servidor DNS não seja autoritativo, ele pode conter um registro Tipo A em seu cache.) Se um servidor não
for autoritativo para um nome de host, o servidor conterá um registro Tipo NS para o domínio que inclui o nome do host; ele
também conterá um registro Tipo A que fornece o IP
endereço do servidor DNS no campo Valor do registro NS. Como exemplo, suponha que um TLD edu
o servidor não tem autoridade para o host gaia.cs.umass.edu . Então este servidor conterá um registro para um domínio que inclui
o host gaia.cs.umass.edu , por exemplo, (umass.edu,
dns.umass.edu, NS) . O servidor TLD edu também conteria um registro Tipo A, que mapeia o
Servidor DNS dns.umass.edu para um endereço IP, por exemplo, (dns.umass.edu,
128.119.40.111, A) .
Mensagens DNS
Anteriormente nesta seção, nos referimos às mensagens de consulta e resposta de DNS. Esses são os dois únicos tipos de
mensagens DNS. Além disso, as mensagens de consulta e resposta têm o mesmo formato, conforme mostrado na
Figura 2.21. A semântica dos vários campos em uma mensagem DNS é a seguinte:
Os primeiros 12 bytes são a seção de cabeçalho, que possui vários campos. O primeiro campo é um número de 16 bits
que identifica a consulta. Esse identificador é copiado na mensagem de resposta a uma consulta, permitindo que o cliente
compare as respostas recebidas com as consultas enviadas. Há uma série de sinalizadores no campo de sinalizador. Um
sinalizador de consulta/resposta de 1 bit indica se a mensagem é uma consulta (0) ou uma resposta (1). Um sinalizador
autoritativo de 1 bit é
Figura 2.21 Formato de mensagem DNS
definido em uma mensagem de resposta quando um servidor DNS é um servidor autoritativo para um nome consultado. Um
sinalizador desejado de recursão de 1 bit é definido quando um cliente (host ou servidor DNS) deseja que o servidor DNS execute
recursão quando não possui o registro. Um campo disponível para recursão de 1 bit é definido em uma resposta se o servidor DNS
oferecer suporte à recursão. No cabeçalho, há também quatro campos de número. Esses campos indicam o número de ocorrências
dos quatro tipos de seções de dados que seguem o cabeçalho.
A seção de perguntas contém informações sobre a consulta que está sendo feita. Esta seção inclui (1) um campo de nome que contém
o nome que está sendo consultado e (2) um campo de tipo que indica o tipo de pergunta feita sobre o nome - por exemplo, um
endereço de host associado a um nome (Tipo A ) ou o servidor de correio para um nome (Tipo MX).
Em uma resposta de um servidor DNS, a seção de resposta contém os registros de recursos para o nome originalmente consultado.
Lembre-se que em cada registro de recurso existe o Tipo (por exemplo, A, NS,
CNAME e MX), o nome de host Value , e o TTL . Uma resposta pode retornar vários RRs na resposta, pois um
pode ter vários endereços IP (por exemplo, para servidores da Web replicados, conforme discutido anteriormente nesta seção).
A seção de autoridade contém registros de outros servidores autorizados.
A seção adicional contém outros registros úteis. Por exemplo, o campo de resposta em uma resposta a uma consulta MX contém um
registro de recurso que fornece o nome de host canônico de um servidor de correio. A seção adicional contém um registro Tipo
A fornecendo o endereço IP para o nome de host canônico de

o servidor de correio.
Como você gostaria de enviar uma mensagem de consulta DNS diretamente do host em que está trabalhando para algum servidor
DNS? Isso pode ser feito facilmente com o programa nslookup, disponível na maioria dos
Plataformas Windows e UNIX. Por exemplo, em um host Windows, abra o prompt de comando e
chame o programa nslookup simplesmente digitando “nslookup”. Depois de invocar o nslookup, você pode enviar um DNS
consulta a qualquer servidor DNS (raiz, TLD ou autoritativo). Depois de receber a mensagem de resposta do servidor DNS, o nslookup
exibirá os registros incluídos na resposta (em um formato legível por humanos). Como alternativa para executar o nslookup a partir
de seu próprio host, você pode visitar um dos muitos sites da Web que permitem o uso remoto do nslookup. (Basta digitar “nslookup” em
um mecanismo de busca e você será levado a um desses sites.) O laboratório DNS Wireshark no final deste capítulo permitirá que você
explore o DNS em muito

Mais detalhes.
Inserindo registros no banco de dados DNS
A discussão acima se concentrou em como os registros são recuperados do banco de dados DNS. Você pode estar se perguntando
como os registros entram no banco de dados em primeiro lugar. Vejamos como isso é feito no contexto de um exemplo específico.
Suponha que você acabou de criar uma nova empresa iniciante chamada Network Utopia. A primeira coisa que você certamente deseja
fazer é registrar o nome de domínio

networkutopia.com em um registrador. Um registrador é uma entidade comercial que verifica a exclusividade do nome de
domínio, insere o nome de domínio no banco de dados DNS (conforme discutido abaixo) e cobra uma pequena taxa de você por
seus serviços. Antes de 1999, um único registrador, Network Solutions, tinha o monopólio
sobre o registro de nomes de domínio para , líquido , e domínios org . Mas agora existem muitos registradores
competindo por clientes e a Internet Corporation for Assigned Names and Numbers (ICANN)
credencia os vários registradores. Uma lista completa de registradores credenciados está disponível em http://
www.internic.net .
Ao registrar o nome de domínio networkutopia.com com algum registrador, você também precisa fornecer ao registrador
os nomes e endereços IP de seu DNS autoritativo primário e secundário
servidores. Suponha que os nomes e endereços IP sejam dns1.networkutopia.com ,
dns2.networkutopia.com , 212.2.212.1 e 212.212.212.2. Para cada um desses dois servidores DNS autorizados, o
registrador garantiria que um registro do Tipo NS e um do Tipo A fossem inseridos nos servidores TLD com. Especificamente,
para o servidor autoritativo primário para
o registrador inseriria os dois registros de recursos a seguir no DNS networkutopia.com ,
sistema:
(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
Você também terá que certificar-se de que o registro de recurso Tipo A para seu servidor Web
www.networkutopia.com e o registro de recurso Type MX para seu servidor de correio
mail.networkutopia.com são inseridos em seu DNS autorizado
FOCO NA SEGURANÇA
VULNERABILIDADES DE DNS
Vimos que o DNS é um componente crítico da infraestrutura da Internet, com muitos
serviços importantes - incluindo a Web e o e-mail - simplesmente incapazes de funcionar sem eles.
Portanto, naturalmente perguntamos: como o DNS pode ser atacado? O DNS é um alvo fácil, esperando para ser
retirado de serviço, ao mesmo tempo em que destrói a maioria dos aplicativos da Internet?
O primeiro tipo de ataque que vem à mente é um ataque DDoS de inundação de largura de banda (consulte a Seção
1.6) contra servidores DNS. Por exemplo, um invasor pode tentar enviar para cada servidor raiz DNS um dilúvio de
pacotes, tantos que a maioria das consultas DNS legítimas nunca é respondida. Um ataque DDoS em grande
escala contra os servidores raiz DNS realmente ocorreu em
21 de outubro de 2002. Nesse ataque, os invasores usaram uma botnet para enviar cargas de mensagens de ping
ICMP para cada um dos 13 endereços IP raiz do DNS. (As mensagens ICMP são discutidas em
Seção 5.6. Por enquanto, basta saber que os pacotes ICMP são tipos especiais de datagramas IP.)
Felizmente, esse ataque em grande escala causou danos mínimos, tendo pouco ou nenhum impacto na experiência dos
usuários na Internet. Os invasores conseguiram direcionar um dilúvio de pacotes na raiz
servidores. Mas muitos dos servidores raiz do DNS eram protegidos por filtros de pacotes, configurados para sempre
bloquear todas as mensagens de ping ICMP direcionadas aos servidores raiz. Esses servidores protegidos foram assim
poupados e funcionando normalmente. Além disso, a maioria dos servidores DNS locais armazena em cache os endereços IP
dos servidores de domínio de nível superior, permitindo que o processo de consulta muitas vezes ignore os servidores raiz DNS.
Um ataque DDoS potencialmente mais eficaz contra o DNS seria enviar um dilúvio de consultas DNS para servidores de
domínio de nível superior, por exemplo, para todos os servidores de domínio de nível superior que lidam com o domínio .com.
Seria mais difícil filtrar as consultas DNS direcionadas aos servidores DNS; e os servidores de domínio de nível superior não
são ignorados tão facilmente quanto os servidores raiz. Mas a gravidade de tal ataque seria parcialmente mitigada pelo
armazenamento em cache nos servidores DNS locais.
O DNS pode ser atacado de outras maneiras. Em um ataque man-in-the-middle, o invasor intercepta consultas de hosts e
retorna respostas falsas. No ataque de envenenamento de DNS, o
O invasor envia respostas falsas para um servidor DNS, enganando o servidor para que aceite registros falsos em seu cache.
Qualquer um desses ataques pode ser usado, por exemplo, para redirecionar um usuário desavisado da Web para o site do
invasor. Esses ataques, no entanto, são difíceis de implementar, pois
exigem a interceptação de pacotes ou limitação de servidores [Skoudis 2006].
Em resumo, o DNS demonstrou ser surpreendentemente robusto contra ataques. A data,
não houve um ataque que tenha impedido com sucesso o serviço DNS.
servidores. (Até recentemente, o conteúdo de cada servidor DNS era configurado estaticamente, por exemplo, a partir de um arquivo de
configuração criado por um gerente do sistema. Mais recentemente, uma opção UPDATE foi adicionada ao protocolo DNS para permitir
que os dados sejam adicionados ou excluídos dinamicamente o banco de dados via DNS
mensagens. [RFC 2136] e [RFC 3007] especificam atualizações dinâmicas de DNS.)
Depois que todas essas etapas forem concluídas, as pessoas poderão visitar seu site e enviar e-mail aos funcionários de sua empresa.
Vamos concluir nossa discussão sobre o DNS verificando se essa afirmação é verdadeira. Essa verificação também ajuda a solidificar
o que aprendemos sobre o DNS. Suponha que Alice na Austrália
deseja visualizar a página da Web www.networkutopia.com . Conforme discutido anteriormente, seu host primeiro enviará uma consulta
DNS para seu servidor DNS local. O servidor DNS local entrará em contato com um servidor TLD com . (O
servidor DNS local também terá que entrar em contato com um servidor DNS raiz se o endereço de um servidor TLD com não for
em cache.) Este servidor TLD contém os registros de recursos Tipo NS e Tipo A listados acima, porque o registrador inseriu esses registros
de recursos em todos os servidores TLD com. O servidor TLD com envia uma resposta ao servidor DNS local de Alice, com a
resposta contendo os dois registros de recursos. O local
O servidor DNS envia uma consulta DNS para 212.212.212.1 , solicitando o registro Tipo A correspondente
para www.networkutopia.com . Este registro fornece o endereço IP do servidor Web desejado, digamos,
212.212.71.4 , que o servidor DNS local repassa para o host de Alice. O navegador de Alice agora pode
inicie uma conexão TCP com o host 212.212.71.4 e envie uma solicitação HTTP pela conexão.
Ufa! Há muito mais acontecendo do que aparenta quando alguém navega na Web!
2.5 Distribuição de arquivos ponto a ponto
Os aplicativos descritos neste capítulo até agora — incluindo Web, e-mail e DNS — empregam arquiteturas cliente-servidor com dependência
significativa de servidores de infra-estrutura sempre ativos. Recuperar de
Seção 2.1.1 que, com uma arquitetura P2P, há uma dependência mínima (ou nenhuma) de servidores de infraestrutura sempre ativos. Em vez
disso, pares de hosts conectados intermitentemente, chamados de pares, se comunicam diretamente entre si. Os pares não são de propriedade
de um provedor de serviços, mas sim desktops e laptops controlados
por usuários.
Nesta seção, consideramos um aplicativo P2P muito natural, ou seja, distribuir um arquivo grande de um único
servidor para um grande número de hosts (chamados pares). O arquivo pode ser uma nova versão do sistema operacional Linux, um patch de
software para um sistema operacional ou aplicativo existente, um arquivo de música MP3 ou um
Arquivo de vídeo MPEG. Na distribuição de arquivo cliente-servidor, o servidor deve enviar uma cópia do arquivo para cada um dos pares —
colocando uma carga enorme no servidor e consumindo uma grande quantidade de largura de banda do servidor.
Na distribuição de arquivos P2P, cada ponto pode redistribuir qualquer parte do arquivo que recebeu para qualquer outro ponto, auxiliando
assim o servidor no processo de distribuição. A partir de 2016, o arquivo P2P mais popular
protocolo de distribuição é BitTorrent. Originalmente desenvolvido por Bram Cohen, agora existem muitos
clientes BitTorrent independentes em conformidade com o protocolo BitTorrent, assim como existem vários clientes de navegador da Web que
estão em conformidade com o protocolo HTTP. Nesta subseção, primeiro examinamos o self
escalabilidade de arquiteturas P2P no contexto de distribuição de arquivos. Em seguida, descrevemos o BitTorrent com algum detalhe,
destacando suas características e recursos mais importantes.
Escalabilidade de Arquiteturas P2P
Para comparar arquiteturas cliente-servidor com arquiteturas ponto a ponto e ilustrar a autoescalabilidade inerente do P2P, consideramos agora
um modelo quantitativo simples para distribuir um arquivo para um conjunto fixo de
pares para ambos os tipos de arquitetura. Conforme mostrado na Figura 2.22, o servidor e os pares estão conectados à Internet com links de
acesso. Denote a taxa de upload do link de acesso do servidor por u o link de acesso do i-ésimo par por u, e a taxa de s, a taxa de upload de
download do link de acesso do i-ésimo par por d. Também denota o

eu eu
tamanho do arquivo a ser distribuído (em bits) por F e o número de peers que desejam obter uma cópia do arquivo por N. O tempo de
distribuição é o tempo que leva para obter

Figura 2.22 Um problema ilustrativo de distribuição de arquivos
uma cópia do arquivo para todos os N pares. Em nossa análise do tempo de distribuição abaixo, tanto para cliente-servidor quanto para
Em arquiteturas P2P, fazemos a suposição simplificadora (e geralmente precisa [Akella 2003]) de que o núcleo da Internet possui largura
de banda abundante, o que implica que todos os gargalos estão nas redes de acesso. Também supomos que o servidor e os clientes
não estão participando de nenhum outro aplicativo de rede, de modo que toda a largura de banda de acesso para upload e download
possa ser totalmente dedicada à distribuição desse arquivo.
Vamos primeiro determinar o tempo de distribuição para a arquitetura cliente-servidor, que denotamos por D . Na arquitetura cliente-
cs
servidor, nenhum dos pares auxilia na distribuição do arquivo. Nós fazemos o seguinte
observações:
O servidor deve transmitir uma cópia do arquivo para cada um dos N pares. Assim, o servidor deve transmitir bits NF . Como a taxa
de upload do servidor é u s, o tempo para distribuir o arquivo deve ser no mínimo NF/ u . s
Seja d min
a taxa de download do par com a taxa de download mais baixa, ou seja,
dmin=min{d1,dp,. . .,dN}. O par com a menor taxa de download não pode obter todos os bits F do arquivo em
menos de F/d segundos.
min Assim, o tempo mínimo de distribuição é de pelo menos F/d . min
Juntando essas duas observações, obtemos
Dcsÿmax{NFus,Fdmin}.
Isso fornece um limite inferior no tempo mínimo de distribuição para a arquitetura cliente-servidor. No
problemas de lição de casa, você será solicitado a mostrar que o servidor pode agendar suas transmissões para que o limite
inferior seja realmente alcançado. Portanto, vamos considerar esse limite inferior fornecido acima como o tempo de distribuição
real, ou seja,
Dcs=max{NFus,Fdmin} (2.1)
Vemos na Equação 2.1 que para N grande o suficiente, o tempo de distribuição cliente-servidor é dado por NF/u . s
Assim, o tempo de distribuição aumenta linearmente com o número de pares N. Então, por exemplo, se o número de pares
de uma semana para a próxima aumentar mil vezes de mil para um milhão, o tempo
necessário para distribuir o arquivo a todos os pares aumenta em 1.000.
Vamos agora fazer uma análise similar para a arquitetura P2P, onde cada peer pode auxiliar o servidor na distribuição do
arquivo. Em particular, quando um par recebe alguns dados de arquivo, ele pode usar sua própria capacidade de
upload para redistribuir os dados para outros pares. Calcular o tempo de distribuição para a arquitetura P2P é um pouco
mais complicado do que para a arquitetura cliente-servidor, pois o tempo de distribuição
depende de como cada par distribui partes do arquivo para os outros pares. Ainda assim, um simples
expressão para o tempo mínimo de distribuição pode ser obtida [Kumar 2006]. Para isso, inicialmente fazemos as
seguintes observações:
No início da distribuição, apenas o servidor possui o arquivo. Para colocar esse arquivo na comunidade de peers, o
servidor deve enviar cada bit do arquivo pelo menos uma vez em seu link de acesso. Assim, o mínimo
o tempo de distribuição é de pelo menos

s F/u . (Ao contrário do esquema cliente-servidor, um bit enviado uma vez pelo
servidor pode não precisar ser enviado novamente pelo servidor, pois os pares podem redistribuir o bit entre si.)
Assim como na arquitetura cliente-servidor, o par com a menor taxa de download não pode obter todos os bits F
do arquivo em menos de F/d segundos.
min Assim, o tempo mínimo de distribuição é de pelo menos F/d . min
Por fim, observe que a capacidade total de upload do sistema como um todo é igual à taxa de upload do servidor mais
as taxas de upload de cada um dos pares individuais, ou seja, utotal=us+u1+ÿ+uN. O
o sistema deve entregar (carregar) F bits para cada um dos N pares, entregando assim um total de NF bits. Esse
não pode ser feito a uma taxa mais rápida do que
total u . Assim, o tempo mínimo de distribuição também é pelo menos
NF/(us+u1+ÿ+uN).
Juntando essas três observações, obtemos o tempo mínimo de distribuição para P2P, denotado por
D.P2P
_
DP2Pÿmax{Fus,Fdmin,NFus+ÿi=1Nui} (2.2)
A Equação 2.2 fornece um limite inferior para o tempo mínimo de distribuição para a arquitetura P2P. Acontece que se
imaginarmos que cada par pode redistribuir um bit assim que receber o bit, então existe um
esquema de redistribuição que realmente atinge esse limite inferior [Kumar 2006]. (Provaremos um caso especial desse
resultado na lição de casa.) Na realidade, onde partes do arquivo são redistribuídas em vez de
bits individuais, a Equação 2.2 serve como uma boa aproximação do tempo de distribuição mínimo real.
Assim, vamos tomar o limite inferior fornecido pela Equação 2.2 como o tempo de distribuição mínimo real, ou seja,
DP2P=max{Fus,Fdmin,NFus+ÿi=1Nui} (2.3)
A Figura 2.23 compara o tempo mínimo de distribuição para as arquiteturas cliente-servidor e P2P
assumindo que todos os pares têm a mesma taxa de upload u. Na Figura 2.23, estabelecemos e F/u=1 hora, us=10u,
dminÿus. Assim, um peer pode transmitir o arquivo inteiro em uma hora, a taxa de transmissão do servidor é 10
vezes a taxa de upload de pares,
Figura 2.23 Tempo de distribuição para arquiteturas P2P e cliente-servidor
e (para simplificar) as taxas de download de pares são definidas suficientemente grandes para não terem efeito. Nós vemos
da Figura 2.23 , para a arquitetura cliente-servidor, o tempo de distribuição aumenta linearmente e sem limites conforme
o número de pares aumenta. No entanto, para a arquitetura P2P, o tempo mínimo de distribuição nem sempre é menor
que o tempo de distribuição da arquitetura cliente-servidor; isso é
também menos de uma hora para qualquer número de pares N. Assim, aplicações com a arquitetura P2P podem ser
autoescaláveis. Essa escalabilidade é uma consequência direta de os pares serem redistribuidores e também consumidores.
de bits.
BitTorrent
BitTorrent é um protocolo P2P popular para distribuição de arquivos [Chao 2011]. Na linguagem do BitTorrent, a coleção de
todos os pares que participam da distribuição de um determinado arquivo são chamados de torrent. Os pares em um torrent baixam pedaços de
tamanho igual do arquivo um do outro, com um tamanho de pedaço típico de 256 KBytes. Quando um par se junta a um torrent pela primeira
vez, ele não tem pedaços. Com o tempo, acumula mais e mais pedaços. Enquanto baixa pedaços, também carrega pedaços para
outros pares. Uma vez que um par tenha adquirido o arquivo inteiro, ele pode (egoisticamente) deixar o torrent ou (altruisticamente) permanecer no
torrent e continuar a enviar partes para outros pares. Além disso, qualquer par pode deixar o torrent a qualquer momento com apenas um subconjunto
de pedaços e depois voltar ao
torrente.
Vamos agora dar uma olhada em como o BitTorrent opera. Como o BitTorrent é um protocolo e sistema bastante complicado,
descreveremos apenas seus mecanismos mais importantes, varrendo alguns dos detalhes para debaixo do tapete; isso nos permitirá ver a
floresta através das árvores. Cada torrent tem uma infraestrutura
nó chamado rastreador.
Figura 2.24 Distribuição de arquivos com BitTorrent
Quando um par ingressa em um torrent, ele se registra no rastreador e periodicamente informa ao rastreador que ainda está no torrent. Dessa forma,
o rastreador acompanha os pares que estão participando do torrent.
Um determinado torrent pode ter menos de dez ou mais de mil pares participando em qualquer instante de
tempo.
Conforme mostrado na Figura 2.24, quando um novo par, Alice, entra no torrent, o rastreador seleciona aleatoriamente
um subconjunto de pares (para concretude, digamos 50) do conjunto de pares participantes e envia os endereços IP
desses 50 pares para Alice. . Possuindo esta lista de pares, Alice tenta estabelecer conexões TCP concorrentes com
todos os pares desta lista. Vamos chamar todos os pares com os quais Alice
consegue estabelecer uma conexão TCP “pares vizinhos”. (Na Figura 2.24, Alice mostra ter apenas três pares vizinhos.
Normalmente, ela teria muitos mais.) Com o passar do tempo, alguns desses pares podem sair e outros pares (fora dos 50
iniciais) podem tentar estabelecer conexões TCP com Alice. Portanto, os pares vizinhos de um par irão flutuar ao longo do tempo.
A qualquer momento, cada par terá um subconjunto de blocos do arquivo, com diferentes pares tendo diferentes
subconjuntos. Periodicamente, Alice perguntará a cada um de seus pares vizinhos (através das conexões TCP)
para a lista dos pedaços que eles têm. Se Alice tiver L vizinhos diferentes, ela obterá L listas de chunks.
Com esse conhecimento, Alice emitirá solicitações (novamente pelas conexões TCP) para pedaços que ela atualmente
não tem.
Assim, em qualquer instante de tempo, Alice terá um subconjunto de pedaços e saberá quais pedaços seus vizinhos têm.
Com essas informações, Alice terá duas decisões importantes a tomar. Primeiro, quais pedaços ela deveria solicitar
primeiro de seus vizinhos? E segundo, para qual de seus vizinhos ela deveria enviar os pedaços solicitados? Ao decidir quais
pedaços solicitar, Alice usa uma técnica chamada mais rara primeiro.
A ideia é determinar, dentre os chunks que ela não possui, os chunks que são os mais raros entre seus vizinhos (isto é, os
chunks que possuem menos cópias repetidas entre seus vizinhos) e então solicitar primeiro aqueles chunks mais raros. Dessa
forma, os chunks mais raros são redistribuídos mais rapidamente, visando igualar (aproximadamente) o número de
cópias de cada chunk no torrent.
Para determinar a quais solicitações ela responde, o BitTorrent usa um algoritmo de negociação inteligente. A ideia básica
é que Alice dá prioridade aos vizinhos que estão atualmente fornecendo seus dados na taxa mais alta.
Especificamente, para cada um de seus vizinhos, Alice mede continuamente a taxa na qual ela recebe bits e determina os
quatro pares que estão alimentando seus bits na taxa mais alta. Ela então retribui enviando pedaços para esses mesmos
quatro pares. A cada 10 segundos, ela recalcula as taxas e possivelmente
modifica o conjunto de quatro pares. No jargão do BitTorrent, esses quatro pares são considerados desbloqueados.
É importante ressaltar que, a cada 30 segundos, ela também escolhe um vizinho adicional aleatoriamente e o envia em blocos.
Vamos chamar o par escolhido aleatoriamente de Bob. No jargão do BitTorrent, diz-se que Bob não está sufocado com otimismo.
Como Alice está enviando dados para Bob, ela pode se tornar um dos quatro principais uploaders de Bob, caso em que Bob
começaria a enviar dados para Alice. Se a taxa na qual Bob envia dados para Alice for alta o suficiente, Bob
poderia então, por sua vez, se tornar um dos quatro principais uploaders de Alice. Em outras palavras, a cada 30 segundos,
Alice escolherá aleatoriamente um novo parceiro comercial e iniciará a negociação com esse parceiro. Se os dois pares
estiverem satisfeitos com a negociação, eles colocarão um ao outro em suas quatro listas principais e continuarão negociando
entre si até que um dos pares encontre um parceiro melhor. O efeito é que os pares capazes de fazer upload em taxas
compatíveis tendem a se encontrar. A seleção aleatória de vizinhos também permite que novos pares obtenham pedaços, para
que possam ter algo para negociar. Todos os outros pares vizinhos além desses cinco pares
(quatro peers “top” e um peer de sondagem) são “sufocados”, isto é, eles não recebem nenhum chunk de Alice.
BitTorrent tem uma série de mecanismos interessantes que não são discutidos aqui, incluindo pedaços (mini chunks), pipelining,
primeira seleção aleatória, modo de final de jogo e anti-snubbing [Cohen 2003].
O mecanismo de incentivo para negociação que acabamos de descrever é muitas vezes referido como tit-for-tat [Cohen 2003]. Tem
foi demonstrado que esse esquema de incentivo pode ser contornado [Liogkas 2006; Locher 2006; Piatek 2007]. No
entanto, o ecossistema BitTorrent é extremamente bem-sucedido, com milhões de pares simultâneos compartilhando ativamente
arquivos em centenas de milhares de torrents. Se o BitTorrent tivesse sido projetado sem olho por olho (ou uma variante), mas
exatamente igual, o BitTorrent provavelmente nem existiria agora, já que o
a maioria dos usuários teria sido freeriders [Saroiu 2002].
Encerramos nossa discussão sobre P2P mencionando brevemente outra aplicação de P2P, a saber, Distributed Hast Table
(DHT). Uma tabela de hash distribuída é um banco de dados simples, com os registros do banco de dados sendo
distribuídos entre os pares em um sistema P2P. DHTs foram amplamente implementados (por exemplo, em BitTorrent) e foram
objeto de extensa pesquisa. Uma visão geral é fornecida em uma Nota de vídeo no site complementar.
Andando por tabelas de hash distribuídas

2.6 Streaming de Vídeo e Redes de Distribuição de Conteúdo
O streaming de vídeo pré-gravado agora representa a maior parte do tráfego em ISPs residenciais na América do Norte. Em
particular, os serviços Netflix e YouTube sozinhos consumiram 37% e 16%,
respectivamente, do tráfego ISP residencial em 2015 [Sandvine 2015]. Nesta seção, forneceremos uma visão geral de
como os serviços populares de streaming de vídeo são implementados na Internet atual. Veremos que eles são implementados
usando protocolos de nível de aplicativo e servidores que funcionam de certa forma como um cache.
No Capítulo 9, dedicado à rede multimídia, examinaremos mais detalhadamente o vídeo na Internet, bem como outros
Serviços multimédia na Internet.
2.6.1 Vídeo na Internet
Em aplicativos de streaming de vídeo armazenado, a mídia subjacente é um vídeo pré-gravado, como um filme, um
programa de televisão, um evento esportivo pré-gravado ou um vídeo pré-gravado gerado pelo usuário (como os comumente
vistos no YouTube). Esses vídeos pré-gravados são colocados em servidores e os usuários enviam
solicitações aos servidores para visualizar os vídeos sob demanda. Muitas empresas de Internet hoje fornecem
streaming de vídeo, incluindo Netflix, YouTube (Google), Amazon e Youku.
Mas, antes de iniciar uma discussão sobre streaming de vídeo, devemos primeiro ter uma ideia rápida do meio de vídeo em si.
Um vídeo é uma sequência de imagens, normalmente exibidas a uma taxa constante, por exemplo, 24 ou 30 imagens
por segundo. Uma imagem não comprimida e codificada digitalmente consiste em uma matriz de pixels, com cada pixel
codificado em vários bits para representar luminância e cor. Um
Uma característica importante do vídeo é que ele pode ser compactado, trocando assim a qualidade do vídeo pela taxa de bits.
Os algoritmos de compressão disponíveis atualmente podem compactar um vídeo para praticamente qualquer taxa de bits
desejado. Obviamente, quanto maior a taxa de bits, melhor a qualidade da imagem e melhor a experiência geral de
visualização do usuário.
Do ponto de vista da rede, talvez a característica mais saliente do vídeo seja sua alta taxa de bits.
O vídeo compactado da Internet geralmente varia de 100 kbps para vídeo de baixa qualidade a mais de 3 Mbps para
streaming de filmes de alta definição; O streaming 4K prevê uma taxa de bits de mais de 10 Mbps. Isso pode se traduzir
em uma grande quantidade de tráfego e armazenamento, principalmente para vídeos de última geração. Por exemplo, um único
vídeo de 2 Mbps com duração de 67 minutos consumirá 1 gigabyte de armazenamento e tráfego. De longe, a medida de
desempenho mais importante para streaming de vídeo é a taxa de transferência média de ponta a ponta. Para fornecer
reprodução contínua, a rede deve fornecer uma taxa de transferência média para o streaming
aplicativo que seja pelo menos tão grande quanto a taxa de bits do vídeo compactado.
Também podemos usar compactação para criar várias versões do mesmo vídeo, cada uma com um nível de qualidade diferente.
Por exemplo, podemos usar compactação para criar, digamos, três versões do mesmo vídeo, a taxas de 300 kbps, 1 Mbps e 3
Mbps. Os usuários podem então decidir qual versão desejam assistir em função da largura de banda disponível no momento. Os
usuários com conexões de Internet de alta velocidade podem escolher a versão de 3 Mbps; os usuários que assistem ao vídeo em
3G com um smartphone podem escolher a versão de 300 kbps.
2.6.2 Transmissão HTTP e DASH
No streaming HTTP, o vídeo é simplesmente armazenado em um servidor HTTP como um arquivo comum com um URL específico.
Quando um usuário deseja ver o vídeo, o cliente estabelece uma conexão TCP com o servidor e emite
uma solicitação HTTP GET para esse URL. O servidor então envia o arquivo de vídeo, dentro de uma mensagem de resposta
HTTP, tão rapidamente quanto os protocolos de rede subjacentes e as condições de tráfego permitirem. no cliente
lado, os bytes são coletados em um buffer de aplicativo cliente. Quando o número de bytes nesse buffer excede um limite
predeterminado, o aplicativo cliente inicia a reprodução — especificamente, o aplicativo de streaming de vídeo captura
periodicamente quadros de vídeo do buffer do aplicativo cliente, descompacta os quadros e os exibe na tela do usuário. Assim,
o aplicativo de streaming de vídeo está exibindo o vídeo enquanto recebe e armazena em buffer os quadros correspondentes
às últimas partes do vídeo.
Embora o streaming HTTP, conforme descrito no parágrafo anterior, tenha sido amplamente implantado em
prática (por exemplo, pelo YouTube desde a sua criação), tem uma grande falha: todos os clientes recebem a mesma codificação
do vídeo, apesar das grandes variações na quantidade de largura de banda disponível para um cliente, tanto entre clientes diferentes
quanto ao longo do tempo para o mesmo cliente. Isso levou ao desenvolvimento de um novo tipo de streaming baseado em HTTP,
muitas vezes chamado de Streaming Adaptável Dinâmico sobre HTTP.
(TRAÇO). No DASH, o vídeo é codificado em várias versões diferentes, com cada versão tendo uma taxa de bits diferente
e, correspondentemente, um nível de qualidade diferente. O cliente solicita dinamicamente blocos de segmentos de vídeo de alguns
segundos de duração. Quando a quantidade de largura de banda disponível é alta, o cliente seleciona naturalmente trechos de
uma versão de alta taxa; e quando a largura de banda disponível é baixa, naturalmente
seleciona a partir de uma versão de baixo custo. O cliente seleciona blocos diferentes, um de cada vez, com solicitação HTTP GET
mensagens [Akhshabi 2011].
O DASH permite que clientes com diferentes taxas de acesso à Internet transmitam vídeo em diferentes taxas de codificação.
Clientes com conexões 3G de baixa velocidade podem receber uma versão de baixa taxa de bits (e de baixa qualidade), e
clientes com conexões de fibra podem receber uma versão de alta qualidade. O DASH também permite que um cliente se
adapte à largura de banda disponível se a largura de banda de ponta a ponta disponível mudar durante a sessão. Esse recurso
é particularmente importante para usuários móveis, que normalmente veem sua disponibilidade de largura de banda flutuar à
medida que se movem em relação às estações base.
Com o DASH, cada versão do vídeo é armazenada no servidor HTTP, cada uma com uma URL diferente. o HTTP
O servidor também possui um arquivo de manifesto, que fornece uma URL para cada versão junto com sua taxa de bits. O cliente primeiro
solicita o arquivo de manifesto e aprende sobre as várias versões. O cliente então seleciona um pedaço de cada vez, especificando um URL
e um intervalo de bytes em uma mensagem de solicitação HTTP GET para cada pedaço.
Durante o download dos chunks, o cliente também mede a largura de banda recebida e executa um algoritmo de determinação
de taxa para selecionar o chunk a ser solicitado a seguir. Naturalmente, se o cliente tiver muitos vídeos
armazenado em buffer e se a largura de banda de recebimento medida for alta, ele escolherá um pedaço de uma versão de alta
taxa de bits. E, naturalmente, se o cliente tiver pouco buffer de vídeo e a largura de banda recebida medida for baixa, ele escolherá um
pedaço de uma versão de baixa taxa de bits. DASH, portanto, permite que o cliente alterne livremente entre
diferentes níveis de qualidade.
2.6.3 Redes de distribuição de conteúdo
Hoje, muitas empresas de vídeo na Internet estão distribuindo fluxos multi-Mbps sob demanda para milhões de usuários diariamente. O
YouTube, por exemplo, com uma biblioteca de centenas de milhões de vídeos, distribui centenas de milhões de streams de vídeo para
usuários em todo o mundo todos os dias. Transmitir todo esse tráfego para locais em todo o mundo, ao mesmo tempo em que fornece
reprodução contínua e alta interatividade, é claramente um
Tarefa desafiante.
Para uma empresa de vídeo na Internet, talvez a abordagem mais direta para fornecer streaming de vídeo
serviço é construir um único centro de dados massivo, armazenar todos os seus vídeos no centro de dados e transmitir os vídeos diretamente
do centro de dados para clientes em todo o mundo. Mas há três grandes problemas com essa abordagem. Primeiro, se o cliente estiver
longe do data center, os pacotes servidor-cliente cruzarão muitos links de comunicação e provavelmente passarão por muitos
ISPs, com alguns dos ISPs possivelmente localizados em diferentes continentes. Se um desses links fornecer uma taxa de transferência
menor que a taxa de consumo de vídeo, a taxa de transferência de ponta a ponta também ficará abaixo da taxa de consumo, resultando
em congelamento irritante
atrasos para o usuário. (Lembre-se do Capítulo 1 de que a taxa de transferência de ponta a ponta de um fluxo é governada pela taxa de
transferência no link gargalo.) A probabilidade de isso acontecer aumenta conforme o número de links
no caminho de ponta a ponta aumenta. Uma segunda desvantagem é que um vídeo popular provavelmente será enviado várias vezes
pelos mesmos links de comunicação. Isso não apenas desperdiça largura de banda da rede, mas também a Internet
a própria empresa de vídeo estará pagando seu provedor ISP (conectado ao data center) para enviar os mesmos bytes para a Internet
repetidamente. Um terceiro problema com esta solução é que um único centro de dados representa um único ponto de falha - se o centro de
dados ou seus links para a Internet caírem, não
ser capaz de distribuir qualquer fluxo de vídeo.
Para enfrentar o desafio de distribuir grandes quantidades de dados de vídeo para usuários distribuídos em
no mundo, quase todas as principais empresas de streaming de vídeo fazem uso de redes de distribuição de conteúdo (CDNs). Um
CDN gerencia servidores em vários locais geograficamente distribuídos, armazena cópias dos vídeos (e outros tipos de conteúdo da Web,
incluindo documentos, imagens e áudio) em seus servidores e tenta direcionar cada solicitação do usuário para um local CDN que
fornecerá o melhor experiência do usuário. O

A CDN pode ser uma CDN privada, ou seja, de propriedade do próprio provedor de conteúdo; por exemplo, o CDN do Google distribui
vídeos do YouTube e outros tipos de conteúdo. A CDN pode, alternativamente, ser uma CDN de terceiros que distribui conteúdo em
nome de vários provedores de conteúdo; Akamai, Limelight e Level-3 todos
operar CDNs de terceiros. Uma visão geral bastante legível das CDNs modernas é [Leighton 2009; Nygren 2010].
Os CDNs normalmente adotam uma das duas filosofias de posicionamento de servidor diferentes [Huang 2008]:
Entre no Profundo. Uma filosofia, iniciada pela Akamai, é entrar profundamente nas redes de acesso dos provedores de serviços
de Internet, implantando clusters de servidores em ISPs de acesso em todo o mundo. (Acesso
as redes são descritas na Seção 1.3.) A Akamai adota essa abordagem com clusters em aproximadamente 1.700 locais. O objetivo é
aproximar-se dos usuários finais, melhorando assim o atraso percebido pelo usuário e a taxa de transferência, diminuindo o número de
links e roteadores entre o usuário final e o servidor CDN do qual recebe o conteúdo. Devido a esse design altamente distribuído, a tarefa
de manter e gerenciar os clusters torna-se desafiadora.
Traga para casa. Uma segunda filosofia de projeto, adotada pela Limelight e muitas outras empresas de CDN, é trazer os ISPs para casa
construindo grandes clusters em um número menor (por exemplo, dezenas) de sites.
Em vez de entrar nos ISPs de acesso, esses CDNs normalmente colocam seus clusters na Internet
Pontos de troca (IXPs) (consulte a Seção 1.3). Comparado com a filosofia de projeto de entrada profunda, o projeto de trazer para
casa normalmente resulta em menor sobrecarga de manutenção e gerenciamento, possivelmente à custa de maior atraso e menor
rendimento para os usuários finais.
Uma vez que seus clusters estão no lugar, o CDN replica o conteúdo em seus clusters. O CDN pode não querer
coloque uma cópia de cada vídeo em cada cluster, já que alguns vídeos raramente são vistos ou são populares apenas em
alguns países. Na verdade, muitos CDNs não enviam vídeos para seus clusters, mas usam uma estratégia de pull simples: se um cliente
solicita um vídeo de um cluster que não está armazenando o vídeo, o cluster recupera o vídeo (de um repositório central ou de outro cluster) e
armazena uma cópia localmente durante o streaming
o vídeo para o cliente ao mesmo tempo. Cache da Web semelhante (consulte a Seção 2.2.5), quando o armazenamento de um cluster
fica cheio, ele remove os vídeos que não são solicitados com frequência.
Operação CDN
Tendo identificado as duas principais abordagens para a implantação de um CDN, vamos agora mergulhar nas porcas
e detalhes de como uma CDN opera. Quando um navegador no navegador de um usuário
ESTUDO DE CASO
INFRAESTRUTURA DA REDE DO GOOGLE
Para oferecer suporte a sua vasta gama de serviços em nuvem, incluindo pesquisa, Gmail, calendário, vídeo do YouTube,
mapas, documentos e redes sociais - o Google implantou uma extensa rede privada e infraestrutura de CDN. A infraestrutura de
CDN do Google tem três níveis de clusters de servidores:

Quatorze “mega data centers”, com oito na América do Norte, quatro na Europa e dois na Ásia [Google
Locations 2016], com cada data center tendo cerca de 100.000 servidores.
Esses mega datacenters são responsáveis por fornecer conteúdo dinâmico (e muitas vezes personalizado),
incluindo resultados de pesquisa e mensagens do Gmail.
Estima-se que existam 50 clusters em IXPs espalhados pelo mundo, com cada cluster consistindo na ordem de
100 a 500 servidores [Adhikari 2011a]. Esses clusters são responsáveis por servir conteúdo estático,
incluindo vídeos do YouTube [Adhikari 2011a].
Muitas centenas de clusters “enter-deep” localizados dentro de um ISP de acesso. Aqui, um cluster
geralmente consiste em dezenas de servidores em um único rack. Esses servidores profundos executam
Divisão de TCP (consulte a Seção 3.7) e veicula conteúdo estático [Chen 2011], incluindo as partes estáticas
de páginas da Web que incorporam resultados de pesquisa.
Todos esses centros de dados e locais de cluster são conectados em rede com a própria rede privada do Google.
Quando um usuário faz uma consulta de pesquisa, geralmente a consulta é enviada primeiro pelo ISP local para um
cache próximo, de onde o conteúdo estático é recuperado; ao fornecer o conteúdo estático ao cliente, o cache
próximo também encaminha a consulta pela rede privada do Google para um dos mega datacenters, de onde são
recuperados os resultados de pesquisa personalizados. Para um vídeo do YouTube, o vídeo em si pode vir de um
dos caches de acesso direto, enquanto partes da página da Web ao redor do vídeo podem vir do cache enter-deep
próximo e os anúncios ao redor do vídeo vêm dos centros de dados. Em resumo, exceto para os ISPs locais, os
serviços em nuvem do Google são amplamente fornecidos por uma infraestrutura de rede independente da Internet
pública.
host é instruído a recuperar um vídeo específico (identificado por um URL), o CDN deve interceptar a solicitação para que
possa (1) determinar um cluster de servidor CDN adequado para esse cliente naquele momento e (2) redirecionar a
solicitação do cliente para um servidor nesse cluster. Discutiremos em breve como um CDN pode determinar um cluster
adequado. Mas primeiro vamos examinar a mecânica por trás da interceptação e redirecionamento de uma solicitação.
A maioria dos CDNs aproveita o DNS para interceptar e redirecionar solicitações; uma discussão interessante sobre tal
um uso do DNS é [Vixie 2009]. Vamos considerar um exemplo simples para ilustrar como o DNS normalmente está
envolvido. Suponha que um provedor de conteúdo, NetCinema, empregue a empresa terceirizada de CDN, KingCDN, para
distribuir seus vídeos para seus clientes. Nas páginas da Web do NetCinema, cada um de seus vídeos recebe um
URL que inclui a string “vídeo” e um identificador exclusivo para o próprio vídeo; por exemplo, transformadores
7 pode ser atribuído http://video.netcinema.com/6Y7B23V. Seis etapas então ocorrem, como mostrado na Figura
2.25:
1. O usuário visita a página da Web no NetCinema.
2. Quando o usuário clica no link http://video.netcinema.com/6Y7B23V, o host do usuário envia um
Consulta de DNS para video.netcinema.com.

3. O servidor DNS local (LDNS) do usuário retransmite a consulta DNS para um servidor DNS autorizado para
NetCinema, que observa a string “video” no nome do host video.netcinema.com. Para “entregar” a consulta DNS ao KingCDN,
em vez de retornar um endereço IP, o servidor DNS autorizado do NetCinema retorna ao LDNS um nome de host
no domínio do KingCDN, por
exemplo, a1105.kingcdn.com.
4. Deste ponto em diante, a consulta DNS entra na infraestrutura DNS privada da KingCDN. O LDNS do usuário então envia uma
segunda consulta, agora para a1105.kingcdn.com, e o sistema DNS da KingCDN eventualmente retorna os endereços IP de
um servidor de conteúdo KingCDN para o LDNS. É assim aqui,
dentro do sistema DNS do KingCDN, que o servidor CDN do qual o cliente receberá seu
o conteúdo é especificado.
Figura 2.25 DNS redireciona a solicitação de um usuário para um servidor CDN
5. O LDNS encaminha o endereço IP do nó CDN de serviço de conteúdo para o host do usuário.

6. Depois que o cliente recebe o endereço IP de um servidor de conteúdo KingCDN, ele estabelece uma
conexão TCP direta com o servidor nesse endereço IP e emite uma solicitação HTTP GET para o
vídeo. Se DASH for usado, o servidor primeiro enviará ao cliente um arquivo de manifesto com uma lista de URLs,
um para cada versão do vídeo, e o cliente selecionará dinamicamente pedaços dos diferentes
versões.
Estratégias de Seleção de Cluster
No centro de qualquer implantação de CDN está uma estratégia de seleção de cluster, ou seja, um mecanismo para
direcionar clientes dinamicamente para um cluster de servidor ou um datacenter dentro do CDN. Como acabamos de ver, o
O CDN aprende o endereço IP do servidor LDNS do cliente por meio da pesquisa de DNS do cliente. Depois de aprender esse
endereço IP, o CDN precisa selecionar um cluster apropriado com base nesse endereço IP. CDNs geralmente empregam
estratégias proprietárias de seleção de cluster. Agora examinamos brevemente algumas abordagens, cada uma das quais
tem suas próprias vantagens e desvantagens.
Uma estratégia simples é atribuir o cliente ao cluster geograficamente mais próximo. Usando
bancos de dados comerciais de geolocalização (como Quova [Quova 2016] e Max-Mind [MaxMind 2016]), cada endereço IP
LDNS é mapeado para uma localização geográfica. Quando uma solicitação de DNS é recebida de um
determinado LDNS, o CDN escolhe o cluster geograficamente mais próximo, ou seja, o cluster que é o
menos quilômetros do LDNS “como o pássaro voa”. Tal solução pode funcionar razoavelmente bem para um grande
fração dos clientes [Agarwal 2009]. No entanto, para alguns clientes, a solução pode ter um desempenho ruim, pois o cluster
geograficamente mais próximo pode não ser o cluster mais próximo em termos de comprimento ou número de saltos do caminho
de rede. Além disso, um problema inerente a todas as abordagens baseadas em DNS é que alguns
os usuários finais são configurados para usar LDNSs localizados remotamente [Shaikh 2001; Mao 2002], caso em que a localização
do LDNS pode estar longe da localização do cliente. Além disso, essa estratégia simples ignora a variação de atraso e largura de
banda disponível ao longo do tempo dos caminhos da Internet, sempre atribuindo o mesmo cluster a um
determinado cliente.
Para determinar o melhor cluster para um cliente com base nas condições de tráfego atuais , os CDNs podem, em vez disso,
realizar medições periódicas em tempo real de atraso e desempenho de perda entre seus
clusters e clientes. Por exemplo, um CDN pode fazer com que cada um de seus clusters envie sondagens periodicamente (por
exemplo, mensagens de ping ou consultas de DNS) para todos os LDNSs em todo o mundo. Uma desvantagem dessa abordagem
é que muitos LDNSs são configurados para não responder a essas sondagens.
2.6.4 Estudos de caso: Netflix, YouTube e Kankan
Concluímos nossa discussão sobre streaming de vídeo armazenado analisando três implantações de grande sucesso em grande
escala: Netflix, YouTube e Kankan. Veremos que cada um desses sistemas adota uma abordagem muito diferente, mas emprega
muitos dos princípios subjacentes discutidos nesta seção.
Netflix
Gerando 37% do tráfego downstream em ISPs residenciais na América do Norte em 2015, a Netflix
tornar-se o principal provedor de serviços de filmes e séries de TV on-line nos Estados Unidos [Sandvine
2015]. Conforme discutimos abaixo, a distribuição de vídeo da Netflix tem dois componentes principais: a nuvem da Amazon e
sua própria infraestrutura de CDN privada.
A Netflix tem um site que lida com várias funções, incluindo registro e login do usuário, cobrança,
catálogo de filmes para navegar e pesquisar e um sistema de recomendação de filmes. Como mostrado na Figura
2.26, este site da Web (e seus bancos de dados de back-end associados) são executados inteiramente em servidores
da Amazon na nuvem da Amazon. Além disso, a nuvem da Amazon lida com as seguintes funções críticas:
Ingestão de conteúdo. Antes que a Netflix possa distribuir um filme para seus clientes, ela deve primeiro receber e
processar o filme. A Netflix recebe versões master de estúdio de filmes e as envia para hosts em
a nuvem amazônica.
Processamento de conteúdo. As máquinas na nuvem da Amazon criam muitos formatos diferentes para cada filme,
adequados para uma gama diversificada de reprodutores de vídeo clientes executados em computadores
desktop, smartphones e consoles de jogos conectados a televisões. Uma versão diferente é criada para cada um desses
formatos e em várias taxas de bits, permitindo streaming adaptável por HTTP usando DASH.
Carregar versões para seu CDN. Depois que todas as versões de um filme foram criadas, os hosts na nuvem da Amazon
carregam as versões em seu CDN.
Figura 2.26 Plataforma de streaming de vídeo Netflix
Quando a Netflix lançou seu serviço de streaming de vídeo pela primeira vez em 2007, ela contratou três empresas
CDN terceirizadas para distribuir seu conteúdo de vídeo. Desde então, a Netflix criou sua própria CDN privada, da qual
agora transmite todos os seus vídeos. (No entanto, a Netflix ainda usa a Akamai para distribuir suas páginas da Web.) Para
criar sua própria CDN, a Netflix instalou racks de servidor em IXPs e nos próprios ISPs residenciais.
Atualmente, a Netflix possui racks de servidores em mais de 50 locais IXP; consulte [Netflix Open Connect 2016] para
obter uma lista atual de IXPs com racks Netflix. Existem também centenas de locais de ISP que abrigam racks Netflix;
consulte também [Netflix Open Connect 2016], onde a Netflix fornece a potenciais parceiros ISP instruções sobre como
instalar um rack Netflix (gratuito) para suas redes. Cada servidor no rack possui vários servidores de 10 Gbps
Portas Ethernet e mais de 100 terabytes de armazenamento. O número de servidores em um rack varia: as instalações
IXP geralmente têm dezenas de servidores e contêm toda a biblioteca de streaming de vídeo da Netflix, incluindo várias versões
dos vídeos para suportar DASH; IXPs locais podem ter apenas um servidor e conter apenas
os vídeos mais populares. A Netflix não usa pull-caching (Seção 2.2.5) para preencher seus servidores CDN nos IXPs e ISPs. Em
vez disso, a Netflix distribui enviando os vídeos para seus servidores CDN fora do horário de pico. Para os locais que não
podem conter toda a biblioteca, a Netflix envia apenas os vídeos mais populares, que são determinados diariamente. O design
Netflix CDN é descrito em alguns detalhes
nos vídeos do YouTube [Netflix Video 1] e [Netflix Video 2].
Tendo descrito os componentes da arquitetura Netflix, vamos dar uma olhada mais de perto na interação entre o cliente e os
vários servidores envolvidos na entrega do filme. Conforme indicado anteriormente, as páginas da Web para navegar na videoteca
do Netflix são servidas de servidores na nuvem da Amazon. Quando um usuário seleciona um filme para reproduzir, o software
Netflix, executado na nuvem da Amazon, determina primeiro qual de seus servidores CDN possui cópias do filme. Entre os servidores
que possuem o filme, o software então
determina o “melhor” servidor para aquela solicitação do cliente. Se o cliente estiver usando um ISP residencial que tenha um
O rack do servidor Netflix CDN instalado naquele ISP, e este rack tem uma cópia do filme solicitado, então um servidor neste
rack é normalmente selecionado. Caso contrário, um servidor em um IXP próximo normalmente é selecionado.
Depois que a Netflix determina o servidor CDN que entregará o conteúdo, ela envia ao cliente o endereço IP
do servidor específico, bem como um arquivo de manifesto, que contém as URLs para as diferentes versões do
filme solicitado. O cliente e esse servidor CDN interagem diretamente usando uma versão proprietária de
TRAÇO. Especificamente, conforme descrito na Seção 2.6.2, o cliente usa o cabeçalho de intervalo de bytes em mensagens de
solicitação HTTP GET para solicitar blocos de diferentes versões do filme. A Netflix usa trechos que
têm aproximadamente quatro segundos de duração [Adhikari 2012]. Enquanto os chunks estão sendo baixados, o cliente
mede a taxa de transferência recebida e executa um algoritmo de determinação de taxa para determinar a qualidade do
próximo chunk a ser solicitado.
A Netflix incorpora muitos dos princípios-chave discutidos anteriormente nesta seção, incluindo
distribuição de streaming e CDN. No entanto, como a Netflix usa sua própria CDN privada, que distribui apenas vídeo (e não
páginas da Web), a Netflix conseguiu simplificar e adaptar seu design de CDN. Em particular,
A Netflix não precisa empregar o redirecionamento de DNS, conforme discutido na Seção 2.6.3, para conectar um determinado
cliente a um servidor CDN; em vez disso, o software Netflix (em execução na nuvem da Amazon) diz diretamente ao cliente para usar
um determinado servidor CDN. Além disso, o Netflix CDN usa cache push em vez de pull
cache (Seção 2.2.5): o conteúdo é enviado para os servidores em horários programados fora dos horários de pico, em vez de
dinamicamente durante faltas de cache.
YouTube
Com 300 horas de vídeo enviadas para o YouTube a cada minuto e vários bilhões de visualizações de vídeo por dia
[YouTube 2016], o YouTube é indiscutivelmente o maior site de compartilhamento de vídeos do mundo. YouTube começou sua
serviço em abril de 2005 e foi adquirido pelo Google em novembro de 2006. Embora o design e os protocolos do Google/
YouTube sejam proprietários, por meio de vários esforços de medição independentes, podemos obter uma
compreensão básica sobre como o YouTube funciona [Zink 2009; Torres 2011; Adhikari 2011a]. Assim como o Netflix, o
YouTube faz uso extensivo da tecnologia CDN para distribuir seus vídeos [Torres 2011]. Semelhante ao Netflix, o Google usa seu
próprio CDN privado para distribuir vídeos do YouTube e instalou clusters de servidores em centenas de locais diferentes
de IXP e ISP. A partir desses locais e diretamente de seus
enormes centros de dados, o Google distribui vídeos do YouTube [Adhikari 2011a]. Ao contrário do Netflix, no entanto, o
Google usa cache pull, conforme descrito na Seção 2.2.5, e redirecionamento de DNS, conforme descrito na Seção
2.6.3. Na maioria das vezes, a estratégia de seleção de cluster do Google direciona o cliente para o cluster para o qual o RTT
entre o cliente e o cluster é o mais baixo; no entanto, para equilibrar a carga entre os clusters,
às vezes o cliente é direcionado (via DNS) para um cluster mais distante [Torres 2011].
O YouTube emprega streaming HTTP, geralmente disponibilizando um pequeno número de versões diferentes para um vídeo,
cada uma com uma taxa de bits diferente e nível de qualidade correspondente. O YouTube não emprega streaming adaptável
(como DASH), mas exige que o usuário selecione manualmente uma versão. Para salvar
largura de banda e recursos do servidor que seriam desperdiçados pelo reposicionamento ou encerramento antecipado, o
YouTube usa a solicitação de intervalo de bytes HTTP para limitar o fluxo de dados transmitidos após a pré-busca de uma
quantidade alvo de vídeo.
Vários milhões de vídeos são carregados no YouTube todos os dias. Os vídeos do YouTube não são apenas transmitidos do
servidor para o cliente via HTTP, mas os uploaders do YouTube também enviam seus vídeos do cliente para o servidor via
HTTP. O YouTube processa cada vídeo que recebe, convertendo-o em um formato de vídeo do YouTube e criando várias versões
em diferentes taxas de bits. Esse processamento ocorre inteiramente nos datacenters do Google.
(Consulte o estudo de caso sobre a infraestrutura de rede do Google na Seção 2.6.3.)
cankan
Acabamos de ver que servidores dedicados, operados por CDNs privados, transmitem vídeos do Netflix e do YouTube para os
clientes. A Netflix e o YouTube precisam pagar não apenas pelo hardware do servidor, mas também pela largura de banda que os
servidores usam para distribuir os vídeos. Dada a escala desses serviços e a quantidade de largura de banda que eles consomem,
essa implantação de CDN pode ser cara.
Concluímos esta seção descrevendo uma abordagem totalmente diferente para o fornecimento de vídeo sob demanda pela
Internet em grande escala - uma abordagem que permite ao provedor de serviços reduzir significativamente sua
custos de infra-estrutura e largura de banda. Como você pode suspeitar, essa abordagem usa entrega P2P em vez de (ou junto
com) entrega cliente-servidor. Desde 2011, a Kankan (de propriedade e operada pela Xunlei) tem sido
implantando entrega de vídeo P2P com grande sucesso, com dezenas de milhões de usuários todos os meses [Zhang 2015].
Em um nível alto, o streaming de vídeo P2P é muito semelhante ao download de arquivos BitTorrent. Quando um colega quer
vê um vídeo, ele entra em contato com um rastreador para descobrir outros pares no sistema que possuem uma cópia desse vídeo.
Esse par solicitante solicita partes do vídeo em paralelo dos outros pares que possuem o vídeo. Diferente do download com
BitTorrent, no entanto, as solicitações são feitas preferencialmente por chunks
que serão reproduzidos em um futuro próximo para garantir a reprodução contínua [Dhungel 2012].
Recentemente, Kankan migrou para um sistema híbrido de streaming CDN-P2P [Zhang 2015]. Especificamente, Kankan agora
implanta algumas centenas de servidores na China e envia conteúdo de vídeo para esses servidores.
Este CDN Kankan desempenha um papel importante no estágio inicial de streaming de vídeo. Na maioria dos casos, o cliente
solicita o início do conteúdo dos servidores CDN e, em paralelo, solicita o conteúdo dos pares.
Quando o tráfego P2P total for suficiente para a reprodução de vídeo, o cliente interromperá o streaming do CDN e transmitirá apenas
dos pares. Mas se o tráfego de streaming P2P se tornar insuficiente, o cliente reiniciará as conexões CDN e retornará ao modo de
streaming CDN-P2P híbrido. Dessa maneira, Kankan pode garantir atrasos iniciais curtos enquanto depende minimamente de
servidores de infra-estrutura caros e largura de banda.

2.7 Programação de Socket: Criando Aplicações de Rede
Agora que examinamos vários aplicativos de rede importantes, vamos explorar como a rede
programas aplicativos são realmente criados. Lembre-se da Seção 2.1 de que uma aplicação de rede típica consiste em
um par de programas - um programa cliente e um programa servidor - residindo em dois sistemas finais diferentes. Quando
esses dois programas são executados, um processo cliente e um processo servidor são criados, e esses processos se
comunicam entre si lendo e gravando em soquetes. Ao criar um aplicativo de rede, a principal tarefa do desenvolvedor
é, portanto, escrever o código para os programas cliente e servidor.
Existem dois tipos de aplicativos de rede. Um tipo é uma implementação cuja operação é especificada em um padrão
de protocolo, como um RFC ou algum outro documento de padrões; às vezes, esse aplicativo é chamado de
“aberto”, pois as regras que especificam sua operação são conhecidas por todos.
Para tal implementação, os programas cliente e servidor devem estar em conformidade com as regras ditadas pelo RFC.
Por exemplo, o programa cliente pode ser uma implementação do lado cliente do HTTP
protocolo, descrito na Seção 2.2 e precisamente definido na RFC 2616; da mesma forma, o programa servidor pode ser
uma implementação do protocolo servidor HTTP, também definido com precisão no RFC 2616. Se um desenvolvedor
escrever código para o programa cliente e outro desenvolvedor escrever código para o programa servidor, e ambos os
desenvolvedores seguirem cuidadosamente as regras do RFC, então os dois programas poderão interoperar. De
fato, muitos dos aplicativos de rede atuais envolvem comunicação entre cliente e
programas de servidor que foram criados por desenvolvedores independentes, por exemplo, um Google Chrome
navegador se comunicando com um servidor Web Apache ou um cliente BitTorrent se comunicando com
Rastreador BitTorrent.
O outro tipo de aplicativo de rede é um aplicativo de rede proprietário. Neste caso, o cliente e
programas de servidor empregam um protocolo de camada de aplicativo que não foi publicado abertamente em um RFC ou
em outro lugar. Um único desenvolvedor (ou equipe de desenvolvimento) cria os programas cliente e servidor, e o
desenvolvedor tem controle total sobre o que acontece no código. Mas como o código não
implementar um protocolo aberto, outros desenvolvedores independentes não poderão desenvolver código que
interage com o aplicativo.
Nesta seção, examinaremos os principais problemas no desenvolvimento de um aplicativo cliente-servidor e "colocaremos a
mão na massa" examinando o código que implementa um aplicativo cliente-servidor muito simples. Durante a fase de
desenvolvimento, uma das primeiras decisões que o desenvolvedor deve tomar é se o aplicativo deve ser executado sobre
TCP ou UDP. Lembre-se de que o TCP é orientado à conexão e fornece um fluxo de bytes confiável
canal através do qual os dados fluem entre dois sistemas finais. O UDP não tem conexão e envia
pacotes de dados independentes de um sistema final para o outro, sem nenhuma garantia de entrega.
Lembre-se também de que, quando um programa cliente ou servidor implementa um protocolo definido por uma RFC, ele deve usar
o número de porta conhecido associado ao protocolo; por outro lado, ao desenvolver um aplicativo proprietário, o desenvolvedor
deve ter cuidado para evitar o uso de números de porta tão conhecidos. (números de porta
foram brevemente discutidos na Seção 2.1. Eles são abordados com mais detalhes no Capítulo 3.)
Apresentamos a programação de soquete UDP e TCP por meio de um aplicativo UDP simples e um aplicativo TCP simples.
Apresentamos os aplicativos UDP e TCP simples em Python 3. Poderíamos ter escrito o código em Java, C ou C++, mas
escolhemos Python principalmente porque Python expõe claramente os principais conceitos de soquete. Com Python, há menos
linhas de código e cada linha pode ser explicada sem dificuldade ao programador novato. Mas não há necessidade de se
assustar se você não estiver familiarizado com o Python.
Você deve ser capaz de seguir facilmente o código se tiver experiência em programação em Java, C ou C++.
Se você estiver interessado em programação cliente-servidor com Java, recomendamos que consulte o site complementar deste
livro; na verdade, você pode encontrar todos os exemplos desta seção (e laboratórios associados) em Java. Para os leitores
interessados em programação cliente-servidor em C, existem vários bons
referências disponíveis [Donahoo 2001; Stevens 1997; Frost 1994; Kurose 1996]; nossos exemplos de Python abaixo têm uma
aparência semelhante a C.
2.7.1 Programação de Socket com UDP
Nesta subseção, escreveremos programas cliente-servidor simples que usam UDP; na seção seguinte, escreveremos programas
semelhantes que usam TCP.
Lembre-se da Seção 2.1 de que os processos executados em máquinas diferentes se comunicam enviando mensagens para
soquetes. Dissemos que cada processo é análogo a uma casa e a tomada do processo é análoga a uma porta. O aplicativo fica
em um lado da porta da casa; o protocolo da camada de transporte reside do outro lado da porta no mundo externo. O
desenvolvedor do aplicativo tem controle de tudo no lado da camada de aplicativo do soquete; no entanto, ele tem pouco
controle do lado da camada de transporte.
Agora vamos dar uma olhada mais de perto na interação entre dois processos de comunicação que usam soquetes UDP.
Antes que o processo de envio possa empurrar um pacote de dados para fora da porta do soquete, ao usar o UDP, ele
deve primeiro anexar um endereço de destino ao pacote. Após o pacote passar pelo remetente
socket, a Internet usará este endereço de destino para rotear o pacote através da Internet para o socket no processo de
recebimento. Quando o pacote chega ao soquete de recebimento, o processo de recebimento recupera o pacote por meio do
soquete e, em seguida, inspeciona o conteúdo do pacote e toma as medidas apropriadas

Ação.
Então você pode estar se perguntando agora, o que vai para o endereço de destino que está anexado ao pacote?
Como você pode esperar, o endereço IP do host de destino faz parte do endereço de destino. Ao incluir o endereço IP de
destino no pacote, os roteadores na Internet poderão rotear o pacote pela Internet até o host de destino. Mas como
um host pode estar executando muitos processos de aplicativos de rede, cada um com um ou mais soquetes,
também é necessário identificar o
socket no host de destino. Quando um soquete é criado, um identificador, chamado número de porta, é atribuído a ele.
Portanto, como você pode esperar, o endereço de destino do pacote também inclui o número da porta do soquete.
Em resumo, o processo de envio anexa ao pacote um endereço de destino, que consiste no

o endereço IP do host de destino e o número da porta do soquete de destino. Além disso, como veremos em breve, o
endereço de origem do remetente — que consiste no endereço IP do host de origem e no número da porta do soquete de
origem — também está anexado ao pacote. No entanto, anexar o endereço de origem ao pacote é
normalmente não é feito pelo código do aplicativo UDP; em vez disso, é feito automaticamente pelo sistema
operacional subjacente.
Usaremos o seguinte aplicativo cliente-servidor simples para demonstrar a programação de soquete para ambos
UDP e TCP:
1. O cliente lê uma linha de caracteres (dados) de seu teclado e envia os dados para o servidor.
2. O servidor recebe os dados e converte os caracteres em maiúsculas.
3. O servidor envia os dados modificados para o cliente.
4. O cliente recebe os dados modificados e exibe a linha em sua tela.
A Figura 2.27 destaca a principal atividade relacionada ao soquete do cliente e do servidor que se comunicam pelo
serviço de transporte UDP.
Agora vamos colocar a mão na massa e dar uma olhada no par de programas cliente-servidor para uma implementação UDP
desta simples aplicação. Também fornecemos uma análise detalhada, linha por linha, após cada programa. Bem
comece com o cliente UDP, que enviará uma mensagem simples no nível do aplicativo para o servidor. a fim de
Figura 2.27 O aplicativo cliente-servidor usando UDP
o servidor para poder receber e responder a mensagem do cliente, ele deve estar pronto e funcionando, ou seja,
ele deve estar em execução como um processo antes que o cliente envie sua mensagem.
O programa cliente é chamado UDPClient.py e o programa servidor é chamado UDPServer.py. Para enfatizar os
principais problemas, fornecemos intencionalmente um código mínimo. “Bom código” certamente
tem mais algumas linhas auxiliares, em particular para lidar com casos de erro. Para esta aplicação, temos
escolhido arbitrariamente 12000 para o número da porta do servidor.
UDPClient.py
Aqui está o código para o lado do cliente do aplicativo:
da importação do soquete *
serverName = 'hostname'
serverPort = 12000
clienteSocket = socket(AF_INET, SOCK_DGRAM)
message = raw_input('Insira a frase em minúsculas:')

clientSocket.sendto(message.encode(),(serverName, serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
print(modifiedMessage.decode())
clienteSocket.close()
Agora vamos dar uma olhada nas várias linhas de código em UDPClient.py.
O módulo socket forma a base de todas as comunicações de rede em Python. Ao incluir esta linha, poderemos criar sockets
dentro do nosso programa.
serverName = 'hostname'
serverPort = 12000
A primeira linha define a variável serverName para a string 'hostname'. Aqui, fornecemos uma string contendo o
endereço IP do servidor (por exemplo, “128.138.32.126”) ou o nome do host do servidor
(por exemplo, “cis.poly.edu”). Se usarmos o nome do host, uma pesquisa de DNS será executada automaticamente para obter
o endereço IP.) A segunda linha define a variável inteira serverPort como 12000.
clienteSocket = socket(AF_INET, SOCK_DGRAM)
Essa linha cria o soquete do cliente, chamado clientSocket . O primeiro parâmetro indica o endereço
família; em particular, AF_INET indica que a rede subjacente está usando IPv4. (Não se preocupe com isso agora —
discutiremos o IPv4 no Capítulo 4.) O segundo parâmetro indica que o soquete é do tipo
SOCK_DGRAM , o que significa que é um soquete UDP (em vez de um soquete TCP). Observe que não somos
especificando o número da porta do soquete do cliente ao criá-lo; em vez disso, estamos deixando o sistema operacional
fazer isso por nós. Agora que a porta do processo do cliente foi criada, vamos querer criar uma
mensagem para enviar pela porta.
message = raw_input('Insira a frase em minúsculas:')

raw_input() é uma função interna em Python. Quando este comando é executado, o usuário no cliente recebe as palavras “Inserir
frase em minúsculas:” O usuário então usa seu teclado para inserir uma linha,
que é colocado na variável message . Agora que temos um soquete e uma mensagem, queremos enviar a mensagem por meio
do soquete para o host de destino.
clientSocket.sendto(message.encode(),(serverName, serverPort))
Na linha acima, primeiro convertemos a mensagem do tipo string para o tipo byte, pois precisamos enviar bytes
em uma tomada; isso é feito com o método encode() . O método sendto() anexa o destino
endereço ( serverName, serverPort ) para a mensagem e envia o pacote resultante para o
socket do processo, clientSocket . (Como mencionado anteriormente, o endereço de origem também é anexado ao pacote,
embora isso seja feito automaticamente, e não explicitamente pelo código.) Enviar uma mensagem de cliente para servidor por meio
de um soquete UDP é muito simples! Depois de enviar o pacote, o cliente espera receber os dados do
o servidor.
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
Com a linha acima, quando um pacote chega da Internet no soquete do cliente, os dados do pacote são
colocado na variável modifyMessage e o endereço de origem do pacote é colocado na variável
serverAddress . A variável serverAddress contém o endereço IP do servidor e o
número da porta do servidor. O programa UDPClient na verdade não precisa dessas informações de endereço do servidor, pois
já conhece o endereço do servidor desde o início; mas esta linha do Python fornece o servidor
endereço, no entanto. O método recvfrom também usa o tamanho do buffer 2048 como entrada. (Esse tamanho de buffer funciona
para a maioria das finalidades.)
print(modifiedMessage.decode())
Esta linha imprime modifyMessage na tela do usuário, depois de converter a mensagem de bytes em string. Deve ser a linha original
que o usuário digitou, mas agora em letras maiúsculas.
Esta linha fecha o soquete. O processo então termina.
UDPServer.py
Vamos agora dar uma olhada no lado do servidor do aplicativo:
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)

serverSocket.bind(('', serverPort))
print("O servidor está pronto para receber")

enquanto verdadeiro:
mensagem, clientAddress = serverSocket.recvfrom(2048)
Mensagemmodificada = message.decode().upper()
serverSocket.sendto(modifiedMessage.encode(), clientAddress)
Observe que o início do UDPServer é semelhante ao UDPClient. Também importa o módulo socket, também
define a variável inteira serverPort como 12000 e também cria um soquete do tipo SOCK_DGRAM (um soquete UDP). A primeira
linha de código significativamente diferente do UDPClient é:
A linha acima vincula (ou seja, atribui) o número da porta 12000 ao soquete do servidor. Assim em
UDPServer, o código (escrito pelo desenvolvedor do aplicativo) está atribuindo explicitamente um número de porta ao soquete.
Dessa forma, quando alguém enviar um pacote para a porta 12000 no endereço IP do servidor, esse
pacote será direcionado para este soquete. O UDPServer então entra em um loop while; o loop while permitirá que o
UDPServer receba e processe pacotes de clientes indefinidamente. No loop while, o UDPServer espera
para um pacote chegar.
mensagem, clientAddress = serverSocket.recvfrom(2048)
Essa linha de código é semelhante ao que vimos no UDPClient. Quando um pacote chega ao soquete do servidor,
os dados do pacote são colocados na mensagem variável e o endereço de origem do pacote é colocado no
variável clientAddress . A variável clientAddress contém o endereço IP do cliente e o
número da porta do cliente. Aqui, o UDPServer fará uso dessas informações de endereço, pois fornece um retorno
endereço, semelhante ao endereço de retorno com correio postal comum. Com essas informações de endereço de origem, o
servidor agora sabe para onde deve direcionar sua resposta.
Mensagemmodificada = message.decode().upper()
Esta linha é o coração da nossa aplicação simples. Pega a linha enviada pelo cliente e, após converter o
mensagem para uma string, usa o método upper() para capitalizá-la.
serverSocket.sendto(modifiedMessage.encode(), clientAddress)
Esta última linha anexa o endereço do cliente (endereço IP e número da porta) à mensagem em letras maiúsculas
(depois de converter a string em bytes) e envia o pacote resultante para o soquete do servidor. (Como mencionado
anteriormente, o endereço do servidor também é anexado ao pacote, embora isso seja feito automaticamente, e não explicitamente
pelo código.) A Internet então entregará o pacote a esse endereço de cliente. Depois
o servidor envia o pacote, ele permanece no loop while, aguardando a chegada de outro pacote UDP (de qualquer cliente em
execução em qualquer host).
Para testar o par de programas, execute UDPClient.py em um host e UDPServer.py em outro host. Certifique-se de incluir o nome de
host ou endereço IP apropriado do servidor em UDPClient.py. Em seguida, você executa UDPServer.py, o programa de servidor
compilado, no host do servidor. Isso cria um processo no servidor que fica ocioso até ser contatado por algum cliente. Então você
executa UDPClient.py, o cliente compilado
programa, no cliente. Isso cria um processo no cliente. Finalmente, para usar o aplicativo no cliente,
você digita uma frase seguida por um retorno de linha.
Para desenvolver seu próprio aplicativo cliente-servidor UDP, você pode começar modificando levemente os programas cliente
ou servidor. Por exemplo, em vez de converter todas as letras em maiúsculas, o servidor pode contar
o número de vezes que a letra s aparece e retorna esse número. Ou você pode modificar o cliente para que, após receber uma
frase em maiúscula, o usuário possa continuar enviando mais frases para o servidor.
2.7.2 Programação de Socket com TCP
Ao contrário do UDP, o TCP é um protocolo orientado à conexão. Isso significa que antes que o cliente e o servidor possam
começarem a enviar dados um para o outro, eles primeiro precisam fazer um aperto de mão e estabelecer uma conexão TCP. Um fim
da conexão TCP é conectada ao soquete do cliente e a outra extremidade é conectada a um soquete do servidor.
Ao criar a conexão TCP, associamos a ela o endereço do soquete do cliente (endereço IP e porta
número) e o endereço do soquete do servidor (endereço IP e número da porta). Com a conexão TCP estabelecida,
quando um lado deseja enviar dados para o outro lado, ele apenas coloca os dados na conexão TCP por meio de seu
soquete. Isso é diferente do UDP, para o qual o servidor deve anexar um endereço de destino ao pacote antes de colocá-
lo no soquete.
Agora vamos dar uma olhada mais de perto na interação dos programas cliente e servidor no TCP. O cliente tem a função
de iniciar o contato com o servidor. Para que o servidor possa reagir ao contato inicial do cliente, o servidor deve estar
pronto. Isso implica duas coisas. Primeiro, como no caso do UDP, o servidor TCP
deve estar em execução como um processo antes que o cliente tente iniciar o contato. Em segundo lugar, o programa servidor
deve ter uma porta especial - mais precisamente, um soquete especial - que receba algum contato inicial de um
processo do cliente em execução em um host arbitrário. Usando nossa analogia de casa/porta para um processo/tomada, às
vezes nos referiremos ao contato inicial do cliente como “bater na porta acolhedora”.
Com o processo do servidor em execução, o processo do cliente pode iniciar uma conexão TCP com o servidor. Isso é feito
no programa cliente criando um soquete TCP. Quando o cliente cria seu soquete TCP, ele especifica o endereço do soquete
de boas-vindas no servidor, ou seja, o endereço IP do host do servidor e o número da porta do soquete. Depois de criar
seu soquete, o cliente inicia um handshake de três vias e
estabelece uma conexão TCP com o servidor. O handshake triplo, que ocorre dentro da camada de transporte, é
completamente invisível para os programas cliente e servidor.
Durante o handshake triplo, o processo do cliente bate na porta de boas-vindas do servidor
processo. Quando o servidor “ouve” a batida, ele cria uma nova porta – mais precisamente, um novo soquete dedicado a
esse cliente específico. Em nosso exemplo abaixo, a porta de boas-vindas é um soquete TCP
objeto que chamamos de serverSocket ; o soquete recém-criado dedicado ao cliente fazendo o
conexão é chamada connectionSocket . Os alunos que estão encontrando soquetes TCP pela primeira vez às vezes
confundem o soquete de boas-vindas (que é o ponto de contato inicial para todos os clientes que desejam se comunicar com
o servidor) e cada soquete de conexão do lado do servidor recém-criado que é posteriormente criado para se
comunicar com cada cliente.
Do ponto de vista do aplicativo, o soquete do cliente e o soquete de conexão do servidor são diretamente
conectados por um tubo. Conforme mostrado na Figura 2.28, o processo cliente pode enviar bytes arbitrários para seu
soquete, e o TCP garante que o processo servidor receberá (através do soquete de conexão) cada
byte na ordem enviada. O TCP, portanto, fornece um serviço confiável entre os processos do cliente e do servidor.
Além disso, assim como as pessoas podem entrar e sair pela mesma porta, o processo cliente não apenas envia bytes
para dentro, mas também recebe bytes de seu soquete; da mesma forma, o processo do servidor não apenas recebe bytes de, mas
também envia bytes para seu soquete de conexão.
Usamos o mesmo aplicativo cliente-servidor simples para demonstrar a programação de soquete com TCP: o cliente envia
uma linha de dados ao servidor, o servidor coloca a linha em maiúscula e a envia de volta ao cliente.
A Figura 2.29 destaca a principal atividade relacionada ao soquete do cliente e do servidor que se comunicam
o serviço de transporte TCP.
Figura 2.28 O processo TCPServer tem dois soquetes
TCPClient.py
Aqui está o código para o lado do cliente do aplicativo:
serverName = 'servidor'
serverPort = 12000
clienteSocket = socket(AF_INET, SOCK_STREAM)

clientSocket.connect((serverName, serverPort))
frase = raw_input('Inserir frase minúscula:')

clientSocket.send(sentence.encode())
Sentença modificada = clientSocket.recv(1024)
print('Do Servidor: ',modifiedSentence.decode())
Vamos agora dar uma olhada nas várias linhas do código que diferem significativamente da
implementação do UDP. A primeira dessas linhas é a criação do soquete do cliente.
clienteSocket = socket(AF_INET, SOCK_STREAM)
Essa linha cria o soquete do cliente, chamado clientSocket . O primeiro parâmetro novamente indica que a rede subjacente está
usando IPv4. O segundo parâmetro
Figura 2.29 A aplicação cliente-servidor usando TCP
indica que o soquete é do tipo SOCK_STREAM , o que significa que é um soquete TCP (em vez de um soquete UDP). Observe
que, novamente, não especificamos o número da porta do soquete do cliente ao criá-lo; em vez disso, estamos deixando o sistema
operacional fazer isso por nós. Agora, a próxima linha de código é muito diferente de
o que vimos no UDPClient:
clientSocket.connect((serverName, serverPort))
Lembre-se que antes que o cliente possa enviar dados para o servidor (ou vice-versa) usando um soquete TCP, um TCP
conexão deve primeiro ser estabelecida entre o cliente e o servidor. A linha acima inicia o TCP
conexão entre o cliente e o servidor. O parâmetro do método connect() é o endereço do lado do servidor da conexão. Depois que
essa linha de código é executada, o handshake de três vias é executado e uma conexão TCP é estabelecida entre o
cliente e o servidor.
frase = raw_input('Inserir frase minúscula:')
Assim como com UDPClient, o acima obtém uma frase do usuário. A frase de string continua a reunir caracteres até que o
usuário termine a linha digitando um retorno de carro. A próxima linha de código também é muito diferente de UDPClient:
clientSocket.send(sentence.encode())
A linha acima envia a sentença através do soquete do cliente para a conexão TCP. Observe que
o programa não cria explicitamente um pacote e anexa o endereço de destino ao pacote, como era o caso dos soquetes UDP. Em
vez disso, o programa cliente simplesmente descarta os bytes na frase da string na conexão TCP. O cliente então espera receber
bytes do servidor.
Sentença modificada = clientSocket.recv(2048)
Quando os personagens chegam do servidor, eles são colocados na string modifySentence .
Os caracteres continuam a se acumular em modifySentence até que a linha termine com um caractere de retorno de linha.
Depois de imprimir a frase em maiúscula, fechamos o soquete do cliente:
Esta última linha fecha o soquete e, portanto, fecha a conexão TCP entre o cliente e o
servidor. Ele faz com que o TCP no cliente envie uma mensagem TCP para o TCP no servidor (consulte a Seção 3.5).
TCPServer.py
Agora vamos dar uma olhada no programa do servidor.
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)

serverSocket.listen(1)
print('O servidor está pronto para receber')

enquanto verdadeiro:
connectionSocket, addr = serverSocket.accept()
frase = connectionSocket.recv(1024).decode()
Sentença maiúscula = frase.upper()
connectionSocket.send(capitalizedSentence.encode())
connectionSocket.close()
Vamos agora dar uma olhada nas linhas que diferem significativamente de UDPServer e TCPClient. Assim
como no TCPClient, o servidor cria um soquete TCP com:
serverSocket=socket(AF_INET, SOCK_STREAM)
Semelhante ao UDPServer, associamos o número da porta do servidor, serverPort , com esta tomada:
Mas com TCP, serverSocket será nosso soquete de boas-vindas. Depois de estabelecer esta porta acolhedora,
vai esperar e ouvir algum cliente bater na porta:
serverSocket.listen(1)
Essa linha faz com que o servidor ouça as solicitações de conexão TCP do cliente. O parâmetro especifica o
número máximo de conexões em fila (pelo menos 1).

connectionSocket, addr = serverSocket.accept()
Quando um cliente bate nessa porta, o programa invoca o método accept() para serverSocket, que
cria um novo soquete no servidor, chamado connectionSocket , dedicado a este cliente em particular.
O cliente e o servidor então completam o handshaking, criando uma conexão TCP entre o cliente
clientSocket e o connectionSocket do servidor . Com a conexão TCP estabelecida, o cliente e o servidor agora podem
enviar bytes um ao outro pela conexão. Com o TCP, todos os bytes enviados de um lado não são apenas garantidos para
chegar ao outro lado, mas também garantidos para chegar em ordem.
connectionSocket.close()
Neste programa, após enviar a frase modificada para o cliente, fechamos o socket de conexão. Mas
como serverSocket permanece aberto, outro cliente pode agora bater na porta e enviar ao servidor uma frase para modificar.
Isso completa nossa discussão sobre a programação de soquetes no TCP. Você é encorajado a executar os dois
programas em dois hosts separados e também modificá-los para atingir objetivos ligeiramente diferentes. Você deve comparar
o par de programas UDP com o par de programas TCP e ver como eles diferem. Você também deve fazer
muitas das atribuições de programação de soquetes descritas no final dos Capítulos 2, 4 e 9. Finalmente, esperamos que
algum dia, depois de dominar esses e outros programas de soquete mais avançados, você escreva seu próprio aplicativo
de rede popular, torne-se muito rico e famoso e lembre-se dos autores deste livro!
2.8 Resumo
Neste capítulo, estudamos os aspectos conceituais e de implementação de aplicativos de rede.

Aprendemos sobre a arquitetura cliente-servidor onipresente adotada por muitos aplicativos da Internet e vimos seu uso nos
protocolos HTTP, SMTP, POP3 e DNS. Estudamos essas importantes aplicações
protocolos de nível e seus aplicativos associados correspondentes (Web, transferência de arquivos, e-mail e DNS) com
algum detalhe. Aprendemos sobre a arquitetura P2P e como ela é usada em muitos aplicativos.
Também aprendemos sobre streaming de vídeo e como os sistemas modernos de distribuição de vídeo utilizam CDNs.
Examinamos como a API de soquete pode ser usada para criar aplicativos de rede. Examinamos o uso de soquetes para
serviços de transporte ponta a ponta orientados a conexão (TCP) e sem conexão (UDP). A primeira etapa em nossa
jornada pela arquitetura de rede em camadas agora está concluída!
Bem no início deste livro, na Seção 1.1, demos uma definição bastante vaga e básica de um protocolo: “o formato e a
ordem das mensagens trocadas entre duas ou mais entidades comunicantes, bem como as ações tomadas na
transmissão e/ou recebimento de uma mensagem ou outro evento”.
O material deste capítulo e, em particular, nosso estudo detalhado sobre HTTP, SMTP, POP3 e DNS
protocolos, agora adicionou substância considerável a esta definição. Os protocolos são um conceito-chave em rede;
nosso estudo de protocolos de aplicação agora nos deu a oportunidade de desenvolver uma sensação mais intuitiva
sobre o que são os protocolos.
Na Seção 2.1, descrevemos os modelos de serviço que o TCP e o UDP oferecem às aplicações que os invocam.
Demos uma olhada ainda mais detalhada nesses modelos de serviço quando desenvolvemos aplicativos simples que
executado sobre TCP e UDP na Seção 2.7. No entanto, falamos pouco sobre como o TCP e o UDP fornecem esses
modelos de serviço. Por exemplo, sabemos que o TCP fornece um serviço de dados confiável, mas não
disse ainda como o faz. No próximo capítulo, examinaremos cuidadosamente não apenas o quê, mas também o como
e o porquê dos protocolos de transporte.
Equipados com conhecimento sobre a estrutura de aplicativos da Internet e protocolos de nível de aplicativo, agora estamos
pronto para seguir adiante na pilha de protocolos e examinar a camada de transporte no Capítulo 3.
Problemas e perguntas sobre o dever de casa
Perguntas de Revisão do Capítulo 2
SEÇÃO 2.1
R1. Liste cinco aplicativos de Internet não proprietários e os protocolos de camada de aplicativo que eles
usar.
R2. Qual é a diferença entre arquitetura de rede e arquitetura de aplicativo?
R3. Para uma sessão de comunicação entre um par de processos, qual processo é o cliente e qual é o servidor?
R4. Para um aplicativo de compartilhamento de arquivos P2P, você concorda com a afirmação: “Não há noção dos
lados cliente e servidor de uma sessão de comunicação”? Por que ou por que não?
R5. Quais informações são usadas por um processo em execução em um host para identificar um processo em
execução em outro host?
R6. Suponha que você queira fazer uma transação de um cliente remoto para um servidor o mais rápido possível.
Você usaria UDP ou TCP? Por que?
R7. Referindo-se à Figura 2.4 , , vemos que nenhum dos aplicativos listados na Figura 2.4 requer
sem perda de dados e tempo. Você pode conceber um aplicativo que não exija perda de dados e
que também é altamente sensível ao tempo?
R8. Liste as quatro amplas classes de serviços que um protocolo de transporte pode fornecer. Para cada uma das
classes de serviço, indique se UDP ou TCP (ou ambos) fornecem tal serviço.
R9. Lembre-se de que o TCP pode ser aprimorado com SSL para fornecer serviços de segurança processo a processo,
incluindo criptografia. O SSL opera na camada de transporte ou na camada de aplicativo? Se o desenvolvedor do
aplicativo deseja que o TCP seja aprimorado com SSL, o que o desenvolvedor precisa fazer?
fazer?
SEÇÃO 2.2–2.5
R10. O que significa um protocolo de handshaking?
R11. Por que HTTP, SMTP e POP3 são executados sobre TCP em vez de UDP?
R12. Considere um site de comércio eletrônico que deseja manter um registro de compra para cada um de
seus clientes. Descreva como isso pode ser feito com cookies.
R13. Descreva como o cache da Web pode reduzir o atraso no recebimento de um objeto solicitado. O cache da Web
reduzirá o atraso para todos os objetos solicitados por um usuário ou apenas para alguns dos objetos?
Por que?
R14. Telnet em um servidor Web e envie uma mensagem de solicitação de várias linhas. Inclua na mensagem de
solicitação a linha de cabeçalho If-modified-since: para forçar uma mensagem de resposta com o 304
Código de status não modificado .
R15. Liste vários aplicativos de mensagens populares. Eles usam os mesmos protocolos do SMS?
R16. Suponha que Alice, com uma conta de e-mail baseada na Web (como Hotmail ou Gmail), envie uma mensagem
para Bob, que acessa seu e-mail de seu servidor de e-mail usando POP3. Discuta como a mensagem vai do host de
Alice para o host de Bob. Certifique-se de listar a série de protocolos da camada de aplicação usados para mover a
mensagem entre os dois hosts.
R17. Imprima o cabeçalho de uma mensagem de e-mail que você recebeu recentemente. Quantas linhas de
cabeçalho Received: existem? Analise cada uma das linhas de cabeçalho da mensagem.
R18. Do ponto de vista do usuário, qual é a diferença entre o modo baixar e excluir e o modo baixar e manter no POP3?
R19. É possível que o servidor Web e o servidor de correio de uma organização tenham exatamente o mesmo alias para
um nome de host (por exemplo, foo.com )? Qual seria o tipo para o RR que contém
o nome do host do servidor de correio?
R20. Examine seus e-mails recebidos e examine o cabeçalho de uma mensagem enviada por um usuário com endereço
de e-mail .edu. É possível determinar a partir do cabeçalho o endereço IP do host de onde a mensagem foi enviada? Faça o
mesmo para uma mensagem enviada de uma conta do Gmail.
SEÇÃO 2.5
R21. No BitTorrent, suponha que Alice forneça blocos para Bob em um intervalo de 30 segundos. Bob necessariamente
retribuirá o favor e fornecerá pedaços para Alice neste mesmo intervalo? Por que ou por que
não?
R22. Considere um novo par Alice que ingressa no BitTorrent sem possuir nenhum chunk. Sem quaisquer pedaços, ela
não pode se tornar uma das quatro principais uploaders para nenhum dos outros pares, já que ela não tem nada para
fazer upload. Como então Alice conseguirá seu primeiro pedaço?
R23. O que é uma rede overlay? Inclui roteadores? Quais são as arestas na rede de sobreposição?
SEÇÃO 2.6
R24. Os CDNs geralmente adotam uma das duas filosofias de posicionamento de servidor diferentes. Cite-os e descreva-os
brevemente.
R25. Além das considerações relacionadas à rede, como atraso, perda e desempenho da largura de banda, há outros
fatores importantes que envolvem o projeto de uma estratégia de seleção de servidor CDN. O que
são eles?
SEÇÃO 2.7
R26. Na Seção 2.7, o servidor UDP descrito precisava de apenas um soquete, enquanto o servidor TCP precisava de dois
soquetes. Por que? Se o servidor TCP suportasse n conexões simultâneas, cada uma de um host cliente diferente, de
quantos soquetes o servidor TCP precisaria?
R27. Para a aplicação cliente-servidor sobre TCP descrita na Seção 2.7 , por que o programa servidor deve ser executado
antes do programa cliente? Para a aplicação cliente-servidor sobre UDP, por que o programa cliente pode ser executado
antes do programa servidor?
problemas
P1. Verdadeiro ou falso?
a. Um usuário solicita uma página da Web que consiste em algum texto e três imagens. Para esta página, o cliente
enviará uma mensagem de solicitação e receberá quatro mensagens de resposta.
b. Duas páginas Web distintas (por exemplo, www.mit.edu/ research.html e
www.mit.edu/ students.html ) podem ser enviados pela mesma conexão persistente.
c. Com conexões não persistentes entre o navegador e o servidor de origem, é possível que um
único segmento TCP para transportar duas mensagens de requisição HTTP distintas.
d. O cabeçalho Date: na mensagem de resposta HTTP indica quando o objeto na
a resposta foi modificada pela última vez.
e. As mensagens de resposta HTTP nunca têm um corpo de mensagem vazio.
P2. SMS, iMessage e WhatsApp são sistemas de mensagens em tempo real para smartphones. Depois de fazer
alguma pesquisa na Internet, para cada um desses sistemas, escreva um parágrafo sobre os protocolos que eles usam.
Em seguida, escreva um parágrafo explicando como eles diferem.
P3. Considere um cliente HTTP que deseja recuperar um documento da Web em uma determinada URL. O endereço
IP do servidor HTTP é inicialmente desconhecido. Quais protocolos de camada de transporte e aplicação
além de HTTP são necessários neste cenário?
P4. Considere a seguinte sequência de caracteres ASCII que foram capturados pelo Wireshark quando o navegador
enviou uma mensagem HTTP GET (ou seja, este é o conteúdo real de uma mensagem HTTP GET).
Os caracteres <cr><lf> são caracteres de retorno de carro e alimentação de linha (ou seja, o caractere em itálico
a cadeia de caracteres <cr> no texto abaixo representa o único caractere de retorno de linha que estava contido naquele
ponto no cabeçalho HTTP). Responda às seguintes perguntas, indicando em que
a mensagem HTTP GET abaixo você encontra a resposta.
GET / cs453/ index.html HTTP/ 1.1<cr><lf>Host: gai
a.cs.umass.edu<cr><lf>User-Agent: Mozilla/ 5.0 (
Janelas;U; Windows NT 5.1; en-US; rv:1.7.2) Gec
ko/ 20040804 Netscape/ 7.2 (ax) <cr><lf>Aceitar:ex

t/ xml, aplicativo/ xml, aplicativo/ xhtml+xml, texto

/ html;q=0.9, texto/ simples;q=0.8, imagem/ png,*/ *;q=0.5
<cr><lf>Aceitar-Idioma: en-us, en;q=0.5<cr><lf>Aceitar
Codificação: zip, deflate<cr><lf>Aceitar-Charset: ISO
-8859-1, utf-8;q=0.7,*;q=0.7<cr><lf>Keep-Alive: 300<cr>
<lf>Conexão:keep-alive<cr><lf><cr><lf>
a. Qual é a URL do documento solicitado pelo navegador? b. Qual versão

do HTTP o navegador está executando?
c. O navegador solicita uma conexão não persistente ou persistente? d. Qual é o
endereço IP do host no qual o navegador está sendo executado? e. Que tipo de
navegador inicia esta mensagem? Por que o tipo de navegador é necessário em uma mensagem de
solicitação HTTP?
P5. O texto abaixo mostra a resposta enviada do servidor em resposta à mensagem HTTP GET na pergunta
acima. Responda às seguintes perguntas, indicando onde na mensagem abaixo
você encontra a resposta.
HTTP/ 1.1 200 OK<cr><lf>Data: terça, 07 de março de 2008

12:39:45GMT<cr><lf>Servidor: Apache/ 2.0.52 (Fedora)
<cr><lf>Última modificação: sábado, 10 de dezembro de 2005 18:27:46
GMT<cr><lf>ETag: ”526c3-f22-a88a4c80”<cr><lf>Aceitar
Intervalos: bytes<cr><lf>Comprimento do conteúdo: 3874<cr><lf>
Keep-Alive: timeout=max=100<cr><lf>Conexão:
Keep-Alive<cr><lf>Tipo de conteúdo: text/ html; conjunto de caracteres =
ISO-8859-1<cr><lf><cr><lf><!doctype html public ”-
// w3c// dtd html 4.0 transitório// en”><lf><html><lf>
<head><lf> <meta http-equiv=”Tipo de conteúdo”

conteúdo=”texto/ html; charset=iso-8859-1”><lf> <meta
name=”GENERATOR” content=”Mozilla/ 4.79 [en] (Windows NT
5,0; U) Netscape]”><lf> <title>CMPSCI 453 / 591 /

Página inicial do NTU-ST550AS, primavera de 2005</ title><lf></ head><lf>
<muito mais texto de documento seguindo aqui (não mostrado)>
a. O servidor conseguiu encontrar o documento com sucesso ou não? Que horas era o
resposta do documento fornecida?
b. Quando o documento foi modificado pela última vez?
c. Quantos bytes existem no documento que está sendo retornado? d.

Quais são os primeiros 5 bytes do documento que está sendo retornado? O servidor concordou com um
conexão persistente?
P6. Obtenha a especificação HTTP/1.1 (RFC 2616). Responda as seguintes questões:
a. Explique o mecanismo usado para sinalizar entre o cliente e o servidor para indicar que uma conexão persistente
está sendo fechada. O cliente, o servidor ou ambos podem sinalizar o fechamento
de uma conexão?
b. Quais serviços de criptografia são fornecidos pelo HTTP?
c. Um cliente pode abrir três ou mais conexões simultâneas com um determinado servidor? d. Tanto um
servidor quanto um cliente podem fechar uma conexão de transporte entre eles se um deles detectar que a
conexão está inativa por algum tempo. É possível que um lado comece a fechar uma conexão enquanto o
outro lado está transmitindo dados através desta conexão?
Explicar.
P7. Suponha que em seu navegador da Web você clique em um link para obter uma página da Web. O endereço IP do
URL associado não é armazenado em cache em seu host local, portanto, uma pesquisa de DNS é necessária para obter
o endereço IP. Suponha que n servidores DNS sejam visitados antes que seu host receba o endereço IP do DNS; as
visitas sucessivas incorrem em um RTT de RTT1,. . .,RTTn. Suponha ainda que a página da Web
associada ao link contenha exatamente um objeto, consistindo em uma pequena quantidade de HTML
texto. Deixe RTT0denotar o RTT entre o host local e o servidor que contém o objeto.
Supondo que o tempo de transmissão do objeto seja zero, quanto tempo decorre desde que o cliente
clica no link até que o cliente receba o objeto?
P8. Referindo-se ao Problema P7, suponha que o arquivo HTML faça referência a oito objetos muito pequenos no
mesmo servidor. Desprezando os tempos de transmissão, quanto tempo decorre com
a. HTTP não persistente sem conexões TCP paralelas? b. HTTP não
persistente com o navegador configurado para 5 conexões paralelas?

c. HTTP persistente?
P9. Considere a Figura 2.12 , para os quais existe uma rede institucional conectada à Internet.
Suponha que o tamanho médio do objeto seja de 850.000 bits e que a taxa média de requisição dos navegadores da
instituição para os servidores de origem seja de 16 requisições por segundo. Suponha também que o
quantidade de tempo que leva desde que o roteador no lado da Internet do link de acesso encaminha um
A solicitação HTTP até receber a resposta é de três segundos em média (consulte a Seção 2.2.5).
Modele o tempo médio total de resposta como a soma do atraso médio de acesso (ou seja, o atraso do roteador da
Internet para o roteador da instituição) e o atraso médio da Internet. Para o acesso médio
atraso, use ÿ/(1ÿÿÿ), onde ÿ é o tempo médio necessário para enviar um objeto pelo link de acesso e b é a taxa de
chegada de objetos ao link de acesso.
a. Encontre o tempo médio total de resposta. b.
Agora suponha que um cache esteja instalado na LAN institucional. Suponha que a taxa de falha seja 0,4.
Encontre o tempo total de resposta.
P10. Considere um enlace curto de 10 metros, pelo qual um transmissor pode transmitir a uma taxa de 150 bits/s em
ambas as direções. Suponha que os pacotes contendo dados tenham 100.000 bits de comprimento e os pacotes
contendo apenas controle (por exemplo, ACK ou handshaking) têm 200 bits de comprimento. Suponha que N
conexões paralelas obtenham 1/N da largura de banda do link. Agora considere o protocolo HTTP e suponha que
cada objeto baixado tenha 100 Kbits de comprimento e que o objeto baixado inicial contenha 10
objetos referenciados do mesmo remetente. Os downloads paralelos por meio de instâncias paralelas de HTTP
não persistente fariam sentido nesse caso? Agora considere o HTTP persistente. Você espera ganhos significativos
sobre o caso não persistente? Justifique e explique sua resposta.
P11. Considere o cenário apresentado no problema anterior. Agora suponha que o link seja compartilhado por
Bob com quatro outros usuários. Bob usa instâncias paralelas de HTTP não persistente e os outros quatro usuários
usam HTTP não persistente sem downloads paralelos.
a. As conexões paralelas de Bob o ajudam a obter páginas da Web mais rapidamente? Por que ou por que
não? b. Se todos os cinco usuários abrirem cinco instâncias paralelas de HTTP não persistente, as conexões
paralelas de Bob ainda seriam benéficas? Por que ou por que não?
P12. Escreva um programa TCP simples para um servidor que aceite linhas de entrada de um cliente e imprima as
linhas na saída padrão do servidor. (Você pode fazer isso modificando o programa TCPServer.py no texto.)
Compile e execute seu programa. Em qualquer outra máquina que contenha um
Navegador da Web, defina o servidor proxy no navegador para o host que está executando seu servidor
programa; também configure o número da porta apropriadamente. Seu navegador agora deve enviar suas mensagens
de solicitação GET para seu servidor, e seu servidor deve exibir as mensagens em sua saída padrão. Use esta
plataforma para determinar se seu navegador gera mensagens GET condicionais para objetos armazenados
em cache localmente.
P13. Qual é a diferença entre MAIL FROM : em SMTP e From : na mensagem de correio
em si?
P14. Como o SMTP marca o fim do corpo de uma mensagem? Que tal HTTP? O HTTP pode usar o mesmo método
que o SMTP para marcar o final do corpo de uma mensagem? Explicar.
P15. Leia RFC 5321 para SMTP. O que significa MTA? Considere o seguinte e-mail de spam recebido (modificado
de um e-mail de spam real). Presumindo apenas o originador deste e-mail de spam
é malicioso e todos os outros hosts são honestos, identifique o host mal-intencionado que gerou isso
e-mail de spam.
De - Sex Nov 07 13:41:30 2008
Caminho de Retorno: <tennis5@pp33head.com>

Recebido: de barmail.cs.umass.edu (barmail.cs.umass.edu
[128.119.240.3]) por cs.umass.edu (8.13.1/8.12.6) para
<hg@cs.umass.edu>; Sex, 7 de novembro de 2008 13:27:10 -0500
Recebido: de asusus-4b96 (localhost [127.0.0.1]) por
barmail.cs.umass.edu (Spam Firewall) para <hg@cs.umass.edu>; sexta, 7

Nov 2008 13:27:07 -0500 (EST)
Recebido: de asusus-4b96 ([58.88.21.177]) por barmail.cs.umass.edu
para <hg@cs.umass.edu>; Sex, 07 de novembro de 2008 13:27:07 -0500 (EST)

Recebido: de [58.88.21.177] por inbnd55.exchangeddd.com; sáb, 8
Nov 2008 01:27:07 +0700
De: ”Jonny” <tennis5@pp33head.com>
Para: <hg@cs.umass.edu>
Assunto: Como proteger suas economias
P16. Leia o POP3 RFC, RFC 1939. Qual é a finalidade do comando UIDL POP3?
P17. Considere acessar seu e-mail com POP3.

a. Suponha que você tenha configurado seu cliente de e-mail POP para operar no download-and-
modo de exclusão. Conclua a seguinte transação:
C: lista
S: 1 498
S: 2 912
S: .
C: retr 1
S: blá blá...
S: .......... blá
S: .
b. Suponha que você tenha configurado seu cliente de e-mail POP para operar no modo
download-and-keep. Conclua a seguinte transação:
C: lista
S: 1 498
S: 2 912
S: .
C: retr 1
S: blá blá...
S: .......... blá
S: .
?
c. Suponha que você tenha configurado seu cliente de e-mail POP para operar no modo download-and-keep. Usando sua
transcrição na parte (b), suponha que você recupere as mensagens 1 e 2, saia do POP e, cinco minutos depois,
acesse novamente o POP para recuperar novos e-mails. Suponha que no intervalo de cinco minutos nenhuma nova
mensagem tenha sido enviada para você. Forneça uma transcrição desta segunda sessão POP.
P18.
a. O que é um banco de dados whois ?
b. Use vários bancos de dados whois na Internet para obter os nomes de dois servidores DNS.
Indique quais bancos de dados whois você usou.
c. Use nslookup em seu host local para enviar consultas DNS para três servidores DNS: seu local
servidor DNS e os dois servidores DNS encontrados na parte (b). Tente consultar os relatórios Tipo A, NS e MX. Resuma
suas descobertas.
d. Use nslookup para encontrar um servidor Web que tenha vários endereços IP. O servidor Web
da sua instituição (escola ou empresa) tem vários endereços IP?
e. Use o banco de dados ARIN whois para determinar o intervalo de endereços IP usado por seu
universidade.
f. Descrever como um invasor pode usar bancos de dados whois e a ferramenta nslookup para executar
reconhecimento de uma instituição antes de lançar um ataque.
g. Discuta por que os bancos de dados whois devem estar disponíveis publicamente.
P19. Neste problema, usamos a útil ferramenta dig disponível em hosts Unix e Linux para explorar a hierarquia dos servidores
DNS. Lembre-se de que na Figura 2.19 delega uma consulta DNS a , um servidor DNS na hierarquia DNS
um servidor DNS inferior na hierarquia, enviando de volta ao DNS
cliente o nome desse servidor DNS de nível inferior. Primeiro, leia a página do manual para dig e, em seguida, responda às
seguintes perguntas.
a. Começando com um servidor DNS raiz (de um dos servidores raiz [am].root-servers.net),
inicie uma sequência de consultas para o endereço IP do servidor Web do seu departamento,
usando dig. Mostre a lista de nomes de servidores DNS na cadeia de delegação em resposta à sua
consulta.
b. Repita a parte (a) para vários sites populares, como google.com, yahoo.com ou
amazon. com.
P20. Suponha que você possa acessar os caches nos servidores DNS locais do seu departamento. Você pode propor uma maneira
de determinar aproximadamente os servidores da Web (fora do seu departamento) que são mais populares entre os usuários
do seu departamento? Explicar.
P21. Suponha que seu departamento tenha um servidor DNS local para todos os computadores do departamento.
Você é um usuário comum (ou seja, não é um administrador de rede/sistema). Você pode determinar se um site
externo provavelmente foi acessado de um computador em seu departamento alguns segundos atrás? Explicar.
P22. Considere distribuir um arquivo de GbitsF=15

para N pares. O servidor tem uma taxa de upload de us = 30 di = 2
Mbps, e cada par
upload detem uma N=10,
u. Para taxa de100
download
e 1.000de Mbps eKbps,
e u=300 uma 700
taxaKbps
de e 2 Mbps, prepare um gráfico com as
tempo mínimo de distribuição para cada uma das combinações de N e u para ambos cliente-servidor
distribuição e distribuição P2P.
P23. Considere distribuir um arquivo de F bits para N pares usando uma arquitetura cliente-servidor. Assuma um modelo
fluido onde o servidor pode transmitir simultaneamente para vários pares, transmitindo para cada
peer em taxas diferentes, desde que a taxa combinada não exceda u . s
us/Nÿdmin.
Suponha que Especifique a.
um esquema de distribuição que tenha um tempo de distribuição de
NF/u . s
Suponha que us/Nÿdmin. b. Especifique um esquema de distribuição que tenha um tempo de distribuição de
F/d .min
Conclua que o tempo mínimo de distribuição é geralmente dado por max{NF/us, F/dmin}. c.
P24. Considere distribuir um arquivo de F bits para N pares usando uma arquitetura P2P. Assuma um modelo fluido. Para
simplificar, suponha que dmin seja muito grande, de modo que a largura de banda de download de pares nunca seja um problema.
gargalo.
usÿ(us+u1+…+uN)/N.
Suponha que Especifique a.
um esquema de distribuição que tenha uma distribuição
tempo de F/u s.
usÿ(us+u1+…+uN)/N.
Suponha que Especifique b.
um esquema de distribuição que tenha um tempo de distribuição de NF/(us+u1+…+uN).
c. Conclua que o tempo mínimo de distribuição é geralmente dado por max{F/us, NF/
(us+u1+…+uN)}.
P25. Considere uma rede overlay com N peers ativos, com cada par de peers tendo um ativo
conexão TCP. Além disso, suponha que as conexões TCP passem por um total de M roteadores. Quantos nós e
arestas existem na rede de sobreposição correspondente?
P26. Suponha que Bob ingresse em um torrent BitTorrent, mas ele não deseja enviar nenhum dado para nenhum
outro peer (o chamado free-riding).
a. Bob afirma que pode receber uma cópia completa do arquivo compartilhado pelo enxame. A afirmação de Bob é
possível? Por que ou por que não?
b. Bob afirma ainda que pode tornar seu “carona” mais eficiente usando uma coleção de vários computadores
(com endereços IP distintos) no laboratório de informática de seu departamento. Como ele consegue fazer
isso?
P27. Considere um sistema DASH para o qual existem N versões de vídeo (em N taxas e qualidades diferentes) e N
versões de áudio (em N taxas e qualidades diferentes). Suponha que queremos permitir que o
jogador para escolher a qualquer momento qualquer uma das versões de vídeo N e qualquer uma das versões de áudio N.
a. Se criarmos arquivos para que o áudio seja mixado com o vídeo, então o servidor envia apenas um
fluxo de mídia em determinado momento, quantos arquivos o servidor precisará armazenar (cada um com uma URL
diferente)?
b. Se, em vez disso, o servidor enviar os fluxos de áudio e vídeo separadamente e tiver o cliente
sincronizar os streams, quantos arquivos o servidor precisará armazenar?
P28. Instale e compile os programas Python TCPClient e UDPClient em um host e TCPServer e UDPServer
em outro host.
a. Suponha que você execute o TCPClient antes de executar o TCPServer. O que acontece? Por
que? b. Suponha que você execute o UDPClient antes de executar o UDPServer. O que acontece?
Por que? c. O que acontece se você usar números de porta diferentes para os lados do cliente e do servidor?
P29. Suponha que em UDPClient.py, após criarmos o socket, adicionamos a linha:
clienteSocket.bind(('', 5432))
Será necessário alterar UDPServer.py? Quais são os números de porta para os soquetes em UDPClient e UDPServer?
O que eles eram antes de fazer essa mudança?
P30. Você pode configurar seu navegador para abrir várias conexões simultâneas para um site?
Quais são as vantagens e desvantagens de ter um grande número de conexões TCP simultâneas?
conexões?
P31. Vimos que os soquetes TCP da Internet tratam os dados enviados como um fluxo de bytes, mas os soquetes
UDP reconhecem os limites da mensagem. Quais são uma vantagem e uma desvantagem da API orientada a byte em
comparação com a API reconhecer explicitamente e preservar os limites de mensagem definidos pelo aplicativo?
P32. O que é o servidor Web Apache? Quanto custa isso? Que funcionalidade tem atualmente? Você pode
querer olhar para a Wikipedia para responder a esta pergunta.
Atribuições de Programação de Socket
O site complementar inclui seis atribuições de programação de soquete. As primeiras quatro atribuições são resumidas abaixo.
A quinta atribuição faz uso do protocolo ICMP e é resumida no final
do Capítulo 5. A sexta tarefa emprega protocolos multimídia e é resumida no final do Capítulo 9. É altamente recomendável
que os alunos concluam várias, se não todas, essas tarefas.

Os alunos podem encontrar detalhes completos dessas tarefas, bem como trechos importantes do código Python, em
o site www.pearsonhighered.com/cs-resources.
Tarefa 1: Servidor Web

Nesta tarefa, você desenvolverá um servidor Web simples em Python capaz de processar apenas
um pedido. Especificamente, seu servidor Web irá (i) criar um soquete de conexão quando contatado por um cliente
(navegador); (ii) receber a solicitação HTTP desta conexão; (iii) analisar o pedido para determinar o
arquivo específico sendo solicitado; (iv) obter o arquivo solicitado do sistema de arquivos do servidor; (v) criar um HTTP
mensagem de resposta que consiste no arquivo solicitado precedido por linhas de cabeçalho; e (vi) enviar a resposta pela conexão TCP
para o navegador solicitante. Se um navegador solicitar um arquivo que não está presente em seu servidor, seu servidor deve retornar
uma mensagem de erro “404 Not Found”.
No Site Companion, fornecemos o código do esqueleto para o seu servidor. Seu trabalho é concluir o código, executar seu servidor e,
em seguida, testar seu servidor enviando solicitações de navegadores em execução em diferentes hosts. Se você executa seu servidor em
um host que já possui um servidor Web em execução, deve usar
uma porta diferente da porta 80 para seu servidor Web.
Tarefa 2: UDP Pinger
Nesta tarefa de programação, você escreverá um programa de ping de cliente em Python. Seu cliente enviará um
mensagem de ping simples para um servidor, receba uma mensagem de ping correspondente do servidor e determine o atraso entre
o momento em que o cliente enviou a mensagem de ping e recebeu a mensagem de ping.
Esse atraso é chamado de tempo de ida e volta (RTT). A funcionalidade fornecida pelo cliente e servidor é semelhante à funcionalidade
fornecida pelo programa de ping padrão disponível em sistemas operacionais modernos.
No entanto, os programas de ping padrão usam o Internet Control Message Protocol (ICMP) (que iremos
estudo no Capítulo 5). Aqui, criaremos um programa de ping não padrão (mas simples!) baseado em UDP.
Seu programa de ping deve enviar 10 mensagens de ping para o servidor de destino por UDP. Para cada mensagem, seu cliente deve
determinar e imprimir o RTT quando a mensagem pong correspondente for retornada. Porque
UDP é um protocolo não confiável, um pacote enviado pelo cliente ou servidor pode ser perdido. Por este motivo, o
o cliente não pode esperar indefinidamente por uma resposta a uma mensagem de ping. Você deve fazer com que o cliente espere até
um segundo por uma resposta do servidor; se nenhuma resposta for recebida, o cliente deve assumir que o pacote foi
perdido e imprimir uma mensagem de acordo.
Nesta tarefa, você receberá o código completo do servidor (disponível no Companion
Local na rede Internet). Seu trabalho é escrever o código do cliente, que será muito semelhante ao código do servidor. Isso é
recomendado que você primeiro estude cuidadosamente o código do servidor. Você pode então escrever seu código de cliente, liberalmente
cortando e colando linhas do código do servidor.
Tarefa 3: Cliente de Email
O objetivo deste trabalho de programação é criar um cliente de e-mail simples que envie e-mail para qualquer destinatário. Seu
cliente precisará estabelecer uma conexão TCP com um servidor de e-mail (por exemplo, um servidor de e-mail do Google), dialogar
com o servidor de e-mail usando o protocolo SMTP, enviar uma mensagem de e-mail para um destinatário
(por exemplo, seu amigo) através do servidor de correio e, finalmente, feche a conexão TCP com o servidor de correio.
Para esta atribuição, o site complementar fornece o código do esqueleto para seu cliente. Seu trabalho é
complete o código e teste seu cliente enviando e-mail para diferentes contas de usuário. Você também pode tentar enviar por meio de
servidores diferentes (por exemplo, por meio de um servidor de e-mail do Google e por meio do servidor de e-mail da sua
universidade).
Tarefa 4: Multi-Threaded Web Proxy
Nesta tarefa, você desenvolverá um proxy da Web. Quando seu proxy recebe uma solicitação HTTP para um objeto de um navegador,
ele gera uma nova solicitação HTTP para o mesmo objeto e a envia para o servidor de origem. Quando o proxy recebe a resposta HTTP
correspondente com o objeto do servidor de origem, ele cria uma nova resposta HTTP, incluindo o objeto, e a envia para o cliente.
Esta procuração irá
ser multi-threaded, para que seja capaz de lidar com várias solicitações ao mesmo tempo.
Para esta atribuição, o site complementar fornece o código do esqueleto para o servidor proxy. Seu trabalho é completar o código e, em
seguida, testá-lo fazendo com que diferentes navegadores solicitem objetos da Web por meio de seu
proxy.
Laboratório Wireshark: HTTP
Tendo experimentado o sniffer de pacotes Wireshark no Laboratório 1, agora estamos prontos para usar o Wireshark
para investigar protocolos em operação. Neste laboratório, exploraremos vários aspectos do protocolo HTTP: a interação básica GET/
resposta, formatos de mensagem HTTP, recuperação de arquivos HTML grandes, recuperação de arquivos HTML
com URLs incorporados, conexões persistentes e não persistentes e autenticação HTTP e
segurança.
Como é o caso de todos os laboratórios do Wireshark, a descrição completa deste laboratório está disponível no site deste livro,
www.pearsonhighered.com/cs-resources.
Laboratório Wireshark: DNS
Neste laboratório, examinamos mais de perto o lado do cliente do DNS, o protocolo que traduz a Internet
nomes de host para endereços IP. Lembre-se da Seção 2.5 de que a função do cliente no DNS é relativamente simples — um cliente envia
uma consulta ao seu servidor DNS local e recebe uma resposta de volta. Muita coisa pode acontecer nos bastidores, invisível para os
clientes DNS, pois os servidores DNS hierárquicos se comunicam entre si para resolver recursiva ou iterativamente a consulta DNS do cliente.
Do ponto de vista do cliente DNS,
no entanto, o protocolo é bastante simples - uma consulta é formulada para o servidor DNS local e uma resposta é
recebido desse servidor. Observamos o DNS em ação neste laboratório.
Como é o caso de todos os laboratórios do Wireshark, a descrição completa deste laboratório está disponível no site deste livro,
www.pearsonhighered.com/cs-resources.
Uma entrevista com…
Marc Andreessen
Marc Andreessen é o co-criador do Mosaic, o navegador da Web que popularizou a World Wide Web em 1993. O
Mosaic tinha uma interface limpa e de fácil compreensão e foi o primeiro navegador a exibir imagens alinhadas
com o texto. Em 1994, Marc Andreessen e Jim Clark fundaram a Netscape, cujo navegador foi de longe o
navegador mais popular em meados da década de 1990. A Netscape também desenvolveu o protocolo Secure
Sockets Layer (SSL) e muitos produtos de servidor de Internet,
incluindo servidores de e-mail e servidores da Web baseados em SSL. Ele agora é cofundador e sócio geral da empresa
de capital de risco Andreessen Horowitz, supervisionando o desenvolvimento de portfólio com participações que incluem
Facebook, Foursquare, Groupon, Jawbone, Twitter e Zynga. Ele atua em vários conselhos, incluindo Bump, eBay, Glam
Media, Facebook e Hewlett-Packard. Ele é bacharel em Ciência da Computação pela Universidade de Illinois em
Urbana-Champaign.
Como você se interessou por computação? Você sempre soube que queria trabalhar em
tecnologia da Informação?
As revoluções dos videogames e da computação pessoal aconteceram quando eu era criança - a computação pessoal
era a nova fronteira tecnológica no final dos anos 70 e início dos anos 80. E não era apenas a Apple e o IBM PC,
mas também centenas de novas empresas como a Commodore e a Atari. Eu aprendi sozinho a programar a partir
de um livro chamado “Instant Freeze-Dried BASIC” aos 10 anos, e consegui
meu primeiro computador (um TRS-80 Color Computer—procure!) aos 12 anos.
Descreva um ou dois dos projetos mais interessantes em que você trabalhou durante sua carreira.
Quais foram os maiores desafios?
Sem dúvida, o projeto mais empolgante foi o navegador da Web Mosaic original em 1992–1993 - e o maior desafio
foi fazer com que alguém o levasse a sério naquela época. Na época, todos
pensou que o futuro interativo seria entregue como “televisão interativa” por grandes empresas,
não como a Internet por startups.
O que o entusiasma sobre o futuro das redes e da Internet? Quais são os seus maiores
preocupações?
O mais empolgante é a enorme fronteira inexplorada de aplicativos e serviços que
programadores e empreendedores são capazes de explorar - a Internet liberou a criatividade em um nível que eu
acho que nunca vimos antes. Minha maior preocupação é o princípio de
consequências - nem sempre sabemos as implicações do que fazemos, como a Internet
sendo usado pelos governos para executar um novo nível de vigilância sobre os cidadãos.
Há algo em particular que os alunos devam estar cientes à medida que a tecnologia da Web avança?
A taxa de mudança - a coisa mais importante a aprender é como aprender - como se adaptar com flexibilidade às
mudanças nas tecnologias específicas e como manter a mente aberta para as novas oportunidades e possibilidades
à medida que avança em sua carreira.
Que pessoas te inspiraram profissionalmente?
Vannevar Bush, Ted Nelson, Doug Engelbart, Nolan Bushnell, Bill Hewlett e Dave Packard,
Ken Olsen, Steve Jobs, Steve Wozniak, Andy Grove, Grace Hopper, Hedy Lamarr, Alan Turing,
Ricardo Stallman.
Quais são suas recomendações para estudantes que desejam seguir carreira em computação e
tecnologia da Informação?
Vá o mais fundo possível para entender como a tecnologia é criada e, em seguida,
complementar com a aprendizagem de como os negócios funcionam.
A tecnologia pode resolver os problemas do mundo?
Não, mas melhoramos o padrão de vida das pessoas por meio do crescimento econômico, e a maioria
o crescimento econômico ao longo da história veio da tecnologia - então isso é o melhor possível.

Caps 1 e 2 - Tradução PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Caps 1 e 2 - Tradução PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Capítulo 1 Redes de computadores e a Internet

introdução ao campo dinâmico de redes de computadores, dando-lhe os princípios e insights práticos

perder de vista o quadro geral.

dados, bem como as redes de acesso e os meios físicos que

atrasos de transmissão, propagação e enfileiramento. Em seguida, apresentaremos alguns

1.1 O que é a Internet?

a descrição prática, usando a Figura 1.1 para ilustrar nossa discussão.

1.1.1 Uma Descrição Porcas e Parafusos

Figura 1.1 Algumas partes da Internet

[Cisco VNI 2015].

convenções. Examinaremos os ISPs e sua interconexão mais de perto na Seção 1.3.

e recebimento de informações na Internet. O Protocolo de Controle de Transmissão (TCP) e o

grande parte deste livro trata de protocolos de rede de computadores!

Os padrões da Internet são desenvolvidos pela Internet Engineering Task Force

também especificam padrões para componentes de rede, a maioria

1.1.2 Uma Descrição dos Serviços

caixa de correio oficial do serviço postal. Assim, o serviço postal

recebimento, uso comum e muitos outros serviços. De forma semelhante, a Internet

questões importantes nas seções e capítulos seguintes.

1.1.3 O que é um protocolo?

redes de computadores: protocolo. O que é um protocolo? O que um protocolo faz?

Uma Analogia Humana

indicação de que se pode prosseguir e perguntar qual é a hora do dia.

resposta não imprimível) pode

Figura 1.2 Um protocolo humano e um protocolo de rede de computador

entende o conceito de tempo e a outra não), os protocolos não interagem

executando o mesmo protocolo para realizar uma tarefa.

você a perguntar ao seu

ouve sua pergunta (recebe sua mensagem de pergunta) e

protocolo. Por exemplo, implementado em hardware

de controle de congestionamento em sistemas finais controlam a taxa na qual os pacotes

livro é sobre protocolos de rede de computadores.

(arquivo) para o seu computador.

1.2 A Borda da Rede

uma rede e examinamos os componentes com os quais

e roteamento em redes de computadores.

Internet como sistemas finais (consulte o Histórico de Caso

Ao longo deste livro, usaremos o

Figura 1.3 Interação do sistema final

A INTERNET DAS COISAS

Segundo algumas estimativas, em 2015 já havia 5 bilhões de coisas conectadas à Internet, e

para a casa inteligente, incluindo

de uma criança e respondem adequadamente.

dispositivos. Essas preocupações de segurança e privacidade podem minar a confiança do consumidor

adoção [FTC 2015].

cerca de 15 grandes centros, cada um com mais de 100.000 servidores.

1.2.1 Redes de Acesso

fisicamente um sistema final ao primeiro roteador (também conhecido como

Figura 1.4 Redes de acesso

Acesso residencial: DSL, cabo, FTTH, dial-up e satélite

Um canal downstream de alta velocidade, na banda de 50 kHz a 1 MHz

Um canal upstream de velocidade média, na banda de 4 kHz a 50 kHz

Um canal telefônico bidirecional comum, na banda de 0 a 4 kHz

Figura 1.5 Acesso à Internet DSL

mesmo milhares de residências se conectam a um único DSLAM

ser menores que as taxas mencionadas acima, pois o

Figura 1.6 Uma rede de acesso híbrida fibra-coaxial

lares downstream de volta para digital formatar. Modems a cabo dividem o

dados contratadas mais baixas ou deficiências de mídia.

downstream, a taxa real na qual

colisão com algum detalhe no Capítulo 6.)