Redes de Computadores: Abordagem Top-Down

Prévia do material em texto

CYAN
VS Gráfica VS Gráfica
MAG
VS Gráfica
YEL
VS Gráfica
BLACK
Forouzan
M
osharraf
www.grupoa.com.br
0800 703 3444
Recorte aqui seu m
arcador de página.
REDES DE COM
PUTADORES
UM
A ABORDAGEM TOP-DOW
N
REDES E INTERNET
www.grupoa.com.br
Forouzan
M
osharraf
REDES DE COM
PUTADORES
UM
A ABORDAGEM TOP-DOW
N
REDES DE
COMPUTADORES
UMA ABORDAGEM TOP-DOWN
Forouzan & Mosharraf
REDES E INTERNET
COMER, D. E.
Redes de Computadores e Internet, 4.ed.
EMC EDUCATION SERVICES
Armazenamento e Gerenciamento de Informações
FOROUZAN, B. A.
Comunicação de Dados e Redes de Computadores, 4.ed.
FOROUZAN & FEGAN
Protocolo TCP/IP, 3.ed.
FOROUZAN & MOSHARRAF
Redes de Computadores: Uma Abordagem Top-down
HAROLD, E. R.
Refatorando HTML: Como Melhorar o Projeto de 
Aplicações Web Existentes
HERRINGTON, J. D.
PHP Hacks: Dicas e Ferramentas Úteis para a Criação de 
Web Sites Dinâmicos
ROMAN, AMBLER & JEWELL
Dominando Enterprise JavaBeans, 2.ed.
STEVENS, FENNER & RUDOFF
Programação de Rede UNIX: API para Soquetes de Rede, 3.ed.
REDES DE
COMPUTADORES
UMA ABORDAGEM TOP-DOWN
Forouzan & Mosharraf
A Internet deixou de ser uma necessidade exclusiva das organizações e passou a 
fazer parte da vida de todos nós, tanto para as questões pessoais quanto para as 
profi ssionais. As tecnologias ligadas às redes e às interconexões de redes estão 
entre aquelas que cresceram mais rapidamente nos últimos anos.
Nesse contexto, Redes de computadores traz aos estudantes e profi ssionais 
da área os conceitos básicos do gerenciamento e da operação, parcial ou to-
tal, de redes. O livro reúne duas características importantes: a apresentação 
dos conceitos usando protocolos em camadas da Internet e da pilha de pro-
tocolos TCP/IP, e a abordagem top-down, ou de cima para baixo, que começa 
explicando os conceitos mais próximos da camada de aplicação até chegar à 
camada física. Nessa abordagem o leitor consegue identifi car situações do seu 
dia a dia antes de passar aos detalhes de implementação usando os serviços das 
demais camadas. 
Trata-se de uma obra essencial para estudantes de informática, sistemas 
de informação, ciência da computação, engenharia elétrica e engenharia da 
computação e afi ns.
Material online
Visite o site www.grupoa.com.br e acesse material de apoio aos 
estudos, em português e inglês.
Área do professor
Visite a Área do Professor no site e tenha acesso ao conteúdo 
exclusivo, em português e inglês, deste livro.
A Bookman Editora é parte do Grupo A, 
uma empresa que engloba diversos 
selos editoriais e várias plataformas 
de distribuição de conteúdo técnico,
científico e profissional, 
disponibilizando-o como, onde 
e quando você precisar.
O Grupo A publica com exclusividade 
obras com o selo McGraw-Hill 
em língua portuguesa.
042381_Redes_computadores_Abordagem_Top-Down.indd 2042381_Redes_computadores_Abordagem_Top-Down.indd 2 14/novembro/12 13:3814/novembro/12 13:38
F727r Forouzan, Behrouz A.
 Redes de computadores [recurso eletrônico] : uma
 abordagem top-down / Behrouz A. Forouzan, Firouz
 Mosharraf ; tradução técnica: Marcos A. Simplicio Jr.,
 Charles Christian Miers. – Dados eletrônicos. – Porto Alegre :
 AMGH, 2013.
 Editado também como livro impresso em 2013.
 ISBN 978-85-8055-169-3
 1. Computação. 2. Redes de computadores. I. Mosharraf,
 Firouz. II. Título. 
CDU 004.7
Catalogação na publicação: Ana Paula M. Magnus – CRB 10/2052
44 Capítulo 2 Camada de aplicação
2.3.1 World  Wide  Web  e  HTTP 
Nesta seção, primeiramente apresentamos a World Wide Web (abreviada como WWW ou 
Web). Discutimos, então, o Protocolo de Transferência de Hipertexto (HTTP – HyperText Transfer 
Protocol), 
o programa cliente-servidor da camada de aplicação de modo geral usado no contexto da Web.
World Wide Web
A ideia da Web foi proposta pela primeira vez por Tim Berners-Lee, em 1989, no CERN*, a Organi-
zação Europeia para Pesquisa Nuclear, para permitir que vários pesquisadores em diferentes locais 
da Europa pudessem acessar as pesquisas uns dos outros. A Web comercial surgiu no início de 1990.
A Web é hoje um repositório de informações no qual os documentos, chamados de páginas 
Web, são distribuídos por todo o mundo e documentos relacionados são vinculados entre si. A 
popularidade e o crescimento da Web pode ser ligado a dois termos da frase anterior: distribuídos 
e vinculados. A distribuição permite o crescimento da Web. Cada servidor Web no mundo pode 
adicionar uma nova página Web ao repositório e anunciá-lo a todos os usuários da Internet sem 
sobrecarregar alguns poucos servidores. A vinculação permite que uma página Web faça refe-
rerência a outra armazenada em um servidor em algum outro lugar no mundo. A vinculação de 
páginas Web é obtida usando um conceito chamado hipertexto, que foi introduzido muitos anos 
antes do advento da Internet. A ideia era utilizar uma máquina que automaticamente recuperasse 
outro documento armazenado no sistema quando um vínculo (link) aparecesse no documento. A 
Web implementou a ideia eletronicamente, permitindo que o documento vinculado fosse recupe-
rado quando o link fosse clicado pelo usuário. Hoje, o termo hipertexto, cunhado para designar 
documentos de texto vinculados, foi alterado para hipermídia, para mostrar que uma página Web 
pode ser um documento de texto, uma imagem, um arquivo de áudio ou um arquivo de vídeo.
O objetivo da Web extrapolou a simples recuperação de documentos vinculados. Hoje, a Web 
é usada para prover serviços de compras eletrônicas e jogos; nela, é possível ouvir programas de 
rádio ou ver programas de televisão sempre que se desejar, sem ser obrigado a ouvir ou ver esses 
programas quando eles são originalmente transmitidos.
Arquitetura
O WWW atual é um serviço cliente-servidor distribuído, em que um cliente usando um navegador 
(browser) pode acessar um serviço por meio de um servidor. No entanto, o serviço fornecido é dis-
tribuído entre muitos locais chamados sites. Cada site possui um ou mais documentos, chamados 
de páginas Web. Cada página Web, no entanto, pode conter algumas ligações ou links para outras 
páginas do mesmo ou de outros sites. Em outras palavras, uma página Web pode ser simples ou 
composta. A simples não tem links para outras páginas; a composta tem um ou mais links para ou-
tras páginas Web. Cada uma delas é um arquivo com um nome e um endereço.
 Exemplo 2.2
Considere	que	precisamos	buscar	um	documento	científico	que	contém	uma	referência	a	outro	arquivo	de	texto	
e	uma	referência	a	uma	imagem	grande.	A	Figura	2.8	ilustra	essa	situação.
O	documento	principal	e	a	imagem	são	armazenados	em	dois	arquivos	separados	no	mesmo	site	(arquivo	A	e	
arquivo	B);	o	arquivo	de	texto	referenciado	é	armazenado	em	outro	site	(arquivo	C).	Como	estamos	lidando	com	
três	arquivos	diferentes,	precisamos	de	 três	 transações	se	quisermos	ver	o	documento	completo.	A	primeira	
* Em francês: Conseil Européen pour la Recherche Nucléaire.
452.3 Aplicações cliente-servidor padronizadas 
transação	 (pedido/	 resposta)	 recupera	 uma	 cópia	 do	 documento	 principal	 (arquivo	 A),	 que	 tem	 referências	
(ponteiros)	para	o	segundo	e	terceiro	arquivos.	Após	recuperar	uma	cópia	do	documento	principal	e	navegar	
por	ela,	o	usuário	pode	clicar	sobre	a	referência	à	imagem	para	invocar	a	segunda	transação	e	recuperar	uma	
cópia	da	imagem	(arquivo	B).	Se	o	usuário	precisar	ver	o	conteúdo	do	arquivo	de	texto	referenciado,	ele	pode	
clicar	sobre	a	sua	referência	(ponteiro)	invocando	a	terceira	operação	e	recuperando	uma	cópia	do	arquivo	C.	
Observe	que,	apesar	dos	arquivos	A	e	B	serem	armazenados	no	site	 I,	eles	são	arquivos	independentes	com	
nomes	e	endereços	distintos.
Duas	 transações	são	necessárias	para	recuperá-los.	Um	ponto	muito	 importante	de	que	precisamos	 lembrar	
é	que	o	arquivo	A,	o	arquivo	B	e	o	arquivo	C	no	Exemplo	2.2	são	páginas	Web	independentes,	cada	uma	com	
um	nome	e	endereço	distintos.	Embora	as	referências	para	os	arquivos	B	ou	C	estejam	inclusas	no	arquivo	A,	
isto	não	significaque	cada	um	desses	arquivos	não	possa	ser	recuperado	de	forma	independente.	Um	segundo	
usuário	pode	recuperar	o	arquivo	B	com	uma	transação.	Um	terceiro	usuário	pode	recuperar	o	arquivo	C	com	
uma	transação.
Cliente Web (Navegador) Diversos fornecedores oferecem navegadores (browsers) comerciais 
que interpretam e exibem uma página Web, e todos eles utilizam quase a mesma arquitetura. Cada 
navegador geralmente tem três partes: um controlador, protocolos cliente, e interpretadores. (Ver 
Figura 2.9.)
Navegador
HTTP FTP SSH SMTP
Interpretadores
Java
JavaScript
HTML
Controlador
Figura 2.9 Navegador (browser).
O controlador recebe a entrada do teclado ou do mouse e usa os programas-cliente para aces-
sar o documento. Depois, o controlador usa um dos interpretadores para exibir o documento na 
tela. O protocolo-cliente pode ser um dos protocolos descritos mais adiante, como HTTP ou FTP. 
2
1
3
5
6
4
Site I Site II
A: Documento original
B: Imagem
C: Arquivo referenciado
A B C
Cliente
Pedido1
Resposta1
Pedido2
Resposta2
Pedido3
Resposta3
Figura 2.8 Esquema para o Exemplo 2.2.
46 Capítulo 2 Camada de aplicação
O interpretador pode ser HTML, Java, ou JavaScript, dependendo do tipo de documento. Alguns 
navegadores comerciais são o Internet Explorer, o Netscape Navigator, o Mozilla Firefox, o Google 
Chrome e o Opera.
Servidor Web A página Web é armazenada no servidor. Cada vez que um pedido chega, o do-
cumento correspondente é enviado ao cliente. Para conseguir uma melhor eficiência, os servidores 
normalmente armazenam arquivos solicitados em memória cache (memória de armazenamento 
temporário), pois é mais rápido acessar a memória do que o disco. Um servidor pode também se 
tornar mais eficiente se usar multithreading ou multiprocessamento. Nesse caso, um servidor pode 
responder a mais de um pedido de cada vez. Entre os servidores Web populares, estão o Apache e o 
Microsoft Internet Information Server (IIS).
Localizador Uniforme de Recursos (URL) 
Uma página Web, assim como um arquivo, precisa ter um identificador único que permita dis-
tinguí-la de outras. Para definir uma página Web, precisamos de três identificadores: host, porta 
e caminho. Entretanto, antes da definição, precisamos dizer ao navegador que tipo de aplicação 
cliente-servidor queremos usar, o que é chamado de protocolo. Isto significa que precisamos de 
quatro identificadores: o primeiro é o tipo de instrumento que será utilizado para buscar a página 
Web; os três últimos formam uma combinação que define o objeto de destino (página Web).
 � Protocolo. O primeiro identificador é a abreviação para o programa cliente-servidor que 
utilizamos para acessar a página Web. Embora na maior parte do tempo o protocolo seja 
o Protocolo de Transferência de Hipertexto (HTTP – HyperText Transfer Protocol), que 
discutiremos em breve, também podemos usar outros protocolos, como o Protocolo de 
Transferência de Arquivos (FTP – File Transfer Protocol).
 � Host. O identificador do host pode ser o endereço IP do servidor ou o nome único dado 
ao servidor. Os endereços IP podem ser definidos usando notações decimais pontuadas, 
conforme descrito no Capítulo 4 (por exemplo, 64.23.56.17); o nome costuma ser o de 
domínio que define univocamente o host, tal como forouzan.com, algo que discutiremos 
quando falarmos do Sistema de Nomes de Domínio (DNS – Domain Name System) mais 
adiante.
 � Porta. A porta, um número inteiro de 16 bits, normalmente é predefinida para a aplicação 
cliente-servidor. Por exemplo, se o protocolo HTTP é usado para acessar a página Web, o 
número de porta conhecido é 80. No entanto, se uma porta diferente for usada, o número 
pode ser fornecido explicitamente.
 � Caminho. O caminho identifica o local e o nome do arquivo no sistema operacional 
subjacente. O formato do identificador normalmente depende do sistema operacional. No 
UNIX, um caminho é um conjunto de nomes de diretório seguido do nome do arquivo, 
todos separados por uma barra. Por exemplo, /topo/proximo/ultimo/meuarquivo é um ca 
minho que define univocamente um arquivo chamado meuarquivo, armazenado no di-
retório ultimo, que por sua vez é parte do diretório proximo, que por sua vez está dentro 
do diretório topo. Em outras palavras, o caminho lista os diretórios de cima para baixo, 
seguido então pelo nome do arquivo.
Para combinar essas quatro partes, foi criado o Localizador Uniforme de Recursos (URL – 
Uniform Resource Locator), que usa três diferentes separadores entre as quatro partes, conforme 
ilustrado a seguir:
protocolo://host/caminho Usado na maioria dos casos
protocolo://host:porta/caminho Usado quando o número de porta é necessário
472.3 Aplicações cliente-servidor padronizadas 
 Exemplo 2.3
O	URL	http://www.mhhe.com/compsci/forouzan/	define	a	página	Web	relacionada	a	um	dos	autores	deste	livro.	
A	cadeia	de	caracteres	www.mhhe.com	é	o	nome	do	computador	na	empresa	McGraw-Hill	(as	três	letras	www	
são	parte	do	nome	do	host	e	são	adicionadas	ao	host	comercial).	O	caminho	é	compsci/forouzan/,	que	define	a	
página	Web	do	Forouzan	no	diretório	compsci	(computer science,	ou	ciência	da	computação).
Documentos Web 
Os documentos na WWW podem ser agrupados em três grandes categorias: estáticos, dinâmicos 
e ativos. 
Documentos estáticos Documentos estáticos são documentos de conteúdo fixo criados e armaze-
nados em um servidor. O cliente pode apenas obter uma cópia do documento. Em outras palavras, 
o conteúdo do arquivo é determinado quando este é criado, não quando é usado. Obviamente, os 
conteúdos no servidor podem ser alterados, mas o usuário não pode alterá-los. Quando um cliente 
acessa o documento, uma cópia dele é enviada. O usuário pode, então, usar um navegador para ver 
o documento. Documentos estáticos são preparados usando uma dentre várias linguagens: Lingua-
gem de Marcação de Hipertexto (HTML – Hypertext Markup Language), Linguagem de Marcação 
Extensível (XML – Extensible Markup Language), Linguagem de Estilo Extensível (XSL – Extensible 
Style Language) e Linguagem de Marcação de Hipertexto Extensível (XHTML – Extensible Hy-
pertext Markup Language). Discutiremos essas linguagens no Apêndice C, no site do livro. 
Documentos dinâmicos Um documento dinâmico é criado por um servidor Web sempre que 
um navegador solicita o documento. Quando uma solicitação chega, o servidor Web executa um 
aplicativo ou um script que cria o documento dinamicamente. O servidor retorna o resultado do 
programa ou script como resposta para o navegador que solicitou o documento. Como um novo 
documento é criado para cada solicitação, o conteúdo de um documento dinâmico pode variar 
de um pedido para outro. Um exemplo muito simples de um documento dinâmico é uma página 
contendo a data e a hora de um servidor. A data e a hora são tipos de informações dinâmicas, dado 
que mudam a cada instante. O cliente pode pedir ao servidor que execute um programa tal como 
o programa date no UNIX, e então envie o resultado da execução de volta ao cliente. Embora 
a tecnologia de CGI (Common Gateway Interface) tenha sido bastante usada para recuperar do-
cumentos dinâmicos no passado, opções mais atuais incluem uma linguagem de script, tal como 
JSP (Java Server Pages), que usa a linguagem Java para executar scripts, ou ASP (Active Server 
Pages), um produto da Microsoft que utiliza a linguagem Visual Basic ou ColdFusion, que incor-
pora consultas a um banco de dados SQL (Structured Query Language, ou Linguagem de Consulta 
Estruturada) no documento HTML.
Documentos ativos Para muitas aplicações, precisamos que um programa ou um script seja exe-
cutado no lado do cliente. Estes são chamados documentos ativos. Por exemplo, considere que 
queremos executar um programa que cria gráficos animados na tela ou um programa que interage 
com o usuário. O programa definitivamente precisa ser executado no lado do cliente, onde a ani-
mação ou interação ocorre. Quando um navegador solicita um documento ativo, o servidor envia 
uma cópia do documentoou um script, que é executado no lado do cliente (no navegador). Uma 
maneira de criar um documento ativo é utilizando applets Java, um programa escrito em Java no 
servidor. Ele já está compilado e pronto para ser executado. O documento encontra-se no formato 
de bytecode (binário). Outra forma é usando JavaScripts, mas, dessa vez, obtendo e executando o 
script no lado do cliente. 
Protocolo de Transferência de Hipertexto 
O Protocolo de Transferência de Hipertexto (HTTP – HyperText Transfer Protocol) é um pro-
tocolo usado para definir como os programas cliente-servidor podem ser escritos para recuperar 
48 Capítulo 2 Camada de aplicação
páginas da Web. Um cliente HTTP envia uma solicitação; um servidor HTTP retorna uma resposta. 
O servidor usa o número de porta 80; o cliente usa um número de porta temporário. O HTTP usa os 
serviços do TCP, o qual, conforme discutido anteriormente, é um protocolo orientado à conexão e 
confiável. Isto significa que, antes que ocorra qualquer transação entre o cliente e o servidor, uma 
conexão precisa ser estabelecida entre eles. Após a transação ser efetuada, a conexão deve ser en-
cerrada, mas o cliente e o servidor não precisam se preocupar com erros nas mensagens trocadas ou 
com a perda de mensagens, já que o TCP é confiável e vai cuidar desses problemas, como veremos 
no Capítulo 3.
Conexões não persistentes versus persistentes
Conforme discutimos na seção anterior, o conceito de hipertexto incorporado em páginas Web pode 
exigir vários pedidos e respostas. Se as páginas Web, os objetos a serem recuperados, estiverem 
localizadas em servidores diferentes, não temos outra escolha além de criar uma nova conexão TCP 
para recuperar cada objeto. No entanto, se alguns dos objetos estão localizados no mesmo servi-
dor, temos duas opções: recuperar cada objeto usando uma nova conexão TCP ou criar uma única 
conexão TCP e recuperá-los todos. O primeiro método é denominado conexão não persistente, e o 
segundo, conexão persistente. O HTTP especificava o uso de conexões não persistentes antes de 
sua versão 1.1, e as conexões persistentes são a opção-padrão da versão 1.1, apesar de isso poder 
ser alterado pelo usuário.
Conexões não persistentes Em uma conexão não persistente, uma conexão TCP é criada para 
cada pedido/resposta. Os passos desta estratégia são listados a seguir:
1. O cliente abre uma conexão TCP e envia uma solicitação.
2. O servidor envia a resposta e fecha a conexão.
3. O cliente lê os dados até encontrar um marcador de fim de arquivo; ele, então, fecha a 
conexão.
Nessa estratégia, se um arquivo contém links para N imagens diferentes em diferentes arquivos 
(todos localizados no mesmo servidor), a conexão deve ser aberta e fechada N+1 vezes. A estratégia 
não persistente impõe uma elevada carga computacional no servidor porque o servidor precisa de 
N+1 buffers diferentes cada vez que uma conexão é aberta.
 Exemplo 2.4
A	Figura	2.10	mostra	um	exemplo	de	uma	conexão	não	persistente.	O	cliente	precisa	acessar	um	arquivo	que	
contém	um	link	para	uma	imagem.	O	arquivo	de	texto	e	a	imagem	estão	localizados	no	mesmo	servidor.	Aqui,	
precisamos	de	duas	conexões.	O	TCP	exige	pelo	menos	três	mensagens	de	handshake	para	estabelecer	a	co-
nexão,	mas	a	solicitação	pode	ser	enviada	com	a	terceira	mensagem.	Depois	que	a	conexão	é	estabelecida,	o	
objeto	pode	ser	transferido.	Após	receber	um	objeto,	mais	três	mensagens	de	handshake	são	necessárias	para	
encerrar	a	conexão,	como	veremos	no	Capítulo	3.	Isto	significa	que	o	cliente	e	o	servidor	estão	envolvidos	em	
dois	estabelecimentos	de	conexão	e	dois	encerramentos	de	conexão.	Se	a	transação	envolve	a	recuperação	de	
10	ou	20	objetos,	os	tempos	de	ida	e	volta	das	mensagens	envolvidas	nesses	handshakes	se	somam	para	criar	
uma	grande	carga	computacional.	Quando	descrevermos	a	programação	cliente-servidor	no	 fim	do	capítulo,	
mostraremos	que	para	cada	conexão,	o	cliente	e	o	servidor	precisam	alocar	recursos	adicionais,	como	buffers	e	
variáveis.	Essa	é	uma	outra	carga	adicional	em	ambos	os	lados,	mas	especialmente	no	lado	do	servidor.
Conexões persistentes O HTTP versão 1.1 especifica como padrão o uso de uma conexão persis-
tente. Em uma conexão persistente, o servidor deixa a conexão aberta para outras solicitações após 
o envio de uma resposta. O servidor pode fechar a conexão a pedido de um cliente ou se um tempo 
limite for atingido. O servidor geralmente envia o tamanho dos dados com cada resposta. No entan-
to, existem algumas ocasiões em que o servidor não conhece o tamanho dos dados, como quando 
492.3 Aplicações cliente-servidor padronizadas 
um documento é criado dinâmica ou ativamente. Nesses casos, o servidor informa ao cliente que o 
tamanho não é conhecido e fecha a conexão após o envio dos dados, de modo que o cliente saiba 
que o final dos dados foi atingido. Tempo e recursos são economizados usando conexões persisten-
tes. Apenas um conjunto de buffers e variáveis precisa ser definido para a conexão em cada local. 
O Tempo de Ida e Volta (RTT* – Round Trip Time) para o estabelecimento e para o encerramento 
da conexão é reduzido. 
 Exemplo 2.5
A	Figura	2.11	mostra	o	mesmo	cenário	do	Exemplo	2.4,	mas	usando	uma	conexão	persistente.	Apenas	um	es-
tabelecimento	e	encerramento	de	conexão	são	usados,	mas	a	solicitação	da	imagem	é	enviada	separadamente.
* N. de T.: O RTT corresponde ao tempo necessário para um pacote ir e voltar de seu destino. Esse conceito será 
mais bem explorado no Capítulo 3.
Cliente
C
on
ex
ão
C
on
ex
ão
Arquivo
Imagem
Imagem
Primeiro handshake
Primeiro handshake
Segundo handshake
Segundo handshake
Terceiro handshake + pedido
Terceiro handshake
Resposta
Primeiro handshake
Primeiro handshake
Segundo handshake
Segundo handshake
Terceiro handshake + pedido
Terceiro handshake
Resposta
Tempo Tempo
Servidor
Arquivo
Figura 2.10 Esquema para o Exemplo 2.4.
50 Capítulo 2 Camada de aplicação
Formatos de mensagens 
O protocolo HTTP define o formato das mensagens de pedido e de resposta, conforme apresentado 
na Figura 2.12. Colocamos os dois formatos lado a lado para fins de comparação. Cada mensagem 
é composta de quatro seções: a primeira seção na mensagem de pedido é chamada de linha de so-
licitação, a primeira seção na mensagem de resposta é chamada de linha de estado. As outras três 
seções têm os mesmos nomes nas mensagens de pedido e de resposta. No entanto, as semelhanças 
entre elas estão apenas nos nomes, pois podem ter conteúdos diferentes. Discutiremos cada tipo de 
mensagem separadamente.
Mensagem de pedido Como dissemos anteriormente, a primeira linha em uma mensagem de 
pedido é chamada linha de solicitação. Existem três campos nessa linha separados por um espaço e 
terminados por dois caracteres – retorno de carro (carriage return) e nova linha (line feed) – como 
mostra a Figura 2.12. Os campos são chamados método, URL e versão. 
O campo de método define os tipos de solicitação. Na versão 1.1 do HTTP, vários métodos são 
definidos, conforme mostra a Tabela 2.1. Na maioria das vezes, o cliente utiliza o método GET para 
enviar um pedido, e o corpo da mensagem fica vazio. O método HEAD é usado quando o cliente 
necessita apenas de algumas informações sobre a página Web do servidor, como a última vez em 
que ela foi modificada. Ele também pode ser usado para testar a validade de um URL. A mensagem 
de resposta, nesse caso, tem apenas a seção de cabeçalho, enquanto a seção de corpo fica vazia. O 
método PUT é o inverso do GET, permitindo ao cliente postar uma nova página Web no servidor (se 
for admitido). O método POST é semelhante ao PUT, mas é usado para enviar alguma informação 
para o servidor para ser adicionada à página Web ou para modificá-la. O método TRACE é utilizado 
para depuração; o cliente pede ao servidor que devolva o próprio pedido para verificar se o servi-
dor está recebendo as solicitações. O método DELETE permite que o cliente remova uma página 
Web no servidor se o cliente tiver permissão para fazê-lo.O método CONNECT foi originalmente 
C
on
ex
ão
Primeiro handshake
Primeiro handshake
Segundo handshake
Segundo handshake
Terceiro handshake + pedido
Pedido
Terceiro handshake
Resposta
Resposta
Tempo Tempo
Imagem
Servidor
ArquivoCliente
Arquivo
Imagem
Figura 2.11 Esquema para o Exemplo 2.5.
512.3 Aplicações cliente-servidor padronizadas 
criado como um método reservado; pode ser usado por servidores proxy, conforme discutido mais 
adiante. Finalmente, o método OPTIONS permite que o cliente pergunte sobre as propriedades de 
uma página Web.
tabela 2.1 Métodos
Método Ação
GET Solicita	um	documento	ao	servidor	
HEAD Solicita	informações	sobre	um	documento,	mas	não	o	documento	em	si	
PUT Envia	um	documento	do	cliente	para	o	servidor	
POST Envia	alguma	informação	do	cliente	para	o	servidor	
TRACE Ecoa	a	solicitação	recebida	
DELETE Remove	a	página	Web
CONNECT Reservado	
OPTIONS Consulta	opções	disponíveis	
O segundo campo, URL, foi discutido anteriormente neste capítulo. Ele define o endereço e 
o nome da página Web correspondente. O terceiro campo, versão, mostra a versão do protocolo; a 
mais atual do HTTP é 1.1.
Após a linha de solicitação, podemos ter zero ou mais linhas de cabeçalho de solicitação. Cada 
linha de cabeçalho envia informações adicionais do cliente para o servidor. Por exemplo, o cliente 
pode solicitar que o documento seja enviado em um formato especial. Cada linha de cabeçalho tem 
um nome de cabeçalho, um caractere de dois pontos ( : ), um espaço e um valor de cabeçalho (ver 
Figura 2.12). A Tabela 2.2 mostra alguns nomes de cabeçalho geralmente usados em uma solicita-
ção. O campo valor define os valores associados a cada nome do cabeçalho. A lista de valores pode 
ser encontrada nas RFCs correspondentes.
O corpo pode estar presente em uma mensagem de solicitação, e costuma conter o comentário 
a ser enviado ou o arquivo a ser publicado no site quando o método é PUT ou POST.
Figura 2.12 Formatos das mensagens de pedido e resposta.
Linha de
solicitação
Linha de
cabeçalho
Legenda
Mensagem de pedido Mensagem de resposta
Linha em
branco
Corpo
sp: Spaço cr: Retorno de carro lf: Nova linha
cr lf
sp sp cr lfMétodo URL Versão
sp
sp
cr lf:Nome do cabeçalho Valor
cr lf: Valor
Linha de
estado
Linha de
cabeçalho
Número variável de linhas
(Presente apenas em algumas mensagens)
Número variável de linhas
(Presente apenas em algumas mensagens)
Corpo
cr lf
sp sp cr lfVersão Frase
sp
sp
cr lf:
:
Valor
cr lfValor
Código
de estado
Linha em
branco
Nome do cabeçalho
Nome do cabeçalho
Nome do cabeçalho
52 Capítulo 2 Camada de aplicação
tabela 2.2 Nomes	de	cabeçalho	de	solicitação.
Cabeçalho Descrição
User-agent Identifica	o	programa-cliente	
Accept Mostra	o	formato	de	mídia	que	o	cliente	pode	aceitar	
Accept-charset Mostra	o	conjunto	de	caracteres	que	o	cliente	pode	manipular	
Accept-encoding Mostra	o	esquema	de	codificação	que	o	cliente	pode	manipular	
Accept-language Mostra	o	idioma	que	o	cliente	pode	aceitar	
Authorization Mostra	quais	permissões	o	cliente	tem	
Host Mostra	o	host	e	o	número	de	porta	do	cliente	
Date Mostra	a	data	atual	
Upgrade Especifica	o	protocolo	de	comunicação	preferencial	
Cookie Devolve	o	cookie	para	o	servidor	(explicado	mais	adiante)	
If-Modified-Since Se	o	arquivo	foi	modificado	desde	uma	data	específica
Mensagem de resposta O formato da mensagem de resposta também é mostrado na Figura 2.12. 
A mensagem de resposta consiste em uma linha de estado, linhas de cabeçalho, uma linha em branco, 
e às vezes um corpo. A primeira linha em uma mensagem de resposta é chamada linha de estado. 
Existem três campos nessa linha separados por espaços e terminados por um retorno de carro e uma 
nova de linha. O primeiro campo define a versão do protocolo HTTP, atualmente 1.1. O campo de có-
digo de estado define o estado do pedido. Ele consiste em três dígitos. Enquanto os códigos na faixa de 
100 a 199 são apenas informativos, os códigos na faixa de 200 a 299 indicam o sucesso da solicitação. 
Os códigos na faixa de 300 a 399 redirecionam o cliente para outro URL, e os códigos na faixa de 400 
a 499 indicam um erro no lado do cliente. Finalmente, os códigos na faixa de 500 a 599 indicam um 
erro no lado do servidor. A frase de estado explica o código do estado em formato de texto. 
Após a linha de estado, pode haver zero ou mais linhas de cabeçalho de resposta, e cada uma 
envia informações adicionais do servidor para o cliente. Por exemplo, o remetente pode enviar 
informações adicionais sobre o documento. Cada linha de cabeçalho tem um nome de cabeçalho, 
um caractere de dois pontos ( : ), um espaço, e um valor do cabeçalho. Mostraremos algumas linhas 
de cabeçalho nos exemplos ao final desta seção. A Tabela 2.3 mostra alguns nomes de cabeçalho 
geralmente usados em uma mensagem de resposta. 
tabela 2.3 Nomes	de	cabeçalho	de	resposta.
Cabeçalho Descrição
Date Mostra	a	data	atual	
Upgrade Especifica	o	protocolo	de	comunicação	preferencial
Server Fornece	informações	sobre	o	servidor	
Set-Cookie O	servidor	pede	ao	cliente	que	salve	um	cookie	
Content-Encoding Especifica	o	esquema	de	codificação
(Continua	)
532.3 Aplicações cliente-servidor padronizadas 
tabela 2.3 Nomes	de	cabeçalho	de	resposta.
Cabeçalho Descrição
Content-Language Especifica	o	idioma	
Content-Length Mostra	o	comprimento	do	documento	
Content-Type	 Especifica	o	tipo	de	mídia	
Location Para	pedir	ao	cliente	que	envie	o	pedido	a	outro	site
Accept-Ranges O	servidor	aceitará	as	faixas	de	byte	requisitadas
Last-modified Fornece	a	data	e	a	hora	da	última	alteração
O corpo contém o documento a ser enviado pelo servidor para o cliente. O corpo está sempre 
presente, a não ser que a resposta seja uma mensagem de erro.
 Exemplo 2.6
Esse	exemplo	recupera	um	documento	(ver	Figura	2.13).	Usamos	o	método	GET	para	recuperar	uma	imagem	
com	o	caminho	 /usr/bin/imagem1.	A	 linha	de	solicitação	mostra	o	método	 (GET),	o	URL	e	a	versão	do	HTTP	
(1.1).	O	cabeçalho	tem	duas	linhas	que	mostram	que	o	cliente	pode	aceitar	imagens	no	formato	GIF	ou	JPEG.	O	
pedido	não	tem	um	corpo.	A	mensagem	de	resposta	contém	a	linha	de	estado	e	quatro	linhas	de	cabeçalho	que	
definem	a	data,	o	servidor,	a	codificação	do	conteúdo	(versão	do	MIME,	que	será	descrito	quando	discutirmos	
sobre	correio	eletrônico)	e	o	comprimento	do	documento.	O	corpo	do	documento	vem	depois	do	cabeçalho.	
Pedido
Resposta
GET /usr/bin/imagem1 HTTP/1.1
Accept: imagem/gif
Accept: imagem/jpeg
HTTP/1.1 200 OK
Date: Mon, 10-Jan-2011 13:15:14 GMT
Server: Challenger
Content-encoding: MIME-versão 1.0
Content-length: 2048
(Corpo do documento)
Cliente
Servidor
2
1
Tempo Tempo
Figura 2.13 Esquema para o Exemplo 2.6.
 Exemplo 2.7
Nesse	 exemplo,	 o	 cliente	 deseja	 enviar	 uma	 página	Web	 para	 ser	 publicada	 no	 servidor.	 Usamos	 o	 método	
PUT,	e	a	linha	de	solicitação	mostra	o	método	(PUT),	o	URL	e	a	versão	do	HTTP	(1.1).	Existem	quatro	linhas	de	
cabeçalhos.	O	corpo	da	solicitação	contém	a	página	Web	a	ser	publicada.	A	mensagem	de	resposta	contém	
a	linha	de	estado	e	quatro	linhas	de	cabeçalhos.	O	documento	criado,	que	é	um	documento	CGI,	é	fornecido	
como	o	corpo	(ver	Figura	2.14).
(Continuação)
54 Capítulo 2 Camada de aplicação
Pedido condicional 
Um cliente pode adicionar uma condição em seu pedido. Nesse caso, o servidor enviará a página 
Web solicitada se a condição for satisfeita, ou informará o cliente caso contrário. Uma das condi-
ções mais comuns impostas pelo cliente refere-se à data e hora em que a página Web foi modificada. 
O cliente pode enviar a linha de cabeçalho If-Modified-Since com o pedido para notificar ao servi-
dor que precisa da página apenas se ela foi modificado após um certo ponto.
 Exemplo 2.8
O	exemplo	a	seguir	mostra	como	um	cliente	pode	impor	a	condição	de	data	e	hora	de	modificação	em	um	pedido.
GET	http://www.commonServer.com/information/arquivo1	HTTP/1.1 linha de solicitação
If-Modified-Since:	Thu,	Sept	04	00:00:00	GMTlinha de cabeçalho
linha em branco
A	linha	de	estado	na	resposta	mostra	que	o	arquivo	não	foi	modificado	após	o	instante	de	tempo	definido.	
O	corpo	da	mensagem	de	resposta	também	se	encontra	vazio.
HTTP/1.1	304	Not	Modified linha de estado
Date:	Sat,	Sept	06	08	16:22:46	GMT primeira linha de cabeçalho
Server:	commonServer.com Segunda linha de cabeçalho
linha em branco
(Corpo	vazio) Corpo vazio
Pedido
Resposta
(Corpo do documento)
Cliente
Servidor
PUT /cgi-bin/doc.pl HTTP/1.1
Accept: */*
Accept: image/gif
Accept: image/jpeg
Content-length: 50
(Informação fornecida)
HTTP/1.1 200 OK
Date: Mon, 10-Jan-2011 13:15:14 GMT
Server: Challenger
Content-encoding: MIME-version 1.0
Content-length: 2000
1
2
Tempo Tempo
Figura 2.14 Esquema para o Exemplo 2.7.
552.3 Aplicações cliente-servidor padronizadas 
Cookies 
A World Wide Web foi originalmente concebida como uma entidade sem estado. Um cliente envia 
um pedido; um servidor responde, e o relacionamento entre as duas partes acaba aí. O propósito 
original da Web, a recuperação de documentos publicamente disponíveis, se encaixa perfeitamente 
nessa estrutura. Entretanto, a Web atual tem outras funcionalidades que precisam se lembrar de 
algumas informações sobre os clientes; algumas delas estão listadas a seguir:
 � Sites estão sendo usados como lojas virtuais, permitindo que os usuários naveguem pela 
loja, selecionem os itens desejados, coloque-os em um carrinho de compras virtual e pa-
guem no final com um cartão de crédito.
 � Alguns sites precisam permitir o acesso apenas a clientes registrados. 
 � Alguns sites são usados como portais: o usuário seleciona as páginas Web que ele deseja ver. 
 � Alguns sites são apenas agências de publicidade. 
Para esses fins, o mecanismo de cookies (cuja tradução literal seria “biscoito”) foi criado. 
Criando e armazenando cookies A criação e o armazenamento de cookies dependem da imple-
mentação; no entanto, o princípio básico permanece o mesmo. 
1. Quando um servidor recebe um pedido de um cliente, ele armazena informações sobre 
o cliente em um arquivo ou em uma cadeia de caracteres. As informações podem incluir o 
nome de domínio do cliente, o conteúdo do cookie (informações que o servidor reuniu so-
bre o cliente, como nome, número da carteira de identidade etc.), um timestamp (registro 
de horário), e outras informações, dependendo da implementação. 
2. O servidor inclui o cookie na resposta que envia ao cliente. 
3. Quando o cliente recebe a resposta, seu navegador armazena o cookie no diretório de 
cookies, que é ordenado pelo nome de domínio do servidor. 
Usando cookies Quando um cliente envia um pedido para um servidor, o navegador procura no 
diretório de cookies algum cookie enviado por aquele servidor. Caso seja encontrado, o cookie é 
incluído no pedido. Quando o servidor recebe o pedido, ele sabe que aquele é um cliente antigo, 
não um novo. Perceba que o conteúdo do cookie nunca é lido pelo navegador ou divulgado para o 
usuário. É um cookie “preparado” pelo servidor e “comido” pelo servidor. Agora, vejamos como 
um cookie é usado para os quatro propósitos mencionados anteriormente: 
 � Uma loja virtual (e-commerce) pode usar um cookie para seus clientes comprado-
res. Quando um cliente escolhe um item e o insere em um carrinho, um cookie que 
contém informações sobre o item, como seu número e preço unitário, é enviado para 
o navegador. Se o cliente selecionar um segundo item, o cookie é atualizado com 
informações sobre a nova seleção, e assim por diante. Quando o cliente termina suas 
compras e deseja realizar o pagamento, o último cookie é recuperado e o preço total 
é calculado. 
 � O site que restringe o acesso apenas a clientes cadastrados envia o cookie para o cliente 
quando este se registra pela primeira vez. Para qualquer futuro acesso, apenas os clientes que 
enviam o cookie apropriado são autorizados.
 � Um portal Web usa o cookie de uma maneira similar. Quando um usuário seleciona suas 
páginas favoritas, um cookie é criado e enviado. Se o site é acessado novamente, o cookie 
é enviado para o servidor para mostrar o que o cliente está procurando. 
 � Cookies também são usados por agências de publicidade. Uma agência de publicida-
de pode colocar anúncios (banners) publicitários em algum site principal que é fre-
quentemente visitado por usuários. A agência de publicidade provê apenas um URL 
56 Capítulo 2 Camada de aplicação
que fornece o endereço da agência de publicidade e não o banner em si. Quando um 
usuário visita o site principal e clica no ícone de uma empresa, um pedido é enviado à 
agência de publicidade, que envia o banner solicitado, mas também inclui um cookie 
com o ID do usuário. Qualquer uso futuro dos banners adiciona informações ao banco 
de dados com relação ao perfil de comportamento daquele usuário na Web. A agência 
de publicidade pode compilar os interesses do usuário e então vender essa informação 
a terceiros. Esse uso de cookies os tornou bastante controverso. Espera-se que alguma 
nova regra seja elaborada para preservar a privacidade dos usuários.
 Exemplo 2.9
A	Figura	2.15	mostra	um	cenário	em	que	uma	loja	virtual	pode	se	beneficiar	do	uso	de	cookies.
Tempo Tempo
Um arquivo de cliente
é criado com o ID: 12343
Atualiza
Atualiza
Atualiza
Pedido
Resposta
GET Melhoresbrinquedos.com HTTP/1.1
HTTP/1.1 200 OK
Página apresentando os brinquedos
Cliente Servidor
2
3
4
5
6
1
Pedido
Pedido
GET image HTTP/1.1
Set-Cookie: 12343
Resposta
HTTP/1.1 200 OK
Página apresentando o preço
Resposta
HTTP/1.1 200 OK
Confirmação da encomenda
Cookie: 12343
GET image HTTP/1.1
Cookie: 12343
Informação sobre o pagamento
Um arquivo de vendedor
é criado com o ID: 12343
Cookie
Cookie
Figura 2.15 Esquema para o Exemplo 2.9.
572.3 Aplicações cliente-servidor padronizadas 
Considere que um comprador quer adquirir um brinquedo de uma loja virtual chamada Me-
lhoresBrinquedos. O navegador do comprador (cliente) envia um pedido para o servidor Melho-
resBrinquedos. O servidor cria um carrinho de compras vazio (uma lista) para o cliente e atribui 
um ID para o carrinho de compras (por exemplo, 12343). O servidor, então, envia uma mensagem 
de resposta, que contém as imagens de todos os brinquedos disponíveis e um link associado a 
cada brinquedo; quando clicado, o link seleciona o brinquedo. A mensagem de resposta também 
inclui a linha de cabeçalho Set-Cookie cujo valor é 12343. O cliente exibe as imagens e armazena 
o valor do cookie em um arquivo chamado MelhoresBrinquedos. O cookie não é revelado ao 
comprador. Então, o comprador seleciona um dos brinquedos e clica sobre ele. O cliente envia 
um pedido, incluindo o ID 12343 na linha de cabeçalho de Cookie. Embora o servidor possa ter 
ficado ocupado e tenha esquecido desse comprador, ao receber o pedido e verificar o cabeçalho, 
ele encontra o valor 12343 como o valor do cookie. O servidor sabe que não se trata de um novo 
cliente; procura um carrinho de compras com o ID 12343. O carrinho de compras (lista) é aberto 
e o brinquedo selecionado é inserido na lista. O servidor envia, então, uma outra resposta ao 
comprador para informar o preço total e pedir a ele que efetue o pagamento. O comprador fornece 
informações sobre seu cartão de crédito e envia um novo pedido com o ID 12343 com o valor do 
cookie. Quando o pedido chega ao servidor, ele vê novamente o ID 12343 e aceita a encomenda 
e o pagamento, então envia uma confirmação na resposta. Outras informações sobre o cliente são 
armazenadas no servidor. Se o cliente acessar a loja no futuro, enviará o cookie novamente; a loja 
recuperará o arquivo e terá todas as informações sobre aquele cliente. 
Armazenamento temporário na Web: servidor proxy
O HTTP suporta servidores proxy. Um servidor proxy é um computador que mantém cópias de res-
postas a pedidos recentes. O cliente envia uma requisição HTTP ao servidor proxy, que verifica seu 
cache (memória de armazenamento temporário). Se a respostanão estiver armazenada no cache, o 
servidor proxy envia a solicitação para o servidor correspondente. Respostas recebidas são enviadas 
para o servidor proxy e armazenadas para futuras solicitações de outros clientes.
O servidor proxy reduz a carga no servidor original, diminui o tráfego e melhora a latência, 
mas, para usá-lo, o cliente deve ser configurado para acessar o proxy e não o servidor de destino.
Perceba que o servidor proxy funciona como servidor e cliente. Quando ele recebe de um 
cliente um pedido para o qual tem uma resposta, ele atua como um servidor e envia a resposta para 
o cliente. Quando recebe de um cliente um pedido para o qual ele não tem uma resposta, e primeiro 
atua como um cliente e envia um pedido para o servidor-alvo. Após a resposta ser recebida, ele atua 
novamente como um servidor e envia a resposta para o cliente.
Localização do servidor proxy
Os servidores proxy costumam ficar localizados no lado do cliente. Isso significa que podemos ter 
uma hierarquia de servidores proxy, como mostrado a seguir: 
1. Um computador cliente pode também ser usado como um servidor proxy, com pequena 
capacidade, que armazena as respostas às solicitações frequentemente feitas pelo cliente. 
2. Em uma empresa, um servidor proxy pode ser instalado na LAN para reduzir seu tráfego 
de entrada e saída. 
3. Um ISP com muitos clientes pode instalar um servidor proxy para reduzir o tráfego de 
entrada e saída na rede daquele ISP. 
 Exemplo 2.10
A	Figura	2.16	mostra	um	exemplo	de	uso	de	um	servidor	proxy	em	uma	rede	local,	tal	como	uma	rede	em	um	
campus	ou	em	uma	empresa.	O	servidor	proxy	está	 instalado	na	rede	 local.	Quando	uma	solicitação	HTTP	é	
criada	por	qualquer	um	dos	clientes	(navegadores),	o	pedido	é	primeiramente	direcionado	para	o	servidor	proxy;	
58 Capítulo 2 Camada de aplicação
Figura 2.16 Exemplo de um servidor proxy.
seestejátemapáginaWebcorrespondente,enviaarespostaaocliente.Casocontrário,oservidorproxyfun-
cionacomoumclienteeenviaopedidoaoservidorWebnaInternet.Quandoarespostaédevolvida,oservidor
proxycriaumacópiadelaeaarmazenaemseucacheantesdeenviá-laparaoclientesolicitante.
Atualização de cache
Uma questão muito importante é quanto tempo uma resposta deve permanecer no servidor proxy 
antes de ser eliminada e substituída. Várias estratégias diferentes são usadas para essa finalidade. 
Uma solução é armazenar a lista de sites cuja informação permanece inalterada por algum tempo. 
Por exemplo, uma agência de notícias pode mudar sua página de notícias todas as manhãs. Isso 
significa que um servidor proxy pode receber as notícias no início da manhã e mantê-las até o dia 
seguinte. Outra recomendação é adicionar alguns cabeçalhos para mostrar o instante da última mo-
dificação das informações. O servidor proxy pode, então, usar as informações contidas no cabeçalho 
para estimar por quanto tempo a informação pode ser válida.
SegurançadoHTTP
O HTTP em si não fornece segurança. Entretanto, como mostraremos no Capítulo 10, o HTTP pode 
ser executado sobre a Camada de Sockets Segura (SSL – Secure Layer). Nesse caso, o HTTP é 
denominado HTTPS, que fornece confidencialidade, autenticação do cliente/servidor e integridade 
dos dados.
 
Servidor
Web
Servidor
Web
Servidor
Web
Servidor
Web
Cliente Cliente Cliente
Servidor
proxy
WAN
Rede local
Internet