TCP之三次握手四次挥手与UDP区别

文章目录

  • 1 TCP三次握手四次挥手
    • 1.1 数据包说明
      • 1.1.1 TCP数据包
      • 1.1.2 UDP数据包
      • 1.1.3 TCP和UDP差异
      • 1.1.4 TCP可靠性传输机制
    • 1.2 三次握手
      • 1.2.1 三次握手定义
      • 1.2.2 三次握手问题
        • 1.2.2.1 问题引入分析
        • 1.2.2.2 历史连接
        • 1.2.2.3 同步双方初始序列号
        • 1.2.2.4 避免资源浪费
    • 1.3 四次挥手

1 TCP三次握手四次挥手

TCP 在传输之前会进行三次沟通，一般称为三次握手，传完数据断开的时候要进行四次挥手

1.1 数据包说明

1.1.1 TCP数据包

在这里插入图片描述
数据包说明:

  1. 源端口号(16 位)：它(连同源主机 IP 地址)标识源主机的一个应用进程
  2. 目的端口号(16 位)：它(连同目的主机 IP 地址)标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址确定唯一一个 TCP 连接
  3. 顺序号seq(32 位)： 用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用顺序号对每个字节进行计数。序号是 32bit 的无符号数， 序号到达 2^32-1后又从 0 开始。 当建立一个新的连接时， SYN 标志变1，顺序号字段包含 由这个主机选择的 该连接的初始顺序号 ISN (Initial Sequence Number )
  4. 确认号 ack(32 位)： 包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1 。 只有 ACK 标志为 1 时确认序号字段才有效。
    TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。
  5. TCP 报头长度(4 位)：给出报头中 32bit 字的数目， 它实际上指明数据从哪里开始。 需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20字节
  6. 保留位(6 位)：保留给将来使用，目前必须置为 0 。
  7. 控制位(control flags ， 6 位)：在TCP报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为：
    URG ：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
    ACK ：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
    PSH ：为 1 表示是带有 PUSH 标志的数据， 指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
    RST ： 用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
    SYN ：同步序号， 为 1 表示连接请求，用于建立连接和使顺序号同步synchronize
    FIN ： 用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。
  8. 窗口大小(16 位)：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个 16bit 字段，因而窗口大小最大为 65535 字节。
  9. 校验和(16 位)：此校验和是对整个的 TCP 报文段， 包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储， 并由接收端进行验证。
  10. 紧急指针(16 位)：只有当 URG 标志置 1 时紧急指针才有效。TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式
  11. 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志的那个段)中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数。
  12. 数据：TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段

1.1.2 UDP数据包

在这里插入图片描述

  • 源端口号(Source Port):这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的UDP端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选项，有时不会设置源端口号。没有源端口号就默认为 0 ，通常用于不需要返回消息的通信中。
  • 目标端口号(Destination Port): 表示接收端端口，字段长为 16 位。
  • 长度(Length): 该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8，最大长度为 2 ^ 16 = 65535 字节（即报文长度为64K）
  • 校验和(Checksum)：UDP使用校验和来保证数据安全性，UDP 的校验和也提供了差错检测功能，差错检测用于校验报文段从源到目标主机的过程中，数据的完整性是否发生了改变

转载于：https://mp.weixin.qq.com/s/aAAZQh8r7eCsIR9GsSvauw

1.1.3 TCP和UDP差异

  • UDP 没有所谓的序列号和确认号，所以不会对数据进行确认，数据丢失后也不会进行重传，所以 UDP 是一种不可靠的协议
  • TCP具有高可靠性，确保传输数据的正确性，不出现丢失或乱序，传输数据量大，没有限制
  • TCP相对于UDP速度慢一点，效率低，而且要求系统资源较多，每个连接都会占用系统的CPU、内存等硬件资源
  • UDP速度快、操作简单、要求系统资源较少，传输数据少，理论64K
  • UDP不可靠，可能会出现丢包、乱序、数据不完整

1.1.4 TCP可靠性传输机制

为了保持 TCP 的可靠性传输，TCP 协议采用了以下机制：

  • 序号与确认机制：TCP 使用序号 (sequence number)来对数据进行编号，并使用确认（acknowledgment）来确认接收到的数据。发送方将每个数据段分配一个序号，接收方通过发送确认消息来告知发送方已成功接收到数据。如果发送方在一定时间内没有收到确认消息，就会重新发送数据。
  • 数据段校验和：TCP 使用校验和(checksum)来检测数据在传输过程中是否发生了错误。发送方在发送数据前计算校验和，并将其附加到数据段中。接收方在接收到数据后也会计算校验和，并与发送方发送的校验和进行比对。如果校验和不匹配，则表明数据在传输过程中发生了错误，接收方会要求发送方重新发送数据。
  • 确认重传机制：如果发送方在一定时间内没有收到确认消息，就会认为数据丢失，并重新发送数据。接收方在收到重复的数据时会丢弃重复的数据，只发送一个确认消息，以避免重复处理。
  • 滑动窗口机制：TCP 使用滑动窗口（sliding window）机制来控制发送方和接收方之间的数据流量。发送方将数据分成多个数据段，并将其发送给接收方。接收方使用滑动窗口来控制可以接收的数据量。滑动窗口的大小可以根据网络状况动态调整，以确保数据的可靠传输。
  • 流量控制：TCP 使用流量控制机制来避免发送方发送过多的数据，导致接收方无法处理。接收方可以通过发送窗口大小告诉发送方可以接收的数据量。发送方需要根据接收方的窗口大小来控制发送的数据量，以避免数据的拥塞和丢失。
  • 拥塞控制：TCP 使用拥塞控制机制来避免网络拥塞。发送方根据网络状况动态调整发送速率，以避免发送过多的数据导致网络拥塞。TCP 使用拥塞窗口 (congestion window)来控制发送方的发送速率。拥塞窗口的大小可以根据网络状况动态调整，以确保网络的稳定性和可靠性。
  • 最大消息长度：为了防止因数据包过大而导致传输错误，TCP设定了最大消息长度的限制

1.2 三次握手

1.2.1 三次握手定义

客户端向服务器发送建立连接请求
在这里插入图片描述
一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

  1. 第一次握手：主机 A 发送位码为 syn＝1,随机产生 seq number=1234567 的数据包到服务器，主机 B 由 SYN=1 知道， A 要求建立联机；该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
    在这里插入图片描述

  2. 第二次握手：主 机 B 收 到 请 求 后 要 确 认 联 机 信 息 ， 向 A 发 送 ack number=( 主 机 A 的seq+1),SYN=1,ACK=1,随机产生 seq=7654321 的包，把 TCP 首部的确认应答号，把 SYN 和 ACK 标志位置为 1，最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
    在这里插入图片描述

  3. 第三次握手： 主机 A 收到后检查 ack number 是否正确，即第一次发送的 seq number+1,以及位码ACK 是否为 1，若正确， 主机 A 会再发送 ack number=(主机 B 的 seq+1),ACK=1，主机 B 收到后确认seq 值与 ACK=1 则连接建立成功。最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。
    在这里插入图片描述
    最后，服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态

1.2.2 三次握手问题

1.2.2.1 问题引入分析

概括起来，是这两个问题：

  • 问：TCP三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的，会发生什么？是直接丢弃 or 回 RST 报文？
    答：回 RST 报文
  • 问：什么情况下会收到不正确的 ack（第二次握手中的 ack） 呢
    答：当客户端发起多次 SYN 报文，然后网络拥堵的情况下，旧的 SYN 报文比新的 SYN 报文早抵达服务端，此时服务端就会按照收到的旧的 SYN 报文回复 syn+ack 报文，而此报文的确认号并不是客户端期望收到的，于是客户端就会回 RST 报文

假如 TCP三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的过程如下：
在这里插入图片描述
当客户端连续发送多次建立连接的 SYN 报文，然后在网络拥堵的情况，就会发生客户端收到不正确的 ack 的情况。具体过程如下：

  • 客户端先发送了 SYN（seq = 90） 报文，但是被网络阻塞了，服务端并没有收到，接着客户端又重新发送了 SYN（seq = 100）报文，注意不是重传 SYN，重传的 SYN 的序列号是一样的。
  • 旧 SYN 报文比最新的 SYN 报文早到达了服务端，那么此时服务端就会回一个 SYN + ACK 报文给客户端，此报文的确认号是 91（90+1）。
  • 客户端收到后，发行自己期望收到的确认号应该是 100+1，而不是 90 + 1，于是就会回 RST 报文。
  • 服务端收到 RST 报文后，就会中止连接。
  • 后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。

上述中的旧 SYN 报文称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止历史连接初始化了连接。

1.2.2.2 历史连接

如果是两次握手连接，就无法阻止历史连接，那为什么TCP 两次握手为什么无法阻止历史连接呢？
先说结论，主要是因为在两次握手的情况下，被动发起方没有中间状态给主动发起方来阻止历史连接，导致被动发起方可能建立一个历史连接，造成资源浪费。

假如在两次握手的情况下，被动发起方在收到 SYN 报文后，就进入 ESTABLISHED 状态，意味着这时可以给对方发送数据给，但是主动发起方此时还没有进入 ESTABLISHED 状态，假设这次是历史连接，主动发起方判断到此次连接为历史连接，那么就会回 RST 报文来断开连接，而被动发起方在第一次握手的时候就进入 ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报文后，才会断开连接。
在这里插入图片描述

可以看到，上面这种场景下，被动发起方在向主动发起方发送数据前，并没有阻止掉历史连接，导致被动发起方建立了一个历史连接，又白白发送了数据，妥妥地浪费了被动发起方的资源。
因此，要解决这种现象，最好就是在被动发起方发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。

1.2.2.3 同步双方初始序列号

TCP 协议的通信双方， 都必须维护一个序列号， 序列号是可靠传输的一个关键因素，它的作用：

  • 接收方可以去除重复的数据；
  • 接收方可以根据数据包的序列号按序接收；
  • 可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；

可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带初始序列号的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送初始序列号给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
在这里插入图片描述

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了 三次握手
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。

1.2.2.4 避免资源浪费

如果只有两次握手，当客户端发生的 SYN 报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的 ACK 报文，所以服务端每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？

如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次 SYN 报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
在这里插入图片描述

两次握手会造成资源浪费
即两次握手会造成消息滞留情况下，服务端重复接受无用的连接请求 SYN 报文，而造成重复分配资源。

1.3 四次挥手

TCP 建立连接要进行三次握手，而断开连接要进行四次。这是由于 TCP 的半关闭造成的。因为 TCP 连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个 FIN 来向另一方通告将要终止这个方向的连接

首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭
在这里插入图片描述

  1. 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u
  2. 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1
  3. 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
  4. 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加 1

主机 A 发送 FIN 后，进入终止等待状态， 服务器 B 收到主机 A 连接释放报文段后，就立即给主机 A 发送确认，然后服务器 B 就进入 close-wait 状态，此时 TCP 服务器进程就通知高层应用进程，因而从 A 到 B 的连接就释放了。此时是半关闭状态。即 A 不可以发送给B，但是 B 可以发送给 A。此时，若 B 没有数据报要发送给 A 了，其应用进程就通知 TCP 释放连接，然后发送给 A 连接释放报文段，并等待确认。 A 发送确认后，进入 time-wait

注意，此时 TCP 连接还没有释放掉，然后经过时间等待计时器设置的 2MSL 后， A 才进入到close状态
在四次挥手期间，服务端不接收报文而发送RST报文给客户端，客户端收到RST报文会报错(NoHttpResponseException)

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/620321.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Java项目：07 Springboot的客户管理系统

Java项目：07 Springboot的客户管理系统

作者主页：舒克日记 简介：Java领域优质创作者、Java项目、学习资料、技术互助 文中获取源码 项目介绍 springboot客户管理系统 功能模块：登录修改密码客户列表充值列表消费记录客户类型 环境：IDEAjdk1.8Tomcat9MySQL5.7maven3.6…
阅读更多...
POI-tl 知识整理：整理2 -＞ 标签

POI-tl 知识整理：整理2 -＞ 标签

1 文本标签 {{var}} 数据模型： String ：文本 TextRenderData ：有样式的文本 HyperlinkTextRenderData ：超链接和锚点文本 Object ：调用 toString() 方法转化为文本 代码示例： Testpublic void testText…
阅读更多...
Jenkins 问题

Jenkins 问题

从gitlab 仓库拉去代码到Jenkins本地报错 ERROR: Couldn’t find any revision to build. Verify the repository and branch configuration for this job. 问题原因： 创建条目》配置的时候，gitlab仓库不存在master分支 修复后：
阅读更多...
【学习】FPGA verilog 编程使用vscode，资源占用多 卡顿 卡死 内存占用多解决方案

【学习】FPGA verilog 编程使用vscode，资源占用多 卡顿 卡死 内存占用多解决方案

问题描述 FPGA verilog 编程使用vscode，资源占用多 卡顿 卡死 内存占用多解决方案。 32G内存，动不动就暂用50%！！ 解决方案 1.打开设置 文件->首选项->设置 或者点击软件界面的左下角的齿轮按钮 2.进入如下【设置】界面 …
阅读更多...
网络安全B模块（笔记详解）- 网络渗透测试

网络安全B模块（笔记详解）- 网络渗透测试

LAND网络渗透测试 1.进入虚拟机操作系统：BT5中的/root目录，完善该目录下的land.py文件，填写该文件当中空缺的Flag1字符串，将该字符串作为Flag值（形式：Flag1字符串）提交；（land.py脚本功能见该任务第6题） 输入flag sendp(packet) Flag：sendp(packet) 2.进入虚拟机操作…
阅读更多...
JavaScript-3

JavaScript-3

Web API 基本认知 作用和分类 作用：就是使用 JS 去操作 html 和 浏览器分类：DOM ( 文档对象模型 )、BOM ( 浏览器对象模型 ) DOM 是什么 DOM ( Document Object Model —— 文档对象模型 )它是用来呈现以及与任意 HTML 或 XML 文档交互的 API通俗的说…
阅读更多...
MongoDB认证考试小题库

MongoDB认证考试小题库

Free MongoDB C100DBA Exam Actual Questions 关于MongoDB C100 DBA 考试真题知识点零散整理 分片架构 应用程序 --> mongos --> 多个mongod对于应用来说，连接分片集群跟连接一台单机mongod服务器一样分片好处， 增加可用RAM、增加可用磁盘空间、…
阅读更多...
缓存和数据库一致性

缓存和数据库一致性

前言： 项目的难点是如何保证缓存和数据库的一致性。无论我们是先更新数据库，后更新缓存还是先更新数据库，然后删除缓存，在并发场景之下，仍然会存在数据不一致的情况（也存在删除失败的情况，删除…
阅读更多...
如何高效进行项目文档的编制及管理？

如何高效进行项目文档的编制及管理？

“做完一个项目到底会产出多少份文档？” 今天看到这样一个吐槽贴：小李作为刚入行的项目经理，每天上班期间电话、会议、邮件各种不停歇，晚上还要加班做各种文档；由于经验不足，熬到十一二点还做不完是常态。…
阅读更多...
Vue学习笔记五--路由

Vue学习笔记五--路由

1、什么是路由 2、VueRouter 2、1VueRouter介绍 2、2使用步骤 2、3路由封装 3、router-link 3.1两个类名 3.2声明式导航传参 4、路由重定向、404 当找不到路由时，跳转配置到404页面 5、路由模式 6、通过代码跳转路由---编程式导航&传参 路由跳转时传参 跳转方式…
阅读更多...
Java 并发之《深入理解 JVM》关于 volatile 累加示例的思考

Java 并发之《深入理解 JVM》关于 volatile 累加示例的思考

在周志明老师的 《深入理解 JVM》一书中关于 volatile 关键字线程安全性有一个示例代码（代码有些许改动，语义一样）： public class MyTest3 {private static volatile int race 0;private static void increase() {race;}public …
阅读更多...
亚马逊时尚如何运用人工智能帮助您找到合适的尺码

亚马逊时尚如何运用人工智能帮助您找到合适的尺码

每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领…
阅读更多...
Docker五部曲之一：容器术语介绍

Docker五部曲之一：容器术语介绍

文章目录 前言背景基本术语容器镜像容器镜像格式容器引擎容器容器主机注册中心容器编排 进阶术语容器运行时镜像层标签存储库名称空间 参考 前言 本文内容翻译自参考文献。 背景 要理解容器术语，重要的是要精确地理解容器是什么。容器实际上是两个不同的东西。像…
阅读更多...
Linux驱动学习—I2C总线

Linux驱动学习—I2C总线

1、应用层实现I2C通信 1.1 I2C简介 I2C是很常见的一种总线协议，I2C是NXP公司设计的，I2C使用两条线在主控制器和从机之间进行数据通信。一条是SCL（串行时钟线），另外一条是SDA(串行数据线)，因为I2C这两条数…
阅读更多...
Windows Server 2019配置多用户远程桌面登录服务器

Windows Server 2019配置多用户远程桌面登录服务器

正文共：1234 字 21 图，预估阅读时间：2 分钟 很久之前，在介绍显卡直通的时候我们简单介绍过RDP（Remote Desktop Protocol，远程桌面协议）（前人栽树：失败的服务器显卡操作&a…
阅读更多...
第 3 场 蓝桥杯小白入门赛 解题报告 | 珂学家 | 单调队列优化的DP + 三指针滑窗

第 3 场 蓝桥杯小白入门赛 解题报告 | 珂学家 | 单调队列优化的DP + 三指针滑窗

前言 整体评价 T5, T6有点意思&#xff0c;这场小白入门场&#xff0c;好像没真正意义上的签到&#xff0c;整体感觉是这样。 A. 召唤神坤 思路: 前后缀拆解 #include <iostream> #include <algorithm> #include <vector> using namespace std;int main()…
阅读更多...
Android平台RTMP推送|轻量级RTSP服务|GB28181设备接入模块之实时快照保存JPG还是PNG？

Android平台RTMP推送|轻量级RTSP服务|GB28181设备接入模块之实时快照保存JPG还是PNG？

JPG还是PNG&#xff1f; JPG和PNG是两种常见的图片文件格式&#xff0c;在压缩方式、图像质量、透明效果和可编辑性等方面存在显著差异。 压缩方式&#xff1a;JPG是一种有损压缩格式&#xff0c;通过丢弃图像数据来减小文件大小&#xff0c;因此可能会损失一些图像细节和质量…
阅读更多...
【AIGC】IP-Adapter：文本兼容图像提示适配器，用于文本到图像扩散模型

【AIGC】IP-Adapter：文本兼容图像提示适配器，用于文本到图像扩散模型

前言 IPAdapter能够通过图像给Stable Diffusion模型以内容提示&#xff0c;让其生成参考该图像画风&#xff0c;可以免去Lora的训练&#xff0c;达到参考画风人物的生成效果。 摘要 通过文本提示词生成的图像&#xff0c;往往需要设置复杂的提示词&#xff0c;通常设计提示词变…
阅读更多...
系列十一、Spring Security登录接口兼容JSON格式登录

系列十一、Spring Security登录接口兼容JSON格式登录

一、Spring Security登录接口兼容JSON格式登录 1.1、概述 前后端分离中&#xff0c;前端和后端的数据交互通常是JSON格式&#xff0c;而Spring Security的登录接口默认支持的是form-data或者x-www-form-urlencoded的&#xff0c;如下所示&#xff1a; 那么如何让Spring Securi…
阅读更多...
Open3D 反算点云缩放系数（21）

Open3D 反算点云缩放系数（21）

Open3D 反算点云缩放系数（21） 一、算法介绍二、算法实现1.方法12.方法2（通用）一、算法介绍 上一章按照指定的系数，对点云进行了等比例缩放，这里输入缩放后的两块点云，反算二者之间的缩放系数。 二、算法实现 已知使用的俩点云是1/2的缩放关系，用于验证计算结果是否…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023