自学网站设计与建设,深圳网页设计兴田德润放心,辽宁建设工程造价信息网,linux网站做301重定向一)应用层协议简介:根据需求明确要传输的信息#xff0c;明确要传输的数据格式#xff1b; 应用层协议:这个协议#xff0c;实际上是和程序员打交道最多的协议了 1)其它四层都是操作系统#xff0c;驱动#xff0c;硬件实现好了的#xff0c;咱们是不需要管 2)应用层:当我… 一)应用层协议简介:根据需求明确要传输的信息明确要传输的数据格式 应用层协议:这个协议实际上是和程序员打交道最多的协议了 1)其它四层都是操作系统驱动硬件实现好了的咱们是不需要管 2)应用层:当我们继续进行写应用程序的时候尤其是应用程序负责网络通信的时候往往是需要自定义应用层协议的我们要根据需求明确要进行传递的信息我们还要明确传递的数据格式 3)应用层这里面最重要的事情就是说自己实现一个应用层协议比较简单也是在工作中经常做的事情 FTPSSHTELNETDNS(域名解析的协议) 1)使用现成的应用层协议来进行开发 2)程序员自己约定一个协议来进行开发只要客户端和服务器自己进行开发的例如我在网页上面给服务器发送了一个请求请求中包含着一个链接然后服务器给浏览器返回了一个响应这个响应就是一个网页在这个过程中使用的协议就是HTTP协议这时就可以 使用自定义协议来约定好请求是什么格式响应是什么格式客户端和服务器就可以按照这样的约定来进行开发了 3)总而言之自定义协议其实是一个很简单的事情只需要约定请求和响应的详细格式即可越详细越好要把各种细节都能够交代到能够更好的表示当前的信息咱们也可以自己来约定好格式也可以基于xmlJson来约定数据格式甚至还可以通过一些其他的二进制的方式来进行约定数据 1)例如我们要提供一个新的需求要求在外卖软件的首页显示一个优惠活动用户参与活动就可以参加抢红包的操作; 2)客户端:修改界面可以显示优惠活动的详情; 3)服务器:修改后台逻辑针对啥样的用户可以参加优惠具体怎么做可以领到红包红包金额是多少; 4)当的客户端启动的时候就要向服务器进行查询当前用户是否可以进行参加活动服务器就要返回是或者否 5)这个时候在开发功能之前就要约定好客户端发的查询请求的功能是怎么样的(带有用户的身份信息)在约定好服务器返回的响应是什么样的(1表示可以表示能参与0表示不能参与true表示能参与false表示不能参与) 1)假设现在自己实现一个功能叫做获取用户的订单历史(这个订单历史在数据库里面我们要从服务器操作数据库来拿这样的功能就会涉及到前后端的一个交互过程)咱们的前端和后端就是通过网络来进行交互的 2)在这个交互的过程中我们就需要约定好前端发送什么样子的数据后端要返回什么样子的数据本质上来说就是在进行规划请求和响应之间的信息以及传数据的格式 咱们进行查历史订单查找谁的订单以及查找哪一个时间段的订单以及数据太多你要不要截取一部分 1)我们前端发送的请求类似于: { 用户的ID 查询的起始时间 查询的结束时间 显示的条数 } 2)我们后端返回的响应: 2.1)查询是否成功如果失败原因都有哪些 2.2)返回一个订单数组: 数组里面的每一个元素: { 商品名 商品单价 商品数量 店铺名称 总的金额 } 像上面的过程就相当于是设计应用层协议咱们设计应用层协议本质上就是做两个工作 1)明确要传输的信息 2)明确数据的组织格式请求的格式是啥样子的响应是啥样子的 1)当前我们只是给出了一种可能的格式此处我们这里面的数据的格式也是可以进行随心所欲的约定的 2)相比之下我们只需要让我们的客户端和服务器都按照一定的格式来进行交互就可以了 3)上面的这一种设计十分不好咱们的输出传输效率比较低这也就说明了是运行效率低 4)咱们的这个代码可读性也不好本身开发效率也比较低正因为如此大佬们发明了一些比较好的协议的模板让我们向上套 XMLJSONprotobuffer前两种可读性比较好但是运行效率不高咱们的第三种可读性不好但是运行效率比较高 1)咱们的XML就是一种老牌的数据格式了虽然现在也在用但是越来越少了咱们的这些标签本身占据的空间已经超过了数据本身所占用的空间也就说引入了更多的辅助信息我们程序的效率就会受到很大的影响对于一个服务器程序来说最贵硬件资源就是网络带宽对于XML来说虽然提高了可读性但是又引入了太多的辅助信息比如说标签名字这些辅助信息所进行占用的空间甚至已经超过了数据本身的一个空间因为在XML里面要经常表示这些辅助信息在传输相同的网络数据的时候这就会导致传输相同数目的请求的时候占用的网络带宽是更高的如果说带宽固定那么相同时间内能够传输的请求数目就是更少的所以说我们程序的效率就会收到很大的影响 2)咱们现在看这个XML标签标签名就是key标签值就是value就构成了一个键值对通过这些标签就更好的体现了我们数据的可读性尤其是哪一个部分代表是什么意思非常一目了然咱们的一个服务器程序最贵的硬件资源就是网络带宽因此XML现在已经很少作为应用层协议的设计模板了现在使用XML主要是为了做配置文件 3)JSON的传输效率虽然要比XML要好一些但是还是要多进行传递一些冗余信息就是Key的名字但是Json格式的数据也是有非常大的缺点尤其是在进行表示数组的时候这里面的Key是在不断重复的这也会占用大量的带宽资源但是咱们的JSON是一种最重要的设计模式 4)因此咱们的protobuffer应运而生这是一种二进制格式的数据在这种格式的数据里面不会再包含上面的key的名字了而是通过顺序或者是一些特殊的符号来进行区分每一个字段的含义同时在通过一个IDL文件来进行描述这个数据格式(来进行描述每一个部分是啥意思)IDL只是起到一个辅助性开发的效果并不会真正的进行传输传输的只是二进制的纯粹的数据似乎传输效率高了但是开发效率低可能是把对应的文字换成了对应的二进制数据咱们通过二进制的数据对这里面的内容重新地进行了编排甚至有可能做出一些数据压缩只进行传递一些必要的信息传输效率会更高但是这些数据肉眼难以观察 5)开发效率低是包含了开发和调试调试很不方便如果说咱们的线上环境出现了问题如果说咱们用JSON出问题的请求和响应一目了然(一看就知道哪里出现了问题)如果使用protobuffer二进制的数据根本没法用肉眼看我们就需要自己开发一个专门的程序来进行解析这里面的数据来进行分析这里面的问题这就会比较麻烦 咱们广论开发:咱们的protobuffer里面有IDL这个就是说咱们的protobuffer约定的一种文件格式类似于C语言结构体的写法 class message Response{bool ok1;string reason2;repeated Data data3;
} 咱们来进行设计应用层协议是一件非常普遍的事情也是一种并不复杂的事情 设计应用层协议我们要做的工作就是说: 1)要根据需求明确传输的信息 2)要进行明确数据传输的格式要参考现有模板比如说JSONXMLprotobuffer 端口号的用途:标识一个进程就可以区分当前数据要交给哪个进程来处理 1)例如在开发服务器的时候首先会让服务器提供一个业务端口通过这个端口就可以提供一些广告搜索的服务(上游服务器就可以通过这个端口来获取到广告数据) 2)其次服务器还会提供一个调试端口在服务器运行过程中其实会涉及到很多很多的数据有时候为了定位一些问题就需要查看一些内存中的数据通过这些调试端口给服务器发送一些调试请求于是服务器解耦可以返回一些对应的结果; 3)直接拿调试器打一些断点可以吗? 如果拿调试器来进行断住程序此时整个进程就会处于一种阻塞的状态的这就意味着这个服务器是无法响应正常的业务请求的 4)咱们的很多网络服务是进行使用非常常用非常广泛的服务为了更好地进行管理我们就给这些服务分配一些专门的端口号 80----http服务器 443----https服务器 23 ------ssh 23------ftp服务器自己的部署http服务器就可以把他绑到80也可以把它绑到其他转口 当一个数据包到达了网卡以后然后自己主机上面的电脑的所有进程都是通过同一个网卡来传输数据的可以让每一个进程分别绑定不同的端口号此时收到的网络的数据包中也会包含一个目的端口的字段此时就会让这些目的端口找到对应的端口号的进程从而把数据交给对应的进程这个过程就是由操作系统内核来完成的 5)咱们的端口号的范围就是0-65535这里我们就需要说一些常见的知名端口号我们把0-1024这些端口号给进行划分出了一些具体的应用 6)因为咱们的很多网络服务是属于非常常见非常应用广泛的一个服务我们为了进行更好的管理我们就需要给这些服务分配一个专门的端口号一方面你见到了这个端口就知道这是什么服务另一方面我们把常见的服务的端口分配好然后我们再进行部署一些服务的时候这些服务之间的端口号就不会容易冲突 7)我们并不是强制要求而是建议因为咱们的80端口是http服务器咱们的443端口是http服务器咱们的22端口是ssh服务器咱们的23端口是ftp服务器 端口号:端口号是一个整数用来区分进程但是PID(用于进程的身份标识)也是一个整数(PCB中的一个特性)用来区分进程为什么在网络编程中不直接使用PID而是直接用到端口号这样的概念呢 端口号是固定不变的端口号我们可以手动指定但是PID每次进程启动之后都会发生改变这是系统自动分配的我们无法控制 1)例如客户端要连接一个服务器客户端就要先知道服务器的IP与PID一旦服务器进行重启PID就会发生改变 中国移动:10086--类似于端口号这是固定不变的 转换人工:工号xxx为您服务 他就类似于PID每次接通电话可能都不一样 同样的两个进程无法绑定到同一个端口号 2)系统提供的原生的socket API其中有一个方法就叫做bind功能就是把端口号和一个socket关联起来一个进程是可以绑定多个端口的 3)端口号是传输层协议的概念, TCP和UDP协议的报头中都会包含源端口和目的端口, 并且都是使用2个字节, 16bit来表示端口号, 范围也就是 0 - 65535; 但是我们日常写的程序使用的端口号一般都是从1024开始的, 因为0 - 1023这个范围的端口号也称为 “知名端口号/具名端口号”, 这些端口号系统已经分配给了一些知名并广泛使用的应用程序 4)这里我们并不是完全不能使用0 - 1023这个范围的端口号, 只是建议使用, 虽然这些端口被分配给了特定程序, 但是这些程序是否在主机运行着, 主机上是否安装了这些程序都是不一定的, 要使用0 - 1023这些端口, 需要注意2点 : 要确定这个端口没有和程序绑在一起.要拥有管理员权限. 应用层和传输层的联系:除了最上面的应用层下面的传输层网络层和数据链路层物理层这四层都已经在操作系统内核驱动程序和硬件设备已经实现好了不需要我们去实现传输层是紧接着应用层的一层, 虽然传输层是操作系统内核实现好了, 但是我们在写应用层代码的时候, 是要调用系统的socket API去完成网络编程, 所以需要我们了解这里传输层的一些关键协议UDP和TCP. 二)UDP协议:适用于数据量比较小的场景了数据载荷比较小 2.1)UDP抱头: 1)传输层是基于操作系的内核进行实现的咱们的程序员是不需要和传输层来进行打交道的但是传输层意义非常重大因为进行网络编程是需要用到Socket也就是说一旦调用了Socket代码就进入到了传输层的范畴 2)咱们一个完整的UDP数据包UDP报头UDP数据载荷UDP数据载荷就是一个完整的UDP数据包 3)所谓的把一个应用层数据报封装成UDP数据包其实本质上也就是说加上了8个字节特定含义的数据 4)咱们在代码中所写的端口号就会被打包到这样的UDP数据包里面这是我们在报头中体现的咱们以UDP客户端为例源端口也就是操作系统自动默认给客户端分配的端口目的端口也就是服务器的端口已经被指定 5)为什么端口号的范围是0-65535在UDP数据报头中最多也就给安排了两个字节的数据 6)咱们是否可以把UDP这里面的端口改成4个字节之类的呢 1)不可以一方面这个东西是操作系统内核实现的不好意思你都拿不到windows系统源码就改不了内核 2)第二方面就算你把自己的主机的UDP协议给改了那还有别人的主机呢要想改就把所有的世界上的主机都进行修改 1)咱们的入口服务器会根据请求分别从广告服务器和大搜索服务器来进行获取数据并进行拼接最终会得到一个完整的网页返回给浏览器 2)现实就是说咱们的广告服务器和入口服务器和咱们的自然搜索结果服务器和入口服务器要进行网络的传输和交互就需要选定一个好的应用层协议最开始的时候用的UDP协议 3)因为最开始的时候咱们的所进行使用的就是UDP协议但是随着时间的推移随着业务的发展咱们的广告服务器所进行吐出的业务数据越来越多更复杂 2.2)UDP校验和: UDP校验和:是验证网络传输过程中这个UDP数据是否是正确的因为咱们的网络上面的传递数据的本质是光信号和电信号 1)网络上传输的数据有可能会发生故障网络上的数据本质都是一些0/1的bit流这些bit流是通过光信号和电信号来表示的(高频率表示1低频率表示0) 2)如果在传输过程中出现了比特翻转(0-11-0)的情况尤其是卫星上面的数据要考虑比特翻转和太空上宇宙射线就比如说磁场就会使我们的原有的一些传递的信息发生了改变肯定会有一些特殊的情况会影响到我们的数据传输质量再举一个例子我们本来是想要发一组连续的高频信号因为我们遇到了一个强磁场我们就可能会导致其中的某些高频信号变成低频信号(从0变成1)在网络传输中我们一定会遇到一种情况会影响到我们的网络传输质量的本来表示0结果变成1了数据就变错了 3)校验和的本质上是检验当时数据的传输是否出问题需要尽可能识别出数据是不是错的校验和就可以帮发现数据是否错误但是校验的效果不够理想, 万一你的数据同时变动了两个bit位(前一个字节少1, 后一个字节多1), 就会出现内容变了, CRC没变这样的情况. 比如说我想要去超市买菜我妈妈让我买四样菜土豆西红柿白菜酸菜; 校验和:四样菜我们就可以根据四样菜来进行判断买菜是否正确 1)我买完之后发现手里面有5样菜或者3样菜就发现我买错了; 但是此时我发现手里面有4样菜就一定买对了吗 就是有可能是菜有猪肉羊肉西兰花韭菜 其实也不一定这是仅仅靠检验数据来进行校验的所以校验和正确不一定保证数据正确 2)校验和不一定可以百分之百的进行校验如果校验和正确不一定可以保证数据100%一定对但是如果校验和不正确这时就可以直接判断数据一定是错的 上面的一副对联就相当于是校验和就是基于内容来计算出来的校验和比如说最后一条变成了小李飞刀对联就对不上了比如说srcmd5还有sha1 2.3)UDP是如何进行数据校验的: 第一种方式:crc机制也叫做循环冗余检验例如现在有一行二进制数据依次按照字节为单位将这些字节进行累加如果说咱们的校验和数据出错那么直接丢弃 short sum;
for(byte b:数组
{sumsumb;
}
这是如果出现溢出溢出的数据就不要了 1)传输数据的时候就会把数据和src校验和一起传输给目标接收方同时收到了src校验和数据接收方就需要验证一下当前的数据是否是正确的(在网络传输中可能会出现比特反转的情况接收方再按照同样的算法再根据数据部分进行校验和把这个新计算的结果和收到的src校验和进行对比看看结果是不是一致的; 2)本质上来说就是在发送之前针对要发送的数据算一遍src接收到之后再次算一遍src把这个新算出的结果与发送过来的src的结果进行对比看看他们俩相同如果出现了比特翻转接收到的内容和发送的内容就不一样了此时算出的两份src就大概率是不会相同了其实还是有一定的概率两个不同的数据算出的src是一致的这个概率整体上来说是比较小的 3)md5算法这种算法的应用场景非常多用来做校验和只是其中的一个场景本质上是一个非对称的哈希算法 3.1)首先回顾一下哈希表它的核心是一个数组可以做到O1复杂度的增删改查借助了数组下标的随机访问能力通过key进行哈希算法转化成一个数组下标 3.2)哈希算法有很多种针对整数的哈希算法都是比较简单的 md5算法本质上是针对数据进行一系列的数学变换md5算法的特性:定长分散不可逆 1)定长:无论输入的字符串长度有多长得到的md5的值都是固定的字符串的长度(32位)4个字节64位 八个字节(128位) 2)分散:只要输入的字符串改变了一点点得到的md5的值都会差别巨大如果两个字符串的md5的值一致基本上是不可能的 3)不可逆:给定源字符串很容易算出md5的值但是对于md5的值很难算出字符串 可以作为哈希算法也可以作为校验和key是MD5value是原始字符串 4)例如在银行里面设置密码后台的工作人员可不可以看到呢 密码原文小键盘输入程序读取到这个密码之后就可以通过MD5进行加密然后数据库里面存的也是密文由于MD5不可逆的特性程序员无法感知 2.4)UDP总结: 1)无连接:知道对端的IP地址端口号就可以直接进行传输不需要建立连接 2)不可靠:没有任何的安全机制咱们的发送端发送数据包之后如果说因为网络故障导致无法收到信息UDP协议层也不会给应用层传递任何错误信息 3)面向数据包:咱们的应用层交给UDP多么长的报文UDP会原样进行发送数据既不会拆分数据也不会合并数据如果说发送端一次发送100个字节那么接收端也必须一次接受100个字节而不是说循环接收10次一次接受10个字节 4)缓冲区:咱们的UDP只有接收缓冲区没有发送缓冲区咱们的UDP没有真正意义上面的发送缓冲区我们进行发送的数据会直接交给操作系统的内核由内核直接把数据交给网络层协议来完成后续的传输动作但是咱们的UDP具有接收缓冲区但是这个接收缓冲区并不能保证咱们的收到的UDP数据包的顺序和发送UDP数据包的顺序是一致的如果缓冲区满了再次到达的UDP数据就会被丢弃 5)大小受限咱们的UDP首部长度中有一个是16位的最大长度也就是2个字节也就是说一个UDP数据包的最大传输的数据范围是64K 三)TCP协议: 1)16位源端口和16位目的端口:表示这个进程从哪里来到哪里去 2)32位序号和32位确认序号:进行编号保证可靠性 3)4位首部长度:这里面是表示四个比特位本质上来说就是表示TCP报头的长度TCP的报头是在不断变长的不像UDP一样就是固定8个字节此处的表示该TCP头部有多少个32个bit位都多少个四个字节4位表示4个比特位也就是说TCP头部的最大长度就是说4*1560个比特位 4)16位紧急指针标识哪些数据是紧急数据 5)16位窗口大小标识滑动窗口的大小 6)16位校验和表示发送端填充CRC校验如果说接收端校验不通过那么就认为数据有问题此处的校验和不光包含TCP首部还包含着TCP数据部分 7)URG:表示紧急指针是否有效 ACK:表示确认序号是否有效 PSH:表示提醒接收端应用程序立刻从TCP接收缓冲区里面把数据读走 RST:表示对方要求重新建立连接我们把表示为RST标识的称之为复位报文段 SYN:表示请求建立连接我们把SYN标识的段叫做请求同步报文段 FIN:表示本段要进行关闭了我们把表示为FIN结束标识的段称之为结束报文段 8)保留6位:保留位的意思就是说现在还不进行使用但是保不齐以后会进行使用也就是说咱们是为了未来的升级留点空间 9)选项:主要是说这个选项可以有也可以没有可以有一个可以有多个 1)TCP头部中的最后一个选项字段是可变长的可选信息这一部分最多包含40个字节因为TCP头部长度最多就是60个字节还包括前面讨论的20个字节 2)最重要的是窗口扩大因子 可靠性:不是说发送出去的数据100%就能够接收到我发出去的数据到底对方收没收到我心里有数我可以知道我发送的数据成功还是失败(接通电话的时候对方有反应就知道可靠不可靠) 1)换一种角度来说客户端发送出去的数据客户端知道对方是接收到发送的数据还是知道对方没有接收到我的数据 2)发送出去之后就不管了也不知道你有没有收到这就叫做不可靠传输 3)接收方收到消息之后给发送方返回一个应答报文ACK表示自己已经收到了 1)确认应答机制(保证可靠传输的核心)(正常情况下数据传输的可靠性) 咱们虽然在TCP代码上面看不出来但是这个确实是TCP中最可靠的机制引入TCP的关键原因就是为了可靠传输因为TCP是有连接的所以在客户端发送数据给接受方了接收方就应该返回一个应答报文当发送方收到了这个应答报文后就认为对方已经收到了我打电话的时候我进行在电话里面说话对方说嗯嗯我才表示已经收到了 1)但是网络上的传输顺序是不确定的因此就不可以单纯的通过收到数据的顺序来判断和确定逻辑你所进行发送的两个数据包是不一定走同一条路的先发后到 2)例如:我给我的女神发送消息 第一次发送请求你在吗女神回复说在这就是一个可靠传输 第二次发送了两个请求: 请求一:我想请你吃个麻辣烫请求二:做我女朋友吧 3)这是我发送了两条消息一个是好呀好呀另一个是滚由于网络延迟我不知道他的回答是是针对我的那条请求来回答的出现了后发先置的情况我并不知道它的这两个响应报文分别对应着哪一次请求可能这个吃麻辣烫是滚对做我女朋友是好呀好呀 1)这时女朋友和我可以来个序号(编号): 我:请求1:女神你陪我吃麻辣烫好吗请求2:女神你做我女朋友好吗(序号) 女神作出回应:针对请求一是好呀好呀针对请求二是滚确认序号我们如果说使用编号就不会再出现数据顺序混乱的情况了让他们彼此之间对应的上 2)确认序号表示当前这个应答报文是针对哪一个消息进行的确认应答TCP是依靠字节来进行编号通过序号来进行表示当前发送的是哪一条消息通过确认序号来进行表示针对哪一条消息来进行回应
