如果你在淘寶上買過衣服，你會發現，模特的圖片一張張的加載起來實在是有點慢。有時候體驗簡直很糟糕。
我們來分析下傳輸生命線：
這是ald.taobao.com 域名下的三次請求，我們發現是按順序的請求響應，不禁要問，爲什麼三個請求不同時進行呢，能不能重疊呢。
現在市面上各類服務器如nginx, apache對HTTP的傳輸響應目前都只有一種，即：請求----響應----請求-----響應，我們暫定爲傳統模式，在傳統模式下，每一次請求都要在上次響應之後才能進行，實際上是拉長了整體的響應時間，在一些多內容的網頁上，這尤其明顯。
今天的互聯網一直還是這樣的串行處理請求，只是網速提高了變相縮小了這個問題，減緩了並行處理的發展。
一些基於TCP的流媒體傳輸控制請求，是很需要並行處理的，可惜的是現在市面上的視頻服務器都是阻塞式的，只是這類產品也不是很多，大家都是抱着能用就不錯的心態，沒有去認真的研究提高效率。
傳統服務器對於事件的處理方式是多個連接對應一個進程，比如nginx,一個連接唯一對應一個進程，事件和內存是綁定在連接上的，優勢在於事件和內存的管理上可以做得很簡單，劣勢也很明顯，比如做不到 請求--請求--響應---響應。
這種新模式其實需要一個連接對應多個進程，每個進程的傳輸內容用唯一的標識符標符。
多進程間共享連接其實很麻煩，不過可以用線程來代替。結果事件模型就轉爲以下模式：
內存和事件的管理不能簡單的綁定在連接上了，除非加鎖（效率很低，個人很排斥），應該在速度與空間折中，例如可以在線程內部分配內存，在線程處理完事件時釋放，這樣做的不好是將線程的處理粒度擴大了，在一些需要流水處理的業務上，則需要將線程中分配的內存掛載到連接上，或者 預先爲線程分配大塊內存。
客戶端可以爲每次講求分配唯一的ID，服務器的響應中也包含相應的ID，可以避免客戶端的響應凌亂。