p-Fe-icerscjn ancJ 8:11:26: 5. Davie:-
`
`“"13:ng—
`
`MIT 2003
`MIT 2003
`Limelight v. MIT
`Limelight v. MIT we ——:-—————
`IPR2017-00249
`IPR2017—00249
`
`FiFth Edition
`
`1
`
`

`

`
`
`'‘T‘‘ILflfim
`
`-~—-.-Ii(-I.
`
`..
`
`'fl.l-
`
`-n'
`
`1:
`
`i l l
`
`Acquiring Editor: Rick Adams
`Development Editor: Nate McFadden
`Project Manager: Paul Gottehrer
`Designer: Dennis Schaefer
`
`Morgan Kaufmann is an imprint of Elsevier
`30 Corporate Drive, Suite 400, Burlington, MA 01803, USA
`
`© 2012 Elsevier, Inc. All rights reserved. '
`
`No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical,
`including photocopying, recording, or any information storage and retrieval system, without permission in writing
`from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies
`and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing
`Agency, can be found at our website: wwwelsevier. com/permissions.
`
`This book and the individual contributions contained in it are protected under copyright by the Publisher (other than
`as may be noted herein).
`
`Notices
`Knowledge and best practice in this field are constantly changing. As new research and experience broaden our
`understanding, changes in research methods or professional practices, may become necessary. Practitioners and
`researchers must always rely on their own experience and knowledge in evaluating and using any information or
`methods described herein. In using such information or methods they should be mindful of their own safety and the
`safety of others, including parties for whom they have a professional responsibility.
`
`To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for
`any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from
`any use or operation of any methods, products, instructions, or ideas contained in the material herein.
`
`library of Congress Cataloging-in-Publication Data
`Peterson, Larry L.
`Computer networks : a syStems approach / Larry L. Peterson and Bruce S. Davie. — 5th ed.
`p. cm. — (The Morgan Kaufmann series in networking)
`Includes bibliographical references.
`ISBN 978-0-12-385059— 1 (hardback)
`1. Computer networks. I. Davie, Bruce S. 11. Title.
`TK5105.5.P479 2011
`004.6—dc22
`
`201 1000786
`
`British Library Cataloguing-in-Publication Data
`A catalogue record for this book is available from the British Library.
`
`ISBN: 978-0-12-385059—1
`
`
`For information on all Morgan Kaufrnann publican'ons
`
`. visit our website at www. mkp.com
`
`Typeset by: diacriTech, India
`
`Printed in the United States of America
`1213141516 10987654321
`
`
`
`Working together to grow
`libraries 1n developing countries
`www.clsevier.com I www.bookaid.org | www.5abre.org
`Sabre. Foundation internatirjnal
`EL-SE\=’iE,R
`300K Am
`
`2
`
`

`

`
`
`
`
` d F
`
`oreword
`Foreword to the First Edition
`
`Preface
`
`Contents
`
`1 Foundation
`
`Problem: Building a Network
`
`1.1 Applications
`
`1.1.1 Classes of Applications
`
`1.2 Requirements
`
`1.2.1 Perspectives
`1.2.2 Scalable Connectivity
`1.2.3 Cost—Effective Resource Sharing
`1.2.4 Support for Common Services
`
`1.2.5 Manageability
`1.3 Network Architecture
`
`1.3.1 Layering and Protocols
`1.3.2
`Internet Architecture
`
`1.4 Implementing Network Software
`
`1.4.1 Application Programming Interface
`(Sockets)
`
`1.4.2 ExampleApplication
`1.5 Performance
`
`1.5.1 Bandwidth and Latency
`1.5.2 Delay >< Bandwidth Product
`
`1.5.3 High-Speed Networks
`
`1.5.4 Application Performance Needs
`
`1.6 Summary
`What’s Next: Cloud Computing
`Further Reading
`Exercises
`
`2 Getting Connected
`
`Problem: Connecting to a Network
`2.1 Perspectives on Connecting
`2.1.1 Classes of Links.
`
`FE.b?
`
`xiii
`
`CONCDQJNb—I
`
`13
`
`18
`
`23
`
`24
`
`24
`
`33
`
`36
`
`37
`
`40
`
`44
`
`44
`
`48
`
`51
`
`53
`
`55
`
`57
`
`58
`
`60
`
`71
`
`72
`
`75
`
`
`
`XXV
`
`3
`
`

`

`
`
`xxvi
`
`Contents
`
`78
`
`81
`
`83
`
`85
`
`88
`
`91
`
`93
`
`94
`
`97
`
`102
`
`103
`
`106
`
`118
`
`119
`
`120
`
`122
`
`127
`
`128
`
`135
`
`142
`
`144
`
`148
`
`150
`
`151
`
`153
`
`169
`
`170
`
`172
`
`174
`
`186
`
`189
`
`203
`
`203
`
`2.2 Encoding (NRZ, NRZI, Manchester, 4B/5B)
`2.3 Framing
`2.3.1 Byte-Oriented Protocols (BISYNC, PPP,
`DDCMP)
`
`2.3.2 Bit-Oriented Protocols (HDLC)
`
`2.3.3 Clock—Based Framing (SONET)
`2.4 Error Detection
`
`2.4.1 Two-Dimensional Parity
`2.4.2
`Internet Checksum Algorithm
`2.4.3 Cyclic Redundancy Check
`2.5 Reliable Transmission
`
`Stop—and-Wait
`2.5.1
`2.5.2 Sliding Window
`2.5.3 Concurrent Logical Channels
`2.6 Ethernet and Multiple Access Networks (802.3)
`
`2.6.1 Physical Properties
`2.6.2 Access Protocol
`
`2.6.3 Experience with Ethernet
`2.7 Wireless
`
`2.7.1
`
`802.11/Wi—Fi
`
`2.7.2 Bluetooth®(802.15.1)
`
`2.7.3 Cell Phone Technologies
`
`2.8 Summary
`What’s Next: “The Internet of Things”
`
`Further Reading
`Exercises
`
`3
`
`lnternetworking
`
`Problem: Not All Networks are Directly Connected
`
`3.1 Switching and Bridging
`
`3.1.1 Datagrams
`3.1.2 Virtual Circuit Switching
`
`3.1.3 Source Routing
`3.1.4 Bridges and LAN Switches
`3.2 Basic Internetworking (1P)
`3.2.1 What Is an Internetwork?
`
`3.2.2 Service Model
`
`3.2.3 Global Addresses
`
`3.2.4 Datagram Forwarding in IP
`3.2.5 Subnetting and Classless Addressing
`4
`
`216
`
`206
`
`213
`
`220
`
`4
`
`

`

`
`
`
`
`Contents
`
`xxvii
`
`iwlflm
`
`".'"I'mll'r—‘I.‘K'
`
`3.2.6 Address Translation (ARP)
`
`3.2.7 Host Configuration (DHCP)
`
`3.2.8 Error Reporting (ICMP)
`3.2.9 Virtual Networks and Tunnels
`
`3.3 Routing
`
`3.3.1 Network as a Graph
`3.3.2 Distance Vector (RIP)
`
`3.3.3 Link State (OSPF)
`3.3.4 Metrics
`
`3.4 Implementation and Performance
`3.4.1
`Switch Basics
`
`3.4.2 Ports
`
`3.4.3 Fabrics
`
`3.4.4 Router Implementation
`
`3.5 Summary
`What’s Next: The Future Internet
`
`Further Reading
`Exercises
`
`4 Advanced Internetworking
`
`Problem: Scaling to Billions
`4.1 The Global Internet
`
`4.1.1 Routing Areas
`4.1.2
`Interdomain Routing (BGP)
`4.1.3
`IP Version 6 (IPv6)
`4.2 Multicast
`
`4.2.1 Multicast Addresses
`
`4.2.2 Multicast Routing (DVMRP, PIM, MSDP)
`4.3 Multiprotocol Label Switching (MPLS)
`4.3.1 Destination-Based Forwarding
`4.3.2 Explicit Routing
`4.3.3 Virtual Private Networks and Tunnels
`
`4.4 Routing among Mobile Devices
`4.4.1 Challenges for Mobile Networking
`4.4.2 Routing to Mobile Hosts (Mobile 1P)
`4.5 Summary
`What’s Next: Deployment of IPv6
`Further Reading
`Exercises
`
`228 7
`231
`
`235
`
`235
`
`240
`
`242
`
`243
`
`252
`
`262
`
`266
`
`267
`
`270
`
`273
`
`277
`
`280
`
`281
`
`282
`
`284
`
`307
`
`308
`
`310
`
`313
`
`324
`
`338
`
`340
`
`341
`
`354
`
`355
`
`362
`
`354 ‘
`369
`
`369
`
`372
`
`379
`
`380
`
`381
`
`382
`
`
`
`5
`
`

`

`
`
`xxviii
`
`Contents
`
`5 End-to-End Protocols
`
`Problem: Getting Process to Communicate
`
`5.1 Simple Demultiplexer (UDP)
`5.2 Reliable Byte Stream (TCP)
`5.2.1 End—to-End Issues
`
`5.2.2 Segment Format
`5.2.3 Connection Establishment and
`Termination
`
`5.2.4 Sliding Window Revisited
`5.2.5 Triggering Transmission
`5.2.6 Adaptive Retransmission
`5.2.7 Record Boundaries
`
`5.2.8 TCP Extensions
`
`5.2.9 Performance
`
`5.2.10 Alternative Design Choices
`5.3 Remote Procedure Call
`
`5.3.1 RPC Fundamentals
`
`5.3.2 RPC Implementations (SunRPC, DCE)
`5.4 Transport for Real—Time Applications (RTP)
`
`5.4.1 Requirements
`
`5.4.2 RTP Design
`5.4.3 Control Protocol
`
`5.5 Summary
`What’s Next: Transport Protocol Diversity
`
`Further Reading
`Exercises
`
`6 Congestion Control and Resource
`Allocation
`
`Problem: Allocating Resources
`6.1 Issues in Resource Allocation
`
`6.1.1 Network Model
`
`6.1.2 Taxonomy
`6.1.3 Evaluation Criteria
`
`6.2 Queuing Disciplines
`6.2.1
`FIFO
`
`6.2.2 Fair Queuing
`6.3 TCP Congestion Control
`6.3.1 Additive Increase/ Multiplicative
`Decrease
`
`6
`
`391
`
`393
`
`396
`
`397
`
`400
`
`402
`
`407
`
`414
`
`418
`
`422
`
`423
`
`425
`
`428
`
`431
`
`431
`
`440
`
`447
`
`449
`
`452
`
`456
`
`460
`
`461
`
`462
`
`463
`
`479
`
`480
`
`481
`
`485
`
`488
`
`492
`
`492
`
`494
`
`499
`
`500
`
`ir
`
`-'“1—H!-I-“—-‘rdIQ—m
`
`
`
`c:r-—-—.—-n';-v—_I-=...——.
`
`‘—t—-—|—-
`
`
`
`
`
`”CFI—n—l4.—="lly—fid‘I—L.—HI-_l_
`
`6
`
`

`

`Contents
`
`xxix
`
`
`
`
`
`6.3.2 Slow Start
`
`III
`
`6.3.3 Fast Retransmit and Fast Recovery
`6.4 Congestion-Avoidance Mechanisms
`6.4.1 DECbit
`
`6.4.2 Random Early Detection (RED)
`6.4.3
`Source—Based Congestion Avoidance
`6.5 Quality of Service
`
`6.5.1 Application Requirements
`6.5.2
`Integrated Services (RSVP)
`6.5.3 Differentiated Services (EF, AF)
`6.5.4 Equation-Based Congestion Control
`6.6 Summary
`What’s Next: Refactoring the Network
`Further Reading
`Exercises
`
`7 End—to-End Data
`
`Problem: What Do We Do with the Data?
`
`7.1 Presentation Formatting
`7.1.1 Taxonomy
`7.1.2 Examples (XDR, ASN.1, NDR)
`7.1.3 Markup Languages (XML)
`7.2 Multimedia Data
`
`7.2.1 Lossless Compression Techniques
`7.2.2
`Image Representation and
`Compression (GIF, JPEG)
`7.2.3 Video Compression (MPEG)
`7.2.4 Transmitting MPEG over a Network
`7.2.5 Audio Compression (MP3)
`7.3 Summary
`What’s Next: Video Everywhere
`Further Reading
`Exercises
`
`8 Network Security
`
`Problem: Security Attacks
`8.1 Cryptographic Building Blocks
`8.1.1 Principles of Ciphers
`8.1.2 Symmetric-Key Ciphers
`
`505
`
`510
`
`514
`
`515
`
`516
`
`523
`
`530
`
`531
`
`537
`
`549
`
`557
`
`559
`
`560
`
`561
`
`563
`
`579
`
`581
`
`583
`
`587
`
`592
`
`596
`
`598
`
`601
`
`609
`
`614
`
`619
`
`621
`
`622
`
`623
`
`624
`
`633
`
`635
`
`635
`
`638
`
`
`
`7
`
`

`

`
`
`XXX
`
`Contents
`
`8.1.3 Public-Key Ciphers
`8.1.4 Authenticators
`
`8.2 Key Predistribution
`8.2.1 Predistribution of Public Keys
`
`8.2.2 Predistribution of Symmetric Keys
`8.3 Authentication Protocols
`
`8.3.1 Originality and Timeliness Techniques
`8.3.2 Public-Key Authentication Protocols
`8.3.3 Symmetric-KeyAuthentication
`Protocols
`
`8.3.4 Diffie-Hellman Key Agreement
`
`8.4 Example Systems
`8.4.1 Pretty Good Privacy (PGP)
`8.4.2 Secure Shell (SSH)
`
`8.4.3 Transport Layer Security
`(TLS, SSL, HTTPS)
`
`8.4.4
`IP Security (IPsec)
`8.4.5 Wireless Security (802.11i)
`8.5 Firewalls
`
`8.5.1 Strengths and Weaknesses of Firewalls
`
`8.6 Summary
`What’s Next: Coming to- Grips with Security
`
`Further Reading
`Exercises
`
`9 Applications
`
`Problem: Applications Need their Own Protocols
`9.1 Traditional Applications
`9.1.1 Electronic Mail (SMTP, MIME, IMAP)
`
`9.1.2 World Wide Web (HTTP)
`
`9.1.3 Web Services
`
`9.2 Multimedia Applications
`9.2.1 Session Control and Call Control
`(SDP, SIP, H.323)
`
`9.2.2 Resource Allocation for Multimedia
`Applications
`9.3 Infrastructure Services
`
`9.3.1 Name Service (DNS)
`
`9.3.2 Network Management (SNMP)
`
`8
`
`640
`
`643
`
`647
`
`648
`
`653
`
`654
`
`655
`
`656
`
`658
`
`662
`
`664
`
`665
`
`667
`
`670
`
`675
`
`678
`
`681
`
`684
`
`686
`
`688
`
`689
`
`690
`
`697
`
`698
`
`700
`
`708
`
`718
`
`727
`
`728
`
`739
`
`744
`
`745
`
`756
`
`8
`
`

`

`
`
`Contents
`
`xxxi
`
`
`
`9.4 Overlay Networks
`
`9.4.1 Routing Overlays
`9.4.2 Peer-to-Peer Networks
`
`9.4.3 Content Distribution Networks
`
`9.5 Summary
`What’s Next: New Network Architecture
`
`Further Reading
`Exercises
`
`Solutions to Select Exercises
`
`Giossary
`
`Bibliography
`
`Index
`
`759
`
`762
`
`769
`
`783
`
`789
`
`790
`
`791
`
`793
`
`801
`
`815
`
`837
`
`851
`
`
`
`9
`
`

`

`path from the desktop to the recipient’s mailbox.
`
`(1) Connection without preauthentication (OK greeting)
`(2) Preauthenticated connection (PREAUTH greeting)
`(3) Rejected connection (BYE greeting)
`(4) Successful LOGIN or AUTHENTICATE command
`(5) Successful SELECT or EXAMINE command
`(6) CLOSE command, or failed SELECT or EXAMINE command
`(7) LOGOUT command, server shutdown, or connection closed I
`
`‘
`
`Connection established
`
`I S
`
`erver greeting
`
`708
`
`CHAPTER9 Applications
`
`(3)
`
`Not authenticated
`
`l
`
`(7)
`
`
`
`(7)
`
`l Selected
`
`
`
`
`
`
`Both sides close the connection I
`
`I FIGURE 9.2 IMAP state transition diagram.
`
`Finally, note that when the user replies to a message, or sends a new
`‘
`message, the mail reader does not forward the message from the client 10
`the mail server using IMAP, but it instead uses SMTP. This means That the :-
`user's mail server is effectively the first mail gateWay traversed along the.
`
`'-
`.
`
`twe
`9.1.2 World Wide Web (HTTP) ‘\
`The World Wide Web has been so successful and has made the mm 0115 -
`accessible to so many people that sometimes it seems to be Synonym '
`
`10
`
`

`

`
`
`9. 1 Traditional applications
`
`709
`
`
`
`with the Internet. In fact, the design of the system that became the
`Web started around 1989, long after the Internet had become a widely
`deployed system. The original goal of the Web was to find a way to
`organize and retrieve information, drawing on ideas about hypertext—
`interlinked documents—that had been around since at least the 1960s.1
`
`The core idea of hypertext is that one document can link to another doc-
`
`ument, and the protocol (HTTP) and document language (HTML) were
`designed to meet that goal.
`
`One helpful way to think of the Web is as a set of cooperating clients
`and servers, all of whom speak the same language: HTTP. Most people are
`exposed to the Web through a graphical client program or web browser
`like Safari, Chrome, Firefox, or Internet Explorer. Figure 9.3 shows the
`Firefox browser in use, displaying a page of information from Princeton
`
`University.
`
`Clearly, if you want to organize information into a system of linked doc-
`uments or objects,,you need to be able to retrieve one document to get
`started. Hence, any web broWser has a function that allows the user to
`
`obtain an object by opening a URL. Uniform Resource Locators (URLs)
`are so familiar to most of us by now that it’s easy to forget that they haven’t
`been around forever. They provide information that allows objects on the
`Web to be located, and they look like the following:
`
`http://wwwcsprinceton.edu/index.html
`
`If you opened that particular URL, your web browser would open a TCP
`connection to the web server at a machine called www.cs.princeton.edu
`and immediately retrieve and display the file called index.htm|. Most files
`on the Web contain images and text, and many have other objects such as
`audio and Video clips, pieces of code, etc. They also frequently include
`URLs that point to other files that may be located on other machines,
`which is the core of the “hypertext” part of HTTP and HTML. A web
`browser has some way in which you can recognize URLs (often by high—
`lighting or underlining some text) and then you can ask the browser to
`Open them. These embedded URLs are called hypertext links. When you
`ask your web browser to open one of these embedded URLs (e.g., by
`pointing and clicking on it with a mouse), it will open a new connec-
`tion and retrieve and display a new file. This is called following a link.
`It thus becomes very easy to hop from one machine to another around
`
`
`1A short history of the Web provided by the World Wide Web consortium traces its roots
`to a 1945 article describing links between microfiche documents.
`
`11
`
`11
`
`

`

` 71 0
`
`CHAPTER 9 Applications
`
`
`
`fl A ‘
`
`'-" ".— I
`
`-'I' .'-‘:.'..""-".
`
`:' "'
`
`'
`
`'|"="'
`
`--.
`
`'. ".
`
`.55:
`«
`E: .J
`' ' "'
`‘ ' '
`a 5 ~:,:‘.T,..—,.,;w::. ”a '
`a.
`.___
`I‘M“ h'IIIKHl —
`I gifi:mm -
`I'.Iui- luti - le "ml—I
`'
`inn
`hrcnnlu'
`[mar-u '
`IRVI- '
`lun- -
`l'uumnu' mun la...
`
`§ ._' Emu sen-u {null-um -
`f. 1
`__' ——-4_.:.—__
`'
`’—
`'
`_‘
`_
`-
`
`(“3: 14
`
`Department of
`.
`Computer Selence
`
`,
`
`
`
`PRINCETON
`@ umvmm
`
`HEWS
`
`{3;
`
`EVENTS
`
`
`
`
`
`
`
`
`
`
`:r
`gag; .w —
`
`LWémglrfs-fifik
`
`t
`
`
`
`
`”PETA‘fCfiTifll‘J
`*7 Bone
`
`V.
`
`.
`
`_.
`
`,, _. _
`
`
`
`
`
`l FIGURE 9.3 The Firefox web browser.
`
`the network, following links to all sorts of information. Once you ha"? a
`
`means to embed a link in a document and allow a user to follow that llnk
`
`to get another document, you have the basis of a hypertext system
`
`When you ask your browser to View a page, your browser (the client)
`
`fetches the page from the server using HTTP running over TCP. Like SMTP’
`HTTP is a text-oriented protocol. At its core, HTTP is a request/$51301”e
`protocol, where every message has the genera] form
`
`START_LlNE <CRLF>
`
`MESSAGE_HEADER <CRLF>
`
`<CRLF>
`
`MESSAGE_BODY <CRLF>
`
`12
`
`
`
`12
`
`

`

`
`
`9.1 Traditional applications
`
`_71 1
`
`
`
`where, as before, <CRLF> stands for carriage-return+line-feed. The
`
`first line (START-LINE) indicates whether this is a request message or a
`
`response message. In effect, it identifies the “remote procedure" to be
`executed (in the case of a request message), or the status of the request
`(in the case of a response message). The next set of lines specifies a col—
`
`lection of options and parameters that qualify the request or response.
`
`There are zero or more of these MESSAGE_H EADER lines—the set is ter—
`minated by a blank line—~each of which looks like a header line in an email
`
`message. HTTP defines many possible header types, some of which per-
`
`tain to request messages, some to response messages, and some to the
`
`data carried in the message body. Instead of giving the full set of possible
`
`header types, though, we just give a handful of representative examples.
`Finally, after the blank line comes the contents of the requested message
`(M ESSAG E_BODY) ; this part of the message is where a server would place
`
`the requested page when responding to a request, and it is typically empty
`
`for request messages.
`
`Why does HTTP run over TCP? The designers didn’t have to do it
`
`that way, but TCP does provide a pretty good match to what HTTP
`
`needs, particularly by providing reliable delivery (who wants a Web page
`with missing data?), flow control, and congestion control. However, as
`
`we’ll see below, there are a few issues that can arise from building a
`
`request/ response protocol on top of TCP, especially if you ignore the sub—
`tleties of the interactions between the application and transport layer
`protocols.
`
`Request/Viessages
`
`The first line of an HTTP request message specifies three things: the oper-
`ation to be performed, the Web page the operation should be performed
`
`on, and the version of HTTP being used. Although HTTP defines a wide
`
`assortment of possible request operations—including write operations
`that allow a Web page to be posted on a server—the two most common
`
`Operations are GET (fetch the specified Web page) and HEAD (fetch sta-
`
`tus information about the specified Web page). The former is obviously
`used when your browser wants to retrieve and display a Web page. The
`latter is used to test the validity of a hypertext link or to see if a particu—
`lar page has been modified since the browser last fetched it. The full set of
`
`Operations is summarized in Table 9.1. As innocent as it sounds, the POST
`
`Command enables much mischief (including spam) on the Internet.
`
`13
`
`13
`
`

`

`712
`
`CHAPTER 9 Applications
`
`Table 9.1 HTTP Request Operations
`
`Operation
`
`Description
`
`OPTIONS
`
`Request information about available options
`
`GET
`
`HEAD
`
`POST
`
`PUT
`
`Retrieve document identified in URL
`
`Retrieve metainformation about document identified in URL
`
`Give information (e.g., annotation) to server
`
`Store document under specified URL
`
`DELETE
`
`Delete specified URL
`
`TRACE
`
`Loopback request message
`
`
`
`CONNECT For use by proxies
`
`For example, the START-LiNE
`
`GE" http://www.cs.princeton.edu/index.html
`HT"P/l.1
`
`
`
`says that the client wants the server on host www.cs.princeton.edu to
`return the page named index.htm|. This particular example uses an abso-
`lute URL. It is also possible to use a relative identifier and specify the host
`name in one of the MESSAGE_H EADEFi lines; for example,
`
`GET index.html HTTP/1.1
`
`Host: www.cs.princeton.edu
`
`Here, Host is one of the possible MESSAGE_HEADER fields. One Of The
`more interesting of these is lf-Modified-Since, which gives the client a way
`to conditionally request a Web page—the server returns the page only ifit‘
`has been modified since the time specified in that header line.
`
`Response Messages
`response messages begin with a
`Like request messages,
`START_L|NE.
`In this case,
`the line specifies the version 0f
`being used, a three-digit code indicating whether or not the I
`was successful, and a text string giving the reason for the respOHS
`
`eqllest
`e. For
`
`example, the START_LlNE
`
`HTTP/1 1 202 Accepted
`
`14
`
`
`
`14
`
`

`

`
`
`9.1 Traditional applications
`
`713
`
`Table 9.2 Five Types of HTTP Result Codes
`
`Code
`
`Type
`
`Example Reasons
`
`ixx
`
`2xx
`
`3xx
`
`4xx
`
`Informational
`
`request received, continuing process
`
`Success
`
`action successfully received, understood, and accepted
`
`Rednecfion
`
`funheracfionrnustbetakentoconnfietetherequefl
`
`CHentEnor
`
`requestcontflnsbadsyntaxorcannotbequMed
`
`
`
`
`
`SaverEnorSxx sewerkfledtofuMHanappamnflyvaHdrequefl
`
`indicates that the server was able to satisfy the request, while
`
`HTTP/1.1 404 Not Found
`
`indicates that it was not able to satisfy the request because the page was
`not found. There are five general types of response codes, with the first
`digit of the code indicating its type. Table 9.2 summarizes the five types of
`codes.
`
`As with the unexpected consequences of the POST request message, it
`is sometimes surprising how various response messages are used in prac-
`tice. For example, request redirection (specifically code 302) turns out to
`be a powerful mechanism that plays a big role in Content Distribution
`, Networks (CDNs) (see Section 9.4.3) by redirecting requests to a nearby
`cache.
`
`Also similar to request messages, response messages can contain
`one or more MESSAGEHEADER lines. These lines relay additional
`information back to the client. For example, the Location header line
`specifies that
`the requested URL is available at another location.
`Thus, if the Princeton CS Department Web page had moved from http://
`www.cs.princeton.edu/index.html to http://www.princeton.edu/cs/index.htmi,
`for example, then the server at the original address might respond with
`
`HTTP/1.1 301 Moved Permanentiy
`
`Location: http://www.princeton.edu/cs/index.ntmi
`
`the response message will also carry the
`In the common case,
`requested page. This page is an HTML document, but since it may
`Carry nontextual data (e.g., a GIF image), it is encoded using MIME (see
`
`15
`
`
`
`15
`
`

`

` 714
`
`CHAPTER 9 Applications
`
`Section 9.1.1). Certain of the MESSAGEHEADE‘R lines give attributes
`
`of the page contents, including Content—Length (number of bytes in the
`
`contents), Expires (time at which the contents are considered stale),
`and Last-Modified (time at which the contents were last modified at the
`
`server).
`
`Uniform Resource /dentif/er5
`
`The URLs that HTTP uses as addresses are one type of Uniform Resource
`
`Identifier (URI). A URI is a character string that identifies a resource,
`where a resource can be anything that has identity, such as a document,
`
`an image, or a service.
`
`The format of URIs allows various more specialized kinds of resource
`
`identifiers to be incorporated into the URI space of identifiers. The first
`part of a URI is a scheme that names a particular way of identifying a
`certain kind of resource, such as mailto for email addresses or file for file
`names. The second part of a URI, separated from the first part by a colon,
`is the scheme-specific part. It is a resource identifier consistent with the
`
`scheme in the first part, as in the URIs
`
`mailto:santa@northpole.org
`
`and
`
`ti)e:///C:/foo.html
`
`A resource doesn’t have to be retrievable or accessible. We SaW an
`example of this earlier in Section 7.1.3——extensible markup language
`(XML) namespaces are identified by URIs that look an awful lot like URLS’
`but strictly speaking they are not locators because they don’t tell you how
`to locate something; they just provide a globally unique identifier for the
`namespace. There is no requirement that you can retrieve anything at
`the URI given as the target namespace of an XML document. We’ll see
`another example of a URI that is not a URL in Section 9.2.1.
`
`TCP Connections
`_
`The original version of HTTP (1.0) established a separate TCP COTmeCflOn
`for each data item retrieved from the server. It’s not too hard to see how
`this was a very inefficient mechanism: connection setup and teardown
`messages had to be exchanged between the client and server even ifall the
`client wanted to do was verify that it had the most recent copy Of a page»
`
`16
`
` -_-'=.-_.-4-
`
`—..—_-i'-.=-'|.-\n_-..E»A"‘=5"\n'."'—:V:1-"int—Inl—
`
`
`
`
`
`_.__::
`."—_:-,-
`
`16
`
`

`

`
`
`744
`
`CHAPTER 9 Applications
`
`The main thing to notice here is the interleaving of session control and
`
`resource allocation tasks. Solid lines represent SIP messages, dashed lines
`
`represent RSVP messages. Note that SIP messages are transmitted direc—
`
`tion from phone to phone in this example (i.e., we have not shown any SIP
`proxies), whereas the RSVP messages are also processed by the routers in
`the middle as the check for sufficient resources to admit the call.
`
`We being with an initial exchange of codec information in the first two
`SIP messages (recall that SDP is used to list available codecs, among other
`
`things). PRACK is a “provisional acknowledgment.” Once these messages
`have been exchanged, RSVP PATH messages, which contain a description
`
`of the amount of resources that will be required, can be sent as the first
`
`step in reserving resources in both directions of the call. Next, RESV mes-
`sages can be sent back to actually reserve the resources. Once a RESV
`is received by the initiating phone, it can send an updated SDP message
`reporting the fact that resources have been reserved in one direction.
`When the called phone has received both that message and the RESV
`from the other phone, it can start to ring and tell the other phone that
`resources are now reserved in both directions (with the SDP message) and
`
`also notify the calling phone that it is ringing. From here on, normal SIP
`signalling and media flow, similar to that shown in Figure 9.9, proceeds.
`
`Again we see how building applications requires us to understand
`the interaction between different building blocks (SIP and RSVP, in this
`case). The designers of SIP actually made some changes to the protocol
`to enable this interleaving of functions between protocols with different
`jobs, hence our repeated emphasis in this book on focusing on complete
`systems rather than just looking at one layer or component in isolation
`from the other parts of the system.
`
`9.3 INFRASTRUCTURE SERVICES
`
`There are some protocols that are essential to the smooth running Of
`the Internet but that don’t fit neatly into the strictly layered model. One
`of these is the Domain Name System (DNS)—not an application that
`users normally invoke explicitly, but rather a service that almost all other
`applications depend upon. This is because the name service is Used
`to translate host names into host addresses; the existence of suCh an
`application allows the users of other applications to refer to remote hOStS
`
`17
`
`17
`
`

`

`
`
`9.3 Infrastructure services
`
`745
`
`by name rather than by address. In other words, a name service is usually
`used by other applications, rather than by humans.
`
`A second critical function is network management, which although not
`
`so familiar to the average user, is the operation performed most often by
`
`system administrators. Network management is widely considered one of
`the hard problems of networking and continues to be the focus of much
`
`research. We’ll look at some of the issues and approaches to the problem
`below.
`
`9.3 1 Name Service (DNS)
`
`In most of this book, we have been using addresses to identify hosts.
`
`While perfectly suited for processing by routers, addresses are not exactly
`
`user friendly. It is for this reason that a unique name is also typically
`
`assigned to each host in a network. Already in this section we have seen
`
`application protocols like, HTTP using names such as www.princeton.edu.
`
`We now describe how a naming service can be developed to map user-
`
`friendly names into router-friendly addresses. Name services are some-
`
`times called middleware because they fill a gap between applications and
`
`the underlying network.
`
`Host names differ from host addresses in two important ways. First,
`
`they are usually of variable length and mnemonic,
`
`thereby making
`
`them easier for humans to remember. (In contrast, fixed-length numeric
`
`addresses are easier for routers to process.) Second, names typically con-
`
`tain no information that helps the network locate (route packets toward)
`
`the host. Addresses, in contrast, sometimes have routing information
`
`embedded in them; flat addresses (those not divisible into component
`
`parts) are the exception.
`
`Before getting into the details of how hosts are named in a network,
`
`we first introduce some basic terminology. First, a name space defines
`
`the set of possible names. A name space can be either flat (names are
`
`not divisible into components) or hierarchical (Unix file names are an
`
`obvious example). Second, the naming system maintains a collection of
`
`bindings of names to values. The value can be anything we want the nam—
`
`ing system to return when presented with a name; in many cases, it is
`
`an address. Finally, a resolution mechanism is a procedure that, when
`
`invoked with a name, returns the corresponding value. A name server is
`
`
`
`18
`
`

`

`746
`
`CHAPTER9 Applications
`
`a specific implementation of a resolution mechanism that is available on
`a network and that can be queried by sending it a message.
`Because of its large size, the Internet has a particularly well-developed
`naming system in place—the Domain Name System (DNS). We therefore
`use DNS as a framework for discussing the problem of naming hosts. Note
`
`that the Internet did not always use DNS. Early in its history, when there
`
`were only a few hundred hosts on the Internet, a central authority called
`
`the Network Information Center (NIC) maintained a flat table of name-t0-
`
`address bindings; this table was called hosts.txt. Whenever a site wanted
`to add a new host to the Internet, the site administrator sent email to
`
`the NIC giving the new host’s name/ address pair. This information was
`
`manually entered into the table, the modified table was mailed out to the
`
`various sites every few days, and the system administrator at each site
`
`installed the table on every host at the site. Name resolution was then sim-
`ply implemented by a procedure that looked up a host’s name in the local
`
`copy of the table and returned the corresponding address.
`
`It should come as no surprise that the hostsixt approach to naming
`
`did not work well as the number of hosts in the Internet started to grow.
`
`Therefore, in the mid—19805, the Domain Naming System was put into
`place. DNS employs a hierarchical namespace rather than a flat name
`space, and the “table” of bindings that implements this name space iS
`partitioned into disjoint pieces and distributed throughout the Internet.
`These subtables are made available in name servers that can be queried
`
`over the network.
`
`What happens in the Internet is that a user presents a host name to an
`application program (possibly embedded in a Compound name such as
`an email address or URL), and this program engages the naming SYStem
`to translate this name into a host address. The application then opens a
`connection to this host by presenting some transport protocol (e.g., TCP)
`with the host’s IP address. This situation is illustrated (in the case of send—
`ing email) in Figure 9.14. While this picture makes the name resolu’EiOI1
`task look simple enough, there is a bit more to it, as we shall see.
`
`'
`Domain Hierarchy
`DNS implements a hierarchical name space for Internet objects. Ulfllke
`Unix file names, which are processed from left to right with the naming
`components separated with slashes, DNS names are processed from Tight
`to left and use periods as the separator. (Although they are processed from
`1 9
`
`I .-
`..
`I
`‘
`
`fl
`2.1;? .
`I
`I
`
`
`
`19
`
`

`

`
`
`9.3 Infrastructure services
`
`747
`
`User
`
`1
`
`5:3;
`
`cs2princetonedu
`
`19212595
`
`'
`
`_
`
`.
`
`1
`
`luser@cs.princeton.edu
`Mail_I
`l.19212..695
`
`4
`
`up_rogram
`
`TOP
`_ _
`
`_
`
`192.12.69.5
`
`5
`
`
`
`IP
`
`
`
`1 FIGURE 9.14 Names translated into addresses, where the numbers 1 to 5 show the sequence ofsteps in the process.
`
`0
`_.
`
`ped
`re
`
`Die
`er
`
`9
`led
`
`t0_
`
`:ed
`to
`
`7&8
`
`he
`ite
`n-
`
`2a] m
`:
`edu
`com
`gov
`mil
`org
`net
`uk
`fr
`3
`/K /\ /\ /\ /\ A A A
`N’
`princeton
`mit
`cisco~ -yahoo nasa -nsf
`arpan -navy acm- nieee
`:0
`re A A A A A A A A A A
`.
`is
`/S\
`t.
`
`ee
`physics
`A A
`
`ux01-- ux04
`
`1
`
`d 1
`
`s 1 1
`
`
`
`- FIGURE9JS Exampleofadomain hierarchy.
`
`right to left, humans still read domain names from left to right.) An exam-
`
`ple domain name for a host is cicada.cs.princeton.edu. Notice that we said
`
`domain names are used to name Internet “objects.” What we mean by this
`
`is that DNS is not strictly used to map host names into host addresses. It
`
`is more accurate to say that DNS maps domain names into values. For the
`
`'
`
`time being, we assume that these values are IP addresses; we will come
`back to this issue later in this section.
`
`Like the Unix file hierarchy, the DNS hierarchy can be Visualized as
`
`a tree, where each node in the tree corresponds to a domain, and the
`
`71‘
`
`I
`
`leaves in the tree correspond to the hosts being named. Figure 9.15 gives
`an example of a domain hierarchy. Note that we should not assign any
`
`
`
`20
`
`

`

`fl
`
`7423
`
`CHAPTER9 Applications
`
`semantics to the term domain other than that it is simply a context in
`which additional names can be defined.5
`
`There was actually a substantial amount of discussion that took place
`when the domain name hierarchy was first being developed as to what
`
`conventions would govern the names th