Đã đăng vào thg 6 18, 2:43 SA 22 phút đọc

157

🔒⚙️ Request Đi Qua Server Như Thế Nào - Backend Internals P1

Chuyện gì thực sự xảy ra khi một Request chạm đến Server? (Hành trình xuyên qua các lớp của Backend Internals)

Xem full series Backend Internal tại: https://www.patreon.com/collection/2114789?view=expanded

1. Nghịch lý của sự "Im lặng" trong Production

Đó là 11 giờ đêm thứ Sáu. Bạn đang theo dõi dashboard của một hệ thống thương mại điện tử lớn ngay trước giờ Flash Sale. Đột nhiên, kênh Slack của đội On-call bắt đầu "nổ" thông báo. Customer Support báo cáo rằng người dùng không thể thanh toán, ứng dụng liên tục báo lỗi Timeout.

Bạn vội vã mở Grafana. Một cảnh tượng kỳ lạ hiện ra: CPU Usage của dàn Instance API chỉ dao động ở mức 15%, Memory còn trống mênh mông. Database Dashboard cho thấy p99 latency của các câu query vẫn duy trì ở mức 5ms – cực kỳ lý tưởng. Về lý thuyết, mọi chỉ số "bề mặt" đều đang màu xanh (healthy). Nhưng thực tế, từ phía client, latency đã vọt lên tới 10 giây hoặc đơn giản là Request bị drop hoàn toàn.

Cảm giác bối rối này là một "nghi thức trưởng thành" mà mọi Senior Engineer đều từng trải qua. Khi các công cụ giám sát thông thường im lặng, chúng ta rơi vào một khoảng không nhận thức. Bạn bắt đầu nghi ngờ code của mình, nghi ngờ framework, thậm chí nghi ngờ cả ISP. Câu hỏi nhức nhối nhất lúc này không phải là "Lỗi ở dòng code nào?" mà là: "Nếu code không chậm, database không treo, thì thời gian của request đã biến đi đâu?"

Để trả lời được câu hỏi đó, chúng ta phải thừa nhận một sự thật phũ phàng: Những gì bạn viết trong Controller chỉ là phần nổi của một tảng băng chìm khổng lồ.

2. Cái bẫy của "Business Logic-Centric"

Sai lầm lớn nhất của các kỹ sư tầm trung là tin rằng Backend chỉ xoay quanh việc thực thi Business Logic. Chúng ta dành hàng tuần để tối ưu thuật toán tìm kiếm, chọn thư viện JSON parser nhanh nhất, hay tranh cãi về việc dùng Map hay List để tiết kiệm vài micro-seconds.

Nhưng trong thế giới Production thực thực tế, code của bạn thường chỉ chiếm chưa đầy 5% tổng thời gian vòng đời của một Request. Hãy làm một phép tính đơn giản: Một API phản hồi trong 500ms. Code xử lý logic của bạn có thể chỉ mất 5ms. Vậy 495ms còn lại nằm ở đâu? Nó nằm ở việc thiết lập kết nối TCP, ở hàng đợi của hệ điều hành, ở quá trình giải mã SSL tại Web Server, ở việc chờ đợi Thread Pool trong Runtime, và ở độ trễ vật lý của hệ thống I/O.

Việc tối ưu hóa code từ O(n^2) xuống O(n) trong Controller sẽ hoàn toàn vô nghĩa nếu bottleneck thực sự nằm ở net.core.somaxconn của Kernel hay do Thread Pool bị cạn kiệt bởi một dịch vụ bên thứ ba đang bị "treo". Nếu bạn chỉ nhìn vào "Code", bạn đang mù quáng trước 95% còn lại của hệ thống.

3. Why This Exists: Sự cần thiết của các tầng trừu tượng (Abstractions)

Tại sao chúng ta không để Request đi thẳng vào code cho nhanh? Tại sao ngành phần mềm lại "tự làm khó mình" bằng cách đắp lên hàng tá lớp từ Network, OS Kernel, Web Server đến Runtime?

Câu trả lời không nằm ở sự phức tạp dư thừa, mà nằm ở bài toán Phân tách trách nhiệm (Separation of Concerns) và lịch sử tiến hóa của phần cứng.

Kernel (OS): Tồn tại để code của bạn không phải lo việc điều khiển điện áp trên card mạng hay quản lý các trang bộ nhớ vật lý. Kernel lo việc "trông nom" phần cứng.
Web Server (Nginx/Tomcat): Tồn tại vì việc xử lý giao thức HTTP – một thứ ngôn ngữ văn bản hỗn độn và phức tạp – là một công việc cực kỳ nặng nề. Nếu mỗi dòng code ứng dụng đều phải tự quản lý hàng ngàn kết nối TCP đồng thời và bắt tay SSL (SSL Handshake), chúng ta sẽ không còn thời gian để viết Business Logic.
Runtime (JVM/NodeJS): Tồn tại để tạo ra một môi trường "giả lập" hoàn hảo, nơi bộ nhớ được tự động thu dọn và các luồng thực thi (Threads) được điều phối mượt mà.

Mỗi tầng này giải quyết một bài toán đau đớn của quá khứ. Nhưng sự tiện lợi luôn có cái giá của nó: Độ trễ tích lũy và những "hố đen" thông tin mà chỉ những người hiểu sâu về Internals mới có thể soi sáng.

4. Góc nhìn "Hộp đen" của Junior Developer

Một Junior Developer nhìn nhận Request như một đường thẳng đơn giản: Request -> API Controller -> Database -> Response.

Trong góc nhìn này, mọi thứ nằm giữa User và Controller là một "hộp đen" hoàn hảo và luôn luôn hoạt động. Khi hệ thống chậm, họ thường có những phản xạ bản năng nhưng sai lầm:

Đổ lỗi cho mạng: "Chắc do cáp quang đứt" – một cách giải thích chung chung để che đậy việc không hiểu về TCP overhead.
Scale-up vô tội vạ: Tăng CPU/RAM cho Server khi thấy ứng dụng phản hồi chậm, trong khi thực tế CPU đang rảnh rỗi và vấn đề nằm ở cấu hình Connection Pool.
Tối ưu code mù quáng: Refactor lại logic xử lý mà không biết rằng Request thậm chí còn chưa chạm tới dòng code đầu tiên vì đang bị kẹt ở hàng đợi của Web Server.

Để bước lên cấp độ Senior, bạn phải đập tan chiếc hộp đen đó và nhìn thấy những bánh răng đang quay bên dưới.

5. The Production Solution: Hành trình 6 chặng của một Request

Hãy cùng mổ xẻ hành trình của một HTTP Request. Đây không phải là lý thuyết giáo khoa; đây là những gì thực sự xảy ra trong một Server Production khi một bit dữ liệu đầu tiên chạm vào Card mạng (NIC).

Chặng 1: Network - Cuộc chiến với vật lý và địa lý

Trước khi đến được Server của bạn, Request là những xung điện hoặc ánh sáng di chuyển qua Wi-Fi, 4G, các router của ISP và có thể là cáp quang xuyên đại dương.

Latency Budget: Tốc độ ánh sáng trong sợi cáp quang là ~200,000 km/s. Nếu Server ở Singapore và User ở Hà Nội (khoảng 2,200km), một chuyến đi-về (Round Trip) mất ít nhất 22ms chỉ tính riêng thời gian vật lý. Một Request HTTPS thông thường cần ít nhất 3 lần Round Trip (TCP handshake + TLS handshake) trước khi gửi dữ liệu thật. Vậy là mất gần 70ms "chết" trước khi Server bắt đầu nhận được byte đầu tiên.
DNS Lookup: Nếu client chưa cache IP, họ mất thêm 10-100ms để hỏi DNS Server.
TCP Overhead: Ở tầng này, chúng ta đối mặt với TCP Slow Start và Congestion Control. Nếu mạng không ổn định gây Packet Loss, giao thức TCP sẽ tự động giảm tốc độ gửi dữ liệu, khiến Latency tăng vọt dù Server vẫn đang rất rảnh.

Chặng 2: Operating System (Kernel) - Người gác cổng thầm lặng

Khi các packet chạm tới Card mạng (NIC), chúng được đưa vào một cấu trúc dữ liệu gọi là Ring Buffer.

Interrupt Handling: NIC phát ra một Hard Interrupt, buộc CPU tạm dừng việc đang làm để chuyển dữ liệu từ Ring Buffer vào bộ nhớ của Kernel. Tại đây, ksoftirqd (một tiến trình kernel) sẽ bắt đầu ghép các gói tin rời rạc thành một luồng dữ liệu (Stream) hoàn chỉnh theo đúng thứ tự.
The Socket Backlog: Đây là nơi thảm họa thường bắt đầu. Request của bạn phải nằm chờ trong hàng đợi của Socket (Backlog). Nếu cấu hình net.core.somaxconn (mặc định ở nhiều hệ thống Linux chỉ là 128) quá thấp, và lượng Request đổ về cùng lúc lớn, OS sẽ thẳng tay Drop các request này. Kết quả? CPU thấp, nhưng User nhận lỗi "Connection Refused".
Context Switching: Khi dữ liệu đã sẵn sàng, Kernel phải đánh thức tiến trình ứng dụng (User Space). Việc chuyển đổi từ Kernel Space sang User Space không hề miễn phí. Nó đòi hỏi CPU phải lưu lại trạng thái các thanh ghi, nạp lại Page Table. Nếu hệ thống có hàng ngàn Thread đang tranh giành nhau, CPU sẽ tốn 30-50% công suất chỉ để làm việc "chuyển cảnh" này mà không thực sự chạy dòng code nào của bạn.

Chặng 3: Web Server (Tomcat/Nginx) - Máy nghiền HTTP

Dữ liệu thô từ Socket được chuyển lên Web Server. Đây là "trạm thu phí" nặng nề nhất về mặt tính toán.

SSL/TLS Termination: Đây là nơi CPU "đổ mồ hôi". Việc giải mã các request HTTPS đòi hỏi các phép toán logic phức tạp (RSA hoặc Elliptic Curve). Nếu bạn không sử dụng các chip hỗ trợ phần cứng (AES-NI), SSL Termination có thể ngốn tới 20-30% tài nguyên CPU của Server.
HTTP Parsing: Web Server phải đọc từng byte dữ liệu để phân tích: "Đây là GET hay POST? Headers có gì? Content-Length là bao nhiêu?". Một request với Header quá lớn hoặc sử dụng HTTP/1.1 mà không có Pipeline tốt sẽ khiến Web Server mất nhiều thời gian để "hiểu" yêu cầu của client.
Keep-Alive & Connection Management: Web Server phải duy trì một bảng danh sách hàng ngàn kết nối đang mở. Nếu cấu hình Keep-Alive quá dài, các kết nối "chết" từ client sẽ chiếm dụng hết slot, khiến người dùng mới không thể vào được dù hệ thống vẫn còn dư RAM.

Chặng 4: Runtime (JVM/Spring/NodeJS) - Thiết lập môi trường

Request đã vào đến "vùng đất" của ứng dụng, nhưng nó vẫn chưa chạm tới code của bạn.

Thread Allocation (The Bottleneck): Trong mô hình truyền thống (Thread-per-Request), mỗi Request cần một Thread riêng. Mỗi Thread trong JVM mặc định chiếm khoảng 1MB Stack Memory. Nếu bạn có 1000 request đồng thời, bạn mất 1GB RAM chỉ để... giữ các thread đó tồn tại. Nếu Thread Pool bị cạn (Starvation), Request sẽ phải đứng chờ trong một hàng đợi nội bộ của Runtime. Đây chính là "hố đen" khiến latency tăng vọt trong khi CPU vẫn thấp.
Request Context & Filters: Spring Boot hoặc NodeJS sẽ bắt đầu nạp Context, thực thi một chuỗi các Filters và Interceptors. Từ việc giải mã JWT, Logging, Rate Limiting đến phân tích Locale. Mỗi Filter này thêm một vài milliseconds vào tổng thời gian. Nếu bạn có 20 cái Filters "nặng nề", Request của bạn đã chậm đi đáng kể trước khi vào tới Service layer.

Chặng 5: Application Logic - Nơi "Code của bạn" bắt đầu

Cuối cùng, sau khi vượt qua vô vàn "cửa ải", Request mới chạm tới Controller.

Validation & Mapping: Việc chuyển đổi từ JSON thô sang các đối tượng DTO, rồi từ DTO sang Domain Model thông qua các thư viện như ModelMapper hay Jackson thực tế tốn kém hơn bạn tưởng. Trong các hệ thống High-throughput, quá trình Reflection để map dữ liệu có thể chiếm đáng kể thời gian CPU.
Business Rules: Đây là nơi bạn thực thi logic nghiệp vụ. Điều kỳ lạ là ở các ứng dụng doanh nghiệp thông thường, tầng này thường là tầng... chạy nhanh nhất nếu không có các vòng lặp vô tận.

Chặng 6: External Services & I/O - Chướng ngại vật cuối cùng

Hầu hết các ứng dụng không tự làm mọi thứ. Chúng cần gọi Database (PostgreSQL/MongoDB), Cache (Redis), hoặc các API bên thứ ba.

The Golden Rule:"I/O luôn chậm hơn CPU hàng triệu lần". Hãy tưởng tượng nếu một chu kỳ CPU mất 1 giây, thì việc đọc dữ liệu từ RAM mất 4 phút, đọc từ ổ cứng SSD mất 2 ngày, và gửi một gói tin từ Hà Nội vào Sài Gòn mất... 2 năm.
Connection Pool Waiting: Khi code của bạn gọi db.find(), nó không tạo kết nối mới mà mượn một kết nối từ Pool (như HikariCP). Nếu tất cả kết nối trong Pool đều đang bận xử lý các câu query chậm, code của bạn sẽ bị Blocked. Nó đứng im, không làm gì cả, nhưng vẫn giữ Thread đó. Đây là khởi đầu của hiệu ứng Domino: Một service chậm kéo sập toàn bộ hệ thống vì chiếm hết Thread Pool.

6. Trade-Off Analysis: Sự đánh đổi giữa Kiểm soát và Trừu tượng

Là một Senior Engineer, bạn không tìm kiếm giải pháp "tốt nhất", bạn tìm kiếm sự đánh đổi "hợp lý nhất".

Nhận định thực dụng: Chúng ta chấp nhận sự chậm trễ của các tầng trừu tượng không phải vì chúng ta lười biếng, mà vì chi phí để tự quản lý mọi thứ (ví dụ: tự viết code xử lý TCP/IP) là quá đắt đỏ và rủi ro cho doanh nghiệp. Tuy nhiên, khi hệ thống đạt đến quy mô lớn, việc "hiểu" các tầng này để tinh chỉnh (fine-tuning) là bắt buộc.

7. Failure Modes: Khi các tầng "phản bội" bạn

Đây là những kịch bản thực tế mà code của bạn hoàn toàn đúng, nhưng hệ thống vẫn "vỡ":

Lỗi tầng OS (Silent Packet Drop): Khi tcp_max_syn_backlog bị đầy, OS sẽ âm thầm drop các gói tin SYN mới. User thấy ứng dụng "quay vòng vòng" rồi báo Timeout, trong khi Log của ứng dụng không hề có một dòng lỗi nào.
Lỗi tầng Web Server (Keep-alive Contagion): Một script crawler xấu xí tạo ra hàng ngàn kết nối và giữ chúng mở (Keep-alive) mà không gửi dữ liệu. Web Server cạn kiệt slot kết nối, từ chối người dùng thật, dù CPU Server đang ở mức 1%.
Lỗi tầng Runtime (Thread Pool Starvation): Đây là lỗi "kinh điển". Bạn gọi một API bên thứ ba để gửi SMS. API này bỗng nhiên chậm lại (mất 30s thay vì 1s). Toàn bộ Thread trong Pool của ứng dụng bị chiếm dụng để "chờ" SMS. Kết quả là trang Login (vốn chẳng liên quan đến SMS) cũng không thể truy cập được. Hệ thống bị tê liệt hoàn toàn trong khi CPU cực thấp.

8. Evolution Path: Từ Localhost đến Global Scale

Cách nhìn nhận về Request Lifecycle thay đổi tùy theo quy mô hệ thống:

Stage 1: Localhost Development: Mọi tầng gần như trong suốt. Network latency = 0. Bạn tưởng rằng code của mình là yếu tố duy nhất quyết định tốc độ.
Stage 2: Single Server Production: Bạn bắt đầu thấy "mùi" của OS và Web Server. Bạn học cách chỉnh Nginx, cấu hình JVM Heap. Bottleneck bắt đầu xuất hiện ở Socket Backlog hoặc Disk I/O.
Stage 3: Cloud & Microservices: Network trở thành kẻ thù số 1. Một Request giờ đây không chỉ đi qua 6 chặng, mà nó lặp lại chu kỳ đó 10 lần khi đi qua 10 microservices khác nhau. Latency tích lũy trở thành bài toán sống còn. Lúc này, bạn cần đến Service Mesh (như Istio) và Distributed Tracing để không bị lạc trong mê cung.

9. Senior Engineer Lens: Tầng nhận thức về Request

Tại TechCraft, chúng tôi đánh giá trình độ kỹ sư qua "chiều sâu" mà họ nhìn thấy trong một Request:

Junior: Nhìn thấy tính năng. Câu hỏi thường trực: "Làm sao để code chạy được và ra kết quả đúng?".
Mid-level: Nhìn thấy framework và database. Câu hỏi thường trực: "Dùng library nào? Index database đã tối ưu chưa?".
Senior: Nhìn thấy Request Lifecycle và Latency Budget. Họ không hỏi "Code chạy chưa?", họ hỏi: "Request này sẽ tiêu tốn bao nhiêu ms ở Network? Bao nhiêu ở Kernel? Cái giá của việc thêm một Filter này là gì? Nếu API bên thứ ba chậm, hệ thống của ta có cơ chế 'Circuit Breaker' để bảo vệ Thread Pool không?".

Một Senior Engineer nhìn hệ thống như một chuỗi cung ứng (Supply Chain). Mỗi tầng là một kho bãi hoặc trạm trung chuyển, và nhiệm vụ của họ là đảm bảo dòng chảy dữ liệu không bị tắc nghẽn ở bất kỳ cửa ải nào.

10. Key Takeaways: Tư duy hệ thống (System Thinking)

Kết thúc hành trình này, điều tôi muốn bạn khắc cốt ghi tâm là: Backend là một bản giao hưởng (Orchestration). Một Request chậm là lỗi của cả hệ thống, không bao giờ chỉ là lỗi của một mình Controller.

3 lời khuyên hành động cho bạn:

Đo lường thay vì phỏng đoán: Đừng bao giờ nói "mạng chậm" hay "code chậm" nếu bạn chưa có dữ liệu từ Distributed Tracing (như Jaeger, Zipkin) để biết chính xác Request đã mất bao nhiêu thời gian ở mỗi chặng.
Tối ưu I/O và Connection trước khi tối ưu thuật toán: Trong 90% các ứng dụng Web, việc giảm một câu query thừa hay tăng kích thước Connection Pool có tác dụng gấp trăm lần việc đổi từ ArrayList sang LinkedList.
Hiểu về hàng đợi (Queues are everywhere): Mọi chặng trong hành trình 6 bước trên đều có một hàng đợi. Hiểu cách quản lý các hàng đợi này (OS Backlog, Web Server Worker Queue, Runtime Thread Pool, DB Connection Pool) là chìa khóa để làm chủ hiệu năng hệ thống.

Hiểu được hành trình của Request là bước đi đầu tiên để bạn ngừng làm một "người thợ code" và bắt đầu trở thành một "kỹ sư hệ thống" thực thụ.

**Câu hỏi mở cho Episode tiếp theo:**Khi Request đã vượt qua mọi cửa ải và an toàn đi vào tầng Application, làm thế nào để xử lý nó hiệu quả nhất? Server nên tạo một Thread mới cho mỗi người dùng, hay bắt tất cả đứng chờ trong một vòng lặp (Event Loop) duy nhất như cách NodeJS vẫn làm? Cái giá phải trả cho mỗi lựa chọn là gì?

Muốn Đào Sâu Hơn?

Bài viết này là một phần trong hành trình khám phá Backend Engineering, System Design và Production Systems tại TechCraft.

Ngoài các nội dung miễn phí, TechCraft còn phát triển Dev Insider — nơi tập trung các series chuyên sâu về:

Backend Internals Database Internals Data Modeling Patterns Transaction & Consistency Distributed Systems Production System Design AI-Proof Engineer 📘 Facebook: https://www.facebook.com/techcraft.official

🎥 YouTube: https://www.youtube.com/@techcraft.official

🎵 TikTok: https://www.tiktok.com/@techcraft.official

🚀 Dev Insider: https://www.patreon.com/techcraft_official/posts/vi-sao-dev-ra-161163881

Không chỉ học cách build. Học cách build đúng.