アプリケーション層には非常に多くのプロトコルがあります。おそらくRFC▼として公式に規格化されているプロトコルより、特定の企業システムやネットワークアプリケーションごとに定義された独自プロトコルのほうが多いでしょう。トランスポート層以下のプロトコルはOSやネットワーク機器の標準機能で、そこに手を入れるのは難しいから▼でしょう。

　例えばIPv6が出始めの頃は、ルーターがプロトコル番号41（IPv6）を認識せず、パケットを廃棄してしまうケースがよくありました。新しい何かのプロトコルを策定しようとすると、そういった問題に遭遇します。

　そのためトランスポートに枯れたTCP/UDPを利用し、アプリケーション層で独自のプロトコルを考えるほうが対応しやすいのです。

▼RFC
インターネットで使うプロトコルなどの技術仕様文書です。番号で管理され、多くのプロトコルの標準仕様がこの文書で規定されています。RFCはRequest For Commentsの略で、IETF（Internet Engineering Task Force）が管理しています。
▼難しいから
例えば「IPv10」や「NgTCP」とでも呼ぶようなプロトコルを作っても、通信経路すべてのネットワーク機器やOSが対応しないと通信できないからです。

テキストで表現される

　もう1つ、アプリケーション層のプロトコルヘッダーはほとんどテキストで表現されているという特徴があります（図6-1）。これはトランスポート層以下のプロトコルヘッダーが、ビットやバイト単位で表現されているのと対照的です。

図6-1●アプリケーション層のプロトコルヘッダー
図6-1●アプリケーション層のプロトコルヘッダー
アプリケーション層のプロトコルヘッダーはテキストで構成されているものが多い。メールのSMTPヘッダー、WebのHTTPヘッダーなどだ。ともにBNF記法と呼ばれる形式で記述方法が規定されている。様々なヘッダーがあり、L2～4より情報量が一気に増える。
[画像のクリックで拡大表示]

　HTTPヘッダーもSMTPヘッダーも、すべてテキストで人間が読める形式です。テキストで記述することにより、開発やデバッグが容易になるという利点があります。

　またこうした記述のルールは、BNF▼記法で定義されています。BNF記法で定義したHTTPが広がったため、多くの人がHTTPと同様な形でプロトコルを策定した結果、大半のプロトコルはヘッダーをテキストで表現するようになったと筆者は想像しています。

▼BNF
Backus-Naur Formの略です。プログラミング言語の仕様記述などに使われます。