运输层协议:端到端协议
- 面向连接的传输控制协议 TCP
- 无连接的用户数据报协议 UDP
-主要任务:为相 互通信的应用进程 提供 逻辑通信服务-屏蔽:运输层向高层用户 屏蔽 了下面网络核心的细节(如网络拓扑、所采用 的路由选择协议等),使应用进程看见的就是好像在两个运输层实体 之间有一条 端到端的逻辑通信信道
TCP
为实现可靠数据传输,就必须增加许多措施(TCP连接管理、确认机制、 超时重传、流量控制以及拥塞控制)UDPUDP通信的双方传送数据之前 不需要建立连接
UDP不需要实现可靠传输,因此 不需要使用实现可靠传输的各种机制![]()
标识进程:进程标识符(PID)
区分进程:端口号(长度为16bit,取值范围是0~65535)
复用:应用层报文在运输层:用UDP协议封装-->UDP复用用TCP协议封装-->TCP复用两者都用IP协议封装-->IP复用![]()
用户数据报协议UDP:
- 无连接
- 支持一对一,一对多,多对一和多对多通信。
- 对应用层交付的报文直接打包,面向报文
- 尽最大努力交付,也就是不可靠;(靠应用层提供可靠性)
- 不使用流量控制和拥塞控制。
- 首部开销小,仅8字节
传输控制协议TCP:
- 面向连接
- 每一条TCP连接只能有两个端点, 只能是一对一(点对点)通信。
- 面向字节流(TCP不保证接收进程收到的数据块大小等于发送进程发出的应用层报文;但接收方进程收到的字节流必须和发送方进程发出的字节流完全一样)
- 可靠传输、流量控制、拥塞控制
- 首部最小20字节,最大60字节
- 全双工通信(连接两端同时发送和接受)
-
TCP 报文段的首部格式
- 序号:32bit
本TCP报文段数据载荷的第一个字节的序号
- 确认号:32bit
期望收到对方下 一个TCP报文段的数据载荷的 第一个字节的序号,同时也是对之前收到的所有数据的确认
- 确认标志位ACK
只有当ACK取值为1时,确认号字段才有效。ACK取值为0时,确认号字段无效TCP规定:在 TCP连接建立后,所有传送的TCP报文段都必须把ACK置1
- 数据偏移:4bit
以4B为单位,TCP报文段的首部长度
- 保留:6bit
保留为今后使用,目前置为0
- 窗口:16bit
以1B为单位,接收方目前允许对方发送的数据量,窗口值=报文段发送方的接收窗口(动态变化)
- 检验和:16bit
检查TCP报文段的 首部+数据载荷两部分
在计算校验和时,要在TCP报文段的前面加上12字节的伪首部![]()
- 同步标志位(SYN): 建立TCP连接
(1) SYN=1 ACK=0 TCP连接请求报文段(2) SYN=1 ACK=1 同意建立连接,TCP响应报文段
- 终止标志位(FIN): 释放TCP连接
FIN=1 TCP报文段发送完毕,释放TCP连接
- 复位标志位(RST): 复位TCP连接
RST=1 TCP连接出现差错、拒绝非法TCP报文段、拒绝打开TCP连接
- 推送标志位(PSH)
接收方收到PSH为1的TCP报文段就尽快交付给应用进程,不用等
- 紧急标志位(URG)
- 紧急指针 16bit 以1B为单位
URG=1 紧急指针字段有效
URG=0 紧急指针字段无效
选项:长度可变(最长40B)
- 最大报文段长度MSS 数据载荷字段最大长度 与接收窗口值没有关系
三报文握手
- 使TCP双方能够确知对方的存在
- 使TCP双方能够协商一些参数(例如最大报文段长度、最大窗口大小、时间戳选项等)
- 使TCP双方能够对运输实体资源进行分配和初始化 (缓存大小、各状态变量、连接表中的项目)
1 TCP客户、服务器都 关闭状态
2 TCP服务器进程 创建传输控制块TCB,进入监听状态
3 TCP客户进程
- 创建传输控制块TCB
- 发送TCP连接请求报文段(SYN=1,seq=x),进入同步已发送状态
4 TCP服务器
发送 TCP连接请求确认报文段(SYN=1,ACK=1,seq=y,ack=x+1),进入 同步已接收状态5 TCP客户
发送普通的TCP确认报文段(ACK=1,seq=x+1,ack=y+1),进入连接已建立状态
TCP规定:普通的TCP确认报文段 可以携带数据 ,但如果不携带数据,则不消耗序号6 TCP服务器
收到普通确认报文段,进入连接已建立状态
-
注意:
SYN=1 连接请求报文段、连接请求确认报文段 不能携带数据,但消耗一个序号
ACK=1 普通确认报文段 可以携带数据,不携带则不消耗序号
第三个报文段:防止已失效的TCP连接请求报文段突然传送到TCP服务器,导致错误(服务器资源浪费)
四报文挥手
1 TCP客户、服务器都 连接已建立状态
2 TCP客户
发送TCP连接释放报文段(FIN=1,ACK=1,seq=u,ack=v),进入终止等待1状态
(u=TCP客户传送数据的最后一个字节seq+1)
3 TCP服务器
发送TCP普通确认报文段(ACK=1,seq=v,ack=u+1),进入关闭等待状态
此时TCP连接 半关闭状态(TCP客户已经没有数据要发送,TCP服务器可能有数据发送)
4 TCP客户
接收TCP普通确认报文段,进入终止等待2状态
此时TCP服务器可能有数据传送
5 TCP服务器
发送TCP连接释放报文段(FIN=1,ACK=1,seq=w,ack=u+1),进入最后确认状态
6 TCP客户
发送TCP普通确认报文段(ACK=1,seq=u+1,ack=w+1),进入时间等待状态,等待2MSL,进入关闭状态,撤销传输控制块TCB
7 TCP服务器
收到TCP普通确认报文段,进入关闭状态,撤销传输控制块TCB
注意:
FIN=1 的报文段 即使不携带数据,也消耗一个序号
2MSL作用:
l 第一 ,保证发送的 最后一个 ACK 报文段能够到达TCP服务器而进入关闭状态l 第二 ,防止“ 已失效的连接请求报文段 ”出现在本连接中
TCP保活计时器
TCP流量控制
让发送方发送速率不要太快,使接收方来得及接收
方法:滑动窗口机制 控制发送方流量控制
接收窗口rwnd
持续计时器:TCP连接的任何一方收到零窗口通知,就启动
持续计时器设置的时间到期,就发送一个 零窗口探测报文段 (仅 携带 1 字节的数据)若窗口仍然是零,收到这个报文段的一方就 重新设置持续计时器若窗口不是零,则死锁的僵局就可以打破了-
TCP规定:即使接收窗口值为0,也必须接受 零窗口探测报文段 、确认报文段以及携带有紧急数据的报文段-如果 零窗口探测报文段丢失,能打破死锁吗?答:能, 因为零窗口探测报文段也有重传 计时器
TCP 的拥塞控制网络中,某一资源的需求 超过 该资源能提供的 , 网络性能就要变坏, 负荷增大,网络吞吐量下降-![]()
![]()
![]()
-根据拥塞信息的反馈形式,将闭环拥塞控制算法分为:(1)显示反馈算法:从 拥塞节点(路由器) 向源点提供拥塞状态信息 (涉及网络层)① 用ICMP源站抑制报文通知源站② 在路由器转发的分组中保留一个字段/比特(2)隐式反馈算法: 源点自身 观察网络(超时重传、往返时间RTT) (只在运输层-->因特网)
四种拥塞控制方法
慢开始
拥塞避免
ssthresh=cwnd/2
cwnd=1
-
快重传:使发送方尽快(尽早)进行重传,而不是等重传计时器超时再重传
- 要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
- 发送方一旦收到3个连续的重复确认,就将相应的报文段立即重传,而不是等该报文段的重传计时器超时再重传
快恢复:发送端收到连续三个重复的确认时,不执行慢开始算法,而是执行快恢复算法 FR
ssthresh=cwnd/2
cwnd=ssthresh
-
选择重传协议ack=n 序号到n为止的数据已正确接收,现在期望收到序号为n+1的数据TCP协议ack=n 序号到n-1为止的数据已正确接收,现在期望收到序号为n的数据-TCP可靠传输没收到确认前,发送窗口内全部发送,已发送的必须暂时保留![]()
确认报文段中的ack是 按序收到的数据最高序号-
超时重传时间RTO的选择
RTT 往返时间
RTTs 加权平均往返时间(平滑的往返时间)
karn算法:出现重传时,不重新计算 RTTs ,进而RTO也不会重新计算
修正的karn算法:出现重传时,RTO*2
TCP的 选择确认SACK
介绍 TCP 的快重传和可靠传输时, TCP 接收方 只能对按序收到的最高序号确认 。当发 送方 超时重传 时,接收方之前 已收到的未按序到达的数据也会被重传-