[Ch2 Application Layer] Principles of Network Applications, Web and HTTP

Network Apps

Loss-sensitive application (= data integrity = reliable)

• email, web, text messaging, remote login, P2P file sharing

Delay-sensitive application

• multi-user network games, voice over IP (e.g. Skype)

Bandwidth-sensitive application

• streaming stored video (YouTube, Netflix), real-time video conferencing

Creating a network app

• no need to write software for network-core devices -> network-core devices don't run user applications
• Applications run on end systems

 

Application Architectures

Client-server

• HTTPS, SMTP, DNS

Server

• always-on host
• parmanent IP address
• data centers for scaling

Client

• communicate with server (don't communicate directly with each other)
• may be intermittently connected
• may have dynamic IP address

 

Peer-to-peer (P2P)

• BitTorrent (file sharing), Skype, IPTV

No always-on server

• arbitrary end systems directly communicate
• peers request service from other peers & provide service in return to other peers
  • self scalability: new peers bring new service capacity as well as demands
• peers are intermittently connected and change IP address

 

Process

Process: program running within a host

• within same host, two processes communicate using inter-process communication (defined by OS)
• in different hosts communicate by exchanging messages (protocol)

Client - Server

• child process: process that initiates communication
• server process: process that waits to be contacted

P2P

• both child process & server processes are in the same host

 

Sockets

Process sends/receives messages to/from its socket

• socket := door btw Application Layer (L5) and Transport Layer (L4)
• TCP는 일대일로 하나의 socket을 이용 / UDP는 여러 process가 하나의 socket을 공유

 

Addressing processes

To receive msg, process must have identifier

• identifier = IP address + port numbers
• host device has unique 32-bit IP address (at NIC)
• many processes can be running on same host -> reason why port # needs. (ex. HTTP: 80, mail server: 25)

 

What App-layer protocol defines

• types of messages exchanged (e.g. request, response)
• message syntax
• message semantics
• rules for when and how process send & respond to msg
• open protocols: defined in RFCs (e.g. HTTP, SMTP)
• proprietary protocols (e.g. Skype)

 

Transport Protocols

Transport Service Requirements

Data Integrity (Loss)- TCP

• some apps (file transfer (FTP), web transactions, email, txt messaging ..) require reliable data transfer
• other apps (e.g. audio, video) can tolerate some loss

Timing (delay)

• some apps (real-time audio/video, stored audio/video, interactive games) require low delay

Throughput

• some apps (multimedia, real-time audio/video, stored audio/video, interactive games) require minimum amount of throughput
• 단위 시간 당 일정양의 데이터가 전송되어야 함
• 'elastic aps' (email, text messaging..) make use of whatever throughput they get

Security

• for encryption

 

TCP Service

• reliable transport (no loss, in-order, loss-sensitive)
• connection-oriented: setup required btw client and server process
• flow control: sender won't overwhelm receiver (at receiving TCP buffer)
• congestion control: throttle sender when network overloaded (at sending TCP buffer)

 

UDP Service

• unreliable transport: only mux/demux & checksum (아무 기능이 없음)
• doesn't provide: connection setup, reliability, flow control, congestion control
• good for real-time streaming service, one-time transaction, smart application

TCP, UDP both don't provide: timing, minumum throughput guarantee, security

---

Web and HTTP

Web

• Web page consists of objects
• Web page consists of base HTML-file which includes several referenced objects
• each object is addressable by a URL (host name + path name)

 

HTTP Overview

HTTP: hypertext transfer protocol

 

Client-server model

• server: Web server sends objects in response to request
• client: Browser that requests, receives, displays Web objects
• Client and a server communicate with each other by exchanging HTTP msg

 

HTTP Operation

uses TCP: 하나의 TCP가 send / receive buffer를 모두 가지고 있음

1. TCP Connection set-up
   • server waits on port 80
   • client initiates TCP connection (creates socket) to server, port 80
   • server accepts TCP connection from client
2. HTTP messages exchange
   • App-layer protocol messages exchanged btw browser(HTTP client) and Web server(HTTP server)
3. TCP connection closed

HTTP is "stateless"

• server maintains no information about past client requests
• each request message can be understood in isolation
• for dynamically load balance requests accross multiple servers: 서버 부하 & client가 느끼는 response time ⬇️

protocols that maintain "state" are complex -> 서버 부하 ⬆️, 복구 어렵

 

HTTP Connections

HTTP Response Time (RTT)

RTT (round trip time)

• time for a small pck to travel from client to server & back to the client including 4 delays

Non-persistent HTTP (1.0)

• at most one object sent over TCP connection then closed
• downloading multiple objects requires multiple TCP connections
• requires 2 RTTs per objects (ignoring transmission time)
  • 1 RTT for initiating TCP connection
  • 1 RTT for HTTP request and first few bytes of HTTP resposne to return
  • file transmission time
• OS overhead for each TCP connection -> multiple TCP connections may be needed per one browser process
• using parallel TCP connections to fetch referenced objects

Persistent HTTP (1.1)

• multiple objects can be sent over single TCP connection btw client and server
• requires 3 RTTs for retrieving n objects (initiating + base file + object)
  • server leaves connection open after sending response
  • subsequent HTTP msg btw same client/server sent over open connection
  • client sends requests as soon as it encounters a referenced object
  • 1 RTT for all the referenced objects
• HTTP Pipelining: HTTP가 persistent TCP connection을 사용하여 request msg를 보내고 그에 대한 response msg를 받기 전에 다음 request를 연속으로 보내는 것 (TCP가 in-order 능력을 지원해주기 때문)

 

HTTP Request Message

Request Message

request line (GET, POST, HEAD Commands) + header lines (persistent HTTP인 경우 Keep-Alive 포함) + body

 

Response Message

status line (protocol status code) + header lines (Last-Modified: data가 마지막으로 업데이트된 시간) + data

• status codes
  • 200 OK / 301 Moved Permanently / 304 Not Modified / 400 Bad Request / 404 Not Found / 505 HTTP Version Not Supported

 

Cookies

Cookies: User-server state

• for stateful support
• component
  1. cookie header line of HTTP response msg (by server)
  2. cookie header line in next HTTP request msg (by client)
  3. cookie file kept on user's host, managed by user's browser
  4. back-end database at Web site
• example
  • when initial HTTP requests arrives at site, site creates: unique ID (allocated by server, used by client at the same PC) & entry in backend database for ID

What cookies can be used for:

• authorization, user session state, shopping carts, recommendations ..

How to keep "state":

• protocol endpoints: maintain state at sender / receiver over multiple transactions
• cookies: http messages carry state

Cookies and Privacy

• Cookies permit sites to learn a lot about you (ex. name, e-mail..)

 

Web Caches (Proxy server)

Web Caches

• for satisfying client request by proxy in LAN without involving origin server in Internet
• browser sends all HTTP requests to cache
  • if object in cache (HIT): cache returns object
  • else (MISS): cache requests object from origin server, then returns object to client
• cache acts as both client and server
  • server for original requesting client / client to origin server
• typically public cache is installed by access ISPs

Benefits of Web caching

• reduce response time
• reduce traffic on institution's access link (when cache hit)

Concerns of Web caching

• Cache inconsistency

Access link utilization = (Data rate to browsers over access link) / (Access Link Transmission Rate) = TI

-> 너무 높은 문제! 느려짐

• Solution 1) fatter access link -> increased access link speed but expensive
• Solution 2) install local cache -> cheaper & faster than increasing access link

 

Conditional GET

• Server does not send object if cache has up-to-date cached version
  • no object transmission delay & loser link utilization -> response time ⬇️
• cache: specify date of cached copy in HTTP request
  • If-modified-since: <date>
• server: response contains no object if cached copy is up-to-date
  • 304 Not Modified