💕"Echo"💕
作者：Mylvzi
文章主要内容：网络原理(一)
一. 应用层
应用层是和程序员联系最密切的一层,对于应用层来说,程序员可以自定义应用层协议,应用层的协议一般要约定好以下两部分内容:
- 根据需求,明确要传输哪些信息
- 明确信息传输的格式
以打开手机订外卖为例
需求:打开手机,想要搜索周边卖黄焖鸡米饭的餐馆
根据请求,明确传输信息:需要传输:用户名,经纬度(根据经纬度来搜索周边黄焖鸡米饭的店铺)
请求:(以下使用一种纯文本的数据组织格式)
用户名,len,lan;
响应:商家列表,包括商家名称,店铺照片,距离,评分等等
常见的数据组织格式有以下三种:
- xml(叉ml) 一种以标签作为信息传输的基本格式,和html类似
< userId > 用户名< /userId >
xml的劣势就在于可读性相较于纯文本格式更高,但是需要传递的数据量变多(标签也需要被传输),需要额外的带宽 - json格式 最常使用的一种格式,符合面向对象编程的思想,将要传输的信息看做一个Object对象,内部使用"键值对"这样的格式来组织数据,相较于xml格式,json可读性更好,更简洁,额外需要的带宽也减少
除了特别追求性能的场景,json广泛应用于各种应用层协议中用于组织数据 - protobuffer 简称pb格式是由谷歌开发的一种数据组织格式,会将需要传输的数据转化为二进制数据,追求最极致的数据传输速度,但是可读性很差
程序员可以自定义协议,同样的,也有一些现成的协议供我们使用,最常见的就是HTTP协议(超文本协议),HTTP会在后续章节作更详细的介绍
二.传输层
网络模型中的传输层关注起点和终点,即通信双方的具体位置,主要是利用端口号来标记位置的,计算机的具体位置不在传输层中记录,而是在网络层中的ip协议之中,不要把端口号和IP地址混为一谈!!!
端口号是应用程序/服务器的标识,在一个计算机中,存在着非常多的应用程序/服务器.通信时要明确是哪一个应用程序进行数据的传输.此时就可以利用端口号进行标识.端口好就像是身份证一样,每个服务器都有其单独的端口号!
端口号一般是两个字节的数据,数据表示范围为 0 -65535,其中 1- 1023被称为知名端口号.这些端口号被一些知名服务器给占用了,程序员指定端口号时不能和知名端口号相同,否则就会出发端口冲突
传输层中最常见的两种协议是TDP和UDP协议,UDP出现的时间更早,速度更快,但是有自己的缺陷,TDP出现较晚,可以看做是对UDP的一个升级版!!
TCP和UDP的区别:
TCP:有连接, 可靠传输, 面向字节流, 全双工
UDP:无连接, 不可靠传输, 面向数据报, 全双工
学习协议,重点就是掌握协议的报文格式,即数据组织管理的格式
1.UDP协议的具体格式讲解
首先一个完整的UDP报文格式由两部分组成:
- UDP报头
- UDP载荷
UDP载荷就是从应用层中打包好的应用层协议数据报,存储要传输的数据
UDP报头中存放与UDP协议相关的一些信息
报头和载荷之间的拼接本质上是字符串拼接(尽管内部的数据都是以二进制的形式存储的)
UDP报头大小为8个字节,具体可以分为四部分,每部分2个字节
1.源端口号:发送方的端口号
2.目的端口号:接收方的端口号
3.UDP报文长度:整个UDP报文的总长度,即UDP报头和UDP载荷的总长度,由16位的数据组成,数据范围是 0 -65535 ,也即最大的报文长度是64 kb,64kb的数据放在当下已经是非常小的一个数据量了,这也是UDP的一个局限性,每次最多传输的数据太小了!而TCP很好的解决了这个问题
4.校验和(checksum):这是网络传输中一个很重要的概念,用于保证数据传输的准确性.原始数据经过一定的算法简化为更加简单.体积更小的字符串,这个字符串就会保留在UDP的报头之中,用于接收方进行数据校验,要理解校验和还要明确一点,即数据在传输的过程中是会发生传输错误的,数据的传输底层上是通过光/电信号进行传输的.传输的过程中难免会受到周围环境的影响,导致光/电信号发生突变,进而数据传输就发生错误,发生错误就要检验错误,校验和就是一种检验错误的手段
以下是一个简单的校验和检验过程
- 发送方将数据整理打包为Data1,根据算法计算出校验和为checksum1
- 发送方将Data1和checksum1通过UDP传输给接收方
- 接收方接收数据,整理数据为Data2,接收checksum1
- 接收方按照相同的算法对Data2进行计算,得到校验和checksum2
- 如果checksum1和checksum2相同,那么Data1和Data2理论上是相同的(也有可能不同,但是是极小的概率,工程上忽略不计)
如果checksum1和checksum2不同,那么Data1和Data2一定不同.此时数据的传输就发生了错误,程序员可以采取其他措施来解决问题
常见的计算校验和的算法有:
1.CRC算法(循环冗余算法): 这也是UDP中使用的计算校验和的算法,这种算法比较简单粗暴,是对整个要传输的UDP报文的每个字节进行累加计算,将最终的结果保存在两个字节的校验和之中,尽管在计算过程中可能会出现溢出问题,但是也不影响校验和的计算.发送/接收双方就通过这样的算法来计算出各自的校验和,来检验数据传输的正确性
但是这种算法也存在缺陷,两个不同的原始数据计算出的校验和相同的概率较大(此时这种概率就无法避免了)
2.md5算法: 这是一种经典的计算校验和的算法,算法的具体计算过程不需要掌握,只需要掌握md5算法的三个特性:
- 定长:无论原始数据的长度是多少,经md5算法计算出的校验和的长度是固定的
- 分散:指的是两个内容相似的原始数据(只有一个字节的差距)最终得到结果也是相差很大的
- 不可逆:将原始数据加密为校验和很容易,但是想通过校验和得到原始数据,计算量特比大,以至于在理论上是不可行的
md5算法其实非常适合于哈希算法,在哈希表中,存储key首先要先将其转化为数组下标,再在对应的位置存入数据,我们要求根据key值得到的下标要尽可能的分散,只有这样,才能降低哈希冲突发生的概率
这里提供一个md5加密的网站
链接: link
基于UDP协议的应用层协议
- NFS：网络文件系统
- TFTP：简单文件传输协议
- DHCP：动态主机配置协议
- BOOTP：启动协议（用于无盘设备启动）
- DNS：域名解析协议
当然，也包括你自己写UDP程序时自定义的应用层协议。
在UDP的代码中也可以体现出UDP的四个特点:
1.无连接: UDP在传输额的过程中不会保留对端的信息,需要显式指定传输的目的地
2.不可靠传输:这个性质在代码中体现不出来
3.全双工: 构建一个socket对象,既可以发送消息又可以接收消息
4.面向数据报: 传输的基本单位是数据报DatagramPacket
2.TCP协议的具体格式讲解
TCP相较于UDP来说是一个更加复杂的传输层协议,内置了很多机制,其中TCP中最重要的机制就是可靠传输,可以说TCP设计的初心就是为了保证数据的可靠传输
先来看TCP数据报的格式
和UDP一样,TCP数据报也是由两部分组成:报头 + 数据载荷,相较于UDP来说,TCP的报头之中还有一些其他不一样的数据,下面进行一一讲解
源端口号和目的端口号和UDP中的是一样的,这里不做讲解
4位首部长度
首先我们要知道TCP的报头长度不是固定的,是可变的,TCP的报头长度通过调整选项内部的数据来改变包头的长度,报头长度最短是20字节(没有选项),最长是60字节(选项最长为40字节)
首部就是报头,4位首部长度就是4位报头长度,即通过4个比特位的数据是报头长度的数值部分,数据范围是 0 -15,这里的一个基本单位是4字节
保留6位
这是TCP设计者的一个小心机,我们知道UDP报头固定长度就是64kb,有时候用起来就很麻烦,且难以扩展,TCP预留6位就是为了将来哪一天能用到而做的预备
16位检验和(checksum) 和UDP的校验和相同
要了解TCP数据报报头其他部分的含义还需要通过TCP的特性来进行引入,其实报头剩余部分都是和TCP设计的初心–可靠传输相关
所谓的可靠传输不是保证数据百分之百的传输给接收方,这是不现实的.可靠,指的是负责任,想得周到,即对发送出去的数据负责任,具体体现在TCP在发送完数据之后,会判断接收方是否接收到数据,如果没有接收到就会采取一定的措施,而不是像UDP一样,发送完数据之后万事大吉,什么也不管了,不在乎对方是否接收到数据
可靠传输的实现主要是依赖于以下几个机制:
1.确认应答
确认应答是可靠传输的核心,发送方发送完数据之后,如果接收方成功接收到数据,就会返回一个ack(acknowledge)数据报(应答报文),表示当前接收方已经接收到了你传输过来的数据,发送方收到应答报文,就知道传输成功了,通过这样的一个机制就做到了信息传输的可靠
网络世界复杂繁琐,通信的过程并不是简单的一问一答,且因为网络的不稳定性,往往会产生一些特殊情况,比如"后发先至"这样的问题,确认应答机制对这些情况做出了预防
后发先至
在这种情况下,确认应答机制通过序号和确认序号这样的机制来避免上述情况的发生
TCP在传输数据的时候会对发送的数据添加序号,这样双方在接收和传输数据时就会根据序号是否相同来确保数据顺序的一致性,如下图
TCP报文中:
总结来说,确认应答机制需要注意的地方有以下两点:
- 要保证传输数据和应答报文顺序要一致
- 通过序号这种方式来避免"后发先至"的问题,确保应用程序能够按照正确的顺序来理解发送的消息
实际上,发送的消息的序号并不是简单的一个数据给一个序号这样的方式,而是以字节为单位进行序号的标记(TCP是面向字节流的) 
下面是一个示例:
也就是说,确认序号会被ack数据报携带,通过ack数据报传输给发送方,那么如何判断一个数据报是ack数据报还是普通的数据报呢? 
确认应答机制是TCP实现可靠传输的核心,辅以其他机制共同保障了TCP的可靠传输
2.超时重传
确认应答其实是一种比较理想的情况,他是建立在网络环境通畅的前提下,实际上,网路世界错综复杂,网络也常常是不稳定的 ,要考虑到数据可能因为网络阻塞导致丢包的出现
丢包有两种情况:
但是站在发送方的角度,他是无法区分这两种情况的,发送方判断是否成功发送的依据是有没有接收到ack,所以,只要没有收到ack数据报,发送方就会触发超时重传!
重传是解决丢包问题的一个很好的解决方案,实际上一个丢包发生的概率是很低的,如果两次重传都失败了,可能网络出现了重大故障,此时就没有进行通信的必要了
说明:对于"返回的ack数据报丢失"这种情况,实际上要传输的数据报已经被成功传输过去了,但因为返回的ack丢失,发送方就要重新进行传递相同的数据报,这种方式确实是降低了效率,但是为了可靠性,做出这点牺牲还是必要的~
那什么时候重传呢?接收方通过设置一个等待时间作为触发超时重传的时机,超过等待时间还没有接收到ack,就会触发超时重传,关于等待时间有两点需要注意:
- 等待时间是可以配置的,不同的系统上的等待时间是不同的,我们可以通过调整内核中的一些参数来调整等待时间
- 等待时间是动态变化的,每次的等待时间是会
变长的,但是不会无限制的增长,增长到一定时间就会触发tcp的重置连接
接收缓冲区
对于上述丢包的第二种情况来说,我们实际上是发送了两条相同的数据,站在发送方的角度是为了确保可靠性,但是站在接收方的角度,我实际上是收到了两条相同的数据,注意:此时接收方已经成功接收了
假设是转账的情形,第一次A向B转了500,B成功接收了,B的账户 +500,但是B的ack丢失了,导致A认为我这500元没有传输过去,触发超时重传,重新给B转了500,B的账户此时就 +1000了!这很明显是一个很严重的bug!!!
但是也不用担心,tcp已经帮助我们解决这种bug,tcp设置了一个接收缓冲区来接收数据,A发送给B的数据不会直接被B读取,而是先存储到接收缓冲区内部,对于上述转账的情况,在第一次成功转账到B时,B的接收缓冲区内部就会存储此次传输的数据和序号,由于第二次传输的是相同的数据,这个数据已经被存储到接收缓冲区内部了,接收缓冲区就会删除这个重复的数据,这样就不会产生转账两次这样的操作了
tcp的接收缓冲区不仅能够去重,还可以重排序,确保B的应用程序读取消息的顺序和A发送消息的顺序是一致的(根据序号的大小进行排序)
3.三次握手,四次挥手
1.三次握手
握手(handshake)是tcp中通信双方建立连接的方式,通过发送一个简单的,没有业务数据的数据报来建立连接,以便进行后续的通信操作,连接的建立就像打招呼,是引起双方注意的一种方式,但是没有实际的内容
syn(synchronized)同步报文段,syn就是通信双方进行打招呼的方式,syn内部不含有任何的业务数据,就是为了引起对方的注意而发送的一个数据报,B接收到syn之后会返回syn和ack数据报,A接收到B的ack+syn数据报之后也会返回一个ack给B,通过这三次握手,A和B之间就建立了连接,各自保存了双方的信息
同样的,也可以通过tcp报头中的标志位来判断是否是syn数据报
三次握手的意义:
- 投石问路,确保当前网络是通畅的(如果不通畅,就没有进行数据传输的必要了)
- 保证通信双方接收和发送的能力均正常
这经常会涉及到关于tcp的一个经典的面试题:两次握手能否成功建立连接呢?不能
tcp是全双工的,通信双方都可以接受发送消息,两次握手不能保证通信双方的接收,发送消息的能力均正常,两次握手只能确保A的发送接收和B的接收能力正常,不能确保B的发送能力正常,只有当B收到A的ack之后,才能确保自己的发送能力正常 - 通信双方就一些重要的参数提前进行协商(比如确认序号)
通信双方在传输数据的时候会提前协商好一个比较大的,和上次传输不一样的序号,这样做的目的是为了防止出现"前朝的剑,斩本朝的官",在一次传输过程中,如果突然出现网络异常,传输的数据没有成功传输,而是堵在路上了,进行重连之后,上次传输的数据姗姗来迟,我们应该删除这个前朝的数据,可以通过序号来区别前朝的数据和当朝的数据,如果序号和当朝的序号差异大,就可以认定为这是前朝的数据,就可以进行删除!
一个更加详细的三次握手的示意图:
2.四次挥手
三次握手用于通信双方建立连接,四次挥手用于通信双方断开连接
以下是一个简单的四次挥手的过程
- 第一次挥手(FIN):发送关闭连接的一方向对端发送一个带有FIN标志位的TCP报文段,表示我不再发送数据,但是仍然可以接收数据
- 第二次挥手(ack):对端接收到关闭的请求之后会发送一个应答报文(ack)表示我已经接收到了断开连接的请求
- 第三次挥手(FIN):对端向发送方也发送一个带有FIN标志位的TCP报文段,表示我这一方也不再发送数据
- 第四次挥手(ack):发送方收到对端的应答报文和结束报文段,向对端发送一个ack报文段
上述四次挥手完成之后,连接不会立即断开,而是处于TIME_WAIT状态，等待2倍的最大报文段生存时间（2MSL）后，连接彻底关闭，释放资源
FIN(finish)报文段和syn报文段相同,也是一个不含有业务数据的报文段,可以通过tcp报头的标志位来判断是否是FIN报文段
此处为什么就不能像三次握手那样,将中间两次的报文段合二为一呢?实际上,究竟是通过几次挥手断开连接是不确定的,之所以是不确定的,原因在于发送FIN报文段和ack报文段的时机是不同的(三次握手的ack和syn都是内核进行触发的)
ack报文段的发送是通过系统内核进行发送的,而FIN报文段的发送依赖于应用程序的关闭,即调用socket.close()方法之后才会发送FIN报文段,如果在close之前还有许多要执行的代码,ack报文段就会先于FIN报文段进行发送(后面讲到的延时应答机制通过延迟ack的发送时间,可以让ack和FIN同时发送)
这里有一个问题,如果我的代码中忘记写close了或者没执行到close方法,是否意味着第二次的FIN报文段就不会成功发送?这是会的,四次挥手断开连接是一种正常的连接断开的方式,但是四次挥手没有完成也可以完成连接的断开,这属于异常断开(tcp会在没有收到确认报文之后触发重传,当达到最大的重传次数之后,会关闭连接)
四次挥手的详细图解(注意tcp的状态)
TIME_WAIT状态存在的意义是为了防止最后一个ack报文段丢失,留下的"后手"
如果A最后发送的ack数据报丢失,站在B的角度,B因为没有收到ack数据报,就会触发超时重传,重新发送一个FIN数据报给A,如果A不处于TIME_WAIT状态,而是直接关闭,那么B发送的FIN数据报就没有意义了.
让A处于TIME_WAIT状态,就是让A有时间去等待B重传的FIN数据报,接收到之后重新发送一个ack数据报给B,等待的时间是 2MSL(MSL是两个通信节点之间传输的最大时间,这个参数是可以进行配置的)
网络原理(一)下
https://developer.aliyun.com/article/1480744?spm=a2c6h.13148508.setting.14.5f4e4f0etCqnjj
