计算机网络-Part5——传输层

[TOC]

传输层概述

  • 只有主机才有的层次
  • 传输层的功能:
    • 传输层提供进程和进程之间的逻辑通信
    • 复用和分用
      • 复用:应用层所有的应用进程都可以通过传输层再传输到网络层。
      • 分用:传输层从网络层收到数据后交付指明的应用进程。
    • 传输层对收到的报文进行差错检测
    • 传输层的两种协议
  • 传输层的两个协议:
    • 面向连接的传输控制协议 TCP
      • 传送数据之前必须建立连接,数据传送结束后要释放连接。
      • 不提供广播或多播服务。
      • 由于 TCP 要提供可靠的面向连接的传输服务,因此不可避免增加了许多开销:确认、流量控制、计时器及连接管理等。
      • 特点:可靠,面向连接,时延大,适用于大文件
    • 无连接的用户数据报协议 UDP
      • 传送数据之前不需要建立连接,收到 UDP 报文后也不需要给出任何确认。
      • 特点:不可靠,无连接,时延小,适用于小文件
  • 传输层的寻址与端口
    • 端口号
      • 端口(逻辑端口/软件端口,区别于硬件端口)是传输层的SAP,标识主机中的应用进程。
      • 端口号只有本地意义,在因特网中不同计算机的相同端口是没有联系的。
      • 端口号长度为 16bit,能表示 65536 个不同的端口号。
      • image-20211220143918200
    • 寻址:
      • image-20211220144448803
      • 在网络中采用发送方和接收方的套接字组合来识别端点,套接字唯一标识了网络中的一个主机和它上面的一个进程。
      • 套接字 Socket =(主机地址,端口号)

UDP 协议

  • UDP 只在 IP 数据报服务之上增加了很少功能,即复用分用和差错检测功能。
  • UDP的主要特点:
    • 无连接,减少开销和发送数据之前的时延
    • 不保证可靠交付,使用最大努力交付
    • 面向报文,适合一次性传输少量数据的网络应用
    • 无拥塞控制,适合很多实时应用
    • 首部开销小,大小为 8B,TCP 是 20B
  • 应用层给 UDP 多长的报文,UDP 就照样发送,即一次发一个完整报文。
    • 使用 UDP 需要选择合适的报文长度。
      • 过长会被网络层分片(链路层有 MTU 要求);
      • 过短会使 IP 首部相对过大,降低网络层效率(希望尽可能减少负压信息、尽可能多的数据信息)。
    • image-20211220144949185
  • UDP 首部格式
    • 分用时,找不到对应的目的端口号,就丢弃报文,并给发送方发送ICMP“端口不可达”差错报告报文。
    • image-20211220150455794
  • UDP 校验
    • image-20211220150544166
    • 使用伪首部检验 UDP 用户数据报
      • 伪首部只有在计算检验和时才出现,不向下传送也不向上递交。
      • 17:封装 UDP 报文的 IP 数据报首部协议字段是 17
      • UDP 长度:UDP 首部 8B+ 数据部分长度(不包括伪首部)。
    • 在发送端:
      • 填上伪首部
      • 全 0 填充检验和字段
      • 全 0 填充数据部分(UDP 数据报要看成许多 4B 的字串接起来)
      • 伪首部+首部+数据部分采用二进制反码求和
      • 把和求反码填入检验和字段
      • 去掉伪首部,发送
    • 在接收端:
      • 填上伪首部
      • 伪首部+首部+数据部分采用二进制反码求和
      • 结果全为 1 则无差错,否则丢弃数据报/交给应用层附上出差错的警告。
    • image-20211220150955461

TCP 协议

TCP 协议特点和报文段格式

  • 特点:
    • 面向连接(虚连接)
    • 点对点:每一条 TCP 连接只能有两个端点
    • 可靠有序,不丢不重:TCP 提供可靠交付的服务,无差错、不丢失、不重复、按序到达
    • 提供全双工通信
      • 发送缓存:准备发送的数据 & 已发送但尚未收到确认的数据
      • 接收缓存:按序到达但尚未被接受应用程序读取的数据 & 不按序到达的数据
    • 面向字节流:把应用程序交下来的数据看成仅仅是一连串的无结构的字节流
  • TCP 报文段首部格式(重点)
    • 序号:在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号,本字段表示本报文段所发送数据的第一个字节的序号
    • 确认号期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N, 则证明到序号 N-1 为止的所有数据都已正确收到。
    • 数据偏移首部长度):TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远,以 4B 位单位,即 1 个数值是 4B。
    • 控制位:
      • 紧急位 URG:URG=1 时,标明此报文段中有紧急数据,是高优先级的数据,应尽快传送,不用在缓存里排队,配合紧急指针字段使用。
      • 确认位 ACK:ACK=1 时,确认号有效,在连接建立后所有传送的报文段都必须把 ACK 置为 1。
      • 推送位 PSH:PSH=1时,接收方尽快交付接收应用进程,不再等到缓存填满再向上交付。
      • 复位 RST:RST=1时,表明 TCP 连接中出现严重差错,必须释放连接,然后再重新建立传输链接。
      • 同步位 SYN:SYN=1时,表明是一个连接请求/连接接受报文。
      • 终止位 FIN:FIN=1时,表明此报文段发送方数据已发完,要求释放连接。
    • 窗口:指的是发送本报文段的一方的接收窗口大小,即现在允许对方发送的数据量。
    • 检验和:检验首部+数据,检验时要加上 12B 伪首部,第四个字段为 6(UDP 是 17)。
    • 紧急指针:URG=1 时才有意义,指出本报文段中紧急数据的字节数。
    • 选项:最大报文段长度 MSS、窗口扩大、时间戳、选择确认…
    • image-20211220165457244

TCP 连接管理

  • TCP 连接传输三个阶段:连接建立、数据传送、连接释放
  • TCP 连接的建立采用客户服务器方式,主动发起连接建立的应用进程叫做客户,而被动等待连接建立的应用进程叫服务器。
  • 过程:(三次握手)
    • 客户端发送连接请求报文段,无应用层数据。
    • 服务器端为该 TCP 连接分配缓存和变量,并向客户端返回确认报文段,允许连接,无应用层数据。
    • 客户端为该TCP连接分配缓存和变量,并向服务器端返回确认的确认,可以携带数据
    • image-20211220172255417
  • SYN 洪泛攻击:
    • SYN 洪泛攻击,发生在 OSI 第四层,利用 TCP 协议的特性(三次握手)。
    • 攻击者发送 TCP SYN,SYN 是 TCP 三次握手中的第一个数据包,而当服务器返回 ACK 后,该攻击者不对其进行再确认,导致这个 TCP 连接就处于挂起状态,即所谓的半连接状态。
    • 同时服务器收不到再确认,还会重复发送 ACK 给攻击者,进一步浪费服务器的资源。
    • 攻击者就对服务器发送非常大量的这种 TCP 连接,由于每一个都没法完成三次握手,所以服务器上,这些TCP连接会因为挂起状态而消耗CPU和内存,最后服务器可能死机,就无法为正常用户提供服务了。
  • TCP 的连接释放:(四次挥手)
    • 客户端发送连接释放报文段,停止发送数据,主动关闭 TCP 连接。
    • 服务器端回送一个确认报文段,客户到服务器这个方向的连接就释放了——半关闭状态。
    • 服务器端发完数据,就发出连接释放报文段,主动关闭 TCP 连接。
    • 客户端回送一个确认报文段,再等到时间等待计时器设置的 2MSL(最长报文段寿命)后,连接彻底关闭。
    • image-20211220181742363

TCP 可靠传输(非重点)

  • 网络层,提供尽最大努力交付、不可靠传输;传输层,使用 TCP 实现可靠传输。
    • 可靠:保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。
  • TCP 实现可靠传输的机制
    • 校验(与UDP校验一样,增加伪首部
    • 序号(序号字段指的是一个报文段第一个字节的序号,保证传输有序)
    • 确认(TCP 默认使用累计确认)
    • 重传(发送方在重传时间没有收到确认就要重传已发送的报文段)
      • 超时:TCP 采用自适应算法,动态改变重传时间 RTTs(加权平均往返时间)
      • 冗余 ACK(冗余确认):每当比期望序号大的失序报文段到达时,发送一个冗余 ACK,指明下一个期待字节的序号。
        • 例如,发送方收到 3 个对于报文段 1 的冗余 ACK,则认为 2 报文段丢失并只重传 2 号报文段(快速重传

TCP 流量控制(重点)

  • 流量控制:让发送方慢点,要让接收方来得及接收。
    • TCP 利用滑动窗口机制实现流量控制。
  • 在通信过程中,接收方根据自己接收缓存的大小,设置确认报文段的窗口字段,动态通知并调整发送方的发送窗口大小。
    • 发送方的发送窗口 = Min { 接收窗口 rwnd,拥塞窗口 cwnd }。
  • TCP 为每一个连接设有一个持续计时器,只要 TCP 连接的一方收到对方的零窗口通知,就启动持续计时器。
    • 若持续计时器设置的时间到期,就发送一个零窗口探测报文段。接收方收到探测报文段时给出现在的窗口值。
    • 若窗口仍然是 0,那么发送方就重新设置持续计时器。
  • image-20211220190918520

TCP 拥塞控制(重点)

  • 出现拥塞的条件:
    • 对资源需求的总和 > 可用资源
    • 网络中有许多资源同时呈现供应不足 -> 网络性能变坏 -> 网络吞吐量将随输入负荷增大而下降
  • 拥塞控制:
    • 防止过多的数据注入到网络中。
  • 拥塞控制与流量控制的区别:
    • 流量控制是点对点的控制,拥塞控制是全局性问题
    • 流量控制是发送过快,拥塞控制是迟迟接收不到
  • 假定:
    • 数据单方向传送,而另一个方向只传送确认
    • 接收方总是有足够大的缓存空间,因而发送窗口大小取决于拥塞程度
    • 发送窗口 = Min { 接收窗口 rwnd,拥塞窗口 cwnd }
      • 接收窗口:接收方根据接受缓存设置的值,并告知给发送方,反映接收方容量。
      • 拥塞窗口:发送方根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量。
    • 一个传输轮次:一个往返时延RTT。发送并收到确认。
  • 拥塞控制两种算法
    • 慢开始和拥塞避免
      • 一收到确认,就提高拥塞窗口数量
      • 新的门限值 = 网络拥塞时的拥塞窗口 ÷ 2
      • image-20211220194719790
    • 快重传和快恢复
      • 收到 3 个重复确认时,不重新开始,而是降为当前窗口的一半。
      • image-20211220194814988