关于TCP的那些事儿

最新推荐文章于 2022-02-19 13:02:22 发布

iTXCode

最新推荐文章于 2022-02-19 13:02:22 发布

阅读量830

点赞数 1

分类专栏：计算机网络

本文链接：https://blog.youkuaiyun.com/jack_wang128801/article/details/107026325

版权

计算机网络专栏收录该内容

4 篇文章

订阅专栏

在这里插入图片描述

图中的反复只是为了确认对方对你的 "请求" 是否有所 “回应”.

再比如,当你给朋友寄快递的时候,你寄完快递之后将单号拍了下来,发给了你的朋友并告诉他如果你收到这份包裹的话就给我发个消息或者回个电话.
这个快递发出去无非就是三种情况

1.你的朋友收到快递,给你发来确认信息
2.你的朋友收到快递,给你的回复消息的因断网而发送失败(他已经发送过了),你主动向你的朋友询问情况.或者他的消息你收到了,你清楚了他的接收情况.
3.你的朋友没有收到快递,快递在运输过程中丢失(朋友告诉你他没有收到快递).

这三种情况中都需要通过你朋友的回应来确定具体是那种情况,

而这里的回应确保了寄件人对📦去向的掌握.

之前学习的通过UDP协议传输的信息并不具备这种通过对方回应来确定对方是否收到包裹的功能

所以我们该怎么知道对方的接收情况呢？

其实也很简单,我们需要一种可以通过双方互动来确认包裹是否正确接收的协议,这就是我们今天将要介绍的TCP协议了。

TCP

报文格式

在这里插入图片描述
16位源端口

本机的数据从哪里出去

16位目的端口

对方的数据从哪里进去

32位序号字段,32位确认序号

TCP连接中传输的数据流中每一个字节都有对应的序号seq(主机内部随机产生).
这两部分和TCP的ACK机制有关,发送端给应用层收到的数据进行打码,接收端通过接收到的数据码回馈接收状态

4位数据偏移(首部长度)

指出TCP报文段的数据起始处距离TCP报文段的起始处有多远,“数据偏移”的单位是32位字(以4字节位计算单位)(由于可选项和填充字段的存在,首部长度不固定)
标明正文位置

保留字段

该字段主要是为了以后扩展时使用,其长度为4位。

控制位
在这里插入图片描述

URG:当URG=1时,表名紧急指针字段有效,告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)
ACK:当ACK=1时确认号有效,ACK=0无效
PSH:当PSH=1就提示接收端应用程序立刻从TCP缓冲区把数据读走
RST复位标志,当RST=1表明TCP连接出现严重差错,必须释放连接,然后再重新建立运输连接
SYN同步标志:SYN=1表示这是一个连接请求或连接接收报文
FIN结束标志,用来释放一个连接, FIN=1表示此报文段的发送端的数据已发送完毕,并要求释放运输连接

16位窗口大小

与TCP滑动窗口、流量控制有关,根据接收方的接收窗口(接收缓冲区的空余空间大小)的大小决定发送端发送窗口(发送端发送数据的长度)的大小

16位校验和

校验和字段检验的范围包括首部和数据两部分,在计算校验和时,要在TCP报文前加上12字节伪首部

16位紧急指针字段

当控制位中的URG=1的时候才有意义,指出在本文中紧急数据字节数
选项:数据字段的最大长度MMS
填充：如果选项字段不是4字节的整数倍就用填充字段凑齐(使得TCP首部是4字节的整数倍)

TCP特点

TCP是面向连接(虚连接)的运输层协议
每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的(一对一)
TCP提供可靠交付的服务
TCP提供全双工通信

发送缓存:准备发送的数据和已发送但尚未收到确认的数据
接收缓存: 按序到达尚未被接受应用程序读取的数据和不按序到达的数据

面向字节流

流:流入到进程或从进程流出的字节序列,如下图所示
在这里插入图片描述

所谓的面向有连接的“连接”

连接管理

建立连接(三次握手)

先举个例子
在这里插入图片描述

用处
1.确定双方的交付能力
2.指定初始序列号(随机产生),为可靠传输做准备
3.交互保密机制
握手过程(粗略的说法)
1.客户端给服务器发送一个SYN报文(无数据部分)
2.服务器收到SYN报文后,会应答一个SYN+ACK报文(无应用层数据)
3.客户端收到SYN+ACK报文后,回应一个ACK报文(可携带数据)

在这里插入图片描述

握手过程(精确的说法)
1.客户端发送SYN报文,指定序列号ISN,处于SYN_Send状态
2.服务端把SYN作为应答,指定ISN,把客户端的ISN+1作为ACK值发送给客户端,此时服务器处于SYN_RECV状态
3.客户端发送一个ACK报文,此时客户端处于established状态
4.服务器收到ACK报文之后也处于established状态

补充:

半连接队列:服务器第一次收到客户端的SYN之后,就会处于SYN_RCVD状态,此时双方还没有完全建立其连接,服务器回把这种状态下请求的连接放入一个队列,我们把这个队列称为半连接队列(用于保存处于SYN_SEND 和 SYN_RECV状态的请求)
全连接队列:已经完成三次握手,建立起连接的就会放到全连接队列中,如果队列满了就会出现丢包的可能性.

SYN洪泛攻击(针对三次握手)

SYN洪泛攻击发生在OSI第四层,这种方式利用TCP协议的三次握手,攻击者发送TCP SYN,而服务器返回 ACK之后,攻击者就对其进行再次确认,那这个TCP连接就处于挂起状态,也就是所谓的半连接状态,服务器收不到在确认的话,还会重复发送给ACK给攻击者。这样更加会浪费服务器的资源,攻击者就对服务器发送非常大量的这种TCP连接,由于每一个都没完成三次握手,所以在服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了.

解决办法(SYN cookie)

SYN Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。

断开连接(四次挥手)

在这里插入图片描述
断开连接的过程(粗略)

1.客户端给服务器发送一个FIN结束报文（分手通知,调用close()函数）
2.服务器给客户端发送一个ACK确认应答（对方告诉你他知道了,收到FIN报文,理解返回ACK）
3.服务器也给客户端发送一个FIN结束报文（对方同意分手，也向你提出分手,调用close()）
４.客户端给服务器发送一个ACK确认应答（你收到对方的分手通知，断开连接）
精确一点的说法

刚开始两者都处于ESTABLISHED状态

假设客户端先发起关闭请求
1.第一次挥手:客户端发送一个FIN报文,报文中会指定一个序列号,此时客户端处于FIN_WAIT1状态
2.第二次挥手:服务器收到FIN之后,会发送ACK报文,且把客户端的序列号值+1作为ACK报文的序列号值,表明已经收到客户端的报文了,此时服务器处于CLOSE_WAIT2 状态
3.第三次挥手:如果服务器也想断开连接了,向客户端发送FIN报文,且指定一个序列号,此时服务器处于LAST_ACK 状态
4.第四次挥手:客户端收到服务器端的FIN报文后,发送一个ACK报文作为应答,且把服务端的序列号值+1作为自己ACK报文的序列号值,此时客户端处于TIME_WAIT 状态.需要过一阵子(2MSL)以确保服务端收到自己的ACK报文后才会进入CLOSED 状态
5.服务器收到ACK报文之后,就处于关闭连接了,处于CLOSED状态
FIN是函数close()进行触发的,由程序控制,而ACK是内核发送的.
第一个ACK和第二个FIN不一定能合并
连接管理的综合图
重要的TCP状态
1.LISTEN状态:服务器已启动,随时可以连接
2.ESTABLISHED状态:连接建立成功,随时可以通信
3.CLOSED_WAIT等待调用close()函数,对端已经执行过close()函数

如果服务器端出现大量的CLOSE_WAIT状态,

代码中忘记调用close

4.TIME_WAIT状态:

为什么客户端发送ACK之后不直接关闭,而要等一会才关闭?

因为最后发送的ACK也存在丢包的可能,所以客户端需要确保服务器已经收到了客户端发送的ACK
若最后发送的ACK丢包了,那么服务器端收不到确认应答就需要重发FIN报文给客户端,客户端再次收到FIN报文之后,就知道之前的ACK报文丢失了,重新发送ACK报文
TIME_WAIT会保持一个报文的来回时间(2MSL).MSL表示网络中的两个结点之间,传输一个数据所经历的最大时间.过了这个时间客户端没有再次收到FIN报文,就表示对方成功接收了ACK报文,此时处于CLOSED状态

TCP可靠传输

校验
序号
确认
重传

序列号与确认应答(保证可靠性)

在这里插入图片描述

在发送数据过程中,某段数据(图中编号为4,5,6)丢失了,那么接收端就会不断的向发送端请求这段数据.直到发送端进行重传

我们之前说的寄快递的例子,你的朋友告诉你他收到了包裹,你才能确定快递没有丢失.
而在TCP中,当发送端的数据到达接受主机时,接收端主机会返回一个已收到的消息通知给发送端,这个消息叫做确认应答(ACK),正如你朋友告诉你快递收到了,而在没有收到你朋友的回复的时候,你就会担心会反问他,这好比一个否定确认应答(NACK)
在这里插入图片描述

未收到确认应答的情况分为两种

1.数据(包裹)丢失,等待一端时间后(等待多久?)重新发送
2.数据已接收(快递已签收),但是返回的确认应答在途中丢失(确认消息因断网而没有发给你).等待一段时间(等待多久?)后重新发送

在TCP协议中,在没有收到确认应答的情况下.会将之前的没有收到ACK的数据重新发送一次.当然也有可能是网络原因导致的确认应答延迟到达,

对于这种情况,对于通信中的不同对象而言会造成不同的后果

对象	导致的问题
发送方	按照机制重发一份数据
目标主机	反复接收相同的数据
目标主机上层应用	必须放弃重复的数据包

为了解决这种情况带来的问题,我们需要引入一种既能识别已经接收数据,又能够判断是否需要接收该数据的机制

上述这种确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现.

序列号是按照顺序给发送的数据的每一个字节都打上一个码,接收端查询接收数据TCP首部中的序列号和数据长度,并将下一次应该接收的序号作为确认应答返回给发送方.

互动图
操作端模拟图
确认应答序号的含义是当前序号之前的数据已经收到了,希望收到的下一条数据就是从确认序号开始的

超时重发如何确定

在这里插入图片描述

超时重发是指在重发数据之前,等待确认应答到来的那个特定时间间隔,如果超过了这个时间仍未收到确认应答,发送端就会重新发送未收到确认应答的数据,那么这个超时重发的等待时间该怎么确定呢?

超时重发的计算既要考虑往返时间又要考虑偏差,是因为同一个报文在不同的网络环境中传输的速度是不同的.而TCP/IP 的目的是在于即使在不同的网络环境下也要对网络流量进行控制,不造成浪费.
在Unix和Windows系统中,超时都是以0.5秒为单位进行控制的,因此重发超时都是0.5秒的整数倍,不过,由于最初的数据报不知道这个时间,所以其重发超时一般设置为6秒左右.

数据被重发之后若还是收不到确认应答,则需要再次重发,此时等待确认应答的时间是以2的整数倍的方式延长的.

当然在网络中也不能对同一份数据反复进行重发,当这份数据的重发次数到达限制之后,仍然收不到任何确认应答.就会判断为网络或对端主机发生异常,强制关闭连接.并通知本端应用层通信异常强行终止连接.

滑动窗口与重发控制

在这里插入图片描述

发送方窗口的上限值 = Min [ rwnd, cwnd ]
当rwnd < cwnd 时，是接收方的接收能力限制发送方窗口的最大值。
当cwnd < rwnd 时，则是网络的拥塞限制发送方窗口的最大

TCP以1个段为单位,每发一个段就需要进行一次确认应答的处理,这样再等待ACK的这段时间里发送端是闲置的,那么就会使得TCP的传输效率低下.

为了解决传输效率低的问题,TCP引入了窗口这个概念.即使在往返时间比较长的情况下,他也能控制网络性能的下降.因此确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短.也就是说,发送端主机在发送了一个段之后不必要一直等待确认应答,而是继续发送(在窗口大小够用的情况下)

在这里插入图片描述

窗口大小:指无需等待确认应答而可以继续发送数据的最大值(真实的窗口大小值为流量控制和拥塞控制两者中的较小者).
发送前四个段的时候,不需要等待任何ACK,直接发送

收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据,依次类推.
操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有那些数据没有应答,只要确认应答过的数据,才能从缓冲区删掉

在这种机制下会出现的两种机制

情况一:数据包已经到达,返回的ACK丢失
这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认
例如:在发送了1~5000个自己的数据后均没有收到ACK,但是再发送了5001 ~ 6000 之后主机A收到ACK(下一个是6001),说明前6000个字节主机B　已经收到了,就不需要再去重发之前的数据了
情况二:数据包就直接丢了

当某一段报文丢失后,发送端会一直收到序号为丢失段的确认应答
如果发送端主机连续三次收到同样内容的确认应答,就会将对应的数据重新发送
当接收端收到丢失段的确认应答后,再次返回的确认应答就是之前已经接收过到数据,被放到了接收端操作系统内核的接收缓冲区中,如上图中的7001,这种机制被称为"高速重发控制(也叫"快重传")"

流量控制

接收端处理数据的速度是有限的,如果发送端一直保持高速发送,就会导致接收端的缓冲区很快就被填满,之后如果接收缓冲区中的数据没有被读走(接收端缓冲区没有空余空间)，发送端继续发送数据就会造成丢包,继而引起包重传等一系列的连锁反应

因此TCP支持根据接收端的处理能力,来决定发送端的发送速度,这个机制叫做流量控制
在这里插入图片描述

接收端将自己可以接收的缓冲区大小放入TCP首部中的"窗口大小"字段,通过ACK报文通知发送端.
接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端
发送端接受到之后,就会减慢自己的发送速度
如果接收端缓冲区满了,接收端就会将窗口置为0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,让接收端把窗口大小告诉发送端
如上图中,当接收端收到从3001号开始的数据段后其缓冲区满了,需要暂停数据的接收.之后,在收到发送窗口更新通知后通信才能继续进行.但是这个更新通知可能在传送途中丢失,所以发送端会时不时的发送一个叫做 窗口探测 的数据段,此数据段仅含一个字节以获取最新的窗口大小信息

TCP 为每一个连接都设有一个持续计时器,只要TCP连接的一方收到对方的零窗口同时就启动持续计时器,若持续计时器设置的时间到期,就发送一个零窗口探测报文段.接收方收到探测报文段时给出现在的窗口值,若窗口仍然是0,那么发送方就重新设置持续计时器⏲

拥塞控制

在这里插入图片描述

为什么会引入拥塞控制?
因为,TCP滑动窗口虽然能高效可靠的发送大量的数据,但是在某个连接刚建立的时候并不清楚网络的拥塞状况,发出数据后迟迟收不到ACK,就可能进行重发.在不清楚网络状态的情况下就进行重发的话,会使拥塞情况更加严重,所以需要我们设计出一种可以控制网络拥塞情况的机制

网络中判定拥堵的依据:在交互过程中是否出现了丢包现像,若出现丢包,则认为比较拥堵。

慢启动(网络拥堵的解决)

TCP 引入了慢启动 机制,先发送少量数据,查看当前网络的拥堵情况,再决定按照多大的速度传输数据.

没有出现丢包就按指数形式增大窗口.若窗口大小达到阈值之后就开始线性增长,当窗口达到某个值后就会发生丢包,一旦发生丢包现像就认为网络出现拥堵,就立刻将窗口大小减小到一个很小的值.之后重复慢开始过程

在这里插入图片描述

当TCP开始启动的时候,慢启动阈值等于窗口最大值
每次发生超时重传,慢启动阈值就会减半,同时将拥塞窗口置为1

快重传和快恢复

快速重传(Fast retransmit)

要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到3个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计数器时间到期。

快速恢复(Fast Recovery)

1.当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意：接下去不执行慢开始算法。
2.由于发送方现在认为网络很可能没有发生拥塞，因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

真实的窗口大小值为流量控制和拥塞控制两者中的较小者

流量控制和拥塞控制和区别

流量控制是客户端和服务器之间(一对一)的传输问题
拥塞控制是多个客户端和同一个服务器交互过程中所发生的网络信道占用率较高等现象
拥塞控制的任务是确保子网可以承载所到达的流量。这是一个全局性问题，涉及到各方面的行为，包含全部的主机、全部的路由器、路由器内部的存储转发处理过程，以及全部可能会削弱子网承载容量的其他因素。
流量控制仅仅与特定的发送方和特定的接收方之间的点到点流量有关。它的任务是，确保一个高速的发送方不会持续地以超过接收方吸收能力的速率数据传输。流控制通常涉及到的做法是，接收方向发送方提供某种直接的反馈，以便告诉发送方别人一端的情形究竟怎么样。

延时应答(提高传输效率)

如果在收到数据报之后立即返回ACK,则有可能在ACK返回和下一次数据发送到来的这段时间内接收端的缓冲区已经比返回ACK的窗口大小要大了,这就导致网络资源利用率的降低

在这里插入图片描述

那么我们可以在第一次接收到数据后不立即返回ACK,而是暂缓一会再发送ACK,可能其在暂缓发送的这段时间里接收缓冲区中的数据就会拿走了,则ACK中返回的窗口大小就变大了,这个过程就是延时应答

那么暂缓的这段时间如何确定呢？

数量限制:每隔N个包就应答一次

上图中,每发两个包就应答一次
时间限制:超过最大延迟时间就应答一次

捎带应答

依赖于延时应答

在延时应答的基础上,引入的一个机制

TCP四次挥手有没有可能是三次呢?

有可能,因为稍等应答支持这件事情.
因为延时应答的存在,可能会使得第二次挥手和第三次挥手时间重合了,导致FIN和ACK在同一个包中发送给对方。这个过程就叫捎带应答

在这里插入图片描述

面向字节流

创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配,

例如:
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;

发送缓冲区调用send()本质上是把用户的数据拷贝到内核的发送缓冲区中,再由内核按照滑动窗口的方式把数据批量发送到对端,如果丢包就会重传对应的数据
接收缓冲区:收到的数据先到达接收缓冲区,用户代码从接收缓冲区中都读走(read/recv)数据后,才会把数据读走后才会清除掉,接收缓冲区也会帮助用户进行数据的去重