开始时间：2022年2月19日20:17:27（原定：2022年2月17日）

5.1 运输层概述

端到端 和 点到点 的区分

~~ 点到点通信 端到端通信
定义 直接相连的结点对等实体的通信叫点到点通信。
它只提供一台机器到另一台机器之间的通信，不会涉及到程序或进程的概念。		 端到端传输指的是在数据传输前，经过各种各样的交换设备，在两端设备建立一条逻辑链路，好像它们是直接相连的一样，链路建立后，发送端就可以发送数据，直至数据发送完毕，接收端确认接收成功。

完成不同应用进程间的通信
实现层次 由物理层、数据链路层和网络层组成的通信子网为网络环境中的主机提供点到点的服务 传输层
优点 发送端设备送出数据后，它的任务已经完成，不需要参与整个传输过程，这样不会浪费发送端设备的资源 链路建立后，发送端知道接收设备一定能收到，而且经过中间交换设备时不需要进行存储转发，因此传输延迟小
缺点 点到点通信并不能保证数据传输的可靠性，也不能说明源主机与目的主机之间是哪两个进程在通信，这些工作都是由传输层来完成的。 整个端到端通信要直到接收端收到数据为止，发送端的设备一直要参与传输，耗费资源。

端到端通信建立在点到点通信的基础之上，它是由一段段的点到点通信信道构成的，是比点到点通信
更高一级的通信方式，完成应用程序(进程)之间的通信。

运输层的任务
为运行在不同主机上的应用进程提供直接的通信服务
运输层的作用范围
应用进程到应用进程 图片.png（AP：application）

基于体系结构上分析运输层图片.png
图片.png

5.2 运输层端口号，复用，分用的概念

端口号
引入
不同操作系统对运行的应用进程标识的格式不同，导致难以通信，
TCP/IP体系为了在支持本体系的PC上无论OS均可相互通信，
统一在运输层加入端口号来区分应用层的不同应用进程
定义
16bit长的用以区分应用层不同进程的数值
注意
端口号只具有本地意义
熟知端口号
FTP 21 20
HTTP 80
DNS 53
TELNET 23
图片.png

发送方的复用和接收方的分用

发送方的某些应用进程所发送的不同应用报文均使用运输层的UDP协议（或TCP协议）进行封装称为UDP（或TCP）复用
例如：收发室的举例qq_pic_merged_1645280142364.jpg
图片.png

常用协议和所使用的运输层熟知端口图片.png

5.3 UDP和TCP的对比

小结图片.png

1 .图片.png
2.图片.png

3.图片.png注意：图示只画出了单端通信，实际上，TCP的两端可以同时进行TCP报文段的发送和接收，即 全双工通信

4.
UDP 接收方可根据数据报首部中的校验和字段检测出是否误码
但 就算发现有误码 仅仅丢弃该数据报 其他什么也不做
发送方，未成功发送数据报给接收方（可以是路由器拥挤或其他原因），发送方UDP不做任何处理
不可靠传输
TCP 基于逻辑链路的通信 ， 不会出现传输差错 可靠传输图片.png

5.
UDP首部 8B
TCP首部 【20~60】B
TCP首部更长是因为：
TCP要实现可靠传输，流量控制，拥塞控制等服务。图片.png

5.4 TCP的流量控制

引入
人们希望数据传更快一些！！！
但如果发送方发送数据过快，接收方可能来不及接收，造成数据的溢出丢失
所以要控制发送方的流量发送速率，引出 流量控制 的概念

流量控制： 让发送方的发送速率不要太快，要让接收方来得及接收

利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制图片.png

举例说明

前提：A和B之间已经建立TCP连接

1.TCP连接建立时，B告诉A，自身的接收窗口大小（400）
图片.png
A也将自己的发送窗口设置为400

这意味着主机A在未收到主机B发来的确认时，可将序号落入发送窗口中的全部数据发送出去图片.png
2.
涉及的名词
seq：此次发送数据的首个编号
ACK：TCP报文段首部中的标志位，取值1表示这是一个TCP确认报文段
ack：TCP报文段首部中的确认号字段，201 表示序号201之前的数据已全部正确接收，现希望收到序号201及其后续字段
rwnd：表示接收窗口的大小

发送窗口变化前图片.png
收到确认报文和接收窗口大小，改变发送窗口

A 】窗口移动
收到了ack=201 说明前两段已经OK，发送窗口向前移动两格（覆盖201~600）
B 】窗口缩/放
又结合rwnd=300 把发送窗口大小缩小为300 （覆盖201~500）
图片.png

改变窗口后，继续发送（包含超时重传）图片.png
有是一波发送窗口改变（1.先移动 2.后缩放）
过程略；结果为：图片.png

发送，以及改变发送窗口图片.png
若非零窗口的通告丢失，会造成死锁局面图片.png破解方法：
为此，TCP为每一个连接设有一个持续计时器
只要TCP连接的一方受到对方的零窗口通知，就启动持续计时器
若持续计时器超时，就发送一个零窗口探测报文，
对方收到该探测报文，回复自身窗口大小
如果回复报文内窗口值为0
则重启持续计时器
否则
死锁局面打破图片.png
为什么接收方的接收窗口为0，还能接收零窗口探测报文段？

TCP规定，即使接收窗口为0，也必须接收零窗口探测报文段，确认报文段，以及携带有紧急数据的报文段

题目
（先移动 再放缩）图片.png

小结图片.png

5.5 TCP的拥塞控制

引入图片.png

TCP的四种拥塞控制算法
讨论的假定条件图片.png
【慢开始 拥塞避免】
相关名词和规则
cwnd：即 拥塞窗口 其值取决于网络的拥塞程度 且动态变化
swnd：即 发送窗口
ssthresh：慢开始门限
cwndcwnd=ssthresh 慢开始/拥塞避免算法
cwnd>ssthresh 拥塞避免算法
图片.png图片.png
开始执行
在TCP双方建立逻辑连接时，会将 cwnd=1
还需设置ssthresh的初始值，本例取16

慢开始阶段 cwnd按指数形式增长
且swnd=cwnd
此时cwnd==ssthresh
图片.png
改用拥塞避免算法（让cwnd线性增加）图片.png
依次线性递增，直到遇到超时重传的发生图片.png

只要发送超时重传，这两个组合算法就会认为网络存在拥塞，采取措施
ssthresh=cwnd/2
cwnd=1
又重新用慢开始算法图片.png组合算法的最后结果图片.png

【快重传 快恢复】
快重传：使发送方尽快进行重传，而不是等超时重传计时器超时再重传
发送方连续发送报文
接收方连续接收报文并返回确认报文

对接收方
if 发现接收的报文未按序
return 已接收中按序的最后一个报文编号
对发送方
持续发送
if 收到3个连续的重复确认M i
return 报文M（i+1）
图片.png
快重传的作用：
对于个别丢失的报文段，发送方不等待超时重传，也不会误认为出现了拥塞，使网络吞吐量提高约20%。

快恢复
ssthresh=cwnd/2
cwnd=ssthresh
图片.png

四合一的体现图片.png

题目

重复确认用快恢复
超时用慢开始图片.png

5.6 TCP超时重传时间的选择

超时重传时间RTO应略大于往返时间RTT
RTO>>RTT 网络的空闲时间增大，降低了传输效率
RYO<image.png

**RTO = RTTs +4 x RTT
image.png

RTTs 和 RTTD都基于RTT，如何得到RTT？

出现超时重传时无法测准RTT：
image.png

解决方法：
v1.0
Karn 只要报文段重传了，就不采用其往返时间RTT作为样本
缺陷：不适用于较长时间的长延时网络状况
v2.0
修正Karn 报文段每重传依次，就把超时重传时间RTO增大一些
典型做法：RTO*=2
image.png

综上方法运用image.png

5.7 TCP可靠传输的实现

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

举例前提
0.收发双方已建立TCP连接
1.假定数据传输只在一个方向进行 （实际可同时双向进行）
2.网络不存在拥塞问题 （也就是说，发送方在调整自身swnd时，仅考
虑接收方的rwnd，不用考虑cwnd）

举例说明(从某一传输过程的中间开始)
假设发送方收到了一个来自接收方的确认报文
由该确认报文 rwnd=20 ack=31
可知
接收方的接收窗口为20
ack=31 是希望收到下一个数据的序号
也说明 前30个字节已确认无误接收
image.png

由此，可以分析出此时，发送方的swnd信息
即 从31起，20个字节
image.png

也可分析前后沿的各种移动可能
image.png

发送方可以将落在发送窗口的数据依次发送 出去【本例先依次发送31~41】
凡是已经发送，但未收到确认报文的数据，均需保留，以便在超时重传时使用
image.png

假设32和32组成的报文先到达接收方，被接收
但这是未按序接收，接收方会返回确认报文：
ack仍是31 希望收到31号数据
（这是由于接收方只能对按序收到的数据中的最高序号给出确认）

发送方收到确认报文，发现这是一个针对31号数据的重复确认
得知接收方收到了未按序到达的数据
但这只是第一个针对31号数据的重复确认
并不会引起发送方对该数据的快重传（连续接收到三次对同一编号的重复确认报文，才会对其快重传）
image.png

31赶到，被接收，接收方的接收窗口前移
返回确认报文，ack=34，从接收缓存中删除31~34
image.png

相应的，发送方继续根据确认报文，将发送窗口 先移动 再放缩
并删除已确认字节
【和TCP流量控制类似，图略。。】

倘若发送方的发送窗口内全部数据均已发送
发送方在未收到接收方发来确认的情况下，不能再发送新的数据
落在发送窗口呢的已发送数据，如果迟迟收不到接收方的确认，则会超时重传
image.png

TCP可靠传输的实现相关说明
1.接发双方的接发窗口大小的同步存在滞后性

2.TCP未明确规定 对于不按需到达的数据应如何处理

3.TCP要求接收方必须有累积确认和捎带确认机制，且接收方不应过分推迟发送确认（会导致不必要的超时重传）

4.TCP的通信是全双工通信（双方都可以是接/发方）
image.png

小结
image.png

5.8 TCP的运输连接管理（三握四挥）

5.8.1 TCP的运输连接管理之TCP的连接建立

TCP的连接建立要解决的三个问题
image.png

TCP的连接建立（“三报文握手”）
相关名词和规则
SYN：同步位 被设置为 1 说明这是一个TCP连接请求报文段
seq： x 作为TCP用户所选择的初始序号
TCP规定：SYN被设置为1的报文段不能携带数据，但要消耗掉一个序号
具体过程
个人图解
IMG_20220223_211559.jpg

视频图解
image.png

为什么TCP客户进程最后还要发送一个普通的TCP确认报文段呢？
这最后一段，是否多余？（为什么不是两报文握手？）

不多余，防止历史连接的建立

如下例
由于TCP客户进程并未发起新的TCP连接请求，并且处于关闭状态，不理会该TCP连接请求确认报文
对于，TCP服务器而言，已经进入连接已建立状态，一直等待TCP客户进程发来数据，白白浪费服务器主机资源
image.png

5.8.2 TCP的运输连接管理之TCP的连接释放

TCP通过“四报文挥手”来释放连接

前提知识
1.数据传输结束后，TCP通信双方都可以释放连接
2.
{
FIN：终止位 取1
ACK：确认位 取1
} 表明这是一个TCP连接释放报文段
{
seq：。。。
ack：对上一次接收的确认，本次希望得到的第一个字节编号
}
TCP规定终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号

举例说明过程
假设TCP客户端要发送的数据均已发送
TCP客户进程的应用进程拓展其主动关闭TCP连接
发送TCP连接释放报文给TCP服务器

服务器通知上层的应用进程并返回一个TCP普通确认报文
IMG_20220224_153835.jpg
此时：
TCP连接属于半关闭状态

从TCP客户进程到TCP服务器进程这个方向的连接就释放了

也就是TCP客户方没有数据要发送了，但如果TCP服务器方仍有数据要发送，TCP客户端也会接受

这也说明，从TCP服务器进程到TCP客户进程这个方向的连接还在

当服务器将要发的数据发送完之后（也可能没有要发送的数据了），
TCP服务器端被动关闭
返回TCP连接释放报文给TCP客户

TCP客户
收到连接释放报文后，返回TCP普通确认报文并等待2MSL时间
便进入关闭状态
TCP服务端
收到来自TCP客户的TCP普通确认便进入关闭状态
IMG_20220224_160537.jpg

为什么TCP在发送最后一个TCP普通确认报文后，要等待2MSL时间再关闭？

假设TCP客户发送该报文后直接进入关闭状态，但该报文发送过程中丢失了
导致TCP服务器长时间未收到确认报文而超时重传，但TCP客户已进入关闭状态，不予理会TCP服务器重传的报文，导致服务端无法进入关闭状态，反复超时重传，浪费其主机资源
image.png

TCP保活计时器
引入
假设已建立TCP连接的双方，其中TCP客户突然出现故障，无法发送数据，
TCP服务器总不可能建立了连接却白白耗着吧？

TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）
若超过计时器的时长，TCP客户仍未发送数据，则TCP服务器每隔75秒发送一个探测报文段，持续10次，仍未响应便主动关闭该TCP连接
image.png

5.9 TCP报文段的首部格式

前情回顾
image.png

TCP报文段首部格式
20字节的固定部分
最大40字节的拓展部分 （和IP数据报首部组成类似）
image.png

源端口和目的端口
源端口（16b）：标识发送该TCP报文段的应用进程
发送端口（16b）：标识接收该TCP报文段的应用进程
image.png
应用举例
image.png

序号，确认号，ACK（与TCP实现可靠传输相关的字段）
seq ack ACK

序号（32b） seq ：本TCP报文段数据载荷的第一个序列号
image.png

确认号（32b）：ack
希望对端发送给我方的TCP报文中的第一个数据编号
也表示，对之前收到的所有数据的确认
image.png

ACK： 取值为1时确认号才有效； 取值为0时确认号字段无效
TCP规定，在连接建立后所有传送的TCP报文段都必须把ACK置1
image.png

数据偏移：TCP报文段的首部长度
以4字节为单位
首部长度为20~~0101
60~~1111
image.png

保留：保留为今后使用
image.png

窗口（16b）： RWND
image.png

校验和（16b）：检测整个TCP报文段在传输过程中是否出现误码
image.png

同步标志位SYN：在TCP连接建立时用来同步序号
image.png

终止标志位FIN：用来释放TCP连接
image.png

RST（复位标志位） PSH（推送标志位）

RST：用来复位TCP连接 （重连）
当RST=1时，说明TCP连接异常，必须释放，重连
RST置1 还可用来拒绝非法的报文段或拒绝打开一个TCP连接
PSH：
接收方接收到TCP报文首部的PSH=1，将该报文尽快上交应用进程
而不必等到几首缓存都填满后再向上交付
image.png

URG（紧急标志位）+紧急指针 【用来实现紧急操作】

URG：
取值为1时，紧急指针有效
取值为0时，紧急指针无效
紧急指针（16b）：用来指明紧急数据的长度
当发送方有紧急数据时
可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。
image.png

可变部分
选项：一些扩展功能
image.png

填充：使TCP报文段首部是4的倍数

结束时间：2022年2月24日22:33:43 （提前了1天）