4 ms·
Such a terrific book. How outdated do you think it is now?
by dondraper36 3y ago
Such a terrific book. How outdated do you think it is now?
- ipnon 3y agoIf you look at the final part of the book “Browser APIs and Protocols” it includes WebSockets and WebRTC. It looks completely up to date. You can handle practically any Web network problem with some combination of XHR, WebSockets and WebRTC.
- e12e 3y agoNot having read the book - judging by the (comprehensive!) table of contents - the most obviously missing piece is 5g (assuming it's not covered by the 4g section). And possibly a "future" bit on http/3 - also a little unclear how much there is about QUIC - but i assume the http/2 section covers it.
- Foivos 3y agoAt the time of writing the book, the author was referencing state of the art papers for the chapter on mobile networks. Especially the work of Morley Mao from U Michigan, who was the first to study commercial deployments of LTE and how applications where using mobile networks. It was probably the most thorough and approachable introduction to mobile broadband at the time. But in 10 years a lot have changed. Most notably 5G. It would be interesting to update the book with the more recent papers of the same group studying commercial 5G deployments. I would also remove anything that has to do with 3G. The state machine of 3G is very different to 4G/5G, so optimising for this might be a bad choice. Finally, I would discuss more recent transport layer protocols, such as QUIC and congestion control algorithms such as BBR. Early experiments on commercial 5G networks show that legacy congestion control algorithms are not able to take advantage of the very high speeds that 5G can offer. I would also add some sections about "5G stand alone" usecases, such as massive IoT and ultra reliable low latency communication.
- ksec 3y agoI dont think anything is outdated, other than some figures in Chapter "Speed Is a Feature". Latency has improved over the years, New York to Sydney is now a 210ms RTT. Compared to ~300. Improvement in Last-mile latencies and Bufferbloat. ( Not perfect but still a little better than 2015 ). I only wish someday we could somehow get Hollow-core Fibers for long distance cable and backbone. Could have lower the New York to Sydney RTT by at least 40ms. Akamai no longer publish the Internet Report. But I wont be surprise if average Global Internet speed is up by at least 5x. And Mobile Network is up 10x. And we continue to improve on those figures. As the world move to Fibre Optic with High Speed PON and Mobile with 4G/5G. WiFi 7, 4G/5G, and Router are all thinking latency during its design. It is amazing to think by 2025, how much better things could be compared to 2015.
- alberth 3y agoAT&T still keeps an updated public (real-time’sh) view of their latency across the US https://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html https://ipnetwork.bgtmo.ip.att.net/pws/network_delay.html Verizon publishes a monthly global update https://www.verizon.com/business/terms/latency/ https://www.verizon.com/business/terms/latency/
- deleted 3y ago[deleted]
- World177 3y agoIt doesn't talk about HTTP/3 or QUIC. [1] It does mention WebRTC, but for a book on high performance browser networking, it's not currently mentioning solutions that were created to resolve difficulty in UDP programming (for performance networking) with WebRTC. [1] https://en.wikipedia.org/wiki/HTTP/3 https://en.wikipedia.org/wiki/HTTP/3
- Dowwie 3y agoUnfortunately, ten years have passed and yet it is far from outdated.
- dylanlacom 3y agoI read it for the first time last year and found most of it still very relevant. And there’s an updated version with a chapter on http/2. I’d love to see an http/3 chapter added.
- KingMob 3y agoThe section on HTTP/2 is definitely out-of-date in some respects. For starters, server push turned out to be very hard to use effectively, and in some situations could make things worse. It's been deprecated for awhile now, and last year Chrome effectively disabled it by always sending SETTINGS_ENABLE_PUSH = 0, which tells servers not to use it. The HTTP/2 prioritization scheme was partly deprecated in RFC 9113. The browsers all have different interpretations, and Safari/Edge effectively don't use it. On top of that, many servers have TCP buffers that are too large to allow priority changes to work in time. RFC 9218 introduced simpler prioritization headers for HTTP/3, and it's been suggested as a backwards-compatible replacement for HTTP/2. That's just in my area of expertise. There's probably more. It looks like a good book, but it seems it hasn't been updated in the decade since publishing. Some links: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though... https://developer.chrome.com/blog/removing-push/ https://developer.chrome.com/blog/removing-push/ https://chromestatus.com/feature/6302414934114304 https://chromestatus.com/feature/6302414934114304 https://datatracker.ietf.org/doc/html/rfc9218 https://datatracker.ietf.org/doc/html/rfc9218 https://calendar.perfplanet.com/2022/http-3-prioritization-demystified/ https://calendar.perfplanet.com/2022/http-3-prioritization-d... https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/ https://blog.cloudflare.com/better-http-2-prioritization-for... https://calendar.perfplanet.com/2018/http2-prioritization/ https://calendar.perfplanet.com/2018/http2-prioritization/ https://github.com/andydavies/http2-prioritization-issues https://github.com/andydavies/http2-prioritization-issues