OpenVPN melalui TCP: rto_min tidak mengatasi tersekat di kepala baris

Shell interaktif melalui terowong membeku selama beberapa saat semasa salinan fail berjalan, kemudian meneruskan seolah-olah tiada apa yang berlaku. Hanya muat turun yang bermasalah, namun shell juga menunggu, dan kedua-duanya pulih pada saat yang sama. Corak itu ialah tandatangan satu aliran boleh dipercayai yang membawa banyak perbualan, dan ia bertahan hampir setiap perubahan penalaan yang dicuba orang dahulu.

Gejala ini wajar dibaca dengan teliti kerana ia menunjuk kepada mekanisme, bukan tetapan: jeda dikongsi, jadi puncanya dikongsi, dan objek yang dikongsi ialah sambungan luar. Segala-galanya dalam log kelihatan normal semasa ia berlaku.

Gejala: semuanya berhenti serentak

Dua sambungan dalam yang tersekat bersama ialah petunjuknya. Muat turun perlahan dan shell perlahan ialah perbualan TCP berasingan dengan nombor jujukan dan keadaan kesesakan berasingan, jadi kerosakan pada satu tidak sepatutnya menyentuh yang lain. Apabila kedua-duanya berhenti serentak, sesuatu di atasnya sedang menyusun bita mereka.

Sesuatu itu ialah pengangkutan terowong. Dalam mod TCP, OpenVPN menulis paket berkapsul ke dalam satu sambungan TCP ke rakan sebaya, dan kontrak TCP ialah penghantaran mengikut urutan bagi satu aliran bita. Bita kemudian tidak diserahkan kepada aplikasi sebelum yang hilang, tidak kira perbualan dalam mana ia tergolong.

Perhatikan apa yang gejala tidak katakan. Ia tidak mengatakan laluan rosak, pelayan terlebih beban, atau penyulitan perlahan. Itu menghasilkan bentuk lain: daya pemprosesan rendah sekata, tamat masa, atau kegagalan yang menjejaskan satu arah. Jeda dikongsi yang berakhir apabila segmen hilang dihantar semula ialah khususnya kesan susunan.

Satu aliran bita luar, banyak perbualan dalam

Bayangkan terowong membawa muat turun dan shell pada masa yang sama. Satu segmen sambungan luar hilang. Segmen berikutnya mungkin tiba di hos penerima, dan tindanan TCP penerima akan mengakuinya, tetapi ia tidak boleh menyerahkannya ke atas sehingga jurang diisi. Jadi OpenVPN tiada apa-apa untuk dibaca bagi shell, walaupun bita shell itu sendiri tiba lama dahulu.

Ini ialah tersekat di kepala baris dalam satu sambungan, dan ia tidak memerlukan kedua-dua aplikasi berkongsi sambungan dalam. Mereka berkongsi yang luar, dan itu sudah cukup.

Kesan peringkat kedua menjadikannya lebih teruk. Penghantar dalam yang tidak melihat pengesahan mungkin menghantar semula data yang lapisan luar sudah cuba hantar. Penghantaran semula itu menjadi trafik terowong tambahan pada laluan yang baru membuktikan ia boleh kehilangan segmen, jadi kerja pemulihan bersaing dengan pemulihan yang penting.

Tiada satu pun daripada ini menjamin keruntuhan. Pada laluan bersih dengan perjalanan pergi balik pendek dan baris gilir lapang, susunan ini boleh digunakan sepenuhnya selama bertahun-tahun. Kegagalan muncul apabila kehilangan, kelewatan dan kedalaman baris gilir bertemu, dan itulah sebabnya laporan berkumpul di sekitar pautan atas yang sesak dan pautan mudah alih, bukan di sekitar pejabat yang lengkap.

Mengapa pemasa dalam yang lebih panjang tidak dapat membantu

Menaikkan tamat masa penghantaran semula minimum pada laluan dengan rto_min menangguhkan penghantaran semula berasaskan pemasa bagi trafik TCP yang dijana secara setempat yang menggunakan laluan itu. Ia ialah tombol sebenar dengan kesan sebenar, dan ia menangani masalah peringkat kedua dan bukan yang pertama.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

Apa yang tidak boleh dilakukannya ialah melepaskan bita luar di luar urutan, memulihkan segmen hilang dengan lebih pantas, atau membuat pelayan aplikasi jauh menggunakan pemasa yang sama. Tindanan penerima tetap menghantar mengikut urutan, dan penghantar di hujung jauh tetap menggunakan ukuran perjalanan pergi baliknya sendiri.

Ia juga tidak mematikan setiap mekanisme pemulihan kehilangan yang lain. Di mana kehilangan sebenar memerlukan pemulihan berasaskan pemasa, minimum yang lebih besar membuat aplikasi menunggu lebih lama sebelum bertindak, iaitu bertentangan dengan apa yang diperlukan sesi peka kependaman.

Paras bawah tetap dua belas saat muncul dalam nasihat tentang topik ini seolah-olah kewujudan terowong TCP mengandaikannya. Pemasa penghantaran semula yang diterangkan dalam RFC 6298 diterbitkan daripada masa perjalanan pergi balik yang diukur dengan pengunduran eksponen, jadi paras bawah malar ialah pilihan dasar untuk laluan tertentu dan bukan keperluan protokol. Apabila digunakan secara meluas, ia menyembunyikan gejala sambil mengubah pemulihan bagi setiap aliran yang dilindungi laluan itu.

Apa yang tcp-nodelay lakukan dan tidak lakukan

Pilihan terowong yang mematikan penimbalan gaya Nagle pada soket pengangkutan mempunyai tujuan sempit: ia menghalang tulisan kecil daripada menunggu lebih banyak data sebelum penghantaran. Itu membantu trafik interaktif mengelakkan kelewatan tambahan pada laluan yang sebaliknya sihat.

Ia tidak menjadikan pengangkutan tidak tersusun, dan tidak memendekkan pemulihan selepas segmen hilang. Shell yang berhenti kerana tamat masa penghantaran semula akan tetap berhenti dengan pilihan itu dihidupkan, kerana pilihan itu tidak pernah menyentuh peraturan susunan.

Mudah mengelirukan kedua-duanya kerana kedua-duanya diterangkan sebagai pembaikan kependaman. Satu membuang tunggu buatan yang diperkenalkan penimbalan, yang lain memerlukan perubahan pada apa yang dijamin pengangkutan, dan tiada pilihan soket melakukannya.

Cara membandingkan pengangkutan secara adil

Jika pengendali membenarkannya dan kedua-dua perkhidmatan wujud, bandingkan perkhidmatan UDP dan perkhidmatan TCP yang membawa beban kerja yang sama melalui laluan akses yang sama ke pelayan yang sama. Menukar negara, pembekal atau generasi pelayan antara dua ujian memasukkan pemboleh ubah yang akan menguasai keputusan.

Perhatikan jeda dikongsi dan bukan angka daya pemprosesan. Beberapa aplikasi dalam tersekat bersama semasa kehilangan luar ialah pemerhatian yang mengenal pasti tersekat di kepala baris; satu angka ujian kelajuan yang lebih rendah tidak.

Tangkapan dibenarkan pada antara muka terowong dan pada antara muka fizikal memisahkan kedua-dua lapisan dengan bersih, kerana penghantaran semula dalam dan luar tergolong dalam sambungan berbeza dengan ruang jujukan berbeza. Melihat penghantaran semula dalam sementara aliran luar menunjukkan jurang ialah bukti langsung.

Beralih kepada UDP membuang aliran boleh dipercayai tambahan dan membiarkan TCP dalam melakukan pemulihannya sendiri. Ia tidak menjanjikan sifar kehilangan atau kependaman rendah, dan pautan atas yang tepu, baris gilir terlalu besar atau masalah MTU masih perlu dibaiki. Trafik di luar terowong tidak pernah ditahan di belakang jurang jujukan terowong, walaupun ia masih boleh menderita apabila kedua-dua laluan berkongsi satu pautan sesak, dan kesesakan dikongsi itu wajar disiasat sendiri dan bukan dilipat ke dalam ini.