Повторна передача TCP означає повторне надсилання через мережу пакетів, які були втрачені або пошкоджені. Тут повторна передача - це механізм, який використовується такими протоколами, як TCP забезпечити надійний зв'язок. Тут надійний зв’язок означає, що протокол гарантує доставку пакету, навіть якщо пакет даних було втрачено або пошкоджено.
конвертувати рядок у char java
Мережі ненадійні та не гарантують затримку або повторну передачу втрачених або пошкоджених пакетів. Мережа, яка використовує комбінацію підтвердження та повторної передачі пошкоджених або втрачених пакетів, забезпечує надійність.
Механізм ретрансляції
Тут повторна передача означає, що пакети даних були втрачені, що призводить до відсутності підтвердження. Ця відсутність підтвердження запускає таймер тайм-ауту, що призводить до повторної передачі пакетів даних. Тут таймер означає, що якщо підтвердження не отримано до закінчення таймера, пакет даних передається повторно.
Розглянемо наступні сценарії ретрансляції.
Сценарій 1: коли пакет даних втрачено або помилковий.
У цьому сценарії пакет надсилається одержувачу, але підтвердження не отримано протягом цього періоду очікування. Після закінчення періоду очікування пакет надсилається повторно. Під час повторної передачі пакета отримується підтвердження. Після отримання підтвердження повторна передача не відбудеться знову.
Сценарій 2: коли пакет отримано, але підтвердження втрачено.
У цьому випадку пакет отримано на іншій стороні, але підтвердження втрачено, тобто ACK не отримано на стороні відправника. Після закінчення періоду очікування пакет надсилається повторно. З іншого боку є дві копії пакетів; Хоча пакет отримано правильно, підтвердження не отримано, тому відправник повторно передає пакет. У цьому випадку повторної передачі можна було б уникнути, але через втрату ACK пакет передається повторно.
Сценарій 3: коли настає ранній тайм-аут.
У цьому випадку пакет надсилається, але через затримку підтвердження або тайм-аут стався до фактичного тайм-ауту, пакет передається повторно. У цьому випадку пакет було надіслано знову без потреби через затримку підтвердження або час очікування було встановлено раніше, ніж фактичний час очікування.
У наведених вище сценаріях не можна уникнути першого сценарію, але можна уникнути двох інших сценаріїв. Давайте подивимося, як ми можемо уникнути таких ситуацій.
Скільки часу має чекати відправник?
Відправник встановлює період очікування для ACK. Час очікування може бути двох типів:
Щоб подолати дві вищевказані ситуації, TCP встановлює тайм-аут як функцію RTT (час проходження в обидві сторони), де час у зворотному напрямку – це час, необхідний для того, щоб пакет пройшов від джерела до пункту призначення, а потім повернувся знову.
Як ми можемо отримати RTT?
RTT може змінюватися залежно від характеристик мережі, тобто якщо мережа перевантажена, це означає, що RTT дуже високий. Ми можемо оцінити RTT, просто спостерігаючи за ACK.
Давайте подивимося, як ми можемо виміряти RTT.
Ми будемо використовувати оригінальний алгоритм для вимірювання RTT.
Крок 1: Спочатку вимірюємо SampleRTT для кожного сегмента або пари ACK. Коли відправник надсилає пакет, ми знаємо таймер, за яким пакет надсилається, а також ми знаємо таймер, за який отримано підтвердження. Обчисліть час між цими двома, і це стане SampleRTT .
Крок 2: Ми не будемо брати лише одну пробу. Ми будемо продовжувати відбирати різні зразки та обчислювати середньозважене значення цих зразків, і це стане EstRTT (Оціночне RTT).
дорівнює рядку в java
де α+ β = 1
α лежить між 0,8 і 0,9
β лежить між 0,1 і 0,2
римські цифри 1-100
крок 3: Час очікування встановлюється на основі EstRTT.
час очікування = 2 * EstRTT.
Тайм-аут встановлено вдвічі більше, ніж очікуване RTT. Таким чином обчислюється фактичний коефіцієнт очікування.
Недолік цього підходу
В оригінальному алгоритмі є недолік. Розглянемо два сценарії.
Сценарій 1.
Наведена вище діаграма показує, що відправник надсилає дані, які називаються оригінальною передачею. Протягом періоду очікування підтвердження не отримано. Отже, відправник повторно передає дані. Після повторної передачі даних отримується підтвердження. Припустімо, що підтвердження отримано для початкової передачі, а не для повторної передачі. Оскільки ми отримали підтвердження оригінальної передачі, отже SampleRTT розраховується між часом початкової передачі та часом отримання підтвердження. Але насправді, SampleRTT мало бути між часом повторної передачі та часом підтвердження.
Сценарій 2.
Наведена вище діаграма показує, що відправник надсилає оригінальний пакет даних, для якого ми також отримуємо підтвердження. Але підтвердження отримано після повторної передачі даних. Якщо припустити, що підтвердження відноситься до повторної передачі, то SampleRTT розраховується між часом повторної передачі та часом підтвердження.
У наведених вище обох сценаріях існує неоднозначність невідомості, чи є підтвердження для оригінальної передачі чи для повторної передачі.
Висновок за наведеним алгоритмом.
java довгий до рядка
- Тут ACK не означає підтвердження передачі, але насправді він підтверджує отримання даних.
- Якщо розглядати перший сценарій, повторна передача виконується для втраченого пакета. У цьому випадку ми припускаємо, що ACK належить до вихідної передачі, через що SampleRTT виходить дуже великим.
- Якщо ми розглянемо другий сценарій, надсилаються два однакові пакети, тому в цьому випадку відбувається дублювання. У цьому випадку ми припускаємо, що ACK належить до повторної передачі, через що SampleRTT стає дуже малим.
Щоб подолати вищевказані проблеми, пропонується просте рішення за допомогою алгоритму Карна/Партріджа. Цей алгоритм дав просте рішення, яке збирає вибірки, надіслані одночасно, і не враховує вибірки під час повторної передачі для обчислення розрахункового RTT.
Алгоритм Карна/Партріджа
У наведених вище двох сценаріях відбувається повторна передача, і ми розглянули приклад RTT. Але цей алгоритм не враховує Зразок RTT під час повторної передачі. Оскільки відбулася повторна передача, це означає, що щось відбувається протягом цього часу зворотного зв’язку або може виникнути перевантаження в мережі. Щоб подолати цю проблему, цей алгоритм подвоює час очікування після кожної повторної передачі. Цей алгоритм реалізовано в мережі TCP.
Обмеження
Він не враховує дисперсію в RTT.
Щоб подолати вищезазначене обмеження, був розроблений алгоритм Якобсона/Карелса, який вводить коефіцієнт дисперсії в RTT.
Алгоритм Якобсона/Карелса
Цей алгоритм було розроблено, щоб подолати обмеження Karn/Partridge алгоритм. Він обчислює різницю між SampleRTT і EstimatedRTT і підвищує RTT на основі різниці.
Розрахунки для середнього RTT
- Спочатку обчислюємо коефіцієнт різниці.
Diff = SampleRTT – EstimatedRTT
- Тепер ми обчислюємо EstimatedRTT, який буде обчислюватися так само, як ми робили вище.
EstRTT = EstRTT + (δ*Diff)
- Тепер обчислюємо середнє значення коефіцієнта різниці.
Dev = Dev + δ ( |Diff| - Dev)
Тут Dev – коефіцієнт відхилення, а δ – коефіцієнт між 0 і 1 Dev є оцінкою дисперсії від EstRTT .
- Під час розрахунку значення тайм-ауту ми будемо враховувати дисперсію.
Де, µ =1 і ɸ =4
Швидка ретрансляція
Стратегія повторної передачі на основі часу очікування неефективна. TCP — це протокол із ковзним вікном, тому щоразу, коли відбувається повторна передача, він починає надсилати його з втраченого пакета.
Припустимо, я передаю пакети 0, 1, 2 і 3. Оскільки пакет 0 і пакет 1 отримані на іншій стороні, пакет 2 втрачається в мережі. Я отримав підтвердження пакета 0 і пакета 1, тому я надсилаю ще два пакети, тобто пакет 4 і пакет 5. Коли надсилаються пакети 3, 4 і 5, я отримаю підтвердження пакета 1 як підтвердження TCP є кумулятивними, тому він визнає пакет, який він отримав у порядку. Я не отримав підтвердження пакетів 2, 3, 4 і 5 протягом періоду очікування, тому я повторно передаю пакети 2, 3, 4 і 5. Оскільки пакет 2 втрачено, але інші пакети, тобто 3, 4 ,5 отримані на іншій стороні, вони все ще повторно передаються через цей механізм тайм-ауту.
Як можна усунути цю неефективність тайм-ауту?
Краще рішення під розсувне вікно:
Припустимо, що n пакетів було втрачено, але пакети n+1, n+2 і так далі були отримані. Одержувач безперервно отримує пакети та надсилає пакети ACK, повідомляючи, що одержувач все ще очікує на n-й пакет. Одержувач надсилає повторювані або повторювані підтвердження. У наведеному вище випадку ACK пакета 1 надсилається тричі, оскільки пакет 2 було втрачено. Цей повторюваний пакет ACK є ознакою того, що n-й пакет відсутній, але пізніші пакети отримані.
Вищевказану ситуацію можна вирішити наступними способами:
кнопка для центрування css
- Відправник може прийняти «дублікати ACK» як ранню підказку про те, що n-й пакет було втрачено, щоб відправник міг виконати повторну передачу якомога раніше, тобто відправник не повинен чекати, доки настане час очікування.
- Відправник може реалізувати стратегію швидкої передачі в TCP. У стратегії швидкої передачі відправник повинен розглядати три дублікати ACK як тригер і повторно передати його.
TCP використовує три дублікати ACK як тригер, а потім виконує повторну передачу. У наведеному вище випадку, коли отримано три ACK пакета 1, відправник повинен надіслати втрачений пакет, тобто пакет 2, не чекаючи закінчення періоду очікування.