（以下内容是我从网上查找整理得到的...红色标注为面试提及的，但不一定是我整理的内容）
TCP/IP
简述TCP三次握手的过程？
答：在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态。第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据简版：首先A向B发SYN（同步请求），然后B回复SYN+ACK（同步请求应答），最后A回复ACK确认，这样TCP的一次连接（三次握手）的过程就建立了。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
这是因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Client端发送FIN报文仅仅表示它不再发送数据了但是还能接收数据，Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
HTTP
https://blog.51cto.com/13570193/2108347
SHELL
https://www.cnblogs.com/gala1021/p/8519456.html
https://www.jb51.net/article/135168.htm
常用命令
top(能了解top后的每一个字段意思)
grep,sed,awk
Apache
https://blog.csdn.net/keda8997110/article/details/19696337
Tomcat
https://blog.csdn.net/xlgen157387/article/details/79006434
Tomcat工作模式？
Tomcat是一个JSP/Servlet容器。其作为Servlet容器，有三种工作模式：独立的Servlet容器、进程内的Servlet容器和进程外的Servlet容器。
进入Tomcat的请求可以根据Tomcat的工作模式分为如下两类：
Tomcat作为应用程序服务器：请求来自于前端的web服务器，这可能是Apache, IIS, Nginx等；
Tomcat作为独立服务器：请求来自于web浏览器；
Haproxy
简介
HAproxy：HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中，同时可以保护你的web服务器不被暴露到网络上。
特点
1）HAProxy 也是支持虚拟主机的。
2）HAProxy 的优点能够补充 Nginx 的一些缺点，比如支持 Session 的保持，Cookie的引导；同时支持通过获取指定的 url 来检测后端服务器的状态。
3）HAProxy 跟 LVS 类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy 会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的。
4）HAProxy 支持 TCP 协议的负载均衡转发，可以对 MySQL 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，大家可以用 LVS+Keepalived 对 MySQL主从做负载均衡。
负载均衡算法
Haproxy有8种负载均衡算法（balance），分别如下：
1.balance roundrobin # 轮询，软负载均衡基本都具备这种算法
2.balance static-rr # 根据权重，建议使用
3.balance leastconn # 最少连接者先处理，建议使用
4.balance source # 根据请求源IP，建议使用
5.balance uri # 根据请求的URI
6.balance url_param，# 根据请求的URl参数'balance url_param' requires an URL parameter name
7.balance hdr(name) # 根据HTTP请求头来锁定每一次HTTP请求
8.balance rdp-cookie(name) # 根据据cookie(name)来锁定并哈希每一次TCP请求
会话保持
由于负载请求分发到不同服务器，可能导致Session会话不同步的问题，若想实现会话共享或保持，可采用如下3种方式：
1.用户IP 识别
haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上（类似于nginx 的IP hash 指令）
配置指令:balance source
2.Cookie 识别
haproxy 将WEB服务端发送给客户端的cookie中插入(或添加加前缀)haproxy定义的后端的服务器COOKIE ID。
配置指令例举:cookie SESSION_COOKIE insert indirect nocache
用firebug可以观察到用户的请求头的cookie里 有类似” Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1” SESSION_COOKIE=app1就是haproxy添加的内容
3.Session 识别
haproxy 将后端服务器产生的session和后端服务器标识存在haproxy中的一张表里。客户端请求时先查询这张表。
配置指令例举:appsession JSESSIONID len 64 timeout 5h request-learn
Keepalived
Keepalived：Keepalived是一个保证集群高可用的服务软件，用来防止单点故障，使用VRRP协议实现。在master和backup之间通过master主动降低自己的权值或者backup检测到master出现故障时，backup将会接管master的工作，继续服务。
Mysql
http://www.imooc.com/article/280936
主从、主主、性能调优、数据备份恢复
详述MySQL主从复制原理及配置主从的完整步骤
主从复制的原理如下：
主库开启binlog功能并授权从库连接主库，从库通过change master得到主库的相关同步信息,然后连接主库进行验证，主库IO线程根据从库slave线程的请求，从master.info开始记录的位置点向下开始取信息，同时把取到的位置点和最新的位置与binlog信息一同发给从库IO线程，从库将相关的sql语句存放在relay-log里面，最终从库的sql线程将relay-log里的sql语句应用到从库上，至此整个同步过程完成，之后将是无限重复上述过程
完整步骤如下：
1、主库开启binlog功能，并进行全备，将全备文件推送到从库服务器上
2、show master status\G 记录下当前的位置信息及二进制文件名
3、登陆从库恢复全备文件
4、执行change master to 语句
5、执行start slave and show slave status\G
Zabbix
Ansible、Jenkins、Gitlab
ansible
https://www.jianshu.com/p/c82737b5485c
Docker
https://blog.csdn.net/zisefeizhu/article/details/83345398
杂七杂八
假如有人反应，调取后端接口时特别慢，你会如何排查？
笔者回答：其实这种问题都没有具体答案，只是看你回答的内容与面试官契合度有多高，能不能说到他想要的点上，主要是看你排查问题的思路。我是这么说的：问清楚反应的人哪个服务应用或者页面调取哪个接口慢，叫他把页面或相关的URL发给你，首先，最直观的分析就是用浏览器按F12，看下是哪一块的内容过慢（DNS解析、网络加载、大图片、还是某个文件内容等），如果有，就对症下药去解决（图片慢就优化图片、网络慢就查看内网情况等）。其次，看后端服务的日志，其实大多数的问题看相关日志是最有效分析，最好用tail -f 跟踪一下日志，当然你也要点击测试来访问接口日志才会打出来。最后，排除sql，，找到sql去mysql执行一下，看看时间是否很久，如果很久，就要优化SQL问题了，expain一下SQL看看索引情况啥的，针对性优化。数据量太大的能分表就分表，能分库就分库。如果SQL没啥问题，那可能就是写的逻辑代码的问题了，一行行审代码，找到耗时的地方改造，优化逻辑。
当一个网站访问慢时，你怎么去优化
翻译为: 当一个网站访问慢时, 你都是怎么去查找问题,和解决问题以达到优化效果的
第一,用5分钟排除网络因素,借助工具(如pagespeed)分析页面加载过程1. 某个元素或者图片加载过慢: 具体原因具体分析
2. DNS解析时长问题: 可以通过购买解析服务, 来让自己的域名在各地DNS更多缓存
3. 网络带宽瓶颈: 考虑增加带宽
4. 网络线路波动: 考虑CDN,或者镜像站第二,要考虑到服务器问题1. 是否有服务器过载: 考虑增加硬件
2. I/O操作:数据库的频繁读写，服务器的频繁请求（包括静态文件的读取，图片的读取）等都属于I/O问题。对于数据库的问题，首先要优化SQL，存储过程等。如果单表数据量过大要考虑做分割或者运用程序来控制分表。如果请求量过大，要考虑做集群。对于服务器（静态）文件的I/O问题，则可以考虑做CDN，这样也可以解决地域性问题。对于动态文件的访问，则涉及到代码优化及负载均衡两项。
3. 具体应用优化: nginx针对访问量修改配置文件,调高Buffers 调低keep alive空连接时间等第三,安全方面1. 查看web\mail等其它服务日志,是否存在被攻击现象: 针对安全方面加固
2. 是否有其它攻击存在DDOS,WEB CC等
简述一下DNS的解析过程
解答：
1、在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。
6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。
linux系统的启动过程
1.加载BIOS
2.读取MBR
3.Boot Loader
4.加载内核
5.用户层init根据inittab文件来设定运行级别
6.init进程执行rc.sysinit
7.启动内核模块
8.执行不同运行级别的脚本程序
9.执行/etc/rc.d/rc.local
10.执行/bi/login程序，进入登陆状态
FTP的主动模式和被动模式
FTP协议有两种工作方式：PORT方式和PASV方式，中文意思为主动式和被动式。
PORT（主动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请 求，服务器接受连接，建立一条命令链路。当需要传送数据时，客户端在命令链路上用PORT 命令告诉服务器：“我打开了XX端口，你过来连接我”。于是服务器从20端口向客户端的 XX端口发送连接请求，建立一条数据链路来传送数据。
PASV（被动）方式的连接过程是：客户端向服务器的FTP端口（默认是21）发送连接请 求，服务器接受连接，建立一条命令链路。当需要传送数据时，服务器在命令链路上用PASV 命令告诉客户端：“我打开了XX端口，你过来连接我”。于是客户端向服务器的XX端口 发送连接请求，建立一条数据链路来传送数据。
从上面可以看出，两种方式的命令链路连接方法是一样的，而数据链路的建立方法就完 全不同。
汇总
https://www.linuxidc.com/Linux/2018-08/153699.htm