パート 3. HTTP/HTTPS

この資料は「エンタープライズ開発入門」シリーズの一部です。以前の記事:

やあ！今日は、HTTP プロトコルと HTTPS プロトコルについて学びます。ただし、最初に 1 つの点を明確にしておきます。これは、OSI モデルのアプリケーションレベルでネットワーク上でデータを送信するためのプロトコルについて話しているということです。以前の記事で OSI モデルについて説明したことを覚えているかもしれません。覚えていない場合は、ここにあります。

データ通信プロトコルとは何ですか?

これは、さまざまなサービスの開発者が他の人が理解できる形式で情報を送信できるようにする、合意された一連のルールと呼ばれるものです。たとえば、Google Chrome を使用して Facebook と Twitter の両方から情報を取得できます。これは、開発者が標準の HTTP プロトコルを使用して情報を送信し、ブラウザで処理できるためです。統一ルールは、サーバー部分を開発する人々にとって非常に便利です。情報を変換し、適切なプロトコルを使用して送信できるライブラリが多数あります。HTTP は当初、HTML ページを送信するためのプロトコルとして考えられました。これは長い間この方法で使用されてきましたが、現在ではプログラマーが文字列とメディアファイルの両方を送信するためにこの方法をよく使用しています。一般に、このプロトコルは広く受け入れられており多用途であり、非常に使いやすいです。そして、今度はそれを使用する方法を調査します。

HTTPの構造

HTTP プロトコルはテキストのみで構成されていることにすぐに注意してください。私たちが最も興味を持っているのは、このテキストの構造です。各メッセージは次の 3 つの部分で構成されます。

開始行 — これはいくつかのハウスキーピングデータを定義します。
ヘッダー — これらはメッセージパラメーターを説明します。
本文 — メッセージの内容です。本文は空行でヘッダーから区切る必要があります。

HTTP プロトコルは、サーバーにリクエストを送信し、サーバーから応答を受信するために使用されます。リクエストとレスポンスのパラメータは若干異なります。

単純な HTTP リクエストは次のようになります。

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

開始行は次のことを示します。

GET — リクエストのメソッド
/ — リクエストのパス
HTTP/1.1 — プロトコルのバージョン

次にヘッダーが続きます。

ホスト— リクエストの宛先となるホスト
ユーザーエージェント— リクエストを送信するクライアント

メッセージ本文がありません。HTTP リクエストでは、開始行と「Host」ヘッダーのみが必要です。それでは、一度にすべてを 1 ステップずつ見てみましょう。HTTP リクエストには何らかのメソッドが含まれている必要があります。それらは 9 つあります: GET、POST、PUT、OPTIONS、HEAD、PATCH、DELETE、TRACE、CONNECT。最も一般的なのは GET と POST です。最初はこの 2 つの方法で十分です。 GET — このメソッドはサーバーにコンテンツを要求します。したがって、GET メソッドによるリクエストにはメッセージ本文がありません。ただし、必要な場合は、次の形式でパス (開始行) を介してパラメーターを渡すことができます。


https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2

codegym.cc はホスト、 /sendはリクエストのパス、そして ? クエリパラメータが続くことを示す区切り文字です。最後に、キーと値のペア (「key=value」) がアンパサンドで区切られてリストされます。 POST — このメソッドはサーバー上に情報を公開します。POST リクエストでは、「key=value」ペアとしてのパラメーター、JSON、HTML コード、さらにはファイルなど、さまざまな種類の情報を送信できます。すべての情報はメッセージの本文で送信されます。例えば：

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}

リクエストは codegym.cc/user/create/json に送信され、プロトコルのバージョンは HTTP/1.1 です。「Accept」は、クライアントが受信することを期待する応答形式を示します。「Content-Type」は、リクエストで送信されるメッセージボディの形式を示します。「Content-Length」は本文の文字数です。HTTP リクエストにはさまざまなヘッダーを含めることができます。詳細については、プロトコルの仕様を参照してください。

HTTP 応答

リクエストを受信すると、サーバーはそれを処理し、クライアントに応答を送信します。

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

応答の開始行には、プロトコルバージョン (HTTP/1.1)、ステータスコード (200)、およびステータスの説明 (OK) が含まれます。そのヘッダーには、コンテンツのタイプと長さが含まれます。応答本文には、ブラウザが HTML ページとしてレンダリングする HTML コードが含まれています。

応答ステータスコード

メッセージ本文とヘッダーに関してはすべて明らかですが、ステータスコードについては少し触れておく必要があります。応答ステータスコードは常に 3 桁です。コードの最初の桁は、応答のカテゴリを示します。

1xx — 情報。リクエストは受け付けられました。サーバーは続行する準備ができています。
2xx — 成功しました。リクエストは受信され、理解され、処理されました。
3xx — リダイレクト。リクエストを処理するには、追加のアクションを実行する必要があります。
4xx — クライアントエラー。リクエストにエラーが含まれているか、プロトコルに準拠していません。
5xx — サーバーエラー。リクエストは正しく作成されましたが、サーバーはそれを処理できませんでした。

コードの 2 番目と 3 番目の数字は、より具体的な応答を示します。例えば：

200 OK — リクエストは受信され、正常に処理されました。
201 Created — リクエストが受信され、正常に処理されました。その結果、新しいリソースまたはインスタンスが作成されました。
301 Moved Permanently — 要求されたリソースは永久に移動されました。それ以降のリクエストは新しいアドレスを使用して行う必要があります。
307 一時リダイレクト — リソースは一時的に移動されました。現時点では、自動転送を使用してアクセスできます。
403 Forbidden — リクエストは理解されましたが、承認が必要です。
404 Not Found — サーバーはこのアドレスでリソースを見つけられませんでした。
501 Not Implemented — サーバーは、リクエストに応答するために必要な機能をサポートしていません。
505 HTTP バージョンがサポートされていません — サーバーは、指定されたバージョンの HTTP プロトコルをサポートしていません。

応答ステータスコードに加えて、ステータスの説明も送信されます。これは、それぞれの特定のステータスが何を意味するかを明確にするのに役立ちます。

HTTP プロトコルは非常に実用的です。HTTP プロトコルは、クライアントとサーバー間の非常に柔軟な通信を調整するために使用できる多数のヘッダーを提供します。すべてのリクエストおよびレスポンスのヘッダー、リクエストメソッド、およびレスポンスのステータスコードを完全に考慮すると、1 つの記事では多すぎます。必要に応じて、プロトコルの公式仕様を読むことができます、すべてのニュアンスを説明します。HTTP プロトコルはポート 80 で使用するのが一般的であるため、ポート 80 で終わる URL を見た場合は、それにアクセスするには HTTP を使用する必要があると確信できます。テクノロジーが進化し、個人データがインターネット経由で送信され始めると、クライアントがサーバーに送信する情報をさらに保護する方法を考える必要が出てきました。この考えの結果、HTTPS プロトコルが誕生しました。

HTTPSとHTTPの違い

構文の点では、HTTPS は HTTP プロトコルと同じです。つまり、同じ開始行とヘッダーが使用されます。唯一の違いは、追加の暗号化とデフォルトのポート (443)です。HTTPS は、HTTP と TCP の間、つまりアプリケーション層とトランスポート層の間で暗号化されます。その意味を忘れた場合は、OSI モデルに関する記事を確認してください。現在の暗号化標準は TLS です。このトピックについてはあまり深入りしませんが、情報がトランスポート層に到達する前に暗号化が行われることを覚えておいてください。。HTTPS では、リクエストが送信されるホストとポートを除くすべての情報が暗号化されます。HTTP ではなく HTTPS プロトコルを使用するようにサーバーを切り替える場合、サーバーコードを変更する必要はありません。この機能はサーブレットコンテナで有効になります。これについては後続の記事で説明します。今日はここまでです。実は、ちょっと待ってください。HTTP リクエストを実行するには、Google Chrome を開き、F12 キーを押して、[ネットワーク] タブを選択します。ブラウザによって送受信されたすべてのリクエストとレスポンスがここに表示されます。パート 4. Maven の基本パート 5. サーブレットと Java サーブレット API。単純な Web アプリケーションの作成パート 6. サーブレットコンテナーパート 7. MVC (Model-View-Controller) パターンの紹介

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION