网站开发小图标,好看的企业网站模板,网站建设平台推广,wordpress投稿申请3.1 概述和传输层服务
传输服务和协议#xff1a; 为运行在不同主机上的应用进程提供逻辑通信#xff1b; 传输协议运行在端系统-发送方:将应用层的报文分成报文段#xff0c;然后传递给网络层#xff1b;接收方#xff1a;将报文段重组成报文#xff0c;然后传递给应用…3.1 概述和传输层服务
传输服务和协议 为运行在不同主机上的应用进程提供逻辑通信 传输协议运行在端系统-发送方:将应用层的报文分成报文段然后传递给网络层接收方将报文段重组成报文然后传递给应用层 有多个传输层协议可供应用选择
网络层服务主机之间的逻辑通信 传输层服务进程间的逻辑通信——依赖于网络层的服务延时、带宽。并对网络层的服务进行增强 可靠的、保序的传输TCP -多路复用、解复用 -拥塞控制 -流量控制 -建立连接
不可靠的、不保序的传输UDP -多路复用、解复用 -没有为尽力而为的IP服务添加更多的其他额外服务
都不提供的服务延时保证带宽保证
3.2 多路复用和解复用
在发送方主机多路复用从多个套接字接受来自多个进程的报文根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装该头部信息用于以后的解复用 在接收方主机多路解复用根据报文段的头部信息中的IP地址和端口号将接收到的报文段发给正确的套接字和对应的应用进程 多路解复用工作原理 解复用作用TCP或者UDP实体采用哪些信息将报文段的数据部分交给正确的socket从而交给正确的进程。 主机收到IP数据报每个数据报有源IP地址和目标地址每个数据报承载一个传输层报文段每个报文段有一个源端口号和目标端口号 主机联合使用IP地址和端口号将报文段发送给合适的套接字 3.3 无连接传输UDP 3.4 可靠数据传输RDT的原理
RDT在应用层传输层和数据链路层都很重要是网络Top10问题质疑 信道的不可靠特点决定了可靠数据传输协议rdt的复杂性 渐增式地开发可靠数据传输协议RDT的发送方和接收方 只考虑单向数据传输但控制信息是双向流动的 双向的数据传输问题实际上是两个单向数据传输问题的总和 使用有限状态机FSM来描述发送方和接受方 状态在该状态下下一个状态只由下一个事件唯一确定 Rdt1.0在可靠信道上的可靠数据传输 下层的信道是完全可靠的没有比特出错没有分组丢失 发送方和接收方的FSM发送方将数据发送到下层信道接收方从下层信道接收数据
Rdt2.0具有比特差错的信道 下层信道可能会出错将分组中的比特翻转——用校验和来检测比特差错 问题怎样从差错中恢复 -确认ACK接收方显式地告诉发送方分组已被正确接受 -否定确认NAK接收方显式地告诉发送方分组发生了差错发送发重传分组 rdt2.0中的新机制采用差错控制编码进行差错检测
发送方差错控制编码、缓存接收方使用编码检错接收方的反馈控制报文ACK、NAK接收方-》发送方发送方收到反馈相应的动作 rdt2.2:无NAK的协议 功能同rdt2.1但只使用ACKack要编号 接收方对最后正确接收的分布发ACK以替代NAK。接收方必须显式地包含被正确接收分组的序号 当受到重复的ACK时发送方与收到NAK采取相同的动作重传当前分组 为后面的一次发送多个数据单位做一个准备一次能够发送多个每一个的应答都有ACKNACK使用对前一个数据单位的ACK代替本数据单位的NAK确认信息减少一半协议处理简单 rdt3.0具有比特差错和分组丢失的信道 新的假设下层信道可能会丢失分组数据或者ACK —会死锁机制还不够处理这种状况 方法发送方等待ACK一段合理的时间 发送端超时重传如果到时没有收到ACK则重传。 问题如果分组或ACK只是被延迟了重传会导致数据重复但利用序列号已经可以处理这个问题。接收方必须指明被正确接收的序列号 需要一个倒计数定时器 流水线协议 流水线允许发送方在未得到对方确认的情况下一次发送多个分组 必须增加序号的范围用多个bit表示分组的序号 在发送方/接收方要有缓冲区发送方缓冲未得到确认可能需要重传。接收方缓存上层用户取用数据的速率接收到的数据速率接收到的数据可能乱序排序支付 两种通用的流水线协议回退N步GBN和选择重传SR
滑动窗口协议 发送缓冲区 -形式内存中的一个区域落入缓冲区的分组可以发送 -功能用于存放已发送但是没有收到确认的分组 -必要性需要重发时可用 发送缓冲区的大小一次最多可以发送多个未经确认的分组 -停止等待协议1 -流水线协议1合理的值不能很大链路利用率不能超过100% 发送缓冲区中的分组 -未发送的落入发送缓冲区的分组可以连续发送出去 -已经发送出去的、等待对方确认的分组发送缓冲区的分组只有得到确认才能删除 接收窗口1GBN协议只能顺序接受累计确认 接收窗口》1SR协议可以乱序接受 异常情况下的GBN的2窗口互动 发送窗口 新分组落入发送缓冲区的范围发送-》前沿移动 超时重发机制让发送端将发送窗口中的所有分组发送出去 来了老分组的重复确认-》后沿不向前滑动-》新的分组无法落入发送缓冲区范围此时如果发送缓冲区有新的分组可以发送 接收窗口 收到乱序分组没有落入到接收窗口范围抛弃 重复发送老分组的确认累计确认 选择重传SR 接收方对每个正确接收的分组分别发送ACK非累计确认因为接受窗口》1因此可以缓存乱序的分组最终将分组按顺序交付给上层 发送方只对那些没有收到ACK的分组进行重传0选择性重发发送方为每个未确认的分组设定一个定时器。 发送窗口的最大值发送缓冲区限制发送未确认分组的个数 3.5 面向连接的传输TCP
点对点一个发送方一个接收方 可靠的、按顺序的字节流没有报文边界 管道化流水线TCP拥塞控制和流量控制设置窗口大小 发送和接受缓存 全双工数据在同一连接中数据流双向流动 面向连接在数据交换前通过握手初始化发送方、接收方的状态变量 有流量控制发送方不会淹没接收方 MSS最大报文段 TCP序号报文段首字节的在字节流的编号 确认号期望从另一方收到的下一个字节的序号累计确认 TCP往返延时RTT和超时 怎样设置TCP超时——比RTT长、太早超时、太长报文段丢失 怎样估计RTT——测量从报文段发出到收到确认的实践因为存在变化所以对多个测量值求平均 可靠数据传输TCP在IP不可靠的服务的基础上建立了rdt 管道化的报文段——GBN/SR 累计确认——GBN 单个重传定时器——GBN 是否可以接受乱序的没有规范 通过以下事件触发重传超时——SR重复的确认 TCP连接管理 在正式交换数据之前发送方和接收方握手建立通信关系同意建立连接同一连接参数 Q在网络中两次握手建立连接总是可行的吗
变化的延迟没有丢但可能超时由于丢失造成的重传报文乱序相互看不到对方
虚假的数据旧数据当作新数据接受了 TCP关闭连接 客户端服务器分别关闭他自己这一侧的连接 一旦收到FIN用ACK回应 可以处理同时的FIN交换
3.6 拥塞控制原理
拥塞得表现 1.分组丢失路由器缓冲区溢出 2.分组经历比较长的延迟在路由器的队列中排队 两个主机经过一个路由器分别发送给两个主机路由器带宽有限。
延迟大为了保证输出输入在持续增加网络拥塞重传没有必要的数据加速拥塞 拥塞控制方法 1.端到端拥塞控制 没有来自网络的明显反馈端系统根据延迟和丢失时间推断是否有拥塞TCP采用的方法。 2.网络辅助的拥塞控制路由器提供给端系统以反馈信息单个bit置位显示有拥塞。显式提供发送端可以采用的速率。
3.7 TCP拥塞控制
端到端拥塞控制 路由器不向主机提供有关拥塞的反馈信息是的路由器负担较轻符合网络核心简单的TCPIP架构原则 端系统根据自身得到的信息判断是否发生拥塞从而采取行动。 拥塞控制的几个问题 如何检测拥塞轻微拥塞拥塞 控制拥塞在拥塞发生时如何动作降低速率在拥塞缓解时如何动作增加速率。
拥塞感知 发送端如何探测到拥塞 1.某个段超时了拥塞 超时时间到某个段的确认没有来网络拥塞某个路由缓冲区没空间了。被丢弃概率大。出错被丢弃了没有通过某个校验被丢弃概率小。一旦超时就认为拥塞了有一定误判但总体控制方向是对的。 2.有关某个段的三次重复ACK轻微拥塞 段的第一个ack正常确认绿段期待红段。段的第二个重复ack意味着红段之后的段收到了乱序到达一直重复ack意味后面的段都乱序到达了说明红段丢失的可能性极大。网络这时还能够进行一定程度的传输拥塞但情况比第一种好
速率控制方法 维持一个拥塞窗口的值CongWin 发送端限制已发送但是未确认的数据量的上限从而粗略地控制发送方往网络中注入的速率
