【网络】-- TCP协议格式及可靠性

hello Jimmy

已于 2023-08-12 09:52:26 修改

阅读量713

点赞数

分类专栏： Java基础文章标签：网络 tcp/ip 网络协议

于 2023-04-13 19:14:34 首次发布

本文链接：https://blog.csdn.net/weixin_44158872/article/details/130136712

版权

Java基础专栏收录该内容

27 篇文章 0 订阅

订阅专栏

文章目录

- - TCP

TCP

传输控制协议

TCP(Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议

1.TCP报文段格式

TCP报文段格式

📢📢报头固定长度部分信息段介绍：

源端口：表示由该进程发送数据；
目的端口：表示数据发送到该进程；
序号：表示对字节流进行编号，目的是对请求方数据的管理；
确认序号：期望收到的下一个报文段的序号，由响应方发送，告诉请求方下一次该发送的报文段序号；
数据偏移：指的是数据部分距离报文段起始处的偏移量，实际上指的是**TCP首部（报头）**的长度。具体表示该TCP首部有多少个32位bit（有多少个4字节），所以当数据偏移是15（1111）时，TCP首部最大长度是 15 * 4 = 60 字节。这也说明TCP报头的长度是可变的；
6位标志位：（0表示无效，1表示有效）；
- URG：紧急指针是否有效；
- ACK：表示响应；
- PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走；
- RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段；
- SYN：请求建立连接；我们把携带SYN标识的称为同步报文段；
- FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段；
窗口：表示滑动窗口的大小，由响应方设置，目的是控制发送数据的多少，因为响应方的数据缓存空间有限；
校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分；
紧急指针：标识哪部分数据是紧急数据；

2.核心机制 – 安全机制（可靠性）

🎯🎯TCP协议保证数据传输可靠性的方式主要有：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制。

1.确认应答

通过确认号告诉发送方已接收发送的数据以及通知接下来要发的数据，确认号为发送数据的最后一个字节的序号加一。

如下图所示，假设每次发送1000条数据，那么确认应答会发送一个ACK，其中的确认号为1001，告诉发送方前1000条数据已经收到，该发送接下来的1000条数据了。

💡💡不等待应答，直接发多个数据，网络传输的先发后至的情况：

两个主机之间，路线存在多条，数据1和数据2走的都是不同路线，数据1转发路径上的路由器/交换机和数据2转发路径上的路由器/交换机也不一样，此时，这俩数据报到达顺序会有变数。

而因为有了序列号，接收的数据和响应的数据都会被排序，所以就不会产生错乱的后果。

序号与确认序号：

2.超时重传

🎯🎯发送方发送数据却没有收到响应，那么在设定的时间到达后会重新发送数据。而造成收不到响应的原因有两种：

一种是数据丢包，另一种是应答数据丢包。如果是第一种直接重传就行。

📌📌值得注意的是第二种的应答丢失的情况，在重传后接收方如何处理重复收到的数据？

答：可以通过报头信息的序号来判断是否为重复数据，是则删除。

如果重发一次之后，仍然得不到应答，等待 2500ms 后再进行重传。如果仍然得不到应答，等待 4500ms 进行重传。依次类推，以指数形式递增。累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。

3.连接管理

🎯🎯就是三次握手建立连接，四次挥手断开连接。

3，4

🔎🔎三次握手流程：

第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

📌📌问：为什么是三次，两次可以吗，四次为什么不行？

答：

三次握手：因为SYN和ACK是同一时机触发的，所以他俩能合并。

两次握手：假设客户端向服务器发送建立连接请求。

两次握手指取消最后一次ACK，那么这样会导致服务器不确定客户端接收功能是否有问题。
进而导致资源浪费问题：

客服端向服务器发送建立连接请求，但是这个请求在传输过程中出现问题而滞留了，由于长时间未得到响应已经重传等操作，而这个连接请求绕了半天又找到服务器了，要建立连接，服务器接收请求然后响应后就视为建立连接，但是客户端已经将此连接请求视为无效，所以服务器的资源被占用。

🔎🔎四次挥手流程：

第一次挥手：主机1（可以使客户端，也可以是服务器端），向主机2发送一个FIN报文段；这表示主机1没有数据要发送给主机2了；

第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，主机2告诉主机1，我“同意”你的关闭请求；

第三次挥手：主机2向主机1发送FIN报文段，请求关闭连接；

第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段；主机2收到主机1的ACK报文段以后，就关闭连接；

📌📌问：为什么是四次挥手？

答：

首先第二次和第三次不一定能合并，因为ACK和FIN是不同时机触发的，只要收到请求则会立即ACK，而FIN则要根据程序。

其次经历四次挥手，通讯双方都知道对方关闭连接，如果减少挥手次数可能导致不确定是否断开连接，造成资源浪费。如果增加挥手次数，四次已经关闭连接，那么增加的挥手是多余的。

📌📌问：为什么TIME-WAIT状态要等2MSL？

保证客户端ACK到达服务器，即没有任何响应，服务器正确断开。
保证双方的报文全部在网络中消失，防止影响新的连接。
如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。客户端的ACK在1MSL时间内丢失，然后服务器再次主动发送FIN关闭请求，这两个一来一回最大时长为2个MSL。

4.滑动窗口（效率机制）

📢📢滑动窗口的目的是指无需等待确认应答而可以继续发送数据，窗口的大小表示发送数据的最大值。如下图所示为普通发送数据然后响应和使用滑动窗口的对比：

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段)。
发送前四个段的时候，不需要等待任何ACK，直接发送；
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推；
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
窗口越大，则网络的吞吐率就越高；

💡💡丢包问题：

使用滑动窗口相当于并发发送多条数据，那么就要考虑丢包问题，自然就是双向发送谁丢包，是数据丢包还是响应ACK丢包：

对于ACK丢包，只要下一个ACK能收到，就可以确定这个数据是发送过去了，可以继续发送数据。

📌📌为什么下一个收到上一个就行？

先了解数据丢包的情况，当数据丢失，发送端会一直收到 1001 这样的ACK。如果发送端主机连续三次收到了同样一个 “1001” 这样的应答，就会将对应的数据 1001 - 2000 重新发送。这个时候接收端收到了 1001 之后，再次返回的ACK就是5001了（因为2001 - 5000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。

再看为什么下一个ACK收到就可以忽略上一个ACK的丢包，因为这一次的ACK是建立在上一次的基础上的，这次的ACK在发送端接受到就说明之前的数据就已经到了。