前言

课程链接
本文仅供个人预习和知识点记录你这不就是抄了一遍PPT吗用。

依照学校教学安排，第三章为应用层（即网课第五章）

3.1 运输层协议概述

3.1.1 进程之间的通信

• 运输层属于面向通信部分的最高层，同时也是用户功能中的最底层，运输层向它上面的应用提供通信服务
• 当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有位于网络边缘部分的主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能
  
• IP协议的作用范围是两个主机之间的所有链路和路由器 （提供主机之间的逻辑通信）
• 运输层协议TCP和UDP的作用范围是从一台主机的某个进程到另一台主机的进程之间 （为相互通信的应用进程提供了逻辑通信）

3.1.2 运输层的两个主要协议

• 在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信
• 运输层的两个重要功能：复用和分用
• 根据应用程序的不同需求，运输层需要有两种不同的运输协议：面向连接的传输控制协议TCP和无连接的用户数据报UDP

  基于端口的复用和分用功能

• 向下复用和向上分用
  • 发送方应用层的多个应用进程通过各自端口传入运输层并在运输层中重复使用TCP和UDP协议，对应转化为TCP报文段和UDP用户数据报，随后在网络层中重复使用IP协议，转换为IP数据报传送至接收方。
  • 接收方在网络层中分开使用IP协议，转化为TCP报文段和UDP用户数据报，在运输层中分开使用TCP协议和UDP协议，最后通过各自端口发给应用进程
    
• 运输层向高层用户屏蔽了下面网络核心的细节，它使应用进程“看见”的仿佛是一条在两个运输层实体间的端到端的逻辑通信信道，但这条通信信道对上层的表现却因运输层使用的不同协议而有很大的差别
  • 当运输层采用面向连接的TCP协议时 （对可靠性要求高），即使下面的网络不可靠，但逻辑通信信道相当于一条全双工的可靠信道
  • 当运输层采用无连接的UDP协议时 （对效率要求高），这种逻辑通信信道是一条不可靠信道
• TCP和UDP
  • 运输协议数据单元：两个对等实体在通信时传送的数据单位
  • TCP报文段：TCP传送的运输协议数据单元
  • UDP报文/用户数据报：UDP传送的运输协议数据单元
  • UDP：一种无连接协议
    • 提供无连接服务
    • 在传输数据之前不需要先建立连接
    • 传送的数据单位是UDP报文/用户数据报
    • 对方的运输层在收到UDP报文后，不需要给出任何确认
    • 虽然UDP不提供可靠交付，但在某些情况下UDP是一种最有效的工作方式 （因为要求少）
  • TCP：一种面向连接的协议
    • 提供面向连接的服务
    • 传送的数据单位协议是TCP报文段
    • TCP不提供广播或多播服务
    • 由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，这不仅使数据单元的首部增大很多，还要占用许多的处理机资源
• 补充：运输层的UDP用户数据报与网际/网络层的IP数据报有很大区别
  • IP数据报要经过互连网中许多路由器的存储转发
  • UDP用户数据报是在运输层的端到端抽象的逻辑信道中传送的

3.1.3 运输层的端口

• 运行在计算机中的进程是用进程标识符来标识的
• 运行在应用层的各种应用进程不应当让计算机操作系统指派它的进程标识符，这是因为互连网上使用的计算机的操作系统种类很多而不同的操作系统又使用不同格式的进程操作符
• 为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识

  端口号

• 为了解决不同操作系统下的应用进程在互连网上相互通信时进程标识符不统一的问题，我们在运输层使用协议端口号/端口
• 虽然通信的终点是应用进程，但我们可以把端口想象为通信的终点，因为我们只要把统一格式的报文交到目的主机的一个合适的目的端口，剩下交付给进程的过程就交由TCP完成

  硬件端口与软件端口

• 软件端口：协议栈层间的抽象的协议端口
• 硬件端口：路由器或交换机上的端口
• 硬件端口是不同硬件设备进行交互的端口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址

  TCP/IP运输层端口

• 端口用一个16位端口号进行标志 （意味着最多可以有2的16次方个软件端口）
• 端口号只具有本地意义 （两个主机的端口号可以相同），即端口号只是为了标识本计算机应用层中的各进程
• 在互连网中，不同计算机的相同端口号是没有联系的
• 两个计算机中的进程要互相通信，不仅必须知道对方的IP地址 （找计算机），而且还要知道对方的端口号 （找进程）

  两大类端口

• 服务器端使用的端口号
  • 熟知端口：一般为1-1023
  • 登记端口号：为1024-49151，供没有熟知端口号的应用程序使用的，使用这个范围的端口号必须在互联网数字分配机构IANA登记以防止重复
• 客户端使用的端口号
  • 又称短暂端口号，为49152-65535，留给客户进程选择暂时使用
  • 当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号，通信结束后这个端口号可供其他客户进程以后使用
    

3.2 用户数据报协议UDP

3.2.1 UDP概述

• UDP只在IP的数据报服务之上增加了一点功能：
  • 复用和分用的功能
  • 差错检测的功能
• 虽然UDP用户数据报只能提供不可靠的交付，但UDP在某些方面有特殊的优点
• UDP的主要特点
  • UDP是无连接的：发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延
  • UDP使用尽最大努力交付：UDP的尽最大努力是在IP的基础上的，即不保证可靠交付，因此主机不需要维持复杂的连接状态表
  • UDP是面向报文的
    • 发送方UDP对应用层交下来的报文，在添加首部后就向下交付IP层，既不合并，也不拆分，而是保留这些报文的边界
    • 发送时应用层交给UDP多长的报文，UDP就照样发送，一次发送一个完整的报文
    • 接收方UDP对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文
    • 应用程序必须选择合适大小的报文
      • 若报文太长，UDP交给IP层后在传输时可能要进行分片，这会降低IP层的效率
      • 若报文太短，UDP交给IP层后在传输时IP数据报中首部的相对长度太大，这会降低IP层的效率
    • UDP发送的报文长度是应用进程给出的
  • UDP没有拥塞控制：：由于UDP不用实现可靠传送网络出现额拥塞不会使源主机发送速率降低，这对某些实时应用很重要，很适合多媒体通信的要求
  • UDP支持一对一、一对多、多对一和多对多的交互通信
  • UDP的首部开销小：只有8字节，比TCP20个字节的首部要短，同时也意味着UDP的功能比TCP少

3.2.2 UDP的首部格式

• UDP用户数据报有两个字段：数据字段和首部字段，首部字段只有8个字节
• 8个字节的首部构成：源端口(2字节)+目的端口(2字节)+数据长度(伪首部+有效数据的字节长度)(2字节)+校验和(2字节)
• 12个字节的伪首部 （不占报文的地址空间，但在计算校验和的时候会临时把伪首部和UDP用户数据报连接在一起）构成：源IP地址(4字节)+目的IP地址(4字节)+8位全0(1字节)+8位协议（17）(1字节)+UDP长度(2字节)
• UDP校验和的计算：将数据报空余的部分填0，将伪首部、首部、数据以一字节为一段，两字节为一行从上到下排列，进行加法计算，产生的进位溢出加到结果的末位，然后将结果取反即得到校验和。
  
  UDP校验和计算教程

3.3 传输控制协议TCP概述

3.3.1 TCP最主要的特点

• TCP是面向连接的运输层协议：先建立连接再传输
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的、一对一的
• TCP提供可靠交付的服务：不重复、不丢失、不失序
• TCP提供全双工通信：双方都可以发送和接收
• 面向字节流
  • TCP中的“流”指的是流入或流出进程的字节序列
  • “面向字节流”的含义：虽然应用程序和TCP的交互时一次一个数据块，但TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节流
  • TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系，但接收方接收到的字节流必须和发送方应用程序发出的字节流完全一样：TCP不管你数据怎么分的块，但要求数据内容必须是一样的
  • TCP不关心应用进程一次把多长的报文发送到TCP缓存
  • TCP对连续的字节流进行分段，形成TCP报文段，但分段是不定的，TCP根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少字节
• 注意，TCP连接是运输层间的需连接，是逻辑上的通信信道
  

  3.3.2 TCP的连接

• TCP把连接作为最基本的工作/功能的抽象：所有的工作都要以连接建立为根本前提
• 每一条TCP连接有两个端点
• TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议接口，TCP连接的端点叫做套接字或插口
• 套接字就是IP后面加上端口号，socket=（ip地址：端口号），每一条TCP连接唯一地被通信两端的两个套接字所确定 TCP连接={socket1，socket2}={(ip:port1),(ip:port2)}
• 同一个IP地址可以有多个不同的TCP连接，同一个端口号也可以出现在多个不同的TCP连接中

3.4 可靠传输的工作原理

3.4.1 停止等待协议

理想的传输条件有两个特点

• 传输信道不产生差错
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据

然而实际的网络都不具备以上两个理想条件，故必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输

停止等待协议

• “停止等待”的思路：每发送完一个分组就停止发送，等待对方确认，在收到确认后再发送下一个分组
• 全双工通信的双方既是发送方也是接收方 （发送/接收数据和确认）

传输情况

• 无差错情况：A向B发送组1，发完暂停发送，等待B接收组1并传回确认后再发送组2
• 接收方B出现差错情况
  • 第一种：B接收组1时出现了差错，就丢弃组1，其它什么也不做（不传回确认）
  • 第二种：组1在传输过程中丢失了，B当然什么都不知道，因此也什么都不做
  • 在这两种情况下，B都不会发送信息
• 确认出现差错情况：确认信息在传输过程中丢失了
• 解决方案：超时重传
  • A为每个已经发送的组都设置了一个超时计时器
  • A只要在超时计时器到期之前收到了确认就撤销该超时计时器，继续发送组2
  • 如果超时计时器到期，就重新发送组1
  • 由此可见传输过程中的问题都由发送方解决

确认丢失和确认迟到

• 确认丢失
  • 若B所发送的对M1的确认丢失了，那么A在设定的超时重传时间内不能收到确认，但A无法知道是上述三种情况的哪种，因此A在超时计时器到期后就要重传组1
  • 假定B又收到了重传的组1（即确认信息丢失），此时B要采取两个行动
    • 丢弃这个重复的组1，不向上层交付
    • 向A发送确认：就算给A发送过确认信息也要再发送，正是因为A没有收到确认信息所以才重发组1
• 确认迟到
  • 若B所发送的对组1的确认传到A的时间过长（在超时计时器到期后送达），则A将重新发送组1，以第二次发送组1收到的确认和第一次发送收到的确认中较早者为时间点发送组2，第二次收到的对组1确认将丢弃
• 注意
  • 在发送完一个分组后，必须暂时保留已发送的分组的副本已备重发
  • 分组和确认分组都必须进行编号
  • 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些，以减少重发次数

    3.4.2 连续ARQ协议

• 通常A最终总是可以收到对所有发出的分组的确认，如果A不断重发却收不到确认，则说明通信线路太差，不能进行通信
• 使用停止等待协议的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信
• 像上述的这种可靠传输协议常称为自动重传请求ARQ,即重传请求是自动进行的，不需要接收方发送重传请求

信道利用率

• 停止等待协议的优点是简单，缺点是信道利用率太低
• 设分组发送所需时间为Td，确认发送所需时间为Ta（均不包含传送时间），两者的传送时间与分组确认接收时间总和为RTT，则信道利用率U=Td/(Td+RTT+Ta)
• 可以看出，当往返时间RTT远大于分组发送时间Td时，信道的利用率就会非常低，若出现重传，则对传送有用的数据信息而言，信道的利用率还要降低、

连续ARQ协议/流水线传输

• 为了提高传输效率，发送方采用流水线传输
• 流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停下来等待对方确认，这样可以使信道上一直有数据不间断地传送
• 由于信道上一直有数据不间断地传送，这种传输方式可以获得很高的信道利用率
• 仍然需要设置超时计时器
• 滑动窗口协议比较复杂，是TCP协议的精髓所在
  • 发送方维持的发送窗口：位于发送窗口内的分组都可连续发送出去而不需要等待对方的确认
  • 连续ARQ协议规定，发送方每收到一个确认，就把发送窗口（缓存中的一块区域）向前滑动一个分组的位置
    

累计确认

• 接收方一般采用累计确认的方式，即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，表示到这个分组之前的所有分组都已经正确收到了
• 优点：容易实现，即使确认丢失也不必重传
• 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息
• 对于缺点的补充：Go-back-N(回退N)
  • 如果发送方发送了x个分组，而其中第N个分组丢失了，此时接收方只能对第N个分组之前的所有分组发出确认，发送方无法得知第N个分组后其他分组的接收情况，只能将从第N个分组起的所有分组重新发送，即表示需要再退回来重传已发送过的分组
  • 可见当通信信道质量不好时，连续ARQ协议会带来不好的影响

TCP可靠通信的具体实现

• TCP连接的每一端都必须设有一个发送窗口和一个接收窗口
• TCP的可靠传输机制用字节的序号进行控制，TCP所有的确认都是基于序号而不是基于报文
• TCP两端的四个窗口经常处于动态变化之中
• TCP连接的往返时间RTT也不是固定不变的，需要使用特定的算法估算较为合理的时间

3.5 TCP报文段的首部格式

• TCP虽然是面向字节流的，但TCP传送的数据单元确是报文段
• 一个TCP报文段分为首部和数据两部分，而TCP的全部功能体现在它首部中各字段的作用
• TCP报文段首部的前20个字节是固定的，后面有4n（n为自然数）字节是根据需要而增加的选项，因此**TCP首部的最小长度是20字节)
  
• 源端口和目的端口字段各占2字节，端口是运输层和应用层的服务接口，运输层的复用和分用功能都要通过端口才能实现
• 序号字段占4字节，TCP连接传送的数据流中的每一个字节都编上一个序号，序号字段的值则指的是本报文段所发送的数据的第一个字节的编号
• 确认号字段占4字节，是期望收到对方的下一个报文段的数据的第一个字节的编号
• 数据偏移（即首部长度）占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远，数据偏移的单位是32位字（以4字节为计算单位）
• 保留字段占6位，保留为今后使用，但目前应置为0
• 六个标志位占六位
  • 紧急URG：当URG=1时，表明紧急指针字段有效，告诉系统此报文段中有紧急数据，应尽快传送
  • 确认ACK：当ACK=1时，确认号字段有效，0则无效
  • 推送PSH：当PSH=1时，就尽快的交付给接收应用进程，而不再等到整个缓存都填满后再向上交付
  • 复位RST：当RST=1时，表明TCP连接中出现严重差错（如主机崩溃），必须释放连接，然后再重新建立运输连接
  • 同步SYN：SYN=1表明这是一个连接请求或连接接受报文（确认连接）
  • 终止FIN：用于释放连接，FIN=1表示此报文段的发送端的数据已发送完毕，并要求释放运输连接
• 窗口字段占2字节，用来让对方设置发送窗口的依据 （告诉对方自己的接收窗口的大小），单位为字节
• 校验和占2字节，检验和字段检验的范围包括首部和数据两部分，计算检验和具体见3.2.2
• 紧急指针字段占2字节，指出在本报文段中紧急数据有多少个字节 *（紧急数据放在本报文段数据的最前面）
• 选项字段：长度可变。TCP最初只规定了一种选项，即最大报文段长度MSS，MSS高速对方TCP己方缓存能接收的报文段的数据字段（TCP报文段长度减去TCP首部长度）的最大长度是多少字节，字节数存储在MSS中。其他选项如下：
  • 窗口扩大选项占3字节，其中有一个字节表示移位S，新的2窗口值等于TCP首部中的窗口位数增大到16+S，相当于把窗口值向左移动S位后获得的实际的窗口大小
  • 时间戳选项占10字节，其中最主要的字段时间戳值字段占4字节，时间戳回送回答字段占4字节
  • 选择确认选项，见3.6.3
• 规定MSS的原因
  • MSS与接收窗口值没有关系
  • 若选择较小的MSS长度，网络的利用率就降低，因为TCP报文段越少，首部占比就越大，传输效率就越低，开销就显得大
  • 若TCP报文段很长，会使得开销增大，在IP层传输时就有可能要分解成多个端数据报片，在终点要把收到的各个短数据报片装配成原来的TCP报文段，当传输出错时还要进行重传，进而增大开销
  • 综上，MSS应尽可能大些，只要在IP层传输时不需要再分片就行
  • 由于IP数据报的路径是动态变化的，因此在这条路径上确定的不需要分片的MSS，如果改走另一条路径就可能需要进行分片
  • 综上，最佳的MSS很难确定

3.6 TCP可靠传输的实现

3.6.1 以字节为单位的滑动窗口

• TCP的滑动窗口是以字节为单位的
• 先假定A收到了B发来的确认报文段，其中窗口（接收能力）是20字节，而确认号（下一个报文段开头的序号）是31（表明序号30为止的数据已经收到了），根据窗口和确认号，A就构造出自己的发送窗口。
  • 发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去
  • 发送窗口里面的序号表示允许发送的序号
  • 显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率
  • TCP标准强烈不赞成发送窗口前沿向后收缩
    
• 发送时遇到字节未按序收到的解决方案
  • 当一部分字节未收到确认时，重新从未收到字节中序号最靠前的那个字节开始重新发送
  • 若发送窗口内的序号都已用完但还没有收到确认，必须停止发送 （不再发送后续字节）
• 发送方的应用进程把字节流写入TCP的发送缓存，发送缓存一般都比发送窗口大
  
• 接收方的应用进程从TCP的接收缓存中读取字节流，接收缓存一般都比接收窗口大
  
• 需要注意
  • A的发送窗口并不总是和B的接收窗口一样大（因为有一定的时间滞后）
  • TCP标准没有规定对不按序到达的数据如何处理，通常是先临时放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
  • TCP要求接收方必须有累计确认的功能，这样可以减少传输开销

    接收方发送确认

• 接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上
• 需要注意：
  • 接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，浪费了网络的资源
  • 捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据

    3.6.2 超时重传时间的选择

• 重传机制是TCP中最重要和最复杂的问题之一
• TCP每发送一个报文段，就对这个报文段设置一次计时器
• 只要计时器设置的重传时间已到但还没有收到确认，就要重传这一报文段
• 重传时间的选择是TCP最复杂的问题之一
  • 如果把超时重传时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大
  • 但若把超时重传时间设置得过长，则又使网络的空闲时间增大，降低了传输效率
• TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间，这两个时间之差就是报文段的往返时间RTT
• 往返时延的方差很大:由于TCP的下层是一个互联网环境，IP数据报所选择的路由变化很大，因而运输层的往返时间的方差也很大

  加权平均往返时间

• TCP保留了RTT的一个加权平均往返时间RTT_S（这又称为平滑的往返时间）
• 第一次测量到RTT样本时，RTT_S值就取为所测量到的RTT样本值，以后每测量到一个新的RTT样本，就按下式重新计算一次RTT_S
  
• 其中，0≤α≤1，若α很接近于0，表示RTT值更新较慢，若α接近于1，则表示RTT更新较快
• RFC2988推荐的α值为0.125

  超时重传时间

• RTO应略大于上面得出的加权平均往返时间RTT_S
• RFC2988建议使用RTO=RTT_S+4xRTT_D计算RTO，其中RTT_D是RTT的偏差的加权平均值
• RFC2988计算RTT_D的计算方法：第一次测量时，RTT_D值取为测量到的RTT样本值的一半，在以后的测量中，使用下式计算加权平均的RTT_D
  
• 其中β是一个小于1的系数，推荐值为0.25

  往返时间RTT的测量相当复杂

• 问题描述：TCP报文段1没有收到确认，重传后收到了确认报文段ACK，如何判定ACK是对第一次发出的报文段的确认还是对重传的报文段的确认？
• 解决方案：Karn算法
  • 思想：在计算平均往返时间RTT时，只要报文段重传了就不采用其往返时间样本
  • 优点：得出的加权平均往返时间RTT_S和超时重传时间RTO就比较准确
  • 缺点：当报文段的时延突然增大很多时，在原来得出的重传时间内不会收到确认报文段，导致需要重传的报文段占比增加，但根据Karn算法，这些报文段的往返时间样本将不予考虑，因此导致超时重传时间无法更新
  • 修正的Karn算法
    • 报文段每重传一次，就把RTO增大一些：新RTO=γx旧的RTO
    • 其中γ的典型值是2
    • 当不再发生报文段的重传时，才根据报文段的往返时延更新平均往返时延RTT和超时重传时间RTO的数值
    • 实践证明，这种策略较为合理

      3.6.3 选择确认SACK

• 针对的问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经准确到达接收方的数据？
• 接收方收到和前面字节流不连续的两个字节块，如果这些字节的序号都在接收窗口内，那么接收方就先收下这些数据，但**要把这些信息准确地高速发送方，使发送方不要再重复发送这些已收到的数据

  RFC2018的规定

• 如果要使用SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方都必须事先商定好
• 如果使用SACK，那么原来首部中的确认号字段的用法仍然不变，只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界
• 由于首部选项的长度最多只有40字节，而指明一个边界就要用到4字节，因此在选项中最多只能指明4个字节块的边界信息

3.7 TCP的流量控制

3.7.1 利用滑动窗口实现流量控制

3.7.2 TCP的传输效率

3.8 TCP的拥塞控制

3.9 TCP的运输连接管理

3.10 补充

• 使用TCP的网络应用：HTTP\FTP\TELNET\SMTP
• 使用UDP的网络应用：流媒体\视频会议\DNS\Internet电话