「HTML5プロフェッショナル認定試験レベル1(ver.2.0)」の試験対策の備忘録。
今回は、「HTTP/HTTPSプロトコル」のまとめ。
ちなみに、2014年10月28日にW3Cによって「HTML5」が勧告され、2016年11月1日には「HTML5.1」へ、そして2017年12月14日には「HTML5.2」が勧告されました。2019年5月になって、W3CとWHATWGは“HTML Living standard”をHTML技術仕様の唯一の標準規格とすると合意しました。これにより現在は、WHATWGによって策定された「HTML Living standard」が「HTML5/5.1/5.2」に代わるHTML技術仕様の標準規格となっているが、2021年04月現在「HTML5プロフェッショナル認定試験レベル1(ver.2.0)」の試験範囲のHTMLのバージョンは「HTML5」だそうなので、「HTML5」をもとに書いています。
実際に受験してきた時の結果と感想はこちら↓をご覧ください。
先日、「HTML5プロフェッショナル認定試験レベル1(ver.2.0)」の認定試験を受験してきました。 これまで20年以上、Webサイト制作の仕事に携わってきた私ですが、今回受験してみた率直な感想は... 「[…]
プロトコル(protocol)とは
ネットワークの世界において「プロトコル(protocol)」とは、コンピューター同士が通信を行うための規格(ルール)のことを指します。ちなみに、英語では「 protocol:外交儀礼、議定書」などの意味を持ち、他にも医療の現場では「手順、治療計画」といった意味で使われ、言わばプロトコルは現実世界の「言語」のようなものです。
プロトコルにもたくさんの種類があります。それぞれが役割を果たすことにより、ネットワーク間のクライアントとサーバーのやりとりが可能となります。
HTTP (Hyper Text Transfer Protocol)
Webブラウザがサーバーと通信するときに使われるプロトコル。htmlなどによって記述されたファイルを送受信する際の決まり事。
HTTPS (Hyper Text Transfer Protocol Secure)
HTTPによる通信をよりsecure(安全に)行うためのプロトコル。
FTP (File Transfer Protocol)
ネットワーク上のクライアントとサーバーの間でファイル転送を行うためのプロトコル
SMTP (Simple Mail Transfer Protocol)
インターネットでメールを送信するためのプロトコル。メールソフトからメールサーバーへ電子メールを送信するときに使用する。
POP3 (Post Office Protocol version3)
インターネットでメールを受信するためのプロトコル。メーラーでメールサーバーから電子メールを受信するときに使用する。
IMAP (Internet Message Access Protocol)
インターネットでメールを受信して管理するためのプロトコル。メールをサーバー上で保持し続けることができる。
NTP (Network Time Protocol)
ネットワーク上にある全ての機器の時刻を同期させるためのプロトコル。通信時間による誤差を最小化する機能がある。
DNS (Domain Name System)
ドメインとIPアドレスの管理のためのプロトコル。ドメイン名とIPアドレスの対応を管理する作業を行う。
TCP (Transmission Control Protocol)
正確性や信頼性の高いデータの送信に用いられるプロトコル。データの順序や内容を保証し、確実なデータ転送ができる。
UDP (User Datagram Protocol)
TCPと同じくデータの送信に用いられるが、正確性よりもより速さを重視したプロトコル。動画や音楽のストリーミング、オンラインゲームなどで使用される。
IP (Internet Protocol)
ネットワーク上で各機器にIPアドレス(住所)を割り当て、それをもとに対象にデータを送り届けるためのプロトコル
これらがすべてではなく、他にも多くのプロトコルが存在する。
HTTPプロトコル
HTTP (Hyper Text Transfer Protocol)とは、HTMLや画像などの表示を提供するサーバ(Webサーバ)とWebブラウザに代表されるクライアントとの間でHTML文書などのテキストメッセージを受け渡すためのプロトコル。
HTTPでの通信は、
[TCP接続]→ [HTTPセッション「リクエストメッセージ(URL、パラメータなど)」を送信して、「レスポンスメッセージ(ステータス、HTMLなど)」を受信する
]
→[TCP切断]
というシンプルなもの。
現行バージョンのHTTPは「HTTP/1.1」で、RFC2616で標準化されたもの。
「HTTP/2.0」は2015年2月にIETFで新しい仕様として承認され、RFCとなった。
HTTPSプロトコル
セキュリティを確保した通信路上でHTTP通信することをHTTPSと呼ぶ。
セキュリティの確保には、データを暗号化して送受信するプロトコルであるTLSプロトコル(またはSSLプロトコル)を使用する。
HTTPSでの通信は、まずSSL/TLSセッションを確立し、その後にHTTPセッションを行う。
HTTPSは広く利用されている技術だが、HTTPSを規定したRFCは存在しない。
一方、TLSの最新バージョンTLS1.2はRFC5246で標準化されている。
TLSとSSLの違い
SSLとTLSの違い、および現在「SSL/TLS」と表記される理由は、この2つのプロトコルが開発され、発展してきた経緯によるもの。
SSL(Secure Sockets Layer)は米Netscape社が開発しましたが、SSL1.0は脆弱性が発見されたため、製品に実装されることはありませんでした。
1994年に、SSL1.0を改良した「SSL2.0」がリリースされた際、高機能ウェブブラウザ「Netscape Navigator 1.1」に実装され、SSLが広く一般に知れ渡るようになりました。
その後、SSLはバージョン3.0までが開発されましたが、1999年にはSSL3.0を元にした「TLS(Transport Layer Security)1.0」が定められ、現在は「TLS1.3」までリリースされています。
SSL3.0とTLS1.0は、仕様の違いもごくわずかで仕組みがほぼ同じですが、TLSが登場した段階では既にSSLという名称が広く使われていたために、現在では「TLSのことも含めてSSLと呼ぶ」または「SSL/TLS」「TLS/SSL」のような併記で使われる事が多いです。
古いSSL/TLSバージョンが抱える脆弱性の問題
初めて開発された「SSL1.0」は、リリース前に脆弱性が発見され公開に至りませんでした。
その後開発された「SSL2.0」では、製品に実装された後に脆弱性が発見され、多くのウェブブラウザでSSL2.0を無効とする初期設定が行われました。
ごく最近まで広く使用されていた「SSL3.0」は、2014年に重大な脆弱性である「POODLE(CVE-2014-3566)」が発見されました。このため、現在ではサーバでのSSL3.0の利用は非推奨とされ、また多くの主要ブラウザで「SSL3.0」が無効となりました。
また「POODLE」においては、実装が不十分な「TLS1.0/1.1」の場合もサーバとの通信において脆弱性があることが確認され、TLS1.0/1.1の利用は非推奨となっております。
この他、2014年と2015年に発覚したOpenSSLの脆弱性「Heartbleed」「FREAK」など、場合によってはOpenSSLのアップグレードやSSLサーバ証明書の入れ替えが必要になるケースもありました。
TLS1.2やTLS1.3への移行の必要性
2008年にリリースされた「TLS1.2」から、ハッシュアルゴリズムにSHA-256(SHA-2)※が追加されておりますが、SHA-1ハッシュアルゴリズムについては、2017年3月にGoogleから衝突に成功したことが報告されました。以前からリスクが指摘されていたSHA-1が、ついに安全ではなくなったことが証明されました。
※SHA(Secure Hash Algorithm)とは、改ざん検出に用いるハッシュ関数の種類の一つ。ハッシュ値は、数値が大きい方がセキュリティ的な強度が高いとされており、SHA-1が160ビットなのに対し、SHA-2は224ビット・256ビット・384ビット・512ビット(SHA-2で現在普及しているのが256ビット)。
このようなことから、古いSSL/TLSバージョンを使い続けるより、よりセキュアなハッシュアルゴリズムをサポートした「TLS1.2」への移行が必要とされています。
TLS1.3
TLS1.2のリリースから10年の歳月が経過した2018年8月に、「TLS1.3」が最新バージョンとしてリリースされました。
上記の脆弱性問題の反省から、TLS1.2以前のバージョンに存在した古い暗号アルゴリズムが削除され、ハンドシェイク(暗号方式や鍵交換などのセキュリティパラメータの取り決め)の途中から暗号化される仕組みが導入されました。また、通信パフォーマンスに関するさまざまなアップデートが行われました。
HTTPのメッセージ構造
HTTPのメッセージ構造は下記の通り。
開始行(リクエストライン/ステータスライン) + 改行(CRLF)
0行以上のヘッダフィールド + 改行(CRLF)
● General-header・・・要求と応答いずれにも使えるヘッダ
● Request-header・・・要求の際に追加できるヘッダ
● Response-header・・・応答の際にサーバが追加できるヘッダ
● Entity-header・・・エンティティ(メッセージボディ)についての情報を定義するヘッダ
改行(CRLF)
メッセージボディ
ブラウザ/Webサーバ間で送受信するデータ。POSTメソッドでブラウザからWebサーバにデータを送信する場合、データはメッセージボディに含む。一方、GETメソッドでリクエストする場合は、メッセージボディは空のままになる。
HTTPのリクエストメッセージ
HTTPのリクエストメッセージの開始行は下記の通り。
メソッド リクエストURI HTTPバージョン 改行(CRLF)
GET /index.html?name=Arucamo&age=40 HTTP/1.1
■リクエストメソッド … リクエストしたファイルに対する動作
リクエストメソッドは、クライアントからサーバにリクエストする際に送信される。
メソッド名 | 説明 |
GET | リソースの要求 リクエストURIで識別されるリソースを取得 |
HEAD | リソースの要求 GETと同等だがヘッダのみを取得し、レスポンスボディを返さない |
POST | リソースの送信 リクエストURIで識別されるリソースの子リソースの作成、リソースへのデータの追加などを要求 |
PUT | リソースの更新 リクエストURIに対してエンティティ(メッセージボディ)に含まれる情報を保存することを要求 |
OPTIONS | サーバの調査 リクエストURIがサポートしているメソッドを取得 |
DELETE | リソースの削除 リクエストURIで識別されるリソースの削除を要求 |
TRACE | ネットワーク経路の調査 自分宛てにリクエストメッセージを返却するループバック試験に使用 |
CONNECT | トンネルを開く プロキシ動作のトンネル接続への変更(SSLトンネリングなど)のために使用 |
■リクエストURI … リクエストするファイルのURI
■HTTPバージョン … クライアントが使用できる最も高いHTTPのバージョン
HTTPのレスポンスメッセージ
メッセージの構造はHTTPのメッセージ構造と同じ。開始行にはレスポンスの状態を3桁の数字で表すステータスコードが含まれる。
ステータスコード | 概要 |
1xx | Informational(情報提供のコード) プロトコルの切り替え |
2xx | Success(成功したことを表すコード) (例)HTTP/1.1 200 OK |
3xx | Redirection(転送に関するコード) (例) 301 Moved Permanently(永続的なリダイレクト) 302 Found(一時的なリダイレクト) 304 Not Modified(変更なし。キャッシュしたファイルが使用される) 307 Temporary Redirect(一時的なリダイレクト) |
4xx | Client Error(クライアントエラーに関するコード) (例) 400 Bad Request 401 認証が必要 403 アクセス権が必要 404 Not Found(ファイルが存在しない) |
5xx | Server Error(サーバエラーに関するコード) (例) 500 Internal Server Error 503 Service Unavailable |
HTTPのヘッダフィールド
ヘッダフィールドの種類 | HTTPバージョン | 意味 | |
1.0 | 1.1 | ||
General-header(要求と応答の双方で使われるヘッダ・フィールド) | |||
Date | ○ | ○ | 作成された日付。RFC822形式、RFC850形式、ANSI C形式などを受け入れる必要がある。 |
Pragma | ○ | ○ | データのキャシュの許容などの通信オプション。no-cacheなる値はサーバがフレッシュな情報をかえすことを示す |
Cache-Control | ○ | キャシュを制御するための情報
Cache-Control: no-store(キャッシュが保存されなくなる) Cache-Control: max-age=60(キャッシュの有効期限を秒単位で指定。 |
|
Connection | ○ | 応答送信後にTCPコネクションを切断するか否かなどの通信オプションConnection: close行は応答の後にTCP切断を指示.Connection: KeepAliveはコネクションの継続を支持 | |
Transfer-Encoding | ○ | ボディ部分のエンコーディング方式 | |
Upgrade | ○ | HTTP/1.1以外のプロトコルに切り替える | |
Via | ○ | 伝達途中で経由したノードが記録 | |
Trailer | 〇 | チャンク形式エンコーディングで使用されるフィールドを記述する。 | |
Warming | 〇 | レスポンス・ステータスコードの付加的なコード番号やテキスト情報 | |
Request-header(要求の付加情報として使われるヘッダ・フィールド) | |||
Authorization | ○ | ○ | HTTP認証の認証情報。ユーザー名とパスワードが格納される。 |
From | ○ | ○ | 要求送信元のメールアドレス |
If-Modified-Since | ○ | ○ | ここに指定された日付以降に更新された情報のみを要求 |
Referer | ○ | ○ | 現在のページを取得するときにユーザが使ったリンクを含むページのURL |
User-Agent | ○ | ○ | ユーザーエージェントの名前。ブラウザのタイプ、ブラウザ固有のコンテンツを返すときに有用 |
Accept | △ | ○ | 利用可能なアプリケーション・メディアタイプを指定。複数指定、優先度指定も可能。
Accept: text/plain(テキストファイルの規定値) |
Accept-Charset | △ | ○ | そのブラウザが期待する文字セット |
Accept-Encoding | △ | ○ | そのブラウザがデコードできるデータのエンコーディング(gzipなど)。大きなファイルのダウンロードに有効 |
Accept-Language | △ | ○ | そのブラウザが予期している言語。サーバが多国語に対応しているときなどに使う |
Host | ○ | もとのURLにリストされているホストとポート | |
If-Match | ○ | Etag参照 | |
If-None-Match | ○ | Etag参照 | |
If-Range | ○ | 情報が更新されていないときはRangeで指定した範囲の情報を、層でなければ全体を要求 | |
If-Unmodified-Since | ○ | 指定された日時以降更新されていなかったときに応答を返す | |
Max-Forwards | ○ | TRACEメソッドとともに使う。経由するポートの最大数指定 | |
Proxy-Authorization | ○ | Proxy-Authenticateに対応して、プロキシにユーザ認証情報を通知 | |
Range | ○ | データの一部を要求する | |
Response-header(応答の付加情報として使われるヘッダ・フィールド) | |||
Location | ○ | ○ | 絶対URLで正確な情報の位置を通知。転送先を指定できる。 |
Server | ○ | ○ | サーバ・ソフトの名称やバージョンに関する情報 |
WWW-Authenticate | ○ | ○ | ユーザ認証用のデータを返す |
Accept-Ranges | ○ | ○ | Range要求があったときに対応可能か通知 |
Age | ○ | プロキシにキャッシュする期限を秒数で指定。
キャッシュされたデータが古くなっていないかの判断用データ |
|
Proxy-Authenticate | ○ | WWW-Authenticateと等価だがプロキシからクライアントに送る | |
Public | ○ | 対応するメソッドの一覧をクライアントに通知 | |
Retry-After | △ | ○ | 現在サービスできないので指定時刻または指定経過時間後の再要求を要請 |
Vary | ○ | 言語、文字コードなど複数の表現形式が許されている場合のネゴシエーションで、サーバがどれを選択したか通知 | |
Warning | ○ | 応答のステータス番号の付加情報で、警告 | |
Alternates | △ | 言語、文字コードなど他に許されるものが無いか問い合わせる | |
Entity-header(エンティティ(ボディ部分の情報)の付加情報として使われるヘッダ・フィールド) | |||
Allow | ○ | ○ | 指定したURIで使用可能なメソッド |
Content-Encoding | ○ | ○ | 圧縮などのエンコーディングが使われているときに、使われている方式 |
Content-Length | ○ | ○ | エンティティの長さをバイトで示す |
Content-Type | ○ | ○ | MIME仕様で定義されているコンテントの形式 |
Expires | ○ | ○ | コンテントの有効期限。Date値
Expires: Wed, 28 Oct 2021 09:30:00 GMT Cache-Cntrolヘッダフィールドでmax-ageの指定がされている場合、Expiresヘッダフィールドは無視される。 |
Last-Modified | ○ | ○ | コンテントの最終更新日時。Date値 |
Content-Base | ○ | Content-Locationなどが相対位置で示されているときのベース | |
Content-Language | ○ | エンティティの自然言語を表す。使われている言語ja(日本語)やen(英語)など | |
Content-Location | ○ | メッセージボディの固有の位置をURIで示す | |
Content-MD5 | ○ | MD5のアルゴリズムで生成した改ざんやエラー検出情報 | |
Content-Range | ○ | 一部分が要求されたときにどの部分が返されているかを知らせる | |
Etag | ○ | 前回の応答と今回の応答とを関連付ける情報。前回の応答でサーバが特定の値をクライアントに渡し、その値でIf-Match、If-Non-Match、If-Rangeなどでクライアントが要求してきたら前回の継続とサーバが識別できる。(セッション管理に使える) |
HTTPでの認証
HTTPでは、特定のファイルやディレクトリへのアクセス制限をするために認証することが可能。
認証名 | 概要 |
Basic認証 | ユーザー名とパスワードをコロン「:」で接続し、Base64でエンコードして送信することで認証を実施。 ・盗聴や改ざんが簡単にできてしまう。・ユーザー名・パスワードはAuthorizationヘッダに付加されて送信される・認証が失敗した場合、ステータスコードとして401が返される。・ほぼすべてのブラウザやWebサーバで実装されている。・HTTPS通信を用いることが望ましいが、必須ではない。 |
Digest認証 | 盗聴や改ざんを防ぐため、ユーザー名とパスワードをMD5、またはSHA2でハッシュ化してWebサーバに送信し認証を実施。 |
HTTP cookie(クッキー)
HTTPは、システムの現在の状態を保持しない(ステートレス)プロトコル。従ってWebサーバとWebブラウザとの間の状態管理はできない。そこで、Webブラウザにクッキーと呼ばれる状態管理情報を保存することで、HTTPでの状態管理を実現する。状態管理するプロトコルをクッキーと呼ぶこともある。
クッキーの代表的な用途として次がある。
◆Webサイト上のサービスにおけるログイン状態の記録
◆ECサイト上でのカート情報の管理
◆広告配信業者によるアクセス履歴の記録
クッキーは、WebサーバからWebブラウザに返されるHTTPレスポンスのヘッダ「Set-Cookie」にて指定される。これにより、Webサーバで指定された情報がWebブラウザに保存される。その後Webブラウザは同フォルダ/同ページへのアクセス時、保存していたクッキーをヘッダ[Cookie]を用いてWebサーバに送信することで、状態管理を行う。
クッキーは、JavaScriptなどのクライアント側スクリプトで操作することができる。またWebブラウザから、クッキーの送受信に関する設定や内容確認および消去することも可能。
★HTTPクッキーで保存できるサイズは、通常4KB程度。また、有効期限を設定する必要がある。大容量のデータを永続的に保存する場合は、Web Strageなどを使用する。
★HTTPクッキーはHTTP/HTTPSどちらの通信でも送受信でき、JavaScriptを用いて操作することも可能だが、セキュリティの観点から、HTTP通信での送受信やJavaScriptで操作させたくない場合は、HTTPクッキーに「Secure」フラグと「HttpOnly」フラグを追加する。
【参考】
Cookie | Web Storage | Indexed Database API | |
保存容量 | 4KB | 5MB~10MB* | 5MB~10MB* |
保存期間 | 有限 | localStorage 無制限 sessionStorage セッション |
無制限 |
データ形式 | 文字列 | 文字列 | ネイティブ/オブジェクト 文字列/ファイル/blob |
非同期 | ×同期 | ×同期 | 〇 非同期 |
特徴 | セッションなどで使用 | ・シンプルなAPIで、大容量データを保存できる。
ブラウザにキーと値の組み合わせでデータを保持する仕組み。 ・sessionStorageはブラウザが閉じられると同時にデータが消失する |
さまざまなデータを扱える。APIが複雑なため、実装が難しい
SQLではなく、JavaScriptで操作する |
備考 | 最も実装が進んでいる | 文字列以外のデータを扱う場合は、別途変換などを行う必要がある | DBとは操作方法が異なる。 |
*ブラウザによって容量が異なる。
URI
URLとは、ネットワーク上のリソースを一意に識別するための記述規約。