一个面试题“输入URL后浏览器做了什么”引发的“血案”-CSDN博客

本文链接：https://blog.csdn.net/lzllxll/article/details/124971899

前言

最近经常能看到“输入URL后浏览器做了什么”这么一道题，相信很多小伙伴也和我一样处于迷惑的状态。最初看到这个问题我就想，它爱干什么就干什么呗，网页显示了就成了，这和我有什么关系吗？影响我做前端开发吗？有关系也是和Server端还有运维的事情啊。实际上大部分时候我们并用不到相关的知识，但是本着“往死里卷”的态度，还是简单了解一下比较好。

本人能力有限，浅薄的说一下自己的理解，如果有误请各位指正。

URL是什么？

既然说是输入一个URL后做了什么，那么我首先就要知道URL是什么。

URL（Uniform Resource Locator）：统一资源定位器 [RFC 1738]

其格式为

Scheme://host:port/path

看到名称后我们就知道URL是用来定位网络上的某一个资源的。那么我们接下来开始输入。

输入一个URL后浏览器做了什么

1. URL是否合法

我们都知道，非法的URL会调用浏览器的默认搜索引擎进行检索，所以我们就只讨论合法的情况

2. 通过域名解析获取IP地址

域名是给我们使用者方便记忆使用的，在寻址的过程中需要先将域名解析成IP地址，过程可能有如下几种：

hosts文件
DNS服务器
已经解析过，走缓存文件

当你本地的hosts文件中有对应的IP配置，则直接使用，否则呢就去DNS服务器做域名解析

不管使用什么方法，到这一步我们都会拿到协议://ip:port/path 这样记录，接下来会通过网络层进行ip寻址，来找到目标服务器

说到这呢，好像有多出了几个概念，为了接下来方便理解，我们先简单说一下这些都是嘛。

知识扩展

首先让我们看看何为网络层，在TCP/IP协议栈中，对原始的OSI七层模型（应、表、会、传、网、数、物）做了简化，简化后的模型为：

应用层 - HTTP
传输层 - TCP、~~UDP~~
网络层 - IP协议
数据链路层
物理层

正常来讲，我们只需要关心应用层的HTTP协议、传输层的TCP协议和网络层的IP协议。因为目前来说无论是http1.1和http2.0的底层都是通过TCP协议传输的。当然，http3.0就不是了，http3.0是基于UDP + google的QUIC协议来实现的，我们目前还不涉及。

3. IP协议网络寻址

通过ip协议，这个http请求在庞大的网络中找到了目标服务器，接下来我们就会思考，找到服务器了，定位到了应用服务器上专门用来处理网络请求的服务（IIS/Apache等）,那么我们如何找到对应的站点呢？

是的，port端口号，大家都知道每个应用服务器上都可能跑着很多网站，若想交换数据，我们就需要定位到对应的网站或者进程，这也就是port的作用之一。如果在请求的时候不填写，那么http会请求会被默认路由到80端口，https会被默认路由到443端口

现在我们在茫茫网络中，找到了另一端的网络进程，接下来就要开启正式访问了。

4. 建立连接

接下来就是建立连接的过程了，那么为什么要建立连接，直接传数据不好吗？这就涉及到TCP协议封装的问题了，我们先看看TCP协议的特点。

TCP协议的特点：

面向连接
可靠的传输
流量控制、拥塞控制

相较于UDP的面相无连接（报文）来说，TCP就显得更加可靠了一些，当然他也有缺点，先简单延伸一下，此处不细说

接下来就是大名鼎鼎的三次握手环节

三次握手

首先我们先看看在握手的过程中会出现的位码：

SYN=1：申请建立连接
ACK(acknowledgement)=1：确认连接
Sequence number：请求的序列号
Acknowledge number：确认的序列号

三次握手简要过程：

第一次握手：客户机 -> 服务器：喂，你在吗？还能对外正常提供服务吗？
- 客户端发送： SYN=1, Sequence number=j
第二次握手：服务器 -> 客户机：我在，可以的。
- ……此处省略N种判断，各种连接队列啊什么的
- 服务器回执：SYN=1; ACK=1,Acknowledge number=j + 1,Sequence number=k
第三次握手：客户机 -> 服务器：妥嘞，我马上就到
- 首先确认下是否是自己请求连接的服务器，通过ack num是否等于 seq num + 1
- 然后确认对方是否提供服务，通过ACK是否等于1
- 客户端发送：Acknowledge number=k + 1, ACK=1