Ограничаващи фактори при пропускателната способност на TCP
Реалната скорост на трансфер на данни по мрежата рядко съвпада с максималния капацитет на физическата връзка. Когато се използва протоколът TCP, производителността на единичен поток се диктува от три независими тавана: капацитета на физическата връзка, размера на прозореца за приемане и загубата на пакети. Най-ниската стойност сред тези три ограничения определя крайната скорост на трансфера.
За да се изчисли теоретичният таван на производителността, Калкулаторът за мрежово закъснение и честотна лента анализира въведените параметри на трасето и прилага математически модели за определяне на тесните места. Всички изчисления се извършват локално в браузъра на потребителя, като въведените данни не се изпращат към външни сървъри.
Таван на връзката и протоколна ефективност
Физическата скорост на връзката не е изцяло достъпна за полезния товар на данните. Всеки пакет носи допълнителна служебна информация. Моделът на инструмента се базира на стандартен Ethernet, който добавя 78 байта служебен трафик към всеки пакет (40 байта за TCP/IP хедъри и 38 байта физически служебни данни по кабела). Ако максималният размер на сегмента (MSS) е 1,460 байта, ефективността се изчислява по формулата:
Ефективност на протокола = MSS ÷ (MSS + 78 B) (40 B хедъри на пакета + 38 B по кабела)
Таванът на връзката след приспадане на този служебен трафик се определя като:
Таван на връзката = rate × efficiency
Таван на прозореца за приемане
TCP изисква получателят да потвърждава пристигането на пакетите. Прозорецът за приемане определя максималното количество байтове, които изпращачът може да пренесе, преди да получи потвърждение. Ако този прозорец е твърде малък, изпращачът спира и изчаква, което ограничава скоростта до:
Таван на прозореца = window ÷ RTT
Таван при загуби (Модел на Mathis)
Когато по трасето има загуба на пакети, TCP интерпретира това като сигнал за претоварване на мрежата и намалява скоростта на предаване. Връзката между вероятността за загуба (p) и максималната скорост се описва чрез формулата на Mathis:
Таван при загуби (Mathis) = MSS ÷ RTT ÷ √p
Този модел предполага равномерно разпределени и независими събития на загуба на пакети. Той е надежден при нива на загуби под приблизително 1%. При по-високи нива на загуба моделът става твърде оптимистичен.
Произведение на честотната лента и закъснението (BDP)
За пълното запълване на капацитета на едно мрежово трасе е необходимо в движение (във всеки един момент по кабела) да има достатъчно количество данни. Това количество се нарича Произведение на честотната лента и закъснението (BDP) и се изчислява по формулата:
BDP = скорост × RTT
За да се поддържа максимална скорост без прекъсване на предаването, необходимият размер на прозореца за приемане трябва да бъде поне равен на BDP:
Прозорец за запълване на трасето = BDP ÷ 8
Ако капацитетът на трасето изисква прозорец, по-голям от стандартния лимит на TCP от 65,535 байта, е необходимо използването на механизма за мащабиране на прозореца съгласно RFC 7323.
Правила за изчисление и ограничения на модела
При използването на калкулатора трябва да се имат предвид следните дефинирани правила и гранични случаи:
- Десетични единици: Всички изчисления за капацитет и размер на данните използват десетичната система (например 1 kbit = 1,000 бита, 1 MB = 1,000,000 байта). Файловите мениджъри в операционните системи обикновено измерват обемите в двоични единици (на база 1024), което може да доведе до разминаване от около 5% при изчисляване на времето за трансфер на файлове.
- Мащабиране на прозореца (RFC 7323): Максималният размер на прозореца, който TCP може да договори чрез мащабиране, е 1,073,725,440 байта. Ако изчисленият BDP изисква по-голям прозорец от този абсолютен лимит, калкулаторът показва съобщение за ограничение.
- Установен режим на работа: Моделът анализира производителността при установен режим на единичен TCP поток. Фактори като бавен старт (slow start), алгоритми за контрол на претоварването, закъснения при TLS ръкостискане или бавна обработка от страна на получателя не са включени в изчисленията. Поради това реалните трансфери започват по-бавно и крайните резултати трябва да се разглеждат като теоретична горна граница.
Въвеждане на данни и съобщения за грешка
За извършване на изчисленията потребителят попълва следните полета в интерфейса:
- Скорост на връзката: Скоростта на най-бавното звено по трасето. Трябва да бъде стойност, по-голяма от нула.
- Двупосочно закъснение (RTT): Времето за пинг до отсрещния край под натоварване. Трябва да бъде по-голямо от нула.
- Размер на данните: Общият обем на полезния товар за трансфер. Трябва да бъде по-голям от нула.
- Прозорец за приемане: Буферът на получателя в байтове. Не може да надвишава 1,073,725,440 байта. Празно поле означава липса на ограничение от прозореца.
- MSS (байтове): Размерът на полезния товар в един пакет (между 1 и 65,495 байта). Празно поле изключва изчисляването на служебния трафик и загубите.
- Загуба на пакети (%): Средната вероятност за загуба (между 0 и 100 процента).
При въвеждане на некоректни стойности системата показва следните съобщения за грешка:
- При грешен формат на числото:
"‹field›: “‹token›” не е число." - При нулева или отрицателна скорост:
"Скоростта на връзката трябва да бъде по-голяма от нула." - При нулева или отрицателна стойност за RTT:
"Двупосочното закъснение трябва да бъде по-голямо от нула." - При нулев или отрицателен размер на данните:
"Размерът на данните трябва да бъде по-голям от нула." - При нулев или отрицателен прозорец:
"Прозорецът за приемане трябва да бъде по-голям от нула." - При превишаване на лимита за прозорец:
"TCP не може да договори прозорец над 1,073,725,440 байта (мащабиране на прозореца по RFC 7323)." - При некоректен MSS:
"MSS трябва да бъде цяло число байтове между 1 и 65,495." - При некоректен процент загуби:
"Процентът на загуби трябва да бъде между 0 и 100 процента." - При препълване на изчислителния диапазон:
"Дадена стойност или междинен резултат надхвърля поддържания диапазон от числа."
Често задавани въпроси (FAQ)
Какво е произведението на честотната лента и закъснението (BDP) и защо то определя размера на прозореца?
BDP — скоростта на връзката × двупосочното закъснение — е количеството данни в движение във всеки един момент. TCP може да има най-много един непотвърден прозорец в движение, така че прозорец, по-малък от BDP, оставя канала частично празен: при 100 Mbit/s с 50 ms RTT каналът побира 625 kB, а прозорец от 65,535 байта запълва едва една десета от него. Ето защо бързите и дълги трасета се нуждаят от мащабиране на TCP прозореца (RFC 7323), което повишава договаряния максимум от 65,535 байта до около 1 GB.
Защо трансферът ми е по-бавен от скоростта на връзката, за която плащам?
Единичен TCP поток се сблъсква с три независими тавана и най-ниският от тях печели. Служебният протоколен трафик намалява самата връзка с около 5% — стандартен Ethernet кадър пренася 1,460 байта полезен товар от общо 1,538 байта по кабела. Прозорецът за приемане ограничава скоростта до window ÷ RTT, така че класическият прозорец от 65,535 байта ограничава трасе с 50 ms закъснение до около 10.5 Mbit/s, независимо колко бърза е връзката. А загубите я ограничават до (MSS ÷ RTT) ÷ √loss. Резултатът по-горе посочва кой таван е ограничаващ за Вашите числа.
Как загубата на пакети ограничава скоростта на TCP?
TCP третира загубата като претоварване и намалява наполовина скоростта си на изпращане при всяко събитие на загуба, така че дори минимални нива на загуби са от значение при бързите трасета. Моделът на Mathis оценява тавана като (MSS ÷ RTT) ÷ √p — при 0.01% загуби по трасе с 50 ms закъснение и 1,460 байта MSS това е около 23 Mbit/s, независимо от скоростта на връзката. Моделът предполага равномерно разпределени, независими събития на загуба; под приблизително 1% той отразява реалността добре, а при пакетни загуби е оптимистичен.
Еднакви ли са мегабайтите тук с тези в моя файлов мениджър?
Не съвсем. Тази страница използва десетични единици, каквато е мрежовата конвенция: 1 kbit = 1,000 бита и 1 MB = 1,000,000 байта. Повечето файлови мениджъри броят в единици на база 1024, често погрешно обозначени като MB — файл от „100 MB“ там обикновено е 100 MiB ≈ 104.86 десетични MB, така че прехвърлянето му отнема около 5% повече време, отколкото предполага десетичната цифра. Въведете 104.86 MB тук, за да съвпадне точно.