Show HN: Máy tính đã đến được máy chủ của tôi như thế nào?
(how-did-i-get-here.net)- Khi khách truy cập mở website, máy chủ chạy traceroute tới IP công khai của họ, hiển thị theo thời gian thực dưới dạng văn bản đường đi mà gói tin di chuyển qua các router và mạng
- Công cụ tự phát triển ktr tăng dần giá trị TTL của các gói ICMP để thu thập phản hồi lỗi từ từng hop, đồng thời tra cứu thông tin mạng cho mỗi hop
- Việc cập nhật màn hình không dùng JavaScript, mà được triển khai bằng cách liên tục đẩy HTML và CSS vào phản hồi HTTP đang mở, để kết quả xuất hiện dần trong khi trang tải
- Đường đi hiển thị là traceroute ngược từ máy chủ tới IP của khách truy cập rồi đảo lại, nên có thể không hoàn toàn giống đường đi thực tế do khác biệt định tuyến hai chiều
- Đường đi trên Internet được tạo nên bởi BGP peering giữa các hệ tự trị (AS) và việc lan truyền bảng định tuyến; lưu lượng di chuyển theo các mạng được kết nối với nhau
Traceroute cá nhân hóa được tạo mỗi lần truy cập
- Văn bản màu xanh ở đầu trang không phải ví dụ được lưu sẵn, mà là traceroute được tạo tức thời cho từng khách truy cập trong lúc website đang tải
- Traceroute cho thấy hành trình mà máy tính hoặc gói tin của khách truy cập đi qua Internet để đến máy chủ lưu trữ website này
- Một đường đi ví dụ bắt đầu từ router của khách truy cập, đi qua mạng ISP, qua nhiều mạng khác, vào mạng nội bộ của Hetzner rồi đến máy chủ
- Router đầu tiên có thể không phản hồi ping; đây là tình huống thường gặp khi ở sau router dùng chung hoặc VPN
- Ở giữa có thể xuất hiện
(no response), và không phải máy chủ nào cũng luôn phản hồi
- Những tên như
core3.sto.hetzner.comlà kết quả của việc thực hiện tra cứu DNS ngược trên IP213.239.252.74xuất hiện trong traceroute để đổi thành tên dễ đọc hơn- Tên DNS ngược chủ yếu nhằm giúp việc debug dễ hơn, và trong nhiều trường hợp không ánh xạ ngược lại IP ban đầu
ktr và traceroute dựa trên ICMP
- Website dùng chương trình traceroute tự phát triển ktr
- Mã nguồn của trang cũng được công khai trên GitHub
- ktr stream kết quả theo thời gian thực đồng thời tra cứu thông tin của từng hop
- Trong định tuyến Internet, máy tính hoặc router xử lý gói tin sẽ chọn thiết bị chuyển tiếp tiếp theo, và quá trình này tiếp diễn cho đến khi tới router có thể gửi trực tiếp tới đích
- Phần triển khai của ktr sử dụng ICMP
- ICMP là giao thức được thiết kế để gửi thông tin chẩn đoán trên Internet
- Gần như mọi thiết bị kết nối Internet đều hỗ trợ ICMP
- Trường TTL(time to live) của gói ICMP không phải thời gian thực, mà là một giá trị đếm ngược
- Mỗi khi router chuyển tiếp gói ICMP, nó phải giảm TTL đi 1
- Khi TTL bằng 0, router dừng chuyển tiếp gói tin và gửi thông báo lỗi rằng đã đạt số hop tối đa về IP nguồn ban đầu
- Traceroute gửi các gói ICMP với TTL tăng dần như 1, 2, 3 để thu thập phản hồi lỗi quay về từ từng hop
- Gói lỗi chứa thông tin chẩn đoán như địa chỉ IP của thiết bị đã gửi lỗi
- Nhờ vậy có thể truy vết đường đi gần đúng của gói tin qua Internet
Giao diện trông như thời gian thực mà không cần JavaScript
- Trang vẫn hoạt động ngay cả khi JavaScript bị tắt
- Với trình duyệt, website trông như đang tải chậm
- Với người dùng, traceroute trông như đang xuất hiện theo thời gian thực
- Khi truy cập, máy chủ nhận yêu cầu HTTP đến từ địa chỉ IP của khách truy cập và lập tức chạy traceroute tới IP đó
- Máy chủ gửi trước phần đầu của phản hồi HTTP rồi giữ kết nối mở
- ktr chuyển các cập nhật traceroute cho máy chủ
- Máy chủ render HTML liên quan và gửi tới máy tính của khách truy cập
- Khi traceroute kết thúc, máy chủ gửi phần văn bản và nội dung còn lại của website rồi đóng kết nối
- Lý do các dòng traceroute trông như được cập nhật dần ở phía trên thay vì phía dưới là do chèn khối CSS
- Về cơ bản, trang web chỉ có thể tải theo chiều tiến về phía trước
- Mỗi lần cập nhật phần hiển thị traceroute, trang chèn kèm CSS để ẩn phần hiển thị trước đó
- Vì trình duyệt render CSS trong lúc đang tải, màn hình trông như được chỉnh sửa theo thời gian
Hạn chế của traceroute ngược
- Đường đi mà trang hiển thị không hoàn toàn giống “đường đi mà gói tin của khách truy cập đã dùng để tới máy chủ”
- Để tính đường đi thực tế, cần có khả năng chạy traceroute từ máy tính của khách truy cập tới máy chủ
- Cách triển khai là chạy traceroute từ máy chủ tới máy tính của khách truy cập, rồi đảo ngược kết quả để hiển thị
- Vì vậy traceroute ở phía trên trông như được tải theo thứ tự ngược
- Traceroute ngược đánh đổi một phần độ chính xác
- Khi gói tin đi theo chiều ngược lại, mỗi thiết bị có thể đưa ra quyết định định tuyến khác
- Chỉ cần một thiết bị đưa ra quyết định khác là phần đường đi sau đó có thể thay đổi
- Dù vậy, đường đi vẫn gần tương tự; khác biệt nhiều khả năng chủ yếu ở mức router cụ thể nào nhìn thấy gói tin
Hệ tự trị và tra cứu WHOIS
- “Mạng” xuất hiện trong traceroute chỉ hệ tự trị (AS)
- AS là tập hợp các router và máy chủ được kết nối riêng với nhau
- Thông thường chúng thuộc sở hữu của cùng một công ty
- Chủ sở hữu AS chọn sẽ kết nối với AS nào khác, qua đó quyết định hình dạng của Internet
- Lưu lượng Internet di chuyển qua các AS có thỏa thuận peering với nhau
- Internet trông như một mạng mở, nhưng thực tế là mạng của các mạng do doanh nghiệp sở hữu, nơi quyền truy cập và kiểm soát phụ thuộc vào giao dịch tài chính và thủ tục hành chính
- Nếu muốn có hệ tự trị riêng, bạn có thể xin ASN từ một trong năm tổ chức đăng ký Internet khu vực (RIR)
- Nếu không có công ty hậu thuẫn hoặc không có đủ điểm kết nối Internet, rất khó được chấp thuận
- Những số như
AS4766trong traceroute là ASN
- ktr dùng giao thức WHOIS để lấy thông tin AS sở hữu từng IP hop
- Nhiều tổ chức theo dõi AS nào bao gồm địa chỉ IP nào
- Nhiều tổ chức cung cấp tra cứu ASN qua WHOIS
- PeeringDB cũng được dùng để xác định thông tin công ty
- PeeringDB có thông tin về khoảng 1/3 tổng số hệ tự trị
- Kết quả tra cứu được dùng cùng với hàng trăm dòng câu lệnh if để tạo phần mô tả việc đi qua mạng
- Đặc tả giao thức WHOIS gần như không quy định cấu trúc
- Nó chỉ quy định đại ý rằng tạo kết nối TCP, gửi nội dung cần tra cứu, rồi máy chủ trả thông tin và đóng kết nối
- Cấu trúc phản hồi WHOIS thực tế giống quy ước do quản trị viên máy chủ tạo ra hơn, và tên trường cần thiết cũng có thể khác nhau như
origin,originas - Parser của ktr giống cách một người đọc kết quả WHOIS rồi tìm ASN cần thiết hơn là một parser nghiêm ngặt
Cách BGP tạo đường đi trên Internet
- Router ở ranh giới mạng quyết định sẽ gửi gói tin tiếp tới mạng nào, và quá trình tương tự tiếp diễn cho đến khi đến mạng có thiết bị đích
- Các router biên này trao đổi thông tin về những mạng có thể kết nối với nhau bằng Border Gateway Protocol(BGP)
- BGP là giao thức tạo nên hình dạng của Internet
- Người dùng thông thường không thể trực tiếp nói BGP
- Phiên bản đầu tiên của BGP được mô tả trong RFC 1105 do kỹ sư của Cisco và IBM công bố năm 1989
- Sau khi thông điệp được truyền một phần trong nguyên mẫu ARPANET năm 1969, nhiều trường đại học, cơ quan chính phủ và công ty bắt đầu tạo mạng riêng và kết nối với nhau
- Năm 1990, BGP v2 ra đời
- Năm 1994, BGP v4 được chỉ định trong RFC 1654
- BGP v4 đã trải qua các lần sửa đổi và vá lỗi vào năm 1995 và 2006, và vẫn được dùng để chọn đường đi giữa các mạng liên kết của Internet hiện đại
Đường đi BGP, peering và bảng định tuyến
- Border gateway, tức router ở ranh giới hệ tự trị, duy trì bảng định tuyến là danh sách mọi đường đi BGP mà nó biết
- Mỗi đường đi BGP chỉ định đường đi ASN có thể theo để đến AS kiểm soát một tập địa chỉ IP cụ thể
- Đường đi BGP được hình thành thông qua quan hệ peering giữa các AS
- Khi border gateway của hai AS peer với nhau, lưu lượng có thể di chuyển giữa hai router đó
- Chúng chia sẻ thông tin đường đi BGP mà nhau biết ở trạng thái mới nhất
- Ví dụ, để Router A của AS0001 và Router B của AS0002 kết nối vật lý và peer với nhau, chúng trao đổi thông điệp BGP để thiết lập phiên BGP
- Router A biết rằng với các đường đi BGP bắt đầu bằng AS0002, nó cần đi qua Router B
- Router B cũng biết thông tin theo chiều ngược lại
- Các peer chia sẻ đường đi mà chúng biết thông qua quá trình quảng bá route (route advertisement)
- Khi Router A thông báo cho Router B mọi đường đi mà nó biết, Router B thêm các đường đi bắt đầu bằng AS0001 vào bảng định tuyến
- Nếu peer khác của Router A quảng bá một đường đi mới, Router A cũng chuyển tiếp đường đi đó cho Router B
- Khi các quảng bá này lan ra toàn mạng AS, mỗi border gateway biết một hoặc nhiều AS path có thể đến một IP nào đó trên Internet
- Khi router gửi gói tin tới một IP cụ thể, nó tìm trong bảng định tuyến đường đi tới AS kiểm soát IP đó
- Sau đó nó dùng nhiều heuristic để chọn đường đi “tốt nhất”
- Các heuristic bao gồm tìm đường đi ngắn nhất và các ưu tiên hoặc không ưu tiên được hard-code đối với một số AS cụ thể
- Router gửi gói tin tới gateway router đang peer với AS đầu tiên của đường đi đã chọn
Đọc kết quả traceroute theo góc nhìn BGP
- AS path trong traceroute ví dụ là AS4766 → AS201011 → AS24940
- Tại một thời điểm nào đó, gói tin đã đến một trong các router của AS4766, và router đó đang peer với router của AS201011
- Router xác định trong bảng định tuyến rằng IP đích có thể đến được qua đường đi bắt đầu bằng AS201011
- Sau đó nó gửi gói tin tới router AS201011 được kết nối
- Trong cùng một ASN vẫn có thể xuất hiện nhiều hop
- Giống sáu hop đi qua Hetzner Online, traceroute hiển thị mọi router mà gói tin đi qua, không chỉ các router biên AS
- Các router nội bộ trong AS có thể ưu tiên đường đi nội bộ hơn đường BGP bên ngoài nếu chúng biết một đường đi nội bộ hiệu quả
- Đường đi nội bộ có thể được học qua BGP nội bộ, giao thức định tuyến nội bộ khác, hoặc được hard-code
- Điều cốt lõi quyết định khả năng đến được trên Internet không phải các hop nội bộ, mà là thỏa thuận peering giữa các AS khác nhau
1 bình luận
Ý kiến trên Hacker News
Xin chào, mình là Lexi. Mình 17 tuổi, và dạo này mình quan tâm đến việc hiểu sâu hơn cách máy tính hoạt động và thể hiện điều đó theo những cách mới
Vài tháng trước mình đã ra mắt https://cpu.land, và thảo luận liên quan ở https://news.ycombinator.com/item?id=37062422
Sau cpu.land, mình chịu khá nhiều áp lực phải tạo ra một thứ gì đó đồ sộ khác, nhưng lại không có ý tưởng nào thực sự cuốn hút, nên trong lúc làm thử vài dự án cá nhân, tình cờ học về cách Internet hoạt động, mình đã tự xây từ đầu một chương trình traceroute được stream theo thời gian thực lên website
Mình chưa từng thấy dạng này trên web, và nghĩ đây là một cách khá mới mẻ, hay ho để trực quan hóa cấu trúc Internet, nên đã trau chuốt lại và làm thành một trang đẹp mắt
Trong quá trình đó mình học được khá nhiều điều thú vị về BGP và cấu trúc Internet, nên đã gộp bài viết chia sẻ kiến thức đó với công cụ traceroute
Mình vẫn đang tiếp tục chỉnh sửa, và chắc chắn ở đâu đó code sẽ bị lỗi, nên nếu có đề xuất gì thì rất mong được nghe
Ngoài ra, về lý do dùng Rust: mình không nghĩ việc chọn ngôn ngữ lập trình là quá quan trọng, nhưng mình muốn viết nhanh một chương trình mức thấp có độ tin cậy cao, và mình thích các thành phần cơ bản để xử lý lỗi của Rust
Gần 30 năm trước, một trong những chương trình CGI đầu tiên mình viết là script Perl bọc traceroute và stream kết quả bằng server push
Cái cũ rồi cũng thành mới lại, nhưng dù vậy cách thể hiện của trang này vẫn rất tốt
Nhân tiện, IPv4 TTL về mặt pháp lý tính bằng giây, nhưng không router nào mất hơn 1 giây và mức giảm tối thiểu là 1, nên trên thực tế nó được dùng như số hop. Các middlebox muốn ẩn mình thì thậm chí còn không giảm nó
Ngoài ra, traceroute trên Linux/Unix mặc định dùng UDP gửi tới các cổng số cao, thường là cổng đóng, thay vì ICMP cho các gói thăm dò, vì về mặt lịch sử UDP ít có khả năng bị drop hoặc lọc hơn ICMP
Việc hỏi traceroute hoạt động như thế nào là một trong những câu hỏi phỏng vấn, nhưng đa số không biết, và ngay cả khi biết thì giá trị của câu hỏi cũng giảm đi. Dù có được hỏi nhiều về TCP/IP, nhiều người vẫn không thể suy luận từ các nguyên lý đầu tiên, và việc xem họ có thể tự gỡ ra được không vẫn là một câu hỏi giải quyết vấn đề hợp lý
Ví dụ: https://www.bgplookingglass.com/
https://www.oreilly.com/openbook/cgi/ch06_06.html
Mình tự hỏi liệu dùng TCP hay UDP thay vì ICMP có cho kết quả chính xác hơn không. traceroute truyền thống cũng có tùy chọn UDP, mtr [1] có thể dùng TCP hoặc UDP, còn tcptraceroute [2] có thể dùng TCP
Và đây là chỗ quá hợp để chèn một câu trích từ Talking Heads. “And you may ask yourself, well, how did I get here?” [3]
[1] https://github.com/traviscross/mtr
[2] https://linux.die.net/man/1/tcptraceroute
[3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
Giờ chỉ cần tìm ra cách làm cho traceroute hoạt động ở từng hop, từ một workstation cụ thể qua Cisco access switch của công ty, core switch, đường hầm BGP tới AWS transit gateway, cho đến khi chạm vào bảng định tuyến VPC của một EC2 instance, thì chắc mới có thể tự xưng là người phụ trách mạng được
Tiếc là quá nhiều node bỏ qua gói traceroute, nên trông chỉ như node thoát của mình kết nối tới Linode rồi Linode kết nối tới máy tính của bạn
Với traceroute xuôi chiều cũng tương tự: router trả lời, server trả lời, và nếu may mắn thì thấy được khoảng một node trong mạng ISP. Còn lại đều bị khóa khá chặt
Bạn nói “BGP là giao thức tạo hình cho Internet, và bạn không thể trực tiếp nói chuyện với nó”, nhưng thực ra một cá nhân lấy ASN và nói chuyện BGP lại dễ đến ngạc nhiên
Nếu bạn thấy việc làm công cụ kiểu này thú vị thì đáng để thử. Nếu quan tâm thì mình có một bài nhập môn mình từng viết: https://qt.ax/asn
Cái này giống cách server của bạn đi tới máy tính của tôi theo chiều ngược hơn là “cách máy tính của tôi đi tới server của bạn”. Định tuyến hai chiều nhiều khả năng sẽ khác nhau khá nhiều
Tóm lại, theo trải nghiệm của mình thì các mạng đi qua thường rất giống nhau, và theo hướng nào thì nội dung này vẫn liên quan và thú vị
Có một bài báo có lẽ sẽ thú vị nếu liên quan đến cách
traceroutehoạt động. Điều mà những người không làm về mạng thường bỏ qua làtraceroutekhông nhất thiết đối xứng. Đường quay về có thể kháchttps://archive.nanog.org/sites/default/files/traceroute-201...
tracerouteđến cùng một đích đã đi qua 8 đường khác nhauCó thể xem như gấp đôi số lượng ECMP tôi từng thấy trên Internet cho đến nay
Và lưu lượng từ văn phòng Cairo đến core ở Anh và lưu lượng theo chiều ngược lại cũng đi qua các đường khác nhau. London→Cairo là đi thẳng và vẫn bị mất gói nhiều, còn Cairo→London giờ đi qua ntt và có vẻ ổn. Nếu đến ngày mai vẫn chưa sửa xong thì có lẽ phải đổi local preference
Có nói rằng “WHOIS là một giao thức thú vị để viết parser”, nhưng thực tế thì gần như bất khả thi
Phản hồi về bản chất là dạng tự do, và máy chủ cũng có thể không phản hồi. Tôi cũng từng thử, và vào khoảng 10 năm trước có thể làm một parser tạm dùng được cho 90% địa chỉ hoặc tên miền, nhưng phần còn lại thì không thể xử lý
Giờ còn tệ hơn, gần như mọi thứ đều bị che sau lớp bảo vệ quyền riêng tư. Họ nói là để bảo vệ PII, nhưng bản ghi WHOIS vốn không phải để chứa thông tin cá nhân mà để chứa thông tin liên hệ của người vận hành mạng
Tôi cho rằng đây là lỗi của ICANN. ICANN từng có quy định mạng phải cung cấp máy chủ WHOIS công khai nhưng không thực thi, và giờ thì họ đã bãi bỏ quy định đó
Tuy vậy không phải nơi nào cũng vận hành máy chủ RDAP. Sẽ tốt nếu ICANN/IANA hoặc ai đó bắt buộc việc này
Thông tin người vận hành mạng cũng có thể là PII. Thông tin của tôi là PII, và vì tôi sở hữu tên miền nên việc đưa thông tin của tôi vào WHOIS là đưa PII vào WHOIS
Dịch vụ bảo vệ quyền riêng tư chỉ chuyển tiếp mọi thứ cho tôi, trừ thư rác
Với công ty thì tôi không thấy có lý do chính đáng nào để cho phép dịch vụ bảo vệ quyền riêng tư, nhưng chưa phải mọi tên miền đều thuộc sở hữu của các tập đoàn lớn
Thay vì truy vết ICMP ECHO riêng, có thể tiến thêm một bước bằng cách tận dụng chính kết nối TCP HTTP sẵn có giữa trình duyệt phía client và máy chủ web
Khi đó có thể đi xuyên qua NAT phía client hoặc tường lửa trạng thái
traceroutethực tế thì nó sẽ hoạt động ra saoCó những công trình trước đây về reverse traceroute
https://research.cs.washington.edu/networking/astronomy/reve...
Bài báo: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
Video: http://www.usenix.org/multimedia/nsdi10katz-bassett
Cũng nên biết rằng các gói của một phiên TCP thường đi qua Internet theo đường bất đối xứng. Theo kinh nghiệm của tôi, lý do phổ biến nhất là các quy tắc kinh doanh liên quan đến chi phí và lỗi con người
Nếu nghĩ về cách IP hoạt động thì bản thân điều này không hẳn là vấn đề, nhưng có thể khiến việc hiểu định tuyến trở nên khó hơn
Boise State University và University of Idaho là hai trường nằm ở hai đầu bang Idaho. UIdaho ở phía bắc gần Spokane hơn và phần lớn kết nối đi từ Seattle, còn Boise gần phía Salt Lake hơn nên thường kết nối qua Portland hoặc Salt Lake City
Khu trung tâm bang nằm giữa hai trường là vùng núi nên hầu như không có kết nối lớn, nhưng trước đây UofIdaho có một lớp học từ xa ở khu vực phía nam nên có một đường truyền nhỏ
Vào một thời điểm cuối thập niên 90, kỹ sư mạng của BSU và kỹ sư của UofI biết rằng họ đặt switch và thiết bị định tuyến trong cùng một tòa nhà, nên đã nối cáp Ethernet giữa hai bên
Kết quả là thảm họa. Hai mạng bắt đầu quảng bá BGP cho nhau, và kết nối đó được lan truyền ra toàn bộ Internet. Đột nhiên xuất hiện một bước nhảy rất ngắn giữa mạng phía Seattle và mạng phía Salt Lake City, và đường T1 nhỏ bé tội nghiệp đó bị bão hòa hoàn toàn
Điều thú vị là điều này chỉ xảy ra theo một hướng. Boise quảng bá đường đi còn Idaho thì không, nên lưu lượng về cơ bản chỉ hỏng theo một chiều
Dĩ nhiên là sợi cáp đã bị rút ra, và vài năm sau khi tôi làm việc tại UofIdaho thì ai cũng biết rõ rằng tuyệt đối không được nối lại hai mạng đó. Trớ trêu thay, vào lúc ấy tôi đang điều hành một chương trình triển khai I2 cho cả hai trường
Trên thiết bị của tôi thì hoàn toàn không thấy các bước trung gian giữa thiết bị của tôi và máy chủ. Chỉ để tham khảo
Tôi đang xử lý ngay bây giờ và hy vọng nó sẽ sớm hoạt động tốt hơn. Trong lúc đó tôi sẽ tăng timeout nên thời gian tải sẽ lâu hơn nhưng có lẽ sẽ hoạt động ổn hơn
mtr cũng đáng được nhắc đến. Tôi dùng nó thường xuyên hơn nhiều so với traceroute
Nó giúp chẩn đoán tình trạng mất gói không liên tục và cho phép nắm được bức tranh trung bình của luồng mạng
Bài viết này của APNIC giải thích chi tiết hơn về
mtrvà cách đọc kết quả của nó, đồng thời cũng đề cập đến việc MPLS có thể làm mờ đường đi thực tế như thế nàohttps://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
Việc truy vết bằng UDP đôi khi cũng hữu ích, và cũng nên biết rằng nhiều router sẽ chọn lọc loại bỏ ICMP khi đang chịu tải
Bài viết hay và cách diễn đạt cũng rất tốt