5

いくつかの利用可能なhttpサーバーライブラリを調べましたが、探しているものがまだ見つかりません。この一連の要件を最初に持つことはできないと確信しています。

'パイプライン化された'APIを提示するライブラリが必要です。パイプラインは、応答を待たずに一度に複数のHTTP要求をTCPリンクを介して送信できるHTTP機能を説明するために使用されます。ライブラリAPIに同様の機能が必要で、アプリケーションは応答を送信せずにこれらの要求をすべて受信できます（応答しますが、内部レイテンシの影響を減らすために一度に複数の要求を処理する機能が必要です）。

したがって、Webサーバーライブラリは次のフローをサポートする必要があります

1）HTTPクライアントはhttpリクエストを送信します1

2）HTTPクライアントはhttpリクエスト2を送信します...

3）Webサーバーライブラリはリクエスト1を受信し、それをMyWebServerアプリに渡します

4）My Web Server Appはリクエスト1を受信し、それをMySystemにディスパッチします

5）Webサーバーはリクエスト2を受信し、それをMyWebServerアプリに渡します

6）My Web Server Appはリクエスト2を受信し、それをMySystemにディスパッチします

7）My Web Server Appは、My Systemから要求1への応答を受信し、それをWebServerに渡します。

8）WebサーバーはHTTP応答1をHTTPクライアントに送信します

9）My Web Server Appは、My Systemからリクエスト2への応答を受信し、それをWebServerに渡します。

10）WebサーバーはHTTP応答2をHTTPクライアントに送信します

うまくいけば、これは私の要件を示しています。認識すべき2つの重要なポイントがあります。Webサーバーライブラリへの応答は非同期であり、未処理の応答を含む複数のHTTP要求がMyWebServerアプリに渡される場合があります。

追加の要件は次のとおりです

  1. 既存の「C」アプリケーションに埋め込むことができます
  2. 小さな足跡; Apacheなどで利用できるすべての機能は必要ありません。
  3. 効率的; 1秒間に数千のリクエストをサポートする必要があります
  4. リクエストへの非同期応答を許可します。それらは応答への小さな待ち時間であり、必要な要求スループットを考えると、同期アーキテクチャは私にとっては機能しません。
  5. 永続的なTCP接続をサポートする
  6. サーバープッシュコメット接続での使用をサポート
  7. オープンソース/GPL
  8. HTTPSのサポート
  9. Linux、Windows間でポータブル。できればもっと。

私はどんな推薦にも非常に感謝します

よろしくお願いします

4

8 に答える 8

4

libmicrohttpを試すことができます。

于 2010-02-09T17:33:31.017 に答える
4

今後の参考のために、あなたの要件を満たすために、libasyncdを見てください 。私は貢献者の 1 人です。

既存の「C」アプリケーションに組み込み可能

Cで書かれています。

小さな足跡; Apache などで利用可能なすべての機能は必要ありません。

非常にコンパクト。

効率的; 毎秒数千のリクエストをサポートする必要があります

libevent ベースのフレームワークです。以上で対応できます。

要求への非同期応答を許可します。

非同期です。パイプラインもサポートします。

永続的な TCP 接続をサポート

もちろん、キープアライブ。

Server-Push Comet 接続での使用をサポート

ロジックをどのようにコーディングするかはあなた次第です。

オープンソース / GPL

BSD ライセンスの下で

HTTPS のサポート

はい。openssl で https をサポートします。

Linux、Windows 間で移植可能。できればもっと。

現時点ではポータブルですが Windows ではありませんが、Windows には移植可能です。

于 2014-04-12T18:42:29.480 に答える
1

必要なのは、HTTP パイプラインをサポートするものです。まだそのページに慣れていない場合は、そのページに慣れておく必要があります。

はい、libmicrohttpに行きます。SSL などをサポートし、Unix と Windows の両方で動作します。

しかし、クリストファーは彼のコメントでその場にいます。各応答の起動時間があれば、パイプライン処理によって得られるものはあまりありません。ただし、最初のリクエストに対してかなりの応答時間しかない場合は、何かを獲得できる可能性があります。

一方、各応答に起動時間がある場合は、パイプラインを使用せずにオブジェクトごとに新しい要求を作成することで多くを得ることができます。次に、各リクエストは独自のスレッドを持つことができ、並行して起動コストを吸い上げます。最適なケースでは、すべての応答が「一度に」送信されます。libmicrohttpは、そのMHD_USE_THREAD_PER_CONNECTIONスレッド モデルでこの動作モードをサポートしています。

于 2010-02-10T11:56:29.393 に答える
0

ハワード、

lighthttpdをご覧になりましたか？明示的に埋め込まれたウェブサーバーではないことを除いて、すべての要件を満たしています。しかし、それはオープンソースであり、アプリケーションにコンパイルするのはそれほど難しいことではありません。次に、リクエストを処理するカスタムプラグインを作成できます。

于 2010-02-19T00:24:53.303 に答える
0

誰もnginxについて言及していないとは信じられません。私はソースコードの大部分を読みましたが、それは非常にモジュール化されています。必要な部品をすぐに動作させることができるでしょう。

于 2010-02-19T10:10:07.597 に答える
0

uIP または lwip がうまくいく可能性があります。私は個人的にuIPを使用しています。少数のクライアントと同時接続 (または「パイプライン」と呼ぶ) に適しています。ただし、私が読んだことによると、コンテンツの提供は lwip ほどスケーラブルでも高速でもありません。私のアプリには通常1人のユーザーしかいないため、lwipのパワーではなく、シンプルで小さなサイズのuIPを使用しました。

同時接続が増加するにつれて、uIP はかなり制限されていることがわかりました。ただし、これは使用可能な MAC 受信バッファーの制限であり、uIP 自体ではないと確信しています。これを回避するために、lwip は何らかの方法でより多くのメモリを使用していると思います。受信する大量のリクエスト パケットをサポートするのに十分なイーサネット RAM がありません。とはいえ、56 MHz プロセッサで約 15 ミリ秒のレイテンシでバックグラウンド ajax ポーリングを実行できます。

http://www.sics.se/~adam/software.html

私は実際にいくつかの方法で uIP を変更しました。DHCP サーバーを追加し、ファイル アップロード用のマルチパート POST をサポートすることが重要です)。質問があればお知らせください。

于 2010-05-12T18:50:53.910 に答える
0

以前のコメントと更新のフォローアップ...

いくつの同時接続があるかはわかりませんが、「TCPリンク」だけです。
単一の接続の場合は、前述のように HTTP パイプラインを使用します。そのため、パイプラインの先頭でリクエストを処理するために必要なスレッドは、数千ではなく、ほんの一握りです。

したがって、リクエストごとにスレッドを用意する必要はありません。各接続のワーカーの小さなプール。

パイプライン接続の応答遅延に実際に問題があるかどうかを示すために、これまでにテストまたは実装を行いましたか?
組み込みデバイスが、TLS の設定、暗号化、復号化など、1 秒あたり数千の要求に対処できるほど強力な場合、このレベルでの時期尚早な最適化について心配するでしょう。

于 2010-02-12T14:37:04.047 に答える