OSI and TCP/IP Models

The OSI Model Explained #

The Open Systems Interconnection (OSI) model is a conceptual framework that divides network communication into seven distinct layers. For QA engineers, this model provides a systematic way to diagnose where network problems occur — instead of saying “it doesn’t work,” you can pinpoint the exact layer causing the failure.

Think of the OSI model like a postal system. When you send a letter, it goes through multiple stages: you write the content (Application), put it in an envelope with an address (Presentation/Session), the post office routes it (Transport/Network), the mail truck delivers it (Data Link), and the physical road carries the truck (Physical). Each layer has a specific job.

Layer 7: Application #

The layer closest to the user. Protocols like HTTP, HTTPS, FTP, SMTP, and DNS operate here. When you get a 404 Not Found or 500 Internal Server Error, you are dealing with an Application layer issue.

QA relevance: API testing, web testing, and most functional testing happen at this layer.

Layer 6: Presentation #

Handles data formatting, encryption, and compression. SSL/TLS encryption operates at this layer. Character encoding issues (UTF-8 vs. ASCII) are Presentation layer problems.

QA relevance: Encoding bugs, SSL certificate errors, and data format mismatches.

Layer 5: Session #

Manages sessions between applications — establishing, maintaining, and terminating connections. Session tokens and authentication sessions relate to this layer.

QA relevance: Session timeout testing, session persistence across load balancers.

Layer 4: Transport #

Provides end-to-end communication between processes. TCP and UDP are the primary protocols. Port numbers live here. “Connection refused” and “connection timeout” errors originate at this layer.

QA relevance: Connection issues, port availability, timeout configurations.

Layer 3: Network #

Handles logical addressing (IP addresses) and routing. Ping and traceroute operate here. “Destination unreachable” and routing errors are Network layer problems.

QA relevance: IP connectivity, DNS resolution (partially), network routing issues.

Layer 2: Data Link #

Manages physical addressing (MAC addresses) and frame delivery on a local network. Ethernet and WiFi operate here.

QA relevance: WiFi connectivity issues during mobile testing, network switch problems.

Layer 1: Physical #

The actual hardware — cables, wireless signals, network interface cards. Signal strength and physical connectivity issues are here.

QA relevance: Rarely directly relevant, but important when testing in hardware environments or IoT.

The TCP/IP Model #

While the OSI model is a theoretical framework, the TCP/IP model reflects how the internet actually works. It condenses the seven OSI layers into four practical layers:

The TCP/IP model is what runs every network you interact with. When debugging real-world issues, you will encounter TCP/IP terminology more often than OSI terminology. However, the OSI model provides finer granularity that helps when explaining problems to network engineers.

The key difference: OSI is a reference model for understanding; TCP/IP is the implementation that powers the internet. Both are valuable for QA engineers — OSI for precise communication about problems, TCP/IP for understanding what actually happens on the wire.

Network Layers and QA #

As a QA engineer, you do not need deep expertise in every layer. Most of your work happens at three layers:

Application Layer (HTTP, API Testing) #

This is where 80% of QA network debugging occurs. HTTP status codes, API response payloads, header values, and content types are all Application layer concerns. Tools like Postman, curl, and browser DevTools inspect this layer.

Common symptoms: Wrong response data, incorrect status codes, missing headers, authentication failures.

Transport Layer (TCP/UDP, Connection Issues) #

When you cannot connect to a service at all, the problem is usually at the Transport layer. “Connection refused” means the port is not listening. “Connection timed out” means packets are not getting through.

Common symptoms: Cannot connect, connection drops, slow data transfer, port conflicts.

Diagnostic commands:

# Check if a port is open
nc -zv hostname 8080

# View active connections and listening ports
ss -tlnp

# Test TCP connectivity
telnet hostname 443

Network Layer (IP Routing, DNS) #

When a host is completely unreachable, the issue is likely at the Network layer. Ping failures, traceroute dead ends, and DNS resolution failures point here.

Common symptoms: Host unreachable, high latency, packets lost in transit.

Diagnostic commands:

# Test basic connectivity
ping hostname

# Trace the route to a host
traceroute hostname

# Check DNS resolution
nslookup hostname
dig hostname

Advanced Layer Analysis #

Understanding Protocol Data Units (PDUs) at each layer helps QA engineers read network captures and diagnose complex issues:

Encapsulation and Packet Size #

As data moves down the layers, each layer adds its own header. This encapsulation increases the total size:

• Application data: variable size
• TCP header: 20-60 bytes
• IP header: 20-60 bytes
• Ethernet frame header: 14 bytes + 4 bytes trailer

The Maximum Transmission Unit (MTU) — typically 1500 bytes for Ethernet — limits the size of a single frame. When a packet exceeds the MTU, it must be fragmented. Fragmentation issues cause mysterious partial failures that are difficult to diagnose without understanding encapsulation.

QA scenario: An API endpoint works for small payloads but fails for large ones. The cause may be MTU-related fragmentation where some fragments are dropped by a firewall that does not reassemble fragmented packets.

Common Layer-Specific Bugs QA Encounters #

Application layer bugs:

• API returns wrong Content-Type header
• CORS headers missing on specific endpoints
• Caching headers cause stale data

Transport layer bugs:

• Connection pool exhaustion under load
• TCP keepalive timeout mismatch between client and server
• Port conflicts between services in test environments

Network layer bugs:

• DNS caching returns stale IP after deployment
• Routing tables not updated after infrastructure change
• TTL too low causing packets to expire in transit

Hands-On Exercise #

Given the following five network error scenarios, identify the OSI layer where each occurs and the diagnostic tool you would use:

1. Scenario: curl: (7) Failed to connect to api.example.com port 443: Connection refused
2. Scenario: ping: cannot resolve api.example.com: Unknown host
3. Scenario: curl: (60) SSL certificate problem: certificate has expired
4. Scenario: HTTP/1.1 502 Bad Gateway returned by the load balancer
5. Scenario: traceroute shows packets timing out after hop 5

Pro Tips #

• When debugging, work from the bottom up: can you ping the host? Can you connect to the port? Can you get an HTTP response? This systematic approach saves time.
• Most QA work happens at layers 4 (Transport) and 7 (Application), but understanding lower layers helps you communicate precisely with network and DevOps engineers.
• “Connection refused” is a Transport layer issue; “404 Not Found” is an Application layer issue. Knowing the difference immediately narrows your investigation.
• MTU issues cause mysterious partial failures — when large API responses fail but small ones succeed, consider fragmentation.
• Use traceroute to identify which network hop is causing latency — the output shows exactly where packets slow down or get lost.

Key Takeaways #

1. The OSI/TCP-IP models provide a framework for systematically diagnosing network issues during testing
2. Most QA-relevant issues occur at the Application (HTTP errors) and Transport (connection issues) layers
3. Bottom-up troubleshooting (ping, then connect, then request) is the most efficient diagnostic approach
4. Understanding network layers helps QA communicate effectively with network engineers and DevOps teams