Lưu ý đây không phải là bản sao của Tại sao lớp IP nhận biết các lớp cao hơn trong ngăn xếp mạng?
Nhu cầu về một mã định danh giao thức (ví dụ: trường Giao thức của người đứng đầu IP) trong giao tiếp dựa trên gói là rõ ràng: Đây là hoặc một loại thuật toán suy luận chuyên sâu tính toán. Câu hỏi là: tại sao nó phải tồn tại như một phần của tiêu đề IP chứ không phải trong các tiêu đề của giao thức được đóng gói?
Dường như với tôi, đây là một trong những trường hợp mà sự rõ ràng về mặt lý thuyết đáp ứng những cân nhắc thực tế (AKA "Haskell gặp Go" ...): Một mặt đặt trường "giao thức" trong tiêu đề IP phá vỡ sự phân chia lợi ích theo khái niệm , ví dụ như . mô hình OSI nhằm mục đích; mặt khác, buộc các giao thức lên cao hơn ngăn xếp để xác định kiểu của chúng một cách nhất quán thì khó hơn nhiều và cuối cùng sẽ dẫn đến một tình huống tương tự (ví dụ: nếu mọi giao thức lên cao hơn ngăn xếp sử dụng byte tiêu đề đầu tiên để nêu loại , nó trông giống như IP sử dụng byte tiêu đề cuối cùng của nó để làm tương tự).
Vì vậy, câu hỏi của tôi là - lý do đằng sau việc đặt trường "giao thức" bên trong tiêu đề gói của IP chứ không phải bất cứ nơi nào khác?
Chỉnh sửa : Khi viết câu hỏi này, tôi đã suy nghĩ có nên thêm từ " nguyên bản " trước khi "lý luận" hay không, tức là lý do của nhóm đã nghĩ ra IP , nhưng cho rằng nó là dư thừa vì câu hỏi đã được đặt ra ở thì quá khứ ("cái gì là câu lý luận ... "). Tuy nhiên, điều này có vẻ cần thiết, vì không có câu trả lời nào thực sự trả lời câu hỏi đó. Một số hiểu biết về lưu ý:
- @immibis đề xuất bất kỳ hình thức nào khác sẽ phá vỡ các mô hình của các giao thức khác (ví dụ: các giao thức truyền thông được mã hóa sẽ phải có trường nhận dạng văn bản gốc)
- @Eddie về cơ bản nói rằng lý do là quy ước (chấp nhận thiết kế chuỗi giao thức , mặc dù tại sao đó là quy ước vẫn còn là một bí ẩn)
- @Ricky nhấn mạnh tính thực tiễn như một sự cân nhắc bao quát
- @Claudio đề xuất rằng trường giao thức là một phần của tiêu đề được đóng gói, cần có một bước xác định tiêu đề bổ sung , trong đó mô hình hiện tại diễn ra trong quá trình phân tích cú pháp của tiêu đề IP
Vì vậy, tôi sẽ viết lại: Có gì sai với một mô hình trong đó thay vì mọi tiêu đề xác định loại tiêu đề tiếp theo, mọi tiêu đề đều xác định loại riêng của nó ở một vị trí được xác định trước (ví dụ: trong byte tiêu đề đầu tiên)? Tại sao một mô hình như vậy bất kỳ ít mong muốn hơn so với mô hình hiện tại?
Chỉnh sửa # 2 : Có vẻ như câu trả lời là sự kết hợp của một số câu trả lời được đưa ra (chủ yếu là những câu được đề cập ở trên cùng với phụ lục thứ hai của @ Eddie):
Tính đơn giản: Phá vỡ nguyên tắc của thuyết bất khả tri trong trường hợp cụ thể này có nghĩa là toàn bộ ngăn xếp (hoặc mô hình) có thể đơn giản hơn:
- Không có giai đoạn "nhận dạng giao thức", không ngầm định hay rõ ràng
- Độc lập lớp được cải thiện (ví dụ: trình xử lý truyền thông được mã hóa không phải chia sẻ một lớp với bất kỳ giao thức trợ giúp nào)
Quy định cũng được đơn giản hóa rất nhiều, không phải thực thi bất kỳ yêu cầu nào trên các giao thức máy khách.
Hiệu suất: Việc nêu rõ giao thức của gói được đóng gói trước gói đó cho phép một số loại giao thức định tuyến nhanh (lọc gói, QOS, chuyển mạch cắt) được tích hợp vào chính lớp mạng (internet); sau đó chúng có thể đưa ra quyết định nhanh chóng như bảng băm có thể được truy cập, điều này quan trọng hơn cả khi xem xét phần cứng giới hạn mà giao thức này được thiết kế để chạy.
Mô hình này có nhược điểm của nó, nhưng dường như đối với các trường hợp sử dụng phổ biến, nó phù hợp hơn các lựa chọn thay thế.
"What's wrong with a model where instead of every header identifying the next header's type, every header identifies its own type in a predetermined location?"Bởi vì sau đó, nó thực sự chỉ là byte cuối cùng của tiêu đề IPv4 (hoặc bất kỳ giao thức cấp thấp hơn) nào ngoài tên. Đó là một vấn đề "gà hoặc trứng". Bạn không thể phân tích tiêu đề nếu bạn không biết giao thức đó là gì.
