Redes de Computadores e a Internet - James F. Kurose, Keith W. Ross - 5ªEdição.pdf

bowAttooico.

REDES DE COMPUTADORES E A INTERNET S' edição

KUROSE ROSS

----PEARSON

Companion

Website

bowotto4ico.

bow4tto4ic~

REDES DE COMPUTADORES E A INTERNET S'ediçiio Uma Abordagem Top·Down

PearsonEducation

EMPRESA CIDAD ~

bowotto4ico.

bow4tto4ic~

KUROSE • ROSS

REDES DE COMPUTADORES E A INTERNET 5 e dição 1

Uma Abordagem Top-Down

Tradução Opporwnil)' Tr
Revisão Té<:nlc.a Wc1gner Lvil Zucclti Professor Doutor do Departamento de Sistemas Eletrônicos da Escola Politécnica da Universidade de São Pau los

----PEARSON São Paulo

Brasil

Argen tina

Colômbia

Costa Rica

Chile

Espanha

Guatelamala

México

Peru

Porto Rico Venezuela

bow4tto4ic~

() 201 O Pearson Education do Brasil Título original: Computer networking: a top-dmvn appmacl1 (eaturing lhe fnwrnet, fifth editio11 () 201O Pearson Education, Inc. Traduc;Jo autorizada a partir da edição original em ingl&s, publ1cada pela Pearson Education, Inc., sob o selo Addison Wesley. Todos os di reitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou transmitida de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de sistema de arm.11cnamento c transmiss;io de informaç~o, sem prévia autori1-aç.io, por escrito, da Pearson Eduution do Brasil.

Diretor editorial: Roger Trimer Cerente de editorial: Sabrina Cairo Supervisor de produção editori,JI: Marcelo Françozo Editoras: G4lbriela Trevisan e TI1elma l~abaoka Revisão: Ma ri a Aiko Nish ijima C.1p.1: Casa de Idéias, sobre projeto origina l de Joyce Cosentino Wells fmagem de capa: O Reutersljean-Phillipe Arbs/Londres ldícoraçiio eletrônica: Casa de Idé ias

Dados Internacionais de Catalogação na Publicação (CIP} (Câmara Brasileira do l iv ro, SP, Brasil) Kvrose, James F. Redes de computadores e a Internet : uma abordagem top-down I James F. Kurose e Keith W. Ross ; tradução Opportunity translations ; revisão técnica Wagner Zucchi. •• 5. ed. - S.io Paulo: Addison Wesley, 2010. Tíwlo original: Computer networking fifth edition a top·down approach featuri ng the Internet. Bibliografia. ISBN 978-85·88639· 97· 3 I. Inte rne t 2. Redes de computadores I. Ross, Keith W. 11. Titulo. CDD-004.67

09· 10003 indices para catálogo sistemático:

I. Internet : Redes de computadores : Processamento de da dos 004.()7

2009 Direitos exclusivos para a língua portuguesa cedidos à Pearson Eduution do Brasil, uma empresa do grupo Pearson Education Av. Ermano Marchetti, 1435 CEP: 05038-001 , São Paulo - SP Fone: (11) 21 78-8686 - Fax: (11) 2178-8688 e-mail: [email protected]

bowotto4ico.

Pcmtjulic c nossas trls J>rCCiosiclculrs: Cl1ris, Charlic c Ninei

JFK

l'mcr miultct mMcwilllosa esposa Vt'roniqur

c 11ossas três filhas: Ctcilc, Clah·c r Katic KWR

bowotto4ico.

bow4tto4ic~

Sumário

Capitulo 1 Red es d e computadores e a lntemet ...................................................................... 1 1.1 O que~ a hucnlct? .................................................................................................................................2 1. 1.1

1.2

1.3

l .4

1.5

Uma descrição dos componentes da rede ................................................................................... 2

1.1.2

Uma dcscnção do sçrviço ...........................................................................................................4

1.1.3

O que é um protocolo? ...............................................................................................................5

A pcrircna da lntcmet ............................................................................................................................. 7 1.2.1

Programas clientes c set'\-;dorcs .................................................................................................. 7

1.2.2

Redes de acesso ..........................................................................................................................8

1.2.3

Mc•os fisicos .............................................................................................................................. l6

O nüclco da rede ................................................................................................................................... 18 1.3.1

Comutação de circuitos e comutação de pacotes ..................................................................... 18

1.3.2

Corno os pacotes percorrem as redes de comutadores de pacotes? ........................................24

1.3.3

ISPs c b:u:kboncs da lntcrneL ..................................................................... ...............................25

i\ traso, perda e vazão em redes de comutação de pacotes .................................................................... 26 1.4.1

Uma visl'lo geral ele atraso em redes de comutação de pacote:s .................................................27

1.4.2

Atraso de nla c perda de pacote ................................................................................................29

1.4 .3

Atraso fim n fim ........................................................................................................................31

1.4 .4

Vaz~io

nas redes de computadores ................................... .........................................................33

C:1madas de protocolo e seus modelos de serviço ................................................................................ 35 1.5.1 Arquitetura de camadas ............................................................................................................35 1.5.2

Mensagens, segmentos, datagramas e quad ros ......................................................................... 40

1.6

Redes sob ameaça ..................................................................................................................................41

1.7

I hs tóna das redes de computadores e da Lntemet ................................................................................45 1.7 . I

Descnvolvimcmo da comutação de pacotes: 1961-1972 ..........................................................45

1.7.2

Redes proprietárias e trabalho em rede: 1972-1980 .................................................................46

1.7.3

Prolircraç;\o de redes: 1980-1990............................................................................................. .47

bow4tto4ic~ Redes de com putod ores e o Inle;.; r n;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

1.8

1.7.4

A explos:\o da Internet: a dé~-ada de 1990 ................................................................................-18

1.7.5

Desenvolvimentos rcccntes .......................................................................................................49

Resumo ..................................................................................................................................................so

Capítulo 2 Camada de aplicação ............................................................................................. 6 1 2.1

Prmcípios de aplicações de rede ...........................................................................................................61

2.1. 1 Arquheturas de a plicação de rede .............................................................................................62 2. 1.2 Comunicaç-Jo entre processos ................................................................................................... 64 2. 1.3 Serviços de transporte disponíveis para aplicações .................................................................66 2.1.4 Serviços de transporte providos pela lmernet ..........................................................................68 2. 1.5 Protocolos de camada de aplicação ...........................................................................................71 2. 1.6 Aplicações de rede abo rd adas neste livro .................................................................................72 2.2 A Vvcb c o 11TTP ......................................................................................................................... ..........72 2.2.1 Dcscriçilo gemi do HTTP .......................................................................................................... 72 2.2.2 Conexões persistentes e não persistentes ................................................................................. 74 2.2.3 Formato da mens.'lgem HTTP ................................................................................................... 76 2.2.4 lntcra(,'fto usuário-servidor: cookies ..........................................................................................80 2.2.5 Cachcs Wcb ..............................................................................................................................81 2.3 2.4

2.5

2.6

2.7

2.8 2.9

2.2.6 GET condicional .......................................................................................................................84 Transferência de arquivo: FTP ..............................................................................................................85 2.3.1 Comandos c respostas FTP .......................................................................................................87 Correio cletrOnico n:~ Internet ..............................................................................................................87 2.4.1 SMTP .........................................................................................................................................89 2.4.2 Comp;1rnçilo com o HTTP.........................................................................................................91 2.4.3 Fonnatos de mcns.1gem de c:orreio e MlME .............................................................................92 2.4.4 Protocolos de ;~cesso ao correio ................................................................................................92 DNS: o serviço de diretório da Internet ................................................................................................96 2.5. 1 Serviços fornecidos pelo DNS ...................................................................................................96 2.5.2 Visao gcrnl do modo de funcionamento do DNS .....................................................................98 2.5.3 Registros c mensagens DNS .................................................................................................... J02 ApiKaçOes P2P .................................................................................................................................... 1Oó 2.6. 1 Dis tribuiçilo de arquivos P2P ....................................................... ...........................................107 2.6.2 Ois trlbuted 1-tash Tables (OHTs) ............................................................................................ 111 2.6.3 Estudo de caso: telefonia por I ntcrnct P2P com Skypc .......................................................... 115 Progmmação c desenvolvimen to de aplicações com TCP ...................... ............................................ 116 2. 7.1 Progmmar."do de aplicações com TCP ..................................................................................... 11 7 2.7.2 Um exemplo de aplicaçflo cliente-servidor emJ:tva ............................................................... ll8 PrognunaÇt1o de sockets com UOP ...................................................................................................... 123 Resumo ................................................................................................................................................ 129

Capitulo 3 Camada de transporte ......................................................................................... 140 3.1

Introdução e serviços de camada de transporte .................................................................................. l40 3. 1.1

Relação entre as camadas de trnnsporte e de rede .................................................................. 142

3.1.2

Visão geral da camada de uansporte na Internet ................................................................... 143

bow4tto4ic~ Sumário

3.2

IX

Multlplexaç-.lo c demultíplexaç;\o........................................................................................................ l44

3.3 Transporte m\o orientado para conexão: UDP.................................................................................... 150 3.3.1

Estrutura do segmcmo UDP ................................................................................................... 152

3.3.2 Soma de vcrificaç;lo UDP ........................................................................................................ 153 3.4

Princ1píos da transfe rfncia cottfiávcl de dados ................................................................................... l 54 3.4.1

Construindo um protocolo de transferência confiável de dados ............................................ 155

3.4.2

Protocolos de transfcrcncia confiá,•cl de dados com paralelismo .......................................... 163

3.4.3

Go-Back-N ............................................................................................................................... 166

3.-+.4

Rcpc t iç~o

seletiva (SR) ............................................................................................................ 170

3.5 Transporte orientado pa ra conexão: TCP ........................................................................................... 174 3.5. 1 A COIICXl'IO TCP ....................................................................................................................... 174

3.6

3.5.2

Estr utura do segmento TCP .................................................................................................... l 76

3.5.3

E.'ltimativa do tempo de viagem d e ida e volta c de esgot;uue tllo de tcmporizaç:\o ............... l80

3.5.4

Transferfncia confh\vcl de dados ............................................................................................ l 83

3.5.5

Cont role de nu xo .................................................................................................................... 189

3.5.6

Gerenciamento da conexão TCP............................................................................................. L90

Príndpios de controle de congestionamen to ...................................................................................... l 96

3.(>.1 t\s causas c os custos do congestionamento ........................................................................... 196 3.6.2

Mecanismos de controle de congestionamemo ......................................................................201

3.6.3

Exemplo dt controle de congestionamento assistido pela rede: controle de congcstionamcmo ATM ABR............................................................................................. 202

3.7

Con trole de congestionamento no TCP ..............................................................................................203 3.7. 1 Equidade..................................................................................................................................210

3.8

Resumo ................................................................................................................................................ 213

Capitulo 4 A ca m a d a de red e ................................................................................................ 228 4.1

lntroduçl'lo ........................................................................................................................................... 229 4. 1. 1 Repasse e ro teamento ...................................................... ........................................................ 229 4.1.2

4.2

Modelos de serviço de rede ..................................................................................................... 232

Redes de circuitos virtuais e de d atagramas ........................................................................................ 234 4 .2.1 Redes de circuitos virtuais ..................................................................................................... 234

4.3

4.4

4.2.2

Redes de d:nagm mas ............................................................................................................... 236

4.2.3

Origens das redes de circuitos virtuais c d e datagrnnms ........................................................ 238

O que há den tro de um roteador? .......................................................................................................239 4.3. 1

Port:1s de emrada.....................................................................................................................240

4.3.2

Elemento de comutaç;lo ..........................................................................................................242

4.3.3

Port:IS de saida......................................................................................................................... 244

4.3.4

Onde ocorre formação de fila? ................................................................................................244

O Protocolo da lmernct ( IP): repasse c endereçamen to na lntcrnet. .................................................247 4.4. 1 Formato do datagrama ............................................................................................................ 247 4.4.2

Endereçamento 1Pv4 ................................................................. ..............................................252

4.4.3

Protocolo de Mensagens de Controle da lmerncl (ICMP) .................................................... 262

bow4tto4ic~ Redes de com putod ores e o Inle;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

4.5

4.4.4

1Pv6 ......................................................................................................................................... 265

4.4.5

Uma breve invcsúd a em scgumnça IP ....................................................................................269

Algoriunos de rotcamento ................................................................................................................... 270 4.5. 1 O algontmo de ro teamento d e estado de enlace (LS) ............................................................273

-1.6

4.7

4.8

4.5.2

O algontmo d e ro teamento d e vetor de disu\ncias (DV)........................................................ 276

4.5.3

Roteamento híerárqutco .......................................................................................................... 282

Roteamento na lntcrnct ....................................................................................................................... 285 4.6.1

Roteamento ítum-AS na Internet: RIP .................................................................................... 285

4.6.2

Roteamento intm-AS na Internet: OSPF ................................................................................. 288

4.6.3

Roteamento externo" sistemas autônomos: BGP................................................................... 290

Ro teamento broaclcast e rnuhi cast .......................................................... ............ ................................295 4.7. I

Algoritmos de roteamento broadcast ............................................................. ,........................ 296

4.7.2

Multlcast ..................................................................................................................................300

Rcs umo ................................................................................................................................................305

Capitulo 5 Camada de enlace e redes locais ......................................................................... 3 ) 8 5. 1

5.2

5.3

Camad:~

de enl:tcc: introdução e serviços ...........................................................................................318

5.1.1

Os scrvi\'OS fornecidos pela camada de cnlacc........................................................................319

5. 1.2

Onde a

carn:~da

de enlace é implementada? ...........................................................................32 1

Técnicas de clctecç;\o c corre\"âO de erros ...........................................................................................323 5.2. I

Vcrific;lÇões de paridade .........................................................................................................32-4

5.2.2

Métodos de soma de verificação .............................................................................................326

5.2.3

Verificação de rc:dundãncia cíclica (CRC) .............................................................................. 326

Protocolos de acesso múltiplo .............................................................................................................328 5.3. 1 Protocolos de divisão de canal ................................................................................................330

5.4

5.5

5.3.2

Pro tocolos de acesso aleatório ................................................................................................331

5.3.3

Protocolos de rcve;tamcnto ..................................................................................................... 336

5.3.4

Redes loe11is (Li\. s) ................................................................................................................ 337

Endereçamento na camada de enlacc.................................................................................................. 338 5.4. l

Endereços MAC ...................................................................................................................... 338

5.4.2

ARP ( protocolo de resolução de endereços) ........................................................................... 339

Eth crnct ...............................................................................................................................................343 5.5. l

[;strutum do quadro Ethcrnct .................................................................................................344

5.5.2

CSMNCD: o protocolo de acesso múltiplo da Eth cm ct ........................................................346

5.5.3

Tecnologias Ethernet ..............................................................................................................349

5.6 Comutadores de camada de enlace ......................................................................................................35 1 5.6.1 Repasse c l'iltmgem.....................................................................................................................35 1

5.7

5.6.3

Propriedades de comutação da camada de enlace ..................................................................353

5.6.4

Comutadores versus roteadorcs ............................................................................................. .353

5.6.5

Rede local vi rtual

(Vinual Local Arca Nc tworkl) ....................................................355

PPP: o protocolo ponto a ponto ..........................................................................................................358 5. 7.1

5.8

(VL\~s

Enquadramento de dados PPP ............................................................................................... .359

Virtualização de enlace: uma rede como camada de enlace ...............................................................361


5.9 5. 10

XI

Um dia na vida de uma solícitaçào de página Web ............................................................................363 Resumo ..............................................................................................................................................367

Capítulo 6 Redes sem fio e redes móveis ............................................................................... 3 77 6. 1

lntroduç-lo ...........................................................................................................................................378

6.2

Carnctcrlsucas de enlaces e redes sem Íto ...........................................................................................380 6.2. 1 COMA ..................................................................................................................................... 383

6.3

\Vi-F•: LANs sem fio 802.11 ............................................................................................................... 385

6.3. 1 A arquitelurn 802.11 ...............................................................................................................387 6.3.2 O protocolo MAC 802. 11 .......................................................................................................389 6.3.3 O quadro IE EE 802.11 ............................................................................................................394 6.3.4 Mobilidade na mesma sub-rede IP.............................................. ............................................39ó

6.4

6.3.5

Recursos Avançados em 802.11 ... ,.............................................. ............................................397

6 .3.6

M;~is

Acesso cel ular ;\ lnlcrnet .....................................................................................................................401

6.4.1 Uma 6 .5

além de 802. 11: Bluctooth c \ViMAX .............................................................................398 vi~\o

geral da arquitemra celular ................................................................................... 402

Gerenciamen1o da mobilidade: princípios .......................................................................................... 405

6.5. 1 Endercc;amcn1o .......................................................................................................................407 6 .5.2

Rolcamento para um nó móvcl ............................................................................................... 409

6.6

IP móvel. ..............................................................................................................................................412

6.7

Gerenciamento de mobilidade em redes cclularcs ................................................................................ l5 6. 7. 1

Rateando chamadas para um usuário móvel ............................................................................ 17

6.7.2 Transrcréncias em

GS~I

(handoffs) ........................................................................................ 418

6.8 Sem f'l o c mobilidade: impac1o sobre protocolos de camadas supcriorcs ...........................................420 6.9 Resumo ................................................................................................................................................422

Capítulo 7 Redes multintídia ................................................................................................. -428 7.1

7.2

7.3

Aplicações de rede multimfd ht ............................................................................................................ 429 7.1. 1

Exemp los de aplicaçocs muhimfdia ........................................................................................ 429

7. 1.2

Obstáculos para a multimídia na Internet de hoje ................................................................. 431

7. 1.3

Como a Internet de,•eria evoluir

7. 1.4

Comprcss;'lo de áudio c vfdeo ................................................................................................. 433

par:~

dar melhor suporte à mu ltim ldía? ............................. 432

Áudio e vldeo de fluxo comfnuo armazenados................................................................................... 43ô 7.2.1

i\ ccsso a ;ludio c vldco por meio de um servidor Wcb ......................................................... A3ó

7.2.2

Envio de multímldia de um servidor de fluxo com lnuo a uma apli caç('lo ;1Uxill:1r ................ 437

7.2.3

RTSP (protocolo de fluxo continuo em temp o real) .............................................................. 439

Fazendo o melho r possivel com o serviço de melhor esforço ............................................................ 442 7.3.1

As limitações de um scn•iço de melhor esforço .....................................................................442

7 .3.2

Eliminaç.1o da variaç-Jo de atraso no receptor para áudio ...................................................... 444

7.3.3

Recupcrnç-lo de perda de pacotes ........................................................................................... 447

7.3.4

Distribuição de mulúmídia: redes de distribuição de come(•do............................................ .449

7.3.5

Di mcnsionando Redes de melhor desempenho para rornecer um serviço de qualidade ....... 452

bow4tto4ic~ Redes de com putod ores e o Inle;.; r n;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

7.4

7.5

Protocolos para aplicações Interativas em tempo real ........................................................................-+53 7.4.1

Protocolo de tempo real ( RTP) ............................................................................................... 453

7.4.2

Protocolo de controle RTP (RTCP) ....................................................................................... 456

7.4.3

SIP ........................................................................................................................................... 458

7.4.4

1-1.323 ....................................................................................................................................... 463

Fornecendo classes de scviço múltiplo ............................................................................................... 46i 7.5. 1 Cenários motivadores ................................................................................................................ 465 7.5.2

Mecanismos de escalonamento c rcgulaÇào ............................................................................468

7.5.3 Dirrscrv ...................................................................................................................................... 474 7.6

Fornecendo garantias de qualidade de serviços...................................................................... ............ 478 7.6. 1 Um exemplo molivador .................................................................................... ........................ 478 7.6.2 Reserva de recurso, admissão de chamada c configumç•\o de chanmda .................................. 479 7.6.3

7.7

QoS gum ntida na Internet: ln tscrv c RSVP ............................................................................. 482

Rcs umo ................................................................................................................................................483

Capitulo 8 Segurança em redes de computadores ...................................................... ........... 492 8 .1 O que é segurança na rede? ................................................................................................................493 8.2

Prinefpios de crip10gmfia .................................................................................................................... 494

8.2. 1 Criptogrol'ia de ch;wes simétriC3S ...........................................................................................495 8 .2.2 8 .3

Criptograf'ia de chave públíc:a .................................................................................................500

lntegndadc d e mensagem c autenticação do ponto f'inai.. ..................................................................S04 8.3. 1 Funções de hash criptogrãf'icas ...............................................................................................S05 8.3.2

Código de autemicaç-.lo da mcnsagcm ....................................................................................506

8 .3.3

Assr n:uuras digitais ................................................................................................................. 507

8 .3.4 8 .4

Autcnt ica~o d o

ponto f'inal ................................................................................................... 512

Protegendo o c-mail ............................................................................................................................ 516 8.4. 1 E-mail seguro ..........................................................................................................................517 8.4.2

8.5

PGP .......................................................................................................................................... 520

Protegendo conexões TCP: SSL .......................................................................................................... 521 8.5. 1 Uma vís.'lo abrangcruc ............................................................................................................. 522

8.5.2 Uma visão nmis completa ....................................................................................................... 524 8.6

Segu r;mç~

na camada de rede: 1Pscc e redes vinuals privadas ...........................................................526

8.6.1 IPsec c red es vi rt uais pri\•ada.o; (VPNs) ................................................................................... 526 8.5.2

Os protocolos AH e ESP ..........................................................................................................527

8.6.3

Associações de segurança ....................................................................................................... .527

8 .6.•1 O datagrama 1Pscc...................................................................................................................528 8.6.5 8.7

8 .8

Gerenciamento de chave no IPsec ..........................................................................................531

Segumnça em LANs sem f'io ................................................................................................................S3 1 8 .7. 1

Privacrdade Equivalente Cabeada (WEP) ...............................................................................532

8 .7.2

IEEE 802.111 .......................................................................................................................... .533

Segurança opcraciomrl: l'irc""JIIs c sistemas de dctccç.lo de

inv<~Sào ................................................. .535

8 .8. 1 Fircwalls .................................................................................................................................. 535 8.8.2

8 .9

Sistemas de detecção de intrusos ........................................................................................... .540

Resumo ............................................................................................................................................... .544


XII I

Capitulo 9 Gerenciamento de red e ........................................................................................ 553 9. 1 O q ue é gerenciamento de red e? ........................................................................................................ .553 9.2 A inrrnestrut ura do ge renciamento de rede ....................................................................................... .556 9.3

A estru1urn d e gerenciamento padrJo da Imerne1..............................................................................560 9.3. 1

$~11

(Estruturo d e lnrormações de Gerenciamento) ...............................................................561

9.3.2 Base de ínrormações de gcrenciamcnto: Ml8.......................................................................... 564 9.3.3

Op<:rnçõcs do protocolo SNMP c mapeamentos de trnnsportc .............................................. 565

9.3.4

Scgu ra nçn c admin is~rnçào ...................................................................................................... S68

9.-t

ASN.I ................................................................................................................................................... 570

9.5

Conclusdo ............................................................................................................................................ 574

Referências ........ ................ ..................................................................................................... 578 indice ................................. ............... ........................ ..................................................... ......... 603 Sobre os autor es ..................................................................................................................... 615

bowotto4ico.

bow4tto4ic~

Prefácio

B

em-vindo 1\ quinta cdiçi\o de Rrdes clt computa(/ons e a ln tl'm t l : 1111111 abordagem cop-tlowu. Desde a publiC':lç-3o da primeiro cdiç;\o, M nove anos, nosso livro foi adowdo em centenas de un iversidades c instituições de ensino superior, traduzido pammais de dez id1omas c utilizado por ma1~ de cem nul l'Studilntes e profiss ionais no mu ndo inteiro. Muitos desses leitores entraram em contato conosco c fiC:l mos cxtrcm:uncntc satisfeitos com sua reaçdo positi\"a. Acreditamos que um;1 importante razão para esse sucesso é que o livro oferece uma abord:~gem moderna do ensino de redes de computadores. Vcxt poderia perguntar: por que é necessária uma abordagem moderna? . os llltimos anos, testemunhamos duas mudancas rcvoluciom\rias no l'3rnpo das redes - mudanças que não cslào renctidas nos livros sobre o assumo publicados entre as décadas de 1980 c 1990. Em primcíro lugar. a Internet dominou o universo das redes de computadores. Atualmen te. em qualquer discuss.'lo séria sobre redes. é obrigatório ter a Internet em mente. Em segundo lugar. o maior crescimento nessa área ocorreu no :\mbito dos serviços e das aplicações, o que pode ser confirmado pelo desenvolvimento da Wcb, pela utilização dos serviços de e-mail por milhares de usuários ao mesmo tempo, pela reccpç;\o de áudio e vldeo, pelo telefone por Internet, pelos scn·iços de m('nsagcrn instantãn(':l, pdas aplicações P2P c pelo comércio ('ICtrõnieo.

Quais são os novidades desta quinto edição? Fizemos mutl:mças nesta quinta edição, mas mantive mos Inalterados os ttspe~: tos que acreditamos ser (c os professores c estudantes que utilizaram nosso li\'ro c:onrlrmaram) os mais importantes deste livro: a abordagem top-down, o roco n:1 In ternet, a menção que demos aos princípios, à prática c sua abordage m e aos estilos acessíveis do ensino de redes de computadores. Contudo. Ozcrnos muitas mudanças significati vas nesta edição. lnlcl:mdo pelo Caprtulo 1, atualizamos a in uoduç;lo rdcremc a redes e atualizamos c expandimos noss.1 ::~bordagcm sobre redes de acesso (particularmente, o uso de redes a cabo, OSL c fiber-to-the-horne corno redes de acesso :\ Internet pliblic:1). No Capítulo 2, retiro mos o material sobre a pesquisa ponto a pomo que se tornou rora de uso para d:u esp.1ço a uma nova seção sobre d1stnbutcd hash tables. A apresentação do contro le de congestionamento TCP no Capítulo 3 é agora baseada em uma representaç;'\o gmfka (máquina de estado fimto) de TCP. estnuurando c esclarecendo nossa abordagem. O Olprtulo 5 roi estendido significati\·amente. com seções novas sobre as redes locais virtll
bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------c:1pflulos. No Capitulo 6, rerno,•cmos um pouco da "sopa de lctrlnhas~ de padrões c protocolos da telefonia celular c acrescentamos unm nova scçJo sobre a arquitetura de redes de celular e como a rede de celular e a Internet operam em COIIJUIIIO para prover serviços da Internet a a pRrelhos móveis como o Blackbcrry c o iPhonc. ossa abordagem sobre a scguranç;1 da rede, no Capfwlo 8, sofreu uma rcvislo signilka uva. O conteúdo sobre a autcntica<;:io do ponto de chegada, encadeamento de blocos de cifras c criptograna da chave pública foi revisado, c o material sobre o IPsec foi reescrito e estendido para incluir as redes vtrtuais privadas (VPNs, do ingl~ virtual pnvatc n ctworks). Ao longo de todo o lhrro, incluímos exemplos modernos c refertncms atualizadas.

Público ·oIvo Este livro destina-se a um estudo inicial de redes de computadores. Pode ser usado em cursos de cicncia da computação c de engenharia elétrica. Em termos de linguagem de programação, requer q ue os estudantes conheçam :~s linguagens C, C++ ottjava (mas apenas em <1lguns lug
Oque há de singular neste livro? O as:.unto rede de computadores é bastantt vasto e complexo c envolve muitos conceitos, protocolos c tecnologias que se cntrelaç;un inexuícavelmentc. Para dar coma desse escopo c complcx1d:tde. muitos li\'l'OS sobre redes são, em geral, organizados de acordo com as ~camadas· de uma arquitetura de rede. Com a org;mizaç:io em camadas, os estud:mtes podem vislumbrar a complexidade das redes de computadores - eles aprendem os conceitos e os protocolos diStintos de uma parte da arquitetura c. ao mesmo tempo. \1Suahzam o grande quadro da interconcxiio entre as camadas. Do ponto de vista pedagógico, nossa cxpcrifncia pessoal connnna que css:\ abordagem em camadas é, de f:~to, muito bo01. Entretanto, achamos que a abordagem tmdtcional, a bouom-upda camada frsica para a camada de aplicaç-.1o - . n:lo é a melhor abordagem pam um curso moderno de redes d e computadores.

Uma abordagem top·down Na primeira edição, propusemos uma inovação adotando uma \•ls.'\o top·down l-amada de aplkaç:\o c descendo até a camada física.

Isto é, começando na

A abordagem top-down orerece diversos benerfeios importames. Em primeiro lugilr, o livro dá enfasc à cam:1da de apli<:ação. que tem sido a área de ·gr<'ndc crescimento~ das red es de computadores. De fmo, muitas das recen tes revoluções nesse ramo- incluindo a \Veb, o cornpartilhamcmo de arquivos P2P c o nuxo continuo de mldi:1 - tivera m lugar nessa camada. Essa abordagem ele ênfase inicial à camada de :1plicaç:\O é diferente das seguidas por muitos outros lh·ros, que têm apenas pouco material sobre aplicações de redes, seus requisitos. paradigm:1s da camada de aplícaç-.lo (por exemplo, clieme-servidor c ponto a ponto) c interfaces de programaçr•o d e aplicação. Em segundo lugar, nossa experiência como professores (c a de mui tos outros que utilizaram este li\'ro) connrma que ensinar a plicações de rede logo no infcio do curso é uma poderosa ferramenta moti\"adora. Os estudantes Ocam mais entusiasmados ao aprender corno funcionam as aplicações de rede- aplicações como o e-mail c a Wcb, que a maioria deles usa diariamente.. Entendendo as aplicações, o estudante pode cmcndcr os serviços de rede necessários ao suporte de tais aplirnçõcs. Pode tam~m . por sua \'CZ, examin:~r as ,·árias maneiras como esses serviços são fornecidos c implementados nas camadas mais baixas. Assm1, a discussão das aplicações logo no início fornece a motivação necessária para os demais assuntos elo livro. Em terceiro lugar, essa abordagem top-down habilita o professor a apresentar o desenvolvimento de aplicações de rede no estágio inicial.

bow4tto4ic~ Prefócio

XVII

Os estudantes n:lo apenas vcem como funcionam aplícações c protocolos populares, como também aprendem que é fácil criar suas próprias aplit"ações c protocolos de aplicaç-.\o de rede. Com a abordagem top-
Um foco no Internet Continu:unos a ut ilizar a arquiteturn e os protocolos da lntcrnet corno veículo pmnorelial p:tra estudar conceitos fundamemals de redes de computadores. É claro que t:un bêm inelufmos conceitos c protocolos de omr:LS arqultCtltr.\S de rede. Mas os holofotes estão claramente dirigidos:'\ Internet, fato rene tido na orga niza~·ào elo livro, que gim em torno da arqui tctum de cinco t:arnadas ela Internet: aplícaç;lo, transporte, rede, enlace e física. OlHro bcneffcio de colot<1r a I ntcrnct sob os holofotes é que a maioria dos est udantes de ci~ncia d<~ compuwç:\o e de engenharia elétrica está ávida por conhecer a Internet e seus protocolos. r!lcs sabem que a Internei é uma tecnologia revolucionária c inov:1dora c podem constatar que da es tá provocando uma profunda transformaçao em nosso mundo. Dada a enorme releviincia da Internet, os eswdantes cst:lo nnturnlmcnte curiosos em saber o que h:\ por tr.is dela. Assim, fic-.t f:lcíl para um professor manter seus ;~I unos interessados nos princípios básicos, usando a Internet como guia.

Ensinando princípios de rede Duas das caractcnsucas exclusivas deste livro -sua abordagem top·do\m c seu foco na Internet- aparecem no tflulo c submulo. Se pudéssemos. teria mos acrescentado uma tcrcclrn palavm ao subtítulo- principios. O campo d:lS redes agom está suficientemente maduro para que uma quamidadc de assuntos de importância fundamental possa ser 1denuficada. Por exemplo, na camada de transporte, cmre os assuntos importames esu'lo a comunicação confiá,·el por uma catnada de rede não confiá,•cl. o estabclecimcntolenccrramento de conexões c mútua aprescntaç;'lo, o controle de congestionamento c de Ouxo c a muhiplcxaçilo. Na camada de red e, dois assuntos muito import.1ntcs s:lo: como determinar "bons" caminhos entre dois roteadores c como intcrconectar um grande n(unero de redes hcterogcncas. Na camada de enlace. um problema fundamental é como cornpanilltar um canal de acesso múltiplo. N:t segurança de rede, técnicas para prover sigtlo, autenticaç'lo e integridade de mensagens s.'\o bascad:ts em fundamentos da criptografia. Este livro identifica as questões fundamcmais ele redes c s os padrões c protocolos de rede de hoje tornarem-se obsoletos, os prindpios que ele incorpora continuarão importantes e releva ntes. Acrcdit:11nos que o uso da Internet para apre-se ntar o assunto aos estudantes e a t:nrasc dada 11 abordagem das questões c d
Material de apoio Comprion

Websitl

No si te de apolo do livro (www.aw.com/kurose_br) . proressores e cswdantcs podem acessar matenais adte1onais em qualquer dia, dur:lntc 2't horas.

Para professores: Fornecemos um pacote de suplementos para amdliar o ensino do conteúdo deste h vro. Manual de soluções (em ingl~). O site do livro oferece um manual de soluções, em mgl~. para os exercícios apresentados ao final de cada capítulo.

bow4tto4ic~ Redes de computadores e o lnte ;.;rn;.;e;.;.t_________________________

Aprcscmaçôes em PowcrPoim. O sitc do livro apresenta s lides em PowcrPoint para todos os nove capnulos. Os slides d<\o detalhes completos sobre cada capitulo e neles us:unos gráficos e animações - c não apenas marcadores- para tomar sua aula visua lmente interessante c atraente. Fornecemos os slidcs originais aos pro fessores para que eles poss;un personalizá-los do modo que mclhor a tenda às suas necessidades de ensino. Alguns desses slides foram fo rnecidos por professores que utilizaram nosso hvro em seus cursos. Material de aprendizagem interativo. O si te Web contém dtvcrsos applcts Java imcrativos, que animam muitos dos princip:tis conceitos de redes. O site também possui quizzes interativos que permitem que o aluno verifique sua compreensão básica sobre o assunto. Os professores podem completar essas c:aracterfsticas interativas com aulas ou usá-las como minilabs. Materi:ll tccníco adicional. Removemos a abordagem de alguns assuntos existentes para deixar o li vro com um \'O lume razoável. Por exemplo, para abrir espaço para o novo conteúdo desta edição, retiramos o m:nerial sobre as redes ATM c pesquisas ponto a ponto. Esse material pode ser encontrado no site Wcb do livro. Tarefas ele progranH.\ç;,o. O s ite Wcb também prov~ divc~s tardas de programaçJo detalhadas. que induem construir um servidor Web multitarefa, constr uir um cliente de e- nmil com uma interface GUI, progr-.unnr os lados remetentes c dc.s tínatliri os de um protocolo de transporte de d~dos conllávcl, programar um algoritmo de rotc.'lmcnto clis tribufdo c muito mais. Wircshark l:1bs. A comprecns;\o sobre protocolos de rede pode ser extremamente aprofundada ao o~rvá-los em ar;.lo. O sile \Vcb pro\'1:! dí\'crsas tardas Wiresh:trk que permitem que os eswdames observem a sequ~ncia ele mensagens trocadas cmrc duas entidades de protocolos. O sitc \.Veb inclui Wircshark labs distintos em l'ITTP. ONS, TCP, UOP, IP, ICMP. Ethernet, ARP, W1-Fi, SSL e no rastreamento de todos os protocolos envolvidos em satisf:tZcr a solicita~.;:io para buscar uma págin;l Wcb. ovos labs ser.lo adicionados com o tempo. Esse nrall'lral t de a>o CYclush·o poro professores e CSld prorcgulo por $('11/ra Para rrr ll(CSSO a t'l~. ex profrswres que ad01am o lh.ro dl'\cm cnrrar C'tll conraro com~~~ reprcSi!manre Pearwn ou em·lar e-maU pora tmhc!lilarios(i!pearsmred.com.

Para estuda ntes: Exercfctos on-li nc autocorriglveis. Teste seus conhecimentos com exercícios de múltipla escolha c, se quiser, envie o rcsu hado para seu professor.

Características pedagógicas Há quase 20 anos da mos aulas ele redes de computadores. Adicionamos n este livro uma experiência agregada ele mais de 45 anos de ensin o para milhares de estudantes. Durante esse perfodo, també m t>Mticipamos ativa men te na área de pesquisas sobre redes de computadores. (De fa to. J lm c Keith se conheceram qttando fazia m mestrado, frequentando um curso sobre redes d e computadores mi nistrado por Mischa Schwanz. em 1979, na Universidade de Colümbia.) Achamos q ue isso nos d:1 u ma boa perspectiva do que foi a rede e de qual será, provavelmente, seu futuro . Nào obstante, resistimos às ten tações de dn r ao material deste livro um viés que favorecesse nossos projetos ele pesquisa prediletos. Se voct csuver interessado em nossas pesquisas, consulte nosso sitc Wcb pessoal. Este li vro é sobre redes de computadores modernas - é sobre protocolos c tecnologias contemporJneas. bem como sobre os princlpios subj~lccntcs a esses protocolos c tecnologias. Também achamos que aprender (e ensinar! ) redes pode ser divertido. Esperamos que um certo senso de humor c a uti lizaçao de analogias e exemplos do mundo real que apa recem neste livro tornem este material ainda mais divertido.

bow4tto4ic~ Prefócio

X IX

Adendos, princípios na prática e segurança em foco O campo das redes de compumdores tem uma história rka c fascinante. Fizemos, neste livro. um esforço espcc.al para contar a história das redes de computadores, o qual se matcr.ahzou em uma sc~lo hislórica especial no Cap1tulo 1 c em 12 adendos históricos espalhados pelos demais cap1tulos. esses artigos históricos, apresentamos a invenc;Jo da comutaç-lo de p:~cotes. a evolução da Internet, o nascimento de importantes empresas gig:~ntes de redes, como a Cisco c a 3Com, e muitos outros e,·entos rcle,·antes. Os estudantes certamente se sentinlo estimulados por esses acontecimentos históricos. Em cada caprtulo, inclurmos um adendo especial que acentua um princ1pio importante de rede de computadores. Esses adendos auxiliarão o estudante a compreender alguns dos conc:citos fundamemais que esti\o sendo aplicados às redes modernas. Um pouco de nossa abordagem mais abrangente sobre segurança da rede aparece nos textos complementares · segurança em foco~ em cada um dos eaphulos principais deste livro.

Entrevistos Inserimos um:1 outra ctmctcrfstica odgimtl que inspiraram c rnotivanun os leitores- entrc,•istas com inovadores famosos no campo de redes. Apresentamos entrevistas com Leonard Klei nrock, Elram Cohen, Sally Floyd. Vi111on G. Ccrf, Slmon S. ltlm, Charlie Perkins, Hcnning Schulzrinne, Ste,•en M. Bcllovin c Jcff C.'lse.

O primeiro capitulo deste livro apresema um apanhado geral sobre redes de computadores. Com a introdução de muitos conceilos c tcmlinologias fundamemais, ele monta o cenário para o restante do li\•ro. Todos os outros capftulos dependem diretamente desse primeiro. Recomendamos que os professores, após o terem complet:~do. percorram em sequ<:ncia os caprtulos 2 ao 5, segumdo nossa Olosona top-down. Cad:t um dos cinco primeiros capftulos utiliza material dos capClUios prcccdcmes. Após ter com pletado os cinco primeiros caphulos, o professor terá bastante Oexibilidadc. Não há interdependência entre os quatro ultimos capCtulos, de modo que eles podem ser ensinados em qualquer ordem. Conhecemos profe-ssores que, após ensinar o capítulo introdutório, ensmam o Capítulo 5 e depois trabalham de baixo para cima, ou até mesmo professores que começam a ensinar pelo meio (Capítulo 4) e depo1s não seguem nenhuma ordem. Contudo. cada um dos quatro depende de material dos cinco primeiros. Muitos professores ensinam os primciros dnco cap11ulos c entào um dos quatro llhjrnos para arrematar.

Uma nota final: gostaríamos que vocês entrassem em contato conosco lncem ivamos professores c estudantes a nos enviarem e·mails (em inglês) com qualquer comentário que possam ter sobre o 11\·ro. Incentivamos os professores, tmnb~m. a nos enviar novos problemas (c soluções) que complementem os problemas existentes. Publkarcmos tudo isso no espaço para professores no site Web. Recomendamos aos professores c alunos que criem novas ap li<:açOes Java que ilustrem os c.:onccitos e protocolos apresentados neste livro. Se voe~ ti,•cr uma aplicação que j ulgue apropriada para este li ,rro, :tprcsemc-a, llOr gentileza, aos au tores (em inglês). Se a aplicação ( incluindo nota<;t\o c terminologia) for adequada, teremos o prazer de inclui-la no sitc Wcb do livro em ingles (www.aw.conv'kurose-ross), com a devida refer~ncia :1 seus autores. Não deixem de nos enviar URls imeressames ou de discordar de qualquer uma de nossas afirmações e nos inform:tr o que funciona c o que mlo funciona. Digam-nos, ainda, o que poderia (ou o que n11o deveria) ser inciUJdo na próxima cdiç'lO. Enviem seus e-mails para [email protected] c [email protected]. AI~ a data de publicaç~o deste li\•ro, todos os URLs mencion:~dos no texto csta\'õ\111 funcíonando. Devido ao caráter din11mico da Internet, porém, alguns d eles podem mudar ou deixar de existir. Para tentar encontmr os s itcs c mformaçOcs mencionados. use uma fermmcma de bltsca como www.googlc.com ou www.yahoo.com.

bowotto4ico.

bow4tto4ic~

Agradecimentos

esde o infdo deste projeto. em l996, muitas pessoas nos der;un inestimável auxilio e i nn uenciar:~m nossas ide ias sobre como melhor organizar e ministmr um curso sobre redes. Nosso MUITO OBRIGADO a todos os que nos ajudar:~m, sobretudo às cemenas de estudantes, acad~micos c: proHssionais que nos enviaram sugestões c comenta rios sobre as edições anreriores e sugestões pam futu ras edições deste livro. Nossos agradecimentos especiais par:~:

D

AI Aho (Columbm Univcrsily)

Vi nton Cerf (Googlc)

Hisha m Al-Mub;ud (Umvcrsity of Hous ton-Clcar Lakc)

Byung K)'U Choi (Michigan Tcchnologil-al Univcrsity)

Pratima Akkun oor (Arizona State Universh>•)

Const:mtine Coutras (Pace Univcrsity)

Paul Amer (U nh•crslly of Dclaware)

John Oaiglc (U nivcrsity of Mississippi)

Shamiul Azom (Arizona State University) ü chun llao (Univers ity of ulifornia at lrvine)

Edmundo A. de Souza c Silva (Universidade Federal d o Rio de Janeiro)

Paul Barford (Unh•crsity of Wisconsin)

Philippe Dccuctos (Eur!!com lnstitute)

Bobby Bhauacharjee (U niversit)' o f Maryland)

Chris lOphe Diot (Thomson Research)

Stcvc n Bcllovin (Columbia Univcrsity)

Pritllllla Dhu nghcl ( Polytcchnic lnslitutc of NYU)

Pravin

Bh~gwat

(Wibhu)

Supr.uik Bh:utaehuryya (previo usly at Sprint)

Bram Cohen (Bi tTorrcnt. Inc.)

Míchalis F::~ lo utsos (U niverslty of Callforni:J m Rivcrsidc)

Erns t Biersack (Eurécom lnstitute)

\Vu-chi Fcng (O rcgo n Graduatc lns titutc)

Shahicl Bokhari (U rtivcrsi t)' of Engineering & Tcehnology. Lnhorc)

Sally Floyd (ICIR, University of Berkelcy)

Jean Bolo t (Sprint)

Paul Fr:~ncis (Max Planck lnstitutc)

Daniel Brus htC}'tt (ex-aluno da Univcrsity of Pennsylvanh•) Kcn Calvert (U mversity o f Kentucky)

C::~líforn ia

ar

lixin Gao (Universi ty o f Massac husetts)

JJ Garcia-Luna-Ace\•es (Unwc rsity of California at Santa Cruz) Mario Geria (Univcrsity o f California at Los Angcles)

E\·andro Cantu (Univcrs•dacle Federal d e S.1111a Catarina)

Oav1d Goodman (Polytechmc Uni,•ershy)

Jeff Case (SNMP Research lnternational)

Tim Griffin (Cambridge Um versily)

jeff Chaltas (Sprint)

Max Hailperin (G ustavus Adolphus College)

bow4tto4ic~ Agrodedmentos

XXIII

Gostaríamos de agradecer a Honggang Zhang, da Suffolk Univcrsity, por revisar e aperfeiçoar alguns problemas presentes nesta ediç.lo. Queremos agradecer, também. a toda a equ•pc da Addison-Wesley- em panicular. a Michael Hirsch, Marilyn Uoyd c Stcphanie Sellinge r - que fizeram um trabalho realmente notável nesta quinta cdiç.lo (c que teve de suportar dois autores muito complicados c quase sempre atrasados). Agmdecemos aos artistas gráficos J anet Theurer e Patrice Rossi Calkin, pelo trnbalho que executarnm nas figuras deste livro, c a esbitt Graphics. i"larry Oruding e Rose Kc:rnan, pelo maravilhoso trabalho de produção desta ediç:lo. Finalmente. um agradecimento muito especial a Susan Hartm;m, noss.1 antiga editora na Addison-Wcsley, c, mais uma vez, a Michael I hrsch, nosso editor na Addison-Wcsler. Este livro n
Nota do Revisor Técnico Mais uma

vez foi com imcns."' satisfaç;\o que pude apreciar c rever a

tradu~~\o

do material apresentado em

Recles (Jc comrmtculorcs r ct Internet: unw ctbordogcm IOJ>-
wu

bowotto4ico.

bow4tto4ic~

1 Redes de computadores e a Internet

Internet de hoje~ prov:wclmemc o maior sistema de engenharia já criado pela hum:midadc, com centenas de compmadorcs conectados. lmks de comunicação e commadores: centen:lS de milhares de usuários que se conectam esporadicamente por meio de telefones celulares c PDAs; c dtsposilivos como sensores, webc
A

O primeiro caprtulo apresenta um panorama de redes de comp~ttadorcs c da Internet. Nosso objetivo é pi n1:1r um quadro amplo que nos permita ve r a norcsta por entre as árvores. Cobriremos u m terr eno bastante extenso neste capitulo de introduç;lo c d iscutiremos várias peças de uma rede ele computadores, sem perder de vista O CJ Ltad i'O geral. Este capitulo Jan~~l as rund ações para O resta nte do livrO. O panora ma geral de redes de computadores que apresentaremos neste c:lpltlllo scn1 estru turado como segue. Após aprcsentnrmos breve mente a termino logia e os cotwcilos fund:~ mc lllOliS, ex~mt ilmrcmos p rimei rame nte os componentes básicos de hardware c sortwarc que compõem uma rede. Part iremos da periferia dn rede e exami nare mos os sistemas fi nais e aplicações de rede executados nela. Considcmrcmos os scn•iços de transporte rornecidos a essas aplicações. Em seguida exploraremos o cerne de uma rede de computadores examinando os enlaces c comutadores que transportam dad os. bem como as redes de acesso c meios flsicos que conectam sistemas fina•s ao nucleo da rede. Aprenderemos que a Internet é u ma rede de redes c observaremos como ess:\S redes se conectam umas com as outras. Após concluirmos essa revisão sobre a periferia c o mlclco de uma rede de computadores. adotaremos uma visão matS ampla c mais abstrata na segunda metade deste capnulo. Examinaremos as causas do atraso de transferênCia de dados c das perdas em uma rede de computadores c forneceremos modelos quantllauvos stmplcs para o atraso fim a fim . modelos que le,·a m em con ta atrasos de transrniss.lo. propagaç.lo c fi la. Depois apresentaremos

bow4tto4ic~ Redes de tom putod ores e o Interne~1-------------------------

alguns princípios fundamentais de arquitetura em redes de computadores. a saber: protocolos em camadas c modelos de scrvaço. Aprenderemos. tamtxm. que as redes de computadores s:lo vulncrá\'cis a diferentes tipos de ameaças: analisaremos algumas dessas ameaças e como a rede de computadores pode se tornar mais segura. Finalmente, encerraremos este capítulo com um breve histórico da computação em rede.

1.1

Oque é a Internet?

Neste lavro, usamos a Internet pública, uma rede de computadores cspccrnca, como o \'Caculo pnncipal para discutir ~lS redes de comptuadores c sellS protocolos. Mas o que é a Internet? Há di\·ersas maneiras de responder a essa qucsti\o. Primeiro, podemos descrever detalhadamente os aspectos principais da Internet, ou seja, os componentes de software c hardware básicos que a formam. Segundo, podemos dcscre,•cr a Internet em termos de uma infraestrutura ele redes que fornece ser\'iços para aplkaçõcs distribuídas. Iniciaremos com a descriçâo dos componentes, lllilizando a Figura 1.1 como ilustração para a nossa díscussâo.

1.1 .1 Uma descrição dos componentes da rede A Lntcrnct é uma rede de computadores que interconecta mjlharcs de dispositivos computacionais ao redor

do mundo. Há pouco tempo, esses disposili"os er-4\m basicamente computadores de mesa. estações de trabalho Urmx, c os assim chamados servidores que armazenam e trllnsmitcm inforrmt~·õcs, como p:lginas da Web e mensagens de c-ma iI. 1 o entanto, cada •cz mais sistemas finais modernos dn Internet. como TVs, laptops, consoles para jogos. telefones celulares, webcams, automóveis, dispositivos de Sensoriamento ambiental, quadros de imagens, e sistemas internos tlétricos c de segurança. estão sendo conectados i\ rede. Realmeme, o termo rl'dt: dl' cornputatl(li.:S está começando a soar um tamo desatualizado, dados os muitos equapamcntos n:\o tradicionais que csuio sendo ligados .I Internet. No jargão da Internet, todos esses cquip.tmentos são dcnommados hospedeiros ou sistemas Onai<;. Em julho de 2008. havia aproximadamente 600 milhões de sistemas finais ligados :'1 Internet IISC, 20091, sem contar os telefones cclulares,laptops c outros daspositivos que s:lo conectados à rede de maneira intermitente. Sistemas finaas s.1o conectados entre si por enlaces (links) de comunicaç•lo c comutadores de pacotes. Na Scç;lo 1.2. veremos que há muitos tipos de enlaces de comunicaçl\0. que sJo constitufdos de diferentes tipos de meios físicos. entre eles cabos coaxiais, fios de cobre, Obras óticas c ondas de rádio. Enlaces dlrercntes podem Lransmuir dados em taxas dHeremcs. sendo a ta;'
bow4tto4ic~ Capítulo 1

Redes de comput adoras e o Inte rnet

3

ISP nKional ou global Rede móvel

ISP local

ou rc9lona1

Rede corporativa

legenda:

Host (ou Siltti'M

lonal)

Sefvidor

MÓ\Itl

Comut~dor

Modem

c1t p~o1e

hta(.\o·ba~e

Telefone ttllllll

Torre dt ttlefon•a celular

Figuro 1.1 Alguns componentes do Internet quilômetros. 'a rábrh.'"ll, a carga é dividida c carregada em uma rrot:~ de caminhões. Cada caminhão viaja. independentemente. pela rede de rodo,•ias, estradas c cruzamentos ao depósito de destino. No depósito, a carga é desetrregada c agrupada com o resto da etrga pcncnccme à mesma remessa. Deste modo. os pacotes se assemelham aos etminhOes, os enlaces de comunietção se assemelham às rodovias c estradas, os comutadores de pacote se

assemelham aos cruzamentos c cada sistema final se assemelha aos prédtos. Assmt como o caminhão faz o percurso pela rede de transporte, o pacote utiliza uma rede de computadores.

bow4tto4ic~ Redes de com putod ores e o Inle.;.';;. ne;;.;t_________________________

Sistemas fin:~is acessam a Internet por meio de Pro,•cdorcs de Scniços de Internet (Internet Sen•ice ProvidcrsJSPs), en tre eles ISPs residenciais corno empresas de TV a cabo ou empresas de telefonia; ISPs co rporativos, ISPs de unive rsidades c ISPs que fornecem acesso sem fio em aeroportos. hotéis, cafés c outros locars públicos. C.1da lSP é uma rede de comutadores de pacotes c enlaces d e comunicação. ISPs provccrn aos sistemas finais uma \-aricdade de u pos de acesso à rede, rncluindo acesso por modem discado de 56 kbps. acesso residencial de banda larga como modem de 01bo coaxial ou DSL (h nha digi tal de assinante), acesso por LAN de aha ''elocidade c acesso sem fio. ISPs tam~rn fornecem acesso a provedores de conteúdo, conectando sitcs Web diretamente à Intern et. Esta se imeress.1 pela conexllo entre os sistemas finais. portanto os ISPs que fornecem acesso a esses sistemas também devem se intcrconcctar. Esses ISPs d e nível mais baixo são in tcrconcCLados por meio d e ISPs d e nível mais alto, nacionais c internacionais, co rno AT &T c Sprim. Um ISP de nfvcl mais alto consiste em rotc:ldorcs de a ha velocidade intcrco ncctados com enlaces de fibra ótic-1 de alta velocidade. Cada rede ISP, seja de mvcl mais alto ou mais ba1xo. é gerenciada de forma mdependc ntc, executa o protocolo lP (ver adiante) c obedece a certas convenções d e nomeaç:1o e end ereço. Examinaremos ISPs e s ua interconexão mais detalhadamem c na Scç:lo 1.1. Os sistemas finai s, os comutadores de pacotes c o utras p<:ç:quest for conmtt llls - ped1do de comentários). Os RFCs começaram como sohc11açõcs gerais de comentários (por isso o nome) para resolver problemas de arqulleturJ que a precursora da Intern et cnfrclllava. Os RFCs tendem a ser bastallle técn icos c detalhados. Definem protocolos como TCP, IP, HTTP (para a Web) c S~ITP (Protocolo Simples de Transferência de Correio- Simple Mail Transrer Protocol) (par.l e-mail). Atualmente, existem mais de 5.000 RFCs. Outros organismos tam~m especificam padrões paro componen tes d e rede, mais nota,·elmcntc para enlaces da rede. O IEEE 802 LAN/MAN Standards Commince (IEEE, 802, 20091 . por exemplo, especifica os padrões Ethcrnet c Wi-Fi sem fio.

1.1.2 Umo descrição do serviço i\ discu~lo anterior identi ficou mu itos dos componentes que compõem a Internet. Mas tamb~m podemos d ~screvê- la p:lrlindo de um ângulo completamente diferente -

ou seja, como umca lnfr·trr.~tr·utura qHc fJrOvé se " ' Í('OS 11 CljJilcaçOcs. Tais apliC.I\'ÕCS incluem correio eletrônico, navcgaç:\o na Wcb, mensage m inswn tânca, Voz sobre IP (VolP) , Internet via n\dio, ' 'ídeo em tempo rcal, jogos distribufdos. co mpani l hr~mcn to de arquivos pccr-to-pcer (P2P). televisão pela Internet, login remoto e muito mais. Ess;\S aplk-açOcs s;\o conhecidas como aplicações distribu ídas, uma vez que envolvem diversos sistemas fi nais que trocam mfo rmações mutuameme. De fonna significati va, as aplicações d:1 In ternet sao executadas em sistemas finais - e nllo em comut:1dorcs de pacote no núcleo da rede. Embora os comutadores de pacote facilitem a troca de dados entre os sistemas . eles não estão relacionados com a apllca~'ào, que é a fonte ou destino d e dados. Vamos explorar um pouco mais o signific.\do de uma infraestrutura q ue fornece serviços a .tplicaçoes. Nesse sentido , s uponha que vocc tenha uma grande ide ia para uma aplicaçlo distriburd::. para a lmc mct, uma que possa beneficmr a human idade ou que simplesmente o enrique\'3 c o torne famoso. Como transformar essa ideia em uma aphcaçt\o real da Internet? Como as aplicações são execUiadas em Sistemas flnms. voct precis.1rá criar componentes de soft"-are que sejam executados em sistemas finais. Vocc pode. po r exemplo. cnar seus componentes em Java, C, ou Python. Agora, já que você está desenvolvendo uma aplicação distribuída para a Internet, os componentes do software executados em diferentes sistemas finais precisarão enviar dados uns aos outros. E, aqui,


Redes de computadores e o Internet

5

chegamos ao assunto principal - o que leva ao modo alternativo de descrc,cr a lmcrnct como uma plataforma para aplicações. De que modo um componcme da aplicação, executado em um sistema final , oriema a lmcrnet a erwiar dados a outro componente de software executado em o mro sistema fimtl? Os sistemas finais ligados à Internet proveem uma Interface de Programação de Aplrcaç-Jo (API) que cspccirica como o componente do software que é executado no sistema final solicita à infraestrutura da Internet que envie dados a um componente de software de destino específico, executado em outro sistema fin:~l. A API da Internet é um conjunto de regras que o software emissor deve cumpnr p
Esta segunda descrição da lntemct- uma inrracstnuura de romccimemo de serviços a nplicaçOcs distribuidas- é muilo importante. Cada vez mais, os avanços na tecnologia dos componentes da Internet estão sendo guiados pelas necessidades de novas aplkações. Portamo, é Importante ter sempre em meme que a Internet é uma infraestrutura na qual novas aplicações estão constamememe sendo inventadas c drspombilizadas. Acabamos de apresentar duas descrições da Internet uma delas diz respeito a seus componentes de hardware c software. c a outra, aos serviços que ela oferece a aplicaeôcs distriburdas. Mas talvez voct ainda esteja confuso sobre o que é a Internet. O que é comutaç-.lo de pacotes, TCP/IP c API? O que s:\o roteadores? Que tipos de enlaces de comunica("Jo estão presentes na lmemet? O que é uma aplicação distrrbufda? Como uma torradeira ou um sensor de variações meteorológicas pode ser ligado à Internet? Se voct está um pouco assustado com wdo isso agora. não se preocupe- a l'inalidade deste livro é lhe apresentar os mecanismos da Internet c uun~rn os prindpios que determinam como c por que ela funciona . Explicaremos esses termos c questões importantes nas seçOCS c nos caphulos subsequcmcs.

1.1.3 Oque é um protocolo? Agora que já entendemos um pouco o que é a Internet. vamos considerar uma outra palavra fundamental usada em recks de compumdort's: protocolo. O que é um protocolo? O que um protocolo f:1z?

Uma analogia humana Provavelmente é mais rádl entender a idcia de um protocolo de rc
bow4tto4ic~ Redes de computadores e o Internet

O;

:..,....... :-.........

.~ Tempo

Tempo

Tempo

Tempo

Figura 1.2 Um proiiXolo hunmo eum protaergunta: ''Alguma dúvida?" (urna mensagem que é transm itida a todos os alunos c recebida por todos os que ntlo esttlo dormindo). Voce levanta a m11o (t ransmitindo uma mensagem impllcita ao professor). O professor percebe c, com um sorriso, diz "Sim ... ~ (um~ mensagem transmitida, lncentivanclo·o a fazer sua pergunta - professores culorcmr perguntas) c você entJlo faz sua pergunta ( isto t, tnrnsmlte su:~ mensagem ao professor). O professor ouve (recebe sua mensagem) e responde (tr:msmitc mna resposta a voce). Mais uma vez, pcn:cbcmos que :l trnnsmissao c a rcccpçi\o de mensagens c um conjunto de :woes convencio nais, rcaliU~das quando as mensagens são cm•iadas c recebidas, são o coração desse protocolo de pergunta c resposta.

Protocolos de rede Um protocolo de rede é semelhante a wn protocolo humano: a unica drferença é que as entidades que trocam mensagens e rcaliz:~m açOes são componentes de hardware ou wftwarc de algum equipamento ( por exemplo, computador, POA, telefones celulares, rottador ou omro equipamento habilitado para rede). Todas as atividades na Internet que en\'olvem duas ou mais entidades remotas comunicantes são governadas por um protocolo. Por exemplo, protocolos implementados em hard"•are nas placas de mterfacc de rede de dois computadores conectados fisicamente controlam o fluxo de bits no 'cabo' cmre as duas placas de interface de rede; protocolos

bow4tto4ic~ (opítulo 1

Redes de
7

de controle de congestionamento em sistemas Cinals controlam a taxa com q ue os pacotes si\o transmitidos enue a origem e o desLino: protocolos em roteadores determinam o caminho de um pacote da origem ao destino. Protocolos estão em execução por toda a Internet e, conscquemememe. grande pane deste livro trata de proto· colos de rede de comput;tdores. Como exemplo de um protocolo de rede de compumdorcs com o qual você pro,-:wclmcme está ramiliarizado, considere o que acontece quando fazemos uma requisiç-.lo a um servidor \Vcb, ISto é. quando digitamos o URL de uma página Web no browser. lsso é mostrado no lado dtrci to da Figura 1.2. Pnmeiramente. o computador enviará uma mctlS."'gcm de requisiç:'lo de conexão ao scn;dor Wcb e aguardará uma resposta. O servidor receberá essa mensagem de requisição de cone>.'âo c retomará uma mensagem de resposta de conexão. Sabendo que agora está tudo ceno para rcquisit:lr o docu mento da Web, o computador envia então o nome da página Web que quer bUSC:lr naquele servidor com uma mensage m GET. Por fim, o SC r\~dor retoma a pãgina da Web (arquivo) para o compmador. Dados o exemplo hu mano c o exemplo de rede anteriores, as troms de mensagens c as ações rcalit.'l.das quando essas mensagens são ctwi<~das c recebidas si\o os elementos fundamentais para a ddiniç:'\o ele u m protocolo:

Um prowwlo d~frnt' e1fimmllo c" (lrdcm das mensagens trocadas entre dtws HII'Cl C\'rnw. A Internet c as redes de computadores em geral fazem uso intenso de protocolos. Diferentes tipos de protocolos são usados para realizar diferentes tardas de comunicação. A medida que for ~wa nçando na leitllm deste livro, você perceberá que alguns protocolos s:.\o simples c diretos, cnquam o outros s:.\o complexos c intelectualmen te p rofundos. Dominar a ;lrca de redes de computadores C(\Uh'3lc a en tender o que ~;lo, por que existem c como funcionam os protocolos de rede.

1.2 Aperiferia do Internet 'as seções antcnores, apresentamos uma descrição da Internet c de protocolos de rede fazendo analogias com nossos atos. Agora passaremos a tratar com um pouco mais de profundidade os componentes de uma rede de computadores (e da Internet, em particular). 'esta seção. come~mos pela periferia de uma rede c examinamos os componentes com os q uais esta mos mais familiarizados- a S:.lber, computadores, POAs, telefones celulares c outros equipamentos que usa mos diariamente. Na seção seguinte, passaremos da perifcri:1 para o núcleo da rede c estudaremos comutaç-lo c ro tea mento em redes de computadores. Como descrito n:1 scç;\o anterior. no jargão de rede de computadores. os computadores c OltLros disposili· conectados à Internet são frcquentemCJltC chamados de slstemõlS nm1ís. El<·s s;\o assi m chamados porqu e se encontram na periferia d:1 l 111crnet, como mostrado na Figura 1.3. Os sistemas fi nais da lmcme1 incluem compULadores ele mesa (por exemplo, PCs de mesa, MACs e Linux Boxes), servidores (por exemplo, Web c servidores de e-mails), c computadores móveis (por exemplo, computadores portáteis, PDAs c telefones com concx:\o sem fio;\ Internet). 1\lém disso, u m crescente nümero de ap;uelhos a lternath•os esl:\o sendo u tilizados com a Internet como SIStemas fi nais (veja p~1gina scguinlc). ' 'OS

Sistemas fina is também são denominados hosr)tdtiros (ltosts) porque hospedam (isto é, executam) progra mas de aplic:tç;\o, tais como um program.1 browscr da Wcb, um progrnma servidor da Web, um progrnma leitor de e-ma iI ou um servidor de e-mail. este livro, utilizaremos os tennos hospedeiros c sistemas finais como sinônimos. As ''ezes. sistcnt:\S nnats si\0 ainda subdivididos em du:IS calcgorias: clientes c servidores. Informalmente, clientes costmnam ser PCs de m<:s\ ou móveis. PDAs e assim por diamc. ao passo que servidores lendcm a ser máquin:IS mais poderosas que annazemun c d~lribucm páginas Web, vidro em tempo real, reLrariSmissào de c-mails c assim por diante.

1.2.1 Programas clientes e servidores No conlexto de soflware de red e há ainda uma outra dctmlç;lo de chcntc c de scr\'ldor, à qual nos referiremos em todo o livro. Um programa cliente é um programa que funciona em um sistema final, que solicita e recebe um


Um conjunto impressionante de sistemas finais do Internet Não foz muito tempo, os sistemas finais conectados õ Internet eram primordialmente computodores tradicionais, como móquinos de mesa e servidores de grande copocidode. Desde o final do década de 1990 até hoje, um amplo leque de equipamentos e dispositivos interessantes, cada vez mais diversos, vem sendo conectado à Internet. A característico comum desses equipamentos é que eles precisam enviar e receber dados digitais de, e poro, outros equipamentos. Tendo em visto o onipresença do Internet, seus protocolos bem definidos (padronizados) e o disponibilidade comercial de hardware copocitodo poro elo, é noturol usar suo tecnologia poro interconector ossos equipamentos. Alguns deles parecem ter sido criados exclusivamente poro diversão. Um computodor de mesa utilizando IP com recurso de moldura do foto (Ceivo, 2009) solicito fotos digitais de um servidor remoto e os apresento em um dispositivo que parece uma moldura tradicional de Fotografia; uma torradeira do Internei baixo infor· moções meteorológicos de um servidor e gravo uma imagem do previsão do tempo do dia em questão (por exemplo, nublado, com sol) no suo torrado matinal [88C, 200 1]. Outros dispositivos fornec-em inlormoç~s úteis- c6meros Web apresentam os condições meteorológicos e de tráfego ou fazem monitoramen to poro fornecer uma localização de interesse; eletrodomésticos conectados à Internet (incluindo máquinas de lavor roupas, geladeiras e fogões) podem ser monitorados e controlados remotamente por meio de um browser. Telefones celulares que utilizam IP com recursos de GPS (como o novo iPhone do Apple) permitem fócil navegação pelo Web e transmissão de e-moib e mensagens. Uma novo classe de sistemas de sensoriomenlo em rede promete revoluciono r o modo como observamos e interogimos com nosso ambiente. Redes de sensores incorporados ao ambiente físico permitem o monitoroçõo de edifícios, pontos, atividade sísmico, hobilols do fauno selvagem, estuários e dos camadas inferiores do atmosfera (CENS, 2009, CASA,2009). Aparelhos biomédicos podem ser incorporados e conectados em rede, causando numerosos problemas de privacidade e segurança (Holperin, 2008). Umo tog de RFIO ou um sensor integrado ligado o qualquer objeto pode for· necer informações o respeito desse objeto no Internet, levando o umo "Internet de coisas" (ITU, 2005).

sen•iço de um programa scn••dor, que funciona em um outro sistema final. A \Vcb. o c-ma1l, a transfcrcncia de arquivo, o login remoto, os grupos de discussão c muitas ouLras aplicações populares adota m o modelo cliemc·Servidor. Uma vez que um program:1 cliente nonnalmcnlc roda em um computador c o programa servido r. em otltro, aplicações cliente-servidor de lmcmct são, por definição, aplicações distribufdas. O programa cl iente c o programa servidor imcmgem enviando mensagens um para o oUlro pela lmerncl. Nesse nível de abstmç-Jo, os roteadores. enlaces c ouLros componentes da lnternct runcionam como uma c:aixa-preta que transfere mensa· gens entre os componemcs distribuielos, comunicantes, de um aplicação da Internet. Esse ~o nlvcl d e :1bstnlC".lO representado na l~igura 1.3. Nem todas as aplkaçOcs da Internet d e hoje cons istem em programas purameme clientes qu.e inter-agem com progmrnas puramente servidores. Muitas aplicações são, cada vez mais, pcer-to-pecr (P2P), nas quais os sistemas finais intcmgcm c executam program:\5 que apresentam fun ções de sen •idor e de cliente. Por exemplo, em apllrncõcs P2P de compartilhamento de arquivos (como o BiiTorrent e o eMule). o programa no sistema final do usurtno runciona como um cliente quando solicita tun arquivo de ouLro p:tr; e o progr.una funciona como um servidor quando envia um arquivo para outro par. Na telefonia por Internei, as duas partes comunicantes intcragcm como pares; uma parte n:lo requisita scn•iço da outra em nenhum scmido. Examinaremos dctalhadamcmc ~\5 scmclhanc;as c diferenças entre arquiteturas clientc-scn·idor c P2P no Capitulo 2.

1.2.2 Redes de acesso Tendo considerado as aplicações e sistemas finais na "periferia da Internet", vamos agom considerar as redes de acesso- os enlaces físicos que conectam um sistema final ao primeiro roteador (também conhecido como "roteador


Redes de computa do ras e o Inte rnet

9

ISP na<1onal OU910bal R~mõvet

ISP local

ou regional

Figura 1.3 ln te~oçõo entre sistemas finais de borda") partindo de um slstcm~ fi nal até Oluro qualquer. A Figura 1A apresenta d iversos tipos de enlaces d e acesso do $lstcma fi nal ao roteador de periferia; os en laces de acesso estão des tacados nas linhas cinzas mais espessas. Esta scç.\o ana lisa muitas das tcwologi;IS mais comuns em rede de ncesso, em tcnnos gerais, de bai xa:'\ altJ velocidade. Veremos mais ad ian te q ue mui tas dessas tec nologi~IS emp regam, em níveis q ue variam, parcelas ela trad icional Infraestru tura tclcfOnica com fio. Essa infraestrutura é romecld;t por u m servidor telefôn ico local, q ue simplesmente chamaremos de operadora. São exemplos de operadoras a Ve rizon , nos Estados Unidos, c a Frnnce Telccom, na Fnuwa. Cada rcsid~ncla (casa c apartamento) possui um par di re to de nos de cobre tran~ado parn um comut:~dor da opcrndorn na regi lo, hx.-alizado em um cdlfacio chamado "ccntral tclefOnica" (CT) no jargão da telefonia. (Dis<:utírcmos par de nos de cobre trançado mais ad i;mtc nesta SC\.iO.) Um;l operadora local possuirá, normalmente, centenas de CTs e ligará cada cliente à sua CT mais próxima.

Diol-up (discado) Nos anos 1990, <1uasc todos os usuán os res1denc•a•s a,cssa,-am a Internet por me1o de hnhas tclc:fOmCIS analóg•· cns utilizando um modem discado. Atuulmeme. muitos usuirios de pa1ses não desenvoh-idos c de áreas rurais em países desenvolvidos (onde o acesso à banda larga é indisponível) ainda têm acesso à Internet discada.Na verdade, estima-se que 10% dos usuários residenciais nos Estados Unidos usavam Internet discada em 2008 !Pew, 2008).

bow4tto4ic~ Redes de compu tado res e o lnte ;.; ro;.;e;.;.t_________________________

ISP nacional ou global

ISP lota i ou regiona l

--x~ ~ - t t-í Rede doméstí
Rede corporativa

Figura 1.4 Acesso o1edes Emprega-se o termo "díul- up~ porque o software do ustttlrlo, na verdade, disca (em ingiCS, IIial) um número de telefone do ISP c realiza uma ligaÇ'
O acesso discado à Internet possui duas d esvantagens principais. Em primeiro lugar, é extremamente lento. fornecendo uma taxa máxima de 5ó kbps. A essa taxa. o download de uma música em formato MP3 de trti rnrnutos leva. aproximadamente, oito minu tos, c um dia é o tempo que leva o do'' nload de um filme de L Gigabytc! Em segundo lugar. o acesso discado bloqueia a linha tclcfOnica comum do usuário- enquanto

uma p~soa usa a mesma linha.

o modem para navegar na Web, ninguém mais pode receber ou realizar ligações comuns com


Redes de computadoras e o Inte rnet

11

Internet

---':=---=<

r~ ~ Legend•: Comutador de circuito

Figura 1.5 Acesso ôInternet dis
DSL Atualmente, os dois tipos de acesso residencial b:Hlda larga mais predomin:mLcs sao :1 linha cligit:tl de a.ssin:mtc (DSL) o u :1 C;tbo. Em muitos P
N.R.T.: Os termos "downstrcmn" c "upstrcam· dcscrcYcm a transmissão de dados p
bow4tto4ic~ Redes de tom pulod ores e o Interne~1-------------------------

Telefone residencial

Internet Linha tclefõnica existente: telefone com 0-4 KHz; dados upstream com 4·50 KHz: dados dowrutrum com 50KHZ - 1 MHZ

\ /

Central telefóniC
Computador

~

~_

Rede telefOniC
~~

reside nela i

Figura 1.6 Acesso à Internet DSL A l:tX:I de 11';11\SnliSS;lo de downstrcam e upstream real disponível r:mra as rcsidencias é Ulll:l runç;\o ela disHin· cia entre a t-:1sa c a CT, permitindo laxns de transmissão mais elevadas do que no :1ccsso discado. Para aumentar a taxa ele d:~clos, a DSL coma com um processamento de sinal avançado c :~lgori t mos de corrcçilo de erro. que podem levar a grandes :nrasos ele pacotes. No entanto, sr a rrsidencía m\o estiver lot-:tlizada dentro ele 8 a 15 quilômetros ela CT, :1 tecnologia de proccsSllmemo de sinal DSL nào será mais eficaz c a rcsidt!ncia deve recorrer a uma rorma alternativa de acesso;\ Internet. Há wm!Xm uma variedade de tecnologias DSL de alta velocidade em alguns p;aíscs allmlmcmc. Por exemplo, a tecnologia DSL de alt.1 velocidade (VDSL), com a maior pcnctra~'ào, hoje, 11.1 Corci;t c no Jap.lo, apresenta wxas impressionantes ele l2 a 55 Mbps p.1ra dO\\ nsucam e 1.6 a 20 Mbps para upstrcam IDSL. 20091.

Cabo Muitas rrsid~ncias na América elo Norte e em outros lugarrs recebem centenas de t-anais de televisão por redes de cabo coaxial. (D•scutiremos cabo coa.xial mais adiante nesta SC\'àO.) Em um sistema tradicional de televisão a cabo. um terminal de distribuição transmite canais de televisão atraves de uma rede de distribuição de cabo coaxial c ampi!Ocadorcs para as resid~ncias. Enqtmnlo as tecnologias DSL e dial-u p utilizam-se da infraestrutura tclcfOnica local existente da operadora, o acesso à Internet a cabo utiliz.'l-se da infraestrutura de televisão a cabo existente da cmpres.1 de TV a cabo. Uma residc:ncia obtém acesso à Internet a cabo da mesma empresa que fom«:c a tclevis;lo a t'tlbo. Como ilustrado na Figura l.7, as nbms óticas CO IICCIJ\111 O lcrmlnaJ ele distribuiç;lO àS junções da rcghlo, Sendo O cabo coaxi:tl tradicionnluti· lizaclo p:1ra chegat :\s casas c apartamentos individualmente. Cada jm1~io normalmente suporta de 500 a 5.000 cas.-.s. Em razão de a Obra e o cabo coaxial fazerem parte desse sistema, a rede é denomiuacltl hrbrid::t fibra-c:o::txial (HFC). O acesso:\ Internet Ll cabo necessita de modems especiais, denominados modcms a cabo. Como o modem DSL, o modem a cabo é. nonnahneme, um aparelho externo que se conecta ao comp utador residencial através da porta Ethernet. (Discutiremos Ethemct em detalhes no Capítulo 5.) Os modcms a cabo dividem a rede IIFC em dois canais, um de trnnsmiss;lo (clownstrcam) c um ele rccebimemo (upstream). Como a tecnologia DSL, o acesso normalmente é assimétrico, com o canal downstrcam recebendo uma taxa de transrniss
bow4tto4ic~ Redes de computadoras e o Internet

Capítulo 1

13

Cabo
Centenas de resld~ncias

Nó de fibra óti
Terminal de

dístribulç.\o

~.--N-ó-de---. /

Centenas --r-')..._--r-_,__ _ _ _ _ _ _ _ de residências

fibra

ótka

figura 1.7 Umo rede de oces~o híbrido fibro-
FTTH (Fiber-To-The-Home) A Obro óuca (que será discutida na Seçl\o 1.2.3) pode oferecer taxas de tronsmiss:\o signiO cati,ramente mais altas do que o par de nos de cobre tron\ado ou o cabo coaxial. Algumas operadoras locais (em muitos países diferentes), que recentemente passaram a uúlizar Cibro óú ca nas resid~ncias, agora oferece m acesso à Internet de aha velocidade. bem como se viços telefônicos e te levisivos através d e fibras ó ticas. Nos Estados Unidos, a Verizo n sai u na fren te com a teenologta F1TH, lançando o serviço FIOS (Verizon FIOS, 2009].

Existem vd rlas tecno logias concorrentes para a distribuição ótica das CTs às resld~nclas. A rede mais sim ples de distribuiç;\o ótie~ e ch:unada fibra direta, para a qual existe umtl Obra saindo da CT para cada resldCncia. Essa dist ribui çào pode fornecer uma nlta largura de banda, uma vez que e~da cliente recebe s ua própria fibra ded icada di retament e da ce ntral tclcro ni<."<'. Geralmente, cada fibra que sai d:1 ~:entr:t l telcronica é ~:ompa rtilhada por v•lrias rcsid!!ncias; a nbra é di vidida em nbras indi viduais do cliente somente após e la se aproxima r relati vamente das rrsidf ncias. Existem duas arquiteturas concorrentes de rede ele distribuh,::lo ótica que aprescnt.:1rn essa divis.'\o: redes ó ticas am·as (AONs) c redes óticas passivas (PONs). A AO é basicamente a Ethcrnct comutada. assunto discutido no Ca pitulo 5. Aqui, falaremos brevemente sobre o. PON, que é utilizada no serviço FIOS da Verizon. A Figuro 1.8 mostro a FTTH utilizando a arquitetura de distribuição de PON. <:.Jda residência possui um terminal de rede óuca (ONT), que é conectado por uma fibra ótica dedicada a u rn dtstribuidor da rcgiào. O distribuidor combina um numero de residências (normalmen te menos d e 100) a uma únirn fibra ótica compartilhada. que se liga a um tcrntinal de linha ótirn (OLT) na CT da operadora. O OLT, que fornece conversão en tre os sinais óticos e elétricos, se conecta a Internet por meio de um roteador da operadora. Na rcsid~ncia, o usuário conecta urn roteador residccial (geralmente um roteador sem Cio} ao ONT c accssa ~ Internet atrás desse rotc.tdor. Na arq ui· tetu m de PON, todos os pacotes enviados do OLT ao distribuidor são nele replicados (semelhante ao terminal de disLribuiçl\o a cabo).

bow4tto4ic~ Redes de cora putod ores e o Inle;.r;;. ne;;,;t_________________________

Central telef6nica....__

Internet

Distribuidor ótico ONT

Q

/~

OLT

Fibras óticas

ONT

Figura 1.8 Acesso à Internet FnH A Frn I pode potcnciahnentc prover t.'lX:tS de acesso à internet na f:1ixa de gigablts por segundo. Porém, a maioria dos provedores de m t l oferecem diferentes taxas, sendo que as mais tllt:ts ~ust:un muito mais. Antalmente. a maioria dos dlcn1cs FITH preferem laX<\S de download na faixa de lO a 20 Mb['>S c de uplo:1d na faixa de 2 a lO Mb(>S. i\lc!m do acesso à lmernct. ns ftbr:ts óticas possuem serviços telefônicos lr.ldicionais c de transmiss;lo televisiva.

Ethernel Nos cmn1Ji universitários c corporatativos, uma rede local (LAN ) geralmente é usada para conectar siste· mas Onais ao roteador d;• pcrífería. Embora existam muitos tipos de tecnologia LAN , a Ethcrnct é, de longe, a tecnologsa de acesso mais predominante nas redes universitárias c corporauvas. Como mostrado na Figura 1.9, os usuários da Ethernet utilizam par de fios de cobre trançado para se conectarem a um comutador Ethernct, uma tecnologia tratada com mais de talhes no Caphulo S. O acesso;\ Ethernel normalmente possui 100 Mbps, enquanto os servsdorcs possuem um acesso de l Gbps ou até mesmo lO Gbps.

Wifi Está cada vez mais comum as pessoas acessarem a Internet sem no, seja por um laptop ou por um aparelho portátil, como um iPhone, Blackberry ou o Googlc phonc (veja o quadro "Um conjunto smpressionante de sistemas flnais da Internet "). llojc. h:l dois Lipos comuns de acesso à Internet sem !lo. Em uma LAN scrn !lo, os usu
it'------daPara ISPs

lnstitu~4o

Figura 1.9

Acesso à rede Elhernet


Redes de computadoras e o Internet

15

fio. Um ltSu:irio LAN sem no geralmente deve estar no espaço de alguns metros do pom o de acesso. Nas redes de acesso sem fio em amplas áreas, os pacotes são trans mitidos para uma csta,.:.o-base por meio da mesma inrraestrutura sem no llliliz.lda para tcldonia celular. Nesse caso, a cstaç:.l o-base (:con trolada pelo pro,•edor da rede de celular. c o usuário normalmente deve estar dentro de alguns q uilOmctros da cstac;Jo-basc.

O acesso à LAN sem fio baseado na tecnologia IEEE 802.11 , ou seja, WiFI, está presente em todo lugaruniversid ades. empresas. c:~ r~. :~eroportos, resid~ncias e. até mesmo, em a\riões. A mai oria d:LS universidades instal ou cstac;óes-base por todo o campus, permitindo que os a lunos etwtem c recebam e-m:uls ou naveguem na Web de qualquer lugar do campus. Em muitas cidades. é possivel ficar na esq uina d e uma ru:1 c estar dentro da raixa de dez o u vinte estações-base (para um mapa global de estações-base 802. 11 que roram descobertas c accssndas por pessoas que :~prccla m coisas do tipo, veja [wiglc.net, 20091). Como discuudo com detalhes no Capítulo 6. atualmente o 802.11 romece uma taxa de tronsmissào compartilhada de até 5'* Mbps. Muitas rcsidéncias unem o nccsso residencia l banda larga (ou seja, modcms a cabo o u DSL) com a tec nologia l.AN sem no a um custo acessrvcl J:>.1ra criar redes residenci:~is poten tes. A Figura 1.1O mostra um esquema de urna tfp lca rede dom~s tica. Essa rede consiste em um laptop móvel c um computador com flo; uma es tação-base (o ponto de acesso sem fio), que se comunica com o computador sem no; um modem a cabo, fornecendo acesso banda larga â Internet; c um roteador, que interconecta :tt'Stação-base c o comp utador fixo com o modem a cabo. Essa rede permite que os momdores da resid~ncia 1cn ham :.cesso banda larga à In ternet com u m momdor se mov uncnt:mdo cl:1 cozinha ao quintal c atl! os quarlos.

Acesso sem fio em longa distôndo Ao acessar:\ Internei mravf:s da tecnologia LAN sem fio, f: preciso estar denlro de alguns meLros do ponto de :~cesso. Isso é possfvcl para acesso domf:slico. em cafés. c. gc:ralmcn1c. de ntro c ao redor de um edlrlcio. Mas e se voe~ esu vcr na prata. no Onibus ou no carro e prccisár da lm ernel? Para o acesso em arcas amplas. os usuários de Internet mó,·cl utili zam uma infracslrulura de 1elefone celular, acessa ndo est:tcOcs-basc que estão a até 10 quiiOmetros de d istância.

t\s empresas de tclecomunicaÇ"Jo t~m im·eslido enonnemente na assi m chamada terceira gcraç;1o (3G) sem fio. que orerecc acesso sem flo em amplas áreas por paco1cs com utados a velocidades que uhrapassam 1 Mbps. Hoje. míl· hOcs de usuários estilo utilizando ess..ls redes pam ler c enviar e-rm\ils, navegar na Wcb c fazer download de música.

WiMAX Como sempre. existe u ma 1ccnologia potente esperando para destro nar esses padrões. O W iM1\X !Intel WiMAX, 2009~ Wi I!AX Foru m, 20091 , também conh ecido como IEEE 802.16, é um primo distante do pro tocolo

Terminal de

i----....J~a--~t.<:l~ ~t.<:/~ ~t.o:l:.....- dis!r~~ao - - - Internet RMidência

figura 1.1 O Esquema de uma típico rede doméstico

bow4tto4ic~ Redes de co11putodores e o

ln;.;l~e;.;rn;.;e;.;.t_________________________

Wifi 802.11 díscUiido acima. O WIMAX (unciona independentemente de uma rede de telefonia celular c promete velocidades de 5 a 10 Mbps ou maiores a distâncias superiores a dez quilômetros. A Sprint-Nextel investiu bilhões de dólares na unplemcntaç-Jo do \ViMAX em 2007 e foi al~m. As tecnologias Wifi, WiMAX c 3G ser.lo abrangidas em detalhes no Capilulo 6.

1.2.3 Meios flsicos Na subscç-lo antcnor, apresentamos uma viSão geral de algumaS das m:us importantes tccnolog~;ts de acesso à Internet. Ao descrever essas tecnologias. indicamos também os meios frsicos utilizados por elas. Por exem-

plo. dissemos que o IIFC usa uma co mbinaç;\o de cabo de fibra ótica c t":\bo coaxí:1l c que modcrns discados de 56 kbps e ADSL usam par de fios de cobre trançado. Dissemos também que redes de acesso móveis usam o espec tro ele r:ldio. Nesta subsc(lc1o dumos uma ' 'isão geral desses c de outros meios de transmissão comu mente cmpreg:~dos na Internet. Para clcnnir o que significa meio físico, ,~.unos pensar na curta vida ele u m bit. Considere um bit saindo de um sistctn:l fi n:1l, transitando por u ma série de enlaces c roteadores e chegando a outi'O sistema final. Esse pobre bit é tra ns mitido muitas c nmilas vezes. Prímci rarncnu~. o sistcm;\ fin.1l origlml
Por de fios de cobre lron~odo O me io de transmissão gui:tdo mais barato e mais com umente usado ~ o par de fi os de cobre trançado, que ve m sendo usado htt mais de cem anos nas redes de telefonia. Realmente, mais de 99 por cento da flaç
Quando a tecnologi:~ da fibra ótica surgiu na década de 1980, mmtos depreciaram o p:~r tranç;~do dcv1do ãs suas taxas de transm issão de bits relativamente baixas. Alguns até acharam que a tecnologia da fibra ótica o substituiria completamen te. Mas o par trançado não desistiu assim tão [acilmente. A moderna tecnologia, tal como UTP


Redes de
17

categoria 5, pode alcançar taxas de transmiss;\o de dados de 100 Mbps para disu\ncias de mé algumas centenas de metros. E. em dast3nc•as mais curtas, podem ser atingidas taxas amda m:uo res. 'o final, o par trancado firmou-se como a soluç;lo donnnamc para LANs de aha velocidade. Como vimos na scç;\o sobre redes de acesso. o par lrançado Lambém é comumente usado para acesso resi· dencial à Internet. Vimos que a tecnologia do modem discado possibilila taxas de acesso de até 56 kbps com pares trançad os. Vamos Lambém que a tecnologia DSL (linha dignai de assi nante) hnbalitou usuános rcsadcnciais a acessar a Internei em velocidades maiores do que 6 Mbps com pares de fios tranç;~dos (q uando as residências estão próximas a um modem de ISP).

Cabo coaxial Como o par trançado, o cabo coaxial é constituído de dois condutores d e cobre, porém concêntricos e não paralelos. Com essa configuraçào, isolamento c blind,,gcm especiais, pode l'lca nçar taxas ahas de hils. Cabos coaxi:Jis s.:to muito co muns em s istemas de televisão a cabo. Como já co ment amos, recc memcme sistemas de televis:lo
Fibras óticas A fibra ótiel é um meio delgado e flexlvel que conduz. pulsos de luz. sendo que cada um desses pulsos

representa um bit. Um:~ unica fibra ótica pode suportar taxas de trans nnssão cJc,·:Jdlssimas. de até dezenas ou mesmo cen tenas de gigabiiS por segundo. Fibras óticas são imu nes à intc rfer~ncia eletromagnética. t~m baixis· s ima atenuação de s innl :u é cem quilômetros e são muito difíceis de derivar. Essas características fizeram da fibra ótio o meio preferido para a transmiss.'o guiada de grande alcance, em especial para cabos submarinos. Hoje, muitas redes tclcfOniC:IS de longa distànda dos Estados Unidos c de ou tros paiscs usam exclusivamente fibras óti· cas, que também predo minam no backbo ne da Internet. Co ntudo, o alto custo de cqu•p:~men tos óu cos- como transmissores, receptores c comut;tdores- vem impedindo sua ulilizaç-.lo para transpo rte a curta dist
(anais de rádio terrestres Canais d e ráelio carregam si nais dcmro do especlro eletromagnéti co. São um meio atraente porque sua insta· lação n;lo requer cabos físicos, podem :uravessar paredes, d;\o conecti vid
bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------As tecnologi:IS u\N sem Oo descrit:IS na seção 1.2.2 utilizam canais de r.klio local: :IS tccnologi:IS de are>so em telefone celular utilizam canal de r.ldio de longo alcance. Abordaremos can;tis de r.ldio dctalhadamcntc no Capímlo 6.

(onois de rádio por satélite Um s:lltlitc de comunicaç-.\o liga dois o u mais ttanSmissores-rcccptores de micro-ond:IS baseados na Terra, dcnommados estações terrestres. Ele recebe transmissões em uma faixa de frcquencia, gera no\'amcntc o sinal usando um repetidor (sobre o qual falaremos a seguir) c o transmite em outra frequencia. Sattlitcs podem prover taxas de transmtss
1.3 Onúcleo do rede Após termos examinado a periferia da lmcrnct , \'amos agora nos aprofundar 111315 no núcleo da rede- a rede de comutadores de paco te c enlaces que inu:rconectam os sistemas finats da Internet. Os nuclcos da rede aparecem destacados em cinza na Figura 1.1 1.

1.3.1

Comutação de circuitos e comutação de pacotes

Há du:IS abordagens fundamcntnis para locomoção de dados através de uma rede de enlaces c comutadores: comuHtçào de circuitos c comutação de pacotes. Em redes de comuta<·ào de circuitos. os recursos necessários ao longo de um caminho (lmrfers. taxa de transmissão de enlaces) para prover comun icaç:'lo cmrc os sistemas fimtis são n·srrvaclos pelo pcríO
bow4tto4ic~ Copítulo 1

Redes de compulodoras e o Internei

19

Rede móvel

ISP local ou regional

I

Rede doméstica

Rede c:o~porati11a

Figura 1.1 1 Onúcleo da rede Hoje, a Internet é a qulntessfncia das redes de comutação de pacotes. Considere o que ocorre qu:mdo um s istema final quer crwiar um pncote a ouuo sistem;~ final pela Internet. Como acontece na connuaç:\o de drcuitos. o p:1cote é transmitido por uma Série de enlaces de comunlca~'i\0. Mas, na comut:lç:lo de pacotes, o pacote é em•iado à rede sem reservar nenhuma largura de oond:t. Se um dos enlaces estiver congestionado (>Orque outros pacotes precls;~m ser transmitidos pelo enlace ao mesmo tempo, ent;\o nosso pacote terá de esperar em um buffcr na cxtremrdade de origem do enlace de transmissi\o e sofrer:i um atraso. A Internet faz o nrdl1or tsfor(o para entregar os dados prontamente, mas não dá nenhuma garantia. Nem todas as redes de telecornunicaç-.lo podem ser classificadas exatamente como redes de comutação de circuitos purns ou redes de comutaç-.lo de pacotes puras. Não obstamc, essa classificação fundamental em redes de comutação de pacotes e de comutação de circuitos é um excelente ponto de partida para a compreensão da tecnologia de redes de telecomunicação.

bow4tto4ic~ Redes de compu tadores e o lnte ;.;rn;.;e;.;.t_________________________

(omutoçõo de circuitos Este livro ~ sobre redes de computadores. Internet c comma~âo de pacotes. c não sobre redes telefônicas c comuta1,:ão de circuitos. Mesmo assim, é importante ente nder por que a Internet c outras redes de computadores usam comutaç-.lo de pacotes, c não a tecnologia mais (l'Qdicionotl de comutaç-Jo de circuitos utilizada nas redes tclcronic-dS. Por essa raz•\o, examinaremos agora resumidamente a comutaçlo de ctrcuitos. 1\ Ftgura 1. 12 ilustra uma rede de conm mç-.io de circuitos. Nessa rede, os quatro comutadores de circuitos estão

interconcctados por quatro enlaces. Cad<1 um desses enlaces tem fi circuitos, de modo que cnda um pode su portar fi conexocs simult:1neas. Cada um dos sistem as finais (por exemplo, PCs c csta1,·õcs de trabalho) está conect.
Multlplexaçõo em redes de comutação de circuitos Um ctrcuito é nnplementado em um cnlnce por multiplcxaç;lo por divisãO de frequencin (jiC
mulliplt:
Em um enlace TOM, o tempo é dividido em quadros de duração fixa, c cada quadro é dividido em um número fixo de compartimentos (slors). Quando estabelece uma conexão por meio de um enlace. a rede dedtca à conexão um comp.1rumento de tempo em cada quad ro. Esses comparttmentos s:lo reservados para o uso cxclusi\'O dessa conexão. c um dos compartimentos de tempo (em cada quadro) fica disponi\'cl para transmi tir os dados dela. i\ Figura 1.13 ilustra as técnicas FDM e TOM para um enlace de rede cspectfieo que s uporta até quatro cir-

cuitos. Para FDM. o dominio de frequ!ncia é segmelllado em quatro faixas. cada uma com largura de banda de 4 kHz. Para TOM , o domínio d e tempo é segmentado em quadros. cada um com quatro compartimentos

SistetM fina l A

Cada enla
- Conex.\o fim a fim entre sistemas finais A e 8, usando um •
SostetN fonal 8

Figura 1.12 Uma rede simples de comutoçõo de circuitos composto de quolra comutadores de circuito e quatro enlaces


Capítulo 1

2.1

FOM

+.

4KHz{l

r

4KHz{[

Enl<'lce

Frequ~nclo

•

TOM

Compartimento

Quadro Tempo

Legenda:

f:l Todos os compartimentos de número ·r

LJ sJo dedicados o um par transmissor/receptor especifico.

Figura 1.1 3 Com FOI.\, codo cilcuitodispõe continuamente de uma ho~õo do largura de bando. Com TOlA, coda circuito ~põe de todo o lorguJa de bando periodi
de tempo; a cada

Os defensores da comutação de pacotes sempre argumentaram que comutaç.lo de c1rcu1tos é d esperd ício, porque os circuitos dedil'ados ficam ociosos durante períodos de silencio. Por exemplo. quando um dos participantes de uma conversa telefônica para de falar, os recursos ociosos da rede (bandas de frcqu~nc1as ou comparti· mentos nos enlaces ao longo da rota da conexão) não podem ser usados por out r:tS conexões em curso. Para um outro exemplo de como esses recursos podem ser subu tilizados, considere um radiologista que usa uma rede de comuu1çao de Circ uitos para acessar remotamente uma s~ne de r-.tdiografias. Ele estabelece uma conexào. requi· sita uma 1magcm. examina-a c, em segu ida. solicita uma nov·a imagem. Recursos de rede s.lo atribu rdos à conexào, mas nào utilizados (isto é, são desperdiçados) durante o período em que o mdiologista examina a imagem. Oercnsorcs da comutaçno de pacotes tamb~m gostam de d es tacar que estabelecer circuitos fím a fim c reservar largums de banda fim a fim é co mplicado e exige softwares co mplexos de sínalizaçno pam coo rdena r a operaç-J.o dos comutad ores ao longo do caminho fim a IIm. Antes de encerrarm os es ta discussão sobre comu taçào de circuitos, vmnos examinar um exe mplo numérico que d eve rá esclarecer melhor o assumo. Vamos considerar o tempo que leva mos para crwlar u m :1rquivo de 640 kbits do sis tema final A ao sistema final B por uma rede de comuta1,.~1o de circuitos. Suponha que todos os enlaces da rede usem TOM de 24 compartimentos c tenham uma taxa de 1,536 Mbps. Suponha também que um circuito fim a fim leva 500 milíssegundos par-;~ ser ativado antes que A possa começar a trans mitir o arquivo. Em quanto tempo o arqu1vo será enviado? Cada circuito tem umn taxa de transmiss\o de ( 1,536 Mbps)/24 = ó-1 kbps: port:mto, demorar:\ (640 kbi ts)/64 kbps • 10 segundos para transmitir o arqu1vo. A esses 10 segundos adicionamos o tempo de ativaç;\o do circuito, resultando 10,5 segund os para o e1wío. Observe que o tempo de transmissão é independente do número de enlaces: o tempo de transmissão seria 10 segundos se o circuito fim a fim passasse por um ou por uma centena de enlaces. (0 atraso real fim a fim tam~m mclm um atmso de propagaç-.lo; ver Seç-.lo 1.-t.)

Comutação de pacotes Aplicações dist ribuídas trocam mensagens ao desempenhar suas tarefas. Mensagens podem conter qualquer característica que o projetista do protocolo queira. Podem desempenhar uma funr;.lo de controle (por exemplo, as

bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'------------------------.....mcn!klgcns 'oi' no nosso exemplo de comunícaç.\o entre pessoas) ou podem conter dados, ml como uma mensagem de c-mail. uma rmagcm JPEG ou um arquivo de áudio MP3. Em redes de computadores modernas. o originador fragmenta mensagens longas em porções de dados menores denominadas pacotes. Entre origem c destino, cada um desses pacotes percorre enlaces de cornunicaç-Jo c comuutdores de pacotes (há dois tipos principais de comutadores de p:~cotcs: roteadores c comutadores de camada de enlace). Pacotes são transmitidos por cada enlace de comuni· caç-.\o a uma taxa igual • de trnnsmissão totcll do enlace. A maroria dos comutadores de pacotes annazcna e rccm
A Figura 1.14 ilustra uma rede simples de comutação de pacotes. Nessa figura c nas subsequentcs, pacotes são representados por plac-as tridimensionais. A largura de uma placa representa o m\mero de bits no pacote. essa llgurn todos os pacotes tem a mes ma largura, portanto. o mesmo tam:mho. Suponha que os sistemas On:~ is A e B esteJam envmndo p;.u.-otcs ao sistema final E. Os sistemas finais A c B pnmeimmcntc enviarão seus pacotes por

Muhiplexaçllo ~

estatrstica

~~:-.

Legenda:

Pacotes

Figura 1.14 Comutação de pacotes

o

E


Redes de
23

enlaces Ethcrnct de lO Mbps au~ o prim~íro comutador de pacotes, que \'ai dirccion:\-los para o enlace de 1,5 Mbps, Se a taxa de chegada de pacotes ao comutador for maior do que a taxa com q ue o comutador pode reenviar pacot('S pelo enlace de sarda de 1,5 Mbps, oc:orrcrá congestionamcnto, pois os pacotes forma r.lo uma nla no buffcr de saída do enlace an tes de scr transmitidos para o enlace. Vamos analisar esse atraso mais dct:dhada mcntc na Scç.lo 1.4.

Comutação de pacotes versus comutação de circuitos: multiplexação estatística Agora qu e ja d esc re,·emos comutaç-Jo de pacotes e comutação de clrCuliOS, vamos comparar as duas. Oposito rcs da comuta~1\o de pacotes frcquememcmc argumentam que ela nilo é adequada para serviços de tempo real ( por exemplo, ligaçOes teldOnicas c videoconferência) por ca usa dl' se us atrasos fi m a fim variáveis e impre,•islveis (que se devem principalmente a a trasos de Ola variáveis c imprevisíveis). Defensores da commaç:1o de pacotes :ugumentam que ( l ) ela oferece melhor compartilhamen to de banda d o qu e comutaçlo de circ uit os c (2) sua implcmentaç:lo é mais si mples, rnais eficiente c mais barata do que a impl ementação d e corn u ta~-ão de circuitos. Urna discussào lm cress."lmc sobre comutação d e rracotcs e comutaç;\o de ci rcuitos 1><><1c ser cncom rada crn (Molinero-Fcrnandcz, 20021. De modo geral, quem não gos ta de perder tempo f:IZC IIdo rese rva de mesa em restaurames prefere comul:l\'fiO de p
Os exemplos acima ilustram duas maneiras pelas quais o desempenho da comutaç:lo de pacotes pode ser superior à da cornu taç;1o de ci rcuitos. Também d estacam a diferença cruc1al entre as duas rom1as de compartilhar a taxa de transmíssilo de um enlace entre várias correntes de brts. Comutação de ci rcullos aloca previamente a utilização do enlace de transmissão independentemente de demanda, com dcsperdicro de tempo de enlace desnecessário alocado e não utilizado. Comutação de pacotes, por outro lado, aloca utilização de enlace eor


ln;.;l~e;.;rn;.;e;.;.t_________________________

clcmcwcla. A capacidade de transmíssâo do enlace será compartilhada pacote por pacote someme entre usuários que tenham pacotes que precisam ser transmitidos pelo enlace. Tal compartilhamento de recursos por demanda (e não por alocação pré\•ia) às vezes é denominado m uhipkxaç:io estaustica de recursos. Embora tanto a comutação de pacotes quanto a comutação de crrcuitos predominem nas redes de tdeconnmicaç.\o de hoje, a tendência é, sem dúvida, a comutaç:\o de pacotes. Até mesmo muitas das atuais redes de teldonia de comutaç:\o de circuitos estão migrando lentamente para a comutaç-:lo de pacotes. Em especinl, redes teldõnrcas frequentemente usam comu tação de pacotes na parte cara de uma chamada telefônica para o exterior, isto é. na parte que n:\o é processada em tenitório nacional.

1.3.2 Como os pacotes percorrem os redes de comutadores de pacotes? Anteriormente dissemos que Ltm roteador conduz um pacote que chega em um de seLtS e nlaces de comunic-.tc;lo pam outro enlace. Mas como o roteador determina o enlace que deve conduzir o pacote? Nn verd<1de, isso c feito de di ferent(.'S maneiras por diferentes tipos de rede de computadores. Neste ca1>1tulo introdutó rio, desc:rc· ' 'cremos uma abord~•gc m popular, a saber, a abordagem cml>rcg;td;t pcl:1 Internet. Ntr In ternet, cada p<~cote que atravessa a rede contém o seu endereço de destino em seu cabeçalho. Como os endereços postais, esse endereço possui uma estruturo hierárquica. Quando um pacote cheg;:~ à um roteador na rede. o roteador examina urna p:rrte do endereço de destino do pacote c conduz o pacote a um roteador adjacente. Espccil'lcamcnte fa lando, cada roteador possui uma oosc de encaminhamen to que mnpcia o endereço de destino (ou panes desse endereço) para enlaces de saída. Quando um pacote chega ;tO roteador, este examina o endereço

c bLLSca sua ba c utiliz.ando cs c endereço de destino para cncomrar o enlace de sarda apropriado. O roteador, então, dirccrona o pacote ao cnl<1cc de saída. Vimos que um roteador usa um endereço de destino do pacote para indexar uma base de encamínhamemo e determirmr o enlace de saída apropriado. Mas essa afi rmaç-.lo tmz ainda outrn ques~;\o: como as bases de encaminhamento se configurnm? Elas sM configuradas manualmente em cada roteador ou a Internet utilíza um pr

Redes de compulodoru e o Internei

2.5

1.3.3 ISPs e bo
\I

""" ~

\I I

--

/

I\\"

Figura 1.1 5 Interconexão de ISPs

bow4tto4ic~ Redes de co11pu todores e o

ln;.;l~ e ;.; rn;.;e;.;.t_________________________

ciona, oflci:tlrnente, se u st:uus de nível l. Corno se costuma dizer , se você tiver de perguntar se é um membro de um grupo. provavelmente nao é. Um ISP de nível 2 normalmente tem ak'ancc regional ou nacional c (o que é importante) conccta-sc apenas a uns poucos ISPs de nf\•cl 1 (veja Figura 1.15). Assim, para alcançar uma grande parcela da Internet global, um ISP de nfvcl 2 tem de dirccion:u o tráfego por um dos ISPs de nfvel 1 com o qual está conectado. Um ISP de nível 2 é denominado um cliente do ISP de nfvcl 1 com o qu:tl está conectado, que, por sua vez. é denominado pron~dor de seu cliente. Mu itas empresas de grande pon c c insuturçOcs conectmn s uas redes corporativas diretamente a um pro,·cdor de nível l ou 2, tomando-se, desse modo, cliente daquele 1SP. O provedo r ISP cobra uma tarifa de se u cheme, que normal· mcmc depende da taxa de tra nsmissão d o enlace que interliga ambos. Uma rede de nível 2 também pode preferir conectar-se diretamen te a outras redes de mesmo nível, caso em qtte o tráfego po<>r uma rede de nível I. Abaixo dos ISPs de nível 2 estt\o os de n1 veis mais b:lixos que se conectam li 1nternct por meio de um ou mais ISPs de nível 2 c. na !Y.'rtc mais b<~ix:t ela luerarquia, estão os ISI's d e acesso. l'am compl icar a inda mais as coisas, a lguns provedo res de nfvcl 1 também s.:lo provedores de nível 2 (is to é, integrados vcnicalmc ruc) c ve nd em acesso para lntcmct diretamente a us uários ri nais c provedores de com etido, bem como os ISPs de níveis mais baixos. Quando dois ISPs estão lig:tdos di rct:uncnte um ao outro s;lo denomi nados p:trcs ( pecrs) um do outro. Um estudo imcrcss;.~ n te ISub raman l:tn, 2002 1 procura ddinir mais cx:l\amcntc a estrutura em níveis da Internet estudando su:t topologia em termos de relacionamentos cliente-provedor e e ntre parceiros ( peer-peer). P;ua uma díscussõlo m;us clara sobre esses relacionamentos, veja Van der Berg. 2008.

Demro da rede de um ISP, os pomos em que ele se conccLa a ouuos I Ps (seja abaixo. acuna ou no mesmo nível na hierarquia) s;\o conhecidos como pontos de prcscm:a (points of prrsrncc - POPs). Um POP é simplesmente um grupo de um o u m:tis ro tead ores na rede do 1SP com os quais roteadores em outros ISPs. ou em redes pertencentes a clientes do ISP, podem se conectar. Um provedor de mvel 1 normalmeme tem muitos POPs espalhados por diferentes localidades geográficas em sua rede c várias redes cliemcs c omros ISPs ligados a cada POP. Pam se conect:tr ao POP de um pro,·cdor, uma rede cliente nonnalmentc aluga um enlace de alta velocidade de um provedor de tclccomumcações de terceiros c conccta um de seus roteadores d•rctamentc a um roteador no POP do pro,·edor. Dois lSPs de nfvcl 1 também podem fo rmar um p:tr conectando um par de POPs. cada um pro,•eniente de um dos dois ISPs. Alé m disso, dois ISPs podem Ler vários pontos de emparelhamento conectandose um ao outro em dois ou mais de pares de POPs. Resumindo. n topologia da In ternet é co mplexa. consistind o em dezenas de ISPs de nivds 1 c 2 c milhares de lSPs de níveis mais baixos. A cobc:rtum dos JSPs é lxtstantc diversificada; alguns abrangem vários conliJientcs c oceanos c o ut ros se limita m a pequenas regiões do mundo. Os lSPs de niveis mais baixos conectam-se a ISPs de nfveis mais altos c estes (nonna imcntc) se interconccta rn uns com os outros. Usuários c provedores ele conteúdo sõlo clientes de ISPs de níveis mais bltixos e estes s-Jo clientes de ISPs de níveis mais altos.

1.4 Atraso, perda e vazão em redes de comutação de pacotes N:1 Seção 1.1 dissemos que a Internet pode ser vista como uma infraestrutura que fornec e serviços a aplic:tçõcs dístribufdas que são executadas nos sistemas finais. De modo ideal, gostarfamos que os sen•iços da Internet tro nsfcrís.l>em t:lntos dados quanto desejamos en tre dois sistemas finais, instantaneamente, sem nenhuma perda. Infeliz mente, esse é um objeth·o elusivo. algo inalcançávcl. Ao comrário drsso, as redes de computador. necessariamente. restringem a vazão (a quantidade de dad os por segundo que podem ser trans· feridos) e ntre sistemas finais. apresentam atrasos entre s istemas finais c podem perder pacotes. Por um lado, Infelizmente as leis fisicas da realidade introd uzem atraso e perda, bem como restringem a \':lzào. Por outro lado. como as redes de com putadores possuem esses problemas. existem mu itas questões fascinantes sobre como lidar com eles - mais do que q uestões suficientes para frequemar um curso de rede de com putadores e motivar centenas de teses de doutorado! Nesta seção, começaremos a examinar e quantificar atraso, perda e vazão em redes de compu tadores.


Redes de computadoras e o Internet

2.7

1.4.1 Uma visõo geral de atraso em redes de comutação de pacotes lembre-se de que um pacote começa em um sistema final (a origem), passa por urna série de roteadores e termina sua jornada em um outro sistema final (o destino). Quando um pacote viaja de um nó (sistema final ou roteador) ao nó subscqueme (sistema final ou rote;~dor), sofre. ao longo desse caminho. diversos tipos de atraso em cmlcr nó existente no c-.tminho. Os mais importantes deles são o atraso de processamento nodal, o atraso de rila. o atraso de transmiss:lo c o atraso de propagaç-lo; juntos, eles se acumulam p:~ra formar o atraso nodal total. rara entender a fundo a comutaç-lo de pacotes c redes de computadores, é preciso entender a natureza e a importância desses atrasos.

Tipos de atraso Vamos examinar esses atrasos no contexto da Figura 1.16. Como pane de sua rota rim a fim entre origem e d estino, um pacote ~ enviado do nó anterior por meio do rot~ulor A ~llé o roteado r 8. Nossa meta é caracteriza r o atrnso n odal no rotc:\do r A. No te que este tem mn enlace d e s;\fda que leva ao roteador B. Esse enlace é precedido de uma filr~ (t:r~mbém conhecid
Atraso de processamento O tempo requerido para examinar o cabeçalho do pacote e determinar para onde direcioná-lo é parte do atraso de process.111tcnto, que pode também incluir outros fatores, como o tempo necess..írio para verificar os erros em bits cxtstentcs no pacote que ocorreram durante a transmtSSào dos btts desde o nó anterior ao roteador A. Atrnsos de proccss:lmento em roteadores de alta veJoctdadc nonnalmente s:\o da ordem de microsscgundos. ou menos. Dcpots desse processamento nodal, o roteador dtreciona o pacote à fila que precede o enlace com o rotead or B. (No Capnulo 4, estudaremos os detalhes da operação de um ro teador.)

Atraso de filo O pacote sorre um atraso de flla enquanto espera para ser trans miudo no enlace. O tamanho desse atraso para um pacote espcctfico dependerá da quantidade de outros pacotes que chegarem antes c q ue já esti verem na Oln CS j) tmndo pela transmissão. Se 11 fila esti ver vm:ia, c nenhum o utro pacote estiver sendo transmitido naquele momento, cntt\o o tempo de filo de nosso pacote será zero. Por outro lado, se o trãrcgo estiver pesado c houver mu itos pacotes também cspcmndo para ser transmitidos, o atraso de fi la será longo. Em breve, veremos que o mi mero de pacotes que um dctcrmin:~do pacote provavelmente Citcontmrá ao chegar é uma funç~o da intcnsi-

~ Propag~ao Fila

Tr ansmissao

(esperando por transmiss.\o)

Figura 1.16

OoiToso nodal no roteador A

8

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------dadc c da n:uurcz,a do tráfego que rsú chegando à fila. I\a pn1lica, atr.ISOS de fila podem ser da ordem ele micro a milissegundos.

Atraso de transmissão Adrnhlndo·se que pacotes são transmitidos segundo a estratégia de Mo primeiro a chegar será o primeiro a ser proccss:1do~,como é comum em redes dr comlllaç-.lo de pacotes. nosso pacote somente podrrá ser transmitido depois que todos aqueles que chegaram an tes tenham sido enviados. Denonnnemos o tamanho do pacote como L bits c a velocidade de transmissão do enlace do roteador A ao roteador B como R bitsls. A '·cloddade R é determinada pela ''elocidade de transmissão do enlace ao roteador B. Por exemplo, parn um enlace Ethem et de 10 MbJ>S, a velocidade é R· 10 Mbps; para um enlace Ethcrnct de 100 Mbps, a velocidade é R· 100 ~·tbps. O atraso d e transmissão ( també m denominado atraso de armazenamento c reenvio, como d iscuti mos na Seção 1.3) é UR . Esta é a quantidade de tempo requerida para empurrar (ísto é, transmitir) todos os bits do pacote para o enlace. Na prática, atrasos de transmissão são comumente da ordem de micro a milissegundos.

Atraso de propagação Assim que é lanç:1do no cnh1ce, um bit precisa se propagar alé o roteador B. O tempo necessário para propagar o bit desde o Início do enlace até o roteador B é o atrnso de propagaçào. O bit se propaga à velocidade de propagação do enlace, a qual depende do meio físico do enlace (isto é, fibra ó tica, par de fios de cobre trançado c assi m por c.liantc) c está na faixa de 2 · l OS m/s a 3 · 10~ m/s

que é igual li velocidade da luz, ou um pouco menor. O atraso de propaga~"tlo é a distancia entre dois roteadores dividida pela velocidade de propagação. Isto é, o atraso de propagação é cVs , onde d é a distância entre o roteador A c o roteador B. c s é a ,•clocidade de propagaç-.lo do enlace. Assim q ue o ulumo bh do pacote se propagar até o n ó B, ele e todos os outros bits precedentes do pacote ~rão armazenados no ro teador 8. Enú\o, o processo inteiro continua, agorn com o roteador B executando a rctrnnsmissào. Em redes WAN, os atrasos de propagação são da ordem de milisscgundos.

Comparação entre atrasos de transmissão e de propaga~õo Os principiantes na área de redes de computadores às vezes têm dificuldade paro entender a diferença entre atraso de transmisst\o c atraso de propag<~ç~o. A diferença é sutil, m:ts impon:mte. O atraso de t ransmiss~o é a quantidade de tempo requerida par.t o ro teador empurrar o pacote para fora; é umn funç-.lo do comprimento do pacote c dn taxa de transmissão do enlace, mas nada tem a ver com a distância entre os dois roteadores. O atraso de propag:tç;lo, por outro Indo, é o tempo que leva para 11111 bit se propagar ele 11111 rotcndor mé o scguime; é uma função da distll ncla entre os dois ro teadores, mas nada tem a ver com o comprimento do pacote o u com a taxa de tra nsmissão do c nl:~ce. Podemos esclarecer melhor as noções de tll(asos de trai\Sihlss\o c de propagação com uma analogia. Considere uma rodovia q ue tenha um posto de pedágio a cada 100 quíiOmctros, como mostmdo na Figura 1.17. Imagine que os trechos d:t rodo,·ia entre os postos de pedágio sejtun enlaces e que os postos de pedágio sejam roteadores. Suponha que os carros trafeguem (isto é, se propaguem) pela rodovia a uma velocidade de lOO km/h (isto é, qttando o carro sat de um posto de pedágio, acelera instantaneamente até 100 km/h c mantém essa velocidade entre os dois postos de pedágio). Agora, suponha que dez carros vi:~cm em comboio. um atrás do outro, em ordem nxa. Imagi ne que cada carro seja um bil e que o comboio seja um pacote. Suponha ainda que cada posto de pedágio libere (isto é. transmita) urn carro a cada 12 segundos, que seja tnrdc da noite c que os carros do com boto SCJll lll os untcos na estrada. Por fim. suponha que, ao chegar a um posto de pcd:\gio, o primeiro carro do comboio aguarde na em roda até que os outros nove chcgllt'lll c formem uma fila atrás dele. (Assim. o comboio mtciro deve :.cr 'armazenado' no posto de pedágio an tes de começar a ser 'reenviado'.) O tempo nccess.-\rio para que todo o comboio passe pelo posto de pedágio e volte à estrada é de (lO carros)/(5 carros/mmuto) =2 minutos. Esse tempo é análogo ao atraso de transmissão em um roteador. O tempo necessário para um carro trafegar da


Comboio de dez carros

Pedágio

Redes de compulodores e o Internei

100km

29

IOOkm--

Ped6gio

figura 1.17 Analogia do comboio saada d e um posto de pedágio até o próximo posto de pedágio é de (100 km)/(100 km/h) .. 1 hora. Esse tempo é análogo ao arraso de propagação. Portanto, o tempo decorrido entre o instante em que o comboio é 'armazenado' em freme a um posto de pedágio até o instante em que é 'arma zenado' em fren te ao seguinte é a so ma do atraso de cransmisst\o c do atraso de propagaçüo- nesse exemplo. 62 minutos. Vamos explorar um pouco mais essa analogia. O que aconteceria se o tempo d e libcraç:\o do co mboio no pos to de ped;lgio fosse maior do que o tempo que ltm carro le,•a para trafegar cn1rc dois postos ? ror exemplo. suponha que os carros trafeguem :\uma velocidade de 1.000 km/h c que o pedágio libere um ca rro po r mlnu1o. Ent:\o, o :umso de trânsito entre dois poscos de pedágio é de ó minutos c o tempo de liberação do co mboio no posto de pedágio é de 1O minutos. Nesse caso, os primeiros carros do comboio chegar;' o ao segundo posto de pedágio ames que os (dtimos carros saiam do primeiro posto. Essa s ituaçi\O também acontece em redes de comu tação de paco tes - os pnmciros bits de um pacote podem chegar a um roteado r enquanto muitos dos remanescentes aind:t cst<\0 esperando para ser transmitidos pelo roteador prcccdcm c. Se uma imagem vale mil pala\•rns, entAo uma animaç-Jo vale um milhi\O. O Co mpanion Website apresenta um a plicati vo imcratívo jav:t que ilustra c co ntraSta o atraso de transmissão c o mraso de propaga~-;lo. Recomenda-se que o leitor visnc esse aplicativo.

Se dP'tilrl. , d,-•.• d... ... c c/N_ forem, respectivamem e, os atrasos de processamemo, de nta, de transmis~lo e d e .p•-,, propagaç.lo, ent."o o atraso nodal total é dado por:

d....w = d,..,.. +di!. +,~.._ + d,...., A contribuição desses componentes do atraso pode variar significativamente. Por exemplo, d....,. pode ser desprczlvel (por exemplo, dois mierosscgundos) para um enlace que conccta dois ro teadores no mes mo camf'IU unh•ersHário: co ntudo, é de centenas de milissegundos para dois roteadores interconectados por um enlace de s:u~lite geoestacionário c pode ser o tenno dominan te no d~oo~.•· De maneim semelhante, 1l..,,., pode variar de desprcztvcl a significativo. Sua contribu ição normalmente é dcsprczlvcl para velocidades de trans missão de 1O Mbps c mais altas (por exem plo, em LANs); co nuado, pode ser de centen as de mtlisscgundos para grandes pacotes d e lmernct enviados por enlaces de modcms d iscados de baixa velocidade. O atraso de processamento, ti,..,,., é quase sempre dcsprczfvcl; no cnt:mto, tem forte influência sobre a produtividade 1n~xima de um roteador, que é a vclot:idttdc nHixim:1 ~:om que ele pode cncaminhnr pacotes.

1.4.2 Atraso de filo e perda de pacote O mais complicado c itucressantc com ponente do atraso nodal é o atraso de flln, d1,... Rcalmencc, o atraso de fila é tão impo rtante c mtcrcssantc em redes de com putadores que milhares de artigos e numerosos li vros j:! foram escri tos sobre ele IBertsck:ts. l99 1; Daigle. 1991: Klcinrock, l975, 1976; Ross , l995l . ' cscc livro, faremos apenas um:t discuss.1o intuitiva, de al to nfvel, sobre o atraso de nla; o leitor mais cu rioso pode consultar alguns dos livros citados (ou at~ mesmo escrever uma tese sobre o ass un to!). Diferentemente dos trés outros a trasos (a saber, d, ~ . d,._ e <1,. 11), o aLraso de fila pode variar de pacote a pacote. Por exemplo. se dez pacotes chegarem a uma fila vazia ao mesmo tempo, o primeiro paco te transmiudo não sofrer:i nenhum atraso, ao passo que o ultimo pacote sofrerá um a traso relativamen te grande (enquan to espera que os outros nove pacotes sejam transmitidos). Por conseguince. para se caracterizar um atmso de fthl , normalmente são uulizadas med1ções estatisticas, tais como atraso de fila médio, variãncta do atraso d e nta e a probabilidade de ele exceder um vai or especificado.

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Q uando o atraso de llla ~grande c quando é insignificante? A resposta a css:\ pergunta depende da velocidaM de trans missão do enlace, da taxa com que o tráfego chega à e de sua m!lureza, isto é. se chega intermitentemenu~. em raJadas. Para entendermos melhor, vamos adotar I, cnt('lo a velocidade média com que os bits chegam à flla cxceder.l a velocidade com que eles podem ser transmitidos para fora da fila. Ness.1 si tuação desastrosa. a fila tenderá a aumentar sem limite c o atraso de fila tenderá ao infini to! Por conseguinte. uma das regras de ouro da engenharia de tmrcgo é: rn·ojrte sru sistruw clf ruo{fo que

ma

a irllcnslt/ll(fr tlr trtlfrgo ndo srja rnuior
Figura 1.18 Dependência entre otroso de filo médio e intensidade de tráfego


Redes de
31

um amncmo muito maior no atraso, em tennos de porcentagem. Talvez voe~ já tenha jXrccbldo esse fenômeno na estrada. Se voe~ dirige regularmente por uma estrada que normalmente está congestionada. o fato de ela estar sempre assim signHlca que a intensidade de tráfego é próxima de 1. Se algum even to caus:tr um tráfego ligt>ira· mente maior do que o usu<~l , 415 demoras que voce sofrerá poderJo ser enormes. Para compreender um pouco mais os atrasos de ma, visite o Compamon Website, que apresrnta um aplicath·o Java interativo. Se voce aumentar 3 taxa de chegada do pacote o suO ciente de forma que 3 intensidade do tráfego exceda l. voct verá a flla 3Umentar ao longo do tempo.

Perda de pacote Na discussào anterior, admit imos que a nla t capar de comer um nümero infinito de pacotes. • 3 realidade, a capacidacle da fila que precede um enlace é nnita. embora a sua fonnaç:lo dependa bastante do projeto c do custo do comutador. Como a capacidade da fila é. finita , na verdade os atrJSOS de pacote n:'lo se aproximam do infinito quando a inte nsidade de tráfego se aproxima de 1. O que re:1lmente m:ontcce é que um pacote pode chegar e enco ntmr tuna l'ila cheia. Sem esp"ço dispomvcl p-.lra armazená-lo, o roteador descartará esse pacote: isto c. ele ser:i perdido. Esse excesso em uma fila pode se r observado novamen te no :tplíc:u lvo Java qu~tndo a intensidade do tráfego é maior do que 1. Do ponto ele vista de um s istem;\ final , uma perda de pacote é vísta como um p;,<.:otc que foi transmitido puro o nüclco ela nxlc, mas sem nun ca ter emergido dele no de-stino. A frn(.'11o de pacotes perdidos a umenta com o aumento da imensidade de tr:ilego. Por conseguintr, o dcs<'mpcnho r m um nó é frtqucntcmeme mecl1do não apenas em tcm1os de atraso, mas também em termos da probabilidade de perda de pacotes. Como discutiremos nos caprtulos subsequcmes. um pacote pcrd1do pode ser retransmilido fim :1 p:m1 garantir que todos os dados sejam finalmente Lrnnsrcridos da origem :10 local de destino.

nm

1.4.3 Atraso fimo fim Até o momento, nossa discuSSão focalizou o:uraso nodal, isto t, o atraso em um unico roteador. Concluiremos essa discussão considerando brevemente o atraso da origem ao destino. Para entender esse conceito. suponha que haja N- I roteadores entre a máqu ina de origem c a máquina de destino. Imagine tamb6n que a rede não esteja congestionada (c, portanto, os atrasos de fila sejam desprezíveis). que o atraso de processamento em cada roteador c na máquina de origrm seja d'""'. que a taxa de trnnsnúsSõlo de S.'lída de cada roteador t da máquina de origem seja R bitsls c que o atraso ele propagação em cada enlace seja d ....,. Os atr-JSOS nodais se acumulam e resultam em um atraso fim a fim

d1• 11 = N (dr,.,. + d,r,.. + d.,..,.) onde, mais uma vez, cl,,,, • UR c L ~ o tamanho do pacote. Convidamos você a generalizar essa fórmul3 para o

caso de atrasos hcterog~ncos nos nós c para o caso de um
Traceroute Pnra perceber o que é realmen te o atraso em uma rrde de co rnpntadorcs, podemos utilizar o Trncerome, programa de ditlgnóstico que pode ser cxecut.ado em qua lquer máquina d:1 Internet. Q uando o usuário especi· fica um nome de hospedeiro de destino. o programa no hospedeiro de origem envia vários JYo1COtCS especiais em dir
pedeiro de destino recebe o pacote N, também envia uma mensagem à origem, que registra o tempo t:ranscorrido entre o envio de um pacote e o recebimento da mensagem de retorno correspondente. A origem registra também o

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------nome c o endereço do roteador (ou do hospedeiro de destino) que rctorna a mensagem. Dessa maneira, a origem pode reconstruir a rota tomada pelos pacotes que V<1o da origem ao destino c pode determinar os atrasos de ida e volta para todos os roteadores mtervenicntcs. Na prática, o progmma Traceroute repete o processo que acabamos de descrever tr~ vczc:.. de modo que a fonte en,ria, na ''erdade, 3 · N p;tcotcs ao destino. O RFC 1393 descrc\'e dctalhadamcnte o Traceroutc. Eis um exemplo de resultado do programa Tracerome, no qual a rota traçada ia do hospedeiro de origem gaia.cs.umass.edu (na Umversidade de Massachuseus) até cis.poly.cdu (na Polytechmc Unh•crsity no Brooklyn). O resultado tem seis colunas: a primeira coluna é o valor n descrito aci ma. isto é, o numero do roteador ao longo da rota; a segunda coluna é o nome do roteador; a terceira coluna é o endereço do roteador (na forma xxx.xxx. xxx.xxx); as ühimas tr~ ~olunas são os atrasos de ida c volta pam tr~ teru:~th·as. Se a fo111e receber menos do que trb mensagens de qu:~lquer roteador detcnninado (devido à perda de pacotes n:~ rede). o Traceroute coloca um asterisco logo após o ní1mcro do roteador c registra menos do que tr~s tempos de duraçi\o ele viagens de ida c volm para aquele roteador. 1

cs·g1~

(128.119 . 240 . 254 ) 1.009 ms 0 .899 ms 0 . 993 ms

2 128.119.3.154 (128 .11 9 . 3 .1 54) 0 . 931 ms 0 . 441 ms 0 . 651 ms 3 border4·rt·g11·3.gw.umass.edu (128 .11 9 . 2 .194) 4 acr1·ge·2·1 O.Soston . cw . ne t

l.OJZ

r~s

0 .484 11s 0 . 451 ms

C208 .172 . 5l.l29) 10 . 006 ms 8 .1 50 ms 8 .460 ms

5 agr4·1oopback.llewYor k. cw.ne t

(206 . 24 .194.104)

6 acr2·1oopback.llewYor k. cw.net

(206 . 24 .1 94 . 62>

12.272 riS 13 . 225 ms

14.344 m!>

13.267 ms

12.292 "s 12.148 ms

7 poslO·Z.coreZ.IIewYorkl.LevelJ.net CZ09 .Z44 . 160.133) 1Z.Zl8 ns ll.8Z3 ros 11.793 ms 8 glge9·1·52.hslp&ccessl.NewYorkl.leve13.net 9 pO·O.polyu . bbnplanet . net

C64.159 .1 7.39l

(4.25 .109.122) 12.716

10 cls.poly.edu <128.238.32 . 126) 14. 080

~s

~s

13.052

13.035 ms

13.081 ms ~s

12.802

11.556 11s 13.297 rr.s

12.786 ms s

'o exemplo anterior há nove roteadores entre a origem c o destino. Quase todos eles t~m um nome c todos t~m endereço. Por exemplo, o nome do Roteador 3 é border4-rt-gi·l·3.gw.um:~ss.cdu c seu endereço é 128.119.2.194. Examinando os dados apresentados para esse roteador, verincarnos que na primeiro das Ires tcntauvas, o atraso de ida c volta entre a origem c o roteador fo• de 1,03 milisscgundos. Os mrasos para as duas tcntauvas subsequcntcs foram 0,48 c 0 ,45 milisscgunclos e incluem todos os atrasos que acabamos de discutir, ou seja, atrasos de transmiss
Sistema final, aplicativo e outros atrasos Além dos atrasos de process;unento, transmissão e de propagaçilo, os SIStemas fina is podem adicionar outros atrasos significativos. Os moclcms discados apresentam um atraso de modula~'ôlo/codific:~ção, que pode ser da ordem de dczemlS de rnicrossegundos. (Os alnlSOS de modulação/codlficaç-lo p;tra outros tecnologias de acesso inclumdo a Ethernct. o modem a cabo e a DSL - são menos significativos c normalmente desprczf\'cis.) Um sistema fi11


33

remetente deve primeiro carregar um pacote com voz digitalizada c codificada antes d e trans mitir o pacote para a Internet. A etapa de carregar um pacote- chamada d e atraso de empacotamento - pode ser significativa e ter impacto sobre a qualidade visível pelo usuário de u rna chamada VoiP. ~ assunto será explorndo mais adiante nos excrcfcios de Oxaç:1o no final deste c:-.-prtulo.

1.4.4 Vazão nos redes de (Omputodores Alf m do atraso c da perda de pacotes, outrn medida de desempenho importan te em redes de co mputadores é a vazão a fim . Para definir vaz;lo, considere a transfcr~ncia de um arqui\'O grande do Hospedeiro A para o Hospedeiro B através de uma rede de computadores. Essa transrerêncm pode ser , por exemplo, um clipe extenso de um parcei ro p;1ra outro por meio do sistema de compartilhamento P2P. A \'l1Z11o ins tantânea a qu:~lqucr momento é a taxa (em bits/s) em que o llospcdciro B está recebendo o arq uivo. (Muitos aplícatívos , incluindo muitos s istemas de compartilhamento P2P, ex i~m a vaz.i\o insta man ca dumnte os downloads na int erface elo usuário- talvez voe~ já tenha observado isso!) Se o arquivo consistir em F bits e a trnnsfer~ncia levnr Tsegundos para o llospl'Ciciro D receber todos os F bits , então a vazilo m&:lia da tronsferencia elo r~rqu i vo é Frr bits/s. Para algunms ap licllÇÔCS, I:OiliO a telefonia via Internet, é ciC$Cjávclter um atraso ooixo c 111113 \lôl%<10 instant;lncrt acima d e ;tlgum limiar (po r exemplo, superior a 24 kbps para tclcfonhl via Inte rn et, c s uperio r a 256 kbps para alguns aplicativos de vfclco em ICllliXl rea l). Para outras aplicações, inclu indo as ele transfe r~ ncia de arquivo, o atraso não é importante, mas~ recomendado ter a vazão mais alta possfvcl.

nm

Para obter uma visão mais detalhada, va mos ana lisar alguns exemplos. A Figura 1. 19 (a) mos tra dois sistc· mas finais , um servidor c um cliente, conectados por do is enlaces de comu nicação c um roteador. Considere a vazão para uma transferência de arquivo elo servidor para o clie nte. Suponha que R, sej:~ a taxa do enlace t'ntre o rote:1clor c o cliente; e R, seja a taxa do enlace entre o roteador e o dit>nLe. Imagine que os (micos bits enviados na rede in teiro sejam os do servidor parn o cliente. Agorn ,·em a pergunta, nes te cenário idcrtl , qual é a \'llZão scrvador-para-clientc? Para responder a ela, pense nos balS como um llctuiclo c nos enlaces de comunicação como wnos. Evidentemente. o servidor nào pode enviar os bits a tro vfs de seu enlace a uma taxa mais rápida do qu e R, bps c o roteado r não pode encaminhar os bits a u ma taxa mais rápada do que R. bps . Se R, < R,, entáo os bits envi ados pelo se rvidor irão "corre r~ diretamente pelo roteador c chegar no cliente a uma taxa de R,bps. Se. por ou tro lado, R, < R,, então o roteador não poderá encamanhar os bus tão rnpidameme quanto ele os recebe. Neste caso. os bus so mente deixarão o roteador a uma taxa R,. dando uma vaz.lo fi m a fim de R, (Observe tam!X m que se os bitS contimtarem a cheg;~r no roteador a uma t.'\Xa R,. c continuarem a deixar o roteador a um:l taxa R,, o aclim ulo de bits no roteador cspcmndo parn trnnsmlss:lo ao cliente Só aumentará uma sit uação, na ma io ri a das vezes, indesejável!) Assim, para essa rede si mples ele dois enlaces, :1 vazão é mfn (R,, R.f , ou seja. é a taxa de transm iss:\o do enl ace de gargalo. Após determinar a vazão, agora podemos

R, ~rvidor

Cliente

Servidor

Cliente

a.

b.

Figura 1.19

Vozõo poro uma transferência de arquivo do servidor oo cliente

bow4tto4ic~ Redes de compu tadores e o lnte ;.; ro;.;e;.;.t_________________________

aproximar o tempo que leva para transferir um arquivo grande de F bits do servidor ao cliente corno F/m!n IR,. R,.J. Para um exemplo especifico. suponha que voe~ está fazendo o dow n lo:~d de um arquivo MP3 de F= 32 milhões de bits, o servidor tem uma taxa de transmis~\o de R,= 2 Mbps. c você tem um cnl:tce de :~cesso de R, = I Mbps. O tempo necessário para transferir o arquivo é, c mão, 32 segundos. Naturalmente essas expressões parn tempo de vazão c de transferência s."\o apenas aproxi mações, já que elas não contabilizam assuntos rela· cionados a protocolos e pacotes. A Figum 1.19 (b) agorn mostra uma rede com N enlaces entre o scrv1dor e o cliente, com as taxas de trnnsmi~\o de N enlaces sendo R, , ~ •... , R,, . Aplicando n mesma análise da rede de dois enlaces. descobrimos que a v:~zão pam uma tmnsfcrêncía de arquivo do servidor ao cliente é mfn IR,, Rl • .... R, I. a qual é novamente a taxa de transmissão do enlace de gargalo ao longo do caminho entre o servidor c o cliente. Agorn considere outro exemplo mo tivado pela Internet de hoje. A Figurn 1.20 (a) mostrn dois sistemas finais, um servidor c um cliente. conectados a uma rede de comptnadorcs. Considere a \r:'IZ!Io pam uma trnnsfcrencia de :1rqtLivo do sen•iclor :10 cliente. O servidor está conectado à rede com um en l
Para um exemplo nnal, considere a figura 1.20 (b) na qual existem lO servidores c 10 clientes conect:~dos ao nuclco d:1 rede de computadores. Neste exemplo. lO downloads simultaneos estão sendo realiU~dos, envolvendo lO pares de clientes-servidores. Suponha que esses lO downloads sejam o unlco tráfego na rede no momento presente. Como mostrndo na figurn, há um enlace no núcleo que é atrnvCSSlldo por todos os lO downloads. Considere R a taxa de tmnsmissilo desse enlace. Suponha que todos os enlaces de acesso do serv1dor possuem a mesma taxa Servidor

Cliente c).

Figura 1.20

lO Clientes

b.

Vazão fim o fim: (o) Odiente baixo um arquivo do seiVidor; (b) 1Oclientes fozem odownlood com 1OseiVidores


Redes de comput adores e o Inter net

R,. todos os enlaces de acesso do cliente possuem a mesma taxa R, e a taxa de

35

t ransm iss~o

dr todos os enlaces no nucko- com exceç-.lo de um enlace comum de taxa R- sejam muito maiores do que R,. R, e R. Agora pergumamos, qua1s s;lo as \'
=

=

Os exemplos na Figura 1.19 e Figu ra 1.20 (a) mostram que a \r:Jzâo depende das taxas de trar\Smlss:lo dos enlaces sobre as quais os dados correm. Vimos que quando n:lo hâ tráfego interveniente, a vazão pode simplesmente ser aproximada corno a taxa de transmissão mínima ao longo do caminho ent re a origem c o local de d estirto. O e>:ernp lo mt Figura 1.20 (b) mostra q ue, de maneim geral, a vaz~o de pende n~o so mente das taxas de tr:lllsm lss~o dos crtlaccs ao longo d o c.- min ho, m:\S também do tráfego irucrveniemc. Em cspcci:~ l . um en lace com u ma alta Lu>:a de trunsmlss;"\o pode, todavia, suo cnlncc de gargalo p:mt uma tmnsfcr~ncia ele arq uivo, t
1.5 Camadas de protocolo e seus modelos de serviço Até aqui, nossa discussão demonstrou que a lntcmct é um sistema c,\11Cn1Cmlrnlc complicado c que possui mu itos componentes: inúmeras aplicações e protocolos. vários tipos de sistemas finais c conexões emre eles, roteadores. além de vários tipos de meios físicos de enlace. Dada css.1 enonnc complexidade, há alguma t'Sperança de organizar a arquitetura de rede ou, ao menos. nossa discuss;lo sobre ela? Felizmente. a resposta a ambas as pergu ntas é sun.

1.5.1 Arquitetura de camadas Ant t'S de tentarmos organizar nosso raciocínio sobre a arquitetura da Internet, \'amos procurar uma analogia h um:ma. Na verdade. lid:unos com sistemas complexos o tempo todo em nosso dia a dia. Imagine se alguém pedisse que voe~ dcscrc,•csse. por exemplo. o sistema de uma companhia aérc-.t. Corno vocé encontraria a estru · tura para descrever esse SIStema complexo que tem agencias de cmiss.lo ele pass..1gens, pessoal p:1ra cmbarcM a b:tgagcm p:u:t fiatr no po rt~o de embarque, pilotos, aviOcs, controle de tráfego aéreo c um sistema mu ndial de roteamen to de acron:wes? Um modo de desc rever t'Sse sis tema poderia ser aprcscm:~r a relação d e uma série de ações que vocé realiza (ou q ue o mros rea lizam para voe~) quando voa por urna empresa aérea. Voe~ compra a passagem, despacha suas malas, dirige-se ao portão de embarq ue e, llnalmente, cnLra n o :~vi:lo. que dccol:~ c segue urn a rota :ué seu destino. Após a aterrissagem, \IOcf desembarca no pon~o des ig11:1do c rccu i>Cra Sltas malas. Se a viage m rol ruim. ''od reclama na agenda que lhe ve ndeu a passagem (esforço em v;lo). Esse cenário é ilustrado na Figura 1.2l. Já podemos notar aqui algumas an:~logias com redes de çomp utadores: voté está sendo dcsp:~c hado da ongcm :10 destino pcht tompan hi:~ atre<~; um pacote é despachado da máquin:1 de o rigem à máquina de destino na Internet. Mas essa não é cxat;lmcntc a analogia que buSG<~mos. Estamos tentando cncontmr alguma estl ulura na Figum 1.21. Observando essa Ogum. notamos que há u ma fu nç;lo referente à passagem em cada ponta: há também uma funç:lo de bagagem para passageiros que já apresema ram a passagt'm c urna funç:lo de portüo de embarque para passageiros que já ap resen tara m a passagem c dt'Spacharam a bagagem. Para passageiros que já pass;tram pelo portão de cmb.1rquc (isto é, aqueles que já a presen tara m a passagem, despacharam a bagagem e pa s:~ram pelo port;lo) . há uma fu nção de decolagem c de atcrnssagem e. durante o voo. uma func.':'lo de rotea mento do avião. Isso sugere que pod emos examinar a funcionalidade na Figura 1.2 l na horizontal, como mostra a Figura 1.22.

bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'------------------------.....-

Po»s.1gem (comprar)

Pass.lgem (reclamar)

Bagagem (despachar)

Bagagem (recuperar)

PonOM (m~barcar)

Ponoo (desembare~rl

Oecol~~gem

Roteamento da aeronave



Figuro 1.21

Umo ~agem de o'liõo: o~ões

A Figura 1.22 d ividi u a funcionalidade da linha a~rca em camadas, provendo uma estrutura com :1 qual podemos discutir a viagem aérea. Note que cada camada, combinada com as cmnadas abaixo dela, implcmcnta alguma funclonalicladc, algum serviço. Na camada da passagem ,ttrca c abaixo dcl:t, é realizada a transfcréncia 'balcilo-dc-linha-nt!rea-balc:lo-de-linha-aérca' de um passageiro. Na camada de bagagem c ab:1ixo dela. é rea lizada a tmnsferênda 'despacho-de-bagagem-recuperação-de-bagagem' de um passageiro e de suas malas. Note que a camada da bagagem provt! esse serviço apenas para a pessoa que já apresen tou a passagem. Na cam:tda do portão, é realizada a tmnsfer~ncia 'port:lo·de·cmbarque·portão..
Passagem aérea (compr ar)

~.........~

Bagagem

(despachar)

Passagem (redamar>

Possegem

Bagagem (rec\Jperar)

Bagagem

Portõe$

Portõe$ (embarcar)

(d~mbarcar)

Decolagem

A terris,gcm

Rote<~mento

1-:

de aeronave Aeroporto de origem

I

Roteamento deaeron<~ve

I .I

Roteamento de aeronave

Centrais Intermediárias de cont role de trilfego H reo

Figuro 1.22 (amados horizontais do funcionalidade de linho aéreo

I

Roteamento de aeronave Aeroporto de destino

Portlo

Roteamento de aeJOn

Redes de comput adoras e o Inter net

37

(embarcar c desembarcar passageiros); ela simplesmemc implemen taria aquela fun~-:lo de maneira difere nte após a modilic-o~ç;\o. P~1ra sistcrn:~s grandes e complexos que são atualizados constan te mente, a cap:~cidade de modificar a implemcntaç-.io de um serviço sem afetar outros componentes do sistem:t ~ o utra vantagem importante da divis:lo em camadas.

Camadas de protocolo Mas chega de linhas aéreas! Vamos agora voltar nossa atenç-.io a protocolos de rede. Para prover uma cstrupara o projeto de protocolos de rede, projetistas de rede orgamzam protocolos- c o hardware c o software de rede que implementam os protocolos- em camadas. Cada protocolo pertence a uma da.o; camadas, exatamente como c-ada fu nç:\o na arquitetu ra de lin ha atrea da Figura 1.22 pertenci:\ a uma camada. NO\':\mcnte estamos interess.1dos nos serviços que uma camada oferece à canKtda acima del::t- denominado modelo de serviço de uma cam;tda. Exat::tmcntc corno no nosso exemplo da li nha aérea. cada camada provt seu serviço (l) executando certas ações dcmro da camada c (2) utilizando os serviços da camada dirc tamemc abaixo dela. Por exemplo, os serviços providos pela camada " podem incluir entrega confiável de mensagens de uma extremidade da rede :i o ut ra, q ue pode ser im plcmeruada utiliz:mdo ltm serviço n;\o conflávcl de cm rcg:l de mensagem fi m a nm da c:unada 11- l c ad icionando funcion;11idadc da (.'<1111<~da n para detectar c retransmitir mensagens perdidas. lUra

Uma cam;tda de protoco lo pode ser implementada em software, em hardware, ou ern u ma combinação dos dois. Protocolos c.Jc camada de aplicação como HTTP c SMTP - quase sempre s;\o implementados em software crn sistemas finais; o mesmo acontece com protocolos de c~unada de tm nsportc. Como a cmnada rfsica c as t'amad:ts de enlace de dados s.'o responsáveis pelo manuseio da com u nica~-ão por um enlace espccirãco, no rmalmente s:\o implementadas em uma placa de interface de rede (por exemplo, placas de interface Ethcrn ct ou Wt-Fi) associadas a um determinado enlace. A camada de rede q uase sempre é uma tmplementaç-.lo mista de hardware c software. Note também que, exatamente como as funções na arq uite tura em camadas da linha afrea eram distribmdas entre os \'ários aeroportos e centrais de controle de tráfego afrco que compunham o sistema, também um protocolo de camada n é d istriburdo entre os sistemas Onals. comutadores de pacote c OlllrOS componentes que formam a rede. Isto é, há sempre uma parcela de um protocolo de camada n em cada um desses componentes de rede.

O sistema de carmtdas de protocolos tem \'3ntagcns conceituais c estruturars. Como vimos, a divisão em camadas proporciona um modo estruturado de discutir componentes de sistemas. A modularidade facilita a atualizaçào de componentes de sistema. Dc,·emos mencionar, no entanto, que alguns pesq uisadores c engenheiros de rede se opOem veementemente ao s is tema de camadas (Wakeman, t992l . Uma des,•an tagem potencial desse sistema ~ que un m c-Jmada pode du plicar a funcionalidade de uma camada inferior. Por exemplo, mu itas pilhas de protocolos oferecem serviço de rccupcraç;lo de erros na camada de enlace c tambtm lima fim. Uma segunda desvan tagem potencial é q ue a funcionalidade em uma cam:-tda pode ncces.o;itar de informac:Oes ( por exemplo, um valor de carimbo de tempo) q ue estão presentes somente em uma outra camad:1, o q ue infr inge o objetivo de scpara~·uo ele camadas. Quando tomados em co•~ unto, os protocolos das várias caml\clas são denominados pilha de protocolos, que é fommcla por cinco camadas: ffsica, de enlace, de rede. de t ro~nsporte e de ap lieaç;lo. como mostm a Figum 1.23 (a). Se voei! vcrlnc-a r o sum:1rio, verá que organizam os este livro utilizando as camadas da pilha de protocolos da Internet. Fazemos uma abordagem descendente, primeiro abordando as c-amadas de aplic-.tç;\o c, em:lo, os processos.

(amado de aplicação A camad<~ de aplícaç-lo é onde residem aplicações de rede c seus protocolos. Ela inclui muitos protocolos. tais como o protocolo t-ITTP (que prov~ rcquisiç-Jo c transfcrtncia de documentos pela Web). o SMTP (que provi! transferl!ncia de mensagens de correio cletr6nieo) e o FfP (q ue provi! a transfcrl!ncia de arquivos entre dois sistemas Onais). Veremos que certas funções de rede, como a tradução de nomes fáceis de entender dados a sistemas linais da Internet (por exemplo. gaia.es.umass.edu) para um endereço de rede de 32 bits, também Sào executadas com a ajuda de um protocolo de camada de aplicação, no caso, o sistema de nomes de domfnio (domain name sysrem - DNS). Veremos no Capitu lo 2 q ue é muito fácil criar nossos próprios novos protocolos de camada de aplicação.

bow4tto4ic~ Redes de co 111 pulod ores e o Inle ;.; ro;.;e;.;.l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Apl~

Apresentaç3o Sessão

Transporte

Transporte

Rede

Rede

Enlace

Enlace

fisico

FísiCO

a. Pilha de protocolo da Internet de oneo

c:amiidas

b. Modelo de referência ISO OSI de sete camadas

Figura 1.23 Apilho de protocolo do Internet (o) e o modelode refe1êndo OSI (b) Um pro tocolo de crunud;~ de aplicuç,'o é distribuído por diversos sistemas fin<~is, se ndo que a aplknc;ão em um sistema nual utiliza o protocolo tx~m trocar tx~cotes de lnrormaç:lo com ~~ apllt~tç:lo em outro ststcma flnal. Denominaremos esse puco1c de infom1açllo na camada de aplicação de mensagem.

(o modo de transporte A c:Hn<~da de 1ranspone da Internet 1ranspona mensagens d;~ cam;~da de aplicaç;\o entre os lados do diente c servidor de uma aplicação. Há dois protocolos de trJnsporte na lmernet: TCP c UDP, c qualquer um deles pode lc,•ar mensagens de camada de aplicação. O TCP prov~ serviços oncntados para conexão para suas aplicações. Alguns desses serviços São a entrega garantida de mrnsagcns da camada de aplicaç;lo ao destino r contro le de fluxo (is1o é , compllúbilização das velocidades do remetente c do receptor). O TCP também rrJg· menta mensagens longas em segmentos mais cu rtos c pro,·ê meca nismo de con1rolc de congestionamento, de modo que uma origem regula sua velocidade de transmisSão quando a rede cs 1:\ congcs1ionada. O protocolo UDP prov~ serviço mio oriemado para conexão a suas aplicações. Este é um senriço econômico que fornece segurança , sem controle de fluxo e de congestionamento. Neste li vro, um paco1c de camada de transporte será denominado segmento.

(o modo de rede A camad:t de rede da Internet é responsável pela movimentação, de uma máquina para ou tra, de pacotes de cntm:tda de rede conhecidos co mo dalagramas. O protocolo de camada de 1ranspon c da lmernet (TCP Oll UDP) em uma máquina ck origem passa um segmento de camada de tra ns porte c u m cnderec;o de destino à camada de rede, exatamente como voe~ passaria ao serviço de correios uma carta com um endereço de d cs ti· natár io . A ca m:tda d e rede cnlllo prove o serviço de entrega do segmento à c:unacla de tmnsportc na máquina d cst in:1 t:\ ri a. A camada de rede d a Internet tem dois componentes princtpais. Um deles é um p ro tocolo que define os c;ttnpos no datagrama, bem como o modo como os sistcm;~s finais c os roteadores agem nesses campos. Este é o famoso pro tocolo IP. Existe somente um único protocolo IP. c todos os componentes dll Internet que tê!m uma camada de rede devem execu tar esse protocolo. O outro componente imponante é o protocolo de ro tea men to que dcu:rmina as rotas que os dmagramas seguem ent re origens c destinos. A Internet tem muitos protocolos de roteamemo. Como ' 'imos na Seção 1.3, a In ternet é u ma rede de redes c, dentro de uma delas, o ;~dminislrador pode cxecu1ar qualquer protocolo de ro 1eamemo que queira. Cmbora a camada de rede contenh a o protocolo IP c 1ambém numerosos protocolos de rolcamcnto, ela quase sempre é denommada stmplesmenre camada lP, refletindo o rato de que ele é o elemento fundame ntal que mantém a integridade da Internet.



39

(amado de enlace A cam:tda de rede da lmcrnct ro teia um datagrama por meio de um:t série de ro teadores entre a origem c o destino. Para levar um pacote de um nó (sistema Cinal o u comutador de pacotes) ao nó seguinte na rola, a camada de rede depende dos serviços da camada de enlace. Em especial. em cada nó, a camada de red e passa o datagrama para a COiiiHO·fJOÍIU fH'otorol - protocolo ponto-a-ponto). Como datagmrn;~s normalmente precisam transitar por diversos enlaces para irem da origem ao destino, serão manuseados por difere ntes protocolos de camada d e enlace em difcrcmcs enlaces ao longo d e sua ro ta , 1>odendo ser manuseados por Ethernet em um enlace e por PPP no seguinte. A camada d e red e receber:\ u m serviço diferente de cada um elos variados J)ro tocolos de camada de enlace. Nes te li vro, pacotes de camada de enlace sen\o d enominados q uadros.

(o modo flsico Enquanto :1 wrda da camada de enlace é movimentar quadros inteiros de um elemento da rede até um elemento adjacente, a da camada fls ic:l é movimentar os bits ir~
OmodeloOSI t\pós di~ utir dct:~lhadamcntc a pilha d e protocolo da Internet, devemos mencionar que essa não é a única pilha de protocolo existente. Particularmente, no final dos anos 1970, a OrganizaçJo Internacional para Padronizaç;\o (ISO) propOs que as redes de computadores fossem organizadas em, aproximadamente, sete camadas, denominadas modelo de Interconexão de Sistemas Abertos (051) liSO. 20091. O modelo OSI tomou forma quando os pro tocolos que iriam se tornar protocolos da Internet estavam em amadurecimento: c eram um dos muitos conjuntos d e protocolos em descnvoh
bow4tto4ic~ Redes de co 111 pu tod ores e o Inle ;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

serviços? A resposta da Internet para essas perguntas é a mesma - dc~ndc do criador da aplícaçâo. Cabe ao criador da apltcaç;\o decidir se um serviço é imponame. c se o serviço jo1 importante. cabe ao criador da aplicaç-Jo desenvolver essa runç.lo para ela.

1.5.2 Mensagens, segmentos, dotogromas e quadros A Figura 1.24 apresenta o caminho físico que os dados percorrem: para baixo na pilha de protocolos de um sistema Onal emissor, para cima c para baixo nas pilhas de protocolos de um comutador de l-amada de enlace intcrvcnicme c de um roteador c então para cima na pilha de protocolos do sistema Onal receptor. Como dis· cmircmos m:us adiante neste livro, ambos, comutadores de camada de enlace c roteadores, são comutadores de pacotes. De modo scmclh:mte :t sistemas finais, roteadores c comutadores de camada de enlace organi:tam seu hardwa re c sortware ele rede em camadas. Mas roteadores c comut
t\ Figura 1.24 tam~rn ilustrJ o importante conceito de encapsulamento. Uma mens.1gcm de camada de aplkaç.lo nll m::\quimt cmissom (M na Figura 1.24) é pass.'lda pam a camada de tmnsportc. No caso mais simples,

esta pega a mensagem e anexa inrormaçOes adicionais (denominadas mrormaçOcs de cabeçalho de camada de transporte, H, 11:1 Figura 1.24) que scr:lo usadas pela camllda de transporte do lado receptor. A mcns.'lgem de c.\mada de aplicaçâo c as in[onnaçOcs de l"abcçalho da camada de transporte. juntas, constituem o segmento da camada de transporte. que encapsula a mensagem da '-amada de aplk-ação. As in[ormaçóes ad•cionadas podem

Oest1no Mens.lgem M

Segmento H1 M Datagrama Hn Ht M Quadro Ht Hn Ht M

Transporte Rede Enlace Ffsoeo Enlace ffsJCo

Or1gem M

Ht M Hn Ht M Ht Hn Ht M

Apt~o

Transporte Rede Enlace fhiCO

Hn Ht M Ht Hn Ht M

Rede Enlace

Físico

-

Hn Ht M HI Hn Ht M

ftgura 1.24 Hospedeiros, roteod01es eco1111ltodores de cmoodo de enloce; codo llfl1 coolém um conjunto dife~ente de

Redes de
41

incluir dados que habilitem a camada de transpone do lado do receptor a entregar a mensagem 11 aplicaç11o apropriada, além de biLS de dctecçJo de erro qu e pemtitcm que o receptor determine se os biLS da mensagem foram modirit"Udos em tr.lnsito. A cam:1da de transporte então passa o segmemo 11 camada de rede, que adiciona infor· mações de cabcç.tlho de camada de rede C d e t'Orrespondencia interna representa o segmento da camada de aplicação- co nt ~m as informações de cabeçalho (o nome de Sob c seu departamento) c encapsula ;\ mens:•gem d e camada de ;~plicol çào (o memorando). Quando 11 central de eorrcsJ>ondência do es<:ritório emissor recebe o envelope, ele~ colocado dentro de outro cnvc· tope adequado pam envio pelo correio. A central de corrcspondi!nci:1ern issom tam~m cscre\'e o endereço pos tal do remetente c do destinatário no envelope postal. Neste ponto, o envelope postal é aná logo ao datagm rna - cnt"Upsula o segmento de camada de transporte (o envelope de correspondênci:• interna), que por sua vez encapsula a mcn.s:.tgcm original (o memorando). O correio entrcg:t o envelope postal à central de correspondência do escntório destinatário. Nesse local, o processo de reencapsulamcnto se inicia. A central de corrcspond~ nc ia retim o mcmo· mndo e o encaminha a Bob. Este, finalmente. abre o envelope e retim o memorando. O processo de encapsulamento pode ser mais complexo do que o descrito acima. Por exem plo, uma mensagem gmnde pode ser di\ridida em vários segmentos de camada de transporte (que também podem ser diVIdidos em v;lríos d:uagmmas de camada de rede). Na extremidade receptora, cada segmento deve ser rcconstrufdo a partir dos datagmmas que o compocm.

1.6 Redes sob ameaço A Internet se tornou essencial para muitas instituições hoje, incluindo empresas gra ndes c pequenas, un iversidades e órgaos do governo. Munas pessoas tambem contam com a lmernet para suas atividades profissionais. sociais c pessoais. Mas atrás de toda essa u tilidade c entusiasmo, existe o lado negro, um lado no qual "vilões~ tentam causar problem:1s em nosso cotidiano danificando nossos computadores conectados à Internet, \•iolando nossa privacidade c tornando inoperantes os serviços da Intern et dos quais dependemos ISko udis, 2006). A área de segurança de red e abrange como esses \'ilões podem ameaçar as redes d e computadores c como nós, futuros cspcci:llist:LS no ass unto, podemos defender a rede comrn essas ameaças ou, melhor amda, criar novas arq~liteturas imunes a tnis ;Hl1Ci1ças em primeiro lugar. Dadas a frequencia e a variedade das ;lmcaçns existcmcs, lxm como o perigo d e novos e mais destrulivos futuros at;~qucs, a segurança de rede se tornou, •·eccnlemcnte, um assunto principal na :\rca de redes de computadores. Um dos objetivos des te livro é trnzer as questões de segurança de rede para primeiro plano. Iniciaremos nossa discussão sobre redes de compmadores nesta seç-Jo, com uma brc,•e descriç;lo de alguns dos ataques mais predominantes c prejudiciais na Internet de hoje. Então, à medida que retratarmos em detalhes as diversas tecnologias de redes de computadores c protocolos nos capítulos seguintes, :malisaremos as diversas questões relacionadas à segurança assoc1aclas a essas tecnologias c protocolos. Finalmente. no Capitulo 8. munidos com nosso know-how em redes de computadores c protocolos da lntemcL recém-adqlurido. estud aremos a fundo como as redes de computadores podem ser defendidas contm ameaças. ou projetadas c operadas para impossibilitá-las. Visto que amda não temos o know-how em rede de computadores c em protocolos da Internet, comeÇO\ remos com uma análise de alguns dos atuais problemas mais predominantes rclacion:1dos à segurança. Isto irá aguçar nosso apetite para ma1s discussões importantes nos capítulos futuros. Começamos com a pergunta, o que pode dar errado? Como as redes de computadores são frágeis? Quais são alguns dos tipos d e ameaças mais predominantes hoje?

bow4tto4ic~ Redes de com putod ores e o Inle.;.';;.ne;;.;t_________________________

Os vilões podem colocar "molware"em seu hospedeiro olrovés do Internei Conectamos aparelhos à Internet porque queremos receber/enviar dados de/para a Intemcl. Isso inclui todos os tipos de recursos \'antaJOSOS, como páginas da \Vcb. mensagens de c-mail, MP3. chamadas tclcfOnicas, \•ídeo em tempo real. resultados de mecanismo de busca etc. Poré m, ínfellzmentc, junto com esses recursos vamajosos aparecem os maliciosos - conhecidos conjunt<~meme como malwarc - que tamb~m podem entrar c inrcct<~r nossos ap.uclhos. Uma \' CZ que o malware infccta nosso aparelho. ele é capaz de fazer coisas tortuosas, como ap:t· gar nossos arquivos; instalar sppv:m: arelhos comprometidos. conhecidos como "botnel", o qua l é con trolado e innuenciado pelos viloes para distribuiç.\o de spams ou ataques de recusa de serviço distribuídos (que serlo brc,•ememc discutidos) contra hospedearos direcionados. Muitos malwares existen tes hoje s.io autorrcprodutivos: uma vez que infecta 11111 hospedeiro, a partir deste, ele faz a busca por em rad:1s em OLuros hospedeiros através da Internet, c :1 partir de hospedeiros recém-in fectados, ele faz a busca por entrada em mais hospedeiros. Desta ma neira. o malware autorreprod utivo pode se d isse mina r rapicl~• me a u c. Por exemplo, o m'unero de aparel hos inrectados pelo worm 2003 Saphirc/SI:unmer dobrou a cada 8,5 segundos nos primeiros minutos após S<:U ataque, infectando mais de 90 por ce nto dos hospedeiros frágeis em lO minutos IMoore, 20031. O malwarc pode se espalhar na forma de vfrus, worms ou cavalo de Trola (Skoudls, 20041. Os vrrus sao nmlwares CJUC ncccssimm de uma interação do usu;lrio para infccwr seu :IJXtrclho. O exemplo ch\ssico é um anexo de e-mail contendo um código execuuwcl malicioso. Se o usu;\rio receber c :abrir tal anexo, o malware será executado em S<:u ap:~rclho. Geralmente, tais ''rrus de e-mail se <~lllorreproduzem: uma vez executado, o vrrus pode enviar unm mensagem idêntica. com um anexo malicioso idêntico. para. por exemplo, todos os cont.1tos da lista de endereços do usuário. Wonns (~;orno o Slrunmcr) s.'l.o mah,-arcs capazes de entrar em um aparelho sem qualquer interação do usuário. Por exemplo. um usuário pode estar cxcnuando uma aplicaç.io de rede frágil para a qual um atacante pode enviar um malware. Em alguns casos, sem a in tervenç;\o do usuário, a aplicação pode aceitar o malware da Internet e executá-lo, criando um worn1. Este, no aparelho recem-infcctado, cm:lo, \':lrre a Internet em busca de outros hospcdetros que estejam executando a mesma aphcaçáo de rede fr:ígil. Ao encontrar outros hospedeiros frágeis, ele cm•ia uma cópia de si mesmo para eles. Por fim, um cavalo de Troia é uma parte oculta de um software funcional. Hoje. o malwarc é pcrsuash·o c é caro para se nlar uma proteç.'lo. À medida que Lrabalh:LT com este livro, sugerimos q ue pense na seguinte questão: O que os projetistas de computadores podem fazer para proteger os aparelhos que ut iliza m a lmernet de ameaças de malware?

Os vilões pode atacar servidores e infraestrutura de redes Um a mplo gr upo de ameaças ;) segunmç.\ pode ser classinc::tdo como awqucs de recusa de se rviços (DoS). Como o nome sugere, um ataque DoS torna uma rede, hospedeiro ou outra p:mc da inrracstrutura inulilizávcl por usuários verdadeiros. Servidores da Web, de e-mails e DNS (discutidos no Capftulo 2), c redes institucionais podem estar Sl~eitos aos atnqucs DoS. Na Internet, esses a taques silo extremamente comu ns. co m milhares deles ocorrendo todo :mo [Moorc, 2001: Mirkovic, 2005). A maioria dos a t:tques DoS na Internet podem ser divididos em trl's c:trtegorias; AICII/111! de vultarrcrbilit/ru/r. Envolve o en\'ÍO de mensagens perfeitas a uma aplicaçflo vulnerável ou a um sistema operacional sendo executado em um hospedeiro direcionado. Se a sequtncia correta de pacotes é env1ada a uma aplicação vulncr.i\•cl ou a um sistema operacional. o sen•iço pode parar ou, pior, o hospedeiro pode pifar.

lnundcaçtlo na largura de banda. O atacante envia um grande n umero de pacotes ao hospedeiro direcionado - tantos pacotes que o enlace de <~cesso do ah•o se entope. unpcdindo os pacotes legítimos de alcançarem o servidor. lnundacdo na contxtlo. O ataca me estabelece um grande nümero de conexões TCP scmiabcrtas ou abertas (as conexocs TCP são discutidas no Capitulo 3) no hospedeiro-alvo. O hospedeiro pode ficar tão atolado com essas conexões falsas que para de aceitar conexões legitimas.


Redes de computadores e o Internei

43

Vamos agom explorar mais detalhadamcote o ataque de inundaç;lo na largum de banda. Lembrando de nossa análise sobre atraso c perda na seçJo 1.4 .2, é evidente que se o servidor possui uma taxa de acesso R bps, então o atacante precisará enviar tráfego a uma taxa de, aproximadarneme, R bps par-.1 causar dano. Se R for muito gmnde, uma fonte de :1wque única pode n~o ser capaz de gerar U'áfcgo suficiente pam prejudicar o servidor. Alêm disso, se todo o tráfego provier de uma fonte: única. um roteador upstrcam pode conseguir detectar o ataque e bloquear todo o tráfego da fome ames que ele se aproxime do servidor. Em um ataque DoS distribmdo (OOoS). ilustrado na Ftgura 1.25. o atacante controla múltiplas fontes que sobrecarregam o ai\'O. Com tal abordagem, a taxa de tráfego agregada por todas as font~ conuoladas precisa st.r, aproximadamente, R paro incapacitar o serviço. Os ataques DOoS que potencializam bomeLS com cemenas de hospedeiros comprometidos s:\o uma ocorr~nc ia comum hoje em dia (Mirkovic, 20051. Os amques DDoS são muito mais dirrceis de detectar c de prevenir do que um ataque DoS de um ünico hospedeiro

Os vilões podem anolisar pacotes Muitos us uários hoje acessam à Internet por meio de aparelhos sem fi o. t•omo l:~pto ps conectados à tccnolo· gia Wi-Fi ou aparelhos port:1teis com concxocs à I mente L via telefone celular (.-.bordado 110 Capftulo ó). Enquanto o :1<:csso onipresente à Internet ê extremamente conveniente c disponibiliza nov:ts aplk~tçócs sensacionais aos usu:lrios móveis, ele tllmbém cria uma grande vulm::mbílidadc de scgL~ran\·a - posicionando um rceepLor passivo nas proximid:.dcs do transmissor sem fio, o receptor pode obter uma cópia de cada pacote transmitido! Esses pacotes podem conter todo tipo de informações confidenciais. incluindo scnh:IS, numero de inscrição da previdenci:\ socktl, segredos comerciais c mensagens pessoais. Um receptor passivo que grava tuna cópia de cada pacote que passa t denominado analisador de pacote. Os analisadores também podem estar distribuídos em ambientes de conexão com llo. 1 esses ambientes, como em munas Ethernct LANs. um analisador de pacote pode obter cópi:IS de todos os pacotes enviados pela LAN. Como descrito na Seção 1.2, as tecnologias de acesso a cabo também transmitem pacotes c são, dess.1 forma, vulnera\'eis à análise. Além disso. um vilão que quer ganhar acesso ao rotCóldor de acesso de: uma insti· tuiçào ou enlace de acesso paro a Internet pode instalar um analisador que faça uma cópia de cada pacote que vai para/de a empresa. Os pacotes farejados podem. emão, ser analisados off-hnc em busca de informações confidenciais. O software para analisar pacotes está disponivel gmtuilamente em diversos silcs da Internet e em produtos comerciais. Professores que rninistmm um curso de redes passam vcercícios que envolvem :1 composição de Ltm progmma de rcconstruÇ':'O de dados dn camada de aplicaç:\o e um programa anahsador de pacotes.

AtacDntc

Zumbi

Figura 1.25

Um otoque de recuso de serviço distribuído (OOoS)

bow4tto4ic~ Redes de co11putodores e o ln;.;l..;.e;.; rn;.;e;.;.t_________________________

Como os analisadores de pacmc s:\o passivos - ou seja, eles n;\o lntroduzcm pacotes no canal - eles s."\o difkcis de detectar. Portanto, quando en,'iamos pacotes para um canal sem fio, devemos aceitar a possibilidade de que alguém poss.1 estar copiando nossos pacotes. Como ,·ocê deve ter imaginado, uma das melhores defesas contm a análise de p;tcotc envolve a criptografia. que será analis.1da no útpll ulo 8. já que se apli~"a à segurança de rede.

Os vilões podem se passar por alguém de suo confiança Por incnvcl que pareça, é extremamente fácil (,•ocê saberá como conforme ler este livro!) criar um pacote com um endereço de fonte arbitrário, conteúdo de pacote e um endereço de destino c. cntào, transmitir esse pacote feito:\ m;'o pam a Internet, que, obedientemente, o cncamtnhará pam seu destino. I maglne que um receptor inocente (digamos um roteador da Internet) que recebe tal pacote, acrcdit:l que a fonte (fals.1) seja confiável c cnLào executa um comando integrado aos contCLidos do pacote (digamos que modifica sua base de encaminhamemo). A habilidade de introduzir pacotes na lruernet com uma fome f;~ls.1 de endereço~ conhecida como IP spoofing, c é uma das muitas maneiras pelas quais o usuário pode se passar por outro. Pam reso h·er esse problema, precisaremos de uma comprovac;ào da fonte , ou sej<~. um mecanismo que nos permítir-.1 determinar com certeza se uma mensagem se origina de onde pensamos. Mais uma vez, sugerimos que pense em como isso pode ser feito em aplic:tçôcs de rede c protocolos à medida que avaewa sua lcitum pelos c:tpltulos deste livro. Exploraremos mais mecanismos p<~m eomprovaçào da fonte no Capitulo 8.

Os vilões podem alterar ou excluir mensagens Encerramos csu1 breve análise de ataques na rede descrevendo os :naqucs nwn-in-tlrc-middlc (homem no meio). Nessa catcgom de ataques. o vihlo está infiltrado no percurso da comunicac;-.\o entre duas entidades comunicantes. Vamos chamar ess.1S enudadcs de Alice c Bob. que podem ser seres humanos rea•s ou entidades de rede como dois roteadores ou dois servidores de c-mail. O vilão pode ser, por exemplo, um roteador comprometido no percurso da comunicação, ou um módulo de software residente em um dos hospedeiros finais em uma camada inferior da pilh:t de protocolo. No ataque nurn-in-tht-midcl/e, o ''ilào nao some me possui a possibilidade de an:tlisar todos os pacotes que passam entre Bob e Alice. como também pode mtroduzir, ahcmr ou excluir pacotes. No jarg.lo da segumnça de rede. um ataque nrnn-in-thc-micldlt pode comprometer a lntcgr•dmlc dos dados enviados entre Alice c Bob. Assim como veremos no Capitulo 8, os mecanismos que oferecem sigilo (proteç-lo contra análise) c autenticação da origem (permitindo que o receptor vcrlnquc com certeza o gerador da mensagem) não necessariamen te oferecem imcgridade dos dados. Ao encermr esta scç-lo, eleve-se considerar como :t lntemct se tornou um local inseguro, em primeiro lugar. A resposta rcsumid;uuentc ~ que a Internet foi , a prrncipio, cri:td


45

1.7 História dos redes de computadores e do Internet Da scç.\o 1.1 à l.6. apresentamos um panorama da tecnologia de redes de compumdores c da Internet. Agora. você Já deve saber o suficrente para impressionar sua família e amigos. Contudo, se realmente qmser ser o maior sucesso do próximo coquetel, voe~ deve rechear seu discurso com pérolas da f
1.7.1

Desenvolvimento do comuto~õo de pacotes: 1961-1 972

Os primeiros passos dt~ disciplina de redes de compmadorcs c da lrnernct podem ser traçados desde o inicio da década de 1960, quando a rede telefônica era a rede de comunicaçllo dominante no mundo inteiro. Lembre-se de que na Scc;:'lo 1.3 dissemos que a rede de telefonia usa comutação de circuitos para transmi tir infonnac;6es entre uma origem c um destino - uma escolha acertada, já que a voz é transmitida a uma taxa constante entre a origem c o destino. Dada
grupos de pesquls:t ao redor do mundo, sem que nenhum tivesse conhecimento do trabalho do Otllro llciner. 1998) . ~omcçaram a inventar a comuta~<10 de pacotes corno uma :altcrn:auva poderosa c cfidentc à de circuitos. O primeiro trabalho publicado sobre u.'cnicas de comutac;-Jo de pacotes foi o de Leonard Kleinrock IKleinrock, 1961 , 19641 . que, naquela época, era um doutorando do MIT. Usando a teoria de filas, o trabalho de Klcinrock demonstrou, com elegância. a eficácia da abordagem da comutação de pacotes para fontes de tráfego interrmtcntes (trn raJCUias). Em 1964. Paul Baran IBaran, 19641. do Rand lnstítute, começou a investigar a uulização de comutac;ão de pacotes na transmissão segura de ,·oz pelas redes milHares. ao mesmo tempo que Donald Oavics c Rogcr Scantlcbury desenvolviam suas idcias sobre esse assunto no National Physic.-al laboratory. na Inglaterra. Os trabalhos desenvolvidos no MIT. no Rand lnstitute e no National Physical Laboratory foram os alicerces do que hoje é a Internet. M:IS a I ntemct tambêm tem uma longa história de alltudes do tipo · construir e demonstrar". que tamtxm data do infcio da década de l900. J . C. R. Licklidcr IDEC. 19901 c lawrcnce Robcns. ambos colegas de Klcínrock no MIT, foram adiante e lideraram o programa de cléncia de computadores na ARPA (Advanccrimciro IMP na UCL.t\ (Universidade da Calirórnio em Los Angclcs) sob a s upervisão de Klcinrock. Logo em seguida foram instal:rdos três IMPs adicionais no Stanrord Research lnstilutc (SRI), na Universidade da Califórnh1 em S:mta Bárb:1ra c na Universidade dc Utah (Figura 1.26). O Incipiente precursor da Internet tinha quatro nós no final de 1969. Kleinrock recorda que a primelrlssima milizacno da rede foi fazer um login remoto emre a UCLA e o SR!. derrubando o sistema IKieinrock, 20

1.7.2 Redes proprietários e trabalho em rede: 1972-1980 1\ ARPt\ nct i melai em um rede isolada, rechadn. Paro se comumc:u com uma máquma da ARPAnct, em prc· ciso estar ligado a um outro IMP dessa rede. Do inicio a meados de l970, surgir:1m novas redes independentes d e comutação d e p:tcotcs:

J\LOHAnet, uma rede de micro-ondas ligando univers idades das ilhas do I lavai (t\bramson, 1970). bem como as redes de pacotes por sat~lite IRFC 829] c por rádio (K:~hn, 19781 dt1 DARPA (Kahn, L978l; Telcnct, uma rede comercial de comutaç

Redes de
47

Esses princrpios de arquitetura foram incorporados ao TCP. As primeiras versões desse protocolo, contudo. eram muito difcremcs do TCP de hoje. Aquelas versões combinavam uma entrega sequcncial confiá,•el de dados v1a retransmissM por sistema rlnal (que ainda faz parte do TCP de hoJe) com funções de envio (que hoje s:1o desempenhadas pelo IP). As primeiras cxpcri~ncias com o TCP. combinadas com o reconhecimento da import:lncla de um serviço de tra nsporte fim a fim não confiável. sem controle de Ouxo. para aplicações como voz em pacotes, lev:~ram :\separação entre IP e TCP e ao desenvolvimento do protocolo UDP. Os tres pro10colos fundamentms da Internet que temos hoje- TCP, UDP e IP- estavam conceitualmente d•sponi\•cis no final da

dmda de 1970. Além das pcsquis.-.s sobre a Interne t realizadas pela DARPA. muitas outras atividades importantes relacionadas ao trnb:tlho em rede est:wam em curso. No !lavar, Norman 1\brnmson estava desenvolvendo a r\LOIIAneL. uma rede de pacotes por rádio que pcnnilia que \rãrios luga res remotos das ilhas havaianas se comunicassem entre si. O ALOIIA (Abr:uuso n, 19701 foi o primeiro protocolo de acesso nni ltiplo q ue pe rmitiu que US LLários dis· triburdos e m dircrcntes localitaçõcs geogrãfit'aS compartilhassem um t\nico meio de cornunicaç~o bro:•dcast ( uma frcquenciu de rádio). O tmbalho de Abrn mson sobre protocolo ele mú ltiplo uccsso foi upri morado por Metcalfe c Boggs com o dese nvolvimento elo J>roto..:olo Ethcrnet [Mctcalrc. 19761 pam redes co mpartilhadas ele transmissCto broadcasl por fio; veja a Figura L.27. O imcrcss:lntc ~ q ue o protocolo Ethcrnet de Metcalfc c Boggs foi motivado pela ncccssiel;~dc ele concct:lr c discos companilhados (Pcrkins. 19941. H:t 25 ~mos. bem tmtcs da n:voluçào do PC c da explos.lo d:~s redes, Metc:~lfe c Boggs cstuvam lan~·nndo as b;\Ses para as JJ\Ns de PCs de hoje. A tecnologia Ethernet representou uma etapa imponamc para o trabalho em redes im erconectadas. Cada rede Ethernct local era, em si, umn rede, c,:\ medida que o número de l.ANs aumcma,·n, a necessidade de in tcrconcctar ess.-IS redes foi se tornando t:adu vez mais importante. Discutiremos detalhadamente a tecnologia Ethernct, ALOHr\ e outras tecnologias de LAN no Capítulo 5. vá r l~ PCs. Impressoras

1.7.3 Proliferação de redes: 1980-1990 Ao final da d écada de 1970, aproximadamente 200 maquinas estavam conectadas;\ ARPAnct. Ao final da o numero de máquinas ligadas à Internet pública. uma confc:dcracuo de redes muito parecida com a Internet de hoje. alcançaria cem mil. A déada de 1980 seria um:t época de formidável crestimento. d~cada de 1980,

Grande parte daquele crescimento foi consequencia de vários esforços distintos para criar redes de computadores para int erligar universidades. A BITNET processava e-mails e fazia transrertncia de arq uivos en tre diversas universidades do nordeste dos Estados Unidos. A CSNET (computer sc•cncc nctwork- rede ela ciencia de corn-

Figura

1.27 Aconcepção original de Metcolfe poro o Ethernet

bow4tto4ic~ Redes de com putod ores e o Inle,;.rn;;.e;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

putadores) foi formada para interligar pcsqlúsadorcs de universidades que não tinham acesso à ARPAtlel. Em 1986. foi criada a NSFt ET para prover acesso a cemros de supcrcomputaç;lo patrocinados pela SF. Partindo de uma velocidade imc.al de 56 kbps. ao final da década o backbonc da NSFNET cstana funcronando a 1,5 Mbps e scn·indo como b:1ckbone primário para a interligação de redes regionais. ' a comunidade da ARPAnet, já estavam sendo encaixados muitos dos componentes finais da arquitetura da Internet de hoje. No dia L'' de janeiro de 1<>83. o TCP/lP foi adotado oficialmente corno o no,•o padrão de protocolo de máqumas para a ARPAnet (em substuurç.\o ao protocolo NCP). Devrdo à nnport!lncta do evento, o dia da transição do NCP para o TCP/IP [RFC 8011 foi marcado com amecedl!ncia- a partir daquele din todas as máquinas th·eram de adotar o TCP/IP. No final da década de 1980, foram agregadas importantes extensões ao TCP para implementação do controle de congcstioMmemo baseado em hospedeiros Uacobson, 1988) . Também foi desenvoh•ido o sistema de nomes de donúr1ios (DNS) utilizado para mapear nomes da lmernet fáceis de entender (po r exemplo, gaia.cs.unuss.edu) para seus endereços IP de 32 bits IRFC 10341. Paralelamente ao d esenvolvimemo da ARPAnct (que em sua maior pane deve-se aos Estados Unidos), 110 inicio da década de 1980 os franceses lançaram o projeto Minilel, um plano :unbicioso p:tm levar as redes de dados p:tr:t todos os lares. P:urocimtdo pelo governo franas, o sistema Minitcl consistia em uma rede pl~blica de comu taç;lo de pacotes (baseada no conjun to de protocolos X.25, que usava circuitos virtmlis), servidores Minitcl c terminais b:tralos com modcms de baixa velocidade embutidos. O Minitcltrnnsformou-se em um enonne sucesso em 1984, quando o governo francês forneceu, gra tuitamente. um terminal para toda residência francesa que quisesse. O sistema Minitcl indula sitcs ele livre acesso- como o da list:l tclefônic.'l- c também s itcs particulares, que cobmvam uma taxa de cada ltsmlrio baseada no tempo de utiliz.aç-lo. No seu auge. em mc:~dos de l990, o Minitcl ofereci:~ m:1is de 20 mil serviços, que iam d~de home banking até bancos de dados especializados para pesquisa. Ern usado por mais de 20 por cento da populaçi\o da França, gerava receita de mais de um bilhM de dólares por ano c cn ou dez rml empregos. Estav:t presente em grande pane dos lares fran ceses dez :mos antes de a maroria dos no rte-a meri canos ouvir falar de Internet.

1.7.4 Aexplosão do Internet: o década de 1990 A década de 1990 estreou com vários C\'entos que s imbolizaram a evoluç-.lo conunua c a comercialização imíneme da Internet. r\ ARPAnet, a progenitora da Internet, deixou de existi r. Durame a década de 1Q80, a MILNET c a Dcfcn~e Data Ne twork (Rede de Dados de Defesa) cresceram c passaram a carregar a maior parte do tráfego do Departamento de Defesa dos Estados Unidos c a NSFJ'ET começou :1 servir como uma rede de backbone conectando redes regionais nos Estados Unidos com nacionais no exterior. Em 1991 . a NSFNET extinguiu as rcstriçôe:. que impunha i\ sua utilização com finalidades comerciais, mas. em l 995, perderia seu mandato quando o tráfego de backbo nc da Internet passou a ser carregado por prm•cclorcs de serviços de Internet. O pr·incipal eve nto da década ele 1990, no entanto. foi o surgimento ela World W iclc Wcb, que levou '' I nt crncL p:m1 os lares e as empresas de milhões de pessoas no mundo inteiro. A Wcb se rviu também como plata· forma p:1ra a h:tbilíta<;ão c a dis ponibilização de centenas de novas aplicações, inclusive negociação de ações c sen•iços bancários on-li nc, serviços multimídia em tempo real e serviços de rccu peraÇllo de informacões. Para um breve histórico dos primórdios da Wcb, consulte [\V3C, 1995). A Web foi invcnwda no CERN (European Gemer for Nuclear Physics - Centro Europeu para Física uc lcar) por Tim Berncrs-Lec emrc 1989 c 1991 [Bcmcrs-Lce, 19891. com base em idcias originadas de trabalhos amcriores sobre hipertexto realizados por Bush (Bush, 19451. na década de 1940, e por Ted Nelson IZiff-Oavis, 1998( . na década de 1960. Bcrncrs-Lec c seus companheiros dcserwolveram versões miciats de IITML, HlTP, um servidor paro :1 Web c um browser- os quatro componen tes fund:~mcntais da Wcb. Os browsers origiMis do CERN ofereciam apenas uma interface de linha de comando. Peno do Onal de 1992 havia aproximadamente 200 scn•rdo res Wcb em opcraçào, c esse conjunto de servidores era apenas uma nmostra do que estava por vir. Nessa época. varios pesqtusadores esta\'am desenvolvendo b rowsers da Wcb com mterfaces GU1 (graphiwl usrr inwfaa - interface gráfica de ttsuário), entre eles Marc Andrc~sen , que liderou o desenvolvimento do popular browser Mosaic. Em 1994, Marc A11d reessen e Jim Clark formaram a Mosaic Communications, que mais



49

tarde se transformou na Nctscape Communicaúons Corpomllon ICusumano, 1998: Quiuner, 1998]. Em 1995, esLUdantes uni versitários estav;un usando browsers Mosaic e Netscapc para navegar na Wcb diaria mente. Nessa época, empresas- grandes c pequenas- começaram a operar servidores Wcb e a rcal1zar transações comerciais pela Wcb. Em 1996, a Microsoft começou a fabricar browscrs, dando in feio;\ guerra dos browscrs cnlrc NelSC3pc c Microsoft, vencida pela úllima alguns anos mais tarde. A segunda metade da década de 1990 foi um período de tremendo crescimento e tnO\'
e-mail , Incluindo anexos c correio e letrônico co m acesso pela Web; a Web, incluindo navcgaç;lo pela Web c comercio pela lmcrnct: serviço d e mcnsngem instnntânea . com listas de corHato, cujo pio11eiro foi o ICQ: compartilhamento pccr-to-pccr de arqu ivos MP3, cujo pioneiro foi o N:\ps tcr.

O ln tcrcss:mte é que as duas primeiras dessas ap licações de sucesso arrasador \•leram da co munidade de pcsquis."\S, :10 p:•sso que as du;\S últlm:IS fomm criad01s por alguns jovens empreendedores. No pcrfodo de 1995 a 2001. a Internet realizou uma viagem vertiginosa nos mercados financeiros. Antes mesmo de se mostrarem lucrath'
1.7.S Desenvolvimentos re(entes A inovnção na áre:~ de redes de computadores cominua a passos largos. lll\ progressos em todas as fremes, incluindo d esenvolvimento de novas aplicaçOcs, distribuição de conteúdo , telefonia por Internet, velocidades de transmiss:\0 mnis altas em LANs c rotc.1dorcs mais rápidos. Mas três dcscnvolvuncntos merecem atcnç:\0 especial: a prolifera\<'O de redes de acesso de nlta velocidade ( incluindo acesso sem fio) . :1 segurança e as redes P2P. Como discutimos na Seção l.2, a peneLrnç:lo cada vez maior do acesso residencial de b.-.nda lnrga 1\ Internet via mode m a caoo e OSL montou o cenário para uma profusão de novas aplicações muh imfdia, en tre elas voz e vídeo sobre IP [Skype. 2009] , comp:~rtilh:uncnto de video [Youtube, 2oo

mcnto de arqui\'O P2P ( la psu~r. Kaz:la, Gn utclla, eDonkey, Ume Wire etc.), distribuiÇtlo de arquivos (BitTorrcnt), Voz sobre LP (Skypc) e IPTV (PPLi,·c. ppStream). Muitas dessas aplicações P2P serJo d•scutidas no Caphulo 2.

1.8 Resumo 'este ~'apltulo. abordamos uma quantidade imensa de assuntos. Examrnamos as '"árras peças de hard\\~.trc c software que co mpOcm a Internet. em especial, c redes de computadores. em gemi. Começamos pela periferia da rede, exa minando sistemas finais c aplicaçocs, além do scn-iço de transporte fornecido às aplicaçocs que excetuam nos sistemas fl naís. Tam!X m vimos as tecnologias de camada de enlace c meio flsíco normalmente cncom rados na rede de :~cesso. Em segUida. mergulhamos no interior da rede c chegamos ao seu núcleo. identificando comlllação de paco tes c comutaç:'lo de circuitos como as duas abordagens bás icas do tmnsportc de dados por uma red e de tclccomunicaçõcs, expo ndo os pontos fortes e (racos de cada uma delas. Examinamos, cnt:lo, as panes inferiores (do J:>O li!O de vista da arquitetu ra) da red e - as tecnologias de camada de enlace c os meios rlsicos comumeme enco ntrados na rede de acesso. Exnmimunos também a estruwra da Internet glob;tl e aprend emos que ela é uma rede ele redes. Vimos que a estrutura hierárquica da lmcrnct, co mposta de lSPs de ní veis mais altos c mais baixos, permillu que ela se expand isse c mcluisse milh:ucs d e redes. N:t segunda pane deste capítulo introdutório, abordamos dive rsos tópicos rundamcnLais da área de redes d e computadores. Primeiramente examinamos as c.'ausas de atrasos c perd;IS de pacotes em uma rede de comutação de pacotes. Desenvolvemos mod elos quamltativos simples de atrasos de trans nüss;lo, de propagavlo e de ma; esses model os de atraSos serão muito usados nos problemas propostos em todo o lh•ro. Ern segu ida examinamos camadas de protocolo e modelos de serviço, princípios fund amentaiS de arquu etura de redes aos quais voltaremos a nos referir neste livro. Analis.1mos t.arn!Xm alguns dos ataq ues mais comuns na Internet atualmente. Terminamos nossa imroduÇtlo sobre redes com uma breve história das redes de compu~:~dorcs. O primeiro capilulo constitui um mimcurso sobre redes de com putadores. Porta nto, percorremos realmente um cxtraordinãrio caminho neste primeiro capitulo! Se voe~ csti\·cr um pouco assustado. m\o se preocupe. Abordaremos todas essas ideias em detalhes nos t:ap1tulos segui ntes (l uma promessa, c não uma ameaça! ). Por enq uanto, esperamos que, ao encerrar este capitulo, voct tenha adquirido uma noç:lo, ainda que mcipicnte, das peças que fom1am uma rede, um domlnio amda em descrwolvimcnto do vocabulário ( n;lo se acanhe de vo ltar aqui para consulta) c um desej o cada \ 'CZ maior de aprender mais sobre redes. Esta é n 1:1rcfa que nos espera no restante deste livro.

Oguiodeste livro i\ntcs de iniciarm os qualquer viagem, sempre é bom consultar um guia parn nos ramiliarizar com as cstrndas principais c desvios que encontraremos pela frente. O destino final da viage m que csuunos prestes a empreender é um cmcndimcnto profLmdo do como. elo quê e do porquê das red es d e co mput:tclorcs. Nosso guia é a scqu ~ncia de capit ulas des te lívro:

1. Redes de computadores e a lmern et 2. C::un:.da de aplicação 3 . Camada de transporte 4 . Cam(lda de rede

5 . Camada de enlace c redes locais (U\Ns) 6 . Sem fio c redes mó\'cis 7. Redes mul timídia 8 . Segurança em redes de computadores 9 . Gerenciamento de rcdr Os capítulos 2 a 5 s:lo os quatro capítulos centrais deste livro. Note que esses capft ulos est:\o organizados segundo as quatro camadas superiores da pilha de cinco camadas de protocolos da Internet, com um capitulo para

bow4tto4ic~ Redes de computadoras e o Internet

Capítulo 1

51

cada camada. Note tam~m que nossa jornada começará no topo da pUha de protocolos da Internet, a saber, a camada de aplica~"<\0, c prossegUirá dai para batxo. O principto racional que orienta essa JOrnada de c una para baixo é que. entcndtdas as aplkaçOes, podemos compreender os serviços de rede necess.irios para dar suporte a elas. En~>,o, poderemos examinar, um por um, os ''ários modos como css~ serviços poderiam ser implementados por uma arquitetura de rede. Assim. o ~tudo das aplicações logo no Inicio d:\ moth-aç-Jo para o restante do livro.

A segunda metade deste ll\'ro -

capilulos 6 a 9 - aborda quatro tópicos extremamente importantes (c de cena manctra independentes) de redes modernas. No Capítulo ó, exanunamos tecnologia sem fi o e mobilidade, incluindo LA s sem fio (Wi-Fi, WiMAX e Bluetoolh), redes de telefo nia cel ul ar (GSM) c mobilidade (nas redes IP c GSM). No C.1 pltulo 7 ( Redes muhimldia), cxamimunos aplicações d e áudio c vídeo. como telefone por Internet, videoconfert! ncía e recepção de midia armazenada. Exammamos também como uma rede de comu tação de pacotes pode ser projet:lda p:1ra prover serviço de q ualidad e consistente pa m aplicações d e :\udio c vfdco. No Ca phulo 8 (Scgumnça em red es d e computadores), analisamos, primeira mente, os runda mem os da cript og rafia c da seg uran ça de redes c, em seguida. d e que modo a teo ria básica está send o apli cada o um amplo leque de contex tos da lnlemc t. No último capfllllo (Gcrcncíamento de r<:dcs), examimHn os as questões funda mentais do gcrcncíamento de redes, bem como os protocolos primários da l tllcrnct u111izados para esse nm .

Exercícios de fixação Capitulo 1 Questõ~ de revisão ~õol.l 1.

Qual é a direrenca en tre um hospedeiro e um sistema final' Ci te os tÍJ>OS de sistemas finais. Um servidor Web t um sis1ema final?

2.

A palaw;1 protocolo é muito usada para descrever relactics diplom~tíeas. O~ um exemplo de um protocolo dlplo m.iueo.

S~õo

1.2

).

O que i: um programa cl iente? O que é um progmmn servidor? Um Jlro~r:mul servidor requisita ..: recebe serviços de um programa cliente?

... 5.

Cilc seis tecnologias de acesso. Classifique cada uma dcl:as nas categorias acesso rcsídcncial, acesso corporal h•o ou acesso movei. 1\ taxa de tmn ~mlssão ll FC é dedicada ou é co m-

partilhada entre usu:\rios? !: possível haver colisões na direç•\o provedor-usuário de um canal HFC? l"or que?

6.

Ci te seis tecnologias de acesso residencial disponíveis em sua ctdadc. Para cada tipo de acesso. apresente a taxa downstrcam, a taxa upstrcam c o preço mensal anunc13dos.

7.

Qual c a taxa de transmissão de L.ANs Etheme1? Para uma dada taxa de transmissão, cada usuário da L.AN pode transmi tir continuamente a essa taxa?

8.

Cile alguns meios rtslcos utilludos p:tra ins1alar a Ethernel.

1\lodems discados, II FC c ADSL s.\o USlldos parn :~cesso residencial. Para cada uma dessas tecnolo· gias de acesso. ci te uma r:uxa de taxas de transmissão e coment e se a la rgura de banda é eomp:milhada ou dedicada. I O. Dcscrc,·a as tccnologi~s de acesso sem fio mais populnrcs :nualmcntc. Faea uma comp:1raçlo entre elas.

9.

Seção 1.3

c a vantagem de uma rede de co muta~:lo de cireuilos em rclaç:lo a 11111a de conmtaçào de p.1cotcs? Quais sl\o as vantagens da TOM sobre a FDM em uma rede de co mutttcllo de circuitos?

ll. Qual

12. Por que se afimta que a com ut
13. Suponha que exista exatamente um comlllador de pacotes entre um computildor de origem c um de desti no. As tax:1s de transmiss.,o entre a maquina de origem e o comutador e entre este c a máquina de d~t ino slo R1 c R:. respccti\'3mcnte. Ad mitindo que um roteador use comutação de pacotes do tipo armazena e reenvia, qual é o atraso total fim a fim para enviar um pacote de comprimento L? (Desconsidere

I

bOWAttOOiC~


--~---------------------------formação ele fila. atraso de propagação e atraso de processamcnw).

a . Consldcrnndo que n!lo hnja nenhum outro

tràfego na rede , <1ual é a \'az:\o para a transrcri:n· cta de arqutvo?

H . Qual é principal chfc rcnc;a que dtstingtte ISPs de nível

I e de nh·cl 2? Suponha que usuários compartilhem um enlace de 2 Mb1>s c que c:~da usuârio transmita continuamente a I Mbps, mas cada um deles 1ransmitc apcnas 20 por ccn1o do tempo. (VeJa a discuss;to sobre muhi· plcxaç:lo cslallslica na Sccão 1.3). a . Quando a comulaeio de ctrcuilos é utilizada.

quantos uswlrios podem usllt
Seçõo 1.4 16. Considere o envio de um paco1e de uma máquina de ongcm a uma de destino por uma rola fixa. Relacione os componen1es do atraso que fom1am o atraso nm a firn Quais deles São constantes c quaís S;lo ,~.ari:IVcis?

b. Suponha que o arqui\'O lenha 4 milh{)cs de b)•tcs. Otvtdmdo u 1am:1nho do arqut\'O pela vauo, quanto 1empo le"ar:i a transfer~ncia pam o Hospedeiro B? c. Repita os itens •a• c "h". mas agora com Rl reduzido a I00 kbps. 20. Suponha que o sis1ema final A queira enviar um arquh•o grande pam o sistema 13. Em um mvcl muito aho, descreva corno o sis1em11 A cria pacotes a partir do arquivo. Quando um desses ar,l uivos cheg;.u ao comu tador de pacolc, qu:•ts tnrormaçMs no pacote o C{ltnutacl or utiliza pam clctcnninar Cl enlace alra\ré$ do qual <'pacote é encaminhado? Por que :1 comuta· çdo de pacote na In ternet é análoga a dirigir de uma cidade pam outrn pedindo informações ao longo do caminho? 21. Visile o applet "Queuing and Loss• nu Companion Website. Qual é :1 taxa de cmlss:lo m::\xima e a taxa

de emissão minim:t> Com essas ta~as. qual c a intcn· stdadc do tmrcgo? Execu1c o applc1 com essas taxas e detennlnc o tempo que lc\a a ocorrencia de uma perda de pacote. Repila o procednncmo uma scgun· dn \'ez e detem1ine novamente o tempo de ocorrincía pam a perda de pacole. Os resultados sJo difcrcmcs? Por que> Por que não>

Seção 15 22. Cite cinco 1arcf:t~ que uma camada 1'10dc executar.

É possi\'el que urna (ou mais) dessas tarefas seja(m) realizada(s) por duas (ou mais) cnmada)l

17. Visite o applet "Tmnsmission vei"Sus Propagation Dclay• no Cornr>anion Website. Entre as taxas, o atraso de propag:tç:\o c os tamanhos ele pacote dispon íveis, determine um01 co mbinação para a qual o emissc>r termine de li'JHISmitir antes que c> primeiro hil do p:u:ote chcRue ao r~CCI>Ior.

23. Quais s:lo as cinco ca m:ICias da pilha de protocolo da Internet? Quais as 1>rincip:~is rcsponsabllrdadcs de cada uma dessas camadas?

18. Q ua1110 temp~) um paco te de l.OOO bytcs leva para se prc•1>:1J..\a r :uravcs de um enlnce de 2.500 km de dist;'\ncia, com uma velocidade de propagação de 2,5 • IO"m/s c uma taxa de transmissão de l Mbps? Geralmente, quanto tempo um pacote de compri· mcnto L leva pata se propagar atravcs de um enlace de distdncta d, velocidade de propagação s. c taxa de tr:msmiss.lo de R hps? Esse atraso depende do comprimento do pacu1e? Esse atraso depende da 1axa de transmissólo?

25. Que camadas da pilha do protocolo du Internet um roteador implemcma? Q ue ca madas um comu1ador de camada de enlace implcrncn1a? Que camadas um sistema fin:~l ímplcmcrua?

19. Suponha que (I Hospedeiro A qucm1 enviar um arquivo grande pam o llospedeiro B. O percurso do Hospedeiro A para o Hospedeiro 13 possui rrês enlaces, de 1axas R1 =500 kbps, R1 =2 Mbps, e Rl =1 Mbps.

24. O que t.! uma n1cnsngcm de

c;un~da

de 3!)1ic;t<;•lo? Um se~mcnto de camada ele trans1>ortc? Um data· grama de camada de rede? Um <1unclro de camnda de cnlncc?

Seçõo 1.6 26. Qual t a diferença cmre um \'trus , um wornl e um c;avalo de Troia? 27. Descreva como pode ser criado uma homet e como

ela pode ser ulilizada no a1aquc ODoS.

bow4tto4ic~ Redes de compulodoru e o Internet

Capítulo 1

53

e enviar o que quiser 1>ara Bob: ela tambcm cons4:gue cnptumr todos os pacotes enviados por Bob c enviar o que quiser p;lm Alice. Cue algumas autudcs m:dictosas que Trudy pode fazer n parur de sua posição.

28. Suponha que Alice c Bob estejam enviando pacotes um paro o outro atmvts de uma rede de computa· dores c que Trudy se posictone na rede paro que ela constga capturar todos os pacotes cm1ados por Ahce

Problemas 1.

l.

Projete c descreva um llrotocolo de n1 vel de aplícaç:'lo paro ser usado entre um caixa automático c o computador central de \lJU banco. Esse protocolo deve permitir vcri llcaçllo d11 cnn.:\o c da senha de urn usuário, consulta do saldo de sua conta (que ê mantido no comr)luador central) c S.'\quc de dinhci· ro da conta co rre nte {isto 1!, e ntrega de dinheiro ao usuário). As c ntid:1dcs do llrotoco lo devem estar rncllamdas a resolver
b. Suj:lonha que todas as conext"'cs sejam entre o comut.1d{lr do canto superior esquerdo c o comuta• dor do canto inferíor direito. Qual é o numero máximo de cmu:xôes s imultâneas que 1xxlcm es1ar em ~;urso?

4.

a . Supo nh:1 que o comboio viaje 150 km. COiliC(;II1· do em fr·clllc ao primeiro dos JlOStos de pedágio, passando por um segundo c terminando após um terceiro. Qual ~ o atraso fim a rim? b. Repita o item 'a' admitindo agom que haja sele

carros no comboio em \'CZ de dez. 5.

Cons1dere uma aphcaç.\o que transmita dados a uma taxa con~t:mtc (por exemplo, :1 origem gera uma unidade de dndos de N bits a cada k unidades de tempo. onde k é IKqueno c fixo). Constckrc também que, quando essa aplicação começa, continuará em runcionamc nto por um pencxlo de tempo rdath'llmcntc longo. Rcspond:1 àS segui ntes pcrguntn.s. dando uma breve justificativa para suas respostas:

de pacote:.? Por quê?

d. Supo nha que o compu tador A comece :1 wmsmit ir o pacote no instante 1 • O. No instante 1 • cl.....,. onde estará o últ imo bit do pacote? e. Su(Xl nha
r.

Cons1dcre a rede de comutaç-lo de circuitos da Figura I 12 Lembre-se de que M 11 circuitos e m cada enlace. a. Qual c 11 numero máximo de conexões simultâneas que podem estar em curso a qualquer instante nessa rede?

dr,,.• e m termos

c. lgnornnd c1 os atrasos de processamento c de fila. obtenha tlllla eX Ilfes$.'\0 para O atraso fim a fim.

b. SuJl On hn que seja usada uma rede de cotmnação de pacotes c que o único tráfego dessa rede venha de n1llicaçõcs como a dcscríta anteriormente. Alem diSSCI, admita que n soma das ' 'clnddades de dados da aplicnçilo seja menor do que a capaci· dade de c:1da um dos en lttccs. Sem necessário algum tipo de controle de congestionamento? Por qu~? 3.

propaga~o.

b. Determine ll tcnii)O de translllbSão do p;lcote, cl,,...,. em termos de L c R.

um~ rede de comutação ele circuitos ou uma rede C\llll iiHICâo

Este problema clcmcntnr começ:1 a explorar mrasos de propagaç;lo c de transmí~o. dois conceitos ~.:cn· t rats em redes de computadores Considere dois compmadores. A c B. conectados JXlr um unico enlace de taxa R bp:.. Suponha que ~ computadores estejam separados por 111 metros c que a ,·clocidade de propagação ao longo do enlnce SI!Ja de s metros/segundo. O computador A tem de cnvinr um p;~cote de L bitS ao computador B a. Expresse o atraso de de rn c s.

a. O que seria m11i s aprorlriado para essa ap licaç:lo:
Considere novamente n analogia do comboio de carros da Sel;ilo 1.4. r\dmlt:t uma \'e locíclade de ,,ropa· gaç
d,..,...?

Suponha que d,..,. seja menor do que dtrans. Onde csmrá o primeiro bit do pacote no instame t=d.,..,?

g. Suponhas • 2.5 . lO'. L • 100 bits e R • 56 kbps. Encontre a dist.lncia m de rorma que t~ .,. seja igual a c!,_. 6.

Neste problema, consideramos o envio de voz em tempo real do compu tador A para o computador

bow4tto4ic~ Redes de to mputod ores e o Interne~1------------------------B por meto de umn rede de connuaçilo de pacotes (VoiP). O computo~dor t\ com·crtc ,·oz analógica para uma cadeia dt~ltnl de biiS de 64 kbps e. em seguida, :~grupa os btiS em pacotes de 56 bytes. Há apenas um enlace entre os computadores A e 8: sua taxa de transm1ss.\o é de 2 Mbps c seu atraso de propagação, de 10 milisscgundos. Assim que o comput~tdor A recolhe um pacote. ele o envia ao computador B. Quando recebe um pacote completo. o computador B converte os bits do pacote em um sinal :~nalógtco. Quanto tempo decorre entre o momento em que um bi t é criado {a p.~rtir do sinal analógico no com· pmador A) c c1 mome nto em que ele e decodi ficado (como parte dc1 sinal analógico no computador B)? 7.

Supon ha CJUC usu:\ rios com1>artilhcm um enlace de 3 Mhps e que cada usuário precise de 150 khps para transmi ti r, mns que transmi ta apenas durame lO por ccruo do tempo. (Veja a discuss;lo sobre muhip lcxa· ç:11> CSI
8.

Considere a discussJo na Scç:to 1.3 sobre muh iplexacJo cstaustica. na q ual é dado um exemplo com um enlace de I Mbp~. Quando em atividade. os usuários cst:lo gcr.mdo dados a uma taxa de 100 kpbs: mas a probabilidade de es tare m em atividade, gerando dados, é de I' • 0,1. Suponha que o enlace de l Mbps seja ~ubstil uldtl por um enlace de I Gbps. a. Qual é o número maximo de usuários. N, que J>Oclc ser su portado simuhancnmcmc por comu ta· c
9.

Considere um i>acotc de comprimento l que se inicia no sistema final A e percorre três et1laces ate um sistema final de destino. Esses três eoalces esl:lo conccllld~ por dois comutadorc:. de p;u:otes. Suponh3 que cl,. s, c R1 representem o comprimento, 3 ' 'cloci· d:tdc de prop:t~ac;;lo c a tax-a de transmissão do cnlncc i, sendo 1 • I. 2, 3. O comlllador de pacote atrasa cada pacote por ~ . Considerando
de propagaç:\o de ambos enl:tces seja 2,5 · 10' mls. as taxas de transm•ss:lo dos tr~ enlaces sejam 2 Mbps. o au·aso de proc~ment(l do comutador de l>acotc seja de 3 míllsscgundos, o comprimento do primeiro enlace SCJ:l 5.000 km. o comprimem~> do segundo seja -f.OOO km c do uh imo SCJa 1.000 km. Dados esses ' 'alores. qual c o atraso fim a fim?

10. No problema o~mcnor, suponha que R1 • R1 • R1 " R c d,...., • O. Suponha que o comutador de pactllc não armazena e cn\'ia pacotes, mas transmite imediata· mente cada bit receb ido antes de esperar o paco te chegar. Qual C o atm5(> fim a fi m?

c de ter· mina o enlace de saldu pelo qual o pncote deve ser enviado. Quando o paco te chega, um ou tro j:l es tá sendo transmitido nesse enlace de s:~ída c outros quatro j ~ cs t;\ll esperando pam serem transmitidos. Os pacotes SOssucm compnmcmo L. o enl:tce possu1 uma taxa de transmissão R x biiS do pacote sendo enViado J.1 roram transmiti· dos c ' pacotes jtt estilo 113 nla?

11 . Um com utador de paco te recebe um 11acote

12. Suponha que N pacotes cheguem smmltt~neamemc ao cn l:~cc no qual nlo h:i pacotes sendo transmiti· dos e nem pacotes enfileirados. Cada pacote tem L de comprimcmo c é lmn milido 11 taxa R. Qual é o atraso m(xlio p:tra os N t>acotcs? 13. Considere o atraso de fila em um burfer de roteador (antes de um enlace de satda). Suponha que todos os pacotes tenham L bits, <)UC a wa de transmissão scjtt de R bps e que N pacotes cheguem simuhanc.·unemc ao hurfcr a cada lNIR segundos. Detcnni ne o :maso de fila mMio paro um pacote. (Dica: o ntraso de fi ltt 11ara o primeiro pacote é zero: 1mm 11 segundo pncote, LIR: J>ara I) ICrcciro I>e3do na fórmula do atraso total {ísto t. o atraso de fila nuís o atraso de transmissão) do problema an terior, deduza um:~ fórmula para o atraso total em relação a 11 e Jl.


16. Considere um burfer de roteador ames de um enlace de S
b. Re1>ita o item ·a•. mas suponha também que um atraso de nta médio

~~.~.em

hajo:~

cada nó.

18 . Execute o pro~tr;una Traccroutc para veril'icar a rota

Clllre urna origem c um destino, no mesmo continente, I>ara trés horários diferentes do dia.

a. Octcm1inc a mcdiól r.: n desvio p;~drào dos ntr:ISOS de ida c \'Oha para Cólda um dos três horários. b. Dctern11ne o numero de roteadores no c-.tminho para cada um dos três. Os c:tminhos mudaram em algum dos hor;lrios? c. Tente tdcntificar o mlmero de redes ISPs pelas qu.lis o pacote do Traccroute passa clllrc origem c destino Roteadores com nomes semelhantes c/ ou endereços IP semelhantes devem ser considerados como parte do mesmo ISP. Em suas respostas, os maiores atrasos ocorrem nas interfaces de ftmnac
d. Faca o mesmo ,,ara uma origem c um desuno cm continentes diferentes. Compare os resultados (!entro do tncslllo continente com os rcsl,ltaeli.>s entre continentes diferentes. 19. Considere o exemrlo de va:tilo eorrespondcme á Figura 1.20 (b). A~ora imagine que h;lja M pares de clicmc·scrvidnr em vez de 10. R,. R, c R representam as t:lxas do enlace do servidor, enlaces do cliente c enlace da rede. Suponha que os outros enlaces possuam capacidade abundante c que não haja outro tráfego na rede ::Mm daquele gerado pelos M pares de clic nte-servidvr. Deduza uma express;lo geral para a v::u::do em rcl;~ção" R,. R,. ReM. 20. Cot\Sldcre a Ftgura 1.19 (b). Agora suponha que h;lja M percursos entre o scnidor c o cliente. Nenhum dos d01s percursos companilham llualquer enlace. O percurso k (k • I..... M) consiSte em N enlaces com taxas de transmiss:lo R~, R~ ...; R~ Se o servidor pode usar somente um percurso para enviar dados ao cliente,

Redes de
55

qual é a vazdo m:lxima que ele pode atingir? Se o servidor pode U!hlr tlldos us M percursos p.~ra enviar dados, qu:tl e :1 \':lzllo mi\xima que ele pode aun~1r? 21. Considere a figuro I IQ (h) Suponha que c:tda ~:nlacc entre o )CI'\•idur c u cliente possu.1 uma probabilidade de p<"rda de pacote p. c que as probabilidades de perda de pacote para esses enlaces sejam independentes. Qual c a probabilidade de um p;tcotc (enviadn pelo sen•idor) ser rccehldt) com sucesso pelo receptor? Se o .,.,cote se p<'rtlcr no percurso do servidor para o cliente, enu1o o senidor rctrat\Smi tirá o JXtCote. Na m~diá, quanta:; vezes o servidor rctransmítínl o pacote p:tra que o cliente o receba com suce~~ 22. Cot\Siderc n Figum 1.19 (a). Suponha que o enlace de g:1rgalll a(l kmgu do p~:rcurso do servidor para o cliente seja o primeiro com a taxa R, hr)s. Imagine que cn vi ;unos um ():Ir ti c J):ICOICS um a pós o outro do servidor p:1rn o cliente, c que nâo haja nenhum outro tr:lf~:go nesse percurso. Imagine tamhém que c.ada p:~cote de tamanhu L bits c os dois enlaces tenham o mesmo atraso de pmp:l~tt<;:'lo <1,....

a. Qual é o temJ'lll entre chegadas ao destiM? Isto é. Cllltlnto tempo tmnscorre de quando o ultimo hit do primeiro pacme chega até o ultimo bit do segund:1 pacote chc~ar' b. Agora suponha que o segundo enlace seja o de gargalo ( isto é. R, < R). É possí\'el que o segundo pacote entre na ma de entrada do segundo enlace? Exphquc t\gora un>~gme que o servidor cn''lc o segundo pacote r segundos após enviar O primeiro. QudO grande deve ser r parn garal\liT que nilo haja nenhuma ma antes do segundo cnl~cc? Explique. 2.3. Suponha que vocc queira enviar. ltrgentcmcnte, 40 tcrabytcs de cl~dos de l3oston 1ma Los Angclcs. Você tem disponíve l um enlace dcdicadv de 100 Mbps 1>ara trnnsfcr~ ncia tlc dados. VocC csoolhcria tmns· mitir os dados l>llr melo desse enlace llll usar o sen•iço de cntrcg<~ 24 horns t'cdEx? Expliq ue. 24. Suponha que dois computadores, A e B, estejam SCJ><~mdos por uma dist~ncla de 20 mil quilômetros c conectados por um enlace direto de R s 2 Mbps. Suponha que a vcloddadc de prOJ><~gaç:'lo pelo enlace seja de 2,5 • IO" metros 11or segundo. a. Calcule o produto largura de banda-atraso

R·dI" f'. b. Considere o envio de um :mtuivo de 800 mil bits do computador A para o computador B. Suponha que o arttutvo seJ~ enviado continuamente, como se fosse uma única grande mensagem. Qual é o número máximo de bits que cstarã no enlace a qualquer dado instante?

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r n;.;e.;.t_________________________

c:. lnterpn!te o produto largura de banda-atraso. d. Qual é o com primento (em metros) de um biL no enlace? ~ maior do que a de um campo de futebol ? c.

Derive uma cxprcss:lo geral para o com primento de um hil em termos da velocidade de propaga· ç;\o s, da velocid;~dc de transmissão R e do com· primemo do enlace m.

25. Com refcrcncla ao 1>rohlcma H . suponh:t que JIDS· s:unos modiOcar R !'ara qual valor de R o compri·

memo de um bit sem do cnla cel

o mesmo que o comprimento

26. Ctlnsiderc o pmblcma

2-t. mns agora com um enl ace

de R = I Ghps.

a . Calcule o produto largura de banda-atraso. R. drAt'. b. Considere o ctwlo de um arquivo de 800 mil bits do computador A para o computador n. Suponha que o arqu ivo seja cn\•tado continuamente. como se fosse uma ünica grande mensagem. Qual será o numero m.lximo de bit que cstarà no enlace a qualquer dado instante? c. Qual é o com primemo (em metros) de um bit no enlace:? 27. No,·amcmc com referência ao problema 24.

a. Quanto tempo demora para enviar o arquivo, admitindo que de seja en,•i:tdo continuamente?

29. Em redes modernas de comutnçào de pacotes. a máquma de origem segmenta mensagens longas de camada de aplicac;lo (ptlr cxcmplu. uma imagem ou um arquivo de müs1ca) em [>:tCO tcs menores e os envia pela rede. A m~qulna destin:u:lria. cnt:io, monta no,·nmente os pacotes restaurando a mensagem origtna l. Denominamos esse processo s.:gmcnW· («lo de Jllcnsagcm. A Figura 1.28 ilustra o transporte nrn a rim de uma mensagem com c se rn segmenta· ção. Considere que uma mcnsn~cm de 8 · 10" bits de cornprl mcnto t~nha de ser enviada da origem no destino na Figura I 28. SUJlonha que a velocidade de cada enlace da ngura seja 2 Mbps. Ignore atrasos de propagaç-Ju. de ma c de processa mento. a . Considere o cnvin da mellS3gcm da origem ao destino ~tm segmenta~o. Quanto tempo essa mensagem levará para ir da m;iquina de origem até o primeiro comu t:tdor de pacotes? Tendo em mente que cada comu tador usa comutação de pacotes do IÍJlO annazena-e-rccswia. qual é o tempo total p~tm lc,'3r a mensagem da máquina de origem à maquma de desuno?

Finalmente. ndm ha que o emissor nâo possa enviar um paco te nté que o anterior tenha sido reconhecido. Qunnto tel11()() demornn! t>am etwlar o arquivo ?

b. Agora suponha que a mensagem seja segmentada em 4 mil l'acotcs. cada um com 2.000 bitS de comprimento. Quanto tempo demorará para o 1>rimeiro pacote ir da máquina de origem até o f>rlmeiro comutador? Quando o primeiro paco te está sendo envi:1do do primeiro ao segu ndo comutador, o segundn pacote está sendo enviado ela máquina de urigc m ao prlmcir\) comutador. Ern que Instante o segundo p~ cotc terá sido completamente recebido no primeiro co mutad or?

Compare os resu ltados de ·a· c 'b'.

c.

b. Suponha agora que o arquivo seja fragmen tado em 20 pacotes c que cada pncote con tenha -tO mel bits. Sttptlnha que cada pacote seja verificado pelo receptor c que o tempo de transmiSSão tle uma \'CriOcaç:\o de pacote seja desprcth·cl.

c. Sttp~m ha

que haja um enlace de microondas de 10 Mbps entre um satélite gcoestacíonár-io c sua cs t:~<:!lo-base na Terra. A c:tda mmuto o satélitt: Lira um:~ fow digu:tl c a cnv1a !I cstaçM·base. Admita uma ' 'docídadc de propagaç;lo de 2,-f • I o-• metros por segundo.

a . Qual é o atraso de i>ropaga<:;\o do enlace? b. Qual é o produto largura de banda-atraso. R· d....,.? c.

28. Considere a analogia da viagem nerca que utilizamos em nossa dlscusslo sobre c:unadas na Seção 1.7, c a adição de cabeçalhos a unidades de dados de protocolo cnquamo passam por sua pilha. Existe uma noção equivalente de adicào de inrormacõcs de cabeçalho :1 movimentaclo de passagcin>s c suas malas pela pilha de protocolos da linha aerea?

SeJa x o tamanho da foto. Qual c o ' ':.tlor mmimo de x para que o enlace de micro-ondas transmita con tin uamen te?

Q uan to tempo dcmomrá para movimentar o nrqui\'o dn máquina dr o ri~cm nt~ n m~q11ina de destino
d. Discuta a) clesvanta~ens da segmenta<;ão de mensagem. 30. Experimen te o ~• pplct "Mcssagc Scgmemation apre·

sentad o" no sue Wcb deste livro. Os atrasos no applct correspondem aos atrasos obtidos no problema an terior? Como os atrasos de propagac:'lo no enlace afetam o atraso total nm a f'im na comutação de pacotes (com segmentação de mensagem) c na comutação de mensagens?


Redes de compulodores e o Internei

Origem a.

ComutadOf de pacotes

Comutildor de pac:otes

Destino

Oflgem b.

Comutador de pacotes

Comutador d
Destino

57

Figuro 1.28 Tump011e fim o fim de mensagem: o) sem segmentação de mensogem; (b) com segmentação de mensagem cada e adie iema 80 bits de cahcç:~l ho a cada segme n to, formando p:acotcs d e: L • --10 + S híts. Cada cn lt~ce tem tnn;~ Luxa tle tr.msml»:1o de R bps. Qual é o valor de S que mínímizn o utr:ISo para levar o ar<1uivo de A pa"" n? Desco nsidere o a tmso de propagação.

3 1. Considere tl envio de um arqu ivo grande de F hils do com1>utador 1\ para o C
(c um comut:~dor) en tre eles c os enlaces nào cstiío congcs ticn1ad os (b.h.> é, nào M :11r:~sos de fila) . O com· putador A fragmcma o arqui,•o em segmentos de 5 bits

Questõesdissertotivos l.

Que tipoS de Sef\ IÇOS de telefone celular sem fio cstào disponlvcts em sua arC:J'

2.

Usando tecnologta de LAN sem fio 802.11 , elabore o rrojeto de um:• rede doméStiC3 J13ra sua casa o u para a casa de seus pais. Relacione os modelos de rrodutos especlfícos para essa rede domestica juntamente com seus cus tos.

J.

Descreva os scf'•lços Skrpc PC para PC. Experimente o SCf\1iCO de vfd co do Sk)'JlC: PC f>31';\ rc c relate " cxpcri~ nci:~ .

...

O Skypc uferccc um sc rvlco (juc rlermite realizar c h:nnadas tcleroni cas de um computador par:~ um comjlu tntl or comum. Isso signine<:t que :1 cl13mad:~ deve passar pela Internet e 1>cla rede telefônica. Discuttl como esse processo deve ser feito.

5.

O que é Shon Mcs.sage Servicc? Em qu:~is paisesl cont inentes esse serviço é comum? É possível enviar uma mensagem SMS de um si te Web para um telefone (XIrtjtíJ?

6.

7.

O que é recepção de vídeo armazenado? Quais são os sites Web mats IX>put;arcs que oferecem esse sef'•ico hoje? O que é recepção de \tdC(I em tempo rc31 por P2P? Quais são os si tes Web mais populares que oferecem esse scf'•iço hoje?

8.

Descubra cinco empresas que oferecem sef''iços de comp.milhamcnto de arqui\'OS P2P. Cite os tipos de arquivos (Isto é. conteudo) que cada empresa processa.

9.

Quem inventou o ICQ. o 1>rimelro SCf\'ÍÇO de men· sagem mstantdnca? Quando foi uwcntado c que idade tinham seus inventores? Quem inventou o Napster? Qua ndo foi hwt'ntado c
10 . Quais sào as semelhanças c dlfcren~as e ntre as tecnologias W i-Fí c 3G de acesso se m fio~ Int erne t? Quais sdo us taxas de bits dos clois serviços? Quais s.'lo os custos? Discuta ro:un ing e acesso d e qun lqucr lugar.

11. Por que o serviço oriE:InAl de compn rtílhamcm o d e ;uqui\•o !'2P allStcr deixou de ex istir? O que é :1 RIAA e qttc p rov idê ncias est:l tom:~nclo para limitar o comp~rt llhamcnto de a rquivos P2P de contclldo pro· tcgido por direito:. autorais? Qu.tl é a diferença en tre ' 'iolaçào de direttos autorais dtrcta c indirctll? 12. O que e BnTorrcnt? No que etc dircrc de um scníco de compartilhamento de an:1uivo P2P. como cDon· key, LtmcWtrc ou K;tz:~a? 13. Voe\! acha que d~qut .1 de:: anos redes de computa· dores ai"da compartilhar.lo amplamente arqui\•os protegidos por direitos autorais? Por que sim ou por que não? justifique.

bow4tto4ic~ Redes de co 11 putod ores e o Inle r.;;n.;;,e,;..t_________________________

Wireshark Lab ·crmtr-nu: c ru ~urcrrcl. Mostre-me Em·t~IWI-IIII" r ru rntcnclcrd •

I'

cu lembrarei.

Provérbio chinês A comprecns;lo de pro1ocolos de rede pode ser mui lo mais profunda se os vlnnos em aç:lo e imeraginnos com eles - observando a scqul:ncia de mcnsõlgcns Lrocadas entre duas entidades de protocolo. pesquisando detalhes de sua opcraç:lo, fazendo cmn que eles execmem determinadas aç1'cs c observando essas . Isso pode ser f4.'1to em cenários simulados 11u crn nm :unblcmc real de rede, tal eümo a lntemet. Os apt,lcts Java apresentados (em Inglês) rw si tc dcSlé livro adot;\111 a primeira aburcla~cm. Nos Wíreshark labs adotaremos ,, uhlm:t. Voçê cxc~:utam aplltn\·ues de rede em vários ccn;lrios utilizando seu computador no escritório, em casa ou em um labora1ório e observará também os pr01ocolos de rede uucragmdo c trocando mensagens com entidades de pro1ocolo que es1ao executando em outros lugares da lntcmct. Assim. \'OCê c seu computador serão partes intc· gmntcs desses laboratórios no vivo c \ "OCÍ: observará - c aprenderá- fazendo.

•.J (\Jnllllodl

lll>tr«l

Menu de COm.lndO

Listagem de pacotes ce~ptur<~dos

Figura 1.29 Umo omostro de leio do Pfogromo Vlireshort:

A rcrramcma bás1ca para observar as mensagens trocadas entre en1idadc:s de pro1ocolos em cxc:cuç;\o é denominad:1 annhsador de pacotes. Como o nome sugere. um analisador de pacotes recebe passivamcnlc mensagens enviadas c recebidas por seu compmador: também exibe o comcudo dos vários campos de protocolo das mensagens que cap1ura. Umn1cln do nn:~lis.1dor de pacotes Wlrcshark é rnos1rada na Figum 1.29. O \Vircshark c um analisador de 1>:1et)ICS pratulto ia du progmma. accssar.l um si t~.: w~b c cxõlmínar.l as mensagens de protocolo trOCõldas entre seu browser c o servidor Wcb. Voe!' encontrará detalhes complc1os, em inglês, sobre este primeiro Wlreshark Lab (incluindo instmções sobre como ob1er c insrnlar o programa) no si rc www.aw.com/ku rosc_br. [-:~~

bow4tto4ic~

leonord Kleinrock leonord Kleinrock é pl'ofessor de ciência da computação do Universidade do Colif6mio em Los Angeles. Em 1969, seu computador na UCLA se tornou o pl'imeiro n6 do Internei. Ele aiou os princípios do comutoçõo de pacotes em 1961, que se tornou a lecnologio bósico do Internet leooord tombém é presidente e fundador da Nomodix, Inc., uma componhio cujo tecnologia oferece maior ocessibilidode o serviços de In rnet bando largo. Ele é bacharel em engenharia elétrico pelo City College of New Yori (CCNY) e me~tre e doutor em engenharia elé-trico pelo Instituto de Tecnologi do Mossochusetts (Mil}.

O que o fez se decidir pelo especialização em tecnologia de redes/Internet? Como doutomndo do MIT em 1959, percebi que a maioria dos meus colegas ele wnm1 estava fazendo pesquisas nas áreas de Lcoria d:1 informa~1io c de teoria da codifkaçào. Havia no MIT o gmndc ~ ui sador Claude Shannon, que já tinha proposlo estudos nessas drcas c resolvido a maior pane dos problemas importantes. Os problemas que restaram para pesquisar eram dif1ccis c de menor importância. Ponanto, decidi propor uma 110\f:l área na qu:1l até cnuio ninguém tinha pensado. Lembre-se de que no MIT. cu estava cerClldo ele computadores. c er.t evidente para mim que brevemente aquelas máquinas teriam de se comunicar umas com as outros. Na época, não havia nenhum meio eficaz de fazer ISSO; pon:1mo, decidi desenvolver a tecnologia que pcrmiúria a criaç-lo de redes de dados eficientes. Qual foi seu primeiro emprego no setor de computoçõo? O que implicava? Frequentei o curso noturno de grnduaç:io em engenharia elé-tnca da CCNY de 1951 a 1957. Dur.tntc o d1a, trabalhei inicialmente como t~cnico c depois como engenheiro em uma pequena empresa de elctrOnie~ industrial chamada Photobcll. Enquanto trabalhava lã. introduzi tecnologia dtgital na linha de produtos da empresa. Essencialmente, est:l\f:lmos us:tndo equipamentos fotoclétricos para detectar a presença de certos ítens (caixas, pessoas etc.) c a u1ilização de um circuito conhecido na época como mullivi/Jrador birswve/ era c>e:uamcnte o tipo de tecnologia de que prccisavamos pnra le,oar o processamento digital a esse ct~mpo da detecção. Acontece que esses circuitos sào os blocos de construç:'o básicos dos computadores e ''icram a ser conhecidos como flip-flot's ou comuwtlolcs nn linguagem coloquial de hoje.

O que possou por sua cabeça quando enviou a primeira mensagem computador a computador (do UCLA poro o Stanford Reseorch lnstitute)? Fmnc
bow4tto4ic~ a vis<1o que cu tinha ela Interne t naquela é~
O fáal c prcdtzer a infracslrutura por si mesma. Eu antecipo q ue vemos uma tmplanLaç:\o considerável de computa· ç:1o nômade. aparelhos móv•eis e espaços inteligemes. Realmente. a disponibilidade de computaç:lo pon:\til, de aho desempenho, accsslvcl e leve c de aparelho de comunicaç-Jo (mais a onipresença da Internet) nos permitiu tornar nômades. A computação nOmadc refere-se à tecnologia que permite aos usuarios finais. que viajam ele um lugar p-.ua o outro. ganhar acesso aos serviços da lruemet de maneira transparente, nao importando para o nde ' "''o c q Ltal aparel ho possue m ou g:mham :tccsso. O difícil é predizer as aplicações c serviços, que nos surpreenderam co tuistentemcntc de formas dramát icas (c·mai l. tecnologias de bus~1. a rede de ak~mcc mundial , blogs. red es sociais, gcmç:lo de usu:lrios c compartilhamento de música. fotos, vídeos etc.). Eswmos na margem de uma nova 4.-atego· ria d e aplicações móveis, inovadoras e surpreendentes presemes e m n ossos apa re lhos portáteis.

O passo seguinte vai nos ~·apacic :1r a sair d o mundo misterioso do dbc rcs paço para o mundo frslco d os cs r>aços intelige ntes. A cccno logia dará vida a nossos ambientes (mesas, J:X:tredcs. vc fcul os. relógios e ci ntos, entre outros) po r meio ele atuaclores. sensorcs. lógica, processamento, armaze nagem, ct\mems. microfones. ah o-falamcs. painéis c comunicação. Essa 1ec nologia cmbmida permitirá que nosso ambiente fo rn e~tdcr.IV'cl mcnte mator gerado não tanto por seres hum:mos. mas por esses equipamentos embutidos c agcn1es nneligcmes de software. Vejo grandes conjumos de ststcmas auto-orgamz:lvc ts controlando essa rede imensa c veloz. Vejo quantidades enormes de informações zunindo por essa rede inst:mLancamcntc c passando por cxtmordin:\rios processamentos c Ohrogens. A Internet será. essencialmente, um sistema nervoso de presença global. Vejo tudo isso c mats enquanto entramos de cabeça no sêculo XX I. Que pessoas o inspiraram profiuionalmente? Quem mais me inspi rou foi Claude Shannon, do MIT, um brilhante pesq uisador qu e tinha :\ capacidade de relacionar suas idcias macemáci cas com o mundo frsico de modo muitíssi mo intuit ivo. Ele fazia pane da banca cx.uninadora de minha tese d e doutorodo. Você pode dar algum conselho aos estudantes que estão ingressando no área de redes/ Internet? A Internet. c llldo o que ela habilita, é uma vasta fronLeira nova. cheia ele desaOos surpree nd entes. llá es paço para gronclcs inovações. Nt\o Aquem limi1~1dos à tecnologia existent e hoje. Soltem sua Imaginação e pe nse m no que poderia aco ntecer c transformem isso em realidade.

bow4tto4ic~

Camada de aplicação

A

pliações silo a mzão de ser de uma rede de computadores. Se não fosse possível inventar aplicações úteis, mlo havcrí:t necessidade de projetar protocolos de rede p:trJ suportá-las. Nos últimos 40 :mos, fomm criadas numerosas aplicações de rede engenhosas e mamvilhosas. Emrc elas estilo as aplicações clássicas de texto, que se tomamm populares na década de 1970 e 1980: correio elctrõnic:o, acesso a computa· dores remotos. tmnsfcr~ncia de arquivo, grupos de discuss;lo c batc-p;tpo c também uma aplicação que alc:mçou estrondoso sucesso em meados da década de 1990; a Wor/d Wic/e Wcb. abrangendo a navega\-:lo na Web, busca e o comércio eletrônico. Duas aplicações de cnonn c sucesso também surgiram no final do mil~nio -mensagem instamãnc:a com lista de amigos c companilhamcnto P2P de arq uivos, assim como muit:IS aplicações de áudio c vidco, incluindo a telefonia por Internet, transmissão c compartilhamento de \1dco, rádio via Internet c telcvis:lo sobre o protocolo IP (IPTV). Além disso. a pcnetraÇ
Em seguida, aborda mos desenvolvimento de apl icação de rede por TCP e também 1><>r UOP. Em particular, csLuclamos o AI' I soekct c examinamos algumas apl icações clieme-servidor s imples em Java. Aprcscnt:unos também vl\rios cxercfcios divertidos e interessantes de progmmaç•lo de aplicações no rlm1l do ~apftulo. A t',H11llda de apl icação é um lugar particularmente bom pam iniciarmos o est udo de protocolos. É ten eno familiar, pois conhecemos muitas das aplicações que dependem dos protocolos que estudaremos. Ela nos dará uma boa ideia do que s:lo protocolos c nos apresentará mui tos assuntos que cnt'Ontrarcmos novamen te quando estudannos protocolos de camadns de transporte. de rede e de enlace.

2.1

Princípios de aplicações de rede

Suponha que \'OC~ tenha uma grande ideia para uma 1\0\'J. aplicação de rede. Essa aplicaçM será. wlvez, um grande serviço para a humanidade, o u agradará a seu professor, ou fará de você um homem (ou mulher) rico(a), ou sirnplesmeruc será dh·ertido desenvolvê-la. Seja q ual for sua motivação, vamos examinar agora como transformar a ideia em uma aplicação do mundo real.


O cerne do desenvolvimento de :tplk-aç-Jo de rede é escrever programas que rodem em sistemas finais dife· rentes c se comuniquem entre si pela rcd~ Por exemplo. n:t aplicaçao Wcb há dois programas distintos que se comunicam um com o OUiro: o progr.una do browser. que roda na máquina do usu:lrio (computador de mesa, laptop. PDA. telefone celular e assun por diante); e o programa do servidor Web. que roda na máquina do serVIdor Web. Outro exemplo é um SIStema de comparolhamen to de arqu1vos P2P no qual h:l um programa em cada m:lquma que participa da comunidade de companilhamemo de arquivos. Nesse caso, os programas de cada máquin:1 podem ser semelhantes ou id~micos. Portanto, ao desenvolver sua nova aplicação, você prccís;u:\ escrevu um software que rode em vários sistemas finais. Esse software podena ser eri:tdo. por exemplo. em C, Java ou P)•thon. Importante: voe~ ntlo prccis:~r:\ escrever programas que executem nos elementos do núcJco de rede. como roteadores e switches. Mesmo se quisesse. \'OC~ não poderia escrever programas para esses elementos. Como aprendemos no Capitulo I c mostmmos na Figura 1.24, equipmnemos de núcleo de rede n:\o funcionam na mmada de aplicar;'ào, mas em mmadas mais baix:1s, espcdfic:uncntc na de rede e ab;tixo dela. Esse r>rojeto básico- a saber. confinar o software de aplicação nos sistemas finais, como moStra a Figum 2.1. f.1cilitou o desenvolvimento c a prolifera<;;\o rápidos de uma \11Sta gmna de aplicações de Internet

2.1.1 Arquiteturas de aplire em mente que a arquitetura de uma aplic;~ção é distintamente diferente da arquitetura de rede (por exemplo, a :uquitetura em cinco camadas da Internet que discu timos no Capitulo 1). Do pomo de \•ista do proOssional que desenvolve a aplicaç:1o, a arquitetura de rede é nxa c prO\'~ um conjumo cspeciOco de serviços às aplimçóes. Por outro lado, a arquitetura da aplicaç.\o é projetad;"t pelo desenvolvedor c determina como a aplicação é organiznda nos vários sistemas finais. Ao escolher a arquitetum da aplicação. o desenvolvedor provõwclmcnte aproveit:1rá uma das duas arquiteturas mais milizadas em aplicac;Ocs modernas de rede: a arquitetura clientc-sef\·ldor ou a arquitcturn P2P. Em uma arquitetura dicme·sef\•idor há um hospedeiro sempre em func1onamento, denominado scrvir.lor. que atende a requisições de muitos outros hospedeiros, denominados clirnles. Estes podem estar em funcionamento às ,·ezcs ou sempre. Um exemplo clássico é a aplicação Web na qual um sef\'idor Wcb que está sempre em funcionamento atende a requisições de browscrs de hospedeiros clientes. Quando recebe uma requisição de um objeto de um hospedeiro cliente, um servidor Web responde enviando o objeto rcquisllado a ele. Obsef\'Cque. na arquhetum díentc-scrvidor, os clientes não se comuním m diretamente uns com os outros; por exemplo, na :tplicação \Veb, doís browscrs ni\o se comunicam diretamente. Outra característica da arquitetura clicme-servldor é que o scf\1dor tem um endereço fixo. bem conhecido, denominado endereço IP (que discutiremos em breve). Devido a essa caracterfstica do servidor c devido ao fato de ele estar sempre em runcaonamento. um cliente s empre pode contatá-lo. enviando um pacote ao endereço do servidor. Algumas das ap licações mais conhecidas que e111pregam a arquitetura cliente-servidor são Web, FTP, Telnet c c-mail. Essa arquitetura cliemc-scrvidor é mostrada na Figura 2.2(u). Em e~plícuc;õcs cliente-servidor, muitas ' 'czcs acontece de um tírm:o hospeclciro servidor ser inc:1p:tz ele atender a todas as requisições de se us dleme:s. Por exemplo. um site Wcb popular pode ficar mpidamcme saturado se ti ver apenas um SCf\•idor para atender a 1odas as requisições. Por essa raz.l\o, um grnndc conjunto de hospedeiros- às vezes coletivamente chamado data center- frequentemente é usado para cr1ar um servidor virtual poderoso em arquiteturas clientc-sef\·idor. Os serviços de aplicaç:\o baseados na arqu1tctura cliente-servidor s:.\o geralmente de infraestrutura intensiva, uma vez que requerem que os provedores de serviço comprem, instalem e prcsef\•cm o servcr Jcrnn. Além disso. os provedores de sef\•ic;o devem pagar as despesas de imcrconexi\o recor· rente c largurn de banda para enviar e receber dados para c da Internet. Serviços populares como mecanismos de busca (por exemplo. o Googlc). comércio via Internet (por exemplo, Am:1zon c c-Bar). e- mail basc:~do na Web ( por exemplo, Yahoo Mail), rede social ( por exemplo. M}'Space c Facebook) c compartilhamento de vrdeo (por exemplo, YouTubc) exigem muita infraestrutura c são de fornecimento diSpendioso. Em uma arqu it etura P2P, há uma confiança mínima (ou nenhuma) nos servidores sempre em funcionamento. Em vez disso, a aplicação utiliza a comunicação direta entre pares de hospedeiros conectados

bow4tto4ic~ (opílulo 2

Camada de

oplico~õo

ISP Nacional ou Global

Rede móvel

Apllcaç6o Transporto

Rede Aplkaç;,o

Enlace

ll'ansporte

Ftslca

Red~

Rede corporativa

Figura 2.1 A(Omunicoçõo de umo oplicoçõo de rede O(Orre en11e sistemas finais no comado de opli(oçõo

altcrnadamcmc. denominados pares. Os pares não são de propriedade dos provedores de scr"Viço. mas são controlados por us uários de compmadores de mesa e laptops. sendo que a maioria dos pares se :tloja em rcsid~ncias, uni ve rsidades c escritórios. Como os pares se comunicam sem r>:tssar por nenhum servidor dcdic:tdo, :1 arquitetura é denominada par-a-par (fJar-IO·p<• r - P2P). Muitas das nplicnç6cs de hoje mais populares c de intenso tráfego são baseadas nas arquiteturas P2P. incluindo distribuição de arquivos (por exemplo. 6itTorrcnt), compartilhamento de arquivo (por exemplo. eMule c LimcWire), telefonia por Internet ( por exemplo. Sk)-pe) e IPTV (por exemplo, PPUve). Essa arquitetura está tlustrnda na Figura 2.2 (b). Mencionamos que algumas aplicações possuem arquiteturas híbridas, combinando elementos cliente· -servidor e P2P. Por exemplo, para muitas aplicações de mensagem instantânea, os servidores costumam

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'-------------------------

(a) Arquitetur
figura 2.2 (o) Alquiteturo lim~·õt's de dis tribuição de vfdeo tr:msrercm o tráfego de saída dos servidores p:~ra ISPs residenciais, colocando, assim , uma pressllo s ignificativa nos ISPs. 1\s fmuras aplietwOcs P2P precisam ser criadas para que sejam ;unigávds aos lSPs IXic, 20081 . 2. Segurtlll('CI. Em raz:\o de sua muurcza altamente dístribufda c expost;l, as aplicações P2P podem ser um desafio p:~m proteger (Doucer, 2002: Y~t. 2006: Liang, 2006: Naoumov, 2006: Dhungcl, 2008). 3. Tnceuthos. O sucesso das futuras aplicações P2P também depende de usu:lrios participatl\•os para oferecer largum de banda, nm1azcnamcmo c recursos da compmaç-Jo às aplícaçõcs, um projeto dcs:1fiador de mccntivo (Feldman, 2005: Piatck, 2008: Apcrjis, 20081 .

2.1.2 Comunicação entre processos Antes de construir sua aplicação de rede, você também precisará ter um entendimento básico de como programas que rodam em vários sistemas rinais comunicam-se entre s i. No jargão de sistemas


(am ado de oplicosõo

65

operacionais, na ve rdade n ão são programas. mas process os que se comunicam. Um processo pode ser imaginado com o um programa que está rodando dentro d e um siste ma final. Q uando os processos estilo roda nd o no mesmo sistem a fi na l. eles comunicam-se entre si u sando comunicação interprocessos. CuJaS regras s
Processos clientes e processos servidores Uma aplka~"ào de rede consiste em pares de processos que enviam mensnviando o arquivo é ro tulado d e cliente c o que es tá recebendo, de servido r. Talvez voe~ já tenha observado que, em algumas aplicações. tal como compartilhamento de arquivos P2P, um processo pode ser ambos, cliente c servidor. Realmente. um processo em um sistema de compartilhamento d e arquivos P2P pode carreg;-~r e descarregar arqul\•os. ~ esmo assi m. no contexto de qualquer d:1da sess;lo entre um par de processos, ainda podemos rotular um processo de cliente c o outro de servidor. Definimos os processos cliente c scn•idor como Stguc:

No conttxto dt urue1 scssclo de comunicaçclo t>nlrc um JXt' de t>roccssos. o t>rous::.o cfiiC' inicicr t1 cortlllllictl(c1o (isto é, o 11riml'iro " contata r o outro no infclo da scssclo) é rotultrdo dr cliente. O processo ttur rSJJC'HI sr1 contc1Wclo para inicicrr" scssclo f o sen •idor. Na Wcb. um processo d o browscr in icia o contato com um processo do servid or Web; por co nseguinte. o processo do browscr é o cliente e o processo do servidor W eb é o sen •ldo r. No compartilhamento d e arqui· vos P2P. quand o o Pa r A solicita ao Par 8 o envio d e um arquivo específico. o Par A é o cliente enquan to o Par B é o servidor no contexto dessa sessão específica ele comunicac;;ão. Quando n ão houver possibilidade

de confus.io. às vezes usaremos também a terminologia wlado cliente e Indo servidor ele uma aplicação~. No final deste ~:aprtulo cxnmlmucmos passo a passo um cód igo sim ples para ambos os lados de aplicações de red e: o Indo cliente c o Indo servidor.

Ainterface entre o processoe o rede de computadores Como d isse mos anteriormente, a maio ria das aplicações t·o ns iste em pares de processos comunicantes. sendo q ue os dois processos de cada par e nviam mensagens um para o outro. Qualquer mensagem cnviad;~ de um processo para um o utro tem d e passar pela rede subjacen te. Um processo envia mensagens para a rede c recebe mens.1gcns dela através d e uma interface d e software d enominad a socket. Vamos con siderar uma analogia que nos auxiliará a entender processos c sockcts. Um processo é ana logo a uma casa c seu socket, à porta da casa. Q uando um p rocesso q uer t>nviar uma m ensagem a um outro processo em o utro h ospedeiro, e le empurra a mens.1gem pela po rta (socket). Esse processo emissor admite que exista uma infraestrutura de transporte d o outro lado de sua port.1 que tra nsportará a mensagem pela rede até a porta d o

processo destinarario. Ao chegar ao hospedeiro destinatário, a mensagem passa atr:wcs da porta (socket) do processo receptor, que e ntão executa alguma ação sobre a mensagem.

bow4tto4ic~ Redes de co 111 pulod ores e o Inle ;.; rn;.;e;.;.l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

i\ Figura 2.3 Ilustra a comunicaç;\o por socket entre dois processos que se comunicam pela Internet. (i\ F1gura 2.3 admite que o protocolo de transporte su bjacente usado pelos processos c o TCP.) Como mostra essa figur.t , um socket é a interface emre a camada de aplicaç-Jo e a de transporte dentro de uma máquina. ~

também denominado interface de programaç-lo da aplicaç-lo (lrppllccuion p10gmmmlng lnltlfcrcr- API) cmre a aplicação e a rede, \'isto que o sockct é a interface de programação pela qual as aphcaçOes de rede são inseridas na Internet. O dcscnvoh•edor da aplicaç-Jo controla tudo o que existe no lado da camada de aplicaç.\o do sockct, mas tem pouco comrolc do lado da camada de transporte do sockct. Os unicos controles que o desenvolvedor da aplicaç-lo tem do lado da camada de t ransporte são: ( l ) a ~olha do protocolo de transporte e ( 2), talvez, a capacidade de determinar alguns parâmetros da camada de ~ransportc. tais como tamanho máximo de buffcr e de segmentos (a serem abordados no Caprtulo 3). Uma vez escolhido um protocolo de transporte. (se houver escolha) o descrwolvcd or constrói a aplicaçõlO usando os serviços da cam:~da de transporte oferecidos por esse protocolo. Examinaremos sockets mais dctalhadamcnte nas seções 2.7 c 2.8.

2.1.3 Serviços de transporte disponíveis paro aplicações Lembre-se ele q ue um socket é a interface entre o processo d<1 aplicaçllo c o pro10colo de callla(Í.1 de tr;uls· porte. i\ RJ>lkt\ç;\o do lado remetente envia mensagens atr.wés do sockct. Do outro lado do socket, o protocolo de <:~1111:1da de tr.msportc tern :1 rcsponsabilídade de levar as mensagens pela rede at~ :1 "porta• do sockct destinatário. Mui tas redes, inclusive a Internet, oferecem mais de um protocolo de camada de transporte. Ao desenvolver uma aplil..õl(ilo, voce deve escolher um dos protocolos de camada de transporte disponlveis. Como fa.zer essa escolha? O mais provável t que você avalie os serviços providos pelos protocolos de c:tmada de transporte disponíveis c escolha o protocolo que melhor atenda às necessidades de sua aplicação. A siluaçllo c! semelhante a escolher trem ou a'•i;lo como meio de transporte entre duas cidades. Voce tem de escolher um ou outro, c cada modalidade de transporte oferece serv1ços d1ferentcs. Por exemplo, o trem oferece a facilidade da partida e da chcg:tda no centro da cidade. ao passo que o a\'lão oferece menor tempo de viagem. Quais s:.lo os serviços que um protocolo da camada de transporte pode oferecer :\s aplicaçOcs que o chamem? Podemos classificar, de maneira geral, os posslvcis serviços segundo quatro dimensões: transferência confiável de dados. va.zão, tcmporiza~-ão c segurança.

Transferência confiável de dados Como discutido no Cat)flulo 1. os pacotes podem se perder dentro de uma rede de computador. Um pacote pode, por exemplo. exceder um buffer em um roteador, ou ser descartado por um hospedeiro ou um ro teador

Controlado pe lo d e1envolvedor

da

Hospedeiro

Hospedalro

ou seNfdor

ou servidor

---r

Controlado pelo desenvolvedor da apllcaç&o

aplicaç~

Conttolado - -+ pelo s•stema operacional

TCPcom

buffen.

variáveis

Internet

Figura 2.3 Processos de oplicoçõo, sockets e protocolo de tronsporte subjocente

TO' com buffers, variáveis

Controlado

pelo sistema oper acionai

bow4tto4ic~ ( opítulo 2

(amada de aplicasõo

67

:tpós alguns de seus bits terem sido corrompidos. Para muilas aplicações- como correio eleuõnico, transferência de arquivo, acesso remoto. tr:mfert'ncias de documemos da Web c aplicações Onancciras- a perda de dados pode ter conscquências dc,•astadoras (no ühimo caso. para o banco e para o cliemc!). Assnn, parn suportar essas apli· caçOes. algo deve ser feito para garnntir que os dados enviados por um:l extremidade da apliCõl~'õ\o sejam enviados correta c completamente parn a outrn extremidade da aplicação. Se um protocolo fornecer um serviço de rece· bimcnto de dados garamidos, ele fornecerá uma transfe rência conOável de dados. Um imponamc sen·i~·o que o protocolo da camada de transporte pode oferecer parn uma aphcação e a trnnsferi!ncia conOavel de dados processo

a processo. Quando um protocolo de transporte of~rece ~serviço, o processo remetem~ pode pãSSar s~us d3dos para um socket e saber com absoluta confiança que os dados chegarão sem erro ao processo destinatário. Quando um protocolo da camada de transporte não oferece uma trnnsferi!nci:l couOltvcl de dados, os dados em•iados pelo processo remetente podem nunca chegar ao processo destinatário. Isso pode ser aceitável para apli· caçõcs tolernntcs a perda, aplicações de multimídia como áudio/vídeo em tempo real ou áudioNídeo armazenado, que podem tolerar uma qunmidadc de perda de dados. Nessas aplicnçOcs muhlmldln, dados perdidos podem resu ltar em uma pequena f:1lha durMte a execução do áudio/vídeo- o que m1o é um prejufzo cruci:1l.

Vozõo No Capitulo I apresentamos o conceito de vazão disponí,•el, que, no contexto de scss.lo <1:1 cormmica~:'\o entre dois processos <10 longo de um caminho de rede. é a taxa à qual o processo remcterHc pode ctwiar bits ao processo des tinatário. Como outms sessões comparlilhar;\o u lnrgura de banda no l"tuninho da rede.' c CSL;lO indo c voltando, a vaz:\o disponlvcl pode oscilar com o tempo. Essas observrrçOes levam :1 outro serviço natural que um protocolo da camada de transporte pode oferet~r. ou seja, urna vazão dispomvcl garnntida a uma taxa específica. Com tal sen·iço, a aplicaç:\o pode solicitar uma \'azilo garantida de r bilsls, c o protocolo de trnnsporte garante, então, que a vaz:\o disponível SCJa sempre r bits/s, pelo menos. Tal sen•iço de vazão garnntida aparece em muitaS aplicações. Por exemplo, se uma aplicação de telefonia por Internet codiOca voz a 32 bits/s, ela prccis:t enviar dados parn a rede e fazer com que sejam entregues na aplicação receptora a essa mesma taxa. Se o protocolo de trnnsporte não puder fornecer essa vaz:lo. a :1plicação precisará codiOcar a uma taxa menor (c receber vazão suOcientc parn sustentar css.1 taxa de codifica\"ilO mais baixa) ou cnt;lo desistir, já que receber metade da vaz<\0 de que precisa de nada adiant:l para essa aplicação de tcldonia por Internet. Aplicações que possuam necessidade de vazilo sâo conhec1das como aplkaçOcs sensíveis à largura de banda. Muitas aplicações de muhimtdia existentes sâo sensíveis à largurn de banda, embora algumas poder-ao usar técnicas adapt.ath•as de codiOcaçilo para codi0c-Jr a uma taxa que corresponcl:~ à vazão disponível n:1 ocasilio. Emborn apliraçocs sensfveis à largurn de banda possuam necessidades espcdOcas de vaz..\o, as aplicações elásticas podem fazer uso de qualquer quantidade mfnirna ou múxim:l que por acaso esteja disponível. Correio eletrOnko. trnns feréncla de :1rqurvo.s c transreréncias Web são todas aplicações clltstkus. Evidentemente, quanto mais vazão, melhor. li::\ um di t:ldo que d iz que "dinheiro nunca é demais": nesse cas o, podemos dizer que vazão nunca é demais!

Temporiza~ão Um protocolo da camada de transporte pode também oferecer garantl:ls de temporiz:lçào. Como na garantia de vazão. as gar:tntias de temporizaçilo podem surgir em diversos aspectos c modos. Podemos citar como exemplo o fato de que c:1d:• bit que o remetente insere no socket chega ao socket destina tário em menos de 100 mílisse· gundos depois. Esse serviço scri:lmrativo para aplicações interativas em tempo real. como a telefonia por lmemct. ambientes virtuais, tcleconferenera c jogos nmhijogadorcs. que exigem rcstnçOcs de tcmporizaç;'o no envio de dados J>an• gar.truir eOeáéia. (Vcj:l Capitulo 7, (Gaulhier, 1999; R:unjce. 1994] .) Longos .ttr:lSOS na telefonia por Internet. por exemplo. tendem a resultar em pausas artificiais na convcrs:1ç;\o: em um jogo multiusu;\rio ou amb1cntc VIrtual interativo, um longo atraso emre realizar uma a~"ào e ver a rCõ\~-:1o do ambien te (por e.xemplo. a rca\"110 de um outro jog:1dor na omra extremidade de uma conexão Om a Om) faz com que a :tplicaç:lo pareça menos realista. Para aplicações que não são em tempo real, é sempre preferível um atraso menor a um maior. mas não há nenhuma limitação estrita aos atrasos fim a fim.


Seguronço Por fim. um protocolo de transporte pode oferecer uma aplicação com u m ou mais ser'i~·os de scgumnça. Por exemplo, no hospedeiro remetente, um protocolo de transporte pode codificar todos os d;~dos transmitidos pelo processo remetente c , no hospedeiro destinatário, o protocolo da camada de transporte pode codificar os dados antes de enviá-los ao processo destinatário. T;~l serviço pode oferecer s•g•lo entre os dois processos. mesmo que os dados SCJalll, de algum modo. observados entre os processos remetente c dcsunat. no. Um protocolo de transporte pode, al~m do sigilo, fornecer outros serviços de segurança, incluindo integridade dos dados c aulcn ticaç.1o do ponto tenmn;~l , assuntos que serão :~bordados em det;~lhcs no C:-.pítulo 8.

2.1.4 Serviços de transporte providos pelo Internet A t~ aq ui, consideramos serviços de transportes que uma rede de t·omputadorcs IWtlrlitl oferecer em geral. Vamos :1gom nos nprofundar mais no assunto c tlllalisar o tipo de suporte de aplicaç
Serviços do TCP O modelo de serviço TCP inclui um serviço orientado para conexão c um scrv1ço confiável de transferência de d:tdos. Qu:tndo uma aplicaç-lo solicit:.t o TCP como seu protocolo de transpor te, recebe dele ambos os serviços. Serviço orientado para conexão: o TCP faz com que o cliente e o servidor troquem informações de comrolc de camada de transport e ames que as mensagens de camada de aplicação comecem a Ouir. Esse procedimento de apresentação, por assim dizer. alerta o clicme c o sen•idor, permitindo que eles se preparem para uma enxurrada de pacotes. Após ;t fase de aprcsentaç.,o. dizemos que existe u m;t conexão TCP entre os sockcts dos dois processos. A conexão~ fu ll-duplcx (simultânea), visto que os dois processos podem enviar mensagens um ao Olttro pela concx:'lo <~O mesmo tempo. Q uando tcnnina de enviar mensagens, a aplicação deve imerromper a conexno. Esse serviço é chamado de sen •iço woricnt.1do pam conex:\o·, c não serviço kdc concx:\o·. porque os dois processos cst:.\o conectados de um modo muito solto. No Capítulo 3. discutiremos detalhadamcn tc serviço orientado p;1ra eonexilo c examinaremos como ele é implementado. Servi('o ronjiá l•fl dr traus1wnr: os processos comunicantcs podem co nfiar no TCP para a emrega de

todos os dados enviados sem erro e na ordem corrct.1. Quando um lado da aplk":l~'lo passa uma cadeia

Apnca~ão

Perda de dados

1roosferên
~peido

~peido

Sem peido

Telefonia via Wemet/lideoconferênOO

Jclerllflfe à pe~do

Wo/YMieo ouoozenodo

Toleroote à perdo TcieriJlle à pe~do Sem peido

Jogos r:terotívos 1.\ensogem ilsfontóneo

Largura de banda

Figura 2.4 Requisitos de oplicoções de rede selecionados

Sensiblndadt ao atraso Niio

Elôsti
V'!deo: 1Okbos - SMbos lgld O
Sim: dé6mos de segu.W Sim: olgltlS seg~~~dos Sim: dé
bow4tto4ic~ ( opílulo 2

(amado de

oplico~õo

69

de bytes para dentro d e um socket, pode contar co m o TCP para entregar a mesma cadeia de dados ao socket recepto r, sem falta de b)•tes nem bytes duplicados. O TCP também incl ui um mecanismo de controle de congestionamento . um serviço voltado ao bem-esta r geral da Internet c n:lo ao beneficio d ireto dos processos comun icantes. O mecanis mo de controle de congestionamento do TCP limita a capacidade d e transmíss.\o de um processo (clie nte o u servidor) quando a rede está congesuonada entre cliente c servido r. Em particular, como ' 'cremos no Capitulo 3, o controle de congestionamento do TCP tenta limitar cada conexão do TCP à s ua justa porção de largura de b.mda de rede. A limitação da velocidade de transmissão pode ter um efeito muito prej udicial sohre aplicações d e áudio c vídeo em 1empo real que impo nham uma li nuta\o\o de largura d e banda mfnima. Além disso. aplicações em tempo real s;\ o to lerantes à perda e no\o necessitam de um serviço d e trans porte to talmente confiável. Por essas razões. desenvo h·cdores de aplicações em tempo real usual mente executam suas aplicações em UDP, c não em TCP.

Serviços do UDP O UDP é utn protocolo de transporte s implillcado, leve, com um mod elo d e servi ço minimalis ta. Ê um se rvi~·o não orientad o para conex ao; portamo. não há apresentação :Hlles que os dois processos comecem a

se comunicar. O UDP prove um serviço não confiável de transre rênda d e dados - isto é, quando um pro· cesso en via um:-. mcnsngem pam dentro de um socke t U DP. o protocolo não oferece nwluuna garantia de qu e a mensagem ch egará no processo recep10r. Além do mais. mensagens qu e rea lm ente chegam ao processo recepto r pod em cheg:~r fom de o rdem. O UDP não inclui um meçanisrno de controle de congestionamento: portanto, um prcx:esso originado r pode bombear dados para dentro de uma camada abaixo (a canmda d e rede) à taxa que quiser. (Observe, entretanto, que a \'azJo nm a nm pode ser menor do que essa taxa devido à largura de bando li mitada d e enlaces intervenientes ou ao congesti onamento). Como aplkações em tempo real usualmente podem tolerar uma certa perda

Um conjunto impressiononte de sistemos finois do Internet protegendo o TCP Nem o TCP ou o UDP fornecem qualquer codificação - o~ dado~ quo o processo remetente transfere poro seu socket são os mesmos que percorrem o rede até o processo deslinatório. Então, por exemplo, se o processo destinatário enviar uma senha em cleortext (ou seja, não codificado) poro seu sockel, elo percor· reró por todos os enlaces entre o remetente e o destinatário, sendo analisada e descoberto em qualquer um dos enlaces in tervenientes. Em razão de o privacidade e outros questões de segurança terem se tornado importantes poro muitas opllcoções, o comunidade do Internet desenvolveu um aperfeiçoamento poro o TCP, denominado Camada de Sockets Seguros (SSLJ . O operfeiçoomenlo SSL paro o TCP não somente faz rudo que o TCP trodicianol foz, como também oferece serviços importantes de segurança processo o proceuo, incluindo codificação, integridade dos dados e autenticação do ponto de chegado. Salientamos que o SSl não é um terceiro protocolo do Internet, no mesmo nível do TCP e do UDP, mos um aperfeiçoamento do TCP implementado no camada de aplicação. Particularmente, se uma aplicação quiser utilizar o serviço do SSI., é preciso incluir o código SSL(existente, bibliotecas oito mente olimizodos e os clones) do aplicação em ambos os portes cliente e servidor. O SSL possui suo próprio API de socket que é semelhante à tradicional API de socket TCP. Quando uma aplicação utilizo o SSl, o processo remelenta transfere dados em c/eortexl poro o socket SSl; no hospedeiro emissor, então, o SSL codifico os dados e os posso poro o socket TCP. Os dodos codificados percorrem o Internet até o socket TCP no ptocesso remetente. O socket remetente posso os dodos codificados ao SSL, que os decodifico. Por fim, o SSl posso os dodos em c/eortext por $8U socket SSL oté o processo deslinotório. Abordaremos o SSl em mois detalhes no Capítulo 8.

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------de d:~dos, m:lS exigem uma mxa mfnima, desenvolvedores desse tipo de aplicações frequentemente preferem executá-l:lS por UDP, evitando, assim. o controle de congestionamento c os cabeçalhos de pacotes do TCP. Por outro lado, como mu11os fircwalls esuio configumdos pam bloqu<.'ar (a ma10na dos u pos de) tráfego UDP. os projctisl:lS têm escolhido, cada vez ma is, executar aplicações muhimfdia c em tempo rc:~l por meio do TCP ISripanidkulchai. 20041.

Serviços nõo providos pelos protocolos de transporte do Internet Organizamos os serviços do protocolo de tr:tnsportc em quatro dimensões: tranfcrencia confiável de dados, vazão, tcmporizaç-;io c segurança. Q uais desses serviços sào providos pelo TCP c pelo UDP? já vimos que o TCP pro,·ê! a lr:tnsferê!ncia confiável de dados fim a fim, e sabemos tarnbem que ele pode ser ap rimorado facilmente na camada de: aplicaç-;lo com o SSL pam oferecer serviços de segurança. Mas em nossa breve descrição sobre o TCP c o UOP. faltou mencionar 1ts gamnl ias de vaz:io c de temporizaç11o- scrvi~'OS mlo fornecidos pelos protocolos de transporte cl:1 Internet de hoje. Isso significa que as aplicações sensíveis ao tempo, como Ll 1elcfoni:l por lmcrnct não podem rod:~r na Internet atunl? J\ resposta é claramente ncgali\•a- a ln1crne1 1cm recebido essas aplicações por mui tos anos. Tais ap licações muí1as vezes funcionam bem, por terem sido dcscnvolvid:~s para lidar, na medida do possível, com essa falta de gara nlia. Analisaremos vários desses anifrcios de criaç;1o no 0 1piwlo 7. 'o crnan· to, a criaçflo engenhosa possui suas limitações quando o :Hra.so é excessivo. co mo é o ,·uso frc<1ue111e da Internet pública. Em resumo, a lmcrncl de hoje pode ofcrcçcr serviços salisfatórios a :1plk açOcs sensíveis ao tempo, mas nào garantias de temporização ou de largura de banda. A Figura 2.5 mostra os r>rotocolos de transporte usados por algumas aplicações populares da Internet.

Vemos que c-mail. a Wcb, acesso a lcrminais remotos e transferência de arquivos usam o TCP. Essas aplicações escolheram o TCP primordialmente porque ele oferece um serviço co nfiáve l de transferência de d ados. garantindo que todos eles mais cedo o u mais tarde cheguem a seu destino. Vemos também que a aplacação de telcfoma por Internet no rmalmente funciona em UDP. Cada lado de uma aplicação de telefone por Internet precisa enviar dados pela rede a urna taxa mínima (veja a Figura 2.4 ). o que é mais provavelmeme posstvel com UDP do que com TCP. E. também, :1plicaçOes de telefone por Internet silo 10lcrantcs às perdas, de modo que não necessitam do serviço confiável de transferência de dados provido pelo TCP.

Endereçamento de processos Nossa discussão acima se f
Aph
COJreio elerrooi
lroosletên
Prota
ProtO
Figura 2.5 Aplicações populares do Internet, seus protocolos de camada de aplicação e seus protocolos de ITonsporte subjacentes


(amado de oplicosõo

71

'a lntemet. o hospedeiro é idcnúflcado por seu endereço lP. Discutiremos endereços IP em detalhes no Capuulo 4. Por enquanto, bast:~ saber que o endereço IP é uma q u:~nt idadc de 32 bitS que identifica rxdusiwuntnte o sistema fln:~l. (Emrctanto, como veremos no Capítulo 4. a implemcntaç;\o ampla do NAT (Traduç:lo de Endereços de Rede) significa que, na prática, um endereço IP de 32 bitS sozinho não endcrc"-a exclusivamente um hospedeiro.) Além de saber o endereço do sistema f mal ao qual a mensagem se destina, o hospedeiro originador também deve identificar o processo que est.1 rodando no outro hospcdciro. Essa informação é nct'CSS.1ria porque, em geral, um hospedeiro podrria estar cxccut.'\ndo muitas aplicações de rede. Um número de porta de destino atende a essa flnalid:~de. Aplicações populares receberam numcros de porta espccfncos. Por exemr>lo. um scrv•dor Web é idrnufkado pelo número de porta 80. Um processo servidor de corr6o (que lLS.'\ o protocolo SMTP) é identificado pelo numero de porta 25. Uma lista de numeros bem conhecidos de portas para todos os protocolos padronizados da lntemet pode ser encontrada no si te hllp:l/www.ian:~.org. Quando um desenvolvedor cria um:~ no\'a apllcaç-âo de rede, ela deve receber um novo numero de porta. Examinaremos mímc:ros de porta dct.'llhad;uncnte no Capitulo 3.

2.1.5 Protocolos de camada de aplicação Acabamos de aprender que procc:ssos de rede comunicam-se entre s i cnvl:mdo mensagens para dentro de sockctS. Mas, como ess:LS mcnsagcrtS s:io estrmuradas? O que signHkam os v:\rlos ca mpos nas mcns:tgens? Qua ndo os processos enviam as mrns:~gens? Essas perguntas nos transporwm para o mundo dos protocolos de c-Jnmda de aplicaçào. Um protocolo de camada d e apUcaçào deOnc como processos de uma aplicaç;lo, que funcionam em sistemas finais diferentes, pass:1m mcns:~gcns entre si. Em p:~rti cular, um p•·otocolo de cam:~da de aplie:~çào define: os tipos de mcnS:Igens trocadas, por exemplo. de req uisiçào e de resposta: a smtaxc dos \':inos tipos de mensagens. tais como os campos da mensagem c como os campos s.'\o dclmcados: a srml\nlica dos campos, is to é, o signiflatdo da infonnaçM nos campos: regras para dctcrnunar q uando e como um processo envia mcnS:Igcns c responde a mensagens. ;\lguns protocolos de e:~mada de aplicação estão especificados em RFCs c, port:lnto, s.lo de dom m io publico. Por exemplo. o protocolo de camada de aplicação da Wcb.IITTP (ltn>erTcxt Transfcr Protocol [RFC 2616)), está à disposiç;lo como u m RFC. Se um desenvolvedor de browscr seguir
1: import:m tc distinguir aplicações de rede de protocolos de c-.unadtt de aplit-aç;,o. Um protocolo de camada de aplicaç;lo é apenas um I>Cdaço (embora grnnde) de aplicação de rede. Examinemos a lgu ns exemplos. A Wcb é uma aplicação dlentc-ser"iclor que pennitc aos usuári os obter documentos de servidores Web por dcm;tnda. A :Lplicaçào Wcb consiste em muitos componentes, entre eles um padrilo p~ua formato ele docu mentos (isto é, HTML), browsers Wcb (por exemplo, Fircfox c Microsoft Internet Explorcr). servidores Web ( por exemplo, servidores Apachr c Microsoft) c um protocolo de camada de :~plica~·ào. O protocolo de camada ele ap licaç.lo da Web, IITTP, define o formato c a sequMcía das mensagens que s.lo pasS:Idas entre o browscr e o servidor Web. Assim, ele é apenas um pedaço (embora importante) da aplicaç:1o Wcb. Como outro exemplo, considere a aplica~-;\o correio clctrOnito da Internet que também tem muitos componentes, entre eles scrv1dorcs de correto que armazenam caixas postais de usu:lrios, leitores de correio que permitem aos usu:lrios ler c criar mcnsageJJS, um padn\o que define como mensagens são passadas entre servidores c entre srrvidorcs c leitores de correio r como o contcudo de certas partes da mensagem de correio (por exemplo, urn cabeçalho) deve ser ímerprctado. O principal protocolo de camada de aplicação para o correio eletrônico é o SMTP- Simple Mail Protocol [RFC 5321). Assim, o SMTP é apenas um pedaço (embora importante) da aplicação correio eletrônico.

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------

7.1.6 Aplicações de rede abordadas neste livro 'o\·as aphcações de Internet de domínio público e proprietárias são descnvoMdas todos os dras. Em vez de tratarmos de um grande nlimero dessas aplicações de maneira cnciclopfdrca. prdcnmos focalizar um pequeno nümcro de aplicações ao mesmo tempo importantes c populares. este capitulo. discutiremos cinco aplicações populares: a Wcb, a tmnsfcrtncia de arquivos. o correio clctrOnko, o serviço de dirctóno c aplicações P2P. Discutiremos primeiramente a 'Web não somente porque ela é uma aplicaç.\o imensamente popular, mas também porque seu protocolo de camada de aplicação, HTTP, é direto e fácil de entender. Após examinarmos a Web. examrnaremos bre\•emente o FTP porque este protocolo oferece um ótimo contraste com o HTTP. Em seguida, discutiremos o correio eletrônico, a primeira aplicação de enorme sucesso da Internet. O correio eletrônico é mais complexo do que a Web, no sentido de que usa não somente um, mas vdrios protocolos de camada de aphcaç:lO. Após o e-mail , estudaremos o DNS, que provê um serviço de diretório para a lmcrnet. A maioria dos usuários nilo intcragc diretamente com o DNS; em vez disso, eles o chamam indirewmentc por meio de ou tras aplicações (inclusive a Wcb, a t ransfcrênda de a rquivos c o correio clctrOnico). O DNS ilustru primorosamente como um componcruc de fu ndon:tlidacle de nudeo de rede (tracluç:lo de nome de rede para endereço de rede) pode ser implementado na camad;1 de aplicação da Internet. Finalmente, discutiremos o compartllllamento ele ;~rquivos P2P que, segundo algumas medições (por exemplo, tráfego de rede), t a classe de Aplicações mais popular da lnu~rnct de hoje. Finalmente. discutiremos várins aplicações P2P, incluindo distribuiç-.'\o de urquivo, banco de dados distribufdos e telefonia IP.

2.2 AWeb eo HTTP Até a década de 1990, a 1mcmct era usada primordialmente por pesquisadores, acad~micos e estudantes univcrsila ri os para se interligar com hospedeiros remo tos, transferir arquivos de hospedeiros I:tra qualquer indivfduo faze r <"O m que lnform<~ çõcs fiquem disponiveis na Wcb; todo mundo pode se trans formar em editor a um custo cxtrem:uucntc baixo. Hipcrcnlaccs c buscadorcs nos ajucl~tm a navegar pelo occauo dos sitcs Wcb. Dispositivos gr:tOcos estimulam nossos scnlidos. Formulários, applctsjava c muilos outros drsposill\•os nos habilitam a interagir com páginas c sites. E, cada vez mais, a Web oferece um menu de interfaces para vastas quantidades de material de vídeo c áudio armazenadas na lnternet- áudio e vídeo que podem ser acessados por dcm:~nda .

7.2.1

Descrição geral do HTTP

O HTIP - Protocolo de Transferên cia de Hipertext o (llypcrTcxt Transfcr Protocol) - protocolo de camada de aphcação da Wcb, esta no coração da Web e ê definido no IRFC 19451 c no IRFC 26161. O liTTP é implementado em dois programas: um programa cliente e outro servidor. Os dois programas, executados em sistemas finais difcremes, conversam um com o outro por meio da troca de mensagens HTTP. O liTTP define a


Camad a de

o pl i' o ~õo

73

estnuu ro dessas mensagens e o modo como o cliente e o servidor as trocam. Ames de explicarmos detalhad arnente o HITP, devemos revisar a termi nologia da Web. Uma página Web (tamb~m denominada documento) f consútufda de objetos. Um objeto ~ simplesmente um arquavo- tal como um arquivo HTML. u ma amagem JP EG. um appletja'""'· ou um clipe de vídeo- que se pode accss.·u com um unico URL. A maioria das páginas Wcb ~ cons útu!da de um a rq uh•o-base HTML e diversos objetos rderenci;ados. Por exemplo. se uma página Web comi\·er um tex to IITML c cinco imagens JPEG. cntilo ela terá sets ob;etos: o arquavo-base HTML e mnis as cinco imagens. O arquavo-bnse HTML rcferencaa os outros objetos na págma com os URLs dos objetos. Cada URL tem dois componentes: o nome do hospedeiro do servidor que abriga o objeto c o nome do caminho do objeto. Por exemplo. no URL h~lp://www.someSchool

.edu/someOepartment/picture.gff

www.someSchool.edu e o nome do hospedeiro c /some0epartment/picture.g1f é o do caminho. Como browscrs We b tamb~m im plementam o lado cliente do HTIP, podemos US<1r as p~lav ras browsrr e dirnlr incliferentcmcnte no contexto da \Vcb. Os servidores Web wmb~m implementam o lado servidor do HTTP, abrigam objetos Wcb, cada um endereçado por um URL São servidores Wcb J>Opulares o Ap:•chc c o Microsoft lllternct lnform:uion Server. O Hn ·p de011e como clientes \ Veb requisitam páginas Web aos servidores c como eles as transrcrem a clientes. Discutiremos det:tlhadamente a i rncra~·:lo entre dicme c servidor amtis adhtntc, mas a idcia geral cst:\ ilustrada na Figura 2.6. Q uando um usu:\ r10 requisita u ma página Web (por exemplo. d ica sobre um hipercnlace). o browscr e1wht no scrv1dor mensagens de req uisição HTTP para os ObJetos dn pági na. O servidor recebe as req uisições c responde com mensagens de resposta Hn·p CjUe contêm os objetos. O HTTP usa o TCP como seu pro tocolo de transporte subjaccmc (em vez de rodar em UDP). O cliente HTTP primeiramente inicia uma conex:lo TCP com o seMdor. Uma vez estabelecida a concx:lo. os processos do browscr e do scrvaclor acessam o TCP por mcao de suas in terfaces sockets. Como descrito na Seção l.l, no lado cliente a interface socket e a porta cmre o processo cliemc c a conex:lo TCP; no lado servidor. ela é a porta entre o processo servidor c a conexão TCP. O cliente envia mensagens d e requ isição HTTP para sua interface socket c recebe mensagens de resposta HTTP de sua interface socket. De maneira semelhante, o servidor HTTP recebe mensagens de requlsiç.l o de sua interface socket c envia mensagens de resposta para sua interface socket. Assim que o cliente envia uma mensagem para sua Interface socket. a mensagem sai de suas mãos c "passa para as maos do TCP". Lembre-se de que na Seção 2.1 dissemos que o TCP pro\·ê ao HTTP u m scrvi~·o conOâvel de tmnsferência d e dados, o q ue unp lica que tod:~ mensagem ele requisic-
~

PC exe
Figura 2.6 Comportamento de requisição-resposta do HITP

Mac executando Navigator

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------HTTP não precisa se preocupar com dados perdidos ou com detalh es de como o TCP rccupcm a perda de dados o u os rcordcn;t dentro da rede. Essa é a ta refa do TCP c dos protocolos das camadas mais inferiores da pilha de protocolos. (; unponante notar que o servidor cm·ia ao cliente os arqu ivos solicitados sem :.rmazenar nenhuma inforrnaç;\o de es~:~do sobre este. Se um detemún:.do cliente solicita o mesmo objeto duas vezes em um pcnodo de poucos segundos. o servidor não responde dizendo que acabou de enviar o objeto ao clicme: em vez disso, cn,•ia novamente o objeto, po•s já esqueceu completamente o que fez antes. Como o servidor l!TTP não manttm nenhum:. inform::~ çt\o sobre clientes. o IITTP é denominado u m protocolo sem estado. S:lhcntamos tambtm que a \Veb usa a arqui tetura de aplicação cliente-servidor, como descrito na Seção 2.1. Um servidor Wcb está sempre em funcionamento, tem um endcrc~·o IP nxo c atende requisições de pOLcncialmeme milhões de browscrs diferentes.

2.2.2 Conexões persistentes e não persistentes Em muitas aplicações da lmernct, o cliente e o servidor se comunicam r><> r um perfodo prolongado de tempo, em que o cliente faz um:. série de requisições c o servidor responde a cada uma delas. Dependendo d:t aplicac;i\o e ele como ela csHi sendo usada, a série de requisições pocle ser feit:t ele form::~ consecutiva, periodicamente em Intervalos regulares ou esporadicamente. Quando a interação cliente-servido r acontece por meio de concxM TCP, o criador da a1>licação precisa tomar uma importante dc(;iS'lo- cada par de req uisiç;\o/resposta deve ser enviado por uma conexão TCP tlistiuw ou tOd:JS as requisições e suas respostas devem ser cnviada.s por um:. m esma conexão TCP? Na abordagem anterior, a aplicação miliza conexões não pcrsistcmcs; c na ultima abordagem, conexões persisten tes. Pam obter uma maior compreensão deste :JSsunto, vamos analisar as \'an tagcns c des\'antagcns das concxocs m\o persistentes c das conexões persistentes no contexto de uma :1phcação cspccíOca, o HTIP. que pode utilizar essas du:JS conexões. Embora o HTIP utilize conexões persisten tes em seu modo padrão, os clientes c servidores IITTP podem ser configurados para utilimr a conexão não persistente.

OHTTP com conexões não persistentes V::~m os percorrer :JS etapas da transferência de uma página Wcb de um servidor paro um cliente para o caso de conexões n, o persistentes. Vamos supor que uma página consista em um arquivo-base HTML c em dez im:tgens JPEG c que todos esses 11 objetos residam no mesmo servidor. Suponha t<~mbém que o URL para o arquivo-base HTTP seja

http: // www. someSc hool .edu/ s omeDepartment / home.index Eis o que

<~co mece:

1.

O processo cliente HTTP inicia uma conexão TCP para o scn•idor www. s orneSclloo 1 . edu na porta nli mcro 80, que to número de porta def:.ult p:.m o HTTP. Associados;) conexão TCP, havcrn urn sockct no cliente c um socket no s ervidor.

2.

O cliente liTfP en vl:t um:1 mensagem ele requisição 11n ·p ;lo servidor mravés ele se u sockct. Essa mensagem inclui o nome de Cilminho /someOepa rlme n llhome . i nd ex. (Discutiremos mensagens HTTP ma•s dctalhadamcnte logo adiante.)

3.

O processo servidor HTTP recebe a mensagem de rcquislç;\o atmv~s de seu soàct. extrai o objeto I some Oe partme nt / home . i nd ex de seu armazenamento (RAM ou disco), cncapsula o obJeto em uma mensagem de resposta HTTP c a cm•i::~ ao cliente atmvts de seu sockc:t.

4.

O processo servidor HTfP ordena ao TCP que encerre a concxt\o TCP. (M:JS, na realidade. o TCP só encermrá:. conexão quando liver certeza de q ue o cliente recebeu a mensagem de resposta intacta.)

5.

O cliente HTTP recebe a mensagem de res posta e a conexão TCP é cnccrmda. A mensagem indica que o objeto encapsulado é um arquivo HTML O cliente extrai o ::~rquivo da mensagem de resposta, analisa o arqurvo HTML e encontra referénci:JS aos dez objetos JPEG.

6.

As primeiras quatro etapas são repetidas para cada um dos objetos JPEG referenciados.


(omodo de

oplico~õo

75

A medida que recebe a págir1a Web, o browser a aprescot<\ <'O usuário. Dois browsers diferentes podem interpretar (isto é. exibir ao usu
1iciar onexao TCP ----,,..

Requisitar arquivo

ii•..,- }

Tempo para transmitir arquivo

Arquivo completamente

recebido Tempo no cliente

Tempo

no servidor

Figura 2.7 Cálculosimples poro o tempo ne

da conexão TCP. Essa rrquisiç:'lo/rcsposta HTTP caus;l mais um RTT. Assim. aproxunadamrmc, o tempo total de resposta s.<'o do1s RTTs mais o ttmpo de transmissão do arquivo HTML no servidor.

OHTIP com conexões persistentes Conexões não persistentes t~m algumas desvantagens. Em primeiro lugar, uma nO\'a conexão deve ser estabelecida c manlida para ccu/cr objeto solidtado. Para cada uma dessas conexões, dc,•em ser alocados buffrrs TCP c conscrv:tdas variáveis TCP tamo no cliente quanto no servidor. Isso pode sobrecarregar seriamente o servidor Web, que poderá est
Em conexões persistcmes, o servidor deixa a concx:'lo TCP abena após enviar resposl:l. Requis ições e respostas subscqucntes entre os mesmos cliente c servidor podem ser enviadas por melo da mesma conexão. Em particul:lr, uma página Web inteira ( no exemplo anterior, o arquivo-base HTML c as dez imagens) pode ser enviada mediante umn únic
2.2.3 Formato do mensagem HTIP As cs~cifkaçõts do HTTP (RFC 26161 definem os forma tos das mensagens HTTP. Há dois tipos de mensagens HTTP: de requisição c d e resposta. Ambas scr.lo discutidas a seguir.

Mensagem de requisição HTIP Apresen tamos a seguir uma mensagem de rcquisic,.'âo HITP Lip1ca:

G(T /somedir/page .html HTTP/1.1 Hosl: www.someschool .edu Connect1on : close

user agenL: Hozilla/4 .0 Accept · 1anguage: f r Podemos aprender bastante examin ando essa simples mensagem de requisição. Em primeiro lugar, vemos que ela c.s tá escrita em texto ASCil comum, de modo que pode ser lida por qualq uer um que conheça computadores. Em segundo lug

(amado de oplico sõo

n

Vamos agora exa minar as linhas de cabeçalho do exemplo. A linha de cabeçalho Hos t: www. some· sc hoo 1 . ed u específica o hospedeiro no qual o objeto reside. Talvez \'OC~ ache que ela é desnecessária. pois já existe uma conexão TCP para o hospedei ro. Mas. como veremos na Seç-.\o 2.2.5, a informação fornecida pela linha de cabeçalho do hospedeiro é requerida por am1azcnadorcs intcnncdiários da Wcb. Ao inclui r a linha de cabeçalho Connec t ion: c l ose. o browscr está dizendo ao servidor que não quer usar conexões persistentes; quer que o servidor feche a conexão após o envio do objeto requisitado. A linha de cabeçalho User· a genl: especifica o agente de usuario, IStO ê. o tipo d e browser que está fazendo a requistçào ao servidor. No caso em quest.à o, o agente de usuário é o Mozill:\14.0, u ll\ browser da etscape. Essa linha de cabe\ollho e utll porque. na verdade, o sen •idor pode em•iar versões diferent es do mesmo objeto a tipos diferentes de agentes de usuário. (Cada uma das versões é endereçada pelo mesmo URL) Po r fim. o cabeçalho Accep t · I a ng ua ge : mos tra que o usuário prefere receber uma versão em franc~ do objeto se esse objeto existir no servidor: se nilo exis tir, o servidor deve en vi:~r :1 vcrscçalho (c após :1 linha ndíc i on:~l com 'ca rriagc rcturn' c ·Une fccd '). h<\ um ·corpo de entidade'. O co rpo de enticl:1dc fica vazto com o método GET . mas é utili· zado co m o método POST. Um cliente HTTP normalmente usa o método POS I quando o usu(trio preenche um formu lário - por exemplo, quando fornece palavras de busca a um site buscado r. Com uma mensagem POST, o usu~rio con timta solicitando uma página Wcb ao sen•idor, mas o co ntc\ldo especifico dela depende do que o usuário escreveu nos campos do fomtulãrio. Se o valor d o campo de método for POST , então o corpo de entidade conterá o q ue o usuán o digitou nos campos do fom1ulário. Scrfamos omissos se não mencionássemos que uma requisição gerada com um formulán o não utiliza necessariamente o método POST. Ao contrário, formulários HTML frequentemente utilizam o método GET c incluem os dndos digttados (nos campos do fonnulário) no URL req uisilado. Por exemplo, se um fomltl lário us.1r o método GET, uvcr dois C'.unpos c as entradas desses dois e~mpos forem mon keys c bananas. então a estrutura do URL scr:1 www. somes i t e . com/ an i na 1se a rc h ?monkeys&banana s. Ao navegar normalmente pcl:1 Wcb, você provavelmente Já notou URLs ex tensos como esse.

O método HEAD é semelhante ao GET. Quando um servidor recebe uma requislçilo com o método H( AO. responde com uma mensagem HTTP. mas deixa de fora o objeto requisitado. Esse métod o é frequentemente usado pelos desenvolvedores de servidores liTf P p:mt depuração.

Linha de requisiç~o

Linhas de cab~alho

Linha em branco Corpo

da entidade Obs.: cr • carriage return; lf & line feed

Figura 2.8 Formato geral de uma mensagem de requisição

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r o;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

O mt10do PUT é frequentemente usado juntamente com ferramcnLas de edlç:'lo da Wcb. Permite que um usu-

ário carregue um objeto para um caminho especifico (diretório) em um serv1dor Wcb especifico. O método PUT também é usado por aphca~·ocs que precisam carregar objetos para servidores Web. O método OELETE permite que um usu;lrio. ou uma aplicaç-lo, elimine um objeto em um servidor Web.

Mensagemde resposta HTIP Apresentamos a seguir uma mensagem de resposta HTIP típica. Essa mensagem poderia ser a resposta ao exemplo de mensagem de requisit,'âo que acabamos de discutir. IHTP/ 1 . 1 200 OK Connectlon : c l ose Da te: Sat . 07 Ju l 2007 12:00:15 GMT Serve r: Apache/ 1. 3 . 0 (Un i x > La s t. -Hodifi ed: Sun. 6 Hay 2007 09:23:24 GMT Con t.ent - l e ngth: 6821 Cont ent· Type : t.ext/html (da t a dat.a da tcJ da t a da t a . .. > Vamos examinar cuídadosameme essa mensagem de resposta. Ela tem tr~s seçOCS: uma linha inídal ou Unha de estado, seis linhas de cabeçalho e, em seguida, o corpo da entidade, que ~ o 'fil é mignon· da mensagemcontém o objeto solicitado (representado por da ta da ta da t a da ta da l a ... ). A linha de estado tem três c-.unpos: o campo de vers:lo do protocolo, um código de estado c uma mensagem de estado correspondente. t-:esse exemplo. ela mostra <1ue o serv1dor está usando o HTIP/1.1 e que está tudo OK {1sto é, o serv1dor encontrou e está enviando o objeto solicitado). Agora, v;unos examinar as linhas de cabeçalho. O servidor usa a linha de cabeçalho Connect i on: cl o se para informar ao cliente que fechará a conexão TCP após en,iar a mensagem. A linha de cabe~ lho Da te : indica a hora e a data em que a resposta HTIP foi criada e enviada pelo servidor. Note que esse não é o horáno em que o objeto foi criado nem o de sua modificação mais recente: é a hora em que o servidor extraiu o objeto de seu sistema de arquivos. inseriu-o na mensagem de resposta c enviou-a. i\ linha de cabe('alho Ser ve r: mostra que a mensagem foi gerada por um servidor Web Apache, análoga u linh:1 de cabeçalho User · agen t: na mensagem de req111siçâo HTTl'. A linha de cabeçalho L<1st Mod i f ied : mdica a hora c a data em qlle o objeto foi criado OLt sofreu a liltima modificação. Esse cabeç:1lho. que logo estudaremos mais dctallmdamcntc, é fund:1mcntal para fazer enche do objeto, tanto no cliente local quanto crn servidores de cuthe da rede

(tarnbfm conhecidos corno servidores proxy). A linha de cabeçalho Conl ent -Leng lh : lndit--a o número de bytcs do objeto que está sendo enviado e a linha Content · Type : mostra qLte o objeto presente no corpo da mensagem é um texto IITML. (O tipo do objeto é oficialmente indicado pelo cabeçalho Conte n t · Type: e não pela extensão do arquivo.) Acabamos de ver um exemplo. Vamos agora examinar o formato geral de uma mensagem de resposta. ilus· trado na Figur:\ 2.9. Esse formato geral de mensagem de resposta condiz com o exemplo :mterior. Mas falemos um pouco mais sobre códigos de estado c suas frases, que indicam o resultado da rcquisi~-:lo. Eis alguns códigos de estado c frases associadas comuns: 200 OK: rcquisiç:'lo bem-sucedida c a infom1açJo é cmreguc com a resposta 301 Moved Perma nent ly : objeto requisitado foi removido permanentemente; novo URL é espccific.-ado no cabeçalho Loca t I on: da mensagem de resposta O software do chentc recuperará atllomaticamcntc o nO\'O URL. 400 Bad Reques t: código generico de erro que indica que a requts1ção não pôde ser entendida pelo servidor.


(amado de

oplico ~ õo

79

Linha de estado

Linhas de cabeçalho

l•nha em branco Corpo da entidade

Figura 2.9

Formolo ge~ol de umo mensagem de resposta

404 No t Found: o documento requisitado não existe no servidor. 505 IITT P Vers i on Not Supported :. a versão do protocolo IITTP requísitad:t n:lo é suponad:t pelo servidor. Voe~ gostaria de \•er uma mensagem de resposta HTTP real? É muito recomendável c muito fácil!

Primeiramente, d~ um comando Telnet em seu servidor Web favorito. Em seguida, digne uma mensagem de rcqliiSt\
GET /-ross/ HTTP/1 . 1 Host: c1s .poly. edu (Clique du:~s vezes a tecla 'cmcr' após digitar a última linha.) Essa sequ~ncia de comandos abre uma conex;\o TCP para a porta nt1mero 80 do hospedeiro c i s. po 1y. edu c. em seguida. envia a mensagem de requisiçi\o HTTP. Dever:\ aparecer uma mensagem de resposta que inclui o arquivo-base HTML da homcpage do professor Ross. Se voe~ preferir apenas ve r ns linhas da mensagem HTTP c não receber o objeto em s i. substhua GET por HEAO. Finalmente, substitua /- ros sI por /-b ana na I e \'eja que tipo d e mens;•gcm voce obtém. Nesta scç;\o, discutimos várias linhas de cabeçalho que podem ser usadas em mensagens de requisição e ele resposta IITTP. A especificaç)o do HTTP define muitas outras linhas ele cabeçalho que podem ser inseridas por browscrs, servidores Wcb c servidores cachc de redes. Vun os upcnas um pouco do total de linhas de cabeçalho. Exammarcmos mais algumas a seguir c mais um pouco quando discullrrnos armazenagem Web na Seção 2.2.5. Uma discussão muho abrangente c fácil de ler sobre o protocolo IITTP, seus cabcç:.~lhos c códigos de estado, pode ser cncont r:1da em !Krishnamuny. 200 lI : vcj:J também [Luoto ncn, l998) se estiver interessado no ponto de ' 'ista do desenvolvedor. Como um browser dec•dc quais li nhas de cabeçalho ser-Jo incl uídas em uma mensagem de rcquisiç;\o? Como um servidor Web decide quais linhas de cabeçalho serão mcluidas em u ma mensagem de resposta? Um browser vai gerar linhas de cabeçalho em função de seu tipo e versão (por e.xemplo, um browser HITP/1.0 não vai gerar nenhuma linha de cabeçalho LI ), da configuração do usuário para o browser (por exemplo, idioma preferido) c se o brO\\Ser tem uma versão do objeto possivelmente ultrapassada em sua memória. Scrv1dorcs Wcb se comportam de maneira semelhante: há diferentes produtos, versões e configurações, e todos infiucnciam as linhas de cabeçalho que são incluídas nas mensagens de resposta.

bow4tto4ic~ Redes de cora putod ores e o Inle;.rn;;.e;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

7.2.4 Interação usuário-servidor: cookies Mencionamos anteriormente que um servidor HTTP n11o tem estado, o que simplifica o projeto do senidor e ve m pcrmiundo que cngcnhctros desenvolvam servidores Web de alto desempenho que podem manipular milhares de concxOes TCP simultâneas. No ent;mto, é sempre bom que um sitc Wcb identifique usuários, seja porque o scrvtdor deseja restringir acesso de usuário. seja porque quer apresentar conteúdo em função da tdentidade do usuário. Para ess.1s Onalidadcs, o HTTP usa cookics. Cookies, definidos no RFC 2965. permitem que sitcs monitorem seus usuários. Hoje. a mmoria dos sites Web comerciais uuliza cookies. Como ilustrado na Figura 2. 10,:1 tecnologia dos cookics tem quatro componentes: ( l) uma linha de cabcÇlllho de cooki c na mensagem de rcspost.1 HTTP; (2) uma linha de cabeçalho de:- cookic na mensagem de rcquisiçao IITTP: (3) um arquivo de cookie mantido no sistema fina l do usuário c gerenciado pelo browscr do usmtr io: (4) um banco de dados de apoio no site Web. Utilizando a Figura 2. 10, ' 'amos esmiuçar um exemplo de como os cookics silo usados. Suponha q ue Susan , que sempre accss.1 a Wcb usando o lntemet Explorer de seu PC, acesse o Amazon.com pcl~1 primeiro ' 'eZ, c que, no passado, ela já tenha visitado o site d;:~ cl3a}'· Q uando a requis iç-lo ch ega ao sen •ldor Web da Amazon. de cri<~ um número de ideruiOt-açâo exclusivo e uma entrad:1 110 seu banco de dados de apoio, que~ indexado pelo número de iden tificação. Então. o servidor Wcb da 1\mnz.on rcs1wndc ao browser d e Susan. incluindo na resposta HTTP um cabeçalho Set · cook i e : q ue contem o m\mero de idcntirlcação. Por exemplo. a linha de cabeçalho poderia ser: Sel cook1e: 1678 Hospedeiro do client e

Hospedeiro do servido r

Ô-. ebay: 8734 -

O servidor cria 10 1678 para o usuário

Ôam.lzon: 1678 ebay: 8734

• : - Açao especifica : do cookie

Jma semana depols {

.

s...---·

amazon: 1678 ebay:8734

·:

Tempo Legenda:

Ô

Arquivo de cookie

Figura 2.1 O Montendo oestodo do usuário com cookies

Tempo

Açl'io especifica do cookie

acesso ..:..:..::.:.:...:_...

ô


(amado de

oplico~õo

81

Quando recebe a mensagem de resposta HTIP, o browser de Susan v~ o C'Jbeç;1lho Se t · cook í e : e, então, anexa uma linha ao arquivo especial de cookics que ele gcrencía. Essa linha inclui o nome de hospcdciro do servidor e seu número de identificação nesse cabeçalho. Observe que o arquivo de cookie já possui um entrada para o cBa)•. uma ''ez que Susan já visitou esse si te no passado. Toda vez que Susan requisita uma página Web enquanto navega pelo sltc da Amazon em questão, seu browscr consulta seu arquivo de cookies, extrai seu número de idemificaç;\o para esse sitc c insere na rcquisiç-.\o HTTP uma linha de cabeçalho de cookie que inclui o m\mero de identificação. Especifica me me. cada uma de suas requisições HTTP llO servidor do si te de comércio eletrônico mclui a linha de cabeçalho: Cookie: 1678 Dessa maneira, o servidor da Amazon pode monitorar a atividade de Susan c, embora não saib~ llCCessaria· mente que o nome dela é Susan, sabe exatamente quais páginas o usuário 1678 visitou, em que ord em c em que horáriosl Então, a Amazon pode utilizar cookies para o rerecer um serviço de t.":lrrinho de compra- a Amazon pode manter uma lista de tOágin::ts Wcb que ela visitou na Amazon anteriormente. Se ela tamb~m se rcgístmr no site- fornecendo seu nome completo, endereço de e-mail , endereço postal c informações de cartão de crédito - a Amazon pode incluir essas Informações em seu banco de dados c, assim, associar o nome ele Susan com seu nitmcro de idcntil'lcaç:\o (c com todas :1s páginas que ela consultou em suas visitas anteriore-s). ~ assim que a Amazon e outros sites de comércio eletrônico oferecem ~compras com um só clique· - quando quiser comprar um item durante uma v1sita subsequente, Susan não precisará d1gitar nova mente seu nome, número de seu cartão de crédito, nem endereço. Ess:1 d1seuss.\o nos mostrou que eookies podem ser usados para idenuficar um usuário. Quando visitar um sue pela pnme1ra vez. um usuário pode fornecer dados de 1demificaç.lo ( poss1vchnente seu nome). , o decorrer das sessões subscquentes, o browser passa um cabeçalho de cookic ao sen•1dor durante todas as viSit.'\5 subse· quentes ao si te. identificando. desse modo. o us uário ao servidor. A discuss.\o também deixou claro que cookies podem ser usados para criar uma camada de sessão de usuário sobre HTTP sem estado. Por exemplo, quando um usuário accssa uma aplicação de e-mail baseada na Web (como o l lotmail), o browser envia informações de cookie ao servidor que. por sua vez. identifica o us uário por meio da s~\o d o usuário com a aplicação. Embora cookies frequcmcmcme simplifiquem a experiência de compra pela In ternet, comín uam provocando muita controvérsia porque também podem ser consider-.ados corno invasão da privacidade de um usuário. Como acabamos de ver, usando uma combinação de cookics c informações de conta romecidas pelo usuário, u m sitc

Wcb pode O<::~ r sabendo muila <:oisa sobre esse usuário e. potencialmente, vender o que sabe para algum terceiro. O Cookic Central ICookie Central, 20081 inclui informações abrangentes sobre a controvérsia dos cooklcs.

2.2.5 Coches Web Um cache Web - também denominado servid or p rOl\.)'- é urna e ntidade ela rede que mendc requisições IIITP em nome de um sen•idor Web de origem. O cache Web tem seu próprio disco de arm azenagem e mantêm, dentro dele, cópias de objetos recentemente requisitados. Como ilustrado na Figum 2. Ll . o browser de um usuâ· rio pode ser configurado de modo que todas as su;IS requisições IITTP sejam dirig1d:u. primcíramente ao Gtehe Wcb. U mr~ vez que esteja configurado um browser, cada uma das req uisições de um objeto que o browscr faz é pnme1ramcnte dlflgida ao cachc Web. Como exemplo. suponha que u m browser estep requiSitando o obje1o http: //www . someschoo 1 . edu/campus. glf. Eis o que acontece:

1.

O brO\\Ser estabelece uma conexão TCP com o enche Web c envia a ele uma requisição HTTP para um objeto.

2.

O cachc Web verifica se tem uma cópia do objeto armazenada localmente. Se tive r, envia o objeto ao browser d o clieme, dentro de uma mensagem de resposta HTTP.

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....-

Cliente

Servidor de origem

Figura 2.1 1 Clientes tequisitondo objetos por meio de um come Web

3.

4.

Se n;Io tiver o objeto, o cache Wcb abre uma conexão TCP com o servidor de origem. isto é. com w•.·m. somes choo 1 . edu. EntUo. envia uma rcquisiÇ•lo HTIP do objeto paro a c.:oncx;\o TCP. Após receber essa rcq uisíçt\o, o servidor de origem envia o objeto ao <."ache Wcb, dentro de uma resposta HTTP. Quando recebe o objeto, o cache Web guarda uma cópia em seu am1azenamcnto loc11l c envia outra, dentro de um:. mens.•gem de resposlll. ao browser do cliente (pàt conexão TCP exi tente entre o browser do diente c o cache Wcb).

Note que um c:ache é, ao mesmo tempo. um servidor c um cliente. Quando recebe requisições de um browser c lhe envia respostas. é um servidor. Quando envia requisições para um servidor de ongcm c recebe respostas dele, t um chentc. Em geral. é um ISP que compra c instala um cachc \Vcb. Por exemplo, uma universidade poderia instalar um cachc n:1 rede de seu rwn1111S c configurar todos os browsers apontando para esse cachc. Ou um importante ISP rcsidcnc.al (como a AOL) poderia instalar um ou mais caches em sua rede c configurar antecipadamente os browsers que fornece apontando para os cachcs instalados. O a 1chc na Wcb tem sido utilizado amplamente na Internet por duas razões. Em primeiro lugar, um <.11che Wcb pode reduzir substancialmente o tempo de resposta para a rcqutsiç:lo de um dtente, em p~trlicular se o gargalo da largura de banda entre o cliente c o servidor de origem for muito menor do que aquele entre o cliente c o cache. Se hom•er uma conexão de ah::t velocidade entre o cliente e o cache, como em geral to caso, esc este ti,•er o objeto requisitado. então ele podem cmregar rapid::tmcnte o objeto ao cliente. Em segundo lugar, como logo ilustraremos com um exemplo, <."aches Web podem reduzir substancialmente o uMego no enlace de :~cesso de umn lnstht1i1,-:io qualquer à Internet. Com a redu1,·M do trMego, a instituição (por exemplo, uma empresa ou uma universidade) nao precisa ampliar su:1 largura de oonda tão rapidamemc, o que diminui os custos. Al~rn disso, <:aches Web podem reduzir substt~.nciahncnte o U"áfcgo na lntcrnet corno um todo. melhorando, assim, o desempenho pam todas llS nplic-açôcs. P..tra entender melhor os btnrflcios dos enches, vamos considerar um exemplo no contexto da Figura 2.12. Essa figura mostra duas redes: uma rede institucional e a Internet pública. A rede institucional~ urna I..AJ'I de alta vdocida· de. Um roteador da rede institucional c um roteador da lmemet estão Hgados por um enlace de 15 Mbps. Ossenidores de origem est:'lo todos ligados u Internet, mas locali!lldos pelo mundo todo. Suponha que o tamanho médio do objeto seja l MbtlS c que a taxa média de rcquisiç.lo dos browscrs d;\ insLitlli\"àO até os sen•idorcs de origem seja de 15 requisições por segundo. Imagine também que o tamanho das mensagens de rcquisi\

(amada de

aplico ~ õo

83

SeNidores de origem

Internet pública

LAN de 10 Mbp5

Rede inrtitucional

r19ura 2.12 Gorgolo enlle umo rede instih.Jcionol e olntemet O tempo de resposta total - isto ê. aquele mmseorrido entre a rcquis •ção de um objeto feita pelo browser e o recebimento dele- ê a soma do atraso da l.AN, do atraso de acesso (isto é, o atraso entre os dms roteadores) e do atraso da Internet. Vamos fazer agora um cálculo bastante rudimentar para esumar c.sse atraso. i\ imensidade de tráfego na l.AN (veja a Seção l.4 .2) é ( 15 req uisiç
(15 requisições/segundo) " ( 1 MbiLSircquisiç

Servidores de origem

.---..,

Internet pública

cache Rede institucional

institucional

ftgura 2.13 Adiçõo de um coche ôrede insti!IXW

ilncdi:u.tmcntc, digamos, em 10 milisscgundos. Mesmo assim. os demais 60 por cento das requisições ainda precisam ser atendidos pelos servidores de origem. Mas, com apenas 60 por cento dos objetos requisitados p-assando pelo enlace de acesso, a intensidade de I.J'árcgo neste diminui de 1,0 para 0,6. Em geral, uma intensidade de tr.lrcgo menor do que 0,8 corrcsponde a um atraso pequeno. digamos. dezenas de milisScgundos. no caso de um enlace de 15 :vtbps. Esse atraso é desprezível se comparado aos 2 segundos do atmso da Internet. Dadas essas considcraçOcs, o atraso médio é, por conseguinte, apenas lígdramentc maior do que l ,2 segundo. 0,4 . (0,01 segundo)+ 0,6. (2,01 segundos), Assim, essa segunda soluç:\o resulta em tempo de resposta até menor do que o que se conseguiria com a troca do enlace de acesso c n~o requer que a i.nstiluição atu:.lizc seu enlace .:om a Internet. Evidentemente, a institui<;fto tcr:I de comprar e instalar um cache Web. Mas esse custo é baixo - muitos cachcs usam softwares de domínio público que rodam em PCs baratos.

2.2.6 Gfl condicional Embora possa reduzir os tempos de resposta do pomo de vista do usu:\no, fazer cache imroduz um novo pro· blema- a cópia de um objeto existente no {

(omoda de

aplico~õo

85

GET /frult/klwi .gif HTTP/ 1.1 Host : www. exotlqueculsl ne .com Em segundo lugar. o servidor Web cn'·ia ao <:ache uma mensagem de resposta com o objeto requisit;tdo:

HTTP/1. 1 200 OK Date: Sa t. 7 Ju l 2007 15 :39 : 29 Server: Apache/1 .3 .0 (Unix> Last· Hodif l ed : Wed . 4 J ul 2007 09 : 23 : 24 Content· Type : image/gi f (data da t a data da t a da t a ... > O cadu: passa o objeto ao browscr requisitante, mas també-m o guarda em sua memória t-ache local. O irn ~r tamc é que ele tilmbém guardn. junuuncme com o objeto, a datn da uh ima modific::l(
GET / fru lt/ kiw l . gi f HTTP/ 1.1 1-tos t: www.exotiqueculsine . com l f·modl f led·stnce : Wed . 4 J ul 2007 09 :23 :24 Note que o valor da linha de cabeçalho lf· mod1f1ed·s1nce : é cx:uamcmc igual ao valor da linha de cabc1,-alho Las t Modi f i ed: que foi !!miada pelo servidor ha uma semana. Esse GET condicional esta dizendo ao servidor para enviar o objeto somente se ele ti,·er sido modificado desde a data cspcciOcada. Su~nha que o objeto não tenha sofndo modificação desde 4 Jul 2007 09:23:24. Então. em quarto lugar, o servidor Web envia urna rncns.1gern de rcs~:ota ao c;~chc:

HTTP/ 1. 1 304 Nol Modi f led Da t e : Sat . 14 Jul 2007 15: 39 : 29 Server: Apache/1 .3. 0 (Unix)
2.3 Transferência de arquivo: FTP Em uma sess.1o FTP tlpirn. o usuário. sentado à freme de um hospedeiro (o lornl}. quer transferir :~rquh•os

de ou para um hospedc1ro remoto. Para acessar a conta remota, o usuáno deve fornecer uma Jdcnuricaçào c um:1 senha. Após fornecer essas informações de autorizaç-J.o. pode ll':lnsferir arquivos do sistema local de arquivos para o sistema remoto c vice-versa. Como mostra a Figura 2. 14, o usuário mtcrage com o FTP por meio de um agente de usuário FTP. Em primeiro lugar, ele fornece o nome do hospedeiro remoto, o que faz com que o processo chente fTP do hospedeiro local estabeleça uma conexão TCP com o processo servtdor FTP do hospedeiro remoto. O usuário então rornece sua identificação e senha, que são enviadas pela conexão TCP como pane dos


lnttrl&<:t FTP do usu~rio

Ciente FTP

Transferên
Usuário ou hospedeiro

Sistema de arquivo remot o

Sistema de arquivo local

Figura 2.14

nP ltonSj)Orto arquivos enlte sistemas de arquivo local e temoto

com:~ndos

FTP. Assi m q LIC auto rizado pelo servidor, o usuMio copia um ma de arqu ivo local para o sisrcma de arqu ivo rem oro (ou vice-versa).

0 11

mais arqu ivos ilrmazcnaclos no siste-

O IITTP c o FTP solo prorocolos ele tmnsfcli!ncia de arquivos c t~m muitas c:~rac tcrfs t icas em comum; por exemplo, ambos u1ilizam o TCP. Contudo, esses dois protocolos de carnl1da de aplicaç~o têm algumas difcrencas imponamcs. A m:~is noulvel é que o FTP usa duas conexões TCP paralel:ts para transferir um arqui\•o: uma conexão d e cont role c uma conexão de da dos. A primeira é usada para erw il1r informações de con1role entre os dois hospederros- como Identificação de usuârio, senha, comandos para trocnr diretório remoto c comandos de 'inserir' c ' pegar' :trquivos. A conexão de dados é a usada para d etiva menlc cnvi:tr um arqui\'O. Como o FTP usa uma conex:lo de controle separada, dizemos que ele en\lla suas informações de controle fora da banda. No Capitulo 7. veremos que o protocolo RTSP, usado para conlro lar a transferência de meios contfnuos como áudio c vtdeo, wmbém envia suas informa~·ões de controle fora da banda. O HTTP. como você recorda. envia linhas de cubc\-albo de requlsiç;lo c de resposta Jl('la mesma conexão TCP que carrega o próprio arquivo transferido. Por essa raz.lo, dizemos que o IITTP envia suas infonnaçõcs de controle na banda. 'a próxuna seç;1o, veremos que o S~ITP , o principal protocolo para correio clctrõnico, também envia suas mformaçõcs de controle na banda. As conexões de com role c de dados do FTP esrão ilustradas na Figura 2. 15. Quando um usuário inicia uma sessão FTP com um hospedeiro remoto, o lado cliente do FTP ( usuário) inicm primeiramente uma conex:\o T CP de controle com o lado scr.11dor (hospedeiro re moto) na porta número 21 do servidor c cnvta por ess.1 conexão de controle a idcntificttC'.lO c a senha do usuário, alt'm de comandos para mudar o dircrório remoto. Quando o lado servidor recebe, pela conexão de controle, um comando para uma transferência de arqLtivo (de ou para o hospedeiro remoto), abre uma conex:'lo TCP de dados parn o lado cliente. O FfP cnviot exatamente um otrquivo pclot conexão d e dados c em scguíd:~ fecha-a. Se, du mntc a mes nm scss;lo, o usuário quiser ll'ansferir ouLro arqui vo, o F!P abrirá ouLra conexão de dados. Assi m, com FTP, a concx:lo de controle permanece t~be rtu durante toda a sess:\o do usu:irio, mas uma no'~' concx:lo de dados t crlilda para cada arquivo tmnsfcrido clcruro de uma sessão (Olt scj<~ , a concx;lo de d;~dos ~ não persistente). Dura me uma sessão, o servidor FTP deve manter informações de estado sobre o us uário. Em particular, o servidor deve associar a conexão de controle com uma conta de LISutirlo espccf0c-J c também deve monitorar o Conexão de controle TCP porta 21 Con@xllo d@ dados TCP porta 20 Cliente FTP

Figuro 2.1 S Conexões de conhole e de dodos

Servidor FTP


87

Camada de opli,osõo

diretório corrente do usu:trío enquanto este passeia pela árvore do diretório remoto. Moni torar essas informações de estado para cada s~lo de usuário em curso limita significativamente o numero tocai de sessões que o FTP pode manter simuh:mcamcntc. Lembre-se de que o HTTP, por outro lado, t sem estado- n:\o tem de monilorar o estado de nenhum us uário.

2.3.1

Comandos e respostas FTP

Enccrmrcmos esta scç:lo com uma breve discussão sobre alguns dos comandos mais comuns do FTP. Os comandos. do cllencc para o scrv1dor, c as respostas, do servidor pam o clicmc, s:\o e1wiados por meio da conexão de conlrolc no formato ASC II de 7 biLS. Assim. tal como comancl~ !IITP. comandos FTP també m podem ser lidos pelas pessoas. Para sepamr comandos sucessivos, um 'carrlagc rcturn· c um ' line fccd' encerram cada um deles. Cada co mando é constituído de qu:11ro caracteres t\SCII maiusculos. alguns com argumentos opcionais. Algu ns dos comandos mais comuns s:lo descritos a seguir:

USER username : us.1do

pam cnvi:~r idcntificaÇt'\o do usu:lrio :10 servidor.

PASS pa s SI~O rd: usado para enviar a senha do usuário ao servidor. LI ST : usado pam pedir ao servidor que envie uma lis ta co m todos os a rqut vos exis tem es no atual diretór io remoto. A list:~ de arquivos é enviada por meio de uma concxt\o de dados (nova c nt\o persisten te), c nt\o pela conex:\o TCP de cont ro le.

RET R fi 1e name : usado para extmir (isto é, obter) um arquivo do diretório atual do hospedeiro remolO. Auva o hospedetro remoto para que abm uma eoncx;lo de dados c envie o arqui vo requisi tad o por CSS1 conexão. STOR fi 1ename : usado para arm;ucnar (isto é, inseri r) um arquivo no diretório atual do hospedeiro remoto. Há, particularmente. uma correspond encia un ívoca entre o co mando que o usuário gera e o comando FTP enviado pela concx:'lo de comrole. Cada comando é seguido de uma resposta, que é en,iada do servidor ao cliente. As respostas S
331 Nome de us ua r1o OK . senha r eq u is itad a 125 Co ne xao de d ados j â abe rta : i ni ci ando trans f e r ê n c ia

425 uao é poss 1ve1 abrir a c o ne x~o 452 Err o ao esc r e ve r o arquivo

de

dados

Para saber mais sobre outros comandos<: respos tas FTP. o leitor irueressndo pode consultar o RFC 959.

2.4 Correio eletrônico no Internet O correio clctrOnico existe desde o inicio d a Internet. Era uma das apl k'lltões mais populares quando ela :linda estava na inr:lncia IScgaller. 19981. c ficou mais c mais elaborado c poderoso ao lo ngo dos anos. uma das aplica~õcs mais import:mtes e de maior uso da Internet.

e

Tal como o corre10 normal, o e-m:ul é um me10 de comunicac;:\o assmcro no - as pessoas enviam c recebem mensagens quando for convcni cm e para elas, sem ter ele estar coordenadas com o hor:trio das outros pessoas. Ao contrário do correio normal. que anda a passos lemos, o correio eletrônico t r:tpido. r:tcil de distribuir c barato. O correio eletrômco moderno tem muitas características poderosas. Utilizando lisLas de m~1la d1rcta. é possí'"d enviar mensagens d e c- mail, desejadas e indesejadas, a milhares de destinatários ao mesmo tempo. As mensagens do correio eletrô nico moderno muitas vezes incluem anexos, hiperlinks, textos rormatados em HTML e fotos.

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------'esta seç:\o, examinaremos os protocolos de camada de aplic1~·ào que estão no coraç;'lo do correio clctrõrtico da Internet. Mas. ames de entrarmos nessa discussão. vamos tomar uma vis.lo geral do sistema de correio da lmcrnct c de s.eus componentes principais. A figura 2. 16 apresenta uma 'is:'o do sistema de correio da Internet utihznndo uma analogia com a correspondência por correio. Vemos. por esse diagrama, que há uês componentes principais: agentes de usuário, servidores de correio c o SMTP. Descreveremos agora atda um desses componentes partindo do seguinte contexto: um remetente, Alice, está enviando uma mensagem de e-mml para um dcsunatáno. Bob. Agentes de usuános permitem que usuários leiam, respondam, rctransmitam, salvem e componham mensagens. (As vezes, agentes de usuário de corr·cio clctrOnico são dcnominndos leitores ,Jt correio, mas. neste livro. evitaremos css.1 cxpress:lo.) Quando Alice tcmlina de compor sua nH!ns.1gem, seu agente de usu:\rio a Cll\1a a seu servidor de correio, onde ela ~ colocada na fila de saida de mensagens desse servidor. Quando Bob quer ler uma mensagem, seu agente de usuário a extrai da ctix:a de correio em seu servidor de corrdo. No final da década de 1990, agentes de usu(•rio com intcrraces gráficas de usuário (GUI) se tomamm populares, pois permi!iam que usuários ''issem c compusessem mensagens rnuhimfdia. Atualmente, o Outlook da Microsoft. o Applc Mail c o Mozilln Thundcrbird são alguns elos agentes ele usuário com imcrfacc gmnca populares parn c-rnall. Também há muitos agcmcs de us m\rio clc texto de domínio público, (entre eles 'mail', 'pinc' c 'clm'), assim como interfaces base.idor de correio do destinatário, onde é deposi tada na caixa posral. Quando Bob quer acessar as mensagens de sua caixa postal, o servidor de correio
Servidor de correio

legend&; ~~ Fíla de mensagem ~~>.t:JJJJJJJJ.t.=bbtobbl de saída

l'iN Caixa de entrada biJ do usu~Jio

Figura 2.16 Umo visõo do sistema de e111oil do Internet em onologio com ocorrespondência por correio


(amado de oplicotõo

E111oil do Web Em dezembro de 1995, após alguns anos depois do •invenção• do Web, Sobeer Bhotio e Jock Smith fizeram umo visito o Oroper fisher Jurvetson, um investidor em empreendimentos de Internet, e propu~rom de$envolver um sistema de e-moil de livre oce$$0 bo~do no Web. A ideio era oferecer uma conto de e-moil grótis o quem quisesse e torna r essos contos acessíveis pelo Web. Em troco de 15 por cento do empresa, Oroper fisher Jurvetson financiou Bhotio e Smith, que formaram umo empresa denominado Hotmoil. Com tris funcionários em tempo in tegral e mais 12 o 14 em tempo porciol, que trobolhovom em troco de opções de compro de ações do empresa, eles conseguiram desenvolver e lonçor o serviço em julho de 1996. Um mês opôs o lançamen to, o Hotmoiltinho cem mil assinantes. Em dezembro de 1997, menos de 18 meses opós seu lançamen to, o Hotmoil, jó com mois de 12 milhões de ouinon tes, foi adquirido pelo Microsoft, oo que se saiba, por 400 milhões de dólares. O sucesso do Hotmoi l é muitos vezes a tribuído ova ntagem de elo ter sido o primeiro o entrar no mercado e oo inerente ' morketing virol' do e-moil. (Talvez alguns dos estudantes que estão lendo este livro estarão entre os novos empreendedores que conceberão e desenvolverão serviços de Internet pioneiros no mercado e com morketing virol). O e-moil do Web continuo o prosperar, tomando-se, o cedo ono, mo is sofisticado e potente. Um dos serviços mais populares de hoje é o gmoil do Google, que oferece livre armazenagem de gigobytes, filtro de spom e detector de viM ovonçodos, codificoçõo de emoil opcional (utilizando SSL). coletor de e-moils e umo interface orientado o busco. correio de Bob. Se o servidor de correio drla não puder ent regar a correspondência ao servidor drle, ma nterá a mensagem em uma de m ensagens c tentará U'3ns feri-la mms tarde. Em geral. novas tentati\':ls ser.lo feitas a oda 30 minutos aproximadamente: se não obti\'Cr sucesso após alguns d1as, o scrv1dor removerá a mensagem c notificará o remetente por meio de uma mensagem de correio. O SMTP é o prindpal protocolo de cam;lda de aplicação do correio eletrôn ico da Internet. Usa o sen •iço confián~l d e t ransfcr~ncia de dados d o TC P para transferi r mensagens do servido r de correio do remetente para o do dcstin:u ário. Corn o acontece com a maio ria dos protocolos d e camada de aplic;~Ç}o, o SMTP tem dois lados: um lado clieme. qu e funciom1 no servidor de co rreio d o remetente, c u m lado servidor, q ue funciona no servidor de correio do d estinatário. Ambos, o lado c liente c o lado servidor do SMTP, funcio nam em todos os scr"idores d e correio. Quando u m servid or de correio envia correspond Cncla para outros, age como um cliente SMTP. Quando o servido r de corrcao recebe correspo nd ência

ma

de outros, age como um servidor SMTP.

2.4.1

SMTP

O SMTP, definido 110 RFC 5321 , es tá no coração do correio eletrô nico da Internet. Como mencionamos ~mtes. esse protocolo transfere mensagens de se rvid ores d e corre io remetentes pam se rvidores d e co rreio dcstina t<\ rios. O SMTP é muito ma is antigo que o HrrP. (0 RFC o riginal d o SMTP d at:l de 1982, c ele já cxíslia muito ames disso.) Embora tenha inúmeras qualidades maravilhosas, como e\'id encia s ua ubaquidade na Internet, o SMTP I' uma tecnologia antiga que possuí cen as c;~rncterrsticas a rcaicas. Por exemplo, restringe o corpo (c nào apenas o c:•bcçalho) de todas as mensagens de correio ao simples formato ASCII de 7 bits. Ess~t restri ção tinha sent ido no começo da d écada de L980, quando a capac1dadc de trans nnssão era escassa c ninguém cnvaa\'a correio eletrônico com anexos volumosos nem arquivos grandes com imagens. áudio o u \'ldco. Mas. hoje em dja, na era da mult im!dia, a rcstri \'ãO do ASCll de 7 bits é um tanto incOmoda - exige que os dados binários d e multimídia sejam codificad os em ASCII ames de ser e1w iados pelo 5:-.tTP e que a mensagem correspondente em ASCII seja decodificada novamente para o sistema binário depois do U'3nsporte pelo SMTP. Lembre-se da Seção 2.2, na qual dissemos que o HTTP não exige que os dados de multimídia sejam codificados em ASC11 antes da transferência.

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....Para ilustra r essa operação básica do SMTP, vamos percorrer wn cenário comum. Suponha que Alice queira enviar a Sob uma s imples men~tgem ASCII: 1.

Ahc:c chama ~cu agente de usuário pam e-mail. rornccc o endereço de Bob (por exemplo. bOb@$Ome$Ciloo 1. edu). compõe uma mensagem e instrui o agente de usuário a enviar a mensagem.

2.

O agente de usuário de Alice envia a mensagem para seu servidor de correro . onde ela é colocada crn uma fila de mcns.-1gens.

3.

O lado cliente do SMTP. que funciona no servidor de correio de Alice, vc a mensagem na conexão ·rcPpara um servidor S:vtTP, que runciona no servidor de correio de Bob.

4.

Após alguns procedimentos iniciais de apresentaç-lo, o cliente SMT P cnvi:l a mensagem de Alice para dentro da conexão TCP.

5.

No servidor de correio de Bob, o lado servidor do SMTP recebe a mensagem c a coloca na m ixu postal dele.

6.

Bob chama seu agemc d e usu:\rio para ler a mensagem quando ro r mais con ven iente para ele.

ma c abre uma

Es.<;c c:cn:írio e-s tá resumido na Figura 2.17. .: impor1ame obse rvar que o SMTP normalmeme não usa servidores de correio intermediári os para enviar corrcspond~ nc i:r, mesmo CJuando os d ois se r"idorcs estão localizados em lados opos tos do mundo. Se o servido r de i\ Iice est:l em llong Ko ng, c o de Bob, em St. Louís, a conex;lo TCP é uma conexão direta ent re os servidores em Hong Kong c St. Louis. Em part k ular, se o servidor de correio de Bob não estiver em funcionamento, a menggem permanece no servidor de correio de Alice esperando por uma nova tentativa - a mensagem não é colocada em nenhum serv1dor de correiO mtemtcdi:irio. Vamos agora exami nar mais d e perto como o SMTP transfere u ma mensagem de um servidor de correio remetente para um servidor de correi o destinatário. Vere mos que o protocolo SMTP tem muitas semelhanças co m protocolos usados na intcraç-:\o humana cara a cara. Primeiramcm e, o clleme SMTP (que runclona no hospedei ro do sen•idor de correro reme teme) faz com que o TCP estabeleça uma conexão na porta 25 com o sen
Servidor dt correio de Bob

servldOi' Cl@ orreio de Allce Agente de Alice

i:K3)ID

0

Legenda:

~ f ila de mensagem

mrnru ru

Figura 2.17 Alice envio umo mensagem o Bob

0 SMTP

<:aixa C)OStal do usuário

~ bmj!lj

®

Agente deBob

~


(omoda de

aplico~õo

91

texto ASCII iniciadas com C: s\o exatamente as Linhas que o cliente erwia para dentro de seu sockct TCP c as inicíadas com S : s:lo exatamente as linhas que o servidor envia para dentro de seu socket TCP. A transcrição a seguir começa assim que a conexão TCP é estabelecida: S: C: S: C:

220 hambu r ge r. e du HELO crepes .fr 250 He11o c r e pes .rr. p1ea sed to me e t you HAIL FROM:

S: C: S: C: C: C:

250 alice@c repes . fr ... Sende r o k RCPT TO :
C: S: C: S:

250 Hessa ge a ccepted f o r de live r y OU ! T 22 1 hamburge r. edu c los lng co nnec ti on

S:

Nesse exemplo , o cliente enviou uma mensagem (•Do yo u 1 i ke ke l c hup? How abou t p i c k 1es ?~) do servidor de correio crepes . f r ao servidor de corrcío hamburge r. eelu. Como parte do diálogo, o cliente cmlliu cinco comandos: HELO (uma abre"iaçilo de HEUO), NAI L FROH, RCPT TO. DATA c OUI T. Esses comandos são ;unoexplicati\'OS. O cliente tambtrn enviou uma linha consistindo em um único ponto final . que indic.l o final da mens.1gcm para o servidor. (No jargào ASCII. cada mensagem termrna com CRL F .CRLF, onde CR significa ·carriagc retum' e Lf significa 'line feed') . O servidor emite respostas a cada comando, c cada resposta tem uma codificação de resposta c algumas explicações (opcionais) em inglês. Mencionamos aqur que o SMTP us.1 cone· xões pcrststcntes: se o servidor de correio remetente uver divcrs.1S mensagens para cnvmr ao mesmo servidor de correto destinatário. poderá enviar todas pela mesma conexãO TCP. Par.t cada mensagem, o cliente inicia o processo com um novo HAI L FROl~: crepes . f r , indica o final da mensagem com um ponto final isolado e emile QUIT somente após todas as mcns.1gcns terem sido enviadas. Recomendamos veementemente que você utilíze o Telnet para executar um dmlogo direto com um servidor SMTP. Para fazer Isso digite te1 ne t se r ver Name 25 em q ltC serv e rName é o nome de ltm sen•idor de correio local. Ao fuzer isso, voce est<\ simplesmente estu· bclecendo uma conex:\o TCP entre seu hospedeiro local e o servidor de correio. Após digita r ess;1 linha, você dcvcr:i receber imediatamente do servidor a respos ta 22.0. Digite, então, os corn:llldos HELO, MAl L FRON, RCPT TO. DATA, CRL r. CRLr c OUIT nos momentos apropriados. Também recomendamos veementemente que voe~ faça a Tarefa de Programaç-:to 2 no fln411 deste capiwlo. Nessa tarefa, vocC construirá um agente de usuário simples que implement41 o lado dientc óo SMTP. Esse agente permitirá que ' 'oce envie uma mensagem de e· mail a um destinatário qualquer, por meio de um servidor de correio local.

2.4.2 Comparação com o HTTP Agora, vamos fazer uma breve comparação entre o SMTP e o HTIP. Ambos os protocolos s:\o usados para transferir arquivos de um hospedeiro para outro. O HTTP transfere arquivos (também dcnommados objetos) de um servJdor Wcb para um cliente Web (nonnalmente um browscr). O SMTP transfere arqutvos (isto é. mellS:lgens de c·marl) de um sen·rdor de correio p-.ua outro. Ao transferir os arqurvos, o HTIP persistente c o SMTP usam conexões persistentes. Assim, os dois protocolos tem características em comum. Existem, todavia, diferenças importantes. A primeira é que o HTIP é, principalmente, um protocolo de recuperação de informações (pull


protocol)- alguém carrega informações em um servidor Web e os usuários utilizam o HTTP para recuperá-las do sen•idor quando qUiserem. Em particular, a conexão TCP é ativ-.1d;1 pela máquina que quer receber o arqui\•o. O SMTP. por sua vez, é, primordmlrncnte, um protocolo de envio de informações (push 11rotocol)- o servtdor de correio remetente cnvta o :~rquivo para o sen·idor de correio destinatário. Em particular, a conex:'lo TCP é ati\":tda pela máquina que quer enviar o arquivo. A segunda diferença, à qual aludimos anterionneme, é que o S:'.ITP exige que C1da mensagem, inclusi\·c o corpo. esteja no formato ASCII de 7 bits. Se a mensagem conth·er caracteres que não estejam nesse formato (por exemplo, e~rnctcrcs em bnc~s. com acento) ou dados binários (como um arquivo de imagem), ter:\ de ser codi· fietda em ASCII de 7 bits. Dados HTTP não impõem esta rcstri~\o. 1\ terceira diferença imponamr rcfrre-se ao modo como um documento que contém texto c imagem (juntamente com outros tipos posstveís de midia) é manipulado. Como vimos na Seçno 2.2, o IITTP encapsula <..-ada objeto em sua pró1>ria mensagem HTTP. O correio pela lntemet, como discutiremos com maiores detalhes mais adiante. colot-a todos os objetos de mensagem em um única mensagem.

2.4.3 Formatos de mensagem de mreio e MIME Quando Alice escreve utnõ1 carta a Bob e a envia pelo correio normal, ela pode incluir todos os tipos de lnfornuwoes pcriférlc;ts no c:~ beça lho da carta, como seu próprio cnderc~·o, o endereço de Bob c a data. De modo semclhamc, qua ndo uma mensagem de e-mail é enviada, um cabeçalho contendo luformaçõcs periférlets antecede o corpo da mensagem em si. Essas informações periféricas estão contidas em uma série de linhas de cabeçalho dcOnidas no RFC 5322. As linha de cabeçalho c o corpo da mensagem sao eparado por uma linha em branco (isto é. por CRLF). O RFC 5322 espcciOca o formato exato das linhas de cabeçalho das mensagens. bem como s uas interpretações sem:\nticas. Como acontece com o HTTP. toada ltnh~1 de cabeçalho contém um texto legtvel, consistindo em uma palavro-chave seguida de doãs.pontos c de um valor. Algumas palavras-chaves:: o obrigatórias e outras, opcionais. Cada cabeçalho deve te r uma linha de cabeçalho rrom: c uma To: c pode incluir também uma Subj e c t: bem como outras opcionais. É importante notar que essas ltnhas de cabeÇõJiho são tliftrenlts dos comandos SMTP que estudamos na Seção 2.-t.l {ainda que contenham algumas pala'TaS em comum. como 1rom' c 'to'). Os comandos daquela scç-lo faziam parte do protocolo de aprcscntaç;lo SMTP; a:. linhas de cabeçalho exa· minadas nesta seção fazem parte da própria mensagem de correio. Um cabeçalho de mensagem tlpieo é semelhante a: From: allceetrepes.fr l o: bobihamburger . edu SubJecl: Searching for the meaning of life. Após o cabeçalho da mensagem, vem uma linha em branco c;, em scgu id~t , o corpo da mensagem (em ASCll). Voei! pode usar o Telnet pam enviar a um scn'idor de correio uma mcns1lgcm que contenha algumas linhas de cabe· Çltlho, inclusive Svbjec l :. P;lm tal, utilize o comando te 1net serverName 25, como dlscutido na Scçtlo 2.4.1.

2.4.4 Protocolos de acesso oo correio Quando o SMTP entrega a mensagem do servidor de correio de Alice ao servidor de correio de Bob, ela é colocada na caixa postal de Sob. Durante toda essa discussão, ficou tacilamcnte s ubcmendrdo que Bob lc sua correspondi!ncia ao entrar no hospedeiro servidor c. ern seguida, executa o leitor de correio que roda naquela m:lquin:-t. Até o infcio da dé<.-ada de 1990. este era o modo padronizado de acess;u o correio. Mas hoje o acesso :to correto usa uma arquitetura cliente-servidor- o usuário upíco lc e·malls (Om um cliente que funciona em seu sistema final , por exemplo. um PC no escritório, um laptop ou um POA. Quando execmam um cliente de corrcío em PC local, usuários desfrutam de uma série de propriedades, inclusive a capacidade de ver mensagens c anexos muhimldia. Dado que Bob (o destinatário) executa seu agente de usuário em seu PC local, é natural que ele considere a instalação de um servidor de correio nessa máquina. Adotando essa abordagem, o servidor de correio de Alice



93

dialogaria diretamemc com o PC de Bob. Porém, há um problema com essa abordagem. Lembre-se de que um servidor de correio gcrcncm caixas postais c execma os lados cliente e servidor do SMTP. Se o servidor de correio de Bob residisse em seu PC local. este teria de frear sempre em funeionamemo c ligado na lmcmet para poder receber novas corrcspondeneias que poderiam chegar a qualquer hora, o que não é prático paro muitos usuários da Internet. Em \'CZ disso, um usuário típico executa um agente de usuMio no PC local, mas accssa sua caixa postal armazenada em um servidor de correio compartilhado que está sempre em funcionamento. Esse servidor de correio e compartilhado com outros usuários e, em geral, e manudo pelo ISP do usuário ( por exemplo, universidade ou empresa). Agora. vamos considerar o cami nho que uma mensagem percorre qu:mdo é enviada de Alice paro Bob. Acabamos de aprender que, em algum ponto ao longo do cnminho, :1 mensagem de e-ma li precisa ser depositada no servidor de correio de Boi>. Essa tarefa poderia ser realizada simplesmente fazendo com que o agente de usuá· rio de Alice enviasse :-. mens.1gem diretamerue ao sen'Ídor de correio de Bob, o que pode ser feito com o SMTPrealmente, o SMTP foi projetado para enviar e-rnail de um hospedeiro para outro. Contudo. normnlmeme o agente de usuário do remetente n<'O dialoga diretamente com o servidor de correio do destinatário. Em vez disso. como mostrn a Figura 2.18, o agente ele usuário de Alice usa SMTP p:1ra enviar a mensagem de e-m
POP3 O POP3 ~ u m protOcolo de acesso de correio extrem:unente simples. E dcflmdo no RFC 1939, que é curto e lx: m fácil de ler. Po•· esse protocolo ser tão simples, sua funcionalidade é bastante limi tada. O POP3 começa

Servidor de correio de 8ob

~orde

correio de Alke

l::t1lThJj

~lbJj SMTP

t1U1Hü

Figura 2.18 Protocolos de e-moil e suas entidades comunicontes

SMTP

[li!Jlllj

POP3, IMAP.ou HTTP

Agente deBob

~

bow4tto4ic~ Redes de computadores e a Inle ;.; rn;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

quando o agcmc de usuário (o cliente) abre uma conexão TCP com o servidor de correio (o servidor) na pona 110. Com a conexão TCP ativada, o protocolo passa por tr~ fases: autorizaç-.lo, trans.1çâo c atualizaç;lo. Durante a primeira fase, au tonzaç:\o, o agente de usuário envia um nome de us uário e uma senha (às clar.tS) para auten· ticar o usuário. !':a segunda fase. Lransaç;lo. recupct:l mens.1gens: é também nessa fase que o
A rase de aut oriz~tçt\o tem dois comandos principais: use r c pa s s . Para iluscrar esses dois comandos, s ugerimos c1uc ' 'oce realize uma sessão Telnet dircc:uncntc com um servidor POP3, usando a porta 110, c emita os dois comandos. Suponha que ma i I Serve r seja o nome de seu servidor de correio. O que voe~ ver:! será algo parecido com: telnet mailServer 110 POP3 server re~dy

~oK

user bob

+OK pass hungry ~OK

Se

voe~

user successfully logged on escrever um comando errado. o POP3 responderá com uma mensagem -ERR.

Agora, vamos examinar a rase de: trartSação. Um agente de usuário que utiliza POP3 frcquentememc pode ser configurado (pelo usuário) para ' ler-e-apagar· ou para ·ler-e-guardar'. A sequ~ncia de comandos emitida por um agente de usu:'lno POP3 depende do modo em que o agcnce de usuario csu vcr operando. No modo lcr·C·apagar, o agente de usuário emite: os co mandos 1 i s t, retr e de 1e. Como exemplo. s uponha que o usuário tenha duas mcnsagc•tS em sua caixa pose ai. No diálogo abaixo. C: (que represc:ma o diellle) é o agente de usuário e S: (que represenca o servidor). o sen1dor de: correio. A tran.saç.'o será mais ou menos assim: C: llst S: I 498 S : 2 912

s: C: retr 1

S: (blah bl ah S: ......... . ...... .

S: ... . ...... blah> S: c: de 1e 1

c:

retr 2

S: (blah blah

S: ................ . S: .......... blah)

S: C: dele 2 C: qui t

S: +OK POP3 server sign1ng off O agente de usuário primeiramente pede ao servidor de correio que apresente o tamanho de cada uma das mensagens armazenadas. Então, ele recupera e apaga cada mensagem do servidor. Note que, após a fase de



95

autorizaç;\o, o agem c de usuário empregou apenas quaLro comandos: 11 s t, retr. de 1 e c QU f t. A sintaxe para esses comandos é definida no RFC 1939. Depois de processar o comando de sarda (cjuír). o servidor POP3 entra na fase de atualização c remO\'C as mensagens 1 e 2 da caixa postal. Há um problema com o modo ler-c-apagar: o destinatário, Bob, pode ser nômade c querer acessar seu correio de muitas maquinas. por exemplo. do PC de seu escritório. do PC de s ua casa c de seu compuUidor portâLil. O modo lcr-e-ap:~gar rcp:~r1c as mensagens de correio de Bob cnli'C essas Ires máquinas: em particular, se ele ler primeiramente uma mensagem no PC de seu escritório, não poderá l~·la novamente mais tarde em seu computador portálll. No modo ler-c-guardar, o agente de usuário deixa as mensagens no servidor de correio após descarregá-las. Nesse caso. Bob pode reler mensagens em máquinas diferentes; pode acessar uma mensagem em seu local de trob:Jiho c, uma sem una depois, acessá-la no,-amente em casa. Durante uma sessão POP3 emre um agente de usuário e o servidor de correio, o servidor POP3 mamém alguma informaç.\o de estado: em particular, monilora as mensagens do usuário mar<.'Odas pam :tpagur. Contudo, não mamém informaç.\o de estado cntrc sessões POP3. Essa f.1.lta de informaçllo simpliflcrt ~' imt>lcmcnta\·âo de um servidor POP3.

IMAP Usando POP3, assim que baix:Jr suas mensagens na m;iquina local. 1\ob pode criar pastas de corrcspond~ncia c transferir as mcns;1gcns baix:tdas para e las. Em seguida, pode apagar as mensagens, mud à· las de pastas c pro· curar mensagens (por nome de remetente ou assunto). Mas esse paradigma - pastas e mensagens na máquina local -apresenta um problema para o usm\rio nômade que gostaria de rnantcr uma h ierarquia de pastas em um servidor remoto que poss.1 ser accss11do de qualquer computador: com o POP3, isso nlo t possfvel. Esse protocolo não prO\'~ nenhum meio para um usuário criar pastas remotas e designar mensagens a pastas. Para rcs oh•er esse c outros problemas, foi invemado o protocolo IMAP, definido no RFC 3SOl. Como o POP3. o IMAP t um protocolo de acesso a correio. porém co m mais recursos. mas t também significativamente mais complexo. ( E. I>Ortanto. também as implemcntacõcs dos lados cliente e servidor s.1o signillcath-amcnte mais complexas.) Um scMdor 1~1AP assoem cada mensagem a uma pasta. Quando urna mensagem chcg;t a um scrvtdor pela primeiro vez, é associada com a pasta INBOX do destinatário. que, emão. pode transferir a mensagem para uma nova pasta cmtda por ele, lê-la, apagá-la e assim por diante. O protocolo IMAP prov~ comandos que permitem que os usuarios criem pastas e transfiram mensagens de uma paro outra. O protocolo também pro"~ comandos que os tlSuários podem usar p.1m pesqttis:tr pastas remotas em buScrt de mensagens que obedeçam a critérios específicos. Note que. diferentemente do POP3, um servidor IMAP mamém informaç;\o de estado de usuário entre sessões IMAP- por exemplo , os nomes das pastas e quais mensagens estão assoc iadas a elas. 011 tra caructerfstka lmportmHc do IMAP é que ele tem comandos que permitem qtte um :tgclllc de usuário obtenh a componentes de mcnsagetlS. Por exemplo, um <~gente de ttSu:.lrio pode obter apeMs o cabeçalho ou soment e uma elas partes ele uma mensagem M1ME muhipartc. Essa caraclerfst it·a é ütil q uando há uma cone· xilo de largura de banda estreita cmrc o agente ele usuário e seu se rvidor de correto, como, por exemplo, uma cone.'Cào de modem se m fio ou de baixa velocidade. Com uma concx:\o de peque nu htrgura de band:1, o usuário pode decidir não baixar todas
E-moil pelo Web Hoje, um numero mda vez maior de usuários está enviando c acessando c-mails por meio de seus browsers Web. O llotmaillançou o c-mail com acesso ptla Wcb em mc.-ados da década de 1990; agora. esse tipo de acesso~ provido por pmucamcntc todos os s ites ISP, bem como universidades c empresas imponames. Com esse sef\'iço, o agente de usuário é um browser Wcb comum c o usuário se comunica com sua caixa postal remota via HTTP. Quando um destinatário, por exemplo, Bob, quer acessar uma mensagem em sua caixa postal, ela é enviada do servidor de correio para o browser de Bob usando o protocolo HTTP, e não os protocolos POP3 ouiMAP. Quando

bow4tto4ic~ Redes de co 11 pu tod ores e o In;.;l~e;.; rn ;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

um remetente, por exemplo, Alice, quer enviar uma mensagem de e-rnail. esta t enviada do browscr de Alice para seu servidor de correio por HTTP, c não por SMTP. O servidor de correio de Alice. contudo, ainda envia mensagens para outros servidores de correio e recebe mensagens de outros servidores de correio usando o SMTP.

2.5 DNS: o serviço de diretório da Internet '6s, seres humanos, podemos ser identificados por diversas maneiras. Por exemplo, podemos ser identificudos pelo nome que aparece em noss:\ certidão de nascimento. pelo numero do RG ou da curteiro de motorista. Embora cada um desses números possa ser usado para identil'icur pessoas. em um dado contexto u m pode ser mais adeqm1do que o utro. Por exemplo, os computadores da Receita Fedeml preferem usar o mímcro do CPF (de tama nho fixo) ao nome que consta em nossa certidão de nascimento. Por oulro lado, 1>essoas comuns prderem nosso nome de b:nismo, mais fác il de lembmr, ao número do CPF. (Realmen te, voe~ pode se rmaginar dizendo: ~o i , meu nome t 132-67-9875. Este é meu marido, 178-87-1 H6"?) Assim como seres humanos pode m ser idem ificados de mu itas manei ras, exatamente o mesmo aco ntece com hospedeiros da In ternet. Um identificador é seu nome de hosp edeiro (hosr namc) . No mes de hospedeirocomo c nn . com, www .ya hoo . com. ga I a. c s. umas s . edu e c i s. po 1y. edu - s:\o fáceis de lembrar e, p<>rtanto, apreciados pelos seres humanos. Todavia, eles fornecem poucu, se t que alguma, info rm:wl\o sobre a localização de um hospedeiro na Internet. (Um nome como www. e ur ecom . f r. que termina com o código do pais . f r , nos informa que o hospedei ro provavelmente está na França, mas não diz muito mais do que Isso.) Altm disso, como nomes de hospedeiros podem consistir em 01racteres alfanumcricos de comprimento variável , seriam diffecis de ser pr0 IP. Disculiremos endereços IP m;\is dcta1hadamente no C:tpftulo 4 , mas é importante falar um pouco sobre eles agom. Um endereço IP é constituído de 4 bytcs c sua estrutura hierárquica é rfgidmo separo um dos bytes expressos em notaç;lo decimal de Oa 255. Um endereço JP e hicr:irqutco porque, ao examiná-lo da esquerda para a d ireita. obtemos gradativamente mais informações cspecrficus sobre onde o hospedeiro está localizado na Internet (isto é, em qual rede, dentre as muitas que compõem a Internet). De maneiro semelhante. quando examinamos um endereço postal de erma para barxo, obtemos inform:u;ões cada vez mais especrlicas sobre a localizaç:lo do desunatárro.

2.5.1 Serviços fornecidos pelo DNS Acabamos de ver q ue há d uas maneiras de identificar um hospedeiro- por um nome de hospedeiro c por um endereço IP. As peS~>oas preferem o idcnlificador nome de hospedeiro por ser mais ft\ci l de Jcmbror, ao passo que roteadores preferem endereços IP ele comprimento l'ixo e estrutur:tdos hicmrqurçamen tc. Par., conciliar essas prefer~ndas, é 11ecessário um scr\'iço de diretório que tmduza nomes de hospedeiro paro c 11de reços IP. Esta é a tarefa pri nci pal do OtiS (tlonwin na mr sys rem- sistem a de n omes de d omtn io) da Internet. O DNS é ( 1} um banco de d:1dos dist ribu!do implementado em uma hierarquia de ser v i do r es d e nome (servidores DNS), e (2) um pro tocolo de cmnncla de aplicaç;\o que permi1e que hospedeiros consultem o ba r~co de d:~dos distribuido. Os servidores de no me silo frequentemente máquinas UNIX que executam o software BlND (Bcrkcley Internet Namc Domain) IBJNO. 2009 1. O protocolo ONS uliliz."l UD P c usa a pona 53. O ONS é comumente empregado por outros entidades da camada de aplicaç;\o- inclusive HITP, SMTP e FTP- p:tra traduzir nomes de hospedeiros fornecidos por usuários pa ra endereços IP. Como exemplo, considere o que :~comece quando um browser ( isto é, um cliente HTTP). q ue execu ta na máquina de algum usu:lno, requiSila o URL www. someschool . edu /i ndex . ht ml. Paro que a máq uina do usuárro possa en\'iar uma mensagem de rcquisiç;lo HTTP ao servidor Web ww•lf . someschoo 1 . edu, ela precisa primeiramente obter o endereço IP de www. someschoo 1 . ed u. Isso é feito da segui me mau eira: I . A própna máqurna do usuário execu1a o lado cliente da aplrcaç;lo ONS. 2.

O browser extrai o nome de hospedeiro, cliente da aplicação DNS.

11w11. someschoo 1 . edu,

do URL c passa o nome paro o lado


(amad a de aplicasõo

97

3.

O cliente DNS envia uma consulta com endo o nome do hospedeiro para um servidor DNS.

4.

O cliente DNS finalmente recebe uma resposta, que incluí o endereço IP corrcspondeme ao nome de hospedeiro.

5.

Táo logo o browscr receba o endereço do ONS, pode abrir uma conexão TCP com o processo servidor HTTP locahzado naquele endereço IP.

Vemos, por esse exemplo, que o 0 :-/S adiciona mais um atraso- às vezes substancial- às aplicações de Internet que o usam. Felizmente, como discutiremos mais adiante. o endereço IP procurado rrequcntemcnte est;\ no enche de um ser"idor DNS 'próximo'. o que ajuda a reduzir o tráfego DNS na rede, bem como o atraso médio do DNS. O DNS prove alguns omros serviços importantes além da traduçao de nomes de hospedeiro p:u•J endereços IP: Apelidos de hosp edeiro. Um hospedeiro com nome complicado pode ter um ou mais ape lidos. Um nome como re l ay l. wes t -coa s t . e nterpri se . com pode ter, por exemplo, dois apelidos, como en t e rp ri se . com e www. en t e rpri se . com. Nesse caso. o nome de hospedeiro r e l ay l. west ·coas t. en t e rp,·1 se . com é deno mi nado no me canônico. Apelidos , quando existem, sM em geral mais fáceis de lembrar do q ue o nome canônico. O DNS pode ser cha mado por uma a ll lic:wão para obter o nome canônico correspondente :1 um apelido fornecido, bem como para obter o endereço IP do hospedeiro. Apelidos de servidor de correio. Por razões óbvias, ê adcqu;~do que endereços de c-mail sejam fáceis de lembrar. Por exemplo, se Bob tem u m;t conta no Holm:lil , seu endereço de c-mail pode ser simplesmente bob@llo t ma 11 . com. Contudo, o nome de hospedeiro do servidor do llouuail é mais compli.cndo c multo mais di frei I de lembrar do que simplcsmeme ho tma í 1 . com (por exemplo, o nome canOnico pode ser algo parecido com re1ay l.wes t ·coas t.llo t ma i l . com). O DNS pode ser ch:un:\do por uma aplicaç-Jo de correto parJ obter o nome e~nOnico a partir de um apelido fornecido. bem como o endereço I P do hospedeiro. Na verd:1de. o rcgisLro M.X (veja :ldt:uuc) permite que o servidor de correio c o servidor \Vcb de uma empresa tenham nomes (apelidos) id~nticos; por exemplo, o servidor Web e o servidor de correio de uma empresa podem a mbos ser denominados ente r prí se . com. Distribuição de ca rga . O DNS também é usado para realiz:tr dtstribul~':lo de carga entre scr\'idorcs replicados, tais como os servidores Web replicados. Sitcs mov tmcntados como c nn . com são replicados em '':\rios servidores, sendo que cada servidor roda em um sistema final diferente c tem um endereço IP diferente. Assim, no caso de sen•idorcs Wcb replicados, um COIIJUIIIO de endereços IP fica associado a um untco nome cnnOnieo e contido no ooneo de dados do DNS. Quando clientes consultam um nome mapeado pamum conjunto de endereços. o DNS responde com o conjunto inteiro de endereços IP. mas faz um rodízio da ordem dos Ctldereços dentro de cada resposta. Como lllll cliente normalmcm c envia sua mensagem de requisição HTTP ao endereço IP que ocupa o primeiro lugar no conjumo, o rodiz io

DNS: funções decisivos de rede via porodigmo dient~rservidor Como os protocolos HTTP, FTP e SMTP, o DNS é um protocolo do comodo de oplicoçõo, jó que (1) rodo e ntre sislemos finois comunic:ontes usando o porodigmo diante-servidor e (2) depende de um protocolo de transporte fim o fim subjacente poro transferir mensogeos ONS entre sistemos finois comunicontes. Em outro sentido, conludo, o popel do DNS é bostonte diferente dos oplicoçÕGs Web, do tronsferõncio de orquivo e do e-moil. Oiferentemenle dessos aplicações, o ONS não é uma aplicação com o qual o usuário interoge diretamente. Em vez disso, fornece uma função interno do Internet - o saber, o lroduçõo de nomes de hospedeiro poro seus endereços IP subjacentes, poro oplicoções de usuário e oulros softwares do Internet. Notamos, no Seção 1.2, que muito do complexídode do orquiteturo do Internet está locolizodo no 'periferia' do rede. O DNS, que implemento o processo cn~eiol de troduçõo de nome poro endereço usondo clientes e servidores locolizodos nos bordos do rede, é mais um exemplo desso filosofia de projeto.

bow4tto4ic~ Redes de co 11 putod ores e o In~l~e;.; rn ;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

ele DNS distribui o tráfego entre os senridorcs repUcados. O rodfzio de DNS também ~ usado para e-mail, de modo que vários servidores de correio podem ter o mesmo apelido. Recentemente. empresas drstribuidoras de conteudo como a Akamai (Akarnai. 20091 passaram a usar o D~S de maneira mais sofistic:~da para prover dis tribuiç.\o de conteúdo na Wcb (veja Capitulo 7). O DNS cst.1 cspecilic:~do no RFC 1034 e no RFC 1035 c atualizado em diversos RFCs adicionais. É um sistema complexo e. neste livro. apenas rnencionamos os aspec tos fundamentais de sun operaç:'lo. O leitor interessado pode consul tar os RFCs chados. o livro escrito por Abnz e uu (Abitz, 19931 c também o artigo de IMockapctris, 19881. que nprcscmn uma retrospectiva c uma ótima descriç:lo do que e do porqu~ do DNS. e (Mockapetris, 20051 .

2.5.2 Visão geral do modo de funtdos centralizado em um unico sen•idor DNS simplesmente não é cscalável. Consequentemente, o DNS é distribmdo por conceito de projeto. Na verdade, ele é um ótimo exemplo de como um banco de dados dis tribuído pode ser implementado na Internet.

Um banco de dados distribuído, hierárquico Para tratar da questão da escala, o DNS usa um grande número de servidores, organizados de maneira hierárquica e distribuídos por todo o mundo. Nenhum servidor de nomes isolado tem todos os mapeamentos para



99

todos os hospedeiros ela Internet. Em vez disso, os mapeamentos são distribuídos pelos servidores de nomes. Como uma primeira aproxirnaç-.lo. há tr~ classes de servidores de nomes: servidores de nomes raiz, servidores DNS de domínio de alto nível (top-levtl clonwin - TlD) c servidores O. S com autondade - organizados em uma hierarquia. como mostra a Figura 2.19. Para entender como essas trfs classes de sel'"\•idores imcragcm, suponha que um cliente DNS queira determinar o endereço IP para o nome de hospedeiro www. amCJ zon. com. Como uma primeira aproximaç;lo, ocorrer.lo os seguintes eventos. Em pnmctro lugar, o chente contatam um dos servtdores raiz, que retornará endereços IP dos sel"ridores TLD para o dommio de alto nível com. Enlào, o cliente cont:Ham um desses sel"•idores TlD, que retomará o endereço IP de um servidor com llutoridadc para ama zon. com. Finalmente. o cliente contatará um dos servidores com autoridade para amazon.com, que retornam o endereço IP para o nome de hos1>edeiro wv.•w. amazon. com. Mais adiante, analisaremos mais detalhadamentc esse processo de consulta DNS. Mas. em primeiro lugar, vamos examinar mais de perto as tres classes de servidores DNS. Servidores de nomes raiz. Na Internet h;l l3 servidores de nomes raiz (denominados de A a M) c a maior parte deles está localizada na Amérlca do Norte. Um mapa de servidores de nomes raiz de outubro de 2006 é mostrado na Figura 2.20: uma lista dos servidores ele nomes miz existentes hoje está disponível em [RooL·scrvers, 2009[. Embora tenhamos nos referido a cacl:1 um dos 13 servidores de nomes raiz corno se rossem um servidor único, na realidade. cada um~ um conglomerado de servidores replk"dos. para fins de segurança c confiabilicladc. Scrvidotcs de nomes de Dominio de Alto Nivel (TLD). Esses servidores s;\o responsáveis por domínios de alto nh•el como com, org, nrl, edu e gov, e p<>r todos os domínios de alto nível de países, tais como ull./r . Ctl cJr>.Aempresa Network SohtLions m:tntinha os servidores TLD pam o domfnio de alto mvcl com e a empresa EducaiiSC mantinha os scl"•idorcs para o domlnio de alto nível rdu. Servidores de nomes com a utoridade. Toda organizaç;\o que tiver hospedeiros que possam ser acess:~dos publicamente na Internet (como servidores Web e servidores de correio) deve fornecer registros D 'S tambcm accsstveis publicamente que mapeiem os nomes desses hospedeiros para endereços IP. Um servidor DNS com autoridade de uma organizaç.lo abriga esses registros. Uma org(lnizaç.\o pode preferir implementar seu próprio sel'"\•idor DNS com autoridade para abrigar esses registros ou. como alternativa, pode p:tgar para annazená-los em um servidor DNS com autondade de algum provedor de servtço. A maioria das universidades c empresas de grande porte unplementam e manttm seus próprios servidores DNS primário c secundário (backup) com autoridade. Os sel'"\•idores de nomes raiz, TLD c com autoridade pencncem à hierarquia de servidores DNS, como mostra a Figura 2.19. H:t um outro tipo importante de DNS, denominado servidor DNS local. que nao pcnence, estritamellle, :\ hierarquia de servidores, mas, mesmo assim, é central para a arquitetura DNS.

Cada ISP - como o de uma universidade, de um departamento acadCmico, de uma empresa ou de uma rcsid~nc ia

- tem um scn•idor de nomes local (também denominado servidor de nomes dcraull). Quando um hospedeiro se conccla com um ISP, o ISP fornece ao hospedeiro os endereços lP de um ou mais ele seus servidores

servidor~

servidor~

servidores DNS yahoo.com

DNS com

servidores DNS amazon.com

Figura 2.19 Porte do hierarquia de servidores DNSs

DNS raiz

servidores DNS org

servidores DNS pbs.org

servidores DNS edu

servidores DNS poly.edu

servidores DNS umass.edu

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------de nomes locais ( normalmcmc por DHCP, que será discutido no Capftulo 4). Determinar o endereço IP do seu sen•idor de nomes local é fácil: basta acessar as janelas de estado da red e no Wi ndo,,s o u UNIX. O servidor de no mes local de um hospedeiro normalmente está 'próximo' dele. No caso de um ISP ms titucional, pode estar na mesma IJ\1': do hospedeiro; já no caso de um ISP residencial, em gemi o scn•idor de nomes está scpamdo do hospedeiro por não mais do que alguns roteadores. Quando um hospedeiro faz urna consulta ao DNS, ela é enviada ao scrv1dor de nomes local, que age como proxy e a rctmns mite para a hierarquia do scn•idor DNS, como discuuremos mais detalhadamente a seguir. Vamos cxmninar um exemplo simples. Suponha que o hospedeiro c I s . po 1y. edu deseje o endereço IP de ga I a. cs. uma ss . edu. Suponha também q ue o servidor de nomes local da Polytechnic seja denominado dns. po1y . edu c que um scn•idor de nomes com autoridade para ga i a .cs. umass. edu seja denominado dns. umass . edu. Como mostra :1 Figum 2.2 1, o hospedeiro c i s. po 1y . edu primcimmentc envia uma mens:~gem de consult:1 DNS a seu servidor de nomes local dn s . po 1y. edu. Ess.-. mensagem comém o nome de hos pedeiro a ser tmd uzido, isto é, ga i a. c s. uma ss . edu. O scn ridor de no mes local transmite a mens..1gem de consulta a um servidor de nomes mlz, que percebe o sufixo cdu c rcto rn:• :10 servidor de nomes local uma lista de endereços IP contendo ser,•ido rcs TLO res ponsáveis 1>0 r edu. Entào, o sen•idor de nomes loc:1l retransmilc a mensagem de ~onsu l to a um desses servidores TLD que, por s ua vez, percebe o sufixo umass. edu c responde com o endereço IP do servidor de nomes com autoridade para a Universit)' o f Massachuseus, a s:1ber, dns. uma s s . edu. Finalmen Lc, o servido r de nomes lo<::~ I reenvia a mensagem de cons ulta diretamente a dns . uma ss. edu, que responde com o endereço lP de ga I a. cs . umas s . edu. Note que, nesse exemplo. para poder obter o mapeamento pam um unico no me de hospedeiro, fomm c1wi;~das oito mensagens DNS: quatro mcnS
;~. Verísígn, Duttes, VA c. Cogent, Herndon, VA (também Los Angeles) d. U Maryland College Park, MO g. US DoD Vienna, VA e. NASA Mt Vlew, CA ~· ARL Aberdeen. ~O f. Internet Software c. Verlsi n (11 localizações) Pato Alto, CA -1. Aut onomka, Estocolmo (e outras 36 localizações) (mais 28 outras IO
7·

r:;;......._

I

Figura 2.20 SetvidDres DNS raizem 2009 (nome, organização, localização)



101

Servidor de nomes rait

.----..,

0 0

® SENidor de nomes local dns.poly . edu

0

--+ Servidor de nomes no

0@ Servidor de nomes com autoridade gaia.cs . umass.edu Hospedeiro requisitante cis.poly .edu dns.cs.u~ass.edu

figura

2.21

lnleroçõo de vórios seiVidOfes OIIS

autoridade. que retornará o mapeamento desejado para o servidor de nomes local c que, por sua vez. o repassará ao hospedctro rcqutsitantc. Nesse caso. scrio enviadas dez mensagens DNS no to tal! O exemplo mostrado 11:1 Fig\tra 2.21 usa consuhas recursivas e consuhas Iterativas. A consulta enviada de c1 s. po 1y . edu parn dns. po l y. edu é recursiva, visto que pede a dn s. po 1y. edu que obtenha o mapeamento em seu nome. Mas as u~s consul tas subscquentes s.\o iterativas, visto que todas as respostas s.lo retorn:~das d iretamente a dns. po1 y. edu. Tcoricamcnlc, qualquer consulta DNS pode ser itcratl\•a ou recursiva. Por exemplo, a Figura 2.22 mos trn uma cadeia de consultas DNS na qmtl todas elas Silo rccur:.ivas. Na prática, as consultas normalmente seguem o pad n\o mostmdo na Figura 2.21: a consulta do hospedeiro rcquisit:tnte :10 servidor de nomes local é recursiva c todas as outras são iterativas.

Coche DNS Até ttqui, nossa discussão ignorou o cache DNS, uma c:mu;Lcrlstica muito importante do sistema DNS. Na realidade, o DNS cxplom extcnsi\'llmeme o cache para melhorar o desempenho quanto ao atraso e reduzir o nú mero de mensagens ONS que ricocheteia pela Internet. A ide ia q ue está por trás do enche ONS é muito simples. Em uma cadeia de consultas, quando um servidor de nomes recebe uma resposta DNS (contendo, por exemplo, o mapeamento de um nome de hospedeiro para um endereço lP), ele pode fazer cache das i11formaçõcs da resposta em sua memória locóll. Por exemplo, na Figura 2.21, toda vez que o servidor de nomes local dns. po 1y. edu recebe uma resposta de algum servidor DNS. pode fazer ~-ache de qualquer informação contida na resposta. Se um par nome de hospedeiro/endereço IP estiver no cache ele um servidor DNS c outra consulta chegar ao mesmo servtdor para o mesmo nome de máquina, o servidor de nomes poderá fo rnecer o endereço IP desejado, mesmo que não tenha autoridade para esse nome. Como hospedeiros c mapeamentos entre hospedeiros c endereços IP não são, de modo algum, permanentes, após um período ele tempo ( frequentemente dois d ias), os servidores DNS descartam as infom1ações armazenadas em seus caches.

bow4tto4ic~ Redes de com pulod ores e o Inle;.; r n;.;e;.;.l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Servidor de nomes raiz

0 0 Strvidor de nomes local

dns.poly.eclu

0

Servidor de nomes TLD

® ®

0

Servidor de nomes
Hospedeiro requisitante

cls.poly.edu

dns.cs.umass.edu

gala.cs.u•ass.edu

figura 2.22 Consultas reooiws em DNS Como exemplo, tmagine que um hospedeiro aprl cot. po 1y . edu consulte dns. pol y. edu para o endereço IP da máqmna cnn. com. Al~m disso, suponha que algumas horas mais tarde out.ra máquina da Polytechnic Univcrsily. digamos. ldwi . pol y. f r também consulte dns. po 1y. edu para o mesmo nome de hospedeiro. Por <.-ausa d o cache, o servidor local poderá imediatamente retomar o endereço IP de cnn. com a esse segundo hos· pcdciro requis ilante. sem ter de consultar quaisquer outros servidores o, S. Um servidor de nomes local também pode fazer enche de endereços IP de servidores TLD, permitindo, as..~í m , que servidores de nomes locais evitem os servidores de nomes raiz em uma cadeia de consuhas (isso acontece frequentemente).

2.S.3 Registros e mensagens ONS Os servidores de nomes que juntos implementam o banco de dados distribuído do DNS armazenam registros de recursos (RR) que fornecem mapeamemos de nomes de hospedeiros para endereços 1?. Cada mensagem de resposta DNS carreg:~ um ou mais registros de recursos. Nrst:\ seçâo e na subscqucnte, aprcsentnl'emos uma breve vis:lo geral dos registros de recursos e mensagens DNS. Para mais deta lhes. consulte IAbitz, 1993] ou [RFC 103-+; RFC 1035] . Um registro de recurso é uma tupla ele quatro elementos que com êm os seguintes campos:
Se Type A, emao tia me é um nome de hospedeiro e Va 1ue é o ende reço IP para o nome de hospedeiro. Assim, um registro Type A fornece o mapearnemo padrão de nomes hospedctros para endereços IP. Como exemplo, (rel ayl . bar. foo . com . 145 . 37 .93 .1 26 . A) é um regis tro com Type igual a A.



103

Se Type-NS, então r• ame é um dom[nio (como foo. com) c va lu e é o nome de um servidor de nomes com amondade que sabe como obter os endereços IP para hospedeirOS do domínio. Esse registro é usado p:~ra cnc:unmhar consultas DNS ao longo da cadeia de consultas. Como exemplo, (foo.com . dns. f oo . com . tiS) é um registro com Typc igual a NS. Se Type•C NAH[. cnt:lo Va 1 ue é um nome canônico de hospedeiro paro o apelido de hospedeiro contido em Na me. Esse registro pode fornecer aos hospede1ros consultantes o nome canônico correspondente a um apelido de hospedc1ro. Como exemplo. (foo. com, r e 1ay l. bar. foo. com , CNAHE) é um registro CNAME. Se Type-MX, então Value é o nome canônico de um servidor de correio cujo apelido de hospedeiro esta contido em Name. Como exemplo, (foo.com . ma i 1.bar . f oo.com . MX) é um rt'gistro MX. Registros MX permitem que os nomes de hospedeiros de servidores de correio tenham apelidos simples. Note que us:~ndo o registro MX. uma empresa pode ter o mesmo apelido pam seu servidor de arquivo c par-a um dc seus o utros servidores (tal como seu sen
Mensagens ONS ;\bordamos :ulteriormente nesta seç:lo mensagens de consulta e de resposta DNS, que são as duas ünicas espécies de mensagem DNS. Além disso, tanto as mensagens de consulta como as de resposta t~m o mesmo formato, como mostra a Figuro 2.23. A semilntica dos \'ârios campos de uma mensagem DNS é a seguinte: Os primeiros 12 bytes formam a scçclo ele cabeçcrllto. que tem '~írios campos. O primeiro campo é um numero de 16 bits que identifica a consulta. Esse identificador~ copiado pam a mensagem de resposta a uma consulta, permitindo que o cliente combine respostas recebidas com consultas enviadas. Há várias Oags no c:mtpo de Oag. Uma Oag de consulta/resposta de I bit indica se a mensagem é uma consulta (O) ou uma respost;l (l). Uma Oag de autoridade de l bit é rn:m:ada em uma mensagem de resposta quando o servidor de nomes é um servidor com autoridade pam um nome consultado. Uma nag de rccur-s<1o dcscjnda de I biL ~ csLabelccida quando uni cliente ( hospedeiro ou servidor de nomes) quer que um servidor ele nomes proccdn recursivamente sempre que nolo tem o registro. Um cam1l0 de recursão disponível ele 1 bit é marcado em uma resposta se o servidor de nomes suporta buscas recursivas. No cabeçalho, h:1tambêm quatro campos de ·número de'. Esses c-Jmpos indicam o mlmcro de ocorrencias elos quatro tipos de seção de dados que se seguem ao cabeçalho. A srçtlo tlc IJrrgunto conLém informações sobre a consulta que csL:I sendo feita. Essa seç;'lo inclui (l ) um campo de nome que contém o nome que eslá sendo consultado c (2) um campo de tipo que indica o tipo de pergumn que está sendo feito sobre o nome- por exemplo, um endereço de hospedeiro assoCiado a um nome (Typc A) ou o sen•idor de correio para um nome (Type MX). Em uma resposta de um sen'iclor de nomes, a scçdo de II!SfWSW contém os registros de recursos pam o nome que roi consultado originalmente. Lembre-se de que em cada rcg1stro de recurso h:\ o Type (por exemplo. A, NS, CSNMtE c MX), o Value e o TTL. Uma resposta pode retornar vários RRs, já que

bow4tto4ic~ Redes de co11pulodores e o ln;.;l..;.e;.;rn;.;e;.;.l_________________________

ldentificaç~o

Flags

Número de perguntas

Número de RRs de resposta

Número de RRs com autoridade

Número de RRs adicionais

Pergunt as (número variável de perguntas)

1,.,.. J }

Nome, campos de tipo para uma consulta

Respostas (número variável de registros de recursos)

1

Autoridad e (número variável de registros de re<:vrsos)

}

Registros para servidores com autoridade

Informação ad icional (número variável de registros de recursos)

}

Informação adicional 'útil', que pode ser usada

-----=

RRs de resposta

---

a consulta

Figura 2.23 Formoto do mensagem DNS

um nome de hospedeiro pode 1er diversos endereços IP (por exemplo, para servidores Wcb replicados, como já discutimos anteriormente nesta scç.io).

A senlo ele rwlor iclmlc contém registros de outros servidores com autoridade. A sC'çclo tuliciorwl contém outros regis tros úteis. Por exemplo, o campo resposta em uma resposta a uma consulta MX conter:\ um registro de recurso que inrorma o nome canônico de um servidor de correio. A seç;\o adic1onal conter:\ um registro T)•pe A que fornece o endereço IP paro o nome <.":lnOnico do servrdor de correio. Voe~

gostaria de cn\liar uma mensagem de consulta DNS dírcuuncmc de sua máquina a algum servidor DNS? Isso pode ser feito facilmente com o programa nslookup. que está dtsponf\•cl na matoria das platarormas Windows c UN IX. Por exemplo. se um hospedeiro executar Wmdows, abro o Command Prompt c chame o programa nslookup simplesmente digitando ' nslookup'. Depoi.s de chamar o programa, voe~ pode cn\liar uma consulta DNS a qualq uer ser\! idor de nomes (raíz, TLD o u com autoridade). 1\pós receber a mensagem de resposta do ser"idor de nomes, o nslookup aprcsemará os regis1ros inclufdos na resposta (em ror mato que pode ser lido normalmcmc). Como alternativa a cxcctuar nslookup na sua própria máquina, voe~ pode visitar um dos muitos shcs Web que permitem o emprego rcmo1o do programa. (Bas•a digitar ·nslookup' em um buscador c voce será levado a u m desses s itcs.)

Poro inserir registros no banco de dados do ONS A dlseussào anterior focalizou como sao extraídos registros do banco de dados DNS. I! possível que você csleja se perguntando como os registros cnlraram no banco de dados em primeiro lugar. Va mos examinar como rsso t fcrto no contexto de um exemplo específico. hnagtnc que ''Oct al-:tbou de cnar uma nova empresa muito interessante denominada Network Ulopia. A primeira coisa que voe~ ccn:.mentc de\!Cr:i fazer é registrar o nome de domfnio ne two rkuto pl a. com em uma entidade rcgistradom. Uma entida de registra dora é uma entidade comercial que verifica se o nome de domínio é exclusi\IO, regis Lra-o no banco de dados do DNS (como discutiremos mais adiante) c cobra uma pequena taxa por seus seNiços. Antes de 1999. uma única emidade rcgrstmdom. a Network Solutions. dctmha o monopólio do registro de nomes para os dormnios com, net c org. Mas agora existem muitas entidades registradoras credenciadas pela lnlernet Corporatlon for Assigned Namcs and Nurnbcrs (ICA N) compelindo por cliemcs. Uma Usta comple1a dessas entidades cstà disponi"el em http://www.internic.net.


Camada de aplicação

10 5

Vulnembilidodesdo ONS Vimos que o DNS é um componente fundamental do infraestrutura do Internet, com muitos serviços importantes - incluindo o Web e o e-moil - simplesmente incapazes de funcionar sem ele. Desta maneiro, perguntamos: como o DNS pode ser alocado? O DNS é um olvo esperando poro ser atingi· do, pois causo dono à moiorio dos aplicações do Internet junto com ele? O primeiro tipo de aloque que vem à mente é o aloque inundação no largura de bonde DDoS (vejo o Seção 1 .6) con tra servidores DNS. Por exemplo, um otocon te pode tentar enviar para cedo servidor DN S raiz uma inundação de pacotes, fazendo com que a maioria das consultas DNS legitimas nunca seío respondida. Tal ataque DDoS em largo escola contra servidores DNS raiz aconteceu em 21 de ou tubro do 2002. Nosso ataque, os atacantes se aproveitavam de um botnel poro enviar centenas de mensagens ping paro cada um dos servidores DNS ra iz. jAs mensagens ICM P são discutidas no Capitulo 4. Por enquanto, basto saber que os pacotes ICM P são tipos especiais de dotogromos IP .) felizmente, esse aloque em largo escalo causou um dono mínimo, tendo um pequeno ou nenhum impacto sobre o experiência dos usuórios com o Internet. Os atacantes ob tiveram êxito ao direcionar centenas de pacotes oos servidores raiz. M os muitos dos servidores DNS raiz foram protegidos por filtros de pacotes, configurados paro sempre bloquear todos os mensagens ping ICM P encaminhodos aos servidores raiz. Desse modo, esses servidores protegidos foram poupados e funcionaram normalmente. Além disso, o maioria dos servidores DNS locais oculto os endereços IP dos servidores de domínio de nivel superior, permitindo quo o processo de consulto ultrapasso frequentemente os servidores DNS raiz. Um aloque DDoS potencialmente mais eficaz contra o DNS seria enviar uma inundação de consultas DNS aos servidores de domínio de alto nível, por exemplo, poro todos os servidores de domínio que lidam com o domínio .com. Seria mais difícil filtrar os consultas DNS direcionados aos servidores DNS; e os servidores de domínio de alto nível não são ultrapassados tão facilmente quanto os servidores raiz. Mos o gravidade de tal ataque poderio ser parcialmente amenizada pelo coche nos servidores DNS locais. O DNS poderio ser alocado potencialmente de outros maneiros. Em um ataque de homem no meio, o atacante intercepto consultas do hospedeiro e retorno respostas falsos . No ataque de enveneno· menta, o otoconte envio respostas fobos o um servidor DNS, fazendo com que o servidor armazene os reg istros falsos em suo coche. Ambos os ataques podem ser utilizados, por exemplo, poro redirecionar um usuário do Web inocente ao site Web do a tacante. Esses a taques, entre tanto, são difíceis de implementar, umo vez que requerem o inlercepçõo de pacotes ou o es trangulamento de servidores (Skoudis, 2006). Ou tro aloque DN S importan te não é um a taque ao serviço DNS por si mesmo, mas, em vez disso, se aproveitar da infraeslruturo do DN S poro lançar um ataque DDoS contra um hospedeiro-alvo (por exemplo, o servidor do mensagens de suo universidade). N esse a taque, o atacante en11io consultas DNS poro muitos servidores DNS outoritotivos, com cada consuho tendo o endereço-fon te fo lsilicado do hospedeiro alvo. Os servidores DNS, entõo, enviam suas repostos diretamente poro o hospedeiro-alvo. Se os consultas puderem ser realizados de tal maneiro quo umo resposta seja muito maior (em bytes) do que uma consulto (denominado amplificação), então o otoconto pode entupir o alvo sem ter que criar muito de seu próprio tráfego. Tais aloques de reflexão que exploram o DNS possuem um sucesso limitado até hoje (Mirkovic, 2005). Em resumo, não houve um ataque que tenha interrompido o serviço DNS com sucesso. Houve ataques refletores bem-sucedidos; entretanto, eles podem ser (e estão sendo) abordados por umo con· figuração apropriada do servidores DNS.

bow4tto4ic~ Redes de tom pu tod ores e o Interne~1-----------------------Ao registro r o nome de domínio ne tworku topi a. com, você tam~m prccísar:l informar os nomes e endereços IP dos seus servidores DNS com autoridade. primános e secundários. Supon ha que os nomes c endereços IP sejam dnsl.networkutopfa .com. dns2 .networkutopla.com, 212.212.212.1 c 212.212 .21 2 .2. A emidadc rcgistmdoro ficará encarregada de pro,•idcnciar a inserção dos registros Typc NS c de um registro Typc A nos servidores TLD do domínio com para cada um desses dois servidores de nomes com autoridade. Espccifit-amentc paro o servidor primário com autoridade networ ku topi a . com, a autoridade rcgistrodom inseriria no sis tema DNS os d ois registros de recursos seguintes:
A>

Nao esqueça de pro\•idcnciar também a inserç;\o em seus scn •tdores de nomes com au toridade do regis tro de recurso Trpc A 1>am seu servidor Web ww1-.•. net1-1orkutop i a . com c o registro de recurso Typc MX pam sctt servidor de correio ma i 1. networkutopi a. com. (Até há pouco tempo, o conteúdo de cada servidor DNS era con ngurado estaticamente, por exemplo, a panir de um arquivo de conl'iguraçilo criado por um gerenciador de sis tema. Mais ret:C IHCmcntc, roi acrescentada ao protocolo DNS uma opç1lo UPDATE que permi te que dados sejam dinamicamente acrescentados no banco de dados ou apagados deles por meio ele mensagens DNS. O IRF C 2l36 I c o [ RF C 30071 cspccincam atualizações dinâmicas elo DNS.) Q uando todas essas etapas estiverem concluídas, o público em geral podem visitar seu si te Wcb e em•iar e-milils aos empregados de sua empresa. Vamos concluir nossa dis~:uss;lo do DNS verirlcando que essa anrmac;;lo é ''crdadcir.1, o que também ajudará a solidifkur aquilo que aprendemos sobre o DNS. Suponha que Alice. que está na Austrália, queira consult.ar a página Wcb www . networku t op1 a. com. Como discmimos amcriormemc, seu hospedeiro primeiramente en,•iar:l u rna consulta DNS a seu servidor de nomes local, que cntào contatar:i um servido r TLD do domfnio com. (O servidor de nomes local também ter:í de contatar um sen •1dor de nomes ratz caso n~o tenha em seu cache o endereço de u m servtdor TLD com.) Esse senti dor TLD cont~m os registros de recursos Type NS c Typc A citados anteriormente. porque a enudade registradora ja os tinha inserido em todos os sen •idores TLD com. O servidor TLD com envia uma resposta ao sen•idor de nomes local ele Alice. comendo os dois regis tros de recursos. Ent~o. o servidor de nomes local envia uma consulta DNS a 212.212.2 12. 1, solicitando o regist ro Type A correspondente a www. networkutopi a. com. Este registro provi! o endereço IP do s ervidor Web dcsCJado, digamos, 212 . 212 . 71 . 4. que o servidor local de nomes transmite para o hospedei ro de Alice. Agora, o browser de Alice pode iniciar uma conexão TCP com o hospedeiro 212 . 212. 71. 4 c enviar uma requisiç-lo HTTP pela conex;\o. Ufa! Acontecem muito mais coisas do que percebemos quando navegamos na Web!

2.6 Aplicações P2P As aplicações descritas neste capítulo até agora- inclusive a \ Veb, e-m ali c DNS - todas empregam a rq uitctums clicntc•servidor com dependência significativa crn servidores com infr-Jcstr utu m que sempre permanecem ligados. Como consta na Sc{:\o 2.1. 1, ~om uma nrquitcturn P2P, há depcndencia mfnim:1 (se houver) de servido· re:s com infraestrutu ra que permanecem sempre ligados. Em vez disso, duplas de hospedeiros lmcrmitcnu•mente conectados, chamados p:ucs. comunicam-se diretamente entre si. Os p:1res mlo silo de propriedade de um provedor de sen•iços, mas si m de dcsktops c lnptops comrolados por usu:\rios. Nesta seç:'\o, examinaremos tri!s diferemcs aplicações que são particularmente bem apropriadas a projetos P2P. A primeiro é a distribuição de arquivos, em que n aplicaç:lo cl1stribui um a rquivo a partir de uma única fome pam um gmndc mlmcro de pares. A distribuiç-.lo de arquivos é um bom local p:1m imcmr a 111\'estigação de P2P, visto que expõe claramente a aUioescalabilidade de arquiteturas P2P. Como exemplo espectfico pam distribuição de arquivos, d escreveremos o popular sistema BitTorrcnL A segunda aplicaç;\o P2P que examinaremos é um banco de dados dtstnburdo em uma grande comunidade de pares. Pam essa aplicação, cxplomrcrnos o conceito de uma Distribmed Hash Table ( DHT). Por fim, para nossa terceira aplicação, examinaremos o Skype, uma aplicação de telefonia P2P da Internet de sucesso fenomenal.


Camada de

opli'o~õo

107

7.6.1 Distribuição de arquivos P2P Começaremos nossa im•estida em P2P considerando uma aplicação bas~.ame n:uural, ou seja, a distribuição de um grande arquh•o a panir de um unico servidor a um grande numero de hospede1ros (chamados pares). O arquivo pode ser uma nova ''ersâo do sistema operacional Linux. um patch de sortware para um sistema operacional ou aplicação extstcnte. um arquivo de música MP3 ou um arquivo de vfdeo MPEG. Em uma distribuiÇão de arqui vo chcnte-servidor, o servidor deve enviar uma cópia do arqui\•o para cada um dos pares- colocando um enorme fardo sobre o servidor c consumindo uma grande q uantidade de banda do servidor. Na distribuiçao de arquivos P2P, t'
Es
ô

Arquivo: F Servidor

Internet

•

Figura 2.24 Um problema ilustrativo de distribui(õo de arquivo

bow4tto4ic~ Redes de computadores e o lnte;.;rn;.;e;.;.t_________________________

gargalos encomram-sc no acesso à rede. Suponha também que o servidor c os clientes n:lo participam de nenhuma omra aplicação de rede, para que toda sua largura de banda de acesso de upload c down load possa ser totalmeme devotada à d1stribuí~'o do arquivo. Dctenmnemos pnmeiro o tempo de distribu ição para a arquitet ura chentc-servidor, que denotaremos por D,,· Na arquitelllra cliente-servidor, nenhu m dos pares auxilia na dislribui~io do arquivo. Fazemos as observações abaixo:

O se rvidor deve transmitir uma cópia do arquivo a cada um dos N p;ucs. Assim, o servidor dc,•e trans· mltir NF bits. Como a taxa de u pload do servidor é de u,. o tempo para distribuição do arqmvo deve ser de pelo menos Nf/u_. Deixemos que ti.,., denote a taxa de download do par com menor taxa de download, ou seja, d,_ • min(tl,.
11111111

Isso propon.:lo n:1 um limite lnrcrior pnra o tempo mínim o de dlstrlbuiç:\o para a arquitetura cliente-scn·idor. Nos problemas do Onal do cólpftulo, vod~ deverá demonstrar que o servidor pode progmmar suas transmissões de forma que o limite Inferior seja sempre alcançado. Portanto, co nsideraremos esse limite inferior fornecido anteriormente como o tempo real de distribuiç;\o, ou seja, NF· __ F 0 0 •máx I -

I

(2.1)

dmtn

Us

Vemos. a parur da Equnç;'o 2.1. que para N gra nde o s uficiente, o tempo de distribuiç:lo cliente-servidor é dado por Nflu,. Assim, o tempo de distribuição aumenta lineannente com o numero de pares N. Port.-mto, por exemplo. se o numero de pares de uma semana para a outra for mullipliCO mini mo de distribuiçllo é de pelo menos Fiel .

....

Finalmente, obscn•emos que a ~-apacidade de upload total do sistema como um todo é igual à taxa de uplood do ser\'idor mais as taxas de upload de cada um dos pares individuares, entregando assi m um total de Nf b1ts. Isso não pode ser feito em uma taxa mais rápida do que u• ....a· Ass1m, o tempo mini mo de distribuição t também de pelo meMs NF/(u. + u, + ... + u.J. juntando essas tr~ observações, obtemos o tempo minimo de disLribuição para P2P, denotado por Drw



109

(2.2)

A Equaç:\o 2.2 fornece um limite inferior para o tempo mínimo de distríbuiç;\o para a arquitetura P2P. Ocorre que. se imaginarmos que cada par pode redistribuir um bn asstm que o recebe, h:i um esquema de redtstnbuiç:lo que, de fato , alcança esse limite infcnor IKumar, 2006) (Provaremos um caso espc· cial desse resultado na liç-.\o de casa). l a realidade, quando blocos do arquivo s;\o redistribuídos, em vez de bits indivtduais, a Equação 2.2 serve como uma boa aproximaç--ão do tempo mínimo real de distribuição. Assun. peguemos o limite inferior fornecido pela Equaç;\o 2.2 como o tempo mínimo real de distribuiç:lo, que é:

NF

( 2.3)

A Figura 2.2S compnrn o tempo mínimo de distribuição para as arquitrturas cliente-servidor c P2P, pressupondo que todos os pares t~m a mesma taxa de upload u. Na Figura 2.25, temos de fi nido que F/u • 1 hora, u~ • 1011 c c/'""' ~ " s· Assim, um par pode transmitir todo o a rquivo em uma hora, sendo a taxa de transmissão do servidor 10 vezes a taxa de upload do par, e ( para simplicid:\de) as taxas de download de par s:l o definidas grandes o sulkicmc de forma a nào ter deito. Vemos na Figura 2.2S que, parn n arqu itetura cliente-servidor, o tempo de dis tribuiç-lo aumenta linearmente c sem IJmítc. conforme aumenta o número de pares. No entanto, para a arquitetura P2P, o tempo mínimo de dístribui\'àO não é apenas sempre menor do que o tempo de distribuiçfto da arquitcturn cliente-servidor; c lambem de menos do que uma hora para qualquer numero de pares N. Assim, aplicaçôcs com a arquitetura P2P podem ter autocscalabilidade. Essa e.scalabilidade é uma consequ~ncia direta de pares sendo redistribuidores. bem como consumidores de bits.

Bitlorrent O BitTorrcnt é um protocolo P2P popular para distribuição de arqmvos IBitTorrent, 20091. No jargão do RitTorrcnt. a coleção de todos os pares que participam da distribuiç-.lo de um determinado arquivo é chamada de IOIICIII. Os pares em um torrcnl fazem o download de blocos de tamanho igual do arquivo entre: s t, com um

3.5

o

~

V'

·:; &l

Cliente; Servidor

·;:

2.5

111

2.0

t:: 'õ -o

~ 'ê &

'é

E

~

/

3.0

I. _./

1.5 1.0

J

0.5

o

~

~ o

I

s

/

P2P

I

I

I

I

I

I

I

10

15

20

25

30

35

N

Figura 2.25 Tempo de distribuição poro arquiteturas P2Pe diente-servidor


tamanho tfpico de bloco de 256 KBytes. Quando um par entra em Ltm torrent. ele nâo tem nenhum bloco. Com o tempo, ele acumula mais blocos. Enquanto ele faz o download de blocos, faz tam!Xm uploads de blocos para omros pares. Uma vez que um par adquire todo o arquivo. ele pode (de forma egorsta) sair do torrem ou (de forma altrutsta) permanecer no torrem e continuar fazendo o upload de blocos a Olllros pares. Além diSSo, qualquer par pode sair do torrem a qualquer momento com apenas um subconJtmto de blocos, c depois ''oltar. Observemos agora. mais atentamente, como opera o BitTorrem. Como o BnTorrent é um protocolo e sistema complicado. descreveremos apenas seus mecanismos mais importantes. ignornndo alguns detalhes: isso nos permitir:\ ver a Oorcsta através das árvores. Cada torrem tem um nó de infraestruturn chamado rastreador. Quando um par chega em um torrcnt, ele se registra com o rastreador c periodicnmente infonn:-~ ao rnstrcador que ainda está no torrem. Dessa forma, o rastrcador mantêm um registro dos pares que participam do torrem. Um detcrmi· nado torrent pode ter menos de dez ou mais de mil pares participando a qualquer momemo. Como demonstrado na Figura 2.26, qltando um novo par, Alke. chega no torrem, o rastrcador seleciona aleatoriamente um subconjunto de pares (para dados concretos, digamos que sejam 50) elo conjunto de pares pitrticipanH."S, c envia os endereços lP desses 50 pares paro Alke. Com a li st:-~ de IY.Jres. Alice tenta cstabcleccr conexOcs TCP simultâneas com todos os pares ela lista. Ch:1maremos todos os p:1res com quem i\lice consiga estabelecer uma concx110 TCP de ~pares vizinhos~ (na Figura 2.26, Alice é reprl'Scnutda com apenas três pares vizinhos. Normalmente, ela Leria muito mais). Com o tempo, alguns desses pares podem sair c Olttros pares (fora dos 50 iniciais) podem tcnwr estabelecer conexões TCP com AJice. Pon:mto, os pares vizinhos de um par podem Omuar com o tempo. A qualquer momcmo, cada par terá um subconjuruo de blocos do arquivo, com pares diferentes com subconJUntos diferentes. Penodicamcntc, Ahce pcdm\ a cada um de seus pares viztnhos (nas conexOCS TCP) a ltsta de quais blocos eles têm. Caso Alice tenha L vizinhos dirercntcs, ela obter:\ L lístas de blocos. Com essa informação, Alice emitir.\ solicitaçOCS (novamente. nas conexões TCP) de blocos que ela não tem. Portamo, a qualquer momento, Alice terá um subconjunto de blocos e saber:\ quats blocos seus vizinhos têm. Com essa inrormaç.\o, Alice terá duas decisões importantes a razcr. Primeiro. quais blocos ela deve solicitar primeiro de seus vizinhos. c segundo, a quais vizinhos ela dc,·c envaar os blocos solicitados. Ao decidir quais Rastreado r

Obter lista de pares

Figura 2.26

Oistribui~õo

de orquivos com o BitTorrent

Par



111

blocos solicitar, Alice usa uma técnica chamada rarest Jírst (o mais raro primeiro). A ide ia~ determinar, dentre os blocos que ela n;\o tem, quais silo os mais raros dentre seus vizinhos (ou seja. os blocos que t~rn o menor número de cópias rcpeudas em seus vizinhos) c então solicitar esses blocos mais raros pnmc.ro. Dessa forma, os blocos mais raros s;\o rcdlstriburdos mais rapidamente. procurando (grosso motlo) equalizar os números de cópias de cada bloco no torrcnt. Para determinar a quais pedidos atender, o BitTorrent usa um algorillllo de troca inteligente. A idcia básica é Alice dar pnoridade aos v1zinhos que :uualmeme fornecem seus dados com tlmc1ior ltLWI. Especificamente, para cada um de seus ''izinhos, Alice mede continuamente a taxa em que recebe bits c determina os quatro pares que lhe fornecem na melhor Hlxa. Então, ela reciprocamente envia blocos a esses mesmos quatro pares. i\ cada lO segundos, ela rccalcula as taxas e possivelmente modiflc.-a o conjunto de quatro pares. No j<~rgão do BitTorrent, esses quatro pares são chamados de 11nclto/led (não sufocado). É importante informar que. a cada 30 segundos. ela também escolhe um "izinho adicional aleatoriamente c en"ia blocos para ele. Chamaremos o "izinho escolhido ale:lloriamcntc de 13ob. No jarg."o de BitTorrcnt, Bob e chamado de optimistiwlly uncholml. Como t\licc envia dados a Bob, ela pode se tornar um dos qumro melhores transmissores para Bob, cttso em que Bob começaria a Clwiar dados para Alícc. C01so a taxa em que Bob envie dados a Alice :.cj:l alta o suficiente, Bob pode, em troca, torn:.r-sc um dos quatro melhores transmissores para Alice. Em outras palavras, Alice nlc:uoriarncnte escolherá um novo parceiro <.lc troca e a começará com ele. ü 1so os dois pares estejam satisfeitos com a Lroc.:a, eles colocar-ao um ao outro nas suas listas de quatro melhores pares c continuarão a troca até que um dos pares encomre um parceiro melhor. O deito é que pares capazes de ftuer uploads em taxas compatfvcis tendem a se encontrar. A sclcc:\o aleatória de vizinho também permite que novos pares obtcnh;un blocos. de forma que possam ter algo para trocar. Todos os pares vizinhos, além desses cinco pares (q uatro pares "top- e um em experiência) estão · sufocados· , ou seja, nllo recebem nenhum bloco de Alice. O BitTorrcnt tem diversos mecanismos interessantes não discutidos aqui, mcluindo pedaços (miniblocos). pif)elrning (tubulação). pnme1ra scleç;\o aleatória, modo cnclgamr ( Om de jogo) c tmti-snubbing (an ti rrcjcição) (Cohcn 2003(. O mccamsmo de mcentivo para troca descrito aci ma é normalmente chamado de tir1oH(Il (olho por olho) (Chcn 2003(. Demonstrou-se que esse esquema de incentivo pode ser burló!do (Uogkas. 2006; Locher. 2006: Piatck, 2007(. Não obstante, o ccossístema do BitTorrent é muito bem-sucedido, com milhOcs de pares s•muhãneos comp:milhando arquivos :llÍ\'3Jnentc em centenas de milhares de torrcnts. Caso o BuTorrent tivesse sido projetado sem o lit-for-tat (ou uma variamc), mas com o restante da mesma maneira. ele provavelmente nem existisse mais, visto que a maioria dos usuarios S<1o pessoas que apenas querem obter as coisas grJtuhamente (Saroiu. 2002(. Variantes interessantes do protocolo BitTorrent são propostas (G uo, 2005: Pmtek, 2007] . Além disso, muilas das aplk11~·oes de tmnsmissl\o em tempo real P2P, como PPUve c ppstrC'Jm, foram inspirados pelo BitTorrcnt (l-lei 2007] .

2.6.2 Distributed Hosh Tobles (DHTs) Um componente crrtlco de muitas aplicações P2P c outras aplicações distrlbuldas é um Cndkc (ou seja. um banco de dados simples), que suport;t oper-acões de busca c atualização. Quando esse banco ele dnclos é distribufdo, os p;~res podem realizar caching de conteúdo c rotenmento solislicado de consultas entre si. Como a indexação c bltsca de informações são um componente crítico nesses sistemas , cobriremos uma técnica popular de Indexação c buS<.~J, Distributed Hash Tables (DHTs). Consideremos assim a construção de um banco de dados simples distrihuldo em um grande numero ( possivelmente nulhOes) de parl'S que suporlllm indexação c solicitação simples. As informações armazenadas em nosso banco de dados consistir-lo de duplas (chave. valor). Por exemplo, as chaves podem ser números de seguridade social c os valores podem ser nomes humanos correspondentes; nesse caso, um exemplo de dupla chave-valor ê (L56-45-708l , johnn)' Wu). Ou as duplas podem ser nomes de comeüdo (ex.: nomes de nlmes, ;ilbuns e software). c o valores podem ser endereços IP onde o conteúdo está armazenado: nesse caso, um exemplo de par cha,·c-valor é (Lcd Zcppclin IV, 203.17.123.38). PMes consultam nossos bancos de dados fornecendo a chave: caso haja duplas (chave, valor) em seus bancos de dados que correspondam à chave. o banco de dados retorna


as duplas corrcspondcmes ao par solíciLantc. Ponanto, por exemplo, caso o banco de dados armazcr1e mlmeros de seguridade social e seus nomes humanos correspondentes. um par pode consultar um número de seguridade sochtl específico c o banco de dados retornará o nome do humano que possui aquele número de seguridade social. Pares tam~m devem ser c.tp;ucs de inserir duplas (chave. '-':llor) em nosso banco de dados. A construção desse banco de dados é direta com uma arquitetura clienu:-servidor na qual todos os pares (chave, valor) silo annazcnados em um servidor central. Essa abordagem centrahzad., também foi considerada em anugos srstemas P2P como o Napster. Mas o problema é srgmflcativamente mais des.~fiador e interessante em um sistema distribuído que consiste de milhões de pares conectados sem autoridade central. Em um sistema P2P. queremos distribui r as d uplas (chave. \'alor) entre todos os pares. de forma que cada par tenha apenas um J>equeno subconjun to d:.t totalidade dos pares (chave, v:~lor) . Urna abordagem inocente p:1r:1 a construção desse banco de dados P2P é (I) espalhar aleato riamente as duplas (chave. valor) entre os pares c (2) fazer com que cada par tenha uma lista dos endereços de IP de todos os pares part icipantes. Dessa rorma, o prrr solicilante pode enviar uma solicit:.tçilo a todos os outros pares, c os pares que tenham dup las (c have, valor) que corrcspondam à chave podem responder com as duplas correspondentes. Essa abo rdagem t cornplct:uncntc n:io escalável, logica· mcm e. visto ttue cada par precisaria r;\Strca r todos os oulros pares (posstvclmcntc milh()cs) c, pior, crwit~r ~·ada solici Laç;lo a lollos os pares. Agora descreveremos uma abordagem clcgamc paro um projeto de banco de dados P2P. Para isso, primeiro designaremos u m idcntlncaclor a cada par, em que ~1da idcntiOcador é um nu mero inteiro na faixa 10. 2•- li de algum ,. rlxo. Observe que cada idcnúl'icador pode ser expresso por uma rcprcscnt:l(;âo com 11-blts. Vamos também exigir que cada chave seja um número imeiro na mesma faixa. O leitor astulo pode ter observado que as chaves de exemplo descritas nntcriorrnentc não são (números de seguridade social c nomes de conteúdo) números inteiros. Pam criar mlmeros imeiros a partir dessas chaves, precisaremos usar uma funç;\o hash que mapeie cada chave (por exemplo. numero de seguridade social) em um numero iruciro na farxa lO. 2• - li . Uma função de hash é uma runç:\o de muitos-para-um parn a qual duas entradas dircrentcs podem ter a mesma salda (mesmo numero intcrro). mas a probabilidade de terem a mesma salda ~ ex1remamcmc pequena (!chores nilo familiarizados com funções de hash podem querer consultar o Caphulo 7, que discu te dctalhadamcntc funções de hash). A função de hash t consrderada publicamente disponível a todos os pares no sistema. Portanto. quando nos rderimos :\ "chave·. nos referi mos ao hash da chave original. Portanto, por exemplo, caso a chave origrnal seja · Led Zcppclin 1v·. a chave será o número inteiro que corresponda ao hash de - Lcd Zeppclin 1v·. Alem disso. como estamos usando hashes de chaves. em vez das próprias d1avcs. nos referiremos ao banco de dados dislribuído corno Oistri bu ted Hash Table ( OHT). Consrdcraremos ar cujo identificador está mais próximo da chave. Para implementar esse esquema, precisaremos dcllnir o que signifiC'l1 'mais próximo', o que admi te mui tas convenções. Por corweniência, defin iremos que o par mais próximo é o srrcl.'ssor· imccllmo da cJr(II'C. Parn visualizarmos, observaremos um exemplo específico. Suponha que 11 • -! , port;mto. todos os identificadores de par c chave estarilo na faixa de (O, 151. Su(>Onha ~linda que haja ol1o pares no sistema com idcnlificadorcs l, 3, 4. S. 8 , 10. 12 c 15. Finalmente, suponha que queiramos armazenar o p:~ r chave-valor (ll ,Johnn)' Wu) em um dos oito pares. Mas em qual? Usa ndo noss1 corwençllo de mais próximo, como o par 12 é o sucessor imediato da chave l l , ar mazenaremos, portanto, a dupla ( l l ,Joh nny Wu) no par l2 (para concluir nossa definiç;io de mais próximo. {".ISO a cha,·c seja cxat;uncnte igual a um dos iden tíficadorcs do par, armazenaremos o par (chave-valor) em urn JY.lr correspondente: e caso a chave seja maior do que todos os tdcntil'icadores de par, uS;~rcmos uma convcn~o módulo-2", q ue armazena o par (chave-,·alor) no par com o menor ldenlificadorJ . Suponha agora que um par, Alice, queira inserir uma dupla (chave-valor) no DIIT. Conccitualmcme, ~ um processo obJeuvo: ela primeiro detern1ina o par cujo identificador e o mais próxrrno da chave: enlilo ela cn\•ia uma mensagem a esse p:lr, instruind~o a armazenar a dupla (cha\'C, \'alor). M.IS como Alice delcrmina o par mais proximo da chave? Se Alice ras1reassc todos os pares no sistema (!Os de par e endereços IP correspondcntcs), ela poderia


Camada de

opli'o ~õo

113

determinar localmente o par mais próximo . Mas essa abordagem requer que ccu/(1 par rastreie tiXIos os outros pares no DHT- o q ue é complcUlmente impraticável para um sistema de grande escala com milhões de pares.

DHT circular Para abordar esse problema, consideraremos agora organizar os pares em um Circulo. Nessa d isposição circular. cuda par rastreia apenas seu sucessor imediato (mód ulo 2"). Um exemplo desse circulo é exibido na Figura 2.27(a). Nesse exemplo, n é novamente 4 e há os mesmos oito pares do exemplo anten or. Cada par está ciente apenas de seu sucessor imedi ato; por exemplo. o par 5 sabe o endereço IP e o identificador do par 8, mas não sabe ncccss."lriamente nada sobre quaisquer out ros JXITCS no DI-IT. Essa disposi~io ci rcular dos pares é um <."J$0 especial de uma rede sobreposta. Em uma rede sobre posta. os pares formam wna rede lógica abstrata que reside aci ma da rede de computadores ~inferior~ que consiste de enlaces rlsicos, roteadores c hospedeiros. Os enlaces em uma rede sobrepost:\ não são rislcos, mns enlaces virwais entre dL1plas dr pares. Na rede de sobreposição d:1 Figura 2.27(:~) , ha oito pares e oi to enlaces sobrepostos; na sobreposição da Figura 2.27(b) há oito pares c 16 enlaces sobrepostos. Um linico enlace de sobrcrX~s i ç-ão normalmemc usa muitas ligaçÕeS físicas c roteadores risicos na rede inferior. Usando a red e de sob•·eposíçâo cirntlar da Figura 2.27(a), SUI>
Qvemé responsável

1

/' •

pela chave t 17

.3 15 .

1S e

e4 12.

12.

•

lO

a.

e4

•s

•8

/ 8

b.

Figura 2.27 (o) Um DHT circular. Opor 3quer determinar quem é responsável pelo chove 11. (b) Um DHT circularcom atalhos


rastrear todos os outros pares (sobreposições de maU)a), apenas uma mensagem será enviada por solicilaç.\o, mas cada par deverá rastrear N pares. Por outro lado. com um DHT circular. cada par esul ciente apenas de dois pares. mas N/2 mensagens s;.\o enviadas em média para cada solicitação. Felizmeme. podemos refinar nossos projetos de DHTs de rorma que o número de vizinhos por par, bem como o número de mensagens por solicit;\ç;\o seja mantido em um tamanho aceitável. Um desses refinamentos é usar a rede sobreposta circular como rundação, mas adicionar "at.1lhos" de rorma que cada par mio apenas rastreie seu sucessor unedrato, mas também um número relativamente pequeno de pares espalhados pelo circulo. Um exemplo desse DIIT circular com alguns atalhos é dernonstrado na ngura 2.27(b). Atalhos são usados para expedir o roteamento das mensagens de solicitação. Especificamente, quando um par recebe uma mensagem que sohcita uma chave, ele encamrnha a mensagem ao vizinho (vizinho s ucessor ou um dos vizinhos via atalho) que está mais perto da chave. Assim, na Figura 2.27 (b). quando o par 4 recebe a mensagem solicitando a chave li , ele determina que o p:1r mais próximo (entre seus vizinhos) é seu vizinho no atalho 10 c então em•ia a mensagem diretamente ao p::rr 10. Clammentc, ::rtalhos podem reduzl r significativamente o rnlmcro de mensagens usado para processar uma sollciLaç-.lo. A próxima (JUCStão natural é "Quantos vizinhos no atalho c:ad:1 par eleve ter, c quais p
Peer (hurn Em srstcmas P2P. um par pode \•ir ou ir sem aviso. Assim. no proJeto de um DIIT, devemos nos preocupar em manter a sobreposição de DHT na presença desse peer churn. Para termos uma compreensão abrangente de como isso pode ser realizado. consideraremos mais uma vez o DI IT circular da figura 2.27(a). Para manejar o peer churn, exigrremos que cada par rdStreie (ou seja. saiba o endereço IP de) seu pnme•ro e segundo sucessores; por exemplo, o par 4 agora rastreia tanto o par 5 como o par 8. Exigrrcmos também que C':lda par verifique periodicamente se seus dois sucessores estão vivos ( por exemplo, enviando pcnodrcameme mcns.1gens de pmg e pedindo respost::rs). Consideraremos agora como o DHT é mantido quando um par s.1i abruptamente. Por exemplo, suponha que o par 5 da Figura 2.27(a) saia abruptamente. Nesse caso. os dois pares precedentes ao par que saiu ( 4 c 3) S<1berão que o par saiu, pois não responde mais :\s mcns.1gcns de ping. Os pares 4 c 3 precis.1m, portan· Lo . atualizar as informações do estado de seu sucessor. Consideraremos agora como o par 4 atualiza seu estado; L

O par 4 substitui seu primeiro sucessor (par S) por seu segundo sucessor (par 8).

2.

O par 4 , então, pergunta a seu novo primeiro sucessor (par 8) o identif'ic:•dor c o endereço IP de seu sucessor imediato (par lO). O par 4 , enLão, torna o par 10 seu segundo sucessor.

Nos problcmus, voe~ deverá determinar como o par 3 atualiza suas informações ele detcrminaç;\o de roteamento de sobreposição. Tendo abordado brevemente o que deve ser feito quando um par sai, consideraremos agora o que acontece quando um par quer entrar no DIIT. Digamos que um par com identificador 13 quer entrar no 0!-IT, c quando entra, sabe ~1pem1s da existencia do par L no DliT. O par 13 primeiro envia ao par l uma mensagem, perguntando ·quem scn\o o predecessor e o sucessor do par l 3r. Essa mensagem é encaminhada atra\•és do DHT até alcançar o par l2. que percebe que será o predecessor do par 13, e que seu sucessor, o par 15. será o s ucessor do par l3. Em seguida, o par 12 envia as inrormaçóes de sucessor e predecessor ao par 13. O par 13, cnt:\o, pode entrar no OHT, tornando o par LS seu sucessor c notificando ao par 12 que deve mudar seu sucessor imediato para 13. DHTs t~m amplo uso na prática. Por exemplo, o BitTorrent usa o DHT Kadcmli::r para criar um rastrcador distriburdo. No BitTorrem. a chave é o identificador do torrem c o valor é o endereço IP dos pares que atualmente participam dos torrents IFalkncr, 2007: Neglia, 2007): Dessa rorma, solicitando ao DHT um rdemif'icador de torrem, um par de BrtTorrcnt rccém-chcgndo pode determinar o par responS

Camada de

oplico ~ õo

115

de oulros p.1res no torrent. DHTs são usados exLensamem e no sistema de comp.1nllh:unemo de arqlli,•os eMule para loc-o~lizar comeudos em pares [Uang. 20061.

2.6.3 Estudo de coso: telefonia por Internet P2P com Skype O Skypc é uma aplica\<'lo P2P imcnsamcm c popular. muilas vezes com sete ou oito milhões de usuários conectados simultancamcmc. Além de fornecer serviço de telefonia PC parn PC na lmcrnct, o Skype oferece sen •iço de telefonia PC-para-telefone, tclefone-para-PC c serviço de vidcoconfer\!ncia PC-a-PC. Fundado pelos mesmos ind1viduos q ue criaram o FastTrack c o Karna, o Skypc foi adquirido pelo cBay em 2005 por US$ 2,6 bilhões. O Skypc us<~ técnic-.IS P2P de diversas maneiras inovadoras, iluslrando de uma boo mandm como o P2P pode ser usado em aplicações q ue vão além da disuibuiÇão de co ntclido c companilhamcnto de arquivos. Assim como co m programas de rncns:tgcns instan Uin~ts, a telefonia PC-para-PC na Internet é i11crcntcmcmc P2P, visto que, no núcleo do apli cações, duplas de usuários (ou seja, JX!rcs) comunicam-se entre si em tempo real. Porém , o Skype tam~ rn em1>rcga téc nicas P2P J>ara duns outras funções importantes. que s:lo locallzlWClO de usul1rio c NAT traversal. Os protocolos do Skypc não s:lo apenas proprietários, como todas as transmissões de pacotes do Skype (pat:otes d e conLrolc c voz) são criptogmfadas. Não obstMtc, a partir do wcbs ite do Skypc c de diversos estudos de mcdi~'llo. os pesquisadores dcscobrir:un como o Skypc gcr-.almcn te funciona IBaset, 200ó; Guha, 2006: Chen, 2006: Suh. 2006 Ren, 2006 1. Assim como com o FastTrack. os nós no Sk)•pe silo organizados em urna rede sobreposta hierárquica, com cada J>a r classificado como supcrpar ou par comum. O Skypc inclui um fndicc que mapeia os no mes de usuários do Skypc a endereços lP atuais (c números de porta). Esse índice é distribuído

cmrc os supcrparcs. Quando Alice deseja tcldonar para Bob, seu cliente Skypc procura o rndicc distribuído para dctcrmmar o endereço I P atual de Bob. Como o protocolo do Skype é proprietário, atualmente nilo está claro como os mapt>amcntos de indicc S:lo orgamzados nos supcrpares, embora alguma forma de org:miza~·ào DHT seja muito possível. Técnicas de P2P também são usadas cm retmnsmissorcs do Skypc. que s:lo utcls para cst:1bclccer chamadas ent re hospedeiros em redes doméSticas. Muitas conflgumçOes de redes doméSticas fornecem acesso à Internet atm· ,.éS de um roteador (11p1camentc um ro teador sem fio). Esses roteadores são, na verdade, ma1s do que roteadores. c normalmcmc incl uem u m elemento chamado Network Addrcss Translator [Tradutor de Endereço da Internet I (NA T). Estudaremos NATs no Capítulo 4. Por enquanto. tudo do q ue precismnos saber é que um NAT impede que um hospedeiro de fo ra da red e domtstica inicie uma conexão com um hospedeiro dentro da rede dom6aica. Caso mnbos os cha madores do Sk}'pe tenham NATs, hâ um problema - nenhum deles pode aceitar uma chamada iniciada pelo outro. tornando aparentemente impoSSI\'CI uma chamad:1. O uso inteligente de superp;~res e rctmns.missorcs resolve muito bem esse problema. Suponha que quando ;\licc ent ra, ela recebe um supcrJXIr sem NAT. Alice pode iniciar uma sessao com seu s upcrpar, visto que seu NAT apenas Impede sessões iniciadas de foro de sua rede dom~tica. Isso permite que Alice c seu sup<:rpar troquem mensagens de co ntrole nessa scss;lo. O mesmo ocorre com Bob qwtndo ele entra. Agom, quando Alice deseja tclefo m1r para Bob, cl:1 informn a seu supcrpar, que, por sua vez, infornm :10 supcrp:1r ele llob, que en tão informa a Bob sobre a chanmda recebida de Alice. Caso Bob aceite a chamada. os dois supcrp;1rcs selecionam um terceiro supcrp;1r sem NAT-o nó ele: reti"Jnsmissor- cujo trabalho será o de transmitir os dados entre Alice c Bob. Os s upcrp;ues de Alice c de Bob, ent<,o, ins true m Alice c Bob, respectivamente. a iniciarem uma sessão com o rctrJ nsmissor. Alice. ent:'lo, envia pacotes de voz ao retransmissor na concx:'lo Alicc- p:~ra-rctransmissor (que roi iniciada por Alice), c o retransmissor trans mite cs.ses pacotes pela conexão rctronc;mis.sor-parn-Bob (que foi inic1ada por Bob); pacotes de Bob para Alice fluem pelas mesmas duas conexões de retransmissor de fonna inve rsa. E pronto, Bob c Alice tfm uma conexão simultânea fim a fim mesmo que nenhum deles poss.1 accit:lr uma sessão originada for.l de sua LAN. O uso de retransmissor ilustra o projeto cada vez mais soOsticado de sistemas P2P, em que pares realizam sen'iços de sistema ccntml parJ outros (serviço de ind exa\<'lo c trnnsmisS:lo sendo dois exemplos) ao mesmo tempo em que usam o serviço de usuário final (por exemplo, download de arquivo, telefonia IP) fornecidos pelo SIStema P2P. O Skypc é uma aplicaç
bow4tto4ic~ Redes de com putod ores e o Inler.;;n.;;,e,;..t_________________________

P2P, da Web c de programas de mensagens instan tâneas ames dele, é um testamento da sabedoria do projeto de arquitetura geral da Internet, um projeto que não poderia ter previsto o conju nto rico c sempre em expansão de aplirnçõcs da Internet que seria desenvolvido nos próxi mos 30 anos. Os servrços de rede oferecidos a aplicações de Internet- transporte de datagr.una sem conexão (UOP). transferl!ncia de datagrama orientado para conexão (TCP). a interface soekct. endereçamento c nomes ( DNS) en tre outros- pro,-aram ser suficientes para pcrmitü que milhares de aplicações fossem desenvolvidas. Como todas essas aplicações foram colocadas sobre as quatro camadas inferiores existemes da ptlha de protocolo de Internet, eles envolvem apenas o desenvolvimento de novos softwares dlente-sc"'idor e ~er- Lo-pcer para uso nos sistemas fin:~ls. Isso. por sua vez, ~rmítlu que essas aplicações fossem rapidamente empregadas e adoradas.

2.7 Programação e desenvolvimento de aplicações com TCP Agora que já cxamimunos várias importantes aplicações de rede, va mos explorar como silo cscrilos progra· mas de ap licação ele rede. Nes ta seçfto escreveremos programas de ap lic;,ções que usam TCP; na seção seguinte, escreveremos programas que usam UDP. Lembre-se de que na Sc~iio 2. L dissemos que multas aplicações de rede consistem em um par de progra· mas- um pt·ograma cliente e um programa scrvídor - qu e residem em dois sistemas finais daferentes. Quando esses progra mas s5o executados, criam-se um processo cliente e um processo servidor, que se comunicam entre si lendo de seus sockets c escrevendo através deles. Ao criar uma aplicaç-lo de rede, a tarefa principal do progra· mador é escrever o código tanto para o programa dicme como para o programa servidor. I lá dois tipos de aplicações de rede. Um deles é uma unplcmentaçllo de um protocolo padr:\o definido, por exemplo, em um RFC. Para essa implementação, os programas, cliente c serv rd or, devem obedecer ás regras dita· das pelo RFC. Por exemplo. o programa cliente poderia ser uma implcmemaç:\o do lado do cliente do protocolo FTP descrito na Scç-lo 2.3 c definido explicitamente no RFC 959 c o programa servidor, uma implcmcntaç;lo do protocolo de ~crvidor FTP também descrito explicitamente no RfC 959. Se um programador escrever codificação para o programa dicme c um outro prog-ramador independe nte escrever uma codtf'icaçl\0 para o programa servidor c ambos seguirem cuidadosamente as regras do RFC, então os dois programas poder-lo interagir. Realmente, muitas das aplicações de rede de hoje cn"olvem comunicacão emrc programas cliente e servidor que foram criados por programadores diferentes- por exemplo, um browser NeiSeape que se comumc.:a com um servidor Wcb Apache, ou um cliente FT P em um PC que carrega um arquivo em um servidor FTP UNIX. Quando um programa, cliemc ou servidor, implemcma um protocolo definido em um RFC. deve usar o número de porta associado com o pr01ocolo. (Nú meros de portas foram díseutidos brevemente na Seç~lo 2. 1. Scr:lo examinados mais deralhadameme no Capitulo 3.)

O outro tipo de aplicac.-ao cliente-servidor é uma ::.plicaç--.lo pro1n'iclllrin. Nesse caso, o protocolo dt> camada de aplicaç:lo utilizado pelos programas cliente e servidor não obedecem ncccssariarncmr a nenhu m RFC existente. Um tlnlco pl'ogramador (ou equipe de desenvolvimento) cria ambos os programtts cliente c se rvidor, e tem co mpleto con tro le sobre o que entra no código. Mas, como a codificaçlo não implcmcma um protocolo de domínio ptrblrco, outros program:~dores independentes nilo podcr:lo desenvo lver programas que in tcrajam com a aplicaç:1o. Ao desenvolver uma nplicat;;'\o proprietária, o progr:tmõldor eleve ter o c uid;~do de nno usar um dos nümcros de porta bem conhecidos, definidos em RFCs. Ncstõl seç.lo c na próxinm, examinaremos as questões fundamentais do dcscnvolvnncnto de uma apliC3ç;lo cliente-servidor propnetária. Durante a fase de desem•oh•imento, uma das pnmeiras decisOes que o programador de,·c tornar é se a aplicação rodará em TCP ou UDP. Lembre-se de que o TCP é orientado para conexão c provê um cano/ conjich·d clr nrclein e/r bytcs. pelo qual Ouem dados entre dois sistemas finais. O UDP não é oncntado para conexlo e envia /HICotrs de dados indepcndemes de um sistema final ao outro, sem nenhuma g.lramia de entrega. Nesta seção. dcsenvoh•eremos uma aplicação cliente simples que roda em TCP; na seção seguinte. desenvolveremos uma aplicação cliente simples que roda em UDP. Apresentaremos essas aplicações TCP c UDP simples em Java. Poderíamos escreve-las em linguagem C ou C++, mas optamos por Java por diversas razões. Em primeiro


Camada de

opli'o~õo

117

lugar, o código das aplicações ~ mais elegante c mais Llmpo em Java. Com Java, há menos linhas de codificação e c-.tda uma delas pode ser explicada a programadores iniciamcs sem muita dificuldade. Mas não precisa ficar assustado se não esuvcr familiarizado com a linguagem Java. Você ('Onsegmrá acompanhar a codtficação se liver experiencia de programaç;lo em outra linguagem. Para leitores Interessados em programação cliente-servidor em linguagem C, há várias boas referências à dis J>osiç.o (Donahoo, 2001 : tevens, 1997; Frost, 1994; Kurose, 19961 .

2.7.1

Programação de aplicações com T(P

Comentamos na Se~-;\o 2.1 que processos que rod;un em máquinas dircrentcs se comunicam uns com os outros enviando mensage ns para sockciS. Dissemos que cada processo é anl\logo a uma casa c que o socket do processo~ análogo a uma po n a. Como ilustmdo na Figura 2.28, o sockct é a porta cnLrc o processo d:1 aplicação e o TCP. O desenvolvedor da aplicaç:\o controla tudo que está no lado ela camad~ de aplic:~çdo we lcomeSocket, Hospedei ro ou servidor

Hospedeiro ou servidor

Controlado pelo --.,_ desenvolvedor da aplicaç~

Controlado- - + pelo sistema operacional

Controlado pelo desenvolvedor da aplicação

TCPcom buffers, varii\veis

Figura 2.28 Processosque se comunicam olrovésde sockets TCP

Internet

varii\veis

Controlado pelo sistema operacional


que cria um novo sockct paro o dieme. Ao final da (ase de aprescn taç-lo, existe uma conex:\o TCP emre o socket do cliente e o novo sockct do servidor. Daqui em diamc. vamos nos referir ao novo sockct dcdic:tdo do sen •idor como socket de conexão do sen•idor. Da pcrspccuva da aplicação, a conexão TCP é uma tubulação vanual direta entre o socket do cliente e o socket de concx:\o do servidor. O processo clíeme pode eaw iar bytcs paro seu sockct arbilroriamente; o TCP garonte que o processo scn•idor receberá (atr.l\'és do socket de conex:\o) cada byte na ordem em que foram enviados. Assim, o TCP prove um ~rviço confiável de corrente de byres emre os processos chente e sen•ador. Al~m disso, exatamente como pessoas podem entrar e sair pela mesma porta, o processo cliente nllo somente em•ia b)•tcs a seu socket, mas também os recebe dele; de modo semelhante, o processo servidor n:\o só recebe bytes de seu socket de conexão, mas também os envia por ele. Isso é ilustrodo na figura 2.29. Como sockcts d esempenham um papel central em aplicações cliente·scrvidor, o desenvolvimento d essas aplic:tçõcs também é denominado progromaç:\o de sockcts. Antes de apresentarmos nosso exemplo de aplica\o'O clicntc·scrvidor. ~ú til discutirmos a noção de c:tdeia. Uma cadeia é uma seq u~nda de caroctercs que nuem p:1ra dentro ou paro for-.1 ele 11111 processo. Cada cadeia é, para o processo, uma cadei~ de cmrada ou urna cadeia de salda. Se a cadeia for de entrada, estará Iigada a alguma fonte de entrada para o processo, tal como uma entrada-padrão (o teclado) ou um sockct pan.1o q ual fluem dados vindos da Internet. Se a cadeia for de s alda, estará ligada a alguma fome de s.1fcl<1 p-am o pi'Ocesso, tal como uma saída padnlo (o monitor) ou um sockcl do qual nucm dados para:. Internet.

2.7.2 Um exemplo de aplicação cliente-servidor em Java Usaremos a segui me aplic:tç.\o cliente-servidor simples pam demonsu ar program<~ç:\o de sockcLS paro TCP c UDP: L

Um cliente I~ um<~ linha a partir de sua entrada padrão ( teclado) e a envia :Hrovés de seu soeket para o ser"idor.

2.

O sen•idor I~

3.

O scn•ador converte a linha para letras maiúsculas.

4.

O servidor envia a linha modificada ao cliemc através de seu sockct de conexão.

5.

O chente I~ a lmha modaOcada através de seu socket c apresenta a hnha na sua (monitor).

11111:1

linha a partir de seu sockct de conexão.

Processo di ente

Figura 2.29 Socket cliente, socket de enlrodo e socket de conexão

Processo servidor

afda padrão


s~rvidor

(amada de

aplico~õo

119

Cliente

(Rodando em hostid Criar socket port-x. para requisição entrante: welcomeSocket = ServerSocketO

.-------~ Esperar por requisição de conexa o entrante

conf1guração de conex.lo TCP

Criar socket conectado a

hostid .port-x ciJentSocket Socket()

ler requisição de connectlonSocket

-

Enviar req uisição u~ndo clientSocket

j Escre11er resposta para connect1onSOCket

Ler resposta de chentSocket

Fechar conne
Fechar chentSocket

Figura 2.30 Aoplicoçõo dienttseMdor, usando ~os de transporte orienrodos ô conexõo i\ Figura 2.30 ilustra a principal atividade do cliente e do servidor re lacionada ao socket.

Em seguida, forneceremos o par de programas clicnlc·Servidor para uma implcmcntaç:lo da aplica41-1lo uli· liz.ando TCP. Aprcsemaremos também uma análise detalhada, linha a linha, após cada programa. O programa cliente seril deno milmdo TCPC 1 i en L. j a va e o programa servidor, TCPServer. Java. Para dar t nhsc às questões fundnmcntals, rorneceremos, lntcndonalrnente, uma codifica~ito objetiv.l, mas não tno 1'1 prova de rogo. Unta 'boa co
no logo os dois programas estejam compilados em seus respectivos hospedeiros. o programa servidor será primeiramen te executado no hospedeiro servidor, o que. criará nele um processo servidor. Como discUlldo anterlonncntc, o processo servidor espera paro ser contawdo por um processo cliente. Nesse exemplo de apl k~lç-.lo. quando o programa dicrnc ê executado. um processo é criado no cliente, c esse processo imediatamente contata o servidor c estabelece uma conc.xão TCP com ele. O usuá rio no clicmc pode então usar a aplicação para enviar uma linha e, em seguida, receber uma versão dessa linha em letras maiusculas.

TCPCiient.jovo Eis a codifi caÇ
import java . io.*: import java . net . *:

bow4tto4ic~ Redes de com pu tod ores e o Inle;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

class TCPCllent 1 publ ic static void main
I String sentence : Strlng modlf1edSentence : BufferedReader inF r omUser - new BufferedReader< new l nputStreamReader(System.in)); Socket clientSocket • new Socket("hostname·. 6789): OataOutputStream outToServer new OataOutputStream< clientSocket . getOutputStream()) : BufferedReader inFromServer new BufferedReader : System.out .pr intln( -FROM SERVER : - + modifiedSentence); c11entSoc ket . close<> :

O progroma TCPC11 ent cria trts cadeias e um socket, como mostrodo n:~ Figura 2.31. O socket é denominado cl ienLSocket. A cadeia lnFromUser é uma cadeia de e1Hr:1da paro o progroma ligada à entroda padnlo (isto é, o tecl:~do). Quando o usuário digi1a caroetcres no teclado, eles fluem paro dentro d:~ cadeia 1nFromUser. A ~".\dei a in FromSe rve r é outro cadeia de cntroda do programa ligada ao socket. Caroctercs que chegam da rC'dc fluem para dentro da cadeia i nFromServer. Finalmente. a cadeia out ToServer é uma cadeia de said:~ do progroma que t:~mbém é hg:~da ao soc kc1. Caracteres que o cliente e rw~a à red e fluem para dentro da cadeia outToServer.

Vamos agora examinar as vâria.s linhas da codillcação. lmport java.io. ~: import java.net. *: j a vil . 1o c j ava . n e t s:\o pacotes J:~ va. O paco te j a va . i o cont ~m classes para cadeias de c ntracl;~ e d c saida. Em particular, conttm as classes BufferedReader e DataOutputStrea m- classes que o 1>rograma usa para criar as tn'!s mdeias previamcmc ilustradas. O pacote java . ne t prov~ classes para suporte de rede. Em panicu· lar, co mém :1s classes Socket c ScrverSoc ket. O objeto cl ient Socket desse programa é clerh".:Hio da classe Socket. class TCPCllenL I publlc static void main(String argv[J) throws [xcept1on l. .. .... I

Att aqui, o que vimos é material padronizado que você vê no início da maioria das codíficaçõcs Java. A terceira linha é o começo de um bloco de definição de classe. A palavra-chave c 1 as s imeia a definição de classe para a classe denominada TCPC1 i ent. Uma classe comérn variáveis c m~todos, limitados pelas cha,rcs li que iniciam e encerram o bloco de dcfimção de classe. A classe TCPC 1 i en t não tem nenhuma variável de classe c possui exa· ta mente um método. em C e C++. Quando o interpretador Java executa uma aplicação (ao ser chamado pela classe de comrole da aplicação) , ele começa chamando o método ma in ( ) da classe. O método ma 1 n ( ) então chama todos os outros métodos exigidos para



12.1

07® Teclado

Monitor

Cadeia

t

Prcxesso

._

41

>

Cadeia

:;;

~ o

de S<~ida

.......c:

Cadeia de en1rada

dientSocket

l

Para

Socket TCP

Da

camada de camada de transporte transporte

Figura 2.31

TCPOienl tem llês codeios ollovés dos quais fluem cora
executar a aplicaç<\o. Para essa introduç.\o à programação de portas em ja\'a, \'OC~ pode rgnorar as palavras-chave publl c, stat I c, voi d, ma 1n c throws Except i ons (embora dc\'3 inclui-las no código). Strlng sentence: Strlng modlfíedSentence ; As duas linhas apresentadas acima declaram objetos do tipo Stri ng (t-adcla). O objeto sen tence ~ a cadeia digitada pelo usuário c crwíad:1 ao servidor. O objeto mod1 fi edSenlence ~a cadeia obud;~ do servidor c en vi;~da :\ s:lida padrão do usu:irio. BufferedReader infromUser • new BufferedReaderCnew lnputStreamReader
Socket cl ientSockel new Socket( "hostname" . 6789) : Essa linha cria o objeto c l lentSocket do tipo Socket. Ela também atív:l a conc~~:ão TCP entre cliente c servidor. A t11dcia I)Os L na me de\fe ser substituída pelo nome de hosprdeiro do servidor (por exemplo, a pp 1e . po 1y .edu). Antes de a conexão TCP ser realmente iniciada, o clicme realiza um procedimento de consulta ao ONS do nome de hospedeiro p:lf
bow4tto4ic~ 12.2.

Redes de compu tadores e o lnt;.;e.;.';;. ne;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Essas linhas criam objetos de cadela que são ligados ao socket. A cadeia outToServer fornece a saJda do processo para o socket. A cadeia i nfromServer fomcct! ao processo a emrada do socket (veja a Figurn 2.31). sentence - 1nFromUser.readLine<> : Essa linha colcx.-a urna linha digitada pelo usuário na cadeia sen tence. A cadeia semcncc continua a juntar caracteres até que o usuário tennine a linha digitando ·camage retunl'. A linha passa da entrada padr.lo para dentro da cadeia senlence por meio da cadeia i nFromuser. outToServer.wrlteBytes(sentence + '\n'): Esta hnha envia a etdcia sen lence para dentro da corrente ou t ToServer ampliada com um ·ca rri<~gc rctum'. A sentcnç;~ ampliada Ou i pelo soc:ket do cliente para dtntro da conexl\o TCP. O cliente então espera para receber carnctcrcs do servidor. modlfledSentence

tnFromServer.readLfne<> :

Quando chegam do servidor, os carnctcrcs nucrn a u-av~ da cadeia i nFromServer c s<10 colocndos dentro da cadeia mod i f i edSen t.ence. Continuam a se ;~cumular em mo di fi edSenter1ce até que a linh;~ termine com um c;~ractcrc de 'carringe return'. SyHem.ouL.prlnlln( " fRO~I

SERVER .. + modHiedSent.ence> :

Essa linha envia para o monitor a cadeia mod i fi edSen tence

retornad~•

pelo servid or.

clientSocket.close() : Essa última linha fcc:ll:l o sockct c, por conseguinte, a conexáo TCP entre o cliente c o servidor. Elu f:•z com que o TCP no cliente envie uma mensagem para o TCP no servidor (veja a Se~o 3.5).

TCPServer.java Agora \'llmos examinar o progrnma servidor. imporl java.io. • : fmport java.net.*: class TCPServer I publfc statlc void mafn(Strtng argv[)) throws Exceptfon I String clientSentence; String capitalizedSentence: ServerSocket welcomeSocket new ServerSocket (6789):

whlle: Bu f feredReader inFromCiienl new BufferedReader>>: OataOutputSt r eam outToClienl • new OataOutputStream< connectionSocket.get.OutputStream()) : clientSentence = ínFromCllent.readline(): capi t a1izedSentence clientSentence.toUpperCase() + ' \n ': outloClient.writeBytes


123

TCPServe r tem mui tas semelhanças com TCPCl i ent. Vamos agora da r uma olhada nas linhas em TCPServer. Java. 'olo comentaremos as linhas que são iMmicas ou semelhantes aos comandos em TCPCll ent. java. t\ prime1ra linha em TCPServer t: substancialmente diferente da que vimos em TCPC 1 i en L:

ServerSocket welcomeSocket

new ServerSocket(6789l :

Essa linha cria o objeto welcomesocket, que é do tipo ServerSocket. O we l comesocket é uma espécie de porta que fica ·ouvindo', :\ espera que algum cliente bata. O we 1comeSockel fica à escu ta na porta número 6789. A linha seguin te é: Socket connecLionSocket welcomeSocket.accept(): Essa linha cria um novo socket. d enominado connecti onSocket, q uando algum clieme bate a porta we I comeSockeL. O numero de porta desse socket tambt'tn é 6789. (Explicaremos por q ue ambos t ~ m o mesmo numero d e po rta no Capítulo 3). O TCP cntào estabelece uma conexão virtual direta e ntre c 11 en t Soe ke t no cliente c con nec Li onSoc ket no servidor. O cliente c o servidor podem cnt:io envhu b)•trs um para o outro pela conexao, e todos os bytes enviados chegam ao o utro lado na ord em cen a. Com connec tI onSoc ke t estabelecido, o serv idor pode continuar à escuta por OLtlros clientes que requisitarão a aplícaçlo usando we 1come Soe ket. (Essa vers;\o do J>rogmma, na verd ade.-, não fi("a à escuta por mais requisições d e conexuo, mas pode ser modifkacla com 1ilrcads para r:1ze r isso.) O progr:una então cria diversos objetos de cadeia, allltlogos nos objetos de cadeia em c I 1enLSocket. Considere agor.l: caplta li zedSentence • cl t entSentence .toUpperCase() t ' \n ': Esse comando é o coraç:lo da apli raçào. Ele toma a linha en viada pelo clien te, passa todas as lctms para mai úsculas c adiciona um ·carriagc rcturn'. Ele usa o método toUpperCase< ). Todos os omros comandos no p rogrnm:1 s.\o periféricos, usad os para a comunicaçào com o cliente. Para testa r o par de programas. instale c compile TCPCl i ent . java em um hospedeiro c TCPServer .j ava em o utro hospedei ro. Não se esqueça de íncluír o nome de hospedeiro do servidor adeq uado em TCPC11 ent. java. Então, execute TCPServer. cl ass, o programa servidor compilado, no serv1dor. Isso cria um procrsso no serv1dor q ue flca ocioso até ser com atado por algum cliente. Então. execute TCPCll ent. cl ass. o programa clien te comp1lado, no cl1entc. Isso cria um processo no cliente c estabelece uma conexão TCP en tre os processos cliente c servidor. Por fim, para usar a aplicação. digite uma sentcn\a seguida de u m 'carriage rcturrf. Para desenvolver sua própria aplicação cliente-servido r. você pode começar modificando ligeiramente os progrnmas. Por exemplo, em ,·ez de converter todas as leu·as p:1ra m:~illsculas, o servidor poderia contar o número de vezes q ue a lctm ·s· a pa rece no texto c retornar esse número.

2.8 Programação de aplicações com UDP Aprendemos na seç.1o anterior que, quando dois processos se comunicam por TCP, é como se houvesse uma tubul:wão rntre eles, q ue perma nece ati\'3 a té que um d os d ois processos a feche. Quando um dos processos quer enviar algu ns bytcs para o ouLro processo, simplesmente insere os bytcs 11 :1 tubu l a<;~\o. O processo de envio não tem ele acrcsccnt:.r um endereço de destino aos byLes porque a tu bulaç;\o ot:l lig~1d a logicamente ao dcsLíno. Além disso, a tub ulação prov~ um canal conrl:lvel de cadeia de by1es- a sequência de bytcs recebida pelo processo receptor é cx:uamentc a mesma que o remetcme inseriu na tubulação. O UOP tam bém permite que dois (ou mais) processos que rodam em hospedeiros diferentes se comuniquem. Contudo. é diferente do TCP de muilas maneiras fuJldruncntais. Primeiramente. é um scrvi~·o n:lo orientado para conex:lo- mlo h:l uma fase inicial de apresentaç-J.o, d urante a q ual é estabelecida uma tubulação ent re os dois processos. Como o UOP n:\o tem uma w bulaçâo, quando um p rocesso quer c1wiar um conj unto de bytt'S a outro, o processo remetente deve anexar o endereço do procrsso destinatário ao conJu nto de b)•tcs. E isso precisa ser feno p;1ra cada conj unto de bytcs que o processo remetente envmr. Como analogm. considere um grupo de 20 pessoas que to ma cinco láxis paro u m mesmo desti no: q uando cada um dos grupos entra em um carro. Lem d e informar separadamente ao motorista o endereço de destino. Assim, o UOP é semelhan te a um serviço de táxi. O endereço de destino é uma tupla que consiste no endereço IP do hosped eiro destinatário e no m1mcro ele porta do

bow4tto4ic~ Redes de computadores e o Internet processo destinatário. Vamos nos referir ao conjunto de bytes de informa~ilo, juntamente com o endereço IP do destimnáno e o numero de porta, como 'pacote'. O UDP provê um modelo de servrço não confiável oncntado para mensagem, no senudo de que faz o melhor esforço para emrcgar o conJunto de bytes ao desuno. Esses conjuntos são bytes etwiados em uma única operação na parte remetente, e serão emregues como um conjunto na parte desúnalária; isso contrasta com o sentido da cadeia de bytcs do TCP. O serviço UDP faz o melhor esforço já que o UDP não garante que o eonJUnto de bytes sem realmente entregue. O servtço UDP contrasta acentuadameme (em vários aspectos) com o modelo de sen·iço confiável de cadeia de bytes do TCP. Após ter criado um pacote. o processo remetente empurra-o para dentro da rede através de um socket. Continuando com nossa analogia do táxi, do outro lado do sockct remetente há um táxi esperando pelo pacote. Esse táxi. então, leva o pacote at~ seu endereço de destino. Contudo, n:lo garante que finalmente entregará o pacote no seu destino final , pois pode quebrar ou sofrer algum outro problema n:\o pre,•isto no caminho. Em outras palavras, o UDP pro\'t serviço ndo confidvd de transporte a seus processos de rom unim(ilo - não dá ncnhu~ ma garantia de que um datagrama ('pacote') alcançará seu destino final.

Nesta seçüo. ilustraremos program:tç-Jo de socket desenvolvendo novamente a mesma :~pllcaç;lo d:~ scç.1o anterior, mas, dessa vez, com UDP. Veremos que a codifica\.10 para UDP é dircrcntc da ~odíficnç:lo p:1rn TCP de muitas maneiras Importantes. Em p:utic ul:~r, (1) n;ío hâ aprcsent:~çflO inicial entre os dois processos c, portanto, nt\o h:l necessld:1dc de um sockct de entrada, (2) não há cadeias lig:1das aos sockc.-ts, (3) os hospedeiros remetentes criam pacotes anexando o endereço I? do destinatário c o numero de porta a '"''da conjunto de bytes q ue enviam c (4) o processo destinatário deve desmontar cad
1.

Um diemc lê ltma linhíl íl pílrlir de sua cmmda padr.lo (teclado) c a envia .uravés de seu sockc1 para o servidor.

2.

O servidor I~ uma linha a partir de seu sockeL.

3.

O servtdor converte a hnha para letras

4.

O scn•idor envia a linha modificada atravéS de seu socket ao cliente.

5.

O cliente I~ a lmha modi!ie:~da através de seu socket e apresenta a hnha em sua satda padrão (monitor).

m:~iúsculas.

A Figura 2.32 destac-J a principal atividade relacionada ao sockct realizada pelo cliente c pelo servidor, que se comunicam por meio de u m serviço de transporte (UDP) não orientado pam concx:\o.

UDPCiient.jovo Eis a codifit'llç:lo paro o lado cliente da aplicação: lmport

java.1o .~;

lmport javd.net .•: class UOPCllent I public static void main(String args[J> lhrows [xception l

BufferedReader inFromuser new 6ufferedReader: lnetAddress IPAddress lnetAddress .getByName( "hostname"): byte[J sendOata - new byte[l024]: byte[] receiveOata = new byte[l024): String sentence inFromuser .readLfne<>: sendData = sentence.getBytes() : OatagramPacket sendPacket =



125

new OatagramPacket(sendData. sendOala. l ength . IPAddress . 9876): cllentSocket.send : OatagramPacket receivePacket new Oa tagra mPacket
I

modifiedSentence> : cllent Soc ket.close () :

O programa UOPCl i enl. java constrói uma cadeia e um socket, como mostm a Figura 2.33. O sockct é denominado cl ientSocket e é do tipo OatagramSocket. Note que o UDP usa, no cliente, um tipo de sockeL dirercnte do usado no TCP. Em p:trticular, com UOP nosso cliente usa um Da tagramSoc ket. enquanto com TCP ele usou um Socket. A cadeia I nFromUser e uma cadela d e entrada parn o progmma; est:\ ltgada à entrada padrão. isto é. ao teclado. Tínhamos uma cadei3 equivalente em nossa vcrs;lo TCP do progmma. Q tmndo o usuário digita camctere:s no teclado, esses caracteres fluem para dentro da cadeia lnfromUser. Porém. ao contrário do TCP, nâo há cadci3S (d e entrada c de safda) lígad3S ao sockct. Em vez de alimentar b)'tCS à cadeia ligada a um obJeto Sockel. o UDP transmne pacotes individuais por meio do obJeto OatagramSocket.

5etvídor (Rodando em honid) Criar socket p;~ra requisiç~o

alente

port•x,

Criar socket

entrante:

Ler requlsiç3o de ••rvorSocket

Esaevcr resposta p;~ra ~orvorSockot

cllont!!ock< t DAtAgrum9ockot(l

-

Ctlar endereço port•x I

(ho~tid,

enviar requisiçto de dat~roma uS&do cllontSockot

1

e$peciflcando endereço

Lcr respos1a de

do hosP«teíro cliente

chont. ockot.

FeO •

Figura 2.32 Aaplicação dient~ervidor usando serviços de tmnsporte nõo orientados poro conexão

..


~ Teclado

Monitor

' cadeia de entrada Processo

Pacote de data grama

Pacote de data grama

UOP

UOP

Socket UOP

l

Para Da camada de camada de transporte vansporte

Figura 2.33 UOPCiienttem uma corrente; osocket oceito pocores do processo e enttego pocores oo processo t\gorn. vamos edclro destinatário. A linha apresentada invoca uma consulta ao DNS que traduz o nome do dcstin:m\rio (nesse exemplo, fornecido na codificação pelo programador) p:1ra um endereço IP. O DNS também foi chamado pela versão TCP do cliente, embora o tenha feito de m;mcira impliciH\, c nao explfcita. O método getByName<) toma como argumento o nome ele hospedeiro do servidor c reaorna o endereço IP desse mt>s mo servidor. Coloca esse endereço no objeto I PAddress do tipo I netAddress. byte(J sendData - new byte(1024]: byle(J recelveData - new byte[1024]: Os vetores de bytcs sendO a ta c recei veDa ta rctcr.lo os d;ldos que o cliente emia c recebe, rcspecli,~lmcntc . sendData • sentence.getBytes(); Essa linha rcalíza. essencialmente. uma convcrs.1o de tipo. Pega a cadeia scntencc c a renomeia como sendDa ta. que é um vetor de b)•tcs. OatagramPacket sendPackel new DatagramPacket( sendOata , sendOata .length. JPAddress . 9876) ;


Camada de aplicasõo

____12.7........

Essa linha constrói o pacote, sendPacket, que o cliente enviará parn a rede atrnvc!s do seu socket. Esse pacote inclui os dados contidos nele, sendDa ta. o comprimemo desses dados. o endereço IP do servidor c o n(lmero de porta da aphcaçào (escolhemos 9876). Note que sendPacket é do tipo OatagramPacket. cllentSocket.send : Nessa linha. o mc!todo send() do objeto cl ientSocket toma o pacote recém-constrllldo c passa-o para a rede atravcs de cllentSocket. Mais uma ''ez. note que o UDP envia a linha de caracteres de maneira muito dircrente do TCP. O TCP s implesmente inseriu a linha de caracteres em uma cadeia que unha urnJ conexão lógica djreta com o servidor: o UDP cria um pacote que inclui o endereço do servidor. Após enviar esse pacote, o cliente espera para receber urn pacote do servidor. DatagramPacket recelvePacket new DatagramPacket
O dicnte ficu ocioso ate! receber urn

pa~:ote;

qu:lndo enfim o recebe, ele o

colo~-:1

em recei vePacket.

Strlng modifiedSentencenew String(receivePacket.getData()) ; Essa linha extrai os dados de recei vePacket e reali~a uma conversão de tipo, convertendo b)•tcs na cadeia modi r; edSentence. System.out.printlnc-rROH SERVER: - • modifiedSentence>:

Lml

vetor de

Essa linha, que também est~ presente no TCPCl ient. apresenta :• t-adeia modi fledSentence no monitor do chcntc. cllentSocket.close(): Essa í•ltima linha fecha o sockct. Como o UOP nào é orientado para conex;lo, cstõ\ lmha nao raz com que o cliente envie uma mensagem de camada de transporte ao servidor (ao contr:lrio do TCPCll ent).

UDPServer.jovo Vumos agora dar uma olhada no lado servidor da aplicaçJo: import java.io.A: fmport java.net. •: class UOPServer I pvbllc statlc void mainCString args[]) throws Except1on

I OatagramSocket serverSocket = new oatagramSocketC9876>: byte[J receiveData = new byte[l024) : byte[J sendOata new byte[t024l: wh 11 e ( trve) I OatagramPacket receivePacket new OatagramPacket>:

InetAddress IPAddress receivePacket.getAddress() :

bow4tto4ic~ Redes de computadores e a Inle ;.; rn;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

int port- receivePacket .getPort() : Strlng capltal1zedSentence • sen t ence .toUpperCase<>: sendData - capi talizedSentence . getBytes(): OatagramPacket sendPacket • new Oa tag ra mPacket (sendOata . sendOata.length . IPAddress . port> : serverSocket.send
O programa UDPServer .j ava cons trói um socket, como mostra a Figura 2.34. O socket é denominado servcr Sockel. I! um objeto do ti po OatagramSocke t , como era o sockct do lado cliente da aplic;~çâo. Mais uma vez, nenhuma t"ttdeia esu.\ ligada ao socke1. Va mos <~gora examinar os línhas da codificação que são direrenti?S de TCPScrvcr .java . DatagramSocket serverSockel • new DatagramSocket (9876) : Essa Iin h:-~ constrói o Da LagramSockel servet Soc keL na porta 9876. Todos os dados enviados c recebidos passar~o através desse socke1. Como o UDP não é orientado para concxào, nào temos de criar um no,•o sockct c

continuar à escu ta de novas requisições d e conex>: lnetAddress IPAddress - receivePacket . getAddressCl: lnt pott recelvePacket . getPort() :

[ssas trl!s linh desmontam o pacol<~ que chega do cliente. A primeira delas extrai os dados do pacote c os coloca no Stri ng sentence: há u ma linha análoga em UOPCl i ent. A segunda línha extrai o endereço IP. A terceira hnha extr.li o numero d e porta do cliente, que é escol hido pelo cliente e é diferente do número de pona 9876 do scrv~dor. (Discutiremos números de pona do clic:m e com mais detalhes no capitulo seguinte.) É neccSS<'lrio que o servidor obten ha o endereço (endereço IP c numero de porta) do cliente para que possa enviar a se ntença em letras mahlsculas d e volta para ele.

Procaso Pacote de

Pacote de datagrama

datagrama UOP

UDP

serverSocket

Sodcet UOP

Porta 9876 Para

Da

camada de

camada de

transporte

transporte

Figura 2.34 UDPServer nõo tem Codeios; osocket aceito pacotes do proce~o e entrego pacotes oo processo


Camada de

opli'o ~õo

Isso conclui nossa análise sobre o par de programas UDP. Para testar a :~plit':l~-;\o, instale c compile UDPCl i en t. Java em um hospedeiro c UDPServer. java rm outro. (Nilo esqueça de incl uir o nome apropriado do hospedeiro do servidor em UOPCl fent.java.) Em seguida, execute os dois programas em seus respccuvos hospedeiros. Ao contrário do TCP. você pode executar primeiramente o lado cliente c depois o lado SCI'\idor. Isso acontece porque, quando você executa o programa cliente, o processo cliente mio tenta iniciar uma conexão com o servidor. Assim que tiver executado os programas cliente e sel'\'idor. voe~ poderá usar a aplic-.1~-.10 digitando uma linha no cliente.

2.9 Resumo Neste capítulo, est udamos os aspectos conceituais c os aspectos de implcmcrllaç;io de aplicações de rede. Conhecemos a onipresen te arquitetura clientc·Sel'\'idor ado tada por aplicações ela Internet c C.IC:uninamos sua utilizaÇ1iO nos protocolos I ITTP, FTP. S MTP, POP3 c D S. Anal isarnos esses Importantes pro tocolos de t'Mlada d e ;lpli<.'aç;lo c suas aplic:~ções associadas (Web, trnnsrerencia de arquivos, c-rnail c DNS) com algu m detalhe. Con hecemos també m a arquitetura P2P, cada vez mais dominante, e examinamos sua ut ilizaç:\ o em muitas aplicações. Vimos como o API soc ket pode ser usado para construir aplicações ele rede. Exmnina rn os a u1ilizac;l\o d e portas p:~m se rvr ços de lmnsporte a fim orientados para co nexão (TCP) e não orientados para conex:lo (UDP) c tamb~m const ru fmos um servidor Wcb simples usando sockctS. t\ primeira etapa de nossa jornada de descida pela arquitetura das camadas da rede está concluida1

nm

Logo no começo deste li vro. na Scçi\o l.l, demos uma dcflniçào um tanto \oaga e despojada de um protocolo. Dissemos que um protocolo é 'o formato e a ordem das mens:,gens trocadas entre duas ou mais entidades comu nicantes, bem co rno as ações realizadas na lmnsmlss:lo e/ou no recebimento de uma mer\S.1gem ou outro eve nto'. O material deste capitulo - em particular. o estudo detalhado dos protocolos HTTP. FTP, SMTP, POP3 c DNS- agregou conslderá,•el subst.\ncia a essa definiç:io. Protocolos são o conceito fundamental de redes. 'osso estudo sobre protocolos de :~plicaç-Jo nos deu agora a oportunidade de desenvolve r uma noç;lo mais intuitiva do que tles realmente s:\o. Na Scç:'lo 2. 1, d escreve mos os modelos de serviço que o TCP e o UDP orcrccern às aplicações qu e os chamam. Examinamos esses modelos de serviço ainda mais de perto quando desenvolvemos, nas seções 2.7 e 2.8, aplicações simples q ue executam em TCP e UOP. Contudo, pouco dissemos sobre como o TCP e o UDP fornecem esses modelos de servtços. Por exemplo, sabemos que o TCP provl' um SCI'\•rço de dados conOá\'el, mas ainda nao mencionamos como ele o faz. No próximo c.apftulo, exami naremos cuidad osamente n;\o apenas o que s;\o protocolos de tran sporte, mas també m o como e o porquê deles. Agora que conhece mos a estrulUra da aplicaç-Jo da Internet c os protocolos de ca mad:1 de aplicaç;io, estamos pron tos para continuar a descer a pilha d e protocolos e examinar a camada de transporte no Úl pllulo 3.

Exercícios de fixocõo . Capítulo 2Questões de revisõo ~õo 2.1

1.

Rclacronc cinco aplicações d:t Internet m\o proprie· tarias e os protocolos de camada de aplicação que elas usam.

2.

Qual é a dtfcrc:nça cnrrc arquitetura de rede c arquire· tura de :tplieaçâo?

3.

Para urna sessão de comumcação enrrc um par de processos, qual processo é o cliente c qual é o servidor?

4.

Em urna aplicaç.lo de comparlllhamcnto de arqui· vos P2P, voe~ concorda com a al'innação: "não existe nenhuma noç:'lo de lados cliente c servidor de uma SCS· slo de comunicaçâo"? Por quê?

5.

Que inforrnaçâo

e uS3d:t por um procCSMJ

t jUC CSL:l

rodando em um hospcdCifo para tdenti!icar um processo que está rodando em out ro hospedeiro?

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r n;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

6.

Suponha que vocc queria fazer uma transação de um clleme remoto p:~ra um ser,1dor d:~ m:mcira lll3\s r.tpi· da (>OSSI\'el. Voe~ usaria o UDP ou o TCP? l"or quN

18. Da perspccti\'a de um usu:lrlo. qual c a diferença entre o modo ler-1:-apagar c o modo ler·e·guardar no POP3>

7.

Com rcfer~ncia i Figura 2.-f , vemos que nenhuma das aphcações relacionadas nela requer 'sem perda de dados' c 'tcmporizaç:lo'. Você consegue imaginar uma aplic:tçilo que requeira ·sem perda de dados' c seja 1amb<:m ahamemc sensível ao atraso?

19.

8.

Rclac1one quatro classes de serviços que um proto· colo de transpone pode prover. Para Cllda uma delas. indique se o UDP ou o TCI" (ou ambos) fornece tal scrvko.

9.

Lcml.lre-se de que o TCP 1>ode ser aprimomdo com o SSL para fumecer scrvicos de segurança processo a prncesso, incluindo a deeodincaçilo. O SSL opera na camado de tmnsporte (lU m1 cnmncJa de aplicação? Se o desenvolvedor da aplicaç:lo quer que o TCP seja aprimorado com o SSL. o que ele deve fazer?

~~2.2o

2.5

10. O que significa protOl"
1.5. Por que se diz que o FTP envia infonnaçõcs de con· trole 'fora da banda'? 16. Suponha que r\llce envie um:\ mensagem a Bob fJOr meio de um;• conta de e-mail da Web (como o Hotmail). c que Bub acesse seu c-mail por seu servi· dor de correio 11S.1ndo POP3. Ocscro:va como a mensagem v;~ i do hospedeiro de: Alice até o hospedeiro de Bob. Nilo se esqueça de relacionar a série de protoco· lo:. de C:~mada de alllkaç;\o usados para movimentar a mensa!!em entre os dois hospedeiros. 17. Imprima o cabecalho de uma mensagem de e-mail que acabou de receber. Quantas linhas de cabeçalho Recei ved: há nela? Analise cada uma das linhas.

1: possível que o scf\~dor Web c o sef\'idor de correio de: uma argamzaç;lo tenham cx:tt:~mcnlc o mesmo apchdo para um nome de hospedeiro (por C.'l:cmplo, f oo . com)? Qual scn~ o upo de RR que contém o nome de hospedeiro do sef\1dor de correio?

Seção 2.6 20. No BitTorrcnt, suponha ara enviar. Então, como Alice uhtcrá seu pri meiro hloco? 22. O que é uma n:de de sobreposição em um sistema de compartilhamen to de arquivt)S P2P? Ela inclui roteadores? O que s.lo as arestas d:t rede de sobreposic':lo? Como n rede de sobrcposiç-Jo de inundação de consultas c criada c como é mantida? 23. De que modo a apliC:~ç;lo me1\Sagem inst:tnlimca c um hibrido das arquueturas clicnte·servidor e P2P? 24. Considere um DHT com uma toJ>ologia da rede de sobreposiç-Jo (ou seja, cada par rastreia todos os pnrcs no sistema) Quais s.'\o as vantagens c dcsvanta· gens de um DHT circular (sem atalhvs)? 25. O Sk)•pc llliliz:~ técnicas P2P para duas funções importan tes. Quais são elas? 26. Rclndone qu.11ro difcrc:ntcsaphc::,ções que s.'lo :~propriadas natur:11111en te para arquitetums 1,21'. (Dim: DiStribuiÇào ele arqui"o c mensagem instant:lnca são duas.)

Seções 2.7-2.8 2.7. O M:rviclor UDP descrito n<~ Scc::lo 2.8 prccbav;1 de uma porta at}Cnas. tiO 1>asso que o scf\•idor TCP descrito na Seç:lo 2.7 prcds.l\'a de duas portas. Por quê? Se um servidor TCP tivesse de suportar n conexões s1muh~ocas. C:~da uma de um hospedeiro cliente diferente. de quantas portas precisaria? 28. Para a aplicação cliente·sc:rvidor por TCP descrita na Scç:\o 2.7. por que Para a aplica· ç;lo clicntc·scf\•ldur pm UDP dcscnta na Scç.to 2.8. por que o programa cliente pode ser executado ames do programa servidor?


(amada de

aplico~õo

131

Problemas 1.

Falso ou vcrdade1ro? 300<7f>Connect1on:keep·allve

a. Um usuáno reqU1si1A uma página \Veb que conSISic em 1ex1o c 1rês imagens. Para essa p.igina. o chenle em iará uma mensagem de requisição e receberá qu.uro mcn:.agens de resposta. b. Duas páginas Web distintas (por exemplo. www. mit . edu/research .html e ww1·1.m1t .edu/ s l udents.html) podem ser enviadas pela mesma conexão pcrsistcmc.

< 1f>< 1f> a. Qual c a URL do documento requisitado pelo

browscr? b. Qual vcrs.lo do Hrl P o browscr c:slá rodando?

c. O browscr requisita uma concx:\<> n:\o persistente

ou pcrslstemc? d. Qual ê o cnclercc;o IP
c. Com conexões n:lo persistentes entre browscr c scrv1dor de origem. ~ ()()ss!vcl que um único segmento TCP transpo rte duns mensagens distJntas de rcqulsiç;to HTTP.

browscr cs t:l rodando? c. Que Lipo de browscr inicia CSSII mensagem? Po r que é necessário o tipo de bmwscr em uma mensagem de rc
d . O c:•hccnlho Oa te: n'' 111CI1Sagcm de resposta

HTIP indíc;~ a 11hlma vez: que o objeto da res· posta rOl modificado. e. As mensagens de rcspos1a HTTP ntmca possuem um corpo de mcns.1gem vazio. 2.

Le"' o RFC 959 I"'~"" FTP. Rclac1onc todos os com:mdos de cliente que S
3.

Considere um clicn1e IITTP que queir:t oh1er um documento Wcb em um dado URL Inicialmente, o endereço IP do se1vidor 1-JTTP é desconhecido. Nesse cenário. qua1s prt>locolos de transporte c de camada de nplicac.\o :>.lo ncccss.irios. alem do HTTP?

...

Considere a scgumtc cadcm de carnctercs ASCII C:IJlturada J>elo Wtrcshark ttuando o browscr c;nviou uma mcns.-.gcm IITTP CET (ou seja. o comeúdo real de uma mensagem HTIP GET). Os carac1ercs s.-\o retorno de carro c avanço de linha (ou seja. a cadeia de caracter em i1álico no texto abaixo representa o caracter unico retomo de c.'lrro que estava cmuido, naquele momento, no cabeçalho HTTr). Responda as seguintes questões, indicando onde csui :1 rcsposw na 111ens.1gcm H'ITP CET abaixo. GET /cs 453/1ndex.html HTTP / 1.1 Host : gaia . cs .uma ss. ed u< I f>User 1\gent: Mozi- lla/ S.O ( Wi ndows : U: Windows NT S.l : en US: rv:1.7.2) Gec ko/20040804 Netscape/7.2 Accept:ex t/xml. appllcation/xml . application/xhtml+xml. text/html :•q•O . w9. text./plc~ln:q-0.8. image/ png .• t -: q•O.S <1f>Accept Language: en-us . en :q•O . SAccept-Encodi ng: zl p. de f I ate< cr>< I f>Accept -Charset : ISO -8859- 1 . utf8 ;q=0.7 . *;q•O. l Keep·Alive :

5.

O texto a seguir mos1ra a rCSJ>osta enviada do servidor em rcac;âc> a mcnS<1f>Da te:Tue. 07 Har 2008 12:39 :4 5G HT Server : Apache/2.0 . 52 (Fedora) < 1f>Last· Hodi f1ed: Sat . 10 Dec2005 18:27:46 GIHETag: -·s26c3- f22- a88a4c80" < 1f>Accept • Ranges: bytes< 1f>Content- Length : 3874Keep Allve:tlmeout•max 100 < 1f>Connect i on : Keep· A1 i ve< 1f> Content Type: text/html: charset ISO 8859 ·1 < 1f>< 1 f>< I f>< 1f>< 1f> <meta http·equlv "Content - Type "content ootext/h tml: charsel iso-8859-1 "><1() <meta> name•"GCNCRATOR" content• "t1ozi 11 a/4. 79 [en] ( W1ndows NT S.O: U) ttetscapeJ "> OIPSCI 453 I 59 L I IHU · STSSOA Spring 2005 homepage< 1f>
a. O servidor roi capaz de encontrar o documento com sucesso ou n.lo? A que horas fo1 aprcscntnda a resposta do dc1eumcnto? b. Quando o documento roi modificado pela última \'eZ:? c. Quan10s bytcs existem no documen10 que CSiâ retornando?

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne;.;t________________________....._

6.

d. Quais s.-to os 5 primeiros byu:s do documento que o.:st.l rctorn~ndo? O scr"dor aceitou uma concx.lo 1~ rstS te ntc? Obtenha a especlfica<;ão HTIP/1.1 (RFC 2616). Responda às seguintes pergumas: a . E"-plique o mccamsrno de slnalizaç:lo que cliente

e sen •dor utiliurn para indicar que urna conex.lo persistente está sendo fechada. O cliente, o scn·i· dor, ou ambos. podem si nalizar o encerramemo de uma conexão?

b. Que sen•icos de criptografia são providos pelo HITP? c.

O clicnto.: c capaz de abrir trlls ou mais co nexões simuh:\nt·as co m um dctcnn inado scn~dor?

d. Um servidor ou nm cliente pode abrir uma conexO.o de transporte entre eles se urn elos cloís descobrir que a eoncxf\o ficou lenta por um tcmfXl. ~ posslvcl que un1 lado comece a cncer· rara concxM cn<1uanto o o utro está transmitindo dados por mcitl dc.s53 con cxào~ Explique. 7.

8.

Suponha que voct: dique com seu browser Web sobre um pontclro p:~rn obter uma página Web c q ue o endcreco IP para o URL associado nJo esteja n<> cache de seu hospedeiro local. Ponanto. será nccess:lna um:1 consuh:1 ao DNS para obte r o endcreco IJ>. Considere que n servidores DNS sejam visitados antes que seu hospedeiro receba o endereco I P do DNS; as visitas Sl•ccssh'liS incorrem em um RTT •gual a RTI1 • •• , RTI•. Suponha ainda que a pág•na Wcb associada ao pon tcíro contenha exatamente um objeto que e1msiste em uma pequena quantidade de texto HTML. Scjo RTI0 o RTI entre o hospedeiro local c o servidor que contém o objeto. Admitindo que o tempo de trans missão do objeto seja zero, quan to tempo p;tssan\ desde que o cliente ciica o pontelm :I tê c1ue receba o obj eto? Com rdcrencin ao problema 7. su r>on ha que o arquivo i ITML refercncie três objetos muito pequenos no mcsm<> scn•idor. Desprczandc> tempos de transmiss;lo, quamo tcmt>o passa. us.'lndo-se: a . I tTTP na o persistente sem Cc)nexocs TCP

paralelas? b. HITP n3o persistente com o browscr configurado para 5 conexões paralelas? c. HITP persistente? 9.

COJlSidere a Figura 2. 12, que mostro uma rede insli· tucional coneewda ,\ Interne t. Suponha que o lama· nho m~d10 do objeto seja 850 mil bits c que a taxa média de requ•stç:'lo dos browsers da instituição aos sen tdores de origem seja 1.6 rcqu•siçào por scgun· do. Suponha também que a quantidade de tempo que leva desde o instante em que o roteador do lado da

Internet do enlace de acesso transmite uma rcquisicJo HTIP :ttc que receba :1 resposta seja 3 segundos em média ('·cja Seção 2.2.5 ) Modele o tempo total mt.>dio de resposta corno a soma do atraso de acesso mcdio (asto t. o atraso entre o roteador d:~ Internet c o rotC;tdor da •nstuutçâo) c o tempo medto de atraso da Lntemct. Paro a m~'
m~dio

de rCSJXISla.

b. Agora, ~'Ons•dcrc que um cac he é mst:r lndo na l..t\N mstituc•
I O. Considere um cnh1cc c urto de IO metros atnwcs do qual um rcmet~rlle pode tr:~nsmltl r li umu taxa de 150 bits/sem ambas as direções. Suponha q ue os pacotes com d:1dos tenham 100 mil bits de comprime nto. c os p<~C:Oh!S que Ctlnt~m cou tmle (ptlr exemplo. ACK ou Uj) rcsentaçào) ten ham 200 h11s de comprimento. Admita que N conexões parale las recebam cada 1/N da largura d e banda do e nlace. Agora, considere o protocolo HTIP c sup\mha que cada objeto baixad(l tenha 100 Kbits de comprimen to c que o objeto in icial baixado con tenha 10 objetos rdcrcnciados do mesmo remetente Os downloads paralelos por meio de instlnclas paralelas de IITIP não persistente fazem senudo nesse caso? Agora considere o t-ITTP persistente. Você espera ganhos signiflcath·os sobre o caso não persistente? justifique sua resf>OSt:l. 11. Considere o cenário apresentado na questão ante·

rior. Agora suponha que o enlace ~ compartilhado por 13ob e mais quatro usuários. Boh u~ ir\Stâncias paralelas de IITTP n:\o persistente, e os outros quatro usuários usam HTffl não persistente sem downloads paralelos.

a. As concxt"H!S paralelas de Dob o ajudam a acc.~r páginas Wcb mnis rapidamente? Por que? Por que nOà? b. Se cinco usuários abrirem cinco ii\Stanclas paraie· I:IS ele HTIP n ~o l>crsistcntc, então as conexc'cs paralelas ele Boh ainda seria m tlteis? Por quê? Por que não?

12. fs(reva um programa TCP sim ples t>aro um se rvido r que aceite linha~ de entrada d e um cliente c envie as linhas para a sarda padr-.lo do servidor. (Você pode faze r isso modificando o programa TCPScn·cr.java no texto.) Compile c execute ~cu programa. Em qualquer outra m:\quma que contenha um browscr Wcb. defina o scn••dor prOl\'}' no browser para a m:lquina que está execumndo seu programa servidor e também configure o número de porta adequadamente. Seu browser deverá agora enviar suas mensa-


gcns de rcqulslç;\o GET a seu scn•ldor. c este deverá aprcsentor as mcns:\gens em su:1 safd3 p.1drJo. Use essa plataforma para determinar se seu browscr gera mensagens GET ct~r~dicion:~is p:~ra objetos que estão em caches loca1s.

13. Qual é a d1fercnça entre MA I L FROM: em SMTP c FRON: na mens.1gcm de correio? 14.

Como o S~TP marca o final de um corpo de mcnsagcm1 E o HTTP? O HTTP pode usar o mesmo método que o SMTP para m:trc:~r o flm de um corpo de mensagem? Explique.

15. Leia o RFC 5321 para SMTP. O que signírica MTA? Considere a seguinte mensagem spam recebida (modificnda de um SJ):IIll vercladeii'O). 1\dmitindo ttuc o cri:.dor desse sp:un seja malicioso c que os hos· pcdeiros scjmn honestos, identifiqu e o hospedeiro m:1li cioso q ue c riou essa mens:~gcm spam.

From · Frl Nov 07 13:41:30 2008 ReLurn·Path: [email protected] Received: from barmall.cs.umass.edu ( barma 11 .cs .umass. edu [ 128.119.240. 3)) by cs.umass.edu (8.13.1/8.12.6> for [email protected]: Fri. 7 nov 2008 13:27:10 -0500 Received: from asusus · 4b96 : Fri. 7 r~ov 2008 13:27: 07 ·0500 Receíved: from asusus·4b96 ([58.88.21.177)) by barma1t.cs.umass.edu for : rrl 07 Hov 2008 13:27:07 ·0500 ([ST> Rece1ved: from (58 .88.21.177] by lnb~dSS.exchangeddd.com: Sat. 8 Nov 2008 01:27:07 +0700 From : ··Jonny ·· To: Subject : How to secure your savings o

16. Lcin o RFC do POP3 ( RFC 19391. Qual é a finalidade do com.tndo UI DL do POP3? 17. Cons1dere accss.1r seu c-mail com POP3.

a. Suponha que voct configure seu cliente de ror· reio POP par.1 funcionar no modo ler-e-apagar.

Conclua a seguinte tmns.1ção: C: list. s: 1 498

S: 2 912 S:


133

C: retr I S: blah blah S: .......... blah

S: ? ? b. Suponha que voei! configure seu cliente de cor· rc10 POP para funcionar no modo ler-c·gttardar. Conclua a seguinte trnnsação:

C: I isl S: 1 498 S: 2 912

S: C: reLr 1

S: blah bl ah S: .......... blah

S: ? ? c. Suponha que você configure seu clicme de correio POP para funcion;~r no modo ler-c-guardar. Us.1ntlo sua soluçlo n:~ p.~rtc: (b). suponha que você rccuJ>~:rc as mensagens I e 2, saia do POP c então. 5 minutos mais tarde. acesse novamente o POP para obter um novo c-mail. Imagine que nenhuma outra mcns.1gcm foi cnvi:tda nesse intcnalo. Elnbon: um transcript dessa segunda sess.\o POP.

18. a. O que é um banco de dados "hc11
servidor DNS h'cJI c os tlois servidores DNS (IUC encontrou na pane (b). Tente etmsuhnr registros dos tipos A, NS c MX. Faça um res umo do que

cncc>rllrou. d. Use nslookur> pam cnetmtmr um scr.•idor Web que tenha vários endereços 11'. O servidor Web de empresa) tem v:lrios endereços IP1 e. Use o banco de dados whois ARIN para determín;~r a raixa de endereços Ir> usados por sua universidade. C. Dcscrc,·a como um mvasor pode usar bancos de dados whois c a ferramenta nslookup para fazer o reconhecimento de uma institui<;;lo anlt$ de lan\-nr um ataque su:~ instituição (csco l t~ ou

g. Discuta por que bancos de dados whois devem estar disponlveis publicamente.

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....19. Neste problema. u1illz.1mos a fcrr.uncma funcional dig dtsptmí,'Cl em hospedeiros Unix c Unux parn explor:tr a luerarqma dos scMdorcs DNS. Lembre de que, na Figum 2 21 . um Sél"'idor 0'15 de nhcl superiOr na hícr:trquta do DNS dek-ga uma consulta DNS p.1m um 51::1"\idor DNS de nh cl inferior na hier:trquia enviando de ' 'oha ao clicme DNS o nome daquele servidor DNS de nível Inferior. Em primeiro lugar. leia a mtm p
.H. Considere distribuir um arquivo de F bits para N

b. Rcpll:1 o hem "rt" com ' 'ários sitcs da Internet populares, como googlc.C{lln, y~hoo.com ou alllUZOn.co 11\,

vos, sendo que c.ld:t dupla de pares t>ossu:t urn:l cone· x~o l 'CI'. Além diSS<>, Sllll4.>nha cs TCP passem por um total de M rotc.1clorcs. Qunmos nós c arestus h:l na rede de sobreposição correspondente?

20. Supon ha que \!OCC consiga acessar os cachcs nos scr,~dorcs DNS locais do seu departamento. Você é capaz de propor uma maneira de determinar, em linhJS gemi~. os servidor~ Wcb (fom de seu dcparta· mcnto) que s.\o nnts populares entre os usuários do seu departamento? Explíquc. 2 1. Suponha
N pares. O servidor possui um taxa ele upload de u, • 30 Mbps c cada par possui Ull\3 taxa de download de cJ, • 2 Mhps e uma taxa de up load de u. Para N • 10, 100 c 1.000 cu • .300 Kbps. 700 Kbps e 2 Mbps, fli'Cilarc um ~rllfico aprcscmando u 1cmpo mfnimo de dlstribuiç:lo pam caoo uma
23. Considere distribuir um arqul\'0 de F bits l>:tr..t N p:tres

uúliz.ando uma arquilctum clicnle·servidor. Admit:l um modelo Oui
pares utiliundo uma arquitetura P2P. Admita um modelo Otud<) c que d_ c muuo gmnde. de modo que a largum de banda
um esquema de dtslribuiç;lo que possua o temi>O de tlislrthuicao de f/u, b. SupO de distnbuiç:lo de NF/(u, + 11 1 + ... + u,). e. Conclua t1uc tl tempo mínimo de distribuiç:lo é, geralmente, dado por m:uc If/11,. Nf/(u, + 111 + ... + u,) }. 15. C<1 nsidcre 1.1 ma rede de sohrcposic;!l
26. SUJIQnha que Bob Lcnh•• emmclo no llitTorrem, mas

ele nflo quer razcr o upload de nenhum dado para qualquer outro par (denominado carona). a. Bob alega que consegue receber uma cópia completa do arcrutvo companilh:tdo pelo gm1>0. A alegaç~o de llob e possh el? Por quê? carona~ de um modo ma•s cf'icicntc usando um conjumo de diversos computadores (com endereços IP dislln· tos) no laoomtório de informática de seu depafla· mento. Como ele lxxlC razer ISSO?

b. lklb alega que ele pode • pegar

21. Ncs1e problema.
um sistema de companilhamcnlO ele arquivo P2P semelhante ao Bi1Torren1. Considere dtliS 1>arcs, Bob c Alice. Eles emram em um torrem com M 1><~rcs no total (incluindo Bob c Alice) c1ue estão compartilh:~ndo um orquh•o que consiste em N blocos. Admita que em um tem1>0 cspcclrico r. os blocM que um 11ar ll4.>SSui Ss os N blocos. e nenhum par possui todos os N blocos. Responda às seguimcs questões: a. Qual é a probabilidade de 13ob ter todos os blocos de t\lice. s:~bcndo queM numeros de blocos que lklb c r\ Iice tem são representados por 11~ c "·? b. Remm•a parte do conthcionamento do item "a~ p:tra descobrir a prolxtbilidadc de &b ter os mcs· mos blocos de Alice, s:~bcndo que Alícc possui n blocos.

•

c. Suponha que cada par no BitTorrcnt tenha 5 vizi· nho!t. Qu:~l é .1 probabthdadc de Oob ter dados que sejam de imeressc de pelo menos um dos cinco vizinhos?


30. Considere um DH I circular com identiOcadores de nos e de cha,·c na faixa lO, 63) . Suponha que haja oito pares com identificadores O, 8, 16, 24, 32, 40, 4Se 56.

a. Supon ha que cada t>nr possa ter um j'ar no atalho. Para cada um dos oito atalhos. dctenninc seu par no ntalhn para que o número de mensagens c • wla
b . Repita o item "a", mas permita que cada p.u ten ha do1S pares no ata lho.

33. Como os DHTs slo redes de subreposiç;lo. eles n11o se adequam necessariamente bem a rede riSica de sobreJ>oStÇ';lo no scnudo de que d01s pares viZinhos podem cstM fisicamctlle muito distantes: por exemplo. um par poderia estar na Ásia c seu vizinho, na t\m~rka do Norte. Se atrib11irmos idcmificatlorcs aleatória c unlrtlrmwtcntc tlara paro.:s rcccm-unldos, css.:: esq uema de atribuiç:lo causan;1 essa incompalibilid;~dc? Explique. E como tal incompatibilidade afetaria o desempenho do DHT7

34. Insta le c compile os pro~ramas Jnvn TCPCiient c UDPCI Icnt ern um huspcdclrt' c TCPScrvcr c UDPScrvcr em outro.

31. Como um mlmero In teiro em 10.2• - I I pode ser expresso como um número bin:lrio de n bit em um DHT. c;~dn ch;wc pode ser expressa como h • Ck, h1• .... k. ,). c cada idcmific~dor de par pode ser e."0, p., ... , P. ,). Vamos. agora. dcllnir a distlncla XOR entre a chave k e o par p como

·-·,.u

d(k. P> • ~ I k1 - p1 12'

135

oplico~õo

em•\o US3mos a métrica do problema anterior para criar um DHT (com 2 subsutuido b). Compare esse DHT baseado nos numcros de base b com o DIIT baseado nos números binários. Na p1or das hipóteses. qual DHT gera mais mensagens por consuha1 Por qu~?

28. No exemplo de DHT circular na Seç.lo 2.6.2. suponha que o par 3 dcscobnu que o par 5 saiu. Como o par 3 alllaliza lnfonnacõcs sobre 11 cs1~1do de seu sucessor? 29. No cxcm1>lo de DliT circular na ScçAo 2.6.2. suponha que um novo par 6 queira cmrar no OHT. sabendo. inicialmente. o endereço IP do par 15. Qua1s p.'IMOS s;tn tomado~?

(omodo de

a. Supo nha que você execut e TCPCiicnt antes de executar TCPServcr. O que acontece? Por quê?

b. lmagmc que nx:ê execute UDI'Ciicm antes de UDPServer. O que acontece? Por que? c. O que ;tcontecc se voe~ usar números de porta diferemcs pam os lados cliemc c scrYidor? 3S. Suponha que. em UDPCiient.j:l\'3, a linha

Oat ag ramSocket cl1 ent Socket OatagramSoc ket < >:

Dcscrc''õl como essa mctrica pode ser usada para determmar duplas (chave. valor) para pares. (Pam aprender mais sobre como consmur um DIIT efic•entc ~ndo essa métrica n:uural, consuhc IMa)'mounkov, 20021, no qual o OHT Kadcmlia ê descrito.)

new

seja substitmda por

OatagramSocket cli entSoc ket • new OatagramSoc ket (5432) : Será necessário mudar UDPScr\'cr.ja\'3? Quais solo os números de porto par~ os sockcts em UOPCiiem c UOPScr,•cr? Quais cmm esses números ames dessa mmhlnça?

32. Considere uma vers;lo 1lcncralizada do csqucm;~ dcscriro no problema acima. Em vez de usar mímero.s binános. vamos tratar os identificadores de chave c de p:tr como numcros de base IJ. sendo b > 2. e

Questões dissertotivos 1.

2.

Na s ua opini:lo, por que as aplicações de compartilh:uncnto de arquivos P2P s.'ln 111tl populares? Será por que distribuem nmsiea c vfdco gmmhamcme (o que é legalmente d1scullvcl) ou por que seu nlimero tmenso de servidores atende cficicmcmcnle uma demanda mac1ça por mcg.1b)'tes? Ou scra pelas duas razões?

3.

Silcs de com~rc10 eletrônico c outros siles \Veb frcq~tcntemcntc tem bancos de dadtlS · de a1>oio·. Como ser\'ldoro.:s HTIP se com unkam com esses bancos de dados?

4.

Como vtl<:t pode confígumr seu brow~er para cachc local? Que opções de cache você tem1

Lemo a rugo "The Darknet and thc Fmure of Contem Distribution• de Biddlc. England. Pcinado c Willman

5.

Você pode configurar seu browser para abrir \':Irias conexões simuh.\neas com um sitc Web? Quais s.lo as vantagens e as desvan tagens de ter um grande número de conexões TCP simultâneas?

!Biddle, 20031. Vocc concorda com a opinião dos autores? Por que? Por que não?

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne;.;t________________________....._

6.

Vimos que sockcts TCP da lmcmet tratam os dados que estão sendo enviados como um:~ cadei:~ de bytes. mas que sockctS UDP reconhecem fronteiras de mensagens. Cue uma vantagem e uma desvantagem da API orientada para b)·tcs em rdac;'lo à API que reconhece c preserva exphcilamentc as fronteiras das mensagens definidas por aplic:u:ões.

7.

O que c o SCI'' tdor Wcb Apache? Ql•anto custa? Que funcionalidade tem atualmente?

8.

Muuos clientes BitTorrcm utilizam DHTs para criar um rns m:ador distribu1do. Para esses DHTs, qual é a "c have" c qual é o "vn lor"?

9.

Imagine que as or~a nizaçôcs responsáveis pela padronizuç;\o da Wcb decidam modi ficar a conven<;ão de nc1 me:H;:lo de modo que cnda objo.:to seja nomead o c

referenciado por um nome exclusivo que Independa de locallt~tç:lo (um UR ). Dlscut:t algumas questões que etwo h·c riam tal modificação 10. Ha empresas diStribuindo transmissões televisivas ao \ 'IVO por meio da lmemet hoje? Se sim, essas empresas estão usando arquiteturas cliente-sen'idor c P2P? 11. As empres...s, hOJe, est.,o oferecendo um SCI''IÇO de vídeo ao \'ivo através da lntcmct usando uma arquitetura f'2P? 12 . Como o Skype provê um serviço PC pam telefone a ' 'ários países tlr destino? 13. Quttis s.~o os clientes mais pop ulnres do BitTorrent atualmente?

Tarefas de programação de sockets Tarefa 1: servidor Web multilhreod Ao final dcsttl tarefa de programaçl'lo, ' 'OCê u:rá dcscnvoh•ido, em Java. um servidor Web multithre;~d , que sep capaz de atender \'áriaS reqmsiçõcs em paralelo. Você nnplerncntilr.l a vcrs.'lo L.O do HTTP como definida no RFC 1945.

O HTTP/1.0 criil uma conexão TCP separada para cada par rcqu•siç;\l>lrc:.posta. Cada uma dessas conc.o<ões será manipulada por um 1hrc.1d. H:l\'er:'i tamhém um thrcad princ1pal, no qual o se n~do r ficara a escuta de clientes que quiserem estabelecer conexões. rara sim· plincar o Lrahalho de programaç~o. desenvolveremos a codinca<,'ao em dois es tágios. No primeiro cst::lgio. ' 'oce escrever:\ um 3Crvidor multhhrcad que si mplesmente :t(>r<.-scnta o conteúdo da mensagem de requisicão HTTP que recebe. Depots que esse programo estiver execmando normalmeme, você ac licio nard a cocliOcaçào nccess.á riu p<~ra gc r:~r umn rcsposlt1 :•pro prittd;l. 1\ o desenvolver .t codilkaç-Jo. vocc poderá tcstnr seu se rvido r com um hrowscr Web. Mas lembre-se de
htlp: // hos l. someschool . ed u: 6789/ index . hlml Quando seu servidor cncomrar um erro, deverá enviar uma mensagem de resposta com uma fome HTM L adequada, de modo que a informação de erro

seja aprcscntad::t na janela do browscr. Voei! pode encontrar mats detalhes sobre esta 1arefa, assim como trechos tmportantcs em códi~o j:wa no site hup://www. aw.com/k urosc.br

Torefo 2: dienle de correio Nesta tarda. você de crwolvcru um :~gente de usuário de corre ro em ja"a com as seguintes caracterlsticas: Que prove uma interface ~r:!llca p:~ra o remetente com Cilmpos l?::tra o scn·idor de correio loe::tl. parn o endereço de c·m:ltl do remetente, para o endereço de e-mail do dcstínal:írio, para o ilSSUn· to da mens..1gcm c para a proprin mensage m. Q ue estabelece uma conex:\o TC P entre o cliente de Cllrrcio c o servidor de correio local. Que envia comandos SMTf' para o servido r de correio local. Que recebe c processa comandos SMTP do scrvidtlr de correio loc;~l. Esta será a apar

Você descnvolvcr:'i o a~cnte de usu:lrlo de modo que ele envie uma mensagem de c-maíl para no mllxímo um dcsunatáno por vez. Além disso, o agente de usuáno admiurá que a pane de dommto do endereço de e-mail do destinatário scr:'i o nome canônico do ~nidor SMTP do desttn:wtrio (0 agente de usuário não realíurá uma busca no DNS para um rcgtstro MX: portanto, o remetente deverá fornecer o nome real do scrvtdor de correio.)

Torefo 3: UDP Pinger lob Neste laboratório, voe~ implementará um cliente e urn servidor Pmg simt)k'S, em UDI'. A funcionalidade que esses programas ofe recem é similar à do programa Ping padronizado, di~ponh·cl em sistemas opcroclonais modernos. O Píng J>:tdro nizado funciona e nviando à Internet uma mwsagcm ECi tO do Prowcolo de Mensagens de Coruro le da lntemet (ICMP), que t1 m:lquinn remota dcvolw:: ao remetente como se fosse wn eco. Ent:\o, () rcmc;tentc; pode

(amada de

aplico~õo

137

detcnnlnar o tempo de 'iagcm de Ida e volta cmre ele mesmo c o computador para o qual enviou o Ping.

0 Java não prO\ e nenhuma [uncionalidade para em'iar o u receber mensagens ICMP c é por isso que nes1e labora1ório voce tmplementara o Pmg 11:1 camada de aplicação com sockets e mensagens UDP padronizados.

Tarefa 4: servidor Proxy Web Neste lahormório. vncê desenvolverá um servidor proxy Web simples <.fiiC lambem !XKlcm razcr cachc de r:tginas Wch. Esse scrviclor accilnr.luma m ensagem GET de um hrowscr. transmllir:l CSS.'l mensagem ao servidor Wcb dcslinatá•·io, rc.:l·cbcm a nwnsas;cm de rcspostn HTTP do servidor dcslinat:1rio c lransmie lrá n mensagem de resposta a~) hmwscr. Esse serviclur r1ruxy (! nl\tho sim[>lcs: emende apenas requisições GET silllples. Comud o, pode manirular ll)dos os 1ipos de objetos: n:\o somem c pãs;inas HTML, mas 1a mhém image ns.

Wireshark Labs Voei tiiCOrtlrarll

dewlht•s completos. t'lll i11g/ts. sobre OS \Vircshark utbs

Wireshork lob: HTIP Como Já ttvcmos uma primeira experiência com o anahs.~dor de pacotes \Vircshark no Lab 1. estamos pronlos para usar o Wireshark para mvesligar protocolos em operação. Neste lnboratorio. exploraremos di,·ersos nspccws do prowculo HTIP; a tnleraç!\v básica GET/ resposta , rormatos de mensagens HTTP, ex1raçâo de grandes arquivos lll'ML. extração de arquivos HTML com URLs inseridos, conexões persistentes c não pcrsistcmes c (llllcntlc.tç<\o e segurança do I iTTP.

Wireshork lob: DNS Neste lnborn lMlo, exa minaremos mais de peno o lado clicmc do DNS, o IHOtocolo que trnnsrorma nomes

110 SÍIC \-IW\'1. ilW. COm/ kurose_br

de hospedeiros da lmeme1 em endereços IP. Lembre-se de que. na Secao 2.5. dissemos que o papel desempenhado pelo cllcmc no DNS é rcl:ulv:uncnle simples - um cliente envia uma consulta a seu scn·idor de nomes local e rccchc uma resposta. Mas há muha coisa que pôde acontecer nos bastidores c que é tm;si\•cl para os cliemes DNS enquanto os sen•tdores 01\S hterárquicos se comunicam uns com os outros para resolver a co nsulta DNS do clicn1c de modo recurstvo ou ieen.ui"o· Do ponto de vista do cliemc DNS, 1odavin. o 11rotocolo é hasta me simples- é formulada uma consulta ao scr,•idor d e nomes local c c recebida uma resposta deste. esse labora1ório observamos o DNS em nc;:ln

bow4tto4ic~

Brom Cohen Srom Cohen é Cientisto
Como surgiu o ideio de desenvolver o BitTorrent? Eu adquiri cxperi~ncia criando redes (protocolos acima TCPIUDP), e implementar enxames parecia o problema irresoluto mais nucressantc da cpat":t, então resolvi trabalhar nisso. O t<3lculo por trás do núcleo do BilTorrent é simples: Exis te muita C':1p:tcidade para upload lá fom. Muitas

outras pessoas ttunbém nzcram essa mesma observação. Mas lmplcmcn1ar algo que pudesse lidar com a logfstíca envolvida é um omro problema. Quais foram os aspectos mais desafiadores oo desenvotver o 8itlorrent? A parte prmcipal fos acertar todo o projeto c a estrutura do protocolo. As!>sm que csuvessc funcionando. sua implcmelllaçJo era Muma mera questão de programação-. Com relaçJo :1 smplemelllaçào, de longe a pane

mais diffcil foi implementar um sistema confiável. Ao lidar com pares desconhecidos, voe~ tem de imaginar que, 11 qualquer momento, qualquer um ddes pode fazer qualquer coisa e ter um tipo de resposta cstabelecsda para todos os casos extremos. Eu unha de ficar reescrevendo uma longa seção sobre o BitTorrent quando o cstllV
bow4tto4ic~ Você acha que, em um futuro próximo, outros sistemas de d i5tribuição de arquivo podem substituir o BitTorrent? Por exemplo, a Microsoft pode incluir seu próprio protocolo de distribuição de arquivo em um lançamento futuro de um sistema operocionol? Pode haver protocolos no futuro , mas t improvável que os prlncfplos fundamentais de como agrupar dados. esclarectdos no protocolo BitTorrent. mudem. A maneira mais provável de ocorrer uma su bstituiç.'o t se houver uma mudança em toda a estrutura da Internet em razão das pro porções entre algumas das constantes fundamentais que mudam radie11lmente à medida que a vclocidadl.' aumenta. Mas projtções para os próximos anos apenas reforçam ainda mats o modelo atual.

De fonna gerol, onde você vê a Internet liderando? Na sua opinião, quais são, ou serão, os desafios técnicos mais importa ntes? Você viz.ualizo alguma novo • oplicoçõo inovadora• que está por vir? A Internet c os co mputadores em geral estão se tornando cada vez mais onipresentes. O iPod nano parece uma lembranci nha de festa , pois inevitavelmente um dia ele o será. em raz<'lo da baixa dos preços. O desafio técni co atua l mais interessa nte é reuni r o maior número de d<1d os possível de tod os os di sposith•os conectados c disponibi llzar esses dados de uma forma ú til e acesslvel. Por exemplo, quase todos os aparelhos portáteis poderiam con ter um GPS, c cada objeto que ' 'OCê possui , incluindo ro up<~s, brinqu ed os, e letrodom ésticos e mobilia, poderiam Informá-lo o nde se enco ntram ao perdê-los c fazer um res um o co mpleto sobre seu históri co atua l, incluindo m:mu tcnçâo necessária, utilidade futura esperada, clclce<,"ôlO de maus tratos etc. V
bow4tto4ic~

Camada de transporte

osiclon:~da

P

entre :~s rnmadas de aplicação c de rede, a camada de transporte

~

urna peça cemral da arqui-

tetura de rede em camadas. Ela desempenha o papel fundamental de fornecer serviços de comumcaÇ{lo

dirctamemc aos processos de aplirnçM que rodam rm hospedeiros diferentes. A abordagrm pedagógica que ildotamos neste capitulo ~ altern;u entre discussões de principios de camada dr trnn!>portc c o modo como esses princfpios são implementados em protocolos e.xistrntcs: como de costume, daremos partícuhtr ~nfase aos protocolos da lmernct, em especial aos protocolos de camada de tr.lnspone TCP e UDP. Começaremos dtScuundo a relação entre as camadas de tr.lnsporte e de rede, preparando o cenário para o primeira func,:;\o importante da camada de transporte- ampliar o serviço de entrega d:~ camad:~ de rede entre dots sistemas finais para um serviço de entrega entre dois processos de camada de aplicação que rodam nos sistemas fin:us. Ilustraremos essa função quando abordarmos o UDP, o protocolo de transporte m\o oricmado para conexão da lmcmct. ex:~ me d:~

Entt\o retornaremos aos princfpios e enfrentaremos um dos problemas mais fundamentais de redes de computadores- como duas entidades podem se (.-ornunicar de maneira confi~wcl por um meio que pode perder e corrom· per dados. Mediante uma s~ríc de cenários cada vc:z mais complicados (c realistas!). construiremos um conjunto de técnit"aS que os protocolos de transpone utilizam para resolver esse problema. Ent~o. mostmrcmos como CS5cs prindpios csu\o incorpomdos no TCP, o protocolo de transporte oricmndo para C
3.1

Introdução e serviços de camada de transporte

Nos dois caphulos amcriorcs, citamos o papel da camada de transporte c os serviços que ela fornece . Vamos rc,•isar rapidamente o que Jà aprendemos sobre a camada de transporte. Um protocolo de camada de trarlSportc fomece comunicação lógica entre processos de aplicaÇ<\o que rodam em hospedeiros diferen tes. Comunicação lógica nesse contexto significa que, do pomo de vista de uma aplicação, tudo se passa como se os hospedeiros que rodam os processos estivessem conectados diretamente; na

bow4tto4ic~ Capitulo 3

(ama do de lronspor le

141

verdade. esses hospedeiros podcr:lo estar em lados opostos do planeta. conectados por numerosos roteado res c uma ampla variedade de tipos de enlace. Processos de aplicaçilo usam a comunicação lógrca pro,•ida pela camada de tmnsponc paro crwrar mens:1gens e111re si, livres da preocu pação dos detalhes da inrraestrutum Hsica utihzada paro transpon nr essas mensagens. A Frgurn 3. 1 ilustro a noç.\o de eomumcação lógrc.1. Nela, vemos que protocolos de camada de transporte s:lo implementados nos sistemas nnais, mas não em roteadores de rede. No lado remt'teme. a camada de trnns pone converte as mensagens que recebe d e um

Rede móvel

ISP National ou Glob
[Apl~

Rede Coorponn~

Figura 3.1 Acomodo de llonspolte fornece comunicoçõo lógKo, e não físico, entre processos de oplicoções. Pode haver mais de m~ prolocolo de comodo de llonsporte disponível poro oplicoções de rede. Porexemplo, o Internet tem dois protocolos - TCP e UDP. (odo um deles provê um conjuntodiferente de serviços de comodo de transporte à oplicoçõo que oestóchamando

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------processo de aplicação remetente em pacotes de mmada d e tmnsporte, denominados segmentos de camada d e tra nsporte na terminologia da Internet. Isso é (possivelmeme) feito fragmentando-se as mensagens da aplirnç:io e m pedaços menores e adicionando-se u m cabe<,-alho de camada de transporte a cada pedaço para cri:1r o segmento de camada de transporte. A camada de transporte. cnt:\o. passa o segmento para a camólda de rede no sistema final remetente, onde ele é encapsulado em um pacote de camada de rede (um datagrama) e enviado ao destinat:irio. E importante notar que roteadores de rede agem somente nos rnmpos de camada de rede do datagrama; isto é. n:\o examinam os campos do segmento de camada de transporte encapsulado com o datólgranla. No lado destlnat~rio. a camada de rede extrai do datagrama o segmento de camada de transporte e passa-o para a camada de transporte. Em seguida, essa camada processa o segmento recebido. disponibilizando os dados para a aplicação des~inat:iria.

3.1.1

Relação entre os camadas de transporte e de rede

Lembre-se de que a camada de transporte se situa logo acima da camada de rede nn pilha de pro tocolos. Enquanto um protocolo de c:unad:l de transporte fornece com unka~1'0 lógica en tre Jll'occssos que rodam em hospedeiros d ircrc llles, urn protocolo d e camada de rede fornece <.:onHtlliC'íl('llo lógica entre lrospe,ldros. Essa distinção é sutll, mas lrn pomuu c. Vamos examiná-Ir• com o auxilio de uma analogia com moraclhs. Considere duas C'íiSas, um:~ n:~ Costa Leste c outra na Costa Oeste dos Eswdos Unidos c que, em cada uma d elas. h:\ uma dl'tzia de crianças. As crianças da Cost~\ Leste s;lo pr1mas das cnanças da Costa Oeste e todas adoram escrever cartas umas para as outms - <:ada crian\.d escreve a cada primo uma vez por semana c cada carta é entregue peJo serviço de correio tradicional dentro de um em•clope separado. Assim, cada rnomdia envia l44 cartaS por semana para a outra. (Essas crianças economizariam muito dinhei ro se tivessem e-matl!) Em cada moradia há uma criança responsável pela coleta c distribuição da correspondê ncia- Ann, na casa da Costa Oeste, c Bill. na da Costa Leste. Toda semana, Ann coleta a correspondblcia de s eus irmãos c irrn:ls c a coloca no correio. Quando as rnrtas chegam à casa da Costa Oeste. também é Ann quem tem a tarefa de d1stributr a correspondência a seus irmãOs e irm:ls. 6111 realiza o mesmo trabal ho na casa da Costa Leste. Nesse exemplo. o serviço postal provê uma comunirnção lógtrn entre as duas casas - ele mo"imenta a correspondência de uma casa para outra, e n:lo de uma pessoa para outra. Por outro lado. Ann c Bill provccm comunicaç:lo lóg1ca entre os primos - eles coletam e entregam a correspondência de seus mn:los e irmãs. Note que, da perspectiva dos primos. Ann e Bill selo o serviço postal, embora scj:un apenas uma parte do sistema (a parte do sistema fina l) do processo de entrega fim a fim. Esse exemplo das moradias é uma analogia imercssame para explicar como a camada de: transporte se relaciona com a camada de rede: mensagens de aplicação

= cartas em envelopes

processos = primos hospedeiros (também denominados sistemas finais)

= <.-asas

protocolo de camad:1 de transporte = Ann c Bill protocolo de cam~da de rede

= scrvi.ço postal (I nduindo os carteiros)

Continuando com essa an:dogi~ . observe que Ann c Bill f."lzcm todo o seu trabalho dentro de suas respectivas C:ISas; eles não cst:lo envolvidos, por exemplo, com a classifica(·ào da corrcspond~ncia em nenhuma central inter·

medi:\ria dos correios ou com o tmnsponc da corrcspond~ncia de uma central a outra. De maneira semelhante, protocolos de camada de transporte momm nos sistemas finais , onde movimen tam mensagens de processos de aplicaçlo pai",\ a borda da rede (isto é, para a camada de rede) c vice-versa, mas não interferem no modo como as mensagens são movimentadas dentro do nücleo da rede. Na verdade, como ilustmdo na Figura 3.1, roteadores íntcnncdiários nilo rct'On hcccm nenhuma informação que a camada de transporte poss:1 ter anexado às mensagens da aphcaç:to nem agem sobre el:~. Prosseguindo com nossa sag

(amado de lronsporle

143

Por serem crianças mais no,·as, Susan c Harvcy recolhem c enlreg;un a correspond~ncia com menos frequfncía c. ocasionalmente, p<:rdcm canas (que às vezes acabam mastigadas pelo c.\o da fanulia). Assim. o par de primos Susan c Harvey não prove o mesmo conjunto de serviços ( isto é, o mesmo modelo de ser,•iço) oferecido por Ann c Bill. De uma maneira análoga, uma rede de co mputado res pode disponibilizar vários protocolos de transporte, em que cada um oferece um modelo de serviço diferente às aplicações.

Os possíveis serviços q ue Ann c Bill podem fornecer s;\o ch1ramcnte limitados pelos possíveis servi\' OS que os correios fornecem. Por exemplo, se o serviço postal não estipula um prazo máximo para entregar a corrcspondtncia entre as duas casas (digamos, três dias). enlào nào há nenhuma possibilidade de Ann c Bill definirem um atraso máximo para a entrega da correspondência cnuc qualquer par de primos. De maneira semelhante, os serviços que um pro tocolo de transporte pode fornecer sâo frequentemente limitados pelo modelo de serviço do protocolo subjacente da camada de rede. Se o protocolo de c:~mada de rede n~o puder dar garanti
3.1.2 Visão geral do camada de transporte no Internet Lembre-se de que a Internet - c, de maneira mais geral. a rede TCPIIP - disponibiliza dois protocolos de transporte dis umos para a camada de aplicação. Um deles é o UDP (User D
bow4tto4ic~ Redes de com pu tod ores e o Inle.;.'; .ne;;.;t_________________________

Agora que abordamos ligcirameme o modelo de sen•iço IP. vamos resumir os modelos de servi\'O providos por UDP c TCP. A responsabilidade fundamental do UDP e do TCP é ampliar o scmço de entrega IP en tre dois sistemas finais para um serviço de entrega entre dois proctSSOs que rodam nos sistemas fin.us. A ampliação da em rega hospedeiro a hospedeiro p.1ra entrega p rocesso a processo é denommada multiplcxação/dem ultiplc.xação de camada de transporte. Discutirem05 multiplexação c dem ultiplexaçilo de camada de transporte na próXInm seção. O UDP e o TCP tam~m fornecem verificação de integridade ao inclu1r campos de detecç:io de erros nos cabeçalhos de seus segmemos. Esses dois serviç05 mmim05 de camada de transporte - emrega de dad05 processo a processo e verlncação de erros - são os llnlcos que o UDP fornece! Eln especial. como o IP. o UDP é um sen•iço n
O TCP, por out ro lado, oferece vá rios serviços adicionais às aplicações. Primeiramente, c mais importante, ele prov~ transferência con fiável de d:tdos. Usando comrole de Ouxo, ntirn eros de sequfncia, reconhecimentos c temporizadores (técnicas que exploraremos detalhadamcnte neste capllulo). o protocolo assegura que os dados ~ja m en tregues elo processo remetente ao proc:csso dcst in:~tário corrcwmcm c c em ordem. Assim, o TCP converte o scr,•iço não confiável do IP entre sistemas finais em um serviço con fi:\vcl de transporte de dados entre processos. Ele t:unbém prov~ cont role d e congestionamento. O comrolc de congestionamento n:lo é t:mto um serviço fornecido;\ ap lic:~ç-.io solicitante; é ma is um serviço d irigido à lmernel como um todo- para o bem geral. Em termos genérícos, o controle de congestionamento do TCP evita que qualctucr outra conex;\o TCP abarrote os enlaces c comutadores entre hospedeiros comunicantes com uma q u:tntidade excessiva de trafego. Em princí· p io, o TCP permite que conexões TCP trafegando por um enlace de rede congestionado compartil hem em pé de igualdade a largura de banda daquele enlace. Isso é feito pela regulagem da tax:\ com a q ual o lado remetente do TCP pode enviar tráfego para dentro da rede. O tráfego UDP, por outro lado, não é regulado. Uma aplicação que usa transporte UDP pode enviar tráfego â taxa que quiser, pelo tempo que qu1ser. Um protocolo que fornece transrertncia confiável de dados c controle de congestionamento é, necessariamente, complexo. Prec•saremos de várias seções para detal har os prmc1píos da tmnsfer~ncia confiável de dados e do controle de congestionamento, bem como de seções adicionais para explicar o protocolo TCP. Esses tópicos são anahsados nas scçOcs 3.-T a 3.8 . A abordagem escolhida neste caprtulo é alternar entre prmcip1os básicos e o prOtocolo TCP. Por exemplo, diS
3.2 Multiplexação e demultiplexação Nesta SCÇllO, discuti remos muhiplexação c dcmuiLiJ)IexaçiiO na c:unacla de transporte, isto t, :1 ampliação do serviço de entrega hospedei ro a hospedeiro provido pela camada de rede para um serviço de entrega processo a processo pam aplicações que rodam nesses hospedeiros. Para manter a disc uss:\o em nível concreto, vamos c.-.:a· minar esse serviço básico da camada de transpor te no contexto da Internet. Enfatizamos, contudo. que o serviço de multi plext~ç:'lo/demuhiplexação é necessário par-.t todas as redes de computadores. No hospedeiro de destino. a camada de transporte recebe segmentos da c:tmacla de rede logo abaixo dela c tem a responsabi lidade de emregar os dados desses segmentos ao processo de aplicação apropriado que roda no hospedeiro. Vamos examin:~r um exemplo. Suponha que você esteja sentado à frente de seu computador, dcscar· regando páginas Wcb enquanto rocb um:~ sesS<'Io FTP e duas sc.çsões Telnct. Por conseguinte, voct tem qu:mo processos de aplicação de rede em execução- do•s processos Tclnct. um processo fTP e um processo HTTP. Quando a camada de transporte em seu computador receber dados da camad:1 de rede abaixo dela, precisará direcionar os dados recebid05 a um desses quat ro processos. Vamos ver agora como isso é feito. Em primeiro lugar, lembre-se de que dissemos, nas seções 2. 7 e 2.8, q ue um processo (como pane de uma aplicação de rede) pode ter um ou mais sockets, portas pelas quais dados passam da rede para o processo e do



145

processo parn :'1 rede. Assim, como mostra :'1 Figura 3 .1. a camada de 1ranspone do hospedeiro destílt:llárío na verdade não entrega dados diretamente a um processo. mas a um sockct íntcrmedhirio. Como. a qualquer dado instante. pode haver ma1s de um socket no hospedeiro destjnatário, cada um tem um Identificador exclusivo. O formato do identificador depende de o socket ser UDP ou TCP. como discutiremos em breve. Agora, vamos considerar como um hospedeiro dcsúmttário dircciona à porta correta um segmento de camada de transporte que chega. Cada segmento de camada de transporte tem um conjunto de campos para essa finalidade. Na extremidade receptora, a camada de transporte examma esses campos para identificar a porta rcceptorn c direcionar o segmento a esse sockeL A tarefa de entregar os dados contidos em um segmento da camada de transporte à porta corret:t é denomin:tda demulti)llexação. O traoolho de reunir. no hospedeiro de origem, porções de dados pro,·enlcntes de diferentes port."\S, encapsular cada porç.\o de dados com infonna~·ocs de cabeçalho (que mais tarde serno usadas na demultiplexação) para criar segmentos, e passar esses segmentos para a camada de rede é denominada multiplexação. Note que a camada de transporte do hospedeiro que está no meio da Figura 3.2 tem ele dcmultlplexar segmentos que chegam da camada de rede nbaixo para os processos Pl ou P2 acima; isso é feito direcionando;\ porta corrcsponclcmc do processo os dados contidos no segmento que está chegando. ;\ C:lllllld
Aplicação

Transporte Rede

Transporte Rede Enlace de dados

Enlace de dados

Enlace de dados

Ffslca

Física

Física

Legenda: Q

PrO
SO
Figura 3.2 Multiplexação e demultiplexação no wmodo de lronsporte

bow4tto4ic~ Redes de computadores e o Interne~!-----------------------32 bits

Porta da fonte 11 Porta do destino 11

Outros campos de ca~atho Dados da aplicaç.lo (mensagem)

Figura 3.3 Campos de número de porto do fonte e do deslino em um segmento de comodo de tronsp01te (que usa a portn número 21). A lista dos nümcros de po rta bem conhecidos~ aprcse mada no RF C 1700 e atuali zada em htLp://w,vw.i:llla.org [RFC 3232) . Quando dcsenvoh,cmos uma nova aplka~·:lo (como as desenvolvidas nas seções 2.7 a 2.8), devemos atribuir a ela um numero de porta. Agora já deve est:lr claro como a camada de transporte poclcrit4implemelllar o serviço de dcmultiplc xaçlo: cada pomt do hospedeiro pode receber um nümero designado; quando um segmen to chega ao hos pedeiro, a camada de trnnspone cx:unina seu mímcro de porta de destino c o dircciona à porta correspondente. En tão, os dados do segmento passam ai r.wés da porta c en tram no processo ligado a ela. Como veremos, é assim que o UDP faz demultlplcxaç:1o. Todavia. veremos também que muhiplcxa~-ãoldemultlp l cxação em TCP é ainda mais sutil.

Multiplexação e demultiplexação não orientados poro conexão Lembre-se. na Seção 2.8, de que um programa em J ava que roda em um hospedeiro pode criar uma porta

UDP com a linha

Da t agr amSocket mySocke t • new OatagramSocket<> : Quando uma porta UDP ~criada dessa maneira. a camada de transporte automaticamente designa um número de porta ao sockct. Em especial. a camada de transporte designa um número de porta na raixa de lOH a 65535 que não esteja sendo usado naquele insta n te por qualquer outra porta UDP no hospedeiro. Alternativamente, um programa Java poderia criar uma porta co m a linha

Oatag ramSocket mySoc ket - new OatagramSocket Orla UDP. Se o desenvolvedor resJ>Ons.ível por esc rever o código da aplicaç

(amado de lron spor le

147

:ISScx:iado. A medida que segmentos UDP cheg:~SScm da rede. a máquina B direcionaria (demulllplexarla) cada segmento :\ porta apropriada examinando o número de porm de destino do segmento.

1: importante not:lr que um sockct UDP t totalmemc identilkado por uma tupla com dois elementos. consistindo em um endereço IP de destino c u m número de porta de destino. Consequcntcmcmc. se dois segmemos UDP Llvercm endereços IP de fom e e/ou números de porm de fo nte diferentes, porém o mesmo endereço IP de dr
Multiplexação e demultiplexação orientadas para conexão Para entender demultiplexa~;-:'o TCP, temos de examinar de perto sockets TCP c l'S tabeledmento de conexão TCJ:>. tiá uma diferença sutil ernre um soeket UDP e um socket TCP: o socket TCP é identificado por uma tupla d e qua tro elementos: (endereço IP da fome, número de porta da ro nte, endereço I P de destino, número de porta do destino). Assim, quando um segmento TCP que vem da rede chega a um hospedeiro, este usa todos os quatro valores paro direcionar (dcmuhiplexar) o segmento paro~ o socket apropriado. Em especial, e ao contrário do UDP, dois segmentos TCP chegando com endereços lP de fonte ou numcros de porta de fonte diferentes serão di recionados para dois sockets diferemes (com exce(<\o de um TCP que esteja carregando a requisição de estabelecimento de conexão original). Paro perceber melhor, va mos considerar novamente o exemplo de programação cliente-servidor TCP aprescmado na Seção 2.7: A aplicação sen·idor TCP tem um socket de emrada que espera rcqutslcOes de estabelecimento de conexão vi ndas de clientes TCP (ver Figura 2.29) na porta número 6789.

O chente TCP gera um segmemo de estabelecimento de conexão corn a hnha

Sockel cl ienlSockel "' new Socket C"serverHos LNarne ". 6789) : Processo cliente

Socket

Servidor B pon4 d4 fC
po•t~ do clttt>no

,, 157

46418

PQIU do fonao PQIU do 6tst""'

46428

19157

l I-

Figura 3.4 Compos denúmero de porto do fonte edo destino em um segmento de comodo de transporte


Uma requlslç:\o de esmbelccimemo de conexão nada mais ~ do que um scgmcmo TCP com número de porta de destino 6789 e um bil especial de estabelecimento de conexão marcado no cabeçalho TCP (que será dtseuudo na Scç:lo 3.5). O segmento inclui tnmbém um numero de porta de rome que foi escolhido pelo cliente. r\ linha acima cria ainda um sockct TCP para o processo cliente, atravts do qual dados podem entrar e sair do processo cliente. Q uando o sistema operacional do computador que está rodando o processo servtdor recebe o segmento de requisição de conexão que está chegando c cuja porta de destino é 6789. ele localiza o processo servidor que está esperando para acei tar uma conexão na porta numero 6789. Então, o processo servidor crirt um novo sockct:

Socke t connectlonSockel

wel comeSocket.accept () :

A camada de transporte no servidor também not..'l os quatro \'lllorcs seguintes no segmento de requisi· çi\o de conexão: {1) o número de porta da ronte no segmento, (2) o endereço lP do hospedeiro da fonte, (3) o nllmcro de porta do destino no segmento c (4) seu próprio endereço IP. O sockct de conexão recém-criado é identil'i<:aclo por esses quatro valores; todos os scgmcmos subscque ntes que chegarem, cujrt porta da fome , endereço I? dn fonte, porta de destino c endereço IP de destino combinarem com esses quatro valo res. scr.lo demultiplexaclos para essa J:>Ortn. Com a conexão TCP agora ativa. o cliente c o servidor podem enviar dados um para o outro. O hospedeiro sen•idor pode supo rlar ' r:l rios sockets TCP simuh:incos. sendo cada um ligado a um processo c iclentil'icado por sua prót>ri:t tupi a de quatro elementos. Quando um segmento TC P chega :to hospedeiro, todos os quatro campos (endereço lP da fome. porl:l da fonte. endereço IP de des tino, porta de destino) si\o usados para dir«:ionar (demuhlplcxar) o segmemo para o socket apropriado. A suuaç:\o é ilustrada na Figura 3.5, na qual o hospedeiro C inícta duas sessoes IITIP para o servidor B. e o hospedeiro A inicia uma sess;lo HTTP para o servidor B. Os hospedeiros A e C e o servidor B possuem, cada um, seu próprio endereço IP exclusivo: A, C e B, rcspccLi\'alllente. O hospedeiro C atribui dois números diferentes (26H5 c 7532) de porta da fonte às suas duas conexões HTIP. Como o hospedeiro A está escolhendo números de porta indcpendentememe de C. ele poderia

Cliente Web hospedeiro C

Setvidor WebB

Proceuos HTTP por
Oemultiplex~io

porta da fonte:

porta da fonte: porta do destino:

porta do destino:

7532

80

26145

80

IPda fonte:

IP do deslino:

IP d<1 fonte:

IP do deS1ino: B

c

c

B

ClienteWeb hospedeiro A

na camada de transporte

-

porta ela fonte: potta do destino:

26145

80

IP d<~ fonte: A

IP do destino: 8

figura 3.5 Dois clientes que usam omesmo número de porto de desfino (80) poro se comunicar com omesmo aplicação de servidor Web


Cama da de lronsporte

149

também atribuir um numero de pona da fonte 26H5 à sua conexão HTTP. Apesar disso, o servidor B ainda será capaz de demultiplexar corretameme as duas conexões que u~m o mesmo numero de porta de fo nte, já que elas têm endereços IP de fonte d iferentes.

Servidores Web e TCP Antes de encerrar essa discuSS
Varredura de Porto Vimos que um processo servidor espero pacientemente em umo porto aborto poro conloto pOI' um clienle remolo. Algumas portos são reservados poro oplic:oções familiares (por exemplo, Web, FTP,ONS e os ~lVi dores SMTPI; oulros portos são ulilizodos por convenção por oplic:oções populores (por exemplo, o Microsoft SOl Server 2000 ouve os solic:ítoções no porto 1434 do UDP). Desta formo, se delerminormos que uma porto eslá aberto no hospedeiro, talvez possamos mapear essa porto poro umo oplic:oção específico sendo executado no hospedeiro. Isso é muilo úlil poro administradores de sistema, que frequenlemenle têm in ter· esse em saber quais aplicações de re

ln;.;l~e;.;rn;.;e;.;.t_________________________

nilo persistente, então uma nova conc.'lão TCP é criada c encerrada para ~da rcquisiçtio/rcsposta c, ponanto, um novo sockct é criado c mais tarde encerrado para cada rcquisiç-Jolresposta. Essa criação c encerramento frequentes de sockcts podem causar sério impacto sobre o desempenho de um servido r Wcb mo,•imcntado (embora o sistema operacional possa usar \':\rios estratagemas para atenuar o problema). Aconsclh
3.3 Tronsporte não orientado para conexão: UDP Nesta seç
O UDP. defintdo no (RFC 7681. faz apenas quase tão pouco quanco um protocolo de cransporte pode fazer. A parte sua funçào de muhiplcxaç-.1o/dcmuhiplexaç;lo c de alguma vcrifiL'nÇào de erros. ele nada adi ciona ao IP. Na verdade, se o criador d:~ aplicação escolher o UDP. em vez do TCP, a aplícaç;lo estará •falando' quase direta mente com o IP. O UOP pega as mensagens do processo de aplicaç-.1o, anexa os campos de numero de porca da fome c do dcscino paro o serviço de mulLiplcxação/dcmuiLiplexação. adiciona dois outros pequenos campos c passa o :.cgmenlo resu ltante :) camada d e rede, que encapsula o segmento dentro de u m datagrama IP c. em seguida, faz mna ccntatl\"a de melhor esforço para entregar o segmento ao hospedeiro receptor. Se o segmento chegar ao hospedeiro receptor, o UDP usará o nümero de porta de destin o para entregar os dados do segmento ao processo de apl kação correto. Note que, com o UDP, não há apresentação entre as entid<~des remetente e destinat.:\ria da camada de transporte antes de enviar um segmento. Por essa razão. dizemos que o UDP é nào oricncado para conex:\o. O DNS é um exemplo de protocolo de camada de aplicação que usa o UDP. Quando a aplicação DNS em um hospedeiro quer fa zer um:~ consulta, cons trói uma mensagem de consu ha DNS c passa a mensagem para o UDP. Se m reali zar nenhuma apresentação com a entidade UDP que está funcionando no s istema final de destino, o UOP do lado do hospedeiro adiciona campos de cabeçalho li mensagem c passa o segmento rcsuhantc ;\ camada d e rede, que cncapsula o segmento UD P em um da1agrama c o envia a um servidor de nomes. t\ aplic.1çüo DNS no hospedeiro requisitante crlliiO espera por urna resposm à s ua consulta. Se não receber uma resposca (possivelmen te porque a rede subjacente perdeu a consulta ou a rcspost~l) , ela tent:11':1 crw iar a consulta a outro servidor d e no mes ou informará à aplicação consulta me que não pode obter unm resposta.

!: possfvcl que agora voe~ c:.teja imaginando por que um criador de aplic:aç;\o es<:olhcria construir uma liccr<;do sobre quc1is clctclos selo enviados r

(amada de lronsporle

151

enlaces entre os hospedeiros da fonte c do destinatário ficam excessivamente congestionados. O TCP também continuará a rcell\riar um segmento até que o hospedeiro destinatário reconheça a recepç.lo desse segmento, mdcpendentemente do tempo que a entrega confiá,rel levar. Visto que aplícat;õeS de tempo real requerem uma t;\Xa mfnima de envio, n;lo querem atras.1r excessivamcmc a tronsmissolo de segmentos c podem tolerar uma certa perda de dados, o modelo de serviço do TCP não é particular· mente comp:uavel com tssas necessidades das aplicações. Como drscutiremos mais adiante, essas aplicações podem usar UOP c implementar, como pane da aplicação, qualquer runcionalidadc adicional necessária além do ~rvit;o d~ ~ntrcga d~ scgm~mos simples c básico do UDP. Nclo Ira rswbrlccimcnto ele conrxtlo. Como discutiremos mais adiante, o TCP usa uma apresenta· t;:lo de tr~s vias antes de começar a trorlSferir dados. O UOP simpksmc.>ntc envia mensagens sem nenhuma preliminar formal c, assim. não introduz nenhum atraso para estabelecer uma conexão. Provavelmente esta é a principal razão pela qual o DNS roda sobre UDP, c n:lo sobre TCP- o DNS seria mtrito m:1is lento se rodasse em TCP. O HTTP usa o TCP, c m1o o UDP, porque a confi abilidade ~ funda mental pam págin;~s Wcb com texto. Mas, como discutimos brevemente na Seção 2.2, o atmso de estabeleci mento de uma conexão TCP t um:l contribuiç•\o importame aos atrasos associados il rcccpçao de documentos Web. Nela hcl c:siCiclos clt' conr;cM. O TCP mamêm o estado de <:onexno nos sistemas finais. Esse est;~do inclui burfers de envio c reçebimcnto. partlmetros de controle de congestionamento c par..\melros numericos de scquênciôl c de reconhecimento. Veremos na Seçno 3.5 que essa informação de estado ê necessária p.1ra implementar o senriço de transreréncia confiável de dados do TCP c para prover cont role de con· gestion;~mcmo. O UDP, por sua vez, não mamém o esmdo de conexão c não monitoro nenhum desses par.1metros. Por essa mzão, um sen'idor devot;~d o a uma aplicação cspecíOc;~ pode suportar um número muito maior de clientes auvos qu.tndo a aplicação roda sobre UOP c m\o sobre TCP. PC'quena ~obrrcargo de cobcçolho de pacorc. O segmento TCP tem 20 bytes de sobrec:trga de cabeçalho ;~lém dos dados paro cada segmento, enqmmto o UDP tem somente 8 bytcs de sobrecarga.

A Figura 3.6 relaciona aplicações populares da Internet e os protocolos de tmnsporte que elas usam. Como era de esperar. o e-mail. o acesso a terminal remmo. a Web e a tronsrcrência de arquivos rodam sobre TCP todas essas aplicações necessitam do serviço conOável de transferência de dados do TCP. Nào obstante, muitas aplicat;ôcs importantes executam sobre UDP, c não sobre TCP. O UDP é usado p;~ra atualiz:~çM das tabelas de roteamento com o protocolo RIP (rollling iufonnellion t>rotoc~>l- protocolo de informação de roteamento) (veja Seção 4.6.1). Corno as atualrzaçõcs RIP são enviadas periodicamente (em geral, :1 cada 5 mmutos). atualizações perdidas scr:\o substitufdas por atualizaçõcs mais recentes, tornando inútil a rccuperaç:lo das tuu;~lizaçóes perdidas. O UDP tam bém é usado para levar dados de gerenciamento de rede (SNMP; vej;t o Capítulo 9). Nesse caso, o UDP t prcfcrlvcl 110 TCP, j~ que apli<:açõcs de gercr1ciamemo de rede frcqltentcmcntc devem rtmeionar quando a rede está em estado sobrec~1rregaclo - cxatameme quando é diHcil conseguir transferência confi:lvel de dados com congcstionmncnto controktdo. E t;mtbém. como mencionamos anteriormente. o ONS roda sobre UDP. cvi· t;,ndo, desse modo. atrasos de cstabelcdmcnto de conexões TCP. Como mostm a Figura 3.6, hoje o UDP c o TCP tambêm é comumente usado p:•ra aplicações de multimídia, como telefone por Internet, videoconrerencia em tempo real e recepção de áudio c vfdeo armazenados. Exanunarcmos essas aplicações mais ele perto no Capitulo 7. No momento, mencionamos apenas que todas ess.'\S aplic:tçôcs podem tolerar uma pequena quantidade de perda de pacotes. de modo que :1 tmnsfcr~ncia confiá\'el de dados não é absolutamente crítica para o sucesso da apUcaç;.io. Além disso, aplia•çõcs em tempo real, como teteronc por lntcmct c ''idcoconrcr~ncia, reagem muito mal ao controle de congestionamento do TCP. Por essas razões, os desenvolvedores de aplicações de multimídia muitas vezes optam por rodar suas aplicações sobre UDP em vez de sobre TCP. Entretanto, o TCP está sendo utilizado cada vez mõlis para trorlSporte de mídia. Por exemplo. (Snp:tnldkulchar. 20
bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------Aplica~3o

Protocolo de camada de aplica~3o

Protocolo de transporte subjacente

Coueio eletrônico

SMTP

TCP

Acesso a terminal remoto

Telnet

TCP

Web

HTTP

TCP

Transferênoa de arquivo

FTP

TCP

Servidor remoto de arquivo

NFS

tipicamente UDP

Recepç~ de

tipicamente proprietària

UDP ou TCP

Telefonia por Internet

tipicamente proprietária

UDP ouTCP

Gerenciamento de rede

SNMP

tipicamente UDP

Protocolo de roteamento

RIP

tipicamente UDP

Traduç!o de nome

DNS

tipicamente UDP

multimfdia

Figura 3.6 Aplicações populares do Internet e s.eus proto
Em bom :.uualrncn te seja comum rodar aplicações de muhimfdía sobre UOP, isso é con n ovcrtido. Como já mencionamos, o UOP n:l o tem controle de congestionamcmo. Mas esse controle é necessário para evitar que a red e entre em um estado no qual pouqufssimo trabalho uul é realizado. Se todos co meça sem a enviar vfdco com alta mxa de bits sem usar nenlmm controle de congestion~unento. haveria tamanho transbordamento de pacotes nos roteadores que poucos pacotes UOP conseguiriam atravessar com sucesso o caminho da rome ao destino. Além do mais, as altas taxas de perda induzidas pt"los remetentes UOP ~em controle fariam com que os remetemes TCP (que, como veremos mais adiame. redu<,rrn suas taxas de env1o em raee de congestionamemo) reduzissem drasucamcntc suas taxas. Assim , a falta de controle de congcsuona men to no UOP pode resultar em altas taxas de pt"rda entre um remetente e um destinatário UOP e no :~cumulo de sessões TCP- um problema potcnctahnente sério [Ftoyd, 19991 . Muitos pesquisadores propuseram novos mecanismos para força r todas as rontes, inclusive as remes UDP, a reali zar um conrrole de congestionamento adaptativo [Mahdavi, 1997: Floyd. 2000; Kohler. 2006: RFC 43401. Antes de discutirmos a estrutura do segmento UDP. mencionaremos que t poss1vel que uma <~plicaç;lo tenha transferCncia confiável de dados usando UO P. Isso pode ser feito se a conOabllldade for embutida na própria aplicação (por exemplo. adicionando mecanismos de reconhcdmcnto c de retransmiss:\o, tais como os que csllldarcmos na próxima seção). Mas esta é uma tarda não trivial que manteria o desenvolvedor ocupado com a depuraçi\o por um longo tempo. NãO obstante, crnbut.ir confiabílid:tde diretamente na aplicay10 permite que ela tire proveito de ambttS as alternativas. Em outras palavms. os processos ele
3.3.1

Estruturo do segmento UDP

A estruwra do segmento UDP, moSLmda na Figura 3.7. é definida no RFC 768. Os dados dn :1plica(-la verdade, a soma de vcrificar.<~o também é calculada para alguns dos campos no cabeçalho IP, além do segmento UOI'. Mas ignoramos esse detalhe para podermos enxergar a floresta por entre as árvores. Discutiremos o cálculo


(ornada de lronsporh

153

32 bits

Porta da fonte lt

Porta do destino lt

Comprimento

Soma de verif1caçoo

Dados da aplicaçáo (mensagem)

Figura 3.7 Eslruturo do segmento UDP da soma de ''crint·a~ao mais adiame. Os princípios básicos da dctecçilo de erros cst;lo descritos na Scç-Jo 5.2. O <.
3.3.2 Soma de verificação UOP A soma de ' 'erificaç.lo UDP serve para detectar erros. Em o utras palavras, t usada p;1ra determinar se biiS dentro do segmento UDP Coram alterados (por exemplo, por ruído nos enlaces ou enqu:u11o armazenados em um

roteador) clurnntc sua movimcmaç
0110011001100000 0101010101010101 1000111 100001100 ;.\ soma das duas primeiras dessas pala,•ms de 16 bi l5 é:

o110011001100000 0101010101010101 1011101110110101 Adicion:mdo a tercei ra palavm à soma acima, temos: 101 1101110110101

10001 11100001100 Ol0010101LOOOOLO Note que essa última adição te,·e ~vai um· no bit mais significativo que roi somado ao bit menos sigl1ifiC'.uivo. O complcmemo de 1 é obtido pela conversão de todos os O em 1 c de todos os 1 em O. Desse modo. o complemento de 1 da sorna 0100101011000010 é 1011010100111101 . que passa a ser a soma de ' 'crificaç:lo. No destinatário. todas as quatro palavras de ló biiS s.'o somadas, inclusive a soma de vcrificaç-Jo. Se nenhum erro ror inLroduz1do no pacote, a soma no destinatário suá, obviamente, I 111111111111111 . Se um dos biiS for um zero. saberemos em;lo que houve inuoduç-J.o de erro no pacote. Provavelmente voce esta imaginando por que o UDP fornece uma soma de venflcação em primeiro lugar, visto que muitos protocolos de camada de enlace (dentre os quais, o popular protocolo Ethcrnct) também for-

bow4tto4ic~ Redes de co 11 putod ores e o In;.;l~e;.; rn ;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

neccm verlficaç:lo de erros. A rnz~\o ~ que não há garnnúa de que todos os enlaces entre a origem c o destino forneçam venficaç:\o de erros- um dos enlaces pode usar um protocolo de camada de enlace que não forne\"3 veriOcaç-.lo de erros. Al~m disso, mesmo que os segmentos sejam corretamente transmitidos por um en lace, ~ possivcl haver introdução de erros de bits quando um segmento~ annazcnado na memória de um roteador. Dado que não são garanudas nem a confiabilidade enlace a enlace, nem a deu:cçllo de erro na memória, o UDP deve prover detecção de erro fim a fim na camada de transporte se quisermos que o scrv~ço de transferl!ncia de dados fim a fim forneça detecção de erro. Esse é um exemplo do famoso principio a fim do projeto de sistemas ISaltzcr. 198·11. Esse princípio allrma que, uma vez que é dado como certo que funcionalidades (detecção de erro. neste caso) devem ser lmplemenmdas fi m a fim, "funções t"olol.
nm

Como se pre tende que o l ? rode sobre qualquer protocolo de l",unada 2, é t\lil que a camada de transporte forne<,"a verificação de erros como medida de segurança. Embora o UDP forneça verificação de erros, ele nada faz pum re~.:upc rar um erro. Algumas implementaçõeS do UDP simplesmente dcsc:~rtm11 o segmento danirlcado: outras passam o segmento errado à aplicação acompanhado de um aviso. Isso ence rra noss.1 disc ussão sobre o UD P. Logo veremos que o TCP oferece trans ferência eonri ável de dados ~is suas :1plicaçõ cs, bem como outros serviços que o UD P não oferece. Na turalmen te, o TCP também é mais

complexo do que o UDP. Co ntudo, antes de discutirmos o TCP, primeiramente devem os examinar os princípios s ubjacentes da transfcrfncía confiável de dados.

3.4 Princípios da transferência confiável de dados Nesta seção, consideramos o problema conceitual da transferência confiá,·el de dados. Isso é apropriado, já que o problema de implementar transferência confiável de dados ocorre não somente na l."amada de transporte. mas também na camada de enlace e na camada de aplicaç-ao. Ass• m. o p roblema geral é de •mport:lncia central para o trab:tlho em rede. Na verdade, se tivéssemos de fazer u ma lista dos dez ma1ores problemas fundamcmalmente import:lntes para o trabalho em rede. o da transferência confi á,•el de dados seria o candidato n úmero um da lista. Na seção seguinte, examinaremos o TCP e mostraremos. em espccmJ, que ele uuliza muitos dos princípios que descreveremos aqui. A Figura 3.8 ilustra a es trutu ra para nosso estudo de transfcr~ncia confiável de dados. A abstraç;lo elo ser,'iço fornecido às entidades d as ca madas superiores é a de um canal co nlhlvel através do qual dados podem ser transfe· ridos. Com Ltm canal co nfi ável, nenhum dos dados transferidos é corro mpido ( trocado de O pam 1 ou vice-versa) nem perdido, c todos s:\o e ntregues na ordem em que foram enviados . Este ê exatamente o modelo de ser\'iço

oferecido pelo TCP às aplicaçóc:s de Interne! que recorrem a ele. É responsabilidade de um protocolo de tra nsferência confiável de dados implementar essa abstração de serviço. A t:~rda é d lficult:~da pelo rato de que li C;lmacla CIVtliXO do protocolo de tra nsfcr~ nd a confi;\vcl de d;~dos pode se r não co nlláve l. Por exe mplo, o TCP e um protocolo confiáve l de transfcrenc ia ele dados que é imple· mentado sobre uma canmda de red e fim a IIm não con[iávcl ( IP) . De modo mais geral, a camada ~'baixo das d u~u; extremidades que se comu nicam eonfia,•elmentc pode consistir em um unico enlace rlsico (como ~ o caso, por exemplo. de um protocolo de transferência de dados na camada de enlace) ou em uma rede global interligada (como é o c:-JSo de um protocolo de t."amada d e transporte). Para nossa fi nalidade, contudo. podemos considerar essa camada mais baixa sim plesmente como um canal ponto a ponto n~\o confiável. Nesta se,Jo. dcscn,•olvcrcmos gradualmente os lados remeterne c destinatário de u m protocolo conliávd de transfcrenda de dados. considerando modelos progTessivamcm e mais complexos do canal su bjacen te. t\ Figura 3.8( b) ilustra as mterfaccs de nosso protocolo de transrcrcncia de dados. O lado remetente do protocolo de transfer~ncia de dados ser.i invocado de cima, por uma chamada a r dt_se nd ( ). Ele pass.1r.i os dados a serem entregues à camada superi or no lado destinatário. (Aqui, rdt representa o pro tocolo de transferência confiável de dados lreliable data transferi e _send indica que o lado remetente elo rdt está sendo chamado. O primeiro


(ornada de lron spo rh

155

--------- ----------------- -t ----ProtO
Camada de transporte

ProtO
uLd send()

Camada do rede CaMin30 conll~11el

a. Servi~o fornecido Legendit: Dados

PitCote

r.gura 3.8 Tronsfelênóo confiável de dados: roodelo do serviço e~~õo do seMÇO

passo no desenvolvimento de qualquer pro tocolo é dar-lhe um bom nome!) Do lado destinatário, rdt_rcv( ) será chamado qmmdo um pacote chegar do lado dcstinalário do canal. Quando o protocolo rdt quiser entregar dados à t-amada s uperior, de o fará c hamando de 1i ver_da ta ( ). No que se segue, us:tmos a terminologia ' pacote' em vez ele 'segmento' de camada de transporte. Como a teoria desenvolvida nesta scçno se aplica a redes de computadores em geral, c não so mente à e-amada de transporte da lmernct, o termo gcntrieo ·pacote' talvez seja muis apropriado aqui. NesHt scc;;lo, consideramos apenas o caso d e tran.-.feri!ncia unidin:c:ion al de dados, islO é, transferf:nc:ia de dados do lado remetente ao lado destinatário. O caso de tTansfer~ncla bidireclonal confiável de dados (is to é, f ull-clurJicx) não é conceitualmente mais dific:il , mas é bem mais tedioso d e ex plicar. Embora consideremos apenas a transrerência unidirccional d e dados, é importante notar que. apesur disso, os lados remclcntc c destinatário de nosso protocolo 1er.'\o de transmitir pacotes em ambas as d ireçoes, como mostra a Figuro~ 3.8. Logo veremos que, além de trO{-a r f>a<:otcs comendo os dados a trnns rerir, os lados remetente c destinatário do rdt também prectsarao trocar pacotes de controle entre s i. Ambos os lados de envio c destino elo rdt enviam pacotes para o omro lado por meio de uma chamada a udt_send( ) (em que udt representa transferencla n11o confiável de dados- unrdicrb/r cllllll mmsjrr).

3.4.1

Construindo um protocolo de transferência confiável de dados

Vamos percorrer agora uma série de protocolos que vão se tornando cada vez ma is complexos, até chegar a um protocolo de transferência co nfiável de dados impecável.

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; ro;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Transferência confiável de dadossobre um conal perfeitamente confiável: rdll .O Vamos co ns iderar primeiramente o caso mais s imples, em que o canal subjacente é complet:unente confiável. O protocolo em si, que denomi naremos rd tI . O, é trivial. As definições de máquina d e ~tad o finito (jlnite-stcue mcrchiue - FSM) para o reme teme c o destinatário rd t.l . O sao apresentadas na Figura 3.9. A FSM da Figuro 3.9(a) define a operaç;\o do remetente. enquanto a FSM da Frgura 3.9(b) define a operaç:lo do desunatárr o. t:: unportante notar qu e há FSM separadas para o remetente c o dcs unat:irio. Ambas as FSM da figura 3.9 t~m apenas um estad o. As setas na dcsc riç
O lado remetente do rd l simplesmente
......

............... Esperar

chamada

J

' dt_srnd(rt<~U l p.1cket lldkl' p~lf ddtd lldt_s~ ntJ(P•JCkct

de cima

l

a. rdt1 .0: lado remetente

.................. Esperar

channada

J

de baixo

rdt _rc v(polcket> tAiracttpolcket.o~t•> dellvrr_daUt d•ta )

b. rdt 1.0: lado destinatário

Figura 3.9 rdtl.O - Um protocolo poro um conol completamente confiável


(ama da de lronspo1le

157

Transferência confiável de dados por um canal com erros de bits: rdt2.0 Um modelo mais realista de canal subjaccote é um canal em que os bits de um pacote podem ser corrompidos. Esses erros de bits ocorrem normalmente nos componentes frsicos de uma rede enquanto o pacote é transmitido, propagado ou armazenado. Continuaremos a admitir, por enquanto, que todos os pacotes transmitidos sejam recebidos (embora seus bits possam estar corrompidos) na ordem em que foram envmdos. Antes de desenvolver um protocolo para se comunicar de maneira confiável com esse <.'"anal, considere primeiramente como as pessoas enfrentariam uma siluaçilo como essa. Constdcre como voce duaria uma mensagem longa pelo telefone. Em um cenário úpico, quem esliv<:Sse anotrmdo a mensagem diria 'o.k.' após cada sen tença que ouvisse, entendesse c anotasse. Se a pessoa ouvisse uma mensagem trun<.-ada, pediriroLOcolos de t ransfcr~ncla confiável de dados baseados nesse ti rJO de re trn nsmlss:'lo s:'\o conhecidos como protocolos ARQ (Automatic Repeat reQuest- solicitaçã o automática de repetição). Essenci:~ lm entc,

são exigidas tres capncitaçõcs adicionnis dos protocolos ARQ para m:tnipular a presença de

erros de bits:

Detcc(ilo ck r1 ros. Primeiramente, é preciso um mecanismo que permita ao destinatário detectar quando ocorrem erros. Lembre-se de que dissemos na seção anterior que o UDP US:.I o c-ampo de soma de vcrificaç:lo da Internet ex:namente para essa final idade. No C.1pftulo 5, examinaremos, com mais detalhes, técnic;\S de detecçilo c de correção de erros. Essas tecnic:as pcrmuem que o destinmário detecte c possivelmente corrija erros de bits dt' pacotes. Por t'nquamo, bas t.'l saocr que essas técnicas exigem que btts extras (além dos bits dos dados originais a serem transferidos) sejam en vmdos do remetente ao dcsunatáno. Esses bits são colocados no campo de soma de vcnfiC'a~"âo do pacote de dados d o protocolo rdl2 .0. Rtcdimcntaçtio tio tlcstinaldrio. Uma vez que remetente e dcstinat.mo nonnalmcnte estejam rodando

em sisu:mas fin
Rttmnsmiss1lo. Um pacote que é recebido com erro no destinatário será retransmitido pelo remetente. ;\ Figum 3. LO most m a reprcscn taç:\o por FSM do rd l2. O, um protocolo de ernusfel'encía de dados que detecção
emprcg<~

O lado rcmcterue do rd t2. O tem dois estados. No estado mais 1\ csquerd;~, o protocolo do lado remetente está es perando que os dados sejam passados pela camada s uperior. Quando o evento rdt._send(da ta) ocorrer. o remetente crl:1rá um p.1cote (sndpk t) contendo os dad os a serem erwiados. juntamente com uma soma d e verifil
bow4tto4ic~ Redes de compu tadores e o lnte;.;rn;.;e;.;,t_________________________

dcsúnat:\rlo recebeu corretamente o pacote em questão. Devido a esse comportamento, protocolos como o rd t2. Osâo conhecidos corno protocolos pare c espere (swp-and-wait ). A FS~I do l:tdo destinatário pam o rd t 2 . O tem um linico estado. Qu:1ndo o p.tcotc chega, o destinatário responde com um ACK ou um NA I<, dependendo de o pacote recebido cst:tr ou não corromptdo. Na Figura 3.10, a not3\' corrcsponde ao e,·ento em que um pacotr t recrbido c existe: um erro. Pode parecer que o protocolo rdt2. O funciona. mas ínfclizmcmc ele tem um defeito fatal. Em especial, ainda n:lo tratamos da possibilidade de o pacote ACI< ou NAK estar corrompido! (Antes de contin u:~r. t bom voce começar a pensar em corno esse problema pode ser resoh-ido.) Lamentavelmente, nossa pequena omissão não é tão inofensiva quanto possa parecer. No mínimo, precisaremos adicionar aos pacotrs ACKINAK bits de soma dr verificação para detectar esses erros. A questão mais dirícil t como o protocolo deve se recuperar de erros em pacotes ACK ou N1\K. Nesse caso, a dific uldade é que, se um ACK ou Ltm NAI< estiver corrompido. o remetente nilo terá como salx:r se o dl.'s tinat:\rio recebeu ou não corrctamclllc a última parcela de dados trans mitidos. Considere trCs possibilid:tdts para manipular ACKs ou NAKs corrompidos: Para a primeira possibilidade, i m<~gi nc o que um ser humano r:tria no ceuário do ditado da mensagem. Se quem estiver di.t:1ndo nüo cmender o 'o.k.' ou o 'Replta, por favor' do destinatário, provavelmente pergumanl: "O que fo i que você disse?" (ímroduzindo assim um novo tipo de pacote rcrnctcme·dcstiu:H:Irio em nosso protocolo). O locmor e mão repetiria a resposta. Mas c se a frase ·o que foi que

sR
udt_send
~ Esperar chamada de cima

rdt

E$perar

ACK ou NAK

rcvtrcvpl tl t& lsACKtrcvpkt l 1\

a. rdt2.0: lado remetent e

rdt revi rcvpkll && corr upl UcvpH) , ',

( } udpk~~• .,l;e_pkl( NAI() tull s~nd( sndpktl

',._

Esperar chamada de baixo

eAtr•c t (rcvpkt .d• t •) d~l1v~r_da lald a t~) $1dp k l•~
udt stnd'sndpkt)

b. rdt2.0: lado destinatário

Figura 3.1 O rdt2.0 - Umprotocolo poro um mnol com erros de bits


(ama do de transpor te

159

voei! disse?" estl\'essc corrompida? O destinatário, sem ter nenhuma n~o se a seruença corrompida era pane do ditado ou um pedido para repelir a última resposta. provavelmeme respo nderia: -o que fot que \'OCc disse?· E então, é claro, essa resposta tmnbém poderia estar truncada. Ê óbvio que estamos entrando em um caminho dirtcil. Uma segunda ahern:uim é adicionar um nttmero s uficiente de bhs de soma de vcrificaç:1o para permitir que o remeten te nao somente detecte. mas também se recupere de erros de bits. Isso resolve o problema imediato para um canal q ue pode corromper pacotes. mas não perdê-los. Uma tercei ra abordagem t o remctemc simplesmente reenviar o pacote de dados corrente quando receber um pacote ACK ou NAK truncado. Esse método. no entanto, introduz pacotes dup licados no canal remetente-des tinatário. A dificuldade fundamental com pacotes duplicados é que o destina tá rio não sabe se o úh tmo ACK ou NAK que enviou foi recebido corretameme no remetente. Assim, ele não pode sal>cr 11 fJI io1l se um pacote que chega contém novos dados ou se é uma rctransmiss;'\o! Um a solu<'âo s imples para esse novo ()roblema (e que é adotada em quase todos os protocolos de transfer~ncia de dados existentes, inclusive o TCP)

é ad icionar um novo campo ao pacote de cl:~dos c fazer co m q ue o remeten te numere seus pacotes de dndos colocando um número de scquência nesse campo. O destinatário cnti\o teria apc r1as de vcrifkar esse n úmero de scqutn cia p<'m determinar se o pacote rcccbtdo é o u n;lo uma rctransmiss:lo. Para esse caso simples de protocolo pare c espere, um mímcro de scq ucncia de u m bit t suficicme, já que pcrmitim que o destinatário saiba se o re me teme está reenviando o pacote previamente transmitido (o mímcro de sequ\!ncia do pacote recebido é o mesmo do pacote recebido mais recentemente) ou u m novo pacote (o número de seq uência muda, indo kpara a frente• em progress
rd t_sellil ld •ta I $ndp~ t...., k e

e>kliO .d•u.chechu udt.st>nd( sndpkll

/

"' 8

~

1 ~"I.KI rcvpkl

))

r dt.rcv
rdt_rcvl I'CvpH I

&& IIOlCO r I IJpl( rcvpkt)

M IIOlCOI r upt( r cvp! l) && 1 SIICKI rcvpkt I

.!.& lsACK< rcvp kl l

f\

" Espera r chamada 1 dedma

Esperar CKou NAK 1

rdt _rcv
C

(corrupt
'-

/

.............._

uat_sendl$ndpktl snOP• 1-tlilke_pU( I,OaU.Cht>C l Sua) udt_sendlsndp~tl

Figura 3.11

rdt_rc~lrcvpl
rdt2 .I remetente

bow4tto4ic~ Redes de computadores e o lnte ;.; ro;.;e;.;.t_________________________

rdl r o ( rcvpkt ) && no~corrup t ( I"C'
rc.pU

>

extract(rcyp ~ t . dJtal d~ll;er_dat4(data)

sndp ~ t~ke_p~tiAtK . ch~cksu~l

relt_rcvcrcvp , t) A& corrupl(rC•P kl)

kdt_srncsrsndOktl

''

sndpr t "WWa t e.pkt ( h 4K.chl'C k
''

' 'lt

~

"-..,.

~ Esperar Ode

Esperar 1 de

UlfllCI ( I"Cvpkt, dllld) delive r_dat•ld"t"l

sndpkt•make_pkt !AtK.chtcksum) udt_sendlsndpLl l

Figura 3.12 rd12.1destinolório enviado (pelo rcmctenre) ou aguardado (no destinaulrio) deveria ter um n umero de scquência O ou I. 1 01e que as ações nos estados em que um pacote numerado com O esta sendo enviado ou agu:~rdado S
Transferência confiável de dados por um canal com perda e com erros de bits: rdt3.0 Su ponha agora Cjue, além ele corromper bitS. o canal subjacent e poss.1 perder pacotes, um acomecimento que não é i11comum n:tS redes de computadores de hoje ( induindo a Internet). Duas preocupações adicionais devem agora ser tratadas pelo protocolo: como detectar perda de pacote e o que fucr quando isso ocorre. A utilização de soma de vcnlicaç.1o. nu meros d e sequéncia, pacotes ACK c rclrlu\SrntssOCS- as técnicas J:í desenvolvidas em rd t2. 2 - nos permitirá a tende r a última prcocupaç.lo. Udar com a primerm prcocupa\'ão. por s ua vez, exigirá a adiç;l o de um novo mcC:Inismo de protocolo. Há muitas ;~bordageJ\S possrvcis parn lidar com a perda de pacote (c dtvcrsas delas ser.lo estudadas nos cxcrdctos ao final do caprtulo). AqUI. atnblllrcmos ao remetente o cnC:Irgo de detectar c se recupcmr das perdas de pacote. Suponha que o remetente transmita um pacote de dados e que esse pacote, ou o ACI< do seu destinatário, seja perdido. Em qualquer um dos casos, nenhuma resposta chegará ao remetente vinda do destinatário. Se o remetente

bow4tto4ic~ Camada de lronsporle

( opllul o 3

......

161

............ ~

rdt.rcvCrcvpktl nctcorrllptlrcvpkll Jt& I sACKI rcvJl • t .0 I

rdl.rcvlrcvpkt )

~~

&& Oi\lçor r1•fl l CrC•P
1\

1\ Es~rar

chamada 1 de cima

sndpkl-.~~e pkt Cl.d4l4. chcc k su~) udt .sendlsndpkt)

figura 3.13 rdl2.2 remetente esti ver disposto a cspcmr o tempo s ufk aente para ter ccrtc:lcorrupl( rcvptt I U hdLHtQO( rcvpU 1

txtractlrcvpkt ,ddtal 110 I h~r.dõt~( d.Jlcl l sndptt·~ak~pkt i~CK . O.checksuml

1\

c

onct> l. hq• O

......

r•Jl rcvlrcvpkll U I corrupt ( rcvpkt) li IIH .Sc<~ICrcvpktl)

lf!Of>CP.thru-1 l

...

' ...

uol_send(sndpktl OIICtH hr u• l

... ~ Esperar

EsJN!rar

Ode baixo

1 de baixo

udt_sendtsndpktl

rdt.rcv( rcvpl\l I && notcorr upl
deltver.data!data) sndpkt-.ake_pkl!A(t . l . chec~s~l

•dt_~~··
Figura 3.14 rdt2.2 destinotório

rdt.rcvt I rcvpt• t I li h~~ -seqOircvpltll lHit.~~ndl sndpkt

I


saber com certeza. Alt rn d isso, o ideal seria que o protocolo se recuperasse da perda de pacotes logo que possível; esperar pelo ntraso do pior dos casos pode sign ifrcar um longo tempo até q ue a recu peraç;lo do erro seja iniciada. Assi m, a abordagem adotada na prática é a scguim e: o remetente faz uma escolha ponderada de um valo r de tempo d entro do qual seria pro,'ável. mas n;lo garantido. q ue a perda ti,•csse acontecido. Se n
A Figura 3. LS mosLra a FSM remetente para o rd t3. O, um protocolo que tra nsfere confi~vclmeme dados por u m t.-anal que pode corro mper ou perd er pacotes: nos "Exercícios de l'hmçüo~ pediremos a \IOC~ que projete a FSM d estinatária para rd t 3 . O. A Figura 3. 16 mostra como o protocolo funcio11a ~ m pacotes perdidos ou atrasados e como manipula pacotes de dados perdidos. Nessa figura , a passagem do tempo ocorre do topo do diagrnma para baixo. No te que o inst:mtc de recebimento de um pacote é neccssaríamcmc posterior ao instante de cn\'io de um pacote, como resuhado de atrasos de transmiSsão e de propagação. as figuras 3.16(b-d), os colchetes do lado remetente mdicam os instantes em que o temporizador foi acionado c, ma1s ta rde, os mstantcs em que ele parou. Vários dos aspectos m:us suús desse protocolo são examinados nos exercidos ao final deste rnpnulo. Como os númcros de sequl!ncia se alternam entre O e I , o protocolo rd t 3 . O às vezes é conhecido como protocolo bit a he.mante_

rdt_send<
rdt_rcvC• cvp~ ll U

starl_tl~er

!< rrupttr~vpk tlll

~ . / ) ls-'CK!rc ~ kl.lll

'',,, rrlt rcvcrcvp ktl ç

udt_sencHsndpkll

)&

11

::>

,t'

'

Esperar chamada Odecima

Esperar ACK 0

tlmeout tldl sl'ndC sndpl.l

sloJrl time•

n lt rcv( rcvpU)

M notcorrupt( rcvpktl 3A

ICH

I~ACK(rcvpkt . l)

t1111eout u.Jt_s~nd(Snclp
st~ • t_llllcr

cv

rdt_rcv
I r.ACK( rcvrtt. Ol)

stop_t taer

Espera r

Esperar

ch am~da

ACK 1

~lde c·tma"""

~

I rdt_send< Clatd 1

--------------------

sndpkt••4~e-pkLCI . d~tJ , ch~c k suQ)

udt

send(Wdp~l)

Slart_tiaer

Figura 3.1 S rdt3.0 remetente

rcv! r c v ~H)

U notcorrupt
Hop_LIIlf!r

rdt rcv(rc,p>l l {\


Destin
Remetente envia pktO

~

recebe pktl envia ACKl

~

recebe ACK1 envia pktO

~

: recebe pktO envia ACKO

~

reenvia

pktl


"

envia pktO

Pkro

~

•~

recebe ACKO envia pktl t emporiuçao r~nvia pkt1

í

L


•

:

X (~rda):

.

Pku

~

~

~

envia pktO

recebe ACKO

~ re,ebe pktl

p..~ envia ACK 1

perda) ~

recebe plctl (detecta duplicaç.)o) envi;, ACK1

~ ~ l~ .

envia pktl [ temporizaçao reenvia pltt1 recebe ACK1 envia pktO recebe ACKl nc'lofaznada

recebe pktl envia ACK1

recebe pktO envia ACKO

" Destinatário

Remetente


~

~

Plru

~

b. Pacote perdido

Destinatário

Remetente

~


~~

.

a. Operaçc'lo sem perda

~

re
163

Destinatário


~

recebe ACKO envia pktl

Remetente envia pktO

~


~

~


~

~ Plcu

,

~

~ ~ ~

.Y"

~

:~ •

recebe pktl envia ACK1 recebe pkt 1 (detecta duplica) envia ACK1 recebe pktO envia ACKO

----._. recebe plttO ei'IVia ACKO

c. ACK perdido

d. Temporizaç&o prematura

Figura 3.1 6 Operoçõo dordt3.0, oprotocolobit oltemonte Agoro já reunimos os elcmcruos fundamentais de um protocolo de transfcrencla de dados. Somas de vcriOcan(rmcros de sequencía. temporizadores c pacotes de reconhecimento negativo c positivo -cada um desempenha um papel crucial c necessário na operação do protocolo. Temos agora em funcion:1mcnto um protocolo de transfcrCncia confiável de dados! ~\o,

3.4.2 Protocolos de transferência confiável de dados com paralelismo O protocolo r dt3 . O é correto em Lermos funcionais. mas é pouco provável que alguém fique contente com o desempenho dele, particularmente nas redes de alta velocidade de hoje. No coração do problema do desempenho do r d t3. O está o fato de ele ser um protocolo do úpo pare c espere. Para avaliar o impacto sobre o desempenho causado pelo componamenlo "pare e espere", considere um caso ideal de dois hospedeiros, um localizado na Costa Oeste dos Estados Unidos e ou1ro na Costa Leste, como mostra a Figura 3.17.


-

Pa
Pa
b. Um protocolo com paralelismo em opera~o

a. Um protocolo pare e espere em oper~ão

Figura 3.1 7 Protocolopore eespere

vemJ5 protocolo tom

porolelismo

O atniSO de propagaçt\o de id•Le (8 mil bits). incluindo o campo de cai>eçalho c também o de dados. o tempo necessá rio para realmen te transmitir o pacote para o enlace de l Gi>ps é:

A Figura 3.18(a) mostra que, com nosso protocolo pare c espere. se o remetente começ:~r a enviar o pacote em 1 O, entào em 1 UR 8 microssegundos, o úl timo bit entrará no canal do lado remetente. O pacote então faz sua jornada de 15 milissegundos atravessando o pais, com o último bu do pacote emergindo no destinatário em L = RTT/2 + UR = 15,008 mihsscgundos. Supondo, para simplificar, que pacotes ACK sejam extremamente pequenos (para podermos ignorar seu tempo de transmissão) c que o destinat.1rio pode enviar um ACK logo que receber o úhirno bit de um pacote de dados, o ACK emergirá de volta no remetente em 1 RTT + UR = 30,008 milbscgundos. 'esse pon to. o remetente agora poderá transmiúr a próxima mensagem. As... im, em 30,008 milissegundos, o remetente esteve cm'iando 1>or apenas 0.008 milisscgundo. e definirmos a utilização do remetcme (ou do canal) como a fmção de tem po em q ue o remetente está realmente ocupado enviando bits para den tro do canal, a an:ilise da Figura 3. 18(a) mostra que o protocolo pare e espere tem uma utilizaçâo do remetente U,_, b:•sHmtc desa nimadora, de:

=

=

=

=

u

rrmtl

•

LfR

IOT + L/ N

•

o.oos. o'00027

30,008

Pon:mto, o remeten te ricou OCltpado apcnus 2,7 centésimos ele 1 por cctuo do te mpo! Visto de outra mancim, ele só fo i capaz de enviar 1.000 bytcs em 30.008 milisscgundos. uma vattio efetiva de at}enas 267 kbps - mesmo estando disponível um enlace de l gigabil por segundo! Imagine o infeliz gerenciador de rede que acabou de pagar uma fonuna para ter capacidade de enlace da ordem de gigabits, mas consegue uma \razão de apenas 267 quilobits por segundo! Este é um exemplo gráCico de como protocolos de rede podem limitar as capacidades oferecidas pelo hardware subjacente de rede. Além disso. desprezamos também os tempos de processamento de protocolo das camadas inferiores no remetente c no dcstinatáno, bem como os atrasos de processamento c de fila que ocorreriam em quaisquer roteadores intermediários existentes entre o remetente e o destinatário. Incluir esses efeitos serviria apenas para aumen tar ai nda mais o a traso e piorar amda mais o fraco desempenho. A soluç.\o para esse problema de desempenho em cspec1al é s1mples: em vez de operar em modo pare e espere, o remetente é autorizado a enviar vários pacotes sem esperar por reconhecimentos, como mostra a Figura 3.17(b). A Figura 3. 18(b) mostra que, se um remetente for autorizado a transmitir três pacotes an tes de tc.r de

bow4tto4ic~ (opilulo 3

Remetente

Primeiro bit do primeiro pacote transmitido, t • O último bit do primeiro ---.....,.~; pacote transmitido. t • L/R

pró~ imo

165

------------------·... ~ :-

t

lronsporle

Destinatário

- Prime~ro

ACK chega, envia

Camada de

b•t do primeiro pacote chega

OIHmo ~·do P
-----------------:..

pacote.

=RTT+UR

.,

.,.

a. OperaçAo pare e espere

Remetente

Deninatário

Primeiro bit do primeiro pacote t ransmitido. t • O Último bit do primeiro - - - - pacote transmitido. t •L/R

ACK chega, envia próximo pacote. t=RTT+LIR

.,. b. Opera~.\o com paralelismo

.

•

Figura 3.1 8 Envio com pore eespere ecom paralelismo

esperar por reconhecimentos, sua utilizac;:'io será essencialmente triplicada. Uma vez que os muitos pacotes em tr.lnsito entre remetente c destinatário podem ser visualizados como se estivessem enchendo uma tubula""o, essa Lecnica é conhecida, em inglês, como pipclining ( tubulação) . Porém, como essa expressão é dificil de traduzir para o português, preferimos us.1r 'paralelismo', embora a transmiSSão de dados seja de fato scqucnciJI. O paralelismo gera as seguintes conscquencias para protocolos de transfer~ncia conOá\'cl de dados: A faixa de nu meros de scqui!ncia tem de ser ampliada. uma vez que cada pacote em tr.lnsito (sem contar as retransmissões) precisa ter um número de sequência exclusivo e pode haver vários pacotes não reconhecidos em trânsito.

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------Os lndos remetem e c destinatário dos prmocolos podem ter de reservar buiTers para mais de um pacmc. o mfnimo, o remetente terá de providenciar buiTers para pacotes que roram transmuidos, mas que amda não roram reconhecidos. O buiTcr de pacotes corrctarnentc rcccbtdos pode também ser necessário no destinatário. como discutiremos a seguir. A raixa de nu meros de scqui:ncia necessária c as nccessidadrs de buiTcr dcpcndcrM da maneira como um protocolo de transrer~ncia de d:tdos responde 11 pacotes perdidos. corrompidos e demasiad:tmente atrnsados. Duas abordagens ~iC:lS em relaÇão :'1 recuperação de erros com paralelismo podem ser identificadas: Go·Back· e repelição seletiva.

3.4.3 Go-Back-N Em um protocolo Go·Back · N (GBN), o remetente é amorizado a transmitir mllltiplos pacotes (se dispon fve is) sem esperar por um reconhecimen to, mas fica limitado a ter não mais do que algum número máxi mo permitido, N, de r>acotcs 11:'10 reconhecidos. L esta scç-Jo, descreveremos o protocolo GBN com dct:tlhcs. Mas antes de continuar
Se definirmos ba s e como o n\imero de scqucncia d o mais antigo pacote nl\o reconhecido c nex t s eqnum como o menor número de sequ~ncia n:\o utilizado (is to é, o número etc SCQ ll~ncla do próximo pncote a ser em•iado) . então qumro intervalos na faixa de n\imero$ de sequf ncia poden\o ser identifi<.-ados. Os numcros de sequên· cia no intcl'\-alo [ O. ba se I) correspondcm aos pacotes que jfl foram tmnsm itidos c rcconhectdos. O intervalo ( base. nexl.s e qn um · l 1 corrcspondc aos pacotes que fora m enviados, mas amda n;\o roram reconhecidos. Os mlmeros de sequênda no Intervalo [ nex t seqnum. ba se+H· 1] podem ser usados paro pac:otcs que podem ser e•wiados tmedtm:uncntc, caso cheguem dados vindos da camada s upe rior. Finalmente, n\imeros de scqu~ncia maiores ou igunis a ba se+l4 não podem ser usados até que um pacote não reconhecido que esteja pendente seja reconhecido (cspcclficameme. o pacote cujo m\mero de sequência é bas e). Como sugere a Figura 3. 19, a raixa de números de scqucncia permitidos para pacotes transmitidos mas ainda m1o reconhecidos pode ser vista como uma 'janela' de tamanho N sobre a faixa de números de scquência. À medida que o protocolo opera, essa janela se desloca para a frente sobre o espaço de numeros de scquência. Por essa razao, N é rrc:qucn tcmcntc denominado tamanho de janela c o protocolo GBN em si. protocolo de janela deslizan te (sliclmg· wimlo"' r~rotocol). 1: possi\•el que você esteja pensando que mzào terfamos. em primeiro lugnr, para limitar o m\ mero d e pnc:otes pendentes não reconhecidos a um valor N. Por que n:lo permitir um mimero ilimitado desses l>:lcotcs? Veremos nn Seçilo 3.5 que o comrole de Ouxo é uma das razOes para impor um limite ao remetente. Examinaremos o utra mzào para isso na Se\'àO 3. 7, quando eswdarmos o co ntrole de congcstiona-

mcmo do TCP. N:1 prática, o n úmero de seq uéncia de um pac:ote é carregado em u m c-ampo de comprimcm o fixo no cabe· Ç<'tl ho do pa~ ot c. Se 11 ror o núme ro de bits 110 c:tmpo de número de scquenci:t do paco te, a faixa de n(uncros de seq uência se rá ent:lo 10.2- - 11. Com uma faixa finita de nll mcros de scquência, todn a aritmética que envolver números de scquência dever:! ser feita usando ariunética de mód u lo 2•. (E m outras palnvrus, o espaço do n úmero de scqu~ncia pode ser imaginado como um anel de tnmanho 2~. em que o número de scq utncia 2~- 1

11111i~oooooõõóõõoooooooooo L-

Figura 3.19 Visão do remetenle poro os números de sequêncio no protocolo Go-Bock·N

legenda:

1.•

te
Autoriudo.

Omas ainda nao enviado



167

é Imediatamente seguid o pelo numero de sequcncía 0.) Lembre-se de que rd t3. O tem um número de sequcncia de I bit c um:~ faixa de numcros de scquência de (O, li. Vários problemas ao final deste capuulo tratam das conscqu~ncias de uma faixa finita de números de scqu~ncia. Veremos na Scçilo 3.5 que o TCP tem urn campo de número de sequl'ncia de 32 bits, onde os números de scqul'ncia do TCP comam bytcs na cadeia de bytcs. em \' CZ de pacotes. As Oguras 3.20 e 3.21 descrevem uma FSM estendida dos lados remetente e destinatário de um protocolo GBN baseado em ACK, mas sem NAK.

Referimo-nos a CSS.1 estendida agora está começando a p..'1recer um pouco com uma especificação de linguagem de prograrna(,"'.lo. IBochman , 1984) fornece um excelente levantamento sobre extensões :~dicion:1is às técnicas FSM, bem como sobre outms técni<:as pa ra especificação de: protocolos baseadas crn linguagens.

O remeten te GBN deve responder >I trés tipos de eventos: Chcwacula 1•hulcr ele d11w. Quando rdt_send () é chamado de cima, o remetente primeiramente verillc;t se a janela está cheia, isto ~ se hã N pacotes pendentes n:\o reconhecidos. Se a janela não estiver cheia, um pacote é criado e enviado e as variáveis são adequadamente atualizadas. Se estiver cheia, o remete me apenas devolve os dados à camada superior- uma indil·açào implfcit:t de que a janela está cheia. Presumivelmente, a camada superior então teria de tcn t:tr outra vez mais tarde. Em uma implcmenLa(,-:lo real, o reme teme muito provavelmente tema colocado esses d~•dos em um buffcr (mas não os teria enviado lmcdi:.uamcntc) ou Leria um mecanismo de sincronizaç.lo (por exemplo. um semáforo ou uma Oag) que permitiria que a camada superior chamasse rd t_send ( ) somente quando as janclns não estivessem cheias.

Ruebirnrnro dr urn ACK. l::m nosso protocolo

GB~ .

um reconhecamento de pacote com numero de sequl'nda 11 scna tomado como um reconhecimento cumulat ivo. mdlc-.mdo que todos os pacotes com mimero de sequ~ncia até e inclusive n tinham sido corretamente recebidos no destinatário. Voltaremos a esse assunto em breve, quando examinarmos o lado destinatário do GBN.

Um rsgowrnrnto dr ttmpo1 i~a(clo. O nome 'Go-Back-N' deriva do comportamento do remetente em rclaçM a pacotes perdidos ou dcmasiadameme atrasados. Como no protocolo pare e espere, um temporizador é usado para recuperar a perda de dados ou reconhecer pacotes. Se ocorrer o esgotamento da temporização, o remetente rccnvia todos os pacotes que tinham sido previamente enviados mas que aind:1 n:lo tinham sido reconhecidos. Nosso remetente da Figura 3.20 usa apenas um thtko temporizador. que pode ser imaginado como um temporizador para o mais antigo pacote já lrnnsmitido mas que ainda n:lo foi rcconhet ido. Se for recebido um ACK c ainda houver pacotes adidon:~is tmnsmitidos mas ainda n:lo reconhecidos, o temporizador será reiniciado. Se não houver nenhum Jl:lCOtc pendente não reconhecido, o temporizador ser:i desligado. As a~·ocs do destinat<\rio no GB também são si mples. Se um pacote com numero de sequ~ncia 11 for recebido corretamente c estiver na ordem (isto é , os últimos dados entregues à camada superior vierem ele um pacote com número de scqul'ncia 11- 1), o destinatário cnviar:l um ACK para o pacote 11 c entregará a por~-:1o dos dados do pacote à c11nada superior. Em todos os outros casos, o destinatário des<.11rta o pacote c rccnvia mn ACK para o pacote mais recente que foi recebido na ordem correta. Dado que os p;:tcotes São en tregues à <.111nada superior um por vez, se o pacote h tiver sido recebido c cntrcgul!, então todos os pacotes com numero de scqu~ncia menores do que li também ter.lo sido entregues. Assim, o uso de reco nhecimentos cumulativos é uma escolha n:ltuml p;ml o GBN. Em nosso protocolo GBI':, o destinatário descana os pacotes que chegam fora de ordem. Embora pareça bobagem e perda de tempo descartar um pacote corretamente rcccbtdo (mas fora de ordem), cxastcm JUStific-.tti\'as para ISSO. Lembre-se de que o destinatário deve entregar dados na ordem certa à camada supe rior. Suponha agora que o pacote n esteja sendo esperado, mas quem chega é o pacote 11 + 1. Como os dados devem ser entregues na ordem cena, o destinatário poderia conservar o pacote 11 + l no buffer (salv-á-lo) e entregar esse pacote à camada

bow4tto4ic~ Redes de co11putodore s e o

ln .-;.;l~ e ;.; rn;.;e:.;.t

_________________________

I f I n~xts~r\u•
udt_sendlsndp•t[nextseqnum)l lflb•s~nextseqnua)

st•rt_llll>l!r I>Ut

t l~~eout

rdl I) I

rdt_rcv! r~ v p k t) U notcorrupt< rcvpkl I b.l>e·~etdC krlu!

( rCvl)kl ) • I I f( base••ne xtsPqnu•l

stop_ti•er

e'se Si.~rt_tlrwr

Figuro 3.20 Descriçãodo FSMestendidodo remetente 6811

superior mais tarde. após ter recebido o pacote 11 . Contudo. se o pacote n fo r perd tdo, os t>acotes n e n + 1 ser;lo ambos fi nalme nte reLransmitidos como resultado da regra de retrans missão do GBN no remetente. Assim , o destinatário pode simplesmente d escartar o pacote n + 1. A vantagem dessa :~bordagem é a simplicidade da manlpulaç;lo de buffers no destinatário - o destinatário não precisa colocar no buffer nenhum pacote que esteja fora de o rd em. Desse modo. enquanto o remetente deve manter os hmnes supeno r c mfcrior de sua j anela c a posiçào de nex tseqnum dentro dcss.'\ janela. a única infonnaç;\ o que o destinatário precisa manter é o número de seq utncia d o próximo pacote esperado co1lrom1e a ordem. Esse '-alor f retido n:1 v-ariável expecledseqnum mostrada na FS:vl destitmtária da Figura 3.21. E\•ldcntemcnte, a desvan tage m de jog<~r fora um pacote recebido corrc Lamcme é que a rctra nsmiss:'lo subscqucm c desse pacote pode ser perdid a ou ncar tnmc<~da, c<~so em que ainda mais rctransmissOes seriam necessárias.

rdt_rcvc rc vpHI && notcorrupt ctcvpktl

U

h~ ss~QnU"'I

rcvpkt . ~xpecte
~x lraCl( I CVP~l . Odld) dellver_d~talaatol snapkt-t~~ake_p k tlcxpectc
ud t_sendc sndpkt) expecledseqnum~~

---------------· A

e~p~ctelhe(lrllrc-1 sndp~. t-&~I
Figura 3.21

.checksu

Descrição do FSM estendido do destinatário GBN



169

A Figura 3 .22 mostra a opcraç-.\o do protocolo GBN para o caso de um L:lmanho de janela de quatro pacotes. Por causa da limitaç;lo do t:-~manho dessa janela. o remetente envia os pacotes de O a 3. mas. em seguida, tem de esperar que um ou m:us desse:. pacotes sejam reconhecidos antes de prosseguir. E, à mcd1da que cada ACK succs. sivo (por c.-ccmplo, ACKO c ACK 1) é recebido, a janela se desloca para a frente c o remetente pode transmitir um novo pacote (pkt4 c pkt5. rcspcctiwmente). Do lado destinatário. o pacote 2 é perdido. Desse modo, verifica·sc que os pacotes 3, 4 e 5 estão fora de ordem e, portanto, são descartados. Antes de cnccrmrmos nossa dtscussão sobre o GB~. devemos ressaltar que uma unplcment.1ção desse protocolo em uma pilha de protocolo pro\':lvelmcntc seria estruturada de modo semelha me à da FS~ estendida da Figum 3.20. A implementação pro,•avclmcntc também seria estruturada sob a romta de vários procedimentos que implementam as açOes a serem executadas em resposta aos vários eventos que podem ocorrer. Nessa programaçAo baseada em eventos, os vá rios procedimentos são chamados (invocados) por outros procedimentos presentes na pilha de protocolo ou como resultado de uma interrupção. No rcmetcmc, esses eventos seriam: (I) uma chamada pela entidade da camada superior invocando rd t_send( ), (2) uma imcrrupç:1o pelo temporizador c (3) llln:l chamada pela camada inrcríor invoe-.mclo rd t._r cv ( ) quando cheg:t um pa<.:otc. Os cxcrddos de progr:Hn~•çào :~o final deste ~'apíwlo lhe danlo a chance de Implementar de verdade essas rotinas em um ambiemc de rede simulado. lll l\S realista. Salícmamos que o protocolo GBN incorpora quase todas as técnicas que encontraremos quando estudarmos, n;t Seção 3.5, os componentes de trat\skrtncia confiável de dados do TCP. Essas ttcnleas incluem a utilizaÇ<1o de números de scqu~ nda , reconhecimentos cumulativos, somas de verifkaç:lo c urna opcra~·ào ele esgotamento de tcmporlzaç:'lo/retmnsmiss:lo. Destinatário

Remetente

envia pktO

.:~..

envia pktl

•

: recebe pktO : envl a ACKO

.-----envia pkt2

.

: recebe pkLl ACKl

envia pkt3

~

r.. . . . . . x

.

descart.s recebe ACKO envia pkt 4

··ecebe ACIO envia pkt5

~ :recebe

""' pk t 2 temporlzaçao envia pkt2 envia pkt3 : envia pkt~ :

pkt4 . descarta

... recebe pkt5 . descar t a :envia ACKl ...

:envia

ACKl

~=

""'

envia pkt5 :

:recebe pkt2 . entrega

/

: envfa ACK2 : recebe pkl3 . entrega

.,.; envl a ACK3 Figura 3.22 GBN em operoçõo

bow4tto4ic~ Redes de compu tadores e o lnte ;.; rn;.;e;.;.t_________________________

3.4.4 Repetição seletivo (SR) O protocolo GBN permite que o remetente potencialmente *encha a rede" com pacotes na Figura 3. 17. C\•itando. assim, os probl~mas d~ utiliza~o:ão de canal obscn-ados ~rn protocolos do tipo pare ~ espere. llá, contudo. CilSOS em que o próprio GBN sofre com problemas de desempenho. Em especial. quando o tamanho da janeln c o produto entre o atraso c a largura de banda são grandes, pode haver muitos pacotes pendentes na rede. Assim, um unico erro de pacote pode ftuer com que o GBN rct.ransmila um grande número de pacotes- muitos deles dcsneccss:lriamente. A medida que a umenta a probabilidade de erros no canal, a r~de pode ncar lotada com essas retransmissões desnccess:irias. Imagine se, em uma conversa. toda vez que uma palavra fosse pronunciada de maneira truncada as outras m1l que a circundam (por exemplo, um tamanho de Janela de mil palavras) tivessem de ser repe tidas. A conversa sofreria atrasos devido a todas essas palavras reiteradas.

Como o próprio nome sugere , protocolos de repcti~'âo seletiva (sdeCII \'C IC/Jeat- SR) evitam retransmissões desnecessárias porque fazem o rcmctcmc retransmitir somente os JXICOtes suspeitos de terem sido recebidos com erro (isto~ . q ue foram perdidos ou corrompidos) no dcstinauirío. Essa rcmmsmissl\o individ ual, somente q uando necessária, exige quc o dcslimuário reconheça jr~di vitlua/,nnuc os pa<:otcs recebidos de modo correto. Uma janela de taman ho N se~l usada novamen te p:1ra limitar o ml mero ele pacotes pendem cs n;\o recon hecidos clenLro da rede. Co mudo, ao conm\rio do GBN, o remetente já terá recebido ACKs p:tra algu ns dos pacotes na janela. A Figura 3.23 mostra a visão que o protocolo de SR remetente tem d o espaço do numero de scqutncia. A Figum 3.24 det:1lha as várias ações executadas pelo protocolo SR remeten te. O protocolo SR destinatário reconhecerá um pacote corretamente recebido esteja ele ou não na ordem cena.

Pacotes rom de ordem n,·am no buffer até que todos os pacotes raltantcs ( isto ê, os que t~rn números de scquencia menores) sejam recebidos, quando então um conjunto de pacotes poderá ser entregue a camada superior na ordem correta. A Figura 3.25 apresenta as "árias ações rc<~liudas pelo protocolo SR dcstinaH\rio. A Figura 3.26 apresenta um exemplo de operação do protocolo SR quando ocorre perda de pacotes. Note que. nessa Ogum. o destinatário inicialmente annazena os pacotes 3, 4 c 5 c os entrega juntamente com o pacote 2 :\camada superior, quando o pacote 2 é finalmente recebido.

send_b4Se

nextseqnum l~enda:

ooooooOooooooo o aooooooo Tamanho da janela

nAutoriudo, mas J<1 Ore<:onhecldo Uainda nao enviaclo Enviado. m<» Ona o ilutorlzado ONao out orizatlo

N

a. Visão que o remetente tem dos números de sequênda

l~enda

Fora de Ofdem

buffer), mas O(no jâ re<:onhe<:ido

ooooóOôõóbooo

Aceitável (dentro da janela)

(ACIQ

Tamanho da janela N

mas ONAo autorizado onda nAo re<:ebido Oa~gU
b. Visão que o destlnat~rio tem dos números de sequénc:ia

Figura 3.23 Visões que os protocolos SRremetente e destinolúrio têm do espaço de número de sequêncio



1. Dados recebidos de cima. Quando são recebidos dados de cima, o protocolo SR remetente verifica o próximo número de sequência disponivel para o pacote. Se o número de sequência está dentro da janela do remetente, os dados são empacotados e enviados; do contrário, eles são armazenados ou devolvidos à camada superior para t ransmissão posterior, como acontece no GBN. 2. Esgotamento de temporização. Novamente são usados temporizadores para proteção contra perda de pacotes. Contudo, cada pacote agora deve ter seu próprio temporizador lógico, já que apenas um pacote será transmitido quando a temporização se esgotar. Um único hardware de temporizador pode ser usado para emular a operação de múltiplos temporizadores lógicos (Varghese, 1997).

3. ACK re<:ebido. Se for re<:ebido um ACK, o SR remetente marcará aquele pacote como recebido. contan· to que esteja na janela. Se o número de sequência do pacote for igual a send_base, a base da janela se deslocará para a frente até o pacote não re
Figura 3.24 Eventos eo~ões do protocolo SR remetente É Importante no tar que na etapa 2 da Figuro 3.25 o destinatário reconhece novame111e (em vez de ignorar) pacotes jd recebidos com certos IH\meros de scqu~ncia que cstâo tlbaixo da atual base da janela. ~ bom que voe~ se convença de que esse reconhecimento duplo é de fato necessário. Dados os es paços dos nürncros de scquencia do remetente c do destinatário na Fig1tra 3.23, por exemplo, se nâo houve r ACK pílra pacote com mi mero send_base pro pagando-se do destinatário ao rcrnctcntc, este acabará rctransmitindo o pacote send_base, embora estcp claro ( paro nós. c não para o remetente!) que o destinatáriOJá recebeu esse pacote. Caso o desunatário n:lo reconhecesse esse pacote. a janela do remetente jamais se deslocaria paro a frente! Esse exemplo ilustra um im portante aspecto dos pro tocolos SR (c também de muitos outros). O remetente c o destinatario nem sempre t~m uma vis.lo idt ntica do que foi recebido corretarneme e do que nâo foi. Paro protocolos SR. isso significa que as Janelas do remetente c do destinatário nem sempre coincidirão.

A falta de sincroniza~o entre as janelas do remetente c do destinatário tem importantes consequ~ncias quando nos defrontamos com a realidade de uma faixa finita de numeros de scqu~ncia . Considere o que poderia acontecer. por exemplo, com uma faixa finita de quatro números de sequ~ncia de pacotes (O, 1, 2, 3) e um tamanho de janela de tres. Supo nha que os pacotes de Oa 2 sejam tronsmitidos. recebidos c reconhecidos correta mente no destinatá rio. Nesse pQIIIO, a janela do dcstinat.1rio está sobre o quarto, o qunuo c o sexto pacotes. que tt m os números de scquencía 3, Oc 1, res pectiva mente. Ago ra. considere dois cenários. No primeiro. mostrado na Figura

1. Pacote com número de sequência no intervalo [rc.v_base, rcv_base+N- 1I foi corretamente recebido. Nesse caso. o pacote recebido cai dentro da janela do destinatário e um pacote ACK seletivo é devolvi-

do ao remetente. Se o pacote não tiver sido recebido anteriormente, irá para o buffer. Se esse pacote tiver um número de sequência igual à base da janela destinatária (rcv_base na Figura 3.22). entl!o ele. e quaisquer outros pacotes anteriormente armazenados no buffer e numerados conse<:utivamente (come~ando com rcv_base), serão entregues à camada superior. A janela destinatária é então deslocada para a frente de acordo com o número de pacotes entregues à camada superior. Como exemplo, considere a Figura 3.26. Quando um pacote com número de sequência rcv_base• 2 é recebido, ele e os pacotes 3. 4 e 5 podem ser entregues à camada superior. 2. Pacote com número de sequência em (rcv_base-N, rcv_base-1) é recebido. Nesse caso, um ACK deve ser gerado mesmo que esse pacote já tenha sido reconhecido anteriormente pelo destinatário. 3. Qualquer outro. Ignore o pacote

Figura 3.25 Eventos eações do protocoloSR destinotório


Remetente

.. . ...·~·.... ... ...

pktO enviado

o1

2 3 4

s

6 7 8 9

pktl enviado

o

ACKO en

1 2 3 4 5 6 7 8 9

pktl recebido . entregue . ACKl en O I 2 3 4 S 6 7 8 9

7 8 9

ACKO recebi do . pkt4 enviado

o

Destinatário

pkt3 rece bido . a rmu zenado . ACK3 • O I 2 3 4 S 6 7 8 9

1 2 3 4 5 6 7 8 9

ACKl recebido . pkt5 en viado o123456 789

pkt4 recebido . armazenado . ACK4 • o12 3 4 s6 78 9

Esgotamen LO de te~porizaç~o !TI HEOUT)pkt2 .

o1

pktS recebido : arma zenado . ACKS • 2 3 4 s 6 7 8 9

pkt2 recebido . pkt2 . pkt3 . pkt4. Pk entregues . ACK2 enviado

o

1 2 3 4 5 6 7 8 9

enviado

Figura 3.26 Oper~õo SR 3.27(a), os ACKs para os tr~s primeiros pac01es foram ~rdldos e o remetente rctr:msrnhc esses pacotes. Assím, o que o destinatário recebe em seguida é um pacote com o n(lmcro de scqu~nc i a O - uma cópia do primeiro pacote enviado. No seglmdo cenário, mostmdo na Figtua 3.27(b). os ACKs para os trt!s primeiros pacotes foram elllrcgttcs corretamente. Assim, o reme tente des loca sua janela pam a frente e cm•ia o quarto, o quinto c o sexto pacotes com os nümeros de scquencia 3, O c l, rcspcCLiva rnentc. O pacote com o número de scq uéncia 3 é perdido, mas o pacote com o m\mcro de se<:tU~ncia O chega - ttm pacote que contém dados no\'OS. Agom. na Figura 3.27, considere o ponto de vista do destinatário, que tem unm cortina imaginária cnlrc o remetente e ele, já que o destinatário não pode '\'e r' as ações executadas pelo remetente. Tudo o que o destinatário observa é a scqu ~ncia de mensagens que ele recebe elo c-.mal c envia para o l'ünal. No que conceme a ele, os dois ccn:ínos da Figura 3.27 são ultnticos. Não há nenhum modo de disunguir a retransm!SS:lo do primeiro pacote da transmissão onginal do qumto pacote. Fica claro que um tamanho de janela que sep igual ao tamanho do cspa· co de numeraç:'lo scqucncial menos l não ''ai funcionar. Mas qual deve ser o tamanho da janela? Um problema ao final deste c:lpllulo pede que voei! demonstre que o tamanho da janela pode ser menor o u igual11 metade do wmanho do espaço de numeraç:'lo scquencial para os protocolos SR. No Companion Wcbsite, você encontrará um applet que anima a operação do protocolo SR. Tente realizar os mesmos experimentos feitos com o applet GBN. Os resultados combinam com o qu e você espera?


(omoda de lronsporh

173

Janela do destinatário (após recep<;llo}

Janela do remetente (após recep<;llo)

2

3

o

2

3

o

2

timeou t

retrans~fte

3

o

1 2

. ...

o

3

o

2 • pktO

2 3

o

2

o1

2

2 3

ACKl

Ol

AC ~2

0 1 2

o

2

O

2

_ _.,:· recebe pacote : com número de sequênc ta

.,..

o

o 1 2 3 o1

o

Janela do dest1nat6rlo (após recepç5o>

Janel a do re~etente

3

O

• pkto:

a.

o

ACKO

ACKO o

2

o

2

ACKl

o

2

ACK2

o 12

2

2

2

recebe pacote número de sequência O

...

...

b.

Figura 3.27 Dilema do remetente SR com jonelos muito grondes: um novo pacote ou uroo retransmissão? Com isso, concluímos noss:1 discussão sobre protocolos de trnnsfercncia conll:ível de dados. Percorremos um longo caminho c apresentamos numerosos mecanismos que, juntos, provccrn tmnsrcrcnci:~ conll;htcl de dados. A Tabela 3. 1 resume esses mcc:mlsmos. t\gora que já vimos todos eles em opernç-lo c podemos enxergar ·o quadro ger:1l', aconselhamos que vocc leia novamente esta seÇ'.\O para perceber como esses mecanismos roram adicionados pouco a pouco, de modo a abordar modelos (realistas) de complexidade cresceme do canal que conecta o remetente ao destinatário ou para melhorar o desem(>('nho dos protocolos. Encerraremos nossa exphmacão considerando uma premiss.'l remanescente em nosso modelo de <.:anal subja· cente. Lembre-se de que admitimos que pacotes nào podem ser reordenados dentro do canal entre o remetente c o dcstinat:lrio. Esta é uma premissa em geral razoá\'el quando o remetente c o deslinaL:lrio est:'lo conectados por um único flo físico. ConLudo, quando o 'canal' que está conectando os dois é uma rede, pode ocorrer reordenação de pacotes. Uma manifestação da reordenação de pacoLes é que podem aparecer cópias an1igas de um pacote com

bow4tto4ic~ Redes de co 11 putod ores e o In;.;l~er;.;;n;.;;e,;.,l- - - - - - - - - - - - - - - - - - - - - - Me
Socoo de ve~ilkoçõo le.Uodor

HOOlelo de sequêncio ~Komecimento

Rec:onhecimento negativo Jonelo, poJalellsmo

Utiizasão, Comentarias llsodo poro dete
Tabela 3.1 Resumo de me
3.S Transporte orientado para conexão: TCP Agora que j<~ vimos os principias s ubjacentes à transferência t•onná,•el de dados, va mos voltar para o TCPo protocolo de trans porte confh\vcl da camada de trnnsponc, orientado p
3.5.1

Aconexão TCP

Dizemos que o TCP ~ orientado para cooc.üo porque. a ntes que um processo de aplicaç.lo possa começar a envrar dados a outro, os dois processos precisam primeiramente se ·apresentar' - rsto é, dc,•cm enviar alguns segmentos prehminares um ao outro para estabelecer os par.imctros da transfcr~ncra de dados em questão. Como parte do estabelecimento da conexão TCP, ambos os lados da conexão iniciarão muitas "variáveis de estado" (muitas das quais serão discutidas nesta seção e na Seção 3.7) associadas com a conexão TCP.


(amada de tronsporle

175

A ·conexão' TCP n:\o é um circuito TDM ou FDM fim a fim. como aco ntece em uma rede de comUla~"tlo de circuitos. Tampouco é um circuilo vinual (veja o Capftulo 1). pois o estado de concxJo reside imeirameme nos dois sistem:IS finais. Corno o protocolo TCP roda somente nos sistemas lin:us, c não nos elementos intcrmcdi:i· rios da rede (roteadores c comlll;tdorcs de camada de enlace), os elementos mtcrmedi:lrios n;lo manttm estado de conexão TCP. Na verdade, os roteadores intermahários são completamente alheios às conexões TCP; eles enxergam datagr-Jmas, c n:\o conexões. Uma conexão TCP prov~ um erviço full-duplex: se houver uma conexão TCP entre o processo A em um hospedeiro c o processo B em outro hospedeiro. enu\o os dados da camada de aplicaç;lo podemo Ouir de A para B ao mesmo tempo em que os dados da camada de aplicaç-Jo Ouem de B para A. A conexão TCP e sempre ponto a ponto, isto~. entre um unico remetente c um llllico dcstinatt\rio. O chamado 'muhicasl' (veja a Sc~·ào 4.7)a transrerl!ncia de dados de um remetente para \'ârios destinatários em uma umca operação de emdo - não é poss(vcl com o TCP. Com o TCP, dois hospedeiros é bom; três é demais! Va mos agora examinar como um11 conexão TCP é cstabclccicla. Suponha que um processo que roda em unl hospedeiro queira iniciar a conexão com outro processo em outro hospedeiro. Lembre-se de que o processo que está iniciando a concxào é denominado Jli'Ocesso cliente, enq uanto o outro processo é denominado 1nocesso servrclo1 . O processo de aplicação cliente primeiramente infonml à camada de transporte no clieme que ele quer estabelecer uma conex;1o ~om um processo no servidor. Lembre-se (Seção 2.7) de que um programa cliente em j;w•J faz isso emitindo o corn;mdo Socke t c l fe n tSoc ke t

ne w Socke t ( "hos tna me - . por t Numbe r ) :

em que h os tname é o nome do servidor e porwu mbe r idcntillca o processo no servidor. A camada de transporte no cliente então passa a estabelecer uma conexão TCP·servidor. Discutiremos com algum dct:~lhe o proccdunento de estabelecimento de conexão ao final desta seção. Por enquanto, basta saber que o cliente primeiramente envia um segmento TCP espcc1al: o servidor responde com um segundo segmcmo TCP espccml c. por fim , o cliente responde novamente com um terceiro segmento espccml. Os pnmc• ros dois segmentos não con t~m nenhuma -carga lltil". isto é, nenhum dado da (amada de aplicaç-Jo: o terceiro desses segmentos pode c.trregar uma carga útil. Como trl:s segmentos são enviados entre dois hospedeiros. esse procedimento de estabelecimento de conexão é frequentemente denominado a presc:ntaçào d e três vias (J-wc1y lwnclslwl:e). Uma vez estabelecida uma conCX
Buffer

TCP de envio

Figura 3.28 Buffers TCP de envio e de re
Segmento -

I Segmento

-

Buffer

TCP de recepçao

bow4tto4ic~ Redes de compu ta dores e o ln;.; te;.;.',;;. ne,;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Vinton Cerf, Robert Kohn eTCP/IP No inicio do dócodo de 1970, Ol redt» de comuloçÕO de poco1e$ começaram o proliferar. A ARPAnet precursora do Internet - ero openos mais umo dentre tontos redes, que tinham, codo umo, seu próprio protocolo. Dois pesquisadores, Vinton Cerf e Robert Kohn, reconheceram o importância de interconector essas redes e inventaram um protocolo inter-redes denominado TCP/IP, que quer dizer Tronsmission Control Protocol/lnternet Protocol (protocolo de controle de transmissão/ protocolo do lnternetl. Embora no começo Cerf e Kohn considerassem o protocolo como umo entidade único, mais tarde ele foi dividido em duas portes, TCP e IP, que operavam seporodomente. Cerfe Kahn publicaram um artigo sobre o TCP /IP em maio de 1974 em IEEE Tronsoctíons on Communicotion Technology [Cerf, 1974). O protocolo TCP/IP, que é o 'feijão com arroz' do Internet de hoje, foi elaborado antes dos PCs e dos estações de tra ba lho, antes do proliferoçõo dos Ethernets e de outras tecnologias de redes locais, antes do Web, do recepção de vídeo e do bole-popa virtual. Cerf e Kohn perceberam o necessidade de um prolocolo de rede que, de um lodo, fornecesse amplo suporte poro apl icações o indo o serem definido s e que, de outro, permitisse o inleroperoc;õo de hospedeiros orbitrórios e protocolos de camada de enlace. Em 2004, Cerf e Kohn receberam o prêmio ACM Turing Aword, considerado o Prêmio Nobel do Computação pelo "trobolho pioneiro sobre interligoc;õo em rede, incluindo o projeto e o implementoc;õo dos protocolos de comunicoçõo do Internet, TCP/IP e por inspirarem liderança no óreo de redes:

limitada pelo tamanho máximo d o ~gmento ( rnCLYÍmum segmelll síze- MSS). O MSS normalmente é estabelecido prímc•ramcmc determinando o tamanho do maior quadro de camada de enlace que pode ser enviado pelo hospcdc•ro remetente local (denominado un idade máxima de transm is ão - maximwn tr(IIISIIIISSíon unit MTU) c. em seguidll. estabelecendo um MSS que garanta que um segmento TCP (quando encapsulado em um datagrama IP) caberá em um único quadro de camada de enlace. Valores comuns da MTU são 1.460 bytcs, 53ó bytcs c 5 12 bytcl>. Também foram propostas abordagens para descobrir a MTU de Caminho (Pat h MTU)- o maior quadro de camad a de enlace que pode ser emoc:kct de conexão de um processo em olllro hospedeiro. Como mencionamos antcriormcme. nenhum buffcr nem vari:!veis s;'o alocados à conexão nos elementos da rede (roteadores, comutadores c repetidores) existentes en tre os hospedeiros.

3.5.2 Estruturo dosegmentoTCP Agora que examinamos brevemente a conexão TCP. vamos verificar a estrutum do segmento TCP, que consiste em campos de cabeçalho e um campo de dados. O campo de dados contém uma quantidade de dados de


(ama do de transpor te

aplic~w:lo.

Como citado antes, o MSS limita o tamanho má;dmo do campo de dados de um segmem o. Quando o TCP envia um arquivo gr.mde. tal como uma imagem de uma página Web, ele comumente rrngmenm o segmento <'m pedaços d<' taman ho MSS (<'XC<'tO o tillimo pedaço, que muitas vezes é menor do que o MSS). Aplicações intc· rntivas. contudo. muitas vezes trnnsmitcm quantidades de dí!dos que s.'\o menores do que o MSS. Por exemplo. com aplicações de login remo to como Telnet. o campo de dados do segmento TCP é. muitas vezes. de apenas 1 b)·te. Como o cabeçalho TCP tem tipicamente 20 bytes ( 12 bytes mais do q ue o cabe\-alho UDP). o comprimento dos segmentos en\•lados por Telnet pode ser d e apenas 21 bytes. A Figura 3.29 mostrn a estruwra do segmento TCP. Como acon tece com o UO P, o cabeçalho inclui números de porta de font e c d e destino , que são usados parn muhiplcxacão c demultiplexação de dados dc!parn aplica· ções de c:~m:~d:~s superiores e, assim como no UDP, inclui um campo de soma de verificação. Um cabeç;1lho de segmento TCP também contém os segu intes campos: O campo de nú mero de sequencia d e 32 biiS e o campo d e número de recon hecimento de 32 biiS sAo usados pelos TCPs remetente c destinatário na implement:~('llo de um serviço confh\vel de tr:.msferencia de dados, como discutido a seguir. O cMnpo ele j a nela de recepçã o de 16 bits é us;~do p<~rn controle de nuxo. Veremos em breve que esse campo é usado para indicar o número d<' bytes que um destinat~rio está disposto a aceitar. O cam po de comprimento d e cabeçalh o de 4 bits especifica o comprimento elo c:~beça lho TCP em palavras de 32 bits. O C:lbcÇ;Jiho TCP pode ter comprim<'nto v:~ri:h•el de\•ido ao campo de opções TCP. (O campo ele opções TCP normalmente está v;uio. de modo que o comprimento do cabeçalho TCP ti pico é 20 b)•tcs.) O campo de opções, opctonal c de comprimemo vanãvel, é usado quando um remetente c u m desti· n~uano negociam o MSS, ou como um rator de a umento de escala da janela pam uLiiLZação em redes de alta velocidade. Uma opç;\o de marca de tempo é também definida. Consulte o RFC 854 c o RFC 1323 pam detalhes adicionais. O campo de flag contem 6 bits. O bh AC K ê usado para indicar se o valor carregado no campo de reconhecnncnto é \'áltdo. isto é , se o segmento contém um reconhccnnemo parn u m segmento q ue foi recebido com sucesso. Os bits RST, SYN e flN são usados pal'ô\ est:~bclccer c encerrnr a conexão, como

32 bits

Porta da fonte 11

Porta do destino ll

Número de seqüência Nomero de re
Janela de re
Valor de verificação da Internet

Ponteiro para dados urgentes

Dados

Figura 3.29 Estruturo do segmento TCP

bow4tto4ic~ Redes de com putod ores e o Inle ;.;;.;.';;. ne;;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

diScutiremos ao final desta seção. Marcar o bit PSH indica que o destinatário deve passar os dados para a camada superior imediatamente. Por fim. o bit URG é usado para mostrar que há dados nesse segmento que a enudade da camada su perior do lado remetente marcou como ·urgen tes'. A localização do ultimo bytc desses dados urgentes é indicada pelo campo de ponteiro de urgênda de 16 bits. O TCP deve inrormar à entidade da camada superior do lado destinatário quando existem dados urgentes c passar a ela um ponteiro para o final desses dados. (Na prática, o PSII, o URG c o ponteiro de dados urgentes não são liS:ldos. Comudo, mencionamos esses campos para descrever todos.)

Números de sequêndo enúmeros de reconhecimento Dois dos mais Importantes campos do cabeçalho do segmento TCP s;'o o campo de numero de scqu~nda c o campo de numero de reconhecimento . Esses campos são parte rundamental do serviço de transrerencia confiável de dados do TCP. Mas. antes de disc utirmos como esses campos são util izados, vamos explicar exatament e o que o TCP coloca nesses campos.

O TCP ve os dados como u ma cadeia de bytes nào estruturada, mas ordenada. O uso que o TCP C:1z dos mhncros de seque nela reOete essa vis;\o, pois esses números s;\o aplicados sobre a cadeia de bytcs transmitidos, e m1o sobre a série de segmentos transmitidos. O número de sequência 11ara um segmento é o número do primeiro bytc do segmento. Vamos ver um exemplo. Suponha que um processo no hospedeiro A queira em·iar unm cadeia ele dados p;l r:t um processo no hospedeiro B por uma concxróximo bytr cjtU' dr estiver lli;UCirdmulo do l1ospcdriro B. É bom examinarmos alguns exemplos 1>ara en tendermos o que está acorncccndo aqui. Suponha que o hospedeiro A tenha recebido do hos pcdetro B todos os b)•tcs numerados de O a 535 c também que esteja prestes a enviar um segmento ao hospcdctro B. O hospedeiro A está esperando pelo by te 536 c por todos os bytes subse<]uCntcs da corrente de d>\dos do hospedeiro B. Assim, ele coloca o número 536 no campo de nümero de rcconhcctmento do segmento que envia para o hospedeiro B. Como o utro exemplo, suponha que o hospedeiro A tenha recebido um segmento do hospedeiro B com endo os bytes de O a 535 e ou tro segmento contendo os bytes de QOO a 1.000. Por alguma razão, o hospedeiro A :.inda não recebeu os bytes de 536 a 899. Nesse exemplo. ele ninda está esperando pelo b)•te 536 (c os s uperiores) p:un pode r recri(lr a cadeia de dados de 6. Assim, o segmento segui nt e que A envia a 6 conterá 536 no campo de

Arquivo Dados para o primeiro segmento

Dados para o

o figura 3.30 Dividindo os dados do mquivo em segmentos TCP

~undo

~mento


(amada de lronspo1le

179

número de reconhecimento. Corno o TCP someme reconhece bytcs at~ o primeiro b)·tc que csth•er fahando na cadeia. dizemos que o TCP pro'·~ ~conhecimentos cumulativos. Esse úhimo exemplo tamb~m revela uma qtK'Stão importàllte. mas sutil. O hospedeiro A recebeu o terceiro segmento (bytcs de 900 a 1.000) ames de receber o segundo (bytcs de 536 a 899). Portanto. o terceiro segmento chegou fora de ordem. E o que um hospedeiro faz quando recebe segmentos fora de ordem em uma eonrx;\o TCP? Esta é a ques t:lo. O interessante t que os RFCs do TCP não impõem nenhuma regra paro isso e deixam a decisão para quem esuver programando a implementaÇtlo TCP. H:\ basicamrnte duas opções: (1) o dcsunatário descarta imediatamente os segmentos foro de ordem (o que, como discmimos anteriormente, pode simplificar o projeto do destinatário) ou (2) o destinatário conserva os bytes fora de ordem c espero pelos bytcs faltantes para preencher as laeum\S. Claro que a segunda alternativa é mais eficu~nte em termos de l:ugura de banda de rede e é a alx>rdagcm adotada na prát ica. Na Figura 3.30, admitimos que o número de sequ~ncia inicial era O. Na verdade, mnbos os lados de Ltma conexão TCP escolhem t~lcatoriamcnte um número de scqucncia inici:tl. Isso é feito para minimizar a possibili· dt\cle ele um segmemo ele uma conexão já enccrmd:\ en tre dois hospedeiros c ainda 1>rcscm c na rede ser tomado por um scgmcm o v:llido em u ma conexão posterior entre esses dois mesmos hospedeiros (q ue também podem estar usando os mesmos números de porw da conexão amiga) [Sunshinc, I 9781 .

Telnet: um estudo de coso para números de sequêncio e números de reconhecimento O Tclnct, definido no RFC 854. é um prOLocolo popular de camada de aplícaçao utilizado para fazer login remoto. Ele roda sobre TCP c é projet.ado para trabalhar entre qualquer par de hospedeiros. Difercrucmente das aplicações de transferência de dados em grandes blocos, que foram díscutid:lS no Capitulo 2, o Tclnct é uma aplicaç;lo intcr.ttiva. Discutiremos. agora. um exemplo de Tclnct. pois ele ilustra muito bem mlmcros de sequência c de reconhecimento do TCP. Obsen-;unos que muitos usuários agora preferem usar o protocolo 'ssh' em vez do Tclnct. visto que dados enviados por uma conexão Telnet (incluindo senhas!) n:'lo são criptografados. o que torna CSSclo b)•tc 42. Como mostra a Figura 3.31, s:lo enviados cr~ segmentos. O primeiro é enviado do cliente ao servidor, contendo, em seu campo de dados. um byte com a representação ASC II para a letra 'C. O primeiro segmento também tem 42 em seu campo de numero de sequtncia. corno acabamos de descrever. E mais, como o cliente ainda não recebeu nenhum d;ldo do scn •idor. esse segmento terá o numero 79 em seu campo de número de reconhecimento. O segundo segmento é enviado do servidor ao cliente. Esse segmento tem dupla nn:~lidadc. A primeira nnalidade é fornecer um rcconhec rmcnto para os dados que o scn•idor recebeu. Ao colocar 43 no campo de reconhecrmcnto. o servidor está dizendo ao cliente que recebeu com sucesso tudo até o b) te 42 c agora está aguardando os bytes de 43 em diante. A segunda finalidade desse segmento é ecoar a letra 'C. Assi m, o segundo segmento tem a representação ASCII de 'C em seu campo de dados. Ele tem o número de sequência 79, que é o


Hospedeiro A

Hospedeiro B

Usuário digita 'C' Hospedeiro reconhece recebimento do 'C'. ecoa 'C' Hospedeiro reconhece recebimento do 'C' ecoado

Tempo

Tempo

Figuro 3.31 Números de sequêncio ede reconhecimenro poro uma oplicoçõo Telner simples sobre TCP numero de sequtncía inicial do nuxo de dados de servidor para chente dessa conexão TCP. pois este é o primei· rlssimo byte de dados que o servidor está envi ando. l'otc que o reconhecunento para dados do cliente para o servidor é levado em um segmemo que carrega dados do sen•idor parJ o cliente. Dizemos que este reconhecimento pegou uma carona no segmento de dados do senidor para o cliente. Tecnicamente, essa 'carona' recebe o nome de piggyback. O terceiro segmento é enviado do cliente ao servidor. Seu único propóSito é reconhecer os dados que recebeu do scn •idor. (Lembre-se de que o segundo segmemo cominha dados - a letra 'C' - do sentidor para o cliente.) Esse segmento tem um campo de dados vazio (isto é, o reconhecimento não esta pegando carona com nenhum dtldo do cliente para o servidor), tem o número 80 no campo do lllímcro de reconhecimento porque o cliente recebeu a cadeia de d~dos até o byte com número de scquenci:1 79 c :~gora est;\ aguardando os bytes de 80 em diante. ~ possível que ' 'ocl! esteja pensando que é estranho que esse segmento também tenha um número de scq u~neia, já q ue nt\o contem dados. Mas, corno o TCP rem um campo de número de scqLu:!ncia, o segmento precisa aprcsent;u ;\lgum mhncro para preenche-lo.

3.5.3 Eslimaliva do tempo de viagem de ida e volto e de esgotamento de temporização O TCP, assim como o nosso protocolo rdt da Seçl\o 3.4, utilíza um mecanismo de controle de temporização/ rctransmiss;lo para recuperar segmentos perdidos. Embora concciwalmcntc simples. s urgem muitas questões sutis qu:mdo Implementamos um mecanismo de controle de tcmporizaç:to/retransmissão em um protocolo real como o TCP. Talvez a pergunta mais óbvia seja a duração dos lntcn·alos de controle. Evidentemente, esse intcrvalo deve ser m:1ior do que o tempo de viagem de ida c volta da conexão (RTI), isto é, o tempo decorrido entre o e•w io de um segmento c seu reconhecimento. Se não fosse assim, senam enviadas retransmissões desncccssarias. Mas qu:1o maior deve ser o mtervalo c, antes de mais nada, como o RTI de,·e ser estimado? Deve-se associar um temporizador a cada segmento não reconhecido? São tantas perguntas! Nesta seçM. nossa discuss;lo se baseia no trabalho de Uacobson, 19881 sobre TCP e nas recomendações da IETF vigentes para o gerenciamento de temporizadores TCP IRFC 29881.


(amado de transpor te

181

Estimativo do tempo de viagem de ido e volto Vamos iniciar nosso estudo do gerenciamento do temporizador TCP considemndo como esse protocolo estima o tempo de viagem de ida c \'Oha entre remetente c dcsúnatário, o que apresentaremos a seguir. O RTT pam um segmento. denominado Samp 1eRTT no exemplo, é a quanlidade de tempo transcorrido entre o momento em que o segmento é enviado (isto é. passado ao IP) c o momento em que é rcccb1do um reconhecimento para o segmento. Em vez de medir um Samp I eRTT para cada segmento transmitido, a m:-tioria das implementações de TCP executa apenas uma medição de Sampl eRTT por vez. Isto é, em qualquer instante, o Samp I eRTT estará sendo estimado para apenas um dos segmentos transmitidos mas ainda n:'lo reconhecidos, o que resulta em um novo v.1lor de Samp I eRTT para aproximadamente t·ada RTT. E mt~ls, o TCP nun(11 computa um Samp 1eRTT para um segmento que foi rctransmilido; apenas mede-o pam segmentos que foram transmitidos uma vez. (Um dos problemas ao final do capítulo perguntará por quê.) Obvl:uucmc, os valores de Samp 1éRTT sofrer-lo variação de segmento pam segmento devido a congestionamento nos ro teadores c a v:uiaçOes de carga nos sistemas nnais. Por causa dessa va riaç:lo, qualquer dado valor de Samp I eRTT pocle ser atfpico. Port:mto, 1:>am estimar um RTT típico, é muuml tom(lr alguma espécie de média dos valores ele Samp 1eRTT. O TCP mantém uma mêdia, denomi nada Es t t matedRTT, dos valores de Sampl eRTT. Ao obter um 110\' 0 Samp l eRTT, o TCP :nualiz.a Estima tedRT T de aco rdo com a seguinte fórmula: EstlmatedRlf - C! - a) · EstimatedRTT +a · Samp1eRTT.

Essa fórmula está escrita sob a form<1 de um comando de linguagem de programaç
o novo \•ator de

EstimatedRTT é uma combinaçâo ponderada entre o ''alor anterior de EsttmatedRTT c o novo '"'lor para Sampl eRTT. O \'lllor recomendado de a é a • 0,125 (isto é, 118) IRFC 29881 . mso em que essa fórmula se toma: Es t 1ma tedRTT

0 .875 · EsttmatedRTT

+

0 . 125 · SampleRTT.

Note que Es t.l ma tedRTT é uma média pondemda dos \'lllorcs de Samp 1éRTT Como veremos em um cxerd cio ao final deste capuulo. essa mêd1a ponderada atribui um peso ma1or às amostras recentes do que às amostras antigas. Isso é natural. pois as amostras mais recentes rcOetcm melhor o estado atual de congestionamento da rede. Em estatís tica, esse tipo de média é denominada média móvd v:ponencial ponderada. A palavra 'exponencial' aparece na MMEP porque o peso atribuído a um dado Samp 1eRTT diminui exponencialmente à medida que as atualizações s:\o realizadas. Os exercíCIOS ped1rão que vocc denve o termo exponencial em Estima tedRTT. A Figura 3.32 mosLra os valores de Samp 1eRTT c Estima tedRTT para um valor de a - 1/8, para uma cone>:âo TCP entre gala.cs.umass.cdu (em Amhcrst, Massaclmsetts) c famasia.curecom.fr (no sul da Franç-a). Fica d:tro que as variações em SampleRTT s.\ o atcn u~tdas no cálculo ele EstimatedRTT. Além de ter uma cstim:uiva do RTT, também é valioso ter uma medida de sua va rial>ilidade. O IRFC 29881 define a variação do RTT. OevRTT. como uma estimativa do desv1o típico entre Samp 1eRTl c Es t 1ma tedRTT : OevRTT - (I -

3) ·

DevRTT +

B·l

SampleRTT- EstfmatedRTT

I

Note que OevRTT é uma MMEP da difcrellça entre Sampl eRTT c Es lima tedRTT. Se os valores de Samp 1eRTT apresentarem pou'-:.1 \".lriaç:lo, ent;lo OevRTT ser-
Estabelecimento e gerenciamento do temporização de retransmissão Dados valores de EstIma tedRTT c OevRTT. que V
bow4tto4ic~ Redes de tom pu tod ores e o Inlerne~t-------------------------

300

~c ~

250

OI

~

g I: 0::

200

ISO

8

15

22

29

36

43

50

57

6.4

71

78

85

92

99

106

Tempo (segundos)

Figura 3.32

Amos~os de

Rlls e RTis eslimodos

v:~riaç;\o nos \':li ores de Samp 1eRTT c pequena quando hou"cr pouca variaç;lo. Assim. o '"-'lorde OevRTT deve cntrnr em jogo. Todas essas constdcrnçOCS São levadas em con t:~ no método do TCP parn dctcm1inar a tcmpori·

Z
T!meoutlnlerval • EstimatedRTT + 4 · OevRTT

O TCP fornece transferênc ia confióvel de dados usando reconhecimentos posi tivos e temporizadores, de modo muito parecido com o que estudamos no Seção 3. 4. O protocolo reconhece dodos que foram recebidos cor· reto menle e retronsmil e segmentos quando entende que eles ou seus reconhecimentos correspondentes foram perdidos ou corrompidos. Certos versões do TCP tombêm t~m um moconismo NAK implícito - com o mecanismo de retransmissão rópido do TCP. O recebimento de três ACKs duplicados poro um dado segmento serve como um N AK implícito poro o segmento seguinte, ocionondo o retransmissão daquele segmento an tes que o tempo se esgote. O TCP uso números de sequêncio poro permitir que o destina tário identifique segmentos perdidos ou duplicados. Exatomente como no coso de nosso protocolo de transferência confiável de dados rd t3.0. o TCP em si não pode determinar com certeza se um segmento, ou seu ACK, estó perdido, corrompido ou excessivamente otrosodo. N o remetente, o resposta do TCP ser6 o mesmo; retransmitir o segmento em questão. O TCP também uti lizo paralelismo, permitindo que o remetente tenho, o qualquer tempo, múhiplos segmentos transmitidos mos oindo não reconhecidos. Vimos anteriormente que o paralelismo pode melhOfor muito o vazão de umo sessão quando o rozão entre o tempo de transmissão do segmento e o otroso de viagem de ido e volto é pequeno. O número específico de segmentos não reconhecidos que um remetente pode ter é determinado pelos meconi s. mos de controle de fluxo e controle de congestionamento do TCP. O controle de fluxo do TCP ê discutido no Finol dosto seção; o controle de congestionomento do TCP é discutido no Seção 3.7. POf enquanto, devemos openos ficar cientes de q ue o TCP remetente uso paralelismo.


(amada de lronspo1le

3.5.4 Transferência confiável de dados Lembre-se de que o serviço da camada de rede da Internet (serviço IP) n:lo é confiavel. O IP n;'lo garante a enrrcga de damgmmas na ordem corrtta nem a integridade de seus dados nos damgmmas. Com o serviço IP, os datagmmas podem transbordar dos buffers dos roteadores c jamais alcançar seu destino; podem mmbém chegar fora de ordem. Além diS.w, os bitS dos datagr.unas podem ser corrompidos (passar de O para l e 'ice-versa). Como os segmentos da camada de tronsporte ~o rnrrcgados pela rede por d:uagram.1S IPs. também eles podem sofrer esses mesmos problemas.

O TCP crta um serviço de cr.tnsferêneia confiável de dados sobre o scrvtço de melhor esforço do IP. Esse serviço de transferência garante que a cadeia de dados que um processo lê a partir de seu buffer de recebimento TCP não est.1 corrompida, n:lo tem lacunas, não tem duplicações c está em sequt'ncia, isto é, a cadeia de b)'tCS é exatamente a mes ma cadeia de bytcs enviada pc.lo sistema final que está do outro lado da conexão. O modo como o TCP provê transferência conflá,•d de dados envolve muitos dos princípios estudados na Seção 3.'1. Quando desenvolvemos anteriormente t~cnicas de tr:msfcrência conl'iávcl de dados, era conceilu;llmente mais fácil ndmitlr que existia um temporiz.ador indívidu:-.1 :-.ssociado com eilda sesmento tr;lllSmitido mas :~inda n1\o reconhecido. Embora, em teor-in, isso seja ótimo. o gcrcnci:unento de tcmporizndorcs pode exigir considcrn· vel sobrcc:1rga. Assim . os procedimentos recomendados no (RFC 29881 p:-.m gc rend;-uncn to de temporizadores TC? tnilizam apenas um rlnico temporizador de retransmiss.<1o, mesmo que haja v;\rl os segmentos transmitidos ainda não reconhecidos. O protocolo TCP apresentado nesta seção segue essa recomendação. Discutiremos como o TCP prov~ transfer~ncia eonl1t\vcl de dados em duas ct:1pas incrementais. Em primeiro lugar, apresentamos uma descrição muito simplificada de um remetente TCP q ue utihza somente controle de tcmpori:tõldorcs par" se recuperar da perda de segmentos: em seguida. aprcscntnrcmos ttma descrição mats com· plexas que utiliza reconhecimentos duplicados além de temporiz.adores de rctransm is~o. Na diM:uss.io que se segue. aclmunnos que os dados csl:lo sendo enviados em uma dtrcç.lo somente. do hospedeiro A ao hospedeiro B, c que o hospedeiro A está enviando um arq uivo grande. A Ftgum 3.33

apresem:~

uma dcscriç-Jo muito simplificada de um remetente TCP.

Vemos que há tr~ eventos importantes relacionados com a transmissão c a retransmissão de dados no TCP remetente: dados recebidos da apli<."aç-lo acima: esgotamen to do tcmporiz.ador c recebnnento de ACK. Quando ocorre o pnmciro evento importante, o TCP recebe. dados da camada de aplicação, cncapsula-os em um segmento c passa-o ao IP. Note que cnda segmento inclui um número de sequência que é o número dn corrente de bytcs do primeiro b)'tC de dados no scgmemo, como descrito na Scç-Jo 3.5.2. 1 otc também que, se o temporiz.ador não cstlvcr fun eion:mdo naquele instante para algum outro segmemo, o TCP aciona o temporizador quando o segmento c passndo para o IP. (Fica mais fácil se você imaginar que o temporizador está associado com o mais antigo segmento n~o reconhecido.) O intervalo de expiração para esse temporizador C o Ti meou tl n t e r va 1, calculado a partir de Es li ma LedRTT c OevRTT, como descrho na Seç
O segundo evento tmportante é o esgot:unento clo temporizador. O TCP responde a esse evento rctranSittitinclo o segmento que l~tusou o esgotamento da tcmporizaç-Jo c então rcinicia o tcmporiz:-.dor. O terceiro C\lcnto importante que deve ser manipulado pelo TCP rcmetcmc é a chegada de urn segmento de reconhecimento (i\CK) do dcstinmrtrio (mais especificamente, um segmento contendo um valor de l-ampo de ACK v::llido). Qu:-.ndo da ocorrencia desse evento , o TCP compar:1 o valor do ACK, y, com sua variável SendBa se. A variável de estado SendBa se do TCP é o número de scqltência do m:-.is ant igo byte nilo reconhecido. (t\ssim, SendSase·l é o número de sequencia do último bytc que se sabe ter s ido recebido pelo dcslinat;\rio corretamente c na ordem ccrt~l .) Como comentamos anteriormente, o TCP llS.I reconhecimentos cumulativos, de modo que y reconhece o recebimento de todos os bylcs antes do b)'tC numero y. Se y >SendBa se. então o ACK está reconhecendo um ou mais bytcs n;'lo reconhecidos antcriorn1cnte. Desse modo, o remetente alllaliz.a sua variável SendBase e t:-.mbém reinicia o temporizador se houve r quaisque r segmentos ainda não reconhecidos.

Alguns (enórios interessantes Acabamos de descrever uma vcrsao muito simplil1cada do modo como o TCP prov~ transfer~ncia confiavel de dados, mas mesmo essa descrição tão simplificada tem muitas sutilezas. Para ter uma boa percepção de como

bow4tto4ic~ Redes de computadores e o lnte-.;rn;.;e;,;.t_________________________

r

wpot~ha que o

remt'tente nAo seja compelido pelo fluxo de TCP ou controle ele congestion
q~ o tamanho dos d.ldos víndos ele cima ~;a~~ do que

NelC1SeqNum=lnltia1SeqNumber SendB.l~IMiaiSeqNumber

loop

(forever) I switch (eventl event data received from lhe applicalion above create TCP segment wlth seqoonce number NextSeqNum 11 (tomt'r currently not runnlng)

start tlmer pass segment 10 IP NextSeqNum•NextScqNum+length (data) break; evcnt:

tlmt'r timeout

retransmit not·yet·acknowledged segmem with smallest sequence number stan timer

event

ACK received. with ACK fleld vatve of y

oi (y > ~Ba~l I

Sendll.lse•y I( (there

are currently any not-yet-aclcnowtedged segmenLS)

sran ttmer

Figura 3.33 Remetente TCP simplificado

esse protocolo ftmciona, vamos agora examinar alguns cenários simples. J\ Figura 3.34 il ustra o primeiro cenário em que um hospedeiro A envi;~ um segmento ao hospedeiro B. Suponhil que esse segmento tenha nl1mero de seq ucneia 92 c conu:nh~t 8 bytes de dados. Após cm•íá-lo, o hospedeiro A espera por um segmento de B com n úmero de reconhecimento 100. Embom o segmento de A scj;t recebido em B. o reconhecimento de B p-ara A se perde. Nesse caso, ocorre o evento de expiração do temporizador e o hospedeiro A retransmite o mesmo segmento. E claro que, quando recebe a reuansmissiio, o hospedeiro B observa, pelo número de sequ~ncia, que o segmento contém dados que ja foram recebidos. Assim, o TCP no hospedeiro 8 desc:Jrt.a os byu~s do segmento retransmitído. Em um segundo cenário, mostrado na Figura 335, o hospedeiro A envia dois segmentos seguidos. O primeiro segmento tem numero de sequCncia 92 e 8 bytes de dados. O segundo segmento tem numero de scquência 100 c 20 b)•te:s de dados. Suponha que ambos cheguem intactos em B c que B envie dois reconhecimentos separados 1>ara cad;~ um desses segmentos. O primeiro desses reconhecimentos tem numero de reconhecunento 100; o segundo, número de reconhecimento 120. Suponha agora que nenhum dos reconhecimentos chegue ao hospedeiro A antes do esgotamento do temporizador. Quando ocorre o evento de expiração do temporizador,


(omoda de lronsporh

185

Hospedeiro

Hospedeiro A

Te1Jporizaç3o

x ~j (perda)

Tempo

Tempo

Figura 3.34 Retronslllssõo devido oum reconhecimento perdido

o hospedeiro A rcerwra o primerro segmento com número de sequêncra 92 c rernicia o tcmponzador. Contanto que o ACK do segundo segmento chegue antes que o temporizador expire novamente. o segundo scgmemo não será rctransmitido. Hos~deiroA

seq-92

temporizaçao

seq•92

t e~porizaç~o

Tempo

Figura 3.35 Segmento I00 nõo retronsmitido

Hospedeiro 8

Tempo


Em um tercei ro c uh imo cenário, suponha que o hospedeiro A cm•ic dois S(gmentos, exatamente como no S(gundo exemplo. O reconhecimento do primeiro segmento é perdido na rede. mas, um pouco antes do evento de expiraç.,o, o hospedc1ro A recebe um rcconhccirncnto com ntnnero 120. O hospedeiro A, portanto, sabe que B recebeu wdo até o byte ll9: portanto, ele nào rcenvia nenhum dos dois segmentos. Esse cen:lrio está iluslr.ldo na Figura 3.36.

Duplicação do tempo de expiração Discuuremos agora algumas modificações empregadas por grande parte das nnplememaçOes do TCP. A primeira refere-S( :\ duraç;lo do tempo d(' expiração após a ('xpiraç.1o de um temporizador. Nessa modillcação, sempre que ocorre o C\'CntO de expiração do temporizador, o TCP retransmite o segmento ainda não reconhecido que tenha o menor numero de sequtncia. como descrevemos anteriormente. Mas. a cada rctransmlss:lO, o TCP njusta o próximo tempo de cxpiraçâo para o dobro do valor anterior em ' 'ez de derivá-lo dos últ imos EstimatedRTT c DevRTT (<·omo descrito na Seção 3.5.3). Por exemplo, suponha que o T1meoutlnterval associado com o mais an tigo segmemo ainda não reconhecido seja 0,75 segundo quando o temporizador expirar pela primeira vez. O TCP então retmnsmile esse segmento c ajusta o novo tempo de expiração para 1,5 segundo. Se o te-mporizador expirar nov:uncnte 1,5 S(gundo nHlis tarde, o TCP ret l'llnsmitir:l novamen te esse segmento, agora ajustnndo o tempo de expir<~Ç1,_0 pam 3,0 segundos. Assim, o tempo aumenta cxponcncinlmcntc após \.~lda retransmlss;\o. Todavia, sempre que o tcmporízador é ín iciado após qm•lqucr um dos outros dois eventos (isto é, dados recebidos da aplicação acima e ACl< recebido), o Tlmeout.l nterval será deri"ado dos valores mais recentes de Estima ted RTT c DevRTT. Essa modificac;âo prov~ uma forma limilada de com role de congestionamento. (Maneiras mais abrangemes de con trole de congestionamento no TCP serfto estudadas na Seção 3.7). A causa mais pro,•:ivel da expiração do temporizador é o congestionamento na red e, isto é, um número muito grande de p:~cotes chegando a uma (ou mais) fila de roteadores no caminho entre a fonte e o destino. o que provoca descarte de pacotes e/ou longos atrasos de fila. Se ;\S fontes continu:~rcm a reLransmiLir pacotes persistentemente durante um congesLionamento, ele pode piorar. Para que isso não aconteça, o TCP age mais cducadamente: cada remetente retransmile após inten·alos cada \'CZ mais longos. Veremos que uma ideia scmclhaute a essa é utilizada pcl:1 Ethernct, quando estudarmos CSMNCD no Capitulo 5. Hospedeiro A

Hospedeiro 8

Seq•92 tempor1zaçao

Tempo

Figura 3.36 Um reconhecimento cumulativo evito retronsmissõo do primeiro segmento

Tempo


(omodo de transporte

Retransmissão rápido Um dos problemas de retransmissões acionadas por cxpiraçào de temporizador é que o período de expiraçào pode ser relativamente longo. Quando um segmento é perdido, esse longo pcrlodo força o remetente a atrasar o reetwio do pJCOte perdtdo, conscquentemente aumentando o atraso fim a rl rn. Felizmente. o remetente pode com frequfncia detectar perda de pacote bem antes de ocorrer o evento de expira~~lo, observando os denominados ACKs duplicados. Um ACK duplicado é um ACK que reconhece no,·amente um segmento para o qual o remetente Já recebeu um reconhecimento anterior. Para entender a resposta do remetente a um ACK duplkado, devemos examinar por que o destin:u:\rio e•wia um ACK duplicado em primeiro lugar. 1\ Tabela 3.2 resume a polftica de gemçào de ACKs do TCP destinatário [RFC 1122, RFC 25811. Quando um TCP destinatário recebe um segmento com um numero de sequtncia que é maior do que o numero de sequ~ncia subsequente, esperado e na ordem. ele detecta uma lacuna na corrente de dados - isto 1.\ a fa lta de um segmento. Essa lacuna poderia ser o resultado de segmentos perdidos ou reordenados dentro da rede. Uma vez <1ue o TCP nao usa reconhecimentos negativos, o destinatário nilo pode cnvi:tr um reconhecimento negativo explicito de volta ao remetente. Em vez disso, ele simplesmente reconhece novamerHe (isto é, gem um ACK duplicado) o Clltimo b}•te de dados que recebeu na ordem. (Note que a Tabela 3.2 admite o caso em que o destinatário n~o descarta segmentos fora de ordem.) Como um remcteme quase sempre envia um grande numero de segmentos. um utrás do outro, se um segmento for perdido, provavelmente existirão muitos ACKs duplicados. também um após o outro. Se o TCP remetente receber trts ACKs duplicados para os mesmos dados, ele tomará ISSO como indicação de que o segmento que se seguiu ao segmento reconhecido três vezes foi perdido. (Nos excrcicios de fixação consideraremos por que o remetente espera tr~ ACKs duplicados e não apenas um.) No l'3SO de recelxr tr~ ACKs du plicados. o TCP remcleme reahz:t uma retransmissão rápida (RFC 25811. relransmitindo o segmento que falta antes da exptraç-.lo do temponzador do segmento. isso ê mostrado na Figura 3.37. em que o segundo segmento é perdido, e ent.to retransnu udo ;mtes da cxpiraç;lo do temporizador. Para o TCP com retransmiss:lo r:\pida, o seguinte trecho de codifi cação substitui o evento ACK recebido na Figura 3.33:

evenl : ACK received. with ACK f i e ld value of y l f SendBase> 1 SendBase-y lf ( there are cu rrently any not yet acknowl edged segments> start timer else I

/ ~ a duplicate ACK f or alrea dy ACKed segment ~ / l ncrement number o f dupl i ca te ACKs rece i ved for y l f (number of dupli cate ACKS rece i ved fo r y~3) I I * TCP fas t r etransml t */ resend segmen t with sequence number y

break ; Observamos anteriormente que muit:tS questões sutis vêm à tona quando um mecanismo de controle de temporização/rctransmtss.lo é implementado em um protocolo real como o TCP. Os procedimentos acima, cuja evoluç-Jo é resultado de ma•s de 15 anos de experiência com lemponzadores TCP, devem convenct-lo de que, indubitavelmente, é isso que acontece!

bow4tto4ic~ Redes de cora putod ore s e o Inle;.rn;;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Evento Chegodo de segmento no ordem com IÚnefo de sequêró1 esperado. Todos os dodos até oIÚnefO dt sequênóo esperado~ reconheOOos. Cbegodo de segmento no ordem com rúnero de ~IQ esperodo. lM1 ouflo segmenlo no «dem esperondo por tronsnissõo de ACK.

Chegado de 001 segmento fora do ordem com rún~o de sequênciJ rmis oito do que oesperado. locuno detectooo. Chegado de 001 segmento que preefXhe, po~ciol ou c001pletomen1e, o loc~o oos dodos rece!ilos.

Ação do TCP Destinatário M.K retordodo. [spe!o de oté500 misseg1n!os pelo chegodo de um outro segmento no ordem. Se osegmento seguinte no ordem nõo chegor nesse ilterwlo, envio t.m MJ. Envio inedioto de um único ACK ciJIIdltivo. reconhe
Envio inedioto de um ACl duptKodo, iool(ando minero de sequêOOo do byte seguilte espe~odo (que é oextremidode rrois baixo do looro). Envio imediato de um ACK. contento que osegmento comece oo extreailode mois baixo do loo.oo.

Tabela 3.2 Recomendoçõo poro geração de ACKs TCP (RFC 1122, RFC 2581 )

Go-Back-Nou repetição seletiva? Va mos encerrar nosso estudo do mecanismo ele recuperac,"'ão de erros do TCJ> considerando a seguinLe pcrguma: o TCP é um protocolo GBN ou SR? Lembre-se de que, no TCP, os reconhecimentos si\o cumul:.uivos e segmemos corretamente recebidos, mas rora da ordem. mio são reconhecidos (ACK) indi\•idualmente pelo des· tin:uário. Conscqucntemcme, como mostra a Figura 3.33 (veja t:unbém a Figum3. 19), o TCP remetente precisa t;'lo somente lcmbmr o menor mímero de scqu~n cia de um bytc transmitido mas n:lo reconhecido (SendBa se) c o nl.'& mero de scqu~ncia do byte seguinte a ser enviado (lfextSeqNum). Nesse sentido, o TCP se parece muho com um protocolo ao estilo do GB~. Porém, há algu mas dircrcnças surpree ndentes entre o TCP e o GBN. Muitas implcmcmações do TCP armazenar-ao segmentos recebidos correta mente, mas rora da ordem (Stevens, 1994 ).

Hospedeiro A

Tenporiuçao

Tempo

Tempo

Figura 3.37 Retransmissão rópido: retransmitirosegmento que faltoantes do expiração do temporizador do segmento



Considere tambc!m o que acontece qu:llldo o remetente envia uma sequi!ncla de segmcmos 1, 2, ...• N c todos os segmentos chegam ao destinatário na ordem e sem erro. Além disso. suponha que o reconhecimento para o pacote n < N se pcr~-a . mas que os N - 1 rcconhecimemos restantes cheguem ao remetente antes do esgotamento de suas respectivas tempori:.1çõcs. Nesse exemplo, o GBN retransmiliria nao somente o pacote 11, mas tarnbc!rn todos os pacotes subsequcntcs 11 + 1, n + 2 •...• N. O TCP. por outro lado, retransmitiria no máximo um segmento, a saber, o scgmemo n. E mais. o TCP nem ao menos retransmiliria o segmento 11 se o reconhecimento para o segmemo n + 1 chegasse ames do final da temporização para o segmento 11 . Uma modilkac;tlo proposta p:tra o TCP, denominadn n:conhec:imento seletivo IRFC 20 18) , pennitc que um destinatário TCP reconhcç:~ sel ct i\o:~mcnte segmentos Cora de ordem. em ''ez de apenas reconhecer cumulad\':1· mente o último segmento recebido corretamente c na ordem. Quando combinado com retransmissão seletiva- isto é, saltar a retransmissão de segmentos que jã Coram reconhecidos seletivamente pelo destinatário-, o TCP se parece muito com nosso protocolo SR genérico. Assim, o mecanismo de reCllpem(·ão de erros do TCP provavel· mente é mais bem caracterizado como um híbrido dos prowcolos GBN e SR.

3.5.5 Controle de fluxo Lembre-se de que os hospedeiros de cada lado de uma conexilo TCP reservam um buffer de rrcepç;lo para a conexão. Quando a conexão TCP recebe b)'tcs que estão corretos e em sequ~ ncia, ele coloca os dados no buffer de recepç:\o. O processo de aplicaç:\o associado lemos dados a partir desse buffer. mas n;\o necessari:\mcnte no momento em que s.\o recebidos. Na verdade, a aplicaÇão rcceptom pode est:lr ocupada com alguma outr'
s

RcvBuffer

A j:lllcla de recepç-ão, denominada RcvWi ndOI•I, é ajustada para a quanúdade de espaço disponível no buffer:

rwnd - RcvB uffer - [ La stBy t eRcvd - LastByteReadJ

bow4tto4ic~ Redes de computadores e o

lnteroe~1------------------------

Corno o espaço disponavelmuda com o tempo. Rwnd é d!m1mlca. A variável Rwnd est1l ilusU':lda na Figura 3.38. Como a conex;'o usa a variável Rwnd para prover o serviço de controle de Ouxo? O hospc
~

rwnd

Hâ um pequeno problema técnico com esse esquema. Para percebe-lo. suponha que o buiTcr de rccc~ilo do hospedeiro B (iq uc l:\o cheio que Rwnd • O. Após anunciar ao hospedeiro A que Rwnd • O, imagine que B não tenha nada para enviar ao hospedeiro A. Agom con.siclerc o que acontece. Enquamo o processo ele ap l ia1ç~o em 8 csv:1zia o buiTer, o TCP n:lo envia novos scgmemos com novos valores R~md P''m o hospedeiro A. Na \•erclade, o TCP envlar.1 um segmento ao hos(>Cdciro A somente se tiver c.l;,clos ou um rcçonhcdmcnto p:u'a enviar. Por conscgulnlc, o hospedeiro A nutH.'il será infomtado de que foi ;tbcrto ;tlgum CSf111~"0 no buiTcr de rcccj)\'àO elo hospedeiro 8: ele fll-urá bloqueado e rr.lo poderá trans mitir mais dados! P:tra resolver esse problema, a espccirlcaçào do TCP requer que o hospedeiro A cominue a l'nviar segmentos com um byte ele dados quando a janela de recepção de B for zero. Esses segmentos scr.lo reconhecidos pelo reccplor. Finalmente o buiTer começam a cn,miar, c os reconhecimentos comen\o um valor difen:te de zero em n••ml.

O Companion Wcbsite elo li\'l'o (http : //www . aw . com/kurose_br) fornece um applet interativo em Java que illrstra a OI>Cnr<,ilo da Janela de rece~~\o do TCP. Agora que descrevemos o serviço de controle de Ouxo do TCP. mencionaremos bre,·emcnte que o UDP não prov~ controle de Ouxo. Para entender a questão. corrsidcre o envio de uma série de scgmemos UDP dc um processo no hospedeiro A para um processo no hospedeiro B. Para uma implementação UDP típica, o UDP anexará os segmentos a um buffer de tamanho finito que 'precede' o socket correspondente (isto é, o socket para o processo). O processo I~ um segmento inteiro do buffer por vez. Se o processo nilo ler os segmentos com rapidez suficiente. o buffer tr.rnsbordará e os segmentos serão descartados.

3.5.6 Gerenciamento do conexão TCP Nesta s ubseçuo, examinamos mais de peno como uma conexão TCP é estabelecida c encerrada. Embora esse tópico talvez n;lo pareça particularmente interessante, é impon::tme, porque o estabelecimento da eoncx:io TCP tl'm um peso signilk aLivo nos atrasos percebidos (por exemplo, ao navegar [)ela Web). Além disso. rnuilos dos at:1qucs mais comuns a redes - entre eles o incrivelmente p01>ular ataque de rnunclaçi\0 SYN -exploram RcvBuffer I

rwnd I

Processo de

Dados vindos do IP Es~o

disponível

Dados TCP

Figura 3.38 Ajanela de recepção (Rwnd) eobuffer de recepção (RcvBuffer)

no buHer

aplicaç~o


(omodo de transporte

191

vulnerabilidades no gerenciamento da cone.x;\o TCP. Em primeiro lugar, vamos ''t r como essa conext\o é estabelecida. Suponha que um processo que roda em um hospedeiro (cliente) qucir-.1 miciar uma conexão com outro processo em outro hospedeiro (servidor). O processo de aplicação cliente prunei~uneme in[onna ao TCP cliente que quer estabelecer uma conex;lo com urn processo no servidor. O TCP no cliente então estabelece uma conexão TCP com o TCP no servidor da ~guintc maneira: Etapa 1. O 1;-~do dieme do TCP prirneirameme envia um ~gmcmo TCP espcci:ll :•o lado servidor do TCP. Esse segmento espec1:ll não contém nenhum dado de camada de aplicação, mas um dos bits de Oag no seu C:lbeç:llho (veja :l Figura 3.29), o bit SYN, é ajust:ldo paro I. Por essa rozJo, esse segmento é dcnomin;~do um ~gmento SYN. Além disso. o cliente escolhe alcatoriameme urn número de scqui!n· cia Inicial (cl 1ent_l s n) c coloca esse nümero no campo de nümero de scq u~ncla do segmento TCP SYN inici;-~1. Esse ~gmento é encapsulado em um datagrama IP c cnv1ado ao servidor. A aleatoriedade ;~dequada da cS<:olha de c1 i ent_i sn de modo a evitar ccnos :11aqucs à segumnça tem dcspcn:ldo consiclernvel imeresse ICERT 2001-091. Etapa 2. Assim que o d:ltagr.:uml 1P contendo o segmento TCP SYN chega ao hospedeiro servidor (admitindo-se que ele realmente chegue!), o servidor extrai o segmemo TCP SYN do dtuagrama, aloca burrcrs c variáveis TCP à conexão c envia Ltm segmento de aceilaÇ".lO de conexi\o :10 TCP cliente. (Veremos, no Caplwlo 8, que a alocução desses bufrcrs c variavcis, antes dn conclusão d:1 terceira ct:1pa da apresentação de trts vias. torna o TCP vulnerável a um :uaque de recusa de serviço conhecido como inundac,:~\o SYN.) Esse segmento de aceitação de conexão t:uubém não contém nenhum dado de camada de aplicaçdo. Contudo, contém três informações importantes no c-.1beçalho do segmento: o bit SYN está com '':llor 1; o campo de reconhecimento do c:lbeç;~lho do segmemo TCP está njuslndo para c 11 en t_1sn+ I; c, por fim. o scn•idor CS<:olhe seu próprio número de sequtncin inicial (se rve r _1 sn) e coloca esse ,•alor no campo de número de sequéncia do cabeçalho do segmento TCP. Esse segmento de ;~ccnaç;\o de conexão está dizendo, com efeito, ~ Recebi seu p:lcotc SYN pam começar uma conexão com seu número de ~qutncia inicial c 11 en t_ i s n. Concordo em estabelecer essa conexão. Meu mime· rode scquenci:l inicial é server_i sn~. O scgmemo de concessão da concxlo às vezes é denominado cgmcnto SYNACK.

Hospedeiro cliente

--

H~pedeiro

servidor

Requlsi~o

de conexllo

.:~ Conexlio acelra

ACK -- ~~

Tempo

Figura 3.39 Apresentotõo de três vios do TCP: troco de segmentos

Tempo

bow4tto4ic~ Redes de cora putod ores e o Inle;.r;;. ne;;,;t_________________________

Eta pa 3 . Ao receber o se-gmemo SYNACK. o cliemc também reserva buffers c \'nri:lveis para a conexão. O hospedeiro cl•cmc então en,•ia ao servidor mais um segmento. E~e último ~gmen to reconhece o segmento de eonflrma~"ào da conc.x:\o do servidor (o cliente o faz colo<:ando o valor s erver_isn+l no campo de reconhecunento do cabeçalho do segmento TCP). O bit SY é 3Jl1Stado para O. jâ que a conex;\o está estabelecida. A terceira etapa da ap~ntaç:lo de três vias pode conduzir os dados cliente/ servidor na carga util do segmento. Completadas as tres etapas, os hospedeiros cliente c servidor podem enviar segmentos contendo dados um ao outro. Em cada um desses futuros segmentos , o bit SYN estará ajustado pam O. Note que, para estabelecer a conexllo, tres pacotes s.lo envi:tdos entre dois hospedeiros, como ilustm a Figura 3.39. Po r essa razão, esse procedimento de CStabclecimcnto de conexão é frequentemente denominado apresen tação de t rfs vias. Vários aspectos da aprescnuwao de tr~ ''ias do TCP são tratados nos exerdcios ao flnal deste caph ulo (Por que são necessários os nlÍmcros de sequ~ncia iniciais? Por que é preciso uma aprcsentaçilo de tr~s "ias, c n•\o a1>cnas de duas vias?) J: interessante not:tr que um alpinista c seu amarmdor (q ue flta mais abaixo c cuja tarefa~ pass.."\r a corda de segurança ao nlpinist~l) usa um protocolo de comunka~'lio de aprcsemac;ilo de três vlns ld~ntico ao do TCP para garantir que ambos os lados estejam prontos antes de o alpinista iniclar a l'Scal:tda. Tudo o que é bom dura pouco, e o mesmo é \I:\ lido para uma (.'Oncx:io TCP. Qual<1uer um dos dois processos que p:trticipam de uma conexão TCP pode encerrar a conexão. Quando a concx:'lo tennina, os 'recursos' (isLO é , os buiTers c as \•triávcís) nos hospedeiros são liberados. Como exemplo, suponha que o dicn te decida encerrar a concxilo, como mostra a Figura 3.40. O processo de aplic:wilo cliente emite um comando para fechar. lsso faz com que o TCP cliente envie um segmento TCP especial ao processo seNidor, n~o bit de Oag no cabeçalho do segmento. denominado bit FIN (veja a Figura 3.39). tem \13lor ajustado em I. Quando o servidor recebe esse segmento, ele cn,·ia de ,·o lta ao clieme um segmemo de reconhecimento. O servidor enü\o en\lia seu prõprio segmento de encerramento. que tem o bit fiN ajustado em I. Por flm. o cliente reconhece o segmento de encermmento do servidor. Nesse pomo, todos os recursos dos dois hospedeiros estilo libcmdos. Servidor

Oiente

-

Fecha

....

:

-

- --

.

...:.....

FIN p.(.~

f IN

ACK

--

.

~=

-

- .....

Fecha

:

...

Espera temporilada

.

Fecha Tempo

Figuro 3.40 Encerramento de umo conexão TCP

Tempo


(amado de

lronsporle

193

Durame a vida de uma conexão TCP, o protocolo TCP que roda em cada hospedeiro faz transições pclos vários estados do TCP. A Figura 3.41 ilustra uma sequêneia típica de estados do TCP visitndos pelo TCP cliente. O TCP chente começa no estado CLOSED. A aplicação no lado cliente inicia uma nova conexão TCP (criando um objeto sockc:t como nos exemplos emj:wa do Ca.prtulo 2). Isso fa.t com que o TCP no cliente envie um segmemo SYN ao TCP no serv1dor. Após ter enviado o segmento SYN, o TCP chente emra no estado $YN_SE:-.JT e, enquanto Isso, o TCP cliente espera por um segmento do TCP servidor que inclui um reconhecimento para o segmento anterior do cliente, c tem o bit SYN ajustado para o valor 1. Ass1m que recebe esse segmento, o TCP cliente emra no estado ESTABLISHED. qu:~ndo pode c:n,·i:~r e receber segmentos TCP que cont~m carga útil de dados (isto ~. gerados pela aplicaç;lo). Suponha que :1 aplicação cliente decida que quer fechar a conexão. (Note que o servidor tamb~m tem a alternativa de rccM-Ia.) Isso f:u com que o TCP cliente c:n,~c um segmento TCP com o bit FIN ajustado em 1 c c1me no estado FIN_WA IT_ I. No estado FIN_WAIT_l , o TCP cliente espera por um segmento TCP do servidor com um reconhecimento. Qu:'mdo recebe esse segmento. o TCP cliente entra no estado FIN_WAIT_2. No estado FIN_ WAIT_2, ele espera por outro segmento do servidor com o bit FI ajustado para I . Após receber esse segmemo, o TCP cliente reconhece o segmento do servidor e enlm no estado TIME_WAIT. O est:tdo TIME_WAIT permite que o TCP clic:mc reenvie o •·cconhccimc:mo fina l, caso o t\CK seja perdido. O tempo passado no estado TIME_Wt\IT depende ela implementaçilo, mas os valores típicos são 30 segundos, 1 minuto c 2 minutos. Após a espera, a conexão se encerra formr~hncntc: c todos os recursos do lado cliente (inclusive os nt\mcros de porta) s:lo liberados. A Figura 3.42 ilustra a série de estados norm;tlmc:ntc visitados pelo TCP do lado servidor, admitindo-se que

f o cliente quem inicia o encernuncnto ela conexão. As lmnslçôes silO autocxplícativas. Nesses dois diagramas de transiç-Jo de estados, mostramos apenas como umt~ conex;lo TCP é normalmente estabelecida c fechada. 1 ;lo de&-

crevemos o que acontece em certos cenários patológicos, por exemplo, quando ambos os lados de uma conexão querem fc:eh:1r ao mesmo tempo. Se csLi,·cr interessado em :~prender mais sobre esse assun to c sobre outros mais a\'ançados rderc:ntes ao TCP, consulte o abrangente livro de (Ste,•ens, 199... 1. 'ossa d1sc:ussão aci ma concluiu que o cliente e o S{'rvidor cst:lo prep..1.rados para se comuniC':lr. isto é, que o servtdo r está Oll\'mdo na porta pela qual o cliente en,•ia seu segmento SY '.

Aplicaç.\o cliente inicia uma conexao TCP

,.,. "'' ""'' (

CLOSEO

1oOoSVN

TIHE WAIT

SYH _SENT

!

Recebe SYN & ACK enviaACK

ESTABLISHEO

J · """

Aplicaç.\(1 client e inicia o fe
Figura 3.41

Umo sequêncio típico de estodos do TCP visitodos por um TCP diente

bow4tto4ic~ Redes de compu tadores e o lnle.;.'"e ;;.;;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Ootoque Syn Flood Vimos em nosso discu,sõo wbre o apresentação de três vias do TCP que um ~rvidor aloco e inicializo os variáveis do conexão e os buffers em resposta oo SYN recebido. O ~rvidor, entôo, envio um SYNACK em resposta e aguardo um segmento ACK do cliente, o terceiro e último posso no apresentação antes de uma conexão ~r completamente estabelecido. Se o cliente nõo enviar um ACK poro completar o terceiro posso do opresenloçõo de três vias, com o tempo (geralmente após um minuto ou mais) o servidor finalizará o conexão semioberto e recuperará os recursos olocodos. Euo protocolo d9 gDrenciomento do conexão TCP obro cominho poro um aloque DoS clássico, ou seja, o aloque SYN Oood. Neste aloque, o vilão envio um grande número de segmentos SYN TCP, sem concluir o terce iro etopo de opresentoçõo. O aloque pode ser ampliado enviando os SYNs de diversos fontes, criando um aloque DDoS (recuso de serviço distribuído) SYN Rood. Com esse acúmulo de segmentos SYN, os recursos de conexão do servidor podem rapidamente se esgotar já que sôo alocados (mos nunca usados) poro conexões semiobertos. Esgolondc>Se os recursos do servidor, o serviço é negado oo verdadeiro cliente. Esses otoques SYN flood (CERT SYN, 1996) estovom entre os primei ros o toques DoS documentados pelo CERT (CERT, 2009]. O SYN Rood é um aloque potencialmente destruidor. Felizmente, há uma proteção eficaz, denominada SYN Cookies [Skoudis, 2006; Cisco SYN, 2009; Bernstein, 2009], ogora implemenlodo no maioria dos sistemoJ operacionais. O SYN Cookie age do seguinte maneiro: •

Quando o servidor recebe um segmento SYN. nõo se sobe se ele vem de um usuário verdadeiro ou se

é porto desse aloque. Entôo, o servidor nõo crio uma conexão TCP somioborto poro osso SYN. Em voz disso, o servidor crio um número de sequêncio inicial TCP, uma função hosh de endereços de fonle e endereços de destino IP e números de porto do segmento SYN, assim como de um número secreto somente conhecido pelo usuário. (0 usuário utilizo o mesmo número secreto poro um grande número de conexões.) Esse número de sequêncio inicial criado cuidadosamente é o assim chamado •cookie·. O servidor, entôo, envio um pacote SYNACK com esse número de sequêncio especial. ~ importante mencionar que o servidor nõo se lembro do cookie ou de qualquer outro informoçõo correspondente oo SYN . •

Se o cliente for verdadeiro, entôo um segmento ACK retornará. O servidor, oo receber esse ACK, preciso é feito se o servidor nõo guardo nenhuma memória wbre os segmentos SYN? Como você deve ter imaginado, esse processo é realizado com o cookie . Poro um ACK legítimo, especificomente, o valor no campo de reconhecimento é íguol oo nú mero de seqllêncio no SYNACK mais um (vejo Figuro 3 .39). O servidor, então, executoró o mesmo lunçõo ulllizondo os mesmos campos no segmento ACK e número secreto. Se o resu ltado do função ma is um for o mesmo que o número de reconhecimento, o servidor conclui que o ACK corresponde o um segmento SYN an terior e, portanto, é vólido. O servidor, en tão, crio uma cone.xõo totalmente aberto com um sockel. veri~cor se ele corrosponde o algum SYN enviado onleriormento. Como isto

•

Por outro lodo, se o diente nõo retorno um segmento ACK, entôo o SYN original nõo causou nenhum dono oo servidor, uma vez que este não alocou nenhum recurso poro ele!

Os SYN cookies eliminam, efetivamente, o omeoço de um aloque SYN flood . Uma variação deue a taque é o clienle malicioso retornar um segmento ACK válido poro cedo segmento SYNACK que o servidor gero. Isto fará com que o servidor estabeleço cone.xões TCP totalmente abertos, mesmo se seu sistema operacional utilizar SYN cookies. Se centenas de clientes estiverem sendo usados (ataque DDoS), codo um de uma fonte de endereço IP diferente, então é difícil o servidor reconhecer os fontes verdadeiros e os maliciosol. Assim, pode ~r mois difícil de ~proteger desse •otoque de apresentação completado• do que o clássico ataque SYN flood.


ni

Recebe AC~dy n3o enllia

(amado de lron sporle

servidor

Aplica~!o

CLOSEO

195

~·~~""

LAST_ACK

LISTEN

CLOSE_WAIT

!

Recebe SYN, envia SYN & ACK

Recebe Ft . \_ envia ACK

SYN_RC VO

) ecebe ACI<•

ESTABLI SHED

..,___/~~o envia nada

Figura 3.42 Umo sequêncio ~pico de estodos do TCPv$1odos po1 umTCPdo lodo doseMdor

Vamos consaderar o que acontece quando um hospedeiro recebe u m segmento TCP Cl~os n úmeros de pona ou endereço IP não são compaliveis com nenhu ma das portas existentes no hospedeiro. Por exemplo, suponha que um hospedeiro receba u m pacote TCP SYN com por~ de destino 80. mas n;\o está aceít:~ndo conexões nessa porta (tsto 4!, não está rod;mdo um servidor Wcb na porta 80). Então, ele enviará à fon te um segmento especial de rcinicializaç-Jo. Esse segmemo TCP tem o bit de Oag RST ajustado para I (veja Sc~to 3.5.2). Assim, quando um hospedetro envia um segmento de rein icialização ele esl:\ dizendo à fonte: · Eu n<\o tenho um socket para esse segmento. Favor n
digamos q ue a porta 6789, o nmap enviará ao compmador-a l\•o um segmento TCP SYN com a port:t de destino. Os três possíveis resul tados são:

O computador-fonte I CCtbc urn St.!,'lllenro TCI) SYNACK tlc wn comrmtador-crll'o. Co mo isso signillca que uma a plica~·ào está sendo executada com a po rta TCP 6 789 no computador-a lvo, o nmap retoma "aberto".

O computador-fonte recebe um segmen to TCP RST de um compul:.ldor·:tlvo. Isto sign ifica c1uc o segmen to SYN atingiu o computador-alvo. mas este não está exccUL~mdo uma aplicação co m a porta TCP 6789. Mas o atacan te, pelo menos, sabe que os segmen tos destinados ao computador n:t porta 6789 nlo estão bloqueados pelo firc,vall no percurso en tre o computador-fome c o :th•o. (Firewalls são abordados no Capitul o 8). 1\ fonte tulo

recebe nadu. Isto, provavelmente, slgnific:t que o segmento SY foi bloqueado pelo fi rcwall

c nunca mingi u o cornpmador-alvo. O nnmp ~urna ferramenta potente, que pode -ex:tminar o local~ não somen te para abrir portas TCP. mas t:t mbém para abrir portas UDP. para fircwalls c suas configu raçOcs. c a té mesmo para as versões de aplit.:a ções e sistemas operncion:tis. A maior pane disto é feito através da manipul;~~'âo dos segmentos de gerenciamento da conexão TCP (Skoudis. 20061 . Caso você esteja sentado próxtmo a u ma máqutna Lanux, talvez voei! queara fazer uma expen~ncta com o nmap apenas digitando o nome da ferramema na hnha de comando. É posstvel fazer downloacl do nmap para outros sistemas operacionais do site hupJ/ínsecure.orglnmap.

bow4tto4ic~ Redes de co11putodores e o ln;.;l..;.e;.;rn;.;e;.;.t_________________________

Com isso, conclui mos nossa introdução ao conuolc de erro e comrolc de Ouxo em TCP. Voltaremos ao TCP na Scçlo 3. 7 c ent;\o examinaremos mais detalhada mente o controle de congestionamento. Antes. contudo, vamos analisar a questão do comrolc de congestionamento em um contexto mais amplo.

3.6 Princípios de controle de congestionamento Nas seções amcriores, examinamos os princípios gerais c também os mecanismos específicos do TCP usados para prover um serviço de tr.msrcr~ncia confiável de dados em rclaç.lo à perda de pacotes. Mencionamos anteriormente que, na prática. essa perda resulta. caracteristicamente. de uma saturação de burrers de roteadores á medida que a rede fica congestionada. Assim. a reuansmiss;\O de pacotes trata de um sintoma de congestionamento de rede (;t perda de um segmento específico de ca1m1da de transporte), mas não mua d:1 c:msa do congestiona me mo da rede: demas1adtlS rontes tentando em•iar dados a uma taxa muito alta. Para tr-Jtar da causa do congestionamento de rede, Silo 11ece~rios mecanismos para regular os remetentes quando esse congestionamento ocorre. Ncs1a scç:1o, consideramos o problema do comrolc de congestionamento em um c:omcx1o geral, buscando en tender por que o congestionamento é algo ruim, como o congestionamemo de rede se m:mircsta no desern· pcnho recebido por aplicnçocs da c.:amada superior e várias mcdid:lS que podem ser adotadas para evitar o con· gcstionamento de rcclc ou reagir a ele. Esse estudo mais gemi do controle de congestionamento t apropriado, j<\ que, como acomccc com a transfer~ncia conl'iável de dados, o congestionamento I! um elos "dez mais~ da lista de problemas fundament.1lmcnte importantes no trabalho em rede. Concluímos esta seç;\o com urna discussão sobre o controle de congestionamento no serviço de taxa de bits disponh•cl (11w1ilf1bk bil-l(llf- ABR) em redes com modo d e transfe~ncia asslncrono (ATM). A scç.lo seguinte contém um estudo detalhado do algoritmo de controle de congestionamento do TCP.

3.6.1

As causas e os custos do congestionamento

Vamos começar nosso estudo geral do controle de congestionamento examinando tr~s \'enários de comple· xidadc crescente nos quais ocorre o congcstionamcmo. Em cada CISO, examinaremos, primeiramente, por que ele ocorre c, depo1s. seu custo (no que se refere aos recursos não utihzados integralmente e ao baixo desempenho recebido pelos sistemas l'inais). Não focalizare mos (ainda) como reagir ao congestionamento, ou evHá·lo; preferimos estudar uma q uestão mais simples. que é emender o que acontece quando hospedeiros aumentam sua taxa de transmissdo c a rede fica congcstion:\da.

Cenário 1: dois remetentes, um roteador com buffers infinitos Comcç;1mos cons i dcr:~~~do o que talvez seja o cenário ele congestionamento mais simples possível: dois hospedeiros (A c B), cada um com 11ma conexão que compartilha um (lllico trecho ele rede entre a fonte e o dest ino, corno mostra a Figuro 3.43. Vamos :~dmhlr que a aplic..-:tç~o no hospedeiro A esteja enviando d~tdos para :1conexão ( por exemplo, passan· do dados para o protocolo de camada de transporte por um sockct) a uma taxa média de >.,,. bytes/segundo. Esses dados são originais no sentido de que cada unidade de dados é enviada para dentro do sockct apenas uma vez. O protocolo de camada de transporte subJacente é simples. Os dados s:1o cncapsuh1dos c em•iados: não há recupc· raç;\o de erros (por exemplo, retransmissão). controle de Ouxo, nem controle de congestionamento. Desprezando a sobrecarga adicional causada pela adição de informações de cabeçalhos de camada de transporte c de camadas mais baixas, a l:lxa à qual o hospcclctro A oferece tráfego ao rotcndor nesse prnneiro cenário é À,. bytcs/segundo. O hospedc1ro B funciona de mancírn semelhante. e admitimos, por simplicidade, que ele também esteja enviando dados a uma taxa de À., bytcs/srgundo. Os pacotes dos hosprdriros A e B pass.1m por um rotrador c por um enlace de S.'\1da compartilhado de capacidade R. O rotcador tem buffers que lhe pcrmllem armazenar os pacotes que chegam quando a taxa de chegada de pacotes excede a capacidade do enlace de sarda. No primeiro cenário, admitimos que o roteador tenha capacidade de armazenamento infinita.


>-1n: dados originais Hospedeiro A

,--,.--...,Hospedeiro 8

(omo do de transpor te

197

>'Oul ..-~...,Hospedeiro O

Hospedeiro C

Roteador com capaddade de armazenamento infinita

Figuro 3.43 Cenório de congestionamento 1: duas conexões compartilhando um único roteodOf com número infmitodebuffe1s 1\ figura 3.44 apresenta o desempenho da c.;onex;lo do hospedeiro A nesse primeiro c.;cnár io. O gráfico da esquerda dessa figura apresenta a vazão por conexão (nümcro de bytcs por segundo no destinatário) como uma função da taxa de envio da conexão. Para uma taxa de transrnissao entre O c R/2, a ' 'azão no destinatário é igual :\ velocidade de envio elo remetente - tudo o que o remetente cnví:t é recebido no dcstinat:lrio com urn

:nraso Onito. Quando a velocidade de envio estiver acima de R/2, contudo. a vaz:\o ser.i somente R/2. Esse limite superior da vazão é consequ~ncia do compartilhamento da capactdade do enlace entre duas conexões. O enlace simplesmente n:lo consegue entregar os pacotes a u m destinatário com uma taxa em regime que exceda R/2 . N:lo importa quão altas SeJam as taxas de envio ajustadas nos hospedeiros A e B, eles jamais alcançarão uma vazão maior do que R/2. Alcançar uma ''azão de R/2 por conexão pode até parecer uma cotsa boa. pots o enlace está sendo mtegral· mente utilizado para entregar pacotes no destinatário. No entamo, o gráfico do lado direito da Figura 3.44 mostra as consequênctas de operar próximo à capacidade máxima do enlace. A medida que a taxa de envio se aproxima de R/2 ( partindo da esquerda) , o atraso médio rica cada ' 'U maior. Quando a taxa de envio ultrapassa R/2, o numero mtdio de pacotes na Ola no roteador é ilimitado c o atraso mtdio entre a fome c o destino se torna infinito (admitindo que as conexões operem a essas velocidades de transmiSSliO durante um perlodo de te mpo infinito c que a capacidade de
R/2

.,g...

<

R/2

a.

>-in

b.

Figuro 3.44 Cenário de congestionamento 1: vozõo eotroso emfunçõo do taxo de envio do hospedeiro

R/2

bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'-------------------------

idealizculo,jd clescobrimos um custo der mie congcstionatlc4- hd grmu/es utrasos ele fila «/IICintlo li taxa tlr clrcgllda de pacotes sr aproxinur cltr capacidade do rnlau.

nesse ccndr ío (extremcuntntt)

Cenário 2: dois remetentes, um roteador com buffers finitos Vamos agora modiOcar ligeiromeme o cenário 1 dos dois modos seguintes (veja a Figuro 3.45). Em primeiro lugar, admitamos que a capacidade de armazenamento do roteador seja Onita. Em uma situação real, essa suposiÇ'lO teria como consequfnc:la o descarte de pacotes que chegam a um buiTcr que já esrá cheio. Em segundo lugar, admi tamos que cacl:r conexão seja conOável. Se um pacote comendo um segmento de camada de rronsporte ror descartado no roteador, o remerente por nm o retransmitir:!. Como os pacotes podem ser retransmitidos, agora temos de ser mais cuidadosos com o uso da expressão • taxa de envio-. Especificamente, vamos novamente designar a t<~xa com que a aplicaÇ..,., seria igual a l\;., c a vaz;\o da conexão seria igual a >.. ,,. Esse caso é moslrado pela curva superior da Figura 3.46(a). Do ponto de ' 'ista d:t vaz:lo, o desempenho é ideal - tudo o que é em
,.--'·'- : dados originais : dados originais mais dados reuansmitidos

Hospedeiro 8

Hospedeiro A

Hospedeiro C

r--:~

Buffers de enlace

de saída finitos compan:ilhados

Figura 3.45 Cenário 2: dois hospedeiros (comrelronsmissões) e um roteador com buffers finitos

,.--,.--,

Hospedeiro D



199

'5

....o

Rf2

a.

;,[n

b.

Rf2

RIZ

c.

Figura 3.4 6 Desempenho no cenário 2 com buffers finitos unw reclr congcslioumlct - o rcmcwuc dCI't recditctr rcmmsmlsslles pttrtt compenstrr os fUlCotes clcsc:t~rwclos (IJcrclfclos) dtviclo ciO esgoltlml'nlo elo buffer.

Fim•lmcmc, va mos considerar o caso em que a temporizaçi\o do remetente se esgote prematuramente c ele retransmila um pacote que ficou atrasado na nla, mas que ainda não está perdido. Aqui, tanto o pacote de dados original qu:mto :\ rctransmiss:1o podem alcançar o destinatário. É claro que o destinatário precisa ape nas de uma cópin desse pacote e descartará a retrnnsrnissão. esse caso. o trabalho realizado pelo rotc:~dor ao rcp3SSar a cópi:1 rctransmitida do pacote origin;ll ~ despcrdi~.tdo, pois o destinatário já ter;\ recebido a cópia original desse pacote. Em vez disso, seria melhor o roteador usar a capac;idadc de trans missão do enlace para etwiar um pacote direrente. Ets lltflll 111t1rs 11111 criSio ela n~cle congrstionada - relransnussões desnecessárias feilas fH!lo remei ente rm face de: gramlcs Cllrasos fXXItm Ja~er com que um roteador use sua largura de: banda tle cnlacr fXUa rcpas$0r copias tlcsrrc· ccssclrias tk um ptrcotr. A Figura 3.4.6(c) mostra a ,-azão versus a carga orcrccida ad mitindo-se que cada pacote seja etwi:~do (em m~la) du.'\S vezes pelo roteador. Vis to que cada pacote t ell\•iado duas vezes. a vazão terá um ''alor assintótico de R/4 à medida que a carga oferecida se aproximar de R/2.

Cenário 3: quatro remetentes, roteadores com buffers finitos e trajetos com múltiplos roteadores Em nosso cenário final de congestionamento, quatro hospcdelros transmitem pacotes sobre trajetos sobrepostos q ue apresentam dois saltos, como ilus trado na Figura 3.47. Novamente admitamos que cada hospedeiro use um mcc-:Ulismo de temporizac;ão/retrnnsmiss:io para implementar um serviço de transfcrencia confiável de d~clos, que todos os hospedeiros tenham o mesmo valor de À., e que todos os enlaces dos rote;~dorcs tenham c:apacldade de R b)•tcs/segunclo. Vamos considerar a conexão elo hospedeiro A ao hospedeiro C que pass:1 pelos roteadores Rl e R2. A conexão A-C comparti Ih:• o roteador Rl com a conexão D-B c: o roteador 2 com a conexão B-0. Para valores extremamente pequenos de >...,. esgot:uncmos de buiTers sâo rnros (como acontecia nos cemirios de congestionamento 1 c 2) c a '"-\Z:lO é quase Igual à ~-arga oferecida. Para valores de X,. ligeiramente maiores, a vazão correspondente é tamb(m maior. pois mais dados originais esll\o sendo transn'litidos pam a rede c entregues no dest ino, c os esgotamentos ainda s.\o raros. Assim, para valores pequenos de .\,., um aumento em >.,.resulta em um aumen to em >.._. Como ja analisamos o caso de tráfego extremamente baixo, vamos examinar aquele em que À., (c, port:lnto. À~) extremamente alto. Considere o roteador R2. O tr.ífego A-C que chega ao rotc-:tdor R2 (após ter sido repassado de Rl) pode ter uma taxa de chegada em R2 de. no máximo. lt que é a cap.1cidadc do enlace de Rl a R2, não importando qual seja o valor ele À •. Se À~ for extremamente alto para todas as conexões (i nclumdo a conex:'lo ~D). ent:lo a taxa de chegada do tráfego B-0 em R2 poderá ser muito maior do que a taxado tr.lfcgo A-C. Como os tráfegos A-C e B-D têm de compeLir no roteador R2 pelo espaço Umitado de buffer, a quantidade de: tráfego A- C que consegue passar por R2 (isto é, que não se perde devido ao congestionamento de buiTer) diminui cada vez mais à medida que ~

bow4tto4ic~ Redes de com putod ores e o Inle;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

hin: dados originais k

in:

dados originais mais dados retransmidos

R1

Buffers de enlace ele selda finitos companilhados

Hospedeiro C

R3

Figura 3.47

Ouollo remetentes, roteodoles com buffe~S finitos e llojetos com vórios soltos

a carga oferecida de 8-0 vai ficando maior. No limite, quando a carga oferecida se aproxima do infinito. um bulfer \'aZIO em R2 é unedh11amente preenchido por um paco1e B-D e a \'az;lo da concx!\o A-C em R2 em a zero. Isso, por sua vez, implica (/flt a \'aZtlofim t1 fim tlc A-C t1 zero no limite de tráfego pesado. Essas considerações dao origem ao compommen1o dn carga oferecida vtr"SIIS a vazào mostrada na Figura 3.-l8.

''"i

A razão para o decréscimo nna l da vazão com o crescimento da curga oferecida é c'•identc quando COI\Sidcramos a qm11Hid:•dc de trabalho d esperdiçado realizado pela rede. No cenário de alto 1r:lfego que acabamos de descrever. sempre que um paco1c é descanado em um segundo roteador, o tmbalho realizado pelo primeiro para envi:~r

o pacote "o segundo acaba sendo 'dcspercUçado'. A rede teria se safdo igualmente bem (melhor dizendo,

Figura 3.48

Desempenho ob~do no cenório 3, com buffers finitos e trojetos com múltiplos roteadores



2.01

igualmente mal) se o primeiro roteador tivesse simplesmemc descartado aquele pacote c tivesse Ocado inativo. Ma1s ObJeuvamcnte, a cap
Por Wlllo, \'tmos crqui mais 11111 custo, o do dcsmrtc ele pacotes tlcvíclo cro congcstionwntnto- tjutmdo 11111 pcrcolt f tlcsnrrtmlo ao longo dr um caminho, a arpaciclaclc ele tmnsmis.sclo qur foi uscrdtr rm aula um elos tnlaets nntrriorrs para r rpassw o tracou lllf o pomo em truc foi tlrscanado acaba sendo drspcrdiçada.

3.6.2 Mecanismos de controle de congestionamento Na Seç:\o 3. 7, examinaremos detalhada mente os mecanismos espee~flcos do TCP para o controle de conges· tionamento. Nes ta subsc(:.lo, idcntiflcaremos os dois procedimentos m:~is comuns :1dotados, na pr:itiCõl, pam o controle de congesti onamem o. Além disso, examinaremos arquitelUras especrOcas de rede e protocolos de controle de co nges tionamento que incorpornm esses procedimentos. No nfvclnmis amplo, podemos distinguir mecanismos de co ntrole de congcstionmnento con rormc a camada ele rede ofereça ou n:lo tiSSISt~ncia explrcita à camada de tn'lnspone com a nnalld~dc de coruro lc de COIIgcstlonarncn to:

Couuolc ele rougrstlonaiiiCIIIO fim

Hospedeiro A

Realimenta~Ao

peta rede por meio do destinatário

Hospedeiro B

Realimenta~o

diretamente pela rede

figura 3.49 DoiscaRinhos de reotimentoçõD poro inf0011oçõo sobre congestionamentoindicado~ rede

3.6.3 Exemplo de controle de congestionomento assistido pelo rede: controle de congestionamento ATM ABR Concluímos esta seç-ao com um breve estudo de caso do algoritmo de co ntrole de congestionamento ATM ABR. :thcnt:unos que nossa meta aqui ru1o é, de modo algum, descrever dctalh:~dameme aspectos da arquitetura ATM. mas mostror um protocolo que adota uma abordagem de controle de congestionamento notavelmente diferente da adotada pelo protocolo TCP da Internet. Na verdade, apresentamos a seguir apenas os poucos aspectos da arqunetura ATM necessários para entender o controle de congestionamento ABR. Fundamcntalmcme, o ATM adota uma abordagem orientada paro crrculto vrrtual (CV) da comutar;ão de pacotes. Lembre. d:l nossa discussão no Caphulo 1, que isso significa que cada comutador no caminho cmrc a fome e o destino manterá est.1do sobre o CV emre a fonte c o desúno. Esse estado por CV pcmtite que um comutador monitore o componamcnto de remetentes indh•iduais (por exemplo, monitorando sua taxa m~dia de transmissão) c realize açOes especificas de controle de congestionamento (tais como sinalizar explrcit:unente ao remetente para que ele rcduzn sua ta.'
O ABR foi projetado co mo um serviço de tronsfcrência de dados elástico que faz lcmbror, de certo modo, o TCP. Quando a rede está vazia. o serviço ABR deve ser capaz de aproveitar a ' 'an tagem da la rgura de banda disponível. Quando a rede está co ngestionada, deve limitar sua taxa de transmlss:lo a algum va lor mínimo predeterminado de taxa ele tronsmiss;'lo. Um tutorial detalhado sobre controle de congestionamento e gerencia mento de tráfego ATM ABR é fornecido por Uain, 19961. A Figum 3.50 mos tro a es trutura do co111rolc de eongestion;lmento para ATM ABR. Nessa discuss.,o, adotaremos a terminologia ATM (por exemplo, usaremos o termo 'comutador' em vez d e 'roteador' c o termo 'célula' em vez de ' paco te') . Corn o serviço ATM ABR, as c~lulas de dados são transmitidas de urna fonte a um des tino por meio de uma série de cormuadores imcrmcdiários. Intercaladas às células ele dad os estilo as células de gerenciamen to de recu rsos, ou células RM (rtsourcr-matragemtnt cells); essas c~l ulas podem ser usadas para portar mfo rmar;õcs relacionadas ;tO congestionamento entre hospedeiros e comu tadores. Quando uma célula RM chega a um destinatário, ela será '\•irada' c enviada de \'Oita ao remetente ( poSSI\•elmcntc após o d estinatário ter moclincado o comcúdo dela). Também é possivel que um comutador gere. ele mesmo. uma célula RM c a em·ie dirctamemc a uma fome . Assim. células RM podem se,r US.'ldas para fo rnecer rcahmencaç.í o diretamente da rede c também rcalimemaç:lo da rede por imcnnédio do destinatário, como mostra a Figura 3.50.

O cont ro le de congcsuonamcnto ATM ABR ~ um m~todo baseado em taxa. O remetente estima explicitamente uma taxa máxima na qual pode envia r e se autorregula de acordo com ela. O serviço ABR provê três mecanismos para sinalizar informações relacionadas a congestionamemo dos comutadores ao des tinatário:



2.03

Oestíno

..-...,

Legenda: Células RM

Células de dados

Figura 3.50 Estruturo de conhole de congesliooomento ATM ABR

Blr EFCI. Cada cfl lllll ele• clttclos contém um bit EFCl de ind icação c...:pliclta de congestion a mento à frente (t'Xflrlcll for ward congtslion imliccuion). Um comumdor de rede congestionado pode modificar o bit EFCI dentro de umíl célula p:ll'a l. a fim de sinalizar congestionamento ao hospedeiro dcstinatdrio, que deve verificar o bll EFCI em todas as células d e dados recebidas. Quando uma célula RM chega 4\0 clcstin
Ajuste de ER. Cada célula RM contém também um campo fR (r~·pllcll mlr - raxa cxplfclta) de dois bytcs. Um comutador congestionado pode reduzir o valo r contido no campo ER de uma célula RM que cstll passando. Desse modo, o campo ER será ajustado para a taxa rnfnima s uportável por todos os c:omutndorcs no trajeto fonte-destino. Uma fonte ATM A8R ajusla a 1axa na qual pode enviar células como uma função dos valores de Cl. Nl c ER de um:~ célula RM devolvida. As regras para f.1zer esse ajuste de taxa sM bastante complic:•das c um tanto tediosas. O leitor poderá consultar U11in , 19961 se quiser saber mais detalhes.

3.1 Controle de congestionamento no TCP ' esta scç;\o, voltamos ao estudo do TCP. Como aprendemos na SeçJo 3.5. o TCP prov~ um setYico de transfert ncía confiável entre dois processos que rodam em hospede~ ros dtfcrcntcs. Outro componente extremamente importante do TCP é seu mecanismo de comrole de congestionamento. Como indtC':lmos na scc:lo anterior, o TCP deve usar controle de congestionamemo fim a IIm em vez de controle de congestionamento assistido pela rede, já que a camada !P não fornece aos sistemas l'inais realimentação expirei ta relativa ao congestionamento da rede.


ln;.;l~e;.;rn;.;e;.;.t_________________________

i\ abordagem adotada pelo TCP é obrigar cada remetente a Umitar a taxa :'1 qual enviam tráfego para

sua conexão como uma fun~\o do congestionamento de rede JXrCebrdo. Se um remetente TCP perceber que há pouco congestionamento no caminho entre ele c o destinatário, aumentará sua taxa de cnvro; se perceber que há congestionamento ao longo do caminho. reduzirá sua taxa de envio. Mas essa abordagem levanta tr~ questões. A primeira é como um remetente TCP limita a taxa à qual envia tr.Hego para sua conexão? A segunda é como um remetente TCP percebe que há congestionamento entre ele c o destinatário? E a terceira, que algoritmo o remetente deve utilizar para modificar sua taxa de envio corno urna funç;lo do congestionamento l'irn a l'im? Em primeiro lugar. vamos examinar como um remetente TCP limrta a taxa de envio :'1 qual emria tráfego

para sua concx•\o. a Seção 3.5. vimos que cada l:tdo de umll conexolo TCP consiste em um buffer de recepção, um buffcr de envio c diversas variáveis (Las tBy teRead. rwnd c assim por di:mte). O mc<::mismo de controle de congestionamento que opera no remetente monitora uma \~tri:ivel adicronal. a janela de congestiona mento. A janela de congestionamento, denominada cwnd, impOe uma limitação :'1 taxa it qual um remetente TCP pode enviar tráfego para dentro da rede. Especificamente, a quantidade de dados m\o reconhecidos em um hospcdeiro nao pode exceder o mfnlmo ele cwnd c rwnd, ou seja: lastByteSent- lasLByleAcked S min(cwnd .

r~mdl

Para focalltar l\ discussão no controle de congestionamcmo (ao comrárlo do controle ele Ouxo), daqui em diante vamos :1dmitlr que o buffcr de recepção TCP seja tàO grande que a llmitaç-Jo da j anela de rcccpç:io pode ser desprezad:t; assim, a quantidade ele dados m\o reconhecidos no remetente estM:I limitada exclusivamente por cwnd. Vamos admitir tambtm que o remetente sempre tenha dados para em,iar, isto~ . que todos os segmentos demro da janela de congestionamento sejam enviados. i\ rcstriç;lo acima limita a quanudadc de dados não reconhecidos no remetente c. por conseguinte. limita

índírctarnente a taxa de envio elo remetente. Para entender mclhor. considere uma conex:\o na qual perdas c atrasos de 1ransnus~\o de pacotes sejam desprezíveis. Enli\o. em hnhas gerais. no lnrcro de cada RTT a limuação permite que o remeteme envie cwnd bytcs de dados para a conexão; ao final do RTT, o remetente recebe reconhecrmentos para os dados. Assim, a taxa tk cn~io tio mncttutc t trrJroxinwclamrult rwud/R1T byres por scguuclo. Porltmto, tl)ustwrtlo o wr/or c/r cwnd, o rcmelenlc pode aju.SL«r"
Já consideramos como~ detectado o congestionamento; ~1gora \O:Imos cons•dcr:1r o caso mais otrmista ele uma rede livre de congesrionamcmo, isto é, quando não ocorre um evento de perda. Nesse L"aSO. o TCP remetente recebem reconhecimentos p:~ra segmentos anteriormente n:\o reconhecidos. Como veremos, o TCP considerará a chcg<~da desses reconhecimentos como uma indica~"Uo de que tudo está bem- os segmentos que estão sendo transmitidos para a rede cst:lo sendo entregues com sucesso no destinatário - c usará reconhecimentos para aumentar o 1amanho de sua janela de congestjonamento (c, por conseguinte. sua raxa de transmissão). 'otc que, se os rcconhecrmcntos chegarem ao remetente a urna taxa relativamente barxa (por exemplo, se o atraso no eamrnho fim a flm for alto ou se nele hou\'er um enlace de baixa largura de banda), cnt;lo a janela de congcsuonamento será aumentada a uma taxa relativamente baixa. Por outro l:tdo, se os reconhecimentos chegarem a uma l:lxa alta, cnt:'lo a Janela de congestionamento será aumentada mais raprdamcntc. Como o TCP utiliza reconhecimentos para acionar (ou regular) o aumento de tamanho de sua janela de congestionamento, diz-se que o TCP é autorregula do.


(ama do de lronsporle

205

Dado o mecanismo de ajliStar o \'lllor de cwnd paro controlar a taxa de envio, permanece a importame pergunta: Como um rcmeteme TCP deve determinar a taxa a que deve enviar? Se os rcmctcmcs TCP enviam eolcm-amcnte muito rJpido, eles podem congestionar a rede, levando ao tipo de eongcsuon:unento que vimos na Figuro 3.8. Realmente, a vcrs:lo de TCP que vamos estudar brevemente foi desenvolvida em resposta :1os congestionamentos d:1lntcrnct observados Uacobson. 1988) sob versões anteriores do TCP. Entretanto, se os remetentes forem multo cautelosos c enviarem lemamentc. eles podem subuulizar a largura de banda na rede: ou seja. os remetentes TCP podem enviar a uma taxa mais alta sem congcsuonar a rede. Ent:'lo. como os remetentes TCP detennln:ml suas taxas de envio de um modo que Mo congcsúonem a rede mas. ao mesmo tempo. raçam uso de toda a largura de banda? Os remetentes TCP são clarnmeme coordenados. ou existe urna :1bordagem distribuída na qual eles podem :~ustar suas taxas de envio baseando-se somente nas informações locats? O TCP responde a essas perguntas ut iliz:~ndo os seguintes princlpios: Um sc·gmruto fU'nlido imt'lica em congestíorwmcnto, 1101 tanto, a lliX
w.xct do rcmctc:utc t'odc
A chegada de reconhecimentos ê tida como urna indiC0 depois. Observe que não h:\ nenhuma sinalizaç.'i.o explidla de congestionamento pela rede - os ACKs c cvcmos ele perda servem como sinais implícitos- e que cada remetente TCP atua em informaçõe..o; lot-ais em momentos diferentes de outros remctcmes TCP.

Ap(ls eSS.'l visl\o gemi sobre controle de congestionamento no TCP. agora podemos considerar os detalhes renomado :tlgoritmo de controle de congcstiOtHimcnto no TCP. sendo primeiramente descrito em Uacobson, 1988) c padronizado em [RFC 2581 1. O algoritmo possui três componentes princlp<~ls: (1) partida lenta, (2) contenção de congcstioammcmo c (3) recuperação rápida. A paníd:t lento c a contenção de congcstionaanemo sno componentes obrig:~tórios do TCP. diferenciando em como eles aumentam o tam:mho do cwnd ern resposta a ACKs recebidos. Abordaremos em poucas pal:~vras que a partida lenta aumenta o tamanho do c11nd de forma mais rJpida (apesar do nome!) do que a contenção de congcstjonamcnto. A recuperação mpid
Partida lenta Quando uma concxlo TCP começa, o valor de cwnd normahnemc é inicializado em 1 MSS [RFC 33901. resultando em uma t:1xa micial de envio de aproximadamente MSSIRTT. Como exemplo. se MSS • 500 bytcs c RTT = 200 milissegundos, então a taxa de envio inicial resultante é aproxrmadamente 20 kbps apenas. Como a largurn de banda disponível para a conexão pode ser muito maior do que MSSIRTT, o remetente TCP ia gostar


de aumentar a quantia de largura de banda rapidamente. Dessa forma , no estado de panida lema, o \'alor de cwnd começa em I MSS c :nunenu1 l MSS toda vez que um segmento transmtudo ~ reconhecido. No exemplo da Figura 3.51 , o TCP envia o primeiro segmento para a rede c aguarda um rct'Onhccimcnto. Quando o rcconhc· cimcmo chcg.t, o remeu:nte TCP aumenta a janela de congestionamento para I MSS c envia dois segmentos de tamanho máximo. Esses segmentos são reconhecidos. e o remetente aumenta a janela de congestionamento para 1 !\•ISS pam cada reconhccimcmo de segmento, fornecendo uma janela de congestionamento de 4 MSS c assim por diante. Esse processo resuha em uma rnuhiplicaç-lo da taxa de envio a cada RTT. Assim. a taxa de envio TCP se inicia lenta. mas cresce exponencialrneme durante a fase de partida lenta. Mas em que momento esse crescimento exponencial termina? A partida lenta apresenta diversas respostas pam css.1 pergunta. Primeiro, se houver um evento de perda (ou seja, um congestionamento) indicado por um esgotamento de tcmporlzaçilo, o remetente TCP estabelece o valor de cwnd para l c inicta o processo de partida lenta novamente. Ele também estabelece o valor de um:l segunda variável de est:1do, s s th resh (abreviação de •sloiV stmt thrcsholclllimiar de partida lema)) pam c~md 12- metade do ' 'ator d:1 ja ne l:~ de congestionamento qt~ando cst~ foi dctcct:tdo. O segundo modo pelo qual a partidr~ lellt:1 pode terminar é ligado diretamente ao v:~ lo r de ss thresh. Visto que ss thresh é metade do valor de cwnd quando o congestionamento foi detectado pela (tftima vez, pode ser uma :1thudc precipitada eonLinuar duplic<~ndo Cl·llld ao atingir ou ultmp.1SS3r o valor de ss thresh . Assim, quando o valor de cwnd se igualar ao de ss lhre sh , a partida lema 1crmina c o TCP é <~lt{'· mdo para o modo de prcvcnç:lo de congestionamento. Como \'Cremos, o TCP aumenw cwnd com mais C:'lutcla quando está no modo de prevcnçM ele congestionamento. O último modo pelo qual a particl:~ lenta pode terminar é se trts ACKs duphc:ados forem detectados, caso no qual o TPC apresenta uma rctmnsmi ss~o rápida (veja Seção 3.5.-+) c cntm no estado de re<:upcm~·ão rápida. como disculido abaixo. O comportamcnlo do TCP n:l partida lenta cs1:1 resumido na descriÇ1\0 FSM do controle de congestionamento no TCP na Figura 3.52. O algoritmo de paruda lenta foi •mcialrncntc proposto por Uacobson, 19981; uma abordagem semelhante a parttda lenta 1ambêm foi proposta de maneira independente em Uain, 19861.

Hospedeiro A

Hospedeiro A

um...,. --,memo

-------· ...:

dois~

9memos

Tempo

Figura 3.S 1 Partido lento TCP

Tempo


evnd-1 HSS ss tllresh- 64 K8 dupACKcount-o ' ,

-1 ,..

~ r)

(

'•

r•

Partida

~rn

. . . :"'"'"

.;;..._ _ _ _ _ __

lenta

Esgourento de

tsoou~nto

te~aporlaçlo

1C [ f " /1 I ljl

I

Pr~vençJo de co~lonam~mo

tenoorl z~çlo

sstllresh-cwnd/2 cwnd- 1 HSS dupACKcount-o

J ......_,

JI~Ol

ft r.

dupACkcount-3 ss thresh-cwnd/2 cwnd- uthruh•3 r 'ti.Ali m ' os 111 1~1 · m

2.07

Novo ACK cvnd- cwnd+HSS · CHSS/ewndl dupACKcount-o

Novo ACK Cwnd-cvnd+IISS dupACKcount-o

ACK 4up 11 cedo dupACKcount++ A

(omodo de tran sporte

ACK dupll cado dupACKcount++

sstllruh- cvnd/2 cvnd- 1 HSS dupACKc:ount-o r,.rr;m
Novo ACK cvnd- sstnresn dupACKcount-o

1

' "''""""''''o<,...,..,., •• '·''"m~

qtt "'fO»

ssthresh-cwnd/2 cwnd- ssthresh•3 r !f " ' 11•'

Re<:uperacAo

rápida

'(In J •• 4UC /JIIum

~

ACK duplicado cwnd-cvnd+HSS nros como ptrmi/ido r~gura

3.52

Oes<~õo

FSJA do controle de
Prevenção de congestionamento 1\o entrnr no estado de prevenç;.\o de congesllonamemo. o valor de cwnd é aproxirnadameruc metade de seu valor quando o congestionamento fo i encontrado pela última vez- o congestiomunem o poderia estar por pen o! Desta forma, em vez de d upli~r o valo r de cwnd a ~da RIT, o TCP adota uma abordagem mais conservadora c aumenta o valor de cwnd por meio de u rn único MSS a cada RTT IRFC 25811. Isso pode ser rcaliz.ado de diversas formas. Uma abo rdagem comum t o remetente a umentar cwnd por MSS bytes (MSSicwnd) no momento em que um novo reco nhecimento cheg;~r. Por exemplo, se o MSS possui 1.~ 60 bytcs c cwnd . H .600 bytcs, ent:lo 10 segmentos cst;\o sendo enviados de ntro de um RTT. C
Mas em que mo mento o aumento linear da prevenção de congest ionamento (de 1 MSS por RTT) deve terminar? O algoritmo de prevenção de congestionamento TCP se comporta da mesma forma quando ocorre u rn esgotamen to de temporíza~·:lo. Como no caso da parlida lenta: o valor de cwnd ~ajustado J>arn l MSS, c o valor de ss thresh é atualizado para memde do valor de cwnd quando ocorreu o evento de perda. Lembrese. entret.lnto, de que um evento de perda também pode ser acio nado por um evento ACK dupli~do triplo. este caso. a rede conttnua a enviar segmentos do remeten te ao destinatário (como indicado pelo recebimento de ACKs duplicados). Portanto, o comportamen to do TCP para esse llpo de evento de perda deve ser menos drástico do que com uma perda de esgotamento de temporização: O TCP reduz o valor de cwnd parn metade (adicionando em 3 MSS a mais para contabilizar os ACI
bow4tto4ic~ Redes de co 111 pu tod ores e o Inle ;.; ro;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

ss thres h como metade do de cwnd quando os ACKs duplicados triplos foram recebidos. Então, entro-se no estado de rccupernçâo rápida.

Recuperação rápido Na recupern~-:lo rápida, o \'alor de cwnd é aumen tado por 1 MSS para cada ACK duplicado recebido no segmento perdado que fez com que o TCP cmrasse no modo de recuperação r.lpida. Consequentcmcnu.·. quando um ACK chega ao segmento perdido, o TCP entra no modo de prevenç-ão de congesuonamento após reduza r c wnd. Se um evento de esgotamento de temporização ocorrer, a recuperação rápida~ alterada para o modo partida lenta após desempenhar as mesmas ações que a partida lenta c a prevenção de <.:ongestionamento: o '"'lorde cwnd é ajustado para I MSS, c o valor de ss thres h. para metade do valor de cwnd no momento em que o C\'ento de perda ocorreu. A recupcraç!lo rápida~ recomendada, mas não exigida, pam o protoco lo TCP IRFC 25811 . É in teressante o fa to de q ue uma amig01 vcrs.'lo do TCI\ conhecid:a como TCP Tahoe, reduz incondícion~lmente sun jrtnela de congcstlonmncnto para 1 MSS c en trou na fase de pa rtida lenta :1pós um evento de perda de csgouuncn to do temporizador ou de ACK duplicado triplo. A versão atual do TCP. a TCP Reno. incluiu a recuperação rápida. A Figura 3.53 ilustra a cvoluç;lo dajnnc la de congestionamento do TCP para as versões Reno c T:ahoe. Nessa figura , o limi.-.r ~. inicialmente, igu.-.1 " 8 MSS. Nas primeiras oito sessões de transmissilo, as duas versões possuem ações id~nticas. 1\ j:mcla de congestionamento se eleva exponencialmente rápido durante a partida lenta c atinge o li miar na quarta sc.ssào de transnússâo. A janela de congestion:uncruo, cnulo, se elc,•a linc-Jrmcmc até que ocorra um evento ACl< duplicado triplo, logo após a oitava sessão de transmissão. Observe que a janela de congestionamento~ 12 • MSS quando ocorre o e,·cnto de perda. O valor de ss thr es h ~. enlào, ajustado para 0.5 • cwn d • 6 • MSS. Sob o TCP Reno. a janela de congestionamento ~ ajustada para cwnd • 6 • MSS. c depois cresce li nearmcnte. A Fagura 3.52 apresenta a descrição FSM completa dos algoritmos de controle de congestionamento partida lenta. prevenç;\o de congestionamento c recuperação rápida. A figum também andica onde pode ocorrer transmiss:lo de novos segmentos ou segmentos retransm iLidos. Embora seja importante diferenciar controle/ retransma~\o de erro TCP de controle de congestionamento no TCP. também é importante avaliar como esses dois aspectos do TCP estão inscpamvclmemc ligados.

Controle de congestionamento no TCP: retrospectivo Após nos aprofundarmos em detalhes sobre partida len1a. prevcnç;\o de congestionamento e recuperação rápida, vn le a pe na agon1 voltar c ver a noresta por entre as árvores. Dcsco rtsidcrando o pcrfodo inicial de partida lenm, quando u rna conex•\o se inicia, c supondo que as pe rdas são indicadas por ACKs dup licados triplos e ni'to por esgotamentos de temporização, o controle dr congestionamento no TCP consiste em urn aumento li near

.... o

14

c:

12

E

"'~ ·-g õ 10

.. ..... ~E

.. c

3~ ., E

8

ssthresh --------

6

-o.., 4 ... ~

Qi

c

~

2 0~-r-r~~~-,-..-r-r-~.-,-,-~~

o

1

2 3 4

s

6

7

8

9 10 11 12 13 14 15

Rodada de transmis~o

Figura 3.53 Evolução do jonelo de congestionamento doTCP (lohoe e Reno)



209

(adi ti\'0) em c wnd de I MMS por RTT c, então. uma rcduç;\o à metade (diminuição muhipllcath'a) de cwnd em um evento ACK duplicado triplo. Por esta razão, o controle de congestionamento no TCP t rrequenternentc denominado aumento aditivo. dimlnuiç'lo multiplicativa (AI:\10). O controle de congestionamento AIMD raz surgir o comport:tmcnto semelhante a ~dentes de serra~. mostrado na figura 3.5_., a qu:tltarn!Xm ilustra de rorma mtcrcssante nossa i ntui~i\o anterior sobre a "busca" do TCP por largura de banda- o TCP aumenta linearmente o t:ummho de sua janela de congestionamento (c , ponanto, sua taxa de transmiss.lo) até que um evento ACK duplicado triplo ocorra. Então, ele reduz o tamanho de sua janela por um [ator de dois mas começa novamente a aumcntã-la linearmente, buS<.-ando saber se há uma largura de banda adicional dasponívcl. Como observado anteriormente, a maioria das implementações TCP, atualmente, utihza o algoritmo Reno IPadhyc. 200 1). Foram propostas muitas variaçocs do algoritmo Reno IR FC 3782; RrC 20 181 . O algorilmo Vegas IBrakmo, 1995; Ahn, 1995)tenta e\stionamcnto (incl uindo o TCP Reno c o TCP Vegas) c permhc que um administrador de sistema conn gure qua l vc rs:\o do TCP será utilizada. A versão padrão do TCP no Linux ''crs:\o 2.6.18 roi dennida p:un CUBIC IHa, 20081 . uma versão do TCP desen vokida para :a plie
Descrição mocros<ópi<~S foscs normalmente são muito curtas, visto que o remetente s;ai delas com rapidez exponenciaL) Durante um detcrmmado lmervalo de \ltagem de ida e volta, a taxa :'\ qu:•l o TCP cn\lia dados é uma runção da janda de congestionamento c do RTT corrente. Quando o tamanho da j;~ncl:• for w bytes, c o tempo de " i•lgcm de ida c volta corrente for RTr segundos. :1 t;axa de transmissão do TCP será :~proximadamcntc w/RTT. Emão, o TCP raz uma sondagem em busca de alguma largura de

o 24 K

~ :! E

·a 16K

g.o v

Gl 'Q

... ...... "ii c

Tempo

Figura 3.54 Controle de congestionamento por aumento auditivo, diminuiçõo multiplicativo

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------banda adicional aurnenmndo w de 1 MSS a cada RIT até ocorrer um C\•ento de perd:l. Seja \V o valor ele w quando ocorre um evcmo de perda. Admitindo que RIT c \V são aproximadameme constantes durante o período da conexão, a taxa de transmiss<1o fica na f.tlxa de W/(2 · a W/RIT.

Rm

Essas suposições lc,•arn a um modelo m:tcroscópico muito simplificado para o comportamento elo TCP em rcgtme. A rede descarta um pacote da conexão quando a taxa aumen ta p:tra W/RTT; então a uxa é rcduzid:t ;. metade c, em seguida, aumenta de um MSSIRTT a cada RTT até alcanç:~r W/RTT no,·amcllle. Esse processo se repete continuamente. Como a vazão do TCP (isto é , a uxa) aumenta lincõlnncnte entre os dois valores extremos. ternos: . de um~ concxioo- 0,75·\V V:tá'lo méd1:t _;__ __ R1T

Usando esse modelo muito idealizado para a dinâmica de regime permanente do TCP, podemos também derivar uma interes.s:mte expressão que relaciona a taxa de perda de urna concx1\0 com sua largura de banda disponível [Mahdavi, IQ97I. Essa derivação está delineada nos exercfcios de fixa~-:lo. Um modelo mais sofisticado que demonstrou emplrlcamcntc estar de acordo com dados medidos é apresentado em IPaclhyc, 20001 .

TCPs futuros É importante perceber que o controle de congcstionamemo no TCP evoluiu ao longo dos anos e, na verdade,

continu:t a evoluir. Um resumo do controle de congestionamento no TCP no final da década de 1990 pode ser encot11r.1do no I RFC 2581): se quiser uma discussão sobre desenvolvimentos recentes do controle de congestionamento no TCP, \'cja IFioyd, 2001). O que era bom para a Internet quando a maior parte das conexões TCP carregav·a tráfego SMTP, FTP c Telnrt não é necessariamente bom para a Internet de hoje, dominada pelo HTTP, ou pam uma Internet futura, com seniços que ainda nem sonhamos. A necessidade da e'·oluçào contfnua do TCP pode ser ilustrada constderando as conexões TCP de alta veloctdadc que soderia ser i>C rdida c ainda assim permitisse que o algoritmo de controle de congestionamento no TCP delineado na Tabel:1 3.52 alcançasse a desejada taxa de 10 Gbps? os cxerclcios de fixação deste capitulo voe~ percorrerá a dcduç;lo de uma fórmula que rt'laciona a vazM de uma concx;1o TCP em função da taxa de perda (L), do tempo de viagem de ida e volta (RT1} c do tamanho máximo de segmen to (MSS): .

Vazno médnl de uma conexão •

l,22·MSS

J'[.

R17' L

Usando css:t fórmula, podemos ver CJUe, pard ;1lcançar um:~ vttzão de 10 Gbps. o algoritmo de controle de congestionamento no TCP ele hoje pode tolerar uma probabilidade de perda de segmentos de apenas 2 · 10' 10 (equivalente a um evento de perda a cada 5 bilhões de segmentos) - uma taxa muito baixa. Essa observação levou muitos pesquisadores a lmrestlgar novas versões do TCP especifk"amente projetadas para esses ambientes de alta ''clocidade: Uin, 2004: RFC 3649; Kell}•. 2003: Ha. 20081 apresentam discus.sOcs sobre esses esforços.

3.7.1

Equidode

Considere K conexOcs TCP, cada uma com um caminho Orna Om diferente. mas todas passando pelo gargalo em um enlace com uuca de transmissão de R bps (aqui, gargalo nn 11111 t~tlacr quer dizer que nenhum dos outros enlaces ao longo do caminho de cada conexão está congestionado e que todos dispõem de abundante capacidade de transmissão em comparação à capacidade de transmissão do enlace com gargalo). Suponha que cada conexão


(ama da de tronspo rle

2.11

cst:\ transrerindo um arquivo grande c que não h:\ tráfego UDP passando pelo enlace com gargalo. Dizemos que um mccamsmo de controle de congestionamento é jusro se a taxa média de tmnsmissâo de Cõlda conexão ror aproxrmadamerne RIK; rsto é, c.tda urna obtém uma parcrla igual da largurn de banda do enlace.

O algorumo AIMD do TCP é justo. considernndo. em cspcci:tl, que drrcrcntes conexões TCP podem começar em momentos dircrcntes c, assim, Ler tamanhos de janela direrentes em um dado instante? IChiu, 19891 explica, de um modo elegante e mwitivo, por que o controle de congestionamento converge para rorncccr um compartilhamento j usto da largurn d e banda do enlace entre conexões TCP concorrentes. Vamos considcrnr o caso simples de duas conexões TCP comp:milhando um unico enlace com taxa de trnnsmissão R, como mostrn a Figurn 3.55. Vamos admitir que as duas conexões tenham os mesmos MSS c RTI (de modo que, se o tama nho de s uas janelas de congestionamento ror o mesmo, então terão a mesma vazão) e uma grande quamidaclc de dados para enviar e que nenhuma outra conex~\o TCP ou datagrnmas UDP atravesse esse enlace com1>ar1tlhndo. Vamos ignorar também a rase de p:mida lenta do TCP e admi tir que as conexões TCP estão opcmndo em modo prcvcn~·;.\o de congestão (AlMO) todo o tempo. A Figura 3.56 mostro a va~lo alcançada pelas duas conexões TCP. Se ror para o TCP compartilhar equilativamerlle a largurn de banela elo enlace entre as duas conexões, então a vaz:1o alcançada clevcr:l cair ao longo ela linha a 45 grous (igu:~l compartilhamento da largura de b!lnd:~) que p:trte da o rigem. ldcalmcmc, a soma das d uas vazOes seria igual a R. (Co m certeza, mlo ~ uma silllaçào desejável ~·ada conexão receber um comparlilhamcnLo igtml, mas igual a zero, da capacidade do enlace!) Portamo, o objetivo ~ que as vazões a lcançadas fiquem em algum lug
Conex3o TCP 1

Figura 3.SS

Duas conexões TCP compartilhando umúnico enlace congestionado


/

R

~Igual

/

N

...~

/

o

compartilhamento da largura da banda

c

..

3 "O

oi N

~ A

vazão da conexlio

1

R

Figura 3.56 Vozõo olconsodopelos
Equidade e UOP Acaba mos de ver como o controle de conges tionamento no TCP regula a taxa d e trans missão de uma apli· <-aÇ
por Intern et c videoconferência, muitas vezes não rodam sobre TC P exatamente por essa raz:\o - elas não querem que S\la taxa de tra nsmiSS<\o seja Iími tada, mesmo que a rede esteja multo congcslionada. Ao contrá rio, preferem rod ar sobre UDP, q ue nno tem controle de congestio namento. Quando rodam so bre esse protocolo. as ap licações podem p<•ss;•r seus áudios c vídeos p-.ua a red e a uma tax:• consL;ullc c. ocasionttlrncnle, perde r pacotes, em vez de red uzir s uas taxas a níveis 1us tos' em hor.Irios d e congestlo n:un ento c ml o pe rder nenhum d eles. Da pcrspccti''" do TCP, as aplicações de multimfdia que rodam so bre UDP nào sáo justas- elas nilo cooperam com as out ras conexões nem aj ustam s uas taxas de transmissolo de ma neira adequada. Como o controle d e congestionamen to no TCP red uz in\ s ua taxa de transmiss;lo quando hou,•c r aumento de congestionamento (p erda). enq uanto fom es UDP não precisam faz:er o mesmo, ~ possfvel que essas fontes desalojem o tráfego TCP. Uma área nn portantc da pesqu isa hoje é o desenvolvi mento d e mecanis mos de controle de congestionamento que Impeçam que o trMego d e UDP leve a \'aZào da Internet a uma l)arada repentina IFlo)•d , 1999; Floyd. 2000: Kohlcr. 20061.

Equidade e conexões TCP paralelos Mas. mesmo que pudéssemos obrigar o tráfego UOP a se comportar com eq~udade. o problema aind a não estaria comple tamente resolvido . Isso porque não há nada que impeça um a apl icação de roda r sobre TCP usando múltiplas conexões paralelas. Por exemplo, browsers Web frequentemente usam múhiplas conexões



213

TCP paralelas paro m lllsfcrir os vários objetos de uma página Web. (O n umero exato de conexões muhiplas pode ser co nfigurado na maioria dos browsers.) Q uando usa m uh iplas co nexões paralelas, uma aplicação consegue uma fraçM maior da largura de banda de um enlace congestionado. Corno exemplo, considere um enlace de taxa R que está suportando nove aplicações clie nte-servidor em curso. c cada uma das aplicações está usando uma concx:lo TCP. Se surgir uma nova aplicação que também ltlilize uma concx:lo TCP, en tão cada aplicaç;\o conseguirá aproximadamente a mesma taxa de trans missão igual a R/10. Porém. se. em vez disso, essa nova aplicação usar ll conexões TCP paralelas, então ela conseguir:\ uma alocação injusta de mais do que R/2. Como a penetração do trnfego Web na Internet é grande, as muhiplas conexões paralelas não s:lo incomuns.

3.8

Resumo

Começamos este capitulo estudando os servi ços que um protocolo de camada de t ransporte pode prover às ap l ica~·oes de rede. Por um lado, o protocolo de camada de tr:u1spone pode ser muito s imples c oferecer serviços básicos i\s aplicações, provendo apcn;ts uma função de mu ltiplcxaç:\o/dcmultiplcxaçào pam processos comunicantes. O pro tocolo UDP da Internet é um exemplo desse serviço b:lsico d e um pro tocolo de camada de tmnspo n c. Por outro lado, um protocolo de camada de transporte pode fornecer uma ,·ariedadc de garantias às aplíca~·ocs, como entrega confiável de dados, gar::mtias contra atrasos e gllran tías de largura de banda. no obstante, os serviços que um protocolo de transporte pode prover s;\o frcquemcmcme limitados pelo modelo ele serviço do protocolo subjacente de camada de rede. Se o protocolo de camada de rede niio puder proporcionar garantias conLra atraso ou gar-antias de largura de banda para segmentos da camada de transporte, ent:lo o protocolo de camada de transporte n:lo poderá fornecer essas garantias para as mensagens enviadas entre processos. Aprendemos na Seção 3.4 que um protocolo de camada de transporte pode prover transfcr~ncia confiável de dados mesmo que a camada de rede subjacente seja não confiavel. Vimos que há muitos pontos sutis na transfcr~ncm conflávcl de d:tdos. mas que a tarefa pode ser realizada pela combma~'110 cutdadosa de reconhecimentos, temporizadores, rctransrmssõcs c nümeros de sequénda. Embora tenhamos examinado a Lransfcrencia confiável de: dados neste capitulo, devemos ter em mente que essa tran!.ferencia pode ser fornecida por protocolos de camada de enlace. de rede, de transpone ou de aplicação. Qualquer uma das camadas superiores da pilha de protocolos pode implementar rcconhccimemos, temporizadores. retransmissões c números de sequencia c prover transferência confiável de dados para a camada s ittmda acima dela. N•t verd ade, com o passar dos anos, engenheiros c cientistas da comp11tação projetaram e implcment.:uam, inder>enden temcntc, protocolos de camada de enlace, de rede, de transporte c de ar)lícação que forn ecem tmnsfcr~ncia confiável de dados (embom muitos desses protocolos ten h:un dcsap:1rccido silen ciosamente). Na Seção 3.5, examinamos deta lhnclamcruc o TCP, o protocolo de camada de tr-.msporte eonfi:lvcl o rientado para concxllo d~t lntcmet. Aprendemos que o TCP t complexo c envolve :a conexão, controle de Ouxo, estimativa de tempo de viagem de ida c ,,olta, bem como transrt>r~ncia confiável de dados. Na verdade. o T CP t mais complexo do que nossa dcscrlçllo- intcnciormlmcntc, não discutimos uma variedad e de ajustes, acertos e melhorias que est~o implementados em várias versões do TCP. Toda css:t complcx icl;~de, no cnt:lnto. nca escondida da aplicaçuo de rede. Se um cliente em um hospedeiro quiser enviar dados de maneira confiável para outro hospedeiro, ele simplesmente abre uma porta TCP para o sen

do julga que o caminho da conexdo TCP está livre de congestiomuncnto c reduz muhiplícativarnente sua taxa de transm1ss:lo quando ocorre perda. Esse mecanismo também luta para dar a {':lda concx:lo TCI> que passa por um enlace congestionado uma parcela igual da largura dr banda da c::oncxt,o. Examinamos ainda com um certo dct;~lhc o impacto do estabelecimento da conexão TCP c da p<~rtida lenta sobre a l<~t~ncia . Observamos que. em muitos cenários importantes, o cstabclccimcnto da conexão c a partida lenta contribuem de modo significativo para o atraso fim a Om. Enfatizamos m:lis uma vez que. embora tenha evoluído com o passar dos anos. o controle de congestionamento no TCP permanece como u ma área de pesquisa mtensa c, pro,oavclmente. cominuarã a evoluir nos anos vindouros. Nossa discussão sobre os protocolos específicos de transporte da Internet neste capitulo se focalizou no UDP e no TCP- os dois "burros de carga~ da camada de transporte da lmernet. Entret:mto, duas d~cadas de cxpc· ri~ncia com esses dois protocolos identificaram circuns tâncias nas quais nenhum deles é apropriado de maneira idt'al. D<'Ssr modo, pcsquisndorts se ocuparam em dcscnvoh•er protocolos da camada de tra nsporte adicionais, muitos dos quais s:lo, agora, p:-~drOcs prop<>stos pelo IETF. O Protocolo de Controle de Congestionamento de Datagr.una (DCCP) IRFC4340l oferece um serviço de baixo consumo. oricmndo a mensagem c não confiável de forma semelhante ao UDP, mas com uma forma sei ceio· nada ele aplicar,:no de controle ele congestionamento que é compatível com o TCP. Caso uma aplicaçno necessitar de uma tr:-~ usfcr~ncia de dados confiável ou scmiconflável. cntilo isso scrht realizado dentro ela própria aplic:t~lo, talvez utiliz:mdo os mc•anismos que estudamos na Seção 3.4. O OCCP é utilizado em aplkaçOcs. como o fluxo de mfdia (,·eja Capitulo 7), que podem se aproveitar da escolha entre 'onveni~ncla c confiança do fornecimento de dados, mas que querem ser sensíveis ao congestionamento da rede.

O Protocolo de Controle de Fluxo de Transmissão (SCTP) (RFC 2960. RFC 32861 é um protocolo confi;\vel c orientado " mensagens que permite que diferentes " fluxos~ de aplicaçi\o sejam muhiplexados através de uma uni c-.t conex;lo SCTP (método conhecido como "rmiltlplos fluxos~). De um ponto de \'ÍSta conO:tvel, os diferentes fluxos demro da conex:lo Sllo controlados separadamente, de modo que uma perda de pacote em um fluxo nào afete o fornecimento de dados em o utros fluxos. O SCTP também permite que os dados sejam transftridos por meio de dois percursos de safdól quando um hospedeiro está conectado a duas ou mais redes. fornecimento opc1onal de dados madequados. c mui tos outros recursos. Os algontmos de controle de congestionamento c de fluxo do SCTP s.'o basicameme os mesmos do TCP. O protocolo TRFC ( TCP- Frirrully Ratr Com rol) (RFC 53481 é mais um protocolo de controle de congestionamento do que um protocolo da camada de transporte completo. Ele especifica lllll mecanismo de cormole de congestionamento que pocleri:1 ser utilizado em outro protocolo de transporte como o DCCP (de fato. um d os dois protocolos de aplic:tção disponível no DCCP é o TRfC). O objetivo do TRFC é est:lbilizar o cornportamemo dos wdentcs de serra" (vej ~ Figura 3.54) no comrole de congestionamenlo no TCP, cnquamo mantém uma taxa de envio de longo prazo "razoavelmente" próxima à do TCP. Com umt\ taxa de envio mais estável do q ue a do TCP, o TFRC é adeq uado tis aplie;~çOes muhimidia, como telefonia 11>ou nu xo de mldia, em que uma taxa estável é Importante. O TFRC é um protocolo baseado em cquaç:Io que utili za a tax:\ de perda de pacote ca lculada como suporte a uma equaçllo IPaclhye. 20001 que estima qual seria a vazão do TCP se uma sessão TCP sofrer taxa de perda. Essa taxa é ent:'\o adotada como a taxa-alvo de envio do TRFC. Somente o futuro dirá se o DCCP. o SCTP ou o TRFC possuirá uma implementaç;lo di fu ndid<~. Enquanto esses protocolos fornecem claramente recursos avançados sobre o TCP c o UOP, cstcs j:l provaram a si mesmos ser "bons o bastante" com o passar dos anos. A vitória do • melhor" sobre o "bom o basHtnte" dc1><'ndcrá de uma mis tum complexa de considerações técnicas. sodais e comerciais. No Caphulo I. dissemos que uma rede de computadores pode ser dividida em ·periferia da rede' c 'núcleo da rede'. A periferia d:1 rede abrange tudo o que acontece nos sistemas fina1s. Com o exame da l'amada de aplicação c da cam:1da de transporte. nossa d iscuss:\o sobre a periferia da rede est:t completa t: hora de explorar o núcleo da rede! Essa jornada começa no próximo capítulo, em que est udaremos a l"<

(amado de lron sporle

2.15

Exercícios de fixação Capítulo 3 Questões de revisão numero de port11 do destino y. Qu:us s.lo os nu meros de porta d:t fonte c do destino parn tlS segmentos que 1rafcgam do hospedeiro() para o hospedeiro A?

Se(ões 3.1 o 3.3 1.

Suponha que uma camada de rede forneça o seguinte serviço. A camada de rede no computador-fonte nccit~ um scgmemo de tamanho máxtmo de 1.200 brtcs c um endereço de computador·:• Ivo da c:\ln:tdn de transporte. Esta, cru~o. garante enc~minhar o segmento para a camada de transport e no coml>lltador-alvo. Suponha que mu itos processos de aplicação de rede 1>oss.1m es tar sc11do excetuados no comput:tdor-alvo. a. Crie, da formo mais simples, o protocolo da çamatlo tk transporte possrvel que lcv;u·~ os dados da or>llcaçjo IX'Iril () processo desejado no computador-alvo. Suponha que o sistema \)[)Craci\HI:ll do computador-alvo dctcm1ínou um numero de porta de 4 bytcs para cada processo de aplicac:\o em execucólo.

4.

Desere\·a por que um desenvo lvedor de :tphc:ação pode escolher rodar uma ar>licaÇllo sohre UDP em \ 'CZ de sobre TCP.

S.

Por que o tráfego de voz e de ''idco é frequentemente enviado por meio do UDP c n:\o do TCP n:t lmernet de hoje? (Díect: A rcsposw que pwcuramos n:lo tcrn nenhuma relaçno com o mcl-anismo de coru ro le de congestionamento no TCP.)

6.

É possrvel que umn nplicaç:\o desfrute de trans ferência confiável de dados mesmo quando roda sobre UDP? Caso a resposta seja afirmativa, como isso acontctc?

7.

Suponha que um processo no Computador C possua \lm socket UDP com número de porta 6789 c que 1l Computador ;\ c o Computador B. individualmente, en\lem um segmento UDP ao Computador C com numero de porta de destino 6789. Esses dois segmentos scrlo encaminhados para o mesmo socket no Computador C? Se sim, como o processo no Computador C sabera que esses dois scgmen1os ' 'iemm de dois comJ>tttadorcs diferentes?

8.

Suponha que um servidor da Web seja executado no Computador C na JlOrLa 80. Esse servidor ut iliza concx1ks comfnuas c, no momento, está recebendo solidtaçllcs de dois Computadores diferentes, r\ c B. Tod:~s as sollcitac1'CS estão sendo enviadas através do mesmo sockct no C<,mput:tdtlr C? Se eles cs1ao passando p
b. Modlnquc esse prOlo<:olo de modo que ele fornec-u um •endereço ele rewrno· para o processo-alvo. c. Em seus protocolos, a camada de: transporte •tem de f;~zcr algo· ntl nucleo da rede de c<>m· pUladores? 2.

Considere um planct.t onde todos possuam uma famllia com seis membros, cada famll ia viva em sua pró1>rla casa, cada casa possua um endereço unlco c cada pessoa em certa casa possua um unico nome. S~tt>onha q11c esse planeta possua um servu;o post:tl que entregue cartas da casa-fonte à casa-ah•o. O serviço exige que (i) a carta esteja em um cn,·clopc c <1uc (ii) o endereço da c:lS:I· alvo (c nada mais) esteja escrito claramente no cnve· lopc. Suponha que cada f:tmllia 1wssu:• um membro representante que recebe c dis tribui cartas para outros mcml,ros da famflla. As canas n:lo apresentam necessariamente qua lquer indicacão dos destinatários das cilft:IS. a . Utilizando a solucdo do Problema I como inspirac;ilo, dcscn:v;~ um protocolo que os representantes possam utiliz:~r para entregar canas de um membro remetente de uma família p:1rn um membro destinatário de outra [amllia. b. Em seu protocolo. o serviço postal precisa abrir o envelope c vcrifieo1r a eo1na pam fornecer o scniço?

3.

Con~ldcrc uma conexão TCP entre o hospedeiro A c o hospedeiro 6. Suponha que os segmentos TCP que trafegam do hospedeiro A para o hospedeiro B ten ham número de pona da fonte x e

Seção 3.4 9.

Nos nossos protocolus rd l . por que prccisMnos introduz• r nu meros de SC
10. Nos nossos protocolos rd l . por que precisamos

introduztr tcmp
cmtssor c o receptor seja constante c conhecido p:lra o emissor. Ainda seria ncccssario um tcmpoli:t:tdor no protocolo rd l 3 . O, supondo que os J>.'lCOtcs podem ser perdidos? E~pliquc:. 12. Visite o applct Go-Oack-N Java no Companion si teWeb.


\'3lor corrente de TI meo ut 1nte rva 1 para a conexão ser.t ncccssari:unente ajustado para um \'3lor :t I segundo.

a . A fome enviou cinco pacotes c depois intcrrumpeu a animação antes que qualquer um dos cmco pacotes chclt:lSSCm ao destino. Então, climme o pnmciro Jlacotc c rcinicie a animaç-.lo. Descreva o que acontece.

g. lmagmc que o hospedeiro A envie ao hospedeiro 8. por uma conexão TCP. um segmento com o numero de sequ!'!nc1a 38 c 4 bytes de dados. Ne.~ mesmo segmento, o nümero de reconhecimento ser:\ necessariamente 42.

b. Repila o experimento. mas agora deixe o primeiro pacote chegar ao destino c elimine o primeiro reconhecimento. Descreva n0\'3mcntc o que acorucce. c . Por fim. tente enviar S(!IS pacotes. O que acontece?

15. Suponh:1 que o hc1spedeiro A envie dois segmentos

13. Repita a ques tlo 12, mas agora com o applet Sdecth·e Rrpc·c11 )m•a. O que difere o Sclurh·c Rcpeat do Go·f.lack-N?

TCP um atrás do outro ao hospedeiro n sobre uma conexâo TCP. O primeiro segmento 1em número de seqtt~ncia 90 e o segundo, numero de sequêncla 110.

S~õo 3.5

a . Quantos dados tem o primeiro segmento? h. Stq>onha que o prim eiro sc~ m en t o seja perdi· do, nl:lS o segundo chegue a U. No ro::eo nhcci· mcnw que ll envia n t\, qual será o lllimcro de

H . Vcrtladciru ou ralw: a. O hospedeiro A es tá enviando ao hospedeiro

B um arquivo grande por uma conexão TCP. Suponha que o hospedeiro D nâo tenha dados par~ envi:1r para o hospe
c. Suponha que o hospedeiro A esteja emliando ao hospedeiro 8 um arquivo grande por uma coneX>\0 TCP. O numero de bytes não reconbcç1dos que o hospedeiro A envia não pode exceder o tamanho do buiTer de recepção. d. Imagine que o htlSilCdelro A esteja en,iando :10 hospedeiro ll um :~rquivo grande por uma concxolc• TCP. Se o número de scqu~ncia para um segmento dessa concx;\o ror 111, en1:1o o nt\mcro de scar~ Rwnd. r. Suponha que o último Samp 1 eRTT de uma conex:lo TCr sejll igual " I segundo. Então. o

reconheci mcnto? 16.

c~msidcrc o exemplo do Tdnc1 di~utldo na Seção J.5. Alguns segundos após o usuário digilar a letra ·c. ele digitar;\ a lc1ro 'R'. Depois disso, quamos segmentos scrao enviados c o que ser:\ colocado nos ~mJlOS ele numero de sequencitt c de rcconhccimcnlo dos segmentos?

~õo31 11. Suponha que du:1s conexões TCP estejam presentes

em algum enlace congestionado de velocidade R bps. Ambas as conext)es l~m um arquivo imenso para enviar (na mesma dircç.lo, 1>clo enlace congestionado). As trnnsnHssõc:s dos arquivos comcç.1m exatamente ao mesmo tempo. Qual c:1 velocidade de tmnsmissâo que o TCP gos taria de dar a c.~da um:~ das COIICXt)CS? 18. Verdadeiro ou falso: considere o comrolc de conges-

tionamento no TCP. Quando um 1cmporlz.ador expira no remetente, o "va lor de s s thres h .. c ajust~1do p;\r.t J metade de se u valor anterior.

Problemas l.

Suponha que o cliente t\ micic umascss;\o Telnct com o scrv1dor S. Quase ao mesmo tempo, o cliente B também inic1a uma scss;lo Tdnct com o servidor S. Forneça pos· slvciS nu meros de ll
c. Os segmentos env1ados de S pam A. d. Os segmentos cn,·1ados de S para 8.

a. Os segmentos enviados de A para S.

e. Se A c 8 s.lo hospedeiros dircrentcs, é possíYcl que o numero de porta da fonte nos segmentos de A para S seja o mesmo que nos de B paraS?

b. Os segmentos enviados de B para S.

f.

E se forem o mesmo hospedeiro?


l.

3.

...

Cons1dcre a Figura 3.5. Quais são os valores da pona de fonte c da porta de destino nos segmentos que Ouem do SCI'\'IclOr de volta DOS processos clientes? Quats são os endereços IP nos da1agramas de camada de rede que C3rrc~am os segmentos de camada de tranSJ)()rtc?

a. Suponhn que voe~ tenhn os segt•inlcs b)•tcs: OIOlliOO c 01010110. Qu:-~1 é o complemento de

6.

Considere nosso motivo ,,ara corrig1r o protocolo rtd2 . L Demonstre que o destinatário apresentado na figura 3.57. tJUando em operação com o remetente mostrado n~ Figura 3. 11 . pode levar remetente c destinatário a entrar em estado de tra\·amemo, em que cada um espera por um C:\'Cnto que nunca vai ocorrer.

7.

,> J>rotoco lu rd t3. 0. o~ pacotes ACK que Oucrn do destinatário ;to rcmctcmc n:la t\!m m\mcros de scquCncia (cmbom tenham um campo de ACK que come m o mlmero de scqu~ncb do pacote que cs1 ~o rcconhccc11do). Por que nossos pacotes ACK não requerem numcros de scqu~ncia?

8.

Elabore a FSM J):lra o lado destinatário elo protocolo

rdl3.0. 9.

Elabore um diagrama de mensagens pam

:1 opera~'llo

do protocolo rdt3. Oquando pacotes de dado e de

da soma desses 2 bytcs? b. Suponha que voct tenha os seguintes bytes: 11011010 c 00110110. Qual é o complemento de I da soma desses 2 b)•tcs? c. Pnra tiS bytcs do nem (a). de um exemplo em que um bit c uwcrtido em cada um dos 2 brtcs c, mesmo ass1m. o comple men to de um não muda.

5.

encontre que essa soma coincide com o valor transportado no c:~mpo da soma de venftcacão. O receptor pode estar absolutamente certo de que n:lo ocorreu nen hum erro de hn? Explique.

O UOP c o TCP usam complementos de I para stHIS somas de verificaç~o. St•ponha que vocc tenha as seguintes tr~s palaHas de 8 bits: 01010011. 01010100 c 01110100. Qual é o complemento de I para ltS somas dessas ,,alavras? (Note que, e mbora o UDP c o TCP usem palavms de 16 bits no c:llcultl da soma de vcriflcaç(\tl, ncsse problema solicitamos que voei.' considere somas de 8 bits). Mostre todo o trabalho. Por que o UDP toma o com t>lemcnto de I da soma. isto é, por que nllo toma upcnns u soma? Com o esquema de complement o de I, como 11 destinatário detecta erros? J: possível que um erro de I bit passe despercebido? E um erro de 2 bits?

217


Suponha que o receptor UDP C:llcule a soma de veriftC3çâo da lntcmcl parn o segmento uor recebido c

rcconhccnncmo cstlo tru ncados. Seu diagrama deve ser semelhan te ao US:ldo na Figum 3. 16. 10. Considere um canal que pode perder pacotes, mas cujo atmso má~•mo ~ conhec1do. Modifique o protocolo rdt2 . 1 para mcl111r esgotamento de tcmpori· raç:\o do remetente e retransmissão. Informalmente, argumente por que seu protocolo J){)dc se comunicar de modo correto por esse canal.

rcll_nc< rcvpkl> && notcorrup t
del fver_datdC data)

coepute

cl1k~ u111

mak~_p kt [~~nd p kt.AC K. e hkSUIII )

udt send(sndpk t)

-

~

F

'

Esperar rdl_rcv! rcvpH) U Cco•rupt(rcvrkt)fl

cbOa?IXeO

8

Espera

b1a?IXeO

has_s~ql(rcvp k lll)

CCIIIPI•te chhUdt IN~C!_P i l(Sndr>k t . IIAk , CI'
sndpkt l

"--

./

~

rdt r vcl rcvpkt l M notcornlpl I rcvpktl M ha~_seq I trcvpkt l extrac t (rcvpkt . da t a) dellver_d~ld(dat•l

coapuLe chksu• aa~e_pktlsendpk t . AC~ . chksu•l

ucH seMI snelpktl

Figura 3.57 Um receptor incorreto poro o protocolo rdt 2.1

d

(

•

••

r l rcv rcvp . t 1 •• lco;,.upt!rcvpUII I

11~~-u•qO! rr;vpl.t I))

co11put e chksua aa ke pkt! ~ndpU . NAK . chHulll)

udl

~~ntl( sndpU)

bow4tto4ic~ Redes de tom putod ores e o Inlerne;.;t_ _ _ __ _ _____________ _ _ _ _ __

11. O lado remc1cmc do rd t3. O simplcsmeme ignora (i~lo

c. n:\o

rc;~liz.1

nenhuma ação) todos os pacolcs recebidos que estão errados ou com o valor crrndo no campo acknum de um paco1c de rcconhccmicnlo. Suponha que em 1:us circurJSiâncins o rd t3. Odevesse apenas rccransmHir o pacote de dados corrente. 'esse caso. o prolocolo ainda funcionaria? (Dica: c:unsid· crc o que acontcccna se houvesse :~penas erros de bhs: não há perdas de paco1es, mns podem ocorrer csgoiJmcncos de lcmpori;t;~~o;\o prematuros. lm:tginc quamas 'czcs o cnl'sinw pacote é enviado, no limilc em que n se apro"i mnssc do inl1nito.)

12. Cm1siderc o protocolo rdt3. O. El:~borc um diagrama mostrando que. se a concxtlo de rede cmrc o rcmc1cut e c o <.ICSiin:uMio puder altcmr a ordem de mcusagcns (isw c. se for possfvcl reord enar duas mensagens que se propagam no melo cmre v rcmcccnlc c o tlcs1inaHirio). cnllo () prococolo bic nhern.mte n:lo funcionar.! corrctnmcmc (lembre-~ de ídcmi ficar clammcmc o scmido no qual o prolocolo n:lo funcionar:! corrc t:•mcntc). Seu diagrama deve mosmu o remclcntc à CS<(Uerda e o dcs11nacáno :\ thrclla: o eixo do tempo dc"crá cst:lr orientado de cima para baixo na págma c moscrar a noca de mensagem de dados (D) c de reconhecimento (A). ':lo csque~a de indica r o n úmero de scqu~ncia associado com qualquer segmcmo de dados ou de rcconhccunento. 13. Considere um protocolo de 1ransfcr~ncia confi:h·cl de dados que use somente reconhecimentos neg~t u,·os. Suponha que o remc•cncc envie dados com pouc;~ frcttu~ncia. Um prmocolo que u1iliza somente Nr\Ks seria prefcrf\el a um protocolo que utiliza ACKs? Por qu~? ,\~ora :.u[lonhn que t) rcmctencc len ha uma grnndc qunnud~dc de dados pam enviar c que a concxl\O fi m a fim sofra poucas perdas. Nesse segundo caso, um protocolo que utilize somente Nr\Ks seria prcferfvel o urn pmlocolo que utilize ACKsl t>or que? H . Considere o exemplo em <1uc se almvcssa os Estados

Un idos mostmdo nn Figura 3.17. Que t
chegarem ao rece ptor. O projeto dcss.1 aplicação aumemarin ·' milizaç,\o do cannl? Por que? I I:! poss•vc•s problemas com esse método? Explíquc. 16. No pro1ocolo genérico SR que estudamos na Seç-.lo 3.4.4 , o remetente cransmilc uma mensagem nssim

que ela esc:\ disponlvcl (se ela estiver na janela), sem CSflcrar por um reconhccuncmo. Suponha. agora, que queiramos um protocolo SR que cn,ie dt•as mensagens de cada vez. Isto é, o remcccme enviará um par de mens.'l~:cns. e o par de mcns.1gcn$ subsequcmc somem c deverá ser enviadOSSa perder mensagens, mas q ue ni\o as corromperá nem as reordcnan\. Elabore um protocolo de comrole de erro pan1 a 1r:1nsfer~ncia conOávcl unldí rccíonal de menSajlCllS. Di! uma dcscriç:lo FSM do rcmctencc c do dcscin:uário. Descreva o form:uo dos pacmes enviados ent re o rcmctcmc c o dcstímuárin e vice-versa. Se você usnr qunisqucr procedimentos de chamada que n;\o scj:~m os tia ScçM 3.-1 (po r exemplo, udt_send( ), start_timer( ), rdt_rcv() etc.), csclarcç,, as 3Cl)CS desses procedimcmos. Dê um exemplo (um di'lgr:un.l de mcns:lgcns parn o remetente c para o dcsunatáno) mos1mndo como seu protocolo se recupera ele uma perda de pacote. 17. CmJS•tlerc um cenário em que o hospedeiro A queira

enviar pacotes para os hospedeiros 13 c C simuha· ocamente. O hospedc•ro A csc:l conectado a B c a C por um canal broadcasr - um parocc cnvi:~do por A é levado pelo canal a B c a C. Suponha que o canal brt)atlcasr que concc1a A. 13 c C possa, inclcpendcnlc· mcmc. perder c corrorn1>er mensagens (e assim, por exemplo. uma mcn~•gcm cn"iada de A txxlcria ser rccchída corretamente por 6. mas não (X'lr C). Projete um protocolo de ctmlrolc de erro do 1ipo pare c espere para a 11':111Sfcrl:ncin connávci de urn pacote de A par;• B c pam C, tal
6 qucim m enviar mensagens ao Hospedei ro C. Os hospedeiros A c C cst

dlamc.) Elabore um prmocolo de comrole de erro pare c ~'Spcrc pam tmnsrercncia confi;h·cl de pacotes de t\ c B pam C. com envio alternado em C. como descnto aCIIna. 0(' dcscncõcs FS~I de A c C. (Dica: a FSM p
l9. Consadcrc o protocolv GB:-1 com um tamanh o de janela remetente de 3 c uma raixa de mlmeros de sequcncia de I.OH. Suponha que, no tempo 1. o

(amada de transporte

2.19

b. Com o GBN. é possh•el o remetente receber um ACK paro um pacote que cata fom de sua janela corrente. c. O protocolo bit ahemantc é o mesmo que o protocolo SR com janela do remetente c do desdnat:\rio de t:tmanho I d. O protocolo bit altcrnantc é o mesmo que o protocolo GBN com janela do rcmctc nle e do destinatário de 1arnanho I.

pacote seguin te na orde m, pelo qual o destinatário csu\ CS I>crondo, ten ha um nllmcro de sequc11Cia k. Adnut:l <1m• o meio não rcordcnc as mcns."\gens. Responda às sej.tuintcs perguntas:

23. Dissemos que um apllcaç:lo t>Ode escolh er o UD P pam um protocolo ele transporte pois ele oferece um contrtlle de .tplic:1côcs melhor (dn que o TCP) de quais dados s<1o enviados em um scgment
Qu:~is s;lo os p()ssfvcls cvnjuntos de namc«IS de scquC ncia dentro da janela d tl remetente no tcmr>
a . Por que uma aplicaç;\o possui mais controle de quais dados s~o cnvi:1dos e m um segmento?

a.

b. Q uais s;\o todos os ~1ssivcis v:tlorcs do campo ACK em wdas as mensagens que estilo correntemente se propagando de volta ao rcnuncntc no Lem~l 1? Justifique sua resposta.

20. Suponha ía de cada mensagem D ,\ camada superior: mensagens R podem ser perdidas (nt:b n:\o e(>rrompidas) no can:tl A·>~-6: mensagens (D), uma vez enviadas, s.lo sempre entregues correta men te: o a tmso entre amlx1s ()S canais é desconh ecido c variável. Ela hllrc um r>rOiocolo (d ~ uma descrição FSM) que incorpo re (I~ meca nismos apropriados pm1l compc.:n5.'\r a prope nsão:\ perda do c;tn:tl A a 6 e implemente passagem de mcnsogcm paro a camada s uperior na cmidadc A. corno discutido am es. Ulilize apmas os mec:tnlsmos abs11lutamcntc ncn'SSários. 2 1. Considere os proto.:olos GBN c SR. Suponha que o espaço de nu meros de S«
b. Por que uma :~plicac;;\o possuí mais co ntrole de quando o segmento é enviado? 24. Considere a tro nsferência de um a rquivo enorme de L b)•tes do hos1>edciro A para o hosj)(deiro B.

Suponha um MSS de 536 b)•tcs. a. Qual é o mMmno valor de L tal que não sejam exauridos os nu meros de S«!Uência TCJ>? Lembrese de que o campo de numero de sequtncia TCP tem q uatro hytes. b . Pam o L que obm·er em (a), descubro quanto tempo dcmom para transmitir o arqutvo. t\drnita que um total de 66 b) tes de cabeçalho de trans· porte. de rede e de enl;~ce de dados seja adiciona· do :1 cada segmento antes que o pacote resultan te sep enviado ~lr um enlace de 155 Mbps. Igno re com role ele fluxo c controle de congest ioname nto de modo (JUC A I>OSS.1 enviar os segmentos um mrás do out ro c contin uamcruc. 25. Os hospedeiros A c 13 ~Ido se comumcando por mcao

de uma conexão

Ter. c o hospedeiro B já recebeu

de A todus os bytcs at ~ o bytc 126. Suponha q ue o Hospedeiro A ctwic, e ntão, dois segmentos ptlrn o Hospedeiro O s ucessivamente. O primei ro c o segu ndo segmentos co ntem 70 c 50 b)'tCS de dados, rcsl>CCiivamcruc. No primeiro segmento, o mímcro de scqucncia é 127. o numero de llMt:l de par1ida é 302. c u nu mero de porta de destino é 80. O hospedeiro B Cll\'ia um reconhecimento ao receber um scgmcn t(l do hospcdearo A. a. No l>Cgundo scgmcnlo crwiado do Hospedeiro t\ p.
bow4tto4ic~ 2.20

Redes de computadores e o Internei - - - - - - - - - - - - - - - - - - - - - - - c. Se o segu ndo segmcm o chegar a mes do primeiro, no rcconhccimcmo do primeiro segmento que chegar, qual é o numero do rcconhccimcmo? d. SuJlOnha que dois segmentos e n,•iados por ,\ cheguem em ordem a 13. O primeiro reconhecimento é perdido c o segundo chega após o primeiro imcrvalo do esgotamen to de tcmporiza· ç.lo. Elabore um diagrnmn de tcmporilaçàO, mostrando esses segmentos, c todos os outros. c os reconhecimentos enviados. (t\dmita que nilo haja nenhuma perda de pacote ad tctonal.) Para cada segmento de seu desenho, apresente o numero de scquência c o mimcro de bytes de dados; para cada reconhecimento adicionado IXlr voei!. aprc· sente o numero do rcconhccimcruo.

26. Os hospedeiros t\ c B est:lo
27.
Por q ue t n~ccss:\rlo tiUC o servido r use um m'mcm de scqu~nc ia especial no S'YNACK?

b. Supo nha que um atacante saiba que um hospedeiro-:tlvo utilize SYN cooklcs. O aH1CMte consegue criar c:onexc)Cs semiaberta ou completa· mente abertas simplcsmcmc enviando um pacote r\CK p;.rn o alvo? Por que sun? Por que não? c. Suponha que ~un atacante receba uma grande quantidade de numcros de scqut'ncia enviados pelo servidor. O atacante consegue fazer com que o scn·ídor crie mui tas conexões totalmente aber tas enviando ACKs com esses números de sequ~n cia? Por quH 28. Clmsidcrc a rede mostr:Jdn no Ccnurio 2 na $cç;1c, 3.6.l. Suponha que os hospt."tlciros emissores A c B poss11am

valores de esgotamcmo de teJlll)()rizaç:lo fixos. a . t\nalise o fato de que aumemar o tamanho do

buffer finito do rotc3dor pode possivelmente reduzir a \'lltilo (À,,.). b. Agora suponha que os hospedeiros ajustem dina· micameme seus va lores de csgoramcnto de rem· porizaç;io (como o que o TCP faz:) b;1seado no atraso no buffcr no ro teador. t\u menlar o tama· nh o do buiTcr ajudaria a aumen tar a \•azi\o? Por quê? 29. Considere o procedimento TCP para estimar RTT. Suponha que a = 0,1. Seja Sampl eRTT 1 a amostra

m:~is recente de RTT. Sampl eRTT2 a segui me amostra mais recente de RTT etc.

a . Para uma dada concx<10 TCI'. SliJ)()nha que c1u:1· tro reconhecimentos fomm devolvidos com as amostms R'IT correspondemcs Sa mpl eRTT••

SampleRrT 1, Samp leRTT c SampleRTT 1• Exprc~c EstimatedRTT em termos das quatro amostras RTT. b . Generalize s ua fórmula para n amosw1s de RTTs.

c. P.lr:J a fó rmula em (b). considere n tendendo ao mfinito. Comente pN que esse procedimen to de mMía é denominado média móvel cxponcnci:ll. 30. Na Se~·ão 3.5.3 discutimos cstimntiva de RTT par:J o TCP. N:• s ua opi nião, por que o TCP cvlt:~ medir o Samp I eRT r p01ra segmen tos rctransmltidos? 31. Qual é a relação entre a variáve l SelldBase na Seção 3.5..t c a variável Las tByteRcvd na Scc;lo 3.5.5?

32. Qual é a relação entre a variável Las tBy teRC\'d na Scc:lo 3.5.5 c a variivcl y na scç;to 3.5.·f? 33. N:1 Scç;to 3.5.4 vimos que o TCP espera :u.: receber três ACKs duplicados antes ele rcaltzar uma retrans· missão rápida. Na sua opinilo, por que os projetistas do TCP preferiram não rea lizar uma rctmnsmiss!io rdpida a1>os se r recebido \) rrimciro t\CK duplicado parn um segmen to?

34. Compare c> GB1 • SR c o TCP (sem ACK retardado). Ad mita que os valores do esgorarncmo de temporiz:lc.lo para \lS três protocolos sejam suficicmcmente longos de tal modo q ue cinco segmentos de dados consecuuvos c seus t\Cl
b. Se os valores do esgotamento de tcmponzaç:\o para os três protocolos forem muito maiores do que 5 RTT. cntüo qunl pro tocolo envia co m s ucesso todos os d nco segmentos de dados em um me nor intermlo de rcmpo7 35. Em nossa descrição sobre o TCP na Figura 3.53, n valor do limiar, ssthresh . é definido p;ml ssthresh • cwnd/2 em diversos lugares c o valor ssthresh ê referido como sendo cle!lnido para metade do lama-


g. Qual e o \'ato r de lransmtssilo?

nho da pnela quando ocorreu um evento de perda. A laxa i\ qual o emissor cs1á en\'iando quando ocorreu o C\'CniO de perda deve ser aproximadamente igual a scgmcn1os cwnd por RlT? Explique s ua rcspos1a. Se sua resposta for negativa, você pode sugeri r uma maneira diferente pela qual ss thresh deve ser dcllmdo?

i.

b. Quais os illlef\'31os de 1empo em que a prevenção de conges1iomuncnto do TCP es1á em execução?

c. Após a 16' rodada de trnnsmiss:lo. a perda de segmento será dclectada por Ires ACKs duphca· dos ou I>Or um esg01amento de 1emporização? d. AJ>M a 22• rodada de 1ransmissilo, a perda de segmento scnl delcc1ada por lrês ACKs duplicados o u por um esg01a memo de temporização? c. Qual é o \,tlor inicial de rodnda de transmi~o?

ss thres h na primeiro

f. Qual ê o \•ator llli Caal de SS thres h na 18• rodada de lrans nliss;\(1?

sc ...E

Admnindo-se que uma perda de (>::tcote ser:! dclectada apos a 26' rodada pelo recebimento de 1rê:. r\CKs duplicados. quais serão os valores do 1:un:mho da janela de congcslion:uncmo c de

j.

Suponha que o TCP Talwc seja usado (em "ez do TCP Reno) c q ue 1\CKs duplicados triplos seja m recebidos na 16' s~o. Q u;tis s;lo o s s th r es h c o 1amanho da janela de eongeslitmamcnto na 19' scss;1o7

k

Suponha novamente que o TCI' Tah oc seja usado, c (luc exista um evc nh) de esgotamento de lelllJXIriz:aç;\o na 22• scss:lo. Quantos pacotes foram e twindos da 17' scs~~t' ote a 22•

38. Consuhe a Figurn 3.56. que Ilustra a convcrgencia do nlgori tmo /\IMO do TCP. Suponha que. em vez de uma diminuic~o multiplicaliva, o TCP reduza o 1am:mho da janela de uma quamidade constame. O AIM D res ultante con,·crgiria a um algoritmo de igual companílhamcmo? jusullquc sua r~pos1a usando um diagroma semelhame ao da Figura 3.56. 39.

1a Scç-J.o 3.5.-f discuumos a d uphcaç:'lo do intef\·alo de 1emporizac;ão após um evento de csgotamcnlo de tcmporiz.1ção Es~ mecanismo c uma forma de conlrolc de congcstion:uncmo. Por que o TCP precisa de um mecanismo de con1rolc de congestionamento que utiliza janelas (como esllldado na Sccão 3. 7) além desse mcc.amsmo de duplicação do mtcr\'alo de csgo1amcnw de lctnporizaç;l(t>

45

«>

c o -~

35

OI~

cov .. o ..,c -o"' «>E

GiZ' c~ ~

...

'1:1

o c

.c

...E

{!

2

4

6

8

10 12 14 16 18 20 22 24 26

Rodada de transmissão

Figura 3.58 Tomonho do janela TCP como uma função de tempo

ss thres h na +' rodada de

s s thresh?

3 7. Considtrc a Figura 3.58.

a . Q uais os nllcrvalos de lcmpo em que a partida lema do TCP csUI em execução?

ll1

b, Durnnlc qual rodada de 1rnnsmissJ.o é cm~ado o 70 segmento?

36. Considtre a Figura 3.46(b). Se À' ,. aumentar para mais d(l que R/2, À... poder:\ aumentar pa ra mais do que R/37 Explique. Agora considere a Figura 3.4ó(c). Se À' .. aumentar para mais do que R/2, À.. poder:! aumenta r para mais de R/4 mlmi1indo-se que um p:lcote ser:! 1rnnsmilido du as ''ezcs, em média, do ro1caclor para o dcstinat:lrio? Explique.

Admhi ndtl·Se q ue TCJ> Reno C c1 prt\H1cOit1 que cxpcritnCt1U.\ o cornf>Ortamcnto mostrado no gnlllco. responda às scgulnl cs pcrg1mtas. Em todos os casos você devenl apresenmr uma jus1ifica1iv::t resumida para s ua respos1a.


I

bOWAttOOiC~


~----------------------------.. o.

O hospedeiro A cs1:\ enviando um arquivo enorme ao hospedem' Dpor uma conexao TCP. Nessa concx:lo nunca há perda de pacotes c os temporizadores nunca se esgotam. Seja R bps a 1axa de •ransmissào do enlace que liga o hospcde1ro A a Internet. Suponha que o processo no hospedeiro A consiga enviar dados para seu socke1 TCP a uma 1:1xa de S bps. em que S = 10 • R Suponha ainda que o burrer de rccepçôlo de, TCP seja grande o suficiente para co mer o arquivo Inteiro e que o buffer de em•io poss:t conter somente um por cento tlo arquivo. O que impediria o processo nu hos pedeiro A de p3SS:Ir dados Ctlntinunmcntc JWra seu sockct TCP 11 ta xa de S bps: o com role de fluxo do TCP; o controle de congestiona mento do TCP: o u alguma outra coisa? Elabore sua resposta.

41. Considere c1wiar um arquivo grande de um co m· pu tador a 0111m por me io de uma concx;lo TCr em que n~hl haja l>ercla.

a. Suponha que o TCP utilize AIMD para seu con· trote de conges11onamen1o se m 1,anida lema_ Atlm itimlo q ue CWI'ld aumema I MSS sempre
um pacote é pcrtlido (bem ao nnal do período).

a. Mos1rc que n taxa de perda (fração de pacotes perdidos) é Igual o L - fraçno de

pacot~ perdido~ •

1 3

:.. w2• 8

3

.:...

4

w

b. Use o resultado anterior p:tm mostrar <(liC, se uma conex:lo 1iver taxa de perda l , sua largura de bando média é dada aprox imadamente JlOr:

1.22·MSS

c.

- lm":ti

..3. Considere que scm1er\le uma unic.-. concxâo TCP (Reno) 111iliza um enlace de l O Mbps <1ue não armazena nenhum dado. Suponha que esse enlace seja o único congestionado entre os hospedeiros emissor e receptor. Admila que o emissor TCP tenha um arquivo enorme para enviar ao receptor c o buffcr de reccbimcn10 do reccp1or c muito maior do que a janela de congestionamemo. Também fazemos as seguint es suposições: o tamanho ele cada segmento

TCP é 1.500 bytes: o atraso de propagação bidirccional dessa concx~o c 10 mrlissegundos: c essa conex:\o esc:\ sempre na rase de prcvcnç:\o de con· gesuonamen1o. ou SeJa. •gnore a pantda lenta. a . Qual I! o 1amanho máximo da janela (em

segmentos)
b. Qual to lamanho medi o da pncla (em scgmen· tos) c :1 vaz:\o medi~ (em bps) dessa conexão TC P? c. Quanto tellli)O essa concx~o TCI' leva para alcançar sua janela máxima novamente após se rccupcr~1r da perda tlc um (l:tcolc?

..... Considere o ecnllrio descrito

n~ qucst;lo :Interior. Sup•lnha S possa armazenar um nírmcrn rin ilo de segmcmos. Demonstre que para o enlace sempre enviar dados, tcrlamos que escolher um tamunho de huffcr lor.

..,. Repila a quest:\o 43. rm1s s ubs1huindo o enl ace de

lO Mbps por um de LO Ghps. Observe que em sua '·em que o tam:tnho d:t jancl:t de conges1ionamento leva muiw tempo pa ra atingir seu tamanho mJximo após se recuper3r de uma perda de pac01e. Elabore uma soluç-lo par3 resolver este problema

rcsr>oSI:t no item (c). você

r (medido por RTT) seja o inlcrvalo de tempo qu~: uma concxlo TCP lcv:t p:tra aum~:ntar seu tamanho de J"ncla de congestionamento de \V/2 para W. sendo \V o 1amanho máximo da janela de conges tio name nto. Demonstre que T é uma função d:~ vazão media do TCP.

46. Suponha que

H . Considere um algoritmo AIM D do TCP slmplíficado, :.endo
bytcs. No aumento adittvo, o tamanho da janela de co ngcslimmmen to aumc1tla por um segmen to em cada RTT. No dim inuição muhiplicjHi\ra, o 1amanlw da joncln de congcs1 innamcnto diminui para me tade (se o rcsu llado n:lo for um mlmcro intei ro, arrcdondnr para o numero ín1ciro mais próximo). Suponha que duas co nexões TCP, C, e C1 compartilhem um umco cnl :~cc congestionado co m 30 segmentos por segundo de velocidade. Adrnila que C, e C1 estejam na fase de prcHnção de congcsJionamemo_ GRTT da conex..'lo C 1 c IOOms c o da co nexão C 1 c de 200ms. Suponh:~ que quando a taxa de dados no enlace excede a "elocidadc do enlace. wd.tS as concx(•CS TCP sorrcm Jlertla de segmento de dados. a . Se C, e C1 no tempo t0 possui uma janela de congestionamento d e 10 segmentos. quais são


seus uun:mhos ele janela de congestlonamcmo após 2. 200 milisscgunclos? b.

'o final das comas, essas duas conexões obter.lo a mesma porção da largura de banda do cn lace congcsuonado? Explique.

-t8 . Consadcrc a rede descnta na questão anterior. Agnra su 1)0nh~ que as duas conext'es TCP, c C1 ,

c,

possuam o mesmo RTT de 100 milisscgundos e q ue no 1cmpo t~ o tamanho da janela de congestionamento de C 1 seja 15 segmentos. c que de C, seja lO segmentos.

a. Quais s:\o os tamanhos de suas janelas de congcstlonamenw após 2.200 milissegundos? b. No fina l cl~s eont:ts.

essas duas conexões ir:lo

obter a mesma porc~o da largura de banda do c11h1CC congcstio11:tdn?

c. Dizemos que duas conexões são sincrortizadus se ambas :nlngircm o taman ho má.xímo c mmimo de jnnela ao mesmo tempo. No final das çomas. essas duas conexões serão sincronizadas? 51! sim, quais os tnmanhos máximos de janela? d. Essa smcronização ajudará a melhorar a utilização do enlace compartilhado? Por qui!? Elabore alguma adcia para romper essa sincronização. -t9. Consadcrc uma modaficaçâo ao algoritmo de controle de congcsuonamcnto do TCP. Em \ 'CZ do

aumento adi ti\o, podemos utilizar a diminuição rnultiplicatÍ\•a. Um emissor TCP aumenta seu tam:mho de janela por uma constante positiva pequena (O < a < I) ao receber um ACK válido. Encontre n rel:u;:lo fu ncional en1 re n ta)(a de (>erda L c a jnncln máxima de congestionamento W. Para esse TCP modíncndo, demonstre, independe ntemente da vnz:hl médht TCP, que uma conexão TCP scm1lrc !:t1Sta t1 mesma quantidade de 1cmpo para aumc m ~r seu tam:mho dtl janela de congcs· tiona mcnto de \V/2 para \V. 50. Quando discu timos TCPs futuros na Seção 3.7, obscr· \'Olmos que. !?ara conseguir un1.1 '~•zão de lO Gbps, o TCP apenas f)O(.Ieria tolerar uma probabilíclatlede perda de :.cgmcntos de 2 • IO •~ (ou. cquivalemememe. uma perda p;tra cad:~ 5.000.000.000 segmentos). :-..1os1re a dcm"aclo dos valores para 2 · 10- ~ ou l: 5.000.000 a parur do:. \'Ollores de RTr c do MSS dados na Se\-.io 3.7. Se o TCP prccaSól!>Sc suponar uma concxao de 100 Gbps. qual seria n perda tokrá,·d? 1


:U3

Sl. Quando discutimos controle de congestionamento em TCP na Seç:\o 3.7. admitimos irnplícilamemc que o remetente TCP sempre tinha dados para enviar. Agora considere o caso em que o rcmetCntl: TCP envie uma grande qunntidadc de dados c cnttlo fique ocioso em 11 (já que não há mais dados a enviar). O TCP permanecerá ocioso por um pcrludu de tempo rclattvamcnte longo c ent ilo irá querer envinr mais dados em I r Quais são ns vantagens c dcs\'nntagens do TCP utilizar os valcnes c wnd c s s th r es h de 11 quando com cear a cnvhu dados em t/ Que ~ h crlll\tlva voei! recomendar-i:~?

Por qui!? 52. Neste problema, vcrirlcamos se o UDP ou o TCP :~prcsentarn mn ~rau de autenticação do ponto de

chegada.

a. Considere um servidor que recebe u 111" solíci· taçi\c) de nt ro de um p:IC:(ltc UDP ~ responde a essa solic:uac.lo dentro de um p:tcotc UDP (por exemplo. corno feito por um servidor DNS). Se um cliente com endereço lP X o cngan:t com o cndcreco Y. paro onde o servador envi:~rá sua fCS(lOSI:.l?

b . Suponha <1ue um :.crvidor receba um SYN de cndercco-fonte IP Y com o numero de rcçonhc· camento correto. Admitindo que o scn·idor escolha um numero de scquO:alt;aa aleatorao c que n:lu haja um · moiJ-in·tiH:·midcllr·. o servi· dor pode ter certeza de que o chentc realmente está em Y (c n;\o em outro endereço X que esta cngiln:tndu Y)7

53. Neste problema. consideramos o atraso npresen· tado pela fase de p;trtida lcntn do TCP. Considere um cliente e u1n servidor dn Web diretamen te conectados por um enlace de tuxa R. Suponha que o dkntc queira rcs1a urar um objeto cujo t:unanho seja cxutamentc lgnal u I S S. ~e n do S o tamanho mi.\xlmo do segmento (MSS). Considere RTT como o tempo de vlugem de Ida e volt:• entre o clícnte c o scr,•ldM (ad mltmdo <(UC seja eonstant~) . Ignorando os cabeçalhos do protocolo. determine o tempo para restaurar o ubjeto (incluindo o estabelecimento da conexão TCP) quando a . 4 SIR > SIR + RIT > 25/R

b . SIR + RIT > -i SIR

c. SIR

>

RIT


~-------------------------------

Questões dissertativas 1.

O que c sequestro de TCP' Como ele pode ser n.-a· lil:ado?

2.

Na Scç.lo 3 7. observamos que um cliente-servidor pode criar muilas conexões paralelas ·de modo injusto" O que pode ser feito para tomar a Internet vcrcladciramcnle justa?

3.

4.

Consulte a li tcmtum de pesquisa para s;~bcr o que quer dizer TCP cu11igdvd. Leia lambem a cntrc,,ista de Snll}' Floyd :w final UI!!! te c:lpftulo. Rcdijn uma J~ginn dcscrevcnci') a carac ter rstlc., mnigclvfl do TCP. Ao final do Seção 3.7. 1, discutimos o raiO de uma aplicaç:1o querer abrir várias conexões TCP c obter unm vazllo mais alta (ou. o que c equ i,·alente. um tempo menor de t ransfer~ncia de dados). O que .tconteeeria se todas as apllcaç,)eS temasscm mdho· rar seus desempenhos utllízando conexões mullli?las? Cite alguma:. das dificuldades ~:nvolvidas nn utilitaç.'lo de um elemento da rede pam determinar

se uma apllcaç;lo está ou n:lo uS<~ndo conexões TCP m ultiplas.

5.

Ah:m da varredura de portas TCP c UDP. o nmap possm qual funcionalidade 7 C'lpturc traços de pacote com o Ethercal (ou qualquer outro analisador de pacote) das trocas de pacote nmnp. Utilize as trilhas paro explícar como funcionam alguns recursos :~vnnçados.

6.

Em ntlSS:I dcscric,";)o sobre o TCP nn Figura 3.53, o \'lllor inicial de cwnd ~ ddlnido pam I. Consulte a lilcrntl tra de pesquisa c uma RFC da lntcrncl c dis· cu ta mél()(los alternativos que forJm propostos pMa dennir o valor inicial de cwnd.

7.

Consulte a lhcmtura a rcSJ}Cito do SCTP IRFC 2960, RFC 328()1. Paro <1uals :.pllcaçt)cs os cri:1do res do SCTP consldemm-M ser usado? Quais recursos do SCTP roram ;~dicionados para atender :\s necessidades dessas aplicaçt\cs?

Tarefas de programação Ortalhrs wmpktllS elas tcurjc1s e/r programacão pt'
Implementando um protocolo de transporte confiável Nesta tarda de progmmaçâo de laboratório, voe~ escreverá o código p."lm a camada ele tmnspone do remetente c do dcsunatârio no caso da implcmemaçâo de um prowcolo st ml>lcs de r ransrcr~ncin confiavel de dados. liá duas vcrs,\cs deste laboratório: a do pro10colo de bit nhcman tc c a do GBN. Essa tarefa ser:! muito di\•enidn, já <1ue a s ua i mpl cmc ntaç~o nilo será muito tlirercnte da que seria cx i ~ldn em urna situaçno real. Corno você pr
rornccida ~ suas rounas - isto é, o código que chamaria suas cnudades de cima (da cnmnda 5) c de baixo (da camada 3) - é muito próxuna ao que é feito em um ambiente UN IX real (Na \'crdade, as interfaces do software descritas nesta tarefa de progmmação s.'lo muito mais realistas do que os remetentes c dcstinat:lrlos de l u~o infinito descritos em muitos livros.)'' pamda e o acioM· tncnto d(lS tcmporiz:~dorcs u.unbém Silo si mulados, c as imcrrupçc,cs do temporizador far~o com que sua rotin a de tmmmcnm de tcmpuriznç;\o sej:1 :\IIV11d:l. A tarefa completa de lahoratórin, as.-;im como o código necessário pam compilar seu próprio código, estão disp,>nfvcis no sile: hllp:l/w\\ w.aw.com/kumse_hr.

Wireshork Lab: Explorando oTCP Neste IJboratório, você \tsar:l seu browscr \Vçb pMa acCSS<~r um arquivo de um servidor Wcb. Como nos Wircshark Labs anteriores. ,•ocê US3ra Wircshark para capturar os pacotes que estão chega ndo ao seu computa• dor. Mas, diferentemente daqueles laboratórios, também

poder:! dl.'SCarrcgar do mesmo servidor Web do qual descarregou o arquivo. um relatório de mcns.'lgcns (trncc) que pode ser lido pelo Wircshark. Nesse rclutório de mcn· sagcns do servídor, voe~ encontrar:! os pacotes que foram gerados pelo seu próprio acesso ao servido r Web. Você


analisará os dlagmmas dos lados do clicmc c do servidor de mud
(omo da de lronsporh

llS

retransmiss.lo. de controle de nuxo c de controle de congestionamento c do tempo de ida c volta estimado. Como acontece com todos os Wircshark labs. a descrição completa deste pode ser cncomrada, em inglês,

OI)

sitc h ttp: //1-1WW. aw. com/ kurose_br.

Wireshork Lob: explorando oUDP Neste pequeno l:•born tMio, voce realizará uma capltlrn de pacutc c urna an:llisc de sua palicaçllo favorita que m iliza o UOP (por exemplo. u DNS o u uma nplicaç;lo muhimfdia. como <, Sk)•J>c). C
voce examinará os campos d<, calx:çalho no se~menw UOP, assim cumo o cálculo d:~ so ma de veriOCJçllo. Como acontece com todos os Wircshark Lahs. a descrição completa deste pode ser enco ntrada. crn ínglcs, no sltc ht tp: //\~w~1. aw. com/ kurose_br.

bow4tto4ic~

Solly Flo~d Soliy Floyd é cientisto-pesquisodoro no ICSI Center for Internet Reseorch, um instituto dedicado o questões do Internet e de redes. Elo é conhecido no selo: por seu l robol~o em projetos de protocolos de Internet, em especial nos óreos de mulhcosl conllóvcl. controle de congestiooomento (TCP), escolonomenlo de pocotcs (RED) e O!lólise de protocolos Solly é boc;horel em Sociologto pelo Universrdode do Colrfo,nio em Berkeley, e mestre e doutoro em c;iônc;io do computação por essa mesmo universidade.

Como você decidiu estudar ciên
Qual foi HU primeiro emprego no setor de computação? O que implicava? Meu primeiro emprego na ârea d e computação [oi na BART, ond e trabalhe i d e l975 a 1982 com os computadores que: co ntrola,-am os trens. Comecei co mo Lécnic",l em manutenção c conserto dos v:\rios sistemas distribuídos de comput:tdorcs envolvidos na operaç-Jo do sistema da BART. Entre esses sistemas cst.'lvam: um sistema central de comp utadores c um sistema distribuído de minicompumdorcs, q ue controlavam a movimentação dos trens; um sistem:J de computado res da DEC, que exibia avisos c destinos de trens nos paméis, c u m sistema d e computadores Modcomp, que coleta\":\ informações das bilheterias. Meus ulumos an os na BART foram dedicados a um proj eto conj unto BARTILBL para estruturar um ststcma substi tuto para o sistema de computado res de con trole de trens da BART, q ue Jd esta,•a fiC'a ndo ultrapass:~do.

226

bow4tto4ic~ Quol porte de seu trabolho lhe apresenta mais desafios? A pesquisa é a p.1rtc mais desafiadora. O primeiro tópico de pesquisa inclui explorar as questões rdercntes ao controle de congestionamento para aplicações, como o fluxo de mídia. Um segundo tópico é abordar obstáculos da rede para uma comunicaç.lo mais explícita entre os roteadores c os nós finais. Esses obstáculos podem incluir tl\neis IP c caminhos MPL.S. rotc-.ldorcs ou dispositivos intcnncdiãrios que soltam os pacotes contendo opções IP, redes complexas da camada 2 e potencmis para ataques na rede. Um terccaro tópico cxastcntc é explorar como nossa escolha de modelos de cenários para uso em análise. simulação c experimentos afeta nOSSl a,·aliaç.\o do desempenho dos mccamsmos de controle de congestionamento. Mais infonnaçOcs sobre esses assuntos podem ser encontradas nas páginas \1\leb do DCCP, Quick-Sum c TMRG em hnp://www.icir.orgtfloyd. Em suo opinião, qual é o futuro das redes e da Internet? Uma possibilidade é que o congestionamento tfpico encontrado pelo tr.ífcgo da Internet se torne menos severo à medida q ue a largura de lxmda disponívd aumentar mais mpidamcnte do que a demanda. Considero q ue a tendt ncia está se dtrigindo para um congestionamemo menos intenso, embora não pareça de todo impossrvel comcmphar um futuro de c:rcsçentc congcs tio n:-amemo, a médio pmzo. pontuado por colapso o~-asiona l. O futuro do Internet em si o u da arquitetura da Internet ai nda náo está cl:aro para mim. Há mui1os fatores que estilo contribuindo para rápidas mudanças. Portanto, é difíci l predizer como a lntc mcl o u a arq ui tetura da In ternet evoluirão ou mesmo prever o grau de sucesso que essa evolurâo scr:l capuz de alcançar n;1 pre,·ençõlo das mui Las armadilhas rxnenciais ao longo do caminho. Uma tcnd~ncia negativa bem conhecida é a dificuldade crescente de realizar mudanças na arquitetura da Internet, que m\o é mais um conjunlo coerente, c os vários componentes como protocolos de 1ranspon c, mecanismos do rote<~dor, nrcwalls. b;llancc;~dores de carga. mecanismos de segurança c seus semelhantes àS vezes trabalham com ObJetivos contrários. Quais pessoas a inspiraram profissionalmente? Richard Karp. o ortelllador de minha tese, me ensinou a razer. de rato. pesquisa. Vt1n jllcobson, meu "chere de grupo· no LBL. fot o responsável pelo meu mLeresse no estudo de redes c por grande parte do meu :-aprendazado l>Obre a infraestrutura da Internet. Davc Clark me inspirou por sua visão clllra dt1 arquitctur:-a da lnlernet c por seu papel no desenvolvimento dessa arquitetura por meio de pesquisa. de ::artigos c da participação na IETF e em outros fóruns publlcos. Dcborah Eslfín me inspirou com sua cllpacidadc de concentraç-Jo e efellvidadc, e sua habilidade em 1omar decisões lúcidas sobre o que investigar e por qu~. Uma das razOes por que apreciei trab•dhar na pesquisa de rede f que encontrei nesse campo muitas pessoas de que gosto, a quem respeito c admiro. São pessoas inteligentes, batalhadoras c que estão profundllmentc compromcLidas com o desenvolvimento da lnterneL, divergem (o u concordam) ele modo amigável e slo bons companheiros p
bow4tto4ic~

Acamada de rede

imos no capflulo anterior que a camada de transporte pro,•e v~lrias form:IS de comunicação processo a processo com base no serviço de comunicação hospedeiro a hospedeiro da camada de rede. Vimos também que a t."::mada de transporte faz isso sem saber como a camada de rede nnplementa esse serviço. Ponanto, é bem possível que agora voe~ ~teja imaginando o que está por baixo do serviço de comunicaçM hospedeiro a hospedeiro: o que o faz runclon:lr.

V

Neste capitulo estudaremos exatamente como a camada de rede implementa o serviço de comunil"açào hospedeiro a hospcde1ro. Veremos que há um pedaço da camada de rede em cada um dos hospedeiros e roteadores na rede, o que nào acontece com a camada de transporte. Por causa disso, os protocolos de camada de rede csuio emre os mais dcsaOadorcs (c. portanto. os mais intercssan t~!) da pilha de protocolos. A camada de rede é, também , uma das camadas mais complexas da pilha de protocolos e, assim. temos um longo caminho a percorrer. Iniciaremos nosso estudo com uma visão geral da camada de rede c dos ser,riços que ela pode prover. Em seguida, examinaremos novamente as duas abordagens da estruturação ela entrega de paco· t~ de c:.uuad01 de rede- o modelo de datagr:unas e o modelo de circuitos virtuais- que vimos pela primeira vez no Caprtulo I c veremos o papel fundamental que o endere~"::mcnto d~empenha na entrega de um pacote a se u hospedeiro de dc-sti no. Faremos. n~te capítulo. uma distinção importante entre as funçõ~ de repasse c roteamento da camada de rede. Repasse envolve a transferl!ncia de um pacote de um enlace de cnt rad:t para um enlace de salda dentro de um 1lnico rote:1dor. Roteamento envolve lodos os roteadores de um01 rede, cujas in terações coletivas por meio do protocolo cle roteamento determinam os caminhos que os pacote~ percorrem em suas viagens elo nó de origem ao nó de d~tino. Essa ser:l um:1 elistinçilo importante para manter em men te ao ler este capítulo. Pam aprofundar nosso conhccuncnto do repasse de pacotes, cxanun01rc mos o "interior" de um rote:tdor- a organizai;i'o c a arquitetura de seu hardware. Então. examinaremos o rep:ISSC de pacot~ na Internet. juntamente com o famoso Protocolo da Internet (IP). Investigaremos o endereçamento na ('limada de rede c o formato de daUlgmma IP,•.f Em seguida, eswdaremos a traduç-Jo de endereço de rede (ue1worl1 tuldn·s~ trtm~lcrtlo11- NA T), a fragmentação de datagrama, o Protocolo de Mensagem de Controle da Internet (lntcmet Control Ylt'sscrge Protocol- ICMP) c 1Pv6. Então voltaremos nossa atenção à função de roteamento da camada de rede. Veremos que o trabalho de um algoritmo de roteamento é dctcm1inar bons caminhos (ou rOlas) entre remetentes c destinatários. Em primeiro lugar, estudaremos a teoria de algoritmos de roteamento concentrando nossa atenção nas duas classes de algo· ritmos mais predominantes: algoritmos de estado de enlace c de vetor de distâncias. Visto que a complexidade

bow4tto4ic~ Capítulo •

A u11oda de rede

ll9

dos algoritmos de roteamento aument;t considcr.tvelmcntc com o aumcmo do número de roteadores na rede. tarnb~m será interessante abordar o roteamento hierárquico. Em seguíd;t veremos como a teoria é posta ern prática q uando falannos sobre os protocolos de roteamento de intrassístcmas autônomos da Internet (RIP, OSPF c IS-15) c seu protocolo de roteamento de imersistemas autônomos. o BGP. Encerraremos este capnulo com uma discuss;lo sobre roteamcmo brOtldCCI~t e rnultitast. I:m resumo, este c-.tphulo temtr~ partes importantes. A primeiro, scçoes 4. 1 e 4 .2, aborda funçoes c serviços de camada de rede. A segunda, seções 4.3 c 4.4. examina o repasse. Finalmente, a terceira pane. seções 4.5 a 4.7, estuda roteamento.

4.1

Introdução

A F1gum 4. 1 mostra uma rede simples com dois hospedeiros. Hl c H2, c diversos roteadores no camin ho entre H I c H2. Suponha que Hl esteja enviando informações a H2 c considere o p;1pcl d~t c;unada de red e nesses hospedeiros c nos roteadores intervenientes. A camada de rede em Hl pegará segmentos da camada. de transporte em 11 1, encapsulará cada segmento em um datagrama (isto &:, em um pacote de camada de rede) c cm:\o dará imc:io à jornada dos daragrarnas até seu desti no, isto é, enviará os dmagra mas para seu roteador vizin ho, RI. No hospedeiro receptor (ll2), :~camada de rede receber:\ os datagrarnas de seu ro teador vizinho R2, extrair:\ os segmentos de cumada de tr;msportc c os cntregaro à camada de transporte em H2. O papel primordial dos roteadores é repassar datagramas de enlaces de emrad:t para enlaces de sarda. Note que os rote.tdorcs ela Figura 4.1 s.-lo mostrados com a pilha de protocolos mmcada, isto é. sem as camadas superiores acima da camada de rede, porque (exceto para finalidades de controle) roteadores m\o rodam protocolos de camada de tronsporte e de aplicaç-,\o como os que examinamos nos capítulos 2 c 3.

4.1.1

Repasse e roteamento

Assim, o papel da camada de rede é aparemememe simples - tranSJ>Orlar pacotes de um hospedeiro remetente a um hospede1ro d estinatário. Para ra:zt-lo. duas importantes runçõcs da camada de rede podem ser identificadas: Quando um pacote chega ao enlace de entrada de um roteador. este deve conduzi-lo até o enlace de sarda apropriado. Por exemplo, um pacote proveniente do hospedeiro H I que chega ao roteador Rl deve ser repassado ao roteador seguinte por um caminho at~ 112. Na Scç:\o -f.3 c.-:aminarcmos o interior de um roteador c lnvesLigaremos como um pacote é realmemc repassado de um enlace de entrada de um roteador nté urn enlace de saída.

Rt[JliSSC'.

Rotclwtcuto. A camada de rede dc,•c determinar a rota ou caminho tom:tdo pelos pacotes ao flu lrem de um rcmctCIIIC a um destin:tt:\rio. Os algoritmos que calculam esses c:tminhos s:lo dcnomln~tdos algoritmos de roteamento. Um algoritmo de roteamento detcrminari:~, por exemplo, o caminho ao longo do qua l os pacotes nuiriam ele Hl paro Hl. Os termos retJa.uc c roteamento são usados indistintamente por autores que discutem a camada de rede. Neste livro, usaremos esses termos com maior exatidão. Repasse refere-se à a(·ào local realizada por um roteador paro transferir um pacote da interface de um enlace de cnar.tda para a interface de enlace de sarda apropriada. Roteamento refere-se no processo de âmbito geral da rede que determina os caminhos fim a IIm que os pacotes percorrem desde a fonte até o destino. Para usar uma viagem como analogia, voltemos àquele nosso viajante da Seçlo 1.3.2, que \":\I da Pcnsih·lnia à Flórida. Durante a ''iagem, nosso motorista passa por muitos cruzamentos de rodO\' taS em sua rota até a Florida. Podemos imaginar o repasse como o processo de passar por um tlnico cruzamento: um carro chega ao cruzamento vmdo de urna rodovia c determina qual rodovm ele deve pegar para sair do cruzamento. Podemos imaginar o rotcamcnto como o processo de planejamento da viagem da Pcnsilvânia até a Flónda: antes de partir, o motorista consultou um mapa c escolheu um dos muitos caminhos possivcis. Cada um desses <:aminhos consiste em uma série de trechos de rodovias conectados por cruzamentos.


Rede móvel

Enlace Sistema final H 1 Aplicaçllo Transporte Red e Enlace Flslco

Enlace Enlace Flsico

Transporte Rede Enlace Rede corporativa

Figura 4.1

flslco

Acomodo de rede

Cada roteador tem um:~ tabela de rc:passc. Um roteador repassa um pacote examinando o valor de um campo no <.·abcçalho do pacote que está chegando e então utiliza esse valor para indclmr sua tabela de rep.1ssc. O resultado da ~:~bela de repasse indictl para qual das imerfaces de en lace do roteador o pacote deve ser repassado. Dependendo do protOcolo de ctlmada de rede, esse valor no cabeçalho do pacote pode ser o endereço de destino do pacote ou uma indicação d:1 conexão à qual ele pertence. A figura 4.2 dá um exemplo. ' a Figura 4 .2, um pacote cujo valor no campo de cabeçalho é 0111 chega a um roteador. O roteador o índexa em sua tabela de repasse, dett!rmina que a imerfacc de enlace de s.~fda para esse pacote é a hnerfaet! 2 e, cnt:'io, repassa o pacote mtemamentc à interface 2. Na Scçlo 4.3 examinaremos o íntenor de um roteador c estudaremos a funç,lo de repasse multo mais dctalhadamentc. Agora voct deve estar imaginando como são configuradas as tabelas de repasse nos roteadores. Essa é uma

qucstllo crucial, que expõe a imponamc interação cmrc rotcamcmo c repasse. Como ilustrado na Figura 4.2, o algoritmo de roteamento determina os valores que são inseridos nas tabelas de repasse dos roteadores.


A uruda de rede

Algoritmo d4! roteamento

~ Tabela de repasse local valor do c~alllo

~la~ de~~

0100 3 0101 2 0111 2 1001 1

~/ Valor no cabeçalllo do pacote que está chegando

\

@ill]-

figura 4.2 AlgOOtmos de roteamento determinom valores em tobelos de reposse O algoritmo de roteamemo pode ser centralizado (por c.xemplo, com um algoriuno que roda em um local central c descarrega infonnações de roteamento a cada um dos roteadores) o u descentralizado ( ts to é. com um jXdaço do algontmo de roteamento distri bufdo runcionando em cada roteador). Em qualquer dos casos, um roteador recebe mcns:~gcns de protocolo d e roteamento que São utiliZ:Idas para configurar sua ubela de repasse. As finalld:~des distintas c diferentes das funções de repasse c roteamento podem ser mais bem esclarecidas considerando o caso hipotético (c nilo realista, mas tecnicamente viável) de uma rede na qual todas as tabelas de repasse s:io configu· rodas diretamente por opemdorcs de rede humanos, fisicamente prcsemes nos roteadores. Nesse caso. não seria precrso nrnhunr protocolo de rote:~mento! Ê claro que os operadores humanos precisariam mteragir uns com os outros para g:mmtir que as tabelas fo~m config1tradM de tal modo que os pacotes chegassem a seus destinos pretendidos. Também ~ provável que uma configuraç•lo human:1 seria mais propcns.t a erro c muito mais lcm:1 do que um protocolo de ro teamento para reagir a mudanç:ts na topologia da rede. Portan to , sorte nossa que todas as redes 1em uma função de rcp-.1sse e tcr111"1'111 uma fun\""tl.o d e roteamento!

Er1qu:uuo estamos no tópico da terminologia, é interessante mcncion;tr dois ou tros termos que também sào utilizados indistintttmentc. mas que us.trcrnos com maior cuid:tdo. Reservaremos o termo CVIIIIIICiclo• clr pacotes pam designar um dispositivo gemi de <.'Omutaçào de pacotes que transfere um p:~cotc de interface de enlace de cntracl
bow4tto4ic~ Redes de co11pu todores e o

ln;.;l~ e ;.;rn;.;e;.;.t_________________________

Estabelecimento de
4.1.2 Modelos de servi~o de rede Antes de examinar a camada ele rede, vamos tomar uma perspectiva mais ampla c conside ra r os d ircr·entcs tipos de servi\'O que poderiam ser oferecidos pela camada de rede. Quando a camada de tr-.msporte em um hospedeiro remetente transmite um pacote para dentro da rede (isto ~. passa o pacote p:tra n cam:tda de rede do hospedeiro remetente), ela pode contar com a camada de rede para entregar o pacote no destino? Quando s.io enviados ,~.írios pacotes. eles scr:lo entregues à camada de tmnsportc no hospedeiro destina tário na ordem em que foram cn"iados? A quamlcladc de tempo decorrido entre duas tra nsmissões de pacotes scqucnciais sem a mesma

quanudndc de tempo decorrido entre suas recepções? A rede fornecerá algum tipo de mrormação sobre congestionamcruo na rede? Qual é o modelo (propriedades) absrrato do can:~l que conceta a camada de transponc nos hospedeiros remetente c destln;ll:\rio? As respostaS a essas c a outras pergunt<\S s:lo determinadas pelo modelo de servu;o oferccrdo pela camada de rede. O moddo de serviço de rede dennc as t-aractcrrstícas do transporte de dados fim a fim entre uma borda da rede e a o utra. isto é . entre sis temas finais remetente c destinatário. Vamos considerar agora alguns serviços possíveis que a camada de rede poderia prover. Quando a camada de transporte em um hospedeiro remetente passa um pacote para a camada de rede. alguns serviços espcciOcos que poderiam ser oferecidos pela camada de rede são:

Entrega garcmtida. Esse sel"\-iço assegura que o pacote mais cedo ou mais tarde cheg:trá :1 seu destino. Eutrcgct gc.rcurticla com atrnso lfruít(l(lo. Esse serviço não somente assegura a entrega de um pacote, mas também a entrega com um atraso hospedeiro a hospedeiro limitado c especificado (por exemplo, dentro de 100 rnilissegundos). Além disso, há outros serviços que podem ser providos a um fluxo tlc 1mcote$ entre urnt\ fonte c um destino determinados, como os seguintes: En rrrga de pa(otes na ordem. EsLe serviço foram en viados.

g<~ra nte

que

p<~cotcs

chegarilo ao destino

11:1

o•·dcm em q lte

Largura tlc banda mfrrima gamrrtida. Esse serviço de camada de rede emula o comportamento de um enl:tce de tr:~nsmissâo com uma taxa de bits c.'Spccificada (por exemplo. I Mbps) entre hospedeiros remetentes e dcstinmários (mesmo que o caminho Om a fim real passe por vários cnl;~ees físicos). Contanto que o hospedeiro remetente transmita bitS (corno pane de pacotes) a urna taxa abaixo da wxa de bits especificada. nenhum pacote scn1 perdido c cada um chegar:\ dentro de um atr-JSo hospedeiro a hospedeiro previamente especificado (por e."\:emplo, dentro de 40 milissegundos). )irtct nrctximo gmmrticlo. Este scl"\·iço garante que a quantidade de tempo entre a tr-ansmissão de dois pacotes sucessrvos no remetente seja rgual à q uantrdadc de tempo entre o recebimento dos dors pacotes no destino (ou que esse espaçamento não mude mais do que algum \'alor especificado). Suviços de stgrmuu;a. Utilizando u ma cha\•c de scssi\o secreta conhecida somente por um computador· fonte e um computador-alvo, a camada de rede no computador-fonte pod e codificar a carga útil de todos os datagramas que estão sendo enviados ao compu tador-alvo. A camada de rede no computador-


A u11oda de rede

233

-alvo, cm~\o, seria rcspons:\vcl por decodificar as cargas úteis. Com esse ser\'iço, o sigilo seria fornecido para todos os segmentos da c-.tmada de transponc (TCP c UDP) entre os computadores-fome e os computadores-alvo. Além do sigilo, a t-amada de red e podena prover imcgndadc dos dados c serviços de autcntkaç-Jo de fonte. Essa é uma lista apenas parcial de serviços que uma camada de rede pode prover- há incontáveis variações possíveis. A camada de rede da In ternet fornece um único modelo de scr..-iço, conhecrdo como s~rvi ço de mdhor esforço. Consultando a Tabela 4 .1, pode parecer que serviço de melhor esforço seja um cufemrsmo para absolutamcurc uculrum serviço. Com o serviço de melhor esforço. não há garantia de que a temporização entre pacotes seja preservada. nao há g:u'3ntia de que os pacotes sejam recebidos na ordem em que formn enviados<' nao há garantia da entrega final dos pacotes transmitidos. Dada essa definição, uma rede que não entregasse 11cnhwn paco te ao dcs tin:u:.lrio satisfttria a defini('t10 de ser,•iço de entrega de melhor esforço. Contudo, como discutiremos adiante, há rnzoes sólidas para esse modelo m inimalista de scn•iço de camada de rede. Exammaremos outros modelos de serviço de In tern et ainda e m evo lu~':lO no Capítulo 7. Outras arquitcurras de rede definiram e implcmenwam modelos de serviço q111~ vão além do serviço de melhor lmernrt. Por exemplo. a arquitetura de rede t\ TM [MFI\ For um 2009: Black. 19951habilita ' 'ários modelos de ser,•iço, o q ur significa q ue. dcmro da mesma rede, podem ser oferecidas conexões clifcrcmcs com classes de serviço diferentes. Discutir o modo como um~• rede ATM prove esses serviços vai muito além do escopo deste livro: nossa meta aqui é apenas s.11icntar que existem alternativas ao modelo de melhor esforço ela lmernct. Dois elos modelos m;~is importantes de serviço ATM são os sen•iços de taxa constante e de taxa diSponível. csror~o da

Stn·íço tle mlr tlr taxa constanu de bits (constam bit ratc- CIJR). Esse roi o primeiro modelo de serviço ATM a ser padronizado, refletindo o interesse imediato das empresas de telefonia por esse seniço e a adequabilidade do scnriço CBR para transmitir trMego de áudio e vídeo de taxa constante de bits. O objeuvo do servrço CBR é conceitualmente simples: prover um fluxo de pacotes (conhecidos como células n;~ ternunologia ATM) com uma tubulaçào virtual cujas propriedades s:\o igu;us às de um hipotético enlace de transmissão ded icado de largura de b:mda fixa entre os hospedeiros remetente e destinatário. Com serviço CBR, um fluxo de células ATM é carregado através da rede de modo tal que garanta que o atrnso fim a fim de uma célula, a variabilidade desse atraso (Isto é, o Jillrr) c a fra\
Arquitetura da rede

Modelo de serviso

Garaatia de largura de banda

Garantio contra perda

Ordenamento

Temporiz~õo

lndica~ão de congestionamento

lnlemet

Meltloc esfor,o

NeMiml

NedMoo

Nõo montido

Nenhwo

A1M

CBR

loxo constonle goumlo

Sin

fMliQue1 ordem possível No ordem

Montilo

Nõo ocooe!Õ c~lio-

A1M

ABR

Miliroo goromm

Hem~m~

No ordem

Hõo mantido

Tabela 4.1 Modelos de serviço das redes Internet, ATM CBR eATM ABR

nomen.to lrdcoçõo de c~esliommento

bow4tto4ic~ Redes de tom pu tod ores e o Interne~1------------------------Além disso, como vimos na Scç;\o 3.6, o serviço ATM ABR pode prover rcalimeruaç:io ao remetente (em termos de um bit de notHic.1ção de congestionamento ou de uma taxa de en\'iO expllcita), que controla o modo como o remetente ajusta sua taxa entre a ~CR e u ma taxa de pico ad missí"el.

4.2 Redes de circuitos virtuais e de datogromos Lembre-se de que. no Caphulo 3, d issemos que a camada de transporte pode oferecer :\5 aplicações serviço não orientado para conexão ou serviço orientado para conexão. Por exemplo, a camada de transporte da huerneL oferece a cada aplicação uma alternativa entre dois serviços: UDP, um servrço não orientado para conexão; ou TCP, um serviço orientado para conexão. De modo semelhante, uma camada de rede rambém pode oferecer qualquer
para concxi\o, ou um serviço entre hospedeiros orient:tdo p.1m conexão. mas ni\o ambos. Redes de computadores que oferecem apenas um scn·iço orientado paro eoncxJo na rnnmda de rede são dcnonti· nadas redes d e circ uitos virtuais (n~des CY); redes de computadores que oferecem apenas um senriço não orientado 1>ara conc.xõo na camada de rede s.-lo denominadas red es de datagramas. As nnplemcn1açõcs de serviço orientado para conexão na camada de transporte c de SCJ'\1ço de conexão na camada de rede são funda mentalmente diferentes. No capítulo anterior vimos que o sel'\'Íço de camada de transporte orientado para eonexrlo é 1mplementado na borda da rede nos srstemas finais; em breve veremos que o SCJ'\•iço da camada de rede oriemado para concx;lo é irnplemellCado nos roteadores no nucleo da rede, bem como nos sistemas finais. Redes de circuitos virtuais c redes de datagmmas s:io duas classes fundamenwis de redes de computadores. El:1s utilizam informações muilo di feremes para to rnar s uas decisões de repasse. Vamos agora examinar suas implementaçOes mais de perto.

4.2.1

Redes de circuilos virluais

j :\ vimos que a Internet é uma rede de datagrnmas. EnLrctanto. mui tas arquiteturas de rede alternativasen tre elas as das redes ATM e frmnc ,.cle~y - são redes de circuitos virt uais c, portanto, us:1m conexões na c-.unada de rede. Essas conexões de <.-amada de rede são denominadas d rcultos virtuais (CVs). V;unos consíderJr agora como um serviço de CVs pode ser implantado em uma rede de computadores.

Um crrcuito virtual (CV) consiste em (I) um caminho (is to é. uma série de enlaces c roteadores) entre hospedeiros de origem e de destino. (2) numeros de CVs. um nú mero paro cada enlace ao longo do caminho c (3) registros n:l tabela de repasse em cada roteador ao longo do caminho. Um pacote q ue pertence a um circuito virtual portar:\ um número de CV em seu cabeçalho. Como um circuito \'irtual pode ter um número de CV diferente em cadn enlace, cada roteador interveniente deve substituir o número de CV de cada p:tcote em tr:\nsito por um novo mlmcro. Esse numero novo do CV é obtido da tabela de repasse. Para ilustrar o conceito, considere a rede mostrada na Figura 4.3. Os números ao lado dos enlaces de Rl na Figura 4.3 são os números das interfaces de enlaces. Suponha agora q ue o hospedeiro A solicite à rede que

bow4tto4ic~ Capí tulo •

A

Rl

R2

R3

R4

A
235

B

Figura 4.3 Umo rede de ciruitos virtuais simples

estabeleça um CV entre ele c o hospedeiro B. Suponha ainda que a rede escolha o caminho A-R 1-R2-8 c atri· bua m\mcros de CV 12, 22, 32 t~Os trcs Cli laces nesse caminho p:~m esse drcuito vintml. Nesse l"';tSo, quando ltm pacote nesse CV sal do hospedeiro A, o valor no campo do mlmcro de CV é 12; quando sai de R l, o valor é 22, c, quando sai de R2, o valor é 32. Como o rot eador dctennina o novo nümcro de CV l'am um p~cotc que passa por ele? Para uma rede de CV, a tabela de repasse de cada ro teador incluí a traclu\'ãO de número de CV; por exemplo, a tabela de repasse de Rl pode ser algo parecido com o segui me:

Interface de entrada

2 3

N• da CV de entrada

Interface de saída

N• do CV de saída

12

2

n

63 7 97

2 3

18 17

87

Sempre que um novo CV é estabelecido através de um roteador. um regastro é adactonado :\ tabela de repasse. De maneira semelhante, sempre que um CV tennina. são rcmov1dos os rcg1stros apropnados em cada tabela ao longo de seu caminho.

t: bem possl\·el que voce estcjn pensando por que um pacote nào conserva o mesmo mimero de CV em cada um dos enlaces ao longo de sua rota. Isso ocorre por dois moti\•os: primeiro, substitui r o nümero de enlace em cnlucc reduz o comprimento do campo do CV no cabeçalho do (X1cotc. Segundo, c mais importante, o estabeleci· mcnto de um CV é consldemvclmente simplificado se for permitido um nllmero diferente de CV em <:õ!da enlace ao longo do caminho do circuito virtual. Especificamente, com vá ri os mlmcros de CV, cada enlace do caminho pode escolher u m número de CV independentemente dos mímcros de CV escolh idos em outros enlaces ao longo do caminho. Se fosse exigido um mesmo rtúmero de CV para todos os cnlac~ ao longo do <:amlnho, os roteadores teriam de trocar c process;~r um número substancial de mcns:1gens pam escolher o m1 mero de CV a ser us.1do para uma concx:\o (por exemplo, IHil mimcro que n
Estabelecimento de CV. Durante a fase de estabelecimento, a camada de transporte remetente comata a camada de rede, especifica o endereço do receptor e espera até a rede estabelecer o CV. A camada de

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....rede dctcnnina o caminho entre remetente c destinatário, ou seja. a stric de enlaces c roteadores pclos quais todos os pacotes do CV trafegar.lo. A camada de rede também determina o numero de CV para cada enlace ao longo do caminho c, fi nalmente, adiciona um registro na 1:1bela de repasse em cada roteador ao longo do caminho. Durante o estabelecimento do CV. a camada de rede pode também reservar recursos (por exemplo. largura de banda) ao longo do caminho do CV.

clmlos. Como mostra a Figura 4.4, tào logo estabelecido o CV, pacotes podem começar a nui r ao longo do cv.

Trclllyl'rbtcict dr

Encerrcwu:nto elo CV. O encerramento começa quando o remetente (ou o destinat:irio) informa à camada de rede seu desejo de desativar o CV. A camada de rede então tipicamemc in[ormará o sistema final do outro lado da rede do término de conexi\o c atualiz;:~r.l as tabelas de rcpôlSSe em cada um dos ro teadores de pacotes no caminho para indicar que o CV ni\o extste mais. I lá uma distinção sutll , mas importante, entre estabclecimcmo de CV na camada de rede c cstabelecimcmo de concl>:ào no çam ~da de transponc (por exemplo, a apresentação TCP de tr~s vias que cstud:unos no Capítulo 3). Estabelecer conexão na cam:1da de transporte envolve apenas os dois sistemas finais. Dur:mtc o cstabelecimcn10 da çoneXõlo n:1 camada de trnnspone, os dois sistemas finais determinam os pari\mctros (por exemplo, mlmero de seque nela itlicial c t:Jmanho da janela de controle de nuxo) de su:1 conexM de camada de trons r>Onc. Embora os dois sistem
As mensagens que os sis1cmas finais enviam à rede paro iniciar ou encerro r um CV c as mensagens passadas entre os roteadores paro estabelecer o CV (isto é, modificar estado de çoncxào em tabelas de roteadores) são conhecidas como mensagens de slnaliz:açào e os protocolos usados para trocar essas mensagens rrequcntcmente são denominados protocolos de sinalização. O estabelecimento de CV está ilustrodo na Figura 4.-f. :-.lão nbordaremos protocolos de simtliz;\çao de CVs neste livro: (Biack. 19971 apresenta uma disnts.s.lo gernl sobre sinalização em redes orientadas para conexão c (ITU·T Q.2931 . 1994) mostra a espcciOcaç;lo do protocolo de sinalizaç;lo Q.293 1 do ATM.

4.2.2 Redes de dologromos Em uma rede de datagramas, toda vez que um sistema Onal quer enviar um paçote, ele marca o pacote com o endereço do sistema llnal de destino c emão o envia para dentro da rede. Como mostrn a Figura -+.5, isso é reito sem o estabelecimento de nenhum CV. Roteadores em um:~ rede ele dmagramas n:lo mant~ rn nenhuma informaç-ão de estado sobre CVs (porque ni\o há nenhum CV!).

ApllcaçAo 4. Chamada conectada

S. Começo do fluxo de dados Flsica

Inicia chamada --'

Figura 4.4 Estabelecimentode circuito virtual

3. Chamad a aceita

6. Receblm

dedado~o~

11:

Aplica~Jo

Transporte Rede Enlace

Ffsica

~2. Chamadachegando

bow4tto4ic~ Capitulo

~

A u11oda de rede

Aplica~3o

Aplica~âo

Transporte

Transporte

Rede Enlace

1. envia dados

Flsica

2. Recebe dados

2.37

Rede Enlace Física

Figura 4.5 Rede de dolog10mos t\o ser tnmsrn itído da fon te ao destino, um pacote passa po r uma sc!ric de ro teadores. C;tda urn desses rotc-.Jdores usa o endereço de destino do pacote para repassá-lo. Especificamente, cada roteador tem uma tabela de repasse que mapeia endereços de destino para interfaces de enlaces; quando um pacote chega ao roteador, este usa o endereço de destino do pacote para procur.tr a interface de enlace de s:lfda apropriada na tabela de repasse. Então. o roteador trans mite o p;ICOte para aquela interf;lce de enlace de safd;l.

Para entender melhor a operaç;1o de consulta. vamos examina r um exemplo cspecinco. Suponha que todos os endereços de destino tenham 32 bits (que, por acaso. é exatamente o co mprimento do endereço de destino em um datagrama IP). Uma implementaç;1o de força brttta da tabela de repasse teri<~ um registro para cada endereço de destino possível. Porém. como há mais de quatro bilhoes de endereços possl"eis, essa opç;1o está totalmente fora de questão - cxigiría uma tabela de repasse imensa. Vamos supor ainda mats que nosso roteador tenha quat ro enlaces numerados de O a 3. c que os pacotes devem ser repassados para as interfaces de enlace como mostrado a seg111r: Faixa de Endereços d e Destino

lntcrrace de enl ace

I LOO 1000 000 1O111 00010000 00000000 até

o

1100100000010111 000 10 111 11111111 11001000000LO L11 00011000 00000000 até 11001000 000 I O111 00011000 11111111 1100 1000 000 LO111 000 1100 1 00000000 até

2

I I00 I 000 000 I O11 I 000 I 1111 llllllll senão

3

Fica ch1ro, por este exemplo. que n:\o c necessário ter quatro bilhões de regis tros na tabeln de repasse do roteador. Poderíamos, por exemplo, ter a seguinte tabela de repasse com apenas quatro registros: PrcfLXo d o endertço

Interface de enlace

11001000 00010111 00010

o

11001000 00010111 00011000

1

llOOlOOO 00010111 OOOll

2

senão

3


Com esse tipo de tabela de repasse. o roteador compara um prcrL..:o do endereço de desuno do pacote com os registros na tabela; se hou,•er uma concordância d e prefixos. o roteador tr.ansmite o pacote para o enlace associado àquele prefixo compatí,•el. Por exemplo, suponha que o endereço de desuno do pacote seja 11001000 00010111 00010110 10100001: como o prefixo de 21 bits desse endereço é igual ao primeiro registro na tabela. o roteador transmite o pacote para a interface de enlace O. Se o prefixo do pacote não combinar com nenhum dos três primeiros registros. o roteador envia o pacote para a interface 3. Embora isso pareça bastante simples, há aqui uma sutileza importante. Voe~ talvez tenha notado que existe a posstbilidade de um endereço de destino combinar com mais de um rtgtstro. Por exemplo. os primeiros 24 bits do tndcreço UOO IOOO 00010111 00011000 10101010 combinam com o segundo registro na tabela e os primeiros 21 bits do endereço combinam com o terceiro registro da t:-tbcla. Quando há várias concordâncias de prefixos. o roteador usa a regra da concordância do prcruco mais longo . isto~. encontra o registro cujo prefixo tem mais bits compatíveis com os bits do endereço do pacote c cn vi:t o pacote à Interface de enlace associada com esse prefixo mais longo compatível. Veremos exatamente por que essa regra de prefixo mais longo compatrvcJ 1: utilizad" quando estudarmos endereçamento da l nternet em tmtis detal hes da Seç-.lo 4 .4. Embora em n·des de datagn11uas os roteadores n110 mantenham nenhuma inrormaçâo de estado de concxo1o. ainda (ISSirn n Hm L~ m inform~tç:io de estado de repasse em suas tabelas de repasse. Tod
4.2.3 Origens das redes de circuitos virtuais e de dotagromos J\ evolução das redes de da tagramas e de circuitos ''irtu.ais renetc as origens dessas redes. A ideia de um circuito virtu:tl como prineír>io fundamental de organização tem suas raizes no mundo da telefonia (que usa circuítos reais). Como em redes de CV os roteadores mantêm estado de chamada c estado por ehatmtda, esse tipo de rede é considemvchnente mais complexo do que urna rede de da tagmmas. ((Mollncro-Fernandez, 20021 faz u ma comp;mlç;\o Int eressante entre <\S complcxtdades de redes ele comut:tcão de circu u os c de comut:tç:\o de pacoles.) lsso lambtm csu\ de acordo com a heranr;a da Lelefonia. A eo rnple.-.:idadc dus redes telefônicas eslava, ncc:e.ssariamemc, dentro ela própria rede, já que elas conectavam sistemas finais m\o inteligentes tais como telefones de disco. ( Para os mais jovens q ue não o conhecem, um telefone de disco é um teldone un:1 lógico (isto é, não digi tal ( sem teclas-, tem somente um mostrador com números e um dispositivo mectln ico denomi nado disco.)

Por sua vez. a Internet como uma rede de datagramas surgiu da necessidade de co nectar computadores. Como esses sistcm"s nn .. is s.io mais sofisticados. os arqui tetos da Internet preferira m construir um modelo de serviço de <.-amada de rede o mais simples possível. Como já vimos nos Capítulos 2 c 3, funcionalidades adicionais ( por exemplo, entrega 11:1 ordem. tr:msrertncia confiável de dados. controle de congestionamento c resoluçi!o de nomes DNS) sào unplcmcntadas em uma camada mais aha, nos sistemas fi nais. Isso mvertc o modelo da rede de telefonia. com nlgum;ts consequencias interessantes: Visto que o modelo de serviço de camada de rede resuhamc da Internet, que oferece garantias mmimas ( nenhuma' ) de serviço. impõe exigencias mínimas sobre a cam:~da de rede. Isso facihta a interconexão de redes que us.1m tecnologias de camada de enlace muno dtfcrentes (por exemplo, satélite, Ethernel. fibra ou rádio) c cujas taxas de transmisSão c caractcrfsticas de perda Lambtm sào muito difercnLcs. Vamos abordar dctal.hadamente a interconexão de redes IP na Seção 4.4.


A
2.39

Como vimos no útpilulo 2, aplicações como e-ma~l. a \Veb e at~ mesmo um sen•iço cemrado na camada de rede como o DNS silo irnplememadas em hospedeiros (scn·idores) na borda da rede. A capacidade de adicionar um novo serviço simplesmente Ugando um hospedeiro :'1 rede c dcOnindo um novo protocolo de camada de aplicação (como o HTIP) pcrmntu que novas aphcaçOes como a Wcb fossem distribuídas pela Internet em um período notavelmente curto. Como veremos no útpilulo 7, há uma considerável discuss;io na comunidade da lmcrnct sobre como a arquitciUra da camada d e rede da lm crnet de\'C evoluir para suponar serviços de tempo real como muhimfdia. Uma comparação intcress.•mte entre a arquiteiUra de rede ATM orientada para CVs c a próxima gcraç-.io proposta para a arquitetura da Internet t dada em [Crowcroft. 19951.

4.3 Oque há dentro de um roteador? i\gom que já tivemos uma visno geral das funções c serviços da camada de rede, \•olt::~remos nossa :ucnç{lo para :1 funç1\o ele repasse- a transferência, propriamente dita, de pacotes dos enlaces de entrada at~ os en laces de saída adequados de un1 roteador. Já estudamos a lgumas questões de repasse na Scç;lo 4.2, a s:~bc r, endere<;umcnto c compatibiliznç;'o com o prdixo mals longo. Nesta scç:lo cxaminnrcmos arquiteturas cspccrn~.-as de roteadores para transferir pac.:otes ele enlaces de entrada para enlaces de sõ\fda. Neste c.:aso, nossa análise t necessariamente breve, pois seria necessário um curso completo para trotar do projeto de roteadores com profundidade. Conscquentementc, faremos um esforço especial nesta seção para indil-ar material que apresente esse tópico com mais profundidade. Mencionamos, de passagem, que os pesquisadores e pronss•onais de redes de computadores usam as pala\•ras ltplJSSI' c comulcrçclo indistintamcmc; nós usaremos ambos os termos neste livro. Uma v1slo de alto nwcl da arquitetura de um ro teador nentes de um roteador podem ser íclcmilkados:

gcn~rico ~

mostr:lda na Figura 4.6. Quatro compo-

Porws cir CII!Hida. A porta de entrada tem diversas funçOes. Ela reahza as funçOcs de camada ffsica

(a

caixa ma1s à esquerda da porta de entrada e a caixa mais à direita da porta de S.'lida na Fígura 4.6) de tcm1inar um enlace físico de entrada em um roteador. Realiza também as funçOcs de camada de cnJace ( representadas petas caixas do meio nas portas de entrad;• e de safd:t) necessárias para interoperar com as funções da camada de enlace do outro lado do r nlacc de entrada. Realiza ainda uma função de exame c de repasse (a caixa mais à direita da porta de entrada c a caixa mais à esquerda da port:t de salda) , de modo que um pacote repassado ao clcmemo de comutação do roteador surja na pona de S.'lfda apropriada. Pacotes de controle (por exemplo, pacotes carregando infonnac;Oes de protocolo de roteamento) s;lo rcpass.1dos de urna porta de entrada até o processador de ro teamento. Na prática, \':Irias portas são frcqucntcmclllc reunidas em uma única placa de linha no interior de um rolcador. Porta de entrada

Porta de entrada

Figura 4.6 Arquitetura de roteador

Porta de salda

Elemento de comutação

Porta de salda

bow4tto4ic~ Redes de tom pulod ores e o Interne~1------------------------Elemrlllo de conwla{tlo. O elememo de commação com~cta as porras de entrada do roteador às suas J>Or-

tas de smda. Ele esta imegralmenu~ contido no interior do roteador- uma rede dentro de um roteador de rede!

Polias tlr sault1. Uma J>Orla de saída armazena os pacotes q ue fomm repassados a ela através do clcmemo de comutação c, emão, os transmite até o enlace de saída. Assm1, a J>Orta de salda rcahza o inverso da funetonahdade da camada de enlace c da camada física da J>Orta de entrada. Quando um enlace é bidirecional (isto é, carrega um tráfego em ambas as direções), uma pona de sarda para o enlace ser.\ tipicamente cmp<~relhada com a pona de cnlr:lda para aquele enlace na mesma placa de linha. P•occssntlo1 ele roteamento. O proct>ssador de roteamento roda os protocolos de roteamento (por exemplo, os protocolos qut: estudamos na ~ção 4.6), mamém as informações de roteamento c tabelas de repasse c executa funções de gerenciamento de rede (vcj:t o Capitulo 9) dentro do ro teador. Nas subse~·õcs seguintes, examinaremos com maíores detalhes porras de entrada, o elemento de comutação c portas de salda. [Chuang, 2005; Kcslassy, 2003; Chao, 2001 ; Turner, 1988; Giacopclli, 1990; McKeown, l997a; Partridge. 19981 fornecem uma análise de algumas arquite turas específicas d e roteadores. IMcKeown, l 997b) aprese nu.\ uma visão geral p:mlcularmente fácil de ler de modernas arquheturas de roteadores us:1ndo o roteador Cisco 12000 como exemplo. Para manter a discussão em terreno concreto, admitimos que a rede de computado· res é u m:~ rede d e pacotes e que decisões de repasse se basci:~m nos endereços de des tino dos pacotes (e não em um número de CV em uma red e de circuitos virtuais). Todavia, os conce11os c técnicas s;\o s i mil:~rcs aos de uma rede de circuitos virtuais.

4.3.1

Portos de entrado

Um:~ \'is;\o mais detalhada d:t funcionalidade de J>Orla da entrada é apresentada na Figura 4.7. Como discutido anteriorme nte, as funções de terminação de linha e de processamento de enlace realizadas pela porta de emrada implcmemam as camadas física e de enlace associadas a um enlace de entrada mdwidual do ro1cador. O módulo cxamin:~r/rcp.tSSar d:~ porta de entrada é fundamental para a funç;'o de repasse do roteador. Em muitos roteadores. é aqui que o roteador determina a J>Orta de sarda para a qual o pacote que está chegando scnl repassado pelo elemento de comutação. A escolha da J>Orta de saída é klla usando a mformaç;lo contida na tabela de repasse. Embora a tabela d e repasse seja tlk~tlada pdo p rocessador de roteamento, uma cópia da tabela é comumente armazenada em cada porta de entrada c arualizada, quando necessário, pelo processador de r01camemo. Com cópias loc-Jis da tabdt1 de repasse, as decisões de repasse podem ser tomadas localmeme, em cada J>Orla de emrada, sem chamar o processador de ro1eamemo centralizado. Esse repasse descemralizado evita a criação de um gargalo de processamento de repasse em um unico ponto no interior do roteador.

Em rotcndorcs com capacidade limitada de proccssamemo na porta de entrada, a pona llode simplesmente repassar o p:1cotc p:tm o processador de r01camemo centralizado, que, elll;lo, reallz:•rá o exame da tabela de repasse e transmhir:t o p:teotc El por~a de saída apropriada. Esta é a abordagem adotada quando uma cs ta~o de trabulho ou um servidor fun ciona como um roteador. f\qui. o processador de roteamento é. nil realidade. apenas a CPU da cstaç;lo de trab:tlho. enquanto a porta de entrada e. 11:1 verdade, :1pcnns uma placa ele interface de rede ( por exemplo, uma ph1ct Ethcrnct). Dada a cxistencia de uma tabel:~ de repasse, o ex:1mc é concehualmen te simples- basta procurar o registro mais longo cornp;llívcl com o endereço de destino. como descrito na Scç:io 4.2.2. Porém, na prática. <15 coisas nào

Termína~ão

de linha

Proce1samento de enlace (protocolo. desencapsulamento)

Figura 4.7 Processomentono porto de entrado

Consulta. repasse, fila Elemento de comutação

bow4tto4ic~ (opítulo •

Á

co11odo de rede

Cisco Systems: dominondo onúcleo do rede Alé outubro de 2008, o Cisco empregava mais de 65 mil pessoos. A empresa dominava o mercado de roteodores do lntemet e, nos últimos anos, voltou-se poro o mercado de telefonia por Internet, em que concorre de igual poro igual com empresas fabricantes de equipamentos de telefonia como lucenl. Alcotel, Nortel e Siemens. Como surgiu euo gigantesco empresa de rede? Tudo começou em 1984 no solo de estar de um oportomento no Vale do Silício. len Bosak e suo esposo Sondy lerner trobolhovom no universidade de Stonford quando tiveram o ideio de construir e vender roteadores de Internet o instituições acadêmicos e de pesquiso. Sondy lerner teve o ideio do nome ·cisco• (umo obrevioçõo de Son Francisco) e também criou o logotipo do empresa, que é uma ponte. A sede do empresa era originalmente o solo de estar do co sal que, no início, financiou o projeto com cartões de crédito e trabalhos e)(tros. No final de 1986, o Cisco conseguiu a trair capital de risco - dois milhões de dólares da Sequoio Capital em troco de um terço da empresa. Nos o nos seguintes. o Cisco continuou o crescer e o conquistar cada vez mais po rticipoçõo de mercado. Ao mesmo tempo, o relacionamento entre Bosak/Lerner e o administraçõo do empresa começou o licor tenso. A Cisco abriu seu capital em 1990 e. ne$$e mesmo ano, lerner e Bosak saíram do empresa. Com o passar dos anos, o Cisco expandiu amplamen te seu mercado de roteadores. vendendo produtos voltados à segurança, redes sem fio, com tecnologia Voz sobre IP e serviços. En tretanto, a empresa estó enfrentando concorrência internacional crescente, incluindo o empre50 chinesa em crescimento Huowei, que fornece equipamentos de rede. Outros fontes de concorrência poro o Cisco no mercado de roteadores e Ethernet comutado incluem o Alcote~lucent e o Juniper.

s~o

assim t;\O snnples Tnlvez o principal fator de complicação seja o fato de os roteadores de oockbone 1erem de opernr em altas velocidades, rodando milhões dr exames por segundo. 'a verdade, é desejável que o proccssamemo da porta de entrnda tenha a capacidade de opcrnr à velo cidade da Unha, is1o é, que o exame possa ser feito em tempo menor do que o necess.1rio parn receber um pacote na porta de entrada. Nesse caso, o proccssamcmo de emrnda de um pacote recebido pode ser concluído :tntes do término da opemç;lo de recebimento subsequcnte. Para ter uma ideia das cxig~ncias de desempenho para uma consulta. cons1dere que um enlace do tipo OC48 opere à ''clocidade de 2,5 Gbps. Com pacotes dr comprimento de 256 bytcs, isso implka uma taxa de aproximadamemr um milh:'\o de consuhas por segundo. Devido à necessidade de operar n<~S a ltas velocidades de enlace atuais, ~ unpossh·el uma busca linear em uma talx la de repasse- extensa. Uma 1écnica mais razoável é armazcnM os registros da t;lbcb de repasse em uma estrutura de árvore de d<~dos. Cada nível da árvore pode ser imagim1do como urn bil no endc•·cc;o ele desl ino. Para ex:1minar um endereço, basta simplcsmeme começar no nó da rniz da árvore. Se o primeiro bit do endereço ror zero, então a subárvore da esquerda contem o regis~ro da tabela de •·epasse para o endereço de desuno: caso conmlrio, ele cstar:l ml s ub:.\rvo re da direita. A sulxlrvorc apropriada~. cm:.io, percorrida usando os bits de endereço remanescentes- se o próximo bít do endereço for zero, ser:\ escolhida a sub::\rvore da esquerda da sub::\rvore in i· cial: caso contrário. será escolhida a s ubárvorc da direita. Dessa maneira, podemos examinar o registro da tabela de repasse em N ctap;IS, em que N é o número de bils do endereço. (Note que isso ~. essencialmemc, uma busca binária em um espaço de endereço de tamanho 2'.) Um melhoramento das técnicas de busca binária é descri lo por (Srlni\~Jsnn, 19991. c um lev:~ntamcnto geral de algoritmos de classiflcaç-Jo de pacotes pode ser encontrado em [Gupta. 200 1) . Mas, mesmo quando N = 32 c~apas (por exemplo. um endereço IP de 32 bitS), a veloc1dade de consulta pela busca binaria não é suficientemente rnpida para os requisitos atuais de roLcamcnto de backbone. Por exemplo. admitindo um acesso à memória a cada etapa. menos de um milhão de consultas de endereços por segundo podem ser re-alizadas com tempos de acesso à memõria de 40 nanossegu ndos. Assim, diVersas têcmcas têm sido pcsquisadas para aumelllar as velocidades de consulta. Memórias d e conteúdo endereçável (content addressable


memorics- CAMs) permitem que um endereço IP de 32 bíts seja apresentado • CAM, que então devoh•e o contel\do do registro da tabela de repasse par.t o endereço em tempo essencialmente constante. O roteador da série 8500 da Cisco tem urna CAM de 64K para cada porta de entrada. O utra técnica para acelerar a consulta é manter registros de tabela de repasse acessados recentemente em armazenamento mtcrmedi:írio (cache) (Feldmeier, 1988). Nesse caso, a preocupaç.\o é o tamanho potencial do cache. Foram propostas estruturas de dados velozes, que permitem que os registros da t:1bel:1 de repasse sejam localizados em log( N) etapas (Wald,•ogel. 1997) ou que comprimem tabelas de repasse de manem\S originais (Brodnik, 1QQ7). Uma abordagem d:1 consulta baseada em hardware c otimizada p:~ra o caso corriqueiro em que o endereço que está sendo examinado tem 24 bits signific;~tivos ou menos é discutida por (Gupta, 1998). Para urna análise c taxonomia d e algoritmos de busca de endereço IP de aha velocidade, consulte (RuizS;~nchcz , 2001). Assim que a porta de s:\fda para um pacote é dctcrminadn por meio da consulta, o pacote pode ser repassado par:t o elemento de comutação. Contudo. um pacote pode ser ternporari:uncntc impedido (bloque
4.3.2 flemento de comutação O elemento de comutação cstJ no coração de um ro teador. 1:! por meio do elemento de comutação que os pacotes ~lo comutados (isto t , repas~tdos) de uma porta de entrada para uma pona de salda. A comutação pode ser rcaliz:tda de inúmeras m:~neiras , como mostro a Figura 4.8. Cornuraçilo po1 memória. Os primeiros e mais simples roteadores q uase sempre eram computadores tradicionais nos quais a comutaç-lo entre as portas de entrada c de sarda era rcalitada sob o controle dtreto da CPU (processador de rotcamento). As portas de entrada e de saída funcionavam como d isposith·os tradicionais de cntmdalsafda de wn sistema operacional tradicional. lJma pona de entrada na Memória

Crossbar A

- o

o

B

Eiilll -

---+---41--~

c

DO@ill X Barramento

A

~

D D o

c z ooC§1 -- ~oo legenda:

DQE)Porta deenttada GDD Porta de saída

Figuro 4.8 Três técnicos de comuto~õo

~

y

z~

~

D o


A collloda

de

rede

qual um pac-ote estivesse entrando primciramemc sinalizaria ao proc-essador de roteamento por meio de uma intcrrupç;lo. O pacote era enuio copiado da porta de entrada para a memória do processador. O process.1dor de roteamento então extraia o endereço de destino do cabeçalho, c-onsult:wa a porta de sarda apropriada na tabcl:l de repasse c copia'" o p:lcotc para os buffcrs da porta de sarda. Note que, se a largura de banda da memória for tal que B pacotes/segundo possam ser escritos ou lidos na memória, então a vazllo total de repasse (a velocidade total com que os pacotes s:lo transferidos de portas de entrada para portas de saída) de,•erá ser menor do que 8/2. Muitos rotc:tdores modernos também comutam por memória. Conwdo, um:. import:mtc diferença entre esses roteadores c os antigos é que a consulta do endereço de destino c o am1azc:namcnto do p::tcotc na localiza\l\O adequada da memória sM realizados por processadores nas placas de linha de entrada. Em certos aspectos, roteadores que comut.am por memória se parecem muito com multi processadores de memória compartillmda, nos quais os processadores de urna placa de linha comutam pacotes para a memória ela porta de salda adeq uada. Os comutadores série 8500 Catalyst da Cisco (Cisco 8500, 20091 comtnam pacotes por uma memória companillmdn. Um modelo abstrato pnra cstlLdar as propriedades da comutaç:lo (>Or memória c uma compar.t~':lO corn outras formas ele comutação podem ser encontrados em ll>•er, 20021.

ComHitiiM pol' um bmramctiiO. Nessa <1bordagcm, as pon.1s de entrada transferem um pacote diretamente para a porta de sarda por um barramento compartilhado sem a inLcrvenç:lo elo processador de roteamemo (note que na comutação por memória o p-.lcote tambtm deve amwcssar o barramento do s istema para vir dn memória c ir para ela.) Embora o processador de roteamemo não esteja envolvido na transferencia por barramento, como o barramento é compartilhado, somente um pacote por \ 'CZ pode ser transferido por meio do barramemo. Um pacote que chega :1 um:1 porta de entrada e encomra o barramento ocupado com n transfertncia de outro pacote tem bloqueada su:1 passagem pelo elemento de comut:lç:lo c é colocado na fila da porta de entrada. Como cada p:~cotc dc\•e atravessar o único barramento, a largura de banda de comu tação do roteador fica limitada à velocidnde do barramento. 001do que larguras de banda de barramento acima de I Gbps s;lo possfvcis com a tecnologia :nual, a comutaç:lo por barramento muitas vezes é sulk•cntc para roteadores que operam em redes de acesso e redes de cmprcs.1S (por c.xemplo, redes locais (LANsl c redes corporativas). A comutaç-ao por barramento foi adotada em uma série de produtos de rotcame1110 atua1s, entre eles o Cisco 5600 (Cisco Switehes, 2009) , que comuta pacotes por um barramento da placa-mãe (bacllpltrnc bus) de 32 Gbps.

Comuttl(tlo por wna rede ele intcrconrxiio. Um modo de vencer a limitação da largura de banda de um barramento tlnico comp:trtilhado é usar uma rede de interconexão m:~is sofistic:~d:~, t:tl como as que eram utilizadas no passado para intcrconectar processadores em uma arquitewra de computadores multiprocessadorcs. Um comutador do tipo crossbar é uma rede de interconexão que <.'Onsiste em 2n barramentos. Esses barramentos conectam 11 portas de entrada com 11 portas de sarda, como mostra a figura 4.8. Um pacote qu e chega a um~• pona de entrada percorre o barramento horizontal ligado à poria de cntrnd:l até interceptar o barramento vertical que leva à port:l de salda desej:1da. Se o barramento vertical que lcvn ~ porta de salda estiver livre, o pacote ser.! transferido para a ponn ele salda. Se o barramento vcrLical estiver sendo us.'ldo para rransferir um pacote de outra porta de entrada para essa mesma porta ele sarda. o pacote que chegou ficará bloqueado e deverá entro~ r na fila da porta de entrada. Elementos de comutação Delta c Omega tam bém foram propostos como rede de interconexão entre portas de emrada c de saída. Consulte (Tobagi, 1990) para um levantamento de arquiteturas de comutaçJo. Os comutadores da Família 12000 da Cist·o [Cisco 12000, 2009) usmn uma rede de íntrrconcx•lo que fornece :ué 60 Gbps pelo elemento de comutaç-Jo. Uma tcndencia no prOJeto de rede de mtcrcon~ilo (Kcshav, 19981 é fragmentar um datagra ma IP de compnmcnto ,·anávcl em células de comprimento fixo c, cnt•\o, marcar c comutar as células de comprimento fixo por meio da rede de in terconexão. As células s;lo então montadas novamente reproduzmdo o pacote onginal na porta de sarda. A célula de comprimento fixo c a wg de comrolc in Lemo podem simplificar c acelerar considcravclmcmc a comutação de pacotes pela rede de imerconexão.


4.3.3 Portos de saído O processamento de ponas de saída mostrado na Figura 4.9 toma os pacotes que foram armazenados na mcmórm da porta de smda c os trnnsmite pelo enlace de saída. O processamento do protocolo de cnl:tcc c :t ter-

minaçâo da linha s.\o as funcionalidades de C:lmada de enlace e de c:tmada flsrca do lado remetente que interagem com a porta de entrada do outro lado do enlace de saída. como discutido na Seção 4.3.1. As functonalidades de fila e de gerenctamento de buffer s.\o necessárias quando o elemento de comutação entrega pacotes à pon;r de salda a uma taxa que excede a taxa do enlace de sarda. Vamos exammar a seguir o enfileiramento na porta de salda.

4.3.4 Onde ocorre formação de filo? Se examim•rmos a funcion:tlidadc da porta de entrada e da pom de salda c as configurações mostradas na Flgura 4.8 , veremos que filas de pacotes podem se formar t:mto nas portas de entrada como nas portas de salda. 1: importante considerar essas Olas com um pouco mais de detalhes. j;\ que, à medid~ que elas rlcam maiores, o espaço de bu[fer do roteador será fi nal mente exaurido c ocorrerá per-da de pa cote. Lembre-se de que, em nossas discussões :mterlores, dissemos que pacotes eram perdidos den tro da r·ede ou descartados em mn roteador. E~ a!, ncss,1s Olas dentro de um roteador, que esses pacotes Sl10 descartt~dos ou perdidos. O local real d41 perda do pacote (seja nas lHas d:\ porta de entrada, seja MS filas da porta de safcla) dependerá da carga de troifcgo, da velocidade relativa do elemento de comutação e da taxa da linha. como discutiremos :1 seguir. Suponh.t que as ta.xas da linha de entrada e as tax-as da linh:t de S
>

Elemento 1 ~ de 1comutaçlo

Fila (gerenciamento de buffe4')

Figura 4.9 Processamentode porto de saído

-

Processamento de enlace (protocolo, encapsulamento)

-

Terminaçlo de linha

-


-

Contenção pela porta de

-DO -DO -DO

-

~aida

A ca11 oda de rede

245

no tempo t

DO o DO o DO o Um tempo de pacote mais tarde

oDD o o~D

-DO Figura 4.1 O Fom~õo de fio no porlo de soído

Dado que os buffcrs do roteador são necessários pam absorver as oscilações da <.""arga de tráfego. deve-se perguntar quwuo de am1azenamemo em buffer é necessário. Durante muitos anos. a regm pr.hica (RFC 3439) pam dimensionamento de buffcr foi que a quanLid:~de de armazenamento em buffcr de,·cria ser igual a um tempo de \'iagcm de ida c volta (RTT. digamos, 250 milissegundos) vezes a cap.1cidade do enlace (C). Esse resultado é baseado em uma análise da dinâmica de l'ilas com um numero relativamente pequeno dos Ouxos do TCP (Villamiz.ar, 1994) . Assim, um enlace de lO Gbps com um RTT de 250 milissegundos precisaria de uma quamidade de am1azcnamcmo em buffcr igual a 8 • RTT • C .. 2,5 Gbps de buffers. Esforços teóricos e expcnmcmms recentes (Appcnzeller. 2004) , cmrctamo. sugerem que quando h:l um grande número de nuxos do TCP (N) passando por um enlace. a quantidade de armazenamento em buffer neccssãna é 8 • RTT • CIVN. Com um grande numero de Ouxos pass.1ndo normalmente por gmndes enl:1ccs dos roteado res da fonte principal (consulte, por exemplo. [Fmlcigh. 20031), o valor de N pode ser gmndc, c :1diminui(,.'ão do tamanho do buffcr necessário se torna bastante signifi<.-:ttiva. [Appcttzdlar, 2004; Wischi k, 2005; Behcshti. 2008) apresentam discussões esclarecedoras em rcla~·i\0 ao problema do dimcnsion:uncmo de buffer a partir de um ponto de vista teórico, de aplicnçao e operacional.

Unm consequencia da nla na porta de sarda t que um escalonador de Jlacotes na porta de sarda deve c.sco· lhcr para trans miss.'lo um pacote dentre os que estão na fila. Essa sde~'{lo pode ser feita com base em uma regra simples baseada na própria ordem da fila (FCFS) ou por uma regra de cscalouamento mais sofistic:1da, tal como a fila ponderada j usta (wrlglrtrd fali' quculng - WFQ). que comp<.mlllta o enlace de safda com justiça entre a-; diferentes concxOes fim a fim que têm pacotes na fila pam tmnsmissilo. O escalonamento de pacotes desempenha um papel crucial no fo rnecimento de garantia de qualidade de serviço. Examinaremos o escalonamento de p:~cotes extensivamente no Capitulo 7. Uma discuss.1o sobre disciplinas de escalonamento ele pacotes na porta de salda pode ser encontrada em ICisco Queue, 2009). De modo semelhante. se n:lo houver memória suOcicnte para armazenar um pacote que está chegando. ser.\ prcctso tomar a deeis;lo de descartar esse pacote (política conhecida como descarte do Gnal da fila) ou remover um ou mais pacotes j:l cnfileimdos pam liber.1r lugar para o pacote rcctm-chegado. Em alguns casos pode ser vantajoso descartar um pacote (ou marcar o seu cabeçalho) antts de o buffcr ficar chcro, parn dar um sinal de congesuonamcmo ao remetente. Várias políticas de desca rte c marcaç;)o de pacotes (conhecidas colctl\•amcme como algoritmos de gerenciamento ativo de ma (aclive qru.'ue managemenl- AQMJ) fomm propostas c analisadas (Labmdor, 1999; Hollot, 2002). Um dos algoriunos AQM mais estudados c implementados é o algoritmo de detecção aleatória rápida (ranclom early cletection - RED). Esse algoritmo man tém uma média ponderada do

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....comprimento d:l Ola de s:.rda. Se o comprimento mtdio da fila for menor do que um valor limite mínimo, rnin,., quando um pacote chegar. será admitido na fila . Inversamente, se a r.ta estiver cheia ou se o com primemo médio da fila for ma1or do que um valor limite máximo, rnttx,_. quando um pacote chegar, será marcado ou descartado. Finalmente, se o pacote chcg;u c encontrar uma Ola de comprimento médio no intervalo (min,•• max,.l. o pacote será marCõldo ou descartado com uma probabilidade que normalmente ~ alguma função do comprimento médio da fila. de min.,. e de mlLY,~. Foram propostas inúmeras funções probab1lrsticas para atuação nos pacotes e várias versões do RED foram modeladas, simuladas e/ou implementadas analiticamente. (Christiansen, 2001) e (Floyd. 2009) oferecem visões gerais e i ndtcaç~ de leituras adicionais.

Se o elemento de comutação n:lo for suficientemente ''cloz (em rclaç;\o às taxas da linha de entrada) p.1ra trall$mitlr sem atraso IO
-DO - DO

OOD -+

- DO

OOD-+

Pacote claro do úhimo retângulo sofre bloqueio HOL

-DOU]-

- D00-DOU]-

Elemento de

comutaç.ão

~mo

o-+

Legenda: d~tin
mais alta

porta de salda

destinado a porta de salda do meio

Figura 4.1 1 Bloqueio de cob~o de filo em um comutodor com filo de entrado

d~tin
a porta de saldo


A ca11 oda de rede

bloqueio de cabeça de fila (ltc(l(l-of-rlrc-linc - HOL b/ockíng) em um comutador com fila de entrada - um pacote q ue está na Ola de cmrada deve esperar pela transfer~ncia a través do elemento de comutaç:\o (mesmo que sua porta de salda esteja lh·re) porque ele está b loqueado por u m outro pacote na cabe~-a da fila. [Karol, 1987) demonstra que, devido ao bloqueio HOL. o comprimento da fila de entrada cresce sem limites (informalmente, isso equi\-alc a dizer que haverá significativas perdas de pacotes) em de terminadas circunstâncias assim que a taxa de chegada de pacotes no enlace de entrada alcan~-a r apenas 58 por cento de sua capacidade. Uma série de soluções para o bloquero IIOL e discut ida por [McKeown, 1997b) .

4.4

OProtocolo do Internet (IP): repasse e endereçamento na Internet

Até agora discutimos endereçamento e repasse na camada de rede, sem referências a nenhuma rede de computadores cspcclfic:1. Nestn scç.\o, volwrcmos nossa ntcn~"enantcs do Protocolo da Internet ( IP). ll:\ d uas versões do protocolo lP em uso hoje. Examim1rcrnos p rimeiramen te a ' 'ersào mais utilizada do IP, a vcrs;lo 4, que normalmente é denominada simplesmente 1Pv4 (RFC 79 1). t::xa mlnare mos a ve rsão 6 do IP [RFC 2460; RFC 429 1), q ue foi proposta para substituir o IP\14, no final desta seç-Jo. Mas. an tes de inidar nosso :uaque ao IP, vamos voltar um pouco atrás e considerar os componentes que formam a camada de rede da Interne t. Corno mostra a Figura 4.12, a camada de rede da In ternet tem trts com· ponen tes mais imi>Ort:mtes. O primeiro componente é o protocolo IP, que é o tópico desta scç-.\o. O segundo componente mais importante é o componente de roteamento, que deter mina o caminho que um d;uagrama segue desde a origem at~ o destino. Mencionamos anteriormente que protocolos de roteamento calculam as tabelas de repasse que ~lo usadas para transmitir pacotes pela rede. Est udaremos os protocolos de ro teamento da Internet na Seção 4.6. O componente final ela ~-amada de rede é um dispositivo para comuni<.-a<,"
4.4.1 Formato do dotogromo lembre-se de que u m pacote de camada de rede é denornmado um datagrama. lnicmmos nosso estudo do IP com uma vislo geral da sintaxe c dó\ SCmllnt.ica do da tagramn lP,·4. Você talvez esteja pensando que nada poderia ser mais dcsinterCSS
L ,.----, Tabela de repasse

Camada de enlace Camada

fisie<~

Figura 4.1 2 Contemplandoo interior do mmodo de rede do Internet

C<~mada

de rede

bow4tto4ic~ Redes de com pulod ores e o Inler.;;n.;;, e;.. l-----------------------um papel ccmr.~l na lmcnm- todos os estudantes c profissionais de rede precisam v~- lo. abson·t-lo c dominá-lo. O fonnato do datagrnma 1Pv4 é mostrado na Figura 4.13. Os principais Cllmpos desse datagrama s'o os seguintes:

Numero 1/cr \'Cisclo. Esses quatro bitS especificam a vcrs
Comprimruto tio wbcç(lllro. Como um daugrama IP,·4 pode conter um número ' 'anável de opções (i nclu ídas no L-abeçalho do datagrama JPvi), esses quatro bitS slo neccssarios para d eterminar ond e, no dat;~gr.un:-~ JP, os d:-~dos realmente come(am. t\ maior parte dos dat;~gramas IP n11o con u~m opções; ponanto, o datagrama IP típico tem um cabeçalho de 20 bytes.

Ti po tlc scrvi(o. Os bits de tipo de serviço (IYIJC of wvicc- TOS) for.~m inclufdos no cabeOiftica determinada pelo administrador elo roteado r. Examinaremos dewlhatlamentc a questão do servi ço diferenciado no Capítulo 7. COIIIJ)I illlCIIIO elo dcrwgrcuna.

e

o comprimento total d o data grama IP (cabeça lho mais dados) medido em bytes. Uma vez que esse campo tem l õ bitS de comprimento, o tamanho máximo teórico d o datagm ma IP é ()5.535 bytes. Contudo, datagromas raramente sào maiores do q ue 1.500 bytcs.

lclcutifietulor, Jlags,
Trmpo ele ' 'ida. O Cllmpo de tempo de vida (timt-to·hve- TTL) t mel urdo para garanur que d;nagr.unas n:lo fiquem circul:-~ ndo para se mpre na rede (devrdo a , por exemplo. um laço de roteamento de longa duraç-.\o). Esse campo é decremcntado de u ma unidade cada ,·cz que o d;nagrama é processado por um roteador. Se o Cllmpo TTL chegar a O, o datagrama deve ser descartado.

P1·orocolo. Esse campo é usado somente quando um datagroma IP chega a seu destino llnal. O valor desse cr~mpo indica o protocolo de camada de transporte cspeciOco ao qu:-~1 a (>Or(<'IO de dr~dos desse 32 bits

versa o

Comprimento do cabeçalho

lípo de serviço

Ftags Oe$IO
Identi ficador de 16 bits Tempo de vida

Comprimento do datagrama (bytes)

Protocolo da camada superior

Soma de veríficação do cabeçalho

Ender~o IP de 32 bits da f ont e Ender~o tP de 32 bits do destino

Opções (se houver) Dados

Figura 4.13 Formato do dotogromo 1Pv4


A collloda de rede

l49

cl:nagr.una IP devem\ ser passada. Por exemplo. um valor 6 indica que a porç;\o de dados será passada ao TCP, enquanto um valor 17 indica que os dados scr:io passados ao UDP. Consulte (!ANA Protocol 1 umbcr, 2009) para ver urna lista de todos os valores possíveis. Note que o número do protocolo no datagrama IP tem um papel que ~ análogo ao do campo de nümcro de porta no segmento da cantada de transporte. O n(uncro do protocolo é o adesivo que liga as camadas de rede c de transporte. ao passo que o numero de pona é o adesivo que hga as camadas de transporte c de aplicação. Veremos no Capllulo 5 que o quadro de camada de enlace também tem um campo eSJ>CCial que hga a camada de enlace à camada de rede. Soma ele vrrifrcaçclo do cabcçcr/110. A soma de verificação do cabeçalho auxiha um roteador na detecção de erros de b1ts em um datagrama IP recebido. A soma é calculada trmando cada 2 bytes do cabeçalho

como se rossem um numero c somando esses mímcros usando complementos aritm~t icos de l. Como discutimos na Seção 3.3, o complemento de l dess;\ soma, conhecida como soma de vcriCiçae;lo da Internet, é armazenado no campo de soma de verificação. Um roteador calculará o valor da soma de verificação para cada d:nagrama lP recebido c dclcctara uma c:ondlc;;\o de erro se o valor da soma de verificação carregado no cabeçalho do datagrama m\o ror igual à soma de vcrificaçi\o calculada. Roteadores norm;lltncntc descartam datagramas qu:mdo um erro ~ clelcctado. Note que a sorna de vcrlfic:v;no deve ser rccalculadn c armazenada novamente em cada roteador, p<>is o campo TTL c, possivelmente, Hlrnb~m os campos de opcões podem mudar. Uma discussão imcressamc sobre algoritmos rápidos para calcular a soma de verificaç:lo da Internet~ encont rada em IRFC 10711 . Uma pcrgunu1 que sempre é feita nesse ponto é: por que o TCPIIP faz vcrH'icaç:1o de erro nas camadas de transporte c de rede? Há várias razões parJ. essa rcpetiç;lo. Em primeiro lugar, note que, na camada IP, a soma de verificação é calculada someme para o cal>eçalho IP, enquan1o no TCPIUDP a soma de vcriOcaçào é calculada para todo o segmento TCPIIP. Em segundo lugar, o TCPIUDP c o IP não prcc1sam necessariamente pertencer à mesma pilha de protocolos. O TCP pode, em princ1pio, rodar sobre um protocolo
cabeçalho sej:Hn us.1das raramente- por isso a dcdst\o de poup:tr sobrec;~rg:• m\o incluindo a inforrn:•ç:lo em campos de opções em todos os cabeç<~ lh os de datagrnm<~. Contudo, a mera exístencia de o pções. n:1 realidade, complica as coisas- uma vez que cabeçalhos de di\lagmmas podem ter comprimentos variáveis, n:lo ~ possível de terminar c1 prlorJ onde começam o campo de dados. AUm disso, uma vez que alguns dawgrnmas podem requerer process<~mcnto de opções c outros nilo, a quantidade de tempo necessária para processar um dat<~grama IP em um roteador pode variar basta nte. Essas considerações se tornam particularmente importantes para o processamento do IP em roteadores c hospedeiros de alto desempenho. Por essas c outras razões.
Duelos (arrgarltil). Fmalmcntc, chegamos ao ultimo c mais importante c;unpo- a ra%<1o de ser do data· grama! Em muilas circunstâncias. o campo de dados do datagrama IP contt'rn o segmento da camada de transporte (TCP ou UDP) a ser entregue ao deslino. Contudo. o campo de dados pode carregar outros tipos de dados, como mensagens ICMP (discutidas na Seçt\o 4.4.3). Note que um datagrama IP tem um total de 20 bytes de cabccalho (admitindo-se que n:lo haja OJXOcs). Se o da~agrama l.":lrrcgar um scgmemo TCP, ent:\o cada datagrama ( não rragmcntado) l.":lrrcga um total de 40 bytcs de cabeçalho (20 bytes de cabeçalho IP. mais 20 bytes de cabeçalho TCP) juntamente com a mensagem de camada de aplicação.


Fragmentação do datagrama IP Veremos no Capitulo 5 que nem todos os protocolos de camada de enlace podem tr.msporL(tr pacotes do mesmo tamanho. Alguns protocolos podem transportar datagramas grandes, ao passo que outros podem transportar apenas pacotes pequenos. Por exe mplo, quadros Ethcmet nâo podem conter mais do que l.500 b) tes de dados. enquanto quadros para 01lguns enlaces de longa distância mlo podem conter mais do que 576 bytcs. A quanudadc máxima de dados que um quadro de camadtl de enlace pode carregar é dcnonunada unidade máxuna de transmiSSt\o (mciXinumt tmnsmission unil- MTU). Como (.O.:tda datagramõl IP é cm.-apsulõldo dentro do quadro de camada de enlace para ser transportado de um roteador até o roteador seguinte, a MTU do protocolo de cama· da de enlace estabelece um limite estrito para o comprimento de um d:uagmma IP. Ter uma limilaç;'lo estrita para o tamanho de um dau1grama IP não é grande problema. O problema é que cada um dos enlaces ao lo ngo da rOla entre rcmeu:nte e destinatário pode usar diferentes protocolos de camada de enl:~ce, c cad:~ um desses protocolos pode ter d iferent es MTUs. P:1ra entender mel hor a questão do repasse. imagine que voa é um roteador qLtC est:\ Interligando diversos enlaces, cad:~ u m rodando diferentes protocolos de camada de enlace com diferentes MTUs. Suponha que vocé receba um clatagr:uua IP de um enlace, verifique sua tabela d~ repasse para determinar o c nl:~cc de S.'lfda c pcrceoo qu e esse enlace de sMd:~ tem urna MTU que é menor do que o comprimento elo dmagmma lP. t; hora de entrar em p:lnico- como voe~ v:ll comprimir esse daLagrama IP de tnman ho excessivo no campo de c:~ rga útil do quadro da camada de enlace? r\ soluç.lo pam esse problema é fragmentar os dados elo datagrama IP em dois ou mais dmagmmas IP menores c, então, enviar esses datagr:unas menores pelo enlace de saída. Cada um desses datagmmas menores é denominado um fragmento. Fr-.tgmcntos precisam ser reconstrufdos antes que cheguem i\ camadól de transporte no destino. ' a verdade. tanto o TCP quamo o UDP esperam receber da camada de rede segmentos completos, nao fmgmcmndos. Os projetistas do IP\•4 percebemm que a reconstrução de datagramas nos roteadores introduzina uma complicação significativa no protocolo c colocaria um freio no desempenho do roteador. (Se voe~ fosse um roteador, iria querer reconstruir fragmentos além de tudo mais que tem de fazer?) Seguindo o princfpio de manter a simplicidade do nllclco da rede. os projetistas do 1Pv4 dccidir.un nlocar a tarefa de reconstrução de datagr~nnas aos sistemas flnms, c n;lo aos roteadores da rede. Quando um hospedeiro destinatário recebe uma série de da~:~gmrnas da mesma fonte , ele precisa detcnninar se alguns dess<.>s datagmmas s.lo fragmentos de um d:llagrama original de maior tam:~nho. Se alguns desses dat:~gramas forem fragmentos. o hospedeiro ainda dever:\ detenmn:~r quando recebeu o último fragmento c como os fragment os recebidos devem ser rcconstrufdos para voltar à forma do dmagrama origin:~l. Pam permitir que o hospedeiro destinatário realize essas tarefas de reconstrução, os projetistas do IP (vcrsi\o 4) criaram rnmpos ele ldentíjicclçclo,flclg c cleslocamcnto de fmgmcntaç;\o no cabeçalho do datagmma LP. Quando um dmagratnt\ é criado, o hospedeiro remetente marca o datagrmna com um número de idcmiflcaç.\o, bem como com os endereços da fonte c do desti no. O hospedeiro remetente incrementn o número de idcntificaçi\o paro cada data grama que envia. Quando um ro teador precisa fragmen tar um clatagrama, cuda da tagrama res ult ante (isto é.lo.:tda fragmento) ê mur· <.-ado com o endereço da fome, o endereço do dcstiriO c o número ele ldentiOcaç~lo do datagroma original. Quando o destinatário recebe uma série ele d:Hagmmas do mesmo hospedeiro remetente, pode cx:~minar os mímeros de idcnt incação dos clatagramas para dctctminar quais deles são, na verdade. fragmentos de um mesmo clatagrnma de tamanho maior. Como o lP é um serviço n.l\o confiável, é possivcl que um ou m:tis desses fragmentos jamais cheguem ao destino. Por essa razão, para que o hospedeiro de destino fique absoluuuncntc seguro de que recebeu o ultimo fragmento do datagmma original, o último datagrama tem um bit de Oag ajustado para O. ao passo que todos os ou tros fragmcmos t~m um bit de Oag ajustado para 1. Além disso. para que o h ospedeiro destinatário possa determinar se está faltando algum fragmento (e possa reconstruir os fragmentos na ordem correta), o campo de deslocamento é us:tdo para especificar a localizaç-Jo exata do fr.tgmento no datagr.una IP original. A Figuro 4. H apresenta um exemplo. Um datagmma de 4 nu I b)•tes (20 bytcs de cabeçalho IP. mais 3.980 bytes de carga útil IP) chega a um roteador c deve ser repassado a um enlace com MTU de l.500 bytes. Lsso implica que os 3.980 bytcs de dados do datagrama original devem ser aloe:~dos a tr~ fragmemos separados (cada qual é também um datagrama IP) . Suponha que o datagrama original esteja marcado com o número de


A
2.S1

Fragmentaçio: Entrada: um datagrama grande (4.000 bytes) Saída: três datagramas menores

Re
Figura 4.14 Frogmentosõo ere
Fragmento

Bytes

lO

Deslocamento

Flag

I• frogmenJo

1.480 bytes oo compo de dodos do dotogromo IP

illentific.oçõo =777

deslocamento :; O(o que signifiCo que os dados devem ser i11se1idos o pcwtir do byte 0)

que hó mois)

2• frogmenJo

l.480 bytes de lblos

idenlifiCOÇÕO

=777

deslocamento = 185 (o que sigMi
que hó mois)

3t frogmenlo

1.020 bytes de dodos <·3.980 -1.480 -1.480)

idenlíficoçõo = 777

deslocomenlo =370 (o que significo que 05 dodos devem ser Jtseridos o(l011ir do byte 2.960. Nole que 370 x8 2.960)

Tabela 4.2 Fragmentos IP

Oog =I (o que significo Oog =I (o que significo

flog = O(o que sigllilico que esse é o~ frog-

mento)


ln;.;l~e;.;rn;.;e;.;.t_________________________

estranhos e inespcrndos. Um exemplo dt\ssico é o ataquejolt2, no qual o a t:~cantc envia uma cadeia de pequenos fragmentos para o computador-alvo, nenhum dos quais tem um deslocamento de zero. O alvo pode se recolher ao tentar reconstrUir datagramas pelos pacotes degenerados. Urna oULr:l classe de cxplorts envia sobreposição de fragmentos IP. ou SCJa. fragmentos cujos \';dores de deslocamento s;lo definidos para que os fragmentos n;\o se alinhem corretamente. Sistemas operacionais vulneráveis, sem saber o que fazer com a sobreposiç.\o de fragmentos, podem pifar (Skoudis, 20061. Como veremos no final desta seç;\o. uma no\'a vers;lo do protocolo IP. o 1Pv6, põe fim por completo à rragmentação. o processamento do pacote IP e LOmando o IP menos wlneravcl a ataques. No sitc Wcb deste lhrro aprcsem;tmos um applet Java que gera fragmentos. Basta informar o tamanho do datagrama que está chegando. a MTU c a idcmificação do datagrama. c o applct gera automaticamente os fragmentos paro vocc. Veja ht t.p : 1/www. aw. com/ ku r ose_br.

4.4.2 Endereçamento 1Pv4 Agor:t voltaremos nossa :ucn~'ào ao endereçamento 1Pv4. Embora vocC: talvez esteja pensando que o endcreçumcnto seja um tópico descompli(."11do, esperamos que. no fina l deste caprtulo, voe~ se convença de que o endereçamento na Internet não é apenas um tópico rico, cheio de sutilezas c interessante, mas também de crucial importOncla para a Internet. Trammemos excelentes do endereçamento 1Pv4 podem ser encontrados em I3Com Addressi ng, 20091 c no primeiro capitulo de (Stcwan. 1999]. Antes de discutirmos o endereçamento IP, contudo. temos de falar um J>OUCO sobre como hospedeiros c roteadores estão interconec~:~dos na rede. Um hospedeiro normalme nte tem apenas um unico enlace com a redl'.

Quando o IP no hospedeiro quer enviar um datagrama, ele o faz por meio desse enlace. A fronteira emre o hospc· deiro c o enlace rrsico é denominada interface. Agora considere um roteador e suas interraces. Como a tarda de um roteudor é receber um datagrama em um enlace c repassá-lo a algum outro cnlt~cc, ele necessariamente estará ligado a dois ou mais enlaces. A fromcira entre o roteador c qualquer um desses enlaces também é denominada uma interface. Assim, um roteador tem múltiplas interfaces. uma para cada um de seus enlaces. Como todos os hospedeiros e roteadores podem enviar e receber datagramas IP, o IP exige que cadr~ interface tenha seu próprio endereço IP. Desse modo, um endereço IP está tecnicamente associado com uma amerrace, c não com um hospedeiro ou um roteador que conttan :~qucla interface. Cada endereço IP tem comprimento de 32 bíts (equivalente a 4 bytes). Portanto, há um total de 2n ende· reços IP possíveis. Fazendo tlma aproximação de 2 '~ por 10), e fácil ver que há cerca de .f bflhOcs de endereços IP possíveis. Esses endereços st\o escritos em n otação decim al separad a por pontos (doucd·dccimnlllOinrion), na qu:al cada bytc do endereço e escrito em sua forma decimal c s eparado dos outros bytcs do endereço por um ponto. Por exemplo, considere o endereço IP 193.32.21C>.9. O 193 é o n~lmcro decimal equivalente aos primeiros 8 bits do endereço; o 32 é o decimal equivalente ao segundo conjunto de 8 bi ts do endereço c assim por di
bow4tto4ic~ Capitulo •

A u11oda de rede

2.53

223.1. 1. 1 223.1.2.1

223.1 .1.2

223.1.1.3

223.1.3.1

223.1.3.2

Figura 4.1S Endereços de interioces e sub-fedes denominada uma JTdr IP ou simplesmente uma rcclc). O cndcrcç:uncnto IP dcsign~ um endereço a css;1 sub-rede: 223.1.1.0/24. no qual a nouu;M /24, às vezes conhecida como uma máscara de rede, indica que os H bit5 mais à esquerda do conjunto de 32 bits definem o endereço da sub-rede. Assim, a sub-rede 223.l.l.0/24 consiste em rrês interfaces de hospedeiros (223.1.1.1, 223.1.1.2 c 123.1.1.3) e uma interface de rot~dor (223.l.l.4). Quaisquer hospedeiros adicionais ligados à sub-rede 223.1.1.0/24 seriam obrigados a ter um endereço na forma 223.1. L.xxx. Há duas sub-redes adicionais mosuadas na Figura 4.15: a sub-rede 223. l.2.0/24 c a sub-rede 223.1.3.0/24. A Figura 4.16 ilustra as trts sub-redes IP presentes na Figura 4.15. A dcfiniçlo IP de uma sub-rede não está restrita a segmentos Ethcrnct que conectam muhiplos hospedeiros a uma Interface de roteador. P;~ra entender melhor isso. considere a Figura 4.17. que mostra tres roteadores imerconectados por enlaces ponto a ponto. Cada roteador tem trts interfaces. uma para cada enlace ponto a ponto c uma para o enlace bJoculwst que conccta diretamente o roteador a um par de hospedeiros. Que sub-redes lP estão presentes :~qui? Tr~ sub-redes, 223.1.1.0/14. 223.1.2.0/14 c 223.1.3.0/24, scmclh:~mcs às sub-redes que

-

223.1.1.0124

223.1.2.0124 -

/223.1.3.0/24

Figura 4.16 Endereços de sub-redes


223.1.1.1

223.1.1.4

223.1.2.6./'"

223.1.2.1

223.1.2.2

223.1.3.1

223.1.3.2

Figura 4.1 7 Três roteollores ínterconectondo seis su!Hedes encontramos na Figura 4.15. Mas note que também há t r~ sub-redes adicionais nesse exemplo: uma sub·rcde. 223. 1.9.0/24, para as imcrfaces que conectam os roteadores RI c R2; o utra sub-rede, 223.l.S.On4. para as interfaces que conectam os roteadores R1 c R3. e uma terceira s ub-rede, 223.1.7.0n4. para as mterfaces que conectam os roteadores R3 c Rl. Para um sistema gcraJ intcrconcctado de roteadores c hospedeiros. podemos usar a seguinte receita para definir as sub-redes no sistema.

Pcu·a clctcmwwr as srtb-ndes, destaque cada inlelfacc de seu lrosr,cclclro ou rotwclor, crimrclo illws de rrdes isoladas com inurfacrs fechando crs ltmrinaçócs cltrs r'tdts isolculcts. Cacla uma tlcs as redes isoladcrs é tlrnominatla sub-rede. Se aplicarmos rssc procedimento ao sistema interconectado da Figura 4. 17, !Cremos sers ilhas ou sub-redes. Fic-.1 claro, com cssn discuss;\o, que uma organizaç;lo (tal corno umôl empresa ou instituiç;lo academi~•) que lenha v:\ rios segmentos Ethemet c enlaces ponto a poruo tcrà várias sub-redes, c todos os equipamentos e disposi ti· vos em urna dada sub-rede terão o mesmo endereço de sub-rede. Em princípio, as d iferentes sub-redes poderiam ter endereços bem di rcrentes. ê ntretanto, na prática. os endereços de sub· rede frcquentcrncru e t~ tn muito em comum. Para entender por que, voltemos nossa aten~-:.io ao modo como o endereçame nt o~ mnnipulado na Internet globaL A estmtégia de atribuição de endereços da Internet é conhecida como roteamento interdomlnio s-em elas~ scs (clctsslcss inlerdomctin routing- CID R), que se pronuncia como a palavra cidcr (cidra) em inglês IRFC 46321. O CID R gcner-.tliza a noç;lo de endereçamento de sub-rede. Como acomccc com o endereçamento de sub-redes, o endereço IP de 32 bits é divtdido em duas panes c, mais uma vez. tem a forma decnnal com pontos de separação a.b.c.cllx, em que x indica o número de bitS existentes na primeira parte do endereço.

O.. x bitS mais significativos de um endereço na forma a.b.c.cl!x consutucm a parcela da rede do endereço IP c normalmente s\o denominados prd'lXO (ou prefL'

A co11oda de rede

2.55

quar1do tun rou~ador ele fora da organização repassar um d
=

Serramos Otmssos se não mencron:\sscmos ainda um outro tipo de endereço lP, o endereço de broodcast 255.255.255.255. Qu:mdo um hospedeiro emite um datagmma com endereço de dtstino 255.255.255.255, a mensagem é entregue a Lodos os hospedeiros na mesma sub-rede. Os roteadores também têm a opção de repassar a mcnsugcm para suas sub-redes vizinhas (embora usualmente ni\o o façam .) Agora que jo1 cslmlamos o cndereçamcnlo IP dctalh;tdamcnte, precisamos s:tbcr, antes de qualquer coisa, como hospedeiros c sub-redes ob1~111 seus endereços. Vamos começar cx:unlnando como uma organiza~'ào obtém um bloco de endereços para seus equipamentos e, cmão, veremos como um e:
Obtenção de umbloco de endereços Pam obter um bloco de endereços 1P pam utilizar dentro d<1 sub-rede de uma organiz:1Ç':lo, um administrador de rede poderia, em primeiro lugar, contatar seu ISP. que romeceria endereços a partir de um bloco maior de endereÇOS que já cst:lo alocados ao lSP. Por exemplo, o próprio lSP pode ter recebido o bloco de endereços 200.23. 16.0120. O ISP, por sua vez, pode dr,•idir seu bloco de endereços em oito blocos ele endereços contiguos, do mesmo tamanho, c dar um desses blocos de endereços a cada uma de um conjunto de oho org.ulrZll\'ÕCS su1>0rtadas por ele. <:omo demonstrado a seguir. (Sublinhamos a parte da sub-rede desses endereços para melhor visualizaçào.) Bloco do ISP

200.23.16.0120

I !OO!QQQ QQQ!O ! 11 00010000 00000000

Orgamzaçào O

200.23. 16.0123

1100100Q OOQlOlll OOQJQOQO

Organização 1

200.23.18.0123

I JOOJQQQ QQQ!O! li OOQlOOJO 00000000

Orgamzação 2

200.23.20.0/23

!IOO!QQQ QQQ1011 I 00010100

00000000

Organização 7

200.23.30.0123

11001000 00010111 00011110

00000000

00000000


Embora a obtcnçM de um conjunto de endereços de um ISP seja um modo de conseguir um bloco de endereços, não é o unico. E'•idcmememe. também deve ha,·er um modo de o próprio LSP obter um bloco de endereços. Há uma autoridade global que tenha a responsabilidade final de gerenciar o es paço de endereços IP c alocar blocos de endereços a ISPs c outr;\S organiz:l<;Ocs? ~ claro que há! Endereços IP sâo administrados sob a autoridade d;l Internet Corporation for Assigncd Namcs and :'>lumbcrs (lCANN) llCA 'N. 20091. com base em diretrizes esta· belccidas no RFC 2050. O papel da ICAN 1 , uma organizaç;.\o sem fins lucrativos [NTIA. 19981. m\o é someme alocar endereços IP, mas também adminisrrar os servidores de nome r:uz (DNS). Essa organizaç:lo também tem a controvertida tarda de atribuir nomes de domínio c resolver dlspums de nomes de domínio. A ICANN aloca endereços a serviços regionais de registro da Internet (por exemplo, AR IN, RlPE, APNIC e L.ACNIC), que. juntas, formam a Addrcss Supportlng Organization da ICANN (ASO-ICANN, 2001. c é rcspons.1vcl pela alocação/ administração de endereços dentro de suas regiões.

Eue exemplo de um ISP que conecto o ito organizac;õe~ com o Internet também ilustra de maneira elegante como endereços 'ciderizodos' cuidodosomenle alocados facilitam o roteamento. Suponho, como mostro o Figuro 4. 18, que o ISP (que chamaremos de ISP Fly·By.Night) anuncie ao mundo exterior que devem ser enviados o ele quaisquer dotogromos cujos primeiros 20 bits de endereço sejam iguais o 200.23.16.0/20. O resto do mundo nõo preciso saber que dentro do bloco de endereços 200.23.1 6.0/20 existem, no verdade, oito outros organizações. codo quol com suos próprios sub-redes. Essa copocidode de usor um úníco prefixo de rede poro anunciar vórios redes é frequentemente denominado og.regação de endereços (e também agregação de rolas ou resumo de rolas). A ogregoçõo de endereços funciono muito bem quando os endereços sôo alocados em blocos ao ISP e, entôo, pelo ISP às organizações clientes. Mos o que acontece quando os endereços nõo sõo alocados deuo maneiro hierárquico? O que aconteceria, por exemplo, se o ISP Fly·By-Night adquirisse o ISPs-R-Us e entõo ligasse o Organização 1 com o Internet por meio de suo subsidiário ISPs-R.Us? Como mostro o Figuro 4.18, a subsidiário ISPs-R-Us é dono do bloco de endereços 199.31.0.0/16, mas os endereços IP do Orgonizoçõo 1 infelizmente estõo foro desse bloco de endereços. O que deveria ser feito nesse coso? Com certeza, o Orgonizoçõo 1 poderio renumerar todos os seus roteadores e hospedeiros poro que seus endereços ficassem dentro do bloco de endereços Organizaçlio O 200.23.16.0123 Organizaç:!o 1 200.23.18.0123

Organizaçao 2 200.23.20.0123

~

·envie-me quaisquer

pacotes cujos endereços

~

comecem com 200.23.16.0120"

tSP Fly-By-Night

~ Internet

Organizaçao 1 200.23.30.0123

----

--

·envíe-me quaisquer pacotes cujos ender~os come
Figura 4.18 Endereçamento hierárquico eogregoçõo de rotos


A u11oda de rede

2.57

Organizaçlio O

200.23. 16.0123 Organizaçlio 2

200.23.20.0123

~

·envie-me quaisquer pacotes cujos endereços comecem com

~

-

200.23.16.0120.

Organizaçlio 7 ___..;--- ISP Fty-8y-Night

200.23.30.0123

•envie-me quaisquer pacotes cujos endereços Internet comecem com 199.31.16.0/16 ou

Organizaçlo 1

---

200.23.18.0/23.

200.23.18.0123 - - ISPs-R-Us

Figura 4.1 9 ISPs·R·Us tem uroo roto mois específico pa10 oOrgonizoçõo 1 ê umo solução dispendioso, e o Orgonizoção 1 poderio muito bem preferir mudar poro umo outro subsidiário no futuro. A solução normalmente adotada é a Organização I manter seus endereços IP em 200.23.18.0/23 . Nesse ca$0, como mo~rro o Figuro .4 19, o ISP Fly·By-Night continuo o onuncior o bloco de endereços 200.23.16.0/20 e o ISPs-R-Us continuo o onuncior 199.31.0.0/ 16. Contudo, o ISPs-R-Us ogoro anuncio também o bloco de endereços poro o Otgonizoção I , 200.23.18.0/23. Quando outros roteadores do Internei virem os blocos de endereços 200.23.16.0/20 (do ISP Fly-By-Night) e 200.23. 18.0/23 (do ISPs-R-Us) e quiserem roleor poro um endereço no bloco 200.23.18.0/23, usarão o regra de compotibilizoção com o prefixo mois longo (veja Seção .4.2.2) e roteorõo poro o ISP-R-Us, já que ele onuncio o prefixo de endereço mais longo do ISPs..R-Us. Mos euo

(mois específico) que combino com o endereço de destino.

Obtenção de um endereçode hospedeiro: o Protocolode Configuração Dinâmico de Hospedeiros (DHCP) T:\o logo tenha obtido um bloco de endereços, uma organtzaçi\o pode atribuir endereços IP individuais àS intcrraces de hospedeiros c roteadores em sua organiz.a~-ão. Norm;-~lmcntc um administrador de sistemas configuram manualmente os endereços IP no roteador ( muitas vezes remotamente, com urna ferramenta ele gerenciamemo de rede). Os cndcre\OS dos hospedeiros podem wmbém ser configurados m:mmllmente, mas essa tarefa é feita geralmente usando o Prot~olo de Configuração Diní\mica de Hospedeiros (D HCP) (RFC 21311 . O DHCP permue que um hos pedeiro obtenha (ser alocado) um endereço IP :mtommíca mente. Um acJministrador de rede pode conngl&rar o DHCP cJe modo que tun determinado hospedeiro receba o mesmo endereço lP toda "ez que se conectar il rede, ou um hospedeiro pode receber um endereço IP temporário diferente sempre que se conectar il rede. Além de receber um endereço IP tempomrio, o DI-I CP também pcrmhc que o hospedeiro descubra informações adicionais, como n máscara de sub-rede, o endereço do primeiro roteador (comumente chamado de pona de comunicaç-lo padrão- clcfcwlt gatcwny) c o endereço de seu servidor DNS local. Por causa de stt.t capacidade de automatizar os aspectos relativos à rede d;-~ conexão de um hospedeiro à rede, o DIICP é comumente denominado um proto colo plug and play. Essa capacidade o torna muito atraente para o administrador de rede que, caso contrârio, teria de executar essas tarcf:15 manualmente! O OI ICP também está conqmstando ampla uuhzação em redes residenciais de acesso à Internet c em LANs sem fio, nas quais hospedeiros entram e saem da rede com frequênda. Considere, por exemplo, um estudante que leva seu lapwp do seu quarto para a biblioteca, para a sala de aula. É provável que ele se conectará a urna nova sub-rede em cada


um desses lugares e, por conseguinte, precisará de um oovo endereço IP em cada um deles. O DHCP ~Ideal para essa silUação. pois há muitos usuários em trânsito c os endereços são ulilizados apenas por um tempo limitado. O DHCP é, de ma neira semelh ante, útil em redes d omésticas de acesso. Como exemplo, considere um ISP residencial que tem dois mil clientes. porém, nunca mais de -KX> deles estão on· line ao mesmo tempo. O ISP não pree1s.'l de um bloco de dois mil endereços para administrar todos os seus dois mil dicmes - usando um servidor DllCP para designar endereços dinamicamente, ele precisa de um bloco de apenas 5 12 endereços (por exemplo. um bloco da forma a .b.c.dl23). À medida que hospedeiros entram e saem da rede, o servidor DHCP preds."' atualizar sua llsl:l de endereços IP dlsponfveis. Toda vez que um hospedeiro se conectar à rede, o servidor DHPC designa a ele um endereço arbitrário do seu reservatório corrente de endereços disponfveis: toda vez que um hospedeiro sair, o endereço é devoh•1do ao reservatório.

O DHCP é u m protocolo cliente-servidor. ' ormalmente o cliente é um hospedeiro recém-chegado que quer obter informações sobre con llgura~·ào da rede, incluindo endereço IP, para si mesmo. Em um caso mais simples, cada sub-rede (no sentid o ele endereçamento na Figura 4.17) terá um ser,,idor DHCP. Se nenhu m servidor estiver prese nte nu sub· recle. ~ necessário um agente reli! DHCP (normalmente um roteador) q ue s;tbc o endereço de um sen •idor OliCP para tal rede. A Figura 4.20 illlStfllum se rvidor DHCP concct;-tdo à rede 223. 1.2/.H, servindo o ro teador de agente reli! para clientes que ch egam conectados às s ub -rcdcs 223.1. 1124 c 223.1.3124. Em nossa discussão ab
Drscobcr w do servidor DHCP. A primeira ta refa de um hospedeiro recém -chegado ê encoru.rnr um servidor DI ICP com quem interagir. Isso é feito ulilizando uma mensagem de dc:.coberta DHCP. a qual o cliente em••a dentro de um pacote UDP para a porta 67. O pacote UDP ~ e•wolv1do em um datagrama IP. Mas paro quem esse datagrama d eve ser enviado? O hospedeiro não sabe o endereço IP da rede à qual es tá se conectand o, mui1o menos o endereço de um servidor DI ICP para essa rede. Desse modo, o

servidor

DHCP

223.1.2.5 223.1.1.1

223. 1.1.4"

223.1.2. 1 '-.. 223.1.3.27

223.1.1.2

Clíent e

DHCP re<ém-chegado

223.1.2.2 223.1.1.3

223.1.3. 1

Figura 4.20 Tradução de endereço de rede

223. 1.3.2

bow4tto4ic~ ~

Capítulo

A ur~oda de rede

l .S9

Servidof OHCP 223.1.2.5

OM<:obetla DH(P R~m: 0.0.0.0,68 Ot1t: 255.255255.255, 67 OHCPOISCOVER yladdr: 0.0.0.0 ID lt~IO: 654

Oferta OHCJ> Rem: 223.1.2.5.67

Ot$l: 255.255.255.255, 68 OHCPOffER yiaddrr: 223.1.2.4 10 trans,;,~ao: 654 .... lO !eMdor DHCP: 223.1.2.S ;.;R.:;t_ _----, Vida útil: 3.600 seg

Rem: 0.0.0.0.68 Ot11: 255.255.255.255. 67 OHCt>REOU EST yiaddrr: 223.1.2.4

10 uansaç~: 655 ID setvidor OHá>: 223.1.2.5 Vida útil~ 3.600 seg_

OHCJ> ACK Rem: 223.1 .2.5, 67 oen: 255.255.255.255, 68 OHCPACK y~ddlr: 223.1.2A 10 uaosaç:lo: 655 I> servidor OHCJ>: 223.1.2.S Voda lhil: 3.600 seg

-.....: Tempo

Figura 4.21

Tempo

Interação diente-se!Vidor DHCP

clíerue DIICP cria um datagrnma IP conlendo sua mensagem de descoberta DIICP com o endereço lP de destino de 1mnsmi~o 255.255.255.255 c um endereco IP destinmário "desse hospedeiro" 0.0.0.0. O cliente DIICP transmite o datagrarna IP à camada de enlace que, então, transmite esse quadro para todos os nós conectados à sub-rede (discutiremos os detalhes sobre trnnsmiss.lo da camada de enlace na Seção 5.4). Ojr.-w(s) dos scrvitlor·rs DJ-ICP. Um servidor OHCP que recebe uma mens agem de descoberta DHCP responde ao c lieme com uma mensagem de oferta DHCP, trans mitida a todos os nós presentes na SLtb· redc, novamente utilizando o endereço IP de Lransmiss;lo 2'55.255.255.255. (Você pode pensar por que essa resposta do servidor pode ser rrnnsmitidn). Como diversos sen •idores DHCP podem estar presentes na sub-rede, o cliente pode se dar ao luxo de escolher demre as muitas ofertas. Cada mensa· gem de oferla do servidor eont~m o lO de transaç;\o da mensagem de dcscobcn:1 recebida, o endereço IP proposto para o cliente. a máscara da rede c o tempo de concessão do endereço IP- o tempo pdo qu~1l o endereço IP ser;\ válido. É comum o scn•idor ddimr o tempo de conccs~1o parn V
bow4tto4ic~ Redes de co 11 putod ores e o Inle r.;;n.;;,e;.. l -----------------------Uma vez que o cliente recebe o DHCP ACK, a ínteraç;\o t conclufda c etc pode us:u o endereço IP alocado pelo DHCP pelo tempo de concessão. Caso o cliente queira usar seu endereço após a expimç:\o da concessão, o DHCP também fornece um mecanismo que permite que o dienu~ renove sua concessào sobre um endereço IP. O \-alor da capacrdade tJiug anlltJiay do DHCP é clara, consrdemndo o fmo de que a alternativa é configurar manualmente um endereço IP do hospedeiro. Considere o aluno que se Iocomove da sala de aula para a biblioteca até seu dormitório com um laptop, entro em uma no'-a sub-rede, obtendo. assim, um novo endereço IP em cada local. Ê innnagmá,•el que um admmistrador de sistema tivesse de reconfiguror laptops em cada local, e poucos alunos (exceto os que csu\o tendo aula de rede de compmadorcs!) teriam a habilidade de configurar seus laptops manualmente. Entretanto, panindo de um aspecto de mobilidade, o DHCP possui desvnmagens. Uma vez que um novo endereço IP é obtido de um novo DHCP toda vez que um nó se conecta a uma nova sub-rede, uma conexilo TCP para uma aplicaç:lo remota não pode ser mantida pois o nó móvel se locomove entre as sub-redes. No Cap1tulo (>, nn:~lisaremos o lf> móvel- uma c.-.:tensâo recente paro a infraestrutura IP que permite que um nó móvel utilize um único endereço permanente à medída que se: locomove entre as sub-redes. Mais detalhes sobre o OHCP podem ser encontrados em [Droms, 20021 c [dhc, 2009) . Uma implcmcntaçilo de refer~ncia de cód igo-fon te aberto do DIICP está d isrX>nl vcl em lntemct Systcm Consortiurn IISC, 2009).

Tradu~õo de endereços na rede (NAT) Dada a nossa discussão sobre endereços de Internet c o formato do datagramn 1Pv4, agora estamos bem cien· tes de que todo equipamento que utilir.~ IP precisa de um endereço IP. Isso aparentemente signlnca que, com a prollfemç;lo de s ub-redes de pequenos escritórios e de escriLórios residenciais (suwll offla lromc offlu- SOHO), sempre que um desses escritórios quiser instalar uma LAN para conectar várias máquinas, o ISP predsará alocar uma faixa de endereços p:~ra atender a todas as máquinas que usam IP do escritório em questão. Se a sub-rede flcasse maior ( por exemplo, as crianças da cas:t não somcmc ti:m seus próprios comput:\dores, mas também compraram PDAs. telefones com LP e jogos Game Boys em rede), seria preciso alocar um bloco de endereços maior. Mas. c se o ISP Já uver alocado as porções contíguas da faixa de endereços uulrzada atualmente por esse cscritóno residencial? E. antes de mais nada, qual ~o proprielário trpico de uma residencia que quer (ou precisaria) saber como administrar endereços IP? Felizmente, há uma abordagem ma is simples da alocação de endereços que vem conquistando um;t utilização cada vez mais ampla nesses tipos de cenários: a tradução de ende reços de r ed e (network a ddress rmnslarion - NAT) (RFC 2663; RFC 30221. A Figura 4. 22 mosLra a opera~'ào de um roteador que uLilizn NAT. Esse roteador, que fica na res idência do ddadão, tem uma interface que faz pane da rede residencial do lado direito da Figura 4.22. O endereçamemo dentro da rede residencial é exatamente como vimos anteriormente - tod:~s as quatro Interfaces da rede u~m o mesmo endereço de s ub-rede, IO.OO.On4. O espaço de endereço 10.0.0.018 ~ umo das tr~ porções do espaço de endereço IP reservado pelo IRFC 19181 para uma rede prh,ada, ou um do mínio com endereços privados, tal como a rede residencial d" Figuro .... 22. Um ,lomCuio com t>mlt·r·eços l"'iva(los refere-se :1 uma rede cujos endereços somente t~m slg•lincado p:tra equipamentos pertcnce,ntcs àquela rede. Para ' 'C r por que isso ~ hnportantc, considere o fato de haver cerneuas de mi lhares de re-des residenciais, muitas delas utilizarHio o mesmo espaço de endereço 10.0.0.0124. Eq uipamemos que pertencem a urna determinada rede residencial podem enviar pacotes emre si mlllzando o endereçamento lO.O.O.On4. Contudo, é claro qu e pacotes repassados da rede residencial para a Internet glob.tl nilo podem usilr esses endereços (nem como endereço de rontc, nem como endereço de destino) porque há centenas de milhares de redes utilizando esse bloco de endereços. Isto cf, os endereços 10.0 .0 .0/2.. so mente podem ter significado denlro daquela rede residencial. Mas, se endereços privados tem significado apenas dentro de uma dada rede, como o endereçamento é administrado quando pacotes são recebidos ou cm•iados para a Internet global, onde os endereços são necessariameme exclusivos? A rcsi>OSta será dada pelo estudo da NAT. O roteador que usa NAT niio partu um roteador para o mundo ex terno, pots se comporta como um equi· pamcnto unico com um unico endcrc('o IP. l'a Figura 4.22. todo o tráfego que sai do roteador residencial para a Internet tem um endereço IP de fonte l38. 7õ.29.7, e todo o trá fego que entra ness.1 rede tem de ter endereço de destino 138.76.29.7. Em essencia, o roteador que usa NAT está ocultando do mundo exterior os detalhes da rede residencial. (A propósito, você talvez esteja imaginando onde os computadores de red es residenciais obtêm seus endereços e onde o roteador obtém seu endereço IP exclusivo. A resposta é quase sempre a mesma - DHCP!

bow4tto4ic~ A u11oda de rede

Capítulo •

261

Tabela de traduçâo NAT LadodaWAN 138.76.29.7, 5001

...

lado da LAN 10.0.0.1, 3345

...

334~~

S-1• 10.00.00.1. 0-·128.119.40.1~

cb ,....10.0.0.4

, 38.76.29.7

sVontt). 128.119.40.186.·~~~

01Dt"'"""•138.76.29.7. ~

SVontt1•128.119.40.186.~ ~

o lllfll~n.o~ • 1o.o.o.1. n4s,_J

Figura 4.22 Troduçõo de endereços de rede O roteador obtém seu endereço do servidor DHPC do ISP c roda um servidor DHPC para rorncccr endereços a computadores que estão dentro do espaço de endereços NAT da rede residcnci:~l comrolado pelo OHCP). Se todos os d:llagrnmas que chegam ao roteador I'AT pro,•eniem es da WAN tiverem o mes mo endereço IP de desuno (cspcc•lkamcnte. o endereço da Interface do ro teador NAT do lado da WAN). então como o rotc:1dor sabe p:1rn qual hospcde1ro in terno deve repassar um dado datagrnma? O truque t utilizar uma tabela de tradução NAT no roteador NAT e incluir nos registros da tabela números de portas, bem como endereços IP. Considere o exemplo da Figurn 4.22. Suponha que um usuário que está utilizando o hospedeiro 10 .0.0.1 da rede rcs1dcncial requisite uma página Web de :1lgum servidor Wcb (porta 80) cujo endereço IP t 128.119.40. 186. O hospedeiro 10.0.0.1 escolhe o numero de porta de fon te (arbitrário) 33-+5 c envia os clatagrnmas parn dentro da LAN. O roteador 11\T recebe o datagrama, gera um novo número de pona de fome, 500 1, parn o d:uagrama, substitui o ende reço IP da ro111c por seu endereço lP do lado da WAN, 138.76.29.7, c substitui o numero de porta de fonte original, 33-15, pelo novo mhncro de porta de fome, 500 l . Ao gerar um novo m\mero de porta de fon te. o ro teador NAT pode selecionar qualquer nümcro de porta de fonte que não esteja correrHernent c na tabela de tra· duç:lo NAT. (Note que, como o com primemo de um campo de m1mcro d e porw é 16 bils, o protocolo NAT pode suportar mais de 60 mi l conexões si multâneas com um únil.:o endereço lP elo lado da WAN para o roteador!). A NAT no roteador tambt m adi ciona um rcgisu o à sua tabda de traduç;lo NAT . O servidor Wc b, totulmcntc al heio ao fato de que o dmagrama que es tá chegand o com uma rcquisi~i\o HITP foi manipulado pelo roteador NAT. responde com um datagrnma cujo endereço de destino é o endereço IP do roteador NAT, c cujo numero de porta de destitto é 5001. Qunndo esse d;uagrnma chega ao roteador NAT. o roteador iudcxa a tabela ele trnduç;'\o NAT us:~ndo o endereço IP de destino e o número de porta de des tino p;~ra obter o endereço IP ( 10.0.0.1) c o número de J>Ort.'l de destino (3345) adequados parn o browscr na rede residencial. O roteador cutt\o recscrc,·e o cnMrcço de destino e o numero de porta de destino do datagrama e o repassa para a rede residencial. A KAT conquistou ampla aceitação nos últimos anos. Mas devemos mencionar que muitos puristas da comun idade da IETF t~m grnndes restnções à NAT. Em primeiro lugar. argumentam. a Onalidade dos nllmeros de portas é cndercçnr processos. c não hospedeiros. (Real mente. a violação dessa regrn pode causar problemas parn sen•idorcs que rodam em redes res1denciais, pois. como vimos no Capitulo 2, processos servidores esperam pela chegada de requisições em números de portas bem conltccidos.) Em segundo lugar, argumentam que roteadores d evem processar pacotes somente até a camada 3. Discutem, em terceiro lugar, que o protocolo NAT viola o argumento denominado fi m a fim; isto é, hospedeiros devem falar diretamente uns com os outros, sem a interferência


de nós que modifiquem cndcrc~·os IP c nümeros de portas. E, em quarto lugar, argumentam que de,crfamos usar o 1Pv6 (veja Scçilo 4A.4) pam resolver a escassez de endereços lP, c nilo tentar resolver o problema imprudentemente com uma soluç:lo tempor:iria como a NAT. Mas, gostemos ou nilo, a NAT tornou-se um componente im portante da Internet. Outro problema imponante da 1 ATé que ela interfere com aplicações P2P. incluindo aplicações de compartilhamento de arquivos P2P c aplicações de voz sobre IP. Lembre-se de que. no Capitulo 2. dissemos que, em uma aplicação P2P, qualquer par A partici pante deve poder iniciar uma conexão TCP com qualquer outro par B participante. A css~ncia do problema é que, se o par B esti ver por tras de uma NAT, não poderá agir como um servidor e aceitar concxMs TCP. Como \'cremos nos problemas de fixa(ão, essa questão da NAT pode ser comornada se o par A se conectar primeiramente com o par n através de um par C imennediário que não está por trás de uma NAT c com o qual o par B tenha estabelecido uma conexão TCP que está em curso. EntãO. o p:tr i\ pode solicitar ao pm B. por intermédio do par C, que inicie uma concx;\o TCP diretamente com ele. Uma vez estabelecida :1 concxM P2P TCP direta entre os pares A c B. os dois podem troc:tr menS
UPnP A travessia da NAT tmversal estã sendo cada vez mais rornccida pelo Unh•t·rsal Plug aucl Play ( UPnP), um protocolo que permite que um hospedeiro descubra e configure uma NAT próxima IUPnP Forum, 20091. O UPnP exige q ue o hospedeiro e(\ NAT sejam compatí\'eis com ele. Com respeito ao UPnP, um;~ aplic.1ç;\o que roda em um hospedetro pode solicitar um mapeamento da NAT entre seus (nulcrcço IP fHirtlcular, mimrro ele 11or1a JXUikulm) c (rmlc1c(o IP publico, mcmtro de /JOI1<1 p•ibliccr) pam algum nümcro de porta pública requisitado. Se a NAT aceitar a requisiç:io c criar um mapeamento, en tão nós externos podem iniciar conexões TCP para (cmdereço IP publico, numero e/r po1ta publica). Além disso. o UPnP deixa a aplicação saber o valor de (emlm·co IP ptiblico, numero ele /JOita publiw), de modo que ela possa anunciá-los ao mundo externo. Como exemplo. suponha que seu hospedei ro, locaUzado atrás de uma NAT com o UPnP habilitado, possua o endereço IP parucular 10.0.0. 1 e esteJa rodando o BitTorrent na porta 3345 Suponha também que o endereço IP publico da AT seja 138.76.29.7. Sua aplicaç-.lo BitTorrent naturalmente quer poder aceitar conexões vindas de outros hospedeiros. para que blocos sejam adquiridos atra,•és delas. Para isso. a aplícaç:'lo BitTorrent. em seu hospedeiro. solícita a NAT para criar uma "abertura· que mapeia (10.0.0. 1. 33'15) para (138.76.29.7, 5001). (A porta publica mimero 5001 é escolhida pela apliç;.lçào.) A aplicaç:\o BilTorrent em seu hospedeiro poderia, também, anunci;~r ao seu rastrcador que escá disponível em (138.76.29.7, 50011. Desta maneira, um hospedei ro externo que está rodando o BitTorrcnt pode contatar o rastreador c d escobrir que s ua apl ic-a~-:lo BítTorren t está rodando em (138.76.29.7, 5001). O hos pedeiro externo pode eawiar um pacote SY TCP para (138.76.29.7, 500 1). Quando a NAT receber o pacote SYN. da alterará o endereço IP d estinatário c o número da i;>OrLa no pacote para (10.0.0. I. 3345) c encaminhará o pacote 3través da NAT. Em resumo, o UPnP permite
4.4.3 Protocolo de Mensagens de Controle do Internet (ICMP) lembre-se de que a camada de rede da Internet tem trêS componentes prindpais: o protocolo IP. d iscut ido na seção an terior; os protocolos de rotcamtnto da Internet (entre eles RIP, OSPF c BGP). que serão estudados na Seção 4.6: c o ICMP, objeto desta seção. O !CMP, especificado no IRFC 7921, é usado por hospedeiros c roteadores para comunicar informações de camada de rede emre s i. A utilização mais comum do lCMP é para comunicação de erros. Por exemplo, ao rodar


A ca11oda de rede

uma scsstlo Tclnet, FTP ou HTIP, ~possível que você Já tenha encontrado uma mensagem de erro como ~Rede de destino inalcanç:\vel". Essa mensagem teve sua origem no ICMP. Em algum pon to. um roteador IP n:\o conseguiu descobrir um t.'
npo de mtn$agem ICMP

Código

o

o o

3

Des(tiçJo

resposta de eco (para ping) rede de destino inalca nçável hospedeiro de destino lnalcançável

3 3

2

protocolo de destino inalcançc\vel

3

3

porta de destino lnalcançável

3

6

rede de destino deS
3

7

hospedeiro de destino desconhecido

4

o o o o o o

reduçlio da fonte (controle de cong~tionamento)

8 9 10 11

12

Figura 4.23 Tipos de mensagens ICMP

solicitaçAo d~ eco anúncio do roteador descoberta do roteador

m

expirado

cabeçalho IP inv~lido

bow4tto4ic~ Redes de com putod ore s e o Inler.;;o.;.e.;..t_________________________

uma strle de d:u agr:unas comuns ao destino. O primeiro desses datag ramas tem um TTL de 1, o segundo tem um TTL de 2, o terceiro tem um TLL de 3 e assim por diante. A fo nte também aciona temporizad ores paro C'Jda um dos datagmmas. Q uando o entsimo da tagmma chega ao l'nésimo roteador. o l'ntsimo ro teador obsl'rva q ue o TTl do datagrama acabou de expirar. Segundo as regras do protocolo IP. o ro teador descarta o d;u agmma c enviil uma mensagem ICMP de :t\'tso à fonte (tipo 11 código O). Essa mensagem de aviso inclui o no me do roteador e seu endere~o IP. Quilndo chega à fome, a mensagem obtém. do tempori zado r. o tempo de viagem de ida e volta e. da mensagem ICMP, o nome e o endereço IP do enesimo ro teador. Como uma fonte Tmceroute sabe quando parar d e enviar segmentos UDP? Lembre-se de qu e a fonte incremcnta o campo do TTL para cada d;uagrama que envia. Assim, um dos d atagramas finalmente consegu irá chegar ao hospedeiro d l' des tino. Como esse datagrama contém u m segmento UDP com um m1mcro de porta improvável. o hospedeiro d e destino d cvoh·e à fome uma mensage m ICMP mdicando que a po rta não pôde ser alcançada (mcns.1gem tipo 3, código 3). Q uando recebe essa mensagem JCMP parti cular, o hospedeiro da fon te sabe que nllo precisa enviar m:1is pacotes de sondagem. (Na verdade. o progr;~ma Trn ccroutc padrM envia cor1juntos de três pacotes com o mesmo TT L: assim. o T mcero utc provê três rcs uh:~d os p:tra cadn T rL)

Inspecionando dotogromos: firewolls e sistemas de detecção de intrusão Suponho que você devo administrar umo rede doméstico, departamental, universitário ou corporativo. Os otocontes, $0bendo o faixa de endereço IP do suo rede, podem envia r facilmente dotogromos IP po ro endereços do suo foixo. Esses dotogromos sôo capazes de fazer todos os tipos de coi$CIS desonestos, inclusive mopeor suo rede, fazendo seu reconhecimento (ping sweep) e varredura de portos, prejudicar h~ pedeiros vulneráveis com pacotes defeiluo$OS, inundar seNidores com milhares de pacotes ICMP e infectar hospedeiros incluindo molwores nos pacotes. Como administrador de rede, o que voei voi fazer com todos esses vilões capazes de envior pacotes maliciosos õ suo rede? Dois consogrodos mecanismos de defeso poro otoques ma liciosos de pacote sõo os firewolls e os sistemas de setecçõo de intruçõo (IOSs). Como odministrodor de rede, você deve, primeiramente, tentar instalar um firewoll entre suo rede e o lntetnet. (A maioria dos roteadores de ocesso, hoje, possuem capacidade poro firewoll.) Os firewolls inspecionam o dotogromo e campos do cabeçalho do segmento, evitando que dotogromos suspeitos entrem no rede interno. Um firewoll pode estar configurado, por exemplo, poro bloquear todos os pacotes de rcquisiçõo de eco ICMP, impedindo que um otoconte realize um reconhecimento de rede por suo folxo de endereço IP. Os Firewolls podem também bloqueor pacotes boseondo-se nos endereços IP remetente e destinatário e em números de porto. Além disso, os firewolls podem ser c;onfigurodos poro rostreor conexões TCP, permitindo o entrado somente de do togromos que pertençam o conexões aprovados. Umo protoçõo odic;ionol pode ser fornecido c;om um tOS. Um lOS, normalmente locolizodo no limite de rede, realizo •uma iru~õo profundo de pacoteH, examinando nõo apenas campos de cabeça lho como cargos úteis no dotogromo (incluindo dados do oomodo de oplicoçõo). Um lOS possui um bonco de dodos de ossinoturos de pacote à medido que novos ataques sôo descobertos. Enquonto os pacotes percorrem o lOS, este tento compotibilizor campos de cabeçalhos e cargos úteis às assinaturas em seu bonco de dados de O$$Ínaturos. Se tol compotibilizoçõo é encontrado, crio-se um alerto. Os sistemas de prevenção de intrusão (IPS) sõo semelhantes o um lOS, exceto pelo foto de eles bloquearem pacotes além de criar alertas. No Capítulo 8, exploraremos mais detolhodomente firewolls e IOSs. Os firewolls e os IOSs sõo copozes de proteger suo rede de todos os ataques? Obviamente, o resposta é nõo, visto que os otocontes encontram novos formos de aloques continuomente po ro os quais os assinaturas o indo nõo estõo d isponíveis. Mos os firewolls e os IOSs boseodos em assi naturas tradicionais sõo úteis poro proteger suo rede de ataques conhecidos.


A ca11oda de rede

Desse modo, o hospedeiro da fonte fica a par do nurncro c das Identidades de ro1eadorcs que e.sl;\o cmrc ele e o hospedc1ro de destino e o 1empo de viagem de ida e volta entre os do1s hospedeiros. Note que o programa cliente Traccroutc tem de ser capa.z de instruir o sistema optracional para que este gere datagramas UDP com valores cspecfficos de TTL. Também tem de poder ser avisado por seu sistema opcracion;~l quando chegam mensagens ICMP. Agora que voe~ emende como o Tracerome funciona, ~ pro''á'·el que queira voltar c brincar um pouco com de.

4.4.4 1Pv6 No comc~·o da d~cadu de 1990, a IETF iniciou um esforço par-.1 dCSCII\'Oivcr o sucessor do protocolo 1Pv4. Uma moti\lllç;10 primária para esse esforço foi o entendimento de que o espaço d e endereços !P de 32 bits estava começando a cscassc:1r, com novas sub-redes c nós LP sendo anexados à Intern et ( c ainda recebendo endereços IP cxclusi\·os) a t•ma velocidade cstontcame. Para atender a essa necessidade ele maior espaço para endereços I P, um novo protocolo IP. o 1Pv6. [oí descnvol,,ldo. Os projetistas do 1Pv6 também apro\•eltaram essa oponunidndc para :1just:1r c a mplinr outros as pectos do I Pv4 com base na cxperienci:l operacion:1l acumulada sobre esse protocolo. O momento em que todos os cnderC'c;os IPv-1 estariam alocados (c. por conseguinte, mais nen huma sub-re
for Internet Numbers - ARIN) lnfonnou que já linham sido alocados todos os endereço da ela c A elo lP\'1, 62 por cento dos endereços da classe B c 37 por cento dos endereços da classe C IARIN, 19961. Para um relatório recente sob re o espaço de alocaç;lo do endereço lJ>\·4 . consulte (Hai n, 2005] . Embora essas csumauvas e números sugerissem que havia um tempo considerável at~ que o espaço de endereços 1Pv4 fosse exaurido, ncou claro que seria neccss:\río um tempo expressivo para disponibiJjzar uma no,·a tecnologia em escala tão gígan tcsm. Assim, foi dado imeio ao es forço denominado Próxima Geração do IP (Nex t Ge neration IP -IPng} (Bradner. 1996; RFC 17521. O resultado desse esforço foi a especificação IP versão 6 ( IP\·6) (RFC 2460]. (Uma pergunta que sempre é fena ~o que aconteceu com o 1Pv5. Foi proposto inicialmente que o protocolo ST-2 se tornasse o 1Pv5, porém, mais tarde. este protocolo foi descartado em favor do RSVP. que discutiremos no Capitulo 7.} Excelentes fomes de infom1aç;1o sobre o JP,•6 podem ser encontradas em (l lu hema, 1998, 1Pv6 20091 .

Formato do datagrama 1Pv6 O formato do d:uagrama 1Pv6 é mostrado na Figura 4 .24. As mudancas mnis importantes in1rodu zidas no 1Pv6 firnm c"idcmcs no fom1ato do dmagrnma: 32 bits

Verslio

CIMse de tráfego

Comprimento da carga útil

Rótulo de fluxo Próximo cabeça lho (Hdr)

Endereço da fonte (128 bits) Endereço do destino (128 bits) Dados

Figura 4.24

Formato do dotogromo 1Pv6

Limite de saltos

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------Ce~puciclmlt

tlt tmlatramrnlo rxparuli
Rowlcrçclo tlr fluxo t" prioliclmlc. O 1Pv6 tem urna definic
seria bem mais simples- veja a discuss.'\o mais adiante, referente à tmnsiç;1o do 1Pv4 pnm o 1Pv6.)

Clcrsse ele tráfego. Esse campo de 8 bitS tem função semelhante à do campo TOS que vimos no IP\·4.

R6wlo clr fluxo. Co mo discuúmos antes. esse campo de 20 bitS é usado p:tm iden tific-ar lr rn nuxo de datagramas. ComJnimcr tro do (arg(t rl1il. Esse valor de 16 bits é trmado como um mlmero inteiro sem sinal que dá o numero ele bytcs no datagrarna IPvó que se segue ao pacote do cabeçalho. que tem tamanho fixo de 40 bytcs.

Próximo C(lbtçctlho. Esse campo identifica o protocolo ao qual o contel\do (ca mpo de dados) dcs..'>e datagrama ser;\ entregue ( por exemplo. TCP ou UOP). Usa os mesmos V
ErrdrH'(os clt jo111c r clt drslirro. Os v.1rios formatos do endereço de l28 bitS do 1Pv6 S;\o descritos no RFC 4291.

Dculos. Esta é :1 parte da <:<1rga útil do datagrama 1Pv6. Quando o datagmma •tlcança seu destino. a c·arg•' ú til pode ser extmfda do datagmma IP c passada adrantc para o protocolo especificado no campo próximo t:abc\-alho. Nessa discuss;\o, apresentamos a finalidade dos campos q ue estão inclufdos no datagmma 1Pv6. Quando comparamos o formato do datagrama 1Pv6 da Figura 4.24 com o formato do datagrama 1Pv4 que vi mos na Figura 4.13, notamos que diversos campos que aparecem no datagrama 1Pv4 não estão presentes no datagrama 1Pv6:


A co111oda de rede

l.67

Fwgmcllla(clolt·cmottWgcm. O 1Pv6 não permite fr:tgmcntaç-Jo c remo ntagem em roteadores intcrmcdh\rios: essas operaçOes podem ser realizadas somente pela fonte c pelo destino. Se um datagrama 1Pv6 recebido por um roteador for muito grande paro ser repassado pelo enlace de saída, o roteador simplesmente descartará o datagrama e devolverá ao remeteme uma mensagem ICl\IIP de erro · Pacote muno grande· (vcp a segu1r}. O remetente pode ent:io rccnv1ar os dados usa ndo um datagrama IP de tamanho menor. FragmentaÇl\o c remontagem são opcroçOcs que tomam muito tempo: retirar essas funcionalidades dos roteadores c colocá-las nos sistemas On:~is acelera consideravelmente o repasse IP paro dentro da rede. Soma 1lc verificação do cabeçalho. Como os protocolos de camada de transporte (por exemplo, TCP c UDP) c de enlace de dados (por exemplo, Ethc:m et) nas camadas da Internet realizam soma de ''criOcaç:io, os projetistas do IP provavelmente acharam que essa funcionalidade em tão redundante na camada de rede que podia ser retirada. M:~ls uma vez, o processamento rápido de pacotes lP era uma preocupação principal. Lembre-se de que em nossa discussão sobre o IPv-+ na Seção 4.4. 1 vi mos que, como o cabeçalho 1Pv4 cont ~ m um campo TIL (semelhante ao campo de li mite de saltos no lPv6), a soma de ' 'eriOc:wao do cabeçalho IP\•4 precisava ser rccaleulada em cada roteador. Como acontece com a fmgmC IHa~·;\o c a rcmom:~gcm , cst~l também era uma opcmc;:\o de aho custo no 1Pv4. Ot'(ÓfS. O campo de opc;ões não faz mais pane do cabeçalho-pacln'lo do lP. Contudo, ele ninda não saiu de ccn:1. Em vez disso, passou :1 ser um dos possíveis próximos cabeçalhos que poderão ser apontados pelo c:1bcçalho do 1Pv6. Em oulras palavras, o campo de opções wmbém poder.\ ser o próximo cabeçalho dentro ele um pacote IP, exatamente como os cabeçalhos dos protocolos TCP c UDP. A remoção do campo de opçOcs rcsuha em um 1.-abeçalho IP de tamanho rlxo de 40 b)•tes.

Lembre-se de que dissemos na Sc~'l\O 4.4.3 que o protocolo ICMP é usado pelos nós IP para mformar condições de erro c fornecer informações limitadas (por exemplo, a resposta de eco para uma mensagem ping) a um sistema final. Uma nova vers;'\o do ICMP foi definida para o 1Pv6 no RfC 4443. Além da reorganização das definições existentes de tipos c códigos ICMP, o ICMPv6 adicionou novos ti pos c códigos requeridos pela no'-a fundon:didade do IP,·6. Entre eles estão mcluídos o lipo "Pacote muito grande· e um código de erro · opções 1Pv6 não reconhecidas·. Al~m disso, o ICMP\'6 incorpom a funcionalidade do IGMP {Internet Group Managcmcnt Protocol - protocolo de gerenciamento de grupos da Internet). que estudaremos na Seç-Jo 4. 7. O IGMP, que é usado para gerenciar a adesão ou a sarda de urn hospcdc1ro de grupos mulllwst, era antcrionncntc um protocolo separado do ICMP no IPY4.

Transiçãodo 1Pv4 para o 1Pv6 Agora que vimos os detalhes técnicos do 1Pv6, vamos tratar de um assunto muito prático: como a lntcrneL pllblka. que ~ baseada no 1Pv4, fará :~ trans i ção para o 1Pv6? O J>roblema é que, enquanto os novos sistcmt\5 habilitados para 1Pv6 podem ser inversamente compativeis, isto é. podem enviar, rotear e receber clatagr;unas 1Pv4. os sistemas habilitados para IP\•4 nM podem manll5car dmagrmnas 1Pv6. H;1 várias opc;õcs possrvcls. Uma opção seria dctermimu um ~dia ela conversão"- uma dnta c um horário clcterminaclos em que todas as máquinas da Internet seriam deslig:~das c ~llu:~lizadas, paSS:Indo do IPv4 para o 1Pv6. A tiltlma transição importan te ele tecnologh• (do uso do NPC par-.t o uso do TCP para serviço confiável de tmnsporte) ocorreu há quase 25 anos. E. mesmo naquela época IRFC 801). quando a Internet era pequenina c ainda era gerenciada por um número reduzido de 'sabichões', ficou claro que esse •dia da conversão" não era possível. Um dia como esse, envolve ndo centenas de milhares de máquinas c milhões de gerenciadores de rede, é ainda mais impcns:\vcl hoje. O RFC 4213 descreve duas abordagens (que podem ser usadas inclepcndentcmcntc ou em conjunto) JXIra a integração gradual dos hospcde1ros e roteadores 1Pv4 :10 mundo 1Pv6 (com a meta de longo prazo de fazer a transição de todos os nós 1Pv4 para 1Pv6). Provavelmente, a maneira mais direta de introduzir nós habilitados ao 1Pv6 SeJa uma abordagem de pilha dupla, em que nós 1Pv6 t:~mbém tcnh:~m uma implementaç-ão IP,•4 completa. Esse nó, denominado nó 1Pv6/1Pv4 no RFC 4213, cstan a habilitado a enviar e receber tanto datagramas 1Pv4 quanto datagramas IPvó. Ao interagir com um nó 1Pv4, um nó 1Pv6!1Pv4 poderá usar datagramas 1Pv4; ao interagir com um nó lPv6, poderá utilizar

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;,;;.;.';;. ne;;.;t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

1Pv6. Nós 1Pv611Pv4 devem ter endereços 1Pv6 c LPv4. Além disso, devem poder determinar se outro nó é habílitado para 1Pv6 ou somente para 1Pv4. Esse problema pode ser rcsolvrdo usando o Da S ('•cja o Capfwlo 2), que poderá retornar um endereço 1Pv6 se o nome do nó a ser resolvido for c-apacuado para 1Pv6. Caso contrário, ele retornará um endereço 1Pv4. ~claro que, se o nó que estiver emitindo a requisi~Jo DNS for habilitado apenas para 1Pv4. o DNS retomará apenas um endereço 1Pv4. Na abordagem de pilha dupla. se o remetente ou o destinatário forem habilitados apenas para 1Pv4. um d:uagra ma 1Pv4 deverá ser usado. Como resultado, é possi\•d que dois nós habrlitados para IP\'6 :tc-abem, em css~nci:t, enviando d:ttagramas 1Pv4 um para o outro. Isso é ilustrado na Figura 4.25. Suponha que o nó A u riliza JP,·6 c queira enviar um da tagrama IP ao nó F. que tam!xm utiliza IP,·6. Os nós A c B podem trocar um d:Hagram:l 1Pv6. Contudo, o nó B de,•e criar um dat:lgrmna IPv4 para cnvi:1r a C. É ch1ro que o c-ampo de d:1dos do daugrama 1Pv6 pode ser copiado para o campo de dados do datagrama 1Pv4 e que o mapeamento adequado de endereço também pode ser feito. No entanto, ao realizar a conversão de 1Pv6 para 1Pv4, haverá campos 1Pv6 espccrficos no datagrama 1Pv6 (por exemplo, o c-ampo do identificador de Ouxo) que n:lo ter!lo contrapartcs em 1Pv4. As lnformaçOcs contidas nesses carnJ>OS serno perdidas. Assim, mesmo que E c F possam trocar d:uagro~mas 1Pv6, os clatagramas IPv.of (!ltC chegarem a E c D não conterão todos os c:~mpos que estavtlrn no datagrama 1Pv6 original en viado de A.

Unm alternativa para a abordagem de pilha dupla , também discutida no RFC 4213, é conhecida como implant ação de túnel. O túnel pode resolver o problema observado :mteriormcn lc. permitindo. por exemplo. que E receba o datagrama 1Pv6 originado por A. A ideb básica por trás dalmplcmemaç:lo do t(mcl é a seguin te. Suponha que do is nós 1Pv6 (por exemplo, B e E na Figura 4.25) queiram interagir usando datagrnmas IP\•6, mas estão conectados um ao outro por rotcndores im crvcnicmcs 1Pv4. Referimo-nos ao conjunto de roteadores intervenientes 1Pv4 entre dois ro teadores lPvó como um túnel. como ilustrado na Figura 4.26. Com a lmplcmcntnçào do tunel, o nó 1Pv6 no lado remetente do tuncl (por exemplo, B) pega o d:uagrama 1Pv6 i melro e o coloc-a no campo de dados (c-arga útil) de um daragrama IP\·4. E5sc daugrama 1Pv4 c cnt.-lo endereçado ao nó 1Pv6 no lado receptor do tund (por exemplo, E) c cll\·iado ao primeiro nó do tuncl ( por exemplo. C). Os roteadores 1Pv4 Intervenientes no tunel rotciam esse datagralllll IP,•4 entre eles, exatamente como fari:un com qualquer outro datagrnma, alhc1os ao fato de que o datagrama JP\·4 contém um datagrama 1Pv6 completo. O nó 1Pv6 do lado receptor d o tunel e,•emualmemc recebe o d;uagrama IP,•4 (pois ele é o destino do datagrama 1Pv4!), determina que o daugrama 1Pv4 contém um datagrama IP\·6, extrai o daugrama 1Pv6 c, em:lo, roteia o datagrama IP,•6 cxatamemc como o faria se tivesse recebido o datagrnma tp,·6 de um vizinho 1Pv6 djrctamente ligado a de. Encerramos es ta sc~·ão mencionando que cnqu
I Lawto n, 200 1I. a inid:1tiva foi tomada recentemente. Consulte I Hus ton, 2008b I para o emprego do IPvó a part ir d e 2008. O Deparr amcnro de Gerenciamento do Orçamento da Casa Branca (OMB) ordenou que os roteadores centrais das redes do governo americ-ano fossem hab ili tados paro 1Pv6 em meados de 2008; um n úme ro de órgãos cu mprill tal o rdem a té a composiçt\o clcs tc livro ( no"cmbro d e 2008). A prolifcraçao de d ispositivos como telefones I P c outros dispositi\IOS poru\teis possam dar o cmpum\o que falLa pr1 ra a aplíc:1ç:\o mais ampla do IPv(),

Fluxo: X Font e: A Destino: F

Fonte: A Destino: F

Fonte: A Destino: F

dados

dados dados

dados A para 8: IPvii

figura 4.25 Abordagem de pilhoduplo

Fluxo:?? Fonte. A D~tino: F

8 para C: 1Pv4

D para E: 1Pv4

E para F: IPvii

bow4tto4ic~ A
Capí tulo •

Vi~o

lógic.a

1Pv6

1Pv6

1Pv6

~

Túnel

·--·----------------------J

Vi~o

269

1Pv6

~f<

flsica

1Pv6

1Pv4

1Pv4

1Pv6

1Pv6

·J-=~~~ Flu•o: X Fonte: A Destino: F

dados

Fonte: 8 Destino: E

Fonte: B Destino: E

FluJCo: X Fonte: A Destino: F

Fluxo: X Fonte: A Destino: F

dados

dados

Flu•o: X Fonte: A Destino: F

dados E para F: 1Pv6

A para 9: 1Pv6

8 para C: 1Pv4 (encapsulando IP\16)

O para E: 1Pv4 (encapsulando 1Pv6)

Figura 4.26 lmplementoçõo de lúnel O progrnm::t europeu Thlrd Gcncrntion Parlncrship [3GPP, 20091 especificou o IP,-6 como o padrão de ende-reçamento parn multimídia móvel. Mesmo que o 1Pv6 não tenha s ido disponibilizado amplamente nos primeiros dez anos de sua jo,•em vida, está bem claro que é preciso uma ' 'isilo de longo prnzo. O sistema de mimeros de tclcrones cxastentc hoje demorou várias décadas parn se firmar, mas está vagcnte há quase meio século e não dá nenhum si nal de que pretende sair de cena. De modo semelhante. pode levar algum tempo parn o 1Pv6 se firmar. mas. depois, provavelmente ele também será milizado durame muito tempo. Bnan C.1rpcmer, anugo diretor d o Internet Archltccturc Board [IAB, 20091 c autor de diversos RFCs relacionados :10 1Pv6, declarou: ~ eu sempre considerei a adoç-ão do 1Pv6 como um processo de 15 anos, começando em 1995.~ llawton. 2001). Pelas contas de Carpt'ntcr, já es tamos perto dos dois terços desse tempo! Uma lição Importante que podemos aprender com a experiência do 1Pv6 é queM eno rme d inc uld::tdc parn mudur protocolos de ct1mada de rede. Desde o infcio da década de 1990, numerosos novos p ro tocolos de c::tmada de rede romm anun ciados como a próxima maior rc,•oluç;1o da Intern et, mas a maioria desses protocolos teve pouca ::tccit a~·t1o até ::tgora. Den tre eles, estão o 1Pv6. os protocolos rnulticasl (veja a Seção 4.7) c os pro tocolos de reserva de recursos (Clll'itulo 7). NA verdade, introduzir novos protocolos na cmn:1da ele rede é co mo substitUir as fundaçó(-s de uma CtiSa- f dlrícil de fazer sem demollr a casa inteira ou, no mínimo, retirar os mor;,dorcs temporariamente da residencia. Por outro lado, a Internet vem tes temunhando a rápida disponibilização de novos protocolos na camada de aplícaçl\o. Os exemplos clássicos são, é claro, a Web. n mens."lgem instantânea e o co mpartilhamento de arquivos P2P. OuLros exemplos sâo a recepção de áudio c vídeo em tempo real c os jogos dist ribuídos. Introduzir novos protocolos de cmn::tda de aplicaç-.lo é como piauar uma casa- é relativamente ráeil de razcr e, se voct: escol her uma cor atraente, outrns casas da vizinhança vão imitá-lo. Em resumo, no ruturo podemos esperar mud::tnças n:1 t~un;ld::t de rede da Internet. mas CSS.'\S mudanças prov::tvclmcntc O<.·o rrcr<'o dentro de urna cscala de tempo bem ma is lenta do q ue as que ocorrerão na camada de npllcação.

4.4.5 Uma breveinvestido em segurança IP 'a Seção 4.4.3 discutimos o IP\•4 em alguns detalhes, incluindo os serviços que ele pro,•ê c como esses serviços são implementados. Ao ler esta seção, você pode ter percebido que nenhum serviço de segurnnça foi mencionado. Realmente, o 1Pv4 foi projetado em uma ern (anos 1970) em que a Internet era utilizada, primordialmente,

bow4tto4ic~ Redes de tom pu tod ores e o Interne~1------------------------entre pesquisadores de rede mutualmeme confiáveis. Criar uma rede de computadores que integrava uma grande qu:mudade de tecnologias da camada de enlace já em desafiador, sem ter de se preocupar com a scgumnça. Mas, com a segurança sendo a principal preocupação hoje, pesquisadores da Internet começaram a criar novos protocolos da camada de rede que oferecem uma \'anedadc de serviços de segurança. Um desses protocolos é o IPsec, um dos protocolos da camada de rede mais conhecidos c empregados em Redes VirtuaiS Privadas (VP 's). Embora o IPscc c seus s uportes sejam abordados no Capítulo 8, aprescmamos uma breve introdução sobre os ser.•iços do IPscc nest.a seção. O LPscc foi desenvolvido para ser compaúvel com o 1Pv4 e o 1Pv6. Particularmente, para obter os benefícios do LPvó, não precisamos substituir as pilhas dos protocolos em toclo~ os roteadores c hospedeiros na Internet. Por exemplo, utilizando o modo transporte ( um dos "-modos- do LPscc). se dois hospedeiros querem se comunicar de modo seguro, o IPscc precisa estar disponível somente em dois hospedeiros. Todos os outros roteadores e hospedeiros podem continuar a rodar o 1Pv4 s imples. Para urna abordage m concreta, a partir daqui focaremos no modo transporte do IPsec. Neste modo, dois hospedeiros estabelecem, primeiramente, uma sessão entre si mesmos. (Assim, o IPscc é oricnwdo a conexão!) Com a sessão em vigor, todos os segmentos TCP e UDP enviados entre os dois hospedeiros aprovei tam os serviços dc segurança providos pelo IPsec. No lado remetente, a camada de transporte passa um segmento para o IPscc. Este, cnt;\o, codifica o segmento, acrescen ta campos de segurança adído nais a ele e envolve a carga útil resultante em um datagrmna IP comum. (Na vcrd;1de, isso é mais complicado. como veremos no Capitulo 8.) O hospedeiro rcmctcnlc, envia, cntdo o datagmma para a Internet, a qual o transporta para o hos pedeiro destinatário. Em seguida, o IPscc dccodifica o segmento c encamin ha o segmento decodificado à camada de transporte. Os serviços providos por uma sessão IPsec incluem:

i\cordo crifJIOgHtjico. Mccanimos que permitem que dois hospedeiros de comunica\'
CodijiCCI((lo d(ls CCirgru 1ilris elo clcllagmma LP. Quando o hospedeiro destinatário recebe um segmento da camada de transporte, o IPsec codifica a carga útil, que pode ser somente decodificada pelo IPsec no hospede1ro destinatário. /urgrldculc elos dculos. O IPsec permite que o hospedeiro destinatário verifique se os campos do l-nbe\·alho do datagmma c a carga útil codificada rulo foram modificados enquanto o datagmma csta\1:1 a caminho da fonte ao destino. J\utrruícnçtlo de origem. Quando um hospedeiro recebe um datagrama IPsec de uma fome confiável (com u ma chave confiável - consulte Capítulo 8). o hospedeiro está certo de que o endereço IP remetente no datagrama t a verdadeira fonte do datagrama. Quando dois hospedeiros estabelecem u rna sess\o !Psec, todos os segmentos TCP c UDP enviados entre eles serão codificados c autetukados. O !Pscc, portamo, oferece uma cobertu ra geral, protegendo toda a comunicação ent re os dois hospedeiros para todas as aplicações de rede. Uma empresa pode lllilizar o IPsec para se comunicar de forma segura na lnterncl pllblica nno segttra. Para fins de il us traç;\o, verificaremos um exemplo simples. Cons ide re uma empresa que possua um grande número de vendedores que viajam , t"ada um possuindo um laptop da empresu. Suponha que os vendedores precisem consultar, frequentemente, informações confidenciais sobre a empresa (por exemplo, lnforrn:~çõcs sobre preços c prod utos) armazenadas em um servidor na rnaLriz da empresa. Suponh:1, ainda, que os vendedores também precisem cnvillr documentos confidenciais u m para o omro. Como isso pode ser feito com o !Pscc? Como voe~ pode imaginllr, instalamos o IPsec no servidor e cm todos os laptops dos vendedores. Com ele instalado nesses hospedeiros. quando um vendedor precisar se comunicar com o servidor ou com outro "cndcdor, a scss;lo de comunlcaç-lo estará protegida.

4.5 Algoritmos de roteamento Exploramos, neste capítulo, a função de repasse da camada de rede mais do que qualquer outra. Aprendemos que, quando um pacote chega a um roteador, o roteador indexa uma tabela ele repasse c determina a interface de


A u11oda de rede

271

enlace para a qual o pacote deve ser dirigido. Aprendemos também que algoritmos de roteamento que rodam em roteadores de rede trocam e calculam as informações que são utilizadas para conOgurar essas tabelas de repasse. A ímeraçào entre algontmos de roteamento c tabelas de repasse foi ilustrada na Figura 4.2. Agora que Já nos aprofund:~mos um pouco na questJo do repasse. voltaremos nossa atcnç;lo para o outro tópico importante desse capitulo. a saber, a função critica da camada de rede, o roteamento. Quer ofereça um serviço de datagramas (quando pacotes dtferentcs entre um determinado par fonte-destino podem pegar rotas dtferentcs) ou um serviço de VCs (quando todos os pacotes entre uma fonte e um destino determinados pegar.\o o mesmo caminho). a camada de rede deve. mesmo assim. dctem,inar o taminho que os pacotes percorrem entre remetentes c destinatários. Veremos que a tarefa do roteamento é determinar bons caminhos (ou rotas) entre remetentes e destinatários :uravés da rede de roteadores. Nonnalmcntc um hospedeiro está ligado diretamente a um roteador, o roteado r d efa ult para esse hospedeiro (tambtm denominado ro teador do primeiro s alto para o hosp«. Além disso. sempre consideraremos somente g raros ni\o clircdonados

Figura 4.27 Modelo obslmto de grafode uma rede de computadores


(isto é, grafos cujas arestas não t~m uma dircçao), de modo que a aresta (x,y) é a mesma que a aresta (y~"> c c(x,y) = c(y~Y). Dizemos tam!Xm q ue y é u m vizinho d o nó x se (x,y) pertencer a E. Dado q ue s:\o atnbu ldos custos às várias arestas na abstraÇão do grofo. um01 me ta natural d e um 01lgo ritmo de roteamento é identificar o <.-aminho de menor custo entre fontes c dcsunos. Para tom:~r esse problema mais preciso, lembremos que um caminho em um grafo G = (N,E) é uma sequêncía de nós . Dados quaisquer dois nós x c y . nonnalmcntc há mui tos caminhos emre os dois, c cada crtminho tem um custo. Um ota mais desses caminhos é um caminho de menor custo. Po r conseguinte. o problema do menor custo é claro: descobrir um crtminho entre a fon te e o destino q ue tenha o menor custo. Na Figura 4.27, po r exemplo, o caminho d e menor custo entre o nó da font e u c o nó de destino w é (11, x, y. w) , cujo cus to de caminho é 3. Note que, se todas as ;u cst:IS do g rafo ti\•crem o mesmo custo, o caminho de menor cus to também é o caminho mais curt o (isto é, o ca minho que tem o menor número de enlaces en tre a fome c o d estino ).

x,>

x,>

i\pc tHIS como sim ples cxcrcfclo, tente descobrir o caminho de menor CLtSto entre os nós u c ;r nn Figura 4.27 c renlta um pOLtco sobre como voe(: calculou esse caminho. Se voce for corno a maioria das pessoas, descobriu o ca mi nho de 1r a ~ exmnin:tndo a figunt, tmçando algumas rotas de 1r a <. c se convencendo, de algum modo, que o c-<~minho que voe(: escolheu tinha o menor cus to entre todos os caminhos possíveis. ( Voe(: vcriOcou todos os 17 possivcis camin hos entre 1r c ;r? Provavelmente, não!) Esse c~Hculo é um exemplo de um algoritmo de ro tea mento centmlizad o - o algoritmo é rod ad o em um local, o seu cérebro. com inronnaçOes completas sobre a red e. De modo gemi, uma maneira possível d e classificar a lgoriunos de rotcamelllo é como globais ou ce n t ra l iz:~dos. Um algoritmo de roteamento global l-alcula o caminho de menor custo entre uma fonte c um destino usando conhecimemo completo c global sobre a rede. Em outras p.1lavras. o algoritmo cons idera como dados de cJiculo a conectividade entre todos os nós e todos os custos dos enlaces. E isso exige que o algoritmo obtenha essas informações, de algum modo. ames de realmente rcaliz.1r o cálculo. O cálculo em si pode ser rodado em um local (um algoritmo de roteamento global ccntralazad o) ou d uplicado em vários locais. Contudo. a principal caracterfstica d istinth~ . nesse l':lSO. é que um algori tmo global tem mformaçào completa sobre conectividade c custo de enlaces. a prática. algontmos com mformação global de estado srio est~ ligado), um nó gradualmerlle <.-alcula o camin ho de menor custo até um destino ou u m conJunto de desti nos. O algoritmo de ro teamento dcsçcntraliz.ado q ue estudaremos logo adiante na Scçi\o 4.5.2 é dcno mi rtado algoritmo de vetor d e dis tâncias (clisllmce-vcclor ulgorillnn - DV) po rqu e cada nó mantém um veto r ele esti mativas de custos (d ist:\ncias) de um nó até todos os outros nós d:1 red e. Uma segunda mancim geral de classificar algoritmos de ro tcrtmcnto é como está ucos ou dmãm tcos. Em a lgoritmo de rotea mento está ticos, as rotas mudam mui to lentam ente ao longo d o tempo. muitas vezes como resultado ele intervenção hu mana ( por exemplo, u ma pessoa edita ndo man ualmente :1 tabela de repasse do roteador). Algoritmos d e roteamento dinâmicos mudam os caminhos de roteamento à med iei:~ que mudam as cargas de trMego o u a topologaa da rede. Um algom mo d inãmico pode ser rodado pcraodicamente ou como reação d ireta à mud:mças de topologia ou d e cus to dos enlaces. Ao mesmo tempo que são maiS sens rvc1s á mudanças na rede, algoritmos clin:lmicos também são mais suscctiveis a problemas como loops de roteamento c osçilaç:io em ro tas. Uma tcrceara maneira d e classificar algoritmos de roteamento é como scns1veis à carga o u inscnSI\'CÍs à carga. Em um algoritmo stnslvcl à carga, custos de enlace variam dmanucamente para refletir o ntvel corrente de congestionamento no e nlace subjacente. Se houver um alto custo associado com um enlace que está correntemente


A uruda de rede

2.73

congestionado, um algoritmo de roteamento tCJlderá a escolher rotas que evitem esse enlace eongestiorlado. Embora amigos algoritmos da ARPAnet rosscm sensíveis à ca rga IMcQuillan. 19801. romm encontrodas ' 'árias diri culdades (liuitcma. 19981 . Os algoritmos de roteamento utilizados na Internet hoje (como RIP, OSPF c BGP) s;\o insens iveis à carga. pois o custo de um enlace " ''o reOete explicitamente seu nível de congestionamento corrente ( nem o de congestionamento mais recente).

4.5.1

Oalgoritmo de roteamento de estado de enlace (LS)

Lembre-se de que em urn algori tmo de estado de enlace a topologia da rede e todos os custos de enlace sao con heddos, rsto é , est;lo dis ponlveis corno dados para o algorumo de estado de enlace. Na pr.\tica, isso se consegue razcndo com que cada nó transmita pacotes de cstndo de enlace n tod os os outros nós d:t rede. sendo que cada um desses pacotes cont ém as identidades c os custos dos enlaces ligados a ele. N:r prá tica (por exemplo, com o protocolo de rotea mento OSI,F da Intern et, disculído na Seç-lo 4 .6 .1) isso rrequentemcme é conseguid o com um algoritmo de transmissão hroadcast de estado de enlace (Perl man, 19991. Algo ritmos de transmissão bromlrCJst scnlo es tudados lll' Scçào 4 .7. O resultado da transmissão broa
O algoritmo de roteamento de estado de enlace que aprescm:un os ad iante é co nh ecido como algoritmo de Dijksmr. o nome ele seu inve ntor. Um ~11gontmo que guarda relações multo próximas co rn ele é o algori tmo de Prim. Consulte (Cormcn, 20011 para uma diScussão geral $Obre algorilmos de g rafo. O algoritm o de Dijkstra cakula o caminho de menor custo entre um nó (a rontc, que d1amarcmos de u) e todos os out ros nós da red e. !: um algoritmo iterativo c tem a propriedade de, após a k-ési ma itemç.lo. conhecer os caminhos de menor cus to para k nós de destino c, dentre os caminhos de menor custo até todos os nós de desuno, esses k caminhos terào os k menores Cltstos. Vamos definir a seguinte notação: D(, ): custo do caminho de menor cllSto entre o nó da ronte e o destino v até essa iteração do algontmo. p(v): nó an tcnor (vizjnho de,.) ao longo d o cammho de menor custo corrente desde a rontc até ''·

N': subconjunto de nós; ,. penence a N' se o caminho de menor custo entre a fonte e'' for inequrvoca-

mcnte conhecido. O algori tmo de roteamento global consiste em uma etapa de inicialização seguida de um loop. O número de vezes que o loop é rodado é igual ao numero de nós na rede. Ao termin ar. o algori tmo Lera calculado os caminhos mais curtos desde o nó da fo nte u até todos os outros nós da rede.

Algoritmo de estado de enlace para o nó da fonte u 1

l nicializaç&o:

2 3

ti '

[U)

pa r a todos o s nós v se v for um vi zi nho de u en t 3o O( v)= c( u. v) senao O • ~

4 5

6 7

8 9 10

11

12 13

14

Loop encon t r e w nlio em tf'. t a l que O< w> é um minimo a dicione w a H" atualize O( v) par a c ada v iz in ho v de w e nao em tf': O( v) ml n( O(v) . O(w) + c(w . v) ) / • o novo c usto para v ê o vel ho custo pa ra v ou o c us to do menor caminho conhecido para w ma is o c us t o de

15 até N·• N

w para v

*/


Como exemplo, v:unos considerar a rede da Figura 4.27 c calcular os caminhos de meno r custo de u até todos os destinos possíveis. Os cálculos do algoritmo esteio ilustrados na T<~bcla 4.3, na qual C<~da linha rornece os valores das '-ariavcis do algoritmo ao final da iteraç:\o. Vamos considerar detalhada me me alguns dos primeiros estágios: No estágio de inicializaç;\o, os ~o-aminhos de menor custo correntemente conhecidos de 11 até os vizinhos diret:uncntc ligados a de (,•, "'c x) são inicializados para 2. 1 c 5. respectivamente. Note. em p:lrticular, que o custo a1é w é estabelecido em 5 (embora logo veremos que, na realidade. existe um trajeto cujo custo é ainda menor), já que este é o custo do enlace (um salto) direto 11 a w. Os custos até y e:<: são estabelecidos co mo infinito, porque eles náo esteio diretamente conect:ldos a 11. Na prime1ra iteraçào, examinamos os nós que ainda não roram adicíonados ao conjunto N' c descobrimos o nó de menor custo ao fin:~l da iteração anterior. Este é o nó x. com um cus to de 1, e, assim, x é adicionado ao conjunto N'. A linha 12 do algorilmo de ve1or de dist!incias (LS) é então rodada para atualizar D (v) para todos os nós v, produzindo os resultados mostrados na segunda linha (Etapa l ) da Tabela 4.3. O cus1o do c:tminho até,. não muda. Descobriremos que o cus1o do camir1ho até w
Etopa

N'

D{v), p(v)

D(w), p(w)

D(x), p(x)

D(y), p(y)

0(1), p(z)

o

u

1,u

l,u

00

00

1 2

2.u 2.u

2.x

00

3

ux uxy uxyv

S.u 4.x

4

IJ1.'f'IW

5

IJXV'INZ

Tabela 4.3

3,y

4.y

3,y

4,y

Exe
4,y


Destination

A u11oda de rede

275

Link

v

(u, v)

w

(u, x)

X

(u, x)

y

(u, x)

z

(u, 11)

Figura 4.28 Coninhos de menorrosto resultonles e otabelo de repasse poro on6 u

algoritmo , que utiliz:1 u rna estrutura de dados conhecida como uma pilha, pode descobrir o mfnimo na linha 9 em tempo logarftmico c m\o·llncar, reduzindo assim a complexidade.) 1\ ntcs de concluirmos no55a discussão sobre o algoritmo LS, vamos considerar· uma patologia que pode surgi r. A Figura 4.29 mostra uma topologia de rede s imples em que os custos dos enlaces s:lo igua is~ carga mmsportada pelo enlace. renetindo, por exemplo, o atraso que seria expcl'i mcntado. Nesse exemplo, os custos dos ct1laccs não são slmf trkos, isto é. c(u,v) é igual a c(v,u) somente se a carga transportada em ambas as direções elo enlace (u,v) ror a mesma. Nesse exemplo , o nó .z origina uma llnidadc d e trãrego desti nada a w, o nó x também origina uma umdade de tr:\rcgo destinada a w c o nó)' injeta uma quantidade de trMcgo igual a c também destinada a "'· O roteamento i niei:~l é mos trado na Figur.t 4.29(a) com os custos dos enlaces corres pondentes à qu:tntid;tdc de u áfcgo carrcgad:~.

a. Roteamento inidal

b. x, y detectam melhor caminho até w em sentido horario

e c. x, y, z detectam melhOI' caminho até w em sentido anti-horário

Figura 4.29 Oscilações com roteamento de congestionamento

d. x, y, z, detectam melhor caminho at~ w em sentido horário

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------Quando o algoritmo LS ~ rodado no,':lmcme, o nó y determina - baseado nos custos dos enlaces mosuados na Figura 4.29(a) - que o caminho em sentido horário até 111 tem um custo de 1, ao passo que o caminho em sentido anti·hor-'rio ;Hé w (que estava sendo usado) tem um custo de 1 + c. Por conseguinte. o C':lminho de menor custo de y ate "' é agora em sentido horário. De maneira semelhante. x determina que seu novo caminho de menor custo até w é também em sentido hornrio, resultando nos custos mostrados na F1gura 4.29(b). a próxima \ 'CZ em que o algon uno LS e rodado, os nós x. y. e t detectam um cammho de custo ze ro até w na d1reção anti·horárra. e todos d1rigem seu tráfego para as rotas anti-horárias. 1a próxima vez em que o algoritmo 1..5 é rodado. os nós x. y. c t cnt:lo dirigem seu trárcgo para as rotas em sentido horário.

O que pode ser rei to para evitar essas oscilações (qur podem ocorrer com qualquer a lgoritmo, c n:'\o apenas com um algoritmo LS, que use uma métrica de enlace baseada em congestionamento ou em atraso)? Uma soluç-Jo seria tornar obrigatório que os custos dos enlaces não dependessem da quantidade de trMcgo carrcg~tda - uma soluç;1o inaceit:\\·el, j:\ que um dos objetivos do roteamento é evitar enlaces muito conges tionados (por exemplo, enlaces com grande a tmso). Outra solução seria assegura r que nem todos os roteadores rodassem o algoritmo LS ao mesmo tempo. Esta parece ser uma solução mais razoável, já que é de esperar que, mesmo q ue os ro teadores rodem o algoritmo I.S com idemica periodicidade, o instame de execução do algoritmo n"o seja o mesmo em c-..dtl nó. O intercssa1ne é que recentemente os pesquisadores descobrirnm que os roteadores da Internet podem se auto-si 11cronizar [ Floyd Synchronization, l99·11, isto 1!. mesmo que inicialmente rodem o :tlgorilmo com o mesmo período, mas em dircrcntes momentos, o instante de cxecuçM do ~1lgor1tmo pode finalmente se tornar, e permanecer, sincronizado nos roteadores. Um modo de evitar essa autossineronizaç:lo é cada roteador variar a leatonameme o Instante em que envia um anüncio de enlace.

Agora que examinamos o algoritmo de estado de enla.::c, Yamos analisar outro imponante ;~lgorilmo usado hoje na pr:\lica- o algoritmo de roteamento de vetor de distãncias.

4.5.2 Oalgoritmo de roteamento de vetor de distâncias (OV) Enquanto o algoritmo 1..5 usa infon naç-Jo global. o algori tmo de vetor de dist:\ncias (distauce·vector- OV) é uerath·o. assfncrono c d is1ribufdo. Ê d istribufdo porque cada nó recebe alguma informaç;\o de um ou mais ''izinhos d1rctamente ligados a ele, realiza cálculos c, em seguida, distnbm os resultados de seus cálculos para seus vizinhos. E iterativo porque esse processo continua até que mais nenlnuna informação seja uocada entre vizinhos. (O interessante é que este é um algoritmo finito- n~o há nenhum sinal de que o cálculo deve parar: ele apenas para.) O algoritmo é assfncrono porque n:lo requer que todos os nós rodem simultaneamente. Veremos que um algoritmo asslnerono, iterativo, fini to e distribuldo é muito mais interessante c divertido do q ue um algoritmo centralizado! Antes de apresentar o algorit mo DV, é bom discutir uma relaç;\o importante que existe entre os custos dos camin hos de menor custo. Seja d,(y) o custo do caminho de menor custo elo nó x ao nó y. Então, os me nores custos estilo relacionados segundo a f;unosa equa~~\o de Bellm:m·Ford, a saber:

.

(-1.1) cl (y) = miu (c(x,v) + cl (y)}, ' ' onde o min, da cquaç~o é calculado pam todos os vizinhos d e x. A cq m1ção de Bcllman·Ford é bastnme inmitiva. Rralmentc, se apóS tmnsitarrnos de x para\' tomarmos o caminho de meno r custo de v a y, o custo do caminho scr:l c:(x,v) +
Mas. para aqueles que ainda se mostrem céticos quanto:\ \•alidadc da cqua~·ão , vamos vcnfic:á-la para o nó d e fonte u c o nó de destino t na Figura 4.27. O nó da fonte u tcmtr~s vizinhos: nós''· x c 1v. Percorrendo vários caminhos no graro, é r, cil ver que d,(t) = 5. d,(t) = 3 c d.(t ) = 3. Passando esses valo res para a Eq u;~ ç;\o 4. L, juntamente com os cus tos c(u,v) = 2, c(u,x) = 1 c c:( u,w) = 5 , temos

A
l.n

A equaçao de Bellman-Ford nao é apenas uma curiosidade intelectual. 'a verd:1de, ela tem uma importância pr.itica significativa. Em particular, a solução da equação de Bellman-Ford fornece os registros da tabela de repasse do nó x. P.1ra vcnllc;~r isso, seja\'* qualquer nó vizinho que represente o mínimo na EquaçM -..1. Entao. se o nó x qui!ter enviar um pacote ao nó y pelo caminho de menor custo, dc,·cr.t. em primeiro lugar, repassar o pacote para o nó v*. Asstm, a tabela de repasse do nó x t'Spccillcaria o nó \'* como o roteador do próximo s:1ho para o desuno final y. Uma outra contribuição importante da equação de Bcllman-Ford é que ela sugere a forma da comunicação vizinho para vizinho que ocorrem no algorlimo DV.

A ideia básica é a seguinte. Cada nó começa com D,(y), uma cstimauva do custo do caminho de menor custo entre ele mt'Smo c o nó y. para todos os nós em N. Seja D, ID,(y): y em Nl o vetor de distâncias do nó x, que é o vetor de estimativas de custo de x mt todos os outros nós, y. em N. Com o algoritmo DV cada nó x mamém os scguimcs dados de roteamento: Para cada vizinho v, o custo c(x,v) de x até o vizinho dlret.unentc ligado a ele, v

=

=

O vetor de distâncias do nó x, isto é, D, ID, (y): y em Nl. contendo a estimativa de x para seus custos :ué todos os des tinos, y. em N Os vctorcs de distâncias de seus vizinhos. isto é. D, = ID,(y): y em Nl pam cada vizi nho v de x No :1lgorhmo distribuído, assíncrono, cada nó envia, a intervalos rcgul:tres, umu cópia elo seu vetor de díst:i ncias a cada um de seus vizinhos. Quando um nó x recebe um novo veLor ele distâncias de qualquer de seus vizanhos v, ele :mnazena o vetor de distànclas de '' c então usa a cqu:u;:\o de Bcllman-Ford p;1m atualizar seu próprio vetor de distàncias, como segue: D.(y )

= miu,lc(x.v) + D.(>·) l para cada nó y em N

Se o vetor de distâncias do nó x tiver mudado como resultado dessa etapa de at ualtzaç-.lo, o nó x então en1•iará seu vetor de dtstânctas atualizado para cada um de St'US vuinhos que. por sua vez, podem atualizar seus própnos vetores de distancias. Parece milagre, mas, contanto que todos os nós continuem a trocar seus vetores de dístãncias assincronamente, cada cstimati1·a de custo D,(y) convergirá para d,(y), que é, na verdade, o custo do caminho de menor custo do nó x ao nó y (Bcrtsekas, 19911!

Algoritmo vetor de distância (DV) Para cada nó, x:

1 lntcia 11zaç5o: 2 para todos os des t 1nos y em N: ct• se y nao é um vtztn ho en tao ccx .y ) 00 3 O,< y) 4 para cada vizinho w 5 O.( Y) • ? para todos os destinos y em N 6 para cada viz inho w 7 env ia um vet.or de di s tanc ia s o, .. [ O,( y ) : y em ti ) pa ra w

f.

8 9 loop 10 wait (até que ocorra uma mudança no cus to do enl ace ao vi zi nho w ou

até a recepçao de um vet or de distancias do vi zinho w)

ll

12 13 14 15 16 17

para cada y em N: O,(y) • min, l c(x . v) + O,(Y) f lf O (y)

18

19 forever

mudou para algum des t ino y envi a um vetor de disUnctas

o. -

[O,(y) : y

em H] para todos os vizinhos

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------' o algoritmo DV um nó x atualiza sua estimativa do vetor de distancias quando percebe um mudança de custo em um dos enlaces ligados diretamente a ele ou recebe uma atualizaçào do vetor de distâncias de algum vizinho. Mas, para atualizar sua própria tabela de repasse para um dado destino y. o que o nó x re;llmcntc precisa saber não c a distância do caminho mais curto até y. mas q ual nó vizinho ,,•(y) é o roteador do próximo salto ao longo do caminho mais curto até y. Como era de esperar, o roteador do próximo salto v•(y) é o vizinho v que representar o mfnimo na Lanha 14 do algoritmo DV. (Se hou1•er vários vizinhos 1• que representem o mmimo. entào 1•*(.>') pode ser qualquer um dos vizinhos minimizadores.) Assim, nas Linhas 13-1-+. para cada destino y , o nó x também determina ,,•(y) c atualiza sua tabela de rep;lSSe p<~ra o destino y. Lembre-se de que o a lgoritmo LS é um algoritmo global no scnudo de que requer que cada nó obtenha, em primeiro lugar, um mapa completo d:l rede antes de rodar o algoritmo de Dijkstra. O algoritmo DV é drscrmralltmlo c não usa ess~1 l nforma~~\o global. Realmente, a única informaçilo que um nó terá ~lo os custos dos enlaces até os vizi nhos diretamemc ligados a ele e as infom1ações que recebe desses viz1 nhos. Cada nó espera uma awalizaç;\o de qualquer vizin ho (Linhas 10-11), calcula seu novo vetor de dist:indas ao receber uma atualiza1,-:1o (Linha 14) c distribui seu novo vetor de distMcins a seus vizinhos (Linhas 16-17). Algoritmos scmelhruues ao DV são uti lizados em muitos protocolos de roteamento na prátlca, entre eles o RIP c o BGP da Internet, o LSO IDRP. o IPX da Novel!, c o ARPAnet original. A Figura 4.30 ilustra a operaç:lo do algoritmo DV para a rede simples de t~s nós mostrada na parte superior da figura. A operação do algoritmo é ilustrada de um modo síncrono, no qua l todos os nós recebem vetores de distâncias simultaneamente de seus ' ' izinhos, calculam seus novos vetores de distâncias c infomtam a seus vizinhos se esses vetores mudnrnm. Após estudar esse exemplo, voce deve se convencer de que o algotiuno também

O(>era cornw:uncme em modo assfncrono, com cálculos de nós e atuali~Wões de

gcraç-Jo/rccc~o

ocorrendo a

qualquer mstantc.

A coluna mais à esquerda na figura mostra tr~ tabelas de roteamento iniciais para <.-nda um dos três nós. Por exemplo. :1 tabela no canto superior à esquerda é a tabela de rotc-.unemo imcial do nó x Dentro de uma tabela de roteamento especifica, cada hnha é um vetor de d1stãncias - especificamente. a tabela de rote-.tmento de cada nó mel ui seu próprio vetor de distâncias e os vetores de cada um de seus vizinhos. Ass1m, a primeira linha da tabela de roteamento micial do nó x t D' = (D•(x), D,\J' '"), D' (z)l [O. 2, 71 . A """Unda linha c a terceira linha nessa -o tabela s;\o os vetores de distâncias recebidos mais recentemente dos nós y e t , respectivamente. Corno na inicializaçilo o nó x nlo recebeu nada do nó y ou t. os registros da segunda linha c da terceira linha estão definidos como infinito.

=

Após a imcializaç:\o, cada nó cm
=

rCl'akul~

seu próprio vetor de disulncias. Por exemplo, o nó x calcula D,(x) =O

D,(y) = ulln lc(x,y) + D,(y), c(x, t) + D,(}')/ D,(z>

= mlnt2 +O, 7 + ll =

= mln(c(x,y) + D,(z). c(x, t) + D;(z)l = min(2 +

2

L. 7 +O I = 3

Por conseguinte, a scgund:1 coluna mostra, para cada nó, o no1•o vetor de distâncias do nó, juntamente com

os vetores de dist;,ncias que acabou de receber de seus vizinhos. Observe, por exemplo, que a estim:uiva do nó x para o menor CLISto até o nó t , D,(z>, mudou de 7 para 3. Note também que. para ambos os nós y e :::,o nó y rcprcscma os mínimos correspondentes. Assim, nesse estágio do algoritmo, os roteadores do próximo salto são v•(y) y e v (;:) = y.

=

Depois que recalculam ~us vetores de distâncias. os nós cnl'iam nol'amcnte seus vetores de distâncias recalculados a seus vizmhos (se houl'cr uma mudança). Isso é il ustrado na F1guro1 4.30 pelas setas que v-Jo da segunda coluna de tabelas até a terceira coluna de t<~belas. Note que somente os nós x e ::: enviam atualizaçOes: o vetor de d1stãncms do nó y não mudou. então o nó y não Cnl'ia uma atualização. Após receber as atualizaÇÕes. os nós então recalculam seus vetores de distâncias e atualizam suas ubelas de roteamento, que são mostradas na

terceira coluna.


A uruda de rede

279

Tabela do nó x Custo até X X 41

o

y

z

y

Custo até

z

.. .... 00

X

y

Custo até

z

X

o"'

o"' y

z

7

X

y

z

X

o

2

3

y

2

o

z

3

o

Tabela do nó y Custo até

Custo até )(

.

o

y

)(

y

z 7

X

X

o

2

y

y

2

o

z

7

z

... ...

o

Custo até

X

o"' y z

)(

y

z

o

2

3

2

o o

3

Tabela do nó z Custo até

Custo até

y

X

y

o

2

X

X 41

c

.. ..

X

Custo até )(

y

z

X

o

2

3

o

y

c"' y

c"' y

2

z

z

z

3

o

.............................................................................. Tempo

Figura 4.30 Algoritmo de vetoc de d'ISrôocias (DV) O processo d e receber vetores de distâncias atuahz.ados de vizinhos. recalcular os rcgrstros de tabelas de roteamento c informar aos vizinhos os c us tos modificados do caminho de menor custo att o deslino continua att que mais nenhuma mensagem de atualiz.açào seja enviada. Nesse pomo, já que mais nenhuma mensagem de atualização t enviada, não ocorrerá mais ne nhum cálculo de tabela de roteamento c o algoritmo entra em estado de inauvidade; isto ê, todos os nós estarlo rodando a espera nas Linhas 10- 11 do algoritmo DV. O a lgoritmo permanece no estado de inau vrdadc ate que o c usto de um enlace mude, como discutiremos a seguir.


Algoritmo de vetor de distâncias: mudanças no custo do enlace e folha no enlace Quando um nó que está rodando o algoritmo OV detecta uma mudanç:~ no custo do enlace dele mesmo até um vizinho ( Unhas 10-ll), ele atualiza seu \'Ctor de distâncias ( UnffitS 13-14) c , se houver uma modificação no custo do caminho de menor custo. informa a seus vizinhos (Linhas 16- 17) seu novo vetor de dist•'ncias. A Figura -4.3l (a) ílustra um cenário em que o custo do enlace de y a x muda de -4 para l. Destacamos aqui somente os registros na tabela de d•stãndas de y e< até o destino x. O algoritmo OV causa a ocorrtncia da seguinte sequencia de C\'cntos: No tempo 10 , y detecta a mudança no custo do enlace (o custo mudou de 4 para l ) . atualiza seu ''etor de dlstãnc•as e informa essa mudança a seus \'izinhos, já que o vetor mudou. No tempo 11• < recebe a atualizaç-.lo de y e atualiza sua própria tabela, Calcula um novo menor custo para x (cujo custo diminuiu de 5 para 2), c envia seu novo vetor de disuinclas a seus vizmhos. No tempo t !, y recebe a awalização dez e aiUaliza sua tabela de distancias. Os menores custos de y nào mudar.H11 c, por conseguinte, y não envia ncnllltma mensagem a z. O :1lgoritmo entra em estado de inatividade. Assim, apenas clu:IS itcraçOes são necessárias para o a lgoritmo DV a lcançar o estado de inatividade. A boa notrcia sobre a redução do custo entre x e y se propugou rapid;tmcntc pela rede. Agom vamos considerar o que pode acontecer quando o custo de um enlace tlumcHtcl. Suponha que o custo do enlace entre x r y aumente de 4 para 60, como mostra a Figura 4.3l(b).

L Ames da mu<.lnnça do custo do enlace, D, (x) = 4, D, (z) = l , D:(y) = l , c D. (x) = S. No tempo'~· y detecta uma mudança no custo do enlace (o custo mudou ele 4 para 60). y calcula seu novo c:~minho de custo mínimo :ué x. de modo a ter um custo de D,(x)

= minlc(y. x) + D,(x), c(y, <) + D<(x)) = min(60 + 0 ,1 + 51 = 6

I! claro que, com nossa visão global da rede, podemos ver que esse novo custo via :: CSlá errado. Mas as únicas tnformaçOes que o nó y tem é q ue seu custo direto até x é 60 e que z disse a y que ~ pode cheg:u a x com um custo de 5. Ass11n, para chegar a x. y teria de fazer a rota atm,•ts de z. com a expectauva de que
=

a.

Figura 4.31

Mudanças no
b.

bow4tto4ic~ A co111oda de rede

Capítulo •

2.81

4. De manen-a scmclh:mtc, após receber o novo ''ctor de distâncias de t. y detcrmma O,(x)= 8 c envia a t seu vetor de d1stãnc•as. Em
Algoritmo de vetor de distâncias: adição de reversão envenenada O cenário especifico de looping que acabamos de descrever pode ser evitado usando uma técnica denominada rc,•crs:lo envenenada (l'oisoncc/ rrvcrsc). A idcia é simples- se a rota de t pam c hegar a x p;tSsa por y, então t deve anunciar a y que s ua distancia a x é infinita. isto é. z anunciará a y QLIC O.(.x) oo (mesmo qt1c Irxidmle ela mensagem. Vimos que o LS requer que cada nó saiba o custo de cada enlace da rede. Isso exige que sejam enviadas O(INI lEI). E, também, sempre que o custo de um enlace muda, o novo custo deve ser enviado a todos os nós. O algoriuno DV requer troc:t de mensagens emre vizinhos diretamente conectados a cada iteração. Já vimos que o tempo necessário para que o algoritmo convirja pode depender de muitos fatores. Quando o custo do enlace muda, o algoritmo DV propaga os resultados do custo modificado do enlace somente se o novo custo resultar em mud:mc;a no caminho de menor custo para um dos nós lig.-.do ao enlace. Vc/ocldmlr dr com•erglucw. Já \'Ímos que nossa impkmcntaç:lo de LS é um algoritmo O(INil) que requer O(NI lEI) mensagens. O algoriuno DV pode convergir lentamente c pode ter loops de roteamento enquanto estiver convergindo. O algori uno DV também tem o problema da contagem até o infinito.

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------Robusft'~.

O que pode acoruecer se um roteador falhar. se comportar mal ou for sabotado? Sob o LS, um roteador poderia transmitir um custo incorreto para um de seus enlaces dtretos (mas não para outros). Um nó poderia tam!Xm corromper ou descartar quaisquer pacotes rcccbtdos como pa11c de uma transmiss.lo de estado de enlace. Mas um nó LS está calculando somente suas próprias tabelas de roteamento; os outros nós estão realizando cálculos semelhantes para SI próprios. Isso significa que, sob o LS, os cálculos de rota são, de cena fonna. isolados, fornecendo um grau de robustez. Sob o DV, um nó pode anunciar incorrctamenLe caminhos de menor custo para qualquer destino, ou para todos os destinos. (Na verdade, em 1997, um roteador que estava funcionando mal em um pequeno ISP forneceu aos roteadores nacionais de backbone tabelas de ro teamento errôneas. Isso fez com que outros roteadores inundassem de tráfego o roteador que estava funcionando mal. Com isso, grandes por(ôcs da Internet ficaram desconectadas durante muitas horas INcumann. 19971 .) De modo geral. not
Outros algoritmos de roteamento Os algoritmos LS c OV que eslUdnmos não somente srto utilizados em grande escala "'' prátiea, mas também S<\O, essencialmente, os •micos algoritmos utilizados hoje na In ternet. Não obstante, muitos algoritmos de roteamento foram propostos por pesquisadores nos últimos 30 anos, abrangendo desde o extremamente simples ;lté o muito sofistiC'.tdo c complexo. Há uma grande classe de algoritmos de roteamento cuja base é considerar o tráfego como nuxos entre fontes e destinos em uma rede. Nessa abordagem. o problema do roteamento pode ser formulado em termos matemáticos como um problema de otim1zaçilo restrita, conhecido como problema de nuxo da rede IBensckas, 19911. Ainda um outro conjumo de algoritmos de roteamento que mencionamos aqui são os derivados do mundo da telefonia. Esses a lgoritmos d e ro teamento d e comutação d e circui tos são d e interesse para redes de comutaçllo de circuitos nos casos em que de,·em ser reservados recursos (por exemplo, buffcrs ou uma fraç:'o da largura de banda do enlace) por enla· cc para cada conexllo roteada pelo enlace. Emborn a formulação do problema do roteamento talvez pareça bem diferente da fomlllla~":''o do problema do ro teamento de menor custo que vimos neste c;1pftulo, existem muitas ~cmclhanças, :10 menos no que se refcrt' ao algoritmo de buS<_·a de caminhos (algori tmo d e roteamento). Veja IAsh, 1998; Ross, 1995: Girard, 19901 para uma discussão detalhada dessa área de pesquisa.

4.5.3 Roteamento hierárquico Q11ando l'St ud:~mos os a lgoritmos LS c DV, consideramos a rede simples mente como uma colcc;t\o de roteadores lntcrconectaclos. Um roteador não se distinguia de outro no sentido de que tod os rodava m o mesmo algoritmo de rote;uHento pam calcular os caminhos de rote:~mcmo pela rede inteira. N:• práLiclt, esse modelo c s~~a visão de um conjunto ltomog(;nco de roteado res, todos rodando o mesmo algoritmo de roteamento, (: um tanto simplista por pelo menos duas razões impor"mtes: Escclln. A medida que aumenta o número de roteadores, a sobrecarga relativa ao cálculo, ao armazenamento c ;\ comunh.:ac;:io de informações para a tabela de roteamento (por exemplo, atualizações de estado de enlace ou de mudan(,'ll no caminho de menor custo) se torna proibitiv:J. A Internet públil'll de hoje consiste em centenas de milhões de hospedeiros. Arm.-.zenar 10formaçoes de roteamento para cada um desses hospedeiros evidentemente exigiria quantidades enormes de memória. Com a sobrecarga exigida para transmitir atualizações do estado de enlace entre todos os roteadores da lntcrrtct não sobra na nenhuma largura d e banda para enviar pacotes de dados! Um algoritmo OV que fizesse iterações entre esse número tão grande de roteadores seguramente jamais convergiria! Ftca claro que algo deve ser feito para reduzir a complexidade do cálculo de rotas em redes tão grandes como a Internet pública.


A ca11oda de rede

Aulonomía crclmínistrlllí\'a. Embora os pesquisadores tendam a ignorar questões como o desejo das empresas de controlt1r seus roteadores como bem entendem ( por exemplo, rodt1r qu:tlquer t1lgoritmo de roteamento que escolherem) ou ocultar do público externo aspectos da organizaç.'o interna das redes, essas considerações são importantes. Idealmente, uma organizaç:lo deveria poder exceltlar c adnumstrar sua rede como bem ente ndesse. man tendo a capaccdade de conectar su:t rede a outras redes externas.

Esses problcm:\S podem ser rcsohidos agmpru1do roteadores em sistemas autônomos (mclonomous systcrns- ASs) . com cada AS cons istindo em um grupo de roteadores sob o mesmo controle admimstmtivo (isto é, operados pelo mesmo ISP ou pertencentes a uma mesma rede corporativa). Todos os roteadores dentro do mesmo AS rodam o mesmo algoritmo de rotea mento ( por exemplo. algoritmo LS ou OV) c dispõem das inform:wõcs sobre cada um dos o utros- exatamente como foi o caso do modelo idealizado da scçJo ante rior. O algoritmo de roteamento que roda dentro ele um A é denominado um p ro to colo de rotea mento intrassistema aut ôno mo. 1 ; claro que será neccss:lrio concc t<~r os ASs entre sí c, assi m. u m ou mais dos roteadores em um AS terá a tarefa adicional de ficar respo nsável por transmitir pacotes a desti nos externos ao AS- esses roteado res são denominados roteadore.~ d e b ord a (gmewtt)' rotrUr:ç), A Figura 4.32 ilus tra um exemplo si mples com trcs ASs: ASl, AS2 E AS3. Na figura , as li n has escuras rcprcsent:uu conexões diretas de enl:tces entre pnres c roteadores. As linhas mais n nas c intcrrompid:1s que saem dos roteadores reprcscuuun sub-redes conectadas di rcwmcntc a eles. O AS l tem quatro rotc:.dores, l.a, l.b, l.c c Lei. e cada qua l roda o protocolo de roteamento utilizado dcmro do AS J. Assim , cada um dcssc:s quatro roteadores s:tbc como trans mitir pacotes ao longo do caminho ótimo para qualquer des tino dentro de ASL De maneira semelhante. cada um dos sistemas autônomos A$2 c AS3 tem tr~ roteadores. Note q ue os protocolos de roteamento intrn -AS que rodam em AS I , AS2 e AS3 não precisam ser os mesmos. Note também que os roteadores l b, I c, 2a c 3a sJo roteadores de borda. Agora j:\ deve estar claro como os roteadores em um AS determinam caminhos de roteamento para pares fome·desúno internos ao sistem:t. M:cs ainda há uma peça faltando nesse q uebra-cabc\'3 de roteamento fim a fim. Como um rotc:tdor que cst:\ dentro de algum AS sabe como rotear um pacote até um desuno que está fora do AS? Essa pergunta t f•lcil de responder se o AS tiver somente um roteador de borda que se conccta com somente um outro AS. Nesse caso. como o algoritmo de roteamento int.nl·AS do sistema <~utOnomo dctenmnou o caminho de menor custo entre cada roteador in terno e o roteador de borda, c;~da roteador in temo sabe como deve enviar o pacote. Ao receber o p;1cote, o roteador de borda o repassa par.t o unico enlace que le,'a ao exterior do AS. l:nt
AS1

Figura 4.32 Um exemplo de sistemas autônomos interconedodos


extrcmid:lde do enlace assume a responsabilidade de rotear o pacote at~ ~u destino final. Como exemplo, supor1ha que o roteador 2b da Figura -t.32 receba um pacote cujo destino está fora do AS2. O roteador 2b cnt:lo transmite o pacote ao roteador 2a ou 2c, como es~cincado pela tabela de repasse do roteador 2b, que foi conflgurada pelo protocolo de roteamento mtrn·AS de AS2. O pacote eventualmente chegará ao roteador de borda 2a, que o retransmitirâ ao roteador I b. Tilo logo o P

Aprende por um protocolo inter-AS que a sub-rede x pode ser alcan~ada via vjrios roteadores de borda

Usa informações de roteamento do protocolo intra·AS para determinar custos de caminhos de menor custo para cada um dos roteadores de borda.

Roteamento da batata quente: escolhe o roteador de borda que tenha o menor cus1o.

A u11oda de rede

285

Determina, peta tabela de repasse, a interface I que leva ao roteador de borda de menor custo. Adiciona (x.l) à tabela de repasse.

Figura 4.33 Etopos do odiçõo de um destino f01o do AS ô tobefo de repasse de um roteador

Lembre-se de que dissemos na Scçfto 1.5 que a internet consiste em uma hierarquia de ISPs intcrconcctados. Então, qual é a re luç;\o entre ISPs c ASs? Voe~ talvez pense que os ro1cndorcs crn um lSP c os enlace.'> qne os intcrconectam cons1itucm um ünko AS. Embora esse seja frequentemente o caso, muitos lSPs d i'•idcm SLia rede em vdrlos ASs. Por exemplo, alguns ISPs de nível 1 utilizam 11m AS para toda a sua rede; outros subd ivide m sua rede em dezenas de ASs imcrconcctaclos. Em res umo. os problemas de escala e de autoridade administrativa são resoh•idos pcln definlç-.lo de sistemas autônomos. Dentro de um AS, todos os roteadores rodam o mesmo protocolo de roteamen to intrnssistema autônomo. Entre eles. os ASs rodam o mesmo protocolo de roleamento intcr·r\S. O problema ele esl·a la é resolvido porque um roteador illlra· AS preciSa saber apenas dos outros roteadores dentro do AS. O problema de autoridade ad ministmti\':l t resolvido. já que uma organização pode rodar o protocolo ele roteamento intra-AS que quiser; todavia , cada par de t\Ss conectados precisa rodar o mesmo protocolo de roteamento inter-AS para trocar infor· mações de alcançabthdade. ' a scço'lo seguinte. examinaremos dois protocolos de roteamento intm·AS (RI P c OSPF) c o protocolo inter· AS ( BGP). que são usados na Internet de hoje. Esses estudos de casos dão um bom arremate ao nosso estudo de roteamento hierárquico.

4.6 Roteamento no Internet ;\ gora que já esllldamos endereçamento na Internet c o protocolo IP, vamos vohar nossa atcnç!lo aos pro tocolos ele roteamento da Internet. A tarefa desses protocolos é determinar o caminho tomado por um datagrama entre a fome c o des tino. Veremos que os protocolos de roteamento da lntcmetlncorporam muitos dos princípios que aprendemos anteriormente nes1e c:~plt ulo. As abordagens de estado ele enlace c de vetor de distâncias estuda· dtts nas seções 4.5.1 c 4.5.2 e a ide ia de um sistema autonorno considerada na Scç;\o 4.5.3 s;\o fundamentais para o mod o como o roteamento é feito na lnlcrnet de hoje. Lembre-se ele que na Seç;\o 4.5.3 vi mos que um sistema autônomo (AS) t um conj unto de roteadores que estilo so b o mesmo contro le ad ministrativo e técnico e que. rodam, tod os, o mesmo protocolo de roteamento entre eles. Cada AS, por sua vez, normalmente comém várias sub-redes (aqui, usamos o termo sub-rede no sentido preciso de endereçamento, como na Seç;\o 4.4.2).

4.6.1

Roteamento intro-ASno Internet: RIP

Um protocolo de roteamento intra-AS é usado par.1 detenninar como é rodado o roteamento dentro de um sistema autônomo (AS). Protocolos de roteamemo intra·AS são lambem conhecidos como pro tocolos de rotea· d ores internos ( JGP - Interior Gattway Prouuols). Historicamente, do1s protocolos de roteamento tem sido usados extcnsh":lmente para roteamento dentro de um sis tema autônomo na Internet: o RIP (Routing Infomwtion Protocol - Protocolo de lnforma\'ãO ele Roteamento) c o OSPf (OJ>CII sltollcsr {XIIII first ). Um protocolo muito relacio nado com o OSPF é o protocolo IS·IS [RFC 1142, Perlman, 1999). Em primeiro lugar, discuti remos o RIP e, em seguida, consideraremos o OSPF.


O RIP foi um dos prim~iros protocolos de roteamenlo inu·a-AS da Lmcrnet, e seu uso é ainda amplameme disseminado. Sua origem c seu nome podem ser lraçados até a arquitetura XNS (Xerox Nctwork Syst~ms) . A ampla dtSpomb•lização do RIP se deveu em grande pane à sua inclusM, em 1982, na versão do UNIX do Bcrkcley Software Oistribution (850). que supon:wa TCP/IP. A versao Ldo RIP está derlnida no (RFC 10581 e a Vet'Si10 2. compatível com a versão J, no (RFC 2453). O RIP é um protocolo de vetor de distâncias que funciona de um modo muno parecido com o protocolo OV idealizado que exammamos na Seção 4.5.2. A verSão do RIP espccirlcada no RFC 1058 usa contagem de saltos como mélrica de custo, isto é, cada enlace tem um custo I. Por simplicidade, no algoritmo OV da Seção 4.5.2 os custos foram definidos emre pares de roteadores. No RIP (c também no OSPF), na realidade, os custos São deOnidos desde um roteador de origem até uJna sub-rede de destino. O RIP usa o termo salto, que é o numero de sub-redes percorridas ao longo do caminho mais curlo entre o roteador de origem c uma sub-rede de destino, incluindo a sub-rede de destino. A Figura 4.34 ilustra um AS com seis sub-redes folha. A tabela ela figura indica o número de saltos desdr o ro teador de origem A até todas as sub-redes folha . O custo máximo de um caminho ê limitado a 15. limltar1do assim o uso elo RIPa sistemas autônomos que tj!m menos de 15 saltos de dHimetro. lembre-se de que em protocolos DV, roteadores vizinl1os trocam veto res ele dist:lncia entre si. O vetor de dist:lncius para qualquer roteador é a estinmtiva corrente das clist:lncias dos t":\minhos de menor custo entre aquele roteador c as sub-redes no AS. No RIP, wbclas de rou~amento s:lo trocadas entre vizinhos a <:ada 30 segundos :1proximadamcnte. usando uma mensagem de resposta RlP. A mcns:tgcm de resposta cnviad:1 por uni roteador ou um hospedeiro contém uma lista de até 25 sub-redes de destino dentro do AS, bem como as distâncias entre o remetente e cada uma dessas sub-redes. Mensagens de resposta também são conhecidas como anúncios RIP. Vamos exammar um exemplo simples de como funcionam os anúncios RIP. Considere a parte de um AS mostrada na Figura 4 .35. Nessa rigura, as linhas que conectam os roteadores representam sub-redes. Somente os roteadores (A, B, C c D) c as redes (w, x , y, z) selecionados são rotulados. As linhas tracejadas

indicam que o AS continua; portanto, esse sistema au tônomo tem muito mais roteadores c enlaces do que os mostrados na figura . Cada roteador mantém uma tabela RJP denomínada tabela de roteamento. A wbela de roteamento de um roteador inclui o \'Ctor de dist•\ncias e a tabela de repasse desse roteador. A F•gura 4.36 mostra a tabrlll de roteamento do roteador D. Note que a tabela de roteamento tem trêS colunas. A primeira coluna é para a sub-rede de destino, a segunda coluna indica a identidade do roteador seguinte ao longo do caminho m:1is curto até a sub-rede de desuno c a terceira coluna Indica o numero de saltos (isto é. o número de sub-redes que I em de ser atravcss;Jdas, incluindo a rede de destino) para chegar :'1 sub-rede de destino ao longo do t
1

v

2 2

w X

y

z Figura 4.34

Número de soltos do roteador de origem, A, atévários sub-redes

Saltos

3 3 2


A ca11oda de rede

2.87

figura 4.35 Umo pcllte de um sistema autônomo Suponha ngom que 30 segundos mais urde o roteador D receba do roteador A o t~núncio mostrndo na Figura 4.37. Note que esse :-.n(lncio nada mais é do que inrormações da tabela de roteamento do roteador A! Ess.1 inror· maç-Jo indica, em particular, qLte a sub-rede~ está a apenas quatro saltos do roteador A. Ao receber esse am\nclo, o rott'ador Do funde (P'igurn 4.37) com a tabela de roteamento a111iga (F igura 4.3ó). Em particular, o roteador D Oca sabendo que agora h;\ um novo caminho através do roteador A até a sub-rede z que é mais curto do que o caminho pelo roteador B. Assim, o roteador D atualiza s ua tabela de rotc:tmento para levar em coma o tn;lis curto dos caminhos rtmis curtos, como mostra a Figura 4.38. Voe~ podcri~t pcrgumar como o caminho mais curto até a sub-rede z se tornou mais curto ainda? Possivelmente, o algoritmo de vetor de dist;1 ncias descentralizado ainda eswv;t em processo de convcrgéncia (veja a Seção 4.5.2) ou, talvez, novos enlaces e/ou roteadores tenham sido adicionados ao AS. mud:mdo assim os caminhos mais curtos dentro dele. Vamos agora considcmr alguns dos aspectos da ímplemcntaç;lo do RIP. Lembre-se de que os roteadores RIP trocam anuncios a t-adn 30 segundos aproximadameme. Se um roteador m\o ouvir nada de seu vizinho ao menos uma vez a cada 180 segundos, esse vizinho sera considerado imposs1vcl de ser alcançado dali em diante, isLO é , o vizinho cst:i inopcramc ou o enlace de concx;io caiu. Quando isso acontece. o RJI> modiOca a tabela de roteamento local e, em seguida, propaga essa informação enviando an(lncios a seus roteadores vizinhos (os que ainda podem ser alcançados). Um roteador pode também requisitar inrorrnação sobre o custo de seu vizinho até um dado destino usando uma mensagem de rcquisi"\o RIP. Roteadores em;am mensagens RIP de requisição c de resposta uns aos outros usando o numero de porta 520. O scgmemo UDP é carregado emrc roteadores dentro de um datagrama IP padr3o. O fato de o RIP usar um protocolo de camada de transporte (UDP) sobre um protocolo de camada de rede (IP) para implcmcnt:u runcionalidade de camada de rede (um algoritmo de roteamento) pode p:trcccr bastante con· ruso (c é! ). Um exame mais prorundo sobre como o RIP é implementado esclarecerá e:.sc assunto. A Figura 4.39 ilustra esquematicamente corno o RlP é comumcmc implementado em um sis1cma UNIX, como, por exemplo, uma cstaç;'o de traiYo1lho UN IX que estt\ servindo como um roteador. Um processo denomimtdo rourrd rodfl o RIP, isto é, mantém inrormaçoes de roteamento e troca mensagens com processos rourctl que rod tlm em roteadores vizinhos. Como o RlP é impleme:nt:ldOcomo um processo da camada de aplicação (se bem que um processo multo especial, que é capaz de manipular as tabelas de roteamento dentro do n(ldeo do UN lX), ele pocle enviar c receber mensagens por uma porta padnio e usar Lllll proto,olo de transporte padn\o. Assim, o RIP é um protocolo de camada de aplicaçllO (veja o Capftulo 2) que roda sobre Uf)P.

Sub-rede de dHtlno

Roteador seg uinte

Número de saltos at• o dest ino

w

A

2

y

B

2

B

7

X

Figura 4.36 Tabelo de roteamento no roteador Oantes de re
bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'-------------------------

Sub-l"ede de destino

z

Roteador segu inte

Numero de saltos att o destino

c

4

w X

Figura 4.37 Anúncio vindo do roteodor A

4.6.2 Roteamento intro·AS no Internet: OSPF Como o RIP. o roteamen to OSPF t usado amplamente para roteamc rllo intm-AS na In ternei. O OSPF c seu primo, 15-IS, muito p:•rce ido rom ele, sào eomumcmc disponibilizados em ISPs de nfvc is mais altos, ao passo que o RlP é diSJ>Onibillzado emiSPs de níveis mais baixos c redes corpor.u h"-ls. O 'opcn' do OSPF sig11i· Oca que OIS cspccific;~çOcs do r>rotocolo de roteamento eStilO dispon[\'CÍS uo público (no COIItrário do pro tocolo EIGRP da Cisco, por exemplo). A versão mais recente do OSPF, vers;lo 2 . está dcn nida no RFC 2178- u m documento ptlblico. O OSPF foi concebido como sucessor do RIP c como tal tem uma stric ele caracterls tic:as av;11wadas. Em S<'u à mago. contudo, ele é um protocolo de estado de enlace que usa bl'otulccrsting de informaç;lo de estado de enlace e u m algoritmo de caminho de menor custo de DijksLra. Com o OSPF, u m roteador constrói um mapa topológico completo ( isto é, um grafo) de todo o sistemtt tmtônomo. O roteador então rodtl localmente o ttlgoriuno do cammho mais curto de Dijkstm parn detem1inar uma árvore de caminho mais curto para todas as sul:>-redes, sendo ele própno o nó míz. Os custos de enlaces individuais são configurados pelo admmístrador da rede (veja Princfpios na prática: detcm1inando pesos OSPF). O administrador pode optar por estabelecer todos os custos de enlace em 1, conseguindo assim rote-dmcmo de salto mmímo, ou pode optar por designar para os enlaces pesos inversamente proporcionais à capacidade do enlace de modo a dcsincentivar o tráfego a usar enlaces de largura de banda baixa. O OSPF não impõe uma políLica parn o modo como sào detcrmmados os pesos dos enlaces (essa tarefa t do administrador da rede): em vez disso. prov~ os mecanismos ( protocolo) para detenninar o caminho de roteamento de menor custo p:ua u m dado conjunto de pesos de enlaces. Com OSPF, um ro teador transmite infonnações de rotcamcnto a rodos os outros roteadores no sistema autônomo, c não apenas a seus roteadores \'izinhos. Um roteador transmite mformaçõcs de estado de enlace sempre que houver uma mudança no estado de um enlace (por exemplo, uma n1udança de custo ou uma mudança de estado para cima/para baixo). Tombém transmite o estado de um enlace periodicamente (pelo menos a cada 30 minutos), mesmo que o estado não tenha mudado. O RFC 2328 observ:1 q ue "essa atualização periódica de anú ncios de enl ace ad iciona robustez ao algorítmo de estado de enlace". i\ n úndos OSPF s:'to contidos em mensagens OSPF que s:'o carregadas diretamente por IP, com um código protocolo ele c.-amada superio r igual a 89 para OSPF. Assim, o próprio protocolo OSPF tem de implemenmr func ionalidades como t ransfer~ncin confiável de mcnsngem c transmissilo bi'O(I(lwst de estado de enlace. O JHOtocolo OSPF 1ambém veriOc.-a se os cnbccs est.:'lo opcmcionals ( vk1 uma mensagem HELLO enviada a um vizinho ligado ao enl ace) c permite que um roteado r OSPF obtenhn o banco de dndos de um roteador vizinho referen te ao estndo elo enlace no ambilo da rede.

Sub-rede de destino

Roteador segu inte

Númvo de saltos at6 o destino

w

A

2

y

B

2

A

s

Figura 4.38 Tabelo de roteamento no roteador Oopós ter recebido anúncio do roteador A

bow4tto4ic~ A
Capí tulo •

Transporte

Transporte

(UDP)

(UDP)

Rede {IP)

I

Tabelas de repasse

I

IdeTabelas I repasse

Rede (IP)

Enlace

Enlace

Flsica

Flsica

'--

Figura 4.39 lmplementoçõo do RIP como um doemon routed

i\lguns dos :wanços im:orporados :\o OSPF

~\o:

Segura/Iça. Trocas entre roteadores OSPF ( por exemplo. atualizações do estado de enlace) são autcnticud:IS. A autcnticaç;Jo garan te que apenas rotc-Jdores de confianca podem participar do protocolo OSPF dentro de um AS, evitando, assim, que Intrusos mal-I ntencionados (o u estudantes de rede testando, por bríncadeim, seu con htdrncm o recenteJnt'llte adquirido) injetem informações incorretas em tabrlas de rotc;~mento. Por defauh, pacotes OSPF cmre roteadores n;\o slo autenticados e poderl:un ser forjados. Dois tipos de autcntícaçJo podem ser configu rados- simples c MD5 (veja o Capftulo 8 para urna dis· cussão sobre M05 c alllemicação em geral). Com autenticação simples. a mesma senha é configurada em cada roteador. Quando um roteador envia um pacote OSPF, inclui a senha em texto normal ( não cnptografado). J: claro que a autenticação simples não c seguro. A autenucação MD5 é baseada em cha,•es secreta~ compartilhadas que Sào configuradas em todos os rou.•adores. Para t~da pacote OSPF o roteador calcula o hash MD5 do contel\do do pacote adiciOnado com a chave secreta. (Consulte a discuss:lo sobre cód igos de autenticaç-Jo de mensagem no Capuulo 7). O roteador inclui, então. o valor de hash resultan te no pacote OSPF. O roteador receptor. usando a chave secreta preconfigurada. calculará um hash MD5 do pacote o comparará com o valor de hash que o p;~cote carrega, \'Crificando assi m a autenticidade do pacote. Ntimeros de scqucncia também são utilizados com autenticação MD5 para protcç:lo contra ataq ues por reenvio. Caminhos mriltiplos ele igual cus10. Quando vários caminhos at~ o destino tl!rn o mesmo t'Usto. o OSPF permttc que sejam usados vários caminhos (is to é, não~ preciso escolher um canunho tinico para carregar todo o 11-dfego quando existem vários caminhos de igual custo).

irJCegmtlo IJlrrrr rotewncmo unicast e multlmst. O OSPF MuhiC'.tSI (MOSJ>F) IRFC 15841 fornece extensões simples ao OSPF para prover roteamento muhictrst (um tópico que exmnin;~remos com mais profundicl;\dc na Seção -+.8). O MOSPF usa o banco de dados de enlaces cxistcme no OSPF c ;~dicion;l umrtovo tipo de nnúncio ele estado de enlace ao mecanismo OSPF exis tente de transmissão de estado de enlace.

SllflOI'IC

S ujlOI te

purctlrit•mrquitl dentro de 11111 tinico domínio clr rotecmrclllo. Talvez o avanço mais significativo do OSPF seja a c:IJY.tcidade de cstrutumr hierarquicamente um sistcm:1 autOnorno. Na Scc,~o -+.5.3, vimos as muitas vantagens de estruturas de roteamento hierárquicas. Exami naremos a implementação do roteamento OSPf hier:\rquico no restante desta sec-.lo.

Um sistema amOnomo OSPF pode ser configurado hierarquicamente em áreas. Cada árc;~ roda seu próprio a lgoritmo de roteamento de estado de enlace OSPF, sendo que cada roteador em uma nrea transmite seu estado de enlace a todos os outros roteadores daquela área. Dentro de cada área, um ou mais roteadores d e borda de área são responsáveis pelo roteamento de pacotes fora da área. Por fim , exatamente uma área OSPF no AS é configurada para ser a área de backbone. O papel

bow4tto4ic~ Redes de com putod ores e o Inle ' .;;n.;;. e ;_ l ------------------------

Configurando os pesos de enlaces no OSPF Nosso discussão de roteomento de estodo de enlace admitiu implicitamente que os pesos dos enloces sõo deter· minodos, quo um algoritmo de roleornento como o OSPF ó rododo o que o trófogo flui de ocordo com os tabelas de roteomento colculada~ pela algoritmo LS. Em termo~ de cou~o e efeito, os pesos d~ enlaces sõo dado~ (i~to é, vêm em primeiro lugar) o resultam (via o algoritmo de Dijhtro) em caminhos do roteamento que minimizam o custo geral. Desse ponto de visto, pesos de enlaces refletem o custo do utilização de um enlace (por exemplo, se os pesos dos enlaces forem inversamente proporcionais o copocidode, enlõo o utilização de enlaces de oito copoc:ídode teria pesos menores e, assim, seriam mais atraentes do ponto de visto de roteamento} e o algoritmo de Dijkstro serve poro minimizar o custo geral. No PfÓiico, o reloçõo causo e eleito onlre p~sos de enlaces e caminhos do roteamento pode ser invertido - operodores de rede configu ram pesos de enloces de modo o obter caminhos de roteamento que cumpram certos metas do engenharia de trófego lforlz, 2000; Forlz, 2002j. Por exemplo, suponho que um operoclor de rede tenho uma eslimolivo de lluxo do tráfego que entro no rede em codo ponto de ingresso no rede e desti nado o cada ponto de soído do rode. Entõo, o operador poderio querer iMtituir um rolcomonto do trófogo do ponto do ingresso a té o ponto de saído que minimizasse o utilização mó.ximo em todos os enlaces do rede . Mos, com um a lgoritmo de roteamento como o OSPF, os principais controles de que o operador dispõe poro ajustar o roteamento de Ruxos através do rode sõo os pesos dos enloces. Assim, poro cumprir a meto do minimizar a utilização móximo do enlace, o ~rodor tem de descobrir o conjunto de pesos de enloces que oleonce esse objetivo. Euo é um inversõo do reloçõo causo e efeito - o roteamento de Ruxos desejado é conhecido o os pesos dos enlaces OSPF têm de ser encontrados de um modo tal que o algoritmo de roteamento OSPF resulte nesse roleomento de Auxos desejoclo.

primordial da área de baekbonc é rotear tráfego entre as outras áreas do AS. O backbonc sempre contém todos os roteadores de borda de área que est;\o dentro do AS c pode conter também roteadores que n;\o s;\o de borda. O roteamento intemrea dentro do AS requer que o pacote seja primcirnmcntc roteado mt um roteador de borda de área (roteamento intm·árca). em seguida roteado por meio do b.Jckbonc att o roteador de borda de área que está na área de destino c, cnt
4.6.3 Roteamentoexterno osistemas autônomos: BGP Acabamos de uprcndcr co mo ISPs utilizam RIP c OSPF pam determinar caminh os ótimos para pares fon te-desti no in ternos ao mes mo t\.S. Agom vamos exam inar como são determ inados caminhos para p:1rcs font e-desti no que abrangem voirios ASs. A vcrs;lo i do Protocolo de Roteador de Borda (Bordcr Gateway Pro tocol - BGP) , especlfícada 110 RFC 4271 (veja t;unbêm (RPC '1274; RFC 42761), é o padrão. ele Jacto, para rotea mento entre sistemas autônomos na Internet de hoje. Esse protocolo t comu mente denomi na· do BGP4 o u simplesmente BGP. Na qualidade de um pro tocolo de roteamento inter-ASs (veja Seção ·L5.3), o BGP provt a cada AS meios d e:

1. Obter de ASs vizi nh os infom1açocs de atingibilidade de sub-redes . 2. Propagar a mformaçM de atlngibílídade a todos os roteadores mtemos ao AS. 3. Determinar rotas 'boas' parn sub-red es com base na informaÇ!lO de alingibilidadc c na política do AS. O BGP, sobretudo , permite que cada sub- rede anuncie sua existtnc•a ao rest:mtc da lmcrnct. Uma subrede grita · Eu existo e estou aq ui" c o BGP garante que todos os ASs d:1 Interne t saib:1m da existência dessa sub-rede e como chegar até ela. Não fosse o BGP, cada sub-rede ficaria isolada -sozinha c desconhecida pelo

restante da Internet.


A u11oda de rede

Obásico do BGP O BGP é extremamente complexo; livros inteiros (oram dedicados ao assunto e muitas questões ainda não estão ehtr-JS (Yannuzzi, 20051 . Além disso, mesmo após ler os livros e os RFCs, ainda assun você talvez ache dífí· cil dominar o BGP totalmente sem ter trabalhado com ele na prática durante muitos meses (se não anos) como projcti!>ta ou administrador dr um lSP dr mvel superior. Não obstante. como o BGP é um protocolo absolutamentr criúco para a Internet- em ~ncia, é o protocolo que agrega tudo-, preeiS:\nlOS ao menos entender os aspectos rudimemares do seu funcionamento. Começamos descrevendo como o 8GP poderia funcionar no contexto do exemplo de rede simples que estudamos ameriormcmc na Scçào 4.5.3; aconselhamos que voce leia novamente esse material.

No 13GP. pares de roteadores trocam informações de roteamento por conexões TCP scmipermnncntes usando a porta 179. As conexões TCP semípermanemes para a rede da Figura 4.32 silo mostradas na Figura '1 .40. Normalmente ht\ uma dessas conexões BGP TCP para cada enlace que conecta diretamente dois roteadores que est:ote que as hnhas elas S<:Ssões BGP na Figura 4.40 nem sempre corrcspondcm aos enlaces fís1cos na Figura 4.32. O BGP permite que cada AS conheça quais destinos podem ser alca~u;ados \'la seus ASs \'IZinhos. Em BGP, os destinos n!lo s.lo hospedctros. mas prcftxos ciclcrizados. sendo que cada prefixo rcprescnt.1 uma sub-rede ou um conjunto de sub-redes. Assim, por exemplo, suponha que haja quatro sub-redes conectadas ao AS2: 138.16.64124. 138.16.65/2-1, 138.16.66/24 c 138.16.67124. O AS2 então poderia agregar os prefixos dessas quatro sub-redes e mihzar o BGP para anunciar ao ASl o prefixo un•co 138. 16.64122. Como outro cxcmr>lo. suponha que somente as primeiras tr~ dessas quatro sub-rc.des estão c.m AS2 c que a quarta sub-rede, 138.16.67124, está em AS3. Então, como descrito no quadro Princípios na Prática na Seção 4.4.2, os rotradores usam compatibilização de prcf'ixo mais longo paro rcp;\ssar d:uagrnmas. Portanto, o AS3 poderia anunciar a ASl o prefixo mais específico 138.16.67124 e o AS2 ai nda r>Oderia anunciar ao ASl o prefixo agregado 138.16.64/22.

Agom vamos cxamln:u como o BGP distribuiria informações sobre a atingibilidadc de prefixos pelas sessões BGP mostradas na Flgum 4.40. Como seria de esperar. u~ndo a sess~o cBGP entre os roteadores de borda 3a c lc. AS3 envia a AS I a lista de prefixos que podem ser alcançados a partir de A$3: c AS I envia a AS3 a lista de prefixos que podem ser alc;mç:ulos de AS I. De tnodo semelhante. AS 1 c AS2 trocam lnrormaçôcs de ;uingibilidade

3b

AS2

legenda: - - - ses~o e8GP ------ sess.\o iBGP

Figura 4.40 Sessões eBGP eiBGP

1d

2b


de prefixos por meio de seus rmeadorcs de borda lb e :Za. E, como tambtm em de esperar, quando um roteador de borda (em qualquer AS) recebe prefixos conhecidos pelo BGP. ele usa suas sessões i8GP para distribuir os prefixos aos outros roteadores no AS. Assim, todos os ro teadores no ASl se inforrnarJo sobre os prefixos de A$3, incluindo o roteador de borda lb. O roteador de borda lb (em ASl) pode reanuneiar a AS2 os preftxos de AS3. Quando um roteador (seja ou não de borda) rica sabendo de um novo prefixo. cria um registro para esse prefixo em sua tabela de repasse, como descrito na Seç-Jo 4.5.3.

Atributos de cominho e roteadores BGP Agora que já temos um conhecimento preliminar do BGP, \"llmos um pouco mais fundo (e, mesmo assim, estaremos varrendo para baixo do tapete algu ns dos det:~lh es menos Importantes!). 10 BGP. um sistema autonorno é idenuficado por seu níamcr o de sistema autôn omo (1\SN) globalmente exclusivo I RFC 19301 . (Tecnicamente, nem todo AS tem um ASN. Em partic ular, um slub AS que carregue somente tráfego do qual é uma fonte o u um d estino normalmente nilo ter::\ um ASN; ignoramos essa tccnicidade em nossa discussao para q ue os detalhc.s ni.'to nos impeçam de observar melhor o quadro geral.) Números de ASs, tal como e ndereços l t>, silo des ignados por emichtdes regionais ICANN de registro llú\NN, 20091. Quando um roteador anuncia um prefixo para uma sess.1o 13GP, Inclui \"'.:\rios atribucos BGP juntamente com o prcnxo. Na terminologia do BGP. um prefixo,jumamemc com seus mribmos, t denominado uma roca. Assim, pares BGP anunciam rot:ts uns aos outros. Dois dos atributos mais irnporwntes são A$-PA'fH c NEXT-HOP: 1\S-PAn r. Este atribmo contém os ASs pelos quais passou o :uulncio para o prefixo. Quando um prefixo é passado par:1 dentro de um AS, o AS adiciona seu ASN ao a tributo 1\S-PATH. Por exemplo, considere

a Figura 4.40 c suponha que o prefixo 138.16.64/24 seja anunciado primeiramente de A$2 para AS1; se ASl então :~nunciar o prefixo a AS3. o AS· PATH seria AS2 ASl. Roteadores usam o atributo AS-PAnt pam detectar c eviutr loopíng de anúncios; espedficamcru c. se um roteador perceber que seu AS está conud o na lista de caminhos. rejeitará o anúncio. Como discutiremos em breve, roteadores também usam o atributo A5-PATI-l ao escolher emre vários camin hos para o mesmo prefixo. Prover o enlace cntico entre os protocolos de rotea mento inter-AS c intm·AS. o NEXT-HOP possut uma suul mas tmportan te utilidade. O NEXT-HOP t. a tlltcifacc do rotcatlor que luicia o cH·JJcUll. Para compreender mais esse atribu to, vamos, novnmcmc, nos rcfcnr à Figura 4.40. Considere o que acontece quando o roteador de borda )a e m AS3 anuncia uma rota a um roteador de borda l c em ASl utiliz:~ndo c BGP. A rota inclui o prefixo anunciado, que chamaremos x, c um AS-PATH para o prefixo. Esse ;m úncio também inclui o NEXI-HOP. que to endereço IP da interrace 3a do roteador que conduz a lc. (Lembre-se de qu e um roteador possui diversos endereços IP. um para cada uma das interfaces.) Considere agora o que acontece quando o roteador l d é informado sobre essa rota pelo iBGP. Após descobrir essa ro ta pam x, o roteador Jd pode querer encaminhar pacotes para x ao lo ngo da ro ta, o u seja, o roteador I d pode querer incluir a e nt rad~t (x, I) em sua tabe la de repasse, na qua l I representa sua interface que inida o caminho de menor custo p:.rtindo de ld em dirc<,'âo ao roteador de borda l c. P:.ra determin:.r I, ld pro,·ê o endcrc~o lP no NEXT-IIO P a seu mód ulo de roteamento intm-AS. Observe que o algoritmo d e roteamento int ra-AS determinou o e nlace de menor cus to emrc lc c 3a. Desse caminho de menor custo de ld :'1 su b-rede l c-3:1, ld determina sua imerface do roteador I que inicia esse caminho e, emi.'to, adidona a entrada (x, I), sua tabela d e repasse. Até que enfim! Em resumo, o atribmo AS-PATH é usado por roteadores p:tra configurar suas tabelas de repasse :~dequadamente. A Figura -1.41 ilustra outra situação em que o AS-PATH é requisitado. Na figura , o AS I c o AS2 estão conectados por dois enlaces imerconectados. Um roteador AS I poderia descobrir duns rotas diferemes p.tr;t o mesmo prefixo x. Ess.'\S duas rotas poderiam ter o mesmo AS-PATH para x. mas poderiam ter diferentes valores , E.XT-HOP correspondentes aos enlaces interconectados. Utilizando os valores AS-PATH c o algontmo de roteamento intra·AS. o roteador pode determinar o custo do caminho para cada enlace interconectado e,emão, aplicar o roteamento batata quente (consulte Seção 4.5.3) para determinar a imerface apropriada.


A uruda de rede

2.93

AS2

O roteador é informado sobre uma - - rota para x

O roteador é informado sobre outra rota para x Legenda: Mensagens de anúncio de rota para o de$tino x

Figura 4.41 Allibutos NEXT·HOP em anúncios servem poro deteminor qual enloce inteKonectodo uHiizor O BGP tambtm inclui :mibutos que permitem que roteadores designem a métrica de Slta prefer~ncia iiS rotas, c um atributo que indica como o prefixo foi inserido uo BGP na origem. Para uma discussão completa de atributos de rota, \'eja (GrHfin, 2009; Stcwart, 1999; Halabi, 1000; Fcamstcr, 2004 ; RFC 42711. Quando um roteador de borda recebe um anuncio de roteador, ele utiliza s ua polltka de importação para decidir se accila ou filtra a rota c se estabelece certos a tributos, tal corno a métrica de prcfcrCncia do roteador. A polnica de importação pode filtrar uma rota porque o AS pode não querer enviar trMcgo por um dos ASs no AS·PATH. O roteador de borda tambón pode filtrar uma rota porque já conhece uma rota preferencial para o mesmo prefixo.

Seleção de roto do BGP Como descrito antcrionncnte nesta seção, o BGP usa eBGP c iBGP para distribuir rotas a todos os roteadores dentro de ASs. Com essa distribuiçt\o, um roteador pode conhecer mais do que uma rota para qualquer prefixo determinado, caso em <1ue deve selecionar uma das rotas ~f"cis. O dado usado por esse processo de seleçllo de ro ta é o conJunto de todas as rotas que o roteador conhece c aceitou. Se houver duas ou mais rotas para o mesmo prefixo. então o BGP invcx:-a scqucncialmcntc as seguintes regras de eliminaçllo alé sobrar npcnas uma rota: Rotas recebem, como um de seus atributos, um valor de prefcrCncia local. A prefcr~nci:l local de uma rota pode ter sido estabelecida pelo ro teador o u pode ter sldo aprcndídn por um oull'o roteador no mes mo AS. Essa é uma decisão política que fit-a a cargo do administrador d:t rede do AS. (Mais adiante cliscLuircmos questões de politica do SGP.) São selecionadas as rotas que tCm os valores de preferência local m:1is nhos. No l"asO d:.s outras rotas remnnescentes (todas com o mesmo valor de prcfer~llci:J local), é selecionadn a rota que tenha o AS-PATH mais curto. Se essa fosse a única regra de selc~·ão de rotas, então o BGP cstari:. us:.ndo um :.lgorit rno DV para determinação de cannnho no qu:tl :1 métrica da distância utiliza o numero de saltos de AS em vez do número de saltos de roteadores. Dentre as rotas remanescentes (todas com o mesmo valor de prdcr~ncia l
bow4tto4ic~ Redes de computadores e o Interne~!-----------------------As regras de eliminaçtlo stlo ainda mais complicadas do que descrevemos aqui. Para evitar pesadl.'los com o BGP. é melhor aprender suas regras de sele~·ào em pequenas doses!

Político de roteamento Vamos ilustrar alguns dos conceitos básicos do roteamento BGP com um exemplo simples. A Figura 4.-f2 mostra seis sistemas autônomos imcrconcctados: A. B. C. W, X. e Y. ~ importante notar que A. B. C, W. X. c Y são ASs. c não roteadores. Vamos admi tir que os sistemas autônomos W, X. e Y s.lo redes stub e que A, B, e C sao redes provedoras de backbone. AdmilirE:mos também que A, B c C. todos conectados uns aos outros, fornecem informação compleHt sobre o BGP a suas redes clieme. Todo o tráfego que entrar ern uma rede stub deve ser des tinado a essa rede, e todo o trnfcgo q ue S.'lir da rede stub deve ter sido originado naquela rede. W e Y s~\o claramcn1c redes stub. X é uma rede s tub com múltiplas interconexões. visto q ue est:l conectado ao resto da rede por meio de dois provedores diferentes (um cenario que está se tornando cada vez mais comum na prática). Todavia, tal eo1no W e Y. o próprio X deve ser a origem/destino de todo o trMcgo que entra/sai de X. Mas, como esse comportamento da rede stub sem implementado e imposto? Como X ser:\ impedido de repassar tráfego entre B c C? Isso pode ser conseguido facihncnte controlando o modo como as rotas BGP s(IO anunciadas. Em particular, X funclon:~m como unu1 rede stub se anunciar (a seus vizinhos B c C) que não h:\ nenhum caminho para quillsqucr ou tros dcs1inos :1 não ser ele mesmo. Isto é, mesmo que X conhcç:1 um ç:unlnho, digamos, XCY, que chegue até a rede Y, ele m1o anunciará esse caminho a B. Uma vez que B n:lo f'ic~1 sabendo que X tem um caminho para Y, B nunca repassaria tráfego destinado a Y (ou a C) via X. Esse exemplo simples Ilustra co rno uma política seletiva de anuncio de rota pode ser usada para implementar relacionamentos de rote
Em seguida, vamos focalizar uma rede provedora, digamos AS B. Su ponha que Bficasse sabendo (por A), que A 1em um caminho AW para W . Assim, B pode instalar a rota BAW em s ua base de mformac;Oes de rotl'l!memo. É claro que B também quer anunciar o caminho BA W a seu cliente, X, de modo que X saiba que pode roll'llr para W \'ia 6. Mas, B dc\'eria anunciar o caminho BA \V a C? Se o fizer, então C poderia rotear tráfego para W via CBAW. Se t\, 8 c C forem todos provedores de backbone, cnt{IO B poderia sentir-se no direito de achar que não deveria ler de suportar a carga (c o custo!) de carregar tr:lfcgo em tn\nsho entre A c 6. 8 poderia sentir-se no direito de achar que é de A e C o trabalho (c o custo) de garantir que C possa rotear de/para chcntcs de A via uma conexão direta crurc A c C. Atualmente não existe nenhum padrão oficial que determine como ISPs de backbone devem ro1car entre si. Todavia, os ISPs comerciais adotam uma regra prntica que diz que qualquer tmfego que esteja nuindo por uma rede de backbonc de um ISP deve ter ou uma origem ou um desuno (ou ambos) em uma rede que seja d1ente daquele ISP: c:~so contrário, o tráfego estaria pegando uma carona gratuita na rede do ISI'. Acordos individuais de parceria (prcring) (pnra reger questões como as levantadas acima) normalmcnle s.lo negociados entre pares de ISPs c, em geral. sflo confidenciais; (Huston, 1999a] provê uma discussflo interessa rue sobre acordos de parceria. Se quiser uma descrici\o de ta lhada sobre como a política de roteamento renete os relaciona mentos co merciais em rc ISPs, veja IGao, 2001; Drnitiropoulos, 2007). P<~ra uma abordagem recente sobre políticas de roteamento BGl". de um po1110 de vislo do ISP, consuhe [Caesar, 2005). Como j:l obscr,•amos, o BGP é um padrão de flwo p:\ra roteamento inter-AS na lnLernct pt"tblic:~. Para ver o con teúdo ele várias tabelas ele roteamento BGP (grandes1) extmídas de roteadores pertencentes a ISPs de nível L. c:onsuhc hup://www.routevicws.org. Tabelas de rolcamento BGP geralmente contem clezcnl\S de milhares de

legenda: 8

w--

A

c

provedor

/

Rede do

-- y

Figura 4.42 Um cenário BGP simples

Rede do

--............_X

cliente


A co11odo de rede

2.95

prcnxos c atributos correspondentes. EstaLísticas sobre tamanho c camctcrlsticas de tabelas de ro teamento BGP sào apresentadas em (Huston, 2001; Meng, 2005: Potaroo, 2009) . Com isso concluímos nossa breve introduç-.io ao BGP. Entender ~ protocolo ~ importante porque ele desempenha um papel centml na Internet. Aconselhamos voe~ a consultar as refer~nci:~s (Griffin, 2002: Stewart, 1999: L:lbovuz. 1997; ll.tlabl, 2000; Huilcrna. 1998; Gao. 2001: Feams tcr. 2004. Cacsar, 2005; LI , 2007( pam aprender mais sobre BGP.

4.7 Roteamento broodcost e multicost Até este ponto do capítulo. focalizamos protocolos de roteamento que suportam comunicação uniCCISI (Isto t, ponto n ponto) na qual um único nó de ro ntc envia um pacote a um tinico nó de destino. Nesta scç;lo, voltaremos noss.1 :nenç;'lo a protocolos de roteamento lmw(lcasr c mullicasl. No roteamento bro adcas t a camada de re
Por que hó diferentes protocolos de roteamentointer-AS eintro-AS? Agora que já exominomos os detalhes de protocolos de roteamento inter·AS e intro-AS específicos uti· lizodos pelo Internet de hoje, vamos concluir considerando o questõo talvez mois fundomentol que, antes de mais nado, poderíamos levontor sobre esses protocolos (esperamos que voei lenho estado preocupado com isso o tempo todo e que nõo tenho deixado de enxergar o quodro geral por eouso dos detolhesl). Por que sõo usodos diferentes protocolos de roteamento inter-AS e intro·AS? A resposto o essa pergunto expõe o õmogo do diferença entre os objetivos do roteamento interno o um AS e entre ASs: • Político. Entre ASs, os questõe$ políticos dominom. Pode otê ser importante que o tráfego que se origino em um dodo AS não posso possor através de um outro AS específico. De maneiro semelhante, um dado AS pode muito bem querer controlar o tráfego em trõnsito que ele corrego entre outros ASs. Vimos que o BGP carrego atributos de cominho e oferece dislriboiçõo controlodo de informação de roteomento, de modo que essos decisões de roteamento boseodos em políticos possam ser tomados. Dentro de um AS. tudo está nomí· nolmente sob o mesmo controle odminislrolivo. Assim, os questões de políticos de roteamento desempenham um papel bem monos importante no eM;olha de rolos dentro do AS. • Escolobilidode. A escolobllidode de um olgoritmo de roteamento e de s.uos esiN1vros de dados poro manipular o roteamento poro/entre grandes números de redes é umo questão fundamental poro o roteamento inter·AS. Dentro de um AS, o escolobilidode é umo preocu~õo menor. lsso porque, se um único domfnio odministrotivo licor muito grande, é sempre possível dividi.lo em dois ASs e realizar roleomento inter-AS entre esses dois novos ASs. (lembre-se de que o OSPF permite que essa hierorquio seja construído dividindo um AS em árSO$.) • Desempenho. Dodo que o roteamento inter-AS é bastante orientodo pelos políticos, o qualidade (por exemplo, o desempenho) dos roleodores usodos é frequentemente umo preocupação secundário (isto é, umo roto mais longo ou de custo mois oito que satisfaço certos critérios políticos pode muito bem prevolecer sobre umo rolo que é mois curto, mos que nõo soti$(oz esses critérios). No verdade, vimos que entre ASs nõo hó nem mesmo o ideio de custo ossociodo às rolos (exceto o contagem de soltos). Dentro de um AS individual, contudo, es.sos preocu~ões com os políticos podem ser ignorodos, permitindo que o roteamento se concentre mais no nível de desempenho atingido em uma rota.


4.7.1 Algoritmos de roteamento broadcast Talvez o modo mais dirt'lo de conseguir comunicação b10aclcas1 é o nó remetente enviar uma cópia separada do pacote para cada destino, como mostra a Figurn 4.43(a). Dados N nós de destino. o nó da fonte simplesmente faz N cópias do p:tcote, endereça cada cópia a um destino diferente c cnt
Dadas as diversas dCS\'antagens do broadwsr de N caminhos, sJo claramente de interesse abordagens nas quais os própnos nós da rede desempenham u m papel ativo na d uplicaç-Jo de pacotes. no repasse de pacotes c no cálculo de rot:ts de brcx1
=

Inundação não controlada A t~cmca mais óbvia par:\ consegu ir broculcas~ é uma abordagem de inu ndação na qual o nó da rontc envia um n cópia do pacote a todos os seus vizi nhos. Quando um nó recebe um pacote briXulccrst. ele d Ltplica o pacote c o repassa a todos os seus vizinhos (exceto ao vizi nho do q ual recebeu o pacote). Ê claro que, se o graro ro r Criaç.a ollrammissão de duplicatas

él.

Figura 4.43 Duplicoçõo defonte versus duplicação dentrodo rede

b.


A co111oda de rede

2.97

conectado. esse esquema finalmente emregará uma cópia do pacote brooclcasr a todos os nós no grafo. Embora esse esquema seja simples c elcgame. tem tuna falha fatal (antes de continu:tr. teme imaginar qual seria essa falha) : se o grafo tiver ciclos, cnulo urna ou mais cópias de cada pacote de bromlwsr permanecerão em ciclo indefimdamcntc. Por exemplo, na Figura ... 43, R2 inundará R3, R3 inundará R,., R4 inundará R2 c R2 inundará (novamente!) R3 c assim por diante. Esse cenário simples resulta no c1clo sem fim de dois pacotes bromlcast, um em sentido horario c um em sentido anti-horário. M:lS pode ha,·cr uma falha fatal aind:~ mais catastrófica: quando um nó estiver conectado a mais de dois outros nós. criará c rcp:lSS:lrá \'li rias cópias do pacote broaclcast. cada uma das quais criam \'árias cópias de si mesmas (em outros nós com mais de dois vizinhos) c assi m por diante. EsS:l tempestade d e broadcast , gerada pela infindável muhiplie:~ção de p:~cotes btocu/((rst. 11nalmentc resultaria na cria~'âo de uma quantidade tào grande de pacotes brollCicast que a rede ficaria inutilizada. (ConStlhc nos exercíciOS de fixação ao final do capitulo um problema que analisa a velocidade com que essa tempe~aade de bromlcasl cresce.)

Inundação conlrolodo A chave p:m1 evitar uma tempestade de broculcciSI e um nó escolher sensatamente quando repassa um pacote (por exemplo, se já tiver recebido e repassado uma cópia anterior do pacote) c quando nfio repassa um pacote. Na pr:ltk,t, há vários modos de fazer isso. Na inundação comrolada com número de sequência, um nó de fonte coloca seu endereço (ou outro identifi<:ador exclusivo) , bem como um número de scqucncia de broa(lcnst em um pat'Otc broculwst c cn~<'o envia o p;~cote a todos os seus vizinhos. Cada nó mantém uma lista de endereços de fonte c números de sequencia para <."::da p;~cote br oclllcast que já recebeu, duplicou e repassou. Quando um nó recebe um pacote br oculcasl, primeiramente verirlca se o pacote está nCS5:1lista. Se esti,•er_ o pacote é des(.:art
bow4tto4ic~ Redes de compu tadores e o lnte;.;rn;.;e;.;,t_________________________

legenda: pacote (pkt) será repassado - . pacote {pkt) n&o será repassado além do rot eador recept or

Figuro 4.44 Repasse pelo
Broadcast por spanning tree Conquanto a inu ndação controlada com números de sequência e o RPF impeçam tempestades de !Jroadcasr. n~o evitam completa me me a trJnsmissâo de pacotes broculcctst redunda ntes. Por exemplo. na Figura -+.45. os nós B, C, D c F recebem ou um ou dois pac01es redundantes. Idealmente, cada nó de,•eria receber somente uma cópia do pacote btoculmst. Examinando a árvore formada pelos nós conectados por linhas grossas na Figura 4.-+5(a). podemos ver que, se os pacotes broculwst fo!>Sern repassados por enlaces dessa árvore. cada nó da rede receberia exatamente uma cópia do pacote broculctm- exatamente a solução que procuravamos! Esse é um exemplo de spanning treeurna árvore que contém todos os nós. sem exceção, em um grafo. Mais formalmente. uma spauuiug t1cc de um grafo G = (N, E) é um grafo G' = (N, E') tal q ue E' é um subconjunto de E, G' é conectado, G' nM contém nenhum ciclo c G' contém todos os nós originais em G. Se cada enlace li\'Cr um custo associado c o custo de uma án·ore for a soma dos custos d os enlaces, então uma á arvore cujo custo seja o nunimo e ntre todas as SfJ«uning trrcs do gráfico é denominada uma spanning tree mínima (o que não é nen h uma surpresa). Assi m, uma outra abordagem para o rornccimento de broatlrasr é os nós da rede const rufre rn u ma ~pauning IlCC , em primeiro lugar. Quando um nó de rome qu iser cmür um pacote browlmst, enviará o pacote por lodos

a. 8roadc.1st iniciado em A

Figura 4.4S Broodcost por umo sponningITee

b. Broadcast Iniciado em D


A
l99

os enlaces lncidcmcs que pcncnçam à spanning tree. Uau nó que receba um pacote b1oaclcast cnli\o o repassa a todos os seus ''izinhos na SJmnning trtt (exceto para o vizinho do qual recebeu o pacote). A spm111ing tru nào apenas elimina pacotes b1 otulcasr redundantes mas, urna ' 'ez instalada , pode ser usada por qualquer nó para iniciar um lmxuletw , como mostram as Figuras 4 .-i5(a) c 4.45(b). Note que um nó n;\o precisa estar ciente da árvore inteira; ele precisa simplesmente saber qual de seus \rizinhos em G são vizinhos que pertencem à S(Jtllllll ng 11 rr. A princtpal complextdade associada com a abordagem de spanning trct' é sua criaç;io c manutençao. Foram descnvoh•idos numerosos algoritmos distribu!dos de spanning trtt IGallager, 1983; Gartncr, 20031 . Aqui, consideramos apenns um algoritmo simples. ~a abordagem de n ó central da construçào de uma Sfltllmi ng trrc . é definido um nó cemral ( também conhecido como ponto de encontro ou núcleo). Os nós entào transmitem em rwkast mensagens de adesão à árvore endereçadas ao nó central. Uma mensagem de adesão à árvore é repassada usando roteamento unimst em direç:lo ao centro mé que eht chegue a um roteador que já pertence à árvore spanning ou a té que chegue ao cem ro. Em qualquer um dos casos, o caminho que a mensagem de adcsao à árvore scgui11 define o ramo da sptlltlling trec entre o rotc-.1dor de porta que enviou a mensagem de adc.sào à árvore c o centro. Esse novo cami11ho pode ser visto como um en xerto il :.fWIInlllg trrc existente. A Figum 4.46 il ustra a construç<\O de uma spmtni11g ln:e com centro. Supo11ha que o nó E seja selecionado como centro da ~lrvorc. Suponh•l que o nó F primeiramente se junte i\ árvore e rept1Sse uma mensagem de adcsào à tlrvorc a E. O línico enlace EF se torna a SJJcnming 1rcc inicial. O nó 8 cntào se junta à SIJWllling trcc enviando a E su;~ mensagem de acles:'lo à árvo['('. Suponha que a rota do caminho 1mlwsr de E f>ara B seja por D. Nesse caso, a mensagem de adesão à árvore resulta no enxeno do rnmi n ho BDE à spauning trer. Em seguida, o nó A se junta ao grupo crescente repassando sua mensagem de adesão à árvore em dircç;\o a E. Se o caminho W1ia1st de A a E passar por B, então, uma ,.ez que 8 já se juntou à Sf)(lllllillg tru. a chegada da mensagem de ndesàO à árvore de A em 8 resultar.\ no enxerto imediato do enlace AB à SJHmning III'C. Em seguida, o nó C se junta à sr)(tnlling tru repassando sua mensagem de adcsào à á rvore di retameme a E. Finalmente, como o roteamento unicrut de G para E tem de passar pelo nó D, quando G envia r sua mensagem de adesão à árvore a E. o enlace GD será enxertado à spanning tru no nó O.

Algoritmos de broodcast na prática Protocolos brotulwst silo usados na prática nas camada de aplirnç-Jo c de rede. Gnutella IGnutella, 2009) usa b10aclcast no mvcl de ap licaçào para fazer Lrai\Smissão bromlcast de consultas de conteúdo entre pares Gmuella. Ne:.se caso, um en lace entre dois processos pares distribuídos no mvd de aplicação na rede Gnutclla é, na verdade, uma conex~o TCP. O G nutella usa uma forma d e inundação controlada com número de sequ~ncia na qual um idcntiOcador de 16 bits e um descri10r de carga útil de 16 bits (que identiOca o 1ipo de mensagem Gnmella)

a. Constru~io da spannlng 'ree pa»o a ~no

Figura 4.46 Construção de umo sponning tree mm centro

b. S~nning ,,... connrulda


so\0 usados pam detectar se uma consulta broaclcast recebida já foi recebida, duplicada c repassada ante.riormente. O Gnutella usa um campo de tempo de vida (TIL) para limitar o numero de saltos pelos quais uma consulta sera repassada. Quando um processo Gnmclla recebe e duplica uma consulta. de decrcmenHl o campo de TTL ames de retransmili-la. Assim. uma consulta Gnmella em broadcast alcançará apenas pares que est:\o dentro de um dado numero (o valor mtcial do TTL) de saltos de nh·cl de aplicação desde o inictador da consulta. Por isso. o mecanismo de consultas por inundaç-~o do Gnutella às vezes é denominado írllmdcr(ilo ele escopo li111itaclo. Uma forma de inundaç;lo controlada com número de seq ui!ncia tam!Xm é usada p:1m fazer a transmiss:lo brtXtclccrst de am\ncios de estado de enlace Oinlt-stalc advcrtisciiiC'IIIS - lSAs) no algoriuno de roteamento OSPF IRFC 2328; Perlman, 1999) e no algoritmo de roteamento Sistema Intermediário a Sistema lntcrmtdi ário (lmrrm('clíatr-Syswu-to-lut('rmediatr-System- 15-IS) IRFC 1142; Pcrlman. 19991. O OSPF usa um número de sequi!nda de 32 bits, bem como um campo de idade de ló bits para identiOcar anúncios de es tado de enlace (lSAs). Lembre-se de q ue um nó OSPF faz broadcctst periódíco de LSAs para os enlaces ligados a ele qLmndo o custo de enlace mé um viz inho muda ou quando um enlace ativa ou d esativa. Números de sequ~n cia l.SA são usados para detecwr LSi\s duplicados, mas também cumprem uma st'gunda run çi\o importfHlle no OSPF. Com inundação, é posslvcl que um LSA gerado pda fo rur 110 tempo t chegue tq>ds um LSA m:tis novo que foi gerado pela mes ma fonte no tempo I + Os tl lllncros de scqut ncia USlldOs pelo nó da fo nte permitem que um LSA lllrc uma finalidade se melhante à de um v:~ Io r TTL. O valor inicial do c:1mpo de i(htde é estabelecido em zero c~ incremen tado t~ cada salto à medida que este ê rctransmltldo, e também é Incrementado enquanto fica na memória de um ro tead or esperando para ser enviado. Embora nossa descri~ilo do algoritmo de inundação l.SA tenha sido apenas breve, observamos que, na verdade, projetar protocolos de broculwstlSA pode ser um negócío muito delic:1do. IRFC 789; Perlman, 19991 descre"em um incidente no qual LSAs transmitidos incorrctruncmc por dois roteadores ddcltuosos nzeram com que uma vers;lo antiga do algontmo de inundaç;\o l.SA derrubasse a ARPAnct inteira!

a.

4.7.2 Multicost Vimos. na seção anterior, que, com serviço broodcast. pacotes sào entregues a cada um c a todos os nós em uma rede. Nessa seç-,\o, voltamos nossa atenç-.lo para o serviço multicast, no qual um pacote mullicrut é entregue a apenas um subgrupo de nós de rede. Uma série de aplicações cmcrgemcs de rede requer a entrega de p:tcotes de um ou mais remetentes a um grupo de destinatários. Entre essas :tpliC'Jçõcs est:\o a transfcr~ncia de dartícipames dis tribuídos) , a alimcruaçao de d:tdos (por exemplo, cotação de ações), a atualização de arquivos de memória intermediária c os jogos interativos (por exemplo, ambientes virtuais iruemtivos distribuídos ou jogos multi usu:l ri os). Na co rnun icaç;lo mulrirasl, enfre ntamos imedíatameme dois problemas- como identificar os des tinatários de um pacote multicmi c como endereçar um pacote enviado a um dessC's destin:urtrlos. No C"JSO da co municaçao unica.~t. o endereço IP do destinatário (receptor) é levado em cada datagrama IP 1111ícast e identifi ca o ünico dcsti· Mtário: no Ct\SO do mullícttsl, temos vários destinatários. Tem senudo que cad:t pacote m11lriwsl carregue os endereços IP de todos os vários destinatários? Embora essa abordagem possa ser funciona l com um número pequeno de dcstin:wlrios. 11:\o tem boa escalabilidade para o caso de centenas de milhares de dcstinattírios; a quantidaM de mformaçôcs de cuderc~·amemo no datagrama sobrepl~aria a quantidade de dados que é realmente carregada no campo de carga util do pacote. A tdentificaç:io explícita dos destinatários pelo remetente também exige que o remetente conheça as identidades e os endereços de todos os destinat:lrios. Veremos em breve que há casos em que essa cxig~ncia pode ser andescj;lvcl. Por essas razões. na arquitetura da Interne t (e em o utras arqu iteturas de rede como ATM IBiack, 1995)), um pacote m11híws1 é endereçado usando endereço indireto, isto é, um único idenufieador é utilizado para o grupo de destinatários e uma cópia do pacote que é endereçada ao grupo usando esse úni co identificador é entregue a todos os destinatários multícast associados ao grupo em questão. Na Internet, o identificador único que representa


A uruda de rede

301

um grupo de destinatários é um endereço lP muhiCO? l'am a Internet, as respostas a todas essas perguntM envolvem o Protocolo de Gerencia men to de Grupo da In tern et (luterncr Grou1> l'llfmragemenl Protorol- IGMP IRFC 3376)). Assim, vamos considerar o protocolo IGMP. Mais ad iame, voltaremos a essas perguntas de caráter mais geral.

Internet Group Management Protocol - IGMP O protocolo IGMP, ' 'ers.\o 3 [RFC 33761 opera entre um hospedeiro e o roteador diretamente conectado a ele (em termos informais, pense no roteador diretamente conectado ao hospedeiro como o roteador de primeiro salto que um hospedeiro veria no caminho até qualquer hospedeiro externo à sua própria rede local. ou como o roteador de ultimo salto em qualquer caminho até esse h ospedeiro). corno mostra a Figura 4.48. Essa figura mostra os três roteadores mu/lictiSI do primeiro salto, cada um conectado ao hospedeiro ao qual está lrgado por uma interface local de salda. Essa imcrfacc local está ligada a uma LA nesse exemplo c, cmborn cada LAN 128.59.16.20

128.119.40.1 86

mcast group 226.17.30.197

Legenda: :>< Roteador ao qual está ligado um membro do grupo :>< Roteador ao qual nenhum membro do grupo está ligado

Figuro 4.47 Ogrupo mul«cost um dotogromo endereçado oo grupo é entregue o todos os membros do grupo mul«cost


Roteameoto

mulricast de área ampla

~ IGMP

Figure 4.48 Os dois componentes de multkosl de comodo de rede: IGMPe protocolos de roteamento mul~cost t~nha vários hospedeiros ligados a ela. no máximo apenas alguns deles comumente pcncnccrllo a um dado grupo mullicasr a qualquer determinado instame.

O IGMP prov~ os meios para um hospedeiro infonnar ao roteador conectado a ele que uma aplicação que está funcionando no hospedeiro quer se juntar a um grupo multicasr especifico. Dado que o escopo de interação do IGMP é lunilado a um hospedeiro c seu roteador conectado. um outro protocolo é claramente necessário para coordenar os roteadores nwlriccur (i ncluindo os roteadores conectados) por toda a lntcmct, de modo que os datagramas multlwst sejam roteados a seus d estinos l'inais. Essa última functonalldadc é realizada por algontmos de roteamento mulriwsr de l-amada de rede. como o PIM (protocol imlq>cnclcul mulricast - rnulriarst indepcndeme de protocolo), o DVMRP (disrcrnu vuror mulricast rouring protocol- protocolo de roteamento multicasr por \'etor de dist.\ncia) c o MO PF (OSPF mulrirasr). O IGMP tem apenas trés tipos de mensagens. Como as mensagens ICMP, as mensagens IGMP são carregadas (encapsuladas) demro de um datagrama IP, com um numero de protocolo igual a 2. Uma mensagem d e pesquisa geral de associação ao grupo (membershi p_query) é enviada por um rotl':ldor a todos os hospedeiros em uma interface conectad:t ( por exemplo, para todos os hospedeiros em uma I.J\N) para determinar o conjunto de:- todos os gn•pos multirc•sr aos quais se ligaram os hospedeiros naquela interface. Os hosped eiros res po11dcm a uma mensagem members hi p_query com uma mensagem mernbersh1 p_ •·epo t t . As mensagens membersh I p_report podem também ser geradas por um hospede iro quando uma apli<.-:u;:\o se Jtlllla pela primeira vez ao grupo tnulli arst sem esperar por uma mensagem membershi p_query vinda do roteador. O último tipo de mensagem IGMP é a mensagem leave_group. O interessante é que essa mensagem é opcional. Mas, se é opdonal, como um roteador detecta se nolo há mais nenhum hospedeiro em uma interface conectada que ainda es tá ligado a um determinado grupo multimsr? A resposta a essa pergunta est:\ no uso da mensagem members h i p_query IGMP. O rotc;ldor infere que n;\o há nenhum hospedeiro lig;\do a um d;ldo grupo multlmsr quando nenhum hosjX:deiro responde a uma mensagem membershi p_query com o dado endereço de grupo. Isso é um exemplo do que às vezes é denominado esta do Uexh •el em um protocolo de Internet. Em um protocolo de estado Oextvel, o estado (no caso do IG~P. o fato de haver hospedctros ligados a um dado grupo mulrlcast) ser.t encerrado por um C\'Cnto de esgotamento de tc:mporlzaç-.\o (nc~c: caso, por uma mensagem membershlp_query periódica emilida pelo rote<~dor) se nolo for explicitamente renovado (nesse caso, por uma mensagem membershlp_report vmda de um hospedeiro conectado). Argumcllla-se que protocolos de estado Oexfvel resullarn em controle mais simples do que o dos protocolos de estado, que não somente exigem que o estado seja explicitamente iniciado e encerrado, mas também requerem mecanismos para se recuperar da situação em


A u11oda de rede

303

que uma entidade responSl' vel pelo encenamemo d o estado CJlcerro u premaLUramente ou falhou. Uma discussão excelente sobre o estado nexrvel pode ser encontrada em IRaman. 1999;Ji. 2003, lu• 20041.

Algoritmos de roteamento multicost O problema de roteamento multicast está ilustrado na Figura 4.49. Os hospedeiros agregados a esse grupo

multicast silo os de tom mais claro: os roteadores imediatamente conectados a eles também est:lo nesse tom. Como mostra essa figura, dentro da populaçilo de roteadores rnulttcast, somente um subconJunto desses roteadores (os que têm hospedeiros conectados que se junt.-tram ao grupo muhiwst) realmente precisa receber o trnfcgo multicem. Ou seja. somente os roteadores A, D, E e F precisam receber esse tr:Hego. Uma vez que nenhum dos hospcdciros conectados ao roteador D está ligado ao grupo muhirast c o roteador C n:lo tem hospedeiros conectados, nem C nem D precisam receber o tráfego do grupo multic
Figura 4.49 Hospedeiros mullicost, seus roteadores conedodos e outros roteadores


mulriwsr- roteadores de aresta cujos hospedeiros a eles ligados pertencem ao grupo rnulrímsr enviam ( vm unica.sr) mensagens de adesào endereçadas ao nó ce ntral. Como no caso do broaclwst, uma mensagem de adesJo ~ transmitida usando roteamemo unicasr em direçào ao centro at~ que a mensagem chegue a um roteador que j:i pertence à árvore mullicasr ou chegue até o centro. Todos os roteadores ao longo do (.':lminho percorrido pela mensagem de adcs:\o então transmitir.\o os pacotes mullic(ISI recebidos ao roteador de aresta que iniciou a adesâo multicast. Urna questão crftka para o roteamento mullicast lr.tseado por árvore de centro é o processo uuliU~do para selecionar o centro. Algontmos de scleç;.\o de centro s.\o discutidos em {Wall, 1980; Thaler, 1997; Estnn, 1997{.

Rouamento multica~t usando uma drvorc baseada na fonll'. Enquanto o roteamento multicast por árvore compartilhada pelo gr upo constrói uma única arvore de roteamento compartilhada para rotear pacotes de tcxlos os hospedeiros, a segunda abordagem constrói uma árvore de roteamento multiwst para cac/n fontr no grupo mrrllica.çt. Na prálica, ê usado um algoritmo RPF (com nó de ronte x) para construir uma árvore de transmissão llllllticasl para razcr mulliarst de dmagramas que se origina m na rome x. P o que acontcccri~t se houvesse mllhares de rotc·a dores ad inntc de 01 Cada um desses milhares de roteadores receberia pacotes multiccrsl indesejados. (Esse ce nário não está tão longe ela realidade corno parece. A Mbone inicial (Casncr, 1992: Maccdonia, 1994). a prirneim rede multicctst global sofria prccisarncnu~ desse problema no infcio.) A soluç.lo para o problema do reccbirncmo de pncotes mulricasr indesejados sob RPF é conhecida como poda. Um roteador multicctsl que receba pacotes multkcrst c nào tenha nenhum hospedeiro conectado a ele pertencente àquele grupo en,'iará uma mensagem de poda ao roteador que cst:i ames dele. Se um roteador receber mensagens de poda de cada um dos roteadores que estão adiante dele, então pode repassar uma mensagem de poda nos roteadores que estão antes dele.

S: fonte

B

E

f Legenda: -

pacote (pkt) que será repassado pacote (pkt) que não será repassado atêm do roteador destínatario

Figuro 4.50 Repasse pelo

A co11oda de rede

305

Roteamento multicast no Internet O primeiro protocolo de roteamemo multicciSI usado oa loternet foi o Protocolo de Roteamen to Multlcast p or Vetor de Dist4ncias (Distwlct-Vrclor MullicasL Rouling Prolocol- DVMRP) IRFC 10751. O DVMRP lmplemema :lr,ores específicas de fome com repasse de caminho inverso e poda. Esse protocolo usa um algoritmo RPF com poda. conforme discmido llCima. Talvez o protocolo de roteamento muhíc-.tSI da lmernel mais utilizado sep o protocolo de roteamento PIM (multicasl independente de protocolo), o qual reconhece absolutamente dois cenários de distribui~'<10 mullicast. No modo denso IRFC 3973) , os membros do grupo muhicast são densamente localizados; ou seja, muitos ou a maioria dos roteadores na :lrca precisam estar cnvolv1dos nos datagramas de roteamento multicast. O PIM de modo denso é uma técnica de repasse de caminho inverso do tipo inundar e podar semelhante em espírito ao DVMRP. No modo esparso [RFC 46011 . o número de roteadores l'Om membros do gt'upo é pequeno em relaç:lo ao número to tal de rot eadores; os membros do grupo são amplamente dispersos. O PIM de modo esparso usa pontos de encontro para definir a :lrvorc de distribuiç;\o multicast. No SSM (mullicasr de fome especifica) IRFC 3569, RFC 46071. somente um t\nico remete nte pode enviar tráfego para a :lr"ore mulrirast. simplificando considerave lmente <1 construç;lo c manutcnç:\o da árvore. Quando o PIM e o DVMRP sào usados dentro de um domínio, o operador ele rede pode configurar rolas IP mulliwst dentro do domfnio, da mesma forma que protocolos de roteamento unlcasr intraclominlo como RIP, IS-lS c OSPP podem ser configurados. Mas o que acontece quando as rotas lmthic-Jst sào requisitadas entre domínios di rercntes? Existe um multiwst equivalente do protocolo BGP imerdo mínio? A resposta f (literalmente) sim. IRFC 4271) define as extensões de protocolos nulltiplos para o BGP que lhe permite curegllr informações sobre ro teamento para outros protocolos, incluindo informações multimst. O protocolo MSDP (Multimst Source Díscovel)• Protocol) [RFC 3618, RFC 461 LI pode ser usado para conectar os pontos de encontro em domfnios de diferentes PIMs de modo esparso. Uma visão geral imeressante sobre o atual estado do rotc:~mcnto muhicast na Internet pode ser encomrada em IRFC 5110) . Vamos finalizar nossa discussão sobre mullicast LP observando que ele amda tem de decolar de forma significativa. Para obter :~bordagens imercss.1mes sobre o modelo de serviço mullicast da lntemet e questões sobre implcmentat;t1o. consulte [Oiot. 2000; Shanna. 20031. Não obstante. apesar da flllta de emprego largo. o mullicciSI em navel de rede está longe de ~morrer·. O tráfego rnultirasl foi conduz1do por muitos anos na Internet 2, assim como as redes com as quais ela se intcrconccta [lmcrncl2 Multicast, 2009). No Reino Unido, a BBC está envolvida em testes de d1stnbuiç:'o de cometldo através do IP mulr1 rc1St IBBC Muhicast, 2009) . Ao mesmo tempo. o mullicnst a nfvcl de apliL"'(IÇâo, como '' imos em PPLive. no Cttpftulo 2. c outros sistemas 11ccr-ro-IJctr, como o Encl Systtm Mulriwsr [ESM, 2007[ , proveem distribuiçilo de contelÍdo mHlticast entre pMcs q ue utilizam protocolos mrrltircm da cam:1da de aplicação (em vez da camada de rede). Os sen•iços rnullimst futuros ser:lo primeiramente

implemcmaclos na camada de rede (no núcleo da rede) ou na camacla de aplicaçi\o (na aresta da rede)? Enquamo a :~t ual mania de distrlhuiç:'lo de contet:lclo llrcr-to·llur inOucncia a favor da camada de aplicação mu/tim~t pelo menos em um futuro próximo, a e"oluçào continua a camlnhar no IP rrmltlcas r, c 1\s vezes, no fim das con tas, devagar se vai ao longe.

4.8 Resumo este capuulo. iniciamos nossa \'Íagem rumo ao núcleo da rede. Aprendemos que a camada de rede envolve todos os roteadores da rede. Por causa disso, os protocolos de camada de rede est:lo entre os mais dcsanadores da pilha de protocolos. Aprendemos que um roteador pode precisar processar m1lhões de Ouxos de pacotes cmrc diferemes pares fonte-desuno ao mesmo tempo. Para que um roteador possa processar um numero tão grande de Ouxos, os projetiStas de redes aprenderam. com o passar dos anos. que as tarefas do roteador devem ser o mais simples possível. Muitas medidas podem ser tomadas para facilitar a tarefa do roteador, incluindo a utilização de uma camada de rede de data gramas, em vez de uma camada de rede de circuitos virtuais, a utilização de um cabeçalho aprimorado

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....de tamanho fixo (como no 1Pv6), a eliminação da fragmemaçào (também fciu\ no 1Pv6) c o fornecimento de mn único serviço de melhor esrorço. Talvez a sutileza mais importante aq ui seja m\o monitorar nuxos indi\•iduais, mas. em vez dtsso, tomar decisocs de roteamento tendo exclllsivamente como base endereços de destino hieror· quicamente estrmurados nos pacotes. t; interessante notar que o serviço dos correios \"em usando essa mesma abordagem ha muitos anos.

Neste capllltlo, examinamos também os princípios subjacentes de algoritmos de roteamento. Aprendemos como algoritmos de roteamento razcm a abslraç;lo da rede de computadores em um groro com nós e enlaces. Com essa abstra~"'ào , podemos pcsqutsar a rica teoria do roteamento de caminho mais curto em grafos, que foi desenvolvida nos últimos ·W anos nas comunidades de pesquisa operacional c de algoritmos. Vimos que há duas abordagens amplas: uma cent ralizada (global), em que cada nó obtém o mapeamento completo da rede e aplica indcpcndemementc o algoritmo de roteamento de caminho mais curto, c uma descen tralizada, em que nós indivi· duais tfm apenas um quadro parcial da rede in1cira c, mesmo assim, trabalha m em conjunto para entregar pacotes ao longo das roHlS mais curtas. Também estudamos como a hierarquia é utilizada para lidar com o problema da cscakl, dividi ndo redes ele gmndc porte em domínios :~dminist rat i vos lndepcrtdentcs de nominados sislcmas a utónomos (ASs). Cnd11 AS rotcia lndcpcndcntcmcntc seus dat;\gramas pelo sistema, exatamente como cada pais distribui sua corrcspondencia posta l pelo seu terri tório. Aprendemos como abordagens ccn1 mlizadas, dcscentm· lizadas c hierárquicas esuio incorporadas nos principais protocolos de roteamento d(l Internet: RIP , OSPF c BGP. Concluímos nosso estudo de algoritmos de roteamento considemndo roteamento bnxulwsr e mulrica,çr. Agom que condufmos nosso estudo da mmada de rede, nossa jornada scglte nu no a um nf,•cl mais baixo da pilha de protocolos, isto é, à camada de enlace. Como a camada de rede, a camada de enlace é também pane do núcleo da rede. Mas veremos no próximo capítulo que a camada de enlace tem a tarda muito mais 1<><.-alizl'l.da de movimentar pacotes cmrc nós no mesmo enlace ou LA!'. Embora essa tarefa possa à primeira vista parecer tnvial quando comparada às tardas da camada de rede, veremos que a camada de enlace envolve uma série de questões unponantes c fascinantes que podem nos mamcr ocupados por muito tempo.

Exercícios de fixação Capítulo 4 Questões de revisõo ~ões

l.

l.

3. 4.

4.1a 4.2

V~mos rc\'cr um pouco da tcrnunologla us:1da neste livro. Lembrc·SC de que o nome de um pacote de camada de transpcmc é sc~mc~ruo c que o nome de um pacote de c:unada de cnl:tcc é quculm. Qual é o nome de um pacote de ~:am:Ldtl de rede? Lcmbrc~sc de que roteadores c comllt:Ldvrcs de camada de enlace são dcnomln~dos ccmwwdorrs de pCICOIC:S. Qual é a diferença fundamcnral entre um roteador c um comula· dor de camad:~ de enlace? L.cmbrc·sc de ~uc usamos o termo rolt'(ldarrs t:~nw pam redes de da1agramas quanto para redes de CVs. QuaiS são as ditas funções m:lis imponames de cama· da de rede em um:t rt:dc de datngramas? Quais s•\o as Ir~ funções maiS importantes de c.unada de rede em uma rede com ctrcultos v1rtuais? Qu:~l ~a chferetwa cn1rc rote:~r c r.:passar (1mnsmitir)?

Os ro1eadorcs de redes de datagramas c de redes de circuitos virtuais usam tabelas de repasse? Caso

usem, descrcv.• liS classes de rcdl:l>.

ltLbcl ~~

de repasse pam ambas as

5.

Descreva alguns serviços hlpotéllcos que ti camada de rede poderia ofcn.:ccr a um pacote lndlvidttal. F~çn o tlltStnC) l)am 11 111 nuxcL de paCillCS. t\lgut\5 elos serviços hipotétícc,s que voe~ descreveu s!o fornecidos pelt1 camad:1 de rede dn Interne t? Alguns deles sao fornecidos pelo modelo de serviço ATM CBRl Alguns S;.)o fornecidos pelo modelo ele serviço ATM ABR?

6.

Cite algumas aplíc.tcões que poderiam se beneficiar do modelo de serviço ATM CBR.

~ão 4.3 7.

Discuta por que cada JX>rla de entrada em \trn rotea· dor de alta velocidade armazena uma cópia-sombra da tabela de repasse.

bow4tto4ic~ Capi tulo 4

8.

Tres IIJX)S de ele me mos de comUiaç-lo sllo discutidos na Sccào 4 .3. Cite c descreva bre,·ememe cada tipo.

9.

Descreva como pode ocorrer perda de pacotes em portas de entrada. Descreva como a perda de pacotes pode ser ehminada em portas de entr.ul:t (sem us:u buffcrs infinitos).

1O. Descreva como pode ocorrer perda de pacotes em

port:ts de saída. 11. O que é bloqueio liOL? Ele ocorre em ponas de salda ou em portas de emradn? S~ôo 4.4

11. Roteadores tCm endereços I P? Em caso posi tivo. quamos c ndereçtlS eles têm1

13. Qual é c> equivalente hindrlo de 32 bits J)ara o endereçu IP 223. 1.3.27? 14. Visite um hospedeiro que usa DHCP para obter seu endereço lP. m:.\scara de rede. roteador de defau lt e endereço IP de seu servidor DNS local. Faça uma lista desses valores.

1.5. Suponha que haJa trêS roteadores emre os hospedei· ros da ft>ntc c do des tino. Ignorando a fragmcntaç-Jo. um data~rama IP enviado do hosrlCdeiro da fonte :uc o hospedeiro do dc:.Hno trnnsitilrá por quantas mterfaces? Quantas tabelas de repasse serão indexadas para dc:.lt,car o datagrama desde a fonte até o destino? 16. Suponha que uma aplicaç:lo gere blocos de 40 bytcs de dados a cada 20 milissegundos e que cada bloco seja cncar>sul~do em um segmento TCP c. em segui· da. em um d:uagrama IP. Que porcentagem de cada datagrama sem sobrecn~a e que porcentagem será dt1dos de aplicnc:lo? 17. Supun ha que o llost>cdeiro '' envie no Hospedeiro 13 um segmento TC I) e ncapsulado em um d~•:•grmna IP. Quando o ltospedciro 6 recebe o da tagranu. como a camada de rede no Hospedeiro 6 S<~bc que deve t>assar o scgrno.:nto (islo c, t1 car~;~ úlil do data· grama) pam TCP c mlo 1>ara UDP ou qua lquer uutra cc1isa?

18. Suponha que voe~ cOrnJ>re um roteador sem fio e o conecte a seu modem a cabo. Suponha t:~mbém que seu ISP dcsr~ne dinamrcamcntc um endereço lP a seu clisposili\'0 concceado (isto é, seu roteador sem fio). Suponha ainda que voe~ tenha cinco PCs em casa c que usa 802. 11 1,ara conectá-los sem fio ao seu roteador também sem fio. Como são designados endereços IP aos cinco PCs? O roteador sem fio usa NAT?

307

A u ru da de rede

os C.11llJ>OS de cabeÇlllho do IPv-1 e do 1Pv6 c :~ponte suas diferenças Eles têm algum campo em comum?

19. Compare

20. Afimla·se que, quando o I1'\6 implcmcnta tuncis através de roteadores 1Pv4, n 1Pv6 erata os tüncis IP\-l como protocolos de camada de enlace. Você concorda com essa afirmacão? Explique sua resposta. S~ôo 4S

c aponte as difcrcncas entre os algor itmos de estado de enlace c de vetor
21. Compare

12. Dlscut:J como tiiiM Of1ta nlz.u;.1{l hierárquica da lmcrnct possibilitou estender sua escala para mil htks de usu:!rios.

13. É ncccss:irlo q ue t0

Seção 4.6 2+. Cnnsidere a Figura 4.37. Cnmeçando com a tabela original em D. SU J)Onha q11c O receba de A o seguinte anuncio:

s.b-rede de

Roteadof seguilte

cltstilo

Nillero de sohos Olt O .JtÍIIO

c

10

w X

A labcla em D mudará? Em caS<> positivo, como mudará? 15. Compare os amlnclos utilizados J>Or RIP e OSPF c aponte suas dlfcrcn~as.

26. Complete: ant1ncios RIP normal mente :munciam o núm~rtl de saltos ate \':Írios dcstinus. Alua lizaç,}es 13GP. JXH oUlro lado, a nunciam - - - - - - - aos diversos destinos. 27. Por que s;lo usados protocolos in ter-AS c intra-AS d iferentes na Internet?

18. Por que c:onsidcraçOcs polrtic:ts não sllo tão Importantes pam protocolos ln tra·AS como o OSPF c o RIP, quamo para um protocolo de roteamento interAS como BGP?

29. Defina e aponte as diferenças entre os seguintes termos: suv·rrdr. prefixo c mw IJGP. 30. Como o BGP US3 o :unbuttl NEXT-IIOP? Como ele usa o atributo AS·PATH? 3 1. Dcscre' a como um admmistrador de rede de um ISP de nlvel superior pode implementar política ao configurar o BGP.

bow4tto4ic~ Redes de computadores e o lnte;.;ro;.;e;.;.t_ _ _ _ _ _______________ _ _ _ __

S~iio 4.7

32. Cite urna •rnponame diferenc;~ emre a implernen•aç~o da abs1raç;lo broatlcasr por rnuhiplos unicasts e a de um ~rupo lmwrclwsl suport:ldo por uma unka rede (roteador). 33. Para cada uma das m!s abordagens gerais que estu-

a. Um nó pode receber ' ':Irias cópias do mesmo pacole. b . Um no 1lode tellass:u ,,mas cóp1as de um pacote pelo mesmo enlace de s.1fda. 3 4. Quando um hospcde1ro se juma a um grupo mulliCd$1, ele deve mudar seu endereço IP p:1ra o endereço do grupo nmltirciSl ao qual es1á se jumando?

damos par~ a comunlcaç-Jo bmadcasc (inundaÇllo nllo comrolada. inundação com rolada e broodcasl de

35. Qu:lls S;lo os PAI~is descm1lenhndos llclo protO(olo

spanning lrce), as scgui mes declaraçt)es são ''crda·

IGMP c por um protocolo de r01eamento nwltiwst de

dciras o u f:tlsas7 Voe~ llO
longa dislilncia? 36. Qual c a diferença cnlre uma arvore compnrtllhada por um grupo e uma árvore de fon te no conlCNto do

ordem em que roram e1wi:ulos.

rotc.mu:nlo rnulliws t?

Problemas 1.

:~tivos

menor do que u máximo determinado na par1e (a) e, mesmo assim. n:\o haver nenhum numero de CV livre em comum ?

Nes1a qucsl:lo. consideramos alguns dos prós e dos contras de redes de circui1os virwais e redes de dala-

gramas.

c. Suponha que sejam permitidos nümeros diferen tes de CVs em cad:1 enlace ao longo do caminho de um CV. Durante o estabelecimento da conexão, após a de1crminaçi\o de um caminho fim a fim. descreva como os enlaces podem escolher seus numcros de CVs e configurar suas tabelas de repasse de urna maneira desccmrnlizad:~, sem depender de um m~ cemral

a. Suponha que os roteadores estivessem sujeitos a condições que os tivessem feito falhar com bastallle frcqu~ncia. Essas ações fa\'orecem uma arquucwra de circuhos \Ínuais ou de datagrn· mas> b. Suponha que um nó de fome c um desúno solicitem que uma quantidade nxa de capacidade esteja sempre dispomvel em 1odos os r01eadorcs no caminho entre o nó de fome c de destino, para o uso exclusivo de nuxo de tráfego entre esse nós de fome e de destino. Essas aç1)es favorecem uma arquiletura de circu i1os vinuais ou de datagramas? ror quê? c. Suponha que os enlaces c os roteadores da rede nunca falhem c que os caminhos de roteamento usados entre as dup las de ron1e/dcs1ino permanc· çam consmn1cs. Nesse cenário, 3 arquil e mra de circuitos virtu(lis ou de dawgmrnas possui mais controle do trMcgo? 2.

Considere uma rede de clrcuiws vinu:ris. Suponh:1 que o numero do CV é um campo de 16 bi1s. a. Q ual é o numero m:lximo de circuitos vinuais que pode ser carregado por um enlace? b. Suponh:1
3.

Uma 1abela de re1>nssc bem básica em uma rede de CVs tem quatro colunas. O que significam os valores em cada uma dessas colunas? Uma tahcla de repasse bem básica em uma rede de da1agramas 1em duas colunas. O que signiOcam os valores em cada uma dessas colunas?

-f.

Considere o. rede ab:1ixo. " · Suponha que c.~t a rede scj<\ uma rede de da tagra· mas. Mostre :1 tabeb de repasse no roteador A, de mudo que todo o 1ráfcgo des1inado ao host>edciro H3 seja enctuninhado pda interface 3. b. St•po nha que CSHI rede seja uma rede de datagmm,\S. Voct consegue compor urna tabela de repasse no rotendor A, de modo que 1000 o 1ráfcgo de H I des1ínado :1u hOSJll' hospedeiro HJ seja encaminhado pela mtcrface 47 (Dica: es1a é uma pergunta capc1osa.) c. Suponha. agor.~. que cs1a rede seja uma rede de circuilos '~nuais c que haja uma chamada em andamento cmre H l e H3, e outra chamada em


andamento entre H2 c H3 Elabore uma tabela de repasse no roteador A, de modo que todo o tr.ife~o de H L dcsunado ao hospedeiro H3 seja encaminhado pda interface 3, enquanto todo o tráfego de 112 destinado ao hospedeiro H3 sejól encammhado pela mterface 4. d. Admitindo o mesmo cenário de

~c·,

8.

elabore tabe-

las de repasse em nós 13. C c O.

5.

Considere urna re
309

A
Considere o comutador abaixo. Sut>Onha que todos os datagrnm:IS posl>uam o mesmo comprimento. que o comutador opere de uma manc1ra segmentada e sincrõnic:l. c que em um intef\'Jio de tempo (time siOI) um da tagrama poss.'l ser transferido de uma porta de entrada para uma porta de salda. A 11\3lha de comutacão c um crossl>.'lr no qual. no má."imo. um datagrnma poss;t ser transferido para uma determinada porta de safd:l em um intcn·:~lo de tcm1>0. mtb portas de salda diferentes podem re<:eber datngramas de portas de cntracla difcrcnlcs em um unico imcnacotcs mostrad()s das punas de cntrada1,.,ra suas JXlrtns de s.1ida, admitindo qualquer ordem de sincmniZllçM ele fila que voee quiser (o u seja, mlo é necessário o bloqueio HOL)? Qual é u m~ ior m\mcro (i e intervalos ncccss.1 rlvs, ad milindo uma ordem de sincrClnlzaç:to de 11iM caso e que uma fila de en trada n.lo \'azia nunca fica parada?

Poru cJt wkla Y-+

ces esteja carrcg;lndo dois outros circuitos virtuais e que os nu meros dcsses outros CVs são os seguintes:

PotU de wkl.a z- +

Enlace A 00 01

Enlace 8 OI lO

Enloce C 10

Enlace D

11

00

11

Ao responder :\s perguntas a seguir. tenha em mente que e:1da um dos CVl> t:xistcntcs pode estar atravesS.1ndo :~penas um dos quat ro enlaces.

Faixa do ender~o de destina

em todos os enlaces ao longo de seu caminho, qual numero de CV l>odcria ser designado ao novo CV?

11100000 00000000 00000000 00000000

No texto u amo) o termo~~ vi(CI m ienwdo tXIrcl ccmt:· J):lro descrever a camada de transporte c serviço de cont'\'tlH para :1 camadól de rede. Por que essa sutileza na terminologta?

xtlo

7.

Considere uma rede de datagrnmas que usa cnde· reços de hospedeiros de 32 bits. Suponha que um roteador tenha quatro enlace:.. numerados de O a 3, c que os pacotes U~m de ser rep.'lssados para as interfaces de enlaces como segue:

a. Se cada CV tiver de usar o mesmo numero de CV

b. Se fosse permitido que cada CV tivesse um numero de CV diferen te nos diferentes enlaces ao longo de seu caminho (tic modo que a tabela de repasse tenha de real izar troduç:\o de número de CV), quantas comlllnaçóes tlifenmtes de ctuatro ntimcrus de CVs (um para cada um dos c1uatro enlaces) poderiam ser usadas? 6.

9.

Na Seção 4.3 obscn-amos que n:'lo pode ha\"er nenhuma flla de entrada se o elemento de comutação for ,. vetes mats r.lpido do que as taxas das linhas de entrada, admnmdo que 11 hnhas de entrada tenham todas a mesma velocidade de linha. Explique (com palavras) por que isso tem de ser assim.

oté

Interface de enlace

O

11100000 00111111 11111111 11111111 111 00000 o1000000 00000000 00000000 oté

111 00000 OI000000 11111111 1llll111 111 00000 O100000 I 00000000 00000000 oté

2

lll00001 01111111 llllllll 11111111 senão

3

I

bOWAttOOiC~


--~---------------------------a.

b.

Elabore uma 1abcla de repasse que lenha qu:uro reg1s1ros. use compatibilização com o prefixo ma1:. lon~o c repasse I>-1COtcs para as imcrfaccs de enlace correias. Descre,-;• como sua 1abela de repasse deu•rmina a mtcrface de enlace apropri:tda para daragramas com os seguimes endereços: 11001000 10010001 01010001 01010101 ILIOOOOL 01000000 11000011 00111100 11100001 10000000 0001000101110111

10. Considere uma rede de dat:1gmmas que utilioro cndc:recos de ~ bits. Sulm nha que \llll roteadQr utilize comi>
Prefixo o ser
lnterfa
00

o

OIO

1

011

2

lO

2

11

3

Para cada uma das quatro interfaces. forneça a faixa assocrada de endereços d e hospedeiros de destino e o nümero de endereços na faixa. 11. Considere uma rede de datagramas que usa endereços de hospedeiros de 8 bits. Suponha que um roteador use comparibilização com o prefixo mais lo ngo c tenha n segui me 1abcl:l de rep:~sse:

Prefixo o ser
Interface

I

o

10

1

111

2 3

settõo

Para c:1da uma das quatro in terfaces, fornc~-a a faixa associada de c11dereços de hospedei ros de d csrino c o número de endereços na faixa.

ll. Considen: um rote:~dor que in terconecla três sub· redes: Sub-rede I. Sub- rede 2 e St•b·rcde 3. Suponha que todas as mtcrf;~ccs de cada uma dessas três subredes lenha de ler o t>rdixo 223.1.17/24. Suponha lambem que a Sub-rede I lenha de suponar au~ 63 interfaces, a Sub-rede 2 lenha de suponar au! 95 interfaces c a Sub-rede 3. 16 interfaces. Dê três endereços de rede (da forma a.b.c.cVx) que satisfaçam essas limitações.

13. Na Seção 4.2.2 é dado um 1!.\Cmpl,) de t3bcla de repasse (us;tndo compaubilltaç~o de prcOxo mnis longo). Rccscre"a a rabcla us.1ndo :~ muac;'lo a.b.c.cVx em \ 'CZ da notaçJo de cadeia bln.tr.a.

14. No Problema 9. solici1amos que voei! elaborasse uma rabcla de repasse (usando compatlliuci\o de prcOxo mais longo). Reescreva a tabela us.1ndo a notação a.b.c.d/x em vez ela n01ação de c.1deia binária. 15. Considcn.:umasub·n.'tlecorn pr~nxo 128.119.-+0.128126. 0<' um exemplo de um endereço Ir (na forma xxx. xxx.xxx.xxx) que possa ser designado para essa rede. Suponha que um ISP posstla o bloct> de e ndereços nn forma 128. 119.40.Mn5. SU()(lllho que ele queira criar lenha o mc:.mo mhncn) de cndac~;os IP. Quais $:10 us prcnx
16. Considere a 1opologia mostmda na Figum 4. 17. Começa ndo pela parlc superior c prosseguindo em sentido htm!rio. denomine as três sub-redes como Redes A, a. c C. Denomine as sub-redes sem hospc· dciros como Redes O, E. c F. a. Designe endereços de rede a cada uma dessas seis sub-redes. com as seguintes rcstriç,,cs: todos os endereços de,•er.lo ser alocados a panir de 214.97.254123: a Sub-rede A deve ter cndcre· tOS SuflereniCS para l>UI)oriOir 250 llllerf.ICCS: a Sub-rede a deve rer endereços sufidemcs para suportar 120 Interfaces c a Sub-n.'dc C deve ter endereços suflclentcs para suportar 120 inter· faces. 1: claro que cad:~ uma das sub-redes O, E c F dc,•em poder suponar duas interfaces. Para cada sub-rede. ignaç:lo deve t0r um enlace que tem ttllla MT U de 700 bytcs. Su1>on ha que o d;nagrorn:l original csll'ja marcado com o número de identíflcaç3o 422. Quantos fragmen tos :.ào gemdos? Qu:.is s:\o C)S v.1lcm:s em vários carnpc)$ d os da1agramas IP gerados em re laç!lo à fragmentação?

18. Suponha que, emre o Hos,,cdciro de origem A c o Hospcdeir<> dcs1inat:lrio B. C)S da1agramas cslej:tm limilados a 1.500 by1cs (mduindo c:~bcçalho). Admllindo um cabeçalho IP de 20 b)•ICS, quantos da1agramas scnam neccss:\rios para en"iar um arqui· MP3 de 5 milhões de b)•tcs? Explique como você obteve a rcspo:.la.

,.o

19. Considere a conOguração de rede da Figura 4.22. Suponha que o ISP designe ao roteador o endereço


311

A u11oda de rede

24.3... 112.235 e que o endereço de rede da rede residencial seja 192.168. 1/H. a . Desagnc endereços a todas as interfaces na rede residencial. b. Suponha que haja duas conexões TCP em curso em cada hospedeiro, todas para a pona 80 no hos· ptdcaro 128.119 ...0.86. Fomcça os :;eis rcgi:>tros corrcst>ondcntes na tabe la de tradução NAT. 20. Suponha que você esteja inte ressado em detectar o numero de hospcdcin.s por trns da NAT. Voei': obser· va que a camada IP traz urn número de iden tificaçilo. de modo seq ucnclal, em cadll pacote I P. O numero de identificaçClo do prirncaro pacote I P gerado por um hospedeiro é ulcatório, c os núme ros de ídcntíri· cação dos pacotes IP subscquentcs s;\o de tcnninados scqucndalmcntc. Admita que todos os pacotes IP gerados pm hospedeiros [Xlr tr:ls d:1 NAT scjt\m enviados p:~ra o mundo c:octerior. a . Com h;tse ness:1 ohscrvnço\o c ndmítindo que você

analbar t~xlos l"rS paootes enviadl>S p;lr:l forn pela NAT . você pade descre"er uma técnicn simples que detecte o número de hospedeiros únicos por tr:ls da NA T7 JusuOque sua resposta. pOOC

b. Se os numcros de idcmiOcação não são de1ermi· macios de maneira scqucncial. c sim aleatória. sua técnica runcionaria? Justifique sua resposta. 21. Neste problema estudaremos o impacto das NATs sobre aplicaçôcs P2P. Surxmha que um parceiro com nome de usu:lrio Arnold descubra, por meio de consulta, que u m parceiro com nome de hospc· dciro Bcrnard tem um arquivo que ele, Arnold. quer

25. Considere a rede mostrada no Problema 24. Usando o algoritmo de Dijkstm c mos trandtl se u trabalho usando mna tabela scmcl h:ante t'l Tahcl:l 4.3, raça o seguinte:

a . Calcule o camin ho mais curto de r nos da rede.

at~

todos

os

b. Calcule o caminho mais cu rto de nós da rede.

11

at
os

1•

até todos os

c. Calcule o caminho mais curto de nós da rede.

d . Cakulc o caminho rnaas curto de w até todos os nús da rede.

c. Calc ule o caminho mais curto de y até todos os nos da rede.

r.

Calcule o caminho mais cuno de nós da rede.

~

até todos os

26. Considere: a rede mostrada a seguir c ad mila que:

cada nó inicaalmcnte conheça os custos ate cada um de seus va;idnhos. Considere o algoriuno de vetor de distànclas c mostre os registros na tabela de distàn· elas para o nó z.

descarregar. Supon ha também que Bcmard c Arnold estejmn fXH mls de um:t NAT. Teme elaborar um\1 técnica que permita que Arnold estabeleça uma cone· :oc(lo TCP com nc rn:wd se m a conng,umç-.'lo da NAT de nplicaçllo es pecifica. Se ' 'ocê tiver dillculdadc na elaboraç;lo dessa técnic;a, discuta o porquê. 2l. Considerando a Figura 4.27. enumere os caminhos

de y a

11

que n~o tenham nenhum laço.

23. Repita u ,,roblema 22 considerando os caminhos de z a t, t a u c t a "'·

24. Consadcre a seguinte rede. Com tiS custos de enlace andacndos. use o algontmo do canu nho maiS cu no de Dijkstra p:1ra calcular o c.1minho mais curto de x até todos os nós da rede. Mostre como o algoritmo funciona calculando uma tabela semelhante à Tabela 4.3.

27. CorlSidcrc uma topo logi:l ~cral (isto t. nilo a rede cspcdfica mostrada anteriormente) c um:~ 1•crso\o sin· crona do algon tmo de l'ctor de distãncias. Suponha que. a cada ncraçâo. um no tr
bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r o;.;e.;.t_________________________

\':llorcs de dist:lncla eles J)()dcrn Informar uns aos outros?

28. Consrdere o fmgmemo de rede mostrndo a seguir.;.: tem apenas dois ,,izinhos ligados a ele: w c y. w tem um canunho de custo minnno ate o destino 11 (n;lo mostrado) de 5 c> tem um caminho de custo mtnimo 11 de 6. Os carmnhos completos de "' c de y até u (e entre "' c) } n.,o s;\o mostmdos. Todos os \'lllores dos custos de enlace na rede s:lo números inteiros cstrit:uncntc posith'OS.

b. Agora sup Se houq:r um problema de c
33. Dcscre"a corno lnços no caminho podem ser detectados com CGP.

a. OC os vctorc:s de dist:lnclas de x para os destinos

"'· y c 11. b. O~ uma mudança de custo de enlace pma cCx. w) ou para c(Y,y) Hll ttucx informar.\ a s..:us vizinhos um novo c~HniniH) de custo minimo até u .:omo resultado d.t execução do algoritmo de vetor de distâncias c. Dê uma mudant:~ de custo de enlace p.·ua c(.Y. w) ou pam c(,Y, >> t:ll que x n~o in[orma~ a seus vazmhos um novo caminho de custo mínimo até u como resultado da execução do algoriuno de 'ctor de distâncias. 29. Consrdcrc a tO!>Oiogia de três nós mostmda na Figum 4.30. Em vez de ter os custos de enlace da Figuro 4.30, os custos de enlace s.lo: c(,Y, y ) = 3, c()'. z) = 6. c(~. x) = 4. Calcule as tabelas de dist:lncias após a etapa de inacralizaçâo e após cada itcraç:lo de uma vcrs:\
34. Um roteador CGP sc m1>re escolher::\ uma rota sem laços com o menor comprimento de AS-path?

juslifique Sull fCSJ)()li1n.

3S.

Considcr~ a rede abaixo. Suponha <1uc ,\ 53 c ;\ S2 cstcpm rodando o OSPF paro seu prutocolo de rotc· amento intra-r\S. SuJx>nha que AS I c AS4 cstcj~m rodando o RIP para seu protocnlo de roteamenao lntra-AS. Supon ha Cjuc o ci3GP e o 113GP sejorn usados p.1rn o protocolo de roteamento rntm-AS. Inicialmente, s upo nha que nllo haja enbce físico entre AS2 e AS~.

x 1>0r qual protocolo de rotc;,memo: OSPF, RIP, eBGP ou rBGP?

a. O roteador 3c sabe sobre o prefixo

b . O roteador 3a sabe sobre o prefixo x por qual protocolo de roteamento? c. O roteador lc sabe sobre o prefixo protocolo de roteamento?

x por qual

d. O roteador ld sabe S()hrc o prefixo x por qual protocolo de roteamento? 4b

30. Considere 11 problema da contagem atê o innnito no roteamcn tt) de vetor de distâncias. Esse problcm:ocorrcr.\ se reduzirmos o custo de um enlace? Por quê? 1: se conectarmos dois nós que nao possuem e nlace? 3 1. Demonstre que , p~m o algoritmo de vetor de distân-

cia 11:1 Figura 4.30, cada "alor no vetor de distância O(.Y) ~ n:1o crescente c. consequemcmentc, se estabilizar.\ em um numero finito de etapas. 32. Considere a Figum 4 31 . Suf>tmha que haja outro rotc.ador w, conectudo aos rotcildorcs y c a. OS custos de todos os enlaces são: c(x. )') "'4, c(x. u "'50, c() . w) • I. c( ~. w) • I, c()'. z) = 3. Suponha que a revers:lo em enenada :.eja utiliz;ldtl nv algoritmo de roteamento de vetor de drstlncia. a . Quando o roteamento de vetor de distância é estabili zado, os roteadores w, y e z informam uns aos outros sobre suas distâncias para x. Que

A~1

36. Rcfcrindo·se ao problema anterior. uma \'ez que o roteador l d sabe sobre:<, ele inserirá uma entrada (,Y, I) em sua tabel:l de rcp.1sse. a. I sem igual a 11 ou I, para essa entmda? Justique a rcspoJ>ta em uma fras~. b. Agom suponha que haja um enlace fisrco entre AS2 e AS4, ilustrado pela linha pontilhada. Supo· nha que o roteador ld saiba que x é acessível por

bow4tto4ic~ Capítulo • melo de AS2 c de AS3. I será definido para I, ou 1/ justinquc o resposta em uma fr.~SC.

c. A~orn suponha que haja outro AS. dcnomin:1do AS5. que fica no caminho .:ntrc A$2 e A$4 (n:lo Ilustrado no dtagrama). Suponha que o roteador ld Sõlib;~ que ~ é acessível por meio de AS2 AS5 AS4. bem como de AS3 AS4. I será definido para 11 ou ll ? justíOquc a resposta em uma frase. 37. Considere a scgumtc rede. O ISP B pro,·ê scnico nacional de backbonc ao ISP regional A. O ISP C rmwê SCI'\ iço nacional de hackbonc ao ISP regional D. Cada ISP consiste em um 1\S. Usando BGP, B c C forn1.~m pares entre si em dois lugares. Considere tráfego na direção de A a O. B preferiria passar esse tráfego pom C na Cosia Oeste (de modo que C teria de absmvcr o custo ele can·cgar o tráfego :uravés do pais). enquanto C preferiria receber o Lr:lfego via seu ponto de formaç;\o d~ par com ll na Costa Leste (de modo que 13 carrcg:tria o trMego ~ma v(-s do pais). Qu:tl mecanismo 13GP C p que B cntreg:tssc o tr:lfcgo de A a O em seu pomo de fomlaç:\c> de par na Costa Leste? Para responder a t."Ssa pergunta, voei' precisará estudar muito bem a ~!Specinca~o do UGP.

38. Nl\ Fi~urn 4.42, considere n infonnac;ãt) de camin ho que chega às suh-rcdcs stttb \V, X e Y. Com base na lnftmtHIÇ~o diS(Hmfvcl em \V c X. quais são as rt:Sj)CCti,•as visOcs da lupo logia lhl rede? justillquc sua resposta. A tO(>n l o~ia vistn de Y ~ mostr:tda a seguir: X

W

A

c

TopolOgia Yista~•

redulubY y

39. Considere que a Figum 4.42.8 nune:t ene:tminharia 1r:lfcgo destinado a Y através de X b:tseado no rotca· mcnto BGP Mas existem muitas aplicações conhecidas pam a> qu.us os pacotes de dados v.\o pdmciro para X c depois p:~rn Y. JdentiOque tal aplicaç;lo. e descreva como os pacotes de dados percorrem um caminho não determinado pelo roteamento BGP.

A u11oda de rede

313

40.

a Figura 4.42. SU(>Onha que haja outra rede stub V cliente de ISP A Suponha que 8 c C tenham uma relu· ção de interconexão, c que A seja cliente de B c de C. Suponha. ainda. que A gostaria de ter o tmfego destinado para \V ,;ndo apenas de B. c o trafego destinado para V vindo de 8 ou C. C<~mo A dcvcda anunciar suas rotas para B c C? Quais rotas AS C recebe?

-f 1.

Considere a rede de sete nos (com nos rotulados <1.: t a:;:) do Problema 4. Mostre a :\n·orc de custo mini mo com raiz em :t que inclua (como hospedeiros fin:tis) us nós u, v, w 1" y. justifique informalmente por que sua :\1'\'0rc é uma árvore de CIISIO rninimo.

42. Considere :ts duas nbordagens b:lsk:ts idcntillcadas para fazer bmadcas1: cmuln ~Ao de unfcc1st c broadcast de c;mlor roteador) c SUponha que seja ll~ldO vmculmSI de SIXIIIII ÍIIJj tr'eC pam ra~cr lml(lllmsr de C:UlHid:t de rede. Co nsidere um Llnlco remetente c 32 destinatários. Supon ha que o remetente esteja concct:~clo aos destinatários por uma árvore binária de roteadurcs. Qulll ê o custo para enviar um pacote IJmcrc/((W nos casos da emulaç:\o de unict1s1 c de llwnclccm de camada de rede para essa topologia? Aqui, cada wz que um pacote (ou cópia de um pacote) é enviado J>vr um unico enlace. ele incorre ern uml'l unidade de custo. Qu:lltopologia para intcrconcctar o remetente. os destinatádos c os rotc;~dorcs far:l com que os custos da emulação de uttlc
43. Considere a opcrac;;lo do algoritmo de repasse de caminho im·crso (RPF) nl'l Figura 4.44. Usando a mesma topologia, d~cubm um conjunto de cami· nhus de todos os nós ate o no de fonte A (c indique CSSí:S caminhos em um gra ro usando linhas grossas como as da Flgu r:t 4.+4 de modl> que, se esses cnmi· nhos rorcm •>S camlnh,)~ de menor cuSU), cntti.O o m\ D receberia. uma cópi:1 das mensagens de broadcctsl ele A dos nós A, C c O sob RPF. 44. Conside re a topulogia ilustracb na Figura 4.44. Supo nha <1uc todos os cnl:1ccs tenham custo unitário e que o nó E é assados usando RPF c enl:~ccs pelos quais pacotes nâo scr.\o rcp:ISsaclos, dado que o no E c a fonte.

45. Rcp1ta o Problcma+t utilizando o gr:ll'ico do Problema 24. Admita que :t na rome de brO

Admllindo que c:ncla roteador conectado use seu caminho de menor custo nté o nó C paro cnvi:tr mcns:lgcns de ades.~o a C. desenhe n árvore de roteamento b."ISC· nda no ccmro resuhamc. Essa an·ore ê uma án·ore de custo tnllllmo? justifique sua resposta. 4 7. Repit.1 o Problema 46, usando o gráfico do Problema H. Adm1tn que o no ccntml seja ,., al~tontmo de roteamento de estado de enlace de Oijkstra para calcular os caminhos lllli((ISI que são, individualmente, os caminhos de menor c usto d:~ fome ate todos os destinos. Podcrfamos imaginar que a união desses Cõlminhos forme uma ::irvorc 1111ÍC11st de caminho de menor cliSto (o u urna .11'vorc tmiCiul de camin ho mais curto. se todos os custos de enlaces rossem idênticos). Consm1indo um exemplo que nega essa allrmaç:lo (um C
..8. Na Seç.lo 4 5 I estudõlmos o

..9. Considere uma rt-dc na qual todos os nós cst.'lo conectados n três outros nós. Em uma única etapa de tempo. um nó pode recehtr de seus vizinhos todt)S os p;1cotcs transmitidos por l>roodcasr. duplicar os ~co tes c enviá-los a todos os seus vizinhos (exceto ao nó que enviou um dado pacote) Na próxima etapa. nós ' 'itinhos podem r.:cehtr. duplicar c repassar esses pacotes c assim por diante. Suponha que seja utilizada a inundacão njo controlada para pro,·c r b,-omlmst

a css.1 rede. Na etapa de tcrnllO 1. quantas cópias do p:tcotc broodcasr scroo trnnsmludas. admitindo que. durante a etapa I, um unico pacote broadcnsr é transmitido pelo nó da fonte a seus tri!s VIZinhos? 50. Vi mos na SecJo 4. 7 que nlo hn nenhum protocolo de camada de rede que possa ser usado para identificar os hospedeiros que participam de um grupo mu lrimsl. Isso posto. como aplicações '"tc/ricasl podem aprender 1\.S Identidades dos hospedeiros que estão participando de urn ~rUJ>O multicast?

51. Projete (de uma descriç~o fictlcia em pseudocódigo) um protocolo de n1 vel de nplicaç.io que rna ntenh:t os endereços de hospedeiros parn todos os hospedei ros participanu.•s de u1n ~trupo multi((rSI. ldcnt iOquc eSJ!eciOcamcnte n scl'\li\n de rede (wticasr ou mullifasr) que e usado por seu pro tocolo c Indique se seu J>rOli!Colo .:stá ctwhmdn nwnsagens dentro da banda ou rnra do lmlda (com rclaç;\o ao fluxo de dados de aplicaç;\o entre os participantes do grupo mulricasl) e por qu~ . 5 2. Qual é o tamanho do espaço de endereço ttudticasr? Suponha ~gorn que dois grltpos multicast cswlhnrn nlcatoriamcnte um cnderec;o mu/lf((ISI. Qual é a probabilidade de que cscolhnm o mesmo endereço? Suponha agora que mil gn1pos mullicctsl estejam em o peraç-:lu ao mesmo tempo c escolham seus endereços de gn11>0 mulríctiSI nlcat(lri:unentc. Qual é n probabilidade de que uns intcrlimm nos outros?

Questões dissertotivos l.

Descubra 1r~ empresas que estão vendendo roteadorcs de alta ve locidade. Compare os ro teadores mais

6.

ricamente as mcns.1gens que um hospcclc1ro utiliza

pmcntcs que elas comercializam. Como voe~ deliniu "mais pntcnlcs"? 2.

3. ...

para rcconllgurar uma NAT.

Use o serviço whols da Amcrlc01n Reglst ry Cor lntclllct

Sur1cmha <1uc os t\Ss X c Z nno estejam diretamente conectados, ma~. em vez disso. estej01 m co nec tados

Numbers (httt)://www.arin.net/whois) p:tra determinar

pelo AS Y. Suponho também que X ten ha um acor-

OS blocos d~ endereços I f> paro tr.::S unl"crsidadcs. Os scn•icos whois podem ser u:..1dos JXIm c.lctcmlin.u com certeza a localiut;Jo de um endereço IP CSt)Ccffico?

do de hucrligac•lo com Y c que Y tenha um :u:ordo

É posslvd escrever o programa ping cliente (usando

cam:gar o trMcgc> de X. O UGP permite que Z. imple-

mensagens ICMP) em Java? Justifique sua resposta.

mente essa polttica?

Na Seção 4 4, dissemos que a disponibilização do IPv6 tem s1do lenta. Por que? O que é ne<:cssáno para acelerar sua disponiblliz.1çilo?

S.

Pesquise sobre o protocole! Ul'nP. Descreva especi-

7.

de interlígaçJo com Z. Finalmente, supon ha que Z qucim carregar lOdo o tráfego de Y. mas mlo
8.

"la Scç-Jo 4.7. idcnlllicamos uma série de aphc;IÇ(iCS mulllcttsl. Qua1s dcss.1S aplicações se aJUStam bem ao modcl1l mínimJicsta de serviço m~tltlro

Discuta alguns dos problemas que as . ATs criam

Por quiH Qua1s aplicac:c\es não se ajustam panicular-

para a segurança lpscc (veja IPhifer, 2000)).

mentc bem a esse modelo de serviço?


A u11oda de rede

315

Torefosde programação Nesta tarefa de progmmacJo, você cscre\•erá um con· junto ·distr•huldo' de procedimentos <1uc implementam um roteamento de vetor de dtstânc•as assmcrono distri· buido pam a rede mostmda a seguir. Você deve escrever as seguintes rotinas que *rodarão~ assincrom1mcntc deturo d() amb•cnte emulado fornecido para ~sa tarefa. Pam o nó O. voe~ escreverá as rotinas:

rclniiO(). Essa rotina será chtlmada umtl vc1. no i meio du cmulac:lo. rthtitO() n:lo tem argumcn· tos. Você deve iniclali::.tr sua tahela de distâncias no m\ 0 pam rcnctir OS CllSlOS diretoS de l , 3 e 7 :ué os nós I, 2 c 3. respectivamente. Na fig· urn anterior. todos vs cnlt11:es ~lo bidirccionais c os custos em :unb.1s as dtrcc;õcs s.'lo Idênticos. r\pos iruci:.th:t:.tr :.t tabcl:.t de distâncias e quais· quer outrns estnuuras de dados necessárias às rotinas de seu nó O. este deve ent:lo enviar a seus vizinhos dirctamente ligados (nesse caso. I . 2 c 3) o custo de seus caminhos de custo minimo parn todos os outros nós da redt. Essa mformac:'lo do custo minimo é enviada aos nos vizinhos em um pacote de atualizac;.;lo de roteamento denominado rotina rolaycr20, como descrita na tarefa completa. O form:.tlo do pactue de atuali z.wao de roteamento t;unbém está dcscrim na t:~rcfa completa.

rwpdtltrO(srrurr Hpkr *r(\'llplrr). Essa rotínu será chamada quando o nó O receber um

pacote de roteamento que foi enviado a ele por um de seus v•zmhos diretamente conectados. O parlmctro •rcnl1'kr c um indicador para o pacote que fo1 recebido. rtuprrcntcs do caminho mais curto de i pam todos os o111ros nús da rede. rrupdareO() usa esses valores rccebín\prin tnhcla de distâncias (cmno especificada pdo algoritmo de \'Chlr de dist:lncias). Se seu própric> custe> m111imo até um outn• nó muda r como resu ltado d~1 atualizaç;lo, o nü O infor· mar:\ essa mud:m~" no custo mmimo a seus vizl nht>S dilctamcntc conectados enviando a eles um pacote de roteamento. Lembre-se de que no algoritmo de vetor de distâncias apenas
mnbicnl r hardwart'lsciflwan· silnulcrdr1. nrvd rmw vcrsdo cl
Tcrml1~111

cslll cHsprl·

Wireshork Lob Ntl Companlon Wehsile deste livro, www. aw. com/ kur os e_br. você encontrará duas tarefas de labt)raiMio Wireshark, em inglês A prímcim examina a operação do

protocolo lf' c, em par ticular, o rorm.no do datagrama IP. A segunda explora :1 tlllliz:u;ão do protocole) ICMr nos coma ndos ping c traceroutc

bow4tto4ic~

Vinton G. Cerf Vinton G Serf é vice-presidente e evongelisto
E"'

O que o fez se decidir pela especiolizoçõo em rede?

Eu trabalhavn como programador na UCU\ no final da dccada de 1960 com o patrocínio da Adv:mccd Rcscarch ProjecLS Agcncy do Dcpanamcnto de Defesa dos Estados Unidos (na ~poca <:onhccida como ARPA e hoje, como DARPA). Meu trabalho era desenvolvido no laboratório do professor Lconard Klclnrock no Nctwork Mcasurcmcm Ccmcr da rcc~m-criada ARPAnet. O primeiro nó da ARPI\nct foi instalado na UCLA no dia 1c de setembro de 1969. Eu era responsável pela programação de um computador utilizado para coletar informações de desempenho da ARPAnct c passar essas informações para comparaç-Jo com modelos matemáticos c previsões de desempenho da rede. Eu c \':\rios outros cstud:mtes de pós-graduação ~ramos responsáveis pelo tralYo~lho com o que era conhecido como protocolos de nível de hospedeiro da ARPAnet -os procedimentos c formatos que pcrmlliriam a intcraçlo dos muitos tipos diferentes de computadores na rede_ Era uma uploração fascinante de um novo mundo (para mim) de computacâo distribuída e comunicaç-.lo. Quondo começou o projetor o IP, você imoginovo que esse protocolo tomar·se·io tõo predominante quanto é hoje? Quando Bob Kahn c eu começamos a trabalhar nisso, em 1973, acho que estávamos muho mais preocupados com a questuo central: como fazer com que redes de pacotes heterogc'!ncas intcragisscm umas com as outras, admitindo que nilo podcrfamos mod ifi cú· l:~s. Espcr:lvamos descobrir um modo que permitisse que um conjunto arbitrllrio de redes de t•omutaç;lo de pacotes fosse interligado de maneira transparcmc, de modo que os compui'tdores componentes cl<~s redes pudessem se comunicar nm a nm sem prccis:•r de ncnhtuna tradução entre eles. Acho que sabramos que est:lvamos lidando com uma te<.:nologia poderosa c expansrvcl, mas duvido que tivéssemos uma idcia muito clara do que seria o mundo com centenas de milhões de computadores todos illlerlig:•dos com a Internet. Em suo opinião, qual é a futuro do, redes e do Internet? Quais sôo os grandes obstóculos/ desofia' que estão no cominho da seu desenvolvimento? Acredito que a Internet. em particular, e as redes. em geral. cominuar-lo a proliferar. Hoje já existem evidencias convancentes de que haverá bilhões de disposuivos habilitados para a Internet, entre eles equipamentos como telefones celulares, refrigeradores. POAs. servidores residenciais, televisões. bem como a costumeira coleção de

bow4tto4ic~ laptops, servidores c assim por diamc. Entre os grandes desafios est~o o s uporte para a mobilidade, a duraCl)o das baterias. a capacídadc dos enlaces de acesso à rede c a cs<:alabilidaclc ilimitada do miclco ótico da rede. A tarda com :1 qual estou profuncl;uncntc em•olvido no Jct Propulsion l.llboratory ~ o projeto de uma extcns.'\o intcrplanet:lri:l d:1 Internet. Precisaremos descobrir u m atalho para passar do 1Pv4 !endereços de 32 bitsI para o 1Pv6 1128 bits I. A lista é comprida! Quais pessoas o inspiraram profiuiona lmente?

Meu colega Bob Kahn: o orientador de minha tese, Gernld Estnn: meu melhor amigo. Stevc Crockcr (nós nos conhecemos na escola secundária e ele me apresentou aos computadores em 1960! ); c os milhares de engenheiros que conunuam a desenvolver a hucmct. Você pode dar a lg um conseU\o aos estuda ntes que e.stõo ingressando no campo das redes/Internet?

Nào limite m seu pensamento aos sistemas existentes- imaginem o que poderia ser possfvcl c então comecem a tmbalhar para descob rir um meio de: sair do estado atual das coisas c chegar hl. Ousem sonhar; eu c a lguns colegas do Je t Propulsion Labor:nory estamos trabal hando no projeto de uma extensão interplane tária da Internet terrestre. A implementa<;;to dessa rede pode Jc,"tlr dCcadas, uma missão por ''ez, mos. usando uma pnrrtrrasc: ~o homem deve tcnt:lr alcançar o que está rom do seu nlcance: scn~lo, para que existiriam os c~us? "

bow4tto4ic~

Acamada de enlace e redes locais

N

o capitulo anterior, aprendemos que a camada de rede rornece um serviço de comunicaç;lo entre dois

hospedeiros Como mostra a Figura 5.1, esse caminho de co munica~-;lo consiste em uma série de enlaces

de comumcaç:lo que tem inicio no hospedeiro d e origem, passa por uma série de roteadores e termina no hospedeiro de destíno. A medida que continuamos a descer a pilha de protocolos, d;t camada de rede :ué a camada de enlace. é natural que tmagincmos como pacotes são cm•iados pdos enlaces mdtviduats dentro do caminho de comuntcaç;)o fim a fim. Como os datagramas de camada de rede süo encapsulados nos quadros de camada de enlace para transmiss;'\o por um único enlace? Protocolos de camada de enlace podem pro\Cr lransrcr~ncia confiá,•cl de dados de roteador a rotc:tdor? Protocolos de camada de enlace dircrcn tcs podem ser usados nos dircremcs enlaces ao longo do cammho de comunícaç-.lo? Neste caphulo responderemos a essas c a outras pergum:IS. Ao d tscullr a camada de enlace. dcscobnremos que há dois tipos de canats de camada de enlace completamente dircrentes. O primeiro tipo são os canais de bnxrdcast. que são comuns e m redes locais (I..ANs}, I..ANs sem fio, redes por satélite e redes de acesso híbridas de cabo coaxial e de fibra (IIFC}. No caso do canal de broadwst, muitos hospedeiros esH\o conectados ao mesmo canal de comunicaç:lo c é preciso um pro10colo de acesso ao meio para coord enar transmissOes e e''itar colisões entre quadros transmitidos. O segundo tipo de canal de camada de enlace é o enlace de comunicação ponto a pomo , tal como o existente entre dois rote11dorcs ou entre um modem discado residencial e um roteador ISP. Coordenor o acesso a um enlace ponto n pon to é trivial, mas há alnd:~ ques tões impOrHI IIICS referentes a enquadramento, trar\SferCncia conn.tvel de dados, de tecção ele erros c controle de n uxo. Nes te capitulo estudaremos diversas tecnologias lmportames de c:un:1da de enlace. Examinaremos minudosamentc a Ethernct, d e longe a tecnologia predominante para LA s com fio. Estud:1rcmos também o protocolo ponto a ponto (fiOÍIIHO·JJoint protocol- PPP) , o preferido para modems discados em hospedeiros residcnci:lis. Embora ccn:uncnte sejam tópicos de camada de enlace, as redes Wi-Fi c, nmis geralmente, as L.ANs sem fio scl".lo estudadas no Capitulo 6, dedicado às redes de computadores sem Hoc a mobilidade.

5.1

Camada de enlace: introdução e serviços

Vamos come\·ar com um pouco de tenninologia ütil. Achamos que, neste capitulo , é con,enicnte que nos refiramos aos hosped eiros c ro teadores apenas como nós, já que, como veremos em breve, nilo estaremos panicularmentc preocupados em saber se um nó é um roteador ou um hospedeiro. Também nos rderiremos aos canais

bow4tto4ic~ (opilulo S

ISP nacional ou global

Rede móvel

Aplicaçâo (nl..... d<

Compu tador-fonte Aplicação

l

Transporte

d~dos

ffsica

Rede

Enl. •<« .d.d

I tri1 '

a -

Ffsica

319

A tomado de enlou e rede\ locais

Aplica~ o

d~

d'(!~

-i

-

l[

Fisica

11

Computador-alvo

Aplicação Transporte Rede ti' •

L

Física

Rede corporativa

Figura S.l Acomodo de enlace de comun ka<.~o qw,: conectam nós :1djncentes ao lo ngo dos cnminhos de comunicnç!lo como enlnees. Para levnr um datagrama de um hos pedeiro de o rigem até um hospedeiro de destino, o datagra ma tem de ser transpOrÚldo sobre cada um dos enlaces indi viduais existentes no caminho fim a nm. Considcrnnclo um dado enlace, um nó transmissor encapsula o datagrama t m um quad ro dt camada dt enlnce e transmite o quadro pnra dentro do en lace. c um nó receptor recebe o quadro c extrai o datagrnma.

5.1.1

Os serviços fornecidos pelo
Um protocolo de camada de enlace é usado para transportar um datagrama por um enlace individual. O protocolo de camada de enlace define o rormato d os pacotes trocados entre os nós nns extremidades do enlace, bem como ns ações realizadas por esses nós ao enviar c rccehe r os pacotes. Lembre-se de que no Capítulo l dissemos que as unidades de dados trocadas pelo pro tocolo de camada de enlace slo dcnomln;~dns quadros e que cada quadro de camada de enlace caracteristicamente encapsula um datagrama de camada de rede. Como veremos adiante, entre as ações realizadas por um protocolo de camada de enlace ao enviar c receber quadros, estão


detecção de erros, retransmiss;\o, controle de fluxo e acesso alea tório. Como exemplos de protocolos de camada de enlace ternos os protocolos Ethernet, 802.11 para LANs sem fio (também conhecidas corno \Vi-Fi). tokcn ring e PPP. Analisaremos muitos desses protocolos detalhadamentc na segunda metade deste capftulo. Enquanto a camad:1 de rede tem como tarefa mo,•imcntar segmentos da camada de transporte fim a fim, desde o hospedeiro de origem au~ o hospedei ro de desti no, u m protocolo de camada de enlace é encarregado de movimentar datagramas de camada de rede nó a nó por um uniro mlact no cammho. Uma característica importante da camada de enlace é que um datagrama pode ser transponado por dtfcrentes protocolos de enlace nos diferentes enlaces no caminho. Por exemplo. um datagrama pode ser transportado pelo protocolo Ethcrnct no primeiro enlace. pelo PPP no último enlace c por um protocolo WAN de camada de enlace nos enlaces interrncdiarios. É importante notar que os serviços fornecidos pelos protocolos de camada de enlace podem ser diferentes. Por exemplo, um protocolo de camada de en lace pode prover ou não entrega confi:wel. Assim, a camada de rede deve ser capaz de realiza r sua tarefa fi m a fim em face de um conjumo heterogeneo de serviços individuais de camada de enlace. Pam uma boa compreens:lo d:l camada de enlace e de como ela se relaciona com a camada ele rede, wunos considerar u ma a nalogia com um sistema de transport e. Cons idere um agente de viagens q ue está fazendo o plancjamemo de um:1viagem para um turista desde Princeton, em Novajersey. at~ Lausannc, na Surça. O agente de viagens decide que é mais conveniente para o turist<~ peg:1r urna limusine de Princeton :u~ o Aeroporto JfK, em seguida um av ião do r\eroportoJFK até o Aeroporto de Gencbr-.1 c. finalmen te. um tre m do Aeropono de Genebra a té a est:v,:~o ferrovi:lria de Lnusanne. Assim que o agente fizer as tr~ reservas, !! respons:1bilidade da empresa de Jimusines levar o turista de Princeton ao Aeroporto JF~ é responsabilidade da companhia aérea levar o turista do Aeroporto JFK a Genebra, c é rcsponsnbilidadt do trem suíço lc,'l\r o tltrista de Genebra a L:\usannc. C:tda um dos trts segmentos da viagem é 'direto" entre duas localidades 'adjacen tes". Note que os trts 5cgmentos de tr:msporte são administrados por empresas diferentes c usam meios de transporte completamente dHerentcs (limusinc. avião c trem). Embora os meios de transporte sejam diferentes, cada u m deles fornece o serviço básico de le,'ar passageiros de um:1 localidade a outra localidade adjacente. Nessa comparaç.lo com o transporte. o turista é análogo a um datagrama. cada segmento de transporte é análogo a um enlace de comunicação, o meio de transpone é análogo a um protocolo de camada de enlace c o agente de viagens é análogo a um protocolo de roteamento. Embom o serviço básico de qualquer camada de enlace seja mover um datagrama de um nó até um nó adjacente por um unico enlace de comun icação, os detalhes do serviço podem vanar de um protocolo de camada de enlace pam outro. Entre os possíveis sef\iços que podtm ser oferecidos por um protocolo de cam.'lda de enlace. cst:\o:

Enc/IICiclrmncnlo de clmlos. Quase lodo:; os protocolos de camada de enlace encapsulam <..'3da datagrama de camada de rede demro de um qltttdro de camada de enlace antes de tmnsmlti-lo pelo enlace. Um quadro consiste em um campo de dados no qu:ll o datagrama da camada de rede é inserido c em uma série de campos de cabeçalho. (Um quadro pode incluir també m campos de tmiler [campos no llnal do q u:tdrol. contudo. "amos nos referir também aos campos de trailer como cam pos de cabeçalho.) A cstrutum do q uad ro é especificada pelo protocolo de camada de enlace. Veremos diversos formatos ele quadros diferentes qu•mclo c.x aminatmos os protocolos de camada de enlace específicos na segunda metade deste capitulo.

Acesso 110 m/crct. Um protocolo de controle de acesso ao meio (mecliwn crcass colllrolrnotocol - MAC) cspcclnca as regras segundo as quais um quadro é tr-Jnsmhido pelo enlace. Para enk1ccs ponto a ponto que tém um único remetente em uma extremidade do enlace c um unico rc<:eptor na outm cxtremidlÍ\'Cr ocioso. O caso mais intcrcss:mtc é q uando "-drios nós comJXtrlllham um unil'O enlace de bnxrdmst- o denommado problema de acesso múltiplo. Aq ui. o protocolo MAC sen·c para coordenar :lS transmissões de quadros dos muttos nós; estudaremos protocolos 1\-IAC detalhadamente na Seção 5.3. Enlrtga confiá"cl. Quando um protocolo de camada de enl.'lcc fornece serviço confiável de entrega. ele garante que \'ai transportar cada datagrama da camada de rede pelo enlace sem erro. Lembre-se de que certos protocolos de camada de transporte (como o TCP) tambem fornecem um sef\rtço confiável de em rega. Semelhante ao que acomece com um serviço confiável de cmrega de camada de transporte,

bow4tto4ic~ Co pi1ulo S

A (amado de tnlou e rede$ locais

32.1

consegue-se um serviço confhh•cl de enuega de cam:~da de enlace com rcconhccimcmos c retransmissões (veja n Seç.'o 3.-l). Um serviço confiável de cnueg.t de camada de enlace é muito usado por enlaces que costumam ter altas taxas de erros, como é o caso de um enlace sem fio. com a finalidade de corrigir um erro localmente, no enlace no qual o erro ocorre. em vez de forçar uma retrans miss;)O fim a fim dos dados por um protocolo de camada de transporte ou de aplicação. Contudo. a entrega confiável de camada de enlace pode ser considerada uma sobrecarga desnecessána para enlaces de baixa taxa d e erros, incluindo enlaces de fibra, enlaces coaXJais e muilos enlaces de pares de fios trançados de cobre. Por essa razão, muitos protocolos de camada de enlace com no não fornecem um serviço de cntreg3 conflá\'el. Conuolr tlr fluxo. Os nós de cada lado de um enlace t~m uma capacidade limitada de armazenar q uadros. I:ste é um problema potencial. pois um nó receptor pode receber quadros a u ma velocidade maior do que sua capacidade de processá-los. Sem comrolc de fluxo, o buffer do receptor pode transbordar c q uadros podem ser perdidos. Semdhame à camada de transporte, um protocolo de t."amada ele enlace pode ro rnccer controle de nuxo para evitar que o nó remetente de Lttn lado de um en lace congcstlo11e o no receptor do outro lado do enlace. Drttc('tlo tlc t"rros. O hardware da camad;1 de enlace de um nó receptor pode decid ir incorretamemc que um bit ele um quadro é O quando foi transmilido como 1 c vice-ve rsa. Esses erros de bits süo introd uzidos por
Corrl'(tlo dr rrTo.ç. A correção de erros é semelhame à detecção de erros. exceto que um receptor não somente detecta quando ocorreram os erros no q uadro, mas também determma exatamente em que lugar do quadro os erros ocorreram (c, então . os corrige). Alguns protocolos fornecem corrcç;lo de erros na camada de enlace apenas para o cabeçalho do pacote, c n;lo para o pacote mtciro. Exanu narcmos a detecç:lo c a corrcç:lo de erros na Se~·ão 5.2.

Hcllf-cluJilcx t full-lluplc.x. Com transmissão fu/1-tlul'le.x. os nós em ambas as extremidad es de um enlace podem transmitir pacotes ao mesmo tempo. Com transmissão half-duplrx um nó m\o pode transmitir c receber pacotes ao mesmo tempo. Como dtssemos antes, muitos serviços fornecidos pela camada de enlace apresentam grandes paralelos com os sen•iços ro mecidos na camada de 1ranspone. Por exemplo, tanto a camada de enlace como a d e transporte podem fomeccr entrega confiável. Embora os mecanismos usados para prover entrega confiável nas duas camadas sejam semelhantes (veja a Seção 3.4 ). os dois serviços d e ent rega confiável nilo s;lo Iguais. Um protocolo de transporte fornece entrega c:onflávcl de scgmt>ntos entre doís processos q ue operam n m a fi m na redt>; um protocolo de enlace confiável fornece serviço de entrega confiável emre dois n Os ligados por um (mico enlace. De modo semelhante, tanto os protocolos de camada ele enlace como os de camada de trnnsporte podem fornecer con trole de n uxo c detccç-ilo de erros: novamente, o controle de nuxo em urn pro tocolo de c~mada d e transporte é fornecido fim a fim , enquan to em um protocolo de camada de enlace t: forn ecido emrc nós adjacentes.

5.1.2 Onde a camada de enlace é implementada? Antes de mergulharmos em nosso detalhado estudo sobre sobre a camada de enlace, vamos considerar a qucstlo de ondr a camada de enlace é implementada. Daqu i em diante focare mos em um sistema final , visto que já aprendemos no Capitulo -+ como a c-.unada de enlace é implementada em uma placa de linha de um roteador. A camada de enlace de um computador de.,·c ser implementada em um software ou em um hardware? Deve ser implememada em uma placa ou chip separado e como ocorre a imerface com o res to d o hardware de um h ospedeiro e com os componentes de sistemas o peracionais?


i\ Figura 5.1 mostra a arqulu~lllra de um llpíco hospedeiro . Na m:tior parte. a camada de enlace é implementada em um adapta dor de rede, por vezes também con hecido como controlador de interface d e rede (NlC). o nud co do adaptador de rede está o controlador da camada de rnlacc, normalmente um unico chip de sistema especial, que implcmcnta vários serviços da camada de enlace (cnqu:~dramcnto, acc:.so ao enl:~ce, controle de fluxo, reconhecimento de erros etc.) como visto na sessão an terior. Dessa form:1 muito da funcionalidade do controlador da ~:amada de enlace é implementado em ha rdware. Por exe mplo. o controlador da lmcl815-lx (Intel 20091 nnplemer11a os protocolos Ethcm et. os quais estudaremos na seção 5.5; o controlador t\thcros AR5006 (Athcros 2009) lmplemcnta os protocolos Wl Fl802. ll que csmdaremos na se~ão 6.3. Até o final dos anos 90, a maioria dos adaptadores de red e eram placas fisicamente separadas (como a placa PCM Clt\ ou uma placa plug-in que se encaixa em um slot para cartão PCl de um computador), agora cada vez mais adaptadores de rede estllO sendo integrados na l>laca-m;\c do hospedei ro -uma configuração charn:~da LAN-on-mothcrboard.

No lado mmsmissor, o contro lador separa um datagrmna que foi criado c o arrnazcrmdo na memória do hospedeiro por camadas mais ah as da pilha de prowcolos, cncapsula o datagrama em uma camada de enlace (preenchendo os v:lrlos campos do quadro), c então transmite o quadro para um enlace de comtmic:u;;1o, seguindo o protocolo de acesso ao enlace. No lado receptor, um co rllrolador recebe todo o quadro c extrai o daLagrama da C'Jmada de rede. Se a camada de enlace dctuar uma vcri fi cação de erros,{: o controlador tran smissor q ue estabelece os bits de dctccc;~o de erros no cabe1,:alho de quadro e é o controlador receptor que executa a vcrific:IÇ:lo de erros. Se a ~-amada de enlace tiver seu nuxo controlado, os controles de transmiss<\o c de recep1,-t\o trocam informações d e co m role de nuxo para que o controlador de cn"io envie quadros ern uma velocid:tde que o receptor possa lid:tr.

A Figura 5.2 mostra um ltdaptador de rede conectado ao barramento do co mputador (por exemplo, PCI ou barramento PCI-X) . que se parece muito com qualq\tcr outro dispositivo de entrada/salda dos outros componen tes do computad or. A figura 5.2 mostra também que, enquanto a maior parte da cam:tda de enlace é Implementada em hardware no cartão de interface. parte da camade de enlace é unplementada em software que é executada na CPU elo hospedeiro. Os componentes do software da camada de enlace upicamcnte implememarn uma funcionalidade camada ele enlace de um nível maior. como receber um datagrama da camada de rede. montando lnfonnaçOcs de endcrc~rnento da camada de enlace c ativando o control e de h:~rdwarc. No lado receptor, o software da camada de enlace responde a in terru pçóes do controlado r (por exemplo. dc,•rdo ao recebimento de um ou mais quadros). lida com condi~õeS de erro c passa o datagrama para a <.-amada de rede. Assi m , :1 camada de enktCC ~ Ullla combina<,'õ'O d e hardware C sortw·Jre- O lugar na pilha de protocolos, onde sortware encontra O

Computador Aplica~ o

Tranlf)O(te

Rede Enlace

.1 ....-~

CPU

Memória

li

I I

'I

.

:./

--

Barramento

r- do Computador (e.g .• PCI)

Controlador 1- Adaptador

Enlace

de Rede

Física ' ...........

Transmissão Física ~

' Figuro 5.2 Adoptodorde rede: seu relocionomento com o resto dos componentes do hospedeiro e ofuncionolidode do pilho de protocolos

bow4tto4ic~ Co pi1 ulo S


323

hardware. (Intel 20091 fornece um panorama legivcl (assim como descrições detalhadas) do controlador 8254x d o ponto de vista de uma programaçlo de software. J\ Figura 5.3 mostra os adapt.1dores transmissores c receptores. Com a funcionalidade principal da camada de enlace sendo implememada pelo controlador, os adaptadores são unidades sc miautõnomas. sendo seu trabaUto transfenr um quadro de um adaptado r ao o utro. Vários pesquisadores Já invesugaram a possib1hdadc de acrescentar mais funcionalidade (além do processamendo d e camada de enlace) aos adaptadores de rede. O comrolador 825'1x, por exemplo. pode calcu lar a soma de verilkaç-Jo TCPIUDP c a soma de vcrificaç-Jo do cabe1.-alho IP em hardware. I! a functonahdadc da ca mada de rede da camada de t ransporte sendo unpl ementada pelo controlador da c-Jmada de enlace. Apcs;~r de parecer urna violação uh.raj:mtc do princípios de disposiç.lo em camadas. a vantagem é que as somas de verificação podem ser calculadas com mais rapidez do que em software, até o ponto que al guns podem ficar lcmados a ignorar essa violação de princfpíos. [Mogul 20031 fornece uma discuss:\o imcressantc dos prós e co ntras do dese mpenho de processar o TCP em um adaptador. [Kim 2005 1 investiga o desempenho de uma fun cionalidade de m;~ior nfvc l (l iTTP em cachc) no adaptador.

S.2 Técnicos de detecção e correção de erros Na seç:io anlcrior, observa mos que detecção c correção de crr~ no nivd de b its - clctcq~io c correção ela corrupçlo de bhs em um quadro de camada de enlace enviado d e um nó para outro nó \•izinho flsicameme ligado a de- s;1o dois serviços frcqucntcmcmc fornecidos pela cam"'da .. de enlace. Vimos no Capítulo 3 que serviços de dctccç:io c correç;'o de erros tamb~m s.\o frequentemente oferecidos na eam:~da de transporte. Nesta sec;lo, cxamiM· remos algumas das técnicas mais simples que podem se,r usadas para detectar e, em alguns (.-:JSOS, corrigi r esses erros de bits. Como esse assumo- em especial. a teoria c :1 implementação dessas t~cnicas- é tratado dctalhadamcme por muitos autores (como (Schwanz, 19801 ou (Bertsckas, 1991 J). nossa abordagem será necessariamente breve. Noss.~ meta é desenvolver urna visào intuitÍ\'3 d as capacidades q ue as técnicas de dctccç.lo c correçfto de erros fornecem c ver como algumas técmcas Simples fu ncionam c são usadas na prátrca na camada de enlace. A F1gura 5.-1 ilustra o cenário de nosso estudo. No nó remetente, para que os dados, O, fiquem protegidos contra erros de bns . eles são aumentados com bits de detccç-.lo c de corrl'Ç:lo (rrror tlrtution-
O desano do receptor é determinar se O' é ou nào igual ao O origi nal, uma ' 'CZ que recebe u apc n
Enla
Cart:io adaptador

Protocolo de
Figuro 5.3 Adaptadores de rede em comunicação: um dotogromo de umo comodo de rede revestido porum quadro de comodo de enlace


+ Oatagrama

Datagrama

H,

@ Erro detectado

D

o·

EOC

EOC

Enlace sujeito a erros

Figura 5.4

escolher um esquenm de detecçi\o de erros para o qual a probabilidade de que css.•s ocorr~ncias aconteçam seja pequena. Em geral. técnicas mats soriSticadas de detecção e correç.io de erros (isto é, as que tém uma probabilidade menor de permtlir erros de biiS não detectados) ficam sujeitas a uma sobrecarga maior- é preciso mais processamento para compuwr c transmitir um n úmero maior de bits de detecç.lo c corrcc;\o de erros. Vamos examinar agora tr~s técnicas de detecção de erros nos dados trans mitidos - verificações de paridade (para ilustrar as ideias básicas da detecção e correção de erros). metodos de soma de veriOcação (que s;lo mais empregados na camada de transporte) c verificações de redundãncra ctclica (CRCs) (que s;lo normalmente cmprt"gadas na camada de enlace. nos adaptadores).

5.2.1

Verificações de paridade

Talvez a mancim mais simples de detectar erros sej:t utilizar um único bit de paridade. Suponha que a informação a ser enviada. D na Figura 5 .5. tenh:t cl bits. Em um esqucm"ar de bitS de valor 1, o receptor saberá que ocorreu pelo menos um erro de bit. Mais precisamente, ele saberá que ocorreu algum nl1mcro rrnpar de erros de bit.

Mas o que acontecerá se ocorrer um numero par de erros de bit? t bom que vo<:i~ se convenç[t de que isso resultaria em um erro n:lo detectado. Se a probabilidade de erro de bitS for pequena e se for razoável admitir que os erros ocorrem mdependentemente entre um bit c o bit segui me, a probabílidade de h:wcr vários erros de bi!S em um pacote seria bastante pequena. Kcsse caso. um único bit de paridade poderia ser suficiente. Contudo. medições demonstraram que, em vez de acontecerem independentemente. os erros frequentemente se aglomeram em ·rajadas·. Sob a condiçtlo de mjada de erros. a probabilidade de haver erros n:'lo detectados em um quadro protegido por um esquema de paridade de bit ünico pode se aproximar de 50 por cento ISpragins, l99l I. Claro que é necessário um esquema de detecção de erros mais robusto (e, felizmente, é o que se usa na prática!). Mas,

bow4tto4ic~ Capitulo )

A (Omodo de enlou e

rede~

locais

325

Bit de paridade

d bits de dados

01110001 1 0101011

Figura 5.5 Poridode po1 com um bit de paridade antes de ex:uninannos os esquemas de detecção de erros que são usados na prática, vamos consíderor uma generoliZ
Suponhn agoro q uc ocorra um erro de bit único nos (I bits originais de informaç:lo. Com esse esquema de parid ad e bidimcnsion ~ll , tanto a l:r.tridadc da coluna quanto a ela rHa que contiver o bil modificado estarão com erro. O receptor cmuo nuo somente pode detectar que ocorreu um erro de um bit unico, mas também usar os fndi ces da f11a c d:1 coluna com erros de paridade paro realmente identificar o bit que roi corrompido c corrigir aquele erro! A Figura 5.6 mostro um exemplo no qual o bit com Vülor I na pos1çào (2, 2) está t·orrompido c mudou para um O- um erro que não somente é detcctávcl, como também corrigfvel no receptor. Embora nossa discussão tenha focalizado os t1 bits originais de informação, um erro unico nos próprios bits de paridade também é detectá\•el e corrigfvel. t\ paridade bidimcnsionaltambém pode detectar (m;ts não corrigir! ) qualquer combinação de do1s erros em um pacote. Outros propriedades do esquema de p:mdade bidirnens1onal são discutjdas nos exercícios ao final deste capítulo. t\ capacidade do receptor paro detectar e corrigir erros é conhecida como correção d e erTOS de rep a_-.se (fon~md CIIOI

corrrcrlon - FEC). Essas técnicas são comumente usadas na armazenagem de áudio e em equiParidad~

"'c:>

8

de linha

d,,,

dq

d,·l·1

d2,1

d2. j

d,,.,

d~l

d;.;

dq.,

~

"O ~

"O

"''C:~"'

d,.,,l

Erro de bit único corrigivel

Nenhum erro

o

o o o

o oo

o o

o

o o o oo

o oo o o o

Erro de paridade

figura 5.6 Poridode porbidimensionol

Erro de paridade


pamcntos de rcproduç;\o, como CDs de áudio. Em um ambiente de rede, as t~cnicas FEC podem ser usadas Isoladamente ou em conjunto com as técnicas ARQ. que examinamos no Capftulo 3. As técnicas FEC são '·aliosas porque podem reduzir o número requerido d e retransmissões do remetente. Talvez o m:us unportamc seja que elas permllem imediata corrcc;lo de erros no receptor. Isso evita ter de esperar pelo :~traso de propagac;lo da \'iagcm de ida c voha que o remetente precisa para receber um pacole NAK c para que um pacote rctransnlllido se propague de \'Oita ao receptor - uma vantagem potencialmente importante para aplicações de rede em tempo real [Rubcnstein . 19981. Pesquisas que examinaram a unhzação da FEC em protocolos de controle de erros estão os de [13icrsack, 1992: !l:onncnmacher, 1998: Byers. 1998: Shacham, 19901.

5.2.2 Métodos de soma de verificação Em t~cnicas de soma de verificação, os d bits de dados na Figura 5.5 S
rápida em sorLwarc m\o somcmc para códigos de sorna de vcrirlcaçào pondcmda, mas Lambem para CRC (veja a seguir) c outros códigos.

S.2.3 Verifica,õo de redundância cíclico (CRC} Uma t~cni ca de detccç-lo de erros usada amplamcmc nas redes de computadores de hoje ~ baseada em códigos de verificação d e redundancia cíclica (c:ydic redurulancy rlu·cl~ - CRC). Códigos ele CRC t:unbém são conhecidos como códigos polinomiais, J•t que ê possfvcl considcr.1r a cadcí;\ de bits a ser cnvi;tda corno um polinômio cujos coeficientes s'o os \'alorcs O c I na cadeia de bits. sendo as opcmçõcs na cadeia de bits interpretadas como aritmétka polinomi:tl. Cóthgos de CRC runcionam como segue. Considere a parcela de d bits de dados, O, que o nó remetente quer cn"iar pam o nó receptor. O remetente e o receptor devem. primcirumcnte, concordar com um padrão de r + 1 bits. conhecido como um gerador. que denominaremos G. Vamos cxtgír que o bit mais significativo (o da extrema esquerda) de G seja um I. A rdeia rundarnental por tn\s dos códtgos de CRC é mostrada na Figura 5.7. Para uma dada parcela de dados, O, o remetente escolherá r bits adicionais, R, e os anexará a O de modo que o

bow4tto4ic~ A cama da de en lou e redu locais

Capitulo )

dbits

r bits

D: bots de dados a enviar

R: bits de CRC

D • 2' XOR

Figura 5.7

327

Padrâo de bit Fórmula matemática

R

Códigos de CRC

padrão de d + r bitS resultante (interpretado como um número binário) seja dh·lstvd exatamente por G (por exemplo, sem nenhum remanescente), usando ariun ética de módulo 2. Assim, o processo de venficaçllo de erros com CRC é sim ples: o receptor divide os d + r bits recebidos por G. Se o resto for diferente de ze ro, o receptor saberá que ocorreu um erro: caso contrario, os dados são aceitos como corretos. Todos os cikulos de CRCsilo feitos poraritmétka de módulo 2sem Vai 1' nas adiçO<:s nem 'emprcsm 1' nas subtrações. Isso s ignifica que a adição e a subtração são id~micas e ambas são cquivalemcs à operação ou exd11sivo (XOR) dos b its dos opcrandos. Por exemplo.

1011 XOR 0 101 - 1110 1001 XOR 1101 0100 Também de modo semelhante lemos:

1011 - 0101 - 1110 1001 - 1101 - 0100 A muhiplicaç;'lo e a divisão são as mesmas da aritmética binária. exceto que. em qualquer adição ou subtração exigida. nào se somam nem se emprestam casas. Como na ari unêtica binaria comum. a multiplicação por 2' desloca um padrão de bits para a esquerda por 1: casas. Assim, dados D c R. a quanlidade (O · 2') XOR R dá como resultado o padrão de bit ti + r mostrado na Figura 5. 7. Usa remos ess.'l represe mação algébrica do padrão de bit cl + r da Figura 5. 7 em noss.'l discussão a seguir. Vamos agora voltar à questão crucial de como o remetente calcula R. Lembre-se de que queremos descobrir um R tal que exista um 11 que

(D · 2') XOR R = nG, isto t, devemos escolher um R tal que G d ivida (D · 2') XOR sem resto. Se us.1rmos a operaç;lo ou rxclusil'o, isto é, adidonarmos bin:-eriamente, sem vai l , em R em ambos os lados da cquaçiio anterior, teremos:

D · 2' = nC XOR R. Essa equaç:\o nos d iz que. se dividirmos D · 2' por G, o valor do resto ~cr.l exatamente R. Em outras pala"ras, podemos cnlcular R como

_ D · 2' R = resto-G

=

=

A Figura 5.8 ilustra esses t:·ãlculos para o caso de D 101110, d = 6 c G 1001, r = 3. Os 9 bits transmitidos nesse caso são 101110 011. Voe~ deve fazer esses cálculos c também ver iricnr se. na verdade, D • 2' = lOLOll · G XOR R. PadrOcs internacionais foram definidos para gcmdorcs G de 8, 12, 16 c 32 bits. O padr11o CRC 32 de 32 bits, que foi adotado em uma série de protocolos do IEEE da camada de enlace, us.'\ um gerador igual a: G (.RC;.U

= 10000010011000001000lll0110Jl01ll.

CadJ um dos padrocs de CRC pode detectar erros de rajada de menos do que ' + I bits. ( Isso significa que todos os erros de bus consecutivos de r bitS ou menos scr.lo detectados.) Além d•sso. sob lupótcscs apropriadas, uma rajada de compnmento maior do que r+ 1 b1ts t detectada com probabilidade de I - 0,5'. C1da um dos padrocs de CRC também pode detecmr qualquer número ímpar de erros de bits. A teoria por trás dos códigos de CRC e de códigos até mais poderosos ultr.tpassa o es<:opo deste livro. O Livro de [Schwartz, 1980[ oferece uma excelente introdução a esse tópico.


G

O I O 1 1

1001!101110000 1001 ".. 1

o

1

ooo o1o oo1

"..

o

I 1 O

ooo , oo oo 1 o 1 o I O O 1

o

1 1

~ R

figura S.8 Um ex~mplo de <ôkulo de CRC

5.3 Protocolos de acesso múltiplo Na introduç:lo deste capllulo, observamos que há dois tipos de enlaces de redes: enlaces ponto a ponto e enlaces l)lomlccut. Um enl ace: pon to a ponto consiste: em um unico remetente em uma extremidade do enlace: c um t\nico receptor na outra extremidade do enlace. Muitos protocolos de l~mada de enlace foram projetados para enlaces pomo :1 I>Onto; o PPP ( protocolo pomo a ponto) e um controle de ligaÇ(Io de dados (IIDCL) de :.tho m vcl são alguns protocolos que examinaremos mais ad iante neste capitulo. O segundo upo de enlace, o en lace broadcast , pode ter varios nós remetentes c receptores. todos conectados ao mesmo canal de transmissão unico c compartilhado. O termo br~Xtclc~Ut ~ usado aqui porque, quando qualquer um dos nós transmite um quadro. o canal propaga o quadro c cada um dos nós recebe uma cópia. A Ethcrnct c as LANs sem fio Silo exemplos d e tecnologias de broe~dwsl de camada de enlace. Nesta scç-Jo, vamos nos afastar um pouco dos protocolos espccfllcos de l-amada de enlace e examinar, primcirameme, um problema de impontinc•a fundamental para a camada de enlace de d01dos: como coordenar o acesso de \'á rios nós remeternes c receptores a um canal btae~dcast compartilhado - o problema do acesso múltiplo. Canais broaclcas1 s;\o muito usados em LANs, redes que csl:\o gcograllcamcntc concen tradas em um único edifício (ou empresa, ou campus universitário). Assim. no fimtl da scç;\o, examinaremos também como os canais de acesso múltiplo são usados em LANs. Todos estamos f;~mlliariz;~dos com a noç"o de broodmst - a tclcvis.'o us-1 essa tccnologl
a todos uma oportunidade de

" ão fale até que

algu~m

fale com

falar.~ vocé.~

"Não monopohze a conversa.· · Levante a mão se tiver uma pergunta a

fazer.~

•Não interrompa uma pessoa quando ela estiver falando: "Não durma quando alguém estiver falando. "


A camada de tnlou e redu locais

329

Redes de computadores tem prOLocolos semelhantes - denominados protocolos de acesso múltiplo - , pelos quaiS os nós regulam sua transmissão pelos canais broodcasl compartilhados. Como mostra a Figura 5.9, os protocolos de acesso muluplo sM necessários em uma ampla variedade de cenários de rede. que inclui redes loc;~is com fio c sem fio c redes por satélite. Emborn tecnicamente cada nó acesse o c;~nal b10(/(lms1 por meio de seu adaptador, nesta seção vamos nos referir ao nó corno o dispositiVO de envio c de rccepç:'io. Na prática, cente• nas ou até milhares de nós podtm st comunicar djrctamentc por um canal biOtiClctiSI. Como todos os nós tem a capacidade de transmitir quadros. mais do que dois nós podem transmitir quadros ao mesmo tempo. Quando isso acontece, todos os nós recebem \'lÍrios quadros ao mesmo tempo. isto é, os quadros trnnsmitidos colidem em todos os rcccpton:s. Em geral, quando há uma colisio, nenhum dos nós receptores consegue perceber algum sentido nos quadros que [oram trnnsmitidos; de certo modo, os sinais dos quadros que colidem llcam inexcricavclmente cmb.·ualh:tdos. Assim. todos os qu:1dros envolvidos na colis:io são perdidos c o can:Jl broatlcast t desperdiçado durn me o Intervalo de colis:lo. É claro que. se muitos nós querem transmilir quadros frequentemente, multas transnussõcs rcsuh:Jrlo em colisões c gra11de pane da largura de banda do canal bro(I(ICIIS! scnl dcspcrdiçada. Para :tsscgumr que o canal bromlclo; um lcvama•ncmo abrangente dos primeiros 20 :mos desse volume de trabalho pode ser cnconcrado em I Rom, 19901, Além disso, a pesquisa ativa sobre protocolos de acesso mtlhiplo comi nua devido ao s urgimcmo concfnuo de novos cipos de e11laces. panicularrnente 11ovos enlaces sem fio. Durante anos, dezenas de protocolos de acesso múltiplo for.m1implementados em uma variedade de cemologias de camado de enlace. Não obstante, podemos classíficar pracicmncnte quolquer protocolo de acesso mt'•ltiplo em uma das seguintes categorias: protocolos de divisão de canal. protocolos de acesso aleatório e protocolos de reve:amento. Examinaremos essas categorias de protocolos de acesso ml\ltiplo nas tr~ subseções seguintes. Compartilhado com fio (por exemplo, Ethernet)

Compartilhado sem fio (por exemplo. Wi·Fi)

Sat~lite

Coquetel

~zzzzz

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....Vamos concluir essa vis\o gemi mencionando que, Idealmente, um protocolo de acesso mú h iplo paro um canal broaclcast com velocidade de R bits por segundo tem as seguintes caroctcrfsticas desejáveis: l . Quando apenas um nó tem dados para enviar. esse nó tem uma vaz:'lo de R bps. 2. Quando .\1 nós tem dados paro enviar, cada um desses nós tem uma vazão de R/.\1 bps. Isso n:\o stgmfica necessariamente que cada um dos M nós sempre terá uma velocidade irlStantãnca de RIM. mas que cada nó de,•erá ter uma velocidade média de transmissão de R/1\t durante algum intervalo de tempo adequa· damentc definido. 3. O protocolo é descentralizado, isto é, nllo há nós mestres que possam falhar c derrubar o sistema inteiro. 4. O protocolo é si mples para que sua implementação seja barata.

5.3.1 Protocolos de divisão de conal Lembre-se de que na ScçM l.3 dissemos que a mulúplexaç~\o por divis:lo de tempo (TOM) c a multiplcxaç-Jo po r divis:'lo de frcquencia ( FOM) s<'lo duas técnicas que podem ser us;tdas pura dividir a largura de banda de um canal bro{l(lca~t entre todos os nós que compartilham esse canal. Como exemplo, s uponha que o canal suporte N nós c que a velocidade de trttnsmissào do canal seja R bps. O protocolo TOM divide o tempo em quadros temporais e d epois divide cada quadro temporal em N compartimentos . (O q uadro temporal TOM não d e,•e ser confundido com a unidade de dados de camada d e enlace trocada entre adaptado res remetentes c receptores, que tamb
4KHl{l~-----~l

f ' " ' " ' 4KHz-[IL--------------~J 1

TOM

Legendcl:

f:l Todos os compartimentos com rótulos '2' I:J são d edicados a um par ~metente/receptor Mpedfico Figura 5.1 O Um exemplo de TOM eFDM de quotro nós



331

Enquanto o protocolo TDM companílha o <:anal brcxulwsr no tempo, o protocolo FOM d h•lde o canal de R bps em rrcqu~ncras drferemes (cada uma com uma largura de banda de R/N) e reserva cada rrequência a um dos N nós. criando . desse modo, N canais menores de RIN bps a partir de um único canal maior de R bps. O protocolo FDM compartilha as vantagens do pro tocolo TOM - evita colisões e divide a largura de ronda com justiça emre os N nós. Porém, tam!Xm comparo lha uma <1<:$\'antagem princiJXll com o pl'O(ocolo TOM - um nó é hrmtado a uma largura de banda R/N, mesmo quando é o único nó que tem pt~cotes a enviar. Um tcrccrro protocolo de divisão de canaJ é o protocolo de acesso múhiplo por divisão de código (codc

divisiou multiplt crcuss - COMA). Enq uanto os protocolos TDM c FDM atribuem aos nós intervalos de tem po c rrcqutnclas, respccLivamcm c. o protocolo COMA atribui um có
5.3.2 Protocolos de acesso oleotório A segu nda classe gemi de protocolos de acesso múltiplo s:\o os pro1ocolos de acesso aleatório. Com um pro1oco lo de acesso alealório, um nó transmissor sempre transmite à 1axa total do canal. isto é. R bps. Qut~ndo há uma colis.lo, c.tda nó Cn\'OI\'ido nela retransmitc rcpetldamcnle seu quadro ( isto ~. paco1e) a té que este passe sem colisào. Mas, quando um nó sofre uma colisão, ele nem sempre re1mnsmi1e o quadro imediatameme. Em \'t'
Slotted Aloho Vamos começar nosso eswdo de protocolos de ace!õso aleatório com um dos mais simples de-sses protocolos, o slou ed i\LOHA. Em nossa descrição do slotted ALOHA. admitiremos o seguinte: Todos os quadros consistem em cxalamenle L bits. O tempo é dividido em intervalos de 1amanho UR segundos (is10 é, um inten•alo é Igual ao tempo de tmnsmiss:lo de um quadro). Os nós começam a transmitir quadros somente no início dos lnlervalos. Os nós s;lo sincronizados de modo que cada nó sabe onde os intervalos comcç;un. Se dois ou mais nós colidirem em um inlen-alo, então lodos os nós dc•cc1arJo o e"cnto de colis:lo an tes do 1érmino do inlcrvalo. Seja I' uma prolxtbrlidade, isto é, um número entre Oc L O funcionamemo do sloued ALOHA em cada nó é simples: Quando o no 1cm um novo quadro para en,·iar, e!õpera até o inicio do próximo rntervalo c transmite o quadro mlciro no intervalo. Se não houver uma colisão, o nó rransmiórá seu quadro com sucesso e, assim, não precisará considerar " retransm issão do quadro. (0 nó pode preparar um novo quadro para transmitir, caso tenha algum.)

bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'------------------------Se houver uma coliSão. o nó a detectara antes do final do intervalo. Ele retransmitira seu quadro em cada intervalo su~qucnte com probabilidade p até que o q uad ro seía transmitido sem colis.\o. Por retransmissãO com probabilidade p, queremos dizer que o nó efeuvamcntc joga uma moeda viciada; coro:1 corrcspondc a 'retransnutir', o que ocorre com probabilidade I'· enquanto cara corrcspondc a · pule o inter· valo c jogue a moeda no,•amente no próximo inten-alo·, o que ocorre com prob:tbilidade (I - p). Todos os nós cn,•olvtdos n:1 colisão jogam suas moedas independentemente. Aparentemente o slotted ALOHA teria muitas vantagens. Diferentemente da partiç. o de canal, esse protoe<>lo permite que um unlco nó transmita co ntin uamente à taxa total do canal, R, quando ele for o único nó ativo. (Diz-se que um nó é ativo quanto tem quadros a enviar.) O sloucd ALOHA também t ;~ltamcntc dcsccmralizado, porque cada nó detecta colisOes c decide independentemente quando retrans mitir. (No entanto, requer que os intervalos sejam sincronizados nos nós; em breve discutiremos uma vcrsilo sem Intervalos do pro tocolo ALOiiA lu nslottcd ALOi lAI. bem como protocolos CSMA- nenhum deles requer essa sincromzaç;'lo e, portamo, s:'\o totalmt'nte dcsccntr-Jiizados.) O slotted ALOHA é também um protocolo ex tremamente simples. O slotted ALO l iA funciona bem quando h~ somente um nó ativo, mas qual é sua eficiCncia q u:mdo há vários nós ativos? Nesse caso. ht1 duas prcocupaçoes possfveis. A ptlmcira. como mostra a Figura 5.11, é q ue, q u:~ndo h:i vários nós ativos. uma ccrt:1 fraç;\o dos intervalos tcn\ colisOcs c, portanto, será 'clcspcr
Q

N6 I

Q

Q

N62

[2]

[2][2]

N63

[2] c

Q

D E

c

s

E

c

D E

s

s

Tempo

Legenda: C =Intervalo de colisAo E • Intervalo vazio S • Intervalo bem-sucedido

Figura 5.11 Nós I, 2 e3 (ofidem no primeiro intervalo. Onó 2finalmente ê bem-su(edido no quorto intervolo, onó 1no oitovo intervolo e o nó3 no nonointervalo

bow4tto4ic~ A camodo de enlou e rede\ locais

(opilulo S

333

Assim, quando ha N nós atl\•os. a eficiéncia d o sloued ALOHA é Np(l - fJ )' 1. Para obtermos a eficicncia mciXima para N nós ati,•os. temos de encontrar um p* que maximize essa expressão. (Veja os exercícios ao final deste t:apftulo para um esboço geral dessa derivação.) E. para obtennos a eficiência máxima para um grande número de nós ativos. consideramos o limite de NfJ"(l - ti"}' 1 quando N tende ao infinito. (Novamente. veja os exercícios ao final deste capítulo.) Após esses cálculos, descobr iremos que a eficiência maxi ma d o protocolo é dada por 1/e 0,37. Isto e. quando um grande numero de nós tem muitos q uadros a t ransmitir. então ( na melhor das h ipóteses) apenas 37 por cento d os intervalos realiza um trabalho útil. Assim. a taxa efetiva de transmissão do <.-a nal não é R bps, mas apenas 0,37 R bps! Uma analise semelhante também demonstra que 37 por cento dos inten •alos ficam vazios c 26 por cento apresentam colisões. Imagine o pobre do ad minis trado r de rede que comprou um s istema slou ed ALOHA de 100 Mbps esperando poder usar a n.'Cie para transmitir dados entre um grande número de usuãriosa unlala.'
=

Aloho O protocolo s lotted ALO IIA requer que todos os nós sincronizem suas transmissões para q ue comecem no inicio de um imerv:1lo. O primeiro protocolo ALOHA (Abramson, 19701 ern. n:\ rcal id:•de, um protocolo sem intervalos e total me me dcscentralí zado. No ALOHA puro, quando um quadro chega pela primeira vez (ísto t , um datagr.una d e <-amada de rede é pass:tdo para baixo a panir da ~-.unada de red e no nó remetente). o nó imediatamente transmite o quadro Imelro ao canal bromlcast. Se um quadro tmnsmiúdo sofrer uma colísào com uma ou mais transmissões, o nó rctransmillr.l nncdiawmcnte (após ter concluído a transmissão total do quadro que sofreu a colisão) o quadro com probabilidade JJ. Caso contráno. o nó esperará por um tempo de t.ransrniss:lo de quadro. Após essa espera. ele ent~o rctransmitirá o quadro com probabilidade p ou espera (permanecendo ocioso) por um o utro tempo de quadro com probabilidade I - I'· Para dctennmar a dici~ncia máxima do ALOHA puro. va mos focalizar um nó Individual. Consideraremos as mesmas premissas que adotamos na análise do sloued ALOHA e tomaremos o tempo de transmissão do qu.1dro como a umdadc de tempo. A qualquer dado tempo. a probabilidade de que um nó esteja transmitindo um quadro é /J· Su ponha que esse qu ad ro comece a transmitir no tempo 1<~. Como mostrado na Figura 5.12, para que esse quadro seja transmitido com sucesso, nenhum dos o utros nós pode começar sua transmiss.lo no intervalo de tempo h,, - I , 10 (. Essa transmissão se sobreporia ao inicio da transmissão do quadro do nó i. A probabilidade de que todos os outros nós nao 111icicm uma transmissão nesse intervalo é (1 - p)' 1• De mnneira semelhante. nenhum o utro nó pode iniciar ullla trans missão enquan to o nó i estiver transmitindo, pois essa transmissão se sobrepori:1 à parte nnal da transmissão do nó i. A probabilidade de que todos os outros nós n:\o Iniciem um:1 transmisslo nesse intervalo é também (1 - p)-'- •. Assim, a probabilidade de que um dado nó tenha uma transmissão bcrn·suc:cd ida é p( L - p)ll·' 11. Lc\rando ao limite, como fizemos no caso do sloHcd ALO I IA, descobri mos que a eflclê nciom;\~im a do protocolo ALO IIA puro ~ ele apcn:IS l/(2c) - exatamente a metade da cflciencia do slottcd ALOHA. I: este o prec;o c1ue se paga por um protocolo ALOHA totalmente descentralizado. Vai se sobrepor ao inicio do Quadro de I

•o

t

Vai se sobrepor ao final do quadro de i

to

Figuro 5.1 2 Transmissões interferentes no Aloho puro

t o+ 1

Tempo

bow4tto4ic~ Redes de compu tadore s e o Internet

Norm Abromsom eoALOHAnet Norm Abromsom, um doutor em engenharia, era apaixonado por surfe e interessado no comutação de pacotes. Esso combinação de interesses o levou õ Universidade do Hovoí em 1969. O Hovoí é for modo por muitos ilhas montanhosos, o que dificulto o instalação e o operação de redes terrestres. Quando não eslavo surfondo, Abromsoo ficava pensando em como projetor uma rede que fizesse comutação de pacotes por rádio. A rede que ele projetou linho um hospedeiro central e diversos nós secundários espalhados pelos ilhas hovoionos. A rede linho dois canais, codo um usondo uma foixo de frequêncio diferente. O conol no direção dos nós secundários Fozio broodcost de pacotes do hospedeiro central poro os hospedeiros secundários; e o conol no direção contrário enviava pacotes dos hospedeiros secundários poro o hospedeiro central. Além de enviar pacotes de informação, o hospedeiro central também enviovo pelo conol no direção dos nós secundários um reconhec imento poro codo pacote recebido com sucesso dos hospedeiros secundários. Como os hospedeiros secundários transm itiam pacotes de maneiro descen tra lizado, inevitavelmen te ocorriam colisões no eonol entre eles e o hospedeiro central. Essa observação levou Abromson o inventor, em 1970, o protocolo ALOHA puro, descrito neste copftulo. Em 1970, com o financ iamento con tfnuo do ARPA, Abromson conectou suo AlOHAnet õ ARPAnet. O trabalho de Abromson é importante não somente porque foi o primeiro exemplo de uma rede de pacotes por rádio, mos também porque inspirou Sob Metcolfe. Alguns anos depois, Metcolfe modificou o protocolo ALOHA e criou o protocolo CSMA/CD e o LAN Ethernet.

CSMA (Acesso múltiplo com detecção de portadora) Tanto no sloued ALOHA quanto no ALOHA puro, a d ecis<1o d e transmitir tomada por um nó independe da atividade dos outros nós ligados ao canal broadcast. Em particular, um nó n;\o se preocupa se por acaso um outro nó esL:i transmitindo quando ele começa a trans mitir nem pám de transmi tir se outro nó começar a inLerrcrir em s ua transmissão. Em noss:t analogia do coquetel, os protocolos ALO IIA se parecem muito com um convidado mal-educado que continua a tagarelar mes mo quando o utros pessoas cstdo ralando. Como seres humanos, temos pr01ocolos que nos levam não somente a nos comportar com mais civilidade. mas também a reduzir o tempo que gastamos 'colidindo' com o utros durante a conversação c, t"Onsequcntcme ntc, a aumentar a quan tidade de dados que trocamos durante nossas conversns. Espcciflemncnte, há duas regras importantes que regem a conversação educada entre seres humanos: Ouçt1 emir~ e/r falar. Se uma pessoa estiver falando. espere :né que ela tenha t erm ín~tdo. No mundo das redes, isso é denominado detecção de portadora - um nó o uve o canal antes de t ra nsmitir. Se um qundro de outro nó cstiYcr correntemente sendo tra nsmitido J>arn dentro do c::. na!, o nó cmao esperar:\ (se af.1s tará - ·back off) por um perrodo de tempo aleatório c. elltolo, nov;tmcnte sonda rá o canal. Se perceber que o canal csnt ocioso. o nó emão começar;\ a transmiss:lo de quadros. Caso comr-Jrio, ele cs1>Cmr:i J>Or um outro período alea tório de tempo c repetirá esse processo. Se alguém começar c1 jc1lar cro mtsmo tempo qur você, pare ele falar. No mundo das redes, isso é denominado detecção de co!isAo- um nó que está trans mitindo OllVC o cam•l enq uanto transmite. 5c esse nó detectar
bow4tto4ic~ A camodo de enlou e rede\ locais

(opilulo S

335

est:t transmitindo. A resposta a essa pergunta pode ser ilustrada utUU.tndo diagramas espaço/tempo (Molle, 19871 . A Figum 5.13 apresenta um diagrama espaço/tempo de quatro nós (A. 8. C. 0) ligados a um barramento línear de tr.u\Sm1ss.1o. O eixo horizontal mostra 111) . o nó O tem um quadro p;rm enviar. Embora o nó 8 esteja tmnsmitindo no tempo 11, os bits que estólo sendo transmitidos por B ainda não alcanç~ram D. Assim, O percebe o canal como ocioso em 11 • De acordo com o protocolo CSMA. O começa então a trela intcrrcrê ncin de um EspiiÇO A

8

c

o

------- tI

T~mpo

Figura 5.13 Diagramo espaço/tempo de dois nós CSMA com colisõo de transmissões

T~mpo


Espaço A

c

8

o

to ------------------

T!!mpode detecç~abortarnento

de colis.lo

Tempo

Tempo

f.gura 5.14 CSMA com dete<~õo de colisão quadro de um outro nó). O protocolo Eth ernet, que estudaremos na Seção 5.5, é um protocolo CSMA que usn detecção de colísllo.

S.3.3 Protocolos de revezamento Lembre-se de que duas propriedndes desejáveis de um protocolo de acesso müh iplo s

A camodo de en lou e redes locais

337

desvantagens. A primeira desvamagem é que o protocolo introduz um atraSo de seleç~\o- o penodo de tempo requerido para notificar um nó que ele pode transmiúr. Se, por exemplo. apenas um nó csth·er ativo. cm:\o esse nó transmitirá a uma velocidade menor do que R bps. pois o nó mestre tem de escolher cada um dos nós ociosos por vez. cada vez que um nó ativo úvcr em•iado seu número máJCimo de quadros. A segunda desvantagem é potencialmente m;lis séria: se o nó mestre ralhar, o cmal inteiro ficará inoperante. O Protocolo 802.15 c o protocolo de Bluclooth. que estudaremos na Seção 6.3. s.-\o exemplos de protocolos de polling. O segundo protocolo de revezamemo é o protocolo de passagem de pcrm bsào. Nesse protocolo, não ha nó mestre. Um pequeno quadro de finalídadc especial conhecido t:omo uma permissão ( tokcn) e pass:Jdo entre os nós obedecendo a uma dctcrmtn:~da ordem fixa. Por exemplo, o nó I poderá sempre cnvi:~r a pcrmissào ao nó 2. o nó 2 poderá sempre enviar" pcrmtssão ao nó 3, o nó N poderá sempre enviar a pcrmiSS
5.3.4 Redes locois (lANs) Protocolos de :~cesso nnlhiplo S;\o usados em conjunto com muitos ttpos dife rentes de canais broatlca.~r . Eles têm sido utiltztldos por canais de satélite c sem fio. cujos nós transmitem sobre um espcclro de rrequencia comum. Alualmcntc eles estão sendo usados no can;tl de acesso por cabo à Internet na direção usuário-provedor (veja a Scç:'!o 1.2) c s;\o utilizados extensivamente em redes IOC:lis (LANs). lembre-se de que um.'l l.A&'J é uma rede de computadores concemrada em uma :lrea geográfica, tal como um prédio ou um campus univcrsh:lrio. Quando wn usuário acessa a lmcmet a partir de um campus universitário ou de wna empresa, o acesso t quase scmprt feito por meio de uma LAN. EspcciOcamcntc, o acesso se d:l do hospedeiro para a LAN, para o rotC:ldor, para a lntcmt't, como mOSLra a Figura 5.15. A velocidade de rransmlssão, R, da maioria das LANs t muito alta. Mesmo no imcio d:1 década de 1980 já eram comuns L.ANs de 10 >.lbps; hoje, LANs de 100 \
Computadore~

de usuarios

Servidor Web Internet

legenda: ;;:: Interface

Figura 5.15 Computadores de usuários ocessom um servidor Web do Internet por meio de uma IAN. Ocanal broadcost entre ohospedeiro de um usuário eoroteador wnsiste em um enlace


[IEEE 802.3 20091), que eram redes de acesso aleatório. A segunda classe de tecnologias de I..AN compreendia as tecnologias de passagem de pemlissão, incluindo a token ring (também conhecida como IEEE 802.5 [IEEE 802.5 20091) c a FODI - interface de d ad os distribuída d e fibra Uam , 1994) . Como na Scç:lo 5.5 estudaremos as tecnolog1as Ethcmet com ma1s detalhes, nesta seç-Jo analtsaremos apenas as I..ANs de passagem de permissão. Nossa discuss~o sobre as tecnologias de passagem de permissão é intencionalmente breve, j:l que a inexorável concorrfncia da Ethc:rnc:t praticamente as extinguiu. Mesmo assim, para dar exemplos de tecnologia de passagem de permissão c apresentar uma pequena perspectiva histórica, scr:lutil falar um pouco sobre anéis de passagem de permissão, ou tokcn nngs. Em uma I..AN tokcn ring. os N nós da I..AN ( hospedeiros c rotead ores) estilo conectados em um anel por enlaces diretos. A topologia do anel define a ordem de passagem de pcrmisSti o. Quando um nó obtém a pcnniss
5.4 Endereçamento no camada de enlace Nós - ISto é, hospedeiros c roteadores- têm endereços de camada de enlace. Você talvez fique surpreso com rsso ao lembrar que d1sscmos, no Capitulo 4. que nós também tém endereços de camada de rede c Utlvez se pergunte por que, aOnal de contas. é preciso ter endereços na camada de rede e na camada de enlace. Nesta seç:\o, além de descrevermos a sintaxe c a fun\lO dos endereços de camada de enlace, esperamos esclarecer por que as duas camadas de endereços são uteis e, na verdade. indispensáveis. Estudaremos também o Protocolo de Rcsoluç.io de Endereços (r\cldrcss Resolutiou P1otocol - ARP). que provê um mecanismo que habilita os nós a trnduzírcm endereços IP para endereços de l"::mada de enlace.

S.4.1

Endereços MAC

Na verdade, n:to é o nó ( isto é, o hospedeiro ou o roteador) que tem um endereço de camada de enlace, mas o :tdaptador do nó. Isso é llustmdo na Figuro 5.16. Um endereço de camada de enlace é tnmbém denominado um cnde.-eço de L\N, um endereço fiSico ou um en dereço MAC (media crruss cono·ol- controle de acesso ao IA-23-F9-CD-06·9B

I SC-66-AB-90-75-81

I 4~BD-D2·0-S6-2A

I Figura 5.1 6 Cada adaptador cone
bow4tto4ic~ Capitulo S

A (amado de enlou e redes locais

339

meio). Como a express\o endereços MAC parece ser o mais popular, daqui em diante nos referiremos a endereços de camada de enlace como endereços MAC. Para a maior pane das lANs ( incl uindo a Elltcrnet c as lANs 802.11 sem fio). o endereço MAC tem 6 bytes d e com primemo, o que dá 248 possh·e•s endereços MAC. Como ilustrado na Figura S.l6. esses endereços de 6 bytes Silo tipicamente e.xpressos em notação hexadecimal. com cada byte do endereço expresso como um par de numcros hexadcdmais. Apesar de os endereços MAC serem projetados como permanentes. é possiVel mudar o endereço de MAC de wn adaptador v1a software. No entamo, pelo resto desta seção presunurcmos que o endereço MAC de um adaptador é fixo. Uma propried:~dc mtercsS:Intc dos endereços MAC é que nilo existem dois :~dapt:~dorcs com o mesmo endereço. Isso pode parecer surpreendente. dado que os adapt:~dores são fabricados em muitos p:~ises por intltncms empresas diferentes. Como uma empresa fabricante de adaptadores em Taiwan se certifica de que está usando endereços diferentes dos usados por uma empresa fabricante de adaptadores na Bélgica? A resposta é que o IEEE gcrencia o espaço fisico de endereços MAC. Em partic ular, quando uma empresa quer fabrit-ar adaptadores. compra, por u ma taxa nominal. uma parcela do espaço de endereços que consiste em 224 endereços. O IEEE :1loca a parcela de 224 endereços fixando os primeiros 24 bilS de um endcrc~·o MAC c permitindo que a empresa crie combinaçOrs exclusivas l"O ill os últimos 24 bilS para cada adaptador. O endereço MAC ele um adaptador tem uma csumum linear (oposta à estruwr,\ hienlrquictl) c nunca muda,

nao importtmdo p~•m onde vá o adaptador. Um comput:•dor portátil com um carulo Et hcrnct tem sempre o mesmo cndcrcc;o MAC. n:lo imJX>rt:mdo para aonde o c.'Omputador v~(. Um PDA com uma interface 802.11 tem sempre o mesmo endereço MAC aonde quer que vá. Lembre-se de que, :10 contrário, um endereço IP tem uma estruturo hierárquica ( isto é, urna parte que é da rede c uma parte que ê do hos pedeiro) e que o endereço IP de um no prcc:ísa ser trocado quando o hospedeiro muda de lugar. por exemplo, muda a rede ao qual esta conectado. O endereço MAC de um adaptador é análogo ao número do CPF de uma pessoa. que também tem uma estruturo linear c n:\o muda, não importando pam onde a pessoa vá. Um endereço IP é análogo ao endereço postal de uma pessoa. que c hierárquico c precisa ser trocado quando a pessoa muda de lugar. Exalllmcntc como uma pessoa pode achar liul ter um endereço postal, bem como um numero de CPF. também é util para um nó ter um endereço de camada de rede, bem como um endereço MA C. Como descrevemos no mrcio desta seção. quando um adaptador quer CIWiar um quadro para algum adapta· dor de destino. o adaptador remetente insere no quadro o endereço MAC do desuno c envia o quadro pam dcmro da LAN. Se a lAN utilizar transmissão bmadcast (como a lAN 802.11 c muitas lANs Ethcmct), o quadro será recebido c processado por todos os outros adaptadores na LA1 . Em particular. cada adaptador que recebe o quadro verificará se o endereço MAC de destino que está no quadro combina com seu próprio endereço MA C. Se os endereços combinarem, o adaptador extrairá o datagmma enccrmdo no qu:tdro c o JY.LSS.'1 para cima na pilha de protocolos :ué seu nó pai. Se os endereços não combinarem, o :~claptador dest-anará o quadro sem passar o datagrarna de camada de rede para cima na pilha d e protocolos. Assim, somente o adap tador no nó de destino interromperá sell nó 1>ai quando receber um quadro. No entanto, às vezes um adaptador remetente quer que tod os os outros adaptado res na LAN recebam c

tJroccsscm o quadro que de está prestes a en viar. Nesse caso. o
S.4.2 ARP(protocolo de resolução de endereços) Como exis tem endereços de camada de rede (por exemplo. endereços IP da Internet) c endereços de camada de enlace (Isto é. endereços MAC), é preciso fazer a tmclução de u m para o outro. P:1ra a Internet. esta é uma tarefa do p ro toco lo de rcsoluçl\o de endereços (mldrtss resof111ion protocol- ARP) [RFC 8261. Para compreender a necessidade de um protocolo como o ARP, cons•clerc a rede mostrada na Figura 5.17. Nesse exemplo simples, cada nó tem um único endereço IP e o adaptador de c.-ada n ó tem um único endereço MAC. Como sempre, endereços IP são mostmdos em notação decimal com pontos c endereços MAC, em notação

bow4tto4ic~ Redes de co 11 putod ores e o Inle r.;;n.;;, e;.. t-----------------------1A·23·f9•CD·Oó-98

tP;222.2l2.222.220

5C·66·AB·90·75·81

tP:222.222.221.223

49·BD·D2·C7·56·2A

tP;222.222.222.222

Figuro S.1 7 Cedo nó em uma IM tem um endereço IP e oodoptodor de codo nó tem umendereçoMAC hexadec:lmal. Agom, suponha que o nó com endereço IP 222.222.222.220 queira mand:n um datagmma IP para o nó 222.222.222.222. Nesse exemplo, os nós de ronte e de destino estno na mesma rede (LAN), no sentido do endereçamento estudado na Seção 4 .4.2. Para enviar um cl:uagrarna. o nó d:1 rente deve da r a seu adaptador não somente o datagmma IP, mas também o endereço MAC para o nó de destino 222.222.222.222. O :~dapl:ldor do nó remetente montar.i então um c1uadro de camada de enlace contendo o endereço MAC do nó receptor e enviará o quadro paro dentro da l.AN. A pergunta importante considerada nesta seção c como o nó remetente determina o endereço MAC para o nó com endereço IP 222.222.222.222? Como voc~j:i deve ter adivinhado. ele usn o ARP. Um módulo ARP no nó remetente toma como entrada qualquer endereço IP na mesma L.AN e retoma o endereço MAC corres· pondente. 1 o exemplo em questão. o nó remeteme 222.222.222.220 rornece a seu módulo ARP o endereço IP 222.222.222.222 c o módulo ARP retoma endereço MAC correspondente. 49-BD·D2·C7·56·2A. Assim. vemos que o ARP converte um endereço IP p:tra um endereço MAC. Sob mui tos aspectos. o ARP é análogo ao DNS (estudado na Seção 2.5). que converte nomes de hospedeiros para endereços IP. Contudo.

Mantendo oindependência dos camadas H6 diversos ratões por que os nós têm endereços MAC além de endereços de camodo de rede. Em primeiro lugar, lANs sôo projetados poro protocolo$ de comado de rede orbitrórios, c nõo openos poro IP e poro o Internet. Se os adaptadores recebeuem endereços IP, e nõo O$ 'neutros' endereços MAC, eles nõo poderiam suportar com facílidode oulros protocolos de camada de rede (por exemplo, IPX ou DECNet] . Em segundo lugar, se adaptadores usassem endereços de camada de rede, em vez de endereços MAC, o endereço de camada de rede teria de ser armazenado no RAM do adaptador e reconfigurado todo vez que o odoptodor mudasse de local (ou fosse ligodol. Outro opçõo é nôo usar nenlwm endereço nos adaptadores e fazer com que cada um deles posse os dados (corocleristicomente, um dotogromo IP) de cada quadro que recebe poro cimo no pilho de protocolos. A comodo de rede poderio, enlõo, verificar se o endereço combino com o endereço do comodo de rede. Um problema com essa opção é que o nó poi serio interrompido por codo quadro enviado à lAN, bem como por quadros destinados o outros nós no mesmo lAN broodcosl. Em resumo, poro que os comodos sejam blocos construtivos em grande porte independentes no orquiteluro de uma rede, muitos delas precisam ter seu próprio esquema de endereços. Jó vimos até agora três tipos diferentes de endereços: nomes de hospedeiros poro o comodo de aplicação, endereços IP poro o camada de rede e endereços MAC poro o comodo de enlace.



341

uma Importante diferença entre os dois conversores é que o DNS convene nomes de hospedeiros para máquinas em qualquer lugar da Internet, uo passo que o ARP convenc endereços LP apenas para nós na mesma sub-rede. Se um nó na Califómia tent.assc us:tr o ARP para converter o endereço IP de um nó no Mississippi, o ARP de,·olveria um erro. Agora que j:\ exphcamos o que o ARP fn, vamos ver como ele fu nciona. Cada nó (hospedeiro ou roteador) tem em suaRAM uma tabela ARP q ue contém ma~amentos de endereços IP para endereços MAC. A Figura 5.18 mostra como seria uma tabela ARP no nó 222.222.222.220. A tabela ARP também contém um valor de tempo de vida (TIL) que mdica quando cada mapeamento será ap:1gado da tabela. Note que a tabela n:'lo contém neccs· sariamente um registro para cada nó da sub-rede; alguns nós podem ter tido registros que já expiraram, ao passo que outros nos pod em jamais ter sido registrados na tabela. Um tempo de remoc;:'lo lipico para um registro é de 20 minutos a partir do momen to em que foi colocado em uma tabela ARP. Su po nha q ue o 11ó 222.222.222.220 queira enviar um datagrama que tem end ereço IP para o utro nó daque la sub-rede. O nó remetente precisa obter o endereço MAC do nó de destino. dado o end ereço IP daquele mesmo nó. Ess..1 tarefa ser:\ fáci l se a tabela ARP do nó remetente tiver um registro p:tra esse nó de destino. Mas, c se, naquele momen to, a tabela ARP nrLo tive r mn registro para o nó desth1at:\rl o? Em particular, SLtponha que o nó 222.222.222.220 qLieim enviar um datagrama pam o nó 222.222.222.222. Nesse caso. o nó remetente usa o protocolo ARI, p;~ra conve rter o endereço. Primeiro, o nó reme ten te monm um pacote cspcci:tl denominado ARP Qucry. Um pacote ARP tem di versos campos, incluindo os endereços IP c MAC de envio c de recepç;lo. Os pacotes ARP de co ns ulta c de resposta têm o mesmo rormato. A nmtlldadc do pacote de co nsulm ARP é pesquisar todos os outros nós na sub-rede paro determinar o endereço MAC corrcspondemc ao endereço IP que está sendo convertido. Vol tando ao nosso exemplo, o nó 222.222.222.220 passa um pacote de cons ulta ARP ao adaptador juntam ente com uma indicação de que o adaptador d eYe enviar o pacote ao endereço MAC de broadcast, a saber, FF-FF-FF-FF-FF-FF. O ad<~ptador cncapsula o pacote ARP em um quadro de camada de enlace, ttSa o endereço de broatlccl~l como endereço de destino do quadro e transm ite o quadro para dentro da sub-rede. Retomando nossa analogia de numero do CPF/endereço postal. note que a consulta ARP equl\':lle a um pessoa grilar em um escritóno panorJmico cheio de d ivisórias de alguma empresa (digamos. a empresa AnyCorp): •Q ual é o número do CPF da pessoa cujo endereço é divisória 13, Sala 112. An yCorp. Paio Alto, Cali[órnia?· O quadro que contém a consulta ARP é recebido por todos os o utros adaptadores na sub-rede (por t-ausa do endereço de /Jroadcasr) e cada adaptador passa o pacote ARP que está dentro do módulo ARP daquele nó. Cada nó verifica se seu cndcrcço IP combina com o endereço IP de destino no pacote ARP. O llnieo nó (no máximo) que atend e a CSS:l condição devoh•c um pacote ARP de resposta ao nó
rcz

O pro tocolo ARP :1prcse nt:l algumas camttcrislit é enviado dcnlro de um quadro padnlo. Antes ele t'Ontinuar a lcitum, é bom que você pense por que isso acontece. Em segu ndo luga r, o ARP é do ti(>o plug-:md-pla)', isto é, a tabela d e um nó ARP é construfdn automaticamente - ela não tem de ser co nflgumda po r u m admi nistmdor de sistemas. E, se um nó for d esligado da su b-rede, seu regisLro será finalmente apagado da tabela dos nós rcmanesccmes na sub-rede. Estudantes se perguntam se o ARP é como um protocolo de camada de enlace o u um protocolo de camada de rede. Como vi mos. um pacote ARP é enc-apsulado demro de um quad ro de camada de enlace c assim encontra· se :trqunctamente acima d:t camada de enlace. No entanto , um pacote ARP tem campos que contém endereços de

Ende~ IP

Endereço MAC

nL

222.212.222.221

SS.B2·2F·54·1 A·OF

13:45:00

222.222 222.223

5C-66·AB·9G-75·B1

13:52:00

Figura 5.1 8 Umo possível tabelo ARP no nó 222.222.222.220

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------c;uu:tda de rede, dessa forma é tamb6n argumentavelmentc um protocolo de camada de rede. Em suma, o ARP é provavelmente o melhor considerado como protocolo q ue acena em cheio as fronteiras ent re as camadas de enlace c as camadas de rede- nao se adequando perfeitamente nas si mples pilhas de protocolo que estudamos no Capftulo l. Tais s.'\o as compiC-'!idadcs dos protocolos do mundo real!

Envio de um dalagrama para um nó que esló fora da sub-rede Agora Já de,•e estar claro como o ARP fun ciona quando um nó quer envmr um datagrama a um outro nô na mesma sub-rede. Mas vamos examinar uma situaç-lo mais complicada, em que um nó de uma sub- rede quer em·iar um data grama de camada de rede para um nó qur tstà fora tia sub-rrclr (isto é, passa por um roteador e en tra em o utra sub-rede). Vamos discutir essa questão no contexto da Figura 5. 19. que mostra uma rede simples constituída de dul\s sub-redes intcrconcctadas por um rotc.1dor. Há diversos pontos lnt cress:mtcs a notar na Figura 5.19. Primeiramente. há dois tipos de nós: hospcdriros c roteadores. Cada hos rx:d eiro tem exatamente um endereço lP c um adaptador. Mas. como discutimos no Capitu lo 4. um roteado r tem um endereço IP para cculn uma de suas In terfaces. Panl t-adn lnterra cc de roteador também há um módulo ARP (demro do roteador) c um adaptador. Co mo o roteador da Fagum 5. 19 tem duas interfaces , ele tem do is endereços JP, dois módulos ARP c dois adaptadores. É cla ro que cada adaptador na rede tem seu próprio endereço MAC. Note também que a Sub-rede l tem endereços de rede lll.lll.1lln4 c qu e a Sub-rede 2 tem endereços ele rede 222.222.222124. Assim, todas as interfaces conectadas à Sub-rede !têm o formato 11 l.l ll.l 1l.xxx c todas as interfaces conectadas à Sub-rede 2 têm o rormato 222.222.222.xxx. Agora. ' -amos examinar como um hospedeiro na Sub-rede 1 enviaria um d:nagrama a um hospedeiro na Sub-rede 2. Especificmncntc. suponha que o hospedeiro 11 1. 11 1.111. 111 queam enviar um datagmma IP ao hospedei ro 222.222.222.222. O hospedeiro remetente passa o datagr.una a seu adapt:-~dor. como sempre. Mas ele deve também indacar a seu adaptador um endereço ~C de desuno apropnado. E que endereço ~IA C o adaptador devena usar? Poderia mos :-~rnscar o palpite de que o ende reço MAC apropriado é aquele do ad:-~pt:-~dor do hospc· dei ro 222.222.222.222. a sal>er. i9· B0- 02-C7-S6-2A. Mas esse palpite estaria ermdo! Se o aclapt:-~dor remetente usasse :-~quclc endereço MAC. nenhum dos adaptadores da Sub-rede I se preocup:-~na em passar os datagramas IP para cima. para sua camada de rede, já que o endereço de dcsLino do quadro nao combinaria com o endereço MAC de nen hum adaptador na Sub-rede L O datagrama apenas morreria c iria para o céu dos datagramas.

Se examinannos cuidados.1 mente :1 Figura 5.19, veremos que. para um datagram:l ir de 111.111.1 11.111 até um nó da Sub-red e 2, ele teria de ser e nviado primeirament e à interface de roteador lll . lll . lll . l I O. Assim, o endereço MAC aprop riado para o q uad ro é o endereço do adaptador pam a interface de rotc:tdor 111. 111.111.1 10, :t sabe r, E6-E9-00-17-BB-4B. Co mo o hos pedeiro remetente consegue o endereço MAC para a interface I l l.lll. lll.llO? Usando o ARP. é claro! no logo tenha esse endereço MAC, o adapLador rcmctcmc cria um quadro (comendo o datagmm;:~ endereçado como 222.222.22.22) e o envia par-.t a Sub-rede t. O adaptador do roteador na Sub-rede 1 ve riO<:a que o quadro de l"tUHada de enlac~ está endereçado a ele e, por conseguin te. o p~1ssa (>llnl a camada de rede do roteador. Viva- O d:twgramll IP foí transportado <:om sucesso do hospedeiro de origem para o roteador! Mas não acabamos. Ainda temos de levar o datagrama do ro teador até o destino! O ro teador agora tem de determina r SS·B2·2F·54·1A-OF

74·29·9C·E8·fF·SS

\

IP: 111.111 . 111 .111

IP:222 .222.222 .221

\

tP:111.111 .11t 112

Figura 5.19 Duas sub-redes inter
1A·2H9-C0-06·9B IP:222.222.222.220

IP:222 222.222.222

bow4tto4ic~ A (omodo de enlou e rede$ locais

Capitulo S

343

a lntcrfac<> correta para a qual o datagr.una deve ser rep<~-sado. Como discutimos no Capítulo -4. isso é feito pela consulta a uma tabela de repasse no roteador. A tabela de repasse indica o roteador para o qual o dmagrama deve ser repassado via interface de roteador 222.222.222.220. Essa interface cmão passa o datagra ma a seu adaptador. que o cncapsula em um novo quadro c envia o quadro para a Sub-rede 2. Dessa \'CZ, o endereço MAC de destino do quadro é , na verdade. o endereço MAC do destino final. E de onde o roteador obtém esse endereço MAC de destino? Do ARP. é claro! O ARP para Ethernet está defintdo no RFC 826. Uma boa mtroduç:'o ao ARP ê dada no tutonal do TCP/IP, RFC 1 180. Explornrcmos o ARP mais dctalhadamcnte nos exercícios ao final deste capitulo.

S.S Ethernel A Ethernct praticamente tomou COIIla do mercado de LANs com no. 1a dêcada de 1980 c início da década de l990, ela cnrrentou muilos desafios de outras tecnologias u \N, inchLindo tokcn ri ng, rODl c ATM. Algumas dcss:ts outras tecnologias conscguimm conquistar uma parte elo mcrc.-.1clo ele LANs durante alguns 01nos. Mas, dcsd<> su:t in vcn~"!\o. em meados s para o sucesso da Ethcrnet. Em primeiro lugar, ela foi a prlmcirn LAN de alta velocidade amplamente disseminada. Como foi disponibilizada cedo, os administradores de rede fi
STÇff\ON

1'~\~&~\~E ~

~X

~ ;u·n~Aee

(J..'!J.E.

I

l~"-CE 1

~ ~

co~:wo.L~

figura 5.20 Oprojeto original de Metcoffe levou oo podrõo Ethemet 1OBoseS. Esse podrõo incluía um cabo de intedoce que conectava o odoptodor Ethernet oum tronsceptor exlerno


original us:wa um barramento coaxial para interconectar os nós. r\s topologias de barramcmo da Ethernet persistiram durante toda a década de 1980 e até metade da década de 1990. Com uma topologia de barramento, a Etllernet é uma trans r111ss:1o LAN de broadcast - todos os q uadros transmitidos mo,·em·se para, c s:lo proces.s:tdos por, totlos os adaptadores concct:~dos ao OOfT'.lmento.

nm

da década de 90, a maioria das empresas c universidades já tinha substilurdo suas LANs com instaNo lações Ethernet usando topologia de estrela baseada em um hub (repetidor). Como demonstrado na flgura 5.21 , ness.'lS mstalaçOcs os hospedeiros (c o roteador) estão diretamente conectados a um llllb com um cabo de pares de cobre. Um hub é um dispositivo de camada física que age em bilS indi\•iduais c n:lo em quadros. Quando um bit, representando O ou I, chega em uma interface, o hub simplesmente recria o bit. aumenta a energia c transmite o bit para todas as outras Interfaces. Sendo assim. Ethemet com uma topologia d e estrela baseada em um hub também é uma LAN da broadcast -sempre que um hub recebe um bit d e uma de suas interfaces, ela envia uma cópi3 para tod;ts as o ut rns interfaces. Em particular, se um hub recebe quadros de duas diferentes interfaces ao mesmo tempo. ocorre uma colis.\o c os nós que criaram os quadros precisam rcll'ansmitir. No começo elos anos 2000, Ethernet passou por outra gntnde mud::mça revolucionária. As instalações Etlternct coruinuar:11n n usar a topologia de estrela, mas o hub no núcleo foi substitu fdo por um comutador. Examinaremos o comu tador d:l Ethcrnct com mais atenç:lo depois nesse capilulo. Por enquanto, só mencionare-mos que um cormllaclor ca prova de "colisões" c lambem um am~ntico cont~•d or no modo arm::~zcnnmcnto c cnc.amin hamento; mas difcrcrucmcntc dos roteadores. que operam ate a camada 3, um comutador opera ate a <.'õlrnada 2.

S.S.l

Estruturo do quadro Ethernet

Podemos aprender muito sobre a Ethernet examinando o quadro Ethcrnet que c mostrado na Figura 2.22. Para colocar noss:1 drscussi\o de quadros Ethernet em um conu.•xto t:mgivel, va mos consrclcrar o cnvro de um datagrama IP de um hospedeiro a outro, estando os dois na mesma LAN Ethernet (por exemplo, a I..A."' Etllernet da Figura 5.21). Embora a carga útil do nosso quadro Etllernct seja um diagrama IP. aproveitamos para comentar que um quadro Ethernet uunb~m pode carregar outros pacotes de camada de rede. ~ja o adaptador do remetente, adaptador A, com o endereço MAC AA·AA·AA·AA·AA·AA; SeJa o adaptador receptor, adaptador B, com o endereço MAC 60-BB·BB·BB-BB·BB. O adaptador remetente cncapsula o d:nagrama IP dentro de um quadro Ethcrnct c p.'lss.t o quadro à camada fis ica. O adaptador receptor recebe o quadro da camada fisica, extrai o datagrama IP c o passa para a camada de rede. Nesse contexto , vamos examinar agora os seis primeiros campos do quadro Ethcrnet, como ilustrados na Figura 5.22.

Campo tlc
Dois pares - de fios

trançados Legenda:

de cobre

Hub

Figura 5.21

Topologia em estrelo poro Ethemet. Nós sõo interconectodos com um hub


Preâmbulo

Endereço

Endereço

de destino da origem

A (amado de en lou e rede$ locais

Dados

345

CRC

I

Tipo

Figura 5.22 EsiiUIUio do quodlo Ethemet do campo de dados ~ 46 b)•tes. Isso significa que, se um datagrama IP tiver menos do que 4ó bytes, o campo de dados terá de ser ·recheado' de modo a completar os 46 b)'tes. Qu:mdo se us.1 recheio (stuffing). os dado:. passados :1 camada de rede contem o recheio, bem como um d:uagn1m:1 IP. A camada de rede usa o campo de comprimento do <."abc<,-;1lho do datagram:t IP para remover o recheio. Entlcm;o dr rksrino (6 bytcs). Esse campo contém os endereços MAC do :tdar>tador de destino, BB-BB-BBBB-BB-1.18. Quando o :tdaptador B recebe um quadro Ethcmct cujo endcrc<,-o de destino é ou BB-BB·BBBB-813-BB, ou o endereço de broculwst MAC. ele passa o corllCl'tdo do campo de dados para a cam:tda de rede. Se receber um quadro com qualquer outro endereço MAC, ele o desc:1nar:\. Erult·r-c(o rir jo111c (6 bytcs). Esse campo contém o cndcrcco MAC do adaptador que tm nsmitc o qltadro para a LAN, neste exemplo, AA·t\A·AA· AA·AA·AA. Cn111po rar) o conteúdo do campo de dados. O IP c outros protocolos de camada de rede (por exemplo, Novell IPX ou ApplcTalk) tem seu próprio numero de tipo padronizado. Além disso, o protocolo i\RP (discutido na scç.lo anterior) tem seu próprio numero de tipo, c se o qu:.dro que chegar conter um pacote ARP (por exemplo. tem um campo de llpo 0806 hcxadccimal), o pacote ARP será de multiplexado até o protocola ARP. Note que o campo de tipo é análogo ao campo dt protocolo no d:.tagrama de cam:.da de rede c aos campos de número de porta no segmento de camada de transporte; todos esses campos servem para ligar um protocolo de urna camada a um protocolo da t"amada acima. Vrrljicnçtlo rlr rrdumlc1ncia clclica (CRC) (4 byta). Como discutido na St("ão 5.2.3. a finalidade do ca mpo de CRC é pcm1itir que o adaptador re<:eptor, o adnpt:tdor B, detecte se algum erro roi irnroduddo no quad ro. Prerlml>u/o (8 bytrs). O quadro Ethcmct começa com um <.-ampo de pr~mbulo de 8 b)•tcs. C.1da um dos primeiros 7 bytcs do preâmbulo tem um valor de 10101010; o lihimo bytc é 1010 10 11. Os primeiros 7 bytes do pre;1 mbulo servem para 'despertar' os adapt<1dorcs receptores c sincroniz:tr seus relógios

com o relógio do remetente. Por que os relógios poderiam estar foro de sincronia? Não csquc(,.11 que o adaptador A visa transmitir o quadro a lO Mbps, 100 Mbps ou L Gbps, dependendo do tipo de LAN E1hcrnct. Contudo, como nad:~ é absolu tamcme perfeito, o adaptador A mlo transmitirá o qu:~dro exa· tamentc à mesma vclocidude-alvo; sempre ha"eni alguma var·iação em rehwâo à vcloddtlde· dos primeiros 7 bytes do pre~mbulo. Os dois írltimos biLS do oitavo byte do preâmbulo (os primeiros dois ls consecutivos) alertam o adaptador B de que 'algo importante' esta chegando. A Ethcmcl us:1 tronsmissão em banda-base. isto é. o adaptador envia um sinal digital diretamente ao canal bro

cadeia de bits

o

o

o

,

o

o

Codific~o

binária

Codifi
Figura 5.23

Codific~õo Mon
minar se é um l ou um O. A codiflcaçào Mancheste.r é mais uma opcmçâo de c:Jmada físic:J do que de cam:1da de enlace; contudo, descrevemos CSS.'l OI>Cra~~ao brevemente aqui porque ela muito usada na Elhcmet.

e

Um serviço não confiável não orientado poro conexão Todas :IS tecnologi
S.S.2 CSMA/ CD: o protocolo de acesso múltiplo do Ethernet Quando os nós estão intcrconectados com um hub (c nâo a um comutador de camada de enlace). como demonstrado na Figura 5.2l, a LJ\N Ethernet ê um;~ verdadeira LAN de bronclcast - isto e, quando um adaptador trans mite um quadro, todos os adaptadores na LAN recebem o quadro. Como pode empregar bro
Um adaptador pode começar a transmitir a qualquer tempo. ou seja. não há noção de companimentos de tempo.

2.

Um adaptador nu nca transmite um quadro quando percebe que algum outro adaptador está tm nsmitindo, ou seja, ele usa detecção de ponadora.


A camodo de en lou e redes locais

347

Bob MetcoKe eoEthernet Gluondo ero estudante de doutorado no Universidade Horvord, no início do décodo de 1970, Sob Metcolfe trobolhovo no ARPAnet no M.I.T. Durante seus estudos, ele tornou conhecimento do trobolho de Abromson com o ALOHA e os protocolo$ de acesso oleotório. Apc» ter concluído ~ doutorado e pouco antes de começar um trobolho no PARC do Xerox (Polo Alto Reseorch Center), fez umo visito de três meses o Abromson e seus colegos do Universidode do Hovoi, quando pôde observar, em primeiro mão, o ALOHAnct. No PARC do Xerox, Metcolf conheceu os computadores Alto, que, em muitos c»pectos, foram os predecessores dos computadores pessoais do dócodo de 1980. Ele entendeu o necessidade de montor esses computodorcs em rede de um modo que nõo fosse dispendioso. Assim, munido com o que conhecia sobre ARPAnet, AlOHAnet e protocolos de ocecsso aleatório, Metcolfe, juntamente com seu colega David Soggs, inventou o Ethernel. A Ethernet original de Metcolfe e Soggs executava o 2,94 Mbps e interligava olé 256 hospedeiros o distâncias de oté 1,5 km. Metcolfe e Boggs conseguiram que o maioria dos pesqui$0dores do PARC do Xerox se comunicassem por meio de seus computadores Alto. Entôo, Metcolfe forjou urna olionço entre o Xerox, o Oigilol e o Intel poro estabelecer o Ethernel de 1O Mbps como podrõo do Elhernet, ratificado pelo IEEE. A Xerox nõo dernonslrou muito interesse em comercializar o EJhemet. Em 1979, Metcolle obriu suo próprio empre$0, o 3Com, poro desenvolver e comercializar tecnologia de rede, induindo o tecnologia Ethernel. Em porticulor, o 3Com desenvolveu e comercíolizou cartões de Ethernet no início do década de 1980 poro os então imen$0mente populares PCs do IBM. Metcolfe deixou o 3Com em 1990, quando o empresa tinha dois mil funcionários e 400 milhões de dólores de receito. Até novembro de 2003, o 3Com empregovo mois de 2.900 pessoos no munclo inteiro. 3.

Um adaptador que esta transmitindo aborla sua transmissão quando percebe que algum ouLro adaptador está transmuindo. ou seja. us:t dctecç-Jo de colisão.

4.

Antes de tentar uma retransmissão, um adaptador espera um perfodo de tempo aleatóno que é nsticamcntc pequeno em eomparaçâo com o tempo de transmiss;.lo de um quadro.

~':lracte

Esses mccamsrnos conferem ao CSMA/CD um desempenho muito melhor. em ambiente LAN, do que o do slotted ALO! IA. De f:uo. se o atraso máximo de propaga<'àO entre esta(·Ocs for muilo pequeno. a dicifncia do CSMNCD poderá ncar próxima a 100 por cento. Mas note que o segundo e o terceiro mecanismos que dlamos requerem que cada adaptador Ethcmet seja capaz de ( l) perceber quando algum outro :~daptador esl.li transmitindo c (2) detectar uma colisão enquanto csti\'er transmitindo. Adaptadores Ethcrnct realizam essas duas tarefas medindo os nf"cis de tc11sâo antes c durnntc a transmissão. Cada adaptador executa o protocolo CSMA/CD sem coorclc na~'llo cxplrcha com os o utros adaptadores na Ethcrnct. De lit ro de Ulll adaptador cspccínco, o pmtocolo CSMJVCD runclo rta corno segue: I. 2.

3.

O adaptador obt~m um datagra ma de camad:~ de rede de seu nó p:~i, prepara um quadro Et hernct c o coloca no bufrcr do adaptador. Se o adaptador percebe que o canal está ocioso (is to é, não há nenhuma energia de sinal entrando elo canal para o adaptador durante 96 tempos ele bits), ele começ-.t a Lransmltlr o q u:~dro. ~o adapmdor percebe que o canal está ocupado. espera até perceber que não há nenhuma energia de sinal (mais Q6 tempos de btts) c então começa a transmitir o quadro. Enquamo transmite. o adaptador monitoro a presença de energia de smal vinda de outros adaptadores. ~ o adaptador transmitir o quadro inteiro sem detectar energia de sinal \•Inda de outros adaptadores, ele considerará conclmda a opcmç-.io com o quadro.

4.

~

5.

Após abortar (isto é, transmitir o sinal de reforço), o adaptador en tra em fase d e ba ek off expo nencia l. Es pecificamente, quando está uansmilindo um dado quadro, a pós sofrer a enésima colisão

o adaptador detectar energia de sinal vinda de outros adaptadores enquanto es1:i transmnmdo, ele pamm de transmll•r seu quadro c, em vez dele. tmnsmuirá um sinal de reforço de colrsM de 48 biLS.


em segUJda para esse quadro. o adapt~1dor escolhe um valor para K alt'lltoriamentc de 10,1.2, ...• 2"' - I). onde 111 min(u, LO). O adaptador estão espera K · 5 l 2 tempos de bits c então rctorna à etapa 2.

=

Alguns comentários adicionais sobre o protocolo CSMA/CD se faze m necessários. A llnalidade do sinal de reforço de colis:lo é garantir que todos os outros adaptadores que estejam transmitindo fiquem cientes da colisão. Vamos ''er um exemplo. Suponha que o adaptador A comece a transmnir um quadro c. exatamente antes de o sin:1l de A alcançar o adaptador 8, o :1daptador 8 comece a trnnsmitir. Assim. 8 terá transmitido apcn;\S alguns bits quando abortar sua transmissão. Esses pou<.'OS bits, na verdade, propagar·Se·ãO até A, mas podem não constituir energia sullciente para que A detecte a coliSão. Para garantir que A detecte a coli~lo (de modo que ele também possa abortar), B transmite o sinal de reforço de colisão de 48 brts. Em seguid~1. considere o :~ lgoriuno de backofT exponcnci:1l. A primeira coisa :1 IIOtar ;1qui é que um tempo de bit (isto 4!, o tempo para transmitir um único bit) é muito curto; para uma Ethcrnct ele 10 Mbps. um tempo de bit é O,lmkrossegundo. Agom, vamos consider;u um exemplo. Suponha que um adaptador tente trans mitir um quadro pela primeira vez e que, enquanto está transmitindo. detecte uma colisão. O adaptador então escolhe K = O com probabilidade de 0 ,5 ou escolhe K = l com probabilidt~de de 0,5. Se o udaptador escolher K r= O, imcdi:uamentc pa~s:1 rá p•ua a ct:tpa 2 após transmitir o sinal de reforço ele colisl\o. Se escolher K :a t, ele esperará 51,2 mlcrosscgundos u 11t ~s de voltar à etapa 2. Após uma segunda co Iisilo, K é escolhi elo com igLtal p robahilidade no conjunto {0,1,2,31. Após ul!s colisões, K é escolhido com igual probabilidade no conjunto {0,1,2,3,4 ,5,6,71. Após dez ou mais colisões, K ~esco l hido com igual p robt~bilidade no cOIIJLIIllO {0,1,2, ... ,10231. Assim, o tamanho dos conjuntos dos quais K é escolhido cresce exponencialmente com o m1mero de colisões (:u~ 11 = LO); ~ por essa razão que o algoritmo de baekofT da Ethcrnet é denominado 'algoritmo de backofT exponencial'.

O padr.lo Ethernct impõe límitcs à dist:lncia entre dois nós quaisquer. Esses limites gar:uuem que. se o adt~ptador

A escolher um \'Uior de 1< mais baixo do que escolheram todos os outros adaptadores envolvidos em urna colis;io, de poderá transmiLir seu quadro sem sofrrr uma nova colis:io. Estudaremos essa propriedade mais dctalhadamcnte nos excrcfeios ao llnal deste capilulo.

Por que usar backofT rxponencial? Por qur, por exemplo, não escolher um K entre (0,1,2.3,4 ,5.6.71 após cada colisão? A raz!o é que, quando urn adaptador sofre sua primeira cohs:\o, ele não tem ideia de quantos adaptadores estão envolvidos na colis:\o. Se houver somente um pequeno nt'tmero de adaptadores colidindo, lera sentido escolher K de um pequeno conjunto de \'alores pequenos. Por outro lado. se muitos adaptadores estiverem envolvidos na cohs:lo, terá sentido escolher K dentro de um conjunto de \õllores maiores c mais dispersos (por qui!? ). Aumentando o tamanho do conjunto após cada colisão, o adaptador se ajusta adequadamente a esses diferentes cenários. Mencionamos também que cada vez que um adaptador prepara um novo quadro para transmiss.'lo, de cxe· cuta o algoritmo CSMNCD que acabamos de apresemar. não levando em cotlla nenhuma coli~lo q ue possa ter ocorrido no passado recente. Assi m, é possível que um adaptador com um novo quadro consiga uma transmisSão imediatamente enq uanto vá rios outros aelapmdores estào no estado de backofT c:-.poncndal.

Eficiência da Ethernet Qtmndo apenas um 11ó tem um quadro para e11viar, de pode transmitir à vclocid:1dc total da tccnologia Ethernct (10 Mbps. LOO Mbps ou I Gbps). Contudo. sr n1uítos nós tiverem quadros para transmitir, a velocidade efetiva de LrtHismi~'o elo canal poderá ser muito menor. Definimos a diciência da Ethernet como a fmçào llnal de tempo dumnte a qual os quadros estão sendo transmitidos no canal, sem colisOcs, quando nilum grande m\mero de nós ativos, c cada nó tem um grunele número de quadros a en,•iar. Pura uma aproximação da dicrência da Ethernet, vamos des•gnar como d,.., o tempo máximo para que a energia de sinal se propague entre dois adaptadores quaisquer. Seja cl. ,_ o tempo que leva para transmitir um quadro Ethernet de tllmanho máximo (aproximadamente 1,2 milisscgundo para uma Ethernet de 10 Mbps). Uma derivação da cOci~ncia da Etherncl ultrapassa o escopo deste livro- para mais d etalhes, consulte ILam, 1980) c IBertsekas. 1991 ). Nesta subseção, vamos apenas mencionar a seguinte aproximação:

.• . E"ncrencta

1

= -----

1 + 5d J>rop/dtran'J


A camada de tn lou e

rede~

locais

349

d,...,

Vemos por essa fón nula que, quando se aproxim'l .. de O, a eficiência se aproxima de L Isso está de acordo com a irlluíçJo que temos de que, se o atraso de propagação for O. os nós em cohs:'lo v:'lo abonar imcdiatameme sem desperdiçar o canal. Altm d isso, à medida q ue d,,_ vai ficando muito grande, a efieu~ncia se aprox1ma de L Isso também t intuitivo, porque, quando um quadro captur:t o canal, vai prendê-lo por muito tempo: assim, o canal estará realizando um trabalho produth·o durante a maior pane do tempo.

5.5.3 Tecnologias Ethemet Em nossa diseuss.'o anterio r. nos referimos à Ethcmet como se fosse um protocolo tínico padrão. Mas na ver· dade, a Ethernet ap:~rcce em diferentes versões, com acrônimos um pouco confusos como lOBASE-T, lOBASE-2, l OOBASE-T. I OOOBASE-L.~ c lOGBASE-T. Estas c muil.'lS outras tecnologias Ethern ct fomm padronizadas atrnvts d os anos pelos grupos de tmbalho IEEE 802.3. Apesar de esses acrônimos parecerem confusos, existe uma ordem seguida. A primeira i>arte do acrónimo se refere à velocidade padrão: 10, 100. 1000 ou IOG, por 10 Mcgttbits (por segundo). 100 Meg:tbits e LOGigabits Ethern et, respectivamem e. "BASE. se rdere à banda base da Ethernet, significando que :1 mídia ffsiea só supo rta o tráfego da Eth crnet; quase tod os os padrões 802.3 s.'lo p:~rn banda base. A pane fi11al do acr0 11hno se rckre à mídia risi<.:a em si: :1 Ethernct ~ Htnto tunn camada de c nl:1cc qu:m to uma camada ffs ica que Incluí um cabo co;lxial, fio de cobre c fibra. Gcralmcr11e u m kT n se refere a um cabo de par Ha n(ado de fios de cobre. HistOricamente, uma Ethcrnct ern inicialmente concebida como um segmento de um cabo coaxial. como mostrado na Figum 5.20. Os primeiros padrões l OBASE-2 c 10BASE5 cspecil'lrnvam IOM bps Ethernet sobre dois tipos de cabos CO'..udaís, cada um limitado a um comprimen to d e 200 metros. E~-:tcnsõcs mais longas podiam scr obudas usando um repetidor - um dispositivo de camada - que recebe um s mal 110 lado de cmrada, e regenem o s inal no lado de saída. Um cabo coaxial. como na Figura 5.20, correspondia muito bem a noss:t visão da Ethemet como uma trans miss;Jo broodcast- todos os qu..1d ros transmitidos por urna interface s.' o n~cebidos em outras interfaces. e o protocolo COMA/CO da Ethcmct resolve salisfatonamcnte os vários problemas de acesso. Os nós s.lo s implesmente conectados ao cabo. e voilà. Lemos uma rede local! A Ethernct passou por urna série de etapas de evolução ao longo dos anos, e a Ethcrnet atual c muito diferente do proJeto onginal da topolog•a de barramento que usa"a cabos coaxia1s. Na maiona elas mtalaçõcs de hoje. os nós são conectados a um comutador via segmen tos ponto a ponto feit os de cabos de pares tranç;tdos de n os de cobre ou cabos de fibra ótica, como demonstrado na Figurn 5.2<1.

E

B

Figura 5.24 Umo comodo de enlace interconectondo seis nós


'o melo da d~da de 1990, a Etbernet (oi padronizada em 100 Mbps, 10 vezes mais rápida do que a Ethernet 10 Mbps. O formmo de quad ro e o protocolo Ethernct Mt\C original forom preservados, mas c-.unadas físicas de alta ''clocidadc forom definidas para fios de cobre c Obra. A Figura 5.25 mostra padrocs diferentes nos formato de quadro e protocolo Ethemet MAC comum. A Ethemet de 100 Mpbs ~ limitnda a 100 meLros de dis t:lncia através de um cabo de par trançado, c \'ârios quilômetros atra"és de Obra, o que permite comutações ELiu:rnet em diferentes prédios a serem conectados. A rede G1gabtt Ethcrnct ~ uma cxtensM dos muito bem-sucedidos padrOcs lO Mbps c 100 Mbps. Oferecendo uma velocidade bruta de 1000 Mbps. n Gigabit Ethemct mam~m total compatibilidade com a imensa base instalada de equipamentos Ethernct. t\ Gigabit Ethernct apresen ta o seguinte padr.'o de funcionamento: Usa o formato-padrão do quad ro Etht>mct (Figura 5.22) e f compatrvcl com as tecnologias lOBascT c IOOBascT. Isso pem1ile fácil integração da Gigabit Ethernet com a l.xlsc Instalada de equipamentos Ethemel. Permite enlaces ponto a porlto. bem como canais bi'O
Aplicaçlo Transporte

Rede

Protocolo MAC e format o de quadro

IIOOBASE-TX 111008ASE-T2 I I IOOBASE·fX I

Enlace

física

1100BASE·T4 11100BASE·SX II IOOBASE·BX I

Figuro S.2S Padrões 100 Mpbs Ethernet umo comodo de enlace comum, diferentes carnudos fisicos.


A camada de en lau e redu lotais

351

5.6 Comutadores de camada de enlace Como demonstrado na Figura 5.26 as lAl" 's Ethcrnet modernas usam uma topologia em estrela, com cada nó conectado a um comutador centraL Ate aqui, temos sido vagos sobre como um comutador trabalha e o que ele faz. A fu nção de um comutador é receber q uadros de camada de enlace c ent.-anunh:\-los para enlaces d e s.·uda; estudaremos essa fun~•lo d e encaminhamento detalhadameme em breve. O comu tador em si é transpa rente até aos nós; ou seja. um nO endere~-a u m quadro a outro nO (em vez de endereçar o q uadro ao comu tador) que alegremente envia o q uad ro à LAN . inconsciente de que um comutador ir:\ recebet o q uadro e encaminhá-lo a outros nós. A velocidade com que os q uadros chegam a q ualquer interface de s.11da do comutador pode tcmporari· amente exceder a capacidade do enlace da daquela interface. Para resoh·er esse p roblema. interfaces de sard as d o comutador 1~111 buffcrs, da mesma fo m1a que uma interface d e saída de um roteador tem buffcrs para da1agramas. Vamos agora observar mais aten ta mcnle o funcionamento de um comumdor.

S.6.1 Repasse e filtragem Filtragem é n capacidade d e um comutador que dete rmina se um q uadro deve ser repassado para a lguma in te rface o u se deve apenas ser d escartado. Repas se é a capacidade de um comutado r q ue d etermina as ime r faces pam as quais um quadro d eve ser dirigido e então dirigir o qu:~ d ro a essas inte rfaces. f ih mgem c repasse po r comutadores são feitos com uma ta bela d e comutação. A tabela de comuta4,.'U0 contém reg istros pa ra alg uns nós da LAN. mas não nec~S.'\riamente pam todos. Um registro de um nó na tabela de comutação contém (1) o endereço l\1AC d o n ó, (2) a im erfacc do comutad o r q ue leva em dircç~lo ao n ó c (3) o ho rá rio em q ue o regist ro para o nó foi colocad o na tabela. Um exe mplo de tabela de comutação pam a LAN d a Figura 5.26 é mostrado na Figura 5.27. Embora essa descrição de repasse de q uadros possa parecer semelh ante à nossa d iscussão de repasse de datagramas no Capit ulo 4. ve remos brevemente q ue hã d i fe ren~-as significativas. Uma d ife rença importa nte é q ue os comutadores e ncam inham pacotes basead os em e ndereços MAC em vez de endereços d e IP. Também \'c remos q ue uma tabela de comutação é mo ntada d e manei ra d ifere nteda momage m de tabelas d e roteamento.

Para Internei externa

- --

Enge nharia elé trica

--<

Servido r de correio

Ciência da computa~.\o

Figuro 5.26 Três Ethernets deportomentois interconectodos comum hub

Engenharia da sistemas


Hori rio

Ende reço

62-FE-F7-11-89-A3 7C-8A-82-a4-91-10

3

9h32 9h36

Figura 5.27 Porte de OOlO tabelo de comutoçôo po10 o Wl do Figuro 5.26 Para entender como funciona a fihragcm c o repasse por commadorcs. suponha que um quadro com endereço de d estino 00-DD-DD-D0-00-DO chegue ao comUiador na mtcrfacc x. O comutador indc;~:a s ua tabela com o endereço MAC 00-00-00-00-00-00. Existem três l'aSOS possfveis: N~o existe entrada na tabela para 00-0D-DO·OD-DD-DO. Nesse <.':lSO, o ~:omutador encaminha antcriorm~n te cópias do quadro para os burfers de saída a todas as intcrfac~s. exceto a interface x. Ott seja, se m1o existe cmrada pam o endereço de destino, o comumdor tran smite o quadro em broaclcast. Existe uma entrada na tabela, associando D0-00-D0-00-DD-DD com u lnLcrracc x. Não existe ucccssidaclc de cncaminh
Aprendizagem automático Um co mmador te m a maravilhosa propriedade (em especial, para o administrador de rede, que quase semp re está sobrecarregado) de monwr suu tabela amomát ica, dinilmica c :mtonomamcnte - se m nenhuma intervenção de um administmdor de rede ou de um protocolo de connguraçào. Em outras palavrns, com utadores são aut odi· datas. Essa capacidade é conscg\tida como scg1tc: 1.

A t:tbela de com utação lnicialmeaue está vazia.

2

Para cada quadro recebido em uma interface, o comutador armazena em sua tabela ( 1) o endereço MAC que está no wm1w tlr rru/crc(o tlc fome do quadro, (2) a interface da qual veio o quadro c (3) o horário corrente. Dess:1 maneira, o comutador regiStra em sua tabela o segmento MAC no qual reside o nó remetente. Se cada nó d.1 LA finalmente e.wiar um quadro, então cada nó será finalmente registrado na tabela.

3.

O comu tador apagará um endereço na tabela se nenhum quadro que tenha :tqucle endereço como endereço de fonte for recebido após um certo pcrfodo de tempo (o tempo de envelhecimento). Desse modo, se um PC for substituído por outro PC (~om um adaptador diferente), o endereço MAC do PC orlgmal acabará sendo expurgado da tabela de romul:lçào.

Vamos examinar a propriedade de aprendizagem automática para a rede da Figura 5.28 e sua tabela de comutação correspondente apresentada na Figura 5.27. Suponha que no horário 9h39 um quadro com endereço


A camada de enlou e redes locais

353

de fonte 01-12-23-34-45-56 venha da interface 2. Suponha tam!Xm que esse endereço não esteja na tabela de comutaç-lo. Ent.M , o comutador anexa um novo registro à tabela, como mostra a Figura 5.28. Continuando com esse mesmo cJCcmplo, suponha ainda que o tempo de envelhecimento para c:ssc comutador seja 60 mmutos c que nenhum quadro com endereço de fome 62-FE-F7-ll-89-A3 chegue ao comutador entre 9h32 e l0h32. Então, no horáno 10h32, o comutador remove esse endereço de sua tabela. Comutadores s
S.6.3 Propriedades de comuto~ ão da ramada de enlace Te ndo descrito :~s operações básicas d:1 comutação da camada de enlace, v;unos considerar su:IS propriedades e funcionalidades. Usando 11 il ustmção de uma LAN na Figura 5.24, podemos identificar di\'ersas vantagens em se usar conmtadorcs, em \'eZ de se usar enlaces broadcast como barramentos Olt hub com topologias de estrela: Elimilwç
Enlaces ltttrrogCncos: Sendo que o comutador isola um enlace do o utro, os dHerentes enlaces na LA~ podem operar em dtfcrentcs velocidades e podem ser executados através de diferentes midias. Na Ftgura 5.24 , por exemplo, A pode ser conectado a 10 Mbps cobre IOOBASE-T, MwiCigenu•nt. In addi tion to providing enhanccd sccurity (scc stdeb.'lr on Focus o n Sccunty). a switch also cases network managcment. For cxample. tf an adapter malfuncuons and cominually sends Ethcrnet framcs (called a jabbcring adapter) , aS'-' itch can detect thc problem anel intcrnally discon nect thc malfunctioning adap ter. With this fc.t tul'e, thc network adminístmtor nccd not get out of bed and drivc back to work in o rdcr to corrcct thc problcm. Similarl)•, a cable cut dlsconnects on l)• th:u node that was us111g thc cut cable to conncct to the switch. In the clays of coaxial cable, many a network managcr spcm hours "walking the line~ (o r more accur.ucl y, ~crawling the Ooor") to find the cable brcak that bro ug ht down Lhe cmire nctwork. As discusscd in Chap ter 9 (Network M:magcmcm), switchcs a lso ga th cr statislics on bandwiclth usage, collision mtes, and tmffic types, anel m:~ke this information avnilable to the network manage r. This information can be used to clebug and correc:t problcms, :~nd to plan how the LAN shoulcl evolve in the futurc. Resc:m:hcrs are cx ploring aclding yet more managcmc nt funct ionali ty imo Ethemc• l..ANs in prototype d cp loymcnts !Casado 2007).

S.6.4 Comutadores versus roteadores Como aprendemos no Capitulo 4 , roteadores são comutadores de paco tes do tipo armaze na-e-repassa que transmitem pacotes usando endereços de camada de red e. Embom um comutador também seja um comutador Endereço 01-12-23-34-45-Só 62-FE-F7-t1-89-A3 K-BA-82-84-91-10

Interface 2 1 3

Figura 5.28 Ocomutador aprende olocolizoçõo do odoptador com endereço OJ.12·23-34-45·56

Hor~rlo

9h39 9h32 9h36


ln;.;l~ e ;.; rn;.;e;.;.t_________________________

de pacotes do ti po armazena-c-repassa, ele é fundamentalmente diferente de um roteador, pois repassa pacotes usando endereços MAC. Enquanto um roteador é um comutador de pacotes de carnad<>s da camada 3. Finalmente, M dois modos direrentes de pronunciar n palavra 'router': 'r úter' ou 'ráutcr·. e as pessoas perdem muito tempo discutindo qual ê a melhor pronúncia (Pcrlman, 19991 . Dado que comutadores e rot~.tdores Lêm seus prós e conLms (como foi resumido 11a Tabela 5.1), quando uma rede institucional (por exemplo, uma rede de um campus unh•crsitário ou uma recle cmpresari;ll) dr,•cria usar cormuadores c quando deveria usar roteadores? Em geral, redes pequenas. com algumas centenas de hospedeiros, tt'm uns poucos Hospedeiro

Hospedeiro

Aplicaçlio Transporte

L..-

Rede Enlace Flsica

Co muta d or

Rot ead or

~

;:-<

Transporte

... (

-

Enlace Fisi
Aplica~

1

Rede Enlace Fisica

Figura S.29 Process.omento de pacotes em comutadores, roteadores e hospedeiros

-

.._

Rede Enlace Flsica

-


Hwbs

lsobnenro de llófego

Tabela S.l

Roteadores

355

(om•tadores

nõo

sim

Roteomento ólimo

A camada de en lou e redes locais

nõo

nõo

nõo

Comparação enlle os corocteristicos típicos de dispositivos de interconexão populoses

segmentos de L.AN. Para essas redes pequenas comutadores ser-lo s.uisratórios, pois localizam o tráfego c aumentam a vaz:lo agregada sem exigir nenhu ma configuraç-Jo de endereços IP. M:IS redes maiores, l'Oill milhares de hospedei ros, lipi<:amentc incluem roteadores na rede (tdém de <'Omutadores). Roteadores fornecem isolamento de tráfego mais robusto. controlam tempestades ele broodccrsc e usam rotas 'mais inteligentes' entre os hospedei ros da rede. Para maiores informações sobre os prós c os contras d:IS redes de comutadores c das redes ele roteadores, assim como informações sobre como a tecnologia de LAN comutada pode ser cste11dida p
5.6.5 Rede Local Virtual (VLANs [Virtual Local Area Network]) Na nossa discussão anterior sobre a Figura 5.26, notamos que as LANs instiLUcionais modernas são frc-

qucntcmcmc configurnctas hicrnrquicamcmc, com cada grupo etc lrnb:dho (dcp;m:uncmo) com sctt próprio comutador de L.AN conectado ao comutador de LA~ de outros grupos via uma hierarquia de comutadores. Enqu:mto tais configurações funcionam bem em um mundo ideal. o mundo real ~ bem diferente. Três desvantagens podem ser idcnt•lkadas na configuração da Figura 5.26: Ft~lta ele •soltmltlllo do trdfcgo: Apesar de a hierarquia localizar o tráfego de grupos dentro de um único comutador, o tráfego broadcast (por exemplo. quadros carregando mensagens ARP e OHCP ou quadros com endereços de desti no que amda não foram apreendidas por um comutador com aprend•zagcm automática) tem que ainda percorrer toda a rede institucional. Limitar o escopo desse tráfego de broadcast aprimora ria o desempenho da L.AN. Talvez mais importante que isso, também seria desejável limitar o tr:!fcgo broadcast da u\N por razões de segurança c privacidade. Por exemplo, se um gntpo contém o time de gcrtncia executiva de uma empresa c outro grupo contém funcionários decepcionados cxccuumdo o analisador de pacote Wircsh:1rk, o gerente de rede pode preferir que o tr:Hego da gcrCnci;~ cxeeuth'<1 não alcance os computadores dos funciomlrios. Esse tipo ele isolamento pode ser substitufdo trocando o conmtaclor central da Figura 5.26 por um roteador. Em breve veremos que esse isolmncnto também pode ser realizado viu uma soluçllo de comutaç:'lo (camada 2).

Uso iHcflclrnlc ele comuttulores. Se em vez de trcs grupos, a ins1ituição tivesse I Ogrupos, os I O comutadores de primeiro nfvcl seriam necessários. Se cacl:1 grupo fosse pequeno. com menos ele 10 pessoas, um comut~tclor de 96 pontos seria sufkicnte para atender a todos, mas esse \Ínko comutador mlo fornece isol:uncnto de tráfego. Gcrrncitmlrnlo de us1rtwios. Se um funcionário se locomovc entre os grupos o cubcamcmo físico de,·c ser mudado para conectar o funcionário a um comutador diferente na Figur.l 5.26. Funcionários pertencentes a dois grupos dificultam o problema. Felizmente. cada uma dessas dificuldades pode ser resol\'ida com um comUJador que suporte uma Rede Lo01l Virtual (VL.ANs). Como o nome ja sugere, um comutador que suporta VL\ Ns permite que diversas redes locaiS virtuais sejam Implementadas mravés de uma única infracstrurura física de uma rede local virtual. Hospedeiros dentro de uma vtAN se comunicam como se eles (c n:lo outrOS hospedeiros) estivessem conectados ao comutador. Em uma vtAN baseada em pontos, as interfaces do comutador são dividid:tS em grupos pelo gerente da rede. Cada grupo consútui uma VL.AN,

bow4tto4ic~ Redes de

cor~pu to dores

e o ln;.;l..;.e;.;rn;.;e;.;.t_________________________

com as imerfaees em cada VL\N fonnando mn domínio de broadcast (por exemplo, o trMcgo de broadcast de uma interface só pode alc:mçar outras interfaces no grupo). A Figura 5.30 mostra um unico comut:~dor com 16 interfaces. As inu:rfaccs de 2 a 8 pertencem a EE VLAN. enquanto as interfaces de Q a 15 pertencem a CS VLAI"l (mu:rfaccs de l c 16 n~o sJo atribmdas). Essa Vl..J\N soluciona todas as dificuldades citad;IS acima- quadros EE c CS VI..J\N s::io isolados uns dos outros, os dois comllladores na Figura 5.26 foram substituídos por um unico comutador, e~ o usuário da interface 8 se JUntar ao Dcpart.'lmcnto CS, o operador da rede simplesmente rcconfigura o :.oftwarc da V1..AN para que a interface 8 seja associada com CS VU\N. Qualquer um poderia imaginar facilmente como o comutador Vl.J\N opera c é configurado - o gerente de rede declara uma interface penenceme a uma dada VU\ (com interfaces mio declaradas pertencentes el VLA 1 padrilo) us;~ndo um software de gerenciamento de comutaç-tlo, uma tabela de interface de mapc:uncrno VL.AN é mantida dentro do comut>1dor: c um hardware de comutação somente entrega qu;~dros entre as interfaces pertencentes à mesma VI..J\ N. Mas isolando as duas VL.ANs, criamos um novo problcm:1! Como o tráfego do Depan:~mcnto EE poclc ser cn· viado para o Departamento CS? Uma maneira de se lidar com isso seria conectnr uma interface de comutaç:\o VI..J\N (exemplo, imcrfncc l na Figura 5.30) a urn rQteador externo, configurando aquela interface para que pcrtcru,;a a ambos ele parlamentos EE c CS Vl.ANs. Nesse caso, apCS:Ir de os Dep:marncntos EE c CS compartilharem um mesmQ roteador físico, a configura~~1o faria parecer que os Departamentos EE é CS u~ m comut.ndores diferentes conecmdos por um rQicador. Um d:uagmma IP, indo do departamento EE para o CS. iria passar primeiramente pela VL\N EE para alcançar o roteador c depois cr encaminhado de voha pelo roteador :umvés d:1 Vl.AN CS até o hospedeiro CS. Felizmente, os fornecedores de comutadores fazem com que as configurações sejam fáceis para o gerente de rede. Eles monwm um disposh1vo ti nieo que contém um comutador Vl.J\ N c um roteador, para que um roteador externo n~o seja necess\rio. Uma li~·tlo de casa ao final do rnpítulo explora esse exemplo mais detalhada mente. Voltando à Figura 5.26, vnmQS supor que em vez de termos um departamento scp:~rado de Engenharia da pane do corpo docente de EE c de CS estcj;lm alojado em um préd1o separado, aonde (é claro!) eles precisariam de acesso à rede, c (é claro!) gostariam de fazer pane do VL.Al' do seu desempenho. A Figura 5.31 mostra um segundo comut:~dor com 8 entradas, onde as entradas do comutador foram dcnnidas como pertencentes a VL.AN EE ou CS. c:onfonne ncccss:irio. Mas como esses dois comutado res seriam intcrconecl
Engenharia El~trica (portas VLAN 2-8)

Figura 5.30 Um único comutodor com duos VlANs configurados

G~ncia

da

Computa~.\o

(portas VlAN 9-15)



357

a.

b.

Figura 5.31

Cone
outro comutador. Mas isso gera mais uma dl\vida: como um comutador ~sabe~ que um quadro que cst:t chegando a uma porta de tronco pertence a uma Vl.A t especifica? O IEEE defimu um fonnato de quadro estendido. 802. 1Q. para quadros atra,·cssando o tTonco VLAN. Como demonstrado na Figura 5.32. o quadro 802.1Q consiste no quadro padr.\o Ethernet com um rótulo de VLAN de quatro bytcs adicionados no cabeçalho que carrega a identidade da VLAN ;\ qual o quadro penencc. O rótulo da VLAN é adicaonado ao quadro pelo comUiador no lado de envio do tronco de VLAN, analisado. c removido pelo comutador no lado de recebimento do tronco. O rótulo d:t VLAN co nsiste prop riamente em um mmpo de 2 bytcs chamado Rótulo de ldentificaç:io de Protocolo ITPID I (com um valor h exadccimal de 81-00 fixo) , um campo de 2 bytes de Co111rolc de lnformaçJo de Rótu lo contendo um t";u npo de identificação de VLAN com 12 bits, c um campo de prioridad e com 3 bi ts similar em propósito ao <.:nmpo TOS do clatagroma IP. Nesta am\lisc, só fizemos uma breve cit.a~:ão sobre \'l.ANs c focamos em VLANS baseadas em portas. Dcverf:tmos mencionar também que as VLANs podem ser d efinidas ele dh•crsas maneiras. Em uma VLAN baseada em Mf\C. o administrador de rede especifica o grupo de end ereços MAC que pertence a cada VLAN; quando um dispositivo é conectado a uma pona. a porta é conectada na VLAN apropriada baseada no endereço MAC do

Tipo Prdmbulo

Endereço do Endere~o do Destinatário Remetente

I

CRC

Dados

,..,

: Prdmbulo

I ...... , ,

Tipo ",

Endereço do Endereço do Destinatário Remetente

Dados

LL

Controle de lnformaçlo de Rótulo Identificador de Protocolo de Rótulo

Figura 5.32

Quodro Ethernet (acima): quadro VIAN 802.1 Q- togged Ethernet

CRC' CRT Re
bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------disposlú,•o . As VlANs também podem ser def'mídas por pro tocolos de camadas de rede (por exemplo, 1Pv4, 1Pv6 ou Appletalk) c o01ros critérios. Veja o padnlo 802.1Q[lEEE802.íq2005l para maiores inronn
S.1 PPP: o protocolo ponto o ponto Grande parte de nossa discus.s:\o sobre protocolos de camada de enlace esteve voltada, até aqui, aos protocolos para cana1s broadcast. Nesta seção. c...:aminaremos um protocolo de camada de dados para enlaces ponto a ponto: o PPP. Como o PPP é o protocolo comumente escolhido para o enlace discado de hospedeiros residenciais, ele é, sem duv1da, um dos protocolos de camada de enlace mais util izados hoje em dia. O outro importnnte protocolo de camada de dados em uso alUahncnte é o protocolo HDLC (high-itl'rl delta link coutrol- con trole de enlace de dados de :1l1o nrvcl); cons ulte (Spmgi ns , 19911 para detalhes sobre o HDLC. Nossa diseussi\o do protocolo PPP, um protocolo mais simples, nos permitirá explorar muitas das mais important es características de um protocolo ponto a ponto de cmnada de enlace. Como o nome indica, o PPP [RFC 1661 ; RFC 21531 é um protocolo de c:mmd;~ de enlace q ue opera sobre um enlace p onto a ponto - um enlace que conecta cliretarneme dois nó~. um em (.':lcltt ex~remidade do enlace. O enlace pomo a pomo sob re o qunl o PPP opera pode ser uma linha telerõnica d1scada serial (por exemplo, uma conexão de modem ele 561(), um cnl.u.."t SONETJSDH, uma conexão X.25 ou um drclti Lo ISDN (lrucgrtlWI Str"Vire digiwl nwvorlt rede digitnl de serviço Integrado). Como observado antes, o PPP se tornou o protO(.'Oio preferido para conectar usuá-rios residenciais :1 seus ISPs por meio de uma conexão discada. Antes de aprcsemannos os detalhes do PPP, é instrutivo examinar as exigtncias originais da l ETF para o projeto do PPP IRFC 15471: Enquaclramrmo do tmcocc. No protocolo PPP de camada de enlace, o remetente de"c ser capaz de pegar um pacote da camada de rede c encapsulá-lo dentro do qundro PPP da camada de enlace de tal modo que o receptor poss.• idcnliric:lr o inrcio c o rim do quadro de camada de enlace c também do pacote da camadn de rede que está dentro do q uad ro. Tr~lll)ps de camada de rede sobre uma tltlka co ncx;lo ponto a po nto. Essa cxlg~ncia signinca que, no mfn imo, o PPP provavelmente necessitará de um c:un1)() de 'tipo de protocolo' ou de algum mecanismo simi lnr para que seu lado receptor possa dcmultiplexar um q~L1clro recebido até o pro tocolo de rumada de I'Cdc <~propriado. MHIIi11los 1Íf10S de enlaces. Além de poder carregar múltiplos protocolos de nfvcl mais alto, o PPP deve também poder operar sobre uma grnndc "aricdadc de tipos d(' enlaces, incluindo enlaces que sào seriais ( transm item um bit por \ICZ em uma d receptor) c sinalizar essa cond1çào de erro à camada de rede. Nrgo;icr(llo do cmlc1 c(o de cmnmla de ,-cdc. O PPP deve fornecer um mccamsmo para que as camadas de rede comunicantcs (por exemplo, IP) aprendam o u conrigurem mutuamente seus endereços de camada

de rede.


A camada de en lau e redu locais

359

Slmplicíclmlr. Além de atender às car.tcterfslicas rclaciouadas, o PPP tem de mender :1 uma série de requi-

adtc:tonais. E. como se tudo isso não bastasse, a exigência mais primordial e nt.1is imponante é a simpltcidadc. O RFC 1547 est:1bclcce que ~a marca de um protocolo pomo a ponto de,•e ser a simplicidade·. Uma ordem reli mente diffeil de ser cumprida, dadas todas as outras ex agências feitas quanto ao projeto do PPP! Mais de 100 RFCs definem atualmente os \'<ÍnOS aspectos desst protocolo 'simples'.

SitOS

Embora possa parecer que tenh:tm sido muitas as e:
Enlncrs r11uiOporuo. O PPP precisa op(rar apenas sobre enlaces qtte t~m um unico remeteme c um t\nico receptor. Outros protocolos de camada de enlace (por exemplo, o HDLC) podem atender a múltiplos receptores (por exemplo, em um ccm1rio semelhante ao da Ethernct) em um enlace. Agora que consideramos as metas de projeto (c as 'não-metas') para o PPP, vamos ver como o projeto do PPP aungc essas metas.

5.7.1

Enquadramento de dados PPP

;\ Figura 5.33 mostra um quadro de dados PPP que utiliza um enquadramento semelhante ao do HDLC I RFC 16621. O quadro PPP contém os seguintes campos: Ca mpo dr flag. Todo quadro PPP começa c termina com um campo de Oag de um b)'tc de valor 0111 111 0.

Cmnpo de erulrre(o. O único valor possível para esse campo é lllll l 11. Cmnr>o de controle. O único \'jlor possível para esse t•am po (: 000000 LI. Como os l'itmpos de endereço c de controle somente podem assumir um v;~lor fixo, é de se pcrgunt:lr, :mtcs de mais nada, por que

foram definidos. A especifi caç:\o PPP IRFC 16621 estabelece que ou1ros ''alorcs •poderfLo ser dcnnidos mais tarde", embora nenhum tenha sido definido até tLgora. Como os campos assumem valores nxos, o f>PP pcrmilc que o remetente simplesmente não envie os bytcs de endereço c de controle, economizando. dessa maneira, 2 bytcs de sobrecarga no quadro J>PP.

1 ou 2

o11 11 11o Flag

1 1 111111 00000011 Endereço

figura 5.33 Formato do quadro de dados PPP

Controle

Protocolo

Comprimento variâvel

2 ou 4

Informação Verificação

o111111 O

'

Flag


P1otocolo. O cmnpo de protocolo diz ao receptor PPP a qual protocolo de l'amada s upe rior penencem os dados encapsulados recebidos (isto é, o conteudo do campo de mformação do quadro PPP). Ao

receber um quadro PPP. o receptor PPP verifica se o quadro e-stá correto c, então, repassa os dados encapsulados ao protocolo apropriado. O RFC 1700 c o RFC 3232 definem os códigos de protocolo de 16 btts usados pelo PPP. São de nosso interesse o protocolo IP (isto é. os dados encapsulados no quad ro PPP em um d:nagrnma IP), que tem um valor hexadecimal de 21, outros protocolos de camada de rede como o ApplcTalk (29) e o DECnet ( 27).

Informaçllo. Esse campo contém o pacote encapsulado (dados) que está sendo enviado por um protocolo de camada superior (por excmplo.IP) pelo enlace PPP. O comprimento máxi mo padrão do campo de informaç:'lo é 1..500 b)•tes, embora isso possa ser mudado quando o enlace é conOgurado pela primeira vez, como discutido a seguir. Soma tlr vr,.iflwçllo. O campo de soma de veriOcaç;lo é usado pt~ra dctec1ar erros de biiS em um pacote transmitido. Ele usa um código de redundância cíclica padr:\o HDLC de 2 ou 4 bytes.

Byte Stuffing i\ntes de encerrarmos nossa discuss:\o sobre o cnquadramcruo PPP. vomos consldemr um problema que surge qu:mdo qtmlqucr protocolo us:t um p:~dr..\o especfnco de bits em um campo de nag para indicar o começo ou o Om do quadro. O que acontece se o padrJ.o do llag ocorre em outro local do pacou~? Por exemplo, o que acontece se o \'lllor do campo de Oag 01111110 aparece no campo de informa~!lo? O receptor "ai detectar incorremmc nte o final do quadro PPP? Uma das maneims de rcsoh•er esse problema seria o PPP proibir que o protocolo de cam:tda superior envias· se dados com o padr.1o de bits do campo de Oag. A exigenda de transparência do PPP. discutida anteriormente, impede essa possibilidade. Uma solu~!lo ahemati\'a, que ~ usada pelo PPP c por muitos outros protocolos. é a técmca conhec1da como bytc stufrmg. O PPP define um bytc de controle especial de escape. O111110 I. Se a scquência do nag OllllllO aparecer em outro lugar do quadro, exceto no campo do Oag, o PPP prcn•der;i aquele exemplar do padrão de nag com o bytc de controle de escape. Em outras palavras, ele 'recheia' (adiciona) com um bytc de controle de escape a sequ~ncia de dados transmitida, antes de 01111110, p:~ra mostrar que o 0 1111110 seguinte não é um ''alor de nag. mas sim dados. Um receptor que vir um 01111110 precedido de um 01111101 removerá. é claro, o byte de controle de escape introduzido para reconstruir os dados originais. De maneirn semelhante, se o próprio padrão do byte de controle de escape aparecer como dados. de também deverá ser precedido por um byte de controle de escape introduzido. Assim, quando o receptor vir um único bytc de controle de escape isolado na corrente de dados, ele saberá que o bytc foi introduzido na corrente de dados. Um par de bytes de controle de escape que ocorrem um :ur.ls do outro slgnil'ica que um exemplar elo b)•te ele controle ele escape aparece nos elaelos originais que estão sendo envi ~dos. A figura 5.3-1 ilustra o b)•te sturfing PPP. (Na re~tlidadc , o PPP tombém rcaliz
t

bS b4 01111110 b2 b1 ppp

b1 b2 011 11110 b4 bS ppp

bS b4 0 1 111110 011 1 1101 b2 bl

Figuro 5.34 Byte stuffing


A (amado de enlou e redes locais

361

que o mitimos aqui para shnpi Lncar). Observamos também q ue o PPP tem um protocolo de controle de enlace (LCP), sendo sua função a de fazer a inicialização, manutençJo c o encerramento de um enlace PPP. O LCP é abordado com maiores detalhes no material online associado a este livro.

S.8 Virtualização de enlace: uma rede como camada de enlace Como este capflulo trata de protocolos de camada de enlace, c dado que est;lmos chegando ao fim do capilu· lo. v:unos reOctir um pouco sobre como c,·oluiu o que entendemos como culace. Começamos este capftulo consi· dcmndo um enlace como um fio físico conectando dois hospedeiros eomunicantcs, como ilustmdo na Figura 5.2. Quando estudamos protocolos de acesso múltiplo (Figura 5.9), vimos que \-.i rl os hospedeiros podiam ser com~cta· dos por um no compart ilhado e que o ·fio' que conec tava os hospedeiros podia ser o espectro de rádio ou qualquer outro meio. Isso nos le vou a considerar o enlace, de um modo um pouco mais abstrato , como um canal, em vez de um no. Quando estudamos LANs Ethcrnct ( Figuras 5 .26·5.31) vimos que, na vcrd:.dc, os meios de interconc.x5o poderiam ser uma infmcstrutura de comutaçào ba.<;tantc complexa. Durante toda essa cvoluçào, entretanto, os hospedeiros semt)l'e manti veram a visão do meio d e conex<\O simplcs meme como Lllll <.-a nal de <.'a mada de enlace conectando dois ou mais hospedeiros. Vimos, por exemplo, que um hosJJedeiro Ethcrnet f>Ode ficar alegremente inconse1eme elo fa to de estar ligad o a O Litros hospedeiros de LAN por um unieo segmen to curto ele LAN (f-igura 5.9) ou por uma LAN comutada geograficamente dispersa (Figu ra 5.26) o u pela VL.I\N (Figura 5.31). Na Seção 5.7 vi mos que o protocolo PPP é frequentemente usado sobre uma conex:'lo de modem entre dois hos· pcdeiros. Nesse caso. o enlace que conecta os dois hospedeiros é, na verdade, a rede de tclefoma- uma rede global d t tclecomuniC'Içõcs logic:uncntc scp:u\'\da, com seus próprios comutadores, cnl,u:es c pilhas de protocolos parn transfcr~ncia c sinaliz<~ção de dados. Entretamo. da perspectiva d:1 c:~mada de rede da Internet, a conexão discada por meio da rede de telefonia é vista como um simples •fio'. Nesse sentido, a Internet virtualiza :1 rede de telefonia. considcmndo-a como uma tecnologia de camada de enlace que provê conectividade de c:~mada de enlace emre dois hospedc•ros da lmemet. Lembre-se de que, quando discm imos redes de sobrcpos1ç:'lo no Capuulo 2, dissemos que, de modo semelhante, essa rede v~ a lntemel como um meio de pro,·er conectividade entre nós sobrepostos. procu· rando se sobrepor à Internet do mesmo modo que a In ternet se sobrepõe à rede de telefonia. 'esta scç:'lo consideraremos redes MPLS (Mulliprotocol J..obd Swltching). Diferentemente da rede de tele· fonia de commação de circuitos, as redes MPL.S, são, de direito, redes de comutação de pacotes por circuitos virtuais. Ehts t~m seus próprios formatos de pacotes c comportamentos de repasse. Assim, de um ponto de "ista pedagógico. é bem coerente discutir MPLS quando estudamos camada de rede ou camada de enlace. Todavia, dn perspectiva da Internet, podemos considerar a MPLS, assim como a rede de telefonia c a Ethcrnel comu tada, como tecnologia d e camada de enlace que serve para intcrconectar dispositivos IP. Assim, consideremos as redes MPL.S ao discu1 irmos a c:tmada de enlace. Redes frame-relay e ATM também podem ser usadas p:ua in terconcctar disposltl"os IP, embora represerucrn uma tecnologia ligeiramente mais antiga (mas a inda disponibilizada), que nao scr-J d iscutida aqu i; se quiser saber mais detalhes consulte o livro, de fnci llcitura, de IGor:tlski, 19Q9 J. Nosso eswdo de MPLS scr-.1 nccessMi:uncnlc breve, pois livros inteiros podem ser escritos (c romrn) sobre essas redes. Rccomend;unos IDavíe, 20001 pam detalhes sobre MPI..S. Aqui, ro..:ali Z
(omutoçõo de Rótulos Multiprotocolo (MPLS) A Comuta~lo de Rótulos Multi protocolo (MPLS) evoluiu dos im\meros esforços realizados pela indústria de meados ao final da década de 1990 para melhorar a velocidade de repasse de roteadores IP adotando um conceito funda mental do mundo das redes de circuitos virtuais: um rótulo de tamanho f1xo. O objetivo n:'lo era abandonar a lnfraestnuum de repasse de daragramas IP com base no desti no em fa,ror de rótulos de tamanho nxo e circuitos "irtuais. mas aumentá-la rotulando d:uagramas seletivamente c pcmtitindo que roteadores repass.'\SSCm datagl"ll· mas com base em rótulos de tamanho flxo (em vez de endereços de destino IP), quando possível. O importante é que essas técnicas trabalhavam de mãos dadas com o IP, usando endereçamento e roteamen to lP. A lETF reuni u

bow4tto4ic~ Redes de com putod ores e o Inler.;;n.;;, e;.. l -----------------------esses esforços no protocolo MPLS (RFC 3031, RFC 30321 misturando efetivamente técniC'JS de circuitos virtuais em uma rede de datagrnmas com roteadores. Vamos começar nosso estudo do MPLS considerando o formato de um quadro de camada de enlace que é manipulado por um roteador habilitado para MPLS. A Figur.t 5.35 mostra que um quadro de l
No exemplo da Figuro 5.36. os roteadores Rl a R4 ~o habilitados pam MPL.S. R5 e R6 s:lo roteadores IP padrão. RI anunciou a R2 c R3 que ele ( Rl) pode rotear para o destino A. c que um quadro recebido com rótulo MPLS 6 sem rcpass.1do ao destino A. O roteado r R3 anunciou ao roteador Rof que ele (Rof) pode rotear para os destinos J\ c O c que os quadros que estão chegando c que portam os rótulos MPLS lO c 12, respectivamente, serão comutados na direção desses destinos. O roteador R2 também anunciou ao roteador R4 que ele (R2) pode alcançar o destino t\ c que um quadro recebido portando o rótulo MPI.S 8 sem comutado na dirC\o)O de A. 'otc que o roteador R4 agora est:\ na mtcrcssamc posição de ter clois caminhos MPI..S paro chegar até A: v1a a intcrracc O com rótulo de saída MPLS 10 c via a interface 1 com um rótulo MPLS 8 . O quadro geral apresentado na Figura 5.36 mostro que o modo como Rof, RS, A e O estão conectados em conjunto via uma infroesmuura :O..IPLS (roteadores habilitados a MPLS R1 , R2, R3 e R4) é praticamente o mesmo modo pelo qual uma LA• comutada ou uma rede ATM podem conectar dispositivos IP entre si. E, do mesmo modo que uma LAN comutada ou uma rede ATM, os roteadores Rl a R4 habilitados para ~iPLS Jc1zcm 1sso sem jcmwi~ toem o cabeçalho IP de um pcrcolc. Nessa discussdo, ndo espccHlcamos o prowcolo especifico mílizado para distribuir rómlos entre ro teadores habilitados pam MPLS, pois os dcwlhcs dessa sinalização estariam muito além do escopo deste livro. Observamos, entretanto, que o grupo de trabalho da IETf' para o MPLS especificou no RFC 3-168 que uma extensão do pro tocolo RSVP (q ue estudaremos no Capitulo 7). conhecido como RSVl,·TE (RFC 32091. será o foco de scus csrorc;os para a sinalizaçt\o MPLS. Assim, aconselhamos o leitor interessado a consultar o RFC 3209. Até aqui, a enrasc ele nossa discussão sobre o MPLS tem sido o rmo de que esse protocolo executa comutação com base em rótulos. sem prccis.-r considerar o endereço I f' de um pacote. As verdadeiras vamagcns do MPLS e a roz:\o do atual interesse por ele, contudo. não estão nos aumentos substanciats nas velocidades de comutação, mas nas novas C:IJXIcidadcs de gerenciamento de tr-.ifcgo que o MPLS proporciona. Como observamos amerionncmc. Ca~lhoPPP

ou Ethernet

Cabeçalho MPLS Ca~lho IP Restante do quadro de camada de enlace

Rótulo

Figura 5.35

Experimental S TEFTL

Cobe~olho MPLS: localizado entre os cobe1olhos de camada de enlace e camada de rede


interface rótulo rótulo de de de destino entrada salda saída 10 12

A

o

o o

8

A

1

....._,_

A camada de en lau e redu locais

interface rótulo rótulo de de de des1inc salda entrada saída

10 12

R2

6

o

o

_,..

R1

rótulo rótu lo interface de de destino de entrada saida salda

8

1

A

6 9

A

o

interface rótulo rót ulo de de de destino ent rada S
6

-

A

o

Figura 5.36 Repasse melhorado
S. 9 Um dia na vida de uma solicitação de pógino Web Agom que já cobrimos :1 camada de enlace neste capitulo, c da rede, de transporte c a mmada de aplicação em capitülos antenorcs. nosso jornada pd;~ pilha de protocolos está completa! No começo do livro (Seç:lo l.l). nós escrevemos que ·grande parte deste livro trata de protocolos de redes de computndores: e nos primeiros cinco capítulos vimos que realmente isso é verdade. Ames de nos di rigirmos aos tópicos dos próximos caphulos da segunda par! e deste livro, gostana mos de finali zar nossa jornada pela pilha de protocolos considerando uma visão integrada e holística dos protocolos que vimos até agora. Uma forma de termos essa vis.1o geral é identificarmos os


\'árlos (,·:trios!) protocolos envolvidos na saús[açào de simples pedidos, como fazer o download de uma página web. A Figura 5.37 ilustra a imagem que queremos passar: um estudante. Sob. coneeta seu laptop 110 eommador Ethernet da sua escola e faz o do" nload de uma página wcb (digamos q ue é a págma princ1pal de www.google.com). Como já s.1 bcmos, existe muito mais sob a superffcie do que se imagina. para realizar est:~ sohcitaçào aparentemente simples. O laborató rio Wireshark examina cenários de comunicaç-lo mais dctalh:~d:~mentc no final deste capitulo. contendo vários pacotes envolvidos em situações parecidas.

Começando: DHCP, UDP, IP e Ethernet Suponha que Bob liga seu laptop e o eonecta através de um cabo Ethcrnet ao comULador Ethemet da escola, que por sua vez é conectado ao roteador da escola, co mo demonstrndo na Figura 5.37. O roteador da escola é conectado a um ISP, que neste exemplo é corncasl.net. Neste exemplo. a co mc<1st.net fornece o serviço 0!\S para :1 escola; dessa rom1a, o servidor DNS se localiza em uma rede da comcast em vez de se localizar na rede da escola. Va mos su1:>0r que servidor DHCP es tá sendo executado dentro do roteador, como norm<1lmcmc acomcce. Quando Bob conecta seu l:~ptop i\ rede pela primeira vez, ele não consegue fazer nada ( por exemplo. <:arregar uma pi1gina na Wcb) sem um endereço IP. Assim, a primeira açào rclncionadn à I'Cdc 1omada pelo Japtop é exccular o protocolo DHCP pam obter um endereço IP, bem como ou tras informaçOcs do scrv1dor DHCP local: 1.

O sistema opcracionol do laptop de Sob crhl uma mensagem OHCP de soliciw~·ào (Sec;•'o 4.4.2) c coloca ess.1 men!klgcm dentro do segmento UDP (Se~'áo 3.3) com a porta de desti no 67 (se rvidor OHCP) c porta de origem 68 (clícme DHCP). O segmento é cnuio colocado dentro de um datagr:11na IJ> (Scç-Z1o 4.41 ) com um endereço de destino IP transmitido (255.255.255.255) c um endereço de origem IP de 0.0.0.0 , já que o laptop do Bob não tinh<1
2.

O datngrama IP contendo uma mensagem de solicitação DHCP é colocado dentro de um quadro I::thernct (Sc~·M 5.51). O quadro Ethernet tem endereços de destino MAC FF:Ff:FF:FF:FF:FF para que o quadro sejn transmitido a todos os dispositivos conectados ao comutador onde se espera que se inclua um scrv1dor DIICP o quadro de origem do endereço MAC é do laptop do Bob. 00: 16:03:23:67:8A.

3.

O quadro broadcast E1hernet contendo a solicitação DHCP é o primeiro quadro a ser enviado pelo laptop de Bob para o comutador Ethcrnet. O comutador transmltc o de salda, incluindo n porta conectada ao ro1cador.

qu:~dro da

Comcast.net Servidor DNS

Rede da escola

00: 16:03:23:68:8A 68.85.2.101

68.80.2.0124

68.87.71.226

Rede da

comcast

68.80.0.0/13

www.google.com Sefvidor da Web

64.233.169. 1os

Figura 5.37

entrnda parn todas as portas


A (amado de enlou e rede$ locais

4.

O roteador recebe o quadro Ethcrnet transmitido, que contém a solicitação OHCP na sua interface com endereço MAC 00:22:6B:45:1F:lB, c o datagrama IP é extmfdo do quadro Et hern eL O rndcreço de destino IP tra nsmitido indica que este datagrama IP d e\'eria ser processado por protocolos de camadas mais elev;1das em seu nó. paro~ que a carga útil (um segmento UDP) seja dessa forma demultiplexada (Scçilo 3.2) :u é o UDP. c a mensagem de solic:itaç-.lo ex trarda do segmento UDP. Agora o servidor DHCP tem a mensagem de solicita~-;lo DHCP.

5.

Suponhamos q ue o scr\'idor OHCP que esteja sendo exec utado dentro de um roteador possa alocar o endereço lP no bloco ClDR (Scç-Jo 4.4.1) 68.85.1.011-l. Neste exemplo, todos os endereços IP us:tdos dentro da escola cst;\o dentro do bloco de endereços da Comcas1. Vamos supor que o scrv1dor DHCP designe o endereço 68.85.2.101 ao laptop do Bob. O serv1dor DIICP cria uma mens;~gcm OHCP ACK (Scç:\o 4.4.2) contendo um endereço IP, assim como o endereço IP do servidor DNS (68.87.7L.226), o endereço IP para o roteador de borda default (68.85.2.1), c o bloco de sub-rede (68.85 .2.0124) (equi\•alcnte à máscam de rede). A mensagem DHCP é colocada dcmro de um segmen to UDP, o q ual é colocado deturo de um dat:~gmma IP. o qual é colocado dentro de um quadro Ethcrnet. O qu:~dro Erhernet tem o endereço MAC de origem da interface d o rot eador na rede doméstica (00.22.68.45. 1F.lB) e um e ndereço MAC de destino do laptop d o Bob (00. 16.0 3.23.68.81\).

6.

Utn:t vez que o comutador realiza a apre nd iz;tgcm auto m:l tic:~ c que reçcbc prcvhllncntc u m qu;tdro do laprop de Doi> (que contém a solicitacão DHCP), o comutador sa be como crK;lminh;lr um quó\dro endereçado :1 00.16. D3.23.68.8A. somente paro a porta de salda que leva :~o laptop do Bob.

7.

0 laprop do Dob rec:ebc o quadro Ethernet que contém o Df-I CP ACK, e:
Ainda começando: DNS, ARP Q uando Bob digira a URL para www.googlc.com em seu na\'cgador wcb. ele inicia um:~ longa cadeia de eventos que nn:~lmcntc res ulta rão na exibição da página principal do Google no seu navegador web. O navegador wcb do Bob inicia o processo ao criar um sockct TCP (Seç-.lo 2. 7) que ser:\ usado para enviar uma requisiçilo HTTP (Scçilo 2.2) para www.googlc.com. Para criar o sockct, o laptop do Bob precisam saber o cndercço IP de www.googlc.com. Aprende mos na Scç;\o 2.5, que o protocolo DNS é usado para forn ecer scrvi\os de traduções d e nomes p:m1 endereço IP. 8. O sistema opcracíonal do laptop do Dob cria cnu\o um:t mensagem de consulta DNS (Seção 2.5.3), colocando a cadeia de caracteres www.googlc.com no cam1>o de i>Crgunta ela mensagem DNS. Essa mensagem DNS é cnuio colocada dentro de um segmento UDP, com :1 porta de des tino 53 (servido r O S). O segmento UDP é então colocado demro de um daragrama IP com um endereço de destino lP 68.87.7 1.226 (o endcrc'-'<> do servidor ONS retomada pelo DHCP ACK na ct:~pa 5) c um endereço d e origem IP 68.85.2. 101. 9. O laptOf> de Bob coloca cntâo um d:~tagram:~ contendo a mensagem de consulta D~S em um quadro Ethcrnct. Este quadro será cn,·iado {endereçado, na camada de enlace) ao roteador de borda da rede da escola de Bob. No entan to, apesar ele o laptop de Bob conhecer o endereço IP do ro teador de borda da rede da escola (68.85.2.1), ''ia a mensagem DHCP ACK na etapa 5 anttrior, ele nilo sabe o endereço MAC do roteador de borda. Para q ue o laptop do Bob obtenha o endereço MAC do roteador de borda. ele precisam usar o protocolo ARP (Seção 5.4.2). 10. O laptop de Bob cria uma mensagem de consulta 1\RP direcionada ao endereço IP 68.85.2.1 (a porta padr.lo), coloca a mensagem ARP dentro do q uad ro Ethernet p:~ra ser tmnsmil1do em broadcast ao endereço de destino (FF:FF:FF:FF:FF:FF) e envia o quadro Ethernet ao comutador, que enr:rega o quadro a todos dispositivos, incluindo o roteador de borda.


11. O roteador de borda recebe wn quadro contendo a mensagem de consulta ARP na Interface da rede da escola, c encontra que o endereço alvo lP 68.85.2.1 na mensagem ARP é compauvcl com o endereço IP de sua mtcface. Então, o roteador de borda prepara urna resposta ARP, mdicando que o seu endereço MAC 00:22:6B:45: lF: lB corresponde ao endereço lP 68.85.2. 1. Ele coloca a mensagem de resposta ARP em um quadro Ethemet, com o endereço de destino 00:16:D3:23:68:8t\ (laptop do Bob) e envia o quadro ao comutador. que entrega o quadro ao laptop de Bob. 12. O laptop d e Bob recebe o quadro que contém a mcr\5.'\gem de resposta ARP c extrai o endereço MAC do rotc.-dor de borda (00:22:6B:45:lf:lB) d:t mc~tgcm de resposta ARP. 13. O laptop de Sob pode agora (11 nalmente!) endere\-ar o quadro Ethcrnet contendo a mensagem de consulta D S ao endereço MAC do roteador de borda. Observe que o datagrama nesse quadro tem o endereço de destino IP 68.87.7l.226 (servidor DNS) . enquan to o quadro tem o endereço d e destino 00:22:68:-15: 1F: I B (roteador de borda). O laptop de Bob envia esse quadro ao comutador, que entrega o qu:tdro :-~o rotc;1dor de borda.

Ainda começando: roteamento de introdomínio ao servidor DNS 14. O rotettdor de borda recebe o quadro c extrai o datl\grama IP que corul'm a consult:l ONS. O roteador procura o cudcre(o de deslino desse dat:\grama (68.87.7 1.226) c determina de sua t:!be la de cnc:aminhamcnto que o datagrnma deve ser cnvi:~.do ao rotCõ\dOr da extremidade esquerda na rede Comcast. como m1 Ftgura 5.37. O datagr:una IP ~colocado dentro de um quadro de uma cam:tdll de enlace :~propriado de acordo com o enlace conectando o roteador da cscol:t ao roteador Comcas1 da extremidade esquerda e o c1uadro ~enviado atmv~ desse enlace. 15. O roteador da extremidade esquerda na rede Comcast. recebe o quadro, extrai o d;nagrama IP, examina o endereço de destino do datagrama (68.87.71.226) c dctennma a Hllcrfacc de sarda pela qual irn enviar o data· gmma ao servidor DNS de sua tabela de encaminhamento, que foi preenchida pelo protocolo lntradomlnio da Comcast (como RIP, OSPF ou 15-15, Seç:\o 4.6), assim como o protocolo lntradommio da Internet, BGP. 16.

Fin:~.hncntc, o dat:~gmma LP contendo a consulta D S chcg.'\ ao servidor DNS. O servidor DNS extrai a mens.,gem de consulta Dl"S, procura o nome em , ..·ww.google.com na sua base de dados DNS (Seção 2.5). c cncontrn o rcg1stro da fonte DNS que contém o endereço IP (64.233. 169.105) para" ww.googlc.com (supondo-se que está em cache no servidor DNS) . Lembre-se que este dado em cache fo1 onginado no servidor DNS com autoridade (Sceào 2.5.2) P•lra googlccom. O servidor DNS fonna urna mensagem DNS de resposta contendo o nm~mcnto do endereço IP p:trn o nome fonte c o coloca a mensagem D1 S de res posta em Ltlll segmento UD P, c o segmento dentro do dat:~.grnma IP endereçado ao laptop do Bob (68.85.2.101). Esse d:uagrama será cnc.'\minhado de ,·olt:l à rede ConK'3Sl ao roteador da escola e de 1:1 :10 ktptop do llob, via o comutador ELhernet.

17. O laptop do Bob cxtmi o endereço IP do servidor www.google.com da mensagem DNS . .Finalmeulc, depois de muito tmbalho, o laptop do 13ob está pronto para contatar o servi elo r wwll'.googlc.com!

Interação cliente-servidor Web: TCP e HTIP 18. Agorn que o l:tptop de Bob tem o endereço lP de www.googlc.com, ele cst:\ pronto paro criar um sockct TCP (Scç;\o 2.7), que será us.'\d:~ p.,rn enviar uma mensagem I ITTP GET (Seção 2.2.3) p:1ra www.google.com. Qu:tndo Bob cria um sockct TCP, o TCP do laptop do Bob precisa primeiro cxccut.'lr uma aprcsentaÇ":Io de trts vias (Seção 3.5.6) com o TCP em www.google.com. Então, o laptop de Bob primeiro cria um scgmelllo TCP SYN com a porut de destino 80 (para HTIP), coloca o segmento TCP dentro de um datagrnma IP. com o endereço de destino IP 64.233.169. 105 ( www.googlc.com). colcx-a o datagrnm


20. Finalmcmc, o dmagrama contendo o TCP SYN chega em W\\w.googlc.com. A mensagem TCP SYN é cxtmfda do dmagrama c demuhiplexada ao socket associado à porta 80. Um sockct de conexão (Seção 2.7) é criado para a conexão TCP entre o servido r HTIP do Googlr r o laptop dr Bob. Um scgmento TCP SYNACK (Seç.lo 3.5.6) é gerado, colocado dentro de uma datagrama endereçado :~o h•ptop de Bob,

c rinalmente colocado dentro de um quadro de camada de enlace apropriado ao enlace conectando \vww.googlc.com ao seu roteador de primeiro s.·dto. 21. O datagrnma que contém o segmento TCP SYNACK é encammhado através das redes do Google, Comcast e da escola, Clnalmente chegando no cartão Ethcrnet no computador de Bob. O d:uagrnma é

demuhiplcxado dentro do sistcmll operacional c entregue ao sockct TCP cri;~do na cta p.1 18, que entra em estado de conexão. 22. Agora, com o socket dentro do laptop de Bob (finalmente!), pronto pra enviar bytes a www.google.com, o navegador de Bob cria uma mcns:~gcm HTIP GET (Scç:\o 2.2.3) contendo a \JRL a ser procurada. A mensagem HTTP GET é envi:~da ao socket. com a mcns;~gcm GET se tornando a carga lltil do segmento TCP. O segmento TCP é colocado em um datagrama c cn"lado c entregue em www.google.com, como nas ctap;~s 18·20 acima. 23. O ser"idor IITTJ> www.google.corn lc :\ mens.1gcm HTTP GET do socket TCP, cria uma resposta HTTP (Scç-Jo 2.2), coloca o conteúdo da página web requisitada no coq)o da mensagem de resposta HTTP. c envia a mensagem pelo sockcLTCP.

24. O datagra ma contendo a mc1ts.1gem de resposta HTTP é encaminhada ntrav~ das redes do Googlc. da Come-1St c da escola c chcg;I ao laptop de Bob. O programa do navcg:1dor de Bob le a resposta IrnP do sockct, extrai o h uni da jXIgina web do corpo da resposta HTfP, c fl nalmclllc (fln:Jimcntc!} mostra a jXIgina web! Nossa representação acima vimos mullo do rundamento das redes de com uni ca~iio! Se você entendeu a maior parte da rcprescntacão acima, então voe~ também viu muito do rund:uncnto desde que leu a Scç-lo 1.1. onde escrevemos ··grande parte deste livro trata de protocolos de redes de computadores: c voce pode ter se perguntado o que na verdade era um protocolo! Por mais detalhado que o exemplo acima possa parecer, nós omitidos um numero de protocolos possíveis (por exemplo, NAT executado no roteador de borda da escola, acesso sem fio ;\ rede da escola, protocolos de segurança para acessar a rede da escola. ou scgmentos ou dat<~gramas codiricados). c considerações (cache da wcb. hierarquia DNS) que poderíamos encontrar na internet pública. Estudaremos a maioria desses tópicos na scgunda parte deste li,•ro. Finalmente, observamos que nosso exemplo acima era integrado c holfstico, mas também muito resumido de muitos protocolos que estudamos na priml'ira parte deste Ji,•ro. Este exemplo é mais rocado nos aspectos de •como·, c ni\o no · porquê". Para uma vis;'o mais ampl:~ c rcOectiva dos protocolos de rede em gemi, veja IClark, 1988, RFC 52 18) .

5.10 Resumo Neste capitulo, cxamin:m1os a camada de enlace -sctt~ serviços, os princípios subjacentes à sua operação c ''ários proLocolos especlflcos Importantes que usam esses prindpios na implcmemaç-Jo dos serviços da c:-un:1da de enlace. Vimos que o serviço b.'tsico da camada de enlace é mover um datagram:\ de camada de rede de um nó (roteador ou hospedeiro) até um nó adjacente. Vimos também que todos os protocolos de canmcla de enlace operam encapsulando um datagrama de camada de rede dentro ele um quadro de c-;uu:1da de enlace :mtes de transmitir o quadro pelo enlace que \':li att o nó adjacente. Altm dessa run'-'o comum de enquadramento, contudo, aprendem~ que diferentes protocolos de camada de enlace oferecem scr"iços muito dtfcrcntcs de acesso ao enlace. de entrega (conrlabilidadc, detecção/correção de erros), de controle de Ouxo c de transmissão (por exemplo, scrviços full-tluplrx vrrsu~ ha/f-dup/r;<). Essas diferenças são devidas, em parte, à vasta \':lriedadc de lipos de enlaces sobre os quais os protocolos de enlace de,•cm operar. Um enlace pomo a ponto simples tem um unico remetente e um úntco receptor comumcando-se por um único 'fio'. Um enlace de acesso muluplo é compartilhado por muitos remetentes e receptores; consequentemente, o protocolo de camada de enlace para um canal de acesso múltiplo

bow4tto4ic~ Redes de co11pu todores e o ln;.;l..;.e;.;rn;.;e;.;.t_________________________

tem um protocolo (seu protocolo de acesso mtiltiplo) para coordenar o acesso ao enlace. Nos casos de ATM e MPLS, o ·enlace· que conccta dois nós adjacentes (por exemplo, dois ro teadores IP que s:lo adj:~ccntes em sem ido IP- ou seja, solo rotc:~dores IP do próximo salto na dircç-Jo do destino) pode, 11:1 rc
Exercíciosde fixação Capítulo 5 Queslões de revisõo ~ões S.l l.

o S.2

Considere a analogia de transpone na Seç-.\o 5.1.1. Se o passageiro é análogo ao datagrama, o que é análogo ao quadro da camada de enlace?

2.

3.

Se todos os enlaces da Internet fornecessem scr\'iço confiá,•d de entrega. o ser' iço confia,·el de em rega TCP seria redundante? justiOque sua respos1a. Quais alguns possíveis serviços que um protocolo de camada de enlace pode oferecer à camada de rede.

bow4tto4ic~ A camada de tn loce e redu locais

Capitulo )

Quais desses serviços de camada de enlace 1cm scrviÇIIS corrcsp<~ndcnles no IP? E no TCP? Se!ÕO 5.3 ...

Sup<~nha

que dois n1\s comecem a transmmr ao mc:.mo tempo um pacote de comprimento L p<~r um canal broculal)l de velocidade R. Denote o atraso de propagac!lo cn1re os dois nús como l lavcrá uma colis!!o se 1 < UR? Por quH Na Si:ç!lo 5.3, relacionamos quatro caracterfslicas desej;h·eis de um canal lml
,...,

5.

6.

7.

t,..,..

é enviada dentro de um quadro com um endereço

MAC de destino espectfico? 11. Na rede da Figura 5 19. o roteador tem dois módulos ARI'. cada um com sua propria tabela ARP. t: possf· vel que o mesmo cndcrcco MAC apareça em .unhas as tabelas?

Seção S.S 12. Compare as estruturas de quaclm das redes Ethcmet IOB.1seT. IOOBascT c Gigabit Ethernct. Quais as difc· rcnças cn1re elas? 13. Suponha <1ue um adaptador de lO Mhps cmoie para dentro de um canal uma cadeia innnlla de I s uSllndo a codiricaç:lo 1\lanchcstcr. Quant:1s transiçtkS p<~r segundo ter:\ o sinal que emerge do adaptador? 14. Em CSMNCD. :1pôs a escolha K = 4? O resultado K "' 4 corrcsponde a um atraso de quantos sc~undos em uma rede Et hcrncr de lO Mhps?

.5.4

Seção 5.6

8.

15. Considere a F1gum 5.26. Qu•mtas sub·rt.'des existem, em rel:tC".iO ao acesso da Scç;Io 4.4?

Que tamanho 1em o espaço de endereço 11.1AC? E o cspa· co de endereço 11"\'4? E o espaço de endereço IP..-6?

Sup<~nha que ("::da um dos nós A. B c C esteja ligado a mesma LAN brooclctiSI (por meio de seus adaptado· res). Se A enviar milhares de datagramas IP a 8 com quadro de cncapsulamen1o endereçado ao endereço MAC de B, o adap tador de C processará esses quadros? Se process.1r. ele passará os datagramas IP desses quadros para C (isto é, para o nó pai do adapta· dor)? O que mudaria em suas resp<~s tas se A Cn\'iassc quadros com o endereço MAC de broadcasr? 10. Por que uma pesquis.1 ARI' é e1wiada dentTo de um quGdro IJm(Jdra
9.

Seção S.7 16. Qual o numero má."mo de VIJ\ 's que 1>0dem ser configuradas em um comutadllr que sup<~rta o pro· tocolo 802.Ql? l'or que? 17. Imagine que N comutadores que suportam K gru· p()S de VLAN :,cr.lo conectados v1a um protocolo de entroncamento. Quantas portas serao nccessá· rias para conectar os comlll~dores? Justifique sua rcspos1a.

Problemas 1.

2.

Suponha que o conteúdo de inforrnaç:'\tl de um pacote seja o padn\u de hits 1110 1011 1001 I IOI c que um esquema de parich1dc par c;tcj:1 scndt> usado. Qual seria o valor do campo de soma de vcrificac:\o parJ o caso de um esquema de paridade bidimensional? Sua resposta deve ser tnl que seja usado um campo de soma de \'Criflcac;ao de comprimento mínimo. Dê um exemplo (que não seja o da Figura 5.6) mostrando que vcrificactks de paridade bidimensíonal podem corrigir c detectar um erro de bit único. D~ um outro exemplo mostrando um erro de bit duplo que pode ser detectado, mas não corrigido.

3.

Suponha que a ptlrç:hl de informac:\o de um pacote (D da Figura 5.-1) contenha 10 bytcs consistindo na rcprescmac;do bmána ASCII :.em sinal de um:1 cadeia de caracteres da "Camada de Enlace". Calcule a soma de ''eriflc:~ç:\o da Internet J>Ma esses dados.

4.

Considere o problema amcrior. mas em \'CZ de comer tlS nu meros hin;lnos do Oao 9. sup<~nha que esses lO bytcs contenham: a. A reprcscmac;!lo binária dos números de I a IO_ b. A representação ASCII das letras A a J (letras maiúsculas).

bow4tto4ic~ Redes de compu tadores e o lnte;.;ro;.;e;.;.t_________________________

c. A reprcsentaç;\o ASCII das letras a a j ( letras mmusculas) C:llculc a soma de verificação da Internet para esses dados.

S.

Considere o gerador de 7 hiiS C·IOOII e suponha que D tenha o valor de 1010101010 Qual c o valor de R?

6.

Considere o problema acima. mas suponha que D tenha o valor de:

a. 1001000101 b. 1010001111

c. 0101010101

7.

Neste problema. exploramos algumas propriedades de CRC. Para o g~rador C (• 1001) dado na Seção 5.2.3, respondu às scguimes quesu)cs:

a. Por que ele pnde dctcctilr
b. l'ode o G acima detectar qualquer mlmero rmpar de crms d e bh? Por que? 8.

Na Sc~;;\o 5.3, fornecemos um esboço da dcri"aç;lo da cflci~ncia do slnued t\LOIIA. Neste rroblema, concluiremos a deriv;u;~o.

a . Lembre-se de que, quando há N nós ativos. a efi· cicncla do sloued ALOHA é Np(l - p)'· •. Ache o valor de p que maximize essa expressão. b. Usando o \'alor de p encontrado em (a). ache a eflcicncta do sloucd Aloha razendo com que N tenda ao tn flnit(>, Dicc1: (l - 11 )' tende a lk quando N tende ao inflnuo. 9.

Mostre que a crictl!ncta máxtma do ALOHA puro é 11(2c·) OI~ : Este problema c f~cil se \'OCê tiver c:on· cluido o anterior.

10. Considere dois nós, A e B, que usem um promcolo ALO HA sluucd para competi r pelo canal. Suponha que o nó A tenh o mais
do nó l's· a. Dcumninc a fc~rmula para a vazão mMia do nó A. Qual é a eficiê ncia tot:tl dll protocolo com esses doiS IICÍS.

b. Se p,. • 2[11 • a vaz~o nu~dia do nó A li duas vezes maior <.lo <.Jue o do no B? Por quê, ou por quê não? Se não. como escolher p.., c p1 para que isso acontc~a?

c. No geral, suponha que existem N nos, e entre eles o nó A tem a probabtlidade de retransmissão de 2p c todos o:. OUiros nos tem a probabilidade de retransmiss.\o de p. Determine as expressões para computar a vazão média do nó A e de qualquer ou tro nó.

11. Suponh.1qucqua1J'0 nósmi\'OS- nós A, B. C c 0 - estão competindo pelo acesso a um canal usando o sloned ALOHA Imagine que cada nô tem um numero infi· nito de pacotes para cn"iar Cada nó tenta transmitir em cada slot com probabilidade p. O primeiro slot é numerado como I. o segundo slot como 2, c assim por diante.

a. Qual a probabihdade de o no A tenha sucesso pela pnmc1ra \'CZ no slot 5? b. Qual a probabilidade que algum no (A, 6. C ou D) tenha sucesso no slot ... ?

e. Qual a

prohahilid:~elc

que o primeirtl sucesso

ocorra nu slot 3? d. Qunl a cfici\!ncia nesse sistema d e <.tua tro nós? 12. Plote em gráfico ~ cllc i ~nciA do sloned ALOHA e do ALOHA puro como uma funç-~o de p, para N:

a. N• 15 b. N = 20

e. N

=30

13. Considere um canal bm(I(]CIIst com N nós e uma taxa de transmiss.'o de R bps. Suponha que o canal broadwsl use protocolo de polhng (com um nó de polling adicional) para aCCSS<> muhiplo. Suponha que o intervalo de tempo entre o momento em que o nó conclui a transm~o c o momento em que o no subscqucnte é autorizado a tr.msmuir (ISto é. o atraso de polling) seja d,. . Suponha aind~ que, dentro de uma rodada de polling. um dado nó seja autorizado a transmitir, no m~ll.lmo, Q bitS. Qual c a vazão mâxi· ma do canal bmculcrul?

H . Considere tres LANs lntcrconectadas por do is rolea· dores. como mostrado na Figurn 5 38 a. Atribua endereços a tod3S as in h:rfac.:es. Paro a Sub-rede l,llSC cndcrcçc>Sdo típo 192.168.1.:-cxx; para a Sub-red e 2, use endereços d o lipo 192.168.2.xxx, c parn a Sub-rede 3 nsc e ndereços elo tipo 192. 168.3.xxx. b. Atribua

mdcrc~'OS de

MACa todos os ttdaptadores.

c. Co nsidere o envio de um data~r.tmtt IP do hospedeiro;\ :10 hospedeiro F. Suponha que todas as mbclas ARP l'Stcjam atualiz:td(IS. Enumere todas as etapas como rol feito no exemplo de um unico roteador nn Sc~âo 5 ..... 2. d. Repna (d), admiundo agora que a tabela ARP do hospedc1ro remetente esteja vazia (c que as o utras tabelas estejam awalizadas). 15. Considere a Figura 5.38. Agora substuuunos o roteador e ntre as sub-redes I e 2 pelo comutador Sl, c etique· tamos o roteador entre as sub· redes 2 c 3 como Rl.


c


371

16. Considere o J>roblcma an terior, mas suponha
K • 100, quanto 1cmpo o adapHtdor espera alé voltar à clólpa 2 parn uma E1hcrnc1 de lO Mbps? E para uma Ethcmet de 100 Mbps? Sub-rede 1

Sub-rede 2

Figura 5.38 3sulxedes, interconectodores por 1oteodores

18 . Suponha que os nós t\ c O estejam no mesmo scg· memo Ethcmc• de 10 Mhi>S c que o a1raso de pro· J>agacão entre os dois nM seja de 225 tempos de bit. Suponha que o nó i\ comece a 1ransmi1ir um quadro c <)UC. :mtcs de 1erminar.
quadrt) foi 1rnnsmitido com sucesso. sem

n~:nhuma

colisM.

a. Considere tl envio de um clatagrama IP do Hospedeiro E no Hospedeiro F. O Hospedeiro E pedirá ajuda .10 roteador RI para enviar o datagrnma? Por que? 'o quadro Ethcmct que contém o datagrnma 11'. qual são os endereços de origem c dcslino IP c \1AC? b. Surxmha que E gostaria de enviar mn datagrnma li' a O. e que o cache ARf> de E não lenha o ende· reço MAC de O. O prc(XIrnrá uma consulta ARP fXII':l descobnr o endereço MAC de O? Por que? 'o
s.'\o os endereços de origem c dcs1ino IP c MAC? c. Suponha que o llosr>edelro A gostaria de enviar um datagrnmn lP ao Hospedeiro B, e nem o

enche ARP ele A contem o endereço MAC de B, nem o i\RP cachc de 13 comém o cndcrc<·o MAC de A. Sut>onha 1nmhém que a mhela de cnc:aminh~mcnlo do comuwdor SI contenha entradas somcnlc para o llospcdciro 13 c para o roteador RI. Dcss.'l forma . A transmitir.\ uma mensagem de rcquisicdo ARP. Que oç,)es o comutador SI tomará quando receber o mensagem ele requi· su;do ARP? O roteador RI lambém receberá a menS<~gcm de requisiç;\o ARP? Se sim. RI encaminhará a mensagem para a Sub-rede 3? Assim que o Hospedeiro B receber esse mensagem de rcqu•sk;\o ARP. ele enviar.\ a mensagem de voha .10 llospedcml A. Mas env•ar.\ uma mensagem ARP de consuh:l (XIra o endereço MAC de A? ror quê? O que o comu tador Sl fará quando receber mensagem de resposta ARP do Hospedeiro B?

Di((t: SliJXlllh:t que no tempo 1 = O 1em1><> de bit, A comece a transmitir um quadro. No pior dos casos, A transmhc um quadro de !amanho nlinimo de 512 + 6-1 tempos de b11 Portanto. A 1crminari01 de transmitir o quadro em 1 - 512 + 64 lempos de bil. Enlilo, a resposta scr.l n
Ethcrnct? Bas.:ado no seu resu ltado. qunl é o lilmilnho de pacótc mfn imo necessário para que uma Ethemet tenha a amplitude de 2 qu ilõtnelros?

20. Suponha que voe~ gostaria ele aumen1ar a velocidade do enlace do seu cabo Eth crncl. Como esse aprimoramento afc1aria os tamanhos mlnimos necessários ao p:tcc,te? Se ao aprimorar s.:11 caiX> para urna ''elo· <:idade mais aha c perceber que n~o pode mucbr tl tamanho do paco1c. o que mais ''OCC pode fazer para manter a operação correta? 2 1. Suponha que os nós A c O esteJam no mesmo seg· me mo de uma Ethcmct de I OMbt>S c que o atraso de propagaçolo entre os dms nós s.:p de 2-+5 tempos de bn. Suponha também que A c 8 enviem quadros ao

mesmo 1cmpo. que os qu~dros colidam c
bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------ativo. as retransmissões de A e 6 podem colidir? Para OOSS.1 nnalidndc. c suOcicnte rcsoh·cr o seguinte exemplo. Suponha que t\ c 8 comecem a transmitir em 1 • O tempo de bit. Ambos detectam colisões em 1 = 245 tempos de bit. Eles terminam de transmitir um sanal de reforço de colisJo em r = 245 + 48 = 293 tempos de bit. Suponha que K4 = O e K1 == L Em que tempo B programa sua retransmissão? Em que tempo A eoml'(";l a tran.:.missJo' (Nc,ra: os nós dt\'Cm esperar IKlr um can:tl ocioso após retomar a etat)lt 2 - veja o protocoln.) Em que tempo n sinal de A chega a B1 n se aostcm de transmi tir em seu temrKl programado? 22. Considere uma Ethcmc t lOOBASE-T de 100 Mbps. Pam ter uma cfici~ncia de 0,50, qual deve ser a distt'lnda m:ixima entre um nó c o hubl Admita um cumpri mcntn de quadro de 1.000 bytt'S c que n:\o h::l rcpctidon·s. Ess<~ dlsH'lncia máxinnt t
exums.~o.

24. Neste r>roblcrna, vocc derivará a eficiencia de um protocolo de acesso mt\ ltirlo semelhante ao CSMA/ CO. Nesse protocolu. o h:mpo ~segmentado c todos os :~daptadores eStilO slncroniudvs C
=

Se, p.,ra um dado mtcrvalo, nenhum nó estiver de posse do ca nal. wdos os nt\s disputam o can~l : em p;trticul:lr, cada nó transmite no intel"o':llo com prollahilidadc I'· Se exatamente um nó transmitir no IIHCI"o'Jio. esse nó tomara posse do c:mal para os k - I intel"o':llos subse· quentes c transmitirá seu quadro imciro. Se algum nó estiver de posse do canal, 10dos os outros nós evitar:\o transmitir até que o nó que c:sla de posse do canal tenha terminado de transmitir seu quadro. Assim que esse nt\ tiver transmit ido seu qul1dro. todos os nós dispu•~ rão o canal. Nmc que o cnnal se alterna en tre do1s estados: o es•ndo produtivo, que dura exa tamente k intervalos, c o estado nlo procluti\•o,
b. Para N fixo. determine I' que maximiza a cfidencia. c. Us;~ndo o p (que é uma runçJo de N) encontrado em (b). determine a eficiencia quando ' tende an infinito. d. Mostre que css.1 cHc1cnciJ se aprox1ma de I quando o compnmcnto do quadro é grande. 25. Suponha que dois nos. A c B. estcj:m1 ligados às extremidades opostas de um cabo de 900 metros c que cada um tenha um quadm de 1.500 bi ts (incluindo todos os c;•bcç;1lhos c preâmbulos) para tra1lSmitir um ao outro. Ambos os t H>s tentam transmitir no tcmp~l t = O. Suponha liUC haja qtU\Ifll repet idores cmrc A e ll, cada um inserindo um atraso de 20 bits. Admita que a tnxn de trl\1\smissllO é I00 Mhps c que é usado 11m CSMA/CD cu m In tervalos de backoff de mtlltiplos de 5 12 bits. Aplis a pri mei r:~ colis;\o, r\ sor· tcin K O e 13 wrteill K I no protocolo de lxlcko[r cxponcncml. Ignore o s1nal ele rdorço c o tempo de atraso de 9ó bits.

=

=

a . Qual é o atmso de pmpagaçào em um sentido (i ncluindo os atrasos de repetidores) entre A c 13 em scgu ndllS? Suponha que a velocidade de propagaç;\o dn sinal seja 2 • lO' m/s.

b. Em que tempo (em segundos) o pacote de A é completamente en tregue em B? c. Agora suponha que somente r\ tenha um pacote para Cll\'iar c que os repetidores seJam substi tui· dos por comutadores. Suponha que cada comutador tenha um atraso de processamento de 20


26. No padr.'o Ethernct, um remetente espera 96 tempos

2 7. C()nsiclcrc n Figum 5.38 no f>roblcma Pl4. Determine

os cndcro\:oS MAC c IP p~t ra as in1crfaccs do ~lospcdciro A. ambos os roteadores c do Hospcdcíro F. Detcrmim: os cndcrccos MAC de origem c d estino no quadro que CllC:tpsula d~Se d:II:J)\rama 1P, já que O quadro é ll'llnS· mitido (I) de r\ ao roteador esquerdo, (ií) do roteador esquerdo ao roteador dircilo, (iii) do roteador direito a f . Determine também os cndcrcctl$ I f> de origem c destiM no dat:~gran1:1 IP encaJl$UI3dn no qundro em cada o desses pontos no tempo.

28. Suponha que o roteador da extremidade esquerda da Figura 5.38 stja suhslituido por um comutador. Os Hospede1ros A, B. C c D c o roteador direito tem uma conex.\o estrela a esse comutador. Deu:nnine os endereços MAC de destino e origem no quadro que encapsula esse d:uagrama IP enquanto o quadro e transmitido (i) de A ao commador, (ii) do comutador ao roteador direito, (iii) do ro1eador direito a F. Determine também os endereços IP de origem c destino no dntagmma IP encapsulado !>Cio quadro em cada um desses pomos no 1cmpo. 29. Considere 11 Figum 5.26. Supon ha que Lodos os e nlaces tem 100 Mhps. Qual é a vawo total rm\xima agrcgad:t que ptlclc se r atingido entre os 9 hospedei· ros c 2 servidores nessa rede? Suponha que qualquer lmspL·dcim ou se rvidor pode enviar a qualquer mum servid or ou ho:.p~clciro. Por 'tu i:?

30. Suponlm que tres comutadores departamentais na figum 5.26 sâo substituldos por hubs. Todos os e nlaces tCm I 00 \1bps. Agora responda as qucstôcs fl\lStas

M

pmhlcma 29.

31. Suponh:~ que todos os c01muadores na Figura 5.26 Slo substitufdos por hubs.. T ódos os enlaces tem I00 Mhps. Agor-.t responda :ls questões postas no problema 29.

32. Vamos cons1dcrar a operac;llo de aprendizagem do comutador no comexto da Figura 5.H . Suponha que (i) B envia um quadro a E, (ii) E responde com um quadro a B, (iii) A envia uma quadro a B, (iv) B

373

rcs1)011de com um q uadro a A. A tabela do comutador cst;t inld:llmcntc \'azia. Demonstre o \.'Stado da talw· la do comutador an tes c depois de cada um desses eventos. Para cada um dos eventos, idcmifique os enlaces em q ue o quadro transmitido scra encaminhado. e brc,emcntc justifique suas rcsr)OStas.

bitS além do mraso de armazenagem e repasse. Em que tempo. em segundos. o pacote de A é entregue em 13? dr bit entre enviar quadros consecmi\'Os. Este periodo de paus.1 é referido como gap de imcrquadro. e é usado para pcnmur que o disposhl\·o de n:cebimcmo complete o processo de um quadro recebido c se prepare para o recebimento de um próximo quadro. Desde que o p:1dr..1o Ethcrnet foi especificado, muitas melhoras tccno lllgicas ucomecemm, incluindo a vcloddade dos processadores. memória c as taxas da Ethcrnct. Se o padrlo pudesse ser reescrito, conw I!SSas melhoras innucnciariam o ga J) de intcrquadm?


33.

' este problemas c.-cploraremos o uso de pequenos p.1cotcs de Jphcaç<)~ de Vm; Sobre IP. Uma dcs· ''antagcm de um pacote pequeno é que uma grande parte da largurn de b.1nda do enlace é consumido por hytes de cabeçalho. Por isso, suponha q11~ o pacote é fonnado por P bytcs c 5 bytes de cabeçalho. a . Considere o envio de uma fo nte de voz eod ific:~da digita lmente diretamente. Supon ha t fUC a fonte esteja cod ificada a uma taxa constante de 128 Kbps. t\dmlla que cada pac111c esteja lntcgralmcnt~ cheio ames de l\ fome enviá- lo parn dentro da rede. O tempo exigido para encher um pacote é o atraso de empacotamento. Determine, em termos de P, o atraso de empacotamento cm mi lisscg undos.

b. Os atl'a$()S de empacotamento maiores do que 20 mihsscgundos pudcm caus.tr ecos pcrcepllvc1S c desagrada,•eis. Detcnnine o atraso de cmpacOla· memo para P = 1.500 bytes (corrcspondeme, aproximadamente, a um pacote Ethernet de tamanho m:\.'iimo} c para P = 50 bytcs (correspondente a um pacote A TM}. c. Calcule o atraso de armazenagem e rc1>assc em um umct> comutador t\TM pam uma taxa de enlace R = 622 Mbps para P I 500 bytes c p 50 bytt!>.

=

=

d. Comente as vamagcns de usar um pacote de ta1nnnho J)cqucm>. .34. Considere ounko comlllador VLAN dn Figura 5.30,

c su r)onha que um ro tc:1dor extcn1o cst~ conectado a pona I elo comutador. Atrihua endereços IP aos hospedeiros EE c CS c~. interf:~cc do ro teador. Relacione as ctal>as nsadrLs em ambas eam:l(las de rede ~ de enlace pam tmnsfcrir o dutagrama 11' ;tt> hospedeiro EE c ao hospedeiro CS. (D ica: Leia novamen te nosso cstttdo da figum 5. L9}

35. Considere a rede MPLS m ostr:tda na Figum 5.36 c suponha que os rot.:adores R5 c R6 agora Slo habilitados para MPLS. Suponha que queremos cxecm.-tr engenharia de trMcgo de mudo que pacot\.'S de Ró destinados a A scjnm comutaclos para A 'ia R6-R4· Rl·R I. Mostre as tabclns \IPLS em R5 e Ró, bem como a tabela modificada em Rof, que tomariam isso possh·el. 36. Considere a mesma situação do problema anterior, mas suponha que os pacotes de R6 destinados a D estão comutados via R6-R4-R3, enquanto os pacotes

bow4tto4ic~ Redes de com putod ores e o Inler-..;n;.;e.;.t_________________________

de ~ destinados n O sejam cormuados via R4-RlRl ·R3. Apresente as tabelas MPLS em todos os roteadores que tornariam isso possh·el.

37. Neste 1>rohlem:1.

voe~ juntnr:\ tudo

que aprendeu

sobre pmtoeolos de Internet. Suponha que você entre em uma s.1la. conecte-se à Ethcmct c quer fazer o download de uma pagina wcb. Quais são c:tapas de

protocolo utilizadas, desde ligar o computador até rcc:cbcr a l>.rgin:~ wcb? Suponh:~ que n.\o tenha n:~da no seu Oi'\S ou no seu na\"C)t:ldor quando voc~ ligar seu compu tador. (Dica: as etapas incluem o uso de protocolos da Ethcmct. OIICP. r\RP. O S. TCP e IITTP). Indique explicitamente em suas etapas como obter os cndcrc~s MA C r: IP de um roteador de borda.

Questões dissertotivas Você dc\'C na,·cgar na Weh para responder às pcrgumas a seguir. 38. Qual é a raixa de prcco llproxirnada atual para um adt~pt ndor Ethc rnet de 10/100 Mbps? E para um

as vantagens c liS d csv;l nt:rgcns de deslocar essa funcionalicladc do adAp tador J):lm o nM

õlch1ptnd or Gigab it Ethcrnct? Compare ~s fHCÇQS com o preço de um modem discado de 56 kb1>s ou de um modem ASOL.

4 1. Utilize a Wch J>arll acha r os mlmcros de prmocolo usados ern u m quadro Ethcrncl para um da1agmma IP c para um pacote AR I".

39. O preço d c1s commado rcs geralmente é determinado segundo o rni mcro de interfaces (também dcnomi· nadas portas no jarg
42. Lei:• as referências IXiao. 2000; Huang 2002 c RFC 33461 sohrc cngc ulwia de tr:lfcgtl utilizand(l MPLS. Rcl:~donc um conjunto de metas pam a cngcnh:~ria de tmfcf!o. Quais dessas metas podem ser cumprlcl:ts somen te com MPLS e quni:. dclns ~)o niC
40. Muitas das funções de um adaptador podem ser realizadas em software que executa no nó da CPU. Quais

zando protocolos existentes que n.lo sJo MPLS> No ultímo caso. q uais solo as \':lntagens que o MPLS ofercc:c?

Wiresharklob No Cc>mJmniml W.-bsitc. W'rtW. aw. com/ kurose_br encmurcml duas tanjas de Wirl'.~lwrk que aaminam Cl oprrocilo do pmtowlo IEEE 802.J .- o fm mcllo dCJ quadrc1 Wireshc1rl1. I'Ol~

A segurulcc Wirt'sltark Ltrb c.wwrina Cl ~cqrrcnciCI dcJS txrcorrs usados numcc ~rruacclo de rrdc dmnl'srica, par~citla com e1 cprt cswc/pmos na Scccltl 5.J .7

bow4tto4ic~

Simon S. Lom Simon S. Lom é professor e regente do cadeira de ciência do computoçõo no Universidade do Texas, em Austin. De 1971 o 1974 trabalhou no ARPA Network Meosurement Center no UCLA, com comutação por satélite e por ródio. liderou um grupo de pesquiso que inventou os sockets seguros e construiu o primeiro protótipo do comodo de sockets seguros, em 1993, denominado Programação de Rede Seguro . Os pontos de interesse de suo pesquiso sõo o projeto e o onólise de protocolos de rede e serviços de segurança. Graduou-se em engenharia elétrico no Washing ton S!Ote University e é mestre e dotJtor pelo UCLA. Foi eleito a Acode mio Nacional de ~ngenhoria em 2007 ;\ O que o fex se decidir pelo especialização em redes?

Quando cheguei à UCLA. recém-form:tdo, no outono d e 1969, minh:. in teuç:lo em estudar teoria de eomrole. EntàO ass isti ils aulas de Leon:1rd Kleinroek sobre teoria das Olas c ele me impressionou muito. Durante um certo tempo trnb:1lhet em controle adaptativo de sistemas de fila com o possrvcl tópico de tese. No in feio de 1972, L.arry Robcrts miciou o projeto ALOHA Satellite Systcm ( mais tarde denominado Packct S:ucllite). O professor Klcinrock perguntou se cu queria participar do projeto. A prüneira coisa que [lz foi int.roduzir um algoritmo de btlckoff simples. mas re.ahslll, no protocolo da sloucd ALOHA. Pouco tempo dcpots, encontrei muitos problemas interessantes paro pcsquis;u , como o problema da instabilidade da ALOI IA c a necessidade de backoff, que for· mariam o núcleo centro! da minha tese. O senhor teve portkipoçõo ativo nos primórdios da Internet no décoda de 1970, desde seus tempos de estudante na UClA. Como era o panorama naquela época? As pessoas faziam alguma ideia do que a Internet se tornaria?

Na verdade, a atmosfcm não em diferente da de outros projetos de construção de sistemas que já \'Í na indústria c no ambiente acad~mico. i\ meta inicial determinada paro a ARPAnet em bastante modesta, isto é, prover acesso a computadores caros a partir de localiz:1ç0es remotas de modo que mais cientistas pudessem utilizá-los. Contudo, com o i nfcio do projeto Packet Satellitc em I 9n c do projeto Packct Radio em 1973. a meta da t\RPA foi amplia· da substancialmente. Em 1973, a ARPA estava montando, ao mesmo tempo. trl!s redes ele pacotes dircrcntcs c tornou-se necessário que Vi nt Ccrf c Bob Kahn desenvolvessem uma estratégia de interconexão. Naquela cpoC'J, todos esses descn,·o lvirncntos progressivos na área de redes crlltn vistos (acredito cu) mais como cst:al<~dll da lmerncl c o poder dos compttladorcs de hoje. Tmnscorrcu uma dé<:ada ames do ap;uccimcnlo dos primeiros PCs. Para colocar :IS coisas em perspectiva, a maiorit1 elos cstud:mtcs apresen tava seus programas d e computador em cart ões pcrfumelos, paro processamento em lote. Somente alguns deles tinham acesso direto a computadores. que normalmente eram abrigados em á re-Js restritas. Os moderns eram lentos c ainda roros. No meu tempo de es wdante, eu tinha apenas um telefone sobre minha mes:• c usava p:1pcl c l:lpis p:1ra fazer a maior parte do meu Lrob:llho.

lógico:. do que tm\gicos. Ninguém poderia ter previsto a

Em suo opinião, qual é o futuro do campo das redes e da Internet?

No passado, a simplicidade do protocolo IP da Internet em sua maior força paro vencer a concorrência c se tornar o padnlo de facto do trabalho em redes. Diferentemente de seus concorrentes, como X-25 na década de 1980 c ATM na decada de 1990, o IP pode rodar sobre qualquer tecnologia de camada de enlace porque oferece apenas um serviço datagmma de melhor esforço. Assim, q ualquer rede de pacotes pode se concct:IT com a Internet.

375

bow4tto4ic~ Atualmente, a m:•ior for(\'a do IP ;~goro é urna deficitncia. O IP é como uma camisa de forç-J que confln;~ o desenvolvimento d:1 lmcrnct a direções especificas. Nos últimos :mos, muitos pesquisadores rcdirccionaram seus csfor(\'os somente p;lm as camadas de aplica(\'àO c transporte. para suporte de multiwst c QoS. Há também uma grande concentmçào de pesquisas em redes sem fio c redes ad hoc, redes de scnsores c redes por satélite. Essas redi.'S podem ser cons1dcradas ou como sistemas autônomos ou como sistemas de camada de enlace, que podem se desenvolver porque estão fora da camisa de forÇll do IP. Há muita gente animada com a possibilidade da utilização de sistemas P2P como plataforma para no\'aS aplicações da Internet. Todavia, a uuhzação de recu rsos da Internet por sistemas P2P é altamente ineficiente. Uma das minhas preocupações é se a capacidade de transmissão c cornutaç;io do nudco da Internet continuara a crescer mais rapidamente do que a dem:mda de tráfego na In ternet, enquanto ela cresce para intc:rconcctar todos os tipos de equipamentos c suportar futuras aplicações habilitadas para P2P. Sem um supcrprovislonamcn to su bstancial de capacidade. garantir a cstabllid:1dc da rede na prcscn(\'a de congestilo c de ataques mal-intencionados seria uma tarefa muito importante. O fenomena l crescimento da Internet também requer a aloc3(\'ào de novos endereços de IP em uma taxa rop id:~ à opertldores de rede c empreend imentos ao redor do mundo. Se continu:1rrnos assi m, o bloco de endereços IPv-t nao alocados v:lo se esgotar em algu ns anos. Quando isso acontecer, grandes blocos de espaços de endereços só poclcri\o ser alocados somenlc de espaços de endereço 1Pv6. Já q ue a adoçno do IPvó não está fazendo mu ito s ucesso, devido à falt:1 de incentivo para os novos usuár ios, 1Pv4 c !Pv6 Yt\o coexlstl r por muitos :mos. A migrn<;;io bem-sucedida de uma In ternet 1Pv4 paro uma 1Pv6 precisará de um grande esforço global. Qual porte de seu trabalho lhe apresento mais desafios?

A parte do meu trabalho que me apresenta mais di.'Safios é ensinar c motiva r rodos os I.'Studantcs que assistem às minhas aulas c rodos oo; cstudames de doutorado que supervisiono, e não apenas os supcrbcm-dotados. Os muito inteligentes c moth-õldos podem cx1gir um pouco de supervisão, mas nào muito ma1s do que ISSO. Muitas \'CZCS aprendo mais com esses estudantes do que eles ~~prendem comigo. Ensinar c motivar os que nno se dcst<\C.''am muito é um grande desafio. Que impactos sobre o aprendizado o senhor acho que o tecnologia terá no futuro? Fin<~lmcnu:. quase todo o conhecimento humano estará accssfvc:l pel;~ Internet. algo que será a mais poderosa

fcrrnmcnta de aprendizado. Essa \'aSta base de conhecimento terá o potencial de niVelar o terreno para estudantes em todo o mundo. Por exemplo. estudantes moti\'ados de qualquer pais poderão acessar os melhores sitcs Wcb de aulas, conferenci;~s multimídia c material de ensino. Já foi dito que as bibliotecas digilais do IEEE c da ACM aceleraram o desenvolvimento de pesquisadores da ciência da compmaçuo na Ch ina. Com o tempo, a Internet transcenderá todas as barreiras geogl'áficas do aprendizado.

376

bow4tto4ic~

6 Redes sem fio e redes móveis

N

o mundo da tclefonl:t pode-se dizer que os quanze úlumos anos fomm a década da telefonia celular. O

numero de assinantes de teldoncs móveis no mundo imeiro aumemou de 34 mílhõcs em IQ93 para

quatro bilhões no final de 2008 e, agora, o numero de assinamcs da telefonia celular ultrapassa o mime· ro de línhas telefônicas convencionais (ITU Statisúes, 20091. As muitas vantagens dos telefones celulares s;\o evidentes para todos - em qualquer lugar, a qualquer hora, acesso desm1pcdado à rede global de tclcfoma por meio de um equapamento Je,·e c totalmente portátil. Com o advento de laptops. palmtops, PDAs c a prorness;~ de :~cesso desimpedido à Internet global d e qualquer lugar. a qualquer hora, sem que estamos prestes a assistir a um

Scç.\o 6.2. lnclurmos uma breve introdução ao Acesso Muhiplo por Divis.io de Código (CO
Acus~-

6.1

Introdução 1\ Figura 6 . 1 mostra o l:enárlo no qual consideraremos os tópicos de conHmicaçào de dados c mobilidad e

scm no. Começaremos man tendo nossa discussão dent ro de um contexto geral o suficien te para abra nger uma ampla faixa de redes, entre clns LANs sem fio como a IEEE 802. 11 c redes celu lares como uma rede 3G; passaremos para unm díscusS;10 mais detalhada de arquiteturas sem fio especificas em seções pos teriores. Podemos 1dcntiflcar os seguintes elementos em uma rede sem fio:

Ho)pcdri• os srm fio. Como no caso de redes cabcadas (ou com fio), hos~deiros sào os equipamentos de sistcm:IS finais que executam aplk11ções. Um h ospedeiro sem Oo pode ser um laplop. um palmtop, um PDA. um telefone ou um compUiador de mesa. Os próprios hospedeiros podem ser ou não ser móveis.

tnfraestrutur a de rede

Legenda:

<' l-.

~

Ponto de acesso sem fio Hospedeiro sem fio Hospedeiro sem fio em movimento

Area de cobenura

Figura 6.1

Elementos de umo redesem fio

bow4tto4ic~ ( opitulo 6

Redes sem fio e redes móve is

Enlt~as

379

sem fío. Um hospedeiro se conecca a wna estação-base (definida mais adi:un c) ou a um outro hospede•ro sem fio por meio de um enlace de comnnicação sem no. Tecnologms de enlace sem fio d1feremcs têm caxas de cransmissM diferem es e podem cransmiur a disulnc1as d1rcrcmes. A Figura 6.2 mostra duas caracterfsticas rund:unen tais (área de cobertura c caxa de enlace) dos padrões de enlace sem fio mais populares. (A figura sen·e somente para mostrnr uma 1deia aproximada dessas caracterfscicas. Por exemplo, alguns desses cipos de redes somente est;Io sendo empregados agom, e algumas taxas de enlace podem aumentar ou diminuir além dos valores mostrndos dependendo da distância, condições do canal c do numero de usuários na rede sem fio.) i\ bordaremos esses padrões mais adiante na primeira metade desce capillllo; consideraremos também ou1ras caracumsticas de enlaces sem fio (como suas taxas de erros de bits c as causas desses erros) na Scç:lo 6.2. Na Figura 6 .1 enlaces sem fio conectam hospedeiros localizados na borda da rede com a inrraestrutura da rede de maior porte. Não podemos nos esquecer de acrcscemar que enlaces sem fio :ls ve:tes mm!Xm são utilizados cle••uro de ltma rede e para conectar ro•eadores, comu1adores c outros cquipamemos de rede. Contudo, neste capitulo, foculizaremos a uti liz:t~·M de comunic;l\iiO sem fio nas bordas dn rede, pois~ aqui que estilo ocorrendo muitos dos dcstfios técnicos mais inu:rcss.·uncs c a maior pane do crescimento. Eslllçilo·basr. A es1ação-ba.se é uma pane fundamental da inrrneslrutu m de rede sem fio. Diferentemente dos hospedeiros c enlaces sem fio, uma estaÇ"Jo-base mlo tem nen huma commpnrtc óbvia em uma rede ~-abcada. Um;! CSHW•lo·basc ~ rcspotlsá,·cl pelo envio c recebimento de dados (por exemplo, pacotes) de c para um hospedeiro sem fio que esto\ àSSOdado com ela. Uma csta~lo-base frequentemente será responsável pela coordena~lo da transmissão de vários hospedeiros sem fio com os quais está associada. Quando dizemos que um hospedeiro sem fio está ·associado' com uma estac:lo- basc, isso quer dizer que ( 1) o hospedeiro está dentro do alcance de comunicaç.lo sem fio da estação-base c (2) o hospedeiro usa a estação-base para rctmnsmllir dados entre ele (o hospedeiro) c a rede maior. Torres celulares em redes cdulares c pontos de acesso em uma l..AN sem fio 802.11 slo exemplos de estações-base. Na hgurn 6. 1, a estação-base está conectada à rede maior (IStO é, à lmernct. à rede empresarial ou residencial ou à rede teldõnica) e. portanto, fu nciona como uma retmnsmíssora de camada de enlace entre o hospedeiro sem fio e o resto do mundo com o qual o hospedeiro se comunica. Quando hospedeiros est.io associados com uma estação-base, em gemi di:t-se que estilo operando em modo de infrae:.trutura, j:í que todos os serviços tradicionais de rede ( por exemplo, atribuic.\o de endereço e roteamemo) são fornecidos pela rede com a qual estiverem conectados por meio da estaçãobase. Em redes ad hoc, hospedeiros sem fio nào dispõem de nenhuma infmes1rutura desse tipo com

200 M bps 54 Mbps

5-11 M bps

802.11 n 802.11 a,g

802.11a,g po nto-a-ponto

802.11b

4 Mbps

Wi MAX UMTSIWCDMA·HSOPA. CDMA2000·1xEVDO

3G enhanced

1 Mbps

802.15.1

384 Kbps

3G

UMTSIWCDMA. CDMA2000

2G

15-95, COMA. GSM

56 Kbps

Interna

Externa

Externa de meia dist~n
10-30m

50-200m

200m- 4km

Figura 6.2 Carocteríslicas de enlaces de padrões selecionados de rede sem fio

Externa de longa d istância Skm-20km

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------a qual se conectar. Na austocia d e tal infraestrutura, os próprios hospedeiros devem prover serviços como roteamento, atribuiç-Jo de endereço, traduçilo de endereços semelhante no DNS e ou tros. Quando um hospedeiro móvel se desloca para fo ra da faixa de alcance de uma estaç-.lo-base e entra na faixa de uma o utra. ele muda seu ponto de conexão com a rede maior (isto~. muda a estação-base com a qual csw associado) - um processo denominado tra nsferên cia (handofO. Essa mobilidade dá ori· gem a muitas questões desafiadoras. Se um hospedeiro pode se mo,·er, como descobrir sua locnlizaç.i o corrente na rede de modo que seja possivellhc transmitir dados? Como~ realizado o endereçamento, dado que um hospedeiro pode estar em uma entre muitas localizações possiveis? Se o hospedeiro se mo,•imcntar tlurmue uma conexão TCP ou ligação telcfOnica, como os dados sen1o rotc;~dos de modo que a conexuo conunuc sem mterrupção? Essas e muitas ( mas muitas!) outrns questões fazem das redes se m no c móveis uma área muito interessante da pesquisa de redes. tnfmestrulura clt' redr. ~a rede maior com a qual um hospedeiro sem fio pode querer se comunicar. Após discutir sobre as "panes" ela rede sem fio, observamos que essas panes podem ser combinadas de diversas maneiras diferentes para formar diferentes tipos de redes sem fio. Vcx:ê pode achar um<~ Laxonom io. desses tipos de red es sem fi o útil ao ler este c<~phulo. ou ler/aprender mais so bre redes se m fio :~l~m dcs1e livro. No nf\•el mais alto, podemos dassiOcar as redes sem Oo de acordo com dois crit~rios: (i) ou um p<~colc na rede sem fio atm\•essa exntmn cntc um salto scmfro ou diversos saltos scmfro, e (ii) ou há ínjmt-slnllum. como uma esta~'ào·b..1SC na rede: Sctllo rlnico. com iufmcscruwr(r. Ess.1S redes tem uma cstaç;lo-b:tse conectada a um rede robe.,da m:~ior (por exemplo, a Internet) . Além disso, toda a comunicaç'.io ~fe ita entre" estação-base e um hospedeiro se m no através de um saho sem Oo único. As redes 802. 11 que voe~ utiliza na sala de aula, no café ou na bibltoteca: redes de telefonia celular; e as redes WiMAX 802.16 que aprenderemos de fomla breve. e ncaix:~ndo-se nes1a cllegori
Neste capitulo. iremos nos delimitar às redes ele saho unico e, depois, às red es co m infraesrruwra. Agora vamos nos apro[und<~r um pouco mais nos desafios ttcnkos que surgem em redes sem fio c móveis. Começaremos considerando, em primeiro lugar, o enlace sem fio indi vidual, adiando no~\ discus~)o da mobilidade para o u1m parte deste t-apitulo.

6.2 Características de enlaces e redes sem fio Van1os começar considerando uma rede simples cabcada, por exe mplo, uma rede rcsrde ncial com hospedei· ros rnterconectados 1>0r um comutador Ethernet cabcado (ver Seç-lo 5.6). Se substit ulsscmos a Ethernet cabcada por uma rede 802.11 sem fio, uma placa NIC sem fio substit uiria as placas da Ethernet cabcada nos hospedeiros e um ponto de acesso substituiria o comUiador Ethernet, mas, na camada de rede ou acima dcl<1, praticamente nenhuma mudança seria necessária. Isso sugere que concentremos nossa atenção na camada de enlace ao pro-


Redes sem fio e redes móuis

Acesso público WHi: em breve facilmenteoseu dispor? Pontos de oce~ W;.Fi - locais públ~os onde os usuários podem encontrar OGesso sem fio 802.11 estõo se tornando codo vez mais comuns em hotéis, oeropor1os e cafés oo redor do mundo. A portir do final de 2008. o l -Mobile oferece pontos de oce$SO em mais de 1O mil locais nos Estados Unidos (e mais de 45 mil no mundo), incluindo os cofeterios Storbucks e os lojas Borders Books & Music. A maioria dos compi universitários oferecem acesso sem fio espalhado por todo o porto, c é difícil encontror um hotel que não oferece oceuo à Internet sem fio. Diversos cidades, incluindo Filadélfia, Son Francisco, Toronto e Hong Kong, anunciaram planos de prover esse oces.so sem fio dentro do todo o cidade. O objetivo no Filadélfia foi "transformar o Filadélfia no maior ponto de acesso Wi-Fi do país e ojudor o melhoro r o educoção, eliminar o exclusão digital, oprimoror o desenvolvimento do reg ião e reduzir os custos do governo". O plano inicialmente exigiu o instolo.ç õo de ponto.s de aceno sem fio 802.11 em aproximadamente 4 mil postes de iluminação e meconismos de controle de rrófego. O ambicioso programo - um acordo entre o cidade, o Weireleu Philodelphio (entidade sem fins lucrativos) e o ISP Eorrhlink - construiu uma rede operocionol. O projeto GovWiFI de Hong Kong "prover6 serviço Wi.fi grátis em 350 dependências do governo em foses. Estobeleceró cerco de 2 mil pontos de ocesso Wi·Fi públicos no território e tornoró Hong Kong uma cidade sem fio com oproximodomente dez mil pontos de ocesso Wi-Fi públicos em 2009: Criar planos poro o Wi-Fi municipal onipresente, entretanto, provou ser uma torefo difícil. A rede Wi.fi municipal de Son Francisco nunca possou do proposto. Em 2008, o Eorthlink cancelou seu serviço Wi-Fi no Filodéllio. Mos o rede municipal pogo de Toronto continuo operonclo, assim como os redes Wi·Fi municipais em diversos cidades. A busco por rede sem fio municipal continuo. O hHp:/ /www.muniwireleu.com é um site que ocomponho o cenário dos redes sem fio municipais.

curarmos d1fcrcnças nnponantes entre redes com fio e sem fio . Realmente. podemos encontrar varias d1ferenças imponantcs entre um enlace com fio c um enlace sem rio:

Rtducclo da for(ll elo sinal. Radiações e1etromagnéticas são atenuadas quando atra,•essam algum tipo de matéria (por exemplo. um sinal de rádio ao atra,•cssar uma parede). O sinal se dispersam mesmo ao ar lívre. resultando na reduç;lo de Slla força (às vezes denominada at enu ação de percurso) à medida que aumenta a distância entre emissor e receptor. lnterfer~ttcia dr outras fonlrs. Várias fomes de rádio transmitindo na mesma banda de frequj!ncia sofrerão lmcrferéncia umas das outras. Por exemplo, telefones sem Oo de 2,4 Gllz c L.ANs sem fio 802.llb transmitem na mesma b.1nda de frequéncia. r\ssim, o usuário ele uma L•.AN sem fio 802.11 b que estiver se comunK~u1do por um telefone sem fio de 2.4 Gl-lz pode esperar que nem a rede nem o telefone fun· cionem particularmente bem. i\lém da interfcren<:ia de fontes transrnissor.ts. o ru(do eletromagnético presente no ambiente (por exemplo, um motor ou um equipamen to de microondas próximo) pode rcsLtltur em imcrferencia.

Propt1gacilo multivlas. Prot>agação multi"ias (ou mulucaminhos)

Tendo considerado as falhas que podem ocorrer em um canal sem no. vamos voltar nossa atenç;lo para o hospedeiro que recebe o sinal sem no. Esse hospedeiro recebe urn sinal eletromagnético que é uma combinaç.lo de uma forma degradada do sinal original transmitido pelo remetente (degradada dcvtdo aos efeitos da atenuação c da propagaç;lo multivias d iscutidas :teima, entre outros) c um ruído de fundo no ambiente. A razão sinal-ruído (SNR) é uma medida relativa da potencia do sinal rcccbtdo (ou seja. a infonnação sendo transmillda) c o rufdo. O SNR é, normalmente, medido em unidades de decibéis (dB), uma unidade de medida que algumas pessoas acham que é uulizada por engenheiros elémcos para confundtr cientistas da computaç.lo. O SNR. medido em dB, é vinte vezes a razão do logaritmo de base 10 da amplitude do sinal recebido à amplitude do ruido. Para nossos flns, precis;tmos saber somente que um SNR maior facilita ainda mais para o destinatário extrair o sinal transmitido de um ruído de fundo. A Figura 6.3 (adaptada de [Holland. 20011 mostra a taxa de erro de bttS (BER)- grosso modo, a probabilidade de um bit trans mitido ser recebido com erro no destinatário- \'l'rsus o SNR para três técnkas de modulac;iiO diferentes p11rn codll'icar informações para a trnnsmissão em um canal sem no idealizado. A teoria dn moduh1ç;o'o c el11 coei ir.~~.,~·ão, bem como 11 extração do sin11l c a BER, v11i t~lérn do objetivo eles te liwo (consulte ISchwa ru , 19801 p;u·n uma d iscussão sobre esses ;lssuntos). Nilo obstante, o Figura 6.3 ilustm cli"crsns caractcrrsticas da carnacln Hska CjUC s;lo im pon an tcs na com preensão dos protocolos de comun lcaçflo sem fio d a camada mais superior:

Ptlm 11111 clrtrrmimu/o rs/JO{o ela moJuiCiçclo, crucmto nte~is alto for o SNR. mais bc4i.~o srrc1 c1 IJER. Visto que u m remetente pode aumentar o SNR ele,•:mdo sua potência de li"'Jnsmiss:lo, ele pode reduzir íl probabilidade de um quadro ser recebido com erro di min uindo sua pol~ncia de tronsmissi!o. Observe, entretanto, que há um pequeno ganho prático no aumento da potêncía além de um certo patamar, digamos que paro aumcnt:u a BER de 10' 11 para to·n. Existem também dt'S\'tlllWgc~ts assoch\cl:\5 com o aumento da pottlncia de transmissão: mais energia deve ser g:\Sta pelo remetente (uma cons•deroção importante paro usuários móveis que utilizam bateria), c as transmissões do remetente tém mais probabilidade de tnterfcnr nas transmissões de outro remetente (consulte Figuro 6.4 (b)). PcuCI 11111 clrwmlnCido S1 R. uma ttcnica ele mO
1o-• - QAM16 -QAM256 ' (11 Mbp~) (8 Mbps)

10' 1

1o·•

..."'

10...

Cl)

lCJS

10.. 10"1

o

10

20

SNR (dB)

Figura 6.3 Taxo de erro de bits, taxo de transmissãoe SNR

30

40


Redes sem fio e redes mónis

A

B

c

.IVc. o

~

.~ v

c

~

õ

o.

c

B

a.

o Locali:açao

b.

Figura 6.4 Problema do teuninol oculto (o) e do desvoneómento (b) BER tão baixa como estar (literalmen te) "fora das pamdasp. Se é possível supo rtar uma BER de 10' 7, a taxa de transmiss:\o mais alta aprcscmada pela modulação QAM l ó a tornaria a técnica d e modulação preferida nesta siluaç;\o. Essas considerações dão origem à camcterfstica llnal. descrita abaixo.

Srlecilo rlimlmlra ciCJiécnica ele motlule~çclo modultJ(clo pam comlições tlc ratral. O SNR (e, portanto, a BER) pode alterar como resuhado ela mobilidade ou

em razao das mudan\<15 no ambicmc. A modulaç-.lo adapliva c a codiflcaç;\o Silo usadas em sistemas de dados celulares, no WiMAX 802. 16 c nas redes Wi-Fi 802.1 1 que estudaremos na Seção 6.3. Isso per· mue. por exemplo, a seleção de uma técnic:a de modulação que oferece a mais alta taxa de transmi.ssão possível sujeita a uma limitaç-Jo na BER. para determinadas características do canal. Taxas de erros de bits lll3is altas c que variam ao longo do tempo não s.\o as linlcas diferenças entre um enlace com llo c um enlace sem llo. Lembre-se de que. no caso de enlaces brooclcast cabeados. todos os nós recebem as Lrnnsm ~Sí>ÕCS de todos os outros nós. 'o caso de enlaces sem llo. a suu:~ç-Jo não é tão Simples, corno mostra a Figura 6.4. Suponha que a estaçl\o A esteja transmitindo para a es~aç-Jo B. Suponha também que a cstaç:\o C esteja Ll"llnsmitinclo para a estação 13. O denominado problema do terminal oculto , obstruções f1sicas presentes no ambiente (por exemplo. uma montan ha ou um ediffcio). pode impedir que A c C escutem :15 trunsmissões d e um e de oulro, mesmo que as transmissões d e A e C estejam interferindo no destino, B. Isso é mostrado na Figura 6.4(a). Um segundo ccn:.trio que resulta em colisões que não são detectadas no receptor é causado pelo d esvanecimento da for~·a d e um sinal à medida que ele se propaga pelo meio sem fio. A Figura 6.4(b) ilustra o caso em que a localizaç-Jo de A c C é 1:11 que as po t~nclas de seus sinais não são suficicmes para que eles detectem as transmissões de um c de o utro. mas, mesmo assim, sdo s uficientcn1ente fones paro~ interkri r uma com a outra na estação B. Como vc1·emos 11:1 Scç:'o 6.3, o problern:1 do terminal oculto c o clesv:llleci Jncmo tornam o acesso nu\ ltlp lo em uma rede sem llo consideravelmente mais complexo do que em uma rede cabc:1da.

6.2.1

COMA

Lembre-se de que dissemos. no Cap!tulo S, que, quando hospedeiros se comunicam por um meio comparulhado. é prec1so um protocolo para que os sinais enviados por vários emissores nâo interfiram nos receptores. No mesmo capflulo descrevemos tr~ classes de protocolos de acesso ao meio: de partiç;lo de canal. de acesso aleatório c de rcvcz;lmento. O acesso mühiplo por divisão de código (Code Oiv1S1on Muhiplc Access- COMA) é ainda um quarto tipo d e protocolo de acesso a um meio com partilhado, predo minante em tecnologias celulares c de LAN sem llo. Por ser tlo importante no mundo sem llo, examinaremos o COMA rap1damen1e agora, antes de passar para tecnolog1as espccíllcas de acesso sem fio nas seções subscquentcs. Com um protocolo CDMA, cada bit que está sendo enviado é codificado pela multiplicação do bit por um sinal (o código) qllC muda a uma velocidade muito maior (conhecida corno velocidade de chip ping) do que a

bow4tto4ic~ Redes de co 111 pu lod ores e o Inle ;.; r n;.;e;.;.l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

sequ~ncia

original de bits de dados. A Figura 6.5 mosua wn cenário simples c idealizado de codifica\-\oldecodificaç-Jo COMA. Suponha que a velocidade com que bits de dados originais cheguem ao codificado r COMA dellna a unidade de tempo, IStO é, que cada bit original de dados a ser trans mitido requeira um intervalo de tempo de um bit. Seja ti, o valor do bit de dados para o i-ésimo intervalo de bit. Por eonveni~nci:~ do cálculo matemático, representamos o bit de dados com valor O por -1. Cada intervalo de bit ê ainda subdiVIdido em M mini-intervalos. Na figura 6.5. M = 8, embora. na prática, M seja muito maior. O código COMA us:tdo pelo remetente consiste em uma sequ~neaa de 1\f \':llores, c.,, m = 1, ...• M, cada um assummdo um valor de + I ou - I. No exemplo da Figura 6.4. o código COMA de M bits que está sendo usado JXIO remetente é (1 , L 1. - 1, I , - 1, - 1. -I). Para il ustrnr como o COMA funciona, \'amos focalizar o i·ésimo bit de dados. cl,. Para o m·ésimo mini· -intervalo de tempo de transmissão de bits d,. a S3fd.-. do eodificador COMI\, é o valor de cl, multiplicado pelo rn-ési mo bit do código COMA escolhido, c,:

z,,...

z.. =d,. c.

(6. 1)

Se o mundo fosse simples c não houvesse remetellles interferindo, o receptor receberia os bits codificados, , t"alculando: 1

z,)ll. c recuperaria os bits de dados origi nais, ci

J M

c/1 -

-

LZ

1"" •

M ,..,

(6.2)

c,.

Talvez o leitor queira repassar os detalhes do exemplo da Figura 6.4 para vcrifi<.'3r se os bits originais de dados s.\o, de fato, corrct.:tmcntc rccuperndos no receptor usando a Eqltaçào 6.2.

Remetente

B•ts de dados

d_,_._._,_

Ll_ _

Saida do canal Z, m

__J

I Intervalo 1

Intervalo O

Salda do canal Int ervalo 1

Intervalo O

Receptor

..

Ztm ·Cm d,- :L;."'•:.;•__ _

~~~~~~~~+4-...

M

o

Intervalo 1 Intervalo O entrada recebida entrada recebida Código

•L ::-___ d,. · 1

I I

Figura 6.5 Umexemplosimples de COMA: codificação no remetente, decodificação no receptor

_,j

~Ida

do cana l



No cntamo, o mundo está longe de ser ideal c, como mencionamos antes, o COMA deve funcionar na presença de remetentes que imerrcrem e que estão codificando e u·.msmitindo seus dados usando um código dcsignado diferente. Mas, como um receptor COMA pode recuperar bits de dados onginais de um remetente quando esses bits de dados cst:'lo sendo ernb
=

z·,...

Sur preendentemente, se os códigos dos remeten tes forem escolhidos com cuidado, cada receptor pode rceu · pemr os dados enviados por um d;,do remetente a p:mir do sinal agregado Olpcnas usando o código do remetente, como na Equaçi\o 6.2: I

d;

5

2: z..... c,., M.,.,

-

M

•

(6.3)

A Ftgura 6.6 ilustra um exemplo de COMA com dois remetentes. O código COMA de M bits que cst
6.3 Wi-Fi: LANs sem fio 802.11 Presentes no locul de trntr.11ho, em casa, em instituições educacionais, em caf~s. aero(X>rtOS c esquin;lS, as LANs sem no agora são um<~ das mais importantes tecnologias de rede de acesso na tmemet de hoje. Embora muitas tecnologias c p;1drOes p~m1 LANs sem fio tenh;~m sido desenvolvidos na d6c;tda de 1990, uma classe particular de padrões surgiu claramente corno a vencedora: a lAN sl'JD fi o 1EEE 802.11 , tam bém conhecida como \Vi-FI. Nesta scç;\o estudaremos mais detalhadamcme as L.ANs se m no 802. 11, exa minando a estru tura do quadro 802.11 , o protocolo 802.11 de acesso ao meio c a interconexão de LANs 802.11 com L.ANs Ethemet cabcadas. H:I dh•ersos padrões 802.11 para tecnologia de LAN sem rio, entre eles 802. 11 b. 802. 11 a c 802. llg. A Tabela 6. 1 apresenta um resumo das principais características desses padrões. Na ~pntos de acesso c (X>r fornecedores de placas LAN. Estão também disponíveis um número de mecanismos de modos duplo (802.llalg) e triplo (802. llalb/g).


Remetentes

l__d..;.f_.._,_ _.....___d-'~;....=_1_

Bits de dados ...

I

__,

o

z

Z~,=

dz > 1 ·c,

..

Receptor 1

~

B

2 2 2 1111

00

d,'-

B

....L ztm·c:, M

o

Intervalo 1 Intervalo O entrada re
.,

d:. _,

(

I

Figura 6.6 Um exemplo de CO/M com dois remetentes Os trCS padrOcs 802.11 comJ>artilham muitas caractcrlsticas. Todos usam o mesmo protocolo de acesso ao melo, CSMNCA, q ue discutiremos em bre,•c. Todos os tr~s tamb~m ll$.1tn n mesma cstnuu rn de quadro para seus quadros de t-:mmda de enlace. Todos os três padrõeS tém a capacidade de reduz ir sua taxa de trnnsm i~lo para ak-ançar distllnci~ m:~iorcs. E todos os três padrões permitem ' modo de infraestrutura' c 'modo ad hoc', como discutiremos em breve. Contudo. como mostra a Tabela 6. 1, os tr~s padrões apresenta m ;Jlgumas difercnÇ':IS importantes

na <.<~m:•da físi<.<~. A LAN sem no 802.11 b tem uma ta.xà de dados de 11 Mbps c opera na faixa de freq u~nCI:.I não licenciada de 2.4 a 2.485 Gl lz. compelindo por espectro de frequtnda com tcldones e fornos de micro-ondas de 2.4 GHz. LANs sem no 802. I la podem funcionar a taxas de bit.s significati\'ameme mais altas. portm em frequ~ncias mais allas. Como operam a uma frequ~ncia mais alta, a distância de trnnsmiss;lo dessas LANs é mais cuna para um dado nl\'el de pottncla e elas sofrem mais com a propagaÇão rnultivlas. lANs sem fio 802.11g. que operam na mesma fa1xa de frequtncm ma1s baixa das l.A~S 802.11 b c que são eompall\'eiS com a 802. 11 b (para que seja possível atualizar clientes 802.llb de forma crescente), porém com as taxas de transmissão mais altas da 802.lla, devem permitir que os usuários tenham o melhor dos dois mundos.

bow4tto4ic~ Redes sem fio e redes mónis

( opífulo 6

Padrão

Faixa de frequenda

Taxa de dados

802.11b

2,4-2,485 GHz

até 11 Mbps

802.11a

5,1-5,8 GHz

até 54 Mbps

802.11g

2.4-2,485 GHz

até 54 Mbps

Tabela 6.1

Resumo de pockões IEEE 802.11

Um novo p;1dn\o Wi-Fi. 802.lln [lEEE 802.lln 2009). está em processo de padron ização. 802.ll n utiliza antenas d e salda rmihipla c entrada mtHtipla (MIMO); ou seja, duas ou mais antenas no I:~ do remetente c duas ou mais amcmts no lado dcsunat:i rio que csl:'lo transmitindo/recebendo sinais dirercntes [Diggavi, 2004]. Embora o padrilo ainda deva ser finnliz:.do. estão disponíveis os produtos pré- padrlo, sendo que os testes iniciais mostram :1 v:.z:\o de mais de 200 Mbps na prátia t [Newman, 2008). Uma considcmc;\o imponante em re lac;;lo 410 padrão atua l é a maneira ru1 q ual os mc~::mismos 802.11 íntcraglr;\o com os mc~"l\lll s rnos 802. 11 a/blg existentes.

6.3.1

Aarquitetura 802.11

A Figur:l 6 .7 Ilustra os principais componentes da arquitetu ra de LA N sem no 802. l l. o bloco construtivo rundamcntal da arquitetura 802. 11 é o conjtmto básico de ~rviço (V
~mO o

AP

BSS 1

BSS2

Figura 6.7 Arquitetura do lAN IEEE 802.11

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....Ell1crnct cabeada que lruerconccta os APs e um roteador. A Figura 6.8 mostra que estações IEEE 802.11 também podem se agrupar c formar uma rede ad hoc- rede sem nenhum controle central c sem nenhuma conexão com o ·mundo externo·. Nesse caso, a rede é formada conforme a necessidade, por eq ui pamentos tnó\'cis que, por acaso. est:'\o próximos uns dos outros, tem necessidade de se comunicar c não dispõem de infmcstrutura de rede no lugar em que se encontram. Uma rede ad hoc pode ser formada quando pessoas que portam laptops se reúnem (por exemplo, em uma sala de confer~ncias. um trem ou um carro) c querem trocar dados na aus~ncia d e um AP centralizado. As redes ad hoc estão dcspcnando um mteresse extraord inário com a continua proliferação de equipamentos portáteis q ue podt>m se comunicar. Porém. nesta s~o. concentraremos r\OSS:'I atcnçáo em LANS sem no de infraestrutura.

Canais e associação Ern 802. I I, cada estação sem fio precisa se associar com um AP antes d e poder enviar o u receber quad ros 802.11 con tendo dados de camad:1 de rede. Embora todos os padrões 802.11 usem associação, discutiremos esse tópico especificamente no contexto da IEEE 802.llb. Ao instal:1r um AP. um administrador de rede designa ao po nto de acesso um Iden tificador d e Conjun to de Serviços (Sr•rvirr Set ltleurifirr- SSIO) composto de uma ou duas pal
BSS

Figura 6.8 Umo redeod hoc IEEE 802.11

bow4tto4ic~ {opitulo 6

Red u sem fio e redes móuis

Especificamente. someme o AP associado enviará quadros de dados (isto 1!, quad ros comendo dados, tal como um datagrama) à sua csta~·âo sem fio e sua estaç-Jo sem fio enviará quadros de dados à Internet somente por meio do AP associado. Mas como sua CSt:\Ç n;'lo carregado n:lo ~sel eciona do em raz:lo :1 um sinal levcmcnlc mais fraco. Um número de maneiras :1hernativus para escolher os APs fo ram p ropostas rccemememe [Vasudevan, 2005; Nicholson, 2006; Sudarcsnn, 2006). P<1r:1 uma diseus~lo inLercssnme c prática de como a força do sinal é medida, consuhc [Bardwell, 2004].

O processo de varrer (;anais e ouvir quadros de sinalizaçao ~conh ecido como varred ura passiva (veja figur:t 6.9a). Um hospedeiro sem fio pode também realizar uma varredura a tiva, transmitindo um quadro de investigaç:.lo que ser:l recebido por todos os APs dentro de uma faixa do hospedeiro sem no, como rnos1rado na Figura 6.9b. Os APs respondem ao quadro de requisição de invesligação com um quad ro de respos1a de im•cstigação. O hospedeiro sem fio pode, ent.'\o, escolher o AP com o qual se associar den tre os APs de resposta. 1\pós selecionar o AP, o hospedeiro sem fio envia u m quad ro de solicitação de associação no 1\P, c este responde com um qu3dro de resposta de associação. Observe que essa segunda apresen raçâo de solicitaçâo/resposm é necess.irta com a varredura ativa, visto que u m AP de resposta ao quad ro de solicitação de in,·estigaçâo inicial não sabe quais dos (possivelmente muitos) APs de rcspos1a o hospcdeiro cscolhcrar para se associar, do mesmo modo que um cliente CHCP pode escolher entre servidores mliltiplos DHCP (veja Figura 4.21 1. Uma vez associado ao AP. o hospedeiro desejará entrar na sub-rede (no sentido do endereçamento IP da Scc,'áo 4.-f.2) à qual pertence o AP. Assim, o hospedeiro normalrncme enviará wna mensagem de descoberta DHCP (vej:. Figura 4.21) à sub-rede at ravés de um AI' a nm de obter um endereço IP na sub-rede. Logo que o endereço é obtido, o res tan te dn lmcmet, emdo, vê esse hospedeiro simplesmente corno ouLro hospedeiro com um endereço IP naquela su b-rede. Para eri:.r u ma associac;1lo com um d eterminado AP, a cst:1ção sem fio possivelmen te terá de se aute nticar perante o AP. Li\ Ns sem fio 802. 1 L d ispõem de várias altcrnn tivns para a utCIHka~·ão c acesso. Um:1 abordagem. usada por muitas empresas, ê permil ir acesso a uma rede sem no com base 110 endereço MAC de uma estnçâo. Uma segunda abordagem, usada por muitos cafés lmernel, emprega nomes de usuários c senhas. Em ambos os casos, o AP normalmente se comu nica com um servidor de au tcn tic-.tç;'lo usando um protocolo como o RADIUS IRFC 28651 ou o OIAMETER IRFC 35881. Separar o servidor de autenticação do J\P permrte que um servidor de amcnticação atenda a muitos APs, centralizand o as decisões de alHCntk-:u;tlo c acesso (quase sempre delicadas) em umlinico servidor c m;mtendo baixos os custos c a complexidade do AP. Veremos, na Seção 8.8.4, q ue o novo prowcolo IEEE 802.11i, que defi ne aspec10s de segurança d:. fnmrlla de pro1ocolos 802.1 1, adota cxammen1e essa abordagem.

6.3.2 Oprotocolo MAC 802.11 Uma vez associada com um AP, uma estaçao sem no pode começar a envtar c receber quadros de dados de e para o ponto de acesso. Porém, como várias estações podem querer transmitir quadros de dados ao mesmo


BBS 1

ln;.;l~e;.;rn;.;e;.;.t_________________________

BBS 1

BBS 2

BBS 2

0 AP 1

AP 1 H1

a. Varredura passiva 1. Quadros de si natizaçio enviados dos APs 2. Quadro de Solicit açlo de Associação enviado: H1 para AP selecionado 3. Quadro de resposta de associaçlo enviado: AP selecionado para H1

Figuro 6.9

H1

a. Varredura at iva 1. Roadcast de quadro de solicit aç!o de investigaçAo de H 2. Quadro de Respost a de Investigações enviado de APs 3. Quadro de Resposta de AssociaçAo en~iado: H1 para AP selecionado 4 . Quadro de Resposta de AssodaçAo en~iado: AP selecionado para H 1

Voneduro passivo eoti'IO poJO pontos de acesso

tempo sobre o mesmo canal, é preciso um protocolo de acesso múltiplo para coordenar :IS transmissões. Aqui, estação significa uma esta Ç'ào sem fio ou um AP. Como discutimos no Caprwlo 5 c na Sc~·;\o 6.2.1, em termos gerais h:\ trts cl:tSses de prot

Redes s tm li o e redes món is

391

slgnlficnlv:uncntc o drscmpcnho de um protocolo de acesso múltiplo. Para reduzir a probabilidade de colisões, o 802.11 emprega diversas t~cnicas de prevenção de colisão, que discutiremos em breve. Antes de considcmr prevenção de colisão. contudo, em p rimetro lugar devemos examinar o esquema de reconhecimento na cama d a de en lace do 802.11. Lembre-se de que dissemos. na Seç:lo 6.2. que. quando uma cstaç;io em uma U\, sem fio envia um quadro , o q uadro pode mio chegar intacto à rstaçJo de drstino por uma \'ariedadc de razões. Para lidar com CS5:l probabilidade não dcsprezlvcl de ralha, o MAC 802.11 usa reconhecimentos de camada de enlace. Como tlustrado na Figura 6.8, quando a estaç-ão de desuno recebe um quadro que passou na verif'icaç;\o de CRC. dn espera um curto período de tempo. conhecido como !Zspaçamcn to Curto Jntcrquadros (Sholl l ntrr-Fmmc Spctcing- SIFS). c então devolve um quadro de reconhecimento. Se a estação trnnsmissora n:lo receber um reconhecimen to dentro de urn dado perlodo de tempo, ela admitirá que ocorreu um erro c rctransmitir.i o quadro usando novamente o protocolo CSMNCA para acessar o canal. Se a estação trnnsmissora m\o receber um reconhec imento após um ccno número fixo de rc transmissôrs, desistirá c descartará o quadro. Agora q ue j:\ discutimos como o 802.11 usa reconhecimentos de c:un:~da de cnl:~ce, est:~ mos prontos para desc rever o protocolo CSMNCI\ 802.11. Suponha que urna estação q mllqucr (pode ser Ulll
De nino

} siFS

Figura 6.1 O 802.1 1 uso reconhecimentos de camada de enlace


4. Se receber um reconhecimcmo. a cstaç-.lo transmissora saberá que esse quadro foi corretamente recebido na cstaç;\o de destino. Se a estaç-Jo tiver outro quadro para tr•.tnsmitir, iniciará o protocolo CSMNCA na etapa 2. Se não receber um reconhecimento. a estação transmissora entrará novamente na fase de backoff na etapa 2 c escolherá um valor aleatório dentro de um intervalo maior. Lembre-~ de que sob o protocolo de acesso múltiplo CS!\-WCD (Scç;io 5.5.2), uma estaç-Jo começa a trans· mitir tilo logo jXrcebe que o can:tl está ocioso. Com o CSMtVCA, entretanto. :1 cst:.ç;lo priva-se de transmitir enquanto realiza a contagem regrcssiw, mesmo quando ela percebe que o canal csul ocioso. Por que o CS~WCD c o CDMNCA adotam css:ts abordagens diferentes aqui? Para responder a essa pergunta, wmos considerar um cenário com duas estações em que cada uma tem um quadro a transmitir, mas nenhuma transmite imediatamente porque percebe que uma terceira estação já está transmitindo. Com o CSMNCD da Ethernet, cada uma das duas estações transmitiria tô'IO logo detectasse que a terceira estação terminou de tr.msmitir. Isso r:ausaria uma colis:'lo, o que nào t uma questão stria em CSMtV CO, já que amf>as as estações :1bortariarn suas tr~msmissões c assim e'•itariam a tmnsmissào im\til do restante dos seus quadros. Ermetanto, com 802.11 a sltuaçao é bem diferente. Como o 802.11 rulo detecta urna colls:\o nem aborta transmlss:\o, l i iTI quadro que sofra uma colisão será transmitido in tegralmente. Assim, a meta do 802.11 é cvimr colisões sempre que possível. Com esse protocolo, se duas estações perceberem que o c:an:~l está ocupa· do, ambas cmmnlo lmcdi:u:HllCntc em backorf aleatório c. esperamos. escolhcrlo valores diferentes de backoff. Se esses valores forem, de fato. diferentes, assim que o canal nc-.u ocioso, uma das clu:IS começará a transmitir antes da outra c (se as duas estações nào estiverem ocultas uma da outra) a 'cs t;~çào perdedora' ouvirá o sinal da 'csLação vencedora', interromperá seu contador e não transmitirá até que a csLação vencedora tenha concluído sua transmiss;\o. Desse modo é evitadt\ uma colisão dísptndiosa. Ê ch\ro que :linda podem ocorrer colisões com 802.11 nesse cenário: as duas estações podem estar ocuhas uma ela outra ou podem escolher valores de backoff aleatório próx1mos o bastante para que a transmiSSão da estaç;\o que se inicia primetro tenha amda de atmgir a segunda estação. Lembre-se de que já vimos esse problema anteriormente em nossa discussllo sobre algoritmos de acesso aleatório no contexto da Figura 5.14.

Terminais ocultos: RTSe GS O protocolo 802.11 MAC também inclui um esquema de reserva inteligente (mas ope1onal) que :tjuda a C\'i· tar colisões mesmo na presença de terminais ocultos. Vamos cstud~u esse esquema no contexto da Figura 6.11 , que mostra du:IS estações sem fio c um ponto de acesso. Ambas as estações sem fio estão dentro da faixa do AP (cuja :!rca de cobertura é representada por um círculo sombreado) c ambas se assoemram com o AP. Comudo, de,•ido ao desvanecimento, as fr~ixas de sinal de estações sem fio esulo lirniLadas ao interior dos círculos som· bre<~dos mostrados na Figura 6. 11. Assim, cada uma das estações sem fio est:l oculta da outra, embora nenhuma esteja oculta do AP.

H1

Figuro 6.11

Exemplo de termino! oculto: Hl estó oculto de H2, e vice-verso


Aedu sem fio e redes mónis

393

Agora vamos consid erar por que terminais ocultos podem ser proble má ticos. Supo nha que a cstaç:\o H 1 está trans milindo um quadro c, a meio caminho de sua t ransm issão. a estação 112 quer enviar um quadro para o AP. O 112. que nllo está o u\rindo a transmissão de H l , primeiramente esperará um intervalo DIFS para, então, transmitir o quad ro, res ultando e m uma colisão. Consequentc mcnte, o canal sera des· perdaçado durante todo o perrodo da transmissão de H 1. bem como durante a transmiss:lo d e H2. Para evitar esse problema. o protocolo IEEE 802.11 permite que uma estação utilize um quadro d e controle RTS curto (Rrqursr ro S1'11d- solicítação de envio) c um quadro d e controle CTS curto (Ciear to Srml - pronto para envio) para reservar acesso ao canal. Quando um remetente quer enviar um q ua· dro DATA. ele pode enviar primeiramente um quadro RTS ao AP indicando o tempo total requerido para uans mitir o quadro DATA c o quadro d e reconhecimento (ACK). Quando o AP recebe o quadro RTS, responde razcndo a tra nsmissão broatlwsr de um quadro CTS. Esse quadro CTS tem duas n nalidadcs: dá ao reme tente uma permissão explícita para enviar e também instru i as outras estações a nllo enviar durante o tempo rcserv"do. Assim, n:1 Figum 6.12, :mtcs de tronsmitir um quadro DATA, Hl primeiramente faz uma trans missão bromlccrsr de um quadro RTS, que ê ou.v ida por todas as estações que estiverem dcn1ro elo seu drculo ele alcance, incluindo o i\P. O i\P cn t;\o responde com um quadro CTS, que é ouvido por todas as eswçõcs dentro d e s ua f:tixa de alcanrc, incluindo lil c H2. Como ouviu o CTS, a estação t-Il ddxa dt tmns mitir dumntc o tempo cspccilkado no quadro CTS. Os quadros RTS. CTS, DATA c ACK são mostrados na Figura 6.12. Fonte

Destino

Todos os outros nós

} stFS

Deferir .'ICMSO

} stFS

.---. ,. " Figura 6.12 Prevenção de colisão usondo os quadros RTS e QS

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------i\ utilizaç~o dos quadros RTS e CTS pode melhorar o dcscm~oho de dois modos imponantes:

O problema da estaç~o oculta é atenuado, visto que um quadro Di\TA longo é transmitido somente após o canal ter sido reservado. Como os qu:tdros RTS e CTS são cun os, uma colisão que envolva um quadro RTS ou CTS terá apenas a duraçõ\0 dos quadros RTS ou CTS cunos. Uma vez que os quadros RTS c CTS sejam corrct.'lmcnte transmitidos. os quadros DATA c ACK subsequen tcs devcr:1o ser transmitidos sem colisões. Aconselhamos o leitor a verificar o applct 802.11 no siu~ Web deste Livro. Esse applet interativo ilustra o protocolo CSMNCi\, incluindo a sequencia de troca RTSICTS. Embora a troca RTSICTS possa üjudar a reduzir colisocs. também introduz atraso c consome recursos do canal. Por essa razão, a troca RTSICTS é ut ilizada (quando utihzada) apenas para resen':lr o canal para a tran>míssào de um quadro DATA lo ngo. Na pr.ilíca, mda estação sem fio pode estabelecer um patamar RTS tal que a sequencia RTSICTS seja utilizada somente q uando o quadro for mais longo do que o patamar. Para muitas estações sem fio, o valor def:tult do patamar RTS é maior do que o com primemo rn:h:imo do quadro, de modo q ue a scquência RTSICTS é omitida p;tra todos os quadros 01\Tr\ en,oiados.

Usando o 802.11 como enlace ponto·o·ponto Até aqui nossa discuss."lo focalizou a utilização do 802.11 em um cenario de nniltiplo :~cesso. Devemos men· cionar que, se dors nós tiverem. t-:tda um. uma an tena d irecional. eles podcr:1o di rigir suas :tntenas um p:tra o outro c executar o protocolo 802.1 I sobre o que é, essencialmente. um enhtce ponto·a·ponto. Dado o baixo custo comercial do h:trdware 802.11 , a utilização de :mtenas direcionais c uma maior pot~nci a de transmissão permitem que o 802. ll sej:t utilizado como um meio barato de prover conexões sem no ponto-a-pomo por dezenas de quilômetros. (Raman, 2007} descreve um:1 dess.'IS redes sem flo mu h.issaltos que funciona nas planrcies rurais do rio G:mges, na lndia. c que contém enlaces 802.11 ponto-a-ponto.

6.3.3 Oquadro IEEE 802.11 Embora o quadro 802.11 tenha muitas semelhanças com um quadro Ethernet, ele t.1mbém contém vários campos que s:lo espccflkos para sua utilização para enlaces sem fio. O quadro 802. 11 é mostrado na Figura 6.13. Os números acima de cada um dos t"am pos no quadro represcruam os comprimentos dos c:tmpos em bytts; os numcros :teima de cada um dos subcampos no campo de controle do quadro representam os comprimentos dos subcampos em bits. Agora vamos examinar os campos no quadro, bem como :tlguns dos sub<:::unpos mais impor· ta ntcs no campo de controle do quadro.

(cmpos de cargo úlil ede CRC No cora~·ão do quadro est;\ a carga útil . que consiste, tipit"amCnte. em um datugmma IP ou e m um pacote ARP. Embora o comprimento permitido do mmpo seja 2.312 bytes, normalmente ele é menor elo que 1.500 bytes, Quadro (os números indicam o comprimento do campo em bytes): 2 2 6 6 6 2 Controle de quadro Ouraç3o

Endereço 1

Ender~o

2

6

Endereço Controle Endereço 3 de sequênda 4

2

CRC

Detalhamento do campo de controle do quadro (os núm.eros i ndicam o compriment o do campo em biu): 2 2 4 1 1 1 1 1 111 VersAo do prot ocolo Tipo

Subtipo

Figura 6.1 3 Oquadro 802.11

Para o AP

Do AP

M ais Nova Gerenciam~nto Mais WEP R d de energra dados sv fragmentos t ent ativa



395

contendo um dmagrnma IP ou um pacote ARP. Como um quadro Ethcrnct, um q uad ro 802.11 Inclui uma veriflcaç.lo de redundância cfclica (CRC). de modo que o receptor possa detectar erros de bitS no quadro recebido. Como já v• mos. erros de b1lS st\o muito mais comuns em LANs sem fio do que em LA 's cabeadas. portanto, aqui, CRC é ainda mais util.

Campos de endereço Talvez a diferença mais marcante no quadro 802.11 é que ele tem quatro campos de endereço e cada um pode conter um endereço MAC de 6 bytcs. Mas por que quatro campos de endereço? Um campo de fonte MAC c um campo de destino MAC não s:lo suficientes como são na Ethernet? Acontece que aqueles tr~ campos de endereço s:\o necessários para flnalldad es de imerconexM em rede- cspecifiC'tlmente, parn mover o datagrnma de camada de enlace de unu1 estação sem fio. passando por um AP. até urnõl interface de rote<~dor. O quarto campo de endereço é usado quando APs encaminham quadros uns aos outros em modo ad hoc. Visto que estamos considerando apenas redes de infrncstruturn, vamos concentrar nossa menção nos u~s primeiros cmnpos de endereço. O padrao 802.11 deflnc esses campos como se segue: Endereço 2 é o endereço MAC da estação que trnnsmite o quadro. Assim, se uma cstaç;\o sem fio transmitir o quadro, o endereço MAC daquela estação será inserido no campo ele cndcre~·o 2. De modo semelhante, se um AP trnnsmitír o qmtdro, o endereço MAC do AP será inserido no campo de endereço 2. E nd crc~·o 1 é o endereço MAC da cstaç.lo sem fio que deve receber o quadro. Assim, se uma estação mó,•el sem fio transmitir o quadro, o endereço 1 conterá o endereço Mt\C do t\P ele destino. De modo semelhante, se um AP tmnsmitir o quadro, o endereço 1 conterá o endereço MAC da estação sem fio dcsunatária.

Para entender o endereço 3 , lembre-se de que o BSS (que consiste no AP c estações sem fio) é pane de uma sub-rede. c que essa sub-rede se conccta com outras sub-redes. via algum,t interface de roteador. Para compreender melhor a finalidade do endereço 3. vamos examinar um exemplo de interconexão em rede no contexto da Figura 6. 14. Nessa figura há dois APs, cada um rcspon~wcl por um certo número de estações sem fio. Cada um dos APs tem uma conexão direta com um roteador, que, por sua vez, se conccta com a Internet global. Devemos ter sempre em mente que um AP é um dispositivo de camada de enlace c, portanto, não 'fala' IP nem entende endereços IP. Agora. considere mover um datagrama da interface de roteador RI até a estação sem fio H l . O roteador não está ciente de que h:i um AP entre ele c H 1; da perspectiva do roteador, H 1 é apenas um hospedeiro em uma das sub-redes às quais ele (o roteador) está conectado.

Internet

BSS 1

BSS2

Figura 6.14 Autilizo~õo de
bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------O roteador. que conhece o endereço IP de Hl (pelo endereço de destino do datagrnma), utiliza ARP paro determi nar o endereço MAC d e H 1. exatamente como aconteceria em uma LAN Ethemet comum. Após obter o endereço MAC de Hl. a interface de roteador Rl cncapsula o datagmma em um quadro Ethcrnct. O cam po d e endereço de fonte desse quadro contém o endereço MAC de Rl c o campo de endereço d e d estino contém o endereço MAC de Hl. Quando o quadro Ethemet chega ao AP, este conven e o quadro Ethernet 802.3 para um quadro 802.11 antes de tm nsnuli·IO paro o canal sem fio. O AP preenche o endereço 1 c o endereço 2 com o endereço MAC de 111 c seu próprio endereço MAC, respectivamente, como descrito acima. Para o endereço 3, o 1\P insere o endereço MAC de RI. Dessa maneiro, H1 pode dctcnninar (a partir do endereço 3) o endereço MAC da interface de roteador que enviou o d:uagrama para a sub-rede. Agora considere o que acontece quando a csmção sem fio H 1 responde movendo um datagrama de 1-ll para Rl. H L cria um quadro 802. 11, preenchendo os campos de endereço I c 2 com o endereço Mt\C do AP e com o endereço MAC de H 1, respectivamente, como d escrito acima. Para o endereço 3, 111 insere o endereço MAC ele Rl. Qu:1ndo recebe o quadro 802.11 , o AP o convenc para urn qu~1dro Et hernet. O campo de endereço de fonte para esse quadro é o endereço MAC de Hl c o campo de endereço de destino é o endereço MAC de Rl. Assim, o endereço 3 permite que o AP determine o endereço de destino MAC apropriado ao construir o qu:1dro Ethcrnet. Em resumo, o endereço 3 desempenha um papel crucial na interconexão do BSS com uma LAN c-abeada.

Campos de número de sequência, duraçãoe controle de quadro Lembre-se de que, em 802.11, sempre que uma estação recebe corretamente um quadro de uma outrn CSlrivacy) indica se ~t:! sendo o u m'o utili zada criptografia. (A WEP é discutida no Capítulo 8.)

6.3.4 Mobilidade na mesma sub-rede IP Para ampliar a raixa ftsica de uma LAN sem fio, empresas e univcrsid<~des rrcquentcmcnte distribuirão vários BSSs dentro da mesm<~ sub-rede IP. Isso naturalrncme leva ma a questao da mobilidade entre os 85Ss- como ~~a ções sem fio passam mimcrrupta e imperceptivelmente de um BSS p.1ra omro enquanto mantem sessões TCP em curso? Como ,·cremos nesta subseção, a mobilidade pode ser manipulada de uma mancirn relativamente direta quando os BSSs são parte de uma sub-rede. Quando estações se movimentam entre sub-redes, são necessários protocolos de gerenciamento de mobilidade mais soÍisúcados, tais como os que estudaremos nas seções 6.5 e 6.6.

bow4tto4ic~ { opítulo 6


397

Agora vamos examinar um exemplo cspedfico de mobilidade entre BSSs na mesma sub-rede. A Figura 6.15 mostra dois BSSs mterconcctados c um hospedeiro. Hl, que se move entre BSSl c BSS2. Como nesse exemplo o dispositivo de mtcrconcx;lo entre os dois BSSs ntio é um roteador, todas as estações nos dois BSSs, incluindo os APs. pertencem à mesma sub-rede IP. Assim, quando Hl se move de 8551 para BSS2. ele pode mamer seu endereço IP c todas as suas conexões TCP em curso. Se o dispositivo de interconexão fosse um roteador. então H I teria de obter um novo endereço IP na sub-rede na qual CSta\'a percorrendo. Essa mudança de endereço Interromperia (c, consequentemente. l'inahzaria) qualquer conexão TCP em curso em 111 . Na Seção 6.6, veremos como um protocolo de mobilidade da camada de rede, como o IP mó\'cl. pode ser usado para c'•ilar esse problcnta. Mas o que acontece espccil'icamente quando H I passa de BSSl para BSS2? A medidr~ que se afasta de APl. o 111 detecta um enfraquecimento do sinal de APl e começa a fazer uma varredura em busca de um sinal mais forte. lll recebe quadros de sinalização de AP2 (que em muitos ambientes empres:maís c universi tários terão o mesmo SS!D do AP I). Então, HI se dcsassocia de APl e se assoei:• com AP2, mamcndo, ao mesmo tempo, seu endereço IP c s uas sessões TCP crn curso. Isso abrange o problema dt> transferência do ponto de vista do hospedeiro c do J\P. Mas c quanto ao comutador na Figura 6. 15? Como é possrvel saber que o hospedei ro se locomovcu de um hospedeiro a outro? O leitor talvez se lembre de que, no Capitulo 5. dissemos que comutadores observam os endereços c constroem automaticnmente suas tnbclas de repasse. Essa ..·aractcristka de :uno-aprendizage m funciona bem parn movimentações ocasiom1is (por exemplo, quando um proftssional ~ transferido de um depa rtamento para outro); contudo, comutadores não são projetados para suportar usuários com alto grau de mobilidade, que querem manter conexões TCP enquanto se mo,•imentam e ntre BSSs. Para avaliar este problema aqui.

lembre-se de que. ames da movimentação. o comutador tem um registro em sua tabela de repasse que vincula o endereço MAC de H 1 com a interface de saida do comutador por meio da qual o 111 pode ser alcançado. Se H 1 estiver inicialmente em BSSl, então um datagmma destinado a H I ser:i direcionado a ele via API. Contudo, tão logo Hl se associe com 8552. seus quadros deverão ser direcionados pam APl. Uma solução ( na verdade um tanto forçada) ~ o AP2 enviar ao comutador um quadro Ethcrnet broodC(ISI com o endereço de fonte de H I logo após a no,•a associação. Quando o comutador recebe o quadro. atualiza sua tabela de repasse. permitindo que H I seja alcançado via AP2. O grupo de padrões 802.1l está desenvolvendo um protocolo intcr-AP pam manipular essas c outras questões associadas.

6.3.5 Recursos avançados em 802.11 Finalizaremos nossa abordagem sobre 802.11 com uma breve discuss.lo sobre capacidades avançad:IS encon· tradas nas redes 802. 11. Como veremos, essas capacidades não s~o completamente cspc-cific:•das no p.1drlo 802.11 , rnas, em vez disso. s;lo habili tadas por mecanismos especificados no padr:\o. Isso permite que fornecedores diferentes i111plemcntcm essas t-apacidades usando suas próprias ~tborclagens, aparentemente tmzc ndo vantagens sobre a concorr~ nci:1. Hub e>u comutador

Figura 6.1 S Mobilidade no mesmo suiHede


Adoptoçõo do taxo 802.11 Vunos amcriormcntc na Figuro 6.3 que as diferentes técnicas de modulação (com as diferentes taxas de Lr:IJISmi~lo que eles fornecem) slo adequadas para cenários SNR diferentes. Considere, por exemplo. um usuário

802.11 mOvei que está, inicialmente. a 20 metros de díst:'lnda da estaçlo·bJSc, com uma alta razão sinal-ruído. Dado o alto SNR, o usuário pode se comunicar com essa estaç-.lo usando uma técnica de modulação da camada fisica que provi! altas taxas de transmissão enquanto mantém uma BER baixa. Esse usuário é um felizardo! Suponha agorn que o usuário se torne mOvei, se d istanciando da cstaç-Jo-base. sendo que o SNR diminui à medida que a distância da estaç:lo-basc aumenta. Neste caso, se a técnica de modulaç:'lo usada no pr01ocolo 802.11 que está operando entre a estaç;io-base c o usuário não mudar. a BER será inaccila\'clmcmc alta à medida que o SNR diminui c , consequcmemcntc, nenhum quadro transmitido será recebido corrctmnente. Por esta raz.\o, algumas implementações de 802.11 possuem uma capacidade ele adapta~co aumenta pam a próxima taxtt mais alta. Esse mecanismo de adaptaç;Io d:1 taxa comparulha a ml'Sma fi loson:, de "investigaçio~ (refletido por recebimentos ACK); qmmdo algo "ruim" acontece, ~~ taxa de transmiss:1o ~ reduzida. A adapta<,'ào da taxa 802.11 c o con trole de t-ongestionamento TCP s;>co, deste modo. semelhantes à cri:m~·a cst•\ sempre exigindo mais c mais de seus pais (dig:unos que dcx:c, para uma criança c chegar mais tarde em casa, JX'fa os adolcsccrlles) at~ eles finalmente ditcrcm ~chega! ~ c a criança dcsístir (parJ tentar novamente após a situac;ilo melhorar!). Um número de métodos também foi proposto para aperfeiçoar esse esquema básico de ajuste automático de taxa encontrado em [Holland, 2001; Lacagc, 20041.

Gerenciamento de potência i\ poté!ncia é uma fonte preciosa em aparelhos mOveis c. assim, o padr;lo 802.11 pro"~ capacidades de gerenciamento de potência, permitindo que os nOs 802.1 1 minimizem o tempo de suas funções de pcrccpç-.lo, lrnltSmissào c recebimento, c outros circuitos precisam estar -em funcionamento". O gerenciamento de potência 802.11 opera da scguimc m:mcirn. Um nó é capaz de alternar claramente entre os estados de dorm!ncia e despcnar (como um aluno em sala de aula! ). Um nó indica ao ponto de acesso que entram no modo de dormência ajustando o bit de gerenciamento de potência no cabeçalho de um quadro 802.1 1 parn 1. Um temporizador localizado no nO é, cnli\o, ajustado para acordar o nó antes de um AP ser programado para enviar seus quadros de sinaliz:wão (lembre-se de que, normalmente. um AP envia um quadro de sinaliza~
Um nó acordar:\ logo após o AP enviar um quadro de sinalizaç:1o, c mpldamcnte entrará no modo ativo (diferentemente do eswdantc sonolento, esse despertar lc''a apenas 250 rnicrossegundos lKamcrman, 1997] !). Os quadros de sinahz:tç:'lo enviados pelo AP contêm uma relaç:\o de nós cujos qu:tdros foram armazenados no AP. Se não existirem quadros armazenados p:trn o nó, ele pode voltar a dormir. C:tso contrário, o nó pode. claramente, solicit<1r o e1wio dos qu:~dros :~rmazcnados enviando uma mcns:lgcm de polling ao AP. Com um tempo de intcrs•· naliz:w:io de 100 milissegundos. um despertar de 250 nülisscgundos c um tempo semcllmmcmcnte pequeno para receber um quadro de sinalização c verificar que não haja quadros armazenados, um nO que não possui quadros para enviar ou receber pode dormir 99% do tempo, resultando em mna economia de energia signiflcati\'a.

6.3.6 Mais além de 802.11 : Bluetooth e WiMAX Como Ilustrado na Ftgura 6.2, o padrão \Vi-Fi IEEE 802.11 é voltado para a comunicação entre aparelhos diferenciados de até 100 metros (exceto quando 802.11 é usado em conHguração ponto a ponto com antena dire-



399

cional). Dois outros protocolos IEEE 802- o Bluetootb (definido no padr~o IEEE 802.15.1 (IEEE 802. 15.20091) e o WiMAX (definido no padr:1o IEEE 802.16 (IEEE 802.16d 2004: IEEE 802.16c 20051)- s:\o padrões para se comunicar a disu'lnc.as m:us curtas c mais longas, respecth':lmente.

Bluetooth Um rede IEEE 802. 15.1 opera sobre uma curta faixa. a baixa potênci:t, e a um custo batxo. Esta~- basicamente, uma tecnologta de · substituição de cabos" de batxa taxa, faixa curta e batxa pottncia para mterconectar laptops. aparelhos periféricos. telefones celulares e PDAs, enquanto 802.11 é uma tecnologia de · acesso" de alt.'l taxa. faixa médta c aha pottncia. Por esta razão, as redes 802.15.1, às vezes, são denominadas rede pessoal sem no (WPAN). As camad:ts de fisk-a e de enlace de 802.15.1 são baseadas na especiOcaçl!o do Bluetooh anterior para redes pessoais [l lcld, 2001 : Bisdikian, 20011 . Redes 802.l5. l operam em faixa de rndio não licenciada de 2.4 GHz em modo TOM, com intervalos de tempo (time slots) de 625 microssegundos. Durante cada intervalo de tempo, urn emissor tmnsmitc por um emre 79 canais, sendo que, de hnervalo para inten•alo, o canal muda de uma maneira conhecida, porém pseudoaleatória. Essa forma de saltar de canal em canal (hopping), conhecida como frcqu eucy·ltopping spread spwncm (FHSS), espalha tnmsmissócs sobre o espectro ele frcqlt~ncir~ ao longo do tempo. O 802.15.1 po
WiMAX O WIMJ\X (lnteroperabilídade Mundial para Acesso em Micro-ondas) pertence. familia dos padrões IEEE 802.16 que vis:t a entregar dados sem !lo a um grande número de usuários sobre uma ampla área a taxas que competem com as redes ADSL c modem a cabo. O padrao 802.16<1 é uma awalíznçilo do paclrao 802.16a. O paclrJo 802. l6c tem o objetivo de suportar a mobilidttdc a velocidades ele 70-80 milha:. por hora (por exemplo,

p

5

p +---~--~~~-------+• Raiode W cobertura

s

Figuro 6.16 Umo picorrede Bluetooth

p

5

p

Legenda:

bow4tto4ic~ Redes de co r11 pu tod ores e o In;.;l~e;.; rn ;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

velocidades de rodovia na maioria dos pafscs fora da Europa) c possui urna estrutura de enlace diferente para aparelhos pequenos c de recursos limitados. como PDf\s. celu lares c laptops. A arquitetura 802.16 t baseada na noção de uma csta(ào-basc que serve uma grande quantidade de clit:ntes (conhcc1da como estações de assinante) associados a essa estação-base. Neste senudo. o WiMAX se parece tanto com a infraestrutura da tecnologia \'Vi-Fi como com as redes de telefonia celular. A CSt.1Çtio-base coordena a transmiss;\o dos pacotes da ~mada de enlace nas direções de tra nsmissão (downstream) (da estação-base para as estações de assinante) c recebimento (upsLream) (das estações de assmame para a cstaç.\o-basc) de acordo com a cstnllura do quadro do TOM mostrodo na Figura 6.17. Usaremos aqui o termo • pacote· em ''C~ do termo •quadro· (que usamos para 802.11 c para pacotes da camada de enlace) para difcrenci.-.r a un idade de dados na camada de enlace da estrutura do quadro do TOM mostrada na Figurn 6.17. Desta maneira, o WI~MX opern em multiplexação de divis;lo do tempo (TDM). embora o tempo de framing seja variável, como discutido abaixo. Observamos qLtC o WiMAX defi ne tambtm um modo de operação FDM, mas esse assunto n:\o scr.i tratado aqui. No infclo do q undro. " estaç.,o-basc primeiramente envia 1111111 rcl:1~\o de mensagens MAP ( l>rotocolo de ~tcesso de mfdia) de transmlss:\o informando :IS estações de assinan te das propriedades dr~ camada ffsíca (esq uema de mod ulaçilo, codificação c parâmetros para correção de erro) q ue scr;'lo utilizadas para transmitir rnjadas de pacotes subscquentcs dentro do q uadro. Pode haver múltiplas rajadas dentro de u111 quadro, c mti ltiplos pacotes dcm ro de uma rnj:1da dt-stin:ldos a um:~ dctermin:~da estação de assi nante. Todos os p;~co t es dentro da r;ljada são transmitidos pela cslacotc WiMAX MAC. O único campo que observamos aqui é do idcn tlncador de conexão no cabeçalho. O WiMi\X é uma mquitetura oricntad
~c:::S~~~~~~~~=~=~===~=~:::::::::::=:=:~~~~~~:-------:

11 Ê "'

X.

lil

i+

l

DL·MAP UL·MAP Rajada 1 Rajada 2 DL DL

~

1 Rajada n DL

tnitial., maint.

Conexao de solic.

l

i SS 11

ss 12

SSik

~---- Subquadro de Downlink -----t•+ l•e---- Subquadro de Uplink-----~ Figura 6.17

Estruturo de quodro802.1 6TOM

bow4tto4ic~ {opítulo 6

Redes sem fio e redes móuis I

o

EC

ESF

a

EKS

I

4 01

I

RSV Comprimento MSB (3)

Conexão 10 (MSB)

Comprimento LSB Conexão lO

HeaderCRC

(LSD)

carga útil 32·bit CRC

Figura 6.18

Pocote 802.16

avaliação de canal c c:nmpos de solicitação de admissão de conexão p
6.4 Acesso celular à Internet Na seção anterior ,rimos como um hospedeiro da Internet pode acessar a Internet quando estiver dentro de um hotspot Wi-Fi, isto t, quando estiver nas ''izinhanças de um pomo de acesso 802.11. Mas a área de cobertura da maioria dos hotspots Wi-Fi e pequena, entre 10 c 100 metros de diâmetro. O que fazer, então, <1uando precisamos desesperadamente ele mn acesso sem fio à Internet c não podemos acessar nenhum hotspot Wl-Fi? Dado que a telefonia celular agora está presente por toda a parte, em muitas áreas no mundo inteiro, uma estratégia natural é estender redes celulares de modo que suportem não somente telefonia de voz. mas também acesso sem Oo :I Internet. Idealmente, esse a~.:esso à Internet teria uma velocidade razoavelmente alta c proveria mobilidade Imperceptível c ininterrupta, permitindo que usuários mantivessem suas sessões TCP enquanto em trânsito, por exemplo, em um ônibus ou em um trem. Com taxas de bits suficientemente altas entre a fome c o usuário c vicC·\•crsa. o usuário poderia até mesmo manter sessões de vidcoconfcrC:nci:\ cnquamo em trânsito. Esse cenário n.io é assim tilo implausfvel. Quando cscre,1amos este 11\'l'o (Inicio de 2009), multas pro,•cdoras de telefonia celular ofereciam a seus assinantes um scr"iço de acesso celular ;'\ Internet por menos de 50 dólares mensais com taxas de btts entre a provcdom c o usuá.-ío c vicc·vCJ'S3 na f:uxa de algumas centenas de kilobits por segundo. Taxas de dados de \t;\.-íos mcgabits por segundo est;\o se tornando accssh•cis à medida que os serviços de dados de banda larga, como o HSDPA, são cada vez mais empregados.

Nesta seção, damos uma breve vis-lo geral das tecnologias de acesso celular à lnlernet já existentes e emergentes. Mais uma vez, aqui focalizaremos o primeiro salto sem fio entre o telefone celular e a infraestrutura de


rede de telefonia cabcada; na Seç<\o 6. 7 consideraremos corno chamadas s.'\o roteadas paro um usuário que está se movimentando entre csmções-basc. Nossa breve discussilo proverá, necessariamente, somente urna descrição simplificada c de alto nrvel de tecnologias celulares. É claro qu(' a questão das comunicações celulares modernas é de grondc amplitude c profundidade, c muitas universidades orcrccern dh•crsos cur..os sobre o assunto. O leitor que desejar um conhecimento mais prorundo da questão deve consultar [Goodman, 1997; Scourias, 1997; Kaaranen, 2001; Lin, 2001 : Korhoncn, 2003; Schiller. 2003: Scourias, 2007: Turner, 2009) , bem corno as referências paniculannentc excelentes c exaustivas em [~ouly. 1992).

6.4.1

Uma visão geral do arquitetura celular

Em noss.1 discuss.'\o sobre a arquitetura da rede celular nesta scç:\o, adotaremos a terminologia dos p:tdrõcs do Sistema G lobal p:m1 Comunkaçõcs Móveis (GSM). (Paro os amantes de história, a sigla GSM , originalmente, deri\•o u de Grou1>e Spécial Mobile, a té a forma angiicizada ser adotada, mantendo as letras in iciais originais.] Nos anos 1980, os europeus reconheceram a necessidade d e um sistema pan-europcu de telefo nia celu lar digital q ue su bstituiria os di\•crsos sistemas analógicos de telefonia celular inco mpatf,•eis, levando no IXId r:lo GSM [Moul)•, L992) . Os europeus lmpl:t111aram a tecnologia GSM com um grande sucesso no in feio elos ;mos I 990 c, desde ent:\o, o GSM cresceu c se tornou um gigante do mundo da teleronin celular, com mais de 80% de ass inantcs no mundo lllillzando essa tecnologia. Quando :~s pessoas ra lam sobre tecnologia celular, geralmente n classificam como pertencendo a uma das divcrs.1s · gerações". As gerações mais antigas [oram. basiC:tmcntc, projetadas pam o trMego de voz. Os sistemas de primeira gcmç-Jo (!G) eram sistemas FDMA analógicos desenvolvidos cspccialrncnte para a cornw1icação somente por voz. Esses sistemas lG quase não e>:istem mais, tendo sido substiturdos pelos sistemas 2G. Os sistemas originais 2G também foram projetados para voz, sendo estendidos, mais tarde, para suportar dados (por exemplo, a Internet), bem como o scn•iço de voz. Os sistemas 3G. que est:lo sendo implementados atualmente. também suportam voz e dados, mas com uma ênfase crescente em capactdades de dados c enlaces de acesso via rádio com ''cloctdad(' maior.

Arquitetura de rede celular, 2G: conexões por voz à rede telefõnico O termo celular refere-se ao fato de que u ma área geográfica é dividida em várias áreas de cobertura geográfica, conhecidas como células , ilustrado como hexágonos à esquerda da Figura 6 .19. Assim como estudamos o padn1o \Vi-Fi 802.11 na Seção 6.3.1, o GS~I possui sua nomenclatura cspccrfica. Cada célula contém u ma cstacàobase de transceptor (llTS) que tra nsmite sinais para, (' recebe sinais de, est:woes móveis dentro de sua célula. A área de cobertura de uma célu la depende de muitos fatores, incluindo pot~ncia da 13TS, pot~ncia de transmissi\o de aparelhos do usuário. da CSHlÇ:\0 móvel, obstáculos, como edifícios, na célu la, c altura das antenas da estaç-.\o·basc. Embora a Figuro 6. t 9 mostre c.td:~ célula com umn estaçM-basc de tra nsccptor posicionada no seu meio, hoje, mu itos sistemas posicionam a BTS em pontos de intcrscçào ele tres células. de modo que u ma 1inic.:a estacào-basc ~o m antenas direcionais possa ate nder a três célu las. O padrão GMS para sistemas celulares 2G utilizam FOMfrOM (rádio) para a interface ar. lembre-se de que no Capitulo 1. com FDM puro. o canal é dividido em um numero de bandas de frcq ui:nela. sendo que cada banda se dcdka a uma chamada. Lembre-se também de que. no Capftulo l , com FOM puro, o tempo é dividido em quadros. sendo cad:1quadro dividido em ínlen':llos c mda c:h;um1da sendo destinada ao uso de um Intervalo especifico no quadro rotativo. Nos sistemas combinados FDMffDM. o canal é dividido em um número de sub-bandas de rrequfncia; dentro de cada sub-banda, o tempo c dh•idido em quadros c intervalos. Desse modo, para um sistema combinado FDM!rDM. se o canal ror dividido em f sub-bandas c o tempo em T inten':llos, cntàO o canal podem suportar chamadas simultâneas F-T.

Os sistemas GS:O.I consistem em bandas de frcquencia de 200-kHz c cada banda suporta oito chamadas TD:VI. O GSM codifica a voz a 13 kbps c 12,2 kbps. Um padrão concorrente do GSM, o IS-95 COMA c seu sucessor COMA 2000, u tiliza o acesso muhiplo de divisão de código (consulte Seção 6.2.1) c não a abordagem combinada FDMITDM, tornand o os telefones dos usuários GSM inoperantes em uma rede IS-95 e vice-versa.

bow4tto4ic~ { opítulo 6


Rede telef6nt~

púbiiC" ROte.ldOt MSC

( .)

Controlador de estaç.\o-baie

(.)

Centra l ele Comut~ao de Unid&cle M óvel

Slstem.t de estCI(Jio·base

Figura 6.19

Componentes do OlQUilelulO de rede cefulo, 2G GSM

Um controlador de esLaçüo-basc (BSC) da rede GSM pode estar fisicamente s ituado com uma BTS, mas. nor· malmente. uma ünica BSC prestará servico a dezenas de est;lçOcs-basc do trascepto r. O papel da BSC é alocar os cana1s de rádio da BTS a assinan tes mO,•eiS, realizar pt1g111g (encontrar a célula na qual res1de um usuário mó,•el) c realizar transfer~ ncia d e usuários móveis - um assunto q ue abordaremos, em poucas pal:wras, na Seção 6.7.2. O controlador de estaç:lo-basc c s uas estações-base d e transccptor, coleti vamente, constituem um sisu:ma d e estaç:,o-basc (BSS) GSM. Como veremos na Scçilo 9.7, a central de comutação de unidade móvel (MSC) interpreta o papel central na cont:1bilidadc c :IUtoriza~~lo do us uário (por exemplo, deternúnar ~ um ap;trclho móvel permitiu a conexão à rl.'dc celular). estabclecimcmo e interrupção de chamada, c transferf ncías. Normalmente, uma única MSC comerá até cinco BSCs, resultando em aproximadamentE' 200K assinantes por MSC. Uma rede de provedor celular terá um mimcro de MSCs, possui ndo MSCs especiais conhecidas como roteadores das MSCs, eonect:mdo a rede de provedor celular à mmor rede telefônica pública.

Arquitetura de rede celular, 2,56 e 3G: estendendo o Internet poro assinantes celulares Até agora, nossa discussão se focou em conectar ustulrlos de voz celular i\ rede tctero nlca publica. Os usuários móveis estão cada vez mais acessando a Internet aLravês da rede celular por meio de IPhones. Bl<~ckberrics, laptops c mais. Uma maneira de faz~-l o, usando somente a infraestrutura 2G mostrada na Figura 6.19, é utilizar uma conexão telefônica cel ular. como uma concx•lo de discagem para um ISP, assim como muitos usu

,

-,'-'--)-

Rede telefõnic.l pública

Roteador

MSC

Internet púbtic<1 legenda:

SGSN 54wv•clor do NO de SUllOf~ GPI\S (SGSN)

GGSN

fl
GGSN(GGSM

Figura 6.20 AlquileiiJro de rede de dado evoz celulm 2,56 GSM n úc leo da rc:
384 kbps para uso cstacio n:\rio em ambiente externo ou velocidades de ql1cm and:1 a pt. 2 Mbps em ambiemc interno. O Serviço Uni\•ersal ele Telecomunicar;ões Móveis (UMTS), urna das tecnologias 3G mais con hecidas, é uma evolução do 2,5G GSM para suportar as t-apacid:~des 3G. A arquitetura da rede UMTS apropria-se cxp ressiv~unen te ela arquitetum da rede GSM est:~belecida. Ela deixa, esl>ecificamente, as redes de dados 2,5G de voz celular existentes rm Figura 6.20 em funcionamento, assim como :1 rede 2,5G o fez com :1s redes existentes. Uma mud:mça signil'icativa no UMTS é que, em vez de usar o rnttodo FDMNTDMA do GSM. o UMTS utiliza uma técnica COl\-iA denominada Dirrct Sequcncr \Vidtband COMA (CD}.1A de banda larga de sequência direta) (05-WCDMA) dentro de in ten-alos TOMA (com quadros de intcn'lllos de TOMA acessí,•cis em frcqu~nc•as mtlhiplas- uma milizaÇllo interessante de todos os m~todos de compartilhamento de canal q ue identincarnos anteriormente!). Essa mudan· ça exige uma n0\'3 rede celular de acesso sem fio operando pamlclamcm e com a rede 8SS mostrada na Figura 6.20. O serviço de dados associado à espccificaç-Jo do WCDMA é conhecido como HSDPt\/HSUPA (Pacote de Acesso de Alta Velocidade Downlin k!Uplínk) e promete taxas de dados de até 14 Mbps. Mais detalhes referentes às redes 3G podem ser encontrados no site do Projeto de Parceria da 3• GeraÇão (3GPP) [3GPP, 2009).

bow4tto4ic~ Copilulo 6


Celular móvel 36 versus lANS sem fio Muitos operadoras de telefonia celular móvel estão disponibilizando sistemas celulares móveis 3G, com taxas de dados de 2 Mbps em ambiente fechado e 384 kbps, ou maior, ao ar livre. Os sistemas 3G estão sendo disponibilizados em faixas licenciados de rodiofrequênc;io, sendo que o preço que algumas operada. ros pagam aos governos pelo licença é uma quantia considerável. Os sistemas 3G permitirão que os usuários acessem o Internet o partir de localizações remotos externos enquanto em trânsito, de modo semelhante ao acesso o telefones celulares existente hoje. Por exemplo, o tecnologia 3G permitirá que um usuário acesse informações sobre estrados enquanto dirige, ou informações sobre o programação de cinema enquanto estiver tomando sol no praia. Não obstante, hoje muitos especialistas estão começando o questionar se o tecnologia 3G teró suceuo, dados o seu custo e o concorrência do tecnologia de IAN sem fio. Em particular, esses espociolistos argumentam que: • A ir~froestru turo emerger~te de IAN sem fio logo se tornará quase ubíquo. As IANs sem fio IEEE 802.11, que operam o taxas do 54 Mbps, estão sendo amplamente disponibilizados. Quase todos os computadores portótei$ e PDAS jó virão elo fóbrlco equipados com plocos ele IAN 802.11. Além disso, os novidades em equipamentos de Internet - como cãmeros sem fio e molduras poro fotografias - também usarão pequenos placas de lAN sem fio de baixo potência. • O WIMAX, que estudamos no Seção 6 .3.6, promete serviços de dados em amplos óreos o usuários móveis de v6rios megobits por segundo ou mais. A Sprint Nextel estó fazendo um investimento multibllionório no implementação do WiMAX. • Estações-base de IANs sem fio também podem manipular equipamentos de telefonia móvel. Os h!turos te~ fones podem ser capazes de se conectar ou o uma rede de telefonia celular ou o uma redo IP utilizando o serviço voz sobre IP semelhante ao Skype, ultropouondo, assim, os serviços de dados 3G e de voz celular do operadora ~ cloro que muitos outros especialistas ochom que o tecnologia 3G não somente será o maior sucesso, mos também revolucionará drasticamente o modo como trabalhamos e vivemos. ~ cloro que ambos, Wi·fi e 3G, podem se tornar tecnologias sem fio dominantes, com equipamentos sem fio em trânsito que selecionam automa ticamente o tecnologia de acesso que prové o melhor serviço em suo localização físico corrente. Até junho de 2007, 200 mil hõcs de assinantes 3G est~wam conectados. Isso é somente 6, 7% dos tr~ bilhões de assimuucs mundiais da telefonia móvel. Nos países onde o 3G chegou primeiro -Japão c Corela do Sul mais d:t metade de todos os :1ssinamcs usa a tecnologia 3G. Na Europa. o (J:tfs que lidera é a Itália, com um terço de assin:uu cs 3G. Outros países que lideram s:lo o Reino Unido, Áustria, Ausmllla c Cinga pura. Com :1 criaç;i.o c lmplemcntaçM de várias gerações de cstxciOcac;õcs 3G :1 c-.unmho, :1 tecnologia 4G sem no pode l'ic:1r pam trás? A rcspost:l ~ t;lnto sim como n;io. Não existe uma del'inl~·ào formal sobre como scr.i.o os sistemas 4G, c mesmo que hnja fornecedores produzindo equipamemo (por exemplo, WiMAX), isso já excede o desempenho dos sistemas 3G. Certamente, no momento em que os sistemas 4G forem dcl'inidos c implcmcn· tados. eles opcmr-Jo a velocidades mais altas do que os sis temas 3G. alcançando l Gbps ou mais: protocolos da Internet mais Integrados: c tendem a se focar em serviços de localização. multimídia c segurança.

6.S Gerenciamento da mobilidade: princípios Após estudarmos a naturrza sfm fio dos enlaces de comunicação em uma rede sem no, é hora de voltarmos nossa atcnçao à mobilidade que esses enlaces sem fio possibilitam. No sentido mais amplo, um nó mó"cl taquele que muda seu ponto de conexão com a rede ao longo do tempo. Como o termo mobilidade adquiriu muitos

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------sigrtificados no mundo da computaç;\o e tamb~ no mundo da telefonia, será proveitoso, ames de mais nada, considerar diversas dimensões da mobilidade com um ceno detalhe.

Do IJonto tlr vrsta dtr carmrda tlc rn/c, crtt' qui" ponto um usuário t IIIÓ\ d? Um usuário fisicamente móvel aprcscm:mi à camada de rede conj untos de desafios muito diferentes dependendo de como ele se movimenta entre pontos de conexão com a rede. Em uma extremidade do espectro na Figura 6.21 , um usuário pode carregar consigo um laptop eq uipado com uma placa de interface de rede sem fio dentro de um edrffcio. Como vimos na Seção 6.3.4. esse usuário ncio é mó,•el da perspectiva da camada de rede. Além do mais, se o usuário se associar com o mesmo I>On to de acesso independentemente de localizaç.lo, então ele não será móvel nem mesmo do ponto de vista da camada de enlace. Na outra extremidade do espectro, considere o usuário que está d entro de um DMW, correndo pela estrada a 150 quiiOmetros por hora, passando por várias red es de acesso sem no e querendo rnamer uma concxOntos de concxilo com a rede. A Figum 6.21 ihlStra esse espectro d e mobilidade do usuário da pcrspectlvn d:~ c;lmada de rede.

Qual ~ cr illlllOrlllucicr de o endereço do nó móvel permwrecrr sempre o mesmo? Com teldonia móvel, o numero de: seu tc:lcfonc- csscncíalmcmc o endereço de camada de: rede do seu aparel ho - permanece o mesmo quando \'OCf transita entre uma provedora de rede de telefonia móvel c outra. Um laptop também tem de mamer o mesmo endereço IP enquamo se movimenta emrc redes lP? A resposta :1 essa perguma dependerá mui lo da aplicação que está sendo executada. Para o motorista da BMW que quer manter urna conexão TCP ininterrupta com uma aplica(,'ào remota enquanto \'Oa pela estrada, seria com•eniente manter o mesmo endereço IP. Lembre-se de que dissemos, no Capitulo 3. que uma aplicaç;lo de Internet precisa conhecer o endereço IP c o numero de porta da entidade remota com a qual está se comunicando. Se uma entidade móvel puder manter seu endereço IP enquanto cstl\er em trânsito, a mobilidade torna-se invisível do ponto de vista da aplicaç:lo. Essa 1ransparéncia é de grande valor - urna aplicação não prec1sa se preocupar com urna potencial mudança de endereço IP c o mesmo códtgo de aplicaÇ'Jo servirá igualmente a concxOcs mó\'Crs c não móveis. Na próxima seção veremos que o IP móvel prov~ essa transp;u
Nenhuma mobilidade

UsuArio se movimenta apenas dentro da mesma rede de acesso sem fio

Figura 6.21

Alta mobilidade

Usuário se movimenta entre redes de acesso. en
Vórios graus de mobilidode do ponto de visto do comodo de rede

Usu~rio se movimenta entre redes de ac:esso mantendo conexões em curso



407

Qrwl t a infwtsuurura ce~becula ele suporte clisponh•d? Em todos os quatro cenários descritos, admitimos unplicitamcntc que existe uma inCraestnnura rixa à qual o usuário móvel pode se conectar, por exemplo, a rede ISP à qual a residl!ncia está ligada. a rede de acesso sem no no loc:tl de trabalho ou as redes de acesso sem rio ao longo da rodovia. E se tal inrraesLrutura n:lo existir? Se doi:. usuários estiverem a uma distl\ncia q ue permita comunicaç-lo, eles podcr.lo estabelecer uma conexão de rede na ausênCia de qualquer outra inrraestrutura de camada de rede? As redes ad hoc pro,•ecm exaLameme essas capacidades. Essa :irca, que está em mpido dcscn,·olvuncnto e representa a pcsquis.1 de ponta em redes mó,•crs, está al~m do escopo deste lh•ro. IPcrkins, 2000] c as pági nas Wcb do grupo de trab:~lho Mobile Ad Hcx: Nctwork (mnnct) d a IETF apresentam um trnt:~mcnto completo do assunto. Para ilus trnr as questões que crwolvem perm itir que um usuário mantenha conexões em curso enq uam o se movi menta entre redes, vamos considerar uma analogia com seres humanos. Um adulto de 20 c poucos anos que sai d<'l cas:1 de seus plliS torna·se móvel, pois passa :a morar em uma séri e de quartos e/ou apartamentos c está sempre mudando de endereço. Se uma vel ha am iga quiser entrar em contato com ele, como conseguirá encontrar o endereço de se u amigo móvel? Uma maneira comum de razer isso é entrar em comato com a famflia, já que um jovem móvel costuma inforntar seus novos endereços :'1 f redes nati vas possivelmente seriam as redes das e mpresas em que trnbalham, enquanto a rede visitada poderia ser a rede de um colega que est<\0 \'iSitando. Um correspondente é a entidade que quer se comuni car com o nó mó,rel. A Figura 6.22 ílustra esses conceitos. bem como conceitos de endereçamento considerados mais adiante. Observe que. na Figura 6.22, os agentes silo colocados junto aos roteadores (por exemplo, co rno processos que funcionam em rott~dores), mas, ahernatívmncnte, poderiam estar fun ciommdo em o utros hospcdcíros ou servidores na rede.

6.5.1

Endereçamento

Já o bservamos que, pam que a mobilidade do usuário seja transpare nte p:~rn aplicações ele rede, é desejável que um nó móvel mantenha seu endereço quando transita de uma rede para outra. Quando um n ó m óvel res idir em uma rede ex terna, todo o tráfego enviado ao endereço permanente do nó agora precisará ser roteado parn a rede externa. Como isso pode ser reito? Uma opção é a rede ex terna anunciar para todas as outras redes que o nó móvel agora reside em sua rede. o que podería ser feito mediante a costumei ra Lroea de inrormações de roteamento intcrdomrnios c intradomínios c exigiria poucas mudanças na in[raestrutura de roteamento existente. A rede externa poderia simplesmente anunciar a seus vizinhos que tem uma rota a ltame nte especifica para o endereço permanente do nó m óvel (isto é, essencialmente, informar a o utras redes que ela tem o <:aminho correto para rotear datagramas para o endereço pern1anente d o nó móvel; ver Seção 4.4). Esses vizinhos então propagariam essa infonnação de roteamento por toda a rede como parte d o procedimento nonnnl de atualizaçAo d e infonnações de roteamento e tabelas de repasse. Quando o nó móvel sair de urna rede externa e se juntar a uma outra, a nova rede externa anunciaria uma nova rota, altamente específica, até o nó móvel c a antiga rede externa retiraria suas informações referentes ao nó móveL


Rede visit ada: 79.129.13124

Rede nat iva: 128. 119.40124

Nó móvel

Endereço permanente: 128.119.40. 186

Endereço aos cuidados de (COA) (ou endereço administrado) 79.129. 13.2 Agent e externo

~

Agente nat ivo Rede de longa d istância

Correspondente

rtgura 6.22 Bementos ini
Agora ,~Jmos conside~u o agente externo com mais dcllllhcs. A abordagem conceitualmcme mais simples. mostrada na Figura 6.22. é localizar agentes externos nos ro teadores de borda na rede externa. Um dos papéis do agente ex terno~ criar o denominado en dereço aos cuida dos d e (carc·of-aclllrcss- COA) o u endereço ad minls· tra do para o nó móvel, sendo que a parte da rede do endereço COA combinaria com a parte da rede do endereço da rede exu~rna . Assim, ha dois endereços associados com u m nó móvel, seu endereço permanente (análogo 110 endereço da famllia d o nosso jovem mó,·cl) e seu endere~o COA, às vezes den ommado endereço externo (análogo ao endereço da casa onde nosso jovem mó"el está residi ndo at ualmente). No exemplo da Ftgura 6.22, o endereço permanente do nó móvel é 128. 119.40.186. Quando cst:\ visitando a rede 79.129. 13/24, o nó móvel tem um COA 79.129. 13.2. Um segundo papel desempenhado pelo agente externo~ informar ao agente nath·o que o nó móvel está resi d indo em sua rede (do ageme externo) e tem o dado endereço COA. Veremos, em breve, que o COA pode ser utilizado para 'rerrotear' da1agramas para o nó móvel via seu agen1e externo.

bow4tto4ic~ ( opífulo 6

Redu sem fio e redes mónis

Em bom tenhamos separndo a funcionalidade do nó móvel c o agente externo, \':li e a pena observar que o nó móvel também pode assumir a responsabilidade do ageme externo. Por exemplo, o nó móvel poderia obter um COA na rede externa (por exemplo, utilizando um protocolo como o DHCP) c ele mesmo mformar seu COA ao agente nativo.

6.5.2 Roteamento poro um nó móvel Agorn já vimos como um nó móvel obtém um COA c como é possível inrorrnar esse endereço ao agemc nativo. Mas conscguar que o agente nativo con heça o COA resoh•e apenas parte do problema. Como datagramas devem ser enderc\'ados c rep:assados parn o nó móvel? Visto que somente o agente nativo (c n:lo os roteadores no ;1mbito to ta l da rede) conhece a localiz:lç:lo do nó móvel, já n:\o será mais suficiente simplesmente endereçar um datagrama para o endereço permanente do nó móvel c cm•iá-lo para a infraestrutura de camada de rede. Ê preciso fazer algo mais. Duas abordagens podem ser identificadas, as quais de no minaremos roteameniO indireto c roteamento di reto.

Roteamento indireto paro um nó móvel Vamos consldcmr primeira mente um correspondente que quer enviar \1111 d:uagmma a um nó móvel. Na abordagem de roteamento indireto o correspondente simplesmente endereça o datagrama ao endereço permanente do nó mó,•cl, envia o datagrnma pam a rede c fica alegremente inconsciente quan to ao nó móvel residir em sua rede nativa ou es tar visitando uma rede externa; assim, a mobilid;~dc é completamen te transparente parJ o corrcspondcnu~. Esses dat;~gmmas são pnmcíramentc roteados, como sempre, pam a rede local do nó móvel. Isso é ilustrado na etapa 1 da Figurn 6 .23. Agorn vamos voltar nossa atenÇão ao agcmc nativo. Altm de ser respons.1vcl por intemgir com um agente

ex temo para monitorar o COA do nó móvel. o agente nativo tem uma outm funçJo muito importante. Sua segunda

Rede visitada: 79.129.13/24

Rede nativa: 128.119.40124

Nó móvel

Endereço permanente: 128.119.40.186

Endereço permane~~~ ~

128. 1 19.40.~

[0 Agente nativo

Rede de longa distAnda

Correspondente

figuro 6.23 Repasse indiretoporo umnó móvel

-

>< )-Endereço aos cu idados de (COA) (ou endere~o administrado): Agente 79.129. 13.2 externo

bow4tto4ic~ Redes de com putod ores e o Inle roe~'------------------------tarefa é ficar i\ cspreiL:l de datagr:unas que dwg:un e são endereçados a nós cuja rede n:uiva é a rede do agenre nativo. mas que cst:\o corrememcmc residindo em uma rede externa. O agente nativo imcrcepta esses datagr-amas e cnu\o os repassa a um nó móvel por um proctSSO de duas empas. Primcimmeme o damgmma é reJY.tSSndo pam o agente ex temo usando o COA do nó móvel (etapa 2 na Figuro 6.23) c cnt:\o é rcp:lSS3do do agcmc externo pam o nó móvel (etapa 3 na Figura 6.23). Ê instrutivo considerar esse rerroteamento com mais detalhes. O agente nauvo precisará endereçar o datagrama usando o COA do nó móvel. de modo que a camada de rede rotcará o datagrama para a rede externa. Por outro l ;~do, é desejável d eixar intacto o datagmma do correspondente, visto que a aplicaç-Jo que recebe o druagmma deve ficar inconscien te de q ue o datagrama foi repassado por meio do agente nativo. Ambas as metas podem ser cumpridas fazendo com que o agente n~ui vo encaps ule o dmagrama original completo do corrcspondcmc dentro de um novo (e maior) damgrama. Esse datagrama maior é endereçado c emrcguc ao COA do nó móvel. O agen te cxtcmo ' proprietário' do COA receberá c dcscncapsulará o d:nagrama, isto é, removerá o da tagrama o ri gi nal do correspo ndente de d entro daquele datagrama maior d e encapsulamento e repassará o dat~grama original (etapa 3 ria Figura 6 .23) para o 116 móvel. A Figura 6.24 mostra um d:uagrama orig inal de um correspondente sendo cnvtado pam a rede local, Ltnl d(H<~gmmu cr1capsulado sendo enviado ao agente ex terno c o datagrama orig inal sendo cntl'cguc ao nó móvel. O leitor observador notará que o cncapsulamc ntoldcscncaps ulamcnto d escrilo aqui é ídt nt ico à noção de implementação de ttí ncl discutida no Capítulo 4 no con texto do IP mu/ticnst c do 1Pv6.

A seguir. vamos consider:tr como um nó móvel cnvi3 datagmm
rede externa. De modo semelhante, um nó móvel C\Jlcelará seu registro no agente externo quando sair da rede externa. destino: 79.129.13.2 Endereço permanente : 128.119.40.186

destino: 128.119.40.186 Endl!feço permanente: ~~ 128.119.40.186

I

EJ\der~o &OS cui~dOs do (COA)

~

~-..;::::!:......--

(ou enderc~o adminíSirado): ___ 79.129. 13.2 ......

I /.. ><

Agente

elite rno

destino: 128. 119.40.186 destino: 128.119.40.186

Correspondente

Figura 6.24 Encapsulamento e desencopsulomento


Redes sem fio e redes móveis

411

Um p101Molo dt registro agtme exumo-agente na1i1•o. O agente ex terno rcgismm\ o COA do nó mó1·cl no agcme nativo. Um agcme externo não precisa cancelar expllcit:unemc um COA quando um nó móvel sa1 da rede porque o registro subscquentc de um no1•o COA se encarregam d1sso quando o nó móvel passar para uma nova rede. Um p101Molo ele rncapsulamtmo clt clawgrarmr para o agentt ncuivo. Encapsulamento c repasse do dalõ\grama original do correspondcm c dentro de um datagrama endereçado ao COA. Um protocolo ele clrsc:nwpsulcunmlo clr dcrtCigmmCI pnm o ccgcntc a1m1o. ExtraçM do datagmma original do correspondente de dentro do datagrama de encapsulamento c repasse do dmagrama original ao nó móvel.

A discussâo anterior prov~ todas as peças - agentes exu~mos , agente naLii'O c roteamen to indireto- de que um nó móvel necessita para manter uma <..'Onexilo em curso enquanto transita entre redes. Como um exemplo de como essas peças se encaixam, admita que o nó móvel está ligado à rede externa A, registrou um COA no agente local na rede ;\ c está recebendo dmagramas que estão sendo roteados indiretamente por meio de seu agcme nativo. O nó mól'cl agora passa para a rede externa B c se rcgísLra no agente externo na rede B, que informa ao agente n:llivo o novo COA do nó móvel. Desse pomo em diamc, o agemc nativo rcrrotcar:t d:~tagramas para a rede cxtcrnn B. No que diz respeito ao corresponden t e,:~ mobilidade t trans(>arente- datagramas silo rot~ldos por meio do mes mo agcmc natii'O antes e depois de o nó móvel mud:1r de rede. No q ue diz respeito ao agente nat ivo, n:\o h:l nenhuma disrupçilo no Ouxo de datagramas- datagramas que chegam s:lo primcimmcnte repassados para a rede externa A; npós a mudança no COA. damgmmas s;\o rcpass;1dos parn a rede externa B. Mas o nó móvel verá um Ouxo ininterrupto de datagramas ao se movimentar entre redes? Contanto que seja pequeno o tempo transcorrido entre o desligamento do nó móvel da rede A (pon to em que ele ni\o pode mais receber datagrama.s 1•ia A) c sua concx•lo com a rede J3 (ponto em que rcgisti"Jr<\ um novo COA no agente nativo da rede). poucos datagramas serão perdidos. Lembre-se de que dissemos, no Capitulo 3. que conexões fim-a-fim podem sofrer pcrdn de dntagramns devido a congestionamento na rede. Por conseguinte, a perda ocaslonnl de d:~mgrnma.s demro de uma conex:\o quando um nó se move entre redes não é, de mane1ra alguma, um problema catastrófico. Se for preciso uma comunicação livre de perdas. mecanismos de camadas superiores rceupcran\o a perda de dado , quer essas pcrdns resultem do congestionamento da rede ou da mobilidade do usu.trio. Uma abordagem indireta de roteamento é utilizada no padnlo IP móvel IRFC 33'141. como discutiremos n:1 Seção 6.6.

Roteamento direto para um nó móvel A abordagem do roteamento indireto ilustrada na Figura 6.23 sofre de uma lneficl~ncia conhecida como problema d o ro teamento tria ngu lar - datagramas endere-çados ao nó móvel devem ser roteados primciramcme para o ageme 11:1tivo c em seguida para a rede externa, mesmo quando exis tir uma rota muito mais eficiente entre o correspondente c o nó móvel. No pior caso, imagine um usuário móvel que está visilando a rede externa de um colega. Os dois cs t:lo sen t:~dos l~•do <1 lado c tro,
Conquamo supere o problema do roteamento triangular. o roteamento direto mtroduz dois imponantcs desafios adicionais:


Rede visitada: 79.129.13124

Rede nativa: 128. 119.40124

Nó móvel 1

Endereço permanente: 128. 119.40.186

Endereço permanente: 128. 119.40.186

/

:r=-

1%

rx~ Endereço aos cuidados de (COA)

Agente nativo

Red~ de longa dinànda

~ (ou endere~o administ rado): Agente 79.129.13.2 externo

Correspondente Legenda: Controle de ~nsagens

- + Fluxo de ct.dos

ftgura 6.2S

Roteamento direto poro um usuório móvel

!: preciso um prot ocolo de localizaçã o de usuá rio móvcl para o agente correspondente consultar o agente nativo de modo a obter o COA do nó móvel (etapas 1 c 2 da Figura 6.25). Quando o nó móvel passa de uma rede externa para outra. como os dados são repassados, agora. para a nova rede externa? No caso do roteamento indireto. esse problema era facilmeme resolvido atualizando-se o COA mantido pelo agente nativo. Todavia, com roteamento direto, o agente correspondente consulta o COA junto ao agente nativo apenas LUlla vez, no infcto da sess.\o. A~irn , atualizar o COA do agente nativo, embora rlecess:1.rio, n:\o será suficiente para resolver o problema do roteamento de dados para a nova rede ex terna do nó móvel. Uma soluçilo se ria cri:tr um no\'0 protocolo para notificar a mudança de COA ao co rrespondente. Uma solu1,.~\o al ternat i\•a, que, co mo veremos. é adotada na prática em redes GSM , funciona da seguime m:meira: suponha

que estilo sendo repass."Jdos dados correntemente para o nó móvel na red e externa onde ele esuwa localizado quando a sessão foi iniciada (e tapa I na Figura 6.26). O agente externo naquela rede externa o nde o nó móvel foi cucorHmdo pela prirncin1 vez será denominado agente externo â nco ra. Quando o nó móvel p:1.ssar para uma nova rede externa (etapa 2 rm Figura 6.26), ele se regis trar:! jumo ao novo agcmc externo (etapa 3) c esse novo agente externo fornecer:! ao agente externo :incora o novo COA do nó móvel (etapa '1). Q uando o agente externo âncora receber um datagramn encapsulado para um nó móvel que já dcrxou a rede, ele ent:lo podem reeneapsular o daragrama c repassá· lo para o nó móvel (etapa 5) usand o o novo COA. Se, mais tarde, o nó móvel pass:tr para mais uma outra rede ex rcrna, o agente externo nessa n ova rede visitada então contatará o agente externo âncora para estabelecer repasse para essa nova rede externa.

6.6 IP móvel A arquitetura e os protocolos da Internet para suporte de mobilidade, conhecid os coletivamente como IP móvel, estão definidos primariamente no RFC 3344 para 1Pv4. O IP móvel é um protocolo flexível que suporta



Rede externa visitada no inicio da sessio

Rede nativa

~te

Rede de longa distânda

0

Agente nativo

/

~~~~~no _, ancora

0 ®

Nova rede externa

~Agente

"'-'correspondente Correspondente

Novo agente externo

Figura 6.26 Tumfetên
externo para anunciar seus sen•iços a nós móveis c protocolos para que os nós móveis solicitem os serv1ços de u m agente externo ou nativo. Registro 110 agrni•• 11mlvo. O IP móvel define os protocolos usados pelo nó móvel e/ou ageme externo para registrar c anu lar os registros de COAs no agente local de um nó móvel.

Rolc
Descoberto de agente Um nó IP móvel que esta chegando a uma nova rede, quer esteja se conectando a uma rede externa ou retornando à sua rede nativa, tem de aprender a identidade do correspondente externo o u do agente nativo. Realmente, é a descoberta de um novo agente externo, com um novo endereço de rede, que permite que a camada


d e rede ern um nó móvel aprenda que ele passou para uma nova rede externa. Esse processo ~conhecido como d escobert a de agente. A descoberta de agente pode ser realizada de duas maneiras: via anuncio de agem e ou via sohcitaçào de agente. No caso do anúncio de agen te, um agente externo ou nativo anuncia seus serv1ços usando u ma extens:' o d o protocolo de descobena d e roteador existente IRFC 12561. O agente faz brocrdCllst peri ódico de uma mensagem ICMP tendo 9 no campo de tipo (d escoberta de roteador) em todos os enlaces aos q uais está conectado. A mensagem de descoberta de roteador contém o endereço IP do ro teador {isto é. o agente). o que permite q ue u m nó móvel aprenda o endereço IP do age nte. A mensagem de descoberta de rotead or tambtm contc!m uma extensão de anu ncio de agente de mobilidade que contem inforn1açõcs adicionais de que o nó móvel necessita. Entre os campos mais im port antes na extens ão esti\0 os seguintes: lJit tio trge11tc 11111ivo (H). Indica que o agente é um ageme nath•o para a rede na qual reside. l3il

c/c agente extcm o ( F) . Indica que o agem c é um agente externo par3 :1 rede na qual reside.

lJit tlc n:gisll o obrlgatório (R). Indica que um us uário móvel nessa rede eleve se reg1stra r em um agente externo. Em rxrrticttlar, um usu:\rio móvel não pode obter um endereço admi nistrado na rede externa ( por exemplo, us;mdo DHCP) e assumir a funci onalidade d e agente externo p:rra si mesmo sem se registrar no agc me externo. lJirs ele rncapsulcrmcnro M, G. lnd1cam se será cn<::lpsula memo IP em IP.

utlliz:~da

un1:1 rorma de encapsulamctllO que não seja o

Campos tlc cudereços administrados (COA). Uma lista de um ou mais endereços administrados fornecida pelo agente externo. No exemplo logo a seguir, o COA estará associado com o agente externo. que receberá datagramas env1ados ao COA c então os repassa rá para o nó móvel adequado. O usuário móvel selecionará um dcsscs endereços como seu COA ao se registrar no seu :1gente nativo. A Ftgura 6.27 tl ustra alguns d os pri ncipais campos na mensagem de anú nc1o de agente. Com solicitação de agente. u m nó móvel que quer conhecer :•gentes sem esperar para receber um anú ncio de agente pode em111r u ma mens:tgem de solicitação d e agente em brocrdcast , q ue é, simplesmente, uma mensagem ICMP cujo valor de tipo é l O. Ao receb('r a solicitar;ao. um agente emite um anuncio unicast de age nte diretam('nte ao nó móvel. q ue, en111o. procederá como se tivesse recebido um anúncio não sohcitado.

o

8 Tipo= 9

Código =0

Endere~o

Tipo " 16

24

16

Comprimento

Tempo de vida de regiwo

Soma de veri ficação

campos ICMP padronizados

do roteador

Número de sequência RSHFMGrT bits

O ou mais endereços admínimados

Reservado Extensão d e anúncio de agente d e mobilidade

Figura 6.27 Mensagem ICMP de descoberto de roteador com extensão de anúncio de agentede mobilidade


Redes sem fio e redes móveis

415

Registro no ogente nativo T:'lo logo um nó móvel I P tenha recebido um COA. esse endereço deve ser rcgtstrado no agente nmivo, o que pode ser feito via o agente externo (que, então, registra o COA no agente nauvo) ou dtrctamente pelo próprio nó móvel IP. A seguir. consideramos o primeiro caso. Há quatro etapas envolvidas. 1.

ApóS o recebimento de um ttntlncio de agente externo, um nó mó,cl envia uma mensagem de registro IP móvel ao agcme externo. A mensagem de registro é carregada dentro de um datagrama UDP c enviada à porta 434. A mensagem leva um COA anunciado pelo agente externo. o endereço do agente nativo (HA). o endereço pcnmmcntc do nó móvel (MA), o tempo de vida de registro requerido c uma identificação de registro de ó4 bitS. O tempo de vida de registro requerido é o numero de segundos dura me os quais o registro sem ''áhdo. Se o registro m1o for renovado no agemc nativo demro do tempo de vida especificado, ele se tornam inv:llido. O identificador de registro age como um niunero de scquencia c serve para eombinnr uma resposta de regist ro recebida com uma solicitação de registro, como discutiremos mais adiante.

2.

O agente externo recebe a mertSagem de registro c registra o endereço IP permanente do nó móvel. Agora o agen te externo snbc que deve procurar datagromas que cotucnha m um datagrama encapsulado Cl~O endereço de destino combine t:om o endereço permanente do 11 6 móvel. O agente externo então envia um:1 mensagem de registro IP móvel (novamente dentro de um clatngrama UDP) à porta 434 do agente nativo. A mensagem com~m o COA. o HA, o MA, o ror mato de encapsulamento requisitado, o tempo de vida de registro requisitado e a idcntificaç;\o do registro.

3.

O agente nativo recebe a rcquisiç~o de registro c verifica sua autcruiddadc c correção. O agente nativo vincula o endereço IP permanente do nó móvel ao COA; no futuro , d:uagmmas que chegarem ao agente nativo c endereçados ao nó móvel serão encapsulados e enviados por LUncl até o COA. O agente nativo envia urna resposta de registro lP móvel contendo o HA. o MA, o tempo de vida de registro vigente c a tdenufica~'
4.

O agente externo recebe a resposta de registro e então a repassa ao nó móvel.

'esse ponto o registro está condufdo c o nó móvel pode receber datagramas enviados :1 seu endereço permanente. A Figura 6.28 ilustra essas etapas. Note que o agente nativo especifica um tempo de vida menor do que o tempo de vida requtsitado pelo nó móvel. Um agente externo não precis.1 anular explicitamente um registro de COA quando um nó móvel sai da rede. Isso ocorrerá automaucamcntc quando o nó mó,·el pass.1r para uma no,·a rede (seja uma outra rede externa, sejtt sua rede nati,•a) c registrar um novo COJ\ . O padnio IP móvel permite muitos cenários c capacidades adicionais além das que acabamos de descrever. O leitor illleressado deve consultar [Perkins. 1998b: RFC 3344).

6.7 Gerenciamento de mobilidade em redes celulares Agora que at-:1bamos de examinar como a mobíliclade é gerenciada em redes IP, vamos voltar nossa ateru;:io a redes cujo histórico de suporte~ mobilidade é ainda mais longo - redes de teldom::. celular. Enquanto na Ser;no 6.4 roa~lizamos o enlace sem no do primeiro sal to em redes celulares , aq ui focalizaremos a mobilidade utilizando a arquitclllra GSM de rede cclul:lr IGoodman, 1997; Mouly, 1992; Scourias, 1997; Kaarnncn 200 I; Korhoncn, 2003; Turner, 20091 como objeto de nosso estudo, visto que é um:~ tecnologia madum c amplamente disponibilizada. Como no caso elo IP móvel. veremos que vários dos princípios fundamentaiS que identificamos da Scçdo 6.5 est:lo incorporados à arquitetura de rede do GSM. Do mesmo modo que o IP móvel, o GSM ttdota uma abordagem de rotc:tmcnto Indireto (veja Scç-Jo 6.5.2), primeiramente rotcando a chamada do correspondente par;1 a rede nativa do nó móvel c dal p;lr.l a rede visitada. Em tcrnunologta GSM a rede nativa do nó móvel é dcnormnada rede p ública terrestre móvel nativa ( PLMN nativa). Visto que o acrõnimo PLMN é um pouco complicado, e sempre firmes n:t nossa decisão de evitar uma sopa de letrínhas, denominaremos a rede PLMN nativa GSM simplesmente rede nativa. A rede nativa é a provedora celular da qual o usuár io móvel é assinante {isto é, a provedora que cobra mensalmente do usuário pelo

bow4tto4ic~ Redes de computadores e o lnte;.;rn;.;e;.;,t_________________________

Rede visitada: 79.129.13124 ~ Agente móvel MA: 128. 119.40.186 Agente nativo

Agente externo

HA: 128.119.40.7

COA; 79.129.13.2

Re
Re
lden~ftcac;.)o:

714

COA: 79. 1l9.13.2

HA: I28.11940.7 MA: 128.1 19.40 186

..oa·

~ tdenlrf~bo: 714 lormo10 de eoo~~10

l('mpo de

Resposta de regiStro HA. 128.119.40 7 MA: 128.119.40. 186 tempo de~- 4999 oden1ofo(~ 714 IOMiilO de tna~lO

Re1posta de re islro HA 128119407 MA. 128 119 40 186

1. .

• ...............

~

TempO

Jempodev~W· 4999

~ ~Uf~714

Tempo

Tempo

Figura 6.28 Anúndo de ogente e registro IP móvel scn •ic;o celular). A PLMN " isitadu, que denominaremos simplesmente rede CSiá residindo corrcrucmcnle.

visitada .~

a rede na qual o nó móvel

Como 110 caso do IP móvel, as responsabilidades das redes nativ;~s c "isiladas sào bas tante d ircrcntcs. A rede nativa mantém um banco de dados conhecielo como registro nativo de loeali:z:ação (home localiou rtglsw · - IILR), que comém o número permanente do telcronc celular c as in ronnações do perfil elo assinante para cada um de seus assinantes. O importante é que o HLR tam!Xm contém inrormaçôcs sobre as loc:alízaçõcs correntes desses assinantes. Is to é, se um usuário móvel estiver correntemente em trJnsito pela rede celular de uma outra provedora. o HLR conterá inform ações suficientes para obter ( por melo de um processo que descreveremos em breve) um endereço na redr visítada para o qual dever.\ ser roteada uma chamada ao usuário móvel. Como veremos. quando é rei ta uma cham3da para um usuário móvel, um comutador especial na rede nativa, conhecido como Central d e Comutação para Portal de Serviços Mõveis (Gauway Mobile Stn•iccs Swirclting Cmrcr- GMSC), é contatado por um correspondente. Mars uma vez. confonnc nossa decrs:'lo de evitar a sopa de letnnhas. denominare· mos a GMSC por um tem1o mais descritivo, uma MSC nativa. A rede visitada mantém um banco de dados conhecido como registro de localização de visitantes (visilor location register - VLR). O VLR contém um registro para cada usuário móvel que está



417

co1 renrtmenrt na porção da rede atendida pelo VLR. Assim, os registros do VLR v~m e vão à medida que usuários cmr"m c s.1em da rede. Um VLR usualmcme está localizado junuuncntc com a ccmral de comuLação móvel (MSC) que coordena o estabelecimento de uma chamada de c para a rede visitada. 'a prJtica. a rede celular de uma provedora servirá como uma rede naU\'11 (>ara seus assinantes c como uma rede visitada para usuários móveis que são assinantes de outra provedora de serviços celulares.

6.7.1

Rateando chamadas para um usuáriomóvel

Agora estamos prontos para descrever como é cstabclccidr. uma chamad:~ para um usuário GSM em uma rede visitada. Considcmrcmos um exemplo simples. representado na Figura 6.24: cenários mais complexos süo descri tos em (Moul)', 19921. As etapas, como ilustradas na Figura 6.29, slo as seguintes: 1.

O correspondente disca o número do telefone do usuário móvel. Esse número, em si. nâo se refere a uma determinada linha tcldonica ou localização (afinal, o número do telefone~ fixo, mas o usuário é móvel!). Os dlgilos iniciais do número são suflcíenLcs para lclcntilkar globalmcmc a rede nativa do us uário móvel. A chamada é roteada desde o correspondente, passa através do PS1'N e chega até a MSC na rede n:.tlÍ\':1do usu. rio móvel. Esse é o primeiro trecho d:t chamada.

2.

A MSC n:uiva recebe a chamada c interroga o I-ILR para determinar a locnlizaçl\o do usu:lrio móvel. No caso mais simples, o HRL retoma o número maming da estação móvd ( mobil•· sltllion roaming num!ler- MSRN). que denominaremos nú.mero de roaming. Note que esse mlmero é direreme do número permanente do tcldonc móvel, que ê associado com a rede nati\•a do usuário móvel. O número de roaming é d~mcro: é des ignado temporariamente a um usu:\rio mó,•cl quando ele entra em uma rede visitada. O número de roaming desempenha um papel semelhante ao do endereço administrado em IP móvel c. tal como o COA, é invisível pam o correspondente c para o usuário móvel. Se o HLR não Li,•cr o número de roaming, ele retornará o endereço do VLR na rede visitada. 1 esse caso (que não é mostrado na Figura 6.29), a MSC naLÍ\'3 precisará consultar o VLR para obter o numero de roaming do nó móvel. Mas. antes de mais nada. como o I-ILR obtém o numero de roaming ou o endereço VLR? O que acontece a esses valores quando o usuário móvel passa para um:~ outra rede visiLad:~? Em bre,·e consideraremos essas pcrgunUIS importantes.

Rede nativa

Correspondente

Rede

0pública telef6níca comutada

Sistema

visitado

Figura 6.29 Estabelecendo umo thomodo poro umusuário móvel: roteamento indireto

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------3.

Dado o n úmero de roam ing, a MSC nativa estabelece o segund o trecho da ch;unada através da rede até a MSC na rede \•isitada. A c hamada está conclu fda- foi roteada do correspondente até a MSC nativa c dai para a MSC visitada, e desta até a estação-base que atende o usuário móvel.

Urna q uestão não resolvida na etapa 2 é como o HLR obtém informação sobre a localízação do usuário móvel. Quando um telefone móvel ê ligado o u entra em uma pane de uma rede visitada que é coberta por um novo VLR. ele deve se registra r na rede ' ' isit.'\da. Lsso é feito por meio da troca de mensagens de sinaliz:u,:ão entre o usuário móvel c o VLR. O VLR visitado. por sua ' 'CZ, envia uma mensagem de requisição de atualizac,:ão de localização ao HLR d o usuário móvel. Ess:\ mensagem informa o HLR d o numero de roaming no qual o usuário m óvel pode ser contatado o u o endereço do VLR (q ue então pode ser consultado mais tarde para obter o número do us uario móvel). Como parte dessa troca. o VLR tambem o btém do HRL info rmações sobre o assinante do usuário móvel e determina quais serviços (se hou,•c r :1\gu m) devem ser p restados ao usuário móvel pela rede visitada.

6.7.2 Transferências em GSM (handoffs) Uma tra nsferê ncia ( ltandoll) ocorre q uando uma estação mó,•cl muda sua associação de uma estação-base para outm durante uma ch amada. Como mostra a Figura 6.30, uma ch:unada de te lefone móvel é ro teada inidalmem e (a mes da trans fe rê ncia) para o usuário móvel po r meio de urna estação-base (a qua l denominaremos estac.'!\o-basc antiga) c, após a transferência, por meio de uma outra estação-base (a qua l denominaremos n ova estação). Note que uma transferência entre estações-base resulta não somente e m transfercncialrcceP\'áO d e/para um telefone móvel c uma nova estação-base, mas também no rerro teamcnto da chamada em cu rso de u m ponto de comuta\·ão dentro da rede para a n ova estação-base. Vamos admiti r inicialmente que as estaçõesbase antiga e nova compartilham a mesma MSC e que o rerrotcamento ocorre ness.1 NISC. Há divers.1s razões possfveis para ocorrer transferência. mduindo ( I ) o sinal entre a estação-base cor· rente c o usuário móvel pode ter-se d eteriorado a tal ponto que a chamada co rre perigo d e ser descartada e (2) uma célula pode ter ficado sobrecarregada, man ipulando um gmnde numero de chamadas. Esse conges tionamento pode ser aliviado transferindo usuários móveis para células próximas menos congest ionadas. Enquamo est.1 associado com uma est;w.to-basc. mn usuário móvel mede periodicamente a potênàa de um sinal de sinalizaç;1o emitido por sua estação-base corrente, bem como de sinais de sinalização emitidos por estações-base próxi mas que ele pode 'ou,
Antiga estaç!o·base

Nova est~o·base

Figura 6.30 Cenário de transferência entre estações-base que têm uma MSC em comum


Antiga a\ estação-base\V

Figura 6.31 2. 3. 4.

5.

6. 7. 8.


419

Nova

@ estação-base

Etopos do execu~õo de umo ITonsferêncio enlle esto~ões-bose que lêm uma MSC em comum

A MSC vlsilada inicia o cstabelecimemo do c.:aminho mé n nova BS, alcx:ando os recursos necessários para carregar a cham~da ren·oteada c sinalizando à no'~' BS que mm1 transferênda cst.1 prestes a ocorrer. A nova BS reserva e mi,•a um t-anal de rádio para ser utilizado pelo usutlrio móvel. A novu BS devolve um sinal à MSC visitada e;, :mtiga BS, indit
Vamos concluir nossa discussão sobre transfcrencia considerando o que acontece quando o usm~rio mó\'cl passa para urna BS que está associada com uma MSC diferente da antiga BS c o que acontece quando essa transfert'nda intcrMSCs ocorre mais de uma vez. Como mostra a Figura 6.32, o GSM define a noção de uma MSC ancora. A MSC :\ncora é a MSC visitada pelo usuário móvel logo no inicio de uma chamada; assi m, a MSC âncora não muda durante a chamada. Por toda a duração da chamada c independentemente do numero de t.ransferencias intcrMSCs •·ealizadas pelo usuário móvel, ;• chamada é roteada desde a MSC nati\'a até :1 MSC âncora e, então, da MSC !In cora até a MSC vL~itacla, onde o usuário móvel está correntemente localizado. Quando um usuário móvel passa da área de cobertura dc uma MSC para a área de cobenura de uma OtLtra MSC. t1 chamada em curso é rer· roteada desde a MSC âncora até a nova MSC visitada, que contém a no,,a cstac;:'lo·basc. Assim, durante o tempo todo há, no máximo, tres MSCs (:1 MSC local, a MSC âncora c a MSC visitada) entre o corresponden te c o usuário móvel. A Figura 6.32 ilustra o roteamento de uma chamada entre as MSCs visitadas por um usuário móvel. Em vez de manter um único sal lO desde n MSC âncora at~ a MSC corre rue, ullH\ abordagem alternativa seria simplesmente encadear as MSCs visitadas pelo móvel, fazendo com que uma MSC anttg:t transmitisse a chamada cm curso até a nova MSC ~da "ez que o mó,•cl passasse par.t uma no,,a MSC. Esse encadeamento de MSC pode realmente ocorrer em redes celulares 15-41, com uma etapa opcional de nunímiz:u::'o de caminho para remover MSCs entre a MSC âncora e a nova MSC Yisitada (Un. 2001). Vamos encerrar nossa discussão sobre o gerenciamento da mobilidade GSM fazendo uma comparação entre gerenciamento de mobilidade em GSM c em IP Móvel. A comparação apresentnda na Tabela 6.2 indica que. embora redes IP c celulares sejam fundamentalmente diferentes sob muitos aspectos. comparl ilham um número s urpreendente de elementos funcionais comuns e abordagens gerais para o gerenciamento da mobilidade.

bow4tto4ic~ Redes de computadores e o

lnteroe~1----------------------Rede nativa

Rede nativa

Correspondente

MSC âncora

PSTN

a. Antes da transferência

b. Após a transferência

Figura 6.32 Renoteomento vio oMSC óncoro

6.8 Sem fio e mobilidade: impacto sobre protocolos de camadas superiores Neste capítulo, vimos que redes sem fio são signific.tlivamcntc dirercntcs de s uas contmpartcs mbcadas ramo na camada de enlace (como resultad o de camcrcrísticas de canars sem no como des,·anecrmcnto, propagação multhias c terminais ocuhos) quanto na camada de rede (como resultado de usu.írios móveis que mudam seus pontos de conex;lo com a rede). M<\S h:\ diferenças impon:\ntes ni\S camadas de transporte c de aphcaç;lo? E: tentador pensar que CSSi\S dircrenças senam minUs<:uli\5. \trsto que a camada de rede prov! o mesmo modelo de serviço de ent rega de melhor esfo rço às camadas superiores tanto em redes cabeadas quan to em redes sem no. De modo semelhante , se protocolos como T CP ou UDP são usados pam prover serviços de camada de transporte a aplicações tanto em redes L-abcadas corno em redes sem flo, cmào a camad
Elemento do GSM Sisremo ootivo (enlrol de cornut~õo de unidode móvel ousimplesmeme MSC no!MJ.

Registro nativo de locolizoçõo (HlRl

Comentário sobre o elemento do GSM Rede ôqool perten
Elemento do JP móvel Rede oorivo Agente nomo

inloonoções de ossiooiiKo

Sísremo visitado

Rede, exceto o sistema nolivo, onde oI&J(jrio môvel está residindo corrente-

Rede vísitodo

llleflle

Cen!Tol de ~os de cntoçõo de ooilode móvel visilodo, Re;stTo de locolizoçõo de \'ISitonte (VIR)

~\SC visitado: r~ po. estob~er cbJmodos de/ptWo nós móveís em cêlllos ossocioOOs com MSC. VI.R: registro teJll)OI(Jio em lm
AQente extemo

~

llOOleso de roomilg de estoçõo móvel (1.\SKN) ou ~te rúnero de roorrilg

Elllereço roleów.l jXliO segmento de cOOmodo telelõrto entre MSC noiMI e IAS( visilodo, que riio é Yisí"Jd nem poro ousuório mr1tel nem poro ocor· respofldente

Tabela 6.2 Semelhanças entre o mobilidade em IP móvel e em GSM

Endeteço odmiristrodo

bow4tto4ic~ {opitulo 6

Redu sem fio e redes móuis

sem mudança. Noss.1 intuição está cena ern um semido - TCP e UDP podem operar, c realrncmc operam, em redes com enlaces sem fio. Por outro lado, pr01ocolos de transporte em geral e o TCP em panicular às vezes podem ter desempenhos muito diferentes em redes cabeadas e em redes sem fio. c t neste particular, em termos de desempenho. que as diferenças se manifestam. Vamos ver por que. lembre-se de que o TCP rctransmite um segmemo que é perdido ou corrompido no caminho enlre remetente e destinatário. No caso de usuários móveis, a perda pode resu ltar de congestionamento de rede (transbordamento de bulfer de roteador) ou de transfer~ncm (por exemplo, de atraSOS no rcrroteamento de segmentos para um novo ponto de concx-;,lo do usuán o à rede). Em todos os casos, o ACK receptor-emissor do TCP indica somen te que um segmento m\o foi recebido iruacto: o remetente não sabe se o segmento foi perdido devido a congestionamento, durante trnns· fcrencia. ou devido a erros de bits detectados. Em todos os casos, a resposta do remetente é a mesma - retransmitir o segmento. A resposta do controle de congestionamento do TCP lcrmWm é a mesma em todos os casos - o TCP reduz su.a j:mcla de co ngestionamento, como discutimos na Sc~·ão 3.7. Reduzindo incondicion:1lmente sua janda d e congcstio namemo, o TCP admilc implicitamente que a perda de sl'gmcnto resulta de eor~ges tionamcnto c nao de corrupç.\o ou tr:msfcrencia de usuário. Vimos na St\ãO 6.2 que erros de bits s;\o muito nmis comuns em redes sem fio do q11c em redes cabcadas. Quando ocorrem esses erros de bits ou quando ocorre perd" na transferência de usuário, na rc:tlid:tdc n:\o hiÍ nen huma razão para que o remetente TCP reduza sua Janela de congestionamento (reduzindo, assim, sua taxa de em~ o). Na verdade, é bem possível que os bulfers de roteadores es tejam vazios e que pacotes estejam Ouindo ao longo ele caminhos lim a fim desimpedidos, se m congestionamento. Entre o inicio e meados da déca da de 1990, pcsquis.tdores perceberam que, dadas as altas taxas d e erros d e bits em enlaces sem fio c a possibilidade de perdas devido à tmnsreréncia de usuários, a resposta do comrole de congestionamento do TCP poderia ser problemática em um ambiente sem fio. I lá duas classes gerais de abordagens posstveis para tratar esse problema: RCCIIJJCICIÇtlo local. Os protocolos d e recuperação local recuperam erros de bits quando e onde (po r exe mpl o, no enlace sem lio) eles ocorrem (por exemplo. o protocolo ARQ 802.11 , que cswdamos na Stç:lo 6.3. ou abordagens mais sofisticadas que utilizam ARQ c também FEC (Ayanoglu. 19951);

Rcmtltulr TCP cirntc tlr rn laccs srm fio. Em abordagens de recuperação local, o remetente TCP fica alegremente inconsciente de q ue seus segmentos est:\o atravess.1ndo um enlace sem fio. Uma abordagem ahcm:uiva é o remetente e o receptor ficarem cientes da cxisténcta de um enlace sem fio, para dtsungutr en tre perdas por conges tionamento que ocorrem na rede cabeada c corrupção/perdas que ocorrem no cnl:1ce sem fio e invocar controle de congcs uon amcnto somente em resposta a perdas por congestio namento na rede cabeada. [Balakrishnan, 1995) irwcsuga \-:\rios tipos de TCP. :tdmiundo que sistemas llnais possam fazer essa dis tinção. (Wei. 2004 I investiga técnicas pam d istinguir entre perdas nos segmentos cabcad os c sem fio de um caminho flm a fim. Aborclctgcr~s

tlc concxclo tfjvididrl. Nesta abordagem (Bakrc, 1995). a conexão fim a flm entre o usuári o móvel e o outro ponto terminal é div id id
bow4tto4ic~ 4:U

Redes de co 111 putod ores e o Inle r ne~'------------------------.....-

de banda como uma mercadoria escassa. Por exemplo. um servidor Web que serve comeudo a um brO\\Ser \Vcb que está rodando em um telefone 3G provavelmente mlo conseguirá prover o mesmo comeúdo rico em imagens que o ferece a um browser que está rodando sobre uma conexão rnbeada. Embora enlaces sem fio proponham desafios na rnmada de aplieotç;lo, a mobilidade que eles criam também torna possfvclum rico conjunto de aplirnçõcs dependentes de lornlização c cientes de contexto (Chcn. 20001. Em temtos mais gerais. redes sem fio c redes móveis desempcnharno um papel fu ndamental na concretização dos ambaentcs de computação ubíquos do futuro (Wciser, 19911 . Ê justo dizer que vimos somente a poma do accbcrg quando se trata do impacto d e redes sem no c móveis sobre aplicações em rede c seus protocolos!

6.9

Resumo

Redes sem fio e móveis revolu caonaram a te lefonia c também est:\o causando um impacto cada vez mais profundo no mu ndo d:ts redes de computadores. Com o acesso:\ infracstruLUra da rede global que oferecemd esimpedido. a qua lquer ltora, em qualquer lugar- est:lo não somemc aumentando :1 ubiquidnclc do acesso a redes, mas t:lmbém habilitando unt novo conj unto muilo interessante de scrvl t;os der>e ndcutes de localíz:tção. Dada a crescente imporH\nda d;ts redes sem fio c móveis. este capftu lo foca lizou os princll'ios, :tS tecnologias de enlace c as arquiteturas de rede para s uport:tr comunicações sem no c móveis. Iniciamos este capflulo com uma introd uçi!o às redes sem fio e móveis. tra~·ando uma Importante distinç.lo entre os dcs.1fios propostos pela natureza sem fio d os enlaces de comunlcaç:lo desse ti po de rcclc, c pela mobiliclcrde que esses enlaces permitem. Isso nos permitiu isola r. identificar c dominar melhor os conceitos fundamentais em C'dda área. Focnhzamos primeiramente a comunicação sem fio, considerando as caractc::rrsticas de um enlace sem fio na Seção 6 .2. Nas seções 6.3 c 6.4 examinamos os aspectos de rn macla de enlace do padr:lo IEEE 802.11 para LANs sem fio (Wr-Fi), do padrtlo WiMAX 802.16. do padnio Bluctooth 802.15.1 c do acesso celular à Internet Enuio, voltamos nossa atenção para a questão da mobihdadc. Na Seçlo 6 .5 adcnuficamos diversas formas de mobilidade c verificamos que h:\ pomos ao longo desse espectro que propõem desafios diferentes c admitem soluções drfcrcntes. Consideramos os problemas de localízaÇ
Exercícios de fixação Capítulo 6 Questões de revisõo S~õo 6.1 1.

l.

O que significa 1>ara uma rede sem no esrnr operando no · rnooo de infraestrutura"? Se a rede não csth•cr no modo de mfracstrutura, em qual modo ela esta c qual é a dafcrcnç;1 entre esse modo de operação c o modo de infraestrutura?

Qu:us sdo os quatro upos de redes sem lio identifica· das em nossa taxonom ia na Seção 6.1? Quais desses tipos de redes sem fio você utilizou?

S~ão6.2

3.

Quais slo as diferenças emre os seguintes tipos de falhas no c;~nal sem no. atcnua,lo de percurso, propagação muhh·a.tS. mtcrfcr~ncaa de outras fontes?

4.

Um nó mó,'tl se distancia cada \ 'CZ maas de uma cstac:\o·basc. Quais sdo as duas atirudes que uma cstaçlo-basc podcna tomar 1>ara garanti r que a pro· babilidadc de perda de u m quadro Lransmilido não aumente?


2G c 2,5G cada um desses dois padrões de\'C sua linhagem?

Seçõo 6.3 5. 6.

7. 8.

9. 10.

11.

12.

13.

J.f.

15.

Dcscre\'i\ o papel dos quadros de sinalizaç-.lo em 802.11. Vcrdatle1ro ou falso: ames de uma estaclo 802.11 tr:msmi tir um quadro de dados. da dc\"C primeira· mcmc cn\iar um quadro RTS c receber um quadro CTS correspondente. Por que s.\o us.1dos rcconhécime ntos em 802.11. mas n:\o em Ethernet cabeada? Falso ou verdadeiro: Ethcrncl c 802.11 usam a mesma estrutura de q uadro. D4'~crcva como funciona o limiar RTS. Supvn lm quadros RTS c CTS IEEE 802.11 fossem ttlo longos quanto os quadros p;1clronizados DA Tf\ c ACK. I laveria alguma vantagem em usar os quadros CTS c RTS? justifique sua rest>osta. 1\ Scçân 6.3.+ discute mobiliclodc 802. 11 , na qual uma cstaç:\o sem fio passa de um 13SS para omro dentro da mesma sub-rede. Quando os APs cst:.lo intcrconcctados com um comutador, um ;\P pode prccis:\r cn"i:H um quo~dro com um endereço M.AC fingido pam fazer com que o comutador transmita quadros adcqundnmcnte. Por quê? Quais S.lo as d1ferenças entre o dispositivo mestre em uma rede 6luetooh e uma estaclo-basc .:m uma rede 802.117 Falsu ou verdadeiro. Em WiMAX, a estaç-.lo-basc dC\'C 1mnsmi11r a todo os nós a um:l mesma 1ax:1 de canal. Qual,, significado de ·program;~çào oportunista" em W1MAX? Aprendemos n n Seção 6.3.2 que ha dois padrões 3G importantes: UM rs c CDMA-2000. A quais padrões


~ão

6.5a 6.6

16. Se um nó tem uma conexão sem fio:\ lmemct. esse nó precisa ser movei? Explique. Suponha que um usuário ponando um laptop ande com ele por sua casa. c sempre acesse a lmcmet por meio do mesmo ponto de :~ecsso. Em relação a rede. este c U5uáno movei? Explique 17. Qual é a diferença entre um endereço permanente c

um endcrcc;o uos cuidados de (COA)? Q uem de termina o cndc rcco aos cuidad1lS cld 18. Considere uma conex~o TCP atmvC:S de urn IP Mó\'CI.

Falso ou verdadeiro; a fase da concx~o TC!> em rc o co rrespo ndcntc c o hosf>cdci ro mó\'cl percorre a rede domestica móvel, ma.s a fase de tmnsferência de dados está diretamente entre o correspondente c o hospcdt!iro movei. pulando n rede doméstlc.1.

~õo61 19. Quais Silo os ohJCllvos do HRL c VLR nas redes GSM?

Quats elementos de IP lllll\'cl HLR c ao VLR?

~o

semelhantes ao

20. Qual .: o papel da MSC âncora em redes GS~I?

Seção 2.8 2 1. Quais Silo os métodos odcm ser realizados para

evitar que um umco cnlncc sem fio reduza o desempenho de uma cone,.do TCP lim a fim da cnmada de 1ransportc 1

Problemas l.

Considere o exem plo do remetente CDMA único na Figura 6.5. Q ual seria a saída do remetente (para os 2 bits de dados mtlStrados) se'' Ci~digo do re meten te COMA fosse ( 1. - I , I, -I. I, -I. I. -J )?

2.

Considere o remetente 2 na Figura 6.6. Qual é a saída do remetente t>ara o canal (antes de ser adicionada ao sinal vindo do remetente I) z;..,?

3.

Suponha que o receptor na Figura 6.6 queira receber os dados que t.'St:lo sendo enviados pelo remetente 2. Mostre (por cllculo) que o receptor pode, na verda· de. recuperar dados do remetente 2 do sinal agregado do canal usn ndo o código do remetente 2.

a. Suponha ainda mais, que, JX>r ;tcidentc, cada 151" configurou seu AP paro O[>Crar no canal 11. O protocolo 802 li fnlhar.l totalmente nessa situacão? Discu tJ o que acontece quando duas estações, cada uma associada com um ISP diferente, tentam transmitir ao mesmo tempo.

4.

Para o exemplo sobre dois emissores, dois receptores, dê um exem plo de dois códigos COMA, que con-

b. Agora suponha que um AP opera no canall eomro no canalll. Como su.1S respostas diferem uma da outra?

tCm os v:tlorcs I c - 1. que n:lu J)ermitem que dois rcccJ)tores cxtmlam os bit~ nrif'ti nnis tr:msrnitidos por dois emissores COMA.

5.

Suponha que do is ISI's fornecem acesso Wi-Fi em um dctcrmin:tdo café. c que cada um deles opera seu proprio AP c tem seu prut,rio bloCll de endereços Ir.

bow4tto4ic~ Redes de tom putod ores e o Inlerne;.;t_________________________

6.

7.

8.

Na cutpa 4 do protocolo CS~1A/CA . uma estaç;lo que transmite um quadro com sucesso inicia o protocolo CSMNCA para um segundo quadro na etapa 2. c não na etapa I . Qmus scnam as razões q ue os projetistas do CS:\1NCA prm-avclmcnte tinham em mente para fazer com que essa estação não transmitisse o segundo quadro tmcd latamcntc (se o canal fosse percebido corno ocio~o)?

ou permanecer silencioso Dado esse controlado r onisciente, qu:~l c a t:lxa mixhna a qual uroo mensagem de dados pode ser transferida de C para A, sabendo que n,\o existem outras mensagens entre nenhuma o utra du1>la remetcntcldestln:n:\ria?

b. Sut>Onha que A en"ie uma mensagem a B. e O cn,'ic uma men~a~tcm a C. Qu:~l c a taxa má.~ima combtnada ,, qual as mens.1gcns de dados JX.~Cm Oui r de A :1 B c de O a C?

Suponha que uma estação 802 I lo seja configurada para sempre rescr\'ar o canal com a sequência RTS/ CTS. Su[Xl nha que essa cstacão repentinamente queira transmitir 1.000 b)·tcs de dados c que todas as outras estJçt\es cstt\o ociosas nesse m omento. Calcule o tempo requerido para transmitir o quadro c receber o rcc:onhccirncruo como uma funç~o de 51 FS e 0 1FS, lgnomndo a traso de pro1'agaç~o c admitindo que não haja erros de bits.

c. Suponha agora que A envie uma mensagem n B. c C envie uma mensage m a O. Qtr:ll ..: :1 taxa máxima co rnbrnada :\ qual as mcns:tgcns de dados podem ir de A a C c de C a O?

nu

d . Suponha agora <1uc os en laces se m fio sejam s ubstitufdos por cnlnc:cs c:ahc:ados. Rcpíla as q uestões de "u" '' .., .. nes1e cenário c:~bcadu . e. Agora sttponha que estejamos no\'lllll~ntc em um c:cn:lrio sem fio e ara cada mcns.1gcm de dados cm•iada do re metente ao destinatário, este cn\'le de volt:1 um:1 mens.'\gern 1\CK para o remetente (como no TCP, por exemplo). Suponha também que cada mcnSllgem ACK possua um imen·alo. Repita as quest•'es de · a· a ·c· para este cen:lrlo.

Con)idere 11 çen:\rlo mostrudo na Flg\tm 6.33, no qual existem quatro nós sem fios, A. 3, C e D. A cohc nura de r:ld it) dos quntro nós I! mostrada pelas formas o'·ais mais escuras; todos os nós compartilham a mesma frcqu~ncia. Quando A transmite, ele pode :.cr ouvido/recebido por B: quando B transmite. ele sü [)()de ~cr ouvidv/rcccbido ptlr A c C; quando C transmhc. 3 c O podem ouvir/receber de C: quando O transmuc, some me C [X)<~ e OU\ir/receber de O. Agora SU[Xlnha que cada nó possua um estoque lnfinho de mensagens q ue ele queira en,•iar para cada um dos o utros nós. Se: o destinatário da mensagem não for um vizmho tmcdiato. então a mensagem deve ser retransnnuda. Por exemplo, se A qu~r enviar para D, uma mensagem de A de\'C ser primeiro enviada a B. que. cnt.lo, envia a mensagem a C. c este a D. O tempo t dividido em inlcn·alos. com um tempo de transmisstlu de mensagem de exatamente um interva lo de tempo. como em um slo11cd Aloha, por exemplo. Ournn1c um imcrva lo, um nó pode faz:cr uma d:ls segui ntes upçõcs: (i) enviar urna mensagem: ( ii) J'Cccbct· umn me nsagem (se, CX.(Ilamcnu~. uma mc nSllgcm estiver se ndo cn"iada a ele), (iii) per· ma ncccr silencioso. Corno sempre, se um nó ouvir duas ou mais transmissões simuhàncas. ocorrení uma colisão e nenhuma das mct\S;tgens transmitidas é rcccbrda com sucesso. Voei! pode admitir :1qui que não exiStem erros de biiS c, desSll fom1a, se uma menSllgcm for enviada. eln ser:\ reccbld;~ corretamente pelos que estão dentro do rádio de transmiss.lo do emissor

a. Suponha que um controlador onisciente (ou seja. um controlador que: sabe o estado de cada no na rede) possa comandar cada nó a fazer o que ele (o controlador onisciente) quiser, ou seja, enviar uma mensagem, receber um:1 mensagem,

I

Figura 6.33 9.

c

D

CenóriD poro DPloblemo 8

Descre,•a o fonnato el o quadro Bluclooth 802.15.1. Você precisar:! de um~ leilura complementar para cnr;;ontr-.tr Cl>Sa infunn:•~·!lo. Extslc ulgo no formalo do quadro que baslc.mtcntc limite o llltmcro de nós ati\'os pnrn oito em umn rede 802.15.1? Explique.

10 . Considere o se~uinte cenário WIMAX idcnl. O S\tb-

quadro de downstrcam (\'Cjll Flgum 6. l7) é d ividido em inten-:~los de tempo. com N Intervalos downslrc,·un por subquadro c todos os intervalos de tempo têm o mesmo cornprírne rtto. l!xis tcm quatro nós, A, ll, C c O. alcanc:lvcis ela cs tncllo-b:tsc a taxas de LO Mb1>S. 5 Mbps. 2.5 MbllS c I Mbp:., respectivamente no canal downs trcam. A cstaç!lo- hasc possui infinitos dados para enviar a cada um dos nós e pode enviar para qualquer um do:. qu:uro nós duranle qualquer in ten-al11 de tem[Xl no subquadm de downstrcam. a. Qual c a tJIXa máxtma. qual a est:u;·.lo-basc [X)de enviar aos nós, admuindo que ela pode enviar a qual

b. Se h:\ requisito de equldade que cada nós deve receber urna <1uantidade igual de dados durante cad:1 quadro de downstream. qu:~l 4! :1 tAXa media de transmtsslo pela estaç:lo·basc (para todos os nOs) durnnte o subquadro de downstrcam? Exphque como você chegou a esta resposta. c. Suponha que. como crlu:rio de equidade, qualquer no possa receber. no máximo. duilS vezes tantos dados quanto qualquer oUi ro nó durnntc o subquadro. Qual é a taxa média de transmissão pela estaçdo·b.1SC (pam todos os nós) durante o subquadro de downstrca m? Explique como você chegou a esta resposta. LI .

Na Scç:\o 6.5. uma S<>lução proposta que permitia q ue usuários móveis mant ivesse m seu endereço IP :'1 mcc licht que transitavam ~ntre redes externas era fazt:r com que uma rede externo anunciasse no usu:l· rio móvel uma rma nltamente cspecHiea e ustssc a infrnestnuuro de roteamento existente para propagar essa lnform:lç.lo por toda a rede. Uma das preocupações que iclentincamos foi a escalabilidade. Suponha que.

425

c. Discut:l n escala temporal segundo a qual outros roteadores na rede nnalmcnte aprendcr:lo o cami· nho ate os usuários lll(l\'eis. 12. Suponll.'\ que o c:tmcspondentc na Ftgurn 6.22 fosse móvel. Faça um desenho csqucnliiUCO da mfrncstrumra adicional de camada de rede que seri:1 ncccssári:t para rotear o datagnuna do usuário mó\'cl original ate o correspondente (qui.' agora é mó,·cl). Mostre a e51ntturn do(s) damgrama(s) entre o usu~rio mô,·cl original c o correspondente (agora mvel, que efc110 ter.\ a mobilidade sobre atrasos fim a nm de datagramas entre a fonte c o destino? 14. Considere o exemplo de encadeament o discu 1ido no final dói s~çào ó.7.2. Supon ha ( JUC um usuário móvel ' 'isite as redes externas A, [) c C, c que um co rrespondente inicie uma concxilo com u usu-'•io 11l('lvd enquanto l'Ste reside na rede externa t\. Relacio ne a scquência de mensagens cn1rc agentes ex1crnos c cntn: agentes externos c o ugcn tc lmtí,·o. enquanto o usuário p:\ssa d:1 rede A 1>ara a rede B e para a rede C. Em seguida. SUIXlnha que n~o e executado en<.-;~dca mcnto e que as mudanças no endereço administrado do us uário móvel de' em ser notificadas explicitamente ao eorre~pondentc (bem como ao agente nati\'O). Relacione a se
Considere dois 1\()S lll(h·eis em uma rede externa que tem um agente cxtcmo. t: posswel que os dois nos moveis utilizem o mesmo endereço ad ministrado em IP móvel? Exphque sua resposta.

16. Qllllndo discutimos como o VlR :uunli:tava o HI.R com informações sobre a localização corrente de usu:\rios mú\·eis. quais era m as vantagens e as des' 'antagcns de fornecer ao HLR n MSRN em vez do endereço do VLR?

Questões dissertotivas l.

Relacione cinco produtos existentes hoje no mercado que fo rneçam uma in terface Bluctooth ou 802.15.

2.

O serviço 3G sem fio está disp()nfvcl em sua região? Q uand o custt1? Quais aplícaçt)CS ele suporta?

3.

Q ue tipo~ de problemas você observou çom11 usuário do IE EE 802.11? Como os projetos do 802. 11 podem evoluir para superar esses problemas?

4.

Faça uma pesquisa na Web para se informar sobre os testes de lmt>lc mcmação do WiMAX. Quãt> abran· gentes fora m cs.~s tes tes? Quais vazt'lcs foram at ingidas a <.1 uais distâncias? Pam quan tos usuários?

5.

Faça uma pesq uisa na Web p.1ra se infonnar S<>hre a lmplcmcn taç:lo de EVDO c IISDPA. Qual deles foi o mais empregado até agora? Em que lugar?

Wireshork Lob No Compan!on Wehslle deste hvro, www.aw.com/

kurose_br, você encontrará um Wircshark l.ab, em inglês,

para este capítulo, que captura c estuda os quadros 802.11 trocados entre um laptop se m no e um ponto de acesso.

bow4tto4ic~

Chorlie Perkins Chorles E. Perkins é um técnico associado no WiChorus, que investigo novos técnicos poro o oplicoçõo dos protocolos de gerenciamento de mobilidade do Internet o novos gerações de mídia sem fio, como o WiM.AX e lTE. Essas tecnob gios jó começaram o transformar o bando largo sem fio em realidade, surgindo novos oportunidades poro expandir o Internet e fornecer conteúdo multimídia sob demando. Ele é o editor de documento paro o grupo de trabalho IP móvel do Internet Engineering Tosk Force (IElf) e é autor ou cooutor de documentos de padrões paro os grupos de trobolho mip4, mip6, monet, mexi, dhc, soomoby (Seomleu Mobilityl e outoconf de grupos de trabalho. ~ editor de vórios jornais do ACM e IEEE relacionados ô rede sem fio. No WiChorus, ele possui um envol· vimento continuo com desenvolvimentos avonç;ados empregando Mobile IP, 1Pv6 e outros proc:ol s baseados no IETF. ' '' ~ '' Chorles escreveu e editou livros so&e IP ~el e Redes Ad Hoc: e publicou vórios estudos e artigos premiados nos óreos de redes móveis, redes od hoc, otimização de roto poro redes móveis, descoberto de recursos e configuração outomótico paro computadores móveis. Ele é um dos criadores do MobiHoc. sendo o coordenodof geral e o coordenador do comitê de programo. Chorles participou do Conselho de Arquitetura do Internet do seu IETF e em vórios comitês do National Resoorch Council, bem como em diversos conselhos de avaliação técnico poro o Army Resoorch Lob e o programo Swiss MJCS. Recentemente, ele foi o coordenodor geral do workshop WiNS..OR e MASS 2006. O que o fez se decidir

pela especialização em sem fio/mobilidade?

Meu cm•olvimcnto com redes sem fio e mobilidade foi uma conscquéncia natuml do meu tmb:llho em projetos na IBM R~rch no fi nal da dtcada de 1980. Nós tfnhamos enlaces de rádio e est:h'õlmos tentando construir um equipamento ao estilo do 'ThinkPad' (digamos. por exemplo. um Paim Pilot) com conectividade sem fio c rcconhccuncnto de escrita. Construímos uma soluç;lo simples (mais tarde denominada 'Mobile IP' (IP Móvel)) c percebemos que ela fun· cionava. Aproveitando nossa expcnencia corn o Mobile IP. projetamos umr~ modific.1!,"'J O rápida c efctiVfl para o RIP - c que também fun cionou muito bem. Aqui, ·funcionar' quer dizer que as aplicações rodav.-.m bem sem ncnhum:1 modincação c que o desempenho da rede n:1o foi prejudicado por nossos novos projetos. Essas propriedades fic11rnm conhecidas como 'transparencia ela aplkaçllo' c 'cscalabilidaclc'. ~ ciMo que funcion:u em labomtório é muito diferente de alcançar sucesso comercial, c ambas as tecnologias têm muito potencial ainda nao rcaliz:1do comercialmente. Qual fai seu primeiro emprego na setor de computação? Trabalhei na TRW Controls, em Houston, Texas. Foi uma mud:mça drástica em rclat,":lo ao estudo universitário. Uma coisa que aprendi na TRW Controls é como o suporte de softw·.tre é precário até mesmo para os sistemas mais criticas de controle de utilidades. Esses sistemas deviam controlar o nuxo de energia clt tríca em redes de enorme potencia c o modo como em construido o softw·.trc subj;Kcntc era de arrcpi:1r os cabelos. E mais, os cronogramas cmm sempre apenados e os programadores, profundmnentc céticos em rcl.1ç:lo às suas condições de trabalho c às lntcnçOcs da diretoria. Em preciso projetar o sistema inteiro a p.-.nir do zero. Não tenho muitas razões pam achar que as co asas mudamm nesses últimos 30 anos, espccaalmcntc con ademndo os eventos recentes que ccrl-ar:1m o apagi\o de 2003. Na verdade, dada a dcsrcgulamentaç:lo, ccrtamcruc fica ram até paorcs. Para mim foi uma felicidade sair da TRW Contrais c passar para a Tcktronix (Tck l ;lbs).

bow4tto4ic~ Qual parte do seu trobolho lhe propõe mais desafios? A parte do meu trabalho que me propõe mais desafios t entender o que devo fazer pam ajudar minha empresa. E tambtm considero corno parte do meu trabalho moldar as tecnologias sem rio com as quais entro em contato e fornecer às pessoas serviços melhores c uma experiência diária mais agmd:wcl. Mmha empresa trabalha no

ramo de prover equipamento de infraestru tura para conccúvidadc sem no de aha velocidade. Além de desenvoh•cndo os documentos de padr;\o relevantes, espero encontrar maneiras de simplincar os sistemas resultantes aplicando \';Irias técnicas relac:aonadas ao IETF. Fazer isso de uma maneara a também maximizar o potencial de benefício das tecnologias que desenvolvemos, cada dia se torna um desafio. Ainda há muito para ser feiro c as oportunidades s3o imcns..'\5. Em um nível técnico maas detalhado, no qual certamente me sinto mais à vontade, tento resolver problemas de protocolos de rede de modo a aplicar o mlnimo de carga possível sobre os eqmpamcntos sem no (c suas baterias!} c provocar a mínima inconve ni~ncia aos us uários. lntcrconcctar os aparelhos sem no de hoje com a ltltcrnct por meio de tecnologias sem l'io de alta velocidade é extremamente interessante tecnicamente c oferece potencial ilimitado de sucesso comercial para quem conseguir encontrar os caminhos cen os para seguir em freme. Além disso, estamos começando a encarar um desafio notá\•cl já que nosso espaço de endereço 1Pv4 cst:l no rumo certo de se csgoHlr em dois ou t r~ anos. O 1Pv6 provou ser armis difícil de empregar do que o que foi previsto h::t dez :mos. mesmo ns especificações b;"\sicas estando complcwmcntc desenvolvidas. Em sua opinião, qual é o futuro da tecnologia sem fio?

O setor, como um todo. está pass.·mdo por tremendas mudanças c ainda não há nenhum flnnl à vist:t. Estilo s urgindo novo:LS tecnologias sem no de aha velocidade que podcrJo causar d ei tos práticos imprevisrveis e pode· riam mudar fund:uncntalmente a sociedade. Nossas expectativas atuais em relação à privacidade c :\s limitações à nossa capacidade de nos comunicar uns com os outros ( vo~. imagem c dados) poderão ser irreconhecíveis dentro de dez anos. A medida que as empresas adotam cada vez mais comunicações sem no, é bem posstvel que novas medidas de segurança sejam tomadas, o que mudaria signil'i cativamente nossa cxperiencia no local de trabalho. Parece bem claro que conseguiremos alocar mais espectro a \"ár ios esquemas de comunicações por rádio, cujas velocidades podcr.lo ser muito ahas. A minha cxpeclati\'3 é que logo scr.i muito viável para as comunidades oferecer a seus cidadãos comuni<.-açõcs sem fi o de alta velocidade completas, como se a cidade anteira fosse uma rede local. Isso poderia ter um efeito revigorante sobre o sentilnento de comunidade que há muito tempo se perdeu em noss..'l soeaedadc, pelo menos nos Estados Unidos. t claro que a comunadade amda dcmandaraa acesso à Internet. A capacidade de armazenamento em disco está crescendo tão rápido. a preços L1o econômicos que já podemos carregar no bolso o Wikipédia inteiro e provavelmente todos os números de telefone do mundo, sem mencionar os acervos pessoais inédi tos de livros, músicas e filmes. A tecnologia sem l'i o está acelerando o crescimento d:~ Internet. A medidtl que equapamcntos sem fio nca m mais

bamtos, as comur1kaçõcs peln Internet estão por toda a parte (em plugues de ouvido, em jogos multiusuário, em

leitoms de bilhetes de metrô), o que motivará novas aplicações c novas soluções ele segumnç:J.

bow4tto4ic~

Redes multimídia

E

stamos todos testemunhando o desdobramento mundial de aplicações de vrdco c áudio na Internet. Milhares de s ues- incluindo CNN, Rhapsody, Napstcr, MSN. AOL. Yahoo!- disponibilizam o cnv1o de mfomla· ç-ao muhimfdia com conteúdo de áudio e vídeo. O YouTubc c outros sitcs de compartilhamento de vtdcos permitem que os usuários vejam- por pedido- \'ideoclips que foram carregados por outros usuários. Milhões de usuános usam o Skypc regularmente para suas necessidades relaCIOnadas a telefonia c a video-confer~ncia. E alguns canais tradicionais da televisão estão sendo transmitidos pela Internet, permitindo que usuários da Internet assistam os canais de tde,isão de todos os cantos do mundo. Esse crescimento explosivo das aplicações multimfdia da In terne t f , primariamente, rcsuhado do aumento da pcnctmçào do acesso residencial a banda larga e do acesso sem llo de aha velocidade (como a WiFi). Como estudado na ScÇ'ào 1.2, as taxas de acesso de banda larga con unuar:lo a aumentar, c a possibilitar a dislrlbuição de novas c cmpolg>lntes aplicações multimídias. As exigências de funcionamento das aplicações mul ü mídiit divergem sigmfica tivamcnte daquelas tradicionais aplicações cl:\sticas, como c-mails, navegação na wcb. login remoto c download c compartil hamento de arquivo (as quais estudamos no Capitulo 2). Em particular. difcrcmcmente das aplicações chtsticas, as

7.1

Redes multimídia

429

Aplicações de rede multimídia

Em nossa discussão sobre requisitos de serviço de aplic-.lç-lo no Capitulo 2, identificamos algurmts linhas no lo ngo das qmns esses requisitos podem ser classificados. Duas dessas hnhas- considerações quanto à temporização c à toler:\ncia à perda de dados - s:\o particulannente importantes paro aplicações de multimídia em rede. Considerações de temporizaç;lo são import:tntes porque muitas aplicações de multimrdia são altamente scrtsiveis a atraso. Veremos em bre,·e que, em murt.'lS a plic~c;õcs de nmltrmídra, pacotes que sofrem atrasos de remetente a dcstinat~rio de mnis do que algumas cemenas de milisscgundos são essencialmente inúteis ao recq>tor. Por outro lado. aplicações de multimídia em rede são. em sua maioria. toleran tes à perda - perdas ocasionais causam somente pequenas perturbações na reccpç;lo de áudio e vídeo. c essas perdas podem ser t>arcial ou totalmente encobertas. Essas características de sensibilidade a atraso c de toler;\ncia à perda s:\o claramente diferemes daquelas das aplicações el:\sticas, como s Wcb, c-mail, FTP c Telnct. Para aplicações elásticas, a trasos longos São incômodos. mas nào particularmente prejudiciais, e a completude c a integridade dos dados transferidos s.\o de sum;' lmport;1ncia.

7.1.1

Exemplos de aplicações mullimídia

A Internet pode comportar uma grande varic
Áudio e vídeo de fluxo contínuo armazenados 'essa classe de aplicações, clientes requisitam. sob demanda, arquh·os de áudio c vldeo comprimidos que est<\o annazcn:-tdos em servidores. Milhares de páginas romecem Oul'\OS am~:ucnados de áudio c vídeo hoje em dia, incluindo a CNN, a Microsoft Vídeo e o YouTube. Essa classe de aplicações tem três característica.'> fundamentais: Mltlltr tmna:trncr
fl uxo conllnuo. Enr Ltrna aplicaçrto de áudio/vídeo armazenado, normalmente o dicntc inici:1 a rcprodu~·t\o do áudio/vídeo alguns segundos após começar a rrccbcr o arquivo elo servidor. Isso significa

que o cliente estará reproduzindo áudio/vfdeo de uma parte do arquivo ao mesmo tempo c1ue está recebendo do servidor p:~rtes do arquivo que estão mais à frente. Ess~1 t~cnic:•. conhecida como Ouxo contin uo (strcaming), evita ter de descarregar o arquivo inteiro (c incorrer em atraso potencialmente longo) antes de começar a reproduzi-lo. H;\ muitos produtos para rcproduçilo de multimfdia de Ouxo continuo. entre eles o RealPiayer, da RealNetworks [RcaiNctworks. 20091. o QuickTime, da Apple [QurckTime, 20091 e o Windows Media, da Microsoft I licrosoft Wmdows ~lc

IPTV O conteúdo televisivo vem trod ic:ionolmente sendo distribuído por micr<>Ondos terrestres fibra híbrido cooxioi(HFC), e canais de sótelites geoestocionórios (vejo Seção 1.2). Mos no era do Internet otuol, existe um interesse enorme no IPlV - isto é, distribuir conteúdo televisivo pelo Internet. Um dos desafios do IPTV é lidar com a imenso quantidade de bando possante necessária, particularmente no fonte do servidor. Por exemplo, considere o transmissão simultânea de um importa nte evento esportivo, como uma portido do Copo do Mundo, de um único seiVidor do Internet o 100 milhões de usuários. Se o velocidade do vldea é, modostomente, de 1 Mbps, entõo o bondo possante oxigido pelo servidor seria de chocantes 100 terobits/segl Sendo assim, o distribuição dóssic:o servidor-cliente é inviável. Se um multic:ost IP fosse lmplementodo otrovés d<:1 Internai seria muito mais fácil poro o IPTV se tornar realidade. Outro a lterna tivo seria distribuir o vídeo através de uma rede multicosl sobreposto, como oquolos que sôo oferec:idos pelos redes de distribuição de conteúdo (Content Distríbutíon Networks - CDNs)(Vejo o Seçõo 7.3). No entan to, outro opção é usar uma distribuição poro(]·por, através do qual oodo por que recebe um conol de televisão também ajudo no redistribuição do conol oos outros pores. Talvez o maior chomolívo desse tipo de abordagem seja o preço boixo de d istribuição: se os pores coletivamente fornecem uma largura de bando upstream suficiente, pooco largura de bando de rede seró nec:essórío (talvez poucos múltiplos do taxo do vldeo). Por ter um custo tõo borato, qualquer pessoo com uma Webcom poderio distribuir um pr~ gramo ao vivo o milhões de usuários por um preço ínfimo! Até hoje, um determinado número de sistemas como o 8itTorrent P2P IPlV desfrutaram de uma distribuição bem-sucedido. O pioneiro do órea, o CooiStreaming, divulgou que teve mais do 4 000 usuários simultâneas em 2003 (CooiStreoming 2005]. Mais recentemente, outros sistemas, incluindo o PPlive e o ppstreom, relataram exilo, com milhares de usuários simultâneos assistindo o canais com velocidades de 300 kbps e 1 Mbps. Nestes sistemas c.omo o BitTorrent, pores formam uma rede dinâmico sobreposto e trocam blocos de vídeo com outros redes sobrepostos. Será interessante acompanhar como o IPTV se soirá nos próximo 5 ou 10 anos. Que tec:nologio de sobreposição será usado: CON ou P2P, ou um híbrido dos dois? E uma fração significativo dos fãs do Copo do Mundo assistirão ôs partidos do Copo de 2014 pelo Internet?

Áudio e vídeo de fluxo contínuo ao vivo Essa classe de aplicaç-~o f semelhame à transmiss;lo tradicional de rádio c tclcvislo, exceto que a tr:msmissllo

é realizada pel:t Internet. Essas :1plicacOcs permitem que um usuário receba uma tmnsmissJo de r;ldio ou tclevisilo ao vh•o de qualquer p<~rte do mundo (por exemplo, um dos :mtores deste livro sempre ouve suas emissoras ele rádio favoritas da Fikldélfia quando está viajando. O outro autor om•iu regu larmente as tr:111smissõcs ao vivo dos jogos de seu amado time de basquete universitário quando morou na Fran1,":1 por um :mo). Estas aplicações sfto frequentemente reconhecidas como um râclio da Internet e IPTV. Hoje existem milha res ele estações de rádio s~ndo tr:msmitidas pela Internet c um número significativo d e implementações de IPTV (ver quadro complcmemar). Como o fluxo contínu o de :\udio c vídeo ao vivo não é armazenado, um cliente nao pode ~tdi~mtnr o programa que está recebendo. Comuclo. com armazenamento local de dados recebidos. outras opernçõcs interntivas. como pausa e retrocesso S:1o poss•veis. No caso de aplicações ao vivo de t ransm~o brcxulccm, frcquememcme há muitos clientes recebendo o mesmo programa de àudío/vídeo. A distribuição de áudiol\•ídeo ao vivo parn muitos receptores pode ser realizada eOcientememe utilizando as tecnicas de muhicasting IP que estudamos na Seção 4. 7.No entanto. atualmente a distribuição d e áudio/vídeo ao vivo é mais comumente realizada por meio de aplicações em camad:1s muhicast (usando P2P ou CDN) aLravés de fluxos unicasl múlt iplos separados scrvidor-clieme. Como acontece com a multimídia armazenada de fluxo continuo. ela requer rcproduç.lo contínua. embora as limitações de temporização sejam menos severas do que para aplicacõcs interati\'l'tS em tempo real. Atrasos de au~ dezenas de segu ndos desde o instanLe em que o usuário requisita a entrega/reprodução de uma transmissão ao vivo até o início da reprodução podem ser tolerados.


Redes multimídia

431

Áudio e vídeo interativos em tempo real Ess.1 classe de aplicações permite que as pcssoos usem áudio/vfdeo p.·tra se comunicar entre si em tempo rc;ll. Áudio interath·o em tempo real pela Internet é frequentemente denominado tdefone por Internet, já que, da perspectiva do uslclrlo. é semelhante ao lr.ldlcional serviço telcfórlico por comutaçâo de circuhos. O telefone por Internet pode fornecer. potencialmente. serviços telefônicos de central pm'ada de comutaç-.lo tclcfómca (PBX). servrços locms c de longa distàncra, a custo muito baixo. Também pode faciht:~r a drspombihzaçM de novos serviços que n~o ~lo suport;•dos com facilidade pelas redes Lradicionais de comutaç;lo de circuitos, como detectores de presença, comunirnç.lo em grupo, integração tclefonc/Wcb. filtragem de cham:~das c outros mais. Hoje. há muitos produtos de telefonia por Internet disponfveis. Por exemplo. usuários do Sk)•pc podem fazer ch:~m:~das por voz de computador para telefone e de computador para computador. Com vídeo interativo em tempo real, também denominado videoconferencia, indi,•rduos se cormmirnm visualrneme, assim como oralmeme. ll:t t:~mbem muitos produtos de vídeo íntcrati,•o em tempo real disponi,•cis para a lmcrnet, incluindo o NctMccting da Microsoft, ' 'idco Sk)'JX. c ' ';\rios produtos da Polycom. Note que, em uma aplicação de áudio/vfdco interativo em temJ>O real, um usuário pode f:~ l nr ou se mover a qu:~lquer instante. Paru uma conversaç.lo com intcraç;to ent re Vllrios usuários. o atraso entre o momento em q ue urn usuário fala ou se move c o momcmo em que a aç;lo se manifesta nos hospedeiros receptor~ deve ser menor do que algumas centenas de milissegundos. No caso da voz, atrasos ml'norcs do que 150 milissegundos não s:'o percebidos pelo ouvido humano, atrasos entre 150 c 400 nulisscgundos 1>odem ser acchávcis c atrasos que excedem 400 mllissegundos podem resultar em conversas rrust.rnnlcs, se m\o <..'Om plctamcnte inintelígfvcis.

7.1.2 Obstáculos paro o multimídia na Internet de hoje lembre-se de que o protocolo IP disponibilizado na lntrrnet de hoje prov~ um servi ço d e m elhor esforço a todos os datagramas que transporta. Em outras pala,•ras, a Internet raz seu melhor esforço para transportar cada datagr.rma do remetente ao receptor o m:~is rapida mente possfvel, mas n:lo faz nenhuma promessa sequer sobre o atraso fim a fim para um pacote individual. Ta mpouco raz prom~as quanto à variaç-lo do atraso de pacote dentro de uma corrente de pacotes. Como TCP e UDP executam sobre IP, nenhum desses protocolos pode dar alguma garantia contra atraso às aplicações requlsitnntcs. De,•rdo à falta de qualquer esforço especial para entregar pacotes a tempo, é um problema utremamcnte desafiador desenvolver aplicações de rede mulrimfdia de sucesso para a Internet. Contudo, 3 multimfdi:t pela Internet alcançou um succ.:.so signiflcath·o at~ o momento. porém limitado. Por exemplo. :1 recepção em Ouxo continuo de ;\udio/ "ldeo anm\Zenado com atrasos de 5 a lO segundos na lntcratlvidadc com o usuário agora é comum na Internet. Mas, durante os horários de pico de tráfego, o desempenho pode ser insatisfatório, sobreiUdo quando os enlaces intervenientes cst..'\o congestionados (como os congestionados enlaces transoccãnicqs) . Tclcrone por Internet c vfdco interativo em tempo real também cncontrar.lm um uso amplo; por exemplo . existem norm:1lmcnte sete milhões de usuários do Sk)•pc onUne em qualquer momento. Voz e vldco interativos em tempo real impOem rígidas limitaçOcs ao a traso de pacote c à variaçlo de aLraso do pacote. Variação de atraso de pacote s ignifica que os pacotes experimentam atrasos diferentes den tro dn mes ma corrente de pacotes. Voz e vfdeo em tempo real fu11ciomun bem em regiões onde a orena de largura de band:1 é :.1bundantc e, port;\ntO, o :uraso c a variaç:lo de atraso S

Assim, por enquamo temos de viver com o serviço de melhor esforço. Mas, dada CSS.'l limilaçM, podemos tomar diversas dccisOes quanto ao projeto e milizar algu mas artimanhas para melhorar a qualidade de uma aplicação de rede muhimldia percebida pelo usuário. Por exemplo. podemos enviar áudio e vldco sobre UDP e, assim, cvilar a barxa ,·az•lo do TCP quando este entra em sua fase de parud:t lenta. Podemos retardar a reprodução no receptor em lOO milissegundos ou mais para reduzir os efeitos da variaç-Jo de atraso induzida pela rede. Podemos colocar marca de tempo nos pacotes no remetem e, de modo que o receptor sarba quando eles devem ser reproduzidos. Para áudio/\1dco armazenados. podemos adquinr dados antecipadamente durante a reprodução, quando houver capacidade de arquivo c largura de banda extra disponíveis no clicllle. Podemos até enviar informações redundantes para atenuar os efeitos da perda de pacotes induzida pela red e. Examinaremos muitas dessas técnicas no restante da primeira metade deste capítulo.

7.1.3 Como o Internet deveria evoluir poro dor melhor suporte à multimídia? Hoje, h:\ um dcb;Hc cxtraordim\rio- c, às ve~cs. feroz- sobre como a lntwlct deve ri:~ evoluir para melhor atender o tráfego multim rd ia com suas limitações rigidas de 1emporizaç;lo. Em um ext1·emo, alguns pesquisadores argurn en tam que devem ser feilas modificações fundamentais na Inte rnet para que aplicações possam reservar explicitame nte largura de banda flm a fim c dessa forma recebe uma gcmwti(l em seu desempenho !Im-IIm. Uma garalllia definitiva significa que a aplicaç<10 receberá •L qualidade exigida de serviço (QoS) com certeza. Uma garamia branda signi!lca que a aplicaç;\o ter.i grande probabilidade de receber s ua qualidade exig•da de serviço. Eles acham, por exemplo, que, se um usuário quiser fazer uma chrunada telefOniea pela Internet do hospedeiro A para o hospedeiro 8, a uplic:~ç;\o de telefone por Internet do usu
Redes de distribuição de conteúdo (contcnl distriburion networl1s - CDNs) duplicariam comeúdo armazenado c o colocariam nas bordas da Internet. Dado que uma grande fraçM do trafego que Oui pela Internet é contet\do ann:ucnado (páginas Web, MP3, vfdco), as CDNs podem alh•iar significativ:unemc as cargas de tráfego nos ISPs e nas interfaces de formaç-ao de pares ( peerrng) entre ISPs. Alêm do mais, CDNs oferecem um serviço diferenciado para provedores de conteúdo: os que pagam pelos serviços de


Redes multim ldio

433

uma CDN podem entregar comeúdo mais rapidamente c com maís dkiencla. Estudaremos CDNs mais adiante neste capitulo, na Seç-Jo 7.3. o caso de tráfego de fluxo comfnuo ao vivo (como a transrmss:io de um e'·cnto esportivo) que está sendo enviado a milhões de usuá rios simultaneamente, podem ser drsponibilizadas redes multicast d e l>Obreposiçào. Urna rede multicasr d e sobreposição consíste em usuários hospedeiros c, possivelrnenu:, scrv1dor~ dedicados espalhados Internet. Esses hospedeiros, servidores e os enlaces lógicos entre el~ formam, coleuvamente, uma rede de sobreposição q ue transmite tráfego multictiSI (veja Seção 4.7) da origem Mé milhões de usuários. Diferentemente do multica.~l IP, no qual a funçJo multim~l é manipulada por roteadores n:~ camada do IP. em redes de sobreposição o multkttSI ocorre na camada de apli· cação. Por exemplo, o hospedeiro de origem poderia enviar uma corrente a tr~ servidores de sobrepo·· sição: cada um desses servidores pode uansmitir a cor rente para mais tres servidores de sobreposição; o processo continua, criando, sobre a rede IP subjacente, uma árvore de distribu ição. A transmissão mulrlrnsr de trMego muito requ isitado, ao vivo, por redes de sobreposição pode reduzir a carga total de tráfego rm l ntcmct em rclaç;lo à dlslribuiçào unicctsl. Entre o campo d:-~ resef\1:1 de largum de banda c o campo da abordagem libcrnl, há ainda um terceiro- o campo dos serviços diferenciados (Dirfserv). Esse C"dmpo quer fazer mudtmças rcl,nlvamentc pequenas nas c:una·
7.1.4 Compressão de áudio e vídeo Antes que áudio c vldeo poss:un ser trans milidos por uma rede de computadores, eles dc,•em ser digitalizados e comprimidos. A necessidade de digilalização é óbvia: redes de computadores uansmttcm bits; portanto , roda informaç-ao transmitida deve ser representada como uma scqu~ncia de bits. A compr~s:\o é importante porque audio e vídeo não comprimidos consomem uma quantidade extraordinária de capacidade de armazenamento e de largum de banda; remover as rcdundtlncias inerentes aos sinais digitalizados de áudio c vídeo pode reduzir, em muitas ''ezes. a qu;mtidadc de dados que precisa ser armazenada c transmitid:~. Como exemplo, sem çompress;lo, u ma lintca irn:1gem constiturela ele 1.024 (com cada píxd codificado em 24 bits- 8 bits pam cada uma das cores venncllm, ve rde c az ul), exige 3 Mby tes de armazena mento. Levaria 7 minu tos para enviar essa imagem por um enlace ele 64 kbps. Se :1 imagem ror comprimida na modcsLa razão de compressão de 10:1 , a necessidade ele :-~rma· zenamento ser:\ reduzida pam 300 kbytes c o tempo de II".Ulsmissào também diminuirá por um r.·uor de 10.

Abordagem

localizo~ão

do

Garantio

Unidade Obtt1 o môximo

do set'liço de mel1u esforço

Henht.m:~

OoSdifera

Oosses de !mos

OoS gorontiOO

fluxos mviduois

He~~rumo, ou

l:condo

Hel1hlroo,ou !Jord! Blando ou defini. tivo, quondo o fluxoéodrOOido

lmplementosão atJGI

Complexidade

Me,onismos

Ooolquer local

Mmlo

Suporte de
A!guns locais

A\édio

[S
POIJ(OS locais

Alro

ES
Tabela 7.1 Três abordagens porosuportar oplicoções de multimídias

sinolizoçõo


O tópico sobre comprcss:lo de áudio c vfdeo é \'liSto. Áreas ativas de pesquisa nesse campo já existem há mais de 50 anos, c agora há literalmente centenas de técnicas c padrões populares para compressão tanto de audio qua nto de vtdco. Muitas unh•crsidades tem cursos completos de compress\o de áudio c vfdco. Portanto, apresentamos aqui uma breve introduç;\o de alto nível ao assunto.

Compressõo de áudio na Internet Um sinal analógico de áudio comi nuamente variável (que podcna emanar de voz ou de nHistca) é normal· mente convertido em um sim\1 digital como segue: O sinal aualógico de áudio é primeiramente amostrado a alguma taxa fixa: por exemplo, 8.000 a mostras por seguudo. O valor de cada amostro é um número real arbitmrio. Cada uma das amostras é ent~\o arredondada para um valor entre um número flnilo de \'lllores. Essa opcraçno é dcnomiuada quantização. O número de v~11orcs finitos - d cno mhmdos valores de quan· tiz1w:1o - é tipicamente uma pou~ncia de 2, por exemplo, 256 valores de qunntiz;t~l'lo. Cada um dos valores de quantizaçào é representado por um m1mcro fi,'CO de bits. J>or exemplo, se hoLM?r 256 v:tlores de q uantizac1\o, então cada valor- e, portanto. <.-:tda :unostra- scnl reprcsemado por l byte. Cada uma das amostras é convertida à sua rcprcscnta~'llo por bits. As represe ntações por bils de todas as amostras são, ent.\o. concatenadas em conjunto para rormar a rcprcsernac,-.1o digitalizada do sinal. Como exemplo, se um sinal de áudio for amostrado a urna taxa d e 8.000 amosLrnS por segundo c cada amostra ror quantizada e rcpresent>~da por 8 bils, emllo o sinal digital resultan te tenl uma taxa de 04.000 biiS por segundo. Esse si nal digital pode ent<ío ser rccom·crtido- is to é, decodrncado - em um sinal analógico para ser reprod uzido. Contudo. o sinal an alógico decodificado é caractcristi c;~men t e diferente do sinal de áudio original. Aumentando a taxa de amostragem c o número de valores de quantizaçào, o sinal dccodiric;~do pode se aproximar do sinal analógtco o riginal. Assim, há urna clara pcmmta entre a qualidade do sinal decodificado c as exigências de armazenamento c largura de banda do sinal digital. A t<'cnica básica de codificação que ac;~bamos de descrever é dcnonunada modulação por codificação d t pulso (rJulse rotlt nrodulatron - PCM). A codificação de voz frequentemente usa PCM, com uma taxa de amostragem de 8 .000 amostras por stgundo c 8 bits por amostra, o que dá uma ta,'CM, com taxa de amostragem de 44.100 amostras por segundo c 16 bits por amostra: isso dá uma taxa de 705,6 kbps para mono c 1,411 Mbps p<~rn cs térco. Urn a taxa de bits de 1,411 Mbps para música estérco ultrapassa a maioria das taxas de acesso, e mesmo os 64 kbps para voz ultrapassam a taxa de acesso ele um modem diS<.'lldo. Por essas razões. voz c música codificadas em PCM mmmente SilO usadas nu lmernet. Em ' ' CZ disso. são utilizadas técnicas de compresslo para reduzir a taxa de bits. Entre as técnicas de com pressão popul:ues para voz estão GSM (13 kbps). G.72.9 (8 kbps) c G.723.3 (6,4 c 5,3 kiJps), c um gm nde número de ttcnicas propri etá rias. Uma técnica ele comt>rc-sstlo popul<~r pam mt1s ica estérco com qtmlidade próxima à do CD é a MPEG l de camada 3 , mais conhecida como MP3 . Codiflcadores MP3 normalmente comprimem para taxas de 96 kbps, 128 kbps ou ll2 kbps e caus:un pouqulsslma degradação d e som. Quando um arquivo de MP3 é rmgmcnlado em pedaços, cada pedaço ainda é reproduzfvcl. Esse formato d e :uqui"o sem c.·abe~·alho permite que arquivos de músk~ e m MP3 sejam tmnsnH ticlos pela Intern et em nuxo contínuo (admitindo que a taxa de bits da rcprocluçao e a velocidade da conexão corn a Internei sejam compatr· vcls). O padr:lo de compresSI1o MP3 é complexo- usa máscara psicoacústica, rcduç.\o de redundância e buffer com rcscr\'atório de bits.

Compressõo de vídeo na Internet Um vldco ~ uma scqu~ncia de imagens que normalmente são apresentadas a uma taxa constante: por exem· pio. 24 ou 30 tmagcns por segundo. Uma imagem não comprimida, ~:odiflcada digitalmente, é constitutda de um conjunto de píxels, e cada pixel é codificado por um número de bits para representar luminânc:ia e cor. Há dois tipos de redundância em vídeo, e ambos podem ser explorados para compressão. Redundância espacial é a


Redes multim ídia

435

redund;\ncía dentro de uma dada imagem. Por exemplo. uma imagem cuja maior pane \! constítlllda de espaço em branco pode ser comprimida cflcicntcrneme. Redund;\ncia temporal reOete a repetição de imagens s ubscquemes. Se, por exemplo, uma unagcm c a imagem subscqucnte forem exatamente as mesmas. não ha,·cr:í razão para ca
Fluxocontínuoormozenodode óudioevídeodo Reolnetworks ao Youtube A ReoiNetworh, pioneiro em Ruxo contínuo de áudio e vídeo, foi o primeiro empresa o trazer o áudio de Internei o corrente principal. Seu primeiro produto, o sistema ReolAudio - lonçodo em 1995 - incluía um codilicodor de óudio, um servidor de óudio e um tocodor de áudio. Permitindo que os usuários novegossem, selecionassem e inlerogissem com o Auxo de áudio, Focilmente se tornou um sistemo populor de distribuição poro os provedores de entretenimento, educação e conteúdo jornalístico. Hoje em dia, os fluxos de óudio e vídeo estão entre os serviços mais populares no Internet. Não somente uma obundãncio de empresas oferecem esse tipo de conteúdo, mos hó também umo quontidode enorme de diferentes servidores, tocadores e tecnologias de protocolos sendo empregados. Alguns exem· pios interessantes (em 2009) são: • O Rhapsody do ReoiNetw~s; Fornece serviços de assinatura de fluxo continuo e downlood oos usuários. Rhopsody uso seu próprio cliente proprietário, que resgolo músicos de seu servidor proprietário otrovés de HITP. Ao posso que umo músico chego através de HTIP, é tocodo por um cliente Rhopsody. Acesso o conteúdo de downlood é restri to por um sistemo de Gerenciamento de Direitos Digitois [Digital Rights Monogemenl - DRM). • MSN Video: Usuórios podem ter acesso oo Ruxo de uma voriedode de conteúdos, incluindo notícias in ter· nocionois e videoclipes musicais. Vídeos podem ser tocodos otrovós do populor Windows Media Ployer (WMP), o quol estó disponível no moiorio dos hospedeiros Windows. A comunicação en tre o WMP e os servidores do Microsofl é feito pelo prolocolo proprietário MMS (Micromedio Medio Sorver), que típicomen te tento fa zer o fluxo de conteúdo através de RTSP/RTP; se bso folha, devido aos lirewalls, ele tento recuperar conteúdo otrovés de HlTP. • Muze: Fornece serviço de amostras de óudio o vorejistos, como o BestBuy e o Yohoo. Amostras de músicos selecionados nos sítes denes vorejistos vem do Muze e tem seu Auxo pelo WMP. O Nwze, o Rhopsody, o YouTubo e mu itos outros provedores de conteúdo de fluxo usom os redes de distribuição de conteúdo (CDNs) poro distribuírem seu conteúdo, como visto no Seçõo 7.3. • YouTube: O imensamente popular serviço de compartilhamento de vídeo uso um cliente boseodo em Flash (embutido em umo pógino Web). A comunicoçõo entre o cliente e os servidores do YouTube é feito através de HTIP. O que estó guordodo poro o futuro? Hoje em dia o maior porte do conteúdo do Auxo de vídeo é de qualidade baixo, codificado em toxos de 500 k.bps ou menos. A qualidade de vídeo certamente melhorou oo posso que o bando lorgo e o acesso à Internet via libra em coso se tornaram acessíveis. ~ muito provável que nossos tocadores de músico portáteis não ormozenem mais músicos - em vez disso eles irõo conseguir tudo por encomendo, por canais sem fio!


ln;.;l~ e ;.; rn;.;e;.;.t_________________________

7.2 Áudio e vídeo de fluxo contínuo armazenados os últimos anos, as aplicações de áudio c vfdeo de Ouxo conlfnuo tornaram-se populares c consumidoras signifitaU\':IS de largura de banda. Em áudio e vidro de fllLxo conlfnuo, clientes solicnam arqul\'os de áudio e \•ideo compriJmdos que residem em servidores. Como discutiremos nesta scç\o, esses sen idores podem ser senidorcs Wcb comuns ou scn •idores de fluxo contínuo especiais configurados para a aplicaç;lo de áudio e vídeo de fluxo continuo. A p«rr$Sc1o, Áudio c vfdco quase sempre s
7.2.1

Acesso o áudio e vídeo por meio de um servidor Web

Áudio c vídeo annazcnados podem residir no servidor Wcb que entrega :\udiol\•fdco para o cliente sobre IITTP ou em um servidor de Ouxo continuo dedicado de áudlolvfdeo usando um protocolo IITTP ou qualquer outro protocolo. Nesta subseção, examinaremos a entrega de áudio/vfdeo a partir de um servidor \ Vcb: na subseção segltinte, abordaremos a entrega de áudio/video a partir de um servidor de fluxo contínuo. Considere, em primeiro lugar, o caso de áudio de fluxo continuo. Quando um :trquivo de áud io reside em um servidor Wcb, ele ~ um objeto cormun dentro do sistema de arquivos do servido r, exatamente como os arqllivos HTML cjPEG. Quando um usuário quer ouvir o arquivo de áudio, o hospedeiro do usuário estabelece urna concx:lo TCP com o servidor Wcb c emoia uma requisit;tlo H'ITP pam o objeto. Ao receber a requisição, o servidor Wcb cnc:1ps ula o arquivo de áudio em uma mcns.1gcm de respos ta II'ITP c devolve a mensagem de resposta parn a conexão TCP. No (.':lSO do vfdco, essa opcroç:Jo pode ser um pouco mars complicada, porque a pane sonom c a parte visual do vfdeo podem estar annazcmtdas em dois arquivos. Ta mb~m ~ possível que o áudio e o vídeo estejam intcrcal:1dos no mesmo arquivo, de modo que somente um objeto precise ser enviado ao cliente. Para simplificar a discussão, no t'l\SO de um vfdeo propriamente dito, admitiremos que o áudio c o vídeo estejam contidos em um 11nico arquivo. Em muuas Implementações de Ouxo contrnuo de :\udlo e vfdeo atrnv~s de IITTP, a funcionalidade do lado do cliente ~ scparnda em duas panes. A tarefa do navegador é requis itar um mctarquivo que fornece infornlações (por exemplo, um:t URL c o tipo de codificação, para que o trnnsdutor adequado possa ser ídcntincado) sobre o arquivo multimídia que dever:\ ser rrnnsmilido sobre HTTP. Este nlCtarquí vo é cn~;lo enviado ao scn

Redes multímldio

437

Cliente

Servidor Srowser Web

---.

Servidor Web com arquivos de áudio

Figura 7.1 Servidor Web envioóudio/vídeo diretomente oo llonsdutor 1.

O usuário dica sobre um hlpullnk de Ltm arquivo de :\udio/vfdco. O hipcrlink não aponta diretamente para o arquivo de áudio/vídeo, mas para um meta rqui\'O. O rnetarquivo contêm o URL do arquivo de :\udio/vfdco. A mens.1gcm de resposta HTIP que cncapsula o metarquivo contêm uma linha de cabe~-alho de tipo de cometido que indica a aplicação de áudio/vídeo especifica.

2.

O browscr cliente examina a linha de cabeçalho de tipo de comeúdo da mensagem de resposta, lança o transdutor associado c passa todo o corpo da mensagem de resposta (isto é. o metarquivo) JX'I'll o trnnsdmor.

3.

O transdutor estabelece uma conexão TCP diretamente com o servidor HTTP e envia uma mensagem de requisiç:\o IITTP do arquivo de áudiof,1deo p;ua a concx:\o T CP O arqui\•o de áudio/vfdeo é enviado ao transdutor dentro de uma mensagem de resposta HTTP. O transdutor exibe o arqui\·o de áudio/vídeo de nuxo continuo.

A import:\ncia da etapa tntennedíária de aqutsição do met~\rqulvo ê clara. Ao ''criflcar o tipo de conteúdo do arquivo, o brO\\ SCr pode la nçar o transdutor adequado c, dessa m;mcira, fazer com que o transdmor contate diretamemc o servidor. Acabamos de aprender como um metarquh·o pode permitir que um transdutor dialogue diretamente com um servidor \.Vcb que armazena u m arquivo de áudio/vídeo. Ainda assim. muitas empresas que vendem prod u· tos que entregam :kudiolvfdeo de fluxo contínuo não recomendam
7.2.2 Envio de multimídia de um servidor de fluxo contínuo a uma aplicação auxiliar Como servidor de nuxo contínuo pode ser proprie1ário, ui como os comcrclalizados pela RcaiNetworks c pela Microsoft, ou pode ser de domínio público. Com um servidor de nuxo continuo, :ludio c vídeo podem ser e1wiados por UDP (c n;lo por TCP) usando protocolos de camada de rede que podem ser mais bem conrigllrados para :\udio/\·tdeo de Ouxo continuo do que o HTTP. Essa arquuetura requer dois servidores, como mostra a Figura 7 .2. Um dos servidores, o servidor \Veb, serve páginas Web (i ncluindo mctarquivos). O segundo servidor, o servidor d e fluxo contínuo. serve os arquivos de audíolvfdeo. Os doiS servtdorcs podem rodar no mesmo sistema final ou em dois sistemas finaiS distintos. As etapas dessa arquitetura são semelhantes às descritas na subseção antenor. Contudo, nesse caso o transdutor requisita o arquí\'O de um servidor de Ouxo contínuo. e não de um semdor Web, c o transdutor e o servidor de Ouxo contínuo podem interagir usando seus próprios protocolos. Esses protocolos permitem uma interação mais rica do usuário com o fluxo de áudio/vídeo.

bow4tto4ic~ Redes de co mp utadores e o Inter net

Cliente

Setvidores

Requisi(ao/respost
Browser Web

Transdutor

Servidor Web

+--{J)Arqu-.vo de iudioNideo requisitado e envia 3

•

Se rvido r de fluxo

conlfnuo

Figura 7.2 EnW> de ftuxo con~nuo de um sefVidor de fliiXo cootínuo poro um honsdutor Na arquheturn da Figura 7.2 há muitas opções para a em rega de áudio/vídeo do servidor de nuxo comínuo ao transdutOr. Uma lista parcial de opções é dada a seguir:

I.

O ;\udiotvrdeo t em•iado por UDP a uma t.axa consta nte igual à taxa de reproduçllo do receptor (que ta taxa codiricada p:tr:\ o áudio/vídeo). Por exemplo, se o audio for comprimido usando GSM a uma taxa de 13 kbps, então o servidor transmitira o arquivo comprimido de áudio a uma taxa de 13 kbps. Tão logo receba o áudioNtdco comprimido da rede, o cliente o descomprime c o reproduz.

2.

É igual ;\ primeiro opço\o, mas o trnnsdutor atrasa a rcproduç;\o de 2 a 5 segundos parn eliminar a variade atraso Induzida pela rede. O cliente reali ra essa tarefa colocando a mídia comprimtda que recebe da rede em um buffer cliente. como mostra a Figurn 7.3 . Tão logo tenha pré-capturndo alguns poucos segundos de mídia, o cliente começa a descarregar o buffer. Para essa opção, c também para a anterior, a taxa de prcenchtmcnto x( r) é igual ã taxa de saída d, exceto quando há perda de pacotes, caso em que x(r) ~ morncntanc:u nen tc menor que d. ~'âo

3.

A mídia é erwiada por TCP. O scl'\1dor lança o arquivo de mídia parn dentro da porta TCP o mais rápido posslvcl; o clicmc (isto é, o trat\sdutOr) IC: da porta TCP o mais rápido posslvcl c coloca o vrdco comprimido no buffcr do trnnsdutor. Após um atraso in icial de 2 a 5 segundos, o 1ransduto r I~ de seu buffer a uma taxa tl c repassa a mídia comprim ida para d escompressão c reprodução. Como o TCP rc transm ite pacotes perdidos, ele rem o porcncial de fom&er melhor qualidade de som do que o UDP. Por outro lado, a taxa de prccnchirncruo x(r) varia com o tempo devido ao cont role de congestionamento c ao controle de fluxo de janela do TCP. De rato, após perd a d e pacotes, o conLrolc de congestionamento TCP pode 8uffer

I

Da rede

Taxa de preench imento x(r )

=

Taxa de salda"' d Para descompress.'lo e reprodução

I

I

Dados de video pré-<.1pturados

Figura 7.3 Buffercliente preenchido o umo loxo x(t) e esvoziodo o umotaxo d


Redes multimídia

439

reduzir a taxa iltstrutt.'\nca a valores menores do que cl por longos pcrlodos de tempo. Isso pode CS\':lziar o bufTer cliente (um processo conhecido como inaniçào) c introduzir paus:lS indesejáveis na satda de uma correme de audiolvtdeo no cliente. [Wang, 2004) mostra que quando a vazão media do TCP e aproximadamente 2 vezes maior que a taxa média de bit, o fluxo conlmuo TCP resulta em ina nição mínima e batxos mveis de atrasos de partida. Paro a terceiro opção, o comportamento de x(t) dependem muiussimo do tamanho do buffcr cliente (que nao de,•e ser confundido com o bufTer de recepção TCP). Se o buffer ror grande o suficiente para conter todo o arquivo de mtdia (possivelmente por arm::tunagen\ em dísco). ctllâo o TCP ram uso de toda a largura de banda instantânea disponível para a conexão, de modo que x(l) pode se tornar muito maior do que d. Se x(l) pennaneccr muito maior do que cl por longos períodos de tempo, enlào uma grande porção da mídia ser~ pré-capturada para dentro do cliente e uma subsequente inanição do cliente será pouco provável. Se. por outro lado, o buffer c liente for pequeno, então x(t) flutuam ao redor da taxa de S."lida d. O risco de inanição do cliente é maior nesse caso.

7.2.3 RTSP(protocolode fluxo
encapsulamento paro mldia de fluxo conúnuo pode ser fornecido por RTP ou por um protocolo proprictáno. ( 0 RTP é discutido na Scç-Jo 7.4.) Por exemplo. os servtdorcs c os tmnsdutores da Real 1ctworks usam o RTSP para enviar informações de conlrolc reciprocamente. mas a corrente de mfdia em si pode ser encapsulada em pacotes RTP ou em algum formato de dados proprietário.

O RTSP não resLringe o modo como a mídia de nuxo contínuo é transportada; ela pode ser transportada por UDP ou TCP. O RTSP não restringe o modo como o 1mnsdu1or armazena o :iudio/vfdco. O áudio/vídeo pode ser repro· duzido logo qu e começa a chegar ao cliente, após um atraso de alguns segund os, ou pode ser descarregado imcgmlmcnte :unes de ser reproduzido. Ponanto, se o RTSP não executa nenhuma dessas funções. o que ele faz? O RTSP permite que Ltm transdutor controle a transmissllo de uma corrente de mídia. Como mencionamos há pouco. as :~ç()cs de controle incluem pausa/rclnlclo, rcposldonamento da reprodução, avanço e retrocesso r-.\pidos. O RTSP é um protocolo •fora da banda'. Em particular, as mensagens RTSP são enviadas fora da banda, :10 passo que a corrcmc de mfdia, cuja estrutura de J>acotc nJo é definida pelo RTSP. é considerada 'dentro da banda·. Mensagens RTSP usam o número de porta 544; a corrente de mfdia utiliza um número diferente. A espectO(.'aÇâo do RTSP (RFC 23261 permite que as mensagens RTSP sejam cnviad:lS por TCP ou UDP. Lembre-se de que o protocolo de transferência de arquivos (FTP - (Seção 2.3)) também usa a noção de roro da b:mda. Em panicular, o FTP usa dois pares de portas cliente-servidor, cada par com seu próprio tnímero de porta: um par de porl:lS clicme-scrvidor s uporta uma conexão TCP que tronsporla informações de comrolc: o olllro par de portas chcmc-servidor suporta uma concx

Servidores

Oiente

1'-=-....:=H:TT:-P_G_e_r____

Browser Web 14

Arquivo~ dtsuo(~

Servidor

Web

da apresenta(~

Setup ~-

Play

Transdutor

Corrente de mídia

Servidor demfdia

Pause ~

Teardown

Figura 7.4 Interação enh'e cliente e seMdor usondo RTSP rêncins a diversos arquivos de mtdia de taxa constante, bem como diretrizes para sincronização dos arquivos de mídia de taxa continua. Cada refer~ncia a um arquivo de mídia de taxa continua começa com o método URL, rtsp:/1. Fornecemos a scgutr uma amostra de arqutvo de apresentaç;lo que fot adaptado de [Schulznnne. 19971 . Nessa aprcsentaç-Jo. uma corrente de áudio c uma de vrdco sio reproduzidas em paralelo c com voz sincronizada (como parte do mesmo grupo). Para a corrente de áudio. o transdutor pode escolher (comutar) entre duns gravações de áudio, uma de baixa fidelidade c o utra de alta fidelidade. (O forma to do arquivo é semelhante ao SMIL ISMIL, 20091." que é usado po r muitos produtos de taxa conunua para definir apresentações si ncro n izad:~s de muhirnfdta.) O servido r Wcb cncapsula o arquivo de descrição da apresentação em uma mensagem de resposta I-ITIP c envia a me nsagem :10 browser. Quando recebe a mensagem de res posta f ITIP. o browscr invoca um t ransduto r (lsto é, uma aplic.:a ção :mxillar) com base no <::ampo de tipo de conteúdo da mensagem. O arquivo de descrição da aprcscntnção contém rd~rências :'is correntes de mídia, usnndo o método URL nsp:l/. como mostrnclo no exemplo anterior. Como ilustra a Figura 7.4. o transdutor c o servidor cnt:'lo enviam um ao outro um:t sl!rie de m~nsngcns RTSP. O trnnsclutor cnvin uma requisição RTSP SETUP c o servidor responde com uma mensagem RTSP OK O LmnsdULor envia uma rcquisic;i\o RTSP PLA Y. digamos, para á udio de baixa fidelidade e o servidor responde com uma mensngem RTSP OK. esse ponto. o servidor de nuxo contínuo bombeia o áudio de baixa fidelidade para dentro de seu próprio cannl 'dentro da banda'. Mais tarde. o transdutor envia umn requisição RTSP PAUSE e o servidor responde com uma mensngcm RTSP OK_ Quando o usuário termina, o transdutor envia uma requisição RTSP TEARDOW c o servidor confirmn com uma resposta RTSP OK.

Twlster

Redes multimldia

441

e-··P01U/8000/l " src - "rtsp: //audio . example .com/twl ster/audio. entl ofi··>

de

Agora vamos examinar rapidamente as mensagens RTSP propriamcme duas. Segue um exemplo slmplirlcado sess;:to RTSP entre um cliente (C:) c um remetente (S:).

tUIHl

C: SCTUP rtsp : //a udi o.example .com/ twister/audio RTSP/1.0 Cseq : I Transport : rtp/udp: compression: port 3056 : mode PLAY S: RTSP/1.0 200 OK Cseq : I Session: 4231 C: PLAY rlsp : //audlo . example .com/twister/audlo .en/lof i RTSP/1.0 Range: npt 0Cseq: 2 Sesslon : 4231 S: RTSP/1.0 200 OK Cseq:2 Session:4231 C: PAUSE rlsp://aud lo.example .com/twister/audlo .en/loff RTSP/1.0 Range: npt 37 Cseq: 3 Session: 4231 S: RTSP/1.0 200 OK Cseq: 3 Sess i on: 4231 C: HAROOWN rtsp://audfo.example .com/ tw fsterlaudlo .en/lo ff RTSP/1.0 Cseq : 4 Session: 4231 S: RTSP/1.0 200 OK Cseq : 4 Sessfon: 4231 ~ interessante notar as similaridades entre HTIP c RTSP. Todas as mensagens de rcquisiç-Jo c resposta S<'o em texto ASCII, o dicntc emprega métodos padronizados (SETUP, PLAY, PAUSE c assim por diante) c o servi· dor responde com códigos padronizados de resposta. Urna diferença importante, contudo, é que o servidor RTSP monitora o estado do cliente para cada sessão RTSP em curso. Por exemplo. o scr.,.idor monnora se o cliente está em um estado de imciahzação, um es~ado de rcproduÇ'.lo (play) ou um estado de pausa (ver a tarefa de programaç;lo ao final deste caphulo). Os nl1meros de sessão e de sequ~ncia , que fucm parte de cada requisição c resposta RTSP, :~judam o servidor :1 monitorar o estado da sessão. O número da scss:\o é fixo durante toda a scss.'lo; o cliente incrementa o número de sequcncia cada vez q ue envia uma nova mensagem; o servidor devolve um eco do número de sessão e do número de sequcocia corrente.


Como o exemplo demonstra, o dieme inicia a sess."10 com a requisiçõlo SETUP, fornece ndo o URL do arquivo que dc,·er.l ser transmitido c a versão do RTSP. A mensagem de estabclccimcmo (SETUP) inclui o n(lmero de pona do cliemc p
1.3 Fazendo o melhor possível com oserviço de melhor esforço O protoc:olo de c:amada de rede da Internet , IP, presta um servi ~·o de melhor es(orço. Isso quer dizer que o serviço faz seu melhor esforço para transportar cada datagrama da fon te ao destino o mais rápido possfvcl. Contudo, o serviço de mel hor esforço nada promete quanto à dimenSão do at raso a Om p-.1ra um pacote indivldual ou quant o à dimenSão da variação do atraso ou da perda d e pacotes dentro da corrente de pacotes. A falta de garanuas quanto ao atraso c à variação do atraso propOc desafios sagnifica tivos ao prOJeto de aphcac;Oes de muhimfdia em tempo real. como telefone por lmcrnet c 'ridcoconfer~ncia em tempo real, que s.1o muito scr\Sh•cis ;lo atraso. à variaç;lo do atraso e à perda de pacotes.

nm

Nesta seç;\o, examinaremos ''tlrios modos de melhorar o desempenho das apllcaçOcs rnihimfdias atra,·és de redes de melhor cforço. Nosso foco será em técnicas de aplicação de camadas, por exemplo, abordagens que m\o requerem mudanças no nuclco de rede ou atf na camada de aplicaç:\o até os hospedeiros de extremidades. Primeiro dcscrc,•eremos o efeito da perda de paco tes. alr.tSOS c a medida de variaç.1o de atr.1sos em aplicacocs muhhmd ias. Então veremos técmc-as para reparar tais falhas. Então descreveremos como redes de distribmção de conteúdo e super-provisionamem o de rccuros podem ser usadas para evitar tais falhas.

7.3.1

As limitações de um serviço de melhor esforço

Mencio namos que o serviço de melhor esforço pode ac.mctnr perda de pacotes. excessivo aLraso fim a fim c variac;;lo ele atmso. Va mos examinar esses assuntos com maiores detalhes. Para deix:umos essa discussão mais rl'al, discu tiremos os mecanismos no contex to de uma aplícação de telefone para Inte rnet, como desc rito abaixo. Esse exemp lo é similar para uma aplicação de conferência em vfdeo de tempo real. O a lto-falante no nosso exemplo de telefone pam Internet gera um sí ml de áudio que é formado po r pcrfodos a lternados de fal;ls c silêncios. Para conservar a banda, nossa aplica~·olo d e telefone para lnrcrnct gera um pacote ape nas durante os períodos d e fala. Durante o período de (ala, o transmissor gera b)•tes em uma velocidade de 8 .000 b)•tcs por segundo , e a cada 20 mscg o transamssor reune os b)•tes em blocos. Assim, o numero de bytes em um bloco é (20 mscg)·(S.OOO b)•tcs/scg) .. 160 bytcs. Um cabeçalho especial é anexado a cada bloco, sendo seu contcüdo d iscutido ab:lixo. O bloco c seu cabeç-alho s:1o encapsulados em um segmento UDP, através da interface socket. Dessa forma, d urante um pcrlodo de fa la, um segmento UDP é enviado a cada 20 mseg.

Se cada pacote chega ao receptor c tem um pequeno a traso fim a llm constante, então pacotes chegam ao receptor periodicamente a cada 20 mscg duranLc um pcrfodo dr fala. Nessas condiçOc:. ideais, o recepto r pode reproduzir novame nte cada bloco assim que chegarem . Mas, infelizmente, algus pacotes podem ser perdidos c a


Redes multimldio

443

maioria dos pacotes n:\o terá o mesmo atmso fim a fim. mesmo em uma Internet pouco congestionada. Por esta r.IZ~o. o receptor precisa ter mais cuidado para determinar (1) quando for o momento de reproduzir um bloco, e (2) o que fazer com um bloco perdido.

Perda de pacotes Consadcrc um dos segmentos UDP gerados por nossa aplicaç-Jo de telefone por Internet. O segmcmo UOP é encapsulado em um d:uagroma IP. Enquamo o datagrama vagueia pela rede. ele passa por buffcrs (isto é, por filas) nos roteado res, paro poder alcançar os enlaces de saída. É possível que um ou mais dos buffers na rota emre o remetellle c o destinatário estejam lotados c não possam aceitar o datagrnma IP. Nesse t.-aso, o d:uagrama IP será descartado c nunca chegará à aplica(':\0 receptora. A perda pode ser eliminada enviando os pacotes por TCP, em vez de por UDP. Lembre-se de que o TCP retransmile pacotes que não chegam ao destino. Contudo, os mecanismos de retronsmissiao frequentemente sao considemclos ínaceil:\vcis para 11plicações interativas de :iudio em tempo real, como o telefone por Internet, porque :nunenmm o :nraso nm a fi m [Bolot, 1996]. Além disso, devido ao controle e a n:lo ser que o ttsu:\rio esteja amls de um NAT ou de um ftrewall que bloqueia os segmentos UDP (nesse caso TCP t usado). Mas perder p:~cotes não é necessariamente tão grave quamo se possa imaginar. t a verdade, taxas ele perda de pacotes entre 1 c 20 por cento podem ser toleradas, dependendo de como a ' 'OZ é codiricada c transmitida c de como a perda é oculwda no receptor. Por exemplo, o mecanismo de correç;\o de erros de repasse (fonvcrrcl crror cot rcclion- FEC) pode a.Jud:~r a ocultar a perda de pacotes. Veremos mats :~diante que. com" FEC, a mformação redundante c transmitida jumo com a infonnaçâo original. de modo que parte dos dados originais perdidos pode ser recuperada da mfom1ação redundante. Não obstante, se um ou mais dos enlaces entre remetente e receptor estiverem fortemente congestionados c a perda de pacotes exceder 10-20 por cento (embora essas taxas raramente sejam obscn ·adas em redes bem pro,'isionadas), então, na realidade. nada poderá ser feito para conseguir uma qualidade de som aceitável. Assim, nca claro que o serviço de melhor esforço tem :.uas limitações.

Atraso fim o fim Atraso fim a fim e o act'unulo de atrasos de processamento, de transmiss.\o c de fom1aç;\o de mas nos roteadores; atrasos de prop.,gação nos enlaces e atrasos de processamento em sistemas finais. Para as aplica~·ões de :ludio altamente interativas, como o telefone por Internet, atraSO$ fim a fim mt norcs do que 150 milisscgundos não St10 percebidos pelo ouvido humano: atrasos entre 150 c 400 núlisscgLmdos podem ser aceit~vcis, mas m\o St1o o ideal, c :1tms0s que excedem 400 milissegundos podem atmpalhar seriamente a irnemtividadc em conversações por ''OZ. O lado receptor de uma aplit
Variação de atraso Um componente crucial do atraso fim a fim s.io os atmsos aleatórios de flln nos roteadores. Por causa desses atrasos vari;lvcís den tro d:a rede, o tempo decorrido entre o momcmo em que um pJCOte t gerado n:a fonte c o momento em que t recebido no dcsunatário pode '-anar de pacote para pacote Esse fe nômeno é denommado variação de a traso. Como exemplo, considere dois pacotes consecutivos de-ntro de uma rajada de voz em nossa aplicação de telefone por Internet. O remetente envia o segundo pacote 20 milissegundos após ter enviado o primeiro. Mas, no receptor, o espaçamento entre esses pacotes pode ficar maior do que 20 milissegundos. Para entender, suponha

bow4tto4ic~ Redes de tom putod ores e o Interne~1-----------------------que o primeiro pacote chegue a uma Cila de roteador quase v;uia, mas que, exatamente am~ de o segundo pacote chegar à llla, um grande nümero de pacotes vindos de outras fontes chegue à mesma ftla. Como o primeiro pacote sofre um pequeno atraso de flla c o segundo pacote sofre um grande atraso de fila nesse roteador, o primeiro e o segundo pacotes ficam espaçados em mais de 20 milisscgundos. O espaçamento entre pacotes consecutivos também pode flcar menor do que 20 milisscgundos. Para entender, considere JlO\'amcnte dois pacotes consceuth·os dentro de uma raj:lda de ,·oz. Suponha que o primeiro pacote se junte ao final de uma fila com um grande nümero de pacotes e que o segundo pacote chegue à Ria ames dos pacotes de outras fontes. Nesse caso, nossos dois pacotes se encontram um ex-atamente atr:ls do omro na fila. Se o tempo que leva pam lr.U\Smitir um pacote no cnlaee de saída do ro1cador for menor d o que 20 milissegundos, emão o primeiro e o segundo J)aCOICS Rc:uilo espaçados por menos de 20 mllissegund os. A siluaç:'lo é análoga a dirigir carros em rodovias. Suponha que voei! c um amigo seu, cada um dirigi ndo seu próprio carro, estejam viajando de San Dicgo a Phocnix, tenham um estilo semelhante de dirigir c mantenham a velocidade de 100 km/h, se o trMego existente pcnnhir. Por fim , suponha que seu amigo parta ltma hora antes de você. Ent
7.3.2 Eliminação do variação de atraso no rerc
Atrasar a reprvd11çilo de porcócs no receptor. O atraso da

Disculircmos agorn como esses trCs mecanismos, quando combinados, podem :11cmmr Oll até eliminar os cfcítos da ' 'ariaç:'lo de atmso. Examin:•remos duas estratégias de rcproduç~o: :~~raso ele rcproduç:lo fixo c :Hmso d e rcprod u~-:lo r~dapta t ívo.

Atraso de reprodução fixo Com a estratégia do atraso fixo, o receptor ten ta reproduzir cada porção exatamente 'I milissegundos após a porção ter s 1do gerada. Assim, se a marca d e tempo de uma por~,-.lo for 1, o receptor reproduz a por~lo no tempo 1 + q. admitindo-se que a porç-Jo já tenha chegado naquele instante. Os pacotes que chegam após seus tempos de rcprodu~-ao progmmados s.'lo descartados c considerados perdidos. Qual é uma boa escolha para q? Telefone por Internet pode suportar atmsos de até cerca de -tOO milissegundos, emborn com valores menores que q a cx~riência interati\'a resultante seja mais sausfatóna. Por outro lado, caso se escolha um tf muito menor do que 400 milissegundos, muitos pacotes podem perder seus tempos de reprodução programados devido à variação de atraso induzida pela rede. Em termos gerais, se grandes varia-


Redes multimídia

445

çõcs no atr:ISO fim :1 fim forem caraCieristícas. ser.! prcferfvcl usar um
Para o primeiro esquema de reprodução, o atraso inicial de reproduç;'\o est:\ est:~bclecido em 11 - r. Com esse esquema, o quarto pacote não chega dentro de seu atraso de reprodução progmmado e o receptor o considera perdido. Pelo segundo esquema de reprodução, o atraso inicial de reproduçolo fixo está estabelecido em 11 - r. Por esse esq uema, todos os pacotes chegam untes de seu tempo de reprodu(-;\o c, portanto. '"'o há perda.

Atraso de reprodução adaptativo O exemplo :mtcrior dcmcmstra um importante compromisso entre atntso c perda que s urge :10 se projell'tr uma estratégia de reprodu,·âo com atrasos de rcproduç~\o fixos. Ao se decidir por um atraso inicial de reproduçJo grande, a maioria dos pacotes cumprirá suas programações e, portanto, :1 perda será insignificante; contudo, para serviços intcrati\•Os como tcldone por Internet, atrasos longos podem s e tornar incômodos, se não lmoler.\vcís. Idealmente, gostaríamos que o atraso de reprodução fosse minimizado, mas que mantivesse a limitaç:\o de perda abaixo de uns poucos por cento. A maneira natural de tratar esse compromisso é estimar o atraso de rede c a vari:lncia de atrnso de rede e ajustar o :ttraso de rcproduç-Jo de acordo com o resultado. no infcío de cada rajada de \•Oz. Esse ajuste adaptativo de atrasos de reprodução no início das rajadas de voz fará com que os períodos de sil~ncto no receptor sejam comprimidos c alongados; contudo, compresSão c along:t mento de silêncio em pequenas quantidades não São percebidos durante a fala.

Tomando (Ramjec, 19941 como base, descrevemos agora um algoritmo genérico que o receptor pode usar para ajustar seus atrasos de reprodução adaptati\ramente. Para tal, consideremos: t,

= marca de tempo do i-ésimo pacote = o instante em que o pacote foi gerado pelo remetente

r 1 "" o Instante em que o p:tcote i ê recebido pelo receptor

1', ., o instante em que o t:>acotc ; é reproduzido no receptor Esquema de

reprodução p-r

Esquema de r eproduçlio p'-r

rp

Tempo

Figura 7.S Perda de pacotes poro diferentes otmsos de reprodução fixos

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------O atraso de rede fim a fim do i-ésimo pacote é r1 - t,. Devido a ,·a ri ação de atraso da rede, esse atraso varia rã de pacote a pacote. SeJa ti, a estimati va do atraso de rede médio para a recepção do r-tsimo pacote. Essa estimatÍ\'ll é obtida das marcas de tempo como segue: d, = (1 - u) d,

1

+ u( r1 - t,) ,

onde 11 é uma constante llxa (por exemplo, 11 = 0,0 1). Assim, d, é uma média ajustada dos atrasos de rede obser\'a· dos r, - 1,. .•.• , , - t,. A estimatÍ\'ll atribu i maior peso aos atrasos de rede \"Cri ficados maiS recen temente d o que aos atrasos de red e ocorridos no passado d istante. Esse modelo de estimati va não de\'e ser tão fora do comum: uma idcia semelhante é usada para eslim;tr os tempos de viagem de ida c volta no TCP, como discutido no Capitulo 3. Seja v uma estimativa do desvio médio do atraso em relação ao atraso médio estimado. A es timativa também é ob tida com base nas marcas de tempo: ' ', • (1 - u)

v,., + 11 I r·, -

1, -

cl,l.

As estimativas cl, e v1 s:lo t-akuladas para todos os p:tcotes recebidos, em bom somente scj:un usadas para determinar o ponto ele rcproduCt'o para o primeiro pacote em qualquer rajada de ' 'Ot. Um a vez t-akuladas cs..'ias es tima tivas, o receptor emprega o seguinte algoritmo para a reprodução d e paco tes. Se o pacote i for o primeiro pacote de uma rajada de vo~. seu tempo d e reproduç •.o f',será computado como:

= t, + ti, + Kv,, onde K é uma cons tante positiva (por exemplo, K = 4). A fi nalidade do termo Kv, é estabelecer o tempo de [11

reprodu\"
q, = P, -

I,

a duração do tempo decorrido desde a geração do primeiro pacote da rnjada de vot ate sua reprodução. Se o pacote 1 também pertencer ~~ essa raj
P,"" t, + q,. O algorilmo que acabamos de descrever tem perfeilo sentido admitindo-se que o receptor possa dizer

se um pacote é o primeiro pacote na rajada de voz. Se não houver perda de pacotes, então o receptor poderá determinar se o pacote i é o p rimeiro pacote da rajada de voz compa rando a marca d e tempo do 1-és rmo pacote co m" marca de tempo do pacote de ordem ( i - I). Realment e, se 1, - t, 1 > 20 milisscgundos, então o receptor sabe que o í-ési mo pacote inicia Lima nova mjada de voz. Mas suponha agorn que haja uma perda de pacote ocasional. Nesse caso, dois pacotes s ucessh•os recebidos no d estino podem ter m:~rcas de tempo que diferem de mais d e 20 mil isscgu ndos qu:mdo os dois paco tes pertencem à mesma rajr~d:1 de voz. E é nesse caso que os numcros de scqui!ncia são p:trLicularmcnLe úteis. O receptor pode usar os números de scqut nci;t para d etermi n:1r se u ma diferença de mais ele 20 milissegundos nas marcas de tempo é devida a uma nova rajada de votou a pacotes perdidos.

Áudio e vídeo de fluxo conlínuo armazenados Vamos co ncluir esta sccâo falando um pouco sobre nu xo cont inuo de áud io e vídeo arm:ucnad os. Aplicações de nuxo co ntinuo de áudío/vrdeo nrmncnado também usam , tipica mente, nu meros de seq uêncía, marcas de tempo c :uraso de rcproduçilo para aliviar ou até elimi nar os efeitos da vari :~ç:'lo d e atraso da rede. Contudo, há urna importante diferença ent re ãudio/\'ideo interativo em tempo re:tl e fluxo co nt inuo de á udi o/ vfdeo armazenado. EspcciOcarneme, fluxo cont inuo de :lud ioNfdco pode tolerar atrasos signifi cativamente ma1orcs. De fato, quando um us u;trio requisita um clipe de á udio/vídeo. ~ prov:\vel q ue ele ache aceitável espera r 5 segundos ou mais ames que a rcproduç;.1o se inicie. E a ma1on a dos usuários pode tolerar atrasos semelha ntes após ações interativas, como um sal to temporal den tro de uma corrente de midia. Essa tolerãn· da maior ao atraso dá ao desenvolvedor d e aplicações maior Ocxibilidadc ao projetar apl icações de mídias armazenadas.


Redes multimídia

447

7.3.3 Recuperação de perda de pacotes Já d1scutimos com algum detalhe como uma aplicaçlio de telefone por lmernet pode hdar com a \'ariaçlio de atraso de pacote. t\gora, descreveremos brevemente diversos esquemas que tentam preservar uma qualidade aceitável de áudio na presença da perda de pacotes. Esses esquemas S;\O denominados esquemas de recuperação d e perda . DeOnunos aqu1 a perda de pacotes em um sentido amplo: um pacote ser.\ considerado pcrd1do se nunca chegar no receptor o u se chegar após o tempo de reprodução programado. Nosso exemplo do telefone por Internet servint outra vez de contexto para a descrição de esquemas de recupcraçi\o de perdas. Como mencion:unos no início desta seç-.lo, em gemi n retmnsmiss<\o de pacotes perdidos nilo é apropriada para aplicnções interativas em tempo re.1l como telefone por Internet. Na verdade, a retransmissão de um pacote que perdeu seu prazo de rcproduçâO 11ão serve p;\ra absolutamente nada. E a rctrniiSmissM de um pacote que tnlnsbordou de uma OI:~ de rote;~dor normalme nte nA o pode ser feil:l com a necessária rapidez. Devido a essas considerações, aplicações de telefone por Internet frequentememc usam alglllll tipo de esq uema de prevenção de perda. Dois desses esquem;:~s st\o a FEC e a intercalação.

FEC (correção de erros de repasse) A ideia b:isiea da FEC é adicionar informações redundantes a corrente de pacotes original. Ao custo de a umentar m;:~rgi nahnente a 1~1xa de 1rnnsmissâo do áudio da correm c, a inrormaçâo redundante pode ser usada para reconstruir aproximaçOes ou versões exatas de alguns pacotes perdidos. Esboçamos, agora, dois mecanismos de FEC segundo [Bolot, 1996( c (Perkíns, 19981. O primeiro mecanismo erwia uma porção red und3nte codifictda após cada n porçOcs. A porçi.\o redundamc é obtida por XOR das 11 porçocs originars [Shacham. 19901. Dcs5c modo. se qualquer JX\C(Ile do gnrpo de n + ljXK'Otes for perdido, o rttt'ptor poderá recoriSlruir íntegrnlmcnte o pacote perdido. Mas, se dois ou mais pacotes de um grupo forem perdidos, o receptor mlo poder-.1 reconstruir os pacotes perdidos. Mamendo 11 + 1 (o t3manho do grupo) pequeno, uma grande fração dos pacotes perdidos pode ser recuperada, quando a perda nilo for excessiva. Contudo. qltanto menor o tam:~nho do grupo. maior scn1 o aumento relativo da taxa de transmissão da correme de áudio. Em particular. a taxa de transmissão aumenta de um fator de V11 ; por exemplo, se 11 .. 3 , em:\o a taxa de transmissão aumenta 33 por cento. Além disso. esse esquema simples ~mmt>nta o atraso de rcproduç;,o, pois o recep1or tem de esperar o término da recepç:'lo do grupo de pacotes imeiro ames de poder começar a reproduzir. Se o leitor quiser mais detalhes práticos sobre como a f EC funciona para transpone de muhimldla, consulte [RFC 2733].

O segundo mecanismo de FEC é enviar uma corremc de áudio de rcsolu~':'lo mais bülxa como infonnaçlio redundante. Por exemplo, o remetente pode criar uma corrente de áudio nominal c uma corrcme de áudio correspondente de baixa resolução e baixa taxa de bits. (A l'Orrcme nominal poderia ser uma codificnçJo PCM de 64 kbps c a corrente de qu;tlídadc mais baixa, uma codificação GSM de 13 kbps.) 1\ con·entc de baix:~taxa de bits é denominada corrente redundante. Como mostra a Figurn 7.6, o remetente constrói o cr1 ~imo pacote tomando a enésima por~ào d:~ COITCntc 110minal c anexando a ela a porçào de ordem (n - l) d:1 corrente redundante. Dessa mancim, sempre que houver perda de pacote mlo consecuti\•a, o receptor pode ocuhar a perda reproduzindo a porc,ilo codificada de balx;~ taxa de bits que chegar com o pacote subscqucmc. f: eviden te que as porções de baixa t:txa de bits oferecem qualici;Jde nmis baixa do que as porções nominais . Con tudo, uma corrente '"' qual a maioria das porções é de alta qualidacle, as porções de ooixa qualidade Si\0 ocasionais C nenhuma por\'àO é pcrdid:t oferece boa qualidade geral de áudio. Note que, nesse esquema, o receptor tem de receber somente dois pacotes antes da reproduç.\o, de modo que o aumento no atraso de reprodução é pequeno. Além disso. se a codiOcaç;'o de baixa taxa de bits for muito menor do que a codiOCI~o nomin31, o aumemo marginal da taxa de transnu~o será pequeno. Para enfrentar perdas consecutivas, podemos u tilizar uma variação s imples. Em \lez de ane.xar apenas a porç-.lo de ooixa taxa de bits de ordem ( 11 - l ) ã enésima porção nominal, o remetente pode ;:~ncxar as porções de ba1xa tax3 de bits de ordens (n - 1) e (n - 2) ou anexar as porçóes de b.1ixa taxa de bits de ordens (n - 1) c (n - 3) c assim por diame. Anexando mais porções de baixa taxa de bits a c:~da porç:lo nominal, a qualidade do áudio no receptor fica aceitável para uma \'ariedadc mais ampla de amb1en1es de melhor esforço adversos. Por outro lado, as porções adicionais aumentam a largum de banda de tr3nsmissão e o atraso de reprodução.


Corrent e original

'' '' ' •'

perda

Corrente t...,...-'--.---..1 re
Corrente re
Figura 7.6 DondoCOIOIIO õ ínformo~õo 1edundonte de qvolidode mois boíxo RAT IRAT. 20091 é um:~ nplietwüo de telefone por Internet bem doc umentada que usa t=EC. Ela pode transmitir correntes de áudio de qualidade mais baixa juntamente co m a co rrente de á ud io nomi nal, como descrito a ntes. Veja t;m1btm [Rosenberg, 2000).

lnler(ola~ão Como uma altemauva à transmissão redundante, uma aplicação de telefone por Internet pode envsar áudio intercalado. Como mostra a F1gura 7.7, o remetente rcarranJa a sequfncia das umdades de dados de áudio antes da trnnsm•ss:'lo, de modo que unidades originalmente adjacentes fiquem separadas por uma cena distância na corrente transmitida. A intercalação pode atenuar o efeito da perda de pacotes. Se. por exemplo, as unidades têm comprimento de 5 milissegundos c as porções sâo de 20 milissegundos (isto 1!, 4 umdadcs por porç:\o), então a pnmeira porção pode conter umdadcs 1, 5, 9 , 13: a segunda porção pode con ter unidades 2, 6 , 10. H , c assim por diante. A Figura 7. 7 mostra que a perda de um unico paeote de uma corrente intercalada resulta em várias

Corrente

,_...a..,....-1-,-.L..-.t _....J-~1--.....,..-'-r original

Corrente int ercalada I I I I

+

I

I I

I

+

I

' I I

+

I

'II + Corrente recebida

Corrente reconstrvlda


Redes multimídia

449

pequenas lacunas na correme re<.'Onstnúda, em vez de em uma úni ca lacuna grande que ocorreria com um sistema não interçalado. A intcrcah•ç-Jo pode melhor.u significativamente a qualidade percebida de uma corrente de áudio IPcrkins, L998l . Além disso. a sobrectrga é baixa. A desvantagem óbvia da intercalação é que ela aumenta a lat!ncia, o que limita seu uso em aplicações imcmtÍ\'aS corno o telefone por Internet, embora possa funcionar bem pam Ouxo contínuo de áudio armazenado. Uma importante va ntagem da imercalaç-.lo é que ela n:\o aumenta as cxig~ncias de largura de banda de uma corrente.

Reparação de correntes de áudio danificados realizado no reaeote :tdequ:•do para cobrir a perda. Ela funciona um pouco melhor do que n repetição de pacotes, mas é significativamente mais trabalhosa pnm proces· sarnento [Perkins. 1998).

7.3.4 Distribuição de multimídia: redes de distribuição de conteúdo Com 1axas de vídeo em nuxo con1inuo na faixa de centenas ele kbps parn vídeos de baixa resolução até ,·anos Mbps para vídeo em OVO. a tarefa de transmitir um vfdco armazenado em Ouxo contínuo, sob demanda, a um grande numero de usuários distribuídos geograficamente é um desafio e tanto! A abordagem mais simples seria armazenar o vídeo em um único servidor e s implesmente transmiti-lo de um servidor de vídeo (ou de uma unidade lógica de proccss.1memo corporativo - sen•er farm) a um cliente, para cada rcquisiç:\o de cliente, como foi discutido na Seção 7.2. Mas há dois problemas óbvios ncssn solução. Em primeiro lugar, como um cliente pode estar muito distante do sen'idor. os pacotes de ~rvidor parn o cliente podem t>ass:~r por muitos ISPs, aumentando n probabilidade de atrasos e perdas significativos. Em segundo lugar. se o ' 'ldco ror muito popular. pro,•nvelmentc sem enviado muitas vezes atravts dos mesmos ISPs (c pelos mesmos enlaces de comunicação). consumindo, por conscguin1e, largura de banda significaliva. No CapHulo 2 discutimos como o cache pode aten unr esses problemas. Embora tenhamos discutido cachc em termos do contet'tdo trnclicional dn Wcb, deve ficar claro que ele Ullnbém é llpropriaclo para con teúd o ele mu h im!di;,, como <\ udio c vídeo armazenados. Nesta sec;ào, discutiremos redes de dis tribuição de conteú do (colltt nt rlistribut1on ucrworhs- CDNs), que orerecem uma nbordagem ulternmiva à distribuição de conteúdo de multimCdia arma zenado (bem como i\ dislribui~--:\o de con teúdo Web tradicional). A filosofia básk:t das CDNs é que. se o cliente não pode vir até o comeMo (porque o caminho de melhor esforço do cliente ao scn·idor não pode suportar vídeo ele Ouxo co ntínuo) , etwlo o conteúdo deve ser levado até o cliente. Assim, CONs usam um modelo diferente do cachc na Web. Pnm uma CON, os clientes pagantes não são mais as lSPs, mas as provedoras de comeúdo. Uma provedora de conteúdo que tenha um video p;1m distribuir (tal como :1 CN ) paga a umn empresa CON (como a Akamai) para levar se u v!deo até os usuários requisitantes com os menores a1msos possfve1s. Uma empresa CON tipit":lmentc prove seu serviço de distribuiç.\o de conteudo da seguinle maneira: I.

A empresa de CON instala centenas de servid ores CON por toda a Internei. Em gemi a empresa instala seus servidores CDN em uma central de dados, que muitas vezes estão em ISPs de mvel mais baixo, próximas às redes de acesso ISP e aos clientes.


2.

A CDN duplirn o comelido de seu cliente nos servidores CON. Sempre que seu cliente atualiza seu conteudo. a CD1 redistribui o conteúdo renovado aos servidores C DN.

3.

A empresa CO provê: um mtGinismo que entrega. :1 um cliente Web que tenha requisitado, conteúdo pelo serv1dor CD. que melhor possa atendê-lo. Esse servidor pode ser o que estiver ma•s próximo do cliente (talvez no mesmo ISP) ou pode ser um servidor CDN cujo rnminho até o cliente está livre de congestionamento.

A Figura 7.8 mostra a interação entre a pron:dora de contcudo c a empres:l CON. A pro\'edora de comeúdo primeiro determma qual de seus objetos (por exemplo, vfdeos) ela quer que a CON d•stnbua. (A pro"edorn de conLcudo distribui os objetos remancsccmes sem a intervenção da CON.) A provedora de contclldo roiUia o cometido c em:lo o envia para um nó CDN, que, por sua vez, duplica esse comcúdo c o retransmitc para todos os seus servidores CDN. A cmprc:sa CDN pode se r proprieL.'Í:ría de uma rede privada que lc\'ar:l o conteúdo do nó CDN até os servidores CDN. Semt>re que a provedorn de conteúdo modi(k-aum objeto disLribufdo pela CDN , ela envia a versão atu:tlizada ao nó CDN, q ue, m;lis uma ''ez imediatamente duplica e dis lriblti o obje to aos servidores CDN. é importante ter em mente que cada servidor CO l normalmente contém objetos ele muitas provedoras de conteliclo. Agor:• surge a pcrgurua intcressame. Quando um browscr no l10spedelro de um us uário recebe Instruções parn extrair um objeto especifico (iden ti ficado por um URL), como o browscr deter mina se deve extrair o objeto do servidor de origem ou de um elos servidores CDN? Normal mente as CDNs mi liza m redirecionamento ONS para guiar os browscrs até o servidor coneto IKa ngasha1ju. 2000). Suponha, por exemplo, que o nome de hospedeiro da servidora de co ntclido seja ~tww . foo . com. Suponha que o nome da empresa CDN seja c dn . com. Suponha ainda que a provedom de conteúdo quer que somente seus arquivos de vrdco mpcg sejam distribufdos pela CD ';todos os outros obJetos, inclumdo as páginas de base IITML, são distribuídos direL.'lmcmc pela provcdom de contct\do. Pa m conseguir isso, a provedora de conteúdo modificn todos ~ objetos HTML no servidor de origem de modo q ue os URLs dos arquivos de vldco tenham o prefixo h t t p : //www . cd n. com. Assim. se um arquivo HThiL na pro\'eelora de conteüdo tinha, originalmente. uma rcfcrtnc•a a htl p://www. f oo . com/s po rts/ h i ghl ig hts . mpg. a provedora de conteúdo rotularia esse objeto subsutt~~ndo a rcfcrtneia no arquh·o HT~L por h ttp: //www . cdn . com/www. foo . com/sports/ h ighl ig hts . mpg.

Servidor de origem na América do Norte

Nó de

distribuição da CON

Servidor CON na América do SUl

servidor CON na Ásia Servidor CON na Europa

Figuro 7.8 ACONenvio o seusservidores CON objetos rotulados do provedora de conteúdo


Redes multimídia

451

Qu:mdo um browscr requíslla uma página Wcb que contém a imagem ruth.mpg. ocorrem as scguímcs ações:

1.

O browscr envia sua requisição para o objeto base HTML ao servidor de origem www. foo . com. que cm•m o objeto IITML requisitado ao browscr. O brov.-scr analis.1 o arqul\'0 IITML c encontra a referência a http : //www.cdn.com/www .foo . com/sport s/highlights . mpg.

2.

O browser cnt:lo rtU uma consulta DNS em www. cdn . com, que é o nome de hospedeiro para o URL referenciado. O DNS é configurado de modo que todas as cons ulta:. sobre www. cdn. com que chegarem a um servidor DNS raiz sejam enviadas a um servidor DNS com au10ridade para www. cdn . com. Quand o o servidor DNS com autoridade recebe a consulta. exttai o endereço IP do browser requisit.11lle. Usando um mapa in terno da rede que constmiu para toda a Internet, o senidor D~Sda CDN retoma o endereço lP do servidor CDN que JXlr~ str o melhor txtra o brO\'>'SCJ' requisit.'lllle (muitas vezes é o servidor CDN mais próximo do browser).

3.

O DNS no cliente requisitante recebe uma resposta DNS com o endereço IP. O browscr então envia sua requis i ~·ão I ITTP ao servidor CDN que tem aquele c ndcre~·o IP. O browser obtém rulh.mpg de se LI sen•idor CDN. Pam requisições s ubscquentes de w1·1w . cd n. com, o cliente eonti11ua a usa r o mesmo scn•idor CDN. j:l que o endereço IP p;~ra ~~~~w . c
Em s um a, corno ilustrado na Figura 7.9, o hospedei ro requísitamc primeiro vai ao servidor Web de o rigem para obter o objeto base tlTML, em seguida vai :ué o servidor DNS com amoridflde pcrtcnccmc ;\ CON p:1rn obter o endereço IP do melhor servidor CDN c, finalrncme. \W até aquele servidor CDN par-.1 ob ter o vídeo. Note que. pilra implemcnt.'lr esse esquema de disttibuiç;.io, não é preciso r;\ztr nenhuma mud;tn~'3 no HTrP. no DNS ne m no browscr. Ainda resta explicar como uma empresa CON determina o ' melhor' servidor CON para o hospedeiro requiSll.'lnte. Embora cada empresa CDN tenha seu modo proprietário cxcluSI \'O para razer ISSO, n:lo t diric•l ler uma idcia aproximada do que elas f:tzem . A empresa CON monitora o melhor servidor CDN para cada acesso ISP n
Servidor de origem

""""'. f.oO ·

Consulta DNS para www.edn .eQIII

0------!';\

Figura 7.9 ACONuso ONS poro direcionor requisições o um servidor CDN próximo


7.3.5 Dimensionando redes de melhor desempenho paro fornecer um serviço de qualidade Em seções anteriores, vimos como téc nicas de mvd de apli~-ação como reprodução de pacotes, FEC, pacotes intercalados nos hospedeiros. c uma estrutu ra CDN implementada através de rede. podem melhorar a qualidade de aplicaçOcs muhimidias na Internet de melhor esforço hoje em dia. Fund;~mentalmcnte. a dificuld;~dc de suportar aplicaçoes multimídia surgem de suas restritas cxigéncias de desempenho- baixo atraso de pacote fim a fim. \'
a tingir um determinado desempenho fim a fim é frequentemente conhecido como provisionamento de banda. O problema mais complicado de como se projetar uma topologia clc rede (no mometn o em qu e colocar roteadores. como interconcctar roteadores com enlaces, e que capacidade designar aos enlaces) p:1ra obter um determinado dcsempenho fim a fim é um problema d e projeto d e rede, normalmente conhecido como di mensionamento de rede. Ambos prO\'isionamcnto de banda e dimensionamento de rede são tóp1cos complexos. muito além da finalidade desse hvro-tcxto. Enfatizaremos aqui. no en tanto. que os segumtcs assuntos devem ser abordados para prever o desempenho de mvel de aplicação entre dois te rminais de rede, ass1m providenciando capacidade suficiente para adequar-se às exig~ncias de dcscmpe1tbo da aplicaç-Jo.

Moclrlos dr drmcuulCI ele lrdfcgo C'lllrc lcrminCiis de rede. Modelos prcc1sar.\o ser especificados tanto no mvel de chamada (por exemplo, usuários •chegando" à rede c iniciando suas aplicações fim-fim), q uanto no nfvel de pacote (por exemplo, pacotes sendo gerados em aplicações em andamento). Observe que a carga de trab.tlho pode mudar a través dos tempos.

E.Yigl'nrias ele d~srmt>rnho drfruidas. Por exemplo, a exigência de desempen ho para suportar tráfego sensível ao atraso, como uma aplicação interativa de áudiof,•ídeo, pode ser que a probabilidade de a traso fim-fim sofrido pelas mensagens da aplicaç;to seja maior que o limite rm\xhno tolerável de atraso, seja menor que um valor pequeno, e IFraleigh, 20031. Mocle/os pam prc~

Redes multim ídia

453

[Oavics. 2005). Para uma pcrspcctí\'3 sobre o fornecimento de redes backbone para suportar o tráfego de atraso sensh•cl. veja (Fralcigh, 2003) .

7.4 Protocolos poro aplicações interativos em tempo real Aplicações interativas em tempo real. incluindo telefone por Internet e vidc:oconfc:r~ncia. prometem liderar grande parte do crescimento futuro da Internet. Portanto. não é surpresa que organismos padronizadorcs, tais como a IETF c: o ITU, tenham se ocupado du rante tantos anos (e ainda se ocupem!) com a prod uç;lo d e padrões para essa classe de aplicações. Tendo ~ mão pad rões apropriados para aplicações interativas em tempo real, empresas inclcpenclcn tes podemo criar novos produtos atraentes que intcragcm uns com os o utros. Nesta seção estudamos RTP, SIP c H.323 pam aplicaçõeS interativas em tempo real. Todos os tres cO nJuntos de padrões estão sendo im plementados amplamen te em produtos do setor.

7.4.1

Prolocolo de tempo reol (RTP)

Na scç:lo antCI'ior. Ortc. Esses c:1111pos de calxçalhos contem mlmeros de scquencia c marcas de tempo. Já que a maioria das aplkações de rede muhimfdia pode fazer uso de m1 meros de scquencla c de marcas de tempo, é conven icm e ter uma estrutu ra de pacote p11dronizada que incluíl campos para dados de áudio/vidco, números de sequCncia c m:•rcas de tempo, bem como ouLros c:unpos potencialmente úteis. O RTP. dennido no RFC 3550. é um p<~d r-ao desse tipo. Ele pode ser usado para transportar formatos comuns como PCM. GSM e MP3 para som e MPEG e H.263 pam vfdeo. O protocolo também pode ser usado para transportar formatos proprietários de som c de vídeo. Hoje, o RTP é amplamente implementado em centenas de protótipos de produtos c de pesquisa. Também é complementar a outros importantes protocolos imerativos de tempo real. entre eles SIP e H.323. Nesta scç.io, faremos umíl introduç.io ao RTP c a seu protocolo companheiro. o RTCP. Também aconselhamos o leitor a v1sit<1r o sne de licnning Schulzrinne ISchulzrinne. RTP 2009). que trata do RTP e tmz uma profu são de infonnaçõcs sobre o assu nto. O leitor também poderá visitar o site da RAT (RAT, 2009) . que documenta uma aplicaçlo de telefone por Internet que usa RTP.

Obásico do RTP O RTP comumente roda sobre UDP. O lado remetente encapsula uma porçllo de mídia dentro de um pacote RTP. em seguida encapsul:1 o pacote em u m segmento UDP, c ent;lo fXIS~a o segmento pam o IP. O lado receptor cxtrui o p:1eotc RTP do segmento UDP, em seguida extrai n porção de mfdi::t do pacote RTP c então passa a porção

para o 1ronsdu10r pam decodil'ica~-:'lo e apresentação. Como exemplo, considere a utilização do RTP para transporta r voz. Suponha q ue a fon te de voz esteja cod ificada (isto ~ . amos trada, quantizada e digita lizada) em PCM a 64 khps. Suponhn tam bém que a aplicação colete os dados codificados em porções de 20 milissegundos. isto <:, 160 bytcs por porç;\o. O lado remeteme precede cada porç;\o dos dados de •\udio com um cabeçalho RT P que cont~m o tipo de codific.1çllo ele ;\udío, um n úmero de seq utncla c unm m:.rca de tempo. O tamanho do cabeçalho RTP ~normal me nte l2 bytes. A porção de áudio. juntamente com o ealxçalho RTP. forma o paco te RT P. O pacote RTP ~. C:JW\o, enviado para dentro do sockc:t de interface: UOP. o líldo receptor, a ''plica<;;\o recebe o pacote RTP díl in tcrf;~ce do seu sockct. A aplicílç;\o extrai a por\-10 de áudio do JXICOte RTP c usa os campos de calxçalho do paco te RTP para decodificar c reproduzir adequadamente a porç-.lo de :ludio.

Se um:. apltc:açâo incorporar o RTP- em vez de um esquema proprieto\rio para fomecer tipo de carga util. númerode sequtnem ou marcas de tempo-. ela mtcragirã mais factlmcnlc com as outr.l> ílplicaçõcs de rede muhimrdia. Por c.xcmplo. se duas cmprcs.1S diferentes desenvolvem um software de telefone por lntemet c ambas incorporam o RTP a seu produto. pode haver alguma chance de um usuário que estiver usando um dos produtos de telefone por Internet conseguir se comunicar com um usuario que estiver usando o outro produto de telefone por Internet. Na Seção 7.4.3, veremos que o RTP é mui to utilizado em conjunto com os padrões de telefonia por Internet.

bow4tto4ic~ Redes de co r11 putod ores e o In;.;l~e;.; rn ;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Devemos enfatizar que o RTP não fornece nenhum mecanismo que assegure a entrega de dados a tempo nem fornece o utras gar.tntias de qualidade de serviço (QoS): ele não g<~rante nem mesmo a entrega dos JXICOICS nem impede a entn:ga de pncotcs fom de ordem. Na ,-ercJade, o encapsulmnemo realizado pelo RTP é ' 'ÍSIO somente nos sistcm<~s fin:•is. Os roteadores n~o distinguem datagramas IP que carregam JXICOtes RTP de datagramas IP que nào os carregam. O RTP permite que seja atribuída a cada fonte (por exemplo, uma câmera ou um microfone) sua própria corrente mdependente de pacotes RTP. Por exemplo, para uma vidcoconferênc:m entre dois parLtcipantes, quatro correntes RTP podem ser abertas- duns correntes para transmitir o áudio (uma em cada dircç-.lo) c duns correntes para trans mitir o vídeo (uma em cada direção). Contudo, muitas tfcnicas de codificaç.\o populares- incluindo MPEGl c o MPEG2 - conjugam ;~udio c vfdco em uma única corrente durante o processo de codif'icaç;lo. Quando áudio c vídeo são conjugados pelo codif'icador, somente uma corrente RTP é gerada em cada direção. Pacotes RTP nào s;\o hmitados às aplicações cmica$t. Eles podem também ser enviados JX>r ál'\•orcs rnulticnst um-para-muitos c muitos-para-muitos. Para uma scss.\o multicastmuilos-pam-multos, todos os remetente-S c fon · tCS da sess.\o em gemi usam o mesmo grupo mulllwsr para enviar suas correntes RTP. Correntes rnulll wst RTP que fornmru um conjunto. como corrcmes de áudio e vfdeo que emanam de V<1r ios remetentes em uma aplicaç;e,o de vitleoconferCncia, pertencem a unm sessão RTP.

Campos de cabe~ olho do pacote RTP Como mostra a Figuro 7. 10 , os quatro principais campos de cabeçalho do p;•cotc RTP s.'o os campos de tipo da carga útil, numero de sequência, marca de tempo e os campos itlcntiftcadores da fome . O c:unpo de tipo de carga útil do pacote RTP tem 7 bits de comprimento. Para uma corrente de áudio, o campo de tipo de carga útil serve para indicar o tipo de codif'icaç-.io de áudio (por exemplo, PCM. modulação delta adaptativa, codificaç-.lo por prc,•is.io linear) que está sendo usado. Se um remetente decidir mudar a codificaç!io no meio de uma sessão, ele poderá infom1ar a mudança ao receptor por meio desse campo de tipo de carga útil. O remetente pode querer mudar o códtgo para aumentar a q ualidade do áudio ou P••ra reduzir a taxa de bits da cor· rente RTP. A Tabela 7.2 apresenta alguns dos tipos de carga util de :ludio correntemente suportados pelo RTP. Para uma corrente de vidco, o tipo de carga ínil é usado para indicar o tipo de codificação de vídeo ( por exemplo, JPEG com movimcmo, MPEG 1, MPEG2, 1-1.261). Novamente, o remetente pode mudar a codificação de vídeo durante a sessão. A Tabela 7.3 apresenta alguns llpos de carga úlll de vídeo awalmcnte suportados pelo RTP. Os outros campos import:1rues s.\o:

CltmtJO elo urímcro de srqttêncicr. O campo do número de srquência tem comprimento de 16 bits. O numero de scquencia I! incrementado de uma unidade a cada JXlCOte RTP enviado c pode ser usado pelo receptor pam detectar perda de pacotes c restaurar a scqt•ência de JXICOtcs. Por exemplo, se o lado rec:eptor da apli~•e;io receber uma con·cntc de pacotes RTP com lu na lacuna cnlrc os números de scqu~ncia 86 c 89, enuio o rC\:cptor saberá que os p:•cotes 87 c 88 estào f.1hando. O receptor podcr.l, cnt;lo, tentar ocultar os d~dos prrdidos.

Campo ele mw·w 1lc trmpo. O campo de marca de tempo tem 32 bits ele comprimento. Ele reflete o instante da amostragem do primeiro byte no pacote RTP. Como ' 'imos na seção anterior. o receptor pode usar marcas de tempo p:tra eliminar a variação de atraso elos p;1cotcs i111roduzida na rede e forncct:r rece pç;lo sincronizad<~ no receptor. A marca de tempo é derivada de um relógio de amostragem no remetente. Como exemplo, pam áudio, o relógio de marc-:1 de tempo é incrementado de uma unidade para cada periodo de amostragem (por exemplo, a cada 125 mierossegundos para um relógio de :~mos tmgem de 8 kllz); se a aplicação de áudio gerar porções cons1stmdo em 160 amostras codtf'icadns, então a marca de tempo aumentará em 160 para c-.tda pacote RTP enquanto a fonte estiver ativa. O relógio de marc.t dc tempo continua a aumentar a uma taxa constante, mesmo que a fonte esteja inativa. Tipo de carga útil

Número de sequenda

Figura 7.1 O Compos de cobeçolho do RTP

Marca de tempo

Identificador de sincronizac;llo da fonte

campos variados


Formato de ádio

Toxo de omostrogem

o

PU.\ lei~~

I

1016

3 7

GSM

9

6.722

14

Áuct.oMPEG

lS

6.728

8kHz 8kHz 8kJ!z 8 k.Hz 16kHz 90kHz 8 k.Hz

Número do tipo de carga litil

lP(

Redes multimídia

455

Votão 6Hbps

4,8 kbps 13 kbps 2,4kbps 48-64 k~ 16 kbps

Tabela 7.2 Tipos de cargo ú~ de óudiosuportOdos pelo RTP Tdcmiflcculor (/r siucroniza(clo da fonte (syndrronizcui on

~ow CC'

flitlrtiflc•r- SSRC). O cmnpo SSRC

u~m

32 bits de comprimento. Ele identifk2. a fonte da correme RTP. Em geral, cadn fome de uma scss-ao RTP tem um SSRC distinto. O SSRC não é o endereço lP do remetente, mas um rulmcro atribuído alc:uoriamcruc pela fonte quando urna nova corre me é iniciada. A prob:1bilidadc de que seja atribufdo o mesmo SSRC a duas correntes é mttito pequena. Se Isso acontecer, us duas fontes escolhcr:lo novos valores SSRC.

Desenvolvimentode oplicoções desoftware com RTP Há duas abordngens pura desenvolver urna aplicação de rede baseada em RTP. A primeira abordagem é o desenvolvedor incorporar o RTP a mão, Isto é, escrever, ele mesmo, o código que executa o encapsulamento RTP no lado remetente e dccodifica o RTP no lado do receptor. A segunda abordagem é o desenvolvedor da aplicação utili zar as brbliotecas de RTP (para programadores que usam linguagem C) e as classes Java ( para programadores em Ja,':t) existentes. que executam o encapsulamento c a decodifica(';'O para a aplicação. Como voce pode estar ans ioso para escrever sua prímeira aplicação de rede muhimidia usando RTP, \ O:llllOS nos aprorundar um pouco nessas dttas abordagens. (A tarefa de progmma(';\o ao final deste t'.lpflulo servirá de guia para a criação de ttma aplicação RTP.) Faremos isso no contexto da comunicação unicasr (em vez de mulriCtiSI). Lembre-se de que, no Capitul o 2. rnostr:tmos que a API UOP requer que, para ~':\da segmento UDP que envia, o processo remetente determine o endereço IP de destino c o número da porta de destino antes de em~ar o pacote pam dentro do socket UOP. Então, o scgmcmo UDP vagueará pckl Internet c (se mio for perdido, por exemplo, por causa de transbordamcmo de buffer de roteador), a qualquer momento, chegará ao sockct elo processo receptor para a aplicação. Esse sockct terá um endereço completo, ou seja, o endereço IP de destino e o número da porta de destino. Na verdade, qualquer datagr-.tma lP que contenha esse endereço IP de destino c número de porta de destino será direcionado ao sot·kct UDP do pr~o receptor. (A API UDP wmbtm permite que o desenvolvedor da aplk~lção cstabc lc~-u o ntuncro UDP de porta da rontc; contudo, e:ssc valor não tem nenhum efeito sobre o processo para o qual o segmemo é enviado.) É imporrantc notar que o RTP mlo impõe um número de porta cspecillco. Quando o desenvolvedor de aplicações cria uma aplicaç[•o RTP, ele especific-am os números de porta para os dois lados da aplicação.

Número do tipo de corga útd

26 31

formato de vldeo 1.\olion JPEG

H.261

32 33

Y.!eoMPEG2

Tabela 7.3 Alguns tipos de cargo útil de vídeo suportados pelo RTP


Como parte da tarefa de programação deste capitulo, você cscrC\'Crá um servidor RTP que encapsula quadros de vídeo armazenado dentro de pacotes RTP. Você faro isso à mão: isto é. sua aplicaç.\o pegam um quadro de vídeo, adicionam os cabeçalhos RTP ao quadro para criar um pacote RTP c cnu\o passam o quadro RTP para a porta UDP. Para fazer isso, "oe~ precis;tm criar campos de reserva para os vários cabeçalhos RTP. incluindo um campo de número de scqucncia c um campo de marca de tempo. E, para cada pacote RTP que for criado. voe~ tem de de1em1inar o número de scqui!ncta e a mam1 de tempo apropriados. Voe~ codificará explicitamcme todas essas operações RTP dentro do lado remetente de sua aphcaçâo. Como mosrra a Figura 7.l i , sua API com a rede será o socke1 padn'lo UDP. Uma abordagem ahcrmuiw1 (que ni!o é desenvolvida na tarefa de programaç11o) é usar uma classe Java RTP (ou uma biblioteca RTP em C para programadores que utilizam essa linguagem) para implementar as operações RTP. Como mos1ra a Figura 7. 12, com essa abordagem o dcsenvoh•cdor terá a imprcssào de que o RTP é parlc da camada de transporte. Sem entrar nos aspectos rundamenlais (pois eles dependem da classe/biblioteca), quando envia uma porção de midia para demro da API , o lado rcmetcmc da aplicação precisa fornecer :\ interface a porção de midia em si, um mlmero de tipo de carga t\til, um SSRC c urna marca de tempo, junwmeme com um mlmero de port:t de
7.4.2 Protocolo de controle RTP (RTCP) O RFC 3550 1amb~m cspecinca o RTCP. um protocolo que uma apl ica~·ão de rede multimídia pode usar juntamente com o RTP. Como mostrado no cenário mullicasr da Figura 7. 13, pacotes RTCP são transmitidos por cada participante de uma sessão RTP para todos os ouuos panicipantcs da sessão usando IP nrullicasl. Para uma sessão RTP há, tipicamente. um único endereço mulriwsr c todos os pacotes RTP c RTCP pertencentes:\ sessão usam o endereço mullictrsl. Pacotes RTP c RTCP se distinguem uns dos outros pela milizaç:\o de números de pona distintos. (O número de porta RTCP é conngurado para ser igual ao numero da porta RTP mais uma unidade.) Pacotes RTCP não encapsulam porções de áudio ou de vídeo. Em vez disso. eles são en\'iados periodicamente c contêm relatórios de remetente e/ou receptor com dados estalistkos que podem ser uteis para n apli<.~ç:\o. Esses dados estatísticos comi:m número de pacotes enviados. número de pacotes perdidos c variação de atraso entre chegadas. A especificação RTP IRFC 35501 não de1cm1ina o que a aplicação deve fazer com ess:ts infom1açõcs de retomo; isso depende do descrwolvedor da apli(.-aç:\o. Remetentes podem us:lf as inrom1ac;ões, por exemplo. para modincar suas taxas de transmiss..'ío. Essas inrormaçõcs tam bém podem ser utilizadas p.1ra finalidades de diagnóstico: por exemplo, receptores podem determinar se os problemas s.lo locais, regionais ou globais.

Tipos de pacotes RTCP Para cacla corre me RTP qLte um receptor recebe como parte de uma sess.'lo. ele gera um relatório ele rcccpç.\o. O receptor agrega seus relatórios de recepção em um Liníco paco1e RTCP. O pacote é então enviado para a árvore uwltlmsr que conec1a todos os paniciparnes da sessão. O relatório de reccpçilo contém diversos campos; os mais importantes s;lo relacion
J

Socket [ UDP

' I

IP

Enlace de dados Física

Figura 7.11

RTP é porte do oplicoçõo e está ocimo do socket UDP

.


Redes multimldio

457

Aplícaçâo

RTP

} ---------UDP

Transporte

IP Enlace de dados Fisi
Figura 7.12 RTP pode ser visto como umo subcomodo do
O ultimo numero de sequ~ncla recebido na corrent e de paco tes RTP. A varia(,~O de atraso entre chegadas, que é uma estimativa amortecida da variação do intervalo de tempo entre chegadas de pacotes sucessivos na corrente RTP. Para l'ada corrente RTP que um remetente estiver transmitjndo. ele criar:\ c transmitir:\ pacotes de relatório d e remetente RTCP. Esses pacotes com~m infonnações sobre a corre nte RTP, incluindo: O SSRC da corren te RTP. A marca de tempo e o tempo do relógio fisico (tempo real) do pacote da corrente RTP gerado mais recentemente. O numero de pacotes enviados na corrente.

O número de b)•tes erwiados na corrente. Relatórios de remetente podem ser u s., dos para sin cronrzar diferentes cor rentes de mldia dentro de uma scss;io RTP. Por exemplo, considere uma aplicação de videoconferência para :1 qual cada remetente gera duas Remetente

Internet

Receptor

Figura 7.13 Ambos, remetentes e receptores, enviom mensogens RTCP

Receptor


correntes RTP indcpendemes, uma para vídeo e wna para áudio. As marcas de tempo desses pacotes RTP estão vinc uladas aos relógios de :unostmgem de vídeo e áudio. e não ao tempo do relógio físico (isto é, ao tempo real). Cada relatório de remetente RTCP comém, pam o pacote gemdo mais recentemente na corrente RTP associada. a marca de tempo do pacote RTP c o tempo do relógio frslco referente ~ criar..õ\o do pacote. Assim, os pacotes de relatório de remetente RTCP associam o relógio de amostmgem ao relógio físico, de tempo real. Os receptores podem usar essa associação preseme nos relatórios de remetente pam sincronizar a reprodução de áudto c vrdco. Pam cada corrente RTP que está tmnsmitindo. o remetente tamtxm cria c tmnsmíte J>acotes de descrição da fonte . Esses pacotes cont~m Informações sobre a fonte. como o endereço de c-mail do remetente, o nome do remetente e a aplicaçâo que gem a corrente RTP. Contêm tambem o SSRC da corrente RTP assoc tada e fornecem um mtlpeamcmo entre o identificador da fonte {isto é, o SSRC) c o nome do usuário/hos pedeiro. Pacotes RTCP podem ser empilhados, isto é, relatórios de recepção do receptor, relatórios de reme tentes e descrações da fonte podem ser concatenados em um único pacote. O pacote resultalltc é, então, encapsulado dentro de um segmento UDP c rep(lssado pam :1 árvore muhicnst.

Escalobilidode do largura de bando do RTCP Voe~ já deve ter observado que o RTCP apresenta um problema potencial de esc;\l;~bilidadc . Considere, por exemplo, uma sessão RTP que consista em um remetente c um grande tlúmcro de receptores. Se cada um dos receptores gerar periodicamente pacotes RTCP, então a taxa de transmissão agregada de pacotes RTCP poder:\ excCacotes de controle pam todos os outros, cada um deles pode estimar o número total de participantes da scss:\o (Frícdman, 19991.

O RTCP tenta limitar S<'u tráfego a 5 por cento da largura de banda da sessão. Por exemplo, suponha que haja um remetente que está enviando vfdeo a uma taxa de 2 Mbps. Ent;lo. o RTCP tenta limitar seu tráfego a 5 por cento de 2 Mbps, ou a 100 kbps, como a seguir. O protocolo da 75 por ccmo dessa taxn, ou seja, 75 kbps. aos receptores; da os restantes 25 por cento dn taxa, ou 25 kbps, ao remetente. Os 75 kbps dcdtcados aos receptores slo compartilhados íguahnentc entre eles. Assim. se houver R receptores, cada receptor conseguirá enviar tráfego RTCP a uma taxa de 75/R kbps e o remetente conseguirá enviar tráfego RTCP a uma taxa de 25 kbps. Um parti· cipantc (remetente ou receptor) determina o período de trnnsmís..'iào do pacote RTCP calcul:mdo dinamicamente o wmanho médio do pacote RTCP (para toda a sessão) c dividindo o tamanho médio do i>acote RTCP pela taxa alocada :1 ele. panlcipmllc. Em suma, pam urn remetente. o período para transmi Li I' pacotes RTCP é:

r.

nümcro de remetentes (tamanho médio do pacote RTCP) 0,25 · 0,05· largura de b;tndn da sess;lo

E, pnra um receptor, o pcrfodo para transmitir pacotes RTCP é: T•

número de recebedores (tamanho médio do pacote RTCP) 0,75 · 0,05· largum da banda da sessão

7.4.3 SIP Imagine um mundo no qual, enquanto \'Ocê cstâ tmbalhando em seu computndor, ele recebe suas chamadas telefônicas pela Internet. E, quando voce sai pam descansar um pouco, as ll0\'35 chamadas telefônicas que chegam s.lo automatí<."amcntc roteadas para seu PDA. E. quando voce está dírigmdo. n0\'35 chamadas telefônicas são automaticamente roteadas para algum equipamento conectado à Internet instalado no seu carro. Nesse mesmo mundo, durante uma confer~ncia em rede você pode acessar uma agenda de endereços e convidar outras pessoas


Redes multim ídia

459

para p:miclpar da rcuni:\o virtual. Esses outros particípames poden\o estar trabalhando em seus computadores ou em u-.\nsho com seus PDAs à mào ou em seus carros - mio importa onde estepm, seu convite scrn roteado para eles de modo transparente. Ainda nesse mesmo mundo, quando voe~ ' 'aSiLar alguma homc pagc pcssool. cncontr.u:t um link 'Ligue para mim'; ao clicar sobre esse link. será estabelecida uma sessão de telefone lntcmet cmrc seu computador c o proprh~tário da homc pagc (onde quer que ele esteja). Nesse mundo m\o existirá mais uma rede de telefonia por comutaç:lo de circuhos. Em vez disso, todas as chamadas telcfOnicas passan\o pela lntemet - fim a fim. Ainda nesse mesmo mundo, empresas não utilizarão mais centrais privadas de comutação teldOnica (pri\•ate auromaric brcmch exclrcmgr- PABX), 1510 é, mesas locais de comuta~>t\O de circuitos, para manipular chamadas telefônicas internas. Em vez disso, o tráfego telefônico interno nuirá pela LAN de alta velocidade da empresa. Tudo isso pode parecer ficção clcnlifita. E e claro que as redes de comutaç;\o de carcuilos c ccntrJis de PABX de hoje ni\o vno desaparecer completamente uo flnuro pró1dmo (Jiang, 2001). Não obstm\le, já existem protocolos c prod utos p01ra transform:.r essa visão em realidade. Emrc os protocolos mais promis.<;ot·cs p01ra essa finalidade esut o Protocolo de lnk ializaçâo de ScssM (Sts..~ion lttilit\o da mídia. E também permite que encerrem as cham01da.s. Prov~ mcc:~nismos que permitem a quem chama determinar o enderc~·o IP corrente de quem é chamado. Os usuários não t~m um endereço IP único, fixo, porque podem receber endereços dinamicameme ( usando OHCP) c porque podem ter v-ários equipamentos IP. cada um com um endereço IP diferente. Prov~ mecanismos para gerenciamento de chamadas, tais como adicionar n0\'35 correntes de mídia, mudar a eodifacaç;lo, convidar outros participantes. tudo du rante a chamada, c amda transferir c segu· rar chamadas.

Estabelecendo uma chamado poro um endereço IP conhecido Para entender a ~ncia do SIP. é melhor examinar um exemplo concreto. Nesse exemplo. Alice está tra· balhando em seu computador c quer chamar Bob. que tambtm está trab:1lh;mdo em seu próprio computador. Ambos os PCs cst:lo equipados com software baseado em SJP para fazer e receber chamadas telefônicas. Nesse exemplo inicial. admitiremos que Alice conhece o cndcrcc:o lP do PC de Bob. i\ Figura 7. 14 ilustra o processo de estabelecimento de chamada do SIP. Na Figura 7. 14, vemos que uma scss:\o SlP começa quando Alice envia'' Bob urna mensagem 1NV1TE, que é parecida com uma mcn agem de rcquisiçl10 HTIP. Essa mensagem INVITE é crwiacla por UDP à pona bem conhr· cida 5060, que~ a porta do SIP. {Mensagens SJI> tamb~m podem ser enviadas por TCP). A mcrasagern I 1VITE indui um idcmi fit~,,ctor para Bob (hob@l 93.64.210.89), uma indicaçào do endereço IP corrente de Alice, uma incliCllçào ele que Alice deseja receber áudio, o qual deve ser codificado em formato AVP O(PCM codificado com lei f.L) c encap· sulado em RTP e uma indi<::lç;lo de que ela quer receber os pacotes RTP na porlíl 38060. Após receber a mensagem INVITE de Alice, Bob envia uma mensagem de respost:l SIP, que é parcdd::~ com uma mensagem de •·cspostn HTTP. Essa mcns:lgem de resposta SIP também é enviada à pona SIP 5060. A resposta de Bob indui um 200 OK. bem como uma mdk~1ç:\0 de seu endereço IP, o código e o empacotamento que deseja para recepc,.~o c seu número de porta para a qual os pacotes de áudao devem ser en,•iados. Note que, nesse exemplo, Alice c Bob \'

Bob

Atice

167. 180. 112.24

193.64.210.89

INVITE bob0193 C::IN IP4 167 180.64-110.89

mcáudio 38Õ60 R~~~t\;,.

---0

200 01<.

porta so60

-

c: In IP~

POrta 5060 Campainha do terminal de Bob soa

64 2\0.89

t937s3 RTP/AVP 3

m .. áuô,o48 -

-----

..

--:

ACK

Porta 5060 ,

Áudio com lei ,,

porta 38060

~r.~

porta 48753

Tempo

Tempo

Figura 7.14 Estobele
Endereços SIP o exemplo anterior. o endereço SIP de Bob é. sip: [email protected]. Contudo, esperamos que muitos endereços SIP- se n:lo a maioria- sejam parecidos com endereços de e-m:ul. Por exemplo , o endereço de Bob poderia ser sap:[email protected]. Quando o disposilÍ\'O SIP de Alice en,•iasse uma mensagem I 1VITE, a mensa· gem incluiria esse endereço scmclh:~nte a um endereço de c-mail: a infmestrutura SIP ent>lo rotcaria a mensagem ao d•sposilwo IP que Bob está usando no momento em questão (como discuuremos mms adiante). Outras formas possíveis para o endereço SIP poderiam ser o número de telefone legado de Bob ou simplesmente seu nome próprio, ou seu primeiro ou segundo sobrenome (admitindo-se que sejam únicos).


Redes multimldio

461

Uma caracu~rística lmeressame de endereços SlP é que eles podem ser incluídos em páginas Web, exauunentc como endereços de c-ma iI s;lo incluídos nessas páginas jumamcntc com o URL de envio. Por exemplo. suponha que Bob tem uma home page pessoal c quer fornecer um meio pam que os visitantes da página entrem em contato com ele. Ele poderia. c1Huo. simplesmelllc incluir o URL 'sip:[email protected]·. Quando o visitante clicar sobre o URL. a aplicaçi\o SIP no dispositivo do visitante será lanç;~da c uma mensagem INVITE será enviada a Bob.

Mensagens SIP Nessa curta introduç:.lo ao SlP, mio abordaremos todos os tipos c cabe~<~lhos de mensagens SIP. Em lugar disso, cx::uninarcmos brevememe a mensagem SIP INVITE. juntamente com algumas linhas de cabecalho comuns. Mais uma vez. vamos supor que Alice quer iniciar uma chamada telefônica IP com Bob c. desta vez, ela conhece somente o endereço SIP de llob, [email protected]. c n:lo conhece o endereço lP do dispositivo que Bob está correntemente usando. Então, sua mensagem poderia ser algo parecido com:

INVITE s1 p:[email protected] SIP/ 2.0 Via: SIP/ 2.0/ UOP 167.180.112.24 From: s ip:ali ce@her eway. com

To: s ip:bob@domaln. com Cal l - 10: [email protected] r eway. com Conten t Type: appli c ati o n /s~p ConLen l · Lenglh: 885 c• lll IP4 167 .180 .11 2.24 m•aud lo 38060 RTP/AVP O A linha 1:--IVITI: inclui a ''crsão do SIP. assim como uma mensagem de requisição HTIP. Sempre que uma mensagem SIP passa por um dispositivo SIP (incluindo o dispositivo que origina a mensagem). ele anexa um cabeçalho Via, que indica o endereço IP do dispositivo. (Veremos. em breve. que uma mensagem I 'VITE Hpica passa por mu11os d•sposuivos SIP antes de chegar à aplicaÇão SIP do usuáno que fo1 chamado.) Semelhante a uma mensagem de c-mail. a mensagem SIP inclui uma linha de cabeçalho From c uma linha de cabeçalho To. Inclui t~mbém um Call-10 (idcmificador de chamadas), que idcntifit-n a chamada exclusivamente (semelhante à mensagem-lO no c-mait). Inclui uma linha de cabeçalho Comem-T)•pe (Tipo de Conte lido), que define o formato usado para dcscrc,·er o contcüdo da mensagem SIP. Inclui tamb~m uma linha de cabeçalho Comem-Lcnght (Tamanho de Contcudo), que indica o comprimemo em b)'tCS do conteúdo na mensagem. Finahncnte, após um carriagc return c um line fccd, a mensagem contém o corpo de informação. Nesse caso, o conteúdo fomecc informações sobl'c o endereço IP de Alice c como Alice quer receber o áudio.

Tradução de nome e localização de usuário No exemplo da Figura 7. 14. admitimos que o disposili,•o SIP de 1\licc <.:onhccia o endereço IP onde Bob podia ser contntado. Mas essa prcmiss:1 <:pouco realista, não somente porque muiu1s vezes os cndere\<)s IP são mribufdos din~m icam cnte com OHCP, mas também porque Bob pode ter v:lrios dispositivos IP (por exemplo, dispositivos diferentes em casa, no trabalho c no carro). Portanto, agora vamos supor que Alice conhece somente o endereço de e-nmil de Bob. [email protected]. c que esse mesmo endereço é usado pam cham:td:LS SIP. Nesse caso, Alice precisa obter o endereço IP do d•sposiuvo que o usuário [email protected] está usando naquele momento. Para descobnr esse endereço, Alícc cria uma mensagem I VITE que começa com IN\fiTE [email protected] SIP/2.0, c envi;l css.1 mensagem a um proxy SIP. O prox'Y responderá com uma resposta SIP que poderá incluir o endereço IP do disposith·o que [email protected] está usando naquele momento. Altemaüvmncntc. a resposta poderia incluir o endereço IP da caixa postal de voz de Bob. ou poderia incluir um URL de uma página Web (que: du: ·nob está dormindo. Nào perturbe:!. ). Além disso, o resultado de"olvido pelo proxy poderia depender de quem chama: se a chamada ,·ier da sogra de Bob. ele poderia responder com o URL que apoma para a págma Web do -estou dormmdo· ! Agora, você provavelmente está imaginando como o servidor proxy pode detenmnar o endereço IP corrente para [email protected]. Para responder a essa pergunta, é preciso dizer algumas palavras sobre um outro disposi-

bow4tto4ic~ Redes de computadores e o Internet úvo SLP, a entidade registradora SiP. Cada usudrio SlP tem urna entidade reglstr:~dora associada. Sempre que um usuário lança uma apliCa\<\0 SIP em um dispositivo, a aplica\
REGISTER slp :domal n. com SIP/2 .0 VIa : SIP/2.0/UOP 193 .64. 210 .89 From: sip :bob@doma i n. com To: sip :bob@domal n. com Expi r es : 3600 A em idade registr:~dora momtora o endereço IP corrente de Bob. Sempre que ele mudar para um novo disposi· tivo SIP, esse novo dispositivo en,•iam uma nova mens.1gem de registro, indicando o novo endereço IP. Alc!rn disso, se Bob permanecer no mesmo dispos itivo durante um longo pcr!odo de tempo, o dispositivo em•iará mensagens de conl'inna~-.\o de registro, indicando que o endereço IP mais recentcmeme enviado ainda é v:llido. (No exemplo acima, é preciso enviar mens.1gcr1S de eonfinnaç;lo a cada 3.600 segundos para numter o endereço no servidor da em idade registradora.) O fato de :t entidade registmdora ser amHoga a um servido r de nomes DNS com autoridade nilo I! di gno de uot;~; o servidor DNS tmduz nomes de hospedeiros fixos pam endereços IP nxos; a cnliclade registradora SIP traduz identificadores flxos de pessoas (por exemplo. [email protected]) para endereços IP dinàmi· cos. Muit:ts vezes, as entidades rcgistmdorJS SIP e os proxies SIP são executadas no mesmo hospedeiro. Agom vamos examinar como o SCT\'idor proxy SIP de Alice obtém o endereço IP corrente de Bob. Vimos. na discuss.'lo f>rcc:cdcme. que o servidor prO>-)' precisa simplesmente tr.msmitir a mensagem i ' VI TE de Alke à entidade registradoralproxy de Bob. Ent;\o, a rcgistrador.Vproxy poderia transmi tir a mcns.1gcm ao dispositivo SIP corrente de Bob. Finalmente, como agora Ilob j. rcccbeu a mensagem 11\'VJTE de Alice, ele pode enviar a el;t uma resposta STP. Como exemplo. considere a Figum 7.15. na qual [email protected]. que está correntemente trabalhando em 217.123.56.8<), quer iniciar uma sessão de voz sobre iP com [email protected], correntemente trabalhando em 197.87.54.21. S~o segtudas as seguimcs etapas: (1) jim envia um01 mensagem INVITE ao pro>.)' SIP de umass. Entidade registradora StP upenn.l!du

Entidade registradora StP

Chente StP 217. 123.56.89

figura 7.1 S lniciolizoçõo de sessõo envolvendo proxies e entidades regislrodoros SIP

Oiente StP 197.87.54.21


Redes multímldio

(2) O proxy raz uma consulta DNS para a entidade rcgisrradora SIP de upcnn.edu (que n:\o t mostrada no diagrama) c ent:'lo e•win a mensagem ao servidor da registradora. (3) Como [email protected] m\o está mais registrado na entidade registradora de upcnn, esta envia uma resposta de redirecionamento, indicando que é preciso tentar [email protected]. (4) O proxy de umass envia uma mensagem INVITE à registradora SIP de curecom. (5) A registradora de curecom conhece o endereço IP de keith@eurccomJr c repassa a mensagem INVITE ao hospedeiro 197.87.54.2 1, que está executando o cliente SIP de KeiLh. (6-8) Uma resposta SIP é devolvida por meio de registradoras/pro;~.'ics ao cliente SIP em 217. 123.56.89. (9) Em:1o a nudia é enviada diretamente emre os dois clientes. (Também há uma mensagem de rcconhcdmcn to SIP. qlle não é mostrada.) Noss.'l discussão sobre o SIP rocatizou a inicializaç.\o de ch<~madas para chamadas de ''oz. Como o SlP é um protocolo de sinalizaç;lo para lnldaHz..1r c enccm
7.4.4 H.323 Como uma altcrmuiva :10 SIP, o H.323 é um padrão popular JY.lra audioconfcrfncia c ,,idcoconfcrêncin entre sistemas fin uis na Internei. Como ilustrado na Figura 7.16. o p:1dn\o t:un!Xrn abrange a m:1nelr:1 como sístem:\S finais ligados;\ Internet se comunicam com lelcfoncs ligados às redes normais de telefonia de comuta\':'10 ele cir· cultos. (O SIP também faz isso, embora não tenhamos discutido esse 3SSimto.) O gatekecper H.323 é um disposi1ivo semelhante a uma cntid:tdc registradora SIP. O JY.ldr:)o H.323 é uma especificação guarda-chu"a que inclui as seguintes cspcc1ficaçõcs: Um:1 especificação para o modo como os terminais negociam codificações comuns de áudio/\•1dco. Como o 11.323 supon:1 uma variedade de padrões de cod1flcação de áud1o e vfdeo, é preciso um prolocolo para permitir que os terminais comunicantes cheguem a um acordo qu:~nto a uma cod1flcação comum. Uma especificação para o modo como porções de áudio e v1deo s.lo enc:~psul:-~das e enviadas à rede. Em particular, para essa finalidade o H.323 impõe o RTP. Um;~

espcclfk aç:1o para o modo como terminais se: comunicam com seus respectivos g;~tckccpcrs.

Gatekeeper

Gateway Internet

~

Rede telefónica

Telefones

figura 7.16 Sisfemos finais H.323 ligados à Internet podem se comunicar com telefones figodos ouma rede Jelelônico de comutação de circuitos


Uma cspccificaçfto para o modo como telefones por Internet se comu nicam por meio do gateway com os telefones comuns na PSTK No mfmmo, <:ad:l termim1l H.323 tem de suport;\r o padr-.10 de comprcss;lo de ' 'OZ G.7ll. O G.7ll usa PCM para gerar voz drgitalizada a 56 kbps ou 64 kbps. Embora o H.323 exija que cada tem1inal seja habrlitado pa ra voz (por meio do G .711) , capacidades de vídeo são opcionais. Como o suporte de vfdeo é opcional, os fabrican tes de terminars podem vender tanto tenninais de \ 'OZ mais simples como terminars mais complexos que suportam áudio e vrdeo Capacidades de vídeo para um tcm1inal H.323 São opcromus. Todavia. se um terminal suportar vídeo, cnlilo ele dever.\ (no mini mo) suportar o padrão de vídeo QCIF H. 261 (176 x l·H pixels).

O I L323 é um padrão guarda-ch uva abrangente que. além dos padrões e protocolos que ambamos de descrever. impõe um protocolo de controle H.245, um canal de sinalizaç{lo Q.93 1 c um protocolo RASpara registro no gatekceper. Conclurmos esta seção destacando algumas das diferenms mais importanles entre H.323 c SIP. O 11.323 ~ u m conjunto de protocolos completo , integrado verticalmen te, pam conferenci:~ mu lthnfdia: s ina lizac;Lio, registro. cont role de ad miss;ío. transporte e codecs.

O SlP, por outro lado, aborda a1>enas inicialização e ge renci;uncnto ele scssno e é um co mponente separado. O SIP trabalha com RTP, mas não o impõe. Trabalha com codecs de voz G. 7ll c codecs de vfdeo QCIF 11.261. mas não os impõe. Pode ser combinado com outros protocolos c serviços.

O 11.323 \•cm da lTU (telefonia), enquanto o SlP vem da IETF c torna

emprest:~do

muí1os conceitos da

Web, do ONS e do e-mail da Internet.

O H.323, corno é um padnlo guarda-chuva. é grande c complexo. O SlP usa o príndpío KISS: man tenha a simplicidade, seu ignorante (keep it si mple, stupid)! Há uma excelente discuss.lo sobre protocolos H.323. SJP e de

\' OZ

sobre IP em gemi. em (lfersent, 2000).

7.S Fornecendo múltiplos classes de serviço Nas scçôc.s anteriores, aprendemos como números de scquência, marcas de tempo, FEC, RTP c H.323 podem ser usados por aphcaçóes de multimídia na Internet de hoje. CD ' s representam uma solução para dist ribuição de contcudo de multimídia no âmbito do sistema inteiro. Mas scril que somente essas técnicas slo suficientes para suportar aplicações de multimídia confiáveis c robustas. como u m serviço de telefon ia IP equivalente ao serviço a tualmen te oferecido pela rede telcfOnica? Antes de responder n essa pergunta, vamos lembrar novamen te q ue a Internet de hoje oferece um serviço de melhor esforço :r todas as suas aplícaçõcs, isto é, ela nad11 promete qua mo à qua lidade de se rviço (QoS) que uma aplica~;-ão receberá. Uma aplicação receberá o níve l de desempenho (por exemplo. atraso fim a fim e perda de paco tes) que a rede estiver capacitada a dar em determinado momento. Lembre-se também de que a Internet publica de hoje nilo permite que

Redes multímldio

J: lmponante observar que esses serviços dl[erendados sãO fornecidos entre conglomerados de tráfego, por c.xemplo, entre classes de trafego, não entre conexões individuais. Por exemplo, todos os passageiros da primdra classe são tratados da mesma mane1ra (sem que qualquer passage1ro da pnmeira classe receba um tratamento diferencial), assim como os pacotes VolP receberiam o mesmo tratamento dentro de uma rede, independentemente da conexão fim-fim a qual eles pcnenccm. Como veremos, ao lidar com um numero pequeno de conglomerados de tráfego, ao inv6. de um grnnde ntimero de conexões individuais, os mecanismos de rede que necessitam fornecer o melhor serviço, podem ser mantidos rclath'llmente simplcs. Os pruneiros prOJCSliStas da Internet claramente tinham essa noç;lo de múhaplas classes de scrv1ço em mente. Relembre do campo tipo de serviço (ToS) no cabeçalho 1Pv4 na Figuro 4.13. IEN123 (ISI 19791 descreve que o campo ToS, tam~m presente em um anccsLml do datagrama IP,·4. como segue: .. O tipo de serviço (campol fomecc uma indicaç;io dos par.lmctros abstr-atos da qualidade de sen•iço desejada. Esses pm-;lmetros devem ser us:~dos para guiar a escolha de parâmetros atr:\\'és de serviço quando um d:nagrama estiver se11do transmilido :ttravés de uma rede especifica. M\til:IS redes oferecem serviços prioritários, os quais de alguma forma reservam m:~is mcnç;lo tiO tráfego de prioridade ;\lta do que ilOS outros. ~ t\tl! mesmo h~ trCs dêc:tdas, a visãO de fornecer diferentes nlvcis de serviço a diferentes nf\•cis de tráfego estava evidente. o ent:tnlo, levou um longo perfoclo pam que pudêsscmos percrbcr essa visão. Começaremos nosso estudo na Seç:\o 7.5 considerando vários cen:\rios que motivarllo a necessidade de mecanismos específicos pam o suporte de múltiplas classes de serviço. Veremos então dois tópicos importantes- CSC".tlomm1cnto de c:unada de enl;lce c classificação/ regulação de pacotes na Scçào 7.5.2. Na Seç-.\o 7.5.3, ve remos Oarfscn· - o padr-;\o atual da Internet de fornecimento de scrvaços dircre nciados.

7.5.1 Cenários motivadores A Figura 7. 17 mostra um cenário simples de rede que us:~remos paro ilustrar os componentes arquitetõnicos mais importantes que t~m sido propostos com a finalidade de fomcccr suporte explicito paro as necessidades de QoS de aphcwõcs de multimídia. Suponha que dois fluxos de pacotes de aphcaç;lo se orlgmcm nos hospedeiros Hl c H2 em uma LAN e sejam destinados aos hospedeiros H3 c H4 em outro LA '. Os rou~adores nas duas LANs sào hgados por um enlace de 1,5 Mbps. Vamos admitir que as taxas das L.ANs sejam significativameme mais ahns do que 1,5 Mbps c \"llmos focalizar a fila de saída do roteador RI; é aqui que ocorrcr:io alraso c perda de pacotes se a taxa agregada de envio de 111 e 112 exceder 1,5 Mbps. Vamos agom considerar davcrsos cenários; cada um deles nos dará 11nponantcs percepções a necessidade de mecanismos especfficos r>ara o suporte de classes múl· ti)>las de serviço.

H3

H1

Rt ~

H2

Figura 7.17 Uma rede simples com duas oplicoções

En!X
H4

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; ro;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

Cenário 1: umo oplicoçõo de áudio de 1 Mbps e um o transferência FTP O cenário L está ilustrado na Figura 7. 18. l'\CSS3 llgura. uma aplkaç;lo de áudio de L Mbps (por exemplo, uma chamada de áudio com qualidade de CD) compartilha o enlace de 1,5 Mbps entre RI c R2 com uma aplicação FTP que está Lransfcrlndo um arquivo de H2 para H4. Na lmcmct de melhor esforço, os pacotes de áudio c FTP são misturados na fila de sarda de Rl c (caractcrislicameme) transnmidos na ordem primeiro a cnlrar/primciro a sair
Cenário 2: umo aplicação de áudio de 1 Mbps e uma transferência FTP de oito prioridade Nosso segundo ccn:lrio ~ apenas ligeiramente diferente do cenário l. Suponha agora que o usuário FTP comprou de seu ISP um servtço de acesso à Internet de aho preço, ao passo que o usuárao de áudio comprou um serviço de Internet barato. cujo preço é uma minl\seula fraç-Jo do outro serviço. Nesse caso. os pacotes de áudio do usuário do serviço barato deveriam ter prioridade em relação :lOS pacolcs FTP? Pode-se afirmar que não. Aqui. o mat!> razoável seria distinguir pacotes com base no endereco IP do remetente. De modo mats gemi. vemos que é necessário que um roteador classifique pacotes segundo algum crit~rio, o que exige uma ligeira modificação no pri nct pio 1: P·rincipio I (modificado): a classificação de pacotes pcranile que um roteador fnça a distinçlo de pacotes pertencentes a difere rues classes de tráfego. HI

Hl

H2

H4

Figura 7.18 Aplicações concorrentes de áudio e FTP


t\ marcaçào explrclta de pac01es é uma maneira pela qual

Redes multim ídia

os pacotes podem ser distinguidos. Contudo, a

mart·a carregada por um pacote não detem1ina por si só que o pacote recebem urna dada qualidade de serviço. t\ marcação é apen:lS um dos mecanismos para distinguir pacotes. O modo corno um roteador distingue pacotes uatando·os de maneira diferenciada e uma decísM administrativa.

Cenário 3: uma aplicação de áudio malcomportada e uma transferência FTP uponha agora q ue, de alguma maneira (pela utilização de mecanismos que cstud:uemos nas seções sub· sequentes), o roteador s:uba que deve dar prioridade a pacotes da aplicação de áudio de I Mbps. Como a taxa de salda do enlace é de 1,5 Mbps, mesmo que os pacotes FTP recebam prioridade m:1is baixa, ai nda assim rece· berào, na média. um serviço de transmissao de 0,5 Mbps. Mas o que acon tece se a :tplkaçào de áudio começar a enviar pacotes a uma taxa de l ,5 Mbps ou mais alta (seja com má intenção, seja de,•ido a um erro de aplicação)? Nesse c~tso, os pacotes FTP morrerJo por inanição, isto é. n;lo receber.lo nenhum serviço no enlace RJ-R2. Problemas semelhan tes ocorre riam se várias aplicações ( IX>r exemplo, vnrias chamndns de <~ud i o), todas com a mesma prioriclade, estivessem compartilh
Marcação e de pa
regulaç~o

Hl

HI

RI

~

Enlace de 1,5 Mbp$

H4

H2

legenda:

(9

R2

~

Mtdo(.lO re<)IA.K.lO

Figura 7.19 Regulação (e morcoçõo) de fluxos de óudioe FTP

li

MMc.s


Hl

H3

H2

H4

Figura 7.20 Isolamento lógico de OuxGS de opliOde u ti liza r largura de banda que nilo cst:l se ndo usada corrcntememe pelas outras ap licações. Por exemplo . se o fluxo de áudio s ilenciasse (se o in terlocutor fizesse uma pausa c não gerasse nenhum paco1e de áud io, por exemplo), aind a assim o nuxo FTP n:lo conseguiria transm itir ma is elo que 0,5 Mbps pelo enl:~ce RJ -R2, mesmo que a alocaç:\o de largura de banda de l Mbps para o nuxo de áudio não estivesse sendo utilizada naquele momen to. Por conseguin te. é desejável usar a largura de banda da maneira mais eficiente possívd, pcrnutindo que u ma classe o u um fluxo ut ilize 11 l:ugura de banda n:lo usada por omro fluxo a qualquer inslanLe. Essn considera <,".
7.5.2

Mecanismos de esmlonomento e regulação

Agora que estabelecemos princípios sobre os mecanismos neccss:\ri~ para o fornecimento de direrentcs classes de serviço, vamos considerar dois dos mais importantes mecanismos - escalonamento e regulação com mais detalhes.

bow4tto4ic~ Capitu lo 7

Redes multimídia

Mecanismos de escolonomen1o lembre-se de que dissemos na Seção 1.3 c na Scç-lo 4.3 que pacotes penenccntes a vários nuxos de rede são multiplexados c enfileirados para transmissão nos buffcrs de salda assoc.ados a um enlace. O modo como os pacotes enntclrados s;\o selecionados p.~ra trans missão pelo enlace é conhecido como d isci plina de escalona mento do enlace. Vamos agora examinar mais detalhadamcnte algumas das mais un pon antes disciplinas de escalonamento.

Primeiro a en1ror/primeiro o sair (FIFO) A Figura 7.21 mostra a representação do modelo de cnflleiramento para a d&sciplina de escalonamento de enlace primeiro a ent rar/primeiro a sair. Pacotes que chegam à nta de saída do cnl:tcc cspcmrn pela transmissão se, naquele momento, o enlace estiver ocupado com a transmissão de outro pacote. Se n;\o houver espaço de buffcr suficiente para guardar o p;~cote que chega, a política de descarte d e pacotes da fi la então determinar;\ se o pacote sem d escartado (perdido) ou se outros paco tes serão relimdos da fila par:1 dar espaço ao p
rna.

A Figura 7.22 mostra a fil a FIFO em opernç-!o. As chegadas de pacotes são indicadas por setas numemdas ae una da linha temporal s uperior; os números indicam a ordem em que os pacotes chegaram. As saídas de pacotes indi\•iduais s;\o mostmdas abaixo da linha tcmpoml inferior. O tempo que um pacote passa no atendimento (sendo transmitido) é mdicado pelo retângulo sombreado ent re as duas linhas d e tempo. Por causa da disciplina FIFO. os pacotes saem na mesma ordem em que chegaram. Note que. após a satda do pacote 4. o enlace permanece ocioso (urna vez que os pacotes 1 a .f já fo ram transmitidos c retirados da fila) até a chegada d o pacote 5 .

Enfileiromen1o prioritário Sob a regra do e nfileiramento J>rioritá rio, pacotes que chegam ao enlace de saída silo classificados em classes de prioridade na OI a d e saída, corno mostro a Figum 7.2.3. Como d iscutimos na seção anterior, a classe de prioridade de um pacote pode depender de uma marca explícita que ele carrega em seu cabeçalho de pacote (por exemplo, o v·alor dos bits de ToS em um pacote rPv4), do endereço IP de s ua origem OLt destino, do número de porta de seu des tino ou de OLttrO critério. Cada classe de prioridade tlplcmncnte tem sua própria nta. Ao escolher um p;lcote para tmnsmiti r, n disciplina de enfileiramento priorit~rio transmitir,\ um p;~cot c d:1 classe de prioridade mais alta cuja nta não esteja vazia (isto é, tenha p;1cotes esperando tmns mlss:lo). A escolha entre pacotes da mesma classe de prioridade é feita, tipicamente, pelo métod o FIFO,

A Figum 7.24 ilustra a opcmçào de uma fila prioritária com d uas c lasses de prioridade. Os pa<:otcs L, 3 c 4 pe rtencem ii classe de alta prioridade e os pacotes 2 c 5, ;-1 classe de baixa prio ridade. O pacote 1 ~o:hcga Partidas

Chegadas

Fila (Área de espera)

Figura 7. 21

Representação do enh1eiromento FIFO

Enlace (Servidor)


Chegadas

2

3

4

5

~

•

t•

t

Pacote em serviço

3

2

t •O

t. 2

fa4

t: 6

4

t ;; 10

t- 8

I • Tempo 5

t .. 12

Tempo

t a 14

Saídas 2

3

4

5

Figura 7.22 Afilo FIFO em operosõo e, encontrando o enlnce vazio, inicia a transmissão. Durante a transmissão do pacote l, os p:~co tes 2 e 3 chegam c são colocados nas fil:\s de baixa prioridade e alta prioridade, respectivamente. Após a trnns miss._,o do pacote l, o p:~co tc 3 ( um pacote de alta prioridade) ê selecionado para trans missão, passando à frente do pacote 2 (que, mesmo te ndo c hegado mais cedo,~ um pacote d e baixa prioridndc). Ao términ o da tra nsmissão d o pacote 3, começ:1 a tmnsmissão do pacote 2 ( um pacote de baixa p r ioridade). O pacote 4 (u m pacote d e alta p rioridade) c hega dura nte a transmissão do pacote 2 ( um pacote de baixa priorid:tde). Sob uma disciplina de eunlcinuncmo prioritário não precmptiva, a transmiss:'\o de um pacote nào será interrompida se já ti ver comcçlldo. Nesse caso, o pacote 4 entra na fila para transmiss.'\o e começa a ser transmitido após a concl usão da trnnsmiSS
Varredura cíclico eWQF (enfileiramento juslo ponderado) Sob a disciplina d e enfileiramento por varred ura ciclica. pacotes são classificados do mesmo modo que no en0leiramen1o prioritário. Contudo, em \'ez de haver uma prioridade eslrila de serviço emrc as classes, um escalonador de varredura cfclica ahema serviços emre as classes. ~a fo mla mais simples de escalonnmemo por varredura cfclica, um paco1e de classe 1 é 1ransmitido. seguido por um pacote de classe 2, seguido por um pacote de classe I , seguido por um pacou: de classe 2 c assim por diante. Uma disciplina de cnfilciramcmo de conscr.·aç-lo de trabalho nunca permitirá que o enlace fique ocioso enquanto houver paco1cs (de qualquer classe) enfileirados para transmissão. Uma disciplina de varredura dclica de conservação de trabalho que procura um pacote de uma d~\da classe, mas nilo encontra nenhum, verifica imediatamente a classe seguinle na scqui:ncia da varredura Ctclica.

i\ Figura 7.25 il ustra a operação de uma IHa de duas classes por varred ura eiclic:~. Nesse exemplo. os pacotes 1, 2 c 4 pertencem à classe 1 c os pacotes 3 c 5 , à classe 2. O pacote l inicia a transmissão imediata·

mente após sua chegada à m aele sarda. Os pacotes 2 c 3 chegam durante a tmnsmisst\o do pacote 1 c, assim, e ntram na fila pam tmns missi\o. Após a transmissão do pacote l , o escalonador de enlace p rocura u m pacote Fila de alta prioridade (ârea de espera)

Chegadas

Classificar Fila de baixa prioridade (área de espera)

Figura 7.23 Modelo de enfileiramento prioritário

Enlace (Servo dor)


Chegadas

r

4

3

2

~ T t=2

C4:

2

t=4

t=8

t=6

471

5

~

Pacote em serviços

t =O

Redes multimídia

f=10

I • Tempo

5

t = 12

Tempo

t = 14

Saldas 3

[4

2

5

Figura 7.24 Operoçõo do enfileiromento pri01itório de classe 2 e. então, transmite o pacote 3. Após a Lrnnsmiss.1o do pacote 3, o escalonador procu ra um pacote de classe 1 c, cmflo, tr:111smitc o pacote 2. Após a transmissão do pacote 2, o paco te 4 ~ o único na fila; assim, ele é t ransmitido imediatamente após o pacote 2. Uma abstração generalizada do c nllteiramento por varredura cidica que encontro u considerável llliliza~o nas arquiteturas com QoS e a denominada disciplina de enfileirament o j us t o p o nderado (111cigl•ted

f(lir qucuing- WFQ) [Demcrs. 1990: Parekh, 1993]. A WFQ é ilustrada na figura 7.26. Os pacotes que chegam s.io classilkados c enfileirados por dasse em suas áreas de espera apropriadas. Como acontece no escalonamento por varredura ciclica, um programador WFQ atende às classes de modo cíclico - atende primeiramente à classe 1, depois à classe 2 e, em seguida, à classe 3; c então (admitindo que haja tr~s classes) repete o esquema de serviço. A WFQ também é uma disciplina de enfileiramento de conservação de trabalho; assim, ao encontrar uma classe de fila vazia, ela imediatamente passa para a classe seguinte na sequéncta de atcndimclllo.

A WFQ é diferente da \':lrredura cfdica. pois cada classe pode receber uma quantidade de serviço diferenciado a qualquer intcn':llo de tempo. Em panicular, a cada classe i é atribuído um peso w,. A 'WFQ garante que. em qualquer intervalo de tempo durante o qual houver pacotes da classe i para transmitir, a cL'\SSC i recebera uma fração de scn'iço •gual a w,IO:w ). onde o denominador é a soma de todas as classes que também tt:m pacotes cniiJcirados 1 para transmissão. No pior caso, mesmo que todas as classes tenham pacotes na IHa, ::1 classe i ainda terá garan tido o recebimento de uma fração w/(!w) dn largura de banda. Assim, para um enlace com tax:l de transmissão R, n classe i sempre conseguirá uma vazão d e, no mínimo, R · w/Ciw ). Descrevemos a WFQ em condições ideais, pois 1 não considera mos o fato de que os pacotes São unidades dis<'retas de dados c que a tr:msmlss.lo de urn pacote t1ão scr.i interrompida para dar inicio :1 mmsmissão de outro: IDcmers, 19QO) c )Pnrckh, 19Q31discutem essa ques tão do empacot:1111e111o. Como veremos nas seções seguimcs, a WFQ tem um papel fu ndamental nas arquiteturas com QoS. Ela tambtm está dispon!vcl nos rou:adores fabricados allmlmemc l Cisco QoS, 2009).

1'1 rT

3

5

4

Chegadas

f Pacote em serviços ta O

t

' t .. 2

t =4

4

2

3 I= 6

1=8

t = 10

I • Tempo

5

t .. 12

Tempo

t. 14

Saídas

OJ

3

12

Figura 7.2S Operoçõo de enfileiramentode duns dusses por varredura cíclico

4

5

bow4tto4ic~ Redes de computadores e o lnte ;.; rn;.;e;.;.t_________________________

Saldas

Figura 7.26 Enfileiramento justo ponderado (WFQ)

Regulação: oleoky bucket Um dos nossos princfpios na Scç-Jo 7.5. 1, foi que o escalonamento, a rcgul:u,"<,O, o ajuste da taxa com a qual é per mitido que um nuxo (suporemos que uma unidade de regulação é um nuxo na nossa discussão abaixo) injete p:1cotes na rede, s:lo pedras fundamentais de qualquer arquitetura com QoS. Mas quais características da taxa de pacotes de um nuxo de,•em ser reguladas? Podemos identificar três critérios importantes de regulação diferentes entre si pela escala de tempo durante a qual o pacote é regulado: T
sesund o. Tcmu111ho t/(1 rtlj(t[/(1, A rede também pode limitar o numero má)o:itllO de p:1co tcs (a 'rajada' de pacotes) quc podem ser enviados para demro dela durante um intervalo de tem po cx trcmamentc curto. No li mite, ;'I medida que o comprimento do intcrv;~ lo se aproxima de zero. o tamanho da rajada limita o mlmero de p:tcotcs que podem ser enviados itlSLmllaneamcnLc pam dentro d:r rede. Mesmo que seja írnpossfvcl em termos ffsicos cn\'iar \•:\rios pacotes para dentro da rede instant:meamcnte (aOn:tl, c:tda enlace tem uma taxa de transmissão que não pode ser ultrapassada!). a abstrnç:'o de u m tamanho tm\ximo de raja· da é util.

O nlec:1nismo lcaky bucket é uma abslr.tçào que pode ser usada para

carncteriz:~r

esses limites da regulaç;\o. Como mostra a Figura 7.27, um lcaky bucket ~um balde que pode conter até b permissões. As permissões são adicionadas ao balde como segue. No'-as permissões. que potencialmente podem ser adrcionadas ao balde, estão sempre sendo geradas a uma taxa de r permissões por segundo. (Para racilitar, nesse caso admitimos que a unidade de tempo seJa L segundo.) Se o balde estiver cheio com menos de b penmssões quando é gerada uma permissão, a permissão recém-gerada será adicionada ao balde; caso contrário, ela será ignorada c o balde permanecerá cheio com as b permissões.


Pacotes

-

----~

Redes multim ídia

473

Área ele

espera de permi5~o

Figuro 7.27 Regulação do l~oky buckel Vamos considerar ngora como o lcaky bucket pode ser usado p:-~ra regubr um fluxo de pacotes. Suponha que. a ntes de um pacote ser transmitido para dentro da rede, ele tenha de retirar uma pcrm i~io de dentro do balde de permissões. Se o lxlldc de permissões esti ver \":tZio. o pacote ter.l de esper;u por uma pcrmiss;io. (Uma altern;Hiva t o pacote ser descartado, mas não ' "unos consiclemr essa Op\'àO aqui.) Vamos considerar agom como

esse componamento regula o fluxo de tráfego. Como pode haver no máxtmo b permissões no balde, o tamanho máximo da rajada para um fl uxo regulado pela técnica do leak}' b ucke t é b pacotes. Além disso. como a taxa de geraç:lo de permissões é r, o número máximo ele pacotes que pode ent rar na rede para qualquer imervalo de tempo t é rt + b. Assi m, a taxa d e geração de permissões, r, serve para limitar a taxa média de longo período com a qual pacotes podem entrar na red e. Tambt:m é possavel usar leak)' buckets (especificamente dois baldes em série) para reg ular a taxa d e pico de um fluxo e a taxa média por um período de tempo; veja os exercacios ao final deste capít ulo.

Leaky bucket e enfileiramento justo ponderado fornecem máximo atraso provável emuma fila Logo examinaremos as abordagens denominadas lntserv e Diffserv para fornecimento de qualidade d e servko na Internet. Veremos que tanto a rcgulaçt•o do leaky bucket quanto o escalonamento WFQ podem desempenhar um papel importante. Vamos fechar esta scç-.lo considerando um enlace de smda de ro teador que multiplexa n nuxos, cada um rcgLalado por um lcak}' bucket com parllmctros b,, c r,, I • 1, ... , 11 , usando escalonamento WFQ. Usamos aqui o Lermo •nuxo· de um modo um pouco impreciso pam dcnomln:u conjuntos ele pacotes que não s.:lo distinguidos uns dos o ut ros pdo escalonador. Na prática, um Ouxo pode conter o trMego de uma única conexão ftrn :1 fim ou um conjunto de muitas conexões desse tipo; veja a Figum 7.28. Lembre-se de que mencionamos, em nossa discussão sobre a WFQ. que c:•da nu xo i tem a garantia de receber uma parcela d~' largura de lxlnda do enlace igual a, no mínimo. R . w;(''i.w1), onde R f a taxa de transmissão d o enlace em pacotes por segundo. Qual é, cn~\o. o atraso máximo que sofrerá um pacote enquanto espera ser atendido na WFQ (isto é, após ter passado pelo balde)? Vamos considcmr o nuxo 1. Suponha que o balde de permissóes do fluxo l esteja imdalrnente cheio. Uma rajada de b1 pacotes então chega ao regulad or de lcaky bucket par.t o nuxo 1. Esses pacotes retimm todas as pcrnlissões do balde (sem esperar) c, em seguida, j untam-se à área de espera WFQ para o fluxo 1. Como esses b1 pae01es são atendidos a u ma taxa de, no mfnimo, R · w/ ('i.w1) pacou:s por seg\lndo. o último desses p.~cotcs sofrerá um atraso mciXimo. d_. até q ue s ua transmissão seja conclurda, onde ti,.... • _ _b, _J..,.:::--R · w1fi. w1

A razão dessa fórmula é que, se houver b, pacotes na fila e os pacotes estiverem sendo ate ndidos (retirados) na fila a uma taxa de, no mínimo, R· w/('i.wi) por segundo, então a quantidade de tempo até que o

bow4tto4ic~ Redes de co mp utadores e o Inter net

• •

•

r,.

~ 'C:Jb ,

Figura 7.28 nfluxos mulfip!exodos com leokybucket com es
7.5.3 Oiffserv A arquitetura Diffscrv )RFC 2475; Kilkki 1999) tem como objetivo fornecer um sen•iço diferenciado- isto é, a habilidade de lidar com as difcrcmes Melasses" de rráfego de diferentes modos na Internet- c faz~- lo de modo cscalávcl c nexavel. A neccsstdade da escabilidade vem do fato que centenas de milhares de fluxos simultâneos de tráfego fonte-destino cst:lo presentes em um roteador backbonc da lmcrnct. Veremos brevemente que essa neccssid:1dc é satisfcit:l ao colocannos u ma fllncionalidade dentro do nuclco da rede, com uma operação mais completa de controle sendo implementada na borda da rede. A ncccssadade de Oexabilidade surge pelo fato que novas classes podem aparecer c classes de serviços amigas podem se tornar obsoletas. A arquitetura Diffserv é flexível pois n:lo define serviços específicos ou classes de serviço. Pelo contrário, Diffserv fornece componentes funcionais, ou sej:l, pcÇ':IS de uma arquitetura de rede, com as quais tais sen•lços podem ser feitos. Va mos agora exmnlnar tais componentes mais detalhadamente.

Serviços diferenciados: um cenário simples Com a nnalidadc de estabelecer uma estrut ura para defi nir os componentes arqu ltctOnicos do modelo de sen•iço diferenciado, vamos começar com a rede simples mostrada na Figura 7.29. i esta seção, descreveremos um possível uso dos componentes da arqui tetura Diffscn •. Muitas outras vari:u;Ocs s:lo posslveis. co rno descreve o RFC 2475. Nosso objet ivo aqui é apresen tar uma introduç-lo aos aspectos fu nda mentais do Diffscrv, c nilo descrc\'er o modelo arq ultctOnico com detalhes exaustivos. O leitor in teressado em aprender mais sobre Difrserv pode consultar o livro mui to abrangen te de I Kilkki, 1999( . A arqu itctum Diffsen• cons1ste em doas conjuntos de elementos funcaonaís:

Funções dr borda: classificaçíio dr pacotes c condiciommacmo dr trdfrgo. Na borda de entrada da rede (isto é, ou em um hospedei ro habilitado a Diffscrv que gera o tráfego. ou no primeiro rot~dor habilitado a Diffscn• pelo qual o tráfego passa}, os pacotes que chegam silo marcados. Maas especificamente, o campo Dafferenuated Service (OS) do cabcÇ':IIho do pacote é configurado para algum valor. Por exern· pio, na Figura 7.29, os pacotes que cslilo sendo enviados de Hl para H3 poderiam ser tn.trcados em Rl, ao passo que os pacotes enviados de H2 para H4 poderiam ser marcados em R2. A marca que um pacote


Redes multim ídia

475

Legenda:

Al ) Roteador de borda

"'j) Rot~adol de nudeo

Figura 7.2 9 Um exemplo simples de 1ede OiffseN recebe identHlca a classe de tr:\fcgo à qual ele penencc. Assim, clircrentes classes de tráfego receberao servrçOS drfcrenciados dentro do núcleo da rede.

Fun(clo a rural: rrl\·io. Quando um pacote marcado com OS chega a um roteador habilitado para Diffserv, ele é repassado até seu próximo salto de acordo com o comportam ento por salto associado à classe do pacote. O co mportamen to por saho influencia a maneira pela qual os buffcrs c a largura de

banda de um roteador s;1o compartilhados entre as chtSSC:. de tr:\fcgo concorrentes. Um dogma crucial da arquitetura Diffserv é que o comportamento por salto do ro teador se basear:\ somente nas marcas dos pacotes. isto é, na classe de trãrego a que o pacote pertence. Assi m, se os pacotes que estão sendo enviados de 111 para H3 na Figura 7.29 receberem a mesma marca dos que estão sendo enviados de 112 para 114. os roteadores da rede tratarão esses pacotes como um agregado. sem distinguir se eles se origi nam de 1-11 ou lU. Por exemplo, R3 não faria nenhuma dis tinção entre pacotes de 1-11 e H2 ao transmiti-los a R-1. Portanto, a arquitetura de serviço dircrenciado evita a necessidade de manter o es tad o do ro teador para pares fonte-desti no individu:üs- uma consideraç.1o importante para atender aos req uisitos de cscalabílidade díscutldos no itúcio desta seç;lo.

Uma analogia poderia ser úl il ncsse ponto. Em muitos eventos sociais de gnmdc escala (por exemplo, uma rccepç:lo com muitos convi dados, uma bo;u e ou discotcctt, um conce rto ou uma p:utid<~ ele [utcbol), as pessoas que partlcipar:lo do evento adquirem algum tipo de ingresso. Há ingressos VlP para pessoas mu ito importantes; há ingressos para m:ti orcs de 18 anos (por exemplo, para eventos em que serão servidas bebidas alcoólicas), há credenciais q ue dllo direito a \•isitar o camarim dos artistas; há ingrcssos cspcd:tis p:tra repórteres e imprensa em geral; há :n é mesmo um ingresso co mum para o cidadão comum. Esses ingressos são, em geral, adquiridos em bilheterias, isto é. na borda d o c,·cn to. E e aqui. na borda, que s.io realizadas as o perações que requerem intensa :nividade computacio nal. co mo pagar pelo ingresso. verificar o ttpo adequado de ingresso, co mparJr o ingresso com um docum ento de ide mídade. Além disso, pode ha ver um hmlte para o numero de pessoas de um dado ti po que poder:lo cnmu no evemo. Se houver esse limi te. as pessoas podcr.'io te r de esperar antes de entrar. Uma vez lá d entro, o ti po de ingresso dttermina o tipo de serviço diferenciado recebido nos diversos locais do evento- um Vl P recebe bebidas gratuitas. uma mesa melhor. refelç;1o gra tuita. dis põe de salas exclusivas c recebe scn•rço espccral. ao passo que uma pessoa com um não pode entrar em cenas áreas. paga s u:1 bebida c recebe apenas o servi\·o básico. Em ambos os casos. o serviço recebido no evento depende exclusivamente do tipo de ingresso da pessoa. Além disso, todas as pessoas pertencentes à mesma classe recebem tratamento igual.


Classificação e condicionamento de tráfego do Oiffserv A Ftgum 7.30 apresenta uma visi\o lógica da função de classiflcaç-.lo c marcaç1o no roteador de borda. Os pacotes que chegam ao roteador de borda são primeiramente class1flcados. O class1flcador seleciona os pacotes com base nos valores de um ou mais campos de cabeçalho de pacote (por exemplo, endereço da fome. endereço de destino. porta da fonte. porta de destino e protocolo lO) c dinge o pacote à função de marcaç.lo apropriada. A marca de um pacote é carregada dentro do campo OS (RFC 3260) no c~tbcçalho de pacote 1Pv4 ou 1Pv6. A intenç;lo é que a deflniç;lo do \.
Comportamentos por salto Até aqUI. examinamos as funções de borda da arquitetura Oiffscrv. O segundo componente fundamental dessa arquitetura envolvr o comportamento por salto (PHB - pcr-hop bdwvior ) rralizado pelos roteadores habilitados para Oiffserv. O PHB é definido de maneira cuidadosa, se bem que um tanto enigmática, como wurna dcscri\'
-

P
/ Cooflgursc:anador

Otscane

Figura 7.30 Visão lógico do dossificoçõo de pacotes e do condicionamento de tráfego no roteodorde bordo


Redes multimídia

para atingir um determinado comportamento. O PHB ~o fi m para o qual os mecanismos de alocação c implemcntaç.lo de recursos s.io os meios.

As diferenças de comportamento devem ser observáveis c. por conseguinte, mensuráveis. Até agora foram dcfimdos dots PHBs: um PHB de repasse acelerado (rx,mlitrtlJonv~~rtling- EF) IRFC 3246) c um PHB de rcp:1ssc assegurado (t&SsurccJ fonvardiug- AF} (RFC 25971: O PHB de repas~ a celerado especifica que a taxa de partida de uma classe de tráfego de um ro teador deve ser tgual ou mator do q ue uma taxa configurada. Isto é, durante qualquer intervalo de tempo , fica garantido que a classe de u:lfego receba largura de b:mda suOcicntc de modo que a taxa de sarda do tráfego seja igual ou maior do que essa taxa mínima cotlfigurada. Note que o comportamento por salto CF imphca algum tipo de isolamento entre as classes de tráfego, pots essa garantia vigora independente· mente da intensidade do trárego de quaisquer outros classes que estejam chcg:mdo a um roteador. Assim, mesmo que as outrJS classes de tráfego estejam sobrecarregando os recursos do roteador c do enlace. recursos suficientes deverão ser ma111idos d isponrveis p:.ra a classe, p:.ra ~1ssegurnr que ela receba sua ta:oca mlnhna garantida. Ponanto, o EF fornece a uma classe uma abstração si111ples de um enlace com lt~rgura de band:t de enlace minima gar:mtida. O PHB de envio assq;urado é mais complexo. O AF divide o u"áfego em qumro classes c garante, a cada classe AF, o fomccimemo de alguma quantidade mínima de largum de banda c de buffer. Dentro ele cada c.:lasse. os pacotes ainda são repartidos em uma de três categor ias de descarte preferenci
Retrospectiva do Diffserv Durante os l\ltírnos 20 anos houve numerosas tentativas (a maior parte malsucedid;\) de introduzir QoS em redes de comutaç.lo de pacotes. As várias tentativas falharam. até agora. mais por razões econõmkas c de com· patibilidade do que por razões técnicas. Entre elas esulo redes ATM fim a fim c redes TCP/IP. Vamos examinar algumas das questões envolvidas no eomcxto Diffscrv (o qual estudaremos bre,•cmcnte no próxima Seção). Até aqui. :.dmitimos que Oiffscrv é disponibilizados dentro de um unico domfnio administrativo. O caso mais ti pico ê o do serviço fim a fim, que tem de ser configurado para várias ISPs localiZ

mente a m:~ioria dos ISPs- lun outro requisito caro para o ISP. Flnaltncnte. se o DífTserv estivessem realmente disponfvcrs c a rede executasse somem<' sob carga moderada. na maior parte do tempo não se perceberia nenhuma difercn~-a entre um scf'\•rço de melhor esforço e um serviço Diffser''· Na verdade, hoJe. atraso fim a fim (: usual· mente dominado pelas taxas de acesso c s.1hOS de roteadores c não por atrasos de fila em roteadores. Imagine o infeliz cliente do Diffscrv que pagou a mais por um serviço diferenciado, mas descobre que o serviço de melhor esforço oferecido por outros quase sempre apresenta o mesmo desempenho de um SCf'\•iço diferenciado.

7.6 Fornecendo garantias de qualidade de serviços Na se~'t\o nntcrior, vimos que a marcação de pacotes c regulação, isolamento de tráfego, e escalonamcmo a nlvcl de enlace podem pro,•cr uma classe de serviço com melhor desempenho do que outra. Sob certas disciplim1s de csc:llonamcn to, como escalonamento de prioridade. as classes inferiores ele tráfego são basicameme "invislveis" à classe de tráfego de prioridade mais alta. Com dimensionamento adequado da rede , a c lasse mais aiLa de serviço pode, ele fato , atingir perda de pacote extremamente baixa e pequeno atraso - basicamente um desempenho semelhante ao circuito. Mas a rede pode garwuir que um nuxo contfnuo em uma classe de trMego ele alta prioridade continuará a receber tal serviço 110 decorrer da duração do fluxo usando apenas os mecanismos que descrevemos atê agora? Não pode. Nes1a seção, veremos por que os mecanismos ndicionais da red e c protocolos são ainda necessários para prover qltalidade com gt~rantías de serviço.

7.6.1 Um exemplo molivador Vamos voltar ao ccn.'\rio da Seção 7.5.1 e considerar du.1S aplicações de áudio de L Mbps que transmitem seus pacotes ntra,•(:s do enlace de 1.5 Mbps. confom1e ilustrado na Figuro 7.31. A ta>"m de dados combinados dos dois Ouxos (2 Mbps) excede a capacidade do enlaee. Mesmo com a classificação c marcação, isolamento de nuxos e o companilhamento ele largura d e banda não utilizada, (a qual não existe nenhuma). esta é obviamente um caso perdido. Simplesmente não existe largura de banda suficiente para acomodar as necessidades de amb.1S as aplicações ao mesmo tempo. Se as duas aplicações companilharcm igualmente a lnrgum de b.·tnda. cada umn receberia somenle 0.75 Mbps. Visto de o utra maneira. cada aplicação perderia 25 por cento de seus pacotes transmitidos. Essa QoS ~ tão inaceitavelmente baixa que ambas as aplicações de áudio são completamente inu1ilizadas: não há necessidade de transmitir quaisquer pacotes de áudio, em primeiro lugar. Sabendo que essas duas aplicações. na Figuro 7.31. não podem ser atendidas simultaneamente. o que a rede deve faze r? Permitir que as d\ras prossigam com uma QoS baixa desperdiça os recursos da rede em fluxos de aplicação que, no fim, não provecm nenhurna utilidade ao usuário final. A resposta, felizmente, H3

H1

Enlace de I.S Mbps

R2

Auchode I Mbps

H2

Figuro 7.31 - Duas aplicações de áudio concorrentes sobrecarregando e enlace Rl·R2

H4


Redes multimídia

479

esta evidente - um dos nuxos de aplicação d eve ser bloqueado (ou seja. acesso negado à rede). enquanto o o utro deve prosseguir, usando o 1 Mbps inteiro neccss.'\rio pela aplicação. A rede telefônica é um exem plo de uma rede que realiza tal bloqueio de chamad a - se as fo ntes necess.irias (um circu ito fim a nm no caso de uma rede telefôn ica) nl\o podem ser alocadas para a chamada. ela é cnt:\o bloqueada (impedida de entrar na rede) c o usuário recebe um sinal de ocupado. Em nosso exemplo. não há gan ho em permitir que um Ouxo entre na rede se ele não vai receber uma QoS s uficiente para ser considerada utiliz.wel. De fato, há um custo em admiti r um Ouxo que não recebe a QoS necessária, pois os recu rsos da rede estilo sendo usados parã suportar um nuxo que não oferece utilidade ao usuârio !lnãl. Admit indo ou bloqueando cxplicadamcnlc os fluxos com b:~sc em suas neccssid:~des de recursos c nas necessidades dos nuxos ja admitidos. a rede pode garantir que os nuxos admitidos serão capazes de receber sua QoS solicitada. Implíci ta com a necessidade d e prover uma QoS garantida a um Ouxo está a necessidade do fiuxo d e declarnr s uas necessidades de QoS. O processo de um Ouxo declarar s ua exigência de QoS e a rede acei tar o Ou xo (na QoS solicitada) ou bloqueá-lo é d eno minado r>roccsso de ad missão de chamada. Isso é o nosso quarto princiJ>io (além das trés anteriores da Seção i.5.1) em rc lac,:t\o aos mecanismos ncccss.irios para prover a QoS. Principio 4 : Se recursos suficientes nem sempre estiverem disponíveis e a QoS deve ser garwatill(l, é n ccessál'io um processo d e admissM de ch amada no qual os fluxos dcdarnm suas necessidades de QoS c. e ntão, s~o admitidos ã rede (na QoS solicitada) ou bloqueados da rede (se a QoS solicitada não pode ser forncced lda pela rede).

7.6.2 Reservo de recurso, admissão de chamado e configuração de chamado Nosso exemplo motivador cnfaLiza a necessidade de di\·crsos novos mecanismos da rede c protocolos. Se uma chamada (um nuxo fi m a fim) deve ser garam ida, de modo a receber sempre uma QoS solicitada: Rescna de I((UI SO. A Onica maneira de garantir que uma chamada tenha os recursos (largura de banda de enlace. buffcrs) ncccssán os para satisfazer a QoS desejada t alocar cxpt.cuamcntc esses recursos;\ chamada - um processo conhecido na linguagem de redes como reserva de recursos. Uma vez que os recursos s:\o reservados. a chamada possui acesso sob d emanda a esses recursos no decorrer de sua durnçlio, indcpcndcntememe das demandas de o m ras chamadas . Se uma chamada reserva c recebe uma garanua de x Mbps de largura de banda de enlace, e nunca transmite a uma taxa maior do que x, a chamada ter:l um desempenho sem perda c sem a traso.

1\c/misstlo ele clwmadtl. Se os recursos forem reservados, emào a rede dc,•e ler um mecanismo d e chamadas para solicitar c reservar recursos - um processo conhecido como admlss:\o de cha mada. Vis1o que os recursos n~o sno infinitos, uma chamada que faz urna solicllação de admissão de chamada sem sm1 t~dm iss:lo negad<~ , ou seja, bloqueada. se os recursos solicitados m\o estiverem disponíveis. Tal :tclmiss:lo de chamadn é realizada pela rede telefônica- solicit~Hnos rec ursos e discnmos um;~ ml mcro. Se os clrcuhos (slots TOMA) necessários pam completar a charnad~' estiverem disponíveis, os circuitos S•lo alocndos e a chamada é concluída. Se os circuilos llilo estiverem d isponíveis, cmão a chamada é bloqueada c recebemos um sinal de ocupado. Uma chanmda ocupada pode tcnlar novamente ganhar aclmiss:\o 1\ rede, mas não é pcrmiliclo enviar tráfego à rede :ué que ela tenha completado com sucesso o processo de :1dmissào de chamada. Nnturalmentc. da mesma forma que o gerente d o restaurante na Seção 1.3. 1 não deve aceitar reservas parn mais mes.'\S do que o restauranLe possuí, um roteador q ue aloca uma largura de banda de enlace não deve alocar mais do que est.á dispo nrvcl no enlace. Normalme nte. uma chamada pode reservar somente uma fração da largura de banda do e nlace. c um roteador pode alocar sua largurn de banda do enlace para mais de uma chamada. Ent retanto. a soma de larg um de banda alocada a 1odas as chamadas deve ser menor d o que a capacidade do enlace. l.

Sinalizaçcio da configuração de chamada. O processo de admissão de chamada descrito acima exige que uma chamada seja capaz de reservar recursos suficieme em cada e todo roteador da rede em seu cami-


nho entre os rernetemes e os receptores para garanúr que sua exigcncia da QoS fim :1 fim seja satisfcila. C:Jda rotc:Jdor deve determinar os recursos locais necessários pela sessão, considerar :JS quantidades de seus recursos que já estão comprometidos com outras sessões em andamento c determinar se ele possui recur:.os suficientes para satisfazer a cxigi!ncia da QoS por saho da scss
Sirwlizaçclo t>ara cstahelecimcnto (/e ligaçtio. O descntor do tráfego c a requisa(,'âo QoS ele uma ligação

prcetsam ser t:~rregados aos rotc-.tdorcs em que os recursos serão reservados p:~rn a ligação. 1a lnterneL. o protocolo RSVP [RFC 22lOI é usado para este propósito dentro da arquitetura lntscr.•. Nas redes ATM, o protocolo Q293lb carrega a Informação cmrc os comutadores d:JS rwcs ATM c o pomo de chegada. Ac/missclo de cltcmwda l'or elemento. Uma vez que o roteador recebe a especificação do tráfego e da QoS, ele prec1sa determinar se :Jdm•tirá a chamada ou não. Esta dec1sao de adm•ssão de chamada de!Xndcrá da cspccificaçJo de tráfego. do tipo de scr.Or leaky buckct c uma WFQ pode ser usada para determinar o atraso máximo de enfileiramento p;~ra aquela fome . Admissi\0 de chamada por elemento é mostr-:•da na F1guro 7.33. Para maiores informações sobre configuraç-Jo e admissão de chamadas, veja (Breslau, 2000; Robcrts, 2004}.

3.

Figuro 7.32

Oprocesso de estabelecimentode chamado


Redes multimídia

Oprincípio do estado soft O RSVP é usado poro criar um estado {reservas de largura de bando) em roteadores, e é conhecido como um protocolo de estado soft. Em lermos gerais, associamos o termo estado soh com abordagens de sinoli:~oção nos quois o estado criado se extingue (e ã reMovido) por lemporizoçõo, o menos que sejo renovado periodicamen te pelo recebimento de uma mensagem de sioolixoçõo [corocteristicomente do entidade que criou o estado no inicio] indicando que o estado deve continuar e permanecer instalado. Como um estado nõo renovado seró extinto o qualquer momento, o sinoliz:oçõo de estado soh não requer remoção explícito de estado nem um procedimen to poro remover estados órfãos coso o criador de estados falhe . De modo semelhante, visto que criação de estado e mensagens de renovação serão seguidos por mensagens do renovação periódicos subsequentes, não é necessório sinolizoçõo confiável. O lermo estado soh foi cunhado por Clork (Ciark, 1988]. que descreveu o noção do mensagens periódicos de renovação de estado enviados por um sistomo final o sugeriu quo, com ossos mensagens de renovação, o estado podia ser perdido devido o uma fo lha e entôo res taurado ou tomalicomenle por mensagens de renovação subsequenles - tudo tro rnparente poro o sistema final, e sem invocar nenhum procedimento de recuperação de falho: o informação de estado nõo seria crítico poro o manutenção do tipo do serviço desejado onociodo com o Auxo. Em vez disso, aquele tipo de serviço seria imposlo pelos extremidades, que enviariam mensagens periodicamente poro assegurar que o tipo de serviço adequado está sendo associado com o Ruxo. Dessa maneiro, o infOfmação de estado associado com o fluxo poderio ser perdido devido o uma falho sem causar o disrupçõo permanente dos corocteristicos de serviço que estão sendo usodos. Eu denomino esse conceito 'estado soh', e ele pode perfeitamente permitir que alcancemos nossos metas primórios de resiliêncio e flexibilidade...• M . ..

Grosseiramente falando, o essência de uma abordagem de estado soh é o utilização pelo criador de estado do serviço de melhor esforço poro criação e renovação de estado e remoção de estado por esgotamento de temporizador no montenedor do estado. Abordagens de estado soh foram adotados em inúmeros protocolos, entre eles RSVP, PIM {Seção 4.7), SIP {Seção 7.4.3) e IGMP (Seção 4.7] e em tabelas de repasse e pontes transparentes {Seção 5.6). Sinoliz:oçõo de estado hord adoto o abordagem inverso do estado soh - o estado cri ado permanece efetivo o menos que explicitamente removido pelo recebimento de uma mensagem de remoção de estado enviado pelo criador de estado. Visto que o estado permanece efetivo o menos que explicitamente removido, o sinali· zoç.õo de estado hord requer um mecanismo p9ra remover um estado órfõo que permanece após um criador do ostodo folhor ou sair sem ler removido o estado. De modo somolhonte, umo voz: que criação e remoção de estado são realizados apenas uma vez: (e sem renovação de estado ou esgotamento de temporização de estodol, e impor tante que o criador de estado saiba quando o es tado foi criado ou removido. Assim, protocolos de sinalização confióveis (e não de me lhor esforço) sõo comumento associados com protocolos de estado hord. Então, groneiromente falando, o essência de uma abordagem de estado hord é o criação e remoção confióveis e explfcitos de informação de estado. Abordagens de estado hord foram adotados em protocolos como ST-11 (Portridge, 1992; RFC 1190) e 0 .293 1 (ITU·T 0 .2931 , 1994 ). O RSVP oferece remoção de reservo explicito {se bem que opcional) desde que foi concebido. Sinalização confióvel baseado em ACK foi introduzido como uma extensão do RSVP no (RFC 2961) e também foi sugerido em (Pon, 1997). Assim, o RSVP adotou, por opção, alguns elementos de uma abordagem de sinalização de estado hord. Poro umo discussão e comporoção de protocolos de estado soh hord, vejo (Ji, 2003).

vetsus estado

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------s.nahzac;~ de estabelecimtnlo de chamada com

aos

Elemen1o considera ré<;urSOS réqurSilados. ré( ursos não reservados

Figura 7.33 Comportomentode
7.6.3 QoS garantido na Internet: lnt,erv e RSVP A a rquite tum de serviços Integrados (lmserv) t um ambiente desenvolvido demro da IETF para romecer ga ra111 ias individuali:rodns de QoS a sessões de aplicações individuais na lmernet. A cspccif'icaç.\ o de gamntia de serviÇOS llllserv, def'imda em IRFC 22121, determina limites estáveis (matcmallC~Imen tc comprováveis) sobre os aU'Usos de cnnlciramcntos que ocorrcrào com um pacote em um roteador. Enquanto os detal hes por trás de um serviço garantido sao complexos, a base da ideia é bem s imples. A uma primem\ aproxím;tçilo, '' caractcrizaçào de uma ron tc de trnrego é dada por um leaky bucket (veja Sc\'àO 7.5.2) com par.lmetros (r,b) e o serviço requisitado é caractcri:rodo por uma velocidade de lransmiss<\o R, ã qual os p:~cotes ser:lo transmitidos. Em csstncia. uma chamada que requisita um servi ço garantido está requisitando q ue seus bits nos pacotes sejam garantidos em uma taxa de transmisslo de R bits/seg. Dado que o u-Jrego é cspccif'icado usando urna caracterização lcaky bucket, c uma vcloc1dade gamntida de R estâ sendo requisitada, também c possível limitar o atraso mâ.'l:imo de enrileiramento no roteador. Lembre-se de que com a car;~cteriza'-\o de tráfego lcaky bucket. a soma do tráfego (em bits) gerado através de qualquer intcn-alo de tempo 1 é limitada por rt + b. Lembre-se também da Seção 7.5.2. onde vr mos que quando uma rontc lcaky buckct é alimentada em uma fila que garante que o trárcgo enfileirado scr:i servido a uma velocidade de R bits por segundo, o máximo de atraso d e enf'ilciramento que o pacote sofrerá estará limitado por b/R, desde que R seja maior que r·. Omra forma d e g.rra ntia d e serviço lntscrv também foi dcf'inida. conhecida como c-arga de serviço controlada, que específica que uma chamada receberá "uma qualidade de scn •iço aproximando a QoS que o fluxo que receberia de um elemento de rede descarregado~ [RFC 2211] . O Protocolo Reserva de Rec urso (RSVP) [RFC 2205; Zhang, l993l é um protocolo de si n:~lizaç:'lo da l n~ernet que pode ser usado para efetuar a sinalização ele chamada exigida pela lntserv. O RSVP também fo i usado j untamente com Diffserv p~1rn coordenar as funções Diffser'' atra,·és de m(,hiplils redes, c também foi estendido c us;~do com um protoc.:olo d e sinalizn~~\o em o utras d rcunstãncias, tal vez mais notavel mente na ro rm a de RSVP-TE [RFC 3209) para sina lizaç:\o MPLS, como visto nn ~çào 5.8.2. No contexto lntscrv, o protocolo RSVP pennitc que aplicações rescn•crn a banda para o seu Ouxo de dados. ~ usado por um hospedeiro, em beneficio de um fluxo de dados de uma aplica~'ào, pam requisit:~r uma quantia

especil'ica de banda da rede. O RSVP também é usado por roteadores pam o envio de pedidos de reserva de b~mda . Para implcmcnt:lr o RSVP, o software do R.SVP precisa estar presente nos receptores, transmissores c roteadores ao longo do caminho f'lm -fim mostrado na Figura 7.32. As duas principais c-aracterísticas do RSVP são: Fornecer reservas para banda em árvores muhlcast. com o unicast sendo trat:~do como um c-aso degenerado de multicast. Isso é paniculanncnte importante para aplicações multimídia como trnsmissão de fluxo contínuo de TV atmvés de IP. onde muitos receptores podem querer receber o mesmo tráfego de multimídia enviado de uma mesma o rige m.

Ebaseado no receptor; ou seja, o rcccptór de um fluxo de dados mic1a c mantém a reserva de recursos usada por aq uele fluxo. A visão inovadora e centrada no recebimento usada pelo RSVP coloca os recep-


Redes multimídia

tores no controle do tráfego que recebem. por exemplo, permitindo que receptores diferentes recebam c vejam uma multimldia multicast em diferentes resoluções. Isto ~ constr.tStantc se compar-.tdo ti visão de smahz:wào centrada no lransmissor adotada na recomcndaç:lo Q293lb do ATM.

O padr-Jo RSVP (RFC 2205) n:lo especifica como a rede fornece a banda rese rvada aos nuxos de dados. É simplesmente um protocolo que permite que as aplicações reservem a borda ncccss:lria no enlace. Uma vez que as reservas estào no lugar certo, f funç-lo dos roteadores na Internet fornecer a banda rescr\"ada aos nuxos de dados. Este supmnento provavelmente se ria fei to usando os mecanismos de escalonarne111o c regulação ( lcaky buekct, escalonamento prtoritário, cn fileimmcm o pondemdo justo) vistos na Scç;\o 7.5. Para mais infonnações sobre RSVP, ' 'cja (RF C 2205: Zhang, 1993) c o material eletrônico onli nc associado a este li vro.

7.7 Resumo A rede multimídia ta lvez seja um dos desenvolvimentos maLS interessantes (comu m potencial q ue ainda não se realizou to talmente) da Internet de hoje. Pessoas em todo o mundo estilo passando menos tcm r>o di:Huc de seus ap:1rc lhos de rádio ou televisão c usando mais a Internet para reccl>cr transmissões de áudio c vldco. ao vivo ou pré-gr:n~.tdas. À medida que o acesso de alta velocidade ror Invadindo mais e m:1ls resid~ncias, essa tendcnda cont inuará - os habituados aos sofás de todo o mundo acessa rão seus programas f.·woritos em vfdeo por meio da Internet, c nào pelos canais tmdi cionais d e distribuição bromlcast. Além da distribuiçào de áudio c vídeo, a Internet está sendo usada para transmitir chamadas telefôni cas. De falo. nos próximos dez anos ela poderá ,.; r a substitu ir o quase obsoleto sistema de telefonia de comut:1ção de ci rcuitos em muitos p:1fses. A Internet não so mente proverá serviço tclcfõmco mais bar:uo, mas trunbém oferecer::\ numerosos serviços d e valor agregado. como vtdeoconfcrtncia, lista telefônica on-line, serviço de mensagens de vÍ\"a· YOZ c integração com a Web.

Na Scç;lo 7.1 . classiOcamos aplicações de multimídia emtrts ca tegorias: á ud io c vídeo armazenados de nuxo continuo: transrmss
nm

Da seção 1.2 à 7.'1, cxamin:unos ~uqu iteLuras e mec:1nismos para rede muhlmidia com se rviço de melhor N:1 cçlo 7.2. avaliamos diversas arquiteturas para nuxo contfnuo de t\uclio e vfdeo armazenados. Dis<.: utitnos interação com o usuário- como pausa/reinfcio, reposicion;.uncnto c nva nço rápido vistlal- c apresen tamos uma introd uç:'lo ao RTSP, um pro[ocolo que provê interaçrto cliente-servidor para ap licações de fluxo continuo. Na Seç:lo 7.3, examinamos como aplicações interativas em tempo real podem ser projetadas parn rodar sobre um:1 rede de serviço de melhor esforço. Vimos como uma co mbin:11,::lo de buffcrs clientes, nlimeros de sequê ncia de pacotes c marcas de tempo pode ali"iar os efeitos da '~lrhw;lo de atraso induzida pela rede. Também vimos <.:o mo um CO N facilita o armazenamento d o Ouxo continuo de mult imídia ao pressionar proati vam cntc a multimídia aos servido res CDN lomlizados próximos dos po ntos d e chegada do us uári o.

esforço.

1 a Seção 7.5, introduzimos como \'ários mecanismos de rede (dtscipli nas de escalonamen to de ni\rel de enlace c condícíonamcnto de lr:lfcgo) podem ser usados para fornecer scn•tços diferenciados entre divcrs.1S classes de tráfego. Finalmente. na Sc\"ão 7.6, investigamos como uma rede pode fazer garantias de qualidade de sen•iço às chamadas ad mitidas na rede. Aqui ainda ro ram necessá rios novos mel"::nismos de redes e de protocolos, indumdo rescn':l de recursos, admissão d e chamada e sinalização de chamada. Juntos, esses novos elementos de rede fazem com que o Qo$ gam ntido de rede do futuro seja bem difercmc (c muito mais complexo) do que a Internet de melhor esforço atual.

bow4tto4ic~ Redes de computadores e o lnte ;.; ro;.;e;.;.t_________________________

Exercícios de fixação Questões de revisão ~ões 7.1

1.

2.

3.

...

o 7.2

o

que stgnlllca mterauvidade no caso de nuxo continuo de .mdiolvfdeo? E no caso de ~udiolvfdco interativo em tempo real? Fomm discutidos tri!S campos par:~ aprimorar a lntcmcr de modo que e lu twssa dar melhor suporte ;\~ aplicuçõcs de muhimldiu. Faça um brC\'c resumo das viS(\cs de cada camp,l. Qual deles vocC defende? Quais Silo algumas pr<>l)(>rçt)es tlpicas de comprcss;lo (pwpon;·flo do numero de bits em um objeto n:lo comprimido ao número de bits na versâtl comprimida daquele objeto) pam aplicact'H:s de imagem c áudio. c as técnicas de com pr~'SSâo discutidas nu Scç.io 7. 1? As llgur.ts 7. 1 c 7.2 apresentam dois esquemas par:1

nuxo conrfnuo de mldia nrmazcn:tda. Quais as \'3nragcns c a desvantagens de cada esquema? S~ões7.3o

5. 6. 7.

8.

7.4

Qual c a di[crença entre atraso llm n fim c vnriação de atraso? Quais s:\o as causas da \'ariaç:\o de atraso? Por que um pacote recebido após seu tempo de reprodu c;\o programado é considerado perdido? a Seç.lo 7.3. descrevemos dois esquemas FEC. Faca um pequcncl resumo deles. Ambos os esquemas aumenta m a raxa de trnnsmissão da corrente adicion:mdo sobrecarga. A intercalação tambêm aumenta a taxa de t ransm iss~t>? Qual o lXIJ>el do DNS em uma CDN? O DNS tem que ser rnodincado r>ara dar suporte a uma CDN? Qual

mform:tcJo, c cxtsre .tlguma, a CDN deve fornecer ao DNS? 9. Que tnformacão e nccess.iria J):lr.l o dimensrM:uncnto de uma rede paro que um determinado nível de qualidade seja alcancado? 1 o. Como as cliferenres correntes RTP em sessões dife· remes s.lo ldcmlficadas por um receptor? Co11u' as diferentes correntes 1ntern:1s à mesma scss:\o s:\o idcntllleado.s? Como s:'lo distinguidos os pacotes RTP e RTCP (come' t>artc da mesma scss:to)? 11. Trcs ripos de p:tcntes RTCI' fonun descritos na Secào 7.4. Faça um pequeno resumo ela inform,1c~o cnntida em cada um desses tipos de pacot ~s. 12. Qmtl é o papel de um registro SlP? Como o papel de um rcttistrt> SIP ê diferente t.h: um homc agenl cmiP móvel?

Seções 7.6 o7.9 13. Na Sec~o 7.5. dtseutimos o enfileiramento priorilá·

rio nào precmprivo. O que seria um cnfileiramenro prioritário preemjHivo' O enfileiramento prioritário prccmpli\'O tcri:l sentido em redes de computadores? H . Dê um exemplo de disc1plina de escalonamento que rulo ê conservadora de trnbalho. 15. Di' um exemplo de enllleiramentl)S que voe.! \'ivcncia em sua rotina di:lria, com disciplina FIFO, prioridade, RR c WFQ 16. Cite algumo.s dificuldades associadas ao modelo I nts.:r" c à rcscrvr~ de recursos por Ou~~:o.

Problemas l.

2.

N;wcguc no Wcb c ache duas páginas qucconumham nuxo COIItiiiUO de ;ludio e/ou vfde{1 ;trmazcnõldo(S). P01ra c;~da produto, use Wireshark para determinar: a . se s~lo usados metnrqulvos; b. se o áudioN!dco é e•wiado llOr UDP ou TCP: c. se c usado RTP: d. se é us.1do RTSP. Consrdcrc o buiTcr cliente mostndo na Figura 7.3. Suponha que o si)tema de transmiss.'lo use a terceira opção, isto é, o scn1dor lança a mídia no sochet o mais rapidamente possível. Suponha que a largura de banda TCP disponível seja >> d na maior parte do

3.

...

tempo. Supo nha tt1mbém que o bufrcr cliente pode conter somente cerca de um terço da mldia. Descreva corno x(l) c <> contcudo do buiTcr cliente cvoluirlo com o tempo. O bufrer de recebimento TCP c o buffcr cliente do transdutor s.lv .1 mesma COIS.'\7 Se não s:\o, como eles imcragcm? 'lo exemplo de telefone por Internet da Scç:\o 7.3. seJa la o numero total de h) t~ de Ci!hec;.tlho :tdicron:tdõ a cada porçlo, incluindo os cabeçalhos UDP e IP. a. Admitindo que um datagrama IP seja emitido a cada 20 milissegundos, qual é a raxa de trans-


485

missão em bhs por segu ndo para os d:uagramas gerados por um lado dessa aplicação?

nuls de 20 milisseg\mdos se os dois pacotes pertencem à mesma rajada de ,·oz?

b. Qual é um valor upico de l1 quando é usado

b. Como o receptor pode usar m\rneros de sequêncta para determinar se um pacote c o primeiro de uma mj:tdn de voz? Scp objetivo em sua

RTP? 5.

Redes multímldio

Considere o proccdimcmo descrito na Seõo 7.3 para cstimnr o ntra:.o méd1o ti,. Sut>onh3 q ue u 0. 1. Seja r 1 - 11 o atraso da amostra mais recen te, seja': - ' : o :maso da amostra mais receme scguimc c assim 1>0r diante.

=

a. Para uma dadn aplicaç~o de audio. supon ha que

resposta.

10. Considere a figura nb.1ixo (que c shnilnr a Figura 7.5). Um transmissor começa a e nviar aud io empacotado periodicament e em r • I . O primeiro pacote chega quando o trn nsmissor cs1:\ em t "8.

quatro pacotes tenha m chegado ao rccep10r com atrasos de amostra d e r. - 1,. r, - 1). 1'1 - ' r r1 - 11• Expresse a estimativ:l ele atraso tl e m termos dns q uatro amostras.

b. G~ rternlíze sua rórmula puro 11 atr;15(1S ele amostra. rara 11 rónml1:1 d a parte ( b ), s uponha que 11 tenda ;l(l ln nntto c d i! a rórmula rcstdt311te. COmente p<)r que esse pmcedimcnto d e determinação de médit1 é d cn
6. 7.

Repila as pa rtes (a) c ( b) da questão an1erior pa ra a cst nnama do dcsv1o médio do a traso. No exemplo do 1cldonc por lmcme1 na Seção 7.3, apresentamos um p rocedi mento on-line (média móvel exponencial) para estimar atraso. 'este problema c.xaminarcmos um procedimento alternati\'o , Seja 1, a marca de temrx1 do 1-ésimo paco1c recebido: ~ja r, o tempo em que o f·csimo paco1c c recebido. Seja d. nossa estimativa do atrnso médio após o recebimento de) c·ntsimo p:temc. Após a rece(l\'1to do primeiro pacote. cst:~btlccc mos :1 estimativa de atraso como cl, =r, - 11•

a. Supon ha que gostaríamos que d. • ( r, - 11 + ,.J - r1 + . , . + r.)/n para lod o 11. Deduza uma ft\nnula recursiva para cl. em termos de d._,, r•• e r•. b. Descreva por que, pnra a tcldo nia por Internet , a c~ t im:u l vn ele a traso descrita na Scc.âo 7.3 c nmis apropriada do que a cs1ima1iva esboçada na Parte a.

r·. -

8.

9.

Compare o proccdimemo d escri lo na Seção 7.3 para a csum:uiva do tksvio médio d o :u raso com o procedimento
a.

Qu:~ís

s:lo os a1msos (dt) transmissor no receptor, ign orand o qualquer a1rnso de 1rans missi\o)d os pacotes 2-8? Observe que cnd:t segmento de linha ve rtical c horizontal na figura tem o comprimento de I. 2 ou 3 umdadcs d e tempo.

b. Se a transmtssdn de áudio começa assim que o r..:ccptor estJ e m t • 8. q ual dos primc1ros oito p:~co1es enviados nilo chegará em tempo para a transmiss.lo? c. Se a 1ransmissdo de áudio começa assim que o receptor está em 1 • 9, qual dos primeiros oito pacotes en viados nno ch cganl em tempo para a transmissão?

d. Qual o mrn imo de :umso d e 1ransmiss:'lo no receptor que resulta em todos os primeiros oito pacotes c h~:g.1n:m a tempo para :t trunsmlss:lo. 11. Consid ere novamente u Ogum em PIO, que mostrn os tempos de tmnsmi~suo dos pacotes de áudio c os tempos de rcccpç:'lo

a . Calcule o atrnso e:.t í m:~do l>;•m os pa~:otes de 2 a 8, US.1 ndo a rormula pam d,, d a Seção 7.3.2. Use o valor de 11 • 0, 1.

b. Calcule o desvio estimad o do atraso para u mMia cs1irn ada p:1ra os pac01cs 2 n 8, usando a fórmula para v, da Scç!lo 7.3.2. Use o \'alor u • 0,1 12. Recorde os dois esquemas FEC pa ra telefone por lmcrnct d cscntos na Seçdo 7.3. Suponha que o primeiro esquema gere u ma porcão redundante para cad a quatro porç1\es originais. Suponha que o segundo es
bow4tto4ic~ Redes de co 111 putod ores e o Inle:.;rn:,:e:.:,l_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

a. Quama lnr&ura de banda adicional cada esquema requer? E quanto atraso de rcproduçJo cada esquema adic1ona? b. Cum
c. Corno os dois ~quemas funcion~r-.lo se em cada grupo de dOIS pacotes o pnmeiro for pétdido? Qual esquema terá melhor
capacidade de enlace em uma rede (supondo que a CDN use os enlaces cxislcmes para distribuir seu comeMo cmre os Ms CDN), como um CDN apri· mom seu
no rclatMio de reccpc:lo RTCP? (Díct~: leia o RFC do RTP.) 16 . a . Suponha que cnvi:1mos dois datagramas IP para ,1 Internet, cada um porlando um segmento UDP diferente O primeiro da13grama 1cm endereço IP de fon1e r\ I. endereço IP de destino B, porta de fome Pl c pona de destino T. O segundo datagram3 tem endereço IP de fonte A2. endcre· co IP de destino 8. porta de fome: P2 c: porta de dcsunu T. Suponh.1 que A I ~
17. Considere um;l scss."lo RTP com quatro usuários. todos eles env1ando c rcccbl:ndo J>
18. a . Quais as semelhanças entre o RTSP e o liTTP? O RSTP tem mctodos? O IITTP pode ser us:tdo para reqmshar uma corrente de dados?

as diferenças cn1re RTSP c HTTP? Por exemplo. o IITTP c dcmro da banda ou fora da

b. QlUiis

banda? O RTSP man1em inform:tç:lo de estado sohrc o clienlc (considere a runc;;lo paUS3/rciní· cio)> 19. Verdadeiro ou fabo: a. Se um vfdeu armazenado c entregue diretamente de um servidor Wcb a um lmnsduHlr, então a aplicacdo está usando TCP cmno pro1ocolo de transt>orte suhjncentc. b. t\ o usar RTP, ~ possfvd que um rcm~temc mude: a codilica\'
c. Em sen·1cos d1fcrcnc.ados. amda que o comporta· memo por salto dcfma d1fercnças de desempenho entre classes. ele m\o imptM: nenhum mecanismo parucular p:tro alcanc:tr esses desempenhos. f. Suponh3 que Alice quer cstabc:lc:cc:r uma SC:S· sâo SIP com 13ob. Ela mclm. n3 sua mensagem I ' VITE. a linha m • audio 48753 RTP/AVP 3 (AVP 3 dcno1a áudio GSM). Ponanto. Alice indicou em sua mensagem que ela deseja enviar áudio GSM. g. Com rcfcr~ncia j declnrnç;lo :tnlerior, Alice indi· COll em sua mensagem INVITE que enviará áudio paro a port;~ 48753. h . Mensagens SIP s:lo enviadas tipicamente entre entidades SIP usando um mlmero dcfauh p3ra a porta SIP. i. Para m:mtcr scll regls1 ro, clientes SIP têm de ctwlllr mensagens REGISTER p~riodic:a me ntc. j. SIP irnpuc ttiiC todos os clientes SIP suporlcm codiflcaçiltl de áud io G. 71l . 20. Suponha que a polilica de csc~lon:unerllu WFQ seja aplicada a um huffer que suporta tr~ classes; suponha que os pesos p~ra essas tr~ classt:s sejam 0.5, 0.25 c0.25. a. SlljX>nh.t ttiiC cada classe tcnh.'l um grande mime· ro de pacotes no bufTcr. Em que scquencia poderiam ser a1cmlidas essas 1rês classes para atingir os pesos WFQ descritos? (P;tra escalonamenLo por varredura c!clica, uma scquência natural é 123123123. ' .)

bOWAttOOiC~

I

Redes

(apilulo 7

tes restantes s;lo de prioridncle baixa. Indique os compartimentos nos quais cada pacote de 2 a 12 deixar:\ a fila

b. Suponha que as c:lasscs 1 c 2 tenham um grande numero de pacotes no burTcr c que não haja pacotes de classe 3 no burTcr. Em que sequÇncill M trÇs clnsscs podcnam ser atcnd1das para alcançar os pesos WFQ descrilos?

b. Agora suponha que um scniço em sequ~ncia é usado, com os pacotes I, -t. S. 6 c li pertencentes a uma classe de tmrcgo. c os restantes pertencendo a uma segunda classe de trMcgo. Indique os compartimentos nos quais cada pacote de 2 a 12 dei xará a fila.

21. Cons1dcrc a figura a seguir. sim1l"r às Figurns 7.22 a

7.2S. Responda as seguintes pergunras: u

•' ! •••

11 10

........

·-· ·-·

•• 10

,• »

,

...

-

a. Supondo que o serviço~ FIFO. indique ll tempo em que scrvc que pode ns 12 pacmes?

c. Suponha agora um scrv1ço WfQ. com os p:.cotes I, -t. S. 6 e 11 pcrtcnccnles a tlm:t classe de trá· rego. c os rcst:ultcs pertencendo a uma segunda classe de tnHego. ;\ classe I tem um ileso WFQ de I, enquanto a classe 2 tem um peso WFQ de 2 (ohscn•e (jlle es1cs pesos sao dircrcntes do que na q11es ti\o ~ntcrlor). lndiq11c os cornpartimc•Hos nos qunis cndn p:1cotc de 2 a 12 deixam o enr.Jcimmento. VCJU também a aclvcrtl!ncia na questão acima rclati"o ao servi co WFQ.

23. Considere a ngum ab:~ixo, que mostra um lcaky buckct sendo alimentado IXlr um nuxo contínuo de pacotes. O burTcr de tokcns pode segurar no, maximo dois tokens c l'SI:I inicialmente cheio em 1 =O. Novos tokcll!> chegam em uma vdocid.1
ç:_·!:j'---··

v ..,......

l<> ....... .

nm ,... ,.. ~ ..• Jl.llU"

L!

.

,.. ....

...........,

Os

pacott"S chegam, nl) começo do compMli·

m ~nto. Sendo assim , na ngurn, os pacotes I, 2 c

3 chegam no com partimcmo O. Se já existirem l>acotes no fi la, os pacotes que \lllo chegar se j untam no nnal da nla. Os pacotes pro:.cguo.:m em direcâc)
Dcp~1is da:. chc~acl:tS serem adicionadas :'\ nla. se j:\ existirem l)acotes n:.1 nta, um ou dois desses pacotes (dependendo do numero de tokcns disponípi\'C~is) Irão remover um tokcn do bu!Tcr de tokcns c imo ao enlace de s:lfda durante esse compartimento. Sendo assim, os pac01es I c 2 rcmo\Cm um token do bufrcr (j:t que existem inicialmente 2 tokcns) c ,,\o ao enlace de salda durante o componamcnto O.

3.

Um novo tokcn é ad icionado ao buffer de wkens se este não estiver cheio, já que :. velocidade de

22. Cons1dcrc nov;tmcntc a figura de P21.

.

1•0

IMJtf.,.,.... . . .M

e. O que \'OC~ pode obscn"ar sobre o tempo de atm· so médio nos qttalro casos (FICO, RR. prioridade c WFQ)? a. Suponha um serviço prioritário, com os pacotes 1, 4, S, 6 c l l sendo de prioridade alta. Os paco-

487

111ullin~ldio


cria~;\o

de 1okens é de r .. I loken/compani-

mcmo. 4. Tempo a\'Jnça a próxima emrada, e as e1apas se

repelem. Responda às scguimes per~ unias: a. Para cada comp.1r1imen1o de 1empo. tdcmillque os pacotes que esulo na fila e o numero de 1okens no buckcl. imcclialamcntc depois que as chegadas rornm proccssndas (clapa I ~cima) mas MICS QUC I)S paC()les passem a nla c rcm
26. Considere o sis1ema de lcaky buckc1 (discutido na Sccôlo 7.7). que regula 11 l:lx;t média c o 1am;1nhu da mjada de um Oul\o de pacotes. Queremos agora lambem regular a 1axa de pico i'· l\los1re como a sarda desse regulador leaky huckc1 pode ser alimen· 1ada para um sc~undo reguladtlr de le:.tk)• buc:kc1, de modo que os dms. em série. regulem a 1axa media. a 1:1xa de pico c o 1am:.111ho da rnjada. Não esqueça de :uribuir um latnanho c uma 1axa de gcrnç:\o de J'emlissào :t<> balde do segundo rq;ulador. 27. Diz-se que um fluxo de fXlCOIC est:l de acordo com a

(.'Sj)(ciflcac:;lo de um lc:tky huckc1 (rJ,) com tamanho de rajada b c taxa média r se o numero de pacotes que chega ao lc:;tky huc Íarn 1od<> 1. Um fluxo de pacmes
b. Para cada coml>tlrlltncnto de ICill f>O. indique qual J)acolc apttrcccrá IH\ snrda depois que os tokens forem removidos ela fi1:1. Sendo assim, ,,ara o compal'timcnlll 1 • O no exemplo acima, os pa.coICS I c 2 :tparccem no enlace de saída do leaky buiTcr duram c a em mda O. 24. Repila o problema 23. mns suponha que r • 2. Admhn novamcn1e que o bucke1 cst:l cheio inicialmcmc. 25. Considere o problema 24, mas suponha agora que

r • 3. c que h • 2 como antes. Sua resposta paro a questão acima é d1fcreme?

28. Dem1lllStre que. cnqunnlu r 1 < Rw/(! w) . então d_, é, na verdade, o mraso m:lximo que qunlquer pacote do Ouxo I sofrerá na nta WFQ.

Questões dissertotivos 1.

2.

3.

...

5.

a . O que é um PABX 1racl1cional? Quem o ulilil:l?

Encontre urna em1nes:1 que distribua fluxo conlinuo de vldco ao vi\'O usa ndo distribui~;lo P2P Escreva um anigo sobre a fundamemaç:lo da tecnologia. Na sua opini:'lo, é melhor transmitir fluxo comlnuo de áudio/vldco por TCP ou por UDP? Escrc1'õ1 um rel:uorio sobre os produtos SIP da Cisco.

O prohlcma de fomccimcmo de garnmías de QoS pode ser resolvido simplesmente romeccndo largura de banda sufícicme, lslo é. apenas aumentando todas as capacidades de enlace, de modo que as limim~ões de Iargum de bandn deixem de ser lllna prcocu paçào? Um intercssanle merendo emergente cs1á us.·mdo o tclcftlnc por Internei c a LAN de 01ltn vd~idadc de urna empresa para subslituir seu PABX {priwuc lmmcl1 c_-cchcmge - ccmral privada de commaçào tcldõnica) Fa~ um relatório ele uma página sobre esse assumo que inclua ns seguintes questões:

b. Considere uma chamada entre um usuário na

6.

empresa c omro uSlt:lrio foro da empresa realiza· da pela rede de 1eldoni:t tmdicional. Que 1ipo de tecnologia c neccss.~r ia nn imcrfncc cmrc a LAN c a rede de 1clcfonia lradicional? c. ,\lém do so ftw:~rc do telcfon~ por Internet c da intcrrace da pane (b), o que mnis c preciso para subsnluir o Pt\13X? Pense em como umn rede de rodovias é dimensiona· da (por exemplo, como o nllmcro is tas em rodo· " ias condu zidn n unm cidade gmndc é determinado). Faça uma lista com as quatro clnpas que \'OCc acha que um engenheiro de 1rnnspor1cs le\•aria em consi· dera~:\() quando dimens ionando 1al rodovia. Quais silo as claJ>3S :~n~ logas no dlmensltlnar 1101:1 rede de compulndorcs1

Wireshork Lob Nes1c laboratório vocé 1mplcmcn1ará um scn·idor e um cliente de vídeo de fluxo contínuo. O cliente usará o protocolo de Ouxo contínuo em tempo real (RTSP)

para con trolar as :~çõcs do serv1dor. O scn•idor usará o protocolo de tempo real (RTP) para cmpacolar o vídeo para transporte por UDP.


Redes multim idio

Você receber:\ um código Java que implemcmara parcialmente RTSP c RTP no cliente c no servidor. Sua tarefa scra conclu1r o cóchgo para o cliente c também para o servidor Qu.1ndo tcm1inar. você tcr:l criado uma aplicaç;\o cliente-servidor que ruo seguinte:

O código q ue voei! receber:\ implcmenta o protocolo RTSP no servidor e o dcscmp:~cotamcnto RTP no clie nte c tambêm cmda da aprcscntaçtlo do ' 'idco transmitido. Voce prcc1snra 1mplememar RTSP no cliente e RTP no scr,•idor.

O cliente cmia com:mdos RTSP SETUP, PLAY, PAUSE c 1 EARDOWN c o servidor responde aos comandos.

Esta tarcra de progrnmaç:\o aprimorar.\ significativamente a comJlrecnslo de RTP, RTSP c vfdeo em nuxo conunuo para o ahmo. Recomendamos veementemente que ela seja cxccutnda. A tarda também su~crc vários excrc1cios opcionais, incluindo implememação do comando RTSP DESCRIBE no cliente c também no scl'\ridor. Vote cnctmtrará Informações completas sob re a t:trcfa. bem como snlflJlCIS lmponantt>s de código j3va. no Companion Wcbsite deste livro, \'IWI~ . aw. c om/

Quando ti servidor estiver no estado de rcproduc;lo, ele pega periodicamente um quadro JPEG anm1zenado, CIUJ)aCOia o quadro com RTP c envia o pacote RTI" para um sockct UDP.

O cliente rccchc os

pt\cOICS RTP. cxtroi os t1uadros JPEG, descomprime os quadros c os ~•prcscnta rw seu monitor.

kurosê_br.

bow4tto4ic~

Henning Schulzrinne Henning Schulzrinne é pronmor, diretor do Departamento de Ciências do Computação e chefe do Internet Reo'-Time Loborotaty do Universidade Columbio. ~ cooutor dos protocolos RTSP, RTP e SIP, protocolos funclomentois poro comunicação de 6udio e vldeo pelo Internet. ~ graduado em engenharia elétrico e industrial pelo Universidade de Dormstadt, no Alemanha, mestre em engenharia elétrico e de computo· çõo pelo Universidade de Cincinnoti e doutor em engenharia elétrico pelo Universidade de Mossochusetts, em Amherst.

O que o fez se decidir pela especialim~ão em tecnologia de rede multimidia? Aconteceu q uase por acidente. Quando fazia doutorado, acabei me e1wolvendo com a DARTnet, uma rede experimental que abrangi:' os Estados Unidos com linhas T L. A DARTllct era usada como campo de prova para ferramentas multiccw c de lrnernct em tempo real. Isso me levou a implementar minha primeira ferramenta de :ludio, a NcVoT. Por intermédio de alguns participantes da DARTnet, a~..-abci me envolvendo com a IETF, com o grupo de trabalho Audio Vídeo Tronspon, que se formam havia pouco tempo naquela ~poca. O grupo terminou por padronizar o RTP. Qual foi o seu primeiro emprego no setor de computação? O que implicava? o meu primeiro emprego no setor de computação fiz a soldagem das peças de um computador Altair. Eu ainda cr.1 estudante do ensmo médio em Livemwre, na Califórnia. Quando voltei à Alemanha, montei uma pequena empresa de consultoria que projetou um programa de gerenciamento de endereços para uma ag~ncia de viagensarmazenando dados em fitas cassete p:~ra nosso TRS-80 e usando uma m:lquma de escrever elétrica Selccmc da IBM com uma mtcrface de hardware feita em casa servindo de unprcssora. Meu pnme1ro emprego verdadeiro foi no AT&T Bell Laboratoncs, no descnvolvnnento de um emulador de rede paro a construçào de redes experimentais em ambkn te de laboratório. Quais os objetivos do Internet Reoi·Time Laboratory?

Nosso objetivo é fornecer componentes c construir blocos para a Internet como uma única infmcstruwra de comunlcaçào. Isso inclui o dcserwolvi mento de novos protocolos, como o GIST (para sinalízaç:lo de camada.-; de rede) e o LoST (para cncomrar recursos por locais), ou a r>rimorar os protocolos nos quais já trabalhamos anteriormente, como o SIP, através de trnbalhos de presença aprimomda, sistemas pccr-to-pcc:r, chamadas de emerg~nci:~ de próxima geraç,,o c ferramentas de criaçi\o de serviços. Rccelllemcntc, tamb~m voltamos I)OSSa a tenção aos sistemas sem no VolP. como as rede 802.11 b c 802.11n c talvez as redes WiMnx se lorncm imPQr· tantes tecnologias de líhima milha paro telefonia. Tarn~ m estamos tentando aprimorar a capacidade de os usuários diagnosucarem ralhas nos confusos equipamentos e provedores, usando lllll sistema de diagnóstico de r,\lhas pccr-to-pecr chamado DYSWIS (Do You Sc:c: whatl Sc:e JVoct' vc o q ue cu ''cjo)). Tentamos fazer Lrabalhos relevantes.
bow4tto4ic~ Em sua apiniõo, qual é o futuro da rede multimídia ?

Estamos 11gora em uma fase de transic:'lo: poucos anos nos separam elo IP como plataforma universal para serviços de muhimfdia. do IPTV ao VoiP. Esperamos que o r;ldio, o tcldone c a TV cominuem funcionando mesmo durante tempestades de neve c terremotos; portanto. quando a Internet assumir os paptis dessas redes dedicadas. os usuários podcrtlo esperar o mesmo nível de confiabilidadc. Teremos que aprender a projetar tecnologias de rede em um ecossistema de carreiras concorrentes, provedores de scrvi~·o c contcudo. servindo muitos usuários sem m~inamcnto e ddcndcndo-os de um pequeno. porém destruuvo. punhado de usuários maliciosos c crimmoso. A mudança de l)rotocolos está se tornando difícil. Estão se torna ndo também mais complexas. já que precisam levar em conta os lucros competitivos de negócios. segurança. privacidade c a falta de transpar~ncia das redes, causada por fircwalls c tradutores de endereços de rede. Desde que a rede multlrnfdla se tornou :1 base para todo cntrctcni mcnto ao consumidor, ex1S11r:l un"' cnfasc na administraç:lo de grandes redes. a um preço baixo. Os usuários esperar-l o um uso f:lcil. como ter o mesmo conteúdo em todos seus dispositivos. Por que o SIP tem um futuro promissor?

Enquanto prossegue a evoluç:lo elas redes sem rio existen tes hoje para 3G, h:i a espcran\<1 ele um único mecanismo de si nalizaçllo p:m1 multimidia que abranja todos os tipos ele rede. desde modem a cabo at~ redes tclefOnicas de empresas c redes püblic:;1s sem fio. Junt.uncnte com sofLwMes de n1dio, isso possibiliLará que, no futuro. um disposith•o línico, tal como um telefone Bluctooth sem fio, possa ser utilizado em um:~ rede rcsiclcncial, em uma rede empresarial via 802. 11 c em redes de longa disLfmcia por meio de redes 3G. Mesmo antes de existir tal dispositivo único, uni versal, sem fio, os mecanismos de mobilid~dc pcsso;tl pcrmiLem ocultar as diferenças entre redes. Um ldentíficaclor torna-se o meio universal de alcançar uma pessoa. em vez de ter de lembrar ou ter de passar por meia duzia de números de telefones específicos para tecnologias ou localizações. O SIP tam!Xrn separa o fornecimento de transporte de voz (bit) dos serviços de voz. Agor-a ficou tecnicamente possfvel acabar com o monopólio local de telefonia, no qual uma única empresa fornece transporte neutro de bits enquanto outras fornecem ·o tom de disatr' IP c os serviços dássicos de telefonia, como gatcwa)·s. transfcrtncia de cham;1das c idcntincador de chamadas. Alem da sinalizaç.lo de multimídia, o STP oferece um novo serviço que estava fal tando na Internet: notificação de eventos. Algo parecido com esse serv1ço jâ vem sendo oferecido por soluçóes improvisadas IITTP e por e-mail, mas nunca foi multo satisfatório. Uma \ 'C% que eventos s:lo uma abstração comum para sistemas distriburdos. isso pode sunphficar a construç.lo de no,·os scr"iços. Você pode dor a lgum consel ho a os estudantes que e:stão ingressando no ca mpo do s redes?

O trabalho com redes é quase interdisciplinar. Ele tira subsídios da engenharia e l ~ trica , da ciencia da computaçllo.

dn pesquisa operacional e de outras disciplinas. Assim, os pesquisadores de redes tCm de estar f:unilíarlzados com assuntos que cst:\o fora de suas áreas centrais di! interesse. Já que as redes est:lo se tornando panes tão imp
bow4tto4ic~

Segurança em redes de computadores

N

a Scç;Jo 1.6 descrevemos algumas das categorias mais predomim11Ues c prejudiciais dos ataques na Internet, incluindo at::~qucs malwarc, recusa de serviço, nnalis:tdor de pacote:., disf::~rcc da fonte c modiOcaç-.lo e exclusão de mensagem. Embora tenhamos aprendido multo sobre rede de computadores. ainda não ::~n:tlismnos como protegê-las dos amques descritos na Se<; comunicar, porém 'com ~gurança', mas o que isso slgni nca exatamente? Como veremos, a segurança (assim como o amor) é repleta de maravilhas; isto é, a segurança tem muitas facetas. É ccno qLtc Alice e 13ob gostariam que o conteúdo de sua comunic:~çào permanecesse secreto, a S:ll,,o de um bisbilltoteiro (dígnmos, um marido, ou espos.1, ciumetuo). Prov:~,•clmcntc gostariam tatnbêm de ter certeza ele qLac estão realmente se comunicando um com o outro c de que, caso algum bisbilhoteiro imerfim na comu· nicação, ess:1 intcrfcrencia seja detectada. Na primeira parte deste c:-Jpltulo , estudaremos as técnicas que permitem criptografar/dccriptar comunicações. autenticar a parte com quem estamos nos comunicando e asscgur.u a integridade da mensagem. Na segunda p:artc deste c:-Jpítulo, examiltilrcmos corno os pnncfpaos da criptogmfia podem ser usados parJ criar protocolos de rede seguros. Utilizando mais uma vez uma abordagem top-down, examinaremos os protocolos seguros em cada uma das (quatro principais) camadas, iniciando pela camada de aplicaçào. Verificaremos como proteger o c-mail c uma conexão TCP, como prover segurança total n:1 c:~m:~da de rede, e como proteger uma LAN sem Oo. :-la terceira parte deste capitulo, a\'aliaremos a segurança operacional, que tem o objetivo de proteger redes organizacionais de ataques. Verificaremos, de forma mmucrosa, como os firewalls c os SIStemas de detecção de invasão podem aprimorar a segurança de uma rede organizacional.


8.1

Seguronço em redes de computadores

493

Oque é segurança na rede?

Vamos iniciar nosso estudo de scgur.tnç,\ de redes voltando aos namorados citados no imeio, Alice e Bob, que querem se comumcar 'com segurança'. O que isso stgn illca exatamente? Com certeza, Alice quer que somente Bob entenda a mensagem que ela cn,•iou, mesmo que dcs estejam se comunicando por um meio insc·guro. em que um intruso (Trudy, a intrusa) pode imerceptCSSOa com quem está se comunicando é de fato Bob. Alice c Bob também querem ter certeza de que o conteudo d e suas mensagens não foi alterado em trânsito. Tambem querem. antes de mais nada. ter certeza de que podem se comun icar (is to é, de que ninguém lhes negue acesso aos recursos ncccss~~ r ios para a comu nicaç;\o). Dadas essas considerações, podemos identificar as seguimcs propncdades desejáveis da comunicação segura:

COiiflclrnrialitltulr. Somente o remetente e o destinatário pretendido devem poder entender o conteudo da mensagem transmitida. O fato de abelhudos poderem interceptar a mensagem exige, necessariamente, que esta seja cifrada de alguma manei ra para im,,cdir que umn mensagem interceptada seja cutcndida po r um mtcrccptndor. Esse aspecto de confldcncialidadc ~. provavchncutc, o significado mnis comumeme percebido na expressão comwriu1çt1o srguro. Esltld;uemos técni<:as de criptografia para c1 rrar c decifrar d<~dos na Seção 8.2.

Aulc'llliatetlo cio t>ento fincrl. O remetente e o destirlatário precisam confirmar a Identidade da outra pane envolvida na comunicação- confirmar que a outra p:1rtc rr-o~lmentc t quem alega ser. A comunicação pessoal entre seres humanos resolve facilmente esse problema por reconhecimento visual. Quando cnlid<~des comunicamcs trocam mensagens por um meio pelo qual não podem ''era outra parte, a autenticaç;io n!lo ~assi m t:\o simples. Por que, por exemplo , você deveria acreditar que o c-mall que recebeu e que comém uma sentença afirmando que aquele e-mail veio de um anngo seu realmente veio daquele ::u nigo?

lnt rgritlmlt tle mrnsagl'ln. Mesmo que o remetente e o destinatário consigam se autcmicar reciprocamente, eles também querem assegurar que o comctldo de sua comunicaçM nlo seja alterado , por actdcntc ou por ma mtenção, durante a transmissão. Extensões das técnicas de soma d e vcrillcaçllo que encon tramos em protocolos de transporte c de enlace confiáveis podem ser utilizadas para proporcionar integridade à mens.1gcm. Estudaremos autcntie:t(,.'";\0 do ponto de chegada c integridade da mensagem na Seção 8.3. Srgurtm(CI O/Jé'rtiCional. Hoje quase todas as organizações (empresas. uni versidades etc.) possuem redes conectadas à Internet pública. Ess.1S redes podem ser compromctid:~s potencialmente por atacantes que ganham acesso a e-ssas redes por meio da Internet pública. Os atacantes podem tentar col
mouitomr - idenuficar e gravar as mensagens de controle e de dados no canal; moclificcw, inserir ou eliminar mensagens ou conteúdo de mensagens.


Dados

Dados ..,.~>----..,Mensagens dl! controll! I! dl! dado;.s_ _ _~;-

L

Remetente

~

seguro

Canal

Alice

Bob

Trudy

Figura 8.1 Remetente, desfiootório einhus() (Alice, Sob eTrudy) Como veremos, a menos que sejam tomadas contramedidas adequadas, essas c:~pac icl:~dcs perm item q ue um intruso monte uma grande variedade de atuqucs à scgurançu: monitorar comuniaH,'0Cs (c, possivelmente, ro ubar senhas c dados), razcr-sc pass;lr por o mra entidade. sequestrar um:~ sessão em Cllrso, rccuSJr serviço a usuários legflimos da rede sobrecarregando os recursos do sistcm:'l c assim por diante. O CI!RT Coordination Centcr ICERT, 2009 1 mamém um resumo de ataques comunicados. Veja também ICisco Sccurlty, 2009; Voydock, l983; Bhimani, 1996; Skoudis, 20061. Agora que já temos certeza de que há ameaças reais à solta na Internet, quais S<'o os equivalentes de Alice e Bob na Internet. esses nossos amigos que precisam se comunicar com segurança? Certame me, Bob e Alice podem ser dois usuários humanos em dois sistemas l'inais, por exemplo, uma Alice real c um Bob real que de rmo querem trocar c-ma•ls seguros. Eles podem também ser os panicipan tcs de uma transação ele comércio eletrônico. Por exemplo, um Bob real pode querer rrnnsmitir com ~gm-ança o numero de seu can:'o de crMito a um sel'\•iclor Web parn comprar um produto pela rede. As partes que necessitam ele uma comunicaç;\o segura podem fazer parte de uma mfracstrutura da rede Lembre-se de que o s istema de nomes de dom!mo (DNS. vcp a Seção 2.5) ou daemons roteadores que trocam infonnaçOes de roteamento (veja a Seção 4.6) requerem comunk-açâo segura entre dois partici pantes. O mesmo é válido para aplicações de gerenciamento de rede. um tópico que examinaremos no Capitu lo 9. Um intruso que conseguisse intrr(erir em consultas do DNS (como discutido na Seção 2.5) processamentos de roteamento IMurphy, 2003) ou funções de gerenciamento de rede (RFC 2574) poderia causar uma clc"astaçâo na Internet. Estabelecida a esmuura, apresent:ldas algumas das definições mais importantes e justifia 1da a necessidade de scguran~·a na rede, vamos examinar a criptograOa. Embora a mllizaç.\o da criptografia para prover conl'idcncialidadc seja evidente por si só. veremos em breve que ela tambem é essencial para prover aute nticação, integridade de mensagem, nilo rcpuclinçilo c controle de acesso- o que faz da criptografia uma pcd r.1 fundamentl11 da segurança na rede.

8.2

Princípios decriptografia

Embora a criptografia tenha urna longa história que remoma, no mínimo. a Jlilio César, técnicas modernas de criptografia, incluindo muims das usadas na lmernet, são baseadas em progressos feitos nos liltimos 30 anos. O ll\•ro de Kahn , Tl•r coclrl>rtaltus !Kahn. 19671, c o livro de Singh, Tht Coclc 8ooft; Tht 5(irua of Stcrtcy from i\urielll Egyp110 Qumuum C'YtllograJJhy ISingh. 1999]. nos oferecem um panorama fascmante dessa longa história. Uma discussão completa sobre a criptografia exige um livro mtctro IKaufman, 1995; Schncicr, 19951; portanto. trata remos apenas de seus aspectos essenciais , em particular do modo como as t~cnicas criptográficas são postas em prática na Internet. Obsen 'amos também que, conquan to ncSSJ seção focalizaremos a utilização da cnptografta aplicada à conftclcncialidadc, em breve ve remos que as técnicas criptográficas cst:lo incxtricavelmente entrelaçadas com a autenticação, a integridade de mensagens, a n:lo repudiação e outras.


Segurança em redes de compu tado res

495

T~cnicas

criptográficas permitem que um remetente disfarce os dados de modo que um imruso não consiga obter nenhuma informaç;\o dos dados interceptados. O destinatário. é claro. de,•c estar habilitado a recuperar os dados origmats a parttr dos dados disfarçados. A Figura 8.2 apresenta alguns dos componentes mais importantes da terminologia usada em criptografia. Suponha agora que Alice queira enviar uma mensagem a Bob. A mensagem de Alice em sua forma original (por exemplo, "Sob. I 1ove yoo. A1 i c c·) é conhecida como te.~ to a berto ou texto claro . Ahcc criptografa sua mensagem em texto aberto usando um a lgoritmo de cri ptografia, de modo que a mensagem cnptografada, conhecida como texto cifrad o, pareça ininteligí\'el para qualquer intruso. O interessante é que em muitos sistemas criptográficos modernos. incluindo os usados na Internei. a técnica de codificaç~o ~ (Ouhaidta- publicada, padroniznda c disponwcl para qualquer um (por exemplo. IRFC 1321, RFC 2437, RFC 2420; NIST 200 11), mesmo pam u m intruso em potencial! Evidentemente. se todos conhecem o método para codHicar dados, então deve l1twer alguma informaç:lo secreta q ue impede que um intruso decifre os dados trans mit idos. É aqui que cm ra a chave. Na Figura 8.2, Alice forn ece uma chave, KA, uma cndcla de nfuncros ou de C:lr.lctcrcs, corno e ntrada para o algo ri tmo de c1·iptogra fi a. O :1lgoritmo de criptografia pega essa chave c o texto ubcrt o da mensagem , 111, como entrada c produz texto ci frado corno saída. A not:1ç-ào K,~(m) rdere.sc i\ forma do texto cifrado (criptogmf:tdo usando :1 cllavc KA) da mcns:1gem em texto aberto, m. O í!lgoriuno criptogr:lfico propri
8.2.1

Criptografia de chaves simétricos

Todos os algoritmos cnptográficos envolvem a substitui~'ào de um dado por outro, como tomar um trecho de um texto aberto c cnu\o, calculando e subslitlú ndo ~texto por outro cifrado apropriado, criar uma mensagem cifrada. Antes de estudar um sistema criptográfico moderno baseado em chaves, vamos abordar um algoritmo de chaves simétricas muito antigo, mui to simples, atribuído a jülio César c conhecido como cifr.t d e César ( uma cifra é u m método paro criptogr.~far d:~dos).

T~xto ab~no

Texto ab~rto Te>eto cifrado Algoritmo de Algoritmo de criptografia 1---=----~ decriptaçao

'f

Alice

Legenda: . . . . . cNYt

Figura 8.2 Componentes criptogróficos

~

Trudy

Canal

Sob

___J


A cifm de Cés.1r funciona tomando cada letra da mensagem do texto aberro c substituindo-a pela k-ésima letra sucess1va do alfabeto (pernutindo a rotatividade do alfabeto, ISto é, a letra 'f seria seguida no,rarncntc da letra •a'). Por exemplo. se h = 3, então a letra ·a· do texto aberto fica sendo 'd' no texto cifrado; 'b' no texto abcrro se transforma em 'c' no texto cifrado, c assim por diante. 'esse caso, o '';dor de h serve de ch:we. Por exemplo, a mensagem "bob . I 1 ove you. a li ce.· se toma ·ere. l oryh brx. do lfh. · em texto cifrado. Embora o texto c1frado na verdade pareça não ter nc.~o. voe~ não levada muito tempo para quebrar o código se soubesse que foi usada a cifrn de César. pois há somente 25 valores possrveis paro1 as chaves. Um apnmoramento da cifra de César é a cifra monoalfabêtka. que tr~mbém substitui uma letra do alfabeto por outra. Contudo. em vez de substituir as letras seguindo um padnlo regular (por exemplo. substituiç:lo por um desloc:uncnto de li para todas as letras), qualquer letra pode ser substitufda por qualquer outra. comamo que cad:l letra tenha uma unlca letra substituta c viCC·\'Crsa. A regra de substhuiÇ'àO :~presentada na Figura 8.3 mostra uma rcgm possfvcl para codificar textos abertos. mensagem do texto aberto "bob , I 1ove you . a 1f c e. • se torna "nkn. s gk te wky. mgs bc." Assim, como aconteceu no caso da cifra de César, o texto p.1rcce sem nexo. A cifrn monoalfabética uunbém p:m~ccscr melhor que a cifra de Césttr, pois há 26! (da ordem de lQU.) possíveis p
Unm abordagem de forca bruta que cxpcrimcnta.~e todos os l Oj(> pares possíveis demandaria um esforço dcmasiad:uncme grande c impedirin que esse fosse um método viável para quchrar o algoritmo crlp10gr:lfico c decodificar a mensagem. Contudo. pela 31\:Uisc esu1lfsuca da linguagem do texto aberto. por exemplo. c sabendo que as lcuas 'c' e 't' são as mais frcqucmcs em textos em íngl~ (13 por cento c 9 por cento das ocorr~ncias de letras, respectivamente) c sabendo também que determinados grupos de duas e de três lctr.IS npareccm com bastante frcquCncia em ingles (por exemplo, 'in', 'il', 'lhe', 'ion', 'ing', c assim por diante), toma-se rclativameme fácil quebrar esse código. ~o intruso tiver algum conhecimento sobre o possível texto da mensagem, ent.\o ll~r:l mais fácil ainda quc:brnr o código. Por exemplo, se a mtrusa Trudy for a esposa de Bob c suspeitar que ele está tendo um caso com Alice, ela poderá facilmente 1maginar que os nome> 'bob' e 'alice· apareçam no texto.~ Trudy tivesse certeza de que esses dois nomes :~parecem no texto cifmdo e uvcsse uma cópia do texto cifrndo da mensagem do exemplo, entao ela podena dctcnmnar ímcdiat:Jmcme sete dos 26 pares de letras, o que resultaria em lO" possibilidades :1 menos para verificar pelo m~todo da força bnua. Na verdade, se Trud>• suspeitasse que Bob estava tendo um C'.ISO, ela poderia muito bem espcmr cncontr:tr algumas outr:IS palavras preferenciais no texto também. Ir~

Constder:tndo como seria fácil para Trudy qucbmr o código crlptogr:lfko de Bob e Ahce. podemos distinguir cenários diferentes. dependendo do tipo de informação que o intruso tem: Atcrcruc· rxdu~ivo

trxto cifrado. Em alguns casos, o intruso pode ter acesso somente ao texto cifrado interceptado, sem ter nenhuma informaç-.lo exata sobre o comcúdo do texto aberto. Já "1mos corno a an:ilise estatlstka pode ajud:1r o ataqtte. exclttSivo ao texto cirrado em um esquema criptográfico. 11

Altl(fHI' com texto clbcrro ronltcciclo. Vimos anteriormente que, se Trudy. por alguma r;tzào, tivesse certeza

de que 'bob' c •a 11 c e· apareciam no texto cifrado, ela poderia clcLcrminar os pares (texto cifrado, wxto aberto) para as letras a, I.!, c, c, b c o. Trudy poderia t:lmbtm ser multo sortuda c ter gr.waclo tod:ts as tmnsmissOcs de texto cifrado c dcs<:oberto urna versão decifrada pelo j>róprio Bob escrita em um pedaço de papel. Quando um intruso conhece alguns dos pares (texto >tbcrto, texto cifrado), referimo-nos a isso como awque ao esquema criptográfico a partir de texto aberto conhecido. Atacrur com texto aberto escolhido. Nesse tipo de ataque, o intruso pode escolher a mensagem em texto abcrro c obter seu texto cifrado correspondente. Para os algoritmos criptográficos simples que vimos at~ nqui, se Trud)' conseguisse que Alice cm•iassc :~ mensagem "The qui ck fox jumps over the Letra no texto aberto: a b c d c f g h j k 1 11 n o p q r s t u v w x y z Letra no texto cifrado: m n b v c x z a s d f g h j lt 1 p o 1 u y t r e w q

Figura 8.3 Umo cifro monoolfobético


Seguronço em redes de compu tadores

497

1azy brown dog~, ela poderia decifrar completameme o esquema crlplogr:\Oco. Veremos em breve que, para 1écnicas de criptografia mais sofisticadas, um ataque com um texto aberto escolhido não significa necess:ui:unente que a técnica criptográfica possa ser dedfrada. Quinhentos anos atrás foram inventadas técnicas que aprimoraVõlm a cifra monoalfabéuca, conhecidas como cifras polialfabéticas. A ideia subjacente à criptografia polialfabêtica é usar várias cifras monoalfabéticas com uma cifra monoalfabé1ica especifica para codificar uma letra em uma postç.'lo especifica no ICXIO aberto da mensagem. Assm1, a mesma lctra, quando aparece em posições diferemcs no tex1o aberto da mensagem, pode ser codificada de maneira diferente. Um exemplo de esquema criptográfico polialfabé1ico é mos1rado na Figura 8.4, na qual há duas cifras de asa r (com h = 5 c l1 1Q), que aparecem nas linhas da figura. Podemos Oplar pelo uso dcss.1S duas cifras de César, c, c cl' seguindo o modelo de repclição c., Cl, cl. c., c~. Isto é, a primeira lcu·a do ICXtO deve ser dfrada usando-se C 1, a segunda e a terceira, Cl , a quarta. C , e a quinta, C1• O modelo, en1ão, se repete, com a sexta letra sendo dfrada usando-se C 1; a s~tim:t, com CJ. c assim por diante. Dessa m:meir-.t, a mensagem em texto ubcrto ~bob . I 1ove yoo . " é cifr.tda como "giiU . n e t ox dh z . ~. Note que o primeiro 'b' da mens.1gem em 1exto aberto é cifrado usando-se C,. ao passo que o segundo 'b' é dfrado usando-se c,. Nesse exemplo, a 'chave' da codlricaç:1o c d~ dccod ifka~·ào ~o COilhcdmento dns duas cifras de C~sar (I( ::: S. 11 ::: 19) c do modelo c,. c~.

=

cl. c,. c•.

Cifras de bloco Vamos agora nos direcionar a tempos modernos c analisar t·omo a criptogmfia de ch:we simétnca é feita atualmente. Existem duas classes amplas de técnicas de criptograna simétrica: cifms de nuxo e cifra~ de bloco. Exami naremos as cifras de Ouxo, de forma breve, na Seção 8.7 ao invt'stigarmos a segurança p:un LANs sem fio. Nesta seçuo, focaremos em cifms de bloco, que s;lo utiliudas em muitos protocolos seguros da Internet, inclumdo PGP ( para e-mail seguro), SSL (para conexc>es TCP seguras) c lpscc (para pr01eg!!r o transporte da camada de rede). Na cifra de bloco. a mensagem a ser crip tografada é processada em blocos de k bits. Por exemplo. se 1: - 64, então a mensagem é di\•idida em blocos de 64 bits, e cada bloco é enptografado de maneira independente. Para cnptografar um bloco, a cifra utiliza um mapeamento um para um para mapear o bloco de h bits de ltxto aberro para um bloco de k b•ts de texto cifrado. Vamos examinar um exemplo. Suponha que k • 3, de modo que a cifra de bloco mapeie entradas de 3 bits (texto abnto) para saídas de 3 bits (trxto cifrado) . Um possível mapeamemo é determinado na Tabela 8.1. Observe que esse e um mape:unento um para um; ou SeJa, há uma saída diferente para cada en1rada. Essa cifra de bloco divide a mensagem em blocos de até 3 bits c criptografa cada bloco de acordo com o mapc:unento acima. Vocc deve verificar que a mensagem 010 llOOOilll é cripto· grafada para 1010001 11001. Aind:t no exemplo do bloco de 3 bits. obsen•c que o mapeamento nr~ Tabel:l 8 .1 é um de muitos possíveis mapcmncntos. Q u:mtos possíveis mapeamentos existem? Par-.1 responder a essa qucsulo, obs~rvc que um mapeamento nilo é nada mais do que uma pcrmutaçi\o de todas as possíveis entradas. Existem 2' (• 8 ) possfveis elllradas (l"clacio n01das nas colunas de entmcla). Essas oito entr.tdas poclern ser permutadas em 8! .. 40.320 fornms diferentes. Uma vez que cada uma dcss.1S permutações especifique um mapcamenlo, há 40.320 mapeamentos possíveis. Podemos ver cada um dcs.<;es mapcruncnLos como uma chave- se Alice c Bob sabem o mapeamento (a cha,•e), eles podem criptogr.tfar e dccriptografar as mensagens enviadas entre ele!>. O ataque de força bruta para essa cifra é tentar dccrip1ografar o ttxlo cifrado us.mdo todos os ma peamentos. Com apenas 40.320 mapeamentos (quando k • 3), isso pode ser rapid:unente realizado em um computador de mcs:l. Para Impedir os maques de força bruta, as cifms de bloco normalmente usam blocos muno maiores. consísLetra do texto abeno: a b c d e f g h i j k 1 • n o p q r s t u v w x y z C1(k = 5): f g h f j k 1 11 n o p q r s t u v w x y z • b c d e C2Ck • 19): t u v w x y z a b c d e f g h i j k 1 ., n o p q r s

Figura 8.4 Umo cifro poliolfobé~co que u~lizo duos cifros de Césor

bow4tto4ic~ Redes de compu tadores e o Internet

Entrada 000

001 010 011

Saída

Entroda

Saído

110 111 101 100

100 101 110 111

011 010 000

001

Tabela 8.1 Requisitos de o~icoções de 1ede selecionados undo em k • ó4 bits ou ainda maior. Observe que o mimero de mapeamentos posslvcrs para uma cifra de bloco h geral é 2k' , o qual é extraordinário para :ué mesmo valores moderados de !1 (como l1 • 64). Embora as cifras ele bloco ela tabela completa, <.-omo elcscrllas, com valores moderados de lz possam produzir esquemas robustos de criptografia de chave sim~trica, eles infelizmente s~o diffeeis de implementar. Para l1 =64 c para um determinado mapeamento, Alice e Bob precisariam mamcr uma tabela com 2M valores de cmrada, uma tarefa impraticlvel. 1\l<:m disso, se Alice c Bob quiserem trocar chaves, cada um teria <:o de 64 bits em 8 bloços. com cada bloco consistindo de 8 bits. Cada bl<><:o de 8 bits é pr<><:cssado por uma tabda de 8 bits para 8 bits, {I qual possui um tamanho comrolável. Por exemplo, o primeiro bloco é processado pela tabela denotada por T'. Em seguida, os ono blocos de salda são reunidos em um bl<><:o de 64 bits. As posições dos 64 bits no bloco são, então, pt.'rrmuadas para produzir uma S.'llda de 64 bits. Essa salda é devoh'ida à entrada de M bits, onde se inicia outro ciclo. Após n ciclos, a funç-Jo aprcsema um bloco de 64 brts de texto cifrado. O objetivo de cada ciclo é fazer com que cada bit de entrada afete a maioria (se não todos) dos bits finais de s:~lda . (Se somente um ciclo fosse usado, um deu:nninado bll de entrada afetaria somente 8 dos 64 bits de salda.) A chave para esse algoritmo das cifras de bloco seria ~\S oito tabelas de permutat.'ào (admitindo que a fun ç-.lo de permutaç-Jo seja publícamcntc conhecida). Hoje. cxrstcm drvcrsas crfroiS de bloco conhecidas. inclumdo DES (abrcvmç-Jo de Daw Encryr,tion Stonclurcl IPmlrclo ck Criptogwjlcl ck Dculosl), 3DES e AES (abrcviaç:lo de Aclvaucccl Euayption Stauclarc/ IPculrclo ele Críptogmfla AwwçculaJ). Cada um desses padrões utiliza funções em vez de t<1bclns prcdctcnninndas, segundo a

) I

\

I

ls ~ts I lsbt l l a ~ts I Loop paran

ciclos

I

Entrada de 64 bits

r-1,

la ~its I

0) C0 @ ®

l a bits I

0

~ @

" l s ~its I Js ~its I

0 C9

Js bits I Ja bits I l a bits I Js bits I Jsbrts I Jabits I l a bits I Js bits I Codificador de 64

~/ Figura 8.S Exemplo de umo cifro de bloco

biu

~

Saida de 64 bits "

•

~\

•

I



499

Figura 8.5 (embora mais complexa c cspedfica para cada cifra). ú da um desses algorhmos tambt'!m utlllza uma cadeia de bits parn chave. Por exemplo, o DES us.'\ blocos de 64 bits com uma chave de 56 bits. O AES US.'\ blocos de 128 bits c pode opernr com chaves de 128, 192 e 256 bits de comprimento. Urna chtwc do algoritmo dctemlina os mapeamemos da ~minitabela" c permutações dentro do algoritmo. O ataque de for~-a bruta parn cada uma dessas ctfras t percorrer todas as chaves, aplicando o algontmo de decnptogrnria com cada chave. Observe que com o comprimento de chave n, hd 2• chaves possfvcis. NIST I 11ST. 20011 estima que uma máquina que pudesse decifrar um DESde 56 bits em um segundo (ou seja, testar 2"' chaves em um segundo) levaria, aproximadamente, 149 trilhões de anos parn dccifrnr u ma chave AES de 128 bits.

Encadeamento de blocos de cifras Em aplicações de redes de computadores, normalmente precisamos criptografar mensagens longas (ou nuxos de dados longos). Se aplicarmos Lima cifra de bloco, corno descrim, simplesmente pani ndo a mens.'lgcm em blocos de h bits c crilltografando, Independentemente. cada bloco, um problema sutil , mas imponante ocorrerá. Para entcnd~- l o, note que dois ou mais blocos de LC.'< LO abcno podem ser idtnticos. Por exemplo, o tex to aberto em dois ou mais blocos poderia ser ~HTIP/l.l ~. Em rcla\·lo ''esses bloí.'OS idt nticos, um:1 cifrn de bloco produziria, c claro, o mesmo texto cifrado. Um atacmuc poderia eventualmente adivinhar o texto aberto 1 - 1 ®O = l. e o XOR das du:1s cadeias de bits é feito em urna base de bit por bit. En H\o. por exemplo, 10101010 e 11110000 = 01011010.) Ademais, denote o algoritmo de criptografia da cifra de bloco com a chave S como K,. Eis a idcia basica. O emissor cria um m\mero aleatório r(i) de k bits par'll o i-ésimo bloco c calcula c(í) ., K, ( m(i) ® r(i)). Observe que um novo numero aleatório de 1: bits é escolhido para cada bloco. O emissor envia, então. c(l), r(l), c(2). r(2), c(3). r(3). etc. Visto que o receptor recebe c(i) c r(i), ele pode recupcrnr cada bloco de texto aberto computando rn(i) • K5 (c(t)) + r(t). É tmportantc observar que, cmbofll r (i) seja em•tado Inocentemente c. portanto. pode ser anahsada por Trudy, ela não pode obter blocos de texto aberto m(i). uma vez que ela não conhece a chave Ks. Observe ta mbém que se dois blocos de texto aberto m( i) c rn (j) silo iguais, os blocos de texto cifrado correspondentes c(i) c c(j) serão diferentes (contanto que os nümeros r (l) c r(j) aleatórios sejam diferentes, o que ::.contcce com urna ::.ha probabilidade). Como um exemplo, considere a cifra de bloco de 3 bits na Tabela 8.1. Suponha que o texto nberto seja 010010010.

Se Alice c:riptografá-lo diretamente, sem incluir a aleatoriedade, o texto cifmdo resultante se torna l O1101 LO I. Se Trucl)' analisar~ texto clfmdo, por cada uma das tr~s cifras de blocos ser igual, cl:1 pode pensar que cada um dos bloeos de tex•o aberto s:lo iguais. Agom suponha que em vez disso Alice cria blocos alea tórios r( I) • 00 1, r (2) • 111. c 1'(3) • 100 c use a técnka acima pam criar o texto cifrado c(l) .. 100, c(2) • OLO c c:(J) • 000. Observe que os lr~ blocos de texto cifrado são diferentes mesmo se os blocos de texto aberto são iguais. Alice cnt;\o envia c(l), r(l), c(2) c r(2). Voe~ de,•c venftcar que Bob pode obter o texto aberto original usando a chave K~ comp<~rtilhada.

O leitor pcrspic:1z observará que Introduzir a aleatoriedade resolve o problema, mas cria outro: ou seja, Alice de"e tmnsmitir duas ''czcs mats bits que antes. Realmente, parn cada bit de cifrn, ela dc,•c agora cn\'iar um bit aleatório. dobrnndo a largura de banda requirida. Para obten11os o melhor dos d01s mundos. as cifms de bloco normalmente us.1m uma tt'!cnica chamada Encadeamento do Bloco de Cifrn (CBC). A idcia básica é enviar somente 11m Htlor trlrtllór ro JIIIIIO com 11 ,,..,ntirtr mensagem c. cnlllo,Jazcr com Co C'lltrssor r o rCCC:f'IOr rrscm blocos codíjicaclos em vt·~ elo mimcro cdrtllório subscqucnlr. O CBC opcrn, como segue:

'f"

I. Antes de cnptografar a mei\S3gem (ou o nu:
em lCXlO abcno.


2. Em rclaç-lo ao primeiro bloco, o cmíssor calcula rn( I) + c( O), ou seja, calcula o ou-exclusivo do primcíro bloco de texto aberto com o IV. Ele então codilica o resuhado através do algontmo de crfra de bloco para obter o bloco de texto cifrado correspondente; ou seja c(l)" K,(m(l ) 9 c(O)). O emissor envia o bloco criptografado r (l) ao receptor. 3. Para o i-tsuno bloco. o emissor nia o i-ésimo bloco de texto cifrado de c(l) • K~ (m(i) ® c(i- J)). Vamos agora examinar algumas das conscquencias desta abordagem. Primeiro, o receptor ainda scr:l capaz de recuperar a men~tgem onginal. Rcalmem e. qu
O CBC possu i unm conscqu~ncia importante ao para os protocolos de rede seguros: precisaremos rornccer u m mecanismo dentro do protocolo para distribuir o IV do emissor ao recepwr. Veremos como isso é fei to para ''0\rios pro tocolos mais adiante, neste caprtulo.

8.2.2 Criptografia de chove público Por mais de dois mil :mos (desde a época da cirra de Cés.1r :né a década de 1970). a comunicaç.lo cifrada cxrgm que as duas partes comunican tes compa rtilhassem um segredo em comum- a cha,·c simétrica usada paro cifrar c dccirrar. Uma dificuldade dessa abordagem é que as duas panes têm de concordar, de alguma mant'ira, com a chave comparulhada, mas. para raz~·lo, é precrso comunrcaç-;ro (prcsumrvelmcnte segura)! Talvez as partes pudessem se encontrar allles, escolher a chave pessoalmente (por exemplo, dois dos centuriões de César poderiam se encontrar nos banhos romanos) c. m:lis tarde, se comunic;,r de modo eirrado. Em um mundo em rede, contudo, o m:us provável é que as partes com unicantes nunca possam se encontrar c jamais possmn convers:tr a nào ser pela rede. É possJVel que elas se comuniquem por criptografia sem comp:milhar um:~ chave comum secreta co nhecida com an tcccdencia? Em 1976. Diffic c Hellman IDiffie, 1976] apresentaram um algori tmo (conhecido como Troca de Chaves Diffic llcll man- Diffie. Hdlman Kcy Exc hangc) que raz exatamente isso- uma :~bo rdagcm da comun icação segura rnclic


501

- - - - - - - - - - ()-- K1' Chave criptográfica pública ~ €)-o

I

Mensagem em texto aberto, m

L

Ki Chave uiptográfica privada Mensagem em texto aberto, m

...11!!-~------,Texto cifrado

Algoritmo de

KIJ· (m)

Algoritmo de

criptografia 1 - - - - ---1 de
m • Ki(K, ·(m))

Figuro 8.6 Criptogrof10 de chaves públicos Em scgu id:~, ela criptogmra sua mensagem, m, us.1ndo a chave ptl blkn d e Bob c um algoriuno criptogronco conhecido ( por exemplo, p
RSA Embora cxi tam muitos algoritmos c cha"es que t.mtam dess

então, por exemplo, L9 mod 5 • -1. Na aritmética modular. uma pessoa executa as operações comuns de adiç-lo. multiplicaç.'o e exponcnciação. Entretanto, o resultado de cada operação é substitufdo pelo resto inteiro que sobra quando o resultado é dividido por 11. A adição e a mu híplicaç-.lo l'Om a aritméuca modular s:iO facilitadas com as seguintes propncd:~des úteis: I(a mod 11) + (b 111oc/ 11) I mod n • (a + b) mod n 11 ,

I(
l{cr mod 11) • (b IIIOCIH)I mod 11 • (cr • b) mod rt Segue da tcrcctra propriedade que (a mod n)J mod n • :ri mod 11, uma idcnudaclc que em bn:vc acharemos muito útil. Agora s uponha que Alice queira enviar a Bob uma mensagem criptografada por meio do RSA, conforme ílustrado na Figura 8.6. Em nossa discussão sobre o RSA, vamos sempre manter em mente que uma mensagem não é nada mais do que um pndn\o de bit, c cada padn\o de bit pode ser rcprcsentudo uni<."amentc por um número inteiro (junto com o comprimento do pudnio de bii.S). Por exemplo, suponha que uma mensagem tenha o padri\o de bit 1001; essa mensagem pode ser representada pelo nlimero Inteiro deci mal 9. Assim, crlptografnr uma mensagem com RSA é equivalente a criptografar um nümero imeiro que representa a mensagem. Existem dois c:o111poncntes inter-relacionados do RSi\: A escolha da chave pública e da chave privada. O algoritmo de criptogmfi:Vdeeriptn.çilo. Para escolher as chaves públíca c privada, Bob deve executar as seguintes etapas: 1. Escolher dois números primos gr.mdes. p e q. Que ordem de grandeza devem ter p c ct? Qu:~mo m:~io rcs os '"'lorcs, mais diftcil se,r;\ quebrar o RSA. mas mais tempo se levará para realizar a codificação c a decodificação. O RSA Laboratorics recomenda que o produto de I' c 'I seja da ordem de 1.02-1 bits. Para uma dtscuSS<\o sobre como achar números primos grandes, consulte IC:Ildwell, 20071 . 2. Computar 11 = JX/ c :: = (p - l )(q - 1). 3. Escolher um m\mcro c menor do que n que não tenha fatores comuns (exceto o 1) com t. (Nesse caso, dizemos que t c z s!lo nu meros primos entre si.) t\ letra ·c' é usada j:l que esse v>~lor será utilizado na cnptografia ('cncrypuon', em mgl~). 4. Achar um número d, tal que ecl - I seja di\isi,·cl exatamente (isto é, m\o h3Ja resto na di\isâo) por:<. A letra 'd' é usada porque seu valor será utilizado na decriptac,~\o. Em outras palavras, dado e, escolhemos d tal que ('(/ mod z • 1 5. A chave ptiblica que Sob poc i\ disposiç.lo de todos. K:. é o par de mimcros (11,c); sua chave privadil, K~ é o par de numcros (u, d). A criptografia feita por Alice e a decriptaç-Jo feita por Bob acontecem como segue: Supo11ha que Alice qucim enviar a Bob um padrão de bii.S, ou tHímero 111, tal que 111 < 11. Para codifi{1lr, Alice <."alcula a pot~nc:ia m' c, então, determina o resto inteiro ch1 di,•is.'\o de m' por 11. Assim, o valor cifmdo, c, cl:1 mensagem em texto aberto de Alice, 111 , é: c = m' mod 11. O padr:lo de bit correspondente a esse texto cifrado c é enviado a Bob. Pam decifrar a mensagem em texto cifrado recebida, c. Bob processa m = cJ mod n. que exige o uso de sua chave secreta (n, lO. Como exemplo simples de RSA, suponha que Sob escolha p = 5 c q = 7. (Admtumos que esses valores são muito pequenos para ser seguros.) Então, 11 = 35 e t = 24. Sob escolhe r = 5, já que 5 c H não t~m fatores comuns. Por fim, ele escolhe d = 29, j:t que 5 · 29 - 1 (isto é, cd - 1) é div1s1vel exatamente por 24. Ele divulga os dois valores, n = 35 c e = 5, c mantém em segredo o valor c/ = 29. Observando esses dois valores públicos,

bow4tto4ic~ Seguronço em redes de computadores

Capitulo 8

503

suponha que Alice queira agora enviar as letras ·t·. 'o', V c 'c' a Bob. lmcrprcuutdo cada letra como um número entre I c: 26 (com ·a· sendo I e ·z' sendo 26). Alice c Bob re:tliz:un a criptografia c: a dccriptac;'o mostradas nas tabelas 8.2 e 8.3, rcspc:ctlvamc:me. Observe que neste exemplo. constderamos cada uma das quatro letras como uma mensagem distinl:l. Um exemplo mais realista seria concrtcr as quatro letras em suas representações ASCII de 8 btlS e então codtficar o número inteiro correspondente ao padrão de bit de 32 bitS resultante. (Esse exemplo realista cria numeros muito longos para publicar neste 11\'To!) Dado que o exemplo fictício das tabelas 8.2 e 8.3 já produziu alguns numeros extremamente grandes e visto que sabemos. porque vimos anteriormente. qttc p c q devem ter, cada um, algumas centenas de bíLS de comprimento, \'árias questões pr.\ticas nos v~m à mente no caso do RSA. Como escolher nu meros primos grandes? Como escolher c c d? Como e~lc ular cxpontncíais de mimeros grandes? A discuss
Chave de sessão Observamos aqui que a cxponcnciação exigida pelo RSA é um processo que consome tempo considerável. O DES. ao contr~r i o, é, no mínimo, cem vezes mais \'Cioz em software c entre mil c dez mil vezes mais veloz em hardware [RSA Fast, 2004] . Como resultado, o RSA é frequcntememc usado na prática em combin:tçt'o corn a cri!>tografia de chave shn ~trka . Por exemplo, se Alice quer enviar n Ik>b uma grande quantidade de dados cifrados a alta velocidade, ela pode fazer o seguinte. Primeiramente ela escolhe uma cha ve que será utilizada para codifica r os dados em si: essa chave às vezes é denominada chave de MSsào, reprcscntad:l por K,. Alice dtve Informar a Bob essa dta''e de sessão, já que essa é a eh3ve simétrica compartilhada que eles usarJo com uma cifra de chave simétric:t (por exemplo, DES ou AES). Alice criptografa o "a1or da chave de ~o usando :1 ch:1vc püblic:~ RSA de Bob. isto é . ela processa c = (K,)' mod 11. Bob recebe a chave de sessão codificada RSA. c, c a decifra para obter a chave de scss:\o K,. Ele a.gora conhece a chave que Alice usar.l para transferir dados cifrados em DES.

Por que o RSA funciono? A eriptograrialdecriptaç-Jo do RSA parece mágiet. Por que será que. aplie~ndo o algoritmo de criptografia c. em segutda. o algoritmo de dccripl;lç.lo. podemos recuperar a mensagem original? P:tra entender por que o RSA funciona. tome novamente n = pq, onde p c q são os mímeros primos grandes usados no algoritmo RSA. Lembre-se dt que na criptografia RSA uma mensagem (representada por um número tnteiro) m é primeiramente elevada , potcncia c usando-se aritmética de módulo 11, ou seja. C" m' mod n A clcaipt:tção é feita clevando·sc esse ,·ator à potencia cl, novamente us:mdo a aritmética de módulo 11. O resultado de uma etapa de cnptografia, seguida de uma etapa de dccriptação. é cnt:'lo (m' mod 11)~ mod 11 . Vamos ver agora o que podemos dizer sobre essa quantidade. Como mencionado nnterionnentc, uma propriedade impor· lanle da aritmética rnodulnr é ( 11 mod u}" rnod 11 "aJ mod 11 para quaisquer v:tlorcs a, 11 c d. Deste modo. usa ndo
=

m• 248832 759375 5153632

Texto dfraclo c= m• mod n

v

m: representosão Mméfi
e

s

3125

10

Letra elo texto aberto

o

Tabela 8.2 Criptografia RSA poroAlice: e= 5, n= 35

17 15 22


Texto dfrado c

c'

m= c1 mod n

Letra do texto aberto

17 15 22 10

4819&85721067509150915091411825223071&97 12783403940394885893911 1232757568359375 8S164331908653770195&194499721106030S92 100000000000000000

12 15 22

o

s

e

Tabela 8.3

Oeaip~õo RSA poro Bob: d

y

=29, n=35

Portanto, falta mostrar que m"' mod n • rn. Embora estejamos tentando eliminar um pouco da mágica do mod o de funciO namento do RSA, para explicá-lo, precisa remos usar. aqui, ou tro resu ltado bastante mágico da teoria dos mirncros. Espccinc:uncntc, precisamos do resultado que diga que. se p c tj fore m primos. n = IX/· c z"' (p - l ) (q - 1) , cnt:'\o X' mod n será o mesmo que .01 ..."~~•> mod n !Kaufman, 19951. Aplicando esse resultado com x. m c y • rti, temos Mas lembre-se de que t>scolhcmos ~ c d tais que ccl mocl z - l. Isso nos d:\

m"' mod 11 = m' mod 11 = m, que é exata mente o resulwdo que espen\varnos! Efetuando primeir.m1cntc a cx poncnci;tç-Jo da pot ~ncia e (isto é, criptografand o) c depois a cxponcnciaçâo da potência c/ (isto é. dccriptando). obtemos o valor originalm. E mais not:lvcl ainda é o fato de que, se primeiramente ele\'3rmos à potancl:l cl c, em seguida, :\ pot~ncia e. isto é. se invertermos a ordem da criptogrnfia e da decriptaç-Jo. realizando in icmlmcnte a opcraÇt\o de dccriptaç-lo c. em seguida, aplicando a opcraç;'o de criptografia. também obteremos o '-:tlor original rn. Esse resultado cxtrnordinã· rio resulta imediatamente da aritmética modular:

(m4 moc/11)' mO
8.3 Integridade de mensagem e autenticação do ponto final N:1 seçl\o amerior, vimos como'' criptogr•lfia pode ser ltSacla para oferecer sigilo a d uas entidades em comunicaç:'\o. Nesta seção, nos volmmos ao assunto igt.almentc importante da criptografia qu e é provi! r integridade da mensagem (também co nhecida como alllemic:tçào da mensagem). Além da integridade da mcns:tgcm, discutiremos dois ô\ssuntos an:\logos nesta scÇt\o: assinaturas digitais e autcmic.·w;lo elo pomo final. Defin imos o problema de integridade da mensagem usando, mais uma vez. Alice c Bob. Suponha que Bob receba uma mensagem (que pode ser cifrada ou estar em texto aberto) acred itando que ela ten hô\ sido enviada por Alice. Para alllcmicar a mensagem, Bob precisa verificar se: I . A mensagem foi, realmcmc. enviada por Alice. 2. A mensagem não foi alterada a caminho de Bob. Veremos nas Seções 8.4 a 8;7 que esse problema de integridade da mensagem é uma preocupação importante em todos os protocolos de rede segmos.



sos

Como um exemplo específico, cons idere uma rede de computadores que está utilizando um algoritmo de roteamento de estado de enlace (como OSPF) para determinar rotas entre c-.•da dupla de roteadores na rede (\·eja Capitulo 4). Em um algoritmo de estado de enlace. cada roteador precisa transmitir uma mensagem de estado de enlace a todos os outros roteadores na rede. Uma mensagem de estado de enlace do rote;~dor inclui uma rel:~çilo de seus vizinhos diretamente conectados c os custos diretos a eles. Uma vez que o roteador recebe mensagens de estado de enlace de todos os outros roteadores, ele pode criar um mapa completo da rede. executar seu algoriuno de roteamento de menor custo e configurar sua lllbela de repasse. Um ataque rclauvamentc fácil no algoritmo de rotta.mento é Trud)• distribuir mensagens de estado de enlace fals..'\S com lnforma(Ocs Incorretas sobre o estado de enlace. Assim. a necessidade de integridade da mensagem - quando o roteador 8 recebe uma mensagem de estado de enlace do roteador A. esse deve verificar que o roteador A na verdade criou a mensagem c que ninguém alterou a mcns.1gem em transito. Nesta sc~;
8.3.1

Funções de hosh
Como mostrndo na Figurn 8. 7, u funç-
Em termo de processamento, é impratic:h•cl encontrar duas mensagens dircrcmc x r y tal que H(x) • lf(y).

lnformnlmcntc, essa propriedade significa que, em Lermos de processamento. ~ impr:uicável que um ill\'asor s ubsmua uma mensagem por outrn que csui pr01egida pela runç.lo hash. Ou sep, se (m, H(m)) é a mensagem e o hash da mcnsugem criada pelo emissor, então um invasor não pode rorjar os coru eudos de out ra mensagem, y, que possui o mesmo valor de hash que a mensagem original. E: bom nos convencermos de que uma simples soma de verif'i caç;lo. como a da Internet, daria um péssimo algoritmo de resumo de mensagem. Em vez de processar a arnmética de complemcmo de 1 (como é feito para a soma de vcrifica~;<1o da Internet), vamos efetuar uma soma de verificaç-.\o trmando cada carnctcrc como um bytc e somando os bytcs usando porções de 4 b)rtes por vez. Suponha que Bob deva a Alice l00.99 dólares e lhe envie um \J;~Ie contendo a sentença encadeada 'I OU 100.99BOB.' (IOU- I Owe Vou - Eu lhe devo.) A representação ASCII (em nota~;
Resumo de mc ns.1gem de tamanho f i,.o: H(m)

Cara Aloc:l!: Essa c.1t W ~ MUrt0 long.l. poos tt!nho muoto a do2~1.. .

Funçao de hash muit os·para· um

Figura 8.7 Funções de Hosh

Opgmdvboijrtnsd gghPPdogm;I(Vkb


Represenraç:lo ASCII

MenS~gcm

I O U 1 9 9 8 o 8

oo .

49 30 39

4F 30 42

ss 4F

31 39 42

82

Cl

02

AC

2E

Soma de ' 'erificaçlo

R.-prcsçmaçlo

Mensagem I OU 9

oo •

1

9 8 O B

ASCII 49 30 39

4F

55

30 42

2E

39

31

4F

42

82

Cl

02

AC

Soma de verificação

figura 8.8 Mensagem inicial e mensagem houduleoto têm omesmo somo de verffico~õol Figura 8.8. 1\s mcns:1gcns 'IOU100.99BOB' e ' JOU900.l9BOB' têm a mesma soma de ' 'crificaçl\o. 1\ssim, es.o;e a lgoritmo simples viola as duas exigênci:~s citadas anteriom1e111e. Fornecidos os dados origi nais, é simples descobri r outro conjunto de dados com a mesma sorna d e vcrillc:!Ç'àO. t: claro que, para deito de scgunw ça. prcds:uemos de uma furw:lo de hash muito m;~is poderosa do que uma soma de vcrilkaç;lo. O algori tmo de hash MOS de Ron Ri"cst IRFC 1321 I é amplamen te usado hoje. Ele proccss:\ um resumo de mensagem de 128 bits por meio de \Hn processo de quatro etapas. constituído de uma etapa de enchimento (adiç-.lo de um ·um' seguido de 'zeros' suficientes. de modo que o comprimento da mensagem satisfa\·a determinadas condições). uma etapa de ancxaç.lo (anexação de uma reprcsemaçlo de b'l bits do comprimcmo da mensagem ames do enchimento), uma e ta pa de inicialização de um acumulador c uma etapa final uerativa, na qual os blocos de 16 palavras da mensagem s:\o processados ( misturados) em quatro rodadas de processamento. Para uma dcscri~~lo do M05 (rnclumdo uma implementaç-.lo em código de fonte C). consuhe IRFC 1321). O segundo principal algoritmo de hash em uso atualmente é o SliA- 1 (srcruc lwslr Cllgoritlrm- algoritmo de hash seguro) IFIPS, 1995). Esse algoritmo se baseia em princípios snmlarcs aos usados no projeto do M04 IRFC 1320), o predecessor do MOS. O uso do SHA-1. um padrão federal non c-amcricano, é exigido sempre que aplicações de âmbito federal precisarem de um algoriUllO d e resumo de mensagem seguro. Ele produz um resumo de mensagem de 160 bits. O rcsu Ita do mais longo toma o SHJ\- 1 mais seguro.

8.3.2 Código de autenticação do mensagem Retornemos ao problema da integridade da mensagem. Agora que comprcc11dcmos as func;õcs de hash, \'amos tcntnr entender como podemos garantir a integridade d.t mensagem: 1.

Alice cria a mensagem

2.

1\li t·e então t~ncxa /l(m) à mensagem m. criando uma mcns.1gcm cxtcndida (m. H(m)). c a c1wia para Bob.

3.

Bob recebe uma mcns.1gc m cxtcndída (m, l1) c calcula H(m). Se H(m) • h, Bob conclui que est:ltudo certo.

111

e calcuLa o hash H( m) (por exemplo, co m Sl li\·1 ).

Essa abordagem é, obvramcnte, crrOnea. Trudy pode criar uma mensagem m' falsa, passar-se por Alice. cal· cular ll (m') c cnvi:tr (m', ll(m')). a Bob Quando Bob receber a mensagem, tud o se encaixa na etapa 3. então de não suspeita de nada. Para realizar a integridade da mensagem, além de usar as fun (Oes de hnsh criptográficas, Alice c Bob prccísarno de um segredo compartilhados, que nilo é nada mais do que uma cadeia de brts denominada chave de autenticação. Ulilizando esse segredo compartilhado, a mtegridade da mén5agcm pode ser realizada da scgumtc mancrra:

1.

Alice cria a mensagem m , concatenas com 111 para criar 111 + s, e calcula o hash H(m+s) (por exemplo, com SHA·l). H (nHs) é denominado o código de autenticação da mensagem (MAC).



s

0~

0

- GDo H(m+S)

lnterMt

507

H(m+s)

o

~

L.:D=----- D

Legenda:

[!!!] • M('ftSil!)MI s

Figura 8.9

C6ã~go

• Se9fedo (oo>l)arllfhado

de outenti
2.

Alkc cnt-'0 :mexa o MAC :\ mcn.s:tgcm m, criMdo uma JtiCilS:Igcm cxtcndida (m. fl(m+s)), c n envia p;tm Bob.

3.

Bob recebe um:~ mensagem cxtcndida (m , h) c conhecendo s, calcula o MAC ll(m+S). Se Tf(m+s) - I•, Bob condu i que cst:l tudo certo.

Um resumo desse processo c ilustrado na Figura 8.9. É imponamc observar que o MAC (:lbrc\'i:w·J o de mrsS!Igt cwtlJcntiwtion coclr !código de autenticação da mensagem(). neste l':.\SO. não<: o mesmo MAC utilizado nos protocolos da camada de enlace (abrc,•iaç-lo de mu lium acccss conrrol lcomrolc de acesso ao meiol)! Um bom recurso d o MAC é o fato de ele não exigir um algoriuno de criptografia. Realmente, em muitas aplicações. incluindo o algoritmo de roteamento de estado do enlace. descrito antcriormcm c. as emidadcs de comunicaç;'o somcme cst:lo preocupadas com a integridade da mensagem c não com o seu sigilo. Utilizando um MAC. as cnudades podem autenticar as mensagens que enviam uma :\ outra sem ter de integrar algoritmos de críp1ografia complexos ao processo de imrgridade. Como voce pode espcmr, muitos padrões diferentes pam os ·lACs foram propostos ao longo dos anos. Atualmente, o mais popular é o HMAC. que pode ser usado com o MD5 o u SliA-1. O IIMAC. na verdade, passa os dados c a chave de autenticação duas vezes pela função de hash IKaufm:m. 1995; RFC 21041 . Ainda resta um assu mo importante. Como distribuímos a ch:l\'c de amcnticaçào compartilhada às entidades d e comuni<."::ç-Jo? No algoritmo de rotct~memo de estado do enlace. por exemplo, precisaríamos. de t~lguma forma, distribu ir :1 chave de autcnticaç;'o secreta a cada um dos roteadores no sistema independente. (Observe que os rmeadores podem usar a mesma chave de autenticação.) Um administrador de rede poderia, de fato, conseguir esse feito visilanclo Osic:uneme cada um dos rot~dores. Ou, se o administrador de red e for prcgul(oso, c se <:-Jda roteador possuir sua 1nóprla cha\'e pública, o administrador poderia distribuir a chave d e tmtcru ict~çâo a qualquer um dos ro teadores críptogmfanclo-a com a cha,•e pública do roteador c, CII\ÜO, Cll via r a chave cifrada por meio da re
8.3.3 Assinaturas digitais Pense no numero de vezes em que você assinou seu nome em um pedaço de papel durante a ultima semana. Voe~ assma cheques. compro,·ames de operação de t•utõcs d e crédito. documentos legais c canas. Sua assinatura atesta o fato de que voe~ (c n:lo outra pessoa) conhece o comeúdo do documento e/ou concorda com ele. No mundo digital, frequentcmcnte se quer indicar o dono ou o criador de um doeumcmo ou dcixt~r claro que alguém concorda com o contcudo de um d ocumento. A assinatura digital é uma técnica cnptogr.lOca usada para cumprir essas finalidades no mundo digital. Exatamente como acontece com as assinaturas por escrito, a assinatura digital deve ser verificável e não falsificável. Isto é, deve ser possível provar que um documento assinado por um indivíduo foi na verdade assinado

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------por ele (a assln:llum tem de ser verificável) c que somente aquele lndh•fduo poderia ter assi nado o documento (a assinatum não pode ser falsificada). Vamos considemr agom como podemos cnar um mf todo de assinatura d1gilal. Observe que quando Bob assina uma mensagem, ele de,•e colocar algo nela que seja ünico para ele. Bob podena adicionar um MACa assí· natura, sendo o MAC criado ao adicionar sua chave (ünica pam ele) à mens.1gem c. depois. fom1ar o hash. Mas p;tm Alice vcrillcar a assinatura, ela deve também ter uma cópia da chave, que mlo seria unica para Bob. Portanto. os MACs não se incluem nesse: processo. Lembre-se de que com a criptOgrafia de chave pública, Bob possui tanto uma chave publica como uma pri\'a· da, as quais Sllo unicas para Bob. Dessa maneira. a criptOgrafia de chave publica é uma excclcmc candidata pam prover assinaturas digitais. Vamos verificar como isso é feito. Su ponh:1q ue Bob queira assi nar digitalmente lLm documento. rn. Imagine que o doc umento seja um arq uivo ou uma mensagem que Bob vai assinar e enviar. Como mostra a Figura 8 .1O, para assinar esse d oeu me mo llob simplesmente usa sua chave criptográfica privada K; para processar K~ (m). A principio, pode parecer esmmho que Bob esteja usando sua chave privada (que, como vimos na Sec;;1o 8.2, foi usada para decriptar urna mensagem que tinha sido criptogmfada com sua chave pú blica) para ass inar um documento. Mas lembre-se ele que cripto· gra na e dccriptaçM n:~da mols são do que uma operação matemática (exponc11ciaçào à po tenci:~ t ou d no RSA: veja a Scç;\o 8.2) e que a intcn(;:\o de Bob n;\o é cmbar-.llhar ou disfarçar o conteMo do documento, mas :~ssinar o documento ele manelrn que este seja vcri0c:1vcl, não falsificávcl c incoll!estávcl. Bob tem o documento, ru, c sua assin:uum digital do documento é K8 (m). A assmmura digital K, (m) atende às nossas exigências de ser verificável c 11:'10 fals•fi c~h•cl? Suponha que Alice

tenham c K. (m). Ela quer provar na justiça (em aç-Jo litigiosa) que Bob de fato assinou o doeu me mo c que ele era a unka pessoa que poderia te-lo nssinado. Alice pega a chnvc publica de Bob, K;( m), c a aplica á assinatura digital K1 (m) assoc1adn ao documento m. Isto é, ela process.1 K;(K, (m)). e, vo1là, com dramática encennção, produz m, que é uma reproduç-lo exata do documento original! Ela entào argllmenta que somente Bob poderia ter assinado o documen to pelas seguintes razões: Quem quer que tenha assinado o documento deve ter usado a chave criptogrnOc:a pri\'ada, K;, pam processar a assinatura K, (m). de modo que K1 ( K1 (m)) = m. A única pessoa que poderia conhecer a chave prh41da K6 • é Bob. Lembre-se de que dissemos em nossa discuss.\o do RSA, na Scç-ao 8.2, que conhecer a ch:wc pllblica, K1 • n;\o serve parn descobrir a cha ve pnvada, K11 • Portanto, a llnica pessoa que poderia conhecer K8 ê aquela que gerou o par de chaves. (K6 • K;). em primeiro lugar. Bob. (Note que. para isso. admitimos que Bob ndo passou K; a ninguém c que ninguém roubou K, de Bob.) Também é Importante no tar que. s~ o docurnrmo original, m, for modificado para algu m modelo alternati vo m', a assinatura que Bob criou para rn n;'\o será válida para m', já que K;CK, (m)) não é igu.-.1.-.m'. Assim, obscr·

~""'""' m

Meosagem anl nada;

K8(m) fadfg54986fgnzmcnv T98734ngldskg02j

Qufflda Alice

~lpeo~ pof ~~

ser09tugkídflg

demot.xlo IMitO p.llol ts(ltv(!l. ~

que

Algoritmo criptográfico

nós ..

1

8ob

f)Chave privada de Bob,

K,-

Figura 8.1 O Crioçõo de uma ossinoturo digital poro um documento



509

vamos que as assinmurns digitais também oferecem imegridadc da mensagem, permitindo que o reeptor ''eriflquc se a mensagem foi ahcrJda, bem como sua fonte. Uma prccx:upaç;\o com os dados de assinatum por criptografia é que a criptogmfia c a dccnptac;ão prejudicam o desempenho do computador. Dados os O\'erlteads de criptografb c decnptaç;\o, os dados de assinatura por meio de criptogra!ia/dccriputç:lo completa podem ser excessivos. Uma abordagem mais eficiente é introduzir as funções de hash na assinatura digital. Na Seção 8.3.2. um algoritmo de hash pega uma mensagem. 111. de comprimento arbitrário c computa uma ·impressão digital. de comprimento lixo da mensagem, representada por H (m). Usando uma fun ção de hash. Bob assina o hash da mensagem em vez de assinar a própria mcns.'lgcm, ou seja. Bob calcula K, (1/(m)). Uma vez que H(m) é geralmente muito menor do que a mensagem original 111, o esforço computacional nc.>ct>ss.1rlo para criar a assinatura digital é reduzido consideravelmente. Em relação a Bob enviar uma mensagem para Alice, a Figura 8.11 apresenta um resumo do procedimento operacional de criar uma asstnatura digilal. Bob eoloc:-.\ sua longa mensagem original em uma função de hash. Ele. cnt:lo. nssimt digitalmente o has h resultante com sua chave privada. A mensagem origi n;~l (em tc.xto claro) junto com o resumo de mensagem assinada digitalmente (de agora em diante denominada assinatura dígítal) é então enviada pam Alice. 11 Figura 8. 12 apresenta um resumo do processo operaciomll ela assin:nura. Alice aplica a fun\,'tlo de lmsh à mens
Resumo de mensagem de tamanho fixo

t3.

Cara AliCe EWJ CO}I MUITO long
Pacote a enviar para Alice

Função de hash muitos.-para.um

Resumo de mensagem assinado Fgkopdgoo69cmllw 54psdterma(asofmz

Figura 8.11

Opg mdvboljrtnsd gghPPdogm;lcvkb

Envio de umo mensagem assinado digitalmente


€>-

Chave privada de Bob. K,-


Resumo de mensagem assinado Fgkopdgoo69cmliW 54psdterma(asofmz

-


(>Chave pública de Bob, K8

Mensagem longa Cara Alice: Essa carta é MUITO longa, pois tenho muito a dizer....

Resumo de mensagem de tamanho fixo Opgmdvboljrtnsd gghPPdogm;l
Resumo de mensagem de tamanho fixo Fun~Ao de hash muitos·para-um

Opgmdvboljrtnsd gghPPdogm;lcvkb

Figura 8.12 Yerifi
Certificação de chaves públicos Uma aplica~·;\o importante de assinaturas digitais c a ccrtificaç-Jo de cha"cs públicas. ou seja, certificar que uma chave pública pertence a uma cnlidadc cspcdnca. A ccrtific.-aç;'lo de ch:wcs públicas c usada e m muitos protocolos de rede seguros, incluindo o IPscc c o SSL. Para compreender m:1ís sobre o problema. consideremos uma vcrs:1o de comercio clcuOnlco pam o clássico ~t rote da pizza". Suponha que Alice trabalhe no ramo de pizzas para viagem c que aceltc pedidos pela Internet. Bob, que adora piz.z.a, envia :1 Alice um:1 mensagem em texto aberto que contfm o endereço de sua cas:~ c o tipo de pizza Q\IC quer. Nessa mcns.1gcm, ele mel ui tambcm uma assina tura digital (isto t. um !tas h assinado cxtraldo da mensagem original em tex to abcno) para provar a Alice que ele t a fonte verdadeira da mensagem. Para verificar a assinatum, Alice obtém a clmvc pública de Bob (talvez de um servidor de ch:~ves públicas ou de uma mensagem de e-mail) c vcrirlcil a assinatura digital. Ocss:l maneira, ela se ccninca de que foi Bob, c mlo :~ lgum .--dolcsccntc brincalMo. quem fez o pedido. Tudo parece caminhar bem até que entra em cena a esperta Trud)•. Como mostrado na Figura 8.13. Trudy decide fazer urna travessura. Ela emria uma mensagem a Alice na qual diz que é Bob, fornece o endereço de Bob c pede uma pizza. Nessa mensagem ela também inclui s ua (de Trudy) chave publica, embora Alice admita. naturalmente, que seja a de Bob. Trudy também anexa uma assinatu ra digital, a qual foi cnada com sua prórpia (de Trudy) cha\'c pn\'ada. Após receber a mensagem, Alice aplica :1 chave publica de Trudy (pensando que é a de Bob) à assi natura digital e concluirá que a mensagem em texto aberto foi, na verdade, criada por Bob. Este ncará muito surpreso quando o cntregador aparecer em sua casa com uma pizza bem variad a!



511

~f

~Mensagem

L

Fun~ de hash

\•~...-m_u_it_os_-pa_r_a_-u_m---1

l

-

Atgontmo aiptogr.Uico

{)lChave privada de Trudy, Kr"

Resumo de mensagem assinado (utilizando a chave privada de Trudy) Fgkopdgoo69cmxw 54psdterma(asofmz

€>Chave pública de Trudy, Kf

Alice usa a chave pública de Trudy pensando que é a de Bob e conclui que a mensagem é de Bob

Figura 8.13 Trudy se posso po1 Bob usando aiptogriiOO de chaves públicos Por esse exemplo, vemos que, para que a criptografia de chaves publicas seja util. \'OC~ precisa ser capaz de verificar se voc~ tem a chave pública verdadeira da entidade ( usuários, browsers. rotcadorcs e outras) com a qual quer se comunicar. Por exemplo, quando Alice estiver se comunicando com Bob usando criptografia de chaves publicas, ela prectsarn saber, com certeza, que a chave publica que supostamente é de Bob é, de rato, dcle. t\ vinculação de uma chave pública a uma entidade particular é rcita, tipicamente. por uma autoridade certificadom (urtiflwtion awhority - CA), cuja tarefa é validar identidades c emitir certificados. Uma CA tem as

seguintes

incumbênci:~s:

I.

Um:~ CA verifica se uma entidade (pessoa, rotc~1dor c assim por di:~nte) é q uem diz ser. Não há procedimentos obrig:~tórios para o modo como deve ser rctt:J a ccrtlfic:~ç
2.

Tào logo verifique :1 identid:lde da entidade, a CA cria um cert il"icado que ' 'incul:• a ch:we pública d;t enudade à tdentidadc ''eriflcada. O cenificado contém :1 chave pública c a inrormaç
Vejamos. agora. como certificados podem ser us.1dos para comb:.ter os espertinhos das pizzas. como Trudr e outros indesejáveis. Quando Bob faz seu pedido, ele também envia seu certificado assinado por uma CA. Alice usa a chave pública da CA para verificar a validade do certificado de Bob e extrair a ch ave pública dele.


Chave p ública da CA, Ku,."

o1

~

1/(....,


Autoridade Certificadora (CA)

Cert1ficado de Bob assinado pela CA. contendo sua chave pública,

K;

Figura 8.1 4 Bob obtém suo
O RFC 1-122 descreve um gerenciamento de chaves baseado ern ú\ para ulilizaçt'o com o c- rnr~il seguro pela Internet. Essa rccomendaçilo é com~livd com X.509, mas vai além dcs1:1. pois es tabelece procedimentos e convençocs p:1r;1 uma arquitetura de gcrcnci;mlento de cll
8.3.4

Autenticação do ponto final

A autcnllc-Jcão do ponto final f o processo de pro,'llr a identidade de uma pessoa a alguém. Como seres humanos. autcnttcamos uns aos outros de diversas maneiros: reconhecemos o rosto um dos outros ao nos cncon· trannos. Reconhecemos a voz urn do o utro no telefone. Somos autenticados por um oficial da Alfãndcga que compara a nossa roto com a do pass.1pone. Mas ao realizar a autenticação alm,·és da rede, as panes em comunicação nilo podem confiar n:~s lnro rmaçOes biométricas, como uma apar~ncia visual ou um timb re de voz. Realmente, muitas vezes os elementos da rede, como roteadores e processos clientc-scrv~dor, devem autenticar uns aos outros somente baseados na troca de mensagens c dados. A primeira ques t:1o que aborda mos é se os M1\ C.s (estudados na Seção 8.3.2) podem ser u~ados pam a auten· do ponto final . Suponha que Alice e Bob compartilhem um segredo comum s, e que Alice queira etwiar uma mensagem (por exemplo, um segmento TCP) a Bob e ele queira ter certeza ele que essa mensage m tenha s ido

t ica~lo

Nome do campo Vtrsõo Núme1o de série

Descrisão NCrne~o do ve.sõo da especificcçõo X .S09 lden1itl(odol exdi.ISivO emitido pekJ CA po10 t.m cellilicodo

Nomedo~o

ldenlidode do CA que emiliu ocertmdo. em forllllto de nome d"ISiinto CDN) [RfC 2253) Inicio e findo pesíodo de volidcde do Wlifi tml ildicoçõo do olgoritmo de chove público (e pctãmetros do olgoritrnol oser usado com esso dl1ve

Chave público do S1Jjeiro

Tabela 8.4 Campos sele


enviada por Alice. A abordagem natural baseada no MAC é a scgulntc. Alice cria um MAC usando a mensagem c o segredo comparlilhado, anexa o MAC à mensagem e envia a · mensagem estendida" res ultante para Sob. Quando Bob rr
Ataque de reprodução e nonces Será que ele sabe mesmo? Bob não tem 100% de certeza sobre a fonte da mensagem porque ainda há a possibilidade de ele estar sendo engMado com um ataque de rcprodu~M. Como mostrado na Figura 8. 15, Trud)• prccisn somente analisar c gravar a mensagem estendida de Alice c reproduzi-la algum te1npo depois. i\ mensagem repetida poderia ser "Concordo em transferi r um milhão de dólares da conta de Bill para a con ta de Trudy.·, fazendo com que um tOt31de dois milhões de dólares sejam rmnsfcridos; ou a mensagem poderia ser "O enlace do Ro teador Alice para o Roteador Charlic parou de runc ionar", que, se e nviada após o enlace ter sido conser1ado, poderia c:msar conngurar;ôcs errôneas nns tabelas de rep11ssc. O cenário de falha na Figura 8.15 resultou do fa to de Bob n:lo conseguir distingui r entre a mensagem original enviada por Alice c a rcproduç;\o da mensagem original de Alice. Ou seja, Bob n;\o conseguiu saber se Alice csta''ll ao ' 'ivo (isto é, rc:.lmente csta"a no outro pomo da conexão) ou se a mensagem que ele recebeu foi uma rcproducM. O leitor muito (multo) atento se lembrará de que o protocolo de aprcscnt3ÇM de trts vias precisou abordar o mesmo problema- o lado do servidor de uma conexão TCP não queria acci~r uma conexão se o segmento SYN recebido rossc uma cópia an tiga (rcLransmiss:io) de um segmento SYN de uma conexão anterior. Como o Indo do servidor TCP rcsoi\ICU o problema de dctcnninar se o cliente esta\-a mesmo ao vi\'o? Ele escolheu um número de scquencia inicial que não havi3 sido usado por um bom tempo, en,iou esse número ao cliente, c então aguardou que o cliente respondesse com um segmento J\CK contendo esse numero. Podemos adotar 3 mesma idcta para fins de autenticação. Um nonce é um numero que o protocolo usará somente uma vez por toda a vida. Ou seja, uma vez que o protocolo Ulilizar um nonec, esse mlmero nunca mais será utilizado. Como mostrado na Figura 8. 16, nosso novo protocolo usa um noncc da seguinte fonna:

1.

Sob escolhe um nonce, R. c o envia a Alice. Observe que o noncc é enviado em aberto. Alíce agora cria o MAC utilizando sua mensagem original, o segredo compartilhado, s. c o nonce, R. (Para criar, o MAC Alice pode, por exemplo, concatenar o segredo compartilhado c o nonce com a mcns.1gcm c obter um

M A( :o

f(msg,s)

TransterirUSSI milhOO MAC de Bill para Trucly

Bob

Alice

~~ Trudy

Legenda:

I; Gravador Figura 8.1 S Ootoque de reprodução

T~USS1 rnílhao de Bill para Trucly

MAC

Bob


~ Alice

eu sou Alice

--

-

Transferir USSl milhão de Bill para Trudy

Bob

• MAC MAC: f{msg.s.R)

Figura 8.16

Defeso conho ootoque de reprodução com um nonce

rtsumo atr:wés de um hash.) Alic.:c anexa o MAC li mensagem, cri:1 uma mensagem estendida c n envia p~ra Bob. 2.

Bob c:•lcula o MAC d;~ mcns:1gcm (comido na mensagem cslendld:•). um noncc R c segredo compar· tllhado s. Se o MAC resultante for igual ao MAC da mens.1gcm cxtcndida. Bob sabe não somente que Alice criou a mensagem mas tambC:m que ela criou a mcr\sagcm IIJJ6s Bob ter cnvi:1
Como veremos n:t Scç.lo 8.5 e 8.6, quando discmimos sobre SSL e lPsec, a combina~o de nonces c MACs muitas vezes é utilizada em protocolos de rede seguros para prover uma mtegridade da men agem e uma auten· tica~o do ponto final. Mas c se Alice qurscr enviar uma série de mensagens - por exemplo, uma série de segmentos TCP? Bob terá de enviar a Alice um novo nonce para cada uma das mensagens? 'a prática. somente um nonce é realmente necess:\no. Como veremos na Se~o 8.5. quando discuunnos sobre SSL, um unico nonce combinado a numcros de sequência permitirá que Bob ''crífique a originalidade de todas as mensagens que ele recebe de Alice.

Autenticação com criptografia de chove pública O uso de um noncc c de um segredo compartilhado compusemm a base de um protocolo de autcntlcaç(lo bem-sucedido. Uma questão natural é se podemos usar um nonce c uma criptograna de chave pllblica para resolver o problema da autenticaç.lo. O uso de uma abordagem sobre ch:1vc pliblic.."l evitaria uma dificuldade em qualquer sistema de segredo compartilhado - preocupando-se, primeir;11ncnte, em como as duas panes sabem o valor do segredo compartilhado. Um protocolo n:uuml que usa essa crl ptogr;1fin de chave pt\blica é: 1.

Alice envia a Boba mensagem •Eu sou Alice".

2.

Bob escolhe um noncc, R, c o envia para Alice. O noncc será usado, novamente, para se assegurar de que Alice cstd ao vivo. Alíce usa sua chave privada K; para cifrar o nonee e envhu o valor resultante K_. (R) para Sob. Visto que somente Alice sabe sua chave priV<~da, só ela pode criar K~ (R) .

3. 4.

Bob aplica a chave publica de Alice, K~. à mensagem recebida; ou seja, lklb computa K~(K~ (R)). Lembre-se de nossa discuss:lo sobre a criptografia de chave pt1b1icu RSA na Seç;lo 8.2 que K~(KA (R)) • R. Assim, Bob computa r c autentica Alice.

A opera~o desse protocolo é ilustrada na Figura 8.17. Esse protocolo é seguro? Uma vez que usa técnicas da chave publica, é necessário que Bob recupere a chave pública de Alíce. Isto nos leva a um cenário imercssantc, mostrado na Frgura 8. 18. na qual Trudy pode ser capaz de se passar por Ahcc paro Bob. 1. Trudy envia a Boba mei\Sllgem "Eu sou Alice".

2. Bob escolhe um nonce, R, e o envia para Alice, mas a mensagem é captada por Trudy.



BU sou Alice

. ...... .-: Bob processa K,t" (KA-(R)) • lt autenticando Atice

Figura 8.1 7 Funcionamento coneto do p1otocolo de outen~cosõo do chove público 3. Trudy usa sua chave privada K, p:~m d rmr um nonce c envia o valor rcs ult:mtc, K,(R), para Sob. Para ele. K, (R) é :1pcn:1s um grupo de bits e ele não sabe se os bits representam K, (R) ou K., (R). 4. Bob deve obter ttgora a chave ptiblica d e Alice para aplk~J.r K~ ao valor que ele a<."tlba de receber. Ele envia uma mensagem a Alice solicitando o (Bob pode também recuperar a chave publica de Alice de seu s ite Wcb). Trudr intercepta essa mc~gcm ~~m~m c responde a Bob com K~. ou seja. a ch:l\'c publica de Trudy. Bob computa K;
K;

A partir desse cen. rio. cst:l claro que o protocolo de autemicaçoJo de chave publica é someme tdo seguro quanto a d1stnbuiç.lo de chaves públicas. Felizmente, podemos usar certificados para d1smbuir cha,•cs publicas de ronna segura, como vimos na Seção 8.3. No ccnáno da Figura 8.18, Bob e Alice podem, finalmente, descobrir que há :~lgo errado. pois Bob afirmará que interagiu com Alice, mas Alice sabe que nunca interagiu com Bob. Existe um ataque ai nda mais traiçoeiro que impediria essa detecção. Na Figu ra 8.19. Alice e Bob estão conversando, mas para aproveitar o mesmo b uraco no protocolo de Jutenucar;ào, Tntd)' é capaz de se interpor clrfomw trcmspclr<'lllc entre Alice c Bob. Em particular, se Bob começa r a Cll\'iar dados cifrados para Alice usando a chave de criptograOa, que ck recebe de Trudy, esta pode

Eu sou Alice

-- -· R

Kr iR)

-------~.: .....-:. Bob processa

.

•

Figura 8.18 Buroco de seguronço noprotocolo de outenticoçõo do chove público

Kr'(K t(R)) =R. autenticando

Trudy como se fosse Alice


Su sou Alice

Eu sou Alice

-· ...-:

R

Envio-1'118 sua chavo !íiblico

K,:

.

..... .:

..

K•

\

Alíce decripta K,.' (m),

recuperam

Trudy decripta K;(m), recuperaMprocessandom•K, ( K,'~)). criptografa musando K..' .

repassa K., .'(m)para Alke

,. Figure 8.19

~

Bob envia dados.m. criptografados por

K.,'

,.

Ootoque do homem do meio

recuperar o texto aberto da comunicação de Boba Alice. Ao mesmo tempo, Trudy pode enc:uninhar os dad os de Bob para Ahcc (apóS recodiflcar os dados usando a verdadeira chave publica de Alice). Bob está feliz por enviar dad os cifrados e Alice eslá feliz por recebe-los utiliz:mdo sua própria chave públicn; :unbos não s;tbem da presença de Trud y. C.'\So Bob c Alice se encontrem depois c discul3m sobre sua interação, Alice terá recebido cxalamenu: o que Bob enviou, eotào nada será d etectado como sus peito. Esse é um exemplo do que denominamos ataque do ho mem do meio (mms apropriadameme nesta seç:'lo, um "ataque da mulhe r do meio"').

8.4

Protegendo o e-mail

as seçOcs ameriorcs analisamos as questões fundamentais em seguran~;:1 de redes, incluindo a criptografia d e chave s im~trica c de chave p\lblica. auLenlic-.v;·.lo do ponto final , distribuiç.1o de chave, intcgrid:tde da mensagem c assl nalllr:tS d igitais. Agom vamos analisar como CSS.'\S ferramentas es lào sendo usadas pam oferecer segurança na Internet. l

Curiosamente, é possível oferecer servi ços de segurança em cada uma das quatro principais camadas da pilha de protocolos da Intern et. Quando a segurança é ofcrcdd;~ p<~ra um protocolo especifico da camad;t de aplicaç.lo, a aplicaç-Jo que usa o protocolo utilizará um ou mais serviços de scguran~;a, como s igilo, autenticação ou integridade. Quando a segurança é ofercc•da para um protocolo da camada de Lransportc, todas as aplicações que usam esse protocolo aproveitam os serviços de segurança do protocolo de transporte. Quando a segurança é oferecida na camada de rede em base hospedeiro para hospedeiro, rodos os segmentos da camada de transporte (e, por-



517

tanto. todos os dados da rnmada de aplirnçào) aproveitam os serviços de segurança da rnmada de rede. Quando a segurança é oferecida em um enlace. então os dados em todos os quadros que percorrem o enlace recebem os serviços de segurança do enlace.

Na Scç;lo 8.4 a 8. 7 vcrifirnmos como as ferramentas de segurança esu\o sendo us:tdas nas rnmadas de enlace, rede. transporte c aplicação. Obedecendo à estrutura geral deste lh•ro, começamos no topo da pilha de protocolo c diseuumos segurança na rnmad."\ de aplicaç;\o. Nossa abordagem é u~r uma aplirnç;lo especifica. c-mail, como um estudo de caso para a segurança da camada de aplicação. Emào, descemos a ptlha de protocolo. Examinaremos o protocolo SSL (que provê segurança na camada de transporte). o IPscc (que provt segurança na camada de rede) e a segurança do protocolo LAN IEEE 802.11 sem fio. Você deve estar se perguntando por que a funcionalidade da segurança cstn sendo rornccida em mais de uma camada na Internet. Já n;'o bastaria prover essa funcionalidade na camada de rede? Há duas respostas para essa perguma. Pr11nclro, embora a segurnnça na camada de rede possa oferecer •cobertura tot:tt• cifrando todos os dados nos d:nagramas (ou seja, todos os segmentos da camada de tl"..\llS!>Onc) c amcnt icando todos os endereços I P dcslinmários, ela não pode prover scgumnça no nível do usuário. Por exemplo, um si! c de co m~ rcio nào pode confiar na segurança da ca mada I P para autemica.r um cliente que vai comprar mercadorias nesse si te. Assim, existe a necessidade de uma funcionalidade da scguranÇ"J em camadas superiores bem como cobertura total em ~1nais inferiores. Segundo, geralmente é mais fácil implcrncm.u serviços dt~ tmernct, incluindo serviços de segurança nas cam:1das superiores da pilha de protocolo. Enquanto aguardamos a ampla implemcmaç:'\o da scgumnça na camada de rede, o que ainda levará muitos anos, muitos criadores de aplicaç:.lo "jâ fazem isso~ c introduzem a funcionalidade da scgumnça em sua aplicações favoritas. Um exemplo d:lssico ~o Prctty Goocl PrivtiC)' (PGP). que oferece e-mail seguro (disctuido mais ndíame nesta scç:lo). 1 eccssltando de apenas um código de aplicaç-.lo do cliente e do servidor. o PGP foi uma das primeiras tecnologias de segurança a ser ampl:uncmc milizada na Internet.

8.4.1

E-mail seguro

Agom usamos os princípios de criptografia das Seções 8.2 a 8.3 par:t criar um sistema de e-mail seguro. Criamos esse projeto de alto mvcl de maneira incrementai, introduzindo, a cada etapa, novos serviços de segu· rança. Em nosso projeto de um sistema de c-mail scgt1ro, vamos mame r em mente o exemplo picante apresentado na Scçüo 8.1- o caso ele amor entre Alice c Bob. Imagine que Alice quer enviar uma mensagem de e- mail para Bob c Trudy quer bisbilhotar. Amcs de avançar c projct:tr um sistema de c-mail seguro pam Alice c Bob. devemos considerar q uais carne· tcrfstkas de scguran~-a seriam as mais desejáveis para eles. A primeira caractcrfst k-a, c a mais importante, é a confidencialicladc. Como roi disc;;mido na Seç~o 8.1, nem Alice nem Bob querem qu~ Trucly leia a mensagem de e-mail de Alice. A segunda camctcr(stjca que Alice e Bob prov:wrlmcnte gostariam de ver no sistema de e- mail seguro é a autentintç
bow4tto4ic~ Redes de tom pu tod ores e o Interne~1------------------------

criptografia de chaves publicas (usando, por exemplo, RSA). Na abord:1gem de ch:wes publicas, Bob dlsponlbíliza publicameme sua chave pública (por exemplo, em um servidor de çhaves públicas ou em sua página Web pessoal) c Ahce criptografa s ua mensagem com a chave pública de Bob, c cnv1:1a mensagem cnptografada pam o endereço de c·mail de Bob. (A mcns;tgcm criptografada é cncapsul:1da com cabccalhos Ml~IE c cnvi:~da por SMTP comum, corno discutimos na Seção 2.4.) Quando Bob recebe a mensagem. ele simplesmente a decodifica com sua dla\'C privada. Admitindo que Alice tenha certeza de que aquela çhave pliblka é a de Bob (c que é suficientememe longa), essa abordagem é um meio exceleme de fornecer a confidenciahdade desejada. Um problema, conmdo, é que a crlptogmfia de chaves publicas é rchtú\-amcntc lncfidcntc, sobrttudo para mensagens longas. Para superar o problema da eficiência. vamos fazer uso de uma chave de sess;'lo (discutida na Scç;lo 8.2.2). Em particular, Alice (1) escolhe uma chave simétrica, K,, aleatoriamente. (2) erlptograra sua mensagem rn com a chave simétrica K., (3) criptogrnra a chave simétrica com a chave pública de Bob. K,, ( 4) conc:llcna a mensagem críptograrad:l c a chave simétrica criptografada de modo que formem um 'pacote' c (5) envia o pacote ao endereço de e·mall de Bob. Os passos estilo ilustrados na Figura 8.20. (Nessa figura c nas subscqucntes, o sinal '+' dentro de um cfrculo re presen ta formar a co n~llcn'Jçilo c o sinal ·-' dentro de um d rculo, desfazer a concatcnaçM.) Quando 6ob receber o pacote, ele (1) usará sua chave privada K11 , para obter a ch:wc sim4!tricn K,. e (2) utilizará a 'havc si m~Lríca K) p:1m dC(odificar a mensagem n1. Agora que projetamos um sistcm;l de c-mail seguro que rornccc confidcncialidadc. vamos desenvolver um outro sistema que rorncça autenticação do remetente c também integridade de mensagem. Vamos s upor. no momento. que Alice c Bob não estejam mais preocupados com confid cndalidadc (querem compartilhar seus scmimcntos com todos! ) c que estejam somente preocupados com a au temicação do remctemc c com a intcgridttdc da mensagem. Para realizar essa tarefa, usaremos assinaturas digitais c resumos de rncns.1gcm, como descrito na Seção 8.3. Especificamente, Alice ( 1) aplica uma funç-Jo de hash li (por exemplo, MOS) â s ua mensagem m. para obter um resumo de mensagem, ( 2) assin:l o resultado da função de hash com sua chave pri,•ada K~ para cri:1r uma assinatura digital, (3) concatena a mc ns;lgcm original (n;'o criptogra[ada) com a assinatura para criar um pacote e ( 4 ) envia o pacote ao endereço de c-mail de Bob. Quando Bob recebe o pacote, ele (1) aplica a cha,•c pública de Alice. K;, ao reswno de mensagem assinado c (2) compara o resultado dessa opcraçilo com o próprio hash H da mensagem. As etapas são ilustradas na Figura 8 .21. Como dtscutimos na ScçM 8.3, se os dois resultados forem iguais, Bob poderá ter razo;\vcl certeza de que a mcns.'lgcm veio ele Alice e n;lo foi alterada. Vamos considemr .tgora o projeto de um sistema de c-mall que romeça confidcncíalidade, autenticação de remetente c integridade de mensagem. Isso pode ser feito pela combinaç;\o dos procedimentos das figuras 8.20 c 8.21. Em primeiro lugar, Alice cria um pacote preliminar, cxat:tmente como mostra a figura 8.2 L, constitufdo de su:t mensagem original jumo com um hash da mensagem assinado digitalmente. Em seguida, ela tra ta esse p;tcote preliminar como uma mens:.~gem em si e envia essa nova mensagem seguindo as etapas do remetente mostra· das na Figura 8.20, criando um novo pacote, que é enviado a Bob. As etapas seguidas s."to mostradas na Figura 8.22. Quando Oob recebe o pacote, ele aplica primeiramente seu lado ela Figura 8.20 c deJ>ois seu lado da Figura 8.2 L

m

58

~ Ks

8 ~

Ks(m)

Ks(m)

K1'(Ks)

Alice envia uma mensagem de e-mail, m

Internet

é K1'(K5)

58 Ks

m

~

~

Bob re
Figura 8.20 Alice usou umo chove de sessão simétrico, Ks· poroenviar um e111ofl secreto poroBob



519

m

0m

Alice envia a mensagem de e-mail m

Figura 8.21

Internet

0 m

Bob recebe a mensagem de e-mail m

U~lizoçõo de fun~ões de hosh e ossinoturos ÕIQitois pOJO fornecer outenticoçõo de remetente eintegridade de rnenso~

É prccbo ficar claro que esse projeto atinge o objetivo de fomcccr confidencia l idr~dc, autcmicaçào de remetente e

integridade de mensagem. 1otc que n~ esquema Alice utiliza criptografia de chaves públicas duas vezes: uma \'CZ com sua clmvc prh"Jda c uma vez com::~ ch:wc pública de Bob. De maneiro semclhanu:, Bob um1 bém apli e~ a cripto· grafia de chaves públicas duas vezes- uma vez com sua chave pri vad<~ c tama vez com a chnvc pública de Alice. O proj eto de c· mail seguro ilustrado na Figura 8.12 pro~\Vtlmentc fornece segumnça satisfatória para os us uários de e-mail na m:aioria das oe~siOes. Mas ainda resta uma questão importante a ser abordada. O projeto da Figura 8 22 requer que Alice obtenha a cha\•e pública de Bob c que Bob obtenha a chave püblk a de Alice. A distribuicào dcss.1s chaves é um problema nad<1 tri vial. Por exemplo, Trud)• poderia se disfa rçar de Bob dar a Alice sua própria chave pública, dizendo que é a chave publica de Bob. Como aprendemos na Seção 8.3, uma abordagem popul:u para distribuir chaves pliblicas com segurança é ccnificar as chaves publicas us:mdo uma atlloridade ceruficadora.

Phil Zimmermonn e o PGP Philip R. Zimmermonn é o criodor do Prelty Good Privocy {PGP). Por couso disso, ele foi olvo de uma investigação criminal que durou três anos, porque o governo norte-americano sustentava que os restrições sobre o exportação de software de criptogroAo tinhom sido violados quondo o PGP se espolhou por todo o mundo após suo publicação como software de uso livre em 1991 . Após ter sido liberado como software comporlilhodo, olguém o colocou no Internet e estrangeiros o descarregaram. Nos Estados Unidos, os progromos de crlptogrofio sôo clossificodos como artefatos militares por lei federal e não podem ser exportados. A despeito do folia de finonciomento, do inexistência de representantes legois, do folto de um o empreso poro lhe dor apoio e dos intervenções governamentais, mesmo assim o PGP se tornoo o software de «iptogrofio poro e-moil mois usodo no mundo. O extroordinório é quo o governo dos Estados Unidos pode ter contribuído inadvertidamente poro o disseminação do PGP devido ao coso Zimmermonn. O governo nort&
bow4tto4ic~ Redes de cora putod ores e o Inle;.rn;;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

G8,

0

0

m

Ks

IK;H I

Para a

Internet

J

Figuro 8.22 ArKe uso criptografia de choves simétricos, criptogrofio de chaves públicos, uma funçõo de hosh e umo ossillaturo digital pom fornecer confidencia&dode, outentic~õo de remetente e íntegridode de mensagem

8.4.2 PGP Projetado originalmente por Phil Zimmermann em 199 I , o PGP (Pretty Good Privacy - privacidade rnzonvel) é um esquema de criptogrnfia parn e-mail que se tornou um padrão de fato. O site do PGP é acessado mais d e um milh;lo de vezes por mes por usuários de 166 países (PGPI. 20071. Versões do PGP est;\0 disponlveis em domfnio pLiblico; por exemplo, voce pode encontrar o software PGP p:trn sua plataforma favorita, bem como gran· de quamidade de material de leitura interessame. na home page imemacional do PGP (PGPI, 2007) . (Um ensaio parueularmcnte mteressante, escrito pelo autor do PGP, é encontrado em (Zimmerm:mn, 2007) .) O projeto do PGP é, em essência, idêntico :10 projeto apresen tado na Figura 8.22. Dependendo da vers;lo. o software do PGP usa !\1105 ou SHA para processar o resumo de mensagem; CAST. DES triplo o u IDEA para criptografar chaves stmétncas. e RSA para crlptografar cha\'es públicas. Quando o PGP é insLnl:~do, o sofm'llre cria um par de cha\'es públicas para o usu:1rio. A chave ptlblica pode então ser colocada no sitc do usu::irio ou em um servidor de cha\'es publícas. A cha\'e prh'llda é protegida pelo uso de uma senha. A senha tem de ser infom1ada todas as vezes que o usuário acessar a chave privada. O PGP orerece ao usuário a opção de :ISSinar digitalmente a mensagem. criptografar a mensagem ou, ainda, ambas as opcOcs: assinar digitalmente e criptografar a mens:~gem . A Figura 8.23 mostra uma mensagem PGP :~SSi nada. Essa mensagem aparece após o cabeçalho MIME. Os dados codificados da mensagem correspondern a KA( lf(m)). isto é , ao reSLtmo de mensagem assinado dlgilalmcmc. Como discmímos antes, para que Bob verinque a integridade da mensagem, ele precisa ter acesso à chave pública de Alíce. A Figura 8.24 mostra uma mensagem PGP secreta. Essa ntens;lgem t:lmbém aparece após o cabeçalho MIME. É claro que a mensagem em tex to aberto mlo está inclufda na mensagem de e-mail secre1<1. Quando um remcteme

-·--·BEGIN PGP SIGNE D MESSAGE----Hash: SHAl Bob: Can I see you tonight? Passionately yours. Alice ·--- BEG IN PGP SIGNATURE----Version: PGP for Personal Privacy 5.0 Charset: noconv yhHJRUhGJGhgg/12EpJ+lo8gE4v83mqJhFEvZP9t6n7G6mSGw2 -----END PGP SIGNATURE--·-Figuro 8.23 Uma mensagem PGP assinado



52.1

BEGIN PGP MESSAGE----Vers i on: PGP for Persona l Pri vacy 5. O u2R4d+/jKmn8Bc5+hgDsqAewsDfrGdszX681iKm5F6Gc4sOfcXyt RfdSlOj uHgbcfOssWe7 /K-1 Khnf·li kloO+ 1/BvcX4 t-Uj k9Pbc04 Thdf2awOfgHbnmKlok8iy6gThlp ENO PGP HESSAGE Figura 8.24 Umo mensogem P6P seueto (como Alice) quer não apenas a confldencialidadc, mas também a integridade, o PGP contém uma mensagem como a d:-t Figura 8.24 dentro da mensagem da Figura 8.23. O PGP t:unbém fornece um me~o":lnismo para cerliflca<.-.10 de chaves pí•blreas, mas esse mc<:flnismo é bem diferente d:1qucle d 11 CA mais convencionaL As chaves púbHcas do PGP s:1o certiflc:-.das por uma rede tle conficm( cr. A própria Alice pode ceniricar qualquer par chave/usuário quando ela ach~r que esse par realmcme está correto. Além disso. o PGP permite que Alice declare que ela confia em outro usuário pam atestar a autenticidade de mais chaves. Alguns usuários elo PGP assinam rcciproc:unenlc su:1s ch:wcs monwndo grupos de assinatura de chaves. Os usuários se reüncm fisicamente. trocam disquetes contendo as dKwes públi<:as c ccniflc:nn sm1s ch;wes reciprocamente, assinando-as com suas chaves privadas.

8.5 Protegendo conexões TCP: SSL 'a seç:\o anterior, vimos como as ttcnjcas criptográficas podem prover sigilo. integridade dos dados c auumlicaç-Jo do ponto final a aplicações espccfficas, ou seja, e-nt;lil. ·esta seç;lo, de!>Ceremos un1.1 cmnada na pilha de protocolo e examinar como a criptografia pode aprimorar o TCP com os serviços de segumnça. mcluindo sigilo. integridade dos dados e autenticaç:to do ponto final. Essa vers:lo apnmomda do TCP é denominada Camada Segura de Sockets(Srcurc Socluts Lc1yrrl (SSL). Uma versão lcYcmcnte modificada da vcrs;'lo 3 do SSL. denominada Segurança na Camad:-. de Transporte ITransport Layer Sccurítyl (Tl.S). foi padronizada pelo IETF IRFC 22461. O SSL fo1 originalmente proJetado pelo Netscape. mas as •dcias básicas por tráS da proteção do TCP antecedem o trabalho do Ne t~pe (por exemplo, consulte Woo (Woo, 19941. Desde sua concepção, o SSL obteYe uma ampla implcmcntaç:\o. Ele t suportado por todos os browscrs Wcb e servidores Wcb. c usado basicamente por todos os sites populares (incluindo Amazon, eBa)', Yahoo!, MSN etc.). Dezenas de bilhões de dólares s:\o gastos com o SSL a cada ano. Na verdade, se ' 'CX:é já comprou qualq uer coisa pela Internet com seu cart:lo de crédito, a comunicaçM entre seu browscr c servidor para essa compra foi quase certamente por meio do SSL. (Vcx:é pode identificar que o SSL está sendo usado por seu browser quando a URL se iniciar corn hnps: em vez de http:.) Para entender a neccssid
Se nenhuma integridade de dados ror utilizada. um invasor poderia modificar o pedido de Bob, fazell· do-o comprar dez vezes mais &ascos de perfumes que o desejado. Finalmente, se nenhuma autenticação do serYidor for utilizada, um sen'ldor poderia exibir o famoso logotipo de Ahce lncorporated, quando na verdade o site é manudo por Trudy. que está se passando por Alice lncorporated. Após receber o pedido de Bob, Trudy poderia ficar com o dinheiro dele e sumir. Ou Trudy poderia realizar um roubo de identidade obtendo o nome, endereço e número do cartão de crédito de Bob.

bow4tto4ic~ Redes de co111 pu tod ores e o Inle ;.; ro;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

O SSL aborda e-ssas q uestões aprimorando o TCP com sigilo. im egridadc dos dados, autcm irnç-.lo do servido r e autcntirnç;lo do cliente. Muitas vezes. o SSL é usado para oferecer segurança em transaçõeS q ue ocorrem através do HTTP. Entretanto, como o SSL protege o TCP, ele pode ser empregado por qualquer aplicação que execute o TCP. O SSL prové uma Interface de Programaç;lo de Aplicação (API) com socket5, semelhante ao API do TCP. Quando urna aplicaç;io quer empregar o SSL, ela inclui classes/bibliotecas SSL. Como mostrad o na Figura 8.25, embora o SSL resida tecnicamente na camada de aplicaç;lo, da perspectiva do desenvolvedor, ele é um protocolo de transporte q ue provê serviços do TCP apri morados com serviços de scrgura nça.

8.5.1

Umo visão obrongente

Começ:un os descrevendo uma versão simplificada do SSL, que nos perm itirá obter uma visão abra ngcme d e 1'0'' que c romo funcion01 o SSL I re mos nos rderir a essa versão simplincada do SSL como "quase-SSL". Após d escrever o quase-SSL, na próxhm\ s ubseção, descreveremos o SSL de verdade, preenchendo ns lac un:~s. O <1uasc· ·SSL (c o SSL) possui trés fases: aprcscntaç,io (lumdslwltc), clcri wrçrlo ele clwvc c trcmsferCncltr tlc clmlos. Agorn des· crcvcrcmos essas três fases para uma sessão de comunícaçào entre u m cliente (Bob) c u m servido r (Alice), o qual possui um par de chave pilbllca!privada e um cen ilk ado que associa sua identidade à ch:tvc pilblica.

Apresentação (Handshake) Dura nte a fase de a presentação, Bob precis a (a) estabelecer uma conexão TCP com Alice, (b) verifi car se Alice é 1calm t'llff Alice, c (c) en viar para ela uma chave sccreLU mestre, que ser:.\ utilí zada por Alice c Bob para criar todas as chaves simétricas de que eles precisam para a sessão SSL. Essas trés etapas estão il ustradas na Figura 8.26. Observe que uma vez a concx:io TCP é estabelecida, Bob en,•ia a Ahcc urna mensagem ~helio" . Alice, cnt:lo, responde com :.cu certificado, q ue ~:ontém sua chave püblica. Conforme discutido na Scç;lo 8 .3 . como o ccrufic-Jdo foi assmado por uma CA, Bob sabe. com certeza. q ue a chave pubhrn no certificado pertence a Alice. Bob então cria um Segredo Mestre (MS) (o qual somente será usado para esta scssolo SSL). codifica o MS com a cha,·e pubhca d e Alice para criar o Segredo Mestre Cifrado (E~15), enviando-o para Alice, que o decodiflca com sua chave privada para obter o MS. Após esta fase, Bob e Alice (c mais ninguém) sabem o segredo mestre para esta scssâo SSL.

Derivoçõo de chove A princípio, o MS, agora compartilhado por Bob c Alice, poderia ser usado como a chave de scss:io simétrica para toda a ve rifl caçâo subscquente de criptografia e integridade elos dados. Ent retanto, geralmente é considerado

mais eguro [)3r:t Alice e Bob usarem, individualmente, clm•es criptográficas diferente . bem romo chaves dife· ren tes para criptograna c vcriO caç-.\o da integridade. Assi m, i\licc c Bob us:11n o MS para criar quatro cha,•cs:

E, - chave de criptografia d e sessão para dados enviados d e Bob para Alice

Camada de a plica çào Aplicação

] Socket TCP( TCP IP

TCP API

IP

TCP a vançado com SSL

Figura 8.25 Emb01o oSSl resido temicomente no comodo de oplicoçõo, do perspectiva do desenvolvedor, ele é um protocolo docomodo transporte


~

TCPSYN

·{. -

-

(t) Criar segredo mestre (MS)

52.3

f1 ..

lC:P/S'(NAo<_ _

-

TCPACK

-

SSt heJto

~

- -- -

(b)


certiflcate

...

---:

·-Decodificar EMS com KA" para obter MS

Figura 8.26 Aopresootoçiio quose-SSL, iniciondo com umo conexão TCP M• • chave MAC de sess•'lo para dados cmriados de Bob para Alice E, • chave de criptografia de sessão paro d:tdos enviados de Alice para Bob M, .. cha,•c MAC de sess.\o paro dados enviados de Alice paro Bob Alice c Bob podem criar quatro chaves a partir do MS. Isso poderia se r feito shnplcsmcntc dividindo o MS em quatro chaves. (Mas na' crd(l(lc, o SSL ~um pouco mais comphcado, como veremos.) Ao final da fase de dcnvação de chave, Ahcc c Bob têm todas as quatro chaves. As duas chaves de cnptogroOa serão usadas para cifrar dados; as duas chaves MAC scr.\o us.1das paro verificar a integridade dos dados.

Transferência de dados Agora que Alice c Bob compartilham as mesmas quatro cha"es de SCSS(\o ( E1 • M1,

c, c M,.), eles podem come-

~-ar a enviar dados protegidos um ao outro por meio da conexão TCP. Como o TCP é um protocolo de nuxo de

bytcs. uma abordagem naturol seria o SSL cifrar dados da aplicação enquanto ~\o enviados c, então, tronsrnitir os dados cifrados pnro o TCP. Mas se f'iz~scmos isso, onde colocarfmnos o MAC para a ' 'erificação da integridade?

Certameme rulo queremos esperar até o fim da sessão TCP para veriOcar a imcgrlcladc de todos os dados de Bob que foram env1ados por toda a scss:\o! Para abordar essa qucstflo, o SSL divide o Ouxo de dados em registros. anexa um MAC a cada registro para a verificação da integridade, e cifra o regisLro+MAC. Para criar o MAC, Bob insere os dados ele registro junto com a chave M8 em uma fun~'llo ele lnsh, conforme discutido na Seção 8.3. Para cifror o pacote registro+MAC, Bob usa sua chave de crlptogmfia de sess:lo E, . Esse pacote dfmdo é ent:'lo transmitido ao TCP paro o tronsportc :nr:wés da Internet. Embora ess.1 abordagem vá longe, o fornecimento de imcgridade dos dados paro um Ouxo inteiro de mensagem ainda m1o é à prova de falhas. Em particular. suponha que Trud)• seja uma mulher no meio c possua a habilidade de inseri r, dclcuu e substituir segmentos no Ouxo dos segmentos TCP enviados entre Alice c Bob. Trudy, por exemplo, poderia capturor dois segmentos envindos por Bob, inverter sua ordem, ajustnr os números de seq u('ncia TCP (que não estão cifrados) e enviar dois segmentos na ordem inversa pnra Alice. Admitindo que cada segmento TCP cncapsula exatamente um rcgislro, vamos \'erificar como Ahce processara a esses scgmcn1os, I . O TCP que esu\ sendo exceULado em Alice pensaria que está tudo bem c passaria os dois registros para a subcamada SSL 2. O SSL ern Alice decriptografaria os dois registros.


3. O SSL em Alice usaria o MAC em cada registro para verificar a integridade dos dados dos dois registros.

4.

o SSL passaria, Cnt;lO, os nuxos de bytes decifrados dos dois registros (I camada de ;tplicaçilo; mas o nuxo de bytes completo recebido por Alice mio estaria na ordem correta devido à invcr:.ão dos registros!

Recomendamos que voct analise cenarios diferentes para q uando Trudy remove segmentos c q uando Trudy repete segmentos. A soluç;lo para esse problema, como você deve ter imaginado, é usar núm eros de sequ~ncia. O SSL os utiliza da scguimemaneira.Bobmant~m um comador demímcrosdcseqm:ncia,qucscinicianozerocvaiaumcmandopamcada

registro SSLque ele envia. Bob, na verdade, não incl ui um número de sequl!ncia no próprio registro. mas no cálculo do MAC. Desse modo, o MAC é agora um hash dos dados mais uma chave MAC M. nwis o numrro de srqurnda atual. Alice rastreia os nu meros de sequencia de Sob. permitindo que ela verillquc a in tegridade dos dados de um registro Incluindo o núme ro de sequência apropriado no cálculo do MAC. O uso de nu meros de scquêncin SSL impede que Trudy rea lize um ataqu e da mulh er do meio, como rcordenar ou repetir os segmentos. (Por qu~?)

Registro SSL O registro SSL (assim co nto o registro quase-SSL) é ilustrado na Figura 8.27. O regis tro consiste em um campo de tipo, um campo de vc rs.\o, um campo de comprimento, um campo de d;tdos c um ca mpo MAC. Observe qu e os primeiros lrê!s cmnpos não estão cifrados. O campo de tipo indica se o registro é uma mensagem

de aprescntaç1\0 ou uma mensagem que comém dados da aplicaçuo. É també m usado pam encerrar a conexão SSL, como discu lido abaixo. Na extremidade receptora, o SSL usa o campo de comprimento p:1m extrair os registros SSL do nuxo d e by1e TCP de entrada. O campo de vcrs.'\o não prccis:1 de explicaçót-s.

8.5.2 Umo visão mais completa A subseção antcr.or abordou o protocolo q uasc·SSL: serviu para nos dar uma comprecns:lo básica de por que c como funciona o SSL Agora que lemos essa comprccnslo básica sobre o SSL, podemos nos aprofundar mais c cxam mar os pri ncfpios básicos do verdadeiro protocolo SSL. Além da leitura dcsli\ dcscriç;lo sobre o SSL. recomendamos que você co mplete o Wireshark SSL lab, dis ponível no comp.1nion Wcb !>i te d este livro.

Apresentasõo SSL O SSL n;\o n:lo exige que Alice c Bob usem um algorillliO especifico de chave simétrica, um algori tmo cspectfico de ch:wc püblic:a ou um MAC especifico. Em vez disso. o SSL pcrn11tc que Alice c Bob combinem os algori un os criptogr:\ficos no início da scss\o SSL, durante a fase de aprcsent::~ção. Ade mais, dumnte a fase de aprcsc nt aç:lo, Alice c Bob envia m noncC's um ao outro, que silo usados na criação de chaves de sess:1o (E1 , M0 , EA c M"), As etapas dn verdade ira t1prcscmac;iio SSL sào: I. O cliente envia

um;~

lista de algoritmos criptográficos que ele Sltporta, junto co m um nonce do cliente.

2. A partir dt1 lista, o servidor escol he um algoritmo simétrico (por exemplo, AES), um a lgori tmo de chave

púbhca (por exemplo, RSA com um com primemo de c have esp;:cffico) e um algor itmo MAC. Ele devoh•c ao clien te suas c:scolhas, bem como um ccrúfic:~do c um noncc do servidor.

3. O client e vcririca o ccnincado, extmi a chave pública do se rvidor , gera um Segredo Pré-Mestre ( PMS), c irra o PMS com a chave püblica do servidor e envia o PMS cifr:1do ao servidor.

Tipo

Versão

Compri·

mento

Dados

Codificado com E8

Figura 8.27 formoto de registo poro oSSL

MAC



525

4. Utilizando a mesma fun\"ào de derlvaç-lo de chave (corlforme especificado pelo padr.lo SSL), o cliente e o scrvrdor compumm independentemente o Segredo Mestre (MS) do PMS c dos nonccs. O PMS t então dividido para gerar as duas chaves de criptografia c duas chaves MAC. Além disso, quando a cifra simé· trlca selecionada emprega o CBC (como 3DES ou AES), os dois Vetores de lnicializaç-Jo (JVs) - um para cada lado da conex.lo- S:lo uunbém obtidos do PMS. De agora em drantc, todas as mensagens enviadas entre o cliente e o servidor são cUradas c autenticadas (com o MAC). 5. O cliente emia um MAC de 10das as mensagens de apresentaçolo. 6. O servrdor envia um :vtAC de todas as mensagens de a prcsentaç-.lo.

As duas úhirnas etapas protegem a aprcsenração da adulteração. Para entender isso, observe que no passo 1, o cliente normal me me oferece uma lisra de algoritmos- alguns fortes c outros fracos. Essa lista é enviada em texto aberto, visto que os algorilmos de criptografia c chaves aluda m\o foram conscmidos. Trudy, corno uma mulher no rneio, poderia delctar os algoritmos mais fortes da lista, obrigando o cliente a selecionar um algoritmo fraco. Para cvi1.1r o r11:1que de adtlheraçào, na etapa 5o cliente envia um MAC da concatcnaçi\o ele todas as mensagens de at>rcscntaç:\o que ele erWOll c recebeu. O scn·idor pode comparar esse MAC com o MAC das mensagens de aprcscnuw:\o que ele enviou c recebeu. Se houver uma inconsist~ncia. o servidor pode On:rlizar a conexão. De mancim semelhan te, o servidor envia um MAC das mensagens de apresentação que encontrou, pcrmilindo que o cliente verifique a presença de inconsistencias. Voe~

pode estar se perguntando. por que existem nonces nas etapas 1 e 2? Os m'un cros de sequencia S:lo sul'icicmes para previnir o ataque de rcpcriç-;lo de segmcmo? A resposta ~sim , mas eles não previnem sozinhos ~o ataque de

rcpctiçao de segmento~. Considere o seguinte au1que de repcti~\o de egmcnto. Suponha que Trud)'

analrsc todt\S as mensagens entre Alícc c &b. No dia seguinte, Trudy se passa por Bob c crwia a Altce exatamente a mesma segul!ncia de mensagens que Bob envou a Alice no dta a menor. Se Ahcc n~o usar os nonces, ela responder:\ com exatamente a mesma sequ~ncia de mensagem que cn,iou no dia anterior. Alice n:\o :.uspcit:tr.\ de n;\da esrmnho, pors cada mensagem que ela recebe passar:\ pela verificaç-.lo de integridade. Se Alice for um servidor de comércio clctrõmco, ela pensam que Bob está demando um segundo pedido ( para exatarneme a mesma coisa). Por outro lado, ao lnclurr um noncc no protocolo, Alice enviará nonces difercmcs pam cada scss:1o TCP, fazendo com que as chaves de criptogl'llfia sejam diferentes nos dois dias. Portanto, quando Alice recebe os rcgisrros SSL repetidos de Trud r . eles falhtui\o na verificaçolo de integridade, c a tmns:w;\o do si re de cornérc10 eletrônico falso não acontecer:\. Em resumo, no SSL, os nonces são usados para proteger o ~ataque de repetição ele conexão•, e os números de sequl!ncia são usados para defender :t reperit;.lo de pacorcs mdividuars durante uma sess:lo em andamento.

Encerramento de conexão Em algum momento, Bob ou Alíce desejarão finalizar a sessilo SSL. Um método seria deixar Bob finalizar a sess
bow4tto4ic~ Redes de com pu tod ores e o Inler.;;n.;;, e;.. l------------------------

8.6 Segurança no camada de rede: IPsec e redes virtuais privados O protocolo IP d~ segurança. mais conhecido como lPscc, pro,-ê segurança na camada de rw~. O IPscc protege os d;nagramas JP entre quaisquer entidades da camada d~ rede, incluindo hospedeiros c rotcadores. Como descreveremos em breve. muitas instituições (corporações. órglos do governo. org.mizaçõl'l> sem fins lucrativos etc.) usam o IPscc para cnar redes virtuais privadas (VPNs) que executadas por meio da Internet pública. Antes de ralar sobre o IPsec, '"::mos ''oh ar c considerar o que sigmf1ca prover s•gllo na camada de rede. Com o sigilo da camada de rede entre u m par de entidades da rede (por exemplo, entre dois rotcadorcs, cmrc dois hospedeiros, ou entre um roteador c um hospedeiro}, a entidade remetente cirra as carga:. úte is de todos os datagramas que envia à emidade destin;nária. A carga útil cifrada podena ser um segmento TCP, um segmento UDP c uma mensagem ICMP etc. Se esse serviço da camada de rede esuvesse em funcionamento, todos os dados de uma ent idade a outra- incluindo e-mail . páginas Wcb. mensagens de aprcscnta\i\0 TCP e mensagens de gcrcnciamcrllo (co mo ICMP c SNMP)- estariam ocultos de qualquer terceira parte que poss-1 estar :malis.1ndo a rede. Por esta r.1z~\o, a segurança na t.--amada de rede é conhecida por prover ~cobert ura to tal". J\ lém do sigilo, um protocolo de segurança da camada de rede poderia potcnci:1lmente prover outros servi~ ços de segurança. Por exemplo, ele pod eria romecer atllentícaçâo da fon te de modo que a en tidade destina tária possa verUkar a ron te do datagmma protegido. Um protocolo de scgu ran~·a da c:amada de rede poderia o ferecer integridade dos d:~clos, de modo que a entidade destinatária poderi:~ verincar qualquer ~ldulteraç;\o do da tagrama que pudesse ter ocorrido enquamo o datagrama eslava em trlnsito. Um serviço de segu rança da camada de rede também poderia oferecer a pre,•enç:lo do ataque de repe tição, q uerendo dizer que Sob poderi:1 detectar quaisquer datagramas duplícados que um atacante possa inserir. Veremos em breve que o IPsec prove mecanismos para todos esses serviços de segurança, ou seja. para sigilo, auteni1C'.tc;<1o ela fonte, integridade dos dados c prevenção do ataque de repetição.

8.6.1

IPsec e redes virtuais privadas (VPNs)

Uma instituiç;)o que se estende por d iversas regiões geográficas muitas vezes deseja ter sua própria rede IP, para que seus hospedeiros e servidores possam enviar dados um ao outro de urna man~ira segura e sigilosa. Para alcançar essa meta, a instituição poderia, na verdade, empregar uma rede física mdcpendente- incluindo rotca· dores. enlaces c uma infraestrutu ra DNS- que é completamente distinta da Internet publica. Essa rede disjunta. reservada a uma institu içlo particular, é chamada de rede privada. Como é de se esperar , uma rede privada pode ser muito cara, jd que a instituiÇ{\o precisa comprar, instalar e manter sua própria infraestrmu ra ele rede física. Em vez de implementar e mante r uma rede privãda, hoje muitas Instituições criam VPNs a partir da lrHernet publica existente. Com uma VJ>N, o tráfego interdepaWlmcntal é cm•iado por meio da Internet p tíblic:l c não ele uma rede fisicamen te Independente. Mas para prover sigilo, o tráfego Interdepartamental é crlptografado antes ele entmr na Inte rnet pública. Um exemplo simples de uma VPN ê mo Lrado na Figura 8.28. t\q ui, :~ institui(ilO consiste em unm mm riz. uma filial c vendedores viajantes, que nonn:1lmente accss.un a Intern et do seu quarto de hotel. (A fi gura mostra somente um vendedor.) Nesta VPN, quando dois hospedeiros dentro da matriz enviam datagramas IP um ao outro ou quando dois hospedeiros dentro de uma filial qut'rcm se comunic:ar, eles usam o bom c vel ho 1Pv4 (ou seja. sem os serviços IPscc.}. Entretanto. quando dois dos hospedeiros da institui~·üa se comunicam atr:\\'~ de um t.-ami nho que cruza a Intcrnct pública, o tnífego é codificado antes de entrar na Internet. Para entender como a VPN funciona, vamos examinar um exemplo simples no contexto da Figura 8.28. Quando um hospedeiro na matnz cnvmum datagrama IP a um vendedor no hotel, o roteador de borda na matriz converte o d:uagrama IP,..f em um datagrama IPsec e o encaminha à Internet. Esse datagrama IPsec, na verdade, possui um cabeçalho 1Pv4 tradicional, de modo q ue os roteadores na Internet publica processam o datagrama como se ele fosse um datagrama 1Pv4 comum -para eles. o da tagrama é perfeitamente comum. Mas. conforme ilustrado na Ftgura 8.28. a carga uhl do datagrama IPscc Inclui um cabeçalho IPsec, que é uti hzado para o processamento do IPsec; além disso, a carga útil do datagrarna IPsec está codificada. Quando o datagrama IPsec chegar ao laptop do vendedor, o OS no Laptop decodifica a carga úúl (e provê outros serviços de segurança, como



52.7

Laptop com IPsec

cabeçalho cabeçalho carga útil IP

IPsec

Vendedor

no hotel

segura

Roteador Cabeçalho Cabeçalho Carga út il IP

IPsec

segura

com 1Pv4 e

carga útil

IPse<

Internet pública

cabeçalho cabeçalho carga útil IP

IPsec

segura

Cabeçalho

carga útil

IP

Figuro 8.28 Rede Vil1uol Privado (VPtl) a verificação da integridade dos dados) e passa a carga útil não codificada para o protocolo da camada superior (por exemplo, para o TCP ou UDP). Acabamos de dar uma visão geral de alto nível de como u ma institui'-lo pode implememar o IPscc para criar uma VPN. Para compreender a Oortsta por entre as árvores, deixamos de lado muitos detalhes importantts. Vamos agora dar uma olhada neles mais de peno.

8.6.2 Os protocolos AH e ESP O lPscc é um urn material um tanto complexo - de é defi nido em mais d e uma dúzia de RFCs. Dois RFCs ímponames são RFC 430 1, o qual descreve a arquitetura de segurança IP geral, c RFC 2411 , que romccc uma vis.''io geral dos protocolos !Pscc. Nossa meta neste livro, como de coswmc, não é simplesmeme reproccss<''lr os RFCs secos e complexos, mas ra zcr um:\ abordagem mais operacional e pedagó~ica para descrever os pro tocolos. No conjunto dos 1>rotocolos IPscc, existem dois protocolos principais: o pro tocolo Cabeçalho de Auu:ntlca<;tlO (AH) c o protocolo Carga de ~gurança de Encapsulamento (ESP). Quando urna cmidadc rem etente IPscc (nor· malmcrue um hos pedeiro o u um roteador) envia datagramas seguros a uma cntld:~dc destin:H:\rla (1ambém um hospcdeire> ou urn roteador), cl:~ utiliza o protocolo t\1·1 ou o protocolo ESP. O protocolo AH prov~ autenticação da fonte c intcgriclade dos dados mas mlo provê sigilo. O protocolo ESP provê :mlcntic
8.6.3 Associações desegurança Os datagramas IPscc são em'iados entre pares de entidades da rede. tal como entre hosped eiros, emre dois roteadores, ou entre um hospedeiro e um roteador. Antes de enviar datagramas lPscc da entidade rementente à enlidade destinatária, essas entidades criam uma conexão lógica da camada de rede, denominada associação de

bow4tto4ic~ Redes de co 111 pu tod ores e o Inle r ne~'------------------------segurança (SA). Uma SA é uma conexão lógica simplcx: ou sejõl, ela ê uuidirccional do reme teme ao destinatário. Se as duas entidades querem enviar datagramas seguros uma a outra, então duas SAs (ou seja, duas conexões logicns) precisam ser estabelecidas. uma em cada di reção. Por exemplo, considere mais uma vez uma VPN insti· tucional na Figura 8.28. Essa instillliçM consiste em uma filial. uma matriz c. digamo:., 11 vendedores ' 'iajantes. Por exemplo, vamos supor que haja tráfego IPscc bidirccional entre a matriz c a filial c tráfego JPsec bidircc10nal entre a matriz c os vendedores viajantes. Existem q uantas SAs nessa VPN? Para responder essa questão, observe que há duas SAs entre o rote:~dor de borda da matriz e o roteador de borda da filial (uma em cada direçilo): para cada laptop do vendedor. M dlll\5 SAs entre o roteador de borda da matriz e o laptop (nov:uncntc. lima em cada direç'.\o). Portanto. no total, há (2 ~ 2n) SAs. Mantenha em llll'ntr, rntrrta11to, qur 111'111 todo o trtlfego e11viado à lncnnet J'dos r·ocrador rs de borda ou pelos l('l'IOJ'S será de lPsec seguro. Podemos citar como exemplo um hospedeiro na m:urtz que quer acessar ao servidor \Vcb (como Amazon ou Googlc) na Internet pública. Assim, o roteador de borda (c os l:lptops) emitimo na In ternet os datagramas 1Pv4 comuns c os dat:1gramas IPscc seguros. Vamos agora olhar "por dentro" de uma SA. Para tornar essa discussão tanglvel c concreta, ut ilizaremos o corucxto
193.68.2.23) O tipo de criptografia a ser usada ( por exemplo. 3DES com CBC)

A chave de criptografia O tipo de verifk-açào de integridade (por exemplo. HMAC com MOS)

A eh:~ve de autenllcaç:lo Quando um rotCõldor precisa construir um datagrama IPscc para cncaminh:u a1ravés dessa SA, ele acessa essas informações de estado p:~rn de1enninar como deveria autenticar c cnptograf:~r o datagrnma. De maneira semelhante, o rotc:~dor R2 manter:i as mesmas informações de estado sobre essa SA e as usará para :~utenticar e decrip1ografar qualquer datagrnma IPsec que chegar da SA. Uma enudade IPsec (roteador ou hospedeiro) muitas vezes guardam essas informações de esmdo para muitas SAs. No exemplo sobre a VPN na Figurn 8.28 com n vendedores, o roteador de borda guarda mfom1açõcs de estado para ( 2 + 2n) SAs. Uma en tidade IPscc armazena as Informações de es1ado para todas as s uas SAs em seu Banco de Dados d e Associação de Segurança (SAD). o qual é uma estruturn de dados do núcleo do sis1ema opemcion ai.

8.6.4 Odotogromo IPsec Após descrever sobre asSAs, podemos agora descrever o verdadeiro datagmrn:~ IPsec. O IPsec poss ui d uas formas diferen tes de pacotes, uma p;u;\ o modo t(mcl c outra p
Matriz

Filíal

Internet

172.16. 1124

Figura 8.29

AssO(ioçõo de Segurança (SA) de Rl o R2

172.16.2/24



529

s uas complexidades, a partir de agora nos focaremos exclusivamente no modo u.lncl. Uma vez que vocf tiver uma comprecnsi.lo sólida do modo tuncl, voe~ poderá facilmente aprender. por sua conta. o modo tra nsporte.

O formato do p
ESP~;

o pacote res ul-

Cria uma autenticação MAC por toda a enchilada usando o algoritmo c chave especificados na SA Anexa a Mi\C :ll r:ls da cnchilada, formando a cm·ga ti til. Por rim, cria um cabeçalho IP novo com todos os campos d e ca beçalho 1Pv4 cl~ss i cos Quntos normalmente com 20 bytcs de comprimento), o qual se anexa antes da carga utll. Observe que o datagmnm IP resultante f um aut~ntico datagrama 1Pv4, com os tradicionais campos de cabeçalho 1Pv4 acompanh:tdos por uma carga lhíl. Mas, neste caso, a carg:1 thll comém um cabeçalho ESP, o datagrnrna IP origmal, um tratlcr ESP c um campo de autenttcação ESP (com o datagrnma onginal e o trailer ESP cifrad os). O datagrama IP origi nal possui o endereço IP remetente l 72. l 6. l.L 7 c o endereço IP destinatário L72.16.2.48. Em razilo de o datagrama IPsec incluir o datagrama LP o riginal. ~cs endereços Silo inclusos (c Cifrados) como parte da carga util do pacote l Pscc. Mas c os endereços JP remetente c destinatáno que esti.lo no novo cabeçalho IP, o u seja. o (.';I beça lho localizado à esquerda do datagrama IPsec? Como vocf pode esperar, eles são estabelecidos para as interfaces do roteador remetente e destinal:lno nas duas extremidades dos nmeis, isto ~. 200.168.1.100 c 193.68.2.23. Além d isso, o número d o protocolo nesse novo campo de cabeçalho 1Pv4 não será o numero do TCP, UDP ou S:vtTP, mas igual a 50, detenninando que esse é um datagrama IPsec que está utilizando o l>rotocolo ESP. Após RI en vi:1r um d:~Lagmma IPscc à lmemet pública, ele passará por dh·crsos roteadores ames de chegar ao R2. Cada um desses roteadores processará o datagrama como se fossem um dmagrama comum - eles são completamente inconscientes do fato de que o datagmma está transportando dados cifrados pelo IPsec. Para esses roteadores da Internet pública, como o endereço IP remetente no c:1bc~·alho externo é R2, o destino final do dôlwgrama é R2. Após acompanhar um exemplo de como o clatagrama IPsec é construído, "amos olhar de perto os ingrediel1tcs cl:1 cnchilada. Ve mos na Figum 8.30 que o trailer ESP consiste em tr~s campos: enchimento, tamanho do " Enchitada" autenticada I

I Novo C
Cabeçalho (a~tho ESP originaltP

SPI

Seq t

Figura 8.30 Formato do dotogromo IPsec

Cifrado I Carga Vtil do datagrama IP original

Tr<1íter ESP

ESP MAC

bow4tto4ic~ Redes de com pu tod ores e o Inler.;;n.;;, e;.. l-----------------------enchimento c próximo cabeçalho. Lembre-se de que clfras de bloco exigem que a mensagem a ser cifrada seja um multi pio inteiro do comprimento de bloco. O enchimento (que consiste de bytes insigmficantes) é usado de modo que quando adlcronado ao datagrama original (junto com o tamanho do enchimento e próximo cabeçalho) . a "mensagem· resultante seja um número inteiro de blocos. O campo tam:mho do cndumento l!ldrca à entidade destinatária quanto enchimento foi inserido (e, portanto. prccis., ser remo,•ido). O próximo C1lbeçalho identifica o tipo (por exemplo, UDP) de dados contidos no campo de dados da carga util. Os dados da carga util ( normalmente o d:uagrama IP original) c o trailer ESP são concatenados e, então, cifrados. Anexado na frente dess., unidade cifrada está o cabeçalho ESP. o qual é enviado em aberto c consrstc em dois C'Jmpos: o SPI c o <.--:u npo de número de sequencia. O SPI indica à entidade destinaturia :1 SA à qual o datagrama pertence; a em idade destinatária pode, então. indexar seu SAD com o SPI para determinar os algoritmos e chaves apropriados de autenticaç-.lo/decriptação. O campo de número de scqucncm é usado para proteger ataques de rcpetiçâo. A entidade remetente também anexa uma autenticação MAC. Como afirmado anteriormente, a entidade rern etcm c calcul:1 um MAC por toda a enchilada (que consis te em um cabeçalho ESP, o data grama IP original c o trailer ESP- com a criptografia do datagrama e do trailer). Lembre-se de que para calcular um MAC, o remete me :mexa uma dHwe MAC secreta 1\ cnchilada e calcula um h:tSh de tamanho nxo elo resu ltado. Quando lU recebe o datagrama IPscc. ele observa que o endereço IP destlnat~lrio do datagr:un:• é o próprio R2, q ue, então, processa o datagrama. Como o campo de protocolo (no t'llbcçalho IP :\esquerda) é 50, R2 cnten· de que deve aplk·ar o processamento IPscc ESP ao datagmrna. Primeiro, alinhando na enchilada. E2 usa o SPI para determinar à qu:1l SA o datagrama pcnence. $(:gundo, ele calcula o MAC da cochilada c vcrifiC1l se o MAC é compauvcl com o valor do campo MAC ESP. Se for, ele sabe que a enchilada vem de Rl e que não foi adultcrnda. Terceiro, de verifica o C1lmpo mlmero de scquência para ver se o datagrama é no,•o (e não repetido). Quarto. ele decodific-a a umdadc cifrada utilizando o algorilmo c a chave de criptografia associados à SA. Quinto. ele remove o enehm1cnto c cxtmi o datagrama IP o riginal básico. E. fi nalmente. sexto, ele encaminha o datagrama original a rede da fihal em dire~"":lo a seu destino final . Ufa, que receita complicada. n:\o é? Ninguém disse que era fácil prcparaT c desvendar uma cochilada! Ka verdade existe outra importante sutileza que precisa ser abordada. Ela se baseia na seguinte questão: Quando RI recebe um datagrama (inseguro) de um hospedeiro na rede da matriz, e esse datagrama é destinado a algum endereço IP destinatário fora da matriz, como RI sabe se ele deve ser convertido em um datagrama IPsec? E se ele vai ser processado por um IPscc. como Rl Sllbe qual SA (de muitas SAs em seu SAO) deve ser uSllda para construir o datagrama IPscc? O problema é resolvido da seguinte maneira. Junto com um SAD, a entidade IPsec também mantém ou tra estrutu ra de dados denomrnada Banco de Dados de Polllica de Segurança (SPD). O SPD indica que tipos de datagramas (como uma função do endereço 11' remeten te, endereço IP dcstlnalilrio c tipo do protocolo) ser;\o processadas pelo IPsec; e para aqueles que serão processados pelo IPsec. qual SA de\•e se r usada. De cena forma, as Informações em um SPD lndícarn ~o que" fazer com um datagrama qu e es tá chegando: as informações no Sr\D inclic:.m "como" r11zer isso.

Resumo dos serviços IPsec Quais serv i ~·os o IPscc prov~. exa t<~mcnte? Vamos c.'OillO de vista de um lltacame, diga mos Trudy, que é uma mulher no meio, situada no caminho entre RI c R2 na Ftgum 8.29. Suponh


531

tente se pass.1 r por R l , criando um datagmma IPsec com remetente 200.168. 1.1 00 c destinatário 193.68.2.23. O ataque de Trud)• será inutil, pois a verificação da integridade do datagmma em R2 f:~lh ará nov.unente. Por fim, em raz;lo de o IPsec incluir números de sequenci:t. Trudy não poder.\ criar um at:~que de repcti\'ilO bem-sucedido. Em resumo. conforme afirmado no inicio desta seção. o IPsec prov~- entre qtmlquer par de dispositi\•os que processam pacotes através da camada de rede- sigilo, autenticação da fonte, integrid ade dos dados e proteção eomra ataque de rcpeliç;lo.

8.6.5 Gerenciamento de chove no IPsec Quando uma VPN possut um número pequeno de pontos finais (por exemplo. apcn:~s dois roteadores como na Figura 8. 29), o admin í$trado r de rede pode inserir m:mualmcnu.• infonnaçOcs sobre aSA (algoritmos e chaves ele crlptografl:llautcnti ca~':lo c os SPls) nos SADs dos pontos d e chegada. Essa ~ teclage m ma nual• é claramcmc imprntic:\vcl parn urna VPN grande, a qual pode consisti r em centenas ou mesmo milhares de ro teadores c hospedeiros IPscc. lmplcmentaçOes grandes c geograficamente distribu ídas exigem um mecanismo aw omátlco para a criaç:\o das SAs. O IPsec o raz com o protocolo de Troca de Ch:we (II
emprega duas rases para realizar essas tarefas. Vamos investigar essas duas fases no comexto de dois ro teadores, R l e R2, na Figura 8 .29. A primeira fase consiste em duas trocas de pnrcs de mensagem entre RI e R2: Durante a primeira troca de mensagens. os dois lados usam Diffíc-llellm:tn (consulte os Problemas) pnm criar um IKE SA bidlrccional emre os roteadores. Para nos confundir, esse IKE SA bidirecional é towlmente dtferentc da SA IPsec disculida nas Seções 8.6.3 c 8.6.4. O IKE SA prove um canal cifrado c autenticado entre os dois roteadores. Durante a primeira troca de par de mensagem. as chaves s.\ o esta· bclcctdas p:1m a criptografia c autcnllcaçào paro o IKE SA. Também t estabelecido um segredo mestre que: ser:l tiSado para computar c:ha,·es SA !Psec mais adiante na fase 2. Observe que durante a primrira etapa, as chaves públicas c privadas RSA não s:lo usadas. Em particular, nem Rl nem R2 revelam sua ident id~de nssinando umn mensagem com sua cha ve privada. Durante a segunda troca ele mensagens, ambos os lados revelam um ao outro sua identidade assi nando su:IS mensagens. Entrct:mto, as identidades n:\o s:lo reveladas a um analisador passivo, ''isto que eles

s:\o enviadas ::nravés de um canal seguro IKE SA. Também dut.lnte cSSt fase. os dois lados negociam os algor itmos de auten ticaÇ
8.7 Segurança em lANs sem fio Segurança é uma preocupaç:\o impon:tme em red es sem fio, onde as ondas de r:ldio carregando qu ad ros podem propagar mullo além da construção contendo os hospcdctros c as estaçOcs base sem fio. esta seção apresentaremos uma breve introdução em segurança sem fto. Para maiores informações, veja o altamente recomendado livro de Ed ney c Arbaugh !Edney, 2003).

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------O tema de segurança em 802.11 tem auaído muita atenç.lo em drculos t~cnicos c na m!dia. Apesar de discussões considernveis terem sido feitas, poucos debates foram feitos- parece existir um entendimento uni,•ersal de que a espccrficaçào 802.121 original comém uma série de falhas graves na segurança. De fato, podemos fazer o download de soft\\arCS de domrnio público que tiram pro"eho dessas falhas, fazendo com que ;tquelcs que usam mecanismos de segurança 802.11 comuns fiquem expostos a ataques de segurança tanto quanto aqueles que não usam nenhum tipo de atributos de segurança. a sc~o seguinte, drscuurcmos os mecanismos de segurança inicralmcntc padronizados na especificação 802.11 , conhecida coleu,·:uncntc como Privacida de Equivalen te Cabeada (WEP, do mgles \Virrd Equh•alrm Privacy). Como o nome s ugere, a WEI' tem como propósito fornecer um nrvcl de segumnca semelhante ao que é encontrado em redes cabcadas. Então, discutiremos algumas falhas de scgur.mça da WEP e exammaremos o padnlo 802.1li, uma \'Crs\o fund:uncntalmcntc mais segura do que 802.11, adotado em 2004.

8.7.1

Privacidade Equivalente Cabeodo (WEP)

O protocolo IEEE 802.11 WEP IIEEE 802.11 20091 fornece autenticação c criptograna de dados entre um hospedeiro c um ponto ele at·esso sem fio (ou seja, a estaç:1o base) usando uma abordagem de chave compartilhada simétrica. A \\IEP n:lo especifica um gerenciamento ele algoríuno de chave, cnt:lo supomos que o hospedeiro c o ponto de acesso sem no de alguma forma concordam sobre a chave atnw~s do método for.t-cle-banda. A autcnticaç;'o é realizada como segue: l . Um hospederro sem no requisila uma amemicaç~o por um pomo de acesso. 2. O pomo de acesso responde à requis isç1o de autcnticaçào com um \':llor de 128 bytcs noncc. 3. O hospedeiro sem no criptografa o nonce usando uma cha,•e simétrica que compartilha com o pomo de acesso. 4. O ponto de acesso decriptografa o nonce do hospedeiro criptografado. Se o nonce decriptografado for compau"cl com o va.lor noncc originalmente cn,•iado ao hospedeiro. então o hospedeiro é autenticado pelo ponto de acesso.

O algoritmo criptogmf:~do de dados WEP é ilustrndo na Figura 8.31. Uma cha\'C sunétrica secreta de -10 bits. presumidamente conhecida por ambos, hospedeiro c ponto de acesso. Além disso, um Vetor de Inicialização (IV. do ingl~s luiticlli~lltiou Vcctor) de 24 bits é anexado a uma chave de -+O bits pam criar uma chave de 64 bits que ser:lo usados para criptografar um único quadro. O IV mudar:l de um quadro para o outro, e, por consegttinte. cada quadro ser:! criptografado com uma chave de 64 bits diferente. A criptografia~ cfctuadn como segue. Primeiramente, um valor de 4 b)•tcs de CRC {veja a Seção 5.2) é calculado para :1 carga t\t il ele dados. Então, :1 carga tttil c o CRC ele quatro bytcs silo crlptografados usando uma cifra de fluxo RC4. N;lo veremos os detalhes de um RC4 aqui (veja ISchncier, 1995) e l Eclncy, 2003) para mais lnformaçOcs). Para nossos objeti vos, é suficiente saber que, qu<~ndo o valor ele urna chave (nesse caso, a cha ve de 64 bits IK,, l VI) ~ aprescmado ao algoritimo RC4, este produz um fluxo de V
IV (por quadro) Gerac:klr de sequência de chaves (J)
~:chave simétrica secreta de 40 b iu

kN krv k] ... k: li 12

Quadro de dados em texto aberto mais CRC

I

I

er

e

e

d,

d2

d) "'dH

I

I

I

I I

I

I I

e I

I I

k~.. ... k~... I

e I

CRC 1 I

I

+ + + + + c, Cz

Figura 8.31

Protocolo 802.11 WEP

C) ... CN

(N+1

I

ED I

... CRC.,

I I

+

... C,.-..c

Cabeçalho 802.11

IV

Dados criptografados por WEP mais CRC



533

ness.1S opcra~Ocs como se fossem executadas em um bytc por vez. A cripLOgraria é realizada por OU-exclusivo no 1-ésimo bytc de dados. di, com a i-ésima chave, 11,' . no Ouxo de valores de cha\•CS produzido pelo par (K,. IV) para produz1r o i-éSimo b)•te do texto cifrado, c,:

c, .. <1, ® 11,' O valor de IV muda de um quadro ao próximo e é incluído no tr.~to abCIIo do cabeçalho de ""da quadro criptografado·\VEP 802.11 , como mostrado na Figura 8.31. O receptor aceita a chave simetrica secreta de 40 bits que compartilha com o transmissor, anexa o IV c usa a chave de 64 bits rcsult:mte (que é id~nt ica a chave usada pelo transmissor para executar a criptogmJia) para decriptografar o quadro: d, =c,® 1::' O uso adequado do :tlgoritimo RC4 necessita que o mesmo valor da chave de 6<1 b1ts nw•cc1seja usado mais de uma vez. Lcmbre·SC de que a chave WEP muda em uma base quadro a quadro. Para um determinado K,. (que muda em rams ocasiões). isso signillca que existem somente 2:• chaves l\nicas. Se essas chaves s.lo escolhidas de modo aleatório, podemos mostrar IWalker, 2000; Edney, 20031 que a probabilidade ele ter escolhido o mesmo valor de IV (c, r><>rtmuo, usado a mcsn'l(l chave de 64 bits) é de mais de 99 por cento depois de somente 12.000 quAdros. Com lllll quadro de L Kbyte c a tmnsmiss.lo de dados de \'Ciocidadc l i Mbps. somente alguns segundos são necessários ames CJUC 12.000 quadros sejam tmn.smitidos. Além do mais, jl\ que lV é transmitido em texto aberto no quadro, um curioso saberá quando um valor duplicado for usado. Para notar um dos vários problemas que ocorrem quando uma chave duplicada é usacl:1, considere o S(lguimc ataque ao texto aberto escolhido pela Trudy à Alice. Suponha que a Trud)' (usando provavelmente uma falsifiC"d~lo de IP) env1a uma solicitação para Alice (por exemplo, uma solicitação hup ou uma soli cita~o FTP) para transmitir um arquiVO de conteúdo dedamdo. cl,. ''~· cl1, cl~ ... A Trudy também nota os dados criptografados C1, c1 • ' ~" c, ... já que cl, • c, $ lt,", se OU-exclusivo c, com (.':Ida lado d~ igualdade. teremos d, .. c, ® 11,'

Nesta rcla~llo. a Trudy pode usar os valores conhecidos de di e cl para t.-alcular k:'. Da próxima vez que a Trudy v1r o mesmo \':llor de VI sendo usado, ela saberá a scqu~ncia de chave 1::' . 1:~'. lt~' .... c assim será capaz de decnptografar a mensagem criptogmf:tda. Existem outras diversas preocupações adicionais sobre a seguran~ da \'VEP. lfluhrer, 20011 descreve um ataque aproveitando-se de uma fraqueza conhecida em RC4 quando certas chaves s:lo escolhidas. (Swbblcficld, 20021 discute maneims cricazcs de programar e tirar proveito deste ataque. Outra preocu pa~o com a \VEP envoh•e os bits CRC. mostrados na Figura 8.31. e tmnsmitldos no quadro 802. 11 para detectar bits alterados na carga útil. No entanto, um :uacante que muda o conteúdo criptografado (por exemplo, substituindo ttxtos in inteligíveis por dados criptografados originais), calcula o CEC através de textos mintehgiveis c coloca o CRC em um quadro WEP, pode produzir um quadro 802. 11 que será aceito pelo recelltor. O que é necessário nesse caso :>fiO técnicas de intcgrid:tdc de mensagem como aquelas estudadas na Sc~'t10 8.3 para detectar intcrcepçOes físicas de simll ou substltui ~·ocs. Pam maiores informações sobre segurança da WEP, vej a IEducy, 2003; Walker, 2000; Wcatherspoon. 2000; Scgu r:m~a 802.11 20091 c as refcr~ncias nestes a esse respeito.

8.7.2 IEEE 802.11i Logo após o lançamento do IEEE 802.11 em 1999, o tmbalho no desenvolvimento de urna vc~io nova c aprimomda do 802.11 . com mct-anisrnos de segurança mais fon es. começou. O novo padr.\o, conhecido como 802.1 I i. passou por uma ratifiC:I\.lO rinal em 2004. Como veremos. enquanto a WEP fornecia uma criptografi:t relativamente fraca , somente um meio de executar autcntica~lo c nenhum mcc-.mismo de dlstribui('àO de chaves, o IEEE 802. 111 fornece formais muito mais fortes de criptografi.t , um conjunto extenso de mecanismos de autcn· tíc-.lçlo e um mecanismo de distrlbuí~llo de chaves. A segulr, apresentamos uma smtcsc do 802.l li; um excelente panorama t~cnico (em Ouxo de áudio) sobre 802.111 é (TechOnhnc. 20041 . A Figur" 8.32 dá uma visão geral sobre o enquadramento 802.lli. Além do cliente sem fio e do ponto de acesso, 802.lli define um servidor de autenúcação, com o qual o AP se comunica. Separar o servidor de comuni-


STA: cliente

AS: servidor de autenticaçAo

AP:

estaç~o

ponto de acesso

Rede com fio

(D Descoberta de capacidades de segurança

0

autenticam-~e

STA e AS mutuamente, juntos geram a Chave Mestra (Master Key- MK). AP funciona como "passagem H

0

STA deriva Chave Mestra do par (PMK)

0

AS deriva a mesma PMK. envia a Af>

@ STA, AP usam PMK para derivar Chave

Tempor
r~guro

8.32 802.1 1i: quolro fases de operação

caçao do AP permite que um ser.•idor de autenticação sir.'a muitos APs. centralizando as decisões (frequentemente scrlSívcrs) relativas~ autcnticaçllo e acesso dcnuo de um ún ico servidor. c derxando os custos c a complexidade do AP menores. 802.llr opera em quatro fases:

J.

Dcscobcr ter. a fase de descobrimento, o AP anuncia sua presença c as formas de autcn ticaç;lo c criptografia que podem ser fornecidas ao nO do cliente sem fio. EnlõlO, o clrentc soltcita as formas específicas de autenticaçilo c criptOgrafia que deseja. Apesar de o cliente c o AP já estarem trocando mensagens, o cliente ainda n:lo foi autenticado nem tem uma chave criptografada, cm:lo vários passos ainda ser-.lo nccess:\rios antes q ue o cliente poss.'l se comunicar com um hospedeiro arbrt.rário remoto através de um canal sem no.

2.

Arur ntíccr,clo 11111111cr e guaçclo du Clull'l' Mrslm (MK). A autcntic;rçào ocorre entre o cliente sem fio e o servidor de autcn t ic;~ção. Nesta f;~se. o pomo de acesso age essencialmente como um relé, cnc:uninhando mensagens entre o cliente c o servidor de autenticação. O f rotocolo de Autenticação Exten.sivcl (EAf , do ingl~s .E.xtcnsiblc r'\HtlWtliCCIIÍOII Pl'otocol) I RFC 2284 1ele fine o formato da mensage m nm a fim usado em um simp les modo de requisic;;ão/resposta de interaçl\0 entre o cliente c o servidor de au tenti ca~·ão. Como mostrado na Figura 8.33, as rnensageJJS EAP são encapsuladas usando um EAPol (EAP através da LAN. IIEEE 802. LXI) e enviadas atnwés de um enlace 802. 11 sem fio. Ent:lo, estas mensagens EAP s;lo descnCaJ>Suladas 110 ponto de acesso, e re-encapsuladas usando um protocolo RADIUS para a lransrniss.'o atra· vêS de UDPII P ao servidor de autcnticação. Enquanto o protocolo c o servidor RADIUS IRFC 2865] não Solo requisitados pelo protocolo 802.lli, eles são, na prâti<:-:1, componentes padr.lo para 802.lli. O protocolo recentemente padronizado DIAMETER IRFC 35881 é propenso a substituir o RADIUS em um futuro próximo. Com o EAP. o servido de autcnticac;;ão pode C;S(:Oihcr drvcrsos modos para rcalrzar a autenticação. Enquanto 802.11 i n:lo dita um método específico de autcnlica~lo. o esquema de autcnlicaç:to EAP-TLS IRFC 2716) é frequentemente usado. O EAP-TLS usa técnicas de chaves públicas ( incluindo a criptografia noncc c resumos de mcrlSagens) scmclham ts àquelas que estudamos na Scçiio 8.3, que permitem que o cliente e o servidor de au tenticação se autentiquem mutuamente, e produzam uma Chave Mestra (MK, do inglês Master Key) que é conhecida por ambos os participantes.


STA:

estação cliente


AP: ponto d~ ac;esso

535

AS:

Servidor de autenticação Rede com fio

EAPns EAP EAP por LAN (EAPoL)

RAOIUS

IEEE 802.11

UOPIIP

Figura 8.33 OEAI' é um JlfOIO
Gernçclo dt• Chave Mcslm l'm·emla (PMK). A MK é compartilh:.d:1 secretamente somente para o cliente c para o servidor de uutentica~"t\o, sendo cl<~ usad:1 por ~tes paro gerar urna segunda ch:wc, :. Chave Mestra Parenda (PMK. do inglts Pain.,ise Mmtcr Kcy). Então. o scn•idor ele autcnticaçt\o envia a PMK ao AP. E é aqui que qucrfamos chegar! O cliente e o AP têm agoro uma chave compartilhada (lembre-se de que em WEP. o problema da distribuiç.lo de chaves n;lo foi nem citado) c se autenticnrom mutuamente. Agoro eles estão quase prontos para entrar em ação.

4.

Gcraçclo tle Chtl\t Telllf'Ortrl (TI(). Com a PMK. o cliente sem Oo e o AP podem agoro geror cha,·es adicion:us que serão usadas paro comunicação. De interesse particular temos a Chave Temporal (TK. do inglts TrmtJOml Key) . que será usada para implementar a crip10graOa de mvel de enlace al13vés do enlace sem fio e um hospedeiro remoto arbitrário. 802.11• forece '.trias fonnas de criptografia, incluindo um csquemn de crlptogrnfia b.'ISCada em AES c uma versão reforç.~da da criptogrona WEP.

8.8 Segurança operacional: firewalls e sistemas de detecção de invasão Vimos, em todo este capitulo, que a Internet não é um lugar muito seguro- nela. os dclinquentcs estfto por toda parte, cri:mdo todo tiro de destruição. Dada a natureza hostil da Internet. vamos considerar uma rede

de organizaç-Jo c um ad lllinistrodor de rede que a administra. Do ponto de vista de um administrador, o mundo está di vidido claramente em dois campos - os bonz:inhos (que pertencem à organizaç~o que admil1is1ra a rede c que deveriam poder acessar recursos dentro da rede que ele administra de um modo rcl:uiv:~ mc •n e Iivrc de restri· ções) e os bandidos ( todo o res to, cujo acesso :tos recursos d;~ rede d eve ser cuidadoS
8.8.1

Firewalls

Um Eirewall é uma combinação de hardware e software que isola a rede inte rna de uma organização da Internet em geral, permitindo que alguns pacotes passem e bloqueando outros. Um firewall permite que um


ad ntinistrador de rede comrole o acesso entre o mundo externo c os recursos da rede que administra gerenciando o fluxo de tráfego de c pam esses recursos. Um firewall possui tres objcuvos:

Tcxlo o trdfrgo ele fom pam tleutro, e \'ÍCC-"1-crscr, pcrssc1 por um fircwall. A Ftgura 8.34 mostra um firewall. situado dirctameme no hmile cmre a rede administrada c o resto da Internet l:nquamo grandes organizações podem usar diversos níveis de fi rewalls ou firewalls distribuídos (Skoudis, 2006). alocar um fircwall em um unico ponto de acesso à rede, conforme mostrado na Figura 8.34. facilita o gerenciamento e a cxccuç;lo de uma poliuca de acesso seguro. Somclllr o mifcgo autori~cr(/o, como definido l'da polltica de segurança local. pcxleJtl rm~scrr. Com todo o tráfego que entra c sai da rede institudonal passando pelo fircwall , este pode limitar o acesso a tráfego aut oriz:~do.

O t"61'rio firrwcrll f imune clJJrnctmçiio. O próprio fircwall é um mecanismo conectado à rede. Se nào projetado ou instalado adequadamente, ele pode ser comprometedor, podendo oferecer apenas uma falsa scnsaçilo de segurança (que é pior do que não ter nenhum fircwnll!). Cisco c Chcck Point SilO dois dos principais fomeccdores de firewa ll hoje. Vo~:e pode criar um f'ircwa ll fa cilmente (filtro de pal·otc) :1 partir de um sistema Li nux usando tabelas tP (software de dominio ptlbliço q ue nonnalmcmc acompanha o Linux). Os fircwalls podem ser classificados em rrcs categorias: filt ros de pacote tradicionais, filtros ele estado e gatcwars de aplkuç;lo. Abordaremos cada um deles nas subscçOcs seguintes.

Filtros de pocole lrodicionois Como mostra a Figura 8.34. uma organização normalmente tem um roteador de borda que conecrn sua rede mterna com seu ISP (c dali com a Internet publica. mais :unph1). Todo o tráfego que saí ou que entra na rede interna pass.1 por esse roteador c é nes5c roteador que ocorre a (ihragcm de pacotes. Um filtro de pacote cx.·unina cada clatagrama que cs1á sozinho, determinando se o datagrama deve passar ou llcar baseado nas regras especiflrns do administrador. As dcc1sõcs de llltragem São normalmellle bàscadas em: Endereço IP de origem c de destino. Tipo de protocolo no campo do datagrama IP: TCP, UDP.

IC~1P,

OSPF etc.

Int ernet publi ca

f irewall

Rede administrada

Figura 8.34 Posição do firewoll entre o rede administrado e omundo exterior



537

Pona TCP ou UDP de origem c de destino. Flag bitS do TCP: SYN, ACK etc. Tipo de mensagem ICMP. Regras d1feremes para da1agramas que entram e saem da rede Regras diferemes p:m1 interfaces do roteador diferentes Um administrador de rede configura o firewall com base na política da organiz:-~ç-lo. A pohtica pode considerar a produtividade do usuMio e o uso de largura de banda, bem como as preocupações com segurança da orgamzação. A T:-~bela 8.5 lista um numero de políticas possíveis que uma organização pode ter. e como elas seriam endereçadas com um filtro de pacotes. Por exemplo. se a organizaç-.'lo n;'lo quer nenhuma conexào TCP de entrada, exceto aquelas para o servidor Wcb público, ela pode bloquear todos os segmentos TCP SYN. com excc\-:\0 dos segmentos TCP SYN com pona de destino 80 c endereço IP dcstinat:lrio correspondente ao servidor Web. Se a organizaçào não quer que seus usuários monopolizem o acesso à largura de banda com aplicações de rádio via Internet. ela pode bloquettr todo o tráfego UDP não imponante (visto que o rádio via Internet é normalmente enviado por UDP). Se a organiz;,çi\o não quer que sua rede interna seja mapeada (mstreio de rota) por um estranho, ela pode bloquear todas as mensagens ICMP TIL expiradas que saem da rede da organização. Uma I)Ollticll de fihmgem também pode ser baseada na combinação de entlereços c números de pona. Por exemplo. o roteador de flltmgem poderia bloque-:.~r todos os d:Hllgmmas Telnet (os que u:m ntimero de porta 23), exceto os que cst:lo vindo ou indo de ou parn uma lista de endereços I P específicos. Essa polfticu permite conexões Tclnet de e para os hospedeiros que estão na lista. Infelizmente, basc:1r a polftlca em endereços externos não oferece nenhuma proteçno contra d:nagmmas cujo endereço de fonte foi falsiflcudo. A Oltragem pode também ser baseada no bit TCP ACK ter ou não valor. Esse estratagema é bastante util quando um:-~ organiza'-\o quer permitir que seus clientes internos se conectem com servidores externos, mas quer impedir que clientes externos se conectem com servidores internos. Lembre·se de que o primeiro segmento de todas as conexões TCP (veja a Seção 3.5) tem o bit ACK com valor O, ao p;tSso que todos os outros segmentos da conexão tem o bit ACK com \'lllor l. Assim, se uma orgamzação quiser impedir que clientes externos iniciem uma conexão com ser, idores mternos, ela simplesmente filtram todos os segmentos que entram que tenham o bit ACK ajustado em O. Ess.1 polltica elimina todas as conc.xõcs TCP originadas do exterior. mas pcnnite conexões que se origmam Internamente. As regras do Orew·all s;)o implementadas em rote<~dorcs com listas de controle de acesso. tendo Cllda interface do roteador sua própria lista. Um exemplo de uma lista de controle de at<.'SSO pam uma organizaçM 222.22116 é ilustrado n:1 Tabcl:. 8.6. Essa lista é para uma imerface que conecta o roteador aos JSPs externos da org:-~nizaç-.lo. As regras são aplicadas a cada clatagrama que atravessa a interface de cima para baixo. As primeiras duas regras jumas permitem qt•e usuários internos naveguem na Web: a primeira rcgm permite qtmlqucr l>acote TCP com porta de des tino 80 saia da rede da org:mizaç:io: a segunda regra permite que qualquer pacote TCP com porta de origem 80 c o bit 1\CK entram na rede da organização. Observe que se uma fonte externa telll:i est:tbclcccr uma

Política

Configuração de firewaU

Ncio hó acesso exterior à Web

Abondonor todos os pocoles de wítlo JlOfO quo~uer endereço IP, porto 80

Hõo hó conexões JCP de en11odo

Abondooor todos os poc01es JCP SYN po10 quolquet IP exceto

130.207.244.203, p0110 80

l~dir f#Je rlittOS Web coroom o bgtJO de bondo d'ISpOrí\·el

A!mlooor todos os pacotes UOP de entrado - exceto pacotes ONS.

lfl'CleÕ~ ~ soo rede s$ usado por um aloQUe OoS 'illlllf

Abondooor todos os pacotes ping que eslõo indo poro IJ11 aeço .broocf cosnpo~ exemplo. 130.207.255.255)

I~ ~ orolo de suo rede sejo rastreado

Alm101101 todo ohôfego de soido e~ ICMP TIL

Tabela 8.5 Políli
bow4tto4ic~ Redes de computadores e o Interne~!------------------------

A!ÕO

EJM!er~o

de

origem

Ender~o

de destina

ProtO
Porto de origem

Porta de destino

F1ag bit

Pemili

222.22/16

f010 de 222.22/16

TCP

>1023

80

twlquer 1.111

Permiti

f010 dt 222.22/16

222.22/16

TCP

80

>1023

ACK

Pemili

222.22/16

f010 de 222.22/16

UDP

>1023

53

Permi!W

f010 dt 222.22/16

222.22/16

UDP

53

>1023

Neg~»

Todos

Todos

Todos

Todos

Todos

Todos

Tabela 8.6 üsto de controle de acesso poro umo inte~oce doroteador conex;\O TC? \:Om um hospedeiro interno, a concx<\Oserá bloqueada, mesmo que n portr~ éle origem ou destino sejrt 80. As segundas duas rcgrns jumas permitem que pacotes DNS entrem c sni:un ela r·ccle d11 organlzaç:lo. Em resumo, essa lista de conLrolc de acesso limitada bloqueia todo o trMego exceto o trMcgo Wcb iniciado de dentro da organlzaç;\o c do tnlfcgo DNS. [CERT Fíltering, 20091 apresema uma lista de portas/protocolos parn :1 filtrn · gem ele pacotes pam cvit:u cli,•crsos burncos de scgur.,nca conhecidos em aplil·açOcs de rede existentes.

Filtros de pocole com controle de estado Em um fihro de pacote tradicional, as decisões de filtragem são feitas em cada pacote ISOlado. Os filtros de est
Endtreso de origem

Ender~a

de destino

Porta de origem

Porta de destino

222.22.1.7

37.96.87.123

12699

80

222.22.93.2

199.1.20S.23

37654

80

222.22.6S.I43

203.77.240.43

48712

80

Tabela 8.7 Tabelo de conexão poro ofiltro de estudo

bow4tto4ic~

Porta de origem

Porta de destino

ICP

>1023

80

222.22/16

TCP

80

>1023

222.22/16

f010 de 222.22/16

Ulll'

>1023

53

Pernifi

Foro de 222.22/16

222.22/16

Ulll'

53

>1023

NeQil

Todos

Todos

Todos

Todos

Todos

Endereso de origem

Endereso de desfiao

ProtCKolo

Pemili

222.22/16

Foro de 222.22/16

Peuritir

foro de 222.22/16

Pemili

Asão

539


Capitulo 8

Flog bit

Conexão de
ACK

X

X

lodos

Tabela 8.8 üsto de controle de acesso poro fi11ro de estado dntagrnmn com pona de origem TCP 80 c com o Oag ACK definido. Suponha ainda que esse pacote possua um nú mero de porta de orige m 12543 c endereço lP remetente 150.23.23.155. Quando esse p;tcote chega ao fircwall, este verifica a lista de comrole de acesso da Tabela 8 .8. que indica q ue a tabela de conexão eleve também ser ve rificara antes de permitir que esse pacote emre na rede da organ iiação. O f'irewall verifica a tabela de conexao c observa que esse pacote n•1o faz parte de uma conexão TCP em andamento c o rejella. Como um segundo exemplo. suponha que um usuário interno queirn navegar em um shc \Veb externo. Como o usuário primeiro en,•ia um segmento TCP SYN. sua conex•\o TCP ~ rcgistrnda na tabela de eonexlo. Qu.mdo o servidor Wcb envia pacotes de volta (com o bit ACK necessariamente definido), o firewall verifica a tabela c observa que uma conexão correspondeme es tá em progresso. O fircwall , ent:\o, deixará esses pacotes passarem, sem Interferir na navegação do usuário interno.

Gateway de aplicação 'os c.xcmplos que acabamos de mostrar. vimos que a filtragem de pacotes permite que uma organização faça uma fihrngcm grosseira de coruc üdos de cabeçalhos IP c TCP/UDP, incluindo endereços IP, numeras de porta c bitS de reconheci mento. Vimos. por exemplo. que a filtragem baseada em uma combinação de endereços IP c números de pona pode permitir que clientes internos c,xecutem Tclnct parn o exterior. ao mesmo tempo que impede que clientes externos executem Telnet parn o interior. Mas, e se uma organizaç.\o quiser fornecer o scn•iço Tcl nct a um conJunto restrito de usuários internos (em vez de a endereços IP)? E se a organiz.aç:lo quiser que esses usuários privilegiados se autentiquem antes de obter permiss:1o pam criar sessões Tclnct com o mundo ~terno? Ess.1s tardas estão além das capacidades de um filtro. Na verdade, in formações sob re a Identidade de usuários Internos n:lo est:1o luclufdas nos cabeçalhos IP/TCPIUDP; elas estão nos dados da c:mmd a de aplicaç:,o. Para assegurar u m nfve l mais refinado de segurnnça. os firew·J lls t~m de combim1r Oltro de pacotes com g;ucwa}'S de aplicaç;1o. G::ueways dE' aplicação fazem mais do que examinar cabE'Ç:Ilhos IPffCP/UDP E' tomam decisões co m base em dados da nplicaç:io. Um ga tcway de aplicação é um scr,riclor especifico de aplicaç;\o através do qu:ll todos os dados da aplk';'l"lo (que entram c que saem) devem passar. Vários ga teways de aplicação podem executar no mesmo hospedeiro. mas cada gateway ~ um servidor separado. com seus próprios processos. Para termos uma percepção dos gateways de aplicação, vamos projetar um fircwall q ue permite que apenas um conjunto re-strito de usuános execute Tclnct para o c.xtcrior c impede que todos os cltcntc-s externos executem TE'Inet para o intE'rior. Ess.1 política podE' SE'r aplicada pda implementaç-lo da combina~':\o de um rlltro de pacotes (em um roteador) com um gmeway de aplicação de Tclnct, como mostra a Figum 8.35. O filtro do roteador está configurado parn bloquear todas as conexões Telnet, exceto aquelas que se originam do endereço IP do gateway de aphcação. Essa configuração de filtro for~ todas as conexões Tclnct de sarda a pass.,rcm pelo gateway de aplicação. Considere agora um usuário interno que quer executar Tel net com o 1nundo ex tE'rior. Em primeiro lugar, ele tem de estabelecer uma sessão Telner com o gateway de aplicação. Uma aplicação que está executando

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------SessAo Telnet hospedeiro·gateway

Sessão Telnet gateway· hospedeiro remoto

Figura 8.35 Firewoll
8.8.2 Sistemas de detecção de intrusos Acabamos de ver que um filtro de pacote (tradicional c de estado) inspcctona campos de cabeçalho IP, TCP. UDP c ICMP quando está decidindo quais pacotes detxará passar através do ftrewall . No entanto, para detectar muitos tipos de ataque. precisamos executar urna in pcção prorunda de pacote, ou seja, precisamos olhar através dos campos de cabeçalho e dentro dos dados da aplicação que o pacote l'arrcga. Como vimos na Seç:'lo 8.8.1 . gatcways de aplicaç;'lo frequcmcmeme fnem inspeções profundas de pacote. Mas um gatcwa)' de aplicação só executa isto para uma aplicação específica. Claramente existe espaço para mais um dispositi,·o - um dispositivo que nôlo só c.-.:;unina os cabeçalhos de todos os pacotes ao passar por eles (como um filtro de pacote), mas também executa uma inspeção profunda de pacote (diferemememe do filtro de pacote). Quando tal dispositivo observa o pacote suspeito, ou uma série de

bow4tto4ic~ Seguron1o em redes de computadores

Capitulo 8

541

Anonimato eprivocidode Suponho que você queiro visitar oquelo polêmico pógino Web (por exemplo, o sita de um otivisto político) e você ( 1) não quer revelar seu endereço IP à p6gino do Web, (2) não quer que o seu ISP (que pode ser o ISP de suo coso ou do escritório) soibo que você está visitando este síte, e (3) não quer que o seu IP local vejo os dodos que você está compartilhando com o sito. Se você uso o abordagem trodicionol de conexão direto à pógino Web sem nenhuma criptografia, você folhoró em seus três objetivos. Mesmo que você use SSL, você folhoró nos duas prímeiros questões: seu endereço IP fonte é opresentodo à pógino Web em todo dotogromo enviado; e o endereço de destino de codo pocote enviado pode facilmente ser onolisodo pelo sou ISP local. Poro obter anonimato e privocidode, você pode usar umo combinoc;õo de um servidor proxy confiável e SSL, como mostrado no Figuro 8.36. Com essa obordogem, você foz umo conexão SSt com o proxy con· fióvol. Então envie, nessa conexão SSL, umo solicitação HTTP poro o sita desejado. Quando o proxy receber osso solicitoçõo SSL de HTIP criptografado, e le decriptograforó o solicitoçõo e encomínharó o texto cloro do solicitação HTTP à pógino Web. A pógino Web responde oo proxy, que por suo vez encaminho o resposta o você através do SSL. Como o pógino Web só vê o endereço IP do proxy, e não o endereço do seu cliente, você está de foto obtendo um ocesso anônimo o pógino Web. E devido oo tráfego entre você e o proxy ser criptogrofodo, seu ISP locol não pode invadir suo privacidade oo logor no sita que você visitou ou grovor os dodos que estavam sendo compartilhados. Atualmente, muitos empresas disponibilizam tais serviços proxy, (como o www.proxify.com). É cloro que, oo usor esta solução, seu proxy soberó tudo: soberó seu endereço IP e o endereço IP do sita que você está visitando; pode ver todo o tráfego em texto cloro comportilhodo entre você e o página Web. Umo obordogem melhor, odotodo pelo serviço de ononimoto e pricovidode TOR, é sequencior seu tráfego através de uma série de servidores proxys que não comportilhom informações entre si [TOR 2009). Em porticulor, o TOR permite que indivíduos independentes contribuam com proxys poro seu acervo. Guondo um usuário se conecto o um servidor usando o TOR, ele escolhe aleatoriamente (de seu ocervo de proxysl uma corrente de três proxys e sequen<:io todo o tráfego entre cliente e servidor otrovés dessa corrente. Dessa maneiro, supondo que os proxys não trocam informações entre si, ninguém percebe que ocorreu umo comunicação entre seu endereço IP e o págino do Web desejado. Além d isso, opesor de o texto cloro ser enviado entre o último proxy e o servidor, o último proxy não sobe quol endereço IP está enviando ou recebendo o texto cloro.

Obtendo anonimato do proxy

1~ Figura 8.36 Fornecimento de ononimoto eprivocidode com um proxy


pacotes sus~itos, ele impede que tais !X\Cotcs entrern na rede organizacional. O u, quando a atividade só é vista como suspeita. o dispositivo pode deixar os pacotes passarem. mas erw ia um alerta ao adminis trador de rede, que pode examinar o tráfego minuciosamente e tomar as ações necessárias. Um dispositivo que gera alenas quando obsen 'll tráfegos potencialmente mal intencionados é chamado de sistema de d etecç;lo de innuso-. (IDS, do ingles inrrusion dtrtetlon syswn). Um dispositivo que filtra o tr.ifego suspeito é chamado de sistema de p reve nção de int rusão ( IPS, do ingles intnrsion prt1·rnrion syswn). Nesta seç-ao. estudaremos ambos os sistemas - IDS e IPS- já que o mais interessa nte aspecto técnico desses sistemas é como eles detectam tráfego suspeito (em vez de enviarem alertas ou abandonar pacotes). Daqui para a freme iremos nos referir ao sistema IDS c ao sistema IPS como sistema IDS. Um IDS pode ser usado para d etectar uma série de tipos de ataques, inclurndo rnapcarn emo de rede ( provindo, por exemplo. de nmap), cscaneamemo de portas, escaneamcnto de pilha TCP, autqucs de inundar;-.lo de banda larga DoS, worrns c vfrus, ataques de vulnerabilidade de OS e ataques de vulnembilidade de ap licações. (Veja a Scçilo 1.6 para um tutorial so bre ataques de rede) . Atualrneme, milhares d e organiz.açOc:s empregam sistemas lOS. Muitos desses sistemas Implementados sao patenteados, comercializados pela Cisco, Chcck Point, c Olmos fornecedores de eqt•iptuncn los ele segurança. Mas muitos desses sistemas IDS implementados silo sistemas de domfn io publico, co mo o slstcrn:~ cxtrcnmmente popular Snon lOS (o qual iremos discutir em breve). Uma organiZ' de aplic;\Çào c monitorada por scnsores lOS: c urna região de scguran(a baixa - referida como : o na dcsmilita rizada (DMZ., do inglês tlnniliwri
Internet

legenda: • SfnsortS lOS

ServidOf

Servidor

SeiVidor

Web

FTP

ONS

Zona desmilitarizada

Figura 8.37 Uma organização implementondo um n1tro, uma aplicação gateway esensores lOS

bow4tto4ic~ Seguronço em redes de computadores

Capitulo 8

543

funda de pacote, como também compara cada pacote que passa com milhares de "assinaturas"; isso pode ser um volume de processamento significativo, panicularmente se a organizaç-lo recebe g1gabn.s/seg de trâfego da Internet. Ao coloc-ar sensores lOS além da transmissão, cada scnsor só vê uma fmç.\o do tráfego da orgamzaç.lo, e pode facilmente manter um ritmo. No entanto, sistemas lOS c IPS de alto desempenho cst{lo disponh"eis hoje c muitas organizaçOcs podem acompanhar com somente um scnsor localizado próximo ao roteador de acesso. Sistemas lOS s.lo amplamente classificados mnto como sistemas baseados em assin atura, ou istcmas basea· dos em anomalias . Um IDS baseado em assinatura mantém um b.-mco de dados extenso de ataques de assinatu· ras. Cada assina tura é um conjunto de regras relacionadas a uma atividade de intrusos. Uma assinatura pode ser uma lista de característíc,ts sobre um unico pacote (por exemplo. numeros ele portas de origem c destino, tipo de protocolo, c uma scqu~ncla de bits em uma carga útil de um pacote), ou pode estar relacionada a uma série de pacotes. As assmaturas são normalmente criadas por engenheiros habilidosos em segurança de rede que tenham pesquisado ataq ues COIIhecidos. Um :~dministrador de rede de uma organiza~-..\o pode personalizar as :~ssinaturas ou inserir as próprias no banco de dados. Opcmdonalmente, uma lOS basc:.1da em assinatura analisa cada pacote que passa, compar.mdo cada pacote analisado com as assinaturas no b:mco de dados. Se um J)acote (ou 11m a série de pacotts) é compatível com uma :ISsin:ltura no banco de dados, o lOS gera um alerta. O :llcrta pode ser e nviado :10 admin lsu-ndor da rede por uma mensagem de cm:til, pode ser enviada ao sistema de adrnínistrnçiio de rede, ou pode s implesmente ser registrado para futuras inspcçOcs. Apesar de os sistemas IDS baseados em assinaturas serem amplamente implemcn t:tdos, eles tem uma série de limitaçOcs. Acima de tudo, eles re
Snort Snort é um código aberto lOS de domínio público com centenas de millmrcs de implementações existentes !Snort, 2007: Koziol, 2003] . Ele pode ser executado em pl:uaformas Linux. UNIX c Windows. Ele usa uma interface libpcap de :1mllise genérica, que também é usada pelo Wireshark c muit:1s outras rerramcmas de análises de pacotes. Pode racilmcntc lidar com 100 Mbps de tr:ifego: para instalaçOcs com velocidades de tráfego de gigabitl seg. múl ti plos scnsorcs Snort serão necessários. Para termos um vislumbre do Snon, vamos observar o exemplo de uma assinatura Snort:

a1ert I cmp H XTERIIAL_HET any · >

~HOME_II ET

any

Esta assin:ltura c companvcl com qualquer pacote ICMP que entrar na rede da org:~nização (SIIOME_NET) c que venha do exterior (SEXTERNAI.._NET). é do tipo 8 ( ping ICMP). c tem uma carga uril vazia (dsizc-0). Já que o nmap (veJa a Seção 1.6) gera pacotes pmg com carncterisucas especificas, essa assinatura é projct:~da para detectar varreduras de ping usadas pelo nmap. Quando um pacote é compatível com esta assinatura, o Snort gera um alerta que incl u i a mensagem '·ICMP PING NMAP".


ln;.;l~e;.;rn;.;e;.;.t_________________________

Talvez o que scj:l mais Impressionante sobre o Snort é a vasta comunidade de usuários c cxpens em segurança que mantém sua base de dados de assinaturas. Normalmente. em algumas horas elo novo ataque, a comunidade do Snon cscre,·c c lança uma assinatura de ataque, q ue então (: transrerida \•ia download por centenas de milhares de amplcmcntações de Snort ao redor do mundo. Além disso, ao usarem a sintaxe da assinatura do Snort. os <~dministmdorcs de rede podem criar suas próprias assinaturas a fim de sausfazer ~ necessidades da organização modificando assinaturas existentes o u criando novas.

8.9 Resumo Neste capftulo, examinamos os dh•crsos mecanismos que Bob c Alice, os amantes secretos, podem usar pam se comunicar com segurança. Vimos que Bob c Alice estão interessados em confidcncialidadc (para q ue somente eles possam entender o conteúdo de uma mensagem transmitida). autenticação de entroncamento fin:~l (p<~rn que tenham a ceneza ele que estão falando um com o outro) c lmegridade de me nsagem ( para que tenham certeza ele que suas mensagens não sejam alteradas em trânsito). claro q ue a necessidade de comun icaçuo seguro m\o está limitada a amantes secretos. Na verdade, vimos n:ts se~·Oes 8.-J a e 8. 7 q ue a segurança é necess:.iria em vál'ias cam;tdas de urna arquitetura de rede para proteção cont ra bandidos que têm il mllo um grande nrscnal de ataques posslvcis. N:. prlmeir:t parte deste capitulo, apresentamos vários princípios subjacentes à cornuniC:lçào segura. Na Seção 8.2, examinamos as técnicas criptográficas para c riptografar e dcerip10graf:1r dados, incluindo criptografia de chaves simétricas c criptografia de cha,•es públicas. O OES e o RSA fornm examinados como estudos de caso espccaficos dessas duas classes mais import:mtcs de técnicas de criptograna em uso nas redes de hoje.

e

Na Seção 8.3, examinanos duas abordagens para fornecer a integridade da mensagem: códigos de amenticaçào de mensagem ( MACs) c :lSSinaturas digitais . As duas abordagens ti'm uma s~rie de paralelos. Ambas usam funções hash criptograradas c ambas permitem que verifiquemos a rontc da mensagem, assim como a imegridade da própria mensagem. Uma diferença importame é que os MACs não recorrem ~ criptogrnfia, ao passo que as assinaturn digi tais necessitam de u ma inrraestrutura de chave publaca. Ambas as técnicas são multo usadas na prática, como vimos na Seções 8.4 à 8.7. Além disso, as assinatur:•s digicais são usadas para criar certificados digitais, os quais são importantes para a \'erificação da validude de uma ch:~vc publica. Vimos também a :wtenticação d e ponto final c como no nccs podem ser usados para impedir acaqucs de repetição. Nas ScçOcs 8.4 a 8. 7 exami namos diversos protocolos de segurança de rede que são usados extensivamente na prát ica. VImos que u ma c riptogl'afia de ch:we simétrica está no nucleo de PGP, SSL. lpscc c scgurnnça sem rio. Vimos que u ma criptografia pública é crucial para ambos PGP c SSL Estudamos que u m PGP usa assinatu· ras c lctrOnic;tS pam a integr idade mensagem. ao passo que SSL c lpsec usam MACs. Agom que entendemos

d,,

os pri ncfpios básicos da cripLografia, e tendo tsllldado como esses pnncrpios silo usados, você agora dc,·e estar pron to para projcwr seus próprios protocolos de scguran~-.., de rede! Munidos das t~cni('as abordadas nas seções 8.2 a 8.7, Bob c t\lice podem se comunicar com scgurnnçu (cspcmmos q ue eles sejam estudantes de rede que aprenderam o que este lívro ensinou c possam, dess.1 maneirn. evitar q ue suas travessuras sejam descobertas por Trucly!) Porém. a confiabilidade é ape nas uma pequena parte do quadro da segurança n;~ rede. Corno vimos na Seç;lo 8 .8 , o foco da seguranç01 em rcdl'S cstt\ se conccntmnclo <.":tda vez mais em gamntir a segurança da infraestrutura da rede contra o ataqltC potencial dos bandidos. Assim, na última parte deste c1pftulo , estudamos fircwalls c sistean.1s lOS que inspecionam pacotes que cntrJm c saem tuna organiz:tç.\o de rede. Este capftulo cobriu dh•crsos fundamentos, enquanto foca"a nos tópicos mais importantes sobre a segurança em uma rede moderna. Os leitores que desejam mais informações podem in\'cstigar as referendas citadas neste C:lpflulo. Em partu:ular, recomendamos (Skoudis. 2006( sobre ataques c segurança opcrncion:~l. (Kaufmann. 19951 parn criptografi;t c como aplicá-la em scgur.mça de rede, (Rescorla. 20011 parn uma explicação profunda, mas dad:iuca sobre SSL c (Edncy, 20031 para uma discussão completa sobre sc:guran(:a 802.11. incluindo uma invesligação sobre a WEP e suas falhas. Os leitores também podem querer consultar (Ross, 20091 para um conjunto vasto de slidcs do Power Point (mais de 400) sobre segurança de rede e o utros labs baseados em Linux.



54 5

Exercícios de fixação Capítulo 8 Questões de revisão ~õo8. 1

~õo8.3

l.

Quaas s.\o as direrencas entre confldencialidadc de tncns.1gcm c mtC$tridadc de merasagem? E flOSS•'·el ter confidencialidade sem imegri
9.

De que maneira um hash rornece um melhor controle de intcgrid.1dc da mensagem do que uma soma de vcriflca~:lo (como a soma de vcrilicaç-ao da Internet}?

2.

Equi pame ntos da lmcmct (r01cad ores, comutadores, servidores D s. servidores dn \Veb, us uários c sis· temas etc.) rrcqucntemCiliC prec;isam SC CQI1l\111 icar com segumnça. De trcs exemplos específicos d e pares de equipamentos dn Internet quo: precisem de uma comunictlç,\o segura.

10.

Voe~ pode decrlptograrar o hash de uma mensagem a fim de obter a mensage m origino!? Explique sua rcspo:.ta.

S~õo

8.2

3.

D.t perspectiva de um serviço. qual é uma d irc rcnça impm tantc entre uma SIStema de chave simêtrica c

...

uma sistema de chave publica? Supon ha que um intruso tcnhn uma mensagem dcc()(Jificado. bem como a vcrs;lo d ecod ificada dessa mensagem Ele pode montar um ataque some nte com texto cirrado, um a taque com texto aberto con hcc tdo o u um :1taquc com texto aberto escolhido?

5.

Considere uma cirm de 8 bltlcos. Qt.:lntos blocos de entrada po)sfveis uma cirm tem? Qua ntos mapeamcmos possíveis podem ex isl ir? Se analisarmos cada mapeamcm o co mo uma ch:l\'e, então quantas chaves essa ctrm teria?

6.

Sup on ha que N pessoas qucimm se comunicar com cada uma das o utras N - I pessoas us:mdo c ripto· gmlla de chaves shue1ricas. 1'odas as co111unicaçi'>es e mre qua isquer duas pcss0as. I e j , s:lo visf\•cis pam to das as outras pcsso~s d esse grupo de N, e nenhuma outm pesso.1 d esse grupo t)Ocle decodificar suas comunicações. O sistema, como um todo, requer quantas cluwcs? Agorn, s uponha que seja usada criptografia de chaves publicas. Q uantas chaves scr.lo necessárias nesse caso?

1.

Supon h;~qucn• I O.OOO, a·I0.023eb·I0.004 . Use

uma id cmid:1de d e ari1mé1ica modular pam calcula r (a x b) mod n de c-.ti>C(a.

8.

Suponha que voc~ queira crip1ogmrar a mensagem 10101111 cnptogmra ndo um numero decimal que corresponda a essa mensagem. Qual seria esse mimero d eci mal?

1 1. Considere a varinç:lo de um algorttmo Mi\ C (F igum 8.9). onde o tmnsmissor envia (m, ll(m) + s). onde ll(m) + s é a co11emc rulçâo de 11( 111) c s . Essn variaçilo é ralha? Por que ou por (JUC nilo?

12. O que si~ni lica afirmar que um documento 4! ,rcrifi· cávcl, nào folsi llc~''cl c n:\o rcp udiavcl?

13. De que modo um resumo de mensagem c riptogrn· rado p<>r Ch ti\' C publica prop<>rti()ll:l uma assin:uum digital melhor do q ue utilizar a mensascm c riptografada com chave publica? 1+. SuJ>Onha que o cc n ificr.com crie um cenilicad o pan• roo.com. Ttpt c;~mcnte , lodo o certificado scna criptograrado com a chave publica de cenifier.com. Ve rdadeiro ou Falso) 15. Su ponha que Ahcc tenha uma mensage m pronta para enviar para qualquer pessoa que pcr~umar. Milhares de pessoas
18. 0 que C O atn
Seções 8.4 - 8.7 l9. Surx)nha que Bob receba urna mensngc:m PGP de Alice. Corno o Bob sabe com ccnezn que Alice criou a mensagem (c nJo Trudy. por exemplo)? O PGP usa um MAC pam nuegridadc d::1 mensagem? lO. Em mn registro SSL. cxtstc um campo para uma scqu~ncia de nume ros SSL Verd:~dciro o u Falso? 21. Qual é a li naIidade de um no nce em um protocolo de

autenticaç

n.

Suponha que uma scss:\o SSL utilize lima cifra bloqueada com CBC. Verdade1ro ou Falso: o servidor envia ao chcnte o IV em abcno?

23. Suponha que Bob inicie uma conexão TCP com a Tn1d)'. que CSlll fingando ser Alice. Durante a aprcsemaç:lo. Trudy envia paro Bob um certificado da Ahcc. Em qual etapa do algoritmo de cumprimento SSL n 13ob descobrirá que ele n~o está se comunicando com a Alice? 24. Considere uma. cadeia de pacotes do Hospedeiro A ao 1-tospeddru B usando IPscc. T ipicamen te. um novo $1\ será CS iabe lccid o para cada pacme crwiado na cadela. V.:rdmlci rn ou Falso? 2~.

Supon ha que o TCP I!Steja sendo execu tado atrovés de I Psec cmre o ecmro de o pemçõcs c a filial na Fl~unl 8.29. Se o TCP rctronsmltlr o mesmo pacote, c nli\o os dois pacotes co rrespondentes enviados por raco1es RI ter.\o u mesmo nt1rnero scquer1cial no cabcçalh(l ESP. Verdadeiro ou Falso1

16. Um SA IKE c um SA IJ>scc são a mesma coisa? Verdadeiro ou Falso?

27. Considere um WEP paro 802.11 Suponha que a inrorm;~ç;lo seja 10101100 c a chave de Ouxo seja 1111000. Qual o texto cifrodo? 28. Em WEP. 11m IV~ enviado em aberto em c:1d:1 quadro. Verdadeiro ou FaiS
Seção 8.8 29. Um J'ihro de pacote de estado mantém duas cstru· turas de dados. 1 omcic-as c brc\'emcme dcscre,·a o que elas fazem. 30. Considere um flhw de pacote tr:1dicional (sem esta· do). Esse flhro de pacote 11ode J'ihror pac01es baseado em Oag bhs TCP assim como em o utros campos de cahcçalhn. Verdadeiro ou Falso?

31. Em um J'iltro de pacote tmdlc lonnl. cada imcrfncc J>tldc ter sua própri:1 lista de con tro le de :tccsso. Verdadeiro ou Falso? 32. Por que uma ap licaç;lo de g;Hcw;~y trabalhn j unl~ mcn tc co m o flhro de roteador p;ara ser eficaz? 33. ID s baseados em ~inatur:~ c lPSs inspecionam a carga util de segmento TCP c UDP. Verdadeiro ou Falso?

Problemas l.

Usando a cifro monoalfabéticada Figuro 8.3. codifique a mensagem "This ls an eaS)' problcm.~ DecodiOque a mensa~ern -rmifu uamu xyj."

2.

Mostre que o aaaquc Côm texto aberto conhecido de Trudy em que ela conhece os pares de amduç:\o (texto cifr:~do. texto aberto) paro sete letras reduz em ~proximndnmcnte I o~ o número de possíveis substitu iç()CS a verificar no cKcmplo apresentado na Sccau 8.2.1.

3.

Considere o sisaem:a !loli:llrabêtico mosarado na Figuro 8.'1. Um ataque co m texto nbeno escolhido que consiga obte1 n cod illca~•lo dn mensagem ~Thc (1\I ÍCk fox j llllll>s OVCr lhe lUZ)' brOWil dog~ é s uri• cien te paro dccifmr todas as mensagens? Explique sua n:spoSH'I.

...

Considere u hloco cifradll na Figuro 8.5. Suponhü que c<~da bloco cifr.tdo T. simplesmente in\'crt:tm a ordem dos oito bits de entrada (ent:lo, por exemplo, 11110000 se torna 00001111 ). Além disso. suponha que o misaurador de 64 bits não modifique qualquer b11 (de modo que o ' 'alor de saída de m·ésimo bit seja Igual ao valm de cnlrada do n'l-l~simo). (a) Sendo n = 3 e a cntmda onginal de 64 bits igtaal a 10100000 repetidos oito vezes, qual o valor da saida? (b) Repita a parte (a), mas agora troque o último bit da entrada

original de 6-f bits de O para I. (c) Repila as partes (a) c (b) mas agora suponha que o mlsturador de 64 bits in,·crta a ordem de 64 bits.

5.

Considere o hloco cifrado da Flgum 8.5 P:lra urna dctennmada ·chave·. 1\licc c Bob precis:mam ter 8 tabelas, cada uma de 8 bits a 8 bits. Paro a Alice (ou o 13ob) am1nzcnarem tvdas as oito tabdns, quantos bits de arm:u:cn;lmcnto s:lo ncCI.'Ss.írios? Cmno c.:ssc mime· ro se rom poro com o m\mero de bits necessários pam 11111 bloco cifmdo de tahc ln cheia de 64 bits?

6.

Considere o bloco cifrad o de 3 bits da Tabela 8.1. Supo nha que n texto L1herto scj:~ 100100100. (:~) Inicialmente supo nha que o CI3C 11àc, sejn usado. Qual é o texto cifrado rusullnntd (b) Suponha que Trudy ana lise o texto cifrado. Supon
7.

Usando RSA, escolha p 3 cq li e codifique a palavra "dog". criptogmfando cada le1ra separadamente. (a) Aplique o algoritmo de decriptação à versão criptografada para recuperar a mensagem

=

=


original em texto aberto. (b) Repila a par1e (a). llliiS .lg
Cons1dcrc RSA com ,,

=5 c q = 11.

a . Quais ~.lo n e d b. Deixe que t seja 3. Por que esta é uma escolha acciuvcl para c'

c. Encontre d d.

par;~

Criptogr;~rc a

que tlt • I (mod ::) c d < 160.

mensagem m a 8 usando a chave (n.

r). Deixe c tknotar o texto cifrado co rresponden-

te. Mustrc todo o 1mx:cssu. Dica: P:1ra sim pliOcar os cálculos. use como dados: I(a mod n) • (b mod n)l mod n • (a • b) mod n 9.

Neste problema. exploraremos o a lgoriuno criptografado Oifnc·Hcllman ( DI I) de dtave publicn, o qual 1x: rmit c qt1c du as entidades concordem em uma chave com panllhada. O algQrltmo Dli fn uso de um ml mcro primo gra nde p e tllltro m\mero grande g. menor que ,,, Ambos, p c g. s:lo pühi•cos (de modo que um atacante os con heça). Em DH, Alice e Bob escolhem. independentemente. cha\'CS secretas, S,. c s•. respccti\'Jmcntc. Alice cnt:\v c.1kula sua chave pubhcn. T~ elevando g a s. c tomando o mod p. Bob. simllamtentc, calcula sua própria chave publica T1 cle\-ando g a S1 e tomando o mod p. Então. Alice t Bob trocJm suas chaves pllblicas a1ravés da lmemet. Alice c;~l cula a chave secreta compartilhada S ao ele'"ar T• aSAc tomando o mod p. Bob, similannente, c;~lcula a chave comp:lrlilhada S' ao elc\•ar T,. a 51 c tomando o mod p. a. Pro\'C que no geral, Alice e Bob ohtêm a mesma

cha\·e simetrica, O U seja, prove que 5 • 5'. b. Com I' • I i c g • 2, suponha que Alice e Bob ~colham chaves l)ri vadas SA. 5 e se= 12. rcspcc-

th•amcntc. Calcule as chaves públicas de Alice c Ooh, TA c T~. Mostre wd(l u processo. c. Scguindv n pane (h), calculeS corno a chave simétrica compartilha

547

KDC t: um servidor que compartilha uma únlcn cha\'C slmctric:t secreta com t':lda usu.1rio registrado. Para Alice c Bob. denote essas cha\CS K. U1C c K1 U'C' Projete um esquenta que use o KDC p:tra distribuir Ks à Alice c Bob. Seu esquema dever.\ usar tres mensagens para distribuir uma chave de s-.~o: a mensagem da Alice ao KDC: a mensagem do l
b. Qual a terce•ra menS:tS(Cm? 11. Calcule uma tcrceim nlcllSt.l!tcm. dir~:rcntc d:~s duas mensagens na Figura f\.18, que tenha a mesma soma de verificação d~-ss:IS duas mensagens na ngura cilada. 11. Suponha <1uc Alice c Doh compartilhem duas chaves secretas: uma chave de aut enticação s, e uma chave criptografada simr!trica S:- Aumente a Figura 8.9 para

que ambas, integridade e romccidas.

Ct)nfidcnc i~lidade,

sejam

13. No protOC<)Io de distnbuiç~o BitTorrent de arqui\'O P2P (veja o Cnpitulo 2), a semente quebra o arquivo em blocos. c os pares rcdistríhuem os blocos tms :tos outros. Sem nenhuma proteção. um atacante pode racllmcnte cnusar destrmç:\o em um torrcnt ao se ntascarar como se fosse um p:1r bcnc\•olcmc c enviar blocos falsos aos muros conjuntus de pares no torrent. Esse pares que não s:\o suspc•tos redis· mbucm os blocos falsos aos outros pares. que distri· buem os blocos falsos aos outros pares. Sendo assim. e importante pam o BitTorrent ter um mecanismo que ,,ermita que os pares veriOquem n mtegridade de um bloco, para que n~o dist ribuam blocos falsos. Suponha que qua ndo um par se junta n um torrem, inicialmente pei:a um arquivo . t orrent de uma fonte inteiramente co nnóvcl. Escrc,·a um esquema simples que perrnhn que os pares ''crífíquem n fntc· gridacle dos blocos. H . O protocolo de roteamento OSPP usa u m MAC em

vez de ass lmlluras d igitais para fornecer a integridade da mcn:.agcm. Por que você ac ha que o Mr\ C foi escolhido em vez de assinatums digitais? 15. Considere nosso proHK."Oio de aut cnticaç;lo da Figura 8.16, no qual Alice se autentica p:trn Bob, e que \•imos que funciona bem (isto c. não cncon1ramos nenhuma falha nele). Agora suponha que. enquanto Alice está se autenticando para Boh, este deve se: autenticar para Alice. Apresente um cenário no qual Trud)'. faze ndo-se passar por Alice. agora pode se autemica r par;~ Boh como se fosse Alice. ( Dica: considere que a sequ~ncla de operações do protocolo. uma com Trudy iniciando a sequência c outra com Sob iniciando a sequência, pode ser intercalada arbitra·

bow4tto4ic~ Redes de co 11 putod ores e o Inle rne;.;'- - - - - - - - - - - - - - - - - - - - - - - - -

16.

l7.

18.

19.

rlamcme. Prcsle particular atcnc;;\o ao fato de que Bob c ,, llcc usarJo um noncc c que. cõiSO n.\o se tome cuidado, o mesmo nonce pode ser utihzado com rn.is imenÇt)es.) No ataque do homem do meio mostrado na Figura 8.19. Alice n;lo autenticou Bob. Se Alice tivesse solicitado a Bob que se autenticasse usando um protocolo de ,\Utcnticac;Jo de chave publica. o alaquc dt> homem do meto teria sido C\'ilado? Exponha seu racioclnio. A Figura 8.20 mostra as operações que a Aliçc deve realizar t·om PGP para fornecer C(mOclcncialidadc, autcnticaçl\o c integridade. Faça um diagrama das oJ>cractks correspondentes que Bob precisa exccmar no 1>acotc recebido por Alice. Suponha que Alice ctucira erwíar um c-mail a Bob. [)(>h tem um par de chave ptihlica·privada (K~. K~). e a Alice 1cm o ccrtiOcado do Oob. Mas a Alice não tem um par de chave ptihllca, pri\•ada. Alice c noh (c o mundo inteiro) compartilham a mesma func;ão hash H( • ). (a) Nessa siltW\âO. é posslvcl projetar um esquema J>am que ,, Boh possa 'cr-ific:tr que 3 ,\licc criou ::~mensagem> Se sim, mostre como. com um diagrama de bloco para Alice e Bob. (b) Ê posstvcl projetar um esquema que forneça conOdcnclalidadc para enviar a mensagem da Alice a Bob? Se sim, mostre como com um di:tgrama de bloco para Ahcc c Bob. Cons1dcre 3 sa1da Wircsh:trk :tbaixo p:trauma porção dcs~lo SSL.

,

4

1

••

<. • ..

..

t •

•• •o

••

•

1•

•

•

'

• -

• .... • ' o •

.(

•

•

•

•

'

•

•

• • ... • • •• ,. •• • ' •• o •..& • •

•

•

•

• •

• ,

.(

• (

~

'·

t-

'

... • ' •

I ' ''

t

'•

,. • • •

t

• ~ "·

_)

•• .. • •

•

I '

~

4 • ~

•

0 '

'

o

••

'

···'···············.; ........ ' . ' ... .., .......... . . ,,,

•.

I •

'

;

'•

•

•

~

•

•

..(:

• < •

••

a . O pacote Wireshark 112

c enviado pelo cliente

ou pelo serv1dor? b. Qual o numero IP do servidor c seu numero de

porta? c. Cons1dcrando que nenhuma perda ou retrans· m1ss;'lo ocorreram. qual será a sequ~ncia de numeras do próximo segmento TCP cm'iado pelo cliente? d. QuanlOs reg istros SSL existem no pacote \Vi rl'Sha rk I 12?

e. O 1>acotc 112 contém um Scgn-do Mestre ou uma Segredo Mestre CriJ>I
Supondo que o carn~)O elo tipo na ilJ)resentação c de I bytc c cacJa campo de comprimento é de J hytes. qmtls s:lo os valores do primcii'O c do ti ltimn hytcs do Segredo Mes tre (ou do Segredo Mestre Crlptografado)?

g. A mcns.1gcm de apn-scnt3Ç;lo criptografadc> do cliente leva em coma o nlimero de registros SSL? b. A mensagem de apresemac-lo criptogrnFadtt do scr· \idor lc\'a em conta o mlmero ele registros SSL? 20. Na Sec-.lo 8.5. 1 mostramos que sem os nlimcros de M."(!u~ncia, a Trudy (a mulher do meio) pode ca\J$ólr dcstruic:•lo em uma ~slo SSL ao 1rocar os scgmcn· tos TCP. A Tn1dy pode fazer algo similar ao ddclar um segmento TCP? O que ela precisa fazer para ter sucesso em seu ataque de a1>agnmemo? Quais serao os seus dcltos?


549


1 1. Suponha que a Alice c o Sob est:\o se comunicando ;urnves de uma sess:\0 SSL. Su1>011ha que um atacan-

e por llhlmo o campo ICV. com alguns desses cam(>OS criptografados.

te , que n ão tem nenhuma das chaves compartilhadas, Insira um segmcmo TCP falso em nuxo de J)acote com a corrctJ soma de vcriOc~c:'o TCP c mímcros sequcncials (e corretos endereços I r c números de porta. A SSI do lado receptor aceitar.! o pacote falso c passar.! a carga carga útil à aphcaç.lo rcceJ)tora? Por que ou por que não?

a . Queremos enviar a m ensagem 111 • lO I 00000 us.1nclo IV • Ll c \VEP. Qual serão os valores nos tres campos WEP?

b. Mostre que ttu ando o receptor tlccriptografa o pacote WEP. ele recupera a mensagem c o ICV. c. SUJ)(lllha que Trudy intercepte um pacote WEP (n,lo ncccss:~rinmente com IV li) c quer modiflcá-lo antes de cncammh:l-lo ao receptor. Suponha que a Trudy gire o primeiro bit do ICV. Admitindo que a Trudy não sabe como o fluxo de chaves par.~ quaisquer IVs. que outros bits a Trudy precisa gerar tarnbcrn, para que os pacotes r'c ccbidos passem pelo controle ICV?

=

21. i\s seguintes quesuics de Vcrdadetro/Falso se referem :\ Figura 8 .29.

a. Quando um hospedcaro em 172 16.1/H envia um datagrama ao scrvtdor Am:~zon.com, o roteador RI vai criptogmfar o d:u~gmma usa ndo 1Pscc.

b. Quan do u m hospcdcim em 172.16.1/H envia tun cltu~nlllt(t a um servidor 172. 16.2/24, o roteador RI rnud:ml os cndca·cços de nrigcm c destino do datagrama IP. c. Suponha que um hosJX.-deiro 172. 16.ln4 inicie uma conexão TCP com um SCI'\'idor Web em 172. 16.2124. Como p;~tte dcss:t conex.lo, todo:. os d:nagrnm~ enviados pelo R I terão o numero de protocolo 50 no campo esquerdo do cab«-:tlho 11'\'4.

d . justinc1 ue sun resposu1 modificando os bits do parote WEP da pane (a), dccriptograf::mdo o paccHe rcsuluuuc c verificando o controle de Integridade.

25. Forneça uma tabela de filtro c uma tabela de conexão par.~ um flrcwall de estado que seja tão restrito
a. Permite que todos os usuários internos cstabelc· cam scsst'CS Telnct com hospedeiros externos.

d. Considere o envto de um segmento TCP de um hospedeiro em 172. 16. 1/24 a um hospedeiro em 172.16.2124. Suponlm CJUC cl rcconhecimenw desse segment o se pe rde, cnt;'\0 um TCP rccnvi3 o segmento.

23. Considere o exemplo na Figura 8.29. Suponha que Tr\ady é a mulher do mcitl, que tn.)Crc d;~t;~gmmas no fluxo de data.gmmttS indo de Rl 3 R2. Como parte do ataque de repetição. Trudy envta uma cópia duplicada de um dos datagmmttS enviados de RI à R2. O R2 decriptografarn o d:ttagrama dutllic.'ldo e o encami· nht~rn i\ rede dn 011~1? Se n~o. dcscrcv:1 em detalhes como R2 detecta o d:uagmma duplicado. 24. Consid ere o seguinte pseudoprotocolo WEP. A chave é de 4 bits e o IV, ele 2 hits. O IV é a nexado ao fln:.l da chave quando está gemndo o nuxo de cha\'es. Suponha q ue uma chave se-c reta cumpartilhada c 1010. O fluxo de chaves pam quatro emmdas possíveis são: 101000: 0010101101010101001011010100100... 101001; 10100LIOII0010101 10100100101101... 101010: 000110 1000Ll l100010100101001ll L. 101011: llllJOI010000000101010100010lll... Suponha qu e todas as mensagens tenham 8 bits. SupMha que o ICV (comrole de Integridade) sej~ de 4 bits c calculadu por OU-exclusivo nos primeiros 4 hhs de dados com os lllthnos 4 hits de dados. Suponha que o pseudo-pacote WEP consista em três campos: primeiro o campo LV, depois o campo de mensagem

b. Permite que usuários externos naveguem pela p:tgina Wcb da empresa em 222.22.0. 12.

c. Mas. em qulllquer outro cnso. blo
A rede interna é 222.2211 (). N:1 sua solu(llo, suponh,, que a tabela de conexão esteja normalmente ocultando tr~ ronc:Mks, de dentro para rom. Vare precisará im·cntar um endereço IP c numçro de porus apropriados.

26.

S~tponha que Alice qucirn ''isitnr n p.1gina Wtb aeti· ' 'ÍSt.com us.1ndo um serviço do típo TOR. Esse ser' 'iço usa dois sel'\•idorcs proxy colabor:td orcs, Proxy I c Proxy 2. Alice primeiro obtc!m tlS ce rtificados (cnda um co ntendo uma c ha"e p1lhlica) 1mm l'nlX)' I c Proxy 2 de um scr,·idor ccn1ml. Denote K;{ ) , K~() e t<;<) pam a criptogmnatdccrlptogmfla com cha\'CS publíca e prh11da RSA.

K;< ),

a . Usando um diagrama de tempo. forncca um protocolo (o mais simples posslvel) que permita que 1\hce estabeleça uma SCSS;lo compartilhada de chave 5 1 com Proxy I. Denote S,(m) para a crip· togranatdccriptogrnfia do dado m com n ch3\'C compartilhada 5,.

b. Usando um diagrama ele te mpo, forneça um protocolo (o nmis simJ)Ics iJOS)fvcl) que permita que Alice l'Slabeleça um;1 scss:\o compartilh ada da chave 52 co m Proxy 2, sem revelar seu endereço lp

página html de actlvist.com sem rr velnr seu crulcrrco IP "'' Pro.\ ) 2 c srm rndnr il PrO'\) I qual sue clc1 I.'SICI visitando. Seu diagrama de"c

c. Suponha que ns chaves companilhadns 5 1 c 51 estejam dctcrmmadas. Usando um diagram:t de tempo, rorneça um protocolo (o mais simples posstvcl e ntlo usando uma dwve críptogmfada rmb/ica) que permita que Alice requisite uma

tcmunar com um:1 requtstçi\o HTTP chegando a acti\'tS t.COill.

Questões dissertativas 1.

2.

Suponha que um inuuso consiga inserir e remo· ver mensagens D 'S da rede. Mome tr(~ cenários dcmonstrondo os problemas que esse intruso poderia causar. O que é Kcrbcros? Como funciona? Como ele pode ser relaciona no Problema lO deste c:apftulo?

3.

Se u I Psc:c oferece scgur.mça na camada de rede. por que ainda s.ltl neccssáritlS mecanismos de scgurn nç:t em cumadas acima do I P?

4.

Faça uma pesquisa sobre I>S botnets. Que protocolos e sistemas os atat':lntes usam paro com rolar e atualizar os bmncts hoje em dia?

Wireshork Lob Neste lab (disponf"cl n:• página Web), investigamos os prowcolos de Camada Soquete Seguro (SSL. do inglês Srcurc Socket utyer) Lemhre·se de que na Seclo 8.5 o SSL é usado para a segurança de uma conexão TCP. c é extensiva· mente u:.ada na pr.ltica JX~rn a ~gurnnc:a de trnnsacóes pela Internet. Neste lab. focuremos os registroS SSL en..iados

atrnvês de uma concxà() TCP. Tcnutrcmos delinear c classificar cada um desses registros, rclCilnclo nu cmenclimemo do porqu~ c como de cad:t registro. Investigamos os vários tipos de registro SSL assim como os campos nas mensagens SSL. analisando os passos elos registros SSL enviados entre seu hospedeiro c um M:f\•ídor c-ccmunrru.

IPsec Lab Neste lab (disponlvcl na pagina Wcb). exploraremos como criar SAs IPscc ent re caixas Iinux. Você pode fazer a primei ra parte com du:1s caixas Iinux simples, cad:1 um:1 com um adaptador Ethcrnet. Mas na seg undo parte do lab, você precisará de quatro cai-

xas Iinux. duas tcnc.l o dois adaptadores Ethcrnct. Na segunda metade do lab. você criara SAs IPscc usando protocolos ESP no modo tuncl. Primeiro voe!' criará as SAs manualmen te c depois fazendo o IKE criar asSAs.

bow4tto4ic~

Steven M. Bellovin Steven M. Bellovin ingressou no corpo docente do Universidade de Columbio depois de muitos anos no AT&T (AT&T Fellow) do Networlc Services Reseorch lob nos AT&T lobs Reseorch, em Florhom Pork, New Jersey. Ele trobolho especifico· mente com

rede~

e seguronço, e com os cousos que os tornom incompotíveis.

Em 1995, Sleven recebeu o Usenix Lifelime Achievement Aword por seu trobolho no criação do Usenet, o primeiro rede de troco de inform()ÇÕe$ que t!govo dois ou mais computadores e permitio que os usuários compartilhassem informações e discutissem em conjunto. Sleve também foi eleito membro do National Acodell\)' o( Ef19ineering, Fez me trodo ~ Columl?io t,Jnlversi!Y e doôloràdô·no University of North Carolina,

ttn Chope! H~l.

O que o fox se decidir pelo especialização no área de segurança de redes? O que \'Ou dizer parecerá estranho, mas
Qual era suo visão sobre o Usenel no época em que o senhor o eslavo desenvolvendo? Qual é suo visão agora? No infcio considerá\':lmos a Usenet como um meio para discutir ci~ncia dn computnç-.\o e progmmaçao de computadores em todo o pa1s e parn utilizar em questões administrativas locais, como recurso de vendas, c assim por diante. Na verdade. minha previs:'lo original era de uma ou duas mensagens por dia, de 50 a 100 sites no máximo. Mas o crescimento rC<~I ocorreu em tópi cos relacionados a pessoas. inchundo- mas não se limitando a - in te· raçoes de seres humnuos co m computado res, Meus grupos de bate-papo preferid os foram. durante muitos anos, cois;ts como rec.woodworking (marcenaria), bem como sci.crypt (criptogmfia). At ~ ce no ponto, ;1s redes de notícias foram dcsbancadas pel:1 Web. Se cu rossc inlci:1r

muito diferente. Mas ainda é um excelente meio sem ter de pass:•r por sitts Web particulares.

pe~ra

o projeto hoje, ele seria

alcanç;u um público muito amplo interessado no
Quais pessoas o inspiraram profissionalmente? De que modo? O professor Fred Brooks - fundad or c primeiro chefe do depart:trnento de cil!ncia da co mj>Utaçâo da Uníversity of No rth Caro lina, em Chapclllill, gerente da equipe que desenvolveu o IBM S/360 e o OS/360, e autor do livro Tiac i\ ly tlJícal Mnu-Monlh- exerceu uma tremenda influencia sobre minha carreira. Acima de tudo, ele me ens inou observaç:\o c compromissos- como considerar problemas no co ntexto do mundo real (e como o mundo real era muito mais confuso do que qualquer reórico gostaria que fosse), c como equilibrar interesses connit:~mcs ao elaborar uma soluç-.\o. Grande pane d o trabalho com computadores é engenharia - a arte de fazer os com· promissos certos de mod o a s:uisrazer muitos objetivos contraditó rios

551

bow4tto4ic~ Em sua apiniõo, qual é o futuro dos redes e da segurança?

Até agora, gm nde pane da scgur:mc.-a que temos ''em do isolamento. Um firewall, por exemplo, funciona Impedindo o acesso a certas máquinas c serviços. Mas vivemos em uma época na qual a conectividade é cada vez maior- ficou mais difícil Isolar coisas. Pior ainda, nossos sistemas de produçâo requerem um numero muiLo mmor de componenLes isolados, imerconectados por redes. GaranLir a segurança de tudo isso é um de nossos maiores dc:sarios. Em que projetos especia is o senhor estó trabalhando agora?

Estou me concemrando muito em qucstc>cs operacionais. 1l\O basta que um sistema SCJa seguro: ele também tem de ser utilizável. Isso significa, por sua vez, que opendores de redes têm de poder monitorar coisas. Mas monitorar pode con011ar com segurança - a segurança lende a ocultar e prolegcr computadores c informações. mas operadores precisam ver certas coisas. Além disso, sisu•tmlS u~m de cominuar funcionando mesmo que componentes cruciais fa lhem. Como comp
Ao menos do ponto de vis ta científico. sabemos como fazer criptogmfia. r: isso é uma grande ajud:1. Mas :1 rn:~ioria dos problemas de segurança se deve a códigos defeituosos c este é um problema multo mais sério. Na ve rdade, é o p1·oblcma mllis amigo da ci~ ncia da computaç;lo que ainda ni\o foi resolvido- c :~choq ue continuar.\ sendo. O dcsafio é descobrir como manter a segurança de sistemas quando ternos de construí-los com componemcs inseguros. Hoje já podemos fazer isso no que tange às falhas de hardware; mas podemos fazer o mesmo em rclaç-ao à segurança? O senhor pode dor algum conselho aos estudantes sobre a Internet e segurança em redes?

Aprender os mecanismos é a parte fácil. Aprender a ~pensar como um paranoico~ é mais difícil. Você tem de lembrar que as disLnbuiçOcs de probabilidade não se aplicam - os atacantes podem encontrar c encomrarão condições improv.h'cis. E os detalhes São imponantes- c muito!

552

bow4tto4ic~


A

pós termos percorrido nosso caminho pelos oito primeiros capítulos deste livro, estamos agora

9.1

Oque é gerenciamento de rede?

conscientes de que uma rede consiste em muitas pecas complexas de hardware c software que intcragcm umas com as outras - desde os enlaces. comutadores, rot{'Udores, hospedeiros c outros dispositivos, que s:lo os componentes risicos da rede, até os muitos protocolos (tanto em hardware quanto em software) que controlam c coordenam esses componentes. Quando ccmcnas ou ntilharcs desses componentes s.1o montados em conjunto por alguma organiz.1ç;l0 para formar uma rede, n~o é nada s urpreendente que ocasionalmente eles apresentem dcfwos, que elementos da rede sejam mal configurados. que recursos da rede SCJam uulizados exces· si\'amcntc ou que compo nentes da rede simplesmente •quebrem' (por exemplo, um cabo pode ser cortado, uma latinha de rdrigcramc pode ser derramada sobre um ro teador). O administrador de rede. cuja tarda e mamé-la 'viva e atuante'. deve estar habilitado a rt':lgir a esses contratempos (c, melhor :unda. a evitá-los). Com potencialmente milhares de componcmes de rede espalhados por uma grande área, ele, em sua central de operações (urrworll O!'CHitio11s cr111rr- NOC), evidentemente necessita de rerrnmentas que o auxiliem a monilornr. administrar c controlar a rede. 'este capítulo, e>:aminaremos a arquitetura. os protocolos e as bases de informac-.\o que um admmistrador de rede utiliza para realizar seu trabalho.

Ames de discutir o gerenciamento de redes em si, vamos considentr :tlguns cen:\rios ilustrativos do 'mundo real' que não s:'o de redes, mas nos qu•tis um sistema complexo com muitos componentes em ínteraçüo deve ser monitontdo, gerenci:tdo e controlado por um administrador. As usinas de geraç:lo de energia clttri<:a tem uma sala de controle, o nde mostmdores, medidores e lâmpadas monitornm o estado ( icmpcrntum, pr~\o, \'a.Z;.\o) d e valvulas. lllbulações, vasos e outros componentes remotos da instalação industrial. Esses dispositivos permitem que o opcrndor monitore os muitos componentes da planta e possam alcrt:l-lo (o famoso piS{'U·piS{'U vermel ho de alerta) caso haja algum problema imincme. O operador responsável executa certas ações para controlar esses componentes. De maneiro semelhante, a cabine de um avião ~ equipada com instrumentos para que o ptloto poss.1 monitorar c controlar os muitos componentes de uma aeronave. Nesses dois exemplos. o ·administrador· mouitorcr equipamentos remotos c analisa os dados para garantir que os equipamentos estejam funcionando e operando dentro dos limites especificados (por exemplo, que a fusão do núcleo de urna usina nuclear nào esteja na iminência de acontecer ou que o combusLível do avião não esteja prestes a acabar), controla reativament e o


sistema fazendo ajustes de acordo com as modWcaçõcs ocorridas no sistema ou em seu ambieme c gtrencia proati,·amenlc o sistema ( por exemplo, detectando tend~ncias o u componamentos anômalos que permitem executar uma ação ames que surpm problemas s~rios). Nesse mesmo sentido, o admitustrndor de rede vai monitorar. gerenciar c controlar ativamente o sistema do qual está encarregado. ' os primórdios das redes de compu tadores, quando elas ainda eram artefatos de pesquisa, c não uma infraestrutura us.1da por milhões de pessoas por dia. ·gerenciamento de rede' era algo de que nunca se tinha ouvido falar. Se alguém descobrisse um problema nu rede, poderia reuhzar alguns testes, como o pmg. para locah zar a fome do problema c . em segu ida, modificar os ajustes do sistema, reiniciar o software ou o hardware ou chnmar um colega para fazer isso. (0 RFC 789 traz uma discussão de fád l leitura sobre a primeira grande ·queda' da ARPA net em 27 de outub ro de l 980, mu ito antes da exist~ncia de ferramemas de gerenciamento de rede, c sobre os esforços realizados para entender os motivos dessa queda c recuperar a rede.) Como a lntcmct pliblica e as íntra nets privadas cresceram c se transformamm de pequenas redes em grandes infraestruturas globais, a necessidade de gc;-rcnciar mais sis tcm:uicamcnte a enorme quantidade de compo nentes de hardware c soft,Vllre den tro dcss:1s redes também se to m ou mais importante. Com o imuito de motivar nosso eswdo de gerenciamento de redes, vamos co meÇ1lr com um exemp lo simples. A Figura 9. 1 ilustra uma pequena rede constilurda de trts roteadores c ;~lguns hospedeiros c servidores. Mesmo p;lra uma •·cdc ti\o simp les, há muitos cenár-ios em que o ~•dministmdor de rede muito se beneficiar;\ por ter à m;lo :1s fc rrmncntas de gerenciamento adequadas: DetC'CÇilO dr fallw em llllltl placa de intrrfau em rrm hospetleiro ou rotcmlor. Com ferramentas de gerenci::tmento apropriadas, uma entidade de rede ( por exemplo, o roteador A) pode indicar ao administrador de rede que uma de suas interfaces n
Servidor

Figura 9.1 Umcenó riosimplesque ilustro oulilizoçõodogerenciamento de rede



sss

MonitorCit;clo llc ltospedtiro. O administrador de rede pode ''eririC3r pcriodic:lmemc se todos os hospedeiros da rede estJo ativos e operacionais. Mais uma ''ez, ele pode. de fa to. impressionar um usuario da rede. reagindo proativamcntc a um problema (ralha em um hospcdctro) antes de o defeito ser apontado pelo usuário. Mollltomt;clo ck trdfcgo pcmt anxiliar o ofrrccimcmo de recursos. Um adnunistrador de rede pode monitorar padrões de tniJego entre fontes e destinos e notar. por exemplo. que. comutando servidores entre segmçmos de LJ\N, o total de ll'áfego que pidas em wbeh~ tk r·orectmcnto. A altern:incia de rotas - mudanças frequentes em t:1bclas de roteamento- pode Indicar instabilidades no roteamento ou um roteador mal configurado. EvidcntenH'nte, um admlnistmdor de rede que conflgLtrou um roteador de modo inapropriado prefere ele mesmo descobrir o erro antes que a rede caht.

Monilomçtio tlr SlAs. Acordos de Nível de Serviços (Scrvtce Levei Agrccmcnts- SLAs) são contratos que definem p:mlmctros especificos de medida c níveis aceitáveis de desempenho do provedor de rede em rcla"io a essas medidas (Huston. l999a] . Vcrizon c Sprint são apenas dois dos muitos provedores de rede que garantem SU\s (Vcrizon, 2009: Sprint. 20091 a seus usuários. Alguns desses SLAs !klo: dtsponibilidadc de scf\•iço (interrupç-Jo de scf\iços), lat~ncia, \"a~ o c requisitos J>am notiflcaç-Jo da ocorrtncia de sef\•tço tntcrrompido. l! daro que, se um contrato espcclncar criténos de desempenho de prestação de serviços entre um provedor de rede e seus usuários. então a medição e o gerenciamento do desempenho do sistema também serão de gronde ímport.lncia para o administrador de rede.

Detcccao dr intrusos. Um administrador de rede provlwclmcnte ..-a, querer ser avtsado quando chegar tráfego de uma fonte suspeilil ou quando se destinar tráfego a ela (por exemplo, hospedeiro ou número de porm). Da mesma maneira, ele pode querer detectar (c, em muitos casos, flhr;~r) a existtncia de certos tipos de tráfego (por exemplo, pacotes roteados pela fonte ou um gronde nl'unero de pacotes SYN dtrlgidos a um dado hospedeiro) que são C3mctcnsticos de determinados tipos de ataque à segurança que consideramos no Capítulo 8. J\ Jnternation:~ l Organlz:ttlon for St:mdardization (ISO) criou um modelo de gerenciamento de rede qlte é lltil para situ<~r os cenários :1prescmados em um quadro milis cstrutur:ldo. S;'lo dcrln id;~s cinco :lrcas de gcrcnciarncnlo de rede: Gcn·nclmncuro 'Ir cksc·mpcnlro. A met~\ do gerenciamento de desempenho é quantirlc:~r. medir, informar, :tnalisar c controlar o desempenho (por exemplo. utilização c vaz;\o) de diferentes componentes da rede. Entre esses componentes estão dispositivos individuais (por exemplo, enlaces, roteadores c hospedetros). hem corno :~bstraçOes rim a rim. como um trajeto pela rede. Veremos. em breve, que padrOes de protocolo como o SNMP (Simplc Network Managernenl Protocol - Protocolo Simples de Gerenciamento de Rede) (RFC 3410) desempenham um papel fundamental no gerenciamento de desempenho dn Internet. Gcrcncimnrnto de fallrns. o objetivo do gerenciamento de ralhas é rcgiSlr:lr, detectar c reagir às condiçOes de falha d:~ rede. A linha divisória entre gerenciamento de falha c gcrenctamcnto de desempenho é bastame indefinida. Podemos considerar o gerenciamento de falhas como o trotamento imediato de falhas tronsuónas da rede (por exemplo, mterrupç.\o de se"'iço em cnl:lccs, hospedeiros, ou em hardware e software de roteadores), enquanto o gerenciamento de desempenho adotil uma abordagem de longo prazo em relação ao desempenho da rede em face de demi\ndas variáveis de tráfego e falhas

bow4tto4ic~ Redes de tom putod ores e o Interne~1------------------------ocasionais na red e. Como acontece no gerenciamento de dese mpenho, o SNMP tem um papel fundamental no gerenciame nto de falhas. Grrrncicmrcnto ele confrgunu;clo. O gctcnclamcnto de configuraç;i o pcnmte que um ad min istrador de rede saiba quais dispositivos fazem pane da rede adm inrstrada c quais s:lo suas configuraç6cs de hardware e software. O [RFC 31391 oferece uma visão geral de gcrcnciamenLo e requisitos de configuração para redes IP. Gcrcndcrmcnlo de contcrbilizacdo. O gcrenciamcnto de co ntabilizaç;\o permllc que o admi nrstrador da rede espcclllque, registre e contro le o acesso de usu.trios c daspositivos aos recursos da rede. Quotas de uulização, cobrança por lllilização e alocação de acesso prkrlegmdo a recursos fazem pane do geren ciamento de contabilização. Grrcnciwncnro de scgrmrnca. A meta do gerenciamento de segura nça é controlar o acesso aos recursos da rede de acordo com alguma política dcfuüda. As centrais de distribuição de chaves c as au10rldades cenificadorns que eswdamos na Seç-Jo 8.3 solo componentes do gerenciamento de segurança. O uso de flrewalls para monitorar e contro lar pomos externos de acesso, rede, um tó pico q ue estudmnos na Seção 8.9, e outro componente crucial. Neste capítulo, abordaremos apenas os rudimentos do gerenciamento d e rede. Nosso foco é proposil:llmcnte somen te a infracstrtnura do gerenciamento de rede: a arquitetura geral , os protocolos de gerenciamento de rede e a base de informações que servem para um administrador de rede mant~·ln em pé c em funciona mento. N:'lo abordaremos os processos de tomada de dccis:\o do admin istrador de rede, que é quem deve planejar, analisar e reagir à5 informações gerenciais dirigidas à NOC. Nessa área estão alguns tópicos, como ldentiOcaç-Jo c gercnciarnrnto de falhas IKaucln, 1995; Mcdhi, 1997; Stcinder, 20021 , detccç.lo proativa de anomalias IThounn. 19981. correlação emre alam1es Uakobson, 19931 e outros mais. Tampouco :~bordaremos o tópico mars amplo do gcrencramento de serviços [Saydam, 1996; RFC 3053; AT&T SL\11, 20061- o forneci· mento de recursos, como largura de banda, c.:apacidade do servidor c outros recursos compul:lcionais c de comunicação necessários para cumprir os requisitos de serviço específicos da miss:\o de uma empresa. Nessa última área, padrões como o TMN IGiiüJo. 1995: Sidor, 19981 c o TINA IHarnada. 19971 . qur s:\o mais amplos. mais abrangemes (c alguns considernvelmentc muito mais pesados), abordam essa queslâo mais geral. l imit:~do- cxamin:~rc mos

·o

que é gerenciamento de rcder Essa pe rgunta é feita com frequ~ncia. Nossa discussão anterior expõs e ilustrou a necess idade de alguns usos do gerenciamento de rede. Concluiremos esta seç-lo com uma deOniç;lo de gerenciamento de rrd c em uma única scmcnça (e mbora um tanto longa c encadeada), dada po r ISa)·dam , L9961 : "Gerenciamento de rede inclui o orerecimenao. a integração c a coordcnac;lo de clcmcrliOS de hardware, sortwarc c humanos. para monitorar, testar, consulta r, configurar, an~lis.'1r, avnli:~r e controlar os recursos da rede, c de clcmcruos, para a1lsfnzcr às exij.tências operacionais, de desempen ho e de qttalidadc de serviço em tempo real :1 Ulll CUStO

razoável,"

É u ma sentença de pe rder o fOiego, mas é uma definição vi:lvcl. N;~s seções seguintes, acrescentaremos um pouco de recheio a essa dellniç:1o bt\Stame enx uta de gerenciamento d e rede.

9.2 Ainfraestrutura do gerenciamento de rede Vimos, na scç-Jo anterior, que o gcrc11ciamento de rede exige a ca pac•dndc de · monitorar, testar, consultar, configurar( ...) c controlar~ os componentes de hardware c software de urna rede. Como os dispositivos da rede Silo drstríbuídos, fazer isso exigirá, no mínimo, que o administrador possa coletar dados (por exemplo, para a finalidade de monitora~ilo) de uma cmidadc rem otn e efetuar mudanças nessa entidade (por exemplo , com role). ' esta seç-Jo, uma analogia humana será útil para entender a infraestru tura neccssaria para gerenciamento de rede. Imagine que voe~ seja o chefe de uma grandr organização que tem Oliais em todo o mundo. É tnrcfa sua assegurar que as diversas panes de sua organização operem sem percalços. Corno você o fará? No mínimo. você coletará dados periodicameme de suas filiais por meio de relatórios e de várias medições quantitativas de arivi-



557

dadc, produtividade c orçamento. De vez em quando (mas oào sempre), voe~ sem explicitamemc n01ificado da existência de um problema em uma das filiais: o gereme da filial que quer galgar a escada corporativa (e talvez ficar com seu cargo) pode enviar relatórios não solicitados mostrando que as coisas est;lo correndo muito bem na filhll a seu ~.-argo. Voe~ examinará os relatórios que receber esperando encontrar operações regulares em todos os lugares. mas. sem duvida, encontrará problemas que precisarão de sua atenção. Você poderá iniciar um diálogo pessoal com uma de suas filiais problemáticas, coletar mais dados para entender o problema e, entâo, passar uma ordem executiva (•Faça essa mudança!· ) ao gerente da filial. Implícita nesse cenllrio hum:mo mui to comum esui uma inrracstrmura para controlar a organização- o chefe ('•od~). os locais remotos que cstâo sendo controlados (as filiais). seus :~gentes remotos (os gerentes das filiais). protocolos de comunicação (para transmitir relatórios c dados padronizados e para di:Uogos pessoais) e dados (o conteúdo dos relatórios e as medições quantitativas de atividade, produtividade c orçamento). Cada um desses com· ponenLes do gcrcnci::une nto organizacional hu mano tem uma comrapartida no gerenciamento de rede. J\ arqui 1c1um de um sistema de gerenciamento de rede é conecilualmcnte idêntica a essa analogia simples com um:\ organlza(,":\o h umana. O campo do gerenciamento de rede tem sua terminologia especifica própria para

os vários componemcs de uma arquitcwra de gerenciamento ele rede; t:x>ruuno, :•dotamos :1q11i css.1 tenninologia. Como mostra a Figura 9.2, há trCs componentes principais ern uma arqu itetura de gercllcinrnento de rede: uma emicl:1de gerenciadora (o chefe, "''analogia nprcscmada), os dispositivos gerenciados (as Ollals) c urn protocolo de gerenci:uncnto de rede. A entidade gere nciad ora é uma aplicação que em geral tem u m ser hu m:mo no circuito c que é executada em uma estação central de gcrtncia de rede na :-.JOC. Ela é o lócus d a ati,•idade de gerenciamento de rede; ela comrol:1 a coleta. o processamento. a análise e/ou a apresemaç;lo de inronnaçOes de gcrend:uncnto de rede. É nela que Sâo iniciadas ações para controlar o comportamento da rede e é aqui que o administrador humano interagc com os dts positivos da rede. Um d isposit ivo ge renciad o é um equipamento de rede (incluindo seu software) que restde crn uma rede gerenciada. Ele corresponde a filial de nossa analogia humana. Um dis posnivo gerenciado pode ser um hospedeiro. um roteador. uma ponte, um hub, uma impressora ou um modem. No interior de um dispositivo geren· ciado pode haver di,•ersos objetos gerencia d os. Estes s-Jo. na ''erdade, as peças de hardware propriamente di tas que estão dentro do d1spos11i\'O gerenciado (por exemplo, uma placa de interface de rcdc) c os conjuntos de par-.lmetros de configumç-'0 para as peças de h:trdware c software (por exemplo, um protocolo de roteamen to intradonunlo. como o RIP). Ern nossa analogia lmmana. os objetos gerenciados podem ser os departamentos existentes na Olial. Esses objetos gerenciados tem informações assoc1adas a eles que silo coletadas dentro de uma Base de Informa ções de Ge.ren d a mcn to (Managemcntlnformation Base- MIB): veremos que os ,•alores dcs· sas inrormaçOes estão disponíveis para a entidade gerenciadora (c. em muitos casos, podem ser ajustados J:x>r ela). Em noss" analogia hum:m:~ , a MIB corrcspondc aos dados quamitativos (mcdil,"ões de atividade, produtividade c orçarnemo. podendo este último ser cst:lbelccido pela entidade gerenciadora!) que s<\o trot
nm.

O tcrcctro componente de uma arquitetura de gerenciamento de rede ~ o protocolo d e gerenciamento de: red e. Esse protocolo é executado emrc a entidade gerenciadora e o agente de gcrcncl.unento de rede dos disposi· tivos gerenciados. o que permite que a entidade gerenciadora investigue o estado dos dispositivos gerenciados e. indtretamente. execute açOcs sobre eles mediante seus agentes. Agentes podem usar o protocolo de gerenciamento de rede para inrormar à entidade gerenciadora a ocorrência de c"emos cxccpc1onais {por exemplo. ralhas de componentes ou "iola~·âo de patamares de desempenho). t importante notar que o protocolo de gcrencia· mcnto de rede em s1 nâo gercncia a rede. Em vez disso. ele romcce uma rcrramcnta com a qual o administrador de rede pode gerenciar ( "monitorar, testar, consultar, configurar, analisar, amliar c com rolar·) a rede. Essa é u ma distinção sutil, mas importante.


Dispositivo geren
~ Protocolo de gerenciamento de rede

Dispositivo gerenciado

Dispositivo gerenciado Dispositivo gerenciado

Figuro 9.2 Prin
Embora a Infraestrutura do gerenci:uncnto de rooc sejn concehualmcmc simples, podemos nos :urapaU1ar com o vocabulário especial de gcrcnctamcnto de rede, como os termos ·cnlid:ldc gerenciadora', 'dispo:,ilivo gcrc~1ciado'. 'o\gcntc de gercncmmento' c 'base de mformaçOcs de gcrcnctamcnto'. Na tcmlinologra do gerenciamento de rede. em nosso cenário simples de monitoraç;lo de hospedeiros, 'agentes de gerenciamento' localizados em 'dispositivos gerenciados· s.lo periodicamente ex:uninados pela 'entidade gerenciadora'- uma idcia simples, mas um problema linguístico! Mas, com um pouco de sorte, lembrar sempre da analogia com uma organização hum01na c seus óbvios paralelos com o gcrcndamemo de rede nos ajudMâ neste capitulo. Noss:. discusst\o anterior sobre arquitetura de gerenciamento de rede foi gcntrit'a c se aplica, em geral, a vários padrões c esforços de gerenciamento de rede que vêm sendo propostos há anos. Os padrões de gcrc nclamcrno de rede comc~·aram a amadurecer no final da d~cada de 1980, sendo que o OSI CMISEICMIP (Co rnmon ManagcmenL Service Elcmem./Common Management lnformation Protocol - Elemento de Serviço de Gerenciamento Comum/Protocolo de InForm ação d e Gerenciamento Comum ) [l>is<.1Hcllo, J993; Stallings , 1993: Glilho . 19981 c o SNMP (Simplc Nctwork M:magemcnt Protocol- Pro tocolo Simples d e Gerenciamento d e Rede) da Internet (RFC 3410; Stallings, 1999; Rose. 1996[ emergiram como os dois padrões mais irnponantes [Miller, 1997; Subram:mian, 2000]. Ambos romm projctttdos para ser indep(·ndemes de produtos ou de redes de fabric-.uues especificos. Como o S. MP foi projetado e orereddo rap1damentc em uma época em que <1 necessidade de gerenciamento de rede começ.w:1a ficar premente, ele encontrou urna ampla aecltaçi\0. Hoje, esse proLocolo é a estrutura de gerenciamento de rede mais amplamente usada e disseminada. t\bordarcmos o SNMP em detalhes na S~

Gerenciamen to de re de

559

Acentral deoperações derede do SprintUnk Hó rodos de todos os tamanhos e formatos. Desde o menor dos rodes residenciais oté o moior dos ISPs do nível 1, cobe oo operador (ou oos operadores) do rode gorontir que suo operoçõo sejo tronquilo. Mos o que acontece em umo central de operações de rede (NOC) e o que um operador de rede foz, no realidade? Com umo rede que otrovesso o mundo, o Sprint opero umo dos moiores redes IP Tier 1 do mundo. Conhecido corno Sprintlink (mois infOfmoções em www.sprint.com), o rede possui mois de 70 pontos de presença (POPs sõo locais que contêm roteadores IP Sprintlink onde clientes se interconedom com o rede) e mais de 800 roteadores. é muito largura de bondol A principal NOC do Sprinttink locolizo·se em Reston, VA, e NOCs de suporte locolizom-se no Flórido, Geórgia e Konsos Oty. A Sprint também montóm NOCs poro suo rede de caixas efetrônicos, rede frome-reloy e rede de 1Tonsporle de Bbro óptico subjacente. A qua lquer tempo um grupo de qua tro centrais operoclonois estó monitorado e gerenciando os equipamentos e o núcleo do rede IP SprintUnk. Outro grupo estó lidando com regis1Tos de problema s de clientes e respondendo às suos solicitações. A outomoçõo - em mon itoraçõa (correlação de alarmes. identificação de folhas e restauração de serviços), gerenciamento de configuração e relatório de problemas dos clientes - possibilito que esse grupo extraordinariamente reduzido de operadores gerencie essa rede tõo grande e complexo . Quando ocorre um problema, o preocupação principal do operador da Sprintlink é monJer, oo restaurar rapidamente, o serviço oferecido aos clientes. Os operadores do NOC fazem triagem, diagnóstico e etopos de reslauroçõo seguindo um conjunto definido de procedimentos correspondentes o um conjunto conhecido de problemas. Problemas que nõo podem ser diagnosticados imediatamente, ou que nõo podem ser resolvidos por operadores dentro de um período de tempo específico que depende do nível de seriedade do problema (por exemplo, 15 minutos), sõo passados poro membros do National Technicol Assistonce Conter (NTAC) da Sprinl, que oferecem suporte. Os técnicos do NTAC dedicam-se o estudar o fundo os cousos dos problemas; eles também redigem procedimentos poro o NOC e, quando necessário, lrobolhom com fornecedores de equipamentos (por exemplo, fabricantes de roteadores) poro diagnosticar e resolver problemas relocionodos o equipamentos específicos. Aproximadamente 90% dos problemas sõo trotados diretamente por técnicos e engenheiros do NOC. O pessoal da NOC e do NTAC também interoge com outros grupos, incluindo parceiros NOCs (internos e externos) e grupos de campo da Sprint que sõo os 'olhos, os mõos e os ouvidos' dos POPs do Sprint.

Técnicos do Spfint monitoram o saúdedorede emcentros de operação como o mostrado acima.


Como discutimos anteriormente neste capítulo, o 'gerenciamento de rede' no Sprintlink (bem como em outros ISPs) evoluiu do gerenciamento de folhas poro o gerenciamento de desempenho poro o gerenciomenta de serviços, com ênfase codo vez maior nos necessidades do cliente. Embora decm o máximo atenção os necessidades dos clientes, os operadores do Sprint tombém se orgulham muito de suo excelência operocionol e do popel que desempenham no manutenção e no segurança do infraestrutura do rede globo! de um dos maiores ISPs do mundo.

9.3 Aestruturo de gerenciamento padrão do Internet Ao contrário do que o nome SNMP (protocolo simples de gcrcnclamcmo de rede) possa sugcnr. o gcrenci~· mcnto de rede na Internet~ mui to mais do que apenas um protocolo ~ra transportar d:Jdos de gerenciamento cnlrc uma entidade gerenciadora c seus age ntes, c o SNMP passou a ser muito mais complexo do q ue a palavra 'simples' (o 'S') possa sugerir. As mlzes da atual esmuura de gerenciamento padr.lo da Internet (In ternet Stnndard Mnnagemem Fr:unework) remontam ;~o SGMP (Simple Ga teway Monitoring Protocol- protocolo de mollitOrlllllento do gate· way simples) IRFC 1028). O SGMP roi t>rojet~do por um grupo de pesquisadores. us uários c adml nist mdorcs uni· versit:lrios de rede, cuja expcriCncia com esse protocolo permitiu q ue eles projetassem, lrnp lcmcruasscm c ofereces· sem o SNMP em poucos meses ILynch, 1993) - um feito muito distante dos processos de paclroniz~çllo atuais, que são bastante prolongados. Desde emâo, o SNMP evoluiu do SNMPvl para o SNMPv2 c chegou à sua vers.lo mais recente, o SNMPv3 IRFC 3410) , l:mçada em abril de 1999 e atualizada em dezembro de 2002. Na dcscriç:)o de qualquer estnuura para gerenciamento de rede. certas questões devem incvitavelnwntc ser abordadas: O que esta sendo monitorado (de um ponto de vista semântico) ? E que tipo de comrolc pode ser cxcr· c1do pelo admi nistrador de rede? Qual to modelo específico das inrom1ações que serao rdacadas e/ou trocadas? Qual é o protocolo de comunit-açào para trocar essas inrormaçocs? Lembre-se de noss.1 analogia hu mana apresentada na seção anterior. O chefe c os gerentes das filiais prc· cisar.lo acertar entre eles as medições de aúvidadc. produúvid:~dc c orç:uncnto que scrlo usadas p:tra rehuar a situa~o,rotocolo de comunka~<'lo) deve ser especificada. A estrutura de gerenciamento pndnio da Internet aborda essns questões. A estrutura é constitu íd:t de q umro partes: Definições dos ol>jttos clr gerenciamento (.lc rcclc, conhecidos l'omo objetos MIB. Na Estnllura de Gerenciamento de Padrão da Internet. as informações de gerenciamen to s;lo representadas como uma colct:lnc~• de objetos gerenciados quc. jumos. [onnamum b;tm:o virt mtl de inrormaçOcs virtuais conhecido como MIB. Um objeto MIB pode ser um comador, tal como o número de datagra mas IP descarta· dos em um roteador de,•ido a erros em cabeçalhos de dat<~gramas IP ou o nume ro de erros de dctecçrto de portadora em uma placa de imerrace Ethernet; um conJunLo de mrormaçOes dcscriLI\'as, como a vcrsJo do sortwarc que está sendo cxecut.1do em um servidor DNS: informações de es tado, como se um determinado dispositivo está funcionando corret


561

Urna liuguagtm dt cltflniçclo de dados, conhecida corno SMI (Structure of Managemem lnformation Estrutura de lnforma"'o de Gerenciamento), que define os tipos de dados, um modelo de objeto e regras p:~ra escrever c revisar tnformações de gcrtnciarnemo. Objetos MIB são espccincados nessa linguagem de ddlniç;lo de dados. Em nossa analogia humana. a SMI é usada pam definir os detalhes do formato das informações que serão trocadas. Um pro10colo, SNMP. O SNMP é US
Capaciclacles clr scgura111;a c ele culmínistraçào. A adição dessas capacid:1dcs representa o aprimo ramento mais importante do $1'\MPv3 em comparação com o SNMPv2. Assim, :1 arquitetura dl' gercnclmncnto da Internet f modular por projeto, com uma linguagem de definição de dados c de MIB independente de protocolo c um protocolo independente de MIB. O intercssaruc é que essa arquitetura modular foi primeiramente criada para f.'lcili tar a transição de um gerenciamento de rede baseado em SNMP para uma estnuura de gcreneiarncmo de nxle que estava sendo desenvolvida pela ISO. que era a arquiletura de gc renciamcruo que concorria com o SNMP qu:mdo este foi projetado - uma transiç-Jo que nunca aconteceu. Com o tempo, contudo, 11 rnoduh,ridade do projeto do SNMP permitiu que ele e''Oiufssc medi ame tr~ importantes rc,•isõcs, corn cada uma das quatro panes do SNMP discutidas ar11eriom1entc se desenvolvendo independentemente. fícou bem claro <1ue a decisão pela modularidade foi correta, alnda que tenlw sido tomada pela raz:1o errada! Nas subseções seguintes, examinaremos com mais detalhes os quatro componentes mais import:mtes da estrutura de gerencinrncmo padnio da Internet.

9.3.1 SMI (Estruturo de Informações de Gerenciomen1o) t\ Estruturo de Inform açõeS de Gerenciamento (Strueture o f Managernentlnformauon- SMI) {um componente da estrutura de gcrcnciamcmo de rede cujo nome é bastante estranho c não dá nenhuma pista quanto à sua funcionalidade) é a linguagem usada para definir as informações de gerenciamento que residem em uma cnudadc gerenciada de rede. Essa linguagem de dcfiniç-ao é necessária para assegurar que a sintaxe e a semâmica dos dados de gerenciamento de rede sejam bem definidas e não apresemem ambigUJdade. Note que a SMI não define uma inst;incia especifica para os dados em uma entidade grrcnciada de rede, mas a linguagem na qual a informação cstã especificada. Os dcx:umentos que descrevem a SM l para o SNMPv3 (confusamente denominada SMI"2) slo (RFC 2578; RFC 2579; RFC 2580]. Vamos examinar a SM I de b:lrxo para cima, começando com seus tipos de dados l>ásicos. Em seguida, examinaremos como os objetos gerenciados são descritos em SMI c, então, corno os objetos gerenciados relacionados entre si são agrupados ern módulos.

Tipos de dados básicos do SMI O RF C 2578 cs1>ecinca os tipos de dados báskos da linguagem SMI ele definição de rnódt1los MIB. Embora a SMI seja basc:lda na linguagem de de!lniç:lo dP objetos ASN.I (t\bstmc:t Syntax Notatlon One - notação de shll;l xe :1bstrata 1) [ISO, I 987; ISO X.óBO, 20021, ta mos formn os Lipos de dados específicos da SMillerescentados que esta de,•e ser considerada uma lingu
Construções SMIde nível mais alto Além dos tipos de dados bás1cos, a línguagen1 de definição de dados SMI também fornece construções de linguagem de nível mais alto.

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r o;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

rfPO de dado

Descri~õo

INTEGER

Nc.nero ilteiro de 32 bits,
lntege132 000 STRING OBJEa IDEIHIFIER Eooereço IP COUiter32 COUiter64 Gouge32 nmeftcks Opoque

Tabela 9.1 Tipos de dados bósicos do SJ~I A consmt~"<\O OBJECT-TYPE é utilizada para especificar o tipo de dado, o st;Hus c a scm:lntica de um objeto gerenciado. Esses objetos gerenciados contêm, colclimmcnu~. os dados de gerenclamcmo que cstllo no cerne do gerenciamento de rede. Há mais de dez. mil objetos defi nidos em diversos RFCs da Internet IRFC 3·H O) . A constru~llo OBJECT-TYPE tem quatro cláusulas. A cláusula SYt TAX de uma dcOmç:\o OBJECT-n ' PE cspcciflca o tipo de dado basico associado ao objeto. A clausula MAX-ACCESS cspecrfica se o objeto gerenciado pode ser lido, cscnto, criado ou ter seu valor incluído em uma notificação. A cláusula STATUS mdica se a definição do objeto é atual c ''áhd


Discontinuities in the value of this counter can occur at re-1nitialization of the management system. and at other times as lndicated by the value of ipSystem· StatsDiscontinuityTime." : := I ipSystemStatsEntry 18 I A construç;\o MODULE-IDE. TlTY pennite que objetos relacion:tdos cmre si sej:tm :tgrupados. como con-

jumo, dentro de um 'módulo'. Por exemplo. o RFC _.293 cspccifka o módulo MlB que deOnc objetos gerenciados (incluindo lpSystemStatslnOel ivers) para gerenciar implementações do IP c de seu protocolo associado, o ICMP. O RFC -f022 cspccificn o módulo MIB p3ra TCP, c o RFC 4 133 especifica o módulo MIB p:1ra UDP. O RFC 4502 dcOnc o módulo MIB para monitom\:.'lo remota, RMON. Al~ m de conter as defi nições OBJ ECT-TYPE dos objetos gerenciados dcmro do módulo, a constnu;-;io MODULE-lDENTlTY contém cl:iusulas pnm documentar ínfom1açõcs de cont:JtOdo autor do módulo, a dnta da último atuali:taçào, um histórico d e revisões c umn descrição textual do módulo. Como exemplo, considere o módulo de definíç" DESCRIPT!Oif: "The HIB module for managlng IP and ICMP lmplementations. but excludlnwg their management of IP routes. " Copyrlght C The Internet Society <2006). Thls version of this t~IB module ls part of RfC 4293 : see the RFC ltself for full legal notfces. R(VISION DESCRIPTIOII

" 200602020000Z "

"The IP version neutral revision wi th added JPv6 objects for tW. default routers. and router adverlisements. As well as being the successor to RFC 2011. thls MlB ls also the successor to RFCs 2465 e 2466. Publlshed as RFC 4293." REVISIOtf DESCRI PT JOtl

REVIS!Otl DESCRIPT!Otl

"199411010000Z"

"A separa te HIB module ( IP MIB) for IP and ICHP management objects . Publfshed as RFC 2011. " "199103310000Z"

"The initial revision of this HlB module was part of MIB-11. which was published as RFC 1213 ." · · • I mib-2 481


i\ C:OI\Stru\·:lo NOTIFICAT IO, -n' PE é usada paro especificar informações referentes a mensagens 'SNMPvl-

Trap' c 'lnformatlon Rcqucst' (solicitaÇ'JO de mformaçoes) gcmdas por um agente ou por um:t entidade gcren· ciadora; veja a $cç;'lo 9.3.3 Entre essas informações est~o um tex to de descrição (DESCRIPTIO~ ) que especifica quando tais mcns:tgcns de,•em ser enviadas, bem como uma lista de valores que devem ser inclu1dos na mensagem gerada; veja o RFC 2578 para ma1s dc1:1lhcs. t\ construçM MODULE· COMPLit\NCE deOne o conJunto de objetos gerenciados dentro de um módulo que um agente deve implementar. i\ construção AGENT-Ct\Pt\BILITIES especiOca as capacidades dos agentes relati\'aS às ddiniçOCS de notiOcaÇ'JO de objetos c de eventos.

9.3.2 Base de informações de gerenciamento: MIB Com dissemos a111criormcnte, a Base d e lnfonnaçõcs de Gerenciamento (Managemcnt lnform:uion BnscMII3) pode ser imaginada como um banco vi rtual de informações que guarda objetos gc renci:~dos cujos '"'lorcs, colet i\~.unentc, reOctcm o ·est:~do' atual d;~ rede. Esses ''ltlores podem ser consultados dou dcnnidos por uma entidade gcrcnciadorn por meio elo envio de mensagens SNMP ao agente que está rodando em um dispositivo gerenciado em no me da entidade gerenciadora. Objcws gcxenciados são cspeciCicados Ulilizando a construção OBJECT-TYPE da SMI disclllidn anteriormente c agmpados em mód ulos M IB utilizando a const mc~\o MODULE· IDENTITY. IETF tem estado muito at:~rcfad<1 com a padronizaÇJ'O de módulos MIB associados 11 roteadores, hospc· dciros c outros equir>amcntos de rede. o que inclui dados b:\sicos de identiOcaçâo sobre um determinado componente de hardware c infonnaçOes de gerenciamento sobre as intcrfuecs c os protocolos de dispositivos da rede. Atf 2006 hav1a mais de duzentos módulos MIB baseados em padrõeS c um mimero ainda maior de módulos MIB espcc1fkados por fabru:antcs privados. Com todos esses padrões, a IETF prec:IS:t\'a encontmr um modo de identi· Ocar c dar nome aos módulos padronizados, bem como aos objetos gerenciados especiCicos dentro de um módulo. Em vez de começar do nada, a IETF adotou uma estrUlura padronizada de idcntlnc:aç;lo de objetos ( nomeação) que já unha s1do pubheada pela ISO. Como acontece com munas entidades dedicadas à padronização. a ISO tinha 'grandes planos' para sua estrutura padronizada de identiCieaçi\o de objetos - identificar todo e qualquer objeto padronizado possível {por exemplo , fonnato de dados. protocolo ou infomtaç.lo) em qualquer rede, independentemente das organizações dedicadas à padronizaç:lo das redes {por exemplo, IETF, ISO, IEEE ou ANSI) , do fabricante do equipamento ou do proprietário da rede. Um objetivo bem grandtoso mesmo! A estrutura de idcntificaç-lo de objeto adotada pela ISO é parte da linguagem de dcCinic:lo de objetos ASN .1 liSO X.680. 2002) . que disçutircmos na $cç.1o 9.4. Os módulos MIB padronizados j:l t~m seu próprio cantinho confortá,•el dentro dcssa cstrulllra de nomeação vastamente nbrangcnte, como ,·cremos :t seguir. 1\

Como mostra a Figura 9.3, pcht estrutura de nomcaÇ"àO da ISO, os objetos s;\o nomeados hierarq uicamente. Note que cada ponto de rumo d:-t :lrvore tem um nome c um número (entre pnrfnteses): assi m, qua lquer ponto da án•o rc pode ser identificado pela sequência de nomes ou nümcros que cspcciOcam o trajcao da ra iz até aquele ponto da árvore de idenLírlcação. Um programa baseado na Web- cJi,•CI'tido, mas iucompicto c não oficial - que perCOrre parte da :lrvorc de idcntificaç.io de objetOS (usando informaÇilCS SObre OS r:llliOS o rcrcddas por voluntários) pode ser cncomrado em IAivestrand, 199il c !Fmncc Telccom, 2006). No aopo da hierarquia estão a ISO c o ITU-T, as duas principais entidades de paclroniz:~çào que muam da ASN.I , bem como um ramo para o esforço eonjumo realizado por essas du:IS organizações. No mmo ISO da án•orc, cncomrumos rcgisLros para todos os padrões ISO (1.0) c para os padrões emitidos por emidades padromzadoras de vários p:tiscs membros da 150 ( L2). Embora não apareça na Figura 9.3 , 1ogo abaixo desse ramo da án•ore (ISO/paises membros, também conhecido como 1.2), cncontrari:unos os Estados Unidos (1.2.1HO), embaixo dos quais cncomrarfamos um numero para os padrões IEEE c ANSI c para os p;~drõcs especfCicos de empres:\S pnvadas. Entre as cmprcsns privadas, estão a RSA (1.2.840.11359) c a Microsoft ( 1.2.840. 113556), sob a qual encontraríamos os Microsoft File Fonnats (1.2.840.113556.4) para \'oirios produtos da Microsoft, como o Word ( 1.2.840. 113556.4.2). Mns estamos interessados em redes (c não nos arqutvos do M1crosoft Word), portanto, vamos voltar nossa atenção ao ramo denominado 1.3, os padrões emitidos por entidades reconhecidas pela ISO. Entre estas escao o Departamento de Defesa dos Estados Unidos (6) (sob o qual encontraremos os padrões


ITU-T (0)

ISO (1)

Standard (0)

ISOmember body(2)

Joint ISOIITU-T (2)

I

ISO identified organization (3)

I

IJ

us

OoO (6)


" NATO

Open Software Foundation (22)

I I

identifi ed (57)

Internet (1)

I

I

I

I

I-

I

I

dlree1ory

management

experimental

prívate

secunty

snmpv2

ma ll

(1)

(2)

(3)

(4)

(5)

(6)

(7)

I

M IB-2 (1)

system

interface

(1)

(2)

I

I

address translatíon

ip (4)

I

I

icmp

tcp

udp

egp

(S)

(6)

(7)

(8)

cmot transmission snmp (9)

(tO)

(11)

·;--,I rmon (16)

(3)

figuro 9.3 Álvore de íden~ficodores de objetos ASN.l da Internet). a Opcn Software Foundation (22), a associaç-lo de empresas a~rcas SITA (69) c as entidades idcmificadas pela OTAN (57). bem como muitas outras organizaçocs. Sob o ramo In t ernet da :\rvore (1 .3.6. 1). há sete am~gorias. Sob o ramo prl v a te ( 1.3.6. 1--t). encontramos uma lista IJANA. 2009b} dos nomes e códigos de empresas privadas para as mais de quatro nu I empresas privadas que se registraram na lmernct Assigned Numbcrs AUihority (IANA) (IANA, 2009a} . Sob o ramo mana ge men t ( 1.3.6. 1.2) c HI B-2 ( L3.6.1.2. l ) da árvore, encontramos a definição dos módulos MIB padronizados. Puxa! É uma longa jornada ate chegarmos ao nosso cantinho no cspaco de nomes da ISO!

Módulos MIBpadronizados O ramo mais baixo da árvore da Figura 9.3 mos tra alguns dos módulos MIB oriemados para hardware importantes (sys tem e 1n t erface) , bem como módulos associados a a lguns dos protocolos mais importan tes da Internet. O RFC 5000 rcl:~don;~ todos os módulos MIB p:.dronizados. Embora os RFCs rcrcrcntcs às Mll3s sejam u ma leitura tediosa e difrcil, é muito instrutivo (isto é, assim como comer verduras, "é I>Om p:~ra voei!") considerar algumas definições de módulos MIB para ter uma idein do tipo de inform;~çào que existe dentro de um módulo. Os objetos gerenciados que fkam sob o título system co111êrn informa~·ões gerais sobre o dispositivo que está sendo gerenciado; todos os dispositivos gerenciados de\'em s uportar os objetos MIB do grupo system. A Tabela 9.2 define os objetos gerenciados no grupo system. de acordo com o RFC 1213. A Tabela 9.3 define os objetos gerenciados no módulo MIB para o protocolo UDP em uma enudade gcrcnc~ada.

9.3.3 Operações do protocolo SNMP e mapeamentos de transporte O SNMPv2 (RFC 34161 é usado para transponar informações da MIB entre cntidndes gerenciadoras e agentes, executando em nome das entidades gerenciadoras. A utilização mais comum do SNMP é em um modo co mando-resposta, no qual a entidade gerenciadora SNMPv2 envia uma requisição a um agente SNMPv2, que a

bow4tto4ic~ Redes de compu tadores e o In terne~!----------------------

Desu~ão

Nome

flpO

1.3.6.1.2.1.1.1

sysDescr

OCTH STRING

1.3.6.1.2.1.1.2

sysObjectlD

OBJECT IDEJlnFIER

ID orriblido pelo foOOconre do objeto que •fonleCe tl1l me~ lóci e nõo omljp poro determilol 'que tipo de coixo' estó sendo getenõodo:

1.3.6.1.2.1.1.3

sysUpTime

fmelicks

·o tem;x> (em centésimos de segoodo) desde que opor(ôo de gerencio-

1.3.6.1.2.1.1.4

sysContacl

OCTET STRING

"A pes.soo de conroto po10 esse n6 gerenôodo, jl.rltomenle com o infOIITlO" ção sobre como tonlctó-lo.•

l.3.6.l.2.l.l.S

sysName

OOHSTRING

·um nome atribuído odmillisrrolii'Omet~le poro esse n6 geteoc~do. Por conventõo. esse é o nome de donínio totolmente quordicodo do nó.·

1.3.6.1.2.1.1.6

syslocatlon

OCTET STRING

·A lomizo~õo físico do nó."

ldenlifi
(segundo o RFC 1213)

"Nome cqleto e idenliflc~õo do 'ltiSÕO do tipo de hcrdwore do sislem~. do sistem~ operoOOrd do softwore e do softwole de rede.·

meoto de rede do sislemo foi re00of11odo petJ último vez:

Um I'Oior coo~i
sysServices

lnteger32

oplicoções físicos (p()j exemplo, 001 repetid01l, de er*Jce/StiHede (por exemplo, pootel. de lntetnel (pOI exemplo, g!ltewoy IP), fim oflm (por

exemplo, hospedeüo}. Tabela 9.2 Obietos gerenciados no grupo system do MIB-2 recebe, realiza alguma ação c envia uma resposta à requisição. Em geral, uma rcquis içào é usada para consultar (r~cupcrnr) ou modiOcar (definir) valores de objetos MIB associados a um dispositivo gerenciado. Um segundo uso comum do SNMP é para um agente enviar uma mensagem não solicitada. conhecida como mensagem trap. à cnudadc gerenciadora. As mensagens trap sM usadas para notificar uma entidade gercncs:tdora de uma s ituaÇão excepcional que resultou em mudança nos valores dos objetos MIB. Vimos anterionncnte, na Sc~o 9.1, que o admmístrndor de rede pode querer receber uma mensagem trnp. por exemplo, quando uma interface cai, quando o congestíon:uncnto atinge um nível predefinido em um enlace ou quando ocorre qualquer outro e,·emo notável. Obscn·e que há uma série de compromissos importantes entre consulta de objetos (mtcrnção comando-resposta) c envio asstncrono de mensagens nilo solucionadas; veja os excrcfcios ao final deste capítulo. O SNMPv2 define sete tipos de mensagens , conhecidas gencricamcmc como POUs ( !lrOiocol daw uníls), como mostra a Tabela 9.-t. O formato da PDU é mostrado na Figura 9.4. As PDUs GetRequest, GetNextRequest e GetBul kRequest s;lo enviadas de u ma entidade gerencia· dom a u m agente para requisi tar o valor d~ um ou mais objetos MIB no dispositivo gerenciado do agen te. Os idcmificaclorcs de objeto dos objetos MlB cujos valores estão sendo rcquisiwdos s:lo cspccincados na porç;lo de vi ncuht~lo de varl:lvcis da PDU. GetReques t, Gettlel\tReques Lc GetBul kReques Ldife rem

Desc~ão

Nome

Tipo

1.3.6.1.2.1.7.1

udp l nDa tdgraos

(ounter32

"número lotol de dotogroroos UOP entregues o usuários UDP"

1.3.6.1.2.1.7.2

udplloPorts

(ounter32

•númelo total de dotogromos UDP rece!Mdos poro os qoois nõo havia nenluno op&ooçõo no po110 de desmo·

1.3.6.1.2.1.7.3

udplnErrors

(0001er32

"fliÍmlo de doto~omos UDP rece!Mdos que nõo piJ!erom set entregues IJOf ollllos razões que não o falto de tl1lO opli
1.3.6.1.2.1.7.4

udpOutDatagrams

(OIII!er32

·IÚ!lefO rolei de do~oroos UDP enviados desso ervidode"

ldentifi
Tabela 9.3 Obietos gerenc.iodos no módulo MIB·2 udp

(segundo o RFC 4113)

bow4tto4ic~ Gerenciomuto de rede

Capitulo 9

T1p0 de SNMPv2·PDU

Remetente-receptor

Desc~ão

Ge· Reques ~

gerente oagente

pego o volol de umo ou roois instôncm de objetos MlB

GetNextReqvest

gesente oagente

pego o volol do próxillll instiilOO de objeto /.118 no tiSio ou tOOelo

GetBulkReques:

gerente oagente

pego vobes em !Joodes I*Kos de dodos,po~ exemplo, valores em lml!]loOOe toiJelo

lnformRequest

gerente ogerente

ilfonm ô enticble ge.enciodolo remoto v00es do MIB que silo remotos poro seu ocesw

SetRequest

gerente oagente

defme voiCJes de umo ou mois instõncios de ol'4etos AUB

Response

agente ogetente ou gerente oge.ente

gerado em resposta o GetRec1uest . GetNextRequest . GetBu 1kReques l. SetRequest

SN~1Pv2 ·l

rap

PDU

ou lnformRequest

informo oo gerente um evento excep
agente ogerente

Tabela 9.4 Tipos oo SI~MPv2-POUs no grau de especificidade de seus pedidos de dados. Ge tReques t pode rcquísit:tr u m conjunto arbitnírio de valores MIB; mühiplas Ge tllextReques t podem ser usadas para percorrer a scqutncin de uma hsta ou tabela de objetos MIB, c Get8u1kReques t permilc que um grande bloco de dados seja devolvido. evitando a sobrecarga incorrida quando tiverem de ser enviadas múltiplas mcttS;\gtns GetReques t ou Gettl extReques t. Em todos os tres casos, o agente responde com uma PDU Response que cont~m os rdemificadores de objetos c seus valores associados. A PDU SetReques t é usada por u rna enlidade gerenciadora para estabelecer o valor de um ou mais objetos MIB em um disposilivo gerenciado. Um agente responde com uma PDU Response que contém

uma mensagem Error Status ·no&ror' para conRrmar que o \'alor na ''crdade roi estabelecrdo. A POU l oformReques t é usada por uma em idade gerenciadora para comunicar a outra em idade gerenciadora inrormaçõcs MIB remotas â entidade receptora. A cnLidadc receptora responde com uma PDU Response com a mcns.-'lgcm Error StaLus ·noError· para reconhecer o rccebimemo da PDU I n fo r mRequest.

Getlset PDU

type (0-3)

Request

ld

header

error

Status (0-5)

POU

Type

Ent erprise Agent

(4)

Addr

Variables to getlset

Error

lndex

Trap Type

Name

Value

Specífic

Time stamp

code

(o-7)

Trap header

SNMPPOU

Figura 9.4 Formoto do SNMP·PDU

Namc

Name

Value

Value

,Trap information

_j


O tipo final de SNMPvl-PDU ~ a mensagem rrap. Mensagens lrllp 5<\o geradas :lSsincronamcmc, isto é, m\o s;\o gerad:lS em resposta a uma requisi ç;to recebida, mas em resposta a um evento para o qual a enudade gerenciadora requer nourlcação. O RFC 34 18 define tipos conhec1dos de trap que 1ncluem uma rxmida a frio ou a quente realizada por um dispositi\'O, a ativaç;\o ou interrupção de um enlace, a perda de um vizinho ou um evento de falha de autcnticaçôlo. Uma reqtusiçM de trap recebida não exige resposta de uma entidade gerenciadora. Dada a lll\turcza comando-resposta do SNMPv2, convém observar que, embora as SNMP-PDUs possam ser transportadas por muitos protocolos de transporte diferentes. clns s.'\o tipicamente transportadas na carga útil de um datagrama UDP. Na verdade. o RFC 3417 estabelece que o UDP é o 'mapeamento de transporte preferencial'. Uma \ 'CZ que o UDP é um pr01ocolo de transpone não confiável, não h:! garantia de qu e um comando ou sua resposta sen\ recebido no desuno pretendido. O campo Request Id da PDU é usado pela entidade gerenciadora para numerar as rcqt1isições que faz a um agemc: a resposta de um agente adota a Rcques t 10 do comando recebida. As.<;im, o c:unpo Rcqucst ld pode ~r usado pela entidade gcrcnciadom paro detectar t·oma ndos ou respostas perdidos. A entidade gerenciadora é quem decidirá se rctrans milir:l um comando se nenhu ma resposta correspondente for recebida após um dado período de tempo. Em p:mlcular, o p:1dr-Jo SNMP não impôc nenhum procedimento especifico de retransmissão. nem mes mo diz que o comando dc\'Cser CIIV i
9.3.4 Segurança e odministro~ão Os projetist:lS do SNMP\'3 têm dito que o-s ' MPv3 pode ser imaginado corno um SNMPvl co m capacidades adicionais de segurança c de administração" IRFC 3410). Certamente, há mudanças no SNMPv3 em relação ao SNMPv2, m:lS em nenhum lugar essas mudanças são mais cvidcmcs do que nas áreas da administmção c da segurança. O papel central da segurança no S:-.I:\I!Pv3 era paniculanncme importante. já que a falta de scguran~~ adequada rcsuha\'a no uso do SNMP primordialmente para monitorar. em vez de controlar (por exemplo, SetRequest é mmmcnte usada no SNMPv l ). À medida que o S• MP amadurecia, passando por tr~s versões, sua func10nahdade crescia, mas infelizmente crescia também o número de documentos de padro nizaç-.lo rclac1onados a ele. Isso fica evidenciado pelo fato de que há agom um RFC IRFC 34 111 que "descreve um:l arquitetura para descrever os Amb1cntes de Gerenciamento doS MP"! Embo ra :1 ideia de uma 'nrquitcLUra' para 'descrever um ambiente' poss.1 ser um pouco excessiva para nossa cabeça, o objetivo do RFC 34 l i é admirável- introduzir uma linguagem comum para descrever a funcionalidade c as ações execu tadas por um agcme ou entidade gcrenclaelora SNMPv3. A arquitetura de uma em idade SNMPv3 c direta, c viajar por ela servirá para solidj(\car nosso entendimento do SNMP.

As denominadas aplica ções SNMP conslstcm em um gcrndor de comandos, um receptor de notificaçõcs e um transmissor proxy (todos normalmente encontrados em uma entidade gerenciadora): um elemento rcspondedor de co mandos c um origmador de notincações (ambos tipicamente encontmdos em u m agente), e na possibilidade de outras a1>licwOcs. O gerador de comandos gera as PDUs GetReques t. Ge tNextReques t. Get8u1 kRequest c SelRequesl, que cx:uninmnos na Seção 9.3 .3. c proccss:t as respost:\S recebidas dessas PDUs. O elemento respondcdor de comandos executa em um agente c recebe, processa e responde (usa ndo a mensagem Rcsponsc) às PDUs GetRequest, GettfextRequest, GetBulkRequest c SetRequest recebidas. A aplicação originadom de no tificações de um agente gera POUs Trap; essas POUs podem ser recebidas e processadas em uma aplicação receptora de notificações em uma enudade gerenciadora. A aphcação do transmissor proxy repassa :lS PDUs de requisição, notifkação c resposta. Uma PDU c1w1ada por uma aplicação 5:-.IMP passa. em segmda. por um ·processador' S MP. antes de ser cn"iada ' 'la protocolo de tmnsporte apropriado. A Figura 9.5 mostra como uma PDU gcmda pela aplictção geradora de comandos entra primeiramente no módulo de despacho. onde é determinada a vcrs;lo do SNMP. A PDU é então processada no sistema de processamento de mensagens, no qual é envelopada em um cabeçalho ele mensagem que contém o número da versão do SNMP, uma mensagem ld e informações sobre o tamanho ela mensagem.


Gerador de comandos


569

Transmissor proxy

Aplicaç6es SNMP

Outro

POU Segurança !--

Processador SNMP

Despacho

Sistema de processamento dl! mensagens

Temporizaç~o.

autentkaç3o, privacidade

Controle

de acesso

Cabeçalho de segurança/mensagem POU

Cêlmada de transpoMe

Figura 9.S Processodor eaplicações do SNMPv3 Caso scp necessária cnptografia ou autenticação. São incluidos tambt m os campos de cabe~-alho apropnados para essas infom1açôcs: veja o RFC 34ll para mais detalhes. Por fim , a mensagem SNMP (a POU gerada pela aplicação e mais as Informações do cabeçalho de mensagem) é passada ao protocolo de transporte apropriado. O protocolo de transporte preferencial para transportar mensagens SNMP é o UDP (isto é, as mcns.1gcns s, MP ~ o tra nsportadas como carga útil de um datagrnma UDP), c o numero de porta preferencial para o SNMP é a porta 16L A porta 162 é usada para mcns.1gens trap. Vimos anterionncn tc que as mensagens S::-JMP s:'!o usadas não somente para monitorar, mas ta mbém para controlar (por exem plo, por meio do comando Se tReques t) elementos da rede. J: claro que um intruso que conseguisse interceptar mensagens SNMP e/ou gerar seus próprios pacotes SNMP n:1 infraestrutu ra de gerenciamento poderia cri ar um gmnde tumulto n:t rede. Assim. t crucial que mensagens SNMP sejam tmns mttidas com segunuu;a. Surpreendentemente, fo i somente na ,·crsão mais recente do SNMP que n segurança recebeu a atcnç<'\o merecida. Sua sc:gur:.mça é conhecida como seguran ça baseada no ru.uár io (RFC 3'1 H J. pois miliza o conceito tradicional d e um usudrio, identificado por um nome de usuário, ao qual as mrormaçOcs de segurança - uma senha, u m valo r de chave ou acessos privilegindos - são associadas. O SNMPv3 rornccc criptogmfln, nuteruicaç-.\o, proteção contra :uaques de reprodu ção (veja a seção 8.3) c controle de acesso.

CrirJtogmfrcr. As SNMP-PDUs podem ser críptografadas usando o DES no modo Encadeamento de Blocos de Cifras. Note que, uma vez que o DES é u m slstcm:J de chaves comp:milhadas. o ''lllor da chave secreta dos dados de codificação do us uário deve ser conhecido pela entidad e receptora que deve decriptar os dados. Aultntimçclo. O SNMP usa a técnica de MAC que estudamos na Seção 8.3.1 p.1ra prover pro teção c autenticação contra aduhera~\o (RFC 2'1011. Lembre-se de q ue um MAC necessita que um emissor e um recepto r conheçam uma eha"e secreta comum. Protcçclo contw ataquts ele rfpmducdo. Lembre-se de que podem ser usados nonccs (veja o Capuulo 8) para proteção contra ataques de reprodução. O SNMPv3 adota uma abordagem relacionada. Para garantir q ue uma mensagem recebida não seja uma reprodução de alguma mensagem anterior, o receptor exige que o remetente inclua em cada mensagem um valor baseado em um contador no receptor.

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....Esse con tador, que funcíona como um noncc, reflete o período de tempo decorrido entre a ultima rcmicializaçilo do soft,,•are de gerenciamento de rede do remetente e o numero total de reinícializaçOcs desde a uh ima vez que o software de gerenciamento de rede do receptor for configurado. Contanto que o contador em uma mensagem recebida esteja dentro de uma detcrmmad:~ mr~rgcm de erro em rcl:~çilo ao próprio valor do receptor, a mensagem é aceita como uma mcns.1gem original e a partir daf pode ser autenticada e/ou decriptada. Cons ulte o RFC 3iH para mais detalhes. Controle tle acesso. O S1 MPv3 fornece um controle de acesso baseado em \'tSócs (RFC 3415) que con· trola quais das informações de gerenciamento de rede podem ser consultadas e/ou definidas por quais usuários. Uma entidade SNMP armazena infom1aç6es sobre direitos de acesso c polfticas em um banco de dados de co nfiguraç;\o local (Local Configuratlon DCIIastor·c - LCD). Partes do LCD sdO accssrveis ci~\S próprias como objetos gerenciados, definidos na MIB de Configuração do Modelo de Contro le de Acesso Baseado em ViSóes (View-llasecl Acccss Com rol Model Conflgurati on) IRF C 3415 1 c , portanto, pode m ser gerenciados c manipu lados remotamente via SNMP.

9.4 ASN.l Neste li vro. examinnmos uma série de assuntos interessa ntes sobre redes d e com putadores. Esta seção sob re a ASN.l, co ntudo, pode ni\o fazer parte da list.a dos dez tópicos mais interessantes. Assi m como r~s verdu ras, con hecer a ASN.l c a quest:\o mais ampla de serviços d e apresentação é algo que ·~ bom para voce·. A i\$1 . I é um padmo origin:~d o 11:1 ISO, usado em uma série de protocolos relacionados à Internet, particularmente na área de gerenciamento de rede. Por exemplo, vimos na Seção 9.3 q ue ;\S variávers M18 do SNMP cst:\o inextricavclmente lig
:1 seguir.

Co mo essa estru-

struct I char code : l nt .x: 1 t es t: tes t.x

tes t. code

259 :

·a·:

O lado esquerdo da Figura 9.6 mostra uma disposição possível para esses dados em uma arquitetura hipotétiCó\: há um ímico byte de memória que contém o caractere ·a·. seguido de uma pal:~vm de 16 bits que con tém

o valor mtelro 259. arm:1zenado com o b)rte mais significativo :lntes. A d lsposrç;lo 11:1 memória de um outro com· pulador é mostrada no lado direito d:1 Figura 9.6. O caractere ·a· é seguido pelo '"llor inteiro armazenado com o by tc menos significativo antes c com o inteiro de 16 bits alinhado para comeÇ:lr em uma fronteira de palavra de 16 bits . Certame nt e, se quiséssemos executar uma cópia ao pê da leLra entre as memórias desses dois computa-

bow4tto4ic~ Copitulo 9


571

Hó centenas (se não milhares) de produtos de gerenciamento de rede à disposição atualmente - todos incor· porondo até certo ponto os fundamentos de estruturo de gerenciamento de rede e SNMP que estudamos neslo seção. Um levantamento desses produtos estó bem olém do escopo deste livro e (sem dúvida) do ãmbito do atenção do leitor. Auim, fornecemos oqui indicações de alguns dos produtos mois proeminentes. Um bom ponto de portida poro se ter umo visõo geral do obrongêncio dos ferramentas de gerenciamento de rede é o Capitulo 12 do livro do (Subromonion, 2000). As Ferramentas de gerenciamento de rede podem ser divididos em duos classes amplos: os ferromer'ltos dos fabrica ntes de equipomenlos de rede, que são destinados oo gerenciamento dos equipamentos desses fobriconles, e os ferramentas que visam co gerenciamento de redes com equipamentos hetefogêneos. Entre as ofertes especf. ficas de fabricantes estó o software de ferramentas de gerenciamento de redo Network Applicotion Performance Anolysis (NAPA) do Cisco criado em um dispositivo-base do Cisco (Cisco NAPA, 2009]. A Juniper oferece sistemas de suporte oporocionol (OSSs) poro fornecimento de rede e suporte SWQoS [Junlper, 2009).

d ores c usar a mesma dcnniçao de estruwra para acessar os valores armazenados, \'Criamos rcsuhados diferemes nos dois computadores! O f:llo de diferentes arquiteturas terem diferentes formatos para os dados internos é um problema real e universal. O problema cs peclnco d o armazenamento de imciros em diferentes formatos é t;\o comum q ue tem até um nome. A ordem de armazenamento de inteiros ·big·endian' (extremidade maior) armazena primeiramente os bytcs m;lis significati vos ( nos endereços de armazenamento mais b:uxos). A ordem 'liule-cndian' (extremidade menor) annazcna primeiramente os brtes menos signincativos. Os processadores Sparc da Sun c os da Motorola sao do tipo 'big·endian'. ao passo que os processadores da Imel c d a DEOCompac Alpha s:\o do tipo 'liule-endian'. Como curiosidade. os termos 'big-endian·e 'liule-end1an' v~m d o liYTo Viagrns dt Gul/n•rr. de jonathan Swift , no qual do1s grupos de pessoas insistem. dogmaticameme. em fazer uma co1sa snnples de duas lllilllelras diferentes (esperamos que a analogia com a comunidade da arqu itetura de com putadores fique clara). Um grupo da Terra de Ulllput insiste em quebrar os ovos pela extrermdade maior (os 'big·cndlans'), enquanto o outro grupo insiste em quebrá-los pela cxtrcrnid:~dc menor. Essa diferença foi a call53 de um grand e conflito c de uma rebelião civiL V1$tO que

diferentes computadores am1azcnam c representam dados de modo diferente, como os protocolos de rede devem enfrentar o problema? Por exemplo, se um agente SNMP csúver prestes a enviar uma mens<\gcm Rcsponsc que contém um número inteiro q ue representa a contagem do numero de datagramas UDP recebidos, como ele dc\'cria rcprcscuwr o valor imciro a ser enviado à entidade gcrendadora- na ordem 'bíg·c nd ian' ou n:1 ordem 'liuJe-cndian'? Uma alternativa seria o agente enviar os bytes do inteiro na mesma ordem em que scrlo armazenados na entidade gerenciadora. Outra ahcrnativn seria o agcntc enviar o inteiro em sua própria ordem de annazcmuncmo, de ixando â entidade gerenci:~dora n respons.1bi lidade de reordenar os b)'lCS quando ncccssdrlo. Qu:~ lqucr um:~ dns altcrn;ulvas e.xiglri:• que o remetente ou o rece ptor soubesse qual o fonnato de reprcsenta~'ão de hneiros do outro. Uma tcrceim alternativa é ter um método independente de máquina, de sistema opemcional e de linguagem para descrever n(tmcros inteiros c outros Lipos de dados (isto é, uma linguagem de dcscriç;'o de dados) c regras que estabeleçam a maneira como cada um d esses tipos de dados de,•e ser transmitido pela rede. Quando forem recebidos dados de um determinado lipo. eles estarão em um rommo conhecido c, nssim, poderlo ser annazcna·

.. cest.x

tcst.co
..

00000001 00000011

teat.x

00000011 00000001

Figura 9.6 Duas organizações diferentes de dados em duas arquiteturas diferentes.


???

???

Adolexente de 2009

Hippie de meia·idade (dos anos 1960)

Figuro 9.7 OJ]foblemo do OJ]fesentoçõo dos em qualquer formmo específico que um dado computador exija. Tanto a SMI, que es tudamos na Scçào 9.3, qua nto a ASN. I adomm css:1 tcrccim a ltc rn ati\•a. No jarg;to da ISO, esses dois padrões descrevem um s erviço de apresen tação - o serviço de tmnsmiti1· c traduzir informações de um formato espcdfico de ttma máquina para outro. A Figuro 9.7 Ilustra um problema de aprcscmaç-.lo no mundo real; nenhum dos receptores entende a idcl:1 esscnci;~l que está sendo comunicada- que o interlocutor gosta de algo. Como mostrado na Figura 9.8, um servit;o de apresentação pode resolver esse problema traduzindo a ideia para uma linguagem intcligí'•el ( pelo serviço de apresentação), independentemente de quem fala, enviando essa informaç.1o ao reccp10r e, em seguida, traduzindo· a para uma linguagem que o receptor cnu~ndc. i\ Tabela 9.5 mostra alguns tipos de dados del'inidos pela ASN.l. Lembre-se de que encontramos os tipos de dados INTEGER, OCTET STRING c OBJECT IDEKTIFIER em nosso estudo anterior da S~ll. Como nossa meta aqui (felizmente) não é fornecer uma int rodução completa à ASN.l , remetemos o leitor aos padrões ou ao livro impr~so c on-llnc de (Larmouth, 1996) , para a dcscriç-lo de tipos c construtores AS .1, como SEQUENCE r SET. que permitem definir os tipos de dados estruturodos.

Altm de fornecer uma linguagem de descrição de dados, a ASN.l oferece Regras Bás icas de Codificação (Basic Encoding Rules - BERs), que especil'icam como instâncias de ObJetos que foram defimdas usando a linguagem de dcscriçào de dados ASN. l devem ser enviadas pela rede. A BER adota a abordagem TLV (Typc. lcngth. Valuc- Tipo, Comprimen to, Valor) para a codificaç-lo de dados para transmiss:lo. Para cada item de dados tl ser remwdo, s:lo enviados o tipo dos dados. o comprimento do item de d:1dos c o valor do item de d:ldos. nessa ordem. Com essa simples convcnçào, os dados recebidos se au toidentificam. A Figura 9.9 mostra como os dois itens de dados de um exemplo simple-s seriam enviados. Nesse- exemplo, o remetente quer enviar a Cõldcia de camctcrcs ·smi th' scguid:1 de um vulor decimal 259 (q ue é Igual a 00000001 000000 LI em linguagem bin
Tag I

2 3 4

5 6 9

npo

OeS<~ão

BOOLEAN INIEGER

vrAor é 'verdodeilo' ou 'fo.lso'

BllSTRING OCTETSTRING IMl.

fiSio de um ou mois bit$ trsto de um ou mois bytes

OBJECTIDEimFIER REAl.

nome, oo me de nomeo1õoPG«ôo ASH.I; ~o ~õo 9.2.2

Tabela 9.5 Tipos de dados ASN.l selecionados

pode ser ~ttooamente 'onde

sem volor

ponto fllAoonte

bow4tto4ic~ Gerenciamento de rede

Capitulo 9

Serviço de

lmuirobom

apresentaç~o

Serviço de

tmuitobom

573

Servíço de apresentaç~o

a~esentação

Queda hora!

l da pontinha/

Que barato!

Vovozinha

Hippie de meia-idade (dos anos 1960)

Adolescente de 2009

Figura 9.8 Resolu1õo do problemo do opresenroçõo 'b i g-~ndh111'. O

primeiro byt~ d~• c:1dcin transmitida tem o valor 4, que indica que o upo do Item de d:1do segui nte é um OCfET STRING; esse é o 'T' do cOdigo TLV. O segundo bytc da cadcir~ con tém o comprimento do OCTET STRING, nesse caso. 5. O terceiro byte dr~ mdeia tmnsmitida inicia o OCTET STRlNG de comprimento 5; ele contém a rcprescma~'o ASCII da letra ·s'. Os valores T, L c V dos dados seguintes sno 2 (o tag do ti po lNTEGER), 2 (isto é, um imciro de comprimento de 2 bytcs) c a rcprcscntr~çao 'big-cndia n' de 2 bytcs do valor decimal 259.

Em ll05S:l discussllo. abordamos apenas um subconjunto pequeno c simples da ASN.l. Entre os recursos para aprender mais sobre a ASN.l estilo os documentos padronizados da ASN.l liSO X.680, 20021, o lí\•ro on-línc de ILam1outh, 19961. rcl:uivo ao modelo OS!, c os sitcs Wcb relativo ao ASN.l c (OSS, 2007( c (Francc Tclccom 20061 .

{código, 259} (sobtenome, ·smith"}

sobtenome ::c OCTET STRlNG código ::• INTEGER Módulo de tipos de dados esc:rito emA5N.l

lnst~ncias de tipos de dados especificados no módulo

/ Basic Encoding Rules

(BER)

3

2 2 h

m

s 5 4

Figura 9.9 Exemplo de codificação BER

Cadeia de bytes transmitida

bow4tto4ic~ Redes de co 111 putod ores e o Inle r ne~'------------------------.....-

9.5

Conclusão Nosso estudo sobre o gerenci
c. na verdade. sobre toda a rede- agora c:.tá completo!

Neste eaphulo final sobre gerenciamento de redes, começamos apresentando os motivos da necessidade de fornecer fcrmmcntas :.dcquadas ao administrador de rede- a pessoa que cem a tarefa de manter a rede 'ligada c runcionando' - paro monitorar, testar, consultar, configurar, analisar, avaliar c controlar a operação da rede. Nossas analogias com a adrninistm~':'lo de sistemas com plexos, como usinas elétricas, aviões c organizações human4\S, ajudaram-nos a fornecer n10tivos paro essa necessidade. Vimos que a arquitetura do sistema de gerenciamento de rede giro em tomo de cinco componentes fundamentais: ( 1) u m gerenciador de rede, (2) um conjunto de dispositivos gerencia· dos remotamcnce (pelo gerenciador de rede), (3) as bases de infom1ações de gerenciamento (Mllls) existemes nesse; dispositivos, co111endo d:tdos sobre seu cscado e sua operação, (4) os agentes rcmocos que reporiam infonnaÇão das MIBs c executam ações sob o controle do gerenciador de rede c (5) um protocolo para a comunicac;
Em seguida, cx:unlmunos em detalhes a cstnuuro de gcrenciamcmo d e rede da lmernet c, em p:micular. o protocolo SNMP. Vimos como o SNMP apresenta os cinco componen tes fund:unclllais de uma arqui lctum de gc re ncimncnto de padr:io da lmcrnct e gastamos um tem po considérávcl cx:uni nMdo objetos MIB, a SMl - a li ngu:~gcm de ddin iç!lo de dados para cspeciricaçào das MIBs- c o protocolo SNMP em si. Obse rvamos q ue a SMI c a ASN. l cs tllo inextricavclmcntc interligadas c que a ASN. l desempenha um p.'1pcl fundamental na c-. tmada de aprescntac;;lo do modelo de referenda de sete cam;tdas IS0/051, c cntlo fi:.emos u m estudo rápido da ASNl. Talvez mais importante do que os detalhes da ASN.l em si foi a necessidade ~rcebida de fornecer a tradu~':'lo entre formatos de dados espcclficos de cada computador de um:1 rede. Enquanto algumas arquitehlras de rede reconhecem explicitamente a importância desse serviço por terem uma camada de apresentação, essa camad:-. nlo existe na pilha de protocolos da Internet. Convém também observar que há muitos tóptcos no gerenciamen to de rede que prefemnos mlo abordar tópicos como as falhas de identificação c gerenciamento. a detccÇ"Jo pro:Jtiva de :-.nomalias. a correlação entre os alarmes c os Jtcns mais amplos do gerenciamento de servtço (por exemplo, como oposto do gcrenciamemo de rede). Embora sejam Importantes, esses tópicos merecem um livro dedi cado a eles. O lehor pode consu ltar as rcfer~ncias apresentadas na Scç.\o 9.1.

Exercíciosde fixação Capítulo 9 Questões de revisão S~õo

9.1

I.

Por que um adm inis1rador de red e. necessita de fe r·

1.

3.

ramcnt,LS de gcrcndamcntn de rede? Descreva cinoo cen:lrios. Quais s;\o as cinco áreas de gerenciamento de rede ddinidas pela IS01 Qual a dircrença entre gerenciamento de rede c gcrcnclamcmo de serviço?

~õo 9.2

'*·

DeOn:t os segum1es 1em1os: entidade gerenciadora. disposltl\'O J:Crcncmdo, agente de gcrcnctanu;nto de rede. MIB c protocolo de gerenciamemo de rede.

Seção9.3 5.

Qual é o papel da SMI no gerenciamento de rede?

6. 7. 8.

Cite uma diferença imponnmc emrc uma mensagem de comando-resposta c uma mcn:.agcm trap no SNMI'. Quais s;lo os sete tipos de rnens:1gcns usados no SNMP? O que signillca um ·processador do 5NMP'?

Seção 9.4 Qual é a nnahcladc da árvore de i«Jcm ificadon:s de ohje10s ASN. J? 10. Qual ê o fYolpcl da ASN. l na t'amada de apresentação nos modelos de rdercncia 150/051? 11. A Internet tem uma camada de aprcsenta\.lo? Se não tiver. como s.\o tratadas as questões de diferençns cnlrc arquucwras de nl.lqtLLI\as - por exemplo, a rtJ)rcscmaç.\o dtfcrentc de numcros inteiros em máquinas diferentes? 12. O que significa codificação TLV?

9.

bow4tto4ic~ Capitulo

9


575

Problemas 1.

2.

3.

...

Cons1derc as duas maneiras pelas quais ocorrem as comuni c-.u;11es cmrc uma entidade gerenciadora c um diSJlOSilivo s:crcnciado: modo com:~ndo-rcsposta c 1ra1>píng. Quais s.'lo os prós e os comras dessas duas allOrdagcns. em 1cnnos de ( I) sobrecarga. (2) tempo de notificaç:\o quando ocorrem eventos excepcionais c (3) robustez quanto às mensagens perdidas entre a entidade gerenciadora c o dispositivo gerenciado? Na Sc(•\O 9.3 vimos
5.

6.

7.

registrado? (Dica: você deve recorrer a alguns RFCs c a outms documcnros similares para rCSJlOnder a essa pc rgurua.) Lembre-se da Sc(ão 9.3.2, que uma empresa privada (empreend imento) pode criar suas proprias vari:h·cis M IB sob o ramo prh•ado 1.3.6. 1 4. Suponha que a IBM qu1scsse cnar uma MIB para seu software do servidClr Wcb. qual seria o prc~ximo qualificador 010 :tpós 1.3.6.1.4? (Para TCSilondcr a essn quest;'\o. você prcciS;~r:\ consultar (IA NA, 2009b(. Pesquise na Wcb para tentar descobrir se cSSo •·que o comprimcmo precede o valor em uma co
8.

Considere a Figura 9.9. Qmtl seria a codiOCJç;lo BER para (peso. 160IIsobrcnome. ·oarlo"l?

3.

Leia o RFC 789 Comn a queda da ARPAnct ocor· rida em 1980 podem\ ter sido evit3da (ou sua recuperação simplificada) se seu~ administradores ti\•cssem as rerramcnlas de gerenciamenro de rede cXiSieniCS hoje?

Questões dissertotivos l.

2.

Além das analogias com uma usina clc!trica c uma cabine de avi~o. cilc uma analogia t>ara um sistema C(lmplcxo d•strihuldo que l>recisa ser conrrolado. Considere o ccn;triu de nwtivac-do da Scç;lo 9. L. Na sua opmilo, que ourras a1ividades um adminisrrador de rede gosrana de monitorar? Por <1uc?

bow4tto4ic~

JeH Cose Jelf Cose é o fundador e diretor técnico da SNMP Reseorch, Inc., empre$0 líder no produção de padrões do Internet e de produtos para gerenciamento de

rede boseodos em padrões. Ele é bochorel em educação industrial e engenharia elétrico pelo Universidade de Purdue. ~ lombém doutor em educação técnico pelo Universidade de lllinois, em Urbono-Champoign.

O que o fex se decidir pelo especialização em tecnologia de rede?

ScmJ>rc fu i fascinado por interligar coisas, desde quando era criança c enfia va gmmpos de cabelo nns tomadas. Essa fnscinaç;lo se desenvolveu c se transformou em interesse por equi pamentos de áudio dumntc a :\dolescencia. qu:mdo cu mont:wa sistemas de som para bandas de rock, cuja potenda parecia ser s uOcicntc para pulverizar concreto. Enquanto estudava c trobalhava como técnico de TV c rádio (em geral , equipa mentos de áudio), fui mordido pelo bicho do computador e. comecei a me interessar por tudo o que era digital, incluindo hardware c software JY.lra computadores. Comecei a me interessar pela construçM de interfaces entre um componente esquisito c outro componente c:squisilo. Primeiro montei uma interface entre pcriféncos c proces· sadorcs. M:us tarde. uma mterface entre dois sistemas. A rede é a interface dcfmitml. E, até agor.t. a Internet é a rede definitiva.

Qual foi seu primeiro emprego no setor de computaçõo? O que implicovo? Passei a maior J>aru: de meus primeiros anos como profissional na Universidade de Purdue. Em determinados anos, d:wa aula para qu;tSc todos os cu rsos do curriculo de graduaç!\o em eletricidade c em tecnologia da computaç;\o. Isso indu la criar novos cursos para os então emergentes tópicos de hardware c sortware para microprocessadores. Durante um semestre, a classe projetava um computador a parúr de chips c o construfa na pane laboratorial do curso, com uma equipe trabalhando na CPU, o utra no subsistema de memória, outra no subsistema de EIS c assim por diante. No semestre seguinte, cscrcvi:unos o software para o hardware que tinh:unos construido. Foi nessa mesma época que chefiei a área de computaç-.lo do campus, rcpommdo-mc serviços acad~m i cos de compmaç;lo aos usuários.

:10

reitor como diretor de

Qual porte de seu trabalho lhe apresenta mai$ desafios? Ficar atual izado com todas as mud;m(;as. tanto técnicas qu:mto cmpresari;liS. Sou um admin istrador muito téc· nico, c está ficando <.11da vez mais difícil fimr :llualizado com os avan~·os tecno lógicos de nosso sl'lor. Meu papel também exige que eu me informe sobre as mudanças no espaço empresarial. como fusões e aquis i ~:ões.

Em sua opiniõo, qual é o futuro dos redes e da Internet? Mais, mais. mais. Maí!> ,·cloddadc. Mais ubiQllidade. Mais contclido. Mais tens;lo entre anarquia c governrm~'\1 . Mais spam. Mais mo,•imcntos anlispam. Mais problemas de segurança. Mais soluções de segurança. E. por fim , devemos espcmr o inesperado.

bow4tto4ic~ Quais pessoas o inspiraram profissionalmente? Meu falecido pai, que era um homem de negócios bem-sucedido; Oilbcrt: dr. Vi nl Ccrf. clr. jon Postei, dr. Marshall Rose c Chuck Oavin, que são figuras muito conhecidas no setor da Inte rnet; Bill Scifert, agora um sócio vice- presideme da empresa; dr. Rupcrt Evans, meu orientador. min h;l espos;1, que trabalha comigo na empresa, e, final mente, mas não menos importante, Jesus.

li que o senhor tem umo coletânea notável de ' provérbios'. Quondo era professor de ciência da computaçã o, quais deles costumava dizer a seus alunos?

·umexe mplo vale d o1s l•vros" (acho que é de Gauss). ~Às vezes. há uma lacuna entre tcona c prática. A lacuna entre teoria c prática não t t•'o grande teoricamen te quanto a lacuna cn1rc teoria e prática na prát ica~ (mlo tenho idcia de ond e veio esse prov('rbio).

Quais têm sido os maiores obstáculos na criação de padrões poro a Internet? Dinheiro. i>olltica. Egos. Fracassos de liderança. Qual tem sido o uso mais surpreendente da tecnologia SNMP? Todos. Na realidade, cu me envolvi no gerenciamento d:t lnu:rnct por causa d:IS minhas necess idades de sobrcviv~ncla. Precistwa ter a lgumas fcrrament:ls adequadas para gerenciar a infnws tna ura de rede ela minha organiza· ~lo. O sucesso estrondoso que acomeceu foi obra do acaso, porque muitas outras pessoas precis:w:ur1 resolver probl emas semclhames: foi também sorte. c muito trabalho árduo. O impon amc t que conseguimos montar a arquitelllrn corrctn logo de inicio.

bow4tto4ic~

Referências

empre que poss1vel, informamos um URL como reJer~ ncla. Todos os URLs foram validados (c testados)

S

em abnl de 2004. tnrelizmentc. os URLs podcr:io estar desatualiz;~dos. Por ravor. cons ulte a bibliografia atualizada na vers:\o on-linc deste livro em ingl~ (hup://www.a\\ l.com/kurose-ross).

Uma nota sobre os pedidos de comentários (rrc1urst for conrrnruts - RFCs) da Internet: há uma cópia dos RFCs em diversos sites. Todos os URLs de RFCs a seguir lc\-am ao arquivo RFC do lnformation Sdenccs lnstitutc (ISI) manudo pelo Editor de RFC ( RFC Editor) da lntcrnet Socicty (a orgamzaç:\o que ~upcrvisiona os RFCs). Outros sites de RFC são: hup:l/wwwJaqs.orglrfcs e hup:l/www.csl.son)'·co.Jplrfc/ (localizado no Jap:\o). Os RFCs da Internet podem ficar desatualizados com a publicação de outros RFCs. Aconselhamos que ''oc~ acesse os shcs relacionados anteriormente para obter mformaçõcs mais atualizadas. A functonahdadc de busca dos RFCs no ISI ( hup://www.rfc-editor.oryrk.h unl) pcnnitirá que \'OC~ procure um RFC c apresentará su as atualizações. [3Co m Addresslng 2009) 3Com Corp.• "\Vhite papcr: Undcrswnding IP addrcssing: Evcrythí ng )'Ou cvcr wantcd to knowfl. hu p://www.3co m.eom/other/pdfs/infra/corpinfo/en_ USISO 1302.p
[3GPP 200 .. I Thml Gcncration Partncrship Projcct homepagc. lmp://www.3gpp.org/. [802.1 1 Secur ily 2009) Thc Unofficial 802.11 Sccuríty Wcb Pagc, h up://www. cl rlzz lc.com/~aboba!IEEEI. [Abi tz 19 93 1 P. Albitz c C. Uu. ONS and BTNO. Pcto.luma: O'Rcilly &: t\ssociatcs, Pc ta luma, CA. 1993. [Abrams on 1970) N. Abromson. "The Aloha Systcm - Anothcr Altcrnat ivc for Computcr Commu nications", P10<. 1970 Fall]ohtl Computcr Cor~fcrencc, AF IPS Confereuce, p. 37. 1970. [Abra mson 1985 ) N. Abramson. "Ocvelopmcnt of the Alohanet", IEEE TratiScrctions on /nfonnatlon Thcory. vol. IT-3 1, n. 3 (mar. 1985), p. I 19-123. (Ahn 19 95] J . S. i\hn, P. B. Danztg, Z. Liu c Y. Yan. ~expcricncc with TCP Vegas: Emulauon and Experimcnt". Proc. 1995 ACM SIGCOMM (Boston, MA, ago. 19Q5), p. 185-195. (Aka ma i 2009 1 Akamai homepagc. hup:l/ww\v.akamai.com. (Akdla , 2003 1 A. Akclla. S. Seshan, A. Shaikh. "An empi rical E'-aluation of Wide-arca Internet Bottlenecks·. P1oc. 2003 ACM Jmcmct Mcasu1cntcnr Conf. (Miami Fio, nov. 2003). [Alves tr a nd 1997 1 H. Alvcstrand. "Object Jdentifier Registry." http://www.alvestrand .no/ objcctidl.

bow4tto4ic~ Reler in cios

579

(Andttrson 1995 1 J. 8. Anderscn, T. S. Rappapon, S. Yosh ída. "Propagatíon Measurcments and Models for Wirclcss Communication Channels~. IEEE Commuuiwlious Mogaziuc. (jan. 1995). p. 42-49. (Aperjis 2008) C. Apcrjis. M.J. Frecdman, R.Johari. "Pccr-assistcd Contem Sislribution with Priccs", Proc. ,\CM CoNEXT08, (Madn, dez. 2008). (Appe~Udler

2004) G. Appcnzeller, I. Keslassy, N. Me Keown. "Sazíng Routcr Buffers·, Proc. 200-l ACM

SIGCOMM (Ponland, OR, ago. 2004).

(ARIN 19961 ARIK. •Jp allocation rcport~, ftp://rs.arin.ncllnctinfolip_nctwork_alloc:uions. (Ash 1998) G.R. Ash. Dyuomrc Rouring in Tdccomnllmiccrtíoru Nrtworks , McGraw I h li: Nova York, 1998.

(ASO-ICANN 20041 Thc Addrcss Supporúng Organization homc pagc, http://www.aso.icann.org. (AT&T SLM 20081 AT&T Busincss. ·AT&T Entcrprise Hosting Scrviccs Scrvícc Guidc", hup://www.au.com/ abslscrviccgu ide/does/c h_sg.pdf. (Atheros 2009 1 Athcros Communications Inc. "Atheros AR5006 WLAN Chipsct Product Bullctins", hnp:l/www. athc ros. corn/pllAR5006Bullct íns. h tm.

(Aya uoglu 1995] E. Ayanoglu, S. P~ml , T. F. La Porta, K K. Sabnanl c R. D. Gltlin. "A lRMA IL: i\ Link-Luycr Protocol for Wirclcss Nctworks~, ACM ACM/B(J/Izer Wi rclcss Networl1s)ourncrl. 1:47-60, fcv. 1995.

lBakre 19951 A. Bukrc e B. R. Badrin;Hh. · t-TCP: tndircct TCP for Mobile Hosts", Proc 1995. 1111. Conf. on Disrriburecl ComJmlíug Sysums (ICDCS). maio 1995. p. 136·143. ( Balakrishnan 1997 I 11. Balakrishnan, V. Padmanabhan, S. Seshan e R. Katz. • A Comparison of Mcchanisms for lmproving TCP Performance ovcr Wirclcss Links", IEEEIACM Tra rrsa(líous em Nctworltiug 5, n. 6, dez. 1997.

I Baran 1964 I P. Baran. "On Distributed Commw1ication Nctworks", IEEE Tmns11Ctions ou Communiccllíons Systcrus, mar. 1964. Rand Corpoi",U ion Technical rcport with thc samc titlc (Mcmorandum RM-3420-PR, 1964). hup://www.rand orglpublicauons/Ri\.f/RM3420/. (BardweU 20041 J. Bardwcll. · vou Bclicvc Vou Undcrstand What You Think I Said ... Thc Truth About 802.11 Signal and Nolsc Mctrics: A Discussion Clarifyl.ng O ftcn-Misused 802.11 WLAN Tcrminologics", hup://www. conncct802.com/download/techpubsl20041you_ bdieve_D l 0020 l .pdf. (Basct 20061 S. A. Basset c H. Schulzrinnc. "An analysis of thc Skypc pccr·lo-J>ecr Internet Telcphony Protocol". Proc. 2006 IEEE lufocom. Barcelona. abr. 2006. (BBC 20011 BBC ncws onlinc. nature/l264205.stm.

~A

Small Slicc of Dcsign", abr. 2001. hup://ncws.bbc.co.uki2A1Vsdcncc/

I BBC Multicast 2009 1 BB, "BBC Muhicast Trial ~ hllp://support.bbc.co.uklm ulticastl. IBeheshti 20081 N. Bchcsh ti, V. Ganjali, M. Ghobadi. N. McKcown, G. S.1lmon. "Expcrimcmal Stud)• of Routcr Buffcr Sizillg", Proc. 1\CM luremrl Metcsurcment Confcrcnce, out. 2008, Vouliagmcni. (Bcndcr 20001 P. Bcndcr, P. 'Binck. M. Grob, R. Padovanl, N. Sindhushayana, A. Vitcrbi. "CDMMHDR: A b.mdwid th-crficicnt high-spced wircless data service for nomadic uscrs~. IEEE Commuu. Mc1g.. vol. 38, n. 7, jul. 2000, f>. 70-77. (Bemers-Lce 19891 T. Bcrncrs·Lcc, CERN. "lnfonnation Managcmcnt: A Proposal", mar. 1989. m
·sYN Cookies·. hup://cr.yp.to/syncookies.html.

I Bertsekas 199 I I O. Bcrtsckas e R. Gall:agher. Dota Nctworks, 2 cd. Englcwood Chffs: Prcnticc Hall, 199l. IBhimani 19961 Anish Bhimani. "Sccuring the Commcrciall ntcrnct~. Commuraícolions of rlrr J\CM, vol. 39, n. 6, mar. 1996, p. 29-35. [Biddle 20031 P Baddlc. P. England, M. Peinado e 8 . Wallman. "The Darknet and the Futurc of Conlclll DistributionK, 2002 ACM Worl1shop on Digital Rights Mcuwgemenr, nov. 2002, Washington, D.C. hup://crypto. stanford.edu/DRM2002Idark neõ.doc.

bow4tto4ic~ Redes de co 111 putod ores e o Inle ;.; r n;.;e.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

( Bier~ac k

1992) E. \V. Bicrsack. ~Performance e\·aluatioo of forward crror correction in ATM networks", Proc. 1999 ACM SIGCOMM . Bahimore, ago. 1992, p. 248-257. IBIND 2009) 1ntcrncl Software Consortium page on BIND, hup://www.isc.org/bind.h tml. IBisdik ian 200 1 J C. Bisdikian. · An Ovcrvicw of thc Bluetooth Wi rclcss Technolog)•", IEEE Con11111111iCcllions n. 12. dez. 2001. p. 86-9-f.

M11gcr~ine,

IBisho p 2003) M. Bishop. Compwcr Sccurity: Art and Scicncc. Boston: Addison Wcslc)•. 2003. IBitTorrent 2009) BltTorrcnt.org homepagt. hup:l/www.biuorrcnt.org. I Black 1995 ) U. Black. A Thf Volumr 1: Founc/alion for Broaclband Ntiii!OI l1s. Prcnticc H ali, 1995. IBiumenchal 200 li M. Blumcn lhal, O. C lark. • Rethinking Lhe Oesign of thc Internet: the End-Lo-c nd ArgumenLS vs. thc Bravc Ncw Wortd·, ACM Tmnsactions 011 lnlm 1e1 Tcclmology, vol. 1, n.l. ago. 200 1, p. 70·109. IBochman 1984 1 G. V. Bochmann c C. t\ . Sunshinc. "Formal mcthods in communic:ltio n protocol dcsign", lff:E TI"Cm.wwions 011 Comm1111ications, vol. 28, n . 4, abrill980, p. 624-631. IBolot l 994IJ-C. Bolot c T. Turlwi. "A rmc control schcmc for packct vidco i11 the l mernct~. Proc. 1994 IEEE

lnfocom, p. 1216- 1223. (Bolot 1996) J·C. 13olot c Andrcas Vcga· Garcla. 1996 IEEE lnfo com, L996, p. 232-23Q.

~comrol

Mechanísms for Packet Audio in thc lntcrnec· . Proc.

IBradner 19961 S. Rmdncr c A. Mankin. IPng: lntemel Protocol Next Gcucra1lo11. Rcacllng: Addison Weslcy, 1996.

(Brakrno 19951 L. Brnkmo c L Pctcrson. ~TCP Vegas: End 10 End Congcstion Avoidancc on a Glob~•llntemct", IEEf)ounwl of Srlatccl Arcus in Communrccllions, vol. 13. n. 8, ouc. 1995, p. L-+65-1480. (Breslau 2000) L. Brcslau, E. Knightly, S. Shcnker, I. Scoiro, H. Zh:1ng. ~ End pom t Admission Control: Architcccural lssues and Pcrform:1ncc", Proc. 2000 AC~ I SIGCO:WM, Es tocolmo, ago. 2000. IBrodnik 19971 A. Brodnik, S. Carlsson, M. Degemark c S. Pink. ~srnall Fonvarding Tables for Fast Routing lookups·. Procudiugs of ACM SIGCO,\fM '97. Canncs, ouL 1997, p. 3·15. (Bush 1945 1 V. Bush. ~As Wc May Think·, The 1\tlautic Montlrly . j ul. 1945. hup://www.thcatlancic.com/ unboundln:lshbkslcomputcrlbushLhtm. I Byers 1998 1J. Bycrs, M. Luby, M. Miucnmachcr e A. Rege. • A digital foun tain approach to rcliable distribution o f bulk d:1tn• . Proc./998 ACM SIGCO.\fM, Vancouver. ago. 1998. p. 56-ó7. I Cablelabs 2004) Cablcl.abs homcpagc. h up://ww\\',t:ablclabs.com. I Cachel ogic 20091 Cachclogic ho rncpage. hup:l/www.rochclogic.com. (Caesar 2005 1 M. Caesar,J . Rcxford. "BGP Routing Policies in ISP Nctworks", IEEE Nctwork Magazine, vol. 19, n . 6, nov. 2005. (Caldwell 2009) C. Cald wcll. Thc Prime Pagcs, http://www. lllm.edu/rese:lrch/primcslprovc. ICardwcll 2000] N. Cnrdwell, S. Savage c T. Andcrson. ftMoclcling TCP Latency", Proc. 2000 IEEE l,ifocom

Co,ifw:ncc. Tci-Aviv, mar. 2000. (CASA 2009( Centcr for Collaboralivc Adaptivc Scnsing of thc i\unosphcre.

lmp://www.~-asa. urnass . cdu.

[Casado 2007) M. Cas:1do, M. Frccdm::m,J. Pcllil,J. luo, N. Mckcown, S. Shcnker, ~ Etha nc: Taking Control of thc Entcrprlsc" , P1·oc. ACM SIGCOMM'07. ago. 1007, Kyoto, japâo. I Casner 19921 S. Cnsncr e S. Dccring. "Firsti ETF Internet Audiocast~, AC\1 S/GCOMM ComputerCommunicmions Revit'w, vol. 22, n. 3.jul. 1992, p. 92-97.

I Ceiva 2009 I Cci\'a homepagc. hup://www.cciva.com/. ICENS 20091 Ccnccr for Embcdded

etwork Scnsing. hllp:l/www.ccns.ucl:l.edu/.

(Cerf 19741 V. Cerf e R. Kahn. -A Protocol for Packel Network lnterconneclro n" , IEEE Transaclions on Communications Technology, vol. COM-22, n. 5 , p. 627-641.

bow4tto4ic~ Referincios

581

(CERT 2001-09) CERT. · Advisory 2001-09: Stalislical Wcakncsses in T CP/IP lnrlial Scqucncc Nu mbcrs", hupJ/ www.ccn .org/advisories/CA-2001-09.html.

I CERT 2003-04 I CERT. "CERT t\dVJSOI)' Ct\-2003.04 MS.SQL Scrvcr Worm". hllp:l/ww\\ .ccn .orglad\'Ísories/ Ct\-2003-04.html. (CERT 2009) CERT Coord inmion Ccntcr. http://www.ccrt.org/advisories. (CERT Fihering 2002) CERT. "Packct Fihcring for Firc,'<-all Systems". hu pJ/www.ccrt.orgltcch_tips/packcLI'il· tcnng.hunl.

I Ccrt SVN 19961 CERT. · Advisory Ct\-96.21: TCP SYN Flooding and I P Spoofing t\uacks", hu p://www.ccn .org/ advisorics/CA-1998-0 l.hlml.

I Chao lOO J ) 11. J. C h ao, C. lam c E. Oki. Broaclband Paclu:t Swítdríng Tcdrnologícs- A Pr crrtícal Gufclc to A TM Swítdrrs anci/P Routrrs. j ohn Wilcy & Sons, 2001. (Chcn 2000) G. Chen e D. Kotz. "A Su rvcy of Comc.-:t-A\\-are Mobile Computing Research", Trclrnical Repor1 TR2000-J8 J, DcpL o r Computcr Sciencc, O;trtmouth Collegc, nov. 2000. hup://www.cs.da n mo uth. cdu/rc portsl

TR2000-38 l .pdf. (Chcn 20061 K. -T. Chcn, C. -Y. lluang, P. HLtang, C.-L. Lei. "Quantifylng Sk)•pc Usc r Satisfaction", Proc. 2006 ACM SIGCOMM, Pisa, It~lla , sct. 2006. (Che.swick 20001 B. Cheswick, H. Burch c S. Branigan. '"Mapping and Visualizing the lmemct" , Proc. 2000 Usrn ix Confcrcncr. S:m Oi ego, jun. 2000.

I Chlu 1989 I O. Cluu e R. Jnin. • t\nalysis o f the lncrease and Occrcase Algorilluns for Congcstio n Avoídance in Computer Nctworks~. Computer Nflworhs and ISDN Systems. vol. 17, n. l , p. l- 14. http://www.cs.wustl.edu/-jnin/ pa~ rslcon&-a\'. htm.

(Christianscn 2001 ) M. Ouistiansen. K.jcffay. O. O u c F. O. Smh h. '"Tuning Rcd for Wcb Traffic". IEEE/ACM TrCIIIS(ICIIons 011 Nctworl1íng. vol. 9. n. 3 , jun. 2001. p. 249-264. (Chuang 2005 1 S. Chuang, S. lycr, N. McKeown. · J>ractical Algorithms for Pcrform:tnce Guarantees in Buffcred Crossbars". Proc. 2005 IEEE lnfocoru.

I Cicconcni 2006 I C. Cicconcu i, L Lcnzin i, A. Mingozi. K. Eklund. · Quaht)' o f Scrvicc Suppon in 802. 16 ctworks ", IEEE Mrll•ork Magatinr, rnar/abr. 2006, p. 50-55.

I Cisco 12000 2009 ) Cisco S)'Stcms Inc. "Cisco XR 12000 Scrics and Cisco 12000 Series Rou tcrs-. http://www.cisco.com/cn/US/products/ps63+21indcx.hunl. (Cisco 8500 20091 Cisco Systcms Inc. "Catalyst 8500 Campus Switch Router Archltecture· . htt pJ/www.cisco. com/uni ''ercd/cc/td/d oclprod uctll>sw/85'1 O/rcl_l2_0/w5_6flsoftcnfgll cfg8500.pdf. (Cisco NAT 20091 Cisco Systcms lm:. " How NAT Works", hllp://www.cisco.com/en/US/tech/tk6-18/tk3ó l/ technologics_tcch_ notc09 186a008009483Lshtml. (Cisco NAPt\ 2009 ) Cisco Sysl\:ms lnc. "Cisco 1ctwork Applic:atlon Pcrform:mcc Analys is (NAPA) Solutlon", http://www,cisco.com/cn/US/products/sw/nctnlglsw/indcx.html. (Cisco QoS 20091 Cisco S)•Stcms Inc. '" Advanced QoS Serviccs for the lntclligcnt Internet", hup://www. cisco. corn/warplpublic/cc/pd!losw/ioftlioqo/tcch/qos_wp.hlm.

ICisco Qucuc: 20091 Cisco Srstcms Inc. ~congcstío Manngcmcnt Ovcrvicw", hup://www.cisco.com/cn/US/docl íos/l 2_2/qos/configuratlon/guide/qckonmg.html. (Cisco Sccurity 2 009) Cisco Systems Inc. "\'1/hy You Nced a Fircwall·, htLp:l/www.cisco.com/en/USI p roductslsw/sccursw/ps7+31produclS_uscr_gu ide_chaptcr09186a008007003.html.

I Cisco

Swltch~

2009 I Cisco Systems Inc. kMuhisen·ices S" itchcs". http://w\\ w.cisco.com/warplpublic/cc/pd!

sí/i ndex .sh tml. [Cisco SVN 20091 Cisco Systcms Inc. - o efining Slrategies to Protcct Againsl TCP SYN Denial of Scrvice Anacks". http://www .cisco.com/cn/US/tcch/ tk828/technologies_tech_note09186a00900f6 7d 5 .shtm I.


(Clark 1988) D. Clark. ~Thc Desígn Phílosophy of lhe DARPA lnlcrncl Protocols~. Proc 1988 ACM SIGCOMM. S tanford, CA, ago. 1988. (Clarke 20021 1. Clarkc. T. W . Hong, S. G. Millcr, O. Sandbcrg c B. Wilcy. · Protccting Frce Exprc:ssion Online with Freenet~, IEEE lmentcl Compuring,jan.Jfev. 2002, p. 40-49. (C()ben 1977) D. Cohen. -lssucs in Transncl Packcúzcd Voicc Communicalion", Ptoc Fifrh Data Communications Symposium. Sno" btrd, sct. 19n, p. 6- 13. (Coh c:n 2003 1 O. Cohcn. "lnccnúvcs to Build Robusmess in BitTorrcm, • fhsr \VotskshotJ ou rhr Ecouomics of Pccr-to-Pccr Systcms•. llerkelcy, jun. 2003. I Cookie Central 2009) Cookic Central homcpagc, hup;//www.cookicccntral.com/n_cookic_faq.lurn . (CooiStreaming 2005) X. Zhang, J. Liu, B. U e T.-S P. Yurn. "CooiStrcarmngDONcLI: A Data-driven Overlay Nctwork for Pcer-to-Pccr live Media Strcamlng", Proc. IEEE lNFOC0/11, 111111 . 200.5, Miami. (Cormen 2001 I T. 11. Corrnen. huroduction to Algorirlmts, 2 ed. Carnbridge: MIT Prcss, 2001. (Crow 1997) B. Crow, I. Widj:~a. J. Kim e P. Sakai. "IEEE 802. 11 Wi rclcss Local Arca Netwo rks", IEEE Communicculons J\-foga~ine, sct. IQQ7, p. 116-126. ICrowcroft 1995) J. Crowcroft, Z. Wa ng, A. Smith ej. Adams. "A Comparison of thc l!lTF a nd ATM Scrvicc Mode ls", JEEE Comn ttwirmiott~ Mag(l~ine, nov Jdez. 1Q95. p. 12- 16. ICrowcroft 1999) J. Crowcroft, M. Handlc)' e L W:tkeman. lnterntrwotlling Multimctlía . S:lo Francísco: MorganKaufmau, 1999.

ICusumano 19981 M. A. Cusumano. O. B. Voffic. Compt•ting 011 Intcnttl Time: Ltssons jto111 Nttscapt m11l ils Btrlllc 111itlt Microsoft. No\'·a York: Free f'ress, IQ98.

I Daigle 1991 IJ. N. Daiglc. Qucuing Thcory for Tclccommunications. Rcading, MA: Addison Wc:slcy, 1991.

I Oalal 1978) Y. Dalal c R. Mctcalrc. · Revcrse Path Forwarding of Broadcast Packcts". Communications of thc ACM. vol. 21, n. 12. dez. 1978. p . 1040-1048. IDavie 20001 8. Davi c c V. Rekhtcr. MPLS: Tccltnology and Applicalion , Morgan Kaufmann Scrics in Nctworking, 2000. (Davic.s 20041 (G. Davics, f. Kclly. ·Network Dimcns ioning. Scn·ice Costing. and Pricing in a Packct·SWitchcd Environmcnt". Tclrcoumumicolions Policy, vol. 28. n . 4. p. 391-4 12. IDEC 1990) Digital Equipmcnl Corporation. Mln Mcmoriam: J. C. R. Licklidcr 1915-1990~, SRC Rmmch Rcport 61. ago. 1990. hllp:l/www.mcmcx.orgll icklidcr.pdf.

I DeCJercq 20021 J.

DcCicrcq e O. Paridaens. "Scalabi lit)• lmplications of Virtual Privntc Net works", TEEE

COIIIIIIlllliCIIIIons Magcl(;l tu', vol. 40. n. 5, rnaio 2002. p. 15 1-157. (Dcmers 1990) A. Dcmcrs, S. Kcshav c S. Shenkcr. "Analysis :mel Simulation of a Fai r Quculng Algo rithm''. llllcrttrtworlling: Rrsrcu·ch mul ExptriCIICC, voi. I , n. l. 1990, p. 3· 26. I Dc nning 1997 1 D. Dcnning (editor) c P. Denning ( prefácio). lttii:11U't Bcsiegccl: CowtrrrfnJ: Cybcrspacc Scofjlaws. Rc;lding: t\ ddiS
Dynamlc Host

Con figuration

working group, http://www.ietf.orglhtml.chartersl

(Diggavi 2004) S. N. Diggavo. N. Al-Dhahir. A. Stamoulis, R. Caldc rbank. ·Grcat Expcctattions: Thc Valuc of Spatial Divcrsil)' in Wirclcss Nctworks", Procwlings of tl1c IEEE, vol. 92. n. 2, fc''· 2004. IDiot 20001 C. Diot, B. . Lc,·inc, 13. Lyles. H. Kasscm c D. Balcnsicfcn. "Deploymcnt lssues for lhe IP Muhicast Scrvicc and Architccturc", IEEE Nctwork, vol. H , n. l , janJfcv. 2000. p. 78-88. (Dmitiropoulos 20071 X. Drnitiropoulos. D. Krioukov. M. Fomcnkov, 8. Huffaker. Y. H)•un, KC Claffy. G . Riley. · AS Rclationships: Jnferencc and Validalion·, ACM Compu ter Communicatiou Rcvicw, jan. 2007. [Oodge 20091 M. Dodge. '·An Atlas of Cyberspaces", hup://www.cybergeography.org/atlaslisp_maps.hunJ.


(Donahoo 20011 M. Donahoo, K. Calvert. TCPIIP Sockets in C: Prcrcliccrl Guiclr for Programrners. Morgan Kaufman. 2000. IDoucc r 2002) J . R. Douccur. ~Thc S}'bil Allack~. firsl Intcnwlional Worllshop '02), Cambndgc, mar. 2002.

011

Prer-lo-Pccr Systrms (IPTPS

lOS L 2009 I OSL Forum homcpage, hup://ww..v.dsl(orum.org/. IOhunghel2008l P. Ohungcl. O. Wu. B. Schonhorst. K. W. Ross. ~A Mcasurcmcnt Study or Auacks on BitTorrcnt lcechcrs·, 7th lntwwtioncrl Wotl!shop on Pccr-lo-Pcrr Systcms (IPTPS 2008), Tampa Ba}'• Cc''· 2008. (Oroms 2002) R. Droms. T. Lcmon. T1ae DHCP Hcrndbook. 2 ed.. SAMS Publishang. 2002. I Edncy 20031 ). Edncy c W.A. Arbaugh. R('e~l 802.11 Securlty: \VI-FI Protcctctl Acuss mul802. I 11, Addíson· Wcslcy Prorcssionul, 2003. IEklund 20021 K. Eklund. R. Marks. K. St:tnswood. S. Wang. "IEEE Sumdarc.l802. 16: A Tcchnlcal Ovcn •icw o r th c Wirckss MAN Ai r ln tcrracc ror Broadb:md Wirclcss Acccss·, IEEE Conwumlwlfons Magazrnc, jun. 2002, p. 98-L07. lEilis 19871 H. Ellis. "Thc Story o r Non·Secret Encryption", http://jya.com/ellisdoc.htm IErlcsson 2009) 'Eri csson. ~The Evolution of the Edgc", http://www.cricsson.com/tcchnology/whhcpapcrsl broadband/cvolution_oCEDGE.shtml. IES M 20091 End Systcm Multicast homepage, http://esm.cs.cmu.edu/. IEstrln 1997) O. Estrin, M. Handley, A. t-lcllll)', P. Huang c O. Thalcr. •A D)•n:unlc Bootstrnp Mechanism ror Rcndcz,·ous-bascd Muhicast Routing~. Proccccliugs of IEEE lufocom '98, Nova York, abr. 1998. I Falkncr 20071 j. Falkncr, M. Piatck, J. P .John. A. KnshnamurLh)•, T. Andcrson. "Profiling a Míllion Sscr DHT-. Proc. ACM lntrr 11('1 Mccrsurcmcru Confcrencc. raov. 2007. ( Faloutsos 19991 C. FalouLSOS, M. FalouLSOS e P. Faloutsos. ~what Does the Internet look Ltkc? Empiricallaws or the Internet Topology·. Proc. 1999 ACM SIGCO.MM, Boston, ago. 1999. I Feamstcr 2004 I N. Feamstcr, j. Winick c j. Rexford. ~A Modcl for BGP Routing for Network Enginccring", Proc.20CH ACM SIGMETRICS, Nova York, j un. 2004. I Feldman 20051 M. Feldman SIGccom Exdwnges, jul. 2005.

J.

Chuang. "Q,·ercomi ng Frec-riding Bchavior in Pecr·to· Peer Systems", ACM

I fddmcier 1988) O. Fcldmcicr. ~lmproving Gatcway Performance wilh a Routing Tablc Cachc". Proc. 19881EEE lnfocom. Nova Orlcans, mor. 1988. I Feldmcic r 1995 I O. Feldmcier. ·Fast Software h11plemcnt:uion of !Zrror Detection Codes". IEEEIACM Tnmsacllons on NC/IvoJIIing. vol. 3, n. 6, dez. 1995, p. 640-652. IFIPS 19951 Federal lnfo nnatlon Proccssing Standard. "Sccure Hnsh StnndardM, FIPS Publicmion 180-1. lmp:// www.ltl.11 ist.gov/11 pspubslfipl80-l.hun. lfloyd 19991 S. Floyd , M. llanc.lley,J. Padhye,J. Widmer. "Equatlon-Bascd Congesu on Control in thc lmernet•, IEEEIACM Trmrscrcllons on Ne1worl1ing, vol. 6 , n. 5, out. 1998, p. -158-472. lfloyd 2000) S. Floyd, M. Hanclley, ). Padhyt e J. Widmcr. "Equ:u lon-Basccl Congcstio n Control for Unicast Applications" . Proc. 2000 J\CM Sigcormn Confercncc, Estocolmo. :1go. 2000. (Fioyd 20011 S. Flo)·d . hr\ Rcport on Some Recent Oevelopments in TCP Congcslion Contror. IEEE Communiccuious Mllgcu:iuc, abr. 2001. (floyd 20091 S. Floyd. · Refcrences on REO ( Random Early Detcction) Queuc Managcmcnt", hup://www.icir. org!Ooydlred.html.

I Floyd Synchron izatio n 1994 I S. Floyd c V. jacobson. · synchroniz.ation of Pcriodic Routing Mcssagcs", IEEE/ ACM Trcmscrctions ou Nrtwoll:i11g, vol. 2, n. 2, abr. 1997, p. 122-136. [ Floyd TCP 19941 S. Floyd. "TCP and Explicil Congcsüo n Noüficaüon", ACM Comptller Communícalion Review, vol. 24, n. 5 , oul. 1994, p. l0-23.

bow4tto4ic~ Redes de computadores e o Interne~!-----------------------

I fluhrer 2 001) S. Fluhrcr, I. Mantin e A. Shamir. "Wcaknesses in thc Kcy Schcduling Algorithm of RC4~, Eighrh Annual Workshop ou Srltcttd Areas in Cl)•!nograr)hy , Toronto. ago. 2002.

I Foru 2000 I 8. Fortz c M. Thorup. "Internet Traffic Engínccríng by O ptimizing OSPF Wcights•, Proc. 2000 IEEE lnfocorn , Tcl Aviv, abr. 2000.

I Foru 200 2) 8. Fortz,J. Rcxford c~- Thorup. "Traffic Enginccring with TraditionaiiP Rouling Protocols·,1EEE Commurucarion 1\tagt!Zrllt, out. 2002.

I f oster 20021 I. Foste r. "Thc Grid: A Ncw lnfrasliUcture for 21st Ccmury Sclcncc· . Physics Toclay, vol. 55, n. 2. 2002, p. .U-47. l f ralcigh 2003) C. Frnlcigh, T. Tobagi, C. Diot. "Pro,·isíoning IP backbonc Networks to Suppon L·uency Sensitivc Traffic•, Proc. IEEE lnfocom Conference , San Francisco, mar. 2003. I France Tclccom 2009) Objcct ldcmifier (OID) rcpository, hup://asnl.clibcl.unJr/oidl. I Freedman 2004 I M.J. Frcedman, E. Freudemhal, D. Mazires. "Democmtizi ng Contclll Pllblicmion wilh Coral", USENIX < 501, 2004. IFricdma n 1999 1 T. Frieclman e O. Towsley. "Muhicast Scssion Mcmbership Sizc Estilll1Hion", Pror. 1999 /fEE

llifocom, Nova York, m:1r. 1999. IFrost 1994 ] sockets.html.

J.

Frost.

·sso Sockets:

A Quick and Dirty Primer~ . http://world .std.com/~jimf/pílpe rs/sockets/

(Gallager 19831 R. G. Gallílghcr, P. A. Humblet e P. M. Spira. • A Distribmcd Algoruhm for Minimum WcigluSJ)ôlllning Trccs·. ACM Twus. ou Progrcuumiug Ltutgtwge3 aud Sywms, vol. 1. n. 5, jan. 1983, p. óô-77. lGao 200 1) L. Gao e J. Rcxford. "Stable Internet Routing Without Global Coordination", IEEEIACM Trans. Ncth'otl:iug. vol. 9. n . 6, dez. 2001. p. 681-692. (Garccs-Erce 2003) L Garces-Ercc. K. W. Ross, E. Bicrsack , P. Fclber c G. Un·oy-Kcllcr. "TOPLUS: Topology Centric Lookup Scrvicc~ , Fifth lutmmtiorwl Workshop on Ncll••orllcd Gr oup Communicmion:. (NGCOJ), Munique, set. 2003. hup://cis.poly.cdu/~ross/J)

sss

(Gtlha 2006) S. Guha, . Daswani, R. Jaín. ~An Experi mental Study of Lhe Skypc Pccr-to-Pecr Vo!P Systcm•, Proc. Fijtl1 /nt. \Vorkshop 011 P2P Syswns. Santa Bárbara, 2006. (Guo 20051 L Guo. S. Chen, Z. Xiao, E. Tan, X. Oing, X. Zhang. "Measurcmcnt, Analysis. :md Modeling of BitTorrcnt-llke Srstcms·. ACM lme•ncr Mca.sureme111 Confcrenrc (IMC), 2005. IGupt a 19981 P. Gupta, S. Lm c . McKcown. "Routing Lookups rn Hardware at Mcmory Acccss Spccds". Proc. J998 IEEl: lnfocom 1998. Silo Franci.sco, abr. 1998. p. 12-H-12-+8.

I Gupta

200 1 ) P. Gupta c N. McKcown. "Aigorithms for Packet C lassification·. lf:ff: Nrrwork Muguzinc, vol. 15. n . 2. marJ abr. 200 1. p. 2+32.

(Ha 2008] I. Rhcc , S. Ha, L Xu. "CUBIC: A Ncw TC P-Fricndly High-Spccd TCP Variant", 1\C\1 SIGOPS

OJJt rating Sysurn Rtview, 2008. ( lia in 2005) T. llain. "1\ Progra mmic Repon on IP\·4 Address Space Consumption". lnttmct Protorol ) onnral.

,,oi. 8, n. 3. (Halabi 20001 S. Halabi. lr11cnw Rowing Arcllircetures, 2 cd. Cisco Prcss, 2000. IKalpcri n 20081 O. li:1lpcrin, T. Hcydt-lknjami n, 8. Rllllsford, S. C lark, 8 . Dcfcnd. W . Morg:Hl, K. Fu, T . Kohno. W. M:r iscl. " P:~ ccmakcrs :mel implantablc cardiac dcfibrillators: Softw:uc mdio auacks and zcro-powcr dcfcnses", Proc. 29th 1\ruuw/ IEEE Symposium 011 Sccurity crml Prh·crcy , maio 2008. (llamada 1997 1 T. lia macia, 11. Kamata c S. Hogg. "An Over"ícw of thc TINA Managcmcnt Archítccture" ,jounwl

ofNcovorll aml Sysum~ Ma11agruwrt , vol. 5, n . 4 , dez. JQ97, p. 4 11-435.

I Hei 2007) X. llc1. C. Laang. j . Liang. Y Uu. K. System", IEEE Twns. 011 Mu/trructlw, dez. 2007.

W. Ross.

~A mcasurcmcnL SLud)' of

a Ulrge-scalc P2P JPTV

1997 I J. Jlctdcmann, K. Obraczka c J. Touch. ~Modclíng thc Performance of JI TTP O' 'cr Severa! Transport Protocols". IEEEIAO.I Transactions 011 i\'ctworlting. vol. 5. n. 5. ou t. 19Q7. p. 616-630.

I Heidema n n

[Held 200 1] G. Hcld.

De~w

Ow Wiu:lrss Nrrwollls: 8/uctootlt. W;\P, tmd Wiltltss LANs. McG raw-Hill. 2001.

(Hersent 2000) O. Hcrscnt. O. Gurle cj-P. Pelit. IP Tdcpltony; P«cket-Based Mulrimrtli« Communie«tion Systcms". Edmburgh: Pcarson Edu<.-ation Límited , 2000. (Holla n d 200 11 G. Holland, N. Vaiclya, V. Bahl. kA Rate-Adaptlve MA C Protocol for Multi-Hop \Virelcss Nctworks", Proc . 2001 1\CM 1111. Confrrtnce of Mobile Com1mting atrd Ntlworlwrg (MobicomOI ), Roma , jul. 2001. (Hollot 2001) C. V. Hollot, V. Misra, O. Towsley e \V. Gong. ·•Analysis and Ocstgn of Controllcrs for AQM Routcrs Supporling TCP Flows", /EEE Tr«usaclions 011 Automalic Control, vol. 47, n. 6,jun. 2002, p. 945-959. (llua ng 20021 C. ll:nmg, V. Sharmn, K. Owcns e V. Makam. "Building Reliable MPLS Networks Using :1 Path Protection Mcchanism", IEEE Cou11nmtiatlions Magazin<. vol. 40. n. 3. mar. 2002, p. 156-161. ( Kuang 2005) Y. Hua ng, R. G11crí n. •·Does Ovcr-Provisio lting Bccomc More or Lcss Erncic nt :~s Nctworks G1·ow L.mgcr?~. Proc. IEEE lnt. Couf Nttwork Protocols (ICNP), Boston, nov. 2005. (H ua ng 2007] C. lluang, J. U , Angela Wang e K. W. Ross. QCan Internet VoD bc Prontabler. Proc. 1\CM SIGCOMM. Kyoto, ngo. 2007. IHunng 20081 C. lluang, J . Li, Angcla Wang e K. W. Ross. ~u ndcrstanding llybrid C DN-P2P: Why Limclight Nccds lts Own Rcd Swoosh ", NOSSDAV 2008, Brauns<'hwcíg, maio 2008. I Huit~ma 19981 C. lluitema. /Pv6; Thc

I Huston

Ncw lnrcnw Prorocol, 2 cd. Englcwood Cliffs: Prcnlicc llall, 1998.

1999a I G. Huston. "lntcrconncction , Pccring, and Scnlcmcnts - Para I", Tltr /nttntct Proroco!) ounral ,

"01. 2. n. I, mar. 1999. I H uston 2001 I G. Huston. "í\nalyzing Lhe Internet BGP Rouung Tablc". Thr /ntcrntl Prorocol )ounwl. vol. 4. n. 1, mar. 200 I. [Huston 2004) G. Huston. "NAT Anatomy: A Look lnside Network Address Translators~. Tite Internet Protocol ]oumal, vol. 7, n. 3, set. 2004.

bow4tto4ic~ Redes de computadores e o Interne~!-----------------------

I Hus too 2008al G. lluston. "Confronting 1Pv4 Address Exhaustion", lmp:l/www.polaroo.netftSpcol/2008-10/v-Jdepletion.html. (Hus ton 2008bl G. lluston. G. Michaelson. UIP,•6 Deployment: jltSt where are we?", hnp:l/www.potarro.net/ tspcol/2008-04/i pv6.h tm I. IIAB 20091 Internet Archhccturc Board homcpagc. hup:l/www.Jab.ory. IIANA 2009a) lntcrnet Assigncd Number A.uthority horne(XIgc. hup:l/www.mna.org/. IIA NA 2009bj Internet Assigned Numbcr Authority, "Prh'tlte Emcrprisc Numbcrs·, hup:l/www.iana.oryassignmcnts/cnccrprisc-nuntbcrs. IIANA Protocol Num bcrs 2009) Internet Assigned Numbers Authoril)'. Procot.-ol Nu mbers, hup:l/www.iana.

orglass ignmc n IS!pro Locol-n um bcrslprotocol-num bers.xh tml. (ICANN 20091 Thc Internet Corporation for Assígned Namcs and Numbcrs homepage, http://www.icann.org. IIEC O(Hical l009IIEC Online Ed ucation. "Opücal Access", hnp://www.icc.org/onll ne/unorials/opt_acc/. llEEE 802 2009) 1EEE 802 LANIMAN Standtmls Commiucc homepagc, lmp://www.lccc802.org/. II EEE 802. 11 19991 IEEE 802. 11 . 1999 Edition ( ISOIIEC 8802- I l : 1999) IEEE Standarcls ror Jnformation Tcehnology- Telecommunicatlons and Information Exchange llctwecn S)•Stcms - Local a11d Mecropolit:m Arca Nctwork- Spccific Rcquircmcncs - Part ll: Wi rclcss u\N Medi um Acccss Control (MAC) and Ph)'Sk111 Laycr (PHY) Specincatíon. http://st:mdards.ieee.orglgecieec8021downloadl802.11·1999.pdf. (IEEE 802.1 In I IEEE, • tEEE P802.11- Task Group N - Meeting Upda te: StalliS of802.lln·. hup://grouper. iccc.org/groups/80211 1/Reporlsltgn_updatc.hun. (IEEE 801. 15 2009) IEEE 802.15 Working Group for WPAN homepage, http://grouper.ieec.ory groups/802115/. (IEEE 802.16d 2004) IEEE, -IEEE Standarcl for Local and Metropolu:m Arc-.t NCt\\ Orks. Partl6: Air Interface for Fixcd Broadband Wirclcss Acccss Systcms-, hup://standards.iccc.orglgcticcc8021download/802.16-2004.pdf. IIEEE 802. 16e 20051 IEEE, "IEEE Standa rd for Local and Mctropolitan Arca · ctworks, Part 16: Air Interface for Fixed Broadband Wireless Access Systcms, Amendmcnl 2: Physical and Medlum Access Control la)•crs for Combined Fixed and Mobile Opcration in Licemed Bands and Corrigcndum t •, http://standards.icce.orglgctieee8021download/802.16c-2005.pdf. ITEEE 802. lq 200S I IEEE, ~I EEE Standard for Local and Metropolítan Arca Networks: Virtual Bridged Local Arca Nctworks. http://stancl:uds.icce.org/gctieec8021download/802.1Q-2005. pdf. IIEEE 802. 1XI IEEE Std 802.1X-200l Port-Bascd Network Acccss Comrol. http://standards.iecc.org/rcading/ ieec/std_pu bl ic/clesaipt ion/la nm:~n/802. 1 x-200 l_desc.h 1ml. (I EEE 802.3 2009l1EEE. "IEEE 802.3 CSMA/CD (Ethcrnct)". hup://grouper.iccc.org/groups/80213. (IEEE 802.5 2009]1EEE, IEEE 802.5 homcpage, hllp:l/iccc802.org15/w\vw802.5orgl. ( IETF 2009llntcrnct Engineeríng Task Force homcpagc. http://www.ictf.org. (IMAP 20091 Thc IMAP Conncction. http://www.imap.org/. (I ntel 2009) Incei Corp, "Intel® 82544 Gigabit Echernct Concrollcr", hup:J/www.intel.com/designlnetworkl products!lan/docsl8255_docs.htm. (I ntel WIMax 2009)Intgcl Corp.,

~wiMax Technology~.

hup://www.intel.com/ccchnology/wimaxlindcx.htm.

l lntemet2 Multlcast 2009) lnternet2 Muhicasl Working Group homepage. http://muhicast.internet2.edu/. 11Pv6 2009) IPv6.com homcp:tgc, hup://www.ipv6.com/. IJSC 2009llntcrnct Srstems Consortium homepage. http://www.isc.org. [151 1979) lnformation Sciences lnstitute, "DoD Standard Internet Protocol", Internet Engineering Note 123, dez. 1979, hnp://www.isi.edu/in-notes/ien/ien123.txt.


liSO 10091 lntern:uional Organization [or Standardizalion homepage, lnternational Organization for Standa rdization, hu p://www.iso.org/. l iSO X.680 2002) lnternational O rganization for Standardiza tion. "X.680: ITU-T Recomrncndation X.680 (2002) ln forn~
IITU Sta t istlcs l009)1ntc rnatíonal Tclecommunícatlon Union. "ICT Statistks", http://www.it u.tn liiTU-DiicteyciRcports.aspx. l tycr 10021 S. lyer, R. Zhung c N. McKeown. "Romers wít h a Single Stagc of 13uffcrrng". Proc. 2002 ACM Sigcomm Pitts!Jurglr, ago. 2002. IJa cobson 1988] V. jacobson. "Congcstion Avoidancc and Control", ProCI.>t·clings of ACM SIGCOMM, Stanfo rd, ago. 1988. p. 314·329. Uacobson 1988) V. J<~l'Obson. "CongcsLion Avoidancc ancl Control'', Proc. J988 ACM SIGCOMM, Píu.sburgh, ago. 2002. Uain 19861 R. Jain. "A tlmcoUL-bascd congeslion conlrol schcmc for winclow now-controlkd nctworks'', IEEE journal of Srlrcwl ArrcLç iu Cormnrmíccrlíons SAC-I, 7, out. 1986. Uain 19891 R. jain. "A Delay-Based Approach for Congcslion Avoldance In lnterconnccu~cl Hctcrogcneous Computcr Nctworks·. ACM SIGCOMM Ccmputer Communications Rcvil'h'. ''OI. 19. n. 5. 1989. p. 56-71. Uain 19941 R. Jam. FDDl Handbooh: Higlt-Speed Networlting Using Fibe1· mrd Otlrcr Meclia. Reading: Addison-Wcslcy. 1994. Uain 19961 R. Jain, S. Kal)'
ATM

Uaiswal 2003 1 S. Jaiswal. G. 1a nnacconc. c. Oiot, J. Kurosc c o. Towsley. "Measurcmcnt and Classification or Out-of-Scqucnce Packets 111 a Tier-1 1P backbone". Proc. 2003 IEEE INFOCOM. Uakobson 19931 G. jacobson c M. Weíssman. •AJarm Correlation". IEEE Nwvorl: MCigazlnt, 1993, p. 52-59. Ul1003) P. Ji, Z. Ge,J. Kurosc

P

O. Towslcy. •A Comparison o f Hard-Statc anel Soft-Statc Signali ng Protocols",

Proc 2003 ACM S/GCOMM. Karlsruhe, ago. 2003, hup://www.acm.orglsrgs/sigcomm/sigcomm2003/papcrsl

p25 1-ji.pdf. Uiang 200 1I W. j inng, J . Lcn nox. 11. Schulzrinnc c K. Singh. "Towards Junking thc PBX: Deplo)•ing IP Tclephon>•", NOSSDA\1'01. Porljefferson,jun. 2001. Uin 2004 I C.Jin, O. X. Wc c S. Low. ''rAST TCI': Molivation. ArchitccLUrc. Algorilhms, Performance". Pmcrrcliug of lEéE lrifocom, llong Kong, mar. 2004. Uu nl per 20091 junipcr Networks. "Provider Network Management", hup://www.Juniper.net/soiULío nslservice_ pro\'i cler/providcr_nctwork_ managemcnt/. IJ

(Kar 20001 K. Kar, M. Kodialam e T.V. Lakshm:m. "Mínimum lnlerfcrcncc Roullng of Bandwidlh Guarameed Tunncls with MPLS Trame Enginccring Applications", IEEE]. Srlwcd Arcas in Communlcations, dez. 2000. [Karol 1987) M. Karol. M. Hluchyj e A. Morgan. ~l npUI Versus Output Qucuing on a Space-Divasion Packet Switch", IEEE Transactions on Communications, vol. COM-35, n. 12, dez. 1987, p. 1347· 1356. IKatabi 20021 O. Katabi, M. Handley, C Rohrs. "lnternet Congesuon Control for Future High Bandwtdth-Delay Product Environmcnts". Proc. 2002 J\Ci\1 SIGCOMM, Pinsburgh, ago. 2002. IKatu la 199511. K:uzcla eM. Schwartz. "Schemcs for Fault ldentirication in Communkation ACM Trnnsacrion~ on Nctwoll:ing, vol. 3 , n . O, dez. 1995, p. 753-764.

1clworks",

I Kauúnan 1995) C. Kaufman, R. Perl man c M. Spccincr. Nctworl1 Srcurity. Prii'Crlc Comnwnication In Wodd. Englewood Cllffs: Prcmicc Hall , 1995.

c1

IEEE/ Public

IKclly 1998] F. P. Kell)'· A. Maulloo, D. Tan. "Rate control for communication networks: Shadow priccs, proporti onal fairness :md stabilh>•",J . Or,cmllons Rcs. Soe. , vol. 49, n . 3.p. 237-252, mar. 1998.

I Kclly 20031 F. P. Kclly. "Scaluble TCP: improving performance in high specd widc arca nctworks", 1\CM SIGCOMM Con1purrr Cornrnuuications Review, vol. 33, n. 2, abr. 2003, p. 83-91. (Kcshav 19981 S. Kcshav c R. Sharma. " lssucs and Trends in Routcr Dcsign· . IEEE CoullllWikalions Magatitlt, vol. 3ó. n. 5, maio 1998. p. 144-151. IKeslassy 200311. Kcslnssy. S. Chuang. K. Yu, D. Miller, M . 1-lorowiu:. O. Solgaard, Me Kcown. "Scaling Internet RoUlcrs Using Optics~. Proc. 2003 1\CM SIGCOMM , Karlsruhc. ago. 2003. I Kilklú 1999) K. Kilkki. Diffcrcnliatcd Servlces for tl1c lnttmct . lndi:tnápolis: Macmillan Tcchmcal Publishing. 1999. (Kim 2005] 11. Kim, S. Rixner, V. Pai. 54, 11 . 11, ov. 2005, p. 1394· 1408.

~Network

Interface Data Cuching", IEEE Transacltons on Compull'rs, \•oi.

IKim 2008) C. Kim, M. CaCSJJr, J. Rexford. · ftoodless in SEATTLE: A Scnlablc EthC'rncl Archltccturc ror Large Entcrpriscs~. Proc. 1\CM SIGCOMM '08, ago. 2008. Scattlr. I Kleinrock 196 11 1 Kleinrock. ~t nfonnation Flow in Largc CommunicatiOll Networks·, RLE Qualltrly Progrtss Rt{tOrt, jul. 196l. I Klcinrock 1964 I L. Klcinrock. 196..f Communicalion Ncu: Stoclwstic Mtssagc Flow wul Dtltty. Nova York: McGraw-llill, 19{)4. IKlcin rock 1975I L. l
~Thc

Binh of Lhe lmcmct", hup://www.lk.es.ucl:l.CduiLK/lrlctlbirth.hun l

I Koh lcr 20061 E. Kohlcr, M. ll:mdlcy, S. Floyd. "DCCP: Dcsigning DCCP: Congeslion Control Witholll Proc. 2006 ACM SIGCO.\JM, Pisa, set. 2006

Rcliabilily~,

[Korh onen 20031 j. Korhoncn. /ntrodnction to 3C Mobile Commwtictttions, 2 cd. Artech Housc, 2003. I Krishnamurthy 200 l i 8 . Krishnamunhy c j . Rcxford. Wcb Protocols mui Pwctict: H1íPIJ .1, Networking Protocols. and Traffic Mea.~uremrnl. Boston: Addison-Wesley, 2001. IKrishnanmrth y 2001b l B. Krishnamurth)•. C. Wills. Y. Zhang. · on thc Use and Performance of Comem DisLribution Nclworks-, i\C.\1 lntc11trt Mcasuwncnt Confcrcnu. 2001. [Kulkarni 2005) S. Kulkarni, C. Rosenberg. "Opportunislic Scheduling: Generalizations to lnclude Mulliple Constraints, Multiple Interfaces and Shon Term Fairness", Wireless Necworlls, 11, 557-569, 2005.


I Kumar 2006 I R. Kumar, K. W. Ross. ~optimal Pcer-Asslstcd File Dístribulion: Sínglc and Muhi-Ciass Problcrns", IEEE Worl:si•OJ>

011

Hot Tot>ics in Wrb Systrms and Tedlllologirs, Boston, 2006.

I Kurose 1996J J. F. Kurose. "Unix Network ProgTammiog· . http://gaia.cs.umass.cdulntu_socketl. ILabovit ~

19971 C. Labo,'itz, G.R. Malan e F. jahanian. • Jnternet Routlng lnstab•lity·. Procudings of J\CM SIGCOMM '97. Canncs. 1997. p. 115-126. hup:l/www.acm.org/sigcomm/sigcornm97/papers/pl09.htnll. (Labrador 1999) M. Labmdor e S. Bancrjec. "Packct Dropping Pohcrcs for ATM and IP Nctworks·. IEEE Communicmions Surwys. vol. 2, n. 3 , Third Qu;~ner 1999, p. 2-H. llacage 2004J M. Lacugc. M. H. Manshaei, T. Turleui. "IEEE 802.11 R:uc t\dllption: A Practical Approach", ACM fui Symr1osium on Motlding. Arwlysís, cmd Simulation of Wirtlcss mui Mobile Sysrcms ( MS\ViM) . out. 2004, Veneza. I Lakshma n 199 71 T. V. Lakshman e U. Madhow. · ·rh e Performance o f TCI'Ilf> for Networks with t-Iigh Bandwidth-Dclll)' Products and Ranclomloss", IEEEIACM Transacrions on Nctworlling, vol. 5, n. 3, 1997, p. 336350. llam 1980 I S. Lam. "A Carricr Scnsc Multiple Acccss Protocol ror Local Nctworks~, ComputCI' Nctworl1s, vol. 4, 1980, p. 21-32, 1980. IL"lmport 1981 I L Lamport. "Password Authenúclltion with lnsecurc Communic;~ l ion ~ . Connnuniwtions of lhe ACM, vol. 24, n. 11 , nov. l98l , p. 770-772. ( Larmouth I 9961 J. L:mnomh. Undrrswnding OS r. lntemarional Thomson Compu ter Press, I 996. O caphulo 8 fllla sobre a ASN.I c está disponivcl on-linc em hup:l/www.salford .ac.~tklnilbookslosllall .html#head8. (Lawt on 200 11 G. L:twton. " ls 1Pv6 Finallr Gaining Ground?~.

IEEE

Compute•

Maga~iuc,

ago. 200 1, p. 11-15.

(Lein cr 1998] B. lcmcr, V. Cerf. O. Clark, R. Kahn, L Klcmrock. D. Lynch.J. Postei. L RoberlS c S. Woolr. ~A Bricr l liSlOI)' or thc lntcmct", http;//www.isoc.org/intcrnctlhisiOI'}'Ibrief.html. (li 2004] L. U. O. Aldcrson. W. Willingcr. j . Ooylc. ~A First-Principlcs t\pproach to Undcrst:mding thc lntcrnct"s Routcr-Lcvcl Topolog)•", Proc. 2004 ACM SIGCOMM, Portland, ago. 2004. (li 20071

J.

Li, M. Guiclt ro, Z. W u, E. Purpus, T. Ehrcnkranz. "BGP Routing Oynamics Revisitcd-, ACM

Compllll'r ColllllliiiiÍCCIIron Revicw, abr. 2007. (liang 20061 j . Liang, N. Nuoumov, K. W. Ross. ~rhc lndex Po1somng Auack in P2P Filc-Sharing Systcms·, Proc. 2006 IEEE Infocom 2006, Barcelona, abr. 2006. http://cis.poly.edu/-ross/papcrs/. IUn 2001 1 Y. Lin c I. Chlamtac. \Virdcss aru/ Mobile Nctwor/1 Ard•irccluii'S. No,•a York: john Wilc)' & Sons, 2001. (Liogkas 2006) N. Liogkas, R. Nelson, E. Kohlcr. L. Zhang. "Exploiling BitTorrcnl For Fun (Btll Not Profit)",

6tlr lnt1•nwrlomrl \VoriiShop on Prcr-to-Pcrr Systems (IPTPS 2006). IU u 20021 B. Ll u, D. Goeckcl e O. Towslcy. Nctworks", Proc. 2002 Glolx•l lntrmet.

~TCP-Cognlzant

Adapli,·c Forward Error Correction in W lrclcss

(Locher 2006] T. lochcr, P. Moor, S. Schmid, R. Waucnhofer. "Free Ridi ng in BitTorrcnl is

Chc-ap~ .

Proc.1\CM

HotNcls 2006, lrvlne, nO\'. 2006.

(Lu i 2004 I J. Lui. V. Mism, O. Rubcnstcin. "On the Robustness o f Soft Stme Protocols ", Proc. IEEE 1111. Confrrrnu ou Nc1wot11 Protocols (ICNP '0·0. p. 50-60. (luotonen 19981 A. Luotonen. Wrb Proxy Scn·crs. Englewood ClifTs: Prcntice Hall. 1998. llyneh 1993) D. Lynch c M. Rose. luternct System Hanclbool:. Rcading: Addison Wcslcy, 1993. (Macedon ia 19941 M. R. Maccdonia e O. P. Brutzman. ~MBonc Provrdcs t\ud•o anel Vídeo Across the Internet~ . LEEE COIIIJ>Uicr Mctgazinc, vol. 27, n. 4. abr. 1994. p. 30-36. [Mahda vi 1997 lJ. Mahdavi e S. Floyd. "TCP-Fricndly Unicast Rate-Based Flow Comrol-. nota não publicada, jan. 1997.


(Malwarc 2006) Computer Economícs. www .computcrcconomícs.com .

~2005

Malware Rcport: Thc lmpact of Malícious Codc Auacks•, hupJ/

IMa nct 2009) IJ:Tf Mobile Ad-li oc Nctworks ( manct) Workmg Group. hnp:IA,·ww.ietf.orglh tml.chaners/ manct-chancr.hlml. [Mao 20021 Z. M. Mao, C. Cranor. F. Oouglis. M. R.lbino,,ích. O. Spatschcck,j. Wang. ~A Precise and Efficicnt Evaluation of the Proximhy bctween Web Clients and their Local DNS Scrvers·. USENIX 2002. IMaym ounkov 2002) P. Maymou nkov c O. Maziercs. ~Kadcmli:t: A Pccr-to-Pccr lnfonn ati on Systcm Based on thc XOR Mctric·. Procrf(/ings of tl1c 1st lrJitnwlione~l Wor kslro11 on Pccr-ro-Perr· Systems (IP'l PS '02), mar. 2002. p. 53-65. IMcKcown l 997al N. McKcown, M. lzzard, A. Mckkiuikul,W. Ellers íck c M. llorowitz. "Thc Tmy Tcra: A Packct Switch Core", IEEE Mlc,.o Magtlúne, jan./fcv. 1997. IM c::Kc::own 1997b ) N. McKcown. ~A Fast Switched Backplanc for a Gigabi t Switchcd Routcr· , Bt1siruss Conununicmions Revirw. vol. 27, n. 12. http:l/tiny- tcra.stanford.cdu/-nicknv'J?apcrs/cisco_fasts-wp.pdf. IMcQuill:m 1980 1 J. McQuilla11, I. Richcr e E. Roscn. "Thc Ncw Rou1i11g Algorilh m for thc Arpanct", IEEE Tnmsnclions 0 11 Comm uuiwlions, COM-28(5), maio 1980, p. 711-719. (Mcdh i 1997 ) D. Mcdhi c O. Tippcr (cds.). ~special lssuc: Fault Managcmcnt in Communi cation Nclworks·. j ounwl of Nerwo r l1 wrcl Sysrcms Mcul(lgcnrrlll. vol. 5, n. 2, jun. 1997. (Meng 2005 I X. Mcng. "IP,•4 r\ddress Allcx::uion and thc BGP Roullng Tablc Evolutio n~, Comr>utcr Commu11icfllion

Rr1•icws. ''OI. 35, n. I. 2005, p. 71 -80. IMctcalfe 1976) R.M. Mctcalre e D. R. Boggs. • Ethcrnct: Dis tributcd Packct Swítchlng for Local Computer Nctworks·, Communimlions of the Associcuion for Computing Me~chinery, vol. 19, n. 7, jul. 1976, p. 395-104. IM FA Fo ru m 2009)1p!MPLS Forum homcpagc, hupJ/" ww.ípmplsforum.org/. l i'tiicrosoft Playcr Med ia 2009) Microsoft Windows Media homcpagc. http://www.microsofL.com/windows/ windowsmcdi:V. li't1illcr 1997) M. A. Millcr. Me~naging lntcmct"'orks h'it/J SNMP, 2 cd. Nova York: M & T Books. 1997. IMirkovic 2005) J. Mirkovk, S. Dictrich . D. Oitlrich . P. Rcihcr. fntrntcl Ocuie~l of Servia: Atltlck anel Defcnsc Mcdwnisms. Prcnt icc Hall, 2005. IMockapct ris 19881 P. V. Mockapctris e K.J. Dunlap. ~oevclopmcnt of thc Oom:1in Namc Systcm·, Procrcdings

of SIGCOMM '88, St:mfo rd, 1988. (Mockapetris 2 005) P. Mockapc1ris, Sigcomm Award lccturc, vídeo disponível em hup://www.postcl.orgtslgcomm.

IMogul 20 03 I J. Mogul. "TCP omoad is a dlllllb ide<~ whose time has come". Proc. Hot OS /X: "fltr 9rlt \Vorhs/rop ou llor Topic~ ill OjJrraling Systcms, 2003. USENIX .Association. IMolincro-Ferna ndc.: 2002) P. Molincro~Fcrnandcz, N. McKcown c H. Zhang. World (of Communit"lui ons)r. Proc. 2002 ACM Hotn elS.

~ ls

IP Going to Takc Ovcr thc

[Molle 19871 M L. Mollc, K Sohrnb)' c A. N. Venctsanopo ulos. "Space-Timc Models of ;\synchronous CSMA Protocols for Local Arca Nctworks~. IEEE]oumal on SdectedAn·CIS in Com11nwiccrlrons, vol. 5, 11. 6, 1987, p. 956-968. (Moort! 2001 I O. Moore, G. Voelker, S. Savage. ~lnferring Internet Denial or Scrvice Acti,•ily·. Pror. 2001 USENIX Sccurrty Symposrum , Washmgton, ago. 2001. IMoore 2003 ) D. Moorc, V. Paxson. S. S:wagc. C. Shannon. S. Stamford c N. Wcavcr. Srcurily curei P1imcy Conft rcuet.

~lnsrdc

th c Slammcr

Worm~. 2003 ltEE

(Mosh chuck 2006 ) A. Mos hchuk. T. Bragin , S. Gribblc, H. LC\')'· · A Crnwlcr-b.'\SCd Stud)• of Spywarc 011 thc Web", Proc. 13t h Amuwl Networl1 m1d DisLributed Systems Securily Syuwosium (NOSS 20061, San Oiego, fcv. 2006.

bow4tto4ic~ 591

Referincios

IMouly 19921 M. Mouly c M. Pautei. Tlu: GSM Syswn for Mobile Communicmions. Palaisrau: Ccll and Sys, 1992. IMoy 19981 J. Moy. OSPF: Anatomy of An lnumct Roming Protocol. Reading: Addison Wcsley. 1998. IMukhcrjee 19971 8. Mukhcrjee. Optical Communicmion Nccworl1s. McGraw-Hill. 1997. IMurphy 2003 I \'Cja (RFC -+272). [Nah u m 2002) E. Nahum. T . Barzilai e O. Kandlur. ·Pcrfonnancc lssues in WW\V Tra11~acclons 011 Nl'tiVOil!illg, vol. 10, n. 1, fcv. 2002. ( aoumov 20061

to·Perr lnfomwtion

Servers~.

IEEEIACM

. N:1ou mov, K. \V, Ross. WExploiúng P2P Sysu:ms for DDoS Auacks", 11111 \Vorhsltor• 011 PccrHong Kong. mai. 2006.

~lcmagcmc11t,

I eglia 2007 1 G. Ncglia, G. Reina, 11. Zhang, D. Towslcy. A. Vcnkatammani, BltTorrcn t SystcmsM, P1oc. IEEE TNFOCOM 2007, maí. 2007.

J.

Danahcr. "Availability in

INcu mann 1997) R. Ncum:mn. "lmcrnct Routing Black H.olc", Tl1r Rishs Digcst: Forum 011 Risl1s to tl1r Pub1ic in ColllfJlllr rs tultl Rclmcd Syslcms. vol. 19, n. 12. mai. 1997. hup:l/catl css.ncl.:•c. ukiRisks/19. 12.1wnl#subjl.l. [Newman 2008] O. Ncwm:m. ~so2.lln Gear 10 Times Fastcr Than Cum:nl Wi-Fi OITerings", Nwvorl1 Worhl, 27 out, 2008. hllp://www.nctworkworld.conllrcvicws/200S/102708-wlan-tcst.hunl?pagc•l. I icholson 2006) A. Nic holson. 'í. Chawathc, M. Chcn. B. Noblc. O. Wcthcmll. "'lmprovcd Acccss Point Proc. 200G ACM Mobisys Confrrcncc , Uppsala, 2006.

Sc l cction~ .

(Nielsen 1997111. F. Niclsen, J. Geu ys, A. Baird-Smith. E. Prud'hommeaux, 11. W. Lie c C. LiliC)'· "Ncrwork Perform:mcc EITccts of IITTP/1.1, CSSl , and PNG", WJC Docurnent. 1997 (pode ser encontrado também em Procccclings of ACM SIGCOMM '97, Cannes, p. 155-166) .

I 1ST 2001 I Nalional lnstitutc of Standards and Technology. "Advanccd Encryption Standard Freiem I lnjOIIntiiiOII Procrss•ng Stcrnclanls 197. fips-197.pdf.

110\'.

(AES)~.

200 1. hHp://csrc.mst.gov/publicationslfipslfips 197/

I Nmap 20091 Nmap homepagc. hHp:l/www.insccun:.com/nmap.

I on nenmachcr 1998) J. Nonnenmacher, E. Bicrsak e D. Towsle)'· · Parity·Bascd loss Recovery for Rcliable Mulucast TransmissionM, IEEE/ACM Transactio11s on Nctworhing , vol. 6. n. 4 , ago. 1998, p. 349-361. INTlA 1998) National TclccommunJcations and Information AdminJstmtion (NTIA), U.S. Dcpanmcm o f Commcrce. · Managemcnt of lmernet Namcs and Addresses·. Docket Numbcr: 9802 12036-8146·02. hup://www. ntia.doc.gov/ntiahomc/domainn:unc/6_5_98dns.hLm. I Odlyzko 20031 i\ . Odlyzko. "1ntcrnct Traffic Growth: Sourccs and Implications". A. /lf. OtJtictll Tw11smission Systcms altCI EquitmlCIIljor \VDM Nclworh ing 11, Proc. SPlE, 5247, 2003. p. 1-15. http://www.dtc.umn.edu/-odlyzko/ d oclltcom .i lll crnet.grow th. pd r. I051 20091 lntcrnational Organiz:u ion for Standardization homcpagc, hup:l/www.iso.org/iso/en/ISOOnlínc. frontp"Jge. IOSS 20091 OSS Nokalva. "ASN. l Rcsourccs· , hnp:l/www.oss.com/asn l/. IPadhye 20001 J. Padhye, V. Firoiu, O. Towslcy,j. Kurosc. "Modcling TCP Reno Performance: i\ Simplc Model and its Empirical Validalion·, IEEE/AC.\1 Trtmsactiou on Nenvorlling. vol. 8, n. 2. abr., p. 133-145. IPadhyc 2001) J . Padh)'C, S. Floyd. won Infcrring TCP Bch:wior", Prol'. 2001 ACM SIGCOMM, San Dicgo. ago. 2001. I Pan 1997) P. Pane H. Schulzrinne. "Slaged Rcfrcsh T imers for RSVP·. 211cl Globcd luttmet Cou]l·rence. Phoerüx, l997. IParekh 1993] A. Parekh e R. Gallagher. ~A Gener.tlized Proccssor Shanng Approach to Flow Control ín lmegrated Servíces Networks: lhe Single-Nodc Case", lEéEIACM Trcmsactious 011 Networl!ing, vol. 1, n. 3, jun. 1993, p. 344-357.

bow4tto4ic~ Red es de co 111 putodores e o Inle ;.; r n;.;e;.;.t_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __

IPartridge 1992) C. Part ridge c S. Pink. ~An lmplemrntalion of the RcviSCd In ternet Stream Protocol (ST-2)", jounwl of lniC'mctworhiug: Rrscarclt and E.''Pcriencc. vol. 3. n. 1. mar. 1992. I Panridge 19981 C. Panridge fi ai. · A Fifty Gigabit per second IP RoULerv. IEEEIACM Trausactions on Nmvorl1ing, vol. 6, n. 3 , JUil. 1998, p. 237-2;8. I Paxson 19971 V. Paxson. VEnd·to·End Internet Packct Dynamics~, Proc. 1997 ACM SIGCOMM '97, Cannes. sct. 1997.

I Pcrkins

1994 1 A. Perki ns. "Nctworki ng with Sob Metçalfc" , Tlle Rctl Hcrring Mugazinc, no''· 199-1.

IPcrkins 1998) C. Pcrkins. O. Hodson c V. Hardman. "A Sui"\IC)' of Packct Loss Rccovcry Tcchniqucs for SLrcamlng i\udio". IEEE Nctworh MugCizine, sctJout. 1998, p. 40-+7. IPcrkins 1998b) C. Pcrkins. Mobile IP: Design Principlrs w1el Pr,rcllcí'. Rcadlng: Addiso n Wcslcy, 1998. IPcrkin!> 2000] C. Pcrkins. Ad-lioc Nrtwotl:ir1g. Rcadíng: Addison-Wcslcy, 2000. I Pcrlman 1999) R. Pcrlm:m. ltlttrcoJwcctions: Bridges, Roulcrs, Swiuhcs, 111111 lnrt'r·uet wol'lting Proc.ocols, 2 cd. Rcading: Addison WcsiC)' Profcssion:~ l Computing Series, lQ99. (PGPI 2009] T he

l ntcrn:~t io nal

PCP Home Page, http://www.pgpt.org.

(Phifer 2000 1 L. Phifer. ·Thc Troublc with NAT", Tl1e Inlemcr Protocoljounwl, vol. 3, n. 4, dez. 2000, http:// www.cisco.com/wn rplpublic/759/ipj_3-4/ipj_3-4_nat.html. IPiatek 20071 M. Piatck, T. lsdal, T. Andcrson. A. KriSh namun hy, A. Vcnkat;tr:lmani. "Do lnccnlivcs Build Robustncss in BitTorrent?", Proc. NSDI, 2007. l Piak et 2008) M. Pimck, T. lsdal, A. Krishnamun hy, T. Andcrson. · onc hop RcpULations for Peer·to·Pecr File Sharing Workloads". Proc. NSDI, 2008. IPickholt: 1982) ll Pickhohz, O. Schilling e L Milstcin. •Thcory of Sprc;~d Spcctru m Communic-:uion - a Tu tonal". IEEE TICIIISllCIIOIIS on Communications, vol. COM-30, n. 5, mmo 1982, p. 855·88-1.

I Pingplottcr 2009 I pmgplouer homepagc, hup://www.pingplouer.com. (Piscatcllo 19931 O. Piscatcllo c A. l )'tnan Chapin. "Opcn Srstcms , ctworking· . Rcadmg: Add1son Wcslcy. 1993. (Point Topic 2006) Poi nt Topic Ltd. World BroCidbantl SttllJStics, Ql. 2006. hup://www.pomuop•c.com. (Pota roo 2009]

~Growth

of thc BGP Tablc - 199-1 to Prcscnt", http://bgp.potaroo nct/.

IPPU vc 2009 1 PPU"c h omcpagc, htt p://www.ppli vc.com. I PrlMctrlca 20091 Global In ternet Gcography, hupJ/www.telegeogmJ>hy.tom/prod uc ts/giglindcx.php. IQuickTime 2 009) Q uickTimc homcpagc, htt p://www.applc.com/quicktlmc. IQuittncr 19981 j . Quiuncr, M. Slatalla. Speeding Ll•c Net: Thc lusíclt- SIOI) ' of NciW1pl' cmcl How il ClwllcHgr'l Microsoft, Ada ntic Monthly Prcss, 1998. (Ramakris hnan 19901 K. K. Ra makrishnan c R. Jai n. " A Binary Fccd back Schcmc for Congestion t\voidancc In CompLHCr Nctworks", ACM Tram.acrions 0 11 Computei' Systcms, vol. 8, n. 2, maio l990, p. 158· 181. (Raman 19991 S. Ram;1n c S. McCan nc. ~A Modcl. Analysis, and Protocol Framcwork ror 5oft Statc·bascd Commu nication". Procwlings of ACM SIGCOMM '99, Boston, ago. 1999. IRama n 20071 B. Rama n, K. Chcbrolu. "Ex pcricnccs in Using WiFi for Ruml In ternet in lndia", IEEE. Communirmious Mc1ga:;int, Spccial lssuc on lC\v Oircctions in Nctworki ng Tcchnologies in Emcrgíng Economies, jan. 2007. (Ra maswa mi 1998) R. Ramaswami c K. Sivnmjan. OpticCil Neovorl1s: 1\ PICICtÍCCII Pc•sprctilt. !llorgan Kaufman Publishcrs. 1998. [ Ramjec 1994) R. Ramjec, J. Kurose, D. Towsley c H. Schulzrinne. "Adaptivc Playout Mechanisms for Packetized Audio Applicalions in Wid e-Area Networks", Proc. 1994 1EEE Infocom.

Redes de Computadores e a Internet - James F. Kurose, Keith W. Ross - 5ªEdição.pdf

Recommend Documents