计算机网络
体系结构¶
- OSI 7 层结构:
- 应用层:通过应用程序间的交互来完成特定的网络应用
- 表示层:解释交换数据的含义。该层提供的服务主要包括数据压缩,数据加密以及数据描述。
- 会话层:负责建立、管理和终止表示层实体之间的通信会话。该层提供了数据交换的定界和同步功能,包括了建立检查点和恢复方案的方法。
- 传输层:负责因特网中两台主机的进程提供通信服务。
- 网络层:选择合适的网间路由和交换节点,确保数据按时成功传送。
- 数据链路层 (链路层):数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧。
- 物理层:实现计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。该层的主要任务是确定与传输媒体的接口的一些特性
- TCP/IP 五层模型:
- 应用层 :为特定应用程序提供数据传输服务。
- 传输层 :为进程提供通用数据传输服务。
- 网络层 :为主机提供数据传输服务。而传输层协议是为主机中的进程提供数据传输服务。
- 数据链路层 :网络层针对的还是主机之间的数据传输服务,而主机之间可以有很多链路,链路层协议就是为同一链路的主机提供数据传输服务。
- 物理层 :负责比特流在传输介质上的传播。
应用层¶
CDN 内容分发网络¶
- 通过在全球分布的服务器上缓存内容来加速访问互联网内容的技术。CDN 的主要目的是通过将内容存储在离用户更近的地理位置上,来减少内容加载的时间,改善用户体验。
- 工作原理
- 分布式数据中心:CDN 由许多位于不同地理位置的服务器组成,这些服务器组成了一个分布式数据中心。这些服务器通常部署在与用户接入点物理位置较近的地方。
- 内容缓存:当内容首次被请求时,它会被从原始服务器拉取到 CDN 服务器上。此后,当其他用户请求相同的内容时,他们将从最近的 CDN 节点接收到内容,而不是从源服务器上。
- 智能路由:CDN 使用智能路由技术来确定哪个 CDN 服务器距离用户最近或最能高效地满足用户的请求。
- 负载均衡:通过在多个服务器之间分配请求,CDN 可以防止任何单一点过载,确保数据的快速和可靠传输。
-
好处
- 提高加载速度(内容靠近用户减少数据传输延时)
- 降低带宽成本(减少对原始主机服务器的数据请求)
- 提高网络可靠、可用性(源服务器出现问题也能访问)
- 提高安全性(如 DDos 防护、网络安全防护)
-
反向代理:反向代理服务与服务端,代理服务器处理客户端的请求(反向代理对客户透明)
- 正向代理:正向代理服务与客户端,代理客户端向服务器发送请求,帮助客户端访问客户端肯呢个无法直接访问的资源
万维网和域名¶
- URI:统一资源标识符
- 标识某一互联网资源名称的字符串
-
URL:统一资源定位符
- 是 URI 的一个子集,不仅标识资源,而且提供了找到该资源的方法
- 三部分组成:协议类型+web 地址(ip+端口)+资源地址
-
应用程序体系架构:CS、P2P
-
常见 web 组件
- 代理
- 位于客户端和服务器之间的 http 中间实体。
- 代理做为转发所有 Web 流量的可信任中间节点使用,可以对请求和响应进行过滤
- 网关
- 连接其他应用程序的特殊 web 服务器。
- 常用于将 http 流量转化为其他的协议。网关接受请求时就好像自己本身是资源源服务器一样,客户端对此无感知。
- 隧道
- 对 http 通信报文进行盲转发的特殊代理。
- 道主要用于跨越不兼容的网络环境,通过封装和加密来安全传输数据。
- 代理
-
DNS 工作原理
- 客户端首先检查本地 hosts 文件,检查是否有缓存的映射关系
- 查找本地 DNS 解析器缓存
- 根据设置的首选 dns 服务器 ip,查询本地服务器
- 本地 DNS 服务器查找失败后会访问根域名服务器,再找到对应的顶级域名服务器,然后向下不断查找
- DNS 服务器分类
- 根域名服务器:最高层次的域名服务器,所有的根域名服务器都知道所有的顶级域名服务器的 ip 地址
- 顶级域名服务器:负责处理所有顶级域名,提供到权威域服务器的映射。
- 授权 (权威)域名服务器:提供主机名到 IP 地址间的映射服务
- 主域名服务器:一个或多个区域域名解析工作的主要域名服务器,通常也是一个或多个区域的授权域名服务器。
- 辅助域名服务器:协助主域名服务器提供域名查询服务,在主机很多的情况下,可以有效分担主域名服务器的压力。当主域名服务器故障时,辅助域名服务器能够在数据有效期内继续为主机提供域名解析服务。
-
DNS 的数据传输方式
- 既采用 udp 协议也采用 tcp 协议
- 默认是采用 udp 协议进行数据传输的;
- 当返回的响应超过 512 字节时、或进行区域传送(主域名服务器向辅助域名服务器传输变化)时使用 TCP
-
网业解析的过程
- 用户输入网址
- dns 解析得到 ip 地址
- 向 web 服务器发起 TCP 连接
- 发送 http 请求:http 请求是建立在 TCP 连接中的
- web 服务器处理请求并返回
- 浏览器渲染网页
- 断开连接
HTTP¶
-
报文结构
- 简略信息:请求方法、url、版本等
- 头部 header
- 内容主体
// 第一部分:简略信息 GET https://leetcode.cn/problemset/all/ HTTP/1.1. // 第二部分:请求首部或者响应首部 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 Cache-Control: max-age=0 Host: leetcode.cn If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT If-None-Match: "3147526947+gzip" Proxy-Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 xxx // --------- 空行 -------------- // 第三部分,内容主体 param1=1¶m2=2
-
post 与 get 的区别
- get 提交的数据会放在 url 之后,post 提交的数据放在 body 上。get 请求参数会以 url 的形式完整的保留在浏览器的记录里,会存在安全问题。post 可以进行复杂的加密,get 则不可以, 并且 get 提交的数据大小有限制
- get 方法不会改变服务器状态,而 post 会改变服务器的状态,从这个角度来看,get 方法更安全。
- get 方法对于服务器更安全,post 方法对于客户端更安全.
-
http 状态码
- 200:成功返回响应
- 301:永久重定向,客户端第一次访问此 url 时,告知客户端以后直接访问新的 url,该状态保存在浏览器缓存中。
- 302;临时重定向,客户端每次访问此 url 时,告知客户端重定向到新的 url ,后续访问依然访问当前的 url。
- 400:发送的请求错误,请求格式错误,或者没有服务器要求的数据。
- 401:没有权限访问,当前用户没有权限访问此资源。
- 403: 请求被服务器禁止。
- 404:请求的 url 不存在,一般是 url 出错。
- 500: 服务器处理请求出现错误。
- 501:服务器超出能力之外的方法,例如:请求的方法服务器不支持。
- 504:来自网关或者代理服务器,请求资源服务器时超时。
-
首部类型:
- 通用首部字段、请求首部字段、响应首部字段、实体首部字段
-
连接管理
- 长连接只需要建立一次 tcp 连接就能进行多次 http 通信,短连接每个 http 请求就要建立一次 tcp 连接。(页面上有多个媒体资源可能需要短时间内频繁通信,此时短连接的效率较低)
- 从 http/1.1 开始默认是长连接的(需要由客户端或者服务器端提出断开)在 http/1.1 之前默认是短连接的
- 流水线是在同一条长连接上连续发出请求,而不用等待响应返回,这样 http 的速度会快很多,tcp 连接的利用率也会非常高。、
- 无状态协议和 cookie
- http 是一种不保存状态,即无状态协议。
- 服务器可以通过 session 或者 cookie 来直到请求从哪个客户端发送
- session:客户端第一次发送信息到服务器时,服务器为该客户端创建一个 session 对象,该 session 包含客户端身份信息,同时为该 session 生成一个 sessionId 。服务端将这个 sessionId 分配给客户端,客户端发送请求时带有此 sessionId ,服务端就可以区分客户端。
- 存储在服务器端。更加安全
- cookie:客户端第一次发送信息到服务器时,服务器根据该客户端信息编码加密生成一个 cookie。服务端将此 cookie 发送给客户端,客户端发送请求时带有此 cookie ,服务端就可以区分客户端。
- 存储在客户端浏览器,cookie 携带着用户信息
-
http 的安全性问题:明文通讯、不验证身份、无法验证报文完整性
-
短连接(http 1.0):每个 HTTP 请求独立完成(即每个 HTTP 请求之前都会有一次 TCP 握手)很慢
- 问题:创建连接慢;TCP 只有使用一段时间之后才能发挥出性能
- 长连接 (http 1.1):长连接会保持一段时间,重复发送一系列请求,在空闲一段时间之后再断开(空闲状态消耗资源,容易被攻击)
-
流水线 :在一条长连接上连续发出请求,不用等待应答返回(实际使用不多,较为复杂,性能改善不明显)
-
https
- https 数据发送时 request 通过 ssl/tls 进行处理,然后再通过 tcp 进行发送;数据接收时,同样也是要通过 ssl/tls 进行处理。相当于在应用层 http 和传输层 tcp 之间多加了一步处理
- 数据加密:首先通过非对称加密(获取公钥时使用数字证书避免篡改),传输对称加密所需的密钥,然后使用密钥进行通信加密。这样既兼顾了安全性,又有了更高的运算速度。
- 数字证书认证:服务器事先向数字证书机构申请数字证书,数字证书机构对数据做数字签名,然后将数据和数字签名打包在一起,做成数字证书,发送给服务端;https 通信时,服务器把数字证书发给客户端。客户端取得其中的数据和数字签名,使用数字证书机构的公开密钥验证数据和数字签名是否合法(确认服务端身份)
- 检验报文完整性:https 的报文摘要功能之所以安全,是因为它结合了加密和认证这两个操作;加密 + 摘要检验 + 认证 = 数据完整
- 缺点:https 虽然通讯安全但是相比 http 使用价格昂贵并且速度稍慢
-
https/ssl 的具体过程
- 客户端发起请求'ClientHello'消息开始握手,包含支持的 SSL/TLS 版本、加密套件列表和一个随机数
- 服务器恢复'ServerHello'选择客户端也支持的协议版本和加密套件,并发送一个服务器生成的随机数和证书(含服务器的公钥和 CA 的身份认证)
- 客户端验证证书的合法性,然后生成一个随机数并用公钥加密后发送给服务器
- 服务器使用自己的私钥解密获取预主密钥,根据客户端随机数、服务器随机数和预主密钥生成对话秘钥用于后续数据加密
- 双方交换 Finished 消息,确认握手结束
-
websocket
- 普通 CS 模式下服务端不能主动给客户端发送数据,需要客户端轮训服务端效率是十分低下。
- websocket 的出现就是为了解决这个问题,web 浏览器与 web 服务器之间全双工通信标准
- 建立在 tcp 协议之上。握手阶段采用 http 协议
其他¶
-
套接字:网络中不同主机上的应用进程之间进行通信的接口(ip+端口)
- socket 由 ip 地址、端口号和协议组成 (协议只有 tcp 和 udp)
- 地址包括协议,所以同一个 ip 同一个 port 可以支持两个进程,一个 TCP 进程,一个 UDP 进程。
-
常用端口
- DNS:53
- HTTP:80
- HTTPS:443
传输层¶
UDP¶
-
udp 只是做了传输协议能够做的最少的工作。除了复用/分解功能及少量的差错检测外,几乎没有在网络层协议上添加什么内容。
-
udp 特点
- 发送数据具有即时性,立即发送
- 无需建立连接
- 无连接状态
- 首部数据较小,开销小效率高
-
udp 报文结构
- 源端口、目的端口(16 位)】
- 报文长度(16 位):表示数据报(报文头+数据)长度
- 校验值
-
udp 可靠传输:通过应用层软件实现
- 为数据包编号(用于重新排列、检测丢失、去重)
- 确认和超时重传
- 滑动窗口
- 快速重传
- 错误校验和矫正
TCP¶
- 三次握手建立连接
- 客户端向服务端发送 SYN (请求建立连接)包,序列号 Seq=x
- 服务端结束 LISTERN 阶段,返回 TCP 报文:标志位为 SYN 和 ACK 序号为 Seq=y(自己的初始序列号),确认号 Ack=x+1 表示收到请求
- 客户端收到 SYN+ACK 包后发送 ACK 序号为 Seq=x+1 确认号为 Ack=y+1
- 服务器收到后完成三次握手建立连接
-
为什么要进行三次握手
- 确认客户端和服务端都可以正常发送接收数据。
-
四次挥手关闭连接
- 客户端发送 FIN 报文表示要释放 TCP 连接 Seq=u
- 服务器收到后回顾 ACK=u+1 确认 Seq=v
- 服务器发送 ACK 后会将遗留带传数据传送到客户端,完成后就也做好了释放服务端到客户端连接的准备,发送 FIN+ACK,Seq=w,ACK=u+1
- 客户端收到后回复 ACK=w+1, Seq=u+1 确认服务器已经准备好释放连接
- 之后客户端还会等待一会再关闭,防止服务端没有收到 ACK 而需要进行失败重传
-
为什么要进行四次挥手
-
可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块。每次接收方收到数据后,都会对传输方进行确认应答
- 校验和
- 流量控制:让发送方的发送速率不要太快,让接收方来得及接收,TCP 连接的双方都有一个固定大小的缓冲空间,发送方发送的数据量不能超过接收端缓冲区的大小。当接收方来不及处理发送方的数据,会提示发送方降低发送的速率,防止产生丢包。TCP 通过滑动窗口协议来支持流量控制机制。
- 拥塞控制:除了发送方和接收方外,还有路由器,交换机等复杂的网络传输线路,此时就需要拥塞控制。防止过多的数据注入到网络中,避免出现网络负载过大的情况。
- 慢启动:由于一开始不知道网络负荷情况。慢开始的慢指的是初始发送报文段的数量为 1,如果收到确认,则发送两个报文段,之后每收到一个确认报文,发送报文端的数量就翻倍,直到到达慢开始门限,当发送报文段的数据大于门限数量时,使用拥塞避免算法。
- 拥塞避免:当网络拥塞发生时,慢开始门限值减半,发送的报文段数量改变为 1 ,然后再次重复两种算法(慢开始和拥塞避免)。
- 快重传:接收方每收到一个失序的报文就立即发送重复确认,而不要等到自己发送数据时才捎带进行确认。出现 3 次重复确认时发送方就进行重传(而不是等待丢失计时),使得发送方尽早重传未被确认的报文段
- 快速恢复:当发送方连续收到三个重复确认,执行乘法减小,慢开始门限值减半;于发送方可能认为网络现在没有拥塞,因此与慢开始不同,发送报文段的数量减半,然后执行拥塞避免算法,线性增加发送报文段的数量。
-
停止等待协议
- 发送后等待 ACK 再发送下一个
- 超时重发
- 太慢,信道利用率低
-
滑动窗口:窗口内连续发送
- GBN:接收方支队正确顺序到达的帧发送确认(否则丢掉,并确认最后一个收到的帧),出现超时重传时重传窗口内的所有帧(效率较低、传输大量不必要数据)
- 选择重传:允许非按顺序到达,对每个正确接受的帧单独确认,只有超时的帧才会被重传(实现复杂度较高,但是更高效的利用带宽)
-
什么是 TCP 粘包?如何解决
- 发送方原因:TCP 默认使用 Nagle 算法(减少网络中报文段的数量)只有上一个分组得到确认,才会发送下一个分组;收集多个小分组,在一个确认到来时一起发送
- 如果一次请求发送的数据量比较小,没达到缓冲区大小,TCP 则会将多个请求合并为同一个请求进行发送,这就形成了粘包问题。
- 如果一次请求发送的数据量比较大,超过了缓冲区大小,TCP就会将其拆分为多次发送,这就是拆包。
- 接收方原因:TCP 接收到数据包时,并不会马上交到应用层进行处理,或者说应用层并不会立即处理。TCP 将接收到的数据包保存在接收缓存里,然后应用程序主动从缓存读取收到的分组。这样一来,如果 TCP 接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度,多个包就会被缓存,应用程序就有可能读取到多个首尾相接粘到一起的包。
- 对于发送方造成的粘包问题,可以通过关闭 Nagle 算法来解决
- 接收方只能将问题交给应用层来处理:循环处理,应用程序从接收缓存中读取分组时,读完一条数据,就应该循环读取下一条数据,直到所有数据都被处理完成(通过格式化数据即添加特殊开始符和结束符或者发送数据长度)
- 发送方原因:TCP 默认使用 Nagle 算法(减少网络中报文段的数量)只有上一个分组得到确认,才会发送下一个分组;收集多个小分组,在一个确认到来时一起发送
网络层¶
IP¶
- IP 地址的结构:网络 id+主机 id
- 同一个物理网络上的所有主机都使用同一个网络 id ,每个网络主机有一个唯一的主机 id
- ip 地址分类
- A 类地址:由 1 字节的网络地址和 3 字节的主机地址组成
- B 类地址:由 2 个字节的网络地址和 2 个字节的主机地址组成
- C 类地址:由 3 字节的网络地址和 1 字节的主机地址组成
- D 类地址:用于多点广播
- E 类地址:以“11110”开始,为将来使用保留
- 此外在 abc 中还保留了三个区域作为内网私有地址:10.0.0.0~10.255.255.255;172.16.0.0~172.31.255.255;92.168.0.0~192.168.255.255
- arp:地址解析协议:根据主机的 ip 地址获取主机的 mac 地址。
- 首先,A 使用缓存的 ARP 表根据 B 的 ip 地址查找 mac 地址,如果找到 MAC 地址,就可以发送消息。如果没有,A 就会发送一个局域网广播的 ARP 请求 B 的 MAC 的,B 返回一个包含 MAC 和 IP 地址的 ARP 响应消息。作为响应请求的一部分,B 可以将 A 的一个条目插入到它的 ARP 表中,以备将来使用。
- icmp: 因特网控制报文协议
- 传输控制信息辅助网络层通讯
- 如 ip 丢包、ping、traceroute 等
- ping 的执行过程
- ping 程序会构造一个 ICMP 回显请求消息(封装在一个 IP 数据包,含序列号以及时间戳用于跟踪和匹配回显应答)通过网络发送的目标主机
- 目标主机收到 ICMP 回显请求,它会构造一个 ICMP 回显应答消息,包括原始请求中的序列号和时间戳,同样封装在 IP 数据包并返回
- 发送者收到回显应答之后,PING 会计算往返时间,来估计延迟
- PING 通常会发送多个回显请求,一遍更加准确的计算平均值
数据链路层¶
- 将网络层传下来的分组添加首部和尾部,用于标记帧的开始和结束。
- 如果帧的数据部分含有和首部尾部相同的内容,那么帧的开始和结束位置就会被错误的判定。需要在数据部分出现首部尾部相同的内容前面插入转义字符。如果数据部分出现转义字符,那么就在转义字符前面再加个转义字符。在接收端进行处理之后可以还原出原始数据。这个过程透明传输的内容是转义字符,用户察觉不到转义字符的存在。
- 差错检测:数据链路层广泛使用了循环冗余检验(CRC)来检查比特差错。
MAC¶
- MAC 地址用于在网络中唯一标示一个网卡。
- MAC 地址与 IP 的关系
- 联网中主机之间相互传递数据的逻辑是,先通过 ip 地址找到对应的局域网,然后再用 MAC 找到对应的主机。
- 如果只采用 ip 地址,不用 mac 地址:不安全,同一个 ip 地址可能绑定多个主机,而无论何时 mac 地址和主机是一一对应的。
- 如果只采用 mac 地址,不用 ip 地址:没有办法使用 ip 通过网段寻找目标主机,需要在全网段内没有规律的找一个主机,效率太慢。
物理层¶
-
通信方式
- 单工通信:单向传输
- 半双工:双向交替通信
- 全双工:双向同时通讯
-
信道复用
- 频分复用 FDM:将信道的总带宽划分为多个独立的子带宽
- 时分复用 TDM:将时间分为若干个时隙,将不同信号分配到不同的时隙中进行传输
- 波分复用 WDM:将光信号分为不同的波长进行传输
- 码分复用 CDM:不同的码片序列对信号进行编码和解码,实现信号在同一信道上的同时传输
网络安全¶
D/Dos¶
- 通过消耗目标系统的资源,使目标系统无法正常提供服务。
- Dos:拒绝服务攻击
- 通常由单个攻击者发起,通过向目标系统发送大量请求或特制的恶意数据包,使目标系统的资源耗尽,从而导致正常用户无法访问目标系统。
- 攻击者的 IP 地址容易被识别,从而受到追踪和制裁。
- DDos:分布式拒绝服务攻击
- 它利用多个受控制的计算机(僵尸网络)同时发起攻击,使攻击更难以防御和追踪。
-
防御方式:
- 限制单个 IP 地址的请求速率。
- 采用负载均衡技术分散请求压力。
- 与互联网服务提供商(ISP)合作,进行流量清洗和封锁恶意 IP 地址。
- 使用防火墙、入侵检测系统(IDS)和入侵预防系统(IPS) 等安全设备。
-
防御 SYN 攻击
- 减少 SYN-ACK 重试次数
- 使用 SYN-cookie:第二次握手时服务器分配一个 cookie 给客户端(此时先不分配资源),第三次返回检查 cookie 之后再分配资源
ARP¶
- ARP 攻击就是攻击者通过伪造 ARP 请求和应答报文,使目标设备与网络中其他设备之间的通信受到干扰,从而达到窃取、篡改数据或拒绝服务的目的。
- ARP 欺骗:攻击者向网络中的设备发送伪造的 ARP 应答报文,使得目标设备将攻击者的 MAC 地址与一个错误的 IP 地址绑定。这样,目标设备在与错误 IP 地址通信时,实际上会将数据发送给攻击者。
- ARP 中间人攻击:攻击者向两台通信设备发送伪造的 ARP 应答报文,使它们分别将攻击者的 MAC 地址与对方的 IP 地址绑定。这样,攻击者可以截获、窃取、篡改这两台设备之间的通信数据,实现中间人攻击。
- 防御方式
- 静态 ARP 表:在网络设备上配置静态 ARP 表,将 IP 地址和 MAC 地址的对应关系固定下来,使攻击者无法通过伪造 ARP 报文篡改地址映射关系。
- ARP 防护设备:部署 ARP 防护设备,如防火墙、入侵检测系统(IDS)等,以监控和阻止异常 ARP 报文。
- 动态 ARP 检查(Dynamic ARP Inspection,DAI):在交换机上启用 DAI 功能,检查通过交换机的 ARP 报文,验证其 IP 地址和 MAC 地址的对应关系,拦截异常 ARP 报文。