3.3HTTP, web, and mail protocols

Web and mail are the most heavily used application-layer services in enterprise networks. A network specialist needs more than knowledge of protocol specifications—they must respond to concrete problems such as "pages load slowly" or "spoofed mail keeps arriving" with concrete design choices like selecting an HTTP version or deploying sender domain authentication. This section covers both.

3.3.1HTTP/HTTPS and HTTP/2, HTTP/3 (QUIC)

• HTTP is a text-based request/response protocol. HTTPS encrypts HTTP with TLS, providing resistance to eavesdropping, tampering, and spoofing. HTTP/1.1 tends to serialize requests over a single TCP connection (head-of-line (HOL) blocking), which degrades performance when fetching many small resources.
• HTTP/2 multiplexes multiple streams over a single TCP connection, mitigating HOL blocking through concurrent request/response handling. Header compression (HPACK) also improves performance, but when the underlying TCP connection experiences packet loss, the entire connection stalls (HOL blocking still occurs at the transport layer).
• HTTP/3 uses QUIC (UDP-based) as its transport layer, eliminating the TCP-layer HOL blocking that remains in HTTP/2. QUIC performs retransmission control independently per stream, so packet loss on one stream does not affect the others. QUIC also integrates TLS, combining connection establishment and the encryption handshake to speed up connection start-up.

3.3.2Cookies and session management

• HTTP is inherently stateless, but to maintain state such as login status, a cookie (small data the server issues via a response header, which the client automatically attaches to subsequent requests) is used to carry a session ID.
• Cookies carry attributes such as Secure (sent only over HTTPS), HttpOnly (inaccessible from JavaScript, mitigating XSS), and SameSite (controls cross-site sending, mitigating CSRF), all used to harden security.

3.3.3Mail protocols and sender domain authentication

• SMTP handles the sending and relaying of mail (both client-to-sending-server and server-to-server relay). POP3 downloads mail from the server to the device and deletes it there (assuming use from a single device). IMAP keeps mail on the server while synchronizing viewing and management across multiple devices.
• MIME (Multipurpose Internet Mail Extensions) extends SMTP, which was originally text-only, to support images, attachments, and non-ASCII characters such as Japanese. Content-Type specifies the data type, and Content-Transfer-Encoding specifies the encoding scheme (e.g., Base64).
• SPF (Sender Policy Framework) publishes the "list of legitimate sending IP addresses" in the sending domain's DNS TXT record, letting the receiving side check against it to detect spoofing. DKIM (DomainKeys Identified Mail) attaches a digital signature to the mail, verified against a public key (published via DNS), providing tamper detection and sender authentication.
• DMARC (Domain-based Message Authentication, Reporting & Conformance) lets a domain owner declare, via DNS, a policy (none / quarantine / reject) for how to handle mail that fails SPF and DKIM checks, based on their combined results. It also lets the owner receive reports of verification outcomes.

Suppose a company's web administrator receives complaints that "page loads are slow for users on mobile connections with heavy packet loss." The site currently serves HTTP/2, and although multiplexing works over a single TCP connection, the likely cause is that when packet loss occurs, the entire connection stalls waiting for TCP retransmission (transport-layer HOL blocking). Migrating to HTTP/3 (QUIC) is an effective countermeasure here: because QUIC performs retransmission control independently per stream, packet loss on one image request does not block the loading of other text or scripts. QUIC also integrates the TLS handshake, speeding up connection establishment and improving perceived performance on unstable environments like mobile networks. Meanwhile, the same company's mail administrator reports an increase in "business email compromise" scams—fake mail impersonating a business partner instructing a change of bank transfer destination for an invoice. The recommended countermeasure sequence in practice is: first set up an SPF record for the company's domain declaring legitimate sending IPs, then attach DKIM signatures to all outgoing mail, and finally strengthen the DMARC policy in stages, from none (monitor only) to quarantine and eventually reject. Jumping straight to reject risks blocking legitimate business mail due to false positives, so a staged rollout with a monitoring period is the appropriate design decision.

3.3.4Section summary

• HTTP/2 multiplexes over TCP; HTTP/3 uses QUIC (UDP) to also eliminate transport-layer HOL blocking
• SPF = sending-IP verification, DKIM = tamper detection via signature, DMARC = failure policy and reporting for both
• DMARC policy should be strengthened in stages, none -> quarantine -> reject, as the appropriate practical design