【Java EE初阶十六】网络原理(一)

        在网络原理中主要学习TCP/IP四层模型中的重点网络协议

1. 应用层

1.1 应用程序与协议

        应用层是和程序员接触最密切的;

        应用程序:在应用层这里,很多时候都是程序员自定义应用层协议(步骤:1、根据需求,明确要传输的信息,2、约定好信息按照什么样的格式来组织)的;所谓的网络协议其实就是约定,即程序员在代码中规划好,数据如何进行传输;

        下面是自定义协议的例子:

1、点外卖
        点开外卖软件,首先会看到商家列表, 这里就涉及到程序和服务器之间进行的网络通信交互

2、请求: 用户信息, 位置信息,
        此处假设就使用简单的格式来组织,使用文本的方式.三个属性,使用""来分割
1000,100,30()--->代码中构造出一个这样的字符串,给写入到 Tcp socket 或者 Udp 的 socket 中

3、响应: 商家列表(多个商家),每个商家,包含 名称,图片,距离,简介,评分.
        此处假设使用简单的格式来组织,使用文本的方式,每个商家信息占一行,每个属性使用","来分割
过桥米线,图片地址1,1.1km,评分5
张亮麻辣烫,图片地址2,2.3km,评分4.8
魏家凉皮,图片地址3,3km,评分4.9

        上述这个过程,就是自定义协议.针对这里的情况,使用啥样的格式来组织,只要客户端和服务器双方能够对应上都是可以的;

1.2 开发中构造协议的格式

1.2.1 xml

        (通过标签来组织数据)

        早期的组织数据的格式,现在几乎很少用于网络通信,下图是代码展示:

xml 的优势:
        让数据的可读性变的更好;

xml 的劣势:
        标签写起来非常繁琐,传输的时候也占用更多网络带宽,(maven, 就会使用 xml 来管理项目配置)

1.2.2 json

        (当下最流行的一种数据组织格式)

         json格式使用键值对,通过{ }把所有的键值对给包裹起来,键值对之间,使用","来分割,键和值之间,使用 ": ” 来分割,其中键固定就是 string 类型,值的话,可以是数字,可以是字符串,也可以是 json,还可以是数组;由于 json 的 key 固定就是字符串类型,很多时候也是可以把 key 的引号给省略的

        下图是代码展示:

json 的优势:

        可读性比较好的; 比 xml 更简洁.

json 的劣势:        
        同样也是会在网络传输中,消耗额外的带宽 (需要把 key 也进行传输的)

虽然如此,json 在网络通信中仍然非常流行,除非是些对于性能要求非常高的场景,不使用json 之外,其余的很多地方都可以使用 json

1.2.3 protobuffer

        相比于json 和 xml 来说,protobufer (简称为 pb)使用二进制的方式来组织数据,可以保证带宽占用最低(相当于把要传递的信息按照二进制形式压缩了)
pb 的优势:.
        占用带宽最低,传输效率最高.非常适合于对于性能要求比较高的场景,
pb的劣势
        可读性不好(二进制结构,肉眼无法直接阅读),一定程度的影响开发效率,

        应用层中也有一些"现成"的应用层协议,其中最知名的,最广泛使用的,就是 HTTP 协议了(超文本传输协议)~~>“超文本”不仅仅是文本,还有图片,视频,音频,字体.. 

2. 传输层

        传输层中使用到的协议主要有TCP和UDP协议:

        端口号:写一个服务器,必须手动指定一个端口号,通过端口来区分当前这个主机上的不同的应用程用,客户端在通信的时候也会有一个端口号(代码中感受不到),系统自动分配的一个客户端,
        端口号,固定就是占2 个字节.表示的数据范围0->65535,一般来说,0是不用的.其中1-1023 称为"知名端口号,1024-65535 普通的端口号,平时自己写代码,用的端口还是普通的端口号为好一点;

2.1 UDP协议

2.1.1 udp报文格式

        学习一个协议,其中最主要的工作,就是去理解协议报文格式。

        udp协议的报文格式总体如下图所示:

        udp协议的报文格式的详细分析图如下图所示:

       源 ip, 目的 ip 不在传输层,而是在网络层 (IP 协议里);像UDP,TCP这样的报文格式,是最初一些大佬们设计并约定出来的内容,最后被整理成了一份标准文档,称为RFC标准文档;

2.1.2 报文案例分析

        用户使用浏览器进行搜索原理如下图所示:

        于业务的发展,搜集信息越来越多了,样式也越来越复杂了.导致商搜服务器和入口服务器之间交互的数据量,已经接近 64kb (udp报文长度就是64kb)了.如果超过上限,数据就会出现截断,最终展示在页面上的数据肯定就会出错
        方案一:把数据拆分成多个包,使用多个 UDP 数据报进行传输.(开发成本,比较大)       

        方案二:直接使用 TCP.TCP 没有数据包的大小限制.

2.1.3 关于校验和

         校验和是计算机中非常广泛使用的概念.由于在网络传输中,一些设备被外部干扰,就可能会出现数据传输出错的情况.在数据传输的过程中低电平被干扰之后扰下就成了高电平,因此, 就需要校验和这一方法来识别出出错的数据.
        校验和,其实本质上也是一个字符串,体积比原始的数据更小,又是通过原始的数据生成的.
如果接收方收到的原始数据相同,得到的校验和就一定相同,;同理,校验和相同,原始数据大概率相同 (理论上会存在不同的情况, 实际的概率非常低,可以忽略不计)

        如何基于校验和来完成数据校验呢
1、发送方,把要发送的数据整理好(称为 data1),通过一定的算法,计算出校验和 checksum1;

2、发送方把data1和checksun1一同发送出去;

3、接收方收到数据,收到的数据称为 data2(数据可能和 data1 就不一样了),收到数据 checksum1;

4、接收方再根据 data2 重新计算校验和 (按照相同的算法),得到 checksum2
5、对比 checksum1 和 checksum2 是否相同.如果不同,则认为 data2 和 data1 一定不相同
如果 checksum1 和 checksum2 相同,则认为 data1 和 data2 大概率是相同的(理论上存在不同的可能性,概率比较低,工程上忽略不计)

        关于校验和的计算方法:

        计算校验和,有很多种算法,
1、此处 UDP 中使用的是 CRC 算法(循环冗余算法)
        把当前要计算校验和的数据,每个字节,都进行累加,把结果保存到这 两个字节的变量中,累加过程中如果溢出,也没关系;如果中间某个数据,出现传输错误,第二次计算的校验和就会和第一次不同
        CRC 这个算法其实不是特别的靠谱,导致两个不同的数据,得到相同的 crc 校验和的概率比较大(前一个字节恰好少1,后一一个字节恰好多1.)

2、md5/sha1 算法 (就只介绍 md5)
        这里有一系列的公式,来完成 md5 的计算,(咱们不需要考虑公式是啥样的,是一个
数学问题),但是咱们需要知道 md5 的特点:

        1.定长,无论你原始数据多长,计算得到的 md5,都是固定长度->校验和本身就不应该很长,要不然不方便网络传输
        2.分散,给定两个原始数据,哪怕绝大部分内容都一样,只要其中一个字节不同,得到的 md5 值都会差异很大(md5 也非常适合作为 hash 算法)
        3.不可逆。给定一个原始数据, 计算 md5,非常容易。但是给定 一个md5,还原出原始数据, 计算量非常庞入,以至于超出了现有计算机的算力极限,理论上是不可行的.

2.1.4 关于udp的特点分析

        通过之前所写的基于udp实现的通信代码来分析相关的特点:

1、无连接.UDP 协议本身不会存储对端的信息,要在发送数据的时候,显式指定要传输给谁

2、不可靠,代码中体现不出来

3、面向数据报

4、全双工 通过一个 socket,既可以 send, 又可以 receive

 2.1.5 基于UDP的应用层协议

NFS:网络文件系统

TFTP:简单文件传输协议

DHCP:动态主机配置协议

BOOTP:启动协议(用于无盘设备启动)

DNS:域名解析协议

2.2 TCP协议

        TCP协议最大的特点就是可靠性传输;

2.2.1 TCP报文格式

        TCP报文格式如下图所示:

        首先:数据报 = 首部(报头 header) + 载荷 

四位首部长度:

        tcp报头长度是不固定的,报头最短,是20字节(没有选项);报头最长是60字节(一般来说选项最长的是40字节),4bit=>(0,0XF)此处的单位是4字节

保留(6位):

        UDP 有个问题,udp报文长度 64kb是固定的;所谓的保留位, 就是当前现在不用,但是先占个位置,后面如果有需要,再使用.(留下了扩展的余地~~)

16位检验和:

        和 udp 一样的校验和一样;

2.2.2 关于可靠传输

        可靠传输,是 TCP 最最核心的特性 (初心),并不是说,发送方把数据能够 100% 的传输给接收方,而是退而求其次:
1、发送方发出去数据之后,能够知道接收方是否收到数据.
2、一旦发现对方没收到,就可以通过一系列的手段来"补救.

        下面是一些确保信息可靠传输的补救手段:

1、确认应答
        发送方,把数据发给接收方之后,接收方收到数据就会给发送方返回一个应答报文(acknowledge, ack).发送方如果收到这个应答报文了,就知道自己的数据是否发送成功了;

        但是每天请求能及时的收到正确的应答这个情况太理想了,实际上网络传输数据可能会出现(后发先至--->一个数据包在进行传输的过程中走的路径可能是非常复杂的.即不同的数据包,可能走不同的路线.)这样的情况‘;

        TCP在此处要完成两个工作:
        1、确保应答报文和发出去的数据, 能对上号,不要出现歧义
        2、确保在出现后发先至的现象时,能够让应用程序这边仍然按照正确的顺序来理解数据

        所谓的序号就是一个整数.大小关系,就描述了数据的先后顺序,准确的说,序号不是按照"一条两条"方式来进行编号的,而是按照字节来编号的,因为tcp是面向字节流的;

        对于序列号并不是我们自己设定的,序列号的情况如下图所示:

        通过特殊的 ack 数据包,里面携带的"确认序号"告诉发送方,哪些数据已经被确认收到了
此时发送方,就心中有数了,就知道了自己刚发的数据是到了还是没到.=>TCP 的初心,是为了实现可靠传输 =>达成可靠传输的最核心的机制, 就是确认应答

        q1:如何区分一个数据包是普通的数据,还是 ack 应答数据呢?

        

        q2:为啥确认序号是现在这样的规则?即用收到的最后一个字节的序号+1来表示呢
        主要是为了关联后面的知识->滑动窗口,

2、超时重传

        确认应答,描述的是一个比较理想的情况。但是如果网络传输过程中,出现丢包,则发送方,势必就无法收到 ACK 了,所以使用超时重传机制,针对确认应答,进行补充.

        为什么会丢包?
        把网络想象成公路,即错综复杂的公路网,在公路上就会有很多的收费站。平时车流量很通畅,但是当节假日的时候,收费站这里经常会堵车好几个小时;
        在网络中,“收费站"可以理解成是一些路由器/交换机,如果数据包太多了,就会在这些路由器/交换机上出现"堵车",但是路由器针对“堵车”的处理,不会把这些积压堵塞的数据包都保存好,而是会把其中的大部分数据包直接给丟弃掉.此时这个数据包就在网络上消失了,

        真实的网络环境,是错综复杂的,我们不会知道哪个节点上会出现上述"堵车"情况,也不知道啥时候会出现丢包, 丟包是非常随机的事件.这个事情出现概率的大小,取决于网络基础设施施,同时也取决于网络环境.

        综上所述,丢包是一个"随机”的事件,因此在上述 tcp 传输过程中,丢包就存在两种情况.

情况一:传输的数据丢了

情况二:返回的 ack 丢了

        对于发送方的来说,无法区分这两种情况.无论出现上述哪种情况,发送方都会进行"重新传输”第一次是丢了,重传一下很大概率就能传过去;重传就是一个很好的丢包下的补救措施了

        q3:发送方,何时进行重传?

        引入等待时间,发送方发出去数据之后, 会等待一段时间, 如果这个时间之内, ack 来了,此时就自然视为数据到达;如果达到这个时间之后,数据还没到,就会出发重传机制

        q4:关于等待时间

        1、初始的等待时间,是可配置的.不同的系统上都不一定一样,也可以通过修改一些内核参数来引起这里的时间变化.
        2、等待的时间,也会动态变化.每多经历一次超时,等待时间都全变长(变长,隐含的含义,就是对能够正确传输数据这件事,前面按照丢包概率 10% 计算,每次重传一次都会让传输成功的概率大幅度增加.)

        eg:A->B发了一条数据,
        第一次,A 等待 ACK 的时间,假设是 50ms,此时如果达到 50ms, 还没有 ack,A 就重传;
当 A 重传的数据,还是没有收到 ack,第二次等待的时间就会比第一次更长,拉长也不是无限拉长,重传若干此时,时间拉长到一定程度,认为数据再怎么重传也没用了, 就放弃 tcp 连接(准确的说是会触发 tcp 的重置连接操作)

        q5:关于接受端收到两条一样的数据的bug处理

        其实 TCP 已经非常贴心的帮我们把这个问题解决了;TCP 会有一个"接收缓冲区",就是一个内存空间,会保存当前已经收到的数据,以及数据的序号;
        接收方如果发现,当前发送方发来的数据,是已经在接收缓冲区中存在的 (收到过的重复
数据了),接收方就会直接把这个后来的数据给丢弃掉,确保应用程序进行 read 的时候,
读到的是只有一条数据,

        所谓的接受缓冲区,不仅仅是能进行去重,还能进行重新排序,确保发送的顺序,和应用程序读取的顺序是一致的;

3、连接管理
        即建立连接 + 断开连接

        建立连接:

        握手,只是为了唤起对方的注意,tcp 这里的握手,也是类似给对方传输一个简短的,没有业务数据的数据包,并通过这个数据包,来唤起对方的注意,从而触发后续的操作.

        TCP 的三次握手.TCP 在建立连接的过程中,需要通信双方一共"打三次招呼”才能够完成连接建立的,简单分析图如下所示:

        A 想和 B 建立连接,A 就会主动发起握手操作;实际开发中,主动发起的一
方, 就是所谓的"客户端,被动接受的一方,就是"服务器”(同步报文段,就也是一个特殊的 TCP 数据包,没有载荷的 (不携带业务数据的))

        q6:三次握手是要解决什么问题?通过四次握手,是否可行?通过两次握手,是否可行呢?

        可以, 但是没必要.两个数据合并成一个数据效率更高.

        q7:三次握手核心作用:

1、确认当前网络是否是畅通的,

2、要让发送方和接收方都能确认自己的发送能力和接收能力均正常

3、让通信双方,在握于过程中,针对一些重要的参数进行协商

        握手这里要协商的信息,其实是有好几个的,至少大家要知道,tcp 通信过程中的序号从几开始,就是双方协商出来的(一般不是从1 开始的),每次连接建立的时候,都会协商出一个比较大的,和上次不太一样的值.

        这种设定方式,是避免“前朝的剑,斩本朝的官"----->

        有的时候,网络如果不太好,客户端和服务器之间可能会连接断开, 再重新建立连接;重连的时候, 就可能在新的连接好了之后,旧连接的数据姗姗来迟,这种迟到的数据,应该要丢弃掉的! 不应该让这个之前的的数据影响到本次的业务逻辑~
        如何区分数据是否是来自于上个朝代?就可以通过上述序号的设定规则来实现->如果发现收到的数据序号和当前正常数据的序号差异非常大就可以判定为是上个连接的数据就可以直接丢弃了;

断开连接,四次挥手:

        建立连接,一般都是客户端主动发起;断开连接,客户端和服务器都可以主动发起

        四次挥手的简单分析如下所示:

        q8:和 三次握手 不同,此处的四次挥手,能否把中间的两次交互合二为一?不一定!!

        不能合并的原因是因为ACK 和 第二个 FIN 的触发时机是不同的.ACK 是内核响应的.B 收到 FIN,就会立即返回 ACK;第二个 FIN 是应用程序的代码触发.B 这边调用了 close 方法才会触发 FIN ->

        从服务器收到 FIN(同时返回 ACK),再到执行到 close发起 FIN,这中间要经历多少时间,经历多少代码,是不确定的!!FIN 就会在 socket 对象 cose 的时候, 被发起.可能是手动调用 close 方法也可能是进程结束.故此综上所述:

       象前面的三次握手, ACK 和 第二个 syn 都是内核触发的.因为是同一个时机,可以合并;但是这里的四次挥手, ACK 是内核触发的,第二个 FIN 是应用程序执行 close 触发的,二者的的触发时机不相同,所以不能合并.

        是否意味着,如果我这边代码 close 没写/没执行到,是不是第二个 FIN 就一直发不出去??(有可能的),并非所有的连接都是好聚好散;但是,TCP 中还有一个机制->延时应答,(后面再说),能够拖延 ACK 的回应时间一旦 ACK 滞后了,就有机会和下一个 FIN 合并在一起了

        

        q8:TIME_WAIT 状态主要存在的意义?

        如果最后一个 ACK 丢了,站在 B 的角度,B 就会触发超时重传重新把刚才的 FIN 给传一遍,如果刚才 A 没有 TIME WAIT 状态, 就意味着 A 这个时候就已经真的释放连接了,此时重传的 FIN 也就没人能处理, 没人能返回 ACK 了.B 永远也收不到 ACK 了

        A这边使用 TIME_WAIT 状态进行等待,等待的这个时间,就是为了处理后续 B 重传的 FIN此时有重传的 FIN 来了, 就可以继续返回 ACK 了.B 这边的重传 FIN 才有意义.

        q9:TIME WAIT 等待多久呢?

ps:本篇的内容就到这里了,如果大家感兴趣的话就请一键三连哦!!!

       

        

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/261743.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

程序员必备技能----删库跑路大总结

删库跑路大总结,各个都是大杀器,破坏性太大,轻易不要尝试。 删除linux根目录,用户目录,其实还可以增加一个删除/etc。删除(清除)数据库。删除redis缓存和持久化文件。删除mongodb库。git push …

MCAL知识点(二十七):TC275如何通过GPT12实现ABZ解码

目录 1、概述 2、代码实现 1、概述 GPT12 - General Purpose Timer Unit (GPT12):通用定时器单元,具备较为灵活的定时器结构,可以用来做定时器、事件计数、脉冲宽度测量、产生PWM、频率调制、ABZ编码器增量测量。文章记录一下如何通过GPT12实现编码器ABZ信号的测量。 注意…

c#创建安装windows服务

背景:最近在做设备数据对接采集时,遇到一些设备不是标准的Service-Client接口,导致采集的数据不够准确;比如设备如果中途开关机后,加工的数量就会从0开始重新计数,因此需要实时监控设备的数据,进行叠加处理;考略到工厂设备比较多,实时监听接口的数据为每秒3次,因此将…

week04day01(爬虫)

一. 爬虫 只爬取公开的信息,不能爬取未公开的后台数据 1.爬虫的合法性 法无禁止皆可为 -- 属于法律的灰色地带https://www.tencent.com/robots.txt -- 网站/robots.txt 可以查看禁止爬取的内容 2. URL Uniform Resource Locator 统一资源定位符https://www.…

【国产MCU】-CH32V307-通用定时器(GPTM)-单脉冲模式

通用定时器(GPTM)-单脉冲模式 文章目录 通用定时器(GPTM)-单脉冲模式1、单脉冲模式介绍2、驱动API介绍3、单脉冲使用实例本文将详细介绍如何使用CH32V307通用定时器的单脉冲模式。 1、单脉冲模式介绍 单脉冲模式可以响应一个特定的事件,在一个延迟之后产生一个脉冲,延迟…

Sora--首个大型视频生成模型

Sora--首个大型视频生成模型 胡锡进于2024年2月20日认为:台当局怂了 新的改变世界模拟器视觉数据转换视频压缩时空补丁(Spacetime Laten Patches)视频生成扩展变压器算法和模型架构结语 胡锡进于2024年2月20日认为:台当局怂了 **T…

AI Agent规划能力全面拆解

“规划今天和每天的工作,然后执行规划” -- 撒切尔夫人 规划,无论对于人类还是智能体而言,本质上是一种预先设定行动的过程,以期望通过这些行动达到特定的目标或解决特定的问题。制定一个好的规划涉及对未来情景的预测、资源的…

机器学习面试:逻辑回归与朴素贝叶斯区别

逻辑回归与朴素贝叶斯区别有以下几个方面: (1)逻辑回归是判别模型,朴素贝叶斯是生成模型,所以生成和判别的所有区别它们都有。 (2)朴素贝叶斯属于贝叶斯,逻辑回归是最大似然,两种概率哲学间的区别。 (3)朴素贝叶斯需要条件独立假设…

ClickHouse--12-可视化工具操作

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 文章目录 可视化工具操作1 tabixhttp://ui.tabix.io/ 2 DBeaverhttps://dbeaver.io/download/ 可视化工具操作 1 tabix tabix 支持通过浏览器直接连接 ClickHouse&#xff…

【Django】Django自定义后台表单——对一个关联外键对象同时添加多个内容

以官方文档为例: 一个投票问题包含多个选项,基本的表单设计只能一个选项一个选项添加,效率较低,如何在表单设计中一次性添加多个关联选项? 示例代码: from django.contrib import adminfrom .models impo…

springboot207基于springboot的实习管理系统

实习管理系统的设计与实现 摘要 近年来,信息化管理行业的不断兴起,使得人们的日常生活越来越离不开计算机和互联网技术。首先,根据收集到的用户需求分析,对设计系统有一个初步的认识与了解,确定实习管理系统的总体功…

消息队列MQ 保证消息不丢失(消息可靠性)

文章目录 概述RabbitMQ 怎么避免消息丢失(可靠传输)RocketMQ 怎么确保消息不丢失Kafka 怎么保证消息不丢失activeMQ 怎么避免消息丢失MQ 宕机了消息是否会丢失线上服务宕机时,如何保证数据100%不丢失吗?消息队列消息持久化 概述 …

一周学会Django5 Python Web开发-Django5路由重定向

锋哥原创的Python Web开发 Django5视频教程: 2024版 Django5 Python web开发 视频教程(无废话版) 玩命更新中~_哔哩哔哩_bilibili2024版 Django5 Python web开发 视频教程(无废话版) 玩命更新中~共计25条视频,包括:2024版 Django5 Python we…

JDK8 升级至JDK19

优质博文IT-BLOG-CN 目前部分项目使用JDK8,部分项目使用JDK19因此,环境变量中还是保持JDK8,只需要下载JDK19免安装版本,通过配置IDEA就可以完成本地开发。 一、IDEA 环境设置 【1】通过快捷键CTRL SHIFT ALT S或者File->P…

【SpringBoot3】Spring Security 常用注解

注:本文基于Spring Boot 3.2.1 以及 Spring Security 6.2.1 Spring Security 6 的常用注解包括以下几种,通过这些注解可以更加方便的控制资源权限。 Secured :方法执行前检查,直接判断有没有对应的角色PreAuthorize:方…

力扣102 二叉树的层序遍历 Java版本

文章目录 题目描述思路代码 题目描述 给你二叉树的根节点 root ,返回其节点值的 层序遍历 。 (即逐层地,从左到右访问所有节点)。 示例 1: 输入:root [3,9,20,null,null,15,7] 输出:[[3],[…

ubuntu22.04-磁盘管理-虚拟机动态扩容-系统monitor

文章目录 1.虚拟机2.ubuntu设置3.命令查看4.系统资源管理器 1.虚拟机 关闭ubuntu22.04,然后修改虚拟机设置,如下图所示: 修改容量 2.ubuntu设置 搜索打开disks,如下图所示: 选择目标磁盘,选择调整大小…

利用LaTex批量将eps转pdf、png转eps、eps转png、eps转svg

1、eps转pdf 直接使用epstopdf命令(texlive、mitex自带)。 在cmd中进入到eps矢量图片的目录,使用下面的命令: for %f in (*.eps) do epstopdf "%f" 下面是plt保存eps代码: import matplotlib.pyplot as…

LeetCode每日刷题:101. 对称二叉树

题目: 解题思路:可以新写一个函数,从root开始,root的left的头结点将记为lefttree(左子树),root的lright的头结点将记为righttree(右子树), 然后递归左子树的root.left与右…

2024.2.22

1> 将互斥机制的代码实现重新敲一遍 #include<myhead.h> int num520; //临界资源 //1、创建一个互斥锁变量 pthread_mutex_t mutex; void *task1(void *arg) {printf("11111111\n");//3、获取锁资源pthread_mutex_lock(&mutex);num1314;sleep(3);pr…