N93-第六周作业

第六周	
第17天-名称解析服务DNS	
第18天-Linux防火墙
第19天-MySQL基础入门第六周作业
1. 总结sudo配置文件格式，总结相关示例。
2. 搭建时间同步服务器，详细总结配置和搭建过程
3. 总结常见的日志服务管理的常见日志服务
4. 总结日志分类, 优先级别。图文并茂解释应用如何将日志发到rsyslog,并写到目标。
5. 完成功能，将3个主机(要求主机名为ip)的ssh日志，通过rsyslog服务将ssh日志写入到集中的主机上的rsyslog服务，写入到/var/log/all-ssh.log文件
6. 总结/var/log/目录下常用日志文件作用。
7. 总结journalctl命令的选项及示例
8. 完成将多个主机（要求主机名为ip)的logger命令日志集中写入到mysql表中
9. 尝试使用logrotate服务切割message日志，每天切割一次，要求大于不超过3M, 保存90天的日志, 旧日志以时间为后缀，要求压缩。
10.apache请按照课程完成搭建和练习，本部分不是重点，不出题
11.总结http协议相关面试题，建议面试前背一背。参考链接: https://juejin.cn/post/7117533146454687757
12.总结NAS的部署和安装过程
13.使用inotify + rsync和sersync实现文件的同步，并且总结两种方式的优缺点

第六周作业

1. 总结sudo配置文件格式，总结相关示例。

• sudo意思是superuser do，用来以其他身份来执行命令，预设的身份为root。允许系统管理员让普通用户执行一些或全部的root命令的一个工具
• sudo默认授权规则配置文件是/etc/sudoers,安全编辑授权规则文件和语法检查工具visudo包：sudo
• 配置文件：/etc/sudo.conf

- visudo  #需要管理员用户权限；默认编辑/etc/sudoers文件
- visudo -c  #/etc/sudoers文件，检查语法
- visudo -f /etc/sudoers.d/test  #检查指定配置文件语法

sudo授权规则配置

• 配置文件格式说明：/etc/sudoers,/etc/sudoers.d/
• 配置文件中支持使用通配符 glob模块

? 任意单一字符
* 匹配任意长度字符
[wxc] 匹配其中一个字符
[!wxc] 除了这三个字符的其它字符
\x 转义
[[alpha]] 字母

sudoers授权规则格式：

用户 登入主机=(代表用户) 命令
user host=(runas) command

范例:

[root@localhost ~]#visudo  #命令进行修改，避免出现语法错误导致无法sudo的情况。
shuai 192.168.134.135=(root) /usr/sbin/,!/usr/sbin/useradd  #授权shuai用户登入192.168.134.135主机代表root执行/usr/sbin/下的命令，不可以执行/usr/sbin/useradd添加用户命令
#root ALL=(ALL) ALL  #授权root用户登入所有主机代表所有用户执行所有命令
验证:
[shuai@localhost root]$useradd ooo
useradd: Permission denied.
useradd: cannot lock /etc/passwd; try again later.
[shuai@localhost root]$sudo useradd ooo
Sorry, user shuai is not allowed to execute '/sbin/useradd ooo' as root on localhost.localdomain.
[shuai@localhost root]$pvsWARNING: Running as a non-root user. Functionality may be unavailable./run/lock/lvm/P_global:aux: open failed: Permission denied
[shuai@localhost root]$sudo pvsPV             VG Fmt  Attr PSize    PFree/dev/nvme0n1p2 rl lvm2 a--  <199.00g    0 

格式说明：

• user：运行命令者的身份
• host：通过哪些主机
• (runas):以哪个用户的身份
• command：运行哪些命令
  授权编辑规则文件的工具：/usr/bin/sudoedit
  执行授权命令：/usr/bin/sudo
  时间戳文件：/var/db/sudo
  日志文件：/var/log/secure
  sudo命令

ls -l /usr/bin/sudo
sudo [-u user] COMMAND  #指定用户执行命令
sudo -i -u shuai  #切换身份功能和su相似，但不一样，sudo必须提前授权，而且要输入自己的密码

-v 显示版本信息等配置信息
-u user 默认为root
-ll 列出用户在主机桑可用的和被禁止的命令
-V 再延长密码有效期5分钟，更新时间戳
-k 清除时间戳（1970-01-01），下次需要重新输密码
-K 与-k类似，还要删除时间戳文件
-b 在后台执行指令
!! 为空默认是root用户，以root权限执行上一条命令

[shuai@localhost root]$sudo -ll
[sudo] password for shuai: 
Matching Defaults entries for shuai on localhost:!visiblepw, always_set_home, match_group_by_gid,always_query_group_plugin, env_reset, env_keep="COLORS DISPLAYHOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENTLC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERICLC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGELINGUAS _XKB_CHARSET XAUTHORITY",secure_path=/sbin\:/bin\:/usr/sbin\:/usr/binUser shuai may run the following commands on localhost:Sudoers entry:RunAsUsers: rootCommands:/usr/sbin!/usr/sbin/useradd

sudo特性：

• 如果未授权用户尝试使用sudo，会提示联系管理员
• sudo提供了丰富的日志，详细地记录了每个用户干了什么。它能够将日志传到中心主机或者日志服务器
• sudo使用时间戳文件来执行类似的"检票"系统。当用户调用sudo并且输入它的密码时，用户获得了一张存活期为5分钟的票
• sudo配置文件时sudoers文件，它允许系统管理员集中的管理用户的使用权限和使用的主机。它所存放的位置默认时在/etc/sudoers,属性必须为0440

2. 搭建时间同步服务器，详细总结配置和搭建过程

[root@Rocky-8 ~]#hostname -I
192.168.134.135 
[root@Rocky-8 ~]#yum -y install chrony
Last metadata expiration check: 3:47:49 ago on Sat 06 May 2023 02:42:21 PM CST.
Package chrony-4.2-1.el8.rocky.0.1.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[root@Rocky-8 ~]#vim /etc/chrony.conf
server ntp.aliyun.com iburst
server cn.ntp.org.cn iburst
server ntp.tencent.com iburst#allow 192.168.0.0/16
allow 0.0.0.0/0  #表示任意，加此行，指定允许同步的网段# Serve time even if not synchronized to a time source.
local stratum 10  #删除此行注释，当互联网无法连接，仍然可以为客户端提供时间同步服务[root@Rocky-8 ~]#systemctl restart chronyd
[root@Rocky-8 ~]#systemctl status chronyd
● chronyd.service - NTP client/serverLoaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)Active: active (running) since Sat 2023-05-06 18:46:34 CST; 21s agoDocs: man:chronyd(8)man:chrony.conf(5)Process: 2048 ExecStopPost=/usr/libexec/chrony-helper remove-daemon-state (code=exited, status=0/SUCCESS)Process: 2059 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)Process: 2054 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)Main PID: 2057 (chronyd)Tasks: 1 (limit: 11174)Memory: 984.0KCGroup: /system.slice/chronyd.service└─2057 /usr/sbin/chronydMay 06 18:46:34 Rocky-8.7 systemd[1]: Starting NTP client/server...
May 06 18:46:34 Rocky-8.7 chronyd[2057]: chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
May 06 18:46:34 Rocky-8.7 chronyd[2057]: Frequency -5.584 +/- 2.146 ppm read from /var/lib/chrony/drift
May 06 18:46:34 Rocky-8.7 chronyd[2057]: Using right/UTC timezone to obtain leap second data
May 06 18:46:34 Rocky-8.7 systemd[1]: Started NTP client/server.
May 06 18:46:39 Rocky-8.7 chronyd[2057]: Selected source 119.28.206.193 (2.rhel.pool.ntp.org)
May 06 18:46:39 Rocky-8.7 chronyd[2057]: System clock TAI offset set to 37 seconds
May 06 18:46:39 Rocky-8.7 chronyd[2057]: Selected source 182.92.12.11 (cn.ntp.org.cn)
#服务启动后会打开端口123/udp
[root@Rocky-8 ~]#ss -ntlu
Netid             State              Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port            Process             
udp               UNCONN             0                  0                                    0.0.0.0:123                               0.0.0.0:*                                   
udp               UNCONN             0                  0                                  127.0.0.1:323                               0.0.0.0:*                                   
udp               UNCONN             0                  0                                      [::1]:323                                  [::]:*                                   
tcp               LISTEN             0                  128                                  0.0.0.0:22                                0.0.0.0:*                                   
tcp               LISTEN             0                  128                                     [::]:22                                   [::]:*                                   #客户端配置
[root@localhost ~]#vim /etc/chrony.conf 
server 192.168.134.135 iburst
[root@localhost ~]#systemctl restart chronyd.service
[root@localhost ~]#systemctl status chronyd.service 
● chronyd.service - NTP client/serverLoaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)Active: active (running) since Sat 2023-05-06 18:53:04 CST; 39s agoDocs: man:chronyd(8)man:chrony.conf(5)Process: 1937 ExecStopPost=/usr/libexec/chrony-helper remove-daemon-state (code=exited, status=0/SUCCESS)Process: 1948 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)Process: 1942 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)Main PID: 1946 (chronyd)Tasks: 1 (limit: 11174)Memory: 956.0KCGroup: /system.slice/chronyd.service└─1946 /usr/sbin/chronydMay 06 18:53:04 localhost.localdomain systemd[1]: Starting NTP client/server...
May 06 18:53:04 localhost.localdomain chronyd[1946]: chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
May 06 18:53:04 localhost.localdomain chronyd[1946]: Frequency -6.069 +/- 1.268 ppm read from /var/lib/chrony/drift
May 06 18:53:04 localhost.localdomain chronyd[1946]: Using right/UTC timezone to obtain leap second data
May 06 18:53:04 localhost.localdomain systemd[1]: Started NTP client/server.
May 06 18:53:10 localhost.localdomain chronyd[1946]: Selected source 192.168.134.135
May 06 18:53:10 localhost.localdomain chronyd[1946]: System clock TAI offset set to 37 seconds#确认同步成功
[root@localhost ~]#chronyc sources -v.-- Source mode  '^' = server, '=' = peer, '#' = local clock./ .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- ntp8.flashdance.cx            2   6    73    21  +5230us[+5230us] +/-  111ms
^- ntp.wdc2.us.leaseweb.net      2   6    65    84  -3119us[-3117us] +/-  224ms
^- stratum2-1.ntp.mow01.ru.>     2   6    37    25  -2920us[-2906us] +/-   59ms
^- 119.28.206.193                2   6    37    23    +32ms[  +32ms] +/-  101ms
^* 192.168.134.135               3   6    37    24    +15ns[  +15us] +/- 5528us

3. 总结常见的日志服务管理的常见日志服务

   日志服务管理涉及对系统及应用运行过程中产生的日志数据进行有效收集、存储、监控和分析，以支持故障排查、安全追踪、性能优化等多种场景。以下是一些常见的日志服务及其特点：1、 rsyslog
简介：rsyslog是Linux系统中广泛使用的日志服务之一，它是syslog的增强版，提供了更高的性能、更好的安全性和模块化设计。
特点：支持多种输入和输出模块，可以灵活地将日志发送到不同的目的地，如文件、数据库、远程服务器等。提供了强大的过滤和格式化功能，可以根据需要筛选和格式化日志信息。配置灵活，支持通过配置文件和命令行参数进行定制。
2、systemd-journal
简介：systemd-journal是systemd提供的日志服务，它采用二进制格式存储日志信息，并支持高效的查询和过滤功能。
特点：可以存储更多的元数据，如时间戳、主机名、优先级等，便于后续的分析和查询。提供了强大的日志查询和过滤功能，可以快速定位到所需的日志信息。与systemd紧密集成，可以方便地管理systemd服务的日志。
3、 ELK Stack（Elasticsearch, Logstash, Kibana）
简介：ELK Stack是一个开源的日志收集、分析和可视化解决方案，由Elasticsearch、Logstash和Kibana三个组件组成。
特点：Elasticsearch是一个分布式搜索引擎，可以高效地存储和检索日志数据。Logstash用于日志收集和处理，支持多种输入和输出插件，可以灵活地配置日志的收集和处理流程。Kibana提供了一个友好的Web界面，方便用户进行日志的查询、分析和可视化。
4、 阿里云日志服务（Log Service, 简称SLS）
简介：阿里云日志服务是针对日志类数据的一站式服务，支持日志数据采集、消费、投递以及查询分析等功能。
特点：实时采集与消费：通过LogHub功能实时接入各种日志数据。查询与实时分析：提供丰富的查询手段和数据可视化功能。投递数仓：支持将日志数据投递至存储类服务进行存储。

4. 总结日志分类, 优先级别。图文并茂解释应用如何将日志发到rsyslog,并写到目标。

一、日志分类
在Linux系统中，日志通常被分为以下几类：
1、内核及系统日志：
记录系统启动、关闭、硬件故障、驱动错误等核心系统事件。
常见的日志文件有/var/log/dmesg（记录系统启动过程中的硬件信息）、/var/log/messages（记录系统整体运行信息）等。
2、用户日志：
记录用户活动、登录、注销、认证等信息。
常见的日志文件有/var/log/auth.log（记录用户认证信息）、/var/log/secure（记录系统安全相关信息）、/var/log/wtmp（记录登录、注销等用户活动信息）、/var/log/btmp（记录登录失败的信息）等。
3、程序日志：
记录应用程序运行过程中产生的各种事件信息。
不同的应用程序可能会将日志信息保存在不同的位置，通常位于/var/log目录下的相应子目录中，如/var/log/apache2（Apache Web服务器的日志文件目录）、/var/log/mysql（MySQL数据库服务器的日志文件目录）等。

二、日志优先级别
日志优先级别用于表示日志消息的严重程度或重要性。以下是一种常见的日志优先级别分类（优先级从高到低）：
1、EMERG（紧急）：会导致主机系统不可用的情况，如系统崩溃。
2、ALERT（警告）：必须马上采取措施解决的问题，如数据库被破坏。
3、CRIT（严重）：比较严重的情况，如硬盘错误，可能会阻碍程序的部分功能。
4、ERR（错误）：运行出现错误，不是非常紧急，但需要尽快修复。
5、WARNING（提醒）：可能会影响系统功能的事件，不是错误，如磁盘使用了较高比例。
6、NOTICE（注意）：不会影响系统但值得注意的事件。
7、INFO（信息）：一般信息的日志，用于反馈系统的当前状态。
8、DEBUG（调试）：调试信息，用于开发过程中定位问题。
需要注意的是，不同的系统和应用程序可能会采用不同的日志优先级别分类标准。此外，日志优先级别通常与日志消息的格式和颜色编码相关联，以便于管理员快速识别问题的严重程度。
三、 将日志发到rsyslog
启用网络日志服务：
在rsyslog服务器上，需要启用网络日志服务，以便接收来自其他主机的日志。这通常通过修改rsyslog配置文件（如/etc/rsyslog.conf）来实现，添加或修改如下配置以启用UDP日志接收：

#在服务器端，开启UDP相关功能
vim /etc/rsyslog.confmodule(load="imudp")
input(type="imudp" port="514")

同样，如果需要启用TCP日志接收，可以添加或修改如下配置：

#在服务器端，开启TCP相关功能
vim /etc/rsyslog.confmodule(load="imtcp")
input(type="imtcp" port="514")

配置 client-1 主机日志远程转发：
在应用服务器上，需要配置应用将日志发送到rsyslog服务器。这通常通过修改应用的配置文件来实现。

#配置服务端
vim /etc/hosts
10.0.0.162 client-1
systemctl restart rsyslog    #重启服务
ss -tunlp | grep 514         #查看端口#配置客户端
hostnamectl set-hostname client-1vim /etc/hosts
#其它注释
127.0.0.1 client-1
::1 client-1#配置远程转发，转发到 10.0.0.161 的 udp 协议514端口,默认514 可以省略
vim /etc/rsyslog.d/net.conf
*.info  @10.0.0.161:514systemctl restart rsyslog

配置rsyslog写入目标：
在rsyslog服务器上，还需要配置rsyslog将接收到的日志写入到指定的文件中。这同样通过修改rsyslog配置文件（如/etc/rsyslog.conf或/etc/rsyslog.d/目录下的配置文件）来实现。
例如，可以添加如下配置来将info分类的所有日志写入到/var/log/syslog文件中：

#在服务器端，修改rsyslog服务配置
vim /etc/rsyslog.d/50-default.conf*.info     /var/log/syslog

测试日志发送与接收：
最后，可以在应用服务器上使用logger命令或触发应用生成日志来测试日志的发送与接收。例如，可以使用如下命令发送一条info级别的日志到rsyslog服务器:

#在客户端，发送消息
logger "this msg from client-1"

然后，在rsyslog服务器上使用tail -f /var/log/syslog命令查看是否接收到了该日志消息。

#在服务器端，查看消息

tail -f /var/log/syslog

5. 完成功能，将3个主机(要求主机名为ip)的ssh日志，通过rsyslog服务将ssh日志写入到集中的主机上的rsyslog服务，写入到/var/log/all-ssh.log文件

#在服务器启用相关模块, 去掉 UDP,TCP 模块的注释
vim /etc/rsyslog.confvim /etc/hosts
10.0.0.161 client-1
10.0.0.162 client-2systemctl restart rsyslog    #重启服务#配置客户端主机日志远程转发
hostnamectl set-hostname client-1
hostnamectl set-hostname client-2vim /etc/hosts
127.0.0.1 client-1
::1 client-1127.0.0.1 client-2
::1 client-2#配置远程转发，转发到 10.0.0.155 的 udp/tcp 协议514端口,默认514可以省略
vim /etc/rsyslog.d/net.conf
*.info        @10.0.0.155:514
*.info        @@10.0.0.155:514#服务器配置
vim /etc/rsyslog.d/50-default.conf
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/all-ssh.logsystemctl restart rsyslog / rsyslog.service    #重启服务#2台客户端和服务器分别发送消息
logger "this message from log-server"
logger "this message from client-1"
logger "this message from client-2"#测试结果
tail -l  /var/log/all-ssh.log

6. 总结/var/log/目录下常用日志文件作用。

    /var/log/ 目录下存放的是Linux系统日志文件，这些文件记录了系统运行过程中的各种事件和错误信息，对于系统管理员进行系统维护和故障排查至关重要。以下是一些常用日志文件及其作用的总结：

1. /var/log/messages
   作用：记录了系统的大部分重要事件和消息，包括内核消息、系统启动和关机信息、服务启动和停止信息等。它是系统管理员了解系统整体状况的重要窗口。

2. /var/log/syslog
   作用：记录了系统的各种系统级别的消息，包括进程启动、停止、错误和警告等。它提供了对系统活动的详细记录，有助于系统管理员进行问题追踪和性能分析。

3. /var/log/auth.log（或/var/log/secure）
   作用：记录了系统的身份验证和授权相关的信息，包括用户登录、su命令使用、sudo命令使用等。它对于追踪用户活动和确保系统安全至关重要。

4. /var/log/kern.log
   作用：记录了内核相关的消息和错误，包括硬件故障、驱动程序问题等。它有助于系统管理员在内核级别进行故障排查和性能优化。

5. /var/log/boot.log
   作用：记录了系统启动过程中的日志信息，包括硬件检测、服务启动等。它对于了解系统启动过程中的问题和优化启动性能非常有帮助。

6. /var/log/cron
   作用：记录了定时任务的执行情况，包括cron作业的执行时间、执行结果等。它有助于系统管理员监控和管理定时任务。

7. /var/log/maillog（或/var/log/mail.log）
   作用：记录了邮件服务器的日志信息，包括邮件的发送、接收、错误等。它对于邮件服务器的维护和故障排查非常重要。

8. /var/log/httpd/access_log（或/var/log/apache2/access.log）
   作用：记录了Apache HTTP服务器访问日志，包括客户端对网站的访问请求、访问时间、访问结果等。它对于Web服务器的流量分析、安全审计等非常重要。

9. /var/log/httpd/error_log（或/var/log/apache2/error.log）
   作用：记录了Apache HTTP服务器错误日志，包括服务器运行过程中遇到的错误和警告信息。它有助于系统管理员快速定位和解决Web服务器问题。

10. /var/log/dmesg
    作用：记录了系统启动过程中内核检测到的硬件设备信息。该文件的内容可以通过dmesg命令查看。它对于了解系统启动时的硬件状态非常重要。

    这些日志文件共同构成了Linux系统的日志体系，为系统管理员提供了宝贵的诊断信息和监控工具。通过合理配置和管理这些日志文件，可以确保系统的稳定性和安全性，提高系统的运行效率。
    

7. 总结journalctl命令的选项及示例

journalctl 是一个用于查询和控制 systemd 日志服务的命令行工具。它允许用户查看、过滤、搜索和导出系统日志。以下是一些常用的 journalctl 选项及其示例：

基本选项
查看所有日志

journalctl

查看当前引导会话的日志

journalctl -b

查看上一次引导会话的日志

journalctl -b -1

查看特定时间段的日志

journalctl --since "2023-10-01" --until "2023-10-02"

实时查看日志

journalctl -f

查看特定服务的日志

journalctl -u <service-name>

查看特定单元的日志查看特定进程的日志

journalctl _PID=<pid>

过滤和搜索选项

按优先级过滤日志

journalctl -p <priority>

按关键字搜索日志

journalctl | grep <keyword>journalctl -e <keyword>journalctl | grep failed

显示日志的完整条目

journalctl -o verbose

显示日志的 JSON 格式

journalctl -o json

显示日志的简短格式

journalctl -o short

显示日志的导出格式

journalctl -o export

导出和分页选项

将日志导出到文件

journalctl > output.logjournalctl | less

显示日志的摘要

journalctl --summary

特定单元和启动选项

查看特定引导会话的日志

journalctl -b <boot-id>

列出所有引导会话

journalctl --list-boots

查看特定用户的日志

journalctl _UID=<uid>journalctl _UID=1000journalctl -M <machine-name>

组合使用

你可以组合多个选项来更精确地查询日志。例如，查看上一次引导会话中特定服务的错误日志：

journalctl -b -1 -u nginx -p err..

8. 完成将多个主机（要求主机名为ip)的logger命令日志集中写入到mysql表中

9. 尝试使用logrotate服务切割message日志，每天切割一次，要求大于不超过3M, 保存90天的日志, 旧日志以时间为后缀，要求压缩。

10.apache请按照课程完成搭建和练习，本部分不是重点，不出题

11.总结http协议相关面试题，建议面试前背一背。参考链接: https://juejin.cn/post/7117533146454687757

叙述对HTTP 0.9、HTTP 1.0、HTTP 2.0、HTTP 3.0 四个版本的联系与区别
联系
基础目标一致：它们的核心目标都是为了实现客户端（如浏览器）与服务器之间的超文本传输，以支持网页等资源在网络上的交互获取，保障互联网应用能够正常展现和运行。
协议演进关系：后续版本都是在前一版本基础上，为了应对不断出现的新需求、解决旧版本存在的问题而逐步发展演变而来的，整体是一脉相承的技术迭代过程。

区别
HTTP 0.9（最早且极为简单的版本）
功能特性：
只支持 GET 请求方法，意味着客户端只能从服务器获取资源，无法进行像提交数据等更复杂操作。
传输的内容只有 HTML 格式的文本内容，功能非常单一。
没有请求头、响应头的概念，通信过程很简洁直接，发送请求获取页面内容后就结束交互。
应用场景及局限：在互联网发展早期，简单的静态网页浏览场景下能基本满足需求，但随着网页内容丰富、交互性增强等发展趋势，其功能匮乏的问题凸显，无法适应后续复杂应用。
HTTP 1.0
功能特性：
新增了多种请求方法，比如 POST、HEAD 等，POST 方法使得客户端可以向服务器提交数据，拓展了交互的维度。
引入了请求头和响应头，能够在其中携带诸如内容类型（如 text/html、image/jpeg 等）、编码格式、缓存控制等丰富的元信息，方便服务器和客户端更好地处理和展示内容、管理缓存等。
支持传输多种类型的文件，不再局限于 HTML 文本，像图片、CSS 样式文件等都能传输，促使网页变得更加美观、功能更丰富。
应用场景及局限：虽然相比 0.9 有了很大进步，但它每次请求都需要建立一个新的 TCP 连接，在加载包含多个资源（如图片众多的网页）时，频繁建立和断开连接会导致性能损耗，加载速度受限，对于复杂、资源繁多的页面响应效率不高。
HTTP 2.0
功能特性：
采用二进制格式进行数据传输，相较于 HTTP 1.0 的文本格式，解析效率更高，更利于计算机进行处理，同时也增强了传输的稳定性和安全性。
引入了多路复用技术，一个 TCP 连接里可以同时并发多个请求和响应，多个资源的请求不用排队等待，极大提高了传输效率，解决了 HTTP 1.0 中连接频繁创建销毁导致的性能瓶颈问题。
具备头部压缩功能，通过特定算法对请求头和响应头中重复出现的信息进行压缩，减少了网络传输的数据量，进一步提升传输效率。
支持服务器推送，服务器可以主动向客户端推送一些它认为客户端可能后续需要的资源，比如在客户端请求 HTML 页面时，服务器主动推送相关的 CSS、JavaScript 文件等，优化页面加载速度。
应用场景及局限：极大地提升了网页等应用的加载性能，尤其适用于如今复杂的、资源众多且交互频繁的网页应用和移动端应用，但在应对一些网络环境多变、丢包严重等复杂情况时，由于底层还是基于 TCP 协议，会面临一些诸如队首阻塞（一个流中的某个数据包丢失会阻塞后续所有流的处理）的问题。
HTTP 3.0
功能特性：
最大的改变是将底层传输协议从 TCP 换成了 QUIC（Quick UDP Internet Connections）协议，基于 UDP 实现，但又融合了 TCP 的可靠传输等特性，解决了 TCP 存在的队首阻塞问题，在丢包等复杂网络环境下也能有较好的传输表现，提升传输的灵活性和效率。
继承了 HTTP 2.0 的诸多优秀特性，如多路复用、头部压缩、服务器推送等，在保障高效利用网络资源、优化交互体验的同时，借助新的底层协议进一步增强了性能。
具备更好的连接迁移能力，比如当用户从一个网络切换到另一个网络（如从 WiFi 切换到移动数据）时，能够更平滑地保持连接，不影响正在进行的传输任务。
应用场景及局限：适用于对网络性能、连接稳定性要求极高的现代互联网应用场景，像高清视频流传输、实时互动的云游戏、大型在线协作办公等场景，但由于其较新，协议推广和在一些老旧网络设施兼容等方面还面临一定挑战，全面普及需要一定时间。
总体而言，HTTP 协议各版本的演进是为了不断适配互联网发展中日益增长的性能、功能需求，逐步走向更高效、更可靠、更智能的超文本传输解决方案。

介绍一下HTTP 协议通信过程和HTTP协议通信过程
HTTP（超文本传输协议）通信过程主要包括以下几个阶段：

一、建立连接

域名解析（可选）
当客户端（如浏览器）要访问一个网站时，通常使用域名来标识服务器。例如，访问 “www.example.com”。首先，客户端需要将域名解析为对应的 IP 地址。这一过程是通过 DNS（域名系统）服务器来完成的。客户端会向本地 DNS 服务器发送请求，本地 DNS 服务器如果没有缓存该域名对应的 IP 地址，会向上一级 DNS 服务器查询，直到找到权威 DNS 服务器获取到 IP 地址。
TCP 连接建立
客户端使用获取到的服务器 IP 地址，通过 TCP（传输控制协议）协议与服务器建立连接。这一过程涉及 TCP 的三次握手。
第一次握手：客户端向服务器发送一个带有 SYN（同步序列号）标志的 TCP 数据包，这个数据包中包含一个初始序列号（ISN），用于后续数据传输的排序和确认。例如，客户端发送一个 SYN = 1，ISN = x 的数据包。
第二次握手：服务器收到客户端的 SYN 数据包后，会发送一个 SYN/ACK（同步 / 确认）数据包作为回应。这个数据包中的 SYN 标志用于同步服务器的序列号，ACK 标志用于确认收到客户端的序列号。服务器的 SYN 标志对应的序列号设为 y，ACK 标志对应的确认号设为 x + 1，表示已经收到客户端的序列号并且期待下一个序列号是 x+1。例如，服务器发送 SYN = 1，ISN = y，ACK = x + 1 的数据包。
第三次握手：客户端收到服务器的 SYN/ACK 数据包后，会发送一个 ACK 数据包进行确认。这个数据包中的 ACK 标志对应的确认号设为 y + 1，表示已经收到服务器的序列号并且期待下一个序列号是 y + 1。例如，客户端发送 ACK = y + 1 的数据包。经过这三次握手，TCP 连接成功建立，双方可以开始传输数据。

二、客户端发送请求

构建请求报文
请求行：包含请求方法（如 GET、POST、PUT、DELETE 等）、请求的 URL（统一资源定位符）和 HTTP 协议版本（如 HTTP/1.1 或 HTTP/2.0）。例如，在一个简单的 GET 请求中，请求行可能是 “GET /index.html HTTP/1.1”，其中 “GET” 是请求方法，“/index.html” 是请求的资源路径，“HTTP/1.1” 是协议版本。
请求头：包含各种与请求相关的信息。比如 “Host” 字段，用于指定请求的目标主机域名，这在服务器托管多个域名时很重要；“User - Agent” 字段，用于告知服务器客户端的软件类型和版本，例如浏览器类型和版本号；“Accept” 字段，用于说明客户端能够接受的内容类型，如 “text/html,application/xhtml+xml,application/xml;q = 0.9,image/webp,image/apng,/;q = 0.8” 表示客户端可以接受多种格式的内容，并且对不同格式有不同的接受优先级（通过 q 值表示）；“Cookie” 字段，如果客户端之前与服务器建立过会话并且服务器设置了 Cookie，那么这个字段会包含相关的 Cookie 信息，用于服务器识别客户端的身份或状态。
请求体（部分请求方法需要）：对于 POST 等请求方法，需要在请求体中放置要发送的数据。例如，在提交一个表单时，请求体中可能包含表单字段的名称和值，如 “username = john&password = 1234”。
发送请求报文
客户端将构建好的请求报文通过已经建立好的 TCP 连接发送给服务器。

三、服务器处理请求

接收请求报文
服务器通过 TCP 连接接收客户端发送的请求报文。
解析请求报文
服务器解析请求行，确定请求方法和要访问的资源路径，同时了解请求的协议版本。
服务器解析请求头，获取各种相关信息，如客户端的身份、接受的内容类型等，这些信息将用于后续生成响应。
如果有请求体，服务器也会解析请求体，提取其中的数据，例如提取表单数据用于数据库插入等操作。
生成响应报文
响应行：包含 HTTP 协议版本、响应状态码和状态描述。例如，“HTTP/1.1 200 OK”，其中 “HTTP/1.1” 是协议版本，“200” 是状态码，表示请求成功，“OK” 是状态描述。常见的状态码还有 404（资源未找到）、500（服务器内部错误）等。
响应头：包含与响应相关的各种信息。例如，“Content - Type” 字段用于告知客户端返回内容的类型，如 “text/html” 表示返回的是 HTML 文档；“Content - Length” 字段用于告知客户端返回内容的长度，以便客户端准确接收；“Set - Cookie” 字段用于设置 Cookie，用于后续会话管理等。
响应体：包含实际要返回给客户端的内容，如请求的 HTML 页面、图片文件的二进制数据、API 返回的 JSON 数据等。
发送响应报文
服务器将生成好的响应报文通过 TCP 连接发送回客户端。

四、客户端接收并处理响应

接收响应报文
客户端通过 TCP 连接接收服务器发送的响应报文。
解析响应报文
客户端解析响应行，了解请求是否成功以及响应的状态码和状态描述。
客户端解析响应头，获取返回内容的类型、长度等信息。
客户端从响应体中提取实际内容，例如，如果是 HTML 文档，就可以进行渲染展示；如果是图片文件，就可以进行显示等。
关闭连接（可选）
在完成请求 - 响应交互后，客户端和服务器可以选择关闭 TCP 连接。不过，在 HTTP/1.1 及以后的版本中，支持持久连接，即可以保持连接用于后续的请求 - 响应，以减少连接建立和关闭的开销。如果选择关闭连接，会通过 TCP 的四次挥手来完成。
第一次挥手：主动关闭方（可以是客户端也可以是服务器）发送一个 FIN（结束）标志的 TCP 数据包，表示自己没有数据要发送了。
第二次挥手：另一方收到 FIN 数据包后，发送一个 ACK 数据包，表示已经收到 FIN 数据包。
第三次挥手：另一方（如果它也没有数据要发送了）发送一个 FIN 数据包，表示自己也没有数据要发送了。
第四次挥手：主动关闭方收到 FIN 数据包后，发送一个 ACK 数据包，表示已经收到 FIN 数据包，此时连接完全关闭。

HTTPS通信过程主要包括以下几个阶段：
建立 TCP 连接
与 HTTP 协议一样，通信的第一步是建立 TCP 连接。客户端（如浏览器）根据服务器的域名，通过 DNS（域名系统）解析获取服务器的 IP 地址。然后，客户端使用该 IP 地址与服务器进行 TCP 的三次握手来建立连接。
第一次握手：客户端向服务器发送一个带有 SYN（同步序列号）标志的 TCP 数据包，这个数据包包含一个初始序列号（ISN），用于后续数据传输的排序和确认。
第二次握手：服务器收到客户端的 SYN 数据包后，发送一个 SYN/ACK（同步 / 确认）数据包作为回应。这个数据包中的 SYN 标志用于同步服务器的序列号，ACK 标志用于确认收到客户端的序列号。
第三次握手：客户端收到服务器的 SYN/ACK 数据包后，发送一个 ACK 数据包进行确认，此时 TCP 连接成功建立。

SSL/TLS 协商阶段
客户端发起 SSL/TLS 握手请求（ClientHello）
客户端向服务器发送一个 “ClientHello” 消息。这个消息包含了很多重要信息，如客户端支持的 SSL/TLS 协议版本（例如 TLS 1.2、TLS 1.3 等），因为不同版本有不同的安全特性和加密算法；加密套件列表，加密套件是一组加密算法和密钥交换算法的组合，例如 RSA - AES - GCM 等，这是为了让服务器选择合适的加密方式；还有一个随机数（Client Random），这个随机数将用于后续生成会话密钥。
服务器响应（ServerHello）
服务器收到 “ClientHello” 消息后，会返回一个 “ServerHello” 消息。这个消息包含服务器选择的 SSL/TLS 协议版本，通常是从客户端支持的版本中选择一个双方都兼容的；加密套件，是从客户端提供的加密套件列表中挑选出来的；另一个随机数（Server Random）。同时，服务器会发送自己的数字证书，这个证书包含了服务器的公钥，用于身份验证。
客户端验证服务器证书
客户端收到服务器证书后，会对证书进行验证。首先检查证书是否是由可信任的证书颁发机构（CA）颁发的，客户端通常会预先安装一些受信任的 CA 根证书，通过这些根证书来验证服务器证书的颁发链是否合法。其次，检查证书是否过期，以及证书的域名与服务器的域名是否匹配。如果证书验证不通过，客户端通常会向用户显示警告信息，提示可能存在安全风险。如果证书验证通过，客户端就可以使用证书中的公钥进行后续操作。
密钥交换和生成会话密钥
根据协商好的加密套件，客户端和服务器会进行密钥交换操作。以 RSA 加密套件为例，客户端会生成一个随机的对称密钥（也称为预主密钥，Pre - Master Secret），这个对称密钥将用于后续数据加密。然后客户端使用服务器证书中的公钥对这个对称密钥进行加密，并发送给服务器。服务器收到后，使用自己的私钥解密得到对称密钥。在使用 Diffie - Hellman（DH）或其变种（如 ECDHE）加密套件时，双方会通过一系列复杂的数学运算来共同生成会话密钥。例如，在 ECDHE 中，客户端和服务器分别生成自己的临时椭圆曲线密钥对，然后交换公钥部分，通过结合自己的私钥和对方的公钥，利用椭圆曲线算法的特性，双方可以计算出相同的会话密钥。
完成 SSL/TLS 握手
客户端发送一个 “ChangeCipherSpec” 消息，表示之后的数据将使用协商好的会话密钥和加密套件进行加密。然后发送一个 “Finished” 消息，这个消息包含经过加密的握手消息的摘要，用于验证握手过程的完整性。服务器收到 “ChangeCipherSpec” 和 “Finished” 消息后，也会发送“ChangeCipherSpec” 和 “Finished” 消息。至此，SSL/TLS 握手完成，双方建立了一个安全的加密通道。

数据传输阶段
客户端发送请求
客户端构建 HTTP 请求报文，包括请求行、请求头和请求体（如果有）。与 HTTP 不同的是，这些请求报文会使用协商好的会话密钥和加密算法进行加密，然后通过加密通道发送给服务器。
服务器处理请求
服务器收到加密的请求报文后，使用会话密钥进行解密，然后按照 HTTP 协议的方式处理请求。即解析请求报文，生成响应报文。
服务器发送响应
服务器将生成的响应报文使用会话密钥进行加密，然后通过加密通道发送回客户端。
客户端接收并处理响应
客户端收到加密的响应报文后，使用会话密钥进行解密，然后按照 HTTP 协议的方式解析响应报文，提取内容并进行相应处理。
关闭连接（可选）
在完成请求 - 响应交互后，客户端和服务器可以选择关闭 TCP 连接和 SSL/TLS 会话。关闭过程和 HTTP 类似，也是通过 TCP 的四次挥手来完成，同时 SSL/TLS 会话相关的资源也会被释放。

​介绍一下请求报文和响应报文的结构，以及响应报文的响应码的含义
请求报文结构
请求行
这是请求报文的起始部分，包含三个关键元素：请求方法、请求 URL 和 HTTP 协议版本。
请求方法：定义了客户端对服务器资源的操作类型。常见的有：
GET：用于从服务器获取资源，例如获取网页、图片、文档等。它是幂等的，多次请求相同的 URL 应该返回相同的结果。
POST：用于向服务器提交数据，比如提交表单数据（用户注册、登录、发表评论等场景）。POST 请求的数据通常包含在请求体中，且它不是幂等的。
PUT：用于更新服务器上指定资源的全部内容，会用请求体中的数据替换服务器上对应的资源。
DELETE：用于请求服务器删除指定的资源。
请求 URL：指明客户端想要访问的服务器资源的位置，例如 “/index.html” 表示服务器根目录下的 index.html 文件。它也可以包含查询参数，如 “/search?q=keyword”，其中 “q=keyword” 就是查询参数，用于向服务器传递搜索关键词等信息。
HTTP 协议版本：如 “HTTP/1.1” 或 “HTTP/2.0”，表明请求所遵循的 HTTP 协议版本。
请求头
由一系列键值对组成，用于向服务器传递额外的请求信息。例如：
Host：指定请求的目标主机域名，在服务器托管多个域名时，用于明确请求的具体目标，如 “Host: www.example.com”。
User - Agent：告知服务器客户端的软件信息，包括软件类型和版本。例如浏览器类型和版本号，像 “User - Agent: Mozilla/5.0 (Windows NT 10.0; Win64;x64) AppleWebKit/7600.14 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36”。
Accept：表示客户端能够接受的内容类型，格式为类型 / 子类型的列表，也可以包含优先级（q 值）。例如 “Accept: text/html,application/xhtml + xml,application/xml;q = 0.9,image/webp,image/apng,/;q = 0.8”，这表明客户端最希望接收 text/html 类型的内容。
Accept - Language：用于指定客户端接受的语言，例如 “Accept - Language: en - US,en;q = 0.9”，表示客户端最希望接收美式英语内容。
Accept - Encoding：表示客户端能够接受的内容编码方式，如 gzip、deflate 等，用于压缩传输内容，例如 “Accept - Encoding: gzip,deflate”。
Cookie：如果客户端之前与服务器有交互并且服务器设置了 Cookie，这个字段会包含相关的 Cookie 信息，用于服务器识别客户端的身份或状态。
请求体（可选）
不是所有请求都有请求体。GET 请求通常没有请求体，因为它主要是获取资源。而 POST、PUT 等请求通常有请求体，用于包含要发送的数据。例如，在 POST 请求提交表单时，请求体可能包含 “username = john&password = 1234” 这样的表单字段值。请求体的内容类型由请求头中的 “Content - Type” 字段指定。

响应报文结构
响应行
位于响应报文的开头，包含三个部分：HTTP 协议版本、响应状态码和状态描述。
HTTP 协议版本：与请求报文中的协议版本相对应，如 “HTTP/1.1” 或 “HTTP/2.0”。
响应状态码：是一个三位数字的代码，用于告知客户端请求的处理结果。
状态描述：是对响应状态码的简单文字解释，如 “OK”（对应状态码 200）、“Not Found”（对应状态码 404），方便用户理解响应状态。
响应头
也是一系列键值对，用于向客户端传递有关响应的信息。例如：
Content - Type：告知客户端返回内容的类型，格式为类型 / 子类型，如 “Content - Type: text/html” 表示返回的是 HTML 文档，“Content - Type: image/jpeg” 表示返回的是 JPEG 格式的图片。
Content - Length：告知客户端返回内容的长度（字节数），例如 “Content - Length: 1234”，方便客户端准确接收内容。
Set - Cookie：用于设置 Cookie，将信息存储在客户端，用于后续会话管理，例如 “Set - Cookie: sessionid = 12345;expires = Fri, 31 - Dec - 2024 23:59:59 GMT;path = /”。
Cache - Control：用于控制客户端的缓存行为，如 “Cache - Control: max - age = 3600” 表示客户端可以缓存内容 3600 秒。
Content - Encoding：如果返回的内容经过编码（如 gzip 压缩），这个字段会告知客户端内容的编码方式，例如 “Content - Encoding: gzip”。
响应体
包含服务器实际要返回给客户端的具体内容，如请求的 HTML 页面、图片文件的二进制数据、API 返回的 JSON 数据等。

响应码的含义
1xx（信息性）
这类状态码主要用于提供信息，在 HTTP/1.1 协议中用于中间状态通信，不太常见。例如：
100（Continue）：客户端发送带有请求体的请求（如 POST）时，先发送请求头，服务器返回 100 表示可以继续发送请求体。
2xx（成功）
200（OK）：最常见的成功状态码，表示服务器成功处理请求并返回请求的内容。例如，客户端请求一个网页，服务器找到并返回网页的 HTML 内容时返回此码。
201（Created）：表示请求成功且在服务器上创建了新的资源。通常在 POST 或 PUT 请求后返回，比如用户成功注册新账号，服务器创建新用户记录后可能返回此码。
204（No Content）：服务器成功处理请求，但没有返回内容。比如客户端请求删除资源，服务器成功删除后返回此码，因为不需要返回数据。
3xx（重定向）
301（Moved Permanently）：请求的资源已永久移动到新 URL，客户端应使用新 URL 进行后续访问。例如网站域名更换，旧域名资源迁移到新域名，访问旧域名时服务器返回此码并在响应头提供新 URL。
302（Found）：请求的资源临时移动到新 URL，客户端应使用新 URL 访问。与 301 不同的是它是临时重定向。
304（Not Modified）：用于缓存控制。如果客户端发送缓存相关请求头（如 If - Modified - Since），服务器判断客户端缓存内容有效，就返回此码，告知客户端可以使用缓存内容，无需重新发送实际内容。
4xx（客户端错误）
400（Bad Request）：客户端发送的请求有语法错误或请求参数不符合要求，如请求 URL 格式错误或请求头字段值不符合预期。
401（Unauthorized）：请求的资源需要授权，但客户端未提供有效授权信息（如用户名和密码）或授权信息无效。
403（Forbidden）：客户端有授权信息，但仍被禁止访问请求的资源，可能是权限不够或资源有访问限制。
404（Not Found）：非常常见，客户端请求的资源在服务器上不存在，如请求不存在的网页或图片文件时返回此码。
5xx（服务器错误）
500（Internal Server Error）：服务器在处理请求时发生内部错误，通常是服务器端代码问题，如程序崩溃、数据库查询出错等。
502（Bad Gateway）：一般是代理服务器或网关服务器出现的错误。当代理服务器无法从后端服务器获取有效响应时返回此码，可能是后端服务器故障或网络问题。
503（Service Unavailable）：服务器暂时无法处理请求，通常是因为服务器过载、维护或其他临时故障。例如服务器升级维护时收到请求会返回此码。
504（Gateway Time - out）是一种服务器返回的 HTTP 状态码，表示网关或者代理服务器在尝试从上游服务器获取响应时，没有在规定的时间内得到响应，出现了超时情况。

12.总结NAS的部署和安装过程

13.使用inotify + rsync和sersync实现文件的同步，并且总结两种方式的优缺点

endl