Application Layer II Flashcards
(14 cards)
Web and HTTP
A web page consists of a base HTML-file which may include several referenced objects
An object can be HTML file, a JPEG image, a Java applet, an audio file,…
each object is addressable by a URL, e.g.,
HTTP overview
Underlying protocol: 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 connections
non-persistent HTTP
* at most one object sent
over TCP connection
* connection then closed
* downloading multiple
objects requires multiple
connections
persistent HTTP
* multiple objects can be
sent over single TCP
connection between client,
server
Non-persistent HTTP: response time
RTT: time for a packet to travel from client
to server and back
- HTTP response time:
- one RTT to initiate TCP connection
- one RTT for HTTP request and first few
bytes of HTTP response to return - This assumes HTTP GET piggy backed on the
ACK
non-persistent HTTP issues:
* requires 2 RTTs per object
* OS overhead for each TCP connection
* browsers often open parallel TCP connections to fetch referenced objects
Persistent HTTP
The “
persistent HTTP” approach
can re-use the same TCP
connection for Multiple HTTP
transfers, one after another,
serially. Amortizes TCP overhead,
but maintains TCP state longer at
server.
The “pipelining” feature
in HTTP/1.1 allows
requests to be issued
asynchronously on a
persistent connection.
Requests must be
processed in proper order
HTTP request message
- two types of HTTP messages: request, response
- HTTP request message:
- ASCII (human-readable format
Method types
GET is used to request data from a specified
resource.
POST is used to send data to a server to
create/update a resource
PUT (idempotent)
* PUT is used to send data to a server to
create/update a resource
Deletes file specified in the URL field
HEAD
* Asks server to leave requested object out of
response - used for debbugging
HTTP response status codes
Some example codes:
200 OK
request succeeded, requested object later in this msg
301 Moved Permanently
requested object moved, new location specified later in this msg
(Location:)
400 Bad Request
request msg not understood by server
404 Not Found
requested document not found on this server
505 HTTP Version Not Supported
User-server state: cookies
Cookie == a small file with data (up to 4KB)
* Sent to the Web browser by the Web server
* Saved locally inside the browser
* Sent back by the browser in all subsequent requests
(keeping “state”)
What cookies can be used for:
* Authorization
* Shopping carts
* Recommendations
* User session state (Web e-mail)
How to keep “state”
* Protocol endpoints: maintain state at
sender/receiver over multiple transactions
* Cookies: http messages carry state
Replicated Web service
A replicated web service means the same website or web application is hosted on multiple servers at the same time.
All servers share one public IP
pros:
High Availability
Load Balancing
Faster Access
How should the balancer assign clients to servers?
* Random / round-robin
* Load-based
Challenges
* Scalability (must support traffic for n hosts)
34
* State (must keep track of previous decisions)
Web caches (proxy server)
Goal: satisfy client request without
involving origin server
* Cache acts as both client and server
* Browser sends all HTTP requests to
cache
* Object in cache: cache returns
object
* Else cache requests object from
origin server, then returns object to
client
Conditional GET
Goal: don’t send object if client
cache has up-to-date cached
version
Saves bandwidth
Speeds up loading
Reduces server load
Client cache: specify date of cached copy in HTTP request
* If-modified-since: <date></date>
Server: response contains no
object if cached copy is up-to
date:
* HTTP/1.0 304 Not Modified
HTTP/2
Key goal: decreased delay in multi-object HTTP requests
HTTP1.1:
introduced multiple, pipelined GETs over single TCP connection
HTTP/2:
[RFC 7540, 2015] increased flexibility at server in sending
objects to client
transmission order of requested objects based on client-specified
object priority (not necessarily FCFS, which HTTP 1.1 does)
- divide objects into frames, schedule frames to mitigate HOL blocking
HTTP/2 to HTTP/3
HTTP/2 over single TCP connection means:
* recovery from packet loss still stalls all object
transmissions
* as in HTTP 1.1, browsers have incentive to open multiple parallel
TCP connections to reduce stalling, increase overall throughput
* no security over vanilla TCP connection
* HTTP/3: adds security, per object error- and congestion
control (more pipelining) over UDP
* more on HTTP/3 in transport layer