计算机网络基础知识之从输入url到浏览器解析的过程

Posted 2021-05-16 黑黑白白君

文章目录

• 1）域名解析
• • DNS查询顺序：
  • • 1.1 浏览器检查本地的DNS缓存
    • • *浏览器自身的DNS缓存
      • 1.1.1 Chrome浏览器DNS缓存
      • 1.1.2 Firefox浏览器DNS缓存
      • *如果一个域名的DNS解析结果会有多个的话，浏览器如何处理？
    • 1.2 浏览器查找操作系统中的DNS缓存
    • • 1.2.1 在Windows中：
      • 1.2.2 在Linux中：
    • 1.3 请求域名服务器来解析域名
    • • 1.3.1 操作系统将域名发送至本地域名服务器（递归查询方式）
      • • 在Windows下：
        • 在Linux下：
      • 1.3.2 迭代查询方式
      • • 1、本地域名服务器向根域名服务器（Root Server）发起请求 。
        • 2、本地域名服务器向顶级域名服务器（gTLD Server）发起请求
        • 3、本地域名服务器向权限域名服务器（Name Server）发起请求
        • 4、本地域名服务器将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来。
        • 5、操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来。
• 2）建立TCP连接
• • 2.1 TCP三次握手
  • • 1、第一次握手：
    • 2、第二次握手：
    • 3、第三次握手：
    • *为什么需要第三次握手？
  • *SYN攻击：
• 3）发起HTTP请求
• • 3.1 什么是HTTP？
  • • 特点：
    • • HTTP是无状态：
      • HTTP是一种短连接：
    • HTTP协议通信流程：
  • 3.2 HTTP请求报文
  • • 3.2.1 请求行（request line）
    • • 请求方法：
      • • 最常用到的是GET和POST：
    • 3.2.2 请求头部（header）
    • 3.2.3 空行以及请求体（body）
• 4）服务器处理请求
• • 4.1 处理HTTP请求
  • 4.2 访问资源
  • • 访问静态资源
    • 访问动态资源：
  • 4.3 记录日志
• 5）服务器构建并发送响应信息
• • 5.1 响应报文
  • • 5.1.1 响应行（respond line）
    • • 状态码规则：
      • 常见状态码：
      • • 200 OK：
        • 204 No Content：
        • 301 Moved Permanently：
        • 302 Found
        • 304 Not Modified：
        • 400 Bad Request：
        • 401 Unauthorized：
        • 403 Forbidden：
        • 404 Not Found：
        • 500 Internal Server Error：
        • 503 Service Unavailable：
    • 5.1.2 响应头
    • • 常见的HTTP响应报文头属性：
    • 5.1.3 空行和响应体
• 6）浏览器渲染页面
• • 6.1 根据 HTML 解析出 DOM 树
  • 6.2 根据 CSS 解析生成 CSS 规则树
  • 6.3 渲染
  • • 6.3.1 生成Render Tree
    • 6.3.2 布局
    • 6.3.3 绘制
• 7）断开TCP连接
• • 7.1 TCP四次挥手
  • • 1、第一次挥手：
    • 2、第二次挥手：
    • 3、第三次挥手：
    • 4、第四次挥手：
  • *为什么关闭连接需要四次挥手？
  • *为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

---

在浏览器中输入URL后，到浏览器呈现给用户的全过程分析：

1）域名解析

比如用户在浏览器输入www.xxx.com后：

通常我们输入一个网址，它包含了域名和端口，可以指定唯一的IP地址，而域名查找IP地址的过程就是dns解析。
比如：www.dnscache.com (域名) - DNS解析 -> 11.222.33.444 (IP地址)

• DNS查询顺序：

  浏览器缓存→系统缓存→路由器缓存→ISP DNS 缓存→递归搜索

1.1 浏览器检查本地的DNS缓存

浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个域名解析过程就将结束。

• *浏览器自身的DNS缓存

  DNS解析过程会对网络请求带来一定的损耗，所以浏览器在第一次获取到IP地址后，会将其缓存起来。下次相同域名再次发起请求时，浏览器会先查找本地缓存，如果缓存有效，则会直接返回该IP地址，否则会继续开始寻址之旅。
  • 浏览器缓存域名也是有限制的：不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过TTL属性来设置。
  • 如果缓存时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有可能会有一部分用户无法访问网站。
  • 如果时间设置太短，会导致用户每次访问网站都要重新解析一次域名。

1.1.1 Chrome浏览器DNS缓存

为了加快访问速度，Google Chrome浏览器采用了预提DNS记录，在本地建立DNS缓存的方法，加快网站的连接速度。

• chrome://net-internals/#dns 这里可以看各域名的DNS 缓存时间。
• chrome对每个域名会默认缓存60s。
• 在url地址栏输入chrome://chrome-urls/可以看到chrome所有的配置界面，选择chrome://dns或者chrome://net-internals/#dns可以查看chrome浏览器的dns缓存信息。
• 点击“Clear host cache”+然后选择"clear cache"和 " flush socket"，可以清空chrome的dns缓存。

1.1.2 Firefox浏览器DNS缓存

相关的配置可在about:config中找到：

• network.dnsCacheEntries：缓存的数量
• network.dnsCacheExpiration：dns缓存的时间
• network.dnsCacheExpirationGracePeriod：dns缓存的时间，设置为0表示不缓存

*如果一个域名的DNS解析结果会有多个的话，浏览器如何处理？

Chrome浏览器会优先向第一个IP发起HTTP请求，如果不通，再向后面的IP发起HTTP请求。

1.2 浏览器查找操作系统中的DNS缓存

如果用户的浏览器缓存中没有，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。

1.2.1 在Windows中：

可以通过C:\\Windows\\System32\\drivers\\etc\\hosts文件来设置，可以将任何域名解析到任何能够访问的IP地址。如果在这里指定了一个域名对应的IP地址，那么浏览器会第二优先使用这个IP地址。

• 例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。
• 正是因为有这种本地DNS解析的规程，所以黑客就有可能通过修改你的域名解析来把特定的域名解析到它指定的IP地址上，导致这些域名被劫持。这导致早期的Windows版本中出现过很严重的问题，而且对于一般没有太多电脑知识的用户来说，出现问题后很难发现，即使发现也很难自己解决，所以Windows
  7中将hosts文件设置成了只读的，防止这个文件被轻易修改。

1.2.2 在Linux中：

在Linux中这个配置文件是etc/hosts文件，修改这个文件可以达到同样的目的，当解析到这个配置文件中的某个域名时，操作系统会在缓存中缓存这个解析结果，缓存的时间同样是受这个域名的失效时间和缓存的空间大小控制的。

• 注意：/etc/hosts文件中有多个重复的时候，前面的优先级高，后面添加了也是白加，要删除前面的或者添加到/etc/hosts的第一行。
• 要清除浏览器的dns缓存：ubuntu linux上直接重启网络即可sudo service network-manager restart

1.3 请求域名服务器来解析域名

前面这两个步骤都是在本机完成的，如果在本机中仍然无法完成域名的解析，就会真正请求域名服务器来解析这个域名了。

1.3.1 操作系统将域名发送至本地域名服务器（递归查询方式）

在我们的网络配置中都会有"DNS服务器地址"这一项，操作系统会把这个域名发送给这里设置的LDNS（Local DNS Server），即本地区的域名服务器。这个DNS通常都提供给你本地互联网接入的一个DNS解析服务。

例如你是在学校接入互联网，那么你的DNS服务器肯定在你的学校，如果你是在一个小区接入互联网的，那这个DNS就是提供给你接入互联网的应用提供商，即电信或者联通，也就是通常所说的SPA，那么这个DNS通常也会在你所在城市的某个角落，通常不会很远。

• 在Windows下：

  在Windows下可以通过ipconfig查询这个地址。

• 在Linux下：

  • 查看配置文件，输入命令cat /etc/resolv.conf。
  • 修改DNS服务器配置，vim编辑配置文件/etc/solve.conf。
  • 跟Windows系统一样，Linux系统也有主机表文件，同样可以通过设置主机表地址进行特定主机的解析，优先DNS服务器地址。配置文件在/etc/hosts。

这个专门的域名解析服务器性能都会很好，大约80%的域名解析都到这里就已经完成了，所以LDNS主要承担了域名的解析工作。

1.3.2 迭代查询方式

1、本地域名服务器向根域名服务器（Root Server）发起请求 。

如果本地域名服务器没有，则向根域名服务器（其虽然没有每个域名的具体信息，但存储了负责每个域，如com、net、org等的顶级域名服务器的地址）发起请求。此例中，根域名服务器返回com域的顶级域名服务器的地址。

2、本地域名服务器向顶级域名服务器（gTLD Server）发起请求

本地域名服务器 向com域的顶级域名服务器发起请求，返回xxx.com权限域名服务器（权限域名服务器，用来保存该区中的所有主机域名到IP地址的映射）地址。

• gTLD是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右。

3、本地域名服务器向权限域名服务器（Name Server）发起请求

本地域名服务器 向xxx.com权限域名服务器发起请求，得到www.xxx.com的IP地址。

• Name Server域名服务器会查询存储的域名和IP的映射关系表，正常情况下都根据域名得到目标IP记录，连同一个TTL值返回给DNS Server域名服务器。

4、本地域名服务器将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来。

5、操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来。

2）建立TCP连接

TCP 用于应用程序之间的通信。当应用程序希望通过 TCP 与另一个应用程序通信时，它会发送一个通信请求，这个请求必须被送到一个确切的地址。在双方“握手”之后，TCP 将在两个应用程序之间建立一个全双工 (full-duplex) 的通信。

• HTTP协议（HyperText Transfer Protocol，超文本传输协议）是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。
• 由于HTTP是基于TCP/IP通信协议来传递数据（html
  文件、图片文件、查询结果等），因此在发送HTTP请求前，需要先建立TCP连接。
• TCP协议对应于传输层，而HTTP协议对应于应用层
• TCP/IP 意味着 TCP 和 IP 在一起协同工作。
  • TCP 负责应用软件（比如浏览器）和网络软件之间的通信。IP 负责计算机之间的通信。
  • TCP 负责将数据分割并装入 IP 包，然后在它们到达的时候重新组合它们。IP 负责将包发送至接受者。
    
    
• TCP报文格式：
  

2.1 TCP三次握手

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

• 在socket编程中，这一过程由客户端执行connect来触发：C#代码每次new 一个connection的时候，connection.open就打开了这个TCP连接。connection.Close的时候就关闭了这个连接。
• 在C#中会有Socket，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口(API)。Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write等等。

• 整个流程如下图所示：
  

1、第一次握手：

Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

2、第二次握手：

Server收到数据包后，由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

3、第三次握手：

Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

*为什么需要第三次握手？

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

• 正常情况下：Client发出连接请求，但是因为连接报文请求丢失而未收到确认，于是Client再重传一次连接请求，后来收到了请求，并收到了确认，建立了连接，数据传输完毕后，就释放链接，Client共发送了两次连接请求报文段，其中第一个丢失，第二个到达了Server，没有“已失效的连接请求报文段”。
• 但是还有异常情况下：Client发送的请求报文连接段并没有丢失，而是在某个网络节点滞留较长时间，以致延误到请求释放后的某个时间到达Server。本来是一个早已失效的报文段，但是Server收到了此失效连接请求报文段后，就误以为Client又重新发送的连接请求报文段，并发送确认报文段给Client，同意建立连接。如果没有三次握手，那么Server发送确认后，连接就建立了，而此时Client没有发送建立连接的请求报文段，于是不理会Server的确认，也不会给Server发送数据，而Server却一直等待Client发送数据，因此Server的许多资源就浪费了。采用三次握手的方式就可以防止这种事情发生。

*SYN攻击：

• 在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。

SYN攻击是一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

netstat -nap | grep SYN_RECV

3）发起HTTP请求

3.1 什么是HTTP？

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

• HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
• Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。Web服务器根据接收到的请求后，向客户端发送响应信息。
• HTTP默认端口号为80，但是也可以改为8080或者其他端口。

• 特点：

  • HTTP是无状态：

    HTTP协议是无状态协议，无状态是指协议对于事务处理没有记忆能力。

    • 浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。如果是一个连接的话，服务器进程中就能保持住这个连接并且在内存中记住一些信息状态。而每次请求结束后，连接就关闭，相关的内容就释放了，所以记不住任何状态，成为无状态连接。
    • 后来，通过Session、Cookie等相关技术，也能保持一些用户的状态，但是还是每次都使用一个连接，依然是无状态连接。
    
    

  • HTTP是一种短连接：

    Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。

    • Http在每次请求完成后就把TCP连接关了，所以是短连接。
    • 从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说：当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。虽然这里使用TCP连接保持了一段时间，但是这个时间是有限范围的，到了时间点依然是会关闭的，所以我们还把其看做是每次连接完成后就会关闭。

• HTTP协议通信流程：

  

• CGI(Common Gateway Interface) 是 HTTP 服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。
• 绝大多数的 CGI 程序被用来解释处理来自表单的输入信息，并在服务器产生相应的处理，或将相应的信息反馈给浏览器。CGI 程序使网页具有交互功能。

3.2 HTTP请求报文

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式：

3.2.1 请求行（request line）

请求行包含请求方法、URL、协议版本。

• 请求方法：

  • HTTP1.0 定义了三种请求方法： GET、POST 和 HEAD方法。

  • HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

  • 最常用到的是GET和POST：

    • GET：请求指定的页面信息，并返回实体主体。
    • POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
    • POST比GET方式的安全性要高，通过GET提交数据，用户名和密码将明文出现在URL上。

3.2.2 请求头部（header）

头部信息是自定义，其用途在于传递额外信息（浏览器信息、请求的内容类型、相应的语言）。报文头包含若干个属性，格式为“属性名:属性值”，服务端据此获取客户端的信息。

• Accept：客户端接受什么类型的响应。 Accept属性的值可以为一个或多个MIME类型的值（描述消息内容类型的因特网标准，消息能包含文本、图像、音频、视频以及其他应用程序专用的数据）。
• cookie：客户端的Cookie就是通过这个报文头属性传给服务端。服务端通过jsessionid的值将客户端的多个请求与一个Session关联起来。
• Referer：表示这个请求是从哪个URL过来的，假如你通过google搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是http://www.google.com。
• Cache-Control：对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。

3.2.3 空行以及请求体（body）

请求体可以承载多个请求参数的数据，包含回车符、换行符和请求数据，并不是所有请求都具有请求数据。

举例：

报文体将一个页面表单中的组件值通过param1=value1&param2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。

• 不但报文体可以传递请求参数，请求URL也可以通过类似于“/chapter15/user.html? param1=value1&param2=value2”的方式传递请求参数。

4）服务器处理请求

4.1 处理HTTP请求

处理的过程大致是把请求的信息解析出来，如下图：

4.2 访问资源

• 访问静态资源

  访问资源可以是访问静态资源，这个就直接根据url地址去服务器里找就好了。

• 访问动态资源：

  访问动态资源的话要经过一个叫cgi的东西，再用服务端脚本处理，再返回给前端。如下图所示：
  

4.3 记录日志

服务端对这个请求响应过程进行记录。

5）服务器构建并发送响应信息

5.1 响应报文

响应报文由响应行（respond line）、响应头部（header）、响应主体三个部分组成。

5.1.1 响应行（respond line）

包括主要包括协议版本，状态码，状态码描述。和请求报文相比，响应报文多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。

• 状态码规则：

  • HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP 状态码共分为 5 种类型。
    

• 常见状态码：

  • 200 OK：

    200表示请求在服务器端被正常处理了。在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。

  • 204 No Content：

    204表示服务器接收的请求已经成功处理，但是在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。当浏览器在发送请求后接收到204响应，它的显示页面不会发生更新。
    • 通常应用在只需要客户端往服务端发送信息，而服务端不需要发送新信息的情况下使用。

  • 301 Moved Permanently：

    永久重定向，301状态码表示请求的资源已经分配了新的URI，以后请求该资源应该访问新的URI。也就是说，如果已经把资源对应的URI保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存。

  • 302 Found

    临时重定向，302表示请求的资源已经被分配了新的URI，希望客户端本次能使用新的URI访问。和301不同的是，这种资源的URI变更是临时的，而不是永久的，因此不用去更新书签。

  • 304 Not Modified：

    304 状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。例如，客户端请求的资源在客户端本地已有缓存，会在请求头部中加入“If-Modified-Since"、"If-None-Match"等字段，服务端根据这些字段信息判断这些资源信息是否经过修改，如果没有则返回 304状态码，客户端可以直接使用缓存中的资源。
    • 304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。

  • 400 Bad Request：

    400 状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像 200 OK 一样对待该状态码。

  • 401 Unauthorized：

    401 状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。第一次收到 401 状态码表示需要进行用户认证，第二次再收到 401 状态码说明用户认证失败。

  • 403 Forbidden：

    403 状态码表明对请求资源的访问被服务器拒绝了，当未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源 IP
    地址试图访问）等列举的情况都可能发生 403 。

  • 404 Not Found：

    表示服务器上无法找到请求资源。此外，也可能是服务器端在拒绝请求且不想说明原因的时候使用。

  • 500 Internal Server Error：

    500 状态码表明服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。

  • 503 Service Unavailable：

    503 状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

5.1.2 响应头

响应报文头也是由多个属性组成。

• 常见的HTTP响应报文头属性：

  • Cache-Control：响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。常见的取值有private（客户端可以缓存）、public、no-cache（需要使用对比缓存来验证缓存数据）、max-age，no-store（所有内容都不会缓存），默认为private。
    • 默认为private，缓存时间为31536000秒（365天）也就是说，在365天内再次请求这条数据，都会直接获取缓存数据库中的数据，直接使用。
  • ETag：一个代表响应服务端资源（如页面）版本的报文头属性，如果某个服务端资源发生变化了，这个ETag就会相应发生变化。它是Cache-Control的有益补充，可以让客户端“更智能”地处理什么时候要从服务端取资源，什么时候可以直接从缓存中返回响应。
  • Location：这个头配合302状态码使用，用于重定向接收者到一个新URI地址。表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
  • Set-Cookie：服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的
  • Last-Modified：文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304(Not Modified)状态。Last-Modified也可用setDateHeader方法来设置。

5.1.3 空行和响应体

响应主体包含回车符、换行符和响应返回数据，并不是所有响应报文都有响应数据。

6）浏览器渲染页面

浏览器解析html代码，并请求html代码中的资源（如js、css图片等）。

• 具体内容可参考：https://blog.csdn.net/qq_41807645/article/details/80839757

浏览器解析渲染页面流程见下图：

6.1 根据 HTML 解析出 DOM 树

浏览器可以解析的资源有HTML，SVG，XHTML等，解析完会生成DOM Tree。

• 大致流程是浏览器使用词法分析器和解析器将HTML内容解析成为语法树，也就是DOM树.
• DOM 树的构建过程是一个深度遍历过程：当前节点的所有子节点都构建好后才会去构建当前节点的下一个兄弟节点。
• DOM树是由DOM元素和属性节点组成，DOM是文档对象模型（Document ObjectModel）的缩写，是HTML文档的对象表示，同时也是外部内容与HTML元素之间的接口。

6.2 根据 CSS 解析生成 CSS 规则树

CSS解析的过程类似于HTML解析，也是浏览器使用自带的解析器进行解析，一般解析过程是由上而下，会将CSS文件解析成为StyleSheet对象，且每个对象都包含CSS规则。CSS规则对象包含了选择和声明对象，以及其他与CSS语法对应的对象。CSS解析完成后会大致生成CSS Rule Tree。

6.3 渲染

6.3.1 生成Render Tree

DOM树和CSS树结合生成Render Tree（渲染树）。JS通过DOM API和CSSOM API来操作DOM树和CSS树。解析完成后综合DOM树和CSS树会生成Rendering Tree。

• 这是由可视化元素按照其显示顺序组成的树形结构，是文档可视化的表示，它的作用是让浏览器能够按照正确的顺序渲染页面元素。Firefox中称之为“框架”，Webkit中的术语则是呈现器或者呈现对象。
• 渲染树是和DOM元素相对应的，但是并非全部一一对应

6.3.2 布局

渲染树中并不包含位置和大小的信息，计算这些值的过程就是布局（layout）或者重排。

• 布局的过程是一个递归的过程，从根元素开始，递归遍历部分或者所有的渲染树结构，并为每一个需要显示元素计算几何信息。一般根元素位置坐标（0，0），大小为浏览器窗口的可见区域。
• repaint（重绘）：元素的某一部分属性发生改变，如字体颜色，背景颜色等改变，尺寸并未改变，这时发生的改变过程就是repaint。
• reflow（回流）： 因为浏览器渲染是一个由上而下的过程，当发现某部分的变化影响了布局时，就需要倒回去重新渲染，这个过程就称之为reflow。reflow几乎是没法避免的，现在一些常用的效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。
• 为了避免细小的改变就进行repaint或者reflow，浏览器采用一种"dirty"系统，会将这些改变操作积攒一批，然后做一次reflow，这又叫异步reflow或增量异步reflow。

6.3.3 绘制

在绘制阶段，系统会遍历渲染树，并且调用呈现器通过“paint”方法，将内容显示在屏幕上。同样，类似于布局过程，也分为全局和增量两种。

• 调用操作系统Native GUI的API绘制。

注意：上述这个过程是理论上是逐步完成的，但是实际实现中为了更好的用户体验，渲染引擎为了尽可能早的将内容呈现到屏幕上，会在构建DOM树的同时去解析CSS构建CSS树，并且还会去生成Rendering Tree。解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容，这样就可以更快的显示出页面，其中解析后面的内容涉及到布局和样式的改变引起的reflow过程和repaint。

7）断开TCP连接

当数据传送完毕，需要断开 tcp 连接，此时发起 tcp 四次挥手。

7.1 TCP四次挥手

所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

• 在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：
  

1、第一次挥手：

Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

2、第二次挥手：

Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

3、第三次挥手：

Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

4、第四次挥手：

Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

*为什么关闭连接需要四次挥手？

因为关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

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

1、保证TCP协议的全双工连接能够可靠关闭。

• 如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。
• 这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

2、保证这次连接的重复数据段从网络中消失。

• 如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。
• 一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

---

【部分内容参考自】

• 浏览器的DNS缓存查看和清除：https://www.cnblogs.com/shengulong/p/7443806.html
• 浏览器域名解析步骤：https://blog.csdn.net/qq_36326947/article/details/72864528
• 三次握手与四次挥手详解（以及常见问题）：https://blog.csdn.net/qq_21993785/article/details/80735776
• 浏览器的url的解析？：https://www.cnblogs.com/xiyunfang/p/11996204.html
• TCP协议详解：https://www.jianshu.com/p/ef892323e68f
• Http协议与TCP协议简单理解：https://www.cnblogs.com/dingjiaoyang/p/5326544.html
• 面试官问你HTTP状态码，你敢答吗？：https://blog.csdn.net/weixin_42292229/article/details/105240877
• HTTP请求报文（请求行、请求头、请求体）：https://www.cnblogs.com/lmh001/p/9928517.html
• 服务器如何处理http请求：https://www.cnblogs.com/feng9exe/p/8041755.html
• 浏览器渲染过程解析——从URL到页面显示：https://blog.csdn.net/qq_41807645/article/details/80839757