1.windows命令bitsadmin
>1、bitsadmin /rawreturn /transfer getfile http://download.sysinternals.com/files/PSTools.zip c:\p.zip
>2、bitsadmin /rawreturn /transfer getpayload http://download.sysinternals.com/files/PSTools.zip c:\p.zip
>3、bitsadmin /transfer myDownLoadJob /download /priority normal "http://download.sysinternals.com/files/PSTools.zip" "c:\p.zip" #第3条命令带进度条
>4、多条命令
bitsadmin /create myDownloadJob
bitsadmin /addfile myDownloadJob http://download.sysinternals.com/files/PSTools.zip c:\lcx.zip
bitsadmin /resume myDownloadJob
bitsadmin /info myDownloadJob /verbose
bitsadmin /complete myDownloadJob
注：对于命令的说明解释，myDownloadJob表示类比一个工作站，这个工作站用于管理下载和上传的文件。多条命令的解释为，创建一个工作站，向工作站添加一个文件，文件来源于http://download.sysinternals.com/files/PSTools.zip，存放地址为c:\lcx.zip，lcx.zip为下载后的更名。resume表示继续下载，info表示详细信息，complete表示工作任务的完成。
2.windows常用渗透命令
https://www.freebuf.com/articles/system/114731.html
3.Linux系统查看文件的编码格式和更改文件的编码格式
>vim查看
vim打开文件，切换到底线命令模式，在最底一行输入如下命令：
:set fileencoding
>file查看
file 文件名
>enca查看
enca 文件名
>编码转换
vim 使用vim直接进行文件的编码转换 :set fileencoding=utf-8
recode 转换文件编码
Utrac 转换文件编码
cstocs 转换文件编码
convmv 转换文件名编码
enca 分析给定文件的编码
iconv iconv -f GBK -t UTF-8 file1 -o file2 -f From 某个编码 -t To 某个编码 -o 输出到文件
4.mysql innodb_autoinc_lock_mode详解
innodb_autoinc_lock_mode这个参数控制着在向有auto_increment 列的表插入数据时，相关锁的行为；
通过对它的设置可以达到性能与安全(主从的数据一致性)的平衡
【0】我们先对insert做一下分类
首先insert大致上可以分成三类：
1、simple insert 如insert into t(name) values('test')
2、bulk insert 如load data | insert into ... select .... from ....
3、mixed insert 如insert into t(id,name) values(1,'a'),(null,'b'),(5,'c');
【1】innodb_autoinc_lock_mode 的说明
innodb_auto_lockmode有三个取值：
1、0 这个表示tradition 传统
2、1 这个表示consecutive 连续
3、2 这个表示interleaved 交错
【1.1】tradition(innodb_autoinc_lock_mode=0) 模式:
1、它提供了一个向后兼容的能力
2、在这一模式下，所有的insert语句("insert like") 都要在语句开始的时候得到一个
表级的auto_inc锁，在语句结束的时候才释放这把锁，注意呀，这里说的是语句级而不是事务级的，
一个事务可能包涵有一个或多个语句。
3、它能保证值分配的可预见性，与连续性，可重复性，这个也就保证了insert语句在复制到slave
的时候还能生成和master那边一样的值(它保证了基于语句复制的安全)。
4、由于在这种模式下auto_inc锁一直要保持到语句的结束，所以这个就影响到了并发的插入。
【1.2】consecutive(innodb_autoinc_lock_mode=1) 模式:
1、这一模式下去simple insert 做了优化，由于simple insert一次性插入值的个数可以立马得到
确定，所以mysql可以一次生成几个连续的值，用于这个insert语句；总的来说这个对复制也是安全的
(它保证了基于语句复制的安全)
2、这一模式也是mysql的默认模式，这个模式的好处是auto_inc锁不要一直保持到语句的结束，只要
语句得到了相应的值后就可以提前释放锁
【1.3】interleaved(innodb_autoinc_lock_mode=2) 模式
1、由于这个模式下已经没有了auto_inc锁，所以这个模式下的性能是最好的；但是它也有一个问题，就是
对于同一个语句来说它所得到的auto_incremant值可能不是连续的。
【2】如果你的二进制文件格式是mixed | row 那么这三个值中的任何一个对于你来说都是复制安全的。
由于现在mysql已经推荐把二进制的格式设置成row，所以在binlog_format不是statement的情况下最
好是innodb_autoinc_lock_mode=2 这样可能知道更好的性能。
5.NAT模式下为什么要去掉服务端timestamp时间戳
PAWS
PAWS全名Protect Againest Wrapped Sequence numbers，目的是解决在高带宽下，TCP序列号在一次会话中可能被重复使用而带来的问题。
客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一定时间没有到达服务端，客户端超时重传序列号为A的数据包A2，接下来假设带宽足够，传输用尽序列号空间，重新使用A，此时服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。
PAWS要解决的就是上述问题，它依赖于timestamp机制，理论依据是：在一条正常的TCP流中，按序接收到的所有TCP数据包中的timestamp都应该是单调非递减的，这样就能判断那些timestamp小于当前TCP流已处理的最大timestamp值的报文是延迟到达的重复报文，可以予以丢弃。在上文的例子中，服务器已经处理数据包Z，而后到来的A1包的timestamp必然小于Z包的timestamp，因此服务端会丢弃迟到的A1包，等待正确的报文到来。
PAWS机制的实现关键是内核保存了Per-Connection的最近接收时间戳，如果加以改进，就可以用来优化服务器TIME_WAIT状态的快速回收。
TIME_WAIT状态是TCP四次挥手中主动关闭连接的一方需要进入的最后一个状态，并且通常需要在该状态保持2*MSL（报文最大生存时间），它存在的意义有两个：
1.可靠地实现TCP全双工连接的关闭：关闭连接的四次挥手过程中，最终的ACK由主动关闭连接的一方（称为A）发出，如果这个ACK丢失，对端（称为B）将重发FIN，如果A不维持连接的TIME_WAIT状态，而是直接进入CLOSED，则无法重传ACK，B端的连接因此不能及时可靠释放。
2.等待“迷路”的重复数据包在网络中因生存时间到期消失：通信双方A与B，A的数据包因“迷路”没有及时到达B，A会重发数据包，当A与B完成传输并断开连接后，如果A不维持TIME_WAIT状态2*MSL时间，便有可能与B再次建立相同源端口和目的端口的“新连接”，而前一次连接中“迷路”的报文有可能在这时到达，并被B接收处理，造成异常，维持2*MSL的目的就是等待前一次连接的数据包在网络中消失。
TIME_WAIT状态的连接需要占用服务器内存资源维持，Linux内核提供了一个参数来控制TIME_WAIT状态的快速回收：tcp_tw_recycle，它的理论依据是：
在PAWS的理论基础上，如果内核保存Per-Host的最近接收时间戳，接收数据包时进行时间戳比对，就能避免TIME_WAIT意图解决的第二个问题：前一个连接的数据包在新连接中被当做有效数据包处理的情况。这样就没有必要维持TIME_WAIT状态2*MSL的时间来等待数据包消失，仅需要等待足够的RTO（超时重传），解决ACK丢失需要重传的情况，来达到快速回收TIME_WAIT状态连接的目的。
但上述理论在多个客户端使用NAT访问服务器时会产生新的问题：同一个NAT背后的多个客户端时间戳是很难保持一致的（timestamp机制使用的是系统启动相对时间），对于服务器来说，两台客户端主机各自建立的TCP连接表现为同一个对端IP的两个连接，按照Per-Host记录的最近接收时间戳会更新为两台客户端主机中时间戳较大的那个，而时间戳相对较小的客户端发出的所有数据包对服务器来说都是这台主机已过期的重复数据，因此会直接丢弃。
6.Linux服务器丢包故障的解决思路及引申的TCP/IP协议栈理论
------------------------------------------------------------------------
故障现象：从办公网访问公网服务器不稳定，服务器某些端口访问经常超时，但Ping测试显示客户端与服务器的链路始终是稳定低延迟的。
抓包特点：
从办公网访问服务器有多个客户端，是同一个出口IP，有少部分是始终能够稳定连接的，另一部分间歇访问超时或延迟很高
同一时刻的访问，无论哪个客户端的数据包先到达，服务端会及时处理部分客户端的SYN请求，对另一部分客户端的SYN包“视而不见”，如tcpdump数据所示，源端口为56909的SYN请求没有得到响应，同一时间源端口为50212的另一客户端SYN请求马上得到响应。
排查过程：
>防火墙拦截
服务器端口无法连接，通常就是查看防火墙配置了，虽然这里已经确认同一个出口IP的客户端有的能够正常访问，但也不排除配置了DROP特定端口范围的可能性。
确认：
iptables-save -t filter
>连接跟踪表溢出
除了防火墙本身配置DROP规则外，与防火墙有关的还有连接跟踪表nf_conntrack，Linux为每个经过内核网络栈的数据包，生成一个新的连接记录项，当服务器处理的连接过多时，连接跟踪表被打满，服务器会丢弃新建连接的数据包。
确认：
方式一：dmesg |grep nf_conntrack
如果输出值中有“nf_conntrack: table full, dropping packet”，说明服务器nf_conntrack表已经被打满。
方式二：
# 查看nf_conntrack表最大连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_max
# 查看nf_conntrack表当前连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_count
对比当前连接数和最大连接数，如果大于或等于，说明跟踪连接数不够了
如何解决：
如果确认服务器因连接跟踪表溢出而开始丢包，首先需要查看具体连接判断是否正遭受DOS攻击，如果是正常的业务流量造成，可以考虑调整nf_conntrack的参数：
nf_conntrack_max决定连接跟踪表的大小，默认值是65535，可以根据系统内存大小计算一个合理值：CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32)，如32G内存可以设置1048576；
nf_conntrack_buckets决定存储conntrack条目的哈希表大小，默认值是nf_conntrack_max的1/4，延续这种计算方式：BUCKETS = CONNTRACK_MAX/4，如32G内存可以设置262144；
nf_conntrack_tcp_timeout_established决定ESTABLISHED状态连接的超时时间，默认值是5天，可以缩短到1小时，即3600。
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600
>Ring Buffer溢出
排除了防火墙的因素，我们从底向上来看Linux接收数据包的处理过程，首先是网卡驱动层。
物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃。
如何确认
通过ethtool或/proc/net/dev可以查看因Ring Buffer满而丢弃的包统计，在统计项中以fifo标识：
ethtool -S eth0|grep rx_fifo
看对应FIFO列的数值是否有增加，有增加说明存在丢包
如何解决
如果发现服务器上某个网卡的fifo数持续增大，可以去确认CPU中断是否分配均匀，也可以尝试增加Ring Buffer的大小，通过ethtool可以查看网卡设备Ring Buffer最大值，修改Ring Buffer当前设置：
# 查看eth0网卡Ring Buffer最大值和当前设置
$ ethtool -g eth0
# 修改网卡eth0接收与发送硬件缓存区大小
$ ethtool -G eth0 rx 4096 tx 4096
>netdev_max_backlog溢出
netdev_max_backlog是内核从NIC收到包后，交由协议栈（如IP、TCP）处理之前的缓冲队列。每个CPU核都有一个backlog队列，与Ring Buffer同理，当接收包的速率大于内核协议栈处理的速率时，CPU的backlog队列不断增长，当达到设定的netdev_max_backlog值时，数据包将被丢弃。
如何确认
通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出：
cat /proc/net/softnet_stat
其中：
每一行代表每个CPU核的状态统计，从CPU0依次往下；
每一列代表一个CPU核的各项统计：第一列代表中断处理程序收到的包总数；第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。
从上面的输出可以看出，这台服务器统计中，并没有因为netdev_max_backlog导致的丢包。
如何解决
netdev_max_backlog的默认值是1000，在高速链路上，可能会出现上述第二列统计不为0的情况，可以通过修改内核参数net.core.netdev_max_backlog来解决：
sysctl -w net.core.netdev_max_backlog=2000
>反向路由过滤
反向路由过滤机制是Linux通过反向路由查询，检查收到的数据包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果没有通过验证，则丢弃数据包，设计的目的是防范IP地址欺骗攻击。rp_filter提供了三种模式供配置：
0 - 不验证
1 - RFC3704定义的严格模式：对每个收到的数据包，查询反向路由，如果数据包入口和反向路由出口不一致，则不通过
2 - RFC3704定义的松散模式：对每个收到的数据包，查询反向路由，如果任何接口都不可达，则不通过
如何确认
查看当前rp_filter策略配置：
cat /proc/sys/net/ipv4/conf/eth0/rp_filter
如果这里设置为1，就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证了。
从原理来看这个机制工作在网络层，因此，如果客户端能够Ping通服务器，就能够排除这个因素了。
如何解决
根据实际网络环境将rp_filter设置为0或2：
sysctl -w net.ipv4.conf.all.rp_filter=2 或sysctl -w net.ipv4.conf.eth0.rp_filter=2
>半连接队列溢出
半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列，队列大小由内核参数tcp_max_syn_backlog定义。
当服务器保持的半连接数量达到tcp_max_syn_backlog后，内核将会丢弃新来的SYN包。
如何确认
通过dmesg可以确认是否有该情况发生：
dmesg | grep "TCP: drop open request from"
半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知
netstat -ant|grep SYN_RECV|wc -l
大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，第三次握手完成后退出，正常的网络环境中这个过程发生很快，如果这个值较大，服务器极有可能受到了SYN Flood攻击。
如何解决
tcp_max_syn_backlog的默认值是256，通常推荐内存大于128MB的服务器可以将该值调高至1024，内存小于32MB的服务器调低到128，同样，该参数通过sysctl修改：
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
另外，上述行为受到内核参数tcp_syncookies的影响，若启用syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。
$ sysctl -w net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies = 1
>PAWS
PAWS全名Protect Againest Wrapped Sequence numbers，目的是解决在高带宽下，TCP序列号在一次会话中可能被重复使用而带来的问题。
客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一定时间没有到达服务端，客户端超时重传序列号为A的数据包A2，接下来假设带宽足够，传输用尽序列号空间，重新使用A，此时服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。
PAWS要解决的就是上述问题，它依赖于timestamp机制，理论依据是：在一条正常的TCP流中，按序接收到的所有TCP数据包中的timestamp都应该是单调非递减的，这样就能判断那些timestamp小于当前TCP流已处理的最大timestamp值的报文是延迟到达的重复报文，可以予以丢弃。在上文的例子中，服务器已经处理数据包Z，而后到来的A1包的timestamp必然小于Z包的timestamp，因此服务端会丢弃迟到的A1包，等待正确的报文到来。
PAWS机制的实现关键是内核保存了Per-Connection的最近接收时间戳，如果加以改进，就可以用来优化服务器TIME_WAIT状态的快速回收。
TIME_WAIT状态是TCP四次挥手中主动关闭连接的一方需要进入的最后一个状态，并且通常需要在该状态保持2*MSL（报文最大生存时间），它存在的意义有两个：
1.可靠地实现TCP全双工连接的关闭：关闭连接的四次挥手过程中，最终的ACK由主动关闭连接的一方（称为A）发出，如果这个ACK丢失，对端（称为B）将重发FIN，如果A不维持连接的TIME_WAIT状态，而是直接进入CLOSED，则无法重传ACK，B端的连接因此不能及时可靠释放。
2.等待“迷路”的重复数据包在网络中因生存时间到期消失：通信双方A与B，A的数据包因“迷路”没有及时到达B，A会重发数据包，当A与B完成传输并断开连接后，如果A不维持TIME_WAIT状态2*MSL时间，便有可能与B再次建立相同源端口和目的端口的“新连接”，而前一次连接中“迷路”的报文有可能在这时到达，并被B接收处理，造成异常，维持2*MSL的目的就是等待前一次连接的数据包在网络中消失。
TIME_WAIT状态的连接需要占用服务器内存资源维持，Linux内核提供了一个参数来控制TIME_WAIT状态的快速回收：tcp_tw_recycle，它的理论依据是：
在PAWS的理论基础上，如果内核保存Per-Host的最近接收时间戳，接收数据包时进行时间戳比对，就能避免TIME_WAIT意图解决的第二个问题：前一个连接的数据包在新连接中被当做有效数据包处理的情况。这样就没有必要维持TIME_WAIT状态2*MSL的时间来等待数据包消失，仅需要等待足够的RTO（超时重传），解决ACK丢失需要重传的情况，来达到快速回收TIME_WAIT状态连接的目的。
但上述理论在多个客户端使用NAT访问服务器时会产生新的问题：同一个NAT背后的多个客户端时间戳是很难保持一致的（timestamp机制使用的是系统启动相对时间），对于服务器来说，两台客户端主机各自建立的TCP连接表现为同一个对端IP的两个连接，按照Per-Host记录的最近接收时间戳会更新为两台客户端主机中时间戳较大的那个，而时间戳相对较小的客户端发出的所有数据包对服务器来说都是这台主机已过期的重复数据，因此会直接丢弃。
如何确认
通过netstat可以得到因PAWS机制timestamp验证被丢弃的数据包统计：
netstat -s |grep -e "passive connections rejected because of time stamp" -e "packets rejects in established connections because of timestamp”
通过sysctl查看是否启用了tcp_tw_recycle及tcp_timestamp:
$ sysctl net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_recycle = 1
$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1
这次问题正是因为服务器同时开启了tcp_tw_recycle和timestamps，而客户端正是使用NAT来访问服务器，造成启动时间相对较短的客户端得不到服务器的正常响应。
如何解决
如果服务器作为服务端提供服务，且明确客户端会通过NAT网络访问，或服务器之前有7层转发设备会替换客户端源IP时，是不应该开启tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外还被其他机制依赖，推荐继续开启：
sysctl -w net.ipv4.tcp_tw_recycle=0
sysctl -w net.ipv4.tcp_timestamps=1
总结思路：
防火墙--->连接跟踪数nf_conntrack--->网卡数据接收缓存ring buffer--->协议栈接受后的缓存队列netdev_max_backlog--->反路由验证链路rp_filter--->半连接队列溢出tcp_max_syn_backlog--->PAWS机制timestamp
------------------------------------------------------------------------
7.mysql binlog记录格式的介绍
binlog模式分三种（row，statement，mixed）
#Row
日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改，只记录要修改的数据，只有value，不会有sql多表关联的情况。
优点：在row模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了，所以row的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程和function，以及trigger的调用和出发无法被正确复制问题。
缺点：在row模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
#statement
每一条会修改数据的sql都会记录到master的binlog中，slave在复制的时候sql进程会解析成和原来master端执行多相同的sql再执行。
优点：在statement模式下首先就是解决了row模式的缺点，不需要记录每一行数据的变化减少了binlog日志量，节省了I/O以及存储资源，提高性能。因为他只需要记录在master上所执行的语句的细节以及执行语句的上下文信息。
缺点：在statement模式下，由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于mysql现在发展比较快，很多的新功能不断的加入，使mysql的复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement中，目前已经发现不少情况会造成Mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能被正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row是基于每一行来记录的变化，所以不会出现，类似的问题。
#Mixed
从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。
8.cc攻击
https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545?fr=aladdin
9.DHCP relay 原理
1 当dhcp client 启动并进行dhcp 初始化时，它会在本地网络广播配置请求报文。
2 如果本地网络存在dhcp server，则可以直接进行dhcp 配置，不需要dhcp relay。
3 如果本地网络没有dhcp server，则与本地网络相连的具有dhcprelay 功能的网络设备收到该广播报文后，将进行适当处理并转发给指定的其它网络上的dhcp server。
4 dhcp server 根据dhcp client 提供的信息进行相应的配置，并通过dhcp relay 将配置信息发送给dhcp client，完成对dhcp client 的动态配置。
事实上，从开始到最终完成配置，需要多个这样的交互过程。
1 dhcp relay设备修改dhcp消息中的相应字段，把dhcp的广播包改成单播包，并负责在服务器与客户机之间转换。
2 netcore路由器（2x05）可以作为dhcp relay 代理。
10.nf_conntrack满之解决方法
------------------------------------------------------
vim /var/log/message报错
nf_conntrack: table full, dropping packet
先关掉iptables
/etc/init.d/iptables stop
查看当前的连接数：
# grep nf_conntrack /proc/slabinfo
查出目前 nf_conntrack 的排名：
$ cat /proc/net/nf_conntrack | cut -d ' ' -f 10 | cut -d '=' -f 2 | sort | uniq -c | sort -nr | head -n 10
优化参数
状态跟踪表的最大行数的设定，理论最大值 CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (ARCH / 32)
以64G的64位操作系统为例，CONNTRACK_MAX = 64*1024*1024*1024/16384/2 = 2097152
即时生效请执行：
sysctl –w net.netfilter.nf_conntrack_max = 524288 （16G）
其哈希表大小通常为总表的1/8，最大为1/2。CONNTRACK_BUCKETS = CONNTRACK_MAX / 8
同样64G的64位操作系统，哈希最佳范围是 262144 ~ 1048576 。
运行状态中通过 sysctl net.netfilter.nf_conntrack_buckets 进行查看，通过文件 /sys/module/nf_conntrack/parameters/hashsize 进行设置
或者新建 /etc/modprobe.d/iptables.conf ，重新加载模块才生效：
options nf_conntrack hashsize = 262144
还有些相关的系统参数`sysctl -a | grep nf_conntrack`可以调优（/etc/sysctl.conf ）：
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.ip_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
------------------------------------------------------
11.NVME接口
NVM Express是标准和信息的开放收集，以充分展示非易失性存储器在从移动设备到数据中心的所有类型的计算环境中的优势。NVMe从头开始设计，可为当前和将来的NVM技术提供高带宽和低延迟的存储访问。NVM Express标准包括：
NVM Express –用于PCI Express附加存储的寄存器接口和命令集，以及适用于多种操作系统的行业标准软件。NVMe被广泛认为是PCIeSSD的事实上的行业标准。NVMe管理界面–用于NVM Express存储的带外管理的命令集和体系结构（例如，使用BMC发现，监视和更新NVMe设备）。架构上的NVMe – NVM Express的扩展，可通过PCIe以外的其他传输方式对NVM Express命令集进行隧道传输。NVMe over Fabric通过允许同一协议扩展到各种网络接口上，扩展了在全球最大的数据中心中大规模高效存储架构的优势。
背景：
历史上，大多数SSD使用如SATA、SAS或光纤通道等接口与计算机接口的总线连接。随着固态硬盘在大众市场上的流行，SATA已成为个人电脑中连接SSD的最典型方式；但是，SATA的设计主要是作为机械硬盘驱动器（HDD）的接口，并随着时间的推移越来越难满足速度日益提高的SSD。随着在大众市场的流行，许多固态硬盘的数据速率提升已经放缓。不同于机械硬盘，部分SSD已受到SATA最大吞吐量的限制。
在NVMe出现之前，高端SSD只得以采用PCI Express总线制造，但需使用非标准规范的接口。若使用标准化的SSD接口，操作系统只需要一个驱动程序就能使用匹配规范的所有SSD。这也意味着每个SSD制造商不必用额外的资源来设计特定接口的驱动程序。
优势：
NVMe具体优势包括：
性能有数倍的提升；
可大幅降低延迟；
NVMe可以把最大队列深度从32提升到64000，SSD的IOPS能力也会得到大幅提升；
自动功耗状态切换和动态能耗管理功能大大降低功耗；
NVMe标准的出现解决了不同PCIe SSD之间的驱动适用性问题。
NVMe扩展到了诸如以太网，光纤通道和InfiniBand®，不仅可以访问单个NVMe设备，还可以访问NVMe存储系统。
12.mysql查看binlog为ROW格式的文件
mysqlbinlog --base64-output=decode-rows -vvv /data/binlog/mysql-bin.000001
13.接口协议
https://baike.baidu.com/item/%E6%8E%A5%E5%8F%A3%E5%8D%8F%E8%AE%AE/6164612?fr=aladdin
14.关于并发和性能的解释
作者：灵剑
链接：https://www.zhihu.com/question/46334482/answer/100892412
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
首先并发度跟性能有联系但不完全一样，性能一般使用qps进行衡量，即每秒处理的请求次数。很容易想象如果程序性能很好，即使同时只能处理一个请求也可以有很高的qps。但一般来说每个请求总会因为资源固有的延迟而耽误一定时间，这个时候提高并发度就会提高一定的性能，但并发度高到一定程度之后再提升并发度并不会增加性能，反而会导致每个请求的延迟都变长，qps不再提升，这时候瓶颈往往出现在其他部分，因此许多Web框架使用线程池的模型，并不能支持非常多的并发数，但性能也不差。如果是有许多长连接的comet服务的话，并发度要求会比较高。否则的话盲目追求并发度并不是一个好的web服务器的优化方法。很多人觉得自己的Web服务器并发度不够，其实性能低下并不是并发度不够的问题。单纯说并发量的话，并发访问量主要受到以下因素的限制：1. 物理资源。主要是内存，每个同时进行的请求都要占用一部分内存，内存超过限度程序就会崩溃，除了扩展物理内存以外，优化每个请求占用的内存资源也很重要。但一般情况下总内存都不会是瓶颈。除了内存以外，CPU、网络带宽、磁盘IO等都会有影响，但主要影响总qps而不是最大并发量。2. 系统资源。主要是内核内存，文件号限制，conntrack表等。应用程序除了占用应用程序空间中的资源以外，一般还需要占用一些系统的资源，在Linux下主要表现为线程、文件号、conntrack表容量，在Windows下主要表现为句柄数量等，大部分最后都对应到操作系统内核使用的内存上。与用户空间不同，操作系统在内核态中往往受到更严格的内存空间限制，因此内核内存会比用户态的内存更宝贵。Linux操作系统对这些系统资源往往有一些限制，主要可以通过ulimit和系统参数进行配置，例如ulimit -n默认配置为1024，这个就会严重影响网络服务的并发量。线程也会占用比较多的内核态资源，因此高并发的系统往往不采用多线程（或者不采用单个线程处理单个请求的模型），而是使用多路转接（如select, epoll）的单线程或者有限数量的多线程的模型。3. 程序结构一般来说socket程序都会有一段是类似这样的：s = create_socket(...)s.bind(...)s.listen(256) # backlogwhile True: s1, addr = s.accept() handleRequest(s1)这段handleRequest如果发生阻塞，比如线程池或者队列已满，就会使整个服务的并发量受到限制。一般这个限制都是故意设计的，这样在服务器压力很大的时候不会发生并发量太大导致内存溢出、资源不足或者用户端IO超时等问题。一般会有相应的参数比如线程池大小、队列长度之类来控制。反过来如果完全不控制的，一般并发能力会很强，但也容易出现单个请求速度过慢之类的问题。有人以为listen的backlog参数会对并发度有影响，其实并没有特别大的影响。总结来说，要提高最大并发量：1. 确保足够大的内存2. 调整相应系统参数如ulimit, nf_conntrack, max.files等3. 调整线程池、队列长度等参数（如果有的话），或者使用没有相应限制的IO框架最后还是强调，最大并发量跟服务器性能其实是不同的，在优化服务器性能的过程中，这是一个比较次要的指标，要承受大量访问最主要还是提高qps。
15.关于soft limit、hard limit以及/proc/sys/fs/file-max
shell级限制
通过ulimit -n修改，如执行命令ulimit -n 1000，则表示将当前shell的当前用户所有进程能打开的最大文件数量设置为1000.
用户级限制
ulimit -n是设置当前shell的当前用户所有进程能打开的最大文件数量，但是一个用户可能会同时通过多个shell连接到系统，所以还有一个针对用户的限制，通过修改 /etc/security/limits.conf实现，例如，往limits.conf输入以下内容：
root soft nofile 1000
root hard nofile 1200
soft nofile表示软限制，hard nofile表示硬限制，软限制要小于等于硬限制。上面两行语句表示，root用户的软限制为1000，硬限制为1200，即表示root用户能打开的最大文件数量为1000，不管它开启多少个shell。
系统级限制
修改cat /proc/sys/fs/file-max
总结：
/proc/sys/fs/file-max限制不了/etc/security/limits.conf
只有root用户才有权限修改/etc/security/limits.conf
对于非root用户， /etc/security/limits.conf会限制ulimit -n，但是限制不了root用户
对于非root用户，ulimit -n只能越设置越小，root用户则无限制
任何用户对ulimit -n的修改只在当前环境有效，退出后失效，重新登录新来后，ulimit -n由limits.conf决定
如果limits.conf没有做设定，则默认值是1024
当前环境的用户所有进程能打开的最大问价数量由ulimit -n决定
/proc/sys/fs/file-max设置很大，超过65535是因为是系统级别的，而/etc/security/limit.conf的配置，则是shell级别的限制，最大可以打开的文件数量为65535。---个人理解
详细请参考：https://www.cnblogs.com/youngerger/p/9128245.html
16.lvs和nginx的区别
一、lvs的优势：
1.抗负载能力强，因为lvs工作方式的逻辑是非常简单的，而且工作在网络的第4层，仅作请求分发用，没有流量，所以在效率上基本不需要太过考虑。lvs一般很少出现故障，即使出现故障一般也是其他地方（如内存、CPU等）出现问题导致lvs出现问题。
2.配置性低，这通常是一大劣势同时也是一大优势，因为没有太多的可配置的选项，所以除了增减服务器，并不需要经常去触碰它，大大减少了人为出错的几率。
3.工作稳定，因为其本身抗负载能力很强，所以稳定性高也是顺理成章的事，另外各种lvs都有完整的双机热备方案，所以一点不用担心均衡器本身会出什么问题，节点出现故障的话，lvs会自动判别，所以系统整体是非常稳定的。
4.无流量，lvs仅仅分发请求，而流量并不从它本身出去，所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
5.lvs基本上能支持所有应用，因为lvs工作在第4层，所以它可以对几乎所有应用做负载均衡，包括http、数据库、聊天室等。
二、nginx和lvs作对比的结果：
1.nginx工作在网络的第7层，所以它可以针对http应用本身来做分流策略，比如针对域名、目录结构等，相比之下lvs并不具备这样的功能，所以nginx单凭这点可以利用的场合就远多于lvs了；但nginx有用的这些功能使其可调整度要高于lvs，所以经常要去触碰，由lvs的第2条优点来看，触碰多了，人为出现问题的几率也就会大。
2.nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。另外注意，lvs需要向托管商至少申请多于一个ip来做visual ip。
3.nginx安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。lvs的安装和配置、测试就要花比较长的时间，因为同上所述，lvs对网络依赖性比较大，很多时候不能配置成功都是因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦的多。
4.nginx也同样能承受很高负载且稳定，但负载度和稳定度差lvs还有几个等级：nginx处理所有流量所以受限于机器IO和配置；本身的bug也还是难以避免的；nginx没有现成的双机热备方案，所以跑在单机上还是风险比较大，单机上的事情全都很难说。
5.nginx可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前lvs中ldirectd也能支持针对服务器内部的情况来监控，但lvs的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障，nginx会把上传切到另一台服务器重新处理，而lvs就直接断掉了。
三、两者配合使用：
nginx用来做http的反向代理，能够upsteam实现http请求的多种方式的均衡转发。由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。这可以最大程度的提高系统的请求成功率。
lvs采用的是同步请求转发的策略。这里说一下同步转发和异步转发的区别。同步转发是在lvs服务器接收到请求之后，立即redirect到一个后端服务器，由客户端直接和后端服务器建立连接。异步转发是nginx在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由nginx返回给客户端。
进一步来说：当做为负载均衡服务器的nginx和lvs处理相同的请求时，所有的请求和响应流量都会经过nginx；但是使用lvs时，仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回。
也就是，当作为后端的服务器规模庞大时，nginx的网络带宽就成了一个巨大的瓶颈。
但是仅仅使用lvs作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了。但是如果在lvs的后端在添加一层nginx（多个），每个nginx后端再有几台应用服务器，那么结合两者的优势，既能避免单nginx的流量集中瓶颈，又能避免单lvs时一锤子买卖的问题。
