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

Table 4.1 Key Terms Related to HTTP

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

Table 4.2 Augmented BNF Notation Used in URL and HTTP Specification

General Header Fields Cache control Connection Data Forwarded Keep alive MIME version Pragma Upgrade

Table 4.3 HTTP Elements

Request Methods Request-Line = Method Request_URL HTTP-Version 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 Status-Code Reason-Phrase

Status Codes Informational Successful Redirection Client error Server error

Table 4.4 HTTP Status Codes (1/2)

Table 4.4 HTTP Status Codes (2/2)

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 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: , , , and Subordinate domain lcs.mit.edu has IP address

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

Table 4.5 Top-Level Internet Domains

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

Table 4.6 Resource Record Types

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 ( server.html) Typically, single queries carried over UDP Queries for group of names carried over TCP

Table 4.7 Internet Root Servers

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 address formats 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

Table 4.8 SIP Header Fields

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/2.0 Via: SIP/2.0/UDP :5060 Max-Forwards: 70 To: Bob From: Alice ;tag= Call-ID: CSeq: INVITE Contact: 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/ OK Via: SIP/2.0/UDP server10.biloxi.com Via: SIP/2.0/UDP bigbox3.site3.atlanta.com Via: SIP/2.0/UDP :5060 To: Bob ;tag=a6c85cf From: Alice ;tag= Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 131

Table 4.9 SIP Response Codes

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

Table 4.10 Socket Functions (1/2)

Table 4.10 Socket Functions (2/2)

Socket Interface Calls Gethostname Gethostbyname Setup Connect —Client Listen/accept —Server Send Receive Close

Figure 4.13 Socket System Calls for Connection-Oriented Protocol

Examples (1/6)

Examples (2/6)

Examples (3/6)

Examples (4/6)

Examples (5/6)

Examples (6/6)

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)