COMP347 (Revision 10) | TrustOpen University
Upon completion of this expanded tutorial, students will be able to:
This concluding tutorial synthesizes the entire Unit 2 curriculum into an integrated framework. We revisit the architectural patterns, protocols, and security mechanisms covered in the previous eleven tutorials, but now examine them as components of a cohesive system. The focus is on integration: how DNS, HTTP, SMTP, P2P, streaming, and security technologies interact to form the modern Internet application stack.
We begin with a structured review of the core concepts, organized by architectural layer and functional domain. We then present three detailed case studies that trace end‑to‑end application flows, exposing the interplay between protocols. A cross‑layer performance analysis section examines how choices at one layer (e.g., transport protocol) affect performance at others (e.g., page load time). The security integration section applies the Dolev‑Yao adversary model to complete systems, identifying vulnerabilities that span multiple layers. Finally, we present integrative design problems and advanced troubleshooting scenarios that require holistic thinking.
The choice between TCP and UDP is governed by application requirements: reliability, timing, throughput, and security. TCP provides reliable, ordered delivery with congestion control; UDP offers low overhead and message boundaries. QUIC (over UDP) is emerging as a hybrid, offering TCP‑like reliability with UDP‑like latency and multiplexing.
| Protocol | Purpose | Transport | Key Feature |
|---|---|---|---|
| HTTP/HTTPS | Web browsing | TCP (or QUIC) | Stateless, request‑response, caching |
| SMTP | Email sending | TCP | Store‑and‑forward, push |
| POP3/IMAP | Email retrieval | TCP | Download‑and‑delete vs server‑side sync |
| DNS | Name resolution | UDP/TCP | Distributed, hierarchical, caching |
| BitTorrent | File distribution | TCP | P2P, pieces, tit‑for‑tat |
| DASH/HLS | Video streaming | HTTP (TCP/QUIC) | Adaptive bitrate, segmentation |
| WebSocket | Real‑time | TCP | Full‑duplex, persistent |
| WebRTC | Real‑time media | UDP (SRTP) | P2P, low‑latency |
Trace the steps from a user typing https://www.example.com to the page being rendered, including DNS resolution, TCP/TLS handshake, HTTP request/response, and CDN edge caching. Highlight the interactions between DNS (load balancing), TLS (encryption), HTTP (caching), and the CDN (edge routing).
Follow an email from a Gmail user to a corporate domain. Include SMTP submission, MX lookup, SPF, DKIM signing, DMARC validation, and retrieval via IMAP over TLS. Discuss how each security mechanism contributes to authenticity and integrity.
Describe a Netflix streaming session: manifest retrieval, bandwidth estimation, segment selection, and adaptation. Show how the CDN cache serves popular segments and how the client uses HTTP/2 or HTTP/3 to fetch segments concurrently.
HTTP/2 multiplexes many streams over a single TCP connection. However, TCP's head‑of‑line blocking (a lost packet delays all streams) can still degrade performance. HTTP/3 over QUIC solves this with independent stream recovery, significantly improving performance under packet loss.
DNS resolution can add 50–200 ms to the first request. Prefetching, pre‑resolving (using <link rel="dns‑prefetch">), and using a fast recursive resolver (e.g., 8.8.8.8) can reduce this. The cumulative effect of DNS, TCP, TLS, and HTTP request/response times determines the Time‑to‑First‑Byte (TTFB).
A high cache hit ratio (e.g., 90%) reduces origin server load and latency. The hit ratio depends on the content popularity distribution (Zipf) and the cache size. CDNs use LRU, LFU, or GreedyDual‑Size to maximise the byte hit ratio.
Apply the Dolev‑Yao adversary model to a scenario where an attacker sits between a user and a web server. Show how TLS protects against eavesdropping, tampering, and impersonation, but also identify weaknesses: mis‑issued certificates, TLS version downgrade, and application‑layer vulnerabilities (XSS, CSRF).
Conduct a systematic security audit of a web application that uses HTTP, SMTP, DNS, and a CDN. Identify potential attack vectors:
Requirements: document editing, video conferencing, chat, and file sharing with low latency. Recommend protocols (WebRTC, WebSocket, HTTP/3), architecture (centralized signaling, P2P media), and security (TLS, DTLS, SRTP). Address NAT traversal (STUN/TURN), scalability (CDN for file sharing, edge for signaling), and consistency (Operational Transformation for editing).
A gateway that connects constrained devices (CoAP, MQTT) to cloud services (HTTP, WebSocket). Describe protocol translation, security (DTLS for CoAP, TLS for HTTP), and scalability (load balancing, message queues).
Users report slow loading. Use curl -w to measure TTFB and total time. Check DNS resolution time (dig), TCP connection time, TLS handshake time, and HTTP response time. Analyze server logs for slow database queries. Use browser DevTools to identify resource bottlenecks. Propose a systematic approach to isolate the problem.
Emails from example.com are being marked as spam. Inspect the authentication results headers (e.g., Authentication‑Results: spf=fail ...). Check DNS records for SPF, DKIM, DMARC. Verify that the sending IP is authorised. Correct the records and test with tools like mail‑tester.com.
A BitTorrent swarm is performing poorly despite many peers. Investigate: high churn, poor piece availability, free‑riding. Use tools to measure peer connectivity and piece distribution. Suggest adjustments to the tracker/DHT, and encourage seeding with incentives.
Q1: In the end‑to‑end web request flow, which protocol is responsible for translating the domain name to an IP address?
DNS.
Q2: What is the primary advantage of HTTP/3 over HTTP/2 in terms of transport?
HTTP/3 uses QUIC (over UDP), which eliminates head‑of‑line blocking at the transport layer and supports connection migration.
Q3: Which email authentication mechanism signs the message body and headers?
DKIM (DomainKeys Identified Mail).
Q4: In the Dolev‑Yao adversary model, what capabilities does the attacker have?
The attacker can intercept, replay, drop, and fabricate messages, but cannot break cryptographic primitives without the key.
Q5: What is the purpose of the Cache‑Control header in HTTP?
It provides caching directives (e.g., max‑age, no‑cache, public, private) to control how responses are cached.
Q6: What is the difference between a recursive and an iterative DNS query?
A recursive query requires the resolver to fully resolve the name; an iterative query returns a referral to the next server.
Q7: How does the Circuit Breaker pattern improve microservice resilience?
It stops requests to a failing service, preventing cascading failures and allowing the service to recover.
Q8: What is the role of the API Gateway in a microservices architecture?
It provides a single entry point for clients, handling routing, authentication, rate limiting, and response aggregation.
Q9: Which protocol is used for adaptive bitrate streaming over HTTP?
DASH (Dynamic Adaptive Streaming over HTTP) and HLS (HTTP Live Streaming) are the two dominant ones.
Q10: What is the purpose of the HSTS header?
It instructs the browser to only connect over HTTPS for a specified duration, preventing SSL stripping.
Q11: In BitTorrent, what is the rarest‑first strategy and why is it used?
It prioritises downloading pieces that are least common among peers, ensuring availability of rare pieces.
Q12: What is the difference between a cache hit and a cache miss in a CDN?
A cache hit means the content is served from the edge cache; a cache miss means the edge must fetch from the origin, adding latency.
Q13: What are the three pillars of observability in microservices?
Metrics, logs, and traces.
Q14: How does TLS provide perfect forward secrecy?
By using ephemeral Diffie‑Hellman (ECDHE) key exchange, where session keys are not derived from the long‑term private key.
Q15: What is the purpose of the SameSite attribute in cookies?
It controls whether the cookie is sent with cross‑site requests, mitigating CSRF attacks.
Exercise 1 – End‑to‑End Performance Analysis
A user in Europe accesses a website hosted in the US. The RTT is 150 ms. The page contains 50 objects (including HTML, CSS, JS, images). Calculate the page load time using HTTP/1.1 with persistent connections (no pipelining) and HTTP/2 with multiplexing. Assume no transmission time.
For persistent HTTP/1.1 (no pipelining): each object requires 1 RTT for request/response after the initial handshake. Total = handshake (1 RTT) + first object (1 RTT) + 49*1 RTT = 51 RTT = 51*150 = 7650 ms. For HTTP/2, all objects can be requested in parallel after the handshake; total = handshake (1 RTT) + one RTT for all responses = 2 RTT = 300 ms (plus transmission). The difference is substantial.
Exercise 2 – DNS and CDN Interaction
Explain how a CDN uses DNS to route a client to the nearest edge. What is the role of the authoritative DNS server and the CDN's DNS infrastructure?
The client's stub resolver queries its recursive DNS server, which queries the authoritative DNS for the domain. The authoritative DNS is configured (via CNAME or NS records) to delegate to the CDN's DNS. The CDN's DNS returns an IP address based on the client's IP subnet (or resolver location), typically the nearest edge node. This is DNS‑based routing, which allows the CDN to direct clients based on geography, load, and health.
Exercise 3 – Secure Email Flow
Trace an email from alice@gmail.com to bob@company.com. Describe the SMTP submission, MX lookup, SPF, DKIM, DMARC, and the retrieval via IMAP. Identify where each security mechanism is applied.
Alice's UA sends to Gmail's SMTP server (submission). Gmail signs with DKIM and passes SPF. The outgoing MTA resolves company.com MX. It connects to mail.company.com via SMTP (STARTTLS). The receiving MTA checks SPF (envelope sender), DKIM signature, and DMARC policy. If all pass, the message is delivered to Bob's mailbox. Bob retrieves via IMAPS (TLS).
Exercise 4 – Microservices Resilience Design
Design a resilience strategy for a microservices application that includes a payment service, inventory service, and order service. Include circuit breakers, retries, timeouts, and a fallback mechanism.
Use a circuit breaker on calls to the inventory service. If it fails, return a cached response or a "temporarily unavailable" message. Implement retries with exponential backoff for transient failures. Set timeouts (e.g., 2 seconds) to avoid hanging. For the payment service, use a fallback to a secondary payment provider if the primary fails. Monitor the failure rates and alert.
Exercise 5 – TLS Configuration Audit
Your web server supports TLS 1.0, 1.1, 1.2, and 1.3, with cipher suites including 3DES and RC4. Identify security risks and propose a hardened configuration.
Risks: TLS 1.0/1.1 are vulnerable to BEAST, POODLE; RC4 and 3DES are weak. Recommendation: disable TLS 1.0 and 1.1, keep TLS 1.2 and 1.3; remove all non‑AEAD ciphers; use only ECDHE with AES‑GCM or ChaCha20; enable HSTS; use a modern cipher suite like ECDHE‑ECDSA‑AES256‑GCM‑SHA384.
Exercise 6 – P2P vs Client‑Server Cost Analysis
A file distribution service expects 10,000 concurrent users. Compare the infrastructure cost (bandwidth) of a client‑server model (with 10 servers) vs a P2P model (with a tracker and DHT). Assume average file size 1 GB, each user downloads once, and upload capacities.
Client‑server: total data transferred = 10,000 * 1 GB = 10 TB. With 10 servers, each serves 1 TB. Cost = egress bandwidth cost per GB. P2P: the tracker only coordinates; the data is exchanged among peers. The server only needs to seed the initial file (or a small fraction) and handle tracker/DHT requests. The bandwidth cost is dramatically lower, but there is overhead for DHT and tracker operations. The trade‑off is infrastructure cost vs complexity.
Homework 1 – Formal Security Analysis
Apply the Dolev‑Yao model to an HTTPS session with TLS 1.3. Prove, in an abstract sense, that an attacker cannot learn the plaintext if the cryptographic primitives are secure. Identify any assumptions (e.g., no side‑channels).
Use the standard TLS 1.3 security proof from the RFC; discuss the role of the handshake hash and the AEAD encryption.
Homework 2 – Cross‑Layer Performance Optimization Plan
Develop an optimization plan for a global e‑commerce website. Include recommendations for DNS (prefetching, TTL), HTTP/2 or HTTP/3, CDN, caching, image optimization, and TLS session resumption. Prioritize by impact.
Use Core Web Vitals as success metrics; recommend A/B testing for each change.
Homework 3 – Multi‑Protocol Application Design
Design a social media platform that supports text posts, image sharing, real‑time chat, and video streaming. Specify which protocols (HTTP, WebSocket, WebRTC, DASH, etc.) you would use for each feature. Justify the choice with technical reasoning.
Use HTTP for static content and APIs; WebSocket for chat; WebRTC for video; DASH/HLS for video playback; consider a CDN for media storage.
Homework 4 – Email System Overhaul
A company's email system is suffering from spoofing and delivery issues. Design a comprehensive email security and deliverability improvement plan: implement SPF, DKIM, DMARC, DANE, and TLS for all MTAs. Provide DNS record examples and a migration timeline.
Start with monitoring (p=none for DMARC), then move to quarantine, then reject. Include procedures for key rotation.
Homework 5 – Serverless vs Microservices Trade‑off
A startup needs to build a real‑time analytics pipeline. Compare serverless (AWS Lambda + Kinesis) vs a microservices architecture (Kafka + Kubernetes) in terms of cost, scalability, latency, and operational complexity. Recommend a solution.
Consider the workload patterns (spiky vs steady); serverless is cost‑effective for spiky, but may suffer cold starts; Kubernetes provides more control but higher operational overhead.
Homework 6 – End‑to‑End Troubleshooting Case Study
A user reports that a video streaming service is buffering frequently. The user has a 50 Mbps connection. Use a systematic approach: check DNS resolution, CDN edge assignment, bandwidth measurement, buffer occupancy, and adaptive bitrate decisions. Provide a step‑by‑step diagnostic process.
Use client‑side logs, network tools (traceroute, iperf), and CDN logs to isolate the issue (network, CDN, or client side).
This concluding tutorial has integrated the knowledge from all Unit 2 tutorials into a cohesive, systems‑level understanding. Key takeaways:
Unit 2 has provided the foundational knowledge required to understand, design, and secure Internet applications. The principles and protocols covered here are the building blocks for advanced topics in networking, distributed systems, and cybersecurity.