UDP ei ole aina nopeampi: OpenVPN:n kuljetuksen valinta

Jokainen opas sanoo, että UDP voittaa TCP:n OpenVPN:ssä, ja tuo neuvo on oletus, ei mittaus. Kuljetus muuttaa sitä, miten paketit toimitetaan ja mitä tapahtuu, kun polku pudottaa ne, ei sitä, miten tunneli salataan. Captive-portaalin tai vain portin 443 sallivan välityspalvelimen takana hitaampi vaihtoehto on se, joka ylipäätään yhdistää. Seuraava erottaa sen, mitä protokolla tekee, siitä, mitä käyttöverkkosi sallii.

Mitä kuljetus oikeastaan muuttaa

TCP tarjoaa luotettavan, järjestetyn tavuvirran ja lähettää uudelleen kaiken kadonneen, kuten RFC 9293 määrittelee. UDP luovuttaa datagrammit verkolle, ja OpenVPN ajaa omaa luotettavuuskerrostaan tuon pistokkeen päällä. TCP:n kapselointi TCP:n sisään pinouttaa kaksi palautussilmukkaa, joten yksi kadonnut segmentti voi pidätellä sisempää virtaa, kunnes ulompi uudelleenlähetys saapuu. Juuri tämä vuorovaikutus on todellinen argumentti UDP:n puolesta, ja se näkyy latenssina eikä läpäisynä.

Vaikutus kasvaa häviöiden ja edestakaisen ajan mukana. Puhtaalla paikallisella polulla molemmat kuljetukset tuntuvat samoilta, minkä vuoksi laboratoriotesti harvoin toistaa valituksen. Ruuhkaisella mobiiliyhteydellä ero näkyy interaktiivisissa istunnoissa kauan ennen kuin suuri siirto huomaa mitään.

Mikään tästä ei koske luottamuksellisuutta tai eheyttä. TLS-kättely ja datakanavan salaus ovat samat molemmille kuljetuksille, joten vaihto ei voi pelastaa heikkoa salauspakettia.

Missä TCP ansaitsee paikkansa

Käyttöverkot ovat tavallinen syy valita TCP. Hotelli, lentoasema tai vierasverkko voi sallia lähtevän 443:n ja pudottaa kaiken muun, ja TCP-kuuntelija tuossa portissa on ainoa toimiva profiili. Se on tavoitettavuutta, ei suorituskykyä, ja se on yksinään riittävän hyvä syy.

TCP auttaa myös silloin, kun polku on vakaa mutta välilaiteet ovat vihamielisiä. Jotkin verkot nollaavat pitkäikäisiä UDP-virtoja samalla kun ne sietävät tavalliselta verkkoliikenteeltä näyttäviä TCP-istuntoja. Onnistuuko tuo samankaltaisuus, on kyseisen verkon ominaisuus, eikä mikään opas voi luvata sitä kaikille. Testaa verkossa, joka epäonnistuu, ennen kuin syytät protokollaa.

Hylätty kirjautuminen ei ole kuljetusongelma. Varmenteen vahvistuksen poistaminen käytöstä yhteyden pakottamiseksi on toinen muutos, jonka lopputulos on paljon huonompi.

TCP-profiilin pitäminen valmiina on käytännöllinen kompromissi. Useimmat asiakkaat tallentavat molemmat ja antavat vaihtaa, kun verkko kieltäytyy UDP-polusta, mikä ei maksa mitään ennen kuin sitä tarvitset. Sitä sinun ei pitäisi tehdä: toimittaa kaksi profiilia, jotka osoittavat eri päätepisteisiin, koska silloin vertailusi mittaa palvelimia.

Tarkista, mikä kuuntelija sinulla todella on

Ennen suorituskyvyn vertaamista varmista, että molemmat päät ovat yhtä mieltä kuljetuksesta ja portista. proto udp:n muuttaminen proto tcp:ksi asiakastiedostossa ei luo palvelimen kuuntelijaa. Palvelin on määritettävä tälle protokollalle, ja profiilin on vastattava sitä.

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

grep tulostaa, mitä palvelimelle on sanottu käytettäväksi, kun taas kaksi pistokeluetteloa näyttävät, mihin se on sidottu. UDP-kuuntelija näkyy vain ensimmäisessä luettelossa ja TCP-kuuntelija vain toisessa, joten puuttuva rivi on nopein tapa löytää profiili, jota ei koskaan otettu käyttöön. Vertaa myös porttia, sillä TCP-profiili portissa 1194 käyttäytyy useimmissa käyttöverkoissa eri tavalla kuin portissa 443. Käynnistä palvelu uudelleen muutoksen jälkeen ja lue lokirivi, joka kertoo sidonnasta.

Asiakaspuolen vahvistus on halpaa: aja yhteys --verb 4:lla ja lue kuljetusrivi lokista. Jos asiakas sanoo UDP, kun palvelin kuuntelee TCP:tä, kättely ei koskaan ala eikä mikään viritys auta.

Vertaa työkuormaa, älä kuljetuksen leimaa

Reilu vertailu pitää kaiken muun paitsi kuljetuksen vakiona. Sama laite, sama käyttöverkko, sama kohdeisäntä, sama sovellus ja ihanteellisesti sama palvelin. Jos kaksi profiilia osoittavat eri isäntiin, mittaat myös niitä isäntiä.

Kirjaa jokaisesta ajosta kolme tulosta: muodostuuko tunneli, pysyykö se pystyssä ja valmistuuko tehtävä. Pienet pyynnöt, jotka toimivat suurten siirtojen juuttuessa, viittaavat pakettikokoon ja MTU:hun, eivät kuljetukseen. Toistuvat uudelleenyhdistämiset viittaavat polkuun tai välilaitteen aikakatkaisuun.

Pidä profiili, joka toimii olosuhteissa, joihin todella törmäät, ja pidä toinen tallessa. Valinta kuuluu verkolle, ei henkilölle, ja siksi mikä tahansa yksittäinen oletusvastaus on jossain väärä.