1 / 22

Enhancing Web Connections Through TCP Optimization for Improved Performance

Discover the intricacies of TCP in contemporary web connections, focusing on HTTP1.1, handshake overheads, persistent connections, security attacks, and efficient deployment strategies for optimal performance. Learn about challenges, attack models, and solutions for a seamless browsing experience.

harley
Télécharger la présentation

Enhancing Web Connections Through TCP Optimization for Improved Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP for today’s Web

  2. Connections today • Web-page > 300KB • but objects are small 7.5KB -2.4KB [25] • lots of small objects in a page. Implication: TCP Handshake == 10%-30% penalty

  3. Add data into Handshake SYN-Flag SYN/ACK-Flag ACK-Flag+Data Let’s talk

  4. How about HTTP1.1 • What is HTTP1.1 • Persistent keep alive • Re-use old connections so no more TCP handshakes • But … • browser tries to be fast opens multiple TCP connections (limits reuse) • Domain sharding -- place resource on different domains to further increases parallelism (so forced to use diff connections). • MB terminate idle conns to reduce state --> so persis con no longer persistent. • mobile devs shut down conns to conserve power

  5. Status of HTTP1.1 • 92% conn use HTTP1.1 • But still Handshake has 5-7% overhead in general • For first use of connect, overhead is 8-27% • Chrome always uses HTTP1.1 • But 33% of conn use new TCP

  6. New Security Attacks SYN-Flag+ Data SYN/ACK-Flag+ Data ACK-Flag+Data

  7. New Attacks: SYN Flood Server does a lot processing And gets overloaded Make up a false ip address Send a bunch of SYN pks with data SYN-Flag+ Data Note: Since you used a fake address, the response from the server don’t come to you, so you don’t maintain state or devote resources

  8. New Attacks: Reflection Use host B’s IP as source Send a bunch of SYN pks with data SYN-Flag+ Data Note: Every server responds to host B with a flood of packet. Host B gets attacked. Once against you don’t devote any resources on your machine to do attack. And since response is larger than syn-flag+data it is better than you attack direction

  9. Attack Model • Attacks work because: • Attacker can spoof SRC IPs. • To prevent this: • TFO adds a cookie to the protocol • Client must include cookie in the handshake • The cookie is an encrypted version of source IP • Source IP encrypted with the server’s private key • Server unencrypts cookie and compares

  10. System Assumptions Acceptable Changes: • 1. symmetric crypto • (can be done in fast path) but no asymmetric. • 2. soft state • (can't keep permanent state-- scale issues) • 3. minor App changes • Don’t want to prevent adoption

  11. Add Cookie to the First Handshake Let’s use TFO Here’s a cookie for next time SYN-Flag+TFO-Option SYN/ACK-Flag+ Cookie ACK-Flag+Data

  12. Second Connection to Same server benefits We are using FTO: here’s a cookie for proof. SYN-Flag+Cookie+Data SYN/ACK-Flag+ Data ACK-Flag+Data

  13. Second Connection to Same server benefits SYN-Flag+Cookie+Data SYN/ACK-Flag ACK-Flag+Data

  14. Attacks Revisited • Reflection • To get cookie must compromise host or network • If you can then you don’t need reflection • SYN Flood • We limit the number TFO connections • So server is still always willing to accept regular TCP connections

  15. Deployment Issues • Middleboxes are HORRIBLE • They drop new TCP options • NAT changes IP addresses so cookies can’t work

  16. Deployment Issues: Load Balancers LoadBalancer

  17. Deployment Issues: Load Balancers LoadBalancer All servers need to share the same key so TFO can work. So, you may need to also change the keys more frequently

  18. Lessons • A webpage === lots of small objects • Harder to ameliorate overheads • TCP Handshake overhead • 2 RTT  Loss detection • Most common loss pattern in WAN • Last packet in small connection • Use redundancy (FEC) to overcome this. • Eliminate Handshake overhead • Send packet during the handshake • Insert secret cookie in handshake to eliminate attacks

More Related