GoでWebサーバ計画再始動 [プログラミング]
GoでHTTP/2サーバを実装しようとしたらプロトコル実装が既にあったので、車輪の再発明はバカっぽいなぁと思ってやめていた。HTTP/3もできるって話なのでやろうかなと思っていたけど、どうせほかの人に先を越されるのでやめて実際のWebサーバを作ろうかと思ったりした。
よくスクリプト言語とかで、Webサーバをフロントエンドとして、バックロジックを書くみたいなことをやっている事が多いと思う。RubyだとWebrickとかがあったが、基本的に既存のWebサーバをかまして運用したほうがいいって話になってたりするので、パフォーマンスなどの面でWebサーバ自体はスクリプト言語で動かさないほうがいいのでしょう。
んで、Go言語でWebサーバを作ろうとすると、パフォーマンスなんかはLL言語よりかは良いのだろう。Webサーバ部分を軽く作って、Webアプリのロジック部分を軽く分離して、同じくGo言語で組み入れてしまうというアプローチはどうだろう。基本的にWebサーバとして使う部分は作っておいて、あとは自分で組み入れてしまうという考えは、コンパイル言語のWebサーバとしてはあまりない気はする。基本CGIみたいな外付けプロセスを、LL言語のWebサーバみたいに言語内に組み入れてしまう、というのはどうだろう。
本来ならコンパイルされたプロセスにお伺いして動かすのが一般的なんだろうけど、それをWebサーバとして一つに固めてしまう。プログラムの粒度も結合度も高すぎると言われそうだが、Linuxだってモノリシックで台頭できたではないか。ハードウェアとしても単一CPUなどよりもSoCの世界が普通になってきているし。結局、プログラマの意識なんだと思うんだよね。確かに細かめに機能分けしてモジュール分けするのは良いのかもしれないけど、最終的には全体が一つになって動くんだし。
そんなわけでGolangをMacBook Airに入れて設定してみたい。Goの設定って久しぶりだな。まとめておさらいしておこう。
GOPATHの設定は最近（でもないか）変わったっぽい。なんかユーザーフォルダに決め打ちでがっつり作るのか？
https://golang.org/doc/code.html#GOPATH
新しいMacBook Airには、~/.bash_profile も~/.bashrcもないので作らないといけない。
これを書くようになった。
該当のディレクトリは事前に作成しなくて良いのかな？
とりあえずgo getしてみようと思う。
一番最近作ったソースがgoqueryを使っていたので入れてみた。
あ、勝手に-/go ディレクトリ作られた。というか、ユーザーディレクトリにドットで隠しもしないディレクトリ作ってとか横柄すぎないか？ まぁそれだけの忠誠心を試されるということか…。
再始動ということで、前のマシンのソースをさらってみたが大したソースは出てこない。このブログを見てみたら、やっぱりそこそこしかやっていない。まぁ当然か。
HTTP/2.0はTLSを使うのでそこから [2015/08/15 05:32]
Goで簡易Webサーバ４ [2015/08/14 09:17]
何かTLSと一緒にHTTP/2をやろうとしているので、あまり意味がよくわからなくなっている。現在の状況でできることを再度検証してみる。
まずはHTTP/2の前に、普通のHTTP 1.1でSSLというかTLSを使うときはどうなのか、というところから行くべきだろう。幸い今はlet's encryptというタダのSSL証明書があるので、検証はお金をかけずにできるようになった。
2016年の終わり頃にサンプルがあってググっても一番にそれが出てくる。
https://github.com/denji/golang-tls
三つのサーバの実装があるみたい。一つはクライアントだから三つだと思うが、クライアントはTLS対応のツールとかないっけ？ curlはTLS対応してるよな。下のようにできるっぽいから一般的なクライアントでやりたい場合は、Webブラウザかcurlでやったほうが一般的だろう。
https://qiita.com/Esfahan/items/53399964cb76cdb87e60
基本的に標準ライブラリで対応できてそう。
"crypto/tls"
"net/http"
あたりでインプリできて、その他の外部ライブラリを使っていないようなので、今後の潰しも利く。とりあえずできるのかどうかをLet's Encryptを絡めて実際にやってみたいと思う。HTTP/2はあるのかもしれないけど、後で見てみることにする。
よくスクリプト言語とかで、Webサーバをフロントエンドとして、バックロジックを書くみたいなことをやっている事が多いと思う。RubyだとWebrickとかがあったが、基本的に既存のWebサーバをかまして運用したほうがいいって話になってたりするので、パフォーマンスなどの面でWebサーバ自体はスクリプト言語で動かさないほうがいいのでしょう。
んで、Go言語でWebサーバを作ろうとすると、パフォーマンスなんかはLL言語よりかは良いのだろう。Webサーバ部分を軽く作って、Webアプリのロジック部分を軽く分離して、同じくGo言語で組み入れてしまうというアプローチはどうだろう。基本的にWebサーバとして使う部分は作っておいて、あとは自分で組み入れてしまうという考えは、コンパイル言語のWebサーバとしてはあまりない気はする。基本CGIみたいな外付けプロセスを、LL言語のWebサーバみたいに言語内に組み入れてしまう、というのはどうだろう。
本来ならコンパイルされたプロセスにお伺いして動かすのが一般的なんだろうけど、それをWebサーバとして一つに固めてしまう。プログラムの粒度も結合度も高すぎると言われそうだが、Linuxだってモノリシックで台頭できたではないか。ハードウェアとしても単一CPUなどよりもSoCの世界が普通になってきているし。結局、プログラマの意識なんだと思うんだよね。確かに細かめに機能分けしてモジュール分けするのは良いのかもしれないけど、最終的には全体が一つになって動くんだし。
そんなわけでGolangをMacBook Airに入れて設定してみたい。Goの設定って久しぶりだな。まとめておさらいしておこう。
brew install golang
GOPATHの設定は最近（でもないか）変わったっぽい。なんかユーザーフォルダに決め打ちでがっつり作るのか？
https://golang.org/doc/code.html#GOPATH
新しいMacBook Airには、~/.bash_profile も~/.bashrcもないので作らないといけない。
touch ~/.bash_profile
これを書くようになった。
export GOPATH=$(go env GOPATH)
該当のディレクトリは事前に作成しなくて良いのかな？
とりあえずgo getしてみようと思う。
go get github.com/PuerkitoBio/goquery
一番最近作ったソースがgoqueryを使っていたので入れてみた。
あ、勝手に-/go ディレクトリ作られた。というか、ユーザーディレクトリにドットで隠しもしないディレクトリ作ってとか横柄すぎないか？ まぁそれだけの忠誠心を試されるということか…。
再始動ということで、前のマシンのソースをさらってみたが大したソースは出てこない。このブログを見てみたら、やっぱりそこそこしかやっていない。まぁ当然か。
HTTP/2.0はTLSを使うのでそこから [2015/08/15 05:32]
Goで簡易Webサーバ４ [2015/08/14 09:17]
HTTP/1.1からのHTTP/2.0 [2015/08/13 07:37]
Goで簡易Webサーバ３ [2015/07/16 08:02]
Goで簡易Webサーバ２ [2015/07/13 06:49]
Goで簡易Webサーバ１ [2015/07/12 09:46]
Goで簡単なWebサーバを作ってみようか画策中。 [2015/07/08 12:46]
何かTLSと一緒にHTTP/2をやろうとしているので、あまり意味がよくわからなくなっている。現在の状況でできることを再度検証してみる。
まずはHTTP/2の前に、普通のHTTP 1.1でSSLというかTLSを使うときはどうなのか、というところから行くべきだろう。幸い今はlet's encryptというタダのSSL証明書があるので、検証はお金をかけずにできるようになった。
2016年の終わり頃にサンプルがあってググっても一番にそれが出てくる。
https://github.com/denji/golang-tls
三つのサーバの実装があるみたい。一つはクライアントだから三つだと思うが、クライアントはTLS対応のツールとかないっけ？ curlはTLS対応してるよな。下のようにできるっぽいから一般的なクライアントでやりたい場合は、Webブラウザかcurlでやったほうが一般的だろう。
https://qiita.com/Esfahan/items/53399964cb76cdb87e60
基本的に標準ライブラリで対応できてそう。
"crypto/tls"
"net/http"
あたりでインプリできて、その他の外部ライブラリを使っていないようなので、今後の潰しも利く。とりあえずできるのかどうかをLet's Encryptを絡めて実際にやってみたいと思う。HTTP/2はあるのかもしれないけど、後で見てみることにする。
タグ：Golang
続編はこちら。
https://miff.blog.so-net.ne.jp/2018-12-14-2
by miff (2018-12-18 05:30)