Tại sao một Ổ cắm TCP được xác định bởi 4 tuple?

Newbie để kết nối mạng ở đây. Tôi đang đọc cuốn sách Mạng máy tính (ấn bản thứ 3) và trong phần 3.2 họ đang thảo luận về ghép kênh / tách kênh cho cả UDP và TCP.

Trong giao thức UDP, một ổ cắm được xác định duy nhất bởi IP nguồn và cổng nguồn.

Trong giao thức TCP, ổ cắm được xác định duy nhất bởi IP nguồn, cổng nguồn, IP đích và cổng đích. Tại sao giao thức TCP yêu cầu hai mẩu thông tin bổ sung cho máy chủ nhận để phân tách chính xác phân đoạn và gửi nó đến đúng quy trình?

Lý do duy nhất tôi có thể nghĩ tại sao điều này lại cần thiết là nếu các máy khách luôn gửi phân đoạn TCP đến cùng một cổng với phân đoạn yêu cầu kết nối. Ví dụ: trình duyệt của tôi luôn gửi dữ liệu đến cổng 80 của máy chủ mặc dù máy chủ đã thiết lập một ổ cắm TCP dành riêng cho phiên đó trên một cổng khác. Trong trường hợp đó, TCP phải sử dụng IP nguồn và thông tin cổng nguồn để demultiplex đến đúng ổ cắm. Nó không thể chỉ dựa vào thông tin IP nguồn, bởi vì một máy chủ duy nhất có thể thiết lập nhiều phiên, nhưng mỗi phiên phải ở một cổng khác nhau.

Lý do tại sao UDP không gặp phải vấn đề này là do tổ hợp IP / cổng đích xác định ổ cắm mà quá trình sẽ xử lý yêu cầu được đính kèm, vì trong UDP không có "sinh sản" của nhiều ổ cắm mới cho các yêu cầu.

Điều này có đúng hay tôi đã đi đến kết luận sai?

Thật không may, mọi thứ trở nên khó hiểu bởi vì có hai định nghĩa khác nhau về ổ cắm ngoài kia. TCP rfc sử dụng thuật ngữ socket để chỉ sự kết hợp của địa chỉ và cổng, nhưng các socket của berkerly và các dẫn xuất của nó (API được sử dụng bởi hầu hết mọi triển khai thực tế của IP được sử dụng ngày nay) sử dụng socket socket để chỉ một loại hoạt động hệ thống đối tượng truyền thông.

Tại sao giao thức TCP yêu cầu hai mẩu thông tin bổ sung cho máy chủ nhận để phân tách chính xác phân đoạn và gửi nó đến đúng quy trình?

Đó không chỉ là vấn đề của quy trình chính xác mà là đối tượng truyền thông chính xác.

Lý do duy nhất tôi có thể nghĩ tại sao điều này lại cần thiết là nếu các máy khách luôn gửi phân đoạn TCP đến cùng một cổng với phân đoạn yêu cầu kết nối. Ví dụ: trình duyệt của tôi luôn gửi dữ liệu đến cổng 80

Họ làm.

mặc dù máy chủ đã thiết lập một ổ cắm TCP dành riêng cho phiên đó trên một cổng khác.

Đây dường như là một quan niệm sai lầm phổ biến, có thể gây ra bởi các định nghĩa khác nhau của ổ cắm. Việc chấp nhận kết nối sẽ tạo ra một đối tượng truyền thông mới (ổ cắm theo nghĩa của ổ cắm Berkerly) nhưng không cấp phát kết hợp ip / cổng mới (ổ cắm theo nghĩa của thuật ngữ TCP RFC) trên máy chủ.

Lý do tại sao UDP không gặp phải vấn đề này là do tổ hợp IP / cổng đích xác định ổ cắm mà quá trình sẽ xử lý yêu cầu được đính kèm, vì trong UDP không có "sinh sản" của nhiều ổ cắm mới cho các yêu cầu.

Đúng (giả sử đoạn văn của bạn đang sử dụng "socket" theo nghĩa ổ cắm berkerly).

Trong giao thức UDP, một ổ cắm được xác định duy nhất bởi IP nguồn và cổng nguồn.

Trong giao thức TCP, ổ cắm được xác định duy nhất bởi IP nguồn, cổng nguồn, IP đích và cổng đích. Tại sao giao thức TCP yêu cầu thêm hai phần thông tin

NB cho thuật ngữ TCP, socket là cặp cổng địa chỉ; một cặp ổ cắm xác định kết nối . (Mỗi RFC 793 p5)

Tôi e rằng bạn đã nhầm về UDP, mặc dù nó không thực sự có "socket" - ngay cả khi thư viện Berkeley Sockets gọi chúng như vậy, và đó là một điều hợp lý để gọi một cặp cổng địa chỉ - ghép kênh về cơ bản là cách giống hệt với TCP.

Một tình huống điển hình mà bạn có thể thấy đây là trường hợp đồng thời nhiều độ phân giải DNS từ một máy chủ đến cùng một máy chủ DNS, trong đó rõ ràng chỉ có số cổng nguồn nhất thiết phải khác nhau. Bạn có thể thấy điều này hoàn toàn giống với nhiều kết nối TCP đồng thời từ một máy khách đến một máy chủ web.

UDP có datagram không kết nối. Máy chủ A gửi datagram ra khỏi cặp cổng địa chỉ, hướng vào cặp cổng địa chỉ tại B, thông thường, nhưng không phải lúc nào cũng trả lời theo cách phản chiếu. Nói một cách lỏng lẻo hơn về "giao tiếp", nó hoạt động chính xác hơn 4 tuple giống như kết nối TCP.

Đôi khi bạn sẽ thấy tham chiếu đến 5 tuple (Procotol, địa chỉ nguồn, cổng nguồn, địa chỉ đích, cổng đích), trong đó giao thức sẽ là 17 cho UDP, 6 cho TCP, v.v ... Đây là thứ mà hầu hết các tường lửa, bộ định tuyến, v.v. NAT và các hoạt động tương tự để xác định cặp giao tiếp này.

mặc dù máy chủ đã thiết lập một ổ cắm TCP dành riêng cho phiên đó trên một cổng khác

Tôi e rằng bạn cũng nhầm về TCP, có thể là do sự mâu thuẫn giữa thuật ngữ giữa định nghĩa của giao thức TCP (RFC 793) và triển khai thực tế phổ biến nhất của nó, Thư viện Sockets Berkeley, như được sử dụng trong Unix và mọi thứ bắt nguồn từ nó

Nếu bạn tập trung vào giao thức thì rõ ràng hơn nhiều: không có "cổng khác". Máy chủ web chỉ lắng nghe, ví dụ, 1.1.1.1 cổng 80. Máy khách chỉ gửi từ, để minh họa cho cổng 2.2.2.2 56789. Mỗi gói sẽ là 1.1.1.1:80 đến 2.2.2.2 giáp6789 hoặc ngược lại ; dễ dàng xác minh bằng cách xem các gói với tcpdump / wireshark / vv.

(Để giải thích ngắn gọn về việc triển khai Berkeley, một kết nối TCP được biểu thị bằng một số nguyên thông thường nhưng được gọi sockfdmột cách khó hiểu ; một ổ cắm TCP được đại diện bởi một struct sockaddr. accept()Hệ thống gọi rất khó hiểu về việc tạo ra một "ổ cắm được kết nối mới", theo nghĩa của nó kết nối mớicấu trúc ở trạng thái kết nối. Bộ dữ liệu của kết quả này sẽ nằm trong ví dụ của chúng tôi (1.1.1.1, 80, 2.2.2.2, 56789). Về UDP, thư viện cho phép bạn coi UDP là được kết nối, đây là cách thuận tiện nếu mô tả hoàn toàn trao đổi datagram UDP giữa hai quy trình và chỉ có nghĩa là cấu trúc ghi nhớ cặp cổng địa chỉ xa, theo thuật ngữ lập trình tạo ra UDP "kết nối" trông giống như một TCP. Hãy nhớ rằng thư viện Berkeley không chỉ dành cho IP và có sự khái quát hóa của một số hệ thống mạng cơ bản khác nhau. Nếu bạn muốn theo dõi các thuật ngữ lập trình mạng này, tôi đề xuất Stack Overflow, nơi có nhiều lập trình viên mạng rất có thẩm quyền.)

Trong giao thức UDP, một ổ cắm được xác định duy nhất bởi IP nguồn và cổng nguồn.

Vui lòng không trộn chương trình mạng (ổ cắm) với các giao thức mạng.

Tuy nhiên, trong trường hợp UDP, bạn cũng có 4-tuple này!

Sự khác biệt giữa TCP và UDP là UDP không sử dụng các kết nối cố định nên có thể sử dụng một ổ cắm để gửi dữ liệu đến các máy tính khác nhau và / hoặc các cổng đích khác nhau.

Vì lý do này, HĐH chỉ lưu 2 phần tử của 4 phần (địa chỉ IP và số cổng của cổng cục bộ) trong khi 2 phần tử khác (địa chỉ IP và số cổng của máy tính khác) phải được cung cấp bởi ứng dụng (trong các sendto()chức năng).

Mặt khác, TCP được định hướng kết nối và ổ cắm mô tả kết nối giữa hai máy tính. Do đó, một ổ cắm chỉ có thể được sử dụng để gửi dữ liệu đến một cổng TCP nhất định của một máy tính nhất định (sử dụng send()chức năng).

Điều này có nghĩa là tất cả 4 yếu tố (và không chỉ 2 trong số chúng) của 4-tuple được cố định cho ổ cắm để HĐH có thể lưu trữ cả 4 yếu tố và ứng dụng không phải cung cấp 2 trong 4 yếu tố.

Nếu cuốn sách bạn đang đọc là "Mạng máy tính - Cách tiếp cận từ trên xuống" của Jim Kurose, thì bạn và tôi đang đọc cùng một cuốn sách. :-) FYI, cuốn sách thực sự nêu hai bộ dữ liệu xác định ổ cắm UDP dựa trên IP và cổng đích (không phải nguồn). Ít nhất, đó là những gì phiên bản thứ 7 tuyên bố.

Để trả lời câu hỏi của bạn, TCP là hướng kết nối, trong khi UDP không có kết nối. Do đó, khi yêu cầu TCP được thiết lập giữa máy chủ và máy chủ, mỗi bên của kết nối đó sẽ muốn chắc chắn rằng các yêu cầu tiếp theo sẽ sử dụng cùng một kết nối (nếu không, điểm sử dụng giao thức hướng kết nối như TCP là gì?). Và vì hai phân đoạn dữ liệu có cùng IP và cổng đích nhưng các IP và cổng nguồn khác nhau sẽ sử dụng hai ổ cắm riêng biệt ở phía máy chủ, cách duy nhất để đảm bảo rằng các yêu cầu tiếp theo sử dụng cùng một ổ cắm như yêu cầu ban đầu là sử dụng cả hai nguồn. và IP / cổng đích khi khớp các phân đoạn dữ liệu với ổ cắm chính xác của chúng.

Ngược lại, bạn có thể nghĩ về UDP như thiết lập một kết nối mới (và do đó là một ổ cắm mới) với mỗi yêu cầu riêng biệt. Vì bạn không phải lo lắng về việc sử dụng cùng một ổ cắm như các yêu cầu trước đó, nên không cần bao gồm IP / cổng nguồn khi xác định ổ cắm UDP nào để định tuyến phân khúc đến. Do đó, một tuple là đủ.