【知识总结】第五章-传输层

提供的服务

功能

提供应用进程之间的逻辑通信
- 即端到端的水平方向通信，屏蔽传输层以下的实现细节
复用和分用
- 复用
  - 不同进程能使用同一传输层协议
- 分用
  - 接收的数据能正确交付到目的进程
差错检测
- 比网络层的差错检测更强，首部和数据部分都检查
可同时提供面向连接和无连接的服务
- 网络层同时最多只能提供一个

寻址和端口

端口

定义：传输层的服务访问点（TSAP）
性质：软件端口
- 硬件端口是接口中的CPU可访问寄存器
作用：使得传输层能和端口号标识的应用进程交换数据

端口号

定义：标识应用进程的16比特，范围0-65535
分类
- 服务器端口号
  - 熟知端口号：0-1023，由IANA（互联网地址指派机构）分配给被熟知的应用服务进程
  - 登记端口号：1024-49151，非熟知的应用服务进程在INAA处登记
- 客户端口号（短暂端口号、临时端口号）
  - 49152-65536，客户进程运行时选择，通信结束后丢弃

套接字

即Socket

定义
- Socket=（IP地址：端口号）
作用
- 唯一的标识网络中一个主机的一个应用

无连接服务和面向连接服务

无连接服务
- 基本概念：通信不需要建立连接，直接发送信息，尽力而为传送
- 常用协议：TCP/IP模型的UDP
面向连接服务
- 基本概念：通信前建立连接，通信时监管连接状态，通信后释放连接
- 常用协议：TCP/IP模型的TCP

应用举例

FTP（文件传输协议）
- 端口号：20/21
- 传输层协议：TCP
TELNET（远程登陆）
- 端口号：23
- 传输层协议：TCP
SMTP（简单邮件传输协议）
- 端口号：25
- 传输层协议：TCP
DNS（域名系统）
- 端口号：53
- 传输层协议：UDP
TFTP（小文件传输协议）
- 端口号：69
- 传输层协议：UDP
HTTP（超文本传输协议）
- 端口号：80
- 传输层协议：TCP
POP3（邮局协议版本3）
- 端口号：110
- 传输层协议：TCP
SNMP（简单网络管理协议）
- 端口号：161
- 传输层协议：UDP
RTP（实时传输协议）
- 端口号：5004/5005
- 传输层协议：UDP

UDP协议

UDP概述

功能（不提供可靠服务，应用层自行实现可靠性）
- 复用分用
- 差错检测
优点
- 不用建立连接
  - 没有建立连接时延
- 不用维护连接
  - 可支持更多客户机
- 首部短
  - 只有8字节
- 无拥塞控制
  - 适合允许数据较少丢失但不允许较大时延的应用
- 支持一对一、一对多、多对一、多对多的通信
  - 显然支持全双工

UDP数据报

结构
- UDP首部（8字节）
  - 源端口（2字节）：若不需要对方回信则默认为全0
  - 目的端口（2字节）：分用时若找不到目的端口则丢弃报文，发送ICMP端口不可达
  - 长度（2字节）：UDP数据报的长度，单位字节，至少是8
  - 校验和（2字节）：不需要校验UDP数据报则设置为全0
- 用户数据（即应用层报文）

功能的实现

封装（复用）
- 应用层报文（不进行分割）加上首部得到UDP数据报
拆分（分用）
- UDP数据报去掉首部得到应用层的报文
- 如果首部的目的端口正确，则向上提交报文
  - 否则丢弃报文，并给发送方回应ICMP端口不可达
校验（差错检测）
- 检测源IP地址、目的IP地址
- 检测首部
- 检测用户数据

UDP校验

发送方
- 校验和设置为全0
- 首部前临时添加伪首部（12字节）
  - 源IP（4字节）
  - 目的IP（4字节）
  - 零填充（1字节）：全0
  - 协议字段（1字节）：设为17
  - UDP数据报长度（首部和数据部分）（2字节）
- 数据部分后临时添加0填充，使得数据部分为偶数字节
- 以16位的字为单位，每个单位看作反码编码的数，按反码求和
  - 反码加法采用循环进位，把进位与结果相加
- 求和结果按位取反，回填到校验和中
  - 原理：设求和结果真值为A，则校验和真值为-A，接收方的校验结果真值为-0（全1）
  - 特殊处理：当求和结果为全1，不用取反成全0，直接回填即可
  - 特殊处理的原理：当求和结果真值为-0，校验和真值为-0而不是+0
  - 特殊处理的必要性：校验和为全0的情况，已被用来表示不采用校验和
  - 特殊处理的正确性：全1和全1的反码加法结果就是全1，不影响接收方的差错校验
- 删去伪首部和0填充，发送UDP数据报
接收方
- 首部前临时添加伪首部
- 数据部分后临时添加0填充，使得数据部分为偶数字节
- 以16位的字为单位，按反码求和
  - 求和结果为全1才说明无差错
- 若无差错，则删去伪首部和0填充，并拆分UDP数据报
  - 否则丢弃该UDP数据报

TCP协议

TCP功能

提供点对点的面向连接的服务
提供可靠交付
- 数据不丢失、不重复、不失序、无差错
提供全双工通信
- 发送方进程把数据发送到发送缓存
  - 数据收到确认后再移出缓存
- 接收方进程把数据从接收缓存取出
  - 失序的数据可提前进入缓存
提供面向字节流的管道
- 保证双方的字节序列相同
- 不保证数据块个数相同，因为用户数据可能被分割

TCP报文段

首部（20+4N字节）
- 源端口（2字节）：实现复用
- 目的端口（2字节）：实现分用
- 序号seq（4字节）：用户数据部分第一个字节的在整个字节流的序号
- 确认号ack（4字节）：期待对方发送的下一个报文段的第一个字节的序号
- 数据偏移（4位）：即首部长度，以4字节为单位，首部最长60字节
- 保留（6位）：暂时没用，置为0
- 标志字段（6位）
  - 紧急位URG：表示是否有紧急数据（一定从用户数据的第一字节开始）
  - 确认位ACK：表示确认号是否有效，TCP连接建立后必须置为1
  - 推送位PSH：表示是否尽快交付给进程，而不用等接收缓存满
  - 复位位RST：表示出现严重差错，连接必须释放、重新建立
  - 同步位SYN：SYN为1，ACK为0表示连接请求，SYN为1，ACK为1表示连接接受
  - 终止位FIN：表示数据发送完毕，要求释放连接
- 窗口（2字节）：本报文段发送方的接收窗口大小（接收缓存的字节余量）
  - 本报文段接收方发送窗口不能大于窗口字段值（流量控制）
- 校验和（2字节）：使用同UDP，唯一区别是伪首部的协议字段从17改成6
- 紧急指针（2字节）：表示紧急数据的字节数，紧急位为1时使用
- 选项
  - 最大报文段长度MSS：表示本报文段发送方能处理的最大用户数据字节数，默认536字节
  - 窗口扩大：用于扩大窗口字段
  - 时间戳：既能计算，又能处理序号在高速传输时因超过而重复的情况
  - 选择确认SACK：包含本报文段发送方缺少的数据的边界，本报文段接收方只需重传这些数据即可
- 填充字段：使首部是4字节的整数倍
用户数据（即应用层报文）

连接管理

连接采取客户/服务器方式，连接的两端即两个套接字

连接建立
- 第一次握手
  - 服务器的进程处于收听状态（LISTEN）
  - 客户机向服务器发送连接请求报文段（SYN=1,ACK=0,seq=x），该报文段不携带数据但消耗一个序号
  - 客户进程进入同步已发送状态（SYN-SENT）
- 第二次握手
  - 服务器收到后，如果同意，发送连接确认报文段（SYN=1,ACK=1,ack=x+1,seq=y），该报文段不携带数据但消耗一个序号
  - 服务器为连接分配缓存和变量
  - 服务器进程进入同步已收到状态（SYN-RCVD）
- 第三次握手
  - 客户机收到后，发送确认报文段（ACK=1,seq=x+1,ack=y+1），该报文段可以携带数据
  - 客户机分配缓存和变量
  - 客户进程进入连接已建立状态（ESTABLISHED）
数据传送
- 全双工通信
连接释放
- 第一次握手
  - 客户机发送连接释放报文段（FIN=1,seq=u），该报文段不携带数据但消耗一个序号
  - 客户机停止发数据，只能收数据（全双工变单向）
  - 客户进程进入终止等待1状态（FIN-WAIT-1）
- 第二次握手
  - 服务器收到后，发送确认报文段（ACK=1,seq=v,ack=u+1）
  - 服务器进入关闭等待状态（CLOSE-WAIT），服务器停止收数据，只能发数据（TCP连接半关闭）
  - 客户机收到后，客户进程进入终止等待2状态（FIN-WAIT-2）
- 第三次握手
  - 服务器若没有要发送的数据，则发送连接释放报文段（FIN=1,ACK=1,seq=w,ack=u+1）
  - 服务器进程进入最后确认状态（LAST-ACK）
- 第四次握手
  - 客户机收到后，发送确认报文段（ACK=1,seq=u+1,ack=w+1）
  - 客户进程进入时间等待状态（TIME-WAIT）。
  - 服务器收到确认报文段，进入连接关闭状态（CLOSED）
  - 经过2MSL（2倍最大报文段寿命）的等待时间，客户进程进入连接关闭状态（CLOSED）
补充
- 连接建立的第三次握手的必要性：考虑超时的连接请求突然到达服务器的情况（举例如下）
  - A向B的第一次握手，连接请求超时，A重传连接请求
  - A和B两次握手，传输数据，完成后断开
  - A超时的连接请求到达B，B误以为连接建立
- 连接释放的第四次握手以及期间让客户机等待2MSL的必要性
  - 考虑超时的连接请求突然到达服务器的情况（同连接建立第三次握手的必要性）
  - 考虑确认报文段丢失，服务器重传连接释放报文段的情况
- 连接建立中，易受到SYN泛洪攻击的原因
  - 根本原因：第二次握手服务器分配资源，第三次握手客户机分配资源
  - 直接原因：客户机发送大量SYN连接请求，服务器分配太多资源导致崩溃
- 连接建立中，初始序号随即设置而不固定的原因
  - 防止新连接和旧连接的报文段序号冲突，因此新连接和近期旧连接的初始序号不同

可靠传输

可靠传输，即保证数据不丢失、不重复、不失序、无差错

确认机制
- 使用首部的确认号字段，保证数据不重复（默认累计确认）
重传机制
- 下面两种情况进行重传，保证数据不丢失
- 超时
  - 发送报文段后开启计时器
  - 超时重传时间略大于加权平均往返时间
  - 为最近一次发送到接收的间隔（不考虑重传间隔，因为重传确认和原确认难区分）
  - 权值
- 冗余确认（冗余ACK）
  - 发送方收到三个冗余确认时（报文段确认号相同），则认为从该确认号开始的报文段丢失，进行快速重传（即没有超时也立刻重传）
序号机制
- 使用首部的序号字段，保证数据不失序
校验机制
- 使用首部的校验和字段，保证数据无差错

流量控制

和数据链路层流量控制的相同之处
- 流量控制目的：匹配发送方和接收方的速率
- 流量控制原理：基于滑动窗口机制
和数据链路层流量控制的不同之处
- TCP是端到端的流量控制，数据链路层是点到点的流量控制
- TCP的滑动窗口能动态调整
  - 接收方根据自己接收缓存的字节余量（接收窗口），发送确认时设置窗口字段，动态调节发送方发送窗口大小
- TCP采取累计确认，但提供选择确认选项SACK
  - 是GBN和SR的混合体

拥塞控制

拥塞窗口

拥塞窗口
- 对网络拥塞程度进行估计而设置的窗口（单位字节）
- 己方的发送窗口的上限为
  - 是己方的拥塞窗口，通过后面的拥塞控制算法获得
  - 是对方的接收窗口，通过对方发送的报文段的窗口字段获得
拥塞控制算法包括
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
接下来描述拥塞控制算法时，把己方最大报文段长度MSS作为己方拥塞窗口的单位
- 该做法只为了表述方便，实际上拥塞窗口的单位是字节

慢开始和拥塞避免

慢开始
- 刚建立连接，开始发送报文段时，
- 每收到一个新报文段的确认，
  - 冗余的确认不算
  - 累计的一个新确认算作多个新确认
- 大约每经过一个，
  - 大约每经过一个，会翻倍
  - 翻倍时不能跳过慢开始阈值
- 拥塞窗口到达后改用拥塞避免算法
  - ，使用慢开始
  - ，默认改用拥塞避免，也可使用慢开始
  - ，使用拥塞避免
拥塞避免
- 每经过一个，
  - 拥塞窗口从指数增长变成线性增长，以避免拥塞
确认超时
- 慢开始或拥塞避免阶段若出现确认超时，则认为网络出现拥塞
- 回到慢开始阶段

快重传和快恢复

本节在慢开始和拥塞避免的基础上改进

快重传
- 收到三个冗余确认时（报文段确认号相同），则认为从该确认号开始的报文段丢失，进行快速重传（即没有超时也立刻重传）
- 冗余的确认表明网络略微拥塞导致丢包，但不是严重拥塞，否则无法收到确认
  - 转入快恢复处理
快恢复
- 转入拥塞避免阶段，拥塞窗口线性增加