A2.1.4 Describe the network protocols used for transport and application.

The big idea

A network protocol is a set of precisely defined rules for formatting, transmitting, and interpreting data so that two or more endpoints can interoperate. Those rules live at different logical layers: transport protocols create an end-to-end pipe between processes, while application protocols define the vocabulary carried through that pipe. (Wikipedia).

Transport protocols such as TCP and UDP are concerned solely with getting bytes from Process A to Process B in a defined fashion.
Application protocols—HTTP, HTTPS (HTTP + TLS), DHCP—dictate the structure and meaning of those bytes.
Keeping the two concerns separate lets engineers improve reliability and performance at one layer without having to redesign the higher-level languages that run the Internet.

---

Transport-layer protocols

Protocol	Connection model	Reliability & ordering	Flow / congestion control	Typical use-cases
TCP	Connection-oriented (three-way handshake)	Guarantees in-order, loss-free delivery via sequence numbers + ACKs	Sliding-window flow control, AIMD congestion control	Web (HTTP/1.1 & 2), e-mail, file transfer
UDP	Connection-less datagrams	Best-effort (no retransmission, no ordering)	None in protocol; apps must add if needed	Live voice/video, DNS, gaming, QUIC/HTTP-3

Transmission Control Protocol (TCP)

• Establishes a virtual circuit with SYN → SYN-ACK → ACK.
• Uses sequence numbers, acknowledgements and time-outs to detect loss and trigger retransmission.
• Implements flow and congestion control so that fast senders do not overwhelm slower receivers or congested links. (GeeksforGeeks)

User Datagram Protocol (UDP)

• Sends independent datagrams with only length and checksum in the header.
• Omits acknowledgements and ordering, trading reliability for minimal latency and overhead. (Wikipedia)
• Applications that need reliability (e.g., QUIC) build their own mechanisms on top.

---

Application-layer protocols

Protocol	Transport basis	Core purpose	Default server port(s)
HTTP	TCP (HTTP/1.1 & 2) or QUIC/UDP (HTTP/3)	Stateless request–response for fetching web resources	80/TCP (HTTP/1.1 & 2), 443/UDP-QUIC (HTTP/3)
HTTPS	TCP or QUIC, wrapped in TLS	Same semantics as HTTP, but encrypted and authenticated	443/TCP (HTTP/1.1 & 2), 443/UDP-QUIC (HTTP/3)
DHCP	UDP	Automatic lease of IP address + configuration (DORA cycle)	67/UDP (server), 68/UDP (client)

Hypertext Transfer Protocol (HTTP)

The foundation of the Web: a client issues a textual request (method, URI, headers) and a server responds with a status line, headers and an optional body. HTTP/3, published as RFC 9114, preserves the same semantics while running over QUIC on UDP to lower latency and integrate encryption by default. (MDN Web Docs, RFC Editor)

Hypertext Transfer Protocol Secure (HTTPS)

HTTPS = HTTP encapsulated inside TLS. The TLS handshake authenticates the server and negotiates encryption keys; thereafter all HTTP messages travel encrypted, defending against eavesdropping and tampering. The well-known port is 443. (SSL2BUY)

Dynamic Host Configuration Protocol (DHCP)

DHCP eliminates manual IP configuration by using a four-message DORA exchange: Discover → Offer → Request → Acknowledge. Clients broadcast from port 68; servers listen on port 67. The result is a lease containing an IP address, subnet mask, gateway, DNS servers and a lease time. (Portnox)

---

Putting it all together—step-by-step

1. Get on the network (DHCP, UDP)
   Boot phase: the laptop broadcasts a DHCP Discover message on UDP port 68.
   A DHCP server answers on UDP 67 with an Offer that contains an IP address, gateway, DNS servers, and a lease time. The laptop Requests the offer and the server Acknowledges it.
   → Result: the laptop now knows its own IP settings.
2. Create the data pipe (TCP or QUIC)
   With an IP address in place, the browser opens a connection to web.example.com.
   If it uses TCP: the classic three-way handshake (SYN ▸ SYN-ACK ▸ ACK) establishes a reliable, ordered byte stream.
   If it uses QUIC: a single round-trip over UDP sets up an encrypted, multiplexed transport.

3. Speak the web language (HTTP)
   Inside that transport pipe the browser sends an HTTP request, e.g.

   GET /index.html HTTP/1.1
   Host: web.example.com
   

   The server replies with headers and the HTML body.

4. Add privacy and trust (TLS → HTTPS)
   If the URL begins with https://, a TLS handshake runs first—still over the same TCP or QUIC connection—to encrypt and authenticate the ensuing HTTP messages. From that point on the traffic is called HTTPS.

---

Why these pieces matter

• DHCP – hands out the addressing information that makes any conversation possible.
• UDP – lightweight way to send DHCP (and QUIC) messages.
• TCP / QUIC – build a dependable end-to-end pipe between browser and server.
• HTTP / HTTPS – define the actual content of the web conversation.

Together, these protocols turn raw bits on a wire into a secure page load on your screen.