大并发服务器之阵痛1---传输响应模式

如果你在淘宝上买过衣服，你会发现，模特的图片一张张的加载起来实在是有点慢。有时候体验简直很糟糕。

我们来分析下传输生命线：

这是ald.taobao.com 域名下的三次请求，我们发现是按顺序的请求响应，不禁要问，为什么三个请求不同时进行呢，能不能重叠呢。

现在市面上各类服务器如nginx, apache对HTTP的传输响应目前都只有一种，即：请求----响应----请求-----响应，我们暂定为传统模式，在传统模式下，每一次请求都要在上次响应之后才能进行，实际上是拉长了整体的响应时间，在一些多内容的网页上，这尤其明显。

今天的互联网一直还是这样的串行处理请求，只是网速提高了变相缩小了这个问题，减缓了并行处理的发展。

一些基于TCP的流媒体传输控制请求，是很需要并行处理的，可惜的是现在市面上的视频服务器都是阻塞式的，只是这类产品也不是很多，大家都是抱着能用就不错的心态，没有去认真的研究提高效率。

传统服务器对于事件的处理方式是多个连接对应一个进程，比如nginx,一个连接唯一对应一个进程，事件和内存是绑定在连接上的，优势在于事件和内存的管理上可以做得很简单，劣势也很明显，比如做不到 请求--请求--响应---响应。

这种新模式其实需要一个连接对应多个进程，每个进程的传输内容用唯一的标识符标符。

多进程间共享连接其实很麻烦，不过可以用线程来代替。结果事件模型就转为以下模式：

内存和事件的管理不能简单的绑定在连接上了，除非加锁（效率很低，个人很排斥），应该在速度与空间折中，例如可以在线程内部分配内存，在线程处理完事件时释放，这样做的不好是将线程的处理粒度扩大了，在一些需要流水处理的业务上，则需要将线程中分配的内存挂载到连接上，或者 预先为线程分配大块内存。

客户端可以为每次讲求分配唯一的ID，服务器的响应中也包含相应的ID，可以避免客户端的响应凌乱。