今天看了 CSRF ，觉得好沉重啊。 突然有下面的设想，不知道有多少可行性，有很多地方不熟悉，例如 server 验证客户端可信等方面不懂。大家一起看下。
让 WebSoket 替代 HTTP 进行通讯的设想如下：
1. 浏览器要通过系统验证，通过验证的浏览器才能使用。( Chrome 、 Safari 、 Firefox...)
2. 用户用某浏览器(设为 B1 )，访问某站点(设为 S1 )， S1 与 B1 之间就创建一条 WebSocket 连接。用户访问 S1 的任何页面、不管同时开启几个页面(都是使用 B1 浏览器)， S1 与 B1 之间都有且仅有一条 WebSocket 连接作为通讯。
3. 用户在电脑中安装了 N 个通过验证的浏览器，那么此用户与 S1 的连接数最大值即为 N ，保护服务器。
4. 站点在与客户端(也就是浏览器)建立连接前，要验证浏览器的合法性。这点能否做到？
CSRF 的难以防范主要是没有办法确认请求来自源页面，上面的方案是否就可以解决这样的问题？因为 ws 是有状态的连接，不需要 session 、不需要把身份信息保存在客户端，连接本身就是身份验证的象征，连接没法伪装(能伪装？没做过什么 C/S 应用，不确定 T_T )
这可能会带来如下问题：
1. SSO 可能没法进行了， SSO 是通过 cookie 作为信息媒介共享身份 token 的。
2. 服务器压力问题。如果所有连接都是长时间活跃的那还没问题，如果一大堆僵死连接，连了之后都没操作，服务器在维持连接方面会耗费大量资源。这个是不是可以通过代理服务器来解决？即大量代理服务器专门用来承担连接保活的工作，请求则转发给处理服务器，再把结果转发给用户。
3. 用户体验变差，没有 SSO 。同时也没有“记住我”的功能，每次关闭浏览器后连接都会关闭，会话结束，即退出登录。 能不能有类似记住密码、自动登录的机制来弥补下。。？
4. 用户体验再差一点，网络不好导致连接断开是不是也要退出了。
| 
转播
