Berikut adalah garis besar dan alasan untuk aplikasi proxy WWW minimal untuk digunakan di I2P.
Operasi HTTP di I2P menggunakan I2PTunnel. Ketika base SocketLibrary keluar, perbedaan signifikan hanya 'wrapRequest' dan 'unwrapRequest' yang secara fungsional akan ditempatkan di socketLibrary, bukan di router (tapi versi SocketLibrary akan mampu menggunakan ACK selektif dan ukuran jendela besar, memungkinkan lebih banyak ACKs yang akan dilewatkan)
---BROWSER--->-I2PTUNNEL--->-ROUTERA--->-ROUTERB--->-I2PTUNNEL--->-HTTPD---------- 1: openCon 2: requestCon 3: wrapRequest 4: unwrapRequest 5: receiveACK receiveCon 6: sentSuccess sendSYN 7: wrapRequest 8: unwrapRequest 9: receiveSYN receiveACK 10: "GET /" sentSuccess 11: sendData 12: wrapRequest 13: unwrapRequest 14: receiveACK receiveData 15: sentSuccess "GET /" 16: "HTTP 200\n\nHi" 17: sendData 18: wrapRequest 19: unwrapRequest 20: receiveData receiveACK 21: "HTTP 200\n\nHi" sentSuccess 22: closeCon 23: sendClose 24: wrapRequest 25: unwrapRequest 26: receiveACK receiveClose 27: sentSuccess
Bentuk yang dioptimalkan, yang hanya dirancang untuk menangani file 128KB [1] dan halaman, dapat beroperasi lebih cepat:
BROWSER --> MinWWW --> ROUTERA --> ROUTERB --> MinWWW --> HTTPD 1: openCon 2: opened 3: "GET /" 4: sendData 5: forward 6: receive 7: receiveData 8: "GET /" 9: "HTTP 200\n\nHi" 10: sendData 11: forward 12: receive 13: receiveData 14: "HTTP 200\n\nHi" 15: closeCon 16: closed
Ada perbedaan signifikan dalam beban jaringan dan latensi - hal ini pada dasarnya adalah UDP versi HTTP. Di web normal, kita tidak bisa benar-benar melakukannya, karena kebanyakan permintaan HTTP dan tanggapan berkalo kali lipat lebih besar daripada paket-paket UDP yang didukung, tetapi dalam I2P, pesan dapat menjadi besar. Beban jaringan yang dihemat berasal dari fakta bahwa kita tidak perlu untuk mengirim pesan ACK- daripada permintaan wrap/unwrap sebelumnya (yang mem-bundle DataMessage dengan DeliveryStatusMessage untuk memberikan jaminan pengiriman), proxy MinWWW berkaitan dengan mengirim ulang (jika diperlukan - dalam I2PTunnel hari ini, ada tidak mengirim ulang).
Data yang dibutuhkan oleh proxy dan server MinWWW untuk membungkus adalah sangat kecil - ketika proxy ingin mengirim "GET /", ia menambahkannya dengan destinasi I2P yang mengirim permintaan, diikuti oleh ID permintaan 4 byte. Server MinWWW menerima permintaan tersebut, mengontak HTTPD yang sesuai, mengirim permintaan, menunggu respon dan mengirim balasan ke proxy MinWWW yang mengandung respon, diawali dengan permintaan id yang asli. Respon itu diambil dan dilewatkan kembali ke browser lalu koneksi ditutup.
Selain itu, proxy MinWWW dapat memilih server MinWWW untuk digunakan dari sebuah daftar, melalui beberapa robin atau algoritma lainnya, sehingga ada beberapa outproxies digabungkan secara transparan. Bandwidth yang diperlukan untuk menjalankan salah satu outproxies ini juga sangat berkurang, karena itu hanya akan menangani file 128KB (sehingga tidak ada yang akan men-download porno, warez, dll).
Fungsinya terbatas, tetapi 128KB data adalah banyak untuk satu permintaan HTTP atau respon. Diagram di atas juga tidak realistis di hop mereka - ROUTERA akan benar-benar tidak pernah berbicara langsung ke ROUTERB. ROUTERA akan mengirimkan kepada setiap pesan melalui dua router outbound tambahan, lalu meneruskan ke dua router inbound tambahan ke ROUTERB, sehingga lag menjadi signifikan - sementara di atas hanya menghemat 11 langkah, 8 langkah tersebut perlu melintasi seluruh jalur tunnel (4 remote hop setiap kali ketika tunnel adalah 2 hop jarak jauh di setiap strecth), meninggalkan MinWWW hanya dengan dua traversals penuh (satu untuk permintaan, satu untuk tanggapannya), bukan 10.
Menerapkan MinWWW proxy dan server seharusnya cukup mudah - sepenuhnya membaca permintaan HTTP dari klien (mungkin hanya dimulai dengan method GET, menyisakan method POST untuk nanti), bungkus pesan, dan menunggu respon. Server selanjutnya hanya perlu parsing permintaan untuk membuka soket atau URL, mengirim permintaan, menunggu jawabannya, dan mengirimkannya kembali melalui jaringan. Jika seseorang menerapkan ini, itu akan menjadi baik :)
[1] Mengapa file sebesar 128KB? Saat ini I2CP memungkinkan ukuran pesan arbitrary secara fungsional, tapi itu akan hilang karena melibatkan overhead memori yang berlebihan pada router intermediary, atau detail implementasi tambahan yang harus ditangani. I2PTunnel saat ini terbatas pada 128KB dan belum menjadi beban, jadi mungkin bisa ditingkatkan menjadi 256KB saat spesifikasi I2CP diperbarui)