TCP协议十大特性

日升时奋斗,日落时自省 

目录

1、确认应答

1.1、序号编辑

2、超时重传

3、连接管理

3.1、三次握手

3.2、四次挥手

4、滑动窗口

5、流量控制

6、拥塞控制

7、延时应答

8、捎带应答

9、面向字节流

10、异常情况


TCP协议:

特点:有连接的、可靠传输、面向字节流、全双工

可靠性传输:是TCP内部的机制,和编码关系不大,咱们感知的不是很清楚

TCP详细图解

(1)首部长度

 4位首部长度:一个TCP报头,长度是可变的,不是像UDP一样固定8个字节

因此,首部长度就描述了TCP报头具有多长,另外,选项之前的部分是固定长度(20字节)

首部长度 - 20字节 ==得到的就是选项部分的长度

20字节表示的就是 源端口号+目的端口号+序号+确定序号+窗口大小+验证和+紧急指针+首部长度的大框框

首部长度解释:4bit位 

注:重要提示!!! 首部长度的单位 不是字节 是4字节  

举例(针对选项和首部长度的联系):

如果首部长度值为5 ,表示整个TCP的报头长度是20字节(相当于没有选项)

选项=首部长度-20字节=20-20=0

如果首部长度值为10,表示整个TCP的报头长度是40字节

选项=首部长度-20字节=40-20=20字节

TCP报文=TCP报头(首部)+TCP载荷

(首部包含了选项及以上     载荷就是数据)

(2)保留位

保留(resevered)位:顾名思义 占个位置起来先不用,进行程序开发的时候,其中一个重点考虑的事情就是可扩展性。有些功能可能暂时不需要,但不代表以后不会再开发。

此处TCP的保留6位,也是为了以后的扩展考虑的,对于网络协议来说,扩展升级,是一件成本极高的事情,这里以UDP提一下这方面的弊端,UDP报文长度是2字节,因此一个包最大64kb,现在能不能把UDP协议升级一下,让UDP能够支持更大的长度,比如把报头长度使用4字节表示;此情况理论上可以,但是修改后的操作系统如何让全世界能够进行更新升级(升级设备涉及广泛 计算机、路由器、手机等等都需要)不是技术问题,而是使用问题,很难做到替代当前所有的设备

“保留位”的引入此时升级操作就会成本低不少,如果后续TCP引入了一些新的功能,就可以使用这些保留位字段

注:对于TCP本来的报头结构的影响是比较小的,老的设备即使不升级也能兼容

(3)选项

option(选项)=>optional(可选的,可有可无的)此处的选项相当于对这个TCP报文的一些属性进行解释说明的

TCP内部的工作机制:

TCP 可靠传输 是怎样做到可靠的

可靠传输不是说一定能把消息发给接收方(因为这个可靠跟网线没有关系,物理设备都断了,那就不可能发过去了)

此处是尽可能把数据传输过去,同时,如果还是传输不过去,至少能知道

1、确认应答

提示:实现可靠传输的最核心机制

 TCP进行可靠性传输,最主要就是靠这个确认应答机制

其实简单化就是 A 给 B 发了个消息,B收到之后就会返回一个 应答报文(ACK),此时,A收到应答之后,就知道了刚才发的数据已经顺利到达B了

更加复杂的情况:

 很明显,此处这里的应答就错乱的,表达意思出现歧义

总结:网络“后发先至”现象客观存在,无法避免,因此应答报文到达的顺序也是可能发生变动的。此时就需要考虑如何规避这种顺序错乱带来歧义

如何解决上述“后发先至” ,看的出来以上出现问题的原因在于顺序上出错,办法很简单,给传输的数据,和应答报文都进行编号。

 引入序号以后此时就不怕顺序乱了,及时顺序乱了,序号就是最好判断方法

1.1、序号编辑

那序号是怎样编号的,当然不是以上编辑的序号不是按照“一条两条”这样的方式来编号的...TCP是面向字节流的,TCP的序号也是按照字节编号的

 TCP的字节的序号是依次累加的,这个依次累加的过程对于后一条数据说,起始字节的序号就是上一个数据的最后一个字节的序号,每个TCP数据报报头填写的序号只需要写TCP数据的头一个字节的序号即可。

TCP知道了头一个字节的序号,再根据TCP报文长度,可以知道每个字节的序号,确认序号的取值,是收到的数据的最后一个字节的序号+1

 总述:

<1>TCP可靠传输能力,最主要就是通过确认应答机制来保证的

<2>通过应答报文,就可以让发送方清楚的知道传输是否成功

<3>引入了序号和确认序号,针对多组数据进行详细的区分

2、超时重传

讨论确认应答的时候,只是讨论了顺利传输的情况,同样会产生问题:丢包???

丢包,涉及到两种情况:

<1>发的数据丢了

<2>返回的ACK丢了

发送方看到的结果,就是没有收到ACK区分不了是哪种情况,都是丢包的情况,针对丢包TCP是要处理的,因为丢包是一个概率性事件,(而且通常情况下,丢包概率已经很小了),重新发一下这个数据报,其实还是很大的概率成功传输(这里下面在做详细解释)

TCP直接引入重传机制:

在丢包的时候,就要重新再发一次同样的数据(到底当前这个传输,是丢包了,还是ACK走的慢,还没有被接收到)

此处TCP就直接引入了一个时间阈值,发送方发了一个数据之后,就会等待ACK,此时开始计时。如果在时间阈值之内,也没有收到ACK,无论是否ACK是在路上,还是彻底丢了,都视为是丢包了

超时重传,超过一定时间,还没响应,就重新传输

这个超时时间,具体是多少ms? 这个时间可以配置,并且不同系统上面的默认值可能存在差别

 以上带有重复数据或者操作(关键时候)可能会带来重大影响,但是针对以上重复数据或者操作带来的影响

TCP对于这种重复数据的传输,是有特殊处理,去重,TCP存在一个“接收缓冲区”这样的存储空间,(接收方操作系统内核里的一段内存)每个TCP的socket对象,都有一个接收缓冲区(发送缓冲区)

主机B 收到的 主机A的数据

其实是B的网卡读取到数据了,然后把这个数据放到B的对应的socket的接收缓冲区中,此处更像是一个优先级队列,根据数据序号,TCP很容易识别当前接收缓冲区里的这两条数据是否是重复的

自己本有这个功能,如果重复了,则把后来的这份数据就直接丢弃了,保证了应该程序调用read读取到的数据,一定是不重复的

TCP使用这个接收缓冲区,对收到的数据进行重新排序,使应用程序read到的数据是保证有序的(与发送顺序一致)

总结:由于去重和重新排序机制的存在,发送方只要发现ACK没有按时到达,就会重传数据,即使重复了,即使顺序乱了,接收方会处理好的

相应问题:

超时重传次数:重传的数据是否存在再次丢包?有可能,所以可能会重传N次(此处的N不是无限的),重传不会一直进行,重传几次还没有结果其实也就没有必要了,可能此时的网络出现问题了

举例:

传输丢包概率假设为:5%  第二次传输丢包的概率:5%*5%=0.25%

第三次还丢包的话,可想而知 0.25%*5% 等于的数字是何等的小,连续丢包能丢几次呀,概率实在太小了,所以多次丢包大可能是网络出现问题了,因为正常丢包不会太多次

因此,重新传输到一定次数的时候,就不会再继续重传,会认为网络故障,接下来TCP会尝试重置连接(网络重连),如果重置还是失败了,彻底断开连接

注:超时重传次数,可以配置

重传的时候,第一次重传和第二次重传,超时时间间隔,并不一样,执行重传时间上不是均匀的,一般情况,重传的次数越大,超时时间间隔就越大,因为超时重传次数越多,重传成功的概率就越小,此时重传的太快也是浪费资源,不如多等等(总结:超时时间变大,重传的频率降低)

总述:

<1>可靠传输是TCP最核心的部分,TCP的可靠传输就是通过 确认应答 + 超时重传 两者都是具体体现,共同支撑整体的TCP可靠性

<2>其中确认应答描述的是传输顺利的情况

<3>超时重传描述的是传输出现问题的情况

3、连接管理

连接管理:涉及到建立连接和断开连接

那连接(Connection)又是什么???如何做到连接的

以结婚类比:大体上结婚还是要有法律认可的结婚手段才是连接,法定结婚就是领证;领取的结婚证两个人一人一份,内容相同,但是针对两个人各自关注点不同

男方:认为了连接上了就是 这个结婚证上写  我老婆是这个女人

女方:认为了连接上了就是 这个结婚证上写  我老公是这个男人

这就是建立连接完成了

TCP 建立连接 :

断开连接:针对实际上来说,离婚就是断开连接

此处A和B把自己存储的连接信息(数据结构)删除,连接就是断开了

3.1、三次握手

建立连接(三次握手)

通信双方各自要记录对方的信息,彼此之间要相互认同(图解)

 上面看着也可以叫做“四次握手” 也能叫“三次握手”

只要不合并就可以叫做“四次握手”,针对这个就有两个问题???

为啥中间这两次要合并?不合并可以吗?

合并原因是:封装分用, 每次都要封装分用,都是要消耗成本的,所以必须合并,降低封装分用的成本

再问两次握手行不行???

答案:针对计算机肯定不行(图解)

 总结:三次握手,本质上是“四次”交互,为了降低封装分用的成本,必须进行合并操作;通信双方,各自要向对方发起一个“建立连接”的请求,同时,再各自向对方回应一个ACK。

三次握手另外一个重要作用:验证通信双方各自的发送能力和接收能力是否正常,同时也一定程度的保证了TCP传输的可靠性(起到的不是关键作用,辅助作用)

此处再举一个实例:

 三次握手的意义:

<1>让通信双方各自建立双方的“认同”

<2>验证通信双方各自的发送能力和接收能力是否可行

<3>在握手过程中,双方来协商一些重要的参数

以上都是简单以实例表现出出握手,以上实例每次的握手是一次通信同时也是一种协议

 3.2、四次挥手

四次挥手就是断开连接,“挥手”和“握手”都只是形象的叫法,都是客户端服务器的数据交互

四次挥手和三次握手非常类似,都是通信双方各自向对方发起一个断开连接的请求,同时再各自给对方一个回应

以上是举例理解四次挥手 (下面详细解析)

 

 TIME_WAIT保持连接不断开,那能保持多久??约定一个时间为 2MSL

如果经历了2MSL时间还是没有收到  重传的FIN  就认为这个ACK就正常到达了(认为对方没有重传FIN)

2MSL 指的是,互联网上两个节点之间数据传输消耗的最大时间,(约定俗成)MSL具体的准数是多少??一般情况下是60s(秒)

针对以上解释对四次挥手可能有点迷离:

四次挥手要做的事情这里简短的比喻一下:
<1>A发送 FIN

<2>B发送ACK

<3>B发送FIN

<4>A发送ACK

仅仅以上四次交互构成四次挥手(最后一个ACK没有丢包的情况下)

4、滑动窗口

TCP依存可靠性,所以传输效率就降低了很多比不上UDP(无可靠性)(可靠性和传输效率本身是相互矛盾的),TCP也有一些其他方法来补救传输效率,但是补救后仍然不及UDP,只是为了减少传输效率上针对TCP的影响;

滑动窗口的本质就是降低了确认应答,等待ACK消耗的时间

缩短渠道批量发送,批量等待,把多份等待时间合并成了一份

 滑动窗口基本理解就是如上图解析,但是有数据传输就有可能会丢包(以下解释丢包情况)

 5、流量控制

这是一种干预发送的窗口大小的机制

滑动窗口,窗口越大,传输效率就越高(一份时间,等的ACK就越多),当然窗口不能是无限大

<1>完全不等ACK,可靠性能否保障画上问号

<2>窗口太大,也会消耗大量的系统资源

<3>发送速度太快,接收方处理不过来,发了也白发

接收方的处理能力,就是一个很重要的约束依据,发送方法的速度,不能超出接收方的处理能力

流量控制要做的工作就是这个,根据接收方的处理能力,协调发送方的发送速度

那既然接收方的处理能决定发送的速度,如何探测接收处理能力??

直接看接收方接收缓冲区的剩余大小

 6、拥塞控制

流量控制和拥塞控制共同决定发送方的窗口大小是多少

流量控制:针对的是接收方的处理能力

拥塞控制:描述传输过程中的中间节点的处理能力

发送方按照滑动窗口的方式发送,此时“窗口大小”描述了发送速率

 拥塞窗口和流量控制的窗口,共同决定了发送方实际的发送窗口(拥塞窗口和流量控制窗口的较小值)

7、延时应答

同样也是提升效率的机制,也是在滑动窗口的基础之上

滑动窗口的关键,让窗口大小在有限的范围之内扩大一点,传输速度就快一点

因此要做的是,在接收方能够处理的前提下,尽可能的把把窗口大小放大一点

延时收到数据之后,不是立即返回ACK 而是稍微等会再返回

等待的时间里,接收方的应用程序,将接受缓冲区的数据给消费一下,此时剩余的空间会更大

 8、捎带应答

也是提高效率的方式,在延时应答的基础上,引入的捎带应答

服务器客户端程序,最典型的模型,就是“一回一答”  (此处举例解释捎带应答)

 9、面向字节流

面向字节流 引入问题:粘包问题

 重点:针对解决方法

<1>约定好分隔符

<2>约定每个包的长度

两个任选其中一个就可以了

10、异常情况

异常情况不可抗拒因素

(1)进程关闭的情况

<1>进程崩溃了

进程没了,对应的PCB就没了,对应的文件描述符表就释放了,相当于socket.close()

此时内核会继续完成四次挥手,此时其实仍然是一个正常断开的流程

<2>主机关机(按照正常流程关机)

主机正常关机要先杀进程,然后才正式关机(杀死进程的过程中,也就是和上面一样触发四次挥手)

(2)进程来不及关闭

<1>主机掉电

<2>网络断开

假设是接收方掉电了(断网)

显然是来不及挥手,发送方仍然在继续发数据,发完数据要等待ACK,都断电了,ACK是真的等不到了,超时重传,再怎么重传,也收不到ACK,重传几次,还没有应答,尝试重置TCP连接,显然这个重置也会失败,最终面临的就是放弃连接

假设是发送方掉电了(断网)

接收方发现,没数据了,没数据是发送方挂了,还是发送方要组织下语言,稍等会再发???

接收方不知道现在发送方的特殊情况 那先等

接收方需要周期性的给发送方发送一个消息,确认下对方是否还工作正常

周期性发送消息:心跳包(确认通信双方是处在正常的工作状态)

<1>心跳,是周期性的

<2>如果心跳结束,那就是没了

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值