こうしたアプリケーションが急増している大きな理由は、ネットワークを通じて伝達されるデータを階層的に処理するアプローチにあります。 特に、アプリケーション層の機能がデータ転送機能から分離されたことで、ネットワークのデータ転送の仕組みを気にすることなく、アプリケーション層プロトコルを変更したり、新しいアプリケーションを開発したりできるようになりました。 データ転送は他の層の機能であるため、他の開発者の管轄になります。
図のように、アプリケーションがサーバ アプリケーションに要求を送信するときには、アプリケーション層でメッセージが作成され、そのメッセージがクライアント上のさまざまな下位層の機能に引き渡されていきます。 階層を下っていく際に、それぞれの下位層がその層の通信プロトコルを含むヘッダーでデータをカプセル化します。 送信側と受信側のホストに実装されたプロトコルの対話によって、ネットワークでのアプリケーションのエンドツーエンドの伝送が可能になります。
HTTP などのプロトコルは、エンド デバイスへの Web ページの配信などをサポートします。 さまざまな層とその機能について理解したところで、今度は、Web サーバからの Web ページのクライアント要求をたどって、これらの独立した機能がどのように連携するかを確認してみましょう。
TCP/IP モデルを使用すると、完全な通信プロセスは 6 つのステップで構成されます。
データの作成
最初のステップは、送信ソースおよびデバイスのアプリケーション層でデータを作成することです。 この場合、Web クライアントの要求（HTTP GET）を作成した後、データは必要に応じて符号化、圧縮、暗号化されます。 これは TCP/IP モデルのアプリケーション層プロトコルの仕事ですが、これには OSI モデルのアプリケーション層、プレゼンテーション層、セッション層で記述されている機能が含まれます。 アプリケーション層はこのデータをストリームとしてトランスポート層に送信します。
セグメント化と最初のカプセル化
次のステップは、プロトコル スタックを下に移動するデータのセグメント化とカプセル化です。 トランスポート層で、HTTP GET メッセージは小さくて管理しやすい単位に分割され、メッセージの各部分にはトランスポート層ヘッダーが追加されます。 トランスポート層ヘッダーの内部は、メッセージを再構築する方法についてのインジケータです。 また、ポート番号 80 の ID も含まれます。 これは、メッセージが Web サーバ アプリケーション宛であることを宛先サーバに伝えるために使用されます。 クライアントが戻り通信を追跡し、正しいクライアント アプリケーションに転送できるよう、ランダムに生成された送信元ポートも追加されます。