我们平时上网，将URL输入到浏览器地址栏之后按回车，直到页面展现在我们眼前，到底发生了什么？
过程是这样的
- 输入网址
- 查找网址的 IP 地址，DNS解析
- TCP链接
- 发送HTTP请求
- 服务器的永久重定向响应
- 服务器处理请求
- 服务器返回HTTP 响应
- 浏览器解析渲染页面
1.输入网址
用户需要在自己的浏览器地址栏里输入网站的域名URL，也就是输入网址。现在的浏览器可以只能匹配URL，会借助各种缓存手段来帮用户补全还没输入完毕的URL，甚至会从缓存中提前读取网页的信息。也就是说，可能用户还没有输入完毕URL，网页就已经加载了。
2.查找网址相对应的IP地址，DNS解析
当我们输入网址之后，这个网址并不是网站真正意义上的地址。例如我们输入www.google.com，这只是一个我们人类善于去记忆，输入的内容，并不是计算机的标识。互联网上每一台计算机的唯一标识是它的IP地址，而IP地址并不方便人类去记忆。所以需要在IP地址和网址之间嫁接一个桥梁，也就是网址和IP地址之间有一个翻译官。这个翻译官就叫做DNS解析。
但在进行DNS本地服务器到根服务器进行查找之前，我们还有DNS缓存这个翻译官，例如系统缓存Hosts，Hosts是一个没有扩展名的系统文件，其基本作用就是将一些常用的网址域名与其对应的IP地址建立一个关联"数据库",当用户在浏览器中输入一个需要登录的网址时，系统会首先自动从Hosts文件中寻找对应的IP地址，一旦找到，系统会立即打开对应网页，如果没有找到，则系统再会将网址提交DNS域名解析服务器进行IP地址的解析，如果发现是被屏蔽的IP或域名，就会禁止打开此网页！
另外，DNS缓存有这些，浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。这些也会存储一些网页数据以及IP地址映射关系，如果浏览器可以从这些里面找到网址对应的IP地址，那就可以直接以这个IP地址访问网页了。
但是，如果在上面的这些手段中，都无法找到网址对应的IP地址，那么就需要本地DNS服务器去向根服务器进行询问查找了。
DNS解析
什么是DNS？
DNS （Domain Name System）就是根据域名查出IP地址。你可以把它想象成一本巨大的电话本。
它是一个网络上用于对域名和IP地址进行互相映射的一个分布式数据库。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。也就是说，我手里有一个域名，通过DNS这个电话本，我可以找到我这个域名对应的IP地址是多少。
DNS服务器是什么
DNS服务器是(Domain Name System或者Domain Name Service)域名系统或者域名服务,域名系统为Internet上的主机分配域名地址和IP地址。用户使用域名地址，该系统就会自动把域名地址转为IP地址。域名服务是运行域名系统的Internet工具。执行域名服务的服务器称之为DNS服务器，通过DNS服务器来应答域名服务的查询。
我们在设置路由器的时候想要固定IP，还要输入本地DNS服务器地址。我们电脑需要与外部计算机沟通就需要有自己的DNS，因为我们离本地网络运营商的网络连接的距离是最近的，所以用本地服务商DNS地址可以最大限度提升电脑与网络的交换速度。比如中国电信，中国移动，中国联通。如果不知道本地DNS地址的话最不要去固定IP地址，选择自动获取即可。
域名解析需要由专门的域名解析服务器来完成，DNS服务器就是进行域名解析的服务器。
DNS的查询方式
DNS 的查询有两种方式。一般两种方式都会用到。递归查询是用在本地机查询本地 DNS 服务器的过程，迭代查询是本地 DNS 服务器在互联网上查找目标机的过程。
a -> b -> c -> d这个链路就是递归查询，这样一级一级向下查询。总有一个人会给出答案，或者返回一个找不到的结果。
b -> C, b -> D，这个就是迭代查询，因为 C 没有帮 b 去查，而是直接给了他一个别的域服务器地址去让它再去打听。
主机到本地 DNS 服务器的查询就属于递归查询。
本地 DNS 服务器向根服务器的查询就是迭代查询。
DNS负载均衡
当一个网站访问的人数非常地多的时候，如果都所有人都访问同一个服务器的IP地址，那这台服务器很容易崩溃掉。那么如何来避免这种情况发生呢？
这里我们可以使用DNS均衡负载技术。也就是DNS服务器为同一个域名，主机名分配多个不同的IP地址，在进行DNS查询中，按照不同服务器的负载能力，距离用户的距离，提供不同的IP地址，将用户引导到不同的服务器上去，从而减少单个服务器的负载压力。
让我们回到DNS解析的过程中来
如图所示，我们想要打开www.google.com，首先联系上本地的DNS服务器，他会通过递归查找的方式查找DNS缓存中是否有相对应的映射关系，如果有，那就皆大欢喜，可以直接返回结果。如果没有，那他就要去询问DNS根服务器。接下来就是一套迭代查找的过程。
首先询问DNS根服务器，但DNS根服务器并没有记录域名与IP地址相对应的映射关系，它只是告诉你应该去域服务器上查找。例如我们要找的是www.google.com的IP地址，根DNS服务器会让本地DNS服务器去com域名服务器查找映射关系。而com域服务器又让本地DNS服务器去找google.com域服务器，结果在这个服务器会得到答案，从而返回结果。
接下来，本地DNS服务器并不会接收到结果就大功告成，上文中请求到google的IP地址时，经历了8个步骤，这个过程中存在多个请求，同时存在UDP和TCP请求，步骤太多，很耗费时间。那么有什么办法可以优化这个过程，减少步骤呢？这就是上文说到的DNS缓存的作用了。本地DNS服务器会把这个映射关系存储在缓存中，下次使用的时候能快速地从缓存中调出IP地址。
3.TCP连接
首先我们来了解一下TCP连接。
有两个常用的传输协议，TCP与UDP。
用户数据报协议 UDP（User Datagram Protocol）：
UDP 在传送数据之前不需要先建立连接，远程主机在收到 UDP 报文后，不需要给出任何确认。
传输控制协议 TCP（Transmission Control Protocol）：
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。
TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务，这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。
TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
源端口和目的端口：各占 2 个字节。
序列号（Sequense Number，SN）：在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。该字段表示本报文段所发送的数据的第一个字节的序号。初始序号称为 Init Sequense Number即 ISN，初始化序列号（initial sequence number）。是在建立TCP三次握手的时候，存储在TCP头部的序列号位置中的数字的代称。
确认号 ACK：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。
紧急位 URG：当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不用在缓存中排队。该控制位需配合紧急指针使用（紧急指针指出本报文段中紧急数据的字节数）
举个例子：我们需要取消一个已经发送了很长程序的运行，因此用户从键盘发出中断命令。如果不使用紧急数据，那么这个指令将存储在接收 TCP 的缓存末尾，只有在所有的数据被处理完毕后这两个字符才被交付接收方的应用进程，这样做就无法实现立即中断。确认 ACK：仅当 ACK = 1 时确认号字段才有效，当 ACK = 0 时确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置为 1。
推送 PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应。在这种情况下，TCP 就可以使用推送（push）操作。这时，发送方 TCP 把 PSH 置为 1，并立即创建一个报文段发送出去。接收方 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程。而不用等到整个缓存都填满了后再向上交付。
复位 RST：当 RST = 1 时，表明 TCP 连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。
同步 SYN：SYN = 1 表示这是一个连接请求或连接接受报文。
当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 且 ACK = 1。终止 FIN：用来释放一个连接。当 FIN = 1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。
三次握手与四次挥手
所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。
三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。
首先，我们要了解的是：
SYN：同步序列编号（Synchronize Sequence Numbers）。是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN+ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。
ACK: 确认字符(Acknowledge character）。在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。
seq： 发送的第一个字节的序号。
ISN： 初始化序列号（initial sequence number）。是在建立TCP三次握手的时候，存储在TCP头部的序列号位置中的数字的代称。
ACKnum*：确认号。希望收到的下一个数据的第一个字节的序号
- 第一次握手(SYN=1, seq=x):
客户端发送一个 TCP 的 SYN =1的包，指明客户端打算连接的服务器的端口，以及初始序号seq= x，等待服务器的回应。并且设置自己的ISN为x，也就是seq=x。
发送完毕后，客户端进入 SYN_SEND 状态。
SYN-SENT ：在发送连接请求后等待匹配的连接请求
- 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服务器收到了客户端发送的SYN=1的包，要确认客户端的SYN，发回确认包(ACK)应答。ACK为q+1，服务器端选择自己 ISN 序列号，放到 Seq 域里，也就是seq=y。同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即x+1。 发送完毕后，服务器端进入 SYN_RCVD状态。这时候接受的连接请求会被放进半连接队列。
SYN-RECEIVED：在收到和发送一个连接请求后等待对连接请求的确认
- 第三次握手(ACK=1，seq=x+1，ACKnum=y+1)
客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1。
发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束。连接成功。这个时候收到的连接请求会放进全连接队列。如果队列满了就有可能会出现丢包现象。
ESTABLISHED：代表一个打开的连接，数据可以传送给用户
为什么要进行三次握手才能完成TCP连接？
为了保证双方的信息发送与接收是正常进行的。
第一次握手，客户端发送了SYN报文，并设置ISN=x，以及第一个子节的序号seq=x发给了服务器。服务器收到了SYN报文，这证明客户端可以正常发送信息，服务器可以正常接收信息。
第二次握手，服务器传回SYN和ACK报文表示自己收到了客户端的SYN报文，并且设置了自己的ISN=y，确认号为客户端seq的下一个子节序号也就是x+1，希望收到的下一个数据的第一个字节的序号是y+1，传给了客户端。这证明了客户端自己发送，接收正常，对方发送，接收正常。
第三次握手，客户端再带着ACK报文和确认号为服务器的第一个字节的序号y+1，传回给了服务器。这证明了客户端和服务器自己发送，对方发送，自己接收，对方接收，都正常。
ISN (Initial Sequence Number) 是固定的吗
当然不是，如果ISN是固定的，那很容易被攻击者攻击。攻击者很容易猜到后面连续的序列号，从而对这三次握手进行中间的伪装造假。
还有如果ISN是固定的，很有可能会造成多次的连接不能区分各个连接之间传输的信息所属。如果第一次的连接，客户端向服务器传输了数据，然而由于网络因素，并没有传到。那么等连接结束，新建连接的时候，由于ISN还是固定一样的，可能上次传输的数据传到了服务器也会照收不误，发生错误。
三次握手过程中可以携带数据吗
第一次，第二次握手的时候是绝对不可以携带数据的。也就是当SYN=1的时候是不可以携带数据的。必须要双方都确认连接没有问题之后才可以传输数据。
SYN 洪泛攻击
SYN攻击就是攻击者在短时间内伪造大量不存在的IP地址，并不断地向服务器发送SYN报文。这时候服务器就会传回信息以求得客户端再握手。但是由于是虚假的IP地址，这些信息并不会被相应，这些虚假SYN请求将会占满半连接队列，让正常的SYN报文被丢弃。引发网络拥堵或瘫痪。如果服务器得不到响应，会一直重传等待，直到到达最大重传次数为止。
TCP 四次挥手
TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。
和三次握手相比，这里多了一个FIN，是连接终止位。
- 第一次挥手(FIN=1，seq=x)
假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。
发送完毕后，客户端进入 FIN_WAIT_1 状态。
- 第二次挥手(ACK=1，ACKnum=x+1)
服务器端确认客户端的 FIN 包，发送一个确认包，且把客户端的序号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了。表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。
发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。
- 第三次挥手(FIN=1，seq=y)
服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。且指定一个序列号seq=y。
发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。
- 第四次挥手(ACK=1，ACKnum=y+1)
客户端接收到来自服务器端的关闭请求，发送一个确认包并且带上服务器序列号+1作为ACK确认号，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。
服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
客户端等待了某个固定时间（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。
为什么要四次挥手
由于 TCP 的半关闭（half-close）特性，TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。也就是说，第一步和第二步挥手就可以释放客户端到服务器的TCP连接。但是这时候服务器可能还想要传输数据。就必须要第三步和第四步挥手让客户端知道服务器也不想连接了。
4. 发送HTTP请求
发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。
建立了TCP连接之后，发起一个http请求。一个典型的 http request header 一般需要包括请求的方法， GET, POST, PUT, DELETE, OPTIONS, HEAD,TRACE等。一般的浏览器只能发起 GET 或者 POST 请求。客户端向服务器发起http请求的时候，会有一些请求信息，请求信息包含三个部分：
- 请求方法URI协议/版本
- 请求头(Request Header)
- 请求正文
请求方法：
Method Request-URL HTTP-Version CRLF
例如
GET index.html HTTP/1.1
请求头：
使用Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息。例如下面的就是百度的请求头。
GET / HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,ja-JP;q=0.8,ja;q=0.7,en;q=0.6,zh-TW;q=0.5
Connection: keep-alive
Cookie: BIDUPSID=BD22C1D9007E7890A5E93A77354FACAA; PSTM=1651839178; BD_UPN=12314753; BDUSS=FRPd3pnT01yZkpRNDRWV3NLSDBKS3JYSUFoclF1VWNVcHlIVVAyRUVaTGtDYUppSVFBQUFBJCQAAAAAAAAAAAEAAADqQwoIxtXA-8ThwOrDqLe5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOR8emLkfHpib; BDUSS_BFESS=FRPd3pnT01yZkpRNDRWV3NLSDBKS3JYSUFoclF1VWNVcHlIVVAyRUVaTGtDYUppSVFBQUFBJCQAAAAAAAAAAAEAAADqQwoIxtXA-8ThwOrDqLe5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOR8emLkfHpib; BAIDUID=09E6473CF3E81110E7A071BA6A7C023B:FG=1; H_WISE_SIDS=107318_110085_127969_132549_184716_188747_189755_190622_193246_194085_194519_194530_196428_197096_197241_197711_197956_199022_199572_201193_202284_203880_203882_203885_204713_204715_204717_204720_204816_204864_204906_205218_205420_205424_207235_207512_207540_207729_208001_208607_208721_208806_209345_209395_209436_209568_209748_209811_209859_210298_210356_210643_210733_210790_210969_211013_211023_211350_211457_211736_211925_212181_212294_212416_212588_212617_212629_212702_212770_212789_212867_213003_213039_213094_213124_213140_213258_213354_213545_213608_213648_213730_213868_214001_214005_214025_8000073_8000105_8000132_8000142_8000145_8000162_8000169_8000178_8000184; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; sugstore=1; BA_HECTOR=ag2hah8g81842l8k8h1h8ot3c14; BAIDUID_BFESS=09E6473CF3E81110E7A071BA6A7C023B:FG=1; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; delPer=0; BD_CK_SAM=1; PSINO=5; ZFY=NLjXY:AeDFqWI3B7JZyKGV8uGpPwnzkocR9DfnOZMMIU:C; baikeVisitId=00b146b5-51e4-4a9c-bc13-a5bbb45707e0; H_PS_PSSID=36428_36459_36454_31660_34812_36422_36167_35979_36055_26350_36468_36447; BDSVRTM=1; ab_sr=1.0.1_OGYzYzkxNzViZGUyYmY5N2QyZjViNTZiNTlhOTdlYzEwMjc1ODkxNjVkOGRhMTU1NTNiZTRhNmY2YjIzNDA5YWNlODNlYzAyZGU0NTBjYTI5MDliMTM1ZWI3YmJjYTJlNzMyZGFhNmM3MDEwOWJjMmNmZmY0ZDc5MjM4ZGRlNDI3YTA2M2ZhZDllMTU2NzI3MGM5ZjU1YmRkZTc5NDU1OGU2MjlmZGY3NmNkNDFjMGM1YzNiMTU3MjMzNWE5NzI4; RT="z=1&dm=baidu.com&si=cvhh3z7o4mm&ss=l3jr0a3z&sl=c&tt=69g&bcn=https%3A%2F%2Ffclog.baidu.com%2Flog%2Fweirwood%3Ftype%3Dperf&ld=8kjt&ul=8o4r&hd=8o5h"
Host: www.baidu.com
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
请求正文
当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。
5. 服务器的永久重定向响应
如果一个页面有两个网址，例如http://www.baidu.com/和http://baidu.com/，他们虽然都指向一个页面。但是搜索引擎会认为他们是两个网址。
这时候服务器会给一个永久重定向的响应,这样就会固定访问前者。
当网站调整，域名调整，地址改变之类的情况发生时，需要进行重定向。
请求网址: http://yy.com/
请求方法: GET
状态代码: 301 Moved Permanently
远程地址: 103.227.121.120:80
引荐来源网址政策: strict-origin-when-cross-origin
请求网址: http://baidu.com/
请求方法: GET
状态代码: 302 Moved Temporarily
远程地址: 220.181.38.251:80
引荐来源网址政策: strict-origin-when-cross-origin
301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。
他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；
302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。SEO302好于301。
浏览器知道了谁才是真正的网址，才会真正地去发送HTTP请求。
6.服务器处理请求
后端收到请求会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。网站访问量非常大，网站越来越慢，一台服务器已经不够用了的时候，这时候还会使用到反向代理。
反向代理有这些好处
- 对客户端隐藏服务器（集群）的IP地址
- 安全：作为应用层防火墙，为网站提供对基于Web的攻击行为（例如DoS的防护，更容易排查恶意软件等
- 为后端服务器（集群）统一提供加密和SSL加速（如SSL终端代理）
- 负载均衡，若服务器集群中有负荷较高者，反向代理通过URL重写，根据连线请求从负荷较低者获取与所需相同的资源或备援
- 对于静态内容及短时间内有大量访问请求的动态内容提供缓存服务
- 对一些内容进行压缩，以节约带宽或为网络带宽不佳的网络提供服务
- 减速上传
反向代理在电脑网络中是代理服务器的一种，服务器根据客户端的请求，从其关系的一组或多组后端服务器（如"Web服务器")）上获取资源，然后再将这些资源返回给客户端，客户端只会得知反向代理的IP地址，而不知道在代理服务器后面的服务器集群的存在)。
与前向代理不同，前向代理作为客户端的代理，将从互联网上获取的资源返回给一个或多个的客户端，服务端（如Web服务器）只知道代理的IP地址而不知道客户端的IP地址；例如Proxy Server。而反向代理是作为服务器端（如Web服务器）的代理使用，而不是客户端。客户端借由前向代理可以间接访问很多不同互联网服务器（集群）的资源，而反向代理是供很多客户端都通过它间接访问不同后端服务器上的资源，而不需要知道这些后端服务器的存在，而以为所有资源都来自于这个反向代理服务器。
7.服务器返回HTTP响应
这是百度的响应头：
HTTP/1.1 200 OK
Bdpagetype: 2
Bdqid: 0xb1af871a0006215f
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html;charset=utf-8
Date: Tue, 24 May 2022 07:57:00 GMT
Expires: Tue, 24 May 2022 07:56:59 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=253; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=36428_36459_36454_31660_34812_36422_36167_35979_36055_26350_36468_36447; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1653379020055736321012803600811376910687
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked
HTTP响应与HTTP请求相似，HTTP响应也由3个部分构成，分别是：
1.状态行
2.响应头(Response Header)
3.响应正文
状态行
HTTP-Version Status-Code Reason-Phrase CRLF
例子：
HTTP/1.1 200 OK
其他状态码有这些意思
1xx：指示信息–表示请求已接收，继续处理。
2xx：成功–表示请求已被成功接收、理解、接受。
3xx：重定向–要完成请求必须进行更进一步的操作。
4xx：客户端错误–请求有语法错误或请求无法实现。
5xx：服务器端错误–服务器未能实现合法的请求。
8.浏览器解析渲染页面
浏览器解析渲染页面是一个从上到下的过程。
1.解析HTML标签，构建DOM树 。
2.解析CSS，构建CSSOM树。
3.把DOM和CSSOM组合成渲染树（render tree）。
4.在渲染树的基础上进行布局，计算每个节点的几何结构。
5.把每个节点绘制到屏幕上（painting）。
在构建页面的过程中，不可避免地会遇到浏览器要重新计算每个元素的大小位置样式。这里会遇到reflow和repaint。
Reflow（回流）Relayout（重新布局）
重新计算元素的几何尺寸，位置。
假设通过JS或是别的什么方法把一些元素消除了，浏览器又要重新计算每个元素的位置，渲染树，几何结构。
Repaint（重绘）
重新绘制界面发生变化的部分。
通过JS修改元素的颜色，其他元素的几何结构位置没变。
只是要改变样式颜色。重绘。
要尽量减少这两个东西的发生。尽量一次性修改样式，给动画使用绝对定位可以减少reflow次数，DOM离线后修改。都是可行的办法。
由于会发生
阻塞解析和阻塞渲染
还是尽量让CSSlink样式表存在于head标签内，JS的加载使用无顺序的async异步加载或者有顺序的defer加载方式。
接着获取所有HTML中嵌入的资源，就完成了一个网页从输入网址到展现在屏幕上的所有过程。
虽然还有很多细枝末节的东西没有说到。
参考于：
https://segmentfault.com/a/1190000039165592
https://hit-alibaba.github.io/interview/basic/network/TCP.html#tcp-%E7%9A%84%E7%89%B9%E6%80%A7
