webcron は、 Web サーバーでホストされる時間ベースのジョブ スケジューラの用語です。この名前は、Web サーバーという語句と Unix デーモンのcronに由来しています。webcron ソリューション[流行語]を使用すると、ユーザーは、シェル アカウントやその他のジョブ スケジューリング手段を提供していないWeb ホスト上の Web サーバー環境内でジョブを実行するようにスケジュールできます。[1] [非一次ソースが必要]
概要
多くのウェブホストは、シェルアカウントやcronなどの組み込みジョブスケジューラを提供しており、ユーザーは簡単にジョブをスケジュールできます。このようなホストは、オプションでウェブサーバーと通信できるコマンドラインアプリケーションとしてジョブを実行します。ただし、webcron ソリューションは、ウェブホストのウェブサーバー環境の範囲内でのみ実行されます。これにより、cron やシェルアカウントなどのジョブスケジューラを提供していないホストでも、webcron ソリューションを動作させることができます。webcron ソリューションは、ユーザーにそのような機能を提供しているホストでも同様に動作しますが、代替または置き換えとして設計されています。[2] [非一次ソースが必要]
Webcron ソリューションは 2 つの部分から構成されます。最初の部分は、URL経由でアクセス可能な場所にあるタスクを実行するスクリプトです。2 番目の部分は、スクリプトの URL に定期的にアクセスするスケジュール プロバイダーを使用することです。
スケジューリング プロバイダーでスケジュールを設定する前に、ユーザーは Web サーバーで実行されるスクリプトを設定する必要があります。ほとんどの[どれ? ] Web ホストでは、スクリプトの 1 つのインスタンスが実行できる時間の長さに制限があります。多くの[どれ? ] Web ホストでは、 CPUとRAMリソースの使用にも制限があります。共有ホスティングプロバイダーの webcron ソリューションのユーザーは、Web ホストの制限を繰り返し超えて強制終了されないように注意する必要があります。長時間実行されるスクリプトは、Web サーバー プロセスによっていつでも終了される可能性があることを考慮する必要があります。ユーザーは、スクリプトが複数の呼び出しにわたって動作し、Web ホストによって課せられた制限内で実行できるようにする状態マシンを実装できます。 [1] [非一次ソースが必要]
スケジューリングプロバイダー
第三者
ウェブ上には多くのサードパーティのウェブクローン スケジューリング プロバイダーがあります。[3] [4]これらのサービスは、URL と頻度スケジュールを受け入れ、指定された URL を取得または ping します。ほとんどの[どの? ]プロバイダーは、サーバーの過負荷を防ぎ、ユーザーにプレミアム アカウントへの登録を促すために、システムに制限を組み込んでいます。[5]
サードパーティのWebcronスケジューリングプロバイダーでプレミアムアカウントを設定したユーザーは通常、[ peacock prose ] SMSおよび電子メール通知、稼働時間レポートとログ、タイムアウト制限の増加、スケジュールの期限切れなし、 HTTP POSTメソッドの使用、 HTTP Cookieのサポート、スケジュール頻度の制限の緩和などの追加のメリットが得られます。[6] [5] [非一次ソースが必要] [独自の調査? ]
一部のWebCronサービスプロバイダーは、 WebインターフェースでCRON式を受け入れ、ジョブの実行時間をスケジュールします。[7] [8]
訪問者ベース
訪問者がサーバー上の Webcron スケジューラ スクリプトをトリガーできるようにすることで、Webcron ソリューションを Web ホスト上に完全に収めることができます。たとえば、Web サイトのヘッダーまたはフッターの'img' HTML 要素、スクリプト内のAjax呼び出し、またはiFrame を使用することでこれを実現できます。訪問者が Web サイトを表示すると、画像が読み込まれ、Webcron スケジューラがトリガーされます。Webcron スケジューラは実行する必要のあるタスクを実行し、画像を出力して、訪問者の Web ブラウザに壊れた画像がページ上に表示されないようにします。[2] HTTP応答が遅延しないように、タスクを非同期で開始することもできます。
訪問者ベースの Webcron スケジュールを使用している Web サイトへの訪問者が不十分な場合、スケジュールされたタスクは時間どおりに実行されません。
訪問者ベースの Webcron スケジューリングにより、自己完結型の Webcron ソリューションが可能になるため、Web サイトまたは Web ベースのソフトウェア製品の移植性が向上します。定期的に実行する必要があるタスクを持つ一部の Web ベースのオープンソース ソフトウェアでは、訪問者ベースの Webcron ソリューションを使用してそれらのタスクを実行します。[引用が必要]
リモートアクセス
リモート アクセス可能な Webcron ソリューションは、通常、クライアントコンポーネントとサーバー コンポーネントのペアにバンドルされています。クライアントは、ユーザーのパーソナル コンピューターなどの別のコンピューターで実行されます。ジョブ スケジュールは、クライアント コンポーネントが存在するコンピューター上に設定されます。その後、ジョブが実行されると、クライアント コンポーネントはサーバー コンポーネントと通信します。[1] [非プライマリ ソースが必要]
リモート アクセスは通常、他のスケジューリング プロバイダーでは不可能な機能を提供します。クライアントとサーバー コンポーネント間のデータは、通常、 HTTP 経由でも暗号化されます。これにより、クライアント コンポーネントのプラグインまたはモジュールは、サーバー コンポーネントと通信して、通常は制限されている情報を安全に要求できます。 [ 1 ]送受信データ の圧縮により、使用される全体的な帯域幅を削減できます。[ 9] [非プライマリ ソースが必要]
リモートアクセスプラグインまたはモジュールの典型的な実装は、Webサーバーからクライアントにファイルとデータベースを増分バックアップすることです。一部の増分バックアップ実装では、基本的なホストベースの侵入検知システム機能も提供される場合があります。[ 9 ]
ローカルアクセス
cron がすでに利用可能なホストでは、webcron ソリューションを使用できます。これは、必要な機能が Web サーバー経由でのみ利用できる場合に便利です[ peacock prose ]。cronデーモンはスケジュール プロバイダーであり、 Wgetなどの別のツールを使用してスクリプトに定期的に接続します。
リモート アクセスが可能な Webcron ソリューションの場合、cron はクライアント コンポーネントを実行してスクリプトを実行できます。
セキュリティ上の懸念
Webcron ソリューションは URL 経由で利用可能であるため、ユーザーが対処すべきセキュリティ上の懸念がいくつかあります。Webcron ソリューションは、信頼の問題、サービス拒否攻撃の機会、ネットワークまたはパケットのスニッフィング、リプレイ攻撃の実行、および情報の漏洩の可能性をもたらします。Webcron ソリューションは、犯罪的なコンピューター ハッカーにとって理想的な侵入口です。[1] [非一次ソースが必要]
サードパーティのスケジュール プロバイダーを使用する場合、ユーザーはサードパーティが URL を悪用しないことを信頼します。また、サードパーティ サーバーと Web サーバー間の接続がハッカーから安全であると想定する必要があります。
訪問者ベースのスケジュール プロバイダーを使用する場合、ユーザーが不注意でサービス拒否攻撃の可能性のある場所を提供してしまう可能性があります。また、スクリプトが不適切に記述されている場合、スクリプトによってサーバーに関する情報が意図せず公開される可能性があります。
リモート アクセス スケジューリング プロバイダーを使用する場合、ユーザーは通常、Web サーバーとの通信方法を細かく制御できます。HTTP を使用する場合、URL はネットワーク上で平文で送信されますが、要求内のデータは通常、暗号化されます。これにより、サービス拒否攻撃やリプレイ攻撃を受ける可能性が高まります 。
参考文献
- ^ abcde WebCron 製品ドキュメント、2010 年 12 月 1 日取得
- ^ ab phpJobScheduler の概要ドキュメント、2010 年 10 月 14 日取得
- ^ SetCron は、cron ジョブをスケジュールできるタスク スケジューラ サービス/Webcron です。
- ^ Webcron サービス
- ^ ab EasyCron プラン
- ^ SetCronJob プレミアム価格ページ、2010 年 10 月 14 日取得
- ^ EasyCronはcron式を受け入れる
- ^ SetCron の crontab 機能とは何ですか?
- ^ ab WebCron サイトバックアップモジュールのドキュメント、2010 年 12 月 1 日取得
