HTTPプロトコルパッケージについて話す

httpパッケージは主に次の3つの部分に分かれていることがわかっています。

1.リクエストライン

リクエストメソッド、GETおよびPOSTは、DELETE、HEAD、OPTIONS、PUT、TRACEに加えて、最も一般的なHTTPメソッドです。
メッセージヘッダーのHost属性を持つ完全なリクエストURLを形成するURLアドレス。
契約名とバージョン番号。

2.リクエストヘッダー（聞き手）

承認：クライアントが受信できるコンテンツのタイプ（テキスト、画像、またはビデオのタイプ）を指定します。
Accept-Encoding：gzip、brなど、ブラウザでサポートされているデータ形式を指定します。
Accept-Language：受信言語、基本的にはen、zhを実行します
Accept-Charset：エンコーディングを指定します。通常はutf-8です。
Content-Length：要求されたコンテンツの長さ
Cookie：サーバーがユーザーのIDを識別できるように一部のユーザー情報を保存するために使用されます（ログインする必要のあるほとんどのWebサイトがより一般的です）。たとえば、Cookieは一部のユーザーのユーザー名とパスワードを保存します。ユーザーがログインすると、クライアント上に1つ生成されます。Cookieは関連情報の保存に使用されるため、ブラウザはCookie情報を読み取ってサーバー上で確認した後、ユーザーが正当なユーザーであると判断し、対応するWebページ。
ホスト：要求されたサーバーのドメイン名とポート番号を指定します
オリジン：リクエストソース
リファラー：リクエストソースからの特定のWebページリクエストを参照します
User-Agent：HTTPサーバー、クライアントが使用するオペレーティングシステムとブラウザーの名前とバージョンを伝えます。コンテンツには、要求を行ったユーザーの情報が含まれています。
接続：接続状態を示します。通常、ページを開いたが、ビデオの再生などのデータを送信する場合は、tcp接続を閉じないでおく必要があるため、キープアライブ（長い接続）が使用されます。以前は、短い接続のクローズが使用されていました。
Sec-Fetch-Dest：リクエストの宛先、つまり取得したデータの使用方法を示します。

Sec-Fetch-Mode：

cors：跨域请求；XMLHttpRequest 或 Fetch 支持跨源请求。
no-cors：并不是代表请求不跨域，而是服务端不设置cors响应头，图片/脚本/样式表这些请求是容许跨域且不用设置跨域响应头的情况使用。
same-origin：同源请求， 表示不跨境，跟cors跟no-cors不一样，cors跟no-cors是要求服务端设置。
navigate：表示这是一个浏览器的页面切换请求(request)。 navigate请求仅在浏览器切换页面时创建，该请求应该返回HTML；
websocket：建立websocket连接；

Sec-Fetch-Site：

cross-site：跨域请求；
same-origin：发起和目标站点源完全一致；
same-site：有几种判定情况，详见说明；
none：如果用户直接触发页面导航，例如在浏览器地址栏中输入地址，点击书签跳转等，就会设置none；

3.応答ライン

契約名とバージョン番号

ステータスコードと説明

1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

4.応答ヘッダー

Access-Control-Allow-Credentials：trueに設定します。これは、サーバーがCookieをリクエストに含めて、一緒にサーバーに送信することを明確に許可することを意味します。資格情報を使用して実際の要求を行うことができるかどうかを示します。
アクセス制御-公開-ヘッダー：
Access-Control-Allow-Methods：リクエストメソッド
Access-Control-Allow-Origin：資格情報を必要としないリクエストの場合、サーバーはワイルドカードとして「*」を使用して、すべてのドメインがリソースにアクセスできるようにします。
```
如需允许所有资源都可以访问您的资源，您可以如此设置：
Access-Control-Allow-Origin: *
如需允许https://developer.mozilla.org访问您的资源，您可以设置：
Access-Control-Allow-Origin: https://developer.mozilla.org
```
- Content-Length：返されるバイト単位のサイズ
- 経過時間：メッセージヘッダーには、オブジェクトがキャッシュエージェントに保存されている時間の長さが含まれます
- 日付時刻
- Set-Cookie：ページに関連付けられたCookieを設定し、Cookie情報をクライアントに再度送信します

クッキー

HTTPプロトコルはステートレスであるため、つまり、サーバーはユーザーが前回何をしたかを知らないため、対話型Webアプリケーションの実装が大幅に妨げられます。典型的なオンラインショッピングのシナリオでは、ユーザーはいくつかのページを閲覧し、ビスケットの箱と飲み物のボトル2本を購入します。チェックアウトの最後に、HTTPのステートレスの性質により、サーバーはユーザーが追加の手段なしで何を購入したかを知りません。したがって、CookieはHTTPのステートレスを回避するために使用される「追加の手段」の1つです。サーバーは、Cookieに含まれる情報を設定または読み取り、サーバーとの会話中のユーザーの状態を維持できます。

今のショッピングシーンでは、ユーザーが最初のアイテムを購入すると、サーバーはユーザーにCookieを送信し、ユーザーにWebページを送信して、そのアイテムの情報を記録します。ユーザーが別のページにアクセスすると、ブラウザーはCookieをサーバーに送信するため、サーバーはユーザーが以前に購入したものを認識します。ユーザーは引き続き飲み物を購入し、サーバーは元のCookieに新しい製品情報を追加します。チェックアウト時に、サーバーは送信されたCookieを読み取ることができます。

Cookieのもう1つの一般的な用途は、Webサイトにログインするときです。この場合、Webサイトはユーザーにユーザー名とパスワードの入力を求めることが多く、ユーザーは「次回自動的にログインする」をチェックできます。チェックすると、次にユーザーが同じWebサイトにアクセスしたときに、ユーザー名とパスワードを入力せずにログインしたことがわかります。これは、前回のログイン時に、サーバーがログイン資格情報（ユーザー名とパスワードの暗号化された形式）を含むCookieをユーザーのハードディスクに送信したためです。2回目のログイン時に、Cookieの有効期限が切れていない場合、ブラウザはCookieを送信し、サーバーは資格情報を確認するため、ユーザーはユーザー名とパスワードを入力せずにログインできます。

セッション

しかし、問題は、現在の多くのWebサイトが複雑な機能を持ち、多くのデータ相互作用を伴うこともわかっていることです。たとえば、eコマースWebサイトのショッピングカート機能は、大量の情報と複雑な構造を持っています。送信できません。単純なCookieメカニズムを介して。詳細については、CookieフィールドがHTTPヘッダーに格納されていることを知っておく必要があります。この情報を伝達できる場合でも、多くの帯域幅とネットワークリソースを消費します。
セッションはCookieと連携してこの問題を解決できます。たとえば、Cookieはそのような変数sessionID = xxxxを格納し、このCookieをサーバーに渡すだけで、サーバーはこのIDを介して対応するセッションを見つけます。このセッションはのデータ構造です。サーバーは、ユーザーのショッピングカートなどの詳細情報を使用して、その情報を使用してユーザーのカスタマイズされたWebページを返すことができ、ユーザーの追跡の問題を効果的に解決します。
セッションは、Webサイト開発者によって設計されたデータ構造であるため、さまざまなデータを運ぶことができます。クライアントのCookieから一意のセッションIDが渡される限り、サーバーは対応するセッションを見つけてクライアントを認識できます。
もちろん、セッションはサーバーに保存されるため、サーバーのリソースを確実に消費するため、通常、セッションには有効期限があります。サーバーは通常、期限切れのセッションを定期的にチェックして削除します。ユーザーが後でサーバーに再度アクセスした場合、再ログインに直面する可能性があります。対策を待つと、サーバーは新しいセッションを作成し、セッションIDをCookieの形式でクライアントに送信します。