Mạng máy tính & Các giao thứcNetworking & Protocols

Part of the DevOps Roadmap knowledge base.

Overview

Networking is the substrate every distributed system runs on. Whether you are debugging why a pod can’t reach a database, terminating TLS at a load balancer, or writing a security group rule, you are working with the same handful of protocols: IP, TCP/UDP, DNS, HTTP, and TLS. A DevOps engineer who understands these layers can reason about failures precisely (“is this a DNS problem, a routing problem, or an application problem?”) instead of guessing — which is the difference between a five-minute fix and a two-hour outage.

The classic mental models are the OSI 7-layer model and the practical 4-layer TCP/IP stack. OSI is a teaching and vocabulary tool (“L4 load balancer”, “L7 firewall”); TCP/IP is what real networks implement. On top of these sit the application protocols you touch daily: DNS for naming, HTTP(S) for almost all service traffic, TLS for encryption and identity, and SSH for administration.

Cloud infrastructure makes networking programmable — VPCs, subnets, route tables, NAT gateways, security groups — but the underlying concepts are unchanged. Mastering CIDR math, DNS resolution, and the TLS handshake pays off across every cloud and every on-prem environment. The goal of this page is to give you enough of a model that packet-level tools (dig, curl -v, tcpdump) become a conversation with the network rather than an incantation.

Fundamentals

OSI model vs TCP/IP stack

In practice engineers use OSI numbers as vocabulary (“L4 vs L7 load balancing”) while real stacks behave like TCP/IP. Each layer wraps the one above it in a header (encapsulation): an HTTP request becomes a TCP segment, inside an IP packet, inside an Ethernet frame.

TCP vs UDP — the two transport protocols you meet constantly:

A TCP connection ends with a FIN handshake; an abrupt RST means “no one is listening” or “connection forcibly closed” — a very common signal when a port is closed or an app crashed. MTU (typically 1500 bytes) matters: packets larger than the path MTU are fragmented or dropped, and mismatched MTU (common with VPN/overlay networks) causes mysterious hangs on large payloads.

IP addressing, subnets, and CIDR

CIDR notation 10.0.0.0/16 means the first 16 bits are the network prefix, leaving 2^16 = 65,536 addresses. The prefix length is the number of leading 1 bits in the subnet mask.

Key facts:

• On traditional networks a /24 has 254 usable addresses (network address .0 and broadcast .255 are reserved). Cloud providers reserve extra addresses — AWS reserves 5 per subnet (network, VPC router, DNS, future use, broadcast), so a /24 gives 251 usable.
• Private ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Also useful: 100.64.0.0/10 (carrier-grade NAT, used by some clouds/VPNs) and 169.254.0.0/16 (link-local, cloud metadata at 169.254.169.254).
• Subnetting: splitting a larger block into smaller ones. Halving a prefix (e.g. /24 → two /25s) doubles the number of subnets and halves the hosts each.
• Typical VPC design: a /16 VPC split into /20 or /24 subnets, one set of public and one set of private subnets per availability zone for high availability.
• IPv6 removes the scarcity problem (128-bit addresses, /64 per subnet is standard) and eliminates the need for NAT; dual-stack deployments are increasingly common.

NAT (Network Address Translation) lets private addresses share public IPs. A NAT gateway gives private subnets outbound internet access (for updates, API calls) without exposing them to inbound connections — a cornerstone of the “private subnet” pattern where app and DB tiers have no public IP at all.

ip addr                          # interfaces and addresses
ip route                         # routing table (which next-hop for which prefix)
ping -c 3 8.8.8.8                # L3 reachability
traceroute example.com           # path discovery, hop by hop
mtr example.com                  # continuous traceroute + loss stats
ss -tlnp                         # listening TCP sockets and owning processes
nc -zv host 443                  # is the port open? (L4 probe)
ipcalc 10.0.0.0/20               # subnet math helper

DNS

DNS translates names to records — it is the phone book of the internet, and it is behind a surprising share of outages (“it’s always DNS”).

Resolution flow: stub resolver (your OS) → recursive resolver (e.g. 1.1.1.1, 8.8.8.8, or the VPC resolver) → root servers (.) → TLD servers (.com) → authoritative servers for the zone → answer, cached at each hop according to TTL.

dig +short example.com A
dig example.com MX @1.1.1.1      # query a specific resolver
dig +trace example.com           # follow the full delegation chain from the root
dig -x 1.1.1.1                   # reverse (PTR) lookup
host example.com                 # quick lookup
resolvectl status                # what resolvers is this host actually using?

TTL is a trade-off: low TTL (60s) means fast propagation and quick failover but more query load and latency; high TTL (hours) means efficient caching but slow changes. Lower TTL before a planned migration, then raise it after.

In infrastructure, DNS is also a traffic-management tool: weighted, latency-based, geolocation, and failover routing (Route 53, Cloudflare, NS1), and service discovery (Consul, Kubernetes CoreDNS resolving service.namespace.svc.cluster.local). Modern privacy variants DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt queries that were historically plaintext.

HTTP and HTTPS

• Methods: GET (read, safe, idempotent), POST (create/action, not idempotent), PUT (replace, idempotent), PATCH (partial update), DELETE (idempotent), HEAD (headers only), OPTIONS (capabilities/CORS preflight). Idempotent means repeating the request has the same effect — which is why proxies may safely retry GET/PUT but not POST.
• Status codes you must know cold:

As an operator, 502/503/504 from a proxy almost always point at the upstream, not the proxy itself: 502 = upstream returned garbage or refused, 503 = no healthy upstream / overloaded, 504 = upstream too slow.

• Headers that matter in ops: Host (virtual hosting / routing), Content-Type, Authorization, Cache-Control / ETag / Last-Modified (caching), X-Forwarded-For / X-Forwarded-Proto / Forwarded (real client behind a proxy), Strict-Transport-Security (force HTTPS), Content-Encoding (gzip/br compression), Connection / Keep-Alive.
• Protocol versions:

curl -v https://example.com/api/health           # inspect the full exchange (DNS, TLS, headers)
curl -I --http2 https://example.com              # headers only, negotiate h2
curl -w '%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n' \
     -o /dev/null -s https://example.com          # latency breakdown per phase
curl --resolve example.com:443:10.0.1.5 https://example.com/  # bypass DNS to test one backend

Key Concepts

TLS/SSL

TLS provides encryption (confidentiality), integrity (tamper detection), and authentication (proving the server, and optionally the client, is who it claims). “SSL” survives only as a colloquial name — SSLv2/v3 and TLS 1.0/1.1 are deprecated and insecure; use TLS 1.2 as a floor and prefer TLS 1.3.

TLS 1.3 handshake (1-RTT): client sends ClientHello with its key share and supported ciphers → server replies with ServerHello, its certificate, and key share → both derive the same session keys via (EC)DHE → encrypted application data flows. TLS 1.3 dropped a full round trip versus 1.2 and removed weak ciphers; 0-RTT resumption can send data on the first packet (at the cost of replay risk for non-idempotent requests).

The certificate chain (leaf → intermediate → trusted root CA) proves identity. The client validates: the hostname against the certificate’s SAN entries (the CN field is obsolete for this), the validity dates, the signature up to a trusted root, and revocation (OCSP/OCSP stapling or CRLs). mTLS (mutual TLS) additionally makes the client present a certificate — the basis of zero-trust service meshes.

Let’s Encrypt issues free 90-day certificates via the ACME protocol; tools like certbot or Caddy renew them automatically. Challenge types: HTTP-01 (serve a token on port 80 — simple, no wildcards), DNS-01 (create a TXT record — required for wildcard certs, works behind firewalls), TLS-ALPN-01 (on port 443).

# Inspect a live certificate chain, subject, issuer, and validity
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Check the negotiated protocol/cipher
openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'

# Issue/renew with certbot (nginx plugin)
sudo certbot --nginx -d example.com -d www.example.com

Common TLS failures: expired certificate, hostname mismatch (cert doesn’t cover the SAN you requested), incomplete chain (missing intermediate — works in browsers that cache it, fails in curl/Java), and clock skew making a valid cert look not-yet-valid.

SSH

SSH gives encrypted remote shells, file transfer, and tunnels. Prefer key-based auth (Ed25519 > RSA-2048+) and disable password login entirely.

ssh-keygen -t ed25519 -C "nam@laptop"    # generate a key pair
ssh-copy-id user@server                  # install your public key on the server
ssh -v user@server                       # verbose: debug auth/handshake problems

Host key verification (the “authenticity of host can’t be established” prompt) is a real security control — it defeats man-in-the-middle attacks by pinning the server’s key in ~/.ssh/known_hosts. Manage it at scale with signed host certificates or a known-hosts distribution.

# ~/.ssh/config — declarative connection profiles
Host bastion
    HostName bastion.example.com
    User ops
    IdentityFile ~/.ssh/id_ed25519

Host app-*
    ProxyJump bastion          # transparently hop through the bastion
    User deploy
    IdentitiesOnly yes

Tunneling (one of SSH’s superpowers):

ssh -L 5432:db.internal:5432 bastion   # local forward: localhost:5432 -> db.internal:5432
ssh -R 8080:localhost:3000 vps         # remote forward: expose a local app on the VPS
ssh -D 1080 bastion                    # dynamic SOCKS proxy (browse via the remote)
ssh -J bastion app-01                  # jump host in one command

Use an ssh-agent (with AddKeysToAgent) so a passphrase-protected key isn’t retyped every connection, and agent forwarding cautiously (it lets the remote host use your keys). For production, prefer session managers (AWS SSM Session Manager, GCP IAP) that eliminate open port 22 and public bastions entirely.

File transfer and email protocols

• FTP (control port 21, data on 20 or passive high ports) is legacy and plaintext — avoid. FTPS adds TLS to FTP but keeps the awkward dual-port model. SFTP (over SSH, port 22) is a completely different protocol and the modern default; also scp (legacy, being replaced by SFTP-backed transfers) and rsync -e ssh for efficient delta sync.
• Email trio: SMTP sends mail (port 25 server-to-server, 587 authenticated submission with STARTTLS, 465 implicit TLS). IMAP (993, TLS) reads mail while leaving it on the server and syncing state across devices. POP3 (995, TLS) downloads and typically deletes — largely obsolete.
• DevOps relevance of email: SPF (TXT record listing who may send for your domain), DKIM (cryptographic signature), and DMARC (policy + reporting tying SPF/DKIM to the visible From) are what keep your transactional mail out of spam. Note that clouds block outbound port 25 by default to fight spam — use a provider (SES, SendGrid, Postmark) over 587/API instead of running your own MTA.

Firewalls, NAT, and security groups

• Stateful firewalls track connection state: allow inbound 443 and the reply packets flow back automatically without a separate rule. Cloud security groups are stateful, instance/ENI-level allow lists (no deny rules — anything not allowed is denied). Network ACLs are stateless (you must allow both directions, including ephemeral return ports) and operate at the subnet level as a coarse second layer.
• Host firewalls: iptables (legacy), nftables (its successor), ufw (simple front-end), firewalld (zone-based). In Kubernetes, NetworkPolicies play the same role between pods.
• Default posture: deny all inbound, explicitly allow only required ports from specific sources (prefer referencing another security group over broad CIDRs), and allow outbound as needed (tighten egress in high-security environments to prevent data exfiltration).
• Reference-based rules beat CIDR rules in the cloud: “allow the load-balancer security group to reach app instances on 8080” survives IP changes and auto-scaling.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 10.0.0.0/16 to any port 22 proto tcp   # SSH only from the VPC
sudo ufw allow 443/tcp                                       # HTTPS from anywhere
sudo ufw enable
sudo ufw status numbered                                    # audit the ruleset

Load balancing basics

A load balancer distributes traffic across backends and health-checks them so dead nodes are removed automatically. L4 balancers route by IP/port (fast, protocol-agnostic, TLS passthrough); L7 balancers understand HTTP and can route by path/host/header, terminate TLS, retry, and rewrite. Common algorithms: round robin, weighted round robin, least connections, and IP hash / consistent hashing for session affinity. Deeper coverage — algorithms, L4 vs L7, sample configs — is in topic 06 (Web Servers, Proxies & Load Balancers).

A layered debugging model

The single most valuable networking skill is isolating which layer is broken, bottom-up:

1. L1/L2/L3 — reachability: ping host (ICMP). Fails? Check routes (ip route), the subnet, and security groups.
2. DNS — naming: dig +short name. Wrong/empty answer? It’s a DNS or record problem, not the app.
3. L4 — the port: nc -zv host 443 or ss -tlnp on the server. Refused = nothing listening; timeout = firewall dropping.
4. TLS — the handshake: openssl s_client -connect host:443. Cert or protocol error surfaces here.
5. L7 — the application: curl -v https://host/path. Now you’re reading status codes and headers.

Each step rules out everything below it, turning “the site is down” into a precise, five-minute diagnosis.

Best Practices

1. Debug bottom-up through the layers — check L3 reachability (ping), then DNS (dig), then the port (nc -zv host 443), then TLS (openssl s_client), then the app (curl -v). This isolates the failing layer in minutes instead of guessing.
2. Plan CIDR ranges before building — overlapping VPC/VPN/office ranges are painful and sometimes impossible to fix later (you cannot route between two 10.0.0.0/16s). Reserve non-overlapping blocks per environment and region up front, and leave room to grow.
3. Set DNS TTLs deliberately — low TTL (60s) before migrations and on failover records; higher TTL (1h+) for stable records to reduce resolver load and latency. Lower TTL before the change, not during.
4. Use TLS everywhere, TLS 1.2 minimum, prefer 1.3 — including internal service-to-service traffic (or mTLS via a service mesh). Generate config with Mozilla’s SSL Config Generator and grade it with SSL Labs.
5. Automate certificate issuance and renewal — ACME/Let’s Encrypt with certbot or Caddy, or cloud-managed certs (ACM, GCP-managed). Alert on certificates expiring within 14–30 days; an expired cert remains one of the most common self-inflicted outages.
6. Disable SSH password authentication and root login — keys only (Ed25519), and prefer a session manager (SSM/IAP) or a bastion over exposing port 22 to the internet. Rotate and inventory keys.
7. Adopt a default-deny firewall posture — open only required ports, restrict sources by security-group reference or tight CIDR, tighten egress where it matters, and review rules regularly for drift.
8. Prefer SFTP / rsync-over-SSH, never plain FTP — plaintext credentials on the wire are indefensible; if you must interoperate with FTP, use FTPS at minimum.
9. Know your HTTP status codes and set correct cache headers — 502/503/504 triage points at upstreams; Cache-Control, ETag, and Last-Modified cut origin load dramatically and enable 304s.
10. Send HSTS and redirect HTTP→HTTPS — Strict-Transport-Security: max-age=31536000; includeSubDomains prevents protocol-downgrade attacks after the first visit; consider HSTS preloading for sensitive domains.
11. Monitor DNS and TLS as first-class signals — resolution failures, NXDOMAIN spikes, handshake errors, and cert-expiry countdowns often precede “the app is down” reports by hours.
12. Right-size MTU on overlays and VPNs — mismatched MTU causes payload-size-dependent hangs; enable PMTUD or lower the interface MTU (e.g. 1400) on tunnels.
13. Prefer private subnets with NAT for egress — app and data tiers should have no public IP; give them outbound access via a NAT gateway and inbound only through the load balancer.
14. Learn the capture tools — tcpdump -i any port 443 -w cap.pcap plus Wireshark, and mtr/ss, answer questions that logs and metrics cannot.

References

• roadmap.sh DevOps roadmap: https://roadmap.sh/devops
• MDN — HTTP documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP
• MDN — HTTP status codes reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
• Cloudflare Learning Center (DNS, TLS, QUIC, load balancing): https://www.cloudflare.com/learning/
• Let’s Encrypt — How it works: https://letsencrypt.org/how-it-works/
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org/
• Qualys SSL Labs — server test: https://www.ssllabs.com/ssltest/
• OpenSSH manual pages: https://www.openssh.com/manual.html
• RFC 9110 — HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110
• RFC 9112 — HTTP/1.1: https://www.rfc-editor.org/rfc/rfc9112
• RFC 9113 — HTTP/2: https://www.rfc-editor.org/rfc/rfc9113
• RFC 9114 — HTTP/3: https://www.rfc-editor.org/rfc/rfc9114
• RFC 9000 — QUIC transport: https://www.rfc-editor.org/rfc/rfc9000
• RFC 8446 — TLS 1.3: https://www.rfc-editor.org/rfc/rfc8446
• RFC 1918 — Private address allocation: https://www.rfc-editor.org/rfc/rfc1918
• RFC 1035 — Domain names (DNS): https://www.rfc-editor.org/rfc/rfc1035
• Julia Evans — networking zines: https://wizardzines.com/
• Book: “Computer Networking: A Top-Down Approach” — Kurose & Ross
• Book: “TCP/IP Illustrated, Vol. 1” — W. Richard Stevens