后端分析
在整个流程中，后端所扮演的角色是传递者，夹在了用户与实验板之间。既不与用户直接进行交流，也不与硬件进行通信。但是，服务器依然有其存在的必要。
首先，用户无法找到实验板进行远程控制，而如果通过服务器进行中转，则可以很容易的在实验板与用户之间建立联系。
其次，同一个实验板能够被多个用户旁观，但是只能有一个用户能够进行有效操作。客户端的权限判别很容易被绕过，所以，实际上用户所做的所有操作全部都会被直接压在下一级的处理单元上，而对于配置较为低同时也不易扩展的树莓派来讲，可能是一个灾难。
而如果通过服务器进行判断，操作压力在服务器全部被分担，树莓派只接收有权限用户发送来的请求，并单向服务器发送视频流，客户端的压力较小。而服务器能力的扩展是较为容易的，至少，比树莓派容易。
当然，加一层服务器对于整体还是有负面影响的。硬件实验要求较高的实时性，而消息在层层传递后容易造成大的延迟，而这就是服务器所面临的挑战。
WebSocket - 浏览器服务器实时交流
实时性
由于http协议是一个无连接的协议，服务器永远是被动接受来自浏览器的请求，而后返回，而无法将某些信息推送给浏览器。在某些网页上，这一点并不会成为束缚。不过，对于我们当前的项目，并不能指望用户按F5的手速来保证用户能够获取实时的内容。
事实上，虽然http是一个无连接的协议，但是还是有一些方式能够做到实时消息的获取。
最早的方式是基于轮询的思想。http协议虽然是没有推送能力的，但是如果客户端刷新的够快，实时性依旧能够保证。这种方式对于服务器的性能要求较高，因为服务器需要处理的请求数与实时性的要求有高度正相关。
而后，更优雅的方式是类似于中断的长连接AJAX，其核心思想是客户端发送请求，服务器受到请求后不立即返回，而是在需要的时候，如有新消息的同时，进行返回。结果就是客户端在服务器有变化的同时，收到了新消息通知。
上述两种基于http协议的实时消息获取方式还有一个最大的弊端，即http协议的一个属性——无状态性。这等于是说，每次向服务器请求某些东西的时候，首先得告诉服务器客户端的身份以及当前所处的状态，而这是相当耗费流量的，而重复解析客户端发送来的身份验证信息将会极大的耗费服务器的资源。
而当前选择的WebSocket技术，则是在服务器与客户端之间建立了一个双工通道，客户端可以与服务器进行消息传递，而服务器也可以以此通道将信息推送到客户端上。
兼容性
选择新技术在前端世界所带来的就是兼容性的压力。
| 浏览器 | 支持版本 |
|---|---|
| Chrome | Supported in version 4+ |
| Firefox | Supported in version 4+ |
| Internet Explorer | Supported in version 10+ |
| Opera | Supported in version 10+ |
| Safari | Supported in version 5+ |
可以看出，目前主流浏览器的最新版本中，基本都对WebSocket做了支持。但如果想要直接照顾到IE用户，WebSocket技术基本上是不用想的了。没错，又是IE浏览器，作为在中国传播最广泛的浏览器，其之前多个版本在前端技术支持上的落后以及总体更新的迟缓造成了当前中国做前端需要考虑的兼容性问题较多。不过，近几年从IE10开始，IE表现良好，然后就被微软丢了换成edge 了，XD。
上图所代表的是国内浏览器的市场份额，明显可以看出IE浏览器在国内依然占有大比例。不过这并不意味着这个项目无法使用WebSocket！结合我的切身体会，我身边的学生所用的浏览器基本上低版本的IE已经绝迹，多见Chrome与Firefox。所以，本项目的目标人群中多数有使用条件，且低版本IE用户迁移到现代浏览器并不困难。
鉴于上述情况，WebSocket技术可行。
socket - 服务器与树莓派
在网络上，可以通过(协议，ip，端口号)这样一个三元组来唯一指定某一台计算机的某一个进程。
而进程间通信方式主要有几种，匿名管道、信号量、共享内存、消息队列、套接字等等。
其中匿名管道最为效率，但是不能实现跨网络的通信，这与我们服务器的思想不符，故放弃。而共享内存、信号量同样也不能进行跨网络的进程通信。
而在网络消息传递的方案中，我选择套接字作为树莓派上的操作进程与服务器之间的交流桥梁。socket支持文本与二进制两种交换方式，同时，交流也是实时传递，符合要求。
rtmp - 视频直播
目前网络上视频直播协议主要有rtmp、rtsp、hls等。
由于协议自身的限制，hls协议所带来的直播延迟较大，一般用作点播，所以与本项目关系不大。
rtmp与rtsp都是直播协议，rtsp的延迟会稍微小些(rtsp: 0.x s , rtmp: 1.x s)，但由于网页端对于rtmp的支持较好，首先选择rtmp协议进行尝试。
Tornado
Tornado 是 FriendFeed 使用的可扩展的非阻塞式 web 服务器及其相关工具的开源版本。这个 Web 框架看起来有些像web.py 或者 Google 的 webapp，不过为了能有效利用非阻塞式服务器环境，这个 Web 框架还包含了一些相关的有用工具和优化。
------ Tornado Web服务器
Python有很多的后端框架，例如说较轻量级的web.py以及Flask，亦或者套件齐全的Django。而作为被知乎以及FaceBook等知名网站使用的后端框架Tornado，它似乎比较偏向于两类之间。
Tornado在提供了RequestHandler这种上层的http处理模块之外，又暴露了TCPserver这种底层模块便于编写者进行拓展。此外，Tornado对于Socket以及衍生的WebSocket协议均有相应的封装。而作为与网站最相关的数据层，Tornado却没有尝试着提供一个默认的ORM模块与数据库进行交互，而是鼓励用户使用自备的模块。
而且，Tornado是一个异步框架，对于处理并发以及响应速度上有着先天的优势。
从以上各方面来看，对于我们这个项目而言，Tornado是一个很不错的选择。
