中间件(apache、nginx、tomcat)你们是怎么监控的？
监控tomcat
监控tomcat可以通过jdk中自带的jconsole或者 java VisualVM来进行监控。更可以自己写系统来监控。
知道了监控工具，那么怎么才能实现监控呢？怎么做呢？
如果想远程监控tomcat，那么需要配置tomcat了：
1.在catalina.bat中的rem Guess CATALINA_HOME if not defined后面添加：
set JAVA_OPTS=-Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
这句代表的是：远程监控的端口，不开启ssl，不开启验证
重启tomcat，然后便可以使用jconsole或java VisualVM去远程监控tomcat了。
.监控nginx
监控nginx通过网页来监控。具体配置是在nginx.conf配置文件中配置：
location /nginx_status {
stub_status on;
access_log off;
allow 192.168.1.100; #访问IP,若为all，代表所有都可以访问#
deny all;
}
192.168.1.100地址的电脑可以直接访问nginx_status这个页面，将可以看到
Activeconnections-----活跃的连接数量
server---------处理的连接数
accepts -------成功创建的握手数量
handledRequests -------处理的请求的数量
Reading ------读取客户端的连接数
Writing ------响应数据到客户端的数量
Waiting -------已经处理完正在等候下一次请求指令的驻留连接（驻留连接）
Apache 监控
一、如何获取apache监控参数
Vi /etc/httpd/conf/httpd.conf
SetHandler 加载某个模块
order 先执行deny
重启apache 项目是实时读取的，但自身配置不是，所以需要重启
浏览器输入：http://ip/server-status
Tomcat中查看JVM内存使用情况
1 进入tomcat后台（manager/status）可以查看
2 可以用jdk自带的工具
C:Program FilesJavajdk1.8.0_221in
工具 jvisualvm.exe
HTTP代理
我们正常的HTTP通信是这样的：
- 客户端先通过TCP与服务器建立一条连接
- 连接建立完成后，客户端向服务器发送请求（比如GET /hello.html HTTP/1.1，意为我想要取得服务器根目录/下的hello.html文件）
- 服务器接收到客户端发来的请求，找到所请求的文件，并通过原来的连接发回去。（接上条的例子，找到根目录/下的hello.html文件，并发送HTTP/1.1 200 OK，代表找到了这个文件，现在我就发送给你）
- 客户端接收到服务器传过来的文件，并用浏览器渲染出来给用户看（通过html/css以及js等把传回来的文本内容可视化，展示在屏幕上）
但我现在可能不想要按照人家的规定来访问，比如说我想访问根目录下的fxxk.html文件，然而又没办法直接跳转过去，那怎么办？这时候就轮到代理服务器出场了（当然这种需求改个url就可以了，这里只是举个栗子）：
- 假设我们有一个受我们控制的代理服务器A。
- 客户端先与A建立TCP连接，然后告诉代理服务器A我想要访问某某网址根目录下的hello.html
- 代理服务器A收到请求，这时我们可以修改请求的内容，比如把hello.html改成fxxk.html。再建立一条到客户端指定网址的TCP连接，把这个新的请求的通过这个新连接发送过去。
- 这样在服务器看来，就好像是客户端请求了/fxxk.html一样，然后把所请求的内容返回回去，代理服务器再把内容通过第一条连接送回客户端…
总结一下，这次请求中，HTTP代理共建立了两条TCP连接：一条是客户端到代理服务器的，另一条是代理服务器到HTTP服务器的。这时代理服务器就好像一个中间商，可以看到你们双方交互的所有内容，并且也可以邪恶地更改这些内容。
顺便一说，代理https也是一样建立了这两个连接。客户端与代理服务器建立https连接，代理服务器又与HTTP服务器建立https连接，所以表面上我们是与代理服务器建立https连接的，这也是为什么在进行这种代理的时候需要导入代理服务器的https证书
HTTP与HTTPS有什么区别？
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
HTTPS和HTTP的区别主要如下：
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP协议的8种请求类型
Options：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
Head：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
Get：向特定的资源发出请求。
Post：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。
Put：向指定资源位置上传其最新内容。
Delete：请求服务器删除Request-URI所标识的资源。
Trace：回显服务器收到的请求，主要用于测试或诊断。
Connect：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
HTTP请求头（Request Headers）包含内容：
Accept : 指定客户端能够接收的内容类型，内容类型中的先后次序表示客户端接收的先后次序。在Ajax代码中，可以使用XMLHttpRequest 对象中setRequestHeader函数方法来动态设置这些Header信息。
Accept-Encoding : 指定客户端浏览器可以支持的web服务器返回内容压缩编码类型
Accept-Language : 指定HTTP客户端浏览器用来展示返回信息所优先选择的语言
Host: 接受请求的服务器地址，可以是IP端口号，也可以是域名
User-Agent: 发送请求的应用程序名称
Connection ： 表示是否需要持久连接，指定与连接相关的属性：如connection:Keep-Alive
Connec-Length : 请求头的长度。
Connect-Type : 显示此HTTP请求提交的内容类型。一般只有post提交时才需要设置该属性
cookie : 浏览器端cookie。
Hose : 客户端地址
Origin : 目标地址
Referer : 包含一个URL，用户从该URL代表的页面出发访问当前请求的页面
x－Requested-With : 是否为同步请求 ，如果为XMLHttpRequest，则为 Ajax 异步请求。如果为null则为传统同步请求
HTTP响应头（Response Header）信息
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括实现特定的指令，它可应用到响应链上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| refresh | 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） |
Refresh: 5; url= http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
HTTP状态码：
2xx 成功
200 正常；请求已完成。
201 正常；紧接 POST 命令。
202 正常；已接受用于处理，但处理尚未完成。
203 正常；部分信息 — 返回的信息只是一部分。
204 正常；无响应 — 已接收请求，但不存在要回送的信息。
3xx 重定向
301 已移动 — 请求的数据具有新的位置且更改是永久的。
302 已找到 — 请求的数据临时具有不同 URI。
303 请参阅其它 — 可在另一 URI 下找到对请求的响应，且应使用 GET 方法检索此响应。
304 未修改 — 未按预期修改文档。
305 使用代理 — 必须通过位置字段中提供的代理来访问请求的资源。
306 未使用 — 不再使用；保留此代码以便将来使用。
4xx 客户机中出现的错误
400 错误请求 — 请求中有语法问题，或不能满足请求。
401 未授权 — 未授权客户机访问数据。
402 需要付款 — 表示计费系统已有效。
403 禁止 — 即使有授权也不需要访问。
404 找不到 — 服务器找不到给定的资源；文档不存在。
407 代理认证请求 — 客户机首先必须使用代理认证自身。
415 介质类型不受支持 — 服务器拒绝服务请求，因为不支持请求实体的格式。
5xx 服务器中出现的错误
500 内部错误 — 因为意外情况，服务器不能完成请求。
501 未执行 — 服务器不支持请求的工具。
502 错误网关 — 服务器接收到来自上游服务器的无效响应。
503 无法获得服务 — 由于临时过载或维护，服务器无法处理请求。
给你任意指定生活中的一件物品，你会怎么测试？
以后碰到这种题型，不管三七二十一，都可以这么来回复面试官：
我不知道这个具体需求，但是我了解基本功能使用
所以我会从以下几个方面来分析
首先从功能测试来考虑的话，balabla；
界面考虑的话，balabla，…，
压力测试考虑的话，balabala；
TCP/IP协议
简单描述下TCP协议
TCP：传输控制协议，是传输层通信协议。它有面向连接、可靠、字节流传输等特点
TCP建立连接时，需要三次握手协议
TCP三次握手的过程如下：
客户端发送SYN报文给服务端，进入SYN_SEND（SEQ=X）状态
服务端收到SYN报文，回应一个SYN（SEQ=Y） ACK(ACK=X+1)报文，进入SYN_RECV状态
客户端收到服务端的SYN报文，回应一个ACK（ACK=Y+1）报文，开始建立连接
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
计算机网络体系结构分层：
cookie与session的区别：
1、cookie数据存放在客户的浏览器上，session数据放在服务器上。
2、cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗
考虑到安全应当使用session。
3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用cookie。
4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。
5、所以个人建议：
将登陆信息等重要信息存放为session
其他信息如果需要保留，可以放在cookie中
get和post区别是什么？
答：POST和GET都是向服务器提交数据，并且都会从服务器获取数据。
区别：
（1）传送方式：get通过地址栏传输，post通过报文传输
（2）传送长度：get参数有长度限制（受限于url长度），而post无限制
（3）GET产生一个TCP数据包（对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据），POST产生两个TCP数据包（对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok返回数据）
（4）get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留
（5）在做数据查询时，建议用GET方式；而在做数据添加、修改或删除时，建议用post方式
TCP与UDP的区别是什么？
TCP传输控制协议 。UDP用户数据报协议
TCP对资源要求比较多，UDP对资源要求比较少
TCP可以保证数据的正确性，UDP有可能会丢包
TCP可以保证数据的顺序，UDP不会保证
如何分析是前段还是后端的问题
浏览器都有自带的抓包插件，F12开启抓包。
我们在分析一个系统bug来自于前端还是后台时，最有用的两个是调试器提供的两个标签，这两个标签底下都记录了一些数据，一个是console，一个network。
console:记录了前端js执行的情况，以及前端向服务器发出去的所有http请求信息，，如果有js错误可以在控制台下看到，同样如果发送到后台的某个http请求没有得到服务器正常响应，也能看到他的状态信息。
network:记录了前端往服务器发的所有的http请求信息，而且每个请求发送了什么数据，服务器是否正常响应了请求，如果响应了，响应回来的状态码是什么，响应数据是什么都可以在“网络”标签下看到
怎么分清前后端bug？
1）请求接口URL是否正确：如果请求接口URL不正确，为前端Bug；
2）http请求中的参数是否正确：如果http请求中的参数不正确，为前端Bug；
3）如果接口URL和参数都正确，查看响应内容是否正确：如果这种情况下响应内容不正确，则为后端Bug。
怎么定位前后端bug？
说明 1 : js是静态资源，会缓存到浏览器的客户端，为了清除缓存，需要强制刷新页面，所有的东西强制的到服务器上拿一下
说明 2 ：http状态码，服务器响应的一个状态码，标记不同的处理结果
说明 3 ：浏览器是如何同远程服务器交互的
前端页面的数据 -> js收集->js发起接口请求->服务器响应请求，返回数据->前端页面js处理数据->页面再展示出来
说明4 : 前端请求一个接口，服务器怎样处理？根据接口地址映射到对应的处理函数，函数处理完后就会返回数据
js报错，直接导致前端没有发起接口请求
400 ： 客户端提交的参数不合格，必须提供的参数或字段没有提供
401 : 没有登录的情况下，访问需要登录的接口
403 ：没有权限
404： not found，js错误属于前端报错，一般是由于url地址写错，或者url地址没错，但是后面接口名和文件名改了
500 : 服务器内部异常
502 : 服务器错误，可能ngix没配置好
5xx均为服务器报错，直接提bug好了
最后一条，发现bug了，要先看看是不是自己的原因，先把案发现场保留好，然后判断前后端bug+尝试复现
怎么定位后端bug？
（1）查看报错日志
查看报错日志，通过日志分析，需要有一定的经验，并且有一定的代码基础，才能更好地定位问题。
（2）查看数据库的数据
了解所测功能的数据表结构，测试过程中，查看数据库的数据，确认数据的正确性。
（3）查看缓存（如Memcache、apc、redis等缓存）是否正确
1.前台bug注意以下三个方面：
1）网站前台权限控制：没有权限的用户不能直接输入url的方式来进行访问，必须进行登录。以后涉及到权限的测试，一定不能漏掉url的方式也需要验证一下。而在单个页面进行W3C测试时则需要去掉该权限控制。
2）网站前台的title，对于这个也很容易忽视。进入到不同的功能页面，title显示应该是有，并且要和你进入的页面一致。title就是在浏览器最左上角看到的那些文字
3）http和https的注意点：https是一种安全链接，需要证书，所以在系统中客户会要求某些关键的地方希望加上这种安全连接，那么此时你需要注意的是：对于不需要的安全链接的地方千万也要去重点测试，有些开发会很容易忽略这一点。要打开HTTPS开头的网站，前提是该网站安装了SSL证书，只有安装了SSL证书的网站，并且开启了443端口，你才可以通过HTTPS加密协议无访问；如果没有则不能访问。比如在某个网站http协议后面加个s去访问，看能否访问成功，能成功，会显示绿色安全小锁，否则就不能访问。
2.后台bug定位：根据后台日志文件
系统使用secureCRT进行日志获取，或者服务器控制方面的操作（关闭和重启）
重启的一般情况：
1）热部署 （新增部分功能，或者修改部分bug)
2）发布新版本 （整个系统）
3）内存溢出，此时重启服务器即可