文章目录
- 1.TCP
- 1.1TCP协议段格式
- 1.2可靠机制
- 1.2.1确认应答机制
- 1.2.2超时重传机制
- 1.2.3连接管理机制
- 1.2.4流量控制机制
- 1.2.5拥塞控制机制
- 1.3效率机制
- 1.3.1滑动窗口机制
- 1.3.2延迟应答机制
- 1.3.3捎带应答机制
- 1.4粘包问题(tcp问题,应用层的数据包)
- 2.UPD和TCP
- 2.1UPD和TCP的区别
- 2.2UDP问题
1.TCP
1.1TCP协议段格式
TCP:传输的数据的控制,可靠和效率是成反比:越可靠,效率越低,TCP是综合考虑了两者,取的一个均衡,不是保证绝对意义的可靠,也不是绝对意义的效率最高
1.2可靠机制
1.2.1确认应答机制
(1)发送的数据,接收端需要返回确认接收到数据报的应答
(2)数据会进行编号,并使用32位序号保存
(3)ack的标志位是1,会使用32位确认序号保存
(4)下一个是接受到的数据报连续序号的最大值+1(说明接收端将之前的数据全部接收到了)
1.2.2超时重传机制
(1)发送端超过一定的时限没有接收到ack应答包,就会进行重传
(2)这里的时限是动态变化的,与网络的环境有关,时限是成指数级增长的,重传达到一定的次数就会关闭连接
(3)没有接收到ack应答包,可能是发送数据丢包,也可能是ack应答丢包
(4)重传指的是数据包重新发送
1.2.3连接管理机制
-
建立连接:三次握手(建立连接本质是双方保存了一个连接状态)
流程:
(1)客户端发送syn,申请建立客户端到服务端的连接;
(2)服务端返回syn+ack,申请建立服务端到客户端的连接,其中ack是对第一个数据包的应答(注意:ack和syn可以合并一起发送,也可以分开发送,合并一起发送就是一个数据包,两个标志位置为1);
(3)客户端返回ack,对第二个数据包的应答;
-
断开连接:四次挥手
流程:
(1)客户端发送syn到服务端,申请关闭客户端到服务端的连接
(2)服务端返回ack,服务端的状态置为close_wait
(3)服务端发送fin到客户端,申请关闭服务端到客户端的连接,客户端的状态置为time_wait
(4)客户端返回ack,服务端状态置为closed,客户端等待一定的时间将状态置为closed
-
重点问题:
(1)双方的连接状态,为什么最后才是closed
客户端接收到第三个数据报不能马上置为closed,因为第四个数据报可能会发生丢包(服务端无法断开连接),服务端就会根据超时重传机制重新发送第三个数据报,此时如果客户端是closed就无法接收了,双方都要保证可靠的关闭连接,如果是一端关闭,一端还存在就会出现藕断丝连的情况
(2)第2,3个数据报为什么没有合并
第二个数据报是系统内核返回的,不需要程序写代码来发送,而第三个数据报是程序调用close方法发送的(服务端在关闭连接前可能还需要做一些其他的工作)
(3)第2,3个数据报是否可以合并
将第二个数据报放在缓冲区(可能立即发也可能不是),对应的第三个数据报也是发送到缓冲区,此时,如果第二个数据报还在缓冲区就可能合并发送
(4)服务端出现大量的close_wait的原因
服务端没有执行close方法(因为只有执行了close才会发送第三个数据报)
(5)客户端接收第三个数据报状态是time_wait需要等待多久
2msl,1msl是单个报文传输的最大时间,需要等待的是第四个返回及可能的重传数据
1.2.4流量控制机制
(1)发送端发送速度如果快于接收端,程序读取速度就可能导致接收缓冲区被打断进而引起系统丢包,重传再次丢包的问题(程序读取指的是程序从缓冲区读取接收的数据)
(2)tcp协议首部:16位窗口大小指的是流量窗口大小
(3)接收端接收能力有限,主动告诉发送端自己的接收能力(接收能力指的是接收端接收缓冲区后剩余的空间大小,返回的ack应答包还会使用窗口大小字段来设置接收能力的大小)
1.2.5拥塞控制机制
(1)网络状态不明的情况下,贸然的发送大量的数据报就可能产生网络拥塞
(2)含义:发送端发送数据之前先根据“拥塞窗口”来进行探路(拥塞窗口是动态变化的)
(3)如何变化:从1开始,先指数增长,再线性增长,网络拥塞导致大量丢包后重置为1
1.3效率机制
1.3.1滑动窗口机制
(1)作用:以并发的方式发送数据报,减少等待时间(通过叠加等待时间),提高数据传输效率
(2)窗口大小指无需等待应答而可以继续发送的数据报最大值
(3)窗口大小确定:窗口大小=min(流量窗口大小,拥塞窗口大小)
(4)滑动窗口的大小决定吞吐率(一定时间网络数据传输数量越大,吞吐率越高)
(5)滑动窗口滑动的方式:可以滑动的位置是下一个序号的最大值减去窗口的起始位置(下一个是x代表接收端在x序号之前的数据报都已接收)
(6)已确认接收的数据都是保存在缓冲区的(发送端保存在发送缓存区(可能需要重传),接收端保存在接收缓冲区(可能需要去重))
(7)发生丢包的情况:
①ack丢包:没有影响,后续的ack也能表示序号前的全部接收
②发送的数据报丢包:接收的ack下一个序号是接收端,接收到的连续序号最大值+1(如果中间有部分没有接收到就相当于不连续);快重传:连续3次接收到下一个是x就表示从x开始的数据报丢包,需要重传
(8)理解缓冲区:把网络数据传输理解为发快递对方返回一个应答
1.3.2延迟应答机制
(1)接收端返回流量窗口代表接收缓冲区的可用空间大小,如果立即返回流量窗口大小就会比较小,不划算(不划算的原因是接收端可能接收速度比较快,读走以后就可以设置的更大)
(2)接收端返回的流量窗口,不是立即返回而是等待一定的时间(等待一定的时间就是延迟应答的由来),这样返回的流量窗口大小就可能更大(流量窗口是滑动窗口大小的决定因素之一,而滑动窗口大小又是网络吞吐量的决定因素之一,所以是效率机制延迟时间应答效率就更高)
(3)延迟的条件是由数量和时间来限制(数量指的是每几个包)(时间指的是不能超过最大延迟时间,超过时间发送端就认为丢包会进行超时重传)
1.3.3捎带应答机制
不管是客户端还是服务端都既可以是发送端也可以是接收端,不管是客户端还是服务端接收到数据后返回的ack应答包(作为接收端),可以和发送的数据报(作为发送端)合并在一起发送给对方
1.4粘包问题(tcp问题,应用层的数据包)
- 应用层需要约定统一的协议,明确包与包之间的边界
- 没有明确边界就会出现粘包问题
(1)在传输层,如果基于tcp协议,面向字节流,没有关闭流可以一直收发数据 - 解决方案:明确包之间的边界
(1)固定大小的包:读、写都按照固定大小来发送\接收
(2)可变大小的包:发送时包含长度的信息,接收时就按照这个信息读取相应大小的数据,也可以使用分隔符 - udp协议:因为是面向数据报(发送数据是一整块的发,接收也是一整块的收),固不存在粘包问题
2.UPD和TCP
2.1UPD和TCP的区别
2.2UDP问题
(1)基于传输层udp协议设计一个可靠的/大小不限的数据传输?
在应用层自己写代码来实现类似tcp的可靠机制:引入tcp类似的字段(序号、确认序号等),引入可靠机制(连接管理机制等)