Чаму VPN здаецца павольным падчас запампоўкі: чарговае запазненне

Пачынаецца запампоўка рэзервовай копіі, лічыльнік перадачы выглядае здаровым, а відэазванок ператвараецца ў кашу. Каналу не бракуе прапускной здольнасці ў тым сэнсе, які падказвае гэты лік; пакеты недзе чакаюць у чарзе, і інтэрактыўныя пакеты стаяць за вялікім аб'ёмам даных. Гэта чарговае запазненне, звычайна званае перапаўненнем буфера. VPN можа дадаць сваю чаргу, але рэдка стварае праблему сам.

Прапускная здольнасць і запазненне — розныя вымярэнні

Прапускная здольнасць адказвае, колькі даных рухаецца за секунду, а запазненне адказвае, колькі часу патрэбна аднаму пакету, каб перасекчы шлях. Насычаны канал можа ўтрымліваць вялікі назапашаны аб'ём і ўсё роўна паказваць добрую прапускную здольнасць, бо чарга апускаецца з хуткасцю лініі, як толькі ўсплеск сканчаецца. Інтэрактыўны трафік пакутуе першым, бо званку патрэбны пакет кожныя некалькі мілісекунд, а не вялікі файл у рэшце рэшт. Таму вымярэнне толькі выніку тэсту хуткасці хавае сімптом, які прымусіў вас зірнуць.

Звярніце ўвагу і на кірунак пад нагрузкай. Поўны буфер запампоўкі можа затрымаць усё астатняе, пакуль магутнасць спампоўкі стаіць без справы.

Вымярайце час кругавога шляху пад нагрузкай

Вазьміце базавы ўзровень на ціхім канале, затым паўтарыце тое ж вымярэнне, пакуль ідзе адна кантраляваная перадача. Параўнайце два прагоны, а не абсалютныя лікі.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

Першая каманда бярэ ўзоры часу кругавога шляху, а другая стварае ўстойлівую запампоўку без патрэбы ў сэрвісе тэсту хуткасці. Базавы ўзровень, які застаецца роўным, а затым загружаны прагон, які вырастае на сотні мілісекунд, — вось шуканая прыкмета. Некаторыя сеткі паніжаюць прыярытэт ICMP, таму лічыце ping падказкай і пацвердзіце праз уласнае адлюстраванне затрымкі праграмы. Трымайце тэст кароткім на лімітаваных каналах, бо паўторны кантраст важнейшы за доўгае насычэнне.

Перанясіце чаргу туды, дзе вузкае месца

Кіраванне чаргой дапамагае толькі на прыладзе, якая сапраўды трымае назапашаныя даныя. Агледзьце, што робіць інтэрфейс, перш чым дадаваць правілы.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

Каманда show паведамляе бягучую дысцыпліну, а таксама лічыльнікі назапашвання і скіду, што паказвае, ці гэты інтэрфейс з'яўляецца вузкім месцам, ці проста прапускае трафік. Замена каранёвай дысцыпліны алгарытмам справядлівай чаргі дае кароткім патокам уласную чаргу замест адной FIFO, падзеленай з вялікім аб'ёмам даных. Ужывайце гэта на WAN-інтэрфейсе маршрутызатара, калі маршрутызатар — вузкае месца, а не на прыладзе тунэля па звычцы. Захавайце папярэднюю канфігурацыю і паўторна праверце як адзыўчывасць пад нагрузкай, так і хуткасць перадачы, бо крыху ніжэйшая масавая хуткасць — добры абмен на прыдатныя званкі.

Што тунэль змяняе і што ён хавае

VPN дадае шыфраванне і яшчэ адзін пераход, а таксама хавае асобныя патокі ад абсталявання па-за тунэлем. Гэта важна, калі вышэйстаячая прылада прапануе прыярытэт для кожнай праграмы, бо яна бачыць шыфраваныя пакеты, а не зыходныя размовы. Маршрутызатар, які сам завяршае тунэль, мае іншы погляд і іншую нагрузку і можа класіфікаваць унутры яго. Ніякая з гэтых схемаў не прыбірае чаргу на канале доступу, дзе звычайна назапашваецца затрымка.

Калі затрымка не залежыць ад нагрузкі, спыніце наладжваць чаргі і паглядзіце ў іншае месца: умовы Wi-Fi, праблемы з памерам пакета або адзін дрэнны шлях выхаду. Налады чаргі, ужытыя без вымярэння, проста пераносяць загадку.