如果你在淘宝上买过衣服,你会发现,模特的图片一张张的加载起来实在是有点慢。有时候体验简直很糟糕。
我们来分析下传输生命线:
这是ald.taobao.com 域名下的三次请求,我们发现是按顺序的请求响应,不禁要问,为什么三个请求不同时进行呢,能不能重叠呢。
现在市面上各类服务器如nginx, apache对HTTP的传输响应目前都只有一种,即:请求----响应----请求-----响应,我们暂定为传统模式,在传统模式下,每一次请求都要在上次响应之后才能进行,实际上是拉长了整体的响应时间,在一些多内容的网页上,这尤其明显。
今天的互联网一直还是这样的串行处理请求,只是网速提高了变相缩小了这个问题,减缓了并行处理的发展。
一些基于TCP的流媒体传输控制请求,是很需要并行处理的,可惜的是现在市面上的视频服务器都是阻塞式的,只是这类产品也不是很多,大家都是抱着能用就不错的心态,没有去认真的研究提高效率。
传统服务器对于事件的处理方式是多个连接对应一个进程,比如nginx,一个连接唯一对应一个进程,事件和内存是绑定在连接上的,优势在于事件和内存的管理上可以做得很简单,劣势也很明显,比如做不到 请求--请求--响应---响应。
这种新模式其实需要一个连接对应多个进程,每个进程的传输内容用唯一的标识符标符。
多进程间共享连接其实很麻烦,不过可以用线程来代替。结果事件模型就转为以下模式:
内存和事件的管理不能简单的绑定在连接上了,除非加锁(效率很低,个人很排斥),应该在速度与空间折中,例如可以在线程内部分配内存,在线程处理完事件时释放,这样做的不好是将线程的处理粒度扩大了,在一些需要流水处理的业务上,则需要将线程中分配的内存挂载到连接上,或者 预先为线程分配大块内存。
客户端可以为每次讲求分配唯一的ID,服务器的响应中也包含相应的ID,可以避免客户端的响应凌乱。