本文想从一个角度来让大家认识到回答一个问题不能从表面或者感觉来判断，这是学习技术的大忌，很多新手如果刚开始没有一套学习方法，从各种碎片化信息去学习编程，学习一段时间很容易进入瓶颈期，所以我觉得有必要通过一些我平时思考过的问题，踩过得坑，来总结一下也方便自己日后巩固，另一方面也想分享出来帮助需要的人，让大家发现解决一个问题只有知道背后越多的概念和设计，思路才会越多，才会懂得基础的重要性，如果有幸能引发共鸣和思考，就非常幸运了，当然文中大部份的内容都是我自己内化过之后用浅显的语言描述，尽量让更多的人能听懂，不会像很多博客复制粘贴，我觉得也没有意义，如果有哪些地方没有讲清楚，也欢迎大家交流补充。

首先从问题当中有几个重要的关键词，请求，线程，多，单，快。我们一个一个来稍为补充一下：

1. 请求。在题目上下文里指的是客户端发送多条HTTP请求到服务端。假设是发送到同一个服务器， 都是HTTP1.1 以上协议开启了多路复用的情况。那就是一条TCP链接。     

2. 线程。一般客户端发送HTTP会启一个单独线程，不在主线程渲染UI线程发起。   

3. 多。就是开多个单独线程分别去请求。这里的多的目的是建立多个TCP还是多个操作系统的线程。    

4. 单。就是单独一个操作系统中的线程，自然TCP链接就是一个。       

5. 快。从题目来看应该是想更快接收到所有请求返回给上层业务处理，想让CPU更快处理完？还是期望客户端和服务器传输的时间尽量快？

基于以上拆分出来的一些小问题我们需要了解一些以下的几个概念：

CPU计算密集型：逻辑很复杂，非常多的计算量，让CPU几乎跑满了，还觉得达不到预期的速度。

I/O密集型：一直在等待一些外部设备的输入或者输出，一般速度更CPU关系不大，比如等待请求返回或者发送，等待硬盘的读入或者写入等等。

一、进程/线程/协程

首先需要知道的概念就是进程，进程是操作系统调度资源的单位，怎么理解呢？就是一种资源分配隔离机制，不同进程当然不能随意互向修改对方资源，本着公平的原则，由操作系统同一分配安排，当然在任一刻的时候CPU只可能在执行一个进程中，不能同时在执行两个进程，一般我们开发的App等都是一个进程，那为什么可以同时听着别的音乐App的音乐，看着另外一个App内的文章呢，不是同时进行的吗？

你以为你以为的同时就是同时吗？

你的大脑欺骗了你，只要CPU在多个进程间切换的足够快，每个进程只给一点点时间，这个时间差小到你都感觉不到，你就觉得你的这个App一直是独占了CPU，从没离开过你这个App， 这个跟我们看视频看动画一样的道理，图片切换的足够快你就认为那个是运动的动态的，非一些离散的时间点拼凑的。

接下来要说的是线程，为什么要有线程这个概念，理论上操作系统的分时机制来快速切换多个进程让大家都有机会被CPU执行已经很完美了，那就要从单个进程内部来看，大部分客户端都会有一个主线程，然后耗时I_O等会放到其他线程，为什么这么做呢，其一渲染在一个线程来做简单，多线程会有数据竞争的问题，其二如果都在主线程如果某个I_O时间等待太长一直占住就没有机会给UI线程渲染就会体验比较差，所以大部分的情况跑在主线程UI线程会让体验更好，这么来看在客户端大部分情况多线程的目的是为了I/O的等待，当然还有一种就是计算量太大开个线程跑，是为了利用多核，我们这里暂且讨论单核。

最后是协程。可能写客户端的接触协程应该还比较少，Kotlin就有协程，当然很多语言都有协程，为什么又要搞出个这个东西呢，多线程还不能满足吗，多线程一般为了I/O的时候不阻塞当前线程而开启了多个线程，但是线程的创建需要大概1M的资源，所以不能创建太多，其二多线程切换切换也有成本，需要保存上下文值，所以协程就是一种更轻量的执行任务的单元，协程和线程区别是：协程一般由编程语言的内部实现，由可以控制的调度器去控制切换，而线程虽然也可以控制当前所在线程，但是线程所属的进程由操作系统抢占式的切换。协程属于轻量级线程，一般背后可以有1对1或者M对N或者N对1的真实线程，不同语言实现不一样。例如Python的协程是N对1，Golang的goroutine是M对N。

二、为什么要用多进程/线程/协程

上面主要介绍了客户端会使用多线程的情况，客户端一般不会用到多进程，当然也可以，多进程的使用一般都为了利用多核去处理计算密集型，多核可以看成多台计算机一起运算，再说说服务端为什么要用多进程或者多线程呢？如果是单进程的话，我们写的服务端代码放在服务器，当有一个用户请求进来需要处理至少需要一个进程，此时如果没有处理完又来了一个用户请求需要处理，此时如果还是单进程就需要排队了，那么这个并发量大的时候显然我们是不能接受的，所以此时我们可以用单进程的方式，但是用多线程每个用户对应一个线程去处理，我们上面知道线程是比较重的，而且开的线程数量也有限因为资源是有限的，一般服务端会用线程池的方式prefork就是预先创建一堆线程。所以只是一种不太好的方案，多进程的方案嘛也可以，跟上面一样只是更加占用资源了，prefork的方式是不错，但是有个缺陷是并发量不大的时候也要预先创建一堆线程，俗话就是站着坑不拉屎，而协程的创建几乎不占用多少资源，可以随时用随时释放，所以现在一些高性能web服务器都采用这种方案。就不举例子了。

三、发送请求背后发生了什么

终于到了网络部分，我们知道TCP链接的建立需要三次握手，其中一部分的原因就是因为需要双方共识大家初始化的id来标识每次请求的id，什么是建立连接？拿一跟线两头连接上吗？当然不是，连接的本质是双方各自初始化了一个socket的标识符，可以当成一个文件，以后这个连接发送过来的东西都存到这个里面，所以说连接只是让双方确认一下，认识到以后有数据进来可以识别出来。发送请求其实就是先把要发送的数据存到一个缓冲区，然后等待操作系统帮你一层层打包发送到网卡然后走网线出去而已，接受就是一个相反的过程本质是一样的。所以我们打包的过程其实是很快的，接受也是，慢是慢在这个路程中，跟快递一样，所以就算开了多个操作系统的线程并不会加快多少速度，开多个TCP的链接呢，理论上会快，跟多线程下载是一个原因，快的是你想占用服务器更多的带宽，对于服务端来说带宽一定，他需要公平的对待多条TCP链接，所以当然你占用条数越多速度也相对会快一点，这里面还有很多细节会影响速度，客户端的带宽，客户端的TCP链接数，TCP拥塞控制等等，读者们可以去扩展阅读，本文能达到启蒙或者有那么点意思就够了。

总结：

经过上面我们的分析我们可以发现，回答一个问题可能并没有银弹，需要有一个场景一个上下文，一个具体的业务中我们再运用这些基础的知识去深入思考，来给我们程序设计或者调优。所以说努力一定就会成功吗？如果遇到一定这个词，我们需要的是多个角度，多个维度来去看待问题，给出我们认为的一种思路，而不是想当然，感谢你认真的读完，这是我第一次尝试用自己的语言去解释一些编程中的问题，如果你觉得还不错或者哪里不太好的地方欢迎给我留言，也许就是你的留言才让我坚持下去✊

如需转载请联系本人，标注转发自原始地址。想要关注更多博主文章请关注公众号，也可以访问博客地址：Blog[1]

References

[1] Blog: koofrank.com