Loading learning content...
Protocol analysis is the skill of understanding how network protocols work at the bit level, comparing their characteristics, and making informed decisions about which to use. Whether you're debugging a network issue with Wireshark, answering an interview question about TCP vs UDP, or designing a system that must meet specific latency requirements, protocol analysis skills are essential.
Why protocol analysis matters: Networks are built from layered protocols, each with specific strengths and weaknesses. Understanding protocol internals lets you predict performance, diagnose problems, and select the right tool for each job. In interviews, protocol analysis questions test whether you truly understand networking or just memorized surface-level facts.
By the end of this page, you will: (1) Analyze header structures and calculate overhead, (2) Compare protocols across multiple dimensions (reliability, latency, ordering, etc.), (3) Interpret packet captures and identify issues, (4) Evaluate trade-offs to select appropriate protocols, and (5) Solve protocol-related interview problems with confidence.
Understanding protocol headers is fundamental to protocol analysis. Each field exists for a reason, and knowing those reasons helps you predict protocol behavior.
| Destination MAC | Source MAC | Type/Length |
| 6 bytes | 6 bytes | 2 bytes |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if IHL > 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key fields and their purposes:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | Res |N|C|E|U|A|P|R|S|F| |
| Offset| |S|W|C|R|C|S|S|Y|I| Window |
| | | |R|E|G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if Data Offset > 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Critical TCP flags:
A common interview technique: 'Why does TCP have sequence numbers but UDP doesn't?' Because TCP guarantees in-order delivery (needs to reorder) and reliability (needs to detect gaps). UDP provides neither, so sequence numbers would be overhead with no benefit. Every field exists because the protocol needs it—understanding why helps you remember what.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
That's it. Just 8 bytes containing:
| Feature | TCP Has | UDP Has | Implication |
|---|---|---|---|
| Sequence numbers | ✓ | ✗ | No ordering guarantee |
| Acknowledgments | ✓ | ✗ | No delivery confirmation |
| Window | ✓ | ✗ | No flow control |
| Connection state | ✓ | ✗ | No handshake overhead |
| Retransmission | ✓ | ✗ | Lost data stays lost |
| Congestion control | ✓ | ✗ | Can overwhelm network |
UDP's philosophy: "Just send it and hope for the best."
This minimalism is a feature, not a bug. It enables:
Real-time media (VoIP, video) prefers UDP because retransmitting a late packet makes things worse—by the time it arrives, it's no longer useful. Games use UDP because a fresh position update matters more than an old one. DNS uses UDP because queries fit in one packet and retrying is simpler than connection setup.
When comparing protocols, evaluate across these dimensions:
| Property | TCP | UDP | QUIC | SCTP |
|---|---|---|---|---|
| Reliability | Full | None | Full | Full (optional) |
| Ordering | Total | None | Per-stream | Partial/Total |
| Connection | Required (3-way) | None | 0-RTT possible | 4-way |
| Handshake RTT | 1 RTT | 0 RTT | 0-1 RTT | 2 RTT |
| Header Size | 20-60B | 8B | Variable | 12B+ |
| Streams | 1 | N/A | Many | Many |
| HOL Blocking | Yes | No | No (per-stream) | No |
| Encryption | Optional (TLS) | Optional (DTLS) | Always (built-in) | Optional |
| NAT Traversal | Moderate | Good | Good | Poor |
| Property | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP | TCP | QUIC (UDP) |
| Connection | Per-request or persistent | Single, multiplexed | Single, multiplexed |
| Header Format | Text | Binary | Binary |
| Header Compression | None | HPACK | QPACK |
| Streams | Serial (pipelining broken) | Multiple | Multiple |
| HOL Blocking | Request level | TCP level | None |
| Server Push | No | Yes | Yes |
| Typical Latency | High | Medium | Low |
Overhead analysis quantifies how much bandwidth is consumed by protocol headers versus actual data.
$$\eta = \frac{Payload}{Payload + Total\ Headers}$$
For TCP/IP over Ethernet:
G.711 codec: 160 bytes payload (20ms @ 8kHz)
Headers without compression:
- RTP: 12 bytes
- UDP: 8 bytes
- IP: 20 bytes
- Ethernet: 18 bytes
With cRTP (compressed RTP): 2-4 bytes replaces RTP+UDP+IPWithout compression:
Overhead = 12 + 8 + 20 + 18 = 58 bytes
Efficiency = 160 / (160 + 58) = 73.4%
Bandwidth = 160+58 bytes × 8 bits × 50 pps = 87.2 kbps
With cRTP (3 bytes avg):
Overhead = 3 + 18 = 21 bytes
Efficiency = 160 / (160 + 21) = 88.4%
Bandwidth = 181 × 8 × 50 = 72.4 kbps
**Savings: 17% bandwidth reduction**VoIP's small payloads make overhead significant. Header compression (cRTP, ROHC) dramatically improves efficiency, which is why it's essential for bandwidth-constrained links like cellular or satellite.
Payload: 10 bytes per reading
Frequency: 10 readings/second
Over Ethernet + IPv4With TCP:
Per-packet overhead = 18 + 20 + 20 = 58 bytes
Minimum Ethernet frame = 64 bytes (padding required)
Actual: 64 bytes (padding 10+58=68 to 64... wait, 68>64)
Actual: 10 + 58 = 68 bytes per reading
Bandwidth: 68 × 8 × 10 = 5,440 bps
Efficiency: 10/68 = 14.7%
With UDP:
Per-packet overhead = 18 + 20 + 8 = 46 bytes
Total: 10 + 46 = 56 bytes (padded to 64)
With padding: 64 bytes
Bandwidth: 64 × 8 × 10 = 5,120 bps
Efficiency: 10/64 = 15.6%
Improvement: Minimal (1% efficiency gain)For tiny payloads, even UDP's smaller header doesn't help much because Ethernet's minimum frame size dominates. The real advantage of UDP here is eliminating connection overhead for many sensors and avoiding TCP's buffering, which could add latency.
Being able to read and interpret packet captures is essential for troubleshooting and protocol analysis.
1. 192.168.1.100 → 93.184.216.34: SYN, Seq=0
2. 93.184.216.34 → 192.168.1.100: SYN-ACK, Seq=0, Ack=1
3. 192.168.1.100 → 93.184.216.34: ACK, Seq=1, Ack=1
This is the three-way handshake:
Connection is now established.
Retransmission:
1. A → B: Seq=1000, Len=1460
2. A → B: Seq=1000, Len=1460 [TCP Retransmission]
Same sequence number sent again = packet was lost or ACK was lost.
Duplicate ACK:
1. B → A: Ack=1000
2. B → A: Ack=1000 [Dup ACK]
3. B → A: Ack=1000 [Dup ACK]
Three duplicate ACKs trigger fast retransmit.
Zero Window:
1. A → B: Seq=5000, Len=1460
2. B → A: Ack=6460, Win=0 [Zero Window]
3. A → B: [TCP Zero Window Probe]
4. B → A: Ack=6460, Win=8192 [Window Update]
Receiver buffer is full; sender pauses until window opens.
Normal Close (FIN-based):
1. A → B: FIN-ACK, Seq=10000
2. B → A: ACK, Ack=10001
3. B → A: FIN-ACK, Seq=8000
4. A → B: ACK, Ack=8001
Abrupt Close (RST):
1. A → B: RST
No acknowledgment, immediate close. Indicates error or rejection.
Watch for: (1) Many retransmissions = packet loss or congestion, (2) RST after SYN = port closed or firewalled, (3) Zero window = application not reading fast enough, (4) Out-of-order packets = network reordering or loss, (5) ICMP unreachables = routing or filtering issues.
Routing protocols differ in algorithm complexity, convergence speed, and scalability.
| Property | RIP | OSPF | EIGRP | IS-IS |
|---|---|---|---|---|
| Algorithm | Distance Vector | Link State | Advanced DV (DUAL) | Link State |
| Metric | Hop count (max 15) | Cost (bandwidth) | Composite (BW, delay) | Cost |
| Convergence | Slow (30s updates) | Fast (immediate) | Very fast | Fast |
| Scalability | Small networks only | Large (with areas) | Large | Very large |
| Protocol | UDP 520 | IP 89 | IP 88 | Directly over L2 |
| VLSM Support | RIPv2 only | Yes | Yes | Yes |
| Authentication | RIPv2: MD5 | MD5, SHA | MD5 | MD5, SHA |
| CPU/Memory | Low | High | Medium | High |
| Property | Value |
|---|---|
| Type | Path Vector |
| Transport | TCP 179 |
| Metric | Path attributes (AS path, etc.) |
| Decision | Complex policy-based |
| Convergence | Minutes (intentionally slow) |
| Table Size | 900K+ routes (full table) |
| Use Case | Inter-domain routing |
BGP Path Selection (simplified order):
When asked to compare: RIP uses hop count (can choose a 15-hop path over a faster 16-hop path—bad), has 15-hop limit (fragile), converges slowly (30-second updates), broadcasts updates (bandwidth waste). OSPF uses bandwidth-based cost (smart), scales with areas (hierarchical), converges immediately (link-state flooding), multicasts efficiently. OSPF wins for anything beyond the smallest networks.
Every protocol design involves trade-offs. Understanding these helps you select the right protocol for each use case.
| Trade-off | Option A | Option B | Examples |
|---|---|---|---|
| Reliability vs Latency | Guarantee delivery | Minimize delay | TCP vs UDP |
| Overhead vs Features | Rich functionality | Minimal headers | TCP vs UDP |
| Stateful vs Stateless | Track connections | No state management | TCP vs UDP, HTTP vs REST |
| In-band vs Out-of-band | Same channel for control and data | Separate channels | HTTP/2 vs FTP |
| Text vs Binary | Human readable | Compact/fast to parse | HTTP/1.1 vs HTTP/2 |
| Pull vs Push | Client requests data | Server sends updates | HTTP vs WebSocket |
| Encryption vs Speed | Security | Performance | HTTPS vs HTTP |
| Use Case | Recommended Protocol | Why |
|---|---|---|
| Web browsing | HTTP/2 or HTTP/3 | Multiplexing, compression |
| API calls | HTTPS + JSON/gRPC | Security, efficiency |
| File transfer | SFTP or HTTPS | Security, resume support |
| SMTP + TLS | Standard, universal | |
| Video streaming | DASH/HLS over HTTPS | Adaptive, cacheable |
| Live video | WebRTC or RTMP | Low latency |
| VoIP | RTP/SRTP over UDP | Real-time, jitter buffer |
| Gaming | Custom UDP | Lowest latency |
| IoT sensors | MQTT or CoAP | Low overhead, pub/sub |
| Database sync | TCP (proprietary) | Reliability essential |
QUIC (HTTP/3's transport) attempts to have it all: reliability like TCP, low latency like UDP, built-in encryption, stream multiplexing without HOL blocking. It's the result of decades of learning what works. When asked 'what's the future of transport protocols?', QUIC is a strong answer.
When troubleshooting or analyzing network behavior, work systematically through the layers.
Layer 1 (Physical):
Layer 2 (Data Link):
Layer 3 (Network):
Layer 4 (Transport):
Application Layer:
Let's examine common interview question patterns and how to approach them.
Question: Explain why DNS uses UDP instead of TCP for most queries.**Answer structure:**
1. Query-response fits in single packet (no segmentation needed)
2. No connection overhead (3-way handshake would double latency)
3. Stateless operation (server handles millions of clients)
4. Simple retry mechanism (just resend if no response)
5. Low overhead (8-byte UDP vs 20-byte TCP header)
**But note:** DNS uses TCP for:
- Zone transfers (large, must be reliable)
- Responses > 512 bytes (truncated over UDP)
- DNSSEC (larger responses)
- Modern DNS (TCP becoming more common)This question tests whether you understand the trade-offs that led to protocol design decisions. Always consider both the primary design choice AND the exceptions.
Walk through the protocol interactions when accessing https://example.com**Protocol sequence:**
1. **DNS lookup** (if not cached):
- UDP to local resolver (port 53)
- Resolver recursively queries root → TLD → authoritative
- Returns IP address
2. **TCP handshake** to port 443:
- SYN → SYN-ACK → ACK (1 RTT)
3. **TLS handshake**:
- ClientHello → ServerHello + Certificate
- Key exchange, verify certificate
- Finished (1-2 RTT depending on version)
4. **HTTP request**:
- GET / HTTP/2
- Headers (host, accept, cookies, etc.)
5. **HTTP response**:
- Status 200 OK
- Headers + HTML body
6. **Render and fetch resources**:
- Parse HTML, discover CSS/JS/images
- Parallel requests (HTTP/2 multiplexing)
7. **Connection kept open** for subsequent requestsThis classic question tests comprehensive knowledge across protocols. Mention specific protocol versions, port numbers, and handshake sequences to demonstrate depth.
What advantages does QUIC have over TCP for HTTP/3?| Aspect | TCP | QUIC |
|--------|-----|------|
| Handshake | 1 RTT (3 RTT with TLS) | 0-1 RTT (built-in crypto) |
| HOL blocking | Stream blocks on any loss | Per-stream, independent |
| Connection migration | IP change = new connection | Connection ID survives |
| Multiplexing | Application-layer only | Native streams |
| Security | Optional (TLS) | Mandatory (built-in) |
| Middlebox ossification | Prone to interference | Encrypted, opaque |
| Congestion control | Kernel-level, hard to iterate | Userspace, rapid evolution |
**QUIC wins for:**
- Mobile users (connection migration)
- High-latency paths (fewer RTTs)
- Lossy networks (no HOL blocking)
- Fast iteration (not stuck in kernel)Comparison questions require structured thinking. Use a table or clear categories, then summarize when each option is preferable.
Protocol analysis combines theoretical knowledge with practical interpretation skills. Here are the essential takeaways:
Congratulations! You have completed the Numerical Problems module. You now have the quantitative skills to analyze network efficiency, calculate delays and throughput, design IP addressing schemes, and evaluate protocol trade-offs. These skills form the foundation for network design, troubleshooting, and acing technical interviews.