应用程序与协议

应用程序在应用层这里很多时候都是程序员自定义应用层协议步骤1、根据需求明确要传输的信息2、约定好信息按照什么样的格式来组织的所谓的网络协议其实就是约定即程序员在代码中规划好数据如何进行传输

1、点外卖

此处假设就使用简单的格式来组织,使用文本的方式.三个属性,使用来分割

1000,100,30()---代码中构造出一个这样的字符串,给写入到

Tcp

此处假设使用简单的格式来组织,使用文本的方式,每个商家信息占一行,每个属性使用来分割

魏家凉皮,图片地址3,3km,评分4.9

上述这个过程,就是自定义协议.针对这里的情况,使用啥样的格式来组织,只要客户端和服务器双方能够对应上都是可以的

1.2

标签写起来非常繁琐,传输的时候也占用更多网络带宽,(maven,

就会使用

}把所有的键值对给包裹起来键值对之间,使用来分割键和值之间,使用

string

在网络通信中仍然非常流行除非是些对于性能要求非常高的场景,不使用json

json

pb)使用二进制的方式来组织数据可以保证带宽占用最低(相当于把要传递的信息按照二进制形式压缩了)

占用带宽最低,传输效率最高.非常适合于对于性能要求比较高的场景,

可读性不好(二进制结构,肉眼无法直接阅读),一定程度的影响开发效率,

应用层中也有一些现成的应用层协议其中最知名的,最广泛使用的,就是

HTTP

协议了(超文本传输协议)~~“超文本”不仅仅是文本还有图片,视频,音频,字体..

传输层

端口号写一个服务器,必须手动指定一个端口号,通过端口来区分当前这个主机上的不同的应用程用,客户端在通信的时候也会有一个端口号(代码中感受不到),系统自动分配的一个客户端,

个字节.表示的数据范围0-65535一般来说,0是不用的.其中1-1023

称为知名端口号1024-65535

协议里)像UDP,TCP这样的报文格式是最初一些大佬们设计并约定出来的内容最后被整理成了一份标准文档称为RFC标准文档

2.1.2

于业务的发展,搜集信息越来越多了样式也越来越复杂了.导致商搜服务器和入口服务器之间交互的数据量,已经接近

64kb

udp报文长度就是64kb了.如果超过上限,数据就会出现截断,最终展示在页面上的数据肯定就会出错

方案一把数据拆分成多个包,使用多个

校验和是计算机中非常广泛使用的概念.由于在网络传输中,一些设备被外部干扰,就可能会出现数据传输出错的情况.在数据传输的过程中低电平被干扰之后扰下就成了高电平因此,

校验和,其实本质上也是一个字符串,体积比原始的数据更小,又是通过原始的数据生成的.

如果接收方收到的原始数据相同,得到的校验和就一定相同同理,校验和相同,原始数据大概率相同

如何基于校验和来完成数据校验呢

大概率是相同的(理论上存在不同的可能性,概率比较低,工程上忽略不计)

计算校验和,有很多种算法,

把当前要计算校验和的数据,每个字节,都进行累加,把结果保存到这

两个字节的变量中,累加过程中如果溢出,也没关系如果中间某个数据,出现传输错误,第二次计算的校验和就会和第一次不同

CRC

md5,都是固定长度-校验和本身就不应该很长,要不然不方便网络传输

2.分散,给定两个原始数据,哪怕绝大部分内容都一样,只要其中一个字节不同,得到的

md5

计算量非常庞入,以至于超出了现有计算机的算力极限,理论上是不可行的.

2.1.4

协议本身不会存储对端的信息,要在发送数据的时候,显式指定要传输给谁

3、面向数据报

tcp报头长度是不固定的报头最短是20字节没有选项报头最长是60字节一般来说选项最长的是40字节4bit00XF此处的单位是4字节

保留(6位)

就是当前现在不用,但是先占个位置,后面如果有需要,再使用.(留下了扩展的余地~~)

16位检验和

发送方,把数据发给接收方之后,接收方收到数据就会给发送方返回一个应答报文(acknowledge,

ack).发送方如果收到这个应答报文了,就知道自己的数据是否发送成功了

但是每天请求能及时的收到正确的应答这个情况太理想了,实际上网络传输数据可能会出现后发先至---一个数据包在进行传输的过程中走的路径可能是非常复杂的.即不同的数据包,可能走不同的路线.)这样的情况‘

TCP在此处要完成两个工作

2、确保在出现后发先至的现象时,能够让应用程序这边仍然按照正确的顺序来理解数据

所谓的序号就是一个整数.大小关系,就描述了数据的先后顺序准确的说,序号不是按照一条两条方式来进行编号的,而是按照字节来编号的因为tcp是面向字节流的

ack

数据包,里面携带的确认序号告诉发送方,哪些数据已经被确认收到了

此时发送方,就心中有数了,就知道了自己刚发的数据是到了还是没到.TCP

ack

q2为啥确认序号是现在这样的规则?即用收到的最后一个字节的序号1来表示呢

2、超时重传

确认应答,描述的是一个比较理想的情况。

但是如果网络传输过程中,出现丢包则发送方,势必就无法收到

ACK

把网络想象成公路即错综复杂的公路网在公路上就会有很多的收费站。

平时车流量很通畅但是当节假日的时候收费站这里经常会堵车好几个小时

在网络中,“收费站可以理解成是一些路由器/交换机,如果数据包太多了,就会在这些路由器/交换机上出现堵车但是路由器针对“堵车”的处理,不会把这些积压堵塞的数据包都保存好,而是会把其中的大部分数据包直接给丟弃掉.此时这个数据包就在网络上消失了,

真实的网络环境,是错综复杂的,我们不会知道哪个节点上会出现上述堵车情况,也不知道啥时候会出现丢包,

丟包是非常随机的事件.这个事情出现概率的大小,取决于网络基础设施施同时也取决于网络环境.

tcp

对于发送方的来说,无法区分这两种情况.无论出现上述哪种情况,发送方都会进行重新传输”第一次是丢了,重传一下很大概率就能传过去重传就是一个很好的丢包下的补救措施了

q3发送方,何时进行重传?

来了,此时就自然视为数据到达如果达到这个时间之后,数据还没到,就会出发重传机制

q4关于等待时间

1、初始的等待时间,是可配置的.不同的系统上都不一定一样也可以通过修改一些内核参数来引起这里的时间变化.

2、等待的时间,也会动态变化.每多经历一次超时,等待时间都全变长变长,隐含的含义,就是对能够正确传输数据这件事前面按照丢包概率

10%

ack,第二次等待的时间就会比第一次更长拉长也不是无限拉长,重传若干此时,时间拉长到一定程度,认为数据再怎么重传也没用了,

就放弃

会有一个接收缓冲区就是一个内存空间,会保存当前已经收到的数据,以及数据的序号

接收方如果发现,当前发送方发来的数据,是已经在接收缓冲区中存在的

数据了),接收方就会直接把这个后来的数据给丢弃掉,确保应用程序进行

read

所谓的接受缓冲区,不仅仅是能进行去重,还能进行重新排序,确保发送的顺序,和应用程序读取的顺序是一致的

3、连接管理

这里的握手,也是类似给对方传输一个简短的,没有业务数据的数据包并通过这个数据包,来唤起对方的注意,从而触发后续的操作.

TCP

在建立连接的过程中,需要通信双方一共打三次招呼”才能够完成连接建立的简单分析图如下所示

建立连接A

就是所谓的客户端被动接受的一方,就是服务器”同步报文段,就也是一个特殊的

TCP

q6三次握手是要解决什么问题?通过四次握手,是否可行?通过两次握手,是否可行呢?

q7三次握手核心作用

握手这里要协商的信息,其实是有好几个的,至少大家要知道,tcp

开始的)每次连接建立的时候,都会协商出一个比较大的,和上次不太一样的值.

就可能在新的连接好了之后,旧连接的数据姗姗来迟这种迟到的数据,应该要丢弃掉的!

如何区分数据是否是来自于上个朝代?就可以通过上述序号的设定规则来实现-如果发现收到的数据序号和当前正常数据的序号差异非常大就可以判定为是上个连接的数据就可以直接丢弃了

断开连接四次挥手

建立连接,一般都是客户端主动发起断开连接,客户端和服务器都可以主动发起

q8和

不同,此处的四次挥手,能否把中间的两次交互合二为一?不一定!!

第二个

FIN,这中间要经历多少时间,经历多少代码,是不确定的!!FIN

就会在

都是内核触发的.因为是同一个时机,可以合并但是这里的四次挥手,

ACK

就一直发不出去??(有可能的)并非所有的连接都是好聚好散但是,TCP

ACK