そのため、現在、クライアントには 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.5UDP ポートをターゲットとするパケットを許可するルールを作成します55555。8888あるため、パケットは通過できます。5.5.5.5および UDP ポートのパケットを作成します55555。多くの場合、企業のコンピューターとルーターはセキュリティを確保するためにより制限されているため、ユーザー (IP 5.5.5.5) が企業ネットワーク内にある場合、2 番目のポイントでパケットを制限できます。
実際にはNATのようなものがほとんど常に存在し、ルールはより複雑であるため、非常に単純化されています...しかし、一般的に、内部でどのように機能するかがわかります。