Схема и объяснение минималистичного WWW-прокси поверх I2P.
Работа HTTP в I2P с использованием I2PTunnel. Когда база библиотеки SocketLibrary будет отделена, единственным существенным отличием будет то, что 'wrapRequest' и 'unwrapRequest' будут функционально располагаться в socketLibrary, а не в маршрутизаторе (но более поздние версии SocketLibrary могут использовать выборочные ACK и большие размеры окон, что позволит пропускать больше ACK)
---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
Оптимизированная форма, разработанная, чтобы обработать только 128 КБ [1] файлы и страницы, может работать значительно быстрее:
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
Разница между загрузкой сети и задержками значительна - это, по сути, UDP версия HTTP. В обычной сети мы не можем этого сделать, так как большинство HTTP запросов и ответов в разы больше, чем UDP пакеты функционально поддерживают, но в I2P сообщения могут быть больше. Экономия на сетевой нагрузке происходит из-за отсутствия необходимости отправлять ACK сообщений - вместо раннего wrap/unwrap запроса (который связывает DataMessage с DeliveryStatusMessage для обеспечения гарантированной доставки), MinWWW прокси производит повторную отправку (если необходимо - на данный момент в I2PTunnels нет повторных отправок).
Данные, которые прокси-сервер MinWWW и сервер должны обернуть, тривиальны - когда прокси-сервер хочет отправить "GET /" запрос, он добавляет к нему I2P адрес назначения отправляющего запрос, за которым следует 4-байтовый идентификатор запроса. Сервер MinWWW получает эти запросы, обращается к соответствующему HTTPD, отправляет запрос, ожидает ответ, и отправляет ответ прокси-серверу MinWWW, содержащему запрос, с префиксом исходного идентификатора запроса. Этот ответ берется и передается браузеру, после чего соединение закрывается.
В дополнение, прокси MinWWW может выбирать используемый сервер MinWWW из списка, по алгоритму round-robin или другому, чтобы прозрачно совмещать несколько выходных прокси. Необходимая пропускная способность для запуска одного выходного прокси уменьшается, так как он должен обрабатывать только 128KB файлы (то есть никто не будет загружать порно, варез и т.д.)
Функциональность /is/ ограничена, но 128KB данных с запасом хватит для одного запроса или ответа HTTP. Диаграммы выше нереалистичны в отображении хопов - ROUTERA никогда напрямую не свяжется с ROUTERB. ROUTERA пошлет каждое из сообщений через два дополнительных выходных роутера, затем их перешлют на два дополнительных входных роутера на ROUTERB, так что задержка здесь существенна - хотя указанное выше сэкономит только 11 шагов, 8 из них нужны для обхода всего туннельного пути (каждый раз 4+ удаленных хопа при туннелях протяженностью 2 удаленных хопа), оставляя MinWWW только два обхода (один для запроса, один для ответа), вместо 10.
Реализация прокси MinWWW и сервера должна быть довольно проста - читать HTTP запрос с клиента полностью (возможно, начать с HTTP GET, оставив HTTP POST на потом), проксировать сообщение и ждать ответа. Далее сервер просто должен распознать запрос и открыть сокет или URL, послать запрос, ждать ответа, и отправить его обратно по сети. Будет отлично, если кто-то реализует это :)
[1] Почему файлы 128KB? Сейчас I2CP допускает работу с произвольным размером сообщения, но это будет отменено, так как привлекает или избыточное использование памяти на промежуточных маршрутизаторах или дополнительные усилия по реализации. I2PTunnel сейчас ограничен до 128KB без перегрузки, так что, возможно, он будет увеличен до 256KB когда спецификации I2CP обновят)