昨日、同僚と HTTP について話し合いました。なぜ HTTP がプレーンテキストで設計されているのかを尋ねられます。確かに、フラグを使用してさまざまな種類のメソッド (POST、GET) と変数 (HTTP ヘッダー) を表す TCP プロトコルと同様にバイナリ方式で設計できます。では、なぜ HTTP はそのように設計されているのでしょうか。技術的または歴史的な理由はありますか?
10 に答える
技術的な理由と歴史的な理由の 2 つは、Unix の世界ではほとんど常にテキスト プロトコルが好まれるためです。
まあ、これは理由ではなくパターンです。この背後にある理論的根拠は、テキスト プロトコルを使用すると、通過するすべてのものをダンプするだけで、ネットワーク上で何が起こっているかを確認できるからです。TCP/IP に必要なため、専用のアナライザーは必要ありません。これにより、デバッグが容易になり、保守が容易になります。
HTTP だけでなく、多くのプロトコルがテキスト ベースです (FTP、POP3、SMTP、IMAP など)。
この Unix のことのより詳細な説明については、The Art of Unix Programmingをご覧になることをお勧めします。
HTTP では、ほとんどの場合、要求の内容はプロトコルのオーバーヘッドよりも桁違いに大きくなります。プロトコルをバイナリ プロトコルに変換しても、帯域幅はほとんど節約されません。また、テキスト プロトコルが提供する簡単なデバッグ機能は、バイナリ プロトコルのわずかな帯域幅節約よりも簡単に打ち負かされます。
多くのインターネット アプリケーション プロトコルは、多かれ少なかれプロトコルにプレーン テキストを使用します (FTP、POP、SMTP などを参照)。
これにより、相互運用性とトラブルシューティングがはるかに簡単になります。
HTTP は「ハイパーテキスト転送プロトコル」の略です。
これは当初、テキスト ドキュメントを提供する方法として考案されたため、テキスト ベースのプロトコルになりました。
現在 HTTP で行っていることは、当初の意図をはるかに超えています。
HTTP 1.1 の RFC 2616 セクション 3.7.1と同様に、コマンド行またはヘッダーのキー識別子は、テキスト改行 CRLF です。テキストベースのアプリケーション プロトコルにより、Telnet クライアントのみとの会話 (トラブルシューティング用) の実行が容易になります。また、ReadLine() 呼び出しと一致するテキスト文字列を使用したプログラミングが容易になります。
また、CRLF パラメータ ブレークは、ビット オフセットでハードコードする固定サイズの TCP または IP ヘッダーとは異なり、ほぼ無制限の任意のヘッダー拡張を提供します。
では、トラフィックを「読み取る」か、クライアントまたはサーバーを作成する方が簡単ですか?
実際に簡単になるかどうかは議論の余地がありますが、それが意図されていたことは確かです。
歴史的に、すべては RFC822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES) から始まり、その最新バージョンは RFC5322 (Internet Message Format) です。SMTP (RFC 821) は、RFC822 に基づく最も一般的なプロトコルの 1 つです。また、HTTP は SMTP (メール プロトコル) から生まれました。