日升时奋斗,日落时自省
目录
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>如果心跳结束,那就是没了