TCP与UDP：传输层详解与应用-优快云博客

本文链接：https://blog.youkuaiyun.com/NickHan_cs/article/details/118067208

计网复习——传输层

1. 传输层协议概述

1.1 进程之间的通信

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

在这里插入图片描述

1.2 传输层的两个主要协议

传输层的两个主要协议
- 用户数据报协议UDP
- 传输控制协议TCP

在这里插入图片描述

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

1.3 传输层的端口

传输层需为多个应用进程提供服务 $\rightarrow$ 复用与分用
- 应用层多个应用进程通过传输层发送数据 $\rightarrow$ 复用
- 传输层收到的数据必须交付给指明的应用进程 $\rightarrow$ 分用
传输层必须提供区分上层引用进程的手段：端口（port）
- 问题：为什么不用进程ID？
  - 进程ID的定义依赖于特定操作系统
  - 一个应用进程常常需要与多个主机中的进程通信 $\rightarrow$ 多条连接
注意：此端口为软件端口，不同于计算机中的硬件I/O端口和交换机/路由器上的物理端口
TCP/IP协议使用16位整数作为端口号
- 源端口号、目的端口号
端口号分类
- 熟知端口号或系统端口号：数值一般为0~1023
  - 例如：HTTP服务使用80，FTP服务使用21，…

在这里插入图片描述

登记端口号：数值为1024~49151
- 供没有熟知端口号的应用程序使用
- 须在IANA登记，以防重复
客户端口号或短暂端口号：数值为49152~65535
- 客户进程临时使用

2. 用户数据报协议UDP

2.1 UDP概述

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

2.2 UDP首部格式

UDP数据报包括2个字段：首部和数据字段
首部共4个字段，8字节
首部各字段
- 源端口：源端口号
- 目的端口：目的端口号
- 长度：UDP数据报长度
- 校验和：UDP数据报的校验和
伪首部：仅在计算校验和时使用，不实际传输

在这里插入图片描述

校验和的计算：与IP包头校验和计算类似
- IP只计算包头校验和，UDP计算整个数据报的校验和
- 计算校验和要添加伪头部，奇数字节需填充0字节

在这里插入图片描述

3. 传输控制协议TCP概述

3.1 TCP的主要特点

TCP是面向连接的传输层协议
- 传输数据前必须先建立连接，数据传输完毕后要释放连接
每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）
TCP提供可靠交付的服务
- 无差错、不丢失、不重复、按序到达
TCP提供全双工通信
- 在一个连接上，通信双方可同时向对方传输数据
面向字节流
- 认为在TCP连接上传输的是字节流
- 应用程序以数据块为单位与TCP交互，但TCP将其视为无结构的字节流
- 结果：发送方应用进程发出的数据块与接收方应用进程收到的数据块可能没有一一对应关系，但数据保证一致

在这里插入图片描述

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

3.2 TCP的连接

TCP把连接作为最基本的抽象
每一条TCP连接有两个端口
TCP连接的端口不是主机，不是主机的IP地址，不是应用进程，也不是传输层的协议端口，TCP连接的端口叫做套接字（socket）或插口
端口号拼接到IP地址即构成了套接字
$套接字 s o c k e t : : = (I P 地址 : 端口号)$
每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：
$TCP连接::=\{socket1, socket2\}=\{(IP1:port1),(IP2:port2)\}$

4. TCP报文段的首部格式

在这里插入图片描述

源端口和目的端口字段：各2字节
序号字段：4字节
- 在TCP连接中传送的数据流中的每一个字节都有序号
- 序号字段指本报文段所发送的数据的第一个字节的序号，以字节位单位
确认号字段：4字节，期望收到对方的下一个报文段的数据的第一个字节的序号
- 例：收到对方的报文段中序号为501，数据长度200字节，则返回报文段确认号=701
- 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，缺省MSS=536字节
- 后续增加的选项：窗口扩大选项、时间戳选项、选择确认选项
填充字段：为了使整个首部长度是4字节的整数倍

在这里插入图片描述

5. TCP可靠传输的实现

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

TCP基于滑动窗口协议实现可靠传输和流量控制，滑动窗口以字节为单位
发送窗口
- 在没有受到对方应答的情况下，可以连续把窗口内的数据发送出去
  - 即：窗口内的序号是允许发送的序号
- 窗口大小的确定：对方发来的窗口大小、拥塞控制
- 根据收到对方的TCP报文段头部中“acknowledge number”字段，窗口向前滑动
  - “acknowledge number”字段表示在此序号以前的数据已被正确接收

在这里插入图片描述

接收窗口
- 窗口内的数据是允许接收的
- 窗口后沿以外是已正确接收并交付上层的数据

在这里插入图片描述

发送缓存用来暂时存放：
- 发送应用进程传送给TCP，但尚未发出的数据
- 已发送，但尚未收到确认的数据
接收缓存用来暂时存放：
- 按序到达的、但尚未被接收应用进程读取的数据
- 未按序到达的数据
A的发送窗口并不总是和B的接受窗口一样大
TCP要求接收方必须有累积确认的功能，这样可以减少传输开销

在这里插入图片描述

5.2 超时重传时间的选择

TCP的可靠传输通过校验和+超时重传实现
- TCP每发送一个报文段，就对这个报文段设置一次计时器
- 如果计时器设置的重传时间到，但还没有受到确认，就要重传该报文段
超时时间的设置是一个复杂的问题
- IP层提供数据报服务，每个数据报所选择的路由都可能有变化
- 传输层的往返时间变化比较大
TCP采用一种自适应算法计算超时重传时间
加权平均往返时间 $RTT_{S}$
- TCP保留了 $R T T$ 的一个加权平均往返时间 $RTT_{S}$
- 第一次测量到 $R T T$ 样本时， $RTT_{S}$ 就取为该值
- 以后没测量到一个新的 $R T T$ 样本，按下式重新计算：
  $新的RTT_{S}=(1-\alpha)*旧的RTT_{S}+\alpha*新的RTT样本$
  其中， $\alpha < 1$ ， $\alpha$ 越小， $R T T$ 值更新越慢， $\alpha$ 越大， $R T T$ 值更新越快。推荐值是0.125。
超时重传时间 $R T O$
- $R T O$ 应略大于 $RTT_{S}$
- RFC 2988建议使用下式计算 $R T O$
  $RTO=RTT_{S}+4*RTT_{D}$
- $RTT_{D}$ 是 $R T T$ 的偏差的加权平均值
- RFC 2988建议这样计算 $RTT_{D}$
  - 在第一次测量时， $RTT_{D}$ 值取为测量到的 $R T T$ 样本值的一半
  - 在以后的测量中，使用下式计算加权平均的 $RTT_{D}$ ：
    $新的RTT_{D}=(1-\beta)*旧的RTT_{D}+\beta*|RTT_{S}-新的RTT样本|$
    其中， $0<\beta<1$ ，推荐值是0.25。

6. TCP的流量控制

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

流量控制（flow control） 就是让发送方的发送速率不要太快，使接收方来得及接收
利用滑动窗口机制可以很方便地在TCP连接上实现流量控制
- TCP连接建立过程中，将自己的接收窗口大小告知对方
- TCP报头中都携带有窗口大小字段，告知对方自己接收窗口的剩余大小（即可接收的字节数）
- 发送方的发送窗口应不大于对方的接收窗口

在这里插入图片描述

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

6.2 传输效率

可以用不同的机制来控制TCP报文段的发送时机
机制一：缓存数据达到一定量就发送
- TCP维持一个变量，它等于最大报文段长度MSS
- 只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送出去
机制二：应用进程控制
- 由发送方的应用进程指明要求发送报文段，即推送（push）操作
机制三：定时发送
- 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过MSS）发送出去

7. TCP的拥塞控制

7.1 拥塞控制的一般原理

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

在这里插入图片描述

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

7.2 拥塞控制方法：慢启动（slow-start）和拥塞避免

慢启动进行拥塞控制的基本思路
- 开始发送时，如果立即把大量数据注入网络，则可能导致拥塞
  - 因为此时不知道网络的负荷状态
- 较好的方法是：试探性地从小到大逐渐增大发送窗口
拥塞窗口cwnd（congestion window）
- 发送方维持拥塞窗口，它是一个状态变量
- 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化
- 发送方让自己的发送窗口等于拥塞窗口，如再考虑到接收方的接受能力，则发送窗口还可能小于拥塞窗口
发送方控制拥塞窗口的原则
- 只要没有出现拥塞，拥塞窗口就增大一些，以便把更多的分组发送出去
- 一旦出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数
如何判断是否发生拥塞？
- 拥塞发生时路由器将丢弃分组
- 简单的主机端判断方法：只要没有受到确认，就认为发生了拥塞
慢启动的工作过程
- 开始发送报文段时，设置拥塞窗口cwnd=1，即设置为一个最大报文段MSS的数值
- 每收到一个对新的报文段的确认后，将拥塞窗口加1，即增加一个MSS的数值
- 用这样的方法逐步增大发送端的拥塞窗口cwnd，可以使分组注入到网络中的速率更加合理

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

在这里插入图片描述

传输轮次（transmission round）
- 使用慢启动时，每经过一个传输轮次，拥塞窗口cwnd就加倍
- 一个传输轮次所经历的时间其实就是往返时间RTT
- 传输轮次更加强调：
  - 把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认
- 例如，拥塞窗口cwnd=4，这时的往返时间RTT就是发送方连续发送4个报文段，并收到这4个报文段的确认，总共经历的时间
为防止拥塞窗口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大小，使拥塞窗口缓慢增大，已放置网络过早出现拥塞

在这里插入图片描述

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

超时时间较长，待超时后再做拥塞处理有些过晚

快重传（fast retransmit）算法思路
- 如果发送方在超时时间内未收到确认报文，说明网络中发生了拥塞，此时发送方应尽早地减小窗口宽度
- 每当接收方收到一个失序的报文段，就发出重复确认，以便使发送方及早知道有报文段没有到达接收方
- 发送方只要接连收到三个重复确认就应当立即重传对方尚未收到的报文段
快恢复（fast recovery）算法思路
- 当发送端收到连续三个重复的确认时，就进行“乘法减小”，把慢启动门限ssthresh减为当前拥塞窗口宽度的一半
- 接下来不执行慢启动算法，而是设置为慢启动门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大
  - 发送方认为现在网络很可能没有发生拥塞（仅有拥塞征兆），因为拥塞时不会有连续多个报文段到达接收方

在这里插入图片描述

发送窗口的上限值
- 从流量控制角度考虑，发送窗口不能超过对方给出的接收窗口值
- 综合考虑流量控制和拥塞控制，发送方的发送窗口的上限值应当在接收方窗口rwnd和拥塞窗口cwnd两者中取较小的一个。
- 当rwnd < cwnd时，是接收方的接收能力限制发送窗口的最大值
- 当rwnd > cwnd时，则是网络的拥塞限制发送窗口的最大值

8. TCP的连接管理

8.1 简介

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

8.2 TCP的连接建立

TCP连接的建立采用三次握手（three-way handshake）

假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）阶段。在本例中，A主动打开连接，而B被动打开连接。

一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求，然后服务器就处于LISTEN（收听）状态，等待客户的连接请求。如有，即作出响应。
1. A的TCP客户进程也是首先创建传输控制块TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
2. B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack=x+1。同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。
3. TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。这是，TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。
当B收到A的确认后，也进入ESTABLISHED状态。

在这里插入图片描述

为什么采用3次握手而不是2次？
- 主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误（或者说防止“失效的连接请求”在服务器端占用资源）
  - 所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失了，第二个到达了B，没有“已失效的连接请求报文段”。
  - 现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才达到了B。本来这是一个早已失效的报文段。但B受到此失效的连接请求报文段后，就误认为是A又发出了一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用报文握手，那么只要B发出确认，新的连接就建立了。
  - 由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
  - 采用3次握手可以防止上述现象的发生。例如在刚才的异常情况下，A不会向B的确认发出确认，B由于收不到确认，就知道A并没有要求建立连接。
3次握手带来的安全问题：TCP SYN Flooding攻击
- 攻击者连续发送大量SYN报文，但却不对SYN ACK报文做出响应
- 结果：服务器内部数据结构满，无法响应正常用户的TCP连接请求
- 此类攻击大多使用IP地址伪装，使得对攻击源的定位比较困难
- Linux内核采用了SYN_Cookies机制应对这种攻击
  
  基本思想：服务器返回SYN + ACK时，根据自身特有信息（时间戳、IP地址、端口号等）计算Cookies，作为seq返回给客户端，并在收到对方应答前，不为该连接分配数据结构

8.3 TCP的连接释放

连接的释放可由任一方发起
（假定A主动关闭连接）A发送报文段，其首部的FIN=1，序号seq=u
B发出确认，ACK=1，确认号ack=u+1，序号seq=v

在这里插入图片描述

A $\rightarrow$ 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，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段

在这里插入图片描述