精华内容
下载资源
问答
  • 2019-11-24 21:41:55

    可靠数据传输协议-GBN 协议的设计与实现

    首先最重要的代码:github地址

    一、 实验目的

    理解滑动窗口协议的基本原理;掌握 GBN 的工作原理;掌握基于 UDP 设计并实现一个 GBN 协议的过程与技术。

    二、 实验内容

    实现了GBN协议,模拟丢包,并支持双向传输,并改进为了SR协议

    1. 基于UDP设计一个简单的GBN协议,实现单向可靠数据传输(服务器到客户的数据传输)。
    2. 模拟引入数据包的丢失,验证所设计协议的有效性。
    3. 改进所设计的 GBN 协议,支持双向数据传输;(选作内容,加分 项目,可以当堂完成或课下完成)
      4)将所设计的 GBN 协议改进为 SR 协议。( 选作内容,加分项目, 可以当堂完成或课下完成)

    三、实验过程及结果

    1. 流程:首先client端将需要发送的文件解析成byte数组,调用send发送server端使用receive接收,当数据传输结束后server端利用在之前receive获取的port和address使用重载的send方法返回数据,client直接调用receive即可。
      其中定时器采用多线程,没发送一个都启用一个定时间线程,并将发送的socket,packet,序列号等传入,启动线程即使其sleep,当超多时间后判断是否接收到ack,没有则重传并再次启动定时器。
      对ack的接收也使用多线程处理,使其发送的同时可以接收。
      需要注意的是由于多个线程都用到了ackMap(记录接收ack状况的map)所以需要使用线程安全的ConcurrentHashMap
    2. 数据分组格式
      Length	Seq	Data	End
      Length:数据长度,2字节,<=1024;
      Seq:序列号,1字节,0 ~ 255;
      Data:数据,最大1024自己;
      End:结尾标志,1字节,0表示结尾,1表示非结尾
    3. 确认分组格式
      Seq	End
      Seq:序列号,1字节,0 ~ 255;
      End:结尾标志,1字节,0表示结尾,1表示非结尾
    4. 协议两端程序流程图
      在这里插入图片描述
    5. 协议典型交互过程
      发送方的事件与动作:
      • 从上层收到数据。当从上层接收到数据后,SR 发送方检查下一个可用于该分组的序号。如果序号位于发送方的窗口内,则将数据打包并发送;否则就像在 GBN 中一样,要么将数据缓存,要么将其返回给上层以便以后传输。
      • 超时。定时器再次被用来防止丢失分组。然而,现在每个分组必须拥有其自己的逻辑定时器,因为超时发生后只能发送一个分组。
      • 收到ACK。如果收到 ACK,倘若该分组序号在窗口内,则 SR 发送方将那个被确认的分组标记为已接收。若该分组的序号等于 send_base,则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且有序号落在窗口内的未发送分组,则发送这些分组。
      接收方的事件与动作:
      • 序号在 [rcv_base, rcv_base+N-1] 内的分组被正确接收。在此情况下,收到的分组落在接收方的窗口内,一个选择 ACK 被回送给发送方。如果该分组以前没收到过,则缓存该分组。如果该分组的序号等于接收端的基序号(rcv_base),则该分组以及以前缓存的序号连续的(起始于 rcv_base 的)分组交付给上层。然后,接收窗口按向前移动分组的编号向上交付这些分组。
      • 序号在 [rcv_base-N, rcv_base-1] 内的分组被正确收到。在此情况下,必须产生一个 ACK,即使该分组是接收方以前确认过的分组。
      • 其他情况。忽略该分组。
    6. 数据分组丢失验证模拟方法
      设置数据包丢失率和ACK丢失率,使用Math.random生成0到1的随机数,只有当生成的随机数大于丢失率时才发送数据或ACK
      private static double sendLoss = 0.1;
      private static double recvLoss = 0.05;
    7. 程序实现的主要类(或函数)及其主要作用
      1)Server:服务器端,首先接收客户端发送的数据,之后发送数据给客户端
      2)Client:客户端,首先发送数据给服务器端,然后接收服务器返回的数据
      3)RecvAck:接收ack,继承自thread,参数为ackMap,datagramSocket。使用新的线程接收ack,注意要设置阻塞时间,否则接收完成后会阻塞住,ackMap的size为0并且收到ack的end为0时代表接收完成。注意当倒数几个有重发时,虽然接到了end是0但不是终止,所以要两个条件一起判断。
      4)TimeOut:定时器类,继承自thread,参数有datagramSocket,datagramPacket,sequence。每发送一个数据则启动一个定时器,睡眠100ms,之后判断是否接受到ack,没接受到则重传,并重新启动定时器
      5)PublicMethod:一些公共的方法,因为实现了双向数据传输,客户端与服务器端逻辑基本相同,都放在了公共方法里,其也是程序的重点,重要代码处理逻辑都在其中。
      a)ByteArrayOutputStream getByteArray(File file) :将要传输的文件转化成ByteArrayOutputStream方便以后传输时转化成数组处理
      通过FileInputStream读入文件并将其写入ByteArrayOutputStream
      b)void send(DatagramSocket socket, byte[] sendBytes, InetAddress address, int targetPort):client端发送函数,参数为UDP的socket,要传输的数据,目的地址,目的端口号。
      使用ackMap记录已经发送的分租收到ack的情况,创建RecvAck对象并start启动接收ack线程,注意必须使用线程安全的ConcurrentHashMap(开始没有发现,经常出现null,debug巨久),当其收到连续的ack时滑动窗口到第一个未收到ack的位置。可以发送的窗口大小为窗口大小减去ackMap的大小,接下来开始发送数据,按上面的数据格式创建报文,并发送,序列号最大为255,注意要循环序列号,之后发送报文并启动定时器线程,将socket和ackMap,packet,sequence传送给定时器并启动。当全部发送且ackMap里面没有数据时终止。
      c) byte[] receive(DatagramSocket socket):接受函数,参数为接受的socket,以byte数组返回接收到的数据。
      使用ByteArrayOutputStream存放接收到的数据,通过datagramSocket的receive接受数据,并获取其中的长度,序列号,是否结束。注意要判断收到序列号所在的位置,由于序列号是循环的,[rcv_base, rcv_base+N-1]和[rcv_base-N, rcv_base-1]的大小可能不同要进行分析。第二种情况发送只ack即可,第一种如果收到和base相同的则滑动接受窗口,不连续则缓存都要发送ack。都不满足则无需处理。当接接收超时时证明接收完成退出循环。(因为发送的ack可能没有到达所以不好用是否接收到全部数据判断,否则对面可能未接到ack而server已关闭不发送ack使对面陷入无限重传)
      d) void send(DatagramSocket socket, byte[] sendBytes):server端的发送函数,参数只有socket和数据,实际为客户端socket的重载,其中目的地址和目的端口号有receive函数中解析出来,由于server端先接受,首先调用receive方法时即可获取targetPort和address。
      处理逻辑与client的send相同
      e) void recvByteMethod(FileOutputStream fileOutputStream, DatagramSocket socket):接受数据函数,使用wile(true)循环使得可以一直处于接受状态,否则必须在server开始后再启动client也可以防止server端回传数据时client已关闭的问题。
    更多相关内容
  • 相当于TCP的稳定性来说,UDP因为其数据传输的不可靠性,所以用在某些特定的场合,如直播、广播消息、视频音频流处理等不太需要校验数据完整性的场合。 UDP相对TCP协议而言,其特点就是简洁,它删除了在TCP协议中为了...

    简介

    简单就是美。在网络协议的世界中,TCP和UDP是建立在IP协议基础上的两个非常通用的协议。我们现在经常使用的HTTP协议就是建立在TCP协议的基础上的。相当于TCP的稳定性来说,UDP因为其数据传输的不可靠性,所以用在某些特定的场合,如直播、广播消息、视频音频流处理等不太需要校验数据完整性的场合。

    UDP相对TCP协议而言,其特点就是简洁,它删除了在TCP协议中为了保证消息准确性的各种限制性特征。简洁带来的好处就是快!今天给大家讲解一下,基于UDP的高速数据传输协议UDT。

    UDT协议

    UDP因为其简单的特性,所以可以做到很多TCP做不到的事情,比如进行大数据量的快速传输。这里并不是要将TCP和UDP分个好坏高下,毕竟各个协议的适应场景不同,他们之所以流行,就是因为可以在特定的场景发挥出重要的作用。套用中国的一句谚语就是:不管白猫黑猫,能抓到老鼠的,就是好猫。

    用好UDP协议,我们就可以快速的传递大量的数据,这个协议就是UDT协议。

    话说,像这些基础协议都是老外发明的,而中国的互联网巨头都在抢着做平台、做流量的生意,真的是无话可说…

    UDT项目开始于2001年,是由Yunhong Gu在芝加哥伊利诺伊大学国家数据挖掘中心 (NCDM)读博士期间开发的,并在毕业之后持续的进行维护和升级改进。

    UDP的出现是因为那时候,传输更快更便宜的光纤网络出现了,代替了之前的铜缆线和双绞线,从而极大的提升了信息传输的效率。这时候大家就发现之前使用TCP协议来进行大数据的传输会有很大的问题。从而基于UDP的UDT协议出现了。

    UDT的第一个版本,也称为SABUL(Simple Available Bandwidth Utility Library),UDT通过支持批量数据传输,从而方便在私有网络中进行数据的传输。

    要注意的是UDT的第一个版本SABUL使用UDP协议进行传输数据,同时使用单独的TCP协议连接传输控制消息。

    UDT的初始版本是在超高速网络(1 Gbit/s、10 Gbit/s等)上进行开发和测试的,2003年10月,NCDM实现了从美国芝加哥到荷兰阿姆斯特丹的平均每秒6.8G比特的传输。在30分钟内的测试中,他们传输了大约1.4TB的数据。

    从2004年发布的2.0版本开始,SABUL改名为UDT,UDT的全称是UDP-based Data Transfer Protocol,也就是基于UDP的数据传输协议。

    为什么要改成UDT呢?因为在UDT2.0中,删除了SABUL中的TCP 控制连接,并使用UDP来处理数据和控制信息。 另外,UDT2还引入了一种新的拥塞控制算法,允许协议动态调整UDT和TCP流,实现UDT和TCP流的并发运行。

    在2006年,UDT协议升级到了3版本,该协议不仅是在私有网络中运行了,而是扩展到了商业互联网中。同时UDT3中的拥塞控制可以进行调整优化,可以在低带宽的环境中运行,并且允许用户轻松定义和安装自己的拥塞控制算法。另外,UDT3还显着减少了系统资源(CPU和内存)的使用。

    2007年,UDT4版本在高并发和防火墙穿透方面进行优化和性能的提升。UDT4允许多个UDT连接绑定到同一个UDP端口,它还支持集合连接设置,以便UDP hole punching。

    什么是UDP hole punching呢?

    UDP hole punching通常被用在网络地址转换 (NAT)中。用来维护穿越NAT的用户UDP数据包流。它是一种使用网络地址转换器在专用网络中的Internet主机之间建立双向UDP连接的方法。

    什么是NAT呢?

    大家都知道IPV4地址是有限的,很快IPV4地址就快用完了,那怎么解决这个问题呢?

    当然,一个永久解决的办法是IPV6,不过IPV6推出这么多年了,好像还没有真正的普及。

    不使用IPV6的话还有什么解决办法呢?

    这个办法就是NAT(Network Address Translators)。

    NAT的原理是将局域网的IP和端口和NAT设备的IP和端口做个映射。

    NAT内部维护着一张转换表。这样就可以通过一个NAT的IP地址和不同的端口来连接众多的局域网服务器。

    那么NAT有什么问题呢?

    NAT的问题在于,内部客户端不知道自己外网IP地址,只知道内网IP地址。

    如果是在UDP协议中,因为UDP是无状态的,所以需要NAT来重写每个UDP分组中的源端口、地址,以及IP分组中的源IP地址。

    如果客户端是在应用程序内部将自己的IP地址告诉服务器,并想跟服务器建立连接,那么肯定是建立不了的。因为找不到客户端的公网IP。

    即使找到了公网IP,任何到达NAT设备外网IP的分组还必须有一个目标端口,而且NAT转换表中也要有一个条目可以将其转换为内部主机的IP地址和端口号。否则就可能出现下图的连接失败的问题。

    怎么解决呢?

    第一种方式是使用STUN服务器。

    STUN服务器是IP地址已知的服务器,客户端要通信之前,先去STUN服务器上面查询一下自己的外网IP和端口,然后再使用这个外网IP和端口进行通信。

    但有时UDP包会被防火墙或者其他的应用程序所阻挡。这个时候就可以使用中继器技术Traversal Using Relays around NAT (TURN) 。

    双方都将数据发送到中继器server,由中继器server来负责转发数据。注意,这里已经不是P2P了。

    最后,我们有一个集大成者的协议叫做ICE(Interactive Connectivity Establishment ):

    它实际上就是直连,STUN和TURN的综合体,能直连的时候就直连,不能直连就用STUN,不能用STUN就用TURN。

    在使用STUN和ICE的过程中,我们会有一台网络主机用来建立端口映射和保持其他UDP端口状态,但是UDP的状态通常在几十秒到几分钟的短时间后过期,为了保证NAT中UDP的状态和生命周期,于是有了UDP hole punching的技术。通过定时传输keep-alive数据包,对NAT中的UDP状态进行更新。

    UDT的缺点

    因为UDT是基于UDP协议的,但是UDP协议因为其简洁的特性,所以并不具备安全性的特征。所以基于其上的UDT协议因为缺乏安全特性,所以在商业环境中应用会受到一定的限制。

    不过UDT的新版本已经在开发中,大家可以期待一下。

    总结

    UDT被广泛用于高性能计算,比如光纤网络上的高速数据传输。我们后续会在netty中告诉大家怎么使用UDT协议。

    本文已收录于 http://www.flydean.com/11-udt/

    最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现!

    欢迎关注我的公众号:「程序那些事」,懂技术,更懂你!

    展开全文
  • 数据传输协议汇总

    千次阅读 2021-04-09 09:14:22
    FTP(文件传输协议) 对于业务文件传输,FTP可能是第一个想到的。 FTP是为单个文件传输和批量文件传输而构建的。它已经存在了一段时间,因此您可能不会在互操作性方面遇到问题。这意味着,您的贸易伙伴将永远有很大的...

    一、FTP(File Transfer Protocol 文件传输协议)

    目前在网络上,如果你想把文件和其他人共享。最方便的办法莫过于将文件放 FTP 服务器上,然后其他人通过 FTP 客户端程序来下载所需要的文件。
    FTP 是 TCP/IP 网络上两台计算机传送文件的应用层协议,如同其他的很多通讯协议,FTP 通讯协议也采用客户机 / 服务器(Client / Server )架构。用户可以通过各种不同的FTP客户端程序,借助FTP协议,来连接FTP服务器,以上传或者下载文件。

    (一)FTP 通讯端口

    FTP 服务器和客户端要进行文件传输,就需要通过端口来进行。FTP 协议要用到两个 TCP(Transmission Control Protocol 传输控制协议) 连接端口:

    1. 控制链路(也叫命令链路,TCP 端口 21)
      用来在 FTP 客户端与服务器之间传递命令,所有你发往FTP服务器的命令和服务器反馈的指令都是通过服务器上的 21 端口传送的。

    2. 数据链路(TCP 端口 20 或者 22)
      数据链路主要是用来传送数据的,比如客户端上传、下载内容,以及显示服务端目录的内容等

    (二)FTP 支持两种连接模式

    FTP 服务器为了适应不同的网络环境,支持两种连接模式:主动模式(Port)和被动模式(Pasv)。其实这两种连接模式主要是针对数据链路进行的,和控制链路无关。

    1. Standard (Port 模式,主动模式)
      主动模式是这样工作的:
      客户端把自己的高位端口(大于1024的端口都就叫高位端口,1024以前的端口都已经预先被定义好,被一些典型的服务使用,当然有的还没使用,保留给以后会用到这些端口的资源服务。)和服务器端口 21 建立控制链路(即控制通道)。所有的控制命令(Is、 get、put 等)都是通过这条链路传送的。
      当客户端需要服务器端给它传送数据时(例如:查看服务端的文件和目录,从服务端下载资源等),客户端会发消息(即 Port 指令)给服务器端,告诉自己的位置和打开的高位端口(该端口用于接收从服务端传输过来的数据),当服务器端收到客户端发送过来的 Port 指令后,就主动通过 TCP 端口 20 和客户端在 Port 指令中指定的端口连接,从而进行数据的传输,这样数据链路就建立起来了。
      采用主动模式连接 FTP 服务器的客户端,当它位于NAT或者防火墙的保护时会碰到连接失败的问题,这是因为当防火墙接到服务器发送过来的信息的时候,并不知道应该发送给内部网络中的哪一台客户端造成的。
      注意:客户端与服务端都是先连接(即先建立好信息传输通道)再传输数据

    2. Passive (Pasv 模式,被动模式)
      被动模式是这样工作的:
      当客户端发送 Pasv 指令给服务端,服务端收到 Pasv 指令后,会打开一个临时端口(端口号大于 1023 小于 65535),接着服务端发信息给客户端,通知客户端在这个临时端口上发起传输数据的请求(服务器很礼貌地告诉客户端:我为您临时打开了一个端口,您现在来连接我吧!)。当客户端收到该信息后,就主动(注意:服务端是被动的)去连接 FTP 服务器端的端口,连接成功后,数据链路就建立了。

    从上面的解释中我们可以看到,两种模式主要的不同是数据连接建立的不同。对于 Port 模式,是客户端在本地打开一个端口等服务器去连接建立数据连接,而 Pasv 模式就是服务器打开一个端口等待客户端去建立一个数据连接。

    在实际中,我们应该选择哪种模式呢?

    由于防火墙的原因,外网的服务器是无法访问内网的PC的。当我们的服务器部署到外网,设备在内网的时候。我们必须使用被动模式。

    (三)缺点

    1. FTP 容易受到防火墙问题的影响, 这可能会对客户端连接产生不利影响
    2. FTP 传输的数据是明文的,所以无法确保数据的安全
    3. FTP有着极高的延时,这意味着从开始请求到接收数据的时间会非常长

    (四)FTP 命令

    ftp> ascii # 设定以ASCII方式传送文件(缺省值)
    ftp> bell # 每完成一次文件传送,报警提示
    ftp> binary # 设定以二进制方式传送文件
    ftp> bye # 终止主机FTP进程,并退出FTP管理方式
    ftp> case # 当为ON时,用MGET命令拷贝的文件名到本地机器中,全部转换为小写字母
    ftp> cd # 同UNIX的CD命令
    ftp> cdup # 返回上一级目录
    ftp> chmod # 改变远端主机的文件权限
    ftp> close # 终止远端的FTP进程,返回到FTP命令状态, 所有的宏定义都被删除
    ftp> delete # 删除远端主机中的文件
    ftp> dir [remote-directory] [local-file] # 列出当前远端主机目录中的文件.如果有本地文件,就将结果写至本地文件.
    ftp> get [remote-file] [local-file] # 从远端主机中传送至本地主机中
    ftp> help [command] # 输出命令的解释
    ftp> lcd # 改变当前本地主机的工作目录,如果缺省,就转到当前用户的HOME目录
    ftp> ls [remote-directory] [local-file] # 同DIR
    ftp> macdef # 定义宏命令
    ftp> mdelete [remote-files] # 删除一批文件
    ftp> mget [remote-files] # 从远端主机接收一批文件至本地主机
    ftp> mkdir directory-name # 在远端主机中建立目录
    ftp> mput local-files # 将本地主机中一批文件传送至远端主机
    ftp> open host [port] # 重新建立一个新的连接
    ftp> prompt # 交互提示模式
    ftp> put local-file [remote-file] # 将本地一个文件传送至远端主机中
    ftp> pwd # 列出当前远端主机目录
    ftp> quit # 同BYE
    ftp> recv remote-file [local-file] # 同GET
    ftp> rename [from] [to] # 改变远端主机中的文件名
    ftp> rmdir directory-name # 删除远端主机中的目录
    ftp> send local-file [remote-file] # 同PUT
    ftp> status # 显示当前FTP的状态
    ftp> system # 显示远端主机系统类型
    ftp> user user-name [password] [account] # 重新以别的用户名登录远端主机
    ftp> ? [command] # 同HELP. [command]指定需要帮助的命令名称。如果没有指定 command,ftp 将显示全部命令的列表
    ftp> ! # 从 ftp 子系统退出到外壳
    

    常用命令:

    ftp> get readme.txt # 下载文件
    ftp> put readme.txt # 上传文件
    

    (五)FTP 响应码

    110: 重新启动标记应答。
    120: 在n分钟内准备好
    125: 连接打开准备传送
    150: 打开数据连接
    200: 命令成功
    202: 命令失败
    211: 系统状态
    212: 目录状态
    213: 文件状态
    214: 帮助信息
    215: 名字系统类型
    220: 新用户服务准备好了
    221: 服务关闭控制连接,可以退出登录
    225: 数据连接打开,无传输正在进行
    226: 关闭数据连接,请求的文件操作成功
    227: 进入被动模式
    230: 用户登录
    250: 请求的文件操作完成
    257: 创建”PATHNAME”
    331: 用户名正确,需要口令
    332: 登录时需要帐户信息
    350: 下一步命令
    421: 不能提供服务,关闭控制连接
    425: 不能打开数据连接
    426: 关闭连接,中止传输
    450: 请求的文件操作未执行
    451: 中止请求的操作:有本地错误
    452: 未执行请求的操作:系统存储空间不足
    500: 格式错误,命令不可识别
    501: 参数语法错误
    502: 命令未实现
    503: 命令顺序错误
    504: 此参数下的命令功能未实现
    530: 未登录
    532: 存储文件需要帐户信息
    550: 未执行请求的操作
    551: 请求操作中止:页类型未知
    552: 请求的文件操作中止,存储分配溢出
    553: 未执行请求的操作:文件名不合法

    (六)FTP 术语

    150    文件状态良好,打开数据连接
    200    命令成功
    202    命令未实现
    211    系统状态或系统帮助响应
    212    目录状态
    213    文件状态
    214    帮助信息,信息仅对人类用户有用
    215    名字系统类型
    220    对新用户服务准备好
    221    服务关闭控制连接,可以退出登录
    225    数据连接打开,无传输正在进行
    226    关闭数据连接,请求的文件操作成功
    227    进入被动模式
    230    用户登录
    250    请求的文件操作完成
    257    创建”PATHNAME”
    331    用户名正确,需要口令
    332    登录时需要帐户信息
    350    请求的文件操作需要进一步命令
    421    连接用户过多
    425    不能打开数据连接
    426    关闭连接,中止传输
    450    请求的文件操作未执行
    451    中止请求的操作:有本地错误
    452    未执行请求的操作:系统存储空间不足
    500    格式错误,命令不可识别
    501    参数语法错误
    502    命令未实现
    503    命令顺序错误
    504    此参数下的命令功能未实现
    530    账号或密码错误
    532    存储文件需要帐户信息
    550    未执行请求的操作
    551    请求操作中止:页类型未知
    552    请求的文件操作中止,存储分配溢出
    553    未执行请求的操作:文件名不合法

    二、HTTP(超文本传输协议)

    与 FTP 一样,HTTP 文件传输是用于业务文件传输的广泛使用的协议。它易于实现用户与服务器,用户与用户之间的文件传输。用户只需要一个Web浏览器就可以使用,无需在客户端安装。
    HTTP 也不太容易出现防火墙问题(与 FTP 不同)。但是,就像 FTP 一样,HTTP 也无法确保传输数据的安全。如果缺乏安全性对您来说不是问题,请大胆地使用 HTTP 吧!
    

    三、FTPS(基于 SSL 的 FTP)

    FTPS 也称作 FTP-SSL 和 FTP-over-SSL。FTPS 相当于加密版的 FTP, 是一种在安全套接层(SSL 是 Secure Sockets Layer 的缩写)下使用标准的 FTP 协议和相关指令的增强型 FTP 协议,FTPS 为 FTP 协议的控制和数据通道增加了 SSL 安全功能。SSL 是一个在客户机和具有 SSL 功能的服务器之间的连接中对数据进行加密和解密的协议。

    FTPS 连接通过用户 ID、密码和 SSL 证书进行身份验证。一旦建立 FTPS 连接,FTP 客户端软件将检查目标 FTP 服务器证书是否可信,如果证书由已知的证书颁发机构(CA)签发,或者证书由您的合作伙伴自己签发,并且您的信任密钥存储区中有其公开证书的副本,则 SSL 证书将被视为受信任的证书。FTPS 所有的用户名和密码信息将通过安全的 FTP 连接加密。

    FTPS 同样存在防火墙的问题,一种替代 FTPS 的协议是 SFTP(SSH File Transfer Protocol)。

    四、SFTP(安全文件传输协议)

    SFTP(Secure File Transfer Protocol 的缩写)是另一种广泛使用的安全文件传输协议,SFTP 与 FTP 有着几乎一样的语法和功能,SFTP 为 SSH 的一部份,SFTP 在 SSH 上运行,是一种传输文件到服务器的安全方式。其实在 SSH 软件包中,已经包含了一个叫作 SFTP 的安全文件传输子系统。

    SFTP 是在 SSH 基础上扩展了文件传输功能,因此它通常仅使用 SSH 端口用于数据传输和控制。SFTP 本身没有单独的守护进程,它必须使用 SSH 守护进程来完成相应的连接操作,所以从某种意义上来说,SFTP并不像一个服务器程序,而更像是一个客户端程序。

    SFTP 对传输的数据使用了加密/解密技术,所以传输效率比普通的 FTP 要低得多,如果您对网络安全性要求很高,可以使用 SFTP 代替FTP。

    下图显示了SFTP的工作模式,它是作为SSH2的一个子服务工作的。
    在这里插入图片描述

    (一)优点

    1. 只有一个连接(不需要 DATA 连接)
    2. FTP 连接始终保持安全
    3. FTP 目录列表是一致的和机器可读的
    4. FTP 协议包括操作权限和属性操作,文件锁定和更多的功能

    (二)缺点

    1. 通信是二进制的,不能“按原样”记录下来用于人类阅读
    2. SSH 密钥更难以管理和验证
    3. 这些标准定义了某些可选或推荐的选项,这会导致不同供应商的不同软件之间存在某些兼容性问题
    4. 没有服务器到服务器的复制和递归目录删除操作
    5. 在 VCL 和 .NET 框架中没有内置的 SSH/SFTP 支持

    (三)SFTP 和 FTPS 对比

    SFTP 和 FTPS 都提供高级别文件传输安全保护,通过强大的算法(如 AES 和 Triple DES)来加密传输的数据,两者都非常适合注重数据隐私性和安全性的企业,但是 SFTP 相对于 FTPS 的主要优点是它对防火墙更友好。SFTP 只需要通过防火墙打开一个端口(默认为 22)。此端口将用于所有 SFTP 通信,包括初始认证、发出的任何命令以及传输的任何数据。

    FTPS 通过严格安全的防火墙相对难以实现,因为 FTPS 使用多个网络端口号。每次进行文件传输请求(get,put)或目录列表请求时,需要打开另一个端口号。因此,必须在您的防火墙中打开更多的端口以允许 FTPS 连接,这使得你的网络存在潜在的安全风险。

    关于 sftp 和 ftps 的简单理解:

    ftps 借助 ssl 协议加密,sftp 借助 ssh 加密。sftp 协议是 ssh 中的一条独立的协议,利用 sftp 服务器就可以安全传输数据。而 ftps 是ftp-over-ssl 的意思,即 ftp 借助 ssl 协议加密传输,不但要用 ftp 服务器还要用 ssl 协议加密。

    如果是 ftp-over-ssh,就是完全不同于 sftp 的传输方式了,而是利用 ftp 服务器和 ssh 协议加密传输数据。

    关于 ssl 和 ssh 的简单理解:

    ssl 是为 http/smtp 等加密设计的,ssh 是为 telnet/ftp 等加密、建立传输通道而设计的。
    通俗的讲,ssh 就像铺管子,ssl 就像打包裹,铺管子和打包裹都会使数据安全,都是一个制作密钥的过程,而因为ssh是一个管子所以它很适合ftp的安全传输。

    (四)支持 FTPS 和 SFTP 的服务器软件

    1. Cerberus FTP 服务器
    2. FileZilla - 最著名的免费 FTP 和 FTPS 服务器软件
    3. Serv-U FTP 服务器

    五、HTTPS(基于 SSL 的 HTTP)

    HTTPS (全称:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1] 。HTTPS 在HTTP 的基础下加入SSL,HTTPS 的安全基础是 SSL,因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层(在 HTTP与 TCP 之间)。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯,例如交易支付等方面.

    HTTPS 是 HTTP 的安全版本。如果您不喜欢为最终用户安装客户端应用程序,并且大多数最终用户都是非技术人员,那么这可能是理想的选择。与 FTPS 相比,它是安全的并且非常人性化。

    六、SCP(安全副本)

    SCP(Secure Copy)这是 SFTP 的旧版本,更原始。它也是在 SSH 上运行,因此具有相同的安全功能。但是,如果您使用的是最新版本的SSH,则已经可以访问SCP和SFTP。

    SCP协议是用来定义“本地机器和远端机器之间”或者“远端机器和远端机器之间”传输文件的过程的协议,是应用层协议。SCP协议基于SSH协议,因而基于SCP协议的文件传输是安全的。

    SCP客户端和服务器两者都包含有“从本地复制文件传输给对方”和“从对方获取文件复制到本地”的功能,但其服务器跟常见的服务器不同,它不是“持续运行,监听端口”,而是被触发运行的。

    当SCP客户端发起文件传输请求时,会去调用同台机器上的SSH客户端程序,接着SSH客户端程序向SSH服务器进行文件传输请求,在得到允许的结果后,SSH服务器会建立一个SSH连接作为数据隧道,并运行同台机器上的SCP服务器。 此时如果是从SCP客户端传输文件到SCP服务器的情形:接下来SCP客户端从本地复制文件数据,将数据通过SSH隧道传输,SCP服务器从SSH隧道读取数据,将数据写入本地存储成一个文件。

    在这里插入图片描述

    (一)命令参数

    -1: 强制scp命令使用协议ssh1
    -2: 强制scp命令使用协议ssh2
    -4: 强制scp命令只使用IPv4寻址
    -6: 强制scp命令只使用IPv6寻址
    -B: 使用批处理模式(传输过程中不询问传输口令或短语)
    -C: 允许压缩。(将-C标志传递给ssh,从而打开压缩功能)
    -p:保留原文件的修改时间,访问时间和访问权限。
    -q: 不显示传输进度条。
    -r: 递归复制整个目录。
    -v:详细方式显示输出。scp和ssh(1)会显示出整个过程的调试信息。这些信息用于调试连接,验证和配置问题。
    -c cipher: 以cipher将数据传输进行加密,这个选项将直接传递给ssh。
    -F ssh_config: 指定一个替代的ssh配置文件,此参数直接传递给ssh。
    -i identity_file: 从指定文件中读取传输时使用的密钥文件,此参数直接传递给ssh。
    -l limit: 限定用户所能使用的带宽,以Kbit/s为单位。
    -o ssh_option: 如果习惯于使用ssh_config(5)中的参数传递方式,
    -P port:注意是大写的P, port是指定数据传输用到的端口号
    -S program: 指定加密传输时所使用的程序。此程序必须能够理解ssh(1)的选项。

    常用命令:
    命令格式: scp srcusername@srcip:srcpath/srcfile dstusername@dstip:dstpath/dstfile
    其中可以根据上传和下载的方式省略掉其中一各参数,具体如下:
    上传:scp -r local_dir username@servername:remote_dir
    下载:scp username@servername:/path/filename /var/www/local_dir

    七、WebDAV(Web分布式创作和版本控制)

    到目前为止,我们讨论的大多数文件传输协议主要用于文件传输。这不仅可以促进文件传输,还可以做更多的事情。WebDAV实际上运行在HTTP上,主要用于协作活动。通过WebDAV,用户不仅可以交换文件。即使他们(用户)在不同位置工作,他们也将能够在单个文件上进行协作。WebDAV可能最适合需要分布式创作功能的组织,例如大学和研究机构。

    八、WebDAVS

    到目前为止,您应该能够猜出S代表什么。没错,WebDAVS是WebDAV的安全版本。如果WebDAV通过HTTP运行,则WebDAVS通过HTTPS运行。这意味着,它具有WebDAV的相同特征以及SSL的安全功能。

    九、TFTP(临时文件传输协议)

    此文件传输协议与其他协议不同,因为您不会使用它来交换文档,图像或电子表格。实际上,您通常不会使用它与网络外部的计算机交换文件。TFTP更适合于网络管理任务,例如网络启动,备份配置文件以及通过网络安装操作系统。

    十、AS2(Applicability Statement 2)

    尽管前面讨论的几乎所有协议都能够支持B2B交换,但是确实有一些协议专门针对此类任务而设计。其中之一是AS2。
    AS2专为EDI(电子数据交换)交易而构建,EDI是制造业和零售业中常见的自动信息交换。

    十一、OFTP(Odette文件传输协议)

    专为EDI设计的另一种文件传输协议是OFTP。OFTP在欧洲非常普遍,因此,如果您与欧洲的公司进行交易,则可能需要这样做。OFTP和AS2本质上都是安全的,甚至支持电子交付,使其非常适合B2B交易。

    十二、AFTP(加速文件传输协议)

    广域网文件传输,尤其是在远距离传输的文件,很容易受到诸如延迟和数据包丢失之类的不良网络条件的影响,这会导致吞吐量显着降低。AFTP是一种TCP-UDP混合,使文件传输实际上不受这些网络条件的影响。电影和制造行业会发现这个协议是非常有用的。

    那么哪种文件传输协议最适合您的业务?确实没有一个正确的答案。那么,你可能必须同时满足互操作性,合规性和可用性要求,如果您面临此类挑战,那么最好的解决方案就是找到可以满足所有要求的解决方案。

    十三、TCP(传输控制协议)

    传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。

    TCP 旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。

    (一)TCP 与 UDP 的基本区别

    它们都是传输层的协议,但两者的机制不同,它们的区别如下:

    1. 报文模式:TCP面向连接的流模式,UDP面向无连接的数据报模式;

    2. TCP提供可靠服务,UDP可能丢包;

    3. TCP要求系统资源较多,UDP对系统资源要求较少;

    4. TCP传输效率较慢,UDP具有较好的实时性,工作效率比TCP高;

    5. TCP的每条连接只能是点对点的,UDP支持一对一、一对多、多对一和多多的的交互通信。

    (二)TCP 与 UDP 的应用场景

    从以上特点上我们已经知道:TCP 是可靠的、传输速度较慢 ,UDP 是不可靠的但传输速度快。因此在选用具体文件传输协议时,应该根据通信数据的要求来决定。

    若对通信数据的实时性考察远重于通信数据完整性,则优先考虑选用 TCP 协议(如文件传输、重要状态的更新等);反之,则使用 UDP 协议(如视频传输、实时通信等)。

    十四、UDP(User Datagram Protocol)

    Internet 协议集支持一个无连接的传输协议,该协议称为用户数据报协议(UDP,User Datagram Protocol)。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。RFC 768 [1] 描述了 UDP。

    Internet 的传输层有两个主要协议,互为补充。无连接的是 UDP,它除了给应用程序发送数据包功能并允许它们在所需的层次上架构自己的协议之外,几乎没有做什么特别的事情。面向连接的是 TCP,该协议几乎做了所有的事情。

    十五、FTP over SSH2

    此协议还是基于ftp协议的。在此协议中SSH2服务器起了一个桥梁作用,把数据在客户端和ftp之间转发。ftp协议本身包括两个通道,一个是控制通道,另一个是数据通道。
    FTP over SSH2有两种情况,半安全连接(Less Secure Connection)和安全连接(Full Secure Connection)。在半安全连接时,ftp客户端先和SSH2服务器连接,在这个连接中无论控制通道和数据通道都是加密的。但是SSH2服务器和ftp服务器之间就不是加密的了,如果ftp服务器运行在另外一台机器上,SSH2服务器和ftp直接就是明文传输。

    半安全连接如下图所示:

    在这里插入图片描述
    下图所示是安全连接模式的情形,SSH2服务器和FTP服务器在同一台服务器上。

    在这里插入图片描述

    十六、TFTP (简单文件传输协议)

    TFTP(Trivial File Transfer Protocol)是TCP/IP协议族中在客户机与服务器之间进行简单文件传输的协议,提供不复杂、开销不大的文件传输服务。端口号为69。

    (一)TFTP协议的优势

    1. TFTP能够用于那些有UDP而无TCP的环境
    2. TFTP代码所占的内存要比FTP小

    (二)TFTP协议与FTP协议的不同点

    1)TFTP协议不需要验证客户端的权限,FTP需要进行客户端验证;
    2)TFTP协议一般多用于局域网以及远程UNIX计算机中,而常见的FTP协议则多用于互联网中;
    3)FTP客户与服务器间的通信使用TCP,而TFTP客户与服务器间的通信使用的是UDP;
    4)TFTP只支持文件传输。也就是说,TFTP不支持交互,而且没有一个庞大的命令集。最为重要的是,TFTP不允许用户列出目录内容或者与服务器协商来决定哪些是可得到的文件。

    (三)命令参数

    -l 是local的缩写,后跟存在于Client的源文件名,或下载Client后 重命名的文件名。
    -r 是remote的缩写,后跟Server即PC机tftp服务器根目录中的源文 件名,或上传Server后重命名后的文件名。
    -g 是get的缩写,下载文件时用,
    -p 是put的缩写,上传文件时用,

    常用命令:

    下载东西: tftp -g -r 1.txt -l 2.txt 192.168.1.1
    上传东西:tftp -p -r 3.txt -l 2.txt 192.168.1.1

    展开全文
  • 【计算机网络自顶向下方法】手把手带你设计一个可靠且高效的数据传输协议

    写在前面:

    1. 本文主要参考《计算机网络自顶向下方法》,主要为个人学习整理的记录,如果能够帮到同样正在学习计算机网络的你,那也再好不过了,一起进步!
    2. 读完本文,你将了解为实现可靠的数据传输都将面临哪些现实挑战,而校验和、序列号、ACK 应答、计时器、管道化传输、滑动窗口、选择重传这些机制又都是如何使得数据传输变得可靠和高效的!

    1. 引言

    稍微了解计算机网络的朋友都会知道的一点是,我们一般说 TCP/IP 协议栈中传输层的协议 TCP 是可靠的,而同样是传输层的协议,UDP 协议则是不可靠的。实际上,不仅对于传输层的部分协议,针对网络协议分层模型中的数据链路层和应用层,实际应用中也都对其中一些协议存在数据传输的可靠性要求。

    由于数据传输可靠性的意义不言而喻,因此本文旨在讨论一般情况下,针对无论处于哪一层的协议,保证其实现可靠的数据传输都需要哪些机制,以及这些机制是如何保证数据传输的可靠性,以此来加深读者对于 TCP 等协议是如何实现可靠数据传输这一点的理解。

    为便于读者理解,下图首先给出接下来讨论所使用的框架,如图 a 所示,可靠的数据传输信道为上层的实体提供了服务的抽象,在可靠的信道内,传输的数据不会发生丢失或误码,而且所有数据在接收端被接收到的顺序和其在发送端被发送出去的顺序一致。实际上,这也是当互联网应用调用 TCP 协议发送数据时,后者向前者提供的服务模型。

    上述提到的服务抽象实际上就是由可靠的数据传输协议负责实现的。事实上,要实现一个可靠的数据传输协议却并不简单,因为一个可靠的数据传输协议,其底层所依赖的传输链路可能并非是可靠的。例如:传输层协议 TCP 是一个可靠的数据传输协议,但其所赖以实现的网络层协议 IP 却并非是可靠的。

    由于对于可靠的数据传输协议底层所依赖的传输链路来说,导致其不可靠本质的原因有很多;因此,接下来,本文将通过不断考虑更加复杂的情况,来尝试设计一个可靠的数据传输协议。例如:如果底层的链路或信道可能引起误码或丢包1,那么应该使用什么样的机制来解决。

    在这里插入图片描述

    上面的图 b 展示了后续即将设计的可靠数据传输所涉及的接口:

    • 在发送端,数据传输协议将由其所服务的上层应用通过 rdt_send() 2接口发起调用,然后数据会被传输至接收端的上层应用;
    • 在接收端,当数据包到达信道在接收方的一端时,rdt_rcv() 接口将会被调用;
    • 当可靠的数据传输协议希望将数据传递给上层时,其将调用 deliver_data() 接口;
    • 可靠数据传输的发送端和接收端3都通过调用下层不可靠协议的 udt_send() 接口发送数据,其中 udt 全称为 unreliable data transfer 即不可靠数据传输。

    2. 设计一个可靠的数据传输协议

    下面,本文将通过不断假设收发双方间的底层信道或链路面临不断复杂的情况,来一步步介绍怎么样实现一个可靠的数据传输协议。

    2.1 rdt1.0 假定底层信道也可靠

    首先是最简单的情形,即假定底层信道也是可靠的。这时我们称该协议为 rdt1.0 ,下图给出了此时发送端和接收端的有限状态机,其中图 a 表示发送端的操作而图 b 表示接收端的操作。

    在解释图中收发双方的状态机之前,有必要对图中的符号和文字含义解释如下:

    • 虚线箭头表示状态机的初始状态;
    • 箭头表示从一个状态转移至另一个状态4
    • 导致状态转移的事件由横线上方接口调用表示;
    • 横线下方表示状态转移事件触发后,相应需要执行的动作;
    • 后续图中还将使用符号 Λ \text{Λ} Λ 表示无事件发生或无动作执行。

    下面是对于下图中 rdt1.0 收发双方状态机的详细解释:

    • rdt1.0 的发送端会通过 rdt_send(data) 事件接收来自上一层的数据,然后使用 make_pkt(data) 创建一个数据包,接着使用 udt_send(packet) 将数据发送至信道或链路中;
    • rdt1.0 的接收端会通过 rdt_rcv(packet) 事件从底层信道或链路接收数据包,然后使用 extract(packet) 获取其中的数据5 ,接着使用 deliver_data(data) 将数据传递给上一层。

    在这里插入图片描述

    在 rdt1.0 中,由于其构建在本身就是可靠的信道或链路之上,因此接收方不需要向发送方反馈是否接收成功的应答。

    2.2 rdt2.0 假定底层信道有误码

    实际上,在实际中上述假设是不可能成立的,即底层的信道总是有可能出现误码6的,因此在 rdt2.0 中来讨论如何解决这个问题,同时这里依旧假设数据包在收发双方被发送或接受的顺序是一致的

    在尝试解决上述问题之前,我们来看一个现实中的例子。假设你正在和别人打电话,而且这时候你需要将对面说的一大段内容都记录下来。在正常情况下,当你每记录一句话之后你都会和对方说“好的”,但如果你没有听清楚对方说的某一句话,此时你会跟对方说“请再重复一下”。

    上面这个实际的例子其实就通过使用“肯定应答”和“否定应答”的方式来实现准确的信息交互。实际上,在计算机网络中也是同样的道理,且基于这种方式实现的可靠数据传输协议称为自动重复请求协议(ARQ: Automatic Repeat reQuest)。

    由上述讨论可知,要应对可靠传输协议底层信道可能产生误码的情况,ARQ 类协议至少应该具体的机制如下:

    • 错误探测。首先,当误码发生时,需要有机制能让接收方探测到。在实际中,这是通过在报文中加入报文校验和字段来实现的,该字段可以让接收方探测甚至可能修正误码报文。
    • 接收应答。其次,由于报文的收发双方通常在相隔很远的不同主机上,因此让发送方知道接收方是否成功是否报文的唯一方法就是后者为前者提供明确的应答。在 rdt2.0 中,类似于上述记录对话内容例子,这里使用 ACK 和 NAK 数据包作为接收方在收到报文后向发送方反馈的应答。原则上来说这类应答报文只需一个比特位即可,例如:用 1 1 1 表示 ACK ,用 0 0 0 表示 NAK 。
    • 报文重传。最后,显然如果接收方收到的报文在传输过程中发生误码,则发送方将对该报文进行重传。

    下图是 rdt2.0 协议即采用了上述机制实现的可靠数据传输协议的收发双方有限状态机:

    • 如下图 a 所示,发送端有两个状态:
      • 左边的状态表示发送端正在等待上层发起调用并传递数据。具体地,当事件 rdt_send(data) 发生时,发送方将会创建一个数据包 sndpkt ,其中除了包含待发送数据以外,还包括了数据包的校验和(checksum),接着使用 udt_send(sndpkt) 将数据包发出;
      • 右边的状态表示发送方正在等待接收方的反馈应答,有可能是 NAK 也可能是 ACK 数据包:
        • 如果收到 ACK 应答,即 rdt_rcv(rcvpkt) && isACK (rcvpkt) 判断为 true ,那么发送方就知道自己刚刚传输的数据包被对方成功接受且传输过程无误码产生,自然地发送方此时将会转移至等待上层应用发起调用的状态;
        • 如果收到 NAK 应答,即 rdt_rcv(rcvpkt) && isNAK (rcvpkt) 判断为 true ,那么发送方就会将刚刚发送过的报文进行重传,同时继续等待对方的 ACK 或者 NAK 应答7

    在这里插入图片描述

    如上图 b 所示,接收端仅有一个状态:

    • 在数据包到达后,接收方会向发送方反馈 ACK 或 NAK 数据包,具体是哪一个取决于到达的数据包是否产生了误码,在上图中,rdt_rcv(rcvpkt) && corrupt(rcvpkt) 就表示收到了数据包数据包有错误。

    上述 rdt2.0 看起来好像是一个可靠的数据传输协议,但实际上其有一个致命的缺陷,即 rdt2.0 没有考虑到 ACK 或 NAK 数据包也可能发生误码的情况。

    为了解决这个问题,你的第一反应可能是给 ACK 或 NAK 数据包也加上校验和字段,然而更关键的问题不止于此,而是该协议如何能在发送方收到发生误码的 ACK 或 NAK 之后还能正确判断接收方是否准确的收到了刚刚的数据包,因此更关键的问题是发送方如何直接从产生误码的 ACK 或 NAK 得到期望的信息

    下面考虑当 ACK 或 NAK 确实发生误码时,可能采取的 3 3 3 种处理方式:

    • 对于第一种情况,这里还是用前面提到的记录通话内容的例子来说明。如果对面说话的人没有听清记录人反馈(可能是“好的”或“请再重复一下”),那么对面可能会问“你刚刚说的是什么?”,如果记录人听清了这句话还好,如果没有记录人又没有听清这句话,那么记录人也会问“你刚刚说的是什么?”在极端情况下,这可能陷入无止境的循环之中;
    • 第二种方式是新增足够位数的校验和,以此让发送方不仅可以探测到误码,还可以从误码中推断出究竟收到的是 ACK 还是 NAK ;
    • 第三种方式是当发送方收到产生误码的 ACK 或 NAK 包时,发送方直接重发当前的数据包。问题是,这种方式会为收发双方的信道引入重复的数据包。由此进一步引发的问题是,接收方其实并不知道发送方究竟是否正确地接收了其刚刚应答的 ACK 或 NAK 报文,从而接收方也就无从得知发送方直接重传的数据包是包含新数据还是仅为重传的报文。

    2.2.1 rdt2.1

    针对 ACK 和 NAK 可能发生误码这个问题,包括 TCP 在内的数据传输协议都基于报文重传采用了一种简单的方式来解决这个问题,即为发送方的数据包新增一个字段,该字段填写的是发送方为数据包进行编号的数字即序列号,然后接收方只需要检查该序列号就能确定收到的数据包究竟是否为重传报文。

    对于上述 rdt2.07 而言,使用 1 1 1 个比特位的序列号就能满足要求,因为这就已经能让接收方知道发送方究竟是在进行报文重传还是发送新的数据包,具体地:

    • 当接收方收到的数据包有着和最近收到的数据包相同的序列号,这说明是重传报文;
    • 当接收方收到的数据包有着和最近收到的数据包不同的序列号,这说明是新的报文。

    需要说明的是,由于截至目前我们依然假设收发双方的信道不会产生丢包,因此 ACK 和 NAK 报文本身并不需要指定是针对哪个收到的数据包的应答反馈,即发送方天然地就知道其收到的 ACK 或 NAK (无所谓是否产生误码8)是针对其最近发出去的数据包的应答。

    上面增加了序列号的数据传输协议(以下称为 rdt2.1),相较于 rdt2.0 ,其收发双方的有限状态机都有更多的状态。原因在于,协议状态需要反映发送方当前发送的或者接收方期望接收的报文究竟序列号为 0 0 0 还是 1 1 1

    下图分别是 rdt2.1 中发送方和接收方的有限状态机:

    • 发送方有限状态机:
      在这里插入图片描述

    • 接收方有限状态机:

    在这里插入图片描述

    2.2.2 rdt2.2

    上述 rdt2.1 使用 NAK 来表明其收到来自发送方的数据包有误码产生,实际上,也可以不用 NAK 而是仅使用 ACK 就实现同样的效果,即当接收方收到来自发送方的数据包有误码产生时,接收方向发送方应答针对上一个正确接收的数据包的 ACK ,如果提前约定好,那么此时发送方收到针对同一个数据包的两个 ACK 时,就知道接收方并未能正确接收紧随其后的数据包。

    上面给出的不使用 NAK 而仅使用 ACK 作为接收方对所有收到报文(不管产生误码与否)进行应答的协议以下称为 rdt2.2 。rdt2.1 和 rdt2.2 之间的区别主要就在于,接收方在发送 ACK 应答时需要带上对应报文的序列号,而发送方在收到 ACK 时,也需要检查其中的序列号

    下图分别是 rdt2.2 中发送方和接收方的有限状态机:

    • 发送方有限状态机:
      在这里插入图片描述

    • 接收方有限状态机:

    在这里插入图片描述

    2.3 rdt3.0 假定底层信道有误码和丢包

    现在假定收发双方间的信道除了可能引起误码外,还可能产生丢包,实际上丢包在今天的计算机网络(包括因特网)中还是很常见的现象。信道丢包的可能又引出了对设计可靠数据传输协议的两大挑战:

    • 如何探测丢包的产生;
    • 丢包产生时如何处理。

    实际上,rdt2.2 协议中已有的报文校验和、序列号、ACK 应答包和报文重传等机制已经可以解决上述第二个挑战了,而解决第一个挑战则需要新的协议机制。

    这里,新的协议机制将会把负责探测丢包和丢包处理的任务都放到发送方来解决。

    假设发送方发送了数据包之后,要么数据包本身,要么接收方针对该数据包的 ACK 应答包丢失了,此时都将导致发送方不可能收到接收方的应答。如果愿意等待足够长的时间,那么发送方是可以判断出数据包是否丢失的,但是问题是究竟多长时间算足够长?

    • 首先,接收方的等待时间至少要大于收发双方间报文往返的时间(可能还要包括数据包在二者中间的路由器中缓存的时间)加上接收方处理报文的时间等。实际上,在多数计算机网络中,这一所谓足够长的时间是很难精确计算的;
    • 其次,为实现高效地数据传输,理想的情况下,丢包的问题应该尽快得到解决,否则将导致数据传输的效率急剧下降。

    在实际中,发送方通过审慎地选择一个折中的时间长度,使得过了这么长时间后就判定数据包大概率已经丢失了,此时发送方将进行报文重传。

    需要注意的是,如果一个数据包在传输过程中经历了特别长的时延,即使最终该数据包本身以及接收方的 ACK 应答都没有丢失,发送方也将进行报文重传,虽然这将会为收发双方的信道中引入重复的数据包,但幸运的是 rdt2.2 中的报文序列号机制已经可以处理这一情形了。

    实际上,从发送者的角度可以说是“遇事不决,报文重传”了。即当发送方并不知道究竟是数据包本身丢失或延时过长了,还是 ACK 应答丢失了抑或是延时过长了。在所有这些情况下,发送方的做法都一样:报文重传。

    下图是 rdt3.0 中发送方的有限状态机:

    在这里插入图片描述

    由上图可知,相较于 rdt2.2 ,为了应对丢包的情况,这里引入了计时器,具体地:

    • 当发送或重传数据包时,发送方需要重新设定计时器;
    • 当计时器显示超时,发送方当前状态被中断,并且需要进行报文重传;
    • 当发送方在超时时间内收到接收方应答时,发送方需要停止计时器。

    为了更好地理解引入计时器机制的 rdt3.0 是如何在收发双方信道可能引起误码和丢包情况下进行可靠的数据传输,下面给出几个示例,分别表示 rdt3.0 在无丢包和有丢包的情况下是如何工作的:

    在这里插入图片描述

    截至目前,rdt3.0 已经是一个较为成形的可靠的数据传输协议了。

    3. 设计一个可靠且高效的数据传输协议

    3.1 管道化传输

    上述 rdt3.0 在功能上已经基本可以实现可靠的数据传输了,但是其传输效率却差强人意,其本质原因是 rdt3.0 是一个停止-等待型协议

    为了更好的理解为什么停止-等待型协议的效率低下,可以用下面这样一个例子:假设有两台主机,分别位于黑河和腾冲(如下图所示),报文在二者之间的往返传播时延(记为RTT)大概为 30 30 30 毫秒,假设两台主机之间通过传输速率为 R R R 1  Gbps 1\text{ }\text{Gbps} 1 Gbps (即每秒传输 1 0 9 10^9 109 比特)的链路相连。

    假设每个数据包大小 L L L 1000 1000 1000 字节(约 8000 8000 8000 个比特,包括报文头和数据),因此将每个数据包传入二者链路所需时间为:
    d t r a n s = L R = 8000  bits/packet 1 0 9  bits/sec = 8  ms d_{trans}=\frac{L}{R}=\frac{8000\text{ }\text{bits/packet}}{10^9\text{ }\text{bits/sec}}=8\text{ }\text{ms} dtrans=RL=109 bits/sec8000 bits/packet=8 ms

    在这里插入图片描述

    通过下图 a 我们可以进一步量化停止-等待型协议效率低下的程度。如果发送方在 t = 0 t=0 t=0 的时候发送数据包,那么由上述计算:

    • 首先,在 t = L / R = 8  ms t=L/R=8\text{ }\text{ms} t=L/R=8 ms 时,数据包的最后一个比特将进入传输链路;
    • 接着,在 t = RTT / 2 + L / R = 15.008  ms t=\text{RTT}/2+L/R=15.008\text{ }\text{ms} t=RTT/2+L/R=15.008 ms 时,数据包的最后一个比特出现在接收端;
    • 最后,为简单起见,这里假定 ACK 数据包大小可以忽略(因此其传输时间传输进链路的时间可忽略),另外还假定接收方收到数据包的最后一个比特后立马发送 ACK ,则发送方在 t = RTT + L / R = 30.008  ms t=\text{RTT}+L/R=30.008\text{ }\text{ms} t=RTT+L/R=30.008 ms 时接收到 ACK 。

    因此,在整整 30.008  ms 30.008\text{ }\text{ms} 30.008 ms 的时间里,发送方只有 0.008  ms 0.008\text{ }\text{ms} 0.008 ms 的时间在发送数据。具体,可以计算发送方对信道的利用率为:
    U sender = L / R R T T + L / R = 0.008 30.008 = 0.00027 U_{\text{sender}}=\frac{L/R}{RTT+L/R}=\frac{0.008}{30.008}=0.00027 Usender=RTT+L/RL/R=30.0080.008=0.00027

    在这里插入图片描述

    解决上述传输效率低下问题的方法其实也比较简单,如上图 b 所示,即实际可以一次性发送多个数据包然后等待接收方对这些数据包的 ACK 应答,而不是以串行的方式一次只发送一个数据包然后等到收到 ACK 应答后才发送下一个。这种解决方式就是所谓的管道化数据传输

    然而,管道化传输给可靠的数据传输又带来了新的挑战:

    • 报文序列号的大小范围需要扩大。因为同一时间可能有多个正在传输且未被确认的数据包,而每一个正在传输过程中的数据包(不包括重传报文)都需要有一个唯一的报文序列号;
    • 收发双方需要缓存一个以上数据包。最起码地,发送方需要缓存那些已发送但是未收到确认的数据包,而如下所述,接收方也需要缓存数据包;
    • 协议所需的序列号范围以及对报文缓存的要求取决于数据传输协议是如何应对丢包、误码和时延过长等情况。具体地将分别由下面介绍的滑动窗口协议和选择重传协议来解决。

    3.2 滑动窗口协议

    在滑动窗口协议(又被称为 GBN 协议,全称 Go-Back-N )中,发送方可以一次性发送不超过某个最大值如 N N N 个数据包。下图是从发送方角度来看,滑动窗口协议中序列号的范围和工作原理:

    在这里插入图片描述

    其中:

    • base 表示所有已发送且未收到 ACK 应答的数据包中,最早被发出去的那一个数据包所拥有的报文序列号;
    • nextseqnum 表示下一个被发出去的数据包所应该拥有的报文序列号。

    由此,所有可能的报文序列号就被分成 4 4 4 个区间:

    • [ 0 ,  base − 1 ] [0,\text{ base}-1] [0, base1] :序列号在此区间的报文都是已发送且发送方已收到接收方 ACK 应答的;
    • [ base ,  nextseqnum − 1 ] [\text{base},\text{ nextseqnum}-1] [base, nextseqnum1] :序列号在此区间的报文都是发送方已发送但还未收到 ACK 应答的;
    • [ nextseqnum ,  base + N − 1 ] [\text{nextseqnum},\text{ base}+\text{N}-1] [nextseqnum, base+N1] :序号序列号在此区间表示如果有报文需要发送,则可以使用此区间的序列号;
    • ≥ base + N \ge \text{base}+\text{N} base+N :序列号在此区间表示此时这些序号暂不可用,只有当发送方收到了针对序列号为 base 的报文的 ACK 应答才可能被使用。

    由上图可知,长度为 N N N 的区间是所有可用于已发送但未收到 ACK 应答的数据包序列号范围,该区间可视为一个窗口,在协议进行数据包收发期间,相当于该窗口在序列号所有可能取值的区间进行滑动,因此该协议被称为滑动窗口协议,而 N N N 被称为窗口大小。

    需要注意的是,在实际中,滑动窗口协议中的报文序列号并非是只增不减,由于序列号这一数据域在数据包的数据头中是固定长度的,假设该长度是 k k k 个比特,那么序列号取值区间就是 [ 0 ,   2 k − 1 ] [0,\text{ }2^k-1] [0, 2k1] 。有人可能会问那如何确保数据包的数量不超过序列号的最大可能取值?

    实际上,并没有必要有这样的要求,因为序列号是可以重用的,具体实现方式是对于序列号的所有数学运算都使用按 2 k 2^k 2k 取模的方式进行,这就意味着序列号区间可以视为一个环形区间,即序列号 2 k − 1 2^k-1 2k1 后跟着的序列号9将会是 0 0 0

    下面是基于滑动窗口协议实现可靠数据传输所对应的发送方有限状态机:

    在这里插入图片描述

    滑动窗口协议中的发送方必须响应以下三种事件:

    • 来自上一层的调用。当上一层调用 rdt_send() 接口时,发送方会先检查窗口是否已满,即目前收发双方的信道中是否已经有 N N N 个发送方已发送但未收到接收方 ACK 应答的数据包:
      • 如果窗口未满,传递过来的数据将会被打包进数据包中然后发出去,相关变量也会被相应更新;
      • 如果窗口已满,发送方可能直接会将数据返回给上一层,即间接向上一层表明当前窗口已满,上一层可能会稍后进行重试10
    • 来自接收方的 ACK 。在上述滑动窗口算法中,接收方针对序列号为 n n n 的数据包发出的 ACK 在发送方被视为累积确认,即该 ACK 表示先前所有序列号小于等于 n n n 的数据包都被接收方成功接收了。
    • 未收到 ACK 但超时。如之前所述,这里的滑动窗口协议也被称为 Go-Back-N 算法,这个名字的由来取自发送方在应对丢包或超时情况下的机制。具体地,和上述 rdt3.0 一样,滑动窗口协议也使用计时器来应对丢包和超时情况:
      • 如果发生超时,那么发送方会重传所有之前已发送但未收到 ACK 应答的数据包;
      • 上面发送方的有限状态机仅使用了一个计时器,该计时器是针对最早发送但未收到 ACK 的数据包,启动计时器的时间是该数据包被发送方发出的同时;
      • 如果收到了代表累积确认的 ACK ,则此时除了需要先更新 base 变量的值,即向后滑动窗口,还需要根据更新后的 base 值做不同的处理:
        • 如果 base 等于 nextseqnum ,这表示收发双方的信道中已经无任何数据包在传输或未被确认,此时直接停止计时器即可;
        • 如果 base 小于 nextseqnum ,此时需要重新启动计时器。

    下面是基于滑动窗口协议实现可靠数据传输所对应的接收方有限状态机:

    在这里插入图片描述

    • 如果序列号为 n n n 的数据包被按顺序正确接收(即上一次被传递至上一层地数据来自序列号为 n − 1 n-1 n1 的数据包),接收方就会针对序列号为 n n n 的数据包发送 ACK 应答,而后将数据包中的数据部分剥离出来后传递给上一层;
    • 在所有其他可能出现的情况下,接收方会丢弃接收到的数据包,然后针对最近一个被正确接收的数据包发送一个 ACK 11

    对于上述滑动窗口协议,有些人可能觉得接收方的处理逻辑过于简单粗暴而且有浪费资源之嫌,他们的理由是接收方在除了序列号为 n n n 的数据包被正确接收并且序列号为 n − 1 n-1 n1 的数据包也已经被正确接收(即数据包按照序列号自然增长地顺序被正确接收)的所有其他情况下,都会直接将数据包丢弃。

    实际上,接收方这么做是有其合理性的。如上所述11,接收方必须按照数据包序列号向上一层传递数据。假设序列号截至 n − 1 n-1 n1 的数据包都已经被成功接收且传递至上一层,此时虽然接收方期望收到序列号为 n n n 的数据包,但是实际先到达的是序列号为 n + 1 n+1 n+1 的数据包。当然,接收方可以先将序列号为 n + 1 n+1 n+1 的数据包缓存下来,等到正确接收且向上一层传递了序列号为 n n n 数据包后,再对缓存的数据包进行处理。

    然而,如果此时序列号为 n n n 的数据包发生丢包,那么根据滑动窗口协议的重传规则,序列号为 n n n n + 1 n+1 n+1 的数据包都会被重传。因此,接收方可以直接丢弃先到达的序列号为 n + 1 n+1 n+1 的数据包。

    上述机制的优点在于,接收方的压根不需要实现缓存数据包的机制,因为没有必要。因此,虽然发送方必须要维护其窗口的上下界以及其中 nextseqnum 的位置,但是接收方仅需要维护下一个期望收到的数据包的序列号 expectedseqnum

    上述机制的缺点在于,如果直接丢弃序列号不是 expectedseqnum 的数据包,那么如果后续对该数据包的重传发生丢包或误码,此时又会进一步导致更多的报文重传发生。

    为了更好地理解上述介绍的滑动窗口协议,下面通过一个示例来说明,示例中窗口的大小为 4 4 4

    在这里插入图片描述

    下面是对上图简单说明:

    • 由于窗口大小为 4 4 4 的限制,发送方在发送了序列号从 0 0 0 3 3 3 的数据包之后导致窗口已满,此时必须收到 ACK 之后才有可能继续进行数据包的发送;
    • 当发送方收到 ACK0 和 ACK1 之后,窗口向右滑动,发送方又可以发送 pkt4pkt5
    • 在接收端,由于数据包 pkt2 丢失,所以序列号为 3 3 3 4 4 4 5 5 5 的数据包都会被直接丢弃;
    • 在发送端,由于 pkt2 超时,所以所有序列号在其之后的数据包都会被重传。

    3.3 选择重传协议

    对于上述滑动窗口协议,虽然其具有提高信道利用率的功能,但是当有一个数据包的传输有问题时,可能就需要重传很多个数据包。下面即将介绍的选择重传协议就是为了缓解这样的问题。

    顾名思义,选择重传协议只会重传那些在传输中发生错误的数据包(如:丢包、误码、时延过长)。这种按需重传机制需要接收方针对每个成功接收的数据包发送 ACK 进行确认,而不是采用累积确认。

    在选择重传协议中,同样使用宽度为 N N N 的窗口来限制信道中已发送但发送方未收到 ACK 确认的最大数据包个数;不同的是,相较于上述滑动协议,此时在窗口中将会有部分数据包已经收到了接收方的 ACK 应答。

    下图展示了选择重传协议中数据包序列号的分布特点和相关含义:

    在这里插入图片描述

    在选择重传协议中,发送方会针对任何正确接收的数据包发送 ACK 应答,不管其序列号是否紧跟上一个正确接收数据包的序列号。如果接收方收到的数据包后,发现其序列号的确不是按序递增的,那么该数据包将会先被缓存下来,然后等到所有小于该序列号的数据包都正确接收之后,会一股脑将这批数据包按序向上一层传递。

    下面针对选择重传协议的收发双方所应该响应的事件和应该执行的操作进行了总结:

    • 发送方:
      • 接收到来自上一层的待传输数据。该事件下,该协议和上述滑动窗口中发送方所应执行的操作一致,即发送方检查 nextseqnum ,如果该值在窗口中则将数据打包后发出,否则对数据进行缓存或直接返回上一层。
      • 计时器超时。该事件下,该协议仅会重传超时的数据包。另外需要特别注意的是,该协议下发送方针对每一个发出的数据包都会启动一个计时器。
      • 接收 ACK 。
        • 如果发送方收到接收方针对某个数据包的 ACK 应答且该应答对应的数据包序列号在窗口内,则发送方会将对应序列号的数据包标记为已被接收。
        • 如果 ACK 应答所对应数据包的序列号等于 send_base ,则窗口会向右滑动,且 send_base 会更新为所有已发送但未被确认的数据包中最小的序列号。
        • 如果滑动窗口后,有来自上一层等待被发送的数据包且对应序列号落在了窗口之内,则这些数据包会被发送出去。
    • 接收方:
      • 序列号在区间 [ rcv_base ,  rcv_base + N − 1 ] [\text{rcv\_base},\text{ }\text{rcv\_base}+N-1] [rcv_base, rcv_base+N1] 内的数据包被正确接收。
        • 如果该数据包的序列号位于窗口区间内部(不包括窗口的边界),那么一方面接收方会给发送方发送一个针对该数据包的 ACK 应答,而后如果这同时也是接收方第一次收到该数据包,那么该包会被缓存下来。
        • 如果该数据包的序列号等于 rcv_base ,那么该数据包以及所有先前被缓存下来且序列号连续(序列号从 rcv_base 开始)的一批数据包都会在剥离出数据之后被传递至上一层。接着接收方的窗口会向右滑动,滑动的距离和刚刚提及的数据包个数一致。
      • 序列号在区间 [ rcv_base − N ,  rcv_base − 1 ] [\text{rcv\_base}-N,\text{ }\text{rcv\_base}-1] [rcv_baseN, rcv_base1] 内的数据包被正确接收。在这种情形下,即使接收方可能之前针对该数据包发送了 ACK 应答,此时也必须再次发送 ACK 应答。否则的话,可能会导致发送方的窗口永远无法向右滑动12
      • 其他所有情况。直接忽略数据包。

    为了使读者更好地理解以上论述,下面通过一个案例来展示选择重传协议是如何处理丢包场景的:

    在这里插入图片描述

    4. 总结

    至此基本就是本文的全部内容,这篇文章通过循序渐进的方式,通过假定收发双方间的信道越来越复杂,逐步引入各种机制,最终基本实现了可靠且高效的数据传输协议,在此将本文提及的各种机制总结如下表:

    机制作用
    校验和用于探测数据包在传输过程中是否发生了误码。
    计时器用于在数据包或应答 ACK 发生丢包或者数据包传输时延过长时进行报文重传。
    序列号用于对收发双方之间的数据包进行编号,便于接收方区别新的数据包和重传数据包,同时还便于接收方可以将报文按照顺序组装还原成原始数据。
    ACK 应答用于接收方告知发送方某个或某几个数据包已经被正确接收。ACK 应答报文中通常包含其所对应的数据包序列号。
    NAK 应答用于接收方告知发送方某个数据包未能被正确接收。NAK 应答报文中通常包含其所对应的数据包序列号。
    窗口,管道化通过允许最大不超过窗口大小个数据包同时发送,可以提高数据传输效率,这样的机制称为管道化传输。

    1. 需要注意的是,本文将自始至终假设数据包在信道或链路中被传递的顺序和其在发送端被发送的顺序是一致的,即虽然可能发生丢包,但是可靠的数据传输协议底层所依赖的信道或链路是不会改变数据包传递的顺序的。 ↩︎

    2. 这里 rdt 全称为 reliable data transfer 即可靠数据传输,而 _send 表示被调用的是发送端的可靠数据传输服务。 ↩︎

    3. 为简单起见,本文仅讨论单向的数据传输,即数据从发送端到接收端,实际上发送端和接收端是对偶的概念。 ↩︎

    4. 由于图中收发双方都只有一个状态,因此这里状态转移前后都是同一个状态,后续当情况更复杂时将出现多个状态之间的相互转移。 ↩︎

    5. 这里数据包(packet)和数据(data)的概念可类比于带包装的快递和拆除包装的快递。 ↩︎

    6. 所谓误码这里指数据在信道或链路的传输过程中比特位由 0 0 0 跳变为 1 1 1 或者由 1 1 1 跳变为 0 0 0↩︎

    7. 需要注意的是,这里当发送方处于等待ACK 或者 NAK 应答的状态时,发送方是不能继续从上一层接受数据的,即 rdt_send(data) 事件无法被触发,只有当发送方收到了 ACK 应答其才能转移到等待上层应用发起调用的状态。也就是说,发送方在确认接收方已经成功接收了最新的一个数据包之前是不会发送新的数据的,因此 rdt2.0 也被称为停止等待型协议(stop-and-wait protocol)。 ↩︎ ↩︎

    8. 实际上,这并不意味着 ACK 或 NAK 是否产生误码对发送方无影响,发送方还是需要知道收到应答报文内容究竟是 ACK 还是 NAK ,因为发送方接下来要据此做不同处理,即如果是 ACK ,即发送方将发送新的数据包;如果是 NAK ,发送方将进行报文重传;如果因为误码产生,无法明确是 ACK 还是 NAK ,发送方也将进行报文重传。 ↩︎

    9. 值得一提的是,在 TCP 协议中,报文序列号并不是按照报文个数增加的,而是按照报文的字节数增加的。 ↩︎

    10. 在实际实现中,发送方一般会在这时候将数据进行缓存,或者采用一种同步机制(如:信号量、标志位)以实现只有当窗口未满时才可以调用 rdt_send() 接口。 ↩︎

    11. 值得注意的是,由于接收方收到数据包之后是挨个将其中的数据剥离出来后传递至上一层,这就意味着如果序列号为 k k k 的数据包被正确接收且其中数据被传递至上一层,那么所有序列号小于 k k k 的数据包也都已经得到了正确地处理。 ↩︎ ↩︎

    12. 在选择重传协议中数据包序列号的分布特点和相关含义那张图中,如果接收方收到了序列号为 send_base 的数据包而且也给发送方发送了 ACK ,但是该 ACK 发生了丢包,那么在计时器超时后发送方会重传该数据包,此时接收方可能再次收到该数据包,虽然之前接收方已经回复了 ACK ,但是整个过程中发送方是无从得知的,即如果接收方不再次针对这个数据包回复 ACK 的话,发送方就会反复重传该数据包,更重要的是发送方的窗口永远都不会向右滑动。 ↩︎

    展开全文
  • 这一周做了一个计算机网络的实验,名字叫 可靠数据传输协议-GBN协议的设计与实现 感觉自己做的很认真,实现的效果也不错,就把自己的过程与结果记录一下 对于这个实验,实验要求上说实现SR协议是加分项,而SR协议又是以...
  • rdt 可靠数据传输协议

    万次阅读 多人点赞 2018-05-20 11:22:54
    计算机网络的设计基本方案是复杂化,多功能化应用...为了保证数据传输的可靠性,我们选择在运输层采用复杂的rdt(可靠数据传输协议),以完成网络的可靠性。 原理图如下所示: rdt协议经历了rdt1.0,rdt2.0,rd...
  • 基于HTTP的XML数据传输协议

    万次阅读 2018-06-25 10:10:25
    消息包 客户端与服务器之间...客户端和服务器端发送和解析XML数据时要遵循数据传输协议。 每一个请求、响应消息包都是一个XML字符串,包含消息头和消息体两部分,对于不同类型的请求、响应,消息头的格式都相同的...
  • 可靠数据传输原理详细图解

    千次阅读 2021-11-11 15:38:35
    可靠数据传输原理概述rdt1.0rdt2rdt2.0rdt2.1rdt2.2rdt3.0流水线可靠数据传输协议为什么使用流水线流水线对可靠数据传输协议带来的影响流水线协议中恢复差错的两种方法回退N步协议(GBN协议、滑动窗口协议)选择重传...
  • 数据传输通信协议总结

    千次阅读 2018-12-02 22:46:19
    数据传输时,总是存在丢包、分包、误包的情况。针对这一问题,则必须引进一套数据通信协议,来保证数据的完整性与准确性。  通常,针对丢包、误包问题都会采用数据长度和校验码比对的方式来判断一包数据的准确性...
  • 2017-02-10 可靠数据传输原理、可靠数据传输协议、自动重传请求协议、停等协议、冗余分组、比特交替协议、滑动窗口协议 《计算机网络-自顶向下方法》(原书第6版) 3.4 可靠数据传输原理  可靠数据...
  • 前言:本文来自论文《基于RTMP...对于即时通讯开发人员来说,文中的相关理论和思路,对于研究即时通讯实时音视频(IM聊天应用的视时音视频通话)技术中的数据传输方案,原理是相通的,有一定的学习和借鉴意义,希望.
  • 视频传输协议

    千次阅读 2021-12-29 11:56:16
    SDP协议 RTP RTCP SRTP RTP只负责传输数据包,需要与RTCP配合使用,由RTCP来保证RTP数据包的服务... IP协议最大传输单元(MTU)最大为1500字节,其中包括至少20字节的IP头、8字节的UDP头、12字节的RTP头, 这样,头信息
  • GPRS所使用的数据传输协议

    千次阅读 2011-11-21 10:31:34
    数据由用户的手机到因特网要经过四个设备,MS(Mobile Station,手机)、BSS(Base Station System,基站系统)、SGSN(Serving GPRS Support Node,服务GPRS节点)和GGSN(Gateway GPRS Support Node,网关GPRS节点...
  • 可靠数据传输基本原理

    千次阅读 2019-04-02 23:00:53
    可靠数据传输是指:数据可以通过一条可靠信道来传输。传输的数据不会受到损失或者丢失,而且...下面一步步构造可靠数据传输协议。称之为rdt协议。 rdt1.0 在rdt1.0中,我们先考虑一个最简单的情况,即底层信道是完...
  • 物联网消息传输协议——mqtt详解

    千次阅读 2021-07-17 15:59:54
    什么是Mqtt mqtt是为物联网场景设计的基于tcp的pub/sub协议, ...使命: 九十年代早期为实现 在带宽有限的条件下,让传感器能与IBM的MQ Integrator通信的一个实时数据传输协议 更多:说到实时数据传输,可能你会想
  • 构造可靠数据传输协议、滑动窗口协议、比特交替协议、回退N步协议、选择重传协议 1:冗余数据分组(duplicate data packet)、2:倒计数定时器(countdown timer)、3:比特交替协议(alternating-bit protocol...
  • HTTP协议--几种数据传输方式

    万次阅读 2019-03-11 15:03:33
    这种设置的好处是:更快的处理更多的请求事务,确保协议的可伸缩性 不过随着web的不断发展,有时候,需要将这种状态进行保持,随即,就引入了cookie技术,cookie技术通过在请求和响应报文中写入cookie信息来控制...
  • WebService采用HTTP协议传输数据,采用XML格式封装数据(即XML中说明调用远程服务对象的哪个方法,传递的参数是什么,以及服务对象的返回结果是什么)。WebService通过HTTP协议发送请求和接收结果时,发送的请...
  • Oracle:TNS数据传输协议-基础篇

    万次阅读 2016-06-20 16:38:20
    我们主要在Oracle 11g的版本上研究客户端和服务端之间的传输协议。网络上关于TNS协议的介绍资料比较少,毕竟它不是开源的数据库,但研究的人还是有不少。在目前所有的可学习资源中,oracle的jdbc驱动无疑是研究TNS...
  • HDMI音视频传输协议

    千次阅读 2021-08-09 22:28:41
    HDMI音视频传输协议 文章目录HDMI音视频传输协议一、HDMI的硬件图示二、TMDS三、DDC四、CEC五、HPD 一、HDMI的硬件图示 1、HDMI通信协议示意图 信号源(source device)<---------------------------...
  • 协议一般广泛用于公用数据网,支持全半双工模式,一种同步传输数据,面向比特的数据链路层协议。 HDLC数据帧结构 Falg字段 Address字段 Control字段 信息info字段
  • 网络传输协议介绍

    千次阅读 2019-04-22 14:01:40
    网络传输中为什么需要协议 在世界上各地,各种各样的电脑运行着各自不同的操作系统为大家服务,这些电脑 在表达同一种信息的时候所使用的方法是千差万别。就好像圣经中上帝打乱了各地人的 口音,让他们无法...
  • Android中的App网络传输协议

    千次阅读 2017-12-05 19:44:41
    这里首先需要明确一点的是什么是网络传输协议呢?这里首先套用一段百度百科的定义: 网络传输协议或简称为传送协议(Communications Protocol[1] ),是指计算机通信的共同语言。现在最普及的计算机通信为网络通信...
  • 文章目录一、Bluetooth(一)、蓝牙分类(二)、蓝牙原理及应用1、工作方式2、应用(三)、发展历史(四)、蓝牙协议堆栈(五)、协议规范(六)、基带纠错(七)、建立连接(八)、配对和绑定1、动机2、实现3、配对...
  • 传输协议介绍

    千次阅读 2022-03-10 23:03:20
    传输协议介绍**传输层**TCP报文段 传输层 定义协议的端口号,以及流控和差错校验;主要包含TCP和UDP协议 TCP协议 面向连接网络协议,指通讯双方需先建立连接,才能通讯,通讯完之后断开连接。类似于语音通话 无连接...
  • 互联网中几种常用的传输协议

    万次阅读 多人点赞 2018-11-10 16:27:09
    互联网中几种常用的网络传输协议 网路传输协议多种多样,各有所长,学起来真的很让人头大。 对协议的学习需要不断地使用不断加深理解。本篇就是我的个人学习笔记。 --一个正在努力学习的码农新人 协议那么多...
  • 数据传输的大致步骤: 配置传输方法——选择事务——发送各种令牌、数据、握手包 传输方法 既然USB是用来进行数据传输的,那么必然会涉及到配置传输方法: 批量传输、中断传输、同步传输、控制传输。 1、批量...
  • 视频传输协议总结、码率

    万次阅读 2018-04-21 09:08:31
    视频图像传输有以下几个...UDP是User Datagram Protocol的简称,中文名是用户数据协议,是OSI参考模型中一种无连接的传输协议。正式通信前不必与对方先建立连接,直接向接收方发送数据,是一种不可靠的通信协...
  • JSON网络传输协议

    万次阅读 2016-10-19 22:19:09
    JSON网络传输协议 JSON是在移动端比较常见的网络传输协议,它较xml格式更叫的简单和“小”,因此比xml更适合移动端对流量和内存的控制。 优点:较XML格式更加小巧;  缺点:传输效率也不是太别高,但相较...
  • 传输层有两个协议,一个是TCP(可靠传输协议),一个是UDP(不可靠传输协议)。 根据五层模型,传输层接收的是网络层数据,也就是说TCP接收的数据(报文段)是由IP传送的,而IP只能提供不可靠传输服务,所以传输层在不加...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 805,512
精华内容 322,204
关键字:

数据传输协议

友情链接: cvx.zip