http请求的socket信息必然需要存储，直到这个http请求结束。upstream的长连接是非阻塞的，一个http请求通过upstream发送给后端的服务器，如果服务器没有响应，那么这个upstrem会处理其他http请求。感觉并不需要修改你们的后端服务器，除非这个后端服务器只支持一个连接接入。
ngx-lua的cosocket功能可以完全替换upstream的功能，所以能写lua尽量写lua，写upstream就要用c了。
在 2012年10月30日星期二UTC+8上午10时28分06秒，珠珠写道：
开始我的设想是：整个webserver部分已有一条tcp连接到upstream，接着看到nginx是多进程的，设想每个进程1条tcp连接到upstream，不过确实实现起来可能得不偿失。
> keepalive的长连接某一时刻也只能给一个前端http用户使用；不过适应这个构架很好
>
这里我的意思是后台 upstream的那个长连接，我看ngx_http_upstream_keepalive_module 是用连接池的，如果只用一条upstream的长连接,势必要保存前端http连接socket，并将该信息关联，等upstream返回再找到前端http连接socket做回应。从效率上看，连接池也是十分高效的，所以我说改动后台服务器代码适应了这个也是很不错的。
以上是我现在的想法，也有可能对nginx upstream keepalive理解错误。
