|
1. 前言互联网行业因为广为人知的高薪以及相对于传统工科行业更多的发展机会，最近几年涌入了越来越多的非计算机专业毕业的从业人员，校招 / 社招面试的时候，候选人往往也会被分为两种：科班和非科班，互联网科班一般特指大学就读计算机科学与技术或者软件专业，非科班则包含其他各大传统工科甚至是文科专业。 某些大厂在招聘后端开发工程师时会严格要求科班背景，因为对于非科班的同学，一般都能胜任计算机网络应用层以上的工作（例如编写一个低并发的后台管理系统），但是对于计算机底层的知识往往是一片盲区。当对计算机网络了解甚少的非科班同学遇到线上问题时，或者网络通信相关的运维故障，往往会束手无策。 所以了解计算机底层如何运作是非常有必要的，我们这里谈到的计算机底层知识，包括但不限于：
从本小节开始，我们会开始学习计算机网络相关的面试题目，并且在熟悉题目的同时，掌握计算机网络的基本知识框架。 2. 计算机网络如何分层面试官提问： 你了解计算机网络的分层模型吗？其中每一层有哪些常见的协议？ 题目解析： 这个题目需要拆分为两个关键点分析： （1）计算机网络是如何分层的？阐述 OSI 七层协议和通用五层协议的区别。（2）分层后的每一层支持哪些协议？主要会涉及到后端开发过程中常用的协议。 2.1 分层模型总览
首先，我们都知道最基础的分层协议是计算机网络 OSI（Open System Interconnection）体系。OSI 模型如上图（a）所示，网络结构被拆分为 7 层，自顶向下分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。但是 OSI 模型是一种概念模型，虽然理论比较完整，并不实用。 TCP/IP 体系如上图（c）所示，包含了应用层、传输层、网络层以及网络接口层，不过我们一般关注上面三层的内容，最下层及网络接口层没有实质性的协议。TCP/IP 体系分层就是我们实际应用中的网络协议。 作为 OSI 七层协议和 TCP/IP 四层协议的折中，还有一种是五层协议的体系，往往是面试中考察的重点。 五层协议，如上图中（b）所示，自顶向下分为应用层、传输层、网络层、数据链路层以及物理层，下面我们将详细阐述每层的作用以及代表协议。 2.2 分层定义以及常见协议在画出了计算机网络的分层模型之后，我们还需要向面试官解释每一层的定义以及介绍常见的协议。 2.2.1 应用层应用层（Application Layer）是 5 层协议的顶层，顾名思义，应用层的作用是通过操作系统中应用进程（例如电子邮件、浏览器文件传输）提供网络交互。 应用层最常被问到的是 HTTP 协议和 DNS 域名解析协议（在之后的小节我们会详细讲解相关题目），其次还有一些后端开发过程中可能会接触的协议，例如支持文件传输的 FTP 协议（例如需要从 Windows 开发机传输文件到 Linux 服务器时使用），以及支持电子邮件的 SMTP 协议（例如需要开发电子邮件读写的相关爬虫时需要开放邮箱的 SMTP 协议）。 2.2.2 传输层传输层（Transport Layer）主要是为了实现端口到端口（port to port）的通信，计算机的不同进程都会被分配不同的端口，例如域名默认的 80 端口。从接收和发送信息的角度可以分为两大功能：
传输层涉及到两个常见的协议，几乎是面试必考协议：
2.2.3 网络层计算机之间的通信可以分为位于同一个子网络（也就是局域网，Local Area Network）和位于不同的子网络（广域网，Wide Area Network），网络层协议解决的问题就是如何判断两台计算机是否属于同一个子网络中。
2.2.4 数据链路层数据链路层（Data-Link Layer）位于物理层和网络层之间，对于两个不同主机之间的数据传输，可能会经过多个路由器中转，中间的这条链路就是我们关注的重点，我们把两个主机抽象为两个点，链路层协议解决的问题就是 "点对点" 的数据传输。 数据链路层将网络层交付的 IP 数据包封装成帧（Frame），其中每一帧包括了数据以及必要的控制信息（比如同步信息、寻址信息、差错控制信息），这种设计方案非常类似 TCP 协议中的控制位（由此也能看出计算机网络设计的互通性）。如果通过差错控制信息校验出了错误，那么就会在本层丢弃这个帧，纠正错误是通过网络层的 TCP 协议完成。 PPP 协议（Point to Point Protocol）：在两个点之间传输数据包的协议，因为本层涉及的协议在面试中考察甚少，基本可以只做简单了解。 2.2.5 物理层物理层（Physical Layer）是 5 层协议模型中最底层的协议，就是通过物理手段（例如网线，电缆）将计算机连接起来，提供信息传输的物理媒介，数据由 0 和 1 二进制信号构成，传输单元是比特位。因为关于物理层的研究更偏向于通信相关的原理，我们只需要了解本层的定义即可。 3. 小结本节给大家讲解了掌握计算机底层知识的重要性，以及对计算机网络 OSI 协议模型和五层协议模型进行了拆分讲解，主要关注点在于应用层以及传输层的相关协议。 1. 前言无论是作为后端开发、前端开发、测试开发程序员或者是运维人员，在面试过程中，大概率都会被问到 HTTP 协议相关题目。 因为伴随着 2010 年之后移动互联网在全世界的高速发展，各种各样的浏览器（Chrome、FireFox、Safari 等）层出不穷，也诞生了诸多服务端开发的语言（例如 Golang 语言），浏览器和服务端之间的交互是不可避免的，我们对于不同的浏览器和不同的服务端，总不能每次都创建一种新的交互协议，所以需要确定统一的协议规范，也就是本文的 HTTP 协议。 2.1 HTTP 协议定义面试官提问： 什么是 HTTP 报文？什么是 HTTP 报文？ 题目解析： 首先，我们给出 HTTP 的定义：HTTP（HyperText Transfer Protocol，超文本传输协议）是一个请求 - 响应（Request to Response）协议，位于网络模型的应用层，基于传输层的 TCP 协议。
(HTTP 请求 - 响应模型) 其次，HTTP 报文是在客户端和服务器端传输的数据报文，由起始行（Start Line）、请求头部（Request Header）和请求主体（Request Body）构成，从类型上分为请求报文（Request Message）和响应报文（Response Message）。
2.2 HTTP 请求方法面试官提问： HTTP 协议的请求方法有哪些，有啥区别？ 题目解析：
除此之外，HTTP 协议还有 TRACE、CONNECT 等方法，但是在日常开发中基本不会用到，所以不用关注。 面试官常常会将 POST 和 GET 方法进行对比，我们需要注意以下几个不同： （1）GET 请求主要是为了从服务器获取资源，POST 请求主要是为了向服务器发送资源。 （2）GET 请求是通过 URL 传参，形式是 （3）GET 请求传输的信息量少，POST 请求能够传输的信息量多。 （4）GET 请求参数在 URL 明文，容易被爬虫直接获取，POST 请求参数不直接可见，安全性更高，例如在表单提交密码时，必须使用 POST 请求。 2.3 HTTP 状态码面试官提问： 请枚举一些常见的 HTTP 状态码，并且说明作用。 题目解析： 首先我们从性质上分类，HTTP 的响应状态码总共有 1XX 到 5XX 五种类型，关于每种状态码的定义：
对于 4XX 开头的错误码，都是因为客户端自身的原因产生，例如我们输入 URL: 对于 5XX 开头的错误码，都是因为服务器处理过程中遇到异常产生，例如后端开发程序员在处理 HTTP 请求的过程触发了 Exception，导致响应失败。 在定性之后，面试官大概率还要抽出几个常见的状态码，考察其具体的含义，我们对常见的状态码也需要进行总结：
这里需要分区开 301 和 302 错误码（也是常见考点），从字面意思上看，301 和 302 都代表某个 URL 被转移了，区别在于： （1）301 表示资源被永久转移了，搜索引擎（例如百度的爬虫）在爬取网站的时候会抓取新网站的内容并且保留新网站的 URL。 （2）302 表示资源被临时转移了，也就是临时重定向，搜索引擎在爬取网站的时候会抓取新的内容，但是保留旧网站作为 URL。 3. 小结HTTP 协议应该是前端、后端、测试开发人员最常接触的网络协议了，因为这是网站和用户之间传输信息的直接渠道。面试官考察 HTTP 相关的问题，也是为了了解候选人的开发基本功，为了熟悉本小结的知识，大家也可以了解下发送 HTTP 的 Postman 开发工具，以及 HTTP 网络抓包的 Wireshark 工具。 1. 前言TCP 和 UDP 协议是计算机网络的重要组成协议，两者经常被拿来比较，其中 TCP 协议往往会被面试官深入考察。 本节课程将和大家一起学习传输层的 TCP 和 UDP 协议。通过本节课程，你会了解到 TCP 和 UDP 协议的区别，重点是要掌握 TCP 协议的三次握手过程以及三次握手的必要性。 2.1 TCP 和 UDP面试官提问： TCP 协议和 UDP 协议有什么区别？有什么共同点？ 题目解析： 相同点：两个协议最大的共同点是都位于 TCP/IP 网络模型的传输层。 不同点：我们通过表格的形式对比不同。
根据表格中的特点对比我们可以总结得到： 面试官提问： 上述你提到了 UDP 和 TCP 报文，它们的具体结构是怎样的？ 题目解析： 在上个题目中我们总结了 TCP 协议和 UDP 协议的不同点，其中谈到了 TCP 和 UDP 协议首部格式不同，接下来分别画图分析。
如上图可见，UDP 首部只有 8 个字节的数据，包括源端口号、目标端口号、长度以及校验和。
在画完了示意图之后，关于 TCP 报文首部，我们需要解释的字段：
上述定义中，序号、确认号以及 ACK、SYN 和 FIN 标志位是我们需要重点关注的部分，因为在 TCP 建立连接和断开连接时会涉及到。 2.3 TCP 三次握手面试官提问： TCP 是如何建立连接的？分析下每个步骤传输了什么样的数据？ 题目解析：
（TCP 三次握手过程） 首先从行为上分析，TCP 建立连接需要发送三次报文，也就是 "三次握手" 的过程。 我们定义发送报文的一方是客户端，接收报文的一方是服务器端。 首先服务器端处于监听（LISTEN）的状态，否则不会收到客户端发来的请求。 （1）第一次握手：客户端往服务器端发送一个请求建立连接报文，报文首部 SYN 标志位 = 1，给定一个初始的 Seq 序号 x。之后客户端进入 SYN_SEN（同步发送）状态； （2）第二次握手：服务器端收到请求报文，如果同意建立连接，则向客户端发送确认报文。确认报文中 SYN 标志位 = 1，ACK 标志位 = 1，同时给定一个 Seq 序号 y，Ack 确认号 x+1，之后服务器端进入 SYN_RCVD（同步已发送）状态； （3）第三次握手：客户端收到来自服务器端的确认报文之后，还需要向服务器端发送确认报文，报文首部 ACK 标志位 = 1，Ack 确认号为 y+1，发送之后客户端进入 ESTABLISHED（已建立连接）的状态。服务器端收到确认报文后，也会进入 ESTABLISHED 状态，在此之后，客户端和服务器端可以开始 TCP 通信了。 2.4 TCP 三次握手的必要性2.4.1 三次握手的意义面试官提问： TCP 建立连接为什么需要三次握手？可以只有两次握手吗？第三次握手有什么意义？ 题目解析： 紧接上面一个问题，如果我们能够成功画出 TCP 三次握手的过程，以及分析每个过程传输报文的首部内容，那么面试官大概率会抛出这样一个问题，考察我们对 TCP 三次握手的理解。 首先从定性角度来看，分析三次握手每个步骤的意义： （1）第一次握手：客户端发送报文，服务器端接收报文，如果成功接收，说明客户端的发送能力、服务器端的接收能力符合预期； （2）第二次握手：服务器端发送报文，客户端接收报文，如果成功接收。从客户端的角度来看：客户端的发送和接收能力符合预期，服务器端的发送和接收能力符合预期，可以建立连接。但是从服务器端的角度来看：客户端的发送能力符合预期（第一次握手），服务器端的接收能力符合预期（第二次握手），但是因为收不到客户端的反馈（无法获知第二次握手的报文是否成功抵达客户端），那么只能得出服务器端的发送能力和客户端的接收能力不一定符合预期的结论； （3）第三次握手：客户端发送报文，服务器端接收报文，如果接收成功，从服务器端的角度来看：客户端的报文接收能力以及服务器端的报文发送能力都符合预期。 经过三次握手的过程，客户端和服务器端都明确对方以及自己能成功接收和发送信息，所以就可以开始正常通信。 2.4.2 假设如果只有两次握手过程，是否能顺利建立 TCP 连接？
如果 TCP 只有两次握手，如果服务器端发送的第一个请求建立连接的报文在某个网络节点长时间阻塞，等到连接释放之后才抵达服务器端。本来这是一个早就失效的报文，但是服务器端收到这个失效的请求建立连接报文之后，会误以为是客户端需要建立一个新的连接请求，于是向客户端发送 ACK 确认报文，同意建立连接，这时候因为已经完成了两次握手，所以新的连接就会建立成功，这种情况显然不符合预期。 如果是三次握手，客户端不会向服务器端发送 ACK 确认报文，所以服务器端超过最长等待时间后，会认为客户端没有要求建立请求，这个无效报文最终会失效。 3. 小结本章节给大家介绍了 TCP 和 UDP 协议的报文格式以及区别，分析了 TCP 建立连接的握手过程，需要大家能够准确画出 TCP 握手每个过程的标志位以及序号、确认号，并且从原理上理解三次握手的必要性，下一章节会继续给大家分析 TCP 四次挥手过程。 1. 前言上一章节分析了 TCP 建立连接的过程，既然有建立连接，对应的也有断开连接。数据传输完成之后，客户端和服务器端保持通信状态会占用资源开销，所以需要断开连接，TCP 协议中断开连接也被称为 TCP 四次挥手。 2.1 TCP 四次挥手面试官提问： 说明一下 TCP 断开连接的过程，涉及到了几个步骤？ 题目解析：
（TCP 四次挥手过程） 首先从行为上分析，TCP 断开连接总共需要发送四次报文，也就是 "四次挥手" 的过程。 我们定义发送报文的一方是客户端，接收报文的一方是服务器端。 上一章节中已经对三次握手过程做出了分析，在建立连接后到传输数据的整个过程，客户端和服务器端均处于 ESTABLISHED（监听）状态，之后四次挥手的过程如下：（1）第一次挥手：客户端发送一个请求结束报文，其中 FIN 标志位设置为 1，报文中给定一个序列号 u，报文内容是 （2）第二次挥手：服务器端收到 FIN 报文，会发送 ACK 确认报文，并且把客户端发送的序列号加一作为确认报文的确认号，表示已经收到了客户端的报文，所以报文内容是 客户端收到第二次挥手的报文后，会进入 FIN_WAIT_2（等待结束）状态，等待服务器发送最后的终止连接报文； （3）第三次挥手：服务器端把最后的数据发送之后，就开始向客户端发送请求结束报文，FIN 标志位设置为 1，确认号设置为 u+1，比较特殊的一点是报文中 ACK 标志位也是 1，报文内容是 （4）第四次挥手：客户端收到服务器的请求断开连接报文后，必须还要发出一个确认报文，ACK 标志位设置为 1，并且序列号同上一报文的确认号，确认号同上一报文的序列号加一，报文内容是 服务器端在收到客户端的第四次挥手报文后，立即进入 CLOSED（关闭）状态，表示结束本次 TCP 连接。 在向面试官分析整个流程的时候，我们可以将四次报文中的第一次和第二次看作一个整体，即是客户端发送请求结束报文以及收到对应响应。第三次和第四次又是一个整体，即服务器端发送请求结束报文并且收到客户端的响应。 2.2 为什么建立连接是三次握手，断开连接需要四次挥手面试官提问： 为什么 TCP 建立连接只需要三次握手，而 TCP 断开连接需要四次握手？ 题目解析： 关于 TCP 建立连接三次握手的必要性，我们已经在上一章节进行了分析，这里不再赘述，这里分析下四次握手的必要性。 前置说明：TCP 是双向通信的协议，客户端可以发送和接收数据，服务器端也可以发送和接收数据，也就是全双工通信模式。 第一次挥手时，服务器端收到了客户端的 FIN 请求结束报文，但是因为应用层的进程可能还需要传输一些数据，不能立即关闭 SOCKET，所以只能先给客户端发送一个 ACK 确认报文，让客户端有 "心理准备"。之后服务器端进入 CLOSE_WAIT 状态，这个状态是为了处理最后的一些数据，等待这些数据也传输完毕之后，服务器端再发送 FIN 请求结束报文，到这里就已经有三次挥手的步骤了。最后，因为服务器端也需要感知第三次挥手的报文是否成功传输到客户端，所以客户端还需要第四次挥手的报文，来作为确认。 2.3 TIME_WAIT 状态面试官提问： 第四次挥手之后，客户端进入的 TIME_WAIT 状态是什么含义？有什么限制？ 题目解析： 在候选人成功向面试官阐述了四次挥手的过程细节以及四次的必要性之后，面试官大概率会针对 TIME_WAIT 这个状态发出提问。 我们将这个问题拆解开来，分步分析： （1）TIME_WAIT 状态的开始时间：TCP 连接中主动关闭连接的一方（一般看作客户端）发送完最后一次挥手，主动关闭方就进入 TIME_WAIT 状态。 （2）TIME_WAIT 的持续时间：TIME_WAIT 的时间是 2*MSL（Maximum Segment Lifetime），即两个最大数据段生命周期。 （3）TIME_WAIT 为什么要持续 2*MSL 这么长的时间： ① 防止丢失报文导致异常：客户端发送的最后一个 ACK 报文可能丢失，服务器端收不到响应则会发送第三次挥手的超时重传报文，我们假设客户端没有 TIME_WAIT 状态，而是直接进入 CLOSED 状态，则会收到非法的报文段，返回一个 RST（拒绝连接）的报文，产生异常。 ② 防止报文在网络中停止影响下次建立连接：MSL 表示报文在网络中的最大传输时间，等待 2*MSL 可以让网络中的所有旧报文段都失效，下一次重新三次握手时就不会收到无效的报文段。 3. 小结本章节给大家分析了 TCP 关闭连接的过程以及常见提问，需要大家能够在白纸上画出 TCP 四次挥手的每个流程，并且重点关注 TIME_WAIT 这个状态。 1. 前言在上一章节中我们介绍了 HTTP 协议相关的面试题目，作为 HTTP 协议的扩展，HTTPS 协议也经常被面试官提起。 因为对于大部分的前端、后端开发者，都接触不到 HTTPS 协议的开发场景，因为我们往往只关注请求路径后缀，例如关注 URL： 2.1 HTTP 和 HTTPS 协议** 面试官提问：** 为什么有了 HTTP 协议后还出现了 HTTPS 协议？HTTPS 协议解决了什么问题？ 题目解析： 在研究 HTTPS 协议之前，我们先总结下 HTTP 协议的优点和缺点：
如上表所示，HTTP 协议牺牲了安全性，换来了效率，但是在某些安全性要求高的场景，使用 HTTP 协议是不合适的。 HTTP 协议的全称是 Hypertext Transfer Protocol，HTTPS 协议的全程是 Hypertext Transfer Protocol Secure，多了一个 Secure（安全）的限制词。从协议上看，HTTPS 协议基于 HTTP 协议，使用 SSL/TLS 协议对传输内容进行加密，从公式上定义： HTTPS 协议将 HTTP 协议的通信部分由 SSL 或者 TLS 协议替代，网络模型划分如下：
除了 SSL 协议以外，HTTPS 协议还涉及几个重要的概念：CA 证书、混淆加密方式，以及 HTTPS 协议具体的工作流程，下面我们拆分解释。 2.2 对称加密和非对称加密算法** 面试官提问：** 既然 HTTPS 协议对通信内容进行了加密，那么涉及到了什么加密算法？ 题目解析： HTTPS 协议的核心是加密流程，首先我们需要区分三种加密方式：对称加密、非对称加密以及混淆加密。 （1）对称加密：加密方和解密方都使用了相同的密钥，只要保证密钥不会泄露给第三方， 整个通信过程就是安全的。
因为对称加密算法整个过程共享同一个密钥，所以使用特点也比较明显。 优点：算法简单，加密速度快； 缺点：安全性低，如果密钥泄露，密文也被中间人拦截，那么信息很容易就会被破解。 在企业生产环境下，常用的对称加密算法有 AES 算法。 （2）非对称加密：在安全性要求更高的场景下，我们需要使用非对称加密，关于非对称加密算法的流程如下：
首先定义两种密钥：一种是公钥（Public Key），给任何需要和接收方通信的客户端保存；另一种是私钥（Private Key），只给接收方自己保存。 对于要发送的原文文本，发送方通过接收方的公钥对内容加密，加密后的内容只有接收方的私钥可以解密。在整个传输过程中，如果发送方的公钥泄露，加密内容也被窃取，也不会导致传输内容被破解（只要接收方的私钥没有泄露）。 常见的非对称加密算法有 RSA 算法（即一种支持变长密钥的公共密钥算法）。 另外，面试官可能会提出 MD5 算法的划分，MD5 是非常常见的加密算法，例如在保存用户密码时经常被使用。但是要区分的是，MD5 算法不是对称和非对称算法，MD5 算法不可逆，主要目的是为了文件校验（例如判断文件是否在传输过程中损坏），或者数字签名等途径。 3. 小结本小节主要给大家简单说明了 HTTPS 协议和传统 HTTP 协议的区别，另外给出了对称加密和非对称加密算法的流程，我们需要掌握不同加密算法的特点，在下一章节中会给大家介绍 HTTPS 协议的具体流程。 1. 前言上一章节中我们主要就 HTTPS 协议的前置知识进行介绍，下面会继续介绍 HTTPS 的通信过程以及抛出一些常见问题的探讨。因为候选人准备面试的时间和精力是比较有限的，我们在学习的过程要抓住重点，如果感觉对于细节缺乏了解，可以通过维基百科和查阅 StackOverflow 等方式进行自行补充。 2. HTTPS 协议2.1 HTTPS 请求流程面试官提问： HTTPS 的请求流程和 HTTP 协议的请求流程有什么区别？ 题目解析： 参考 HTTPS 的官方文档，我们将整个请求的流程简单抽象为以下几个步骤，抓住其中的核心步骤：
1. 前言虽然计算机网络是后端开发过程中必须要接触的模块，但是计算机网络相关的面试题大多都偏向理论，为了更好的理解在开发过程中计算机网络交互的作用，本小节会介绍一道网络相关的高频整合题目。 2. 在浏览器输入了一个 URL 后发生了什么面试官提问： 当你在浏览器中输入了一个网址URL，例如 1. 前言虽然计算机网络是后端开发过程中必须要接触的模块，但是计算机网络相关的面试题大多都偏向理论，为了更好的理解在开发过程中计算机网络交互的作用，本小节会介绍一道网络相关的高频整合题目。 2. 在浏览器输入了一个 URL 后发生了什么面试官提问： 当你在浏览器中输入了一个网址URL，例如 2.1 DNS域名解析题目解析：输入 URL 之后，浏览器做的第一件事情就是 DNS 域名解析。 在之前的小节，我们分析五层网络模型时就知道了数据链路层传输的帧，并不是通过字符串 “http://imooc.com” 寻找到目标主机，而是通过 MAC 地址找到目标主机的硬件地址，要通过 ARP 协议解析获取 MAC 地址，我们需要目标主机的 IP 地址，所以问题是如何通过域名获取对应 IP 地址。 所以第一个步骤，我们需要获取域名对应的IP地址，会经过以下几个步骤： 2.1 DNS域名解析题目解析：输入 URL 之后，浏览器做的第一件事情就是 DNS 域名解析。 在之前的小节，我们分析五层网络模型时就知道了数据链路层传输的帧，并不是通过字符串 “http://” 寻找到目标主机，而是通过 MAC 地址找到目标主机的硬件地址，要通过 ARP 协议解析获取 MAC 地址，我们需要目标主机的 IP 地址，所以问题是如何通过域名获取对应 IP 地址。 所以第一个步骤，我们需要获取域名对应的IP地址，会经过以下几个步骤： （1）访问 Hosts 文件浏览器会首先查看本机的 Hosts 文件，是否已经存在映射关系。Hosts文件是用来存储常用的域名和对应IP地址关系的关联文件，例如在Hosts文件中存储了 （2）访问本地缓存如果 Hosts 文件中不存在映射关系，浏览器（例如Chrome）会再查看浏览器本地的缓存，是否存在映射关系。 （3）访问 DNS 服务器
DNS 解析的过程简单来看，是从"我的电脑"传输域名
步骤（1）：浏览器会向本地 DNS 服务器发送域名报文。 步骤（2）：本地 DNS 接收报文之后，会将请求转发到根 DNS 服务器。 步骤（3）：根 DNS 服务器通过 步骤（4）：本地 DNS 服务器带着域名访问IP： 步骤（5）：com 顶级域名服务器根据后缀 步骤（6）：本地 DNS 服务器带着域名访问IP 步骤（7）：二级域名服务器通过 步骤（8）：本地 DNS 服务器透传IP 2.2 建立 TCP 连接在经过 DNS 解析之后，浏览器已经获取了对应网站的 IP 地址，通过三次握手连接到网站服务器，这个步骤中，我们可以给面试官画出简化后的三次握手过程：
TCP三次握手 （1）客户端发送一个带有 SYN 标记位的数据包（syn=J）到服务器，然后进入 SYN_SENT 状态； （2）服务器收到 SYN 包，需要确认客户端的 SYN（赋值ack=J+1），然后自己也发送一个 SYN 包（syn=K），服务器进入 SYN_RCVD 状态； （3）客户端收到服务器的 SYN+ACK 包，向服务器端发送确认包，即ack=K+1，发送完成之后，两边都进入 ESTABLISHED 建立连接状态。 2.3 发送 HTTP 请求TCP 三次握手之后，客户端和服务器端成功建立了连接，之后浏览器会向服务器特定端口发送HTTP请求。
以 Chrome 浏览器为例，按下 F12 即可进入开发者模式，Network 一栏查看HTTP请求的具体报文。 一个 HTTP 报文由请求行（Request Line）、请求头部（Request Headers）、空行（Blank Line）以及请求体（Request Body）构成，请求行中规定了请求方法、URI 以及 HTTP 的版本，关于每个字段的详细解释，之前的小节已经进行了阐述。 2.4 服务器端解析请求当一个 HTTP 请求打进服务器之后，一般的流程是：网关层（例如Ngnix）最先获取请求，然后路由转发到具体的Web服务，经过一段业务逻辑之后，可能还会查询数据库，最后将处理的结果返回给浏览器客户端。 对于后端开发程序员来说，日常的工作就集中在服务器端，特别是流程图中的"Web业务服务"这块，例如基于 Spring 框架、Django 框架或者ThinkPHP 框架进行业务逻辑开发和上线。
(HTTP 请求进入服务器端后的解析流程图) 2.5 返回 HTTP 响应服务器端处理业务结果之后，也要返回 HTTP 响应，HTTP 响应由状态行（Status Line）、响应头部（Response Headers）、空行（Blank Line）以及响应体（Response Body）构成，关于每个部分的细节也不再赘述。需要特别注意的是，响应体中的各种错误码定义：
2.6 TCP四次挥手当浏览器获取了域名对应的页面信息，为了避免服务器和客户端双方的资源损耗，客户端会请求断开 TCP 连接，和三次握手的过程相似，TCP 四次挥手的过程可以总结为： （1）第一次请求：客户端请求断开FIN,携带信息seq=u； （2）第二次请求：服务器确认客户端的断开请求 ACK ,携带信息ack=u+1,seq=v； （3）第三次请求：服务器请求断开 FIN ,携带信息seq=w,ACK,ack=u+1； （4）第四次请求：客户端确认服务器的断开 ACK ,携带信息ack=w+1,seq=u+1。
2.7 浏览器解析 HTML服务器返回给客户端的是 HTML 以及 CSS、Javascript 代码，要展示为静态页面，还需要经过浏览器的解析行为。 浏览器内核引擎解析 HTML 文档并且将标签转换为 DOM（Document Object Model，文档对象模型）树的 DOM 节点，不同浏览器的渲染解析流程大同小异。 同时，浏览器内核引擎还会解析 CSS 生成 CSS 规则树，按照从右到左的顺序读取选择器。 另外，在浏览器中还有个"JS脚本解析器"，解析 HTML 和 CSS 是多线程同时执行的，CSS 解析失败不会影响 HTML 内容的解析，但是如果 JS 脚本解析过程中触发了异常，会直接终止 HTML 内容的解析。关于更详细的解析动作，作为后端开发，我们不需要了解太多，这块也不会作为面试考察的内容。 3.小结本节中和大家讲解了"我们在浏览器中输入一个URL，具体发生了什么"，整个过程中分析了应用层（HTTP、DNS）、传输层（TCP）、网络层（IP）等网络分层的各个协议的作用，也对服务器解析HTTP的基本流程进行了阐述，本小节需要大家掌握访问 URL 时每个步骤的基本功能，能够通过对调用链路的分析，向面试官展示自己的计算机网络功底。 |
|
|
