序文

これまでの研究を通じて、合意が実際には合意であり、両当事者が相手方のメッセージを理解する必要があることを私たちはすでに知っています。アプリケーション層のプロトコルはOSに属さず独自にカスタマイズしていますが、双方が理解できる範囲であれば、今日はHTTPプロトコルについて学びましょう。

URL

URLとは:
ここに画像の説明を挿入します

URLコードとURLデコード

URL は http 専用に設計されているわけではありません。URL はすべてのネットワークプロトコルで使用されることが想定されています。ただし、プロトコルでは非 ASCII 文字を使用できないと規定されているため、非文字はエスケープする必要があります。たとえば、図では /?: などが特殊文字として扱われていますが、これらの文字を個別に表現したい場合は、最初に特殊文字をエスケープする必要があります。

ルール:
トランスコードする必要がある文字を 16 進数に変換します。
2 桁ごとに 1 桁を実行し、前に % を追加して、%XY としてコード化します。

例:
16 進数は 0xE4BDA0 (utf-8)
%E4%BD%A0です。

HTTP形式

聞く
1行目: メソッド + URL + バージョン
ヘッダー: 要求された属性、コロンで区切られたキーと値のペア。各グループは \n で区切られます。空白行は終了を示します。
- 接続: 長い接続と短い接続。長い接続では複数の要求を受信できますが、短い接続は応答後に切断されます。
本文: 空白行の後に本文のコンテンツが続きます。本文は空の文字列に設定できます。本文が存在する場合は、本文の長さを識別するためにヘッダーに Content-Length が含まれます。
応答

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

1行目：バージョン番号 + ステータスコード + ステータスコードの説明
ヘッダー: 応答の属性であり、キーと値のペアでもあり、ルールは上記と同じです。
本文: 空白行の下が本文です。サーバーがインターフェイスを返す場合、HTML ページは本文内にあります。

方法

GET と POST が最も一般的で、GET はリソースを取得し、POST はリソースエンティティを送信します。

<form action = "a/c.exe",method="GET">
    姓名：<input type="text" name="myname" value="输入姓名"><br/>
    密码：<input type="text" name="mypass" value=""><br/>
    
    <input type="submit" value="submit"><br/>
</form>

GET メソッドと POST メソッドの違い:
ここに画像の説明を挿入します

ここに画像の説明を挿入します
GET と POST の違い:

データ: GET はデータを URL に置き、POST はデータをテキストに直接置きます。
サイズ: GET は URL サイズによって制限されるため、長すぎることはできません。POST は長くなる可能性があります。
セキュリティ: GET は URL で直接公開されるため、機密データの送信には適していませんが、POST は比較的安全です。

HTTPステータスコード

1XX: 情報ステータスコード、受信したリクエストは処理中です
2XX: 成功ステータスコード。リクエストは正常に処理されます。
3XX: リダイレクトステータスコード: リクエストを完了するには追加のアクションが必要です
4XX: クライアントエラーコード: サーバーはリクエストを処理できません
5XX: サーバーエラーコード: サーバーはリクエストの処理中にエラーを検出しました。

リダイレクト

一時リダイレクト: ブラウザのアドレス情報は変更されません。
永続的なリダイレクト: 永続的なリダイレクトでは、ブラウザーのローカルブックマークが変更されます。

qq のホームページにリダイレクトします。

    std::string response;
    response += "HTTP/1.0 302 Found" + SEP;
    response += "Location: https://www.qq.com/" + SEP;
    response += SEP;

一時的なリダイレクトの主な使用シナリオには、古い Web サイトのメンテナンス、アクティブな広告ジャンプなどが含まれます。
永続的なリダイレクトは、私たちの用途では一般的ではありません。検索エンジンは、ネットワーク全体からデータを定期的にクロールする必要があります。永続的にリダイレクトされた Web サイトがクロールされた場合、彼は、対応するジャンプを直接変更します。

HTTP共通ヘッダー

Content-Type: リクエストのタイプ
Content-Length: 本体の長さ。
ホスト: クライアントは、要求されたリソースがどのホストとポート上にあるかをサーバーに伝えます。
ユーザーエージェント: ユーザーのオペレーティングシステムとブラウザのバージョンを宣言します (クローラ偽造防止情報)
リファラー: 現在のページのリダイレクト元のページ
location: リダイレクトステータスコードを書き込むために 3 とともに使用されます
Cookie: セッション機能を実装するためにクライアントに関する少量の情報を保存します。

セッションの永続性

HTTP 自体はステートレスであるため、アクセスを記憶することができません。http は直接関与しませんが、ユーザーはセッションを維持する必要があるため、ユーザーがオンラインであるかどうかを記録する必要があります。

Cookie は、ユーザー情報をキャッシュするために使用される技術です。ブラウザーは、保存した Cookie 情報を自動的に取得し、対応する Web サイトに送信します。ただし、これにはユーザー情報が直接外部に公開されるため、危険が伴います。 Cookie 情報が仲介業者によって取得されると、Web サイトのアカウントが盗まれるだけでなく、個人情報も盗まれる可能性が非常に高くなります。

現在の一般的な方法は、サーバーがユーザーの情報を均一に維持することです。ログインして確認した後、サーバーはセッションオブジェクトを形成し、セッション ID (一意) をクライアントに返します。クライアントの Cookie ファイルには、このセッション ID のみが保存されます。たとえ途中で傍受されても、ユーザー情報が漏洩する心配はありません。

同時に、サーバーは、IP が異常かどうか、データが異常かどうかなどを検出するなど、特定作業も行います。これらの異常に基づいて、セッションは無効になります。

結論

それにもかかわらず、HTTP プロトコルは依然として安全ではありません。ポストリクエストはブラウザのキャッシュを回避し、直接共有したりブックマークしたりすることはできません。Cookie とセッションもユーザー情報のセキュリティを確保しようとしますが、依然として多くのセキュリティ上の問題があります。これらのセキュリティ問題を解決するには、新しいプロトコルである HTTPS を導入する必要があります。

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

記事ディレクトリ

序文

URL