导图社区 计算机网络第五章运输层
- 422
- 3
- 0
- 举报
计算机网络第五章运输层
计算机网络第五章 运输层，比较详尽。伪首部格式与UDP也一样，但应把伪首部的第四个字段中的17改为6（TCP的协议号为6），把第五个字段中的UDP长度改为TCP长度。
编辑于2022-01-23 13:57:00- 运输层
- 相似推荐
- 大纲
计算机网络第五章 运输层
运输层协议概述
进程之间的通信
运输层向它上面的应用层提供通信服务，属于面向通信服务的最高层，同时是用户功能层的最底层
明确概念
端对端通信：通信的两端发起和接收者应当是两个主机之间的应用进程
逻辑通信：好像是直接是从不同主机同层之间相互通信，但实质并非如此
运输层和网络层区别
网络层为主机之间的通信提供服务
运输层则在网络层的基础上为应用进程提供服务
运输层的功能
复用
发送方不同的应用进程都可以使用同一个运输层协议传送数据
分用
接收方的运输层在剥去报文的首部后能够把这些数据正确地交付给目的应用进程
运输层提供应用进程间的逻辑通信
运输层要对收到的报文进行差错检测
向用户屏蔽下面网络核心的细节，使之看起来像运输层实体之间有一条端对端逻辑通信信道
不同的协议
UDP
提供不可靠逻辑信道
TCP
提供全双工可靠逻辑信道
运输层的两个主要协议
用户数据报协议UDP
传输协议数据单元——UDP数据包
在传输前不需要建立连接
远地主机在收到UDP包后不需要给出确认
多数情况下很有效
传输控制协议TCP
传输协议数据单元——TCP报文段
传输数据前必须先建立连接，传输结束后要释放连接
TCP不提供广播或多播服务
TCP提供可靠的，面向连接的运输服务， 但也要为此增加许多开销
确认
流量控制
计时器
连接管理
运输层的端口
使用统一的方法让数据信息传递给TCP/IP协议，且这种方法应该与特定的操作系统无关
协议端口
应用层和运输层之间的“门”
每个端口使用一个端口号的正整数来标志
比较
在协议栈层之间的抽象协议端口是软件端口，软件端口是应用层的各种协议进程与运输实体进行层间交互的地点
硬件端口是不同硬件设备进行交互的接口
用一个16位端口号来标志一个端口，只具有本地意义，不同主机相同端口号是没有关联的
两个计算机相互通信，不仅要知道对方的IP地址（找到计算机），还要知道对方的端口号（找到计算机中对应的进程）
运输层端口号分类
服务器使用的端口号
熟知端口号/全球通用端口号
数值为0~1023
全球所有的应用程序都使用该端口号，不能改变
例
DNS：53
FTP：21
HTTP：80
HTTPS：443
登记端口号
数值为1024~49151
为没有熟知端口号的应用程序使用的，要使用这类端口号必须要在IANA按照规定的手续登记，防止重复
客户端使用端口号
数值为49152~65535
这类端口号仅在客户进程运行时才动态选择，也称短暂端口号，是临时的
用户数据包协议UDP
UDP概述
UDP仅在IP的数据包服务上增加了很少一点功能，就是复用、分用和差错检测
主要特点
UDP是无连接的
发送数据前不需要建立连接
UDP使用尽最大努力交付
不保证可靠交付
UDP是面向报文的
发送方UDP对应用程序交下来的报文，在添加首部后向下交付IP层
UDP一次交付一个完整的报文（若报文太长则会降低IP层效率
UDP没有拥塞控制
网络出现拥塞不会使源主机的发送速率降低
应用：IP电话、实时视频等
可能会引起网络产生严重的拥塞问题
UDP支持一对一、一对多、多对一和多对多的交互通信
UDP首部开销小
只有8个字节，比TCP20字节短
UDP的首部格式
两个字段
首部字段
仅有8个字节，由四个字段组成，每段2个字节
源端口
源端口号，在需要对方回信时选用，不需要时全为0
目的端口
目的端口号，在终点交付报文时必须使用
长度
UDP用户数据报的长度，最小值为8（仅有首部
检验和
检验UDP用户数据报在传输中是否有错，有错就丢弃
计算检验和时要在UDP用户数据包之前增加12字节的伪首部
伪首部
仅仅用来计算检验和
临时添加
UDP检验和是把首部和数据部分一起检验
数据字段
传输控制协议TCP概述
TCP最主要特点
TCP是面向连接的运输层协议
使用TCP前必须先建立TCP连接，使用完后必须释放TCP连接
每条TCP连接只能有两个端点，每条TCP连接是点对点的连接
TCP提供可靠交付的服务
通过TCP连接传送的服务，无差错、不丢失、不重复并且按序到达
TCP提供全双工通信
TCP允许通信双方的应用进程在任何时候都能发送数据
面向字节流
应用程序和TCP交互是一次一个数据块，但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流
虚连接，逻辑链接，并非真正的实连接
TCP的连接
TCP把连接作为最基本的抽象
端点
套接字/插口（socket）
即端口号拼接带IP地址即构成套接字
表示
套接字=（IP地址：端口号）
例：192.3.4.5：80
每一条TCP连接唯一地被通信两端的两个端点所确定
TCP连接::={socket1,socket2}={(IP1:port1),(IP2:port2)}
socket可表示不同意思
允许应用程序访问联网协议的应用编程接口API，称为socket API
在socket API中使用的一个函数名也叫socket
调用socket函数的端点称为socket，如“创建一个数据包socket”
调用socket函数时，返回值称为socket描述符，简称为socket
在操作系统内核中联网协议的Berkeley实现简称为socket实现
注意加以区分
可靠传输的工作原理
总概
理想传输特点
传输信道不产生差错
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据
但实际网络不具备这些条件，所以需要人为干预
停止等待协议
无差错情况
发送分组后收到确认后再发下一个分组
出现差错
出现差错后就丢弃该分组，并不返回信息，待到超过一定时间没有收到确认信息后重新传输该分组——超时重传
在发送一个分组后设置一个超时计时器，若超时计时器到时之前收到了对方的确认，就撤销已设置的超时计时器
注意
发送端在发送完一个分组后必须暂时先保留已发送的分组副本，只有收到相应的确认后才能清除暂时保留的分组副本
分组和确认分组都必须进行编号，这样才能明确所收到确认的分组是哪一个
超时计时器设置的重传时间应该比数据在分组传输的平均往返时间更长一些，这样才能保证在通信效率和节省网络资源之间找到平衡
实际上网络时延和经过网络都是不确定的，所以需要选择出合适的重传时间
确认丢失和确认迟到
确认丢失
导致发送端重新发送分组
接收端丢弃旧的重复的分组
接收端再次向发送端发送确认
确认迟到
发送端收到延迟很久的确认
导致发送端重新发送分组
发送端收下这个确认后就丢弃
接受端丢弃旧的分组，接收新的分组
使用上述协议可以在不可靠的阐述网络上实现可靠的通信，这样可靠传输协议常常称为自动重传请求ARQ
信道利用率
停止等待协议的信道利用率低
信道利用率=发送分组时间/(发送分组时间+往返时间+发送确认时间)
为提高信道利用率，可以采用流水线传输，不必每发完一个分组就停顿下来等待对方的确认，这样可以获得很高的信道利用率
连续ARQ协议
发送窗口
发送窗口包含n个分组，这n个分组都可以连续发出
累计确认
接收方不必对收到的分组逐个发送，而是对按序到达的最后一个分组发送确认，表示到这个分组为止的所有分组都已经正确地收到了
优点
容易实现
确认丢失也不必重传
缺点
不能向发送方及时反映接收方已经正确收到所有分组的信息
通信线路质量不好时连续ARQ会带来负面影响
TCP报文段的首部格式
TCP报文段首部的前20字节是固定的
各字段及意义
源端口和目的端口
各占2字节，分别写入源端口号和目的端口号
序号
占4字节，范围是0~2的32次方-1
序号加到2的32次方-1后，又会回到0，为mod 2的32次方
指的是本报文段所发送的数据的第一个字节的序号
理解
相当于在一个分组数据字节内每个字节都标号，TCP序号就是表示 其分段后的每个分段的第一个字节标号
确认号
占4字节，是期望收到对方下一个报文段的第一个数据字节的序号
若确认号为N，表明N-1个字节都已经正确的收到了
例：若发来TCP分组的序号是201，数据长度100，则确认号应该是301
数据偏移
占4位，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远
其实指的是TCP报文段的首部长度
数据偏移最大60字节，即首部长度最大字节，即选项长度不能超过40字节
保留
占6位
目前均为0，保留
6个控制位
紧急URG
当URG=1时有效，表明文段中有紧急数据，设置最高优先级传送，TCP会将其插入到本报文段数据的最前面，需要与首部中紧急指针配合使用
确认ACK
ACK=1时确认字段有效
在建立TCP连接后所有传送的报文段的ACK置为1
推送PSH
两个应用进程进行交互通信时，当希望输入命令后能立即收到对方的响应，则需要把PSH=1
复位RST
当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输连接
同步SYN
在连接建立时用来同步序号
SYN=1而ACK=0时，表明是一个连接请求报文段，若对方同意连接，则在响应的报文段使用SYN=1，ACK=1
SYN=1表示一个请求连接或同意连接的报文
终止FIN
FIN=1时表明此报文段的发送方的数据已经发送完毕，并要求释放连接
窗口
占2字节，是0~2的16次方-1之间的整数
指的是发送本报文段的一方的接收窗口
窗口值作为接收方让发送方设置其发送窗口的依据
窗口字段明确指出现在允许对方发送的数据量，窗口值经常动态变化着
检验和
占2字节，检验和字段检验的范围包括首部和数据部分
与UDP检验一样，计算检验和时，要在TCP报文段前面加上12字节的伪首部
伪首部格式与UDP也一样，但应把伪首部的第四个字段中的17改为6（TCP的协议号为6），把第五个字段中的UDP长度改为TCP长度
若使用IPv6，则相应的伪首部也要改变
紧急指针
占2字节，紧急指针仅在URG=1时才有意义，指出本报文段中的紧急数据的字节数
紧急指针指出了紧急数据的末尾在报文中的位置
窗口为0时也可以发送紧急数据
选项
长度可变，最长可达40字节
填充字段仅仅是为了使整个TCP首部长度是4字节整数倍
选项种类
最大报文长度MSS
指的是每个TCP报文段中数据字段的最大长度
具体来说是 TCP报文长度-TCP首部长度
两个传送方向可以有不同的MSS值，默认是536
窗口扩大选项
时间戳
占10个字节
时间戳值（4字节
时间戳回送回答字段（4字节
作用
用来计算往返RTT
用于处理TCP序号超过2^32的情况，又称为防止序号绕回PAWS
选择确认SACK
TCP可靠传输的实现
以字节为单位的滑动窗口
发送方和接收方都有一个窗口
发送窗口的实现由三个指针P1，P2，P3控制
P1表示窗口的后沿，表示左边的已经收到确认
P2左边为已发送但未收到确认，右边是可以发送但尚未发送的窗口部分
P3表示窗口的前沿，右边禁止发送
接收窗口
接收窗口左边为已经收到的数据
接收窗口内为正在接收数据
注意
缓存空间和序号空间都是有限的，并且循环使用
发送窗口是根据接收窗口设置的，但在同一时刻发送窗口并不总是和B的接收窗口一样大，可能因为网络传送原因有一段滞后
对于不按序到达的数据如何处理，TCP标准并无明确规定，若是直接丢弃实现会简单，但会对网络资源利用不利。TCP通常是把不按序到达的数据先存起来，等前面补齐后再按序交付上层的应用进程
TCP要求接收方必须有累计确认的功能， 这样可以减小传输开销，
接收方不应该过分推迟确认，TCP规定确认推迟时间不应超过0.5s
接收方可以在合适的时候发送确认，也可以在自己有数据发送的时候把确认信息顺便捎带上。捎带确认实际上不经常发生
超时重传时间选择
问题
超时重传时间设置太短会引起很多报文段的不必要重传
超时重传时间设置太长会使网络空闲时间增大，降低传输效率
TCP采用自适应算法
实现
记录一个报文段发出的时间，以及收到相应的确认的时间，时间差就是RTT
TCP保留了RTT的一个加权平均往返时间RTTs
第一次RTTs即为第一次的RTT
以后每测一次RTT样本，则会按照公式：
新的RTTs =（1-α）x（旧的RTTs）+αx（新的RTT样本）
α取值为[0,1)，若α接近0时更新慢，α接近1时更新快
RFC6298建议α取1/8
超时计时器设置的超时重传时间RTO应略大于RTTs
RFC6298建议公式：RTO=RTTs+4xRTTd
RTTd是RTT的偏差的加权平均值
它与RTTs和新的RTT样本差有关，第一次测量时RTTd取值为测量到的RTT样本值的一半
新的RTTd=（1-β）x（旧的RTTd）+βx|RTTs-新的RTT样本|
β为小于1的系数，推荐值为0.25
往返时间的测量
Karn算法
计算加权平均RTTs时，若报文重传了，则不采用其往返时间样本，这样得出的加权平均RTTs和RTO比较准确
修正
报文段每重传一次，就把超时重传时间RTO增大一些，典型做法是增大2倍，再使用公式计算超时时间
选择确认SACK
若收到的报文无差错，只是未按序号，中间缺少一些序号的数据，能否设法只传送缺少的数据而不重传已经正确达到接收方的数据
RFC2018规定选择SACK需要在首部的选项上增加SACK选项，双方都必须商定好
指明一个边界要4字节，SACK选项2字节，所以最多能指明4个缺失的片段，（5个就42字节超出选项的长度范围）
TCP的流量控制
利用滑动窗口实现流量控制
流量控制
让发送方的发送速率不要太快，让接收方来得及接收
发送方的发送窗口不能超过接收方给出的接收窗口数值
为防止出现数据丢失而发生的锁死状态，TCP为每一个连接设有一个持续计时器，只要TCP连接的一方收到对方零窗口通知，就启动持续计时器，若持续计时器设置时间到期，就发送一个零窗口探测报文段（仅携带1字节数据），对方在确认这个探测报文段时给出现在的窗口值。
TCP 的传输速率
使用不同机制控制TCP报文段的发送时机
TCP维持一个变量，等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节就组装成一个TCP报文发出
由发送方的应用进程指明要求发送报文段，即TCP支持的推送操作
由 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（不超过MSS）
Nagle算法
发送方把第一个数据字节先发送，把后面的数据字节先缓存
当发送方收到对第一个字符的确认后，再把发送缓存里的所有数据组装成一个TCP报文发送，同时继续对后到达的数据进行缓存
只有收到前一个报文的确认后，才发送下一个报文
当到达的数据已达到发送窗口大小的一半或报文段最大长度时，立即发送一个报文段
好处
可以明显减少所用的网络带宽
有效提高网络吞吐量
糊涂窗口综合征
TCP接收方缓存已满，交互式应用一次只从接收缓存中读取1字节，然后向发送方发送确认
接着发送方又发来1字节数据，在存到接收机的发送缓存，每次发送1字节
解决问题方法
让接收方等待一段时间，或者等到接收缓存已有一半空闲时间
TCP的拥塞控制
拥塞控制一般原理
在某段时间内，若网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况叫做拥塞
∑对资源的需求>可用资源
引起网络拥塞的因素
某个节点缓存容量太小，到达该节点的分组因无存储空间暂存而不得不被丢弃，但单纯扩大缓存容量，输出链路的容量和处理机处理速度并未提高，在队列的绝大部分分组排队等待时间将大大增加，或因为超时而重传，只会造成网络资源的严重浪费
处理机处理速率太低可能引起网络的拥塞，但单纯提高速率会将瓶颈转移到其他地方
问题的实质是整个系统的各个部分不匹配，只有所有的部分平衡了，问题才能解决
拥塞常常趋于恶化
一个路由没有足够的缓存空间，则会丢弃一部分，而部分分组被丢弃时发送分组的源点会重传这一分组，或者多次重传
拥塞引起的重传不会缓解网络的拥塞，反而会加剧网络的拥塞
拥塞控制
防止过多数据注入到网络，这样可以使网络的路由器或链路不至于过载
前提
网络能够承受现有的网络负荷
区分
拥塞控制是一个全局性的过程，涉及主机、路由器以及与降低网络传输性能有关的所有因素
流量控制往往是指点对点通信的控制，是个端对端的问题
在拥塞控制算法中会对发送端发送控制报文，告诉发送端网络出了问题，必须放慢发送速率，这一点和流量控制很像
拥塞控制需要代价
要在节点之间交换信息和各种命令，以便选择控制的策略和实施控制，会产生额外的开销
有时需要将一些资源分配给个别用户单独使用，这样使得网络资源不能很好实现共享
在涉及拥塞控制时要全面衡量得失
实际网络情况
随着提供负载增大，网络吞吐量的增长速率逐渐减小，即还未达到饱和时就有一部分输入分组被丢弃
网络的吞吐量明显小于理想吞吐量时，网络进入轻度拥塞的状态
当提供的负载达到某一数值时，网络吞吐量反而随提供的负载的增大而下降，这时网络就达到了拥塞状态
当提供的负载继续增大到某一数值时，网络的吞吐量就下降到0，网络已经无法工作，这就是所谓的死锁
拥塞控制很难设计，因为拥塞是动态的问题，可能拥塞控制机制本身是引起拥塞的原因
拥塞控制方法
开环控制
在设计网络时事先将发生拥塞的有关因素考虑周到，力求网络在工作时不产生拥塞，一旦整个系统运行后，就不中途改正
闭环控制
基于反馈环路的概念
措施
检测网络系统以便检测到拥塞在何时、何处发生
把拥塞发生的信息传送到可采取行动地方
调整网络系统的运行以解决出现的问题
TCP的拥塞控制方法
慢开始和拥塞避免
也称基于窗口的拥塞控制
发送方维持一个叫做拥塞窗口cwnd的状态变量
cwnd的大小取决于网络的拥塞程度，并且动态变化
发送方让自己的发送窗口等于拥塞窗口，假定拥塞窗口小，仅考虑拥塞窗口
发送cwnd原则
只要网络没有出现拥塞，则cwnd可以更大一些，以便把更多分组发送出去，这样可以提高网络的利用效率
只要网络出现拥塞窗口或者可能出现拥塞，就把拥塞窗口减小些，减少网络注入分组数，以便缓解网络出现的拥塞
判断出现拥塞的依据
发送方在超时重传计时器启动时，就判断网络出现了拥塞
慢开始算法
当主机在已建立的TCP连接上开始发送数据时，并不清楚网络当时的负荷情况，若大量注入分组到网络可能引起网络的拥塞
较好的方法是探测，由小到大逐渐增大注入到网络的数据字节，或者说由小到大增大cwnd
新的RFC5681把初始cwnd设置为2-4个发送方最大报文段SMSS值
若SMSS>2190字节，设置cwnd=2xSMSS且不得超过两个报文段
若2190>=SMSS>1095字节，则设置cwnd=3xSMSS，且不得超过3个报文段
若SMSS<=1095字节，则设置cwnd=4xSMSS，且不得超过4个报文段
在每收到一个对新的报文段的确认后，可以把cwnd增加最多一个SMSS数值，即：cwnd每次增加量=min(N,SMSS)，N是原先未被确认，但现在被刚收到的确认报文段所确认的字节数（理想情况是2的倍数式增加）
慢开始门限ssthresh
cwnd<ssthresh，使用上述慢开始算法
cwnd>ssthresh,停止使用慢开始算法，而改用拥塞避免算法
cwnd=ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法
拥塞避免算法
目的是让拥塞窗口cwnd缓慢地增大
每经过一个往返RTT，发送方的cwnd大小加1，而不是像慢增长那样加倍增长
在拥塞避免阶段称为“加法增大”AI，表明在拥塞避免阶段，cwnd按线性规律增长，比慢开始的指数式增长缓慢得多
快重传和快恢复
一些情况
首先慢开始启动，达到门限值ssthresh后转为拥塞避免算法
察觉到网络拥塞的话立即将cwnd设为慢开始初始值，并且将ssthresh/2
若在拥塞避免阶段有报文段丢失，而非网络拥塞， 则接收方应该发送三个重复确认，表明网络未拥塞
乘法减小MD
出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗口的一半，并且大大减少cwnd的值
与前面的加法增大AI，合称AIMD算法
此时执行快重传，快恢复算法，cwnd/2, ssthresh/2
接收方窗口又称通知窗口，发送方的发送窗口一定不能超过对方给出的接收方窗口值rwnd
主动队列管理AQM
尾部丢弃策略
路由器遵循先进先出策略FIFO
后面超过路由器缓存的分组都将被丢弃
全局同步
当发生路由的尾部丢弃则会影响经过它的多条TCP线路，使得许多TCP连接在同一时间突然进入慢开始状态
QAM原理
不应等到路由器队列到达最大值再丢弃分组，而是应当在队列长度达到某个界限就主动丢弃分组，这样可以提醒发送方放慢发送速率，因而有可能使得网络拥塞减轻，甚至不出现拥塞
实现方法
随即早期检测RED
需要路由维持两个参数，队列长度最小门限和最大门限
每当分组到达时，按照算法计算当前的平均队列长度
平均队列<最小门限，则把新到达的分组放入队列进行排队
平均队列>最大门限，则把新到达的分组丢弃
若平均队列在最大门限和最小门限之间，则按照某一概率p把新到达的分组丢弃
检测到网络拥塞的早期征兆时，就以概率p把新到达的分组丢弃，让拥塞控制只在个别TCP上进行，避免发生全局性的拥塞控制
如今RED使用效果不理想，此方面还没有一种算法成为IETF标准
TCP的运输连接管理
总概
运输连接三阶段
连接建立
数据传送
连接释放
客户
主动发起连接建立的应用进程
服务器
被动等待连接建立的应用进程
三个问题
使得连接的双方知道对方存在
要允许协商一些参数
能够对运输实体资源进行分配
TCP连接建立
TCP连接建立叫做握手，需要在客户和服务器之间交换3个TCP报文段
TCP规定
SYN报文段不能携带数据，但要消耗一个序号
ACK报文段可以携带数据，如果不携带数据则不消耗序号
（三报文握手）流程
服务器被动打开连接
服务器打开后进程先创建传输控制块TCB，转为LISTEN状态准备接收用户的连接请求
客户主动打开连接
首先创建传输控制块TCB
在打算建立TCP连接时，向服务器发出连接请求报文段，此时首部同步位SYN=1，同时选择一个初始序号seq=x
若服务器收到连接请求报文段后，若同意连接，则发送确认，确认报文段中SYN=1，ACK=1，确认号是ack=x+1，同时为自己选择一个初始序号seq=y
TCP客户收到服务器的确认后，还需向B给出确认，ACK=1，确认号ack=y+1而自己的序号seq=x+1
注意：前两个报文不能携带数据，但要消耗2个序号，后一个报文携带数据会消耗一个序号，如果不携带则不消耗序号
TCP连接的释放
四报文握手流程
客户A主动关闭，发送FIN=1，seq=u（u为上一个数据段标号加1），进入FIN-WAIT-1状态，等待服务器B确认
B收到释放连接报文段后即发送确认，确认号ack=u+1，而这个报文段seq=v（v为B发送最后一个数据段标号+1），然后B进入CLOSE-WAIT状态，并通知高层应用进程，释放连接，此时TCP处于半关闭状态
A收到B的确认后进入FIN-WAIT-2状态，等待B发出的连接释放报文段
若B没有要向A发送的数据，则应用进程会通知TCP释放连接，B发出FIN=1，seq=w，ack=u+1（重复确认上次已发送的确认号），B进入LAST-ACK状态
A收到B的连接释放报文段后，必须对此发送确认，ACK=1，seq=u+1,ack=w+1，然后进入TIME-WAIT状态（经过时间等待计时器经过2MSL后A才进入CLOSE状态）
最长报文段寿命MSL
RFC793建议为2分钟
A撤销相应的TCB后，结束此次TCP连接
2MSL原因
保证A发送的最后一个ACK报文段可以到达B
防止已失效的连接请求报文段出现在本连接中
保活计时器
若客户端出现故障，在2h后服务器没有收到数据，则会75s发送一次探测报文段，发送10次没有反应则会认为客户端出现故障，关闭该连接
TCP有限状态机