Chapter 7 Application Layer 1 Some of the slides in this chapter are courtesy of Profs. Kurose/Ross and others.

Chapter 7: Application Layer Objectives:  to understand conceptual and implementation aspects of network application protocols  transport-layer service models  client-server model  learn about protocols by examining popular application-level protocols  HTTP (quickly) 2

Some network apps   web  instant messaging  remote login  P2P file sharing  multi-user network games  streaming stored video (YouTube)  voice over IP  real-time video conferencing  cloud computing  …  3

Creating a network app write programs that  run on (different) end systems  communicate over network  e.g., web server software communicates with browser software No need to write software for network-core devices  network-core devices do not run user applications  applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical 4

Chapter 7: Application Layer 7.1 Principles of network applications 7.2 Web and HTTP 7.3 Synthesis: a day in the life of a web request 5

Client-server architecture server:  always-on host  permanent IP address  server farms for scaling clients:  communicate with server  may be intermittently connected  may have dynamic IP addresses  do not communicate directly with each other client/server 6

Processes communicating process: program running within a host.  within same host, two processes communicate using inter-process communication (defined by OS).  processes in different hosts communicate by exchanging messages client process: process that initiates communication server process: process that waits to be contacted 7

Sockets  process sends/receives messages to/from its socket = API (app. programming interface)  socket analogous to door  sending process shoves message out door  sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Internet controlled by OS controlled by app developer  API: (1) choice of transport protocol; (2) ability to fix a few parameters 8

Addressing processes  to receive messages, process must have identifier  host device has unique 32-bit IP address  Q: does IP address of host on which process runs suffice for identifying the process?  A: No, many processes can be running on same host  identifier includes both IP address and port number associated with process on host.  example port numbers:  HTTP server: 80  Mail server: 25  to send HTTP message to web server:  IP address:  Port number: 80 9

10 Typical Client Program  Prepare to communicate  Create a socket  Determine server address and port numbers  Initiate the connection to the server  Exchange data with the server  Write data to the socket  Read data from the socket  Do stuff with the data (e.g., render a Web page)  Close the socket

11 Servers Differ From Clients: example for TCP  Passive open  Prepare to accept requests  … but don’t actually establish  … until hearing from a client  Hearing from multiple clients  Allowing a backlog of waiting clients ... in case several try to communicate at once  Create a socket for each client  Upon accepting a new client  … create a new socket for the communication

What transport service does an app need? Data loss  some apps (e.g., audio) can tolerate some loss  other apps (e.g., file transfer) require 100% reliable data transfer Timing  some apps (e.g., Internet telephony, interactive games) require low delay to be “effective” Throughput  some apps (e.g., multimedia) require minimum amount of throughput to be “effective”  other apps (“elastic apps”) make use of whatever throughput they get Security  encryption, data integrity, … 12

Internet transport protocols services TCP service:  connection-oriented: setup required between client and server processes  reliable transport between sending and receiving process  flow control: sender won’t overwhelm receiver  congestion control: throttle sender when network overloaded  does not provide: timing, minimum throughput guarantees, security UDP service:  unreliable data transfer between sending and receiving process  does not provide: connection setup, reliability, flow control, congestion control, timing, throughput guarantee, or security 13

App-layer protocol defines  types of messages exchanged between processes,  e.g., request, response  message syntax:  what fields in messages & how fields are delineated  message semantics  meaning of information in fields  rules for when and how processes send & respond to messages public-domain protocols:  defined in RFCs  allows for interoperability  e.g., HTTP proprietary protocols:  e.g., Skype 14

Chapter 7: Application Layer Principles of network applications 7.2 Web and HTTP 7.3 Synthesis: a day in the life of a web request

The Web  Is a client-server application  Consists of many components:  A standard for document format: HTML  Web browsers: e.g. Firefox  Web servers: Microsoft  An application layer protocol; HTTP defined in RFC 1945 and RFC

Web and HTTP First,  web page consists of objects  object can be HTML file, JPEG image, Java applet, audio file,…  web page consists of base HTML-file which includes several referenced objects  each object is addressable by a URL  example URL: host name path name 17

HTTP overview HTTP: hypertext transfer protocol  Web’s application layer protocol  client/server model  client: browser that requests, receives, “displays” Web objects  server: Web server sends objects in response to requests PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response 18

HTTP overview (continued) Uses TCP:  client initiates TCP connection (creates socket) to server, port 80  server accepts TCP connection from client  HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)  TCP connection closed HTTP is “stateless”  server maintains no information about past client requests 19

HTTP connections non-persistent HTTP  at most one object sent over TCP connection. 20

Chapter 7: Application Layer Principles of network applications 7.2 Web and HTTP 7.3 Synthesis: a day in the life of a web request

Synthesis: a day in the life of a web request   journey down protocol stack complete!   application, transport, network, link   putting-it-all-together: synthesis!   goal: identify, review, understand protocols (at all layers) involved in seemingly simple scenario: requesting www page   scenario: Bob attaches laptop to campus network, requests/receives 22

A day in the life: scenario Comcast network /13 Google’s network / web server DNS server school network /24 browser web page

A day in the life… connecting to the Internet  connecting laptop needs to get its own IP address, addr of first-hop router, addr of DNS server: use DHCP router (runs DHCP) DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP  DHCP request encapsulated in UDP, encapsulated in IP, encapsulated in Ethernet  Ethernet frame broadcast (dest: FFFFFFFFFFFF ) on LAN, received at router running DHCP server

A day in the life… connecting to the Internet  DHCP server formulates DHCP ACK containing client’s IP address, IP address of first-hop router for client, name & IP address of DNS server router (runs DHCP) DHCP UDP IP Eth Phy DHCP UDP IP Eth Phy DHCP  encapsulation at DHCP server, frame forwarded (switch learning) through LAN, demultiplexing at client Client now has IP address, knows name & addr of DNS server, IP address of its first-hop router  DHCP client receives DHCP ACK reply

A day in the life… ARP (before DNS, before HTTP)  before sending HTTP request, need IP address of DNS DNS UDP IP Eth Phy DNS  DNS query created, encapsulated in UDP, encapsulated in IP, encapsulated in Eth. In order to send frame to router, need MAC address of router interface: ARP  ARP query broadcast, received by router, which replies with ARP reply giving MAC address of router interface  client now knows MAC address of first hop router, so can now send frame containing DNS query ARP query Eth Phy ARP ARP reply

A day in the life… using DNS DNS UDP IP Eth Phy DNS  IP datagram containing DNS query forwarded via LAN switch from client to 1 st hop router  IP datagram forwarded from campus network into comcast network, routed (tables created by RIP, OSPF, and/or BGP routing protocols) to DNS server  demuxed to DNS server  DNS server replies to client with IP address of Comcast network /13 DNS server DNS UDP IP Eth Phy DNS

A day in the life… TCP connection carrying HTTP HTTP TCP IP Eth Phy HTTP  to send HTTP request, client first opens TCP socket to web server  TCP SYN segment (step 1 in 3-way handshake) inter- domain routed to web server  TCP connection established! web server SYN TCP IP Eth Phy SYN SYNACK  web server responds with TCP SYNACK  The client responds with ACK segment

A day in the life… HTTP request/reply HTTP TCP IP Eth Phy HTTP  HTTP request sent into TCP socket  IP datagram containing HTTP request routed to  IP datagram containing HTTP reply routed back to client web server HTTP TCP IP Eth Phy  web server responds with HTTP reply (containing web page) HTTP  web page finally (!!!) displayed

Summary We have learnt the Principles of network applications We have studied the Web and HTTP with an example “a day in the life of a web request” 2: Application Layer30