mirror of
https://github.com/yhirose/cpp-httplib.git
synced 2026-10-16 16:23:18 +00:00
bef278e0d2
Samples that did not compile or run as shown: - res.user_data.get<T>() inside a generic lambda needs the `template` keyword; use explicit parameter types (tour 09, cookbook s15). - listen() on a Unix domain socket fails with port 0 (tour 09, s22). - "*.dev.local" is not a NO_PROXY pattern (c16). - ssl_backend_error() holds a verify result, not an ERR_get_error() value, after a verification failure; decode each with the matching OpenSSL function (c18). - The content provider's `length` is everything that remains, so the sample read the whole file in one call (s05). Statements corrected: - Client keep-alive is off by default; c14 is rewritten around set_keep_alive(true). - Mounted files are looked up before GET handlers (tour 04, s04). - Params keep insertion order, and to_string(Error::Connection) reads "Could not establish connection" (tour 02). - A chunked provider ends with sink.done(), and post_routing_handler runs before the response is sent (tour 09). - Timeouts surface as Error::Read; Error::Timeout comes from the stream API (c17). The max timeout cuts off the wait for the response only (c13). The progress callback needs Content-Length (c11). - Encoding selection follows q-values, then Brotli, gzip, Zstd (s08), and the client compresses with the first of those it was built with (c15). - stop() cuts a provider-driven response short (s19); a rejected content_reader already gets 400 or 413 (s07); user_data values must be copyable (s12); Client accepts a client certificate too (t04); on_message() is the fallback for every unhandled event and 204/403/404 end reconnection (e04); the pong timeout takes two to three intervals and ends a waiting read() (w02). In the LLM app tutorial, an uncaught exception does not crash the server, so say what it does instead. Drop the server and client timeout settings whose stated purpose, covering inference and download time, they do not serve: those timeouts bound a single socket wait. Update the llama.cpp server layout in chapter 7.
2.4 KiB
2.4 KiB
title, order, status
| title | order | status |
|---|---|---|
| C14. 接続の再利用とKeep-Aliveの挙動を理解する | 14 | draft |
httplib::Clientは、デフォルトではリクエストごとに接続を閉じます（Connection: closeを送ります）。set_keep_alive(true)を呼ぶと、同じインスタンスで送る複数のリクエストが1本のTCP接続を使い回すようになり、TCPハンドシェイクやTLSハンドシェイクのオーバーヘッドを毎回払わずに済みます。
Keep-Aliveを有効にする
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
auto res1 = cli.Get("/users/1");
auto res2 = cli.Get("/users/2"); // 同じ接続を再利用
auto res3 = cli.Get("/users/3"); // 同じ接続を再利用
あとはcliを使い回すだけで、内部的には同じソケットで通信が続きます。とくにHTTPSでは、TLSハンドシェイクのコストが大きいので効果が顕著です。
Keep-Aliveをオフに戻す
毎回新しい接続を張り直す動作に戻したい場合は、set_keep_alive(false)を呼びます。これがデフォルトの動作です。
cli.set_keep_alive(false);
リクエストごとにClientを作らない
1回のリクエストのたびにClientをスコープから抜けて破棄すると、接続の再利用は効きません。ループの外でインスタンスを作り、中で使い回しましょう。
// NG: 毎回接続が切れる
for (auto id : ids) {
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
cli.Get("/users/" + id);
}
// OK: 接続が再利用される
httplib::Client cli("https://api.example.com");
cli.set_keep_alive(true);
for (auto id : ids) {
cli.Get("/users/" + id);
}
並行リクエスト
複数のスレッドから並行にリクエストを送りたいときは、スレッドごとに別々のClientインスタンスを持つのが無難です。1つのClientは1本のTCP接続を使い回すので、同じインスタンスに複数スレッドから同時にリクエストを投げると、結局どこかで直列化されます。
Note: サーバー側のKeep-Aliveタイムアウトを超えると、サーバーが接続を切ります。cpp-httplibは次のリクエストを送る前にそれを検出して接続し直すので、アプリケーションコードで気にする必要はありません。