mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-24 05:35:51 +00:00
178 lines
19 KiB
Markdown
178 lines
19 KiB
Markdown
---
|
||
html: peer-protocol.html
|
||
parent: xrpl-servers.html
|
||
blurb: ピアプロトコルは、rippledサーバーが互いに通信する言語を指定します。
|
||
labels:
|
||
- コアサーバー
|
||
- ブロックチェーン
|
||
---
|
||
# ピアプロトコル
|
||
|
||
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/ripple/rippled)の[Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。）
|
||
|
||
## ピアの検出
|
||
|
||
XRP Ledgerでは、「ゴシップ」プロトコルを使用して、XRP Ledgerネットワーク内でサーバーが互いを識別できるようにします。サーバーは、起動するたびに、以前に接続したその他のあらゆるピアに再接続します。フォールバックとして、[ハードコーディングされた公開ハブ](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525)を使用します。サーバーがピアに正常に接続されると、ピアを探している他のXRP Ledgerサーバーの接続情報（通常はIPアドレスとポート）をそのピアに要求します。その後、サーバーはそれらのサーバーに接続し、ピア接続するXRP Ledgerサーバーの接続情報をさらに要求できます。このプロセスにより、サーバーは十分なピア接続を確立し、単一のピアへの接続が失われた場合でも、ネットワークの残りの部分にその後も接続されます。
|
||
|
||
通常、サーバーが公開ハブに接続する必要があるのは1回のみです。他のピアを見つけるために、短時間のみ接続します。そうすることで、ネットワーク接続の安定性、ハブのビジー状態、およびサーバーが検出する他の高品質ピアの数に応じて、ハブにサーバーを引き続き接続するかどうかが異なります。サーバーでは、これらの他のピアのアドレスを保存するため、ネットワークの停止後または再起動後、それらのピアへの直接再接続を試行できます。
|
||
|
||
[peersメソッド][]は、サーバーが現在接続しているピアのリストを示します。
|
||
|
||
価値の高いサーバー（重要な[バリデータ](rippled-server-modes.html#rippledサーバーのモード)など）によっては、ピア検出プロセスを通じて、サーバーを信頼性の低いピアに接続しないようにする場合があります。この場合、[プライベートピア](#プライベートピア)のみを使用するようにサーバーを構成できます。
|
||
|
||
|
||
## ピアプロトコルポート
|
||
|
||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||
|
||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。`rippled`サーバーに、[ファイアウォール経由でピアプロトコルに使用するポートを転送する](forward-ports-for-peering.html)必要があります。
|
||
|
||
[デフォルトの`rippled`構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスにおいて、ポート51235で着信ピアプロトコル接続をリッスンします。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||
|
||
例:
|
||
|
||
```
|
||
[port_peer]
|
||
port = 51235
|
||
ip = 0.0.0.0
|
||
protocol = peer
|
||
```
|
||
|
||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
|
||
|
||
## ノードキーペア
|
||
|
||
サーバーを初めて起動すると、ピアプロトコル通信でサーバー自体を識別するための _ノードキーペア_ が生成されます。サーバーはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバーからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバーのメッセージが信頼できないピアにより中継される場合も同様です。
|
||
|
||
ノードキーペアはデータベースに保存され、サーバーの再起動時に再利用されます。サーバーのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバーを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
|
||
|
||
また、ノードキーペアは、[ピアスロットの](#固定ピアとピアリザベーション)[クラスタリング](clustering.html)または[確保](#固定ピアとピアリザベーション)のために他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||
|
||
|
||
## 固定ピアとピアリザベーション
|
||
|
||
通常、`rippled`サーバーでは多数のピアを維持するよう試みるため、信頼性の低いピアの最大数まで自動接続されます。特定のピアサーバーへの接続を維持するように`rippled`サーバーを構成するには、いくつかの方法があります。
|
||
|
||
- **固定ピア**を使用して、IPアドレスに基づき特定の他のピアへの接続を維持します。これは、ピアのIPアドレスが固定されている場合にのみ機能します。固定ピアを構成するには、構成スタンザ`[ips_fixed]`を使用します。これは、[クラスタリング](clustering.html)または[プライベートピア](#プライベートピア)の重要な部分です。固定ピアは構成ファイルで定義されているため、変更を適用するにはサーバーを再起動する必要があります。サーバーが同じユーザーまたは組織によって実行されている場合、固定ピアは、サーバーの接続状態を維持するのに最も有益です。
|
||
- **ピアリザベーション**を使用して、特定のピアに優先順位を付けます。サーバーに特定のピアのピアリザベーションがある場合、既に最大数のピアに接続されていても、サーバーは常にそのピアからの接続要求を受け入れます。（これにより、サーバーでのピアの最大接続数を*超える*可能性があります。）[ノードキーペア](#ノードキーペア)によって確保済みピアを識別するため、可変IPアドレスを持つピアに対してもこれを行うことができます。ピアリザベーションは、管理コマンドを使用して構成され、サーバーデータベースに保存されるため、サーバーがオンラインの場合に調整することができ、再起動後も保存されます。ピアリザベーションは、さまざまなユーザーや組織が運営するサーバーを接続するのに最も有益です。[新規: rippled 1.4.0][]
|
||
|
||
次の場合、`rippled`サーバーは、信頼性の低いピアには接続されません。
|
||
|
||
- [プライベートピア](#プライベートピア)として構成されている場合、サーバーは固定ピアに _のみ_ 接続されます。
|
||
- [スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で実行されている場合、サーバーは _どの_ ピアにも接続されません。
|
||
|
||
|
||
## プライベートピア
|
||
|
||
`rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||
|
||
**注意:** [固定ピア](#固定ピアとピアリザベーション)を使用せずにプライベートサーバーを構成すると、サーバーはネットワークに接続できないため、ネットワークの状態を認識したり、トランザクションをブロードキャストしたり、コンセンサスプロセスに参加したりすることができません。
|
||
|
||
サーバーをプライベートサーバーとして設定すると次のさまざまな影響が生じます。
|
||
|
||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peersメソッド]などの信頼できる通信には影響しません。
|
||
|
||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||
|
||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||
|
||
### ピア接続設定のメリットとデメリット
|
||
|
||
XRP Ledgerで使用できるように、`rippled`サーバーをピアツーピアのオープンネットワークの残りの部分に接続する必要があります。大まかに言えば、`rippled`サーバーがネットワークに接続する方法には、次の3種類の構成があります。
|
||
|
||
- **検出されたピア**を使用します。サーバーは、検出された信頼の低いサーバーに接続し、それらのサーバーが適切に動作する限り接続を維持します。（たとえば、要求するデータはそれほど多くなく、ネットワーク接続は安定しているため、同じ[ネットワーク](parallel-networks.html)をフォローしているように見えます。）デフォルトでは、この構成に設定されています。
|
||
- 同じユーザーまたは組織が実行する**プロキシを使用したプライベートサーバー**として使用します。プロキシは、プライベートサーバーとの固定ピア接続を維持するストック用の`rippled`サーバーです（検出されたピアにも接続されます）。
|
||
- **公開ハブを使用するプライベートサーバー**として使用します。プロキシを使用する構成と似ていますが、サードパーティーによって異なります。
|
||
|
||
各構成のメリットとデメリットは次のとおりです。
|
||
|
||
|
||
<table>
|
||
<thead><tr>
|
||
<th>設定</th> <th>メリット</th> <th>デメリット</th>
|
||
</tr></thead>
|
||
<tbody>
|
||
<tr><th>検出されたピア</th>
|
||
<td><ul>
|
||
<li><p>最もシンプルな構成。メンテナンスの負担が抑えられます。</p></li>
|
||
<li><p>ダイレクトピア接続の機会が多数得られます。ダイレクトピア接続には、いくつかのメリットがあります。サーバーは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。同期時と履歴の埋め戻し時のいずれも可能です。履歴は、すべてのピアで完全に保持されているわけではないため、アクセスするピアを増やすことで、幅広い履歴データにアクセスすることもできます。</p></li>
|
||
<li><p>切断されたピアを新しいピアに置き換えることができるため、サーバーがネットワークから切断される可能性を抑えることができます。</p></li>
|
||
</ul></td>
|
||
<td><ul>
|
||
<li><p>サーバーのピアを選択することはできません。つまり、ピアによって悪意のある動作が行われるかどうかは不明です。「rippled」サーバーは悪意のあるピアから保護するように設計されていますが、悪意のあるピアがソフトウェアの欠陥を悪用してサーバーに影響を及ぼすリスクは常にあります。</p></li>
|
||
<li><p>サーバーのピアは頻繁に切断または変更される場合があります。</p></li>
|
||
</ul></td>
|
||
</tr>
|
||
<tr><th>プロキシを使用したプライベートサーバー</th>
|
||
<td><ul>
|
||
<li><p>最も安全で信頼できる構成（効率的に実装された場合）。</p></li>
|
||
<li><p>信頼性と冗長性を実現します。</p></li>
|
||
<li><p><a href="clustering.html">クラスタリング</a>によって、プライベートサーバーのパフォーマンスを最適化できます。</p></li>
|
||
<li><p>必要な数のダイレクトピア接続を作成できます。プライベートサーバーでは、複数のピアから並行して<a href="ledger-history.html#履歴の取得">履歴を取得</a>できます。複数のピアを実行するため、各ピアで保持するレジャー履歴の量も制御します。</p></li>
|
||
</ul></td>
|
||
<td><ul>
|
||
<li><p>複数のサーバーを実行することで、メンテナンスの負担とコストは高くなります。</p></li>
|
||
<li><p>ピア接続が停止する可能性が完全に排除されるわけではありません。実行するプロキシの数に関係なく、それらがすべて同じサーバーラックに存在する場合は、1つのネットワーク停止または停電によって、すべてのプロキシに影響が及ぶ可能性があります。</p></li>
|
||
</ul></td>
|
||
</tr>
|
||
<tr><th>公開ハブを使用するプライベートサーバー</th>
|
||
<td><ul>
|
||
<li><p>構成がシンプルでメンテナンスの負担を低減できます。</p></li>
|
||
<li><p>安全なネットワーク接続に簡単にアクセスできます。</p></li>
|
||
<li><p>プロキシを使用して接続する場合と比較して、同時ピア停止によりプライベートサーバーがネットワークから切断される可能性を低減できます。</p></li>
|
||
</ul></td>
|
||
<td><ul>
|
||
<li><p>信頼性を維持できるように、評判の高いサードパーティー製品を使用します。</p></li>
|
||
<li>
|
||
<p>使用する公開ハブが混雑している場合、サーバーはネットワークから切断される可能性があります。公開ハブの性質上、ユーザー数が多いため、すべてのユーザーに安定した接続を確保することが困難な場合があります。</p>
|
||
<p>この問題を回避するには、使用するハブを増やします。多いほど効果的です。また、デフォルト以外のハブを使用することをお勧めします。ビジー状態になる可能性が低くなります。</p>
|
||
</li>
|
||
</ul></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
### プライベートサーバーの設定
|
||
|
||
サーバーをプライベートサーバーとして設定するには、設定ファイルの`[peer_private]`を`1`に設定します。詳細な手順については、[プライベートサーバーの設定](configure-a-private-server.html)を参照してください。
|
||
|
||
|
||
## 関連項目
|
||
|
||
- **コンセプト:**
|
||
- [コンセンサス](consensus.html)
|
||
- [並列ネットワーク](parallel-networks.html)
|
||
- **チュートリアル:**
|
||
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
|
||
- [プライベートサーバーの設定](configure-a-private-server.html)
|
||
- [ピアクローラーの設定](configure-the-peer-crawler.html)
|
||
- [ピアリングのポート転送](forward-ports-for-peering.html)
|
||
- [特定のピアへの手動接続](manually-connect-to-a-specific-peer.html)
|
||
- [ピアの最大数の設定](set-max-number-of-peers.html)
|
||
- [ピアリザベーション](use-a-peer-reservation.html)
|
||
- **リファレンス:**
|
||
- [peersメソッド][]
|
||
- [peer_reservations_addメソッド][]
|
||
- [peer_reservations_delメソッド][]
|
||
- [peer_reservations_listメソッド][]
|
||
- [connectメソッド][]
|
||
- [fetch_infoメソッド][]
|
||
- [ピアクローラー](peer-crawler.html)
|
||
|
||
|
||
<!--{# common link defs #}-->
|
||
{% include '_snippets/rippled-api-links.md' %}
|
||
{% include '_snippets/tx-type-links.md' %}
|
||
{% include '_snippets/rippled_versions.md' %}
|