TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
这里将介绍TCP报头的特性以及TCP报头各个字段的含义
.工作在传输层面向连接协议
.全双工协议
.半关闭
.错误检查
.将数据打包成段，排序
.确认机制
.数据恢复，重传
.流量控制，滑动窗口
.拥塞控制，慢启动和拥塞避免算法
.源端口、目标端口 ：计算机上的进程要和其他进程通信是要通过计算机端口的，而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的，可推算计算机的端口个数为2^16个
. 序列号 ：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个字节，就会出现序列号回绕，再次从0 开始
. 确认号 ：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。也就是告诉发送发：我希望你（指发送方）下次发送的数据的第一个字节数据的编号是这个确认号
. 数据偏移 ：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可变的选项部分，需要指定这个TCP报文段到底有多长。它指出TCP 报文段的数据起始处距离TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节
. URG ：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效
. ACK ：表示是否前面的确认号字段是否有效。ACK=1，表示有效。只有当ACK=1时，前面的确认号字段才有效。TCP规定，连接建立后，ACK必须为1,带ACK标志的TCP报文段称为确认报文段
. PSH ：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序不将接收到的数据读走，就会一直停留在TCP接收缓冲区中
. RST ：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST标志的TCP报文段称为复位报文段
. SYN ：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段
. FIN ：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段
. 窗口大小 ：表示现在充许对方发送的数据量，也就是告诉对方，从本报文段的确认号开始允许对方发送的数据量
. 校验和 ：提供额外的可靠性
. 紧急指针 ：标记紧急数据在数据字段中的位置
. 选项部分 ：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表示，选项部分最长为：(2^4-1)*4-20=40字节
常见选项 ：
.最大报文段长度：MaxiumSegment Size，MSS
.窗口扩大：Windows Scaling
.时间戳：Timestamps
.a 最大报文段长度
指明自己期望对方发送TCP报文段时那个数据字段的长度。默认是536字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双方都把自己能够支持的MSS接入这一字段。MSS只出现在SYN报文中。即：MSS出现在SYN=1的报文段中
.b 窗口扩大
为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产
生（如卫星通信），需要更大的窗口来满足性能和吞吐率，所以产生了这个窗口扩大选项
.c 时间戳
可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中，当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文
2.3 TCP协议PORT
.传输层通过port号，确定应用层协议
.Port number:
. tcp ：0-65535,传输控制协议，面向连接的协议；通信前需要建立虚拟链路；结束后拆除链路.
. udp ：0-65535,User Datagram Protocol，无连接的协议.
. IANA :互联网数字分配机构（负责域名，数字资源，协议分配）
0-1023：系统端口或特权端口(仅管理员可用) ，众所周知，永久的分配给固定的系统应用使用，22/tcp(ssh), 80/tcp(http), 443/tcp(https)
1024-49151：用户端口或注册端口，但要求并不严格，分配给程序注册为某应用使用，1433/tcp(SqlServer)，1521/tcp(oracle),
3306/tcp(mysql),11211/tcp/udp(memcached)
49152-65535：动态端口或私有端口，客户端程序随机使用的端口
其范围的定义：/proc/sys/net/ipv4/ip_local_port_range
有限状态机，（英语：Finite-state machine, FSM），又称有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
常见的计算机就是使用有限状态机作为计算模型的：对于内存的不同状态，CPU通过读取内存值进行计算，更新内存中的状态。CPU还通过消息总线接受外部输入设备（如键盘、鼠标）的指令，计算后更改内存中的状态，计算结果输出到外部显示设备（如显示器），以及持久化存储在硬盘。
TCP协议也存在有限状态机的概念，TCP 协议的 *** 作可以使用一个具有 11 种状态的有限状态机来表示
.CLOSED 没有任何连接状态
.LISTEN 侦听状态，等待来自远方TCP端口的连接请求
.SYN-SENT 在发送连接请求后，等待对方确认
.SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认
.ESTABLISHED 代表传输连接建立，双方进入数据传送状态
.FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认
.FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求
.TIME-WAIT 完成双向传输连接关闭，等待所有分组消失
.CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认
.LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失
.CLOSING 双方同时尝试关闭传输连接，等待对方确认
.客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服务器发送一个同步报文段，使连接转移到SYN_SENT状态。
.此后connect系统调用可能因为如下两个原因失败返回：
.1、如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一个复位报文段，connect调用失败。
.2、如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段，则connect调用失败。
.connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收到服务器的同步报文段和确认，则connect调用成功返回，连接转移至ESTABLISHED状态
.当客户端执行主动关闭时，它将向服务器发送一个结束报文段FIN，同时连接进入FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段，则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态
.客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文段（而不是先收到确认报文段，再收到结束报文段）
注意，客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收服务端的报文，该报文会有三种可能：
a 只有服务端的ACK，只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续2MSL(TCP报文段在网络中的最大生存时间,RFC 1122标准的建议值是2min).客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失
b 只有服务端的FIN，回应一个ACK给服务端，进入CLOSING状态，然后接收到服务端的ACK时，进入TIME_WAIT状态
c 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态
.收到服务器ACK后，客户端处于FIN_WAIT_2状态，此时需要等待服务器发送结束报文段，才能转移至TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿进程类似）。
.Linux为了防止孤儿连接长时间存留在内核中，定义了两个内核参数：
./proc/sys/net/ipv4/tcp_max_orphans 指定内核能接管的孤儿连接数目
./proc/sys/net/ipv4/tcp_fin_timeout指定孤儿连接在内核中生存的时间
TCP协议中的三次握手和四次挥手
客户机端的三次握手和四次挥手
服务器端的三次握手和四次挥手
1 client 首先发送一个连接试探，此时ACK=0,表示确认号无效，SYN=1表示这是一个请求连接或连接接受报文，同时表示这个数据包不携带数据，seq=x表示此时client自己数据的初始序号是x,这时候client进入syn_sent状态，表示客户端等等服务器的回复
2 server 监听到连接请求报文后，如同意建立连接，则向client发送确认，将TCP报文首部的SYN和ACK都置为1，因为client上一个请求连接的报文中seq=x,所以服务器端这次就发ack=x+1,表示服务器端希望客户端下一个报文段的第一个数据字节序号是x+1，同时表示x为止的所有数据都已经正确收到了，其中，此时服务器端发送seq=y表示server自己的初始序号是y，这时服务器进入了SYN_RCVD状态，表示服务器已经收到了客户端的请求，等待client的确认。
3 client收到确认后还要再次给服务器端发送确认，同时携带要发给server的数据。ACK=1表示确认号ack=y+1有效，client这时的序号seq为x+1
一旦client确认后，这个TCP连接的client 和 server 都直接进入到established状态，可以发起http请求了
4.2 四次挥手详解
第一次挥手：client向server，发送FIN报文段，表示关闭数据传送，此时ACK=0,seq=u,表示客户端此时数据的报文序号是u，此时，client进入FIN_WAIT_1状态，表示没有数据要传输了
第二次挥手：server收到FIN报文段后进入CLOSE_WAIT状态（被动关闭），然后发送ACK确认，表示同意你关闭请求了，主机到主机的数据链路关闭，同时发送seq=v,表示此时server端的数据包字节序号是v,ack=u+1,表示希望client发送的下一个包的序号是u+1,表示确认了序号u之前的包都已经收到，客户端收到server的ACK报文后，进入FIN_WAIT_2状态
第三次挥手：server等待client发送完数据，发送FIN=1，ACK=1到client请求关闭，server进入LAST_ACK状态。此时发送的seq有变化，因为上一个ACK的后server端可能又发送了一些数据，说以数据字节序号发送了变化，为w,但是ack还是保持不变
第四次挥手：client收到server发送的FIN后，回复ACK确认到server，client进入TIME_WAIT状态。发送ack=w+1,表示希望服务器下个发送的报文的字节序号是w+1,确认了服务器之前发送的w字节都已经正确收到，发送seq=u+1表示当前client的字节序号是u+1.server收到client的ACK后就关闭连接了，状态为CLOSED。client等待2MSL，仍然没有收到server的回复，说明server已经正常关闭了，client关闭连接。
其中，MSL（Maximum Segment Lifetime）：报文最大生存时间，是任何报文段被丢弃前在网络内的最长时间。当client回复server的FIN后，等待(2-4分钟)，即使两端的应用程序结束。
TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态的原因是如果client直接进入CLOSED状态，由于IP协议不可靠性或网络问题，导致client最后发出的ACK报文未被server接收到，那么server在超时后继续向client重新发送FIN，而client已经关闭，那么找不到向client发送FIN的连接，server这时收到RST并把错误报告给高层，不符合TCP协议的可靠性特点。如果client直接进入CLOSED状态，而server还有数据滞留在网络中，当有一个新连接的端口和原来server的相同，那么当原来滞留的数据到达后，client认为这些数据是新连接的。等待2MSL确保本次连接所有数据消失。
当客户端等待2MSL后服务器端没有再次发送确认的报文后，client认为该次断开连接已经正常结束，client进入closed状态。四次挥手正式结束
tcp 协议 是互联网中最常用的协议 ， 开发人员基本上天天和它打交道，对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨
客户端：收到 ack 后 分配连接资源。 发送数据
服务器 : 收到 syn 后立即 分配连接资源
客户端：收到ACK， 立即分配资源
服务器：收到ACK， 立即分配资源
既然三次握手也不是100%可靠， 那四次，五次，六次。。。呢? 其实都一样，不管多少次都有丢包问题。
client 只发送一个 SYN， server 分配一个tcb， 放入syn队列中。 这时候连接叫 半连接 状态；如果server 收不到 client 的ACK， 会不停重试 发送 ACK-SYN 给client 。重试间隔 为 2 的 N 次方 叠加（2^0 , 2^1, 2^2 ....）；直至超时才释放syn队列中的这个 TCB
在半连接状态下， 一方面会占用队列配额资源，另一方面占用内存资源。我们应该让半连接状态存在时间尽可能的小
当client 向一个未打开的端口发起连接请求时，会收到一个RST回复包
当listen 的 backlog 和 somaxconn 都设置了得时候， 取两者min值
Recv-Q 是accept 队列当前个数， Send-Q 设置最大值
这种SYN洪水攻击是一种常见攻击方式，就是利用半连接队列特性，占满syn 队列的 资源，导致 client无法连接上。
解决方案:
为什么不像握手那样合并成三次挥手? 因为和刚开始连接情况，连接是大家都从0开始， 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据，不能丢弃。 所以需要分开。事实可能是这样
当然，在没有待发数据，并且允许 Delay ACK 情况下， FIN-ACK合并还是非常常见的事情，这是三次挥手是可以的。
同上
CLOSE_WAIT 是被动关闭方才有的状态 。
被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN， 收到ACK ] 期间的状态为 CLOSE_WAIT， 这个状态仍然能发送数据。 我们叫做 半关闭 , 下面用个例子来分析:
这个是我实际生产环境碰到的一个问题，长连接会话场景，server端收到client的rpc call 请求1，处理发现请求包有问题，就强制关闭结束这次会话， 但是 因为client 发送 第二次请求之前，并没有去调用recv，所以并不知道 这个连接被server关闭， 继续发送 请求2 ， 此时是半连接，能够成功发送到对端机器，但是recv结果后，遇到连接已经关闭错误。
如果 client 和 server 恰好同时发起关闭连接。这种情况下，两边都是主动连接，都会进入 TIME_WAIT状态
1、 被动关闭方在LAST_ACK状态(已经发送FIN)，等待主动关闭方的ACK应答，但是 ACK丢掉， 主动方并不知道，以为成功关闭。因为没有TIME_WAIT等待时间，可以立即创建新的连接， 新的连接发送SYN到前面那个未关闭的被动方，被动方认为是收到错误指令，会发送RST。导致创建连接失败。
2、 主动关闭方断开连接，如果没有TIME_WAIT等待时间，可以马上建立一个新的连接，但是前一个已经断开连接的，延迟到达的数据包。 被新建的连接接收，如果刚好seq 和 ack字段 都正确, seq在滑动窗口范围内(只能说机率非常小，但是还是有可能会发生)，会被当成正确数据包接收，导致数据串包。 如果不在window范围内，则没有影响( 发送一个确认报文（ack 字段为期望ack的序列号，seq为当前发送序列号），状态变保持原样)
TIME_WAIT 问题比较比较常见，特别是CGI机器，并发量高，大量连接后段服务的tcp短连接。因此也衍生出了多种手段解决。虽然每种方法解决不是那么完美，但是带来的好处一般多于坏处。还是在日常工作中会使用。
1、改短TIME_WAIT 等待时间
这个是第一个想到的解决办法，既然等待时间太长，就改成时间短，快速回收端口。但是实际情况往往不乐观，对于并发的机器，你改多短才能保证回收速度呢，有时候几秒钟就几万个连接。太短的话，就会有前面两种问题小概率发生。
2、禁止Socket lingering
这种情况下关闭连接，会直接抛弃缓冲区中待发送的数据，会发送一个RST给对端，相当于直接抛弃TIME_WAIT， 进入CLOSE状态。同样因为取消了 TIME_WAIT 状态，会有前面两种问题小概率发生。
3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse选项是 从 TIME_WAIT 状态的队列中，选取条件：1、remote 的 ip 和端口相同， 2、选取一个时间戳小于当前时间戳； 用来解决端口不足的尴尬。
现在端口可以复用了，看看如何面对前面TIME_WAIT 那两种问题。 我们仔细回顾用一下前面两种问题。 都是在新建连接中收到老连接的包导致的问题 ， 那么如果我能在新连接中识别出此包为非法包，是不是就可以丢掉这些无用包，解决问题呢。
需要实现这些功能，需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候，在ACK应答中除了TCP包头中带自己此时发送的时间戳，并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:
那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的
4、tcp_tw_recycle
tcp_tw_recycle 也是借助 timestamp机制。顾名思义， tcp_tw_reuse 是复用 端口，并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量，还是 几千几万个，这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。
tcp_tw_recycle 工作原理是。
给大家分享一些Linux面试题的笔记，从负载均衡、nginx、MySQL、redis、kafka、zabbix、k8s等方面拆解 Linux 知识点。用来对个人技术点进行查漏补缺。目录：
1. 磁盘使用率检测（用shell脚本）
2. LVS 负载均衡有哪些策略？
3. 谈谈你对LVS的理解？
4. 负载均衡的原理是什么？
5. LVS由哪两部分组成的？
6. 与lvs相关的术语有哪些？
7. LVS-NAT模式的原理
8. LVS-NAT模型的特性
9. LVS-DR模式原理
10. LVS-DR模型的特性
11. LVS三种负载均衡模式的比较
12. LVS的负载调度算法
13. LVS与nginx的区别
14. 负载均衡的作用有哪些？
15. nginx实现负载均衡的分发策略
16. keepalived 是什么？
17. 你是如何理解VRRP协议的
18. keepalived的工作原理？
19. 出现脑裂的原因
20. 如何解决keepalived脑裂问题？
21. zabbix如何监控脑裂？
22. nginx做负载均衡实现的策略有哪些
23. nginx做负载均衡用到哪些模块
24. 负载均衡有哪些实现方式
25. nginx如何实现四层负载？
26. 你知道的web服务有哪些？
27. 为什么要用nginx
28 . nginx的性能为什么比apache高？
29 . epoll的组成
30 . nginx和apache的区别
31. Tomcat作为web的优缺点？
32. tomcat的三个端口及作用
33. fastcgi 和cgi的区别
34. nginx常用的命令
35. 什么是反向代理，什么是正向代理，以及区别？
36. Squid、Varinsh、Nginx 有什么区别？
37. nginx是如何处理http请求的
38. nginx虚拟主机有哪些？
39. nginx怎么实现后端服务的健康检查
40. apache中的Worker 和 Prefork 之间的区别是什么?
41. Tomcat缺省端口是多少，怎么修改
42. Tomcat的工作模式是什么？
43. Web请求在Tomcat请求中的请求流程是怎么样的?
44. 怎么监控Tomcat的内存使用情况
45. nginx的优化你都做过哪些？
46. Tomcat你做过哪些优化
47. nginx的session不同步怎么办
48. nginx的常用模块有哪些？
49. nginx常用状态码
50. 访问一个网站的流程
51. 三次握手，四次挥手
52. 什么是动态资源，什么是静态资源
53. worker支持的最大并发数是什么？
54. Tomcat和Resin有什么区别，工作中你怎么选择？
55. 什么叫网站灰度发布？56.. 统计ip访问情况，要求分析nginx访问日志，找出访问页面数量在前十位的ip
57. nginx各个版本的区别
58. nginx最新版本
59. 关于nginx access模块的面试题
60. nginx默认配置文件
61. location的规则
62. 配置nginx防盗链
63. drop，delete和truncate删除数据的区别？
64. MySQL主从原理
65. MySQL主从复制存在哪些问题？
66. MySQL复制的方法
67. 主从延迟产生的原因及解决方案？
68. 判断主从延迟的方法
69. MySQL忘记root密码如何找回
70. MySQL的数据备份方式
71. innodb的特性
72. varchar(100) 和varchar(200）的区别
73. MySQL主要的索引类型
74. 请说出非关系型数据库的典型产品、特点及应用场景？
75. 如何加强MySQL安全，请给出可行的具体措施？
76. Binlog工作模式有哪些？各什么特点，企业如何选择？
77. 生产一主多从从库宕机，如何手工恢复？
78. MySQL中MyISAM与InnoDB的区别，至少5点
79. 网站打开慢，请给出排查方法，如是数据库慢导致，如何排查并解决，请分析并举例？
80. xtrabackup的备份，增量备份及恢复的工作原理
81.误执行drop数据，如何通过xtrabackup恢复？
82. 如何做主从数据一致性校验？
83. MySQL有多少日志
84. MySQL binlog的几种日志录入格式以及区别
85. MySQL数据库cpu飙升到500%的话他怎么处理？
86. redis是单线程还是多线程？
87. redis常用的版本是？
88. redis 的使用场景？
89. redis常见的数据结构
90. redis持久化你们怎么做的？
91. 主从复制实现的原理
92. redis哨兵模式原理
93. memcache和redis的区别
94. redis有哪些架构模式？
95. 缓存雪崩？
96. 缓存穿透
97. 缓存击穿
98. redis为什么这么快
99. memcache有哪些应用场景
100. memcache 服务特点及工作原理
101. memcached是如何做身份验证的？
102. mongoDB是什么？
103. mongodb的优势
104. mongodb使用场景
105. kafka 中的ISR，AR代表什么，ISR伸缩又代表什么
106.kafka中的broker 是干什么的
107. kafka中的 zookeeper 起到什么作用，可以不用zookeeper么
108. kafka follower如何与leader同步数据
109. kafka 为什么那么快
110. Kafka中的消息是否会丢失和重复消费？
111. 为什么Kafka不支持读写分离？
112. 什么是消费者组?
113. Kafka 中的术语114. kafka适用于哪些场景
115. Kafka写入流程：
116. zabbix有哪些组件
117. zabbix的两种监控模式
118. 一个监控系统的运行流程
119. zabbix的工作进程
120. zabbix常用术语
121. zabbix自定义发现是怎么做的？
122. 微信报警
123. zabbix客户端如何批量安装
124. zabbix分布式是如何做的
125. zabbix proxy 的使用场景
126. prometheus工作原理
127. prometheus组件
128. ELK工作流程
129. logstash的输入源有哪些？
130. logstash的架构
131. ELK相关的概念
132. es常用的插件
134. zabbix你都监控哪些参数
135. MySQL同步和半同步
136. CI/CD
137 K8S监控指标
138. k8s是怎么做日志监控的
139. 【运维面试】k8s中service和ingress的区别
140. k8s组件的梳理
141. 关于tcp/IP协议
142. 谈谈你对CDN的理解
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）