跳至主要內容

计算机网络自顶向下

程序员李某某大约 74 分钟

计算机网络自顶向下

计算机网络和因特网

什么是Internet

我们可以从两个角度来回答这个问题:一种是描述组成它的软硬件;另一种是将其视为为分布式应用提供基础服务的联网设施来描述。其实,第一种角度,是从它的组成来描述,第二种角度是从它的功能来描述

组成

因特网是一个世界范围的计算机网络,这意味着它互联了数以亿计的计算设备(不仅仅是计算机哦);这些设备包括但不限于传统PC、工作站以及所谓的服务器。现在有更多的设备加入到因特网中,比如便携式计算机、电视机、汽车、传感器等。用因特网的术语来说,所有连入因特网的设备都叫做主机或者端系统

  • 端系统通过通信链路和分组交换机连接到一起。
  • 端系统之间发送数据时,发送端系统将其数据分成一段一段,然后加上必要的信息后形成一个个的数据包,这个数据包用术语来说叫做分组。于是分组==用户数据+必要信息。链路系统就是用来传输分组的。分组到达接收端系统后,接收端系统将根据必要信息来抽取用户数据;
  • 分组交换机从它的一条入链路接收分组,并且选择一条出链路将分组转发出去;分组交换机也有很多种类,最为有名的是路由器和链路层交换机;两者的的不同之处在于,链路层交换机主要用在接入网中,路由器主要用在网络核心
  • 端系统通过因特网服务提供商(Internet Service Provider,简称ISP)接入因特网;
  • 很有名的协议有:TCP(Transport Control Protocol,传输控制协议)和 IP(Internet Protocol,网际协议);因为协议控制了信息的传递,所以对协议达成一致就很重要,所以需要一个标准来规范协议,以便创造可以协同工作的系统和产品

可以将计算机网络结构理解为三部分组成:

  • 节点
    • 网络边缘(端系统):如主机,网络应用, (end system)
    • 网络核心:如互联的路由器(或分组转发设备)
    • 通信链路:接入网络,物理介质,如有线或无线通信链路,传输速率我们叫做带宽, bit /s or bps
  • 协议

协议

分组==用户数据+必要数据;这些必要数据为分组接收者理解用户数据提供保障,而协议就是如何使用必要数据理解用户数据的方法或者规则;

分组接收者接收到分组并按照协议获得了用户数据后,还应该对此消息做出反应,而如何做出反应也是协议规范的一部分(不反应也是一种反应哦)

协议:定义了在两个或多个通信实体之间交换的报文格式和次序,以及报文发送和/或接收一条报文或其他事件所采取的动作。

凡是通信实体的所有活动都要受到协议的约束。比如,硬件实现的控制协议控制了两块网卡之间的比特流;在端系统中,拥塞控制协议控制了发送方和接收方之间传输数据的速率等

网络边缘

网络边缘端系统(主机),客户和服务器

网络应用的通信模型:

  • 客户/服务模型(C/S):客户为使用服务者,服务器:提供服务者。
    • 主机多 ,集中式 、损失很大 , 可扩展性差, 请求载荷增加, 能力下降 , 到阈值处,会达到断崖式下降
  • 对等模型(P2P):所有的主机同时承担服务器和客户机的双重身份。
    • 分布式 , 解决服务器的扩容总满足不了用户请求的需求 eg文件分发系统(迅雷)

通信链路

接入网

接入网access network:将端系统连接到其边缘路由器edge router的物理链路

作用:将网络边缘与网络核心连接起来,通常是将端系统连接到边缘路由器上

边缘路由器为端系统到任何其它远程端系统的路径上的第一台路由器

方式:家庭--Modem拨号/ADSL拨号/HFC/FTTH/卫星;机构--以太网/Wi-Fi;广域无线接入--3G/LTE。

  • Modem拨号

    将上网数据调制加载音频信号上 --- 调频、调幅、调相位、综合调制

    通过本地电话回路,点对点连接ISP拨号池(一般是路由器)

    在局端将其中的数据解调出来

    无法实现上网的同时拨打电话;不能总是在线

    速率低(以56kbps的速率直接接入路由,通常更低)

  • 数字用户线(Digital Subscribe Line,DSL)

    用已有的电话线连接中心局的 DSLAM

    • 数据通信通过 DSL 电话线接入互联网 --- ISP
    • 语音(电话)通过DSL电话线接入电话网

    使用的通信链路的物理材质为电话线,是一种双绞线

    上行速率2.5Mbps,通常小于1Mbps

    下行速率24Mbps,通常小于10Mbps

    频分复用(不同频率的信号发送不同功能的数据),带宽独享

  • 电缆因特网接入(Cable Internet Access,CIC)

    这是另一种宽带住宅接入方法,它的 ISP 是有线电视公司。其使用的通信链路的物理材质有光纤和同轴电缆,也被称为混合光纤同轴(Hybrid Fiber Coax HFC);

    用户使用电缆调制解调器通过同轴电缆光纤结点相连,光纤结点通过光缆与电缆头端相连,而电缆头端接入了因特网。在电缆头端,电缆调制解调器端接系统(Cable Modem Termination System)起到 DSLAM 的作用,即实现模拟信号和数字信号的转换

  • 光纤到户(Fiber TO The Home,FTTH)

    这里主要是指使用光纤作为通信链路的材质,有两种竞争性的光纤分布方案,一种是主动光纤网络(Active Optical Network),另一种是被动光纤网络(Passive Optical Network).其主要区别在于,是否在传输数据时共享光纤

  • 以太网和WIFI

    以太网接入是一种在公司、大学、家庭里很流行的接入方式;用户使用双绞线以太网交换机相连,从而接入因特网;接入以太网交换机的速度可达 100Mbps;

    在无线局域网中,无线用户从一个接入点发送和接收数据,而该接入点与企业网相连,企业网最终接入因特网;在无线 LAN 中,用户需要在一个接入点的几十米范围之内

  • 广域无线接入

    在移动设备中,通过蜂窝网提供商运营的基站来发送和接收分组,与 WIFI 不同的是,用户仅需要位于基站的数万米范围之内即可;

物理媒体

传输媒体是构成通信链路的主要部分,物理媒体通常可以分为导引性媒体和非导引性媒体;对于导引性媒体,电波沿着固体媒体前行,如光缆、双绞线活同轴电缆。对于非导引性媒体,电波在空气或外层空间中传播。

值得注意的是,架设传输媒体的人力成本要远远高于物理材料的成本

双绞线

最便宜的引导性传输媒体,由两条相互螺旋缠绕的铜线组成。目前局域网中的双绞线数据传输速率在10Mbps到10Gbps之间,所能达到的数据传输速率取决于线的粗细以及传输距离;双绞线实际上已经成为高速局域网联网的主要方式;因为现代的双绞线技术速率和传输距离都是很不错的;

同轴电缆

也由两个铜导体构成,但是它们是同心的,而非并行的;借助特殊的结构和绝缘层,同轴电缆可得到较高的数据传输速率;在电视系统中应用广泛;同轴电缆可被用作引导性的共享媒体;

光纤

一种可以引导光脉冲的媒体 陆地无线电信道

无线电信道承载电磁频谱中的信号,不需要物理线路,提供与移动用户的连接以及长距离承载信号的方式;是一种有吸引力的媒体;

卫星无线电信道

通过卫星连接两个或多个在地球上的微波发射方(也被称为地面站),该卫星在一个频段上接收信号,在另一个频段上发送信号;种类有同步卫星和近地轨道卫星

网络核心

网络核心:互联端系统的分组交换机和链路构成的网状网络, 网络核心的关键功能: 路由+转发

  • 路由: 决定分组采用的源到 目标的路径- --- 路由算法
  • 转发: 将分组从路由器的输 入链路转移到输出链路

基本问题:数据怎样通过网络进行 传输?

通过网络链路和交换机移动数据有两种基本方法:电路交换和分组交换

数据交换除了电路交换和分组交换,还有一种书上未介绍的报文交换报文:源(应用)发送信息整体,比如一个文件,作为整体进行发送

报文交换与分组交换均采用存储-转发交换方式,区别:

  • 报文交换以完整报文进行“存储-转发”
  • 分组交换以较小的分组进行“存储-转发”

电路交换

  • 先建立连接再数据交换,建立连接的过程是确定链路是通的,交换机存储一些路由信息,预留端系统间通信路径上的相关资源(缓存,链路传输速率),即先建立连接,然后通信,独占资源;(建立连接就是先把路径规划好,然后按照这个路径进行通信),这一连接,用电话的术语被称为“电路”。

  • 建立连接的阻塞:如果A->B建立了连接,那么他们之间的链路就被他们占了,也就是说,在端系统进行通信时,其所需要的资源是被保持的,其他通信是无法使用这一部分资源的;

  • 保证带宽:电路交换网络必须以固定的速率进行数据传输,高不行,低也不行。这对于实时数据是有好处的,例如语音和视频,每个连接一旦建立就能够保证性能,传统的电话网络就是电路交换网络的例子

  • 多路复用:电路交换网络把链路划分成很多信道,然后进行多路复用,可以避免阻塞,更灵活了。

  • 如果连接建立后没有数据发送,被分配的资源就会被浪费

  • 电路交换 不适用于计算机之间的通信 ,计算机之间的通信有突发性,如果使用线路交 换,则浪费的片较多 ,即使这个呼叫没有数据传递,其所占据的片也不能 够被别的呼叫使用

    电路交换网络保持恒定的速率,如果负载<链路的带宽,比如链路每次可以传100个快递,但用户只传10个,那么用户需要填充一些空白的信息,即发90个空的快递,等另一个用户接收的时候,再把这些空快递扔掉。

    对于突发性的数据,分组交换可以更好的分配带宽,最大程度利用链路的带宽(因为分组交换是缓存了packet,然后传到不同的链路上)。但是,分组交换的话,时延不确定,对于实时性的数据不太适用,(相当于不知道快递啥时候才到),通常实时数据用电路交换。

电路交换网络中的复用

时分复用(Time-Division Multiplexing TDM):是指将时间划分为固定区间的帧,每个帧则又被划分为固定数量的时间空隙;当网络需要建立一条连接时,网络将在每个帧中为该连接指定一个时隙;在该时隙内,链路用来传输该链接的数据

image-20230815165353008

频分复用(Frequency-Division Multiplexing FDM):将频率域划分为频段,然后将频段分配给连接;此频段被用来专门传输链接的数据。该频段的宽度成为带宽

image-20230815165647559

除此之外,多路复用技术还有波分多路复用(Wavelength division multiplexing-WDM)和和码分多路复用( Code division multiplexing-CDM),波分复用就是光的频分复用

分组交换

  • 将要传送的数据分成一个个单位: 分组

    数据流划分为小的片段(分组、帧、信元),每个分组有头有尾,头包括了目的地址,尾部包括了检验和,检验数据传输过程是否丢失或者修改。

    数据流分拆出来的一系列相对较小的数据包,分组交换需要报文的拆分与重组,会产生额外开销

  • 每段:采用链路的最大传输能力( 带宽) -- 网络带宽资源不再像电路交换的多路复用那样将资源分成小片,传输时使用全部带宽

    分组在通信链路上以等于该链路的最大传输速率传输通过通信链路。因此如果某条链路的最大传输速率为R,分组长度为L,则该链路传输该分组的时间为L/R;这个时间也被称为传输时延

  • 资源共享,按需使用:不再像电路交换那样独占资源,通过存储转发,将分组从一个路由器传到相邻路由器(hop),一段段最终从源端传到目标端

  • 统计时分复用:分组交换的多路复用本质上也是时分复用,只不过是随机的,而电路交换是提前划分好的

存储转发

  • 存储转发:交换机在收到一个完整的分组,才会向链路输出转发分组,否则就将收到的部分分组缓存起来;

  • 因为缓存等待一个分组的全部数据而导致的时间开销被称为存储转发时延,存储转发时延比线路交换的时延要大

    交换机收到很多分组,先看目的地址、校验和,如果检验和表示数据完整,交换机开始分组处理。

    首先将分组放入输入缓存队列,经由内置处理器转发到下一接口的输出队列进行排队。这个技术称之为,存储转发技术(store-and-forward technique)

转发表与路由选择协议

实际上,分组交换机之所以能够知道往哪去是因为其内部有一个转发表,这个表维护了一个IP地址和链路的对应关系,所以处理流程为:

  1. 通过分组的必要信息,获得目的端系统的IP地址
  2. 通过IP地址索引转发表,从而确定输出链路

分组转发方法

  • (数据报)无连接:数据报传输,走一步看一步。每个分组各自携带目的地址,分别由路由交换,各自独立到达目的地。好处是简单,速度快。缺点是难以追踪各分组,延时、丢失、到达顺序难以控制(不满足Qos要求)
    • 分组的目标地址决定下一跳
    • 在不同的阶段,路由可以改变 ---- 类似:问路
  • 面向连接的传输:建立会话(别名:逻辑连接),记录会话开始和结束,按照会话历史可调整转发过程
  • 虚电路:路线写死,每个虚电路需要先建立逻辑连接,再传输数据流。每个分组都有一个标记
    • 每个分组都带标签(虚电路标识 VC ID),标签决定下一跳
    • 每个节点维护一个虚电路表,存储从哪来、第几号电路、到哪去、第几号电路
    • 在呼叫建立时决定路径,在整个呼叫中路径保持不变
    • 路由器维持每个呼叫的状态信息

对比

分组交换的优点:

  • 提供了比电路交换更好的带宽共享;
  • 比电路交换更简单、更有效、实现成本更低;

分组交换的缺点:

  • 分组交换不适合实时服务,因为端到端的时延是可变、不可预测的,这和整个网络的情况相关;
  • 容易丢包

电路交换的优点:

  • 提供了端对端传输数据的速率保证;

电路交换的缺点

  • 电路交换存在静默期,这是指专用电路空闲时,其占用的资源并没有得到充分的利用;
  • 建立连接的过程比较复杂;

总体上来说,分组交换的性能要好于电路交换的性能,但是不同类型的分组交换方式有不同的应用场景;比如一些对最低速率有着严格要求的应用,比如实时服务等,为了获得速率保证,牺牲网络的效率也是可以接受的。趋势向着分组交换发展

Internet结构和ISP

ISP

  • 第一层ISP --- 国家/国际覆盖
    • 商业ISPs(commercial ISPs) --- (如电信、移动、联调、UUNet, BBN/Genuity, Sprint, AT&T)
    • 内容提供商网络 (Internet Content Providers,) eg :Google, Microsoft, Akamai ,baidu 可能会构建它们自己的网络,将它们的服务、内容更 加靠近端用户,向用户提供更好的服务,减少自己的运营支出
    • 竞争与合作:不同ISP合作扩展业务,肯定要互联
      • peering link 两个ISP对等连接
      • IXP(Internet exchange point) 多个ISP对等连接
  • 第二层ISP --- 区域ISP(Regional ISP)
  • 第三层ISP --- 本地ISP

网络的网络

为了实现端系统的互联,ISP也必须互联

网络结构发展

  • 网络结构1:存在唯一的全球承载ISP互联所有的接入ISP

  • 网络结构2:存在多个全球承载ISP,它们分别与一部分的接入ISP互联;为了实现端系统的互联,这多个全球ISP也必须互联;网络结构是一个两层结构,其中全球承载ISP位于顶层,接入ISP处于底层;

  • 网络结构3:顶层全球承载ISP基本上已经定型,但是接入ISP现在还很混乱,比如,它们直接同顶层ISP相连;而网络结构3中,接入ISP也是分层的:下层的ISP连接上层的ISP,而不是直接与顶层ISP相连;这是因为,如果都直接同顶层ISP相连,那么两个同一较小区域内,分属不同ISP的端系统之间通信的数据也会到顶层ISP中心去一趟,如果它们不是直接接入顶层ISP,而是接入了一个较大区域的ISP,那么它们之间的通信数据就不用去顶层ISP中心了,因为它们通过较大区域的ISP已经实现了互连,所以通信速度肯定就上去了。

  • 网络结构4:是在网络结构3的基础上,增加了以下特点而形成的结构:存在点(Point of Presence,PoP)、多宿、对等、因特网交换点(Internet exchange point,IXP)

  • 网络结构5:网络结构5是在网络结构4的基础上增加了内容提供商网络而构成。内容提供商构建自己的网络,并且通过与较低层ISP对等而“绕过”较高层因特网ISP,而且内容提供商对端用户也有了更多的控制

    image-20230815171727629

ISP之间的连接

  • POP:高层ISP面向客户网络的接入点,涉及费用结算,如一个低层ISP接入多个高层ISP,从而实现与提供商ISP连接。这样接入速度很明显就提高了
  • 多宿(multi home):任何ISP(除第一层ISP)都可以与两个或者多个提供商ISP连接,这被称为多宿;这样网络的可靠性就提高了
  • 对等接入(peering link):位于相同等级结构层次的一对邻近ISP能够直接将它们的网络连接到一起,使它们之间流量经直接连接而不是经过上游的中间ISP传输,这样既不用付费,速度也可能会快一些
  • 因特网交换点(Internet exchange point IXP):多个对等ISP互联互通之处,通常不涉及费用结算
  • 网络内容服务商(Internet Content Provider ICP)自己部署专用网络,同时和各级ISP连接

分组转发时延

一个分组在沿途每个节点承受不同类型的时延,这些时延中最为重要的是:结点处理时延、排队时延、传输时延和传播时延.这些时延总体累加起来是结点总时延

  • 处理时延(nodal processing delay)

    处理时延是因为节点需要解析分组的必要信息然后决定其出链路(索引转发表等操作)而产生的,通常在微秒或者更低数量级;

    • 检查bit级差错
    • 检查分组首部和决定将分组导向何处
  • 排队时延(queueing delay)

    排队时延是因为分组所对应的出链路前面有其他分组正在传输,所以分组需要该链路的缓冲队列里等待其他分组传输完毕而产生的;一般来说,排队时延是到达该队列的流量强度和性质的函数,通常可以达到毫秒级到微秒级;

  • 传输时延(transmission delay) --- $d_{trans} = L/R$,其中 L 是分组长度(bits),R 是链路带宽 (bps)

    传输时延是将所有分组的比特推向链路所有需要的时间,实际的传输时延通常在毫秒到微秒数量级。用L表示分组的长度,用Rbps表示从路由器A到B的链路传输速率。传输时延是L/R。

  • 传播时延(propagation delay) --- $d_{prop} = d/s$,其中 d 是物理链路长度,s 是信号传播速度 (~2×10 8m/sec)

    传播时延是指比特进入链路后,从该链路的起点到下一个结点所用的时间;一旦分组中的最后一个比特到达路由器就意味着该分组的所有比特都已到达路由器;广域网中,传播时延一般是毫秒级的。传播时延是d/s。d是路由器A到B的距离。s是链路的传播速率

分组转发丢失

如果到达速率>链路的输出速率:

  • 分组将会排队,等待传输 --- 排队时延
  • 丢包:到达的分组发现一个满的队列。由于没有地方存储这个分组,路由器将丢弃该分组,该分组将会丢失

排队时延和丢包与网络的状况和结点的缓冲空间大小、处理速度相关;

如果分组到达的速度高于结点的处理速度,那么分组就会在缓冲队列里排队等待。

当缓冲空间用完后,如果还有到的分组,那么该分组将被迫丢弃

为了描述网络状体,我们引入了流量强度这一概念:流量强度=分组到达的速度/结点的处理速度;流量工程里一个金科玉律就是:设计系统时流量强度不能大于1;

当流量强度持续大于1时,就将出现丢包现象

吞吐量

  • 计算机网络的吞吐量实际上是一个速度指标,它描述了比特经过某个节点的速度。

  • 对于某条路径上的结点来说,和该结点有关的速度有两个:接收数据的速度和发送数据的速度,而该结点的吞吐量是这两个速度中较小的一个;

  • 对于某条路径来说,该路径的吞吐量则是所有节点的吞吐量的最小值;网络的吞吐量可以衡量网络的性能

    任何时间的瞬时吞吐量是主机B接受到该文件的速率,如果该文件由F比特组成,主机B接受到所有比特用去Ts,则文件的平均吞吐量为F/Tbps

吞吐量可以近似为源和目的地之间路径的最小传输速率。最小传输速率的链路为瓶颈链路。在今天,因特网对吞吐率的限制因素通常是接入网

Traceroute 诊断程序

在Windows系统下,可以通过 tracert 命令跟踪路由与延时,详情open in new window

协议层次及服务模型

  • 网络是一个复杂的系统!
  • 问题是: 如何组织和实现这个复 杂的网络功能?

ISO/OSI七层模型

层级功能TCP/IP协议族设备
应用层为用户提供接口,包括文件传输,电子邮件,文件服务,虚拟终端等TFTP,HTTP,SNMP,FTP,SMTP,DNS,RIP,Telnet
表示层数据格式化,码转换(如ASCII,GBK,JPEG等),数据加密、压缩
会话层对应用会话的管理、同步ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets
传输层进程 - 进程,可靠与不可靠的传输、传输前的错误检测、流控TCP、UDP
网络层端 - 端(E2E),定义IP编址,定义路由功能IP,ICMP,RIP,OSPF,BGP,IGMP路由器
数据链路层点 - 点(P2P),成帧、用MAC地址访问媒介、错误检测与修正SLIP,CSLIP,PPP,ARP,RARP,MTU网桥、交换器
物理层设备之间的比特流的传输、物理接口、电器特性等ISO2110,IEEE802中继器、集线器
image-20230818114957825

封装

一个分组,在不同的层次有不同的称谓,是因为它们经过每一层的时候就被该层封装上了属于该层的相关信息,也就是前面提到的必要信息;于是,每一分层的分组有两种类型的字段:首部字段和有效负载;其中有效负载即为来自上一层的分组数据,而首部字段就是该层加上的必要信息;分组不断被封装以实现各层协议规定的相关功能

封装增加控制信息,构造协议数据单元 (PDU);控制信息主要包括:地址,差错检测编码(Error-detecting code),协议控制(Protocol control),协议控制实现协议功能的附加信息,如: 优先级(priority)、服务质量(QoS)、 和安全控制等

image-20230818115326796

应用层

应用层协议原理

  • 研发网络应用的核心是写出能够运行在不同端系统和通过网络彼此通信的程序;

  • 值得注意的是,我们不需要写在网络核心设备如路由器或者链路层交换机上运行的软件,

  • 这种设计方式即将应用程序限制在端系统的方法,促进了大量网络应用程序的迅速研发和部署

体系结构

客户-服务器(C/S)体系结构

  • 服务器

    • 一直运行

    • 固定IP、约定端口

    • 扩展性差

      通常,如果仅有一台服务器处理所有的请求,那么服务器系统将很快变得不堪重负,

      为此,配备大量主机的数据中心常被用于创建强大的虚拟的服务器,

      一个数据中心可以有数十万台服务器,它们需要供电和维护,同时服务提供商还需要支付不断出现的互联和带宽费用,以及发送和接收到达/来自数据中心的数据

  • 客户端

    • 主动与服务器通信
    • 与互联网有间歇的连接
    • 可能是动态的ip
    • 客户端之间不能通信

对等(P2P)体系结构

  • 几乎没有一直运行的服务器
  • 任意端系统之间 可以进行通信
  • 每个节点既是客户端又是服务器
    • 自扩展性 -- 新peer节点带来新的服务能力,当然也带来新的服务请求
  • 目前,流量密集型应用都是P2P体系结构的。这些应用包括文件共享(例如 BitTorrent)、协助下载(例如迅雷)、因特网电话(例如 Skype)和 IPTV (例如迅雷看看)
  • 但是 P2P 也面临着以下三个问题:
    • ISP 方面。大多数住宅 ISP 受制于非对称带宽应用,也就是下载比上传要多得多。但是 P2P 视频和文件分发应用改变了从服务器到住宅ISP的上载流量,因而给 ISP 带来压力;
    • 安全方面。因为其高度的分布和开放式,P2P应用也可能给安全带来挑战;
    • 用户方面。如何说服用户资源向应用提供带宽、存储和计算资源?这是一个问题;

混合结构

  • P2P参与的主机间歇性连接且可以改变IP地址 --- 难以管理
  • 值得注意的是,某些应用具有混合的体系结构,它们结合了客户-服务器和P2P这两种体系结果,比如许多的即时通讯工具,服务器用来跟踪用户IP地址,但是用户之间的通信则使用直接发送
    • Napster:全球第一个走红的P2P文件共享平台
      • 文件搜索:C/S ---- 主机在服务器上注册资源;主机通过服务器找资源位置
      • 文件传输:P2P ---- 任意的Peer节点
    • 即时通讯
      • 在线检查:C/S ---- 用户在线时,向服务器注册IP地址;用户通过服务器找好友位置
      • 在线聊天:P2P

进程通信

  • 进程:在主机上运行的应用程序

    • 客户端进程:发起通信的进程
    • 服务器进程:等待连接的进程
    • P2P架构应用也有客户端进程和服务器进程之分
  • 在同一主机内,使用进程间通信机制通信(操作系统)

  • 在不同主机之间,通过交换报文来通信:使用OS提供的通信服务,按照应用协议交换报文(借助传输层提供的服务)

  • 分布式进程通信需要解决的问题

    • 进程标识和寻址问题

      • 进程为了发送、接收报文,必须有一个标识,即:SAP

        • 主机:唯一的32位IP地址
        • 传输协议:TCP、UDP
        • 端口号
      • 一个进程:用IP+port标识 端节点

      • 一对主机通信由2个端节点构成

    • 传输层-应用层 提供服务是如何

      • 位置:层面界面的SAP(TCP/IP:socket)
      • 形式:应用程序接口API(TCP/IP:socket API)

      如果Socket API每次传输报文,都携带如此多的信息,太繁琐易错,不便于管理

      用代号标识通信的双方会单方:socket

      就像OS打开文件返回的句柄一样(对句柄操作就是对文件操作)

      TCP socket

      • TCP服务,两个进程之间的通信之前需要建立连接,通信会持续一段时间,通信关系稳定

      • 可以用一个整数表示两个应用实体之间的通信关系:本地标识

      • 通过本地标识,使得穿过层间接口的信息量最小

      • 对于TCP的应用而言,套接字是4元组的一个具有本地意义的标识

      • 4元组:源IP、源port、目标IP、目标port

      • 唯一的指定了一个会话(2进程之间的会话关系)

      • 应用使用这个标识,与远程的应用进程通信

      • 不必在每个报文发送时都指定这4元组

      • 就像使用OS打开文件,OS返回一个文件句柄一样,操作socket的值就是在操作会话关系

      • 简单、便于管理

      UDP Socket

      • UDP服务,无需建立连接,每个报文都独立传输,前后报文可能给不同的分布式进程
      • 因此,只能用整数表示本地应用实体
      • 2元组:本IP、本Port
      • 在发送数据时,采用创建好的本地套接字,就不必在发送每个报文时指明采用的ip、port
      • 但是,传输报文时,必须提供对方的IP、port
    • 如何使用传输层提供的服务,实现应用进程之间的报文交换,实现应用

      • 定义应用层协议:报文格式,解释,时序等
      • 编制程序:使用OS提供的API,调用网络基础设施提供通信服务传报文,实现应用时序等

      应用层协议:定义了运行在不同端系统上的应用进程如何交换报文

      • 交换的报文类型:请求和应答报文
      • 各种报文类型的语法:报文中各个字段和描述
      • 字段的语义
      • 进程何时、如何发送报文、对报文进行响应的规则

      应用协议仅仅是应用 的一个组成部分 ---- web应用:http协议、web客户端、web服务器、html

      公开协议:由RFC文档定义,允许互操作,如http、SMTP

      私有协议:协议不公开,如Skype

传输服务

传输层协议的特点大致可以从以下这四个方面考量:可靠数据传输、吞吐量、定时和安全性

  • 可靠数据传输

    如同在第一章中介绍的,分组在传输过程中可能会丢失。比如,分组因为路由器中的缓存溢出而被丢弃或者分组在传输的过程中发生了损坏等情况;有些应用是不允许数据发生丢失的,比如电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等。为了支持这些应用,必须做一些工作以确保应用程序一段发送的数据正确、完全地交付给接收数据的进程。如果一个协议提供了这样得确保数据交付的服务,就认为该协提供了可靠数据传输。

    • 当应用程序使用可靠数据传输的传输层协议时,只要将要发送的数据传输进套接字就可以完全相信该数据可以完整无差错地到达接收方;

    • 当一个运输层协议不提供可靠数据传输时,由发送方发送的数据就可能不能够到达接收进程。有些应用是允许这样的情况发生的,这些应用被称为丢失允许的应用。这类应用常见的有:交谈式音频和视频

  • 吞吐量

    在一条网络路径上的两个进程之间的通信会话中,可用吞吐量就是指能够向接收进程交付比特的速率。因为会有其他会话共享该网络的路径的带宽,并且因为这些会话的到来和离开,可用吞吐量将发生变化;这就导致另一种自然的服务,即运输层协议能够提供确切的可用吞吐量。使用这种服务时,应用程序就能以明确的速度接收数据,并且运输层应当保证可用吞吐量必须总是至少为该速度;

    对吞吐量有明确要求的应用程序被称为带宽敏感的应用。许多多媒体应用是带宽敏感的(尽管某些多媒体应用程序可能采用自适应编码技术对数字视频和音频以与当前可用带宽相匹配的速度加解码。),比如因特网电话。而弹性应用则对吞吐量没有严格的要求。这类应用包括:电子邮件、文件传输以及web传送等。值得注意的是,吞吐量当然是越多越好了。

  • 定时(延迟)

    定时和吞吐量都是关于速度的。一个提供定时服务的例子是:发送方注入套接字中的每个比特到达接收方的套接字不迟于100ms。也就是说,定时是对数据从发送到到达所需时间的要求,而吞吐量是对数据交付速度的要求。打个比方,吞吐量是指一个小时内经过某个收费站的汽车数目,而定时则是第一辆车从出发到进入收费站的时间。有些应用为了服务的有效性而对数据到达时间有严格的要求,常见的应用有:因特网电话、多方在线游戏等;

  • 安全性

    运输层可以提供一些安全服务,以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括:数据的加解密、数据的完整性和端点鉴别等。

常见应用对传输服务的要求

img

TCP服务

  • 可靠的,面向连接的
  • 流量控制:发送方不会淹没接收方
  • 拥塞控制:当网络出现拥塞时,能抑制发送方
  • 不能提供的服务:时间保证、最小吞吐量保证、安全

UDP服务

  • 不可靠的,无连接的
  • 不能提供的服务:可靠、流量控制、拥塞控制、时间保证、带宽保证、建立连接、安全

为什么要有UDP?

  • 能够区分不同的进程,而IP服务不能:在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程
  • 无需建立连接,省去了建立连接的时间,适合事务性的应用
  • 不做可靠性的工作,例如检错重发,适合对实时性要求比较高,对准确性要求不高的应用
  • 没有拥塞控制、流量控制,应用能按照设定的速度发送数据,而TCP上面的应用发送数据的速度和主机向网络发送的实际速度不一致

安全TCP

  • TCP、UDP都没有加密,明文传输
  • SSL在应用层,应用采用SSL库提供的加密,SSL库使用TCP通信

Web 和 HTTP

  • web页:由一些对象组成
  • 对象可以是HTML、JPEG、Java小程序、声音剪辑文件等
  • Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
  • 通过URL对每个对象进行引用

http

  • 使用的TCP

    • 客户端发起与服务器的TCP连接(建立套接字)
    • 服务端接受客户的TCP连接
    • 在浏览器与服务器交换HTTP报文
    • TCP连接关闭
  • HTTP是无状态的:服务器不维护关于用户的任何信息

    维护状态的协议很复杂,必须维护历史信息(状态)

    如果服务器\客户端死机,他们的状态信息可能不一致,二者的信息必须得一致

    无状态的服务器能支持更多的客户端

  • 非持久HTTP

    • 最多只有一个对象在TCP连接上送达(每次请求都要建立一次连接)
    • 下载多个对象需要多个TCP连接,每次请求时间 = 2RTT+传输时间
    • HTTP/1.0使用非持久连接
  • 持久HTTP

    • 多个对象可以在一个TCP连接上传输
    • 非流水线的持久HTTP:等收到响应再发送下一次请求
    • 流水线的持久HTTP:客户端遇到一个引用对象就立即产生一个请求
      • HTTP/1.1默认使用持久连接

报文

  • 一个请求报文具有至少一行的内容。

    • 请求报文的第一行称为请求行(request line)。请求行包含三个内容:方法字段、URL字段、HTTP版本;其中方法字段可为:GET、POST、PUT、DELETE、HEAD等。URL字段里可以传递请求对象的标志;

    • 请求行后继的各行被称为首部行(header lines) --- 请求头

      • Host :对象所在的主机。
      • Connection : close 使用非持续连接;
      • user-agent:浏览器版本是 Mozilla/5.0,即 Firefox 浏览器;
      • Accept-language :表示用户想得到该对象的法语版本。
    • 请求空行

    • 请求体:可以在POST方法里传递Form表单内容、二进制流数据等。值得注意的是,表单也不一定必须使用POST方法。如果使用get,实体体为空,会显示在url中

    img
  • 请求方法

    • Head类似于get方法,将会用一个http报文进行响应,但是不返回请求对象,经常用作调试跟踪。
    • put方法允许用户上传对象到指定的Web服务器上指定的路径。
    • Delete方法允许用户或应用程序删除Web服务器上的对象。
  • 响应报文总体上也分三个部分,

    • 状态行(status line),包含HTTP版本、状态以及状态信息等内容;
    • 首部行(header lines),包含发送日期、服务器类型、上一次修改请求资源的时间、内容的类型等内容。
    • 实体体(entity body),实体体包含请求对象本身。

前面提到,HTTP是无状态协议,但是Web站点为了识别用户身份或者限制用户访问的时间或者将用户访问的内容同用户身份相关联,Web站点可以使用Cookie技术;

Cookie技术包含4个组件

  • HTTP响应报文里增加一个关于Cookie的首部行;
  • HTTP请求报文里增加一个关于Cookie的首部行;
  • 用户端系统保留一个Cookie文件,由浏览器保存维护;
  • Web站点建立Cookie和用户身份的关联 --- 后端数据库;

Web缓存

  • Web缓存器( Web cache)也被称为代理服务器,在存储空间里保持有最近请求过的对象的副本;

  • 当代理服务器收到一个HTTP请求后,它将检查本地是否缓存过该对象,如果所请求对象在缓存中,缓存返回对象,否则,缓存服务器向原始服务器发送HTTP请求,获取对象,然后返回给客户端并保存该对象。

  • 缓存既充当客户端,也充当服务器

  • 通常,代理服务器与客户端的通信速度要快于初始服务器与客户端的连接速度。Web代理服务器可以大大减少对客户请求的响应时间;能够大大减少一个机构的接入链路到因特网的通信量。此外,Web 缓存器能从整体上大大减低因特网上的 Web 应用层流量, 从而改善了所有应用的性能。

Web 缓存示例

假定:

  • 对象的平均大小=100kb
  • 机构网络中的浏览器平均请求数:15个/s
  • 平均到浏览器的速率:1.5Mbps
  • 从机构路由器到原始服务器的往返延迟 = 2秒
  • 接入链路带宽:1.54Mbps

网络性能分析:

  • 局域网(LAN)的利用率(流量强度)=15%

  • 接入网的利用率(流量强度)=100%

  • 总的延迟=LAN延时+接入延时+Internet延时

    即:延迟 = ms + min + 2s

解决方案1:

  • 提升互联网接入带宽=10Mbps

网络性能分析:

  • 局域网(LAN)的利用率=15%
  • 接入互联网的链路的利用率=15%
  • 总的延迟=互联网上的延迟+访问延迟+局域网 延迟=2秒+几微秒+几微秒

问题:成本太高

解决方案2:

安装Web缓存 假定缓存命中率是0.4 网络性能分析:

40%的请求立刻得到满足,60%的请求通过原始服务器满足 接入互联网的链路的利用率下降到60%,从而其延迟可以忽略不计,例如10微秒 总的平均延迟=互联网上的延迟+访问延迟+局域网延迟 =0.6×2.01秒+0.4×n微秒<1.4秒

条件GET方法

高速缓存器的使用,带来很多好处,但是存在数据一致性问题

其实HTTP提供了一种机制,允许缓存器证实其使用的对象是最新的,这种机制就是条件GET(conditional GET)方法。

使用条件GET方法只需在使用GET方法的时候,增加一个If-Modified-Since首部行,其对应的内容是一个时间,如果所请求的资源在指定日期后被修改了,那么服务器将返回新的对象,否则服务器将返回一个包含空实体体的报文。这样代理服务器就可以确认缓存是否过期了。

FTP

  • FTP是FileTransferProtocol(文件传输协议)
  • C/S模式
  • ftp:RFC 959
  • 端口为21
  • 有状态,控制连接与数据连接分开

状态

  • FTP客户端与FTP服务器通过端口21联系,并使用TCP协议传输

  • 客户端通过控制连接获得身份确认

  • 客户端通过控制连接发送命令浏览远程目录

  • 收到一个文件传输命令时,服务器打开一个到客户端的数据连接

    • 服务器打开第二个TCP数据连接用来传输另一个文件
    • 控制连接:带外(out of band)传送
    • FTP服务器维护用户的状态信息:当前路径、用户账户与控制连接对应
  • 一个文件传输完成后,关闭连接

命令

  • 在控制连接上以ASCII文本方式传输
  • USER username
  • PASS password
  • LIST 请求服务器返回远程主机当前目录的文件列表
  • RETR filename:从远程主机的当前目录检索文件(gets --- 下载)
  • STOR filename:向远程主机的当前目录存放文件(puts --- 上传)

响应

状态码和状态信息同http

  • 331 Username OK,password required
  • 125 data connection already open;transfer starting
  • 425 Can't open data connection
  • 452 Error writing file

Email

电子邮件

  • 用户代理 ---- 又叫邮件阅读器,用于编写、阅读邮件,如Outlook、Foxmail,输出和输入邮件保存到服务器上
  • 邮件服务器
  • 传输协议 --- SMTP

传输协议 -- SMTP

(Simple Mail Transfer Protocol)简单邮件传输协议

交互过程

  • Alice使用用户代理(QQ邮箱)撰写邮件并发给Bob@163.com
  • Alice的用户代理将邮件发送到自己对应的邮件服务器(QQ),邮件放在报文队列中
  • SMTP的客户端打开到Bob邮件服务器的TCP连接(QQ和网易)
  • SMTP的客户端通过TCP连接发送Alice的邮件
  • Bob的邮件服务器将邮件放到Bob的邮箱
  • Bob用他的用户代理阅读邮件

交互命令

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

客户发送了 5 条命令:HELO(是 HELLO 的缩写)、MAIL FROM、RCPTTO、DATA 以及 QUIT,都是自解释的。 报文内容:“Do you like ketchup? How about pickles?” 客户发送一个只包含一个句点的行,向服务器指示该报文结束了。

使用 Telnet 与一个 SMTP 服务器进行一次直接对话,有兴趣的可以参考利用 telnet 命令测试 SMTP 服务open in new window

报文格式

  • 交换email报文的协议
  • RFC 822
  • 首部行:如To,From,Subject,与SMTP命令不同
  • 主体:报文只能是7位的ASCII码
  • 使用CRLF.CRLF决定报文的尾部

报文由两部分组成:一个包含环境信息的首部和一个包含邮件内容的报文体;

首部和报文体之间使用空行分开;

首部行的格式为关键字跟冒号及其值;

每个首部必须包含一个From和To首部行。

首部也可以包含其它信息,比如Subject等。SMTP命令不同,命令是握手协议的一部分;这里是邮件报文自身的一部分

多媒体扩展

  • 当一个字符不在ASCII码上,则需要扩展
  • MIME:多媒体邮件扩展(multimedia mail extension),RFC 2045,2056
  • 在报文首部用额外的行申明MIME内容类型
    • MIMIE-Version:MIME版本
    • Content-Transfer-Encoding:base64 数据编码方式
    • Content-Type:image/jpeg 多媒体数据类型、子类型和参数申明

与HTTP对比

  • Http是拉,SMTP是推
  • 二者都是ASCII形式的命令、响应交互、状态码
  • HTTP:每个对象封装在各自的响应报文中
  • SMTP:多个对象包含在一个报文中(如多个附件)
  • SMTP使用持久连接

访问协议 -- POP/IMAP

SMTP:是传送到接收方邮件服务器

image-20230822174432227

邮件访问协议:是从服务器访问邮件

POP3

  • POP:邮局访问协议(Post Office Protocol)[RFC 1939]

  • POP3是一个非常简单的协议,因为简单,所以功能有限;

  • POP3使用端口110来建立TCP连接(SMTP使用端口25);

  • POP3按照三个阶段进行工作

    • 用户确认阶段:用户代理发送密码和用户名,进行身份鉴别

      • 客户端命令

        • user:申明用户名
        • pass:口令
      • 服务器响应

        • +OK
        • -ERR
      • 事物处理阶段:用户代理取回报文,同时还可以做删除、取消删除等标记或者统计邮件信息

        • list:报文号列表

        • retr:根据报文号检索报文

        • dele:删除

        • quit

    • 更新阶段:在用户退出后,POP3结束会话,删除被标记的邮件

  • 事务处理两种模式

    • 下载并删除:

    • 下载并保留:不同的客户机上为报文的拷贝

  • POP3在会话中是无状态的

IMAP

  • IMAP:Internet邮件访问协议(Internet Mail Access Protocol)[RFC 1730]
  • POP3协议无法为用户提供邮件分类管理的功能,虽然用户可以通过将邮件下载到本地,然后由用户代理程序做分类管理,但是处理的结果是无法同步到其他查看设备上的。为了解决这一问题,IMAP诞生了。IMAP是一个邮件访问协议,在服务器上处理存储的报文,比POP3要复杂的多,当然也就有更多的特色
  • IMAP服务器将每个报文(邮件)与一个文件夹联系起来,当报文第一次到达服务器时,它与收件人的INBOX(收件箱)相关联
  • 允许用户用目录来组织报文:收件人可以将邮件移到新创建的文件夹,阅读邮件,删除邮件等,允许用户在不同文件夹里移动邮件并且查询邮件
  • 还允许用户代理获取报文组件而不是报文整体
  • IMAP在会话过程中保留用户状态:用户名、报文ID与目录名的映射

HTTP

方便,如Hotmail、Yahoo Mail等

用户使用HTTP协议和邮件服务器通信。用户代理就是普通的浏览器,但是,邮件服务器之间还是使用SMTP协议的

DNS

问题:域名和IP地址之间如何映射?

计算机网络里有一种应用专门提供这样的服务,它就是域名系统(Domain Name System,DNS)。DNS是:①一个由分层的DNS服务器(DNS serve)组成的分布式数据库;②一个使得主机可以查询分布式数据库的应用层协议组成;

DNS通常被其他应用层协议使用,比如:HTTP、SMTP和FTP等。这些协议在正式工作以前,首先利用DNS提供的服务,将主机名转换为IP地址,可以发现的是,DNS为用户带来方便的同时,也为网络应用带来额外的时延——查询DNS服务器的时延。需要注意的是,缓存作为一种提高性能,特别是查询性能的手段,在DNS中同样适用。

DNS运行在UDP之上,使用53号端口。

DNS提供的服务:

  • 主机名到IP地址的转换

  • 主机别名:虽然,主机名比起IP地址好记多了,但是有时候我们的主机名仍然很长,很不好记忆,所以我们需要为主机名再起一个名字,这就是主机别名,DNS不但提供主机名到IP地址的转换服务,还提供主机名与主机别名的转换;此时主机名被称为规范主机名;

  • 邮件服务器别名:DNS同样也提供邮件服务器主机名和别名的转换服务,实际上,公司的邮件服务器和Web服务器可以使用相同的主机别名。

  • 负载均衡:DNS也被用在冗余的服务器之间分配负载。每个服务器有着不同的IP地址,但是它们都和同一个主机名相关联,也就是一个IP地址集合同一个规范主机名相联系;当某个DNS服务器收到DNS请求时,该服务器奖使用IP地址的整个集合作为相应,但是在每个应答中,循环这些地址的次序。因为客户端通常都是使用IP地址集合的首个元素,所以DNS就在冗余的Web服务器之间分配了负载。同理,多个邮件服务器可以具有相同的别名

工作原理

  • 分层的,基于域的命名机制

  • 若干分布式的数据库完成名字到IP地址的转化

  • DNS使用UDP作为其传输层协议,使用53端口;

  • 核心的Internet功能,但以应用层协议实现 --- 在网络边缘处理复杂性

名字空间

  • 层次树状结构的命名方法
  • Internet根被划分为几百个顶级域(TLD --- top lever domains)
    • 通用的(generic) --- com、edu、gov、mil、net、org、firm、hsop、web。。。
    • 国家的(countries) --- cn、us、nl、jp。。。。
  • 每个域或子域可划分为若干子域(subdomains)
  • 树叶是主机
  • 域名
    • 域的域名可用用来表示一个域,主机的域名表示一个域上的一个主机
    • 一个域管理其下的子域,创建一个新的域,必须征得所属域的同意
  • 域与物理网络无关
    • 域遵从组织界限,而不是物理网络 -- 一个域的主机可以不再一个网络,一个网络的主机也不一定在一个域
    • 域的划分是逻辑的,而不是物理的

分布式设计

一个名字服务器存在的问题

  • 可靠性:单点故障
  • 扩展性:通信容量
  • 维护性:远距离的集中式数据库

区域(层次结构)

  • 区域的划分由区域管理者自己决定

  • 将DNS名字空间划分为互不相交的几个区域,每个区域都是树的一部分

  • 名字服务器

    • 每个区域都有名字服务器,维护着他所管辖区域的权威信息
    • 名字服务器允许被放置在区域之外,以保障可靠性(本地DNS服务器)
  • 层级

    • 根DNS服务器:因特网上有13个根DNS服务器,大部分分布在北美洲

    • TLD(顶级域)服务器:负责顶级域名

      • network solution公司维护com TLD服务器
      • educause公司维护edu TLD服务器
    • 权威DNS服务器:组织机构的DNS服务器,提供组织机构服务器(如Web、mail)可访问的主机和IP之间的映射,组织机构可以选择自己维护或由某个服务提供商来维护

    • 本地DNS服务器:不在层次结构中,每个ISP(居民区的ISP、公司、大学)都有一个本地的DNS服务器,也叫默认名字服务器

      • 本地DNS服务器通常邻近其所在网络的其他主机。
      • 当主机发出DNS请求时,该请求被发往本地DNS服务器,它起着代理的作用,并将请求转发到DNS服务器层次结构中

查询

名字解析过程

  • 先在Local Name Server中查找
    • 可能在该区域内部
    • 可能在缓存
  • 不在本地名字服务器,就找根服务器,TLD服务器,权威名字服务器

递归查询

image-20230823141110929

问题:根服务器负担太重

迭代查询

根DNS服务器不再返回查询的结果,而是返回下一个NS的地址,最后由权威名字服务器给解析出来

image-20230823141558511

记录

DNS服务器维护着资源记录(RR --- resource records)

  • 作用:维护 域名-IP地址(其它)的映射关系
  • 位置:Name Server的分布式数据库中
  • RR格式:(domain_name, ttl, type,class,Value)
    • Domain_name: 域名
    • Ttl: time to live : 生存时间(权威,缓冲记录)
    • Class 类别 :对于Internet,值为IN
    • Value 值:可以是数字,域名或ASCII串
    • Type 类别:资源记录的类型
typenamevalue举例
A主机域名对应的IP地址(Tayl.bar.foo.com, 145.37.93.126, A)
NS该域权威域名解析服务器的主机域名(fgcom, cins.foo.com, NS)
CNAME主机别名规范主机名(foo.com, relay1.bar.foo.com, CNAME)
MX主机别名邮件服务器的规范主机名(foo.com, mail.bar.foo.com, MX)

DNS协议报文

查询和响应报文的格式相同

image-20230823144529283

DNS报文有两种,即查询报文和回答报文,并且两种报文有着相同的结构:

  • 前12字节为首部区域。
    • 标识符indentification 是一个用来标记该查询的16比特数。该标志符会被复制到相应的回答报文里,以便匹配请求和回答;
    • 标志字段flags 有若干标志,用来指出报文的类型(请求还是响应)、查询类型(递归还是迭代)、是否是所请求名字的权威DNS服务器、以及4个有关数量的字段,用来指示4类数据区域出现的数量;
  • 问题区域:查询信息,包括名字字段、查询类型(即Name和Type)
  • 回答区域:对应的RR,可以包含多条RR,因此一个主机名能有多个IP地址
  • 权威区域:权威服务器的记录;
  • 附加区域:它有帮助的记录,比如在对于一个MX类型的请求回答报文里,回答区域里指出了邮件服务器的规范主机名,而附加区域里就有可能包含一个类型为A的关于该规范主机名的的IP地址;

新增

  • 在上级域的NS中增加两条记录,指向新增的子域域名和域名服务器地址
  • 在新增子域的NS上运行服务,负责本域的名字解析:名字->IP
  • 如到注册登记机构注册域名aaa.com
    • 需要向该机构提供权威DNS服务器(基本的和辅助的)的name和ip
    • 登记机构在com TLD服务器中插入两条RR记录
      • (aaa.com,dns1.aaa.com,NS)
      • (dns1.aaa.com,212.212.212.1,A)
    • 在aaa.com的权威服务器中可以插入两个记录
      • 用于Web服务器的www.aaa.com的类型为A的记录
      • 用于邮件服务器mail.aaa.com的类型为MX的记录

缓存

  • 一旦名字服务器学到了一个映射,就将该映射缓存起来
  • 根服务器通常都在本地服务器中缓存着,使得根服务器不用经常被访问
  • 目的:提高效率
  • 可能存在的问题:如果情况变化,缓存结果和 权威资源记录不一致
  • 解决方案:TTL(默认2天)

攻击

DDoS(distributed denial of service) ---- 效果一般(有缓存)

  • 对根服务器进行流量轰炸攻击:发送大量ping
    • 没有成功
    • 原因1:根目录服务器配置了流量过滤防火墙
    • 原因2:Local DNS 服务器缓存了TLD服务器的IP地址,因此无需查询根服务器
  • 向TLD服务器流量轰炸攻击:发送大量查询

重定向攻击 ---- 技术上较困难:分布式截获和伪造

  • 中间人攻击:截获查询,伪造回答,从而攻击某个站点(DNS回答指定IP)
  • DNS中毒:发送伪造的应答给DNS服务器,希望他能缓存虚假的结果

利用DNS基础设施进行DDos --- 效果有限

  • 伪造某个IP进行查询,攻击这个目标IP
  • 查询放大,响应报文比查询报文大

P2P架构

架构

  • 纯P2P架构 :

    • 没有(或极少)一直运行的 服务器;

    • 任意端系统都可以直接通信;

    • 利用peer的服务能力;

    • Peer节点间歇上网,每次IP 地址都有可能变化

  • 非结构化P2P :

    • 集中化目录 :有一个中心服务器负责记录共享信息(索引信息)并应答对这些信息的查询
    • 完全分布式:采用了随机图的组织方式来形成松散的网络,没有中心服务器,采用洪泛式搜索(Flooding)和随机转发机制(TTL转发机制)
    • 混合分布式:第三代P2P,在分布式模式基础上,将用户节点按能力进行分类,使某些节点担任特殊的任务。首先索引节点的引入不直接连接有版权的资料,摆脱了版权问题。其次引入搜索节点,查询时,用户节点直接连接搜索节点,若搜索的结果不足100个,就向相临的搜索节点再发请求,若还不足,再继续扩散请求,直到所有的搜索节点都访问过
      • 用户节点:可以从索引节点处得到相临的搜索节点地址。
      • 搜索节点:处理搜索请求,要有128k以上的速度,从子节点中搜索文件列表。
      • 索引节点:速度快、内存大的节点,保存可以利用的搜索节点信息、搜集状态信息,并维护网络结构。
      • 索引节点也可以同时是搜索节点。用户节点可以选择三个搜索节点为父节点,并提交它的共享列表。一个父节点可以维护500个孩子节点。
  • 结构化p2p :结构化是对网络解决的管理方式,是一种逻辑上可以结构化查询,而不是物理连接的变动,结构化是为了搜索算法的快捷,一般相当于折半查找。

    • DHT(Distributed Hash Table分布式散列表)路由算法是通过分布式散列函数将输入的关键字唯一映射到某个节点上,然后通过特定路由算法和该节点建立连接。 --- DHT维护环or树的有序拓扑结构( 不断深入的过程)
    • 网络节点被分配唯一节点标识符(Node ID),资源对象通过散列运算产生唯一资源标识符(Object ID),且该资源存储在NID与之相等或相近的节点上,查询时,同样的方法定位到存储该资源的节点

对比

问题 : 从一个服务器向N个节点分发一个文件需要多长时间?下面对比客户机/服务器 和 P2P 文件分发时间。

  • $u_s$:服务器上传带宽,$u_i$:节点i的上传带宽,$d_i$:节点i的下载带宽

  • 对于客户机/服务器模式下的文件分发:

    • 服务器串行地发送N个副本,用时 $NF/u_s$,

    • 客户机 i 需要 $F/d_i$ 时间下载。

    • 则最小的分发时间 $d_{cs} = max{NF/u_s,F/min(d_i)}$,

    • 随着N线性增长

  • 对于 P2P 模式的文件分发:

    • 服务器必须发送一个副本,用户 $F/u_s$,
    • 客户机 i 需要$F/d_i$ 时间下载,
    • 总共需要下载 NF 比特,最快的可能上传速率为$ u_s + ∑u_i$。
    • 则最小的文件分发时间 $d_{P2P} = max { F/u_s,F/min(d_i),NF/(u_s + ∑u_i)}$
    • 随着N增长,无限趋近于$F/u_{i均}$

若$F/u_i = 1h$,$u_s = 10u_i$,$d_{min} ≥ u_s$,则P2P理论极限是小于1小时

image-20230824132003787

BitTorrent

  • BitTorrent 是一种用于文件分发的流行P2P协议;(即bt种子)
  • 文件被分为一个个块256KB
  • 网络中的这些peers发送接收文件块,相互服务
  • 洪流(torrent):参与一个特定文件分发的所有对等方的集合;
  • 在一个洪流中的对等方彼此下载等长度的文件块;
  • 通过**位图(bitmap)**记录文件块的拥有情况,全0就是刚加入,全1就是种子
  • 当一个peer加入到洪流时,一开始没有块(位图全0),通过其他节点积累块
  • 每个洪流都有一个追踪器(tracker),新peer向跟踪器注册,获得peer节点列表,然后和部分peer节点构成邻居关系(连接),并周期性通知追踪器仍在洪流中
  • 扰动(churn):每个peer可能上线或者下线
  • 当一个对等方下载文件块的时候,同时也向其他对等方发送了多个块
  • 请求节点的策略:最稀缺优先(rarest Erst)。这种技术的思路是,针对她没有的块在她的邻居中决定最稀缺的块(数量最少的块),并首先请求那些最稀缺的块。这样,最稀缺块得到更为迅速的重新分发,其目标是均衡每个块在洪流中的副本数量。
  • 一旦某对等方获得了完整文件,就可以自私地离开洪流或者大公无私地留下来继续向其他对等方发送文件

举例说明:

注册

Alice加入某洪流时,会在追踪器里进行注册,周期性通知追踪器它仍在洪流中。我们称所有与Alice成功的创建了一个TCP链接的对等方成为邻近对等方。

请求块

  • 洪流随机从参与对等方的结合中选择一个子集,将他们的IP地址发给Alice,Alice维护这张对等方列表,试图与所有对等方建立并行的TCP连接。
  • Alice周期询问每个邻近对等方(连上的)他们有的文件块列表,她随时知道邻居有哪些文件块。
  • Alice向peer节点请求他希望的,稀缺的块

发送块

  • 从向他传送最快的4个邻居那里获取文件块。

    • 其他peer被阻塞,将不会从Alice处获得服务
    • 每10s重新评估一次,选出top4
  • 优化疏通:每过30s,Alice也要随机选择另外一个对等方Bob,向他发送块。若Alice是Bob最快的前四快,Bob也是Alice的前4快,则Bob和Alice互相发送数据。每过30s换一个新的对象,互相交换数据(一报还一报),为了使对等方能够找到彼此协调的速率上传。

资源定位

集中式

有一个中心服务器负责记录共享信息(索引信息)并应答对这些信息的查询

  • 单点故障
  • 性能瓶颈
  • 侵犯版权

泛洪(完全分布式)

  • flooding:查询一个节点,下一个节点会查询周围的所有节点,以此类推,直到遍布网络

  • 问题:会出现重复查询

  • 解决:TTL

  • Guntella协议

    • 在已有的TCP连接上发送查询报文

    • 对等方转发查询报文

    • 以反方向返回查询命中的报文

  • 对等方加入

    • 新加入节点X,先发现在覆盖网络中的其他对等方,并维护一张对等方列表(经常开机的对等方IP),在集中式的架构中是找跟踪器要的
    • 尝试与列表上的对等方建立TCP连接,直到与其中一个Y建立连接
    • X向Y发送一个ping报文,Y转发该报文
    • 所有收到Ping报文的对等方响应Pong报文 --- IP地址、共享文件的数量、总字节数
    • X收到许多Pong报文,然后他能建立其他TCP连接
  • 对等方离开:也需要告知,然后再找一个节点补充,保持网络的容量

KaZaA

利用不均匀性:KaZaA

  • 每个对等方要么是一个组长,要么隶属一个组

    • 对等方与组长之间有TCP连接,组长之间有TCP连接
  • 组长跟踪孩子节点的内容

  • 组长与组长联系

    • 转发到其他组长
    • 获得其他组长的数据拷贝
  • 查询

    • 每个文件有一个散列标识码和描述符

    • 客户端向其他组长发送关键字查询

    • 组长用匹配进行响应:对每个匹配 --- 元数据、散列标识码、IP地址

    • 如果组长将查询转发给其他组长,其他组长也以匹配进行响应

    • 客户端选择要下载的文件:向拥有文件的对等方发送一个散列标识码的HTTP请求

    • 请求队列

      • 限制并行上载的数量

      • 确保每个被传输的文件从上载节点接收一定量的带宽

    • 激励优先权

      • 鼓励用户上载文件
      • 加强系统可扩展性
    • 并行下载

      • 从多个对等方下载同一个文件的不同部分
      • HTTP的字节范围首部
      • 更快的检索一个文件

CDN

视频流化服务

  • 流量大、用户多、异构性

    • 不同用户拥有不同的能力(如:有线接入和移动用户、带宽丰富和受限用户)
    • 解决方案:分布式的,应用层的基础设施
  • 多媒体视频

    • 视频:固定速度显示的图像序列
    • 网络视频特点
      • 高码率:大于10倍音频,高的网络带宽需求
      • 可被压缩
      • 90%以上的网络流量是视频
    • 数字化图像:像素的阵列 --- 每个像素被若干 bits 表示
    • 编码:使用图像内和图像间的冗余来降低编码的比特数
      • 空间冗余:图像内(压缩举例:不发生n个相同的颜色,改为发送两个值 --- 颜色,重复的个数)
      • 时间冗余:相邻图像间(压缩举例:仅发送与前1帧有差别的地方)
  • 由于存储下载视频 是一对一的关系,则下载未免有些慢了,于是就有了存储视频的流化服务

  • 多媒体流化服务:DASH

    • DASH:Dynamic Adaptive Streaming over HTTP

    • 服务器

      • 将视频文件分割成多个块
      • 每个块独立存储,编码于不同码率(8-10种)
      • 告示文件(manifest file):提供不同块的url
    • 客户端

      • 先获取告示文件
      • 周期性地测量服务器到客户端的带宽
      • 查询告示文件,在一个时刻请求一个块,HTTP头部指定字节范围
        • 如果带宽足够,选择最大码率的视频块
        • 会话中不同时刻,可以切换请求不同的编码块(取决于当时的可用带宽)
    • 智能客户端:客户端自适应决定

      • 什么时候去请求块(不至于缓存挨饿或者溢出)

      • 请求什么编码速率的视频块(当带宽足够用时,请求高质量的视频块)

      • 哪里去请求块(可以向离自己近的服务器发送url,或者向高可用带宽的服务器请求)

CND

挑战:服务器如何通过网络向百万用户同时提供流视频服务

  • 选择1:单个的,大的超级服务中心 -- mega-server
    • 服务器到客户端路径上跳数较多,瓶颈链路带宽小导致停顿
    • 二八定律决定了网络同时充斥着同一个视频的多个拷贝,效率低(付费高、带宽浪费、效果查)
    • 单点故障
    • 周边网络的拥塞
  • 选择2:通过CDN,全网部署缓存节点,存储服务内容,就近为用户提供服务,提高用户体验
    • enter deep:将CND服务器深入到许多接入网
      • 更接近用户,数量多,离用户近,管理困难
      • Akamai,1700个位置
    • bring home:部署在少数的关键位置(10个左右),如将服务器簇安装于POP附近(离若干1st ISP POP较近)
      • 采用租用线路将服务器簇连接起来 ---- LimeLight(提供商)
  • Content Distribution Networks 内容分发网络

  • CDNs

    • 在CDN节点中存储内容的多个拷贝

    • 用户从CDN中请求内容

      • 重定向到最近的拷贝,请求内容

      • 如果网络路径拥塞,可以选择不同的拷贝

    • OTT挑战:在拥塞的互联网上复制内容 (over the top)

      • 从哪个CDN节点中获取内容?
      • 用户在网络拥塞时的行为?
      • 在哪些CDN节点中存储什么内容?
  • 简单的访问场景 --- Bob客户端请求视频 http://aaa.com/Aahasajk,视频存储在CDN http://kingCDN.com/juaAi

    • 流量服务器返回web页面资源地址 http://aaa.com/Aahasajk
    • 向本地DNS服务器请求解析,找到权威DNS服务器(netcinema’s authorative DNS),可能需要往顶级DNS找
    • 权威DNS服务器返回给本地DNS服务器CDN的URL -- http://kingCDN.com/juaAi,告诉它最近的服务端地址
    • 通过CDN簇选择策略(经过KingCDN的权威DNS --- authoritative DNS),向客户端提供流化服务
  • Netflix(网飞)案例

    • 服务器提前将多个版本的影片上载至CNDs(如Akamai CND、Limelight CND、Level-3 CND)
    • Bob浏览网飞视频,向Amazon Cloud服务器发起请求
    • 为请求的视频 DNS 解析缓存返回的清单文件
    • 请求CDN提供的DASH流化服务

Socket编程

2种传输层服务的socket类型:

  • TCP: 可靠的、字节流的服务
  • UDP: 不可靠(数据UDP数据报)服务

TCP套接字

  • 套接字:应用进程与端到端传输协议(TCP或UDP)之间的门户
  • TCP服务:从一个进程向另一个进程可靠地传输字节流
image-20230831162001137
  • 通信流程:从应用程序的角度,TCP在客户端和服务器进程之间提供了可靠的、字节流(管道)服务

    • 服务器进程必须先处于运行状态

      • 创建welcomeSocket(相当于java中的ServerSocket)
      • 和本地端口捆绑
      • 在欢迎socket上阻塞式等待接收用户的连接
    • 创建客户端本地套接字(隐式捆绑到本地port)

      • 指定服务器进程的IP地址和端口号,与服务器进程连接
    • 当与客户端连接请求到来时

      • 服务器解除阻塞式等待,返回一个新的socket((相当于java中的Socket)),与客户端通信
      • 允许服务器与多个客户端通信
      • 使用源IP和源端口来区分不同的客户端
    • 连接API调用有效时,客户端P与服务器建立了TCP连接

    image-20231009163601997
  • Socket底层就是个整数,代表一个会话关系

  • 端口的 绑定 ≠ 共用

    • 一个端口只能被绑定一次
    • 被绑定的端口可以被多个进程共用(发送或接收)

数据结构

sockaddr_in --- IP地址和port捆绑关系的数据结构(标示进程的端节点)

struct sockaddr_in {
    short sin_family; 			// AF_INET(是 IPv4网络协议的套接字类型)
    u_short sin_port; 			// port
    struct in_addr sin_addr ;	// IP address, unsigned long
    char sin_zero[8]; 			// align对齐
};

hostent --- 域名和IP地址的数据结构

作为调用域名解析函数时的参数 返回后,将IP地址拷贝到sockaddr_in的IP地址部分

struct hostent{
    char *h_name;				//主机域名
    char **h_aliases;			//数组存储 主机别名  
    int h_addrtype;				
    int h_length; 				/*地址长度*/
    char **h_addr_list;			// 数组存储 IP地址
    #define h_addr h_addr_list[0];
}

UDP套接字

  • UDP提供的是一种不可靠的数据流传输,传输过程中可能会丢包,接收的时候顺序也可能被打乱。

  • 在客户端和服务器之间没有连接

  • 没有握手

  • 发送端在每一个报文中明确地指定目标的IP地址和端口号

  • 服务器必须从收到的分组中提取出发送端的IP地址和端口号

image-20231009165500987

传输层

传输服务和协议

  • 为运行在不同主机上的应用进程提供逻辑通信

  • 传输协议运行在端系统

    • 发送方:将应用层的报文分成报文段,然后传递给网络层

    • 接收方:将报文段重组成报文,然后传递给应用层

  • 传输层 vs 网络层

    • 网络层服务:主机之间的逻辑通信
    • 传输层服务:进程间的逻辑通信
      • 依赖于网络层服务 --- 延时、带宽
      • 并对网络层的服务进行增强 --- 数据丢失、顺序混乱、加密
        • 有些服务可以加强,如不可靠 -> 可靠,不安全 -> 安全
        • 有些服务不能加强,如延时、带宽
    • 类别两家庭通信
      • A家的12个小孩和B家的12个小孩写信
      • 主机 --- 家庭
      • 进程 --- 小孩
      • 应用层报文 --- 信件
      • 传输层协议 --- A 和 B ---- 为家庭小孩提供复用解复用服务
      • 网络层协议 --- 邮局服务 ---- 家庭到家庭之间邮件传输服务
  • Internet传输层协议

    • 可靠的、保序的传输:TCP
      • 多路复用、解复用
      • 拥塞控制
      • 流量控制
      • 建立连接
    • 不可靠、不保序的传输:UDP
      • 多路复用、解复用
      • 没有为尽力而为的IP服务添加更多的其他额外服务
    • 都不提供的服务
      • 延时保证
      • 带宽保证

多路复用

在发送方主机多路复用

  • 从多个套接字接收来自多个进程的报文,根据套接字对应的IP和端口,对报文段用头部加以封装(头部信息用于解复用)
  • 复用指的是,多个应用层应用使用一个传输层传数据:应用层 -> 传输层(在传输层复用,加上头给底层)

在接收方主机多路解复用

  • 根据报文段的头部信息中的IP地址和端口,将接收到的报文段发给对应的套接字(即对应的进程)
  • 解复用指的是,传输层把不同的数据正确交付给不同的应用:传输层 -> 应用层(在应用层解复用,根据头找进程)

简单说

  • 多个应用请求同一个ip和端口(如:浏览器+下载器)
  • 多个应用对应多个端口,但是只会建立一个TCP连接
  • 当浏览网页时也可以同时下载文件,而且你不会感到阻塞或延迟
  • 再者,一个请求在传输层会将数据分割成小的数据包,通过一个TCP连接发送,在接收端重新组装
  • 传输层多路复用使得多个应用程序可以在同一个连接上并发地传输数据,从而提高了网络的效率和吞吐量。

UDP多路解复用

  • 服务端创建套接字,绑定端口(UDP和TCP不同),客户端需要知道端口才能给服务端发送数据报

  • 客户端创建套接字,没有Bind,不需要显式绑定端口,操作系统会为之分配某个端口号捆绑(客户端使用什么端口号无所谓,客户端主动找服务器)

  • 在接收端,UDP套接字用二元组标识(目标IP、目标端口)

    • 当主机收到UDP报文段,操作系统会检查报文段的目标端口号,用该端口号将报文段定位给套接字
    • 如果两个不同源IP/不同源端口的数据报,但是有相同的目标IP和端口,则被定为到相同的套接字

TCP多路复用

  • TCP套接字用四元组本地标识:源IP、源端口、目标IP、目标端口

  • 解复用:接收端用四元组将数据报定位到合适的套接字

  • 服务端能在一个TCP端口上支持多个TCP套接字,每个套接字由四元组标识

  • Web服务器对每个连接客户端有不同的套接字

    在Web服务器中,通常会为每个与客户端的连接创建一个不同的套接字。这是因为HTTP是一种无状态协议,每个请求/响应周期都是相互独立的。通过为每个请求创建一个独立的套接字,可以更好地分离和管理每个连接的状态信息,确保每个请求都是独立进行处理的。

UDP

  • “no frills”, “base bones” ---- 基本的传输协议
  • 报文段可能丢失、乱序
  • 无连接 --- 没有握手、每个报文段都被独立的处理
  • 主要用于流媒体、DNS、SNMP
  • 在UDP上进行可靠传输,需要在应用层增加可靠性,应用特定的差错恢复

UDP相对网络层的IP协议,增加了复用解复用和简单的错误校验,几乎没有再增加其他的了

为什么要求UDP

  • 无需建立连接 (减少延迟)。这也可能是DNS使用UDP而不是TCP的主要原因,如果使用TCP的话,DNS服务将会慢很多
  • 无需维护连接状态:TCP为了实现可靠数据传输和拥塞控制需要在端系统中维护一些参数,这些参数包括:接收和发送的缓存、拥塞控制参数、确认号和序号;这些参数信息都是必须的;而UDP因为不建立连接,所以自然也就不需要维护这些状态,这就减少了时空开销;
  • 分组首部更小:TCP20字节的首部开销,而UDP只有8字节;
    • UDP首部只有4个字段,每个字段占用两个字节,分别是:源端口号、目的端口号、长度和校验和
    • 长度字段指示了在 UDP 报文段中的字节数(首部加数据)。
    • 接收方使用检验和来检查在该报文段中是否出现了差错。
  • 无拥塞控制和流量控制:UDP可以尽可能快的发送报文段 --- 应用层 --> 传输层的速率= 主机 --> 网络层的速率

UDP校验和

  • 目标:检测在被传输报文段中的差错(如比特反转)
  • 计算过程
    • 计算伪首部 = 源IP地址(4字节) + 目标IP地址(4字节) + 协议类型(2字节UDP的值为17) + UDP长度(2字节)
    • 将伪首部拼接到UDP数据报文前,伪首部 + UDP首部(8字节) + 数据
    • 分成若干16位的字节对,进行二进制求和
    • 溢出回卷
    • 按位取反即可得到校验和
  • 只能检错,不能纠错,发生错误就丢弃

可靠数据传输

rdt在应用层、传输层和数据链路层都很重要,是网络Top 10 问题之一

信道不可靠的特点决定了可靠数据传输协议(rdt)的复杂性

与不可靠信道之间的函数调用都是双向的,由于其不可靠性,需要进行确认的控制信号(ACK,NAK)

有限状态机(Finite State Machine,FSM)是一种数学模型,用于描述系统或计算机程序的行为。它由一组状态、状态之间的转换规则以及输入和输出组成。

  • 在FSM中,系统或程序可以处于一系列预定义的状态之一
  • 状态转换由预定义的规则控制,这些规则描述了在给定的输入条件下,系统将从一个状态转移到另一个状态的方式

Rdt1.0: 在可靠信道上的可靠数据传输

  • 假设下层的信道是一个完全可靠的信道(理想情况)--- 没有错误,没有丢失

发送方FSM状态:

  • 等待数据 ---- 上层的调用rdt_send(data);packet = make_pkt(data);udt_send(packet)

    发送方首先在“等待上级调用”的状态,rdt_send(data)上级调用rdt,从上级接收到data,make_pkt(data)将data装到packet里,再用udt_send(packet)将packet发送出去,完成后发送方再回到“等待上级调用”的状态

接收方FSM状态:

  • 等待数据 ---- 下层的调用rdt_rcv(packet);extract (packet,data);deliver_data(data)

    接收方首先在“等待下级调用”的状态,rdt_rcv(packet)下级调用rdt,从下级接收到packet,用extract(packet, data)将packet重新恢复成data,提取出来的data再通过deliver_data(data)传送给上级。完成后接收方再回到“等待下级调用”的状态

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

采用差错控制编码进行差错检测

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

发送方FSM状态:

  • 等待数据 ---- 上层的调用rdt_send(data);packet = make_pkt(data);udt_send(packet)

  • 等待确认(Waiting for Acknowledgement):发送方已发送数据包,并等待接收到确认消息

    发送方最初处于“等待上级调用”的状态,rdt_send(data)上级调用rdt,从上级接收到data,sndpkt = make_pkt(data, checksum)将data装到packet里,再用udt_send(sndpkt)将packet发送出去。此时,发送方变为“等待ACK或NAK”的状态。rdt_rcv(rcvpkt)接收反馈,如果isNAK(rcvpkt)即接收到NAK,则重传udt_send(sndpkt),并保持“等待ACK或NAK”的状态;如果isACK(rcvpkt)即接收到ACK,则回到“等待上级调用”的状态。

接收方FSM状态:

  • 等待数据 ---- 下层的调用rdt_rcv(packet);extract (packet,data);deliver_data(data)

    接收方首先在“等待下级调用”的状态,rdt_rcv(rcvpkt)接收方接收packet,如果corrupt(rcvpkt),即检测到错误,则udt_send(NAK)反馈NAK;如果notcorrupt(rcvpkt),即未检测到错误,则extract(packet, data)将packet重新恢复成data,deliver_data(data)将data传送给上级,最后udt_send(ACK)反馈ACK。完成后接收方再回到“等待下级调用”的状态。

image-20231016154434375

rdt2.0的致命缺陷!-> rdt2.1

ACK/NCK出错

  • 发送方不知道接收方的状态,所以发送方不知道接下来怎么操作
    • 重传 --- 可能重复
    • 不重传 --- 可能死锁或出错
  • 引入新机制 --- 序号
  • 处理重复
    • 发送方在每个分组中加入序号
    • 如果ACK、NCK出错,发送方重传当前分组
    • 接收方丢弃重复分组
    • 停止等待协议(Stop and Wait):发送一个分组就等待接收方应答
上次编辑于:
贡献者: ext.liyuanhao3,李元昊