第三章、运输层（重点知识梳理）

3.1概述和运输层服务

 

3.1.1运输层概述

运输层协议是为运行在不同主机上的应用进程之间提供逻辑通信

传输协议运行在端系统

• 发送方：将应用层的报文分成报文段，然后传递给网络层
• 接收方：将报文段重组成报文，然后传递给应用层

有多个传输层协议可供应用选择

• Internet:TCP和UDP

3.1.2传输层和应用层的关系

传输层vs网络层

网络层服务：主机之间的逻辑通信

传输层服务：进程之间的逻辑通信

• 依赖于网络层的服务（延时、带宽）
• 并对网络层的服务进行增强（数据丢失、顺序混乱、加密）

有些服务是可以加强的，（不可靠到可靠、安全）；但有些服务是不可以被加强的（带宽、延迟）。

3.2多路复用和多路分解

多路分解：将传输层报文段的数据到正确的套接字的工作。

多路复用:在源主机从不同套接字中收集数据块，并为每个数据块装上首部信息（这将在以后用于分解）从而生成报文段，然后将报文段传递到网络层的工作。

多路解复用的工作原理：

• 解复用作用：TCP或者UDP实体采用哪些信息，将报文段的数据部分交给正确的进程
• 主机收到IP数据报

              每个数据报有元IP地址和目标地址

              每个数据报承载一个传输层报文段

              每个报文段有一个源端口号和目标端口号（特定应用有署名的端口号）

• 主机联合使用IP地址和端口号将报文段发送给合适的套接字

 1.无连接的多路复用与多路分解

• 创建套接字

服务器端：

server socket=socket(PF_INET,SOCK_DGRAM,O);

bind(server socket,&sad,sizeof(sad);

server socket和sad的端口号捆绑

客户端：

没有Blind,client socket和OS为之分配的某个端口号捆绑（客户端使用什么端口号无所谓，客户端主动找服务器）

• 在接收端，UDP套接字用二元组标识（目标IP地址，目标端口号）
• 当主机收到UDP报文段：检查报文段的目标端口号    用该端口号将报文段定位给套接字
• 如果两个不同源IP地址/源端口号的数据报，但是有相同的目标IP地址和端口号，则北定位到相同的套接字

2.面向连接的多路复用和多路分解

3.Web服务器与TCP

3.3无连接运输：UDP(User Datagram Protocol)---用户数据报协议

“尽力而为的服务”，报文段可能

• 丢失
• 送到的应用进程的报文段乱序

无连接

• UDP发送端和接收端之间没有握手
• 每个UDP报文段都被独自的处理

UDP被用于

• 流媒体(丢失不敏感，速率敏感，应用可控制传输速率)
• DNS
• SNMP

在UDP上实现可靠传输：

• 在应用层增加可靠性
• 应用待定的差错恢复

为什么要有UDP?

• 不建立连接（会增加延时）
• 简单:在发送端和接收端没有连接状态
• 报文段的头部很小（开销很小）
• 无拥塞控制和流量控制，UDP可以尽可能快的发送报文段

应用--传输速率＝主机--网络的速率

3.1.1UDP报文段结构

3.3.2 UDP检验和

目标：检测在被传输报文段中的差错（如比特反转）

发送方：

• 将报文段的内容视为16比特的整数
• 校验和:报文段的加法和（1的补运算）
• 发送方将校验和放在UDP的校验和字段

接收方：

• 计算接收到的报文段的校验和
• 检查计算出的校验和字段的内容是否相等，不相等---检查到差错；相等---没有检查到差错（可能还存在差错）

 3.4可靠数据传输

3.4.1可靠数据（rdt)传输的原理

• rdt在应用层，传输层和数据链路层都很重要
• 是网络Top10问题之一
• 信道的不可靠特点决定了可靠数据传输协议（rdt)的复杂性

我们将：

• 渐增式地开发可靠数据传输协议（rdt)的发送方和接受方
• 只考虑单向传输    但控制信息是双向流动的！
• 双向流动的数据传输问题实际上是2个单向数据传输问题的综合
• 使用有限状态机（FSM）来描述发送方和接受方

3.4.2 rdt1.0：在可靠信道上的数据传输

下层的信道是完全可靠的

• 没有比特差错
• 没有分组丢失

发送方和接收方的FSM

• 发送方和数据发送到下层信道

• 接收方从下层信道接收数据

3.4.3 rdt2.0:具有比特差错的信道

用校验和来检验比特差错

问题：怎么从差错中恢复；

• 确认（ACK):接收方显式地告诉发送分组已被正确接收
• 否认确认（NAK):接收方显式地告诉发送方分组发生了丢失    发送方收到NAK后，发送方重传分组

rdt2.0中的新机制：采用差错控制编码进行差错检测

• 发送方差错控制编码,缓存
• 接收方使用编码检错
• 接收方的反馈：控制报文（ACK,NAK):接收方----发送方
• 发送方收到反馈相应的动作

3.4.4 rdt2.1发送方和接收方处理出错的ACK/NAK 

rdt2.1：讨论

发送方：

• 在分组中加入序列号
• 两个序列号（0，1）就足够了    一次只发送一个未经确认的分组
• 必须检测ACK/NAK是否出错（EDC)
• 状态数变成了两倍           必须记住了当前分组的序列号为0还是1

接收方：

• 必须检测接收方的分组是否是重复的    状态会指示希望接收到的分组的序号为0还是1

注意：接收方并不知道发送方是否正确接收到了其ACK/NAK

•     没有安排确认的确认
• 具体解释见下

接收方不知道最后发送的ACK/NAK是否被正确地收到

• 发送方不对收到的ACK/NAK给确认，没有所谓的确认的确认；
• 接收方发送ACK,如果后面接收方收到的是：

           老分组PO？  则ACK错误

           下一个分组？p1,ACK正确

3.4.5 rdt2.2:无NAK的协议 

功能同rdt2.1,但只使用ACK（ACK要编号)

接收方对最后正确接收的分组发送ACK以代替NAK

• 接收方必须是显示地包含被正确接受分组的序号

当收到重复的ACK（如：再次收到ack0），发送方与收到NAK采取相同的动作：重传当前分组

为后面的一次发送多个数据单位做一个准备

• 一次发送多个
• 每一个的应答都有：ACK,NAK；麻烦
• 使用对前一个数据单位的ACK,代替本数据单位的NAK
• 确认信息减少的一半，协议处理简单

3.4.6 rdt3.0:具有比特差错和比特丢失的信道 

• 新的假设：下层信道可能会丢失分组（数据或ACK)
• 会锁死
• 机制还不够处理这种状况：

        检验和    序列号    ACK    重传

方法：发送方等待ACK一段合理的时间

• 发送方端时重传；如果到时没有收到ACK----重传
• 问题;如果分组（ACK)只是被延迟了;

                重传将会导致数据重复，但利用序列号已经可以处理这个问题

                接收方必须指明备被正确接收的序列号

• 需要一个倒计时定时器

链路层的time out时间是确认的

传输层timeout时间是适应式的

• 过早超时（延迟的ACK)也能够正常工作；但是效率较低，一般的分组和确认是重复的
• 设置一个合理的超时时间也是比较重要的

rdt3.0的性能

• rdt3.0可以工作，但是链路容量比较大的情况下，性能较差

链路容量比较大，一次发一个PDU的不能够充分利用链路的传输能力

 3.4.7 选择重传（SR)

• 接收方对每一个正确接收的分组，分别发送ACKn（非累计确认）

接收方窗口>1    可以缓存乱序的分组

• 发送方只对那些没有收到ACK的分组进行重发-选择性重发

        发送方为每一个未确认的分组设定一个计时器

• 发送窗口的最大值（发送缓冲区）限制发送未确认分组的个数

选择重传

发送方：

从上层接收数据：

• 如果下一可用该分组的序号可在发送窗口中，则发送time out(n):
• 重新发送分组n,重新设定定时器 
• 将分组n标记为已接收
• 如n为最小未确认的分组序号，将base移到下一未确认序号

接收方：

• 发送ACK（n)
• 乱序：缓存
• 有序：该分组及以前缓存的序号连续的分组交付给上层，然后将窗口移动到下一个仍未被接收的分组
• 忽略该分组

3.5面向连接的传输：TCP

•  点对点：

一个发送方，一个接收方

• 可靠的，按顺序的字节流：

没有报文边界

• 管道化（流水线):

TCP拥塞控制和流量控制设置窗口大小

• 发送和接收缓存
• 全双工数据：

在同一连接中数据流双向流动

MSS:最大报文段大小

• 面向连接    在数据交换之前，通过握手（交换控制报文)初始化发送方，接收方的状态变量
• 有流量控制    发送方不会淹没接收方

TCP序号，确认号

• 序号：报文段首字节在字节流的编号
• 确认号：

                   期望从另一方收到的下一字节的序号

                    累计确认

     Q：接收方如何处理乱序的报文段--没有规定

       TCP往返时延（RTT）和超时

Q：怎样设置TCP超时？

• 比RTT要长  但RTT是变化的
• 太短：太早超时           不必要的重传
• 太长：对报文段丢失    反应太慢，消极