计算机网络：传输层（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时间很短，长期来看可以忽略

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的讲解。