そのため、現在、クライアントには TCP のみを使用しています。クライアントはサーバーに接続し、ソケットを開き、パケットを自由に取得します。しかし、自分のゲームで UDP も使用することにした場合はどうなりますか? 彼らはポートを開く必要がありますか?たとえば、彼らが通常の WiFi を使用している場合、ポートを開かずにクライアントに UDP を送信できますか?
ありがとう。
そのため、現在、クライアントには TCP のみを使用しています。クライアントはサーバーに接続し、ソケットを開き、パケットを自由に取得します。しかし、自分のゲームで UDP も使用することにした場合はどうなりますか? 彼らはポートを開く必要がありますか?たとえば、彼らが通常の WiFi を使用している場合、ポートを開かずにクライアントに UDP を送信できますか?
ありがとう。
TCP と UDP は、トランスポート層の実装の 2 つの例にすぎません。どちらも「ポート」という用語を使用して、着信パケットを受信するアプリを決定していますが、ルーター/スイッチ/ファイアウォールなどによって異なる方法でルーティング/フィルター処理される可能性があります。
したがって、答えはノーです。ポートを開く際にも同様の問題が発生します。「TCP ポート xxx を開く必要がある」以外は、「UDP ポート xxx を開く必要がある」と要求する必要があります。
ほとんどのホーム ネットワークでは、ファイアウォール ルールにより、任意のリモート ポート (たとえば、このポートを開く必要があるサーバー上) への発信パケット (要求) が許可されます。そして、そのようなパケットがルーターを通過すると、応答が要求パケットのローカル ポートに返されることを許可する一時的なルールが作成されます。
したがって、通常のシナリオは次のようになります。
5.5.5.5
。送信元 UDP ポート55555
、送信元 IP アドレス5.5.5.5
、宛先ポートがあるとします8888
。5.5.5.5
UDP ポートをターゲットとするパケットを許可するルールを作成します55555
。8888
あるため、パケットは通過できます。5.5.5.5
および UDP ポートのパケットを作成します55555
。多くの場合、企業のコンピューターとルーターはセキュリティを確保するためにより制限されているため、ユーザー (IP 5.5.5.5
) が企業ネットワーク内にある場合、2 番目のポイントでパケットを制限できます。
実際にはNATのようなものがほとんど常に存在し、ルールはより複雑であるため、非常に単純化されています...しかし、一般的に、内部でどのように機能するかがわかります。