TCP/IP and the path of a request

OSI and TCP/IP models, IP, ports, TCP vs UDP

The OSI model has 7 layers, TCP/IP has 4. In an interview you do not need to recite all the layers; what helps is being able to assign a problem to a layer:

Link/network access (Ethernet, Wi-Fi): the cable, MAC addresses, radio quality;
Network (IP): addressing and routing packets between networks. "Host unreachable", packet loss, MTU;
Transport (TCP, UDP): ports, reliability, ordering. "Connection refused", "timeout", dropped connections;
Application (HTTP, DNS, TLS, WebSocket): what QA works with every day: methods, headers, response codes.

When a test fails with "ECONNREFUSED", that is the transport layer (nobody listens on the port), not a "bug in HTTP". When a 500 arrives, TCP and HTTP work fine and the problem is in the application.

IP and ports. An IP address (IPv4 or IPv6) points to a host, a port (0–65535) points to a process on that host. Common ports: 80 (HTTP), 443 (HTTPS), 53 (DNS), 22 (SSH), 5432 (PostgreSQL). An "IP + port" pair is called a socket; a connection is uniquely defined by the addresses and ports of both sides. localhost is 127.0.0.1 (IPv6: ::1); a service listening only on 127.0.0.1 is unreachable from outside a container or machine, while 0.0.0.0 means "all interfaces".

TCP vs UDP.

TCP: a connection, guaranteed delivery, ordering, flow and congestion control. The price: a handshake and latency on loss. HTTP/1.1, HTTP/2, WebSocket, databases;
UDP: connectionless, no guarantees or ordering, minimal overhead. DNS queries, video/voice, games, and also QUIC (which HTTP/3 runs on) that implements reliability itself.

DNS: name resolution, records, TTL and cache

DNS turns a name into an IP address. A typical chain: browser → OS cache (and the hosts file) → the provider's or corporate recursive resolver (8.8.8.8, 1.1.1.1) → if needed the root servers → TLD servers (.com) → the domain's authoritative server that gives the answer. Each level caches the result.

A: name → IPv4; AAAA: name → IPv6;
CNAME: an alias to another name (www → app.example.net). A CNAME is normally not placed at the domain apex because it cannot coexist with other records;
MX: mail servers, TXT: free text (SPF, domain ownership checks), NS: authoritative servers;
HTTPS/SVCB: hints for the client (for example that the server supports HTTP/3).

TTL is how many seconds an answer may be kept in a cache. A long TTL means fewer queries but slower rollout of changes. That is why the TTL is lowered in advance before a server migration. Negative answers (NXDOMAIN) are cached too.

What it means for QA.

"Works on my machine but not on a colleague's" after a DNS change: an old answer in a cache (OS, browser, corporate resolver, a JVM/Node process);
Different answers in different regions: geo-balancing or a CDN;
ENOTFOUND in Node or ERR_NAME_NOT_RESOLVED in Chrome: the domain did not resolve (a typo, a missing record, an unreachable resolver, a VPN);
Checks: dig example.com, dig +short example.com AAAA, dig @1.1.1.1 example.com (another resolver), nslookup example.com. Flush the OS cache: ipconfig /flushdns (Windows).

TCP handshake, TLS 1.3 and certificates

TCP: the three-way handshake. The client sends SYN, the server replies SYN-ACK, the client sends ACK. After that data can flow; this costs one RTT (a full round trip). Closing is done with FIN from both sides, while RST aborts a connection immediately. This is why:

Connection refused: nobody listens on the port, the OS answers RST right away;
Timeout: no answer at all (a firewall drops packets, the host is down, there is no route);
Connection reset: there was a connection but the other side aborted it (RST): a process crash, an idle timeout on a balancer, a closed socket.

TLS provides three things: encryption, integrity and server authentication (and client authentication when needed, mTLS). In TLS 1.3 a full handshake takes one RTT: in ClientHello the client immediately sends the supported ciphers, a key share and SNI (the host name, so one IP can serve many domains); the server answers with its share, the certificate and a confirmation; everything after that is encrypted. On session resumption 0-RTT is possible, but this early data is replayable, so it is allowed only for safe requests. The obsolete TLS 1.0/1.1 are switched off.

A certificate binds a public key to a name. The client checks: the signature chain up to a trusted root authority, the validity period, that the requested name matches the SAN entries (not only CN) and the revocation status (often via OCSP stapling). Typical errors:

ERR_CERT_DATE_INVALID: the certificate has expired (or the machine clock is wrong);
ERR_CERT_COMMON_NAME_INVALID: the name does not match the certificate (access by IP or by another domain);
ERR_CERT_AUTHORITY_INVALID: a self-signed certificate or a missing intermediate in the chain;
In a corporate network TLS inspection replaces certificates with its own root: tools without that root complain about trust.

In Playwright, self-signed certificates on test environments are allowed with the ignoreHTTPSErrors: true option (in use or in a context). Enable it only for harmless test environments, not "just in case".

What happens when you type a URL in the browser

A classic question. A strong answer is not a list of words but a sequence with time costs and failure points.

URL parsing: scheme (https), host, port (443 by default), path, query. The browser checks its HSTS list: if the host is there, http:// is replaced by https:// immediately;
Caches: the browser HTTP cache (a fresh response per Cache-Control can be served with no request at all), Service Worker;
DNS: browser cache → OS → resolver → authoritative server. The result is an IP (A/AAAA). Cost: from 0 to hundreds of ms; failure point: NXDOMAIN, an unreachable resolver;
TCP handshake (1 RTT) to the IP on port 443. Failure points: refused, timeout;
TLS handshake (1 RTT in TLS 1.3): SNI, certificate validation, key agreement. The application protocol is negotiated here too (ALPN): h2 or http/1.1. For HTTP/3 the browser learns about QUIC from the Alt-Svc header or the HTTPS DNS record and tries it in parallel or on the next request;
HTTP request: GET /path with headers (Host, Cookie, Accept, ...). It may pass a CDN, a load balancer, a reverse proxy and other hops before reaching the application;
Response: the first byte (TTFB) shows the server processing time plus the path; then the body downloads. Redirects (3xx) repeat part of the chain;
Rendering: HTML parsing, loading subresources (CSS, JS, images, API calls): each may need its own DNS/TCP/TLS (for another domain) or reuse an already open connection; then JS execution.

How to use it: the Network tab in DevTools shows at which exact step the time goes (DNS Lookup, Initial connection, SSL, Waiting, Content Download), so "the site is slow" becomes a concrete hypothesis.