Download Chapter 04 Modern Applications

Computer Networks with
Internet Technology
William Stallings
Chapter 04
Modern Applications
Hypertext Transfer Protocol
HTTP
• Underlying protocol of the World Wide Web
• Not a protocol for transferring hypertext
—For transmitting information with efficiency necessary
for hypertext jumps
• Can transfer plain text, hypertext, audio,
images, and Internet accessible information
HTTP Overview
• Transaction oriented client/server protocol
• Usually between Web browser (clinet) and Web
server
• Uses TCP connections
• Stateless
—Each transaction treated independently
—Each new TCP connection for each transaction
—Terminate connection when transaction complete
Key Terms
•
•
•
•
•
•
•
•
•
•
•
•
Cache
Client
Connection
Entity
Gateway
Message
Origin server
Proxy
Resource
Server
Tunnel
User agent
Figure 4.1
Examples of HTTP Operation
Figure 4.2
Intermediate HTTP Systems
HTTP Messages
• Requests
— Client to server
• Responses
— Server to client
•
•
•
•
•
•
•
Request line
Response line
General header
Request header
Response header
Entity header
Entity body
Figure 4.3
HTTP Message Structure
General Header Fields
•
•
•
•
•
•
•
•
Cache control
Connection
Data
Forwarded
Keep alive
MIME version
Pragma
Upgrade
Request Methods
• Request-Line = Method <SP> Request_URL <SP> HTTP-Version
<CRLF>
• Methods:
—
—
—
—
—
—
—
—
—
—
—
—
—
—
Options
Get
Head
Post
Put
Patch
Copy
Move
Delete
Link
Unlink
Trace
Wrapped
Extension-method
Request Header Field
•
•
•
•
•
•
•
•
•
•
•
•
•
Accept
Accept charset
Accept encoding
Accept language
Authorization
From
Host
If modified since
Proxy authentication
Range
Referrer
Unless
User agent
Response Messages
• Status line followed by one or more general,
response and entity headers, followed by
optional entity body
• Status-Line = HTTP-Version <SP> Status-Code
<SP> Reason-Phrase <CRLF>
Status Codes
•
•
•
•
•
Informational
Successful
Redirection
Client error
Server error
Response Header Fields
•
•
•
•
•
•
Location
Proxy authentication
Public
Retry after
Server
WWW-Authenticate
Entity Header Fields
•
•
•
•
•
•
•
•
•
Allow
Content encoding
Content language
Content length
Content MD5
Content range
Content type
Content version
Derived from
•
•
•
•
•
•
•
Expires
Last modified
Link
Title
Transfer encoding
URL header
Extension header
Entity Body
• Arbitrary sequence of octets
• HTTP transfers any type of data including:
—text
—binary data
—audio
—images
—video
• Interpretation of data determined by header
fields
—Content encoding, content type, transfer encoding
Internet Directory Services
DNS
• Directory lookup service
• Provides mapping between host name and numerical
address
• Essential to functioning of Internet
• RFCs 1034 and 1035.
• Four elements
— Domain name space
• Tree-structured
— DNS database
• Each node and leaf in name space tree structure names set of
information (e.g., IP address, type of resource) in resource record
— Name servers
• Servers that hold information about portion of tree
— Resolvers
• Programs that extract information from name servers
Domain Names
• 32-bit IP address uniquely identifies devices
• Two components
— Network number
— Host address
• Problems
— Routers devise routes based on network number
— Can’t hold table of every network and path
— Networks group to simplify routing
— 32-bit address usually written as four decimal numbers
— Effective for computer processing
— Not convenient for users
• Problems are addressed by concept of domain
— Group of networks are under control of single entity
— Organized hierarchically
— Names assigned reflect organization
Domain Name Example
•
•
•
•
edu is college-level U.S. educational institutions
mit.edu is M.I.T.
lcs.mit.edu is Laboratory for Computer Science at M.I.T.
Eventually get to leaf nodes
— Identify specific hosts
— Hosts assigned Internet (IP) addresses
— Internet-wide organization assigns domain names
• Delegated down the hierarchy
• mit.edu, has four IP addresses: 18.7.21.77, 18.7.21.69,
18.7.21.70, and 18.7.21.110
• Subordinate domain lcs.mit.edu has IP address
18.26.0.36
Figure 4.4
Portion of Internet Domain Tree
DNS Database
• Variable-depth unlimited levels hierarchy for
names
—Delimited by period (.)
• Distributed database
• Distribution controlled by database
—Thousands of separately managed zones
• DNS servers provide name-to-address directory
service for network applications
Resource Record
• Domain name
— Human readable form
— Series of labels of alphanumeric characters or hyphens
— Each pair separated by period
• Type
— E.g. A = Host address, MX = Mail exchange
• Class
— Usually IN, for Internet
• Time to live
— How long to hold result in local cache
— Zero means don’t cache
• Rdata field length
• Rdata
— Description of resource
— For A type, Rdata is 32-bit IP address
Figure 4.5
DNS Resource Record Format
DNS Operation
• User program requests IP address for domain name
• Resolver module in local host or local ISP formulates
query for local name server
— In same domain as resolver
• Local name server checks for name in local database or
cache
— If so, returns IP address to requestor
— Otherwise, query other available name servers
• Starting down from root of DNS tree or as high up as possible
• Local name server caches reply
— Depending on Time to live field
• User program given IP address or error message
• DNS name servers automatically send out updates to
other relevant name servers as conditions warrant
Figure 4.6
DNS Name Resolution
Server Hierarchy
• Name servers operated by any organization that has
domain
• Each name server holds subset of name space (a zone)
— One or more (or all) subdomains within domain
— Authoritative
• This name server maintains accurate data for this portion hierarchy
• Can extend to any depth
• 13 root name servers share responsibility for top level
zones
— Replication prevents root server bottleneck
• Individual root servers are busy
• Internet Software Consortium server (F) answers almost 300
million DNS requests daily (www.isc.org/services/public/F-rootserver.html)
• Typically, single queries carried over UDP
• Queries for group of names carried over TCP
Name Resolution
• Resolver knows name and address of local DNS server
• If resolver does not have name in cache, it sends DNS
query to local server
• Either returns address or after querying one or more
other servers
• Server (A) forwards request to server (B)
— If B has name in cache or database, it can return result
— If not, B can
— Query another name server and send result back to A
• Recursive
— Tell A address of next server (C) to ask
• A then asks to C
• Iterative
• Server exchanges use can either
• Name resolvers use recursive
Figure 4.7
DNS Message Format
DNS Message Fields - Header
• Header always present
— Identifier to match queries and responses.
— Query Response: is message query or response
— Opcode: Standard, inverse query (address to name), or server
status request
— Authoritative Answer
— Truncated: was response truncated
• Requestor will use TCP to resend query
— Recursion Desired
— Recursion Available
— Response Code: e.g. no error, format error, refused
— QDcount: entries in question section (zero or more)
— ANcount: RRs in answer section (zero or more)
— NScount: RRs in authority section (zero or more)
— ARcount: RRs in additional records section (zero or more)
DNS Message Fields –
Question and Answer
• If present, question typically contains only one entry
• Domain Name
— Sequence of labels
• Length octet followed by that number of octets
• Terminates with the zero length octet for null label of root
• Query Type
— Values include all values valid for Type field in RR format plus
general codes that match more than one type of RR
• Query Class: typically Internet.
• Answer section contains RRs that answer question
— Authority section contains RRs that point toward an
authoritative name server
— Additional records section contains RRs that relate to query but
not strictly answers
Session Initiation Protocol
Overview
• RFC 3261
• Application-level control protocol
— Setting up, modifying, and terminating real-time sessions
— Enable Internet telephony,(voice over IP, VoIP
— Supports single or multimedia session, including
teleconferencing
• Facets of SIP
— User location: Users can access application features from
remote locations
— User availability: Willingness of called party to communicate
— User capabilities: Media and parameters to be used
— Session setup: Point-to-point and multiparty calls
— Session management: Transfer and termination, modifying
session parameters, and invoking services
Session Initiation Protocol
Features
• Based on HTTP-like request/response transaction model
• Client request invokes function on server
— At least one response
• Uses most HTTP header fields, encoding rules, and
status codes
— Readable format for displaying information
• Uses concepts similar to recursive and iterative searches
of DNS
• Incorporates Session Description Protocol (SDP)
— Defines session content using types similar to MIME
Components and Protocols (1)
• Client
— Sends requests and receives responses
— User agent clients and proxies are clients
• Server
— Receives requests and sends back responses
— Proxies, user agent servers, redirect servers, and registrars
• User Agent
— In every SIP end station
• User agent client (UAC): Issues requests
• User agent server (UAS): Receives requests and reponds
• Redirect Server
— Determines address of called device
— Like iterative searches in DNS
Components and Protocols (2)
• Proxy Server
— Server and client
— Makes requests for other clients
• Routing
• Enforcing policy
• Like recursive searches in DNS
• Registrar
— Server that accepts REGISTER requests
— Places information it receives in requests inlocation service for
domain
• SIP address, associated IP address of device
• Location Service
— Used by redirect or proxy server to obtain information about a
callee's possible location(s)
— Maintains database of SIP-address/IP-address mappings
Components and Protocols (3)
• Servers defined (RFC 3261) as logical devices
• Implemented as separate servers or combined into
single application
• Proxy servers may act as redirect servers
— Need to consult location service database
• May be on proxy server or not
• Communication between proxy server and location service beyond
scope of SIP standard
• Proxy consults DNS server to find target domain proxy
• SIP typically runs on UDP for performance
— Own reliability mechanisms
— May also use TCP
— May use Transport Layer Security (TLS) protocol for secure
connection
Session Description Protocol
SDP
• RFC 2327
• SIP invites participants to session
• SDP-encoded body of SIP message contains
information about what media encodings (e.g.,
voice, video) parties can and will use
• Then data transmission begins, using
appropriate transport protocol
—Real-Time Transport Protocol (RTP)
• Participants can make changes to session
parameters using SIP
Figure 4.8
SIP Components and Protocols
Uniform Resource Identifier URI
• Identifies SIP resource
— User of online service
— Appearance on multiline phone
— Mailbox on messaging system
— Telephone number at gateway service
— Group (such as "sales" or "helpdesk") in an organization
• Format based on email address formats
— user@domain
— sip:[email protected]
• May also include password, port number, and related
parameters
• If secure transmission required, use "sips:“
— SIP messages are transported over TLS
• URI is generic identifier for resource on Internet
— URL, for Web addresses is type of URI
Figure 4.9 SIP
Call Setup Attempt Scenario
Figure 4.10
SIP Presence Example
Figure 4.11 SIP Registration
and Notification Example
Figure 4.12
SIP Successful Call Setup
SIP Messages
• Requests and responses
• Difference between types in first line
• Request
— Method: nature of request
— Request-URI: where request should be sent
• Response has response code
• All messages include header
— Number of lines
• Beginning with header label
• Message can also contain body e.g. SDP media
description
SIP Messages - Requests
• Methods
—REGISTER: notify SIP network of IP address and
URLs for which it would like to receive calls
—INVITE: establish session between user agents
—ACK: Confirms reliable message exchanges
—CANCEL: Terminates pending request, but does not
undo completed call
—BYE: Terminates session between two users in
conference
—OPTIONS: Solicits information about callee
capabilities
SIP Message Request Example
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice
<sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
SIP Messages - Response
• Provisional (1xx): Request received and being processed
• Success (2xx): Action successfully received, understood,
and accepted
• Redirection (3xx): Further action needed
• Client Error (4xx): Request contains bad syntax or
cannot be fulfilled at this server
• Server Error (5xx): Server failed to fulfill apparently valid
request
• Global Failure (6xx): Request cannot be fulfilled at any
server
SIP Response Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: Bob <sip:[email protected]>;tag=a6c85cf
From: Alice
<sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
SDP Information
• Media streams
— Session can include multiple streams of differing content
— Currently defines audio, video, data, control, and application
• Addresses
— Destination addresses,
— May be multicast
• Ports
— For each stream
• Payload types
— For each media stream type
• Start and stop times
— For broadcast sessions e.g. television or radio program
• Originator
— For broadcast sessions
Sockets
• 1980s UNIX Berkeley Sockets Interface
• Socket enables communications between client and
server process
• Connection-oriented or connectionless
• Endpoint in communication
• Client socket in one computer uses address to call server
socket on another computer
• Once appropriate sockets engaged, can exchange data
• Server sockets keep TCP or UDP port open
• Once connected server switches dialogue to different
port
Sockets API (1)
• Sockets can be constructed from within program in most
languages
• Berkeley Sockets Interface is de facto standard API
— Windows Sockets (WinSock) based on Berkeley
• TCP and UDP header includes source port and
destination port fields
— Identify respective users (applications)
• IPv4 and IPv6 header includes source address and
destination address fields
— Identify host systems
• Port value with IP address forms socket
— Unique throughout Internet
• When used as API, socket is identified by triple
— Protocol, local-address (IP), local-process (port)
Sockets API
• Sockets API recognizes three types of sockets
—Stream sockets for TCP, connection-oriented reliable
—Datagram sockets for UDP, connectionless
—Raw sockets
• Direct access to lower layer protocols, e.g. IP and ICMP
Socket Interface Calls
•
•
•
•
Gethostname
Gethostbyname
Setup
Connect
—Client
• Listen/accept
—Server
• Send
• Receive
• Close
Figure 4.13 Socket System Calls for
Connection-Oriented Protocol
Required Reading
•
•
•
•
•
Stallings chapter 4
RFCs
WWW Consortium
Loads of books and web sites on sockets
E.g. Comer, D.E. and Stevens, D.L.
Internetworking with TCP/IP Volume III,
Prentice Hall
—Comes in three versions:
• Windows Sockets
• BSD Sockets
• AT&T TLI (not sockets)