wordpress网站音乐播放器,海拉尔网站开发,服务公司有哪些,百度推广账号注册流程1. 应用层
日常开发中最常用到的一层#xff0c;主要涉及到两种情况#xff1a; 1) 使用现成的应用层协议 2) 自己定义应用层协议 1.1 自定义应用层协议的流程
1. 明确前后端交互过程中需要传递哪些信息
实例#xff1a;开发一个外卖软件
打开软件#xff0c;首先需要展…1. 应用层
日常开发中最常用到的一层主要涉及到两种情况 1) 使用现成的应用层协议 2) 自己定义应用层协议 1.1 自定义应用层协议的流程
1. 明确前后端交互过程中需要传递哪些信息
实例开发一个外卖软件
打开软件首先需要展示一个“商家列表”根据需求决定传递哪些信息
a) 请求用户 id用户所在的位置外卖上显示的商家列表都是用户附近的商家
b) 响应商家列表其中包含多个商家每个商家的信息中又包含商家名、图片、距离、评分等 2. 明确组织这些信息的格式使用现有的格式
针对信息组织的格式有很多种方式使用哪种方式都可以但是要保证前后端是同一种方式
例如使用行文本的方式来组织上述数据
a) 请求
格式用户 id,用户位置\n
实际1001,E45N60\n
b) 响应
格式商家 id,商家名称,商家图片地址,商家距离,商家评分;商家 id,商家名称,商家图片地址,商家距离,商家评分\n
实例2001,煎饼果子,http://image1.com,1.5km,4.5;2002,蛋炒饭,http://image2.com,2.0km,4.6\n 上述“行文本”这样简单粗暴的方案在实际开发中很少会用
1.2 常用的信息组织方案如下
1. xml 传统的方案
通过 “成对的标签” 表示 “键值对” 信息
requestuserId1001/userIdpositionE45N60position
/request
xml 进行网络传输的时候会消耗大量的带宽 2. JSON 当前更主流的方案
JSON 也是 “键值对” 格式键和值之间使用 : 分割键值对之间使用 , 分割所有的键值对都使用 { } 括起来
{userId:1001,position:E45N60
}
其相比于 xml 来说可读性比较好同时也能节省一定的带宽
但是它的可读性也不是完全那么好因为其没有明确要求数据的格式所以存在一些极端情况如下
{userId:1001,position:E45N60,userId:1001,position:E45N60,userId:1001,position:E45N60,userId:1001,position:E45N60,userId:1001,position:E45N60}
像这样 { } 里若有 2030 个键值对日常开发很常见可读性就不高了 3. ymlyaml
强制要求了数据组织的格式如下
request:userId:1001position:E45N60
yml 强制要求了键值对必须独占一行而且“嵌套”结构必须通过缩进来进行表示 4. google protobuffer
前三个方案都是关注可读性protobuffer 则关注性能牺牲了可读性通过二进制的方式组织数据直接通过“位置”约定字段的含义不需要传输 key 的名字也会针对传输的数值进行二进制的编码起到一些“压缩”效果
极大的缩减了要传输的数据的体积从而带宽消耗就越小效率就越高
但由于二进制数据无法肉眼阅读调试相关程序的时候就会比较麻烦
2. 传输层
2.1 端口号
端口号是一个整数用来区分不同的进程同一时刻同一个机器上同一个协议一个端口只能被一个进程绑定一个进程是可以绑定多个端口的
端口号是通过 2 个字节的无符号整数表示的取值范围0~655350 端口比较特殊随机设定空闲端口一般不会使用
端口号划分
1-1023知名端口号像 http(80)、https(443)、ssh(22)、ftp(21)、telnet(23)...他们的端口号都是固定的1024-65535操作系统动态分配的端口号客户端程序的端口号就是由操作系统从整个范围分配的
tip
编写服务器一定需要先绑定至少一个端口业务端口和客户端交互服务器运行过程中希望能够对这个服务器的行为进行一些“控制”比如让服务器重新加载某个数据/某个配置/修改服务器的某个功能就可以通过网络通信完成让服务器绑定另一个端口管理端口通过这个端口编写一个客户端给服务器发送一些“控制类”的请求当需要针对服务器运行状态进行检测和调试或需要查看服务器运行中某个关键变量的数值时不能用调试器来调试若使用调试器很可能会使服务器的一些线程被阻塞从而无法给客户端正确提供服务了可以让服务器绑定另一个端口调试端口实现一些相关的打印关键变量的逻辑由客户端发送对应的调试请求
2.2 UDP 协议
2.2.1 UDP 的“数据格式”/“报文格式” tip
实际上的 UDP 的数据并没有“换行”动作如下图 UDP 报头中的四个字段没有指定分隔符而是通过固定长度来进行区分的总共 8 字节
UDP 报文长度 报头长度 载荷长度
报文长度的单位是 “字节”如报文长度 1024 整个 UDP 数据报就是 1024 字节
由于是使用 2 字节来表示报文长度所以最大值就是 65535 64KB 2.2.2 关于校验和
前提网络传输过程中是非常容易出现错误的电信号/光信号/电磁波 受到环境的干扰会使里面传输的信号发生改变比特翻转
校验和存在的目的就是为了能够 “发现” 或者 “纠正” 这里出现的错误给传输的数据中引入额外信息checksum用来 发现/纠正 传输数据的错误只是 “发现错误” 携带的 额外信息 可以少一点若是想“纠正错误”就需要 携带更多额外信息消耗更多的带宽
1) 校验和纠正原理
1. UDP 中使用 2 个字节作为校验和使用方案为 CRC校验和循环冗余校验
把 UDP 数据报整个数据都进行遍历分别取出每个字节往 一个 两个 的变量上进行累加由于整个数据可能很多加着加着可能结果就溢出了溢出也没关系重点不关心最终加和是多少而是关心校验和结果是否会在传输中发生改变具体流程如下 当接收方收到数据后就可以根据数据的内容按照同样的算法再算一遍校验和得到 checksum2如果传输的数据在网络通信过程中没有发生任何改变那么 checksum1 checksum2反之如果 checksum1 ! checksum2就可以认为数据在网络传输中出错了 2) MD5 和 SHA1
除了 CRC 之外另外两个典型的算法其中的 MD5 算法本质上是一个 “字符串 hash 算法”。背后的实现过程是一个“数学过程”可简单理解为套公式 MD5 的特点SHA1也是这三个特点 1) 定长无论输入的字符串长度多长算出的 md5 的结果都是固定长度适合做 校验和 算法 2) 分散输入的内容哪怕只有丁点改变得到的 md5 值都会相差非常大适合做 hash 算法 3) 不可逆根据输入内容计算 md5 非常简单但若是已知 md5 值想要还原出原始的内容理论上是不可行的适合作为加密算法 2.3 TCP 协议
TCP 全称为“传输控制协议Transmission Control Protocol”
2.3.1 TCP 的“数据格式”/“报文格式” 4 位首部长度TCP 的报头长度表示该 TCP 头部有多少个 32 位 bit此处的长度单位是 “4 字节”不是 “字节” 保留(6位)现在虽然不用但是先申请下来如果未来某天 TCP 需要新增属性/或者某个属性的长度不够用就可以把保留位拿出来使用用于考虑未来的可扩展性 选项optional 更准确的翻译 “可选的”TCP 报头变长的主要原因就是 选项 可以有也可以没有 2.3.2 TCP 相关机制
TCP 最核心的机制就是 “可靠传输”代码层面感知不到系统内核完成了这里的工作但是也不能做到 100% 送达只能尽可能使数据能到达对方
1) TCP 核心机制(一)——确认应答
感知对方是否收到所谓的感知对方收到就是靠对方告诉一声应答报文如下图 上述应答报文的机制还存在问题如果发送方发送多个消息的时候就可能存在歧义如下 后发先至是客观的情况无法改变可以给传输的数据添加“编号”通过编号可以区分出数据的先后顺序 这样即使收到的应答报文顺序出现错乱也能识别出来
由于 TCP 是面向字节流的实际上编号并非是按照“第一条、第二条”这样的方式来编排的而是按照“字节”第 1 个字节...第 1000 个字节
每个字节都有一个独立的编号字节和字节之间编号是连续的递增的按照字节编号这样的机制就称为“TCP 的序号”
在应答报文中针对之前收到的数据进行对应的编号称为 “TCP 的确认序号” 32 位序号
由于编号是连续的对于一个 TCP 数据报来说知道了数据部分的第一个字节就知道了后续所有字节的序号序号只是针对 TCP 数据报携带的载荷来进行编号的TCP 报头不参与 这里 32 位序号4字节表示的范围是 0~42亿9千万0~4GB是否意味着一个 TCP 一次传输最大就只能传输 4GB呢
答案是否定的因为 TCP 是面向字节流的一个 TCP 数据报一个 TCP 报头 载荷和下一个 TCP 数据报携带的数据天然就是 “可拼装的”
比如要传输一个特别大的数据传输过程中本身就会通过多个 TCP 数据报进行携带这些 TCP 数据报彼此之间携带的载荷都是可以在接收方自动被拼起来的
这样就不像 UDP 存在传输的上限使用 UDP 传输大数据就需要考虑调用这一次 send 操作参数是否超过 64KB超过 64KB 就不行 32 位确认序号的设定方式 如果是普通报文序号是有效的确认序号是无效的如果是 ack 应答报文序号和确认序号都是有效的这是另一套编号的体系和传输的数据的序号不是一套 再谈 “后发先至”
TCP 就可以针对接收方收到的数据进行重新排序确保应用程序 read 到的数据一定是和发送方发的数据顺序是一致的 2) TCP 核心机制(二)——超时重传
实际上网络传输中并不是一帆风顺的而是可能会出现 “丢包” 的情况 丢包的原因 1) 数据传输过程中发生了 bit 翻转收到这个数据的接收方/中间路由器计算校验和发现对不上了 出现这种情况就会把这个数据报丢弃掉不继续往后转发/不交给应用层使用了 2) 数据传输到某个节点路由器/交换机这个节点负载太高了 某个路由器单位时间内只能转发 N 个包现在网络高峰期这个路由器单位时间需要转发的包超过了 N后续传输过来的数据就可能被这个路由器直接丢弃掉 发生丢包是完全随机的不可预测的 TCP 对丢包的应对方式
TCP 中通过应答报文来区分是否丢包收到应答报文说明数据没丢包没收到说明数据丢包了发送方发送数据之后会给出一个 “时间限制”超时时间如果在这个时间限制之内没有收到 ack就视为数据丢包了
如果丢包就重新发一次假设网络丢包率 10%数据报到达对方是 90%此时进行一次重传两次传输至少一次到达对方的概率1 - 10% * 10% 99%传输次数越多数据到达对方的概率就越大 TCP 的去重操作 发送方无法区分上面两种情况当出现第二种情况后B 就收到了两份一样的数据若是传输的数据是 “扣款” 这样的请求就会造成扣两次款的问题
TCP 针对上述情况在接收方会有一个 “接收缓冲区”收到的数据先进入到缓冲区里后续再收到数据就会根据序号在缓冲区中找对应的位置排序如果发现当前序号 1-1000 这个数据已经在缓冲区中存在了就直接把新收到的数据丢弃了去重
确保应用程序调用 read 读取出来的数据是唯一的不重复的 超时重传时间的设定
这里的时间不是固定值而是动态变化的如发送方第一次重传超时时间是 t1如果重传之后仍然没有 ack还会继续重传第二次重传超时时间是 t2其中 t2 t1每多重传一次超时时间的间隔会变大/重传的频次会降低
这是因为经过一次重传之后就能让数据到达对方的概率提升很多再重传一次又会提升很多若是重传几次都没有到达说明网络的丢包率已经达到了一个非常高的程度网络发生了严重故障大概率没法继续使用了
重传不会无休止的进行当重传达到一定次数之后TCP 就不会继续重传了会先尝试进行 “重置/复位 连接” 发送一个特殊的数据报 “复位报文”如果网络这时恢复了复位报文就会重置连接使通信可以继续进行如果网络还是有严重问题复位报文也没有得到回应此时 TCP 就会单方面放弃连接 tip
1) 连接就是通信双方各自保存对方的信息发送方释放掉之前保存的接收方的相关信息这个连接就无了
2) 确认应答 和 超时重传 相互补充共同构建了 TCP “可靠传输机制”TCP 的可靠传输不是通过“三次握手和四次挥手”保证的 3) TCP 核心机制(三)——连接管理
在正常情况下TCP 都要经过三次握手建立连接四次挥手断开连接
三次握手 三次握手的意义
1) 投石问路初步的验证通信的链路是否畅通进行可靠传输的 “前提条件”
类似于日常中地铁在开始运营之前都会空跑一趟先进行“链路畅通的验证”
2) 确认通信双方各自的发送能力和接收能力是否正常
类似于连麦时 tip a) 四次也行就是将中间一次拆成两次但没必要 b) 两次不可行无法完成通信双方针对各自接发能力的验证 c) 针对 TCP 来说必须是三次握手但是其他协议握手过程不一定是三次 3) 让通信双方在进行通信之前对通信过程中需要用到的一些关键参数进行协商
类似于开会时准备茶杯 TCP 通信时起始数据的序号就是通过三次握手协商确定的换而言之TCP 序号并不是从 1 开始的每次建立连接 TCP 的起始序号都不同而且故意差别很大
这样做的意义就是避免出现 “前朝的剑斩本朝的官”如下 给每个连接都协商不同的起始序号如果发现收到的数据和起始序号以及最近收到的数据序号有较大差距就把这个数据视为“前朝”数据
tip
三次握手对于可靠性是有一定的支持的但是 “可靠性就是三次握手体现的”这个说法非常武断三次握手只是建立连接的时候进行的一旦连接建立好数据就开始传输了和三次握手没关系了
确认应答 超时重传 才是负责传输数据中的 “可靠性” 四次挥手 通信双方各自给对方发送“FIN”各自给对方返回“ACK”通过这个过程双方各自把对端的信息删除掉
三次握手是因为中间两次的交互合并在一起了而对于四次挥手来说中间两次不一定能合并大概率不能
因为对于三次握手来说中间的两次 ACKSYN 都是在内核中由操作系统负责进行的因为其执行的时机都是在收到 SYN 之后所以可以合并
对于四次挥手来说ACK 是由内核控制的但是 FIN 的触发则是通过应用程序调用 close/进程退出来触发的
TCP 回显服务器中例 三次握手四次挥手中的状态 1) LISTEN服务器进入的状态
服务器把端口绑定好相当于进入了 listen 状态了此时服务器就已经初始化完毕准备好随时迎接客户端了
2) ESTABLISHED 客户端和服务器都会进入的状态
TCP 连接建立完成保存了对方的信息了接下来就可以开始进行业务数据的通信了
3) CLOSE_WAIT被断开连接一方会进入这个状态
先收到 FIN 的一方等待代码执行 close 方法
tip如果发现服务器这端存在大量的 CLOSE_WAIT 状态的 TCP 连接说明此时服务器代码可能有 bug需排查 close 是否写了是否及时执行到了
4) TIME_WAIT主动断开一方会进入这个状态
此处的 TIME_WAIT 按照时间来等待达到一定时间之后连接就释放了这是为了防止发送给对端的 ACK 丢包 当 A 保留一段时间后没有收到 FIN说明刚才的 ACK 没丢包就可以释放这里的连接了
TIME_WAIT 存在的时间称为 2MSLMSL 数据报在网络传输中消耗的最大时间 4) TCP 核心机制(四)——滑动窗口
TCP 的可靠传输代价是降低了传输的效率为了在可靠传输的基础上也能有一个不错的效率引入了滑动窗口这里的提高效率只是“亡羊补牢”使传输效率的损失尽可能降低并不能使传输效率比 UDP 还高
没有滑动窗口时的传输如下 A 每次需要收到 ACK 之后再发下一个数据
有滑动窗口后 把 “发送一个等待一个” 改为 “发送一批等待一批”把多次等待 ACK 的时间合并成一份时间批量发送的数据越多可以认为效率就越高 窗口控制与重发控制在滑动窗口传输中出现丢包情况
情况一数据包已抵达ACK 丢了 情况二数据包丢了 tip
滑动窗口/快速重传、确认应答/超时重传彼此之间并不冲突他们是分情况的
如果通信双方单位时间发送的数据量比较少就按照 确认应答/超时重传
如果单位时间发送的数据比较多就会按照 滑动窗口/快速重传 5) TCP 核心机制(五)——流量控制
滑动窗口的窗口大小对于传输数据的性能是直接相关的窗口越大传输越快但是也不能无限大因为通信是双方的事发送方发的快的同时也要保证接收方能处理的过来滑动窗口提高速度相当于踩油门流量控制制约速度相当于踩刹车 解决方案通过 “定量” 的方式来实现制约看接收缓冲区剩余空间大小 TCP 中接收方收到数据的时候就会把接收缓冲区剩余空间大小通过 ACK 数据报反馈给发送方
下一步发送方就可以根据这个数据来设置发送的窗口大小了 tip流量控制不是 TCP 独有的机制其他的协议也可能会涉及到流量控制比如数据链路层中有的协议也支持流量控制 6) TCP 核心机制(六)——拥塞控制
拥塞控制与流量控制是有关联的也是踩刹车
流量控制站在接收方的视角来限制发送方的速度
拥塞控制站在传输链路的视角来限制发送方的速度 流量控制可以精准的使用接收方 接收缓冲区 剩余空间来进行衡量
但站在传输链路的角度考量中间节点的情况就很麻烦了因此可以通过 “做实验” 的方式来找到一个合适的发送速度面多加水水多加面
1. 先按照一个比较小的速度发送数据
2. 数据非常流畅没有丢包说明网络上传输数据整体比较流畅就可以加快传输数据的速度
3. 增大到一定的速度之后发现丢包了说明网络上可能存在拥堵了就减慢传输数据的速度
4. 减速之后发现不丢包了再加速
5. 加速之后丢包了再减速
tip发送速度是持续动态变化的因为网络环境也是一直变化的
流量控制和拥塞控制都会限制发送窗口这两个机制会同时起作用最终实际的发送窗口大小取决于两个机制得到的发送窗口较小值
拥塞控制中窗口大小具体的变化过程 1) 刚开始传输数据拥塞窗口会非常小用一个很小的速度来发送数据因为当前网络是否拥堵是未知的刚启动时发数据很慢
2) 不丢包增大窗口大小指数增长增长速度特别快短时间内达到很大的窗口大小
3) 增长到一定程度达到某个指定的阈值此时即使没有丢包也会停止指数增长变为线性增长避免太快进入到丢包的节奏
4) 线性增长也会使发送速度越来越快达到某个情况下就会出现丢包
一旦出现丢包接下来就要减少发送的速度减小窗口大小两种处理方式
a) 经典的方案回归到开始非常小的初始值然后指数增长再线性增长已废弃不用
b) 现在的方案回归到新的阈值上线性增长以后都不会指数增长了 7) TCP 核心机制(七)——延时应答
延时应答是提升效率的机制尽可能降低可靠传输带来的性能影响 其实在收到数据的时候应用程序也会源源不断的消费接收缓冲区中的数据
如果我们返回 ACK 的时间稍晚一点应用程序就有可能读取缓冲区中更多的数据假设让 ACK 不是立即返回而是 100ms 之后再返回可能在这 100ms 内应用程序又消费掉了 2KB 的数据此时再返回 ACK 携带的窗口大小就是 6KB了
此时返回的 ACK 窗口大小大概率要比立即返回 ACK 的窗口大小更大之所以不是一定
a) 应用程序代码的实现逻辑是不是一刻不停的读取数据
b) 延时时间内是否发送方会发来新的数据 8) TCP 核心机制(八)——捎带应答
在延时应答的基础上引入的提升效率的机制把返回的业务数据和 ACK 两者合二为一了
实际网络通信中大部分的情况都是 “一问一答” 的形式 9) TCP 核心机制(九)——面向字节流
通过面向字节流的方式传输数据都会涉及到 “粘包问题”粘的是 TCP 携带的载荷【应用层数据包】 上面这样应用层数据包在 TCP 的接收缓冲区中连成一片粘在一起就称为 “粘包问题”
要想解决粘包问题关键就是要明确 “包之间的边界”
方案一指定分隔符适用于文本类的数据xml、yml、json 用此方案
在前面 TCP echo server 的例子中我们约定的做法是请求响应都以 \n 结尾
发送请求响应的时候专门使用 println 进行写数据读取请求响应的时候专门使用 scanner.next 按照 \n 进行解析
tip需要确认数据内容的正文中不能包含分隔符如果传输的数据是纯文本数据此时使用 \n 或者 ; 之类的可能都不合适但是可以使用 ascii 中靠前的 “控制字符”这些字符早就不再使用了如下图 方案二指定数据的长度适用于传输二进制protobuf 用此方案
例如约定每个应用层数据包开头的 2 / 4 个字节表示数据包的长度 tip
1) 如果希望在文件中存储结构化数据也是存在这样的问题所以存文件也会经常使用 xml/json 这样的格式来存储解决粘包问题
2) UDP 这种面向数据报的传输方式就不涉及 粘包问题 因为 send/receive 得到的就是一个完整的 DatagramPacket这里携带的二进制的字节数组就是一个完整的应用层数据包了 10) TCP 核心机制(十)——异常情况处理
1) 进程崩溃
Java 中的体现就是抛出异常如果没有 catch 的话最终会到 JVM进程就直接无了
进程崩溃看起来挺严重实际上操作系统会进行善后当进程崩溃时进程中的 PCB 就要被回收PCB 中的文件描述符表里对应的所有文件也都会被系统自动关闭
其中针对 socket 文件就会触发正常的关闭流程TCP 四次挥手 2) 主机关机正常流程的关机
正常流程点击关机按钮此时操作系统会先干掉所有的进程此过程中也会触发四次挥手但会分为两种情况 a) 四次挥手非常快四次挥手已经完成了关机动作才真正完成 b) 四次挥手没来的及挥完关机就完成了如下图 3) 主机掉电拔电源 a) 接收方掉电 A 给 B 发送的数据不会再有 ACK 了
A 触发超时重传重传的数据依旧没有响应反复多次之后A 尝试重置连接rst重置操作也没有 ACKA 就会单方面释放连接A 把保存的 B 的信息删除掉 b) 发送方掉电 A 发着发着数据突然停了B 的视角并不知道 A 是无了还是休息一下晚点再发
此时 B 就会给 A 发送一个数据包不携带业务数据只是为了触发 ACK查询 A 的状态
如果发了这个 “探测报文” 之后A 返回了 ACK说明 A 只是休息一下若发了探测报文甚至发了多个探测报文A 都没有 ACK就可以视为 A 无了
这种探测报文是周期性的同时这个报文时用来探测对方的 “生死” 的于是把这样的报文称为 “心跳包”
计算机中非常广泛的使用“心跳包”的思想TCP 内置了心跳包由于 TCP 内置的心跳包周期比较长秒级~分钟级应用程序这一层通常也会自行实现一些心跳包达到更快速的 “保活机制” 4) 网线断开
和主机掉电一样
TCP 中的其他标志位 1. URG 是和紧急指针配合使用的
当 URG 设置为 1 时紧急指针能够生效紧急指针里面保存的是一个偏移量
TCP 正常情况下都是按照顺序来传输数据的紧急指针就是让后谜案的数据排队根据紧急指针的偏移量把指定位置的数据优先发送出去这是特殊场景的特殊方案不通用日常开发很少直接涉及
2. PSH 催促标志位
带有这个标志位的数据就相当于提醒接收方要尽快的来处理这个数据也是特殊场景下的特殊方案
3. 选项
选项中包含 “窗口扩展因子”结合窗口大小使用
实际窗口大小 报头窗口大小 窗口扩展因子相当于指数增长 TCP/UDP 对比
TCP 对于数据需要可靠传输的场景是首选
UDP 对于可靠性要求不高对于性能要求很高的场景是首选
经典面试题用 UDP 实现可靠传输
参考 TCP 的可靠性机制在应用层实现类似的逻辑例如
引入序列号保证数据顺序引入确认应答确保对端收到了数据引入超时重传如果隔一段时间没有应答就重发数据等等。。。
