一个请求过来都经过了什么

我面试人家的时候特别喜欢问一个问题：”请描述一下一个请求过来到响应完成都做了什么，越详细越好。” 对于一个高手来说，他只要回答好了这一个问题，技术面试就通过了。所以如果我要去面试，我就把这个问题的答案压缩到40分钟到1个小时。因为一般的技术面试都是这个时间段哒，虽然我其实很想讲上两天。哎，一看我们部门就是做业务的。

为了让人家听懂，我一般会设置一个业务场景。比如说：现在用户要开始上传一个视频。那么业务上要经过用户打开浏览器页面，用户点击[选择视频文件]按钮，JS端调用系统本地文件选择器，JS端将视频信息写入到浏览器页面，用户点击[开始上传]，此时开始发送请求。

我去哪里都是随身带纸笔哒，为了直观，我会画出页面效果，还不忘补充一句：选择完视频，JS端是可以获取到视频信息哒，如：名称，大小。可以根据业务需要直接在页面上展示，用户可以对名称进行编辑。

那么我就开始描述一下这个请求到响应都做了什么啦：

一 首先是关于HTTPS的

请求通过POST的方式经过HTTPS协议发送到服务器端。HTTPS本身并非协议，而是标准的HTTP协议架在SSL/TLS协议之上的一种结构。由于HTTP协议是基于TCP/IP进行通讯的，所以HTTPS必须暴露IP和端口，这部分不加密。

HTTPS需要在服务器端生成私钥，我们服务器端用的RSA算法加密哒(对于有好几个算法发明专利的我来说，面试时涉及到算法的地方是绝对不能漏掉哒)。然后创建签名请求的证书，然后可以去CA授权或者自己签发证书，最后将证书配置到nginx里。因为服务器上HTTPS是我配的，所以我会把这部分详细的讲出来。

HTTPS在传输数据前需要客户端与服务端进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。握手的时候才用非对称加密和HASH算法，握手后数据的传输才用对称加密。

握手过程如下：

1. 浏览器将自己支持的一套加密规则发送给网站。

2. 网站从中选出一组加密算法与HASH算法，并将自己的身份信息用证书的形式发送给浏览器。证书里包含了网站地址，加密公约，以及证书的颁发机构等信息。

3. 获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性(盘发证书的机构是否合法，是否过期，证书中包含的网站地址是否与正在访问的地址一致等)，如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信任的提示。一般的浏览器对于自己签发的证书都会给不收信息的提示。

b) 如果证书受信任，或者用户接受了不受信任的证书，浏览器会生成一串随机数的密码，用最开始约定好的HASH方式，把握手消息取HASH值，然后用用证书中提供的公钥加密”握手消息+握手消息HASH值”发送给服务端。

c) 服务端拿到客户端传来的密码，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码解密握手消息与HASH值，并与传过来的HASH值做对比确认是否一致。然后服务端自己也生成一个随机密码加密一段握手消息(握手消息+握手消息的HASH值)给客户端。

d) 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后的所有通信数据将有之前浏览器和服务器生成的随机码生成的一个新的随机密码并利用对称加密算法进行加密。利用客户端和服务端的随机码来生成数据传输的随机码是为了防止写死的假随机码带来的安全隐患，使用对称加密是因为对称加密的加密加密过程比非对称快得多。

常用的非对称加密算法有: RSA,DSA/DSS; 对称加密算法有: AES,RC4,3DES; HASH算法:MD5,SHA1,SHA256。

二 然后是关于DNS的

请求会访问我们公司云存储那边的DNS(Domain Name System, 域名系统)，这是因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名或主机名，最终得到该域名或主机名对应的IP地址的过程叫做域名解析(或主机名解析)。DNS协议运行在UDP协议之上，使用端口号53。DNS会有一些策略将静态的东西直接返回给浏览器，只有动态部分才继续向后面传递。发生过测试人员在同一台机器上在不同的浏览器上用不同用户登录，结果刷新页面看到用户变了的奇怪现象，是DNS策略造成的（不负责这一块，不赘述）。

三 下面开始公司的7层代理

主要作用是转发到对应的业务nginx代理，公司使用的是SLB进行流量分发，负载均衡(不负责这一块，略过)

四 nginx反向代理和负载均衡

我有个什么都想说明白的习惯。提到反向代理，就要先说正向代理。正向代理一般叫代理。就是请求发起人找一个代理做一件事情，真正做事情的人只认识代理不认识请求发起人。常用FQ，就是http中介的一种：代理。所以我们使用FQ代理服务器连接上了国外的网站，但那个网站并不知道我们在使用。

反向代理是服务提供方出一个代理，请求人只跟代理打交道。比如这里请求只发给了nginx这个代理，后面的就是nginx自己进行处理，找到真正的业务处理服务器。如果是静态请求，如css,js啥的，就直接转向静态服务器。如果是动态请求就转向WEB应用服务器。然而不管是静态服务器还是WEB应用服务器都是有好几台服务器。Nginx按照一定的策略对请求向业务服务器进行分配，让压力不集中在一台服务器，这就是负载均衡了。

Nginx除了配置实际处理业务的服务器，还可以配置一些安全策略，比如如果一个IP在1秒内请求了100次，那么将视为攻击，直接返回错误码，不向后传递请求。还可以配置超时等待时间，多媒体文件的允许大小等。

其实……，负载均衡在SLB代理那层已经做了，但是安全方面需要各个业务端自己处理，我们每个物理机基本上只提供一个服务，所以可以直接使用80端口的

五 WEB应用服务

WEB应用服务总体采用SOA架构。分成WEB前端，后台服务，API服务，共同模块和代理接口模块。

WEB前端是返回页面的，API服务是PC，手机各端都用到的共同接口。后台服务通过代理接口模块来和API服务及WEB前端服务进行通信。代理接口里含有传递消息的可序列化POJO。共同模块含有一些公共方法。

请求根据nginx提供的IP和端口找到服务器上对应的WEB前端服务。我们服务器上部署的是resin。我们的WEB 服务采用的是SpringMVC框架(面试官哥哥会不会汗流满面，终于说到正题上了)。SpringMVC的实现原理和核心思想老掉牙了，略过(面试官哥哥是不是要惊愕了，其实只想听这个)。不过spring作为一个久经考验的框架，里面用到了几乎所有的设计模式，是应该好好总结一下的(以后专门写一篇，此处略过，面试官哥哥是不是又该开始擦汗了)。

Resin WEB应用中除了SpringMVC还有一些细小的逻辑，如一般会配置utf8编码器，logback监听器，guava限流。请求经过Spring加载上下文，上下文可以使用类加载，配置文件加载等多种方式（策略模式）。加载后我们调用的只是ApplicationContext(门面模式)，当然它同时也是一个Bean工厂(工厂模式)。DispatcherServlet将请求映射到处理器。我看过DispatcherServlet的源码，在初始化策略的时候，还支持多种类型的处理器（适配器模式）。处理器要经过拦截器对请求的用户身份等进行校验，校验不通过直接返回错误，校验通过找到对应的controller然后就开始进行参数校验。

校验不成功返回错误码。成功后HttpClient调用采用了Restful架构的视频资源系统进行内容创建。创建不成够返回错误码。成功则需要在数据库插入一条记录。调用DUBBO后台服务，服务的service层调用couchbase缓存取出当前记录是否存在，不存在则调用mybatis持久层框架到mysql数据库进行操作。操作成功后httpclient调用Restful架构的云存储那边返回视频上传初始化参数。结果回到controller里包装成ModelAndView对象，再经过拦截器注入一些session参数。因为http协议是无状态的，现在的系统又都是分布式的，不支持session，所以每次都需要在拦截器里将参数再塞入进去。然后原路返回响应。客户端收到响应后断开连接。因为http请求是无连接的。

当然处理过程中会用到好多基于AOP的，比如调试，分析埋点，日志。

浏览器收到响应里含有的上传初始化链接（返回结果里带着的）就会调用这个链接将真正的视频介质传进去。经过别的部门的云存储，云转码。转码那边会给我用消息队列，我们用的是qpidd mq采用direct的exchange发送到队列。我们这边的监听器监听到队列里的消息就将消息解析存到数据库。总体流程图如下：

关于作者
晓静，20岁时毕业于东北大学计算机系。在毕业后的第一家公司由于出众的语言天赋，在1年的时间里从零开始学日语并以超高分通过了国际日语一级考试，担当两年日语翻译的工作。后就职于人人网，转型做互联网开发。中国科学院心理学研究生。有近百个技术发明专利，创业公司合伙人。有日本东京，美国硅谷技术支持经验。目前任美团点评技术专家（欢迎关注静儿的个人技术公众号：编程一生 ）,心法文章可参考我的《自动化管理之新人培养》

技术交流可关注我的github: https://github.com/xiexiaojing