ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

传输层 transport TCP UDP

2021-08-18 11:32:00  阅读:186  来源: 互联网

标签:UDP 重传 ACK 报文 TCP 发送 传输层


传输层 transport

一、简介

传输层有两个协议:TCP、UDP

TCP: 传输控制协议

UDP: 用户数据报协议

二、TCP UDP的区别

TCP UDP
连接性 面向连接 无连接
可靠性 可靠传输,不丢包 不可靠传输,尽最大努力交付,可能丢包
首部占用空间
传输速率
资源消耗
应用场景 浏览器、文件传输、邮件发送 音视频通话、直播
应用层协议 HTTP、HTTPS、FTP、SMTP、DNS DNS

区别的文字描述

1、是否建立连接:TCP需要建立连接。UDP不需要
2、是否可靠 :由于TCP建立的传输通道,不会丢包,所以是可靠传输,而UDP不是,可能丢包
3、传输速率:TCP需要建立连接,所以传输速度较慢吗,,UDP较快
4、应用场景不同:由于以上特性,TCP通常用在浏览器、文件传输、邮件发送等场景,UDP通常在音视频通话、直播等场景应用。
5、对应的应用层协议也不同:TCP对应 HTTP、HTTPS、FTP、SMTP、DNS。UDP对应DNS协议。

三、UDP 用户数据报协议

1、数据格式

  • UDP首部为固定8个字节

2、介绍UDP首部

  • 源端口号/目标端口号:端口号,客户端的源端口号是随机端口,服务器端口号比如8080、8888 等
  • UDP长度: 首部的长度 + 数据的长度
  • UDP检验和: 伪首部 + 首部 + 数据
UDP伪首部:是计算 UDP检验和 需要的,由 (源IP地址+目的IP地址+0+17(代表UDP协议)+UDP长度) 组成,他只是计算用,并不在UDP里面,不会传递给网络层

四、TCP 传输控制协议

1、数据格式

  • TCP首部为至少20个字节(20字节 - 60字节)

2、介绍TCP首部

  • 源端口号/目标端口号:端口号,客户端的源端口号是随机端口,服务器端口号比如8080、8888 等

  • 序号:这次传给对方的TCP数据部分的第一个字节的编号,在传输过程的每一个字节都会有一个编号

  • 确认号:期望对方下一次传过来的TCP数据部分的第一个字节的编号

  • 数据偏移:数据偏移 * 4 等于首部的长度(首部的长度为20字节 - 60字节)

  • 标志位:
    URG:当URG=1时,紧急指针字段生效,表明当前报文字段中有紧急数据,应优先尽快传送,传送的是紧急指针指向的数据。
    ACK:当ACK=1时,确认号字段生效。
    PSH: 不重要。
    RST(reset):当RST=1时,连接中出现严重差错。需要重新建立连接。
    SYN:当SYN=1、ACK=0,标识是建立连接的请求,若对方同意建立连接,则回复SYN=1、ACK=1。
    FIN(finish):表明数据报已发送完毕,要求释放连接。

  • 窗口(window):告知对方下一次允许发送的数据大小,所以有流量控制功能

  • 检验和:和UDP一样, = 伪首部 + 首部 + 数据 不会传递给网络层

TCP伪首部:是计算 UDP检验和 需要的,由 (源IP地址+目的IP地址+0+6(代表tcp协议)+tcp长度) 组成,他只是计算用,并不在UDP里面,不会传递给网络层
  • 思考:为什么TCP的首部比UDP的首部复杂很多?
  • 答:因为TCP要保证可靠传输,流量控制,拥塞控制等。

五、TCP 可靠传输

一 简介

TCP可靠传输: 就是保证不会丢包,丢包是会重传。

二 重传的几种方式

1、超时重传:停止等待ARQ协议

2、连续ARQ协议 + 滑动窗口协议 + SACK(选择性确认)

和停止等待ARQ协议不同的是,滑动窗口会知道每次可以传送最多多少数据,发送方会一次传送多个包,然后停止发送,等待确认,若接收到确认包,滑动窗口滑动到下个数据报继续传送,若中间有丢包情况,例如:1、2、3、4中的3丢了,接收方给发送方的确认包是2,那发送方会冲床3、4,由于4其实已经成功传过去了,为提高性能,有了SACK(选择性确认)技术,配置支持SACK(选择性确认)技术,这种情况,发送方就只会重传3.

三 SACK(选择性确认)

SACK 信息会放在TCP首部的选项部分

kind:值为5代表是SACK选项
Length:代表SACK选项一共占多少字节
Left Edge:左边界
Right Edge:右边界
SACK选项最多携带4个边界信息,因为TCP首部的选项部分最多40字节,一对边界信息占8字节,加上kind,length。SACK最多字节数= 4 * 8 + 2 = 34

上图的意思,发送方给 接收方 发了1 - 1000 的10个包,其中棕色的包代表传过去了,白色的包代表丢失了,此时开启了SACK选项的话,接收方 给 发送方确认收到M2包, TCP首部中可选部分会记录,收到了
Letf Edge = 301,Right Edge = 401,
Letf Edge = 501,Right Edge = 601,
Letf Edge = 701,Right Edge = 801,
Letf Edge = 901,Right Edge = 1001,
发送方收到之后就知道M3,M5,M7,M9包修饰,就会重传这几个包

  • 思考:若有个包重传了N次还是失败,会一直持续重传到成功为止么?

  • 答:这个取决于系统设置,有的系统设置重传5次还未成功就会发生eset报文(RST)断开连接

  • 思考:为什么选择在传输层将数据分成多段,而不是网络层或者数据链路层?

  • 答:因为可以提高重传性能。
    因为可靠传输是在传输层进行控制的
    如果在传输层不分段,若丢包,整个传输层的数据都需要重传
    如果在传输层分段, 若丢包,只重传丢包的一段数据即可

六、TCP 流量控制

  • 简介
    TCP流量控制:点对点 接收方有缓存的概念,接收方通过确认报文中的窗口字段来控制发送方的发送速率,最大只能给我发送这么多,超过就会丢包,要重传。

  • 思考:极端情况,一开始,接收方给发送方发送了0窗口的报文段,后面,接收方有了缓存空间,给发送方发送的非0窗口报文丢失,发送方一直以为的0,此时怎么办?

  • 答:当发送方收到0窗口通知时,会停止发送报文,并启动一个定时器,隔一段时间就发个测试报文询问最新的窗口大小,如果接受的窗口还是0,则发送方会再次刷新定时器

七、 TCP 拥塞控制

一 简介

TCP拥塞控制:避免网络中的路由器或者链路过载,防止过多数据输入到网络中的一个规则

二 方法

  • 慢开始
  • 拥塞避免
  • 快速重传
  • 快速恢复
1、 慢开始

cwnd(拥塞窗口):是由发送方估计链路的拥塞程度计算出来的
cwnd的初始值比较小,然后随着数据包被接收方确认,收到ACK,cwnd就会指数级增长(例如2,4,8,16…..)

2、拥塞避免

ssthresh(slow start threshold):慢开始阈值
拥塞避免:当cwnd滑动窗口到达阈值后,cwnd会以线性方式增大,加法增大
乘法减小:只有网络出现拥塞(丢包),会把ssthresh减为拥塞峰值的一半,同时执行慢开始,cwnd恢复为初始值

拥塞避免作用:防止网络过早出现拥塞
3、快重传

快重传:要求接收方每收到一个失序的报文段就立即发出重复确认(使发送方及早的知道有报文段没有收到)而不要等到自己发送数据时才捎带确认。

快重传算法规定,发送方只要一连收到三个重复确认(总共4个相同的确认)就应当立即重传对方尚未收到的报文段,而不必继续等待为其设置的重传计时器到期再重传。

4、快恢复

快恢复:当发送方连续收到三个重复确认时,说明网络出现拥塞,就执行“乘法减小”算法,把ssthresh减为峰值一半,但不执行慢开始算法,cwnd不恢复到初始值,而是cwnd设置为新的ssthresh值,然后开始执行拥塞避免算法(加法增大)。

快重传 + 快恢复

  • 注释:发送窗口 = min(拥塞窗口,接受窗口)

八、TCP 建立连接 3次握手

解释状态
客户端:

closed : client(客户端)处于关闭状态
SYN-sent:表示client已经发送SYN报文,等待server的第二次握手
established:表示已经建立连接

服务器端

listen:server(服务器)处于监听状态,等待client连接
SYN-RCVD: received,表示server接收到了SYN报文,当收到client的ACK报文后,会进入established状态
established:表示已经建立连接

解释报文

SYN:同步建立连接请求
ACK:建立请求的反馈
seq:序号,本次发送的数据的第一个数据的编号
ack:确认号,反馈给对方我希望你下一次数据从这个编号开始发送

注释:
  • seq 和 ack 在TCP建立连接时基本没有作用,是在建立连接之后传输数据时起主要作用
  • 在TCP建立连接时,双方会交换确认一些信息,比如是否支持SACK,Window scale(窗口缩放系数)等,这些数据放在TCP头部的选项部分中
思考:为什么TCP建立连接需要3次握手,而不是2次?
  • 答:主要目的是防止server端的一直等待,浪费资源
    比如场景:
    如果建立连接只需要2次握手,可能会出现的情况:
    假设client发出的第一个连接请求报文段,因为网络延迟,在连接释放一会的某个时间才到达server
    本来这是一个早已经失效的连接请求,但server收到此失效的请求后,误认为client再次发送一个新的连接请求
    于是server就向client发出确认报文段,同意建立连接
    如果不采用“3次握手”,那么只有server发出确认,新的连接就建立了
    由于现在client并没有真正想连接服务器的意愿,因此不会理睬server的确认,也不会向server发送数据
    但server却以为新的连接已经建立,并一直等待client发来数据,这样,server的很多资源就白白浪费了

因此,采用“3次握手”可以防止上述现象发生。

思考:TCP建立连接过程中,第三次握手失败了,会怎么处理?
  • 答:此时server端处于SYN-RCVD状态,若等不到client的ACK,server会重新发送SYN+ACK包,如果server多次(发送几次是由不同系统决定的)发送SYN+AVK都等不到client的ACK,就会发送RST包,强制关闭连接。

九、TCP 释放连接 4次挥手

解释状态
客户端:

FIN-wait-1:表示想主动关闭连接
向对方发送了FIN报文,此时进入到FIN-wait-1状态

FIN-wait-2:只有对方发送ACK确认后,主动方就会处于FIN-wait-2状态,然后等待对方发送FIN报文

Time-wait:表示收到了对方的FIN报文,并发出ACK报文,等2MSL后进入closed状态(MSL:最大分段生存周期,规定,这个可以保证FIN,ACK报文会失效,不会发生重新发送报文,自己收到不,导致资源浪费的状态)

closed:关闭状态

服务器端

close-wait:表示在等待关闭
当对方发送FIN给自己,自己会回应一个ACK报文给对方,此时则进入到close-wait状态
在此状态下,要考虑自己是否还有数据要发送给对方,如果没有,则发送FIN报文给对方

Last-ACK:被动方在发送FIN报文后,等待对方的ACK报文是处于last-ack状态,收到对方的ACK报文后,会进入closed状态

closed:关闭状态

两端

Closing:一种比较罕见的状态,表示双方等正在关闭
表示你发送FIN报文之后,没有收到对方的 ACK报文,而是收到了对方的FIN报文,比如如果双方几乎同时给对方发送FIN报文,这时会出现closing状态

注释:
  • TCP/IP协议允许任何一端先发起断开,例子是以客户端先发起断开
思考:为什么要4次挥手?
  • 答:因为TCP是双工模式。
    主动方想断开之后,被动方仍然可以发送数据给对方,当被动方没有数据发送,需要断开连接时,再发送报文,并主动方告知接收到,
    最后的如果不等主动方回馈的ACK报文,有可能网络不好时,被动方发出的FIN报文,主动方没有收到,导致资源浪费

十、总结

标签:UDP,重传,ACK,报文,TCP,发送,传输层
来源: https://www.cnblogs.com/miaomiaocat/p/15156043.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有