Webサービスにポート80のみが必要なのはなぜですか？

複数のTCP / IPポートをhttp専用にするのが賢明ではないのはなぜですか？確かに素朴ですが、サーバーのパフォーマンスが何らかの形で向上する可能性があると考えるのは、なんとなく直感的ではありませんか？

ポート80は既知のポートです。つまり、通常はHTTPサーバーを見つける場所としてよく知られています。HTTP / 1.1 RFCに文書化されています。

URIを使用してWebブラウザーに入力する必要がないため、デフォルトを使用すると便利です。非標準ポートでHTTPサーバー（または実際には任意のサービス）を実行する場合、選択した任意の16ビット番号をクライアントに記憶させて入力するように強制します。

この不便さに加えて、パフォーマンス上の利点はありません。ポートは(dst ip:port, src ip:port)、TCP接続を一意に識別する4タプルの一部にすぎません。2つの接続がを共有する場合dst ip:port、それは何らかのシステムリソースを共有することを意味しません-それらは異なるスレッドまたは異なるプロセスに存在できます。

あなたは、両方が論理的に異なるサービスがあれば今、起こり HTTPを使用するように、何もありません問題異なるポート上でそれらを実行しているとは。URIが少し見苦しくなります。

サーバーは、1つ以上のポートで接続を処理することでリソースを無駄にしません。サーバーリソースは接続を処理するために割り当てられ、ポート番号は特定のプログラムを特定の接続に接続する方法にすぎません。

たとえば、HTTPサーバーは、ポート80に着信する接続をリッスンすることを知っています。また、サーバーは、ポート80で何らかの要求を受信するたびに、HTTPサーバーに処理することを知っています。その後、httpサーバーが通信を処理し、リソースを消費します。

ポートは現実のものと考えているようです。IPパケットのヘッダー内のラベルである、ちょうど16ビットの符号なしの数値（0〜65535）。これは、アプリケーションレベルの多重化に役立ちます。着信パケットがネットワークカードに到着すると、OSは通知を受け取ります。着信パケットがどのポートに向けられたかを確認し、パケットを適切なアプリケーションにのみ転送します。Webサーバー（nginx）を実行してポート80でリッスンしている場合、nginxのみがポート80に送信されたパケットを取得します。

クライアント（IP：100.200.100.200）がサーバー（55.55.55.55）にHTTP要求を行うと、サーバー上の宛先ポート80（55.55.55.55:80）にその要求を行いますが、送信元ポートはWebブラウザーのOS（45490など）。WebサーバーからのHTTP応答は（55.55.55.55:80）から送信されますが、宛先（IP）（100.200.100.200:45490）に送信されます。コンピューターのOSは、ポート45490（55.55.55.55:80から）の着信パケットを要求を行ったWebブラウザーに与える必要があることを知っています。クライアントからWebサイトへの一意の接続はそれぞれ一意のランダムポートを取得するため、複数のWebブラウザーが同じWebサイトに接続し、1つのブラウザーでページをリロードしても他のウィンドウは影響を受けません。

各IPパケットには、ヘッダーで使用可能な送信元と宛先の両方のIPアドレスとポートがあります。OSとアプリケーション（WebブラウザーまたはWebサーバー）は両方を使用して、パケットの処理方法に関する適切なアクションを見つけます。

ポート80および443は、HTTP / HTTPSの「デフォルト」ポートです

これは、ポートを（指定する必要がないことを意味http://www.example.com:80、https://www.example.com:443 Webブラウザを使用している場合）。

他のポートでリッスンするWebサーバーが必要な場合、ユーザーは手動でポートをURLに追加するか、その特定のポートへのリンクでエンコードする必要があります。

また、ほとんどのプロキシとファイアウォールは、そうするように特別に設定されていない限り、それらのポートへの接続を許可しません（設定なしでは、発信プロキシはデフォルト以外のポートをリッスンしないため、ファイアウォールは単純にリクエストをウェブサーバーに転送しませんTCP80 / 443以外の接続試行をブロック）

これらはすべて、TCP / IPレベルでできることを制限します。

パフォーマンスを向上させる1つの方法は、TCP80 / 443をリッスンする負荷分散デバイス/サービスを使用して、異なるポートやIP（ローカルバランシング）または異なるリモートサイト（グローバルバランシング）上のサーバーにリクエストをリダイレクトすることです。しかし、これはまったく別のトピックです

余分なポートを追加しても、帯域幅などは追加されません。ポートはパイプよりもラベルに近く、パイプがいっぱいになったために速度を落とすことなく、必要なだけ幅を広げることができます。

サーバーがあまりにも多くのリクエストを受信した場合、サーバーはもちろん速度が低下しますが、これは別のポート番号を追加することで解決できる問題のタイプではありません。

ランダムポートを使用した場合、ユーザーはサイトにアクセスするたびに正しいポート番号を追加する必要があります。すなわちwww.example.com:80; www.example.com:81; www.example.com:82など

より多くのポートを使用してもパフォーマンスは向上しません。各接続のソースポートは一時ポートであり、とにかく異なる

各TCP / IP接続には、sourceIP：sourcePortとdestinationIP：destinationPortがあります。

接続を開始するとき、宛先ポートとして常に80を使用します（サーバーはポート80でHTTPのみをリッスンする必要があり、複数のポートではリッスンしないため、これは理にかなっています）。トリックは、sourcePortが各接続に対して動的であることです。

例：

user1：1.1.1.1:29999から2.2.2.2:80

user2：1.1.1.2:45333から2.2.2.2:80

別のポートを別の物理接続、またはより高いネットワーク帯域幅またはサーバー処理パフォーマンスと間違えないでください。サーバーが取得するのはTCPまたはUDPパケットです。これらのパケットには、アドレスの一部としてポート番号が含まれています。彼らはまだ同じ配線を通り、同じネットワークインターフェースハードウェアとドライバーを通過します。

サーバーに2つのパケットを送信する場合、サーバーがこれらの2つのパケットを処理するために費やすリソースの観点から、2つのうちの1つに異なるポート番号または同じポート番号が関連付けられていても、内部処理は問題になりません。同一に近い。

したがって、これはパフォーマンスを向上させる方法ではありません。

唯一の例外は、同時に実行されている2つの異なるデーモン（または同じコピーの2つ）を2つの異なるポート番号に関連付ける場合、およびこれらの各デーモンが負荷によって非常に大きくスケールアップする場合です。通常はそうではありません。

Remiが述べたように、ポート80と443はHTTP / HTTPSの「デフォルト」ポートです。

ほとんどのネットワークとファイアウォールは、このポートを通過するトラフィックをブロックしません。したがって、ほとんどの場合、ファイアウォールがサービスをブロックすることを心配する必要がないため、このポートの使用は簡単です。そうでない場合は、ファイアウォールルールの再構成と、コンプライアンス/セキュリティからの承認を取得する必要があります。

ここの他のみんなが言っているように、自宅からホストしているのでない限り、ポート80以外のポートでWebサーバーをホストすることは基本的に意味がありません。多くのISPは、スロットルアウトバウンドTCP / UDPポート80および443（IANAは、として定義され、HTTPおよびHTTPS、それぞれ）、この場合、これらのポートを使用するが、等サイトローディング速度、を損なうであろうIANAが 3に割り当てられたHTTP-ALTのためのポートをTCPとUDPの両方。これらは、591、8008、8080です。これらのポートを使用することもできますが、サーバー管理者の命を奪います。

ポート番号のソース：https : //www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml