Các giao thức cốt lõiCore Protocols

Part of the Network Engineer Roadmap knowledge base.

Overview

A protocol is an agreed-upon set of rules that lets two or more parties exchange information reliably. It defines the syntax (how messages are formatted — the bits, fields, and delimiters), the semantics (what each message means and what actions it triggers), and the timing (the order of messages and how parties react to loss, delay, or errors). Without protocols, two machines from different vendors could not agree on so much as where a message ends.

Most of the protocols a network engineer works with day to day are application-layer protocols: DNS, DHCP, HTTP, TLS, SSH, SMTP, NTP, SNMP, and so on. These do not talk to the wire directly. Instead they ride on top of a transport protocol — almost always TCP or UDP (see ./03-network-models-and-layers.md for the full layering model). The transport layer, in turn, rides on IP (see ./05-ip-addressing-and-subnetting.md).

The choice of transport shapes the application protocol’s behaviour:

The rule of thumb: use TCP when every byte must arrive in order (web pages, file transfers, shell sessions); use UDP when speed and low overhead beat perfect delivery, or when the application implements its own reliability (DNS, real-time media, QUIC).

The rest of this note walks through each core protocol: what problem it solves, how it works on the wire, the ports it uses, and the CLI commands you use to inspect and troubleshoot it.

Fundamentals

Layered application protocols over TCP/UDP

Think of a request to load https://example.com as a stack of protocols working together:

1. DHCP already gave your host an IP address, gateway, and DNS server when it joined the network.
2. DNS turns example.com into an IP address (over UDP/53, or TCP for large answers).
3. TCP opens a reliable connection to that IP on port 443 (or QUIC over UDP/443 for HTTP/3).
4. TLS negotiates encryption on top of TCP so the exchange is private and authenticated.
5. HTTP carries the actual request (GET /) and response inside the TLS tunnel.

Every layer is independent: HTTP does not care whether TLS is present, and TLS does not care what application data it carries. This separation is what lets the same TLS library secure HTTP, SMTP, and IMAP alike.

Ports and sockets

A transport-layer port (0–65535) identifies which application on a host a packet belongs to. A socket is the combination (IP address, port, protocol). Well-known ports (0–1023) are reserved for standard services (53 DNS, 80 HTTP, 443 HTTPS, 22 SSH). Registered and ephemeral ports (1024–65535) are used by clients and custom services. When you type curl https://example.com, your OS picks a random ephemeral source port and connects to destination port 443.

Key Concepts

DHCP — Dynamic Host Configuration Protocol

DHCP automatically hands out IP configuration to hosts so nobody has to configure addresses by hand. It runs over UDP, with the client on port 68 and the server on port 67. A new client and a server that have never spoken before complete the DORA exchange:

Key ideas:

• Lease — an address is granted for a finite lease time. The client tries to renew at 50% of the lease (T1, unicast to the server) and rebind at 87.5% (T2, broadcast to any server) if the original server is gone.
• Options — the ACK carries more than an address: subnet mask (option 1), default gateway/router (option 3), DNS servers (option 6), domain name (option 15), NTP servers (option 42), lease time (option 51), and many more.
• DHCP relay (relay agent / ip helper-address) — DHCP relies on broadcasts, which routers do not forward. When the server sits on a different subnet, a relay agent on the client’s router captures the broadcast and unicasts it to the server, inserting the client’s subnet (giaddr) so the server knows which pool to use.
• DHCPv6 exists for IPv6, though IPv6 also supports stateless address autoconfiguration (SLAAC).

Inspect a lease on Linux with ip addr and check /var/lib/dhcp/dhclient.leases; on macOS ipconfig getpacket en0 dumps the full DHCP reply including all options.

DNS — Domain Name System

DNS is the distributed database that maps human-friendly names (example.com) to machine data (IP addresses and more). It runs primarily over UDP/53 for small queries and falls back to TCP/53 for large responses (over 512 bytes without EDNS) and zone transfers.

Resolution flow (recursive lookup for www.example.com):

1. Stub resolver — the client OS asks its configured recursive resolver (the DNS server it got from DHCP, e.g. 8.8.8.8).
2. Recursive resolver — if not cached, it starts at the top. It asks a root server (“where is .com?”).
3. Root — replies with the TLD name servers for .com.
4. TLD server — replies with the authoritative name servers for example.com.
5. Authoritative server — returns the actual A/AAAA record for www.example.com.
6. The resolver caches the answer (honouring its TTL) and returns it to the stub.

The stub does one query and gets a final answer; the recursive resolver does the legwork of walking the hierarchy.

Common record types:

TTL (Time To Live) — every record carries a TTL in seconds telling resolvers how long to cache it. Low TTLs (e.g. 300s) make changes propagate fast but increase query load; high TTLs (e.g. 86400s) cut load but slow down failovers.

Encrypted DNS — classic DNS is plaintext, so on-path observers can see and tamper with lookups. Two upgrades fix this:

• DoT (DNS over TLS) — DNS wrapped in TLS on TCP/853.
• DoH (DNS over HTTPS) — DNS sent as HTTPS requests on TCP/443, indistinguishable from normal web traffic.

dig examples:

# Basic A record lookup
dig example.com A +short
# 93.184.216.34

# Full answer with query time, flags, and TTL
dig example.com

# Query a specific resolver
dig @1.1.1.1 example.com

# Mail records
dig example.com MX +short

# Trace the full delegation from the root down (shows each hop)
dig +trace example.com

# Reverse lookup (PTR)
dig -x 93.184.216.34

# See the TTL and SOA
dig example.com SOA

# nslookup equivalent for a quick check
nslookup example.com 8.8.8.8

HTTP & HTTPS — HyperText Transfer Protocol

HTTP is the request/response protocol of the web. A client sends a request (method, path, headers, optional body) and the server returns a response (status line, headers, body). Plain HTTP uses TCP/80; HTTPS is HTTP inside a TLS tunnel on TCP/443.

Methods:

Status code classes:

Important headers: Host (which site on a shared IP), Content-Type, Content-Length, Authorization, Cookie/Set-Cookie, Cache-Control, User-Agent, Accept, Location (for redirects).

Protocol versions:

HTTP/2 in depth

HTTP/2 (RFC 9113, originally RFC 7540, derived from Google’s SPDY) keeps HTTP’s semantics — the same methods, status codes, and headers — but completely changes how bytes go on the wire:

• Binary framing layer. Instead of the plaintext, line-delimited messages of HTTP/1.1, HTTP/2 splits every message into binary frames (HEADERS, DATA, SETTINGS, etc.). Frames are easier to parse unambiguously and are the unit that multiplexing operates on.
• Multiplexing over one connection. Many streams (each an independent request/response) are interleaved over a single TCP connection, each identified by a stream ID. This kills the HTTP/1.1 need to open 6+ parallel connections per origin and eliminates application-level head-of-line blocking (a slow response no longer blocks others in the HTTP layer).
• Header compression (HPACK, RFC 7541). Request/response headers are highly repetitive (same User-Agent, Cookie, etc. on every request). HPACK compresses them with a shared dynamic table plus Huffman coding, cutting overhead dramatically. HPACK was designed to resist the CRIME attack that broke naive TLS-layer compression.
• Stream prioritization & flow control. Clients can express a dependency/weight tree so the server sends critical resources (CSS, above-the-fold) first; per-stream and per-connection flow control prevent a fast sender from overwhelming a slow receiver.
• Server push (deprecated in practice). The server could pre-emptively send resources the client hadn’t requested yet. It rarely helped and was often wasteful, so most browsers and servers have disabled/removed it — prefer 103 Early Hints and preload instead.

The catch — TCP head-of-line blocking. HTTP/2 removes HoL blocking inside the HTTP layer, but all streams still ride one TCP connection. TCP guarantees in-order delivery of the byte stream, so if a single packet is lost, TCP holds back every stream’s data until that packet is retransmitted — even streams that had no missing bytes. On lossy links (mobile, congested Wi-Fi) this can make HTTP/2 no faster, or slower, than multiple HTTP/1.1 connections. This is exactly the problem QUIC/HTTP/3 was built to fix.

QUIC & HTTP/3 in depth

QUIC (RFC 9000) is a new, general-purpose transport protocol built on top of UDP, and HTTP/3 (RFC 9114) is HTTP mapped onto QUIC. QUIC was pioneered by Google and standardized by the IETF; running over UDP was a pragmatic choice — TCP and UDP are effectively the only transports that middleboxes (firewalls, NAT) reliably pass, and evolving TCP itself is nearly impossible because so much logic is baked into OS kernels and network hardware. QUIC lives in user space, so it can iterate quickly.

Why QUIC matters:

• No transport-level head-of-line blocking. QUIC implements streams inside the transport. Each stream is delivered independently, so a lost packet only stalls the stream(s) whose bytes it carried — other streams keep flowing. This finally delivers the multiplexing HTTP/2 promised, even on lossy networks.
• Encryption is built in (TLS 1.3). QUIC integrates TLS 1.3 directly rather than layering TLS over a separate transport. There is no unencrypted QUIC — the transport headers themselves are largely encrypted/authenticated, which also reduces middlebox ossification.
• Faster connection establishment. A classic HTTPS start is TCP handshake (1 RTT) then TLS handshake (1 RTT). QUIC merges transport and cryptographic setup into a single 1-RTT handshake, and supports 0-RTT resumption where a returning client can send request data in the very first packet (with the well-known 0-RTT replay-safety caveat — only for idempotent requests).
• Connection migration. A QUIC connection is identified by a Connection ID, not the 4-tuple of IPs/ports. When your phone switches from Wi-Fi to cellular (its IP changes), the connection survives instead of breaking — a big win for mobile.
• Modern loss recovery & congestion control. QUIC uses monotonically increasing packet numbers (no TCP retransmission ambiguity), explicit ACK ranges, and pluggable congestion control (e.g. CUBIC, BBR).

Trade-offs & operational notes. QUIC is more CPU-intensive than TCP (encryption per packet, user-space processing) and, because it is UDP, some restrictive networks throttle or block UDP/443 — clients then fall back to HTTP/2 over TCP. HTTP/3 is advertised via the Alt-Svc header (or HTTPS/SVCB DNS records), so the first visit typically happens over HTTP/2 and subsequent connections upgrade to HTTP/3.

Request lifecycle for curl -v https://example.com:

1. DNS resolves example.com.
2. TCP handshake to port 443 (or QUIC for HTTP/3).
3. TLS handshake negotiates encryption and validates the certificate.
4. HTTP request is sent inside the TLS tunnel.
5. Server responds with status, headers, and body.
6. Connection is kept alive for reuse or closed.

# Verbose request: shows DNS, TCP, TLS handshake, request and response headers
curl -v https://example.com

# Response headers only
curl -I https://example.com

# Force a specific HTTP version
curl --http2 -I https://example.com
curl --http3 -I https://cloudflare.com

# Follow redirects and time the phases
curl -L -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n" https://example.com

SSL/TLS — Transport Layer Security

TLS (the modern successor to SSL, which is fully deprecated) secures a transport connection. It provides three guarantees:

• Confidentiality — traffic is encrypted; on-path observers cannot read it.
• Integrity — tampering is detected via authenticated encryption (AEAD).
• Authentication — the client verifies the server’s identity via its certificate (and optionally the server verifies the client, mutual TLS).

The TLS handshake (TLS 1.2, simplified):

1. ClientHello — client sends supported TLS versions, cipher suites, and a random.
2. ServerHello — server picks a version and cipher, sends its random and its certificate.
3. Client validates the certificate chain, then both sides perform a key exchange (ECDHE) to derive a shared session key.
4. Finished messages confirm both sides derived the same keys; encrypted application data flows.

This costs two round trips before data can flow.

TLS 1.3 streamlines this to one round trip (1-RTT), and supports 0-RTT resumption for repeat visits. It removes all the old, weak options: only forward-secret (ephemeral) key exchange and AEAD ciphers remain, RSA key transport and static Diffie-Hellman are gone, and the whole cipher-suite list is much smaller and safer.

Certificates and the chain of trust: a server presents an X.509 certificate binding its domain name to a public key, signed by a Certificate Authority (CA). Your device trusts a set of root CAs shipped by the OS/browser. The server’s leaf certificate is usually signed by an intermediate CA, which is signed by a root. The client walks this chain from leaf → intermediate → trusted root; if it terminates in a trusted root and none are expired or revoked, the certificate is valid.

# Inspect a server's certificate and the full chain
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Show the negotiated protocol and cipher
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Read a certificate's subject, issuer, and validity dates
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# curl shows TLS details in verbose mode
curl -v https://example.com 2>&1 | grep -E "SSL|TLS|subject|issuer"

SSH — Secure Shell

SSH is the standard for secure remote administration, replacing the plaintext telnet, rlogin, and rsh. It runs over TCP/22 and gives you an encrypted, authenticated channel for shell access, file transfer, and tunnelling.

Authentication:

• Password — simple but phishable and brute-forceable.
• Public-key — the preferred method. You generate a key pair; the public key goes into the server’s ~/.ssh/authorized_keys, the private key stays on your client. The server challenges you to prove you hold the private key without ever transmitting it.

Host keys — on first connect the server presents its host key; you verify and cache its fingerprint in ~/.ssh/known_hosts so future connections detect man-in-the-middle attempts (that’s the “REMOTE HOST IDENTIFICATION HAS CHANGED” warning).

Tunnelling / port forwarding — SSH can wrap other traffic inside its encrypted channel:

• Local forward (-L) — expose a remote service on your local machine.
• Remote forward (-R) — expose a local service on the remote machine.
• Dynamic forward (-D) — turn SSH into a SOCKS proxy.

# Generate a modern key pair
ssh-keygen -t ed25519 -C "you@example.com"

# Copy your public key to a server
ssh-copy-id user@server.example.com

# Connect (verbose to debug auth issues)
ssh -v user@server.example.com

# Local forward: reach the remote DB (127.0.0.1:5432 on server) via localhost:5432
ssh -L 5432:localhost:5432 user@server.example.com

# Dynamic SOCKS proxy on port 1080
ssh -D 1080 user@server.example.com

# Run a single command remotely
ssh user@server.example.com "uptime"

FTP vs SFTP vs FTPS — file transfer

Plain FTP is discouraged because it sends credentials and data in cleartext, and its dual-channel (control + data) design is a nightmare through firewalls and NAT (active vs passive mode). Prefer SFTP — it is not “FTP over SSL” at all but a distinct protocol running as a subsystem of SSH, so it reuses SSH’s authentication, encryption, and single-port simplicity. Use FTPS only when you must interoperate with legacy FTP servers that support TLS.

# SFTP interactive session (uses SSH auth on port 22)
sftp user@server.example.com

# Non-interactive: fetch a file
sftp user@server.example.com:/remote/path/file.tar.gz .

# scp is the simple copy cousin, also over SSH
scp localfile.txt user@server.example.com:/remote/dir/

SMTP / IMAP / POP3 — email

Email uses different protocols for sending and retrieving:

Mail flow: your mail client submits a message to your provider’s SMTP server on port 587 (authenticated submission). That server looks up the recipient domain’s MX record in DNS and relays the message over SMTP/25 to the recipient’s mail server. The recipient later fetches it with IMAP (modern, keeps mail server-side and synced) or POP3 (older, download-then-delete).

Anti-spoofing (see ./11-network-security.md): because SMTP has no built-in sender authentication, three DNS-based mechanisms fight forgery:

• SPF — a TXT record listing which servers may send mail for the domain.
• DKIM — the sending server signs messages with a private key; the public key is published in DNS.
• DMARC — a policy (TXT record) telling receivers what to do when SPF/DKIM fail, plus reporting.

# Find where mail for a domain is delivered
dig gmail.com MX +short

# Check a domain's SPF and DMARC policies
dig example.com TXT +short
dig _dmarc.example.com TXT +short

NTP and SNTP — time synchronization

NTP (Network Time Protocol) keeps clocks across a network accurate to milliseconds. It runs over UDP/123. Time sources are organized into strata:

• Stratum 0 — reference clocks (GPS, atomic clocks). Not on the network directly.
• Stratum 1 — servers directly attached to a stratum-0 source.
• Stratum 2, 3, … — servers that sync from the stratum above them. Higher number = further from the source.

NTP uses timestamped exchanges to estimate both the offset and the round-trip delay, then gradually disciplines the local clock (slewing) rather than jumping it, to avoid time going backwards.

SNTP (Simple NTP) is a lightweight subset of the same protocol and wire format, used by devices that just need a simple one-shot sync without the full statistical filtering and disciplining that NTP daemons do.

Why accurate time matters:

• TLS certificates have validity windows; a wrong clock makes valid certs look expired or not-yet-valid, breaking HTTPS.
• Logs and monitoring across many hosts are useless if timestamps do not line up when correlating an incident.
• Kerberos and many auth systems reject requests whose timestamps drift too far (replay protection).
• TOTP / 2FA codes are time-based.

# Check sync status (chrony)
chronyc tracking
chronyc sources -v

# Check sync status (systemd-timesyncd)
timedatectl status

# Query an NTP server directly
ntpdate -q pool.ntp.org

SNMP — Simple Network Management Protocol

SNMP is how you monitor and (optionally) configure network devices — routers, switches, firewalls, printers, UPS units. It runs over UDP/161 (queries to agents) and UDP/162 (traps sent to the manager). Core pieces:

• Manager — the monitoring system (NMS) that polls devices and receives traps.
• Agent — software on the managed device that exposes data and sends traps (asynchronous alerts).
• MIB (Management Information Base) — the schema describing available data.
• OID (Object Identifier) — a dotted numeric path (e.g. 1.3.6.1.2.1.1.3.0 = system uptime) addressing one value in the MIB tree.

Versions matter for security:

Prefer SNMPv3 wherever possible. This is a brief overview; monitoring workflows, polling vs streaming telemetry, and dashboards are covered in ./14-monitoring-and-observability.md.

# Walk a device's system MIB with SNMPv2c (community "public")
snmpwalk -v2c -c public 192.0.2.1 system

# Get a single OID (sysUpTime)
snmpget -v2c -c public 192.0.2.1 1.3.6.1.2.1.1.3.0

# SNMPv3 with auth + privacy
snmpwalk -v3 -l authPriv -u monitor -a SHA -A "authpass" -x AES -X "privpass" 192.0.2.1 system

APIs for networking

Modern network gear is increasingly managed programmatically instead of by hand-typed CLI. This is the foundation of network automation (see ./17-network-automation.md). The main interfaces:

Why APIs matter: typing commands into a CLI does not scale to hundreds of devices and is error-prone. APIs give you structured data (JSON/XML instead of screen-scraped text), transactional changes (NETCONF’s commit/rollback), and machine-readable models (YANG) so tools like Ansible, Terraform, and Python scripts can configure fleets consistently and safely. gNMI additionally enables streaming telemetry — devices push metrics continuously instead of being polled, which is far more scalable than SNMP for large fleets. See ./17-network-automation.md for tooling and workflows.

# RESTCONF: read interface config as JSON
curl -k -u admin:admin \
  -H "Accept: application/yang-data+json" \
  https://192.0.2.1/restconf/data/ietf-interfaces:interfaces

# NETCONF happens over SSH on port 830
ssh admin@192.0.2.1 -p 830 -s netconf

Summary: protocol → transport → default port

Best Practices

• Encrypt everything. Prefer the secure variant of every protocol: HTTPS over HTTP, SFTP/FTPS over FTP, SNMPv3 over v2c, DoT/DoH over plaintext DNS, and TLS-enabled SMTP/IMAP. Plaintext protocols leak credentials and data to anyone on the path.
• Disable weak versions. Turn off SSLv3, TLS 1.0/1.1, SSH v1, and SNMPv1/v2c wherever you can. Standardize on TLS 1.2+ (ideally 1.3) and SNMPv3.
• Use key-based auth, not passwords, for SSH and SFTP. Disable password and root login on servers, and protect private keys with passphrases.
• Set sensible DNS TTLs. Lower TTLs before a planned migration so changes propagate quickly; raise them afterward to reduce query load. Always keep at least two NS records on separate infrastructure.
• Keep clocks synced. Run NTP/chrony on every host and network device. Clock drift silently breaks TLS validation, log correlation, and Kerberos/2FA.
• Understand your transport. Know whether a protocol is TCP or UDP before troubleshooting — a UDP service (DNS, DHCP, NTP, SNMP) fails differently from a TCP one, and firewall rules must match.
• Harden DHCP. Use DHCP snooping on switches to block rogue DHCP servers, and relay agents (ip helper-address) for cross-subnet delivery.
• Protect email with SPF, DKIM, and DMARC. All three are DNS records; missing any of them lets attackers spoof your domain.
• Prefer APIs over screen-scraping. For automation, use NETCONF/RESTCONF/gNMI structured interfaces rather than parsing CLI output — they are transactional and machine-readable.
• Validate certificates properly. Never disable certificate verification (curl -k, verify=False) in production; fix the trust chain instead. Monitor certificate expiry.

References

• RFC 2131 — Dynamic Host Configuration Protocol (DHCP)
• RFC 1034 / 1035 — Domain Names (DNS concepts and specification)
• RFC 9110 — HTTP Semantics
• RFC 9113 — HTTP/2
• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9114 — HTTP/3
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 4251 — The Secure Shell (SSH) Protocol Architecture
• MDN Web Docs — HTTP
• Cloudflare Learning — What is DNS?
• Cloudflare Learning — What is SSL/TLS?