计算机网络复习

爱喜剧的魔王

已于 2022-07-26 17:46:38 修改

阅读量186

点赞数

分类专栏：面试复习文章标签：网络

于 2022-07-26 11:16:56 首次发布

本文链接：https://blog.csdn.net/orz_include/article/details/125991035

版权

面试复习专栏收录该内容

11 篇文章 0 订阅

订阅专栏

计算机网络一轮复习

一、计算机网络体系结构

OSI（7）

1、应用层

2、表示层：序列化和反序列化

3、会话层

4、传输层

5、网络层：路由器

6、数据链路层：交换机

7、物理层：集线器

TCP/IP（4）

1、应用层

HTTP/HTTPs、SMTP、POP3/IMAP、FTP、Telnet、SSH、ping、DNS

2、传输层

TCP、UDP

3、网际层

IP、ARP、ICMP

4、网络接口层

二、网络层

1、ip的分类

ip = 网络号+主机号
- A类：8+24，0开头
- B类：16+16，10开头
- C类：24+8，110开头
- D类：1110开头，28
- E类：11110开头
主机号全为1为广播地址

2、ARP

地址解析协议，将IP转成MAC
为什么要mac还要ip
- ip可以自己改，mac不能
- ip是收获地址，mac是收件人

三、传输层

TCP

1、⭐三次握手

过程（缺一不可）
- Client —syn（握手信号）— Server：S确认接受正常，C发送正常
- Server—ack（确认信号）、syn—Client：C接受正常，S发送正常
- Client—ack—Server：S、C收发正常
为什么第二次要将syn传回
- 回传 SYN 则是为了建立并确认从服务端到客户端的通信

2、四次挥手

过程
- Client—fin（断开信号）—Server
- Server—ack—Client
- Server—fin—Client：C不知道S是否已经完成通信，所以要再进行两次挥手
- Client—ack—Server

3、⭐可靠传输

数据包校验：检查TCP首部和数据的校验和是否改变
数据的重排序：TCP将数据划分为合适的大小并编号发送给接收端，接收端接到后进行重排序
流量控制
- 发送方仅允许发送接受方发送接受方数据缓存可容纳的大小
- 通过滑动窗口实现
拥塞控制
- TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
  - 慢开始
    - 发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 …
  - 拥塞避免
    - 设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1
    - 如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始（cwnd 设定为 1）
  - 快重传
    - 在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认
    - 在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3
  - 快恢复
    - 当3-ACK时，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免
    - 慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。
ARQ协议：自动重传请求（Automatic Repeat-reQuest，ARQ）
- 等待确认
- 超时重传：发送段后启动计时器，没有收到确认就重传

4、对应的常见应用层协议

FTP: File Transfer Protocol (文件传输协议), 默认端口(20用于传输数据，21用于传输控制信息)
SSH：Secure Shell（安全外壳协议），默认端口 22
TELNET: Teletype over the Network (网络电传), 默认端口23
SMTP: Simple Mail Transfer Protocol (简单邮件传输协议) ,默认端口25
HTTP：HyperText Transfer Protocol（超文本传输协议），默认端口80

UDP

1、⭐TCP与UDP的区别

是否面向连接
是否可靠
传输的形式：TCP（字节流）、UDP（数据报文段）
传输的效率：UDP更快
消耗的资源：TCP首部（20-60字节）、UDP（8字节）
场景：TCP（文本、网页、邮件）、UDP（媒体）

2、UDP如何实现可靠传输

利用应用层实现
解决：模仿TCP的可靠传输技术
- 确认应答
- 超时重传（添加计时器）
- 添加包序号，数据包重排
已有技术
- UDT：基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）
- RUDP

3、对应的常见应用层协议

DNS : Domain Name Service (域名服务),默认端口 53
TFTP: Trivial File Transfer Protocol (简单文件传输协议)，默认端口69
SNMP：Simple Network Management Protocol（简单网络管理协议），通过UDP端口161接收，只有Trap信息采用UDP端口162。

四、应用层

HTTP

1、特点

①简单快速：客户端向服务器发送请求时，只需传送请求方法和路径即可。
②灵活：HTTP允许传输任意类型的数据对象。
③无连接：限制每次连接只处理一个请求。服务器处理完客户请求，并收到客户应答后，即断开连接。
④无状态：协议对于事务处理没有记忆能力。
⑤支持B/S及C/S模式。

2、HTTP与HTTPs

HTTPs
- Http+SSL/TLS（安全套接字协议）
- 过程：先使用非对称加密传递对称加密的密钥（用CA保证不会被换），然后用对称加密进行会话
区别
- 端口不同：Http是80，Https443
- 安全性：http是超文本传输协议，信息是明文传输，https则是通过SSL加密处理的传输协议，更加安全。
- 是否证书（付费）：https需要拿到CA证书，需要付费
- 资源消耗： HTTPS 比 HTTP 耗费更多服务器资源

3、HTTP中的请求方式

分类
- GET POST PATCH PUT DELETE
Get和Post的区别
- url是否可见
- 数据传输的方式：get（url）、post（body）
- 缓存：get可以缓存，post不能
- 页面后退：get不会重新提交请求，post会
- 传输数据的大小：get（2-4k），post（可以上传大数据）
- 安全性：post比get安全，但也可以通过抓包获取

4、常用的HTTP状态码

状态码	含义
100	继续请求
200	成功
204	成功但没返回
301	重定向
302	临时重定向
304	未修改
400	http请求错误
401	没权限
403	非法访问
404	找不到
500	服务器错误
502	网关错误
503	服务不可用
504	网关超时

5、HTTP无状态

每个请求都是独立的，不会对上一请求的状态进行保存
如何有状态：cookie和session
- cookie：保存在客户端，保存用户信息
- session：保存在服务器，记录用户状态
- 区别：
  - 存放位置
  - 安全性：session高
  - 有效期：session短，cookie长
- cookie被禁用
  - 加在url上
  - 使用 token + LocalStorage/SessionStorage（关浏览器清空）
- 使用session的问题
  - 如果服务器做了负载均衡有多个服务器，用户的请求到达某个服务器时，这个服务器没有用户的session信息，就会会话失败。所以Session默认机制下是不适合分布式部署的
  - 解决：使用Token
- 使用cookie可能受到的攻击
  - CRSF（跨域伪造请求）：利用网站的cookie
    - 解决：除了cookie，在请求中再加一个token
JWT身份认证
- Session-Cookie身份认证
  - 过程
    - 用户成功登陆系统，然后返回给客户端具有 SessionID 的 Cookie
    - 当用户向后端发起请求的时候会把 SessionID 带上，这样后端就知道你的身份状态了
  - 问题
    - 依赖 Session 的关键业务一定要确保客户端开启了 Cookie
    - CRSF攻击
    - 分布式架构下通过负载均衡到没有session信息的机器上需要重新登录
- Token
  - 解决问题
    - 服务器只需要对token进行解密就可以验证身份，不需要再查询数据库
    - 代替session-cookie的方式，使服务器无状态，可以在多个服务间共享，适用于分布式服务
    - 一般放在localStorage中，用户发起请求时前端代码再将token放入header（浏览器不会自动加入header），避免crsf（跨域请求伪造）攻击
  - JWT：Json Web Token，是目前最流行的跨域认证解决方案，是一种基于 Token 的认证授权机制。
- JWT的组成
  - Header：JSON 形式的 Header 被转换成 Base64 编码，成为 JWT 的第一部分
    - typ（Type）：令牌类型，也就是 JWT。
    - alg（Algorithm）：签名算法，比如 HS256。
  - Payload：放一些声明（包括生效时间和过期时间），Payload 部分默认是不加密的，转换成 Base64 编码成为 JWT 的第二部分，一定不要将隐私信息存放在 Payload 当中
    - Registered Claims（注册声明） ：预定义的一些声明，建议使用，但不是强制性的。
    - Public Claims（公有声明） ：JWT 签发方可以自定义的声明，但是为了避免冲突，应该在 IANA JSON Web Token Registryopen in new window 中定义它们。
    - Private Claims（私有声明） ：JWT 签发方因为项目需要而自定义的声明，更符合实际项目场景使用。
  - Signature：Signature 部分是对前两部分的签名，作用是防止 JWT（主要是 payload）被篡改
    - 计算公式：
```
HMACSHA256( base64UrlEncode(header)+ "." + base64UrlEncode(payload),secret)
```
- JWT的优点
  - 无状态：服务器不需要存储 Session 信息。这显然增加了系统的可用性和伸缩性，大大减轻了服务端的压力
  - 有效避免了crsf攻击
  - 适合移动端应用：本地存储（不用cookie），跨语言
  - 单点登录（SSO）友好：不会有Cookie 跨域的问题
- JWT的缺点
  - 注销登录等场景下 JWT 还有效
    - 将 JWT 存入内存数据库（Redis）
    - 黑名单机制
    - 用户修改密码时：用用户的密码的哈希值对 JWT 进行签名。因此，如果密码更改，则任何先前的令牌将自动无法验证
  - JWT的续签问题
    - 类似于 Session 认证中的做法：假设服务端给的 JWT 有效期设置为 30 分钟，服务端每次进行校验时，如果发现 JWT 的有效期马上快过期了，服务端就重新生成 JWT 给客户端。
    - JWT 有效期设置到半夜

6、HTTP版本的对比

HTTP 1.0：默认使用短连接，每次请求都需要建立一个TCP连接。它可以设置Connection: keep-alive 这个字段，强制开启长连接。
HTTP 1.1（当前）：
- 引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
- 管道机制，即在同一个TCP连接里面，客户端可以同时发送多个请求
- HTTP/1.1在请求头中加入了Host字段
HTTP 2.0：
- 二进制协议，1.1版本的头信息是文本（ASCII编码），数据体可以是文本或者二进制；2.0中，头信息和数据体都是二进制
- 完全多路复用，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应
- 服务端推送，允许服务器未经请求，主动向客户端发送资源
- 报头压缩，HTTP协议不带有状态，每次请求都必须附上所有信息。Http/2.0引入了头信息压缩机制，使用gzip或compress压缩后再发送