大併發伺服器之陣痛1 傳輸響應模式

如果你在**上買過衣服，你會發現，模特的一張張的載入起來實在是有點慢。有時候體驗簡直很糟糕。

我們來分析下傳輸生命線：

這是ald.taobao.com 網域名稱下的三次請求，我們發現是按順序的請求響應，不禁要問，為什麼三個請求不同時進行呢，能不能重疊呢。

現在市面上各類伺服器如nginx, apache對http的傳輸響應目前都只有一種，即：請求----響應----請求-----響應，我們暫定為傳統模式，在傳統模式下，每一次請求都要在上次響應之後才能進行，實際上是拉長了整體的響應時間，在一些多內容的網頁上，這尤其明顯。

今天的網際網路一直還是這樣的序列處理請求，只是網速提高了變相縮小了這個問題，減緩了並行處理的發展。

傳統伺服器對於事件的處理方式是多個連線對應乙個程序，比如nginx,乙個連線唯一對應乙個程序，事件和記憶體是繫結在連線上的，優勢在於事件和記憶體的管理上可以做得很簡單，劣勢也很明顯，比如做不到請求--請求--響應---響應。

這種新模式其實需要乙個連線對應多個程序，每個程序的傳輸內容用唯一的識別符號標符。

多程序間共享連線其實很麻煩，不過可以用執行緒來代替。結果事件模型就轉為以下模式：

客戶端可以為每次講求分配唯一的id，伺服器的響應中也包含相應的id，可以避免客戶端的響應凌亂。