The PHP podcast where everyone chimes in.

Originally aired on

June 16th, 2016

047: All About HTTP/2

HTTP/1.1 will eventually be replaced by HTTP/2 so it's important for us PHP nerds to know all about the latest version of the HTTP protocol that's already running some of the internet's biggest websites. We discuss the things we need to know to start using HTTP/2 in our next PHP app.

We also go briefly off topic to discuss the status of PHP 7.1 and the ramsey/uuid lib.

with


All About HTTP/2 Show Summary


Why move away from HTTP/1.1?

  • We have stretched the limits of HTTP/1.1
  • Pressure/innovation from Google:
    • Google developed its own SPDY protocol
    • SPDY was later folded into the HTTP/2 specification
    • Some devices/browsers still support only SPDY
  • Improvements in efficiency and security

What are the usage stats for HTTP/2?

  • The big sites (Google, Facebook, Twitter) are all using HTTP/2 where possible
  • Some cloud providers e.g: CloudFlare are already using HTTP/2 either by default or as an option
  • ~60% of browsers support HTTP/2
  • All browser implementations effectively require TLS for HTTP/2 communication
  • Due to these support/requirements constraints, a significant proportion of traffic falls back to HTTP/1.1
  • One of the barriers to greater adoption of HTTP/2 is persuading users to switch on TLS
  • TLS unlocks the benefits of HTTP/2, but also:
    • It offers improved security over SSL
    • Google uses it as a ranking signal
    • TLS certificates are now available for free from Let's Encrypt
    • HTTP/2 negates a lot of the performance overhead associated with encrypted HTTP traffic
  • HTTP/2 is in use by 8.2% of websites surveyed by w3techs as of June 2016

How does PHP help us to implement HTTP/2?

  • cURL support for handling server push will be part of PHP 7.1
  • There is an open RFC for adding support for HTTP/2 to PHP's CLI server
  • This will introduce some additional dependencies: nghttp2 and OpenSSL

What is multiplexing in the context of HTTP/2?

  • Multiplexing allows us to interleave frames containing responses relating to multiple requests using a single connection
  • HTTP/1.1 requires a separate TCP connection for each request/responses
  • There are some limits on this:
    • ngnix defaults to 128 streams per connection
    • Chrome defaults to 256 streams per connection

What do HTTP/2 request/responses look like?

  • From a user-level perspective, pretty much the same as a HTTP/1.1 request/responses
  • HTTP/2 requests still use HTTP verbs. Requests and responses still have a head and a body, etc
  • At a lower level:
    • Header and data frames are separated
    • HTTP/2 is a binary protocol
    • Frames will be multiplexed
  • Unless you are directly writing a client or server, little will change from your perspective
  • If you are writing your own client or server, h2spec can help you with this
  • More info on the low-level details is in RFC 7540

How does server push work?

  • The server can send a frame called a push promise
  • The client can choose to accept or decline the asset
  • If the client accepts, the asset will be delivered as if it had been requested by the client and cached for future use
  • This could be used to help browsers to start pre-fetching/pre-caching assets such as javascript, css, images and web fonts before starting to parse the HTML of a web page, for example.

Do optimization techniques we use in HTTP/1.1 apply to HTTP/2?

  • Domain Sharding is broadly rendered irrelevant by multiplexing. Sharding resources across subdomains probably makes performance worse in HTTP/2 as it increases the number of DNS lookups that must be performed (and potentially TCP connections that must be opened) to complete a request.
  • CSS Sprites may still be a valid technique
  • If using GZip compression, minification is of dubious value anyway
  • HTTP/2 may allow us to reduce the amount of pre-processing we need to do on css/js in future
  • Each technique will need to be evaluated in isolation. HTTP/2 is sufficiently new that best practices are still not fully defined

If my CDN uses HTTP/2, does it help performance if my origin also serves HTTP/2

  • It will benefit communication between the origin and cache, but how substantial this benefit is depends on how often the cache fetches from the origin
  • The largest performance benefit is to be found using HTTP/2 between the CDN and the end-user
  • HTTP/2-enabled cache may still fetch from the origin over HTTP/1.1

Can I just enable HTTP/2 and immediately start seeing performance benefits?

  • Some performance benefits will apply immediately (e.g:
    • multiplexing
    • more efficient binary protocol
  • Some benefits (e.g: effective use of push headers) will require change/optimization to take advantage of them
  • The community is still working out best practices
  • Upgrading is frictionless:
    • Clients that can use HTTP/2 will do so
    • Clients that don't support HTTP/2 can fall back to HTTP/1.1
    • If you're using apache, enable mod_http2

Tangents

What is the status of PHP 7.1?

  • PHP 7.1 Alpha 1 is out
  • Working towards beta 1
  • 7.1 will be a "loaded version": lots of new features
  • Will hopefully not include many non-backwards compatible changes

Are there any plans to add ramsey/uuid lib to PHP as a core extension?

  • Core extensions are difficult to iterate
  • Keeping it as a package that can be required by composer provides more flexibility
  • There is a PHP uuid extension
  • It only works on linux due to dependency on /dev/random

Other Resources

Davey Shafik


Ben Ramsey


Junade Ali


Developer Shout-Out

The Developer Shout-Out recognizes developers in the community for their contributions.

For this episode the panel guests, Davey, Ben, and Junade nominated Jessica Mauerhan for the Developer Shout-Out segment.

Thank you, Jessica Mauerhan for your efforts to add more tests to OSS projects. A $50 Amazon gift card is on its way to you.

$50 Amazon gift card sponsored by Laracasts

Laracasts

It's like Netflix for developers.

Show Notes Credit

Chris Shaw

Thank you Chris Shaw for authoring the show notes for this episode!

If you'd like to contribute show notes and totally get credit for it, check out the show-notes repo!