この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
エンジニアをやっていると色々なモノの気持ちにならないといけない。バイナリツリーの気持ちになったり、CPUの気持ちになったり、メモリの気持ちになったり……。あ、書いたコードが低レイヤーでどんな挙動をするのか考えるっていう意味だよ。
普段使っているHTTPサーバの気持ちはどうだろう？ 実際に書いて見ればわかるんじゃないかな。というわけで書いてみよう、Rubyで。
いきなりコーディング
HTTP通信の基本は知ってるよね。クライアントはTCPで80番ポートに接続してリクエストを投げ、サーバからレスポンスを受ける。いわゆるリクエスト-レスポンス型プロトコルだ。
だからまずはTCPで80番ポートをlistenしてブラウザにリクエストを送ってみてもらおう。
require 'socket'
module ReWheel
class Server
def initialize
@tcp_server = TCPServer.new 80
end
def listen
loop do
client = @tcp_server.accept
request = Array.new
while request_line = client.gets
break if request_line.chomp.empty?
request << request_line.chomp
end
puts request.join("\n")
client.close
end
end
end
end
ReWheel::Server.new.listen
sudo ruby server.rb
ここでsudoをつけて実行することに注意。実はsudoを外すとエラーが発生して動かない。理由はHTTPの80番など1023以下のポート番号はLinux上で特権ポートとされているため。プロセスがこれらのポート番号をバインド(束縛)するにはroot権限で実行されている必要がある。
バインドというのは、あるポート番号をあるプロセスが占有するということだ。つまり、既にあるプロセスがバインドしているポート番号は、送られて来る通信を他のプロセスが受け取ることは出来ない。もしも、既にプロセスがバインドされている番号を新たに起動するプロセスが利用しようとすればエラーが発生する。試してみたければ上のスクリプトを二重起動すればいい。
（ ˘⊖˘）。o(待てよ、受け取った通信を他のポートにもコピペで渡すアプリケーションを作れば一つのポートを実質的に複数プロセスで共有出来るのでは？)
と思った初心者はかしこい。それはnginxなどが持つリバースプロキシと呼ばれる機能の考え方だ。この機能があるからWebサーバは負荷分散や機能分担のために80/443ポートで受け取ったリクエストを他のポート番号でlistenしている同一マシン内のunicornやpumaに処理させたり出来るってワケ。
ま、とにかくこのコードを実際に使ってみよう。
ブラウザから来るリクエスト
では、サーバを起動した状態でブラウザからアクセスしてみよう。標準出力にこんな表示が出来て来るはずだ。
GET / HTTP/1.1
Host: 203.XXX.XXX.XXX
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.8,en;q=0.6
改めて考えるとちょっと不思議だが問答無用でHTTP/1.1のリクエストが送られて来る。サーバがどんなプロトコルに対応しているかは不明な時点で決め打ちされてくるワケだ。
では例えばHTTP/2.0の通信はどうするかというと、最初のリクエスト自体はHTTP/1.1で送られ、ヘッダ内にHTTP/2.0に対応可能である旨が記述される。そして、サーバ側もHTTP/2.0で対応可能であった場合はプロトコルが変更されてHTTP/2.0の通信が始まるというワケ。
次は送られてきたこのリクエスト文について読み解いて行こう。
[構成]
HTTPの規格については当然、というより言うまでもなくRFCのドキュメントを読むのが最も正しい。RFCではリクエストやレスポンスの構文はABNFで定義されている。この前書いた記事「作ろう、ミニ言語」でBNFが登場したがその拡張版にあたる言語がABNFだ。BNFみたいに自己参照しなくても繰り返しが表現出来たり色々と便利。
(作ろう、ミニ言語 https://doruby.jp/users/yam/entries/mini_lang)
HTTP-message
= start-line
*( header-field CRLF ) CRLF
[ message-body ]
(出典:RFC 7230 の総集的 ABNF
https://triple-underscore.github.io/RFC723X-ABNF-ja.html)
うん、日本語にしよう。
１行目 開始行
２〜N行 ヘッダー
N+１行目 区切りのための空白行
N+２行目 メッセージ本文(オプション)
この形式はリクエストもレスポンスも共通であり、どちらも最低限に必要なのは１行目の開始行だけだ。まずは開始行の構文について説明しよう。前述したリクエストのサンプルで例えるとこうだ。
GET / HTTP/1.1
{メソッド} {URI} {プロトコル}
区切りは半角スペース。難しいことはなし。ヘッダについても項目がたくさんあるというだけで構文は難しくない。
Accept-Encoding: gzip, deflate
{パラメータ名}: {値}
じゃ次はサーバ側でレスポンスをしてみよう。レスポンスの場合はリクエストと開始行の構文が違う。先にABNFの方で見てみよう。
status-line
= HTTP-version SP status-code SP reason-phrase CRLF
SPは半角スペース、つまり”{HTTPバージョン} {ステータスコード} {理由句} 改行コード”という形式になる。ちょっと当てはめてみよう、このサーバはごく単純にHTTP 0.9で実装しておくとして、正常にGetできるのでコードは200、理由句はOKだ。
HTTP/0.9 200 OK
OK！ ところで書いていて疑問に想ったことが一つ。ステータスコードはどういうステータスなのかが定義されている。では、わざわざ理由を書かないといけない理由はなんだ？ もしかして自由に書いてもいいのか？
RFCのABNFを読んでみるとreason-phrase = *( HTAB / SP / VCHAR / obs-text )、obs-text = %x80-FF、としか書かれていない。つまり省略してもいいし何を書いてもいい。普段、我々が目にするあのNot Foundといったフレーズはあくまでも推奨される1案らしい。どころかクライアントソフトでは無視することが推奨されている(RFC 7230)とのこと。ふーん…。
(HTTP responseのstatus-line、reason-phraseの内容にどこまでこだわるか？:
http://blog.magnolia.tech/entry/2017/10/09/224148)
返事をしてみる
じゃあさっきのサーバスクリプトにレスポンスを返すように書き加えてみよう。
def listen
loop do
client = @tcp_server.accept
request = Array.new
while request_line = client.gets
break if request_line.chomp.empty?
request << request_line.chomp
end
puts request.join("\n")
response_root(client)
client.close
end
end
def response_root(client)
client.puts <<-EOS
HTTP/0.9 200 OK
Content-Type: text/html
Hello, <b>neko</b>.
EOS
end
サーバを起動し直してブラウザで接続。猫に会えたかな。基本はこれだけだ。しかしGoogleChromeで接続するとプロトコルはH1.0扱いされるな…0.9は対応外なのか、あるいは足して２で割られているのかは不明。
さて、今までのところは全くリクエストの内容を解釈していない。リクエストもレスポンスも好き勝手に投げているだけだ。ドッジボール・プロトコル…。次はキャッチボールをしよう。要求されたURLに応じて異なるコンテンツを返す。Railsなんかのルーティングに相当する処理だ。
その前にリクエストをパースする必要があり、ABNFが定義されているしミニ言語のようにちゃんとlex&parseしても良いわけだけれど…今日はそこまでやる気がない。String#stripで乗り切る。
require 'socket'
module ReWheel
class Server
def initialize
@tcp_server = TCPServer.new 80
end
def listen
loop do
client = @tcp_server.accept
raw_request = Array.new
while request_line = client.gets
break if request_line.chomp.empty?
raw_request << request_line.chomp
end
request = Request.create_from_raw_text raw_request.join("\n")
response = route_and_response(request)
client.puts response.to_text
client.close
end
end
def route_and_response(response)
case response.url
when '/'
Response.new.tap do |res|
res.code = '200'
res.body = 'Im root.'
end
when '/neko'
Response.new.tap do |res|
res.code = '200'
res.body = 'Im a neko.'
end
when '/coffee'
Response.new.tap do |res|
res.code = '418'
res.body = 'Im a tea-pot.'
end
else
Response.new.tap do |res|
res.code = '404'
res.body = 'Not Found'
end
end
end
end
class Request # ヘッダは面倒なので省略
attr_accessor :method, :protocol, :url
def self.create_from_raw_text(text)
request_line = text.split("\n").map(&:chomp)
start_line = request_line[0]
self.new.tap { |req| req.method, req.url, req.protocol = start_line.split(' ') }
end
end
class Response # reason-phraseは不要らしいので省略
attr_accessor :protocol, :code, :body
def initialize
@protocol = 'HTTP/1.0'
end
def to_text
start_line = [@protocol, @code].join(' ')
[start_line, '', @body].join("\n")
end
end
end
ReWheel::Server.new.listen
書けた、第三部完。せっかくステータス・コードが選べるのでtea potも実装しておいた。厳密に言えばHTTPプロトコルではない(下記リンク参照)けど、遊びのスクリプトで書かなかったらどこで書いていいのかわからないよ。
(https://tools.ietf.org/html/rfc2324)
発展の話
というわけで基本的なことが出来るようになった。これをHTTP/2.0対応にしたり、あるいは自分だけのHTTPプロトコルを設計したり、unixドメインソケットでRackアプリに接続してみたり色々と試してみよう。
connpass
Peatix
Wantedly
デザインチームnote