33/34 Ping và traceroute Các chương

Ping và traceroute cho chúng ta thấy gì?

Làm sao biết gói tin chậm ở chặng nào?

Máy bạn biết mạng đang chậm: video bắt đầu xoay vòng.

Nhưng nó không biết 200 ms vừa mất ở đâu. Trong Wi-Fi nhà bạn? Trong mạng của ISP? Hay trên một tuyến cáp biển cách đó hàng nghìn kilomet?

Làm sao biết gói tin chậm ở chặng nào?

Ping: đi tới đích rồi quay về mất bao lâu?

Năm 1983, Mike Muuss ở Ballistic Research Laboratory cần một cách đơn giản để kiểm tra một máy khác trên mạng IP có còn liên lạc được hay không và mất bao lâu để nhận phản hồi.

IP lúc đó đã có sẵn một cơ chế phù hợp: ICMP.

ICMP có hai loại thông điệp tên là Echo Request và Echo Reply. Một máy gửi Echo Request tới máy khác. Nếu máy kia cho phép trả lời, nó gửi Echo Reply ngược lại.

Muuss viết một chương trình nhỏ thực hiện đúng việc đó và bấm giờ từ lúc gửi đến lúc nhận phản hồi.

Ông gọi nó là ping, theo tiếng sonar phát ra rồi chờ tiếng vọng quay về.

Thời gian ping in ra là thời gian khứ hồi (round-trip time, RTT): thời gian để gói tin đi tới đích và phản hồi quay trở lại.

Sơ đồ thời gian chạy từ trên xuống với Echo Request đi từ máy bạn tới máy đích và Echo Reply quay về còn ngoặc RTT nằm trên cột máy bạn từ lúc gửi tới lúc nhận

Ví dụ:

64 bytes from 1.1.1.1: time=18.4 ms

18.4 ms không có nghĩa chiều đi mất 9.2 ms. Gói đi và gói về có thể được định tuyến qua hai con đường khác nhau.

Sau nhiều lần ping, chương trình còn cho biết thời gian nhỏ nhất, trung bình, lớn nhất và mức dao động giữa các lần đo. Những con số này giúp nhìn ra kết nối có ổn định hay không.

Một dòng như:

Request timeout

cũng không có nghĩa máy đích chắc chắn đã chết. Tường lửa hoặc máy chủ có thể đơn giản là không trả lời ICMP Echo.

Ping vì vậy trả lời khá tốt hai câu:

Có nhận được phản hồi không?

Nếu có, cả chuyến đi và về mất bao lâu?

Nhưng nếu kết quả là 244 ms, ping không nói được 244 ms đó phát sinh ở đâu.

Traceroute: khiến từng router lần lượt lên tiếng

Gói IP không đi thẳng từ máy bạn tới server. Nó đi qua nhiều bộ định tuyến (router).

Mỗi gói còn mang một bộ đếm gọi là TTL. Mỗi router chuyển tiếp gói tin phải giảm TTL đi 1.

Nếu TTL giảm xuống 0, router không được chuyển gói tiếp nữa. Nó huỷ gói và thường gửi ngược về một thông báo ICMP Time Exceeded.

Traceroute lợi dụng đúng cơ chế này.

Đầu tiên, nó gửi một gói có:

TTL = 1

Router đầu tiên nhận gói:

1 → 0

Gói bị huỷ.

Router gửi ICMP Time Exceeded về máy bạn. Nhờ đó, traceroute biết địa chỉ của router thứ nhất và đo được thời gian phản hồi.

Sau đó traceroute gửi gói mới:

TTL = 2

Router thứ nhất giảm còn 1 và chuyển tiếp.

Router thứ hai giảm:

1 → 0

Lần này router thứ hai phải lên tiếng.

Tiếp tục với:

TTL = 3
TTL = 4
TTL = 5
...

và từng chặng trên đường lần lượt lộ ra.

Ba hàng TTL = 1 TTL = 2 TTL = 3 mà mỗi hàng gói tin đi xa thêm một router rồi dừng ở R1 R2 R3 có dấu × và router đó gửi Time Exceeded về máy bạn

Không có một giao thức đặc biệt tên là “traceroute” mà mọi router phải hỗ trợ.

Công cụ chỉ ghép hai cơ chế vốn đã có trong IP và ICMP: TTL giảm dần và thông báo khi TTL hết.

Cuối năm 1988, Van Jacobson ở LBL viết traceroute trong lúc điều tra một vấn đề định tuyến, dựa trên một ý tưởng của Steve Deering.

Một mẹo gỡ lỗi nhỏ cuối cùng lại trở thành một trong những công cụ quen thuộc nhất để nhìn vào đường đi của Internet.

Một traceroute thật từ Melbourne về Việt Nam

Bản ghi dưới đây được chạy ngày 18/09/2026 từ một máy ở Melbourne tới vnexpress.net.

$ traceroute -m 22 -w 1 -q 1 vnexpress.net
traceroute to vnexpress.net (111.65.250.2), 22 hops max
 1  192.168.1.1                                              7.956 ms
 2  172.31.0.33                                             12.491 ms
 3  100.127.30.101                                          10.281 ms
 4  103.51.113.205.vic.leaptel.network                      11.483 ms
 5  103.51.113.193.vic.leaptel.network                      11.740 ms
 6  e25.mel-ndcm1-cr9.globalsecurelayer.com                 11.049 ms
 7  po9.mel-eqxme1-bb1.globalsecurelayer.com                10.395 ms
 8  po9.mel-eqxme1-bb1.globalsecurelayer.com                13.447 ms
 9  po6.syd-eqxsy5-bb1.globalsecurelayer.com                21.943 ms
10  e50.guam-rti-cr1.globalsecurelayer.com                 119.700 ms
11  e50.guam-rti-cr1.globalsecurelayer.com                 120.432 ms
12  e4-1.ty-eqxty2-bb4.globalsecurelayer.com               121.254 ms
13  po7.sg-eqxsg3-bb5.globalsecurelayer.com                188.799 ms
14  42.112.149.133                                         244.657 ms
15  *
16  *
17  *
18  *
19  118.69.189.52                                          235.843 ms
20  42.119.253.190                                         237.328 ms
21  42.112.0.226                                           201.981 ms
22  *

Chỉ cần đọc từ trên xuống đã thấy con đường dần mở ra.

Chặng Có thể đọc ra gì
192.168.1.1 · 8 ms router trong mạng nhà, cũng là cổng mặc định
100.127.30.101 thuộc dải 100.64.0.0/10, dải địa chỉ dùng chung (Shared Address Space) thường được ISP dùng cho NAT cấp nhà mạng (CGNAT)
…vic.leaptel.network · 11 ms gói đã đi vào hạ tầng của ISP
mel-… · 11 ms tên máy (hostname) cho thấy router được đặt tên theo Melbourne
syd-… · 22 ms tuyến tiếp tục qua Sydney
guam-… · 120 ms thời gian tăng gần 100 ms ở một chặng dài ra khỏi Australia
ty-… → sg-… các tên máy cho thấy tuyến tiếp tục qua Tokyo rồi Singapore
42.112.… tiền tố thuộc mạng của một nhà mạng Việt Nam
* gói thăm dò (probe) đó không nhận được phản hồi

Cú thay đổi rõ nhất nằm ở đây:

Sydney       21.943 ms
Guam        119.700 ms

Gần 100 ms xuất hiện chỉ sau một bước.

Đó là dấu hiệu rất mạnh cho thấy từ điểm này gói tin đã đi qua một chặng truyền dẫn dài. Với tuyến này, tên máy cũng phù hợp với việc nó đi từ Sydney tới Guam.

Đây chính là thứ ping không thể cho thấy.

Ping chỉ nói:

~240 ms

Traceroute cho thấy độ trễ bắt đầu tăng mạnh ở đoạn nào của đường đi.

Nhưng đừng cộng các con số lại

Có một chi tiết dễ đọc nhầm.

Chặng 14:

244.657 ms

nhưng chặng 21 lại chỉ:

201.981 ms

Router 21 rõ ràng xa hơn router 14. Tại sao thời gian lại thấp hơn?

Vì mỗi dòng là một phép đo khứ hồi riêng biệt từ máy bạn tới router đó.

Nó không phải thời gian của riêng đoạn:

router 13 → router 14

và cũng không phải một bộ đếm cộng dồn hoàn hảo.

Router có thể bận ở thời điểm trả lời một gói thăm dò. ICMP có thể bị ưu tiên thấp. Hàng đợi trên mạng cũng thay đổi liên tục.

Vì vậy không nên lấy:

244 ms - 188 ms

rồi kết luận đoạn đó chắc chắn mất đúng 56 ms.

Traceroute hữu ích nhất khi nhìn xu hướng và những bước nhảy lớn, đặc biệt khi cùng một mẫu xuất hiện qua nhiều lần chạy.

Dấu * nghĩa là gì?

Các chặng 15 đến 18 chỉ hiện:

*

Gói tin vẫn tiếp tục tới chặng 19, nên rõ ràng các router đó vẫn đang chuyển tiếp dữ liệu.

Chỉ là chúng không trả lời gói thăm dò của traceroute.

Router có thể:

  • chặn ICMP;
  • giới hạn số phản hồi;
  • ưu tiên chuyển dữ liệu thật hơn việc trả lời traceroute;
  • hoặc tường lửa trên đường đã chặn thông báo quay về.

Vì vậy:

*

không đồng nghĩa với:

mạng bị đứt ở đây

Ping và traceroute vì vậy nhìn cùng một con đường theo hai cách khác nhau:

Ping: chuyến đi và về mất bao lâu?

Traceroute: trên đường tới đích, những router nào đã xuất hiện và độ trễ bắt đầu thay đổi ở đâu?

Từ router trong nhà, mạng ISP, NAT cho tới những tuyến quốc tế dài hàng nghìn kilomet, một phần của Internet vốn vô hình bắt đầu hiện ra ngay trong terminal.

Nhưng đây mới chỉ là đường đi của một gói tin.

Khi bạn gõ một địa chỉ web rồi nhấn Enter, trước khi trang xuất hiện còn phải xảy ra DNS, kết nối giao vận (transport), mã hoá TLS và HTTP.

Nhấn Enter, trong chưa tới một giây chuyện gì xảy ra?

Nguồn bài viết (4)

  1. The Story of the PING Program · Mike Muuss, U.S. Army Research Laboratory
  2. traceroute (mã nguồn và trang man, LBL) · Lawrence Berkeley National Laboratory, Network Research Group
  3. RFC 792: Internet Control Message Protocol · IETF / RFC Editor (J. Postel), 1981
  4. traceroute(8) — Linux manual page · man7.org