개요
이 페이지는 전체 I2P router 바이너리를 애플리케이션과 함께 번들링하는 것에 관한 내용입니다. I2P와 함께 작동하는 애플리케이션을 작성하는 것(번들링되거나 외부)에 관한 것이 아닙니다. 그러나 router를 번들링하지 않더라도 많은 가이드라인이 유용할 수 있습니다.
많은 프로젝트들이 I2P를 번들링하거나 번들링에 대해 논의하고 있습니다. 올바르게 수행된다면 훌륭한 일입니다. 잘못 수행된다면 우리 네트워크에 실질적인 해를 끼칠 수 있습니다. I2P router는 복잡하며, 사용자로부터 모든 복잡성을 숨기는 것은 어려운 과제가 될 수 있습니다. 이 페이지에서는 몇 가지 일반적인 가이드라인을 논의합니다.
이러한 지침의 대부분은 Java I2P나 i2pd에 동일하게 적용됩니다. 그러나 일부 지침은 Java I2P에만 해당되며 아래에 명시되어 있습니다.
문의하기
대화를 시작하세요. 저희가 도와드리겠습니다. I2P를 임베드하는 애플리케이션은 네트워크를 성장시키고 모든 사용자의 익명성을 향상시킬 수 있는 가장 유망하고 흥미로운 기회입니다.
router를 현명하게 선택하세요
애플리케이션이 Java나 Scala로 작성된 경우, 선택은 간단합니다 - Java router를 사용하세요. C/C++인 경우, i2pd를 권장합니다. i2pcpp의 개발은 중단되었습니다. 다른 언어로 작성된 앱의 경우, SAM이나 BOB 또는 SOCKS를 사용하고 Java router를 별도 프로세스로 번들하는 것이 가장 좋습니다. 다음 내용 중 일부는 Java router에만 적용됩니다.
라이선스
번들링하는 소프트웨어의 라이선스 요구사항을 충족하는지 확인하세요.
설정
기본 설정 확인
올바른 기본 구성이 매우 중요합니다. 대부분의 사용자는 기본 설정을 변경하지 않습니다. 애플리케이션의 기본값은 번들로 제공하는 router의 기본값과 다를 수 있습니다. 필요한 경우 router 기본값을 재정의하십시오.
검토해야 할 몇 가지 중요한 기본값: 최대 대역폭, tunnel 수량 및 길이, 최대 참여 tunnel 수. 이 대부분은 앱의 예상 대역폭과 사용 패턴에 따라 달라집니다.
사용자들이 네트워크에 기여할 수 있도록 충분한 대역폭과 tunnel을 구성하세요. 외부 I2CP는 아마도 필요하지 않고 다른 실행 중인 I2P 인스턴스와 충돌할 수 있으므로 비활성화하는 것을 고려해보세요. 또한 예를 들어 종료 시 JVM 종료를 비활성화하는 설정도 살펴보세요.
참여 트래픽 고려사항
참여 트래픽을 비활성화하고 싶은 유혹을 느낄 수 있습니다. 이를 위한 여러 가지 방법이 있습니다(숨김 모드, 최대 터널을 0으로 설정, 공유 대역폭을 12KBytes/초 이하로 설정). 참여 트래픽이 없으면 우아한 종료에 대해 걱정할 필요가 없고, 사용자들도 자신이 생성하지 않은 대역폭 사용량을 보지 않아도 됩니다. 하지만 참여 tunnel을 허용해야 하는 많은 이유들이 있습니다.
무엇보다도, router가 네트워크와 “통합"될 기회를 갖지 못하면 제대로 작동하지 않는데, 이는 다른 사용자들이 당신을 통해 tunnel을 구축할 때 크게 개선됩니다.
둘째, 현재 네트워크에서 router의 90% 이상이 참여 트래픽을 허용합니다. 이는 Java router에서 기본 설정입니다. 만약 여러분의 애플리케이션이 다른 사용자들을 위한 라우팅을 하지 않으면서 정말 인기를 얻게 된다면, 그것은 네트워크에 대한 무임승차가 되어 현재 우리가 유지하고 있는 균형을 깨뜨립니다. 만약 정말 커진다면, 우리는 Tor가 되어 사람들에게 릴레이를 활성화해달라고 애걸하며 시간을 보내게 될 것입니다.
셋째, 참여 트래픽은 사용자의 익명성을 돕는 커버 트래픽입니다.
기본적으로 participating traffic을 비활성화하는 것을 강력히 권하지 않습니다. 만약 이렇게 하고 당신의 애플리케이션이 매우 인기를 얻게 된다면, 네트워크를 손상시킬 수 있습니다.
지속성
router 실행 간에 router의 데이터(netDb, 설정 등)를 반드시 저장해야 합니다. 매번 시작할 때마다 리시드를 해야 한다면 I2P는 제대로 작동하지 않으며, 이는 리시드 서버에 큰 부하를 주고 익명성에도 좋지 않습니다. router 정보를 번들로 포함하더라도, I2P는 최적의 성능을 위해 저장된 프로필 데이터가 필요합니다. 지속성이 없으면 사용자는 시작 시 좋지 않은 경험을 하게 됩니다.
지속성을 제공할 수 없는 경우 두 가지 가능성이 있습니다. 이 중 어느 것이든 우리 reseed 서버에 대한 프로젝트의 부하를 제거하고 시작 시간을 크게 개선할 것입니다.
일반적인 reseed에서 제공하는 router info 수보다 훨씬 많은, 예를 들어 수백 개의 router info를 제공하는 자체 프로젝트 reseed 서버를 설정합니다. router가 오직 당신의 서버만 사용하도록 구성합니다.
설치 프로그램에 1천~2천 개의 router info를 번들로 포함하세요.
또한, tunnel 시작을 지연시키거나 단계적으로 진행하여, router가 많은 tunnel을 구축하기 전에 통합할 기회를 제공하세요.
설정 가능성
사용자가 중요한 설정의 구성을 변경할 수 있는 방법을 제공하세요. I2P의 복잡성 대부분을 숨기고 싶어할 것이라는 점을 이해하지만, 몇 가지 기본 설정은 보여주는 것이 중요합니다. 위의 기본값 외에도 UPnP, IP/포트와 같은 일부 네트워크 설정이 도움이 될 수 있습니다.
Floodfill 고려사항
특정 대역폭 설정 이상에서 다른 상태 기준을 충족하면, 라우터가 floodfill이 되어 연결 수와 메모리 사용량이 크게 증가할 수 있습니다(최소한 Java 라우터에서는). 이것이 괜찮은지 고려해보세요. floodfill을 비활성화할 수 있지만, 그렇게 하면 가장 빠른 사용자들이 기여할 수 있는 만큼 기여하지 못하게 됩니다. 또한 애플리케이션의 일반적인 가동 시간에도 달려있습니다.
리시딩
router info를 번들링할지 아니면 저희 reseed 호스트를 사용할지 결정하세요. Java reseed 호스트 목록은 소스 코드에 있으므로, 소스를 최신 상태로 유지하면 호스트 목록도 함께 업데이트됩니다. 적대적인 정부에 의한 차단 가능성을 유의하세요.
공유 클라이언트 사용
Java I2P i2ptunnel은 공유 클라이언트를 지원하며, 여기서 클라이언트들은 단일 풀을 사용하도록 구성할 수 있습니다. 여러 클라이언트가 필요하고 보안 목표와 일치한다면, 클라이언트를 공유하도록 구성하세요.
터널 수량 제한
inbound.quantity와 outbound.quantity 옵션을 사용하여 tunnel 수량을 명시적으로 지정하세요. Java I2P의 기본값은 2이고, i2pd의 기본값은 더 높습니다. 두 router 모두에서 일관된 설정을 얻으려면 SAM을 사용하여 SESSION CREATE 라인에서 지정하세요. 대부분의 저-중간 대역폭 및 저-중간 팬아웃(fanout) 애플리케이션에는 각각 2개의 인바운드/아웃바운드가 충분합니다. 서버와 높은 팬아웃 P2P 애플리케이션은 더 많이 필요할 수 있습니다. 높은 트래픽 서버 및 애플리케이션의 요구사항 계산에 대한 가이드는 이 포럼 게시물
을 참조하세요.
SAM SIGNATURE_TYPE 지정
SAM은 기본적으로 destination에 대해 DSA_SHA1을 사용하는데, 이는 원하는 설정이 아닙니다. Ed25519 (타입 7)가 올바른 선택입니다. DEST GENERATE 명령어에 SIGNATURE_TYPE=7을 추가하거나, DESTINATION=TRANSIENT인 경우 SESSION CREATE 명령어에 추가하세요.
SAM 세션 제한
대부분의 애플리케이션은 하나의 SAM 세션만 필요합니다. SAM은 많은 수의 세션이 생성될 경우 로컬 router나 심지어 더 넓은 네트워크를 빠르게 압도할 수 있는 능력을 제공합니다. 여러 하위 서비스가 단일 세션을 사용할 수 있다면, PRIMARY 세션과 SUBSESSIONS로 설정하세요 (현재 i2pd에서는 지원되지 않음). 세션의 합리적인 제한은 총 3개 또는 4개, 또는 드문 상황에서 최대 10개까지입니다. 여러 세션을 사용하는 경우, 각각에 대해 낮은 tunnel 수량을 지정해야 합니다. 위를 참조하세요.
거의 모든 상황에서 연결당 고유한 세션이 필요하지 않습니다. 신중한 설계 없이는 네트워크에 DDoS 공격을 빠르게 가할 수 있습니다. 보안 목표에서 고유한 세션이 필요한지 신중히 고려하십시오. 연결당 세션을 구현하기 전에 Java I2P 또는 i2pd 개발자들과 상의해 주시기 바랍니다.
네트워크 리소스 사용량 줄이기
이러한 옵션들은 현재 i2pd에서 지원되지 않습니다. 이 옵션들은 I2CP와 SAM을 통해 지원됩니다 (delay-open은 예외로, i2ptunnel을 통해서만 지원됩니다). 자세한 내용은 I2CP 문서 (그리고 delay-open의 경우 i2ptunnel 설정 문서)를 참조하세요.
애플리케이션 tunnel을 delay-open, reduce-on-idle 및/또는 close-on-idle로 설정하는 것을 고려해보세요. i2ptunnel을 사용하는 경우 간단하지만, I2CP를 직접 사용하는 경우 일부 기능을 직접 구현해야 합니다. 백그라운드 DHT 활동이 있는 상황에서도 tunnel 수를 줄이고 tunnel을 닫는 코드는 i2psnark를 참조하세요.
생명 주기
업데이트 가능성
가능하다면 자동 업데이트 기능을 포함하거나, 최소한 새 버전의 자동 알림 기능을 구현해 주세요. 우리가 가장 우려하는 것은 업데이트할 수 없는 수많은 router들이 존재하는 상황입니다. Java router는 연간 약 6-8회 릴리스되며, 사용자들이 최신 버전을 유지하는 것이 네트워크 건강성에 매우 중요합니다. 일반적으로 릴리스 후 6주 내에 네트워크의 80% 이상이 최신 릴리스를 사용하고 있으며, 이런 상태를 유지하고 싶습니다. router의 내장 자동 업데이트 기능을 비활성화하는 것에 대해서는 걱정할 필요가 없습니다. 해당 코드는 router console에 있으며, 여러분이 번들링하지 않을 것으로 추정되기 때문입니다.
배포
점진적 출시 계획을 세우세요. 네트워크를 한 번에 압도하지 마세요. 현재 일일 고유 사용자는 약 25,000명, 월간 고유 사용자는 40,000명입니다. 연간 2-3배의 성장은 큰 문제없이 처리할 수 있을 것으로 보입니다. 그보다 빠른 증가를 예상하거나, 사용자층의 대역폭 분포(또는 가동시간 분포, 기타 중요한 특성)가 현재 사용자층과 크게 다른 경우, 반드시 논의가 필요합니다. 성장 계획이 클수록 이 체크리스트의 다른 모든 항목들이 더욱 중요해집니다.
긴 가동 시간을 위한 설계 및 권장
사용자들에게 I2P는 계속 실행 상태를 유지할 때 가장 잘 작동한다고 알려주세요. 시작 후 제대로 작동하기까지 몇 분이 걸릴 수 있으며, 처음 설치한 후에는 더 오래 걸릴 수 있습니다. 평균 가동 시간이 한 시간 미만이라면, I2P는 아마도 적합하지 않은 솔루션일 것입니다.
사용자 인터페이스
상태 표시
애플리케이션 tunnel이 준비되었음을 사용자에게 알려주세요. 인내심을 가지도록 격려하세요.
우아한 종료
가능하다면 참여 중인 tunnel이 만료될 때까지 종료를 지연시키세요. 사용자들이 tunnel을 쉽게 중단하지 않도록 하거나, 최소한 확인을 요청하세요.
교육 및 기부
사용자들에게 I2P에 대해 더 자세히 알아볼 수 있는 링크와 기부 링크를 제공하면 좋을 것입니다.
외부 Router 옵션
사용자층과 애플리케이션에 따라, 외부 router를 사용할 수 있는 옵션이나 별도 패키지를 제공하는 것이 도움이 될 수 있습니다.
기타 주제
기타 공통 서비스 사용
다른 일반적인 I2P 서비스들(뉴스 피드, hosts.txt 구독, 트래커, 아웃프록시 등)을 사용하거나 링크할 계획이라면, 해당 서비스들에 과부하를 주지 않도록 주의하고, 서비스를 운영하는 사람들과 대화하여 사용해도 괜찮은지 확인하세요.
시간 / NTP 문제
참고: 이 섹션은 Java I2P를 다룹니다. i2pd는 SNTP 클라이언트를 포함하지 않습니다.
I2P에는 SNTP 클라이언트가 포함되어 있습니다. I2P는 올바른 시간이 있어야 작동합니다. 시스템 시계가 틀어져 있어도 보정하지만 시작이 지연될 수 있습니다. I2P의 SNTP 쿼리를 비활성화할 수 있지만, 애플리케이션에서 시스템 시계가 정확하다는 것을 보장하지 않는 한 권장하지 않습니다.
번들할 항목과 방법 선택하기
참고: 이 섹션은 Java I2P에만 해당됩니다.
최소한 i2p.jar, router.jar, streaming.jar, mstreaming.jar가 필요합니다. 데이터그램 전용 앱의 경우 두 개의 streaming jar를 생략할 수 있습니다. 일부 앱은 i2ptunnel.jar나 addressbook.jar 등 더 많은 jar가 필요할 수 있습니다. 암호화를 훨씬 빠르게 하기 위해 jbigi.jar나 지원하는 플랫폼에 대한 하위 집합을 포함하는 것을 잊지 마세요. 빌드하려면 Java 7 이상이 필요합니다. Debian / Ubuntu 패키지를 빌드하는 경우, 번들로 포함하는 대신 우리 PPA에서 I2P 패키지를 요구해야 합니다. 예를 들어 susimail, susidns, router console, i2psnark는 거의 확실히 필요하지 않습니다.
다음 파일들은 “i2p.dir.base” 속성으로 지정된 I2P 설치 디렉토리에 포함되어야 합니다. reseeding에 필요한 certificates/ 디렉토리와 IP 검증을 위한 blocklist.txt를 잊지 마세요. geoip 디렉토리는 선택사항이지만, router가 위치 기반으로 결정을 내릴 수 있도록 포함하는 것을 권장합니다. geoip를 포함하는 경우, 해당 디렉토리에 GeoLite2-Country.mmdb 파일을 넣어야 합니다 (installer/resources/GeoLite2-Country.mmdb.gz에서 gunzip으로 압축 해제). hosts.txt 파일이 필요할 수 있으며, 애플리케이션에서 사용하는 호스트를 포함하도록 수정할 수 있습니다. 초기 기본값을 재정의하기 위해 베이스 디렉토리에 router.config 파일을 추가할 수 있습니다. clients.config와 i2ptunnel.config 파일을 검토하고 편집하거나 제거하세요.
라이선스 요구사항에 따라 LICENSES.txt 파일과 licenses 디렉터리를 포함해야 할 수 있습니다.
- hosts.txt 파일을 번들로 포함하고 싶을 수도 있습니다.
- 우리의 바이너리를 사용하는 대신 릴리스용 Java I2P를 컴파일하는 경우 bootclasspath를 지정해야 합니다.
Android 고려사항
참고: 이 섹션은 Java I2P에만 해당됩니다.
우리의 Android router 앱은 여러 클라이언트가 공유할 수 있습니다. 설치되지 않은 경우, 사용자가 클라이언트 앱을 시작할 때 설치하도록 안내받게 됩니다.
일부 개발자들은 이것이 좋지 않은 사용자 경험이라고 우려를 표명했으며, 자신들의 앱에 router를 임베드하고 싶어합니다. 저희는 로드맵에 임베딩을 더 쉽게 만들 수 있는 Android router 서비스 라이브러리를 가지고 있습니다. 더 많은 정보가 필요합니다.
도움이 필요하시면 저희에게 연락해 주세요.
Maven jar 파일들
참고: 이 섹션은 Java I2P에만 해당됩니다.
우리는 Maven Central 에 제한된 수의 jar를 보유하고 있습니다. Maven Central에 릴리스된 jar를 개선하고 확장하기 위해 우리가 해결해야 할 수많은 trac 티켓이 있습니다.
도움이 필요하시면 저희에게 연락해 주세요.
데이터그램(DHT) 고려사항
애플리케이션에서 DHT 등을 위해 I2P 데이터그램을 사용하는 경우, 오버헤드를 줄이고 안정성을 높이기 위한 다양한 고급 옵션을 사용할 수 있습니다. 이것이 제대로 작동하도록 하려면 시간과 실험이 필요할 수 있습니다. 크기/안정성 절충점을 고려하세요. 도움이 필요하면 저희에게 문의하세요. 동일한 Destination에서 데이터그램과 스트리밍을 함께 사용하는 것이 가능하며 권장됩니다. 이를 위해 별도의 Destination을 만들지 마세요. 기존 네트워크 DHT(iMule, bote, bittorrent, router)에 관련 없는 데이터를 저장하려고 하지 마세요. 자체적으로 구축하세요. 시드 노드를 하드코딩하는 경우 여러 개를 두는 것을 권장합니다.
Outproxy들
I2P outproxy를 통한 clearnet 접근은 제한된 자원입니다. outproxy는 일반적인 사용자 주도 웹 브라우징이나 기타 제한된 트래픽에만 사용하세요. 다른 용도로 사용하려면 outproxy 운영자와 상의하여 승인을 받으시기 바랍니다.
공동 마케팅
함께 작업해요. 완료될 때까지 기다리지 마세요. 트위터 핸들을 알려주시고 이에 대해 트윗을 시작하면, 저희도 보답하겠습니다.
악성코드
I2P를 악한 목적으로 사용하지 마십시오. 이는 우리 네트워크와 평판 모두에 큰 해를 끼칠 수 있습니다.
함께하기
당연한 말일 수도 있지만, 커뮤니티에 참여하세요. I2P를 24시간 실행하세요. 프로젝트에 대한 I2P 사이트를 만드세요. IRC #i2p-dev에서 대화하세요. 포럼에 글을 올리세요. 소문을 퍼뜨리세요. 사용자, 테스터, 번역가, 심지어 코더까지 구하는 데 도움을 드릴 수 있습니다.
예제
애플리케이션 예제
I2P Android 앱을 설치하고 사용해보며 코드를 살펴보는 것을 권장합니다. 이는 router를 번들링하는 애플리케이션의 예시가 됩니다. 사용자에게 무엇을 노출하고 무엇을 숨기는지 확인해보세요. router를 시작하고 중지하는 데 사용하는 상태 머신을 살펴보세요. 다른 예시로는 Vuze, Nightweb Android 앱, iMule, TAILS, iCloak, Monero가 있습니다.
코드 예제
참고: 이 섹션은 Java I2P에만 해당됩니다.
위의 내용들은 실제로 Java router를 번들하기 위한 코드 작성 방법을 알려주지 않으므로, 다음은 간단한 예제입니다.
import java.util.Properties;
import net.i2p.router.Router;
Properties p = new Properties();
// add your configuration settings, directories, etc.
// where to find the I2P installation files
p.addProperty("i2p.dir.base", baseDir);
// where to find the I2P data files
p.addProperty("i2p.dir.config", configDir);
// bandwidth limits in K bytes per second
p.addProperty("i2np.inboundKBytesPerSecond", "50");
p.addProperty("i2np.outboundKBytesPerSecond", "50");
p.addProperty("router.sharePercentage", "80");
p.addProperty("foo", "bar");
Router r = new Router(p);
// don't call exit() when the router stops
r.setKillVMOnEnd(false);
r.runRouter();
...
r.shutdownGracefully();
// will shutdown in 11 minutes or less
이 코드는 Android 앱에서와 같이 애플리케이션이 router를 시작하는 경우를 위한 것입니다. Java 패키지에서 하는 것처럼 clients.config와 i2ptunnel.config 파일을 Jetty webapps와 함께 사용하여 router가 애플리케이션을 시작하도록 할 수도 있습니다. 언제나 그렇듯이 상태 관리가 어려운 부분입니다.
참고: Router javadocs .