Halaman ini terakhir diperbarui pada sAgustus 2010 dan akurat untuk router versi 0.8.

Ada beberapa teknik utama yang dapat dilakukan untuk meningkatkan kinerja I2P - seperti yang terkait dengan CPU, yang terkait bandwidth, dan yang terkait protokol. Namun, semua dimensi tersebut mempengaruhi latensi, throughput, dan kinerja jaringan yang dirasakan, karena mengurangi pertengkaran sumber daya yang langka. Daftar ini tentu tidak komprehensif, tapi sudah mencakup hal-hal yang utama.

Untuk perbaikan kinerja masa lalu, lihat Riwayat kinerja.

Pembuatan profil dan seleksi peer yang lebih baik

Mungkin salah satu bagian yang paling penting dari mendapatkan kinerja yang lebih cepat adalah meningkatkan cara router memilih peer yang di mana mereka membangun tunnel - memastikan mereka tidak menggunakan peer dengan link lambat atau peer dengan link cepat yang kelebihan beban, dll. Selain itu, kita harus memastikan bahwa kami tidak membuka diri terhadap serangan Sybil dari musuh yang kuat dengan banyak komputer yang cepat.

Network database tuning

Kita akan ingin untuk menjadi lebih efisien dengan algoritma penyembuhan database dan pemeliharaan - daripada terus-menerus menjelajahi keyspace untuk peer baru - menyebabkan sejumlah besar pesan jaringan dan beban router - kita dapat memperlambat atau bahkan berhenti menjelajahi sampai mendeteksi yang ada sesuatu yang baru yang bernilai (misalnya decay dari tingkat eksplorasi berdasarkan terakhir kali seseorang memberi kami rujukan kepada seseorang yang kami belum pernah dengar). Kita juga dapat melakukan beberapa tuning pada apa benar-benar kita kirimkan - berapa banyak peer yang bounce back (atau bahkan jika kita bounce back balasan), serta seberapa banyak kita melakukan pencarian simultan.

Session Tag Tuning and Penyempurnaan

Cara ElGamal / AES + SessionTag algoritma bekerja adalah dengan mengelola serangkaian 32 byte array acak satu-kali-digunakan, dan hal itu menjadi kadaluarsa jika tidak digunakan dengan cukup cepat. Jika kita mengakhiri mereka terlalu cepat, kita dipaksa untuk kembali kepada enkripsi ElGamal penuh (mahal), tapi jika kita tidak membuat mereka kedaluwarsa dengan cukup cepat, kita harus mengurangi jumlah mereka sehingga kita tidak kehabisan memori (dan jika penerima entah bagaimana rusak dan kehilangan beberapa tag, bahkan lebih banyak kegagalan enkripsi mungkin terjadi sebelum deteksi). Dengan deteksi lebih aktif dan umpan balik yang didorong algoritma, kita bisa dengan aman dan lebih efisien mengelola masa waktu tag, menggantikan enkripsi ElGamal dengan operasi trivial AES .

Ide-ide tambahan untuk meningkatkan pengiriman sesi Tag dijelaskan pada ElGamal / AES + SessionTag halaman.

Memigrasi sessionTag ke PRNG tersinkronisasi

Sekarang, algoritma ElGamal / AES + SessionTag bekerja dengan tagging setiap pesan terenkripsi dengan unique random 32 byte ("session tag"), yang mengidentifikasi bahwa pesan dienkripsi dengan session key AES terkait. Hal ini mencegah peer dari membedakan pesan-pesan yang merupakan bagian dari sesi yang sama karena setiap pesan memiliki tag acak yang benar-benar baru. Untuk mencapai hal ini, setiap beberapa pesan menggabungkan keseluruhan tag sesi baru dalam pesan terenkripsi itu sendiri, secara transparan memberikan cara untuk mengidentifikasi pesan di masa mendatang. Kami kemudian harus melacak pesan yang berhasil dikirim sehingga kami tahu tag apa yang dapat digunakan.

Ini bekerja dengan baik dan cukup berguna, namun ini tidak efisien dalam penggunaan bandwidth, karena memerlukan pengiriman tag terlebih dahulu (dan tidak semua tag mungkin diperlukan, atau beberapa mungkin terbuang akibat mereka menjadi kadaluarsa). Rata-rata, predelivering tag sesi memiliki biaya 32 byte per pesan (ukuran tagnya). Seperti yang disarankan oleh Taral, ukuran sebesar itu dapat dihindari dengan mengganti pengiriman tag dengan sebuah PRNG disinkronisasi - ketika sesi baru dimulai (melalui blok dienkripsi oleh ElGamal), kedua belah pihak seed sebuah PRNG untuk digunakan dan menghasilkan session tag on demand (dengan penerima precalculating berikutnya beberapa nilai yang mungkin untuk menangani pengiriman).

Tunnel yang bertahan lebih lama

Durasi default tunnel saat ini 10 menit cukup arbritrary, meski "terasa oke". Begitu kita mendapat tunnel healing code dan deteksi kegagalan yang lebih efektif, kita akan bisa lebih aman memvariasikan durasi, mengurangi beban jaringan dan CPU (karena penciptaan message tunnel yang mahal).

Ini tampaknya merupakan perbaikan yang mudah untuk beban tinggi pada router dengan bandwidth besar, namun kami sebaiknya tidak menggunakannya sampai kami telah menyempurnakan algoritma pengembangan tunnel lebih jauh. Namun, 10 menit umur tunnel adalah hardcoded di beberapa tempat, sehingga upaya substansial akan diperlukan untuk mengubah durasi. Juga, akan sulit untuk menjaga kompatibilitas dengan perubahan seperti itu.

Saat ini, karena rata-rata tingkat keberhasilan pembangunan jaringan tunnel cukup tinggi, tidak ada rencana saat ini untuk memperpanjang umur tunnel.

Adjust the timeout

Namun, hal lain yang cukup arbritrary namun "rasanya oke" yang kita dapatkan adalah timeout saat ini untuk berbagai aktivitas. Mengapa kita memiliki timeout 60 detik untuk "peer unreachable"? Mengapa kita mencoba mengirimkan sebuah pesan melalui tunnel yang berbeda yang diiklankan oleh LeaseSet setelah 10 detik? Mengapa query database jaringan dibatasi oleh batas-batas 60 atau 20 detik? Mengapa destinasi dikonfigurasi untuk meminta serangkaian tunnel baru setiap 10 menit? Mengapa kita memperbolehkan 60 detik untuk peer untuk membalas permintaan kami bahwa mereka bergabung dengan sebuah tunnel? Mengapa kita menganggap sebuah tunnel yang tidak lulus tes kami dalam waktu 60 detik dianggap "mati"?

Setiap dari imponderables tersebut dapat diatasi dengan kode lebih adaptif, serta tunable parameter untuk memungkinkan timbal balik lebih tepat antara bandwidth, latensi, dan penggunaan CPU.

Perbaikan protokol streaming penuh

  • Mungkin kembali mengaktifkan profil stream interaktif (implementasi saat ini hanya menggunakan sebagian besar stream profile).
  • Pembatasan bandwidth di tingkat client (dalam salah satu atau kedua arah stream, atau mungkin dibagi di beberapa aliran). Ini akan menjadi tambahan untuk keseluruhan pembatasan bandwidth router, tentu saja.
  • Daftar kontrol akses (hanya mengizinkan arus ke atau dari tujuan estinasi lainnya yang diketahui).
  • Kontrol web dan pemantauan kesehatan berbagai aliran, serta kemampuan untuk secara eksplisit menutup atau meningkatkannya.

Ide-ide tambahan untuk meningkatkan streaming library dijelaskan pada halaman streaming library.