NACK so với ACK? Khi nào nên sử dụng cái này hơn cái kia?

Cá nhân tôi thậm chí không cảm thấy rằng cần phải có ACK. Sẽ nhanh hơn nếu chúng ta chỉ gửi NACK (n) cho các gói bị mất thay vì gửi ACK cho mỗi gói nhận được. Vậy khi nào / tình huống nào người ta sẽ sử dụng ACK trên NACK và viceversa?

Lý do cho ACK là NACK đơn giản là không đủ. Giả sử tôi gửi cho bạn một luồng dữ liệu gồm các phân đoạn X (giả sử 10 để đơn giản).

Bạn đang kết nối kém và chỉ nhận được các phân đoạn 1, 2, 4 và 5. Máy tính của bạn gửi NACK cho phân khúc 3, nhưng không nhận ra rằng nên có các phân đoạn 6-10 và không NACK những phân đoạn đó.

Vì vậy, tôi gửi lại phân khúc 3, nhưng sau đó máy tính của tôi tin rằng dữ liệu được gửi thành công.

ACK cung cấp một số đảm bảo rằng phân khúc đã đến đích.

Nếu bạn muốn ứng dụng xử lý thứ tự dữ liệu và truyền lại, bạn chỉ cần chọn sử dụng một giao thức như UDP (ví dụ như TFTP).

Tất cả sôi sục xuống phân phối xác suất mất mát và mô hình lưu lượng.

Lấy ví dụ một liên kết không dây điển hình, với tỷ lệ mất 10-30% ổn định. Nếu bạn ack từng khung hình nhận được (như 802.11abg), bạn sẽ nhanh chóng phát hiện khi khung hình bị mất, do đó bạn sẽ không mất thời gian để chờ thời gian chờ.

Thay vào đó, nếu bạn đã đến NAK, bạn sẽ trở nên phụ thuộc vào mẫu lưu lượng truy cập: - Nếu bạn gửi một gói yêu cầu duy nhất và mong đợi câu trả lời, và yêu cầu đó bị mất, bạn sẽ phải hết thời gian nếu bạn không nhận được câu trả lời. - Nếu bạn chỉ gửi một luồng gói đến một người nhận chủ yếu là người câm, thì chỉ nhận được một NAK khi người nhận nhận được gói tiếp theo. Nhưng điều này có nghĩa là người nhận phải sắp xếp lại các gói và người gửi phải theo dõi một lượng lớn các tin nhắn mà nó đã gửi.

(đoán xem 802.11n chọn giải pháp nào? cả hai. Người nhận sẽ gửi một bitmap có độ dài thay đổi của các khung mà nó đã nhận được)

Bây giờ hãy sử dụng một mạng Internet thông thường: Bạn bị mất gần 0% gói, cho đến khi có điều gì đó xấu xảy ra và bạn bị mất gần 100% gói trong một thời gian nhất định theo luật phân phối theo cấp số nhân, từ gián đoạn 200ms đến một phút và một một nửa.

Acking mỗi gói dường như vô nghĩa trong một mạng không bị mất, cho đến khi bạn xem xét trường hợp khi liên kết bị cắt đứt: bạn sẽ không nhận được ACK hoặc NACK trong một khoảng thời gian có thể kéo dài và người nhận thường sẽ không gửi bất cứ điều gì cho đến khi liên kết được phục hồi.

Nếu bạn sử dụng ACK, người gửi sẽ ngừng gửi và giữ lại hồ sơ tồn đọng cho đến khi liên kết được khôi phục. Nếu bạn sử dụng NACK thay vào đó, thì cuối cùng người nhận có thể cho bạn biết rằng nó đã không nhận được gói tin bị tồn đọng trong thời gian dài của người gửi và kết nối về cơ bản không thể phục hồi được.

ACK rất hữu ích trong các giao thức cửa sổ trượt, chúng cho phép Máy phát A nhận biết rằng dữ liệu đã gửi được nhận từ xa B. Máy phát A sau đó có thể tiến hành gửi dữ liệu tiếp theo - cho đến khi cửa sổ truyền của nó đầy (chưa gửi dữ liệu đến từ xa thừa nhận).

ACK có thể được coi là thiết yếu hơn NAK. NAK chỉ đơn giản là cho phép phục hồi nhanh hơn , trong trường hợp gói / khối gửi bởi A không được nhận bởi B và B phát hiện bằng cách nào đó gói / khối bị thiếu.

Hoàn toàn khả thi khi thiết kế một giao thức hỗ trợ điều khiển luồng và điều khiển luồng đáng tin cậy chỉ với ACK, không có NAK (với việc truyền lại bởi Máy phát trong trường hợp Máy phát không nhận được ACK, cơ chế truyền lại cần thiết trong mọi trường hợp).

Một điều quan trọng nhất tôi muốn thêm vào đây, trong TCP, chúng tôi KHÔNG gửi ACK cho MỌI GÓI NHẬN ĐƯỢC.

Tuy nhiên, ACK chỉ được gửi cho GÓI NHẬN ĐƯỢC MỚI NHẤT.

Xin hãy sửa tôi nếu tôi sai.