HTTPの概要
httpdプロトコルはハイパーテキスト転送プロトコルです。データ（テキスト、画像、クエリ結果など）を転送するためのTCP / IP通信プロトコルに基づいています。
クライアントが静的リソースにアクセスするとき、それは静的ページです。クライアントが静的リソースにアクセスします。これは動的アクセスです（一方的なものもあります）。）、アプリケーション層にあります。
HTTPの3つの特徴
接続なし：
たとえば、データをダウンロードし、データをダウンロードした後に切断します。
独立：
任意のデータタイプのMIMEタイプのコンテンツで
ビデオ、オーディオ、および画像を送信できます。
ステートレス：
メモリ容量がありません。
たとえば、情報が不足した後に再送信する必要があります。tcpとは異なり、tcpにはメモリがあります。
HTTPメッセージ構造
HTTPは、信頼できるリンクを介して情報を交換するクライアント/サーバー（C / S）アーキテクチャモデルに基づいており、ステートレスな要求/応答プロトコルです。
HTTP「クライアント」は、サーバーに接続して1つ以上のHTTP要求をサーバーに送信するアプリケーション（Webブラウザーまたはその他のクライアント）です。
HTTP「サーバー」はアプリケーション（通常はNginx、Apache Webサーバー、IISサーバーなどのWebサービス）でもあり、クライアントから要求を受信し、HTTP応答データをクライアントに送信します。
HTTPは、Uniform Resource Identifier（URI）を使用してデータを送信し、接続を確立します。
HTTPリクエストフロー
1. DNS解決
ブラウザは自身のDNSキャッシュをチェックし、キャッシュを読み取らずにローカルHOSTファイルを読み取ります。DNSシステムコールを開始します（オペレーターがDNSキャッシュ解決を開始するように）。オペレーターは自身のキャッシュをチェックします。反復的なDNS解決要求を開始し（ルートDNSサーバー-> comドメインDNSサーバー）、結果をオペレーティングシステムのカーネルに返し、キャッシュします（次の使用のために）。これは、サーバーのドメイン名に対応するIPを取得するための単純なDNS解決です。
2.TCPプロトコルに基づく3つのハンドシェイク
TCP / IPプロトコルでは、TCPプロトコルは信頼性の高い接続サービスを提供し、3方向ハンドシェイクを使用して接続を確立します。
最初のハンドシェイク：接続を確立するとき、クライアントはサーバーにsynパケット（syn = j）を送信し、サーバーが確認するのを待ってSYN_SEND状態に入ります。2
番目のハンドシェイク：サーバーはsynパケットを受信し、クライアントのSYN（ack = j + 1）を確認し、同時にSYNパケット（syn = k）、つまりSYN + ACKパケットを送信します。このとき、サーバーはSYN_RECV状態になります。3番目のハンドシェイク：クライアントはサーバーからSYN + ACKパケットを受信し、確認応答パケットをサーバーACK（ack = k + 1）に送信します。このパケットが送信され、クライアントとサーバーはESTABLISHED状態になり、スリーウェイハンドシェイクが完了します。スリーウェイハンドシェイクが完了すると、クライアントとサーバーはデータの送信を開始します。
スリーウェイハンドシェイクが完了すると、ホストAとホストBがデータの送信を開始します。
3.クライアント
は、要求メッセージと応答メッセージの形式を定義するリソース要求httpプロトコルをサーバーに送信します。httpメッセージは「tcpプロトコルベースのデータ転送チャネル」を介して送信されますが、httpプロトコルは送信しません。 httpメッセージに注意するテキスト送信の方法は、要求コンテンツと応答コンテンツを標準化する方法です。
クライアントがサーバーにHTTP要求を送信する要求メッセージには、要求行、要求ヘッダー、空白行、および要求データの形式が含まれます。次の図は、要求メッセージの一般的な形式を示しています。
たとえば、Baiduのようなリクエストプロセス：
リクエストライン：
①HTTPリクエスト方式：
HTTP規格によると、HTTPリクエストは複数のリクエスト方式を使用できます。
HTTP1.0は、GET、POST、およびHEADメソッドの3つのリクエストメソッドを定義しています。
HTTP1.1は、OPTIONS、PUT、DELETE、TRACE、およびCONNECTメソッドの5つの新しい要求メソッドを追加します。
主な方法：
GET：単にデータを取得する（index.htmlページを取得する）
POST：ファイルをアップロード/作成する（新しいデータが生成されます）
PUT：データを保存します（ファイル、画像などを上書き/更新します。新しいデータはありません）生成）
DELETE：削除
②URL：
URL ：URL：Uniform Resource Locatorは、リソースの場所を抽象的かつ一意に識別する方法です。
構成：<プロトコル>：// <ホスト>：<ポート> / <パス>
ポートとパスは省略できます（HTTPのデフォルトのポート番号は80です）
③
プロトコルバージョン：プロトコルバージョンの形式はHTTP /メジャーバージョン番号です。マイナーバージョン番号。一般的に使用されるのはHTTP / 1.0とHTTP / 1.1です。
リクエストヘッダー
これらは要求メッセージに固有であり、Acceptヘッダーなど、クライアントが受信するデータのタイプなど、サーバーにいくつかの追加情報を提供します。
データをリクエストする
4.サーバー応答データ
HTTP応答も、ステータス行、メッセージヘッダー、空白行、および応答本文の4つの部分で構成されます。
ステータスライン
ブラウザがWebページにアクセスすると、ビューアのブラウザはWebページが配置されているサーバーにリクエストを送信します。ブラウザがWebページを受信して表示する前に、Webページが配置されているサーバーは、ブラウザの要求に応答するためのHTTPステータスコードを含むサーバーヘッダーを返します。
HTTPステータスコードの英語はHTTPステータスコードです。
一般的なHTTPステータスコードは次のとおりです。
- 200-リクエストが成功しました
- 301-リソース（Webページなど）は他のURLに永続的に転送されます
- 404-要求されたリソース（Webページなど）が存在しません
- 403-サーバーは要求元のクライアントの要求を理解しましたが、要求の実行を拒否しました
- 500内部サーバーエラー
応答ヘッダー
応答ヘッダー：クライアントは、サーバーヘッダーなど、カスタマーサービスが対話しているサーバーの種類などの情報を提供すると便利です。
エンティティヘッダー：エンティティの本体部分を処理するために使用されるヘッダーを参照します。たとえば、エンティティヘッダーは、Content-Typeヘッダーなど、エンティティ本体のデータ型を記述するために使用できます。
| 応答ヘッダー | 説明 |
|---|---|
| 許可する | サーバーがサポートするリクエストメソッド（GET、POSTなど）。 |
| コンテンツエンコーディング | ドキュメントのエンコードメソッド。デコード後にのみ、Content-Typeヘッダーで指定されたコンテンツタイプを取得できます。gzipを使用してドキュメントを圧縮すると、HTMLドキュメントのダウンロード時間を大幅に短縮できます。JavaのGZIPOutputStreamはgzip圧縮を簡単に実行できますが、UnixのNetscapeとWindowsのIE4およびIE5のみがそれをサポートしています。したがって、サーブレットは、Accept-Encodingヘッダー（つまり、request.getHeader（ "Accept-Encoding"））を調べて、ブラウザーがgzipをサポートしているかどうかを確認し、gzipをサポートするブラウザーのgzip圧縮HTMLページを返し、通常のページを返す必要があります。他のブラウザの場合。ページ。 |
| コンテンツの長さ | コンテンツの長さを示します。このデータは、ブラウザが永続的なHTTP接続を使用する場合にのみ必要です。持続的接続を利用したい場合は、出力ドキュメントをByteArrayOutputStreamに書き込み、完了後にそのサイズを確認してから、Content-Lengthヘッダーに値を入力し、最後にbyteArrayStream.writeTo（response）を介してコンテンツを送信できます。 .getOutputStream（）。 |
| コンテンツタイプ | 次のドキュメントが属するMIMEタイプを示します。サーブレットのデフォルトはtext / plainですが、通常はtext / htmlとして明示的に指定する必要があります。Content-Typeが設定されることが多いため、HttpServletResponseは専用のメソッドsetContentTypeを提供します。 |
| 日付 | 現在のGMT時刻。setDateHeaderを使用してこのヘッダーを設定し、時間形式の変換の問題を回避できます。 |
| 有効期限が切れます | ドキュメントの有効期限が切れてキャッシュされなくなったといつ考えるべきですか？ |
| 最終更新日 | ドキュメントが最後に変更された時刻。顧客は、If-Modified-Sinceリクエストヘッダーを介して日付を指定できます。リクエストは条件付きGETとして扱われ、変更時刻が指定された時刻より後のドキュメントのみが返されます。それ以外の場合は、304（未変更）ステータスが返されます。返却されます。Last-Modifiedは、setDateHeaderメソッドを使用して設定することもできます。 |
| ロケーション | 顧客がドキュメントを取得するためにどこに行くべきかを示します。通常、場所は直接設定されませんが、HttpServletResponseのsendRedirectメソッドを介して設定されます。このメソッドは、ステータスコードも302に設定します。 |
| 更新 | ブラウザがドキュメントを更新するまでの時間を秒単位で示します。現在のドキュメントを更新するだけでなく、setHeader（ "Refresh"、 "5; URL = http：// host / path"）を使用して、指定したページをブラウザに読み取らせることもできます。この機能は通常、HTMLページのHEAD領域で<META HTTP-EQUIV = "Refresh" CONTENT = "5; URL = http：// host / path">を設定することで実現されます。これは自動更新のためです。またはリダイレクトCGIまたはサーブレットを使用できないHTMLライターは非常に重要です。ただし、サーブレットの場合は、Refreshヘッダーを直接設定する方が便利です。更新の意味は、「このページを更新するか、N秒ごとに指定されたページにアクセスする」ではなく、「このページを更新するか、指定されたページにN秒後にアクセスする」ことです。したがって、継続的な更新では毎回更新ヘッダーを送信する必要があり、204ステータスコードを送信すると、更新ヘッダーを使用しているか<META HTTP-EQUIV = "Refresh"…>を使用しているかに関係なく、ブラウザーが更新を続行できなくなる可能性があります。Refreshヘッダーは公式のHTTP1.1仕様の一部ではなく、拡張機能ですが、NetscapeとIEの両方がそれをサポートしていることに注意してください。 |
| サーバ | サーバー名。通常、サーブレットはこの値を設定しませんが、Webサーバー自体によって設定されます。 |
| セットクッキー | ページに関連付けられたCookieを設定します。サーブレットはresponse.setHeader（ "Set-Cookie"、…）を使用しないでください。ただし、HttpServletResponseによって提供される特別なメソッドaddCookieを使用する必要があります。以下のCookie設定に関する説明を参照してください。 |
対応するデータ
ルートヘッドタイプはデータを返します
5.ページのレンダリングページをレンダリングする
最新のブラウザのプロセスは次のようになります。HTMLを解析してDOMツリーを構築します->レンダリングツリーを構築します->レンダリングツリーをレイアウトします->レンダリングツリーを描画します。
DOMツリーは、htmlファイル内のタグの配置で構成されています。
レンダリングツリーは、cssまたはhtmlのスタイルスタイルをDOMツリーに追加することによって形成されます。レンダーツリーには、ページに表示する必要のあるDOMエレメントのみが含まれます。たとえば、エレメントや表示属性値がnoneのエレメントは、レンダーツリーにあります。ブラウザは完全なhtmlファイルを受信する前に、ページのレンダリングを開始します。
外部にリンクされたスクリプトタグ、スタイルタグ、および画像に遭遇すると、上記の手順を繰り返すためにhttpリクエストが再度送信されます。cssファイルを受信すると、レンダリングされたページが再レンダリングされ、適切なスタイルが追加されます。画像ファイルをロードすると、すぐに対応する位置に表示されます。このプロセスでは、ページの再描画または再配置がトリガーされる場合があります。
6.サーバーが切断されます（4回ウェーブ）
TCP接続は全二重であるため、各方向を個別に閉じる必要があります。原則として、一方の当事者がデータ送信タスクを完了すると、FINを送信して、この方向の接続を終了できます。FINを受信するということは、この方向にデータフローがないことを意味するだけです。TCP接続は、FINを受信した後もデータを送信できます。最初にシャットダウンした側がアクティブシャットダウンを実行し、もう一方の側がパッシブシャットダウンを実行します。
第一次挥手：TCP 客户端发送一个 FIN，用来关闭客户端到服务器的数据传送。
(第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧)
第二次挥手：服务器收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号。
(第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧)
第三次挥手：服务器关闭客户端的连接，发送一个 FIN 给客户端。
(第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧)
第四次挥手：客户端发回 ACK 报文确认，并将确认序号设置为收到序号加 1 。
(第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧)
================================================= = ================================================ == =============================================== === ============================================== ==== ============================================= ===== ========================================
正しい場合は、ハードブラウジングとウォッチング、気に入ってください（σﾟ∀ﾟ）σ…：*☆