Internet Protocol là gì và yêu cầu của bạn thất bại ở đâu?
Hiểu Internet Protocol phối hợp với DNS, TCP, UDP, TLS và HTTP như thế nào. Dùng ví dụ theo từng lớp để xác định lỗi mà không nhầm IP với website.
Tác giảYiyao
IP chuyển các gói tin giữa các điểm cuối mạng
Internet Protocol cung cấp việc định địa chỉ và chuyển các gói tin qua các mạng liên kết. IPv4 và IPv6 là hai phiên bản của giao thức ở lớp mạng này. Địa chỉ IP xác định một điểm cuối trong bối cảnh mạng; bản thân nó không phải là trang web, tài khoản người dùng hay sự bảo đảm rằng dịch vụ luôn khả dụng.
IP không tự cung cấp đầy đủ độ tin cậy, thứ tự, mã hóa và hành vi ứng dụng cần có trong một phiên web hiện đại. Các giao thức khác và logic ứng dụng đảm nhận những chức năng đó. Phân tách vai trò giúp việc chẩn đoán chính xác hơn.
Theo dõi một yêu cầu HTTPS quen thuộc
Với một yêu cầu HTTPS thông thường tới hostname, trước hết máy khách cần có địa chỉ, thường lấy được qua DNS. Sau đó máy khách thiết lập giao thức truyền và kết nối ứng dụng bảo mật phù hợp trước khi trao đổi các thông điệp HTTP. Chi tiết khác nhau giữa các phiên bản HTTP, vì vậy đây là trình tự khái niệm chứ không phải công thức gói tin cố định.
Lỗi ở một giai đoạn có thể ngăn các giai đoạn sau diễn ra. Nếu phân giải tên thất bại, có thể không có kết nối máy chủ ứng dụng để kiểm tra. Nếu máy chủ trả về lỗi HTTP, yêu cầu đã đi xa hơn một lỗi DNS đơn giản.
Đặt một câu hỏi riêng cho từng lớp
| Mối quan tâm | Câu hỏi | Bằng chứng |
|---|---|---|
| DNS | Tên trả về địa chỉ hoặc bản ghi nào? | Truy vấn, loại, trình phân giải và trạng thái DNS |
| IP và đường đi mạng | Lưu lượng có đến được đích mạng dự kiến không? | Kết nối của máy khách và chẩn đoán định tuyến được cho phép |
| Transport | Có thể thiết lập giao tiếp cần thiết không? | Kết quả kết nối và điểm cuối dịch vụ |
| TLS | Kết nối bảo mật có hợp lệ cho hostname này không? | Chứng chỉ và kết quả bắt tay |
| HTTP | Yêu cầu nhận được phản hồi nào? | Trạng thái, header và nội dung |
| Đầu ra nhiệm vụ | Nội dung có đáp ứng yêu cầu thực tế không? | Các trường bắt buộc hoặc thao tác người dùng đã được xác minh |
Một dấu kiểm màu xanh không thể thay thế các kiểm tra khác. Một website có thể phân giải thành công một địa chỉ, chấp nhận kết nối nhưng vẫn trả về sai trang tenant. Một lần truyền hoàn tất cũng có thể chứa thông báo lỗi thay vì bộ dữ liệu được yêu cầu.
Giữ TCP và UDP đúng vai trò
TCP cung cấp dịch vụ luồng byte có thứ tự và đáng tin cậy cho các ứng dụng sử dụng nó. UDP cung cấp các datagram nhưng không có cùng bảo đảm về việc giao nhận và thứ tự. Ứng dụng và giao thức có thể xây dựng thêm hành vi trên một trong hai cơ chế truyền này.
Đừng đồng nhất UDP với mọi tác vụ nhanh hoặc TCP với mọi tác vụ chậm. Ứng dụng, đường đi mạng, mất gói, thiết kế giao thức và cách triển khai đều có ảnh hưởng. DNS có thể dùng cả TCP và UDP; HTTPS có thể dùng cách truyền khác nhau tùy phiên bản HTTP được thương lượng.
Tách việc phát hiện IPv6 khỏi việc truyền IPv6
Bản ghi AAAA cung cấp thông tin địa chỉ IPv6 nhưng không tạo ra tuyến IPv6 hoạt động. Tương tự, bản ghi A không chứng minh đích IPv4 chấp nhận dịch vụ dự kiến. Hãy dùng hướng dẫn dual-stack để kiểm tra từng họ địa chỉ từ một môi trường thực sự hỗ trợ nó.
Khi ghi nhận kết quả, hãy xác định công cụ chạy trên thiết bị của người dùng hay trên máy chủ từ xa. Công cụ DNS công khai của Arcvenza quan sát từ nút của chính nó. Câu trả lời giúp điều tra DNS nhưng không thể xác lập mọi thuộc tính của mạng cục bộ của người dùng.
Phân tích một sự cố theo từng lớp
Hãy tưởng tượng một yêu cầu dữ liệu được cho phép phân giải thành công và tới dịch vụ HTTPS, nhưng dịch vụ trả về 403. Thay đổi bản ghi DNS khó có thể sửa quyết định quyền truy cập. Hãy đọc các yêu cầu xác thực và quyền truy cập của ứng dụng, rồi điều tra phản hồi cùng người phụ trách dịch vụ.
Bây giờ hãy tưởng tượng cùng máy khách báo timeout DNS và không nhận được trạng thái HTTP. Hãy bắt đầu từ trình phân giải và đường đi mạng thay vì thay đổi các trường trong nội dung yêu cầu. Thói quen chẩn đoán hữu ích là xác định giai đoạn cuối cùng đã được xác nhận và giai đoạn đầu tiên thất bại trước khi chọn cách sửa.
Câu hỏi thường gặp
Một địa chỉ có thể lưu trữ nhiều website không? Có. Hạ tầng lưu trữ và định tuyến ứng dụng có thể liên kết nhiều hostname với hạ tầng dùng chung, vì vậy một địa chỉ số không phải là thay thế đầy đủ cho URL dự kiến.
Biết một IP có cho biết vị trí chính xác của một người không? Không. Thông tin mạng và đăng ký có những giới hạn, không nên được xem là vị trí cá nhân chính xác. Chỉ dùng thông tin phù hợp với nhiệm vụ chẩn đoán được cho phép.
Chọn trang chẩn đoán tiếp theo
Khi không nhận được phản hồi, hãy dùng hướng dẫn DNS server; với đường đi riêng cho IPv6, hãy dùng hướng dẫn AAAA; khi máy chủ đã trả về phản hồi ứng dụng, hãy dùng hướng dẫn mã lỗi HTTP。Hãy giữ truy vấn, môi trường, phản hồi và kết quả nhiệm vụ cùng nhau để người xem tiếp theo có thể theo dõi lập luận.
Tài liệu tham khảo kỹ thuật
RFC 791: Internet Protocol · RFC 3596: Bản ghi DNS IPv6 · RFC 9110: Ngữ nghĩa HTTP