一、多路复用和多路分解

1、运输层端口号

2、概述

3、原理

1、无连接的多路复用与多路分解 - UDP

2、面向连接的多路复用与多路分解 - TCP

二、无连接运输——UDP用户数据报协议

1、UDP概述

2、UDP的优点

三、可靠数据传输原理

1、概述

2、rdt1.0——可靠信道上的可信数据运输

3、rdt2.0——产生位错误的信道

4、rdt2.1——发送方处理错误的ACK/NAK

5、rdt2.2——不需要NAK的协议

6、rdt3.0—— 比特差错和丢包的信道、比特交替协议

四、流水线可靠数据传输协议

1、流水线技术

2、回退N步协议GBN

3、选择重传

五、面向连接的传输——TCP传输控制协议

1、TCP概述

2、TCP报文段结构

（1）端口号

（2）序号和确认号

（3）数据偏移

（4）保留

（5）窗口rwnd

（6）校验和

（7）标志位

① 紧急标志位URG

② 推送标志位PSH

③ 复位标志位RST

④ 同步标志位SYN

⑤ 终止标志位FIN

（8）紧急指针

（9）选项（长度可变）

（10）填充

3、TCP可靠传输的实现

4、TCP超时重传时间的选择

（1）超时重传时间RTO选择

（2）计算超时重传时间RTO的方法

① RTTs加权平均往返时间

② RTTd偏差的加权平均

（3）误差分析

5、TCP流量控制

6、TCP拥塞控制

（1）慢开始

（2）拥塞避免

（3）快重传

（4）快恢复

7、TCP连接管理

（1）建立TCP连接

（2）释放TCP连接

六、UDP和TCP比较

七、TCP吞吐量

八、相关习题

一、多路复用和多路分解

1、运输层端口号

运行在计算机上的进程用进程标识符PID标志
不同的操作系统（windows、Linux）用不同格式的PID
TCP/IP体系的运输层用端口号来区分应用层的不同进程

端口号用16bit表示，取值范围0~65535

熟知端口号【0~1023】
指派给重要应用协议，例如：FTP——21/20，HTTP——80，DNS——53
登记端口号【1024~49151】
为没有熟知端口号的应用程序使用
短暂端口号【49152~65535】
留给客户进程选择暂时使用

端口号只有本地意义，只是为了标识本计算机应用层的各进程

2、概述

一个进程对应一个或多个套接字

多路分解（接收端）：报文段→各套接字将运输层报文段中的数据交付到正确的套接字的工作
多路复用（发送端）：各套接字→报文段从不同套接字中收集数据块，并在数据块封装上首部信息生成报文段，将这些报文段传递给网络层

3、原理

1、无连接的多路复用与多路分解 - UDP

UDP套接字用二元组标识（目的IP地址，目的端口号）

如果两个UDP报文段具有不同的源IP地址（或源端口号），但具有相同的目的ip地址和目的端口号，则这俩报文段将通过相同的目的套接字定向到相同的进程

2、面向连接的多路复用与多路分解 - TCP

主机A的P1和主机B的P3除了源IP地址外均相同，主机C能准确区分P1和P3
主机B的P2和P3除了源端口号外均相同，主机C能准确区分P2和P3

TCP套接字用四元组标识

（源IP地址源端口号目的IP地址目的端口号）

两个TCP报文段具有不同的源IP地址（或源端口号），将被定向到两个不同的套接字

二、无连接运输——UDP用户数据报协议

1、UDP概述

UDP从应用进程得到数据，附加上用于多路复用/多路分解服务的【源、目的端口号】，将形成的报文段交给网络层，网络层将其封装到IP数据报，然后将其交付给接收主机
当报文段到达接收主机，UDP使用目的端口号将报文段的数据交给正确的进程
在发送报文段之前，发送方和接收方运输层实体之间没有握手，因此是无连接的
DNS是一个通常使用UDP的应用层协议的例子
UDP段使用应用层协议提供可靠性

2、UDP的优点

无需建立连接 TCP需要三次握手，而UDP无须任何准备直接可以传输数据
无需维护连接状态
分组首部开销小 每个TCP报文段有20字节的首部开销，UDP只有8个字节的开销

三、可靠数据传输原理

1、概述

注：本节研究蓝框和绿框代表的可靠数据传输协议

（1）有限状态机FSM

2、rdt1.0——可靠信道上的可信数据运输

假设：下层信道完全可靠：既不会发生位错误，也不会丢弃分组（理想状态）
在发送方向接收方发送数据时，接收方不必要向发送方反馈任何消息，因为发送方能100%确保数据可以正确无误地发送到接收方

3、rdt2.0——产生位错误的信道

假设：可能发生比特位翻转错误：checksum 检测比特位错误（2.1，2.2都是这个错误）

ACKs（肯定确认）：接收方告知发送方，分组已正确接收——停等协议
NAKs（否定确认）：接收方告知发送方，分组有错误
当发送方收到NAK，重传数据包（pkt）——自动重传协议ARQ

rdt2.0缺点：

如果ACK/NAK出错，发送方不知道接收方出了什么情况
不能直接重传，因为可能发生重复传输
发送方需要让接收方知道自己发送的数据是新的还是旧的——在数据报添加顺序号

4、rdt2.1——发送方处理错误的ACK/NAK

给分组添加序列号

假设：ACK或NAK分组发生比特差错：如果发送方收到了含糊不清的ACK或NAK分组（发生比特差错）时，只需要重传当前分组既可。
然而这种方法会产生一个问题：接收方不知道发送方是否正确地收到了ACK或NAK分组，因此接收方无法事先确认它收到的是新的分组还是一次重传。解决这个问题的简单办法就是让发送方对其数据分组编号，并在分组中添加一个序号字段。这样接收方就可以根据分组序号来判断收到的是新的分组还是一次重传。

发送方：

接收方：

5、rdt2.2——不需要NAK的协议

与rdt2.1类似，但只使用ACKs，给ACK加上顺序号，不需要NACK
发送方收到重复的ACK，将进行与接收NAK后一样的动作：重传数据报

6、rdt3.0—— 比特差错和丢包的信道、比特交替协议

假设：既会产生比特差错，又会产生分组丢失
对于分组丢失：发送方发送一个分组时启动一个倒计数定时器，如果在倒计数定时器倒计时结束之前收到了ACK响应，则中断定时器，进入准备接收来自上层的下一次调用。如果倒计数定时器超时，则发送方认为分组丢失，向接收方重传该分组，并且重新启动定时器

注：

定时器超时有以下三种可能：数据分组确实丢失、ACK丢失、过度时延（发送方与接收方之间的一个往返时延大于倒计数定时器）
重传在发送方到接收方的信道中引入了冗余数据分组，但是rdt3.0是基于rdt2.2的，rdt2.2可以处理冗余数据分组，因此rdt3.0也可以处理冗余数据分组

四、流水线可靠数据传输协议

1、流水线技术

必须增加序号范围。因为每个输送中的分组(不计算重传的) 必须有一个唯一的序号，而且也许有多个在输送中的未确认报文。
发送方和接收方需要缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组。接收方或许也需要缓存那些已正确接收的分组。
所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。

解决流水线的差错恢复有两种基本方法：

回退N步(Go-Back-N，GBN)
选择重传(Selective Repeat, SR)

2、回退N步协议GBN

GBN协议：允许发送方发送多个分组而不需等待确认，但它也受限于在流水线中未确认的分组数不能超过某个最大允许数N，接收方丢弃所有失序分组

上图给出窗口长度N=4的GBN协议运行情况，发送方先发送分组0~3，在继续发送前，必须等待直到一个或多个分组被确认
当收到每一个连续的ACK（ACK0-ACK1），窗口向前滑动，可以发分组4、5
因为分组2丢失，则接收方丢弃失序分组3、4、5

GBN缺点：一旦超时，会有许多不必要重传的分组被重新传送，尤其是当窗口长度N很大时，随着差错率的提升，信道中会充斥着不必要重传的分组

3、选择重传

SR协议：让发送方仅重传那些它怀疑在接收方出错（丢失或受损）的分组从而避免不必要的重传，失序分组将被接收方缓存

五、面向连接的传输——TCP传输控制协议

1、TCP概述

点对点通信：发送者→接受者
全双工：可以同时双向传输数据（全双工——电话，半双工——对讲机）
面向连接：通信前双方先握手（交换控制报文），建立数据传输所需状态（套接字、缓存、变量）
可靠、有序的字节流：不保留报文边界
流水线

2、TCP报文段结构

（1）端口号

源端口号：16bit，发送方
目的端口号：16bit，接收方

（2）序号和确认号

序号：32bit 指出本TCP报文段数据载荷的第一个字节的序号

确认序号ack：指出期望收到对方下一个TCP报文段数据载荷的第一个字节的序号，也是对之前收到的所有数据的确认
（若确认号=n，说明到序号n-1为止所有数据都已经正确接收，期望收到序号为n的数据）
只有当ACK位取值为1时，确认序号段才有效，TCP规定在连接建立后所有传送的TCP报文段都必须把ACK置1

（3）数据偏移

数据偏移占4bit，以4B字节为单位
指出【TCP报文段的数据载荷部分的起始】距离【TCP报文段的起始处】有多远

实际上指出TCP报文段的首部长度

首部固定长度为20字节（5个单位），因此数据偏移字段的最小值为0101
首部最大长度为60字节（15个单位），因此数据偏移字段最大值为1111
设数据偏移=0101，则偏移值为5，5×4=20字节，即首部长度=20字节

（4）保留

占6bit，保留为今后使用，目前置为0

（5）窗口rwnd

占16bit，以字节为单位
指出发送本报文段一方的接收窗口
本报文【接收方】按照本报文【发送方的报文的窗口值】来设置自己的窗口值
以接收方的接收能力来控制发送方的发送能力，称为流量控制

（6）校验和

占16bit
检查范围：TCP报文段首部 + 数据载荷

（7）标志位

① 紧急标志位URG

URG=1时，紧急指针字段有效，URG=0时，紧急指针字段无效
当发送方有紧急数据时，可以将紧急数据插队到发送缓存的最前面，并立刻封装到报文段发送

② 推送标志位PSH

尽快上交应用进程，不必等到接收缓存都填满再向上交付

③ 复位标志位RST

复位TCP连接
当RST=1时，表明TCP连接出现异常，必须释放连接，再重新建立连接
用于拒绝一个非法报文段或拒绝打开一个TCP连接

④ 同步标志位SYN

在TCP连接建立时用于同步序号

⑤ 终止标志位FIN

用来释放TCP连接

（8）紧急指针

占16bit，指明紧急数据的长度

（9）选项（长度可变）

最大报文段长度MSS选项：TCP报文段数据载荷部分的最大长度
窗口扩大选项：扩大窗口，提高吞吐率
时间戳选项：用于计算往返时间RTT，用于处理序号超范围的情况（防止序号绕回PAWS）

（10）填充

因为选项长度可变，所以要用填充确保报文段首部能被4整除

3、TCP可靠传输的实现

5.7 TCP可靠传输的实现_哔哩哔哩_bilibili

TCP基于以字节为单位的滑动窗口来实现可靠传输

用SR选择重传协议——将失序分组保存在缓存中

相关题目：

4、TCP超时重传时间的选择

（1）超时重传时间RTO选择

如果超时重传时间RTO < 往返时间RTT——引起报文段不必要的重传，网络负荷增大

如果超时重传时间RTO >> 往返时间RTT——网络空闲时间增大，降低传输效率

综上：RTO应该设置为略大于RTT的值

（2）计算超时重传时间RTO的方法

$RTO=RTT_{S}+4\times RTT_{D}$

① RTTs加权平均往返时间

$RTT_{S1}=RTT_{1}$

$newRTT_{S}=(1- \alpha )\times oldRTT_{S}+\alpha \times newRTT_{sample}$

$\alpha =0.125$

② RTTd偏差的加权平均

$RTT_{D1}=RTT_{1}\div 2$

$newRTT_{D}=(1- \beta )\times oldRTT_{D}+\beta \times \left | oldRTT_{S}-newRTT_{sample}\right |$

$\beta =0.25$

出现超时重传，新的RTO=2倍旧RTO

（3）误差分析

5、TCP流量控制

5.4 TCP的流量控制_哔哩哔哩_bilibili

流量控制：让发送方的发生速率不要太快，要让接收方来得及接收，利用调整滑动窗口长度的机制

收到确认后，先滑动窗口，再流量控制（改变窗口大小）

相关习题：

6、TCP拥塞控制

5.5 TCP的拥塞控制_哔哩哔哩_bilibili

拥塞：对网络的某一资源需求超过该资源所能提供的可用部分，网络性能就会变坏

发送方维护一个拥塞窗口cwnd的状态变量：其值取决于网络的拥塞程度，并且动态变化
拥塞窗口cwnd的维护原则：

只要网络没有出现拥塞，拥塞窗口就再增大一些
但只要网络出现拥塞，拥塞窗口就减少一些

判断出现网络拥塞的依据：没有按时收到应当到达的确认报文 (即发生超时重传)

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd
维护一个慢开始门限sshresh状态变量：

当cwnd < sshresh时,使用慢开始算法
当cwnd > sshresh时，停止使用慢开始算法而改用拥塞避免算法
当cwnd = sshresh时，既可使用慢开始算法，也可使用拥塞避免算法

（1）慢开始

拥塞窗口cwnd是x，就可以发生x个数据报文段
如果接收方返回已传数据报个数m的确认报文段，则拥塞窗口cwnd=cwnd+m
当拥塞窗口值达到sshresh（慢开始门限），则进入拥塞避免算法

（2）拥塞避免

拥塞窗口只能+1，即cwnd=cwnd+1

假设报文段发生丢失，则发送方会对这些丢失报文段超时重传，则判断出现网络拥塞

将【慢开始门限值】更新为【发生拥塞时拥塞窗口的一半】
将拥塞窗口减少为1，并重新开始慢开始算法

（3）快重传

快重传：使发送方尽快进行重传，而不是等超时重传计时器超时再重传

要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认
即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传
对于个别丢失的报文段，发送方不会出现超时重传，也就不会误认为出现了拥塞 (进而降低拥塞窗口cwnd为1) ，使快重传可以使整个网络的吞吐量提高约20%