JAVA Web知识点整理

资料收集来自互联网，比较杂，自己做了些简单的整理

Spring相关

Spring

IOC 控制反转

1. 概念： 在传统的程序设计过程中，通常由调用者来创建被调用者的实例对象。但在spring中创建被调用者的工作不再由调用者来完成，因此称为控制反转。创建被调用者的工作由spring的IOC容器来完成，然后注入调用者直接使用。
2. 原理： IOC:控制反转也叫依赖注入。利用了工厂模式。将对象交给容器管理，你只需要在spring配置文件总配置相应的bean，以及设置相关的属性，让spring容器来生成类的实例对象以及管理对象。在spring容器启动的时候，spring会把你在配置文件中配置的bean都初始化好，然后在你需要调用的时候，就把它已经初始化好的那些bean分配给你需要调用这些bean的类（假设这个类名是A），分配的方法就是调用A的setter方法来注入，而不需要你在A里面new这些bean了。
   （其实就是通过解析xml文件，或取到用户配置的bean，然后通过反射将这些bean挨个放到集合中，然后对外提供一个getBean(“beanID”)方法，以便我们获得这些bean。）

AOP

1. 概念： 可以让容器中的对象都享有容器中的公共服务，将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
2. 原理： 一个代理类（里面包含一个目标对象的引用）在调用目标对象方法前后，加入一些别的操作。如果被代理对象实现了接口，则采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行，代理类实现InvocationHandler接口，重写invoke（）方法； 如果没有实现接口，使用CGLIB生成代理类。拦截器类实现其中intercept（）方法

Spring Boot

概念

就是把 spring，spring mvc，spring data jpa等等的一些常用的常用的基础框架组合起来

1. Spring boot对第三方技术进行了很好的封装和整合，提供了大量第三方接口；
2. 内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作了。
3. 无需再像Spring那样搞一堆繁琐的xml文件的配置；
4. 可以自动配置Spring；

Spring 最初利用“工厂模式”（ DI ）和“代理模式”（ AOP ）解耦应用组件。大家觉得挺好用，于是按照这种模式搞了一个 MVC 框架（一些用 Spring 解耦的组件），用开发 web 应用（ SpringMVC ）。然后有发现每次开发都要搞很多依赖，写很多样板代码很麻烦，于是搞了一些懒人整合包（ starter ），这套就是 Spring Boot 。

自动配置

1. 使用@EnableAutoConfiguration注解，启动自动配置。
2. 该注解导入了EnableAutoConfigurationImportSelector，其使用 SpringFactoriesLoader类加载所有META-INF下具有spring.factories文件（文件里面都是配置类）的jar包，并根据spring.factories文件中的配置，去加载相应的类。

HTTP协议相关

TCP

TCP特点

1. TCP面向连接
2. TCP面向字节流，TCP不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值大小和当前网络的拥塞情况来决定一个报文应该包含多少个字节（TCP可以决定发送的报文长度，少了多等一些，多了划分短一些）
3. TCP保证可靠传输，无差错，不丢失，不重复，按序到达
4. TCP支持全双工通信
5. TCP支持端口到端口的连接，每一条TCP连接只能有两个端点（TCP连接的端点叫嵌套字socket = （IP地址：端口号））

TCP首部

20字节固定长度：
端口号：4字节
发送字节序号：4字节
确认号：希望方法下一个报文的第一个数据序号，若为401，表示前400个收到了，4字节
数据偏移：TCP首部长度（加上可选的部分）
窗口：接收方目前允许对方发送的数据量，2字节
校验和：也要加上12字节的伪首部，同样要检验首部和数据两部分，2字节（协议码为6）

40字节可选长度： 比如，可以用来放选择确认SACK，如果TCP接收方收到的数据不连续（丢了一部分），为了不回退N，可以用4个字节标记已收到的左边界，4个字节标记右边界【已收到的 [左，右）】，告诉发送方不用再发这部分数据

连续自动重传请求ARQ

1. 自动重传： 重传是自动进行的，接收方不需要请求发送方重传，只要发送方过了一段时间没有收到确认，就会自动重传（超时重传-超时计时器）
2. 要求： 发送端对发出去但是没有收到确认请求的数据都要保存副本；分组要编号（字节序号）；超时时间略大于平均往返时间RTT（加权平均往返时间：每测到一个新的往返时间，就修正一下，如果出现报文重传，就不算这次的往返时间）
3. 连续： 滑动窗口（发送和接收，以字节为单位），接收方一般采用累积确认的方式.即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示：到这个分组为止的所有分组都已正确收到了。累计确认的缺点是：Go-back-N(回退N)，即如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了.这时接收方只能对前两个分组发出确认.发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次

流量控制

1. 特点： 让发送方发的不要太快，让接受方来的及接收，点对点通信量的控制，是个端到端的问题
2. 实现方法： TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节，发送方方发送窗口不能大于接收端的接收窗口rwnd（接收窗口大小在TCP首部体现（窗口字段））
3. 死锁： 接收端B向发送端A发送了0窗口，一段时间后，B有缓存空间了，向A发送新窗口大小，但这个信息丢失了，则此时A会一直等待B发送非零窗口的通知，而B也一直在等A发数据——解决方法：TCP设置一个持续计数器，收到零窗口通知后开启，倒计时结束，发送一个1字节的试探报文，对方在确认报文时给出目前的窗口值

拥塞控制

1. 目的： 防止过多的数据注入到网络中，使网络中的路由器或链路不至于过载，是一个全局性的过程

2. 四种拥塞控制算法：

   慢开始和拥塞避免：
   cwnd 拥塞窗口； ssthresh慢开始门限
   （1）. 一开始建立TCP连接时：使用慢开始算法，每发送成功一字节就把cwnd加1，经过RTT发送成功了多少字节就增加了多少字节，也就是发送的字节数*2，
   （2）. 当cwnd>ssthresh时使用拥塞避免算法，拥塞避免算法则不管发送成功多少字节都仅将cwnd加1)，此时cwnd的变化开始平缓。
   （3）. 无论是在慢开始阶段还是在拥塞避免阶段，只要网络发生拥塞(判断的依据是丢包)，都将慢开始门限ssthresh减小为当前cwnd的一半，并将发送窗口cwnd置为1，执行慢开始算法。
   
   快重传和快恢复：
   （1）. 我们知道TCP在发送一个数据包后会设置一个定时器，如果这个定时器到时后仍然没有接受到对端的确认，那么就确认该报文已丢失需要重新发送，但是如果每个已丢失的报文都需要等到定时器到达在重新发送那么传输效率势必会造成影响。因此TCP采用快重传来使得TCP拥有更高效的传输速率。快重传的意思是指接受方每接受到一个失序的报文就立即确认该报文，而不是采用上文所讲的延时确认。当接收方连续接收到三个失序的确认报文后就马上重新发送导致失序的那个报文(这个报文未被确认而导致收到了三个失序的确认报文），而不必等待重传定时器到时。
   （2）. 配合快重传算法的还有快恢复算法，当发送方连续收到三个重复的确认报文时就采用快恢复算法。此时先把cwnd减半，sthresh设置为cwnd相同大小，同时执行拥塞避免算法。注意到此次并未将cwnd置为1,因为TCP认为能够连续收到三个确认报文，所以网络可能并不拥塞，因此只采用了快恢复算法。
   
   因此，发送方窗口的上限 = Min [rwnd,cwnd]; (接收窗口和拥塞窗口的最小值)

TCP三次握手四次挥手

基本流程：


为什么需要三次握手：
采用两次握手，那么若Client向Server发起的第一次握手包A1如果在传输链路上遇到的故障，导致传输到Server的时间相当滞后，在这个时间段由于Client没有收到Server的对于包A1的确认，那么就会重传一个包A2，假设服务器正常收到了A2的包，然后返回确认B2包（第二次握手包）。由于没有第三次握手，这个时候Client和Server已经建立连接了。
再假设A1包随后在 上个连接释放后 在链路中又传到了Server，这个时候Server又会返回B1包确认，但是由于Client已经清除了A1包，所以Client会丢弃掉这个确认包，但是Server会保持这个相当于“僵尸”的连接，一直等待Client发送信息。所以采用两次握手，有可能会浪费Server的网络资源。

为什么需要等待2MSL：

1. 为了保证A发送的最后一个ACK报文能够到达B。如果这个ACK报文段丢失，则B会超时重传FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后就立即释放连接，就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常的步骤进入CLOSED状态。
2. A在发送完ACK报文段后，再经过2MSL时间，就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

TCP中的四个定时器

1. 重传计时器(Retransmission Timer)：
   • 目的：为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
   • 工作原理：在TCP发送报文段时，会创建对次特定报文段的重传计时器。可能发生的两种情况：在截止时间（通常为60秒）到之前，已经收到了对此特定报文段的确认，则撤销计时器；在截止时间到了，但为收到对此特定报文段的确认，则重传报文段，并且将计时器复位。
   • 重传时间：2*RTT（Round Trip Time，为往返时间）

2. 坚持计时器(Persistent Timer)：
   • 目的：主要解决零窗口大小通知可能导致的死锁问题（流量控制里面用到的）
   • 工作原理：当发送端TCP收到接收端发来的零窗口通知时，就会启动坚持计时器。当计时器的期限到达时，发送端就会主动发送一个特殊的报文段向对方询问当前接受窗口大小【这个特殊的报文段就称为探测报文段，探测报文段只有1个字节的大小，里边只有一个序号，该序号不需要被确认，甚至在计算其他部分数据的确认时该序号会被忽略。】
   • 截止期的设置：设置为重传时间的值。但如果没有收到接收端的响应，则会发送另一个探测报文段，并将计时器的值加倍并复位，直到大于门限值（一般为60秒）。在此之后，发送端会每隔60秒发送一个探测报文段，直到窗口重新打开。

3. 保活计时器(Keeplive Timer)： 心跳包
   • 目的：主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后，很长时间内客户端都没有向服务器端发送数据，此时很有可能是客户端出现故障，而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
   • 工作原理：每当服务器端收到客户端的数据时，都将保活计时器重新设置（通常设置为2小时）。过了2小时后，服务器端如果没有收到客户端的数据，会发送探测报文段给客户端，并且每隔75秒发送一个，当连续发送10次以后，仍没有收到对端的来信，则服务器端认为客户端出现故障，并会终止连接。

4. 时间等待计时器(Time_Wait Timer)：
   • 时间等待计时器是在连接终止期间使用的。
   • 当TCP关闭连接时并不是立即关闭的，在等待期间，连接还处于过渡状态。这样就可以使重复的FIN报文段在到达终点之后被丢弃。
   • 时间设置：一般为报文段寿命期望值的2倍。2*MSL

UDP

UDP特点

用户数据报协议UDP只在IP的数据报服务上增加了很少的一些功能：复用和分用功能以及差错检测。

• UDP是一种无连接的， 即发送数据前不需要建立连接，因此减小的开销和发送数据的延迟。
• UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
• UDP是面向报文的，把应用程序较下来的报文添加首部后直接交付IP层，不对报文进行合并或拆分。因此需要选择长度合适的报文
• UDP没有拥塞控制，因此网络出现的拥塞不会使主机的发送率降低。允许丢失一些数据，但不允许太大的时延。
• UDP支持一对一，一对多，多对一和多对多的交互通信。
• UDP首部开销小，只有8字节，比TCP的20个字节的首部要短。

UDP首部

伪首部： 伪首部只是用来计算校验和，不向下转送也不向上提交，把首部和数据部分一起检验（IP数据报只检验IP首部）12字节：4字节源IP地址，4字节目的IP地址，1字节（0）,1字节（17），2字节UDP长度（真首部和数据总字节数）
（真）首部： 8字节：2字节源端口号，2字节目标端口号，2字节数据报长度，2字节校验和

差错检验

方法： 把伪首部，真首部（校验和先全为0）和数据按每16位（最后不足16位则补0），进行二进制反码求和，得到的结果存入校验位。接收端同样求二进制反码和，若无差错，结果为全1
处理： 如果检验和有差错，那么UDP数据报就要被丢弃

TCP与UDP区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达; UDP尽最大努力交付，即不保证可靠交付。（Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。）
3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。（实时视频会议，IP电话）
4、每一条TCP连接只能是点到点的; UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP对系统资源要求较多，UDP对系统资源要求较少。
6、TCP首部长度20字节; UDP的首部开销小，只有8个字节

HTTP请求报文和响应报文

1. 请求报文
   
2. 响应报文
   

HTTP与HTTPS

HTTP协议以明文方式发送内容，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
　　安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS流程

1、客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的443端口。

2、服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3、传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4、客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值，然后用证书（公钥）对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5、传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6、服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(共享秘钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和共享秘钥通过某种算法混合在一起，这样除非知道共享秘钥，不然无法获取内容，而正好客户端和服务端都知道这个共享秘钥，所以只要加密算法够彪悍，共享秘钥够复杂，数据就够安全。

7、传输加密后的信息，客户端解密信息
这部分信息是服务段用共享秘钥加密后的信息，客户端用之前生成的共享秘钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

缺点

1、HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电。
2、 HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗（因为还要传秘钥），甚至已有的安全措施也会因此而受到影响。
3、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
4、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
5、HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

HTTP与HTTPS区别

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTP中介

1. 代理(Proxy)： 一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过 URI的标识把已格式化过的请求发送到服务器。
2. 网关(Gateway)： 一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
3. 通道(Tunnel)： 一个不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道经常被使用。一旦激活，通道便被认为不属于HTTP通讯，当被中继 的连接两端关闭时，通道便消失。