vlan：实现机制 分类
负载均衡技术：分类 技术（LVS keepalive vrrp nginx） 负载均衡技术
数据库：索引 存储引擎 范式 acid

网络

物理层：调制解调器，物理信号和模拟信号的转换。光猫
放大器和集成器：信号放大功能

数据链路层：交换机，通过MAC地址进行寻址。分割碰撞域
（三层交换机：同时实现二层和三层的功能，而路由器只能实现三层。从而在寻址的时候，一次路由多次交换，速度更快。原理在于，通过IP找到MAC，当第一次的使用三层交换机找到了局域网中的MAC，之后的机器如果请求这个MAC，如果是不同局域网也可能不利用IP直接MAC转发）

（VLAN：虚拟路由，分离广播域，利用MAC地址和IP地址）
路由器：IP寻址，分离广播域

所以网关既可以是三层交换机，也可以是路由器。为了保证稳定性，还有一个VRRP协议

DNS-CDN-LVS-NGINX

Vlan

虚拟局域网
参考资料
我理解为带Vlan的交换机实现路由器的功能——分离广播域
目的在于路由器成本贵性能较低
实现机制：在交换机上加红蓝口，通过vlan上的ID来区分

不同vlan通信：路由器或者三层交换机
同一vlan连接多台交换机：
1：每一个vlan id布线 麻烦
2：汇聚链接，一根线转发多个不同VLAN的通信的端口。

静态vlan
基于Mac：根据Mac地址划分为不同的vlan id
基于IP：根据IP地址划分
基于用户：则是根据交换机各端口所连的计算机上当前登录的用户，这这些用户名信息，属于OSI第四层以上的信息。

计算机中的网络接口卡(NIC)相连的IP地址
虚拟IP地址(VIP) 是一个不与特定计算机或一个计算机中的网络接口卡(NIC)相连的IP地址。
用处：VRRP

负载均衡技术

参考资料
目的：
1）减少用户等待响应的时间；
2）使得单个服务器上的访问分流，减轻负担

分类：

二层负载均衡：多个服务器有相同的VIP，当访问此VIP后，修改目的MAC地址将请求分发给不同的服务器（DR模式）
三层负载均衡：不同的IP转发给不同的服务器（NAT模式）
四层负载均衡LVS：IP地址+端口号（lvs,f5）
七层负载均衡：也称为“内容交换”，四层负载均衡加上应用层的内容比较URL(nginx,apache)

具体技术

基于DNS的负载均衡

会在DNS处进行随机解析，返回不同的服务器IP地址

F5

四层的硬件负载均衡器

LVS

IPVS 模块来实现的在负载调度器上虚拟出VIP，client需要首先访问VIP，之后负载均衡选择合适的服务器进行分配响应
CIP：client IP
DIP：负载均衡IP
RIP：server IP
VIP：虚拟IP
LVS：Linux virtual server
RS：Real Server

DR模式-数据链路层模式 ：三角传输，通过修改Mac地址实现负载均衡
仅仅修改目的MAC地址
特点：
1：路由器和服务器有相同的VIP
2：不能跨vlan
3：经过一次负载均衡路由器

NAT：不需要再在应用服务器上配置VIP。
仅仅修改目的IP地址
特点：
1：不用相同的VIP(LVS和服务器不用相同VIP)
2：不能跨vlan（原因在于仅仅改变目的地址，如果不在一个vlan将找不到LVS网关）
3：经过两次负载均衡路由器
缺点是由于这种模式修改了目的IP地址，这样如果应用服务器直接将应答包发给客户端的话，其源IP是应用服务器的IP，客户端就不会正常接收这个应答（因为会接收很多不同IP的垃圾信息），因此我们需要让流量继续回到负载均衡，负载均衡将应答包的源IP改回VIP再发到客户端，这样才可以保证正常通信

IP隧道：
Ip Tunnel模式下：
负载均衡器：不会改写请求包的IP和端口，但是会在数据包IP层外面再封装一个IP层，源地址为DIP，目的地址为RIP
真实服务器RS：将外面封装的Ip Tunnel头去掉，发现里面还有一层 IP 首部的目标地址是自己 lo 接口上的 VIP，然后处理里面实际的请求报文
特点
1：路由器和服务器有相同的VIP
2：能跨网段
3：与DR模式类似，响应包也不再经过LVS，而是直接返回给客户端。所以Ip Tunnel模式的转发效率虽然弱于DR，但是强于NAT

（分为源地址修改SNAT和目标地址修改DNAT）
FullNAT:
Fullnat主要实现的功能：
1.数据包从外部进来的时候，目标ip更换为realserver ip，源ip更换为内网local ip；
2.数据包发送出去的时候，目标ip更换为client ip，源ip更换为vip；
目的IP和源IP都修改

1：不用相同的VIP
2：可以跨网段（与NAT的不同点 解决扩展问题）
因为可以跨网段，解决单点服务问题(原因在于即修改源地址又修改目的地址)
3：经过两次负载均衡路由器
应用服务器会丢失客户端的真实IP地址。

KeepAlive

目的：LVS服务高可用方案
基于VRRP协议来实现的LVS服务高可用方案，可以利用其来避免单点故障。
一个LVS服务会有2台服务器运行Keepalived，一台为主服务器（MASTER），一台为备份服务器（BACKUP），但是对外表现为一个虚拟IP，主服务器会发送特定的消息给备份服务器，当备份服务器收不到这个消息的时候，即主服务器宕机的时候， 备份服务器就会接管虚拟IP，继续提供服务，从而保证了高可用性。Keepalived是VRRP的完美实现，因此在介绍keepalived之前，先介绍一下VRRP的原理。

VRRP

(Virtual Router Redundancy Protocol-虚拟路由冗余协议)

参考资料
1：多台设备（路由器、交换机、防火墙等）虚拟化成一台设备，然后通过配置虚拟IP地址
2：分别是：初始状态（Initialize）、活动状态（Master）、备份状态（Backup）。
Master状态下的设备：定期发送VRRP报文给backup向她说吗我还存活着
backup设备如果长时间没有收到VRRP报文，会上升为Master，多个Master会根据优先级/IP地址大小竞争谁成为Master

Nginx

反向代理

参考资料


正向代理代理的是客户端，目的是访问无法访问的资源，单个服务器
如A无法访问谷歌C，但是B能访问C，所以A委托B去访问C

反向代理代理的是服务器，目的是安全，负载均衡，多个服务器
如多个服务器C1，C2，C3，访问服务器前需要访问代理服务器B

区别在于：
是否指定目标服务器：正向代理需要明确，方向不需要
客户端是否要做设置：正向代理需要设置代理服务器的IP或者域名，而反向不需要

反向代理：
1)提高了内部服务器的安全
2)加快了对内部服务器的访问速度
增加不同的代理服务器提升访问速度
3)解决IP地址不够的问题
内部服务器不需要配置全局IP，只需要内部IP

①weight 轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx 会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。
这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率。
权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
②ip_hash：每个请求按照发起客户端的 ip 的 hash 结果进行匹配，这样的算法下一个固定 ip 地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下 Session 共享的问题。
③fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配。
响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少，它是结合了前两者的优点的一种调度算法。
④url_hash：按照访问的 URL 的 hash 结果分配请求，每个请求的 URL 会指向后端固定的某个服务器，可以在 Nginx 作为静态服务器的情况下提高缓存效率。
同样要注意 Nginx 默认不支持这种调度算法，要使用的话需要安装 Nginx 的 hash 软件包。

企业级：LVS+NGINX
LVS：高并发能力
NGINX：多种分流能力

负载均衡策略

轮循均衡(RoundRobin)
每一次来自网络的请求轮流分配给内部中的服务器，从 1 至 N 然后重新开始。
权重轮循均衡(WeightedRoundRobin)
根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。
随机均衡(Random)
把来自网络的请求随机分配给内部中的多个服务器。
权重随机均衡(WeightedRandom)
此种均衡算法类似于权重轮循算法，不过在处理请求分担时是个随机选择的过程。

响应速度均衡(ResponseTime探测时间)
负载均衡设备对内部各服务器发出一个探测请求(例如 Ping)，然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时 间，而不是客户端与服务器间的最快响应时间。
最少连接数均衡(LeastConnection)
最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在 处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡 更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如 FTP。
处理能力均衡(CPU、内存)
此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器 CPU 型号、CPU 数量、内存大小 及当前连接数等换算而成)最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层(应用层)负载均衡的情况 下。
DNS响应均衡(FlashDNS)
在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的 IP 地址并返回给客户端，则客户端将以最先收到的域名解析 IP 地址来继续请求服务，而忽略其它的 IP 地址响应。

哈希算法
一致性哈希，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
IP 地址散列(保证客户端服务器对应关系稳定)
通过管理发送方 IP 和目的地 IP 地址的散列，将来自同一发送方的分组(或发送至同一目的地的分 组)统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信时，该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处 理。
URL 散列
通过管理客户端请求 URL 信息的散列，将发送至相同 URL 的请求转发至同一服务器的算法。

Netty：非直接缓冲区 缓冲区池 串行无锁
RPC：构造 调用过程 RMI区别
http：数据返回格式 调用过程 五大特性 https加密
CDN：构造 缓存
日志：log4j
事务提交：两阶段 三阶段 paxos
zookeeper：三种组成 ZAB 两种模式

http

有状态/无状态：
不是通过知不知道发送者信息【都是建立在IP上，一定知道对方是谁】
发送者和接受者有无状态的改变
IP/UDP：无状态的改变，前后的报文没有关系
TCP：有状态的改变，三次握手四次挥手
http无Cookie：无状态的改变
http有Cookie：有状态的改变，第一次登陆未登录态，第二次登陆通过SessionID

首先，请求和相应头和都是ASCII编码，所以不会存在歧义
主要的是请求体和响应体
这两个的格式需要在content-type里进行设置
content-type:序列化方式+(charset)编码方式

通过这两个，就可以准确对数据进行解析。具体解析后的格式可以通过charles-raw进行看
通过请求头和请求行，一定是ACSII编码，所以一定能准确解析
对于请求体，需要content-type和charset分别解码和解序列化才能准确翻译

服务器返回的数据格式：
HTML:作用为显示数据
XML，JSON：存储和传输数据
HTML片段：
可以直接插入页面，不用解析
可读性高
重用性低
XML和JSON对比
1:编码 JSON
2:解码 JSON
3:体积 JSON
4:速度 JSON
1:数据的描述性 xml
2:流行度 xml
Google的Protocol Buffer：各方面优于上述
缺点在于不适合描述数据结构

http：
HTTP 是一个无状态的协议，需要cookie来保存信息

调用过程：
DNS地址解析
http://localhost.com:8080/index.html
协议名 主机名 端口号 对象路径
–> 发起TCP的3次握手建立TCP连接 -->发起http请求，发出http请求头信息，发出空白行结束–> 服务器发出响应行，发出相应信息，发出空白行结束——》浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

1、常用的HTTP方法有哪些？
GET： 请求访问
POST：传输信息
PUT：传输文件到对应URI位置
DELETE：删除对应URI位置的文件
OPTIONS：查询相应URI支持的HTTP方法
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效

2、GET方法与POST方法的区别
1:get重点在从服务器上获取资源，post重点在向服务器发送数据；
2:get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?“连接，多个请求数据间用”&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin
post将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
以上导致
Get传输的数据量小，因为受URL长度限制，但效率较高；
Post可以传输大量数据，所以上传文件时只能用Post方式；
get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
post较get安全性较高；

3、HTTP请求报文与响应报文格式
请求报文包含三部分：
a、请求行：包含HTTP版本，请求方法、请求资源的名称（URI）
b、请求首部字段（固定字段）Accept，Accept-Language等
c、请求内容实体 （get请求时，通过url传给服务器的值。post请求时，通过表单发送给服务器的值）
响应报文包含三部分：
a、状态行：包含HTTP版本、状态码、状态码的原因短语
b、响应首部字段（固定字段）
c、响应内容实体三种方式

4、常见的HTTP相应状态码
返回的状态
1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现（404）
5xx：服务器端错误–服务器未能实现合法的请求（服务器正忙）

5、HTTP1.1版本新特性
a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应
c、断点续传原理/带宽优化
例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能
文件大小1024K，已下载512K
客户端HTTP头Range=512000

d:缓存处理
整体过程可理解为：
1：发送请求前浏览器先检查本地是否有缓存，没有则直接向服务器请求资源；
2：若本地有缓存且尚未过期（根据请求头的Expires和Cache-Control）则直接取缓存，若过期则向服务端发送请求；
3：服务端收到请求后判断是否仍让客户端使用缓存
4：若以上两个缓存都没命中，则浏览器再请求服务器获取最新资源，服务器返回资源的同时设置一些上述缓存参数

步骤二：
Expires和Cache-Control：判断本地缓存是否过期

步骤三：判断服务器是否修改(缓存可能过期但是没被修改)

Last-Modified：表明请求的服务端资源上次的修改时间(单位为s，且为服务器时间）
Etag：服务端根据资源内容生成的一段标识（不唯一，通常为文件的md5或者hash值或版本号等，只要保证写入和验证时的方法一致即可）
对应header
If-Modified-Since：客户端保留的资源上次的修改时间
If-None-Match：客户端保留的上次获取到的的Etag

浏览器向服务端发送请求时，若上一次的缓存中有Last-Modified或Etag字段则在request header中加入If-Modified-Since（对应Last-Modified）或If-None-Match字段（对应If-None-Match），以询问服务端资源是否被修改过。
服务端判断资源是否修改（对于If-Modified-Since服务端看自该时间后资源是否修改、对于If-None-Match服务端比较资源目前的Etag是否与所收到的一样）：若未修改则服务端返回304，浏览器使用缓存；否则浏览器再次请求资源，状态码为200、资源为服务器最新资源。
if-Range：若未修改则使用缓存，若修改则返回原有的数据

https：利用SSL和TLS加密，位于HTTP和TCP之间

参考资料客户端：发送请求到服务端
服务端：返回公钥和证书，加密算法到客户端（加密算法是加密协议集合）
客户端：利用TLS验证证书的安全性,如果通过则会随机生成一个随机数,用公钥对其加密,发送到服务端
服务端：私钥对其解密,随后用这个随机数当做私钥对需要发送的数据进行对称加密
客户端：使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户

1：SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密
2：如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（pre-master secret）能不能被破解因为私钥在服务器
3：client-random和server- random的作用是防止回放攻击，即已经知道了密钥，也无法推出历史信息

chrome浏览器使用的是多进程多线程模式
1：浏览器主进程(Browser进程)：控制chrome的地址栏，书签栏，返回和前进按钮，同时还有浏览器的不可见部分，例如网络请求和文件访问。Chrome浏览器为每个Tab页面单独启用进程，因此每个tab网页都有其独立的渲染引擎实例
2：第三方插件进程：每种插件一个进程，插件运行时才会创建
3：浏览器渲染进程（浏览器内核，内部是多线程的）：负责界面渲染，脚本执行，事件处理等
4：GPU进程：最多一个，用于3D绘制

CDN

非CAS模式，CAS目的解耦合，其中的A我理解为仍然在client上
Content Delivery Network内容分发系统
用户能就近的获取请求数据

浏览器——DNS服务区——CDN服务器
浏览器——服务器
好处：
访问加速
减轻源站负担，CDN能够帮助返回数据
扛住攻击

日志

Log4j ：
只有级别高过配置级别的才能输出
debug： 调试。
info： 输出一下你感兴趣的或者重要的信息，这个用的最多了。
warn error fatal

Logback 改良版Log4j

架构模式
java事务 ACID 两种方法 两阶段
Mybatis 架构 两级缓存
Tomcat 架构 connector架构 container架构
耦合：代码 WEB架构的耦合
微服务：服务的注册 服务的发现 API Gateway 服务雪崩效应
Reactor：历史 三种模式 Netty零拷贝

首先区别前端MVC和后端MVC：
后端MVC的V就是整个前端
前端又分为MVC,MVP,MVVM

MVC:通信是单向的
M：数据访问层
V：表现层
C：业务逻辑层

MVP：双向的
接触了Model和View的耦合

MVVM：
1：实现了View和ViewModel的的自动更新。想象VUE框架，修改页面的值也能同步更新其他值，而不需要再经过model逻辑
2：本质上还是存在controller，只不过被弱化，将其数据解析的部分抽出为VM

SpringMVC：

HandlerMapping为映射，通过不同的URL路径，getset方法，value值等映射为不同的controller
@RequestMapping利用其进行绑定

Tomcat

参考资料

（1）Tomcat有一个Server和多个Service，一个Service可以有多个Connector和一个Container；
（2） Server掌控整个tomcat的生命周期

Service：
Connector用于接受请求并将请求封装成Request和Response，交给Container包装和处理Servlet，以及具体处理request请求，处理完后返回给Connector

Connector：

Connector就是使用ProtocolHandler来处理请求的，不同的ProtocolHandler代表不同的连接类型，比如：Http11Protocol使用的是普通Socket来连接的，Http11NioProtocol使用的是NioSocket来连接的。
（1）Endpoint用来处理底层Socket的网络连接，实现TCP/IP协议的
（2）Processor用于将Endpoint接收到的Socket封装成Request，Processor用来实现HTTP协议的
（3）Adapter用于将Request交给Container进行具体的处理。

Container
Engine：引擎，用来管理多个站点，一个Service最多只能有一个Engine
Host：代表一个站点，也可以叫虚拟主机，通过配置Host就可以添加站点——webapps
Context：代表一个应用程序——webapps下的文件夹
Wrapper：每一Wrapper封装着一个Servlet

处理过程：Pipeline-Value，责任链模式是指在一个请求处理的过程中有很多处理者依次对请求进行处理，每个处理者负责做自己相应的处理，处理完之后将处理后的请求返回，再让下一个处理着继续处理。
tomcat运行原理：
任何项目必须由main开始启动，而对于Web项目是没有main函数的。
而启动的实际上是tomcat的主类是BootStrap类，此时tomcat运行。
而当用户访问8080端口——》connector监听请求——〉Container====根据上图，会给wrapper，
此时构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法，此时得到一个新的HttpServletResponse对象，在依次返回（此处利用反射机制）

apache和tomcat的区别
apache是web服务器（nginx也是）
tomcat是应用（java）服务器，它只是一个servlet容器，可以认为是apache的扩展，但是可以独立于apache运行。
理解为apache是一辆卡车，上面可以装一些东西如html等。但是不能装水，要装水必须要有容器（桶），而这个桶也可以不放在卡车上
但是要注意Apache是很最开始的页面解析服务，tomcat是后研发出来的，从本质上来说tomcat的功能完全可以替代Apache，但Apache毕竟是tomcat的前辈级人物，并且市场上也有不少人还在用Apache，所以Apache还会继续存在，不会被取代，apache不能解析java的东西，但解析html速度快。
区别：
1：Apache是普通服务器，本身只支持html静态普通网页。Tomcat是jsp/servlet容器，同时也支持HTML、JSP、ASP、PHP、CGI等，
2：Apache可以运行一年不重启，稳定性非常好，而Tomcat则不见得。
如果客户端请求的是静态页面，则只需要Apache服务器响应请求，如果客户端请求动态页面，则是Tomcat服务器响应请求

那为什么还要JDK呢？因为jsp需要连接数据库的话就要jdk来提供连接数据库的驱程，所以要运行jsp的web服务器平台就需要APACHE+TOMCAT+JDK

nginx和Apache的区别
1：负载均衡 2：反向代理 3：IMAP/pop3提供邮件服务
Apache 是同步阻塞模型，一个连接对应一个进程；Nginx 是异步非阻塞的，利用epoll方式，多个连接可以对应一个进程。
Nginx 的优势是处理静态请求，cpu 内存使用率低，Apache 适合处理动态请求

耦合

Java代码耦合
方法签名：方法名+参数列表
10个团队做开发
写了一个类A，供其他团队调用

紧耦合：
这个类打成jar包，其他团队就A a = new A()，然后调用a的方法。
缺点：A类升级 再打jar包，再给其他9个组每个组发一份
如果a中，方法签名发生变化，则其他团队重新改代码来适应你新的jar包

松耦合：
定义接口，并让他们利用控制反转（构造或者设值），然后IOC的方式将实现类给他们

WEB架构的耦合：

紧耦合：CS模式

优点：简单
缺点：
1、同步操作导致对网络资源消耗大。同步操作在数据发送和数据返回之间，有很大一段是空闲的，这种空闲占用是对网络资源的极大浪费。
2、安全控制力度差，因为服务器直接暴露给客户机，容易引发网络攻击行为。
3、程序代码之间关联度过高，不利于模块化处理。

松耦合：CAS模式

以上取反

如何搭建服务器

高稳定性：服务器有长时间正确运行的能力，可以常年不关机。
高并发能力：服务器需要响应成千上万的各种服务请求，如果没有强大的并行能力，用户访问就会延迟或失败。
高扩展性：随着业务的不断发展，初始设置的服务器已不能满足现在的需求时，则可以增加网卡、CPU、内存、硬盘等等

centos
1：阿里云购买ecs服务器获得可以访问IP地址和自选端口号

2：利用应用镜像或者远程操控搭建环境
应用镜像：预装服务器的环境，比如mysql，apache，tomcat，有的还会给你提供管理服务器的面板，方便对服务器的操作。应用镜像可用可不用，如果你只是想快速的配置好服务器，推荐大家安装宝塔linux面板

2.1：利用xshell和xftp远程操控
安装JDK，安装tomcat，运行tomcat

3：运行项目
项目直接放入tomcat的webapps目录中即可，或者将项目打包成war文件后放入，重启tomcat后war文件会被自动解析

http无状态，实现对话跟踪：
1：Cookie 实现会话跟踪机制
首次访问的时候，服务端会记录该用户的信息(或者说身份凭证)，当再次访问服务的时候，服务端要求客户端携带用户信息，服务端进行确认。辨别出是哪个用户，哪个会话。存储在客户端
2：URL重写
以参数的形式附加到要请求页面的URL后面，提交的时候解析此URL ，得到所需要的参数。
暴露敏感信息
3：隐藏表单域
那么就可以通过隐藏表单域来实现这一连续的过程。当第一张页面提交后，服务器端作出响应返回第二张页面，此页面中用隐藏域记录了来自登陆时的用户名。通俗说就是当服务器回发给客户端的响应中，就同时把用户名再次回发到客户端，用隐藏域隐藏起来，是不可见的。当第二张页面提交时，此隐藏域中的用户名一并随表单提交。这样服务器就仍然可以判断此用户是否与以前的用户相同。于是，再次处理完结果后继续将响应回发给客户端，且此响应中也仍然包含了用户名，在客户端中仍然用隐藏域将这一信息隐藏

4：初次访问的服务端的时候会把客户端的信息保存起来，再次访问的时候直接从Session中获取即可
但是值得注意的是，Session的使用需要Cookie的支持，因为单独的Session还是无法知道当前访问服务器的是否是同一个客户端，它要根据存储在Cookie中的JSESSIONID来进行判断[这个Cookie是客户端自动创建的]，如果客户端关闭了Cookie，那么Session是没有什么效果的。这个时候，需要使用URL重写的方式，将JSESSIONID直接放置在URL中，访问服务器的时候可以直接进行解析

普通登录：
1：客户段带着身份验证信息访问浏览器
2：浏览器登录后，生成cookie返回给客户端
3：之后客户端登录只需要带着cookie即可免登录
cookie：
键值对的形式
Expires设置过期时间
返回信息存放于HTTP响应头（Set-Cookie）
请求信息存放于HTTP请求头（Cookie）
Domain：用于跨服务器登陆。
服务器在设置域的时候，只能设置为上级域名或者本域名，而不能设置其他域名/子域名，设置的话该cookie失效。
服务器接受cookie的域名会进行比较，如果服务器域名和cookie的相同或者c服务器的是cookie的子集（cookie大于服务器），则可以接受
保存在客户端，例如账号密码直接保存在本地，下次登陆的话不需要用户输入

Session：是一种抽象的存在，会话
具体的实现依赖于cookie或者URL
保存在服务器内存，会为客户端生成一个Session id唯一标示
当服务器调用HttpServletRequest.getSession(true)时创建Session,返回Session id
当客户端再次发送请求的时候，请求头(cookie)会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session
Session删除的时间是：
1）Session超时：超时指的是连续一定时间服务器没有收到该Session所对应客户端的请求，并且这个时间超过了服务器设置的Session超时的最大时间。2）程序调用HttpSession.invalidate()
3）服务器关闭或服务停止

spring分布式：cookie不安全，session复制效率不高
spring-session
默认采用外置的 Redis 来存储 Session 数据

Web服务器接收到http请求后，本地会创建Session，同时第三方服务器Spring-Session也会创建Session。Web服务器之间通过连接第三方服务来共享数据，实现Session共享

单点登录：
1：浏览器app系统，app系统是需要登录的，但用户现在没有登录，返回浏览器
2：浏览器访问SSO登录系统，进行登陆，SSO系统进行认证后，将登录状态写入SSO的session，浏览器（Browser）中写入SSO域下的Cookie。
SSO系统登录完成后会生成一个ST（Service Ticket），返回浏览器
3：浏览器带着ST（Service Ticket）登陆app
4：app系统拿到ST后，从后台向SSO发送请求，验证ST是否有效
验证通过后，app系统将登录状态写入session并设置app域下的Cookie。
至此，跨域单点登录就完成了。以后我们再访问app系统时，app就是登录的。接下来，我们再看看访问app2系统时的流程。

1：用户访问app2系统，app2系统没有登录，返回浏览器。
三种状态：
有sessionID：直接访问
无sessionID，有Ticket：app2访问SSO系统验证ticket有效性
无sessionID，无Ticket：返回302跳转到SSO
2：浏览器反问SSO，由于SSO已经登录了，不需要重新登录认证。
SSO生成ST，返回
3：浏览器跳转到app2系统，并将ST作为参数传递给app2。
4：app2拿到ST，后台访问SSO，验证ST是否有效。
验证成功后，app2将登录状态写入session，并在app2域下写入Cookie。

登陆

查看DNS缓存
浏览器——DNS服务区(CNAME)——CDN服务器(IP地址)
IP——MAC(ARP)
TCP
HTTP
本地渲染

TCP知识点：
如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击

四次挥手为什么有time_wait状态：
原因一：保证第四次ACK能够到达服务器
原因二：使得链路上关于本次连接的报文失效
客户端A，服务器B
A和B建立连接，B发送的报文落后于FIN，并且AB关闭连接后，A又以相同的I四元组（客户端IP地址和端口，服务端IP地址和端口号）建立B连接，此时发送报文。如果没有time_wait，则第一次连接的报文可能会在第二次连接中收到，A以为是本次链接的报文接受后就会出错。
所以time_wait状态下所有接受的报文都会失效

快速回收：等待一个Retrans时间即释放，也就是等待一个重传时间
释放TCP，但是保留peer的IP地址信息以及TCP最后一次触摸它的时间戳
如果同时触犯了以下几点则不可以建立TCP连接：
1.之前同一台peer机器的某个TCP数据在MSL秒之内到过本机，且本次连接小于上次TCP到来时的时间戳，且差值大于重放窗口戳。

快速重用：
1.初始序列号比TW老连接的末序列号大
2.如果使用时间戳，那么新到来的连接的时间戳比老连接的时间戳大

保活机制：
TCP会在连接空闲一定时间间隔之后会发送一个特殊的段给对等方
若对等方应用程序依然运行，则会响应并发送一个ACK消息。
若没有运行，则超时关闭连接
若那就是对等方应用程序没有运行，但是对等方主机依然可以到达，此时，对等方主机就会返回RST消息，待发送方主机接收后，则会撤销TCP连接并返回ECONNRESET错误给应用程序。
TCP keepalive probe报文
TCP保活探测报文是将之前TCP报文的序列号减1，并设置1个字节，内容为“00”的应用层数据
TCP keepalive ACK报文
TCP保活探测确认报文就是对保活探测报文的确认， 其报文
int keepalive = 1; // 开启KEEP_ALIVE
int keepidle = 60; // 如该连接在60秒内没有任何数据往来,则进行探测
int keepinterval = 5; //探测时发包的时间间隔为5秒（每个探测包的存活时间）
int keepcount = 3; //探测尝试的总次数.如果第1次探测包就收到响应了,则后2次的不再发.

HTTP 的 KeepAlive：
http头加入”Connection: Keep-Alive”
Keep-Alive timeout： Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。

Content-Length
Content-Length表示实体内容的长度。浏览器通过这个字段来判断当前请求的数据是否已经全部接收。
Transfer-Encoding
Transfer-Encoding是指传输编码，在上面的问题中，当服务端无法知道实体内容的长度时，就可以通过指定Transfer-Encoding: chunked来告知浏览器当前的编码是将数据分成一块一块传递的。最后，当浏览器接收到一个长度为0的chunked时， 知道当前请求内容已全部接收。

注意和 HTTP 的 KeepAlive 区别对待
HTTP 协议的 KeepAlive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
TCP 的 KeepAlive 机制意图在于保活、心跳，检测连接错误。

ping:
Echo request——回显请求（Ping请求）

ping localhost:
localhost的IP地址一般为127.0.0.1,；如果此时ping不通，则表示协议栈有问题；

ping 本机IP：
ping 本机IP其实是从驱动到网卡，然后原路返回；所以如果此时ping不通，则表示网卡驱动有问题，或者NIC硬件有问题；

ping 网关：
若此时ping不通，则为主机到路由器间的网络故障；

ping 目的IP:
若此步骤不成功，应该就是路由器到目的主机的网络有问题