CS 408

Computer Networks

Week 7-2 TCP/IP Applications

HTTP

Kürşat Çağıltay, kursat.cagiltay@sabanciuniv.edu

1
Happy Bayrams to all....

2
Happy 31st Birthday Turkish Internet

3
 Protocol Suites

TCP/IP Protocol Suite

• An open standard
protocol suite: freely
available to the public
and can be used by any
vendor
• Endorsed by the
networking industry and
approved by a standards
organization to ensure
interoperability
• IETF, ISOC, ITU
 Hypertext Transfer Protocol
HTTP
• What does hypertext mean?
“a body of written or pictorial material interconnected in such a complex
way that it could not conveniently be presented or represented on paper”
Ted Nelson, 1965
• Underlying protocol of the World Wide Web
• Can transfer plain text, audio, images, etc.
— actually you can transfer any type of file using HTTP
• Widely used version HTTP 1.1 – RFC 2616
—176 pages
•HTTP/2 (2015 – RFC 7540)
•HTTP/3 – (2022 - RFC 8441)
As we may think–Memex (Bush 1945)
• «Memex is an enlarged
intimate supplement to one’s
memory»
• «Hypertext Demo» Doug
Engelbart –1968

• HTTP/0.9 Tim
Berners-Lee - 1991
Engelbart - https://youtu.be/74c8LntW7fo
As we may think, The Atlantic Monthly, July 1945
http://www.theatlantic.com/doc/194507/bush
6
December 9, 1968 demo by Doug Engelbart
at SRI (Stanford Research Institute)

7
Web and HTTP
 web page consists of objects, each of which can be
stored on different Web servers
 object can be HTML file, JPEG image, Java applet, audio
file,…
 web page consists of base HTML-file which includes
several referenced objects, each addressable by a URL,
e.g.,
www.someschool.edu/someDept/pic.gif

host name path name

 HTTP Overview
• Transaction oriented client/server protocol
• Usually between Web browser (client) and Web server
• Uses TCP connections (on port 80)
• Stateless
— Server (normally) does not keep any info about client history
— Each transaction treated independently
— New TCP connection for each transaction
— Terminate connection when transaction is complete

• Why stateless?
— Hint: it was a design decision due to the nature of transactions
 HTTP overview
HTTP: hypertext transfer protocol
 Web’s application layer protocol
 Textual protocol (Headers are PC running
textual – like SMTP) Firefox browser
 client/server model:
• client: browser that requests,
receives, (using HTTP protocol) and server running
Apache Web
“displays” Web objects server
• server: Web server sends (using HTTP
protocol) objects in response to iPhone running
Safari browser
requests
 HTTP overview (continued)
HTTP uses TCP: HTTP is “stateless”
 client initiates TCP connection  server maintains no
(creates socket) to server, port 80 information about past client
 server accepts TCP connection from requests
client aside
protocols that maintain “state”
 HTTP messages (application-layer are complex!
protocol messages) exchanged  past history (state) must be
between browser (HTTP client) and maintained
Web server (HTTP server)  if server/client crashes, their
 TCP connection closed views of “state” may be
inconsistent, must be reconciled
HTTP message structure: general format

Response / request
method sp URL sp version cr lf
line
header field name value cr lf
header
~
~ ~
~ lines

header field name value cr lf

cr lf

~
~ entity body ~
~ body
 HTTP request message
 two types of HTTP messages: request, response
 HTTP request message:
• ASCII (human-readable format) carriage return character
line-feed character
request line (GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www.mit.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
header Accept-Language: en-us,en;q=0.5\r\n
lines Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
carriage return, line \r\n
feed at start of line
indicates end of
header lines
General Header Fields
• Contain information that is not directly related to data to be
transferred
— some are for connection management
— for example
• Keep-alive: to keep the TCP connection open for a while; needed for
persistent connections (shall see persistent connections later)
— can be used for both request and response
 Other HTTP request messages
GET method (for sending data to
server): HEAD method:
 requests headers (only) that
 include user data in URL field of HTTP would be returned if specified
GET request message URL were requested with an
HTTP GET method.
POST method: PUT method:
 web page often includes form
 uploads new file (object) to
input
server
 user input sent from client to
 completely replaces file that
server in entity body of HTTP
exists at specified URL with
POST request message
content in entity body of POST
HTTP request message
HTTP response message
status line (protocol HTTP/1.1 200 OK\r\n
status code status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
header Accept-Ranges: bytes\r\n
lines Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n

data, e.g., requested

data data data data data ...
HTML file
 HTTP response status codes
 status code appears in 1st line in server-to-client response message.
 some sample codes:
200 OK
• request succeeded, requested object later in this message
301 Moved Permanently
• requested object moved, new location specified later in this message (in
Location: field)
400 Bad Request
• request msg not understood by server
404 Not Found
• requested document not found on this server
505 HTTP Version Not Supported
Trying out HTTP (client side)
1. Telnet to people.sabanciuniv.edu
 opens TCP connection to port 80 (default HTTP
server port)
 anything typed in will be sent to port 80

2. type in a GET HTTP request:

 by typing this in (hit carriage return twice), you
send this minimal (but complete) GET request to
HTTP server
 HTTP connections: two types
Non-persistent HTTP Persistent HTTP
1. TCP connection opened TCP connection opened
2. at most one object sent to a server
over TCP connection multiple objects can be
3. TCP connection closed sent over single TCP
connection between
downloading multiple client, and that server
objects required multiple TCP connection closed
connections
 Non-persistent HTTP:
response time initiate TCP
connection
RTT

RTT (definition): time for a small request file

packet to travel from client to RTT time to
transmit
server and back file received file
initiate TCP
HTTP response time (per object): connection RTT
 one RTT to initiate TCP connection
request file
 one RTT for HTTP request and first few
RTT time to
bytes of HTTP response to return transmit
 object/file transmission time file received
file
initiate TCP
connection RTT

time time
Non-pers HTTP response time = 2RTT+ file trans. time
 Non-persistent HTTP: example
User enters URL: www.mit.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

1a. HTTP client initiates TCP

connection to HTTP server 1b. HTTP server at host www.mit.edu
(process) at www.mit.edu on port waiting for TCP connection at port
80 80 “accepts” connection, notifying
client
2. HTTP client sends HTTP
request message
(containing URL) into TCP 3. HTTP server receives request
connection socket. message, forms response message
time Message indicates that containing requested object, and
client wants object sends message into its socket
someDepartment/home.index
 Non-persistent HTTP: example
(cont.)
User enters URL: www.mit.edu/someDepartment/home.index
(containing text, references to 10 jpeg images)

4. HTTP server closes TCP

5. HTTP client receives response connection.
message containing html file,
displays html. Parsing html file,
finds 10 referenced jpeg objects

6. Steps 1-5 repeated for

each of 10 jpeg objects
time
T=2 RTT + 10 x 2 RTT + all Trans. Time
(no parallel connections)
 Persistent HTTP (HTTP 1.1)
Non-persistent HTTP Persistent HTTP (HTTP1.1):
issues:  server leaves connection open
 requires 2 RTTs per object after sending response
 OS overhead for each TCP  subsequent HTTP messages
connection between same client/server sent
over open connection
 browsers often open multiple
parallel TCP connections to  client sends requests as soon as
fetch referenced objects in it encounters a referenced object
parallel  as little as one RTT for all the
referenced objects (cutting
response time in half)
 Pipelining in Persistent HTTP

Persistent without pipelining:

• client issues new request only when previous response has been received
• one RTT for each referenced object (plus the transmission time)
• Another RTT is needed for TCP connection, but this is only once for the entire
connection
Persistent with pipelining:
• default in HTTP/1.1
• client sends requests as soon as it encounters a referenced object
• as little as one RTT for all the referenced objects (plus the transmission
times)
— Another RTT plus the transmission time may be needed for the main object where the
references are learnt
• Another RTT is needed for TCP connection, but this is only once for the entire
connection
initiate TCP RTT
Persistent, no pipeline
connection

RTT time to
Transmit
index file
time to 1 index, 10 image files
RTT transmit
image file
RTT time to T=RTT+RTT+10xRTT+all trans. times
transmit
image file
RTT time to
transmit
image file

time time 25
initiate TCP RTT
Persistent, with pipeline
connection

RTT time to
Transmit
index file
time to 1 index, 10 image files
RTT transmit
image file
time to T=RTT+RTT+RTT+all trans. times
transmit
image file

time time 26
Maintaining user/server state:
cookies
Recall: HTTP GET/response interaction is stateless
Web sites and client browser use cookies to maintain some
state between transactions
four components:
1) cookie header line of HTTP response message
2) cookie header line in next HTTP request message
3) cookie file kept on user’s host, managed by user’s
browser
4) back-end database at Web site
Maintaining user/server state:
cookies
client
server
usual HTTP request msg Amazon server
cookie file creates ID backend
usual HTTP response 1678 for user create database
amazon 1678 set-cookie: 1678 entry
usual HTTP request msg
cookie: 1678 cookie- access
specific
action
usual HTTP response msg
one week later: access
amazon 1678 usual HTTP request msg
cookie: 1678 cookie-
specific
usual HTTP response msg action
time
time
HTTP cookies: comments
aside
What cookies can be used for: cookies and privacy:
 authorization  cookies permit sites to
 shopping carts learn a lot about you on
their site.
 recommendations
 third party persistent
 user session state (Web e-mail) cookies (tracking
cookies) allow common
identity (cookie value)
Challenge: How to keep state: to be tracked across
 protocol endpoints: maintain state at
multiple web sites
sender/receiver over multiple transactions
 cookies: HTTP messages carry state
 Web caches (proxy servers)
Goal: satisfy client request without involving origin server

 browser is pointed to a Web proxy

cache server
client
 browser sends all HTTP origin
requests to cache server

• if object in cache: cache

returns object to client
• else cache requests object
from origin server, caches client
origin
received object, then server
returns object to client
 Web caches (proxy servers)
 Web cache acts as Why Web caching?
both client and server  reduce response time for
• server for original client request
requesting client • cache is closer to client
• client to origin server
 reduce traffic on an
 typically cache is institution’s access link
installed by ISP
(university, company,  Internet is dense with caches
residential ISP) • enables “poor” content
providers to more effectively
deliver content
Real life example
 Where is www.mit.edu server located?
 Where is the main delay point to access mit.edu?
 What can you do?

32
Caching example
Scenario:
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Average request rate from browsers to origin
servers: 15reqs/sec
 average data rate to browsers: 1.50 Mbps
1.54 Mbps
Performance: problem: large
access link

 LAN utilization: .0015 delays at high institutional

network
 access link utilization = .97 utilization! 1 Gbps LAN

 end-end delay = Internet delay +

access link delay + LAN delay
= 2 sec + minutes + usecs
Application Layer: 2-33
Caching example: buy a faster
access link
Scenario: 154 Mbps
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Avg request rate from browsers to origin
servers: 15/sec
 avg data rate to browsers: 1.50 Mbps 154 Mbps
1.54 Mbps
Performance: access link

 LAN utilization: .0015 institutional

network
1 Gbps LAN
 access link utilization = .97 .0097
 end-end delay = Internet delay +
access link delay + LAN delay
= 2 sec + minutes + usecs
Cost: faster access link (expensive!) msecs
Application Layer: 2-34
Caching example: install a web
cache
Scenario:
 access link rate: 1.54 Mbps origin
 RTT from institutional router to server: 2 sec servers
 Web object size: 100K bits public
Internet
 Avg request rate from browsers to origin
servers: 15/sec
 avg data rate to browsers: 1.50 Mbps
1.54 Mbps
Performance: access link

 LAN utilization: .? institutional

network
1 Gbps LAN
 access link utilization = ?
 average end-end delay = ?
Cost: web cache (cheap!) local web cache

Application Layer: 2-35

HTTP/2
Key goal: decreased delay in multi-object HTTP requests

HTTP1.1: introduced multiple, pipelined GETs over single

TCP connection
 server responds in-order (FCFS: first-come-first-served
scheduling) to GET requests
 with FCFS, small object may have to wait for transmission
(head-of-line (HOL) blocking) behind large object(s)
HTTP/2
Key goal: decreased delay in multi-object HTTP requests

HTTP/2: [RFC 7540, 2015] increased flexibility at server in

sending objects to client:
 methods, status codes, most header fields unchanged from
HTTP 1.1
 transmission order of requested objects based on client-
specified object priority (not necessarily FCFS)
 push unrequested objects to client
 divide objects into frames, schedule frames to mitigate HOL
blocking
HTTP/2: mitigating HOL blocking
HTTP 1.1: client requests 1 large object (e.g., video file, and 3
smaller objects) server

GET O4 GET O
3 GET O2
GET O1
object data requested
client

O1

O2
O1
O2 O3
O3
O4
O4

objects delivered in order requested: O2, O3, O4 wait behind O1

 HTTP/2: mitigating HOL blocking
HTTP/2: objects divided into frames, frame transmission interleaved
server

GET O4 GET O
3 GET O2
object data requested
GET O1
client
O2
O4
O3 O1

O2
O3
O1 O4

O2, O3, O4 delivered quickly, O1 slightly delayed

HTTP/3 –

• It uses UDP
• HTTP/3's use of UDP is specifically built on top of the QUIC
(Quick UDP Internet Connections) protocol
• HTTP/3 aims to enhance the performance and security of web
communication, especially in scenarios with high latency or
unreliable network conditions

40