1、rsync 是否是加密传输的?
以守护进程的形式启动 rsync 服务时是不加密传输,但也可以使用基于 SSH 的加密传输。
2、常见服务及其端口号。
服务名 | 端口号 |
---|---|
HTTP | 80 |
https | 443 |
SQLServer | 1433 |
Oracle | 1521 |
MySQL | 3306 |
FTP | 20、21 |
SSH | 22 |
Tomcat | 8080 |
Telnet | 23 |
SMTP | 25 |
Redis | 6379 |
NFS | 2049 |
Portmapper | 111 |
Samba | 137/udp、138/udp、139/tcp、445/tcp |
Rsyncd | 873 |
3、HTTP 常见状态码及其含义。
状态码 | 描述 |
---|---|
200 | OK 成功的返回页面 |
301 | 永久跳转,所有来源的请求全部指定到新的位置 |
302 | 临时重定向,每次请求都会先请求源地址,然后在去请求新的位置 |
307 | 内部跳转 |
304 | 页面未被修改 |
400 | 客户端错误 |
401 | 认证错误 |
403 | 权限错误 |
404 | 找不到指定页面 |
500 | 服务器内部错误 |
502 | 坏的网关,如负载均衡节点或者 lnmp 代理往后没找到是 |
503 | 服务器负载过高,或者停机维护 |
504 | 网关超时,在请求后端服务器,后端服务器没有在约定的时间返回数据时 |
4、Nginx 的优化。
1、CPU 亲和、worker 进程数、调整每个 worker 进程可打开的文件数;
2、使用 epool 模型、调整每个 worker 进程的最大连接数;
3、文件的高效读取配置:sendfile、tcp_nopush;
4、文件的传输实时性配置:tcp_nodealy;
5、开启 tcp 长连接,合理控制长连接时间;
6、开启文件传输压缩 gzip;
7、开启静态文件缓存;
8、隐藏 Nginx 版本号;
9、禁止通过 IP 地址访问,禁止恶意域名解析,只允许域名访问;
10、配置防盗链、以及跨域访问;
11、防 DDOS、cc 攻击,限制单 IP 并发连接,以及 http 请求;
12、优雅重定向错误页面;
13、添加 HTTPS 支持;
14、使用 Nginx 代理缓存,如 proxy_cache、fastcgi_cache、uwsgi_cache 缓存,第三方工具(squid、varnish);
5、shell 获取字符串变量长度的几种方式。
$ name='zhangsan'
$ echo ${#name}
8
$ echo $name | awk '{print length}'
8
$ expr length "$name"
8
6、网络七层。
物理层
数据链路层
网络层
传输层
会话层
表示层
应用层
7、详述 MySQL 主从复制原理自己配置主从的步骤。
原理:
1. 从库执行 change master to ...,将 change master to ... 指定的信息保存到 master.info 中;
2. 从库通过 start slave 启动 SQL 线程 和 IO 线程;
3. 从库 IO 线程请求到达主库的连接层,与主库的 dump 线程建立连接;
4. 从库通过已建立连接向主库请求 bin log 日志;
5. 主库响应从库的请求返回 bin log 日志;
6. 从库将返回 bin log 日志的状态信息保存到 master.info 中,并将接受到的 bin log 日志保存到 relay log;
7. 从库的 SQL 线程读取 relay.info 中的回放状态信息,从 relay log 中读取并回放最新接收到的日志;
步骤:
1. 主库开启 bin log,配置 server-id;
2. 从库开启 relay log 日志,配置 server-id;
3. 主库创建拥有复制权限的账号;
2. 从库执行 change master to <主库信息>;
3. 从库执行 start slave 启动 SQL 线程和 IO 线程;
注:如果主库事先已存在数据,则需要先做全备并记录 bin log 日志点,再从库恢复全备,change master to 时指定相应的位置点;
8、ansible 常用模块。
1. file:文件内容填充;
2. copy:文件拷贝;
3. template:使用 jinjia2 模板做变量替换;
4. yum:安装软件;
5. yumrepository:配置 yum 仓库;
6. iptables:批量管理 iptables 规则;
7. service:管理服务;
8. systemd:同 service;
9. mysql:mysql 管理;
10. group:用户组管理;
11. user:用户管理;
12. shell:执行命令;
13. cron:定时任务管理;
9、docker 容器时间跟宿主机时间不同的解决方案。
导致该问题的原因是容器的时区和宿主机时区不一致。
解决方案有如下两种:
1、直接以宿主机的时区配置文件替换容器中的时区配置文件,docker cp /etc/localtime a9c27487faf4:/etc/localtime
2、进入容器进行修改:ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
最后重启容器。
10、编写一个 shell 脚本将 /boot/grub
目录下大于 100K 的文件转移到 /opt
目录下。
find /boot/grub -size +100K | xargs -i mv {} /opt
11、如何查看某进程打开的所有文件。
$ lsof -c <进程名>
$ lsof -p <进程 ID>
12、发现系统中存在大量的 TIME_WAIT 状态的连接,请分析原因,并列出三条以上的优化建议。
根据 TCP 协议定义的 3 次握手断开连接规定,发起 socket 主动关闭的一方,socket 将进入 TIME_WAIT 状态,TIME_WAIT 状态将持续 2 个 MSL(Max Segment Lifetime),在 Windows 下默认为 4 分钟,即 240 秒,TIME_WAIT 状态下的 socket 不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于 TIME_WAIT 状态的 socket,甚至比处于 ESTABLISED 状态下的 socket 多的多,严重影响服务器的处理能力,甚至耗尽可用的 socket,停止服务。 TIME_WAIT 是 TCP 协议用以保证被重新分配的 socket 不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。
建议:
1、启用 keepalived 长连接,尽量让一个连接处理多个请求,以最大程度的复用;
2、修改内核参数 net.ipv4.tcp_tw_reuse = 1,让 socket 文件立即可以被重用于新的 TCP 连接;
3、修改内核参数 net.ipv4.tcp_tw_recycle = 1,让占用 socket 文件的连接快速回收,可被新的连接可使用;
4、修改内核参数 net.ipv4.tcp_fin_timeout = 30,缩短关闭连接的超时时间,使连接关闭更迅速;
13、Linux 如何防止 DDOS 攻击。
分析请求日志,将短时间频繁请求的 IP 使用防火墙禁掉;
限制单位时间内处理的请求数量;
14、ansible 同时分发多台服务器的过程很慢(它是逐台分发的),你想过怎么优化吗?
1. 修改 forks 属性,控制并行进程的数量,默认为 5;
2. 修改 async 属性,开启异步模式,对应还有 poll 属性可控制轮询查看结果的间隔时间;
15、写 SQL,查询 xuesheng
表每门课都大于 80 分的学生姓名。
name | kecheng | score |
---|---|---|
张三 | 语文 | 81 |
张三 | 数学 | 73 |
李四 | 语文 | 86 |
李四 | 数学 | 90 |
王五 | 数学 | 89 |
王五 | 语文 | 88 |
王五 | 英语 | 96 |
select name,count(1) as kemushu,sum(case when score>80 then 1 else 0 end) jigeshu from xuesheng group by name having jigeshu=kemushu;
16、简要介绍一下 redis 的持久化机制,说明各自的优缺点。
RDB: 类似于快照,当前内存里的数据的状态持久化到硬盘。
优点:压缩格式/恢复速度快;
缺点:不是实时的,可能会丢数据,操作比较重量;
AOF:类似于 MySQL 的 binlog,可以设置成每秒/每次操作都以追加的形式保存在日志文件中;
优点:安全,最多只损失 1 秒的数据,具备一定的可读性;
缺点:文件比较大,恢复速度慢;
评论区