异步http和同步http原理和差异

开发服务器端程序时，一种常见的需求是，通过向另一个http服务器发送请求，获得数据。最常规的作法是使用同步http请求的方式，过程如下

这种方式简单好用，但是在高并发场景下有缺陷。在单线程环境下，程序发送http请求是串行的，也就是第一个请求未完成的情况下，第二个请求发不出去，就像一条单行车道，车子只能一辆一辆的过。 为此我们会引入多线程提高并发性，然而多线程对并发发送http请求的提升也是有限的，比如8个线程同时只能发送8个请求，假如每个请求从发送到得到结果的时间是1秒，那么8个线程每秒钟也只能发送8个请求，而线程不能无线多开，因此多线程并不能很好的解决客户端高并发发送请求的问题。

这听起来很扯淡，我们使用的服务器配置动不动就8核16G，为什么发送http请求的能力如此弱鸡，实际上这并不是服务器的锅，也不是java的锅，而是http工作模式的原因，在发送数据和得到数据的过程中有一个等待的过程，等待的过程并不消耗CPU，但是会让当前线程陷入等待，干不了别的事情。如果把多线程转换成线程池的模式，那么使用同步http时，在高并发场景下，线程池的队列中会堆积大量请求任务发不出去，而被请求的目标服务器，却还远没有达到瓶颈。

解决方案是使用异步http模型，我们知道nodejs因为天生的异步高性能而出名，实际上异步并不是nodejs的专利，任何主流的高级语言都支持，如 java、c++、.net等。

异步为什么快呢？因为异步http去除了同步http请求的等待过程，只保留了发送和处理得到数据的过程， 这听起来很扯蛋，发送http怎么可能没有等待呢？我在浏览器里访问网站不也要等一会才能打开页面吗？ 实际上异步http请求并不是没有等待，只是把等待的这个步骤从当前线程转移到了别的地方，当前线程除了发送数据， 可以不干别的事情，而发送数据非常快，每一刻都是成千上万，可以充分利用计算机资源，而不是空等啥都干不了。

而http结果的响应，可以理解成以事件响应的形式触发，或者更通用的说法是回调函数的形式，所以发送数据和处理结果是两个不同的分支，也可以理解成处于不同的线程，互不干扰。

要较为深刻的理解异步http，还需要从TCP说起。TCP连接就像一根双向流通的管道，客户端从一端发送数据给服务器，服务器也从另一端发送数据给客户端。http本质上也是这种工作模式。客户端把一些http规范指定的必须数据项，包括请求头、请求主体、内容长度等信息打包成一个http请求数据包，通过TCP连接发送给服务器。服务器接受到http请求数据包，解码处理后，组装一个http响应包，发送给客户端。所以http本质上还是基于TCP的。

异步http就是这种底层工作模式的体现，客户端向服务器发送http请求，然后去做别的事情了，比如发另一个请求给服务器。至于服务器何时把响应数据包发送过来，客户端可以不管，至少在当前执行的上下文中可以不管，因为当服务器响应时，会有另外的线程被唤醒处理这个响应。

既然异步http更接近http的本质，性能也更高，那么为什么还会有同步http出现呢？而且通常还是使用http请求的默认模式。主要原因还是同步 http使用简单，易于理解，更符合人类正常思考问题的思维，也更容易让新手入门。

同步http只是将异步http进行了封装，当客户端发送一个http请求时，让当前线程进入等待，当结果响应了再让当前线程唤醒处理结果。这样整个http的过程变的简单了，但是却远离了tcp的本质，性能也更差劲了。