Successfully reported this slideshow.

Part 7 : HTTP/2, UDP and TCP

0

Share

Loading in …3
×
1 of 89
1 of 89

Part 7 : HTTP/2, UDP and TCP

0

Share

Download to read offline

Description

Slides supporting the "Computer Networking: Principles, Protocols and Practice" ebook. The slides can be freely reused to teach an undergraduate computer networking class using the open-source ebook.

Transcript

  1. 1. Week 7 HTTP/2 UDP and TCP
  2. 2. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
  3. 3. HTTPS versus HTTP
  4. 4. Today's web pages Source: httparchive.org
  5. 5. How many HTTP requests per page ? Source: httparchive.org
  6. 6. 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
  7. 7. How many TCP connections per page ? Source: httparchive.org
  8. 8. A faster web • How could we speed up the web ? • What is our objective ?
  9. 9. How to improve web ? • What can be done to improve web performance ? • Reduce unnecessary data transfers • If-Modified-Since
  10. 10. Reducing latency ? • How can we reduce latency ? • Move server closer to client – CDN
  11. 11. Web proxies
  12. 12. Improving HTTP
  13. 13. 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
  14. 14. HTTP/2.0 • Key changes from HTTP/1.x • Binary protocol instead of ASCII • Support multiple datastreams over the underlying transport connection
  15. 15. 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
  16. 16. HTTP/2.0
  17. 17. HTTP/2 versus HTTP/1 Source: https://hpbn.co/http2/
  18. 18. 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 ?
  19. 19. 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)
  20. 20. HTTP/2 streams Source: https://hpbn.co/http2/
  21. 21. 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
  22. 22. Server Push Source: https://hpbn.co/http2/
  23. 23. Agenda • Internet applications • Web • UDP • TCP
  24. 24. Transport layer • Objectives • Improve service provided to applications • Multiplexing Physical Physical Datalink Datalink Network Network Physical Datalink Network Segments Transport Transport
  25. 25. Network service • Characteristics • Connectionless • Unreliable • Maximum packet size Physical Physical Datalink Datalink Packets Network Network Physical Datalink Network Packets
  26. 26. 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
  27. 27. UDP ports Server Client Source port : 1234 Destination port: 5678 Request Response Source port : 5678 Destination port: 1234
  28. 28. 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
  29. 29. UDP Applications • Among these applications, which typically use UDP ?
  30. 30. Usage of UDP • Request-response applications • DNS, RPC, NFS, .. • Applications with short delay • Games • Multimedia transfer • Voice over IP • Video over IP
  31. 31. 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
  32. 32. 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 ?
  33. 33. https://spoofer.caida.org/country_stats.php
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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 ?
  38. 38. 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
  39. 39. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
  40. 40. TCP • Service provided • Connection-oriented • Reliable • No losses, no errors, no duplications • Bytestream
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. TCP FSM Init SYN RCVD SYN Sent Established ?SYN / !SYN+ACK !SYN ?SYN+ACK / !ACK ?SYN / !SYN+ACK ?ACK !SYN ?ACK
  46. 46. 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)
  47. 47. 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
  48. 48. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
  49. 49. 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 ?
  50. 50. 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
  51. 51. 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
  52. 52. 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 ?
  53. 53. 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
  54. 54. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
  55. 55. 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
  56. 56. 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
  57. 57. Agenda • Internet applications • Web • UDP • TCP • Connection establishment (more details) • Reliable data transfer • Connection release
  58. 58. 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 ?
  59. 59. 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
  60. 60. 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 ?
  61. 61. 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
  62. 62. 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
  63. 63. 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
  64. 64. 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
  65. 65. 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
  66. 66. 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 ?
  67. 67. 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
  68. 68. TCP options • Maximum Segment Size • Selective acknowledgements • Window Scale • Timestamps • Multipath TCP • ...
  69. 69. 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
  70. 70. 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
  71. 71. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer (more details) • Connection release
  72. 72. 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
  73. 73. Retransmission timer • How to compute it ? • round-trip-time may change frequently during the lifetime of a TCP connection
  74. 74. 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)|
  75. 75. 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")
  76. 76. 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")
  77. 77. TCP Timestamps • Two different roles • Help in rtt measurements • Protection Against Wrapped Sequence Numbers (PAWS)
  78. 78. 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
  79. 79. 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
  80. 80. 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 ?
  81. 81. 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
  82. 82. Nagle algorithm • A new data segment can be sent if either • This is a full segment (MSS bytes) • There are no unacknowledged bytes
  83. 83. Observed IP packets http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml
  84. 84. 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 !
  85. 85. 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
  86. 86. 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
  87. 87. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release (more details)
  88. 88. 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
  89. 89. 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

Editor's Notes

  • CSS : 70 KBytes
    Fonts: 130 KBytes
    HTML: 27 KBytes
    Image: 948KB
    Javascript: 448KB
    Video: 1678KB
  • The computation of the UDP checksum is defined in :


    R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
  • 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
  • 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.
  • 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.
  • MSL in IP networks : 120 seconds
  • MSL in IP networks : 120 seconds
  • Don’t forget that TCP’s acknowledgements are cumulative.
  • See e.g.

    RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
  • Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
  • MSL in IP networks : 120 seconds
  • Most TCP implementations today have fixes for those problems. We will discuss them later.
  • Most TCP implementations today have fixes for those problems. We will discuss them later.
  • 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
  • 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.
  • MSL in IP networks : 120 seconds
  • MSL in IP networks : 120 seconds
  • 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.
  • See

    P. Karn, C. Partridge, Improving round-trip time estimates in reliable transport protocols, Proc. ACM SIGCOMM87, August 1987
  • 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.
  • See e.g.

    RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.

  • RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.

  • RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
  • 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.
  • Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
  • Description

    Slides supporting the "Computer Networking: Principles, Protocols and Practice" ebook. The slides can be freely reused to teach an undergraduate computer networking class using the open-source ebook.

    Transcript

    1. 1. Week 7 HTTP/2 UDP and TCP
    2. 2. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
    3. 3. HTTPS versus HTTP
    4. 4. Today's web pages Source: httparchive.org
    5. 5. How many HTTP requests per page ? Source: httparchive.org
    6. 6. 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
    7. 7. How many TCP connections per page ? Source: httparchive.org
    8. 8. A faster web • How could we speed up the web ? • What is our objective ?
    9. 9. How to improve web ? • What can be done to improve web performance ? • Reduce unnecessary data transfers • If-Modified-Since
    10. 10. Reducing latency ? • How can we reduce latency ? • Move server closer to client – CDN
    11. 11. Web proxies
    12. 12. Improving HTTP
    13. 13. 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
    14. 14. HTTP/2.0 • Key changes from HTTP/1.x • Binary protocol instead of ASCII • Support multiple datastreams over the underlying transport connection
    15. 15. 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
    16. 16. HTTP/2.0
    17. 17. HTTP/2 versus HTTP/1 Source: https://hpbn.co/http2/
    18. 18. 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 ?
    19. 19. 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)
    20. 20. HTTP/2 streams Source: https://hpbn.co/http2/
    21. 21. 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
    22. 22. Server Push Source: https://hpbn.co/http2/
    23. 23. Agenda • Internet applications • Web • UDP • TCP
    24. 24. Transport layer • Objectives • Improve service provided to applications • Multiplexing Physical Physical Datalink Datalink Network Network Physical Datalink Network Segments Transport Transport
    25. 25. Network service • Characteristics • Connectionless • Unreliable • Maximum packet size Physical Physical Datalink Datalink Packets Network Network Physical Datalink Network Packets
    26. 26. 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
    27. 27. UDP ports Server Client Source port : 1234 Destination port: 5678 Request Response Source port : 5678 Destination port: 1234
    28. 28. 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
    29. 29. UDP Applications • Among these applications, which typically use UDP ?
    30. 30. Usage of UDP • Request-response applications • DNS, RPC, NFS, .. • Applications with short delay • Games • Multimedia transfer • Voice over IP • Video over IP
    31. 31. 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
    32. 32. 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 ?
    33. 33. https://spoofer.caida.org/country_stats.php
    34. 34. 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
    35. 35. 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
    36. 36. 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
    37. 37. 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 ?
    38. 38. 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
    39. 39. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
    40. 40. TCP • Service provided • Connection-oriented • Reliable • No losses, no errors, no duplications • Bytestream
    41. 41. 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
    42. 42. 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
    43. 43. 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
    44. 44. 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
    45. 45. TCP FSM Init SYN RCVD SYN Sent Established ?SYN / !SYN+ACK !SYN ?SYN+ACK / !ACK ?SYN / !SYN+ACK ?ACK !SYN ?ACK
    46. 46. 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)
    47. 47. 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
    48. 48. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
    49. 49. 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 ?
    50. 50. 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
    51. 51. 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
    52. 52. 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 ?
    53. 53. 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
    54. 54. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release
    55. 55. 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
    56. 56. 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
    57. 57. Agenda • Internet applications • Web • UDP • TCP • Connection establishment (more details) • Reliable data transfer • Connection release
    58. 58. 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 ?
    59. 59. 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
    60. 60. 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 ?
    61. 61. 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
    62. 62. 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
    63. 63. 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
    64. 64. 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
    65. 65. 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
    66. 66. 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 ?
    67. 67. 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
    68. 68. TCP options • Maximum Segment Size • Selective acknowledgements • Window Scale • Timestamps • Multipath TCP • ...
    69. 69. 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
    70. 70. 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
    71. 71. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer (more details) • Connection release
    72. 72. 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
    73. 73. Retransmission timer • How to compute it ? • round-trip-time may change frequently during the lifetime of a TCP connection
    74. 74. 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)|
    75. 75. 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")
    76. 76. 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")
    77. 77. TCP Timestamps • Two different roles • Help in rtt measurements • Protection Against Wrapped Sequence Numbers (PAWS)
    78. 78. 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
    79. 79. 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
    80. 80. 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 ?
    81. 81. 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
    82. 82. Nagle algorithm • A new data segment can be sent if either • This is a full segment (MSS bytes) • There are no unacknowledged bytes
    83. 83. Observed IP packets http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml
    84. 84. 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 !
    85. 85. 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
    86. 86. 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
    87. 87. Agenda • Internet applications • Web • UDP • TCP • Connection establishment • Reliable data transfer • Connection release (more details)
    88. 88. 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
    89. 89. 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

    Editor's Notes

  • CSS : 70 KBytes
    Fonts: 130 KBytes
    HTML: 27 KBytes
    Image: 948KB
    Javascript: 448KB
    Video: 1678KB
  • The computation of the UDP checksum is defined in :


    R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
  • 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
  • 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.
  • 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.
  • MSL in IP networks : 120 seconds
  • MSL in IP networks : 120 seconds
  • Don’t forget that TCP’s acknowledgements are cumulative.
  • See e.g.

    RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
  • Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
  • MSL in IP networks : 120 seconds
  • Most TCP implementations today have fixes for those problems. We will discuss them later.
  • Most TCP implementations today have fixes for those problems. We will discuss them later.
  • 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
  • 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.
  • MSL in IP networks : 120 seconds
  • MSL in IP networks : 120 seconds
  • 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.
  • See

    P. Karn, C. Partridge, Improving round-trip time estimates in reliable transport protocols, Proc. ACM SIGCOMM87, August 1987
  • 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.
  • See e.g.

    RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.

  • RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.

  • RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
  • 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.
  • Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
  • More Related Content

    Related Books

    Free with a 30 day trial from Scribd

    See all

    Related Audiobooks

    Free with a 30 day trial from Scribd

    See all

    ×