
HTTP/2 for TCP/IP Geeks - akerl_
http://daniel.haxx.se/blog/2015/05/07/http2-for-tcpip-geeks/
======
gizzlon
Nice recap, mostly understandable with just the slides.

I was not aware that my firefox now use http2 when speaking with google etc,
kind of cool.

You can check it with the Network monitor (Ctrl-Shift-Q). Reaload the page,
clck on a request an look for "Version" beneath "Status code".

------
yellowapple
> HTTP/2 is used _10 times more_ than HTTP/1.0

Isn't the usage of HTTP/1.0, like, zero? Does anyone (other than _maybe_ some
minimal embedded applications that probably won't upgrade to HTTP/2 anyway)
actually use HTTP/1.0 instead of HTTP/1.1?

~~~
bagder
The usage share there referred to stats from Mozilla and Firefox 36, where
HTTP/1.0 is seen in 1% of all HTTP responses compared to 10% for HTTP/2\. /
Daniel - author of those slides

~~~
bch
If the GP post is correct, ironically the HTTP/1.0 traffic thats really
happening might be services/appliances and (lib)curl (@bagder is principle dev
of curl, for those that don't know), not Firefox or any consumer browser.

------
digi_owl
Something of an aside, but i have come to understand that the major issue for
adopting IPv6 was hardware.

This both in terms of existing router installs, and endpoint devices that
can't be flashed to grok IPv6.

~~~
exelius
Well, kind of... It's less about not being able to grok IPv6 and more about
these routers having limited memory available. IPv6 addresses take up 4x as
much memory as IPv4 addresses, and that adds up pretty quickly in a routing
table. As routers are typically integrated devices, you can't just go "add
more RAM", so sticking with IPv4 effectively quadruples your capacity.

~~~
harshreality
Is that mixing up two different classes of devices?

Home embedded routers run into problems due to the overhead of state tracking
and buffers for all the simultaneous connections. If they support 10k
simultaneous connections, and they track 2x ip addresses for each, the
additional overhead of 2x 12 bytes per ipv6 connection is 240kB memory.
Buffers are going to be much, much more than that, and buffer requirements are
about the same for ipv4 and ipv6.

Routers that have full BGP routing tables tend to be serious routers with
TCAM. That's expensive and that does put pressure on BGP routing table sizes,
to accommodate older and cheaper [real] routers. However, ignoring ipv6 is
simply not an option, so there's no point in dreaming about how staying with
ipv4 forever would allow quadruple the routing table capacity for a set amount
of TCAM.

~~~
exelius
I was actually referring more to the core routers with TCAM than home routers.
And I agree, ignoring IPv6 isn't an option, but it is a viable option to
encourage workarounds. Which is exactly what's happened; so most ISPs that
support IPv6 do 6to4 tunneling at the edge.

~~~
harshreality
That's a workaround? Interior routers within the ISP don't need to hold the
global routing table, so there's no real TCAM pressure on them, right?

------
EvanPlaice
While HTTP/2 will lead to some huge improvements in efficiency it's going to
take some time for the web to collectively forget a decade's worth of kludges
otherwise known as 'best practices.'

Domain sharding, image spriting, script concatenation, lots of unnecessary
intermediate caching, etc. All of these were created with one goal. Faster
page load times (via connection thrashing) meant more Google PR juice. All of
them have hidden costs that add to development complexity and unnecessarily
increase load on the servers-side. IMHO, all should die a fiery death.

If we're really shooting for a faster and more efficient web experience,
HTTP/2 solves the greatest constraint on the back-end (ie allowing multiple
connections over a single TCP stream).

What we need next are a change in priorities defined by a new standard of
'best practices' such as:

1) Stop concatenating scripts

Assuming HTTP/2 and no 1 request/asset constraint what's the point? Sure, it
may lead to to a 10-20% increase in compression overall but only if the user
navigates to every page on your site.

2) Stop minifying scripts

Controversial? Maybe, but why are we intentionally creating human unreadable
gibberish for a modest gain when intermediate gzip compression leads to much
greater gains.

I can't count the number of posts I've read where a developer goes gets
excited about shaving 40KB off of their massive concatenated global.js soup
(incl jquery, mootools, underscore, angular, etc) when they would have had
much greater gains by optimizing image/media compression.

As a library developer, minifying sucks. For every version I release I have to
produce another copy, run a second set of tests (to make sure minifying didn't
break anything), and upload/host an additional file. In addition, any error
traces I get from users of the minified version are essentially useless unless
they take the time to download and test the non-minified version.

3) Quit loading common libraries locally

If I could teach every budding web developer one lesson it would be how a
local cache works and how no variation of concatenation/compression will lead
to a faster response than a warm cache.

Yes, loading 3rd party code can potentially lead to a XSS MITM attack (if you
don't link via HTTPS). No, your local copy is not more robust than a globally
distributed CDN. No, loading yet another unique copy of jquery is not going to
be faster than fetching the copy from a warm local cache.

The _only_ justification for loading common libs locally is if the site
operates on an air-gapped intranet.

Google indirectly encouraged most of these 'best practices' by giving PR juice
to sites with faster page load times.

It would be really interesting to see if/how the search engines will adjust
their algorithms as new 'best practices' are established. I know they're
starting to incentivize sites that use HTTPS.

What I'd _really_ like to see is sites being penalized for making an
unnecessarily large number of external domain requests with the exception of a
whitelist of common CDNs.

As for TCP/IP. I'd __really __like to hear a sound technical justification of
why the header checksum calculation for TCP is coupled to the IP header.

~~~
laumars
_> 2) Stop minifying scripts

Controversial? Maybe, but why are we intentionally creating human unreadable
gibberish for a modest gain when intermediate gzip compression leads to much
greater gains_

gzip compression is already widely supported, however minification does sill
have savings (eg removing comments from code - which really have no purpose
being transmitted in the first place.

What is actually counter productive for compression is renaming all of your
Javascript variable names to single character tokens. But that isn't something
I've seen any Javascript minimizers do.

I'd also challenge your point about " _human unreadable gibberish_ " as once
the data leaves the server it doesn't need to be human readable. It only needs
to be human readable at the development end - which is why minification only
happens on live content hosted on the production environment.

~~~
EvanPlaice
What I was implying was, minification only adds - at best - an additional %20
reduction in file size after gzip (ie which is more like 40%-60% reduction).
Assuming practices #1 and #3 are followed, scripts should remain relatively
small and the added benefit of minification would be negligible.

Unless the end goal is obfuscation, I don't see the value of adding additional
complexity to the development process for what amounts to a micro-
optimization. Plus - from a user perspective - if a site's scripting fails,
I'd like to see developers maintain the ability to view the source in
production and determine why.

In an unrelated note, I'd also like to see ES/CSS updated with new features
that render the most common transpiled languages obsolete. I think transpiling
is an awesome approach for testing language improvements and possibly building
DSLs but supporting them in the long-term (ex tooling, backward compatibility)
doesn't make sense.

Speaking from the perspective of a library author/contributor. Developing,
testing, and stabilizing a widely-used codebase over the long term is hard.
Removing additional steps and reducing complexity makes life a bit easier.

~~~
laumars
20% isn't worthless if you're browsing on a mobile phone on a slow GPRS
connection.

From an end user perspective, I get sick of all the responsive sites that look
pretty on all screen sizes, but loads like a sack of shit on anything slower
than WiFi. Which is why the libraries I write auto-minimize live code (they
also use smaller dependencies, but that can be mitigated by your public CDN
point).

