VPN-ээр файл хуваалцах яагаад удаан мэт санагддаг вэ: Mbps биш, харин тойрог

VPN-ээр хуваалцсан хавтас нээж, лавлахын жагсаалт мөлхөж урагшлахыг хүлээх нь танил туршлага бөгөөд эхний зөн совин зурвасын өргөнийг буруутгах явдал юм. Ихэвчлэн холбоос бараг ажилгүй байдаг. Протокол цагаа хариу хүлээхэд зарцуулдаг бөгөөд хүлээлт бүр локал сүлжээ хэзээ ч тооцоогүй бүтэн тойрог зарцуулдаг. Ажлын хэлбэрийг зас, хуваалцалт дахин хэрэглэгдэх болно.

Алсын ажлын хуулбар буруу хэлбэртэй

SMB файл нээж, мета өгөгдөл уншиж, олон жижиг солилцоогоор баталгаажуулдаг. Холбогдсон диск дээрх хувилбарын хяналтын ажлын хуулбар локал файлын системийн саатал гэж үзэж, олон жижиг файл уншдаг. Ширээний өгөгдлийн сан хэрэглэгч ажиллаж байхдаа хуудсыг татдаг. Эдгээр нь тус бүр саатлыг үржүүлэгч болгодог, учир нь зардал үйлдлийн хийх солилцооны тоотой хамт өсдөг; тиймээс 40 ms-ийн туннель хэдэн зуун үйлдлийг хэдэн секунд болгодог. Тэр тооцоонд ачааны хэмжээ бараг хамаагүй.

Шифрлэлтийн нэмэлт зардал нь үүний багахан хэсэг; алдагдал илүү муу, учир нь нэг дахин дамжуулалт ба нурангидсан түгжрэлийн цонх оролцсон байтуудаас хамаагүй илүү үнэтэй.

Мегабайтаас өмнө тойргийг тоол

Багтаамж худалдаж авахаас өмнө саатлыг хэмж. Нэг ping солилцоо бүр юу төлдөгийг хэлнэ.

ping -c 10 fileserver.example.net

Хураангуй хамгийн бага, дундаж, хамгийн их тойргийн цагийг өгдөг бөгөөд тархалт дундажтай адил чухал. Дунджийг лавлахын жагсаалтын хийх солилцооны тоогоор үржүүлээд, бодитоор ажиглаж буй цагтай харьцуул. Хэрэв нэг том файл хурдан дамжиж, үзэх нь удаан бол хязгаар нь саатал ба хүсэлтийн тоо юм. Хэзээ ч дүүрдэггүй холбоост арав дахин багтаамж нэмэх нь юу ч өөрчлөхгүй.

Байтуудыг биш, ажлыг зөө

Илүү өргөн хоолойд төлөхийн оронд ажил хаана болохыг өөрчил. Агуулахыг холбохын оронд үйлчилж, зөвхөн ялгааг илгээдэг хэрэгслээр бөөнөөр хуул.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Агуулахад үйлчлэх нь hgweb эсвэл алсын Git-ийн адил клиентэд локал клон дээр ажиллах боломж олгодог тул файлын системийн дуудлагууд туннелийг хэзээ ч давахгүй. rsync хоёр талыг тойрч, өөрчлөгдсөн блокуудыг илгээдэг бөгөөд энгийн хуулбарын төлдөг ихэнх солилцоог арилгадаг. Ширээний өгөгдлийн сан серверийн талын хөдөлгүүрт байх ёстой, клиент нь урд талын интерфэйс болж хумигдана, эсвэл бүх клиент дотоод хост дээр ажиллана. Сонголт бүр протокол хэр их сааталд өртөхийг өөрчилдөг бөгөөд энэ нь гол зүйл юм.

Ижил хэмжээний дэргэд гацах нь MTU-ийн шинж

ping болон жижиг хуудсууд ажиллаж байхад ойролцоогоор ижил хэмжээний өгөгдлийн дараа зогсдог том дамжуулалт нь зурвасын өргөнийг биш, пакетийн хэмжээг заана.

ping -M do -s 1400 -c 3 fileserver.example.net

Амжилттай туршилт нь 1428 байтын IP пакет замд хуваагдахгүй гарахыг илтгэнэ, учир нь ICMP ба IP толгойнууд 28 байт нэмдэг. Хуваахыг хориглох тугтай алдаа нь туннелийн ашиглах боломжтой MTU серверийн таамаглаж байгаагаас бага гэдгийг харуулна. 9000 байтын буферыг 1500 байтын замд илгээдэг сервер хуваалт эсвэл алдагдалд хүргэдэг бөгөөд ICMP шүүгдэх үед замын MTU-г олдох нь чимээгүй бүтэлгүйтэж болно. Туннелийн MTU-г бууруул, асаа mssfix OpenVPN дотор, эсвэл серверийн буферыг багасга, дараа нь баталгаажуулахын тулд мөнөөх дамжуулалтыг дахин ажиллуул.

Ач холбогдолтой зөрүүг хэмж

Бодлого зөвшөөрсөн газар мөнөөх үйлдлийг гурван аргаар хий: локал, туннелээр, шууд интернэт замаар. Тус бүрд тойргийн цаг, нэг том урсгалын хурд, лавлахын жагсаалт эсвэл програмыг нээхэд хэр их цаг орохыг бич. Локал гүйцэтгэлийг туннелээр гүйцэтгэлтэй харьцуулах нь аль зардал давамгайлж байгааг харуулна. Удаан дуусаж буй хуулбар нь хурд эсвэл саатлын асуудлыг заана, харин тогтмол цэг дээр үхэж буй хуулбар нь пакетийн хэмжээ эсвэл замд төлөв хадгалдаг төхөөрөмжийг заана.

Зөвхөн эхний мегабайтууд чирэгдэж байвал нэвтрүүлэлт ба мета өгөгдлийг хар; бүгд мөлхөж байвал багтаамж ба алдагдлыг хар. Тохирох шалтгааныг засаж, WAN холбоос локал сүлжээний кабель мэт авирлана гэж хүлээхээ болино.