За останні
роки протокол керування передачею (TCP) у сполученні з інтернет протоколом
(IP) стали найбільш розповсюдженою формою організації мереж між комп'ютерами.
У зв'язку з розробками високошвидкісних мереж, що ведуться, і додатків які
використовують TCP, проблеми поводження ТСР мають підвищену важливість. Поводженню
(тобто продуктивність, кількість загублених пакетів, стабільність і т.д.)
під час початкової стадії необхідно приділяти окрема увага, тому що більшість
додатків використовують ТСР для коротких передач, що завершуються ще до того
як ТСР перейде до стійкого поводження.
Один з підходів у дослідженні проблем поводження полягає у вивченні роботи
конкретної реалізації TCP. У такий спосіб у даній роботі, за допомогою моделювання,
детально вивчається поводження декількох реалізацій ТСР(Tahoe, Reno, SACK,
Vegas). На основі цих спостережень пропонується кілька простих змін, що при
визначеній ситуації істотно поліпшують поводження протоколу.
Сучасні реалізації TCP
містять безліч алгоритмів, націлених на керування мережним перевантаженням
при підтримці гарної продуктивності користувача. Ранні реалізації TCP випливали
моделі, що використовує сукупне позитивне підтвердження і вимогу витікання
таймера для повторної посилки даних, загублених при транспортуванні. Ці TCP
небагато робили для мінімізації перевантаження в мережі.
Реалізація Tahoe TCP додала безліч нових алгоритмів і удосконалень до більш
ранніх реалізацій. Нові алгоритми включають Повільний старт, Запобігання перевантаження,
і Швидку повторну передачу. Удосконалення включають модифікацію в оцінку часу
кругового звертання для установки значення часу чекання повторної передачі.
Усі модифікації були описані в [Jac88].
До алгоритму Швидкої повторної передачі виявляється особливий інтерес у цій
роботі, тому що він модифікується в наступних версіях TCP. Зі Швидкою повторною
передачею , після одержання маленького числа подвійних підтверджень для одного
пакета TCP (dup ACK), джерело даних укладає, що пакет було загублено і повторно
передає пакет без того, щоб очікувати витікання таймера повторної передачі,
що веде до більш високого використання каналу і продуктивності зв'язку.
Reno TCP зберігає розширення,
включені в Tahoe, але змінює операцію Fast Retransmit додаючи Швидке Відновлення
[Jac90]. Новий алгоритм запобігає шлях зв'язку ("канал") від перебування
в порожньому стані після Швидкої повторної передачі, у такий спосіб іде від
потреби Повільного старту для наповнення каналу після єдиної втрати пакета.
Швидке Відновлення припускає, що кожен отриманий dup ACK представляє один
пакет, що залишив канал. Таким чином, протягом Швидкого Відновлення відправник
TCP здатний робити інтелектуальні оцінки про кількість відправлених даних.
Вхід у Швидке Відновлення відправником TCP відбувається після одержання початкового
порога dup ACK. Цей поріг, звичайно відомий як tcprexmtthresh, звичайно встановлюється
рівним трьом. Як тільки поріг dup ACK отриманий, відправник повторно передає
один пакет і зменшує його вікно перевантаження на половину. Замість Повільного
старту, як у Tahoe TCP, відправник Reno використовує додатковий прихід dup
ACK, щоб синхронізувати наступні пакети, що ідуть.
Алгоритм Reno Швидкого відновлення оптимальний лише при одиничних утратах
пакетів. Відправник Reno передає не більш одного пакета за один час кругового
звертання. Reno значно поліпшує поводження в порівнянні з Tahoe TCP коли відбувається
втрата одного пакета, але може істотно погіршити ситуацію якщо відбулася втрата
декількох пакетів у межах одного вікна. Дана проблема ілюструється при моделюванні.
Алгоритм TCP SACK використовує
поле "Опції" заголовка кадру ТСР для додаткової інформації про отримані
пакети станцією-одержувачем. Якщо відбулася втрата, то кожен сегмент dup ACK
відправляється станцією одержувачем містить інформацію про кадр вызвавшем
посилку даного сегмента. У такий спосіб відправник, одержавши даний кадр має
інформацію не тільки про тім який кадр був загублений, але також і про тім
які кадри успішно досягли одержувача. Завдяки цьому избегается непотрібна
повторна посилка сегментів, успішно буферированных на стороні одержувача.
Як і Reno, TCP SACK входить у режим Швидкого відновлення при одержанні 3 підтверджень,
що дублюються, (dup ACK). Під час Швидкого відновлення відправник підтримує
перемінну pipe, що відображає число пакетів, що знаходяться в мережі. Дана
перемінна збільшується щораз, коли новий сегмент був відправлений і зменшується,
якщо було отримано чергове підтвердження. Передача нового пакета в мережу
дозволена якщо значення pipe менше вікна перевантаження .
Відправник також підтримує структуру даних scoreboard, що запам'ятовує підтвердження
з опції SACK прибуваючих підтверджень. Якщо відправнику дозволена передача,
він передає наступний пакет зі списку пакетів, рахованих загубленими. Якщо
таких пакетів, то посилається новий пакет.
На
підставі особливостей реалізації алгоритмів, представлених вище будується
модель для кожного протоколу. Важливим моментом у побудові моделі є надточне
відображення поводження проколу в реальній мережі для того, щоб результати
отримані експериментальним шляхом можна було переносити в реальну мережу.
На мал.1 представлена моделируемая топологія в мережі, використовувана в даній
роботі.
Мал.1. Топологія моделі
На мал.1. коло представляє
шлюз з кінцевим буфером типу FIFO, а квадрати представляють хост відправника
й одержувача. Використовуваний час кругового звертання встановлено рівним
1 msec. Для простоти всі моделі представлені в даній роботі використовують
одержувача, що посилає АСК на кожен отриманий сегмент. Вузьким місцем у мережі
є шлюз, переповненні буфера якого і представляє перевантаження в мережі.
У ході
моделювання були отримані наступні результати.
· При експонентному збільшенні вікна під час Повільного старту в протоколі
ТСР Tahoe, якщо розмір буфера менше 1/3 добутку ширини смуги на затримку поширення,
то відбувається переповнення буфера, що приводить до другого Повільного старту
і зменшення продуктивності.
· TCP Reno намагається уникнути цього ефекту зменшуючи вікно вдвічі при виявленні
втрати. Хоча це і забезпечує кращу продуктивність при ідеальних умовах, TPC
Reno у своїй нинішній формі занадто уразливий, що б бути заміною Tahoe.
· Використання "грубого" таймера приводить до катастрофічної втрати
продуктивності, якщо таймаут є ідентифікатором утрати пакета. Тому необхідно
використання більш складної обробки оцінки часу кругового звертання.
· Ідеальне поводження при множинній утраті пакетів представляє TCP SACK, однак
використання даної реалізації можливо лише в тих випадках коли обидва кінці
з'єднання (і відправник і одержувач) підтримують дану опцію.
· При відсутності опції SACK можлива ситуація багаторазової швидкої передачі,
що приводить до значного зменшення продуктивності. Щоб уникнути даного ефекту
необхідно додатково використовувати перемінну "send_high", що відбиває
максимальний номер посланого пакета, або, що більш універсально, аналізувати
час відправлення лже- загубленого пакета. Останній варіант більш складний
тому що зв'язаний з точною оцінкою часу кругового звертання.