西宁做网站建设公司哪家好,WordPress有哪些工具,html5网站开发开题报告,十大网页设计网站目录
一、应用层
举个例子#xff1a;点外卖
约定数据格式简单粗暴的例子
客户端和服务器的交互#xff1a;
序列化和返序列化
xml、json、protobuffer
1、xml
2、json
3、protobuffer
二、传输层
端口
端口号范围划分
认识知名的端口号
三、UDP协议
端口
U…目录
一、应用层
举个例子点外卖
约定数据格式简单粗暴的例子
客户端和服务器的交互
序列化和返序列化
xml、json、protobuffer
1、xml
2、json
3、protobuffer
二、传输层
端口
端口号范围划分
认识知名的端口号
三、UDP协议
端口
UDP长度
UDP校验和
UDP特点
面向数据报
UDP使用注意事项
基于UDP的应用层协议 一、应用层 我们之前编写完了基本的 java socket 要知道我们之前所写的所有代码都在应用层中都是为了完成某项业务如翻译等。关于应用层,后面会有专门的讲解在此处先讲一下基础知识。 应用层对应着应用程序程序员打交道最多的就是这一层调用系统提供的 网络api 写出的代码都是属于应用层的。 应用层这里当然也有很多现成的协议但更多的程序员需要根据实际场景自定义协议网络传输的数据要怎么使用也要考虑数据是什么样的格式里面包含了哪些内容。 而协议就是一种约定虽然存在很多现有的协议一般都是大佬们已经搞好了的但除此之外咋们程序员也可以自己来约定协议。 自定义协议要约定好两方面内容如下 1、服务器和客户端之间要交互哪些信息 2、数据的具体格式 客户端按照上述约定发送请求服务器按照上述约定解析请求。 服务器按照上述约定构造响应客户端也按照上述约定解析响应。
举个例子点外卖 打开点餐软件显示出页面页面里就会显示出商家列表而这些商家都是在你附近的打开软件的时候就会把你的位置告诉给点餐软件的服务器 显示的商家列表也会包含一些信息商家的名称、图片、商家的评分、商家的简介等等 以上交互过程中需要传输哪些信息并不是程序员规定的而是产品经理规定的。要交互哪些信息一方面是产品经理约定的一方面是程序员补充的这些都要根据 实际的场景 来确定。 上述的数据按照啥样的格式来组织就是有一些固定套路而数据格式如何组织和产品经理无关属于程序员自己的事情往往需要 客户端 的程序员 和 服务器 的程序员这两伙人坐在一起共同把这个事给敲定下来。这里的格式怎么约定都行只要这两伙程序员达成共识即可
约定数据格式简单粗暴的例子 1、请求约定使用行文本的格式来表示 userIdposition \n 一个请求以 \n 为结尾多个字段之间使用用来分割 1000[经纬度] \n 2、响应也是使用文本行来表示一个响应中可能会包含多个商家每个商家占一行每个商家要返回 id、名称、图片、评分、简介。 1001杨国福[logo图片地址]4.8非常好吃的麻辣烫 \n 1002魏家凉皮[logo图片地址]4.7很好吃的凉皮 ....... 若干行的最后使用 空行 作为所有数据的结束标记 (上面的这一系列内容是同一个响应中的数据) 上述的例子里约定的这个格式太过于简单粗暴了虽然能解决问题但实战中很少真的会这么约定这样的约定不太适合拓展可读性也不高。
客户端和服务器的交互 客户端和服务器之间往往要进行交互的是 “结构化数据”数据是还有个结构体 / 类包含很多个属性而网络传输的数据其实是 “字符串” “二进制 bit 流”。 协议约定的过程就是把结构化数据转成 字符串 / 二进制比特流 的过程。
序列化和返序列化 把结构化数据转成字符串 / 二进制比特流这个操作称为 序列化。 把字符串 / 二进制比特流 还原成结构化数据这操作称为 反序列化。
序列化 / 反序列化 具体要组织成什么样的格式这里包含哪些信息约定这两件事的过程就是 自定义协议 的过程。
xml、json、protobuffer 为了让程序员更方便的去约定这里的协议格式业界也给出了几个比较好用的方案可以直接套进来xml、json、protobuffer等待
1、xml 大概模型如下 可读性和扩展性都提升很多标签的名字可以对数据起到描述的效果后续要增加一些属性就新增一个标签即可对于已有的代码影响不大代码中按照标签名字获取到标签的值新增新的标签对于已有代码都没啥影响。 缺点整个数据冗余信息非常多标签描述性信息占据的空间反而比数据本身更多尤其是网络传输的时候这些数据都要通过网络传输的消耗带宽而国内最贵的硬件资源就是网络带宽。 当前存在大量的库可以方便我们解析处理 xml 格式的数据通过这些库就可以使用 xml 来进行数据的组织和传输保存。
2、json 非常主流 / 非常常用的数据组织格式大概模型如下 键值对结构键和值之间的使用分割简直对的使用进行分割 把若干个键值对使用 { } 括起来此时就形成了一个 json 对象还可以把多个 json 对象放到一起使用分隔开并且使用 [ ] 整体括起来就形成了 json 数组。 json的可读性很好扩展性也很好通过 key 来对数据起到解释寿命对于 xml 来说解释说明通过标签需要有开始和结束两个标签比较占用空间。相比之下json值使用一个key就能描述占用空间比xml更少就更节省带宽了。 虽然 json 比 xml 节省了带宽但是很明显当前这里的带宽仍然是有浪费的部分尤其是这种数组格式的 json这种情况下往往传输的数据字段都是相同的使刚才这里的key名字被重复传输了。
3、protobuffer 更节省带宽的效率最高的方式 只是开发阶段代码定义出这里都有哪些资源描述每个字段的含义。程序真正运行的时候实际传输的数据是不包含这样的描述信息。而这样的数据是按照二进制的方式来组织的。 因为数据是按二进制的方式传输的所以这样的设定是最高效的做法程序运行的效率高但并不有利于程序员阅读。 虽然 protobuffer 运行效率更高但是使用的并没有 json 更广泛。只是那些对于性能要求非常高的场景才会使用 protobuffer。应用层也有很多现成的协议比如 HTTP 这种HTTP 协议非常重要独立成章节。 二、传输层 负责数据能够从发送端到接收端。这一层是系统内核实现好了的提供socket的api供程序员使用。
端口 端口号端口号是一个 2 个字节的整数使用端口号的时候1~1024 都属于系统保留自用的端口知名端口号。 端口号(port)标识了一个主机上进行通信的不同的应用程序。 在TCP/IP协议中用源IP源端口号目的IP目的端口号协议号这样一个五元组来表识一个通信。 端口号范围划分 0-1023知名端口号如HTTPFTPSSH 等这些广为使用的应用层协议他们的端口号都是固定的。 1024-65535操作系统动态分配的端口号。客户端程序的端口号就是由操作系统从这个范围中分配的。 认识知名的端口号 有些服务器是非常常用的为了使用方便人们约定一些常用的服务器都是用以下固定的端口号 ssh服务器使用22端口 ftp服务器使用21端口 telnet服务器使用23端口 http服务器使用80端口 https服务器使用443 我们自己写一个程序使用端口号时要避开这些知名端口号。 三、UDP协议 UDP协议是传输层中的其中一个协议具有 无连接、不可靠传输、面向数据报、全双工的特点。研究一个协议主要就是研究报文格式基于报文格式了解这个协议的其他各个特性。 UDP 数据报 报头重点 载荷应用层数据包 UDP报头一共有 4 个字段每个字段 2 个字节一共 8 个字节 16位UDP长度表示整个数据报(UDP首部 UDP数据)的最大长度。 如果校验和出错直接丢弃。 端口 由于协议报头使用 2 个 字节表示端口号端口号的取值范围就是0 ~ 65535最大值是64K。
UDP长度 因此一个 UDP 数据报最大长度就是 64K无法更长了整个数据报的长度超出 64 K此时就可能导致数据出现 截断本来数据是完整的后面的部分没了。 总的 UDP 数据报最大长度是 64 K载荷部分实际能承担的最大长度应该是 64K - 8但是 64K - 8 约等于 64K使用语言表述的时候会采取 约数 的这种近似值。
UDP校验和 校验和 的作用就是用来识别当前的数据是否出现 比特翻转是否是正确的数据。 验证数据在传输过程中是否正确。因为数据在网络传输过程中可能会坏掉。 网络数据传输本质上是光信号 / 电信号 / 电磁波因此在传输过程中就可能会收到干扰 外界有形形色色的电磁波传输数据时是使用高电平 低电平 表示 0 1这时外界如果加上一个磁场就可能把其中 低电平 变成 高电平此时出现 0 - 1 或者 1 - 0这种情况这种情况称为比特翻转。 像十几年前的时候如果出现太阳黑子 / 太阳耀斑就会引起地球上的通信中断现代的传输体系其实有一系列的保护机制减少外界的干扰现在的技术更加发达、成熟不太害怕这些影响影响还是有的只不过少很多了。 在 UDP 中校验和使用比较简单的方式CRC算法来完成校验循环冗余校验。 UDP 数据报发送方在发送之前会先计算一遍 CRC把算好的 CRC 值放到 UDP 数据报中设这个 CRC 值为 value1。接下来这个数据报通过网络传输到达接收端接收单收到这个数据之后也会按照同样的算法再计算一遍 CRC 的值得到的结果是 value2比较自己计算的 value2 和收到的 value1 是否一致如果是一致就说明数据是ok的如果不一致传输过程就发生了比特翻转了。 上述 CRC 算法中如果只有一个 bit 位发生翻转此时 100% 能够发现问题。如果有两个 / 多个比特位发生翻转校验和有可能恰好和之前的一样这种情况概率比较低可以忽略不计如果希望这里有更高的检查精度就需要使用其他的更严格的校验和算法了。 所以严格的来说校验和只能用来 “证伪”证明数据是出错了无法确保这个数据 100% 正确但时间中可以近似的人为校验和一致原来的数据就是一致的。 除 CRC 算法外还有一些更高精度的校验和算法。业界还有其他常用的算法md5 算法 / sha 1算法。如图 UDP特点 UDP传输过程类似于寄信。 1.无连接知道对端的IP和端口号就可以直接传输不需要建立连接。 2.不可靠没有确认机制没有重传机制如果因为网络故障无法发送到对方UDP协议层也不会给应用层返回任何错误信息。 3.面向数据报不能够灵活的控制读写数据的次数和数量。 4、全双工 面向数据报 应用层交给UDP多长的报文UDP原样发送既不会拆分也不会合并。 用UDP传输100个字节的数据。 如果发送端调用一次sendto发送100字节那么接收端也必须调用对应的一次recvfrom接收100个字节而不能循环调用10次recvfrom每次接收10个字节。 UDP使用注意事项 我们注意到,UDP协议首部中有⼀个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。 然而64K在当今的互联网环境下是⼀个非常小的数字。 如果我们需要传输的数据超过64K,就需要在应用层手动的分包,多次发送,并在接收端手动拼装。 基于UDP的应用层协议 NFS网络文件系统 TFTP简单文件传输协议 DHCP动态主机配置协议 BOOTP启动协议(用于无盘设备启动) DNS域名解析协议 也可以根据需求自定义协议。 都看到这了点个赞再走吧谢谢谢谢谢
