UDP не заўсёды хутчэйшы: як выбраць транспарт OpenVPN

Кожнае кіраўніцтва кажа, што UDP лепшы за TCP для OpenVPN, і гэтая парада — прадвызначэнне, а не вымярэнне. Транспарт змяняе тое, як дастаўляюцца пакеты і што адбываецца, калі шлях іх губляе, а не тое, як шыфруецца тунэль. За абмежавальным парталам або проксі, які дазваляе толькі порт 443, больш павольны варыянт — адзіны, які ўвогуле злучаецца. Далейшае аддзяляе тое, што робіць пратакол, ад таго, што дазваляе ваша сетка доступу.

Што транспарт сапраўды змяняе

TCP забяспечвае надзейны ўпарадкаваны байтавы паток і перадае паўторна ўсё страчанае, як вызначае RFC 9293. UDP перадае датаграмы ў сетку, а OpenVPN запускае ўласны слой надзейнасці па-над гэтым сокетам. Інкапсуляцыя TCP у TCP складае два цыклы аднаўлення, таму адзін страчаны сегмент можа затрымаць унутраны паток, пакуль не прыйдзе знешняя паўторная перадача. Менавіта гэтае ўзаемадзеянне — сапраўдны аргумент за UDP, і яно праяўляецца як затрымка, а не як прапускная здольнасць.

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

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

Дзе TCP заслугоўвае сваё месца

Сеткі доступу — звычайная прычына выбраць TCP. Гатэль, аэрапорт або гасцявая сетка могуць дазваляць зыходны 443 і адкідаць усё іншае, і TCP-слухач на гэтым порце — адзіны профіль, які працуе. Гэта дасягальнасць, а не прадукцыйнасць, і гэта дастаткова добрая прычына сама па сабе.

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

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

Трымаць профіль TCP гатовым — практычны кампраміс. Большасць кліентаў захоўваюць абодва і дазваляюць пераключыцца, калі сетка адмаўляе UDP-шлях, што нічога не каштуе, пакуль не спатрэбіцца. Чаго не варта рабіць — гэта выпускаць два профілі, накіраваныя на розныя канчатковыя пункты, бо тады вашае параўнанне вымярае серверы.

Праверце, які слухач у вас сапраўды ёсць

Перад параўнаннем прадукцыйнасці пераканайцеся, што абодва бакі згодныя наконт транспарту і порта. Змена proto udp на proto tcp у кліенцкім файле не стварае серверны слухач. Сервер трэба наладзіць на гэты пратакол, і профіль павінен яму адпавядаць.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep друкуе тое, што серверу сказана выкарыстоўваць, а два спісы сокетаў паказваюць, да чаго ён прывязаны. UDP-слухач з'яўляецца толькі ў першым спісе, а TCP-слухач — толькі ў другім, таму адсутны радок — самы хуткі спосаб знайсці профіль, які ніколі не ўжываўся. Параўнайце і порт, бо TCP-профіль на 1194 паводзіць сябе інакш, чым на 443, у большасці сетак доступу. Пасля змены перазапусціце службу і прачытайце радок журнала, які паведамляе пра прывязку.

Кліенцкае пацверджанне — танна: запусціце злучэнне з --verb 4 і прачытайце радок транспарту ў журнале. Калі кліент кажа UDP, а сервер слухае TCP, рукапоцісканне ніколі не пачнецца, і любое наладжванне не дапаможа.

Параўноўвайце нагрузку, а не ярлык транспарту

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

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

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