家 › 料金 › ウェブプロトコル。 Webサービスとは何ですか。 HTTP の基本的な側面

ウェブプロトコル。 Webサービスとは何ですか。 HTTP の基本的な側面

World Wide Web は、Web サービスに基づいた分散マシン指向システムを作成および使用するための既製のプラットフォームです。 Web サーバーは、エンドユーザーではなくサードパーティアプリケーションによってアクセスされるアプリケーションサーバーとして機能します。これにより、機能要素を再利用し、コードの重複を排除し、アプリケーション統合の問題の解決を簡素化することができます。

ウェブサービス、 ウェブサービス(eng. web-service) は、Web 標準に基づいてプログラム間の対話を提供するネットワークテクノロジです。 W3C では、Web サービスを「ネットワーク上の相互運用可能なマシン間通信をサポートするように設計されたソフトウェアシステム」と定義しています。

Web サービス: 概念とプロトコル

Web サービスは URI 文字列によって識別されます。 Web サービスには、機械処理可能な形式で表示されるソフトウェアインターフェイスがあります。他のシステムは、プロトコルメッセージを交換することによってこの Web サービスと対話します。 HTTP プロトコルはメッセージのトランスポートとして使用されます。 Web サービスとその API の説明は、を使用して見つけることができます。技術の概念図を図に、プロトコル間の関係を図に示します。 2.

米。 1. Webサービスのコンセプト

石鹸(Simple Object Access Protocol) - コンシューマーと Web サービスプロバイダーの間でメッセージを交換するためのプロトコル。
WSDL(Web サービス記述言語) - Web サービスの外部インターフェイスを記述するための言語。
UDDI(Universal Discovery、Description、および Integration) は、Web サービスのカタログを作成し、それにアクセスするために使用されるユニバーサルな認識、説明、および統合インターフェイスです。

米。 2. Webサービスプロトコル

この技術で使用される仕様はすべて XML に基づいており、そのため、XML の利点 (構造性、柔軟性など) と欠点 (煩雑さ、遅さ) が引き継がれています。

石鹸

ソープ（元々は シンプルオブジェクトアクセスプロトコル、バージョン 1.2 ではこの略語の正式なデコードはありません) は、構造化メッセージの交換に基づいて、オブジェクト (分散コンピューティングシステムのコンポーネント) にアクセスするための単純なプロトコルです。他のテキストプロトコルと同様に、SOAP は SMTP、FTP、HTTPS などのアプリケーション層プロトコルで使用できますが、ほとんどの場合、SOAP は HTTP 経由で使用されます。

すべての SOAP メッセージは、と呼ばれる構造でフォーマットされます。封筒(エンベロープ)。これには次の要素が含まれます。

メッセージ ID (ローカル名)。
オプションのヘッダー要素:
- この名前空間で使用できるゼロ個以上のプロパティ。
必須の Body 要素 (メッセージ本文)
- 使用されている名前空間への 0 個以上の参照。
- メッセージ本文の子要素

SOAP メッセージ要素の詳細なリストは、データスキーマ (SOAP バージョン 1.2 の場合) に示されています。

SOAP メッセージのサンプル:

封筒 xmlns:env= http://www.w3.org/2003/05/soap-envelope"> ヘッダ> 1 2001-06-22T14:00:00-05:00 ヘッダ> 体> 午前6時30分に起床体> 封筒>

XML-RPC: 競合ではないが、SOAP の代替となる

XML-RPC は、Web サービスを通信するための非常にシンプルで効率的なプロトコルです。 SOAP のようなグローバルな問題を解決するように設計されたものではありませんが、多くの Web 開発で広く使用されています。

XML-RPC の概念

表 1. WSDL プロトコルの基本要素。

WSDL 1.1 要素	WSDL 2.0 要素	簡単な説明
ポートタイプ	インターフェース	Web サービスインターフェイスの説明 (操作とそのパラメーターのリスト) を表します。
サービス	サービス	システム機能一覧
バインディング	バインディング	SOAP プロトコルを使用してインターフェイスを指定し、バインディングパラメーター (バインディングスタイル (RPC/ドキュメント) およびトランスポート (SOAP)) を設定します。このセクションは各操作でも利用できます
手術	手術	Web サーバーによって提供される操作を定義します。 WSDL 操作は、従来の関数やプロシージャに似ています。
メッセージ	使用されていない	特定の操作に関連付けられたメッセージ。特定の操作を実行するために必要な情報が含まれます。各メッセージは、データ型と属性名を記述するいくつかの論理部分で構成されます。バージョン 2.0 では除外されました。 XML スキーマのサポートがすべての要素に導入されました。
種類	種類	XMLスキーマに従ったデータの記述。

米。 3. WSDLプロトコルの構造

WSDL 1.1 仕様では、4 つのメッセージ交換パターン (操作タイプ) が定義されています。

一方向操作: 操作はメッセージを受信できますが、応答は返しません。
要求-応答: 操作は要求を受け入れることができ、応答を返す必要があります。
質問-回答 (要求-応答): 操作はリクエストを送信でき、それに対する応答を待ちます。
通知: この操作はメッセージを送信できますが、応答は待機しません。

WSDL 2.0 では、これらのテンプレートはエラーメッセージ (たとえば、Robust-in-only テンプレート) をサポートするために変更および拡張されていますが、WSDL 1.1 タイプは下位互換性のためにサポートされています。

UDDI は、業界標準の HTTP、XML、XML スキーマ (XSD)、SOAP、および WSDL に依存しています。 UDDI と Web サービススタック内の他のプロトコルの間の概念的な関係をに示します。

米。 4. Web サービスプロトコルスタックにおける UDDI の位置

UDDI レジストリの機能は、Web サービスに関するデータとメタデータを表すことです。パブリックネットワーク上と組織の内部インフラストラクチャ内の両方で使用できます。 UDDI レジストリは、Web サービスを他のアプリケーションで使用できるように、Web サービスを分類、カタログ化、管理するための標準ベースのメカニズムを提供します。このメカニズムには、サービスの検索、そのサービスの呼び出し、およびそのサービスに関するメタデータの管理のための機能が含まれています。

UDDI の主な機能は、サービスに関する情報をレジストリに公開し、サードパーティのアプリケーションにその情報を検索させることです。これらに加えて、保存されたデータモデルと情報ベース構造の表現、レジストリオブジェクト間の関係、レプリケーション、セキュリティなど、ディレクトリサービスに典型的な機能も実装されています。 - レジストリのすべての主要な機能は Web サービスとして提供され、UDDI API を通じてアクセスできます。

Web サービス: プロとコントラ

利点

プラットフォームに関係なく、ソフトウェアシステムの相互作用を保証します。
オープンな標準とプロトコルに基づいています。
HTTP を使用すると、アプリケーションはファイアウォールを越えて通信できるようになります。

欠陥

CORBA や DCOM などのテクノロジと比較して、パフォーマンスが低く、ネットワークトラフィックの量が多くなります。

このページの永久アドレス:

プロトコルは、異なるプログラム間のデータ交換を定義する一連の合意です。プロトコルは、ネットワーク内でのメッセージの送信方法とエラーの処理方法を定義し、特定のハードウェアプラットフォームに縛られない標準の開発も可能にします。

ネットワークプロトコルネットワークに接続されたコンピュータの動作ルールを規定します。これらはマルチレベルの原則に基づいて構築されています。あるレベルのプロトコルは、通信の技術ルールの 1 つを定義します。現在、ネットワークプロトコルには OSI (Open System Interconnection) モデルが使用されています。 OSI モデルは、ネットワーク運用の 7 層論理モデルです。 OSI モデルは、いくつかの層に編成されたプロトコルと通信ルールのグループによって実装されます。

の上 身体レベル通信回線の物理的（機械的、電気的、光学的）特性が決定されます。

の上 リンクレベルネットワークノードによる物理層の使用規則が決定されます。

- ネットワーク層メッセージのアドレス指定と配信を担当します。

- トランスポート層メッセージコンポーネントの送信順序を制御します。

タスク セッションレベル- 異なるワークステーション上で実行される 2 つのアプリケーションプログラム間の通信の調整。

- プレゼンテーション層データをコンピュータの内部形式から送信形式に変換する役割を果たします。

- アプリケーション層アプリケーションプログラムと他のレベルとの境界です。アプリケーション層は、ユーザーネットワークプログラムに便利な通信インターフェイスを提供します。

TCP/IPプロトコルは、インターネット通信の基礎となる 2 つの下位レベルのプロトコルです。 TCPプロトコル(伝送制御プロトコル) は、送信される情報を部分に分割し、すべての部分に番号を付けます。を使用することで IPプロトコル(インターネットプロトコル) すべての部分が受信者に送信されます。次に、TCP プロトコルを使用して、すべての部分を受信したかどうかを確認します。すべての部分を受信すると、TCP はそれらを必要な順序に配置し、1 つの全体に組み立てます。

インターネットで使用される最もよく知られたプロトコル:

HTTP (ハイパーテキスト転送プロトコル) ハイパーテキスト転送プロトコルです。 HTTP プロトコルは、あるコンピュータから別のコンピュータに Web ページを送信するために使用されます。

FTP (ファイル転送プロトコル) 特別なファイルサーバーからユーザーのコンピュータにファイルを転送するためのプロトコルです。 FTP を使用すると、加入者はネットワーク上の任意のコンピュータとバイナリファイルやテキストファイルを交換できます。リモートコンピュータとの接続を確立すると、ユーザーはリモートコンピュータから自分のコンピュータにファイルをコピーしたり、自分のコンピュータからリモートコンピュータにファイルをコピーしたりできます。

POP (ポストオフィスプロトコル) 標準のメール接続プロトコルです。 POP サーバーは受信メールを処理し、POP プロトコルはクライアントメールプログラムからのメール要求を処理するように設計されています。

SMTP（簡易メール転送プロトコル）規格 メールを送信するための一連のルールを指定します。 SMTP サーバーは確認応答またはエラーメッセージを返すか、追加情報を要求します。

UUCP (Unix から Unix へのコピープロトコル) は、現在では時代遅れですが、電子メールなどのデータ転送プロトコルとして依然として使用されています。このプロトコルには、最初にクライアントとサーバーの接続が確立されてデータパケットが送信され、その後独立して処理、表示、または準備される、パケット方式の情報転送が含まれます。

TELNET リモートアクセスプロトコルです。 TELNET を使用すると、加入者はインターネット上の任意のコンピュータを自分のコンピュータであるかのように操作できます。つまり、プログラムを起動したり、動作モードを変更したりすることができます。実際には、機能はリモートマシンの管理者が設定したアクセスレベルによって制限されます。

DTN - 超長距離宇宙通信を提供するために設計されたプロトコル。

HTMLドキュメントなどのさまざまなリソースを受信できます。 HTTP プロトコルは、インターネット上のデータ交換の基礎となります。 HTTP はクライアント/サーバー通信プロトコルであり、サーバーへのリクエストは受信者自身 (通常は Web ブラウザー) によって開始されることを意味します。結果として得られる最終ドキュメントは、最終ドキュメントの一部であるさまざまなサブドキュメントで構成されます (場合によっては)。たとえば、個別に受け取ったテキスト、ドキュメント構造の説明、画像、ビデオファイル、スクリプトなどです。

クライアントとサーバーは、(データのストリームではなく) 単一のメッセージを交換することによって通信します。クライアント (通常は Web ブラウザ) によって送信されるメッセージは、 リクエスト、サーバーによって送信されるメッセージは次のように呼ばれます。答え.

HTTP は 1990 年代初頭に開発されましたが、その拡張性により継続的に改良されてきました。 HTTP は、別のプロトコルの機能をほとんどの場合使用するアプリケーション層プロトコルです。 TCP（または TLS- セキュア TCP) - メッセージを転送するために使用されますが、理論的には他の信頼できるトランスポートプロトコルを使用してそのようなメッセージを配信することもできます。その拡張性により、クライアントがハイパーテキストドキュメント、画像、ビデオを受信するためだけでなく、HTML フォームなどを使用してコンテンツをサーバーに送信するためにも使用されます。 HTTP は、オンデマンド (AJAX リクエストなど) で Web ページを更新する目的でドキュメントの一部のみを取得するために使用することもできます。

HTTP ベースのシステムのコンポーネント

HTTP はクライアント/サーバープロトコルです。つまり、リクエストは一方の当事者、つまり交換の参加者 (ユーザーエージェント) (または代わりにプロキシ) によって送信されます。ほとんどの場合、参加者は Web ブラウザですが、たとえば、検索エンジンの Web ページのインデックスデータを補充および更新するために Web 上を移動するロボットなど、誰でも参加できます。

それぞれのリクエスト リクエスト) がサーバーに送信され、サーバーがそれを処理して応答を返します (英語)。応答）。これらのリクエストとレスポンスの間には、通常、と呼ばれる多数の仲介者が存在します。プロキシ、さまざまな操作を実行し、ゲートウェイとして機能します。キャッシュ、例えば。

通常、ブラウザとサーバーの間には、ルーターやモデムなど、リクエストの処理において何らかの役割を果たすさらに多くのさまざまな仲介デバイスが存在します。ネットワークは対話レベル (層) のシステムに基づいて構築されているという事実により、これらの仲介者はネットワークレベルとトランスポートレベルで「隠蔽」されます。この階層化システムでは、HTTP が最上位の層を占め、これは「アプリケーション」層 (または「アプリケーション層」) と呼ばれます。プレゼンテーション、セッション、トランスポート、ネットワーク、リンク、物理などのネットワーク層の知識は、ネットワークの動作を理解し、考えられる問題を診断するために重要ですが、HTTP の説明と理解には必須ではありません。

クライアント: 交換参加者

ユーザーエージェントは、ユーザーの代わりに動作するツールまたはデバイスです。このタスクは主に Web ブラウザによって実行されます。場合によっては、参加者は、エンジニアや Web 開発者がアプリケーションをデバッグするために使用するプログラムです。

ブラウザ いつもリクエストを作成するエンティティです。通常、サーバーはこれを行いませんが、長年にわたってネットワークはサーバー側のリクエストを実行できるようにする方法を開発してきました。

Web ページを表示するには、ブラウザは最初のリクエストを送信して、そのページの HTML ドキュメントを取得します。この後、ブラウザはこのドキュメントを調べ、Web ページのコンテンツを表示するために必要な追加ファイル (実行可能スクリプト、ページレイアウト情報 - CSS スタイルシート、画像やビデオファイルの形式の追加リソース) を要求します。これらは、Web ページの直接の一部です。ソースドキュメントですが、ネットワーク上の別の場所にあります。次に、ブラウザはこれらすべてのリソースを接続して、単一のドキュメント (Web ページ) の形式でユーザーに表示します。ブラウザ自体によって実行されるスクリプトは、Web ページの処理の後の段階でネットワーク経由で追加のリソースを受け取ることができ、それに応じてブラウザはそのページの表示をユーザーに更新します。

Web ページはハイパーテキストドキュメントです。これは、表示されるテキストの一部がリンクになっており、(通常はマウスボタンをクリックすることで) アクティブ化して新しい Web ページを取得し、(リンクに従って) 表示できることを意味します。これにより、ユーザーは Web ページ (インターネット) を「ナビゲート」できるようになります。ブラウザはこれらのハイパーリンクを HTTP リクエストに変換し、受信した HTTP レスポンスを使いやすい形式で表示します。

ウェブサーバー

通信チャネルの反対側には、サービスを提供するサーバーがあります (英語)。 仕える）ユーザーの要求に応じて文書を提供します。エンドユーザーの観点から見ると、サーバーは常に、ドキュメントを完全または部分的に生成する単一の仮想マシンです。ただし、実際には、負荷が分散されるサーバーのグループ、つまり、異なるユーザーからのリクエストが分散されるサーバーのグループである場合もあります。再配布されるソフトウェア、または他のコンピュータ (キャッシュサーバー、データベースサーバー、電子商取引アプリケーションサーバーなど) をポーリングする複雑なソフトウェア。

サーバーは必ずしも 1 つのマシン上に配置される必要はなく、その逆も同様です。複数のサーバーが同じマシン上に配置 (ホスト) される可能性があります。 HTTP/1.1 バージョンに準拠しており、ホストヘッダーを共有している場合、同じ IP アドレスを共有することもあります。

プロキシ

Web ブラウザとサーバーの間には、HTTP メッセージを送信する多数のネットワークノードがあります。階層構造のため、そのほとんどはトランスポートネットワークまたは物理層でも動作し、HTTP 層に対して透過的になり、パフォーマンスが低下する可能性があります。これらのアプリケーションレベルの操作は次のように呼ばれます。 プロキシ 。これらは透過的である場合とそうでない場合があり (変更リクエストは透過されません)、多くの機能を実行できます。

キャッシュ (ブラウザーのキャッシュのように、キャッシュはパブリックまたはプライベートにすることができます)
フィルタリング (ウイルス対策スキャン、ペアレンタルコントロールなど)
負荷分散 (複数のサーバーが異なるリクエストを処理できるようにする)
認証 (さまざまなリソースへのアクセスを制御)
ロギング (トランザクション履歴を保存する権限)

HTTP の基本的な側面

HTTPは簡単です

HTTP/2 では HTTP メッセージをフレームにカプセル化することで複雑さが増しましたが、HTTP は一般にシンプルで人間が判読可能です。 HTTP メッセージは人間が読んで理解できるため、開発者にとってはテストが容易になり、新規ユーザーにとっては複雑さが軽減されます。

HTTP - 拡張可能

HTTP/1.0で導入 HTTPヘッダーこのプロトコルを拡張して実験しやすくしました。新しい機能は、新しいヘッダーのセマンティクスに関するクライアントとサーバー間の単純な合意によっても導入できます。

HTTP はステートレスですがセッションがあります

HTTP はステートレスです。同じ接続上で連続して実行される 2 つのリクエストの間には関係がありません。これは、オンラインストアでショッピングカートを使用する場合など、ユーザーが特定のページを連続して操作しようとすると問題が発生する可能性を直ちに示唆します。ただし、HTTP コアはステートレスですが、Cookie によりステートフルセッションが可能になります。ヘッダーの拡張性を使用して、Cookie がワーカースレッドに追加され、セッションが各 HTTP リクエストで一部のコンテキストまたは状態を共有できるようになります。

HTTP と接続

接続はトランスポート層で管理されるため、基本的に HTTP の境界を超えます。 HTTP では、基礎となるトランスポートプロトコルが接続ベースである必要はありませんが、必要なのは 信頼性、またはメッセージが失われていない（つまり、少なくともエラー表現）。最も一般的な 2 つのインターネットトランスポートプロトコルのうち、TCP は信頼できますが、UDP は信頼できません。その後、HTTP は、接続が常に必要なわけではありませんが、接続ベースの TCP 標準に依存します。

HTTP/1.0 は、要求/応答交換ごとに TCP 接続を開きます。これには 2 つの重要な欠点があります。接続を開くには複数のメッセージ交換が必要なので時間がかかります。ただし、複数のメッセージを送信する場合、またはメッセージを定期的に送信する場合は効率的になります。 暖かい接続はより効果的です寒い.

これらの欠点を軽減するために、HTTP/1.1 ではパイプライン化 (実装が困難であることがわかった) と永続的な接続が導入されました。基盤となる TCP 接続はヘッダーを通じて部分的に制御できます。繋がり。 HTTP/2 は、単純な接続にメッセージの多重化を追加することで次のステップを踏み出し、接続を継続的に維持し、より効率的にするのに役立ちました。

HTTP により適した、より優れたトランスポートプロトコルを開発するための実験が行われています。たとえば、Google は、より信頼性が高く効率的なトランスポートプロトコルを提供するために、UDP に基づく QUIC を実験しています。

HTTP経由で制御できるもの

HTTP の自然な拡張性により、時間の経過とともに Web の制御と機能が向上してきました。キャッシュと認証方法は、HTTP の歴史の初期の機能でした。一方、当初の制限を緩和する機能は 2010 年代に追加されました。

以下は、HTTP で管理される一般的な機能です。

サーバーは、何をどのくらいの期間キャッシュするかをプロキシとクライアントに指示できます。クライアントは、保存されたドキュメントを無視するように中間キャッシュプロキシに指示できます。
ソース制約の緩和
スパイウェアやその他のプライバシーを侵害する侵入を防ぐために、Web ブラウザは Web サイト間の厳密な分離を維持します。からのページのみ 同じソース Web ページ上の情報にアクセスできます。このような制限はサーバーに負担をかけますが、HTTP ヘッダーを使用すると、サーバー側での厳密な分離が緩和され、ドキュメントが異なるドメインの情報の一部になることが可能になります (セキュリティ上の理由から)。
認証
一部のページは特別なユーザーのみが閲覧できます。基本認証は、HTTP 経由、またはヘッダーの使用を通じて提供できます。 WWW認証および同様のもの、または Cookie を使用して特別なセッションをセットアップすることによって。
プロキシとトンネリング
サーバーやクライアントはイントラネット上に配置されることが多く、実際の IP アドレスを他の人から隠します。 HTTP リクエストはプロキシを経由して、このネットワーク障壁を越えます。すべてのプロキシが HTTP プロキシであるわけではありません。たとえば、SOCKS プロトコルは下位レベルで動作します。 FTP などの他の機能は、これらのプロキシによって処理できます。
セッション
HTTP Cookie を使用すると、リクエストをサーバー上の状態に関連付けることができます。 HTTP は本質的にステートレスプロトコルであるにもかかわらず、これによりセッションが作成されます。これは、オンラインストアのショッピングカートだけでなく、ユーザーが出口をカスタマイズできるサイトでも役立ちます。

HTTPストリーム

クライアントがサーバーと通信する場合、それが最終サーバーであっても中間プロキシであっても、次の手順に従います。

TCP 接続を開く: TCP 接続は、1 つまたは複数のリクエストを送信し、応答を受信するために使用されます。クライアントは、新しい接続を開いたり、既存の接続を再利用したり、サーバーに対して複数の TCP 接続を開いたりできます。
HTTP メッセージの送信: HTTP メッセージ (HTTP/2 以前) は人間が判読可能です。 HTTP/2 以降、単純なメッセージはフレーム内にカプセル化されるため、直接読み取ることはできませんが、基本的には同じです。 GET / HTTP/1.1 ホスト: サイト Accept-Language: fr
サーバーからの応答の読み取り: HTTP/1.1 200 OK 日付: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Range: バイト Content-Length: 29769 Content-Type: text/html
さらなるリクエストのために接続を閉じるか再利用します。

HTTP パイプラインが有効な場合、最初の応答全体が受信されるのを待たずに、複数の要求を送信できます。 HTTP パイプラインは、古いソフトウェアと最新のバージョンが共存する既存のネットワークに統合するのが困難です。 HTTP パイプラインは HTTP/2 でフレーム内のより信頼性の高い多重化リクエストに置き換えられました。

HTTPメッセージ

HTTP/1.1 以前の HTTP メッセージは人間が判読可能です。 HTTP/2 では、これらのメッセージは新しいバイナリ構造であるフレームに埋め込まれ、ヘッダー圧縮や多重化などの最適化が可能になります。元の HTTP メッセージの一部がこのバージョンの HTTP で送信された場合でも、各メッセージのセマンティクスは変更されず、クライアントは元の HTTP リクエストを (仮想的に) 再作成します。 HTTP/1.1 形式の HTTP/2 メッセージを理解するのにも役立ちます。

HTTP メッセージにはリクエストとレスポンスの 2 種類があり、それぞれ形式が異なります。

リクエスト

HTTP リクエストの例:

HTTP 方法、通常は次のような動詞です得る ,
見出し(オプション) サーバーに追加情報を提供します。
または、POST などの一部のメソッドの場合は、送信されたリソースが含まれる本文。

答え

回答例:

HTTPプロトコルのバージョン。
HTTPステータスコード、リクエストが成功したかどうか、または失敗した理由を示します。
ステータスメッセージ -- ステータスコードの簡単な説明。
HTTP ヘッダー、リクエストのヘッダーに似ています。
オプション: 送信されるリソースを含む本文。

結論

HTTP は使いやすく、拡張可能なプロトコルです。クライアント/サーバー構造とヘッダーを簡単に追加できる機能により、HTTP は Web の拡張機能に合わせて前進することができます。

HTTP/2 では、パフォーマンスを向上させるためにフレームに HTTP メッセージを埋め込むことによって多少の複雑さが追加されていますが、基本的なメッセージ構造は HTTP/1.0 のままです。セッションスレッドはシンプルなままなので、探索やデバッグが簡単に行えます。

クライアントが特定のポートでサービスに接続すると、確立されたプロトコルを使用してサービスにアクセスできるようになります。プロトコルは、サービスの使用を希望する当事者とサービスを提供する当事者の間で情報を交換するために事前に開発された手順です。サービスを必要とする「当事者」は人間の場合もありますが、ほとんどの場合、Web ブラウザなどのコンピュータプログラムです。プロトコルは多くの場合、クライアントとサーバーの間で情報を交換する手順をテキストで説明したものです。

UNIX

おそらく最も単純なプロトコルは日中サービス用です。昼間サーバーをサポートするマシンのポート 13 に接続すると、サーバーは現在の日付と時刻の情報で応答し、接続を切断します。プロトコルは次のとおりです。「クライアントが昼間のサーバーとの接続を確立すると、日付と時刻のデータがサーバーに送信され、その後接続が切断されます。」ほとんどの UNIX マシンはこのサーバーをサポートしています。 Telnet アプリケーションを使用して彼に連絡できます。 UNIX では、セッションは次のようになります。

%telnet web67.ntx.net 13
web67.ntx.net への接続。
キャンセル文字「^]」。
1998 年 10 月 25 日日曜日 08:34:06

ウィンドウズ

Windows マシンでは、MSDOS ウィンドウに「telnet web67.ntx.net 13」と入力すると、このサーバーにアクセスできます。

この例では、web67.ntx.net が UNIX サーバーマシンで、13 が日中サービスのポート番号です。 Telnet アプリケーションはポート 13 に接続します (Telnet は通常、ポート 23 に接続しますが、他のポートを指定して接続することもできます)。サーバーは日付と時刻のデータを送信して、接続を閉じます。 Telnet のほとんどのバージョンにはポート番号を指定する機能があり、この機能はマシンにインストールされている Telnet のバージョンに関係なく使用できます。

ほとんどのプロトコルは昼間のプロトコルよりも複雑で、公開されている RFC (Request for Comments) で定義されています (すべての RFC の適切なアーカイブについては、sunsite.auc.dk/RFC/ を参照してください)。インターネット上のすべての WEB サーバーは、1991 年に『The Original HTTP』文書にまとめられた HTTP プロトコルの要件に準拠しています。 HTTP サーバーが理解できる最も重要な形式のプロトコルには、GET コマンドが 1 つだけ含まれます。 HTTPプロトコルでサーバーに接続し、「ファイル名GET」リクエストを送信すると、サーバーは指定されたファイルの内容をリクエスト元に送信して接続を切断します。典型的なセッションは次のようになります。

%telnetサイト80
78.110.59.235 に接続しようとしています…
pcwork.ruとの接続。
キャンセル文字「^]」。
接続は外部ホストコンピュータによって無効にされています。

HTTP プロトコルの初期バージョンでは、[/] などの実際のファイル名のみを送信する必要がありました。プロトコルは後に完全な URL を処理できるように変更されました。これにより、仮想ドメインを扱う企業は、1 台のマシン上に多数のドメインが存在する状況で、そのようなすべてのドメインに対して 1 つの IP アドレスを使用できるようになりました。

要約する

この記事を読んだ後、あなたは多くのことを学びました。具体的には、ブラウザに URL を入力すると、次のことが起こることがわかりました。

URL を 3 つの部分に分割しました。

プロトコル (「http」)
サーバー名 (「サイト」) - 最近、最初の 3 文字を短縮する傾向があります www
ファイル名（「webサーバー.htm」）

ブラウザはネームサーバーに接続して、サーバー名を IP アドレスに変換します。この IP アドレスは、ブラウザが対応するサーバーマシンに接続するために使用されます。

IP アドレスを受信した後、指定されたブラウザはポート 80 でこの IP アドレスを持つ WEB サーバーへの接続を確立します。

HTTP プロトコルに従って、ブラウザはファイルを受信するためにこのサーバーに GET リクエストを送信します (GET リクエストとともに、ブラウザからサーバーに Cookie を送信できることに注意してください。詳細については、Cookie の送信方法に関する記事を参照してください)仕事）。

サーバーは、要求された WEB ページの HTML テキストをブラウザーに送信します。 (Cookie はページヘッダーでサーバーからブラウザに渡すこともできます。)

ブラウザはHTMLタグを読み取り、対応するページをモニタ画面に表示します。

付録: セキュリティ

この説明から、WEB サーバーは非常に単純なプログラムであると結論付けることができます。 GET コマンドで送信されたファイル名を取得し、探しているファイルを見つけてブラウザに送信します。ポート管理とポート通信のコードをすべて含めても、500 行未満のコードで簡単な WEB サーバーとして機能する C プログラムを簡単に作成できます。もちろん、フル機能の企業 WEB サーバーはより複雑ですが、その動作の基本原理は依然として非常にシンプルです。

ほとんどのサーバーは、ワークフローにある程度のセキュリティを追加します。この目的のために、たとえば、パスワードで保護されたページが使用されます。ブラウザでそのようなページを開こうとすると、ユーザー名とパスワードの入力を求めるダイアログボックスが表示されます。サーバーは、Web ページの所有者に、このページへのアクセスを許可されているユーザーの名前とパスワードのリストを使用する機能を提供します。この場合、サーバーは適切なパスワードを持つユーザーのみにページの表示を許可します。高度なサーバーには、サーバーとブラウザ間で交換される情報を暗号化する追加のセキュリティ機能があり、クレジットカード番号などの機密情報をインターネット経由で送信できるようになります。

これらは事実上、標準の静的 WEB ページを送信するように設計されたサーバーが実行できるすべての機能です。静的ページは、開発者が編集するまで変更されない WEB ページです。

アドオン: 動的ページ

動的 WEB ページについてはどうでしょうか? 例えば：

どのレビュー本でも HTML 形式でメッセージを残すことが許可されており、次回閲覧するときに入力された新しい情報がこのページに保存されます。
ネットワークソリューションの Whois 画面フォームでは、ドメイン名を入力すると、入力した名前に応じて表示される Web ページが受信されます。
どの検索エンジンでも、キーワードは HTML フォームに入力され、その後マシンがこれらの単語の検索結果を表示するページを作成します。

上記のすべてのケースにおいて、WEB サーバーは必要なファイルを検索するだけではありません。受信した情報を処理し、受信したリクエストに何らかの方法で対応する WEB ページを作成します。ほとんどの場合、WEB サーバーはいわゆる CGI プロシージャを使用してこの問題を解決します。

各サーバーマシンは、サーバーで利用可能なサービスごとに 1 つずつ、番号付きポートを使用してインターネットからサービスを公開します。たとえば、サーバーマシンに WEB サーバーと FTP サーバーがある場合、通常、WEB サーバーにはポート 80 を通じてアクセスし、FTP サーバーにはポート 21 を通じてアクセスします。クライアントは、適切なアドレスを選択してサービスに接続します。適切なポート。

人気のある各サービスには、特定のポート番号が割り当てられます。最も一般的に使用されるポート番号は次のとおりです。

エコー7
昼13時
qotd 17 (今日の名言)
ftp21
テルネット23
smtp 25 (電子メール)
時間37
ネームサーバー 53 (ネームサーバー)
ニックネーム 43 (誰が誰)
ゴーファー 70
指 79
WWW80

制限

サーバーマシンがインターネットからのポートへの接続を許可しており、このポートが保護されていない場合は、インターネット上のどこからでもサーバーマシンに接続して、対応するサービスを使用できます。たとえば、WEB サーバーをポート 80 に接続する必要があるという制限はないことに注意してください。独自のマシンを試運転し、そこに WEB サーバーソフトウェアをインストールすることで、必要に応じて WEB サーバーが動作するように指定できます。たとえば、ポート 918 、またはその他の空いているポート上です。次に、マシンの名前が xxx.yyy.com の場合、URL xxx.yyy.com:918 を使用してインターネット経由でこのサーバーに接続できます。「:918」の部分はポート番号を明示的に示しており、このサーバーに接続したい人は必ず追加する必要があります。ポートが指定されていない場合、ブラウザはデフォルトで共通ポート 80 への接続を試行します。

カテゴリ内で人気のあるもの: