Algılanan I2P başarımını iyileştirmek için yapılabilecek birkaç temel işlem vardır. Aşağıdakilerden bazıları işlemci ile, bazıları bant genişliği ile, bazıları da iletişim kuralları ile ilgilidir. Bununla birlikte, bu boyutların tümü, kıt kaynakların kullanımını azalttığı için ağ gecikmesini, verimini ve algılanan başarımı etkiler. Bu liste çok ayrıntılı olmasa da ele alınan ana konuları kapsıyor.

Geçmişte yapılmış başarım iyileştirmeleri için Başarım geçmişine bakabilirsiniz.

Daha iyi eş belirleme ve seçme

Daha hızlı başarım elde etmenin en önemli parçalarından biri, yönelticileri tüneller oluşturduğu eşleri seçme şeklini iyileştirmek olabilir. Yavaş bağlantıları olan ya da hızlı bağlantılara aşırı yüklenmiş eşlerin kullanılmadığından emin olmak gibi. Ayrıca, kendimizi çok sayıda hızlı bilgisayara sahip güçlü bir düşmanın Sybil saldırısına açık hale getirmeyeceğimizden de emin olmalıyız.

Ağ veri tabanını ayarlama

Ağ veri tabanının iyileştirme ve bakım algoritmalarıyla daha verimli olmak isteyeceğiz. Sürekli olarak yeni eşler bulmak için anahtar alanını keşfetmek ve önemli sayıda ağ iletisine ve yöneltici yüküne neden olmak yerine, bulmaya değer yeni bir şey olduğunu algılayıncaya kadar keşfetmeyi yavaşlatabilir hatta durdurabiliriz (birinin bize daha önce hiç duymadığımız birinin referansını vermesine bağlı olarak keşif oranını azaltmak gibi). Ayrıca, gerçekte ne gönderdiğimizle, kaç eşten geri döndürüldüğümüzle (veya bir geri dönüş yanıtı aldığımızle) ve aynı anda kaç tane eş zamanlı arama yaptığımızla ilgili bazı ayarlamalar yapabiliriz.

Oturum etiketi ayarlama ve geliştirme

ElGamal/AES+SessionTag algoritmasının çalışma şekli, rastgele tek kullanımlık 32 baytlık diziler kümesini yönetmek ve yeterince hızlı kullanılmazlarsa bunların sürelerini sona erdirmektir. Süresini çok erken doldurursak, tam (pahalı) bir ElGamal şifrelemesine geri dönmek zorunda kalırız. Ancak süreleri yeterince hızlı bir şekilde sona erdirmezsek, bitmemesi için sayılarını azaltmamız gerekir (ve alıcı bir şekilde bozulursa ve bazı etiketleri kaybederse, algılamadan önce daha da fazla şifreleme hatası oluşabilir). Algılama ve geri beslemeye dayalı daha etkin bazı algoritmalarla, ElGamal şifrelemesini önemsiz bir AES işlemiyle değiştirerek etiketlerin ömrünü güvenli ve daha verimli bir şekilde ayarlayabiliriz.

Oturum etiketi dağıtımını iyileştirmeye yönelik ek fikirler ElGamal/AES+SessionTag sayfasında açıklanmıştır.

Eşitlenmiş PRNG üzerine sessionTag aktarımı

Şu anda, ElGamal/AES+SessionTag algoritmamız, her şifrelenmiş iletiyi benzersiz bir rastgele 32 bayt nonce ("oturum etiketi") ile etiketleyerek çalışır ve bu iletiyi ilişkili AES oturumunun anahtarıyla şifrelenmiş olarak tanımlar. Böylece, her iletinin tamamen yeni bir rastgele etiketi olduğundan, eşlerin aynı oturumun parçası olan iletileri ayırt etmesi engellenir. Bunu başarmak için, her birkaç ileti, şifrelenmiş iletinin içinde yepyeni bir oturum etiketi kümesi toplayarak ve gelecekteki iletileri şeffaf bir şekilde tanımlamanın bir yolunu sunar. Ardından, hangi etiketleri kullanabileceğimizi bilmemiz için hangi iletilerin başarıyla iletildiğini izlemeliyiz.

Bu yöntem iyi çalışır ve oldukça sağlamdır. Ancak bu etiketlerin zamanından önce teslim edilmesini gerektirdiğinden bant genişliği kullanımı açısından verimsizdir (ve tüm etiketler gerekli olmayabilir veya sürelerinin dolmasından dolayı bazıları boşa gidebilir). Bununla birlikte, ortalama olarak, oturum etiketinin önceden iletilmesi, ileti başına 32 bayta (bir etiketin boyutuna) mal olur. Yine de Taral tarafından önerildiği gibi, etiketlerin teslimi eşitlenmiş bir PRNG ile değiştirilerek bu boyuttan kaçınılabilir. Yeni bir oturum kurulduğunda (ElGamal şifrelenmiş bir blok aracılığıyla), her iki taraf da kullanım için bir PRNG tohumu ve istek üzerine oturum etiketlerini oluşturur (alıcı, istek teslimatını işlemek için sonraki birkaç olası değeri önceden hesaplarken).

Daha uzun ömürlü tüneller

10 dakikalık geçerli varsayılan tünel süresi oldukça keyfidir, ancak "iyi hissettirir". Tünel iyileştirme koduna ve daha etkili arıza algılamasına sahip olduğumuzda, ağ ve işlemci yükünü azaltarak (pahalı tünel oluşturma iletileri nedeniyle) bu süreleri daha güvenli bir şekilde değiştirebileceğiz.

Bu, büyük bant genişliğine sahip yönelticilerdeki yüksek yük için kolay bir düzeltme gibi görünüyor. Ancak tünel oluşturma algoritmalarını daha fazla ayarlayana kadar buna başvurmamalıyız. Bununla birlikte, 10 dakikalık tünel ömrü birkaç yerde sabit olarak kodlanmıştır. Bu nedenle süreyi değiştirmek için büyük çaba gerekir. Ayrıca, böyle bir değişiklik yapıldığında geriye dönük uyumluluğu korumak zor olacaktır.

Şu anda, ağın ortalama tünel oluşturma başarı oranı oldukça yüksek olduğundan, tünel ömrünü uzatmaya yönelik bir plan bulunmuyor.

Zaman aşımlarını ayarlama

Sahip olduğumuz oldukça keyfi ama "tamam saydığımız" şeylerden bir diğeri, çeşitli işlemler için var olan zaman aşımlarıdır. Neden 60 saniyelik bir "eş ulaşılamaz" zaman aşımına sahibiz? Neden bir "Kiralama kümesini" (LeaseSet) duyurulduktan 10 saniye sonra farklı bir tünelden göndermeyi deneriz? Neden "Ağ veri tabanı" (netDB) sorgularını 60 ya da 20 saniye ile sınırlandırıyoruz? Neden hedefleri her 10 dakikada bir yeni bir tünel kümesi isteyecek şekilde yapılandırıyoruz? Neden bir eşin tünele katılma isteğimize yanıt vermesi için 60 saniyeye izin veriyoruz? Neden 60 saniye içinde sınamamızı geçemeyen bir tüneli "ölü" olarak değerlendiriyoruz?

Bu öngörülemez sorunların her biri, bant genişliği, gecikme ve işlemci kullanımı arasında daha uygun bir denge bulabilmek için ayarlanabilir parametrelerin yanında daha uyarlanabilir bir kodlama ile de çözümlenebilir.

Tam akış iletişim kuralı iyileştirmeleri

• Belki de etkileşimli akış profilini yeniden etkinleştirme (geçerli uygulama yalnızca toplu akış profilini kullanır).
• İstemci düzeyinde bant genişliği sınırlaması (bir akışta herhangi bir yönde ya da her iki yönde ya da birden çok akışta paylaşılabilir). Bu durum, yönelticinin genel bant genişliğinin sınırlamasına ek olur.
• Erişim denetimi listeleri (yalnızca bilinen diğer belirli hedeflere ya da bu hedeflerden akışlara izin verilir).
• İnternet, çeşitli akışların sağlığını denetleme ve izlemenin yanında bunları açıkça kapatabilir ya da kısabilir.

Akış kitaplığını geliştirmek için ek fikirler akış kitaplığı sayfasında açıklanmıştır.