OpenVPN TCP dayanmaları: rto_min başlıq sırası bloklanmasını həll etmir
Xarici bayt axını sıra ilə çatdırır, ona görə bir itkin seqment hər daxili axını dayandıra bilər. Daha uzun daxili taymer saatı dəyişir, bu məhdudiyyəti yox.
Tunnel üzərindəki interaktiv shell fayl kopyalanması gedərkən bir neçə saniyə donur, sonra heç nə olmamış kimi davam edir. Problemi olan yeganə şey yükləmədir, amma shell də gözləyir və hər ikisi eyni anda bərpa olunur. Bu naxış bir çox söhbəti daşıyan bir etibarlı axının imzasıdır və insanların ilk sınadığı demək olar ki, hər tənzimləmə dəyişikliyinə davam edir.
Simptomu diqqətlə oxumağa dəyər, çünki o, parametrə deyil, mexanizmə işarə edir: fasilə ortaqdır, deməli səbəb ortaqdır və ortaq obyekt xarici bağlantıdır. Bu baş verərkən logdakı hər şey normal görünür.
Simptom: hər şey eyni anda dayanır
İki daxili bağlantının birlikdə dayanması ipucudur. Yavaş yükləmə və yavaş shell ayrı ardıcıllıq nömrələri və ayrı tıxanma vəziyyəti olan ayrı TCP söhbətləridir, ona görə birindəki nasazlıq digərinə toxunmamalıdır. Onlar eyni templə dayandıqda, onların üstündə nəsə baytlarını sıralayır.
O nəsə tunnelin nəqliyyat qatıdır. TCP rejimində OpenVPN qablaşdırılmış paketləri peer-ə bir TCP bağlantısı ilə yazır və TCP-nin müqaviləsi tək bayt axınının sıra ilə çatdırılmasıdır. Sonrakı baytlar hansı daxili söhbətə aid olmalarından asılı olmayaraq, itkin olanlardan əvvəl tətbiqə verilmir.
Simptomun sizə nə demədiyinə diqqət edin. O, yolun pozulduğunu, serverin həddindən artıq yükləndiyini və ya şifrənin yavaş olduğunu demir. Bunlar başqa formalar yaradır: bərabər aşağı ötürmə qabiliyyəti, timeout-lar və ya bir istiqamətə təsir edən nasazlıqlar. İtirilmiş bir seqment yenidən ötürüldükdə bitən ortaq fasilə məhz sıralama effektidir.
Bir xarici bayt axını, çoxlu daxili söhbət
Tunnelin eyni anda həm yükləmə, həm də shell daşıdığını təsəvvür edin. Xarici bağlantının bir seqmenti itir. Sonrakı seqmentlər qəbuledici hosta çata bilər və qəbuledici TCP stack onları təsdiqləyəcək, lakin boşluq doldurulana qədər onları yuxarı çatdıra bilməz. Buna görə OpenVPN-in shell üçün oxuyacaq heç nəsi yoxdur, halbuki shellin öz baytları çoxdan çatıb.
Bu, bir bağlantı daxilində başlıq sırası bloklanmasıdır və iki tətbiqin daxili bağlantını paylaşmasını tələb etmir. Onlar xarici olanı paylaşır və bu kifayətdir.
İkinci dərəcəli effekt vəziyyəti pisləşdirir. Təsdiq görməyən daxili göndərən, xarici qatın artıq çatdırmağa çalışdığı məlumatları yenidən ötürə bilər. Bu yenidən ötürmə, seqment itirə bildiyini yenicə sübut edən yolda əlavə tunnel trafikinə çevrilir, ona görə bərpa işi vacib olan bərpa ilə rəqabət edir.
Bunların heç biri çökməyə zəmanət vermir. Qısa gediş-dönüş vaxtları və geniş növbələri olan təmiz yolda bu düzüm illərlə tamamilə yararlı ola bilər. Nasazlıq itki, gecikmə və növbə dərinliyi üst-üstə düşdükdə görünür; buna görə hesabatlar yaxşı təchiz olunmuş ofislərdən çox tıxanmış uplink və mobil bağlantılar ətrafında toplanır.
Niyə daha uzun daxili taymer kömək edə bilməz
Bir marşrutda minimum yenidən ötürmə timeoutunu rto_min ilə artırmaq, həmin marşrutdan istifadə edən yerli yaradılmış TCP trafiki üçün taymerə əsaslanan yenidən ötürməni gecikdirir. Bu, real təsiri olan real bir düymədir və birinci deyil, ikinci dərəcəli problemi həll edir.
ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1
Edə bilmədiyi şey xarici baytları sıradan kənar buraxmaq, itkin seqmenti daha tez bərpa etmək və ya uzaq tətbiq serverini eyni taymeri qəbul etməyə məcbur etməkdir. Qəbuledici stack hələ də sıra ilə çatdırır və uzaq tərəfdəki göndərən hələ də öz gediş-dönüş ölçmələrindən istifadə edir.
O, həmçinin hər digər itki-bərpa mexanizmini söndürmür. Həqiqi itki taymerə əsaslanan bərpa tələb etdikdə, daha böyük minimum tətbiqi hərəkət etməzdən əvvəl daha çox gözlədir, bu da gecikməyə həssas sessiyanın ehtiyacının əksidir.
Bu mövzuda verilən məsləhətlərdə on iki saniyəlik sabit döşəmə, sanki TCP tunnelinin mövcudluğu bunu tələb edirmiş kimi görünür. RFC 6298-də təsvir olunan yenidən ötürmə taymeri ölçülmüş gediş-dönüş vaxtından eksponensial geri çəkilmə ilə törəyir, ona görə sabit döşəmə protokol tələbi deyil, konkret yol üçün siyasət seçimidir. Geniş tətbiq edildikdə simptomu gizlədir, eyni zamanda həmin marşrutun əhatə etdiyi hər axın üçün bərpanı dəyişir.
tcp-nodelay nə edir və nə etmir
Nəqliyyat soketində Nagle tipli buferləməni söndürən tunnel seçiminin dar məqsədi var: kiçik yazıların ötürmədən əvvəl daha çox məlumat gözləməsinin qarşısını alır. Bu, interaktiv trafikin başqa cür sağlam yolda əlavə gecikmədən yayınmasına kömək edir.
O, nəqliyyatı sırasız hala çevirmir və itirilmiş seqmentdən sonra bərpanı qısaltmır. Yenidən ötürmə timeoutu üçün dayanan shell həmin seçim aktiv olsa da dayanacaq, çünki seçim sıralama qaydasına heç vaxt toxunmayıb.
İkisini qarışdırmaq asandır, çünki hər ikisi gecikmə düzəlişi kimi təsvir olunur. Biri buferləmənin gətirdiyi süni gözləməni aradan qaldırır; digəri nəqliyyatın nəyə zəmanət verdiyini dəyişməyi tələb edərdi, heç bir soket seçimi bunu etmir.
Nəqliyyatları necə ədalətli müqayisə etmək olar
Operator buna icazə verirsə və hər iki xidmət varsa, eyni iş yükünü daşıyan UDP xidməti ilə TCP xidmətini eyni serverə eyni giriş yolu üzərindən müqayisə edin. İki test arasında ölkəni, provayderi və ya server nəslini dəyişmək nəticəyə hökm edəcək bir dəyişən gətirir.
Ötürmə qabiliyyəti rəqəminə deyil, ortaq fasiləyə baxın. Xarici itki zamanı bir neçə daxili tətbiqin birlikdə dayanması başlıq sırası bloklanmasını müəyyən edən müşahidədir; tək bir aşağı sürət testi rəqəmi bunu etmir.
Tunnel interfeysində və fiziki interfeysdə icazəli tutmalar iki qatı təmiz ayırır, çünki daxili və xarici yenidən ötürmələr fərqli ardıcıllıq fəzaları olan fərqli bağlantılara aiddir. Xarici axın boşluq göstərərkən daxili yenidən ötürmələri görmək birbaşa sübutdur.
UDP-yə keçmək əlavə etibarlı axını aradan qaldırır və daxili TCP-nin öz bərpasını etməsinə imkan verir. O, sıfır itki və ya aşağı gecikmə vəd etmir və doymuş uplink, həddindən böyük növbələr və ya MTU problemi hələ də düzəldilməlidir. Tunnel xaricindəki trafik heç vaxt tunnelin ardıcıllıq boşluğunun arxasında saxlanmır, baxmayaraq ki, hər iki yol bir tıxanmış keçid paylaşdıqda o hələ də əziyyət çəkə bilər və bu ortaq darboğaz bu araşdırmaya qatılmaq əvəzinə öz araşdırmasına layiqdir.