1.免费证书DNS验证说明
申请免费证书，需要进行DNS验证，验证方式有三种，一种为自动DNS验证，当然这种方式需要客户主域名接入解析到DNSpod下，并且重要的点需要关注：用作解析的ns服务器不能指定为其他云产商的，若指定了，要么删除，要么去到做解析的云产商DNS解析记录里面手动添加TXT记录验证。总结为域名在哪解析，就需要在哪进行TXT记录验证，只是区分是自己手动添加TXT记录还是云产商自动添加。另一种为手动DNS验证，此种方式通用，适合主域名解析的云产商也适用于其他云产商，根据申请时，提供的TXT记录值到对应的云产商解析即可。第三种为DNS文件验证方式，这种方式需要往自己的站点目录下添加用于验证的文本，比较麻烦，不推荐。
2.kdump服务配置过程及说明
以centos7为例：
#安装kexec-tools
yum install kexec-tools
#设置crashkernel预留内存大小
vim /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="<span style="color:#ff0000;">crashkernel=256M</span> rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
注：修改crashkernel的大小，我的系统内存是1G，保留了256M，注意预留内存大小，过小会导致生成coredump文件失败。根据官网推荐值配置和内存大小有关https://access.redhat.com/solutions/59432
#修改后还需重新生成grub配置文件，重启系统才能生效
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
此处必须要重启系统才能是预留内存配置生效
#修改kdump默认配置/etc/kdump.conf
vim /etc/kdump.conf
-指定coredump文件存储位置
path /var/crash
-增加-c参数，代表压缩coredump文件
core_collector makedumpfile -c -l --message-level 1 -d 31
-生成coredump后，重启系统，
default reboot
#开启kdump服务
systemctl start kdump.service //启动kdump
systemctl enable kdump.service //设置开机启动
systemctl status kdump.service //检查服务状态
#手动触发kdump测试
echo 1 > /proc/sys/kernel/sysrq ; echo c > /proc/sysrq-trigger
若正常，则会在/var/crash下生成vmcore文件ls /var/crash/
#安装crash命令，分析coredump文件
yum install crash
crash /var/crash/127.0.0.1-2020-10-9-16:25:11/vmcore /usr/src/kernels/linux-`uname -r`/vmlinux
3.mysql替代outfile导出为csv格式命令
mysql -uroot -p -hlocalhost -P3306 -e "select * from test.rtt" |sed -nr 's#^(.*) (.*) (.*)$#"1","2","3"#gp'>test.csv
mysql -uroot -p -h10.66.x.x -P3306 -e "select * from rossy.nsd" | sed 's/ /","/g;s/^/"/;s/$/"/;s/
//g' >nsd.csv
mysql -uroot -p -hlocalhost -P3306 -e "select * from test.rtt"|awk '{printf ""%s","%s","%s"
",$1,$2,$3}'>tty.csv
4.URL中的特殊符号说明
URL特殊字符需转义
1、空格换成加号(+)
2、正斜杠(/)分隔目录和子目录
3、问号(?)分隔URL和查询
4、百分号(%)制定特殊字符
5、#号指定书签
6、&号分隔参数
5./proc/buddyinfo的理解
/proc/buddyinfo是Linuxbuddy系统管理物理内存的debug信息
在Linux中使用buddy算法解决物理内存的有效利用问题，其把所有空闲的内存，以2的幂次方的形式，分成11个块链表，分别对应1,2,4,8,16,32,64,128,256,512,1024个页块。
Linux支持numa技术，对于numa设备，numa系统的节点通常是由一组cpu和本地内存组成，每个节点都有对应的本地内存，因此buddyinfo中的node0表示节点ID；而每一个节点下的内存设备，由可以划分为多个内存区域。因此下面的显示中，对于Node0的内存，又划分类DMA、Normal、HighMem区域。而后面则是表示空闲的区域。
此处以Normal区域进行分析，第二列值为100，表示当前系统中normal区域，可用的连续两页的内存大小为100*2*PAGE_SIZE；第三列值为52，表示当前系统中normal区域，可用的连续四页的内存大小为52*2^2*PAGE_SIZE
cat /proc/buddyinfo
Node 0, zone DMA 23 15 4 5 2 3 3 2 3 1 0
Node 0, zone Normal 149 100 52 33 23 5 32 8 12 2 59
Node 0, zone HighMem 11 21 23 49 29 15 8 16 12 2 142
6.Linux内核内存管理算法buddy和slab
https://www.sohu.com/a/282749474_467784
7.Nginx的健康检查机制
---------------------------------------------------
nginx原生的健康检测主要涉及两个模块:ngx_http_proxy_module和ngx_http_upstream_module
一、ngx_http_upstream_module模块
upstream backend {
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
}
1.max_fails
设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。在下一个fail_timeout时间段，服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数，认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream来配置什么是失败的尝试。 默认配置时，http_404状态不被认为是失败的尝试。
2.fail_timeout
设定服务器被认为不可用的时间段以及统计失败尝试次数的时间段。在这段时间中，服务器失败次数达到指定的尝试次数，服务器就被认为不可用。默认情况下，该超时时间是10秒。
二、ngx_http_proxy_module模块
1.proxy_connect_timeout
与后端服务器建立连接的超时时间
2.proxy_read_timeout
定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭
3.proxy_next_upstream
指定在何种情况下一个失败的请求应该被发送到下一台后端服务器
需要理解一点的是，只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。
三、原生nginx的健康检测存在的问题
1.节点异常：如果后端节点异常，nginx依然会先把该请求转发给该异常节点，然后再转发给别的节点，这样就会浪费一次转发。当尝试max_fails次失败后才会将其设置为异常节点。
2.无法精确判断异常节点是否恢复：判断为异常的节点，在fail_timeout时间后，nginx直接使用线上流量去请求异常节点，而不是先探测是否恢复，在导入线上流量
四、使用第三方健康检测模块nginx_upstream_check_module，可以很好的解决上述问题。
在编译了nginx_upstream_check_module模块后，可以在upstream中定义。
check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp]
- interval：向后端发送的健康检查包的间隔。
- fall(fall_count): 如果连续失败次数达到fall_count，服务器就被认为是down。
- rise(rise_count): 如果连续成功次数达到rise_count，服务器就被认为是up。
- timeout: 后端健康请求的超时时间。
- default_down: 设定初始时服务器的状态，如果是true，就说明默认是down的，如果是false，就是up的。默认值是true，也就是一开始服务器认为是不可用，要等健康检查包达到一定成功次数以后才会被认为是健康的。
- type：健康检查包的类型，现在支持以下多种类型
- tcp：简单的tcp连接，如果连接成功，就说明后端正常。
- ssl_hello：发送一个初始的SSL hello包并接受服务器的SSL hello包。
- http：发送HTTP请求，通过后端的回复包的状态来判断后端是否存活。
- mysql: 向mysql服务器连接，通过接收服务器的greeting包来判断后端是否存活。
- ajp：向后端发送AJP协议的Cping包，通过接收Cpong包来判断后端是否存活。
- port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口，比如后端提供的是443端口的应用，你可以去检查80端口的状态来判断后端健康状况。默认是0，表示跟后端server提供真实服务的端口一样。
---------------------------------------------------
8.nice设置进程优先级
优先级从-20 - 19,数字越大优先级越低.
$ nice –n 5 ~/bin/longtask //把优先级降低(提高谦让度)5
$ sudo renice -5 8829 //把谦让值设为-5
$ sudo renice 5 –u boggs //把boggs的进程的谦让值设为5
9.Linux下删除空行的办法
方法一：利用grep
grep -v '^s*$' test.txt
注：-v表示将匹配的结果进行反转，正则表达式匹配空行。（空行可包括空格符制表符等空白字符）
方法二：利用sed
sed '/^s*$/d' test.txt
注：d代表删除该行
方法三：利用awk
awk NF test.txt
注：NF代表当前行的字段数，空行的话字段数为0,被awk解释为假，因此不进行输出。
方法四：若空行均由’
'造成，则还可以利用tr命令去除空行
tr -s '
' < test.txt
注：-s代表将多个连续的字符压缩成一个字符，这里是将多个‘
'压缩成一个'
'，达到去除空行的效果。
方法四的缺陷:如果首行就出现空行的话则无法去除首行的空行
10./proc/sysrq-trigger功能
# 立即重新启动计算机 （Reboots the kernel without first unmounting file systems or syncing disks attached to the system）
echo "b" > /proc/sysrq-trigger
# 立即关闭计算机（shuts off the system）
echo "o" > /proc/sysrq-trigger
# 导出内存分配的信息 （可以用/var/log/message 查看）（Outputs memory statistics to the console）
echo "m" > /proc/sysrq-trigger
# 导出当前CPU寄存器信息和标志位的信息（Outputs all flags and registers to the console）
echo "p" > /proc/sysrq-trigger
# 导出线程状态信息 （Outputs a list of processes to the console）
echo "t" > /proc/sysrq-trigger
# 故意让系统崩溃 （ Crashes the system without first unmounting file systems or syncing disks attached to the system）
echo "c" > /proc/sysrq-trigger
# 立即重新挂载所有的文件系统 （Attempts to sync disks attached to the system）
echo "s" > /proc/sysrq-trigger
# 立即重新挂载所有的文件系统为只读 （Attempts to unmount and remount all file systems as read-only）
echo "u" > /proc/sysrq-trigger
e — Kills all processes except init using SIGTERM
i — Kills all processes except init using SIGKILL
11.Linux系统上的/proc目录是一种文件系统，即proc文件系统。
https://www.cnblogs.com/lidabo/p/5628020.html
12.长连接保活，Keep-Alive与心跳保活技术
发展史：短连接--->并行连接--->长连接
(1) 为何需要长连接保活
上一节的分析可以看到，对于客户端而言，使用TCP长连接来实现业务的好处在于：在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了DNS解析，连接建立，TCP慢启动等时间，大大加快了请求的速度，同时也有利于接收服务器的实时消息。
在使用TCP长连接的业务场景下，保持长连接的可用性非常重要。如果长连接无法很好地保持，在连接已经失效的情况下继续发送请求会导致迟迟收不到响应直到超时，又需要一次连接建立的过程，其效率甚至还不如直接使用短连接。而连接保持的前提必然是检测连接的可用性，并在连接不可用时主动放弃当前连接并建立新的连接。
(2) 心跳保活
App实现长连接保活的方式通常是采用应用层心跳，通过心跳包的超时和其他条件(网络切换)来执行重连操作。心跳一般是指某端(绝大多数情况下是客户端)每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。
(3) Keep-Alive可否实现保活？
a.HTTP中的Keep-Alive
实现HTTP/1.0 keep-alive连接的客户端可以通过包含Connection:Keep-Alive首部请求将一条连接保持在打开状态，如果服务器愿意为下一条请求将连接保持在打开状态，就在响应中包含相同的首部。如果响应中没有Connection: Keep-Alive首部，客户端就认为服务器不支持keep-alive，会在发回响应报文之后关闭连接。HTTP/1.1以后Keep-Alive是默认打开的。
c.TCP中的Keep-Alive
TCP协议的实现中，提供了KeepAlive报文，用来探测连接的对端是否存活。在应用交互的过程中，可能存在以下几种情况：
客户端或服务器意外断电，死机，崩溃，重启；
中间网络已经中断，而客户端与服务器并不知道；
利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。
虽然TCP提供了KeepAlive机制，但是并不能替代应用层心跳保活。原因主要如下：
(1) Keep Alive机制开启后，TCP层将在定时时间到后发送相应的KeepAlive探针以确定连接可用性。默认时间为7200s(两小时)，失败后重试10次，每次超时时间75s。显然默认值无法满足移动网络下的需求；
(2) 即便修改了(1)中的默认值，也不能很好的满足业务需求。TCP的KeepAlive用于检测连接的死活而不能检测通讯双方的存活状态。比如某台服务器因为某些原因导致负载超高，无法响应任何业务请求，但是使用TCP探针则仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态，对客户端而言，这时的最好选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态，一直向当前服务器发送些必然会失败的请求。
(3) socks代理会让Keep Alive失效。socks协议只管转发TCP层具体的数据包，而不会转发TCP协议内的实现细节的包。所以，一个应用如果使用了socks代理，那么TCP的KeepAlive机制就失效了。
(4) 部分复杂情况下Keep Alive会失效，如路由器挂掉，网线直接被拔除等；
因此，KeepAlive并不适用于检测双方存活的场景，这种场景还得依赖于应用层的心跳。应用层心跳也具备着更大的灵活性，可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。
(4) 影响心跳频率的关键因素
通过上一节的分析可以看到应用层心跳是检测连接有效性以及判断双方是否存活的有效方式。但是心跳过于频繁会带来耗电和耗流量的弊病，心跳频率过低则会影响连接检测的实时性。业内关于心跳时间的设置和优化，主要基于如下几个因素：
1.NAT超时--大部分移动无线网络运营商在链路一段时间没有数据通讯时，会淘汰 NAT表中的对应项，造成链路中断；
2.DHCP租期--DHCP租期到了需要主动续约，否则会继续使用过期IP导致长连接偶然的断连；
3.网络状态变化--手机网络和WIFI网络切换、网络断开和连上等情况有网络状态的变化，也会使长连接变为无效连接；
网络状态变化导致长连接变为无效连接的原因很容易理解。但是NAT超时和DHCP租期的问题对长连接保活存在的影响就涉及到网络协议底层的细节了。
13.长连接保活机制
方法1：应用层自己实现的心跳包
由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。
方法2：TCP的KeepAlive保活机制
因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功 能，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。并且，默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启KeepAlive功能并设置合理的KeepAlive参数。
心跳包机制
跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。
在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。
心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。
其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。
在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。
总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。
心跳检测步骤：
1客户端每隔一个时间间隔发生一个探测包给服务器
2客户端发包时启动一个超时定时器
3服务器端接收到检测包，应该回应一个包
4如果客户机收到服务器的应答包，则说明服务器正常，删除超时定时器
5如果客户端的超时定时器超时，依然没有收到应答包，则说明服务器挂了
14.wireshake info字段解释
SLE、SRE：https://blog.csdn.net/u013636377/article/details/70243621
RST、PSH：https://blog.csdn.net/qq_19307133/article/details/89289703
MSS、MTU：https://blog.csdn.net/chiyuwei1766/article/details/50762894
WIN、WS、SACK_PERM：https://www.cnblogs.com/dplearning/p/4819627.html
15.ssl握手过程
SSL握手过程
第一阶段clienthello:在clienthello过程,客户端主要完成以下几个操作;
向服务器发送自己支持的协议版本,比如TLS1.2
客户端生成的一个随机数,稍后用于生成一个会话密钥
发送自己支持的各种加密算法,比如AES(对称加密算法),RSA(公钥加密算法)…
发送自己支持的压缩算法
第二阶段:serverhello:服务器端在收到客户端的请求之后要向客户端发出回应;回应主要有以下内容;
确认使用的加密通信协议版本,比如TLS1.2
服务器端生成一个随机数,稍后用于生成”会话密钥”
确认使用的加密方法
服务器证书
第三阶段:客户端收到服务器端的serverhello以后给出的回应;
验证服务器证书;在确认无误后取出其公钥;(发证机构,证书签名,证书完整性,证书持有者,证书有效期,吊销列表)
发送以下信息给服务器端
一个随机数:用于服务器公钥加密
编码变更通知:表示通信双方都用商定好的密钥进行通信;即随后的信息都将用双方商定好的加密方法和密钥发送.
客户端握手结束通知:
第四阶段:收到客户端发来的第三个随机数pre-master-key后,计算生成本次会话所有用到的”会话密钥”;向客户端发送如下信息;
编码变更通知:表示通信双方都用商定好的密钥进行通信;即随后的信息都将用双方商定好的加密方法和密钥发送.
服务器端握手结束通知
16.远程桌面登录排查流程
-1.判断主机是否存在异常情况，比如cpu、内存、磁盘等异常增高或者报错等
-2.ping客户机网络，确定网络没问题，telnet对应端口，确认端口没问题
-3.上机和控制台，确认防火墙和安全组是否存在拦截情况
-4.执行以下命令，确认远程桌面服务运行是否正常
netstat -ant | findstr 3389
-5.检查远程桌面端口是否被修改
需查看2个注册表键值，开始—运行--regedit
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWds
dpwdTds cp PortNumber
HKEY_LOCAL_MACHINESYSTEMCurrentContro1SetControlTenninal ServerWinStationsRDP-Tcp PortNumer
-6.检查远程桌面服务是否异常
开始—运行—services.msc
查找 Remote Desktop Services，尝试重启服务