TCP 协议的相关特性

Starry灬

已于 2024-07-29 18:28:02 修改

阅读量951

点赞数 22

文章标签： tcp/ip 网络服务器

于 2024-07-29 18:22:19 首次发布

本文链接：https://blog.csdn.net/Brenda_Bestow/article/details/140775611

版权

1.TCP

1.1 TCP特性

TCP协议是有连接、可靠传输、面向字节流和全双工的传输层通信协议

TCP可靠性的基石：

传输顺利时，使用确认应答保证可靠性。
出现丢包时，使用超时重传作为补充。

1.2 报文格式

真正的结构是这样的：

2.TCP十大核心特性

2.1 确认应答

确认应答是TCP可靠通信的最核心机制，TCP是可靠传输，可靠性指的不是数据100%能到达对方，而是尽可能的传输过去，所以要确认数据是否真的到达对方了

这里接收方会返回一个应答报文（ACK），会引入序号和确认序号的概念，建立应答报文和传输的数据之间的对应关系

序号：按照字节编号，连续递增。确认序号：序号的最后一个字节+1.

例如：A给B发送了1-1000的数据序号，B返回序号1001，这里就代表B告诉A，1001以内的数据我都收到了，接下来要1001后面的数据了

2.2 超时重传

超时重传是对确认应答的一个重要的补充，组成正常情况下，TCP是通过确认应答来知道数据是否被对方收到了，A给B发消息，如果B没有收到A的数据，此时B不可能给出任何应答报文，如果A没有收到B返回的ACK（应答报文），此时A就可以判断出现了丢包。

A从发送数据之后，到正常收到ACK，肯定也会经历一些时间，A就会进行一定的等待，如果等待时间超过了某个阈值，此时就可以认为出现丢包，发现丢包后，进行重传，把刚才发的数据再传输一遍，如下图所示

如果数据报顺利到达，但是返回的ACK丢了捏？

其实站在 A 的角度, A 无法区分是数据丢了,还是 ACK 丢了,A 能看到的都是没有收到 ACK!!!
A 做的事情只能是触发重传！！

因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。

这时候我们可以利用前面提到的序列号，就可以很容易做到去重的效果。

那么，如果超时的时间如何确定？

最理想的情况下，找到一个最小的时间，保证 "确认应答一定能在这个时间内返回"。
但是这个时间的长短，随着网络环境的不同，是有差异的。
如果超时时间设的太长，会影响整体的重传效率；
如果超时时间设的太短，有可能会频繁发送重复的包；

2.3 连接管理机制（安全机制）

图中我们要注意两个状态
A. 服务器的第二个状态,LISTEN,代表服务器服务器已经做好连接的准备,可随时与客户端建立连接.
B. 客户端与服务器的最后一个状态都是ESTABLISHED,代表此次连接建立成功,可以正常通信.
如果面试题中,要求描述三次握手的过程,我们只需画出下图.
三次握手的本质是,各自要向对方发起一次建立连接的请求,并在接收到对方的请求时立即返回一个ACK.

首先,必须由客户端主动发起建立连接的请求,发送的syn为同步报文段
服务器在收到建立连接请求后,会立即返回一个ack.
之后,由服务器发起建立连接的请求.
最后,客户端在接收请求后立即返回一个ack.

上述过程由内核自动完成，应用程序干预不了。等到连接完成，服务器accept把建立好的连接从内核拿到应用程序中。

B收到了A的问话，此时B知道：A麦克风正常，自己的耳机正常
A收到了B的回答和问话，A知道：自己的耳机和麦克风正常；B的耳机和麦克风正常。
B收到A的回答，B知道：自己的麦克风正常；A的耳机正常。
确认了客户端和服务器各自的发送能力和接收能力都正常，这就是后续可靠传输的基础

注：上述流程中间的syn和ack拆开分别发送同样能够达成目的。但是没有必要，分层两次发送效率不如合并成一次（封装和分用）。

客户端向服务器发送一个fin（结束报文）
服务器接收到fin后，向客户端返回一个ack
服务器同时向客户端发送一个fin
客户端接收到fin后向服务器返回一个ac

注：ack和fin有一定概率合并成一个的，但是通常情况下不能合并。

三次握手：ack和syn是同一个时机触发的（都是内核来完成的）
四次挥手：ack和fin则是不同实际触发的，ack是内核完成的，会在收到fin时的第一时间返回；fin则是应用程序代码控制的，在调用到socket的close方法时才会触发fin

2.4 滑动窗口

滑动窗口的出现时为了提高TCP传输效率的,我们没有引入滑动窗口之前,TCP的大量时间都浪费在了等待ack上面,这时候我们便想到了一个办法 一次传输多个数据,

一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

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

2.5 流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此 TCP 支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制（ Flow Control ）；

● 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端
● 窗口大小字段越大，说明网络的吞吐量越高；
● 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；发送端接受到这个窗口之后，就会减慢自己的发送速度；
● 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

2.6 拥塞控制（安全机制）

然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。

因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

TCP引入慢启动机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；

刚开始,窗口大小为1,试探网络拥塞程度
发现未丢包,以指数形式扩大窗口
引入慢启动阈值,达到阈值,这里阈值为16,则停止指数增长,开始进行线性增长.
网络拥塞达到极限,窗口重新回到慢开始阶段.
进行新一轮的重复.

2.7 延迟应答（效率机制）

如果接收数据的主机立刻返回ACK应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为1M。一次收到了500K的数据；如果立刻应答，返回的窗口就是500K；
但实际上可能处理端处理的速度很快，10ms之内就把500K数据从缓冲区消费掉了；
在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
如果接收端稍微等一会再应答，比如等待200ms再应答，那么这个时候返回的窗口大小就1M；