Rails Session工作原理

How Rails Sessions Work
如果你的Rails应用不知道谁在访问它?如果同一个人请求两个不同的页面你不知道怎么处理?如果接到回应后所有保存的数据都消失?

对于大部分静态站点来说这没什么大不了的。但是大部分应用需要储存一些关于用户的信息。可能是user id,偏好语言或者类似于是否在ipad上呈现应用的桌面版本这样的设置。

Session是储存这类信息的完美方案。为多个请求保留的小数据量信息。

Session使用起来很简单:

session[:current_user_id] = @user.id

但是这其中蕴藏着一些魔法。什么是Session?Rails怎么知道向不同的用户呈现其对应的信息?以及如何决定存放Session信息的位置?

Session是什么?

Session是一个可以存储请求信息,使后续请求可以读取该信息的地方。

可以在一个action中设置数据:

    #app/controllers/sessions_controller.rb
    def create
    # ...
        session[:current_user_id] = @user.id
    # ...
    end

在另一个action中读取数据:

    #app/controllers/users_controller.rb
    def index
        current_user = User.find_by_id(session[:current_user_id])
    # ...
    end

Session在客户端浏览器和你的Rails应用之间进行了协调,将两者联系在了一起。而且是基于Cookie实现的。

当客户端请求页面时,服务器会在响应中设置一个Cookie

~ jweiss$ curl -I http://www.google.com | grep Set-Cookie
Set-Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-nVyaoejz-4K6aouUQtyp5B_rK3Z7G-EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnly

浏览器会存储Cookie信息。在Cookie过期之前,每次发出请求时,浏览器都会将Cookie信息回传给服务器:

    ...
    > GET / HTTP/1.1
    > User-Agent: curl/7.37.1
    > Host: www.google.com
    > Accept: */*
    > Cookie: NID=67=J2xeyegolV0SSneukSOANOCoeuDQs7G1FDAK2j-    nVyaoejz-4K6aouUQtyp5B_rK3Z7G-      EwTIzDm7XQ3_ZUVNnFmlGfIHMAnZQNd4kM89VLzCsM0fZnr_N8-idASAfBEdS; expires=Wed, 16-Sep-2015 05:44:42 GMT; path=/; domain=.google.com; HttpOnly
    ...

Cookie看起来像一堆乱码,这是正常的,毕竟Cookie信息并不是给用户看的。Rails应用可以从Cookie中读取信息。Rails应用设置了它,当然也能读取它。

和Session有什么关系?

现在我们有了Cookie。在某次请求中设置了该值,在后续请求中得到同样的值。那么Cookie和Session的区别是什么呢?
默认情况下,在Rails中两者并没有很大的不同。Rails对Cookie做了处理来提高安全性,除此之外,像你预期的一样:在Rails应用中将数据存入Cookie,也可以将其取出来。从这一点来说,Session和Cookie确实没有任何区别。
(译注:这里指在Rails中的用法没有任何区别,而非概念上没有任何区别)

但是Cookie不总是存储Session数据的理想方案:

  • 只能在Cookie中存储4kb的数据。
    通常情况下够了,但有时不满足
  • Cookie在你每次发出的请求中携带。
    大的Cookie信息意味着更大数据量的请求(request)响应(reponse),意味着更慢的网站。
  • 如果不小心暴露了secret_key_base,用户可以修改Cookie中的信息。
    当Cookie中包含类似current_user_id这样的信息时,每个人都可能进行身份冒充。
  • 在Cookie中保存错误类型的数据是不安全的。
    如果小心一点,没有什么大问题。

当你因为以上一些原因不能选用Cookie来保存Sessio信息时,Rails还提供了其他一些方式来保存Session信息。
(译注:通常使用cookie来保存session_id)

可选择的Session存储方案

其他的Session存储方案和使用Cookie储存Session的方式类似。我们来举一个真实的例子帮助理解。
如果使用ActiveRecord纪录Session
1. 当调用session[:current_session_id] = 1时,Session实际上还没有存在。
2. Rails会在session表中使用随机的Session id(例如:09497d46978bf6f32265fefb5cc52264)插入一条新纪录。
3. 保存{current_user_id: 1}(base64编码)在该记录的data属性中。
4. 将生成的session id(09497d46978bf6f32265fefb5cc52264)使用set-cookie返回给浏览器。

下次发出请求时,
1. 浏览器使用Cookie头向服务器发送同样的Cookie信息(Cookie: _my_app_session=09497d46978bf6f32265fefb5cc52264;
path=/; HttpOnly)
2. 当调用session[:current_user_id]时
3. 服务器取出cookie头中的session id,并在sessions表中找到这条纪录。
4. 然后,返回该记录data属性的包含的current_user_id信息。

不管你将Session存储在数据库,memcached,redis或者其他的地方,几乎都遵循以上的过程。Cookie只存储session id,Rails应用使用session id在Session存储中查找相应的数据。

cookie存储,缓存存储还是数据库存储?

如果满足需求的话,将Session信息存储在Cookie中是最简单的方法。不需要额外的构造或者设置。
但是如果需要将Session从Cookie存储中移出的话,你有两个选项。
存储在数据库或存储在缓存。

在缓存中存储session信息

你可能已经使用了类似于memcache之类的来缓存你的局部页面或数据。考虑到缓存相关信息已经配置过了,缓存存储是存储Session数据第二简单的方式

不用担心Session存储增长过快,因为当缓存信息过大时,旧的Session信息会被自动清除。而且因为数据存储在缓存中类似于在内存中,访问速度是很快的。

但是这也不完美

  • 如果需要保存旧的Session信息,你可能不想让它们在缓存信息过多时被清除。
  • Session和缓存数据争夺空间。如果没有足够的空间,你可能面临缓存缺失和Session过早过期的问题。
  • 如果需要重置缓存时(例如升级rails,旧的缓存数据不再可用),只能将所有的Session信息过期。

在数据库中存储session信息

如果想存储Session信息直到它真正失效,应该考虑将其存储在数据库中。无论是Redis,AcitiveRecord或者是其他的形势。

但是数据库存储也存在短板:
- Session不能被自动清除(只能亲自清除过期的Session)
- 需要了解Session数据满溢时,数据库如何表现
- 创建Session是更加小心,否在会在数据库中填满无用的Session信息

应该怎样存储Session信息?

如果不在意Cookie存储带来的限制,那就用它。毕竟它不需要过多配置,并且维护简单。

存储在缓存中还是在数据库中,取决于怎样看待Session过早失效的问题。我认为Session信息本来就应该是暂时的,所以更倾向于将其存在缓存中。

所以我的选择顺序一般是优先cookie,其他缓存,最后考虑数据库。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页