curlのビルドと対応機能
今回は、エンジニアだったら絶対に一度は実行したことがあるんじゃないかと思うんですけど、
curlについて話をしていけたらなと思います。
curlって言えば、僕自身はAPI叩くときに実行したりとか、
あとはサーバーのレスポンスを細かく確認したいとき、ステータスコードだったりとか、
そういったときに使うのが一般的かなと思うんですよね。
そうですね。自分も大体そんな感じなんですけど、
自分はこのポッドキャストで、これまでHP2、HP3の話とか、
あとECHの話とか、いろいろしてきたと思うんですけど、
そういう挙動の確認でもcurlを使って確認してたりします。
そういうエッチなことをやろうとすると、OSにプリインストールされているcurlだと機能が足りなかったりして、
自分でコンパイルしないといけなくなるんですよ。
なので、自分でcurlをコンパイルしていろいろやったりとか、そういう工夫をしてますね。
デフォルトのcurlの状態だと、確認できないことがあるので、
自分でサイビルドして使ってるみたいなことをしてるんですね、いろいろ。
そうですね。
ここからcurlについての詳しく話していけたらなと思うんですけど、
どういったところからいきましょうかね。
まずはライトなところからいこうかなと思うんですけど、
curlって、普通にcurlURLとかってやると、さっきも言ったとおり、
API実行できたりとか、HPレスポンス見れたりとか、そういうのがすると思うんですけど、
curl-largevって実行してもらうと、curlとかその辺のバージョンが出るし、
あとcurlって、大体のソフトウェアはそうなんですけど、
TLSを使うときに、今OpenSSLとかそういうライブラリーを使ってやってるんですよ。
なのでそのTLS何使ってんのとか、あとHP2とかHP3が使えるのとか、
他にもいろいろな設定が出てきて、このcurlはどの機能が使えるのかみたいなのが出てくるんですよね。
これってどうビルドされたかによって使える機能がだいぶ違います。
なるほど。curl自体のバージョンを表示するマイナス大文字のVってことですね。
そうですね。
で、そのビルドされたかによって、環境によってこのバージョンの出力されるものがいろいろ違うよねっていうところですね。
環境もあるし、ビルドするときにどうやってビルドしたかが結構大きいんですよね。
例えばそのcurlってHP2を使いたい場合はnghttp2っていうライブラリーが必要です。
あとHP3を使いたい場合はnghttp3とngtcp2っていう2つのライブラリーが必要だったりします。
これデフォルトでは入ってないっていう意味ですかね。
デフォルトのcurlコマンドだとnghttp2とかが入ってないのでhttp2対応してないみたいな感じですかね。
デフォルトのコンパイルオプションがどうなってるかは確認しないとわかんないんだけど、
ライブラリーは入ってないです。
なのでライブラリーは自分でダウンロードするなりしないと全部使えないですね、この辺は。
ここら辺はデフォルトで入ってるcurlがどの使ってるOSかによってちょっといろいろ差はあるけどという感じですね。
そうですね、ただ最近はさすがにHP2は大体有効になってるところが多いかなとは思いますね。
普通に使えるようにって感じですね。
そうです、みんな使うんで。
ただcurl単体だとできなくてnghttp2っていうのを一緒にビルドしないと使えないって形ですね。
だからcurl自身がそこら辺を実装しているわけではないってことですよね、独自で。
そうですね、curlのソースコードの中に直接入ってるわけじゃないですね。
別のライブラリーとして実装されているのでそちらを読み込んでるみたいなイメージ。
そうですね。
さっき言ってた、片手さんの環境だったらここら辺のライブラリーを一緒に同梱してビルドするみたいなことをしているみたいな。
そうですね、自分でやってるんですけど、結構めんどくさくて、特にHP3がすごいめんどくさくて、
まず、OpenSSLとか、この辺もちょっとめんどくさい話があるんですが、
OpenSSLとかそういうのをまずビルドしますと。
その後にnghttp3をビルドしますと。
その後にnghttp2をビルドして、初めてcurlがビルドできるんですよね。
今、順番に言っててくれたじゃないですか、nghttp2、nghttp3、nghttp2。
nghttp2ですね。
この順番って依存関係あるんですか?
そうですね、この順番でやらないとダメです。
順番が重要だと。
そうですね、一個一個ビルドしていかないとダメなんですよ。
ちなみにそれは何でですか?
単純に依存関係の問題ですね。
なるほど、先にビルドしている方が依存関係がないってことですよね。
そうですね、OpenSSLとかは単体でビルドできるんですけど、
nghttp3はOpenSSLのAPI使ってるし、nghttp2はnghttp3のAPI使ってるし、みたいな感じで、
それぞれに依存しているので、この順番でやらないとダメ。
なるほど、なんかもうめんどくさそうだなという気がしてきたんですけど。
すごいめんどくさいです。
独自のというか、それに合わせたビルドチェーンみたいないうものを構築しないといけない、そうですね。
そうですね、ただ一応カールって結構ドキュメントがいろいろあって、
HP3対応用のカールを作るんだったら、これビルドしてくださいってちゃんとドキュメントに書いてあるんですね。
優しい。
なのでドキュメント通りに順番に今言った通りに順番にコンパイルしていけば普通にできます。
基本はできるんですね。
そうですね。
この環境のやつを使いたいので、このビルドを使いたいっていう、この環境を作りたいってなったらドキュメントに大体書いてあると。
そう、大体書いてあるけど、ドキュメント通りにやればできるんですけど、
シンプルに何回も何回もコンパイルしないといけないからすごくめんどくさいっていう。
なんか単純に誰かをまとめてシェルスクリプト書いてくれてるんじゃないのかなと思っちゃったんですけど。
書いてる人は多分いるとは思うんですけど、本当に変わるっていろんな機能あるんで、
そのピンポイントでそれを見つけてくる方がめんどくさいってなりますね。
なるほど。組み合わせが多種多様ってことですね。
そうですね。自分も使ったことのない組み合わせがたくさんあるし、本当に機能が多いので、
自分が使いたい機能をピンポイントでそういうのを作ってる人を探すよりは自分でやっちゃった方が多分楽。
ちゃんとドキュメント見て読み解いて、ここの部分だったらこうやればいいんだねっていうような形を取った方が普通に早いよねってことですね。
HTTP/3対応TLSライブラリの系譜
そうですね。もう一個めんどくさい、最近はそうでもないんだけどもともとめんどくさい話があって、HP3の場合。
自分が最初HP3対応のカールをコンパイルした当時って、
ドキュメントにはバーリングSSLっていうGoogleがOpenSSLをフォークして作ったやつがあって、
このバーリングSSL互換のQuick APIっていうのを使って実装されてたんですね。
これ何でかっていうと、当時OpenSSLがHP3に必要なQuickのAPIの実装をしてなくて、
GoogleがバーリングSSLで実装してたんですよ。そっちが先行してたんですね。
このバーリングSSLがChromeとかAndroidとかに組み込まれているTLSのライブラリになるので、
この辺でどんどんChromeのためにどんどんこの辺に機能が足されていったんですよ。
で、OpenSSLにバーリングSSL互換のAPI足そうって言って、
OpenSSLをフォークした人たちがいて、
またさらにフォークした。
そうですね。それがQuick TLSってやつなんですよ。
もともとHP3対応のカールのドキュメントにはこのQuick TLSを使う方法が紹介されてました。
けど、自分はLibreSSLっていう、これもOpenSSLのフォークなんですけど、
LibreSSLを推しなので、
当時LibreSSLにもバーリングSSL互換のAPI実装してたんですよ。
なのでドキュメントにはないけど、LibreSSLでもコンパイルできるのではと思って、
自分が最初やったときはLibreSSLを使ってコンパイルしました。
特に問題なく使えたので、
特にドキュメントには書かれてなかったけど、問題なく使うことができましたね、当時。
すごく今バーって言ってもらったんですけど、すごく複雑だなというところがあるんですか。
全てはあれですよね、OpenSSLから派生してフォークされた各種なんとかSSLだったりTLSだったりとかいうライブラリーが存在していて、
それらがGoogleが作ったバーリングSSLの互換のAPIをそれぞれが生やし出して、互換性があるので動いたっていうところなんですね。
当時はOpenSSLだとHP3は使えなかったので、
OpenSSL以外のOpenSSLのフォークを使う必要があったって形ですね、当時は。
OpenSSL公式の方はなんで対応しなかったんですかね。
その辺は正直よくわかんない部分はあるんですけど、結局今はOpenSSLにもあります。
ちゃんと対応されてるんですね。
対応されてるんですけど、ただバーリングSSL互換ではない、また別のAPIになってますね。
なんでなんですかね、ちょっと互換性がないんですね。
正直わかんないけど、正直見えの部分もあるんじゃないかなと思ってて。
自分たちが主流だから、後追いする必要はないみたいなのが多分あったのかなと個人的には思ってますね。
ちょっとプライドが見え隠れするところですね。
そうですね、正直最初はQuickTLSもOpenSSLにフォークしてくださいってお願いしてたんですよ。
オープンSSLにフォークしてくださいっていうか取り組んでください。
バーリングSSLの互換API入れたいからこれ取り込んでくださいって最初お願いしてたんですけど、
結局OpenSSLは自分たちでやるから取り込みませんって拒否されちゃったんだよね。
突っ跳ねたんですねそこで。
突っ跳ねちゃったからじゃあもうQuickTLSとして自分たちでやりますってなったっていう経緯が元々あった感じですね。
なるほどそういう歴史的経緯があって一回突っ跳ねたからちょっとじゃあ時代が変わって新しいAPIと同じようなものを取り込んでみようかなっていう時代になったけどそのまんまじゃいけんよなみたいな。
自分たちは自分たちでやりましょうっていう。
なので今OpenSSLだけ別のAPIっていう状況にはなってますね。
めちゃくちゃ面倒くさいですね。
カールはなんと両方とも対応しています。
すごいしっかりしてる。
カールが対応しているというよりはNGTCP2が対応しているっていう方が正確かもしれないけど。
カールが使っているライブラリーの方が対応しているから。
カールが利用しているライブラリーが両方とも対応しているから結果的にカール両方とも使えているっていう。
幸せな世界ですね。
そっちのライブラリーが頑張ってるっていう話なんだけど、結局APIが統一されなかったのでこの辺はライブラリーが頑張ってくれていると。
吸収してくれてるって感じですね。
LibreSSLとOpenSSL、ECH対応の違い
なので今はOpenSSLでもHP3を有効にすることはできるんですけど、当時できなかったので自分はLibreSSLを使ってました。
ちょっとここらへん歴史的経緯というかやっぱ人間が運営してるなという感じが出てきますね。
ちなみにMacで最初から入っているプリインストールされているカールは実はLibreSSLを使ってますね。
そうなんですね。
AppleがLibreSSL推しらしくて。
OpenSSLじゃないんですね。
Mac実はOpenSSLコマンド入ってるけどあれはLibreSSLですね。結構古いんだけど。
ちなみにちょっと話で破綻しちゃうかもしれないんですけど、なんで片杖さんはLibreSSL推しなんですか?
LibreSSLってセキュリティ重視なんですよね。その代わりパフォーマンスは遅いんですけど、
OpenSSLからなんでフォークしたかというと、そのセキュリティ、脆弱性がOpenSSLいくつか出てる中で、
もっとセキュアなOpenSSLが欲しいって言ってできたのがLibreSSLなんですよ。
そういう立ち上げ目的というかフォーク目的なんですね。
なので実際脆弱性、OpenSSLより少ない印象は個人としてはあるので、自分は結構LibreSSLをしてますね。
OpenSSLの方で対応しきれてないセキュリティのイシューをLibreSSLでは積極的に取り込んでるっていうところですかね。
基本的にOpenSSLは破格したセキュリティイシューは全部対応してるんですよ。
というよりも例えばOpenSSLは速度のためにちょっとセキュリティ的に大丈夫なのか怪しいことをやってたりとかするんですよ。
そういうのは怪しいやり方というかアーキテクチャ的な問題?
例えばマロックとかメモリのアロケートとかをOpenSSL独自でやってたりとかするんですよね。
そういうパフォーマンスのための細かいことをやってるんですけど、LibreSSLはそういうの全部OS側の普通の仕組みに乗っかってたりするんですよね。
なるほど独自で実装してしまってるが故に若干セキュリティ的に怪しいよねみたいなところが一番。
そのコードって本当にチェックしたのみたいな。
なるほど。
LibreSSLはそういうちょっと危なそうなコードとかを全部削除しているっていう特徴で、その代わりLibreSSLのほうが全然パフォーマンスは遅い。
カリカリにチューニングされてるのがOpenSSLで、OSの機能をできる限り使ってセキュアにしたのがLibreSSLですね。ざっくり言うと。
ざっくりそういう理解で大丈夫だと思います。
ありがとうございます。LibreSSL推しの理由が若干分かりました。
AppleはLibreSSL使ってるよねっていうところなんですね。
AppleはLibreSSL推しなので、実はみんなLibreSSL使ったことないと思ってるかもしれませんが、Mac使ってる人はみんな使ったことあると思います。
なんとなくOpenSSL使ってるのかなと思ってたらLibreSSL自分使ってましたね。いつの間にか。
OpenSSLっていうコマンドなんだけどLibreSSLです実は。
MacでOpenSSL使ってると思ったらLibreSSLなんですね中身あれ。
そう、あれ中身LibreSSLです。古いLibreSSLですね。
分かりづら。
そうですよ。意外と知られてないんですけどあれLibreSSLです。
今衝撃的な事実だったんですけど、そんなこともありえるんですね。
そうですね。
ちょっとお話。
自分はLibreSSL推したと。
これはめんどくさいじゃないですか。
なので自分はHomebrewにしました。Homebrewフォーミュラーで実装しましたね。
HomebrewってなんかRubyのコードで書けるんですよね。いろいろコマンドのシェルスクリプトみたいなのをかけてこれコンパイルした後にこれコンパイルしてみたいなのをRubyで書けるんですよHomebrewって。
カールをビルドする時のビルドスクリプトみたいなのをRubyで書けるみたいな。
そうですね。Homebrewだったら。
Mac変える度にとか他のMacとかで毎回毎回これビルドしてるのつらすぎるんで。
ではHomebrewフォーミュラーにしてこれで好きな時にブリュー経由でHP3が使えるカールをインストールできるようにしてます。
すごい。自分でMac変えた時用のスクリプトを用意してるってことですね。
そうですね。だってこのカールを手に入れるためだけに何回も何回もビルドしないといけないからマジでめんどくさいんですよ。
そのフォーミュラー自体はRubyのスクリプトで書かれているってことなんですけどGitHubとかで。
普通にGitHubでできますよ。Brewタップで自分のやつタップしてもらえれば普通に入りますね。
公開リプして出して公開して。
公開してます。
ちなみにサーバーとかVPSのサーバーとかでカールインストールしたい時にも同じHomebrew使ってるんですかね。
Homebrew一応Linux版もあるんですけど自分はLinuxの方は使ってないですね。
それで言うとLinuxであんまりコンパイルしてないかもしれないですね。Docker経由で使ったりとかしてる気がします。
Dockerファイルとかでカール自前ビルドしたい時はDockerビルドしてみたいな感じですね。
やることもありますね。
なるほど。じゃあ基本的にカールをカスタマイズしてビルドして使ってるのはクライアントであるMacなんですね。
Macが多いですね自分は。
そういった形でカールを自前ビルドしているっていう形なんですけど何か他にあったりしますかね。
そうですね。LibreSSLの話をしたんですけどLibreSSLって結構致命的な欠点があってセキュリティ重視なんで開発が遅いんですよ。
なるほど。
新機能をガンガン入れてないんですよね。
うんうん。
なので前回ECHの話をしたんですけど実はLibreSSLにはまだECHの機能入ってません。
使えないじゃないですか。
使えないんですよ。なのでECH使いたいなーと思ってLibreSSLだと使えないんで。
でOpenSSLがあのLTSじゃないやつで4.0っていうLTSじゃないんですけど4.0が今最新の開発版みたいになっていてこの4.0からECHが入ってます。
なのでECH使いたいんで今までLibreSSL使ってたんですけどちょっとECH使いたいからOpenSSLに戻ろうかなと思って今はOpenSSL4.0でECHまで使えるようにしてます。
じゃあちょっと新条を曲げてでも最新の機能を使いたかったからOpenSSLをビルドしてっていうような形で使ってるんですね現状で。
そうですねまあ新条ってことじゃないんだけどまあ確かにLibreSSLがECH対応したら多分乗り換えると思います。
すぐに乗り換えるけども。
けどまあ今は使えないんでまあOpenSSLを使ってやってますね。
ちなみにLibreSSLでECH対応する見込みというかなんかプロジェクトが立ってるんですかね。
最近確認してないけどなんかあんま立ってなかったような気が。
なんか一周とかでちょっと言ってる人はいるけどそのメンテナーの人あんま反応しなかった気はしますね。
なるほど。
なんかLibreSSLってなんか結構ゆっくりなんですよそういう新規の追加が。
その新規の追加によって脆弱性出るかもしれないからなんかそういうの結構嫌がるんですよねLibreSSL。
かなり保守的というか変更でかい変更っていうのをまああまり入れない方針ってことですよね。
そうですね。
まあだから安心できるんですけどこういうECHとかやりたいなと思ったら使えないって感じです。
確実に保守的じゃないですからね。
ECHみたいな新しい機能を試したいみたいないうのはちょっとエッチケースだと思うので。
実際OpenSSLもまだLTSに入ってないんでECH。
なのでまあ最先端というかそういうのでやりたい場合はLibreSSL向かないですね。
ちなみにBowlingSSLとかQuickTLSとか他さっき言ってたLibreとかは採用してたりするんですかねECHもすでに。
BowlingSSLは多分対応してるんじゃないかなとは思うんですけどただBowlingSSLってGoogle社内で使ってるやつなんですよ。
なのであのあんまり外の人が使える感じになってなくて。
なるほど。
というのもOpenSSL例えばv4.0.0ってバージョン切ってるじゃないですかバージョンタグ。
けどBowlingSSLってもうメインブランチみたいなのしかなくて。
どこのバージョン使ったらいいのかが正直よくわかんない。
じゃあちょっとなんかあれですね。
Google社内のドキュメントでちょっと公開されている情報というのが表に出てきてないか。
もうなんかすごい雑な開発をしているのか。
それでいうと、Chromiumで使ってるBowlingSSLがどれかとかは多分調べればわかるんだよね。
あとAndroidが使ってるBowlingSSLのバージョンがどれかとかも調べればわかるんだけど。
多分BowlingSSLはもうそのソースコードを中身知ってる人が使う前提なんじゃないかなって自分は思ってたりしますね。
メンテナンスしてる人たちが使ってる側とほぼ一緒だよねっていう前提に立ってるライブラリだよねっていう。
そうですね。なのでBowlingSSLは知名度は高い。
この辺やってる人からすると知名度は高いんですけど、使ってるケースはそんなに多くないですね。
やっぱりそのソースコードをちゃんと読んでる人じゃないと使えないと思いますねBowlingSSLは。
ちゃんと対応してるかどうかっていうのもそもそもわかんないしみたいな。
そうですね。基本外の人が使う想定をしてないと思います多分。
ちなみにもう一個のQuickTLSは。
QuickTLSは多分最近あんま動いてないんじゃないかな。
もともとOpenSSLにHP3互換のAPIを入れようって立ち上がったやつで、
もともとQuickTLSが結構デファクトスタンダードみたいになってて、
Node.jsとかはQuickTLSだったりするんですけど、
最近はもうOpenSSLに入ったから多分もうやる気のある人があんまいない気はしますね。
OpenSSL使えばいいじゃんっていう。
最初の目的達成したからもういいよねっていう。
っていうのはあるんじゃないかなと思いますね。
それはわかりやすいですよね。
まあまあまあなんで今だったらOpenSSLを使うか、
LibreSSLとかBoringSSLとか使う人が多いんじゃないかな。
なるほど。
ただ最新バージョンのものを使いたかったら、
OpenSSLの4.0を使うしかないっていうような現状ってことですね。
一番使いやすいのは多分OpenSSL4系だと思いますね、今だったら。
ただやっぱこれエッチなんで、
実際自分4.0.0でやったんですよ一回以前。
そしたらHP3とECHの組み合わせがなぜか動かなくて、
これ一応調べたら一周登録されてて動いてないよっていう一周があって、
自分も動いてないなーと思ってたんですよ。
で、今回このPodcastを撮るってことで、
先日また確認したらOpenSSL4.0.2に上げて、
変わるも上げてやったらHP3でもECH使えました。
なのでそれぐらいまだ結構バグってるというか、
そもそもエクスペリメンタルな機能なんだよね。
実験的なところなのでまだバグってるよね。
そう、OpenSSLも変わるもどっちもエクスペリメンタルじゃないかなこの辺は。
なので普通にまだバグってることはある。
ぐらいのエッチな機能になりますね。
ていうと、ECHの確認するのに立てたVPSで、
片瀬さんが自分で運用してるVPSでECH対応したときに確認したのはブラウザーってことですかね。
ブラウザーが多いですかね。
でも変わるで手元でやりたいケースもあるので、
やっぱり両方ともできるようにはいつも極力したいなと思ってますね。
だからこういうことやってるんですけど。
ちょっとカールの中身とかブラウザーが使っているライブラリ、
OpenSSLなのかWarningSSLなのかとか、
そういう細かいところを知ってないとというか、
そういうところまで気を配らないと、
対応している機能がどれかってなかなか見えづらいですね、
ここの最新機能とかに関しては。
やっぱ最新機能なんで、
このOpenSSLのこのバージョンじゃないと使えないとか色々あるので、
その辺を把握してないとダメですね。
難しいですね、クライアント側のことも加味しないといけないので、
色々見ないといけないなというのが、
そこはめんどくさいですけどね。
ただこの辺ちゃんとやって、
あとコンパイルするときにenableECHとかその辺の必要なオプション渡せば、
一応使えるは使えるって感じですね。
じゃあ今、片手さんの環境では使えるとECHが。
今CURLでECH使えます。
便利。
なので確認するときとか使ったりしますね。
そうやって確認してる人がどれだけいるのかという感じも若干しますね。
そうですね、どれぐらい使われてるかわかんないけど、
一応CURLのドキュメントにはあるので、
まあまあ何か使ってるんじゃないかな。
もしこれ聞いてる人の中でね、
CURLでECH確認してるよっていう人がいたらかなり特殊だと思うので、
自分もやってますという人がいたらコメント絶対に書いてほしいんですけどね。
お願いします。
ちなみに前もちょっとECHの時に話したと思うんですけど、
DNSを暗号化しないとECHって意味ないよねって話したと思うんですけど、
CURLも基本的にはDNS over HTTPSを使う前提で作られてたりしますね。
DNSに確認していって、証明書、鍵か、鍵をダウンロードしてっていうような形を取ってるってことですかね。
そうですね、基本的にはCURLでもそういう実装になってますね。
わかりやすいですね。
まあまあまあ、その辺はブラウザーと一緒って感じかなって感じですね。
そんな形でCURLいろいろカスタマイズして、やりくりして、ライブラリーも変えたりとかしていろいろいじってるかなと思うんですけど、
CURL使ってる中で迷ったところっていうか、悩んだところとかってあったりするんですかね。
curlオプションの互換性と--resolve
なんかそれがあってですね、なんか実はCURL、あんま知られてない気がするんですけど、
互換性がなくなったことがあって、自分すごい困ったんですよね。
互換性がなくなったことというのは、前のバージョンのCURLと新しいCURLのバージョンでなんか違うけどになったりとか。
これが結構自分困って、
--TLS-V1.1っていうオプションがあって、
これをやると、昔はTLS1.1を使って通信するっていう意味だったんですよ。
絶対にTLS1.1を使えよというようなオプションですね。
名前的にもそうじゃないですか、V1.1.1だから。
--そんな気がしますよね。
--って思ってたら、なんか仕様が変わって、TLS-V1.1はTLS1.1以上を使うっていう意味になったんですよ。
--すごい変更じゃないですか、これ。
--そう、だからTLS-V1.1で通信できないことを確認しようとしたら、なんか通信できるってなって、
よく見たらTLS1.2で通信してるってなって、え、どういうこと?ってなったんですよ。
--おいおいおいって感じですよね、これ。
--そう、わざわざこれつけるのは、なんかTLS1.1で通信できないことを確認したかったのに、あれ通信できんじゃんってなったんですよ。
--だからCIとかで、この--TLS-V1.1をつけて失敗することをCIで確認したいみたいなところで使ってたところが、
変わるバージョンをアップしちゃったら、え、なんかグリーンになったんですけどみたいなことが起きえたってことですよね、これ。
--そうですね。で、自分はこれ結構イラっとしたんですけど、今まで通りTLS1.1までに制限したいんだったら、今だとTLS-V1.1をつけて、
かつTLSMAXってオプションが追加されているので、TLSMAXで1.1って書くと、1.1以上を使うかつ1.1以下を使うみたいな設定になる。
--これ2つ使うのが、まあそもそも意味わかんないですけど。
--意味わかんないんですけど、2つ指定しないとTLS1.1を絶対使うっていう指定にはならない。
--なるほど。後者の--TLS-MAX1.1だけじゃダメってことですね。
--それだと、なんかTLS1.0とか他のやつを使う可能性があるんだよね。
--あーなるほど、そっちか。
--なのでピンポイントで1.1だけにしたい場合はこう指定しないとダメですね。
--なるほど。ビトビンというかここからここまでっていうのをちゃんと指定しないといけないんですね、範囲指定で。
--それで言うと、これTLS-V1.1じゃなくてTLS-MIN、TLS-MAXがあるならTLS-MINっていうオプションを追加して1.1とかってやるんだったらわかるんですよ。
--確かに。
--けどTLS-MINってオプションはないんですよ。
--だからTLS-V1.1の挙動を変えてしまったが故に、本当だったらMINにすべきだったところがなんか変なことになっちゃったんですね。
--そう変になってる。これは結構困ったんだけど、なんか自分以外困ってる人あんまいないのか?なんかあんま聞かないんですよね、自分以外に文句言ってる人は。
--破壊的変更ですよね、これ難しいですね。
--そうでなんかヘルプ見たらしれっと変わってたんですよね、TLS-V1.1の説明が。
--そうなんでヘルプ見たらあれ違うじゃんみたいになってめっちゃびっくりしましたね、当時。
--なるほど。そういうことも起きえるんですね、変わるぐらい。
--そういうこともあるので、まあちゃんと変だなと思ったらちゃんとヘルプ見ましょうっていうオプションがめちゃくちゃ多いんで変わるって。
--でしかもバージョンで変わることもあるから必ず自分が使っているカールでヘルプを見ましょうっていうのがここの教訓ですね。
--普通に今まで、てか変わるぐらい一般的なコマンドになるとあんま変わることなんてないだろうみたいな。
結構保守的な方だろうみたいなことを思う一方、破壊的変更もしれっとくる可能性があるってことですね。
--そう、自分もここ変わるのってめっちゃ思ったんで、めっちゃびっくりしたんで気をつけてくださいという。
--もしかしたら他にもそういうオプションがあるかもしれないですね。
--そうですね、他にも変わったやつあるかもしれないですけど、自分が困ったのはここですね。
--何か他にあったりしますか。
--他なんか自分がたまに便利に使っているオプションがあって、--Resolveっていうやつはすごい自分は便利に使ってます。
--Resolveっていうと何かを解決する感じなんだよね。
新しいサーバーとか追加して、そのサーバーはまだDNSを登録してませんみたいな時にリクエストを送れるってやつで、
昔だったらHTTPが普通だったと思うので、ホストヘッダーさえつければ大体動くので、
カール-h、ホスト、コロン、なんちゃらってホスト名でドメイン名書けば大体通信できたと思うんですけど、
今ってECH界でも話した通りSNIって言ってTLSレイヤーにドメイン名載せないと今って通信できないんですよ、HPSだから。
それをやろうとすると、例えばエトセホストにドメイン名書いて、カール-hにリクエストを送れば、そこに対してリクエストを送れるんですよね。
だけどホストってあんまりいじりたくないじゃないですか。事故にニコニコなるし。
--書き換えるの忘れるのであんまり書き換えたくないですね。
書き換えたくないじゃないですか。
なので一時的にそのコマンドでそのホスト書き換えたのと同じ効果を出したい時に使うのが--resolve。
なるほど。
自分は結構使いますね。新しく設定したサーバーで動くかどうか確認とかの時に--resolveを使います。
一時的にIPアドレスを偽装できるというか、ドメインとIPアドレスの解決を変えることができるのがオプションなんですね。
これ大きいのはやっぱりSNI、HBSに対しても使えるっていうのが大きいです。
なので--resolveは結構自分は便利に使っている超重要機能ですね。
具体的にやるとき、この--resolve使うときどういう事例とかあったりします?
めっちゃ使いますよ僕は。新しいサーバーを構築して、
そのサーバーを本番投入する前に動くかどうか確認する時に必ず--resolveを自分は使いますね。
リクエストしたい時にですね、新しいサーバーに対して。
例えば証明書を置き忘れたとか、そういう事故って可能性は全然あるので。
そのままIPアドレス直打ちだとHTTPSとかでアクセスできないので、
HTTPSでアクセスして確認する時に使いたいって事ですね。
本番同様のアクセスがしたいからって事ですね。
しかも本番サーバー複数台構築したりとかするんで、
ホスト書き換えるだと絶対事故るんですよ。
なので--resolveで一個一個確認してちゃんと動いているのを確認します。自分だったら。
確かにそっちの方が手軽ですね。
そうですね。なので--resolveは結構お勧めの機能です。
新しくサーバーを立てて検証する時に使うって感じですね。
他にあったりします?
Happy EyeballsとDNS名前解決
他なんかね、ちょっと変わった機能を紹介したいんですけど、
変わった機能ではないんですけど、
ハッピーアイボールっていうのをカールは実装してて、
今はブラウザーも実装してるんですけど、
具体的に言うと、IPv6とIPv4が両方使える環境で、
IPv6とIPv4を両方試して、先に成功した方を使うっていうのが
ハッピーアイボールっていう機能です。
ハッピーアイボールっていう機能が、
IPv6とIPv4を一気に通信して、
早い方を採用するっていう機能のことを
ハッピーアイボールズって言うんですね。
そうですね。
ハッピーアイボールズ、最近だとちょっと意味が広がってたりするんですけど、
もともとはIPv6とIPv4で、
IPv6を基本は使ってほしいので、
IPv6の方が少しだけ先にやるのが普通なんですけど、
もともとハッピーアイボールって名前は、
自分もあんま詳しくないんだけど、
アイボールっていうのがネットワークの世界で、
実際にサービスを利用する人のことで、
エンドユーザーのことを指す言葉らしいんですよね。
アイボールっていうのがユーザーってことですね。
そうですね。
なので、アイボールをハッピーにするための仕組み。
なので、IPv6を先試しつつ、
IPv4もほぼ同時にやるっていう。
なるほど。
実際にリクエストは2個走ってるってことなんですかね、
ハッピーアイボールズの。
リクエストするというか接続ですね。
接続して成功した方を使うって感じです。
なるほど。
リクエストまでいかないその手前の部分ですね。
そうですね。
実際これ役に立つことがあって、
実際自分最近あったんですけど、
IPv6とIPv4両方用意したんだけど、
設定ミスってて、
IPv6実は使えてなかったですと。
お、通信できなかったと。
通信できない。
だけど、IPv6とIPv4、
今のブラウザーもハッピーアイボールズ実装してるから、
両方試すんですよ。
で、IPv6は必ず毎回失敗すると。
だからIPv4必ず行くんですよ。
だから壊れてること誰も気づいてないっていう。
ちょっとダメじゃないですか。
ダメなんだけど、
けど実害は発生しないっていう。
確かに。
気づけないというダメさはあるが、
実害は発生してないってことですね。
そのためにハッピーアイボールってあって、
IPv6とIPv4両方やることで、
どっちか壊れてても行けるよねっていうのをやってるのが
ハッピーアイボールなんですよ。
確かにエンドユーザーにとってはハッピーですね。
壊れてないから。
絶対通信できるから。
で、カールはこのハッピーアイボールを実装しています。
ちなみに今ので気づく方法ってあるんですか?
IPv6失敗してるわけじゃないですか。
ハッピーアイボールを今のブラウザーもカールも実装しているので、
普通にやったら気づけなくて、
イント的にIPv6で通信、
自分で明智的にやらない限り、
多分気づけないです。
難しいですね。
サーバー側のログとかにも出てこないですかね。
どこ見ればって感じですよね。
サーバー側でIPv6用意したりとかしたら、
いくらでも気づくところはあると思いますけど、
クライアント側だとなかなか難しいですね。
気づきづらいところですね。
ChromeのDevToolsとか開いてても分からないってことですよね。
基本的には。
基本分からないですね。
繋がっちゃうから。
そう、繋がっちゃうから分からない。
クライアントにとっては、ユーザーにとってはいいですね。
いい機能ですね。
そうですね。この後ちょっと話す話に繋がってくるので、
この辺も話すと、
IPv6とIPv4ってDNSでまず解決しないといけないのが違っていて、
普通AレコードっていうのでIPv4のアドレス得ると思うんですけど、
IPv6はQuad AレコードっていうAが4つ並んでるやつ。
で、Quad AレコードでIPv6のアドレスを得るんですね。
なので、これやろうとするとDNSをまずAレコードとQuad Aレコード両方、
試さないといけないんですよ。
普通に考えたらそうですよね。
なので、カールだとケアーズって読むらしいんですけど、
ケアーズっていうのでDNSの名前解決を非同期に行うっていう機能があって、
これはコンパイルでオプションで指定しないと使えないんですけど、
このケアーズっていうのを使うと、
AレコードとQuad Aレコードっていうのを非同期でほぼ同時に実行してくれて、
この辺のハッピーアイボールが実装されていたりしますね。
逆にこのケアーズをオプションで有効にした状態でビルドしないと、
ハッピーアイボールズはカールでは利用できないってことですか?
いや、ハッピーアイボールは使えるんだけど、
そのDNSのAレコードとQuad Aレコードをカール内で非同期に、
ほぼ同時に解決するっていう挙動はないはず。
非同期じゃなくて同期的な解決がされてるってことですね。
になるんじゃないかな。
ちょっと有効にしなかった時の挙動はあんま詳しく知らないですが。
先に例えばAレコード解決して、
で、Quad Aレコード解決してみたいな感じになる。
なのでケアーズをビルドしておけば若干速くなるってことですね。
多分本当に速くなるかはちゃんとやらないと分かんないんですけど、
そういう機能があるよっていうところですね。ケアーズっていう。
で、今はハッピーアイボールの意味がちょっと、
ハッピーアイボールV3っていうのが出てきてて、
IPv4とV6だけじゃなくてもっと意味が広がっていて、
というのもHP2、HP3以外の時も話したと思うんですけど、
HP2とHP3をどっち先に使うかっていうのもあるじゃないですか。
なのでそのIPv4とV6だけじゃなくて、
HP2とHP3も両方とも試して、
速い方を採用みたいなことを実はやっていたりします。
すごい、そこさえも並列で解決しようとするんですね。
というのがハッピーアイボールV3っていうので、
最近だとできるようになってきています。
それはV3はChromeとかWacomとかも対応してるってことなんですかね。
ChromeとかあとFirefoxとかも対応してるんじゃないかな、
ハッピーアイボールV3。
これ結構最先端なので、
本当に対応してるか確認しないと分からない部分あるんですけど、
結構対応しようとしているはずですね。
もしかしたらオプションとかで設定有効にしないといけない機能かもしれないけどってことですね。
かもしれないんですけど、
FirefoxはハッピーアイボールV3のソースコードをGitHubに上がってたので、
多分使ってるんじゃないかなと思いつつ、
そのレベルの話ですね、この辺は。
本当に実験的というか最先端のところですね。
そうですね。
ちなみにV2は何かって知ってます?
知らないですね。
V2はなんかあるかもしれないけど。
分かんないですね。
なんかV3になってたって感じですね、
ハッピーアイボールが。
そうですね。
Alt-SvcとHTTPSレコードによるHTTP/3接続
なのでこの辺の話をもっとしていきたくて、
というのもHP2、HP3回の時にもいろいろ話をしたと思うので、
その辺の話をちょっとしていきたいんですけど、
HP2、HP3回の時に話したと思うんですけど、
HP3って最初から基本的にアクセスできないんですよね。
最初HP2で通信をした後に、
オルトSVCヘッダーっていうのでHP3使えますよって伝えて、
初めてHP3の接続を試すんですよ。
で、これがHTTPSレコードっていうのが最近DNSにあって、
それでHTTP3が使えるよってことを伝えてると、
最初にHP3を通信できるようになるっていう話を
HP2、HP3回の時にちょっと話したと思うんですけど、
なんで、その辺の話をちょっとこれからもっとしていくと、
実はオルトSVCヘッダー、まずブラウザーの挙動を話すと、
オルトSVCヘッダーでHP3使えますよって返すと、
ブラウザー側はHP3の通信を試すんですよね。
で、HP3の通信が成功したらその次からはHP3で通信するようになるっていうのが
今のブラウザーの挙動ですと。
けどこれカールでやろうとすると、カールってCLIで使ってると
毎回毎回1から起動するじゃないですか。
1コマンド、1起動って感じですよね、基本的には。
そうなるとこのオルトSVCヘッダーの仕様って使えなくないですか。
先に通信しとかないといけないからってことですかね。
HP2で通信成功して、ヘッダーレスポンスで
オルトSVCヘッダーでHP3使えるよって言われても
カール側はもう処理終了しちゃうから
いやそんな今更言われても困るよって話になるんですよ。
でもそれブラウザ側の挙動と一緒で
1回通信してで2回目通信しちゃえばいいんじゃないのかなって
なんとなく思っちゃうんですけど。
2回目通信する時にそのオルトSVCヘッダーの情報を渡す方法っていうのが
実はコンパイルオプションで有効にすればなんですけどあって
オルトSVCっていうオプションがあるんですよ。
でこれでファイル名を渡す。
ファイル名渡すとそのファイルの中に
このドメインオルトSVCヘッダー帰ってきてよみたいな
情報を保存してくれるんで
キャッシュしておけるんですね。
そうキャッシュしておけるんで
それオルトSVCのファイル作っとくと2回目以降からは
HP3の通信を試すっていう挙動をしてくれます。
なんか単純にカール側で2回リクエスト一気にしちゃえばいいじゃんと思っちゃったんですけど
そうではないんですね。
いやあのカールでだって
カールでURL書いたら1回リクエストするだけじゃないですか基本的に。
はい。
なのでその単純にカールでやってることは1回リクエストしただけなんですよ。
で初回のリクエストはHP2だから。
それだけだから。
で初回のリクエストはHP2やらないといけないから
そうなるんですよ。
なるほどカールの挙動としてもう1リクエストというのが決まってるので1リクエストでやるからこそこのオルトSVCの仕組みは使えない。
だからこそキャッシュファイルを間に置いといてそこのキャッシュファイルを読み込むことで2回目はHTTP3で通行できるようになると。
まあけど
仕様的な問題なんですねカール。
そうですねHP3の仕様なんで仕方ないんですけどただやっぱり最初から通信したいじゃないですか。
はい。
なのでさっきから言ってるHTTPSレコードに通信すればそれができるはず。
できるはずですねDNSでの解決時にこいつ大丈夫なんだっていうのがカール側が分かってればいいですよね。
そうなのでこれもカールコンパイル時にEnable HTTPS RRって書けばそのHTTPSリソースレコードが使えるカールが手に入るので
これをコンパイルすれば初回からHP3通信できるはず。
はい。
はずなんですよ。
めっちゃ便利。
って思うじゃないですか。
うん。
で僕もそう思ったんですよ。
はい。
でやってみたらなんかうまくいかないんですよね。
なんで?なんで?そのオプションはなんなのか。
そう自分もすごい混乱したんですよなんかうまくいかないなと思ってでなんか一瞬うまくいったことがあって今うまくいったと思ってもう一回やったらまたHP2になっちゃう。
バグじゃん。
そう何回かやったらたまにHP3が最初通信するんだけどその後やるとまたHP2になるっていう。
なんでですか?
そうこれ僕自分もねあのこれね1ヶ月以上かな悩みましたこれ実は。
はい。
でなんとわかったんですけど。
はい。
DNSキャッシュがHTTP/3検証を妨げた理由
あのAとQuad AレコードもHPSレコードもDNS問い合わせが必要なんで別に差はないはずなんですけどこれ最初の1回目はそうなんですけど2回目以降は話が違っていて
カールの実装としてAレコードとQuad AレコードってあのLibcにget address infoっていう関数があってこれを使って実装されていて
このget address infoってあのOSのDNSキャッシュを使ってるんですよ。
なので2回目以降はほぼ一瞬で返ってくるんですよ。
キャッシュを使ってるから。
そうOSもDNSキャッシュを使ってるから。
けどHPSレコードはあのカールの内部実装から直接DNS問い合わせをしているのでOSのDNSキャッシュは使えないんですよ。
なんか見えてきましたよ。
で最初に言っていた何でハッピーアイボールの話ちょっとしてたかっていうとこの辺の話をしたかったからなんですけど
ハッピーアイボールで要は競争させてるんですよ。
で最初に成功したやつ通信接してるからAレコードがQuad Aレコードが勝っちゃうんですよHTPSリソースレコードよりも。
キャッシュしてるからね。
OSのDNSキャッシュ分早いから必ずHP2になっちゃう。
必ずではないが大概の場合になってしまうんですね。
自分の手元だと必ずでしたね。
なのでMacのDNSキャッシュを削除するコマンドがあるからそれやったら100発100中でHP3に初回から通信するようになりました。
なるほどね。毎回キャッシュを削除しておけばいいっていう話。
なんか本末戦闘かなという気が若干しますが。
そうですねこれなんでブラウザーは発生しないかというとブラウザーはDNSキャッシュをブラウザー上で持ってるから大丈夫なんですよ。
でカールがそのAレコードとQuad Aレコードの解決をGet Address InfoっていうOS側のそのlibc側の機能を使ってるからこれが発生するんですよね。
だからここでカール側もキャッシュをOS側の機能ではないカール側で持ってたらブラウザーと同じだったってことですね。
そうですね。けどやっぱカールってそのデーモンで立ち上がってるわけじゃないからそういうのは現実的じゃないっていうところですね。
一軌道一軌道なのでそこまでって感じですよね。
そうですね結構これ深刻な問題でやっぱAレコードとかQuad Aレコードって昔からずっと使われている機能だからそのlibc側に関数があるしなんかいろんなDNSキャッシュとかいろんな仕組みがあるんですよ。
けどHPSレコードって新しい仕組みだから基本的にこういうのないんですよね。
だから基本的に競争させたら不利だっていうのがここからわかるんですよ。
OS側がHTTPSレコードの方を対応していないからこそこういう差分が発生してしまうんですね。
そうOS側に支援機能みたいなのないから。
そうなのでこれはね自分本当にすごい悩んだんですけどなんでうまくいかないのかずっと悩んだ結果ここにたどり着きました。
なんか全体的にあれですねカールの使用上CLIから起動する都合上こうなってしまいがちというか色々制約ありそうですねカールの。
ブラウザーと比較すると全然違うというかブラウザーと同じことをカールでやろうとするとここに差があるのかみたいな。
正直自分まさかDNSキャッシュがここで出てくると思ってなかったんで。
DNSキャッシュをブラウザー側独自でやってるからこの問題は起こらないけどカールだとこの問題が起こるよねとか。
なんかそういうかカール自分はただ単にカールで挙動試したいだけなんだけどカールでやってると結構色々なことを知らないと理解できないみたいなのが結構発生してます。
すごい端的に言うとカールとブラウザー違うよねっていうところだと思うんですけど。
そうそうそういうこと。
でもなんとなく同じことやってるじゃないですかカールとブラウザーって確認したいこと一緒だししかも。
同じです。
本当に細かいところマジで違いますね。
そうねやっぱりこういう変なことというかエッチなことやってるからあんまり情報もなくてだから結構悩むんだよねこういうことやってると。
あれなんでこうなるんだろうみたいな。
でも紐解いていけば確かに納得だよなっていうところには落ち着きますね。
理解すると確かにそうなるね。
しかもそれが結構実装の本質的な部分だったりするから勉強にはなるんだけど自分結構本当に1ヶ月ぐらいから悩んでるんでこれで。
なんで本当に最初わからなかったです。
実装の部分だし仕様の部分でしょうがない部分で丸しみたいなところ結構絡み合ってるなと思う一方。
これ今あれですかでもこの1ヶ月ってのは1ヶ月悩んでたのは結構最近ってことですか?
でもちょっと前ですかね。
AI使って結構難しそうだなっていうここら辺の解決するの。
それで言うと当時そんな頭良くなかったんですけどAIにいろいろ相談してやっとわかりましたねこれは。
自分一人だとたどり着けなくてAIにいろいろ言ってったらこれはDNSキャッシュじゃないかって言われてやってみたらあ、いけたってなりました。
そうじゃんみたいな。
そうじゃんみたいになりました。なんでこれを解決してくれたのがAIですね。
AIはあれなんですかねソースコードを見てわかったとかそういう感じなんですかねどこを見て判断したのか。
どこを見て判断したのか自分もわからなかったし当時ブログとかもなくてあの今は確かいくつかこの手のブログ出てたと思うんですけど当時はなかったと思いますね。
なんでDNSキャッシュにたどり着いたんだろうなって。
それは謎です。
最近はいくつか英語のブログもなんか出てたの見ましたね。直接的じゃなかったけど。
まあまあでもなんかそういうあのヒントがあるんだったらまだわかるけどもなんかヒントがない状態でDNSキャッシュにたどり着くその調査力どうやったんだってことですね。
そうですねそれはマジでわからなかったですね。
気になるところでありますけどちょっと超越してきてる感じがしますけどAIさんが。
まあそうですね。自分はずっとわかんなかったけどAIにいろいろ相談していったらわかりました。
深掘っていったらわかったってところですね。
そうですね。
DNSキャッシュが原因だったというか。
まあ多分あのいろんな仮説がある中でこれじゃねこれじゃねっていうので試してみたらDNSキャッシュクリアしてみたら通ったみたいなところだかなとは思うので。
かなり深い問題だなというところですけどなんか他あったりします?
libcurlのタイムアウト設計
あとですねちょっと話変わるんですがタイムアウト周りでちょっとね挙動が意外と知られてなかったりもするので少し話したいんですけど。
変わってタイムアウトが大きく2つあってコネクトタイムアウトとマックスタイムの2つありますと。
でコネクトタイムアウトっていうのが接続フェーズ全体をいつやめる諦めるかってやつでマックスタイムが通信全体をいつ諦めるかってやつなんですよ。
なんかあの今聞いた限りどっちがどう違うのかみたいなところなんですけどもうちょっと詳しくいいですかねコネクトタイムアウトが。
コネクトタイムアウトが例えば最初の接続フェーズってまずDNS確認しますその後にTCPコネクションがありますその後にTLSハンドシェイクがありますっていう風になるじゃないですか。
それが全部終わったら通信が実際開始できるじゃないですか。
サーバーとの通信が開始できると。
その開始するまでのタイムアウトって実はデフォルトだと無限大になってて。
だからその最初の実際に通信が始まる前の通信でなんか変なことが起こったりするとカールってタイムアウトしなかったりするんですよ。
なるほどまあ具体的には何かハンドシェイク中に何か無限ループに入ったとかもし何かそういうことが発生してたらタイムアウトはしないと。
そうですねこれ一応あれか300秒とかなのか。
ハードルに似てはあるですね。
ただまあめっちゃ長いんでウェブアプリケーションとかだと300秒ってめちゃくちゃ長いから。
長い。
でこれのせいであのウェブアプリケーション上でリブカールでカール使ってることってあると思うんですけど
このコネクトタイムアウトの設定忘れてるとなんかAPIがちょっと障害になったとかって時に
その失敗リクエスト失敗したやつがずっと溜まっちゃってそれでまた障害になっちゃうとかが起こり得るんだよね。
なるほど通信が溜まるあのそもそもコネクトできない時の溜まりの原因がこのコネクトタイムアウトの場合があるってことですね。
なのでタイムアウトを指定してもここのコネクトタイムアウトの指定を忘れてるケースって結構ある。
っていうのがコネクトタイムアウトでMAXタイムっていうのは。
MAXタイムが全体のタイムアウトですね。
この全体というのはコネクトの部分も含まれる。
接続フェーズ全体のはずですね。
なのでなんかその辺がちゃんとしてタイムアウト2つリブカールだと設定あるので両方ともちゃんと指定しているのかっていうのがかなり大事だったりします。
これはさっきからCLIの話してたんですけどこれはリブカールとしてそのアプリケーション側に組み込んだ時の話になりますね。
カールのコマンドラインとして使う場合じゃなくてライブラリとして読み込んでアプリケーション側から通信する場合のことですね。
そうですね。CLIだと最悪なんか変だったらCtrl-Cとかすればいいと思うんですけど。
やっぱりアプリケーションを組み込んじゃうとAPIが障害になった時にガッてたくさんこういう変なコネクションが発生しちゃってそれで死んじゃうとかって全然あるので。
あり得る。
なのでその辺は結構気をつけないといけないし、
実際あの例えばPHPってリブカール使えるんですけどその今言ったやつがカールオプトタイムアウトとカールオプトコネクトタイムアウトって両方とも両方の定数があるのでこれを両方ともちゃんと指定しないといけないですよ。
なのでこの辺の知識がないと結構障害になったりとかしますね。
ただリブカールを直接アプリケーション側から使うタイミングというかそういう状態がどこまであるのかってことですよね。
それもね結構勘違いされてる人多いんですけど、例えばPHPだとよく使われるのはGazlってやつよく使われるんですけど、
Gazlも内部的にリブカール使ってるんですよ。
だからGazlでもコネクトタイムアウトとタイムアウトって2つの指定があったりして。
なるほどAPIが統括されてるんですね。
なのでGazlだったら大丈夫かっていうとGazlもリブカール内部で使ってるから両方のタイムアウトちゃんと指定しないとダメですよっていう感じになる。
なるほどそこら辺がリブカール使って間接的に使ってるからこそここの指定っていうのが明示的にする。
もしくはライブラリー側でいい感じにやってくれてる場合もライブラリーによってはあるっていう。
あるかもしれないけどマスカットのGazlに関してはリブカールにそのまま足してるだけだね。
なるほど。
でなんかリブカールっていうかそのPHPのリブカールってなんか面白くて、面白いっていうかあのCのリブカールの関数をそのまま呼び出してるだけなんですよ。
そのまま統括的にやってるんですね。
PHPでリブカール使っちゃうともうC言語でリブカール呼んでる時とコードほぼ一緒になっちゃうんだよね。
ちょっとあの前の回でPHPはCであるという回をやったと思うんですけどそれと一緒ですね。
それと一緒でPHPのコードなのかCのコードなのかよくわかんないコードを書かざるを得ないリブカールを使うと。
なるほど。
みたいな感じになるのでこの辺はリブカール使うんだったら結構そうなりますっていう感じですね。
ちょっと根深い問題ですねPHPを使ってる場合はちょっと問題になりそうですね。
なのでその辺リブカール使うときはこの辺のタイムアウトの仕様も把握しておいてほしいなというところですかね。
ちなみにリブカールの話が出てきたんでここで聞きたいなと思うんですけど、
カール自身はリブカールを内部で使ってるってことですかね。
使ってますね。
じゃあカール自体もリブカールをライブラリとして使っているクライアントの一部ってことですね。
そうですね。
じゃあほぼほぼ一緒ってことですね。
基本は一緒だし結構対応してこのオプションに対応したのがこれですみたいな感じになっているので。
わかりやすくはありますね。カール使ってるのとリブカール使うのっていうのは。
そうですね。
なので両方ともやっぱりWeb系にいたらカールとリブカールと無縁では入れられないと思うので、
この辺の知識もあったら役に立つと思いますね。
では他にあったりしますか。
リブカールはこのタイムアウトのやつ気をつけてねっていうところが一番大きいですかね。
そんな感じかな。
結構めんどくさい話たくさんしたと思うんですけど。
カールの話もう1時間ぐらい経ってるんで結構カール単体でもおそらくまだまだ全然話足りないところはあるのかなとは思いつつも。
カール1つでもこんだけ話せるんで。
まあまあいろいろありますね。
今回ちょっとカールといっても今回話せてないところもいろいろありますよね。
カールは本当にいろいろ機能あるんで本当に一部自分がよくハマったところとかそういうところに絞って話した感じですね今回は。
リブカールの話も若干最後出てきましたけどそのリブカールの話になってくるともっといろんなところ出てくるかなという気は若干しますけど今の話だったらPHPだけの話だったので他の言語の話だったりとかね。
他の言語でもやっぱ語とかは違うんですけどCでやっぱりほとんどの言語書かれてるんでリブカール結構使える言語多いんですよ。
なので今言った注意点って他の言語でもある注意点にはなりますね。
語の場合はリブカール使ってないんですね。
ここは独自実装してるってことですね。
語は全部ライブラリーは語で実装されているのでこの辺は独自ですね。
リブカールは関係ないっていう。
そうですねただ語のHPクリエイントもデフォルトだとタイムアウトは無限大になってたりとかするのでこの辺は語でも要注意な設定ではあります。
考え方としては一緒ってことですね。
そうですね。
はいありがとうございます。
じゃあいい時間になってきたのでここまでにしたいなと思うんですけど。
ということで今回はここまでにしたいなと思います。
エアロイズのOSSでは毎回一つのOSSを取り上げてそれについて片付いていないということで技術的なところも深掘りしながら話をしていく番組になっています。
今後もその通りですね。
今回みたいな巨大な昔からあるようなカールみたいなコマンドだったりとか他にもOSS取り上げていけたらなと思ってますので
ぜひお聞きのプラットフォームでフォローや高評価の方お願いします。
またこのOSSについても深掘って見てほしいみたいなのがあったらコメントなどいただけると非常に嬉しいです。
番組についての感想もお待ちしております。
Xなどでつぶやく際にはハッシュタグヤオヨロズのOSSをつけてくださると発見しやすくなるのでよろしくお願いします。
それでは今回もありがとうございました。
ありがとうございました。