Minecraft Bedrock は、その歴史の大半で RakNet ——独自の信頼性付き UDP プロトコル——を使ってきました。より新しいビルドでは、WebRTC 上に構築されたトランスポートである NetherNet が追加されています。サーバーを運用している場合、この切り替えによって、クライアントがサーバーを見つける方法、開放するポート、接続の保護方法が変わります。本記事ではこの 2 つを比較します。
| RakNet | NetherNet | |
|---|---|---|
| 基盤 | UDP 上の独自の信頼性付きプロトコル | WebRTC（ICE + DTLS + SCTP データチャネル） |
| 探索 / ステータス | ゲームポート上の非接続の UDP ping/pong | TCP ポート上の HTTP GET /v1/join |
| 接続 | UDP ハンドシェイク、その後 Minecraft のログインパケット | HTTP POST /v1/join/{networkId} で SDP offer/answer を交換し、その後 ICE + DTLS |
| ポート | UDP ポート 1 つ（デフォルト 19132） | TCP のシグナリングポート + UDP メディアポートの範囲 |
| 暗号化 | アプリケーションレベル、ログイン後にネゴシエート | 最初から DTLS（必須、WebRTC 経由） |
| NAT traversal | ポートフォワードが必要 | ICE candidate（host / server-reflexive）、P2P 向けに設計 |
| server.properties | transport=raknet | transport=nethernet |
RakNet は、ゲームポート上の単一の UDP サービスです。クライアントは unconnected ping を送信してサーバーを探索し、サーバーは MOTD 文字列（名前、プロトコル、バージョン、プレイヤー数など）を含む unconnected pong を返します。参加するには、クライアントは RakNet の接続ハンドシェイクを行い、その後、信頼性が確保された UDP チャネル内で Minecraft のログインパケットを送信します。探索・ハンドシェイク・ゲームプレイのすべてが、その 1 つの UDP ポート上で行われます。
NetherNet はブラウザの接続モデルを借用しています。シグナリングは、ゲームが TCP ポート上に開く小さな HTTP サーバー経由で行われます。
GET /v1/join -> ステータス JSON（name, protocol, version, players, …）
POST /v1/join/{networkId} -> サーバーの ICE candidate を含む SDP answerクライアントは SDP offer を送信し、サーバーは、到達可能な UDP エンドポイント（ICE candidate）を列挙した SDP answer を返します。両者はその後 ICE 接続性チェックを実行し、DTLS ハンドシェイクを完了して、SCTP データチャネル上でゲームプレイを伝送します——これはブラウザの WebRTC データチャネルが使うのと同じスタックです。したがって、ゲームプレイは UDP 上を流れますが、そのネゴシエーションは TCP 上の HTTP です。
RakNet では、認証はトランスポートが接続した後に行われる Minecraft のログインシーケンスの一部です。NetherNet は、シグナリングの段階でアイデンティティを付与します。offer には a=identity 属性——トークンが公開鍵に紐付けられた署名付きアサーション——が含まれます（クライアントは DTLS 中に、対応する秘密鍵を保有していることを証明します）。必須の DTLS と組み合わさることで、NetherNet 接続は最初のメディアパケットからエンドツーエンドで暗号化され、サーバーは有効なアイデンティティを欠く offer を、メディアが一切交換される前に拒否できます。
RakNet では、開放が必要な UDP ポートはちょうど 1 つです。NetherNet では 2 つのものが必要です。TCP のシグナリングポートと、UDP メディアポートの範囲（server-udp-ports で設定）です。各保留中のセッションもタイムアウトするまでポートを 1 つ占有するため、同時接続プレイヤー 1 人あたり少なくとも 1 つの UDP ポートに加えて、余裕分が必要です。これはNetherNet で新たに生じるキャパシティプランニング上の考慮点です——範囲が小さすぎると、いっぱいになった時点で接続の拒否が始まります。
NetherNet のシグナリングは素の HTTP なので、通常のリバースプロキシの背後に置けます。大規模なネットワークでは、その前段に nginx と TLS 証明書を置き、UDP メディアは直接流しつつ、シグナリングを HTTPS で提供します。RakNet は独自の UDP プロトコルであるため、これに相当するものがなく——単純に nginx でラップすることはできません。
RakNet は、単純なポートフォワードを前提とします。NetherNet の ICE モデルは candidate アドレスをアドバタイズし、peer-to-peer と NAT traversal を念頭に設計されています。これは、Mojang がクロスプラットフォームプレイや自社運営の「featured」体験に NetherNet を採用した理由の一つでもあります。実際には、公開されて到達可能な専用サーバーであっても、そのシグナリングポートと UDP メディア範囲がインターネットから到達可能である必要があります。
ステータスチェックの方法は異なります。RakNet のモニターは unconnected ping を送信し、pong を解析します。NetherNet のモニターは /v1/join に HTTP リクエストを送ります。NetherNet サーバーを運用しているなら、iceFetch ツールでそのステータスを確認し、アドバタイズしている candidate を正確に確認できます——server-udp-ports のマッピングが正しいパブリックアドレスを公開していることを確かめるのに役立ちます。
NetherNet は Bedrock が向かっている方向であり、最近の Dedicated Server ビルドはこれをデフォルトとしています。RakNet は依然として広く利用されており、運用面ではより単純です（UDP ポート 1 つ、シグナリングサービスなし）。現行ビルドで新しいサーバーを立ち上げるなら、NetherNet を想定し、TCP のシグナリングポートに加えて UDP メディア範囲を計画してください。従来の単一ポートモデルや、RakNet 専用ツールとの互換性が特に必要な場合は、引き続き transport=raknet を選択できます。
RakNet と NetherNet は、同じ問題——Bedrock クライアントをサーバーと通信させること——を、まったく異なる方法で解決します。一方は独自の UDP プロトコル、もう一方は HTTP シグナリング・ICE・DTLS を備えた WebRTC スタックです。NetherNet サーバーのステップバイステップのセットアップ（ポート、systemd、nginx HTTPS）については NetherNet で Bedrock サーバーをセットアップする を、シグナリングのやり取りをより詳しく見るには iceFetch の仕組み を参照してください。