VPN oplade stadiger as delhelje? Bepale hokker grins jo reitsje

De measte tagongslinen binne asymmetrysk, dus in tunnel sil meast stadiger oplade as delhelje, en dat is it ferwachte antwurd en net in fout. De nijsgjirrige fraach is oft jo oplade beheind wurdt troch de line, troch eat oars dat dy al brûkt, of troch in stream dy’t fêstslacht ynstee fan gelyk te rinnen. Dy trije jouwe deselde klacht en freegje oar wurk.

Trije grinzen dy’t fan de fuortgongsbalke itselde lykje

Kapasiteit is de earste, en it is in eigenskip fan it tagongsprodukt, net fan de tunnel. In opgeande stream fan in pear megabit is normaal op ferbrûkersglêsfezel en op in protte mobile plannen, en de kosten fan fersifering binne lyts neist dat gat. Ynkapseling foeget ek bytes ta per pakket, wat de nuttige trochset yn beide rjochtingen ferminderet en net allinnich yn ien, dus it kin op himsels gjin grutte asymmetry ferklearje.

Konkurrinsje is de twadde. Wolkensyngronisaasje, fotobibleteken en bywurkingsagenten oplade wylst de masine leech liket, en in twadde apparaat op deselde line docht itselde. Rige is de tredde: in folsleine opgeande stream skoot ynteraktive ferkear efter massale gegevens, dus petearen brekke ôf wylst de oerdracht sels sûne foarútgong rapportearret.

Mjit ien rjochting tagelyk

Brûk itselde apparaat, itselde profyl en deselde bestimming, en lit nea beide rjochtingen tagelyk rinne, útsein as konkurrinsje krekt is wat jo observearje wolle. Pauzearje jo eigen opsjonele oerdrachten foar de earste run. Twa runs mei ien flagge dertusken besljochtsje it measte.

iperf3 stjoert standert fan de klant, dus de gewoane run mjit jo opgeande paad; -R keart de rjochting om en mjit it delheljen. Lit se in pear minuten útinoar rinne en notearje beide sifers ynstee fan it gemiddelde te nimmen:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

As de oplaadsifer in lyts part fan de delhelsifer is en oer runs stabel bliuwt, past de foarm by in asymmetryske tagongsline en is de tunnel net it ferhaal. As it opladen tusken runs skommelet of nei tsien sekonden ynstoart, lês dan fierder.

Beslút op basis fan wêr’t it opladen feroaret

Feroarje ien fariabele tagelyk en sjoch hokker rjochting beweecht. In twadde VPN-einpunt dat better oplade docht, wiist op dat punt of de rûte dêrhinne. Itselde stadige opladen fan in twadde apparaat op deselde line wiist op de line. In oar apparaat op in oare line dat ek stadich is, wiist op it yngongsbelied fan de bestimming, dat jo net lokaal reparearje kinne.

Notearje bytes per sekonde en ferstrutsen tiid foar deselde wurklêst, net ien snelheidsskoare. In reservekopyklant en in snelheidstest brûke ferskillende bestimmingen en ferskillende paralleliteit, dus it fergelykjen fan har sifers antwurdet neat. As lytse oanfragen goed binne en allinnich grutte oerdrachten krûpe, is de grins wierskynlik hielendal gjin bânbreedte.

Foar deistich gebrûk helpt it beheinen fan in eftergrûnoplaad of it plannen bûten vergaderingsoeren faak mear as hokker tunnelynstelling dan ek. Beoardielje dy feroaring oan de kombinearre wurklêst: in reservekopy dy’t letter klear is mar no net mear petearen ferpestet, is meastentiids de bettere ruil.

As fêstslach de traagheid ferslacht

In oerdracht dy’t op in werhelber punt befriest en dan wer trochgiet, hâldt him as in MTU-probleem fan it paad en net as in taryflimyt. De tunnel ferminderet de brûkbere lading per pakket, en in apparaat dat it resultearjende ICMP-berjocht weilitten, lit de stjoerder riede. Dat patroan fertsjinnet syn eigen test, want de reparaasje ferskilt fan it ôfstellen fan in taryf. In stiiffêst leech sifer wiist op kapasiteit, wylst in útbarsting folge troch stilte wiist op in lading dy’t it paad net drage kin.

Test it paad mei in lading dy’t net fragmintearre wurde mei, en fergelykje dan de MTU fan ’e tunnelinterface mei de wearde dy’t trochkomt:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

As de grutte probe ferdwynt wylst in lytsere slagget, knyp dan de TCP MSS op ’e tunnel yn ynstee fan de interface-MTU foar elk protokol te ferleegjen. Oanhâldende fêstslach nei dat punt heart by de opslach of it tempo fan ’e ûntfangende tapassing, net by it netwurkpaad.

Wat te feroarjen en wat te litten

Feroarje de dingen dy’t jo kontrolearje: skema’s foar eftergrûnoerdrachten, kar fan einpunt en MSS foar in fêstslach paad. Hâld elke feroaring weromdraaibaar en beheind ta ien wurklêst. Lit de dingen gewurde dy’t de mjitting goed neamt, ynklusyf in delhelsnelheid dy’t al by de line past.

Skriuw de sifers foar en nei op mei it profyl, it einpunt en it tiidstip fan de dei, want in opladeprobleem dat mei it einpunt mei beweecht is in rûtefraach, en ien dat mei it apparaat beweecht is lokaal. Dat ferslach is wat in ûndúdlike klacht yn in beslút feroaret, en it kostet twa runs fan itselde kommando.