【面试题】一个Http请求的流程

一、一个Http请求的流程（+4分）

DNS域名解析 –> 发起TCP的三次握手 –> 建立TCP连接后发起http请求 –> 服务器响应http请求，浏览器得到html代码 –> 浏览器解析html代码，并请求html代码中的资源（如javascript、css、图片等） –> 浏览器对页面进行渲染呈现给用户

举个例子在浏览器中输入www.baidu.com后执行的全部过程:
(1) 浏览器获取输入的域名www.baidu.com
(2) 浏览器向DNS请求解析www.baidu.com的IP地址
(3) 域名系统DNS解析出百度服务器的IP地址
(4) 浏览器与该服务器建立TCP连接(默认端口号80)
(5) 浏览器发出HTTP请求，请求百度首页
(6) 服务器通过HTTP响应把首页文件发送给浏览器
(7) TCP连接释放
(8) 浏览器将首页文件进行解析，并将Web页显示给用户。

涉及到的协议:
(1) 应用层：HTTP、DNS
(2) 传输层：TCP、UDP
(3)网络层：IP(IP数据数据包传输和路由选择)，ICMP(提供网络传输过程中的差错检测)，ARP(将本机的默认网关IP地址映射成物理MAC地址)

---

二、HTTP与HTTPS的特点和区别（+2分）

HTTP的协议和特点，与HTTPS的区别？

2.1、HTTP

Http协议是超文本传输协议，是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。特点主要有：

• 1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
• 2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• 3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• 4.无状态：HTTP协议是无状态协议。协议对于事务处理没有记忆能力。缺点：每次发送请求的时候都需要不断的重新传输数据。优点：server服务器只是作为应答，时效速度比较快。
  为了解决上述无状态的特性：可以使用cookie和session，来支持客户端和服务端的动态交互。
• 5、支持B/S及C/S模式。

2.2、HTTPS

2.2.1、https是什么

https 是 http over ssl(Secure Socket Layer)，简单讲就是 http 的安全版本，在 http 的基础上通过传输加密和身份认证保证了传输过程中的安全性。你通常访问的网站大部分都是 http 的，最简单的方法可以看看网址是以 http:// 开头还是 https:// 开头。
http 不安全，主要是因为它传输的是明文内容 , 也不对传输双方进行身份验证。只要在数据传输路径的任何一个环节上，都能看到传输的内容，甚至对其进行修改。例如一篇文章”攻下隔壁女生路由器后 , 我都做了些什么” 中，很多攻击的环节，都是通过分析 http 的内容来进行。而在现实生活中呢，你很有可能泄露你的论坛高级会员账号 / 密码，游戏 vip 账号 / 密码，隐私的聊天内容，邮件，在线购物信息，等等。
https 之所以安全，是因为他利用 ssl/tls 协议传输。

2.2.2、https 耗性能吗 ?

答案是，握手的时候耗，建好连接之后就不太耗了。按照目前加密强度的计算开销，服务器支撑握手性能会下降 6-8 倍，但是如果建立好连接之后，服务器就几乎可能撑住打满网卡的 https 流量了。所以连接复用率的提升和计算性能的优化都是重点。

2.2.3、什么是SSL（Secure Socket Layer）

SSL 由 Netscape 公司于1994年创建，它旨在通过Web创建安全的Internet通信。它是一种标准协议，用于加密浏览器和服务器之间的通信。它允许通过Internet安全轻松地传输账号密码、银行卡、手机号等私密信息。
SSL证书就是遵守SSL协议，由受信任的CA机构颁发的数字证书。
SSL/TLS的工作原理:
需要理解SSL/TLS的工作原理，我们需要掌握加密算法。加密算法有两种：对称加密和非对称加密：
对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是需要保护好密钥，如果密钥泄露的话，那么加密就会被别人破解。常见的对称加密有AES，DES算法。
非对称加密：它需要生成两个密钥：公钥(Public Key)和私钥(Private Key)。
公钥顾名思义是公开的，任何人都可以获得，而私钥是私人保管的。相信大多程序员已经对这种算法很熟悉了：我们提交代码到github的时候，就可以使用SSH key：在本地生成私钥和公钥，私钥放在本地.ssh目录中，公钥放在github网站上，这样每次提交代码，不用麻烦的输入用户名和密码了，github会根据网站上存储的公钥来识别我们的身份。
公钥负责加密，私钥负责解密；或者，私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA。

2.3、HTTPS的工作原理

https 的连接过程大概分为两个阶段，证书验证阶段和数据传输阶段

2.3.1、证书验证阶段

大概分为三个步骤

1. 浏览器发起请求
2. 服务器接收到请求之后，会返回证书，包括公钥
3. 浏览器接收到证书之后，会检验证书是否合法，不合法的话，会弹出告警提示（怎样验证合法，下文会详细解析，这里先忽略）

2.3.2、数据传输阶段

证书验证合法之后

1. 浏览器会生成一个随机数，
2. 使用公钥进行加密，发送给服务端
3. 服务器收到浏览器发来的值，使用私钥进行解密
4. 解析成功之后，使用对称加密算法进行加密，传输给客户端
   之后双方通信就使用第一步生成的随机数进行加密通信。

2.3.3、https 的加密方式是怎样的，对称加密和非对称加密，为什么要这样设计

从上面我们可以知道，https 加密是采用对称加密和非对称机密一起结合的。

在证书验证阶段，使用非对称加密。
在数据传输阶段，使用对称机密。

这样设计有一个好处，能最大程度得兼顾安全效率。

在证书验证阶段，使用非对称加密，需要公钥和私钥，假如浏览器的公钥泄漏了，我们还是能够确保随机数的安全，因为加密的数据只有用私钥才能解密。这样能最大程度确保随机数的安全。

在内容传输阶段，使用对称机密，可以大大提高加解密的效率。

2.3.4、内容传输为什么要使用对称机密

对称加密效率比较高
一对公私钥只能实现单向的加解密。只有服务端保存了私钥。如果使用非对称机密，相当于客户端必须有自己的私钥，这样设计的话，每个客户端都有自己的私钥，这很明显是不合理的，因为私钥是需要申请的。

2.3.5、https 是绝对安全的吗

不是绝对安全的，可以通过中间人攻击。

2.6、什么是中间人攻击

中间人攻击是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

HTTPS 使用了 SSL 加密协议，是一种非常安全的机制，目前并没有方法直接对这个协议进行攻击，一般都是在建立 SSL 连接时，拦截客户端的请求，利用中间人获取到 CA证书、非对称加密的公钥、对称加密的密钥；有了这些条件，就可以对请求和响应进行拦截和篡改。

一个通俗的例子
假设 Tom 想和 Jerry 交换一些秘密信息，然而 Tom 又不想跑到 Jerry 家里，于是 Tom 叫来了邮递员，给了邮递员一封信。信的内容是希望 Jerry 给 Tom 一个盒子（这个盒子有两把钥匙）和其中一把钥匙（另一把在 Jerry 手里）。
邮递员在拿到 Tom 给的信件以后，把 Tom 的信拆开看了一遍，了解到 Tom 希望 Jerry 给 Tom 一个有锁的盒子，又用另一个信封装了回去，并交给了 Jerry。
Jerry 在收到 Tom 的信（实际已经被邮递员拆阅过了）之后，给了邮递员一个有锁的盒子和其中一把钥匙。
邮递员想知道他们的通信内容，于是他把 Jerry 给 Tom 的盒子换成了他自己的盒子，并附上了自己盒子中的一把钥匙，并在之后将自己的盒子交给了 Tom。
Tom 在收到盒子之后，以为这个盒子是 Jerry 给他的，于是就把秘密的信件放进了盒子里，并把钥匙留下了，之后又交给了邮递员。
邮递员在拿到盒子之后，用自己的另一把钥匙打开盒子，看了里面的信件。之后将信件调换之后放进了 Jerry 给的盒子，交给了 Jerry。
Jerry 在拿到邮递员给他的盒子之后，并不知道这个盒子里的信件其实已经被邮递员调换过了，所以 Jerry 认为盒子里的信件是来自 Tom 且未被修改过的。之后 Jerry 把回信放进了盒子里，又交给了邮递员。
邮递员再次调换盒子里的信件，交给了 Tom。
这就是一个典型中间人攻击的过程。在 HTTPS 中，Tom 就是客户端，Jerry 是服务端，而邮递员就是客户端和服务端之间的任何实体（包括代理服务器、路由器、反向代理服务器等等），两把钥匙分别是公钥和私钥。通信双方并不知道（且通常很难发觉）自己其实在和中间人通信而非直接和对方通信。在通信过程中，Tom 和 Jerry 并没有验证对方的身份，这就导致了邮递员可以任意查看、修改或者丢弃双方的通信内容

2.7、https 是如何防止中间人攻击的

在https中需要证书，证书的作用是为了防止"中间人攻击"的。 如果有个中间人M拦截客户端请求,然后M向客户端提供自己的公钥，M再向服务端请求公钥,作为"中介者" 这样客户端和服务端都不知道,信息已经被拦截获取了。这时候就需要证明服务端的公钥是正确的.

怎么证明呢?

就需要权威第三方机构来公正了.这个第三方机构就是CA. 也就是说CA是专门对公钥进行认证，进行担保的，也就是专门给公钥做担保的担保公司。 全球知名的CA也就100多个，这些CA都是全球都认可的，比如VeriSign、GlobalSign等，国内知名的CA有WoSign。

2.8、浏览器是如何确保CA证书的合法性？

2.8.1、证书包含什么信息？

颁发机构信息、公钥、公司信息、域名、有效期、指纹…

2.8.2、证书的合法性依据是什么？

首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

2.8.3、浏览器如何验证证书的合法性？

浏览器发起HTTPS请求时，服务器会返回网站的SSL证书，浏览器需要对证书做以下验证：

验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；
判断证书是否被篡改。需要与CA服务器进行校验；
判断证书是否已吊销。通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与CA服务器的交互，提高验证效率。
以上任意一步都满足的情况下浏览器才认为证书是合法的

2.8.4、精简下HTTPS流程

1. 用户通过浏览器请求https网站，服务器收到请求，选择浏览器支持的加密和hash算法，同时返回 数字证书给浏览器，包含颁发机构、网址、公钥、证书有效期等信息。
2. 浏览器对证书的内容进行校验，如果有问题，则会有一个提示警告。否则，就生成一个随机数X， 同时使用证书中的公钥进行加密，并且发送给服务器。
3. 服务器收到之后，使用私钥解密，得到随机数X，然后使用X对网⻚内容进行加密，返回给浏览器
4. 浏览器则使用X和之前约定的加密算法进行解密，得到最终的网⻚内容

2.8.5、HTTPS可以抓包么

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。

但是，我们可以通过抓包工具来抓包。它的原理其实是模拟一个中间人。

通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

2.8.5.1、 HTTPS 不能防抓包，那 HTTPS 有什么意义？

HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解

2.8.5.2、如何防止抓包？

对于HTTPS API接口，如何防止抓包呢？既然问题出在证书信任问题上，那么解决方法就是在我们的APP中预置证书。在TLS/SSL握手时，用预置在本地的证书中的公钥校验服务器的数字签名，只有签名通过才能成功握手。由于数字签名是使用私钥生成的，而私钥只掌握在我们手上，中间人无法伪造一个有效的签名，因此攻击失败，无法抓包。

同时，为了防止预置证书被替换，在证书存储上，可以将证书进行加密后进行「嵌入存储」

2.8.6、SSLTrip 及 HSTS

在浏览器输入地址的时候都是直接输入 www.example.com 而非 https://www.example.com，在大部分情况下，如果一个网站启用了 HTTPS，服务器会将这个请求使用 301 或者 302 状态码以及一个 Location 头部将请求从 80 端口重定向至使用 HTTPS 的 443 端口。但是，如果中间人劫持了使用者的网络请求，那么中间人可以阻止客户端与服务器建立 HTTPS 连接，而是一直使用不安全的 HTTP 连接，而中间人则和服务器建立正常的 HTTPS 连接，让客户端以为自己正在和真实服务器通信。这种攻击手法称作 SSLTrip。

为了解决这个问题，IETF（互联网工程任务小组）引入了一个策略，叫做 HSTS (HTTP Strict Transport Security, HTTP 严格传输安全)。HSTS 的作用是强制客户端与服务端建立安全的 HTTPS 连接，而非不安全的 HTTP 连接。如果一个站点启用了 HSTS 策略，那么客户端在第一次与该站点建立连接之后，在未来的一段时间内（由一个 HTTP 头部控制，这个头部为：Strict-Transport-Security），客户端与该站点的所有连接都会直接使用 HTTPS，即使客户端访问的是 HTTP，也会直接在客户端重定向到 HTTPS 连接。

假设 https://example.com 的响应头部含有 Strict-Transport-Security: max-age=31536000; includeSubDomains，这意味着：

在未来的 1 年时间里（即 31536000 秒中），只要浏览器向 example.com 或者其子域名发送请求，必须采用 HTTPS 来发起连接。即使用户在地址栏里写的是 http://example.com，那也直接重写为 https://example.com 并直接发起 HTTPS 连接。
在接下去的一年中，如果服务器提供的 HTTPS 证书无效（不论是域名对不上还是自签名还是不在有效期内），用户都无法访问该站点。
如果站点没有启用 HSTS，用户可以忽略证书无效的警告，继续建立连接，而如果站点启用了 HSTS，那么用户即使想冒风险，浏览器也不会继续访问。

HSTS 可以很大程度上防止 SSLTrip 攻击，不过这样还是有个问题，那就是要启用 HSTS，浏览器至少要和服务器建立一次 HTTPS 连接，如果中间人一直阻止浏览器与服务器建立 HTTPS 连接，那么 HSTS 就失效了。解决这个问题有个办法，那就是将 HSTS 站点列表内置到浏览器中，这样只要浏览器离线判断该站点启用了 HSTS，就会跳过原先的 HTTP 重定向，直接发起 HTTPS 请求

三、TCP耗时的三次握手原理和四次挥手，以及为什么三次握手和为什么四次挥手？（+2分）

首先我们明确：TCP标志位有6种标示，即：SYN(建立联机) 、 ACK(确认) 、 PSH(传送) 、 FIN(f结束) 、 RST(重置) 、 URG(紧急) 、 Sequence number(顺序号码) 、 Acknowledge number(确认号码)

3.1、三次握手

为了准确无误的将数据发送到指定IP处，TCP协议采用了三次握手的策略，如下步骤所示：
1、客户端采用TCP协议将带有SYN标志的数据包发送给服务器，等待服务器的确认。
2、服务器端在收到SYN的数据包后，必须确认SYN，即自己发送的ACK标志，同时，自己也将会向客户端发送一个SYN标志。
3、客户端在接收到服务器短的SYN+ACK包后，自己会向服务器发送ACK包，完成三次握手。那么客户端和服务器正式建立了连接，开始传输数据。

3.2、四次挥手

四次挥手是用来断开服务器和客户端之间的通信的，之所以要断开连接，是因为TCP/IP 协议是要占用端口号的，而计算机的端口却是有限的，不进行断开的话，势必会造成计算机资源的浪费。
1、在整个通信的过程中，谁先发起请求，谁就是客户端。
当客户端的数据传输到尾部时，客户端向服务器发送带有FIN标志的数据包，使其明白自己准备断开通信了。
2、因为TCP的通信是使用全双工通信的WebSocket，所以在断开连接的时候也应该是双向的；当服务器收到带有FIN标志的数据包时，其必不会直接发送FIN标志断开通信的请求，而是先发送一个带有ACK标志的应答信息，使客户端明白服务器还有数据要进行发送。
3、当 服务器的数据发送完成后，向客户端发送带有FIN标志的数据包，通知客户端断开连接。
4、这一次挥手是我觉得四次挥手中设计的最巧妙的一次。
当客户端收到FIN后，担心网络上某些不可控制的因素导致服务器不知道他要断开连接，会发送ACK进行确认，同时把自己设置成TIME_WAIT状态并启动定时器，在TCP的定时器到达后客户端并没有接收到请求，会重新发送；当服务器收到请求后就断开连接；当客户端等待2MLS（两倍报文最大生存时间）后，没有收到请求重传的请求后，客户端这边就断开连接，整个TCP通信就结束了。

3.2.1、注：三次握手为什么不能改成两次握手？

解：三次握手中的每一次都是必须的。如果是两次握手，在第二次结束后，服务器并不能保证客户端已经收到了第二次的请求，如此一来的话，服务器会一直保存着这个通信过程，因为TCP通信都是要占用端口的，造成了一定的资源浪费。所以，就一定要让客户端来发送ACK的确认请求。

3.2.2、注：关闭的时候为什么会是四次挥手？

解：四次挥手不能像三次握手一样，三次握手可以将ACK+SYN 一起发送，ACK用于确认信息，SYN却是用来建立联机的；四次挥手中ACK是不能和FIN一起发送，ACK只是告诉客户端确认我收到了，等我将数据发送完毕之后会向其发送FIN的标志，所以四次挥手是不能够改变的。

3.2.3、注：为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
1.为了保证连接的可靠关闭。如果server没有收到最后一个ACK，那么就会重发FIN。
2. 为了避免端口重用带来的数据混淆。如果client直接进入CLOSED状态，又用相同端口号向server建
立一个连接，上一次连接的部分数据在网络中延迟到达server，数据就可能发生混淆了。

四、TCP和UDP的区别（+1分）

4.1、TCP

TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。

TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击

4.2、UDP

UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击……

UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。

4.3、应用场景

基于上面的优缺点，各自应用场景：

• 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 …………
• 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……

4.4、TCP怎么保证传输过程的可靠性

校验和:
发送方在发送数据之前计算校验和，接收方收到数据后同样计算，如果不一致，那么传输有
误。
确认应答，序列号:
TCP进行传输时数据都进行了编号，每次接收方返回ACK都有确认序列号。
超时重传:
如果发送方发送数据一段时间后没有收到ACK，那么就重发数据。
连接管理:
三次握手和四次挥手的过程。
流量控制:
TCP协议报头包含16位的窗口大小，接收方会在返回ACK时同时把自己的即时窗口填入，发 送方就根据报文中窗口的大小控制发送速度。
拥塞控制:
刚开始发送数据的时候，拥塞窗口是1，以后每次收到ACK，则拥塞窗口+1，然后将拥塞窗口 和收到的窗口取较小值作为实际发送的窗口，如果发生超时重传，拥塞窗口重置为1。这样做的目的就是 为了保证传输过程的高效性和可靠性。

五、DNS具体解析原理（+1分）

5.1、DNS基本工作原理

DNS(Domain Name System) 是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于 TCP/IP 网络，它从事将主机名或域名转换为实际 IP 地址的工作。DNS 就是这样的一位“翻译官”，它的基本工作原理可用下图来表示

• 在浏览器中输入 www.qq.com 域名，操作系统会先检查自己本地的 hosts 文件是否有这个网址映射关系，如果有就先调用这个 IP 地址映射完成域名解析。
• 如果 hosts 里没有这个域名的映射，则查找本地 DNS 解析器缓存是否有这个网址映射关系，如果有直接返回，完成域名解析。
• 如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系，首先会找 TCP/IP 参数中设置的首选 DNS 服务器，在此我们叫它本地 DNS 服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
• 如果要查询的域名，不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析，此解析不具有权威性。
• 如果本地 DNS 服务器本地区域文件与缓存解析都失效，则根据本地 DNS 服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地 DNS 就把请求发至 “根 DNS 服务器”，“根 DNS 服务器”收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个 IP。本地 DNS 服务器收到 IP 信息后，将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后，如果自己无法解析，它就会找一个管理 .com 域的下一级 DNS 服务器地址 (qq.com) 给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后，就会找 qq.com 域服务器，重复上面的动作，进行查询，直至找到 www.qq.com 主机。
• 如果用的是转发模式，此 DNS 服务器就会把请求转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转请求转至上上级，以此循环。不管是本地 DNS 服务器用是是转发，还是根提示，最后都是把结果返回给本地 DNS 服务器，由此 DNS 服务器再返回给客户机。
  

5.2、对应四层架构是如何解析的？

1. 首先通过DNS服务器把域名解析成IP地址，通过IP和子网掩码判断是否属于同一个子网
2. 构造应用层请求http报文，传输层添加TCP/UDP头部，网络层添加IP头部，数据链路层添加以太网
   协议头部
3. 数据经过路由器、交换机转发，最终达到目标服务器，目标服务器同样解析数据，最终拿到http报 文，按照对应的程序的逻辑响应回去。
   

5.3、如何通俗易懂的表达出来整个过程让小白用户，或者你的女朋友能理解。

普通的上网过程，系统其实是这样做的：浏览器本身是一个客户端，当你输入URL的时候，首先浏览器会去请求DNS服务器，通过DNS获取相应的域名对应的IP，然后通过IP地址找到IP对应的服务器后，要求建立TCP连接，等浏览器发送完HTTP Request（请求）包后，服务器接收到请求包之后才开始处理请求包，服务器调用自身服务，返回HTTP Response（响应）包；客户端收到来自服务器的响应后开始渲染这个Response包里的主体（body），等收到全部的内容随后断开与该服务器之间的TCP连接。
一个Web服务器也被称为HTTP服务器，它通过HTTP协议与客户端通信。这个客户端通常指的是Web浏览器(其实手机端客户端内部也是浏览器实现的)。

Web服务器的工作原理可以简单地归纳为：
客户机通过TCP/IP协议建立到服务器的TCP连接
客户端向服务器发送HTTP协议请求包，请求服务器里的资源文档
服务器向客户机发送HTTP协议应答包，如果请求的资源包含有动态语言的内容，那么服务器会调用动态语言的解释引擎负责处理“动态内容”，并将处理得到的数据返回给客户端
客户机与服务器断开。由客户端解释HTML文档，在客户端屏幕上渲染图形结果
一个简单的HTTP事务就是这样实现的，看起来很复杂，原理其实是挺简单的。需要注意的是客户机与服务器之间的通信是非持久连接的，也就是当服务器发送了应答后就与客户机断开连接，等待下一次请求。

参考资料：

• https安全么
• HTTPS中间人攻击和防范