JavaWeb 7.07总结

阳仔475
66 阅读9分钟

1.Spring中常用注解

1.1@RestController

1.@Controller:当前类是一个控制器，用来处理客户端的请求。

2.@ResponseBody：表示方法的返回值是以响应体的形式返回。如果是对象或者集合，则会转成JSON字符串返回给客户端。该注解标记在类上，等同于该类中每个方法都标记了该注解。

1.2@Component:当前类是一个Spring容器管理的bean

1.@Controller：参考上面。

2.@Service：标记在业务层上。

3.@Repository：标记在持久层上。

==以上注解可以使用value来指定bean的名称，默认为类名首字母小写==

1.3@Autowired

自动按照类型注入，如果要指定bean名称，可以使用Qualifier来指定。

1.4@Resource

按照名称注入，使用name属性指定bean名称，如果没有name，则就是变量名作为beanName。

2.三层架构

  • Controller：控制层。接收前端发送的请求，对请求进行处理，并响应数据。
  • Service：业务逻辑层。处理具体的业务逻辑。
  • Dao：数据访问层(Data Access Object)，也称为持久层。负责数据访问操作，包括数据的增、删、改、查。

3.IOC&DI

3.1.IOC(控制反转)

  • 控制反转**：** Inversion Of Control，简称IOC。对象的创建控制权由程序自身转移到外部（容器），这种思想称为控制反转。（反转之前对象的创建由程序完成，需要什么对象就new什么对象。反转之后，对象由spring容器管理。）
  • 对象的创建权由程序员主动创建转移到容器(由容器创建、管理对象)。这个容器称为：IOC容器或Spring容器。

3.2.DI(依赖注入)

  • 依赖注入**：** Dependency Injection，简称DI。容器为应用程序提供运行时，所依赖的资源，称之为依赖注入。
  • 程序运行时需要某个资源，此时容器就为其提供这个资源。（程序需要什么对象，spring容器就提供什么对象并且将其注入。）
  • 例：EmpController程序运行时需要EmpService对象，Spring容器就为其提供并注入EmpService对象。
  • **bean对象：**IOC容器中创建、管理的对象，称之为：bean对象

4.@Resource 与 @Autowired区别

@Resource：

  • Java注解，按名称进入注入

@Autowired：

  • Spring注解，优先按类型注入。如果找到多个相同类型的bean，则会把变量名当作bean名称再去容器中匹配，找到则注入；找不到则报错

5.GET请求方式和POST请求的区别

  1. 数据传输方式:
    1. GET: 数据参数附加在URL的查询字符串中，例如 www.example.com/searchq=key… 查询字符串以问号?开头，参数之间用&符号分隔。
    2. POST: 数据参数包含在请求体中，不会显示在URL中。
  2. 安全性:
    1. GET: 由于数据暴露在URL中，安全性较低。 不适合传输敏感信息，例如密码、信用卡号等。 GET请求的数据会被浏览器缓存，也可能被记录在服务器日志中。
    2. POST: 数据不在URL中显示，安全性相对较高。 仍然建议对敏感数据进行加密传输。 POST请求的数据不会被浏览器缓存，服务器日志中通常也不会记录完整的请求体。
  3. 数据量限制:
    1. GET: URL的长度有限制，因此GET请求能够传输的数据量较小。 具体限制取决于浏览器和服务器，一般不超过几KB。
    2. POST: 请求体的大小没有严格限制，可以传输大量数据，例如文件上传。
  4. 缓存:
    1. GET: GET请求会被浏览器缓存，这意味着如果再次请求相同的URL，浏览器可能会直接使用缓存中的数据，而不会发送新的请求到服务器。 这可以提高效率，但也可能导致数据不同步。
    2. POST: POST请求不会被浏览器缓存，每次请求都会发送到服务器。
  5. 用途:
    1. GET: 通常用于获取数据，例如搜索、浏览网页等。 GET请求应该是幂等的，即多次执行相同的GET请求应该产生相同的结果，不会对服务器状态产生影响。
    2. POST: 通常用于提交数据，例如表单提交、文件上传、修改数据等。 POST请求不一定是幂等的，多次执行相同的POST请求可能会产生不同的结果，例如多次提交订单会创建多个订单。
  6. 编码类型:
    1. GET: 通常使用URL编码，将特殊字符转换为%XX格式。
    2. POST: 可以使用多种编码类型，例如application/x-www-form-urlencoded、multipart/form-data、application/json等。
特性GETPOST
数据传输URL查询字符串请求体
安全性低较高
数据量受URL长度限制，较小较大
缓存会被缓存不会被缓存
用途获取数据，幂等操作提交数据，非幂等操作
编码类型URL编码application/x-www-form-urlencoded等

6.三次握手&四次挥手

6.1三次握手

TCP 三次握手是建立可靠 TCP 连接的关键过程。它的主要目的是确保通信双方都已准备好进行数据传输，并且协商初始序列号，为后续的数据传输建立基础。下面是三次握手的详细介绍：

1.第一次握手 (SYN)

  • 过程: 客户端（发起连接的一方）向服务器端发送一个 TCP SYN (synchronize) 报文。
  • 报文内容:
    • SYN 标志位: SYN=1 (表示这是一个同步报文，请求建立连接)
    • 序列号 (Sequence Number): 客户端选择一个随机的初始序列号 x (ISN - Initial Sequence Number)。这个序列号是后续数据传输的基础，每个发送的数据包都会携带递增的序列号。
    • 其他可选字段: 窗口大小 (Window Size) 等。
  • 状态变化: 客户端进入 SYN_SENT 状态，等待服务器的确认。

2.第二次握手 (SYN-ACK)

  • 过程: 服务器端收到客户端的 SYN 报文后，如果同意建立连接，会发送一个 SYN-ACK (synchronize-acknowledge) 报文作为回应。
  • 报文内容:
    • SYN 标志位: SYN=1 (表示同意建立连接)
    • ACK 标志位: ACK=1 (表示确认收到客户端的 SYN 报文)
    • 确认号 (Acknowledgment Number): 设置为 x + 1，表示服务器期望接收到的下一个数据包的序列号。这是对客户端发送的 SYN 报文的确认。
    • 序列号 (Sequence Number): 服务器选择一个随机的初始序列号 y (ISN)。
    • 其他可选字段: 窗口大小等。
  • 状态变化: 服务器端进入 SYN_RCVD 状态，等待客户端的确认。

3.第三次握手 (ACK)

  • 过程: 客户端收到服务器端的 SYN-ACK 报文后，会发送一个 ACK (acknowledge) 报文作为确认。
  • 报文内容:
    • ACK 标志位: ACK=1 (表示确认收到服务器端的 SYN-ACK 报文)
    • 确认号 (Acknowledgment Number): 设置为 y + 1，表示客户端期望接收到的下一个数据包的序列号。这是对服务器端发送的 SYN-ACK 报文的确认。
    • 序列号 (Sequence Number): 设置为 x + 1 (与第一次握手时发送的序列号相关)。客户端从 SYN_SENT状态转移到 ESTABLISHED状态后，后续发给服务器端的数据包的序列号，以 x+1 为基础递增。
  • 状态变化: 客户端发送 ACK 报文后，进入 ESTABLISHED 状态，表示连接已成功建立。服务器端收到 ACK 报文后，也进入 ESTABLISHED 状态，连接建立完成。

img

6.2四次挥手

TCP 四次挥手是断开一个已建立的 TCP 连接的过程。与三次握手建立连接类似，断开连接也需要经过一定的协商，以确保数据传输的完整性和可靠性。 以下是四次挥手的详细过程：

  1. 第一次挥手 (FIN)
  • 过程: 客户端（或服务器端，通常是客户端发起关闭连接）发送一个 TCP FIN (finish) 报文，告诉对方自己已经没有数据要发送了。注意，这并不意味着客户端立即关闭连接，它仍然可以接收来自对方的数据。
  • 报文内容:
    • FIN 标志位: FIN=1 (表示这是一个结束报文，请求关闭连接)
    • 序列号 (Sequence Number): 携带当前已发送的最后一个数据的序列号。
  • 状态变化: 客户端进入 FIN_WAIT_1 状态，等待服务器的确认。
  1. 第二次挥手 (ACK)
  • 过程: 服务器端收到客户端的 FIN 报文后，会发送一个 ACK (acknowledge) 报文作为确认，表示已经收到客户端的关闭连接请求。
  • 报文内容:
    • ACK 标志位: ACK=1 (表示确认收到客户端的 FIN 报文)
    • 确认号 (Acknowledgment Number): 设置为 x + 1，其中 x 是客户端 FIN 报文的序列号。
  • 状态变化:
    • 客户端进入 FIN_WAIT_2 状态，等待服务器发送 FIN 报文。
    • 服务器端进入 CLOSE_WAIT 状态，表示等待应用程序关闭连接。 服务器端仍然可以继续发送数据给客户端，直到服务器端的应用程序也调用 close() 关闭连接。
  1. 第三次挥手 (FIN)
  • 过程: 当服务器端也准备好关闭连接时，会发送一个 FIN 报文，告诉客户端自己也没有数据要发送了。
  • 报文内容:
    • FIN 标志位: FIN=1 (表示这是一个结束报文，请求关闭连接)
    • 序列号 (Sequence Number): 携带当前已发送的最后一个数据的序列号。
  • 状态变化: 服务器端进入 LAST_ACK 状态，等待客户端的确认。
  1. 第四次挥手 (ACK)
  • 过程: 客户端收到服务器端的 FIN 报文后，会发送一个 ACK 报文作为确认。
  • 报文内容:
    • ACK 标志位: ACK=1 (表示确认收到服务器端的 FIN 报文)
    • 确认号 (Acknowledgment Number): 设置为 y + 1，其中 y 是服务器端 FIN 报文的序列号。
  • 状态变化:
    • 客户端进入 TIME_WAIT 状态。 在经过 2MSL (Maximum Segment Lifetime) 时间后，客户端才会真正关闭连接并释放资源。
    • 服务器端收到 ACK 报文后，直接关闭连接并释放资源，进入 CLOSED 状态。

img

avatar
文章
阅读
粉丝