文章目录
- 一、应用层
- 1.1 自定义协议
- 1.2 通用协议
- XML
- JSON
- protobuf
- 1.3 DNS 域名解析系统
- 二、传输层
- 2.1 UDP协议
- 2.2 TCP协议
- 协议端格式及解析
- 可靠性机制
- 确认应答
- 超时重传
- 连接管理(三次握手,四次挥手)
- 流量控制
- 拥塞控制
- 效率机制
- 滑动窗口
- 延迟应答
- 捎带应答
- 粘包问题
- TCP异常情况
本篇主要主要解析各个层面的协议,包括应用层、传输层、数据链路层、
一、应用层
序列化和反序列化:网络上传输的数据,本质上就是二进制的“字符串”,但java中写的都是一个个对象,我们也无法传输一个“Java对象”,所以为了实现网络通信,就需要相互转化对象和二进制字符串,即序列化(对象 <—> 二进制字符串)和反序列化。
1.1 自定义协议
对于自定义协议,我们需要首先明确传递的信息是什么,数据是如何组织的
1.2 通用协议
尽管协议可以自定义,但早已有大佬搞出了通用协议,便于我们直接使用,比如xml、JSON
XML
概念:
- 用成对的标签来表示“键值对”信息,标签支撑嵌套。
- 每个标签都是人自定义的,只要记住格式(<></>)即可。
- 与html相比,并没有一个标准,html如果不按标准来,无法正常运行。
优缺点:
- 优点:能够清晰地表示结构化数据
- 缺点:
- 要引入大量标签,十分繁琐。
- 因为要传标签,会占用不少的网络带宽。
<request>
<userId>1234</userId> //键值对结构:key = userId, value = 1234
<userName>张三</userName>
</request>
JSON
概念:
- 是最流行的一种数据组织格式,本质也是键值对,但更简洁。用{}表示键值对,[]表示数组,数组中的每个元素可以是数字、字符串、其他的{}、[]
- JSON对于换行并不敏感,所以一般网络运输时,会对JSOM进行压缩(去掉不必要的换行和空格),同时把所有数据都放到一行里,整体占用的带宽就更低了(但会影响到可读性)
优缺点
- 优点:数据简洁,可读性好
- 缺点:花费带宽传输了名字
protobuf
概念:谷歌提出的一套二进制的数字序列化方式,即使用二进制的方式约定哪些字节表示哪个属性
优缺点:
- 优点:可以最大限度的节省空间(不必传key,而是根据位置和长度来区分每个属性)
- 缺点:都是二进制数据,可读性差,使用也比较麻烦,需要专门编写一个 protobuf 文件
1.3 DNS 域名解析系统
- 什么是域名:上网需要访问服务器,也就需要知道服务器的IP地址。但是IP地址即使是用点分十进制进行简洁表示了,依旧不方便人民记忆和传播,于是我们便使用baidu,taobao这样的单词来代替IP地址,这样的单词就被称为 “域名”。
- 实践中,为了保证域名的唯一性,域名往往是分级的
二、传输层
2.1 UDP协议
- 全双工:又能receive,又能send
- 端口:因为是2字节,所以范围是0 ~ 65535,注意0一般不用,1~1024被分配给知名的程序了,一般也不用
- 16位UDP长度:描述了载荷有多大,但是只有2字节,即64kb,对于现在而言,有些小。但是我们无法把协议中设置的位数加大,这涉及到了政治问题。为了解决这个问题,有两个方法:
- 把一个要传的数据拆成多个后重组。但是代码量较大,成本高,不建议实行。
- 改用TCP,因为TCP没有报文长度要求
- 16位校验和:
(1)网络通信要传的数据到最后物理层都会变成光信号/电信号,同时传输时难免会出现漏传的情况,校验和可以帮我们检验,该数据是否完整传输了。
(2)CRC检验算法,主要是把UDP数据报中的每个字节都依次进行累加。传输数据时,发送方发送原始数据和校验和,接收方收到后,会将数据再算一遍,然后将受到的检验和和自己算的进行比较,如果相同,那么数据相同,即传输过程中没有出现错误。
1字节:
有符号:-128 ~ 127
无符号:0~255
2字节:
有符号:-32768 ~ 32768
无符号:0~65535
4字节:
有符号:-21亿 ~ 21亿
无符号:0~42亿95万
2.2 TCP协议
协议端格式及解析
- 4位首部长度:
- 作用:表示TCP协议报头的长度。报头前9个加起来20字节,大小是固定的,但是选项是可变的,所以总体TCP的报头是变化的,需要专门描述
- 注意点:单位是“4字节”,要把这里的数值乘以4字节才是真正的大小
- 选项:可以有,也可以没有。包含了一个窗口扩大因子M,可以接受的缓冲区大小是 “16位窗口大小”字段的值左移 M 位(与)。
- 保留(6位):解决了UDP无法升级的问题,为未来留下了可以升级扩展的空间
- 6个标志位:每个都是1bit,有对应的含义
- ACK:表示是否是确认报文。当ACK为0时,为普通报文,此时只有32位序号有效。当ACK为为1时,为应答报文,序号和确认序号都有效。
- RST:复位报文段
- SYN:申请和对面建立连接,“同步报文段”
- FIN:通知对面要删除连接了,“结束报文段”
- 32位序号:该数据报地第一关字节的序号,需要结合IP协议中的“16位总长度”来确认最后一位字节的序号
- 32位确认序号:反馈给发送方收到了多少数据,以及发送数据要从哪里发起
- 16位窗口大小:接收端自己可以接收的缓冲区大小放入,用于流量控制,通过ACK端通知发送端
可靠性机制
安全机制主要支持了TCP可靠性的实现,TCP可靠传输主要依靠内核实现,用户方面是感知不到的。其中确认应答是保证可靠性的最核心机制,其他的安全机制都只是有效补充。
确认应答
- 网络上从一个点到另一个点的能走的线路很多,而不同的路线选择以及路由器/交换机的繁忙程度,都会影响到包到达的顺序。所以,为了区分,TCP将每个字节的数据都进行了编号,即为序列号。
- 每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。
超时重传
-
什么是超时重传:当出现下面两种问题时,等待了一段时间后都没有收到数据包时,就需要重传数据包,即【超时重传】。
-
去重:内核是无法区分到底是第一种丢包还是第二种,都是要重传,所以接收方就需要对数据去重,确保不会重复读取。
- 如何去重:使用TCP的序号作为判定依据。
TCP会在内核中给每个Socket对象都安排一个内存空间,相当于一个队列,即“接收缓冲区”,收到的数据都会被放到接收缓冲区里,并且按照序号排列好,此时就可以很容易判断新收的数据是否重复。当队列首元素序号>新接收数据序号,就表示该数据已经被读取过了。 - 如何确定超时时间:
(1)最理想的情况下,找到一个最小的时间,保证 “确认应答一定能在这个时间内返回”。这个时间的长短,随着网络环境的不同,是有差异的。如果超时时间设的太长,会影响整体的重传效率,如果超时时间设的太短,有可能会频繁发送重复的包。
(2)TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间。Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后,仍然得不到应答,等待 2 *500ms 后再进行重传。如果仍然得不到应答,等待 4 *500ms 进行重传。依次类推,以指数形式递增。累计到一定的重传次数,会尝试重置TCP连接,即“TCP复位报文“。如果连重置操作都不行,那么TCP就会认为网络或者对端主机出现异常,强制关闭连接。
拉长等待时间是等待修复,当前网络可能有问题,而次数太多了就说明此时网络已经出现了严重故障。
- 如何去重:使用TCP的序号作为判定依据。
连接管理(三次握手,四次挥手)
在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接。
-
三次握手:
概念:
(1)什么是三次握手:握手指发一个不携带业务信息,只用于打招呼,测试网络连接是否可行的数据。而三次握手就是指A、B如果要建立连接,这样的数据要发三次。三次握手是内核完成的工作,应用程序是无法干涉的,确保IP、端口对即可。(2)如何衡量连接的建立:ServerSocket socket = new ServerSocket();new完成,连接就建立完毕,accept()是将把连接队列中的元素取出来。单线程TCP服务器情况下,无法调用第二次accept,但这不影响连接操作的完成,形成的连接对象在连接队列里。
(3)关于合并问题:中间的SYN+ACK其实可以拆开来,但为了节省效率,故而合并变成【三次挥手】
(4)关于丢包问题:遵循超时重传机制,会重传,多次失败也会单方面释放连接
意义:
(1)保证可靠性:先行测试网络是否通常,以及各个主机的通信能力和接收能力是否正常(三次握手恰好能够验证双方的能力,二次握手无法验证完设备的正确性,四次握手可以,但没必要效率太低)
(2)消息协商:协商双方的序号从几开始,保证双方连接消息的序号有较大差异,从而好判定该消息是否属于这个连接 -
四次挥手:释放在内存中保存的对端的相关信息
概念:
(1)关于合并问题:中间的两次无法像“三次握手”那样合并,因为ACK的应答由内核控制,见到FIN就发送,是顺发的,可能会因为延迟应答机制返回慢。FIN则是当服务器执行到 close() 时发送。当FIN发送快,即可和ACK合并。所以这个合并因为FIN发送快慢问题,并不能百分百合并。(2)客户端如果迟迟收不到对方的FIN,也会单方面删掉连接
(3)关于丢包问题:遵循超时重传机制,会重传,多次失败也会单方面释放连接。
如果是第一组FIN/ACK丢失:A直接重传FIN即可
如果是第二组 ACK 丢失:注意当A收到FIN发出ACK后,不能直接释放连接,因为最后一个ACK可能会丢包。万一连接删了,又丢包了,那B重传的FIN永远没人接收了。所以A需要等一会(等待时间是网络上任意两点之间传输数据的最大时间 * 2,即MSL),如果对方未重传FIN,就认为ACK已经被对方接受到了,此时A才能释放连接。
流量控制
根据接收端的处理能力,来决定发送端的发送速度(窗口大小)。用“接收缓冲区剩余空间大小”来衡量,越大,处理能力就越强。
拥塞控制
-
概念:
(1)使用场景:窗口大小的决定不能光关注接收方(流量控制),还要关注中间节点(交换机/路由器),总的传输效率取决于最短板。
(2)如何衡量中间设备的转发能力:把中间设备看成一个整体,通过“实验”的方式,动态调整,最终产生出一个合适的窗口大小(具体细节看下面的操作部分)
(3)拥塞窗口:在拥塞控制机制下采用的窗口大小 -
操作:
(1)慢启动:使用一个小窗口,试试水
(2)指数增长:如果网络传输十分通畅,拥塞窗口大小就会呈指数式增长。指数增长速度极快,所以需要靠线性增长来调整窗口大小。
(3)线性增长:指数增长使得窗口大小越过一个阈值时,就会采用“线性增长”。线性增长寓意每一轮固定+N,一轮次指“发数据到收到回应”。因为是增长,也会使得发送速度越来越快,而当快接近网络传输的极限,就可能丢包了,少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞。
(4)拥塞窗口回归小窗口:网络拥堵了,将窗口大小调为慢启动的小窗口,同时根据当前拥堵的窗口大小,调整阈值,然后重复增长操作。 -
优缺点
优点:能够更好地适应多变的网络环境缺点:每次回到慢启动,都会使得传输速度大打折扣,后续推出的优化操作,都只是尽可能缩短传输小窗口的时间而已
-
注意点:
拥塞控制和流量控制共同限制了滑动窗口机制,确定了要传的窗口大小,使得滑动窗口得以在可靠性的前提下,提高传输效率
效率机制
滑动窗口
概念:一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(用原本一份等待时间换多份)
- 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
- 发送前四个段的时候,不需要等待任何ACK,直接发送。收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据,依次类推。
- 操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉。
- 窗口越大,则网络的吞吐率就越高,但如果太大,相当于完全不用等ACK,相当于不可靠传输了。而且无法保证接收方能否处理得过来,设备是否支持得住。
关于丢包问题:
情况一:数据包已经抵达,ACK被丢了 ----------- 不用做任何处理,因为可以通过后续的ACK进行确认前面的数据报是否正常收到。
情况二:数据包就直接丢了 --------------- 重传
延迟应答
(1)作用:接收方在返回ACK时,拖延一段时间,来让应用程序有更多的时间消费数据,从而提高接收缓冲区的剩余空间大小。
(2)限制:并非所有的包都能延迟应答。滑动窗口有数量限制,非滑动窗口则有时间限制。
数量限制:每隔N个包就应答一次。滑动窗口下丢了几个ACK应答包也没事,因为后面的ACK包可以涵盖前面的
时间限制:超过最大延迟时间就应答一次
捎带应答
-
概念:ACK搭响应的顺风车,和响应合并起来一起发送出去。
-
条件:
时机合适:客户端和服务器的交互主要是一问一答的形式,而延迟应答又使得ACK的返回时机更迟,此时就有机会搭响应的顺风车,和响应合并起来。数据不冲突:ACK数据不需要携带载荷,和响应的数据包也不冲突。所以就可以让一个数据包既携带载荷数据,又带有ACK信息(ACK标志位、窗口大小、确认序号)
粘包问题
-
问题:发送方可以一次性发送多个应用层数据报,此时接受的时候,无法区分从哪里到哪里是一个完整的应用层数据报
-
解决方法:传输层方面已经规定死了,无解,只能从应用层协议上下手。
(1)应用层协议引入分隔符来区分包,如JSON、xml
(2)引入包长度来区分包,如 protobuf
TCP异常情况
-
进程崩溃:和正常关闭没有什么区别
(1)相当于进程没了,此时对应的PCB也就没了,对应的文件描述被释放,相当于调用了socket.close(),崩溃的一方发出FIN,进一步触发四次挥手。
(2)Socket相当于一个网卡文件,会被放到文件描述符表中 -
主机关机(正常关机)
先尝试强制终止所有进程,主机关闭期间,如果四次挥手完成,那正好。如果没完成,对方也最终会单方面释放自己的连接信息
-
主机掉电:没有任何可操作空间
两种情况:
(1)如果B正在给A发消息,那么就会像【主机正常关机】那样,最终单方面断开连接,B没有什么负面影响
(2)如果A正在给B发消息。A突然不发消息了,但是B分不清A是等会发,还是一直不发了,于是B便阻塞等待。但这个等待时间不是无限的,B会周期性地给对方发起一个不携带任何业务数据(载荷)的TCP数据包,即【心跳包】。这主要是用来触发ACK,确认一下A是否正常工作/网络是否畅通。如果发现对方不在了,就会单方面断开连接。其他:
(1)“心跳包”有点类似于“窗口探测报文”
(2)应用层心跳包:虽然TCP已经有心跳包的支持了,但是还需要再应用层中重新实现心跳包。因为TCP的心跳包是分钟级别的,周期太长。在如今高并发的场景下,速度太慢。 -
网线断开:机器都还在,但无法通信
(1)客户端A:主机掉电的第一种情况
(2)服务器B:主机掉电的第二种情况