Computer Networking Review: OSI, TCP/UDP, HTTP, DNS, CDN, and WebSocket

Networking fundamentals matter for frontend, backend, and cloud engineering.

OSI and TCP/IP

The OSI model has seven layers:

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

TCP/IP is often simplified into four layers: network interface, internet, transport, and application.

TCP and UDP

TCP is connection-oriented and reliable. It uses a three-way handshake and a four-way teardown. It is suitable for file transfer, web requests, and database connections.

UDP is connectionless and lightweight. It does not guarantee delivery. It is suitable for real-time audio/video, games, and DNS.

HTTP and HTTPS

HTTP is plaintext. HTTPS adds TLS encryption.

Common methods:

• GET: read
• POST: create
• PUT: full update
• PATCH: partial update
• DELETE: delete

Common status codes:

• 200: success
• 301/302: redirect
• 400: bad request
• 401: unauthenticated
• 403: forbidden
• 404: not found
• 500: server error

DNS and CDN

DNS resolves domain names into IP addresses. CDN caches static assets at edge locations closer to users.

WebSocket

WebSocket is a long-lived connection protocol. It is useful for chat, notifications, and collaborative editing.

HTTP/2

HTTP/2 improves over HTTP/1.1 with multiplexing, header compression, and more efficient connection reuse.

Deeper Notes

When reviewing this topic, do not memorize names only. Focus on OSI/TCP-IP, TCP/UDP, HTTP/HTTPS, DNS, CDN, WebSocket, and HTTP/2. If this stays at the definition level, it becomes hard to explain in interviews or apply in projects. A stronger way to study it is to place it in a concrete scenario: who calls it, where the input comes from, what happens on failure, and whether data or state can be processed twice.

• Understand networking through a full request path: DNS, connection setup, TLS, HTTP, cache, proxy, and server response.
• Interview questions often focus on edge cases: packet loss, retransmission, congestion, long connections, CORS, and certificate trust.
• Debug by layer: DNS, connectivity, TLS, HTTP status, then application logic.

In a real project, use it as a decision framework: identify inputs, constraints, failure modes, and observability before choosing a specific tool or pattern. If a solution looks simple, keep asking whether it still works when scale grows, permissions change, recovery matters, and more people collaborate on it.

Practical Checklist

• Identify where this concept sits in the system: development-time constraint, runtime behavior, infrastructure capability, or collaboration workflow.
• Write one minimal working example and one failure example; only knowing the happy path is usually not enough.
• Record common misuses: edge cases, permission assumptions, performance assumptions, sync/async differences, or environment differences.
• Connect the concept to a project experience so that an interview answer can be grounded in real tradeoffs.
• End with one sentence about tradeoff: what it gives up and what it buys.

Self-Check Questions

1. What core problem does this topic solve?
2. What alternatives exist, and what are their costs?
3. Where are the most likely edge cases?
4. How would code, tests, or monitoring prove that it is reliable?

Applied Scenario

Study this topic through one page load. The browser resolves DNS, establishes TCP/TLS, sends an HTTP request, may pass through CDN, proxy, and load balancer, and finally receives a server response. When debugging, avoid guessing application bugs first. Locate the layer: DNS resolution, port connectivity, certificate validity, status code, response body, then application logic.

Common Pitfalls:

• Blaming backend code for every access failure.
• Ignoring DNS cache, proxy behavior, and CDN layers.
• Not distinguishing 401, 403, 404, 502, and 504.