为什么HTTP协议最初被设计成无连接的？
就我而言，Ajax 提供了一种解决方法，使 HTTP 协议的行为类似于面向连接。 但为什么 HTTP 协议一开始没有设计成面向连接的呢？
As far as I'm concerned, Ajax provides a workaround for behaving like connection-oriented with HTTP protocol. But why wasn't HTTP protocol designed to be connection-oriended at first?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
因为它的目的是用于连接没有意义的事情。
它被设计为超文本传输协议，这意味着它的职责只是允许发送“请向我发送文档 X”和“这是您请求的文档 X”形式的消息。
这样的协议应该使用持久连接来做什么？
Because it was intended to be used for things where connections do not make sense.
It was designed as a HyperText Transfer Protocol, which means its responsibility was simply to allow the sending of messages of the form "please send me document X", and "here is document X, as you requested".
What should such a protocol use a persistent connection for?
和简单。
回想起来这可能并不是一件坏事，因为这意味着 HTTP 很简单，这意味着它可以轻松地用于简单的事情。
您可以通过在其之上构建层来将其用于确实需要状态的更难/更复杂的东西。
正是这种简单性使得 HTTP 得到了广泛的采用并使其具有吸引力。
如果它不简单，那么它就只是另一个复杂的协议，除非迫不得已，否则没人会使用。
如果您不相信我，您能告诉我为什么您不使用 RPC 进行通信并使用 X11 进行显示/渲染来编写 ajax 应用程序吗？ :D
请记住，HTTP 最初设计是为了实现类似 wiki 的读/写信息存储，而不是在线商店、银行、文字处理器等。
我记得读过蒂姆·伯尼尔斯·李 (Tim Berniers-Lee) 的采访，他很高兴维基得到了广泛的接受，因为（释义）这就是他希望网络运作的方式。
实际上，这种情况在更广泛的网络上并没有发生，并且大多数站点都禁用了旨在启用此功能的 HTTP PUT 方法。
And simplicity.
It was in retrospect probably not such a bad thing, as it means that HTTP is simple, which means it can be used for simple stuff easily.
And you can use it for harder/more complex stuff that does need state by building layers on top of it.
It is exactly this simplicity that got HTTP widely adopted and made it attractive.
If it was not simple, then it woud have been just another complex protpocol that n-one uses unless they have to.
If you don't believe me, can you tell me why you don't write your ajax apps using say RPC for the comms and X11 for the display/rendering? :D
Remember HTTP was originally designed to implement a wiki like read/WRITE information store, not online stores, banking, word processors etc.
I recall reading an interview with Tim Berniers-Lee where he was really happy that wikis were gaining wide spread acceptance as (to paraphrase) thats how he intended the web to work.
In practise this did not happen on the wider web and most sites disable the HTTP PUT method that was intended to enable this functionality.
HTTP 最初是无连接的，并且仍然。 AJAX 只是利用现代浏览器的 JavaScript 功能将 XML（或通常是 JSON）发送到服务器，而无需重新加载页面。
如前所述，主要原因是可扩展性。 为网站的每个浏览者保持活跃的连接将非常耗费资源。 此外，事实是 HTTP 的原始创建者并没有设想任何需要具有维护连接的系统 - HTTP 的想法只是发送对请求的文本响应，然后完成。
HTTP was originally and still is conectionless. AJAX simply makes use of modern browser's JavaScript capabilities to send XML (or often JSON) to the server without reloading the page.
As mentioned, the main reason is scalability. Maintaining an active connection for each viewer of the website would be incredibly resource-intensive. Also, the fact was that the original creators of HTTP did not envisage any need for a system with a maintained connection - the idea of HTTP was simply to send a textual response to a request and then finish.
AJAX 并不是面向连接行为的解决方法。 这是为了确保基于用户交互，您只想更新客户端的一部分内容，而不是再次从服务器获取完整的标记。 它不会在浏览器和 Web 服务器之间建立往返连接。
如果每台服务器与每个客户端都有实时连接，则互联网大小将限制为几百万用户。
如果每台
AJAX is NOT a workaround for behaving like connection oriented. It is to ensure that based on user interaction, you want to update only a PORTION of content on client side instead of getting the full markup again from the server. It does not establish a to-and-fro connection between your browser and the web server.
If every server had a live connection with the every client the internet size would have got limited to a couple of millions of users.
出于可扩展性的原因。 维持连接会消耗资源。
For scalability reasons. Maintaining connections uses up resources.
我认为原因很简单 - 当 http 创建时：
1）大多数/所有页面都是静态的
2) 由于互联网上几乎没有商业存在，因此假设链接很可能不会指向不同的站点。
所以，静态页面+非本地内容=免连接协议。
I think the reasons are pretty simple - when http was created:
1) Most / all pages were static
2) With almost no commercial presence on the internet, it was assumed that links were as likely as not to be pointed to a different site.
So, static pages + non-local content = connection free protocol.