Rails5中引入的可以實現實時通訊的新功能，ActionCable，可以說是這個版本的Rails的重大特性之一，ActionCable底層究竟是如何進行通訊，本文就來聊一聊這些相關的技術。
WebSocket
簡單的說，websocket是一個基于TCP的應用層協議，使用http協議建立連接，并且能夠通過一個已經建立的連接，進行雙向的通訊，也就是不僅僅能夠從客戶端發送信息到服務器端，服務端還可以推送信息到客戶端, 而且這一切的是建立在一個連接中進行的，有了它我們就不需要再使用，polling或long polling做輪詢信息了。
它的通訊過程是，通過向http頭添加特定信息，然后發送到服務器，如果服務器能夠支持websocket的話，就會識別出http頭中關于websocket的信息，并且升級http連接為websocket連接并返回，一個同樣包含websocket頭信息的http response，這樣下來，客戶端和服務器的連接就已經建立了，直到一方關閉連接。
請求：
GET /cable HTTP/1.1
Host: example.com:3000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
應答：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
上面的請求和應答頭中 upgrade: websocket代表著這是一個websocket的連接請求，Sec-WebSocket-Key 和 Sec-WebSocket-Accept，是用于確認服務器是否真的，能夠出來websocket請求的驗證方式，過程是，服務器端介紹到websocket-key后，通過組合magic string，之后再進行SHA-1和 base64編碼，然后以Sec-WebSocket-Accept返回給客戶端，客戶端接受到后驗證正確，這就表明服務器真正的可以處理websocket請求了。
如何使用Websocket
ActionCable本身可以作為一個單獨的服務，綁定到單獨的端口上運行，也可以與rails一起在同一個端口上一起啟動運行，這是因為它實際上是一個處理websocket的rack app。
單獨啟動的ActionCable Server，先加載Rails環境，然后再運行的rack app。
# cable/config.ru
require ::File.expand_path('../../config/environment', __FILE__)
Rails.application.eager_load!
run ActionCable.server
與Rails一同啟動的時候，是通過掛載ActionCable.server到指定的PATH上。
# actioncable/lib/action_cable/engine.rb
initializer "action_cable.routes" do
config.after_initialize do |app|
config = app.config
unless config.action_cable.mount_path.nil?
app.routes.prepend do
mount ActionCable.server => config.action_cable.mount_path, internal: true
end
end
end
end
不管是，單獨端口啟動的ActionCable，或是與Rails一同啟動的。它們實際都是用rack up作為統一入口的。
# actioncable/lib/action_cable/connection/base.rb
# Called by Rack to setup the server.
def call(env)
setup_heartbeat_timer
config.connection_class.call.new(self, env).process
end
call方法中第一是，每個三秒發送一個心跳包到客戶端，已確定連接是否還可用，第二行就是初始化action-cable自己的連接類，執行響應。
# actioncable/lib/action_cable/connection/base.rb
def process #:nodoc:
logger.info started_request_message
if websocket.possible? && allow_request_origin?
respond_to_successful_request
else
respond_to_invalid_request
end
end
首先輸出日志表示請求已經接受，然后判斷請求是否為websocket，并且判斷HTTP_ORIGIN是否允許。
# actioncable/lib/action_cable/connection/base.rb
def respond_to_successful_request
logger.info successful_request_message # 輸出日志：成功升級連接為 Websocket
websocket.rack_response # 調用 websocket對象，返回websocket響應。
end
走到這一步，服務器端的連接已經確認是可以繼續websocket通訊了，但是與客戶端的握手還沒有完成，還需要發送一個，驗證服務器端接受并有能力處理websocket的信息給客戶端。
可以從下面看出來，action-cable使用了Websocket-driver 這個Gem來完成websocket的通訊工作。
# actioncable/lib/action_cable/connection/web_socket.rb
require 'websocket/driver'
module ActionCable
module Connection
# Wrap the real socket to minimize the externally-presented API
class WebSocket
def initialize(env, event_target, event_loop, client_socket_class, protocols: ActionCable::INTERNAL[:protocols])
@websocket = ::WebSocket::Driver.websocket?(env) ? client_socket_class.new(env, event_target, event_loop, protocols) : nil
end
def possible?
websocket
end
def alive?
websocket && websocket.alive?
end
def transmit(data)
websocket.transmit data
end
def close
websocket.close
end
def protocol
websocket.protocol
end
def rack_response
websocket.rack_response
end
protected
attr_reader :websocket
end
end
end
# actioncable/lib/action_cable/connection/client_socket.rb
module ActionCable
module Connection
class ClientSocket
def initialize(env, event_target, event_loop, protocols)
············
@driver = ::WebSocket::Driver.rack(self, protocols: protocols)
@driver.on(:open) { |e| open }
@driver.on(:message) { |e| receive_message(e.data) }
@driver.on(:close) { |e| begin_close(e.reason, e.code) }
@driver.on(:error) { |e| emit_error(e.message) }
············
end
end
end
end
那么接下來就不得不講一講，websocket-driver 這個Gem了。
websocket-driver
簡單的說，websocket-driver是一個利用，EventMachine，來讀寫socket-io對象的驅動器。使用了它的API就可以很輕松的實現websocket-server。
websocket-driver提供了一個基于rack的接口，action-cable就是使用這個接口進行通訊的。下面的代碼通過一個socket代理對象，初始化一個driver，然后再向客戶端發送一段信息。這里最重要的地方就是，被傳入的socket代理對象，它必須能夠響應三個方法，env，url，和write，分別是告訴driver 向哪個URL，如何發送信息。這里的 env 返回的就是rack app的env變量，webscoket-driver實際上就是利用Rack hijacking API 來實現獲取socket-io對象進行讀寫的，所以action-cable基于websocket-driver就代表著像webrick這類不支持full hijacking API的應用程序服務器，也不能支持action-cable。
driver = WebSocket::Driver.rack(socket, options)
driver.text "I'm websocket server"
使用rack hijacking API
require 'websocket/driver'
require 'eventmachine'
class WS
attr_reader :env, :url
def initialize(env)
@env = env
secure = Rack::Request.new(env).ssl?
scheme = secure ? 'wss:' : 'ws:'
@url = scheme + '//' + env['HTTP_HOST'] + env['REQUEST_URI']
@driver = WebSocket::Driver.rack(self)
env['rack.hijack'].call
@io = env['rack.hijack_io']
EM.attach(@io, Reader) { |conn| conn.driver = @driver }
@driver.start
end
def write(string)
@io.write(string)
end
module Reader
attr_writer :driver
def receive_data(string)
@driver.parse(string)
end
end
end
Rack hijacking API
Rack hijacking API 是在Rack 1.5 中引入的，hijack即為劫持，聽起來好想是挺危險的樣子，不過其實只是名字而已，它實際上是通過支持Rack的應用程序服務器上，攔截下client端的請求和server的相應的
Rack的hijacking API 提供了兩種模式：
- 全部劫持(full hijacking)，在這個模式下應用對socket傳輸的數據有絕對的控制權，也就是應用程序服務器，將對socket的控制權移交給你應用程序本身去處理，通過這個特性我們就可以實現任意應用層協議的傳輸，比如websocket協議。當然這些也是有一個大前提的，就是如果你的應用程序服務器(puma) 前端有反向代理(nginx) 或者 負載均衡器的話，應用程序只能通過socket傳輸它們兩個支持的協議。
- 部分劫持(partial hijacking)，而這個模式下應用程序可以在應用程序服務器設置完成header后，進行控制。
hijacking API 可以通過Rack的env變量訪問，要想知道應用程序服務器是否支持hajacking API，要通過 env['hijacking?']來判斷，它會返回一個布爾值。
接下來我們就通過full hijacking來寫一個能夠同時處理HTTP請求和websocket請求的rack app
下面的代碼通過env['rack.hijack'].call來運行full hijack，再使用env['rack.hijack_io']返回socket對象，然后我們就可以通過這個socket對象進行通信了。
#encoding: utf-8
require 'thread'
def websocket(env)
env['rack.hijack'].call
io = env['rack.hijack_io']
begin
start = 'HTTP/1.1 101 Switching Protocols'
headers = [start, 'Upgrade: websocket', 'Connection: Upgrade', '']
io.write headers.join("\r\n")
io.write("\r\n")
10.times do |i|
io.write("Line #{i + 1}!\n")
io.flush
sleep 1
end
ensure
io.close
end
end
def http(env)
['200', {'Content-Type' => 'text/html'}, ['Normal HTTP']]
end
app = lambda do |env|
if env['REQUEST_URI'] == '/cable' && env['HTTP_UPGRADE'] == 'websocket'
websocket env
else
http env
end
end
run app
上面的Rack app 使用了兩個方法分別處理，HTTP和websocket請求，其中webscoket處理綁定在 '/cable'這個URI上。websocket方法接受一個rack env變量，進行websocket處理，首先是運行full hijack，然后再通過socket對象返回 websocket response header，這樣就與客戶端建立了websocket連接，并在連接上每個1秒發送一個消息，共10個。
這個例子中的websocket方法是不嚴謹的僅作為參考。首先是判斷請求是否是websocket請求，再一個是reponse header 中缺少對websocket-key進行加密，然后返回的WebSocket-Accept。
使用Puma運行
$ puma app.ru
Puma starting in single mode...
* Version 3.4.0 (ruby 2.3.0-p0), codename: Owl Bowl Brawl
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:9292
首先發送一個常規的HTTP請求
$ curl -X GET -i -H "Cache-Control: no-cache" "http://localhost:9292"
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 11
Normal HTTP%
接下來在發送一個websocket請求：
通過socket對象連續發送10行數據后，關閉連接。
總結
ActionCable最底層是一個利用rack hijacking和EventMachine的Rack App，通過不斷地使用websocket-driver和自身的抽象封裝，在上層提供了一個非常好用的方法，與rails server也可以無縫的結合在一起
