Mas mabilis ba ang mas maliit na MTU ng VPN? Ihambing ang tunay na ebidensya

Inihuhulog ng tunnel ang malalaking paglilipat ngunit pinapayagan ang ping, kaya mabilis dumating ang payo: babaan ang MTU. Minsan gumagana ang pagwawasto, at pagkatapos ay inilalapat ito sa bawat profile sa bawat network. Doon nagiging permanenteng buwis sa pagganap ang isang naka-target na pagkukumpuni. Ang paghahambing na dapat gawin ay nasa pagitan ng tunay na hangganan ng landas at ng gastos ng pagpapaliit ng bawat packet sa ilalim nito.

Ano ang talagang lumiliit kapag binabaan mo ang MTU

Bawat packet ay may dalang header bago ito magdala ng iyong data. Sa landas na Ethernet na 1500 byte, ang IPv4 at TCP ay kumokonsumo ng 40 byte at nag-iiwan ng 1460 para sa payload; nagdadagdag ang encapsulation ng panlabas na IP, UDP at tunnel header sa itaas, kaya bumababa muli ang panloob na badyet ng payload. Ang pagbaba ng MTU ng interface ay sadyang pinapaliit ang badyet na iyon.

Ang gastos ay proporsyonal sa bilang ng mga packet, hindi sa bilang ng mga byte. Ang parehong file na hinati sa mas maraming packet ay nangangailangan ng mas maraming interruption, mas maraming desisyon sa routing at mas maraming pagproseso bawat packet sa bawat device sa landas. Sa router na malapit na sa limitasyon nito sa packet kada segundo, iyon ay tunay na pagbagal at hindi error sa rounding. Lumilitaw ang gastos kahit na magtagumpay ang paglilipat mismo.

Kaya ang mas maliit na MTU ay isang pag-ikot sa isang had, hindi isang pangkalahatang optimisasyon. Binibili nito ang pagiging maaasahan laban sa landas na hindi kayang magdala ng mas malaking frame, at naniningil ito ng overhead para sa bawat packet na hindi kailangan ang pagbawas.

Kailan ang mas maliit na MTU ang tamang pagwawasto

Ang klasikong sintomas ay tiyak: natatapos ang handshake ng TCP, dumarating ang maliliit na tugon, at ang malaking download ay natigil o nire-reset. Nabigo ang ping na may bit na huwag-hatiin sa 1472 byte habang nagtagumpay ang ping na 1400 byte, na tumuturo sa landas na hindi kayang magdala ng packet na buong laki at hindi naghahatid ng mensaheng ICMP na magsasabi sa nagpadala na bawasan.

Ang pagtuklas ng MTU ng landas ay nakasalalay sa mga mensaheng ICMP tungkol sa kailangang paghahati. Kapag itinapon ng firewall ang mga iyon, patuloy na sinusubukan ng nagpadala ang malaking packet at ang koneksyon ay tila nakabitin. Ang pagbaba ng MTU sa gilid ng tunnel ay umiiwas sa pag-uulit, at iyon ay lehitimong pagkukumpuni para sa network na iyon.

Nagtatakda rin ng sariling hangganan ang mga teknolohiya ng pag-access: ang PPPoE ay karaniwang humihinto sa 1492, ang ilang landas na mobile at DSL ay mas mababa, at ang mga nested tunnel ay nagbabawas ng overhead nang dalawang beses. Sukatin ang tunay na landas sa halip na kopyahin ang numero mula sa gabay, at tandaan na ang IPv6 ay nangangailangan ng hindi bababa sa 1280 byte na MTU sa bawat link na nagdadala nito, gaya ng tinutukoy ng RFC 8200.

Ihambing ang tatlong kontrol bago magpalit ng isa

Ang MTU, MSS at paghahati ay magkaibang kontrol sa magkaibang layer, at ang pagpalit ng mali ay iniiwan ang sintomas sa puwesto nito.

Ang paglilimita sa MSS ay kadalasang pinakamaliit na nagsasalakay na pagkukumpuni dahil tanging TCP ang naaapektuhan at iniiwan nitong malaya ang interface para sa ibang trapiko. Ang mas mababang MTU ng interface ay mas malawak at mas madaling isipin, kaya karaniwan ito sa mga router ng consumer, ngunit naniningil ito sa bawat protocol ng problema ng isang protocol.

Itinatago ng pagpapahinto sa ugaling huwag-hatiin ang sintomas sa pamamagitan ng pagpayag sa paghahati, at kadalasan ay pinalalala nito ang latency habang sinisira ang feedback na sana ay nakahanap ng tamang laki. Iwasan ito bilang permanenteng pagkukumpuni.

Sukatin ang kompromiso sa halip na isang numero

Hanapin ang hangganan ng landas gamit ang probe na huwag-hatiin, magsimula sa mataas at bumaba hanggang dumating ang tugon:

ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10

Pagkatapos ihambing ang tunay na gawain sa dalawang setting: parehong paglilipat ng file, parehong endpoint at parehong network. Itala ang oras ng pagkumpleto at mga retransmission, halimbawa gamit ang nstat -az TcpRetransSegs, at bantayan ang CPU ng device kung ang tunnel ay nagtatapos sa maliit na router. Ang maikling sintetikong pagsubok ng throughput ay maaaring makaligtaan ang pagtigil na lumilitaw lamang pagkalipas ng ilang megabyte.

Tataas ang mga counter ng packet pagkatapos ng pagbawas dahil ang parehong paglilipat ay gumagamit na ngayon ng mas maraming packet. Iyon ay inaasahan at hindi patunay ng mas mataas na throughput. Ihambing ang natapos na data ng application, bilang ng retransmission at pagtugon, hindi lamang ang rate ng packet.

Ipakilala ang pagbabago nang paunti-unti at panatilihin itong limitado

Itala ang orihinal na halaga, palitan ang isang kontrol, at ulitin ang pagsukat bago gawin itong permanente. Kung hindi nagpapakita ng pakinabang ang ebidensya, ibalik ang dating halaga gamit ang parehong utos ng interface na ginamit mo upang itakda ito:

ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500

Limitahan ang resulta sa network na nangangailangan nito. Ang profile na dapat gumana sa Wi-Fi ng hotel, mobile hotspot at LAN ng opisina ay hindi dapat magmana ng pinakamababang halaga na kailangan ng alinman sa mga iyon, maliban kung hindi matukoy ng client ang landas.

Ang tamang halaga ay ang pinakamalaking MTU na nakakaligtas sa landas, hindi ang pinakamaliit na nagpapawala ng sintomas. Idokumento ang landas, resulta ng probe at rollback, at suriin muli ang setting kapag nagbago ang network ng pag-access.