!!!!本文是基于javaGuide开源项目进行学习的记录和自我总结!!!!
计算机网络
一、网络分层模型
1. TCP/IP四层架构和OSI七层架构⭐️⭐️⭐️⭐️⭐️
应用层
传输层
网络层
网络接口层
一个很形象的七层架构图:(from:javaGuide)
2. 为什么网络要分层?⭐️⭐️⭐️
- 各层之间互相独立:各层只需要知道自己如何调用下层提供的功能就好了
- 提高了灵活性和可替换性:因为各层之间互相独立,每一层都可以根据需求进行修改和替换
- 大问题化小:分层可以将复杂的网络问题分解为许多比较下的、界限比较清晰简单的小问题来处理和解决
3. 各层都有那些协议?⭐️⭐️⭐️⭐️
应用层:
传输层:
网络层:
二、HTTP【重要】
1. http状态码?⭐️⭐️⭐️
1 | 类别 | 原因短语 |
---|---|---|
1×× | Informational(信息性状态码) | 接收的请求正在处理 |
2×× | Success(成功状态码) | 请求正常处理完毕 |
3×× | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
4×× | Client Error(客户端错误状态码) | 服务器无法处理请求 |
5×× | Server Error(服务器错误状态码) | 服务器处理请求出错 |
2×× Success(成功状态码)
- 200 OK :请求被成功处理
- 201 Created:请求被成功处理并且在服务端创建了一个新的资源
- 202 Accepted:服务端已经接收了请求,但还未处理
- 204 No Content:服务端已经成功处理了请求,但是没有返回任何内容
3×× Redirection (重定向状态码)
- 301 Moved Permanently:资源被永久重定向了。比如:网站的网址更换了
- 302 Found:资源被临时重定向了。比如:网站的某些资源被暂时转移到另外一个网站
4×× Client Error(客户端错误状态码)
- 400 Bad Request:发送的HTTP请求存在问题。比如:请求参数不合法、请求方式错误
- 401 Unauthorized:未认证却请求需要认证之后才能访问的资源
- 403 Forbidden:直接拒绝HTTP请求,不处理。一般用来针对非法请求
- 404 Not Found:你请求的资源未在服务端找到。
- 409 Conflict:表示请求的资源与服务端当前的状态存在冲突,请求无法被处理
5×× Server Error(服务端错误状态码)
- 500 Internal Server Error:服务端出问题了(通常是服务端出bug了)。比如:服务端处理请求时候突然抛出异常,但是异常并未在服务端被正确处理
- 502 Bad Gateway:网关将请求转发到服务端,但是服务端返回的却是一个错误的响应
2. 从输入URL到页面展示到底发生了什么?⭐️⭐️⭐️⭐️⭐️
简述:
- 用户输入url地址
- 浏览器通过DNS协议,获取域名对应的IP地址
- TCP三次握手
具体流程:【学习路径:浅谈一个网页打开的全过程】
(1)用户输入url地址
【比如:www.baidu.com–>这是一个域名(domain)】
这里做一下url地址的详解【学习路径:javaGuide】
1)协议:URL 的前缀通常表示了该网址采用了何种应用层协议,通常有两种——HTTP 和 HTTPS。当然也有一些不太常见的前缀头,比如文件传输时用到的ftp:。
2)域名:域名便是访问网址的通用名,这里也有可能是网址的 IP 地址,域名可以理解为 IP 地址的可读版本,毕竟绝大部分人都不会选择记住一个网址的 IP 地址。
3)端口:如果指明了访问网址的端口的话,端口会紧跟在域名后面,并用一个冒号隔开。
4)资源路径:域名(端口)后紧跟的就是资源路径,从第一个/开始,表示从服务器上根目录开始进行索引到的文件路径,上图中要访问的文件就是服务器根目录下/path/to/myfile.html。早先的设计是该文件通常物理存储于服务器主机上,但现在随着网络技术的进步,该文件不一定会物理存储在服务器主机上,有可能存放在云上,而文件路径也有可能是虚拟的(遵循某种规则)。
5)参数:参数是浏览器在向服务器提交请求时,在 URL 中附带的参数。服务器解析请求时,会提取这些参数。参数采用键值对的形式key=value,每一个键值对使用&隔开。参数的具体含义和请求操作的具体方法有关。
6)锚点:锚点顾名思义,是在要访问的页面上的一个锚。要访问的页面大部分都多于一页,如果指定了锚点,那么在客户端显示该网页是就会定位到锚点处,相当于一个小书签。值得一提的是,在 URL 中,锚点以#开头,并且不会作为请求的一部分发送给服务端。
(2)DNS解析
什么是DNS解析?(其实域名可以理解为一个好记的名字,然后它对应着ip地址)
当用户输入一个网址并按下回车键的时候,浏览器得到了一个域名,我们需要的是一个ip地址。 因此我们需要先把域名转换为相应的ip地址,这个过程称作DNS解析
1)浏览器首先搜索浏览器自身缓存的DNS记录(chrome浏览器通过输入:chrome://net-internals/#dns 打开DNS缓存页面)
2)如果浏览器缓存中没有找到需要的记录或记录已经过期,则搜索hosts文件和操作系统缓存- 在Windows操作系统中,可以通过ipconfig/displaydns命令查看本机当前的缓存 - 通过hosts文件,可以手动指定一个域名和其对应的IP解析结果,并且该结果一旦被使用,同样会被缓存到操作系统缓存中 - Windows系统的hosts文件在%systemroot%\system32\drivers\etc下 - Linux系统的hosts文件在/etc/hosts下
3)如果上面的都没有找到记录或者记录已过期,则向域名解析服务器发送解析请求
其实第一台被访问的域名解析服务器就是我们平时在设置中填写的DNS服务器一项,当操作系统缓存中也没有命中的时候,系统会向DNS服务器正式发出请求。这里是真正意义上开始解析一个未知的域名。
4)如果域名解析服务器也没有该域名的记录,则开始递归+迭代解析
- 为什么是递归:问题有一开始的本机要解析mail.google.com变成域名解析服务器要解析mail.google.com,这是递归
- 为什么是迭代:问题由向根域服务器发出请求变成向com域服务器发出请求,再变成向google.com域发出请求,这是迭代
(3)发起TCP请求
TCP三次握手
- 先简单介绍一下tcp三握四挥 需要用到的tcp报文的内容:
SYN:TCP报文标志位,SYN=1表示发起一个新连接
seq:sequence number,报文初始序列号,代表发送的第一个字节的序号
ack:acknowledgement number,报文确认序号,代表希望收到下一个数据的第一个字节的序号
ACK:TCP报文标志位。ACK=1时,确认序号有效,确认收到消息。TCP规定,在连接建立后,所有报文传输都必须把ACK置1
TCP三次握手:
可以类比于打电话 客户端就是C,服务器就是B
- C表示想给B打电话,给B发个消息确认一下能不能打电话
- B收到消息,回给C说可以打电话
- C收到消息了,然后给B发个确认信息 说 我收到你的确认消息了【因为这个时候B不知道C收没收到消息(就像已读功能一样,现在是没有已读功能)】
然后C跟B就可以打电话了
TCP三次握手就可以简单的理解为
客户端说想要访问服务器,然后服务器说可以,客户端收到服务器的确认之后再给服务器返回一个确认
嗯…大概是这个样子,我写的比较乱 看不懂 看下面的那个
这里补充一下TCP四次挥手(打开网页的过程没有这个!!)
(4)负载均衡
(5) 浏览器渲染
1)浏览器根据页面内容,生成DOM Tree。根据CSS内容,生成CSS Rule Tree(规则树)。调用JS执行引擎执行JS代码
2)根据DOM Tree和CSS Rule Tree生成Render Tree(呈现树)
3)根据Render Tree渲染网页
(6) 网页静态资源加载
3. HTTP和HTTPS的区别?HTTPS的安全性体现在什么方面?⭐️⭐️⭐️⭐️⭐️
(1)端口号:HTTP默认80;HTTPS默认443
(2)URL前缀:HTTP的URL前缀是http://
,HTTPS的URL前缀是https://
(3)安全性和资源消耗:
- HTTP协议运行在TCP协议之上,所传输的内容都是明文,客户端和服务器端都无法验证对方身份。
- HTTPS是运行在SSL/TLS之上的HTTP协议,SSL/TLS运行在TCP之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的整数进行了非对称加密。所以说,HTTP安全性没有HTTPS高,但是HTTPS比HTTP耗费更多服务器资源。
HTTPS之所以能达到较高的安全性要求,就是结合了SSL/TLS和TCP协议,对通信数据进行加密,解决了HTTP数据透明的问题。
4. HTTPS加密过程是怎样的?⭐️⭐️⭐️⭐️⭐️
简述:
(1)客户端向服务器发送HTTPS请求
(2)服务器将公钥整数发送给客户端
(3)客户端验证服务器的证书
(4)如果验证通过,客户端生成一个用于会话的对称密钥
(5)客户端使用服务器的公钥对密钥进行加密,并将加密后的密钥发送给服务器
(6)服务器使用私钥对客户端发送的加密密钥进行解密,得到对称密钥
(7)服务器和客户端使用对称密钥进行加密和解密数据传输
图片form bilibili——技术蛋老师
解释:
HTTPS加密原理的重点在于 非对称加密(服务器有公钥和私钥;客户端有公钥)
约定:公钥加密的东西只有私钥能解开(公钥解不开);私钥加密的东西只有公钥能解开
Step1:客户端发送HTTPS请求 给服务器
Step2:服务器确认请求正确,并将 公钥、证书等数据 发送给客户端;服务器都发送完毕,告诉客户端OK了
Step3:客户端这边确认之后 生成一个随机数(叫做预主密钥),这个预主密钥 用 公钥 加密后 发送给服务器
Step4:根据我们的约定——公钥加密的东西 只能用私钥解密。所以服务器用私钥解开客户端发的预主密钥,得到真正的预主密钥
Step5:客户端和服务器现在都有了 随机数1、随机数2和预主密钥–》两方 用这三个东西生成一个“会话密钥”。之后的数据传输都使用这个“会话密钥”进行对称加密
5. HTTP1.1和HTTP2.0的区别?
一下简称为1.1和2.0
- 多路复用:
- 1.1是一对一的请求和响应 也就是说一个请求发送并响应成功后,才能发送第二个请求,(其实也可以同时发送多个请求,但是1.1要求响应的顺序要与请求顺序相同,基本上没得到广泛应用)虽然浏览器允许同时连接 但是限制了TCP同时连接的个数
- 2.0在同一个连接上可以同时传送多个请求和响应,且互不干扰
- 二进制帧
- 1.1 是明文进行数据传输的
- 2.0 使用二进制帧进行数据传输——二进制帧更加紧凑和高校,减少了传输的数量和带宽消耗
- 头部压缩
- 1.1 支持Body压缩,不支持Header压缩
- 2.0 专门设计了算法进行Header压缩,减少了网络开销
- 服务器推送
- 1.1 需要客户端自己发送请求来获取相关资源
- 2.0 支持服务器推送,可以在客户端请求一个资源时,将其他相关资源一并推送给客户端,从而减少了客户端的请求次数和延迟(但其实有挺大问题的–》比如:用户误点了一个网页,然后服务器库库推一堆东西过来,客户端这边一下多一大堆缓存,这肯定是不行的)
6. HTTP2.0和HPPT3.0的区别
- 传输协议
- 2.0是基于TCP实现的
- 3.0 新增了QUIC(Quick UDP Internet Connections)协议来实现可靠的传输,提供与TLS相当的安全性,具有较低的连接和传输延迟
- 连接建立
- 2.0 需要经过经典TCP三次握手过程(由于安全的HTTPS连接建立还需要TLS握手,共需要大概RTT)
- 3,0 由于QUIC协议的特性(TLS1.3,TLS1.3除了支持1个RTT握手,还支持0个RTT握手)连接建立仅需0-RTT或者1-RTT。这意味着QUIC在最佳情况下不需要任何额外往返时间就可以建立连接
- 头部压缩
- 2.0 使用HPACK算法进行头部压缩
- 3.0 使用更高效的QPACK头压缩算法
- 队头阻塞
- 2.0 多请求复用一个TCP连接,一旦发生丢包,就会阻塞住所有HTTP请求
- 3.0 由于QUIC协议的特性,一次连接建立多个不同的数据流,这些数据流之间独立互不影响,某个数据流发生丢包了,其数据流不受影响(本质上是多路复用+轮询)
- 连接迁移
- 2.0 由于是基于TCP,TCP连接是由(源IP,源端口,目的IP,目的端口)组成,这个四元组中一旦有一项值发生改变,这个连接也就不能用了
- 3.0 支持连接迁移,因为QUIC使用64位ID标识连接,只要ID不变就不会中断,网络环境改变时(wifi-》移动数据)也能保持连接
三、WebSocket
1. 什么是WebSocket?
WebSocket是一种基于TCP连接的全双工通信协议,即客户端和服务器可以同时发送和接收数据
WebSocket协议本质上是应用层的协议,用于弥补HTTP协议在持久通信能力上的不足。客户端和服务器仅需一次握手,两者之间就直接可以创建持久性的连接,并进行双向数据传输。
WebSocket的常见应用场景
- 视频弹幕
- 实时消息推送
- 实时游戏对战
- 多用户协同编辑
- 社交聊天
- …
2. WebSocket和HTTP有什么区别?⭐️⭐️⭐️⭐️
两者都基于TCP的应用层协议,都可以在网络中传输数据
主要区别:
- WebSocket双向,HTTP单向
- WebSocket支持扩展
- WebSocket通信数据格式比较轻量
详述
- WebSocket是一种双向实时通信协议,而HTTP是一种单向通信协议。并且,HTTP协议下的通信只能由客户端发起,服务器无法主动通知客户端
- WebSocket的前缀为ws://或wss://
- WebSocket可以支持扩展,用户可以扩展协议,实现部分自定义的子协议,如支持压缩、加密等
- WebSocket通信数据格式比较轻量,用于协议控制的数据包头部相对较小,网络开销小;而HTTP通信每次都要携带完整的头部,网络开销较大
3. WebSocket的工作过程是怎样的?⭐️⭐️⭐️⭐️
客户端先发送HTTP请求到服务器升级协议未WebSocket,再建立WebSocket连接
详述:
- 客户端向服务器发送一个HTTP请求,请求头中包含
Upgrade:websocket
和Sec-WebSocket-Key
字段,表示要求升级协议为WebSocket - 服务器收到这个请求后,会进行升级协议的操作,如果支持WebSocket,它将回复一个HTTP101状态码,响应头中包含,
Connection:Upgrade
和Sex-WebSocket-Accept: xxx
等字段,表示成功升级到WebSocket协议 - 客户端和服务器之间建立了一个WebSocket连接,可以进行双向的数据传输。数据以帧(frames)的形式进行传送,WebSocket的每条消息可能会被切分成多个数据帧。发送端会将消息切割成多个帧发送给接收端,接收端接收消息帧,并将关联的帧重新组装完整的消息
- 客户端或服务器可以主动发送一个关闭帧,表示要断开连接。另一方收到后,也会回复一个关闭帧,然后双方关闭TCP连接
四、PING
1. PING命令的作用是什么?
PING 命令是一种常用的网络诊断工具,经常用来测试网络中主机之间的连通性和网络延迟。
2. PING命令的主要原理是什么?
PING 基于网络层的 ICMP(Internet Control Message Protocol,互联网控制报文协议),其主要原理就是通过在网络上发送和接收 ICMP 报文实现的。
五、DNS
1. DNS是什么?解决了什么问题?是哪一层的协议?⭐️⭐️⭐️⭐️⭐️
- DNS(Domain Name System)域名管理系统,是当用户使用浏览器访问网址之后,使用的第一个重要协议。
- DNS要解决的是域名和IP地址映射的问题
- DNS是应用层协议,基于UDP协议之上,端口为53
2. DNS能解析端口吗?⭐️⭐️⭐️⭐️
DNS是域名解析协议,只能将域名和IP地址相互映射,不能指定端口。
虽然DNS不直接解析端口号,但是可以通过几种方式间接与端口相关联:服务记录;正向解析;反向解析;特定配置
3. DNS服务器有哪些?根服务器有多少个?⭐️⭐️⭐️
- DNS服务器自底向上可以依次分为4个层级(所有DNS服务器都属于这4个类别之一)
- 根DNS服务器
- 顶级域DNS服务器
- 权威DNS服务器
- 本地DNS服务器
图片from bilibili——技术蛋老师
- 根服务器
常说:世界上只有13台根服务器
但是!!!最初确实是为DNS根服务器分配了13个IP地址,每个IP地址对应一个不同的根DNS服务器。然而,由于互联网的快速发展和增长,这个原始的架构变得不太适应当前的需求。为了提高DNS的可靠性、安全性和性能,目前这个13个IP地址中的每一个都有多个服务器。AI说:截止2023年6月,已有1719个。
4. DNS解析过程是什么样的?⭐️⭐️⭐️
图片 from bilibili——技术蛋老师
详述:(比如 想要解析www.bilibili.com)
- 输入域名之后 其实会现在浏览器或操作系统或本地hosts文件中查找有没有缓存【这里可以看 上面的 HTTP——》从输入URL到页面展示到底发生了什么?——》DNS解析】
- 浏览器发送解析请求到解析器(这个时候可以把解析器看做客户端,DNS服务器就是服务端)
- DNS客户端向DNS服务器发送解析请求
- 服务器 向 根DNS服务器 咨询地址;
- 根DNS服务器返回一个顶级域DNS地址——com
- 服务器 向 顶级域DNS 咨询地址
- 顶级域DNS 返回 权威DNS 地址——bilibili.com
- 服务器 向 权威域DNS 咨询地址
- 权威域DNS 返回 IP地址——www.bilibili.com
- DSN服务器将IP地址传给DNS客户端(也就是解析器)
- 解析器 传给 浏览器
5. DNS劫持了解吗?如何应对?⭐️⭐️【暂时不了解哈哈哈】
六、TCP与UDP【重要】
1. UDP和TCP的区别?⭐️⭐️⭐️⭐️
· | TCP | UDP |
---|---|---|
是否面向连接 | 是 | 否 |
是否可靠 | 是 | 否 |
是否有状态 | 是 | 否 |
传输效率 | 较慢 | 较快 |
首部开销 | 20~60bytes | 8bytes |
是否提供广播或多播服务 | 否 | 是 |
详述:
- 是否面向连接:UDP在传送数据之前不需要先建立连接。而TCP提供面向连接的服务,在传送数据之前必须建立连接,数据传送结束后要释放连接
- 是否是可靠传输:远地主机在收到UDP报文后,不需要给出任何确认,并且不保证数据不丢失,不保证是否顺利到达。TCP提供可靠的传输服务,TCP在传递数据之前,会有三次握手来建立连接,而在数据传递时,有确认、窗口、重传、拥塞控制机制。通过TCP连接传输的数据,无差错、不丢失、不重复、并且按序到达。
- 是否有状态:TCP有状态,会记录自己发送的消息的状态,比如是否发送了,是否被接受了等。但UDP是无状态服务,像个渣男一样,发出去了就不管之后的事了。
- 传输效率:由于TCP的机制比较多,所以慢
- 传输形式:TCP是面向字节流的,UDP是面向报文的(这也就决定了TCP的可靠和UDP的实时性)
- 首部开销:TCP首部开销(20~60字节);UDP首部开销(8字节)
- 是否提供广播或多播服务:TCP只支持点对点通信,UDP支持一对一,一对逗,多对一,多对多
2. 什么时候选择TCP,什么时候选择UDP?
- UDP一般用于即使通信。比如:语音,视频,直播等等。这些场景对传输数据的准确性要求不是特别高,比如你看视频即使少个一两帧,实际给人感觉区别不大
- TCP用于对传输准确性要求特别高的场景,比如文件传输、发送和接收邮件、远程登录等
3. HTTP是基于TCP还是UDP?⭐️⭐️⭐️
HTTP/3.0之前是基于TCP协议的,而HTTP/3.0 弃用TCP,改用基于UDP的QUIC协议
HTTP3.0和HTTP2.0的区别可以看上面的【HTTP——HTTP2.0和HTTP3.0的区别】
4. 使用TCP的协议有哪些?使用UDP的协议有哪些?⭐️⭐️⭐️
- 运行在TCP协议之上的协议:HTTP(HTTP/3.0之前),HTTPS,FTP,SMTP,DNS等
- 运行在UDP协议之上的协议:HTTP3.0,DHCP协议,DNS等等
5. TCP的三次握手和四次挥手⭐️⭐️⭐️⭐️⭐️
三挥四握在上面的 【HTTP——》从输入URL到页面展示到底发生了什么?——》(3)发起TCP请求】中已经做了详细的解释。
这里有些重要的点:
- 为什么要三次握手?
三次握手的目的是建立可靠的通讯信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的
而三次刚好双方都能 确认对方收到消息了
两次不能保证双方都确认了;四次会有网络延迟,资源浪费
- 第2次握手传回了ACK,为什么还要传回SYN?
ACK是 服务端告诉客户端:“我确认收到你发的消息了”
SYN 则是为了 建立并确认从服务端到客户端的通信连接
- 三次握手过程中可以携带数据吗?
- 在TCP三次握手过程中,第三次握手是可以携带数据的
- 如果第三次握手的ACK确认包丢失,但是客户端已经开始发送携带数据的包,那么服务端在接收这个携带数据的包时,如果该包中包含了ACK标记,服务端会将其视为有效的第三次握手确认。这样,连接就被认为是建立的,服务端会处理该数据包,并继续正常的数据传输流程。
- 为什么不能把服务端发送的ACK和FIN合并起来,变成三次挥手?
四次挥手的过程是
客户端发FIN;服务端发ACK;服务端发FIN;客户端发ACK第一次挥手:A说“我没啥要说的了” 第二次挥手:B说“我知道了” ,但是B可能还会有话要说 第三次挥手:于是B可能又说了些东西,最后B说“我说完了” 第四次挥手:A回答说“我知道了”;至此 通话结束
所以 在服务端发完ACK之后,可能还有一些数据没有传送完成,这时先回复ACK表示确认收到了客户端的 断开连接的请求。等数据发完之后,再发FIN,断开服务端到客户端的数据传送。
- 如果第二次挥手时服务端的ACK没有送达客户端,会怎样?
客户端没有收到ACK确认,会重新发送FIN请求
- 为什么第四次挥手 客户端需要等待2MSL(报文段最长寿命)时间后才进入CLOSE状态?
第四次挥手时,客户端发送给服务端的ACK有可能丢失,如果服务端因为某些原因没有收到ACK的话,服务端就会重发FIN,如果客户端在2MSL的时间内收到了FIN,就会重新发送ACK并再次等待2MSL,防止Server没有收到ACK而不断重发FIN