Синдром, створюваний передавачем

Протокол передачі TCP може створити синдром "дурного вікна", якщо він обслуговує повільну прикладну програму, яка повільно створює дані, наприклад, 1 байт за час передачі всього вікна. Прикладна програма за цей час записує один байт в буфер передачі TCP. Якщо передавальний TCP не має жодних заданих інструкцій, він може створити сегмент, що містить один байт даних. Результат - передача великого числа 41-байтних сегментів, які проходять через Інтернет. Елементарне рішення – заборонити TCP-передавача передавати дані довжиною 1 байт. Можна алгоритм передавача поставити в режим очікування моменту, коли зберуться дані, щоб послати великий блок. Як довго має TCP чекати? Якщо очікування занадто довге, то це може уповільнити процес. А якщо чекати недостатньо, це може закінчитися посилкою маленького сегмента. Просте рішення у разі, коли передавальний процес повільніше приймаючого, полягає в тому, щоб встановити оптимальну величину сегмента для передачі в лінію. Природно, що така передача може початися, тільки коли накопичений сегмент заданої величини і до цього часу отримано підтвердження прийому попереднього сегмента.

Алгоритм Нагла (Nagle's algorithm)

Алгоритм Нагла простий, але вирішує проблему. Цей алгоритм для передавача TCP

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

Алгоритм Нагла дозволяє враховувати і погоджувати швидкість передачі пакету даних програмою TCP і фактичної швидкістю передачі даних по мережі. Якщо прикладна програма швидше, ніж мережева – створюється більший сегмент (максимальний сегмент). Якщо прикладна програма повільніше, ніж мережева, то створюється сегмент, менший, ніж максимальний. У повільних глобальних мережах, де відповідь йде довго, пакети будуть надсилатися рідше і, отже, в трафіку буде менше службової інформації.

Синдром, створюваний приймачем

TCP приймач може створити синдром "дурного вікна", якщо він обслуговує програму, яка поглинає дані повільно, наприклад, 1 байт за один цикл читання всього буфера. Припустимо, що програма передачі створює дані в блоках 1K, але програма приймача приймає 1 байт за один цикл. Також припустимо, що вхідний буфер TCP прийому дорівнює 4 Кбайта. Передавач посилає 4 Кбайта даних. Приймач зберігає їх у своєму буфері. Тепер його буфер повний. Він перетворює розмір вікна в нуль, що означає, що передавач повинен припинити передачу даних. Додатки приймача читає перший байт даних з вхідного буфера приймача. Тепер ми маємо 1 байт простору у вхідному буфері. TCP приймача оголошує розмір вікна 1 байт, який означає, що передавач TCP, який раніше очікував дозвіл на передачу, сприйме це перетворення вікна як гарну новину і пошле сегмент, що переносить тільки один байт. Процедура триватиме. Один байт даних поглинається, і надсилається сегмент, що переносить один байт даних. Знову ми маємо проблему ефективності.

Щоб запобігти створенню "дурного вікна" прикладною програмою, яка поглинає дані повільніше, ніж вони перебувають, пропонуються два рішення. Перше: надіслати підтвердження відразу, як дані прийняті правильно, але сигнал про зміну розміру вікна посилати по мірі накопичення в буфері простору для прийому сегмента максимального розміру або коли буфер порожній. Друге рішення – затримати передачу підтвердження. Це означає, що коли сегмент прибуває, його не треба підтверджувати негайно. Приймач чекає, поки кількість простору у вхідному буфері стане підходящим, перш ніж підтвердити прибулий сегмент. Затримка підтвердження запобігає передавальний TCP від ​​виникнення ефекту "дурного вікна". Після посилки даних вікно зупиняється. Дані не передаються до отримання підтвердження. Це усуває синдром. Затримана підтвердження також має іншу перевагу: воно зменшує трафік, оскільки приймач не підтверджує кожен сегмент. Однак його недолік в тому, що затримана підтвердження може змусити передавач повторно передати непідтверджений сегмент. Протокол знаходить баланс переваг і недоліків. Він тепер визначає, що підтвердження не повинно бути затримано більш ніж на 500 мс.

Контроль помилок

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

• перекручених сегментів;

• втрати сегментів, порушення порядку проходження сегментів;

• дублювання сегментів.

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

Виявлення і корекція помилок

Виявлення помилок в TCP досягається за допомогою використання трьох простих інструментів: контрольної суми, підтвердження та контролю за часом (time-out). Кожен сегмент включає в себе поле контрольної суми, яке використовується для перевірки перекрученості сегмента. Якщо сегмент спотворений, він видаляється пунктом призначення TCP. TCP застосовує метод підтвердження для отримання відомостей про те, що сегмент досяг пункту призначення неспотвореним. Негативне підтвердження не використовується в TCP. Якщо сегмент не підтверджений, перш ніж закінчиться контрольний час, це вважається ознакою спотворення або втрати і сегмент буде переданий повторно.