这篇文文章我们将详细讲解网络通信的整个流程
当我们在浏览器中输入地址到浏览器返回页面给我们这中间究竟发生了什么?
总的来说有以下六个点
- 网络模型
- 浏览器与服务器建立连接(三次握手)
- 浏览器发送请求报文(HTTP协议)
- 服务器返回响应报文(HTTP协议)
- 浏览器渲染页面
- (看我之前的浏览器渲染原理这篇文章)
- 浏览器与服务器断开连接(四次挥手)
1.网络模型
1.七层网络模型(了解)
七层网络模型(OSI 模型)
七层网络模型,也称为 OSI 模型(Open Systems Interconnection Model),是由国际标准化组织(ISO)提出的一种概念框架,用于描述和标准化网络通信系统的功能。该模型将网络通信过程分为七个层次,每一层都有特定的功能,并且各层之间相互协作以实现完整的通信。
1. 物理层(Physical Layer)
- 功能:负责传输原始比特流(0 和 1),定义了物理连接的电气、机械、过程和功能特性。
- 设备:电缆、集线器、中继器等。
- 协议:无具体协议,但涉及标准如 IEEE 802.3 (Ethernet)。
2. 数据链路层(Data Link Layer)
- 功能:负责节点之间的可靠数据传输,包括帧同步、错误检测与纠正、流量控制等。
- 子层:
- 逻辑链路控制(LLC):提供与高层协议的接口。
- 媒体访问控制(MAC):管理多个设备共享同一物理介质的访问。
- 设备:网桥、交换机。
- 协议:Ethernet、Wi-Fi (IEEE 802.11)、PPP 等。
3. 网络层(Network Layer)
- 功能:负责路由选择和分组转发,确保数据包从源地址正确传输到目的地址。
- 设备:路由器。
- 协议:IP、ICMP、ARP、RIP 等。
4. 传输层(Transport Layer)
- 功能:提供端到端的可靠或不可靠数据传输服务,负责错误恢复和流量控制。
- 协议:
- TCP(Transmission Control Protocol):面向连接、可靠的传输协议,提供错误检测、重传机制和流量控制。
- UDP(User Datagram Protocol):无连接、不可靠的传输协议,适用于实时应用(如视频流、语音通话)。
5. 会话层(Session Layer)
- 功能:负责建立、管理和终止应用程序之间的会话,提供对话控制和同步功能。
- 协议:NetBIOS、RPC(远程过程调用)、PPTP 等。
6. 表示层(Presentation Layer)
- 功能:负责数据格式转换、加密解密、压缩解压等,确保不同系统之间的数据表示一致。
- 协议:SSL/TLS、JPEG、MPEG、ASCII、EBCDIC 等。
7. 应用层(Application Layer)
- 功能:直接为用户提供网络服务,支持各种应用程序的通信需求。
- 协议:HTTP、HTTPS、FTP、SMTP、DNS、Telnet 等。
在实际应用中,特别是互联网通信,通常使用的是 TCP/IP 模型,它是一个四层模型
2.四层网络模型(了解)
四层网络模型(TCP/IP 模型)
四层网络模型,也称为 TCP/IP 模型,是互联网通信的基础框架。它简化了 OSI 七层模型,将网络通信过程分为四个层次,每一层都有特定的功能,并且各层之间相互协作以实现完整的通信。以下是四层网络模型的详细介绍:
1. 应用层(Application Layer)
- 功能:直接为用户提供网络服务,支持各种应用程序的通信需求。
- 协议:HTTP、HTTPS、FTP、SMTP、DNS、Telnet 等。
- 描述:这一层负责处理特定的应用程序细节,如网页浏览、文件传输、电子邮件等。它定义了应用程序如何通过网络发送数据。
2. 传输层(Transport Layer)
- 功能:提供端到端的可靠或不可靠数据传输服务,负责错误恢复和流量控制。
- 协议:
- TCP(Transmission Control Protocol):面向连接、可靠的传输协议,提供错误检测、重传机制和流量控制。
- UDP(User Datagram Protocol):无连接、不可靠的传输协议,适用于实时应用(如视频流、语音通话)。
- 描述:该层确保数据能够从源端正确地传输到目的端,同时提供了不同级别的可靠性保证。
3. 网络层(Internet Layer)
- 功能:负责路由选择和分组转发,确保数据包从源地址正确传输到目的地址。
- 协议:IP、ICMP、ARP、IGMP 等。
- 描述:这一层使用 IP 地址来标识主机,并决定数据包在网络中的最佳路径。它不保证数据包按顺序到达,也不保证数据包一定能够到达目的地。
4. 网络接口层(Network Interface Layer)
- 功能:负责在物理网络上发送和接收数据帧,包括帧同步、错误检测与纠正、流量控制等。
- 设备:电缆、集线器、中继器、网桥、交换机等。
- 描述:这一层结合了 OSI 模型中的物理层和数据链路层,管理多个设备共享同一物理介质的访问,以及实际的数据传输过程。
各层之间的交互
在 TCP/IP 模型中,每一层都依赖于下一层提供的服务,并为上一层提供服务。例如,当浏览器发送一个 HTTP 请求时,它首先通过应用层(HTTP 协议),然后依次经过传输层(TCP 或 UDP)、网际层(IP),最终通过网络接口层发送到网络中。接收方则按相反顺序处理接收到的数据。
简单来说
应用层
- 软件的层面,浏览器 服务器都属于应用层
传输层
- 负责对数据进行拆分,把大数据拆分为一个一个小包
网络层
- 负责给数据包,添加信息
网络接口层
- 传输信息
3.DNS解析(掌握)
通俗DNS 解析的具体流程
你正在找一个朋友的新家。你只知道他家的门牌号(域名),但你需要具体的地址(IP地址)才能找到它。以下是你会经历的步骤:
1.检查本地缓存:
你首先查看自己的笔记本(本地DNS缓存),看看是否之前已经记下了这个门牌号对应的详细地址。如果有,直接按照记录去就好。这一步减少了重复查询的时间。
2递归解析器请求:
如果没有记录,你就去找街区向导(递归解析器,比如在阿里云购买的域名,它会提供域名解析器),请求帮助查找具体地址。街区向导承诺帮你找到答案,并负责处理整个查询过程直至获取结果。
3.根域名服务器查询:
街区向导不确定具体位置,于是先咨询城市总图(根域名服务器)。根域名服务器是DNS层次结构中的最高级别,它不会提供具体的IP地址,而是根据所查询域名的顶级域(如.com, .org),指引递归解析器到下一步应该联系的服务器。
4.顶级域名服务器查询:
根据城市总图提供的信息,街区向导再去找负责该区域的地图(顶级域名服务器)。顶级域名服务器管理特定顶级域的所有域名信息。对于.com域名,它会返回负责该域名的权威域名服务器的信息。
5.权威域名服务器查询:
最后,街区向导向负责这条街的具体地图管理员(权威域名服务器)询问,得到你朋友家的确切地址(IP地址)。权威域名服务器存储着关于其管理下的域名的具体信息,包括与域名关联的IP地址。
6.响应客户端并缓存结果:
街区向导返回给你详细的地址,并且为了方便下次有人问同样问题,他会把这个地址记在他的笔记本上(缓存结果)。这样,如果未来有相同的查询,可以快速从缓存中获取答案,而无需再次遍历整个解析流程。
通过这种方式,你可以知道如何到达朋友的新家。在互联网上,DNS解析过程也类似,只是这一切都在几毫秒内自动完成,让你可以快速访问网站。这种机制确保了互联网通信既高效又便捷。
作为前端开发我们一般只关注于应用层
我们只需要知道我们在浏览器输入网址之后通过DNS解析我们拿到了域名所对应的IP地址,
并将这些数据包装成了一个个的请求报文接下来就要开始与服务器通信了
2.浏览器与服务器建立连接(三次握手)
在浏览器与服务器之间建立 TCP 连接的过程中,会使用 三次握手(Three-Way Handshake)机制来确保双方能够可靠地通信
1. 第一次握手:SYN(同步序列编号)
- 客户端(浏览器)发送 SYN 报文段:
- 客户端向服务器发送一个带有
SYN
标志的 TCP 报文段。- 报文段中包含一个初始序列号(ISN, Initial Sequence Number),表示客户端希望开始的数据传输的起始位置。
- 此时,客户端进入 SYN_SENT 状态,等待服务器的确认。
2. 第二次握手:SYN + ACK(同步确认)
- 服务器接收 SYN 并发送 SYN + ACK 报文段:
- 服务器收到客户端的
SYN
报文段后,会分配必要的资源(如缓冲区)来处理这个连接。- 服务器向客户端发送一个带有
SYN
和ACK
标志的 TCP 报文段。- 报文段中包含服务器的初始序列号(ISN),以及对客户端序列号的确认(ACK = 客户端 ISN + 1)。
- 此时,服务器进入 SYN_RCVD 状态,等待客户端的最终确认。
3. 第三次握手:ACK(确认)
- 客户端接收 SYN + ACK 并发送 ACK 报文段:
- 客户端收到服务器的
SYN + ACK
报文段后,确认服务器已经准备好并可以进行数据传输。- 客户端向服务器发送一个带有
ACK
标志的 TCP 报文段。- 报文段中包含对服务器序列号的确认(ACK = 服务器 ISN + 1)。
- 此时,客户端进入 ESTABLISHED 状态,表示连接已成功建立。
- 服务器收到客户端的
ACK
报文段后,也进入 ESTABLISHED 状态,连接正式建立。
看图说话简单明了
3.HTTP协议
HTTP协议就是应用层的协议, 用来规定客户端和服务器间通信的报文格式的
HTTP(HyperText Transfer Protocol,超文本传输协议)是用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。
- 无状态性:HTTP是一种无状态协议,服务器不会保存客户端的请求记录,每个请求都是独立的。
- 请求-响应模型:HTTP基于请求-响应模式。客户端发送一个请求到服务器,服务器处理后返回一个响应。
- 方法:
GET
:请求获取由URL所标识的资源。POST
:向指定资源提交数据进行处理(例如提交表单),数据包含在请求体中。PUT
:上传客户端的文件或更新现有资源。DELETE
:删除指定的资源。HEAD
:与GET类似,但服务器只返回状态行和头部,不返回实体主体部分。OPTIONS
:询问服务器支持哪些请求方法。
- 状态码:HTTP响应包含一个三位数的状态码,表示请求的结果。
2xx
表示成功。3xx
表示重定向。4xx
表示客户端错误。5xx
表示服务器错误。
- 版本:
- HTTP/1.0:简单直接,每次请求建立新的连接。
- HTTP/1.1:引入了持久连接和管道化,提高了效率。
- HTTP/2:二进制分帧、头部压缩、多路复用等特性,进一步提升了性能。
- HTTP/3:基于QUIC协议,改进了网络抖动和丢包情况下的传输效率。
1.看看请求报文
请求头解析
- Accept:
application/json, text/plain, */*
- 表示客户端可以接受的内容类型,优先接受JSON格式的数据,其次是纯文本,最后是任何类型。
- Accept-Encoding:
gzip, deflate, br, zstd
- 表示客户端支持的压缩算法,包括
gzip
、deflate
、br
(Brotli)和zstd
。
- Accept-Language:
zh-CN,zh;q=0.9
- 表示客户端首选的语言为简体中文(
zh-CN
),其次是通用中文(zh
),权重为0.9。
- Authorization:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTg4MTAxLCJpYXQiOjE3MzQ2ODY2MDksImV4cCI6MTczNDY5MzgwOX0.YyOgRSfVI7nNC_i9Me4M4uBDo3OYtTl4E5QsYHJZzOc
- 这是一个JWT(JSON Web Token),用于身份验证。它包含了用户的身份信息和其他元数据,经过签名以确保其完整性。
- Connection:
keep-alive
- 表示客户端希望保持连接打开,以便后续请求复用同一个TCP连接,提高性能。
- Content-Length:
49
- 表示请求体的长度为49字节。
- Content-Type:
application/json
- 表示请求体的内容类型为JSON格式。
- Host:
hmajax.itheima.net
- 表示请求的目标主机名和端口号。
- Origin:
http://127.0.0.1:5500
- 表示请求的来源页面所在的域名和端口,用于CORS(跨域资源共享)检查。
- Referer:
http://127.0.0.1:5500/
- 表示发出请求的页面URL,通常用于统计分析或安全检查。
- Sec-CH-UA:
"Google Chrome";v="131", "Chromium";v="131", "Not_A Brand";v="24"
- 表示客户端使用的浏览器及其版本信息。
- Sec-CH-UA-Mobile:
?0
- 表示客户端是否为移动设备,
?0
表示不是移动设备。
- Sec-CH-UA-Platform:
"Windows"
- 表示客户端的操作系统平台。
- Sec-Fetch-Dest:
empty
- 表示请求的目标资源类型,
empty
通常用于非导航请求。
- Sec-Fetch-Mode:
cors
- 表示请求模式为跨域资源共享(CORS)。
- Sec-Fetch-Site:
cross-site
- 表示请求的来源站点与目标站点不同,即跨站请求。
- User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
- 表示客户端的浏览器和操作系统信息。
总结
这组请求头表明这是一个从本地开发环境(http://127.0.0.1:5500
)发起的跨域AJAX请求,目标服务器为hmajax.itheima.net
,并且使用了JWT进行身份验证。请求体为JSON格式,长度为49字节。服务器可能会根据这些头信息来处理请求并返回适当的内容。
2.看看响应报文
响应头解析
- HTTP/1.1 200 OK:
- 表示HTTP协议版本为1.1,状态码为200,意味着请求成功。
- Date: Sat, 21 Dec 2024 01:52:55 GMT:
- 表示服务器生成响应的时间,使用GMT时区。
- Content-Type: application/json; charset=utf-8:
- 表示响应体的内容类型为JSON格式,并且字符编码为UTF-8。
- Content-Length: 83:
- 表示响应体的长度为83字节。
- Connection: keep-alive:
- 表示服务器希望保持连接打开,以便后续请求复用同一个TCP连接,提高性能。
- Set-Cookie: acw_tc=...;path=/;HttpOnly;Max-Age=1800:
- 设置一个名为
acw_tc
的Cookie,有效期为1800秒(30分钟),并且标记为HttpOnly
,表示该Cookie只能通过HTTP(S)请求访问,不能通过JavaScript访问。
- Server: nginx:
- 表示服务器使用的Web服务器软件为Nginx。
- Vary: Origin:
- 表示响应的内容会根据
Origin
头的不同而变化,主要用于缓存控制。
- Access-Control-Allow-Origin: http://127.0.0.1:5500:
- 允许来自
http://127.0.0.1:5500
的跨域请求。
- Access-Control-Allow-Credentials: true:
- 表示允许发送凭据(如Cookies、HTTP认证信息)。
- Accept-Ranges: bytes:
- 表示服务器支持部分请求(分块下载)。
- x-frame-options: SAMEORIGIN:
- 禁止页面被嵌入到其他域名的页面中,防止点击劫持攻击,只允许同源页面嵌入。
- x-xss-protection: 1; mode=block:
- 启用浏览器的XSS过滤器,并在检测到XSS攻击时阻止渲染页面。
- x-content-type-options: nosniff:
- 禁止浏览器猜测MIME类型,强制按照服务器指定的类型处理响应内容。
- x-download-options: noopen:
- 禁止用户直接打开下载的文件,防止潜在的安全风险。
- x-readtime: 212:
- 表示服务器处理请求并生成响应所花费的时间为212毫秒。
- Referrer-Policy: no-referrer-when-downgrade:
- 当从HTTPS降级到HTTP时,不发送Referer头,以保护用户隐私。
- X-Download-Options: noopen:
- 重复了
x-download-options
,确保浏览器正确处理下载选项。
- X-Content-Type-Options: nosniff:
- 重复了
x-content-type-options
,确保浏览器正确处理MIME类型。
- X-Permitted-Cross-Domain-Policies: none:
- 禁止跨域策略文件的加载,防止跨域资源共享漏洞。
总结
这组响应头表明服务器成功处理了客户端的请求,并返回了一个JSON格式的响应。服务器还设置了多个安全相关的头信息,以增强安全性,例如防止XSS攻击、点击劫持和MIME类型嗅探等。此外,服务器允许来自http://127.0.0.1:5500
的跨域请求,并设置了会话Cookie。
3.看看HTTP状态码
HTTP 状态码用于指示 HTTP 请求的处理结果,它们被分为五类,每类都有特定的含义。为了帮助记忆,可以将这些类别简化为“信息、成功、重定向、客户端错误、服务器错误”
HTTP 状态码分类 - 记住“信、成、重、客、服”
- 信:1xx 信息性响应
- 表示请求已接收,继续处理。
- 100 Continue:服务器已收到请求头,并要求客户端发送请求体(如果有)。
- 成:2xx 成功
- 表示请求已成功处理。
- 200 OK:请求成功,返回的数据通常包含在响应体中。
- 201 Created:请求成功并且创建了一个新的资源,通常用于 POST 请求后。
- 204 No Content:请求成功但没有新内容返回。
- 重:3xx 重定向
- 表示需要进一步操作以完成请求,通常浏览器会自动处理这些重定向。
- 301 Moved Permanently:请求的资源已被永久移动到新位置。
- 302/307 Found(临时重定向):请求的资源现在暂时从不同的 URI 响应请求
- 因为 307 不会改变请求方法,所以对于涉及敏感数据的操作(如提交表单),使用 307 比 302 更安全。
- 304 Not Modified:资源未修改,客户端可以使用缓存版本。
- 客:4xx 客户端错误
- 表示请求包含语法错误或无法完成。
- 400 Bad Request:服务器无法理解请求的格式。
- 401 Unauthorized:请求需要用户认证。
- 403 Forbidden:服务器理解请求,但拒绝执行。
- 404 Not Found:请求的资源不存在于服务器上。
- 405 Method Not Allowed:请求方法对于指定的资源不合法。
- 服:5xx 服务器错误
- 表示服务器在处理请求时发生了某种错误。
- 500 Internal Server Error:服务器遇到意外情况,无法完成请求。
- 502 Bad Gateway:服务器作为网关或代理,从上游服务器收到无效响应。
- 503 Service Unavailable:服务器暂时无法处理请求,可能过载或停机维护。
- 504 Gateway Timeout:服务器作为网关或代理,未能及时从上游服务器获得响应。
4.浏览器与服务器断开连接(四次挥手)
浏览器与服务器断开连接的过程称为四次挥手(Four-Way Handshake),具体步骤如下:
- 第一次挥手 (FIN)
- 客户端发送一个FIN标志的数据包给服务器,表示客户端已经没有数据要发送了,想要关闭连接。
- 第二次挥手 (ACK)
- ACK是"Acknowledgment"(确认)
- 服务器接收到客户端的FIN请求后,会发送一个ACK确认包给客户端,表示已收到客户端的断开请求。此时服务器可能还有未发送完的数据。
- 第三次挥手 (FIN ACK)
- 当服务器确认所有数据都发送完毕后,会发送一个FIN标志的数据包给客户端,表示服务器也没有数据要发送了,同意断开连接。
- 第四次挥手 (ACK)
- 客户端接收到服务器的FIN请求后,发送一个ACK确认包给服务器,表示已收到服务器的断开请求。此时连接正式断开。
注意事项
- 四次挥手中,每个FIN和ACK都是独立的TCP段,确保双方都能安全地结束通信。
- 在实际网络环境中,如果一方在规定时间内没有收到对方的ACK响应,可能会重发FIN或ACK直到成功为止。
看图说话简单明了
标签:Node,网络通信,HTTP,请求,ACK,js,服务器,浏览器,客户端 From: https://blog.csdn.net/weixin_67448099/article/details/145016295