Tự đo lường
Mọi con số độ trễ trên trang web này đều đến từ các probe của chúng tôi, và đó chính là điều bạn không nên tin một cách mù quáng. Looking glass chạy từ tất cả 34 trang web, không cần tài khoản, và trả lời câu hỏi duy nhất quan trọng: đường truyền giữa bạn và thành phố đó hiện tại thực sự như thế nào.
Xây dựng lệnh
Chọn một điểm kiểm tra và một công cụ. Các lệnh này chạy từ máy của bạn, tới các máy chủ kiểm tra công khai của chúng tôi, đây là phép đo duy nhất cho biết điều gì đó về đường truyền của chính bạn.
mtr -rwzbc 100 lg-ams-01.paragonvps.comMột tệp 1 GB dữ liệu ngẫu nhiên không nén được, để đo băng thông thay vì hiệu quả nén.
Chạy mỗi lệnh ba lần vào các thời điểm khác nhau trước khi rút ra kết luận. Một traceroute duy nhất trong lúc bảo trì của người khác không phải là bằng chứng.
Nó là gì, và không phải là gì
Một máy chủ probe tại mỗi trang web, trên cùng VLAN với môi trường sản xuất, đằng sau cùng bộ lọc.
Looking glass là một máy chủ nhỏ tại mỗi trang web chạy các bài kiểm tra thay cho bạn và in kết quả thô. Nó nằm trên cùng mạng với các phiên bản của khách hàng và sau cùng bộ lọc biên, vì vậy những gì nó đo được chính là những gì bạn sẽ nhận được. Không có đường thử nghiệm tối ưu, không có kết nối riêng, không có góc yên tĩnh nào của rack.
Nó không phải là một benchmark và không phải là công cụ tiếp thị. Một số kết quả không mấy tích cực: Sydney đến bất kỳ đâu đều đắt đỏ về mili giây, và Johannesburg vẫn đang ổn định đường truyền của mình. Những con số đó có ở đó vì che giấu chúng là vô nghĩa khi bất kỳ ai cũng có thể chạy thử nghiệm.
Tất cả 34 trang web, mọi lúc
Bao gồm cả các trang web pre-order. Johannesburg đã trả lời probe từ trước khi nó có một phiên bản trả phí đầu tiên.
Không cần tài khoản, không cần đăng ký
Nhất quán với phần còn lại của dịch vụ. Bài kiểm tra duy nhất yêu cầu điều gì đó từ bạn là iperf3, và nó cần một token chỉ để ngăn máy chủ bị dùng như một nguồn tấn công DDoS.
Giới hạn tần suất, có chủ đích
Một bài kiểm tra mỗi lần cho mỗi địa chỉ nguồn và bốn bài kiểm tra mỗi phút. Một looking glass là một vector khuếch đại tuyệt vời nếu người vận hành không nghĩ về điều đó.
Kết quả là của bạn
Đầu ra là văn bản thô với một permalink tồn tại trong ba mươi ngày. Dán nó vào một ticket, hoặc vào một cuộc tranh luận với đội ngũ mạng của người khác.
Những gì bạn có thể chạy
Năm bài kiểm tra, được chọn vì chúng trả lời các câu hỏi khác nhau. Chạy tất cả chúng chứng minh rất ít; chọn đúng bài thường giải quyết vấn đề trong một phút.
Bắt đầu với MTR, không phải ping
Một ping chỉ cho bạn biết về một khoảnh khắc. Ba trăm chu kỳ MTR cho bạn biết liệu đường truyền có tệ, thỉnh thoảng tệ, hay ổn và bạn đã gặp may mắn.
Hãy dùng tệp thử nghiệm trước để đo băng thông
Một bản tải xuống 1 GB qua HTTPS mô phỏng những gì hầu hết các tác vụ thực tế làm. Nếu nó chậm nhưng iperf3 nhanh, vấn đề nằm ở kiểm soát tắc nghẽn hoặc các thiết bị trung gian, chứ không phải dung lượng.
MTU của đường truyền đáng để bạn dành chín mươi giây
Một phần đáng ngạc nhiên trong các ticket kiểu "trang tải được nhưng tải lên tệp lớn bị treo" kết thúc ở đây, thường là do một đường hầm nào đó mà ai đó quên mất giữa bạn và chúng tôi.
| Bài kiểm tra | Câu hỏi mà nó trả lời | Giới hạn |
|---|---|---|
| ICMP ping | Nó có thể truy cập không, và thời gian khứ hồi ngay bây giờ là bao nhiêu | Tối đa 100 gói tin mỗi lần chạy |
| Traceroute (ICMP và UDP) | Những chặng mà đường đi thuận từ trang web đó đi qua | Tối đa 30 chặng, 3 probe mỗi chặng |
| MTR | Mất gói và độ trễ trên mỗi chặng theo thời gian thay vì trong một ảnh chụp nhanh | Tối đa 500 chu kỳ, khoảng 8 phút |
| Mục tiêu iperf3 | Bạn thực sự có thể đạt được băng thông bao nhiêu tới trang web đó | Token bảng điều khiển, 60 giây, tối đa 4 luồng |
| Tệp thử nghiệm | Câu trả lời về băng thông mà không cần cài đặt gì | 100 MB và 1 GB qua HTTPS |
| Probe MTU đường truyền | Liệu có thứ gì ở giữa đang làm giảm kích thước gói tin lớn | Báo cáo kích thước lớn nhất còn tồn tại |
Đọc kết quả mà không hiểu sai
Đầu ra của traceroute không phải là một bức tranh về lưu lượng của bạn. Nó là một tập hợp các phản hồi từ các router vốn đang bận rộn với việc khác, và việc đọc nó như một biểu đồ độ trễ sẽ dẫn đến những kết luận sai lầm một cách tự tin.
Hầu hết các khiếu nại về định tuyến mà chúng tôi nhận được đều đúng về triệu chứng và sai về hop.
Các hop ở giữa phóng đại
Một router trả lời gói tin traceroute đang xử lý trên control plane của nó, vốn bận rộn và coi ICMP là việc ưu tiên thấp nhất. Khi một hop hiển thị 180 ms và hop tiếp theo hiển thị 14 ms, thì router đầu tiên đó đang bận, chứ không phải đường truyền phía trước nó.
Chỉ dòng cuối cùng là thật
Mất gói tin xuất hiện ở hop sáu và biến mất ở hop bảy là do giới hạn tốc độ phản hồi, không phải mất lưu lượng. Khi nó bắt đầu từ hop sáu và tiếp tục đến tận đích, hãy gửi đầu ra cho chúng tôi.
DNS ngược chỉ là gợi ý
Các mã sân bay trong tên hop thường lỗi thời hàng năm. Hãy coi chúng như một dấu hiệu về ý định của người đặt tên cho interface, chứ đừng bao giờ coi là bằng chứng về vị trí địa lý.
MPLS che giấu phần giữa
Các đường truyền đi qua lõi chuyển mạch nhãn có thể trông ngắn hơn ba hop so với thực tế. Độ trễ vẫn ở đó; chỉ có phần trung thực về nguồn gốc của nó là biến mất.
Vật lý đặt ra giới hạn thấp nhất
Từ Amsterdam đến Singapore là khoảng 168 ms và không một chính sách peering nào có thể cải thiện nó một cách đáng kể. Nếu phép đo của bạn gần với con số chúng tôi công bố, đường truyền đang hoạt động đúng và giải pháp là một trang web thứ hai, chứ không phải mở một ticket.
Định tuyến bất đối xứng, nơi sự nhầm lẫn cư trú
Traceroute chỉ đo đường đi của gói tin theo chiều tiến và không đo gì khác. Tuy nhiên, mọi con số trong kết quả đều bao gồm hành trình phản hồi của hop đó, và hành trình trở về có thể đi một con đường hoàn toàn khác xuyên qua hành tinh.
Lưu lượng từ chúng tôi đến bạn và lưu lượng từ bạn đến chúng tôi là những quyết định riêng biệt do các mạng riêng biệt đưa ra. Chúng tôi chọn những gì rời đi; các mạng ở giữa chọn những gì quay trở lại. Hầu hết các nhà khai thác chuyển lưu lượng tại thời điểm sớm nhất có thể, vì vậy đường trở về của bạn thường rời khỏi nhà cung cấp của bạn ở một thành phố khác với nơi đường truyền của chúng tôi đi vào.
Hậu quả có thể thấy là một hop trông chậm trong khi lưu lượng thực tế của bạn lại ổn. Tệ hơn là hậu quả vô hình: tắc nghẽn trên đường trở về hiện ra dưới dạng độ trễ mà bạn sẽ mất cả buổi chiều để tìm kiếm ở chiều đi.
Luôn đo cả hai chiều
Chạy MTR từ máy của bạn đến instance, và MTR từ looking glass tại trang web đó về địa chỉ của bạn, lý tưởng nhất là chạy cùng lúc. Chỉ có một nửa bằng chứng sẽ chỉ cho bạn một nửa câu trả lời.
Bất đối xứng tự nó không phải là lỗi
Gần như mọi đường truyền trên internet đều bất đối xứng và gần như tất cả chúng vẫn hoạt động. Nó chỉ trở thành vấn đề khi một hướng bị tắc nghẽn, rớt gói tin, hoặc đi qua một thiết bị lọc giữ trạng thái.
Chúng tôi chỉ có thể ảnh hưởng đến những gì quay trở lại
Chính sách định tuyến của chúng tôi kiểm soát trực tiếp hướng đi. Đường trở về chỉ thay đổi nếu chúng tôi công bố khác đi, chuyển giao ở nơi khác, hoặc nhờ vả một peer một cách lịch sự. Cả ba điều đều có thể; nhưng không điều nào là tức thời.
Các middlebox có trạng thái ghét bất đối xứng
Nếu bạn chạy tường lửa mong đợi thấy cả hai chiều của luồng dữ liệu và đường trở về ngừng đi qua nó, bạn sẽ gặp các lần đặt lại ngắt quãng trông giống hệt như lỗi mạng. Hãy kiểm tra điều này trước khi đổ lỗi cho ai.
Gửi khiếu nại định tuyến được xử lý
Thời gian phản hồi trung bình đầu tiên cho một ticket là 11 phút. Việc sửa định tuyến mất nhiều thời gian hơn, vì người khác phải đồng ý.
- 01
Loại trừ instance của bạn
Kiểm tra tải, connection tracking, bộ đếm interface của instance và xem quy tắc lọc của bạn có đang drop lưu lượng không. Khoảng một trong năm báo cáo kết thúc ở đây, và nó kết thúc nhanh hơn nếu bạn kiểm tra trước.
- 02
Thu thập cả hai chiều
Ít nhất 300 chu kỳ MTR từ phía bạn và 300 từ looking glass tại trang web đó, chạy trong cùng một khung thời gian. Đính kèm permalink thay vì ảnh chụp màn hình; chúng tôi cần số liệu, không phải hình ảnh của chúng.
- 03
Đánh dấu thời gian đúng cách
UTC hoặc bù giờ rõ ràng. "Sáng nay" mô tả một thời điểm cho bạn và một khoảng mười một giờ cho chúng tôi, và việc tương quan dữ liệu luồng với nó là đoán mò.
- 04
Nói rõ điều gì đã thay đổi và khi nào
Luôn luôn như vậy, hay bắt đầu từ thứ Ba. Liên tục, hay từ 20:00 đến 23:00 giờ địa phương. Một câu duy nhất đó thường quyết định liệu chúng tôi đang xem xét thay đổi peering hay tắc nghẽn buổi tối của ai đó.
- 05
Gửi tới bộ phận hỗ trợ
Gửi email tới [email protected] hoặc mở ticket trong bảng điều khiển. Bất kỳ điều gì hóa ra là vấn đề đường đi thực sự sẽ được chuyển lên nhóm mạng trong cùng giờ đó, và bạn sẽ được thông báo những gì chúng tôi đã yêu cầu từ mạng khác.
Những gì chúng tôi có thể làm: repath, giảm ưu tiên một transit, yêu cầu một peer điều tra, hoặc chuyển bạn đến một trang web có tuyến đường tốt hơn. Tắc nghẽn bên trong một mạng mà chúng tôi không chạm tới nằm ngoài cả bốn điều trên, và ở đó chúng tôi định tuyến bạn vòng qua vấn đề thay vì dành một tuần để đúng.
Câu hỏi về looking-glass
Có, trong sáu mươi giây mỗi lần. Token tồn tại để giữ cho máy chủ không trở thành nguồn flood của ai đó, không phải để hạn chế đo lường trung thực. Kiểm tra liên tục muốn instance của bạn ở cả hai đầu.
Nó không nên khác, và nếu khác, chúng tôi muốn biết. Máy chủ probe nằm trên cùng VLAN và kế thừa cùng chính sách. Một khác biệt thực sự thường có nghĩa là chính sách per-prefix được áp dụng cho địa chỉ của bạn, đáng để mở một ticket.
Không trên looking glass công khai. Hãy hỏi trong một ticket với một prefix cụ thể và lý do, bạn sẽ nhận được câu trả lời, bao gồm upstream nào chúng tôi đang ưu tiên cho nó và tại sao.
Trong giới hạn tốc độ, có; các kiểm tra là outbound và vô hại ở mức đó. Sử dụng nó như một nguồn đo lường cho một mục tiêu bạn không kiểm soát là ổn. Nhưng như một thành phần của bất cứ thứ gì lớn hơn, thì không.
Ba mươi ngày, sau đó chúng hết hạn cùng với đầu ra được lưu trữ. Đính kèm nó vào một ticket trong khi nó còn hoạt động, hoặc dán văn bản, mà chúng tôi thích hơn.
Chạy kiểm tra, sau đó chọn thành phố
Độ trễ bạn đo được tốt hơn độ trễ ai đó công bố. Khi các con số có ý nghĩa, chỉ mục vị trí có kho hàng, uplink và khả năng lọc cho mỗi trang web.