Numerical Problems in Computer Networks
Protocol Analysis
Read aloud is unavailable in this browser.
Decoding the Language of Networks
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.
Header Structure and Field Analysis
Understanding protocol headers is fundamental to protocol analysis. Each field exists for a reason, and knowing those reasons helps you predict protocol behavior.
Ethernet Frame Header (14 bytes + 4 byte FCS)
| Destination MAC | Source MAC | Type/Length |
| 6 bytes | 6 bytes | 2 bytes |
- Destination MAC: Where the frame should go (or broadcast FF:FF:FF:FF:FF:FF)
- Source MAC: Where the frame originated
- Type: 0x0800 = IPv4, 0x0806 = ARP, 0x86DD = IPv6
- FCS (4 bytes at end): CRC-32 for error detection
IPv4 Header (20-60 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:
- Version (4 bits): 4 for IPv4
- IHL (4 bits): Header length in 32-bit words (5 = 20 bytes minimum)
- TTL (8 bits): Prevents infinite routing loops
- Protocol (8 bits): 6 = TCP, 17 = UDP, 1 = ICMP
- Checksum: Header integrity only (not data)
TCP Header (20-60 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
- SYN: Connection establishment
- ACK: Acknowledgment valid
- FIN: Connection termination
- RST: Connection reset
- PSH: Push data immediately
- URG: Urgent data present
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.
UDP: The Minimal Protocol
UDP Header (8 bytes only)
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:
- Source Port (16 bits): Sender's port
- Destination Port (16 bits): Receiver's port
- Length (16 bits): Header + data in bytes
- Checksum (16 bits): Optional in IPv4, mandatory in IPv6
What UDP Doesn't Have (And Why)
| 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:
- Lower latency (no handshake, no ACK wait)
- Lower overhead (8 vs 20+ bytes per packet)
- Application control (app decides what to retransmit)
- Broadcast/multicast support (no connection needed)
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.
Protocol Comparison Framework
When comparing protocols, evaluate across these dimensions:
- Reliability: Does it guarantee delivery?
- Ordering: Does it guarantee in-order delivery?
- Connection State: Stateful (connection-oriented) or stateless (connectionless)?
- Latency: How much delay does the protocol add?
- Overhead: How many bytes per packet/message?
- Throughput: Does it have flow/congestion control?
- Multiplexing: Can multiple streams share a connection?
- Security: What security features are built in?
| 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 |
HTTP Protocol Comparison
| 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 |
Protocol Overhead Analysis
Overhead analysis quantifies how much bandwidth is consumed by protocol headers versus actual data.
Calculating Protocol Efficiency
$$\eta = \frac{Payload}{Payload + Total\ Headers}$$
For TCP/IP over Ethernet:
- Ethernet: 14 + 4 = 18 bytes
- IP: 20 bytes (no options)
- TCP: 20 bytes (no options)
- Total overhead: 58 bytes per packet
Example 1: VoIP Overhead Analysis
Compare overhead for different VoIP configurations.
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**Explanation
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.
Example 2: Protocol Selection by Overhead
For a sensor sending 10-byte readings every 100ms, compare TCP vs UDP.
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)Explanation
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.
Packet Capture Interpretation
Being able to read and interpret packet captures is essential for troubleshooting and protocol analysis.
TCP Handshake Example
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:
- Client sends SYN with initial sequence number (ISN)
- Server responds with SYN-ACK, its own ISN, acknowledging client's ISN+1
- Client sends ACK, acknowledging server's ISN+1
Connection is now established.
Common Patterns to Recognize
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.
Connection Termination
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 Protocol Analysis
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 |
BGP: The Internet's Routing Protocol
| 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):
- Highest Local Preference
- Shortest AS Path
- Lowest Origin (IGP < EGP < Incomplete)
- Lowest MED
- eBGP over iBGP
- Lowest IGP metric to next-hop
- Oldest route
- Lowest router-id
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.
Protocol Trade-off Analysis
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 |
Selecting Protocols by Use Case
| 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.
KEEP LEARNING
There’s more to understand.
You’re reading the introduction. Create a free account to read the complete lesson, save notes and keep track of your progress.