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.
HTTP (Hyper Text Transfer Protocol) regulates simple conversations between clients and servers, like placing an order in a restaurant. However, there are some gotchas like the server having short term memory requiring the client to repeat themselves. But don’t despair, HTTP helps reduce confusion with standardized requests and responses. By following these conventions developers are able to create amazing things not possible with just POST requests and 200 OK responses.
In this talk Adrian Cardenas will review examples of clients and servers, as well as the stateless nature of HTTP. He will then go into more detail about headers discussing request methods, and common request headers. Good conversations cannot be one sided, so he will also cover common response headers as well as useful response status codes.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
HTTP has a new specification (two actually) and has received a major overhaul of some of it's internals. While the protocol itself has not changed much, the transfer mechanism and other underlying systems have been completely re-worked. Adrian will expand on what has and has not changed, how to make the best use of it, and how to transition to the new standard if you need to.
O'Reilly Fluent Conference: HTTP/1.1 vs. HTTP/2Load Impact
Load Impact founder Ragnar Lönn presented the results from his study on HTTP/2 at the O'Reilly Fluent Conference 2016 in San Francisco. If you'd like to chat with us about HTTP/2, reach out on Twitter: @LoadImpact.
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.
HTTP (Hyper Text Transfer Protocol) regulates simple conversations between clients and servers, like placing an order in a restaurant. However, there are some gotchas like the server having short term memory requiring the client to repeat themselves. But don’t despair, HTTP helps reduce confusion with standardized requests and responses. By following these conventions developers are able to create amazing things not possible with just POST requests and 200 OK responses.
In this talk Adrian Cardenas will review examples of clients and servers, as well as the stateless nature of HTTP. He will then go into more detail about headers discussing request methods, and common request headers. Good conversations cannot be one sided, so he will also cover common response headers as well as useful response status codes.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
HTTP has a new specification (two actually) and has received a major overhaul of some of it's internals. While the protocol itself has not changed much, the transfer mechanism and other underlying systems have been completely re-worked. Adrian will expand on what has and has not changed, how to make the best use of it, and how to transition to the new standard if you need to.
O'Reilly Fluent Conference: HTTP/1.1 vs. HTTP/2Load Impact
Load Impact founder Ragnar Lönn presented the results from his study on HTTP/2 at the O'Reilly Fluent Conference 2016 in San Francisco. If you'd like to chat with us about HTTP/2, reach out on Twitter: @LoadImpact.
After 16 years of solid use, the HTTP protocol finally got a major update this year. HTTP is the standard that defines how computers communicate over the Internet, and had not changed since 1999. The modern web, however, has become much more complex and HTTP/2 helps to address this brave new world.
Watch the webinar on demand: https://www.nginx.com/resources/webinars/whats-new-in-http2/
Internet of Things Presentation
ในการ อบรม Android Control Hardware and Arduino IoT
โดย Adun Nantakaew บริษัท Soft Power Group
email: info@softpowergroup.net
Tel : 081-6452400
http://softpowergroup.net/%E0%B8%AA%E0%B8%AD%E0%B8%99-arduino/
HTTP/2, roughly speaking a formalization of Google's SPDY, is the successor to our beloved HTTP/1.1 protocol. We’ll look at the state of SPDY and HTTP/2, try to understand how they try to be faster, when they might not be and why it makes sense to cater to the machine instead of humans.
TSC Summit #4 - Howto get browser persitence and remote execution (JS)Mikal Villa
A simple PoC shown how insecure random http proxies are. And how easy you can trick people into traps.
Disclaimer: No data collected under the PoC was saved after the presentation, and everything was removed from the user browsers without any harm or stealing of information or any criminal activity at all.
For successful implementation of distributed systems, flexible and scalable messaging layer is one of the most important components. Setting a static messaging infrastructure and provisioning it manually doesn’t fit well in the cloud-centric development model most organisations are adopting lately. The EnMaase project (http://enmasse.io/) provides an open source solution for deploying your own messaging infrastructure in the cloud. It’s based on proven standards and technologies like AMQP and Kubernetes and provides all the features you’d need, from multi-tenancy to simple management and monitoring. This session will cover EnMaase project in details, providing details on the architecture, messaging concepts supported and ways to set and configure it.
After 16 years of solid use, the HTTP protocol finally got a major update this year. HTTP is the standard that defines how computers communicate over the Internet, and had not changed since 1999. The modern web, however, has become much more complex and HTTP/2 helps to address this brave new world.
Watch the webinar on demand: https://www.nginx.com/resources/webinars/whats-new-in-http2/
Internet of Things Presentation
ในการ อบรม Android Control Hardware and Arduino IoT
โดย Adun Nantakaew บริษัท Soft Power Group
email: info@softpowergroup.net
Tel : 081-6452400
http://softpowergroup.net/%E0%B8%AA%E0%B8%AD%E0%B8%99-arduino/
HTTP/2, roughly speaking a formalization of Google's SPDY, is the successor to our beloved HTTP/1.1 protocol. We’ll look at the state of SPDY and HTTP/2, try to understand how they try to be faster, when they might not be and why it makes sense to cater to the machine instead of humans.
TSC Summit #4 - Howto get browser persitence and remote execution (JS)Mikal Villa
A simple PoC shown how insecure random http proxies are. And how easy you can trick people into traps.
Disclaimer: No data collected under the PoC was saved after the presentation, and everything was removed from the user browsers without any harm or stealing of information or any criminal activity at all.
For successful implementation of distributed systems, flexible and scalable messaging layer is one of the most important components. Setting a static messaging infrastructure and provisioning it manually doesn’t fit well in the cloud-centric development model most organisations are adopting lately. The EnMaase project (http://enmasse.io/) provides an open source solution for deploying your own messaging infrastructure in the cloud. It’s based on proven standards and technologies like AMQP and Kubernetes and provides all the features you’d need, from multi-tenancy to simple management and monitoring. This session will cover EnMaase project in details, providing details on the architecture, messaging concepts supported and ways to set and configure it.
WebCamp Ukraine 2016: Instant messenger with Python. Back-end developmentViach Kakovskyi
Lessons learnt by the development of Instant Messenger with Python 2 and Twisted.
About the project:
* 100 000+ connected users
* 100+ nodes
* REST API for integration
Expected audience: developers who are new to development of Instant Messenger or folks who develop a system from scratch.
All the stuff based on own production experience.
WebCamp 2016: Python. Вячеслав Каковский: Real-time мессенджер на Python. Осо...WebCamp
Доклад построен на опыте разработки платформы реал-тайм мессенджера с характеристиками:
* 100 000+ одновременно подключенных пользователей
* 100+ серверов
* REST API для ботов
Структура доклада:
* Зачем разрабатывать мессенджер?
* Актуальные протоколы обмена сообщениями
* Архитектурные подходы к разработке мессенджера
* Библиотеки и инструменты
* Проблемы и подводные камни
USENIX LISA15: How TubeMogul Handles over One Trillion HTTP Requests a MonthNicolas Brousse
TubeMogul grew from few servers to over two thousands servers and handling over one trillion http requests a month, processed in less than 50ms each. To keep up with the fast growth, the SRE team had to implement an efficient Continuous Delivery infrastructure that allowed to do over 10,000 puppet deployment and 8,500 application deployment in 2014. In this presentation, we will cover the nuts and bolts of the TubeMogul operations engineering team and how they overcome challenges.
Zero Downtime Architectures based on JEE platform. Almost every big enterprise with online business tries to design its applications in a way that they are always online. But is it also the case when we upgrade the database cluster? When we switch the whole data center? Based on a customer project we try to present common architecture principles that enable you to do all this without any service interruption and the most important: without any stress.
Uber mobility - High Performance NetworkingDhaval Patel
Speakers: Ganesh Srinivasan & Minh Pham (Uber), Jim Roskind (Neumob), Makarand Dharmapurikar & Eric Anderson (Google), and Karthik Ramgopal (LinkedIn)
Networking is one of the most important, yet often underserved aspects of any mobile application. The latency and bandwidth of mobile networks can vary greatly between cities and even within cities, ranging from broadband LTE speeds to performance that feels more like a 300 baud modem.
You can read more about Uber Mobility here : https://www.uber.com/p/uber-mobility/
The web has dramatically evolved over the last 20+ years, yet HTTP - the workhorse of the Web - has not. Web developers have worked around HTTP's limitations, but:
--> Performance still falls short of full bandwidth utilization
--> Web design and maintenance are more complex
--> Resource consumption increases for client and server
--> Cacheability of resources suffers
HTTP/2 attempts to solve many of the shortcomings and inflexibilities of HTTP/1.1
Similar to SPDY and What to Consider for HTTP/2.0 (20)
2. Why am I here?
SPDY started over 3 years ago
Reduced latency is now proven
It's better for the network
Let's focus on interoperability
3. Who is using SPDY?
● Google Chrome &
All Google Web Properties
● Mozilla Firefox
● Twitter
● Amazon Silk
● Others: Cotendo, Strangeloop, iPhone client, Apache mod-spdy, nginx
beta, jetty, netty, libraries in python, node.js, erlang, ruby, go, and C
4. How did SPDY come to be?
wanted reduced web page latency for users
5. What SPDY is Not
A transport layer protocol (like TCP)
Rocket Science
Cheap Compression Tricks
6. What SPDY is
An amalgam of well-known ideas based on
performance data:
multiplexing
prioritization
compression
server push
transparent to HTTP app servers
deployable today
7. Real deployment has shown also
● Better for the network
● Better for Mobile
HTTP is not just for HTML
Battery life matters
8. Background: What is a WebPage?
● 86 resources
● 13 hosts
● 800+KB
● only 66% compressed (top sites are ~90%
compressed)
14. 1. Multiplexing
● Small, fixed length frames
● Fully interleaved streams
● Streams can be created by either endpoint
with zero round trips.
● Many implementors have remarked it's easy
to implement!
17. 2. Prioritization
● Not all requests are equal!
● Failure to prioritize is actually slower
● Must consider two metrics:
○ Time to first render
○ Overall Page Load Time
● SPDY allows client-specified priorities with
server best effort to deliver
18. 3. Header Compression
● SPDY uses stateful
compression across
requests
● Using zlib,
achieves 85-90%
compression
● Don't care if compressor
is zlib; only care about
session state.
● Must be mandatory
29. Other results
● Firefox confirmed Chrome results
● Google recently reported that SPDY over
SSL is now faster than HTTP without SSL
● BoostEdge paper confirms Google numbers
● need vendors to publish more!
30. Deployment
A Process of Elimination
● Transport choices: TCP or UDP
○ Chose TCP
● Port choices: 80 or 443
○ But both are taken!
● Chrome test shows usability of port 80 for non HTTP
protocols is <75%.
○ Using port 80 makes SPDY like Pipelining.
● Port 443 is the only untampered port.
● Other ports: blocked by firewalls
31. Pause - That was the Big Picture
"Better is the enemy of good"
● The aforementioned items are the non-
controversial parts of SPDY.
● HTTP/2.0 should take those concepts.
● Minutiae doesn't matter:
○ exact framing syntax
○ exact compression algorithm
● Stay Focused on the Big Picture!
33. Why not SCTP?
Multiplexing over a single TCP stream does
have one element of head-of-line blocking.
But SCTP has problems:
● Not available on most platforms
● Requires administrative privs to install (so it
can't be bundled easily with browser installs)
● Incompatible with NAT on today's internet.
34. Why not Pipelining?
Pipelining was introduced a decade ago.
● Wasn't deployable due to intermediaries that didn't
handle it properly.
● It has complex head-of-line blocking problems (hanging
GETs)
● Firefox team list of heuristics is huge. SPDY was easier
to build than pipelining.
● Counterpoint: mobile uses pipelining. Does it work?
35. Why 1 Connection?
● More efficient for network, memory use, and
server scalability; better compression.
● Don't have to wait for a handshake to
complete before sending a request.
● Doesn't encourage Buffer bloat. (Jim
Gettys)
● Lets the transport do what it does best.
● Would like to see more research here.
37. Mobile is Different
● New client-side problems
○ Battery life constraints
○ Small CPUs (changing fast!)
● New Network Properties
○ Latency from 150 - 300ms per Round Trip
○ Bandwidth 1-4Mbps
● New use cases
○ Mobile Web Browsers are 1st generation
■ So web browsing sucks
○ Everyone uses Apps w/ REST APIs anyway
38. SPDY and Mobile
● Fewer connections/bytes/packets reduces
transmit requirements of radio
● Mobile connection management is different
due to NAT and in-and-out networks.
○ Can't use TCP Keepalives
○ PING frame detects closed conns quickly
● Header compression minimizes upstream
sends
● 1 conn per domain minimizes tcp-level
40. Don't make things "optional"
● Optional features are disabled features.
e.g. pipelining.
● Optional features are buggy.
e.g. absolute URIs fail on many HTTP/1.1 servers.
● Feature detection often takes a round-trip.
e.g. does it support a compressed request?
● Proxies will tamper with option negotiation.
e.g. Accept-EnXcoding
41. Security
I often hear that security is
difficult/expensive/costly or unwanted.
I've NEVER heard this complaint from a user.
I've ONLY heard this complaint from proxy and
server implementors.
Could it be that users just expect it to be
secure?
42. What Security Can HTTP/2.0
Provide?
● Security is accomplished across the stack, not at a
single layer. But HTTP does play a role.
● Requiring SSL with HTTP/2.0 will:
○ Protect the user from eavesdroppers (firesheep!)
○ Protect from content tampering
○ Protect the protocol for future extensions
○ Authenticate servers
43. Insecure Protocols Hurt Users
Without integrity & privacy, you enable anyone
to:
○ record data about you
○ inject advertisements into your content
○ prevent access to certain sites
○ alter site content
○ limit your bandwidth (for any reason)
Is this what the user wants?
44. Insecure Protocols Enable
Transparent Proxies
● Transparent proxies are proxies that you
didn't opt-in to
○ As a site operator, they can alter your content
○ As a user, they can alter your web experience
● Transparent proxies are to blame for many
of our protocol woes:
○ Inability to fix HTTP/1.1 pipelining
○ Turning off compression behind the user's back
● They are easy to deploy, however...
45. SSL is not Expensive
● Twitter and Google rolled out with zero
additional hardware.
● Bulk encryption (RC4) is basically free
● Handshakes are a little expensive, but <1%
of CPU costs
● Certificates are free.
● SPDY + SSL is faster than HTTP.
46. Is an insecure protocol legal
anymore?
● Privacy laws in the US & EU make those
that leak private information liable for the
losses
● Should web site administrators need to know
how HTTP works in order to obey basic
laws?
48. We have distinct use cases
● End User HTTP
○ targets consumers and Internet User needs
● BackOffice HTTP
○ for those using HTTP in behind their own firewalls
● Caching HTTP (also corp firewall HTTP)
○ For corporate environments or organizations sharing
a common cache
○ May not be a separate protocol, but lets make it
work explicitly.
49. End User HTTP
● Optimized for the Internet Consumer.
● Features:
○ Always secure (safe to use in the Cafe)
○ Always compressed
○ Always fast
50. BackOffice HTTP
● Used for backoffice server infrastructure,
already behind your own firewalls.
● Features:
○ Not implemented by browsers
○ Makes SSL optional
○ Makes Compression optional
51. Caching HTTP
● Used by corporations with filtering firewalls
or those that want to have an external cache
● Features:
○ User opts-in. Never transparent.
○ SSL to the proxy; proxy brokers the request to origin
○ Respects HSTS
○ Reduces need for SSL MITM