OSI 体系结构是法律上的国家标准,从上往下讲分别是:
OSI 的七层体系结构概念清楚,理论也很完整,但是它比较复杂而且不实用,而且有些功能在多个层中重复出现。
TCP/IP 四层模型 是目前被广泛采用的一种模型,我们可以将 TCP / IP 模型看作是 OSI 七层模型的精简版本,是事实上的国家标准。
它们分别是:
作用
应用层 – 主要作用是 – 解决通过应用进程的交互来实现特定网络应用的问题
传输层 – 主要作用是 – 解决进程之间基于网络的通信问题
网络层 – 主要作用是 – 解决分组在多个网络上传输 (路由) 的问题
网络接口层 – 主要作用是 – 解决分组在一个网络 (或一段链路) 上传输以及使用何种信号来传输比特的问题
计算机网络体系结构之所以要分层,主要是为了实现模块化和分工合作的设计思想,将整个网络系统分解为若干个相对独立的层次,每层都有自己的功能和责任,便于设计、实现和维护网络系统。同时,分层还可以提高网络的灵活性和可扩展性,使得网络系统更易于适应不同的应用需求和技术变革。
但这些名词并没有什么本质的区分,可以统称为数据包。
9 个:HTTP、SMTP、POP3、IMAP、FTP、Telnet、SSH、RTP、DNS
传输控制协议 TCP 和 用户数据协议 UDP
7 个:IP、ARP、ICMP、NAT、OSPF、RIP、BGP
总体来说分为以下几个过程:
期间使用到的协议:
思考:ip 地址与 MAC 地址的区别?
HTTP 状态码主要有五大类,用于描述 HTTP 请求的结果。
比如:
类别 | 具体含义 | 常见状态码 | |
---|---|---|---|
1xx | Informational(信息性状态码) | 提示信息,接收的请求正在处理,表示目前是协议处理的中间状态,还需要后续的操作 | |
2xx | Success (成功状态码) | 成功,请求正常处理完毕 | 200、204、206 |
3xx | Redirection (重定向状态码) | 重定向,资源位置发生变动,需要客户端重新发送请求 | 301、302、304 |
4xx | Client Error (客户端错误状态码) | 客户端错误,请求报文有误,服务器无法处理请求 | 400、403、404 |
5xx | Server Error (服务器错误状态码) | 服务器错误,服务器在处理请求时内部发生了错误 | 500、501、502、503 |
思考:每个常见状态码的含义?
客户端发送请求时,用来指定服务器的域名。
有了 Host
字段,就可以将请求发往「同一台」服务器上的不同网站。
示例
Host: www.A.com
Host: en.wikipedia.org:80
服务器在返回数据时,会有 Content-Length
字段,表明本次回应的数据长度。
比如:
Content-Length: 1000
如上面则是告诉浏览器,本次服务器回应的数据长度是 1000 个字节,后面的字节就属于下一个回应了。
PS:大家应该都知道 HTTP 是基于 TCP 传输协议进行通信的,而使用了 TCP 传输协议,就会存在一个“粘包”的问题,HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界,通过 Content-Length 字段作为 HTTP body 的边界,这两个方式都是为了解决“粘包”的问题。
什么是 TCP 粘包问题?
Connection
字段最常用于客户端要求服务器使用「HTTP 长连接」机制,以便其他请求复用。
HTTP 长连接的特点是:只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。
HTTP/1.1 版本的默认连接都是长连接,但为了兼容老版本的 HTTP,需要指定 Connection
首部字段的值为 Keep-Alive
。
Connection: Keep-Alive
开启了 HTTP Keep-Alive 机制后,连接就不会中断,而是保持连接。当客户端发送另一个请求时,它会使用同一个连接,一直持续到客户端或服务器端提出断开连接。
PS:HTTP Keep-Alive 和 TCP Keepalive 是不一样的,具体可以看这篇文章:TCP Keepalive 和 HTTP Keep-Alive 是一个东西吗?
Content-Type
字段用于服务器回应时,告诉客户端,本次数据是什么格式。(即代表数据格式)
比如:
// 下面类型表明,发送的是网页,而且编码是 UTF-8。
Content-Type: text/html; Charset=utf-8
客户端请求的时候,可以使用 Accept
字段声明自己可以接受哪些数据格式。
// 客户端声明自己可以接受任何格式的数据。
Accept: */*
具体如图所示:
Content-Encoding
字段指的是数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
// 服务器返回的数据采用了 gzip 方式压缩,告知客户端需要用此方式解压
Content-Encoding: gzip
客户端在请求时,用 Accept-Encoding
字段说明自己可以接受哪些压缩方法。
// 客户端能接受 gzip 和 deflate 的压缩数据
Accept-Encoding: gzip, deflate
具体如图所示:
主要有四个区别:
http://
,HTTPS 的 URL 前缀是 https://
。主要有五类区别:
连接方式:
状态响应码: HTTP/1.1 中新加入了大量的状态码,光是错误响应状态码就新增了 24 种。
比如说:
100 (Continue)
——在请求大资源前的预热请求;206 (Partial Content)
——范围请求的标识码;409 (Conflict)
——请求与当前资源的规定冲突;410 (Gone)
——资源已被永久转移,而且没有任何已知的转发地址。
缓存机制:
在 HTTP/1.0 中主要使用 Header 里的 If-Modified-Since,Expires 来做为缓存判断的标准;
HTTP/1.1 则引入了更多的缓存控制策略,例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
带宽:
206(Partial Content)
,这样就方便了开发者自由的选择以便于充分利用带宽和连接。Host 头(Host Header)处理:
主要有四个区别:
IO 多路复用(Multiplexing):
二进制帧(Binary Frames):
头部压缩(Header Compression):
HTTP/1.1 支持 Body
压缩,不支持 Header
压缩。
HTTP/2.0 支持对 Header
压缩,减少了网络开销。
服务器推送(Server Push):
传输协议:
HTTP/2.0 是基于 TCP 协议实现的。
HTTP/3.0 新增了 QUIC(Quick UDP Internet Connections)协议来实现可靠的传输,提供与 TLS/SSL 相当的安全性,具有较低的连接和传输延迟。
你可以将 QUIC 看作是 UDP 的升级版本,在其基础上新增了很多功能比如加密、重传等等。HTTP/3.0 之前名为 HTTP-over-QUIC,从这个名字中我们也可以发现,HTTP/3 最大的改造就是使用了 QUIC。
连接建立:
队头阻塞:
错误恢复:
HTTP/2.0 需要依赖于 TCP 的错误恢复机制。
而 HTTP/3.0 具有更好的错误恢复机制,当出现丢包、延迟等网络问题时,可以更快地进行恢复和重传。
安全性:
HTTP/2.0 和 HTTP/3.0 在安全性上都有较高的要求,支持加密通信,但在实现上有所不同。
HTTP 是一种不保存状态,即无状态(stateless)协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?
使用 Session 机制。
Session 机制的存在就是为了解决这个问题,Session 的主要作用就是:通过服务端记录用户的状态。
典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁这个 Session)。
在服务端保存 Session 的方法很多,最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。
1、既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?
大部分情况下,都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
2、Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。
URI(Uniform Resource Identifier):是统一资源标志符,可以唯一标识一个资源。
URI 示例,比如一个电子邮件地址:
mailto:[email protected]
// mailto: 是 URI 方案,后跟实际的电子邮件地址。
URL(Uniform Resource Locator):是统一资源定位符,可以提供该资源的路径(用于标识资源的地址)。它是一种具体的 URI,即 URL 可以用来标识一个资源,而且还指明了如何 locate 这个资源。
URL 示例,比如网页的地址:
https://www.example.com/index.html
https:// 是 URL 的协议部分
www.example.com 是主机名
index.html 是在服务器上的文件路径
URI 的作用像身份证号一样,URL 的作用更像家庭住址一样。URL 是一种具体的 URI,它不仅可以唯一标识资源,而且还提供了定位该资源的信息。
Cookie 和 Session 都是在 Web 开发中用于管理用户状态的技术,它们的主要区别有 5 个:
存储位置:
Cookie 保存在客户端,而 Session 保存在服务器端。
安全性:
由于 Cookie 保存在客户端,所以 Cookie 存在被恶意篡改的风险;而 Session 保存在服务器端,相对来说更加安全。
存储内容:
Cookie 保存的信息是明文的,而 Session 保存的信息是加密的。
生命周期:
Cookie 可以设置过期时间,而 Session 默认情况下在用户关闭浏览器后就会过期。
存储容量:
Cookie 存储的数据量有限制,一般为 4KB 左右;而 Session 存储的数据量没有限制,但是过多的 Session 会占用服务器的内存。
GET 的语义是从服务器获取指定的资源,这个资源可以是静态的文本、页面、图片视频等。(用 URL 传输数据)
GET 请求的参数位置一般是写在 URL 中,URL 规定只能支持 ASCII,所以 GET 请求的参数只允许 ASCII 字符 ,而且浏览器会对 URL 的长度有限制。(用 body 传输数据)
HTTP 协议本身对 URL 长度并没有做任何规定。
POST 的语义是根据请求负荷(报文body)对指定的资源做出处理,具体的处理方式视资源类型而不同。
POST 请求携带数据的位置一般是写在报文 body 中,body 中的数据可以是任意格式的数据,只要客户端与服务端协商好即可,而且浏览器不会对 body 大小做限制。
安全和幂等的概念:
- 在 HTTP 协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
- 所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的。
1、从 RFC 规范定义的语义来看:
简单总结一下:
2、从实际过程来看
在实际过程中,开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如:
如果单从信息是否会被泄漏来判定安全性的话,并不能说 GET 不如 POST 安全。
虽然 POST 用 body 传输数据,
而 GET 用 URL 传输,这样数据会在浏览器地址拦容易看到
因为 HTTP 传输的内容都是明文的,虽然在浏览器地址拦看不到 POST 提交的 body 数据,但是只要抓个包就都能看到了。
所以,要避免传输过程中数据被窃取,就要使用 HTTPS 协议,这样所有 HTTP 的数据都会被加密传输。
可以带。
另外,URL 中的查询参数也不是 GET 所独有的,POST 请求的 URL 中也可以有参数的。
POST 请求中的参数通常包含在请求的消息体中,而不是像 GET 请求一样包含在 URL 中。以下是一个登录功能的例子:
POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=johndoe&password=secret
在这个例子中,我们向 example.com
发送了一个 POST 请求,请求的路径为 /api/login
,请求头中包含了 Content-Type
字段,表示请求消息体的格式为 application/x-www-form-urlencoded
,请求消息体中包含了两个参数 username
和 password
。
在实际开发中,我们可以通过发送 POST 请求并在请求消息体中包含参数,来向服务器提交数据。
RFC(Request for Comments)是一系列文件的集合,这些文件包含了关于互联网技术、协议、体系结构和操作的信息和思想。
RFC 文件由互联网工程任务组(IETF)进行维护和发布。IETF 是一个开放的、国际性的组织,旨在推动互联网的技术和标准的发展。
RFC 文件通常描述了互联网标准、协议、流程、算法、编码规范和其他相关主题。RFC 文件的主要目的是促进开放、自由和协作式的标准制定过程,以便所有人都可以参与互联网标准的制定和实施。
RFC 文件不仅仅是一堆文本文件,它们还会被设计成软件规范和协议,以便开发人员可以根据这些规范开发互联网应用程序。 RFC 文件是互联网技术发展史上非常重要的一部分,每个 RFC 文件都有一个唯一的编号和标题,例如 RFC 2616,也称为 HTTP/1.1。这个 RFC 文件定义了 HTTP 协议的版本 1.1,包括 HTTP 请求和响应的格式、语法和语义。其他一些著名的 RFC 文件包括 RFC 793(TCP 协议)、RFC 821(SMTP 协议)和RFC 2822(电子邮件格式)。
总结来说:
UDP 在传送数据之前不需要先建立连接,是无状态的,传输不可靠但效率较高,支持一对多通信;
TCP 在传送数据之前必须先建立连接,是有状态的,提供可靠传输服务,只支持点对点通信。
是否面向连接:
是否是可靠传输:
是否有状态:
传输效率:
由于使用 TCP 进行传输的时候多了连接、确认、重传等机制,所以 TCP 的传输效率要比 UDP 低很多。
传输形式:
首部开销:
TCP 首部开销比 UDP 首部开销要大。
是否提供广播或多播服务:
常见的有:
常见的有
IP(Internet Protocol,网际协议) 是 TCP/IP 协议中最重要的协议之一,属于网络层的协议。
主要作用是定义数据包的格式、对数据包进行路由和寻址,以便它们可以跨网络传播并到达正确的目的地。
IP 地址是 Internet Protocol Address(网际协议地址)的缩写,是互联网中用于识别设备的数字标识。
在 TCP/IP 协议中,IP 地址用于标识网络中的主机或设备。它是一个 32 位二进制数,通常用“点分十进制”表示法表示,即四个用点分隔的十进制数,每个数的取值范围为 0-255。
IP 地址分为公网 IP 地址和私有 IP 地址两种类型。
IP 寻址是指:确定数据包在网络中的传输路径,使其能够正确地到达目标设备。
IP 寻址的过程主要分为四个步骤:
IPv4 和 IPv6 之间的主要区别在于地址空间大小和地址表示方式。
地址空间大小:
地址表示方式:
除了地址空间大小和地址表示方式之外,IPv6还具有一些其他的优势,例如更好的安全性、更高的性能和更智能的路由选择。
ping 命令是一种常用的网络诊断工具,经常用来测试网络中主机之间的连通性和网络延迟。
ping 是基于 ICMP
协议工作的,其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。
具体来说:
PING 用到的 ICMP Echo Request(类型为 8 ) 和 ICMP Echo Reply(类型为 0) 属于查询报文类型。、
- 8 - 代表回送请求
- 0 - 代表回送应答
PING 命令利用 ICMP 协议的 ECHO REQUEST 和 ECHO REPLY 消息来测试目标主机的可达性和网络质量。
ICMP 全称是 Internet Control Message Protocol,也就是互联网控制报文协议。
ICMP 报文是封装在 IP 包里面,它工作在网络层,是 IP 协议的助手。
ICMP 包头的类型字段,大致可以分为两大类:
PING 命令的输出结果通常包括以下几部分信息:
下面是一个 ping 百度的例子:
# 发送4个PING请求数据包到 www.baidu.com
❯ ping -c 4 www.baidu.com
PING www.a.shifen.com (14.119.104.189): 56 data bytes
64 bytes from 14.119.104.189: icmp_seq=0 ttl=54 time=27.867 ms
64 bytes from 14.119.104.189: icmp_seq=1 ttl=54 time=28.732 ms
64 bytes from 14.119.104.189: icmp_seq=2 ttl=54 time=27.571 ms
64 bytes from 14.119.104.189: icmp_seq=3 ttl=54 time=27.581 ms
# 输出的结果
--- www.a.shifen.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 27.571/27.938/28.732/0.474 ms
DNS(Domain Name System)域名管理系统,是当用户使用浏览器访问网址之后,使用的第一个重要协议。
DNS 要解决的是域名和 IP 地址的映射问题。
目前 DNS 的设计采用的是分布式、层次数据库结构,DNS 是应用层协议,基于 UDP 协议之上,端口为 53
DNS(Domain Name System)的作用是:将域名转换为 IP 地址,使得用户可以通过更易于记忆的域名来访问网站和其他网络服务。
在互联网上,每个设备都需要一个唯一的 IP 地址来进行通信,而使用域名可以避免用户需要记住许多复杂的 IP 地址。DNS 将域名映射到对应的 IP 地址,使得用户在输入域名时可以自动向正确的 IP 地址发送请求,从而访问相应的网站或服务。
DNS 服务器自底向上可以依次分为以下 4 个层级:
根 -> 顶级 -> 权威 -> 本地
所有 DNS 服务器都属于这四个类别之一。
- 根域名服务器。它是互联网上最高级别的 DNS 服务器,管理顶级域名服务器的地址,并提供 DNS 递归解析服务。目前世界上只有 13 组根服务器,我国境内目前仍没有根服务器。
- 顶级域名服务器(TLD 服务器)。顶级域是指域名的后缀,如
com
、org
、net
和edu
等。国家也有自己的顶级域,如uk
、fr
和ca
。TLD 服务器提供了权威 DNS 服务器的 IP 地址。- 权威域名服务器。它是管理特定域名下所有主机的 DNS 服务器,例如某个网站的域名服务器。权威域名服务器存储着该域名下所有主机的 IP 地址信息,它们只回答自己管理的域名和主机的 DNS 查询请求。
- 本地域名服务器。它是用户计算机或局域网中的 DNS 服务器,用于缓存 DNS 查询结果,并提供 DNS 递归解析服务。
- 当用户计算机发起 DNS 查询请求时,本地域名服务器会优先检查自己的缓存中是否有该域名对应的 IP 地址信息。
- 如果没有,则向根域名服务器发起 DNS 查询请求,按照自底向上的顺序逐级向下查询,直到找到权威域名服务器并获得 IP 地址信息,最后将结果返回给用户计算机。
DNS 解析过程大致可以分为以下几步:
简单来说:
Mac 地址常被称为物理地址,是用于识别网络设备的唯一标识符且固定不变。
MAC 地址,全称 Media Access Control Address,即媒体访问控制地址,也称为物理地址或硬件地址,是用于识别网络设备的唯一标识符。MAC 地址通常由 48 位二进制数组成,其中前 24 位表示厂商代码,后 24 位为该厂商设备的序列号。
MAC 地址是数据链路层(OSI模型第二层)的概念,用于在同一局域网内识别和寻址网络设备。
在局域网中,每个网络设备都有一个唯一的 MAC 地址。当一个网络设备需要发送数据时,它首先会在目标设备的 ARP 缓存中查找目标设备的 MAC 地址,如果没有找到,则向局域网广播 ARP 请求,请求目标设备的 MAC 地址。当目标设备收到 ARP 请求后,它会向发送设备回复一个 ARP 响应,包含自己的 MAC 地址。发送设备在收到 ARP 响应后,就可以使用目标设备的 MAC 地址来发送数据了。
MAC 地址是固定不变的,一般情况下不会被修改。在实际应用中,MAC 地址被广泛应用于网络设备的管理和安全控制,如网络设备的远程管理、访问控制列表等。
ARP 协议,全称 地址解析协议(Address Resolution Protocol),解决了 IP 地址转 MAC 地址的一些问题。
因为一个 IP 数据报在物理上传输的过程中,总是需要知道下一跳(物理上的下一个目的地)该去往何处
IP 地址属于逻辑地址,
而 MAC 地址才是物理地址
简单来说:
Mac 地址常被称为物理地址,是用于识别网络设备的唯一标识符且固定不变。
MAC 地址,全称 Media Access Control Address,即媒体访问控制地址,也称为物理地址或硬件地址,是用于识别网络设备的唯一标识符。MAC 地址通常由 48 位二进制数组成,其中前 24 位表示厂商代码,后 24 位为该厂商设备的序列号。
MAC 地址是数据链路层(OSI模型第二层)的概念,用于在同一局域网内识别和寻址网络设备。
在局域网中,每个网络设备都有一个唯一的 MAC 地址。当一个网络设备需要发送数据时,它首先会在目标设备的 ARP 缓存中查找目标设备的 MAC 地址,如果没有找到,则向局域网广播 ARP 请求,请求目标设备的 MAC 地址。当目标设备收到 ARP 请求后,它会向发送设备回复一个 ARP 响应,包含自己的 MAC 地址。发送设备在收到 ARP 响应后,就可以使用目标设备的 MAC 地址来发送数据了。
MAC 地址是固定不变的,一般情况下不会被修改。在实际应用中,MAC 地址被广泛应用于网络设备的管理和安全控制,如网络设备的远程管理、访问控制列表等。
ARP 协议,全称 地址解析协议(Address Resolution Protocol),解决了 IP 地址转 MAC 地址的一些问题。
因为一个 IP 数据报在物理上传输的过程中,总是需要知道下一跳(物理上的下一个目的地)该去往何处
IP 地址属于逻辑地址,
而 MAC 地址才是物理地址