HTTP について知っておくべきこと

1、HTTP

1.1 はじめに

HTTPの概念

ハイパーテキスト転送プロトコル (HyperText Transfer Protocol) は、ブラウザとサーバーの間の関係を規定します。データ転送ルール。

データ送信のルールとは、指定された形式で送信する必要がある要求データと応答データを指します。
特定の形式を知りたい場合は、ブラウザを開き、F12 をクリックして開発者ツールを開き、Network をクリックして以下の図に示すように、特定のリクエストのリクエストデータとレスポンスデータの特定の形式の内容:

ここに画像の説明を挿入します

注: ブラウザで上記のコンテンツが表示されない場合は、ブラウザの閲覧データをクリアする必要があります。 Chrome ブラウザでは Ctrl+Shift+Del を使用してクリアできます。

したがって、HTTP を学習するということは、主にリクエストデータとレスポンスデータの特定の形式の内容を学習することを意味します。

HTTPプロトコルの特性

HTTP プロトコルには、次のような独自の特徴があります。

TCP プロトコルに基づく: 接続指向、安全

TCP は、コネクション指向 (接続を確立する前に 3 ウェイハンドシェイクが必要) で、信頼性の高いバイトストリームベースのトランスポート層通信プロトコルであり、データ送信の安全性が高くなります。
リクエスト-レスポンスモデルに基づく: 1 つのリクエストは 1 つのレスポンスに対応します

リクエストとレスポンスは1対1で対応します
HTTP プロトコルはステートレスプロトコルです。トランザクション処理用のメモリがありません。それぞれのリクエストとレスポンスは独立しています

ステートレスとは、クライアントがサーバーに HTTP リクエストを送信した後、サーバーがリクエストに応じたデータで応答することを意味し、応答後の情報は記録されません。この機能にはメリットもデメリットもあり、
- 欠点: 複数のリクエスト間でデータを共有できない
- 利点: 速い
リクエスト間でデータを共有できないことによって引き起こされる次のような問題。
- 京東ショッピング、加入购物车 と 去购物车结算 は 2 つのリクエストです。
- HTTP プロトコルのステートレスな性質により、ショッピングカートへの追加リクエストへの応答が完了した後、ショッピングカートに追加された商品は記録されません。
- ショッピングカートをチェックアウトするリクエストを開始した後、ショッピングカートに追加された製品を取得できないため、このリクエストではデータが正しく表示されません。
具体的にを使用すると、JD.com でデータが正常に表示されることがわかりました。その理由は、Java がすでにこの問題を考慮し、この問題を解決するために 会话技术(Cookie、Session) の使用を提案しているためです。

1.2 リクエストデータ形式

1.2.1 フォーマットの紹介:

リクエストデータは 3 つの部分に分かれています。リクエストライン、リクエストヘッダー、リクエストボディ

ここに画像の説明を挿入します

リクエストライン: HTTP リクエストのデータの最初の行リクエストラインには、GET [リクエストメソッド] / [リクエスト URL パス] HTTP/1.1 [HTTP プロトコルとバージョン] の 3 つのコンテンツが含まれます。

リクエストメソッドは 7 つあり、最もよく使用されるのは GET と POST です。
リクエストヘッダー：2行目以降はkey:valueの形式になります

リクエストヘッダーにはいくつかの属性が含まれます。一般的な HTTP リクエストヘッダーは次のとおりです。
```
Host: 表示请求的主机名
User-Agent: 浏览器版本,例如Chrome浏览器的标识类似Mozilla/5.0 ...Chrome/79，IE浏览器的标识类似Mozilla/5.0 (Windows NT ...)like Gecko；
Accept：表示浏览器能接收的资源类型，如text/*，image/*或者*/*表示所有；
Accept-Language：表示浏览器偏好的语言，服务器可以据此返回不同语言的网页；
Accept-Encoding：表示浏览器可以支持的压缩类型，例如gzip, deflate等。
```
このデータは何に使用されますか?

例: サーバーは、リクエストヘッダーの内容に基づいてクライアントに関する関連情報を取得できます。この情報を使用して、サーバーは次のようなさまざまなビジネスニーズを処理できます。
- 異なるブラウザーで HTML タグと CSS タグを解析した結果は一貫性がなくなるため、同じコードでもブラウザーが異なれば効果も異なります。
- サーバーは、クライアントのリクエストヘッダー内のデータに基づいてクライアントのブラウザタイプを取得し、異なるブラウザに応じて異なるコードを設定して、一貫した効果を実現できます。
- これは、ブラウザの互換性の問題とよく呼ばれるものです
リクエストボディ: POST リクエストの最後の部分。リクエストパラメータが保存されます。

ここに画像の説明を挿入します

上図で示すように、赤線のボックスの内容がリクエストボディの内容であり、リクエストボディとリクエストヘッダーの間には空行が入っています。この時点で、ブラウザは POST リクエストを送信しています。GET が使用できないのはなぜですか? この時点で、GET リクエストと POST リクエストの違いを確認する必要があります。

GET リクエストのリクエストパラメータはリクエストラインにあり、リクエストボディはありませんが、POST リクエストのリクエストパラメータはリクエストボディにあります。
GET リクエストのリクエストパラメータサイズには制限がありますが、POST には制限がありません。

小结:

リクエストデータには、リクエスト行、リクエストヘッダー、リクエスト本文の 3 つの部分が含まれます。
POST リクエストデータはリクエスト本文にあり、GET リクエストデータはリクエスト行にあります

1.3 レスポンスデータフォーマット

1.3.1 フォーマットの紹介

応答データは 3 つの部分に分かれています。応答ライン、応答ヘッダー、レスポンスボディ

ここに画像の説明を挿入します

応答行: 応答データの最初の行。応答行には、HTTP/1.1 [HTTP プロトコルとバージョン] 200 [応答ステータスコード] ok [ステータスコードの説明] の 3 つの内容が含まれます。

レスポンスヘッダ：2行目以降はkey:value形式となります。

応答ヘッダーにはいくつかの属性が含まれます。一般的な HTTP 応答ヘッダーは次のとおりです。

Content-Type：表示该响应内容的类型，例如text/html，image/jpeg；
Content-Length：表示该响应内容的长度（字节数）；
Content-Encoding：表示该响应压缩算法，例如gzip；
Cache-Control：指示客户端应如何缓存，例如max-age=300表示可以最多缓存300秒

応答本文: 最後の部分。応答データを保存する

上の図では、この部分が応答本文であり、応答ヘッダーから空行で区切られています。

1.3.2 レスポンスステータスコード

応答ステータスコードについては、まず主に 3 つのステータスコードを理解し、後で使用するときに残りをマスターします。

200 ok クライアントリクエストは成功しました
404 Not Found 要求されたリソースが存在しません
500 Internal Server Error サーバー側で予期しないエラーが発生しました。

まとめ

応答データには、応答行、応答ヘッダー、応答本文の 3 つの部分が含まれます。
3 つの応答ステータスコード 200、404、および 500 の意味を理解します。配布は成功、アクセスされたリソースは存在しません、およびサービスエラーです。

ここに画像の説明を挿入します