クライアント サーバー アプリケーション用のプロトコルの設計を検討しており、役立つリソースへのリンクが必要です。
大きな部分は、送信される情報の量を最小限に抑えることができるように、独自の「パケット」形式を作成しようとしていることです。彼らのプロトコルを分析するためのリソースを探していますが、SMTP (CLRF で終了する文字列を送信するだけ) など、パケット設計が完全に欠けているものもあるようです。カスタムメイドのパケットを使用するシステムよりも SMTP のようなシステムを使用することの利点/欠点は何ですか? SMTP は数バイトだけを使用して、ビット フラグを介してすべてのコマンドをカバーし、帯域幅/スペースを節約できませんでしたか?
このすべてに頭を悩ませようとしているだけです。
まず第一に、拡張トランスポート プロトコル (UDP 上の RTP など) またはアプリケーション プロトコル (HTTP/SMTP など) を実装しようとしていますか?
プロトコルの設計またはアプリケーションの要求に関して、両方のケースで考慮すべきことがいくつかあります。フロー/輻輳制御、セキュアまたはプレーン。
アプリケーション層プロトコルに向けて、次のことも考慮する必要があります: テキストまたはバイナリ データ、ネットワーク データ ユニット/パケットへのアプリケーション データのマッピング、セキュリティの要求と整合性など。
確かに、SMTP はスペースに対して特に最適化されたわけではなく、パケットベースのプロトコルでもありません。TCP の上に位置し、TCP のストリーム機能を使用します。プロトコルで何が望ましいかを決定する必要があります。それはパフォーマンスに敏感ですか? レイテンシー？帯域幅？
スーパーユーザーとして実行する必要がありますか? そうでない場合は、UDP または TCP を使用することをお勧めします。
配達時の保証は必要ですか？その場合、かなり極端なパフォーマンスやサイズの問題を扱っていない限り、おそらく TCP が最適なオプションです。
最近では、個々のパケットを設計するプロトコルはほとんどありませんが、多くのプロトコルは、TCP またはあまり一般的ではないが UDP を使用して、非常に特殊なデータ構造をネットワーク経由で送信します。
スペースまたは帯域幅を本当に最適化したい場合は、データを可能な限り個々のビットとバイトに凝縮し、TCP 経由で送信する構造を定義およびパッキングすることを検討してください。とにかく、最新のネットワーク アダプタは TCP 用に最適化されているため、他の戦略にはほとんど利点がないことがよくあります。
SMTP、HTTP、およびその他の TCP ベースのプロトコルは、ストリーム ベースであるため、パケットの設計には関与しません。したがって、プロトコル設計について話す方が理にかなっています。
テキストベースのプロトコルとバイナリプロトコルを使用する理由について...
Wiresharkのようなパケット スニッフィング プログラムによるプロトコルの可読性は非常に便利です。
また、単純にポートに telnet で接続し、プレーン テキストを指定してサーバーと通信できると非常に便利な場合がよくあります。
また、HTTP のようなプロトコルでは、実際のリソースは通常、通信のペイロードであり、リソースはバイナリまたはその他の指定された形式にすることができます。したがって、ヘッダーとステータスだけをプレーン テキストにすることは悪いことではありません。