Transport Layer Protocols

1. Which transmission protocol should be selected for an application where speed and minimal overhead are critical, and occasional data loss is acceptable?

UDP (User Datagram Protocol).

UDP is a connectionless, best-effort protocol. It has almost no overhead:

• No connection setup (no handshake).
• No acknowledgments.
• No retransmission of lost packets.
• No ordering guarantees.

That’s exactly what you want when speed beats reliability — video streaming, live gaming, VoIP, DNS lookups. A dropped frame in a video call is a blip; the next frame arrives anyway.

Compare with TCP: reliable and ordered, but it pays for that with handshakes, acks, and retransmissions — latency and overhead.

2. During a TCP Three-Way Handshake, what is the second packet sent to establish the connection?

The second packet is SYN-ACK.

The full sequence:

1. Client → Server:  SYN          (client wants to open connection)
2. Server → Client:  SYN-ACK      (server agrees + syncs its own side)
3. Client → Server:  ACK          (client confirms, connection open)

So the client initiates with SYN, the server responds with SYN-ACK (acknowledging the client’s SYN while sending its own), and the client closes the loop with ACK.

After the third step, both directions are synchronized and data can flow.

3. How does a Gateway differ fundamentally from a standard Router?

• Router — connects networks that use the same protocols (IP to IP). It forwards packets between subnets by IP address.
• Gateway — connects completely dissimilar networks and acts as a protocol converter, translating data between different formats and architectures.

Router:   IP network ──── router ──── IP network   (same protocol)
Gateway:  IP network ──── gateway ──── legacy/mainframe network (converts)

Example: a gateway lets an IP-based office LAN talk to an old mainframe using a different protocol. It’s a translator; a router is just a forwarder.

4. What is the primary network efficiency benefit of Piggybacking?

Piggybacking attaches an acknowledgment (ACK) onto an outgoing data frame’s header instead of sending a separate ACK frame.

Without piggybacking:
  A → B: data        B → A: separate ACK        A → B: next data

With piggybacking:
  A → B: data
  B → A: [data + ACK in same frame]   ← one frame does two jobs

The benefit: fewer frames on the wire, less overhead, better bandwidth use. The receiver piggybacks its acknowledgment onto the next frame it was going to send anyway.

5. What is the main difference between TCP and UDP protocols?

• TCP — connection-oriented and reliable. It establishes a connection (handshake), acknowledges data, retransmits lost packets, and delivers in order. Slower, but dependable.
• UDP — connectionless and fast. No handshake, no acks, no retransmission, no ordering. Lower overhead — but no delivery guarantee.

	TCP	UDP
Connection	Yes	No
Reliability	Guaranteed	Best-effort
Overhead	High	Low
Use cases	Web, email, file transfer	Streaming, gaming, VoIP

Choose TCP when correctness matters; UDP when speed matters and a little loss is acceptable.

6. Which structural header field is unique to a TCP segment and completely absent from a UDP datagram?

Acknowledgment Number.

The TCP segment header carries reliability machinery: Sequence Number, Acknowledgment Number, Window, Flags (SYN/ACK/FIN/RST), Urgent Pointer, etc.

UDP’s header is minimal:

Source Port (16) | Destination Port (16)
Length (16)      | Checksum (16)

Four fields, 8 bytes total — no sequence, no acknowledgment, no ordering.

Why? TCP is connection-oriented and reliable (it needs to track what was received — the Acknowledgment Number says “I got everything up to this byte”). UDP is connectionless best-effort; it has nothing to acknowledge.

7. What occurs if a TCP SYN-ACK packet is lost in transit during the 3-Way Handshake connection process?

The client’s retransmission timer expires, and the client resends its original SYN.

Client                Server
  │  ── SYN ──→          │
  │  ←─ SYN-ACK (lost) ─ │
  │  [timer expires]     │
  │  ── SYN (retry) ─→   │   ← client re-sends SYN
  │  ←─ SYN-ACK ──       │
  │  ── ACK ──→          │
  │   connection up      │

Because the client never saw the SYN-ACK, it can’t know the server even got the first SYN. It waits a timeout window, then retransmits the SYN. This repeats (with growing backoff) until the connection establishes or the client gives up. No permanent blocking, no fallback to UDP — just patient retries.

8. What is protocol Pipelining?

Pipelining lets a client send multiple requests back-to-back without waiting for each response.

Without pipelining (serial):
  send req1 ── wait for resp1 ── send req2 ── wait for resp2

With pipelining:
  send req1, req2, req3 ──────── resp1, resp2, resp3 arrive together

The win: one round-trip per request becomes one round-trip for many requests. It cuts latency dramatically on high-RTT connections (HTTP/1.1 pipelining) by keeping the channel busy instead of idling. The modern HTTP/2 successor to this is multiplexing — true concurrent streams on one connection.

9. What is the difference between flow control and congestion control?

Both control how much data TCP sends, but they solve different problems:

• Flow control — protects the receiver. It uses the sliding window (the receiver’s Window field in the ACK): “I can accept up to X bytes before you wait.” The sender never sends more than the advertised window, so the receiver’s buffer can’t overflow. It’s a sender↔receiver agreement.
• Congestion control — protects the network. It prevents the sender from overwhelming intermediate routers by detecting congestion (packet loss/timeouts) and shrinking its congestion window (cwnd). It’s the sender protecting the whole path.

The sliding window is bounded by min(receiver window, congestion window) — flow control is about the receiver’s capacity, congestion control about the network’s capacity. Interview one-liner: flow control = don’t overflow the receiver; congestion control = don’t flood the network.

10. How does TCP congestion control work?

TCP detects congestion by packet loss and responds by adjusting its congestion window (cwnd), in three phases:

1. Slow start — cwnd starts small (e.g. 1 MSS) and doubles every RTT (1→2→4→8…) until it hits the slow-start threshold (ssthresh). Growth is exponential.
2. Congestion avoidance — once past ssthresh, cwnd grows linearly (roughly +1 MSS per RTT). Slow, cautious growth while the path is healthy.
3. On loss — TCP takes this as congestion. In AIMD (Additive Increase Multiplicative Decrease), a timeout cuts cwnd to 1 and halves ssthresh; a triple-duplicate-ACK triggers fast retransmit (resend the lost segment without waiting for the timer) and fast recovery (cut cwnd in half, skip slow start).

cwnd
  ▲  slow start      congestion avoidance
  │  /││││      /││││││││
  │ / ││││     / ││││││││
  │/  ││││    /  ││││││  ← loss: halve cwnd (AIMD)
  └───┴───────┴─────────→ time

The interview summary: slow start ramps up exponentially, congestion avoidance grows linearly, loss cuts it back (multiplicative) — hence AIMD. TCP is fair and self-limiting precisely because every sender behaves this way.

11. What are the TCP connection states and why does TIME_WAIT last 2MSL?

A TCP connection’s life is a state machine. The client’s path:

CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED

The server’s: LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED.

Key states:

• SYN_SENT / SYN_RCVD — handshake in progress.
• ESTABLISHED — data flows.
• FIN_WAIT_1 / FIN_WAIT_2 / CLOSE_WAIT / LAST_ACK — the 4-way termination (each side sends FIN and waits for the other’s ACK).
• TIME_WAIT — the side that initiated close stays here after sending its last ACK.

Why TIME_WAIT = 2 × MSL (Maximum Segment Lifetime)? Two reasons:

1. Ensure the final ACK is received. If it’s lost, the other side retransmits its FIN, and the wait lets this side re-ACK it.
2. Allow old segments to die out of the network. MSL is the longest a segment can survive in transit, so 2MSL guarantees no late duplicate packets from the old connection linger to be mistaken for a new connection’s data.

You can’t reuse that (IP, port) pair during TIME_WAIT — that’s why busy servers tune SO_REUSEADDR. The one-liner: TIME_WAIT exists so the last ACK isn’t lost and so stale packets expire before the connection is reused.