小知识记录：第六篇

1.jmeter压测工具
https://www.cnblogs.com/pwj2lgx/p/10283864.html
https://www.cnblogs.com/pwj2lgx/archive/2004/01/13/10282895.html

2.mysql查看时区和更改时区
show variables like '%time_zone%';
set time_zone = '+8:00'; #设置当前会话生效
set global time_zone = '+8:00'; flush privileges; #修改全局的时区配置
# vim /etc/my.cnf ##在[mysqld]区域中加上
default-time_zone = '+8:00'
# /etc/init.d/mysqld restart ##重启mysql使新时区生效

3.gdisk在线扩容
#不同文件系统扩容的方式
对于 EXT 文件系统：resize2fs /dev/vdb
对于 XFS 文件系统：xfs_growfs /dev/vdb
#扩容示例
安装：yum install -y gdisk
查看磁盘GUID：partx /dev/vdb 或者 gdisk /dev/vdb 输入i
sgdisk -d 1 -n 1:2048:0 -c 1: -u 1:27818343-797F-4BF5-915E-AD338312AA30 -t 1:0700 /dev/vdb
以上命令的解释：-d 表示删除编号为1的分区；-n表示新建分区，从2048扇区磁柱开始到最后；-c 表示重命名分区；-u表示磁盘GUID号1为分区号；-t 表示更改磁盘属性，1表示分区号，0700表示为微软基础数据格式，这个编号可以gdisk /dev/vdb按照创建分区步骤，执行到Hex code or GUID时，执行L获得。
重新加载分区信息：partx -u /dev/vdb
扩容分区：resize2fs /dev/vdb1 #old blocks数据和new block数据不一致表示成功
查看扩容结果：lsblk

4.growpart工具扩容
#系统盘扩容
以CentOS 6.5 64bit 50GB系统盘为例，root分区在最末尾分区(e.g: /dev/xvda1: swap,/dev/xvda2: root)的扩容场景。
>执行以下命令，查询当前弹性云服务器的分区情况。
parted -l /dev/xvda
>执行以下命令，获取文件系统类型、UUID。
blkid
>执行以下命令，安装growpart工具。
工具growpart可能集成在cloud-utils-growpart/cloud-utils/cloud-initramfs-tools/cloud-init包里，可以直接执行命令yum install cloud-*确保growpart命令可用即可。
yum install cloud-utils-growpart
>执行以下命令，使用工具growpart将第二分区的根分区进行扩容。
growpart /dev/xvda 2
>执行以下命令，检查在线扩容是否成功。
parted -l /dev/xvda
>执行以下命令，扩容文件系统。
resize2fs -f $分区名
resize2fs -f /dev/xvda2
#数据盘扩容分区和文件系统
这里区分内核版本高于3.6.0还是低于3.6.0
uname -r 查看内核版本
--内核版本高于3.6.0
>（可选）执行以下命令，安装growpart扩容工具。
yum install cloud-utils-growpart
说明：
可以用growpart命令检查当前系统是否已安装growpart扩容工具，若回显为工具使用介绍，则表示已安装，无需重复安装。
>执行以下命令，查看系统盘“/dev/vda”的总容量。
fdisk -l
>执行以下命令，查看系统盘分区“/dev/vda1”的容量。
df -TH
>执行以下命令，指定系统盘待扩容的分区，通过growpart进行扩容。
growpart 系统盘 分区编号
命令示例：
growpart /dev/vda 1
>执行以下命令，扩展磁盘分区文件系统的大小。
resize2fs 磁盘分区
命令示例：
resize2fs /dev/vda1
>执行以下命令，查看扩容后系统盘分区“/dev/vda1”的容量。
df -TH
--内核版本低于3.6.0
须知：
当操作系统内核低于3.6.0时，扩大已有MBR分区需要reboot重启，扩展分区和文件系统才会生效，会中断业务。
>（可选）执行以下命令，安装growpart扩容工具。
yum install cloud-utils-growpart
说明：
可以用growpart命令检查当前系统是否已安装growpart扩容工具，若回显为工具使用介绍，则表示已安装，无需重复安装。
>执行以下命令，安装dracut-modules-growroot工具。
yum install cloud-utils-growpart
>执行以下命令，重新生成initramfs文件。
dracut -f
>执行以下命令，查看系统盘“/dev/vda”的总容量。
fdisk -l
>执行以下命令，查看系统盘分区“/dev/vda1”的容量。
df -TH
>执行以下命令，指定系统盘待扩容的分区，通过growpart进行扩容。
growpart 系统盘 分区编号
命令示例：
growpart /dev/vda 1
>执行以下命令，重启云服务器。
reboot
待重启完成后，重新连接云服务器后，执行以下操作。
>执行以下命令，扩展磁盘分区文件系统的大小。
resize2fs 磁盘分区
命令示例：
resize2fs /dev/vda1
>执行以下命令，查看扩容后系统盘分区“/dev/vda1”的容量。
df -TH

5.关于rpcbind漏洞的问题
【风险详情】
RPCBind（也称Portmapper、portmap或RPCPortmapper）是一种通用的RPC端口映射功能，默认绑定在端口111上，可以将RPC服务号映射到网络端口号。它的工作原理是当RPC服务启动时，它会告诉RPCBind它正在监听的地址，以及它准备服务的RPC服务号；当客户端希望对给定的服务号进行RPC调用时，客户端首先需要联系服务器上的RPCBind，以确定应该在哪里发送RPC请求的地址。利用RPCBind进行UDP反射DDoS攻击的事件相对较少，这也是腾讯云安全今年以来捕获的首例利用云主机上的RPCBind服务进行UDP反射DDoS攻击的行为。不过其实早在2015年Level 3 Threat Research Labs就发现了这样一种新的攻击DDoS放大攻击形式，该反射方式放大系数最高可达28.4，US-CERT也在当时将该种攻击方式加入了UDP 攻击类型列表，具体可见https://www.us-cert.gov/ncas/alerts/TA14-017A 。
部分用户在云主机上启动RPCBind服务，服务绑定在默认TCP或UDP端口111，同时开放在外网，黑客通过批量扫描开放的111 UCP端口的服务器，利用UDP反射放大DDoS攻击原理发送虚假UDP请求，伪造源IP地址，将请求包中的源IP地址替换成攻击目标，反射服务器收到请求包发送响应来完成整个攻击流程。由于发送的请求包远小于响应，所以最终达到了反射放大的效果。
【修复建议】
服务被恶意利用的主要原因是RPCBind服务绑定在默认端口并开放在外网从而导致黑客可以访问并发送伪造的请求，腾讯云安全中心建议：
1、【直接关闭RPCBind服务】： 如果业务中并没有使用RPCBind服务，建议直接关闭，操作如下：
Ubuntu系统：
1）打开终端，运行如下命令，关闭rpcbind服务：
sudo systemctl stop rpcbind.socket && sudo systemctl disable rpcbind.socket
2）检查rpcbind服务是否关闭：
netstat -anp |grep rpcbind

CentOS系统：
1）打开终端，运行如下命令：
systemctl stop rpcbind.socket && systemctl disable rpcbind.socket
2）检查rpcbind服务是否关闭：
netstat -anp |grep rpcbind
2、【通过安全组进行限制RPC服务访问源IP或绑定内网IP】：如果因业务需要必须使用RPCBind服务，建议通过安全组/防火墙等方式进行访问限制或者将其绑定在内网IP，不要开放在外网，操作如下：
安全组配置如下：
1、打开控制台安全组配置界面：https://console.cloud.tencent.com/cvm/securitygroup，添加入站请求规则
2、检查规则是否生效。
注：可以查看源文档https://bbs.qcloud.com/thread-55034-1-1.html，这种安全报告模板不错

6.STP协议
TP（Spanning Tree Protocol）是生成树协议的英文缩写，可应用于计算机网络中树形拓扑结构建立，主要作用是防止网桥网络中的冗余链路形成环路工作
STP的基本原理是，通过在交换机之间传递一种特殊的协议报文，网桥协议数据单元（Bridge Protocol Data Unit，简称BPDU），来确定网络的拓扑结构。BPDU有两种，配置BPDU（Configuration BPDU）和TCN BPDU。前者是用于计算无环的生成树的，后者则是用于在二层网络拓扑发生变化时产生用来缩短MAC表项的刷新时间的（由默认的300s缩短为15s）。
Spanning Tree Protocol（STP）是在IEEE 802.1D 文档中定义，该协议的原理是按照树的结构来构造网络拓扑，消除网络中的环路，避免由于环路的存在而造成广播风暴问题。
Spanning Tree Protocol（STP）的基本思想就是按照"树"的结构构造网络的拓扑结构，树的根是一个称为根桥的桥设备，根桥的确立是由交换机或网桥的BID（Bridge ID）确定的，BID最小的设备成为二层网络中的根桥。BID又是由网桥优先级和MAC地址构成，不同厂商的设备的网桥优先级的字节个数可能不同。由根桥开始，逐级形成一棵树，根桥定时发送配置BPDU，非根桥接收配置BPDU，刷新最佳BPDU并转发。这里的最佳BPDU指的是当前根桥所发送的BPDU。如果接收到了下级BPDU（新接入的设备会发送BPDU，但该设备的BID比当前根桥大），接收到该下级BPDU的设备将会向新接入的设备发送自己存储的最佳BPDU，以告知其当前网络中根桥；如果接收到的BPDU更优，将会重新计算生成树拓扑。当非根桥在离上一次接收到最佳BPDU最长寿命（Max Age，默认20s）后还没有接收到最佳BPDU的时候，该端口将进入监听状态，该设备将产生TCN BPDU，并从根端口转发出去，从指定端口接收到TCN BPDU的上级设备将发送确认，然后再向上级设备发送TCN BPDU，此过程持续到根桥为止，然后根桥在其后发送的配置BPDU中将携带标记表明拓扑已发生变化，网络中的所有设备接收到后将MAC表项的刷新时间从300s缩短为15s。整个收敛的时间为50s左右。

7.BPDU
网桥协议数据单元(BPDU,Bridge Protocol Data Unit)生成树协议是一种桥嵌套协议，在IEEE 802.1d规范里定义，可以用来消除桥回路。它的工作原理是这样的：生成树协议定义了一个数据包，叫做桥协议数据单元BPDU（Bridge Protocol Data Unit）。
网桥用BPDU来相互通信，并用BPDU的相关机能来动态选择根桥和备份桥。但是因为从中心桥到任何网段只有一个路径存在，所以桥回路被消除。
在一个生成树环境里，桥不会立即开始转发功能，它们必须首先选择一个桥为根桥，然后建立一个指定路径。在一个网络里边拥有最低桥ID的将变成一个根桥，全部的生成树网络里面只有一个根桥。

8.AS系统
AS（autonomous system）系统指的是处于一个管理机构控制之下的路由器和网络群组。它可以是一个路由器直接连接到一个LAN上，同时也连到Internet上；它可以是一个由企业骨干网互连的多个局域网。在一个自治系统中的所有路由器必须相互连接，运行相同的路由协议，同时分配同一个自治系统编号。一个AS只能运行一种路由协议。
自治系统：autonomous system。在互联网中，一个自治系统(AS)是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。这个网络单位可以是一个简单的网络也可以是一个由一个或多个普通的网络管理员来控制的网络群体，它是一个单独的可管理的网络单元(例如一所大学，一个企业或者一个公司个体)。一个自治系统有时也被称为是一个路由选择域（routing domain）。一个自治系统将会分配一个全局的唯一的号码，有时我们把这个号码叫做自治系统号（ASN）。
一个自治系统网络内部进行路由信息的通信使用内部网关协议（IGP，Interior Gateway Protocols），而各个自治系统网络之间是通过边界网关协议（BGP，Border Gateway Protocol）来共享路由信息的。以前，我们通常使用外部网关协议（EGP，Exterior Gateway Protocol）来进行路由信息的通信。将来，边界网关协议将有望取代OSI中的域间选路协议（Inter-Domain Routing Protocol，IDRP）。
互联网协议指南给自治系统提出了如上的的定义后，又提出了一个更具有技术性的定义如下：一个自治系统即为由一个或多个网络运营商来运行一个或多个网络协议前缀的网络连接组合，这些运营商往往都具有单独的定义明确的路由策略。

9.as-path
AS-PATH属性详解：
概念：
AS-PATH是公认必遵属性，该属性用一串AS号来描述去往的指定目的地AS间路径或路由，当BGP speaker发气一条路由，将在AS_Path中增加自己的AS号。也就是说，这条路由每经过一个AS区域，就会加上一个AS号，用来标示路径的优先级。As号叠加得越多，说明经过的AS越多，那么这个路由的优先级也越低。相反，经过的AS越少，那么说明路由越优先，而且AS-Path还可以防止BGP的环路。
工作原理比较简单，如果某台BGP路由器从其外部对等体接收到的某条路由的AS-Path中包含已有的自己的AS号，那么该路由器就知道该路由出现了环路，因为需要丢包处理。
其实在真实的网络环境中，不一定AS号越少的链路质量越高。而AS-PATH这个功能又是根据AS号来判断路由的优先的，AS号越少越优先。那么这个时候我们可能会用到AS-path的一个功能，来增加AS号的长度,从而实现选路的功能

总结一下，这里AS-path一共有三个相关知识点：
1,一个路由的AS号附加得越多，路由的优先级越低。
2,AS-path属性可以防止环路.
3, 可以修改AS的附加，称为path-prepending.
总结，AS-path属性比较简单,关于比较原则：
AS号少的路由为最优路由.可以通过命令set as-path prepend命令在原来有的as号前再进行人为的添加，让这条路有劣于其他的路由。

10.BGP选路原则
---------------------------------------------------------------
在IGP时代我们都知道，比如说ospf，链路状态协议，在进行路由选择的时候，比的是链路的耗费，哪条链路耗费小则会更优先，如果两个链路耗费是一样的，那么就做负载均衡。
实际上就2个原则成就了ospf---最短路径优先的工作原理。
那如果在BGP中，有多条路由可以到达目的的时候，应当如何进行选择呢？哪一条路径是比较优先的呢？
来看看这11个属性的优先级，加深记忆，最好能熟练的背下来：
1 HIGHEST WEIGHT--cisco私有属性
2 HIGHEST LOCAL PRERENCE -----公认可选
3 ROUTE ORIGINATED BY THE ROUTER NEXT HOP=0.0.0.0 * -----公认必尊well-known mandatory
4 SHORTEST AS PATH * -----公认必尊well-known mandatory
5 LOWEST ORIGINATED IGP>EGP>INCOMPLETE * -----公认必尊well-known mandatory
6 LOWEST MED
7 EBGP PATH OVER IBGP PATH
8 PREFER THE PATH THROGH THE CLOSEST IGP NEIGHBOR
9 RREFER OLDEST ROUTER FOR EBGP PATH
10 PREFER THE PATH WITH THE LOWEST NEIGHBOR BGP ROUTER ID
11 BGP LOWEST ROUTER ID
12 MINIMUM CLASTER LIST LENGTH

在bgp中，除了有一大堆原理需要深刻理解以外，选路原则是重中之重。一定需要掌握(要想对bgp有所认识和故障排查，这里一定是要掌握而不是了解)选路原则。
该文档会逐一对每个属性进行验证.力求能达到让我自己在心里有数对这些概念。
再来看看BGP的选路原则：
1、 优先选取具有最大权重（weight）值的路径，权重是Cisco专有属性。
2、 如果权重值相同，优先选取具有最高本地优先级的路由。
3、 如果本地优先级相同，优先选取本地路由（下一跳为0.0.0.0）上的BGP路由。
4、 如果本地优先级相同，并且没有源自本路由器的路由，优先选取具有最短AS路径的路由。
5、 如果具有相同的AS路径长度，优先选取具有最低源代码（IBGP<EBGP<INCOMPLETE）的路由。
6、 如果起源代码相同，优先选取具有最低MED值的路径。
7、 如果MED都相同，在EBGP路由和联盟EBGP路由中，首选EBGP路由，在联盟EBGP路由和IBGP路由中，首选联盟EBGP路由。
8、 如果前面所有属性都相同，优先选取离IGP邻居最近的路径。
9、 如果内部路径也相同，优先选取最低BGP路由器ID的路径。
-----------------------------------------------------------------

11.mysql参数optimizer_switch
使用optimizer_switch系统变量可以控制优化程序的行为。它的值是一组标志，每个标志的值都为on 或off指示相应的优化器行为是启用还是禁用。此变量具有全局值和会话值，可以在运行时更改。可以在服务器启动时设置全局默认值。
查看optimizer_switch参数配置： SELECT @@optimizer_switch\G
命令行设置参数：SET [GLOBAL|SESSION] optimizer_switch='command[,command]...';
下面描述了opt_name按优化策略分组的允许 标志名称：
------------------------------
批处理密钥访问标志batched_key_access（默认 off）
控制BKA连接算法的使用。
为batched_key_access使设置为有效on，该 mrr标记还必须为 on。当前，MRR的成本估算过于悲观。因此，也有必要对 mrr_cost_based要 off用于要使用的BKA。

块嵌套循环标志block_nested_loop（默认 on）
控制BNL连接算法的使用。

条件过滤标志 condition_fanout_filter（默认 on）
控制条件过滤的使用。

派生表合并标志
derived_merge（默认 on）
控制派生表和视图合并到外部查询块中。
derived_merge假设没有其他规则阻止合并，则 该标志控制优化器是否尝试将派生表，视图引用和公用表表达式合并到外部查询块中。例如，ALGORITHM视图的指令优先于 derived_merge设置。默认情况下，该标志on用于启用合并。

存储引擎状态下推标志
engine_condition_pushdown（默认 on）
控制发动机状态下推。

哈希联接标志
hash_join（默认 on）
控制哈希联接（仅适用于MySQL 8.0.18；在MySQL 8.0.19或更高版本中无效）。

索引条件下推标志index_condition_pushdown（默认 on）
控制索引条件下推。

索引扩展标志use_index_extensions（默认 on）
控制索引扩展的使用。

索引合并标志index_merge（默认 on）
控制所有索引合并优化

index_merge_intersection（默认 on）
控制索引合并路口访问优化。

index_merge_sort_union（默认 on）
控制索引合并排序联盟访问优化。

index_merge_union（默认 on）
控制索引合并联合访问优化。

索引可见性标志use_invisible_indexes（默认 off）
控制不可见索引的使用。

多范围读取标志mrr（默认on）
控制多范围读取策略。

mrr_cost_based（默认 on）
如果，则控制基于成本的MRR的使用 mrr=on。

跳过扫描标志skip_scan（默认 on）
控制“跳过扫描”访问方法的使用。

半联接标志semijoin（默认 on）
控制所有半联接策略。
在MySQL 8.0.17和更高版本中，这也适用于抗联接优化。

duplicateweedout（默认 on）
控制半联接重复除草策略。

firstmatch（默认 on）
控制半联接的FirstMatch策略。

loosescan（默认 on）
控制半联接的LooseScan策略（不要与Loose Index Scan for混淆GROUP BY）。
semijoin、firstmatch、loosescan和duplicateweedout标志允许控制半联接策略。半联接标志控制是否使用半联接。如果设置为on，那么firstmatch和loosescan标志可以更好地控制允许的半连接策略。
如果duplicateweedou半联接策略被禁用，则除非所有其他适用策略也被禁用，否则不会使用该策略。
如果半联接和物化都处于启用状态，则半联接在适用的情况下也使用物化。默认情况下，这些标志处于启用状态。

子查询实现标志:
1、materialization（默认 on）
控制实现（包括半联接实现）。
2、subquery_materialization_cost_based （默认on）
使用基于成本的物化选择。

materialization控制是否使用子查询materialization。如果semijoin和materialization 都处于启用状态，则semijoin在适用的情况下也使用物化。默认情况下，这些标志处于启用状态。
基于子查询物化和基于成本的标志可以控制子查询物化和IN到现有子查询转换之间的选择。如果标志为on（默认值），优化器将在子查询物化和IN-to-EXISTS子查询转换（如果两种方法都可以使用）之间执行基于成本的选择。如果标志为off，优化器将选择子查询物化而不是IN来存在子查询转换。
------------------------------

12.mysql const与eq_ref的区别
------------------------------
简单地说是const是直接按主键或唯一键读取，eq_ref用于联表查询的情况，按联表的主键或唯一键联合查询。

下面的内容翻译自官方方档：
const
该表最多有一个匹配行, 在查询开始时读取。由于只有一行, 因此该行中列的值可以被优化器的其余部分视为常量。const 表非常快, 因为它们只读一次。
const用于将 "主键" 或 "唯一" 索引的所有部分与常量值进行比较。在下面的查询中, tbl_name 可以用作 const 表:

SELECT * FROM tbl_name WHERE primary_key=1;
SELECT * FROM tbl_name
WHERE primary_key_part1=1 AND primary_key_part2=2;
eq_ref

读取本表中和关联表表中的每行组合成的一行。除 了 system 和 const 类型之外, 这是最好的联接类型。当连接使用索引的所有部分时, 索引是主键或唯一非 NULL 索引时, 将使用该值。
eq_ref 可用于使用 = 运算符比较的索引列。比较值可以是常量或使用此表之前读取的表中的列的表达式。在下面的示例中, MySQL 可以使用 eq_ref 连接(join)ref_table来处理:

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;
SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

几个重要参数的说明：https://www.cnblogs.com/mysql-hang/articles/10342287.html
------------------------------

13.lsof命令常用用法
------------------------------
1.列出所有打开的文件:

lsof

备注: 如果不加任何参数，就会打开所有被打开的文件，建议加上一下参数来具体定位

2. 查看谁正在使用某个文件

lsof /filepath/file

3.递归查看某个目录的文件信息

lsof +D /filepath/filepath2/

备注: 使用了+D，对应目录下的所有子目录和文件都会被列出

4. 比使用+D选项，遍历查看某个目录的所有文件信息 的方法

lsof | grep ‘/filepath/filepath2/’

5. 列出某个用户打开的文件信息

lsof -u username

备注: -u 选项，u其实是user的缩写

6. 列出某个程序所打开的文件信息

lsof -c mysql

备注: -c 选项将会列出所有以mysql开头的程序的文件，其实你也可以写成lsof | grep mysql,但是第一种方法明显比第二种方法要少打几个字符了

7. 列出多个程序多打开的文件信息

lsof -c mysql -c apache

8. 列出某个用户以及某个程序所打开的文件信息

lsof -u test -c mysql

9. 列出除了某个用户外的被打开的文件信息

lsof -u ^root

备注：^这个符号在用户名之前，将会把是root用户打开的进程不让显示

10. 通过某个进程号显示该进行打开的文件

lsof -p 1

11. 列出多个进程号对应的文件信息

lsof -p 123,456,789

12. 列出除了某个进程号，其他进程号所打开的文件信息

lsof -p ^1

13 . 列出所有的网络连接

lsof -i

14. 列出所有tcp 网络连接信息

lsof -i tcp

15. 列出所有udp网络连接信息

lsof -i udp

16. 列出谁在使用某个端口

lsof -i :3306

17. 列出谁在使用某个特定的udp端口

lsof -i udp:55

特定的tcp端口

lsof -i tcp:80

18. 列出某个用户的所有活跃的网络端口

lsof -a -u test -i

19. 列出所有网络文件系统

lsof -N

20.域名socket文件

lsof -u

21.某个用户组所打开的文件信息

lsof -g 5555

22. 根据文件描述列出对应的文件信息

lsof -d description(like 2)

23. 根据文件描述范围列出文件信息

lsof -d 2-3
------------------------------

14.df和du查看的空间容量相差很大问题
一个大文件虽然使用了rm -rf删除了，但是由于该文件还存在其他进程调用，所以相当于没有被删除。当我们使用rm -rf删除文件时，只是删除了该文件在磁盘上的索引，并不是真正的删除，当有新文件写入的时会被覆盖。

15.flannel网络通信流程
https://zhuanlan.zhihu.com/p/157607451

16.关于kubernetus使用storageclass动态分配pv动态存储
https://blog.csdn.net/u011943534/article/details/100887530
https://www.cnblogs.com/xiangsikai/p/11424245.html

17.clickhouse概述
https://www.jianshu.com/p/350b59e8ea68

18.csi插件-腾讯云cos用作kubernetus的卷存储
https://github.com/TencentCloud/kubernetes-csi-tencentcloud/blob/master/docs/README_COSFS.md

19.服务器出现TIME_WAIT和CLOSE_WAIT的原因以及解决方法
--------------------------------
1.服务器保持了大量TIME_WAIT状态
这种情况比较常见，一些爬虫服务器或者WEB服务器（如果网管在安装的时候没有做内核参数优化的话）上经常会遇到这个问题，这个问题是怎么产生的呢？
从上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：
1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

关于MSL引用下面一段话：
MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好讓 連線埠 (Ports) 能更快空出來給其他連線使用。
再引用网络资源的一段话：
值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可 想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个 request/response，一个主要原因就是发现了这个问题。
也就是说HTTP的交互跟上面画的那个图是不一样的，关闭连接的不是客户端，而是服务器，所以web服务器也是会出现大量的TIME_WAIT的情况的。
现在来说如何来解决这个问题。
解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。

下面来看一下我们网管对/etc/sysctl.conf文件的修改：
#对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间
net.ipv4.tcp_syn_retries=2

#net.ipv4.tcp_synack_retries=2

#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3

#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout=30

#表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 4096

#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭
net.ipv4.tcp_syncookies = 1

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
net.ipv4.tcp_tw_reuse = 1

#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
net.ipv4.tcp_tw_recycle = 1

##减少超时前的探测次数
net.ipv4.tcp_keepalive_probes=5

##优化网络设备接收队列
net.core.netdev_max_backlog=3000
修改完之后执行/sbin/sysctl -p让参数生效。
这里头主要注意到的是net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
这几个参数。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_*一系列参数，是用来设置服务器检测连接存活的相关配置。
关于keepalive的用途可以参考：http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

2.服务器保持了大量CLOSE_WAIT状态
TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。

但是CLOSE_WAIT就不一样了，从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。

如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况，那么这篇日志也许对你有用：http://blog.csdn.net/shootyou/article/details/6615051
在那边日志里头我举了个场景，来说明CLOSE_WAIT和TIME_WAIT的区别，这里重新描述一下：
服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。
所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。因为问题出在服务器程序里头
--------------------------------

20.explain数据库过程分析
https://blog.csdn.net/qq_28702747/article/details/79491844

21.mysql执行流程
--------------------------------
查询执行流程
　　下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：
1.连接
　　1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求
　　1.2将请求转发到‘连接进/线程模块’
　　1.3调用‘用户模块’来进行授权检查
　　1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求

2.处理
　　2.1先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回
　　2.2上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树
　　2.3接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树
　　2.4再转交给对应的模块处理
　　2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划
　　2.6模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限
　　2.7有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件
　　2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理
　　2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中

3.结果
　　3.1Query请求完成后，将结果集返回给‘连接进/线程模块’
　　3.2返回的也可以是相应的状态标识，如成功或失败等
　　3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接

语句执行顺序：
1 FROM <left_table>
2 ON <join_condition>
3 <join_type> JOIN <right_table>
4 WHERE <where_condition>
5 GROUP BY <group_by_list>
6 HAVING <having_condition>
7 SELECT
8 DISTINCT <select_list>
9 ORDER BY <order_by_condition>
10 LIMIT <limit_number>
-------------------------------

21.sql mode
https://www.cnblogs.com/cuixiaoying/p/11436167.html

标签：BPDU,记录,知识,默认,第六篇,lsof,连接,路由,WAIT
来源： https://www.cnblogs.com/hrers/p/13759510.html