Week 7
HTTP/2
UDP and TCP

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release

HTTPS versus HTTP

Today's web pages
Source: httparchive.org

How many HTTP
requests per page ?
Source: httparchive.org

Today's web pages
Source: https://httparchive.org/reports/page-weight.org
• Can you order the different elements of web
pages in terms of importance ( smallest average
volume first) ?
• CSS
• Font
• HTML
• Images
• Javascript
• Video

How many TCP
connections per page
?
Source: httparchive.org

A faster web
• How could we speed up the web ?
• What is our objective ?

How to improve web ?
• What can be done to improve web
performance ?
• Reduce unnecessary data transfers
• If-Modified-Since

Reducing latency ?
• How can we reduce latency ?
• Move server closer to client – CDN

Web proxies

Improving HTTP

HTTP/2
• Why changing HTTP ?
• Reduce page load time
• Minimize data exchanged
• Reduce network load
• Fewer transport connections
• Reduce risks of attacks from ASCII
parsing

HTTP/2.0
• Key changes from HTTP/1.x
• Binary protocol instead of ASCII
• Support multiple datastreams over the
underlying transport connection

Basics of HTTP/2
• Main modifications compared to HTTP/1.1
• Binary framing protocol
• Will be used over TLS anyway
• One connection for several objects
• Several objects can be multiplexed
• Server push
• Data compression for requests and
responses

HTTP/2.0

HTTP/2 versus
HTTP/1
Source: https://hpbn.co/http2/

A single TCP
connection
• One TCP connection for all objects for a
given client-server pair
• Minimize in-network and server
resources
• Beware of head-of-line blocking
• Can we do better than HTTP/1.1 ?

Issues with HTTP/1.1
• Can use a single connection per server
but
• Client decides the order of the requests
• Server sends objects in order
requested by client
• A large object (e.g. image) may block
smaller but more important objects
(e.g. css/javascript)

HTTP/2 streams
Source: https://hpbn.co/http2/

HTTP/2 streams
• Benefits
• Client can send multiple requests in
parallel
• Server can decide the optimal delivery
order
• Server can interleave multiple objects
and prioritise them

Server Push
Source: https://hpbn.co/http2/

Agenda
• Internet applications
• Web
• UDP
• TCP

Transport layer
• Objectives
• Improve service provided to
applications
• Multiplexing
Physical Physical
Datalink Datalink
Network
Network
Physical
Datalink
Network
Segments
Transport Transport

Network service
• Characteristics
• Connectionless
• Unreliable
• Maximum packet size
Physical Physical
Datalink Datalink
Packets Network
Network
Physical
Datalink
Network Packets

UDP protocol
Source Port Destination port
UDP length UDP Checksum
8 bytes
Payload
32 bits
Constraint
Each UDP segment must
fit inside a single IP packet
Used to identify the
application that will receive
this segment on destination
host
Checksum computed over the entire
UDP segment and part of the IP
header to detect transmission errors.
0 means that the sender did not
compute a checksum.
Used to identify the
application that sent this
segment on sending host

UDP ports
Server
Client
Source port : 1234
Destination port: 5678
Request
Response
Source port : 5678
Destination port: 1234

UDP : limitations
• Maximum length of UDP SDUs depends on
maximum size of IP packets
• Unreliable connectionless service
• SDUs can get lost but transmission errors
will be detected
• UDP does not preserve ordering
• UDP does not detect nor prevent
duplication

UDP Applications
• Among these applications, which typically
use UDP ?

Usage of UDP
• Request-response applications
• DNS, RPC, NFS, ..
• Applications with short delay
• Games
• Multimedia transfer
• Voice over IP
• Video over IP

Attacks against DNS
• DNS is key, if an attacker can change the
responses returned by resolvers, this
could have a major impact
• Users rely on their resolver to obtain
name-to-address mappings

Packet spoofing
• On the Internet, every device has one IP
address
• All the packets sent by this device use its
IP address as their source
• Is it possible for Trudy to send a packet
using Alice’s IP address ?

https://spoofer.caida.org/country_stats.php

Spoofing attack
B
T
A
Q? www.bob.net
www.bob.net=2001:db8:12::1
Response sent
using Bob’s IP
address
How can Alice verify that
Bob’s message is
legitimate and Trudy’s

Countering spoofing
attacks
Identification Flags
32 bits
Number of additional
Number of authority
Number of answers
Questions
(variable number of resource records)
Number of questions
Answers
(variable number of resource records)
Authority
(variable number of resource records)
Additional information
(variable number of resource records)
Source port Dest. port
UDP Length Checksum
UDP
header
DNS
message
Alice should use random
source port in her queries and
verify the server response
Alice should use random
identifiers and verify the
server response
Total: 32 bits of randomness
https://tools.ietf.org/html/rfc6056

Other approaches
• DNSSEC
• DNS extensions that allows servers to sign their
reponse using public keys
• DNS responses sent in clear over UDP
• Alice can verify the cryptographic signature
• DNS over TLS or DNS over HTTPS
• Request/Response sent over TLS session(encrypted
and authenticated)
• cannot be hijacked by Trudy

Denial of Service
attacks
• How can Trudy saturate Alice’s link to
make it impossible for her to use Internet
?
• Naive approach
T
A
Lots of traffic
sent by
Trudy
Can Trudy hide the
attack and amplify it ?
https://www.cloudflare.com/en-gb/learning/ddos/famous-ddos-attacks/
What was the largest
known DDoS attack ?

Amplification attack
• Protocol designers, beware !
B
T
A
S=B,D=A www.bob.net=...
Trudy will try to send a
short request that triggers
a large response from Bob

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release

TCP
• Service provided
• Connection-oriented
• Reliable
• No losses, no errors, no duplications
• Bytestream

TCP port numbers
Server : S
Client : C
Source Port : 1234
Destination Port: 5678
Request
Response
Source Port : 5678
Destination Port: 1234
Established TCP connections on client
Local IP Remote IP Local Port Remote Port
C S 1234 5678
Established TCP connections on server
Local IP Remote IP Local Port Remote Port
S C 5678 1234

Multiple connections
Client: A
Client : B
Server : S
TCP connections on server
IP local IP remote Port local Port remote
S A 80 1234
S A 80 1235
S B 80 1235
TCP connections on host A
IP local IP remote Port local Port remote
A S 1234 80
A S 1235 80
TCP connections on host B
IP local IP remote Port local Port remote
B S 1235 80

TCP segment
Source port Destination port
Payload
32 bits
Checksum Urgent pointer
THL Reserved Flags
20 bytes
Sequence number
Optional header extension
Window
Flags :
used to indicate the function of a segment
SYN : used during establishment
FIN : used during connection release
RST : used in case of problems
ACK : if true, means that the Acknowledgement
number inside the segment is valid
Computed over the entire
segment and part of the IP
header
Acknowledgement number
Segment header length

Three-way handshake
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y)
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Initial sequence number (y)
SYN(seq=x)
Connection established
Connection established
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1

TCP FSM
Init
SYN RCVD SYN Sent
Established
?SYN / !SYN+ACK !SYN
?SYN+ACK / !ACK
?SYN / !SYN+ACK
?ACK
!SYN
?ACK

Simultaneous open
CONNECT.conf
SYN(seq=y)
CONNECT.req
CONNECT.req
SYN(seq=x)
Connection established
Connection established
CONNECT.conf
SYN+ACK(seq=y, ack=x+1)
SYN+ACK(seq=x, ack=y+1)

Connection refused
RST+ACK(ack=x+1,seq=0)
DISCONNECT.req
DISCONNECT.ind
CONNECT.req
CONNECT.ind
SYN(seq=x)
Connection refused
A TCP entity MUST never send a RST segment
upon reception of another RST segment

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release

Reliable data transfer
DATA.req ("abcd")
DATA.ind("abcd")
(seq=123,"abcd")
DATA.req ("jkl")
(seq=132,"jkl")
(seq=127,"efg")
DATA.req ("efg")
(ack=127)
(ack=135)
DATA.ind("efghijkl")
DATA.req ("hi")
(seq=130,"hi")
Which ack is returned ?
Which ack is returned ?
Which ack
is returned ?

Reliable data transfer
(seq=127,"ef")
(seq=123,"abcd")
(seq=123,"abcd")
(seq=127,"ef")
(ack=123)
Retransmission timer
(ack=129)
(ack=129)
unnecessary
retransmission
"abcdef"
Retransmission of all
unacked segments
“ef” placed in buffer

Fast retransmit
(seq=123,"abcd")
(seq=120,"xyz")
(ack=123)
(seq=129,"gh")
(seq=131,"ij")
(ack=123)
First duplicate ack
(ack=123)
Second duplicate ack
(ack=123)
Third duplicate ack
(seq=127,"ef")
Out of sequence
Out of sequence
Out of sequence

Fast retransmit
(ack=123)
(ack=123)
(ack=123)
(ack=123)
(ack=133)
"abcdefghij"
(seq=127,"ef")
Out of sequence, in buffer
(seq=129,"gh")
Out of sequence, in buffer
(seq=131,"ij")
Out of sequence, in buffer
Which ack is returned ?

Flow control
(seq=122,"abcd")
(ack=126,rwin=0)
Last_ack=122, swin=100, rwin=4
To transmit : abcdefghijklm
Last_ack=122, swin=96, rwin=0
Last_ack=126, swin=100, rwin=0
(ack=126,rwin=2)
(seq=126,"ef")
(ack=128,rwin=20)
Last_ack=126, swin=100, rwin=2
Last_ack=126, swin=98, rwin=0
Last_ack=128, swin=100, rwin=20
Last_ack=128, swin=93, rwin=13
(seq=128,"ghijklm")
(ack=135,rwin=20)
Last_ack=135, swin=100, rwin=20

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release

Connection release
FIN(seq=x)
DISCONNECT.req (A-B)
DISCONNECT.ind(A-B)
ACK(ack=x+1)
DISCONNECT.conf(A-B)
ACK(ack=y+1)
DISCONNECT.conf(A-B)
DISCONNECT.req(B-A)
DISCONNECT.ind(B-A)
FIN(seq=y)
Time WAIT
Maintain state for this
connection during twice MSL
to be able to retransmit ACK
if a segment is received from
the other entity
outgoing connection closed
incoming connection closed
incoming connection closed
outgoing connection closed
State can be removed
Last sent data : x-1
Last sent data : y-1

Abrupt release
RST(seq=x)
DISCONNECT.req (abrupt)
DISCONNECT.ind(abrupt)
Connection closed
Connection closed
State can be removed
State can be removed
Last sent data : x

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment (more details)
• Reliable data transfer
• Connection release

Three-way handshake
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y)
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Initial sequence number (y)
SYN(seq=x)
Connection established
Connection established
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1
How is this number chosen ?
How is this number chosen ?

Initial sequence
number
• First approach
• Each TCP host has a clock that
increments the iss every 4 microsecond
• Current approach
• Each TCP host picks a random number
as its initial sequence number

The problem with
trusted addresses
B
T
A
ACK(seq=x+1, ack=y+1)
SYN+ACK(ack=x+1,seq=y)
SYN(seq=x)
Connection comes
from Alice’s IP
address don’t need
to ask username
and password
DATA(seq=x+1, ack=y+1)
Can Trudy hijack this
connection ?

TCP and spoofing
• Can Trudy create a fake TCP connection
by spoofing Alice's IP when she is away
?
• Trudy can send spoofed IP packets to
Bob using Alice’s address
• But Trudy cannot receive the packets
sent by Bob to Alice

TCP and spoofing
• Trudy's view of the transfer
SYN+ACK(Dst=A,ack=x+1,seq=y)
SYN(Src=A,seq=x)
ACK(seq=x+1, ack=y+1)
Data(Src=A,seq=x+1)
Trudy Alice
Ignored if Alice is offline
Can Trudy predict y ?
Bob

TCP establishment
SYN(Src=C,seq=x)
CONNECT.ind
SYN+ACK(Dest=C,ack=x+1,seq=y)
ACK(Src=A,seq=x)
CONNECT.req

DoS attack
SYN(Src=A,seq=x)
CONNECT.ind
CONNECT.ind
SYN+ACK(Dest=A,ack=x+1,seq=y)
SYN+ACK(Dest=B,ack=x+1,seq=z)
SYN(Src=B,seq=x)
• Attacker sends 1000s of (spoofed) SYNs

Countering DoS attacks
• Principle of the solution
• Server should not create any state
before being sure that the client can
receive the segments that it sends
SYN(Src=C,seq=x)
SYN+ACK(Dest=C,ack=x+1,seq=y)
ACK(Src=A,seq=x,
ack=y+1)
CONNECT.req
Server does not
store anything
Server checks
that third ACK is
valid
and creates state

SYN Cookies
SYN+ACK(ack=x+1,seq=y)
SYN(seq=x)
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
CONNECT.conf
No state created
y=Hash(IPClient,PortClient,Secret)
Verify that
ack=1+Hash(IPClient,PortClient,Secret)
State is created
• Server verifies third ack without any state
How should the
server select y ?

TCP options
Source port Destination port
Payload
32 bits
Checksum Urgent pointer
THL Reserved Flags
20 bytes
Sequence number
Optional header extension
Window
Acknowledgement number
Space in the
header with new
fields which can
be exchanged
over a
connection
Each TCP Option encoded as:
• Type
• Length
• Value

TCP options
• Maximum Segment Size
• Selective acknowledgements
• Window Scale
• Timestamps
• Multipath TCP
• ...

Negotiating the utilization
of TCP Options
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y) Option K
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Option K proposed
Initial sequence number (y)
Option K accepted
SYN(seq=x),Option K
Connection established
Option accepted
Connection established
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1

The MSS Option
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y) MSS=1000
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Will not accept segments longer
than 1200 bytes
Initial sequence number (y)
Will never send segments longer than
1200 bytes
Will not accept segments longer
than 1000 bytes
SYN(seq=x),MSS=1200
Connection established
Option accepted
Connection established
Will never send segments longer than
1000 bytes
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer (more details)
• Connection release

Reliable data
transfer
(seq=127,"ef")
(seq=123,"abcd")
(seq=123,"abcd")
(seq=127,"ef")
(ack=123)
Retransmission timer
(ack=129)
(ack=129)
unnecessary
retransmission
"abcdef"
Retransmission of all
unacked segments
“ef” placed in buffer

Retransmission
timer
• How to compute it ?
• round-trip-time may change frequently
during the lifetime of a TCP connection

Retransmission timer
• Algorithm
• timer = mean(rtt) + 4*std_dev(rtt)
• est_mean(rtt) = (1- )*est_mean(rtt)
+ *rtt_measured
• est_std_dev=(1-)*est_std_dev+
*|rtt_measured - est_mean(rtt)|

RTT measurements
• Solution (Karn/Partridge)
• Do not measure rtt of retransmitted segments
(seq=123,"abcd")
(seq=120,"xyz")
(ack=123)
(ack=128)
measured rtt
Timer
which is the good rtt ?
(seq=123,"abcd")

With Timestamp option
(seq=123,TS=3, TS echo=12, "abcd")
(seq=120,TS=1, TS echo=7, "xyz")
(ack=123, TS=12, TS echo=1)
(ack=127, TS=17, TS echo=3)
measured rtt
timer
measured rtt
(seq=123,TS=5, TS echo=12, "abcd")

TCP Timestamps
• Two different roles
• Help in rtt measurements
• Protection Against Wrapped Sequence
Numbers (PAWS)

Fast retransmit
(seq=123,"abcd")
(ack=123)
(ack=123)
(ack=123)
(ack=123)
(ack=133)
(seq=123,"abcd")
"abcdefghij"
(seq=127,"ef")
Out of sequence, in buffer
(seq=129,"gh")
Out of sequence, in buffer
(seq=131,"ij")
Out of sequence, in buffer
3 duplicates was the initial specification.
Modern TCP stacks adjust the number
dynamically

Selective Acks
(seq=123,"abcd")
(seq=127,"ef")
(ack=123)
(seq=129,"gh")
(seq=131,"ij")
(ack=123,sack:127-128)
(ack=123, sack:127-130)
(ack=123, sack:127-132)
Lost
(seq=123,"abcd")
(ack=133)
"abcdefghij"
only 123-126 must be
retransmitted
• Receiver reports SACK blocks
• Negotiated during establishment

Delayed acks
• Sending an ack per segment is costly
• Tradeoff
• In sequence data segment
• no ack waiting, delay by up to 50 msec
• one ack waiting, send immediately
• Out-of-sequence data segment
• send ack immediately
What is the benefit of delayed
acks ?

When to send data ?
• When should a segment be sent ?
• Option 1
• After each write system call
• Lowest delay for application
• Option 2
• When there is a full segment of data
• Lowest overhead for network

Nagle algorithm
• A new data segment can be sent if either
• This is a full segment (MSS bytes)
• There are no unacknowledged bytes

Observed IP packets
http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml

Limitation of TCP flow
control
Source port Destination port
Payload
32 bits
Checksum Urgent pointer
THL Reserved Flags
20 bytes
Sequence number
Optional header extension
Window
Acknowledgement number
16 bits !

TCP flow control
• Performance function of window size
• Throughput ~= window/rtt
• TCP window : 16 bits field
• RFC1323 Window scale extension
rtt 1 msec 10 msec 100 msec
Window
8 Kbytes 65.6 Mbps 6.5 Mbps 0.66 Mbps
64 Kbytes 524.3 Mbps 52.4 Mbps 5.2 Mbps

Window scaling
• Window maintained as a 32 bits integer
by TCP implementations
• But sent as a scaled 16 bits in
segments
• Scaling factor announced in WScale
option in SYN/SYN+ACK segments

Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release (more details)

Connection release
FIN(seq=x)
DISCONNECT.req (A-B)
DISCONNECT.ind(A-B)
ACK(ack=x+1)
DISCONNECT.conf(A-B)
ACK(ack=y+1)
DISCONNECT.conf(A-B)
DISCONNECT.req(B-A)
DISCONNECT.ind(B-A)
FIN(seq=y)
Time WAIT
Maintain state for this
connection during twice MSL
to be able to retransmit ACK
if a segment is received from
the other entity
outgoing connection closed
incoming connection closed
incoming connection closed
outgoing connection closed
State can be removed
Last sent data : x-1
Last sent data : y-1
Sent only after all data
up to x has been
received

TCP connection
release
FIN Wait1
SYN RCVD
CLOSE Wait
Established
FIN Wait2
LAST-ACK
TIME Wait
Closing
Closed
?FIN/!ACK
!FIN
?ACK
Timeout[2MSL]
?FIN/!ACK
?ACK
!FIN
?ACK
?FIN/!ACK
!FIN