Card 1 of 20
Front. Layer Boundary. A TCP connection succeeds but an HTTPS request fails. Which layers remain to investigate?
These cards are original study material. They are not questions from a named employer or a live hiring loop.
All 20 cards in this deck
1.Layer Boundary
A TCP connection succeeds but an HTTPS request fails. Which layers remain to investigate?
TLS negotiation and identity, HTTP protocol handling, proxy behavior, and application responses. Transport connectivity proves neither secure identity nor application correctness.
2.Dns Cache
Why can two clients resolve the same hostname differently at the same time?
They may use different resolvers, cached records, geographic routing, or split-horizon DNS. Compare the actual resolution paths and record lifetimes.
3.Tcp Framing
Two writes send two logical messages. Can a TCP receiver assume two matching reads?
No. TCP preserves byte order, not write boundaries. Define message framing and handle partial or combined reads.
4.Ack Meaning
Does a TCP acknowledgement prove that a server committed an application transaction?
No. It acknowledges transport receipt, not business processing or durable storage. Use an application-level result and a recovery identifier.
5.Flow Control
What is the difference between TCP flow control and congestion control?
Flow control protects the receiver's capacity; congestion control responds to network capacity and loss signals. Either can limit a connection's throughput.
6.Bandwidth Delay
Why can a high-bandwidth path still deliver poor throughput with insufficient in-flight data?
The sender must keep roughly bandwidth × round-trip time in flight to fill the path. Window limits, congestion behavior, and application production can prevent that.
7.Slow Reader
How can a slow receiver eventually affect the sending application?
Receive buffers fill, flow control reduces sending, and send buffers may fill. The application must handle blocking or backpressure instead of buffering indefinitely.
8.Keepalive
Why do TCP keepalives not replace an application request deadline?
They detect some idle connection failures on their configured schedule, not whether a particular operation is completing usefully. Bound application work explicitly.
9.Connect Read
Why should a client distinguish connection timeout from response-read timeout?
Connection establishment and waiting for application data fail for different reasons and need separate budgets. Also cap total elapsed time so repeated phases cannot exceed the operation deadline.
10.Ambiguous Timeout
A payment request times out after being sent. What does the client know about its effect?
Only that it did not receive a timely result. The server may have committed; retry using the same operation identity or query status rather than assuming nothing happened.
11.Tls Name
What identity must an HTTPS client verify in the server certificate?
The intended hostname or supported reference identity, along with trust and validity checks. Encryption without identity verification can connect securely to the wrong peer.
12.Tls Termination
If TLS terminates at a load balancer, is traffic to the backend automatically encrypted?
No. That is a separate connection with its own security configuration. Identify each trust boundary and protect backend traffic according to the deployment requirements.
13.Http Idempotent
Why can repeated DELETE requests return different statuses while remaining idempotent?
Idempotence concerns the intended server-side effect, not identical responses. After the first deletion, a later request may report absence without changing the final intended state.
14.Conditional Write
How can If-Match with an ETag prevent overwriting another client's edit?
The server applies the mutation only if the current representation matches the supplied validator. A failed precondition tells the client to reconcile rather than overwrite newer state.
15.Cache Vary
Why must a shared cache account for representation-varying request headers?
Otherwise it can reuse a response for a request that needs a different representation. Vary identifies relevant request fields; authorization and personalized caching require additional deliberate policy.
16.Status Retry
Why should a client not retry every 4xx or 5xx response using the same rule?
Some failures are permanent, some are transient, and retries can duplicate effects. Interpret the contract, retry safety, Retry-After where applicable, and the remaining deadline.
17.Http2 Loss
Why can packet loss on one HTTP/2 TCP connection delay multiple streams?
TCP delivers a single ordered byte stream, so missing bytes can block later bytes for all multiplexed HTTP streams. Multiplexing does not remove transport-level head-of-line blocking.
18.Quic Streams
What does QUIC change about delivery when one stream loses data?
Independent streams can make delivery progress without waiting for another stream's missing bytes. They still share connection-level congestion and other resources, so loss can affect overall throughput.
19.Retry Load
Why can retries make a network slowdown turn into a service overload?
They add attempts while original work may still be running. Bound attempts, use jitter, propagate deadlines, and measure useful completions rather than total attempts.
20.Protocol Test
What failures should a network client test beyond a server returning an error response?
Partial reads, slow responses, connection reset after a write, DNS failure, TLS failure, and cancellation. Verify resource cleanup and recovery from unknown operation outcomes.