Bagaimana cara kerja I2P, mengapa I2P lambat, dan mengapa I2P tidak menggunakan bandwidth penuh?

Mungkin salah satu hal yang paling sering ditanya adalah "seberapa cepat I2P?", dan tak seorang pun tampaknya menyukai jawaban - "tergantung". Setelah mencoba I2P, hal berikutnya yang mereka tanyakan "akankah lebih cepat?", dan jawabannya adalah paling tegas adalah ya.

I2p adalah jaringan dinamis penuh. Setiap client dikenal oleh node lain dan menguji lokal known node untuk reachability dan kapasitas. Hanya node yang terjangkau dan mampu, disimpan NetDB lokal (ini adalah umumnya hanya sebagian dari jaringan, di sekitar 500-1000). Ketika I2P membangun tunnel, I2P memilih sumber daya terbaik dari pool ini. Sebagai contoh, subset kecil dari 20-50 node hanya tersedia untuk membangun tunnel. Karena pengujian terjadi setiap menit, pool dari node yang telah digunakan berubah setiap menit. Setiap node I2P tahu bagian yang berbeda dari internet, berarti bahwa setiap router memiliki kumpulan I2P node digunakan untuk tunnel. Bahkan jika kedua router memiliki subset known node yang sama, tes untuk reachability dan kapasitas akan mungkin menunjukkan hasil yang berbeda, seperti router lain bisa saja di bawah beban hanya sebagai satu router tes, tetapi menjadi bebas jika router kedua menguji.

Di atas menjelaskan mengapa setiap node I2P memiliki node berbeda untuk membangun tunnel. Karena setiap node I2P memiliki latency dan bandwidth berbeda, tunnel (yang dibangun melalui node tersebut) memiliki nilai latency dan bandwidth yang berbeda. Karena setiap node I2P memiliki tunnel berbeda, tidak ada dua node I2P yang memiliki tunnel set yang sama .

Server/klien dikenal sebagai sebuah "destinasi" dan setiap destinasi memiliki setidaknya satu tunnel inbound dan outbound. Defaultnya adalah 3 hop per tunnel. Ini menambahkan hingga 12 hop (alias 12 I2P node berbeda ) untuk ulang-alik penuh client-server-client.

Setiap paket data dikirim melalui 6 node I2P lainnya sampai mencapai server:

client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server

dan perjalanan kembali 6 I2P node yang berbeda :

server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client

Karena sebagian besar lalu lintas di I2P (www, torrent,...) memerlukan ack package sampai data baru dikirim, I2P perlu menunggu sampai ack package kembali dari server. Pada akhirnya: mengirim data, menunggu ack, mengirim lebih banyak data, menunggu ack,... Karena RTT (RoundTripTime) menambah latency dari setiap node I2P dan setiap koneksi pada ulang-alik ini, dibutuhkan biasanya 1-3 detik sampai ack package kembali ke klien. Dengan beberapa transport TCP dan I2P internal, paket data memiliki ukuran terbatas dan tidak dapat sebesar seperti yang kita inginkan. Secara bersama-sama, kondisi ini menetapkan batas bandwidth maksimal per terowongan sebesar 20-50 kbyte/detik. Tetapi jika hanya satu hop di tunel memiliki bandwidth hanya 5 kb/detik, seluruh tunnel terbatas untuk 5 kb/detik, tidak tergantung latency dan keterbatasan lain.

Karena enkripsi yang digunakan dan setup lainnya di I2P (bagaimana membangun terowongan, latency, ...) cukup mahal dalam waktu CPU untuk membangun tunnel. Inilah sebabnya destinasi hanya diperbolehkan untuk memiliki maks 6 tunnel MASUK dan 6 KELUAR untuk transportasi data. Dengan max 50 kb/detik per terowongan, destinasi dapat menggunakan kira-kira total 300 kb/detik lalu lintas (dalam kenyataannya mungkin lebih jika terowongan lebih pendek digunakan dengan anonimitas tidak tersedia atau rendah). Tunnel bekas dibuang setiap 10 menit dan yang baru dibangun. Perubahan terowongan ini (dan kadang-kadang klien yang hard shutdown karena penggunaan "shut down at once" atau situasi di mana ada mati lampu) kadang-kadang break tunnel dan koneksi, seperti yang terlihat pada jaringan IRC2P kehilangan koneksi (ping timeout) atau pada saat menggunakan eepget.

Dengan serangkaian destinasi dan serangkaian unnel per tujuan, satu node I2P hanya menggunakan serangkaian tunnel di node I2P lain. Misalnya, jika node I2P adalah "hop1" di dalam contoh kecil di atas, kita hanya melihat 1 participating tunnel yang berasal dari client. Jika kita menjumlahkan seluruh jaringan I2P, hanya sejumlah tunnel yang terbatas yang bisa dibangun dengan jumlah bandwidth yang terbatas. Jika salah satu mendistribusikan angka-angka terbatas ini di sejumlah node I2P, ada hanya sebagian dari kapasitas bandwidth tersedia yang tersedia untuk digunakan.

Untuk tetap anonim, satu router tidak boleh digunakan oleh seluruh jaringan untuk membangun tunnel. Jika satu router bertindak sebagai tunnel router untuk semua node I2P, dia menjadi titik pusat kegagalan dan juga titik sentral untuk mengambil data dari klien dan IPs. Ini tidak bagus. I2P mencoba menyebarkan beban ke banyak node I2P karena alasan ini.

Hal lain adalah jaringan mesh penuh. Setiap hop-hop koneksi menggunakan satu koneksi TCP atau UDP pada node I2P. Dengan 1000 koneksi, seseorang melihat 1000 koneksi TCP. Itu cukup banyak dan router rumah dan kantor kecil (DSL, kabel, ..) hanya mengizinkan sejumlah kecil koneksi (atau hanya menjadi gila jika menggunakan lebih dari koneksi X). I2P mencoba untuk membatasi koneksi ini di bawah 1500 per UDP dan per tipe TCP. Ini membatasi jumlah lalu lintas yang diarahkan ke node I2P milik anda juga.

Singkatnya, I2P sangat kompleks dan tidak ada cara mudah untuk menentukan mengapa node anda tidak digunakan. Jika node anda dapat dijangkau dan memiliki pengaturan bandwidth> 128 kbyte / detik yang dibagi dan dapat dijangkau 24/7, itu harus digunakan setelah beberapa waktu untuk participating traffic. Jika berada di tengah-tengah, pengujian simpul I2P anda yang dilakukan oleh node lain akan memberi tahu: anda tidak dapat dijangkau. Ini memblokir node anda setidaknya 24 jam pada node lain. Jadi, node lain yang menganggap anda sebagai tidak aktif tidak akan menggunakan simpul Andaaselama 24 jam untuk membangun tunnel. Inilah sebabnya mengapa lalu lintas anda akan menjadi lebih rendah setelah restart / shutdown selama minimal 24 jam.

Selain itu: node I2P lainnya perlu mengetahui router I2P Andaauntuk mengujinya untuk reachability dan kapasitas. Butuh waktu untuk node lain untuk diketahui node anda. Ini akan lebih cepat jika anda menggunakan I2P dan membangun lebih banyak tunnel, misalnya menggunakan torrent atau www untuk beberapa lama.

Peningkatan Kinerja

Untuk peningkatan kinerja masa depan, lihat Perbaikan Kinerja Masa Depan .

Untuk perbaikan kinerja masa lalu, lihat Riwayat kinerja.