I2P 네트워크 성능: 속도, 연결 및 리소스 관리
I2P 네트워크는 완전히 동적입니다. 각 클라이언트는 다른 노드들에게 알려져 있으며 로컬에서 알고 있는 노드들의 접근 가능성과 용량을 테스트합니다. 접근 가능하고 능력이 있는 노드들만 로컬 NetDB에 저장됩니다. tunnel 구축 과정에서는 이 풀에서 최적의 리소스를 선택하여 tunnel을 구축합니다. 테스트가 지속적으로 진행되기 때문에 노드 풀은 변화합니다. 각 I2P 노드는 NetDB의 서로 다른 부분을 알고 있으며, 이는 각 router가 tunnel에 사용할 서로 다른 I2P 노드 집합을 가지고 있음을 의미합니다. 두 router가 동일한 알려진 노드 하위 집합을 가지고 있더라도, 접근 가능성과 용량에 대한 테스트는 서로 다른 결과를 보일 가능성이 높습니다. 이는 한 router가 테스트할 때 다른 router들이 부하 상태에 있을 수 있지만, 두 번째 router가 테스트할 때는 여유로울 수 있기 때문입니다.
이는 각 I2P 노드가 tunnel을 구축하기 위해 서로 다른 노드들을 사용하는 이유를 설명합니다. 모든 I2P 노드는 서로 다른 지연 시간과 대역폭을 가지고 있기 때문에, (이러한 노드들을 통해 구축되는) tunnel들은 서로 다른 지연 시간과 대역폭 값을 갖게 됩니다. 그리고 모든 I2P 노드가 서로 다른 tunnel들을 구축하기 때문에, 어떤 두 I2P 노드도 동일한 tunnel 집합을 갖지 않습니다.
서버/클라이언트는 “destination"이라고 하며, 각 destination은 최소한 하나의 인바운드 tunnel과 하나의 아웃바운드 tunnel을 가집니다. 기본값은 tunnel당 3홉입니다. 이는 전체 클라이언트-서버-클라이언트 왕복에서 총 12홉(즉, 12개의 서로 다른 I2P 노드)에 해당합니다.
각 데이터 패키지는 서버에 도달하기까지 6개의 다른 I2P 노드를 거쳐 전송됩니다:
client - hop1 - hop2 - hop3 - hopa1 - hopa2 - hopa3 - server
그리고 돌아오는 길에는 6개의 서로 다른 I2P 노드들:
server - hopb1 - hopb2 - hopb3 - hopc1 - hopc2 - hopc3 - client
네트워크의 트래픽은 새로운 데이터를 전송하기 전에 ACK를 필요로 하며, 서버로부터 ACK가 돌아올 때까지 기다려야 합니다: 데이터 전송, ACK 대기, 더 많은 데이터 전송, ACK 대기. RTT(RoundTripTime)는 각 개별 I2P 노드와 이 왕복 경로상의 각 연결의 지연 시간이 누적되므로, 일반적으로 ACK가 클라이언트에게 돌아오기까지 1-3초가 소요됩니다. TCP와 I2P 전송 설계로 인해 데이터 패키지의 크기는 제한적입니다. 이러한 조건들이 결합되어 tunnel당 최대 대역폭을 20-50 kbyte/sec로 제한합니다. 하지만 tunnel의 단 하나의 hop이라도 5 kb/sec 대역폭만 제공할 수 있다면, 지연 시간 및 기타 제한 사항과 무관하게 전체 tunnel은 5 kb/sec로 제한됩니다.
암호화, 지연시간, 그리고 tunnel이 구축되는 방식으로 인해 tunnel 구축에는 상당한 CPU 시간이 소요됩니다. 이것이 바로 목적지(destination)가 데이터 전송을 위해 최대 6개의 IN tunnel과 6개의 OUT tunnel만 가질 수 있는 이유입니다. tunnel당 최대 50 kb/sec의 속도로, 목적지는 대략 300 kb/sec의 트래픽을 합쳐서 사용할 수 있습니다 (실제로는 익명성이 낮거나 없는 상태에서 짧은 tunnel을 사용하면 더 높을 수 있습니다). 사용 중인 tunnel은 10분마다 폐기되고 새로운 것들이 구축됩니다. 이러한 tunnel 변경과 때때로 종료되거나 네트워크 연결을 잃는 클라이언트들로 인해 tunnel과 연결이 끊어지기도 합니다. 이런 현상의 예는 IRC2P 네트워크에서 연결 끊김(ping timeout)이나 eepget 사용 시에서 볼 수 있습니다.
제한된 목적지 집합과 목적지당 제한된 tunnel 집합으로 인해, 하나의 I2P 노드는 다른 I2P 노드들을 거쳐 제한된 tunnel 집합만을 사용합니다. 예를 들어, I2P 노드가 위의 간단한 예시에서 “hop1"인 경우, 클라이언트로부터 시작되는 참여 tunnel을 1개만 볼 수 있습니다. 전체 I2P 네트워크를 합산하면, 제한된 대역폭으로 구축할 수 있는 참여 tunnel의 수는 상당히 제한적입니다. 이러한 제한된 수를 I2P 노드 수에 분산시키면, 사용 가능한 대역폭/용량의 일부분만이 실제로 사용 가능합니다.
익명성을 유지하기 위해서는 하나의 router가 전체 네트워크에서 tunnel을 구축하는 데 사용되어서는 안 됩니다. 만약 하나의 router가 모든 I2P 노드의 tunnel router 역할을 한다면, 이는 매우 현실적인 중앙 실패 지점이 될 뿐만 아니라 클라이언트의 IP와 데이터를 수집하는 중앙 지점이 됩니다. 이것이 네트워크가 tunnel 구축 과정에서 노드 간에 트래픽을 분산시키는 이유입니다.
성능에 대한 또 다른 고려사항은 I2P가 메시 네트워킹을 처리하는 방식입니다. 각 연결의 홉-홉마다 I2P 노드에서 하나의 TCP 또는 UDP 연결을 사용합니다. 1000개의 연결이 있으면 1000개의 TCP 연결이 생깁니다. 이는 상당히 많은 수이며, 일부 가정용 및 소규모 사무실 router들은 소수의 연결만을 허용합니다. I2P는 이러한 연결을 UDP 및 TCP 유형별로 각각 1500개 미만으로 제한하려고 합니다. 이는 I2P 노드를 통해 라우팅되는 트래픽 양도 제한합니다.
노드가 연결 가능하고 대역폭 설정이 128kbyte/sec 이상 공유되며 24시간 연중무휴로 연결 가능하다면, 일정 시간 후 참여 트래픽을 위해 사용되어야 합니다. 중간에 연결이 끊어지면, 다른 노드들이 수행하는 I2P 노드 테스트를 통해 해당 노드가 연결 불가능하다는 것을 알게 됩니다. 이로 인해 해당 노드는 다른 노드들에서 최소 24시간 동안 차단됩니다. 따라서 해당 노드를 연결 불가능한 것으로 테스트한 다른 노드들은 tunnel 구축에 해당 노드를 24시간 동안 사용하지 않습니다. 이것이 I2P router를 재시작/종료한 후 최소 24시간 동안 트래픽이 낮아지는 이유입니다.
또한 다른 I2P 노드들이 I2P router를 테스트하여 도달 가능성과 용량을 확인하려면 해당 router를 알아야 합니다. 이 과정은 애플리케이션을 사용하거나 I2P 사이트를 방문하는 등 네트워크와 상호작용할 때 더 빨라질 수 있으며, 이는 더 많은 tunnel 구축으로 이어져 네트워크상의 노드들이 테스트할 수 있는 더 많은 활동과 도달 가능성을 제공합니다.
성능 개선
향후 성능 개선 가능성에 대해서는 Future Performance Improvements 를 참조하세요.
과거 성능 개선 사항에 대해서는 성능 기록 을 참조하세요.