关于 非持续 HTTP 请求以及持续 HTTP 请求

对于一个浏览器的请求来说，从连接的角度来看，似乎是一个比较持续的过程，因为对于一个请求发送和接收来说，往往是类似这样的一个过程：

如上图所示，如：
$$请求发出\to 等待服务器响应\to 服务器处理\to 最终发送响应的报文$$
的这一整个过程来看，对于页面的使用者来说，他们通常只会是一个简单的动作：一次点击，或是一次页面的刷新，而这个请求的过程，其实只会在用户每次在前端触发某个事件的时候才会相应的产生的，每次的请求事实上都是若干个单独的请求连接，而不是在客户端这边始终会跟服务器这边保持联系，通过一个持续维持的通道随时准备发送客户端的请求。

因此，从这个角度来看，对于多个请求的过程来说，这些请求并不是一个持续的 HTTP 请求的过程，每次在服务器这边，都会创建一个新的进程来负责相应的请求内容处理：

而当 $Ajax$ 出现之后，客户端例如在浏览器的页面请求上，有了更加灵活的加载形式。这个时候，客户端不再需要在每次发送一个请求的时候都需要刷新整个的页面，而只需要对页面所需要的部分信息进行更新。这样，从用户的使用角度来看，不必在每次点击一个搜索按钮，或者是一个获取页面部分内容展示的时候，都需要看到一个让人烦躁的页面刷新按钮，重新展示整个页面，而可能仅仅只是需要更新一个查询结果或者是换一个图标：

这样，对于整个浏览的过程来说，从用户的角度来看，减少了多余页面元素的刷新带来不胜友好的体验，另外，对于数据传输以及服务器处理来说，也无需再次响应一个完整的页面，而是仅仅需要传输部分相关的更新数据即可。

此时前端就只需要关注：当后端传递来什么样的数据，或者接收到什么形式的内容，页面的布局以及展示方式需要如何调整。

这样，响应式的前端页面布局就应运而生了，后端不再需要处理页面的展示逻辑，前端也无需关注需要展示什么数据，整个应用的在设计上，数据和展示逻辑更加的分离，更加明确，只需要确定好数据交互方式，前后端可以更专注于自己需要实现的内容。

当然，这种分离也不是完全绝对的，任何前后端的设计上更多的时候需要取决于具体的需求，以及具体的数据展示的需要，进行相应的处理，有时候，一些数据可能在前端上进行处理将会更加的方便，而有时候也可能需要依赖于后端来返回某些页面的展示。这样的完全独立是理想化的，但是不管怎样，在设计上尽可能的考虑类似这样相互独立，让每个部分的逻辑更加的分离，不仅可以让我们在页面设计上更加的清晰，也方便项目在后续进行迭代和更新时更具有扩展性。