Các Wikipedia article on TCP chỉ ra rằng các gói IP vận chuyển các phân đoạn TCP đôi khi có thể bị mất và TCP "yêu cầu truyền lại dữ liệu bị mất".Các quy tắc truyền lại cho TCP là gì?
Chính xác quy tắc yêu cầu truyền lại dữ liệu bị mất là gì? Tần suất thời gian là các yêu cầu truyền lại được thực hiện? Có giới hạn trên về số không? Có chức năng nào cho máy khách để chỉ ra cho máy chủ quên toàn bộ phân đoạn TCP mà phần nào bị mất khi gói IP bị mất không?
Chính xác quy tắc yêu cầu truyền lại dữ liệu bị mất là gì?
Người nhận không yêu cầu truyền lại. Người gửi đợi ACK cho phạm vi byte được gửi tới máy khách và khi không nhận được, gửi lại các gói tin, sau một khoảng thời gian cụ thể. Đây là ARQ (Tự động lặp lại yêu cầu). Có một số cách để thực hiện điều này.
Stop-and-wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ
được nêu chi tiết trong RFC 3366.
Tần suất thời gian là các yêu cầu truyền lại được thực hiện?
Thời gian truyền lại và số lần thử không được thực thi theo tiêu chuẩn. Nó được thực hiện khác nhau bởi các hệ điều hành khác nhau, nhưng phương pháp luận là cố định. (Một trong những cách để hệ điều hành vân tay có lẽ?)
Thời gian chờ được đo theo thời gian RTT (Thời gian chuyến đi khứ hồi). Nhưng điều này là không cần thiết rất thường xuyên do Fast-retransmit mà đá trong khi 3 trùng lặp ACKs được nhận.
Có giới hạn trên về số không?
Có. Sau một số lần thử lại nhất định, máy chủ được coi là "xuống" và người gửi từ bỏ và rớt xuống kết nối TCP.
Có chức năng nào cho khách hàng chỉ ra cho máy chủ quên toàn bộ phân đoạn TCP mà phần bị mất khi gói IP bị mất không?
Toàn bộ điểm là giao tiếp đáng tin cậy. Nếu bạn muốn khách hàng quên đi một số phần, bạn sẽ không sử dụng TCP ngay từ đầu. (UDP có lẽ?)
Không có thời gian cố định để truyền lại. Triển khai đơn giản ước tính RTT (khứ hồi-thời gian) và nếu không có ACK để gửi dữ liệu đã nhận được trong 2x thời gian đó sau đó họ gửi lại.
Sau đó, họ tăng gấp đôi thời gian chờ và gửi lại lần nữa nếu một lần nữa không có trả lời. Rửa sạch. Nói lại.
Các hệ thống phức tạp hơn sẽ đưa ra ước tính tốt hơn về thời gian cần thực hiện cho ACK cũng như dự đoán chính xác dữ liệu nào đã bị mất.
Điểm mấu chốt là không có quy tắc cứng và nhanh về chính xác thời điểm truyền lại. Đó là vào việc thực hiện.Tất cả truyền lại chỉ được kích hoạt bởi người gửi dựa trên việc thiếu phản hồi từ người nhận.
TCP không bao giờ bỏ dữ liệu để không, không có cách nào để cho biết máy chủ nên quên một số phân khúc.
"đoán chính xác dữ liệu nào đã bị mất" SACK (xác nhận chọn lọc) không đoán. Tôi hy vọng bạn không có nghĩa là SACK. –
Người nhận có thể tái ACK dữ liệu trước đó khi một phân đoạn không theo thứ tự đã được nhận. Điều này gợi ý cho người gửi rằng một số nhưng không phải tất cả các gói đang chờ xử lý đều bị mất và do đó người gửi có thể chọn chỉ truyền lại một tập con của cửa sổ gửi đi (và do đó dẫn đến gói mạng nhỏ hơn và sử dụng băng thông ít hơn) thay vì gửi gói lớn hơn bao gồm dữ liệu được gửi trước đó trong gói sau (điều này sẽ giảm độ trễ và số lượng gói được gửi trong trường hợp mất nhiều lần). Không có sự chắc chắn, vì vậy chúng ta hãy gọi nó là một "dự đoán có học thức". –
xem SACK. Nó là một tiêu đề bổ sung cho người gửi biết chính xác những gì người nhận có. Tôi tin rằng gần như tất cả các ngăn xếp TCP hiện đại thực hiện SACK ngày nay –
thường là thời gian truyền lại = thời gian chuyến đi khứ hồi * một số hằng số và độ trễ cố định (điều này khá bi quan) đối với gói 'syn'. –