计算机网络第三章--运输层
计算机网络第三章--运输层
- 传输层服务
- 多路复用和多路分解
- 多路分解--接受主机
- 将接受到的数据段传递到正确的套接字
- 多路复用--发送主机
- 从多个套接字收集数据，用首部封装数据，然后将报文段传递到网络层
- 无连接多路分解--UDP套接字
- 当主机收到UDP数据段
- 检查数据段中的目的端口号
- 用端口号指示UDP数据段属于哪个套接字
- 具有不同的源IP地址/或源端口号，但具有相同的目的IP地址和目的端口号的IP数据报，指向同样的套接字
- 当主机收到UDP数据段
- 面向连接的多路分解
- TCP套接字
- 源IP地址
- 源端口号
- 目的IP地址
- 目的端口号
- TCP套接字
- 多路分解--接受主机
- 无连接传输：UDP
- UDP 用户数据报协议
- UDP 不建立连接，减少延迟
- UDP 没有拥塞控制，能够用尽可能块的速度传递
- UDP 首部开销小，只有8个字节：源端口、目的端口、长度、校验和
- UDP 是面向报文的，对于应用程序的报文，添加首部后就交给IP层
- UDP 校验和
- 按位求和相加，求和时产生的进位必须回卷加到结果，抛出溢出位
- 累加和按位变反，得到校验和
- UDP 用户数据报协议
- 可靠数据传输原理
- Rdt1.0：完成可靠信道上的可靠数据传输
- 在完美可靠的信道上
- 没有bit错误
- 没有分组丢失
- 发送方，接受方分离的FSMs
- 发送方发送数据到下层信道
- 接收方从下层信道接受数据
- 在完美可靠的信道上
- Rdt2.0：具有bit错误的信道
- 下层信道可能让传输分组中的bit受损
- 校验和将检测到bit错误
- 如何从错误中恢复
- 确认（ACKs）：接受方明确告诉发送方 分组接受正确
- 否认（NAKs）：接收方明确告诉发送方 分组接受出错
- 发送方收到NAK后重发这个分组
- 新机制
- 差错检测
- 接受方反馈：控制信息（ACK，NAK）
- 停-等协议
- 发送方发送一个报文，然后等待接收方的响应
- 致命缺陷
- ACK/NAK混淆
- 发送方不知道接收方发生了什么，不能正确重发
- 下层信道可能让传输分组中的bit受损
- Rdt2.1：处理混乱的ACK/NAKs
- 发送方给每个分组加一个序号
- 在 ACK/NAK 混淆时发送方重发当前分组接收方丢弃重发的分组
- 发送方
- 序号加到分组上
- 两个序号（0，1）就可以满足
- 必须检查是否收到混淆的ACK/NAK
- 状态必须记住当前报文是1号还是0号
- 接收方
- 必须检查是否接收到重复的报文
- 状态指示0或者1：是否希望的报文序列
- 接收方并不知道它的上一个ACK/NAK是否被发送方正确收到
- Rdt2.2：一个不要NAK的协议
- 不用NAK，如果上个报文接收正确接收方发送ACK
- 接受方必须明确包含被确认的报文的序号
- 发送方收到重复ACK将导致和NAK一样的处理：重发当前报文
- Rdt3.0：具有出错和丢失的信道
- 新假设：下层信道还会丢失报文（数据或者ACKs）
- 方法：发送者等待“合理的”确认时间
- 如果在这个时间内没有收到确认就重发
- 如果报文（或者确认）只是延迟（没有丢失）
- 重发将导致重复，但是使用序号已经处理了这个问题
- 接受方必须指定被确认的报文序号
- 要求倒计时定时器
- 只有在定时器超时时才触发重发
- 性能很差：网络协议限制了物理资源的使用
- 流水线技术--增加利用率
- 发送方允许发送多个“在路上的”，还没有确认的报文
- 序号数目的范围必须增加
- 在发送方/接收方必须有缓冲区
- Go-Back-N
- 滑动窗口：允许的连续未确认的报文
- ACK-only：总是为正确接收的最高序号的分组发送ACK
- 选择性重传SR
- 接收方分别确认已经收到的分组
- 发送者只重发没有收到确认的分组
- 发送方
- 从上层收到数据：如果下一个可用的序号在发送方窗口内，则将数据打包并发送，启动定时器
- 超时：重发分组n，重启定时器
- 收到ACK(n)在[sendbase,sendbase+N-1]内：如果n是最小的未确认分组，则增加窗口基序号到下一个未被确认的序号
- 接收方
- 分组n的序号在[rcvbase,rcvbase+N-1]内：发送ACK(n)
- 失序分组：缓冲
- 有序分组：交付上层，提高窗口到下一个没有接收的分组
- 分组n在[rcvbase-N,rcvbase-1]内：发送ACK(n)
- 分组n的序号在[rcvbase,rcvbase+N-1]内：发送ACK(n)
- 发送方
- 发送方允许发送多个“在路上的”，还没有确认的报文
- Rdt1.0：完成可靠信道上的可靠数据传输
- 面向连接传输：TCP
- 特点
- 点到点：一个发送方，一个接收者
- 可靠按序的字节流：没有信息边界
- 流水线：TCP拥塞和流量控制设置窗口大小
- 收发缓冲区
- 全双工数据：同一个连接上的双向数据流
- MSS：最大报文段长
- 面向连接：在数据交换前握手（交换控制信息）初始化发送方和接收方的状态
- 流量控制：发送方不会淹没接收方
- 报文段结构
- TCP报文段的首部格式
- 20字节的固定首部
- 源端口、目的端口：各占2字节，端口是运输层与应用层的服务接口
- 序号：4个字节，序号字段的值是指本报文段所发送的数据的第一个字节的序号
- 确认号：4个字节，是期望收到对方的下一个报文段的数据的第一个字节的序号
- 数据偏移（首部长度）：占4位，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远，单位为4个字节
- 窗口：2个字节，用来让对方设置发送窗口的依据
- TCP往返时延的估计和超时
- 设置TCP超时值
- TCP报文段的首部格式
- 可靠数据传输机制
- 可靠数据传输
- TCP发送方事件
- TCP重发场景
- 快速重传
- 发送方可以在超时之前通过重复的ACK检测丢失报文段
- 如果发送方收到3个对同样报文段的确认，则发送方认为该报文段之后的数据已经丢失，启动快速重传
- 流量控制
- 速度匹配服务：发送速率和接收应用程序的提取速率匹配
- 流量控制：发送方不能发送的太多太快，让接收缓冲区溢出
- TCP流控原理
- 流量控制使用接收窗口：接收缓冲区的剩余空间
- 接收方在报文段中宣告接受窗口的剩余空间
- 发送方限制没有确认的数据不超过接受窗口--保证接受缓冲区不溢出
- 连接管理
- 建立连接：三次握手
- Step 1：客户发送TCP SYN报文段到服务器--指定初始的序号、没有数据
- Step 2：服务器接收SYN，回复SYN/ACK 报文段--服务器分配缓冲区、指定服务器的初始序号
- Step 3：客户接收SYN/ACK，回复ACK报文段，可能包含数据
- 关闭连接：四次挥手
- Step 1：客户发送TCP FIN 控制报文段到服务器
- Step 2：服务器接收FIN，回复ACK，半关闭连接，并发送FIN到客户
- Step 3：客户接收FIN，回复ACK--进入timed wait状态、等待结束时释放连接资源
- Step 4：服务器接收ACK，连接关闭
- 建立连接：三次握手
- 特点
- 拥塞控制原理
- 拥塞
- 太多源主机发送太多的数据，速度太快以至于网络来不及处理
- 流量控制是双方的，拥塞是整个网络的
- 拥塞控制的方法
- 端到端拥塞控制
- 没有从网络中的得到明确的反馈
- 从端系统观察到的丢失和延迟推断出拥塞
- TCP采用的方法
- 网络辅助的拥塞控制
- 路由器给端系统提供反馈
- 单bit指示拥塞
- 指明发送者应该发送的速率
- 端到端拥塞控制
- 拥塞
- TCP拥塞控制--划重点
- 感知拥塞
- 丢失事件：超时或者3个重复ACKs
- TCP发送方在丢失事件发生后降低发送速率CongWin
- TCP慢启动 slow start
- 初始化：CongWin = 1MSS
- 当连接开始的时候以指数方式增加速率
- 每个RTT内倍增CongWin--每收到一个ACK，CongWin加1
- 对拥塞事件的反应
- 当超时事件发生时
- 阈值设置为丢失前的CongWin的一半
- CongWin 立即设置为1个MSS
- 窗口开始指数增长（进入慢启动）
- 到达一个阈值后再线性增长
- 收到三个重复的确认时--表明网络具有传输一些数据段的能力
- CongWin 减半 + 3
- 窗口线性增长
- 当超时事件发生时
- AIMD
- 发送方增加传输速率（窗口大小），探测可用带宽，直到发生丢包事件
- 乘性递减MD：发生丢包事件后将拥塞窗口减半
- 加性递增AI：每个RTT内如果没有丢失事件发生，拥塞窗口增加一个MSS
- 感知拥塞