OSI 7层模型
应用层 应用层是ISO七层模型的最高层,它直接与用户和应用程序交互,提供用户与网络的接口。它包括各种应用协议,如HTTP、FTP、SMTP等,用于实现特定应用的功能和通信
表示层 表示层负责数据的格式转换、加密和压缩,以确保不同系统之间的数据格式兼容性,并提供数据安全和加密功能
会话层 会话层负责建立、管理和终止会话(Session)或连接。它提供了会话的同步、管理和恢复功能,以确保不同应用程序之间的通信顺利进行
传输层 传输层负责端到端的数据传输和可靠性。它提供了传输控制协议(TCP)和用户数据报协议(UDP)等传输协议,用于实现可靠的数据传输、流量控制和错误恢复
网络层 网络层负责在不同的网络之间进行路由和转发,以确保数据能够正确地从源节点传输到目标节点。它处理逻辑地址(如IP地址),选择最佳路径,并进行分组和路由选择
数据链路层 数据链路层位于物理层之上,负责在直接相连的节点之间传输数据。它将比特流划分为帧(Frame),并提供了错误检测、流控制和访问控制等功能,以确保可靠的数据传输
物理层 物理层是ISO七层模型的最底层,负责在物理媒介上传输原始比特流。它定义了电压、电缆规范、物理连接和传输速率等物理特性
nginx的七层代理和四层转发
Nginx的七层代理和四层转发是Nginx在网络架构中常用的两种技术,它们在处理网络请求时的工作层次和方式有所不同。以下是对这两种技术的详细解释:
一、Nginx七层代理
1. 定义与背景
Nginx的七层代理,也称为HTTP代理或应用层代理,工作在OSI模型的第七层(应用层)。它主要处理HTTP、HTTPS等应用层协议的数据,通过解析这些协议的请求和响应内容,实现请求的转发、负载均衡、缓存、安全等功能。
2. 实现原理
- 协议解析:Nginx接收客户端的HTTP或HTTPS请求后,会解析请求头、请求体等应用层信息。
- 负载均衡:根据配置的策略(如轮询、权重、最少连接数等),Nginx将请求转发到后端服务器。
- 功能扩展:Nginx的七层代理支持URL重写、SSL/TLS加密解密、缓存、会话保持等多种功能,可以灵活应对各种业务需求。
3. 常用使用场景
- Web服务负载均衡:对于HTTP/HTTPS协议的Web服务,Nginx可以实现基于URL、Cookie等信息的智能负载均衡。
- API网关:在微服务架构中,Nginx可以作为API网关,实现请求的路由、认证、限流等功能。
- 安全加固:通过SSL/TLS加密解密,Nginx可以提升数据传输的安全性。
二、Nginx四层转发
1. 定义与背景
Nginx的四层转发,也称为TCP/UDP代理或传输层代理,工作在OSI模型的第四层(传输层)。它主要处理TCP或UDP协议的数据包,通过IP地址和端口号进行转发和负载均衡,而不需要解析应用层协议的内容。
需要注意的是,Nginx的四层转发功能是通过stream模块实现的,该模块在Nginx 1.9.0及以后的版本中可用。
2. 实现原理
- 基于IP+端口转发:Nginx接收客户端的TCP或UDP请求后,会根据数据包的源IP地址、目标IP地址、源端口号和目标端口号等信息进行转发决策。
- 负载均衡算法:Nginx支持多种负载均衡算法(如轮询、最少连接数等),以确保请求的均匀分布。
- 无状态转发:Nginx的四层转发通常是无状态的,即它不会维护会话状态,每个数据包都被独立地转发。
3. 常用使用场景
- 数据库负载均衡:对于MySQL、Redis等数据库服务,Nginx的四层转发可以实现高效的负载均衡,提高数据库的访问性能。
- 非HTTP服务负载均衡:对于基于TCP/UDP协议的非HTTP服务(如SSH、FTP等),Nginx的四层转发是更合适的选择。
- 高性能需求场景:由于四层转发不需要解析应用层协议的内容,因此具有较低的处理成本和延迟,适用于对性能要求较高的场景。
三、比较与总结
Nginx七层代理 | Nginx四层转发 | |
---|---|---|
工作层次 | OSI第七层(应用层) | OSI第四层(传输层) |
协议解析 | 解析HTTP、HTTPS等应用层协议 | 不解析应用层协议,仅基于IP+端口转发 |
负载均衡决策依据 | 基于URL、Cookie、Header等应用层信息 | 基于IP地址、端口号等传输层信息 |
功能扩展 | 支持URL重写、SSL/TLS加密解密、缓存、会话保持等 | 主要关注数据传输的负载均衡和转发 |
性能特点 | 处理成本较高,但灵活性强,适用于需要处理应用层数据的场景 | 处理成本低,延迟小,适用于对性能要求高且不需要处理应用层数据的场景 |
使用场景 | Web服务负载均衡、API网关、安全加固等 | 数据库负载均衡、非HTTP服务负载均衡、高性能需求场景 |
综上所述,Nginx的七层代理和四层转发各有其特点和适用场景。在实际应用中,可以根据具体需求选择合适的技术方案。
TCP,UDP协议区别
- TCP协议:面向连接,传输可靠,字节流传输,传输效率慢,所需资源多,应用场景(要求通信数据可靠:文件传输,邮件传输,远程登录),首部字节20-60;
- UDP协议:无连接,不可靠,以数据报文段的形式传输,传输效率快,所需资源少,应用场景(要求通信速度快,如域名转换,qq语音,直播),首部字节8个,由4个字段组成;
UDP 在传送数据之前不需要先建立连接,远地主机在收到 UDP 报文后,不需要给出任何确认。虽然 UDP 不提供可靠交付,但在某些情况下 UDP 确是一种最有效的工作方式(一般用于即时通信),比如: QQ 语音、 QQ 视频 、直播等等
TCP 提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的,面向连接的运输服务(TCP的可靠体现在TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源),这一难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
打开一个链接 --》显示主页的过程
OSPF:Open Shortest Path First开放式最短路径优先
ARP:Address Resolution Protocol地址解析协议
MAC:(Media Access Control或者Medium Access Control)地址,意译为媒体访问控制,或称为物理地址、硬件地址,用来定义网络设备的位置。在OSI模型中,第三层网络层负责 IP地址,第二层数据链路层则负责 MAC地址。因此一个主机会有一个MAC地址,而每个网络位置会有一个专属于它的IP地址。 [1]
MAC地址是网卡决定的,是固定的
TCP三次握手和四次挥手
客户端–发送带有 SYN 标志的数据包–一次握手–服务端
服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端
为什么要三次握手?
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
第一次握手:Client 什么都不能确认;Server 确认了对方发送正常
第二次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己接收正常,对方发送正常
第三次握手:Client 确认了:自己发送、接收正常,对方发送、接收正常;Server 确认了:自己发送、接收正常,对方发送接收正常
所以三次握手就能确认双发收发功能都正常,缺一不可。
为什么要传回 SYN
接收端传回发送端所发送的 SYN 是为了告诉发送端,我接收到的信息确实就是你所发送的信号了。
SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时,客户机首先发出一个 SYN 消息,服务器使用 SYN-ACK 应答表示接收到了这个消息,最后客户机再以 ACK(Acknowledgement[汉译:确认字符 ,在数据通信传输中,接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ])消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接,数据才可以在客户机和服务器之间传递。
传了 SYN,为啥还要传 ACK
双方通信无误必须是两者互相发送信息都无误。传了 SYN,证明发送方到接收方的通道没有问题,但是接收方到发送方的通道还需要 ACK 信号来进行验证。
断开一个 TCP 连接则需要“四次挥手”:
客户端-发送一个 FIN,用来关闭客户端到服务器的数据传送
服务器-收到这个 FIN,它发回一 个 ACK,确认序号为收到的序号加1 。和 SYN 一样,一个 FIN 将占用一个序号
服务器-关闭与客户端的连接,发送一个FIN给客户端
客户端-发回 ACK 报文确认,并将确认序号设置为收到序号加1
为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。
举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。
上面讲的比较概括,推荐一篇讲的比较细致的文章:
blog.youkuaiyun.com/qzcsu/artic…
参考:https://juejin.im/post/5ba591386fb9a05cd31eb85f