网络原理(一)下

简介: 网络原理(一)下

网络原理(一)上

https://developer.aliyun.com/article/1480742?spm=a2c6h.13148508.setting.14.5f4e4f0eeZsU7J

💕"Echo"💕

作者:Mylvzi

文章主要内容:网络原理(一)

4.滑动窗口机制

滑动窗口机制是提高TCP传输效率的一种机制

TCP的可靠传输是会降低数据的传输效率的(多出了等待ack的时间),通过滑动窗口机制缩短了等待ack的时间,来提高数据传输的效率,具体提升的方式见下图:

传统的tcp传输数据的方式:

利用滑动窗口机制进行的传输:

传统的tcp进行数据的传输是一次只传输一条数据,等到该条数据的ack返回之后才进行下一条数据的传输.而滑动窗口机制通过批量传输数据的方式,缩短了等待ack的时间,提高了效率,单次可以发送最大的数据量被称`窗口大小

在滑动窗口机制下,确认应答机制是可以正常工作的,但是如果出现丢包就要出发超时重传,这里的重传机制和上述的重传还有所不同

1.ack数据包丢失

B返回的确认序号为1001的ack数据报丢失,这种情况下不需要进行重传.原因在于确认序号为2001的ack数据报成功传输给A了,确认序号的意义就是当前序号之前的所有数据都已经成功接收,A收到2001的ack数据报,就知道序号为1-2000的所有数据都成功传输了

2.数据报丢失

这里的重传和之前的重传是不一样的,之前重传可能会出现传输重复数据的情况,但是滑动窗口机制下的重传并不会出现这种情况,效率相较于普通的重传更高,被称为快速重传

滑动窗口其实是一种使tcp根据通信数据量进行动态调整的一种机制

  1. 如果通信双方通信数据量大,通信频繁,就会采用滑动窗口机制和快速重传
  2. 如果通信双方通信的数据量小,通信不频繁,就采用普通的tcp传输和普通的超时重传

5.流量控制

前提:滑动的窗口越大,等待ack的时间就越少,传输的效率就越高,但是窗口越大传输效率就越高么?显然不是的,我们还要考虑接收方处理数据的能力,窗口越大,批量传输的数据就越多,接收方需要处理的数据就越多,如果超过了接收方可以处理数据的上限,就有可能出现丢包的情况,此时发送方就需要进行重传,导致效率下降

这种情况的出现违背了tcp的初心–>可靠传输,提高效率的前提应该是在可靠性的基础之上进行效率的提升,不能一昧的提高效率,忽视可靠性

流量控制就是站在接收方的角度,来约束发送方的窗口大小的一种机制,发送方发送数据的速率不应该超过接收方处理数据的能力

数据由发送方传输到接收方时,不会直接被接收方的应用程序读取,而是先存储到接收方的接收缓冲区内部,这个接收缓冲区是内存的一个区域(tcp的socket创建),接收方读取数据时直接从接收缓冲区内部读取数据

接收缓冲区存在的意义就像是生产者消费者模型中的阻塞队列,降低了连接双方的耦合性

接收方处理数据的效率是通过接收缓冲区的剩余空间大小进行衡量的,剩余空间大小越大,处理数据的效率就越高,反之就越低

接收方在返回ack数据报是会返回当前接收缓冲区剩余空间的大小,发送方收到后,就会动态的调整窗口大小,来保证接收方有足够能力来处理数据

以下是流量控制机制示意图:

说明:

  1. 接收方每次传输ack时会传输当前接收缓冲区内部剩余空间的大小,发送方根据这个大小来动态的调整窗口大小,适应接收方处理数据的速率
  2. 当接收方返回的大小是0时,此时接收方的接收缓冲区已经爆满不能再处理额外的数据了,发送方收到后就停止传输数据,开始等待接收缓冲区有额外的空间
  3. 发送方通过发送窗口探测包的方式来判断接收缓冲区是否有空余空间,这个数据报不含有任何的业务数据,当接收缓冲区的大小不再为0时,发送方就继续传输数据

tcp的报头中的16位窗口大小就是接收缓冲区的大小

6.拥塞控制

流量控制考虑的是接收方处理数据的能力,关注的是通信终点处理数据的能力,但数据的传输还需要通过中间的网络节点进行传输,如果发送的数据超过了中间节点可以接收的数据上限,也会发生丢包,发送方还是需要重传

也就是说,我们还需要考虑中间节点处理数据的能力,接收方处理数据的能力可以通过接收缓冲区的大小来进行判断,但是中间节点处理数据的能力不容易判断,此时可以通过实验的方式来动态的调整发送数据的速率(窗口大小)

具体的实验方式很简单,让发送方先以一个比较小的速率发送数据(小窗口),如果在这个过程中发送很顺利,没有出现丢包的情况,就逐渐增加发送速率(增大窗口),随着窗口的不断增大,就有可能出现丢包,一旦出现丢包就降低发送速率,重新以一个比较小的窗口发送数据

慢启动曲线很好的演示了实验的过程

说明:

  1. ssthresh是慢启动阈值(Slow Start Threshold)的缩写,它是一个拥塞窗口的上限,是指数增长的终点,一旦超过ssthresh,就进入拥塞避免(Congestion Avoidance)模式(线性增长阶段)
  2. ssthresh会动态调整,具体来说会调整为上一次达到网络阻塞时的窗口大小的一半,这样做的目的是让发送方可以更高效率传输数据,延缓达到网络阻塞窗口大小的时间(增大传输轮次)

实际上,后来tcp对慢启动算法进行了一定的优化,具体优化体现在:在上一次达到网络阻塞时,下一次不会直接从特别小的窗口进行数据传输,而是直接从新的ssthresh值开始进行传输(省略了指数增长的情况),曲线如下图

流量控制和拥塞控制是对滑动窗口机制的一种限制,约束,使其不忘初心–可靠传输,最终的窗口大小是Math.min(流量控制的窗口大小,拥塞控制的窗口大小)

7.延时应答

进一步优化传输效率的方式,通过延时应答的方式,增大窗口大小,使发送方一次发送的数据更多(延缓ack的等待时间,让应用程序多处理一些数据,使接收缓冲区的内部剩余空间大小更大一些)

举个例子,如果接收方收到数据之后立即返回ack, 剩余空间的大小是10 如果延时应答 2ms 在这2ms内接收方可以从接收缓冲区内读取一定的数据 此时剩余空间的大小就变为 12了 接收缓冲区的剩余空间增大 窗口增大 传输效率增加

在上述四次挥手部分,我们说到断开连接不一定必须经过四次挥手,也有可能是三次.如果通过延时应答的方式延迟ack的发送时机,使其和FIN数据报一起发送,就构成了三次挥手断开连接

8.捎带应答

捎带应答是在延时应答的基础之上对传输效率的进一步优化

通信时,双方传输的都是含有业务逻辑的数据,通常都是"一问一答"这样的方式(全双工)

将业务数据报和确认信息(ack)合二为一,减少tcp封装分用的次数,进一步提高效率

9.粘包问题

粘包问题其实不是tcp特有一种问题,而是面向字节流传输数据的机制都存在的一种问题,tcp在传输的过程中是通过字节流进行传输的(两个字节流对象),传输的数据通过字节流发送,接收时也是接收一个一个的字节,但是在接收的时候你无法明确哪里到哪里是一个完整的要传输的信息,一次读取的字节个数也是不一定的,这就会造成读取错误的出现

相比之下,UDP这种面向数据报传输的协议就不会出现粘包问题:

如何解决粘包问题呢?核心在于:明确好应用层协议,确定好应用层数据报的边界

常见的做法有:

  1. 设置分隔符; 如设置 \n 为一个完整的应用层数据报的边界,接收方在读取数据的时候就会以 \n 作为每次读取数据的结束标志
  2. 引入长度; 发送数据的时候对每一个要发送的数据附加上数据的长度,接收方在读取数据时就会先读取到长度,根据这个长度来确定每次读取数据的范围

    一些常见的应用层协议格式的数据报都是自带"结束标志的",如xml有开始,结束标签,json格式是通过{}作为传输数据的边界,protobuffer是通过二进制长度来确定边界的

10.异常处理

异常处理指的是,在通信时如果发生意外,tcp的解决方案

1.进程崩溃

进程崩溃其实就是进程终止,进程占有的文件描述符表被释放,相当于调用了socket.close()方法,接着就会触发FIN数据报,完成一次正常的四次挥手的断开连接的过程

tcp的连接可独立于进程存在,进程没了,tcp连接仍然可以存在(进程没了,通信双方可以继续接收双方发送的数据报)

2.主机关闭(正常关机)

主机关闭时,会先触发FIN,但是主机关闭意味着整个系统的关闭,虽然发送方可以发送FIN数据报,但是对端的FIN和ack有可能因为系统的关闭导致无法正常传输到发送端,站在对端的角度,就是数据报发送失败,要执行超时重传,重传几次之后发现都没有成功发送,就会自动关闭连接了

3.主机断电(非正常关机)

主机的突然断电是一瞬间的事情,对于通信双方来说来不及关闭进程,来不及触发FIN数据报,站在对端的角度主机断电可以分为两种情况

  1. 对端正在发送数据,此时突然断电,对端就无法收到ack数据报了,触发超时重传,重传多次之后还是没有收到,此时就会触发tcp的重置连接,对端会发送一个复位报文段给主机,如果还是没有收到确认信息就会断开连接
  2. 对端正在接收数据,此时突然断电,对端一直没有收到数据,站在对端的角度,他也不知道主机是消息发送完毕了还是和主机之间断开连接了,为了避免这种情况的出现,作为接收方的对端会周期性的发送一个不含有业务数据的数据报,如果发送之后主机并没有返回确认信息,就认为连接断开,此时相当于对端单方面的断开连接,这种机制也被称为心跳包机制,发送的不含有业务数据的数据报就是一个心跳包,这个包是接收方周期性进行发送的,如果没有收到确认信息,就认为是没有心跳了,就要断开连接了~

心跳包机制在以后的工作中其实很常见,比如可以通过心跳包机制在分布式系统中判断主机是否正常工作

4.网线断开

以上就是TCP中比较重要的十大机制(TCP不仅仅只有这十个机制,只是这十个比较重要)

这就是网络原理(一)的所有内容,主要讲述了网络模型中的应用层协议和传输层协议,重点是对传输层协议中的TCP的每个机制的理解!


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
3月前
|
网络协议 安全 5G
网络与通信原理
【10月更文挑战第14天】网络与通信原理涉及众多方面的知识,从信号处理到网络协议,从有线通信到无线通信,从差错控制到通信安全等。深入理解这些原理对于设计、构建和维护各种通信系统至关重要。随着技术的不断发展,网络与通信原理也在不断演进和完善,为我们的生活和工作带来了更多的便利和创新。
83 3
|
3天前
|
机器学习/深度学习 算法 PyTorch
深度强化学习中SAC算法:数学原理、网络架构及其PyTorch实现
软演员-评论家算法(Soft Actor-Critic, SAC)是深度强化学习领域的重要进展,基于最大熵框架优化策略,在探索与利用之间实现动态平衡。SAC通过双Q网络设计和自适应温度参数,提升了训练稳定性和样本效率。本文详细解析了SAC的数学原理、网络架构及PyTorch实现,涵盖演员网络的动作采样与对数概率计算、评论家网络的Q值估计及其损失函数,并介绍了完整的SAC智能体实现流程。SAC在连续动作空间中表现出色,具有高样本效率和稳定的训练过程,适合实际应用场景。
21 7
深度强化学习中SAC算法:数学原理、网络架构及其PyTorch实现
|
11天前
|
前端开发 网络协议 安全
【网络原理】——HTTP协议、fiddler抓包
HTTP超文本传输,HTML,fiddler抓包,URL,urlencode,HTTP首行方法,GET方法,POST方法
|
11天前
|
域名解析 网络协议 关系型数据库
【网络原理】——带你认识IP~(长文~实在不知道取啥标题了)
IP协议详解,IP协议管理地址(NAT机制),IP地址分类、组成、特殊IP地址,MAC地址,数据帧格式,DNS域名解析系统
|
11天前
|
存储 JSON 缓存
【网络原理】——HTTP请求头中的属性
HTTP请求头,HOST、Content-Agent、Content-Type、User-Agent、Referer、Cookie。
|
11天前
|
安全 算法 网络协议
【网络原理】——图解HTTPS如何加密(通俗简单易懂)
HTTPS加密过程,明文,密文,密钥,对称加密,非对称加密,公钥和私钥,证书加密
|
11天前
|
XML JSON 网络协议
【网络原理】——拥塞控制,延时/捎带应答,面向字节流,异常情况
拥塞控制,延时应答,捎带应答,面向字节流(粘包问题),异常情况(心跳包)
|
14天前
|
网络协议 安全 网络安全
探索网络模型与协议:从OSI到HTTPs的原理解析
OSI七层网络模型和TCP/IP四层模型是理解和设计计算机网络的框架。OSI模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,而TCP/IP模型则简化为链路层、网络层、传输层和 HTTPS协议基于HTTP并通过TLS/SSL加密数据,确保安全传输。其连接过程涉及TCP三次握手、SSL证书验证、对称密钥交换等步骤,以保障通信的安全性和完整性。数字信封技术使用非对称加密和数字证书确保数据的机密性和身份认证。 浏览器通过Https访问网站的过程包括输入网址、DNS解析、建立TCP连接、发送HTTPS请求、接收响应、验证证书和解析网页内容等步骤,确保用户与服务器之间的安全通信。
62 1
|
11天前
|
网络协议 算法 Java
【JavaEE】——初始网络原理
局域网,广域网,局域网连接方式,交换机,集线器,路由器,网络通信,五元组(源IP,源端口,目的IP,目的端口,协议),协议分层,TCP/IP五层网络协议,封装和分用,交换机和路由器的封装和分用
|
2月前
|
运维 物联网 网络虚拟化
网络功能虚拟化(NFV):定义、原理及应用前景
网络功能虚拟化(NFV):定义、原理及应用前景
120 3

热门文章

最新文章