Book notes. Browser Networking by Ilya Grigorik

Cover Image for Book notes. Browser Networking by Ilya Grigorik
Sergej Brazdeikis
Sergej Brazdeikis

What I have learned by reading this book. Hope something will be helpful to you also.

Most liked sentence in the book

Fastest request is no request

Things I learned

TCP

For HTTP it takes minimum 3 end to end signal trips before any data starts to transfer.

Learned about Slow start TCP nature. Speed is slow in the beginning and goes up until packets start being lost. Then it drops, and starts to raise again until it gets packets being lost again.

Speed / time:
|-------------------|
|                   |
|             /|   /|  
|       /|   | |  | |  
|      | | _/  |_/  |
|    _/  |/         |
|  _/               |
|_/                 |
|-------------------|

Packet loss is fine. This is how TCP finds the connection limits

Distance matters. Signal trips add up to response time. Distance between New York to London translate to round trip of ~56 ms in fiber.

For Linux kernel optimisations in non-latest Linux distributions:

# check TCP Window Scaling (RFC 1323)
sysctl net.ipv4.tcp_window_scaling

# enable scaling setting 
sysctl -w net.ipv4.tcp_window_scaling=1

# Slow-Start Restart 
sysctl net.ipv4.tcp_slow_start_after_idle

# To disable resetting swnd window
sysctl -w net.ipv4.tcp_slow_start_after_idle=0

UDP

UDP protocol does not promise anything:

  • neither message delivery
  • neither packet order of delivery
  • neither tracks the connection status

It just streams and that's it.

TLS

To run TLS it needs a three-way handshake. It means 6 signal travels. If your server is far away high response times are expected.

In the case of TCP New York to London roundtrip of ~56 ms. It translates to 168 ms latency for full TCP and TLS setup.

Wifi & 3G

It is a battleground for the signals. Your 50% speed drop is because of neighbor.

Do not trust benchmarks. They can change: - Moving couple centimeters a side. Signal gets weaker / stronger depending on the walls and etc. - Same location later - your benchmark can interfere another wifi client. Same wifi or different.

Use wifi channel which is least used at your place.

HTTP

HTTP 0.9 was really funny protocol. ASCII only :)

HTTP 1.1 is really old. It was officially released in January 1997

It is based on TCP

HTTP 2.0

HTTP 2.0 was mainly based on SPDY experimental protocol from Google. It started being adopted by browsers, and after it started having traction HTTP 2.0 document was written.

HTTP 2.0 main benefits:

  • Reuses same connection. Performance gain.
  • Binary protocol. Performance gain.
  • Supports server push. Transparent to client. Resource goes to client cache. On request instead
  • Compresses the header. Resends only header deltas. For instance, User-Agent does not really change. So it is cached in server and client.
  • Optimisations made for HTTP 1.1 does not apply for HTTP 2.0 and could be considered harmful.
  • End to end HTTP 2.0 connection is the best for performance. For e.g. Browser to Nginx which serves content in HTTP 2.0.
  • HTTP 2.0 proxy can be enabled in front of HTTP 1.1 servers to get started. But it should not be taken as a long term solution.
  • The connection can be upgraded from HTTP 1.1 to HTTP 2.0 with headers:
Connection: Upgrade HTTP/2.0
HTTP2-Settings: <base64 settings>

Network latency

Bandwidth doesn't matter much. The biggest impact is up to 1 Mbps. Later each Mbps gives only about 5% improvement. Reason - connection roundtrips.

Mobile

Do as fewer connections as possible. Each new connection kills the battery and is very slow.

Try to suppress multiple requests into one.

Also, try to wait in time to suppress requests. Bundle them as much as possible.

Tools

Use Wireshark for network connections analysis

XHR

Best usage is long pooling for live updates

  • It is a fallback for other custom protocols
  • It is not good fit for streaming
  • Uses HTTP / HTTP 2.0 connection.
  • 500-800 bytes overhead on HTTP 1.x. On HTTP 2.0 lowest possible after caching - 8 bytes.

SSE Server-Sent Events

Usage: to transport the message from server to client. It uses:

  • Long-lived connection
  • Event-stream protocol
  • Uses Gzip compression
  • 5 bytes overhead

Limitations:

  • Server to Client only
  • Designed to transfer UTF-8 Data

SSE is bad for mobile. Do not have a connection open for SSE. It will drain the battery.

WebSocket

Bidirectional message streaming of text and binary data.

  • Uses only via HTTPS. Because on the internet, there are many misconfigured servers which can misinterpret, cache or block WebSocket connection.
  • Check if it makes sense to compress UTF-8 for transfer
  • Do not send big messages. Because of head-of-line blocking.
  • Is not compressed.
  • 2-14 bytes overhead

Linux

  • The network protocols are updated and latest Linux kernel distributions include them.

Book reference

I rated this book 4/5 and yes, I recommend to read it for web developers.

Ilya Grigorik - High Performance Browser Networking: What every web developer should know about networking and web performance

Available on the web - https://hpbn.co/

Sergej Brazdeikis
Sergej Brazdeikis