网络原理(3):三次握手 四次挥手 滑动窗口与丢包

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 网络原理(3):三次握手 四次挥手 滑动窗口与丢包

一:TCP

1:连接层管理

   1:三次握手

1:意义

    ①: 三次握手,也是一种保证可靠性的机制."投石问路".TCP三次握手,就是要验证网络通信是否畅通,以及验证每个主机的发送和接收能力是否正常.恰好三次握手,就能验证双方的发送和接收能力是否正常.

      为了帮助大家更好的理解,举个栗子:

      在这个栗子中:麦克风:发送能力.耳机:接收能力====>通过三次握手,是进行可靠传输的前提条件.


2:三次握手的作用

  三次握手,还能起到,"消息协商"这样的效果.

  通信的时候会涉及到一些参数,需要双方保持一致.通过协商,来确定具体的参数是多少!!!

 举个栗子:

 你和你女朋友结婚的时候,办酒席,摆多少桌?

 一场结婚酒席,包含两类人:婆家 娘家

2:断开连接

1:四次挥手

四次挥手示意图:

将由服务器发出的ACK和FIN合并成一项可以吗?或者将四次挥手可以改成三次可以吗?

四次挥手有的时候可以改成三次,有的时候不能改.

原因:

FIN的触发,是由应用程序代码控制的===>调用socket.close()来进行触发的,

如果close触发的慢,那么无法和内核控制的ack进行合并.那么,此时就是四次挥手

如果close触发的快,那么就可以和内核控制的ack进行合并.那么,此时就是三次挥手

即;两个步骤能否合并取决于close的执行快慢.

2:两个问题

a:如果服务器,始终不进行close,会怎么样?客户端的连接就始终不关闭吗?

  客户端给服务器发送过去了FIN(在内核中完成),此时服务器收到了,在内核中触发了ack,ack为1,此时,服务器始终不进行close,会怎么样?客户端的连接始终不关闭吗?

原因:

情况1:

客户端给服务器发送FIN,服务器端的内核会立即向客户端发送ACK(在内核中完成),服务器端没有进行close操作,那么服务器端就会进入close_wait状态,当发送成功后,便会进入last_ack状态.

站在服务器的角度来看,此时,客户端已经删除了服务器端的信息,即使服务器不进行close操作,这个连接也不能使用了.

针对服务器端的socket进行读操作:

a:如果还没有读完(即缓冲区里面还有数据),可以正常读

b:如果已经读完了,由于TCP协议是面向字节流的,此时,(EOP为-1,hasNext为false)

针对服务器端的socket进行写操作:

无法进行写操作,此时便会直接报出异常.(客户端没有服务器端的连接,此时服务器端的socket进行写操作,将其当做响应传递给客户端,但没有办法找到响应的客户端,此时,便会抛出异常)

综上所述,此时这个连接就是废人一个.


情况2:

更极端的情况,close忘记写了,此时,客户端一直等待服务器的close,却一直没有等到,客户端便会单方面删除服务器端的连接)


b:如果通信过程中,出现丢包了,又怎样处理?


原因:

     第一组的FIN/ACK丢失了,可以让其客户端进行重传

     第二组的FIN/ACK丢失了:

     如果第二组的ACK丢失了,让B进行重传FIN即可,但是当第二组的ack,即A向B发送ACK时,ack丢失了,此时B没有收到A的ack消息,B就会重新将FIN传递给A,(在此过程中,由于A将自己和B的连接给删除了),导致B的FIN传不到A里面去,那么,B就永远也收不到A的ack了

    为了解决这一问题,A在发送出去最后一个ACK时,便会等一会(A的等待时间,网络上任意两点之间传输时间的最大时间*2),万一B没有收到,此时就可以等B再重新发送FIN ,直到B接收到由A发送的应答报文(ack).这样,A就可以释放连接了.

MSL:存活时间,理论啊上拍脑门拍出来的时间,这个时间是s/ms


3:TCP是如何可靠传输的?

1:确认应答=====>可靠性传输的核心

2:超时重传

3:连接管理(三次握手,四次挥手)


4:滑动窗口

提高传输效率(更正确的说,是让TCP在可靠传输的前提下,效率不要太拉胯)

使用滑动窗口,不能使TCP变的比UDP快,只能说缩小两个的速度差距

无滑动窗口:将大量的时间用在等待ack上

有滑动窗口:"一次等待时间"等三个ack.

注意:

1:窗口越大,批量发送的数据也就越大,运行效率更高

2:窗口也不能无限大,相当于批量发送的数据无限多,此时,便会接近udp协议,所以窗口不能无限大另一方面,如果窗口无限大,接收方能不能处理过来,中间的设备能不能承受的住!!!都是未知数.

滑动窗口图例:

如上图:主机A给主机B发送数据,1001-5000的数据

数据如下:

1001-2000 2001-3000 3001-4000 4001-5000

当B接收到A的数据后,B就会给A返回上述四组数据所对应的ACK.

当A收到2001的ack之后,A就会向B传输5001-6000这个数据,

A向B发送的数据就会变成如下的样子:

2001-3000 3001-4000 4001-5000 5001-6000

我们会发现,当一个ack传完之后,会将已经传完的ack进行过滤掉,往后再移动一个格子.类似于滑动一样.

滑动窗口批量传输数据时,发送丢包,该怎么办?

情况1:数据包丢了

一旦丢失的数据报被补上了,此时,1001-2000后面的数据都不必重新传输了(都在缓冲区待着呢)====>此时,就完成了重传的过程.这个过程,只是把丢失的数据进行重传了===>快速重传(超时重传+滑动窗口)

情况2:ack丢了

如上图所示:ack丢了,不用做任何处理!!!

原因:

     1001的ack丢了,但2001的ack传递过去了,在前面我们学习的过程中.2001代表2001之前的数据都被传递过去了即包含(1-2000)的数据,换句话说,包含1001的ack.

5:流量机制

流量控制:实际上为了给滑动窗口的窗口大小做限制(如果滑动窗口窗口过大,会导致接收方接收不过来,中间链路处理不过来)

以上图为例:

 主机A 给主机B的内核态发送数据,内核将发送的数据存储在接收缓冲区.

 假设:A生产速度很快,B这边的消费速度跟不上,那么,就会导致接收缓冲区的数据越来越多,      最终就满了,此时,剩余的传过来的数据便会被丢包

流量控制怎样解决?

流量控制会根据接收方的内核中的接收缓冲区剩余大小作为主机A给主机B传输数据的速度大小的依据,当接收缓冲区剩余的空间越大,那么,应用程序消费的数据也就越大.同时主机B便会将剩余缓冲区的空间当做ack发送给主机A,作为发送方下一次的数据,窗口大小.

如上图所示:流量控制可以控制滑动的大小.

假设滑动窗口默认是4000,刚开始主机A已经给主机B发送了1000大小的数据,相当于剩下3000的接收缓冲区.那么,此时主机A连续主机B发了3000大小的数据,此时,主机B还没有来得急处理从主机A的3000大小的数据,但此时主机B的接收缓冲区大小已经满了.相当于剩余缓冲区为0.

主机B就不会接收从主机A传来的消息,即主机A先暂停发送(ack=0).主机A便会发送一个"窗口探测包",只是为了触发ack(查询当前缓冲区的情况,一旦发现ack=1)时,便可以继续发送.

接收方就可以根据窗口大小,来反向限制发送方传输速度了.

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
16天前
|
网络协议 安全 5G
网络与通信原理
【10月更文挑战第14天】网络与通信原理涉及众多方面的知识,从信号处理到网络协议,从有线通信到无线通信,从差错控制到通信安全等。深入理解这些原理对于设计、构建和维护各种通信系统至关重要。随着技术的不断发展,网络与通信原理也在不断演进和完善,为我们的生活和工作带来了更多的便利和创新。
57 3
|
2月前
|
并行计算 安全 网络协议
探索未来网络:量子互联网的原理与应用
本文深入探讨了量子互联网的基本概念、技术原理及其潜在应用。通过对量子纠缠、量子叠加和量子隐形传态等核心概念的解释,文章展示了量子互联网如何利用量子力学特性来实现超高速、超高安全性的通信。此外,还讨论了量子互联网在金融、医疗、国防等领域的应用前景,以及当前面临的技术挑战和未来的发展方向。
69 2
|
2月前
|
缓存 算法 物联网
基于AODV和leach协议的自组网络平台matlab仿真,对比吞吐量,负荷,丢包率,剩余节点个数,节点消耗能量
本系统基于MATLAB 2017b,对AODV与LEACH自组网进行了升级仿真,新增运动节点路由测试,修正丢包率统计。AODV是一种按需路由协议,结合DSDV和DSR,支持动态路由。程序包含参数设置、消息收发等功能模块,通过GUI界面配置节点数量、仿真时间和路由协议等参数,并计算网络性能指标。 该代码实现了节点能量管理、簇头选举、路由发现等功能,并统计了网络性能指标。
162 73
|
10天前
|
网络协议 安全 算法
网络空间安全之一个WH的超前沿全栈技术深入学习之路(9):WireShark 简介和抓包原理及实战过程一条龙全线分析——就怕你学成黑客啦!
实战:WireShark 抓包及快速定位数据包技巧、使用 WireShark 对常用协议抓包并分析原理 、WireShark 抓包解决服务器被黑上不了网等具体操作详解步骤;精典图示举例说明、注意点及常见报错问题所对应的解决方法IKUN和I原们你这要是学不会我直接退出江湖;好吧!!!
网络空间安全之一个WH的超前沿全栈技术深入学习之路(9):WireShark 简介和抓包原理及实战过程一条龙全线分析——就怕你学成黑客啦!
|
21天前
|
机器学习/深度学习 人工智能 监控
深入理解深度学习中的卷积神经网络(CNN):从原理到实践
【10月更文挑战第14天】深入理解深度学习中的卷积神经网络(CNN):从原理到实践
62 1
|
23天前
|
网络协议 Linux 应用服务中间件
Socket通信之网络协议基本原理
【10月更文挑战第10天】网络协议定义了机器间通信的标准格式,确保信息准确无损地传输。主要分为两种模型:OSI七层模型与TCP/IP模型。
|
2月前
|
存储 弹性计算 测试技术
阿里云服务器实例规格vCPU、内存、网络带宽、网络收发包PPS、连接数等性能指标详解
阿里云服务器ECS实例可以分为多种实例规格族。根据CPU、内存等配置,一种实例规格族又分为多种实例规格。而实例规格又包含vCPU、处理器、内存、vTPM、本地存储、网络带宽、网络收发包PPS、连接数、弹性网卡、云盘带宽、云盘IOPS等指标,本文为大家详细介绍实例规格的这些指标,以供大家了解和选择。
124 14
阿里云服务器实例规格vCPU、内存、网络带宽、网络收发包PPS、连接数等性能指标详解
|
1月前
|
存储 安全 算法
网络安全与信息安全:构建数字世界的防线在数字化浪潮席卷全球的今天,网络安全与信息安全已成为维系现代社会正常运转的关键支柱。本文旨在深入探讨网络安全漏洞的成因与影响,剖析加密技术的原理与应用,并强调提升公众安全意识的重要性。通过这些综合性的知识分享,我们期望为读者提供一个全面而深刻的网络安全视角,助力个人与企业在数字时代中稳健前行。
本文聚焦网络安全与信息安全领域,详细阐述了网络安全漏洞的潜在威胁、加密技术的强大防护作用以及安全意识培养的紧迫性。通过对真实案例的分析,文章揭示了网络攻击的多样性和复杂性,强调了构建全方位、多层次防御体系的必要性。同时,结合当前技术发展趋势,展望了未来网络安全领域的新挑战与新机遇,呼吁社会各界共同努力,共筑数字世界的安全防线。
|
1月前
|
存储 安全 自动驾驶
探索未来网络:量子互联网的原理与应用
【10月更文挑战第2天】 本文旨在探讨量子互联网的基本原理、技术实现及其在通讯领域的革命性应用前景。量子互联网利用量子力学原理,如量子叠加和量子纠缠,来传输信息,有望大幅提升通信的安全性和速度。通过详细阐述量子密钥分发(QKD)、量子纠缠交换和量子中继等关键技术,本文揭示了量子互联网对未来信息社会的潜在影响。
|
10天前
|
网络协议 安全 算法
网络空间安全之一个WH的超前沿全栈技术深入学习之路(9-2):WireShark 简介和抓包原理及实战过程一条龙全线分析——就怕你学成黑客啦!
实战:WireShark 抓包及快速定位数据包技巧、使用 WireShark 对常用协议抓包并分析原理 、WireShark 抓包解决服务器被黑上不了网等具体操作详解步骤;精典图示举例说明、注意点及常见报错问题所对应的解决方法IKUN和I原们你这要是学不会我直接退出江湖;好吧!!!

热门文章

最新文章