阿里面试官：淘宝页面请求的过程说一下

Posted 2023-04-09 Think_Higher

文章目录

• 1.在浏览器输入https://www.taobao.com
• 2.DNS获取IP地址
• 3.根据HTTP协议生成HTTP请求报文
• 4.TLS进行加密,提供保密性和数据完整性
• 5.TCP三次握手
• 6.IP寻址
• 7.ARP协议获取MAC地址
• 8.BGP外部网关协议
• 9.MAC寻址
• 10.服务器接受请求
• 11.服务端处理请求
• 12.服务端提供响应
• 13.四次挥手
• 14.浏览器解析和渲染
• 15.网页静态资源加载
• 16.交互结束

1.在浏览器输入https://www.taobao.com

浏览器接收url开启网络请求线程,URL包括以下部分
protocol：协议头https
host：主机域名www.taobao.com
port：端口号(默认)
path：无
query：无
fragment：无
https协议
https协议是基于http协议开发的,是比http更安全的协议,在http协议的基础上增加了SSL/TLS加密

2.DNS获取IP地址

计算机之间只能通过ip相互通信，因为ip不好记，于是才使用dns服务器把域名解析为相应的ip，
这里以解析www.taobao.com为例–>当我们输入这个网址回车的时候，浏览器–>会首先查询浏览器的缓存–>如果没找到

–>则去查询本地的dns缓存和hosts文件，如果有www.taobao.com这个域名对应的ip，则直接通过这个ip访问网站服务器。如果本地的dns缓存和hosts文件没找到

–>这时候就会把请求发送给，网卡配置信息里的dns服务器，默认有两个，只有当dns1不能访问时，才会使用dns2(运营商)。

我们也称网卡配置信息里的dns为local dns，这时候local dns会先查询它的缓存，有没有www.taobao.com相应的记录，如果有，则返回给用户，如果没有

–>就会访问根域名服务器，世界一共有13台根域名服务器，根域名服务器一看，是找.com的，于是会把.com的顶级域名服务器的ip发送给local dns

–>这时local dns再次访问.com的顶级域名服务器，.com的顶级域名服务器一看，是找一级域名taobao.com的，于是再将taobao.com的ip发送给local dns

–>然后继续往下找，直到找到www.taobao.com的权威dns的A记录或者cname–>这时候local dns会把找到的www.taobao.com的ip发送给客户端，并记录在缓存中，这样的话，下次如果有其他的用户访问www.taobao.com这个域名时，local dns的缓存中就有记录了。

客户端收到local dns发送过来的ip就会通过ip去访问服务器，并将这个ip记录在dns缓存中。如果url里不包含端口号，则会使用该协议的默认端口号。

3.根据HTTP协议生成HTTP请求报文

HTTP报文一般包括了： 请求/响应行，请求/响应头部，空白行，请求体/响应数据。
请求

【请 求 行】请求方法 空格 请求资源地址(URI、无域名) 空格 HTTP版本 空格 CRLF(换行符)
【请 求 头】标识:内容 CRLF(换行符)
【空 一 行】(表示请求头结束)
【请求 主体】（即请求正文，用户的主要数据。POST方式时使用，GET无请求主体）
响应

【响 应 行】HTTP版本 空格 状态码 空格 状态码的文本描述 空格 CRLF(换行符)
【响 应 头】标识:内容 CRLF(换行符)
【空 一 行】(表示响应头结束)
【响应 主体】所谓响应主体，就是服务器返回的资源的内容。即整个html文件。

4.TLS进行加密,提供保密性和数据完整性

(1)TLS是对SSL的改进,目标是为了更安全,可以确保数据发送到正确的客户端和服务器,途中防止被窃取,并且数据在过程中不发生改变.

TLS 使用“消息认证代码的密钥散列法”，当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。

增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，数据仍然是安全的。

TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。

(2)TLS协商过程
客户端发出请求(ClientHello)，客户端表达想跟服务端安全进行通话

服务器回应 (ServerHello)，服务器收到并返回给客户端证书,拿去验证身份

客户端回应Certificate Verify),客户端验证证书的真实性,如果有误发出警告并断开链接,如果无误,客户端就会取出公钥并把秘密消息加密发送至服务端

服务端最后回应(Server Finish),用私钥将客户端消息解密,然后处理并加密发给客户端,这时加密通道已经建立成功了.双方可以进行加密传输了.

应用层结束
在应用层将要发送的数据内容形成了应用层的报文data,发送到传输层
传输层开始

5.TCP三次握手

握手过程:
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN©。此时客户端处于 SYN_Send状态。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD的状态

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised状态。

服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接。

通俗点说就是:

客户端想要跟服务端进行通信,首先告知服务端一声:“我想跟你通信”
服务端收到客户端的连接请求,回一个确认消息:“我知道了,你现在能连吗?”
客户端收到服务端的确认消息后,礼貌的告知一下服务端:“好的,咱们开始通信吧”
传输层结束
这些数据通过传输层发送，比如tcp协议。所以它们会被送到传输层处理，在这里报文打上了传输头的包头，主要包含端口号，以及tcp的各种制信息，这些信息是直接得到的，因为接口中需要指定端口。这样就组成了tcp的数据传送单位segment。tcp是一种端到端的协议，利用这些信息，比如tcp首部中的序号确认序号，根据这些数字，发送的一方不断的进行发送等待确认，发送一个数据段后，会开启一个计数器，只有当收到确认后才会发送下一个，如果超过计数时间仍未收到确认则进行重发，在接受端如果收到错误数据，则将其丢弃，这将导致发送端超时重发。通过tcp协议，控制了数据包的发送序列的产生，不断的调整发送序列，实现流控和数据完整。然后待发送的数据段发送到网络层。
网络层开始

6.IP寻址

网络层开始负责将这样的数据包在网络上传输，如何穿过路由器，最终到达目的地址。在这里，根据目的ip地址，就需要查找下一跳路由的地址。首先在本机，要查找本机的路由表。
查找过程是这样的:

根据目的地址，得到目的网络号，如果处在同一个内网，则可以直接发送。

如果不是，则查询路由表，找到一个路由。

如果找不到明确的路由，此时在路由表中还会有默认网关，也可称为缺省网关，IP用缺省的网关地址将一个数据传送给下一个指定的路由器，所以网关也可能是路由器，也可能只是内网向特定路由器传输数据的网关。

路由器收到数据后，它再次为远程主机或网络查询路由，若还未找到路由，该数据包将发送到该路由器的缺省网关地址。而数据包中包含一个最大路由跳数，如果超过这个跳数，就会丢弃数据包，这样可以防止无限传递。路由器收到数据包后，只会查看网络层的包裹数据，目的ip。所以说它是工作在网络层，传输层的数据对它来说则是透明的。

如果上面这些步骤都没有成功，那么该数据报就不能被传送。如果不能传送的数据报来自本机，那么一般会向生成数据报的应用程序返回一个“主机不可达”或 “网络不可达”的错误。

关于NAT转换
如果是在局域网中,每台电脑都有自己的私网IP,在对外传输的时候,会经过NAT转换,改成路由器的公网IP

7.ARP协议获取MAC地址

ARP协议是将IP地址映射成MAC地址的,由于是IP协议使用了ARP协议,因此通常把ARP协议划归为网络层,但是ARP协议的用途是为了从网络层使用的IP地址解析出在数据链路层使用的MAC地址.
获取MAC地址过程:

主机生成一个具有目的IP地址(默认网关)的ARP查询报文,将该ARP报文放置在一个具有广播目的地址(例如FF:FF:FF:FF:FF:FF:FF)的以太网帧中,并向交换机发送该以太网帧,交换机将该帧交付给所有连接的设备,包括网关路由器。

网关路由器在接口上收到包含该ARP查询报文的帧,发现ARP报文中目的地址IP地址匹配接口的IP地址.网关路由器因此准备一个ARP回答,指示它的MAC地址对应报文中的IP地址,它将ARP回答放在一个以太网帧中,其目的地址是源MAC地址,并向交换机发送该帧,再由交换机将该帧交付给主机。

主机接收包含ARP回答报文的帧,并从ARP回答报文中抽取网关路由器的MAC地址。

将这个MAC地址将与IP包共同传输给下层。

8.BGP外部网关协议

在网络层用BGP协议来控制路由的传播和选择最佳路由。
路由更新时，BGP只发送更新的路由，大大减少了BGP传播路由所占用的带宽，适用于在Internet上传播大量的路由信息。
BGP路由通过携带AS路径信息彻底解决路由环路问题。
BGP提供了丰富的路由策略，能够对路由实现灵活的过滤和选择。
网络层结束
在网络层被打包，这样封装上了网络层的包头，包头内部含有源及目的的ip地址，该层数据发送单位被称为packet。
数据链路层开始

9.MAC寻址

首先通过广播获取足够的MAC地址表，交换机使用MAC地址通过指向相应端口的交换结构将网络通信转向目的节点。交换机为了知道要使用哪个端口来传送单播帧，它必须首先知道自己的每个端口上都存在哪些节点。

交换机使用其 MAC 地址表来确定如何处理传入的数据帧。通过记录与其每一个端口相连的节点的 MAC 地址来构建其 MAC 地址表。当某个特定端口上的某个特定节点的 MAC 地址记录到地址表之后，交换机就可以知道在后续传输中，应将目的地为该特定节点的流量从与该节点对应的端口上发出。

当交换机收到传入的数据帧，而地址表中没有该帧的目的MAC地址时，交换机将把该帧从除接收该帧的端口之外的所有端口转发出去。当目的节点响应时，交换机从响应帧的源地址字段中获得的该节点的MAC地址，并将其记录在地址表中。在多台交换机互连的网络中，连接其它交换机的端口MAC地址表中记录有多个MAC地址，用来代表远端节点。通常，用于互连两台交换机的交换机端口在MAC地址表中记录了多个MAC地址。

数据链路层结束

10.服务器接受请求

用户发起的请求都指向调度服务器（反向代理服务器，譬如安装了nginx控制负载均衡），然后调度服务器根据实际的调度算法，分配不同的请求给对应集群中的服务器执行.
服务端将数据包通过数据链路层->网络层->传输层一层层的解封,最后处理HTTP中的请求

11.服务端处理请求

首页请求

因为输入的url是请求进入网站首页的,不带任何参数请求,而且操作简单,这样下来QPS即每秒查询量是极大的,服务器需要在极短的时间内处理这些流量,这时候会用到CDN系统的缓存服务器将首页的图片迅速分发给用户。
在网站和用户之间引入CDN之后，用户不会有任何与原来不同的感觉。
使用CDN服务的网站，只需将其域名的解析权交给CDN的负载均衡设备，CDN负载均衡设备将为用户选择一台合适的缓存服务器，用户通过访问这台缓存服务器来获取自己所需的数据。
用户可以以最短的路径，最快的速度对网站进行访问。因此，CDN可以加速用户访问速度，减少源站中心负载压力。
其它请求

后台统一处理请求，处理完后响应结果.一般后端都是有统一的验证的，如安全拦截，跨域验证.如果这一步不符合规则，就直接返回了相应的http报文（如拒绝请求等）
然后当验证通过后，才会进入实际的后台代码，此时是程序接收到请求，然后执行（譬如查询数据库，大量计算等等）
等程序执行完毕后，就会返回一个http响应包
关于数据库
对于数亿用户的存储
合理设计数据库字段
创建索引
分库分表
水平分库分表

对单个指标通过Hash等方式分散在多个库或表中
简单来说就是把一个表的数据划分到不同的数据库,两个数据库的表结构一样,根据一点的规则来划分数据库,查询的时候也根据一定的规则知悉在哪个数据库
垂直分库分表

将不同业务指标分散在不同库和表
简单来说,就是按照业务功能等划分,比如说把收藏夹和购物车放到不同的库中

12.服务端提供响应

服务端处理完请求后,会将所请求的东西响应给客户端
服务器会以同样的顺序同样的方式将响应数据包发送都客户端

13.四次挥手

在这种短链接下,当客户端接受到服务端的响应后进行挥手操作
第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态。

服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

通俗点说就是:

客户端:“我要下了,还有什么想跟我说的吗?”
服务端:“等等,上一句还没说完”
服务端发完后说:“好了,说完了”
客户端:“我知道了,拜拜”

14.浏览器解析和渲染

(1)解析HTML,构建DOM树
HTML文档会被解析成一棵以document为根的DOM树，解析过程中如果遇到javascript，则会暂停解析并传输下载相应的文件造成阻塞，故推荐将JavaScript脚本放在HTML文件的后面。
(2)构建CSSSOM树
浏览器根据外部样式，内部样式和内联样式来解析CSS，构建CSSSOM树。
(3)构建渲染树和布局
DOM树和CSSOM树构建完毕后会融合成渲染树，然后浏览器会确认页面各元素的位置。
(4)页面绘制和优化
浏览器根据布局结果进行页面的绘制，并优化页面内容，减小CPU消耗。

15.网页静态资源加载

以阿里巴巴的淘宝网首页的logo为例，其url地址为img.alicdn.com/tps/i2/TB1bNE7LFXXXXaOXFXXwFSA1XXX-292-116.png_145x145.jpg,我们清楚地看到了url中有cdn字样。

什么是CDN？如果我在广州访问杭州的淘宝网，跨省的通信必然造成延迟。如果淘宝网能在广东建立一个服务器，静态资源我可以直接从就近的广东服务器获取，必然能提高整个网站的打开速度，这就是CDN。

CDN叫内容分发网络，是依靠部署在各地的边缘服务器，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度。

16.交互结束

这时如果以上步骤都不出意外,就得到我们想要访问的网页了.在我们输入网址到网页展示短短几秒的过程中就大致经历了这么多过程.
客户端到服务端如上所示,看似只有一次交互,其实中间过程中已经交互了多次,比如握手过程,都是需要进行发包交互的.
还有很多需要细化没有涉及到的点

阿里面试官：小伙子，你给我说一下前后端分离的接口规范是什么？

1. 前言

随着互联网的高速发展，前端页面的展示、交互体验越来越灵活、炫丽，响应体验也要求越来越高，后端服务的高并发、高可用、高性能、高扩展等特性的要求也愈加苛刻，从而导致前后端研发各自专注于自己擅长的领域深耕细作。

然而带来的另一个问题：前后端的对接界面双方却关注甚少，没有任何接口约定规范情况下各自撸起袖子就是干，导致我们在产品项目开发过程中，前后端的接口联调对接
工作量占比在30%-50%左右，甚至会更高。往往前后端接口联调对接及系统间的联调对接都是整个产品项目研发的软肋。

本文的主要初衷就是规范约定先行，尽量避免沟通联调产生的不必要的问题，让大家身心愉快地专注于各自擅长的领域。

2. 为何要分离

目前现有前后端开发模式：“后端为主的MVC时代”，如下图所示：

代码可维护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。为了让 View 层更简单干脆，还可以选择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码。看起来是功能变弱了，但正是这种限制使得前后端分工更清晰。然而依旧并不是那么清晰，这个阶段的典型问题是：

1. 前端开发重度依赖开发环境，开发效率低。这种架构下，前后端协作有两种模式：一种是前端写demo，写好后，让后端去套模板 。淘宝早期包括现在依旧有大量业务线是这种模式。好处很明显，demo 可以本地开发，很高效。不足是还需要后端套模板，有可能套错，套完后还需要前端确定，来回沟通调整的成本比较大。另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发，支付宝是这种模式。 好处是 UI 相关的代码都是前端去写就好，后端不用太关注，不足就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因素。
2. 前后端职责依旧纠缠不清。 Velocity 模板还是蛮强大的，变量、逻辑、宏等特性，依旧可以通过拿到的上下文变量来实现各种业务逻辑。这样，只要前端弱势一点，往往就会被后端要求在模板层写出不少业务代码。还有一个很大的灰色地带是 Controller，页面路由等功能本应该是前端最关注的，但却是由后端来实现。 Controller 本身与 Model 往往也会纠缠不清，看了让人咬牙的业务代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养，否则 JSP 就够了。
3. 对前端发挥的局限。 性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。

总上所述，就跟為什麼要代碼重構一樣：

1. 关注点分离
2. 职责分离
3. 对的人做对的事
4. 更好的共建模式
5. 快速的反应变化

3. 什么是分离

我们现在要做的前后分离第一阶段：“基于 Ajax 带来的 SPA 时代”，如图：

这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。 看起来是如此美妙，但回过头来看看的话，这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。类似 Spring MVC，这个时代开始出现浏览器端的分层架构：

对于这一SPA阶段，前后端分离有几个重要挑战：

1. 前后端接口的约定。 如果后端的接口一塌糊涂，如果后端的业务模型不够稳定，那么前端开发会很痛苦。这一块在业界有 API Blueprint 等方案来约定和沉淀接口，==在阿里，不少团队也有类似尝试，通过接口规则、接口平台等方式来做。有了和后端一起沉淀的接口规则，还可以用来模拟数据，使得前后端可以在约定接口后实现高效并行开发。== 相信这一块会越做越好。

2. 前端开发的复杂度控制。 SPA 应用大多以功能交互型为主，JavaScript 代码过十万行很正常。大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情。典型的解决方案是业界的 Backbone，但 Backbone 做的事还很有限，依旧存在大量空白区域需要挑战。

4. 如何做分离

4.1 职责分离

1. 前后端仅仅通过异步接口(AJAX/JSONP)来编程
2. 前后端都各自有自己的开发流程，构建工具，测试集合
3. 关注点分离，前后端变得相对独立并松耦合

后端	前端
提供数据	接收数据，返回数据
处理业务逻辑	处理渲染逻辑
Server-side MVC架构	Client-side MV* 架构
代码跑在服务器上	代码跑在浏览器上

4.2 开发流程

1. 后端编写和维护接口文档，在 API 变化时更新接口文档
2. 后端根据接口文档进行接口开发
3. 前端根据接口文档进行开发 + Mock平台
4. 开发完成后联调和提交测试

Mock 服务器根据接口文档自动生成 Mock 数据，实现了接口文档即API：

4.3 具体实施

现在已基本完成了，接口方面的实施：

1. 接口文档服务器：可实现接口变更实时同步给前端展示；
2. Mock接口数据平台：可实现接口变更实时Mock数据给前端使用；
3. 接口规范定义：很重要，接口定义的好坏直接影响到前端的工作量和实现逻辑；具体定义规范见下节；

5. 接口规范V1.0.0

5.1 规范原则

1. 接口返回数据即显示：前端仅做渲染逻辑处理；
2. 渲染逻辑禁止跨多个接口调用；
3. 前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；
4. 请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现；

5.2 基本格式

5.2.1 请求基本格式

GET请求、POST请求==必须包含key为body的入参，所有请求数据包装为JSON格式，并存放到入参body中==，示例如下：

1. GET请求：

xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

2. POST请求：

5.2.2 响应基本格式

{
    code: 200,
    data: {
        message: "success"
    }
}

1. code : 请求处理状态

200: 请求处理成功

500: 请求处理失败

401: 请求未认证，跳转登录页

406: 请求未授权，跳转未授权提示页

2. data.message: 请求处理消息

code=200 且 data.message="success": 请求处理成功

code=200 且 data.message!="success": 请求处理成功, 普通消息提示：message内容

code=500: 请求处理失败，警告消息提示：message内容

5.3 响应实体格式

{
    code: 200,
    data: {
        message: "success",
        entity: {
            id: 1,
            name: "XXX",
            code: "XXX"
        }
    }
}

data.entity: 响应返回的实体数据

5.4 响应列表格式

{
    code: 200,
    data: {
        message: "success",
        list: [
            {
                id: 1,
                name: "XXX",
                code: "XXX"
            },
            {
                id: 2,
                name: "XXX",
                code: "XXX"
            }
        ]
    }
}

data.list: 响应返回的列表数据

5.5 响应分页格式

{
    code: 200,
    data: {
        recordCount: 2,
        message: "success",
        totalCount: 2,
        pageNo: 1,
        pageSize: 10,
        list: [
            {
                id: 1,
                name: "XXX",
                code: "H001"
            },
            {
                id: 2,
                name: "XXX",
                code: "H001"
            } ],
        totalPage: 1
    }
}

data.recordCount: 当前页记录数
data.totalCount: 总记录数
data.pageNo: 当前页码
data.pageSize: 每页大小
data.totalPage: 总页数

5.6 特殊内容规范

5.6.1 下拉框、复选框、单选框

由后端接口统一逻辑判定是否选中，通过isSelect标示是否选中，示例如下：

{
    code: 200,
    data: {
        message: "success",
        list: [{
            id: 1,
            name: "XXX",
            code: "XXX",
            isSelect: 1
        }, {
            id: 1,
            name: "XXX",
            code: "XXX",
            isSelect: 0
        }]
    }
}

禁止下拉框、复选框、单选框判定选中逻辑由前端来处理，统一由后端逻辑判定选中返回给前端展示；

5.6.2 Boolean类型

关于Boolean类型，JSON数据传输中一律使用1/0来标示，1为是/True，0为否/False；

5.6.3 日期类型

关于日期类型，JSON数据传输中一律使用字符串，具体日期格式因业务而定；

最后

欢迎大家关注我的公众号：前程有光，金三银四跳槽面试季，整理了1000多道将近500多页pdf文档的Java面试题资料，文章都会在里面更新，整理的资料也会放在里面。