「図解HTTP」_html/css_WEB-ITnose

第 1 章、Web とネットワークの基本を理解する

1.2 http

の誕生

HTTP は 1990 年に登場しました。当時、HTTP は正式な標準として確立されていませんでした

HTTP と呼ばれていました。この標準は 1996 年 5 月に正式に発表され、そのバージョンは HTTP/1.0 と名付けられ、現在でもサーバー側で広く使用されています。

HTTP/1.1 は 1997 年 1 月に発表され、現在の主流の HTTP プロトコルのバージョンです。

HTTP/2.0 は開発中です。

1.3 TCP/IP

TCP/IP は特定のプロトコルではなく、インターネットに関連するさまざまなプロトコル ファミリの総称です。詳細については、TCP/IP 詳細学習ノートを参照してください

TCP/IP プロトコル ファミリは、レベルに応じて次の 4 つの層に分かれています:

アプリケーション層: アプリケーション サービスをユーザーに提供する際の通信アクティビティを決定します。この層には、FTP DNS HTTP が含まれます

送信層: 上位のアプリケーション層は、ネットワーク接続内の 2 台のコンピューター間のデータ送信を提供します。 この層には TCP UDP が含まれます

ネットワーク層: ネットワーク上を流れるデータ パケットの処理方法を指定します。パスが相手のコンピューターに到達し、データパケットを相手に送信します

リンク層: ネットワーク接続のハードウェア部分を処理するために使用され、ネットワークカード光ファイバー

TCP/IP 通信送信プロセス (http の例)

まず、アプリケーションでは送信側となるクライアントが使用されます。その層（httpプロトコル）は、あるWebページを閲覧するためにhttpリクエストを発行します。そして、送信の便宜上、アプリケーション層から受信したデータ（httpリクエストメッセージ）をトランスポート層（tcpプロトコル）で分割し、各メッセージにタグシーケンス番号とポート番号を付けてネットワーク層に転送します。 。通信先のMACアドレスはネットワーク層(IPプロトコル)に付加され、リンク層に転送されます。このようにして、ネットワークへの通信要求が完了する。

1.4.1 送信を担うIPプロトコル

IPプロトコルの役割は、様々なデータパケットを相手に送信することです

IPアドレスはノードに割り当てられたアドレスを指定し、MACアドレスはネットワークカードが属する固定アドレス

1.4.2 信頼性を確保するための TCP プロトコル

TCP プロトコルは、ビッグデータの配信を容易にするためにデータを分割し、データが最終的に確実に送信されることを保証するために 3 ウェイ ハンドシェイク戦略を採用しています。相手に届ける

スリーウェイハンドシェイク戦略:

送信側はまずSYN(同期)フラグ付きのデータパケットを相手に送信し、それを受信した後、受信側はSYN(同期)フラグ付きのデータパケットを送り返す。確認情報を伝えるための SYN/ACK フラグ。最後に、送信側はハンドシェイクの終了を表す ACK (確認応答) フラグを付けたデータ パケットを送り返します。

1.5 ドメイン名解決を担当する DNS (Domain Name System) サービス

DNS は、ドメイン名から IP アドレスへの解決サービスを提供します

1.6 http プロトコル通信プロセスにおけるさまざまなプロトコルの役割

プロセスのシーケンスは次のとおりです:

DNS サービス: ユーザーが入力したドメイン名を IP アドレスに解決します

HTTP プロトコル: ターゲット Web サーバーへの HTTP リクエスト メッセージを生成します

TCP プロトコル: 通信を容易にするために、HTTP リクエスト メッセージはメッセージ セグメントに分割されます、それぞれのメッセージセグメントを確実に相手に送信します

IPプロトコル：相手のアドレスを検索し、転送しながら送信します

TCPプロトコル：相手からメッセージセグメントを受信し、それに応じたグループにメッセージを要求しますシーケンス番号へ

HTTPプロトコル: Webサーバーへ リクエストされたコンテンツの処理

1.7 URI/URL

URI (Uniform Resource Identifier) 特定のプロトコルスキームのリソースの位置識別子

URL (Uniform Resource Locator) は、インターネット リソースの特定の場所を表します

第 2 章、簡単な http プロトコル

2.2 通信は、リクエストとレスポンスの交換を通じて実現されます

リクエスト メッセージは、リクエスト メソッド、リクエスト URI、プロトコル バージョン、オプションのリクエストヘッダーフィールドとコンテンツエンティティ。

応答メッセージは基本的に、プロトコル バージョン、ステータス コード、ステータス コードを説明する理由フレーズ、オプションの応答ヘッダー フィールド、およびエンティティ本文で構成されます。

2.3 HTTPは状態を保存しないプロトコルです

HTTPプロトコル自体はリクエストとレスポンスの間の通信状態を保存しません

2.5 サーバーに意図を通知するhttpメソッド

GET:使用URI で識別されるリソースにアクセスします

POST: エンティティの本体を送信するために使用されます

GET メソッドと POST メソッドの違い:

1. Security

GET によって要求されたデータは URL に追加されます(つまり、データは HTTP プロトコル ヘッダーに配置されます)、URL を分割してデータを転送し、パラメータを & で接続します。パラメータは URL 上にクリア テキストで表示され、他の人が簡単に見ることができます。情報は履歴に記録される場合もあります。
POST リクエストは、送信されたデータを HTTP パッケージの本文に配置します。
4. データ長:

HTTP プロトコルでは送信されるデータと URL の長さに制限はありませんが、特定のブラウザーとサーバーには URL の長さに制限があるため、GET を送信する場合、送信されるデータは URL の長さによって制限されます。
POST 操作は URL を介して値を転送しないため、データ長は理論的には無制限です。
7. GET リクエストはキャッシュでき、GET でリクエストされた URL はブラウザのブックマークとして保存できますが、POST リクエストは保存できません。

8. Get はサーバーからデータを取得するために使用され、Post はサーバーにデータを転送するために使用されます。

以下の他のメソッドは一般的に使用されません

PUT: ファイルを転送 HEAD: メッセージ ヘッダーを取得 DELETE: ファイルを削除 OPTUIONS: サポートされているメソッドを尋ねます TRACK: トレース パス CONNECT: プロキシに接続するにはトンネル プロトコルが必要です

2.7 永続的接続の節約 通信量

永続的な接続の利点は、TCP 接続の確立と切断の繰り返しによって生じる追加のオーバーヘッドが軽減され、サーバー側の負荷が軽減されることです。 HTTP/1.1 では、デフォルトですべての接続が永続接続になります

永続接続では、ほとんどのリクエストをパイプライン方式で送信できます。つまり、複数のリクエストを同時に並行して送信できます。

2.8 Cookieを使用した状態管理

Cookie技術は、リクエストメッセージとレスポンスメッセージにCookie情報を書き込むことでクライアントの状態を制御します

Cookieは、サーバーから送信される応答メッセージ内のSet-Cookieと呼ばれる値に基づきますフィールド情報は、クライアントに Cookie を保存するように通知します。次回クライアントがサーバーにリクエストを送信するとき、クライアントはリクエスト メッセージに Cookie 値を自動的に追加して送信します。クライアントから送信された Cookie を受信したサーバーは、どのクライアントが接続リクエストを送信したかを確認し、サーバー上のレコードと比較して、最終的に以前のステータス情報を取得します。

第 3 章、http メッセージ内の http 情報

3.1 HTTP メッセージ

HTTP メッセージは、メッセージヘッダーとメッセージボディの 2 つの部分に分けることができます。通常、この 2 つは最初の空白行によって区切られます。メッセージ本文

3.2 リクエストメッセージとレスポンスメッセージの構造

リクエストライン: リクエストに使用されたメソッド、リクエストURI、HTTPバージョンが含まれます

ステータスライン: レスポンス結果のステータスコード、理由フレーズ、HTTPが含まれますversion

Header フィールド: リクエストと応答のさまざまな条件と属性を表すさまざまなタイプのヘッダーが含まれます。通常、一般ヘッダー、リクエスト ヘッダー、応答ヘッダー、エンティティ ヘッダーが含まれます。 + 標準圧縮)

deflate(zlib)

identity (エンコーディングなし)

3.5 コンテンツの一部を取得するための Range リクエスト (Range Request)

Range リクエストを実行するとき、ヘッダフィールド Range は、コンテンツの指定に使用されます。リソースのバイト範囲

範囲リクエストの場合、応答はステータスコード 206 の応答メッセージを返します 部分的なコンテンツ

3.6 コンテンツネゴシエーションは最も適切なコンテンツを返します

コンテンツネゴシエーションメカニズムとは、クライアントとサーバーが応答をネゴシエートすることを意味しますリソースのコンテンツを選択し、クライアントに最適なリソースを提供します。コンテンツネゴシエーションでは、応答リソースの言語、文字セット、エンコード方式などを判断材料として使用します。ヘッダーフィールドの Accept、Accept-Charset、Accept-Enoding、Accept-Language、Content-Language など

第 4 章、返された結果の http ステータス

4.1 ステータスコードは、サーバーから返されたリクエスト結果を通知します

カテゴリクール

1XX

informational(情報ステータスコード)

受信したリクエストは処理中です

2XX3XX 4XX5XX

4.2 2XX 成功しました

200 OK は、クライアントから送信されたリクエストがサーバー側で正常に処理されたことを意味します

204 No Content は、サーバーによって受信されたリクエストが正常に処理されたことを意味しますが、エンティティの本文は許可されません返される応答メッセージで返される 部分

206 部分コンテンツは、クライアントが範囲リクエストを作成し、サーバーが GET リクエストのこの部分を正常に実行したことを意味します

4.3 3XX リダイレクト

304 未変更は、クライアントが条件付き GET リクエスト、アクセスするリソース (前回のアクセス以降、またはリクエストの条件に従って変更されていないため)

4.4 4XX クライアント エラー

401 Bad Request は、メッセージに構文エラーがあることを示します

403 禁止要求されたリソースへのアクセスがサーバーによって拒否されたことを示します

404 Not Found 要求されたリソースがサーバー上で見つからないことを示します

4.5 5XX Server Error

501 Internet Sever Error サーバー側でエラーが発生したことを示しますリクエストを実行しています

503 Service Unavailable サーバーが一時的に過負荷になっているか、メンテナンスのためにシャットダウンされているため、リクエストを処理できないことを示します。

第 5 章、http と連携する Web サーバー

5.1 単一の仮想ホストを使用します。複数のドメイン名を実装するには

同じIPアドレスの下で、仮想ホストは異なるホスト名とドメイン名を持つ複数のWeb Webサイトをホストできるため、HTTPリクエストを送信する際には、ホスト名またはドメイン名のURIが完全に一致している必要があります。 Hostヘッダーで指定します

5.2.1 プロキシ

プロキシサーバーの基本的な動作は、クライアントから送信されたリクエストを受信し、それを他のサーバーに転送することです。プロキシは、転送時にリクエストURIを変更する必要はありません。 Via ヘッダー フィールドを追加して、受け渡しホスト情報をマークします。

プロキシ サーバーを使用する理由:

キャッシュ テクノロジ (プロキシ キャッシュ) を使用して、ネットワーク帯域幅トラフィックを削減します。

アクセス ログを取得することを主な目的として、組織内の特定の Web サイトのアクセス制御。

5.2.2 ゲートウェイ

ゲートウェイにより、通信回線上のサーバーが非 HTTP サービス (SQL データ クエリ) を提供できるようになります

5.2.3 トンネル

トンネルの目的は、クライアントが安全に通信できるようにすることですサーバーとの接続

第 6 章、http ヘッダー

6.2.4 ヘッダーフィールドのリスト

共通ヘッダーフィールド

Success(成功ステータスコード)	リクエストは正常に処理されました
リダイレクト(重いダイレクトステータスコード)	追加のアクションが必要です リクエストが完了しました
クライアントエラー(クライアントエラーステータスコード)	サーバーはリクエストを処理できません
サーバーエラー(サーバー側)エラーステータスコード) )	リクエスト処理中のサーバーエラー

ヘッダーフィールド名の説明Cache-Controlキャッシュ動作の制御 Cache-制御DateプラグマトレーラーTransfer-EncodingアップグレードVia警告リクエストヘッダーフィールド

ホップバイホップの最初の部分、接続の管理
メッセージ作成日時
メッセージコマンド
最後にヘッダーの概要メッセージの転送エンコーディング
指定レポート 本文の転送エンコード方式
他プロトコルへのアップグレード
プロキシサーバー関連情報
エラー通知

ヘッダーフィールド 名前の説明AcceptAccept-Charset Accept-EncodingAccept-LanguageAuthorizationExpectフォームホストif-Matchif-None-Mathもしも- Modified-Sinceif-Unmodified-Since if-Range Max-ForwardsProy-Authorization Referer範囲TEUser-Agent

レスポンスヘッダーフィールド

ユーザーエージェントが処理できるメディアタイプ
優先キャラクターセット
優先コンテンツエンコーディング
優先言語
Web認証情報
Expectサーバーからの動作
ユーザーのメールアドレス
リクエストされたリソースが存在するサーバー
エンティティタグETagの比較
エンティティタグの比較
リソースの更新時間を比較
リソースの更新時間を比較
リソースが更新されていない場合にエンティティのバイト範囲リクエストを送信
最大送信ホップバイホップ数
サーバーが必要とするエージェントクライアント認証情報
リクエスト内のURIの元のゲッター
エンティティのバイト範囲リクエスト
転送エンコードの優先度
httpクライアントプログラム情報

ヘッダーフィールド名の説明Proxy-Authenticateクライアントのプロキシサーバーの認証情報Petry-Afterリクエストを再開始するタイミングの要件 ServerHTTPサーバーのインストール情報Varyプロキシサーバーのキャッシュ管理情報WWW-Authenticateクライアントのサーバー認証情報

Accept-Range	バイト範囲リクエストを受け入れるかどうか
Age	リソース作成経過時間
ETag	リソースのマッチング情報
Location	指定されたURIにクライアントをリダイレクト

Entityヘッダーフィールド

第 7 章、Web の確保安全なhttps

7.1http 短所

通信はクリアテキストを使用するため、内容が盗聴される可能性があります

通信相手の身元が確認されないため、偽装される可能性があります

メッセージの完全性を証明できないため、送信された可能性があります改ざん

7.2 HTTP+ 暗号化 + 認証 + 整合性保護 = HTTPS

HTTPS はアプリケーション層の新しいプロトコルではなく、実際には HTTP 通信インターフェイス部分が SSL および TLS プロトコルに置き換えられているだけです。 SSL プロトコルのシェル内で

SSL は公開鍵暗号と呼ばれる暗号化処理方式を使用します

公開鍵暗号では、秘密鍵と公開鍵のペアを使用します 暗号文を送信する側は、相手の公開鍵を使用します。暗号化された情報を受け取った後、相手は自分の秘密鍵を使用して復号化します

公開鍵暗号化は共有鍵暗号化よりも複雑であるため、通信中に公開鍵暗号化を使用すると、効率は非常に低くなります。したがって、HTTPS は共有キー暗号化と公開キー暗号化の両方を使用するハイブリッド暗号化メカニズムを採用しています。

ハイブリッド暗号化メカニズムの原理:

公開キー暗号化を使用して共有キーを安全に交換します (共有キーについては後で説明します)。

共有鍵暗号を利用して、交換した秘密鍵の安全性を確保しながら通信を行います。

第8章、アクセスユーザーの身元を確認するための認証
第9章、httpベースの機能追加プロトコル

httpボトルネックを解消する9.2 spdy

httpボトルネック:

1つの接続で送信できるリクエストは1つだけ

リクエストはクライアントからのみ開始でき、クライアントはレスポンス以外の指示を受け取ることができません

リクエスト/レスポンスヘッダーは圧縮せずに送信され、ヘッダー情報が多いほど遅延が大きくなります

長いヘッダーを送信し、毎回同じヘッダーを送信します。より多くの無駄が発生します

データ圧縮形式を任意に選択し、強制的な圧縮を行わずに送信できます

http ボトルネックを排除するようにしてください:

Ajax はサーバーからリアルタイムでコンテンツを取得できるため、大量のリクエスト

Comet コンテンツはリアルタイムで更新できますが、応答を保持するために接続時間が長くなり、より多くのリソースを消費します

SPDY はボトルネックを効果的に排除できますが、Web ウェブサイトが複数のドメイン名でリソースを使用している場合, 改善効果は限定的です

9.3 ブラウザ間の全二重通信にWebSocketを使用します

WebSocketプロトコルの主な特徴:

サーバーからクライアントへデータをプッシュする機能をサポートします

通信量を削減するだけでなく、各接続の総コストは削減されますが、ヘッダー情報も非常に小さくなります

WebSocket 通信を実現するには、前のハンドシェイク要求の場合、Http の Upgrade ヘッダー フィールドの値を WebSocket に設定する必要があります。ハンドシェイクが成功して WebSocket 接続が確立されると、HTTP データ フレームは使用されなくなりますが、WebSocket の独立したデータ フレームが使用されます

WebSocket API

JavaScript は、「WebSocket API」で提供される WebSocket プログラム インターフェイスを呼び出すことができます。 " WebSocket プロトコルで全二重通信を実現します

第 10 章、Web コンテンツ構築技術

第 11 章、Web 攻撃技術