计算机通信网课程自学笔记
前言
本人选择并阅读的参考书为《计算机网络——自顶向下方法第七版》,因此本人将尝试以书中的顺序来梳理自己的学习笔记。同时本人还借鉴了一些课程课件中的知识内容,也将一并与书本内容结合进行归纳。
运输层
- 将网络层的在两个端系统之间的交付服务扩展到运行在两个不同端系统上的应用之间的交付服务
3.1 概述和运输层服务
- 运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信
- 在发送端,运输层将从发送应用程序进程接收到的报文转换成运输层报文段
3.1.1运输层和网络层的关系
- 运输层协议只工作在端系统中。在端系统中,运输层协议将来自应用进程的报文移动到网络边缘(即网络层),反过来也是一样,但是对有关这些报文在网络核心如何移动并不作任何规定
- 运输协议能够提供的服务常常受制于底层网络层协议的服务模型。如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话,运输层协议也就无法为进程之间发送的应用程序提供时延或带宽保证
3.1.2因特网运输层概述
- 网际协议(IP)为主机之间提供了逻辑通信,其服务模型是尽力而为交付服务,被称为不可靠服务
- UDP和TCP最基本的责任是,将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程之间的交付服务。
- 将主机间交付扩展到进程间交付被称为运输层的多路复用与多路分解
- UDP和TCP还可以通过其在报文段首部包括差错检查字段而提供完整性检查
3.2 多路复用与多路分解
- 将运输层报文段中的数据交付到正确的套接字的工作叫做多路分解
- 在源主机从不同套接字中收集数据块,并为每一个数据块封装上首部信息(这将在以后用于分解)从而生成报文段,然后将报文段传递到网络层,所有这些工作称为多路复用
- 运输层多路复用要求:
①套接字有唯一标识符
②每个报文段有源端口号字段和目的端口号字段来指示该报文段所要交付到的套接字
1.无连接的多路复用和多路分解 - 一个UDP套接字是由一个二元组全面标识的,该二元组包含一个目的IP地址和一个目的端口号
- 在A到B的报文段中,源端口号用作“返回地址”的一部分,即当B需要回发一个报文段给A时,B到A的报文段中的目的端口号便从A到B的报文段中的源端口号取值
2.面向连接的多路复用与多路分解 - TCP套接字是由一个四元组(源IP地址,源端口号,目的IP地址,目的端口号)来标识的
- 与UDP不同的是,两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字,除非TCP报文段携带了初始创建连接的请求
3.Web服务器与TCP
- 连接套接字与进程之间并非总是有着一一对应的关系
3.3 无连接运输:UDP
- UDP只是做了运输协议能够做的最少工作
- 在发送报文段之前,发送方和接收方的运输层实体之间没有握手,因此UDP被称为是无连接的
3.3.1UDP报文段结构
- UDP首部只有四个字段,每个字段由两个字节组成
3.3.2UDP检验和
- 检验和用于确定当UDP报文段从源到达目的地移动时,其中的比特是否发生了改变(例如,由于链路中的噪声干扰或者存储在路由器中时引入问题)
- 发送方的UDP对报文段中的所有16比特字的和进行反码运算,求和时遇到的任何溢出都被回卷。得到的结果被放在UDP报文段中的检验和字段
- UDP提供差错检测,但是对差错恢复无能为力
3.4 可靠数据传输原理
- 由于可靠数据传输协议的下层协议也许是不可靠的,因此这是一项困难的任务。
3.4.1构造可靠数据传输协议
- 经完全可靠信道的可靠数据传输:rdt1.0
- 经具有比特差错信道的可靠数据传输:rdt2.0
引入基于差错检验、接收方反馈(ACK&NAK)和重传机制的自动重传请求协议(ARQ)
rdt2.0被称为停等协议,当发送方处于等待ACK或NAK的状态时,它不能从上层获得更多数据,除非发送方确信接收方已正确接收当前分组
- 但是rdt2.0中并没有考虑ACK或NAK分组受损的情况,当发送方收到含糊不清的ACK或NAK分组时,只需重传当前数据分组即可。
- 通过让发送方对其数据分组编号,接收方只要检查序号即可确定收到的分组是否一次重传
- 经具有比特差错的丢包信道的可靠数据传输:rdt3.0
3.4.2流水线可靠数据传输协议
- 发送方(或信道)的利用率为:发送方实际忙于将发送比特送进信道的那部分时间与发送时间之比
- 若以停等方式发送,利用率太低。解决方法是允许发送方发送多个分组而无须等待确认
- 流水线技术:许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中
流水线技术对可靠数据传输协议带来如下影响:
①:必须增加序号范围
②:协议的发送方和接收方两端需要缓存多个分组
解决流水线的差错恢复有两个基本方法是:回退N步(GBN)和选择重传(SR)
3.4.3回退N步GBN
- 在**回退N步(GBN)**协议中,允许发送方发送多个分组(当有多个分组可用时)而不需等待确认。但它也受限于在流水线中未确认的分组不能超过某个最大允许数N
- [0,base-1]段内的序号对应于已经发送并被确认的分组
- [base,nextseqnum-1]段内对应已经发送但未被确认的分组
- [nextseqnum,base+N-1]段内的序号能用于那些要被立即发送的分组
- 大于或等于base+N的序号是不能使用的
- N常被称为窗口长度,GBN协议也常被称为滑动窗口协议
- GBN发送方必须响应三种类型的事件:
①上层的调用
②收到一个ACK,采用累积确认
③超时事件
GBN协议接收缓存简单,接收方不需要缓存任何失序分组,只需要丢弃即可
3.4.4选择重传SR
- 选择重传SR协议通过让发送方仅重传那些它怀疑在接收方出错(即丢失或受损)的分组而避免了不必要的重传。
- SR接收方将确认一个正确接收的分组而不管其是否按序。失序的分组将被缓存直到所有丢失分组(即序号更小的分组)皆被收到为止。
3.5 面向连接的运输:TCP
- TCP是因特网传输层的面向连接的可靠的运输协议
3.5.1TCP连接
- TCP被称为是面向连接的
- TCP连接也总是点对点的,即在单个发送方与单个接收方之间的连接
- 由于在两台主机之间发送了三个报文段,所以这种连接建立过程被称为三次握手
- TCP连接的组成包括:一台主机上的缓存、变量和与进程连接的套接字,以及另一台主机上的另一组缓存、变量和与进程连接的套接字
3.5.2TCP报文段结构
- 与UDP首部一样,包括源端口号、目的端口号、检验和字段
- 除此之外还有32比特的序号字段、32比特的确认号字段
- 16比特的接受窗口字段,用于流量控制,指示接收方愿意接受的字节数量
- 4比特的首部长度字段,指示了以32比特的字为单位的TCP首部长度
- 可选与变长的选项字段,用于发送方和接收方协商最大报文段长度(MSS)
- 6比特的标志字段:
①ACK比特用于指示确认字段中的值是有效的
②RST、SYN、FIN比特用于连接建立和拆除
③PSH比特被置位时,就指示接收方应立即将数据交给上层
④URG比特用来指示报文段里存在着被发送端的上层实体置为“紧急”的数据
- TCP可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度(MSS)
- MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度(即所谓的最大传输单元MTU)来设置
1.序号和确认号
- TCP报文段首部中最重要的两个字段是序号字段和确认号字段
- 一个报文段的序号因此是该报文段首字节的字节流编号
- 确认号是主机A期望从主机B收到的下一字节的序号
- 因为TCP只确认该流中至第一个丢失字节为止的字节,所以被称为累积确认
3.5.3往返时间的估计与超时
- 超时间隔必须大于该连接的往返时间(RTT),即从一个报文段发出到它被确认的时间
1.估计往返时间
样本RTT(SampleRTT) 就是从某报文段被发出(即交给IP)到对该报文段的确认被收到之间的时间量。
随着路由器的拥塞和端系统负载的变化,SampleRTT会随之波动
TCP维持一个SampleRTT均值——EstimatedRTT=(1-α)·EstimatedRTT+α·SampleRTT
这种平均被称为指数加权移动平均(EWMA)
同时定义了RTT偏差——DevRTT=(1-β)·DevRTT+β·|SampleRTT-EstimatedRTT|
2.设置和管理重传超时间隔
TimeoutInterval = EstimatedRTT+4·DevRTT
3.5.4可靠数据传输
- TCP在IP不可靠的尽力而为服务之上创建了一种可靠数据传输服务
1.一些有趣的情况
2.超时间隔加倍
TCP重传具有最小序号的还未确认的报文段。只是每次TCP重传时都会将下一次的超时间隔设为先前值的两倍,而不是用EstimatedRTT和DevRTT推算出的值
3.快速重传
冗余ACK就是再次确认某个报文段的ACK,而发送方先前已经收到对该报文段的确认
一旦收到三个冗余ACK,TCP就执行快速重传,即在该报文段的定时器过期之前重传丢失的报文段
4.是回退N步还是选择重传
对TCP提出的一种修改意见是所谓的选择确认,它允许TCP接收方有选择地确认失序报文段,而不是累积地确认最后一个正确接受的有序报文段。
3.5.5流量控制
- TCP为它的应用程序提供了流量控制服务,以消除发送方使接收方缓存溢出的可能性
- TCP通过让发送方维护一个称为接收窗口的变量来提供流量控制
①RcvBuffer:接收缓存的大小
②LastByteRead:接收方主机上的应用进程从缓存读出的数据流的最后一个字节的编号
③LastByteRcvd:从网络中到达的并且已放入接收缓存中的数据流的最后一个字节编号
则TCP要求有LastByteRcvd-LastByteRead<=RcvBuffer
使用rwnd来动态地标识接收窗口,则rwnd=RcvBuffer-[LastByteRcvd-LastByteRead]
3.6拥塞控制原理
为了处理网络拥塞原因,需要一些机制以在面临网络拥塞时遏制发送方
3.6.1拥塞原因与代价
- 情况1:两个发送方和一台具有无限大缓存的路由器
- 情况2:两个发送方和一台具有有限缓存的路由器
运输层向网络中发送报文段(含有初始数据或重传数据)的速率用λ’in bps表示,有时也被称为供给载荷
发送方必须执行重传以补偿因为缓存溢出而丢弃(丢失)的分组
发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本
- 情况3:四个发送方和一台具有有限缓存的路由器
- 对流式视频的最重要的性能度量是平均端到端吞吐量
3.6.2拥塞控制方法
- 端到端拥塞控制,网络层没有提供显式支持
- 网络辅助的拥塞控制,路由器提供显示反馈信息
3.7 TCP拥塞控制
- TCP所采用的方法时让每一个发送方根据所感知到的网络拥塞程度来限制其能向连接发送流量的速率
- 运行在发送方的TCP拥塞控制机制追踪一个额外的变量——拥塞窗口(cwnd)
- LastByteSent - LastByteAcked <= min{cwnd,rwnd}
- 通过调节cwnd的值,发送方因此能调整它向连接发送数据的速率
1.慢启动
当一个TCP连接开始时,cwnd的值通常初始置为一个MSS较小值
在慢启动状态,cwnd的值以一个MSS开始并且每当传输的报文段被确认就增加一个MSS
这一过程每过一个RTT,发送速率就翻番
当存在一个由超时指示的丢包事件(即拥塞),将第二个状态变量——慢启动阈值(ssthresh)设置为cwnd/2
当cwnd的值等于ssthresh时,结束慢启动并且TCP转移到拥塞避免模式
2.拥塞避免
一旦进入拥塞避免模式,cwnd值大约是上次遇到拥塞的值的一半
每个RTT只将cwnd的值增加一个MSS,进行线性增长
当出现超时时,TCP将cwnd的值减半,并进入快速恢复状态
3.快速恢复
在快速恢复中,对于引起TCP进入快速恢复状态的缺失报文段,对收到的每个冗余的ACK,cwnd的值增加一个MSS
4.TCP拥塞控制:回顾
TCP拥塞控制常常被称为加性增、乘性减拥塞控制方式
3.7.1公平性
- 我们的目标应该是使取得的吞吐量落在图中平行等宽共享曲线与全贷款利用曲线的交叉点附近的某处
- 假定在某给定时刻,连接1和连接2实现了由图中A点所指明的吞吐量。
- 因为这两条连接共同消耗的链路带宽量小于R,所以无丢包事件发生,根据TCP的拥塞避免算法的结果,这两条连接每过一个RTT都要将其窗口增加一个MSS。因此,这两条连接的总吞吐量就会从A点沿45°线前行
- 最终,这两条连接共同消耗的带宽将超过R,最终发生分组丢失,由B点指明。连接1和连接2于是就按二分之一减小其窗口,产生了由C点指明的吞吐量。以此类推,最终沿着平等带宽共享曲线波动。
- 无论这两条连接位于二维空间的何处,它们最终都会收敛到该状态
1.公平性和UDP
UDP没有内置的拥塞控制协议,因此从TCP的观点来看,运行在UDP上的多媒体应用是不公平的
2.公平性和并行TCP连接
当一个应用使用多条并行连接时,它占用了一条拥塞链路中较大比例的带宽
3.7.2明确拥塞通告:网络辅助拥塞控制
- 路由器所使用的一种ECN比特设置指示该路由器正在经历拥塞
- RFC3168并没有提供路由器拥塞时的定义;该判断是由路由器厂商所做的配置选择,并且由网络操作员决定
跳转
我们将以以下顺序进行总结: