Network Protocols

What are Network Protocols?

Network protocols define rules and standards for communication between devices on a network.

A protocol is an agreed set of rules that specifies how devices format, address, send, receive, and confirm data so both sides understand the same message.

They ensure efficient data transmission, security, and reliability over the internet.

Deep Dive: Transport Layer Protocols

TCP (Transmission Control Protocol)

What it is:

A connection-oriented protocol that aims for reliable, ordered delivery of bytes between two endpoints.

How it works (in practice):

  • Handshake: The two hosts agree to talk using a three-step setup (SYN → SYN-ACK → ACK). This reserves ports and sets starting sequence numbers.
  • Segmentation & order: Data is split into segments, each numbered. The receiver reassembles them in the right order.
  • Acknowledgements & retries: The receiver sends ACKs to confirm what arrived. Missing pieces are retransmitted.
  • Flow control: The receiver advertises a “window size” so the sender doesn’t overwhelm its buffer.
  • Congestion control: The sender adjusts its rate (e.g. “slow start”) to avoid flooding the network when it detects loss.
  • Close: A short exchange (FIN/ACK) cleanly ends the connection.

When to choose TCP:

You need accuracy and the right order - every byte matters, and it’s OK to wait a little for re-sends.

Example scenarios (clear use cases):

  • Web pages & logins: Loading HTML/CSS/JS and signing in to a site. Every file must arrive intact; mistakes break the page or the session.
  • File downloads & updates: Getting an installer or OS update. Reliability beats speed; integrity is critical.
  • Email: SMTP/IMAP/POP use TCP so messages aren’t corrupted or reordered.
  • Remote admin: SSH needs reliable, in-order text streams for commands and output.

Trade-offs:

Extra overhead (handshake, ACKs) and slight delay if a segment is lost (everything waits for a retry). Great for correctness; not ideal for real-time media.

UDP (User Datagram Protocol)

What it is:

A connectionless protocol that sends independent messages (“datagrams”) with minimal overhead. No built-in guarantee of delivery or order.

How it works (in practice):

  • No handshake: The sender just transmits datagrams to a destination IP and port—fast to start.
  • Best-effort delivery: Packets may be lost or arrive out of order. If reliability is needed, the application adds its own checks/retries.
  • Lightweight header: Small per-packet overhead; includes a checksum to detect basic corruption.
  • One-to-many: Can use multicast for sending the same stream to many receivers efficiently.

When to choose UDP:

You care most about low delay and can tolerate the occasional lost packet. “Keep going” is better than “wait and fix.”

Example scenarios (clear use cases):

  • Voice/Video calls (VoIP): If one audio packet is late, it’s useless. Better to play the next packet than to pause and wait.
  • Online gaming: Position updates are frequent and time-sensitive. Missing one update is fine; a late update is not.
  • Live streaming: Small losses are less noticeable than buffering. Players may use forward error correction to hide drops.
  • DNS lookups: Quick question/answer messages fit well in a single, small datagram (with TCP as a fallback for large replies).

Trade-offs:

No built-in reliability, ordering, or congestion control. If an app needs those features, it must add them itself, which increases complexity.

Deep Dive: Application Layer Protocols

HTTP (Hypertext Transfer Protocol)

What it is:

Application-layer protocol for transferring web content. It defines how a browser (client) and a web server talk using requests and responses.

How it works (in practice):

  • Request–response: The client sends a method (e.g. GET, POST) to a URL; the server replies with a status code (200 OK, 404 Not Found) and a body.
  • Headers & content types: Headers carry extra info (e.g. Content-Type: text/html or application/json), caching hints, and cookies.
  • Stateless by design: Each request stands alone; cookies or tokens are used to remember logins and preferences.
  • Caching: Browsers/CDNs reuse responses using Cache-Control and ETag to speed up repeat visits.

When it’s used:

General web browsing and API calls where encryption isn’t required (in practice, most production sites redirect to HTTPS).

Example scenarios:

  • Loading a static website: A school noticeboard site serves HTML, images, and CSS quickly from a CDN.
  • Calling a public API: A demo page fetches open data (e.g. weather) using simple GET requests.

Ports & tools:

  • Port: TCP 80 (often redirected to HTTPS).
  • Tools: Browser DevTools, curl, Postman.

HTTPS (HTTP Secure)

What it is:

HTTP carried inside TLS encryption. It provides confidentiality (can’t read), integrity (can’t change silently), and server authentication (you’re talking to the real site).

How it works (in practice):

  • TLS handshake: Client and server agree on keys and ciphers; the server presents a digital certificate that the browser verifies.
  • Encrypted session: After the handshake, all HTTP requests/responses are encrypted.
  • Security features: HSTS forces HTTPS; modern sites prefer HTTP/2 or HTTP/3 for efficiency (multiplexing, fewer round-trips).

When it’s used:

Almost all modern websites, especially for logins, payments, and personal data. It’s the default for secure web apps and APIs.

Example scenarios:

  • Online banking checkout: Card details and session cookies are protected in transit to prevent eavesdropping.
  • School portal sign-in: Student usernames/passwords and grades are sent over an encrypted connection.

Ports & tools:

  • Port: TCP 443.
  • Tools: Certificate viewer (browser padlock), openssl s_client, curl -I https://….

DHCP (Dynamic Host Configuration Protocol)

What it is:

Automatically gives devices their network settings so they can join a network without manual setup (IP address, subnet mask, default gateway, DNS).

How it works (in practice):

  • DORA steps: Discover (client broadcasts), Offer (server proposes an address), Request (client asks for one), Acknowledge (server confirms the lease).
  • Lease & renewal: The address is “leased” for a time; the client renews before it expires.
  • Options: Server also provides router (default gateway), DNS servers, domain, etc.
  • Relays: In larger networks, a relay agent forwards DHCP messages between subnets.

When it’s used:

Any time devices join a LAN or Wi-Fi and need an address automatically - home, school, and enterprise networks.

Example scenarios:

  • Joining school Wi-Fi: A student’s phone gets an IP address, gateway, and DNS within seconds after connecting.
  • New lab PCs: Freshly imaged machines boot, receive addresses by DHCP, and then contact update servers.

Ports & tools:

  • Ports: UDP 67 (server), UDP 68 (client).
  • Tools: ipconfig /all or ifconfig/dhclient, ipconfig /renew.

Comparison of Network Protocols

Protocol Layer Function Example Use Case
TCPTransportReliable, connection-oriented data transferEmail, file downloads
UDPTransportFast, connectionless data transferOnline gaming, video calls
HTTPApplicationTransfers web contentWeb browsing
HTTPSApplicationSecure web communicationBanking, e-commerce
DHCPApplicationAssigns IP addressesNetwork configuration

Why Are Network Protocols Important?

  • Standardised Communication: Ensures compatibility across devices and networks.
  • Reliable Data Transfer: TCP ensures error-free data delivery, while UDP supports fast transmissions.
  • Security: HTTPS encrypts data to protect user privacy.
  • Efficient Network Management: DHCP automates IP address allocation.

 Key Takeaways

  • Transport protocols like TCP and UDP manage data delivery and reliability.
  • Application protocols like HTTP, HTTPS, and DHCP support web communication and network management.
  • Protocols ensure standardised and secure data transmission over the internet.
  • The choice between TCP and UDP depends on whether reliability or speed is more important.