blog

HTTPプロトコルのコンピュータ・ネットワーク・アプリケーション層

HTTP プロトコルは、クライアントプログラムとサーバープログラムの 2 つのプログラムによって実装されます。HTTP は、Web クライアントが Web サーバーに Web ページを要求する方法と、...

Sep 20, 2013 · 6 min. read
シェア

HTTP プロトコルとは

HTTPプロトコルは、クライアントプログラムとサーバプログラムの2つのプログラムによって実装され、これらは異なるエンドシステム上で実行され、TPメッセージを交換することによってセッションを実行します。

HTTPクライアントはサーバとのCP接続を開始します。接続が確立されると、ブラウザとサーバプロセスはソケットインターフェースを通してTCPにアクセスすることができます。ここで読者が知っておくべきことは、TCP はコネクション指向であり、送信するデータをエラーなく連続的に配送できる信頼性の高いデータ転送サービスを提供するということです。つまり、TCP をバックボーンとして使用する HTTP プロトコルは、データ損失や CP がネットワーク上のデータ損失や故障からどのように回復するかについて心配する必要はありません。

HTTP はステートレスプロトコルなので、サーバはリクエストされたファイルをクライアントに送信するとき、そのクライアントに関する状態情報を一切保存しません。例えば、あるクライアントが同じオブジェクトを数秒の間に二度リクエストした場合、サーバはそのオブジェクトをユーザに提供したばかりなので応答しないのではなく、サーバが何をしたかを完全に忘れたかのようにオブジェクトを再送します。

非持続的接続と持続的接続

クライアント/サーバ間のインタラクションが TCP プロトコル上で実行されるとき、 アプリケーションからの各リクエスト/レスポンスのペアが別々の TCP 接続を介して送信される場合、 アプリケーションは非持続的接続を使用し、アプリケーションからの各リクエスト/レスポンスのペアが 同じ TCP 接続を介して送信される場合、持続的接続を使用します。

1.まず、非パーシステント接続について見てみましょう。

非持続的接続の場合、サーバは応答を送信した後にTCP接続を閉じます。ラウンド・トリップ・タイムRTTは、小さなパケットがクライアントからサーバに移動し、再びクライアントに戻るまでにかかる時間として定義されます。つまり、RTTにはパケット伝播遅延、アライメント遅延、パケット処理遅延が含まれます。

HTTPプロトコルは、トランスポート層としてCPプロトコルに基づいていることを知っているので、TPの使用とサーバへのCP接続の開始との間の接続を確立するために、CPは "3ハンドシェイク "プロセスが含まれます。3つのハンドシェイク "の詳細については、CPの記事で後述しますが、ここでは、クライアントがサーバに小さなCPメッセージセグメントを送信し、サーバは小さなメッセージセグメントで確認と応答を行い、最後にクライアントがサーバに確認を返す、ということだけ知っていればよいでしょう。3つのハンドシェイクの最初の2つの部分を完了した後、クライアントは3つのハンドシェイクの3番目の部分とTPリクエストメッセージを組み合わせて、そのCP接続に送信することに注意してください。要求メッセージがサーバに到達すると、サーバはその CP 接続に ML ファイルを送信します。上記の説明から、非パーシステント接続の場合、TP リクエスト/レスポンスに必要な総時間は、2 つの TT+サーバが ML ファイルを転送するのにかかる時間であることが知られています。

2. その後、持続的な接続を調べます。

持続的接続の場合、サーバは応答を送信した後もそのTCP接続を開いたままにします。同じクライアントとサーバ間の後続の要求メッセージと応答メッセージは、同じ接続を介して送信されます。特に、1つの永続的なTCP接続を使用して、完全なWebページを送信することができます。接続が一定時間経過しても使用されない場合、HTTP サーバは接続を閉じます。

同じサーバにある複数のウェブページを、そのサーバから同じクライアントに単一の持続的TCP接続で送信することができます。これにより、保留中のリクエストに対する応答を待つことなく、オブジェクトリクエストを次々に送信することができます。

3.非持続的接続の欠点

まず、非パーシステント接続では、要求されたオブジェクトごとにまったく新しい接続を確立し、維持する必要があります。このような接続のたびに、クライアントとサーバーの両方でTCPバッファと変数が割り当てられるため、サーバーに大きな負担がかかります。第2に、各オブジェクトの伝送遅延は2つのRTT、つまり、TCPを確立するための1つのRTTと、オブジェクトを要求して受信するためのもう1つのRTTになります。

HTTPメッセージフォーマット

1、HTTPリクエストメッセージフォーマット

まず、HTTPリクエストメッセージのメッセージフォーマットを見てみましょう:

最初の行はリクエスト行で、メソッドフィールド、URLフィールド、HTTPバージョン フィールドの3つのフィールドがあります。ほとんどのリクエストは ET メソッドを使います。その後継の行は最初の行と呼ばれます。ETメソッドが使われる場合、エンティティボディは通常空です。一方、STメソッドが使われる場合、エンティティボディは通常、サーバにSTする必要がある内容、例えばウェブページに入力されたデータです。

以下に、実際のHTTPリクエストメッセージを示します:

GET /xxx/page.html HTTP/.1

ホスト:www.xxx.com

接続:閉じる

ユーザーエージェント:Mozilla/4.0

受諾言語: fr

上の図に対応するように、このメッセージの最初の行はリクエスト行を表し、ブラウザはGETメソッドを使ってサーバーにオブジェクトをリクエストし、URLフィールドでは/xxx/page.htmlとアドレスされ、使用されるHTTPバージョンは.1です。

残りの行はヘッダー行で、コロンの前にヘッダーフィールド名があり、その後にフィールドの値が続きます。

Host: www.xxx.com はターゲットが存在するホストを定義します。1行目で提供される情報はWebプロキシキャッシュによって必要とされます。

Connection: close 持続的接続を使いたくないことをサーバーに伝え、要求されたオブジェクトの送信が終わり次第、接続を閉じるようにサーバーに要求します。

User-agent:Mozilla/4.0はユーザーエージェント、つまりサーバーにリクエストを送るブラウザーのタイプを定義するのに使われます。

Accept-language: fr ユーザがオブジェクトのフランス語版を望んでいることを示します。

2、HTTPレスポンスメッセージフォーマット

HTTP レスポンスメッセージのフォーマットは TP リクエストメッセージとは少し異なり,TP レスポンスメッセージのフォーマットは以下のとおりです.

最初の行がステータス行、それに続く行がヘッダー行、最後の行が送信するエンティティボディです。エンティティボディの部分はメッセージのボディで、要求されたオブジェクトそのものを含んでいます。

実際のHTTPレスポンスメッセージを見てみましょう:

HTTP/. 200 OK

接続:閉じる

データ: Thu, 03, Jul, 2013 00:00:00 GMT

サーバー:Apache/1.3.0

最終更新日: 2007年5月6日 (日) 09:23:24 GMT

コンテンツタイプ: text/html

まず、上の図のステータス行に相当する1行目を見てください。 このメッセージでは、ステータス行は、サーバーが使用しているプロトコルがHTTP/.1であること、ステータスコードが00であること、フレーズがOKであることを示しています。つまり、すべてがOKであり、返されたレスポンスメッセージに情報が含まれていることを意味しています。

2行目から5行目までが最初の行です。

Connection: close メッセージの送信後、この TCP 接続を閉じるようにクライアントに指示します。

Dataヘッダー行は、サーバーがこの応答メッセージを生成して送った日時 を示します。これは、サーバーがファイルシステムからオブジェクトを取 得して応答メッセージに挿入した時刻です。

Serverヘッダー行はメッセージがApache Webサーバーによって生成されたことを示し、リクエストメッセージのUser-agentヘッダー行に似ています。

Last-Modifiedヘッダー行は、オブジェクトが作成されたか、最後に修正された日時を示します。

Content-Typeヘッダー行は、エンティティ本体のオブジェクトのファイルタイプを示します。 オブジェクトタイプは、ファイル拡張子ではなく、このヘッダー行を使って正式に示すべきです。

Content-Lengthヘッダー行は、送られるオブジェクトのバイト数を示します。

3、一般的なHTTPステータスコードとフレーズ

200 OK: リクエストは成功し、返されたレスポンスメッセージに情報が含まれています。

301 Moved Permanently: リクエストされたオブジェクトは恒久的に移動され、新しい URL 定義は応答メッセージの Location ヘッダー行で指定されます。クライアントは自動的に新しいURLでオブジェクトを取得できます。

400 Bad Repuest: リクエストがサーバーに理解されなかったことを示す一般的なエラーコード。

404 Not Found: 要求されたドキュメントはサーバー上にありません。

505 HTTP Version Not Supported: サーバーは、要求メッセージに使用された HTTP プロトコルのバージョンをサポートしていません。

Read next

ファーウェイのFusionSphereが通信ネットワークの仮想化革命を促進する

データの洪水の波は、通信事業者は、ネットワークの需要を満たすために強制的にデバイスとパフォーマンスの数を増やす必要がありますが、データの指数関数的な成長の圧力の下で、通信事業者はまだネットワークを構築するための専用のハードウェアを主にしている場合、それは大幅に速度の展開を実施するビジネスの柔軟性を制限するだけでなく、コストを増加させるので、オペレータは、ネットワークアーキテクチャを変更することが不可欠です。

Sep 19, 2013 · 3 min read