Chương nào của Kurose và Ross giúp FDE gỡ lỗi mạng của khách

Thử hình dung một buổi chiều ở văn phòng khách hàng. Họ nói mỗi lần gọi API mất vài giây, trong khi log máy chủ của bạn cho thấy xử lý chỉ mất vài chục mili giây. Khoảng chênh ấy nằm đâu đó trên đường đi, và người phải chỉ ra nó nằm ở bước nào là bạn.

Đó là khoảnh khắc quen thuộc của FDE. Bạn ngồi trong mạng của người khác, với proxy, chứng chỉ và Wi-Fi của người khác, và không có đội hạ tầng nào gánh hộ. Với nhiều kỹ sư quen làm việc ở tầng ứng dụng, đây cũng có thể là lần đầu cần nhìn kỹ từng gói tin.

Cuốn Computer Networking: A Top-Down Approach của James F. Kurose (UMass Amherst) và Keith Ross (NYU Abu Dhabi) không viết cho FDE. Nhưng nếu đọc đúng chương, cộng với bộ lab Wireshark mà hai tác giả phát miễn phí cho giảng viên, sinh viên lẫn người đọc, nó cho bạn đúng thứ cần có trong buổi chiều hôm đó.

Thứ tự từ trên xuống trùng với thứ tự khách than phiền

Ấn bản thứ 9 ra mắt mùa hè 2025, Pearson ghi ngày phát hành 20/6/2025. Bạn có thể đọc bản online, thuê hoặc mua sách in. Tám chương đi từ “Computer Networks and the Internet” đến “Security in Computer Networks”, và Pearson mô tả cách tiếp cận là trình bày chủ đề phức tạp này theo lối từ trên xuống.

Lối từ trên xuống là lý do cuốn sách hợp với FDE. Khách hàng không bao giờ báo lỗi bằng tầng mạng. Họ báo bằng thứ họ thấy: trang không tải, request treo, chứng chỉ báo đỏ, và bắt đầu từ tầng ứng dụng rồi đi xuống chính là cách một người gỡ lỗi giỏi đặt câu hỏi.

Chương 2 và 3 là nơi phần lớn sự cố bắt đầu

Chương 2 (Application Layer) trong ấn bản này đã cập nhật HTTP/3 và QUIC, đúng phần nên đọc trước khi bạn gỡ lỗi lưu lượng web hay API của khách. Chương 3 (Transport Layer) cập nhật phần kiểm soát tắc nghẽn và hoàn tất phần QUIC bắt đầu từ chương 2, nên hai chương nên đọc liền nhau.

Hai chương này phủ gần hết những chỗ mà vài giây trong ca “API chậm” có thể biến mất: phân giải tên, thiết lập kết nối và gói tin rơi trên đường. Cách dùng chúng hiệu quả nhất là mang thẳng vào một bản chụp gói tin.

Lần theo ca “API chậm” trong Wireshark

Xin phép khách rồi chụp gói tin ngay trên máy đang gặp lỗi, trong lúc tái hiện đúng một lần gọi API. Sau đó đừng nhìn cả bản chụp cùng lúc. Lọc từng lớp, theo đúng thứ tự cuốn sách dạy. Các con số dưới đây chỉ là ví dụ minh họa để bạn hình dung một kết quả xấu trông ra sao, không phải ngưỡng chuẩn.

Bước đầu, gõ bộ lọc dns và so thời điểm truy vấn với thời điểm có phản hồi.

Giả sử một truy vấn bình thường trả lời trong khoảng 20 mili giây, nhưng bản chụp của khách cho thấy truy vấn gửi lại hai lần và phản hồi về sau 1,5 giây: phần lớn độ trễ đã xảy ra trước khi HTTP kịp bắt đầu, và đó là kiến thức của chương 2.

Bước hai, lọc tcp.analysis.retransmission để Wireshark chỉ hiện những đoạn bị gửi lại. Thử hình dung một lần gọi gồm 400 đoạn, trong đó 40 đoạn bị gửi lại, tức 10%: gói tin đang rơi trên đường, và chương 3 cho bạn ngôn ngữ để giải thích vì sao kết nối bị bóp băng thông sau đó.

Nếu chỉ thấy một hai dòng lẻ tẻ, nhiều khả năng thủ phạm nằm chỗ khác. Còn nếu lọc tcp mà gần như trống, thử lọc quic, vì kết nối có thể đang chạy HTTP/3.

Bước ba, lọc tls.handshake để xem handshake đi tới đâu. Ví dụ, nếu máy khách gửi lời chào mở đầu rồi chờ vài giây không có hồi âm, hoặc handshake kết thúc bằng một cảnh báo lỗi, bạn đã tìm thấy chỗ gãy. Chỉ khi ba bước trên đều sạch, bạn mới đo khoảng từ lúc gửi request đến lúc nhận byte phản hồi đầu tiên.

Lúc đó câu bạn nói với khách thay đổi hẳn. Thay vì “để em kiểm tra”, bạn nói được “kết nối của anh đang gửi lại gói nhiều lần trước khi request đến được máy chủ”. Câu đầu chỉ xin thêm thời gian, câu sau chỉ ra hướng sửa.

Có ba lỗi rất dễ mắc khi làm việc này:

• Bạn chụp trên laptop của mình thay vì trên đường đi thật của khách, nên bản chụp sạch trong khi khách vẫn chậm.
• Bạn kết luận từ một lần chụp duy nhất, trong khi sự cố có thể chỉ xuất hiện lúc mạng đông.
• Bạn đổ lỗi cho “mạng” trước khi xem DNS, dù DNS là bước rẻ nhất để loại trừ.

Chương 8 khi lỗi nằm ở handshake

Chương 8 (Security) của ấn bản thứ 9 có thêm TLS 1.3 và WPA3, đúng phần cần đến khi chứng chỉ hay handshake hỏng trong môi trường của khách. Đọc chương này để hiểu một handshake đúng diễn ra thế nào trước khi đi tìm chỗ nó gãy.

Hai chương còn lại đáng biết nhưng có thể để sau. Chương 5 (Network Layer: Control Plane) bổ sung phần SDN, lấy hệ điều khiển mạng Orion của Google làm case study, hữu ích khi bạn phải làm việc với routing hay mạng cloud của khách.

Chương 7 (Wireless and Mobile Networks) được viết lại nhiều nhất trong ấn bản này, với Wi-Fi 6 và 5G. Hãy mở nó khi sự cố nằm ở Wi-Fi hay mạng di động ngay tại văn phòng của khách.

Lab Wireshark biến đọc thành làm

Trang lab của hai tác giả viết rằng công cụ cơ bản để quan sát thông điệp trao đổi giữa các thực thể giao thức là packet sniffer. Bộ lab dạy đúng kỹ năng ấy với các chủ đề HTTP, DNS, TCP, UDP, IP, NAT, DHCP, ICMP, Ethernet và ARP, Wi-Fi 802.11, 5G và TLS.

Đây không phải bài tập chỉ để thi. Tài liệu chính thức của Wireshark cho biết các quản trị viên mạng dùng nó để xử lý sự cố mạng, nên kỹ năng bạn luyện ở nhà chính là công cụ bạn mở ra trên máy của khách.

Thứ tự hợp lý cho một FDE là đọc chương 2 rồi làm lab HTTP và DNS, đọc chương 3 rồi làm lab TCP, sau đó nhảy sang chương 8 và lab TLS. Chương 1 đọc lướt để nắm khung, các chương còn lại đọc khi dự án đòi hỏi.

Ba ý nên giữ lại và cách đưa vào CV

Gấp sách lại, có ba ý nên mang theo ra hiện trường. Gỡ lỗi từ trên xuống, bắt đầu từ triệu chứng khách nhìn thấy. QUIC được sách giải thích ở cả chương tầng ứng dụng lẫn chương tầng vận chuyển, nên đừng tìm lỗi của nó ở một chỗ duy nhất. Và quan sát bằng packet sniffer luôn đi trước phỏng đoán.

Về nghề nghiệp, một dòng “biết networking” trong CV không thuyết phục ai. Hãy chụp một lần gọi API thật từ dự án cá nhân, đi qua ba bộ lọc ở trên, viết một trang giải thích mỗi bước tốn bao lâu rồi đưa vào portfolio.

Khi đọc tin tuyển FDE, để ý những mô tả nhắc đến môi trường mạng của khách, VPC hay proxy doanh nghiệp: đó là chỗ bản phân tích ấy giúp bạn nổi bật.

Lần tới khách nói “API chậm”, bạn sẽ không đoán mò nữa mà mở bản chụp gói tin ra và chỉ cho họ thấy chỗ chậm.