発信TCP / IP接続でファイアウォールポートを開く必要がないのはなぜですか？
着信TCP/IPまたはUDP接続を作成するときに、ファイアウォールポートを開くか、指定したポートの特権を取得する必要があります。
発信TCP/IP接続を使用しないのはなぜですか？
実際に発信TCP接続には ファイアウォール も開く必要があります。着信および発信接続もブロックするようにファイアウォールを設定することができます。ファイアウォールに関する上記の記事をご覧ください。
ファイアウォールのデフォルトルールなどがあります。ほとんどの安全な構成には、開く必要のあるいくつかのポートを除いて、すべてをブロックするデフォルトのルールがあります。発信接続の場合、特別なセキュリティ設定がない限り、またはコンピュータ上（またはファイアウォールの「内部」）で実行されるプログラムを信頼しない場合を除いて、デフォルトのルールは「すべてを許可」にすることができます。許可されたポートまたはアドレスにのみ。また、発信接続用にもファイアウォールを開く必要があります。
つまり、ファイアウォールの構成とデフォルトのファイアウォールルールの問題です。
1990年代の旧式または単純化されたファイアウォールの中には、個々のパケットに個別にルールを適用することしかできなかったものもありますが、最新のファイアウォールはすべて、ステートフルパケットインスペクション（SPI）ファイアウォールと呼ばれています。 SPIファイアウォールはトラフィックフローの状態を記憶します（たとえば、発信TCP同期がTCP =セッション）、その状態情報を将来の許可/拒否の決定に適用します（TCPセッションは「内部から」開始されたため、いずれかの方向に流れることを許可するなど）。
多くのホームゲートウェイルーター製品には、完全な機能を備えたファイアウォールすらありませんが、NAT（具体的には「NAPT」、別名「PAT」）が一種の「貧乏人」として機能するという事実に依存していますSPIファイアウォール "。NATゲートウェイにはポートマッピングが必要です。そうしないと、外部から開始された着信時に、接続の試行がNATゲートウェイの外部IPアドレス。状態が記録されていないため、転送先のプライベートサイドクライアントがわかりません。そのため、ゲートウェイをドロップするだけです。ポートマッピングにより、NAT特定の種類の着信要求を転送するクライアントを知るため。
ホストの特定のポートにリスナーを配置する特権を取得することに関して、一部のOSは、1024未満の「WellKnown」ポート、または49152未満の「Registered」ポートにリスナーを配置する機能を制限しますが、ほとんどのOSは通常のユーザーは、49152より上の「エフェメラル」ポートにリスナーを配置します。ポート80（「よく知られている」ポート範囲）または8080（「よく知られている」ポート範囲）で独自のWebサーバープロセスを起動する権限がないことに不満がある場合登録済み）、60080（エフェメラル）で起動してみてください。
発信TCPおよびUDP接続はエフェメラル範囲からポートを自動的に割り当てます（一部のOSは、エフェメラルポートにも「登録済み」範囲の一部を使用する場合があります）。