汕头优化网站,光辉网站建设公司,公众号平台官网登录,浪漫做爰网站文章目录应用层自定义应用层协议什么是自定义应用层协议自定义方式运输层运输层概述运输层特点运输层协议UDP协议UDP的特点UDP首部格式校验规则TCP协议TCP的特点TCP协议段格式TCP的性质确认序号超时重传连接管理三次握手四次挥手TCP的状态滑动窗口流量控制拥塞控制延迟应答捎带…
文章目录应用层自定义应用层协议什么是自定义应用层协议自定义方式运输层运输层概述运输层特点运输层协议UDP协议UDP的特点UDP首部格式校验规则TCP协议TCP的特点TCP协议段格式TCP的性质确认序号超时重传连接管理三次握手四次挥手TCP的状态滑动窗口流量控制拥塞控制延迟应答捎带应答粘包问题异常情况处理应用层
应用层是负责应用程序之间沟通的一层。由于不同的网络应用的应用进程之间有着不同的通信规则因此自然就需要应用层协议来解决这些问题这就构成了应用层的主要内容即精确定义这些通信规则。
应用层有不少应用广泛的协议像域名系统DNS、文件传输协议FIP、网络远程访问协议Telent等具体的协议规则这里不做介绍除此之外在日常程序员的工作中使用同样频繁的还有自定义应用层协议
自定义应用层协议
什么是自定义应用层协议
所谓自定义即程序的开发者自定义。自定义包含着一个根据需要从无到有的过程。协议则代表了某种约定。因此自定义协议就可以简单理解为由程序的开发者根据程序开发的需要去约定客户端和服务器传输数据的格式
自定义方式
在约定之前首先要明确交互过程中传递的信息有哪些。以网上购物为例用户作为请求的发出方就需要明确用户的地址电话号码等信息而商家则是作为请求的接收方需要明确商家的一些具体情况像商品类型商品销量、商品价格、接单时间等
根据用户需求明确了交互中涉及到的信息之后就需要根据实际情况来确定这些信息的组织格式自此即真正开始了应用层协议的自定义。 实际需求下信息的组织格式是有多种方式的 使用简单的分隔符来区分不同部分的信息 仍然使用商品上网购物的例子如上图[;]就是用来区分不同信息的简单分隔符 使用固定长度确定不同信息 使用固定长度来表示不同信息也根据长度来区分不同信息 融合方式一和方式二一部分字段信息使用分隔符来区分一部分字段使用固定长度来区分 使用xml格式来约定数据
xml格式是一种标签结构的用来展示数据的格式它包含了开始标签和结束标签标签一般都是成对出现的
使用json格式组织数据 相比xml,json的使用更加广泛它是使用键值对的方式来组织数据每个键值对之间使用逗号进行分割每个键值对的键和值之间使用冒号进行分割 json格式的键必须是字符串形式
二进制数据组织格式protobuffer,thrift 这种数据组织格式较为复杂尽管它的效率相比json或xml要更高且占用的带宽也要更低但它的可读性却不如前者在具体使用中可以根据实际情况进行选择。
运输层
运输层概述
运输层是整个网络体系结构中的关键层次之一为应用层提供通信服务。其实对于通信而言如果是主机对主机之间的通信网络层即可实现。可是更多的情况下是端口与端口之间的通信像主机A的应用程序1与主机B的应用程序2通信如果在这种情况下仅仅依靠网络层就无法很好的实现这时运输层就在这样的通信中起到了关键作用。
运输层特点
一般而言运输层有2个特点即复用(multiplexing)和分用(demultiplexing); 复用即发送方不同的应用进程都可以使用同一个运输层协议传送数据 分用接收方的运输层可以把传送来的数据正确交付指定的应用进程 运输层协议
TCP/IP运输层有2个主要协议即用户数据报协议UDP和传输控制协议TCP
UDP协议
UDP协议即用户数据报协议。UDP数据报传送实际是一种不可靠的传输因为UDP在传送数据之前不会有建立连接的操作同时在主机B的运输层收到报文以后也不需要对发送端给出任何确认。但尽管UDP是一种不可靠的传输也不可避免在一些情况下是有效且便利的。
UDP的特点 UDP是无连接的 发送之前不需要建立连接 UDP是不可靠传输 其不可靠也是由于其是无连接的 UDP是面向数据报的 UDP不会对应用层交付的报文做任何处理只会原样发送一次发送一个报文同时接收端的UDP也是一次交付一个报文 UDP传送报文的长度受限 过长的报文在被交付到IP层后可能会被分片过短的报文被交付会使IP数据报的首部长度过长都会较低IP层的效率 UDP支持一对一、一对多、多对一、多对多的交互通信
UDP首部格式 UDP用户数据报的组成包括了2个字段即首部字段和数据字段 首部字段又包含了4个字段8个字节每个字段的长度为2个字节 4个字段分别为 源端口号数据发送端的端口号 目的端口号数据接收端的端口号 长度UDP用户数据报的长度 校验和用于检测UDP传输过程中是否出错 校验规则
UDP校验和是用来校验UDP传输过程是否正确的主要指标。由于在数据通过网络传输的过程中有可能会受到许多元素的影响。为了避免错误的数据在未知的情况下被传输规定在发送数据时将其校验和和数据一起传输。在计算校验和时是在UDP用户数据报之前增加了12个字节的伪首部。这个伪首部是临时增加在数据报首部的而不属于数据报真正的首部也不会被作为向下传递的一部分。 UDP使用的校验和算法是一种循环冗余校验和(CRC)的方法,具体计算方法这里不做介绍。
TCP协议
TCP协议即传输控制协议。
TCP的特点 有连接 TCP在发送数据之前首先需要建立连接 可靠传输 TCP的可靠传输是TCP的核心特点所谓可靠传输并非是指一旦发送一定接收成功而是当数据发送成功后对方是否接收成功对于发送方来说是清晰的。通过TCP传输的数据无差错、不丢失、不重复、按序到达 面向字节流传输 即在发送数据时对数据进行编号是依照字节来编
TCP协议段格式
TCP协议段是由20个字节的固定首部加数据组成的 源端口号数据来源 目的端口号数据去处 序列号数据编号后得到的序列号 确认序号接收到数据后的应答 首部长度4位表示TCP头部长度 标志位URG-紧急指针是否有效ACK-确认号是否有效PSH-提示接收端从缓冲区读取数据PST-对方要求重新建立连接SYN-请求建立连接同步报文段FIN-结束报文段 TCP的性质
TCP可靠传输的保证最主要的一点实际就是确认应答。
确认序号
确认应答首先依靠确认序号来实现即首先对需要发送的数据普通报文进行编号。假设发送的数据编号情况是1—500则确认序号为501。可以理解为发送端将编好号的数据发送给接收端后由接收端给发送端发送一个应答报文即确认序号通过确认序号就可以确定当前接收端是对哪个普通报文做出了应答。也就代表接收端已经接收到了该报文。 超时重传
TCP数据的可靠性传输是依靠于应答报文的接收来确定的而如果发送方发送数据之后等待一定时间但未收到接收方的应答报文大概率就可以判定为数据传输失败于是触发重传。
使用超时重传的方式在很大程度上就可以避免数据传输失败的问题但伴随着超时重传同样也带来了接收端难免会收到一些重复数据的问题因此接收方就需要对收到的数据进行去重也就是根据之前数据的编号进行排查如若发现收到了一份与之前相同的数据就自动丢弃依次来保证最终在应用层读到的数据是不重复的。
当然初始传输的数据可能会丢失如若处在同样的网络环境中重传的数据同样也有可能会丢失。而TCP为了保证较高性能的通信就会不断动态地来计算最大等待时间。像一般情况下操作系统都是以500ms一个单位为基础等待时间假如在重发之后一个500ms任未得到应答下次重传就会在2个500ms之后。依次类推~~~
当然若是多次重传仍然得不到回应就会强制关闭连接不再进行传输。
连接管理
TCP作为一种有连接的可靠传输与它的连接管理机制是分不开的而所谓连接管理就是TCP经过三次握手建立连接四次挥手断开连接。
三次握手
TCP通过“三次握手”建立连接连接的建立一定是由客户端首先主动发起的 三次握手的主要过程和原理如图即首先由客户端向服务器发送一个请求尝试建立连接第一次握手服务器收到该请求之后向客户端做出应答同时建立与客户端的连接第二次握手最后再由客户端对服务器的请求做出应答至此连接建立成功第三次握手~
三次握手是保证数据正常传输的重要前提只有在通信之前就确定通信链路的畅通即验证通信双方的发送能力和接收能力才可以更大程度的成功传输数据。同时在这样一个过程中客户端与服务器双方也会进行一些重要参数的协商也是通信中不可避免的一个环节~
四次挥手
四次挥手实际就是通信双方通知断开连接的过程与三次挥手不同四次挥手既可以由客户端一方发起也可以由服务器方发起~ 四次挥手的原理如图任意一方首先发送一个断开连接的请求对方做出回应之后再发送一个断开连接的请求待对方最初应答之后连接断开~
TCP的状态
TCP的状态实际有很多种这里主要介绍下面几种 LISTEN 一般表示服务器的状态表示服务器已经启动完毕~ ESTABLISHED 表示通信双方连接建立成功可以进行通信~ CLOSE_WAIT 待断开连接的状态对方发送了断开连接的请求自己也做出了应答待自己发送断开连接的请求时就是该状态在Socket编程中调用close()方法表示断开连接 TIME_WAIT 主动发送断开请求的一方的状态主动方在收到对方断开连接请求同时做出应答之后就处于该状态该状态持续一段时间后连接彻底断开~
滑动窗口
以上三种机制确实是保证了TCP传输的可靠性但从某个角度来说反复保证可靠传输的操作也不可避免地降低了TCP通信的效率因此为了尽可能地提高其传输效率就产生了滑动窗口的机制。 最基本的TCP通信是主机A发送一条数据待主机B返回应答报文后主机A再继续发送下一条数据而添加了滑动窗口机制的TCP特性则是一次发送一批数据这一批数据有可能包含了多条单个的数据待对方返回了第一条数据的应答报文之后主机A就继续发送下一批数据这就是滑动窗口的基本工作原理。
至于这里一批数据包含了多少条数据就在于这个窗口的大小窗口大小越大一次发送的数据就越多相应其发送速率也就越高。 与普通的TCP传输相同增加了滑动窗口机制的TCP通信同样有可能会出现丢包的问题那么它们对于丢包的处理又会有什么不同呢
第一种情况是传输的数据本身丢了 发送方通过接收到的应答报文来判断是否出现了丢包假设发送方一次发送了1-1000、 1001-2000、 2001-3000三条数据同时收到的多条应答报文都是1001就可以断定后面的2条数据发生了丢包此时发送方就会重新发送后面的2条数据而不会重复发送第一条数据。因此对于数据本身丢包原则就是丢哪条重发哪条对于成功传输的数据则不会重复发送。
第二种情况是应答报文丢了 一般情况下无论网络环境有多么复杂丢包始终都是一个小概率事件因此假设数据的发送情况与上面一致但接收到的应答报文却只有2001和3001对于发送方来说是可以认为1-1000的数据也是顺利到达了的即对于应答报文涵盖的信息后一个是会包含上一个的。
我们说滑动窗口的机制是提高TCP的通信效率但这只是针对没有滑动窗口时的普通的TCP通信如果是与不保证可靠性的UDP相比自然是不及UDP的效率的。因此与其将滑动窗口机制看做是提高效率的方式不如认为是对低效率的补救。
流量控制
流量控制实际就是对滑动窗口进行限制的一种机制因为对于滑动窗口而言窗口越大数据的发送效率就越大。但如若这个效率过大又会带来丢包等一系列的问题因此对其效率进行控制就是必要的。 由于接收端接收到数据之后是将数据暂时存储在缓冲区等待接收端的应用程序来读取数据因此如果发送方发送数据过多过快就会出现接收端的缓冲区被占满的情况若是在这种情况下发送方仍然不停地发送数据丢包现象的产生也就是必然的了。而流量控制就是TCP根据接收端的处理能力来制约发送端的发送速度。 如何制约呢 前面我们再介绍TCP协议段格式时就包含了一个代表窗口大小的字段这里的制约方式实际就是接收端将自己剩余的缓冲区的大小存取该字段中再通过ACK应答报文来告知发送端发送端就可以根据这个窗口大小来调整自己的发送效率避免接收端缓冲区满仓。 关于流量控制机制需要注意这样几个点 窗口大小的字段越大就说明网络的吞吐量越高 当窗口大小为0时发送方就不会再发送数据但在一段时间后发送方一般会尝试发送一个探测包来查验接收端此时的数据处理能力 实际的窗口大小是窗口字段的值左移M位M代表窗口扩大因子 拥塞控制
如果说前面的流量控制是站在接收方的角度控制发送速率那么拥塞控制就是站在整个发送过程的角度来调整发送速率。
一般为了数据传输效率和可靠性的保证TCP是采用慢启动的机制的即在网络状况未知的情况下先发少量的数据来探路再根据实际情况来确定实际的传输速率。
可以理解为整个发送过程就是这样的初始发送时按照较小的窗口大小来发送如果没有出现丢包的问题就判定网络环境良好可以尝试发大发送窗口的大小在不断发大的过程中如若出现丢包的情况就立即减小发送的窗口利用这样反复试探的操作来寻求一个动态平衡的局面 在TCP中具体的操作是这样的 此处可以引入一个拥塞窗口的概念假定第一次发送时拥塞窗口的初始值为1每次发送方收到一个ACK应答拥塞窗口值加1具体的发送速率就由拥塞窗口和之前流量控制中的窗口的较小值来决定 一般TCP拥塞窗口的初始增长速度是非常快的基本是指数级别的增长到达一定的阀值后就变为线性增长 延迟应答
延时应答同样是一个用来提高TCP通信效率的机制它更像是对前面流量控制的一种缓解。顾名思义延时应答就是接收端在接收到数据以后等待一定时间再像发送端返回应答而在这样一个等待的时间里接收端的接收缓冲区仍在不停地被应用程序读取缓冲区的剩余容量也在不断增加等到真正返回ACK报文时可以返回的窗口大小也就会更大 但是对于延时应答也是有一定限制的 数量限制每隔N个包就应答一次因为后面的应答报文时可以涵盖前面的数据接收情况的即2001的应答报文表示收到了1-2000的所有数据 时间限制超过最大延迟时间就应答一次这一点对于不同的操作系统有不同的时间限制超过该时间限制则应答一次 捎带应答
捎带应答同样是一种提高传输效率的机制是基于延时应答而实现的因为正常情况下ACK报文是接收端接收到请求之后由内核立即返回的而具体的响应数据则是由代码实现来控制的但是如果基于延时应答的机制ACK报文延时发送在时间上就可能与响应数据重合也就达到了捎带的目的。 TCP的通信整体而言是比较复杂的因为它在保证可靠性的同时又在尽可能的提高性能。在其整个机制系统中校验和、序列号、确认应答、超时重传、连接管理都是在保证其可靠性而滑动窗口、延时应答、捎带应答则是在提高其传输性能。 粘包问题
TCP是基于字节流的传输层通信协议。这里的基于字节流实际是指在读取接收端缓冲区的数据时以“字节流”的方式来读取但是面向字节流的方式势必会带来一个问题即粘包问题
由于“流”数据是没有明确的开始和结尾边界的对于同一进入到接收端缓冲区的众多数据而言更是难以区分这些数据来自何处结束于何处因此在进行数据的读取时就有可能会出现在一条消息中读取到了另一条消息的部分数据这就是粘包问题。
如何解决粘包问题呢 常见的解决办法主要有2种
约定长度 发送方和接收方固定发送数据的大小明确边界使用分隔符类似于前面的自定义应用层协议
异常情况处理
异常情况主要就是发送方与接收方以非正常四次挥手的方式断开连接主要有下面几种情况 主机关机 如果是按照正常程序逐步关机会首先释放进程然后释放文件描述表上对应的文件资源然后触发结束报文段开启四次挥手的流程若流程顺利结束无影响继续关机若流程未完成就重新发送FIN结束报文段得不到回应就自行断开放弃~ 程序崩溃进程终止 与上面流程基本一致~ 机器掉电/网线断开 极端情况下当来不及进行四次挥手操作时对于接收方突发异常而言对方发送数据得不到ACK就尝试重传如此多次之后仍无法成功就放弃操作对于发送方突发异常而言接收方无法得知具体情况是暂未发送数据还是发送方故障了在长时间等待不到数据的情况下就会通过发送心跳包的方式周期性地去判定对方是否仍然存活如果可以得到回应证明只是暂未发送数据若得不到回应表示发送方故障
至此关于网络五层模型中最重要的应用层与传输层重点协议就介绍完毕啦over~~
