xác nhận bởi TCP không đảm bảo rằng dữ liệu đã được gửi

11

Trong RFC 793 có một phần về sự thừa nhận các phân đoạn TCP:

Khi TCP truyền một phân đoạn chứa dữ liệu, nó sẽ đặt một bản sao vào hàng đợi truyền lại và bắt đầu một bộ đếm thời gian; khi nhận được dữ liệu đó, phân đoạn sẽ bị xóa khỏi hàng đợi. Nếu không nhận được xác nhận trước khi hết giờ, phân đoạn được truyền lại.

Một xác nhận của TCP không đảm bảo rằng dữ liệu đã được gửi đến người dùng cuối , nhưng chỉ có điều rằng TCP nhận đã chịu trách nhiệm thực hiện.

Bây giờ, điều này là thú vị. Trong NOC của chúng tôi, chúng tôi thường khắc phục sự cố kết nối giữa mạng của chúng tôi và mạng máy khách bên ngoài và bất cứ khi nào chúng tôi phát hiện lưu lượng truy cập trên tường lửa và thấy các bit SYN và ACK được gửi và nhận theo cả hai hướng, chúng tôi cho rằng kết nối được thiết lập và sự cố không có gì để làm với mạng.

Nhưng bây giờ RFC này khiến tôi phải suy nghĩ - tôi nên kiểm tra cái gì khác (không thiết lập Wireshark) nếu kết nối TCP được thiết lập nhưng người dùng vẫn gặp sự cố kết nối?

— kamokoba
nguồn

5

Ý nghĩa của câu này chỉ đơn giản là nghĩa tiếng Anh của câu: thực tế là trình điều khiển mạng đã nhận được dữ liệu (và thừa nhận việc tiếp nhận) không đảm bảo rằng người dùng cuối nhận được dữ liệu. Có thể có một lỗi trong máy chủ web, ví dụ. Liên quan đến câu hỏi đóng của bạn: cách duy nhất để biết liệu người dùng cuối có nhận được dữ liệu hay không, là gọi cho họ và hỏi họ.

— Jörg W Mittag

24

Phần này của RFC là về việc chuyển trách nhiệm cho hệ điều hành hoặc bất cứ điều gì là giai đoạn tiếp theo của quy trình. Về cơ bản, nó liên quan đến việc tách các lớp.

Một xác nhận của TCP không đảm bảo rằng dữ liệu đã được gửi đến người dùng cuối, nhưng chỉ có điều rằng TCP nhận đã chịu trách nhiệm thực hiện.

Tôi đã luôn nghĩ về nó theo cách này:

HĐH có thể gặp sự cố giữa việc gửi ACK và dữ liệu đến quá trình máy khách ("máy khách" ở đây có nghĩa là máy khách của HĐH, không phải "máy khách mạng")
Quá trình máy khách có thể bị lỗi hoặc gặp sự cố hoặc chậm hơn nhiều so với dự kiến để xử lý dữ liệu đến hoặc thực sự chỉ đọc nó trong các trường hợp không rõ ràng
Nếu máy khách đang gửi dữ liệu trở đi, có lẽ đến một tệp đĩa, tệp có thể chưa được ghi hoặc xóa
Nếu máy khách đang gửi dữ liệu trở đi bằng TCP, TCP phía xa có thể không truyền dữ liệu, nhận được ACK hoặc quá trình xa đã tiêu thụ thành công dữ liệu

Tất cả những gì nó nói là đây là một xác nhận lớp 3 ("Tôi nghe thấy byte của bạn") không phải là một xác nhận lớp cao hơn . Ví dụ, hãy xem xét sự khác nhau giữa TCP ACK, SMTP 250 OKsau cổng thư tiếp theo chấp nhận một tin nhắn, tin nhắn nhận tin nhắn (ví dụ: theo RFC 3798 ), pixel theo dõi mở tin nhắn, một lời cảm ơn từ PA, và một câu trả lời "Có, tôi sẽ làm điều đó."

Một ví dụ cụ thể khác sẽ là một máy in:

Nó phải ACK dữ liệu sớm trước khi biết phần cuối của nó chứa gì (có thể là tệp Postcript bắt đầu bằng một thư viện đi kèm lớn hơn cửa sổ truyền TCP)
Nó có thể chứa một truy vấn trạng thái ("bạn có giấy không?", Nó rõ ràng có thể thực thi)
Nó có thể chứa lệnh in ("vui lòng in cái này", nhưng nó có thể bị lỗi, nếu hết giấy)

Tôi sẽ đề nghị rằng nếu người dùng đang nhìn thấy và gửi ACK nhưng vẫn gặp sự cố kết nối, thì đó là các đơn đặt hàng có nhiều khả năng xảy ra sự cố tắc nghẽn, HĐH hoặc ứng dụng hơn bất kỳ vấn đề nào liên quan đến mạng nghiêm ngặt.

Để chẩn đoán, tôi khuyên bạn nên tìm kiếm truyền lại, thay vì ACK cụ thể.

— jonathanjo
nguồn

Một mục đạn khác: ngay cả khi quy trình máy khách đang chạy tốt, nó có thể chưa đọc dữ liệu.

— Barmar

1

Quá trình máy khách (nếu cảm thấy lười biếng hoặc đồi trụy) có thể đơn giản là không bao giờ gọi recv()vào ổ cắm, trong trường hợp đó, dữ liệu nhận được sẽ vẫn còn trong bộ đệm nhận của ổ cắm TCP vô thời hạn.

— Jeremy Friesner

Cảm ơn cả hai, cập nhật nó để đề xuất quá trình khách hàng có thể chậm, lỗi, hay thay đổi.

— jonathanjo

Bạn không thể dựa vào ACK để đảm bảo rằng ứng dụng đã xử lý dữ liệu đầu vào của bạn, bạn phải triển khai lớp ứng dụng ACK hoặc Kiểm tra. Để đặt điều này trong bối cảnh khác. Đối với các mạng điều khiển công nghiệp sử dụng TSN có IP Stack ở phía máy khách, TCP ACK không đủ để đảm bảo rằng các biến quy trình đã được chốt. Nghĩa là, bạn không thể dựa vào TCP ACK để đặt hệ thống ở trạng thái an toàn hoặc có thể bảo trì được, bạn phải có sự thừa nhận từ một dịch vụ của lớp ứng dụng rằng an toàn khi đặt tay vào máy.

— crasic

10

Từ góc độ RFC, "người dùng cuối" là ứng dụng. Không có gì đảm bảo rằng ứng dụng có được dữ liệu, chỉ là quá trình TCP đã nhận được nó.

Từ quan điểm NOC của bạn, mạng đang hoạt động và dữ liệu đến máy chủ cuối. Có lẽ, đó là tất cả những gì bạn quan tâm.

— Ron Trunk
nguồn

0

Bạn có thể thấy nó theo cách này.

Bạn là M.Smith và bạn muốn gửi thư cho M.Toto (người là lớp ứng dụng).

Để gửi thư, bạn đến bưu điện địa phương A sẽ gửi thư đến M.Toto bưu điện địa phương B (bưu điện là lớp TCP).

Mọi thứ có thể chạy tốt giữa bạn, bưu điện A và bưu điện B - B sẽ gửi ACK đến bưu điện A. Nhưng không có gì đảm bảo rằng bức thư sẽ đến M.Toto. Bất cứ điều gì có thể xảy ra giữa bưu điện B và M.Toto.

Đó là những gì RFC nói.

— toto
nguồn