TCP协议


UDP和TCP对比

UDP和TCP是TCP/IP体系结构传输层中的两个重要协议,使用频率仅次于网络层的IP协议

image-20210701161037488

UDP是用户数据报协议,TCP是传输控制协议,这里的连接指的是逻辑连接关系而不是物理连接,UDP是无连接的,TCP是面向连接的

image-20210701161227368

UDP支持单播、多播以及广播,TCP仅支持单播

image-20210701161435700

UDP直接给应用层报文添加一个UDP首部,UDP对应用进程交下来的报文既不合并也不拆分,保留这些报文的边界,接收方的UDP收到UDP用户数据报后去掉UDP首部后交给应用程序,UDP是面向应用报文的

发送方的TCP把应用进程交付下来的数据块仅仅看作是一连串的无结构的字节流,将它们编号并存储在自己的发送缓存中,TCP根据发送策略从发送缓存中提取一定数量的字节,构建TCP报文段并发送,接收方的TCP一方面从接收到的TCP报文段中,取出数据载荷部分并存储在接收缓存中, 一方面将接收缓存中的一些字节交付给应用进程,也就是TCP是面向字节流的,这正是TCP实现可靠传输、流量控制以及拥塞控制的基础

image-20210701162433099

UDP向上提供无连接不可靠传输服务

TCP向上提供面向连接的可靠传输服务

image-20210701163004787

UDP用户数据报首部仅8字节

TCP报文段首部最小20字节,最大60字节

image-20210701163228403

总结

image-20210701163316806

TCP流量控制

一般来说,我们总是希望数据传输得更快一些,但是如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失

所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收

利用滑动窗口机制可以很方便在TCP连接上实现对发送方的流量控制

图片 描述
image-20210701164218140 ack=201表示201前的数据已经全部接收希望收到201及其后续数据,rwnd是TCP报文段首部中的窗口字段,取值300表示自己接收窗口为300
image-20210701164550174 主机A收到主机B对它们的累计确认,现在可将发送缓存中序号1~200的字节数据全部删除
image-20210701164835436 主机A的重传计时器超时了,主机A重新封装成一个TCP报文段发送出去,发送窗口内的数据已经全部发送了,不能发送新的数据,等待主机B的累计确认
image-20210701165225716 主机A通过主机B返回的rwnd调整自己的窗口
image-20210701165431752 主机A收到cwnd为0,于是自己的发送窗口调整成了0,不能再继续发送数据了
image-20210701165600989 为了解决这个问题,TCP为每个连接设有一个持续计时器,只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,如果计时器超时就发送一个零窗口探测报文,仅携带一字节的数据,对方确认这个探测报文段时,给出现在的接收窗口值,如果接收窗口仍然是0,则重新启动计时器
image-20210701170043712 TCP规定,即使接收窗口为零,页必须接收零窗口探测报文段,确认报文段以及携带有紧急数据的报文段,如果零窗口探测报文段丢失也不会发生死锁,因为零窗口探测报文段也有重传计时器,当重传计时器超时,零窗口探测报文段会被重传

image-20210701170405402

总结

  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
  • TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文

TCP拥塞控制

在某时间,若对网络中某一个资源的需求超过了该资源所能提供的可用部分,网络性能就要变坏,这种情况就叫做拥塞

在计算机网络中的链路容量(即带宽)、交换节点中的缓存和处理机等,都是网络的资源

若出现拥塞而不进行控制,整个网络的吞吐量将随输入负荷的增大而下降

image-20210701183150773

输入负载:代表单位时间内输入给网络的分组数量

吞吐量:代表单位时间内从网络输出的分组数量

image-20210701183237894

image-20210701183352431

慢开始

image-20210701183812184

传输轮次是指发送方给接收方发送数据报文段后,接收方给发送方发回相应的确认报文段

拥塞避免

image-20210701183922153

image-20210701184336075

慢开始是指一开始向网络注入的报文段少,并不是指拥塞窗口cwnd增长速度慢

拥塞避免并非完全能够避免拥塞,而是指在拥塞避免截断将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞

快重传和快恢复

image-20210701184716688

image-20210701184820312

image-20210701184924738

image-20210701185057454

image-20210701185154796

总结

image-20210701185243960

TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题之一

图片 描述
image-20210701192115710 如果超时重传时间很小就会造成,不必要的重传,使网络负荷增大
image-20210701192345846 如果超时重传时间过大,会造成,网络的空闲时间增大,降低了传输效率
image-20210701192449037 超时重传时间RTO应略大于往返时间RTT
image-20210701192727082 RTO计算公式
image-20210701192855763 RTT测量的困难

image-20210701193028857

image-20210701193121107

image-20210701193250734

image-20210701193313889

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

图片 描述
image-20210701193809369 TCP强烈前沿不推荐收缩,因为很可能发送方在收到这个通知之前就已经发送了窗口中的许多数据,现在又要收缩窗口不让发送,可能会就会产生错误
image-20210701194209559
image-20210701194354648 接收方只能对按序收到的数据中的最高序列给出确认,因此发送的确认报文段中ack=31表示之前的数据已经收到需要接收31及其以后的数据
image-20210701194540728 到目前为止可以将31到33号数据交付给应用进程,并将它们从接收缓存中删除
image-20210701194639311

image-20210701195123419

image-20210701195247618

image-20210701195341665

TCP连接

image-20210701195548491

TCP连接建立要解决以下三个问题

  • 使TCP双方能够确知对方的存在;
  • 使TCP双方能够协商一些参数(如最大窗口值,是否使用窗口扩大选项和时间戳选项以及服务质量等);
  • 使TCP双方能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配
图片 描述
image-20210701201318209 TCP服务器进程首先创建传输控制块,用来存储TCP连接中的重要信息,然后进入监听状态
image-20210701201456617 TCP服务器进程是被动等待来自TCP客户进程的连接请求而不是主动发起,因此称为被动打开连接
image-20210701201611483 TCP客户端进程也是首先创建传输控制块
image-20210701202023163 向TCP服务器进程发送TCP连接请求报文段,并进入同步已发送状态,SYN被设置为1,表明这是一个TCP连接请求报文段,序号字段seq被设置了一个初始值x,TCP规定SYN被设置为1的报文段不能携带数据,但要消耗掉一个序号
image-20210701202047602 如果同意建立连接,则向TCP客户进程发送TCP连接请求确认报文段,并进入同步已接收状态,不能携带数据,因为SYN被设置为1,但要消耗一个序号
image-20210701202359853 发送普通的TCP确认报文段,并进入连接已建立状态,ACK=1,表明这是一个普通的TCP确认报文段,序号字段seq被设置为x+1,TCP规定普通的TCP确认报文段可以携带数据,但如果不携带数据,则不消耗序号,在这种情况下发送的下一个数据报文段序号仍是x+1

TCP客户端进程最后为什么还要发送一个普通的TCP确认报文段,是否多余,换句话说是否能简化为两报文握手

image-20210701205020648

综上所述,采用三报文握手是为了防止已失效的连接请求报文段突然又传送到了TCP服务器,因而导致错误

小结

image-20210701205435242

TCP释放连接

image-20210701210453863

注意:FIN=1的报文段不能携带数据

如果没有2MSL会发生什么?

image-20210701210753220

TCP保活计时器

image-20210701210936970


文章作者: dyl
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 dyl !
  目录