计算机网络谢希仁——运输层知识点整理总结详情

本文章根据计算机网络谢希仁第6版知识点整理

期末复习了,记了一下笔记

第5章 运输层

本章内容：

• 运输层协议的特点
• 进程间的通信和端口概念
• 什么是UDP协议及其特点
• 什么是TCP协议及其可靠运输的工作原理
• TCP的三个重要问题：滑动窗口、流量控制和拥塞控制
• TCP的连接管理

本章要点：

1. 运输层为互相通信的应用进程提供逻辑通信
2. 端口和套接字的意义
3. 无连接的UDP的特点
4. 面向连接的TCP的特点
5. 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议
6. TCP的华东窗口和流量控制、拥塞控制和连接管理

5.1、 运输层协议概述

5.1.1进程之间的通信

1.运输层的作用

运输层向应用层提供通信服务

运输层为应用进程之间提供端对端的逻辑通信

网络层是为主机之间提供逻辑通信

2.运输层的功能

• 复用 ：发射方不同的应用进程都可以使用同一运输层协议传输数据

• 分用 ：运输层从IP层接收到数据后能正确分发给各个应用进程

• 差错检测:检验数据和首部是否出现差错

5.1.2 运输层协议

使用UDP和TCP协议的各种应用、应用层协议和他们的端口号

应用	应用层协议	运输层协议	端口
名字转换	DNS（域名系统）	UDP	53
文件传输	TFTP（简单文件传送协议）	UDP	69
路由选择协议	RIP(路由信息协议)	UDP
IP地址配置	DHCP（动态主机配置协议）	UDP
网络管理	SNMP（简单网络管理协议）	UDP	161
远程文件服务器	NFS（网络文件协议）	UDP
IP电话	专用协议	UDP
流式多媒体通信	专用协议	UDP
多播	IGMP	UDP
电子邮件	SMTP（简单邮件传送协议）	TCP	25
远程终端接入	TELNET（远程终端协议）	TCP	23
万维网	HTTP（超文本传输协议）	TCP	80
万维网	HTTPS（超文本传输协议安全）	TCP	443
文件传输	FTP（文件传输协议）	TCP	21

5.1.3 端口

端口TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。

• 服务器使用的端口号
  • 熟知端口：数值为0~1023
  • 登记端口:数值为1024~49151为没有熟知端口号的应用程序使用
• 客户端使用的端口号
  • 短暂端口：数值为49151~65535仅在客户进程运行时动态选择

5.2 UDP概述

1.UDP的特点

• 无连接
• 尽最大努力交付
• 面向报文
• 没有拥塞控制
• UDP支持一对一、一对多、多对一、多对多的交互通信
• UDP的首部开销小，仅有8字节

2.UDP的首部格式

字段名	字段意义	字段大小
源端口	源端口号	2
目的端口	目的端口号	2
长度	UDP用户数据报的长度，最小值为8（仅有首部）	2
检验和	检测数据报是否有错，有错就丢弃	2

5.3 TCP的概述

1. TCP的特点

• 面向连接
• 提供可靠交付
• 提供双全工通信
• 点对点（一对一）通信
• 面向字节流

2. TCP的首部格式

字段名	字段意义	字段大小（字节）
源端口	源端口号	2
目的端口	目的端口号	2
序号	TCP传送的字节流的每一个字节都按顺序编号	4
确认号	期望收到对方下一个报文段的第一个数据字节的序号	4
数据偏 移	指出首部长度，最大60，即选项长度不能超过40	4
保留	保留为今后使用，目前填0	6
紧急URG	URG=1表明紧急指针字段有效。报文段有紧急数据，发送方应尽快传送，而不是按原本的排队顺序传送	1
确认ACK	ACK=1表明确认号字段有效，在连接建立后所有传送的报文段都必须把ACK置1	1
推送PSH	PSH=1表明接收方应尽快地交付应用进程，而不是等到缓存满了再向上交付	1
复位RST	RST=1表明TCP连接出现了严重差错，必须释放连接，然后再重新建立运输连接。RST置1还用于拒绝非法的报文段打开一个连接	1
同步SYN	SYN=1表明这是一个连接请求或连接接受报文	1
终止FIN	FIN=1表明发送方数据已经发送完毕，要求释放连接	1
窗口	作为接收方，让发送方设置其发送窗口的大小，与确认号协同使用，确认好700，窗口1000，表示告诉发送方：从序号700开始，我只能再接收1000字节数据了	2
检验和	用于检验首部和数据是否有错，全为1表示	2
紧急指针	仅为URG=1才有意义，表明紧急数据在报文段中的位置	2
选项	可选，MSS最大报文长度,时间戳	0~40

TCP报文段的首部格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qURuzhpm-1611120692105)(C:\Users\10854\AppData\Roaming\Typora\typora-user-images\image-20201102105556445.png)]

3.TCP的连接

一条TCP连接需要有两个端点，TCP连接的端点叫**套接字socket**

套接字socket = (IP地址:端口号)

5.4 TCP 可靠传输的原理

运输层不使用如下两种协议，使用的是滑动窗口协议，这里只是阐述滑动窗口的原理由来

1. ARQ协议

自动重传请求ARQ(Automatic Repeat reQuest),即停止等待协议

停止等待协议的三种情况：

• 无差错情况

  发送方A每发送一个分组，接收方B接收后向A发送确认，只有当A收到确认后才会发送下一个分组

• 出现差错

  发送方A发送完分组后设置一个超时计时器，如果分组丢失了/分组出错了，接收方B不会发送任何确认，发送方在超时计时器时间到达后仍没有收到确认，就认为分组丢失了，重传之前发送过的分组

  注意：

  • 分组和确认分组必须编号，才能明确哪个分组有问题
  • 发送完分组后必须保留副本，以便分组丢失后重传，接收到确认后才可以清楚副本
  • 超时计时器设置的时间应该比平均往返时间长

• 确认丢失和确认迟到

  接收方B收到分组后发送确认，但是确认丢失了／迟到，发送方A没有收到确认再次重传，接受方B收到了重传的分组，丢弃这个重复的分组并再次发送确认

信道利用率: U = $\frac{T_D}{T_D+RTT+T_A}$

$T_D$ 发送方A发送分组需要的时间

RTT :往返时间

$T_A$ :接收方B发送确认分组的时间

2.连续ARQ协议

发送窗口:在ARQ协议的基础上，连续ARQ协议在发送方维持一个发送窗口，窗口的大小取决于流量控制/拥塞控制,发送方一次性将发送窗口内的分组发送出去,而不用等待确认,每收到一个确认发送窗口向前至该确认分组后一个位置

累计确认:不必对每一个分组发送确认,只需对按序到达的最后一个分组发送确认,表示到这个分组为止的所有分组都收到了

Go-back-N:需要退回来重传已经发送过的N个分组

如果发送方一次性5个分组中,第3个分组丢失了,接收方只能对前两个分组发送确认,发送方重新发送第3-5个分组(尽管后两个分组没有丢失)

Go-back-N动画模拟:点击

5.5 TCP可靠传输的实现

1.滑动窗口协议

先前的可靠传输原理中我们只假定了数据传输在一个方向上进行,即A到B,事实上TCP提供双全工通信,双方可以互相发送数据,在此协议中,双方都有各自的发送窗口和接受窗口,在此协议中,为了方便讲诉原理,仍然假定传输只在一个方向进行

• 正常流程:

  • 发送方维持一个发送窗口,可以一次性连续将所有分组发出,仍需保留副本

  • 接收方每收到一个按序的分组向前移动一个位置,直到收到了非按序分组,发送按序到达的最后一个分组的确认

  • 发送方接收到确认后向前移动至确认分组对应的分组后一个位置

接收缓存 : 1.用于存放不按序到达的数据 2.按序到达且未交付给应用程序的数据

发送缓存 : 1.应用程序发送给TCP准备发送的数据 2.用于存放TCP已发送但未收到确认的数据

发送缓存和接收缓存的空间是有序的,并且是循环使用的,这里涉及到后续的流量控制

• 分组丢失（假定发送窗口和接收窗口的大小为10）
  • 发送方A发送了1,2,3,4,5号分组,3号分组丢失了
  • 接收方B在接收到4号分组时,此分组未按序,同时向前移动两个位置,将1,2号分组交付给应用程序
  • 接收方B发送2号分组的确认,表示只接收到了1-2号分组
  • 接收方B将4,5号分组放入接收缓存中,等待3号分组接收后一并交付给应用程序
  • 发送方A收到２号分组的确认，发送窗口向前移动2个位置，但未收到3,4,5的确认
  • 在超时计时器到时间后重传3,4,5号分组

滑动窗口动画模拟:点击

5.6 TCP的流量控制

1.流量控制

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

发送方的发送窗口不能超过接收方给出的窗口值

持续计时器：TCP为每一个连接设有一个持续计时器，只要收到了零窗口通知，就启动持续计时器，时间到达后发送一个零窗口探测报文段（1字节）

探测报文段：1字节，用于探测接收方窗口值，接收方收到探测报文段后给出现在的窗口值，如果为零则重新设置持续计时器。

流程：

文件大小为16Kbytes，接收缓存大小为2Kbytes

• Host A先向Host B发送2k的数据，序号SEQ=0

• 当Host B接收数据后，因为缓存大小只有2K，满了，不能够再接收，此时Host B向Host A发送确认ACK=2048的零窗口通知，告诉Host A接收窗口WIN=0，不能够再接收了

• Host A收到通知后启动持续计时器，在持续计时器的时间到期后，就发送一个仅1字节的零窗口探测报文段。如果窗口仍为0则重新设置持续计时器

• 对方接收探测报文段后给出现在的窗口值，如图为WIN=2048，可以再发送2K的数据了

流量控制动画模拟 ：点击

2.TCP的传输效率

三种机制控制TCP报文段发送时机:

1. TCP维持一个变量，它等于最大报文段长度MSS,只要缓存中的数据达到MSS字节时，就组装成一个TCP报文段发送出去
2. 发送方的应用进程指明了要求发送报文段，即推送操作：TCP报文首部中PSH=1时
3. 发送方的一个计时器期限到了，就把当前缓存数据装入报文段（不能超过MSS）发送出去

在TCP的实现中广泛使用Nagle算法控制TCP报文发送的时机

Nagle算法：若应用进程把要发送的数据逐字节地送到发送缓存，则发送方把第一个字节先发送出去，后面到达的字节先缓存起来，等收到了接收方对第一个字节的确认后再把发送缓存中所有的数据组装成一个报文段发送出去，同时继续对后续到达的数据进行缓存。

Nagle算法规定收到对前一个报文段的确认才会继续发送下一个报文段，且当到达的数据已达发送窗口大小的一半或达到报文段的最大长度MSS时，就立刻发送一个报文段

糊涂窗口综合症：当接收方处理缓存区数据很慢，会使得应用进程之间传输的报文段很小，如探测报文段，可能只有1个字节，而传输开销却有40字节（20字节的IP首部，20字节的TCP首部）。这种现象叫糊涂窗口综合症

解决方法 ：

1. 让接收方等待一段时间，使得接收缓存有足够的空间容纳一个最长的报文段
2. 等到接收缓存已有一半的空闲空间

5.7 TCP的拥塞控制

1.拥塞控制的一般原理

拥塞:某段时间中，网络某一资源的需要超过了该资源所能提供的可用部分，网络的性能就要变坏

​ $\sum 对资源的需求>可用资源$

2.TCP的拥塞控制方法

拥塞控制有四种方法，即慢开始、拥塞避免、快重传和快恢复

本节中我们假定：

1.数据是单方向传送的，

2.接收方总是有足够的缓存空间

1. 慢开始和拥塞避免

慢开始:从小到大逐渐增大发送窗口cwnd，每收到一个对新的报文段的确认后，就可以增加一个最大报文段SMSS的数值，所以每经过一个传输轮次，拥塞窗口cwnd就加倍

为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh，当慢开始拥塞窗口cwnd达到门限后就改用拥塞避免算法

拥塞避免：让拥塞窗口cwnd缓慢的增长，每经过一个往返时间RTT就让拥塞窗口加1，而不是像慢开始一样成倍增加。

当网络出现超时，发送者判断为发生了网络拥塞，调整门限ssthresh=cwnd/2，同时设置拥塞窗口cwnd=1，进入慢开始阶段

快重传:发送方只要一连接收到了3个重复确认，应当立即进行重传，这样就不会出现超时

快恢复：当发送方一连收到了3个重复确认，不启动慢开始，而是调整门限ssthresh=cwnd/2,同时设置cwnd=ssthresh,并开始执行拥塞避免算法

AIMD算法：

加法增大AI：指拥塞避免阶段，拥塞窗口是按线性规律增大的

乘法减小MD：指一旦出现超时或3个重复的确认，就要把门限设置为当前拥塞窗口的一般，并大大减小拥塞窗口的数值

发送窗口的上限值 = Min[接收方窗口,拥塞窗口]

3.主动队列管理AQM

尾步丢弃策略：路由器的分组丢弃策略，指路由器的队列已满时，后续到达的所有分组都将被丢弃

全局同步现象：由于路由器的尾步丢弃，会导致发送方出现超时重传，而很多TCP连接的报文段是复用的，这样导致很多条TCP连接在同一时间进入慢开始阶段

主动队列管理AQM:为了避免发生全局同步现象，应当在队列达到某个警戒值时主动丢弃后续到达的分组。

AQM实现方法：随机早期检测RED

5.8 TCP的传输连接管理

TCP连接有三个阶段：

• 连接建立
• 数据传送
• 连接释放

客户：主动发起连接建立的应用进程

服务器：被动等待连接建立的应用进程

1. TCP的连接建立（三次握手）

第一次报文握手:

客户端A创建传输控制模块TCB，向服务器B发送连接请求报文段

报文段:SYN=1,seq=x,

第二次报文握手

服务器B收到报文请求报文后,如同一建立连接,向A发送确认

报文段:SYN=1,ACK=1,seq=y,ack=x+1

第三次报文握手

客户端A收到服务器B的确认后,还要向服务器B发送确认.A已建立连接,当B收到确认后也建立连接

报文段:ACK=1,ack=y+1,seq=x+1

A最后再发送一次确认的目的:防止已失效的连接请求报文段突然又传送到了B

2.TCP的连接释放

第一次报文握手

客户端A发送一个连接关闭请求,并停止发送数据,A进入终止等待状态FIN-WAIT-1

报文段:FIN=1,seq=u

第二次报文握手

服务器B收到A的请求后发出确认,进入关闭等待状态CLOSE-WAIT,此时A到B的连接已经释放了,但是B到A的连接没有释放

A收到确认后就进入终止等待状态FIN-WAIT-2

报文段:ACK=1,seq=v,ack=u+1

第三次报文握手

若B已经没有要发送的数据了,向A发送连接释放报文

报文段:FIN=1,ACK=1,seq=w,ack=u+1

第四次报文握手

A在收到B的连接释放报文后,向B发送确认,然后进入时间等待状态TIME-WAIT,等待时间等待计时器设置的2MSL才进入连接关闭状态CLOSE，这个MSL叫最长报文段寿命,B收到确认后进入CLOSE状态

报文段:ACK=1,seq=u+1,ack=w+1

时间等待的目的 :1.防止A的确认丢失 2.防止出现已失效的连接请求报文段

3.有限状态机

可靠传输协议rdt(好像这个谢希仁版没讲,但是学校发的课本有,考试要考…)

rdt 1.0

基于理想情况下的协议,假设所有信道都是可靠的

rdt 2.0

在1.0的基础上解决了比特位翻转,三种机制:

• 错误检测
• 接收者反馈接收信息(正确ACK错误NAK)
• 重传机制

rdt 2.1

在2.0的基础上解决了ACK和NAK发生比特位翻转的问题

在数据包上添加0,1编号,同样在ACK和NAK添加0,1字段

rdt 2.2

在2.1的基础做了改善,丢弃了NAK,只需采用ACK,在ACK的信息上加上序号

rdt 3.0

在2.2的基础上处理了数据包丢失的情况,增加了计时器机制,超时重传

需要markdown的自取：计算机网络运输层知识点整理.md