Mạng cơ bản

Mạng là gì trong một bài thiết kế

Mọi sơ đồ thiết kế đều có những mũi tên giữa client, load balancer, API server và database. Mỗi mũi tên là một kết nối mạng, và mỗi kết nối có ba thuộc tính quyết định thiết kế: độ trễ (mất bao lâu), độ tin cậy (có mất gói không, có đúng thứ tự không) và hướng (ai được chủ động gửi dữ liệu).

Bạn không cần thuộc mô hình OSI bảy tầng. Bốn tầng sau là đủ cho phỏng vấn (cách gom tầng này là của khoá học; Grokking ch.8 dùng các tầng L3, L4, L7 để phân loại load balancer):¹

IP gán cho mỗi máy một địa chỉ (IPv4 như 203.113.1.10, IPv6 dài hơn) và chuyển từng gói tin độc lập qua các router. IP không hứa gì cả: gói có thể mất, tới trễ, tới sai thứ tự. Các tầng trên xử lý những chuyện đó. Trong data center, các service thường dùng IP nội bộ (dải 10.x.x.x), chỉ load balancer hoặc gateway có IP public.²

Vì sao quan trọng trong phỏng vấn

Người phỏng vấn ít khi hỏi "TCP handshake có mấy bước". Họ hỏi những câu mà câu trả lời phụ thuộc vào mạng:

• Làm sao để người nhận thấy tin nhắn chat ngay lập tức?
• Vì sao người dùng ở Hà Nội tải video chậm khi server đặt ở Mỹ?
• Load balancer đặt ở đâu, nó có biết user nào đang gọi không?
• Một trang gọi 30 API nhỏ thì chậm vì đâu?

Hiểu mạng giúp bạn chọn đúng cơ chế realtime, đặt server và CDN đúng chỗ, và tính độ trễ end-to-end bằng con số thay vì cảm giác. Ứng viên tốt thường nói được câu như "server ở Singapore, mỗi round trip từ Việt Nam khoảng 40 ms, nên tôi gộp ba lần gọi thành một" (40 ms là ước lượng ví dụ, cần đo thật). Grokking nêu ứng dụng thời gian thực thường cần độ trễ dưới 200 ms, VoIP không quá 150 ms.³

TCP, UDP và QUIC

TCP

TCP tạo một kết nối giữa hai bên, đánh số từng byte, gửi lại phần bị mất và giao dữ liệu đúng thứ tự. Trước khi gửi dữ liệu phải bắt tay ba bước (SYN, SYN-ACK, ACK), tốn một round trip; Grokking cũng nhắc TCP cần three-way handshake trước khi trao đổi dữ liệu.⁴ Node.js in Practice mô tả TCP là luồng byte tin cậy, hai chiều, còn UDP dựa trên datagram.⁵ TCP còn có congestion control: kết nối mới bắt đầu gửi chậm rồi tăng dần, nên kết nối mới "lạnh" hơn kết nối đã dùng lâu.

Hệ quả thực tế: mở kết nối mới rất đắt khi ở xa. Đó là lý do có connection pool tới database, keep-alive trong HTTP, và lý do nên dùng lại kết nối giữa service với service.⁶ Phần congestion control ở trên là kiến thức mạng chung.²

UDP

UDP chỉ gửi gói tin đi, không bắt tay, không gửi lại, không sắp xếp. Đổi lại nó nhanh và không bị "kẹt" khi một gói mất. Phù hợp cho thứ mà dữ liệu cũ vô giá trị: gọi thoại, video call, game realtime, DNS query, gửi metrics. Grokking giải thích DNS dùng UDP vì chỉ cần một round trip, nhanh hơn TCP, và resolver tự gửi lại khi không có phản hồi.⁴ Node.js in Practice cũng nói UDP hợp khi việc giao hàng không bắt buộc nhưng cần hiệu năng.⁵

QUIC

QUIC (chưa có nguồn trong thư viện)⁷ chạy trên UDP nhưng tự làm lại các phần tin cậy của TCP, gộp luôn TLS vào handshake, và cho phép nhiều stream độc lập trong một kết nối. Một gói mất chỉ làm chậm stream chứa nó. QUIC là nền của HTTP/3.

HTTP, TLS và DNS

HTTP/1.1, HTTP/2, HTTP/3

HTTP là giao thức request/response mà gần như mọi API web dùng. Ba phiên bản khác nhau chủ yếu ở cách tận dụng kết nối (bảng so sánh là kiến thức chung, chưa có sách trong thư viện;⁸ Microservices Patterns chỉ nhắc HTTP/2 như giao thức nền cho gRPC):⁹

Trong phỏng vấn, thường chỉ cần nói: client tới edge dùng HTTP/2 hoặc HTTP/3, giữa các service nội bộ dùng HTTP/2 (gRPC chạy trên HTTP/2).

TLS

TLS mã hóa dữ liệu và xác thực server bằng certificate. Bắt tay TLS tốn thêm ít nhất một round trip sau TCP handshake. Với người dùng ở xa, đó là thêm vài chục tới vài trăm ms cho request đầu tiên (ước lượng, cần đo). Số round trip chính xác của từng phiên bản TLS chưa có sách trong thư viện.⁸

TLS termination là chỗ giải mã. Grokking ghi load balancer giảm tải cho server bằng cách xử lý TLS termination với client.¹⁰ Thường đặt ở load balancer hoặc CDN edge: nó giữ certificate, giải mã, rồi chuyển request vào mạng nội bộ (có thể mã hóa lại nếu yêu cầu bảo mật cao, gọi là mTLS giữa các service).

DNS

DNS đổi tên miền thành IP. Theo Grokking ch.7, DNS là một hệ phân cấp: resolver (của ISP hoặc public như 1.1.1.1, 8.8.8.8) hỏi root server, root chỉ tới TLD server (.vn, .com), TLD chỉ tới authoritative server của tên miền, server này trả IP. Tên được xử lý từ phải sang trái.¹¹

Mỗi tầng đều cache theo TTL, nên phần lớn truy vấn được trả từ cache.¹² (Sơ đồ trên đơn giản hóa: Grokking phân biệt truy vấn iterative và recursive.) Hai điều đáng nhớ cho thiết kế:

• TTL quyết định tốc độ chuyển hướng. TTL 300 giây nghĩa là khi đổi IP, một số người dùng còn vào IP cũ tới 5 phút, có resolver còn giữ lâu hơn. Muốn failover nhanh, đừng chỉ dựa vào DNS. Grokking nói TTL nhỏ giúp cập nhật bản ghi nhanh hơn khi server hỏng, và việc phục hồi qua DNS có thể chậm vì cơ chế cache, nhất là khi TTL dài.¹²¹³ Con số 300 giây ở trên là ví dụ.
• DNS là load balancer tầng 0. Grokking ch.8 gọi DNS là tier-0: trả về nhiều IP xoay vòng, hoặc trả IP theo vị trí người hỏi (GeoDNS) để đưa người dùng Việt Nam về region Singapore và người dùng Mỹ về region Mỹ; Grokking lưu ý DNS geolocation và anycast làm được nhưng không đơn giản.¹³

Load balancer L4 và L7

Load balancer chia request cho nhiều server, kiểm tra sức khỏe (heartbeat) và gỡ server hỏng ra khỏi pool.¹⁰ Grokking ch.8 mô tả data center lớn có nhiều tầng: DNS, router ECMP chia tải giữa các LB, tầng L4, rồi tầng L7 nói chuyện trực tiếp với server.¹

Hai dòng đầu của bảng (nhìn thấy gì, tốc độ) khớp với Grokking: L4 duy trì kết nối với client và nhanh hơn, L7 xem dữ liệu ứng dụng như user ID, thông minh hơn nhưng chậm hơn, và một số L4 cũng hỗ trợ TLS.¹⁴ Các dòng ví dụ sản phẩm, tính năng thêm và "hợp với" là kiến thức chung của khoá học.¹⁵

Thuật toán chia tải hay gặp: round robin, weighted round robin, least connections, và hash theo key (IP hoặc user id) khi cần sticky.¹⁶ Với WebSocket, chú ý: kết nối sống lâu nên round robin lúc kết nối không cân bằng được khi server mới vừa thêm vào. Dùng least connections hoặc chủ động ngắt kết nối dần để client kết nối lại.

Long polling, SSE, WebSocket, WebRTC

HTTP mặc định là client hỏi, server trả lời. Khi server cần đẩy dữ liệu (tin nhắn mới, giá mới, comment mới), có bốn lựa chọn. Bảng sau là kiến thức mạng chung (chưa có sách trong thư viện mô tả đầy đủ SSE, long polling, WebRTC); Grokking ch.36 dùng WebSocket giữa client và chat server trong bài WhatsApp:¹⁷¹⁸

Cách chọn nhanh:

• Chỉ server đẩy xuống, tần suất vừa phải: SSE. Chạy trên HTTP thường, qua được proxy, trình duyệt tự kết nối lại.
• Cả hai chiều đều gửi nhiều, cần trễ thấp: WebSocket.
• Truyền âm thanh, video giữa người dùng: WebRTC, server chỉ làm signaling.
• Không chắc hạ tầng hỗ trợ: long polling làm phương án dự phòng.

Phần khó của WebSocket và SSE nằm ở phía server: mỗi kết nối gắn với một máy, nên khi user A ở gateway 1 gửi tin cho user B ở gateway 7, cần một lớp pub/sub (Redis, Kafka) để chuyển tin giữa các gateway. Chi tiết ở bài Cập nhật realtime.

Độ trễ theo khoảng cách và CDN

Con số độ trễ (ước lượng)

Grokking cho biết round trip trong cùng data center khoảng 500 micro giây, San Francisco sang New York khoảng 71 ms, và độ trễ round trip từ US East (N. Virginia) tới Africa (Cape Town) là 225,63 ms vào thời điểm đo của sách.¹⁹³ Các dòng cho tuyến Việt Nam trong bảng dưới là ước lượng của khoá học để tính nhẩm, cần đo lại bằng ping hoặc công cụ của nhà cung cấp.²⁰ Quy tắc "khoảng 1 ms cho mỗi 100 km một chiều" (tín hiệu trong cáp quang đi khoảng 200.000 km/s) là vật lý chung, không lấy từ sách. Đường cáp thực tế vòng vèo và qua nhiều router nên con số thật cao hơn.

Request đầu tiên tốn bao nhiêu round trip

Một request HTTPS mới từ Việt Nam tới server ở Mỹ, RTT 200 ms (ví dụ tính nhẩm của khoá học; TCP handshake mất một round trip theo Grokking ch.7,⁴ số round trip của DNS và TLS là kiến thức chung):

Cùng request đó tới server ở Singapore (RTT 40 ms) tốn khoảng 150 ms. Tới CDN edge ở TP.HCM (RTT 10 ms) chỉ còn khoảng 40 ms. Đó là lý do người ta đưa phần handshake và nội dung tĩnh về gần người dùng.

CDN

CDN là mạng các proxy server đặt ở rìa mạng (edge), gần người dùng. Grokking ch.11 nêu ba vấn đề khi phục vụ từ một data center duy nhất: độ trễ cao do khoảng cách, băng thông đường trục bị dồn tải, và một điểm hỏng duy nhất.²¹ CDN giải quyết bằng cách đưa nội dung tới proxy server ở edge, giảm độ trễ và tiết kiệm băng thông, chỉ hỏi origin khi chưa có.

Grokking mô tả push CDN: nhà cung cấp nội dung chịu trách nhiệm đẩy nội dung tới proxy server, hợp với nội dung tĩnh; nội dung đổi nhanh thì push khó theo kịp và đẩy dư thừa.²² Thời hạn hết hạn theo TTL do origin đặt cho từng đối tượng.²³

Những gì CDN làm được ngoài cache file tĩnh (kiến thức chung về dịch vụ CDN thương mại, chưa có sách trong thư viện;²⁴ Grokking nêu thêm vai trò độ tin cậy và bảo mật của CDN):²¹

• Terminate TLS ở edge, giữ kết nối ấm về origin, nên cả API động cũng nhanh hơn.
• Phục vụ video theo từng đoạn nhỏ (HLS, DASH), ảnh đã resize.
• Chặn DDoS, rate limit ở edge.
• Cache cả response API công khai trong vài giây (trang sự kiện, bảng xếp hạng).

Vô hiệu hóa cache: dùng tên file có hash (app.3f9a1c.js) để không bao giờ phải xóa, hoặc gọi API purge của CDN, hoặc đặt TTL ngắn cho nội dung hay đổi.²³

Sai lầm hay gặp

• Quên round trip khi tính độ trễ. Ba lần gọi tuần tự từ mobile tới server ở Mỹ đã tốn gần 1 giây. Gộp lời gọi, dùng HTTP/2, hoặc đặt server gần người dùng (ba lần RTT 200 ms là phép tính ví dụ).
• Dùng WebSocket cho mọi thứ realtime. Thông báo một chiều dùng SSE đơn giản hơn nhiều, qua được proxy, tự kết nối lại.
• Dựa vào DNS để failover trong vài giây. TTL và cache ở resolver làm việc chuyển hướng chậm. Failover nhanh nên làm ở load balancer hoặc anycast IP.¹³
• Đặt sticky session ở L7 để giữ state trong RAM của API server. Server chết là mất state. Giữ API stateless, đưa session vào Redis. Grokking nêu LB có thể giữ session (stateful, hạn chế scalability) hoặc session nằm ở cache phân tán hoặc database.²⁵
• Mở kết nối mới tới database cho mỗi request. Dùng pool.⁶ Số kết nối Postgres chịu được và việc dùng PgBouncer là kiến thức vận hành chưa có sách trong thư viện, xem bài PostgreSQL.
• Quên rằng mobile đổi mạng liên tục. Kết nối WebSocket rớt khi chuyển wifi sang 4G. Client phải kết nối lại với backoff và lấy bù tin nhắn bị lỡ theo sequence.

Khi nào nhắc tới trong phỏng vấn

Bảng trên là gợi ý của khoá học. Các điểm có nguồn: WebSocket giữa client và chat server (Grokking ch.36),¹⁸ CDN giảm độ trễ và tải cho origin (Grokking ch.11),²¹ LB giữ vai trò TLS termination và phân phối (Grokking ch.8).¹⁰

Đọc tiếp: Thiết kế API cho phần nội dung đi trên các kết nối này, API gateway cho tầng L7 ở rìa hệ thống, và Con số cần thuộc cho bảng độ trễ đầy đủ.

Nguồn trích dẫn

1. Grokking Modern System Design · ch.8 Load Balancers · bài "Advanced Details of Load Balancers", mục "Types of load balancers" và "Load balancer deployment" (Tier-0 đến Tier-3). ↩ ↩²

2. Chưa có nguồn trong thư viện: thư viện không có sách mạng tổng quát (IP, địa chỉ nội bộ, congestion control); chỉ nêu khái niệm cơ bản. ↩ ↩²

3. Grokking Modern System Design · ch.11 Content Delivery Network (CDN) · mục "Problem statement" (High latency: dưới 200 ms cho ứng dụng thời gian thực, 150 ms cho VoIP, và các số đo trễ giữa vùng). ↩ ↩²

4. Grokking Modern System Design · ch.7 Domain Name System · bài "How the Domain Name System Works", phần nói về giao thức (UDP một round trip so với TCP cần three-way handshake). ↩ ↩² ↩³

5. Node.js in Practice (file .zip, tải về giải nén) · ch.7 Networking: TCP, UDP, and HTTP clients and servers · mục "UDP and how it compares to TCP". ↩ ↩²

6. Building Microservices (file .zip, tải về giải nén) · ch.11 Microservices at Scale · phần về HTTP connection pool và bulkhead (pool kết nối tách riêng cho từng downstream). ↩ ↩²

7. Chưa có nguồn trong thư viện: thư viện không có sách về QUIC hay HTTP/3; đoạn này chỉ nêu khái niệm cơ bản. ↩

8. Chưa có nguồn trong thư viện: thư viện không có sách mô tả HTTP/1.1, HTTP/2, HTTP/3 hay TLS 1.2/1.3 ở mức giao thức; bảng giữ lại vì cần cho phỏng vấn, viết ngắn gọn. ↩ ↩²

9. Microservices Patterns (file .zip, tải về giải nén) · ch.3 Interprocess communication · phần nhắc gRPC dùng HTTP/2. ↩

10. Grokking Modern System Design · ch.8 Load Balancers · bài "Introduction to Load Balancers", mục "What is load balancing?" và "Services offered by load balancers" (health checking, TLS termination). ↩ ↩² ↩³ ↩⁴

11. Grokking Modern System Design · ch.7 Domain Name System · bài "How the Domain Name System Works", mục "DNS hierarchy" (root, TLD, authoritative; xử lý từ phải sang trái) và "Iterative versus recursive query resolution". ↩

12. Grokking Modern System Design · ch.7 Domain Name System · bài "How the Domain Name System Works" (caching và time-to-live). ↩ ↩²

13. Grokking Modern System Design · ch.8 Load Balancers · bài "Global and Local Load Balancing", mục "Load balancing in DNS" (hạn chế của DNS: kiểm soát client hạn chế, failover chậm do cache, geolocation và anycast không đơn giản). ↩ ↩² ↩³

14. Grokking Modern System Design · ch.8 Load Balancers · bài "Advanced Details of Load Balancers", mục "Types of load balancers". ↩

15. Chưa có nguồn trong thư viện: các ví dụ sản phẩm (AWS NLB/ALB, LVS, Envoy), tính năng thêm và cột "hợp với" không có trong sách; giữ lại như kiến thức tham khảo. ↩

16. Grokking Modern System Design · ch.8 Load Balancers · bài "Advanced Details of Load Balancers", mục "Algorithms of load balancers" (round robin, weighted round robin, least connections). ↩

17. Chưa có nguồn trong thư viện: thư viện không có sách mô tả Server-Sent Events, long polling và WebRTC; bảng chỉ nêu khái niệm cơ bản. ↩

18. Grokking Modern System Design · ch.36 Design WhatsApp · phần thiết kế (client và chat server giao tiếp qua WebSocket). ↩ ↩²

19. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective", mục "Standard numbers to remember" (Important Latencies). ↩

20. Chưa có nguồn trong thư viện: các số độ trễ của tuyến Việt Nam là ước lượng của khoá học, không có trong sách; cần đo thực tế. ↩

21. Grokking Modern System Design · ch.11 Content Delivery Network (CDN) · mục "Problem statement" và "How will we design a CDN?". ↩ ↩² ↩³

22. Grokking Modern System Design · ch.11 Content Delivery Network (CDN) · bài "In-depth Investigation of CDN: Part 1", mục "Push CDN" và "Pull CDN". ↩

23. Grokking Modern System Design · ch.11 Content Delivery Network (CDN) · mục "Time-to-live (TTL)" (nhất quán nội dung giữa origin và proxy). ↩ ↩²

24. Chưa có nguồn trong thư viện: các tính năng như HLS/DASH, chặn DDoS và cache API công khai ở edge không có trong sách; chỉ nêu ngắn gọn. ↩

25. Grokking Modern System Design · ch.8 Load Balancers · bài "Advanced Details of Load Balancers", mục "Stateful versus stateless LBs". ↩