Go TCP プロキシはどのようにしてバイト ストリーム内のサーバーの応答の終わりを確実に判断できるのでしょうか?

Go での TCP プロキシ: データ送信の処理

概要:

TCP プロキシの作成クライアントとサーバー間のデータ中継が含まれます。ただし、サーバーの応答の形式が分からないまま、サーバーがいつすべての必要な情報を送信したかを判断することが課題となります。

TCP バイト ストリームについて:

TCP は次のように動作します。バイト ストリーム。データは連続したバイト シーケンスで送信されます。固定長のメッセージや区切り文字を使用するプロトコルとは異なり、TCP にはメッセージの終わりを示す固有のメカニズムがありません。

ゼロまで読むアプローチ:

コードサーバーから利用可能なデータがない場合、TCP 接続はゼロバイトを読み取ると想定します。ただし、このアプローチには潜在的な欠点があります。

• サーバーが小さな塊で断続的にデータを送信すると、誤った結果が生じる可能性があり、プロキシが最初に読み取ったゼロを応答の終わりとして解釈する可能性があります。
• ネットワーク分断の可能性を無視します。ネットワーク分断では、通信できないにもかかわらず接続が開いたままになり、データに関する誤った仮定が生じます。

代替解決策:

代替アプローチの 1 つは、ソケット タイムアウトよりわずかに短い期間実行を一時停止する「待機」関数を使用することです。後続の読み取りでもゼロバイトが得られる場合は、データが完全に受信されていないと考えて間違いありません。

もう 1 つのオプションは、読み取り操作中に EOF (ファイルの終わり) に達するまで待つことです。ただし、これには、TCP とその EOF の処理についてのより深い理解が必要です。

デッドロックに関する考慮事項:

このコードは、発生する可能性のあるデッドロックの可能性に対処していません。サーバーとクライアントの両方がお互いからのデータを待っている場合。このような問題を防ぐには、適切なエラー処理と同期技術が重要です。

プロキシ実装用の Go ライブラリ:

回答で述べたように、TCP プロキシのコア ロジックGo では、標準ライブラリを使用して簡素化できます。

io.Copy(server, client)
io.Copy(client, server)

このコードは、次のコード間でデータを効果的に中継します。最小限の複雑さでサーバーとクライアントの接続を実現します。

追加メモ:

• 質問で使用されているたとえ (カップが徐々に満たされていく) は、TCP の動作方法を不正確に説明しています。 TCP は送信者と受信者の両方のバッファ スペースを維持し、データが早期に失われないようにします。
• サーバーが「標準/通常の書き込みアルゴリズム」を使用するという前提は保証されておらず、サーバーの実装と状況によって異なる場合があります。
• 「待機」期間にわたって実行を一時停止することによるパフォーマンスへの影響を考慮することが重要です。このような一時停止により、タイムリーな応答を期待しているクライアントに遅れが生じる可能性があります。

以上がGo TCP プロキシはどのようにしてバイト ストリーム内のサーバーの応答の終わりを確実に判断できるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。