计算机网络--访问一个网页的全过程

访问一个网页的全过程

应用层

在浏览器输入URL网址http://www.aspxfans.com:8080/news/index.aspboardID=5&ID=24618&page=1#r_70732423

URL格式示例
一个完整的URL包括：协议部分、域名部分、端口部分、虚拟目录部分、文件名部分、参数部分、锚部分
1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在”HTTP”后面的“//”为分隔符
2.域名部分：该URL的域名部分为“www.aspxfans.com”。
3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口
4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
8.锚部分：HTTP请求不包括锚部分，从“#”开始到最后，都是锚部分。本例中的锚部分是“r_70732423“。锚部分也不是一个URL必须的部分。
锚点作用：打开用户页面时滚动到该锚点位置。如：一个html页面中有一段代码，该url的hash为r_70732423, 打开上面的URL, 用户页面会滚动到name='r_70732423’的代码块.

通过DNS获取IP地址

• 如果平台配备了负载均衡的话，前一步DNS解析获得的IP地址应该是Nginx负载均衡服务器的IP地址。所以，之后会将我们的网页请求发送到了Nginx负载均衡服务器上。
  Nginx根据我们设定的分配算法和规则，选择一台后端的真实Web服务器，与之建立TCP连接、并转发我们浏览器发出去的网页请求。

• DNS详细步骤(以迭代查询为例)

1. 检查浏览器缓存.

本地电脑会检查浏览器缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过TTL属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名。

2. 检查操作系统缓存

如果浏览器缓存中没有数据，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。其实操作系统也有一个域名解析的过程，在Linux中可以通过/etc/hosts文件来设置，而在windows中可以通过配置C:\Windows\System32\drivers\etc\hosts文件来设置，用户可以将任何域名解析到任何能够访问的IP地址。例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地DNS解析的规程，所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的IP地址上，导致这些域名被劫持。

3. 以UDP方式发出由本地DNS客户端构造的DNS请求报文给本地域名服务器，本地域名服务器查看缓存的解析结果。

前两个过程无法解析时，就要用到我们网络配置中的"DNS服务器地址"了。操作系统会把这个域名发送给这个本地DNS服务器。每个完整的内网通常都会配置本地DNS服务器，例如用户是在学校或工作单位接入互联网，那么用户的本地DNS服务器肯定在学校或工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。大约80%的域名解析到这里就结束了，后续的DNS迭代和递归也是由本地DNS服务器负责。

4. 本地域名服务器未命中，发送解析请求报文给根DNS服务器。(本地DNS第一次)

如果本地DNS服务器仍然没有命中，就直接到根DNS服务器请求解析。

5. 根域名服务器返回com.域的顶级域名服务器GTLS-DNS

根DNS服务器返回给本地DNS域名服务器一个顶级DNS（按例子中为com.域服务器）服务器地址，它是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右。

6. 本地服务器继续发送解析请求报文给顶级DNS服务器。(本地DNS第二次)

本地DNS服务器再向上一步获得的顶级DNS服务器发送解析请求。

7. 顶级DNS服务器返回权威服务器的IP地址。

接受请求的顶级DNS服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server服务器就是我要访问的网站域名提供商的服务器，其实该域名的解析任务就是由域名提供商的服务器来完成。比如我要访问www.baidu.com，而这个域名是从A公司注册获得的，那么A公司上的服务器就会有www.baidu.com的相关信息。

8. 本地DNS继续向权威域名服务器发送解析请求(本地DNS第三次,注意这里大部分情况是3次，但遇到域名很长的name server服务器可能会有多级)

Name Server服务器会查询存储的域名和IP的映射关系表，再把查询出来的域名和IP地址等等信息，连同一个TTL值返回给本地DNS服务器。

9. 本地DNS接收到之后缓存对应域名和IP的对应关系，并返回给主机

返回该域名对应的IP和TTL值，本地DNS服务器会缓存这个域名和IP的对应关系，缓存时间由TTL值控制。

10. 主机收到结果缓存到本地缓存

把解析的结果返回给本地电脑，本地电脑根据TTL值缓存在本地系统缓存中，域名解析过程结束在实际的DNS解析过程中，可能还不止这10步，如Name Server可能有很多级，或者有一个GTM来负载均衡控制，这都有可能会影响域名解析过程。

生成HTTP请求报文

使用HTTP协议生成HTTP请求报文

应用层最后

将所产生的数据报文传送到传输层

传输层

传输层处理应用层报文

• 将HTTP请求报文按序号分为多个报文段(segment)，并对每个报文段进行封装（加入TCP首部）。

1. TCP视应用层下发的http请求报文为字节流，TCP协议会根据规定的**MSS（最大报文长度：规定了TCP报文所能携带的数据载荷的大小）**判断是否进行拆分
2. 如果字节流长度大于MSS，则需要进行拆分，拆分成合理的几块，然后为每一块添加上合适的TCP头部
3. TCP头部中的序号字段就是为此服务的，最终形成一个个TCP报文段，接收方对应的运输层收到这些TCP报文段后可以根据TCP头部信息进行组装还原原来的http请求报文

建立TCP连接

• 建立TCP连接
  通过三次握手建立连接

传输层最后

• 将封装好的TCP报文传送到网络层

网络层

网络层对TCP报文进行处理

• 对TCP报文进行封装以及分片

1. 根据TCP报文端的类型选择不同的协议。协议字段值为6表示TCP，17表示UDP
2. IP协议会根据输出端口（其实也就是被链路层的各种协议类型所规定）的**MTU（最大传输单元：它规定了IP网络包的最大长度包括首部和数据载荷）**进行判断是否进行分片；
3. 分片是IP对整个TCP报文段一视同仁，也就是不会区分是TCP头部还是数据载荷
4. 这里会加入源IP地址和目的IP地址，一般情况下不会改变（NAT路由器会将其改变，会更改其端口号和源地址[即为NAT路由器的外网IP地址]，服务器响应的目的地址也为NAT的IP地址）

网络层的转发

主机将其封装好后会发往与其直接相连的交换结点。(路由器只使用协议栈的下三层)
路由器在将主机发送的MAC帧拆封,在收到IP分组之后，路由器会查找路由表得到下一跳的IP地址，首先将IP报文中的目的地址和路由表项中的子网掩码进行"逻辑与"操作，得到一个网络地址，然后拿此网络地址与路由项中的网络地址做比较，如果一致就认为匹配，否则认为不匹配。
如果没有路由项能够匹配，则丢弃该IP报文并发送ICMP报文。

网络层的最后

在得到下一跳的IP地址后，利用ARP协议转换为MAC地址后，需要将其连同IP数据报交付给数据链路层。

• 根据ARP协议将下一跳的IP地址转换为MAC地址

1. 主机A首先查看自己的ARP表，确定其中是否包含有主机B对应的ARP表项。如果找到了对应的MAC地址，则主机A直接利用ARP表中的MAC地址，对IP数据包进行帧封装，并将数据包发送给主机B。
2. 如果主机A在ARP表中找不到对应的MAC地址，则将缓存该数据报文，然后以广播方式发送一个ARP请求报文。（详情可以看4.2IPV4）
   ARP请求报文中的发送端IP地址和发送端MAC地址为主机A的IP地址和MAC地址，目标IP地址和目标MAC地址为主机B的IP地址和全0的MAC地址。

由于ARP请求报文以广播方式发送，该网段上的所有主机都可以接收到该请求，但只有被请求的主机（即主机B）会对该请求进行处理。
如果是向另一网络上的主机进行发送和，则路由器会响应给其对应的硬件地址

3. 主机B比较自己IP地址和ARP请求报文中的目标IP地址，当两者相同时进行如下处理：将ARP请求报文中的发送端（即主机A）的IP地址和MAC地址存入自己的ARP表中。
   之后以单播方式发送ARP响应报文给主机A，其中包含了自己的MAC地址。
4. 主机A收到ARP响应报文后，将主机B的MAC地址加入到自己的ARP表中以用于后续报文的转发，同时将IP数据包进行封装后发送出去。

ARP协议在OSI参考模型中属于数据链路层，而在TCP/IP模型中属于网络层**。

ARP（地址解析协议）是一个用于将网络层的IP地址转换为数据链路层的物理地址（如以太网MAC地址）的协议。在两个不同的网络模型中，ARP的位置有所不同：

• 在OSI模型中：ARP工作在数据链路层。这是因为ARP的主要功能是在同一局域网内解析出设备的物理地址，这个过程涉及到数据链路层的帧和物理层的硬件地址。
• 在TCP/IP模型中：ARP被视为网络层的一部分。这是因为ARP为IP地址到物理地址的映射提供服务，而IP地址是网络层的概念。在TCP/IP模型中，ARP直接生成自己的报文，不需要经过IP协议的封装，然后这些报文会被数据链路层协议（如以太网）进一步封装。

基于功能来考虑，ARP是链路层协议；基于分层/包封装来考虑，ARP是网络层协议。

数据链路层

对IP数据报的处理

在得到对应的MAC地址和IP数据报后可以将其封装成MAC帧

• 将IP数据报进行封装成帧
  封装成帧是指数据链路层给上层交付的协议数据单元添加帧头和帧尾使之成为帧。

帧头和帧尾中包含有重要的控制信息。(源地址为本机MAC地址，目的地址为上层交付到的MAC地址，这里MAC地址可以说是适配器的MAC地址（网卡）)
帧头和帧尾的作用之一就是帧定界

数据链路层的MAC寻址

• 交换机:
  工作在数据链路层,是基于MAC地址识别,能够完成数据包封装转发的网络设备;主要用于构建局域网;具有流量控制能力;交换机有自学习功能，并且学习过的内容不是一直保存的，在经过一定时间就会删除。所以交换表有三列：MAC地址 端口 写入时间
• 交换机在使用直通交换时，转发MAC帧只检查帧的目的MAC地址(6B)以此决定转发端口。缺点是不检查差错，可能将无效帧给转发给其他的站。
• 兜圈子：从所有端口转发很可能就不断的进行循环，造成资源浪费：采用生成树协议去逻辑上切断某些链路，使得一台主机到所有其他主机的路径是无环路的树状结构。

MAC地址寻址是,首先通过广播包获取足够的MAC地址表,然后维护这个MAC地址表(反映各端口与MAC地址之间的关系,便于后面的数据转发)

数据链路层的最后

将MAC帧交付给物理层

物理层

对MAC帧的处理

• 插入8B的前导码，通过物理层将构成帧的各比特，转换成电信号发送到传输媒体

• 前导码中的前7个字节为前同步码，作用是便接收万的时钟同步。

• 之后的1字节为帧开始定界符，表明其后面是跟着的就是MAC帧。
• 另外，以太网还规定了帧间可隔时间为96比特的发送时间。
• 因此，MAC帧并不需要帧结束定界符。

服务器响应

服务端将数据包通过数据链路层->网络层->传输层一层层的解封,最后处理HTTP中的请求

发出HTTP响应报文

1. HTTP响应包含以下内容：

状态行：包括HTTP版本、响应状态码和对应的状态消息；
响应头部：包括一系列关于响应的元数据，如Content-Type、Content-Length、Server等；
空行：响应头部和响应正文之间需要空一行；
响应正文：包含响应的数据，如HTML、XML、JSON等文档格式、图片、音频、视频等二进制数据等等。

2. HTTP响应报文状态码
   状态码（status code）是在HTTP协议中用于表示服务器对客户端请求的处理结果的数字代码。通过状态码，客户端可以了解到请求的处理结果，如访问是否成功、是否需要重定向、是否存在错误等。

1xx：信息性响应

100：继续（Continue）- 表示服务器接收到请求，客户端可以继续发送请求的剩余部分。
101：切换协议（Switching Protocol s）- 表示服务器正在切换协议，例如从HTTP切换到WebSocket。

2xx：成功响应

200：成功（OK）- 表示请求已成功处理，并返回相应的内容。
201：已创建（Created）- 表示请求已成功处理，并在服务器上创建了新的资源。
204：无内容（No Content）- 表示请求已成功处理，但没有返回任何内容。

3xx：重定向

301：永久重定向（Moved Permanently）- 请求的资源已永久移动到新位置。
302：临时重定向（Found）- 请求的资源临时移动到其他位置。
304：未修改（Not Modified）- 表示客户端的缓存资源仍有效，可以直接使用缓存的内容。

4xx：客户端错误

400：错误请求（Bad Request）- 请求无效或不可理解。
401：未授权（Unauthorized）- 请求需要身份验证。
403 ：不可访问（Forbidden）表⽰访问被拒绝.有的⻚⾯通常需要⽤⼾具有⼀定的权限才能访问(登陆后才能访问).如果⽤⼾没有登陆 直接访问,就容易⻅到403.
404：未找到（Not Found）- 请求的资源不存在。

5xx：服务器错误

500：服务器内部错误（Internal Server Error）- 服务器遇到了意外情况，无法完成请求。
503：服务不可用（Service Unavailable）- 服务器暂时无法处理请求，通常是因为过载或维护。
504：超时（GatewayTimeout） 当服务器负载⽐较⼤的时候,服务器处理单条请求的时候消耗的时间就会很⻓,就可能会导致出现超时 的情况.

3. HTTP响应的"正文"(body)
   是指服务器返回给客户端的实际数据内容。正文通常包含了请求所需要的信息，如HTML、XML、JSON等文档格式、图片、音频、视频等二进制数据等等。

在HTTP响应中，正文通常跟随在响应头部分的后面，使用空行来分隔。响应头部分包含了HTTP协议版本、状态码、响应头字段等元数据信息，而正文则包含了具体的数据内容。例如，一个HTTP响应的格式通常如下所示：

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234

Welcome to Example Website!

This is an example website.

cookie

客户端请求服务器后，如果服务器需要记录用户状态，服务器会在响应信息中包含一个Set-Cookie的响应头，客户端会根据这个响应头存储Cookie信息。再次请求服务器时，客户端会在请求信息中包含一个Cookie请求头，而服务器会根据这个请求头进行用户身份、状态等较验。

浏览器解析响应报文

浏览器解析html代码，并请求html代码中的资源

浏览器拿到html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这时候就用上 keep-alive(HTTP/1.1)了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序。

浏览器渲染

浏览器利用自己内部的工作机制，把请求的静态资源和html代码进行渲染，渲染之后呈现给用户，浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。

这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。
页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载。

TCP连接断开

四次挥手结束TCP传输