220 likes | 312 Vues
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.
E N D
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
Add data into Handshake SYN-Flag SYN/ACK-Flag ACK-Flag+Data Let’s talk
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
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
New Security Attacks SYN-Flag+ Data SYN/ACK-Flag+ Data ACK-Flag+Data
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
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
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
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
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
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
Second Connection to Same server benefits SYN-Flag+Cookie+Data SYN/ACK-Flag ACK-Flag+Data
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
Deployment Issues • Middleboxes are HORRIBLE • They drop new TCP options • NAT changes IP addresses so cookies can’t work
Deployment Issues: Load Balancers LoadBalancer
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
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