运维常见面试题_应用运维面试题

说又槐

于 2024-04-29 20:14:59 发布

阅读量510

点赞数 16

分类专栏：程序员文章标签：运维

本文链接：https://blog.csdn.net/2301_76225520/article/details/138324105

版权

程序员专栏收录该内容

155 篇文章 0 订阅

订阅专栏

运维常见面试题

OSI七层协议模型
TCP：三次握手与四次挥手
HTTP：状态码
HTTP请求报文与响应报文
HTTP中cookie和session的作用
rm -rf避免
K8S容灾及高可用
python：魔术方法
python深拷贝和浅拷贝
zookeeper集群选举机制
redis集群种类，选举

OSI七层协议模型

7层是指OSI七层协议模型，从7到1分别为：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。

TCP：三次握手与四次挥手

三次握手（建立连接）

第一次：客户端向服务端发送连接建立请求。
传递两件事：a.希望建立连接。b.指明可用哪个syn同步序列号回应。
第二次：服务端接收到请求，用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应客户端，并与客户端建立连接。传递两件事：b.我已收到请求，具备接收能力。a.你可使用该syn来回应我。
第三次：客户端接收服务端响应后，向服务端发送ack确认包。传递一件事：a.告诉服务端，自己已接收并具有数据传输能力。
- 状态解释：
  send_syn：发送syn中。
  receive_syn：接到syn包。
  send_ack：发送确认包ack。
  receive_ack：收到确认包ack。
- 为什么需要三次握手，及场景。
  通过两次握手，客户端与服务端之间可建立连接。假如遭遇网络延迟，客端发出的第一次握手请求，直到客户端超时后才送到服务端，此时服务端返回响应并建立连接，客户端并不知晓，也就不会传输数据因而造成资源浪费。
- 提炼，第三次握手的必要性。
  a.告诉服务端，客户端具有数据传输能力。（稳定连接）
  b.节省资源消耗。

四次挥手
- 一方主动关闭
- 双方同时请求关闭
  
  客户端/服务端均可请求关闭连接，且可同时请求。
  请求关闭连接的一方向对方发送FIN包，并进入FIN_WAIT_1状态。接收到关闭请求的一方向对方发送接收确认包ACK为FIN包内容+1,并进入CLOSE_WAIT状态，在向对方发送请求关闭FIN包，进入LAST_ACK状态。接收到最后一个FIN包的一方，向对方发送接收确认包ACK为FIN包内容+1，并进入TIME_WAIT状态，等待2MSL周期后视为确认对方已关闭并释放本方连接。
- 状态解释。
  从图可清晰的看出，每个状态代表的意思。
  FIN_WAIT_1：即为发送了第一个FIN包，等待回应。
  CLOSE_WAIT：即为接收到了关闭请求，等待关闭。
  FIN_WAIT_2：即为单方关闭请求情况中，接收到回应的关闭请求FIN。
  LAST_ACK：即为已发出最后的关闭请求FIN包，等待对方已收到的回应。
  TIME_WAIT：即等待一个固定时长确保对方已关闭后自己在关闭。
  CLOSED：即为已经关闭连接

HTTP：状态码

分类	描述
1**	消息，一般是告诉客户端，请求已经收到了，正在处理，别急…
2**	处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
3**	重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
4**	处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
5**	处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等。

举例
100 Continue 继续。客户端应继续其请求。
200 OK: 请求成功。
302 Found: 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。
400 Bad Request：客户端请求的语法错误，服务器无法理解。
405 Method Not Allowed：客户端请求中的方法被禁止。
500 Internal Server Error：服务器内部错误，无法完成请求。

HTTP请求报文与响应报文

请求报文：
响应报文

HTTP中cookie和session的作用

session机制采用的是在服务端保持状态的方案，而cookie机制则是在客户端保持状态的方案，cookie又叫会话跟踪机制。打开一次浏览器到关闭浏览器算一次会话。HTTP协议是一种无状态协议，在数据交换完毕后，服务端和客户端的链接就会关闭，每次交换数据都需要建立新的链接。此时，服务器无法从链接上跟踪会话。cookie可以跟踪会话，弥补HTTP无状态协议的不足。

cookie分为会话cookie和持久cookie。
会话cookie：浏览器关闭则cookie销毁.
持久cookie：生命周期expires到期，则cookie销毁。
cookie的缺点:
保存在客户端
存储大小有限
用户可见可修改

session工作流程，寻找cookie中的session id。根据session id去服务器内存中找到相应的用户资料。如果没有找到则新建，根据资料来判断用户访问的状态。
一般通过redis集群来同步seesion，解决负载均衡指向不同服务器的情况。

session与cookie的区别:

1、存放位置不同

Cookie保存在客户端，Session保存在服务端。

2 、存取方式的不同
Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二进制数据，需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息，运用Cookie是比拟艰难的。

而Session中能够存取任何类型的数据，包括而不限于String、Integer、List、Map等。Session中也能够直接保管Java Bean乃至任何Java类，对象等，运用起来十分便当。能够把Session看做是一个Java容器类。

3、安全性（隐私策略）的不同

Cookie存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。假如选用Cookie，比较好的方法是，敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密，提交到服务器后再进行解密，保证Cookie中的信息只要本人能读得懂。而假如选择Session就省事多了，反正是放在服务器上，Session里任何隐私都能够有效的保护。

+ 4、有效期上的不同只需要设置Cookie的过期时间属性为一个很大很大的数字，Cookie就可以在浏览器保存很长时间。 由于Session依赖于名为JSESSIONID的Cookie，而Cookie JSESSIONID的过期时间默许为–1，只需关闭了浏览器（一次会话结束），该Session就会失效。


+ 5、对服务器造成的压力不同Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。而Cookie保管在客户端，不占用服务器资源。假如并发阅读的用户十分多，Cookie是很好的选择。


+ 6、 跨域支持上的不同Cookie支持跨域名访问，例如将domain属性设置为“.baidu.com”，则以“.baidu.com”为后缀的一切域名均能够访问该Cookie。跨域名Cookie如今被普遍用在网络中。而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。

rm -rf避免

方法一：校验rm中使用的变量
提醒一下，在shell脚本中使用到rm命令并且rm命令的参数中有带有变量时，需要特别注意变量名是否与上面声明的保持一致，还有一种做法就是：在引用变量的时候使用下面的方法，可以确保变量不会为空。
比如上面的DIRPATH变量，在引用此变量作为rm的参数的时候，使用如下方式：
rm -rf ${DIRPATH:-default}/bin/
${DIRPATH:-default}：表示如果变量DIRPATH没有被声明或者已经声明，但是赋值为空，那么就使用默认值default，否则就使用DIRPATH初始化的值
方法二：回收站，在重定向rm命令
方法三：改用safe-rm命令，在配置文件中配置不会被删除的路径

K8S容灾及高可用

【安全版本】
Kubernetes v1.13.12
Kubernetes v1.14.8
Kubernetes v1.15.5
Kubernetes v1.16.2

k8s中需要高可用的组件（包括内置已实现的）以及实现方式？
https://www.cnblogs.com/ants/p/11489598.html#_labelTop
http://press.demo.kuboard.cn/install/install-kubernetes.html
- SLB(LVS+HAProxy)
- etcd集群
  为什么需要3台物理机以上？
  主要是考虑到了etcd的问题，如果只有两台物理机部署了5个etcd节点，那么部署了3个etcd的那台物理机故障了，则不满足etcd失败容忍度而导致etcd集群宕机，从而导致k8s集群宕机
- K8S Node (Master / Worker)
  三个 master 组成主节点集群，通过内网 loader balancer 实现负载均衡；至少需要三个 master 节点才可组成高可用集群，否则会出现脑裂现象
  多个 worker 组成工作节点集群，通过外网 loader balancer 实现负载均衡
k8s中需要常期备份的组件及文件，容灾恢复？
答：
- etcd定义及作用：
  基于GO开发的高可用的分布式键值(key-value)数据库，用于服务发现（即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接），实现分布式系统数据的可用性和一致性。
  优点：1.支持SSL证书验证，2.提供HTTP API。
  备份方法：通kind: CronJob,挂载/var/lib/etcd，执行etcdctl备份命令。
  恢复：移除损坏的/var/lib/etcd，docker镜像任务挂载/var/lib/etcd，执行etcdctl恢复命令【待恢复的机器上，机器名称和ip地址需要与崩溃前的主节点配置完成一样】。
- 用户主目录下.kube/config文件(kubectl连接认证)
- 【2】/etc/kubernetes/目录下的所有文件(证书，manifest文件)
- 【3】/var/lib/kubelet/目录下所有文件(plugins容器连接认证)
  （2），（3）可通过CronJob进行每日备份，tar。
- 恢复步骤：
  - kubeadm reset,iptables等
  - 恢复etcd数据
  - 删除/etc/kubernetes/manifest/目录下的文件，及/var/lib/kubelet/pki/目录下的文件
  - 还原【2】【3】
  - kubeadm init
  - 还原./kube/config，执行命令测试。
k8s-master集群有哪些组件
- apiserver：一个api服务器，所有外部与k8s集群的交互都需要经过它。（可水平扩展）
- controller-manager：执行控制器逻辑（循环通过apiserver监控集群状态做出相应的处理）（一个master集群中只会有一个节点处于激活状态）
- scheduler：将pod调度到具体的节点上（一个master集群中只会有一个节点处于激活状态）

python：魔术方法

构造函数，析构函数

	__init__，__del__，__new__:
	__new__：是用来创建类并返回这个类的实例
**先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前在阿里**

**深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**

**因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。**
![img](https://img-blog.csdnimg.cn/img_convert/6dc4d2f5bf4ace02c260d2f30f367062.png)
![img](https://img-blog.csdnimg.cn/img_convert/d519717e5604b21c8e39a7548aecaccc.png)
![img](https://img-blog.csdnimg.cn/img_convert/7ab45ed9e542b55a1c0444a77dfc72eb.png)
![img](https://img-blog.csdnimg.cn/img_convert/c4585a3f39d14f038a84730f5699d4b7.png)
![img](https://img-blog.csdnimg.cn/img_convert/32d3edcf710a457d42caebd20593a035.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[需要这份系统化的资料的朋友，可以点击这里获取！](https://bbs.csdn.net/topics/618542503)**

888177)]
[外链图片转存中...(img-ze8SsmsY-1714392888178)]

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！**

**由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

**[需要这份系统化的资料的朋友，可以点击这里获取！](https://bbs.csdn.net/topics/618542503)**

说又槐

关注

16
点赞
踩
22

收藏

觉得还不错? 一键收藏
0
评论
运维常见面试题_应用运维面试题

Cookie存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。session机制采用的是在服务端保持状态的方案，而cookie机制则是在客户端保持状态的方案，cookie又叫会话跟踪机制。7层是指OSI七层协议模型，从7到1分别为：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。
复制链接

扫一扫