Skip to main content

Module Quiz

Complete this quiz after finishing all concept and practice pages.

Current Module Questions​

Question 1: Layered Model​

Name the five layers of the Internet stack in order from bottom to top, and give one representative protocol for each.

Answer: Physical (copper/fiber/radio signaling), Link (Ethernet, Wi-Fi), Network (IPv4, IPv6), Transport (TCP, UDP), Application (HTTP, DNS, SSH).

Question 2: Encapsulation​

A server receives an Ethernet frame containing an IP packet containing a TCP segment containing an HTTP request. In what order does the kernel strip headers as the data moves up the stack?

Answer: Ethernet header first, then IP header, then TCP header; the remaining bytes are the HTTP request passed to the listening socket.

Question 3: Addressing​

Why is a MAC address not used to deliver a packet between two hosts in different cities, even though both machines have MAC addresses?

Answer: MAC addresses are only meaningful on one link. Each router rewrites the Ethernet header with a new MAC pair for the next hop. The IP header is what survives end-to-end.

Question 4: Subnet Math​

Given 10.0.24.53/20, name the network address, the broadcast address, and the number of usable host addresses. Is 10.0.33.10 in this subnet?

Answer: Network 10.0.16.0, broadcast 10.0.31.255, usable hosts 10.0.16.1-10.0.31.254 (4094 total). 10.0.33.10 is not in the subnet because its bit 20 differs from 10.0.16.0.

Question 5: Routing​

Two routes 10.0.0.0/8 via R1 and 10.0.24.0/20 via R2 both match destination 10.0.24.53. Which is selected, and why?

Answer: 10.0.24.0/20 via R2, by longest-prefix match. The more specific prefix wins regardless of table order.

Question 6: UDP Use Cases​

Why does DNS use UDP for a typical query instead of TCP?

Answer: A DNS query is a single small request and reply. Using UDP avoids the TCP three-way-handshake cost and the connection state, which would add latency and memory for no benefit. DNS falls back to TCP for larger responses or zone transfers.

Question 7: TCP Mechanisms​

Distinguish flow control from congestion control in TCP. Which one protects the receiver, and which one protects the network?

Answer: Flow control uses the receiver's advertised window (rwnd) and protects the receiver from being overwhelmed. Congestion control uses the sender's computed congestion window (cwnd) and protects the network from being overwhelmed. The sender sends at most min(rwnd, cwnd) bytes in flight.

Question 8: TCP Lifecycle -- SYN to Established​

Walk through the exact packet flags on the wire for opening a TCP connection, from client CLOSED to both sides ESTABLISHED.

Answer:

  1. Client sends SYN seq=X; client enters SYN_SENT.
  2. Server replies SYN, ACK seq=Y, ack=X+1; server enters SYN_RCVD.
  3. Client sends ACK ack=Y+1; both sides enter ESTABLISHED.

Question 9: TCP Lifecycle -- Close​

Walk through the close of that same connection, assuming the client initiates the close. Name each state and explain the purpose of TIME_WAIT.

Answer:

  1. Client sends FIN; enters FIN_WAIT_1. Server sees FIN, enters CLOSE_WAIT, replies ACK.
  2. Client moves to FIN_WAIT_2 on receiving that ACK.
  3. When the server application closes, server sends FIN, enters LAST_ACK.
  4. Client receives FIN, sends ACK, enters TIME_WAIT.
  5. Server sees final ACK, enters CLOSED.
  6. Client stays in TIME_WAIT for ~2*MSL so that late-arriving segments of this connection cannot be mistaken for data on a future connection reusing the 4-tuple, then enters CLOSED.

Question 10: HTTP Methods and Status Codes​

Why is PUT /resource/42 generally retry-safe while POST /resource is not?

Answer: PUT is defined to be idempotent: replacing the resource at /resource/42 with the same body any number of times has the same effect as doing it once. POST has no such guarantee -- the typical use is to create a new resource, so retrying can create duplicates.

Question 11: HTTP/2 vs HTTP/1.1​

What specific problem does HTTP/2 multiplexing solve that HTTP/1.1 pipelining could not?

Answer: Pipelining in HTTP/1.1 allowed sending multiple requests without waiting, but responses still had to come back in request order, so one slow response blocked the rest (head-of-line blocking). HTTP/2 gives each request its own stream with frames that can be interleaved on the same connection, so a slow response no longer blocks others.

Question 12: TLS​

Why is a TLS server's certificate public information, while a TLS server's private key must never leave the server?

Answer: The certificate is what the server shows to prove its identity; it is meant to be shared. The private key is what lets the server demonstrate that the certificate really belongs to it (by signing/decrypting in the handshake). Anyone with the private key can impersonate the server, which is why it is guarded.

Question 13: Sockets API​

In the TCP server flow socket -> bind -> listen -> accept, why do you need a separate file descriptor returned by accept rather than using the listening socket for data?

Answer: The listening socket represents the endpoint on which new connections arrive; it only accepts. Each accepted connection is a distinct 4-tuple (local, remote) and needs its own fd so the server can read/write to one client without affecting the others or the accept queue.

Question 14: Server Architecture​

A service handles 100 concurrent clients fine on a thread-per-connection model and collapses at 10,000. Name the likely cause and the architectural fix.

Answer: Thread-per-connection allocates per-thread stack and kernel scheduling overhead that do not scale to that many connections. The fix is an event-driven architecture (epoll/kqueue or equivalent) that multiplexes many connections onto a small number of threads, optionally combined with a worker pool for CPU-bound work.

Question 15: Debugging​

You capture a TCP handshake and see SYN leave the client but no SYN-ACK return. Name two plausible causes and say how you would tell them apart.

Answer: Plausible causes: (a) a stateful firewall or security group is dropping the SYN, (b) the server is not actually listening on that port, (c) an intermediate router is blackholing the packet. Distinguish by: running ss -ltn on the server to confirm the listener; running tcpdump on the server interface to see whether the SYN arrived at all; and checking firewall/ACL rules.

Interleaved Review Questions​

Prior Module Question 1 (from Module 3 -- Concurrency)​

Why do multiple threads sharing memory need a synchronization primitive like a mutex, and what does a mutex actually prevent?

Answer: Threads sharing memory can have interleaved reads and writes that leave data structures in inconsistent intermediate states. A mutex enforces that only one thread at a time executes the critical section, preventing that interleaving for the protected region.

Prior Module Question 2 (from Module 1 -- Processes)​

What does a blocking system call do to the calling process, and why is that relevant when you call accept in a single-threaded server?

Answer: A blocking syscall puts the process/thread in a wait state until the kernel signals readiness. In a single-threaded server, calling accept blocks the only thread until a new connection arrives, so it cannot serve existing clients during that wait -- the motivation for concurrent or event-driven designs.

Prior Module Question 3 (from Module 4 -- File Systems & I/O)​

A socket is a file descriptor. Name two syscalls that work on both regular-file fds and socket fds, and one place where the semantics differ.

Answer: read/write, close, fcntl work on both. A key difference: read on a regular file returns 0 only at end-of-file; read on a socket returns 0 when the peer has performed an orderly shutdown (FIN received), which is a different semantic event.

Prior Module Question 4 (from Module 2 -- Memory / Virtual Memory)​

Why does an event-driven server typically use much less memory per connection than a thread-per-connection server?

Answer: Each thread needs its own stack (often ~1 MB on Linux by default) plus kernel scheduling metadata. An event-driven server keeps only a small per-connection state object on the heap and reuses one or a few threads, saving stack memory and context-switch cost.

Prior Module Question 5 (from Semester 1 -- Probability)​

Why is the expected number of retransmissions in a session a useful quantity, and what distribution describes it under independent packet loss?

Answer: Expected retransmissions multiplied by cost gives a budget for tail latency and bandwidth overhead. Under independent per-packet loss probability p, the number of transmissions needed for one successful packet is geometric with parameter 1-p, so the expected count is 1 / (1 - p).

Self-Assessment and Remediation​

Mastery Level (90-100% correct):

  • Ready to advance with confidence to Semester 6.

Proficient Level (75-89% correct):

  • Review only the missed concept pages and redo two problems of each missed type.

Developing Level (60-74% correct):

  • Rework Practice pages 2 and 3 and revisit the TCP cluster.

Insufficient Level (<60% correct):

  • Return to the concept sequence from Cluster 1 and rebuild the layered-model habits before advancing.