Нещодавно ми модернізували віддалений сайт з волокна 10/10 Мбіт / с до волокна 20/20 Мбіт / с (це волокно до підвалу, потім VDSL від підвалу до офісу, приблизно 30 метрів). Існують регулярні великі копії файлів (багато гігів) між цим сайтом та центральним сайтом, тому теорія полягала в тому, що збільшення посилання на 20/20 повинно вдвічі зменшити час передачі.
Для переказів для копіювання файлів (наприклад, robocopyдля копіювання файлів у будь-якому напрямку чи реплікації Veeam Backup та Recovery) вони обмежуються в 10 Мбіт / с.
Перед оновленням:
Після оновлення ( robocopy):
Майже однакові (ігноруйте різницю в тривалості часу передачі).
Передача здійснюється через тунель IPSec між Cisco ASA5520 та Mikrotik RB2011UiAS-RM .
Перші думки:
- QoS - немає. Існують правила QoS, але жодне не повинно впливати на цей потік. Я відключив усі правила на кілька хвилин, щоб перевірити все одно, і жодних змін
- Програмно-визначені ліміти. Більшу частину цього трафіку здійснює резервне копіювання та відновлення Veeam за межами сайту, але там немає визначених обмежень. Крім того, я просто зробив прямий
robocopyі побачив абсолютно таку ж статистику. - Обладнання не здатне. Ну, опубліковані 5520 показники продуктивності - це 225 Мбіт / с даних 3DES, а Mikrotik не публікує номери, але це було б набагато більше 10 Мбіт / с. Mikrotik використовує приблизно 25% -33% процесора при виконанні цих тестів на передачу. (Крім того, передача HTTP через тунель IPSec дійсно наближається до 20 Мбіт / с)
- Затримка в поєднанні з розміром вікна TCP? Добре це затримка між сайтами 15 мс, тому навіть найгірший розмір вікна 32 КБ
32*0.015становить максимум 2,1 Мб / сек. Крім того, кілька одночасних передач все ще просто складають до 10 Мбіт / с, що не підтримує цю теорію - Можливо, джерело та місце призначення - це лайно? Добре, джерело може підштовхувати 1,6 Гб / сек послідовних послідовних зчитувань, тож це не все. Пункт призначення може робити послідовне записування, що підтримується 200 Мб / сек, так що це теж не так.
Це дуже дивна ситуація. Я ніколи раніше не бачив нічого такого, що проявилося б таким чином.
Де ще я можу подивитися?
Під час подальшого дослідження я впевнений, що вказав на тунель IPSec як проблему. Я зробив надуманий приклад і зробив кілька тестів безпосередньо між двома загальнодоступними IP-адресами на сайтах, а потім зробив точно такий же тест, використовуючи внутрішні IP-адреси, і мені вдалося повторити 20 Мбіт / с через незашифрований Інтернет, і лише 10 Мбіт / с на IPSec сторона.
У попередній версії була червона оселедець про HTTP. Забудьте про це, це був несправний механізм тестування.
Згідно з пропозицією Xeon та відголосом мого провайдера, коли я попросив їх підтримку, я встановив правило mangle, щоб скинути MSS для даних IPSec до 1422 - на основі цього розрахунку :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Щоб поміститися всередині MTU 1480 MTU. Але, на жаль, це не мало жодної ефективної зміни.
Порівнюючи захоплення проводів, сеанс TCP узгоджує MSS 1380 з обох кінців зараз (після налаштування кількох речей та додавання буфера на випадок, якщо моя математика смокче. Підказка: це, мабуть, так). 1380 - це так само MSS за замовчуванням MSA у будь-якому випадку, тому, можливо, він вев переговори про це все одно.
Я бачу деякі дивні дані в інструменті всередині Mikrotik, який я використовував для вимірювання трафіку. Це може бути нічого. Я раніше цього не помічав, коли використовував відфільтрований запит, і це бачив лише тоді, коли видалив фільтр.
1394це найбільший MTU, який мені вдалося пройти.
