私が認識している 2 つの異なる TCP メッセージ フレーミング方法の長所と短所を調べています。
- Delimited: TCP ストリームは、区切り文字バイトを使用して、固定長でないメッセージに分割されます。データを送信するとき、ルーチンはデリミタのメッセージ データをチェックし、それをエスケープして、メッセージ フレームの安全な送信を保証する必要があります。データを受信するとき、ルーチンはフレームをメッセージに分割するために区切り文字バイトを探してストリームを読み取る必要があります。
例: ユーザー [ユーザー名]\nパスワード [パスワード]\n
- 長さのプレフィックス: TCP ストリームは、メッセージの長さを示すために、たとえば 4 バイトのプレフィックスを使用して、所定のサイズのメッセージに分割されます。データを受信すると、ルーチンは最初にプレフィックスを読み取り、メッセージ フレームの長さを決定します。データを送信するとき、ルーチンは送信前に長さプレフィックスをメッセージに追加する必要があります。
例: [MessageLength]User [ユーザー名][MessageLength]Password [Password]
これらの方法はどちらも、サイズが異なり、解釈されるバイトのストリームを含むメッセージ フレームの送信を可能にします。上位レベルのメッセージ構造またはプロトコルは関係ありません。
そのため、私はスケーラビリティとパフォーマンス効率に注意を向けています。ベンチマーク テストを実行して、メッセージ処理を伴わずに最大の効率スループットを得ることができる方法を確認する必要があることに気付きました。
私の現在の考えでは、私は決して専門家ではありません。
区切りメッセージ フレームは、ストリーム内の各バイトをチェックしてメッセージ フレーム区切り文字を確認する必要があるため、受信ルーチン中の効率が低下します。Length-Prefixed メッセージ フレームは、常にプレフィックス バイトを読み取り、残りのメッセージ フレーム ストリームは、メッセージ フレーム全体が受信されるまで、処理されずにバッファに直接送られます。
長さプレフィックス付きのメッセージ フレームは、メッセージ自体の前に送信されるメッセージ プレフィックスとして、送信ルーチン中の効率が低くなります。
私が考えることができる他の要因は次のとおりです。
- 小さなメッセージ フレームが多数あると、Length-Prefixed 構造で送信されるパケットが多くなります。
- デリミタをチェックするために各バイトが読み取られないため、Length-Prefixed 構造を使用すると、多くの大きなメッセージ フレームがはるかに効率的に処理されます。
このトピック全体の光は素晴らしいでしょう。TCP のメッセージ フレーム構造の違いに関する適切なリソースを見つけるのは非常に難しいと思います。