Unduhan Besar vs VPN: Pilih Jalur saat Permintaan

“Kirim unduhan besar melewati VPN dan biarkan balasan kecil tetap di atasnya” terdengar seperti kebijakan perutean, tetapi bukan. Router memutuskan dengan informasi yang tersedia pada saat itu: alamat, port, protokol, tanda firewall, alur yang teridentifikasi. Ukuran akhir sebuah respons tidak ada dalam himpunan itu, karena belum tiba, dan ketika router bisa mengukur byte-nya, ia sudah mengangkutnya. Jika Anda ingin pengarahan per tugas, keputusan harus pindah ke titik yang mengenal tugas itu, dan daftar periksa di bawah menunjukkan apakah rancangan Anda punya titik semacam itu.

Mengapa router tidak bisa mengukur respons

Pada saat sebuah paket membutuhkan rute, router paling banyak telah melihat beberapa paket pertama dari suatu alur. Ia bisa mengatakan siapa berbicara dengan siapa, lewat protokol apa, dengan tanda apa, dan berapa byte yang sudah lewat. Byte sejauh ini menggambarkan masa lalu. Ukuran balasan adalah sifat respons yang belum dihasilkan, dan pada respons terpotong atau streaming mungkin tidak akan pernah bisa diketahui sebelumnya.

Bahkan metadata protokol itu sendiri lebih lemah daripada kelihatannya. HTTP mengizinkan respons yang panjangnya tidak diumumkan sebelum badan, dan satu tindakan pengguna bisa menghasilkan banyak permintaan yang biaya gabungannya tidak menyerupai nilai header mana pun. Memperlakukan header sebagai ukuran tugas adalah kesalahan pemodelan sebelum menjadi kesalahan perutean.

Pemeriksaan 1: adakah titik keputusan yang bisa memilih jalur?

Sebutkan komponen yang akan membuat pilihan, lalu sebutkan apa yang ia ketahui pada saat memilih. Pembaru yang mengambil dari kumpulan host terdokumentasi mengetahui tujuannya sebelum transfer dimulai. Layanan unduhan yang memeriksa metadata lalu membuka permintaan mengetahui tugas itu sebelum koneksi ada. Proxy yang bekerja sama bisa menerapkan kebijakan tingkat permintaan atau menyimpan respons di cache tanpa berpura-pura menjadi router.

Jika jawabannya “gateway”, daftar periksa sudah gagal. Gateway bisa mengklasifikasikan alur yang dikenal berdasarkan tujuan, tanda, atau segmen klien dan mengirimnya ke jalur yang ditentukan sejak paket pertama, yang sering cukup untuk pembaru yang disetujui dan tidak pernah cukup untuk ukuran respons yang tidak diketahui.

Pemeriksaan 2: apa yang sebenarnya dikatakan metadata?

Pengarahan yang sadar aplikasi hanya sebaik field yang dibacanya. Aturan panjang respons di semantik HTTP mengizinkan kasus ketika panjang tidak tersedia di awal, dan pengodean konten membuat jumlah byte yang ditransfer tetap berbeda dari ukuran representasi. Karena itu kebijakan yang berpindah jalur saat header melewati ambang akan berperilaku tidak konsisten, dan terutama justru pada transfer besar yang seharusnya ditangkapnya.

Yang bisa didukung metadata aplikasi adalah keputusan tentang tugas: alur kerja ini adalah sinkronisasi massal, ini interaktif, ini pembaruan perangkat lunak dari asal yang dikenal. Itu kebijakan yang ditulis dalam istilah niat, dan cukup stabil untuk diuji. “Respons ini akan lebih besar dari empat puluh megabita” bukan kebijakan seperti itu.

Pemeriksaan 3: apakah alurnya sudah ada?

Perutean bisa berubah untuk suatu alur tanpa mengubah identitas koneksi, dan perbedaan itu layak dijaga dengan benar. Koneksi TCP diidentifikasi oleh alamat dan port ujungnya, dan paket bisa mengambil jalur berbeda jika tabel perutean berubah di bawahnya. Yang tidak bisa berubah secara tak terlihat adalah status terjemahan alamat jaringan: memindahkan lalu lintas ke jalan keluar lain biasanya mengubah tuple sumber publik, dan ujung jauh akan melihat rekan yang berbeda tanpa status yang cocok.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Jadi aturan praktisnya adalah perpindahan di tengah koneksi dari satu jalan keluar ke jalan keluar lain merupakan hubungan baru, bukan migrasi. Jika rancangan menuntut koneksi yang sama berlanjut, keputusan harus diambil sebelum SYN pertama, dan tidak ada aturan paket yang ditambahkan kemudian dapat merekonstruksinya dengan bersih.

Pemeriksaan 4: apakah kebutuhan sebenarnya latensi, bukan jalan keluar?

Sangat banyak permintaan “kirim lalu lintas massal ke tempat lain” sebenarnya keluhan bahwa transfer besar membuat pekerjaan interaktif terasa lambat. Itu masalah penjadwalan, dan ada jawaban penjadwalannya: antrean adil atau kebijakan bandwidth yang didukung pada jalur yang ada mencegah alur massal membuat pesan obrolan kelaparan tanpa memindahkan salah satunya.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Menangani gejala dengan cara ini menjaga keputusan jalan keluar di tempat kebijakan keamanan meletakkannya, dan bisa dibalik dengan satu perintah. Mengubah jalan keluar untuk seluruh kelas lalu lintas adalah perubahan kebijakan dengan konsekuensi autentikasi, pencatatan, dan aturan akses, jadi seharusnya bukan alat pertama saat ada keluhan latensi.

Jika persyaratannya benar-benar jalan keluar internet yang berbeda, katakan dengan kata-kata itu dan terapkan di batas yang didukung: koneksi baru dari alur kerja yang disetujui, atau aplikasi yang membuka permintaannya sendiri melalui jalan keluar yang dipilih. Lalu catat tugas mana memakai jalan keluar mana, agar orang berikutnya tidak perlu menyimpulkannya dari tabel perutean.

Simpan daftar periksa dalam catatan perubahan: titik keputusan, field atau tugas yang menggerakkannya, apakah alurnya sudah ada, dan apakah gejala yang diukur adalah latensi atau jalan keluar. Empat pertanyaan, dan kebijakan yang menjawab keempatnya adalah kebijakan yang bisa Anda operasikan, bukan Anda bela.