SlideShare une entreprise Scribd logo
1  sur  89
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

Contenu connexe

Tendances

Drivetest procedure for network optimization
Drivetest procedure for network optimizationDrivetest procedure for network optimization
Drivetest procedure for network optimizationBallary Venkateswara
 
Data and computer communication exam i
Data and computer communication exam iData and computer communication exam i
Data and computer communication exam iAndrew Ibrahim
 
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdfibrahim jerbi
 
Calculating center frequency of ieee 802.11 wlan
Calculating center frequency of ieee 802.11 wlanCalculating center frequency of ieee 802.11 wlan
Calculating center frequency of ieee 802.11 wlanAkhil Vijay
 
Dipch01 Introduction to digital image processing
Dipch01 Introduction to digital image processingDipch01 Introduction to digital image processing
Dipch01 Introduction to digital image processingVeerawan Janthanasub
 
Call Routing in Huawei MSOFT
Call Routing in Huawei MSOFTCall Routing in Huawei MSOFT
Call Routing in Huawei MSOFTemyl97
 
Layer 3 messages
Layer 3 messagesLayer 3 messages
Layer 3 messagesJohn Samir
 
UMTS UTRAN Call Flow
UMTS UTRAN Call FlowUMTS UTRAN Call Flow
UMTS UTRAN Call FlowSujeet Kumar
 
Redes - VoIP Asterisk Dial Plan
Redes - VoIP Asterisk Dial PlanRedes - VoIP Asterisk Dial Plan
Redes - VoIP Asterisk Dial PlanLuiz Arthur
 
Call flow oma000003 gsm communication flow
Call flow oma000003 gsm communication flowCall flow oma000003 gsm communication flow
Call flow oma000003 gsm communication flowEricsson Saudi
 
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPP
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPPElementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPP
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPPLouis K. H. Kuo
 

Tendances (15)

Drivetest procedure for network optimization
Drivetest procedure for network optimizationDrivetest procedure for network optimization
Drivetest procedure for network optimization
 
Data and computer communication exam i
Data and computer communication exam iData and computer communication exam i
Data and computer communication exam i
 
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf
2-How to Extend DTAC LTE Coverage with Limited RRU Capacity.pdf
 
Summary 2G y 3G
Summary 2G y 3GSummary 2G y 3G
Summary 2G y 3G
 
Calculating center frequency of ieee 802.11 wlan
Calculating center frequency of ieee 802.11 wlanCalculating center frequency of ieee 802.11 wlan
Calculating center frequency of ieee 802.11 wlan
 
02 channel concept
02 channel concept02 channel concept
02 channel concept
 
Dipch01 Introduction to digital image processing
Dipch01 Introduction to digital image processingDipch01 Introduction to digital image processing
Dipch01 Introduction to digital image processing
 
Call Routing in Huawei MSOFT
Call Routing in Huawei MSOFTCall Routing in Huawei MSOFT
Call Routing in Huawei MSOFT
 
Layer 3 messages
Layer 3 messagesLayer 3 messages
Layer 3 messages
 
UMTS UTRAN Call Flow
UMTS UTRAN Call FlowUMTS UTRAN Call Flow
UMTS UTRAN Call Flow
 
Redes - VoIP Asterisk Dial Plan
Redes - VoIP Asterisk Dial PlanRedes - VoIP Asterisk Dial Plan
Redes - VoIP Asterisk Dial Plan
 
GSM Channel Concept
GSM Channel ConceptGSM Channel Concept
GSM Channel Concept
 
Call flow oma000003 gsm communication flow
Call flow oma000003 gsm communication flowCall flow oma000003 gsm communication flow
Call flow oma000003 gsm communication flow
 
kpi-analysis-nsn
kpi-analysis-nsnkpi-analysis-nsn
kpi-analysis-nsn
 
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPP
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPPElementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPP
Elementary procedures for Circuit-Switched (CS) Call Control (CC) in 3GPP
 

Similaire à Part 7 : HTTP/2, UDP and TCP

Networking Fundamentals: Transport Protocols (TCP and UDP)
Networking Fundamentals: Transport Protocols (TCP and UDP)Networking Fundamentals: Transport Protocols (TCP and UDP)
Networking Fundamentals: Transport Protocols (TCP and UDP)Andriy Berestovskyy
 
Aplication and Transport layer- a practical approach
Aplication and Transport layer-  a practical approachAplication and Transport layer-  a practical approach
Aplication and Transport layer- a practical approachSarah R. Dowlath
 
Socket programming
Socket programmingSocket programming
Socket programmingDivya Sharma
 
Dcn (transmission control protocol) ppt
Dcn  (transmission control protocol) pptDcn  (transmission control protocol) ppt
Dcn (transmission control protocol) pptVijay Kumar
 
Primer to Browser Netwroking
Primer to Browser NetwrokingPrimer to Browser Netwroking
Primer to Browser NetwrokingShuya Osaki
 
Network programming in Java
Network programming in JavaNetwork programming in Java
Network programming in JavaTushar B Kute
 
Network tunneling techniques
Network tunneling techniquesNetwork tunneling techniques
Network tunneling techniquesinbroker
 
Network Programming in Java
Network Programming in JavaNetwork Programming in Java
Network Programming in JavaTushar B Kute
 
Jaimin chp-6 - transport layer- 2011 batch
Jaimin   chp-6 - transport layer- 2011 batchJaimin   chp-6 - transport layer- 2011 batch
Jaimin chp-6 - transport layer- 2011 batchJaimin Jani
 
Nachos Theoretical assigment 3
Nachos Theoretical assigment 3Nachos Theoretical assigment 3
Nachos Theoretical assigment 3colli03
 
Application Layer and Socket Programming
Application Layer and Socket ProgrammingApplication Layer and Socket Programming
Application Layer and Socket Programmingelliando dias
 
Innovation is back in the transport and network layers
Innovation is back in the transport and network layersInnovation is back in the transport and network layers
Innovation is back in the transport and network layersOlivier Bonaventure
 
Network protocols
Network protocolsNetwork protocols
Network protocolsAbiud Orina
 
Beyond TCP: The evolution of Internet transport protocols
Beyond TCP: The evolution of Internet transport protocolsBeyond TCP: The evolution of Internet transport protocols
Beyond TCP: The evolution of Internet transport protocolsOlivier Bonaventure
 
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9Waqas Ahmed Nawaz
 

Similaire à Part 7 : HTTP/2, UDP and TCP (20)

Lecture set 7
Lecture set 7Lecture set 7
Lecture set 7
 
Networking Fundamentals: Transport Protocols (TCP and UDP)
Networking Fundamentals: Transport Protocols (TCP and UDP)Networking Fundamentals: Transport Protocols (TCP and UDP)
Networking Fundamentals: Transport Protocols (TCP and UDP)
 
6 app-tcp
6 app-tcp6 app-tcp
6 app-tcp
 
Part 6 : Internet applications
Part 6 : Internet applicationsPart 6 : Internet applications
Part 6 : Internet applications
 
Aplication and Transport layer- a practical approach
Aplication and Transport layer-  a practical approachAplication and Transport layer-  a practical approach
Aplication and Transport layer- a practical approach
 
Socket programming
Socket programmingSocket programming
Socket programming
 
Dcn (transmission control protocol) ppt
Dcn  (transmission control protocol) pptDcn  (transmission control protocol) ppt
Dcn (transmission control protocol) ppt
 
Primer to Browser Netwroking
Primer to Browser NetwrokingPrimer to Browser Netwroking
Primer to Browser Netwroking
 
Network programming in Java
Network programming in JavaNetwork programming in Java
Network programming in Java
 
Network tunneling techniques
Network tunneling techniquesNetwork tunneling techniques
Network tunneling techniques
 
Network Programming in Java
Network Programming in JavaNetwork Programming in Java
Network Programming in Java
 
Jaimin chp-6 - transport layer- 2011 batch
Jaimin   chp-6 - transport layer- 2011 batchJaimin   chp-6 - transport layer- 2011 batch
Jaimin chp-6 - transport layer- 2011 batch
 
Nachos Theoretical assigment 3
Nachos Theoretical assigment 3Nachos Theoretical assigment 3
Nachos Theoretical assigment 3
 
Application Layer and Socket Programming
Application Layer and Socket ProgrammingApplication Layer and Socket Programming
Application Layer and Socket Programming
 
Innovation is back in the transport and network layers
Innovation is back in the transport and network layersInnovation is back in the transport and network layers
Innovation is back in the transport and network layers
 
CCNA 1 Chapter 7 v5.0 2014
CCNA 1 Chapter 7 v5.0 2014CCNA 1 Chapter 7 v5.0 2014
CCNA 1 Chapter 7 v5.0 2014
 
Network protocols
Network protocolsNetwork protocols
Network protocols
 
Unit 6 : Application Layer
Unit 6 : Application LayerUnit 6 : Application Layer
Unit 6 : Application Layer
 
Beyond TCP: The evolution of Internet transport protocols
Beyond TCP: The evolution of Internet transport protocolsBeyond TCP: The evolution of Internet transport protocols
Beyond TCP: The evolution of Internet transport protocols
 
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9
CCNA (R & S) Module 01 - Introduction to Networks - Chapter 9
 

Plus de Olivier Bonaventure

A personal journey towards more reproducible networking research
A personal journey towards more reproducible networking researchA personal journey towards more reproducible networking research
A personal journey towards more reproducible networking researchOlivier Bonaventure
 
Part 11 : Interdomain routing with BGP
Part 11 : Interdomain routing with BGPPart 11 : Interdomain routing with BGP
Part 11 : Interdomain routing with BGPOlivier Bonaventure
 
Part 10 : Routing in IP networks and interdomain routing with BGP
Part 10 : Routing in IP networks and interdomain routing with BGPPart 10 : Routing in IP networks and interdomain routing with BGP
Part 10 : Routing in IP networks and interdomain routing with BGPOlivier Bonaventure
 
Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Olivier Bonaventure
 

Plus de Olivier Bonaventure (20)

Part3-reliable.pptx
Part3-reliable.pptxPart3-reliable.pptx
Part3-reliable.pptx
 
Part10-router.pptx
Part10-router.pptxPart10-router.pptx
Part10-router.pptx
 
Part1-Intro-Apps.pptx
Part1-Intro-Apps.pptxPart1-Intro-Apps.pptx
Part1-Intro-Apps.pptx
 
Part9-congestion.pptx
Part9-congestion.pptxPart9-congestion.pptx
Part9-congestion.pptx
 
Part2-Apps-Security.pptx
Part2-Apps-Security.pptxPart2-Apps-Security.pptx
Part2-Apps-Security.pptx
 
Part11-lan.pptx
Part11-lan.pptxPart11-lan.pptx
Part11-lan.pptx
 
Part5-tcp-improvements.pptx
Part5-tcp-improvements.pptxPart5-tcp-improvements.pptx
Part5-tcp-improvements.pptx
 
Part8-ibgp.pptx
Part8-ibgp.pptxPart8-ibgp.pptx
Part8-ibgp.pptx
 
Part4-reliable-tcp.pptx
Part4-reliable-tcp.pptxPart4-reliable-tcp.pptx
Part4-reliable-tcp.pptx
 
Part7-routing.pptx
Part7-routing.pptxPart7-routing.pptx
Part7-routing.pptx
 
Part6-network-routing.pptx
Part6-network-routing.pptxPart6-network-routing.pptx
Part6-network-routing.pptx
 
Part1-Intro-Apps.pptx
Part1-Intro-Apps.pptxPart1-Intro-Apps.pptx
Part1-Intro-Apps.pptx
 
Part2-Apps-Security.pptx
Part2-Apps-Security.pptxPart2-Apps-Security.pptx
Part2-Apps-Security.pptx
 
Part4-reliable-tcp.pptx
Part4-reliable-tcp.pptxPart4-reliable-tcp.pptx
Part4-reliable-tcp.pptx
 
Part3-reliable.pptx
Part3-reliable.pptxPart3-reliable.pptx
Part3-reliable.pptx
 
A personal journey towards more reproducible networking research
A personal journey towards more reproducible networking researchA personal journey towards more reproducible networking research
A personal journey towards more reproducible networking research
 
Part 12 : Local Area Networks
Part 12 : Local Area Networks Part 12 : Local Area Networks
Part 12 : Local Area Networks
 
Part 11 : Interdomain routing with BGP
Part 11 : Interdomain routing with BGPPart 11 : Interdomain routing with BGP
Part 11 : Interdomain routing with BGP
 
Part 10 : Routing in IP networks and interdomain routing with BGP
Part 10 : Routing in IP networks and interdomain routing with BGPPart 10 : Routing in IP networks and interdomain routing with BGP
Part 10 : Routing in IP networks and interdomain routing with BGP
 
Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6Part 9 : Congestion control and IPv6
Part 9 : Congestion control and IPv6
 

Dernier

IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119APNIC
 
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书rnrncn29
 
TRENDS Enabling and inhibiting dimensions.pptx
TRENDS Enabling and inhibiting dimensions.pptxTRENDS Enabling and inhibiting dimensions.pptx
TRENDS Enabling and inhibiting dimensions.pptxAndrieCagasanAkio
 
SCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is prediSCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is predieusebiomeyer
 
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书rnrncn29
 
Unidad 4 – Redes de ordenadores (en inglés).pptx
Unidad 4 – Redes de ordenadores (en inglés).pptxUnidad 4 – Redes de ordenadores (en inglés).pptx
Unidad 4 – Redes de ordenadores (en inglés).pptxmibuzondetrabajo
 
Company Snapshot Theme for Business by Slidesgo.pptx
Company Snapshot Theme for Business by Slidesgo.pptxCompany Snapshot Theme for Business by Slidesgo.pptx
Company Snapshot Theme for Business by Slidesgo.pptxMario
 
Cybersecurity Threats and Cybersecurity Best Practices
Cybersecurity Threats and Cybersecurity Best PracticesCybersecurity Threats and Cybersecurity Best Practices
Cybersecurity Threats and Cybersecurity Best PracticesLumiverse Solutions Pvt Ltd
 
ETHICAL HACKING dddddddddddddddfnandni.pptx
ETHICAL HACKING dddddddddddddddfnandni.pptxETHICAL HACKING dddddddddddddddfnandni.pptx
ETHICAL HACKING dddddddddddddddfnandni.pptxNIMMANAGANTI RAMAKRISHNA
 

Dernier (9)

IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119IP addressing and IPv6, presented by Paul Wilson at IETF 119
IP addressing and IPv6, presented by Paul Wilson at IETF 119
 
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
『澳洲文凭』买詹姆士库克大学毕业证书成绩单办理澳洲JCU文凭学位证书
 
TRENDS Enabling and inhibiting dimensions.pptx
TRENDS Enabling and inhibiting dimensions.pptxTRENDS Enabling and inhibiting dimensions.pptx
TRENDS Enabling and inhibiting dimensions.pptx
 
SCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is prediSCM Symposium PPT Format Customer loyalty is predi
SCM Symposium PPT Format Customer loyalty is predi
 
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
『澳洲文凭』买拉筹伯大学毕业证书成绩单办理澳洲LTU文凭学位证书
 
Unidad 4 – Redes de ordenadores (en inglés).pptx
Unidad 4 – Redes de ordenadores (en inglés).pptxUnidad 4 – Redes de ordenadores (en inglés).pptx
Unidad 4 – Redes de ordenadores (en inglés).pptx
 
Company Snapshot Theme for Business by Slidesgo.pptx
Company Snapshot Theme for Business by Slidesgo.pptxCompany Snapshot Theme for Business by Slidesgo.pptx
Company Snapshot Theme for Business by Slidesgo.pptx
 
Cybersecurity Threats and Cybersecurity Best Practices
Cybersecurity Threats and Cybersecurity Best PracticesCybersecurity Threats and Cybersecurity Best Practices
Cybersecurity Threats and Cybersecurity Best Practices
 
ETHICAL HACKING dddddddddddddddfnandni.pptx
ETHICAL HACKING dddddddddddddddfnandni.pptxETHICAL HACKING dddddddddddddddfnandni.pptx
ETHICAL HACKING dddddddddddddddfnandni.pptx
 

Part 7 : HTTP/2, UDP and TCP

Notes de l'éditeur

  1. CSS : 70 KBytes Fonts: 130 KBytes HTML: 27 KBytes Image: 948KB Javascript: 448KB Video: 1678KB
  2. The computation of the UDP checksum is defined in : R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
  3. UDP is mainly used for applications where either short messages are exchanged or losses or not a severe problem (either because they can be supported by the application or because they are used in LAN environment where there are almost no losses) Domain Name System, Network File System (NFS), Remote Procedure Call (RPC), jeux Multimedia (conversational) applications such as VoIP or VideooverIP often use UDP. In this case, UDP is often combined with RTP H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.RTP: A Transport Protocol for Real-Time Applications. RFC1889, Jan 1996
  4. The biggest DDoS attack to date took place in September of 2017. The attack targeted Google services and reached a size of 2.54 Tbps. Google Cloud disclosed the attack in October 2020. The attackers sent spoofed packets to 180,000 web servers, which in turn sent responses to Google. The attack was not an isolated incident: the attackers had directed multiple DDoS attacks at Google's infrastructure over the previous six months.
  5. Urgent pointer is rarely used and will not be described. The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
  6. MSL in IP networks : 120 seconds
  7. MSL in IP networks : 120 seconds
  8. Don’t forget that TCP’s acknowledgements are cumulative.
  9. See e.g. RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
  10. Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
  11. MSL in IP networks : 120 seconds
  12. Most TCP implementations today have fixes for those problems. We will discuss them later.
  13. Most TCP implementations today have fixes for those problems. We will discuss them later.
  14. This utilization of a hash function to compute the value of the initial sequence number is usually called a SYN cookie. In practice, the computation of the SYN cookie is slightly more complex than a simple hash function because the server must also remember inside the cookie the following information : - the MSS value advertised by the client - the optional utilization of TCP options such as RFC1323 large windows or timestamps or SACK by the sender The original discussions that lead to the development of the SYN cookie solution may be found in : http://cr.yp.to/syncookies/archive
  15. Urgent pointer is rarely used and will not be described. The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
  16. MSL in IP networks : 120 seconds
  17. MSL in IP networks : 120 seconds
  18. The computation of TCP’s retransmission timer is described in RFC2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000. Usual values for alpha and beta are 1/8 and 1/4.
  19. See P. Karn, C. Partridge, Improving round-trip time estimates in reliable transport protocols, Proc. ACM SIGCOMM87, August 1987
  20. Les timestamps TCP ont étés introduits dans : RFC1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. L'utilisation de ces timestamps est négociée lors de l'établissement de la connexion TCP. La plupart des implémentations TCP actuelles supportent ces extensions.
  21. See e.g. RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
  22. RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
  23. RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
  24. Urgent pointer is rarely used and will not be described. The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
  25. Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.