UDP ne vienmēr ir ātrāks: OpenVPN transporta izvēle
UDP ir saprātīga OpenVPN noklusējuma izvēle, nevis spriedums. Salīdziniet transportus vienā ceļā un uzdevumā un pārbaudiet, kurš klausītājs patiešām darbojas.
Katrs ceļvedis saka, ka UDP ir labāks par TCP OpenVPN, un šis padoms ir noklusējums, nevis mērījums. Transports maina to, kā tiek piegādātas paketes un kas notiek, kad ceļš tās izmet, nevis to, kā tiek šifrēts tunelis. Aiz captive portāla vai starpniekservera, kas atļauj tikai 443 ostu, lēnākais variants ir tas, kas vispār pievienojas. Turpmākais atdala to, ko dara protokols, no tā, ko atļauj jūsu piekļuves tīkls.
Ko transports patiešām maina
TCP nodrošina uzticamu, sakārtotu baitu plūsmu un atkārto visu, kas tiek pazaudēts, kā nosaka RFC 9293. UDP nodod datagrammas tīklam, un OpenVPN virs šīs ligzdas darbina savu uzticamības slāni. TCP iekapsulēšana TCP iekšienē sakrauj divas atkopšanas cilpas, tāpēc viens pazaudēts segments var aizturēt iekšējo plūsmu, līdz pienāk ārējā atkārtošana. Tieši šī mijiedarbība ir īstais arguments par labu UDP, un tā izpaužas kā aizture, nevis kā caurlaidspēja.
Ietekme pieaug līdz ar zudumiem un turp-atpakaļ laiku. Tīrā vietējā ceļā abi transporti šķiet identiski, tāpēc laboratorijas tests reti atkārto sūdzību. Pārslogotā mobilajā saitē atšķirība parādās interaktīvās sesijās krietni pirms liels pārsūtījums ko pamana.
Nekas no tā neattiecas uz konfidencialitāti vai integritāti. TLS rokasspiediens un datu kanāla šifrs ir vienādi abiem transportiem, tāpēc pārslēgšanās nevar glābt vāju šifru kopumu.
Kur TCP nopelna savu vietu
Piekļuves tīkli ir parastais iemesls izvēlēties TCP. Viesnīca, lidosta vai viesu tīkls var atļaut izejošo 443 un izmest visu pārējo, un TCP klausītājs šajā ostā ir vienīgais strādājošais profils. Tā ir sasniedzamība, nevis veiktspēja, un tas pats par sevi ir pietiekami labs iemesls.
TCP palīdz arī tad, kad ceļš ir stabils, bet starpniekierīces ir naidīgas. Daži tīkli atiestata ilgstošas UDP plūsmas, vienlaikus pieļaujot TCP sesijas, kas līdzinās parastam tīmekļa trafikam. Vai šī līdzība izdodas, ir konkrētā tīkla īpašība, un neviens ceļvedis to nevar solīt visiem. Pārbaudiet tīklā, kas neizdodas, pirms vainot protokolu.
Noraidīta pieteikšanās nav transporta problēma. Sertifikāta pārbaudes izslēgšana, lai piespiestu savienojumu, ir cita izmaiņa ar daudz sliktāku iznākumu.
Gatava TCP profila turēšana ir praktiskais kompromiss. Lielākā daļa klientu glabā abus un ļauj pārslēgties, kad tīkls atsakās no UDP ceļa, kas neko nemaksā, līdz tas ir vajadzīgs. Tas, ko nevajadzētu darīt, ir piegādāt divus profilus, kas norāda uz dažādiem galapunktiem, jo tad jūsu salīdzinājums mēra serverus.
Pārbaudiet, kurš klausītājs jums patiešām ir
Pirms veiktspējas salīdzināšanas apstipriniet, ka abi gali vienojas par transportu un ostu. proto udp maiņa uz proto tcp klienta failā neizveido servera klausītāju. Serverim jābūt konfigurētam šim protokolam, un profilam tam jāatbilst.
grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn
grep izdrukā, kas serverim tika likts lietot, bet divi ligzdu saraksti parāda, kam tas ir piesaistīts. UDP klausītājs parādās tikai pirmajā sarakstā, bet TCP klausītājs tikai otrajā, tāpēc trūkstošā rinda ir ātrākais veids, kā atrast profilu, kas nekad nav ticis piemērots. Salīdziniet arī ostu, jo TCP profils 1194 ostā lielākajā daļā piekļuves tīklu uzvedas citādi nekā 443. Pēc izmaiņām restartējiet pakalpojumu un izlasiet žurnāla rindu, kas ziņo par piesaisti.
Klienta puses apstiprinājums ir lēts: palaidiet savienojumu ar --verb 4 un izlasiet transporta rindu žurnālā. Ja klients saka UDP, bet serveris klausās TCP, rokasspiediens nekad nesākas un nekāda regulēšana nepalīdzēs.
Salīdziniet darba slodzi, nevis transporta etiķeti
Godīgs salīdzinājums visu notur nemainīgu, izņemot transportu. Tā pati ierīce, tas pats piekļuves tīkls, tas pats galamērķa resursdators, tā pati lietojumprogramma un ideālā gadījumā tas pats serveris. Ja divi profili norāda uz dažādiem resursdatoriem, jūs mērāt arī tos resursdatorus.
Katram palaidienam pierakstiet trīs iznākumus: vai tunelis izveidojas, vai tas noturas un vai uzdevums tiek pabeigts. Mazie pieprasījumi, kas darbojas, kamēr lieli pārsūtījumi iestrēgst, norāda uz paketes izmēru un MTU, nevis transportu. Atkārtoti savienojumi norāda uz ceļu vai starpniekierīces taimautu.
Paturiet profilu, kas darbojas apstākļos, ar kuriem jūs patiešām saskaraties, un saglabājiet otru. Izvēle pieder tīklam, nevis personai, tāpēc jebkura viena noklusējuma atbilde kaut kur ir nepareiza.