TCP 协议(包含三次握手，四次挥手)(1)-CSDN博客

本文链接：https://blog.csdn.net/2401_84004012/article/details/137930123

当 B 回复 A 的消息时，若存在对应关系，那么即使出现了"后发先至"的情况，也能顺利的确立应答

在这里插入图片描述

上述方法，虽然可以顺利的确立应答，但额外的信息很多，占用的带宽很多

下面如图，针对发送的请求进行编号，应答的时候也针对编号进行应答，这样既能保证数据传输没有歧义，也不会浪费太多的空间和带宽

在这里插入图片描述

序号和确定序号，在上篇TCP报文格式中提到过

上述情况不严谨，真实的 TCP 还不一样，TCP 是面向字节流的，此处的编号并不是按照一条两条来编的，而是按照字节来编号的 (每个字节有一个编号)

在这里插入图片描述

确认应答是一种特殊的报文(ACK)，所谓的应答报文，本质上就是 ACK 字段为1 的报文，此时报头中的"确认序号"字段才是生效的

初始序号是随机的，为了防止网络攻击；如果发送多个数据，每个数据都会带着一个序号

接收方收到数据后，是知道数据所带着的序号的，根据序号给出确认序号(告诉发送方下次给我发的序号)，发送给发送方，发送方就知道接收方收到了哪些数据

在这里插入图片描述

2.超时重传

确认应答是比较理想的情况，但数据在传输过程中，可能是会丢包的

仍以上面例子为例，A 给 B 发消息，你在家嘛？等了很久，A 也没收到 B 的消息，此时，存在以下几种情况：

① B 不想回 A 的消息

② B 没收到 A 的消息 (丢包情况1: 发的请求丢失)

③ B 回复了消息，但 A 没收到 (丢包情况2: 应答的 ACK 丢失)

②③情况：丢包的两种情况，对于发送方来说无法确定是哪种情况，因此，进行统一处理：当发送了一条数据之后，TCP 内部就会自动启动一个定时器，达到一定时间也没收到 ACK，定时器就会自动触发重传消息的动作 —— 超时重传

①情况：

思考：

假设第二次重发没有成功，那么就存在两个超时时间 t1，t2 如图所示：

那么，t1 和 t2 时间一样长吗？？

在这里插入图片描述

在 TCP 中，t2 会比 t1 更长

TCP 抱着一种 “悲观的态度”，当一次丢包重传之后，TCP 就觉得大概率后面的重传也没用，所以就隔一个更长的时间，节省带宽

上述丢包有两种情况，一种是请求丢失 —— 重传没有问题；一种是 ACK 丢失，重传就意味着接收方收到了相同的数据

TCP 会在内部进行数据去重 (以序号为 key 进行去重)，保证应用层读到的数据不是重复数据

确认应答 和 超时重传是 TCP 可靠性中最核心的机制

3.1建立连接 - 三次握手 ▲

为什么要就建立连接？

1.更好的保证可靠性: 建立连接的过程其实就是让通信双方验证各自的发送能力和接受能力是否正常

2.协商一些重要参数 (如: 序号的初始值)

具体怎样建立连接？

举例：A 给 B 打电话，打电话同样要验证自己以及对方的话筒和听筒是否正常工作

在这里插入图片描述

第一次握手： 刚开始，A 不知道自己和 B 手机的听筒和话筒是否正常，所以 A说"喂，你能听到吗?"

第二次握手： B 听到后，说明 A 的话筒和 B 的听筒正常，但 B 还需进一步检查自己的话筒和 A 的听筒是否正常；同时 B 把 A 话筒正常和自己听筒正常的消息传递给 A；于是 B “我能听到，你呢？”

第三次握手： A 收到 B 的消息后，就证明了 A 听筒正常，B 话筒正常

以上三次握手就保证了 A、B 的听筒和话筒都正常，也就保证了通话的正常，这就类似于网络建立连接时的三次握手

TCP 中真实的建立连接过程： (假设主机 A 主动发起连接)

在这里插入图片描述

第一次握手： 客户端向服务器发送 SYN 报文 (SEQ=x，SYN=1)，并进入 SYN_SENT 状态，等待服务器确认
第二次握手： 实际上是分两部分来完成的，即 SYN+ACK (请求和确认) 报文

服务器收到了客户端的请求，向客户端回复一个确认信息 (ack=x+1)

服务器再向客户端发送一个 SYN 包 (SEQ=y)建立连接的请求，此时服务器进入 SYN_RECV 状态

第三次握手： 客户端收到服务器的回复 (SYN+ACK 报文0)；此时，客户端也要向服务器发送确认包 (ACK)；此包发送完毕客户端和服务器进入 ESTABLISHED 状态，完成 3 次握手

建立连接的过程，相当于通信双方各自给对方发送 SYN，在各自给对方发送给 ACK，只不过中间的 ACK 和 SYN 合二为一了，于是最后就是"三次握手"

在这里插入图片描述

几个重要的状态:

LISTEN: 正在侦听来自远方的 TCP 端口的连接请求，服务端启动后处于 LISTEN 状态用于监听不同客户端的 TCP 请求并建立连接
SYN_SEND / SYN_RCVD: 建立连接的中间过程，若连接顺利的话(建立连接过程也可能丢包)，这两个状态就一瞬消失
ESTABLISHEN: 连接建立完毕 (验证了通信双方的发送和接受能力都正常)，可以进行数据传输

1.两次握手可以吗？？

不可以

防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源

两次握手只能保证单向连接是通畅的 (为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的；三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认）

.

2.为什么是三次？？

主要是为了建立可靠的通信通道，保证客户端与服务端同时具备发送、接收数据的能力

.

3.四次握手可以吗？？

可以，但没必要

四次握手可以验证双方的发送接收能力正常，但是这样做效率比较低

.

3.2.断开连接 - 四次挥手 ▲

三次握手: 双方各自向对方发起建立连接的请求，再各自给对方回应，只不过，中间的 SYN 和 ACK 能合并在一起

四次挥手: 双方各自向对方发起建立连接的请求，再各自给对方回应，只不过，中间的 FIN 和 ACK 不一定能合并在一起

仍以打电话为例，如下图：

在这里插入图片描述

TCP 中真实的断开连接过程： (假设主机 A 主动断开连接)

在这里插入图片描述

第一次挥手: 客户端向服务器端发送断开 TCP 连接请求的 [FIN，ACK] 报文，在报文中随机生成一个序列号 SEQ=u，表示要断开 TCP 连接

此时，客户端进入FIN_WAIT_1 (终止等待1) 状态

第二次挥手: 当服务器端收到客户端发来的断开 TCP 连接的请求后，回复发送 ACK 报文，表示已经收到断开请求。回复时，随机生成一个序列号 SEQ=v；由于回复的是客户端发来的请求，所以在客户端请求序列号 SEQ=u 的基础上加 1，得到 ack=u+1

此时，服务端就进入了CLOSE_WAIT (关闭等待) 状态，客户端收到ACK后，就进入FIN_WAIT_2 (终止等待2) 状态

第三次挥手: 服务器端在回复完客户端的 TCP 断开请求后，不会马上进行 TCP 连接的断开。服务器端会先确认断开前，所有传输到客户端的数据是否已经传输完毕。确认数据传输完毕后才进行断开，向客户端发送 [FIN，ACK] 报文，设置字段值为 1。再次随机生成一个序列号 SEQ=w；由于还是对客户端发来的 TCP 断开请求序列号 SEQ=x 进行回复，因此 ack 依然为 x+1

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。