Các mảnh TCP bị phân mảnh được giữ trong máy chủ TCP trong bao lâu


10

Giả sử rằng một đoạn TCP đã cho được phân mảnh thành hai datagram IP và datagram đầu tiên đến máy chủ TCP, nhưng datagram thứ hai không bao giờ đến.

Sau một khoảng thời gian nhất định, máy chủ TCP sẽ gửi một bản giữ và xác định rằng máy khách còn sống. Sau đó, máy chủ TCP sẽ làm gì với datagram đầu tiên này? Là chờ đợi datagram thứ hai đến, hay nó loại bỏ datagram đầu tiên?

Câu trả lời:


8

Sau khi hết thời gian sắp xếp lại đoạn, mảnh bị bỏ đi; đầu kia sẽ cần truyền lại.

Thời gian chờ này thường là cấu hình. Trên Linux, mặc định là 30 giây và được điều khiển thông qua /proc/sys/net/ipv4/ipfrag_time.


Là thời gian sắp xếp lại đoạn có liên quan đến đoạn đầu tiên nhận được, hay là thiết lập lại bộ đếm thời gian cho mỗi đoạn mới đến?
Randomblue

2
Tôi nghĩ rằng bạn phải đọc mã nguồn để trả lời dứt khoát.
Michael Hampton

2

Không có câu trả lời dứt khoát cho câu hỏi này;

Nếu bạn thấy này bài viết về retransmition adaptive bạn sẽ thấy TCP sử dụng RTT là một yếu tố trong việc tính toán chậm trễ thích hợp.

Đây là một bài viết chi tiết hơn. Về cơ bản, không có giá trị thời gian chờ đặc biệt chỉ dành cho phân mảnh.

Bài viết này của Cisco mặc dù chỉ ra rằng tường lửa ảo IOS XR có thời gian chờ mặc định là 10 giây cho các đoạn, với bộ hẹn giờ có thể định cấu hình riêng. Tôi đang liên kết điều này để nói rằng các hệ điều hành và thiết bị sẽ hoạt động khác đi và nếu bạn đang truyền một kết nối mặc dù một thiết bị như thế này chẳng hạn, nó có thể gây trở ngại tiêu cực cho kết nối của bạn.

Tốt nhất là kết nối hai máy có cùng cấu hình với nhau và bắt đầu thử nghiệm từ đó nếu bạn muốn kiểm tra ảnh hưởng của độ trễ phân mảnh.


Cảm ơn. Bạn có nghĩ rằng thời gian chờ phân đoạn trong bài viết của Cisco được tính tương ứng với phân đoạn nhận được đầu tiên hoặc phân đoạn nhận được cuối cùng không?
Randomblue

Đoạn nhận được cuối cùng có ý nghĩa hơn phần đầu tiên, nhưng tôi không biết, theo ý của Cisco trong ví dụ đó.
jwbensley
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.