# ピアプロトコル XRP Ledgerのサーバは、XRP Ledgerピアプロトコル（RTXP）を使用して相互に通信します。 ピアプロトコルは、XRP Ledgerのサーバ間のメイン通信モードです。XRP Ledgerの動作、進捗状況、接続に関するすべての情報がピアプロトコルを通じて伝達されます。ピアツーピア通信の例を以下に示します。 - ピアツーピアネットワーク内の他のサーバへの接続のリクエスト、または接続スロットの使用可能性についてのアドバタイズ。 - ネットワークのその他の部分との候補トランザクションの共有。 - 履歴レジャーへのレジャーデータのリクエスト、またはレジャーデータの提供。 - コンセンサスのための一連のトランザクションの提示、またはコンセンサストランザクションセットの適用に関する算出結果の共有。 ピアツーピア接続を確立するには、サーバどうしをHTTPSで接続し、一方のサーバはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)をリクエストします。（詳細は、[`rippled`リポジトリ](https://github.com/XRPLF/rippled)の[Overlay Network](https://github.com/XRPLF/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)をご覧ください。） ## ピアの検出 XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledgerネットワーク内でサーバが互いを識別できるようにします。サーバは、起動するたびに、以前に接続したその他のあらゆるピアに再接続します。フォールバックとして、[ハードコーディングされた公開ハブ](https://github.com/XRPLF/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525)を使用します。サーバがピアに正常に接続されると、ピアを探している他のXRP Ledgerサーバの接続情報（通常はIPアドレスとポート）をそのピアにリクエストします。その後、サーバはそれらのサーバに接続し、ピア接続するXRP Ledgerサーバの接続情報をさらにリクエストできます。このプロセスにより、サーバは十分なピア接続を確立し、単一のピアへの接続が失われた場合でも、ネットワークの残りの部分にその後も接続されます。 通常、サーバが公開ハブに接続する必要があるのは1回のみです。他のピアを見つけるために、短時間のみ接続します。そうすることで、ネットワーク接続の安定性、ハブのビジー状態、およびサーバが検出する他の高品質ピアの数に応じて、ハブにサーバを引き続き接続するかどうかが異なります。サーバでは、これらの他のピアのアドレスを保存するため、ネットワークの停止後または再起動後、それらのピアへの直接再接続を試行できます。 [peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)は、サーバが現在接続しているピアのリストを示します。 価値の高いサーバ（重要な[バリデータ](/ja/docs/concepts/networks-and-servers/rippled-server-modes#rippled%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E3%83%A2%E3%83%BC%E3%83%89)など）によっては、ピア検出プロセスを通じて、サーバを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%83%94%E3%82%A2)のみを使用するようにサーバを構成できます。 ## ピアプロトコルポート XRP Ledgerに参加するため、`rippled`サーバはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバで[クラスター化されている](/ja/docs/concepts/networks-and-servers/clustering)場合を除き、信頼できないものとして扱われます。） サーバがピアポートで接続を送信 *かつ* 受信できることが理想的です。`rippled`サーバに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](/ja/docs/infrastructure/configuration/peering/forward-ports-for-peering)必要があります。 [デフォルトの`rippled`構成ファイル](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。 例: ``` [port_peer] port = 51235 ip = 0.0.0.0 protocol = peer ``` ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](/ja/docs/references/http-websocket-apis/peer-port-methods/peer-crawler)も処理します。 ## ノードキーペア サーバを初めて起動すると、ピアプロトコル通信でサーバ自体を識別するための *ノードキーペア* が生成されます。サーバはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバのメッセージが信頼できないピアにより中継される場合も同様です。 ノードキーペアはデータベースに保存され、サーバの再起動時に再利用されます。サーバのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/key-generation-methods/validation_create)を使用します。 また、ノードキーペアは、[ピアスロットの](#%E5%9B%BA%E5%AE%9A%E3%83%94%E3%82%A2%E3%81%A8%E3%83%94%E3%82%A2%E3%83%AA%E3%82%B6%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)[クラスタリング](/ja/docs/concepts/networks-and-servers/clustering)または[確保](#%E5%9B%BA%E5%AE%9A%E3%83%94%E3%82%A2%E3%81%A8%E3%83%94%E3%82%A2%E3%83%AA%E3%82%B6%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)のために他のサーバも識別します。サーバクラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバのクラスター化](/ja/docs/infrastructure/configuration/peering/cluster-rippled-servers)をご覧ください。 ## 固定ピアとピアリザベーション 通常、`rippled`サーバでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバへの接続を維持するように`rippled`サーバを構成するには、いくつかの方法があります。 - **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](/ja/docs/concepts/networks-and-servers/clustering)または[プライベートピア](#%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%83%94%E3%82%A2)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバを再起動する必要があります。サーバが同じユーザまたは組織によって実行されている場合、固定ピアは、サーバの接続状態を維持するのに最も有益です。 - **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバは常にそのピアからの接続リクエストを受け入れます。（これにより、サーバでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#%E3%83%8E%E3%83%BC%E3%83%89%E3%82%AD%E3%83%BC%E3%83%9A%E3%82%A2)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバデータベースに保存されるため、サーバがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザや組織が運営するサーバを接続するのに最も有益です。新規: rippled 1.4.0 次の場合、`rippled`サーバは、信頼性の低いピアには接続されません。 - [プライベートピア](#%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%83%94%E3%82%A2)として構成されている場合、サーバは固定ピアに *のみ* 接続されます。 - [スタンドアロンモード](/ja/docs/concepts/networks-and-servers/rippled-server-modes#%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%89%E3%82%A2%E3%83%AD%E3%83%B3%E3%83%A2%E3%83%BC%E3%83%89)で実行されている場合、サーバは *どの* ピアにも接続されません。 ## プライベートピア `rippled`サーバが「プライベート」サーバとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバは1つ以上の非プライベートサーバに接続するように設定されている必要があります。この非プライベートサーバにより、メッセージがネットワークのその他の部分へ中継されます。 [固定ピア](#%E5%9B%BA%E5%AE%9A%E3%83%94%E3%82%A2%E3%81%A8%E3%83%94%E3%82%A2%E3%83%AA%E3%82%B6%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)を使用せずにプライベートサーバを構成すると、サーバはネットワークに接続できないため、ネットワークの状態を認識したり、トランザクションをブロードキャストしたり、コンセンサスプロセスに参加したりすることができません。 サーバをプライベートサーバとして設定すると次のさまざまな影響が生じます。 - サーバがピアツーピアネットワーク内の他のサーバに接続するように明示的に設定されていない場合、サーバは他のサーバに発信接続しません。 - サーバは、他のサーバからの接続を受け入れるように明示的に設定されていない場合、他のサーバからの着信接続を受け入れません。 - サーバはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPIレスポンス](/ja/docs/references/http-websocket-apis/peer-port-methods/peer-crawler)を含む）の中ではサーバのIPアドレスを公開しないように指示します。これは、[peers adminメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)などの信頼できる通信には影響しません。 プライベートサーバの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。新規: rippled 1.2.1 サーバのソースコードを改ざんして、サーバがこのリクエストを無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバを、このように改ざんされていないことが確認されているサーバにのみ接続するように設定してください。 ### ピア接続設定のメリットとデメリット XRP Ledgerで使用できるように、`rippled`サーバをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバがネットワークに接続する方法には、次の3種類の構成があります。 - **検出されたピア**を使用します。サーバは、検出された信頼の低いサーバに接続し、それらのサーバが適切に動作する限り接続を維持します。（たとえば、リクエストするデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](/ja/docs/concepts/networks-and-servers/parallel-networks)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。 - 同じユーザまたは組織が実行する**プロキシを使用したプライベートサーバ**として使用します。プロキシは、プライベートサーバとの固定ピア接続を維持するストック用の`rippled`サーバです（検出されたピアにも接続されます）。 - **公開ハブを使用するプライベートサーバ**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。 各構成のメリットとデメリットは次のとおりです。 table thead tr th 設定 th メリット th デメリット tbody tr th 検出されたピア td ul li p 最もシンプルな構成。メンテナンスの負担が抑えられます。 li p ダイレクトピア接続の機会が多数得られます。ダイレクトピア接続には、いくつかのメリットがあります。サーバは、複数のピアから並行して a 履歴を取得 できます。同期時と履歴の埋め戻し時のいずれも可能です。履歴は、すべてのピアで完全に保持されているわけではないため、アクセスするピアを増やすことで、幅広い履歴データにアクセスすることもできます。 li p 切断されたピアを新しいピアに置き換えることができるため、サーバがネットワークから切断される可能性を抑えることができます。 td ul li p サーバのピアを選択することはできません。つまり、ピアによって悪意のある動作が行われるかどうかは不明です。「rippled」サーバは悪意のあるピアから保護するように設計されていますが、悪意のあるピアがソフトウェアの欠陥を悪用してサーバに影響を及ぼすリスクは常にあります。 li p サーバのピアは頻繁に切断または変更される場合があります。 tr th プロキシを使用したプライベートサーバ td ul li p 最も安全で信頼できる構成（効率的に実装された場合）。 li p 信頼性と冗長性を実現します。 li p a クラスタリング によって、プライベートサーバのパフォーマンスを最適化できます。 li p 必要な数のダイレクトピア接続を作成できます。プライベートサーバでは、複数のピアから並行して a 履歴を取得 できます。複数のピアを実行するため、各ピアで保持するレジャー履歴の量も制御します。 td ul li p 複数のサーバを実行することで、メンテナンスの負担とコストは高くなります。 li p ピア接続が停止する可能性が完全に排除されるわけではありません。実行するプロキシの数に関係なく、それらがすべて同じサーバラックに存在する場合は、1つのネットワーク停止または停電によって、すべてのプロキシに影響が及ぶ可能性があります。 tr th 公開ハブを使用するプライベートサーバ td ul li p 構成がシンプルでメンテナンスの負担を低減できます。 li p 安全なネットワーク接続に簡単にアクセスできます。 li p プロキシを使用して接続する場合と比較して、同時ピア停止によりプライベートサーバがネットワークから切断される可能性を低減できます。 td ul li p 信頼性を維持できるように、評判の高いサードパーティー製品を使用します。 li p 使用する公開ハブが混雑している場合、サーバはネットワークから切断される可能性があります。公開ハブの性質上、ユーザ数が多いため、すべてのユーザに安定した接続を確保することが困難な場合があります。 p この問題を回避するには、使用するハブを増やします。多いほど効果的です。また、デフォルト以外のハブを使用することをお勧めします。ビジー状態になる可能性が低くなります。 ### プライベートサーバの設定 サーバをプライベートサーバとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバの設定](/ja/docs/infrastructure/configuration/peering/configure-a-private-server)をご覧ください。 ## 関連項目 - **コンセプト:** - [コンセンサス](/ja/docs/concepts/consensus-protocol) - [並列ネットワーク](/ja/docs/concepts/networks-and-servers/parallel-networks) - **チュートリアル:** - [rippledサーバのクラスター化](/ja/docs/infrastructure/configuration/peering/cluster-rippled-servers) - [プライベートサーバの設定](/ja/docs/infrastructure/configuration/peering/configure-a-private-server) - [ピアクローラーの設定](/ja/docs/infrastructure/configuration/peering/configure-the-peer-crawler) - [ピアリングのポート転送](/ja/docs/infrastructure/configuration/peering/forward-ports-for-peering) - [特定のピアへの手動接続](/ja/docs/infrastructure/configuration/peering/manually-connect-to-a-specific-peer) - [ピアの最大数の設定](/ja/docs/infrastructure/configuration/peering/set-max-number-of-peers) - [ピアリザベーション](/ja/docs/infrastructure/configuration/peering/use-a-peer-reservation) - **リファレンス:** - [peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers) - [peer_reservations_addメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add) - [peer_reservations_delメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_del) - [peer_reservations_listメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_list) - [connectメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect) - [fetch_infoメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/fetch_info) - [ピアクローラー](/ja/docs/references/http-websocket-apis/peer-port-methods/peer-crawler)