Калкулатор за мрежно доцнење и пропусен опсег

Разбирање на лимитите на TCP протокот

Реалните перформанси на еден TCP тек (single TCP flow) ретко ја достигнуваат номиналната брзина на мрежната врска. Протокот на податоци е ограничен од три независни фактори кои дејствуваат истовремено: физичкиот капацитет на врската намален за протоколарниот трошок, големината на прозорецот за прием на дестинацијата и стапката на губење пакети на патеката. Најнискиот од овие три лимити го претставува активното тесно грло на преносот.

Алатката „Network Latency Bandwidth Calculator“ овозможува прецизно пресметување на овие перформанси врз основа на внесените параметри за патеката, преносот и TCP протоколот. Пресметките се извршуваат локално во Вашиот веб-прелистувач. Секоја вредност што ја внесувате се пресметува во овој прелистувач — ништо никаде не се испраќа.

Влезни параметри и нивните ограничувања

За да се изврши пресметката, потребно е да се конфигурираат следните полиња во интерфејсот:

• Брзина на врската: Најбавниот скок на патеката — честопати номиналната брзина на Вашиот пакет. Вредноста мора да биде поголема од нула. Се избира соодветна „Единица за брзина“.
• Време на повратно патување (RTT): Време на пинг до одредиштето — користете ја најголемата вредност што ја очекувате под оптоварување. Вредноста мора да биде поголема од нула, изразена преку соодветната „Единица за време“.
• Големина на податоци: Корисни податоци за пренос — датотека, резервна копија, збир на податоци. Вредноста мора да биде поголема од нула, дефинирана со соодветната „Единица за големина“.
• Прозорец за прием: Бајти што примачот може да ги зачува во бафер. Вредноста мора да биде поголема од нула и не смее да надмине 1,073,725,440 бајти. Доколку ова поле се остави празно, тоа означува дека нема лимит на прозорецот. Се користи соодветната „Единица за прозорец“.
• МСС (MSS): Корисни бајти по пакет — 1,460 пополнува стандардна Ethernet рамка. Мора да биде цел број на бајти помеѓу 1 и 65,495. Доколку се остави празно, протоколарниот трошок и загубите се игнорираат.
• Губење пакети (%): Просечна веројатност за губење пакети. Мора да биде вредност помеѓу 0 и 100 проценти. Доколку се остави празно или се внесе 0, се смета дека нема лимит за загуби.
• Прикажани децимали: Ја контролира децималната прецизност на прикажаните резултати.

Интерфејсот нуди и копче „Вчитај пример“ за автоматско пополнување на полињата со пример-вредности, како и копче „Исчисти“ за ресетирање на сите внесени податоци.

Излезни резултати и системски известувања

По внесувањето на параметрите, калкулаторот ги прикажува резултатите во три главни секции. Главниот резултат е прикажан како „Очекуван TCP проток“, придружен со поднаслов кој го идентификува активното тесно грло: „ограничен од ‹constraint›“. Динамичкиот ограничувачки фактор (‹constraint›) може да биде:

• капацитетот на врската
• прозорецот за прием
• губењето пакети

Останатите пресметани метрики вклучуваат:

• Време на пренос
• Време до првиот бајт (1 RTT)
• Време на пренос на податоците
• Производ на пропусен опсег и доцнење
• Прозорец за пополнување на патеката
• Проток ограничен со прозорецот
• Проток ограничен со загуби (Mathis)
• Лимит на врската по протоколарен трошок
• Ефикасност на протоколот

Дополнително, во зависност од вредностите, системот генерира специфични забелешки:

• Ако потребниот прозорец го надминува стандардниот лимит: „За пополнување на оваа патека потребен е прозорец од ‹window› — над нескалираниот максимум од 65,535 бајти, па двете страни мора да договорат TCP скалирање на прозорецот (RFC 7323).“
• Ако потребниот прозорец ги надминува апсолутните TCP лимити: „За пополнување на оваа патека потребен е ‹window› — над најголемиот прозорец што TCP може да го договори (1,073,725,440 бајти). Еден тек на оваа патека никогаш не може да надмине ‹value›.“
• Ако зголемувањето на баферот би помогнало: „Зголемувањето на прозорецот за прием на ‹window› би му овозможило на овој пренос да достигне до ‹value›.“
• Ако стапката на загуби е превисока за моделот: „Загубите над 1% се надвор од сигурниот опсег на моделот на Mathis — третирајте го лимитот за загуби као оптимистичен.“

Корисникот може да ги зачува пресметаните податоци со кликнување на копчето „Копирај го резултатот“.

Математички формули и замена на вредностите

Пресметките се засноваат на следните математички релации, кои се прикажуваат во делот „Формули и замена“:

• Главна формула: проток = min(брзина × ефикасност, прозорец ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = брзина × RTT
• Ефикасност на протоколот: Ефикасност на протоколот = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B заглавија на пакети + 38 B на самиот медиум)
• Лимит на врската: Лимит на врската = брзина × ефикасност = ‹rate› × ‹eff› = ‹value›
• Производ на пропусен опсег и доцнење (BDP): BDP = брзина × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes›
• Прозорец за пополнување на патеката: Прозорец за пополнување на патеката = BDP ÷ 8 = ‹bdp› → ‹window›
• Лимит на прозорецот: Лимит на прозорецот = прозорец ÷ RTT = ‹window› ÷ ‹rtt› = ‹value›
• Лимит поради загуби (Mathis): Лимит поради загуби (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
• Очекуван проток: Очекуван проток = најнискиот од овие лимити = ‹value› → ограничен од ‹constraint›
• Време на пренос: Време на пренос = RTT + 8 × големина ÷ проток = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›

Правила, протоколарен трошок и ограничувања на моделот

При користење на калкулаторот и толкување на резултатите, мора да се земат предвид следните технички правила:

1. Децимални наспроти бинарни единици: Сите пресметки користат децимални единици (на пр. 1 kbit = 1,000 бита, 1 MB = 1,000,000 бајти). Менаџерите на датотеки во оперативните системи најчесто користат бинарни единици базирани на 1024 (каде 100 MB се всушност 100 MiB, односно околу 104.86 децимални MB).
2. Протоколарен трошок (Overhead): Моделот претпоставува стандарден Ethernet пренос, додавајќи фиксни 78 бајти по пакет (40 бајти за TCP/IP заглавија и 38 бајти за физичкиот медиум).
3. Ограничувања на Mathis-овиот модел: Овој модел претпоставува рамномерно распоредени и независни загуби на пакети. Тој е сигурен само за стапки на загуби под 1%. Доколку загубите го надминат овој праг, се активира предупредувањето.
4. TCP скалирање на прозорецот (RFC 7323): Стандардниот нескалиран TCP прозорец е ограничен на 65,535 бајти. За поголеми капацитети, неопходно е двете страни да поддржуваат скалирање според спецификацијата RFC 7323, која овозможува максимален прозорец до 1,073,725,440 бајти.
5. Исклучоци од моделот: Пресметките се однесуваат на воспоставена, усталена состојба на еден TCP тек. Факторите како што се TCP бавен старт (slow start), алгоритмите за контрола на преоптоварување, бавните примачи и TLS ракувањата не се вклучени во пресметката, што значи дека реалните преноси во почетокот ќе бидат побавни.

Често поставувани прашања (FAQ)

Зошто мојот пренос е побавен од брзината на врската што ја плаќам?

Еден TCP тек се соочува со три независни лимити, и најнискиот победува. Протоколарниот трошок ја намалува самата врска за околу 5% — стандардна Ethernet рамка пренесува 1,460 корисни бајти од вкупно 1,538 на самиот медиум. Прозорецот за прием го ограничува протокот на прозорец ÷ RTT, па класичниот прозорец од 65,535 бајти ја ограничува патеката од 50 ms на околу 10.5 Mbit/s без разлика колку е брза врската. А загубите го ограничуваат на (MSS ÷ RTT) ÷ √загуби. Резултатот погоре го именува лимитот што е пресуден за Вашите бројки.

Што е производ на пропусен опсег и доцнење, и зошто тој ја одредува големината на прозорецот?

BDP — брзината на врската × времето на повратно патување — е количината на податоци во пренос во кој било момент. TCP може да има најмногу еден непотврден прозорец во тек, па прозорец помал од BDP ја остава патеката делумно празна: при 100 Mbit/s со 50 ms RTT патеката собира 625 kB, а прозорец од 65,535 бајти пополнува едвај една десетина од неа. Затоа на брзите и долги патеки им е потребно TCP скалирање на прозорецот (RFC 7323), кое го зголемува максимумот за договарање од 65,535 бајти на околу 1 GB.

Како губењето пакети го ограничува TCP протокот?

TCP го третира губењето како преоптоварување и ја преполовува својата брзина на испраќање при секој изгубен пакет, па дури и занемарливи стапки на загуби се важни на брзите патеки. Моделот на Mathis го проценува лимитот као (MSS ÷ RTT) ÷ √p — при 0.01% загуби на патека од 50 ms со MSS од 1,460 бајти, тоа е околу 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 тука за точно да се совпадне.