VPN fayl paylaşımı niyə yavaş görünür: Mbps yox, gediş-dönüşlər

VPN üzərindən paylaşılan qovluğu açmaq və kataloq siyahısı sürünərkən gözləmək tanış təcrübədir, ilk instinkt isə bant genişliyini günahlandırmaqdır. Adətən əlaqə demək olar ki, boşdur. Protokol vaxtını cavab gözləməklə keçirir və hər gözləmə LAN-ın heç vaxt tutmadığı tam bir gediş-dönüşə başa gəlir. İşin formasını düzəldin, paylaşım yenidən istifadəyə yararlı olar.

Uzaqdakı işçi nüsxə yanlış formadadır

SMB faylları açır, metadatanı oxuyur və çoxlu kiçik mübadilələrdə təsdiq verir. Xəritələnmiş diskdə versiya nəzarəti işçi nüsxəsi yerli fayl sistemi gecikməsini nəzərdə tutur və çoxlu kiçik fayl oxuyur. Masaüstü verilənlər bazası istifadəçi işləyərkən səhifələri çəkir. Bunların hər biri gecikməni çarpanə çevirir, çünki xərc əməliyyatın etdiyi mübadilə sayı ilə artır; buna görə 40 ms-lik tunel bir neçə yüz əməliyyatı bir neçə saniyəyə çevirir. Yükün ölçüsü bu hesablamada demək olar ki, əhəmiyyətsizdir.

Şifrələmə yükü bunun kiçik hissəsidir; itki daha pisdir, çünki bir təkrar ötürmə və dağılmış sıxlıq pəncərəsi məsələdəki baytlardan qat-qat bahadır.

Meqabaytlardan əvvəl gediş-dönüşləri sayın

Tutum almazdan əvvəl gecikməni ölçün. Bir ping hər mübadilənin nə ödədiyini deyir.

ping -c 10 fileserver.example.net

Xülasə minimum, orta və maksimum gediş-dönüş vaxtlarını verir və yayılma orta qədər vacibdir. Ortalamanı kataloq siyahısının etdiyi mübadilə sayına vurun, sonra müşahidə etdiyiniz vaxtla müqayisə edin. Bir böyük fayl sürətli ötürülürsə, gəzinti isə yavaşdırsa, məhdudiyyət gecikmə və sorğu sayıdır. Heç vaxt dolmayan əlaqəyə on qat tutum əlavə etmək heç nəyi dəyişmir.

Baytları deyil, işi köçürün

Daha çox boru üçün pul vermək yerinə işin baş verdiyi yeri dəyişin. Repozitoriyanı montaj etmək yerinə onu xidmət kimi verin və yalnız fərqləri göndərən alətlə toplu surətdə kopyalayın.

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

Repozitoriyanı hgweb və ya uzaq Git kimi xidmət kimi vermək müştəriyə yerli klonda işləməyə imkan verir, beləliklə fayl sistemi çağırışları tuneldən heç vaxt keçmir. rsync hər iki tərəfi gəzir və dəyişmiş blokları göndərir, sadə kopyanın ödədiyi mübadilələrin çoxunu aradan qaldırır. Masaüstü verilənlər bazasının yeri server tərəfli mühərrikdir, müştəri isə ön panelə endirilir, ya da bütün müştəri daxili hostda işləyir. Hər variant protokolun hansı qədər gecikməyə məruz qaldığını dəyişir və məqsəd də budur.

Eyni ölçü yaxınlığında donmalar MTU simptomudur

Təxminən eyni həcmdə datadan sonra dayanan, ping və kiçik səhifələrin isə işlədiyi böyük ötürmələr bant genişliyinə deyil, paket ölçüsünə işarə edir.

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

Uğurlu sınaq 1428 baytlıq IP paketinin yolu fraqmentasiyasız keçdiyini bildirir, çünki ICMP və IP başlıqları 28 bayt əlavə edir. Fraqmentasiya etmə bayrağı ilə uğursuzluq tunelin istifadə oluna bilən MTU-nun serverin fərz etdiyindən kiçik olduğunu göstərir. 9000 baytlıq buferləri 1500 baytlıq yola göndərən server fraqmentasiya və ya itkilərə məcbur edir və ICMP süzgəcdən keçirildikdə yol MTU kəşfi səssizcə uğursuz ola bilər. Tunelin MTU-nu aşağı salın, aktivləşdirin mssfix OpenVPN-də, ya da server buferlərini kiçildin, sonra təsdiqləmək üçün eyni ötürməni yenidən işə salın.

Əhəmiyyətli olan fərqi ölçün

Siyasət icazə verdiyi yerdə eyni əməliyyatı üç yolla aparın: yerli, tunel üzərindən və birbaşa internet yolu ilə. Hər biri üçün gediş-dönüş vaxtını, bir böyük axının sürətini və kataloq siyahısının və ya tətbiqin açılmasının nə qədər çəkdiyini qeyd edin. Yerli işə salmanı tunel işə salması ilə müqayisə etmək hansı xərcin üstün olduğunu göstərir. Yavaş bitən kopya sürət və ya gecikmə probleminə işarə edir, sabit nöqtədə ölən kopya isə paket ölçüsünə və ya yolda vəziyyət saxlayan cihaza işarə edir.

Yalnız ilk meqabaytlar sürünəndə autentifikasiya və metadataya baxın; hər şey sürünəndə tutuma və itkiyə baxın. Uyğun səbəbi düzəldin və WAN əlaqəsinin LAN kabeli kimi davranmasını gözləməyi dayandırın.