高遅延環境（接続ごとのトラフィックシェーピングなどがないと仮定して地理的な距離が長いパブリックインターネット）で複数の並列TCP接続を使用してより良いデータ転送速度を実現することは可能ですか、それともTCPは単一の接続で帯域幅全体を利用できますか？
受信者がウィンドウサイズが0のバッファ輻輳を報告しない場合、TCPは可能な限り高速にデータを送信しますか？それで、RTTがたとえば60秒のようなものである場合、それはレートにまったく影響しませんか？最大ウィンドウサイズなど、レートを制限するものはありますか？
複数の同時接続がもたらす利点の 1 つは (dove と Brian が述べたのと同じ注意事項の対象となります)、TCP 受信ウィンドウが小さすぎるという問題をより適切に克服できることです。
これが関係する原則は、帯域幅遅延積です。（こちらに詳しい説明があります）。
簡単な要約: 高レイテンシーで高帯域幅の環境では、TCP などの信頼できる通信は、常に転送中のデータ量によって制限されることがよくあります。複数の接続は、帯域幅遅延積が各接続に個別に適用されるため、これを回避する 1 つの方法です。
さらに詳しくは、次の点を考慮してください。エンドツーエンドの帯域幅が 10^8 ビット/秒 (10 メガビット/秒) で、往復遅延が 100 ミリ秒 (0.1 秒) であるとします。したがって、データの最初のビットの確認応答が送信者に返される前に、最大 10^7 ビット (10 メガビット = ~1.25 メガバイト) のデータが送信される可能性があります。
これは OS の TCP スタックによって異なりますが、TCP 受信ウィンドウ サイズの一般的な値は 64K バイトです。これは明らかに小さすぎて、エンド ツー エンドの帯域幅をフルに活用できません。64 キロバイト (512 キロビット) のデータが送信されると、送信プロセスは受信側からのウィンドウの更新を待ち、一部のデータが消費されたことを示してから、それ以上のデータを送信します。
複数の TCP セッションを開くと、各 TCP セッションが独自の送受信バッファーを持つため、これを回避できます。
もちろん、インターネットでは、TCP ウィンドウ サイズや競合などにより、実際に利用可能なエンドツーエンドの帯域幅を判断することは困難です。いくつかのサンプル数値を提供できる場合は、さらに支援できる可能性があります。
検討すべきもう 1 つのオプションは、ソケットを作成するときに、OS 設定を使用してグローバルに、またはソケット オプションを使用してソケットごとに、より大きな受信ウィンドウを設定することです。
リンク上にいるのがあなただけの場合、オーバーヘッドが増加し、速度が低下します。ただし、完全に飽和したリンクを他のユーザーと共有する場合は、システムをゲーム化して全体的な速度を上げる方法です（各接続は単一の接続よりも遅くなりますが、あなたに割り当てられた「タイムスロット」（専門用語は何ですか？今は私を免れています）。
はい。ただし、実装は必ずしも容易ではありません。アカマイなどの CDN は、専用の信頼できるパイプにより、通常送信されるよりも大きなパケットを圧縮することで、パフォーマンスの一部を主張しています。アプリケーションの詳細を知らずに詳細を説明することは困難です。
この問題に関する Muz の説明は的を射ています。
これを利用できるかどうかは、オペレーティング システムでの TCP の実装に依存する可能性があることに注意してください。特に、最良の結果を得るには、 RFC 1323の Window Scale オプションをサポートする TCP スタックが必要です。
さらに、これを機能させるには、いくつかの OS 設定を微調整する必要がある場合があります。Windows では、 TcpWindowSizeと呼ばれるレジストリ設定があり、調整が必要になる場合があります。Microsoft KB Article 224829: Description of Windows 2000 and Windows Server 2003 TCP Featuresがあり、その方法を説明しています。