NACK проти ACK? Коли використовувати один над іншим?

Особисто я навіть не відчуваю, що є потреба в АСК. Це швидше, якщо ми просто надсилаємо NACK (n) для втрачених пакетів, а не надсилаємо ACK для кожного отриманого пакету. Отже, коли / в яких ситуаціях можна було б використовувати ACK через NACK та viceversa?

Причиною ACK є те, що NACK просто недостатній. Скажімо, я надсилаю вам потік даних X сегментів (скажімо, 10 для простоти).

Ви перебуваєте в поганому з’єднанні і отримуєте лише сегменти 1, 2, 4 і 5. Ваш комп'ютер надсилає NACK для сегмента 3, але не усвідомлює, що має бути сегментів 6-10, і він НЕ NACK.

Отже, я надсилаю сегмент 3, але потім мій комп'ютер помилково вважає, що дані успішно надсилаються.

ACK надають певну впевненість, що сегмент прибув до пункту призначення.

Якщо ви хочете, щоб програма стосувалася порядку впорядкування даних та повторної передачі, ви можете просто скористатися протоколом типу UDP (наприклад, як TFTP).

Все це зводиться до розподілу ймовірності втрат та структури трафіку.

Візьмемо для прикладу типовий бездротовий зв’язок із стійкою втратою 10-30%. Якщо ви підключите кожен отриманий кадр (наприклад, 802.11abg), ви швидко виявите, коли кадр був втрачений, тому ви не втратите часу на очікування тайм-ауту.

Якщо ви були замість цього на NAK, ви станете залежними від схеми трафіку: - Якщо ви надішлете один пакет запитів і очікуєте відповіді, і цей запит буде втрачено, вам доведеться мати час, який закінчиться, якщо ви не отримаєте відповідь. - Якщо ви просто відправляєте потік пакету до переважно відключеного одержувача, то приймати NAK можна лише тоді, коли одержувач отримає наступний пакет або близько того. Але це означає, що одержувач повинен переупорядкувати пакети і що відправник повинен відслідковувати великі відставання повідомлень, які він надіслав.

(здогадайтесь, яке рішення обрано 802.11n? обидва. Одержувач надсилає растрові карти змінної довжини отриманих кадрів)

Тепер візьміть типову мережу Інтернету: у вас близько 0% втрат пакету, поки щось погано не станеться, і ви втратите близько 100% втрати пакетів протягом певного часу, дотримуючись деякого експоненціального закону про розподіл, від перерви в 200 м до хвилини і половина.

Захист кожного пакету буде здаватися безглуздим у не втрачається мережі, поки ви не розглянете випадок, коли посилання розірвано: ви не отримаєте ACK або NACK протягом, можливо, тривалого часу, і одержувач, як правило, нічого не відправить, поки посилання відновлюється.

Якщо ви використовуєте ACK, відправник припинить надсилання та зберігатиме його відставання, поки посилання не відновиться. Якщо ви замість цього використовуєте NACK, одержувач може врешті сказати вам, що він не отримав пакет, який випав із відставання відправника вже давно, і з'єднання по суті не можна відновити.

ACK корисні для протоколів розсувних вікон, вони дозволяють Передавачу А усвідомлювати, що дані, отримані отриманими віддаленим В. Потім передавач A може перейти до надсилання наступних даних, поки його вікно передачі не заповниться (даних, що надсилаються на віддалений, але ще не визнав).

АСК можна вважати важливішими, ніж НАК. NAK просто дозволяють швидше відновити , у випадку, коли пакет / блок, надісланий A, не отриманий B, а B якимось чином виявляє, що пакет / блок відсутній.

Цілком можливо спроектувати протокол, що підтримує надійний контроль передачі та потоку тільки з ACK, без НАК (з повторною передачею Передавачем у випадку, якщо Передавач не отримає ACK, механізм повторної передачі, який потрібен у будь-якому випадку).

Одне найважливіше, що я хотів би додати тут, у TCP, ми НЕ надсилали ACK ЗА ВСІЙ, ЩО ВИДАЛЕНО ПАКЕТ.

Однак АСК надсилаються лише для ОСТАНОГО ВИДАЛЕНОГО ПАКЕТУ.

Будь ласка, виправте мене, якщо я помиляюся.