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

文章目录

前言
一、面向连接传输TCP
- 1.段结构
- - TCP往返延时（RTT）和超时
- 2.可靠数据传输
- - TCP发送方事件
  - TCP重传
  - 产生TCP ACK的建议[RFC 1122. RFC 2581]
  - 快速重传
- 3.流量控制
- 4.TCP连接管理
- - 同意建立连接（2次握手）
  - TCP三次握手
  - TCP关闭连接（四次挥手）
- 5.拥塞控制
- - 机制
  - 拥塞感知
  - 速率控制：速率控制方法
  - 联合控制的方法
  - TCP控制策略
总结

前言

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时间很短，长期来看可以忽略