computer-network-note-5

传输层

传输层协议概述

进程之间的通信

• 传输层(Transport layer)又称为运输层
• 传输层向它上面的应用层提供通信服务
  • 实现可靠传输：差错控制、顺序控制、拥塞控制等
• 传输层 vs. 网络层
  • 网络层实现主机之间的逻辑通信
  • 传输层实现应用进程之间的逻辑通信
    • 真正的端到端通信
    • 复用(multiplexing)和解分(demultiplexing)
• 传输层主要协议
  • TCP 协议：可靠传输协议
  • UDP协议：不可靠传输协议

传输层的两个主要协议

• 传输层的两个主要协议
  • 用户数据报协议UDP
  • 传输控制协议TCP
• 传输的数据单位
  • OSI术语称为TPDU(Transport Protocol Data Unit)
  • TCP/IP体系称为TCP报文段(segment)或UDP用户数据报
• TCP协议
  • 可靠传输协议
  • 提供面向连接的服务
    • 传送数据前要先建立连接，传送结束后释放连接
    • 需进行确认、流量控制、计时器、连接管理等，处理开销较大
  • 基于TCP的典型应用协议：HTTP、FTP、 …
• UDP协议
  • 不可靠传输协议
  • 传送数据时无需建立连接
  • 与TCP相比，效率更高，但可能出现数据错、丢包、顺序错等问题
  • 基于UDP的典型应用协议：DNS、RIP、 …

传输层的端口

• 传输层需为多个应用进程提供服务 -> 复用与分用

  • 应用层多个应用进程通过传输层发送数据 -> 复用
  • 传输层收到的数据必须交付给指明的应用进程 -> 分用

• 传输层必须提供区分上层应用进程的手段：端口(port)

  • 问题：为什么不用进程ID？
    • 进程ID的定义依赖于特定操作系统
    • 一个应用进程常常需要与网络中的多个主机中的进程通信->多条连接

• 注意：此端口为软件端口，不同于计算机中的硬件I/O端口和交换机/路由器上的物理端口

• TCP/IP协议使用16位整数作为端口号

  • 源端口号、目的端口号

• 端口号分类

  • 熟知(well-known)端口号或系统端口号：数值一般为 0~1023
  • 登记端口号：数值为1024~49151
    • 供没有熟知端口号的应用程序使用
    • 须在 IANA 登记，以防重复
  • 客户端口号或短暂端口号：数值为49152~65535
    • 客户进程临时使用

用户数据报协议 UDP

UDP概述

• UDP 只在 IP 的数据报服务之上增加了很少一点的功能
  • 端口和差错检测
• UDP 为不可靠传输协议，但具有自身特点，与TCP分别面对不同的应用
• UDP协议的特点
  • 无连接，即发送数据之前不需要建立连接
  • 使用尽最大努力交付，即不保证可靠交付，同时也不使用拥塞控制
  • 是面向报文的。没有拥塞控制，很适合多媒体通信的要求
  • 支持一对一、一对多、多对一和多对多的交互通信
  • 首部开销小，只有 8 个字节

UDP首部格式

• UDP数据报包括2个字段：首部和数据字段
• 首部共4个字段，8字节
• 首部各字段
  • 源端口: 源端口号
  • 目的端口: 目的端口号
  • 长度: UDP数据报长度
  • 校验和: UDP数据报的校验和
• 伪首部(pseudoheader)：仅在计算校验和时使用，不实际传输
• 校验和的计算：与IP包头校验和计算类似
  • IP只计算包头校验和，UDP计算整个数据报的校验和
  • 计算校验和时要添加伪头部，奇数字节需填充0字节
• 在接收方，如果在目的端口号上没有应用进程接收数据，则向源主机返回ICMP的“目的不可达”报文

传输控制协议 TCP 概述

TCP的主要特点

• TCP 是面向连接的传输层协议

  • 传输数据前必须先建立连接，数据传输完毕后要释放连接

• 每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的 (一对一)

• TCP 提供可靠交付的服务

  • 无差错、不丢失、不重复、按序到达

• TCP 提供全双工通信

  • 在一个连接上，通信双方可同时向对方传输数据

• 面向字节流

  • 认为在TCP连接上传输的是字节流
  • 应用程序以数据块为单位与TCP交互，但TCP将其视为无结构的字节流
  • 结果：发送方应用进程发出的数据块与接收方应用进程收到的数据块可能没有一一对应关系，但数据保证一致

• 要注意的几点：

  • TCP连接是一条虚连接而不是一条真正的物理连接
  • TCP对应用进程一次把多长的报文发送到TCP的缓存中是不关心的
  • TCP根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)
  • TCP可把太长的数据块划分短一些再传送
  • TCP也可等待积累有足够多的字节后再构成报文段发送出去

TCP 的连接

• TCP把连接作为最基本的抽象

• 每一条TCP连接有两个端点

• TCP连接的端点不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口，TCP 连接的端点叫做套接字(socket)或插口

• 端口号拼接到(contatenated with) IP 地址即构成了套接字 套接字socket::=(IP地址：端口号)

• 每一条 TCP 连接唯一地被通信两端的两个端点(即两个套接字)所确定。即：

  TCP连接 ::={socket1，socket2}={(IP1:port1),(IP2:port2)}

TCP 报文段的首部格式

• 源端口和目的端口字段：各2字节

• 序号字段：4字节

  • 在TCP连接中传送的数据流中的每一个字节都有序号
  • 序号字段指本报文段所发送的数据的第一个字节的序号，以字节为单位

• 确认号字段：4字节，期望收到对方的下一个报文段的数据的第一个字节的序号

  • TCP连接是全双工，通信双方可互相发送数据，因此应答与数据一同发送给对方

• 数据偏移(首部长度)：4bit，TCP报文段的数据起始位置的偏移，也就是首部的长度，单位是32位字(4字节)

• 保留字段：6bit，保留

• 紧急URG：1bit，为1时，紧急指针字段有效，表明有紧急数据，应尽快传送

• 确认ACK：1bit，为1时，确认号字段有效；为0时，确认号无效

• 推送PSH：1bit，为1时，接收方将尽快向应用进程交付此报文段，而不是等到整个缓存填满

• 复位RST：1bit，为1时，表明TCP连接出现严重差错(如由于主机崩溃)，须释放连接后重新建立连接

• 同步SYN：1bit，为1时，表示这是一个连接请求或连接接受报文

• 终止FIN： 1bit，为1时，表示要求释放TCP连接

• 窗口大小：2字节，用来让对方设置发送窗口的依据，单位为字节

• 检验和：2字节，伪首部+首部+数据的校验和

  • 伪首部(pseudoheader)格式与UDP的伪首部相同

• 紧急指针：2字节，指出本报文段中紧急数据共有多少个字节(紧急数据放在数据的最前面)

• 选项：长度可变，最长40字节

  • 最早定义的一种选项：最大报文段长度MSS(Maximum Segment Size)
    • 告知对方报文段中数据最大长度，双方可使用不同的MSS，缺省MSS=536字节
  • 后续增加的选项：窗口扩大选项 、时间戳选项、选择确认选项

• 填充字段：为了使整个首部长度是4字节的整数倍

TCP可靠传输的实现

以字节为单位的滑动窗口

• TCP基于滑动窗口协议实现可靠传输和流量控制，滑动窗口以字节为单位
• 发送窗口
  • 在没有收到对方应答的情况下，可以连续把窗口内的数据发送出去
    • 即：窗口内的序号是允许发送的序号
  • 窗口大小的确定：对方发来的窗口大小、拥塞控制
  • 根据收到对方的TCP报文段头部中“acknowledge number”字段，窗口向前滑动
    • “acknowledge number”字段表示在此序号之前的数据已被正确接收
• 接收窗口
  • 窗口内的数据是允许接收的
  • 窗口后沿以外是已正确接收并交付上层的数据
• 发送缓存用来暂时存放：
  • 发送应用进程传送给TCP，但尚未发出的数据
  • 已发送，但尚未收到确认的数据
• 接收缓存用来暂时存放：
  • 按序到达的、但尚未被接收应用进程读取的数据
  • 未按序到达的数据
• A的发送窗口并不总是和B的接收窗口一样大
• TCP要求接收方必须有累积确认的功能，这样可以减小传输开销

超时重传时间的选择

• TCP的可靠传输通过校验和+超时重传实现

  • TCP每发送一个报文段，就对这个报文段设置一次计时器
  • 如果计时器设置的重传时间到，但还没有收到确认，就要重传该报文段

• 超时时间的设置是一个复杂的问题

  • IP层提供数据报服务，每个数据报所选择的路由都可能有变化
  • 传输层的往返时间变化较大

• TCP采用一种自适应算法计算超时重传时间

• 加权平均往返时间$RTT_S$

  • TCP 保留了RTT的一个加权平均往返时间$RTT_S$ (又称为平滑的往返时间)
  • 第一次测量到RTT样本时， $RTT_S$就取为该值
  • 以后每测量到一个新的RTT样本，按下式重新计算：
    新的$RTT_S=(1-\alpha)$x旧的$RTT_S+\alpha$x新的RTT样本,其中$0 \lt \alpha \lt 1$,$\alpha$越小，RTT的值更新越慢，$\alpha$越大，RTT值更新约快
  • RFC 2988 推荐$\alpha$=1/8，即 0.125

• 超时重传时间RTO(Retransmission Time-Out)

  • RTO应略大于$RTT_S$

  • RFC 2988 建议使用下式计算RTO：
    $RTO=RTT_S+4xRTT_D$

  • $RTT_D$ 是RTT的偏差的加权平均值

  • RFC 2988 建议这样计算 $RTT_D$

    • 第一次测量时，$RTT_D$值取为测量到的RTT样本值的一半

    • 在以后的测量中，使用下式计算加权平均的 $RTT_D$：

      新的$RTT_D$ = ( 1 - $\beta$ ) x 旧的$RTT_D$ x $\beta$ x|$RTT_S$ -新的RTT样本|

      其中0<$\beta$<1，推荐值是1/4，即 0.25

TCP的流量控制

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

• 流量控制(flow control)就是让发送方的发送速率不要太快，使接收方来得及接收

• 利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制

  • TCP连接建立过程中，将自己的接收窗口大小告知对方
  • TCP报头中都携带有窗口大小字段，告知对方自己接收窗口的剩余大小(即可接收的字节数)
  • 发送方的发送窗口应不大于对方的接收窗口

• 持续计时器(persistence timer)

  • TCP为每一个连接设有一个持续计时器
  • 只要一方收到对方的零窗口通知，就启动持续计时器
  • 若持续计时器设置的时间到，就发送一个零窗口探测报文段(仅携带1字节的数据)，而对方在确认这个探测报文段时给出当前窗口值
  • 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器
  • 若窗口不是零，则死锁的僵局就可以打破了

传输效率

• 可以用不同的机制来控制TCP报文段的发送时机

• 机制一：缓存数据达到一定量就发送

  • TCP维持一个变量，它等于最大报文段长度MSS
  • 只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去

• 机制二：应用进程控制

  • 由发送方的应用进程指明要求发送报文段，即推送(push)操作

• 机制三：定时发送

  • 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段(但长度不能超过 MSS)发送出去

TCP的拥塞控制

拥塞控制的一般原理

• 拥塞(congestion)概念和产生原因
  • 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，从而产生拥塞，即拥塞产生的条件：
    对资源的总和>可用资源
  • 网络资源：链路带宽、路由节点缓存及处理能力等
  • 网络拥塞是由多种原因引起的，通过简单地增加某种资源数量往往并不能消除拥塞
    • 报文可在缓存中排队，但如果路由器处理能力和出口链路带宽未增加，报文排队时间过长，发送主机将超时重发->拥塞没有解决
  • 网络拥塞的表现
    • 网络性能下降，具体表现为网络吞吐率下降、报文传输时延增大、丢包率增加、用户端响应时间变长、…
  • 拥塞常常会趋于恶化，即恶性循环
    • 由TCP重传机制引起
    • 如：一个路由器由于缓存不足丢弃了部分报文，发送端主机将超时重发，导致网络中被注入更多的报文，从而加剧拥塞
  • 拥塞控制(congestion control)与流量控制
    • 拥塞控制：防止过多的数据注入到网络中，使网络中的路由器或链路不致过载
    • 拥塞控制是全局性的过程，而流量控制是点对点通信量的控制，是端到端的问题
• 拥塞控制的作用

• 开环控制与闭环控制
  • 开环控制
    • 在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞
  • 闭环控制：基于反馈环路，有以下几种措施：
    • 监测网络系统以便检测到拥塞在何时、何处发生
    • 将拥塞发生的信息传送到可采取行动的地方
    • 调整网络系统的运行以解决出现的问题
• RFC 2581中定义了四种拥塞控制方法
  • 慢启动(slow-start)，又称为慢开始
  • 拥塞避免(congestion avoidance)
  • 快重传(fast retransmit)
  • 快恢复(fast recovery)

拥塞控制方法：慢启动(slow-start)和拥塞避免

• 慢启动进行拥塞控制的基本思路

  • 开始发送时，如果立即把大量数据注入网络，则可能导致拥塞
    • 因为此时不知道网络的负荷状况
  • 较好的方法是：试探性地从小到大逐渐增大发送窗口

• 拥塞窗口cwnd (congestion window)

  • 发送方维持拥塞窗口，它是一个状态变量
  • 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化
  • 发送方让自己的发送窗口等于拥塞窗口，如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口

• 发送方控制拥塞窗口的原则

  • 只要没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去
  • 一旦出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数

• 如何判断是否发生拥塞？

  • 拥塞发生时路由器将丢弃分组
  • 简单的主机端判断方法：只要没有收到确认，就认为发生了拥塞

• 慢启动的工作过程

  • 开始发送报文段时，设置拥塞窗口cwnd = 1，即设置为一个最大报文段MSS的数值
  • 每收到一个对新的报文段的确认后，将拥塞窗口加 1，即增加一个 MSS 的数值
  • 用这样的方法逐步增大发送端的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理

  注意：TCP中窗口大小是以字节为单位的为方便起见，这里以MSS为单位讨论拥塞窗口大小

• 传输轮次(transmission round)

  • 使用慢启动时，每经过一个传输轮次，拥塞窗口cwnd就加倍
  • 一个传输轮次所经历的时间其实就是往返时间RTT
  • 传输轮次更加强调：
    • 把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认

• 为防止拥塞窗口cwnd增长过大导致拥塞，设置一个慢启动门限ssthresh

  • cwnd < ssthresh时，使用慢启动算法
  • cwnd > ssthresh时，停止使用慢启动算法而改用拥塞避免算法
  • cwnd = ssthresh时，可使用慢启动算法或拥塞避免算法

• 拥塞避免算法的思路

  • 让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加 1，而不是加倍，使拥塞窗口cwnd按线性规律缓慢增长

• 拥塞发生时的处理

  • 无论在慢启动阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(没有按时收到确认)，就要把慢启动门限ssthresh改为出现拥塞时的发送方窗口值的一半(但不能小于2)
  • 然后把拥塞窗口cwnd重新设置为 1，执行慢启动算法
  • 这样做的目的：迅速减少注入到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕

• 乘法减小(multiplicative decrease)

  • 不论在慢启动阶段还是拥塞避免阶段，只要出现一次超时(即网络拥塞)，就把慢启动门限ssthresh减小到拥塞窗口的一半
  • 当网络频繁出现拥塞时，ssthresh值下降得很快，以大大减少注入到网络中的分组数

• 加法增大(additive increase)

  • 执行拥塞避免算法后，每经过一个往返时间RTT，把拥塞窗口cwnd增加一个MSS大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞

拥塞控制方法：快重传和快恢复

• 快重传(fast retransmit)算法思路

  • 如果发送方在超时时间内未收到确认报文，说明网络中发生了拥塞，此时发送方应尽早地减小窗口宽度
  • 每当接收方收到一个失序的报文段，就发出重复确认，以便使发送方及早知道有报文段没有到达接收方
  • 发送方只要接连收到三个重复确认就应当立即重传对方尚未收到的报文段

• 快恢复(fast recovery)算法思路

  • 当发送端收到连续三个重复的确认时，就进行“乘法减小”，把慢启动门限ssthresh减为当前拥塞窗口宽度的一半
  • 接下来不执行慢启动算法，而是设置为慢启动门限ssthresh减半后的数值，然后开始执行拥塞避免算法(“加法增大”)，使拥 塞窗口缓慢地线性增大
    • 发送方认为现在网络很可能没有发生拥塞(仅有拥塞征兆)，因为拥塞时不会有连续多个报文段到达接收方

• 发送窗口的上限值

  • 从流量控制角度考虑，发送窗口不能超过对方给出的接收窗口值

  • 综合考虑流量控制和拥塞控制，发送方的发送窗口的上限值应当在接收方窗口rwnd和拥塞窗口cwnd两个者中取较小的一个：

    发送窗口的上限值=Min[rwnd，cwnd]

    • 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值
    • 当 rwnd > cwnd 时，则是网络的拥塞限制发送窗口的最大值

TCP的连接管理

简介

• TCP传输连接有三个阶段
  • 连接建立
  • 数据传送
  • 连接释放
• 连接建立过程中要解决三个问题：
  • 使每一方能够确知对方的存在
  • 允许双方协商一些参数(如最大报文段长度、最大窗口大小、服务质量等)
  • 能够对传输实体资源进行分配(如缓存、连接表中的项目等)
• TCP 连接的建立都是采用客户/服务器方式
  • 客户(client)：主动发起连接建立的应用进程
  • 服务器(server)：被动等待连接建立的应用进程

TCP 的连接建立

• TCP连接的建立采用三次握手(three-way handshake)
  • A 向 B发出连接请求报文段，其首部中的SYN=1，并选择序号seq=x，表明传送数据时的第一个数据字节的序号是x
  • B收到连接请求后，如同意，则发回确认，其中SYN=1，ACK=1，确认号ack=x+1，自己选择的序号seq=y
  • A收到后向B给出确认，其ACK=1，确认号ack=y+1
• B收到后，TCP连接建立
• 为什么采用3次握手而不是2次？
  • 防止“失效的连接请求”在服务器端占用资源
    • 客户端发出了连接请求，但该数据报在网络中某处滞留了
    • 客户端等待超时后，重发连接请求，服务器响应，建立连接
    • 滞留的连接请求又到达服务器端，如果采用2次握手，服务器将建立一个连接，分配资源(缓冲区、定时器、…)  占用资源且长期存活
  • 3次握手带来的安全问题：TCP SYN Flooding攻击
    • 攻击者连续发送大量SYN报文，但却不对SYN ACK报文做出响应
    • 结果：服务器内部数据结构满，无法响应正常用户的TCP连接请求
    • 此类攻击大多使用IP地址伪装，使得对攻击源的定位比较困难
    • Linux内核采用了SYN_Cookies机制应对这种攻击
      • 基本思路：服务器返回SYN+ACK时，根据自身特有信息(时间戳、IP地址、端口号等)计算Cookies，作为seq返回给客户端，并在收到对方应答前，不为该连接分配数据结构

TCP的连接释放

• 连接的释放可由任一方发起

• (假定A主动关闭连接)A发送报文段，其首部的 FIN=1，序号seq=u

• B发出确认，ACK=1，确认号ack=u+1，序号seq = v

• A -> B方向的连接被释放，此时连接处于半关闭状态，B若发送数据，A仍要接收

• 若B已经没有要向A发送的数据，就向A发送连接释放报文(FIN=1, ACK=1)

• A收到后，发出确认，其中ACK=1，确认号ack=w+1，序号seq=u+1

• TCP连接必须经过时间2MSL后才真正释放掉

• 关于MSL

  • Maximum Segment Lifetime，报文段最大存活时间
  • RFC793中建议MSL=2分钟，一般使用更小的值

• 关闭连接前等待2MSL时间的原因

  • 为了保证A发送的最后一个ACK报文段能够到达B
  • 防止“已失效的连接请求报文段”出现在本连接中
    • A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段