підтвердження TCP не гарантує доставку даних

У RFC 793 є частина про підтвердження сегментів TCP:

Коли TCP передає сегмент, що містить дані, він ставить копію в чергу повторної передачі і запускає таймер; коли отримано підтвердження для цих даних, сегмент видаляється з черги. Якщо підтвердження не отримано до закінчення таймера, сегмент повторно передається.

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

Тепер це цікаво. У нашому NOC ми часто вирішуємо проблеми з підключенням між нашою мережею та зовнішньою мережею клієнтів, і кожного разу, коли ми нюхаємо трафік на брандмауері та бачимо, що біти SYN та ACK надсилаються та отримуються в обох напрямках, ми вважаємо, що зв’язок встановлений, і проблема не має нічого робити з мережею.

Але тепер цей RFC змусив мене задуматися - що ще я повинен перевірити (не встановлюючи Wireshark), якщо встановлено з'єднання TCP, але у користувачів все ще виникають проблеми з підключенням?

Ця частина RFC стосується передачі відповідальності перед операційною системою або будь-яким наступним етапом процесу. Це принципово стосується поділу шарів.

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

Я завжди думав про це так:

• ОС може бути збоєм між відправленням ACK і даними, що надходять до клієнтського процесу (тут "клієнт" означає клієнта ОС, а не "мережевого клієнта")
• Клієнтський процес може бути помилковим або збоєм або просто набагато повільніше, ніж передбачалося, щоб вирішити справу з його вхідними даними, або навіть читати їх лише за неочевидних обставин
• Якщо клієнт надсилає дані далі, можливо, на файл диска, файл, можливо, ще не був записаний або пропущений
• Якщо клієнт надсилає дані далі за допомогою TCP, далекобійний TCP, можливо, не передав дані, отримав ACK або далекий процес успішно спожив дані

Все, про що йдеться, - це підтвердження рівня 3 ("Я чую ваші байти"), а не підтвердження вищого рівня . Розглянемо, наприклад, різницю між TCP ACK, SMTP 250 OKпісля того, як шлюз наступного переходу приймає повідомлення, повідомлення про отримання повідомлення (наприклад, за RFC 3798 ), піксель відстеження, відкритий повідомленням, подяку від ПА, і відповідь "Так, я це зроблю".

Іншим конкретним прикладом може бути принтер:

• Він повинен обробляти дані раніше, перш ніж він дізнається, що його кінець містить (може бути файл Postscript, що починається з включеної бібліотеки, більшою за вікно передачі TCP)
• Він може містити запит про стан ("у вас є папір?", Який він, очевидно, може виконувати)
• Він може містити команду друку ("будь-ласка, надрукуйте це", що може бути невдалим, якщо немає паперу)

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

Для діагностики я пропоную шукати повторні повідомлення, а не конкретно АКК.

З точки зору RFC, "кінцевим користувачем" є додаток. Немає гарантії, що програма отримала дані, лише те, що процес TCP отримав їх.

З точки зору NOC, мережа функціонує, а дані дійшли до кінцевого вузла. Імовірно, це все, що вам цікаво.

Ви могли бачити це так.

Ви - M.Smith і хочете надіслати листа до M.Toto (люди - це додаток).

Щоб надіслати лист, ви перейдете до місцевого поштового відділення А, яке надішле лист до місцевого поштового відділення М.Тото (поштові відділення - рівень TCP).

Між вами все може працювати добре, пошта А та поштове відділення B - B відправлять ACK на пошту А. Але нічого не гарантує, що лист надійде до M.Toto. Між поштовим відділенням B та M.Toto може статися щось.

Це в основному те, що говорить RFC.