[Linux网络]TCP三次握手和四次挥手的连接建立和断开

TCP三次握手与四次挥手详解

TCP的三次握手

  • 第一次握手:客户端发送网络包,服务器端收到,证明客户端的发送能力、服务器的接收能力是正常的。
  • 第二次握手:服务器发送网络包,客户端收到,证明服务器端的发送能力是正常的,不过此时并不能确定,客户端的接收能力是正常的。
  • 第三次握手:客户端发包,服务器端收到,服务器端可以得出结论,客户端的发送,接收能力是正常的。服务器端的接收,发送能力是正常的。
    在这里插入图片描述

什么是半连接队列?

  • 服务器端第一次收到客户端的SYN之后,会处于SYN_RCVD状态,此时双方还没有正式完全建立连接,服务器会把这种状态下的连接请求放入一个队列中,这个队列就被称之为半连接队列。
    对应的,完成三次握手之后,建立起的连接我们就会放入到全连接队列中,如果队列满了就有可能出现丢包的现象。
  • SYN-ACK重传次数的问题:服务器端发送完SYN-ACK包,如果未收到客户端的确认包,服务器进行首次重传,如果重传次数超过系统规定的最大重传次数,
    系统将连接信息从半连接队列中删除。
  • 半连接存活时间:

ISN(Initial Sequence Number)是固定的吗?

  • 肯定不是,序列号是动态生成的,防止被攻击
  • ISN随时间变化,每个连接都将具有不同的ISN。ISN可以看作是一个32bit的计数器。每4ms加一。这样选择的序列号的目的在于防止在网络中被延迟的分组在以后又被传送。

SYN攻击

  • 服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击。
    SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包,并等待Client确认,由于源地址不存在,因此Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。
  • SYN 攻击是一种典型的 DoS/DDoS 攻击。

TCP的四次挥手

建立一个TCP链接,需要三次握手,终止一个连接需要经过四次挥手。

  • 第一次挥手:客户端发送FIN报文,说明断开连接,客户端停止向服务器端发送信号,此时客户端处于FIN_WAIT1,然后服务器端处于半关闭状态(FIN = 1, seq = u)
  • 第二次挥手:服务器端接收到FIN报文之后,发送ACK报文,把客户端的序列号值+1作为ACK报文的序列值进行发送,表示服务器端已经收到客户端的报文,服务器处于CLOSE_WAIT(关闭等待)状态
    服务器收到连接释放报文段后发出确认报文段(ACK=1,确认号ack= u+1,序号seq=v)
  • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。(FIN = 1, ACK = 1,ack = u+1,seq = w)此时服务器处于LAST_ACK状态。
  • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态(ACK = 1, seq = u+1, ack = w + 1)
    在这里插入图片描述

为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSED状态?

  • 理论上,四个报文都发送完毕,就可以直接进入CLOSE状态了,但是可能网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

四次挥手释放连接时,等待2MSL的意义?

  • MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。
  • 保证客户端发送的最后一个ACK报文段能够到达服务端。
  • 防止“已失效的连接请求报文段”出现在本连接中。:客户端在发送完最后一个ACK报文段之后,再经过2MSL,就可以使本连接持续的时间内所有请求的报文段都从网络消失,便使下一个新的连接中不会出现这种旧的连接请求报文段。
<think>好的,我现在需要回答用户关于Linux环境中TCP三次握手四次挥手的详细过程。首先,我得回忆一下TCP协议的基本概念,确保自己理解正确。用户已经提供了三个引用,我需要结合这些内容来构建答案,同时注意正确使用LaTeX格式,并且生成相关问题。 首先,三次握手。根据引用[1]引用[2],三次握手是为了建立连接,确认双方的收发能力,并且是全双工通信的最小成本确认方式。引用中还提到三次握手实际上是四次,但中间两次被合并了。我需要详细描述每一步:客户端发送SYN,服务端回应SYN-ACK,客户端再发送ACK。同时,需要说明每个步骤中的标志位(SYN,ACK)序列号的变化。可能还需要提到状态变化,比如LISTEN、SYN-SENT、SYN-RECEIVED、ESTABLISHED等,但引用中提到了TCP连接的11种状态,这里需要确认是否需要详细展开。不过用户的问题主要是过程,所以可能简要提及状态即可。 然后是四次挥手。根据引用[1]引用[2],四次挥手用于断开连接,这里需要说明为什么需要四次而不是三次。引用[2]提到四次挥手,可能是因为双方都需要独立关闭自己的连接。步骤包括FIN、ACK、FIN、ACK。状态变化如FIN-WAIT-1、CLOSE-WAIT、LAST-ACK等,但同样是否需要详细描述状态取决于用户需求,用户的问题是关于过程,所以重点放在步骤上。 需要确保使用中文回答,结构清晰,分步骤说明。同时,按照系统级指令,行内数学表达式用$...$,但这里可能更多是协议步骤,可能不需要数学公式,但如果有涉及变量或技术术语,可能需要用LaTeX。例如,序列号可能用$x$表示,但根据示例,可能不需要特别处理,除非明确有数学表达式。 接下来,检查是否需要引用。每个引用的内容需要对应到回答中的相关部分。例如,引用[3]提到TCP的可靠性UDP的区别,可能在回答中不需要,但用户的问题是关于三次握手四次挥手,所以主要引用[1][2]。 现在组织内容: 1. 三次握手过程: - 客户端发送SYN(seq=x) - 服务端响应SYN-ACK(seq=y, ack=x+1) - 客户端发送ACK(ack=y+1) - 建立连接,状态变为ESTABLISHED 引用[1][2]说明三次握手的目的合并中间步骤。 2. 四次挥手过程: - 客户端发送FIN(seq=u) - 服务端响应ACK(ack=u+1) - 服务端发送FIN(seq=v, ack=u+1) - 客户端响应ACK(ack=v+1) - 进入TIME-WAIT状态,等待2MSL后关闭 引用[1][2]说明四次挥手的原因,如全双工关闭需要独立步骤。 注意状态转换可能需要提及,但用户的问题可能更关注过程而非状态细节。需要确认是否必要。 然后生成相关问题,如: 1. 为什么三次握手需要三次而不是两次? 2. TIME-WAIT状态的作用是什么? 3. 如果握手过程中丢包会怎样? 确保符合用户要求的格式,使用正确的引用标识,例如在解释三次握手时末尾添加[^1][^2],在四次挥手部分添加。 最后,检查LaTeX是否符合要求,例如如果有变量或公式,如序列号使用$x$,则用$...$包裹,但根据示例,可能不需要,除非明确有数学表达式。例如,在描述seq=x时,可以写成$seq = x$,但需要看是否需要。根据示例中的快速排序代码,可能用户的问题中不需要太多LaTeX,但按照系统指令,所有行内数学表达式必须使用$...$,因此像seq=x可能需要写成$seq = x$。需要检查这一点。 例如,步骤中的序列号确认号可能需要用行内公式,如客户端发送SYN,序列号为$x$,即$seq = x$,这样符合系统指令。 现在,开始撰写回答,分步骤详细说明三次握手四次挥手,确保引用正确,结构清晰,生成相关问题,并检查LaTeX格式是否正确。</think>### TCP三次握手四次挥手的过程详解(Linux环境) #### 一、TCP三次握手建立连接 TCP通过三次握手确保双方具备双向通信能力,并同步初始序列号(ISN)。 1. **第一次握手(SYN)** 客户端发送SYN报文,设置标志位$SYN=1$,并生成随机初始序列号$seq = x$。此时客户端进入$SYN\text{-}SENT$状态。 2. **第二次握手(SYN-ACK)** 服务端收到SYN后,回复SYN-ACK报文,设置$SYN=1$$ACK=1$,生成自己的序列号$seq = y$,确认号为$ack = x + 1$。服务端进入$SYN\text{-}RCVD$状态。 3. **第三次握手(ACK)** 客户端确认服务端的SYN-ACK,发送ACK报文,设置$ACK=1$,序列号$seq = x + 1$,确认号$ack = y + 1$。双方进入$ESTABLISHED$状态,连接建立完成。 > **关键点**:三次握手本质上是四次交互,但服务端将$SYN$$ACK$合并为一次发送,减少开销[^2]。 --- #### 二、TCP四次挥手:终止连接 四次挥手确保双方数据收发完全结束,并安全释放连接[^2]。 1. **第一次挥手(FIN)** 主动关闭方(如客户端)发送FIN报文,设置$FIN=1$,序列号$seq = u$,进入$FIN\text{-}WAIT\text{-}1$状态。 2. **第二次挥手(ACK)** 被动关闭方(如服务端)回复ACK报文,确认号$ack = u + 1$,进入$CLOSE\text{-}WAIT$状态。客户端收到后进入$FIN\text{-}WAIT\text{-}2$状态。 3. **第三次挥手(FIN)** 被动关闭方完成数据发送后,发送FIN报文,设置$FIN=1$,序列号$seq = v$,确认号$ack = u + 1$,进入$LAST\text{-}ACK$状态。 4. **第四次挥手(ACK)** 主动关闭方回复ACK报文,确认号$ack = v + 1$,进入$TIME\text{-}WAIT$状态,等待$2MSL$(最大报文生存时间)后关闭。服务端收到ACK后立即关闭连接。 > **关键点**:四次挥手TCP全双工特性,需独立关闭两个方向的连接。$TIME\text{-}WAIT$状态防止旧报文干扰新连接[^3]。 --- #### 三、Linux环境中的实践 - **抓包分析**:使用`tcpdump`命令可捕获握手与挥手报文,例如: ```bash tcpdump -i eth0 'tcp port 80' -w capture.pcap ``` - **状态查看**:通过`netstat`或`ss`命令查看TCP连接状态: ```bash netstat -ant | grep ESTABLISHED ``` ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值