This presentation was made for the Transport Area discussion on 04/01/11 in Prague. Although SPDY is an application layer protocol, this talk focuses on how HTTP impacts the transport layer and what SPDY can do to improve it.
Talk about HTTP/2, how it has been deployed, did it meet its promises and how QUIC is going to attempt to fix some of the remaining issues. Held in FOSDEM at Febyrar 2017.
A technical description of http2, including background of HTTP what's been problematic with it and how http2 and its features improves the web.
See the "http2 explained" document with the complete transcript and more: http://daniel.haxx.se/http2/
(Updated version to slides shown on April 13th, 2016)
Talk about HTTP/2, how it has been deployed, did it meet its promises and how QUIC is going to attempt to fix some of the remaining issues. Held in FOSDEM at Febyrar 2017.
A technical description of http2, including background of HTTP what's been problematic with it and how http2 and its features improves the web.
See the "http2 explained" document with the complete transcript and more: http://daniel.haxx.se/http2/
(Updated version to slides shown on April 13th, 2016)
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
Yet another JSON RPC library for JavaScript? In my talk, I will explain why I've created Mole RPC, show architectural patterns which were useful. I will show you what modern features of JavaScript helped me with API design.
Learn about HTTP/2 and its relationship to HTTP 1.1 and SPDY. Understand core features and how they benefit security and browser efficiency. More that a "what's new" this talk will leave you with an understanding of why choices in HTTP/2 were made. You'll leave knowing what HTTP/2 is and why it is better for clients and servers.
Reaching 5 Million Messaging Connections: Our Journey with KubernetesConnected
Learn how we built a high-scale messaging service and state store on Kubernetes. The solution supports millions of persistent, concurrent connections; enables tens of thousands of messages per second; is globally addressable; stores millions of states; and responds with minimal latency (<250ms).
To evaluate build approaches, the team split into Makers & Breakers. Makers developed the solution stack while Breakers focused on repurposing Locust, a high-scale load testing framework, to simulate behavior. Leveraging the flexibility of Kubernetes, we were able to scale the stack and solve blockers on the path to a viable solution. Blockers included ingress, file descriptors, service discovery and resource limits. The experience was deeply educational, generating key learnings for developers tasked with building a scaled solution on top of Kubernetes.
In Jan 2012, Zynga was kind enough to invite me to speak at their SF office. These are the slides I presented; its much of the same SPDY content, although starting to focus more on mobile.
NetScaler Web 2.0 Push technology scales Comet or Reverse Ajax applications that depend on long running idle client connections. It offloads server load by handling all the client connections on the NetScaler and publishing a REST API for the server application to send periodic updates.
The SPDY Protocol is likely going to be the successor of http. This short talk summarizes the most important points and includes a demo on how to migrate a Wordpress blog on httpd.
HTTP/2 for Developers: How It Changes Developer's Life?
by Svetlin Nakov (SoftUni) - http://www.nakov.com
jProfessionals Conference - Sofia, 22-Nov-2015
Key new features in HTTP/2
- Multiplexing: multiple streams over a single connection
- Header compression: reuse headers from previous requests
- Sever push: multiple parallel responses for a single request
- Prioritization and flow control: resources have priorities
Yet another JSON RPC library for JavaScript? In my talk, I will explain why I've created Mole RPC, show architectural patterns which were useful. I will show you what modern features of JavaScript helped me with API design.
Learn about HTTP/2 and its relationship to HTTP 1.1 and SPDY. Understand core features and how they benefit security and browser efficiency. More that a "what's new" this talk will leave you with an understanding of why choices in HTTP/2 were made. You'll leave knowing what HTTP/2 is and why it is better for clients and servers.
Reaching 5 Million Messaging Connections: Our Journey with KubernetesConnected
Learn how we built a high-scale messaging service and state store on Kubernetes. The solution supports millions of persistent, concurrent connections; enables tens of thousands of messages per second; is globally addressable; stores millions of states; and responds with minimal latency (<250ms).
To evaluate build approaches, the team split into Makers & Breakers. Makers developed the solution stack while Breakers focused on repurposing Locust, a high-scale load testing framework, to simulate behavior. Leveraging the flexibility of Kubernetes, we were able to scale the stack and solve blockers on the path to a viable solution. Blockers included ingress, file descriptors, service discovery and resource limits. The experience was deeply educational, generating key learnings for developers tasked with building a scaled solution on top of Kubernetes.
In Jan 2012, Zynga was kind enough to invite me to speak at their SF office. These are the slides I presented; its much of the same SPDY content, although starting to focus more on mobile.
NetScaler Web 2.0 Push technology scales Comet or Reverse Ajax applications that depend on long running idle client connections. It offloads server load by handling all the client connections on the NetScaler and publishing a REST API for the server application to send periodic updates.
The SPDY Protocol is likely going to be the successor of http. This short talk summarizes the most important points and includes a demo on how to migrate a Wordpress blog on httpd.
SPDY - http reloaded - WebTechConference 2012Fabian Lange
The SPDY Protocol is likely going to be the successor of http. This short talk summarizes the most important points and includes a demo on how to migrate a Wordpress blog on httpd.
Cleaning Up the Dirt of the Nineties - How New Protocols are Modernizing the WebSteffen Gebert
About HTTP/2, QUIC, and Multipath TCP.
Download of PDF file recommended (Slideshare screws backgrounds up)
Talk at the TYPO3camp Vienna
Vienna, Austria, 06.-08.05.2016
HTTP is one of the most widely used protocols in the world.
The version of HTTP 1.1, used to this day, was developed and described 18 years ago - 1999.
With the increasing complexity of web applications, the capabilities of HTTP 1.1 are already insufficient to provide increased demands on performance and responsiveness.
So in order to meet new requirements, HTTP must evolve. HTTP 2.0 is designed to make web applications faster, simple and reliable.
In this report I will tell about
- drawbacks of HTTP 1.1 and why we need a new version of HTTP.
- which advantages HTTP/2 offers in comparison with the previous version?
- how the new protocol affected the new version of SERVLET 4.0 and how we can use it.
Communication over the kinds of Data-Links used for unmanned vehicles presents important challenges dues to the low bandwidth, intermittent, and lower reliability of these links. Classic network protocols such as TCP do not operate well in this environment forcing application developers to implement their own reliability and session management. This presentation describes he issues and alternatives.
Similar to SPDY, TCP, and the Single Connection Throttle (20)
3. State of the Web Page
An average Web Page Consists of:
~44 resources
~7 hosts
~320KB
~66% compressed (top sites are ~90% compressed)
Note: HTTPS is < 50% compressed.
Incremental improvements to HTTP don't move the needle
Transparent proxies change the content.
Example: pipelining
Example: stripped "Accept-Encoding" headers
we can't even improve "negotiated" compression!
4. Quick SPDY Background
Goals:
Faster web page downloads
Always secure
Deployable
Open
Features (No rocket science here!)
Single-connection, Multiplexed, prioritized streams
Mandatory header compression
Supports server-push
SPDY is Basic Networking "blocking and tackling"
Use fewer connections
Send fewer bytes
11. Throttle #1: CWND
Problem:
Server-side slow start limits server to N packets. (in flux)
Workaround:
Use more client connections.
Update server to go beyond spec.
SPDY can use a cookie based cwnd.
Note:
HTTP's per-domain cwnd is currently ~24 (6*4).
draft-ietf-tcpm-initcwnd-00.txt helps
13. Throttle #2: Receive Windows
Problem:
Some clients set initial rwnd to 5840 bytes (4 pkts)
Trumps larger cwnd on servers.
Patch just shipped this month in linux mainline
Workaround:
Use more client connections.
15. Throttle #3: Intermediaries
Problem:
"Just a bug"... but... Intermediaries can (and do) tamper.
window scale enables large receive windows.
Workaround:
Use more client connections.
Client Side Server Side
// Client wants window // Server recvs window
// scaling 6. // scale 3. Someone
// tampered with this.
SYN -> w=5840, ws=6 SYN -> w=5840, ws=3
// Client receives server // Server sends its own
// ws as sent. // ws of 6.
SYNACK <- w=5840, ws=6 SYNACK <- w=5840, ws=6
// going to be slow....
16. Throttle #4: Congestion Control
Problem:
Congestion detection decreases the send rate.
But congestion signals can be erroneous.
Applied to the connection, not the path:
1 connection: single packet loss cuts send rate by N
(typically 0.5/0.7).
6 connections: single packet loss cuts send rate by
1/6*(1/N) == (~1/9th to 1/12th)
Workaround:
Use more client connections.
17. Too Obsessed With 1 Connection?
Could we use 2? 3?
Sure, but it neutralizes many of our benefits.
Disadvantages of multiple connections:
Sharing state across connections is hard.
Server farms would be required to do sticky load
balancing
Compression worsens (we use stateful compression)
Prioritization becomes impossible
Server push difficult
But it shouldn't be this hard...
19. What's Next?
Before SPDY, we could blame the app layer (HTTP).
With SPDY, we're on the verge of proving that the transport
is the new bottleneck.
TCP needs to address 2 performance obstacles:
Data in initial handshake.
Single connection taxes.
TCP needs to address security
Both Server Auth & Encryption
(Sorry I didn't have time to discuss in this talk!)
How can we iterate on the transport when it is buried in the
kernel? Can we auto-update the network stack?