TCP报文结构和相关特性

小曹Dayhappy.

已于 2023-04-22 11:57:53 修改

阅读量199

点赞数

文章标签： tcp/ip 网络网络协议

于 2023-04-20 17:42:47 首次发布

本文链接：https://blog.csdn.net/m0_71690645/article/details/130147162

版权

1.TCP基本概念

TCP是传输层一项非常重要的协议.TCP 为应用程序提供可靠的按顺序的字节流服务。

应用程序字节流通过 TCP 段通过网络传输，每个 TCP 段作为互联网协议（IP）数据报发送。

基本特性:

1.有连接

2.可靠性

3.面向字节流

4.全双工

2.可靠性

TCP最为重要的特性就是它的可靠性了.这里的可靠性不是指数据就一定可以发送成功.而是它会关心发送结果成功或者失败,会有回应.

下面有几个比较重要的特性就是围绕可靠性来展开的.

1.确认应答

当主机A给主机B发送数据,主机B给主机A的会有就是一个确认应答,也叫做ack.

TCP给每个字节都标了序号.

每个ack都会有一个确认序号,告诉发送者我已经收到了哪些数据以及要给我发送的下一个数据.

例:比如主机A给主机B发送了(1-1000)的数据,此时1-1000每个字节都是一个序列号,主机B返回的ack的确认序号为1001.即<1001的数据(1-1000)是主机B已经收到的数据.>=1001即为接下来主机A需要发送的数据.

2.超时重传

在网络中,在数据传输过程中常常会产生一个bug---丢包.丢包是什么意思呢?顾名思义，在通信中是指通信数据包丢失。数据在通信网络上是以数据包为单位传输的.

超时重传又分为两大类:

发送过程中(还未到达接收方)数据包丢失

此时数据并未到达接收方,是不会返回ack的.就需要重传

接收方返回的ack丢失

此时发送方仍然会重传!但是此时接收方是不是收到了重复的数据呢?

TCP有一个去重的功能,会在接收缓冲区中,根据收到的数据的序号进行自动去重,保证了应用程序读到的数据只有一份.

总结:可靠性的核心是确认应答和超时重传

3.连接管理

三次握手

建立连接:

握手指的是通信双方进行一次网络交互,此时的三次握手就指的是客户端和服务器之间,通过三次交互,建立了连接关系.

1.客户端向服务器发起连接请求;

2.服务器给客户端回复一个响应(答应连接),再向客户端发起一个连接请求;

3.客户端给服务器回一个响应,答应服务器的连接请求.

确认了客户端和服务器各自的发送能力和接受能力都正常!!!

注意:连接只有到最后一步完成,才真正建立成功.

而为什么是三次握手就可以了呢?我们下面通过一个例子来证实.

比如有两个人,陈宇和顾魏.陈宇和顾魏需要通过QQ语音确认各自的设备(耳机,麦克风)是否正常,才能一起打游戏.陈宇和顾魏约定协议:陈宇说Hello,顾魏回应Hi.

四次挥手

断开连接:通信双方各自给对方发一个Fin(结束报文),各自给对方返回一个ACK.

那么看到这里,一定还有一个疑问,为什么三次握手可以合并syn和ack,四次挥手就不可以合并fin和ack呢?

时机问题!

syn和ack是同一时机触发的,都是由内核来实现的;但是fin和ack不一样,是不同时机触发的,fin不是由内核完成的,而是由应用程序代码控制的.是在调用到socket的close方法时,才会触发.

服务器在发现客户端与自己断开连接后,会自己再调用一个close();这个close会触发第二个fin.

但是这个close执行的时机也分成两种情况:如果是立即close,则可以与ack合并;但如果是很久才执行,就不可以合并了.

以上都是TCP有关可靠性的功能,下面我们来讲一下效率问题.

3.效率

1.滑动窗口

滑动窗口是有关批量传输的.

批量传输:

发送方先给接收方发送一定数据后,停止发送,等待接收方ack.当接收方第一个ack到达发送方时,发送方又开始发送数据.

批量等待的数据就成为窗口大小.

(1)初始:ack(下一个1001)已经发送成功:

(2)发送方向接收方发送数据(1001-2000),接收方确认应答(下一个2001):

收到2001这个ack就意味着1001-2000的数据以及收到,此时就会发送下一个数据5001-6000.

(3)滑动窗口移动:

滑动窗口也会有丢包问题:

情况1:数据包已经到达,ack丢了

这种情况下,部分ack丢了没关系,因为ack有确认序号.比如2001丢了,但是5001ack发送成功,表示5001前的数据都收到了,那么此时ack2001有没有则不重要.

情况2:数据包直接丢了.

假设1-2000发送失败:

当重复收到几次同样的ACK发现不对,于是重传1-2000这个数据.(引发快速重传机制)

2.流量控制

由于滑动窗口是批量发送的,批量发送的数据越多,整体的速度就越快,然而,并不是越快就越好,可靠性永远是最重要的,那我们如何控制速度呢?

流量控制!!!让ACK报文里,携带一个"窗口大小"的字段.

发送方发送的数据,是存在接收方的接受缓冲区中的,如果发送方发的太快,会导致缓冲区缓冲不过来.进而造成丢包.流量控制的本质就是接收方限制发送方的速度.

流量控制是如何进行的呢?

1.接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发
送端

2.接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
3.发送端接受到这个窗口之后，就会减慢自己的发送速度；
4.如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一
个窗口探测数据段，使接收端把窗口大小告诉发送端。

3.拥塞控制

拥塞控制是衡量中间节点传输的能力,因为传输阶段任意一个节点遇到问题都会对整体产生影响.

下面我们来看一个拥塞窗口变化情况图:

对上图进行分析:

1.慢开始:刚开始传输时,会给一个非常小的窗口(如果刚开始就传输很大数据,不确定是否会造成拥塞)!!!

2.指数规律增长:当发现安全时,传输数据迅速增大,短时间内达到一个比较大的值;

3.拥塞避免加法增大:当传输数据达到ssthresh值时,由指数增长转变成线性增长,避免一下突然超过上限很多;

4.网络拥塞:增长到一定程度,丢包;又回归到一个比较小的初始值.设置新的ssthresh值.

上述过程其实很小谈恋爱:刚开始恋爱时,不熟悉,然后迅速感情升温到热恋期;热恋期后,感情稳定增长;吵架分手.再次复合,进入热恋期(此时的峰值自然是比第一次低的).

4.延时应答

ACK要发,但不是立即发

窗口大小与流量控值(接收缓冲区的剩余空间大小)以及拥塞控制有关

当立即返回一个ACK,ACK里有一个窗口大小,设置为n;

当延时应答时,返回的窗口大小大概率是大于n的,因为此时应用程序已经消费了一批缓冲区的数据.

延时应答起到的效果:

延时,顾名思义,当接收方延迟发ACK时,应用程序就能从缓冲区中读多点数据,进而使反馈ACK的窗口大小变大,提高发送方发送速率.

5.捎带应答

基于延时应答

客户端和服务器在大部分情况是一对一的,A对B发请求,B对A发响应.

当ack延时应答,就可能与response合并成一个数据包.此时的传输效率就会变高.

4.其它

1.面向字节流

这里最重要的就是粘包问题!

什么是粘包呢?

当A给B连续发了很多个应用层数据报之后,这些数据报就都会积累到B的接收缓冲区中;当应用程序尝试从接收缓冲区读取数据时,无法区分从哪到哪是一个完整的数据报.

解决方案:

(自定义应用层协议)

1.定义分隔符 2.约定长度

2.异常处理

1.进程关闭

此时连接依然在线.

2.主机关机(正常程序)

杀死所有用户进程;如果刚好四次挥手挥完,则恰好.

如果没有挥完,当对方发来的fin过来了,还没来得及发送ack,就关机了.此时对方会重新发送fin,几次过后仍然没有收到ack,就尝试重新连接;如果还不行,直接放弃连接.

3.主机掉电(拔电源)

(1)对端是发送方

对方收不到ack,重传.

(2)对端是接收方

对端收不到数据,不知道是数据已经发了,还是已经没了.TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放.

4.网线断开

同上

总

以上十个特征是TCP的核心机制.确认应答(1)和超时重传(2)是TCP的核心保证,连接管理(3)也是与可靠性相关联的;TCP既想有可靠性,又想有效率,在此基础上,引入了滑动窗口(4),批量传输数据;接着引入了流量控制(5)和拥塞控制(6)制约滑动窗口的大小,避免传输速率太快.延时应答(7)也是基于滑动窗口的,延时应答,返回的窗口大小就会大一些,进而提高传输速率(前提是接收方应用程序不断消费数据).捎带应答(8)基于延时应答,将ACK和响应合二为一,提高效率.TCP是一个面向字节流(9)的协议,这里引入了一个粘包问题;当我们连续给接收方发送多个数据报时,这些数据会堆积在接收缓冲区中,接收方应用程序无法区分从哪到哪是一个完整的应用层数据报.异常处理(10),在这里有一个"心跳包"机制,可以通过心跳包来查看对方是否是一个正常的工作状态.