计算机网络_传输层

计算机网络基础（自顶向下） HIT 哈工大课程笔记，介绍详细，可以让你更快速更方便去了解学习。有需要的赶紧收藏吧！

传输层

• 关键词
  • 理解
    • 尚未弄懂
  • 思考题
    • 1. 为什么TCP选择的序列号是segment中第一个字节的编号
    • 2. 单一重传定时器如何理解？
      • 每个报文段设定一个定时器
        • 即使有多个已发送但还未被确认的报文段也一样。
    • 3. 反馈控制信息延误
      • 
      • 理解后续如何处理？
    • 4. 定时器
      • 一个/多个的协议有哪些
      • 如何定时，具体如何工作
    • 5. ACK 生成
    • 6. 吞吐率（throughout）
      • 
      • 吞吐率与丢包率的关系
• 概述
  • 理解传输层服务的基本理论和基本机制
    • 基本理论
      • 复用/分用
    • 基本机制
      • 可靠数据传输机制
      • 流量控制机制
      • 拥塞控制机制
  • 掌握Internet的传输层协议
    • UDP：无连接传输服务
    • TCP：有连接传输服务
    • TCP拥塞控制
• 传输层（下）
  • 面向连接的传输协议_TCP
    • 1. TCP概述
      • TCP概述
        • 通信机制
          • 点对点
            • 一个发送方，一个接收方
          • 数据形式：可靠的、按序的字节流
            • TCP把数据看成一个无结构的但是有序的字节流。
          • 流水线机制
            • TCP拥塞控制
            • TCP流量控制
            • 动态调整窗口尺寸
          • 发送方/接收方缓存
            • 均有窗口
          • 全双工
            • 同一连接中能够传输双向数据流
        • 面向连接
          • 含义
            • 通信双方在发送数据之前必须建立连接
          • 状态维护
            • 只在连接的两端中维护，在沿途节点中并不维护状态。
          • 实质
            • 主机上的缓存、控制变量和与一个进程连接的套接字变量名，以及另一台主机上的一套缓存、控制变量和与一个进程连接的套接字。
        • 发送/接收数据的流程
          • 发送方
            • 客户机操作系统中运行的TCP软件模块首先将这些数据放到该连接的发送缓存里，然后会不时地从发送缓存里取出一块数据发送。 TCP可从缓存中取出并放入报文段中发送的数据量受限于最大报文段长MSS，通常由最大链路层帧长度来决定(也就是底层的通信链路决定)。 报文段被往下传给网络层，网络层将其封装在网络层IP 数据报中。然后这些数据报被发送到网络中。
          • 接收方
            • 当TCP在另一端接收到一个报文段后。该报文段的数据就被放到该连接的接收缓存中。 应用程序从接收缓存中读取数据流(注意是应用程序来读，不是操作系统推送)。
          • TCP 连接的每一端都有各自的发送缓存和接收缓存。
          • 注意
            • MSS
              • 最大链路层帧长度来决定(也就是底层的通信链路决定)
                • 例如一个链路层帧的最大长度1500字节，除去数据报头部（网络层）长度20字节，TCP报文段的头部长度20字节（传输层），MSS为1460 字节（应用层）。
            • 所经过的路由器和交换机没有为该连接分配任何缓和控制变量。
      • TCP段结构
        • 
        • 首部字段
          • 一般TCP首部的长度就是20字节。
          • I. 源端口号和目的端口号
            • 用于多路复用/多路分解来自或送至上层应用的数据。
          • II. 32比特的序号字段和32比特的确认号字段
            • 被TCP发送方和接收方用来实现可靠数据传输服务。
          • III. 标志字段ACK
            • 用于指示确认字段中的ACK值的有效性，即该报文段包括一个对已被成功接收报文段的确认
          • IV. 4比特的首部长度字段
            • 指示以32比特的字为单位（4bytes）的TCP首部长度。
          • V. 16比特的接收窗口字段
            • 用于流量控制（指示接收方能够接受的字节数量）
          • VI. 校验和字段
          • VII. 可选与变长的选项字段
            • 用于当发送方与接收方协商最大报文段长度 或在高速网络环境下用作窗口调节因子时使用。
          • VIII. SYN和FIN比特用于连接建立和拆除。
          • IX. PSH、URG 和紧急指针字段通常没有使用。
        • 数据字段
          • 应用层数据
      • 序列号和ACK
        • 序列号
          • 含义
            • segment中第一个字节的编号
              • 一个报文段的序号是该报文段首字节在字节流中的编号。
            • segment的编号
              • TCP 序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。
            • 例子
              • 假如1000KB的数据，拆成两个segment，那么第二个segment的编号不是2，可能是501/500
          • 初始序列号选择
            • 建立TCP连接时，双方随机选择序列号
              • 可以减少将那些仍在网络中的来自两台主机之间先前连接的报文段，误认为是新建连接所产生的有效报文段的可能性。（类似SR协议收发双方窗口大小的规范）
        • ACKs
          • 含义
            • 希望接收到的下一个字节的序列号
          • 机制
            • 累积确认：该序列号之前（小于等于n）的所有字节均已被正确接收到
        • 接收方如何处理乱序到达的Segment？
          • TCP规范中没有规定，由TCP的实现者做出决策
        • 例子
          • 
    • 2. TCP可靠数据传输
      • 概述
        • 目的
          • TCP 在IP不可靠的尽力而为服务基础上建立了一种可靠数据传输服务。
        • 重传
          • 单一重传定时器：每个报文段设定一个定时器
            • 每个报文段设定一个定时器，即使有多个已发送但还未被确认的报文段也一样。
          • 触发重传的事件
            • 超时
            • 收到重复ACK
      • RTT和超时
        • 如何设置定时器的超时时间
          • 大于RTT（RTT是变化）
            • 过短
              • 不必要的重传
            • 过长
              • 对段丢失时间反应慢
        • 如何估计RTT（平均值）
          • SampleRTT
            • 测量从段发出去到收到ACK的时间（忽略重传）
          • EstimatedRTT
            • 测量多个SampleRTT，求平均值形成RTT的估计值
            • 计算方法
              • 指数加权移动平均
                •  既考虑新的SampleRTT也考虑历史的Estimated RTT
        • 定时器超时时间的设置（偏差设定）
          • EstimatedRTT + “安全边界”
            • EstimatedRTT变化大-->较大的边界(RTT不稳定)
          • 安全边界的设定
            • （类似偏差）
              •  RTT 偏差也使用了指数加权移动平均
        • 定时器超时时间的设置
          • TimeoutInterval = EstimatedRTT + 4*DevRTT
      • TCP发送方事件
        • 1. 从应用层收到数据
          • 创建Segment 序列号是Segment第一个字节的编号 开启计时器 设置超时时间：TimeOutInterval
        • 2. 超时
          • 1. 重传引起超时的segment
            • 只会重传引起超时的那一个segment
          • 2. 重启定时器
        • 3. 收到ACK
          • 确认此前未确认的Segment
            • 1. Y>SendBase，更新sendbase ACK 是在确认一个或多个先前未被确认的报文段。 发送方更新其SendBase变量--->发送窗口向前移动。 2. 若窗口中还有未被确认的分组，重新启动定时器
        • 与重传有关的重要事件
        • 4. 补充
          • sendbase
            • TCP 状态变量SendBase 是最早未被确认的字节的序号 就是指接收方已正确按序接收到数据的最后一个字节的序号
      • TCP接收方事件
        • ACK生成（理解）
          • I. 具有所期望序号的报文段按序到达 所有在期望序号及以前的数据已经确认
            • 延迟500ms发送ACK（观察是否有下一个按序的报文段到达）
          • II. 子主题
          • III. 子主题
          • IV. 子主题
      • 快速重传机制
        • 引入
          • 原因
            • 超时周期可能相对较长
              • 超时触发重传存在的另一个问题是超时周期可能相对较长 当一个报文段丢失时，这种长的超时周期迫使发送方等待很长时间才重传丢失的分组，因而增加了端到端时延。
          • 解决
            • 在超时事件发生之前通过观察冗余ACK来检测丢包情况。
        • 3个重复ACKs
          • 为什么要3个重复ACKs才执行快速重传
            • 三个重复ACKs：TCP接收方希望报文段是乱序到达而非丢失，所以给予三次重复ACKs的机会，若三次都收到重复ACKs，则认为该报文段已经丢失了 当TCP 接收方收到一个序号比所期望的序号大的报文段时，它认为检测到了数据流中的一个间隔，即有报文段丢失。 这个间隔可能是由于在网络中报文段丢失或重新排序（乱序）造成 TCP使用累计确认，所以接收方不向发送方发回否定确认，而是对最后一个正确接收报文段进行重复确认(即产生一个冗余ACK)
          • actions
            • 执行快速重传（即在该报文段的定时器过期之前重传丢失的报文段）
        • 补充
          • 冗余ACK
            • 发生方多次受到对同一报文段的确认
              • 冗余ACK 就是接收方再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。
    • 3. TCP流量控制
      • 原因
        • 发送方
          • 传输太多、太快以至于淹没接收方(buffer溢出)
        • 接收方
          • 上层应用可能处理buffer中数据的速度较慢
      • 解决方法
        • 接收方
          • 通过在Segment的头部字段将RcvWindow 告诉Sender
        • 发送方
          • 限制已经发送但未收到ACK的数据不超过接收方的空闲RcvWindow尺寸
        • 速度匹配
        • 特例
          • Receiver告知SenderRcvWindow=0,会出现什么情况？
            • 发送方停止发送-->连接丢失 因此，需要增加额外的机制，保证rcvwindow=0时，发送方还能发送一个很小的信息，以便能够信息交互（使得当接收方rcvwindow改变时能够通知发送方）
      • 补充
        • 
        • RcvWindow
          • 可接受数据的窗口大小（Buffer中的可用空间(spareroom)）
        • RcvBuffer
          • 接收方缓存窗口大小
        • LastByteRcvd
          • 最后一个已经接受的字节
        • LastByteRead
          • 最后一个已经确认的字节
    • 4. TCP连接管理
      • 建立
        • 1. 客户机发送SYN报文段给服务器
          • Step 1: client host sends TCP SYN segment to server specifies initial seq # no data
          • SYN = 1
          • no date
          • 客户机随机选择起始序列号作为第一条报文的序列号
        • 2. 服务器收到SYN
          • Step 2: server host receives SYN（提取出TCPSYN 报文段）, replies with SYNACK segment server allocates buffers specifies server initial seq. # 实际意义：我收到了你要求建立连接的、带有初始序号的分组。我同意建立该连接，我自己的初始序号是XX
          • I. 为TCP连接分配TCP缓存和控制变量并向客户机TCP发送允许连接报文段
          • II. 回复SYNACK报文段
            • SYN = 1
            • NO date
            • 服务器随机选择起始序列号作为第一条报文的序列号
            • 确认号字段ACK = client_isn + 1
              • TCP 报文段首部的确认号字段被置为客户端序号+1
        • 3. 客户机收到SYNACK
          • I. 为TCP连接分配缓存和控制变量。
          • II. 回复ACK segment
            • may contain date
        • 三次握手
          •  这个过程发生在客户机connect()服务器，服务器accept()客户连接的阶段
      • 关闭
        • TCP 连接的关闭需要客户端和服务器端互相交换连接关闭的FIN、ACK 置位报文段 
        • 1. 客户机
          • i. 发送FIN=1的TCP报文段
            • 进入FIN WAIT1状态
          • ii. 收到来自服务器的ACK信息
            • 进入FIN WAIT2状态
          • iii. 收到来自服务器的FIN=1的另一个TCP报文段，发送ACK
            • 进入TIME_WAIT状态
              • 使得TCP客户机重传最终确认报文，以防该ACK丢失。（若丢失有足够的时间重传）
          • iv. TIME_WAIT Over，连接正式关闭
        • 2. 服务器
          • i. 收到FIN，发送ACK，关闭连接，发送FIN
          • ii. 收到ACK.，连接关闭
  • 拥塞控制原理
    • 拥塞
      • 非正式定义
        • 主机发送了太多数据或发送数据太快以至于网络无法处理
      • 表现
        • 分组丢失（路由器缓存溢出）
        • 分组延迟过大（在路由器缓存中排队）
      • 处理方法
        • 拥塞控制
          • 不要让中间的网络处理不了
        • 流量控制
          • 控制发送方的速率
            • 发送方不要发太快，以致于接收方处理不了
    • 拥塞的成因和代价
      • 1. 场景1
        • 模型
          • 两个发送方和一个具有无穷大缓存的路由器（无重传）
        • 一种开销
          • 即当分组到达速率接近链路容量时，分组将经历较长的排队时延。
            • 
      • 2. 场景2
        • 模型
          • 两个发送方和一个具有有限缓存的路由器
        • 情况a
          • Sender能够通过某种机制获知路由器buffer信息，有空闲才发
            • 
        • 情况b
          • 丢失后才重发
            • 发送方必须执行重传以补偿因为缓存溢出而丢弃(丢失)的分组。 
        • 情况c
          • 分组丢失和定时器超时后都重发
            • 遇到大时延时所进行的不必要重传，导致路由器需要利用其链路带宽来转发不必要的分组 
      • 3. 场景3
        • 模型
          • 四个发送方、具有有限缓存的多台路由器和多跳路径
        • 另一种开销
          • 当分组被drop时，任何用于该分组的“上游”传输能力全都被浪费掉
            • 
    • 拥塞控制的方法
      • 1. 端到端拥塞控制
        • 网络层不需要显示的提供支持
        • 端系统通过观察loss、delay等网络行为判断是否发生拥塞
      • 2. 网络辅助的拥塞控制
        • 路由器（网络层）向发送方显式地反馈网络拥塞信息
        • 简单的拥塞指示(1bit)：SNA,DECbit, TCP/IP ECN, ATM)
          • 指示发送方应该采取何种速率
        • 拥塞信息从网络反馈到发送方的方式
          • 直接反馈信息：路由器发给发送方
          • 间接反馈信息
            • 对经过一个拥塞路由器的数据报做记号
              • 路由器标记或更新从发送方流向接收方的分组中的某个字段来指示拥塞的产生 接收方收到这个有拥塞标记的分组，就会通知发送方网络发生了拥塞。
      • 区分
        • 可根据网络层是否为传输层拥塞控制提供了帮助来区分。
      • 3. 例子
        • ATM ABR拥塞控制（理解）
          • 弹性服务
            • 发送方路径underloaded（负载比较低）
              • 使用可用带宽
            • 发送方路径拥塞
              • 将发送速率降到最低保障速率
          • 核心方法
            • RM cells（与data cell分开）
              • 
              • 发送方发送
              • 交换机设置RM cell位（网络辅助）
                • NI bit:rate不许增长
                • CI bit：拥塞指示
                • ER（显示的速率）两个字节 定量指示
                  • 拥塞的交换机可以将ER置为更低的值
                  • 发送方获知路径所能支持的最小速率
              • RM cell由接收方返回给发送方
          • 补充
            • 数据cell中的EFCI位: 拥塞的交换机将其设为1
              • 如果RM cell前面的data cell的EFCI位被设为1，那么发送方在返回的RM cell中置CI位
  • TCP拥塞控制
    • 拥塞控制
      • 基本原理（控制发送发的发送速率）
        • Sender限制发送速率（接收方）
          • LastByteSent-LastByteAcked<= CongWin：限定已发送未确认数据的量
          • rate = CongWin/RTT Bytes/sec
          • 发送窗口=min{CongWin,RcvWin}
        • 如何感知网络拥塞？
          • Loss事件(丢包事件)=timeout或3个重复ACK
        • 感知网络拥塞后发送方如何处理？
          • 发生loss事件后，发送方降低速率
        • 如何合理地调整发送速率？
          • 加性增—乘性减: AIMD
          • 慢启动: SS
        • 补充
          • CongWin(拥塞窗口)
            • 动态调整以改变发送速率
            • 反映所感知到的网络拥塞
      • 拥塞避免的算法
        • 基础
          • 对CongWin控制变量的调整是以MSS最大报文段长度)字节为单位进行的
        • 加性增—乘性减: AIMD
          • 原理
            • 逐渐增加发送速率，谨慎探测可用带宽，直到发生loss
          • 方法
            • Additive Increase: 每个RTT将CongWin增大一个MSS——拥塞避免
            • Multiplicative Decrease: 发生loss后将CongWin减半
          • 图像
            • 锯齿行为：探测可用带宽
              • 
        • 慢启动: SS
          • 原因
            • 可用带宽可能远远高于初始速率（希望快速增长）
          • 原理
            • 当连接开始时，指数性增长
              • 每次的增加是已有当前量的两倍 2^n（翻倍） initialize: Congwin = 1 for (each segment ACKed) Congwin++ //指数性增加 until (loss event OR CongWin > threshold) Congwin++ //指数性增加 TCP一次发送多个报文段进入网络，从 而使发送方的发送速率在经过一个RTT 时间后成倍增长 第一次发送一个MSS长度的报文段，然后收到一个ACK，CongWin +=1 第二次可以发送两个MSS长度的报文段，然后每收到一个ACK，CongWin += 1，由于第二次有两个ACK，所以CongWin+2； 以此类推，第n次可发送 2^n个MSS长度的报文段
              • 1. 每个RTT将CongWin翻倍
              • 2. 收到每个ACK进行操作
          • 图像
            • 初始速率很慢，但是快速攀升
              • 
        • Threshold变量
          • 引出
            • 何时应该指数性增长切换为线性增长(拥塞避免阶段)?
            • 当CongWin达到Loss事件前值的1/2时（Threshold）
          • 实现方法
            • I. 初始化时被设置为一个很大的值
            • II. Loss事件发生时, Threshold被设为Loss事件前CongWin值的1/2。
        • Loss事件的处理
          • I. 3个重复ACKs
            • 1. CongWin切到一半
            • 2. 然后线性增长
          • II. Timeout事件
            • 1. CongWin直接设为1个MSS
            • 2. 然后指数增长
            • 3. 达到threshold后, 再线性增长
          • III. 注意
            • 3个重复ACKs表示网络还能够传输一些segments（至少ACK还能收到）
            • timeout事件表明拥塞更为严重
        • 总结
          • 
          • i. 增长速率
            • CongWin<Threshold Grows exponentially
            • CongWin>Threshold Grows linearly.
          • ii. LOSS事件处理
            • Threshold = CongWin/2 and CongWin = Threshold.(3个重复ACK)
            • timeout ocurs--->Threshold = CongWin/2 and CongWin = 1 MSS.
      • 算法
        • 
    • 性能分析
      • 公平性
        • TCP具有公平性
          • 数学表示
            • 
            • K个TCP Session共享相同的瓶颈带宽R，那么每个Session的平均速率为R/K
          • 图像
            • 
            • 不断收敛于共享相等带宽的直线
              • 
        • UDP不具有公平性
          • UDP无拥塞控制机制限制速率，能以恒定速率发送
      • 吞吐率（throughout）
        • 
        • 吞吐率与丢包率的关系
• 传输层（上）
  • 传输层服务概述
    • 传输层协议
      • 作用
        • 传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制
          • 端到端的通信 两个进程之间仿佛直接连接，不需关注两进程之间实际的物理媒介和距离
      • 如何运行
        • 实现
          • 在端系统中而不是在网络路由器中实现
        • 发送方
          • 运输层将接收到的来自发送应用进程的报文转换成传输层分组，称其为传输层报文段(segment)：该过程是将应用消息划分为较小的块，并为每块加上一个传输层首部来创建传输层报文段。 然后，在发送方端系统中，传输层将这些报文段传递给网络层，网路层将其封装成网络层分组(数据报)并向目的地发送。
          • 1. 应用进程的报文->传输层报文段（首部+应用信息划分的小块）
          • 2. 传输层报文段->网络层分组（数据报）->向目的地发送
        • 接收方
          • 网络层从数据报中提取传输层报文段，并将该报文段向上交给传输层。传输层则处理接收到的报文段，使得接收方应用进程可应用该报文段中的数据。
          • 发送方的逆过程
      • 提供哪些协议
        • TCP（可靠、按序）
          • 拥塞控制、流量控制、连接建立
        • UDP（不可靠）
          • 提供最基本的多路复用和多路分用
          • 1. 基于“尽力而为(Best-effort)”的网络层
          • 2. 没有做（可靠性方面的）扩展
    • 传输层报文段
      • 网络路由器仅检查该数据报的网络层字段
        • 即它们不检查封装在该数据报的传输层报文段的字段。
    • 传输层VS网络层
      • 家庭类比: 12个孩子给12个孩子发信  应用进程= 孩子  应用消息= 信封里的信  主机= 房子  传输层协议= 李雷和韩梅梅（应用进程之间的逻辑通信）  网络层协议= 邮政服务（主机之间的逻辑通信）
      • 网络层
        • 提供主机之间的逻辑通信
      • 传输层
        • 位于网络层之上 依赖于网络层服务 对网络层服务进行（可能的）增强
        • 提供应用进程之间的逻辑通信机制
    • 补充
      • 传输层协议的限制
        • 传输层协议所能提供的服务也受到了底层网络层协议的服务模型的限制。 例子：如果网络层协议不能为两主机之间发送的传输层报文段提供时延和带宽保证，那么传输层协议也不能为两进程之间发送的消息提供时延和带宽保证。
      • 传输层协议的扩展
        • 底层网络协议在网络层不提供相应服务，传输层协议也能提供某些服务。 例如：传输层能为应用程序提供可靠的传输服务。另一个例子是即使网络层不能保证传输层报文段的机密性，传输层也能使用加密来确保应用层消息不被入侵者读取。
  • 多路复用和多路分用
    • 绪论
      • 原因
        • 如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用 直观理解：一个主机上有多个进程，进行传输必须进行多路复用（利用同一种物理媒介传输多个进程的信息必须多路复用与分用才能进行信息的区分）
        • 例子
          • 一个例子：假定你正坐在计算机前下载Web 页面，同时还在运行一个FTP 会话。此时你就有2个网络应用进程在运行，即一个FTP 进程和一个HTTP 进程。当计算机的传输层从底层的网络层接收数据时，它需要将所接收到的数据定向到这2个进程中的一个。
      • 如何工作？（TCP/UDP）
        • 1. 主机接收到IP数据报
        • 2. 传输层协议提取IP地址和端口号
        • 3. 将segment导向相应的socket
      • 要求
        • 1. 套接字有唯一标识符
        • 2. 每个报文段有特殊字段来指示该报文段所要交付的套接字
          • 特殊字段：源端口号字段(source port number field)和目的端口号字段(destination port number field)。
    • 概念
      • 多路复用
        • 原因
          • 由于网络层协议只有一个，所以传输层的数据都需要通过同一个网络层去传输，这样就需要区分不同应用进程发送的数据
        • 执行者
          • 发送端
        • 理解
          • 从不同socket接收数据块->报文段（封装首部信息）->网络层
            • 从源主机的不同套接字中收集数据块，井为每个数据块封装上首部信息(在多路分解时使用)从而生成报文段，然后将报文段传递到网络层的工作
      • 多路分用（接收端）
        • 传输层依据头部信息将收到的Segment交给正确的Socket，即不同的进程（将不同的socket发送的segment正确分开，交付给对应的socket）
        • 执行者
          • 接收端
        • 理解
          • 将传输层报文段中的数据放置到正确的套接字的工作
            • 将数据放到正确的存储位置的过程
    • 无连接的多路复用与多路分解
      • 1. 利用端口号创建socket
      • 2. UDP的Socket用二元组标识（目的IP地址，目的端口号）
      • 3. 主机收到UDP端
        • 检查段中的目的端口号
        • 将UDP端导向绑定在该端口号的socket
    • 面向连接多路复用与多路分解
      • 1. 建立连接
        • 在TCP服务器程序接受客户机连接，accept()函数创建并返回一个新的连接套接字用于与客户机的通信，并将这个套接字与请求报文段中的4个值建立关联
      • 2. TCP的Socket用四元组标识
        • TCP连接需用四元组才能唯一标识 源IP地址：区分不同的请求主机 源端口号：服务器C返还消息时使用 目的IP地址：服务器C得区分一个请求从哪个网卡进来，以便返回响应消息。 目的端口号：C服务器转发报文段给应用的时候要看这个字段 P3-P5 P2-P6(若不用四元组标识，则不能区分两个TCP连接) 
    • 知识补充
      • 1. TCP/UDP段格式（每个）
        •  TCP/UDP段格式在红色部分的内容一致，其他不一样 携带源端口号和目的端口号 源IP地址和目的IP地址 携带一个传输层的段
      • 2. 当一个网络应用程序运行时，必须为其分配一个端口号。
      • 3. 端口号
        • 1. 端口号是一个16 比特的数字，其大小在0-65535 之间。
        • 2. 0-1000 范围的端口号称为周知端口号
          • 它们是保留给诸如HTTP和FTP之类的公有的应用层协议的。
      • 4. 套接字与进程之间并非总是有着一一对应的关系
        • Web 服务器通常一个服务进程可以为每个新的客户机连接创建一个具有新连接套接字的线程
    • 课堂问题
      • 1. 目的进程返回给源进程信息时如何确定源进程主机的IP地址？
        • 接收方在接收UDP报文段时，如调用recvfrom()，会提取对方的端点地址即（IP地址+端口号）
  • UDP
    • 简述
      • 功能
        • UDP 从应用进程得到数据，附加上多路复用/多路分解服务所需的源端口号和目的端口号字段，及两个其他的小字段，然后将形成的报文段交给网络层。 
        • 基于网络层IP协议
          • 只是做了传输协议能够做的最少工作，几乎没有对IP 增加别的东西
          • 复用/分用
          • 简单的错误校验（校验和）
      • 无连接
        • UDP发送方和接收方之间不需要握手
        • 每个UDP段的处理独立于其他段
      • 优缺点
        • 优点
          • I. 无需建立连接
            • 不会引入建立连接的时延
          • II. 实现简单，无需维护连接状态
          • III. 头部开销小
            • 8个字节，TCP头部或首部是20个字节
          • IV. 无拥塞控制: 应用层可更好地控制发送时间和速率
            • 百分百听从上层应用
        • 存在问题（“Best effort”服务）
          • 丢失
          • 非按序到达
      • 应用
        • 流媒体应用
          • 实时应用通常要求最快的发送速率，不想过分地延迟报文段的传送，且能容忍一些数据丢失
          • 容忍丢失、速率敏感
        • DNS、SNMP
          • DNS
            • 当主机中的DNS客户端要进行一次查询时，它构造了一个DNS查询消息并将其交给UDP（无须与目的端系统握手）主机端的UDP为此报文添加首部字段，然后将形成的报文段交给网络层。网络层将此UDP 报文段封装进一个IP 数据报中，然后将其发送给一个DNS 服务器。 查询主机中的DNS客户端便等待对该查询的响应。 如果它没有收到响应，则要么试着向另一个名字服务器发送该查询，要么通知调用的应用程序它不能获得响应。
          • SNMP
    • 报文段结构
      • 
      • UDP首部（4个字段）
        • 校验和
        • 源端口号
          • 返回消息时使用
        • 目的端口号
          • 使目的主机将应用数据交给运行在目的端系统中的相应进程(即执行多路分解功能)
        • 校验和
          • 接收主机使用校验和来检查报文段中是否存在差错。
        • 长度
          • 长度字段指明了包括首部在内的UDP报文段长度(以字节为单位)。
        • 每个字段由两个字节组成
      • 应用层数据（message）
    • 检验和
      • 目的
        • 检测UDP段在传输中是否发生错误（如位翻转）
      • 校验过程
        • 发送方
          • 发送方的UDP 对报文段中的所有16 比特字的和进行反码运算，求和时遇到的任何溢出都被回卷 将段的内容视为16-bit整数 校验和计算：计算所有整数的和，进位加在和的后面（回卷），将得到的值按位求反，得到校验和 发送方将校验和放入校验和字段
        • 接收方
          • 计算所收到段的校验和 将其与校验和字段进行对比 • 不相等：检测出错误 • 相等：没
      • 校验和计算示例
        • 
      • 知识补充
        • 全部数据的16-bit整数 + checksum = 1111111111111111
    • 课堂问题
      • 1. 在UDP上实现可靠数据传输？
        • I. 在应用层增加可靠性机制
        • II. 应用特定的错误恢复机制
  • 可靠数据传输原理
    • 绪论
      • 
      • 可靠
        • 不错，不丢，不乱
          • 不错：0和1不会错 不丢：分组不丢 不乱：分组顺序不乱,可分辨出重复的分组
      • 服务的提供
        • 传输层端到端的数据传输（向应用层提供的信道）是可靠的
      • 服务的实现
        • 传输层之下（网络层、数据链路层、物理层）的数据传输是不可靠的
    • 可靠数据传输协议（rdt）
      • 研究背景
        • 只考虑单向数据传输，但控制信息双向流动
        • 利用状态机(Finite State Machine, FSM)刻画传输协议
          •  actions:进行状态转换时发生的动作 event:状态转变的触发事件 注意：一个触发事件只能触发一个状态确定地向另一个状态迁移，不可能向多个状态迁移
      • 基本结构
        • 接口
          • 
          • rdt_send()
            • 被上层应用调用，将数据交给rdt以发送给对方（单向）
          • udt_send()
            • 被rdt调用，在不可靠信道上向接收方传输数据
              • 可靠数据传输协议调用的不可靠发送
          • rdt_rcv()
            • 当数据包到达接收方信道时被调用
          • 双向
            • 双向；不可靠的信道实现可靠的数据传输并不是一个简单的数据流动就实现，需要双向地控制信息流动
          • deliver_data()
            • 被rdt调用，向上层应用交付数据（单向）
              • 接收方传输层处理完接收数据后才交付给应用层(丢了错了都不用告诉上一层）
      • Rdt 1.0（理想）
        • 可靠信道上的可靠数据传输
        • 特点
          • 底层信道完全可靠
            • 不会发生错误
            • 不会丢弃分组
        • 发送方和接收方的FSM独立（无耦合）
          • 不需要控制信息交互：发送方只要发出去就百分百无误到达接收方
          • 发送方
            •  event： 应用层调用rdt_send(data) actions： packet = make_pkt(data) //发送方从较高层接收数据，生成一个包含该数据的分组 udt_send(packet) //将分组发送到信道中
          • 接收方
            •  event： 接收方应用层调用rdt_rcv(packet)，(注意是接收方主动接收) actions： extract (packet,data) //接收方接收提取， deliver_data(data) //交付数据
            • 接收方主动接收数据分组
      • Rdt 2.x
        • Rdt 2.0
          • 只产生位错误的信道（分组不乱序不丢失）
          • 特点
            • 底层信道可能翻转分组中的位(bit)->利用校验和校测位错误
          • 如何从错误中恢复？(协作)
            • 差错检测
              • 检测比特位错误
            • 接收方反馈控制信息（确认机制）
              • ACK（acknowledgements ）
                • 接收方显式地告知发送方分组已正确接收
              • NAK（negative acknowledgements）
                • 接收方显式地告知发送方分组有错误
            • 重传机制
              • 发送方收到NAK后，重传分组
            • Rdt 2.0引入的新机制 （对比Rdt 1.0）
          • FSM规约
            • 发送方
              • 
            • 接收方
              •  Receiver也可调用udt_send()
            • 停-等协议
            • 特殊场景状态变迁图
              • 无错误
                • 
              • 有错误
                • 
          • 补充
            • ARQ：基于这种重传机制的rdt协议
        • Rdt 2.1和2.2
          • Rdt 2.0缺陷
            • 背景
              • ACK/NAK消息发生错误/被破坏，发送方无法识别
              • 添加额外控制消息不能从根本上解决（控制信息可能会坏掉）
            • 改进思路
              • 如何克服Rdt2.0缺陷（重传）
                • 1. 为ACK/NAK增加校验和，检错并纠错
                • 2. 若ACK/NAK坏掉，发送方重传
              • 新的问题（产生重复分组）
                • 已经正确传送，ACK坏掉
                • 已经正确传送，ACK延迟到达
              • 如何解决重复分组问题（序列号）
                • 发送方给每个分组增加序列号
                • 接收方丢弃重复分组（序列号相同）
          • Rdt 2.1
            • 状态翻倍
              • 应对ACK/NAK破坏
            • 发送方
              • 制作分组时需把序列号加入
                • 两个序列号
                  • 停等协议：两个序列号即可交替代表待发送文件和已发送文件两种状态
              • 成功发送分组
                • 收到ACK&&反馈控制信息正确（notcorrupt(rcvpkt)）
              • 重发分组
                • 收到NAK||反馈控制信息错误（corrupt(rcvpkt)）
                • 注意逻辑关系
            • 接收方
              • 成功接收分组
                • 无错误&&所期待序号的分组
                  • rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)&& has_seq0(rcvpkt)
              • 需重新接收分组
                • 收到非期待序号的分组
                  • 
                  • 如何理解？？？？为什么发送ACK
                • 分组错误
                  • 
          • Rdt 2.2
            • 与rdt 2.1功能相同，但是只使用ACK
              • 通过返回序列号来代替NAK
            • 如何实现
              • 接收方
                • 
                • 接收方通过ACK告知最后一个被正确接收的分组
                • 在ACK消息中显式地加入被确认分组的序列号
              • 发送方
                • 
                • 收到重复ACK后，采取与收到NAK消息相同的动作（重传）
        • 易混淆
          • 哪里加入checksum和序列号
            • Rdt2.0
              • 发送方发送数据制作分组时加入checksum
                • snkpkt = make_pkt(data, checksum)
            • Rdt 2.1
              • 发送方发送数据制作分组时加入checksum和序列号
                • sndpkt = make_pkt(0, data, checksum)
              • 接收方发送反馈控制信息时加入checksum
                • sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(NAK, chksum)
            • Rdt 2.2
              • 接收方发送反馈控制信息时ACK中加入checksum和序列号（NAK）
      • Rdt 3.0
        • 特点
          • 信道既可能发生错误有可能丢失分组
            • 发送方发送数据分组或者接收方的反馈控制信息直接丢失
        • Rdt 2.x缺陷
          • 丢失数据时无法处理->接收方/发送方一直等
          • 解决思路（定时器）
            • 发送方等待“合理”时间
              • 若没收到ACK，重传
              • 若分组或ACK只是延迟而不是丢了
                • 重传会产生重复，序列号机制能够处理 接收方需在ACK中显式告知所确认的分组
        • FSM
          • 发送方
            • 加入定时器（对比Rdt2.2）
              • 
          • 接收方
            • 补充
        • 示例情况
          • I. 操作无错误
            • 
          • II. 丢失数据分组(packet)
            • 
          • III. 丢失反馈控制信息（ACK）
            • 
          • IV. 反馈控制信息延误
            • 
            • 理解后续如何处理？
        • 性能分析
          • 网络协议限制了物理资源的利用
            • 启示：软硬件需协同设计，软硬件性能相匹配
            • 停等操作
              • 
          • 数学分析
            • 
      • 流水线机制与滑动窗口协议
        • 概述
          • 流水线机制
            • 内容
              • 多发几个数据分组再等待确认消息
            • 优点
              • 提高资源利用率
          • 流水线协议
            • 内容
              • 允许发送方在收到ACK之前连续发送多个分组
            • 新的要求
              • 需求取决于数据传输协议处理丢失、损坏及过度延时分组的方式。
              • 必须增加序号范围
                • 因为每个传输的分组(不计算重传的)必须有一个唯一的序号，而且也许有多个在传输中的未确认的分组
              • 发送方和/或接收方需要更大的存储空间以缓存分组
                • 发送方最低限度应当能缓冲那些已发送但没有确认的分组 接收方也需要缓存那些已正确接收的分组
          • 滑动窗口协议
            • 
            • 窗口
              • 允许使用的序列号范围
              • 窗口尺寸为N：最多有N个等待确认的消息
            • 滑动
              • 随着协议的运行（ACK返回），窗口在序列号空间内向前滑动
        • 滑动窗口协议
          • GBN（回退N步）
            • 发送方
              • 分组头部包含k-bit序列号
                • 2^k次方个序列号可以用
              • 扩展FSM
                • 定时器的设置问题（理解）
                  • 为何等于就停掉，不等于就重开
            • 接收方
              • ACK机制
                • 发送拥有最高序列号的、已被正确接收的分组的ACK
                  • 只需要记住唯一的expectedseqnum
                  • 可能产生重复ACK
                    • expectedseqnum = 5，but 收到 7；则发送ACK(4)；那么ACK(4）可能之前曾经发过
              • 接收情况
                • 按序到达的分组
                  • 如果一个序号为n的分组被正确接收到，并且按序(即上次交付给上层的数据是序号为n-1的分组)，则接收方为分组n 发送一个ACK，并将 该分组中的数据交付到上层。
                  • ACK（n）
                • 乱序到达的分组
                  • 1. 接收方没有缓存->直接丢弃
                  • 2. 重新确认序列号最大的、按序到达的最后一个分组序列号->发送ACK
              • 扩展FSM
                • 
              • 注意
                • GBN累积确认机制
                  • ACK(n)丢失触发发送方Timeout(n)事件
                  • 接收方收到连续的两个分组
                    • 只需对最大序列号确认就行（不用两个的ACK都发）
            • 相关机制
              • ACK(n)
                • 确认到序列号n(包含n)≤n的分组均已被正确接收
                  • n=max{收到的多个确认序列号} 
              • Timeout(n)事件
                • 重传序列号大于等于n，还未收到ACK的所有分组
          • SR（选择重传）
            • GBN缺陷
              • 充斥很多重传的分组
            • 发送方
              • 内容
                • 
                • data from above
                  • 上层有数据需要发送，此时可用的序列号又在窗口内，则发送pkt if next available seq # inwindow, send pkt
                • timeout(n)
                  • 每个分组必须有自己的定时器，因为超时后只能发送一个分组。
                  • resend pkt n, restart timer
                • ACK(n)
                  • ACK(n) in [sendbase,sendbase+N]:  mark pkt n as received  if n smallest unACKed pkt,advance window base tonext unACKed seq # 如果该分组的序号等于窗口左边缘的基序号，则窗口基序号向前移动到具有最小序号的未确认分组处。
              • 重传机制
                • 只重传没收到ACK的那些分组
                • 为每个分组设置定时器
              • 窗口
                • N个连续的序列号
                • 限制已发送且未确认的分组
            • 接收方
              • 内容
                • pkt n in [rcvbase, rcvbase+N-1]
                  • send ACK(n) out-of-order: buffer（缓存） 失序的分组将被缓存直到所有丢失分组(即序号更小的分组)都被收到，这时才它们按序交付给上层 in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt 如果该分组的序号等于接收窗口的基序号，则该分组以及以前缓存的、序号连续的分组交付给上层，然后接收窗口向前移动。
                • pkt n in [rcvbase-N,rcvbase-1]
                  • 不在窗口之内（可能之前发送的ACK丢失了，然后接收方重传分组） ACK(n)
                • otherwise:igoore
            • 窗口不一定同步
            • 困境
              • 序列号空间大小与窗口尺寸需满足N^S+N^R<=2^k
                • 发送方和接收方窗口尺寸不能太大，否则会导致重传的数据误认为新的数据
          • 区别
            • 定时器
              • SR：每个分组都有一个定时器
              • GBN：只有一个定时器