详解 TCP(三次握手 + 四次挥手 + 滑动窗口 + 拥塞控制 + 和 UDP 做对比)

本文涉及的产品
数据传输服务 DTS,数据同步 small 3个月
推荐场景:
数据库上云
数据传输服务 DTS,数据迁移 small 3个月
推荐场景:
MySQL数据库上云
数据传输服务 DTS,数据同步 1个月
简介: 1. TCP / IP五层模型和OSI七层模型1)OSI七层模型2)TCP/IP 五层模型2. TCP和UDP1) TCP首部结构2)UDP首部结构3)TCP和UDP的区别2.2 UDP和TCP对应的应用场景3. TCP 建立连接时的三次握手1)为什么需要三次握手,而不是两次2)为什么是三次握手,而不是四次握手3)如果第三次握手的 ACK 报文丢失,会发生什么4. TCP 建立连接时的四次挥手1)为什么需要四次挥手2)为什么主动断开方的 TIME_WAIT 状态必须等待 2MSL5. TCP 如何保证可靠性1)检验和2)序列号/确认应答:3)滑动窗口:

1. TCP / IP五层模型和OSI七层模型

1)OSI七层模型

OSI七层网络模型是一个逻辑上的定义和规范:把网络从逻辑上分为7层


52.png

应用层: 为应用程序提供交互服务


表示层: 将数据格式转换成网络标准数据格式


会话层: 管理通信,负责建立和断开通信连接


传输层: 向主机进程提供通用的数据传输服务


网络层: 选择适合的路由和交换节点,确保数据的传送


数据链路层: 将网络层传下来的IP数据包组装成数据帧,在相邻节点之间传送


物理层: 实现相邻节点之间比特流的透明传输


2)TCP/IP 五层模型

在 TCP/IP 五层模型中,每层都呼叫它的下一层所提供的服务来完成自己的需求


53.png


应用层: 为应用程序提供交互服务,如电子邮件传输(SMTP)、文件传输(FTP)


传输层: 向主机进程提供通用的数据传输服务,该层主要有以下两种协议:


TCP:提供面向连接的、可靠的数据传输服务

UDP:提供面向无连接的、尽最大努力的数据传输服务,但不保证数据传输的可靠性

网络层: 选择适合的路由和交换节点,确保数据及时传送。主要包括IP协议


数据链路层: 将网络层传下来的IP数据包组装成数据帧,在相邻节点的链路上传送


物理层: 负责光/电信号的传播,在相邻节点之间比特流的透明传输


2. TCP和UDP

1) TCP首部结构


54.png

2)UDP首部结构55.png

3)TCP和UDP的区别


1683886797393.png

2.2 UDP和TCP对应的应用场景

TCP应用场景: TCP面向连接,能够保证数据的可靠性传输,因此常用于:

  • FTP 文件传输
  • HTTP服务器

UDP应用场景: UDP面向无连接,他可以随时发送数据,传输速度快,因此常用于:

  • 视频、音频等多媒体通信
  • 广播通信

56.png


3. TCP 建立连接时的三次握手

简单流程如下:


第一次握手:客户端向服务端发送 同步报文(SYN),同时选择一个 随机数 x 作为初始序号,随后进入 同步已发送状态(SYN_SENT),等待服务端确认

第二次握手:服务端在收到客户端发来的同步报文之后,服务端向客户端发送 同步确认报文(SYN + ACK),同时选择一个 随机数 y 作为初始序号,确认序号为 x + 1,随后服务端由 收听状态(LISTEN)变为 同步已收到状态(SYN_RECV)

第三次握手:客户端在接收到服务端发来的同步确认报文之后,客户端向服务端发送 同步确认报文(SYN + ACk),序号为 x + 1,确认序号为 y + 1,随后客户端进入 连接已建立状态(ESTABLISHED),服务端在接收到这个同步确认报文之后,也立即进入 连接已建立状态(ESTABLISHED)


57.jpg


1)为什么需要三次握手,而不是两次

三次握手才能让双方都确认自己和双方的接受能力都正常


第一次握手:客户端发送同步报文,服务器接收同步报文,服务器可以确定自己的接收能力正常和对方的发送能力正常


第二次握手:服务端发送同步确认报文,客户端接收同步确认报文,客户端可以确认自己的接收能力正常和发送能力正常,以及对方的接收能力正常和发送能力正常


第三次握手:客户端发送同步确认报文,服务端接收同步确认报文,服务端可以确认自己的发送能力正常,以及对方的接收能力正常


告知对方自己的初始序列号,并且确认收到对方的初始序列号


TCP 实现可靠传输的原因之一就是维护序列号和确认序列号,实现确认应答机制,通过这两个字段可以让双方知道哪些数据已经发出,哪些数据被对方确认对方接收,如果只是两次握手,那么双方只能知道对方的序列号,而不知道确认序列号


2)为什么是三次握手,而不是四次握手

因为三次握手之后就已经可以确认双方的发送和接受能力正常,而且双方也都知道对方的序列号和确认序列号,就不需要第四次了


3)如果第三次握手的 ACK 报文丢失,会发生什么

第三次握手的 ACK 报文丢失,服务端会根据超时重传机制,重新向客户端发送 SYN + ACK 报文,以便客户端重新发送 ACK 报文


如果重发指定次数之后,服务端还未收到客户端的 ACK 报文,那么一段时间之后,服务端就会自动断开这个连接


4. TCP 建立连接时的四次挥手

大致流程如下:


第一次挥手:主动断开方向被动断开方发送 释放报文(FIN),同时 随机选取一个数作为序号,随后主动连接方变为 结束等待1状态(FIN_WAIT_1)

第二次挥手:被动断开方向主动断开方发送 确认报文(ACK),同时随机选取一个数作为序号,并且将主动断开方发来的序号 +1 作为确认序号,随后被动连接方变为 关闭等待状态(CLOSE_WAIT),主动断开方在收到确认报文之后变为 结束等待2状态(FIN_WAIT_2)

第三次挥手:被动断开方向主动断开方发送 释放报文(FIN),同时将上一次发送数据的序号 +1作为本次序号,随后被动断开方变为 最后确认状态(LAST_ACK)

第四次挥手:主动断开方向被动断开方发送 确认报文(ACK),同时将上次发送数据的序号 +1作为本次序号,并且将被动断开方发送来的序号 +1 作为确认序号,随后主动断开方变为 等待时间状态(TIME_WAIT),被动断开方在收到确认报文之后变为 连接关闭状态(CLOSE)。主动连接方在经过 2MSL 时间 之后变为 连接关闭状态(CLOSE)

58.jpg


1)为什么需要四次挥手

被动断开方在收到主动断开方的 FIN 报文之后,可能还会有一些数据需要发送,所以不会立即断开连接,但是会做出应答,返回给主动断开方 ACK 报文


在数据发送完之后,被动断开方会向主动断开方发送 FIN 报文,请求断开连接,主动断开方收到之后返回一个 ACK 报文,连接才会断开。被动断开方的 FIN 报文和 ACK 报文一般分开发送,从而导致多了一次,所以需要四次挥手


2)为什么主动断开方的 TIME_WAIT 状态必须等待 2MSL

主要原因有:


为了确保被动关闭方能够收到最后一次 ACK 报文,正常关闭连接


第四次挥手时,主动关闭方发送的 ACK 报文不一定会到达被关闭方,如果被动关闭方长时间未收到,就会重传 FIN 报文,并等到新的 ACK 报文,所以主动关闭方在 TIME_WAIT 等待 2MSL时间后,就可以保证双方的连接正常关闭


防止上一次 TCP 连接的数据包影响到下一次连接


如果主动断开方不等待 2MSL 时间直接关闭连接,然后又与另一个主机建立连接,并且上一次的被动关闭方未收到 ACK 报文,重传 FIN 报文,那么新的 TCP 连接就会收到一些不希望收到的数据。因此,需要等到 2MSL 时间,确保网络中的报文全部消失再关闭连接


5. TCP 如何保证可靠性

TCP提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现可靠性传输


1)检验和

通过检验和的方式,接收端可以检测出来数据是否出现差错,假如出现差错就会丢弃TCP段,重新发送


2)序列号/确认应答:

TCP传输过程中,接收方每次收到数据后,都会给发送方进行确认应答,即发送ACK报文,这个ACK报文中包括对应的确认序列号、本次接收到哪些信息、下一次数据从哪里发送


序列号不仅仅是应答的作用,有了序列号就能够将接收到的数据根据序列号排序,并且去除相同序列号的数据


3)滑动窗口:

滑动窗口提高了报文传输的效率,避免发送方一次性发送数据过多导致接收方无法正常处理


4)拥塞控制:

数据传输过程中,可能由于网络状态的问题,造成网络拥堵,加入拥塞控制就可以在保证可靠性的同时,提高性能


5)流量控制:

如果主机A一直向主机B发送数据,不考虑主机B的接受能力,则可能导致主机B的接收缓冲区满了而无法接收数据,从而导致丢失大量数据,引发重传机制。而在重传过程中,如果主机B的缓冲区仍未好转,将会浪费大量时间进行重传,降低传输效率。所以引入流量控制机制,主机B通过告诉主机A自己缓冲区的大小,来控制发送的数据量。


6. 滑动窗口

在进行数据传输时,如果传输的数据比较大,就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后,才能发送下一个数据包。这样一来,就会在等待确认应答环节浪费时间。


为了避免这种情况,TCP 引入了窗口的概念。窗口大小指的是不需要确认应答也可以发送的数据的最大值


可以看到滑动窗口起到了一个限流的作用,滑动窗口的大小决定了 TCP 发送数据包的速率,而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口二者间的最小值


59.jpg

7. 拥塞控制

TCP 的拥塞控制是一种在网络发生拥塞时,发送方会维持一个叫做拥塞窗口的变量来适当减少数据发送速率的机制,以避免数据丢失和网络拥塞恶化


TCP 一共使用了四种算法来实现拥塞控制:


慢开始

拥塞避免

快速重传

快速恢复

1)慢开始

TCP 在建立连接之后,初始的拥塞窗口大小为1,在经过几个传输轮次之后,拥塞窗口开始呈指数增长,直到达到慢开始阈值或者丢包


2)拥塞避免

当拥塞窗口大小达到慢开始阈值或者发生丢包了,就进入拥塞避免阶段,此时没经过一个传输轮次,拥塞窗口大小就加1,呈线性增长,直到再次发生丢包


在慢开始和拥塞避免阶段,主要出现网络阻塞,就将慢开始阈值变为当前拥塞窗口的一半,再将拥塞窗口大小设置为1


4)快重传

当发送方连续收到三个对同一个报文的确认,就认为该报文段的下一个报文段已经丢失,立即重传


5)快恢复

发送方执行快重传之后,将慢开始阈值设置为当前拥塞窗口大小的一半,然后将拥塞窗口大小设置为慢开始阈值加3(由于收到三个重复确认而增加的),随后进入拥塞避免阶段

60.png


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
9天前
|
存储 网络协议 安全
用于 syslog 收集的协议:TCP、UDP、RELP
系统日志是从Linux/Unix设备及网络设备生成的日志,可通过syslog服务器集中管理。日志传输支持UDP、TCP和RELP协议。UDP无连接且不可靠,不推荐使用;TCP可靠,常用于rsyslog和syslog-ng;RELP提供可靠传输和反向确认。集中管理日志有助于故障排除和安全审计,EventLog Analyzer等工具可自动收集、解析和分析日志。
|
25天前
|
网络协议 网络性能优化 数据处理
深入解析:TCP与UDP的核心技术差异
在网络通信的世界里,TCP(传输控制协议)和UDP(用户数据报协议)是两种核心的传输层协议,它们在确保数据传输的可靠性、效率和实时性方面扮演着不同的角色。本文将深入探讨这两种协议的技术差异,并探讨它们在不同应用场景下的适用性。
65 4
|
25天前
|
监控 网络协议 网络性能优化
网络通信的核心选择:TCP与UDP协议深度解析
在网络通信领域,TCP(传输控制协议)和UDP(用户数据报协议)是两种基础且截然不同的传输层协议。它们各自的特点和适用场景对于网络工程师和开发者来说至关重要。本文将深入探讨TCP和UDP的核心区别,并分析它们在实际应用中的选择依据。
53 3
|
1月前
|
网络协议 算法 网络性能优化
|
1月前
|
网络协议 SEO
TCP连接管理与UDP协议IP协议与ethernet协议
TCP、UDP、IP和Ethernet协议是网络通信的基石,各自负责不同的功能和层次。TCP通过三次握手和四次挥手实现可靠的连接管理,适用于需要数据完整性的场景;UDP提供不可靠的传输服务,适用于低延迟要求的实时通信;IP协议负责数据包的寻址和路由,是网络层的重要协议;Ethernet协议定义了局域网的数据帧传输方式,广泛应用于局域网设备之间的通信。理解这些协议的工作原理和应用场景,有助于设计和维护高效可靠的网络系统。
40 4
|
1月前
|
缓存 负载均衡 网络协议
面试:TCP、UDP如何解决丢包问题
TCP、UDP如何解决丢包问题。TCP:基于数据块传输/数据分片、对失序数据包重新排序以及去重、流量控制(滑动窗口)、拥塞控制、自主重传ARQ;UDP:程序执行后马上开始监听、控制报文大小、每个分割块的长度小于MTU
|
2月前
|
网络协议 前端开发 物联网
TCP和UDP区别?
本文首发于微信公众号“前端徐徐”,详细介绍了TCP和UDP两种传输层协议的核心概念、连接性和握手过程、数据传输和可靠性、延迟和效率、应用场景及头部开销。TCP面向连接、可靠、有序,适用于网页浏览、文件传输等;UDP无连接、低延迟、高效,适用于实时音视频传输、在线游戏等。
72 1
TCP和UDP区别?
|
2月前
|
Web App开发 缓存 网络协议
不为人知的网络编程(十八):UDP比TCP高效?还真不一定!
熟悉网络编程的(尤其搞实时音视频聊天技术的)同学们都有个约定俗成的主观论调,一提起UDP和TCP,马上想到的是UDP没有TCP可靠,但UDP肯定比TCP高效。说到UDP比TCP高效,理由是什么呢?事实真是这样吗?跟着本文咱们一探究竟!
69 10
|
2月前
|
网络协议 网络性能优化 C#
C# 一分钟浅谈:UDP 与 TCP 协议区别
【10月更文挑战第8天】在网络编程中,传输层协议的选择对应用程序的性能和可靠性至关重要。本文介绍了 TCP 和 UDP 两种常用协议的基础概念、区别及应用场景,并通过 C# 代码示例详细说明了如何处理常见的问题和易错点。TCP 适用于需要可靠传输和顺序保证的场景,而 UDP 适用于对延迟敏感且可以容忍一定数据丢失的实时应用。
52 1
|
2月前
|
网络协议 Linux 网络性能优化
Linux C/C++之TCP / UDP通信
这篇文章详细介绍了Linux下C/C++语言实现TCP和UDP通信的方法,包括网络基础、通信模型、编程示例以及TCP和UDP的优缺点比较。
49 0
Linux C/C++之TCP / UDP通信