Blog by Sergej Jevsejev

Book notes. Browser Networking by Ilya Grigorik

· by Sergej Jevsejev · Read in about 4 min · (781 Words)

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


  • 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 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.


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 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.

  • The connection can be upgraded from HTTP 1.1 to HTTP 2.0 with headers

Connection: Upgrade HTTP/2.0
HTTP2-Settings: <base64 settings>
  • 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.

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.


  • 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.


Use Wireshark for network connections analysis


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


  • 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.


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


  • 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.

Also available on the web -