运输层

运输层服务

运输层协议：为运行在不同主机上的应用进程提供逻辑通信功能（主机直接相连）。即端到端传输。

进程之间使用逻辑通信功能彼此发送报文，无需考虑具体物理链路。

运输层协议运行在端系统，不在路由器中。

发送方：将应用进程的报文划分成若干段，封装后传给网络层。

接收方：将网络层上传的报文段，重新装配为报文，传向应用层。

路由器只根据网络层字段而动作。

运输层和网络层的关系

运输层位于网络层上。

网络层提供主机之间的逻辑通信。

运输层为运行在不同主机上的进程之间提供逻辑通信；

依赖、强化网络层服务

运输层概述

UDP(用户数据报协议)：为应用程序提供不可靠，无连接的服务。

TCP(传输控制协议)：为应用程序提供可靠的，面向连接的服务。

报文段(segment)：运输层分组。

数据报（datagram）：网络层分组。

网络层概述

IP（网际协议）：为主机之间提供逻辑通信。

IP服务模型：尽力交付服务。

尽最大的努力在通信的主机之间交付报文段，但不保证按序交付或数据的完整性。属于不可靠服务。

IP地址：主机的网络层地址。每台主机有一个。

UDP和TCP的服务模型

将两个端系统间IP的交付服务扩展为运行在两个端系统上的进程之间的交付服务。

即主机间交付扩展到进程间的交付。运输层的多路复用和分解

可提供完整性检查。UDP是不可靠服务。TCP提供可靠数据传输及拥塞控制。

复用与分解

将网络层所提供的主机到主机交付服务扩展到在主机上运行的应用程序到应用程序的交付服务。

主机上可以有多个应用进程运行。当运输层从底层网络接收数据时，应能正确地定向到相应的一个进程（套接字）

套接字

从网络向进程传递数据，或从进程向网络传递数据的门户。

运输层和应用进程通过套接字来传递数据。主机上的套接字可以有多个，每个套接字都有惟一的标识符（格式取决于UDP或TCP）。

多路复用与分解过程

多路复用（发送主机）： 从不同套接字收集数据块，并*为每个数据块封装上首部信息，生成报文段，*传递到网络层。

多路分解（接收主机）：*将报文段中的数据交付到正确的套接字。*即接收方运输层从报文段的多个字段中，识别出套接字，并将报文段定向到该套接字。

过程事例

主机1：运输层收集套接字输出的数据，形成运输层报文段，将其传递给下面的网络层（多路复用）主机2：运输层将从其网络层收到的报文段多路分解后通过相应的套接字交给其上的P1进程。

目的主机分解过程

当报文段到达主机时，运输层检查报文段中的目的端口号，将其定向到相应的套接字。报文段中的数据通过套接字进入其所连接的进程。

报文段格式

端口号：主机上的每个套接字分配一个16位端口号。(0-65535)

0-1023 为常用端口号开发新应用时需选择一个端口号

无连接的多路复用与分解

UDP的多路复用与分解

创建UDP套接字的方法

自动为该套接字分配一个端口号。

DatagramSocket mySocke = new DatagramSocket()

从1024～65535的号码中分配一个主机尚未使用的UDP端口号。

直接为套接字指定一个特定的端口号。

DatagramSocket mySocke = new DatagramSocket (19157)

UDP套接字

UDP套接字组成（标识目的套接字）: 二元组（目的IP地址，目的端口号）

具有不同源套接字，但具有相同目的套接字的UDP报文段，接收段可通过相同套接字定向到相同的目的进程(多对一)源端口号的作用：目的方回发报文段中的返回地址

面向连接的多路复用与分解

TCP的多路复用与分解

TCP套接字

标识目的的套接字：四元组 (源IP地址，源端口号，目的IP地址，目的端口号)

目的主机使用全部四个值来将收到的TCP报文段定向(分解)到对应的套接字两个具有不同源套接字的TCP报文段，将被定向到不同的两个套接字

TCP的连接与分解

服务器应用程序在某个端口上等待TCP客户机连接建立请求。如

ServerSocket welcomeSocke = new serverSocket(6789)TCP客户机在相应端口上产生一个连接建立请求报文段。

Socket clientSocke = new Socket (“serverHostName”，6789)当服务器收到客户机的连接请求后，通知服务器进程，并创建一个连接套接字。如，

Socket connectionSocket = WelcomeSocket.accept()连接套接字通过4个值来标识。TCP连接完成后，客户机和服务器可相互发送数据。当一个TCP报文段到达主机时，根据4个字段值的来定向(多路分解)到相应的套接字。

实例

主机C向服务器B发起两个HTTP会话；

主机A向服务器A发起一个HTTP会话。

多线程Web服务器

无连接服务：UDP

基本概念

UDP报文段结构

UDP检查和

用于检查所传输的报文段中的比特差错 (如比特翻转)。

实例

作加法时，最高位的进位要回加到结果中。

可靠数据传输原理

可靠数据传输的问题在运输层、链路层及应用层都会出现。

数据通过一条可靠的信道传输即传输的数据不出错，丢失，并按照发送的顺序传送

可靠传输实现

设计可靠数据传输协议

低层信道不太可靠，通过使用可靠数据传输协议来保证可靠的数据传输。

分别设计可靠数据传输协议的发送方和接收方。

基本实现

只考虑单向数据传输，数据传输从发送方到接收方发送方和接收方可以来回交换控制分组(控制信息双向流动)使用有限状态机(FSM)来定义发送方和接收方

有限状态机概述

箭头：表示协议从一个状态变迁到另一个状态横线上方：表示引起变迁的事件横线下方：表示事件发生时所采取的动作∧：表示没有事件或未采取动作虚线：表示FSM的初始状态

构造可靠的的数据传输协议

rdt1.0 完全可靠信号的上的可靠数据传输

RDT1.0

条件假设

底层信道完全可靠：数据传送不出错不丢失收发双方速率匹配：接收方接受数据的速率和发送方发送数据一样快所有分组都是从发送方流向接收方接收方无需反馈信息，因为无差错发生

rdt1.0的FSM

接受发送方FSM相互独立

rdt 2.X具有比特差错信道上的可靠的数据传输

RDT2.0停止等待协议：发送方发完一个分组后停止，等待对方回答

条件假设

信道不完全可靠，可能产生比特差错，但不丢包所有分组按序发送并被接收(有些bit可能出错)

肯定确认，否定确认

类比例：

打电话传递一条长信息收听者：

听清每句话后说“OK”（肯定确认）；

听到不清楚的话，要求对方重复说“请重复一遍”（否定确认）。

肯定确认：告诉发送方内容被正确接收。

否定确认：告诉发送方内容出错需要重传

基于重传机制的可靠数据传输协议称为自动重传请求协议ARQ(Automatic Repeat request)

ARQ协议处理比特差错机制

差错检测

使接收方检测出是否出现比特差错。

如采用差错检测和纠错技术，使接收方能够进行差错检测并纠正。需要给分组附加额外的比特一起发送。如rdt2.0协议，分组增加检验和checksum字段。

接收方反馈

使发送方知道发送的分组是否被正确接收。

通过接收方回送肯定确认(ACK)和否定确认(NAK)分组完成。如rdt2.0协议，接收方将向发送方回送*ACK（“1”比特）或NAK（“0”比特）*分组。

重传

接收方收到有差错的分组时，通知发送方重传该分组。

rdt2.0特点

可以解决数据分组出错问题。若返回ACK或NAK分组受损，发送方无法知道接收方是否正确接收了上一块数据。

rdt2.0的FSM

停等（stop-and-wait）协议：发送方发完一个分组后停止，等待对方回答。

基本模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BKRkbFk6-1610437010294)(D:\StudyData\Notes[其他]计算机通用知识\CNpics\image-0105160439748.png)]

当发送方在等待ACK或NAK状态时，不能从上层得到数据，直到收到ACK离开该状态。发送方在收到ACK分组之前，不会发送任何新数据，直到收到ACK分组为止。

无错误场景

有错误场景

处理受损ACK和NAK的可能方法

收发双方互不理解对方回答的含义使对话不能正常进行。

增加足够的检验和比特：

使接收方不仅可以检测差错，还可进行恢复。适用于会产生差错但不丢失分组的信道。

当发送方收到含糊不清的ACK或NAK分组时：简单地重发当前数据分组。

产生冗余分组(duplicate packets)：同一个分组收到两次。接收方无法知道收到的是新的分组还是重传的分组。

冗余分组解决方法

给分组添加一个序号字段。

发送方：给发送的数据分组编号，并将其序号放入“序号字段”。

每发送一个新的分组*“序号加1”。*

接收方：通过检查序号，确定收到的分组是不是重复传送。

按序号接收，若本次接收到的分组序号与前一次收到的分组的序号相同，即为重复分组，将该重复分组丢弃。

序号位数选择

停等协议：只需用一个比特，即“0”和“1”两种不同的序号。

序号通过模2运算向前移动，可以区分前后相邻的两帧。0、1、0、1、……

说明

ACK和NAK分组不需要指明要确认的序号。因为假设信道不丢失分组。

不丢失必然有序，故此ack，nak天然带序号

发送方知道所接收的ACK和NAK分组是对最近发送分组的响应。

rdt2.1

可以处理重复分组

判断分组是否重复方法：当前所处状态提供了期望收到分组的的序列号

相较rdt2.0多了序列号

指出正发送或准备接收的分组的序号。发送或期望接收0号分组的状态中的动作与发送或期望接收1号分组的状态中的动作相似，只是序号处理方法不同。使用从接收方到发送方的肯定和否定确认。

发送方

接收方

对收到0或1且内容正确，必发ack，因为收到正确内容则可以继续接收下一个数据

rdt2.2

无NAK消息协议；给ACK标记序列号

接收方通过ACK告知最后一个被正确接收的分组在ACK消息中显示地加入被确认分组的序列号发送方收到重复ACK之后，采取与收到NAK消息相同的动作重传当前分组

发送方

接收方

rdt3.0 具有比特差错的丢包信道上的可靠的数据传输

保证可靠数据传输协议的要点：检验和、序号、定时器、重传、肯定和否定确认。

假设条件

会出现比特差错会出现丢包发送的的数据分组丢失或接收方回发的AKC丢失

发送方发现丢包处理方法

发送方等待合理时间

若未收到ACK，重传

若分组或ACK只是延迟而非丢失

重传产生重复，序列号机制能够处理接收方需在ACK中显式告知所确认的分组

需要定时器

设置一个“递减（倒）计数定时器”，给定时间过期后，中断发送方。

要求发送方：

每发送一个分组(包括第一次和重发的分组)，启动一个定时器；响应定时器中断：采取适当的动作；终止定时器。

rdt3.0的FAM

发送方

接收方

rdt3.0接工作场景

无差错与分组丢失

ACK丢失与过早超时

停止-等待协议流程

基本概念

N(S)：发送序号变量，当前传送分组的编号，发送新分组时，N (S)+1；

V®：接收序号变量，当前准备(希望)接收的分组序号，每收到一个新分组时，V®+1；

判断重复分组（接收方）：

N(S) = V®，收到的是新数据分组；

N(S) != V®，收到的是重复分组。

发送方和接收方流程

发送方

接收方

停等协议效率

能够正常工作，但效率不高。

发送方(信道)利用率Usender = 发送方将比特发送到信道的时间/发送时间 即（传输时延L/R/发送方从发送分组开始，到收到对方ACK分组，所需的时间。）

两个端系统之间的光速往返传播时延RTT约 30ms信道传输速率 R=1Gb/s(109bit/s)分组长 L = 1000字节 发送方只有0.027%的时间忙。发送方在30.008ms内只能发送l000byte，有效的吞吐量仅为267kbit/s(l000X8/(30.008X10-3),即使有1Gbit/s的链路可用)

流水线技术改进效率

允许发送方连续发送多个分组而无需等待确认，称为流水线技术（众多分组可看成是填充到一条流水线中）。

N为连续发送分组个数

应用实例

技术要点

增加序号范围：由于可连续发送多个分组，每个分组有唯一序号，可能有多个在传输中的未确认报文。需要缓存多个分组：

发送方至少能缓冲已发送但没有确认的分组；

接收方缓存已正确接收的分组。序号范围和对缓存的要求：取决于数据传输协议处理丢失、差错及过度延时分组的方式。

滑动窗口协议(Silding-window protocol)

窗口：

允许使用的序列号范围窗口尺寸为N：最多有N个等待确认的消息

滑动窗口：

随着协议的运行，窗口在序列号空间内向前滑动

主要类型：GBN,SR

GBN协议

回退N步 (Go-Back-N, GBN协议)

GBN协议综合可靠数据传输的全部技术：使用序号、累积确认、检验和以及超时/重传操作等

GBN缺点：可能需要很多的重传

基本思想

发送方：连续发送多个数据分组，停止等待

收到确认ACK，继续发送后面分组；超时，未收到应答，从出错分组开始重发

接收方：按序号接收数据分组

正确：接收处理，发确认ACK；出错：将出错分组及后面分组均丢弃，不发任何应答。

注意事项

连续发送的分组个数不能太多：

增加序号字段位数；

出错时，要重传很多数据分组，影响效率。连发个数受流水线中未确认的分组数限制，不能超过最大允许数N。

通过设置发送窗口和接收窗口来分别控制连续发送和接收的分组个数。

发送方

控制发送方连续发送的个数

实际是允许连续发送的序号表，只有落在发送窗口所包含序号之内的，才能不等待应答发送。

分组头部包含k-bit序列号

窗口尺寸为N，最多允许N个分组为确认

ACK(n)：确认序列号n(包含n)的分组均已被正确接收累计确认

可能收到重复ACK

为空中的分组设置计时器(timer)

超时Timeout(n)事件：重传序列号大于等于n，还未收到ACK的所有分组

序号范围分割成4部分：

[0，base-1]：已经发送并确认过的分组。[base，nextseqnum-1]：已经发送但未被确认分组[nextseqnum，base+N-1]：用于将立即发送的分组[base+N, ]不能使用，直到当前流水线中未被确认的分组得到确认(序号为base的分组)。

发送窗口大小WT

WT = N，即序号范围[base，base+N-1]，包括已发送未被确认的分组、以及准备发送的分组。随着协议的运行，发送的分组陆续被确认，发送窗口在序号空间内向前滑动。若分组序号字段的位数是k，则序号范围是[0,2k-1]

发送方扩展FSM

响应的事件：

上层的调用：上层调用rdt_send()检查发送窗口是否已满（是否有N个已发送、但未被确认的分组）

窗口未满：创建一个分组并将其发送，更新变量

窗口已满：将数据返回给上层，以后再试。

收到ACK： 对序号为 n的分组的确认使用累积确认，即表明接收方已正确接收到序号为n及以前的所有分组(从接收方来说，如果n分组以前有一个分组没有正确收到，接收方是不会发出n分组的确认的；所以发送方只要收到n的确认即说明n及以前分组接收方都正确收到了，但是发送方不一定能收到所有n及以前分组的确认，因为有些确认分组可能丢掉了)。

超时：设置定时器处理*“数据或确认分组丢失”*情况

只使用一个定时器，作为最早的已发送但未被确认的分组的定时（每次窗口滑动后，还有已发

未确认分组时，定时器都重新开始对窗口中基序号分组进行倒计时，即基序号变化且还有已发未确认分组时将重启定时器）。

产生超时：发送方重发所有已发未确认分组。

收到一个ACK：

​ 仍有已发送但未被确认的分组，重新启动定时器。

​ 没有未确认报文，终止定时器。

接收方

按序接收。接收方WR=1。

正确按顺序接收到序号为n 的分组：将分组中的数据交付到上层，并回发一个 ACK；分组一次性交付给上层：分组k 被交付，k之前均已交付。其他情况的分组：丢弃该分组，并为最近按序接收的分组重发ACK。丢弃所有失序分组：控制简单，接收方不需要缓存任何失序分组。

接收方扩展FSM

ACK机制: 发送拥有最高序列号的、已被正确接收的分组的ACK

可能产生重复ACK只需要记住唯一的expectedseqnum

乱序到达的分组：

直接丢弃->接收方没有缓存重新确认序列号最大的、按序到达的分组 接收方维护下一个按序接收的分组的序号，该值保存expectedseqnum变量中。

窗口为4的GBN协议的运行

发送方：连续发送4个分组后等待，直到一个或多个分组被确认；

每接收到一个连续的ACK时，该窗口便向前滑动。

接收方：收到一个连续的正确的分组，窗口向前滑动。

SR协议

选择性重传 (Selective Repeat, SR协议)

发送方只重传出错（丢失或受损）的分组。

SR协议的发送方和接收方窗口不总一致

基本概念

GBN需要重传很多分组

发送方：连发多个数据分组，停止等待

收到确认ACK，继续发送后面分组；超时,未收到应答，只重发出错分组。

接收方：不按序号接收数据分组

正确：接收、按顺序交付，发确认ACK；出错：丢弃该分组，以后正确分组放入缓存，当出错分组正确收到后，按顺序一起交付。

​

不按序接收。接收窗口大小 > 1，即只要序号落在接收窗口内的正确分组都可接收。

某时刻发送方/接收方窗口

发送方的事件与动作

接收方的事件与动作

接收方接收正确分组不管其是否有序。

SR协议示例

窗口最大尺寸

若序号位数k位，SR协议，发送窗口和接收窗口尺寸最大是2k-1，不是2k-1。即序号空间一半。

避免发生接收序号重叠，出现重复分组

反例说明：

设序号2位，则序号空间为0#～3#，发送窗口和接收窗口尺寸最大是2，不是3。

三种协议比较

可靠传输机制及用途总结

机制

校验和：检测分组传输中的比特错误。

定时器：用于检测分组超时及重传分组

分组或ACK丢失；

一个分组被延时但未丢失（过早超时），或ACK丢失，接收方可能会收到重复分组。

序号：发送的数据分组按顺序编号。

接收方可检测分组丢失（序号间的空隙）或重复（相同序号的分组）。

**ACK确认：**接收方用其告诉发送方某个分组或一组分组已被正确地接收。

确认报文包含被确认的分组或多个分组的序号。可以是逐个的或累计。

**NAK否认：**接收方告诉发送方某个分组尚未正确地接收。包含未被正确接收的分组的序号。

*窗口、流水线：*发送方可以连续发送序号落在发送窗口序号范围内的分组，可以不用逐个确认。

问题

即使发送方或接收方的窗口中都没有包含x，但可能会出现一个具有序号或确认号x的分组的旧拷贝。

为确保序号不被重新使用，需要*发送方“确信”*任何先前发送的序号为x的分组都不再在网络中为止。

*规定分组最长的寿命：*分组在网络中“生存”的时间不会超过某个固定的最长时间。

如在TCP中假定为大约3分钟。

面向连接服务：TCP

采用：差错检测、重传、累积确认、定时、序号和确认序号。

TCP概述

特点

通信过程

建立TCP连接：三次握手。进程通信：通过套接字发送及接收。

封装成报文段传输。

报文段结构

TCP序列号与ACK

序列号

序列号指的是segment中第一个字节的编号，而非segment的编号

建立TCP连接时，双方只能随机选择序列号

ACKs

希望收到的下一个字节的序列号

累计确认：该序列号之前的所有字节均已被正确接收到

由TCP实现者做出决策如何处理乱序到达的Segment

TCP的可靠数据传输

TCP连接管理

建立连接 3次握手

3次握手机制

Client：是连接发起者

Server：等待客户连接要求

使用三次握手原因：为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

关闭连接 4次挥手

四次挥手

Client 和 server都可为发起者

一般为Client

等待2MSL原因：确认服务器端是否收到客户端发出的ACK确认报文

拥塞控制

网络中的10大主要问题之一

流量控制：发送方不要发送得太快以至于接收方无法处理

拥塞：太多的源发送的太多太快的数据，使网络来不及处理。

表现：

丢包(路由器缓冲区溢出)长时延(路由器缓冲区中排队)

对丢失的分组重传，不能解决网络拥塞问题

产生拥塞控制时遏制发送方

网络拥塞如何从上层得到的服务中反映出来；如何避免网络拥塞，或对其作出反应。

拥塞原因与开销(代价)

拥塞原因：资源未被充分利用

拥塞的代价：端系统得到很差的服务性能

讨论：随着主机增加发送速率是网络变得拥塞时产生的影响。

场景1

两个senders,两个receivers

一个路由器：

无限缓存（两个连接共享，单跳路由）：不丢失分组

没有重传

拥塞时分组延迟太大达到最大throughput

网络拥塞代价：当分组到达速率接近链路容量时，分组排队时延非常大。

吞吐率与时延

场景2

两个senders,两个receivers

一个路由器, 有限缓存

拥塞的代价：

对给定的”goodput”，要做更多的工作 (重传)造成资源的浪费

场景3

四个发送方

多跳

超时/重传

拥塞：

当分组被drop时，任何用于该分组的“上游”传输能力全都被浪费掉

拥塞控制方法

根据网络层是否为运输层拥塞控制提供明确的帮助

TCP的拥塞控制

端到端控制 (没有网络辅助)

由发送方根据感知到的拥塞程度，来限制其发送流量的速率。

无拥塞：增加发送速率

有拥塞：降低发送速率

如何限制发送速率

设置拥塞窗口CongWin：对发送方向网络的发送流量速率进行限制。

发送方中未被确认的数据量小于拥塞窗口。通过调节CongWin值，调整发送速率。

如何感知拥塞

丢失事件：超时或者3个重复ACK发生丢失事件后，TCP发送方降低速率（拥塞窗口）。

拥塞时处理方式

AIMD（加增倍减算法）

逐渐增加发送速率，谨慎探测可用带宽，直到发生loss

Additive Increase: 每个RTT将CongWin增大一个MSS——拥塞避免

Multiplicative Decrease: 发生loss后将CongWin减半

慢启动SS

初始时可用带宽远远大于初始速率，窗口呈指数型增长，在CongWin达到Loss事件前1/2变为指数增长

例题