计算机网络：传输层（TCP详解）

2023-12-13 20:43:29

文章目录

前言

TCP报文段结构、可靠数据传输、TCP连接管理（三次握手、四次挥手）、拥塞控制。

一、面向连接传输TCP

  • 点对点：
    • —个发送方，一个接收方
  • 可靠的、按顺序的字节流：
    • 没有报文边界
  • 管道化（流水线）：
    • TCP拥塞控制和流量控制设置窗口大小
  • 发送和接收缓存
    在这里插入图片描述
  • 全双工数据：
    • 在同一连接中数据流双向流动
    • MSS：最大报文段大小
  • 面向连接：
    • 在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量
  • 有流量控制：
    • 发送方不会淹没接收方

1.段结构

在这里插入图片描述

  • 序号：
    • 报文段首字节的在字节流的编号（在整个字节中的偏移量）
  • 确认号：
    • 期望从另一方收到的下一个字节的序号
    • 累积确认
  • Q：接收方如何处理乱序的报文段——没有规定

如下：主机A向主机B传输的序号42的字节（字母C），序号42字节到了主机B，主机B收到后回显，告诉主机A：我已经收到，我希望你传来43及以后的字节；对于主机B来说它受到主机A的确认号79，说明78及以前的字节主机A收到了，所以后面它将传输79及以后的字节。即：主机B向主机A回传的Seq = 79，ACK = 43。

在这里插入图片描述

TCP往返延时（RTT）和超时

Q：怎样设置TCP超时?

  • 比RTT要长
  • 但RTT是变化的
  • 太短：太早超时
  • 不必要的重传
  • 太长：对报文段丢失反应太慢，消极

Q：怎样估计RTT?

  • SampleRTT：测量从报文段发出到收到确认的时间
  • 如果有重传，忽略此次测量
  • SampleRTT会变化，因此估计的RTT应该比较平滑
  • 对几个最近的测量值求平均，而不是仅用当前的sampleRTT

在这里插入图片描述

在这里插入图片描述

2.可靠数据传输

  • TCP在IP不可靠服务的基础上建立了rdt
    • 管道化的报文段
      • GBN or SR
    • 累积确认（像GBN）
    • 单个重传定时器（像GBN）
    • 是否可以接受乱序的，没有规范
  • 通过以下事件触发重传
    • 超时（只重发那个最早的未确认段:SR）
    • 重复的确认
      • 例子：收到了ACK50,之后又收到3个ACK50

下面首先考虑简化的TCP发送方：

  • 忽略重复的确认
  • 忽略流量控制和拥塞控制

在这里插入图片描述

TCP发送方事件

  • 从应用层接收数据：用nextseq创建报文段
  • 序号nextseq为报文段首字节的字节流编号
  • 如果还没有运行，启动定时器
    • 定时器与最早未确认的报文段关联
    • 过期间隔：TimeOutInterval
  • 超时：
    • 重传后沿最老的报文段
    • 重新启动定时器
  • 收到确认：
    • 如果是对尚未确认的报文段确认
    • 更新己被确认的报文序号如果当前还有未被确认的报文段，重新启动定时器

TCP重传

在这里插入图片描述

产生TCP ACK的建议[RFC 1122. RFC 2581]

在这里插入图片描述

建议的实施见下面讲解

快速重传

  • 超时周期往往太长：
    • 在重传丢失报文段之前的延时太长
  • 通过重复的ACK来检测报文段丢失
    • 发送方通常连续发送大量报文段
    • 如果报文段丢失，通常会引起多个重复的ACK
  • 如果发送方收到同一数据的3个冗余ACK，重传最小序号的段：
    • 快速重传：在定时器过时之前重发报文段
    • 它假设跟在被确认的数据后面的数据丢失了
      • 第一个ACK是正常的;
      • 收到第二个该段的ACK，表示接收方收到一个该段后的乱序段;
      • 收到第3，4个该段的ack，表示接收方收到该段之后的2个，3个乱序段，可能性非常大段丢失了

根据下图通俗总结：下面五个报文段，先来了40-49的报文段，接收方立马回传ACK50的确认，后面本来要传50-59，但是60-69、70-79、80-89报文段依次来了，但是在这三个报文段来之后，接收方都依然依次回传ACK50。

在这里插入图片描述

TCP快速重传示意图：
在这里插入图片描述

在这里插入图片描述

3.流量控制

在这里插入图片描述

在这里插入图片描述

  • 接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
    • RcvBuffer大小通过socket选项设置(典型默认大小为4096字节)
    • 很多操作系统自动调整RcvBuffer
  • 发送方限制未确认(“in-flight”)字节的个数 ≤ 接收方发送过来的rwnd值
  • 保证接收方不会被淹没

4.TCP连接管理

在正式交换数据之前，发送方和接收方握手建立通信关系：

  • 同意建立连接（每一方都知道对方愿意建立连接）
  • 同意连接参数

同意建立连接（2次握手）

在这里插入图片描述

Q：在网络中，2次握手建立连接总是可行吗?

  • 变化的延迟(连接请求的段没有丢，但可能超时)
  • 由于丢失造成的重传(e.9.req_conn(×))
  • 报文乱序
  • 相互看不到对方

两次握手的失败场景：

  • 第一次发送连接请求，但是在连接确认回复时超时了，就发出第二次连接请求，结果发出去后，超时的确认终于到了，新发的连接未确认，确认连接的是以前超时的请求连接，导致维护了虚假连接。
  • 在上面的情况时，第一次请求连接建立后会发送数据，服务器接收数据，但是当第一次连接关闭后，新连接这时到达服务器得到确认并发送数据，服务器又收到数据。
  • 注意这里，你在第一次连接成功了，然后客户端做的操作会通过此连接传输数据，但是关闭第一次连接后，新连接终于连上，然后开始发送数据，这时的数据就是以前请求的数据，很难保证第一次连接做了其他数据传输，但第二次连接中也有。（类似于你在半连接成功后，第二次新连接成功前做了些操作，此时第一个连接肯定正常，但是第二个连接虽然未连接上，但是也发数据，当第一个关闭连接后，新连接终于连上，开始发送数据但是发送的时以前第一次连接关闭前传输过的老数据。）

在这里插入图片描述

TCP三次握手

  • 三次握手的关键是要确认对方收到了自己的数据包，这个目标就是通过“确认号（Ack）”字段实现的。计算机会记录下自己发送的数据包序号Seq，待收到对方的数据包后，检测“确认号（Ack）”字段，看Ack = Seq + 1是否成立，如果成立说明对方正确收到了自己的数据包。
  • 在开始握手时，客户端和服务器都会选择初始序号，这个初始序号是随机的，这样是为了避免半连接和接收老数据问题——正因为每次建立连接时Seq是随机的，而当个一个连接建立后，服务器和客户端就开始维护成功的连接的状态了，所以其他连接的Seq不在这个维护状态的范围内（如果运气很差随机值在这个维护范围内，那也没办法，网络不能解决所有问题）。
  • 所谓的维护范围：TCP连接的一方A，由操作系统动态随机选取一个32位长的序列号(InitialSequence Number)，假设A的初始序列号为1000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，1001，1002，1003…，并把自己的初始序列号ISN告诉B，让B有一个思想准备，什么样编号的数据是合法的，什么编号是非法的，比如编号900就是非法的，同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001，则意味着字节编号为1001-2000，共1000个字节已经安全到达。同理B也是类似的操作，假设B的初始序列号ISN为2000，以该序列号为原点，对自己将要发送的每个字节的数据进行编号，2001，2002，200…，并把自己的初始序列号ISN告诉A，以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001，则意味着字节编号为2001-4000，共2000个字节已经安全到达。

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

实际中，第三次握手通常跟第一次数据传递弄在一起
为什么要三次握手：

  • 第一次握手 ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
  • 第二次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
  • 第三次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

按照现在的理解2次握手是不行的，说根本点就是客户端（发起建立连接的一方）知道服务器（客户端的初始序列号与服务器达成了一致，相对于客户端来说），服务器其实并不知道客户端是否收到自己同步信号。

TCP关闭连接（四次挥手）

  • 客户端，服务器分别关闭它自己这一侧的连接
    • 发送FIN bit = l 的TCP段
  • 一旦接收到FIN，用ACK回应
    • 接到FIN段，ACK可以和它自己发出的FIN段一起发送
  • 可以处理同时的FIN交换

在这里插入图片描述

  • 第一次挥手：Clien发送一个FIN = 1，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
  • 第二次挥手：Server收到FIN = 1后，发送一个ACK给Client,Server进入CLOSE_WAIT状态，Client进入到FIN_WAIT_2状态。
  • 第三次挥手： Server发送一个FIN = 1，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
  • 第四次挥手：Client收到FIN = 1后，Client进入TIME_WAIT状态（假定 ACK 丢失,TIME_WAIT状态使TCP客户重传最后的确认报文），发送ACK给Server，Server进入CLOSED状态，完成四次握手。

在这里插入图片描述

5.拥塞控制

拥塞：

  • 非正式的定义:"太多的数据需要网络传输，超过了网络的处理能力”
  • 与流量控制不同
  • 拥塞的表现/原因：
    • 链路最大的吞吐量有限，当输入速率无限接近链路带宽时，延迟增大。
      在这里插入图片描述
    • 路由器的缓冲区是有限的，缓冲区溢出，新来分组丢失，发送端重传，传输层的输入又增加了重传的输入
    • 发送超时，重传多个分组拷贝
    • 没必要的重传，链路中包括多个分组拷贝
    • 分组经历比较长的延迟（在路由器的队列中排队）
  • 网络中前10位的问题

2种常见的拥塞控制方法：

  • 端到端拥塞控制：没有来自网络的显式反馈
    • 端系统根据延迟和丢失事件推断是否有拥塞
    • TCP采用的方法
  • 网络辅助的拥塞控制：路由器提供给端系统以反馈信息
    • 单个bit置位，显示有拥塞(SNA,DECbit,TCP/IP ECN,ATM)
    • 显式提供发送端可以采用的速率

机制

  • 端到端的拥塞控制机制
    • 路由器不向主机有关拥塞的反馈信息
      • 路由器的负担较轻
      • 符合网络核心简单的TCP/IP架构原则
    • 端系统根据自身得到的信息，判断是香发生拥塞，从而采取动作
  • 拥塞控制的几个问题
    • 如何检测拥塞
      • 轻微拥塞
      • 拥塞
    • 控制策略
      • 在拥塞发送时如何动作，降低速率
        • 轻微拥塞，如何降低
        • 拥塞时，如何降低
      • 在拥塞缓解时如何动作，增加速率

拥塞感知

发送端如何探测到拥塞？

  • 某个段超时了（丢失事件）：拥塞
    • 超时时间到，某个段的确认没有来
    • 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
    • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
    • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
  • 有关某个段的3次重复ACK：轻微拥塞
    • 段的第1个ack，正常，确认该段，期待紧挨着的第二个段
    • 段的第2个重复ack，意味着紧挨的的第二段的后一段（第三段）收到了，第三段乱序到达
    • 段的第2、3、4个ack重复，意味着第二段后的三个段收到了，他们都是乱序到达，但是就是没有第二段，所以第二段丢失的可能性很大
    • 网络这时还能够进行一定程度的传输，拥塞但情况要比第一种好

速率控制：速率控制方法

如何控制发送端发送的速率

  • 维持一个拥塞窗口的值：CongWin

  • 发送端限制已发送但是未确认的数据量（的上限）∶LastBytesent-LastByteAcked ≤ CongWin

  • 从而粗略地控制发送方的往网络中注入的速率
    在这里插入图片描述

  • Congwin是动态的，是感知到的网络拥塞程度的函数

    • 超时或者3个重复ack，Congwin值下降
      • 超时时: Congwin降为1MSS（最大报文段长度）,进入慢启动（SS）阶段然后再倍增到Congwin/2(每个RTT)，从而进入拥塞避免（CA）阶段
      • 3个重复ack : Congwin降为congwin/2 ,CA阶段
    • 否则（正常收到Ack，没有发送以上情况）: congwin跃跃欲试
      • SS阶段:加倍增加(每个RTT)
      • CA阶段:线性增加(每个RTT)

联合控制的方法

发送端控制发送但是未确认的量同时也不能够超过接收
窗口，满足流量控制要求

  • sendWin=min{CongWin, RecvWin};RecvWin是对方接收的空闲尺寸
  • 同时满足拥塞控制和流量控制要求

TCP控制策略

  • 慢启动
  • AIMD:线性增、乘性减少
  • 超时事件后的保守策略

TCP慢启动：

  • 连接刚建立，Congwin = 1MSS
    • 如:MSS = 1460bytes & RTT = 200 msec
    • 初始速率 = 58.4kbps
  • 可用带宽可能MSS/RTT
    • 应该尽快加速，到达希望的速率
  • 当连接开始时，指数性增加发送速率，直到发生丢失的事件
    • 启动初值很低
    • 但是速度很快
  • 当连接开始时，指数性增加（每个RTT）发送速率直到发生丢失事件
    • 每一个RTT，CongWin加倍
    • 每收到一个ACK时，CongWin加1MSS
    • 慢启动阶段:只要不超时或3个重复ack，一个RTT,CongWin加倍
  • 总结：初始速率很慢，但是加速却是指数性的
    • 指数增加，SS时间很短，长期来看可以忽略

在这里插入图片描述

TCP拥塞控制：AIMD

  • 乘性减：
    • 丢失事件后将congwin降为1，将congwin/2作为阙值,进入慢启动阶段（倍增直到congwin/2）
  • 加性增:
    • 当CongWin>阈值时，一个RTT如没有发生丢失事件,将congwin加1MSS：探测

在这里插入图片描述

  • 当收到3个重复的ACKs：
    • congwin 减半
    • 窗口（缓冲区大小）之后线性增长
  • 当超时事件发生时：
    • Congwin被设置成1MSS，进入SS阶段
    • 之后窗口指数增长
    • 增长到一个阈值（上次发生拥塞的窗口的一半）时，再线性增加

Q：什么时候应该将
指数性增长变成线性?
A：在超时之前，当congwin变成上次发生超时的窗口的一半
实现：

  • 变量:Threshold
  • 出现丢失，Threshold设置成CongWin的1/2

在这里插入图片描述

总结

以上就是TCP的讲解。

文章来源:https://blog.csdn.net/weixin_62951900/article/details/134838525
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。