网络原理(TCP协议)

文章详细介绍了TCP协议的可靠性传输机制,包括确认应答、超时重传、滑动窗口以及连接的建立和断开(三次握手和四次挥手)。此外,还讨论了滑动窗口在不同情况下的工作原理,以及流量控制和拥塞控制在确保网络传输效率和稳定性中的作用。
摘要由CSDN通过智能技术生成

目录

1 TCP报文

2 TCP基本特性--可靠性传输

2.1 确认应答机制

2.2 超时重传

2.3 连接管理(三四握手,四次挥手)

2.3.1 建立连接:双方建立一个相互认同的关系(三次握手)。

2.3.2 建立连接两个重要TCP状态

2.3.3 断开连接:双方取消相互认同关系(四次挥手)。

 2.3.4 断开连接两个重要TCP状态

2.4 滑动窗口

2.4.1 正常情况下的滑动窗口机制

2.4.2 ACK丢失情况下的滑动窗口机制(没有影响)

2.4.3 数据包丢失情况下的滑动窗口机制(快速重传)

2.4.4 TCP滑动窗口可以无限大吗?

2.5 流量控制

2.6 拥塞控制

1 TCP报文

头部长度描述了TCP报头的长度,此处是4个字节,0-60,TCP的报头长度能发生改变,选项部分可有可无,可以有一个选项,也可以有多个选项。保留位也是可扩展的空间。

2 TCP基本特性--可靠性传输

在前面我们了解过TCP的有连接、全双工、面向字节流等特点,以上特点我们也在代码中有所体会。接下来我们了解一下可靠性传输,这是TCP存在的意义。

2.1 确认应答机制

  • 可靠传输是TCP中最核心的特征,确认应答机制是保证可靠性的最核心机制,上面六个特殊标志位中的第二位如果是普通报文,ACK为0,如果是应答报文,ACK就为1。
  • 我们在聊天过程中经常会遇到“后发先至”的情况,就是后面发送的消息先发送出去显示在对面,其中原因可能是网络上通信传输的路径较为复杂,可能两点之间两个报文走了不同的路线。这是网络基本结构导致的,难以避免,解决方案是针对请求和应答报文进行编号,在这个过程中引入序号,32位序号是针对数据进行编号,32位确认序号只针对ACK报文有效。TCP是一个字节流的协议,因此编号的时候就是按照字节的顺序编号的。
  • ack(相当于已读,是系统内内核负责的,会在收到请求后立即返回)和响应(相当于已读并给出回复,属于业务上的响应,是应用程序负责的,取决于代码)是两个不同的概念。

2.2 超时重传

  • 确认应答描述的是数据报顺利到达对方,对方给出响应,但是传输过程中可能会丢包,由于网络环境非常复杂,网络传输的过程会传输很多人的数据,在这个过程中如果很多数据报同一时间在同一个地点进行传输,导致这个地方的转发达到了转发上限无法快捷完成转发,就可能会导致一部分数据报超时。
  • 丢包的情况如何解决呢?此时就需要考虑超时重传来进行。假如我确定我发的数据丢了,就可以重新发送,报文连续丢包的概率很低,因此丢包后重传能解决这样的问题。假如另外一种情况是对方的数据丢了,我无法确定是我的数据丢了还是ACK丢了,但是无论何种情况,我都需要进行重传。但是此时对方的数据可能已经进行重传了,我就会发送重复的数据给对方。TCP接收方因为丢失ACK就会导致收到重复的消息,就会针对相同的信息进行去重(根据序号来去重)保证应用层代码通过socket读数据的时候,读到的不是重复数据。
  • 超时时间如何确定?一般系统里面会有一个配置项,描述超时的时间阈值,第一次丢包就会在到达超时时间阈值之后进行重传,如果重传的数据仍无响应,还会继续超时重传,第二次超时时间一般会比第一次时间更长。超时时间并非是均等的,而是逐渐变大的,此时可能就是网络问题,时间间隔就会变长。这样的重传重试几次后仍然无法传输就会尝试重置TCP连接(断开重连),如果还是连不上此时就直接释放连接了。

2.3 连接管理(三四握手,四次挥手)

  • 连接管理是用来描述TCP建立连接和断开连接的过程。TCP的连接是逻辑上的虚拟连接,例如主机A和主机B建立连接,主机A的系统内核记录一个数据结构包含了连接对象,B的系统内核中也记录一个数据结构包含和他连接的对象,此时我们就认为A和B建立连接了。

2.3.1 建立连接:双方建立一个相互认同的关系(三次握手

  • A向B申请连接→B给A回应→B向A申请连接→A给B回复。这里的申请建立连接是通信双方各自向对方申请尝试和对方建立连接,然后各自给对方回应。建立连接的时候其实是四次数据的交互,中间的两次其实是可以合并一起发送(收到加申请),因此就是三次握手。在TCP中的三次握手就是以下图中情景:如果syn这一位是1说明这是一个同步报文段(尝试和对方建立连接)。

ps:这里一定是客户端先握手

  • 建立连接的意义:①检查当前网络是否顺畅(三次握手建立连接不传输任何业务数据);②三次握手的同时就是在检查双方的发送能力和接受能力都是正常的(如果握手两次是不行的,测试是不完整的);三次握手过程中也在协商一些重要参数,例如TCP的序号不是从1开始,通常都是建立连接的时候协商了一个数字,目的是为了保证两个连接的序号有差别,如果连接断开又重连,接收方就可以区分当前收到的数据是哪次连接的。

2.3.2 建立连接两个重要TCP状态

  • LISTEN:服务器启动之后,绑定端口之后(new ServerSocket完成),相当于手机开机信号良好别人可以给他打电话了。
  • ESTABLISHED:连接建立后的稳定状态,相当于电话接通了可以进行通话。

2.3.3 断开连接:双方取消相互认同关系(四次挥手)。

  • 断开连接其实就是双方取消相互认同关系,通信双方各自向对方申请断开连接,再各自给对方回应。
  • 在这里四次挥手不一定能合并。

ps:这里可以是客户端先挥手,也可以是服务器先挥手

 2.3.4 断开连接两个重要TCP状态

  • CLOSE_WAIT:等待代码中调用close操作
  • TIME_WAIT:主动发起关闭的一方,就会进入TIME_WAIT,A处理完最后一个ACK后不能立即释放连接,而需要保持一定时间,为了万一最后的ACK丢失B还有机会进行重传fin,如果等待一定的时间后没有收到fin就认为ACK 顺利到达了。

2.4 滑动窗口

2.4.1 正常情况下的滑动窗口机制

  • TCP能够保证可靠传输,但是不能保证高效率,传输效率低于UDP。但是TCP在保证可靠性的同时在提高传输效率方面做出一定的努力。滑动窗口就是提高TCP传输效率的有效机制。
  • 在我们上述的应答机制中,大量的时间都浪费在ACK上,为了提升效率,就决定一波一波等ACK,就像你给对方发消息,对方回复的太慢,就决定发几条等对方回复,再发几条等对方回复,在这里等待对方回复的信息相当于没有发生改变。这里就把不需要等待就可以直接发送的数据的量,就称为窗口大小。
  • 若批量发送4条数据,就批量等待4条ACK,这里的窗口大小是4000(以字节为单位)。收到一个ACK就发下一个,而不是等待所有ACK都到了再发下一组。

  •  这里的效率高不高就看窗口的大小,窗口大就效率高,窗口小就效率低。

2.4.2 ACK丢失情况下的滑动窗口机制(没有影响)

  • ACK丢失不需要做任何的处理,不用做任何的处理,对传输没有任何影响。数据序号每次都会涵盖前面的序号,确认序号就能保证前面的数据都收到了,比如上大学就已经包含小学和初中这些学习阶段。

2.4.3 数据包丢失情况下的滑动窗口机制(快速重传)

  • 假如数据包丢失后没有意识到还在继续发送数据,对方ACK就会连续索要丢失的数据,当连续多次重复确认应答,就会重发丢失的数据报,对方接收丢失的数据包后,就会接收后面发的所有数据。上述设定只是把丢失的数据进行重传,没丢的数据包并没有进行重传,这种重传过程比较高效,不做多余的工作,因此叫做快速重传,搭配滑动窗口机制的超时重传。
  • 如果正好是最后一个数据丢失,也可以用超时重传方法来进行。

2.4.4 TCP滑动窗口可以无限大吗?

  • 上面我们说窗口越大速率越高,但是发送的速度快了,接收方就会应接不暇,如果速度对于接收方速度过于快,就会导致接收方就丢弃一部分的数据。
  • 由于TCP要保证可靠性,TCP就需要重传丢失的数据,就会加重接收方的负担,陷入恶性循环,因此滑动窗口不能无限大。
  • 因此就需要有其他的机制来掣肘发送速度,对速度做出限制。

2.5 流量控制

  • 流量控制机制就是在滑动窗口的基础之上对发送速率做出限制的机制,限制发送方的窗口不要过大。
  • 那窗口多大合适呢?此时就可以考虑一下接收方的意见,看看接收方觉得多快合适,这是接收方对于发送的反制,接收方根据自己的接受能力来反向影响发送方的发送速率。
  • 接收方的接收速率如何进行量化?此时接收方就需要使用接收缓冲区的剩余空间大小来作为发送方发送速率(窗口大小)的参考数值。
  • 接收方收到的数据就会先放到系统内核的接收缓冲区(内存空间:字节数组)中,等待接收方的程序通过socket api 把数据从接收缓冲区中读取走。接收方在收到发送方的数据后就会在ACK应答报文中把当前接收缓冲区剩余空间大小的值反馈给发送方。
  • TCP报头中有一个16位窗口大小就是当前接收方接收缓冲区剩余空间大小,这个字段必须在ACK为1的时候才有效,否则这个字段无效。16位能表示的最大数字就是64kb(65535),但是并不意味滑动窗口最大就只有64kb,在TCP报头的选项中会有一个特殊的值是窗口大小的扩展因子,可以扩大缓冲区剩余空间。
  • 如果接收端缓冲区满(窗口为0)的情况下发送方就会暂停发送,如果发送方不发数据,接收方就没法返回ACK,如果接收方不反回ACK后续缓冲区里有剩余空间如何反馈给发送方呢?此时就有一个数据报(窗口探测报文),不携带任何业务去探测一下窗口大下是多少。

2.6 拥塞控制

  • 流量控制就是通过接收方的处理能力来衡量发送方的速率。但是也不是完全根据接收方的接受速率来确定的,假如过程中某个节点出现问题也会发生丢包的情况,中间节点的情况难以估量,如何考虑呢?此时就要把中间节点视为一个整体,不断改变发送速率找到合适的发送速度,达到动态平衡。上述这种找寻动态平衡的过程就叫做拥塞控制。
  • 当流量控制和拥塞控制发生分歧听谁的?谁小听谁的,考虑短板。
  • 拥塞控制具体实现方式:TCP引入慢启动机制,先发少量的数据,如果不丢包就要放大拥塞窗口(拥塞控制下的窗口大小),开始的时候先指数增长(唰唰往上增),短时间内摸到底线,达到阈值就线性增长,设定阈值就是为了防止增长太快一下子就超出上限了,初始阈值一般四是系统配置的。指数增长过程遇到丢包情况就将这个数值设为新的阈值。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值