Instant Messaging のために、TCP の上に独自のアプリケーション層プロトコルを定義したとします。メッセージにはパケット構造を使用しました。対称 (AES) および非対称 (RSA) 暗号化を使用しているため、異なるメッセージ タイプに対して異なるパケット サイズを取得します。今私の質問に。
単一のアプリケーション層パケットを受信したことをソケットから読み取る方法は? どのサイズを指定すればよいですか？
前もって感謝します。
私は2つのアプローチを念頭に置いています。
実際のパケット サイズを表す一定量のバイトを TCP ストリームから読み取り、最後に、以前に収集されたバイト サイズをストリームから再度読み取ります。
ストリームから最大パケット サイズを読み取ります。取得したバイトの実際のサイズを確認し、それがどのメッセージ タイプであったかを判断します。
さて、より一般的な質問です。パケット サイズ、暗号化方式、受信者、送信者などのメタデータを提供する必要がありますか? はいの場合、これらのメタデータも暗号化する必要がありますか?
TCP では、ネットワークから読み取るときに、その時点で受信したバイト数について保証がないことに注意してください。つまり、クライアントは完全なパケットを で送信する可能性がありwrite()ますがread()、同じバイト数を受信するとは限りません。したがって、コードは常にネットワークからいくつかのバイト数を読み取る必要があり、(蓄積されたデータに基づいて) 必要なバイト数を受信したことを確認してから、パケット (タイプ、内容など) を確認することができます。そこの。
一部のアプリケーションは、ネットワーク データの読み取り/書き込みにステート マシン エンコーダー/デコーダーと固定サイズのバッファーを使用します。他のアプリケーションは、「フル パケット」に十分な大きさのバッファを動的に割り当て、「フル パケット」バッファがいっぱいになるまでネットワークからバイトを読み取り続けます。どのアプローチを取るかは、アプリケーションによって異なります。したがって、読み取りに使用するサイズは、コードが完全なパケットを受信したことを保証する方法ほど重要ではありません。
追加のメタデータを暗号化する必要があるかどうかについては、脅威モデル (つまり、プロトコルが防御したい脅威、プロトコルがクライアント/ユーザーに提供する必要がある保証)に大きく依存します。コンテキスト/詳細がなければ、その質問に答える簡単な方法はありません。
お役に立てれば！