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 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.
- 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:
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.
I rated this book 4⁄5 and yes, I recommend to read it for web developers.
Also available on the web - https://hpbn.co/