文章目录
- 1.运输层协议概述
- 2.用户数据报协议UDP
- 3.传输控制协议TCP概述
- 4.可靠传输的工作原理
-
- 4.2停止等待协议
-
- [1. 无差错情况](#1. 无差错情况)
- [2. 出现差错](#2. 出现差错)
- [3. 确认丢失和迟到](#3. 确认丢失和迟到)
- [4. 信道利用率](#4. 信道利用率)
- 4.3连续ARQ协议
- 5.TCP报文段的首部格式
- [6.TCP 可靠传输的实现------以字节为单位的滑动窗口](#6.TCP 可靠传输的实现——以字节为单位的滑动窗口)
- 7.TCP的流量控制------利用滑动窗口实现流量控制
- 8.TCP的拥塞控制
- 9.TCP运输连接管理
本章先概括介绍运输层协议的特点、进程之间的通信和端口等重要概念,然后讲述比较简单的 UDP协议。其余的篇幅都是讨论较为复杂但非常重要的 TCP协议"和可靠传输的工作原理,包括停止等待协议和ARQ协议。在详细讲述TCP报文段的首部格式之后,讨论TCP的三个重要问题:滑动窗口、流量控制和拥塞控制机制。最后,介绍TCP的连接管理。运输层是整个网络体系结构中的关键层次之一。一定要弄清以下一些重要概念:
- 运输层为相互通信的应用进程提供逻辑通信。
- 端口和套接字的意义。
- 无连接的 UDP 的特点
- 面向连接的 TCP 的特点。
- 在不可靠的网络上实现可靠传输的工作原理,停止等待协议和ARQ协议。
- TCP的滑动窗口、流量控制、拥塞控制和连接管理。
1.运输层协议概述
1.1进程之间的通信
通信主体:应用进程
从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务 ,它属于面向通信部分的最高层,同时也是用户功能中的最低层。
运输层通信主体与前面三层的区别:
网络层:定位主机的IP地址(主机之间),路由。
运输层:定位到进程,端口号区分进程。
1.2运输层的两个主要协议
TCP/IP 运输层的两个主要协议都是互联网的正式标准,即:
- 用户数据报协议 UDP
- 传输控制协议 TCP
以下是UDP协议与TCP协议的区别:
特性 | UDP协议 (用户数据报协议) | TCP协议 (传输控制协议) |
---|---|---|
连接性 | 无连接 | 有连接 |
可靠性 | 不可靠 | 可靠 |
传输方式 | 无确认机制,数据可能丢失或重复 | 提供数据确认,保证数据完整传输 |
速度 | 较快 (没有流量控制和错误检测) | 较慢 (有流量控制和重传机制) |
数据顺序 | 不保证顺序 | 保证数据顺序 |
适用场景 | 实时性要求高的应用,如视频流、DNS等 | 需要高可靠性的应用,如网页浏览、文件传输 |
头部开销 | 较小 (8字节) | 较大 (20字节) |
错误检测 | 有简单的校验和,但不保证纠错 | 提供错误检测和纠错机制 |
1.3运输层的端口
在运输层,端口用于标识和区分同一台计算机上的不同应用进程。不同的应用程序通过不同的端口来通信,以确保数据能够正确地发送到相应的进程。端口通常由16位数字表示,范围从0到65535。
1.3.1端口分类
类别 | 端口范围 | 说明 |
---|---|---|
知名端口 | 0 - 1023 | 这些端口用于常见的系统服务或协议,如HTTP(80端口)、FTP(21端口)、SMTP(25端口)。 |
注册端口 | 1024 - 49151 | 由软件开发者注册,供应用程序使用的端口。例如,MySQL通常使用3306端口。 |
动态/私有端口 | 49152 - 65535 | 临时分配给客户端应用程序使用的端口,通常由操作系统动态分配。 |
1.3.2端口和协议的关系
运输层协议(如TCP和UDP)通过端口来标识特定的服务或应用。常见协议与端口的关系如下:
协议 | 端口号 | 服务名称/描述 |
---|---|---|
TCP | 80 | HTTP (HyperText Transfer Protocol) |
TCP | 443 | HTTPS (HTTP Secure) |
UDP | 53 | DNS (Domain Name System) |
TCP | 25 | SMTP (Simple Mail Transfer Protocol) |
TCP | 21 | FTP (File Transfer Protocol) |
1.3.3端口在通信中的作用
- 源端口:发送方端口,用于标识发送方的应用进程。
- 目标端口:接收方端口,用于标识接收方的应用进程。
当一个主机(客户端)向另一个主机(服务器)发起请求时,通信会通过指定的端口来传递数据,从而确保数据能够正确地传递到相应的应用程序。
2.用户数据报协议UDP
2.1UDP的概述
用户数据报协议 UDP只在IP的数据报服务之上增加了很少一点的功能,这就是复用和分用的功能以及差错检测的功能。UDP的主要特点是:
特点 | 描述 |
---|---|
UDP是无连接的 | 发送数据之前不需要建立连接(当然,发送数据结束时也没有 连接可释放),因此减少了开销和发送数据之前的时延。 |
UDP使用尽最大努力交付 | 即不保证可靠交付,因此主机不需要维持复杂的连接状态表(这里面有许多参数)。 |
UDP是面向报文的 | 发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。 |
UDP没有拥塞控制 | 因此网络出现的拥塞不会使源主机的发送速率降低 |
UDP 支持一对一、一对多、多对一和多对多的交互通信。 | |
UDP的首部开销小 | 只有8个字节,比TCP的20个字节的首部要短 |
2.2UDP首部格式
UDP(用户数据报协议)的首部格式相对简单,由四个字段组成,总长度为8字节。下面是UDP首部的格式以及每个字段的说明:
字段 | 长度 | 描述 |
---|---|---|
源端口 | 2字节 | 发送方的端口号。 |
目标端口 | 2字节 | 接收方的端口号。 |
长度 | 2字节 | UDP数据报的总长度,包括头部和数据部分的长度。 |
校验和 | 2字节 | 用于检测数据在传输过程中是否发生错误。 |
2.2.1字段详细说明:
- 源端口(Source Port) :
- 2字节(16位)。
- 发送方的端口号,表示数据从哪个应用程序发送。
- 如果没有指定源端口,通常该字段会设置为0。
- 目标端口(Destination Port) :
- 2字节(16位)。
- 接收方的端口号,表示数据发送到哪个应用程序。
- 长度(Length) :
- 2字节(16位)。
- UDP数据报的总长度,即UDP头部和数据部分的长度之和。
- 由于UDP头部固定为8字节,因此该字段值至少为8。
- 校验和(Checksum) :
- 2字节(16位)。
- 用于检验数据在传输过程中是否发生错误。这个字段是可选的,但在IPv6中是必需的。
- 校验和计算包括UDP头部和数据部分,并且在传输中对其进行校验。
2.2.2校验和的计算:
UDP的校验和采用的是一个简单的"伪头部"(pseudo-header)来增加错误检查的可靠性。伪头部包含了IP头的一部分(如源IP地址、目标IP地址等)以及UDP数据部分的一些信息。通过计算整个伪头部、UDP头部和数据部分的校验和,能够检测到数据在传输过程中可能发生的错误。
UDP校验和是用来检测数据在传输过程中是否发生错误的机制。其计算方法包括以下步骤:
-
构建伪头部:伪头部包含源IP、目标IP、协议类型(UDP)和UDP数据长度等信息,帮助检测网络层错误。
-
合并数据:将伪头部与UDP头部和数据结合起来,形成一个数据块。
-
二进制反码求和:将数据块按16位为单位相加,如果有进位则加到低位,直到没有进位为止。
-
反码取反:对求和结果取反,得到最终的校验和。
接收方也用相同的方式计算校验和,如果结果为0,表示数据完整。
3.传输控制协议TCP概述
3.1TCP最主要的特点
特点 | 描述 |
---|---|
TCP是面向连接的运输层协议 | 这就是说,应用程序在使用TCP协议之前,必须先建立 TCP连接。在传送数据完毕后,必须释放已经建立的TCP连接。 |
每一条TCP连接只能有两个端点(endpoint),每一条 TCP 连接只能是点对点的(一对一)。 | |
TCP提供可靠交付的服务。 | 通过TCP 连接传送的数据,无差错、不丢失、不重复,并且按序到达 |
TCP提供全双工通信。 | TCP允许通信双方的应用进程在任何时候都能发送数据,TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据。 |
面向字节流。 | TCP中的"流"(stream)指的是流入到进程或从进程流出的字节序列 |
3.2TCP的连接
3.2.1TCP连接及其端点
TCP把连接作为最基本的抽象,许多TCP特性都与这一面向连接的基本特性有关。因此,我们需要对TCP连接有更清楚的了解。
每一条TCP连接有两个端点。TCP连接的端点不是主机本身、主机的IP地址、应用进程,或者是运输层的协议端口,而是套接字 (socket)或插口(endpoint)。
根据 RFC 793 的定义,端口号拼接到 IP 地址后,构成了套接字。因此,套接字的表示方法是:
- 在点分十进制的IP地址后面加上端口号,中间用冒号(:)或逗号隔开。
例如:
- 若IP地址是
192.3.4.5
,端口号是80
,则得到的套接字就是(192.3.4.5:80)
。
3.2.2套接字的定义
总之,套接字 (socket) 的形式为:
socket = (IP 地址:端口号)
每一条TCP连接唯一地由通信两端的两个端点(即套接字对)所确定:
TCP连接 = {socket1, socket2} = {(IP1:port1), (IP2:port2)}
3.2.3关键概念总结
- TCP连接:由两个套接字(socket)组成,每个套接字是由IP地址和端口号唯一标识的。
- 套接字:是一个抽象的概念,代表了TCP连接的端点。
- 同一个IP地址:可以有多个不同的TCP连接。
- 同一个端口号:也可以出现在多个不同的TCP连接中。
4.可靠传输的工作原理
我们知道,TCP 发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务,也就是说,TCP下面的网络所提供的是不可靠的传输。因此,TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。理想的传输条件有以下两个特点:
(1)传输信道不产生差错。
(2)不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据。
4.2停止等待协议
止等待协议(Stop-and-Wait Protocol) 是一种在数据通信中使用的可靠传输协议,它确保数据从发送方到接收方的可靠传输。它是最简单的一种可靠传输协议,主要用于点对点通信中,通常用于低速网络中。
1. 无差错情况
在无差错情况下,停止等待协议的工作过程非常简单,可以保证数据的可靠传输。假设信道中没有任何干扰或丢包,数据和确认帧都能按时、正确到达对方。
过程:
一个确认帧(ACK)。
- 发送方收到确认帧(ACK)后,认为数据已经成功传输,然后继续发送下一个数据帧。
无差错时的工作流程:
- 数据帧1 → ACK1 → 数据帧2 → ACK2 → ... → 数据帧n → ACKn。
在这种情况下,协议的操作非常高效,发送方始终在等待接收方的确认并继续发送下一帧数据,数据传输没有任何问题。
2. 出现差错
在出现差错的情况下,数据帧或确认帧可能会受到干扰,导致接收方无法正确解码或接收数据,这时候会影响数据的可靠传输。
过程:
- 发送方将数据帧发送到接收方。
- 由于信道问题,接收方可能收到损坏的数据帧,无法正确解码。
- 由于数据帧错误,接收方不会发送正确的确认帧。
- 发送方会因为超时没有收到确认帧而重新发送该数据帧。
出现差错时的工作流程:
- 数据帧1 → (错误) → 接收方不发送ACK1 → 发送方超时重发数据帧1。
- 重发的数据帧1 → ACK1 → 数据帧2 → ACK2 → ...。
在这种情况下,发送方会重新发送丢失或损坏的数据帧,直到接收到正确的确认帧(ACK)。这会导致协议效率的降低,因为需要重发错误的帧。
3. 确认丢失和迟到
在某些情况下,接收方可能正确接收到数据帧,但确认帧(ACK)可能丢失或迟到。确认丢失通常是因为网络中出现拥塞或其他原因,导致确认帧没有被发送回发送方。
过程:
- 发送方发送数据帧1。
- 接收方正确接收到数据帧1并发送确认帧(ACK1)。
- 由于网络问题,ACK1可能丢失或迟到,发送方在规定时间内未收到确认帧。
- 发送方超时后重新发送数据帧1。
确认丢失和迟到时的工作流程:
- 数据帧1 → ACK丢失或迟到 → 发送方超时重发数据帧1 → ACK1 → 数据帧2 → ACK2 → ...。
这种情况下,由于确认丢失或迟到,发送方会误以为数据丢失或未正确接收,从而导致数据帧的重复发送。这会增加网络负担和协议的延迟,导致效率降低。
4. 信道利用率
信道利用率是指在整个传输过程中,信道中实际用于传输数据的时间占总时间的比例。在停止等待协议中,信道利用率较低,尤其是在高延迟的网络环境中。
信道利用率计算:
信道利用率 = 有效数据传输时间 / 总时间
在停止等待协议中,每发送一帧数据后,发送方必须等待确认帧。由于确认的往返时间(RTT)可能很长,空闲时间(发送方等待ACK的时间)占用了大量的总时间。
假设:
- 数据帧的传输时间为 TdataTdata。
- 确认帧的往返时间为 TRTTTRTT。
那么,在停止等待协议中,发送方在发送一个数据帧后,必须等待一个完整的往返时间(TRTTTRTT)才能发送下一个数据帧。信道的有效利用就变成了:
信道利用率=TdataTdata+TRTT信道利用率=Tdata+TRTTTdata
可以看出,随着RTT的增加,信道利用率会显著降低。若网络延迟较高(RTT大),发送方将有较长的空闲时间,导致信道的利用率下降。
为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据在不间断地传送。显然,这种传输方式可以获得很高的信道利用率。
4.3连续ARQ协议
连续的ARQ协议(Continuous Automatic Repeat reQuest, ARQ)是一种用于数据传输中的错误控制协议,它主要用于可靠数据传输系统中,确保数据在不可靠的信道中能够正确地传输。ARQ协议通过自动重复请求(ARQ)机制来检测和纠正传输中的错误。
连续ARQ的基本概念
在连续ARQ协议中,发送方会连续不断地发送数据帧,而接收方则根据收到的帧来决定是否进行错误检测和确认。这与停等ARQ(Stop-and-Wait ARQ)协议不同,后者要求发送方每发送一帧后都必须等待接收方的确认,才会发送下一帧。
具体而言,连续ARQ协议允许发送方在接收方确认上一帧数据是否成功之前,继续发送下一帧数据。这样做的好处是提高了传输效率,避免了等待确认的延时。
连续ARQ协议的工作原理
-
数据帧的连续发送:发送方在没有等待确认的情况下,继续发送多个数据帧。每个数据帧都有一个唯一的序列号。
-
接收方的确认 :接收方在收到数据帧后,会检查其完整性和是否有错误。如果没有错误,接收方会发送一个累计确认(Cumulative Acknowledgment),确认到达的最高序列号的帧;如果帧有错误,接收方不会确认该帧,并要求发送方重新发送该帧。
-
错误检测与重传 :如果某个数据帧在传输过程中发生了错误(例如丢失、损坏或被篡改),接收方会请求发送方重新发送该帧。发送方会根据接收方的反馈重新传输丢失或损坏的帧。
5.TCP报文段的首部格式
字段名称 | 占用字节 | 描述 |
---|---|---|
源端口 | 2 | 源端口号 |
目的端口 | 2 | 目的端口号 |
序号 | 4 | 数据字节的序号,mod 2^32 |
确认号 | 4 | 期望收到的下一个字节的序号 |
数据偏移 | 4位 | TCP报文段的首部长度 |
保留 | 6位 | 保留位,目前应置为0 |
控制位 | 6位 | 包括URG、ACK、PSH、RST、SYN、FIN |
窗口 | 2 | 接收窗口大小 |
检验和 | 2 | 首部和数据的检验和 |
紧急指针 | 2 | 紧急数据的字节数,仅在URG=1时有意义 |
选项 | 长度可变 | 最长可达40字节,用于TCP选项 |
填充 | 可变 | 使首部长度为4字节的整数倍 |
6.TCP 可靠传输的实现------以字节为单位的滑动窗口
-
滑动窗口概念:TCP使用滑动窗口机制来控制数据传输的流量。滑动窗口以字节为单位,允许发送方在没有收到确认的情况下发送多个数据包。
-
窗口大小:窗口大小由接收方的接收窗口决定,发送方的发送窗口不能超过这个值。窗口大小的单位是字节。
-
发送窗口:发送窗口表示发送方可以发送但尚未确认的数据量。发送窗口由三个指针(P1, P2, P3)定义:
- P1之前的数据已发送并确认。
- P3之后的数据不允许发送。
- P3-P1是发送窗口的大小。
- P2-P1是已发送但未确认的数据量。
- P3-P2是允许发送但尚未发送的数据量。
-
接收窗口:接收窗口表示接收方准备好接收的数据量。接收方通过确认报文段告知发送方其接收窗口的大小。
-
确认号:接收方通过确认号告知发送方它期望接收的下一个字节序号。发送方根据这个信息来调整其发送窗口。
-
数据传输:发送方在发送窗口内的数据发送后,必须暂时保留这些数据,直到收到确认。如果数据未被确认,发送方可能需要在超时后重传这些数据。
-
窗口调整:当发送方收到接收方的确认后,它会根据确认号来调整发送窗口。如果确认号表明接收方已经成功接收了数据,发送窗口的后沿(P1)会前移。
-
缓存和窗口的关系:发送方和接收方都使用缓存来暂时存放数据。发送缓存用于存放准备发送和已发送但未确认的数据。接收缓存用于存放按序到达和未按序到达的数据。
-
全双工通信:TCP支持全双工通信,即通信的双方可以同时发送和接收数据。每一方都有自己的发送窗口和接收窗口。
-
累积确认:TCP要求接收方具有累积确认的功能,以减少传输开销。接收方可以在有数据要发送时顺便发送确认,但不应过分推迟发送确认。
7.TCP的流量控制------利用滑动窗口实现流量控制
一般说来,我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快,接收方就可能来不及接收,这就会造成数据的丢失。流量控制(fow control) 就是让发送方的发送速率不要太快
既要让接收方来得及接收,也不要使网络发生拥塞。
-
初始状态:A向B发送数据,B告诉A它的接收窗口(rwnd)是400字节。这意味着A可以发送最多400字节的数据,而不需要等待B的确认。
-
发送数据:A开始发送数据,每100字节为一个报文段。A首先发送了序号1至100的数据,然后是101至200的数据。此时,A还能发送200字节。
-
数据丢失:A发送了201至300的数据,但这个报文段丢失了。
-
窗口更新:B发送了一个ACK,确认了序号1的数据,并告知A它的接收窗口是300字节。这意味着A可以继续发送数据,直到序号500。
-
继续发送:A继续发送301至400的数据,然后是401至500的数据。此时,A不能再发送新数据,因为它已经达到了B允许的接收窗口大小。
-
超时重传:由于201至300的数据丢失,A在超时后重新发送了这部分数据。
-
窗口进一步缩小:B再次更新窗口,这次是100字节,允许A发送501至600的数据。
-
窗口关闭:最后,B发送了一个窗口大小为0的ACK,告诉A它不能再发送任何数据,直到B再次更新窗口大小。
-
死锁情况:如果B的接收缓存满了,它会发送一个窗口大小为0的报文段。如果这个报文段丢失,A和B都会等待对方的动作,导致死锁。为了解决这个问题,TCP使用持续计时器。如果A收到了零窗口的通知,它会启动一个持续计时器。当计时器到期时,A会发送一个探测报文段,通常只包含1字节的数据。B在确认这个探测报文段时,会提供当前的窗口大小。如果窗口仍然是0,A会重新设置计时器。如果窗口不是0,那么死锁就可以被打破。
8.TCP的拥塞控制
TCP拥塞控制的基本原理是通过监测网络的拥塞程度来调整数据传输的速率,以避免网络过载。TCP拥塞控制主要包含以下几个关键算法:
-
慢启动(Slow Start):
- 当一个连接开始时,发送方从一个较小的拥塞窗口(cwnd)开始,通常是1个MSS(最大报文段大小)。
- 每当收到一个ACK,cwnd就会加倍,这样数据传输的速率就会指数增长,直到达到一个特定的阈值(ssthresh,慢启动阈值)。
-
拥塞避免(Congestion Avoidance):
- 当cwnd达到ssthresh时,TCP进入拥塞避免阶段。
- 在这个阶段,cwnd的增长速度变慢,每次收到ACK时,cwnd增加1个MSS。
- 这样可以线性增长cwnd,而不是指数增长,以更平滑地增加网络负载。
-
快速重传(Fast Retransmit):
- 当发送方收到三个重复的ACK时,它会认为数据包丢失,并立即重传丢失的数据包,而不是等待重传计时器到期。
- 这是基于这样的假设:如果一个数据包丢失,那么紧随其后的数据包也可能丢失。
-
快速恢复(Fast Recovery):
- 在快速重传之后,TCP进入快速恢复阶段。
- ssthresh被设置为当前cwnd的一半,cwnd也被设置为ssthresh加上3个MSS(因为收到了三个重复的ACK,意味着有三个数据包已经离开网络)。
- 然后,cwnd以拥塞避免的方式增长,直到再次遇到丢包。
9.TCP运输连接管理
TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此,运输连接就有三个阶段,即:连接建立、数据传送和连接释放 。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在TCP连接建立过程中要解决以下三个问题:
- 要使每一方能够确知对方的存在。
- 要允许双方协商一些参数(如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等)。
- 能够对运输实体资源(如缓存大小、连接表中的项目等)进行分配。
TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫作客户(client) ,而被动等待连接建立的应用进程叫作服务器(server)。
9.1TCP连接的建立(三次握手)
TCP连接建立的三次握手(Three-way Handshake)是TCP协议中用于在客户端和服务器之间建立连接的一系列步骤。其目的是确保双方都准备好进行数据传输,并确认双方的初始序列号。以下是三次握手的详细过程:
-
第一次握手(SYN):
- 客户端 发送一个TCP数据包到服务器,其中包含一个SYN(同步序列编号)标志。客户端会选择一个初始序列号(例如,x)并发送给服务器。这个包的目的就是告诉服务器:"我想要和你建立连接。"
-
第二次握手(SYN-ACK):
- 服务器收到SYN包后,会发送一个SYN-ACK包作为响应。这里,服务器会确认它接收到了客户端的SYN包,并发送自己的初始序列号(例如,y)以及一个ACK(确认)标志,确认号为客户端初始序列号加1(x+1)。这表示服务器同意建立连接并准备好接收数据。
-
第三次握手(ACK):
- 客户端 收到服务器的SYN-ACK包后,会发送一个ACK包给服务器,确认号为服务器的初始序列号加1(y+1)。这最后一步确认了双方的序列号和连接已经准备好,通信可以开始。
- 客户端 收到服务器的SYN-ACK包后,会发送一个ACK包给服务器,确认号为服务器的初始序列号加1(y+1)。这最后一步确认了双方的序列号和连接已经准备好,通信可以开始。
为什么需要第三次握手:
-
确保连接的可靠性:第三次握手确认了双方的准备状态,确保双方都知道对方已经准备好进行数据传输。如果只有两次握手,可能会出现以下问题:
- 如果客户端发送的SYN丢失或被延迟,服务器可能不会收到连接请求,导致连接建立失败。第三次握手确保客户端知道服务器已经准备好接收数据。
- 防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。例如,旧的SYN请求在网络中延迟很久后到达服务器,服务器可能会认为这是新的连接请求并响应,但是没有第三次握手,客户端不会再次确认,这样就不会建立错误的连接。
-
同步序列号:第三次握手不仅确认连接,还确保双方都知道对方的初始序列号,这些序列号在后续的数据传输中用于确保数据包的有序性和完整性。
通过这三次握手,TCP能够建立一个可靠的双向通信通道,确保数据传输的准确性和可靠性。
9.2TCP连接的释放(四次握手)
TCP连接的释放通常被称为"四次握手"(Four-way Handshake),用于在客户端和服务器之间终止一个已经建立的TCP连接。这个过程确保双方都同意结束连接,并且数据传输安全地结束。以下是TCP连接释放的四次握手步骤:
-
第一次握手(FIN):
- 客户端 决定关闭连接时,会发送一个FIN(Finish)标志的数据包给服务器,表示它已经完成了数据的发送(但仍然可以接收数据)。这个FIN包包含一个序列号。
-
第二次握手(ACK):
- 服务器收到FIN包后,发送一个ACK(确认)包给客户端,确认它已经收到了FIN请求。这个ACK包的确认号是客户端FIN包的序列号加1,表示服务器已经知道客户端想要关闭连接,但服务器可能还有数据需要发送。
-
第三次握手(FIN):
- 当服务器完成它想要发送的数据传输后,它也会发送一个FIN包给客户端,表示它现在也准备好关闭连接。这个包同样包含一个序列号。
-
第四次握手(ACK):
- 客户端 收到服务器的FIN包后,发送一个ACK包给服务器,确认它已经收到了服务器的FIN请求。这个ACK包的确认号是服务器FIN包的序列号加1。
- 客户端 收到服务器的FIN包后,发送一个ACK包给服务器,确认它已经收到了服务器的FIN请求。这个ACK包的确认号是服务器FIN包的序列号加1。
连接进入所谓的TIME_WAIT状态:
- 客户端在发送了最后的ACK后,并不立即关闭连接,而是进入TIME_WAIT状态,保持一段时间(通常是2个最大段生命周期,MSL - Maximum Segment Lifetime)。这确保了:
- 如果最后一个ACK包丢失,服务器可以在超时后重发FIN包,而客户端可以重新发送ACK。
- 确保所有数据包在网络中消失,防止旧连接的数据包干扰新连接。
完成这四个步骤后,连接正式关闭。客户端和服务器都可以释放这个连接所占用的资源。
为什么是四次握手而不是三次?
- 因为TCP是全双工通信,双方都可以独立地关闭发送数据的通道。客户端发送FIN表示它不会再发送数据,但它仍然可以接收数据;服务器在收到FIN后需要确认这个请求,并在自己完成数据发送后再发送自己的FIN。这意味着关闭连接需要双方的协调,分别关闭各自的发送和接收通道,这就导致了四次握手的必要性。