【简记】Computer Networking——transport layer（tcp part）

最新推荐文章于 2022-10-23 12:16:42 发布

qqqqq1993qqqqq

最新推荐文章于 2022-10-23 12:16:42 发布

阅读量303

点赞数

分类专栏： Computer Networking

本文链接：https://blog.csdn.net/qqqqq1993qqqqq/article/details/73306168

版权

Computer Networking 专栏收录该内容

20 篇文章 1 订阅

订阅专栏

本part重点：

面向连接的TCP的特点
在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议
TCP的滑动窗口、流量控制、拥塞控制和连接管理

http://blog.csdn.net/hacker00011000/article/details/52319111
http://www.51testing.com/html/48/202848-249774.html
两篇有关握手挥手的好文

5.3 传输控制协议 TCP 概述
5.3.1 TCP 最主要的特点

TCP 是面向连接的运输层协议。首先建立连接，最后释放连接。
每一条 TCP 连接只能有两个端点(endpoint)，每一条 TCP 连接只能是点对点的（一对一）。
TCP 提供可靠交付的服务。无差错，不丢失，不重复，按序到达。
TCP 提供全双工通信。设有发送缓存和接受缓存，允许通信双方在任何时候都可以发送数据。
面向字节流。

TCP根据当前网络拥塞值和对方给出的窗口长度决定报文段的长度（UDP的报文段长度是应用层决定的）。所以TCP把应用层交下来的数据看成是无结构的字节流，可靠传输确保的是字节流保证相同。

5.3.2 TCP 的连接

TCP 连接的端点叫做套接字(socket)或插口。
套接字 socket = (IP地址: 端口号)

每一条 TCP 连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：
TCP 连接 ::= {socket1, socket2}
= {(IP1: port1), (IP2: port2)}

5.4 可靠传输的工作原理（只是分析基本思路，真正的TCP协议实现比这个更复杂）

5.4.1 停止等待协议

停止等待：每发送完一个分组就停止发送，等待对方的确认

（a）无差错情况
（b）超时重传
发送方在发送完一定时间后仍没有得到接收方的确认报文，就认定分组丢失，需要重传。
注意以下几点：
1.需要暂时保留已发送的分组的副本，方便重传
2.分组和确认分组都必须编号，才能明确需要重传的是哪个分组
3.超时计时器的设置时间应比正常的往返时间大一些（考虑到拥塞等）
这里写图片描述
（c）确认丢失和确认迟到

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest)。
ARQ 表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

信道利用率

但使用停止等待协议会导致信道利用率低下。
这里写图片描述

发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。由于信道上一直有数据不间断地传送，这种传输方式可获得很高的信道利用率。
这里写图片描述

5.4.2 连续 ARQ 协议

当使用流水线传输时，就需要用到连续ARQ协议和滑动窗口协议了。
这里写图片描述

当收到第一个分组的确认时，将发送窗口向前移动一位，意味着现在可以发编号为6的分组了。

累积确认：
接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认，而是对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都已正确收到了。

累积确认有的优点是：容易实现，即使确认丢失也不必重传。缺点是：不能向发送方反映出接收方已经正确收到的所有分组的信息。

TCP 可靠通信的具体实现：

TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。
TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。
TCP 两端的四个窗口经常处于动态变化之中。
TCP连接的往返时间 RTT 也不是固定不变的。需要使用特定的算法估算较为合理的重传时间。

5.5 TCP 报文段的首部格式

TCP的全部功能都体现在首部中各字段的作用上。
这里写图片描述

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。
序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。如本报文段的序号是301，携带的数据有100个字节，则下一个报文段的第一个序号是400。
确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。

若确认号是N，则表示到序号N-1为止的所有数据都已收到
数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。所以数据偏移的最大值是60字节（15*4），也是TCP首部的最大长度。
保留字段——占 6 位，保留为今后使用，但目前应置为 0。
紧急 URG —— 当 URG = 1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。
确认 ACK —— 只有当 ACK = 1 时确认号字段才有效。当 ACK  0 时，确认号无效。 TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1
推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付。
复位 RST (ReSeT) —— 当 RST = 1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。当SYN = 1,ACK = 0时，表示这是一个连接请求报文段。
终止 FIN (FINis) —— 用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。窗口指的是发送本报文段一方的接受窗口，从确认号算起，允许对方发送的数据量。因为接收方有接受缓存限制。
检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。
选项，最大40字节，当没有使用“选项时”，TCP首部是20字节

MSS (Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。是考虑到利用率和IP层分片规定的。

其他选项：
窗口扩大选项 ——占 3 字节，其中有一个字节表示移位值 S。新的窗口值等于TCP 首部中的窗口位数增大到(16 + S)，相当于把窗口值向左移动 S 位后获得实际的窗口大小。
时间戳选项——占10 字节，其中最主要的字段时间戳值字段（4 字节）和时间戳回送回答字段（4 字节）。
选择确认选项——在后面的 5.6.3 节介绍。

5.6 TCP 可靠传输的实现
5.6.1 以字节为单位的滑动窗口

（是把窗口内的字节封装成一个数据报发出？）
这里写图片描述

需要使用三个指针来描述A的发送状态。
此时B发送的确认号仍为31。（因为32和33未按序收到，说明31丢失）
这里写图片描述

A 收到新的确认号，发送窗口向前滑动
B 在按序收到部分序列号后，接收窗口也会向前滑动：
这里写图片描述

当A 的发送窗口内的序号都已用完，但还没有再收到确认，必须停止发送。

发送缓存和接收缓存：

这里写图片描述

发送缓存用来暂时存放：

发送应用程序传送给发送方 TCP 准备发送的数据；
TCP 已发送出但尚未收到确认的数据。

接收缓存用来暂时存放：

按序到达的、但尚未被接收应用程序读取的数据；
不按序到达的数据。

需要强调三点：

A 的发送窗口并不总是和 B 的接收窗口一样大（因为有一定的时间滞后）。
TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中（否则发送方会重传较多数据），等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
TCP 要求接收方必须有累积确认的功能（可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息带上），这样可以减小传输开销。

5.6.2 超时重传时间的选择

加权平均往返时间：
TCP 保留了 RTT 的一个加权平均往返时间 RTTS（这又称为平滑的往返时间）。
第一次测量到 RTT 样本时，RTTS 值就取为所测量到的 RTT 样本值。以后每测量到一个新的 RTT 样本，就按下式重新计算一次 RTTS：
这里写图片描述
推荐的 α 值为 1/8，即 0.125。

超时重传时间 RTO (RetransmissionTime-Out) ：

RTO = RTTS + 4 * RTTD
RTTD 是 RTT 的偏差的加权平均值。
RFC 2988 建议这样计算 RTTD 。第一次测量时，RTTD 值取为测量到的 RTT 样本值的一半。在以后的测量中，则使用下式计算加权平均的 RTTD ：
这里写图片描述

修正的 Karn 算法：
报文段每重传一次，就把 RTO 增大一些：
这里写图片描述

5.6.3 选择确认 SACK(Selective ACK)

已经收到但顺序错误，接收方通过选择确认的方法告诉发送方，使其减少重复传送。

如果要使用选择确认，那么在建立 TCP 连接时，就要在 TCP 首部的选项中加上“允许 SACK”的选项，而双方必须都事先商定好。

如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在 TCP 报文段的首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。

由于首部选项的长度最多只有 40 字节，而指明一个边界就要用掉 4 字节，因此在选项中最多只能指明 4 个字节块的边界信息。

注：目前大部分实现还是重传所有未被确认的数据块

5.7 TCP 的流量控制
5.7.1 利用滑动窗口实现流量控制

流量控制(flow control)就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

（大写ACK表示首部中的确认位，小写ack表示确认字段的值）
这里写图片描述

避免死锁情况发生：

上例中，B最后发送的窗口值为0，A收到此报文后将不再传输数据。假设之后B可以继续接收数据了，并发送了一个新的窗口值，而该报文段在传输过程中丢失了，就有可能发生死锁现象。

TCP 为每一个连接设有一个持续计时器。
只要 TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。
若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
若窗口不是零，则死锁的僵局就可以打破了。

5.7.2 必须考虑传输效率

可以用不同的机制来控制 TCP 报文段的发送时机：

第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP报文段发送出去。
第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送(push)操作。
第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。

TCP的实现中广泛使用Nagle算法（后补）

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

出现资源拥塞的条件：对资源需求的总和 > 可用资源

拥塞控制与流量控制的关系：

拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷
拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素
流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收

开环控制和闭环控制：

开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。
闭环控制是基于反馈环路的概念。属于闭环控制的有以下几种措施：

监测网络系统以便检测到拥塞在何时、何处发生。
将拥塞发生的信息传送到可采取行动的地方。
调整网络系统的运行以解决出现的问题。

5.8.2 几种拥塞控制方法

讨论的前提，假定：
（1）数据都是单方向传送，另一个方向只传送确认
（2）接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度决定

1.慢开始和拥塞避免

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。如再考虑到接收方的接收能力，则发送窗口还可能小于拥塞窗口。

判断出现拥塞的条件：没有按时收到确认报文，则猜想可能出现了拥塞。（现在通信线路的传输质量一般都很好，因传输差错而丢弃分组的概率是很小的。）

===

慢开始算法的原理：

在主机刚刚开始发送报文段时可先设置拥塞窗口 cwnd = 1，即设置为一个最大报文段 MSS 的数值。
在每收到一个对新的报文段（重传的不算在内）的确认后，将拥塞窗口加 1，即增加一个 MSS 的数值。所以经历一个RTT，可能拥塞窗口会成倍数增长。
用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理

这里写图片描述
（这里为了方便说明原理，将窗口单位改为了报文段个数，实际上窗口是以字节为单位）
（图中，慢开始算法的拥塞窗口值看起来像是成倍增长，其实是接收到一个确认就增长1）
（包括这里的确认号，也是概念上的，和之前说的TCP报文段的确认号不一样）

传输轮次(transmission round)：
一个传输轮次所经历的时间其实就是往返时间 RTT。
拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间。

===

拥塞避免算法的原理：

拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。

===
设置慢开始门限状态变量ssthresh：
慢开始门限 ssthresh 的用法如下：
当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

当网络出现拥塞时：
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认），就要把慢开始门限 ssthresh 设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。
然后把拥塞窗口 cwnd 重新设置为 1，执行慢开始算法。

这里写图片描述

乘法减小(multiplicative decrease) ：ssthresh变为原来的0.5倍
加法增大(additive increase) ：拥塞避免算法

===
2.快重传和快恢复

快重传算法

快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发送方及早知道有报文段没有到达接收方。
发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。
不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。
这里写图片描述

（5、6、7的确认什么时候传，还是说最后只传一个7就可以？
只传一个7，见下文）
http://www.cnblogs.com/ggjucheng/archive/2012/02/05/2339228.html

快恢复算法

(1) 当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。

(2)由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，即拥塞窗口 cwnd 现在不设置为 1，而是设置为慢开始门限 ssthresh 减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

TCP Reno版本：采用快恢复算法，慢开始算法只在TCP连接建立和网络出现超时时才使用。

发送窗口的上限值 = Min [rwnd, cwnd] （真实情况中）

5.8.3 随机早期检测 RED (Random Early Detection)

有时路由器处理分组的时间过长，路由器有一个分组丢弃策略，当路由器中队列已满时，会把后到的分组丢弃，导致发送方以为网络发生拥塞而重传，所以需要RED。

由于误判造成的拥塞控制，通常会使许多TCP在同一时间突然都进入到慢开始状态，这被称为全局同步。全局同步使全网的通信量突然下降很多又突然上升很多。这也是RED所要解决的问题。

这里写图片描述

检测到网络拥塞的早期征兆时，就先以概率p丢弃一些分组，可使得拥塞控制只在少数TCP上发生，避免全局同步。

这里写图片描述

5.9 TCP 的运输连接管理

5.9.1 运输连接的三个阶段

运输连接就有三个阶段，即：连接建立、数据传送和连接释放。

连接建立过程中要解决以下三个问题：

要使每一方能够确知对方的存在。
要允许双方协商一些参数（如最大报文段长度，最大窗口大小，服务质量等）。
能够对运输实体资源（如缓存大小，连接表中的项目等）进行分配。

这里写图片描述

A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x。此时ACK=0，说明这是一个连接请求报文。
B 的 TCP 收到连接请求报文段后，如同意，则发回确认。B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x = 1，自己选择的序号 seq = y。
A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y = 1。A 的 TCP 通知上层应用进程，连接已经建立。
B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。

※第三次握手可以携带数据。

Q：为什么需要三次握手，两次不行么？
A：不行。如果已失效的连接请求报文突然又传到了B，此时B向A发送了确认报文。假设没有第三次握手，B以为A要传送数据，但A并不传送，则B的资源会被浪费。所以需要三次握手。

5.9.2 TCP 的连接释放

这里写图片描述

数据传输结束后，通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的 FIN = 1，其序号seq = u，等待 B 的确认。
B 发出确认，确认号 ack = u + 1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收。
若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。此时B还要重复上次的确认序列号u+1。
A 收到连接释放报文段后，必须发出确认。在确认报文段中 ACK = 1，确认号 ack = w + 1，自己的序号 seq = u + 1。
TCP 连接必须经过时间 2MSL 后才真正释放掉。

A 必须等待 2MSL 的时间：
第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。若这个报文段在传输过程中丢失了，B会超时重传之前的确认报文段。如果A没有等待时间，在连接已经关闭的情况下，无法对重传的报文段进行回应，则B无法正常进入CLOSED状态。

第二，防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

补充：TCP还有个保活计时器。

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

5.9.3 TCP 的有限状态机

图中有三种不同的箭头。