Як я можу сформулювати затримку зв'язку в TCP / IP?

У мене виникають труднощі при виведенні математичної моделі / рівняння для оцінки затримки зворотного руху між двома вузлами, що спілкуються за допомогою TCP / IP. Вузли обмінюються даними на основі протоколу HTTP. У цій моделі найважливішими факторами для вивчення є фізична відстань між двома вузлами в мережі, кількість проміжних стрибків, пропускна здатність, затримка обробки при кожному стрибку. Я шукав в Інтернеті, але не зміг знайти нічого в цьому сенсі, скоріше знайшов щось про комутацію мереж і протокол UDP. Чи можу я їх налаштувати, щоб вони входили в TCP?

Це дуже складний процес, тому скласти рівняння, яке може бути корисним для точного прогнозування RTT, вкрай складно. У кращому випадку, я б сказав, що ви можете створити модель, яка використовує купу середніх значень для кожного етапу, яку ви можете налаштувати, якщо вам трапляється «краще знати» для певної ситуації, приблизно настільки ж близької, наскільки ви можете її отримати. Це те, що я зараз вивчаю, тому я можу вам сказати, що я знаю дотепер (з нуля, починаючи з фізичного рівня):

• Дивіться мої запитання щодо Electronics SE; Кодування затримки Ethernet і відношення до номінальної частоти кабелю та швидкості електрики (поширення сигналу?) Через мідь для затримки зв'язку . Оскільки ви використовуєте стандартизовану швидкість (100 Мбіт / с, 1 Гбіт / с, 10 Гбіт / с і т.д.), не поводьтеся з волокном або міддю по-різному. "Затримка" внизу - це майже так само чорт, але мідь не може нести сигнал настільки очевидно. У мене є це питання на сайті Physics SE, на яке я зараз знаю відповідь. Мені просто потрібно знайти час, щоб виправити це, тому слідкуйте за тим, якщо вам це цікаво (я опублікую ще кілька питань, пов’язаних із телекомунікаційним використанням волокна, на які я тепер знаю відповідь, коли отримаю можливість ).

• Набагато більше затримок буде додано пристроями в кінці посилання. Не існує стандартного способу сказати: "Ой 2 перемикачі по шляху - це затримка Xms, 4 комутатори - 2 * Xms, 2 маршрутизатори - Yms ... тощо". Припускаючи, що ви використовуєте, наприклад, 1Gpbs, і пристрої, що рухаються вперед, за швидкістю лінії, ми знаємо, що це 1000000000bps, тому фізичний інтерфейс працює з фіксованою швидкістю кодування (в межах від 1 наносекунди на біт до максимальної величини Використовувана схема кодування символів є, наприклад, 10b )

• Існують три основні види затримки (на фізичному рівні), про які потрібно знати, і враховувати це; Затримка серіалізації, затримка кодування, затримка розповсюдження (і затримка обробки, затримка черги, затримка кодування та декодування, але вони знаходяться вище фізичного рівня, але потребують згадування!). Вони досить добре зафіксовані в Інтернеті, VoIP: Поглиблений аналіз , слайд 13 тут , завантаження Google Академії та багато іншого.

• Коли ми рухаємося вгору до стеку протоколів, я працюю над припущенням, що MAC призначення знаходиться у кожній таблиці комутаторів, а на рівні IP - MAC призначення у таблицях ARP. Додаткова затримка, викликана цими процесами відкриття, виникає лише для першого пакету в потоці, тому їх можна обійти шляхом збільшення тайм-аутів та надсилання безплатних ARP тощо.

• Коли ви перейдете до рівня програми, це стане дуже важким, оскільки це залежить від сервера (наприклад) обробки запиту, який може зазнати затримки переривання. Кількість переривань, необхідних для обробки запиту та контекстних комутаторів через навантаження, непередбачувана.

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

У середній час більшість людей прагнуть працювати з фігурою для затримки на фізичному шарі мідь / волокно близько 0,6 * с (С = швидкість світла). Крім того, вам потрібно подумати про обмін TCK ACK кожні X пакети, що відрізняється, наприклад, якщо ви використовуєте SACK, і якщо ви використовуєте рамки jumbo та / або більший розмір MSS (тепер MTU також потрібно враховувати!) , якщо ви надсилаєте більше ACK-файлів між ними (якщо обсяг переданих даних вас цікавить). Вам також потрібно врахувати сумнозвісний продукт із затримкою пропускної здатності і не робити дурних помилок, які я робив на цій сторінці. Я почав робити різні прості (і дуже негарні) калькулятори даних тут. Знову незавершена робота, я спробую їх скоро оновити. Я планую додати калькулятор, подібний до того, що ви намагаєтесь зробити. Я також зробив декілька калькуляторів світла та волокон, якщо вам цікаво, але знову ж таки, немає часу! Я спробую якнайшвидше оновити цю відповідь у найближчі дні.

PS Я забув згадати QoS! Якщо QoS грає в будь-якій точці шляху, це стане дуже важким для обчислення RTT!

(Я хочу зазначити, що інші розмістили чудові відповіді про те, як працюють затримки та ін., І що їх викликає. Але ОП запитала про моделювання; Основна модель проста, і ви просто вкажіть цифри прикладів. Якщо ви хочете знати, чому затримки є такими, якими вони є, то дивіться відповіді всіх інших: ^)

Затримка мережі - це просто час переходу від однієї кінцевої точки до іншої кінцевої точки, що охоплює N переходів між ними .

Отже, у вас N сегментів (хмелів) з проміжними вузлами N-1. Кожен вузол має затримку (сукупний ефект кількох речей на цьому вузлі, наприклад, затримка черги, затримки обробки тощо), і кожен сегмент має затримку транзиту. Загалом це 2N - 1 незалежні змінні. Отже, це seg1 + node1 + seg2 ... + вузол (N-1) + segN Один скачок , просто = seg1, дві надії - seg1 + вузол1 + seg2 і т.д.

Далі ви повинні визначити, що це за всі шматки. Таким чином, ви можете побудувати модельну мережу з мережею CATV, супутниковою ланкою, оптоволоконною ланкою, Ethernet і т. Д. Для кожної з цих технологій потрібно шукати приклад інформації.

Затримка транзиту буде приблизно розміром даних, поділеним на швидкість передачі сегмента. Якщо вам потрібна більш точна модель, ви додали затримку часу польоту - приблизно довжину відрізка, поділену на швидкість потоку даних (приблизна швидкість світла). ЦЕ НЕ має значення, якщо у вас є супутниковий зв’язок; Піднімання до геосинхронного супутника є суттєвим.

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

Якщо ви хочете затримати додаток (наприклад, затримку до початку потоку даних передачі FTP), то ви створюєте підрахунок, скільки разів запускається затримка вашої мережі. Наприклад, тривимірне рукостискання TCP додає трикратну мережеву затримку і т. Д. Надбудовує те, що бачить додаток.

Ви можете оцінити затримку в обидва боки, зробивши захоплення пакетів з будь-якої сторони, а потім виміряйте затримку між запитами, що виходять з контрольованої машини, та відповідями, що повертаються. Наприклад, якщо ви позначите час виходу SYN на віддалену машину, а потім позначив час надходження відповіді SYN + ACK, різниця дасть вам досить хороший показник затримки TCP в обидва кінці.

Майте на увазі, що це буде більше, ніж справжня затримка в мережі, і наскільки більше залежить від того, наскільки сильно завантажена будь-яка машина.

Затримка між двома хостами залежатиме від кількох факторів:

• Затримка розповсюдження
• Затримка серіалізації
• Затримка черги / буферизації

Затримка розповсюдження - це те, скільки часу фізично потрібно, щоб пакети пересувалися між двома місцями. Швидкість світла у волокні становить близько 200000 км / с. У Швеції, де я живу, проходить близько 1570 км, так що це буде 7,85 мс, але насправді це більше, адже це відстань через вигляд птахів.

Затримка серіалізації - це скільки часу потрібно, щоб розділити пакет через фізичний носій, тобто інтерфейси мережевого пристрою. Якщо у вас є 2 Мбіт з'єднання і ви надсилаєте пакет 1500 байт, який би мав 6 мс для серіалізації пакету (12000/2000000).

Затримка черги / буферизації - це скільки часу пакет повинен залишатися в черзі / буфері, перш ніж надсилатись по інтерфейсу. Залежно від швидкості в інтерфейсі та від того, як використовуються великі буфери, це може бути далі, нічого, або значної затримки.

Тоді хости буде певна затримка для хостів, щоб генерувати пакети та програму, яка їх обробляє. Існують програми для вимірювання затримки HTTP. Люди не приймають великих затримок на веб-сайтах, перш ніж відмовлятися від них, тому це є важливим фактором.