计网第五章
5.1 运输层协议概述
5.1.1 进程之间的通信
运输层：面向通信部分的最高层，用户功能中的最低层
为应用层进程之间的通信提供服务
屏蔽作用：运输层向高层用户屏蔽了下面网络核心的细节（网络拓扑、所采用的路由选择协议等），使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道
可靠信道：使用面向连接的协议，TCP
不可靠信道：使用无连接的协议，UDP
5.1.2 运输层的两个主要协议
用户数据报协议UDP
传输控制协议TCP
运输协议数据单元
两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元TPDU
TCP传送的数据单位协议是TCP报文段
UDP传送的数据单位协议是UDP报文或用户数据报
区别
UDP：
传送数据前不需要先建立连接
收到UDP报后不需要给出任何确认
不提供可靠交付，但是一种最有效的工作方式
TCP：
提供可靠的、面向连接的运输服务
不提供广播或多播服务
开销较多
使用UDP和TCP的典型应用和应用层协议
点击图片可查看完整电子表格
5.1.3 运输层的端口
复用：应用进程都可以通过运输层再传送到IP层
分用：运输层从IP层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程
问题：
进程的创建和撤销都是动态的，因此发送方几乎无法识别其他机器上的进程
我们需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个
有时我们会改换接收报文的进程，但并不需要通知所有的发送方
在运输层使用协议端口号，把端口设为通信的抽象终点
软件端口与硬件端口
软件端口：
协议栈层间的抽象的协议端口
是应用层各种协议进程与运输实体进行层间交互的地点
不同系统实现端口的方法可以不同
硬件端口：
不同硬件设备进行交互的接口
TCP/IP运输层端口标志
端口用一个16位端口号进行标志，允许有65535个不同端口号
端口号只具有本地意义，只是为了标志本计算机应用层中的各进程
5.2 用户数据报协议UDP
5.2.1 UDP概述
UDP只在IP的数据报服务之上增加了一些功能：
复用和分用
差错检测
主要特点
无连接，发送数据之前不需要建立连接
使用尽最大努力交付，不保证可靠交付
面向报文，UDP一次传送和交付一个完整的报文
没有拥塞控制，网络出现的拥塞不会使源主机的发送速率降低，适合多媒体通信的要求
支持一对一、一对多、多对一、多对多等交互通信
首部开销小，8字节
简单方便、但不可靠
UDP是面向报文的
发送方UDP对应用层交下来的报文，既不合并，也不拆分，按照原样发送
接收方UDP对IP交上来的UDP用户数据报，去除首部后就原封不动地交付上层应用进程，一次交付一个完整地报文
应用程序必须选择合适大小的报文：
太长，IP层传送时要分片，降低IP层效率
太短，使IP数据报首部相对长度太大，降低IP层效率
UDP通信和端口后的关系
复用：将 UDP 用户数据报组装成不同的 IP 数据报，发送到互联网。
分用：根据 UDP 用户数据报首部中的目的端口号，将数据报分别传送到相应的端口，以便应用进程到端口读取数据。
5.2.2 UDP的首部格式
首部8字节，4个字段，每个字段2个字节
源端口：源端口号，对方回信时选用，不需要回复时（单纯广播）可用全0
目的端口：目的端口号，终点交付报文时必须使用
长度：UDP用户数据报的长度，最小值8，单位为1字节
检验和：检测UDP用户数据报在传输中是否有差错
UDP基于端口的分用
接收方UDP根据首部中的目的端口号，把报文通过相应的端口上交给应用进程
如果接收方UDP发现收到的报文中目的端口号不正确，丢弃改报文，由ICMP发送端口不可达差错报文给发送方
计算检验和时需要添加12字节的伪首部
5.3 传输控制协议TCP概述
5.3.1 TCP最主要的特点
TCP是面向连接的运输层协议，在无连接的、不可靠IP网络服务基础之上提供可靠交付的服务，为此，在IP的数据报服务基础之上，增加了保证可靠性的一系列措施
特点：
TCP是面向连接的运输层协议
每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的
TCP提供可靠交付的服务
TCP提供全双工通信
面向字节流：
TCP中的流指的是流入或流出进程的字节序列
面向字节流：虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序交下来的数据看成仅仅一连串无结构的字节流
TCP面向流的概念
TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应的大小关系
但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样
5.3.2 TCP的连接
TCP把连接作为最基本的抽象
连接的端点：套接字或插口
套接字socket=（ip地址：端口号）
每一条TCP连接唯一地被通信两端地两个套接字所确定：
1 | TCP连接:: = socket_{1},socket_{2} |
TCP连接就是协议软件所提供的一种抽象
TCP连接的端点是抽象的套接字
同一个ip地址可以有多个不同的TCP连接
同一个端口号也可以出现在多个不同的TCP连接中
Socket
应用编程接口API称为socket API简称socket
Socket API中使用的一个函数名叫socket
调用socket函数的端点称为socket
调用socket函数时其返回值称为socket，描述符，可简称为socket
在操作系统内核中连网协议Berkeley实现，称为socket实现
5.4 可靠传输的工作原理
理想的传输条件：
传输信道不产生差错；
不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据
在理想传输条件下，不需要采取任何措施就能实现可靠传输
5.4.1 停止等待协议
每发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组
全双工通信的双方既是发送方也是接收方
无差错情况
出现差错
两种差错：
B接收M时检测出了差错直接丢弃
M在传输过程中丢失
方法：
超时重传：
A为每一个已发送的分组设置超时计时器
只要在超时计时器到期之前收到了相应确认，就撤销计时器，继续发送
若规定时间没有收到确认，就认为分组错误或丢失，重发分组
确认丢失
B发送的对M的确认丢失，A在超时计时器到期后重传M
B正确收到了重传的分组M：
丢弃重复分组M
向A发送确认
确认迟到
B对分组M的确认迟到了，A在超时计时器到期后重传M
B收到重复分组M，丢弃后重新发送确认
A收到重复确认，对重复确认进行丢弃
信道利用率
1 | U = T_{D} \div (T_{D} + RTT + T_{ACC}) |
RTT>>T_D，简单但是利用率低
要点
停止等待，发送方每次只发送一个分组，收到确认后再发生
暂存：发送完一个分组后，发送方必须暂存已发送分组的副本，以备重发
编号，对发送的每个分组和确认都进行编号
超时重传，发送方为发送的每个分组都设置超时计时器
超时计时器重传时间应当比数据在分组传输的平均往返时间更长
简单但信道利用率低
5.4.2 连续ARQ协议
发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可以被连续发送出去，而不需要等待对方确认
发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置
累计确认：接收方对按序到达的最后一个分组发送确认，表示到这个分组为止的所有分组都正确收到了（后退N帧协议使用）
选择-重传：发送、接收窗口>1
5.5 TCP报文段的首部格式
TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段
一个TCP报文段分为首部和数据两部分，TCP全部功能都体现在它首部中各字段的作用
TCP报文段首部前20字节固定，后面4n字节根据需要增加
源端口、目的端口：2字节
序号：4字节，TCP连接中传送的数据流中的每一个字节都有一个序号，序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
确认号：4字节，期望收到对方下一个报文段的数据的第一个字节的序号
数据偏移（首部长度）：4位，指出TCP报文段的数据起始处距离TCP报文段的起始处有多远，单位为4字节
保留：6位，置零
紧急URG：1位，当URG=1时表明紧急指针字段有效，告诉系统此报文段中有紧急数据，应尽快传送
ACK：1位，ACK=1时确认号字段有效
PSH：1位，控制位，接收TCP收到PSH=1的报文段后，尽快交付接收应用进程，不需要等到整个缓存填满
复位RST：1位，控制位，RST=1时表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输连接
SYN：1位，同步控制位，SYN=1时表示连接请求或接受，三次握手
终止FIN：1位，控制位，FIN=1表明此报文段的发送端数据已发送完毕，请求释放连接
窗口：2字节，从本报文段首部的确认号算起，接收方目前允许对方发送的数据量
检验和：2字节，检验和字段检验首部和数据两部分，计算检验和时在TCP报文段前加上12字节伪首部
紧急指针：2字节，URG=1时，指出本报文段中紧急数据的字节数，指出了紧急数据的末尾在报文段中的位置
选项：长度可变，最长40字节
可选MSS：数据字段最大长度MSS个字节
窗口扩大：3字节，一个字节表示移位值S，新窗口位数（16+S），移位值最大为14
时间戳：10字节，时间戳值字段4字节和时间戳回送回答字段4字节，用来计算往返时间RTT，防止序号绕回PAWS
填充：TCP首部为4字节整数倍
有关数据报长度限制
MSS不能太小：
网络利用率降低
如仅1字节，利用率不会超过1/41
不能太大：
开销增大
IP层传输时要分片，终点要装配
分片传输出错时，要整个分组
尽可能大：
IP层传输不分片
默认=536字节
5.6 TCP可靠传输的实现
5.6.1 以字节为单位的滑动窗口
TCP使用流水线传输和滑动窗口协议实现高效、可靠的传输
TCP滑动窗口以字节为单位
发送窗口：在没有收到确认的情况下，发送方可连续把窗口内数据全部发送，已经发送的数据在未收到确认前必须暂时保留，以便超时重传
接受窗口：只允许接受落入窗口内的数据
发送缓存暂时存放：
发送应用程序传送给发送方TCP准备发送的数据
TCP已发送但未收到确认的数据
接受缓存暂时存放：
按序到达、但未被接收应用程序读取的数据
未按序到达的数据
规定
发送窗口根据接收窗口设置，同一时刻发送窗口不总是和接收窗口一样大（时间滞后）
TCP标准没有规定对不按序到达的数据如何处理，通常先临时存放在接收窗口中，等字节流所缺少的字节收到后，再按序交付
TCP要求接收方必须有累计确认的功能，接收方可以再合适时候发送确认，也可以在自己有数据要发送时把确认信息顺便带上。接收方不应过分推迟发送确认，否则会导致发送方不必要重传，捎带确认实际上不经常发生
5.6.2 超时重传时间的选择
太短：引起不必要重传，网络负荷增大
太长：网络空闲时间增大，降低传输效率
加权平均往返时间RTTs
又称平滑的往返时间
1 | RTT_{s} = (1 - \alpha) \times (旧的RTT_{s}) + \alpha \times (新的RTT样本) |
1 | \alpha 推荐值为1/8，即0.125 |
超时重传时间RTO
RTO应略大于RTTs
1 | RTO = RTT_{s} + 4 \times RTT_{D} |
RTT_D是RTT偏差的加权平均值
1 | RTT_{D} = (1 - \beta) \times (旧的RTT_{D}) + \beta \times |RTT_{s} - 新的RTT样本| |
1 | \beta 推荐值为1/4，即0.25 |
Karn算法
超时重传报文段后，如何判断确认报文段是对原来报文段的确认，还是重传报文的确认
Karn算法：在计算平均往返时间RTT时，只要报文段重传，就不采用其往返时间样本
当报文段时延突然增大，原来得出的重传时间内不会收到确认报文段，于是重传，但根据Karn，不更新超时重传时间，造成很多不必要重传
修正：每重传一次RTO增大一次，一般变2倍
5.6.3 选择确认SACK
收到的报文段无差错，只是未按照序号，中间缺少一些序号的数据，只传送缺少的数据而不重传已经正确到达接收方的数据
使用选择确认：建立TCP连接时在TCP首部选项加上允许SACK选项，双方必须事先商定好，原首部中确认号用法不变，只是在TCP首部中增加了SACK选项，以便报告收到的不连续的字节块的边界
5.7 TCP的流量控制
5.7.1 利用滑动窗口实现流量控制
流量控制：让发送方的发送速率不要太快，使接收方来得及接收
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方地流量控制
利用可变窗口进行流量控制
可能发生死锁：rwnd=0后rwnd=400的确认报文丢失
持续计时器：只要TCP连接的一方收到对方的零窗口通知就启动该持续计时器
若持续计时器设置时间到期，就发送一个零窗口探测报文段，对方在确认这个探测报文段时给出当前窗口值
若窗口值为0，继续设置新的持续计时器
若不是0就可以打破死锁
5.7.2 TCP的传输效率
控制TCP发送报文段的时机：三种机制
TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中存放的数据达到MSS字节时，就组装成一个TCP报文段发送
由发送方的应用进程指明要求发送的报文段，TCP支持的推送操作
发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段发送出去
糊涂窗口综合征
每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象（首部占大头）
使用Nagle算法
接收方糊涂窗口综合征：接收方每次仅读取一个字节
让接收方等待一段时间，使接收缓存已有足够空间容纳一个很长的报文段，或者等到接收缓存已有一半空闲再发送确认报文
5.8 TCP的拥塞控制
拥塞控制的一般原理
在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降，这种现象称为拥塞
原因：
节点缓存容量太小
链路容量不足
处理机处理速率太慢
拥塞本身会进一步加剧拥塞
拥塞控制与流量控制的区别
拥塞控制：
防止过多的数据注入到网络中，避免网络中的路由器或链路过载
是一个全局性的过程，涉及到所有主机、路由器，以及与降低网络传输性能有关的所有因素
流量控制：
抑制发送端发送数据的速率，以使接收端来得及接收
点对点通信量的控制，是个端到端的问题
拥塞控制的一般原理
前提：网络能够承受现有的网络负荷
拥塞控制是一个动态问题，很难设计
分组的丢失是网络发生拥塞的征兆，许多情况下，拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因
开环控制和闭环控制
开环控制：
在设计网络时，事先考虑周全，力求工作时不发生拥塞
思路：力争避免发生拥塞
但一旦整个系统运行起来，就不再中途更改
闭环控制：
基于反馈环路的概念
根据网络当前运行状态采取相应控制措施
思路：在发生拥塞后，采取措施进行控制，消除拥塞
闭环控制措施
监测：监测网络系统，检测拥塞在何时何处发生
由于缺少缓存空间而被丢弃的分组百分数
平均队列的长度
超时重传的分组数
平均分组时延
分组时延的标准差等等
传送：将拥塞发生的信息传送到可采取行动的地方
传送到产生分组的源站
在路由器转发的分组中保留一个比特或字段，用该比特或字段的值表示网络有无拥塞
周期性地发出探测分组等
调整：调整网络系统的运行以解决出现的问题
过于频繁会使系统产生不稳定的振荡
过于迟缓实用价值不高
5.8.2 TCP的拥塞控制方法
TCP采用基于滑动窗口的方法进行拥塞控制，属于闭环控制方法
TCP发送方维持一个拥塞窗口cwnd
拥塞窗口的大小取决于网络的拥塞程度，且是动态变化的
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量
发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况
1 | realwindow = min(rwnd,cwnd) |
控制cwnd原则
只要网络没有出现拥塞，拥塞窗口就可以再大些，以便把更多分组发送出去，提高网络利用率
只要网络出现拥塞或有可能出现，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，缓解网络出现的拥塞
发送方判断拥塞的方法：隐式反馈
超时重传计时器超时：网络已经出现了拥塞
收到3个重复确认：预示网络可能会出现拥塞
TCP拥塞控制算法
慢开始
拥塞避免
快重传
快恢复
传输轮次：一个传输轮次所经历的时间其实就是往返时间RTT，传输轮次强调把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认
慢开始
目的：探测网络的负载能力或拥塞程度
由小到大逐渐增大注入到网络中的数据字节（cwnd）
cwnd初始值：1至2个MSS或2至4个MSS
发送方每收到一个对新报文段的确认（重传的不算在内）就使cwnd加一
每一个RTT传送报文段翻倍（无rwnd限制），所以cwnd翻倍
ssthresh：慢开始门限，防止拥塞窗口增长过大引起网络拥塞
当cwnd<ssthresh使用慢开始算法
cwnd>ssthresh使用拥塞避免算法
拥塞避免
目的：让拥塞窗口cwnd缓慢地增大，避免出现拥塞
拥塞窗口cwnd增大：每经过一个往返时间RTT发送方cwnd+1
有加法增大特点，使拥塞窗口按线性规律缓慢增长
拥塞避免并非完全避免拥塞，而是让cwnd增长缓慢，不容易出现拥塞
出现拥塞
重传计时器超时——标志拥塞已经出现，立即执行：
ssthresh=max（cwnd/2，2）
cwnd=1
执行慢开始
目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕
快重传算法
目的：让发送方尽早知道发生了个别报文段的丢失
发送方只要连续收到三个重复的确认（一共四个），就立即进行重传
后续的数据包不断到达接收方，触发了接收方“每收到一个乱序包就必须重申一次期待序号”的机制
使用快重传可使整个网络吞吐量提高约20%
快重传算法要求接收方立即发送确认，即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认
快恢复算法
当发送端收到连续三个重复确认时，不执行慢开始算法，而是执行快恢复算法：
ssthresh=cwnd/2
乘法减小MD拥塞窗口，新cwnd=ssthresh
执行拥塞避免算法
5.8.3 主动队列管理AQM
TCP拥塞控制和网络层采取的策略有密切联系
若路由器对某些分组的处理时间特别长，可能引起发送方TCP超时，对这些报文段重传
重传会使TCP连接的发送端认为在网络中发送了拥塞，但实际上网络并没有发生拥塞
对TCP拥塞控制影响最大的就是路由器的分组丢弃策略
先进先出FIFO处理规则
尾部丢弃策略：当队列已满时，以后到达的所有分组将都被丢弃
路由器的尾部丢弃往往会导致一连串的丢失，这就使发送方出现超时重传，使TCP进入拥塞控制的慢开始状态，TCP发送方突然把发送速率降到很小的值
这会导致所有到达的分组都被丢弃，不论它们属于哪个TCP连接，多个TCP连接同时进入慢开始状态，发生全局同步
主动队列管理AQM
不等路由器的队列长度达到最大值时不得不丢弃，而是在队列长度到达警惕值时主动丢弃到达的分组
随机早期检测RED
队列长度最小门限THmin
队列长度最大门限THmax
RED对每一个到达的分组先计算平均队列长度Lav
若平均队列长度小于THmin，则加入队列
若大于THmax，则丢弃
之间，则按照概率p将分组丢弃
5.9 TCP的运输连接管理
TCP是面向连接的协议
连接三个阶段：
连接建立
数据传送
连接释放
TCP的连接管理就是使TCP连接的建立和释放都能正常进行
TCP连接的建立采用客户服务器的方式
要使每一方能确知对方的存在
允许双方协商一些参数
能够对运输实体资源进行分配
5.9.1 TCP连接的建立
三次握手：客户和服务器之间交换三个TCP报文段，防止已失效的连接请求报文段突然又传送到因而产生TCP连接建立错误
B的TCP服务器进程先创建传输控制块TCB，准备接收客户进程的连接请求
A的TCP向B主动发出连接请求报文段，其首部中的同步位SYN=1，选择序号seq=x，表明传输数据时的第一个数据字节序号是x（SYN报文段SYN=1的不能携带数据，但要消耗一个序号）
B的TCP收到连接请求报文段后，如同意则发回确认，确认报文段中SYN=1，ACK=1，确认号ack=x+1，字节选择序号seq=y（同样不携带数据，消耗一个序号）
A收到B的确认后向B给出确认ACK=1，ack=y+1，A的TCP通知上层应用进程，连接已经建立（此报文段可携带数据，如果不携带则不消耗序号）
5.9.2 TCP连接释放
四次挥手：通信双方都可释放连接
A的应用进程先向其TCP发出连接释放报文段，并停止发送数据，主动关闭TCP连接，FIN=1，seq=u等待B确认（可以携带数据，但不携带数据也消耗一个序号）
B发出确认ACK=1，确认号ack=u+1（或+uu+1），seq=v（可携带数据），TCP服务器进程通知高层应用进程，A到B的连接释放，TCP处于半关闭状态
若B没有向A发送的数据，其应用进程通知TCP释放连接，FIN=1，ACK=1，确认号=u+1（与B之前确认号一样），seq=w
A收到连接释放报文段后，发出确认ACK=1，ack=w+1（或+ww+1），seq=u+1（与B之前确认号一样）
必须等待2MSL时间：
保证发送的最后一个ACK报文段能够到达B
防止已失效的连接请求报文段出现在本连接中
保活计时器：
防止在TCP连接中出现长时期空闲
通常设置为2小时
若服务器过2小时还未收到客户信息，就发送探测报文段
若发送了10个探测报文段还没有相应就假定客户出故障，终止连接
