Що представляє затримка, що викликає локальний хост?

Я грався з пінгом, бачачи, якщо мій пінг був швидше, ніж мій екран оновлення (це, іноді), і я вирішив пінг localhost.

Я запускаю веб-сервер apache, який дає помилку 403 на localhost. Коли я пінг це, я отримую затримку 0,058 мс. Іноді це досягає 0,10 2мс

Що таке затримка представляє - surley мій комп'ютер до мого комп'ютера повинен бути миттєвим, і чому існує така зміна - від 0,027 до 0,102 є майже 400% варіації.

— Tim
джерело

Якщо apache не налаштовано на відповідь на localhost, то яка проблема виникає, але що буквально затримка 0 мс? Питання повинні бути практичними питаннями, про проблеми, з якими ви насправді зіткнулися, я не зовсім зрозуміла, яку проблему ви намагаєтеся вирішити.

— Ramhound

@Ramhound налаштований на реагування - але він має 3 віртуальних сервера, а перелік каталогів вимкнено. Тому localhost щось робить.

— Tim

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

— Ramhound

@Ramhound моя відповідь не була 0, вона була 0.1. Я запитую, чому це не 0

— Tim

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

— Ramhound

Відповіді:

напевно, мій комп'ютер до мого комп'ютера повинен бути миттєво

0,102 мс те ж саме, що 0,102х10 ^ (- 3) секунди або 0,000102 секунди. Він не отримує набагато більше "миттєвого", ніж це.

Протягом цієї десятої тисячної частки секунди ваша система повинна:

читати ехо-запит ICMP з rxqueue ^* пристрою зворотного зв'язку
побудувати відповідний пакет ехо-відповідей ICMP
запишіть пакет відповіді на txqueue ^* інтерфейсу петлі
читати пакет назад з rxqueue ^* для ping для обчислення RTT.

Ваша стурбованість полягає в тому, що цей RTT не є постійним. Це пояснюється тим фактом, що ваша система виконує цей процес.

Я запускаю веб-сервер apache, який дає помилку 403 на localhost. Коли я пінг

Якщо ви використовуєте ping команда не має значення, чи запущено веб-сервер чи ні. Якщо ви використовуєте час відповіді веб-сервера як "пінг", то існує досить багато додаткових шарів, через які пакет повинен пройти.

_{(*) : це не зовсім так, будь-яка логіка нижче шару 3, очевидно, є короткозамкненою, але справа в тому, що вона пройде через весь стек}

— GnP
джерело

Я думаю, здається, довгий час в порівнянні з 3,2 ГГц процесором - що процесор може зробити ці дії приблизно за 0.000000003 секунди ...

— Tim

@Вона могла б, якби нічого іншого не робила. Крім того, слід розглядати не тільки задіяний процесор, оперативна пам'ять та її шина. Як бік, я звичайно роблю тести продуктивності мережі на інтерфейсі loopback маршрутизаторів, щоб виміряти їхню верхню межу: якщо вона нижче 1 Гбіт / с, я, звичайно, не хочу, щоб маршрутизатор на 1 Гбіт / с.

— GnP

Існує багато факторів, які впливають на затримку, відмінну від фізичної відстані, яку повинен пройти сигнал, включаючи:

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

ICMP-пакети, як правило, розглядаються як низький пріоритет, і всі вони повинні оброблятися системним процесором, де відбувається зміна затримки.

— Mark Riddell
джерело

"Швидкість світла і матеріал, через який пересувається пакет, тут король". Так, дифракція в стеку tcp / ip ядра - b **** ;-)

— GnP