🙇🏼 🔔 🐎 libeventおよびC ++ 11の40行未満のコードで独自のhttpサーバー 🥚 ⏩ 😵

Habrを時々見ながら、C ++または別の言語で独自のWebサーバーを作成するというトピックに関する投稿に定期的に出会っています。プログラミング言語のC ++のほうが興味があるので、このブログを一番読みます。これに目を通すと、boost.asioなどを使用して、「ソケットで」Webサーバーを作成する方法を簡単に見つけることができます。少し前に、テストタスクを解決する例として、このようなhttpサーバーの作成に関する投稿も公開しました。しかし、取得したものに限定されず、興味のために、私はlibeventおよびboost.asioの開発と比較しました。そのため、彼はそのようなテストタスクの実行を拒否しました。

私自身、職場では、libeventとlibevを検討しました。それぞれに独自の利点があります。小さなhttpサーバーの迅速な開発が必要な場合、libeventは私にとって非常に興味があり、C ++ 11の革新により、コードははるかにコンパクトになり、基本的なhttpサーバーを40行未満で作成できます。

投稿の内容は、おそらくlibeventにまだ慣れていない人にとって有用であり、すぐに独自のhttpサーバーを作成する必要があります。また、このような資料は、まだそのようなニーズを持っていない人にとっても興味があるかもしれません。彼らの意見と経験。投稿には根本的に新しいものが含まれていないため、この方向で作業を開始するための資料として使用できます。したがって、「トレーニング資料」というメモを書きます。

libevの良い点は、たとえばlibevやboost.asioとは異なり、独自の組み込みHTTPサーバーと、バッファーを操作するための抽象化があることです。また、補助機能のかなりのセットがあります。単純なステートマシンまたは他のメソッドを記述することで、HTTPプロトコルを自分で解析することもできます。 libeventを使用する場合、これですべてです。これはとてもいいことです。または、libeventでソケットを操作しながら、下位レベルに進んでHTTP用の独自のパーサーを作成できます。ライブラリの詳細レベルが気に入ったのは、何かをすばやく実行したい場合、通常は柔軟性の低い高レベルのインターフェイスを見つけることができるためです。大規模なニーズの出現により、レベルが低くなるにつれてレベルを徐々に下げることができます。このライブラリを使用すると、非同期入出力、ネットワークの操作、タイマーの操作、rpcなど、多くのことができます。これを使用して、サーバーソフトウェアとクライアントソフトウェアの両方を作成できます。

なんで？

独自の小さなhttpサーバーの作成は、何らかの理由で完全に機能する既製のサーバーを使用したいというニーズ、要望、または不本意によってそれぞれ発生する可能性があります。独自のプロトコルに従って動作し、いくつかの問題を解決するサーバーソフトウェアがあり、HTTPプロトコルを介してこのソフトウェアのAPIを発行する必要があるとします。サーバーを構成し、HTTPを介して現在のステータスを取得するために使用できる機能はごくわずかです。たとえば、パラメータを使用してGET要求の処理を整理し、応答またはその他の形式で小さなxmlを指定した場合。この場合、わずかな労力で独自のhttpサーバーを作成できます。これは、メインサーバーソフトウェアのインターフェイスになります。さらに、特定のファイルセットを配布するために独自の小規模なサービスを作成する必要がある場合、または独自のWebアプリケーションを作成する必要がある場合は、このような自作の小規模サーバーを使用することもできます。一般的に、これを使用して自己完結型のサーバーソフトウェアを構築したり、大規模なシステム内でサポートサービスを作成したりできます。

40行未満のシンプルなhttpサーバー

libeventを使用して単純なシングルスレッドHTTPサーバーを作成するには、次のいくつかの簡単な手順に従う必要があります。

event_init関数を使用して、グローバルライブラリオブジェクトを初期化します。この関数は、シングルスレッド処理にのみ使用できます。マルチスレッドの作業では、スレッドごとにオブジェクトを作成する必要があります（これについては後で詳しく説明します）。
httpサーバー自体の作成は、グローバルイベント処理オブジェクトを備えたシングルスレッドサーバーの場合、evhttp_start関数によって実行されます。最後にevhttp_startで作成されたオブジェクトは、evhttp_freeで削除する必要があります。
着信要求に応答するには、evhttp_set_gencbを使用してコールバック関数を設定する必要があります。
その後、event_dispatch関数を使用してイベントループを開始できます。この関数は、グローバルオブジェクトを持つ単一のスレッドで動作するようにも設計されています。
要求を処理するとき、evhttp_request_get_output_buffer関数を使用して応答用のバッファーを取得できます。このバッファにコンテンツを追加します。たとえば、evbuffer_add_printf関数を使用して文字列を送信し、evbuffer_add_fileを使用してファイルを送信できます。その後、要求に対する応答を送信する必要があります。これは、evhttp_send_replyを使用して実行できます。

40行未満のシングルスレッドサーバーコード：

#include <memory> #include <cstdint> #include <iostream> #include <evhttp.h> int main() { if (!event_init()) { std::cerr << "Failed to init libevent." << std::endl; return -1; } char const SrvAddress[] = "127.0.0.1"; std::uint16_t SrvPort = 5555; std::unique_ptr<evhttp, decltype(&evhttp_free)> Server(evhttp_start(SrvAddress, SrvPort), &evhttp_free); if (!Server) { std::cerr << "Failed to init http server." << std::endl; return -1; } void (*OnReq)(evhttp_request *req, void *) = [] (evhttp_request *req, void *) { auto *OutBuf = evhttp_request_get_output_buffer(req); if (!OutBuf) return; evbuffer_add_printf(OutBuf, "<html><body><center><h1>Hello Wotld!</h1></center></body></html>"); evhttp_send_reply(req, HTTP_OK, "", OutBuf); }; evhttp_set_gencb(Server.get(), OnReq, nullptr); if (event_dispatch() == -1) { std::cerr << "Failed to run messahe loop." << std::endl; return -1; } return 0; }

HTTPリクエストを処理できる文字列「Hello World」を返すことができる40行未満であることが判明し、evbuffer_add_printf関数をevbuffer_add_fileに置き換えると、ファイルを送信できます。このサーバーを基本構成と呼ぶことができます。ほとんどの場合、自動車ディーラーや不動産業者は、どのような状況においても、追加のオプションがある場合に限り、自分の車やアパートが決して標準として停止しないことを夢見ています。しかし、そのようなオプションが消費者に必要かどうか、そしてどの程度まで...

このような基本的なパフォーマンスパッケージが提供できるものは、パラメータがわずかに異なる* nixシステムのabユーティリティを使用して確認できます。

ab -c 1000 -k -r -t 10 http：//127.0.0.1►555 /

サーバーソフトウェア：

サーバーのホスト名：127.0.0.1

サーバーポート：5555

ドキュメントパス：/

ドキュメントの長さ：64バイト

同時実行レベル：1000

テストにかかった時間：2.289秒

完全なリクエスト：50,000

失敗したリクエスト：0

書き込みエラー：0

キープアライブリクエスト：50,000

転送された合計：8500000バイト

転送されるHTML：3200000バイト

1秒あたりのリクエスト：21843.76 [＃/秒]（平均）

リクエストあたりの時間：45.780 [ms]（平均）

リクエストあたりの時間：0.046 [ms]（平均、すべての同時リクエスト全体）

転送速度：3626.41 [Kバイト/秒]受信

接続時間（ミリ秒）

最小平均[±sd]最大中央値

接続：0 3 48.6 0 1001

処理中：17 42 9.0 43 93

待機中：17 42 9.0 43 93

合計：19 45 49.7 43 1053

ab -c 1000 -r -t 10 http：//127.0.0.1∗555/

サーバーソフトウェア：

サーバーのホスト名：127.0.0.1

サーバーポート：5555

ドキュメントパス：/

ドキュメントの長さ：64バイト

同時実行レベル：1000

テストにかかった時間：5.004秒

完全なリクエスト：50,000

失敗したリクエスト：0

書き込みエラー：0

転送された合計：6,300,000バイト

転送されるHTML：3200000バイト

1秒あたりのリクエスト：9992.34 [＃/ sec]（平均）

リクエストあたりの時間：100.077 [ms]（平均）

リクエストあたりの時間：0.100 [ms]（平均、すべての同時リクエスト全体）

転送速度：1229.53 [Kバイト/秒]受信

接続時間（ミリ秒）

最小平均[±sd]最大中央値

接続：0 61 214.1 20 3028

処理：7 34 17.6 31 277

待機中：6 28 16.9 25 267

合計：17 95 219.5 50 3055

このテストは、32ビットUbuntu 12.10オペレーティングシステムを実行しているそれほど新しいラップトップ（2コア、4 GBのRAM）で実行されました。

マルチスレッドHTTPサーバー

マルチスレッドは必要ですか？質問は修辞的です...すべてのIOを1つのスレッドに整理し、リクエストをキューに入れて複数のスレッドにスクープできます。この場合、上記のサーバーには、処理用のキューとスレッドのプールを追加するだけでよく、他には何もフェンスしないでください。マルチスレッドサーバーを構築したいという要望がある場合、以前のサーバーよりも少し長くなりますが、それほど長くはなりません。上記の例のstd :: unique_ptrで示されたように、スマートポインターを備えたC ++ 11ではRAIIを適切に実装でき、ラムダ関数の存在によりコードがわずかに削減されます。

マルチスレッドサーバーの例は、そのイデオロギーがシングルスレッドサーバーに似ており、マルチスレッドに関連する一部の機能はコード量の約2倍増加します。 C ++でのマルチスレッドhttpサーバー用の数行のコードで80はそれほど多くありません。

作成できる1つのソリューション：

たとえば、プロセッサコアの数の2倍に等しい複数のスレッドを作成します。 C ++ 11はスレッドの操作をサポートしており、独自のラッパーを記述する必要はなくなりました。
スレッドごとに、event_base_new関数を使用して独自のイベント処理オブジェクトを作成します。最後に作成されたオブジェクトはevent_base_free関数によって削除する必要があり、std :: unique_ptrおよびRAIIにより、これをよりコンパクトに行うことができます。
上記のオブジェクトを考慮して、ストリームごとに、evhttp_new関数を使用して独自のhttp-serverオブジェクトを作成します。このオブジェクトも最後に削除する必要があります。これは、evhttp_freeを使用して実行できます。
前の例のように、evhttp_set_gencbを使用して要求ハンドラーをインストールします。
この手順は最も奇妙な場合があります。ソケットを作成して、それぞれが独自のスレッドに配置されている複数のハンドラーのネットワークインターフェイスにバインドする必要があります。ここで、APIを使用してソケットを操作（ソケットを作成、構成、特定のインターフェイスにバインド）してから、evhttp_accept_socket関数を使用して操作用のソケットをサーバーに渡すことができます。これは長い時間です。 Libeventは、この問題を解決するためのいくつかの機能を提供します。前述のように、libeventを使用すると、必要に応じてレベルを下げたり、必要に応じて最適なレベルを選択したりできます。この場合、最初のスレッドでは、ソケットの作成、その構成とバインドのすべての作業はevhttp_bind_socket_with_handle関数によって実行され、他のフローのソケットはevhttp_bound_socket_get_fdを使用して構成済みオブジェクトから抽出されます。他のすべてのスレッドは既に受信したソケットを使用しており、evhttp_accept_socket関数による処理用に設定しています。少し奇妙ですが、ソケットを操作するためにAPIを使用するよりもはるかに簡単で、クロスプラットフォームを検討する場合はさらに簡単です。 BerkeleyソケットのAPIは同じように見えますが、たとえばWindowsやLinux向けにクロスプラットフォームソフトウェアを使用して作成した場合、あるオペレーティングシステム用に記述されたコードは、別のオペレーティングシステム用のコードとはまったく異なります。
イベントループを開始します。シングルスレッドサーバーとは異なり、これは別の方法で行う必要があります。誰もが異なるオブジェクトを持っているからです。 libevent（event_base_dispatch）にはこのための特別な機能があります。私にとっては、マイナスが1つあります。正しい方法で修正することは困難です（たとえば、event_base_loopexitを呼び出すことができる状況が必要な場合）。これを行うには、少しかわす必要があります。したがって、関数event_base_loopを使用できます。この関数は、処理するイベントがなくてもブロックせず、制御を返します。これにより、イベント処理サイクルを完了する簡単な機会と、呼び出し間で何かを行う機能が提供されます。マイナスもあります-プロセッサを無駄に使用しないために、少なくともわずかな遅延を設定する必要があります（C ++ 11では-std :: this_thread :: sleep_for（std :: chrono :: milliseconds（10）））
要求処理は最初の例に似ています。
次のスレッドの作成および構成中に、その機能に問題がある可能性があります。たとえば、一部のlibevent関数がエラーを報告しました。この場合、例外をスローしてキャッチし、同じC ++ 11ツール（std :: exception_ptr、std :: current_exceptionおよびstd :: rethrow_exception）を使用してストリームの外部に送信できます。

シンプルなマルチスレッドサーバーコード：

 #include <stdexcept> #include <iostream> #include <memory> #include <chrono> #include <thread> #include <cstdint> #include <vector> #include <evhttp.h> int main() { char const SrvAddress[] = "127.0.0.1"; std::uint16_t const SrvPort = 5555; int const SrvThreadCount = 4; try { void (*OnRequest)(evhttp_request *, void *) = [] (evhttp_request *req, void *) { auto *OutBuf = evhttp_request_get_output_buffer(req); if (!OutBuf) return; evbuffer_add_printf(OutBuf, "<html><body><center><h1>Hello Wotld!</h1></center></body></html>"); evhttp_send_reply(req, HTTP_OK, "", OutBuf); }; std::exception_ptr InitExcept; bool volatile IsRun = true; evutil_socket_t Socket = -1; auto ThreadFunc = [&] () { try { std::unique_ptr<event_base, decltype(&event_base_free)> EventBase(event_base_new(), &event_base_free); if (!EventBase) throw std::runtime_error("Failed to create new base_event."); std::unique_ptr<evhttp, decltype(&evhttp_free)> EvHttp(evhttp_new(EventBase.get()), &evhttp_free); if (!EvHttp) throw std::runtime_error("Failed to create new evhttp."); evhttp_set_gencb(EvHttp.get(), OnRequest, nullptr); if (Socket == -1) { auto *BoundSock = evhttp_bind_socket_with_handle(EvHttp.get(), SrvAddress, SrvPort); if (!BoundSock) throw std::runtime_error("Failed to bind server socket."); if ((Socket = evhttp_bound_socket_get_fd(BoundSock)) == -1) throw std::runtime_error("Failed to get server socket for next instance."); } else { if (evhttp_accept_socket(EvHttp.get(), Socket) == -1) throw std::runtime_error("Failed to bind server socket for new instance."); } for ( ; IsRun ; ) { event_base_loop(EventBase.get(), EVLOOP_NONBLOCK); std::this_thread::sleep_for(std::chrono::milliseconds(10)); } } catch (...) { InitExcept = std::current_exception(); } }; auto ThreadDeleter = [&] (std::thread *t) { IsRun = false; t->join(); delete t; }; typedef std::unique_ptr<std::thread, decltype(ThreadDeleter)> ThreadPtr; typedef std::vector<ThreadPtr> ThreadPool; ThreadPool Threads; for (int i = 0 ; i < SrvThreadCount ; ++i) { ThreadPtr Thread(new std::thread(ThreadFunc), ThreadDeleter); std::this_thread::sleep_for(std::chrono::milliseconds(500)); if (InitExcept != std::exception_ptr()) { IsRun = false; std::rethrow_exception(InitExcept); } Threads.push_back(std::move(Thread)); } std::cout << "Press Enter fot quit." << std::endl; std::cin.get(); IsRun = false; } catch (std::exception const &e) { std::cerr << "Error: " << e.what() << std::endl; } return 0; }

コードでは、各スレッドがしばらく待ってから作成されていることがわかります。これは、サーバーの最終バージョンですでに修正される小さなハックです。現時点では、これが行われない場合、スレッドを何らかの方法で同期する必要があるとしか言えないため、ソケットを作成してバインドするための「奇妙なステップ」を解決します。簡単にするために、このハックはそのままにしておきます。また、上記のコードでは、ラムダ関数は物議を醸す解決策のように見えるかもしれません。ラムダは、たとえば、標準アルゴリズムを使用する場合のある種の述語として使用すると、優れたソリューションになります。同時に、より大きなコードを書くときの使用について考えることができます。上記の例では、すべてを通常の関数に入れ、必要なすべてのパラメーターを渡し、C ++ 03スタイルのコードを取得できます。同時に、ラムダの使用によりコードの量が削減されました。私の意見では、コードが小さい場合、ラムダは最短のコンテンツではなく、コードの品質に悪影響を与えない場合でも非常にうまく適合することができます。主な機能。

前の例と同じパラメーターを使用して、マルチスレッドサーバーのテストを実行しました。

ab -c 1000 -k -r -t 10 http：//127.0.0.1►555 /

サーバーソフトウェア：

サーバーのホスト名：127.0.0.1

サーバーポート：5555

ドキュメントパス：/

ドキュメントの長さ：64バイト

同時実行レベル：1000

テストにかかった時間：1.576秒

完全なリクエスト：50,000

失敗したリクエスト：0

書き込みエラー：0

キープアライブリクエスト：50,000

転送された合計：8500000バイト

転送されるHTML：3200000バイト

1秒あたりのリクエスト：31717.96 [＃/ sec]（平均）

リクエストあたりの時間：31.528 [ms]（平均）

リクエストごとの時間：0.032 [ms]（平均、すべての同時リクエスト全体）

転送速度：5265.68 [Kバイト/秒]受信

ab -c 1000 -r -t 10 http：//127.0.0.1∗555/

サーバーソフトウェア：

サーバーのホスト名：127.0.0.1

サーバーポート：5555

ドキュメントパス：/

ドキュメントの長さ：64バイト

同時実行レベル：1000

テストにかかった時間：3.685秒

完全なリクエスト：50,000

失敗したリクエスト：0

書き込みエラー：0

転送された合計：6,300,000バイト

転送されるHTML：3200000バイト

1秒あたりのリクエスト数：13568.41 [＃/ sec]（平均）

リクエストあたりの時間：73.701 [ms]（平均）

リクエストあたりの時間：0.074 [ms]（平均、すべての同時リクエスト全体）

転送速度：1669.55 [Kバイト/秒]受信

接続時間（ミリ秒）

最小平均[±sd]最大中央値

接続：0 36 117.2 23 1033

処理中：3 37 10.0 37 247

待機中：3 30 8.7 30 242

合計：9 73 118.8 61 1089

サーバーの最終バージョン

基本的な機器が提供されますが、オプションの小さなセットを持つ機器もあります。今度は、少しチューニングを加えて、より有用で機能的なものを作成する番が出ました。

最小HTTPサーバー：

 #include "http_server.h" #include "http_headers.h" #include "http_content_type.h" #include <iostream> int main() { try { using namespace Network; HttpServer Srv("127.0.0.1", 5555, 4, [&] (IHttpRequestPtr req) { req->SetResponseAttr(Http::Response::Header::Server::Value, "MyTestServer"); req->SetResponseAttr(Http::Response::Header::ContentType::Value, Http::Content::Type::html::Value); req->SetResponseString("<html><body><center><h1>Hello Wotld!</h1></center></body></html>"); }); std::cout << "Press Enter for quit." << std::endl; std::cin.get(); } catch (std::exception const &e) { std::cout << e.what() << std::endl; } return 0; }

C ++ httpサーバーの非常に最小限のコード。すべてに料金がかかります。そして、この場合、サーバーを作成するためのクライアントコードのこのような単純さは、libeventの提案されたラッパーに隠されたより長い実装によって支払われます。実際、売り上げはわずかに増加しています。以下に、その断片について説明します。

サーバーの作成：

タイプHttpServerのオブジェクトを作成する必要があります。少なくとも、サーバーが動作するアドレスとポート、スレッドの数、およびリクエストを処理するための関数をパラメーターとして渡します（この場合、リクエストの処理は最小限であるため、別個の関数またはハンドラークラス全体を作成せずに少しのラムダを実行できます）。オブジェクトの作成後、サーバーはそのオブジェクトが存在する限り機能します。
ハンドラーは、IHttpRequestインターフェイスへのスマートポインターを受け入れます。IHttpRequestインターフェイスの実装は、libeventバッファーでのすべての作業を隠し、応答を送信します。そのメソッドにより、着信要求からデータを受信し、応答を形成できます。

IHttpRequestインターフェイス

 namespace Network { DECLARE_RUNTIME_EXCEPTION(HttpRequest) struct IHttpRequest { enum class Type { HEAD, GET, PUT, POST }; typedef std::unordered_map<std::string, std::string> RequestParams; virtual ~IHttpRequest() {} virtual Type GetRequestType() const = 0; virtual std::string const GetHeaderAttr(char const *attrName) const = 0; virtual std::size_t GetContentSize() const = 0; virtual void GetContent(void *buf, std::size_t len, bool remove) const = 0; virtual std::string const GetPath() const = 0; virtual RequestParams const GetParams() const = 0; virtual void SetResponseAttr(std::string const &name, std::string const &val) = 0; virtual void SetResponseCode(int code) = 0; virtual void SetResponseString(std::string const &str) = 0; virtual void SetResponseBuf(void const *data, std::size_t bytes) = 0; virtual void SetResponseFile(std::string const &fileName) = 0; }; typedef std::shared_ptr<IHttpRequest> IHttpRequestPtr; }

このインターフェイスを使用すると、着信リクエストから、そのタイプ、一部の属性（ヘッダー）、リクエスト本文のサイズ、リクエスト本文自体（利用可能な場合）を受信し、属性（ヘッダー）、リクエスト完了コード、およびレスポンス本文（この中に）実装では、文字列、バッファまたはファイルを応答で渡すためのメソッドがあります）。実装の各メソッドは、HttpRequestException型の例外をスローできます。

サーバーコードをもう一度見ると、リクエスト処理コードの次の行に気付くことができます。

 req->SetResponseAttr(Http::Response::Header::Server::Value, "MyTestServer"); req->SetResponseAttr(Http::Response::Header::ContentType::Value, Http::Content::Type::html::Value);

これが応答ヘッダーの構成であり、この例では、「Content-Type」や「Server」などのヘッダーフィールドが設定されています。 libeventにはHTTPのニーズをはるかに超える非常に幅広い機能があるという事実にもかかわらず、ヘッダーイベント定数のリストはありません。戻りコードのリストは不完全です（最も一般的に使用されています）。ヘッダーフィールドを定義する文字列を混乱させないため（たとえば、ユーザーコードのタイプミスを避けるため）、すべての定数はlibeventの提案されたラッパーで既に定義されています。

文字列定数を定義する例

 namespace Network { namespace Http { namespace Request { namespace Header { DECLARE_STRING_CONSTANT(Accept, Accept) DECLARE_STRING_CONSTANT(AcceptCharset, Accept-Charset) // ... } } namespace Response { namespace Header { DECLARE_STRING_CONSTANT(AccessControlAllowOrigin, Access-Control-Allow-Origin) DECLARE_STRING_CONSTANT(AcceptRanges, Accept-Ranges) // ... } } } }

文字列定数は、ヘッダーファイル内の純粋なCの古いスタイルの単純なマクロとして定義できます。また、宣言と定義を.hファイルと.cppファイルに広げながら、すでにC ++スタイルで標準化されています。ただし、ファイルの間隔を空けずに、ヘッダーファイルでのみすべての型付き定義をC ++スタイルで作成できます。これを行うには、テンプレートで何らかのアプローチを使用し、そのようなマクロを作成します（もちろん、マクロはC ++によって認識され、悪意のある少量のバームです;異種ソリューションにはより高い実行可能性があります）。

DECLARE_STRING_CONSTANT

 #define DECLARE_STRING_CONSTANT(name_, value_) \ namespace Private \ { \ template <typename T> \ struct name_ \ { \ static char const Name[]; \ static char const Value[]; \ }; \ template <typename T> \ char const name_ <T>::Name[] = #name_; \ template <typename T> \ char const name_ <T>::Value[] = #value_; \ } \ typedef Private:: name_ <void> name_;

ほとんど同じように、コンテンツのタイプを設定するための定数が定義されています。わずかな修正が必要です。リクエストへの応答でファイルを送信するときの便宜のために、ファイル拡張子によるコンテンツタイプの検索を実装したいという要望がありました。

たとえば、リクエストされたリソースへの遷移が行われたホストやページから、ユーザーがCookieを持っているなど、着信リクエストから何かを取得したい場合は、着信リクエストのヘッダーからこのすべてを取得できます。

 std::string Host = req->GetHeaderAttr(Http::Request::Header::Host::Value); std::string Referer = req->GetHeaderAttr(Http::Request::Header::Referer::Value); std::string Cookie = req->GetHeaderAttr(Http::Request::Header::Cookie::Value);

同様に、応答では、たとえば、ユーザーにいくつかのCookieを設定できます。Cookieは後でセッションで機能し、ユーザーがリソースをさまようかどうかを追跡します（応答ヘッダーの使用例は、サーバーコードに記載されています）。

HTTPを介してAPIの一部を整理する場合は、同じくらい簡単です。メソッドを作成する必要があるとします：セッションを開き、サーバーに関する統計情報を取得し、セッションを閉じます。サーバーへのこのクエリ文字列を次のようにします。

  http://myserver.com/service/login/OpenSession?user=nym&pwd=kakoyto
 http://myserver.com/service/login/CliseSession?sessionId=nym1234567890
 http://myserver.com/service/stat/GetInfo?sessionId=nym1234567890

これらのクエリ文字列に応答することにより、ユーザーサーバーは、たとえばxml形式で何らかの種類の応答を生成できます。これはサーバー開発者の仕事です。しかし、そのようなリクエストを処理する方法、それらからパラメータを取得する方法を以下に示します。

 auto Path = req->GetPath(); auto Params = req->GetParams();

上記の例の方法の1つは/ service / login / OpenSessionであり、パラメーターは渡されたキーと値のペアのマップです。パラメータカードタイプ：

 typedef std::unordered_map<std::string, std::string> RequestParams;

libevent上のラッパーの提案された最終バージョンを使用して実装できるすべてを分析した後、このラッパー自体の内部を確認できます。

クラスHttpServer

 namespace Network { DECLARE_RUNTIME_EXCEPTION(HttpServer) class HttpServer final : private Common::NonCopyable { public: typedef std::vector<IHttpRequest::Type> MethodPool; typedef std::function<void (IHttpRequestPtr)> OnRequestFunc; enum { MaxHeaderSize = static_cast<std::size_t>(-1), MaxBodySize = MaxHeaderSize }; HttpServer(std::string const &address, std::uint16_t port, std::uint16_t threadCount, OnRequestFunc const &onRequest, MethodPool const &allowedMethods = {IHttpRequest::Type::GET }, std::size_t maxHeadersSize = MaxHeaderSize, std::size_t maxBodySize = MaxBodySize); private: volatile bool IsRun = true; void (*ThreadDeleter)(std::thread *t) = [] (std::thread *t) { t->join(); delete t; };; typedef std::unique_ptr<std::thread, decltype(ThreadDeleter)> ThreadPtr; typedef std::vector<ThreadPtr> ThreadPool; ThreadPool Threads; Common::BoolFlagInvertor RunFlag; }; } </source</spoiler> <spoiler title="  HttpServer"><source lang="cpp"> namespace Network { HttpServer::HttpServer(std::string const &address, std::uint16_t port, std::uint16_t threadCount, OnRequestFunc const &onRequest, MethodPool const &allowedMethods, std::size_t maxHeadersSize, std::size_t maxBodySize) : RunFlag(&IsRun) { int AllowedMethods = -1; for (auto const i : allowedMethods) AllowedMethods |= HttpRequestTypeToAllowedMethod(i); bool volatile DoneInitThread = false; std::exception_ptr Except; evutil_socket_t Socket = -1; auto ThreadFunc = [&] () { try { bool volatile ProcessRequest = false; RequestParams ReqPrm; ReqPrm.Func = onRequest; ReqPrm.Process = &ProcessRequest; typedef std::unique_ptr<event_base, decltype(&event_base_free)> EventBasePtr; EventBasePtr EventBase(event_base_new(), &event_base_free); if (!EventBase) throw HttpServerException("Failed to create new base_event."); typedef std::unique_ptr<evhttp, decltype(&evhttp_free)> EvHttpPtr; EvHttpPtr EvHttp(evhttp_new(EventBase.get()), &evhttp_free); if (!EvHttp) throw HttpServerException("Failed to create new evhttp."); evhttp_set_allowed_methods(EvHttp.get(), AllowedMethods); if (maxHeadersSize != MaxHeaderSize) evhttp_set_max_headers_size(EvHttp.get(), maxHeadersSize); if (maxBodySize != MaxBodySize) evhttp_set_max_body_size(EvHttp.get(), maxBodySize); evhttp_set_gencb(EvHttp.get(), &OnRawRequest, &ReqPrm); if (Socket == -1) { auto *BoundSock = evhttp_bind_socket_with_handle(EvHttp.get(), address.c_str(), port); if (!BoundSock) throw HttpServerException("Failed to bind server socket."); if ((Socket = evhttp_bound_socket_get_fd(BoundSock)) == -1) throw HttpServerException("Failed to get server socket for next instance."); } else { if (evhttp_accept_socket(EvHttp.get(), Socket) == -1) throw HttpServerException("Failed to bind server socket for new instance."); } DoneInitThread = true; for ( ; IsRun ; ) { ProcessRequest = false; event_base_loop(EventBase.get(), EVLOOP_NONBLOCK); if (!ProcessRequest) std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } catch (...) { Except = std::current_exception(); } }; ThreadPool NewThreads; for (int i = 0 ; i < threadCount ; ++i) { DoneInitThread = false; ThreadPtr Thread(new std::thread(ThreadFunc), ThreadDeleter); NewThreads.push_back(std::move(Thread)); for ( ; ; ) { if (Except != std::exception_ptr()) { IsRun = false; std::rethrow_exception(Except); } if (DoneInitThread) break; std::this_thread::sleep_for(std::chrono::milliseconds(100)); } } Threads = std::move(NewThreads); } }

クエリ処理機能は、サンプルのソースファイルをダウンロードすることでフルバージョンで表示できます。以前のサンプルよりも少し多くなり、コードの可読性を損なうことなくラムダを要求することをやめました。また、IHttpRequestインターフェイスの実装については言及しませんでした。これは、libeventバッファーを使用したルーチン作業にはほとんど関心がないためです。残りについては、最終バージョンのコードを見ると、あまり変更されていません。少しの修正と少しの「チューニング」が追加されました。

ユーザーサーバーは、すべての種類のhttp要求を処理する必要はありません。 , libevent evhttp_set_allowed_methods ( GET). libevent , .

: . «» - http- evhttp_set_max_headers_size evhttp_set_max_body_size. , . . - , , …

, GET ( ) , .

http-

 #include "http_server.h" #include "http_headers.h" #include "http_content_type.h" #include <iostream> #include <sstream> #include <mutex> int main() { char const SrvAddress[] = "127.0.0.1"; std::uint16_t SrvPort = 5555; std::uint16_t SrvThreadCount = 4; std::string const RootDir = "../test_content"; std::string const DefaultPage = "index.html"; std::mutex Mtx; try { using namespace Network; HttpServer Srv(SrvAddress, SrvPort, SrvThreadCount, [&] (IHttpRequestPtr req) { std::string Path = req->GetPath(); Path = RootDir + Path + (Path == "/" ? DefaultPage : std::string()); { std::stringstream Io; Io << "Path: " << Path << std::endl << Http::Request::Header::Host::Name << ": " << req->GetHeaderAttr(Http::Request::Header::Host::Value) << std::endl << Http::Request::Header::Referer::Name << ": " << req->GetHeaderAttr(Http::Request::Header::Referer::Value) << std::endl; std::lock_guard<std::mutex> Lock(Mtx); std::cout << Io.str() << std::endl; } req->SetResponseAttr(Http::Response::Header::Server::Value, "MyTestServer"); req->SetResponseAttr(Http::Response::Header::ContentType::Value, Http::Content::TypeFromFileName(Path)); req->SetResponseFile(Path); }); std::cin.get(); } catch (std::exception const &e) { std::cout << e.what() << std::endl; } return 0; }

おわりに

libevent . : . , http-. github . http server .

:

ab -c 1000 -k -r -t 10 http://localhost:8888/libevent_test_http_srv.zip

Server Software: test

Server Hostname: test

Server Port: 8888

Document Path: /libevent_test_http_srv.zip

Document Length: 23756 bytes

Concurrency Level: 1000

Time taken for tests: 10.012 seconds

Complete requests: 2293

失敗したリクエスト：0

書き込みエラー：0

Keep-Alive requests: 2293

Total transferred: 60628847 bytes

HTML transferred: 60328370 bytes

Requests per second: 229.02 [#/sec] (mean)

Time per request: 4366.365 [ms] (mean)

Time per request: 4.366 [ms] (mean, across all concurrent requests)

Transfer rate: 5913.65 [Kbytes/sec] received

…

!

libeventおよびC ++ 11の40行未満のコードで独自のhttpサーバー

なんで？

40行未満のシンプルなhttpサーバー

マルチスレッドHTTPサーバー

サーバーの最終バージョン

おわりに

More articles: