Koneksi Bersamaan

Pengertian koneksi dan cara kerjanya

Koneksi jaringan adalah jalur komunikasi yang dibentuk dua program untuk bertukar data. Misalnya, browser terhubung ke server web untuk meminta halaman dan menerima isinya. Koneksi menyediakan jalur pertukaran tersebut; permintaan dan respons adalah pesan yang dikirim melaluinya.

Perhatikan koneksi TCP konvensional. Aplikasi menghubungi alamat IP server dan port untuk layanan yang dibutuhkan. Kedua pihak bertukar pesan kendali untuk membentuk koneksi. Data kemudian dikirim dalam satuan kecil bernama paket. TCP melacak pengiriman, mengatur pengiriman ulang data yang hilang, dan menyajikan data kepada penerima dalam urutan yang benar. Kedua pihak menyimpan informasi tentang pertukaran tersebut selama koneksi masih ada.

Dengan proksi TCP konvensional, aplikasi terlebih dahulu terhubung ke server proksi. Proksi membentuk koneksi terpisah ke situs tujuan dan meneruskan data di antara kedua koneksi, dalam kedua arah. Karena itu, proksi mempertahankan komunikasi dengan klien maupun tujuan.

Aplikasi dapat mengirim permintaan, menerima respons, dan menggunakan koneksi yang sudah terbentuk untuk pertukaran berikutnya. Menerima halaman, misalnya, belum tentu menutup koneksi: browser dapat mempertahankannya untuk permintaan selanjutnya ke server. Ketika tidak lagi diperlukan, salah satu pihak menutupnya; kesalahan atau timeout juga dapat mengakhirinya. Sampai ditutup, koneksi dapat tetap ada tanpa terus-menerus mentransfer data.

Program dapat mempertahankan beberapa koneksi semacam itu sekaligus: menerima data pada satu koneksi, menunggu balasan pada koneksi lain, dan menyiapkan koneksi ketiga untuk permintaan berikutnya. Inilah koneksi bersamaan. Jumlahnya menjelaskan saluran komunikasi yang terbuka saat itu, bukan total permintaan sejak program dimulai.

Apa yang diukur batas ini

Koneksi terbuka menempati satu tempat dalam kuota yang relevan. Setelah koneksi ditutup dan layanan menghapusnya dari hitungan, tempat itu tersedia lagi. Ini adalah batas aktivitas saat ini, sehingga mencapainya tidak menghabiskan saldo koneksi bulanan.

Cara koneksi dihitung dalam kuota pelanggan merupakan aturan layanan tersendiri. Dua ruas koneksi jaringan pada proksi tidak otomatis menghabiskan dua satuan kuota.

Penyedia menetapkan batas ini karena koneksi terbuka menggunakan sumber daya server meskipun hanya mentransfer sedikit data. Koneksi yang menunggu balasan tetap harus dipertahankan. Mengendalikan jumlahnya membantu layanan menjaga kapasitas yang memadai untuk beban kerja yang telah disanggupi.

Beberapa batas berbeda dapat berlaku pada layanan yang sama:

Karena itu, trafik tanpa batas tidak menjelaskan jumlah koneksi serentak. Mungkin juga ada batas terpisah atas kecepatan pembukaan koneksi baru. Membuka dan menutupnya dengan cepat dapat mencapai batas tersebut meskipun hanya sedikit koneksi yang tetap terbuka pada suatu saat.

Mengapa jumlah thread tidak sama dengan jumlah koneksi

Jumlah thread atau pekerja dalam aplikasi menjelaskan cara aplikasi mengatur tugas. Angka itu tidak secara andal menunjukkan banyaknya koneksi yang akan dihitung proksi. Satu tugas dapat menghubungi beberapa server, dan skrip asinkron dapat mengelola banyak operasi jaringan tanpa membuat thread sistem operasi terpisah untuk setiap operasi.

Setiap permintaan HTTP juga tidak selalu memerlukan koneksi baru. Klien dapat memakai ulang koneksi yang ada, dan HTTP/2 dapat membawa beberapa permintaan sekaligus melalui satu koneksi. Karena itu, jumlah permintaan berbeda dari jumlah koneksi.

Istilah yang digunakan penyedia juga penting. Batas yang disebut “thread” atau “sesi” dapat merujuk pada koneksi terbuka atau permintaan yang sedang diproses. Sesi yang mempertahankan IP, yang menjaga IP proksi tetap sama untuk permintaan terkait, belum tentu mewakili satu koneksi jaringan. Definisi yang berguna adalah apa yang benar-benar dihitung layanan.

Program mana yang berbagi kuota?

Batas dapat melekat pada akun, paket yang dibeli, IP proksi tertentu, atau gateway tertentu. Untuk batas akun atau paket, jumlahkan koneksi dari setiap program dan perangkat yang menggunakan kuota tersebut. Membagi daftar IP di antara beberapa komputer tidak membuat kuota terpisah bagi setiap komputer.

Pada batas per IP, pembagiannya berbeda: satu alamat yang sibuk dapat mencapai maksimum sementara alamat lain masih memiliki ruang. Memindahkan sebagian pekerjaan ke alamat kedua dapat membantu, selama layanan tidak sekaligus menetapkan batas bersama yang lebih rendah. Paket dapat memiliki kuota keseluruhan serta alokasi lebih kecil untuk pengguna atau IP klien tertentu.

Jumlah IP klien yang diizinkan melakukan autentikasi adalah pengaturan lain. Pengaturan ini menentukan jaringan yang dapat mengakses proksi, bukan banyaknya koneksi yang dapat dibuka jaringan tersebut. Beberapa perangkat di balik satu IP publik dapat berbagi aturan akses maupun alokasi koneksi yang melekat padanya.

Mengubah IP proksi yang dilihat situs tidak mengatur ulang kuota koneksi seluruh akun. Demikian pula, mengganti nama sesi IP tetap atau protokol tidak otomatis menyediakan kapasitas tambahan. Batas tetap melekat pada akun, paket, atau titik koneksi yang digunakan penyedia untuk menghitungnya.

Mengapa koneksi menumpuk

Koneksi menumpuk ketika koneksi baru dibuka lebih cepat daripada penutupan koneksi yang ada. Ini dapat terjadi saat memuat halaman, mengunduh berkas, atau menjalankan tugas jaringan lain secara paralel: sebagian koneksi masih mentransfer data atau menunggu respons sementara aplikasi membuka koneksi tambahan. Koneksi-koneksi ini dihitung dalam kuota pada saat yang sama dan bersama-sama dapat menghabiskan batas koneksi proksi.

Respons lambat membuat koneksi terpakai lebih lama. Jika program terus memulai pekerjaan baru dengan laju yang sama, pekerjaan yang belum selesai menumpuk. Sebaliknya, jika aktivitas paralel dipertahankan pada tingkat tetap, situs yang lebih lambat umumnya berarti lebih sedikit tugas selesai per menit. Kedua situasi dapat terjadi tanpa perubahan paket proksi.

Unduhan panjang dan koneksi yang menunggu timeout dapat memberikan efek yang sama. Karena itu, banyak koneksi terbuka dapat hadir bersama kecepatan transfer yang rendah: sebagian besar waktu digunakan untuk menunggu, bukan memindahkan data.

Sebagian koneksi sengaja dibiarkan terbuka di antara permintaan. Ini biasanya disebut keep-alive. Cara ini menghindari pembentukan koneksi baru setiap kali, tetapi koneksi menganggur mungkin tetap menempati satu tempat jika layanan menghitung koneksi terbuka. Koneksi yang dikembalikan ke kumpulan koneksi aplikasi tersedia untuk dipakai ulang; belum tentu koneksi itu telah ditutup pada proksi.

Masalah terpisah adalah pembersihan koneksi yang tidak benar. Hal ini dapat terjadi pada perangkat lunak siap pakai maupun skrip buatan sendiri. Misalnya, kode mulai membaca respons, menemui kesalahan, dan memulai permintaan lain tanpa menyelesaikan atau menutup respons sebelumnya. Jika koneksi baru terus terbuka sementara koneksi lama tetap terpakai, aplikasi dapat menghabiskan kuotanya tanpa melakukan lebih banyak pekerjaan berguna. Karena itu, periksa pembersihan setelah kesalahan dan pembatalan, bukan hanya setelah permintaan berhasil.

Pembersihan yang benar memungkinkan klien memakai ulang koneksi yang sesuai atau menutup koneksi yang tidak diperlukan. Timeout mencegah operasi yang ditinggalkan menunggu tanpa akhir. Menonaktifkan pemakaian ulang di semua tempat bukan solusi umum: cara itu menambah pekerjaan pembentukan koneksi dan dapat meningkatkan laju koneksi baru. Tujuannya adalah jumlah koneksi yang dapat dipakai ulang secara terkendali, dengan koneksi yang tidak diperlukan dilepas atau ditutup dengan benar.

Mengapa proksi tampak bekerja, lalu berhenti, lalu bekerja lagi

Kegagalan berselang saat beban meningkat menjadi alasan untuk memeriksa batas koneksi sejak awal. Sebagian alamat proksi tampak bekerja sementara yang lain gagal; tidak lama kemudian, polanya berubah. Dari sudut pandang aplikasi, bagian-bagian berbeda dari daftar proksi terlihat terus bergantian tidak tersedia.

Salah satu penjelasannya adalah kuota bersama sudah penuh. Koneksi yang ada dapat berlanjut, sementara percobaan membuka lebih banyak koneksi ditolak atau dibiarkan menunggu. Ketika koneksi sebelumnya ditutup, sebagian percobaan baru berhasil. Percobaan lainnya gagal saat tempat yang tersedia kembali penuh. Hasil yang berubah berasal dari persaingan untuk kuota yang sama, bukan sekelompok IP rusak yang tetap.

Perilaku ini terkadang disebut throttling. Di sini, pembatasan memengaruhi penerimaan koneksi baru; belum tentu kecepatan setiap koneksi yang sudah terbentuk ikut berkurang. Respons tepatnya bergantung pada layanan: layanan dapat mengembalikan pesan batas yang jelas, menolak koneksi, atau membiarkan klien mengalami timeout. Antrean tunggu tidak dijamin tersedia.

Untuk memeriksa penjelasan ini, bandingkan kegagalan dengan jumlah koneksi dan kurangi sementara aktivitas paralel di seluruh program yang berbagi kuota. Jika kegagalan berhenti ketika aktivitas turun di bawah batas dan kembali saat kuota penuh lagi, batas koneksi mungkin penyebabnya. Gangguan serupa juga dapat berasal dari situs tujuan atau jaringan. Timeout maupun respons HTTP 429, 502, atau 503 saja tidak membuktikan bahwa batas koneksi proksi tercapai; sumber dan bunyi kesalahan perlu diperhatikan.

Menjaga pekerjaan berguna tetap di dalam batas

Mulailah dari situs dan operasi yang benar-benar perlu dilakukan perangkat lunak Anda. Tingkatkan aktivitas paralel bertahap dan amati hasil yang berhasil, waktu respons, serta puncak koneksi. Pengujian singkat terhadap halaman cepat mungkin tidak mewakili proses lengkap yang mencakup login, respons besar, dan titik koneksi yang lebih lambat.

1. Berikan anggaran koneksi bersama kepada semua program. Sisakan ruang untuk aktivitas lain dan lonjakan singkat. Jika beberapa proses menggunakan paket yang sama, mengatur setiap proses sebesar seluruh kuota paket dapat membebani layanan secara berlebihan saat semuanya berjalan bersamaan.
2. Kendalikan tugas dan koneksi. Kumpulan koneksi menyimpan koneksi untuk dipakai ulang. Periksa apakah pengaturan ukurannya merupakan batas tegas atau hanya jumlah yang dipertahankan setelahnya; sebagian klien membuka koneksi tambahan kecuali mode menunggu diaktifkan. Pertahankan pembersihan respons dan timeout, termasuk ketika pekerjaan gagal.
3. Jarakkan peluncuran dan percobaan ulang. Memulai semua browser sekaligus atau segera mengulangi setiap permintaan yang gagal menciptakan puncak lain. Gunakan jumlah percobaan ulang terbatas dengan jeda yang meningkat, dan pertahankan semuanya dalam anggaran beban kerja yang sama. Timeout juga tidak membuktikan bahwa tindakan yang dikirim gagal, sehingga mengulangi pembelian atau pembaruan memerlukan kehati-hatian.
4. Ukur pekerjaan yang selesai. Lebih banyak pekerja hanya berguna selama meningkatkan laju hasil yang berhasil. Ketika terutama menambah waktu tunggu dan kesalahan, pengaturan lebih rendah mungkin menyelesaikan pekerjaan yang sama lebih cepat. Jika dasbor merata-ratakan aktivitas sepanjang waktu, puncak singkat mungkin kurang terlihat dibandingkan pada catatan waktu kesalahan aplikasi.

Untuk tugas browser, menghindari unduhan yang tidak diperlukan juga dapat mengurangi aktivitas jaringan. Memblokir gambar atau video mungkin membantu jika tugas tidak membutuhkannya; menghapus skrip dapat merusak operasi itu sendiri. Nilai perubahan berdasarkan apakah tugas yang dimaksud masih selesai dengan benar.

Kapan batas lebih tinggi membantu

Kapasitas koneksi tambahan berguna ketika aplikasi mengelola koneksinya dengan benar dan beban kerja yang dibutuhkan terus mencapai maksimum penyedia. Kapasitas ini memungkinkan lebih banyak tugas berjalan bersamaan tanpa memperebutkan kuota kecil yang sama.

Pembelian harus meningkatkan batas yang benar-benar tercapai. Menambah IP dapat membantu mengatasi pembatasan per IP jika pekerjaan dibagi di antaranya. Untuk batas paket bersama, paket baru atau tambahan harus menaikkan kuota bersama tersebut. Penambahan jumlah IP saja tidak membuktikan bahwa kuota itu akan naik.

Ada pula batas maksimum lainnya. Klien mungkin memiliki kumpulan koneksi yang lebih kecil, komputer mungkin kekurangan sumber daya jaringan, atau tujuan mungkin membatasi permintaan. Satu koneksi seluler juga memiliki lebar pita yang tersedia sendiri, terlepas dari jumlah koneksi proksi yang diizinkan. Membeli lebih banyak kapasitas koneksi bersamaan tidak menghapus batasan tersebut dan tidak memperbaiki skrip yang terus membocorkan koneksi.

Sasaran praktisnya adalah ruang yang cukup untuk puncak normal beban kerja sambil menjaga kegagalan tetap rendah. Setelah itu tercapai, kuota koneksi tambahan dapat menjadi peningkatan kapasitas yang berguna, bukan cara menunda perbaikan aplikasi.