代码之家  ›  专栏  ›  技术社区  ›  Jeff Cyr

为什么HTTP只能为每个套接字处理一个挂起的请求?

  •  2
  • Jeff Cyr  · 技术社区  · 16 年前

    出于好奇,我想知道为什么HTTP在设计上只能处理每个套接字一个挂起的请求。

    我理解这种限制是因为没有“Id”将请求与其响应相关联,因此将响应与其请求相匹配的唯一方法是在发送请求的同一套接字上发送响应。如果套接字上有多个挂起的请求,则无法将响应与其请求相匹配,因为我们可能无法按照发送请求的相同顺序接收响应。

    如果协议被设计为具有与请求和响应匹配的“Id”,那么可能只有一个套接字上有多个挂起的请求。这可以大大减少使用web服务的internet浏览器和应用程序使用的套接字数量。

    谢谢

    5 回复  |  直到 16 年前
        1
  •  1
  •   EricLaw    16 年前

    它基本上是为了简单;多年来,人们提出了各种建议,在同一个连接(如SPDY)上进行多路复用,但迄今为止还没有一项得到实施。

        2
  •  6
  •   slebetman    16 年前

    不是真的。阅读关于HTTP1.1流水线的内容。Apache实现了它,Firefox实现了它。尽管Firefox默认禁用它。

    about:config

    见: http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

        3
  •  1
  •   tster    16 年前

    在单个套接字上发送多个请求的一个问题是,这会导致排队效率低下。

        4
  •  1
  •   Einstein    16 年前

    我想回顾一下几个礼宾部。

    第一个与TCP本身的性质有关。TCP遇到“线路头”阻塞问题,即飞行中只能有一个未完成(未确认)的请求(连接/TCP级别)。考虑到传统的延迟,从加载时用户体验的角度来看,与浏览器目前采用的并行连接方案相比,这可能是一个问题。链接的延迟越高,此基本限制的影响就越大。

    还有一个并发性问题,有时您确实希望以增量/并行方式加载多个资源。回想当年,mozilla在mosaic上的一个最大特点是,它将以增量方式加载图像和对象,这样您就可以开始查看正在发生的事情并使用资源,而无需等待加载。如果连接较少,则存在风险,例如,从经验的角度来看,在样式表之前加载页面上的大型图像可能是灾难性的。期望某种缓解智能或显式配置来优化请求顺序可能不是一个现实或理想的解决方案。

    有一些建议,如HTTP over SCTP,或多或少会完全纠正您在传输级别提出的问题。

        5
  •  0
  •   Jé Queue    16 年前

    还要认识到HTTP并不一定要求 Content-Length 报头提供数据服务。即使每个HTTP响应都有ID,您如何管理没有内容长度的流式二进制内容(HTTP/1.0样式)?或者如果客户端发送了 Connection: close 由于长度未知,是否要将客户端关闭?

    推荐文章