Dalam keadaan apa kinerja TCP-over-TCP jauh lebih buruk daripada TCP saja (2014)?

Banyak admin terus mengabadikan - di ServerFault dan di tempat lain - seberapa buruk ide TCP-over-TCP, misalnya dalam VPN. Bahkan kehilangan paket sekecil apa pun akan membuat seseorang menderita setidaknya degradasi throughput yang parah jika bukan TCP meltdown, dan karena itu TCP-over-TCP harus dihindari secara ketat. Dan itu mungkin sekali semuanya benar, misalnya tahun 2001 ketika artikel ini ditulis yang masih dirujuk.

Namun sejak itu kami telah melihat kemajuan besar dalam teknologi dan protokol. Saat ini kami telah menerapkan 'Selektif ACK' hampir di mana-mana, dan hukum Moore telah memberi kami lebih banyak memori, dan dengan itu muncul buffer TCP besar dioptimalkan untuk uplink Gbit. Kehilangan paket juga jauh dari masalah akhir-akhir ini pada tautan non-radio. Semua ini harus meringankan masalah TCP-over-TCP secara signifikan, bukan?

Perhatikan bahwa ada skenario dunia nyata di mana misalnya VPN berbasis TCP lebih mudah diimplementasikan dan dioperasikan daripada yang berbasis UDP / ESP (lihat lebih lanjut di bawah). Karena itu pertanyaan saya:

Dalam keadaan apa (kehilangan paket latensi & latensi) adalah TCP-over-TCP berperforma lebih buruk secara signifikan dibandingkan dengan TCP saja, dengan asumsi dukungan SACK dan buffer TCP berukuran layak di kedua ujungnya?

Akan sangat bagus jadi lihat beberapa pengukuran yang menunjukkan korelasi antara (koneksi luar) packet loss / latency, dan (koneksi internal) throughput / jitter - untuk TCP-over-TCP, dan untuk TCP saja. Saya menemukan artikel yang menarik ini , tetapi tampaknya hanya memperhatikan latensi, dan tidak membahas kehilangan paket (luar).

Juga: Apakah ada pengaturan yang disarankan (misalnya opsi TCP, pengaturan buffer, pengurangan MTU / MSS, dll) untuk mempersempit kesenjangan kinerja antara TCP dan TCP-over-TCP?

Pembaruan: Dasar pemikiran kami.

Pertanyaan ini masih sangat relevan dalam beberapa skenario dunia nyata. Misalnya, kami menyebarkan perangkat tertanam di bangunan besar yang mengumpulkan data sensor dan memasukkannya ke platform kami melalui VPN. Masalah yang kita hadapi adalah firewall dan uplink yang dikonfigurasi dengan tidak benar, yang tidak berada di bawah kendali kita, dikombinasikan dengan departemen TI yang enggan. Lihat contoh rinci yang dibahas di sini .

Dalam banyak kasus seperti itu, beralih dari non-TCP ke VPN berbasis TCP (sangat mudah jika Anda menggunakan OpenVPN seperti kami) adalah perbaikan cepat yang memungkinkan kami menghindari pertarungan yang mengarah ke jari. Misalnya sering port TCP 443 umumnya diperbolehkan (setidaknya melalui proxy), atau kita dapat mengatasi masalah Path-MTU dengan hanya mengurangi opsi MSS TCP.

Akan baik untuk mengetahui dalam keadaan apa VPN berbasis TCP dapat dianggap sebagai alternatif yang layak, sehingga kita dapat membuat keputusan berdasarkan informasi yang lebih baik daripada pro dan kontra dari opsi mana pun. Sebagai contoh, kita tahu bahwa TCP-VPN tidak masalah bagi kita pada tautan non-radio, tetapi kita memiliki cukup banyak klien jarak jauh pada uplink 3G dengan kehilangan paket yang signifikan dan latensi tinggi - bagaimana kinerja TCP-VPN di sana?

Saya mencoba untuk meningkatkan judul dan pertanyaan utama sesuai; Saya harap ini masuk akal.

— Nils Toedtmann
sumber

Anda akan dengan cepat melihat perbedaan antara TCP lebih TCP vs UDP (dll) lebih dari TCP VPN ketika menggunakannya untuk sesi interaktif, misalnya ssh. Anda akan melihat latensi jika sesi tidak turun. YMMV, TIAS

— Daniel S. Sterling

Hanya jika koneksi 'luar' tunduk pada tingkat latensi atau kehilangan paket tertentu di tempat pertama. Saya memiliki banyak sesi SSH melalui VPN berbasis TCP, dan banyak yang berfungsi dengan baik tanpa jeda waktu yang nyata.

— Nils Toedtmann

Memang - itu berfungsi ketika Anda memiliki jaringan yang bagus. Jika Anda tidak selalu memiliki jaringan yang baik, itu tidak selalu berhasil

— Daniel S. Sterling

Apa itu jaringan yang baik? Jika semuanya berjalan dalam satu wilayah AWS, apakah jaringannya cukup baik?

— Pengingat kaya

Saya pikir itu sebenarnya lebih diperdebatkan daripada Anda membuatnya muncul. Ada FAQ Linux yang diakui dan terkait lama: http://www.tldp.org/HOWTO/VPN-HOWTO/

Saya telah menggunakan PPP-over-ssh-over-ADSL selama lebih dari 12 tahun, dan itu tidak pernah mengecewakan saya, jadi dari pengalaman saya, saya berani mengatakan bahwa para doomsayer kemungkinan besar melebih-lebihkan. TCP over TCP mungkin merupakan ide yang buruk dengan koneksi RTC, tautan satelit dan tautan lain dengan throughput yang sangat rendah atau penundaan yang sangat lama, tetapi untuk sebagian besar menggunakannya hanya berfungsi .

Sekarang pertanyaan sebenarnya adalah: mengapa Anda menggunakan TCP lebih dari TCP sama sekali ? Ketika saya mengatur PPP-over-ssh saya, itu sebagian besar karena saat itu itu adalah cara termudah untuk membangun VPN cepat; maka saya sudah menggunakannya sejak kemalasan belaka.

Saat ini ada alat yang praktis dan mudah diatur seperti OpenVPN, IPSec VPN sehingga Anda tidak perlu repot dengan masalah TCP-over-TCP ini.

— wazoox
sumber

Ada situasi di mana TCP-over-TCP adalah perbaikan sederhana untuk sejumlah masalah jaringan. Saya menambahkan bagian yang menjelaskan alasan kami.

— Nils Toedtmann

Saya berharap jawaban yang lebih spesifik tentang kondisi di mana TCP-over-TCP menjadi masalah. Salah satu kasus penggunaan kami adalah tautan radio yang memiliki berbagai tingkat latensi dan kehilangan paket.

— Nils Toedtmann

TCP over TCP over TCP (lalu lintas TCP dalam OpenVPN TCP yang diakses melalui maju SSH TCP) harganya sekitar 5Mb / s. Itu tidak pernah mengecewakan saya, tetapi saya tidak akan merekomendasikannya hanya karena itu adalah pemborosan besar.

— Sirene