精华内容
下载资源
问答
  • TCP四次挥手过程

    万次阅读 多人点赞 2019-07-11 11:27:33
    四次挥手 状态转化:A、B连接建立状态ESTABLISHED -> A终止等待1状态FIN-WAIT-1 -> B关闭等待状态2CLOSE-WAIT -> A终止等待2状态FIN-WAIT-2 ->... 四次挥手过程 第一次挥手:A数据传输完毕需...

    四次挥手

    状态转化:A、B连接建立状态ESTABLISHED -> A终止等待1状态FIN-WAIT-1 -> B关闭等待状态2CLOSE-WAIT -> A终止等待2状态FIN-WAIT-2 -> B最后确认状态LAST-ACK -> A时间等待状态TIME-WAIT -> B、A关闭状态CLOSED

    • 四次挥手过程

    第一次挥手:A数据传输完毕需要断开连接,A的应用进程向其TCP发出连接释放报文段(FIN = 1,序号seq = u),并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1状态,等待B的确认。

    第二次挥手:B收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),B进入CLOSE-WAIT关闭等待状态,此时的TCP处于半关闭状态,A到B的连接释放。而A收到B的确认后,进入FIN-WAIT-2状态,等待B发出的连接释放报文段。

    第三次挥手:当B数据传输完毕后,B发出连接释放报文段(FIN = 1,ACK = 1,序号seq = w,确认号ack=u+1),B进入LAST-ACK(最后确认)状态,等待A 的最后确认。

    第四次挥手:A收到B的连接释放报文段后,对此发出确认报文段(ACK = 1,seq=u+1,ack=w+1),A进入TIME-WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,A才进入CLOSE状态。

    • 为什么A在TIME-WAIT状态必须等待2MSL(最大报文生存时间)的时间?

    1.保证A发送的最后一个ACK报文段能够到达B,保证A、B正常进入CLOSED状态。

       这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B超时重传FIN+ACK报文段,A能2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,同时重启2MSL计数器,2MSL时间后A和B进入CLOSE状态,如果A在TIME-WAIT状态时接收到B的FIN+ACK报文段之后向B发出确认报文段,而不再确认B是否收到立即进入CLOSED状态,如若B并没有正常收到A 的确认报文段,则B无法正正常进入到CLOSED状态。

    2.防止“已经失效的连接请求报文段”出现在本连接中。

       A在发送完最后一个ACK报文段并经过2MSL,会使本次连接持续时间内所有产生的报文段消失,保证在下一次新连接中不会出现旧连接遗留的请求报文段。

    展开全文
  • TCP三次握手四次挥手过程 原文链接

    TCP三次握手四次挥手过程

    原文链接

    展开全文
  • TCP三次和四次挥手过程1、TCP报文段首部2、TCP三次握手过程及常见问题2.1 TCP三次握手过程2.2 常见问题2、TCP四次挥手过程及问题2.1 TCP四次挥手过程2.2 常见问题 1、TCP报文段首部     &...

    1、TCP报文段首部

    在这里插入图片描述
             要理解TCP三次握手和四次挥手的过程,首先需要了解TCP报文段的某些首部的含义:

    • 序号 seq:本报文段所发送的数据的第一个字节序号
    • 确认号 ack:期望收到对方下一个报文段的第一个数据字节的序号
    • 确认位 ACK:仅当ACK=1时确认号字段才有效
    • 同步位 SYN:在连接建立时用来同步序号,SYN=1表示这是一个连接请求或是连接接受请求。
    • 终止位 FIN:用来释放一个连接。当FIN=1时,表示此报文段的发送方数据已经发送完毕,并要求释放运输连接

    2、TCP三次握手过程及常见问题

    2.1 TCP三次握手过程

    在这里插入图片描述
    (1)客户端A向服务端B发出连接请求,同步位SYN=1,初始序列seq=x,连接请求报文段不能携带数据,但是要消耗一个序号,这时客户端A进入SYN-SENT(同步已发送状态)。
    (2)服务端B收到请求报文段之后,向A发送后确认。将同部位SYN和确认位都置为1,确认序号ack=x+1,同时自己选择一个初始序号seq=y。连接接收报文也不能携带数据,但是也要消耗一个序号,这时服务端进入SYN-RCVD(同步收到状态)。
    (3)A收到B的确认时候要给B一个确认。确认报文段的确认位ACK=1,确认号ack=y+1,自己的序号seq=x+1。这时,TCP连接已经建立,客户端进入ESTABLISHED(已建立连接状态)。B收到A发出的确认报文之后也进入已建立连接状态。

    2.2 常见问题

    (1)为什么客户端还需要再发送一次确认
             主要是为了防止已经失效的连接请求报文段突然又传到了B,因而产生错误。“已失效的连接请求报文段”的产生在这样一种情况下:A发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了(因为网络并发量很大在某结点被阻塞了),以致延误到连接释放以后的某个时间才到达B。但是B收到此失效的报文段后,就认为是A又发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接。如果不采用三次握手,那么只要B发出确认,新的连接就建立了,B的许多资源就白白浪费。
    (2)SYN Flood攻击
             SYN Flood攻击指利用tcp协议缺陷发送大量伪造的TCP连接请求,从而使被攻击方资源耗尽(CPU满负载或者内存不足)的攻击法方式。解决方法:

    • 缩短 SYN Timeout 时间缩短从接收到 SYN 报文到确定这个报文无效并丢弃该连接的时间,但是过低的SYN Timeout可能会影响用户正常访问。
    • 设置 SYN Cookie给每一个请求连接的 IP 地址分配一个 Cookie,如果短时间内连续受到某个IP的重复 SYN 报文,就认定是受到了攻击,以后从这个 IP 地址来的包会被丢弃
    • 使用硬件防火墙

    可以参考百度百科对SYN Flood攻击 的理解

    3、TCP四次挥手过程及问题

    3.1 TCP四次挥手过程

    在这里插入图片描述
    (1)客户端进程发出连接释放报文,并且停止发送数据。A将连接释放报文的终止位FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1)。此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
    (2)服务器收到连接释放报文后发出确认,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向的连接就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
    (3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)
    (4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认
    (5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗MSL(最长报文段寿命)的时间后,客户端才进入CLOSED状态
    (6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。

    3.2 常见问题

    (1)为什么A在WAIT-TIME状态必须等待2MSL的时间??

    • 为了保证A发送的最后一个确认报文段能够达到B。这个ACK报文段可能丢失,因而使处在LAST-ACK状态的B收不到A发送的FIN+ACK报文段的确认。B会超时重传这个ACK+FIN报文段,而A就能在这个时间内收到这个重传的报文。接着A在再重传一次确认报文,并且重启2MSL计时器。使A和B都能正常的进入释放连接状态。
    • 防止已经关闭的连接报文段出现在新的连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有旧报文段都从网络中消失。这样新的连接中不会出现旧连接的数据报文。

    (2)为什么建立连接是三次握手,而关闭连接却是四次挥手呢??
             这是由于服务端的LISTEN状态下收到SYN报文的建立连接请求后。它能够把ACK和SYN(ACK起应答作用。而SYN起同步作用)放在一个报文里来发送给客户端。
             但关闭连接的时候,当服务端收到客户端的FIN报文段的时候,表示客户端没有数据发送给服务端了,但是服务端可能还有数据要发送给客户端,这时TCP连接处于半连接状态。当服务端没有数据再发送给客户端的时候就会向客户端发送一个FIN报文表示服务端要关闭连接,ACK和FIN一般不会分开发送。这个过程也是由于TCP的通信方式是全双工的,发送和接收方都需要发送FIN和ACK。

    展开全文
  • 三次握手,四次挥手过程 三次握手 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn 包(tcp 协议中syn位置1,序号为J)到服务器,并进入SYN_ ...

    三次握手

      在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。


           第一次握手:建立连接时,客户端发送syn 包(tcp 协议中syn位置1,序号为J)到服务器,并进入SYN_ SEND状态,等待服务器确认;
           第二次握手:服务器收到syn包,必须确认客户的sYN,同时自己也发送一一个SYN包,即SYN+ACK包(tcp 协议中syn位置1,ack位置1,序号K,确定序号为J+1),此时服务器进入SYN RECV状态:
           第三次握手:客户端收到服务器的SYN+ACK 包,向服务器发送确认包ACK (tcp协议中ack位置1,确认序号K+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。通过这样的三次握手,客户端与服务端建立起可靠的双工的连接,开始传送数据。三次握手的最主要目的是保证连接是双工的,可靠更多的是通过重传机制来保证的。


           但是为什么一定要进行三次握手来保证连接是双工的呢,一次不行么? 两次不行么?
           我们举一个现实生活中两个人进行语言沟通的例子来模拟三次握手。同理对于TCP为什么需要进行三次握手我们可以一样的理解:为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手,为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

     

    四次挥手

           由于ICP连接是全双工的,因此每个方向都必须单独进行关闭。这好比,我们打电话(全双工),正常的情况下(出于礼貌),通话的双方都要说再见后才能挂电话,保证通信双方都把话说完了才挂电话。


           那TCP的四次握手,是为了保证通信双方都关闭了连接,具体过程如下:
           1、客户端A在应用层调用close时会激发底层发送一一个FIN (tcp协议中FIN位置1、序号为M,结合上图分析)请求,用来关闭客户A到服务器B的数据传送,客户端A此时处于半关闭状态(应用层无法接收数据但底层还可以接收数据) :
           2、服务器B底层收到客户端A的FIN时会做两件事
           第1件事:收到客户端A的FIN时底层会主动回发一个ACK(tcp协议中ACK位置1,确认序号M+1)
           第2件事:收到客户端A的FIN时,导致服务器B的应用层read()返回0 (告诉服务器B应用层:客户端A关闭了)
          3、服务器B应用层调用close ()激发底层给客户端A发送一个FIN (tcp 协议中FIN位置1、序号为N) , 这是服务器B已处于半关闭状态;
          4、客户端A底层回发ACK (tcp协议中ACK位置1,确认序号N+1)给服务器B, 这是客户端A、服务器B都处于完全关闭状态,回收相应的资源。

     

     


    TCP 通信过程中各步骤的状态图 1

     

           状态图 2
           对于上面的图 N 多人都知道,它排除和定位网络或系统故障时大有帮助,但是怎样牢牢地将这张图刻在脑中呢?那么你就一定要对这张图的每一个状态,及转换的过程有深刻的认识,不能只停留在一知半解之中。下面对这张图的 11 种状态详细解析一下,以便加强记忆!不过在这之前,先回顾一下 TCP 建立连接的三次握手过程,以及关闭连接的四次握手过程,详情请看上面的 TCP 三次握手和四次挥手。

     

    展开全文
  • HTTP三次握手四次挥手过程HTTP三次握手四次挥手过程基本描述工作流程建立连接-TCP三次握手为什么三次握手断开连接-TCP四次挥手为什么四次挥手 HTTP三次握手四次挥手过程 基本描述 http协议全称:HyperText Transfer...
  • 案例测试TCP的三次握手和四次挥手过程。包括C语言写的服务器端程序以及c#写的客户端程序,以及使用wirkshark进行的网络抓包分析TCP三次握手四次挥手的过程。
  • TCP四次挥手过程分析

    2020-09-19 16:38:26
    1、tcp四次挥手过程状态迁移如下所示: 1)、客户端通过close系统调用向服务端发起第一次挥手请求,此时客户端将自己状态置为TCP_FIN_WAIT1状态; 2)、服务端收到fin请求后,将状态置为TCP_CLOSE_WAIT,并设置...
  • 简述TCP三次握手和四次挥手过程
  • TCP/IP的四次挥手过程

    2020-08-27 09:02:21
    文章目录必要的基础知识四次挥手过程为什么挥手需要四次为什么客户端等待2MSL后才进入CLOSE状态 必要的基础知识 FIN:FIN位为1表示结束连接 四次挥手过程 第一次挥手:客户端给服务段发送FIN=1信号,告诉客户端我...
  • 三次握手四次挥手过程详解 三次握手: 1.客户端发送syn=1连接报文起始号为x,进入同步已发送状态。 2.服务器发送确认报文syn=1,ack=1,起始号为y,确认号为x+1,进入同步已接收状态 3.客户端发送确认报文syn=1,...
  • 描述TCP协议状态机及三次握手四次挥手过程
  • 三次握手与四次挥手过程详解三次握手建立连接:传输数据过程:四次握手断开连接:常见面试问题: TCP通信过程包括三个步骤:建立TCP连接通道,传输数据,断开TCP连接通道 上图主要包括三部分:建立连接、传输数据、...
  • TCP四次挥手过程:  1、第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态;  2、第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN...
  • 根据前一篇介绍TCP三次握手内核代码分析,下面来大致分析一下,四次挥手过程。 首先上一张四次挥手图片: 由上图可以观察到是客户端先发起的close操作(服务器先发起close操作也是同样的流程)。 (1)谁先close套接...
  • 简单描述 TCP三次握手与四次挥手过程

    万次阅读 多人点赞 2018-06-03 10:15:34
    TCP三次握手与四次挥手过程首先,客户端与服务器均处于未连接状态,并且是客户端主动向服务器请求建立连接:客户端将报文段中的SYN=1,并选择一个seq=x,(即该请求报文的序号为x) 将这个报文发送到服务器。...
  • TCP三次握手和四次挥手过程一 、 TCP协议TCP(Transmission Control Protocol传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP提供全双工服务,数据可在同一时间段双向传输。每一个TCP都有...
  • 详解TCP三次握手和四次挥手过程及常见面试题

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,162
精华内容 1,664
关键字:

四次挥手过程