【计算机网络】TCP三次握手和四次挥手

本文详细解析了TCP的三次握手和四次挥手过程,解释了其原理、细节以及为什么采用三次握手和四次挥手的原因。

一、TCP简介

        TCP(传输控制协议,transmission control protocol)是可靠的、面向连接的数据传输协议,需要通过三次握手建立通信信道,他会把长数据切分成小数据包进行IP发送,以便进行差错控制(发送切分的小数据包,每发送一次都要等另一方确认,网络传输是不可靠的,如果中途某一个小数据包出错,则重新发送一次;如果不切分成小数据包,则只有等待长数据发送完成在进行ACK以及校验,这时候如果出错,则需要全部重传,这尼玛不是坑爹吗)。


二、三次握手

        客户端通过三次握手和服务器端建立连接,进行通信,其过程如下图所示。


1. 三次握手过程详解

        思想:客户端需要和服务器建立通信连接,但是不知道服务器是否可以建立链接,因此发起第一次握手,目的是告诉服务器端“我想和你建立链接”;当服务器收到请求建立链接数据包的时候,如果可以建立链接,则向客户端回应“我可以和你建立链接,我准备好了,你发起吧”,完成第二次握手;当客户端收到这个允许建立链接的响应数据包的时候,立即向服务器端发起确认,并进入ESTABLISHED状态,服务器收到该数据包之后,也进入ESTABLISHED状态,此时TCP链接建立完毕,三次握手完成。

        细节:第一次握手的时候,客户端发送一个SYN=1的同步标志(该标志仅在三次握手时有效)和一个随机数seq给服务器端;第二次握手的时候,当服务器端收到SYN=1,表明客户端需要和自己建立TCP链接,如果服务器端授予链接,则也回复一个SYN=1的标志位(这个标志位表示三次握手,而且仅在三次握手中有效,三次握手中都必须出现)以及ACK=seq+1(用于校验)和一个随机数seq;第三次握手的时候,客户端收到服务器端授予链接的数据包,于是查看SYN=1标志位,确认是建立链接的数据包,校验ACK中的随机数是否是自己发送的随机数+1,如果是,则立即发送数据包向服务器端进行确认,包含SYN=1(三次握手标志位,很重要)以及ACK=seq+1(服务器端的随机数)和自己的seq+1给服务器端,发完后立即进入ESTABLISHED状态,服务器端收到之后,检查ACK和seq,确认无误也立即进入ESTABLISHED状态,链接建立,三次握手完毕。

2. 为什么不是一次握手

        如果是一次握手,那么客户端在发完请求建立链接数据包的时候就要立即进入ESTABLISHED状态,网络传输时不可靠的(没有TCP进行差错控制和校验的话),如果这时候数据包丢失了服务器端收不到,那么就悲剧了,客户端已经绑定端口占用资源空等了,之后传输数据都不会得到ACK确认,会一直发送数据包给服务器,服务器由于没有收到请求建立链接的数据包从而认为后续到达的数据包都是垃圾信息全部丢弃,这样会造成客户端资源量费,消耗网络带宽,因此至少还需要服务器端的确认客户端才能建立链接分配资源。

3. 为什么不是两次握手

        接着一次握手讨论,客户端在发送请求建立链接之后要等到服务器端确认才开启链接分配资源,那就意味着服务器端在收到请求建立链接的数据包之后就要进入ESTABLISHED状态——也就是客户端发起请求,服务器端收到请求后想客户端确认并立即进入ESTABLISHED状态,此时如果服务器端向客户端确认的数据包丢失,那么客户端不会和服务器端成功建立链接导致服务器端的资源量费,此时如果客户端有重试机制,那么就会导致服务器端建立两个以上的连接(一个是分配资源但是没有客户端),要是在网络抖动期间有大量客户端建立链接,那么服务器的资源浪费就太严重了,所以,三次链接更靠谱。


三、四次挥手

        客户端通过四次挥手和服务器端解除通信连接,释放资源,其过程如下图所示。


1. 四次挥手详解

        思想:假设是客户端发起关闭连接请求。首先明确的一点是TCP通信时双工通信,即客户端可以向服务器端发送数据,同时服务器端也可以向客户端发数据,因此在关闭的时候,每一个方向都要单独关闭。第一次挥手,此时客户端数据发送完了需要关闭连接,但是他不知道服务器端是否还有数据要发送可不可以关闭链接,于是发起结束链接的数据包告诉服务器端“我要关闭连接了,你是不是同意”;第二次挥手,服务器端收到之后,立即回复ACK,表明“哦,我已经知道你的数据发送完了,我回收我接收数据的资源,你可以回收你发送数据的资源了”,进入你不再发数据我不再收数据的状态,也就是各自关闭一半;第三次挥手,服务器端也没有数据发送了,于是发送关闭连接的数据包FIN给客户端,通知我的数据发完了,准备管理链接;第四次握手,当客户端收到之后,立即向服务器端确认并关闭资源,服务器端收到之后,进入closed状态,服务器端也关闭资源,四次挥手结束。

        细节:http://blog.chinaunix.net/uid-7411781-id-3812206.html


2. 为什么不是一次挥手

        这个比较容易理解,节省时间,不做讨论。

3. 为什么不是两次挥手

        这个也比较容易理解,节省时间,不做讨论。

4. 为什么不是三次挥手

        原因:http://blog.youkuaiyun.com/xifeijian/article/details/12777187,简单来说,第三次握手后服务器端向客户端ACK是附在随后服务器端向客户端通信的数据包之后,而不是单独的一个ACK数据包。


参考资料:

1. http://www.cnblogs.com/panjun-donet/articles/1142466.html

2. http://www.cnblogs.com/rootq/articles/1377355.html

3. 《HTTP权威指南》

4. http://blog.youkuaiyun.com/xifeijian/article/details/12777187


附注:

        时间紧迫,写的简陋,烦请见谅。本文如有错漏,烦请不吝指正,谢谢!

<think>首先,用户的问题是关于计算机网络TCP三次握手四次挥手的原理及过程。我需要参考提供的引用,这些引用解释了一些关键点: - 引用[1]:TCP使用三次握手四次挥手来建立终止连接,目的是确保可靠的连接建立终止,保护数据的完整性可靠性。 - 引用[2]:三次握手确保双方具有接收发送的能力。两次握手可能导致资源浪费,因为服务器无法确认客户端是否收到回复。四次挥手可以优化为三次,但挥手过程是四次。 - 引用[3]:如果采用两次握手,服务器在收到SYN包后立即分配资源,可能导致无效连接占用资源,如端口耗尽或内存泄漏。 用户要求了解原理及过程,所以我需要系统地解释TCP三次握手四次挥手的步骤、原因目的。 根据系统级指令: - 所有行内数学表达式使用$...$格式。 - 独立公式使用$$...$$格式并单独成段。 - 使用中文回答。 - 生成相关问题。 - 在回答中引用的段落末尾添加引用标识。 - 回答结构清晰,帮助用户逐步解决问题,保证真实可靠。 结构我的回答: 1. **介绍TCP连接管理**:简要介绍TCP是面向连接的协议,需要建立终止连接。 2. **TCP三次握手原理及过程**: - 步骤:详细描述三次握手的过程。 - 目的:解释为什么需要三次握手,而不是两次或四次。 - 引用相关部分:例如,为什么两次握手会导致问题(如资源浪费)。 3. **TCP四次挥手原理及过程**: - 步骤:详细描述四次挥手的过程。 - 目的:解释为什么需要四次挥手,以及为什么它不能简化成三次在某些情况下。 - 注意引用中提到四次挥手可以优化为三次,但标准是四次,因为挥手涉及半关闭状态。 4. **总结**:强调可靠性的重要性。 5. **生成相关问题**:在最后添加相关问题。 在回答中,我需要自然地添加引用标识。例如,当提到资源浪费时,引用[3]。 现在,详细内容: ### TCP三次握手 过程: 1. 客户端发送SYN包(SYN=1, seq=x)到服务器,进入SYN_SENT状态。 2. 服务器接收SYN包,发送SYN-ACK包(SYN=1, ACK=1, seq=y, ack=x+1),进入SYN_RCVD状态。 3. 客户端接收SYN-ACK包,发送ACK包(ACK=1, seq=x+1, ack=y+1),进入ESTABLISHED状态。服务器接收后也进入ESTABLISHED状态。 为什么三次? - 确保双方都具有发送接收能力。两次握手时,服务器无法知道客户端是否收到了ACK,可能导致服务器资源被无效连接占用[^3]。 ### TCP四次挥手 过程: 1. 主动关闭方(如客户端)发送FIN包(FIN=1, seq=u),进入FIN_WAIT_1状态。 2. 被动关闭方接收FIN包,发送ACK包(ACK=1, seq=v, ack=u+1),进入CLOSE_WAIT状态。主动方进入FIN_WAIT_2状态。 3. 被动关闭方发送FIN包(FIN=1, seq=w, ack=u+1),进入LAST_ACK状态。 4. 主动关闭方接收FIN包,发送ACK包(ACK=1, seq=u+1, ack=w+1),进入TIME_WAIT状态。等待2MSL后关闭。被动方接收ACK后关闭。 为什么四次? - 因为连接是全双工的,关闭需要双方都确认关闭。ACKFIN分开发送,是因为被动方可能还有数据要发送。 引用中提到“四次挥手可以优化为三次”,但在标准TCP中,是四次,因为ACKFIN不能总是合并。 现在,生成相关问题: 1. TCP三次握手为什么能防止资源浪费? 2. TCP四次挥手时TIME_WAIT状态的作用是什么? 3. TCP连接管理中还有其他优化机制吗? 确保使用正确格式: - 对于数学表达式,如果有序列号,可以使用行内格式,如$seq=x$。 - 独立公式可能不常用,如果有必要,比如计算时间,但这里可能不需要。 最终回答结构: 1. 介绍 2. 三次握手详细解释 3. 四次挥手详细解释 4. 总结 5. 相关问题 </think> ### TCP三次握手四次挥手的原理及过程 TCP(传输控制协议)是一种面向连接的可靠传输协议,在通信前需建立连接,通信后需终止连接,以确保数据的完整性、有序性可靠性。TCP使用“三次握手”建立连接四次挥手”终止连接,以下将逐步解释其原理过程。整个过程基于序列号(如$seq=x$)确认号(如$ack=x+1$)机制,确保数据同步[^1][^2]。 #### 1. **TCP三次握手(连接建立过程)** 三次握手确保通信双方(客户端服务器)都具有发送接收数据的能力,防止无效连接占用资源(如端口或内存)。如果采用两次握手,服务器可能为延迟的SYN包分配资源,导致资源浪费或耗尽[^3]。过程如下: 1. **第一步:客户端发送SYN包** - 客户端向服务器发送一个SYN(Synchronize)包,设置SYN标志位为1,并生成一个随机初始序列号$seq=x$。 - 客户端进入SYN_SENT状态。 2. **第二步:服务器回复SYN-ACK包** - 服务器收到SYN包后,分配连接资源(如TCB控制块),并发送一个SYN-ACK包(同时设置SYN=1ACK=1)。 - 包中包含:服务器的初始序列号$seq=y$,以及确认号$ack=x+1$(表示已收到客户端的序列号x)。 - 服务器进入SYN_RCVD状态。 3. **第三步:客户端发送ACK包** - 客户端收到SYN-ACK包后,验证$ack=x+1$是否正确。 - 客户端发送ACK包(ACK=1),序列号为$seq=x+1$,确认号为$ack=y+1$。 - 双方进入ESTABLISHED状态,连接建立完成。 **为什么需要三次握手?** - 两次握手(省略第三步)可能导致服务器在未确认客户端状态时分配资源。如果旧SYN包延迟到达,服务器可能创建无效连接,引发资源耗尽风险(如端口占满)。 - 三次握手确保双工通信可靠:客户端确认服务器能收数据(通过SYN-ACK),服务器确认客户端能发数据(通过ACK)。 #### 2. **TCP四次挥手(连接终止过程)** 四次挥手用于安全关闭全双工连接,确保双方数据都传输完毕。挥手过程不能简化为三次,因为服务器可能还有数据需发送(半关闭状态)。过程如下: 1. **第一步:主动关闭方发送FIN包** - 主动关闭方(如客户端)发送FIN(Finish)包,设置FIN标志位为1,序列号为$seq=u$。 - 客户端进入FIN_WAIT_1状态。 2. **第二步:被动关闭方回复ACK包** - 被动关闭方(如服务器)收到FIN包后,发送ACK包(ACK=1),序列号为$seq=v$,确认号为$ack=u+1$。 - 服务器进入CLOSE_WAIT状态,客户端收到后进入FIN_WAIT_2状态。此时,服务器可能继续发送剩余数据。 3. **第三步:被动关闭方发送FIN包** - 服务器完成数据发送后,发送FIN包(FIN=1),序列号为$seq=w$(通常$w = v + \text{数据长度}$),确认号仍为$ack=u+1$。 - 服务器进入LAST_ACK状态。 4. **第四步:主动关闭方回复ACK包** - 客户端收到FIN包后,发送ACK包(ACK=1),序列号为$seq=u+1$,确认号为$ack=w+1$。 - 客户端进入TIME_WAIT状态,等待2MSL(最大报文段生存时间,通常2分钟)后关闭,防止旧包干扰新连接。服务器收到ACK后立即关闭。 **为什么需要四次挥手?** - ACKFIN分开发送,是因为被动关闭方可能需时间处理剩余数据(半关闭),无法立即发送FIN[^2]。 - TIME_WAIT状态确保最后一个ACK可靠到达,避免连接混乱[^1]。 #### 总结 TCP三次握手四次挥手是保证可靠传输的核心机制:握手防止连接错误建立,挥手确保优雅终止。这些过程通过序列号标志位(如SYN、ACK、FIN)实现同步,解决了网络延迟丢包问题[^1][^3]。在实际网络中,优化如SYN Cookie可减少握手资源开销,但基本流程不变。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值