The internet itself makes very few promises. It takes a packet of about 1,500 bytes, tries to get it to an address, and that's it. Packets get lost. They arrive out of order. Sometimes they arrive twice. Nobody tells you.
Every app you build sits on top of that mess. Something has to turn "packets, maybe" into "the order JSON arrived, complete and in the right order". That something is the transport protocol. There are three you need to know: TCP, UDP and QUIC. Each one makes a different trade between reliability and speed, and the choice shows up directly in your latency numbers.
Where this fits. In Module 2 you followed a request from the Tiffin app to the server and back. The lesson before this one covered how the app finds the server's address (DNS). This lesson covers how bytes actually travel once it has that address.
What IP gives you
IP (the Internet Protocol) delivers individual packets between machines. It's best effort: no guarantees of delivery, order or uniqueness.
On top of IP, transport protocols add ports, so one machine can run many services. Your server's HTTPS listener is on port 443. Postgres is on 5432. A connection is identified by four things: source IP, source port, destination IP, destination port.
Before going further, get a feel for the one number that dominates everything here: the round-trip time (RTT), how long a packet takes to go there and back.
| Path | Typical RTT |
|---|---|
| Two servers in the same data centre | 0.2-0.5 ms |
| Mumbai to Bangalore | 20-30 ms |
| Phone on 4G to a server in the same country | 40-80 ms |
| Mumbai to US East Coast | 180-220 ms |
You can't make light faster. What you can control is how many round trips your protocol needs before useful data flows. That's the theme of this whole module.