Networking nền tảng cho backend: DNS, TCP, TLS, HTTP và proxy

Vì sao developer backend cần hiểu network?#

Rất nhiều lỗi production nhìn bề ngoài giống lỗi code nhưng gốc lại nằm ở network: DNS cache sai, timeout quá ngắn, reverse proxy giới hạn body size, TLS certificate hết hạn, database connection bị firewall chặn, hoặc load balancer health check cấu hình sai. Nếu hiểu network ở mức thực dụng, bạn debug nhanh hơn và thiết kế API ổn định hơn.

Không cần trở thành network engineer để làm backend tốt, nhưng bạn cần biết request đi qua những lớp nào trước khi tới code của mình.

Hành trình của một request#

Khi người dùng mở một URL, trình duyệt thường đi qua các bước sau: phân giải DNS để tìm IP, mở kết nối TCP, thương lượng TLS nếu dùng HTTPS, gửi HTTP request, đi qua CDN hoặc reverse proxy, tới load balancer, vào app server, app gọi database/cache/service khác, rồi response quay ngược lại.

• DNS: chuyển domain thành IP.
• TCP: tạo kết nối tin cậy giữa client và server.
• TLS: mã hóa và xác thực server cho HTTPS.
• HTTP: giao thức ứng dụng chứa method, header, body và status code.
• Proxy/load balancer: định tuyến, terminate TLS, cân bằng tải và áp policy.

Khi một request chậm, hãy xác định nó chậm ở đâu: DNS lookup, TCP connect, TLS handshake, time to first byte, download response hay xử lý phía app.

DNS: đơn giản nhưng dễ bị bỏ qua#

DNS record phổ biến gồm A record trỏ domain tới IPv4, AAAA trỏ tới IPv6, CNAME trỏ alias sang domain khác, MX cho email và TXT cho xác minh hoặc chính sách. Tham số TTL cho biết resolver được cache record bao lâu. TTL quá cao làm thay đổi DNS chậm có hiệu lực; TTL quá thấp tăng số lần query.

dig example.com
dig api.example.com CNAME
nslookup example.com

Khi đổi hạ tầng, hãy giảm TTL trước thời điểm cutover. Sau khi chuyển xong và ổn định, tăng TTL lại để giảm chi phí lookup.

TCP và timeout#

TCP bảo đảm dữ liệu đến đúng thứ tự, nhưng đổi lại có chi phí kết nối và có thể bị ảnh hưởng bởi latency, packet loss hoặc congestion. Backend cần cấu hình timeout hợp lý cho HTTP client, database client và queue worker. Không có timeout là một lỗi thiết kế. Timeout quá ngắn lại gây lỗi giả khi hệ thống chịu tải.

Một nguyên tắc thực tế: mỗi dependency bên ngoài app phải có timeout, retry có giới hạn, circuit breaker nếu phù hợp và log đủ thông tin để biết dependency nào đang chậm.

TLS: HTTPS không chỉ là ổ khóa#

TLS giúp mã hóa dữ liệu trên đường truyền và xác thực server qua certificate. Trong production, TLS thường được terminate ở CDN, load balancer hoặc reverse proxy như Nginx. App phía sau có thể nhận HTTP nội bộ hoặc HTTPS nội bộ tùy mô hình bảo mật.

Các lỗi TLS hay gặp gồm certificate hết hạn, thiếu intermediate certificate, domain không khớp certificate, redirect HTTP sang HTTPS sai, hoặc backend tự generate absolute URL bằng scheme sai vì không tin header proxy.

HTTP: status code là hợp đồng vận hành#

Status code không chỉ để frontend hiển thị lỗi. Nó còn ảnh hưởng cache, retry, monitoring và SEO. Hãy dùng status code nhất quán.

• 200: request thành công.
• 201: tạo resource thành công.
• 400: request sai định dạng hoặc thiếu dữ liệu.
• 401: chưa xác thực.
• 403: đã xác thực nhưng không đủ quyền.
• 404: resource không tồn tại hoặc bị ẩn.
• 409: xung đột trạng thái, ví dụ slug đã tồn tại.
• 429: vượt rate limit.
• 500: lỗi không mong đợi phía server.
• 503: service tạm thời không sẵn sàng.

API tốt không trả 200 cho mọi trường hợp rồi nhét lỗi vào body. Cách đó làm monitoring và client retry khó chính xác.

Reverse proxy và những lỗi kinh điển#

Nginx, Caddy, Traefik hoặc load balancer thường đứng trước app. Proxy có thể nén response, cache, terminate TLS, giới hạn body size, thêm header bảo mật và chuyển tiếp request tới upstream.

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://app:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    client_max_body_size 10m;
  }
}

Nếu app cần biết IP thật của client hoặc scheme HTTPS, proxy phải chuyển đúng header và app phải được cấu hình tin proxy. Nếu không, bạn sẽ gặp lỗi redirect loop, log toàn IP proxy hoặc tạo link callback sai scheme.

Công cụ debug network nên biết#

curl -I https://example.com
curl -v https://api.example.com/health
ping example.com
traceroute example.com
dig example.com
nc -vz db.example.com 5432
openssl s_client -connect example.com:443 -servername example.com

curl -v cho bạn thấy DNS, TCP, TLS và header HTTP ở mức đủ chi tiết cho phần lớn lỗi backend. nc -vz giúp kiểm tra port có mở từ môi trường hiện tại hay không. openssl s_client hữu ích khi nghi ngờ certificate chain.

Checklist network cho API production#

• Domain có DNS record đúng và TTL phù hợp.
• HTTPS hoạt động, certificate còn hạn và redirect HTTP sang HTTPS đúng.
• Health check đi qua đúng path nhẹ, không phụ thuộc chức năng nặng.
• Proxy chuyển tiếp Host, X-Forwarded-Proto và X-Forwarded-For nếu app cần.
• Body size limit phù hợp với upload thực tế.
• Timeout giữa proxy và upstream không quá thấp cũng không vô hạn.
• API trả status code nhất quán để monitoring bắt lỗi đúng.
• Log có latency, status code, method, path và request id.

Hiểu network giúp bạn bớt đoán mò. Khi production báo lỗi, bạn có thể đi từng lớp, loại trừ từng khả năng và thu hẹp vấn đề trước khi sửa code.

Nguồn tham khảo chính#

• MDN: HTTP response status codes
• NGINX Docs: HTTP proxy module
• MDN: HTTP caching