新人IT担当者のためのネットワーク機器入門【第8回】
Webを支える技術「HTTP」のエッセンス
ネットワークと関連機器に関する「今更聞けない」基礎知識をこっそりおさらいしようというこの連載。今回はレイヤー5からレイヤー7における代表的なプロトコルである「HTTP」について解説します。
連載第7回の「レイヤー4の代表的製品『ファイアウォール』基礎の基礎」では、レイヤー4(トランスポート層)で動作するネットワーク機器「ファイアウォール」について説明しました。ファイアウォールは「コネクションテーブル」を利用して、セキュリティ強度を高めているのが特徴でした。
今回は、レイヤーをさらに上げて、レイヤー5(セッション層)からレイヤー7(アプリケーション層)について説明します。レイヤー5からレイヤー7におけるプロトコルの動作は、使用するアプリケーションによって、大きく異なります。そこで、本連載では「HTTP(HyperText Transfer Protocol)」をピックアップして説明します。
HTTPを理解する3つのポイント
レイヤー5からレイヤー7で動作するアプリケーションプロトコルの中で、最もなじみ深いものがHTTPでしょう。このプロトコルなしにインターネットを語ることはできません。HTTPが現在のインターネットの爆発的普及を支えているといっても過言ではないでしょう。HTTPはもともとHTML(HyperText Markup Language)で記述されているテキストデータを転送するためのプロトコルでした。しかし、今やその枠を飛び越え、ファイルの送受信やリアルタイムのメッセージ交換など、いろいろな用途で使用されています。
HTTPをネットワークの側面から見たときのポイントは「バージョン」「HTTPリクエスト」「HTTPレスポンス」の3つです。それぞれについて説明します。
バージョン:その違いは「TCPコネクション」の使い方の違い
現在、世の中に流通しているHTTPのバージョンは「HTTP/1.0」と「HTTP/1.1」の2つです(※1)。どちらを使用するかは、WebブラウザとWebサーバの設定次第です。最近はWebブラウザもWebサーバもHTTP/1.1をデフォルトの設定にしており、現在の主流となっているバージョンはHTTP/1.1です。この2つはデータの通り道である「TCPコネクション」の使い方が大きく異なっていて、それがサーバの負荷や選定する機器のスペック、設定などに影響してきます。
※1 2015年2月、インターネット標準化団体のInternet Engineering Task Force(IETF)が「HTTP/2」の仕様を標準化したと発表しましたが、本稿執筆時点ではまだ普及には至っていないので、ここでは「HTTP/1.0」と「HTTP/1.1」に絞って話を進めます。
- HTTP/1.0
HTTP/1.0は、リクエストごとにTCPコネクションを作っては壊すという手順を繰り返します。例えば、訪問者が4個のコンテンツで構成されているWebサイトを見た場合、4本のコネクションを作り、コンテンツをダウンロードしたら壊すという手順を繰り返します。これは、相手が1クライアントだったら負荷にはならないでしょう。しかし、1000クライアントとなれば話は別です。ちりも積もって山になり、サーバにとって大きな処理負荷になります。また、ファイアウォールや負荷分散装置に対する新規コネクション数の増大を招きます。
- HTTP/1.1
HTTP/1.1はHTTP/1.0のアップデート版であり、HTTPの効率化を図るいろいろな仕様が盛り込まれています。そのうちの1つが「持続的接続」あるいは「HTTPキープアライブ」と呼ばれるものです。持続的接続はHTTP/1.0では拡張機能でしたが、HTTP/1.1では標準機能になりました。持続的接続は、一度作ったTCPコネクションを使い回す機能です。最初にTCPコネクションを作っておいて、その上で複数のHTTPリクエストを送信します。HTTP/1.0で発生していた「作っては壊す」というTCPの処理がなくなるため、サーバの処理負荷が大きく軽減します。また、ファイアウォールや負荷分散装置の新規コネクション数の増大も回避できます。
同時に作るTCPコネクションの数(最大接続数)は、Webブラウザやそのバージョンによって異なります。例えば、「Internet Explorer」の場合、バージョン7以前はRFC(※2)の推奨に準拠して「2」でしたが、バージョン8から「6」になりました。「Firefox」の場合は「6」です。
※2 RFCは「Request for Comments」の略で、技術の標準仕様がまとめてられている文書のことです。HTTP/1.0はRFC 1945(https://www.ietf.org/rfc/rfc1945.txt)、HTTP/1.1はRFC 2616(https://www.ietf.org/rfc/rfc2616.txt)で標準の仕様がまとめられています。
HTTPリクエスト:サーバに処理を要求
HTTPリクエストは、WebブラウザなどのHTTPクライアントからHTTPサーバへ送信する要求のことです。HTTPクライアントは、リクエストメッセージ(アプリケーションデータ)の最初に記述する「リクエストライン」で、やりたいことをHTTPサーバに伝えます。リクエストラインは、HTTPクライアントが行いたい処理を指定する「メソッド」、処理を行いたいコンテンツの場所を表す「URI(Uniform Resource Identifier)」、前節で説明した「HTTPバージョン」で構成されています。クライアントはURIに対してメソッドを要求し、サーバはその処理結果を「HTTPレスポンス」(詳細は後述)として返します。リクエストラインで使用するメソッドは、以下の通りです。8種類しかなくて、とてもシンプルです。
ここでは、TechTargetジャパンのTopページ(http://techtarget.itmedia.co.jp/)にアクセスする場合を例に、HTTPリクエストを説明します。このページにアクセスするときのHTTPリクエストは「GET / HTTP/1.1」です。「GET」がメソッドで、サーバの情報を取得するときに使用します。「GET」と「HTTP/1.1」の間にある「/」がURIです。HTTPサーバの「/」というところに対してHTTPリクエストを投げています。「HTTP/1.1」がHTTPのバージョンです。つまりこの場合、「HTTP/1.1で“/”の情報をください」と要求していることが分かります。
HTTPレスポンス:処理結果を返答
HTTPサーバは、受け取ったHTTPリクエストを処理し、その結果をレスポンスメッセージとして返します。レスポンスメッセージの最初には「ステータスライン」が記述されていて、処理結果の概要がざっくり分かるようになっています。ステータスラインは「HTTPバージョン」「ステータスコード」「ステータスコードの説明」で構成されています。
この中で最も重要な要素がステータスコードです。ステータスコードは処理結果を表す3桁の番号です。それぞれに意味があって、例えば、Webサーバが正常にしている場合、200番台が返ってきます。また、サーバの処理にエラーが発生した場合、500番台が返ってきます。ステータスコードは、例えば500番は「内部サーバエラー(Internal Server Error)」、503番は「サービス利用不可(Service Unavailable)」という具合に、1の位まで細かく意味が区分されていて、少々覚えにくいものです。新人IT担当者はまず「何百番台は○○」くらいな感じで、ざっくり覚えるところから始めた方がよいでしょう。
では、HTTPリクエストと同様にTechTargetジャパンのTopページにアクセスする場合を例に、HTTPレスポンスを説明します。この場合のHTTPレスポンスに含まれるステータスラインは「HTTP/1.1 200 OK」です。「HTTP/1.1」はHTTPのバージョンです。「200」がステータスコードです。「OK」がステータスコードの概要です。この場合、HTTPリクエスト「GET / HTTP/1.1」に対する処理が正常に終了したことを表しています。このステータスラインの後に、テキストや画像などのアプリケーションデータが続きます。
以上、今回はHTTPについて解説しました。レイヤー5~7ではまず、世の中で最も普及しているHTTPから押さえて、その後に他のアプリケーションへと派生させて学習していけばよいでしょう。次回は、レイヤー4で動作する機器であった「負荷分散装置(ロードバランサ)」からレイヤー7で動作する機器へと進化した「アプリケーションデリバリコントローラー」について説明します。
執筆者紹介
みやたひろし
大学と大学院で地球環境科学の分野を研究した後、某システムインテグレーターにシステムエンジニアとして入社。その後、ネットワーク機器ベンダーのコンサルタントに転身。設計から構築、検証に至るまで、ネットワークに関連する業務全般を行い、今日もどこかで自己研さんを積んでいる。CCIE(Cisco Certified Internetwork Expert)。F5 Certified Technology Specialists。著書に『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』『サーバ負荷分散入門』(いずれもSBクリエイティブ)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
事例
[日本オラクル株式会社] ピンチをチャンスに変えたEPR製品は? 先行企業の導入事例3選 -
技術文書・技術解説
[日本オラクル株式会社] 無自覚なリスク 秘伝Excelファイルが監査の壁、不正・ミスの温床となる理由 -
製品資料
[日本オラクル株式会社] 戦略的経理の第一歩 失敗のない「脱Excel」を実現する秘訣とは? -
技術文書・技術解説
[日本オラクル株式会社] いまさら聞けないオンプレERPとクラウドERPの違い 最適な製品をどう見極める? -
事例
[株式会社ビザスク] 連結売上高が約2倍に成長、富士フイルムが実践した新規事業創出の戦略とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
3
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
4
「企業内サーバ環境の利用実態」に関するアンケート
-
5
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
6
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
7
「SIEMの利用」に関するアンケート
-
8
「ITインフラとデータ保護・バックアップ対策」に関するアンケート
-
9
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
10
「0.3秒のスピード顔認証」の入退室管理が社員に好評 事例に学ぶオフィス改革
ホワイトペーパーランキング PR
-
1
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
バックアップは“取っているから大丈夫”なのか? ランサムウェア時代の備え方
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
9
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー