Kích thước cửa sổ và số ACK

Sao chép từ các slide của giảng viên của tôi:

• Receiver indicates the window size is 3000 
• Transfer goes ahead 
• Acknowledge every 3000 bytes 
• Receiver increases window size to 4000 
• 4000 bytes will be transferred before the next acknowledgement 

Vì vậy, từ đây tôi thu thập được rằng Kích thước cửa sổ biểu thị số lượng byte mà người nhận sẽ thu thập trước khi gửi ACK.

Nhưng đây không phải là những gì tôi thấy trong bản chụp Wireshark này:

Như bạn có thể thấy trong ảnh chụp màn hình (từ truyền tệp TCP), máy chủ đang ACKing mỗi ~ 1400 byte hoặc hơn (nhìn vào số ACK), nhưng đồng thời cho biết kích thước cửa sổ là 100'000 + byte?

Từ những gì tôi hiểu được từ các slide của giảng viên của mình, máy chủ có nên ACKing cứ sau 100.000 byte không? Tại sao anh ấy ACKing thường xuyên hơn thế?

Tôi dạy TCP và tôi thường gặp những người bị dạy sai rằng ACK chỉ được gửi khi đạt đến Kích thước cửa sổ. Đây không phải là sự thật. (Để thực sự minh bạch, tôi cũng đã dạy điều này không chính xác trước khi tôi biết rõ hơn, vì vậy tôi hoàn toàn hiểu sai lầm).

LƯU Ý, tôi sẽ sử dụng Người nhận / Người gửi để mô tả nó, nhưng hãy nhớ rằng TCP là hai chiều và cả hai bên đều duy trì Kích thước cửa sổ.

Kích thước cửa sổ (mà Người nhận đặt) là một giới hạn cứng đối với số lượng byte mà Người gửi có thể gửi mà không bị buộc phải dừng lại để chờ xác nhận.

Kích thước cửa sổ không xác định tần suất người nhận nên gửi xác nhận. Ban đầu, giao thức TCP yêu cầu một xác nhận được gửi sau khi từng phân đoạn được nhận. Sau đó, TCP đã được tối ưu hóa để cho phép Người nhận bỏ qua ACK và gửi ACKnowledribution mỗi gói khác (hoặc hơn).

Sau đó, mục tiêu của TCP là để Người gửi liên tục gửi các gói, không bị chậm trễ hoặc gián đoạn, bởi vì nó liên tục nhận được các xác nhận, sao cho số lượng "byte đang chuyển" luôn nhỏ hơn Kích thước cửa sổ. Nếu bất cứ lúc nào, Người gửi đã gửi một số byte bằng kích thước cửa sổ mà không nhận được ACK, thì buộc phải tạm dừng gửi và chờ.

Điều quan trọng cần xem xét trong tất cả điều này là Thời gian khứ hồi. Thông thường, khi bạn đang nghiên cứu TCP trong một wireshark, bạn chỉ nhìn thấy viễn cảnh của một bên trong cuộc trò chuyện TCP, điều này khiến bạn khó có thể suy ra hoặc thực sự "thấy", hiệu ứng của RTT. Để minh họa hiệu quả của RTT, hãy xem hai ảnh chụp này. Cả hai đều ghi lại cùng một cuộc trò chuyện, tải xuống tệp 2 MB qua HTTP, nhưng một là từ góc độ của Máy khách và cái còn lại là từ góc độ của Máy chủ .

Lưu ý: việc phân tích TCP sẽ dễ dàng hơn nếu bạn tắt tính năng Wireshark " Cho phép người đăng ký lắp ráp lại các luồng TCP "

Lưu ý từ bản chụp phía Máy chủ (ai là người gửi tệp), Máy chủ sẽ gửi 8 gói có kích thước đầy đủ liên tiếp (gói số 6-13) trước khi nhận ACK đầu tiên trong gói số 14. Nếu bạn truy sâu vào ACK đó, lưu ý rằng xác nhận của Khách hàng dành cho phân khúc được gửi trong Gói số 7. Và ACK mà Máy khách đã gửi trong gói 20 là từ phân đoạn được gửi trong Gói số 9.

Xem cách Client thực sự thừa nhận mọi gói khác. Nhưng có vẻ như nó thừa nhận họ "muộn". Nhưng trên thực tế, đây chỉ là hiệu ứng của Thời gian khứ hồi. Người gửi có thể gửi 7 ~ phân đoạn trong thời gian cần thiết để phân khúc đầu tiên đến được máy khách và để ACK của máy khách tiếp cận máy chủ. Nếu bạn nhìn vào bản chụp từ phối cảnh của Máy khách, nó trông rất 'sạch', nghĩa là cứ mỗi gói thứ hai nó nhận được, nó sẽ gửi ra một ACK.

Cũng lưu ý những gì xảy ra ở Gói số 23. Máy chủ đã gửi tất cả những gì có thể, bởi vì "byte trong quá trình" đạt đến Kích thước cửa sổ, do đó buộc phải dừng gửi. Cho đến khi ACK tiếp theo đến. Vì ACK đang đến ở mọi phân khúc khác nhận được. Mỗi ACK cho phép người gửi gửi lại hai phân đoạn mới, trước khi Cửa sổ đầy lại và Máy chủ buộc phải tạm dừng. Điều này xảy ra cho đến khi Gói số 51, khi Máy khách (Người nhận) tăng đáng kể Kích thước cửa sổ, cho phép Máy chủ (người gửi) bắt đầu truyền lại dữ liệu không bị chặn ... ít nhất là cho đến khi Gói # 175, khi Cửa sổ mới lấp đầy.

Kích thước cửa sổ được sử dụng để ngăn chặn tắc nghẽn tại máy thu (trái ngược với cửa sổ tắc nghẽn cố gắng ngăn chặn tắc nghẽn trong mạng).

Chức năng của nó tương đối đơn giản: người nhận thông báo cho người gửi về kích thước cửa sổ của nó, thường đại diện cho kích thước bộ đệm có sẵn. Do đó, nên giảm số lượng này mỗi khi một gói mới đến máy thu và nên tăng lên mỗi khi gói được xử lý tại máy thu.

Về phía người gửi, người gửi cố gắng đảm bảo rằng tại bất kỳ thời điểm nào, anh ta / cô ta không có quá nhiều byte hơn cửa sổ được quảng cáo nhận được lần cuối và do đó làm giảm khả năng làm ngập người nhận.

Bây giờ từ đầu ra wireshark của bạn, chúng ta có thể thấy rằng kích thước cửa sổ của bạn tương đối lớn và do đó việc truyền của bạn không bị điều chỉnh và bạn nhận được ACK cho mỗi gói bạn gửi (vì nó sẽ nằm trong trường hợp chung không sử dụng tổng hợp ACK) . Hiện tại kích thước tối đa được sử dụng nhiều nhất cho các khung ethernet là 1500 byte. Nếu bạn loại bỏ tất cả các tiêu đề, bạn sẽ thấy rằng các byte còn lại thực sự là số lượng ACK của bạn được tăng lên.