精华内容
下载资源
问答
  • TCP三次握手和四次挥手详细过程

    千次阅读 2018-07-02 17:02:49
    这篇文章对TCP的三次握手和四次挥手详细过程进行总结。 1. TCP连接的建立—三次握手: 先对相关的符号作一下说明: 确认号字段(ack):占四个字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。若...

        这篇文章对TCP的三次握手和四次挥手详细过程进行总结。

    1. TCP连接的建立—三次握手:

    先对相关的符号作一下说明:

    • 确认号字段(ack):占四个字节,是期望收到对方的下一个报文段的数据的第一个字节的序号。若ack = N,则表明到序号N-1为止的所有数据都已正确收到。
    • 确认位(ACK):只有当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。
    • 同步位(SYN):同步 SYN=1 表示这是一个连接请求或连接接收报文。当SYN=1,ACK=0时,表明这是一个连接请求报文,对方若同意建立连接,则在响应报文中使用SYN=1,ACK=1。即,SYN=1就表示这是一个连接请求或连接接收报文。

        TCP的连接的建立采用客户/服务器的方式。主动发起连接建立的应用进程叫做客户机,而被动等待连接建立的应用进程叫做服务器。连接的建立分为3步,如下图所示。

                                 

                                                                                        图1  TCP三次握手

        第一步:客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段中不含应用层数据,其首部中的SYN标志位被置为1。另外,客户机会随机选择一个起始序列号 seq = x(连接请求报文不携带数据,但要消耗掉一个序号)。

        第二步:服务器的TCP收到连接请求报文段后,如同意建立连接,就向客户机发回确认,并未该TCP连接分配TCP缓存和变量。在确认报文段中,SYN和ACK位都被置为1,确认号字段的值为x+1,并且服务器随机产生起始序列号 seq = y(确认报文不携带数据,但也要消耗掉一个序号)。确认报文段同样不包含应用层数据。

        第三步:当客户机收到确认报文段后,还要向服务器给出确认,并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置为1,序号字段为 x+1,确认号字段 ack = y+1。该报文段可以携带数据,如果不携带数据则不消耗序号。

        在成功进行了以上三步之后,TCP连接就建立了,接下来就可以传送应用层数据了。TCP提供的是全双工通信,因此通信双方的应用进程在任何时候都能发送数据。需要注意的是,服务器端的资源是在完成第二次握手时分配的,而客户端的资源是在完成第三次握手时分配的。这就使得服务器易于受到SYN泛洪攻击。

    连接状态:

    1. CLOSE : 起始状态,无任何连接;
    2. LISTEN : 服务端建立socket之后需要listen进入LISTEN(侦听)模式,侦听来自远方的TCP连接请求。
    3. SYN_SENT : 客户端建立socket之后需要connect服务器,向服务端发送seq=x(随机数)申请连接,然后进入SYN_SENT状态。
    4. SYN_RECVD : 服务端在**侦听模式 *下收到seq后会向客户端回应ack=x+1,同时发送seq=y,然后进入SYN_RCVD状态。
    5. ESTABLISHED : 客户端收到ack后进行验证,同时回应服务端发来的seq,返回ack=y+1,然后进入ESTABLISHED状态。服务端收到最后一个ack后验证,然后进入ESTABLISHED。表示双方的连接建立完成,可以进行数据传输。

    TCP连接的释放—四次挥手

    相关符号说明:

    • 终止位(FIN):用来释放连接。FIN=1表明此报文段的发送方的数据已发送完毕,并要求释放传输连接。

      参与TCP连接的两个进程中的任何一个都能终止连接,释放步骤分为四步。释放连接过程图如下所示。

     2MSL (Maximum Segment Lifetime):  最大报文生存时间;

                               

                                                                                        图2 TCP四次挥手

        第一步:客户机打算关闭连接,就向其TCP发送一个连接释放报文段,并停止再发送数据,主动关闭TCP连接,该报文段的FIN标志位被置为1,seq = u,它等于前面已传送过的数据的最后一个自己的序号加1(FIN报文段即使不携带数据,也要消耗一个序号)。TCP是全双工的,即可以想象成是一条TCP连接上有两条数据通路。当发送FIN报文时,发送FIN报文的一段就不能再发送数据,也就是关闭了其中一条数据通路,但对方还可以发送数据。

        第二步:服务器收到连接释放报文段后即发出确认,确认号是ack = u+1,而这个报文段自己的序号是v,等于它们前面已传送过的数据的最后一个字节的序号加1。此时,从客户机到服务器这个方向的连接就释放了,TCP连接处于半关闭状态。但服务器若发送数据,客户机仍要接收,即从服务器到客户机这个方向的连接并未关闭。

        第三步:若服务器已经没有要向客户机发送的数据,就通知TCP释放连接,此时其发出FIN=1的连接释放报文段。

        第四步:客户机收到连接释放报文段后,必须发出确认。在确认报文段中,ACK字段被置为1,确认号ack = w+1,序号seq = u+1。此时TCP连接还没有释放掉,必须经过时间等待计时器设置的时间2MSL后,A才进入到连接关闭状态。

    连接状态:

    1. FIN_WAIT_1 : 在ESTABLISHED(连接)状态下,主动断开连接会向对端发送FIN=1,然后进入FIN_WAIT_1状态。
    2. CLOSED_WAIT : 被动断开连接的一端收到FIN之后,会回应ack,然后进入CLOSED_WAIT状态,在CLOSED_WAIT状态下,连接只能发送数据不能接收数据。
    3. FIN_WAIT_2 : 主动断开连接的一端收到FIN的ack回应后会进入FIN_WAIT_2状态。此时无法再发送数据但是可以接受数据。
    4. LAST_ACK : 被动断开连接的一端在缓冲区数据发送完成后会发送FIN = 1然后进入LAST_ACK状态。如果程序健壮性较差,在socket收到文件结束符之后没有关闭socket,此处不会发出FIN,导致连接停留在CLOSED_WAIT&FIN_WAIT_2状态。
    5. TIME_WAIT : 主动断开连接的一端在收到对端的FIN后回应ACK然后进入TIME_WAIT。此状态下连接已断开,但为了避免最后一个ACK在网络中迷路,而导致的状态紊乱,端口会被保留2*MSL的时长。
    6. CLOSED : 在TIME_WAIT状态停留时间达到2*MSL之后进入CLOSED状态,表示无任何连接。
    展开全文
  • 四次挥手 客户端TCP状态变化 服务器端TCP状态变化 问题 为什么连接三次握手,关闭四次挥手? 答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,...

    TCP连接中除了报文段发送以外,还涉及到客户端和服务端(连接的两端)的TCP状态变化

    三次握手

    三次握手

    四次挥手

    四次挥手

    客户端TCP状态变化

    这里写图片描述

    服务器端TCP状态变化

    这里写图片描述

    问题

    • 为什么连接三次握手,关闭四次挥手?
      答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
    • 为什么TIME_WAIT需要一段时间才能返回CLOSED?
      答:在TIME_WAIT状态中,如果TCP client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放。我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文

    参考

    https://blog.csdn.net/whuslei/article/details/6667471

    展开全文
  • tcp 三次握手 四次挥手 详细过程

    千次阅读 2011-05-20 08:22:00
    TCP状态迁移大家对netstat -a命令很熟悉,但是,你有没有注意到STATE一栏呢,基本上显示着established,time_wait,close_wait等,这些到底是 什么意思呢,在这篇文章,我将会详细...关闭连接要四次握手:发FIN包,ACK 包

    TCP状态迁移
    大家对netstat -a命令很熟悉,但是,你有没有注意到STATE一栏呢,基本上显示着established,time_wait,close_wait等,这些到底是 什么意思呢,在这篇文章,我将会详细的阐述。
    大家很明白TCP初始化连接三次握手吧:发SYN包,然后返回SYN/ACK包,再发ACK包,连接正式建立。但是这里有点出入,当请求者收到SYS /ACK包后,就开始建立连接了,而被请求者第三次握手结束后才建立连接。但是大家明白关闭连接的工作原理吗?关闭连接要四次握手:发FIN包,ACK 包,FIN包,ACK包,四次握手!!为什么呢,因为TCP连接是全双工,我关了你的连接,并不等于你关了我的连接。

    客户端TCP状态迁移:
    CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
    服务器TCP状态迁移:
    CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

    当客户端开始连接时,服务器还处于LISTENING,
    客户端发一个SYN包后,他就处于SYN_SENT状态,服务器就处于SYS收到状态,
    然后互相确认进入连接状态ESTABLISHED.


    当客户端请求关闭连接时,客户端发送一个FIN包后,客户端就进入FIN_WAIT_1状态,等待对方的确认包,
    服务器发送一个ACK包给客户,客户端收到ACK包后结束FIN_WAIT_1状态,进入FIN_WAIT_2状态,等待服务器发过来的关闭请求,
    服务器发一个FIN包后,进入CLOSE_WAIT状态,
    当客户端收到服务器的FIN包,FIN_WAIT_2状态就结束,然后给服务器端的FIN包给以一个确认包,客户端这时进入TIME_WAIT,
    当服务器收到确认包后,CLOSE_WAIT状态结束了,
    这时候服务器端真正的关闭了连接.但是客户端还在TIME_WAIT状态下,

    什么时候结束呢.我在这里再讲到一个新名词:2MSL等待状态,其实TIME_WAIT就是2MSL等待状态,
    为什么要设置这个状态,原因是有足够的时间让ACK包到达服务器端,如果服务器端没收到ACK包,超时了,然后重新发一个FIN包,直到服务器收到ACK 包.

    TIME_WAIT状态等待时间是在TCP重新启动后不连接任何请求的两倍.
    大家有没有发现一个问题:如果对方在第三次握手的时候出问题,如发FIN包的时候,不知道什么原因丢了这个包,然而这边一直处在FIN_WAIT_2状 态,而且TCP/IP并没有设置这个状态的过期时间,那他一直会保留这个状态下去,越来越多的FIN_WAIT_2状态会导致系统崩溃.

    上面我碰到的这个问题主要因为TCP的结束流程未走完,造成连接未释放。现设客户端主动断开连接,流程如下

     

    如上图所示,

    Client                            消息                                    Server

             close()
    ------ FIN ------->
    FIN_WAIT1                                                         CLOSE_WAIT
    <----- ACK -------
    FIN_WAIT2
    close()
    <------ FIN ------                    
    TIME_WAIT                                                       LAST_ACK      

                                          ------ ACK ------->
    CLOSED
    CLOSED


    由于Server的Socket在客户端已经关闭时而没有调用关闭,
    造成服务器端的连接处在“挂起”状态,而客户端则处在等待应答的状态上。
    此问题的典型特征是:
    一端处于FIN_WAIT2 ,而另一端处于CLOSE_WAIT.

    不过,根本问题还是程序写的不好,有待提高

    -------------------------------------------------------------------------

    CLOSE_WAIT,TCP的癌症,TCP的朋友。

    CLOSE_WAIT状态的生成原因
    首先我们知道,如果我们的服务器程序APACHE处于CLOSE_WAIT状态的话,说明套接字是被动关闭的!

    因为如果是CLIENT端主动断掉当前连接的话,那么双方关闭这个TCP连接共需要四个packet:

    Client ---> FIN ---> Server

    Client <--- ACK <--- Server

    这时候Client端处于FIN_WAIT_2状态;而Server 程序处于CLOSE_WAIT状态。

    Client <--- FIN <--- Server

    这时Server 发送FIN给Client,Server 就置为LAST_ACK状态。

    Client ---> ACK ---> Server

    Client回应了ACK,那么Server 的套接字才会真正置为CLOSED状态。

    Server 程序处于CLOSE_WAIT状态,而不是LAST_ACK状态,说明还没有发FIN给Client,那么可能是在关闭连接之前还有许多数据要发送或者其 他事要做,导致没有发这个FIN packet。

    通常来说,一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序,给你造成一堆的 CLOSE_WAIT,消耗你的资源,那么通常是等不到释放那一刻,系统就已经解决崩溃了。

    只能通过修改一下TCP/IP的参数,来缩短这个时间:修改tcp_keepalive_*系列参数有助于解决这个 问题。

    解决这个问题的方法是修改系统的参数,系统默认超时时间的是7200秒,也就是2小时, 这个太大了,可以修改如下几个参数:

    sysctl -w net.ipv4.tcp_keepalive_time=30
    sysctl -w net.ipv4.tcp_keepalive_probes=2
    sysctl -w net.ipv4.tcp_keepalive_intvl=2

    然后,执行sysctl命令使修改生效。

     

    连接进程是通过一系列状态表示的,这些状态有:
    LISTEN,SYN-SENT,SYN-RECEIVED,ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE- WAIT,CLOSING,LAST-ACK,TIME-WAIT和CLOSED。

    各个状态的意义如下:
    LISTEN - 侦听来自远方TCP端口的连接请求;
    SYN-SENT -在发送连接请求后等待匹配的连接请求;
    SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认;
    ESTABLISHED- 代表一个打开的连接,数据可以传送给用户;
    FIN-WAIT-1 - 等待远程TCP的连接中断请求,或先前的连接中断请求的确认;
    FIN-WAIT-2 - 从远程TCP等待连接中断请求;
    CLOSE-WAIT - 等待从本地用户发来的连接中断请求;
    CLOSING -等待远程TCP对连接中断的确认;
    LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认;
    TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认;
    CLOSED - 没有任何连接状态;

    TCP连接过程是状态的转换,促使发生状态转换的是用户调用:
    OPEN,SEND,RECEIVE,CLOSE,ABORT和STATUS;
    传送过来的数据段,特别那些包括以下标记的数据段SYN,ACK,RST和FIN;
    还有超时,上面所说的都会时TCP状态发生变化。

     

    TCP连接的状态转换图

     

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

    1、建立连接协议(三次握手)
    1)客户 端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1

    2) 服务器端回应客户端的,这是三次握手中的第2个报文,这个报文同时带ACK标志和SYN标 志。因此它表示对刚才客户端SYN报文的回应;同时又标志SYN给客户端,询问客户端是否准备好进行数据通 讯。

    3) 客户必须再次回应服务段一个ACK报文,这是报文段3

    2、连接终止协议(四次握手)
       由于TCP连 接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终 止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接 在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

     (1 TCP客 户端发送一个FIN,用来关闭客户到服务器的数据传送(报文段4)。
     (2) 服务器收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一 样,一个FIN将占用一个序号。
     (3) 服务器关闭客户端的连接,发送一个FIN给客户端(报文段6)。
     (4) 客户段发回ACK报文确认,并将确认序号设置为收到序号加1(报文段7)。

    CLOSED: 这个没什么好说的了,表示初始状态。

    LISTEN: 这个也是非常容易理解的一个状态,表示服务器端的某个SOCKET处 于监听状态,可以接受连接了。

    SYN_RCVD: 这个状态表示接受到了SYN报 文,在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本上用netstat你是很难看到这种状态的,除非你特意写了一个客户端测试程序,故意将三次TCP握手 过程中最后一个ACK报文不予发送。因此这种状态时,当收到客户端的ACK报文 后,它会进入到ESTABLISHED状态。

    SYN_SENT: 这个状态与SYN_RCVD遥想呼应,当客户端SOCKET执行CONNECT连接时,它首先发送SYN报文,因此也随即它会进入到了SYN_SENT状态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。

    ESTABLISHED:这个容易理解了,表示连接已经建立了。

    FIN_WAIT_1: 这个状态要好好解释一下,其实FIN_WAIT_1FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报 文。而这两种状态的区别是:FIN_WAIT_1状态实际上是当SOCKETESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况 下,无论对方何种情况下,都应该马上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。

    FIN_WAIT_2:上面已经详细解释了这种状态,实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点 数据需要传送给你,稍后再关闭连接。

    TIME_WAIT: 表示收到了对方的FIN报 文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标 志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。

    CLOSING: 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发 送FIN报文后,按理来说是应该先收到(或同时收到)对方的ACK报 文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报 文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一 个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接。

    CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一 个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文 给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话, 那么你也就可以close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。

    LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报 文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。

    最后有2个问题 的回答,我自己分析后的结论(不一定保证100%正确)

    1、 为什么建立连接协议是三次握手,而关闭连接却是四次握手呢?

    这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACKSYNACK起 应答作用,而SYN起同步作用)放在一个报文里来发送。但关闭连接时,当收到对方的FIN报文 通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报文 和FIN报文多数情况下都是分开发送的。

    2、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状 态?

    这是因为:虽然双方 都同意关闭连接了,而且握手的4个报文也都协调和发送完毕,按理可以直接回到CLOSED状 态(就好比从SYN_SEND状态到ESTABLISH状态那样);但是因为我们必须要假想网络是不可靠的,你无法保证你最后发送的ACK报 文会一定被对方收到,因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文,而重发FIN报 文,所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报 文,并保证于此。

     

     

     

     


     

            断开连接的时候, 当发起主动关闭的左边这方发送一个FIN过去后,
    右边被动关闭的这方要回应一个ACK,这个ACK是TCP回应的,而不是应用程序发送的,
    此时,被动关闭的一方就处于CLOSE_WAIT状态了。


    如果此时被动关闭的这一方不再继续调用closesocket,那么他就不会发送接下来的FIN,导致自己老是处于CLOSE_WAIT。
    只有被动关闭的这一方调用了 closesocket,才会发送一个FIN给主动关闭的这一方,同时也使得自己的状态变迁为LAST_ACK。

    比如被动关闭的是客户端.

    当对方调用closesocket的时候,你的程序正在

    int nRet = recv(s,....);
    if (nRet == SOCKET_ERROR)
    {
    // closesocket(s);
    return FALSE;
    }

    很多人就是忘记了那句closesocket,这种代码太常见了。
    我的理解,
    当主动关闭的一方发送FIN到被动关闭这边后,被动关闭这边的TCP马上回应一个ACK过去,同时向上面应用程序提交一个ERROR,
    导致上面的SOCKET的send或者recv返回SOCKET_ERROR.

    正常情况下,如果上面在返回SOCKET_ERROR后调用了closesocket, 那么被动关闭的者一方的TCP就会发送一个FIN过去,自己的状态就变迁到LAST_ACK.

     


    服务器上出现大量的close_wait的例子和解决方法(例子从网上找的,基本差不多)

    oracle9i@RHEL3 oracle9i]$ /usr/sbin/lsof -i | grep 6800
    oracle    22725 oracle9i    3u IPv4 18621468       TCP RHEL3:6800 (LISTEN)
    oracle    22725 oracle9i    4u IPv4 18621469       TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT)
    oracle    22725 oracle9i    8u IPv4 18621568       TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT)
    oracle    22725 oracle9i    9u IPv4 18621578       TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT)
    oracle    22726 oracle9i    3u IPv4 18621468       TCP RHEL3:6800 (LISTEN)
    oracle    22726 oracle9i    4u IPv4 18621469       TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT)
    oracle    22726 oracle9i    8u IPv4 18621568       TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT)
    oracle    22726 oracle9i    9u IPv4 18621578       TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT)

    [oracle9i@RHEL3 oracle9i]$ kill -9 22725

    # 22725, 22726就是使用该6800端口的进程号(PID)。
    [oracle9i@RHEL3 oracle9i]$ /usr/sbin/lsof -i | grep 6800

    进程被kill时,会释放占用的所有链接句柄。

    该问题的出现原因网上到处都是,也就是Socket的Client端出现异常没有Close就退出了。

    展开全文
  • 面试官,不要再问我三次握手和四次挥手

    万次阅读 多人点赞 2019-10-08 09:55:58
    三次握手和四次挥手是各个公司常见的考点,也具有一定的水平区分度,也被一些面试官作为热身题。很多小伙伴说这个问题刚开始回答的挺好,但是后面越回答越冒冷汗,最后就歇菜了。 见过比较典型的面试场景是这样的: ...

    温馨提示:本篇文章会长期维护及更新,详情见:https://yuanrengu.com/2020/77eef79f.html

    面试相关文章推荐:

    三次握手和四次挥手是各个公司常见的考点,也具有一定的水平区分度,也被一些面试官作为热身题。很多小伙伴说这个问题刚开始回答的挺好,但是后面越回答越冒冷汗,最后就歇菜了。

    见过比较典型的面试场景是这样的:

    面试官:请介绍下三次握手
    求职者:第一次握手就是客户端给服务器端发送一个报文,第二次就是服务器收到报文之后,会应答一个报文给客户端,第三次握手就是客户端收到报文后再给服务器发送一个报文,三次握手就成功了。
    面试官:然后呢?
    求职者:这就是三次握手的过程,很简单的。
    面试官:。。。。。。
    番外篇:一首凉凉送给你

    记住猿人谷一句话:面试时越简单的问题,一般就是隐藏着比较大的坑,一般都是需要将问题扩展的。上面求职者的回答不对吗?当然对,但距离面试官的期望可能还有点距离。

    希望大家能带着如下问题进行阅读,收获会更大。

    1. 请画出三次握手和四次挥手的示意图
    2. 为什么连接的时候是三次握手?
    3. 什么是半连接队列?
    4. ISN(Initial Sequence Number)是固定的吗?
    5. 三次握手过程中可以携带数据吗?
    6. 如果第三次握手丢失了,客户端服务端会如何处理?
    7. SYN攻击是什么?
    8. 挥手为什么需要四次?
    9. 四次挥手释放连接时,等待2MSL的意义?

    三次握手和四次挥手.png

    1. 三次握手

    三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号,交换TCP窗口大小信息。

    刚开始客户端处于 Closed 的状态,服务端处于 Listen 状态。
    进行三次握手:

    • 第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

      首部的同步位SYN=1,初始序号seq=x,SYN=1的报文段不能携带数据,但要消耗掉一个序号。

    • 第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于 SYN_RCVD 的状态。

      在确认报文段中SYN=1,ACK=1,确认号ack=x+1,初始序号seq=y。

    • 第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后,也处于 ESTABLISHED 状态,此时,双方已建立起了连接。

      确认报文段ACK=1,确认号ack=y+1,序号seq=x+1(初始为seq=x,第二个报文段所以要+1),ACK报文段可以携带数据,不携带数据则不消耗序号。

    发送第一个SYN的一端将执行主动打开(active open),接收这个SYN并发回下一个SYN的另一端执行被动打开(passive open)。

    在socket编程中,客户端执行connect()时,将触发三次握手。

    三次握手.png

    1.1 为什么需要三次握手,两次不行吗?

    弄清这个问题,我们需要先弄明白三次握手的目的是什么,能不能只用两次握手来达到同样的目的。

    • 第一次握手:客户端发送网络包,服务端收到了。
      这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
    • 第二次握手:服务端发包,客户端收到了。
      这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
    • 第三次握手:客户端发包,服务端收到了。
      这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

    因此,需要三次握手才能确认双方的接收与发送能力是否正常。

    试想如果是用两次握手,则会出现下面这种情况:

    如客户端发出连接请求,但因连接请求报文丢失而未收到确认,于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,客户端共发出了两个连接请求报文段,其中第一个丢失,第二个到达了服务端,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达服务端,此时服务端误认为客户端又发出一次新的连接请求,于是就向客户端发出确认报文段,同意建立连接,不采用三次握手,只要服务端发出确认,就建立新的连接了,此时客户端忽略服务端发来的确认,也不发送数据,则服务端一致等待客户端发送数据,浪费资源。

    1.2 什么是半连接队列?

    服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列

    当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

    这里在补充一点关于SYN-ACK 重传次数的问题:
    服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传。如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。
    注意,每次重传等待的时间不一定相同,一般会是指数增长,例如间隔时间为 1s,2s,4s,8s…

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

    当一端为建立连接而发送它的SYN时,它为连接选择一个初始序号。ISN随时间而变化,因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器,每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送,而导致某个连接的一方对它做错误的解释。

    三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number),以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的,攻击者很容易猜出后续的确认号,因此 ISN 是动态生成的。

    1.4 三次握手过程中可以携带数据吗?

    其实第三次握手的时候,是可以携带数据的。但是,第一次、第二次握手不可以携带数据

    为什么这样呢?大家可以想一个问题,假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发 SYN 报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。

    也就是说,第一次握手不可以放数据,其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话,此时客户端已经处于 ESTABLISHED 状态。对于客户端来说,他已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没啥毛病。

    1.5 SYN攻击是什么?

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

    检测 SYN 攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击。

    netstat -n -p TCP | grep SYN_RECV
    

    常见的防御 SYN 攻击的方法有如下几种:

    • 缩短超时(SYN Timeout)时间
    • 增加最大半连接数
    • 过滤网关防护
    • SYN cookies技术

    2. 四次挥手

    建立一个连接需要三次握手,而终止一个连接要经过四次挥手(也有将四次挥手叫做四次握手的)。这由TCP的半关闭(half-close)造成的。所谓的半关闭,其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

    TCP 连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),客户端或服务端均可主动发起挥手动作。

    刚开始双方都处于ESTABLISHED 状态,假如是客户端先发起关闭请求。四次挥手的过程如下:

    • 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
      即发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN_WAIT1(终止等待1)状态,等待服务端的确认。
    • 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。
      即服务端收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),服务端进入CLOSE_WAIT(关闭等待)状态,此时的TCP处于半关闭状态,客户端到服务端的连接释放。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待2)状态,等待服务端发出的连接释放报文段。
    • 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
      即服务端没有要向客户端发出的数据,服务端发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),服务端进入LAST_ACK(最后确认)状态,等待客户端的确认。
    • 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。
      即客户端收到服务端的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),客户端进入TIME_WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,客户端才进入CLOSED状态。

    收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的,服务端通常执行被动关闭,不会进入TIME_WAIT状态。

    在socket编程中,任何一方执行close()操作即可产生挥手操作。
    image.png

    2.1 挥手为什么需要四次?

    因为当服务端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当服务端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉客户端,“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四次挥手。

    2.2 2MSL等待状态

    TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime),它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的,因为TCP报文段以IP数据报在网络内传输,而IP数据报则有限制其生存时间的TTL字段。

    对一个具体实现所给定的MSL值,处理的原则是:当TCP执行一个主动关闭,并发回最后一个ACK,该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失(另一端超时并重发最后的FIN)。

    这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间,定义这个连接的插口(客户的IP地址和端口号,服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。

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

    MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。

    为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。

    两个理由:

    1. 保证客户端发送的最后一个ACK报文段能够到达服务端

      这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,服务端超时重传FIN+ACK报文段,而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段,接着客户端重传一次确认,重新启动2MSL计时器,最后客户端和服务端都进入到CLOSED状态,若客户端在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到服务端重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则服务端无法正常进入到CLOSED状态。

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

      客户端在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。

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

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

    3. 总结

    《TCP/IP详解 卷1:协议》有一张TCP状态变迁图,很具有代表性,有助于大家理解三次握手和四次挥手的状态变化。如下图所示,粗的实线箭头表示正常的客户端状态变迁,粗的虚线箭头表示正常的服务器状态变迁。

    TCP状态变迁图.jpg

    以后面试官再问你三次握手和四次挥手,直接把这一篇文章丢给他就可以了,他想问的都在这里。

    参考:《TCP/IP详解 卷1:协议》


    个人公众号:猿人谷
    公众号会有更多关于面试、源码解读、架构设计、程序人生等干货!
    期待您的关注

    在这里插入图片描述

    展开全文
  • 包含以下个层次: 1. 链路层,也称作数据链路层或者网络接口层,通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆(或其他任何传输媒介)的物理接口细节。 2. 网络...
  • 我们都知道tcp连接是三次握手,断开连接是四次挥手,那么为什么是三次握手?四次挥手?我想不少人存在疑惑,本文将分为三部分进行详细讲解。 三次握手 注意以下几个问题 为什么一次握手不行? 为什么两次握手...
  • TCP三次握手及四次挥手详细图解

    千次阅读 2016-06-13 14:31:48
    TCP三次握手及四次挥手详细图解
  • 在面试中,三次握手和四次挥手可以说是问的最频繁的一个知识点了,我相信大家也都看过很多关于三次握手与四次挥手的文章,今天的这篇文章,重点是围绕着面试,我们应该掌握哪些比较重要的点,哪些是比较被面试官给问...
  • 建议首先了解三次握手和四次挥手过程再分析网络包信息:计算机网络传输层—TCP连接的建立和终止(详解三次握手四次挥手) 首先开启wireshark监听网口,然后访问了google,输入简单的过滤规则进行过滤,抓包如下: ...
  • tcp四次挥手,为什么是四次?

    万次阅读 多人点赞 2019-07-04 21:29:34
    四次挥手的原因;为什么要有TIME_WAIT状态?2MSL的的意义;四次挥手中如果有一次挥手失败怎么处理?
  • TCP三次和四次挥手过程1、TCP报文段首部2、TCP三次握手过程及常见问题2.1 TCP三次握手过程2.2 常见问题2、TCP四次挥手过程及问题2.1 TCP四次挥手过程2.2 常见问题 1、TCP报文段首部     &...
  • 四次挥手过程如下: 第一次挥手: 客户端向服务器发送一个 FIN 数据包(FIN = 1,seq = u)主动断开连接,报文中会指定一个序列号。 告诉服务器:我要跟你断开连接了,不会再给你发数据了; 客户端此时还是可以...
  • TCP三次握手,四次挥手这是一个非常重要的知识点,我也来总结一下。 关于面试最经常问的问题无非就是: 握手为什么是3次? 2次可以吗? 为什么不是4次呢? 你能不能详细的介绍一下TCP三次握手的详细过程? 能不能说...
  • TCP的三次握手与四次挥手理解及面试题(很全面)

    万次阅读 多人点赞 2018-07-17 20:56:17
    四次挥手过程理解  1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1...
  • 这就造成了四次挥手。 如果是三次挥手会有什么问题? 等于说服务端将ACK和FIN的发送合并为一次挥手,这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端,从而让客户端不断的重发FIN。 不断的进行数据包...
  • 1. 为什么四次挥手? 为什么连接的时候是三次握手,关闭的时候却是四次握手? 答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是...
  • 基于ajax请求过程分析Http协议的三次握手和四次挥手过程。 基于ajax请求过程分析Http协议的三次握手和四次挥手过程 基于ajax请求过程分析Http协议的三次握手和四次挥手过程 基于ajax请求过程分析Http协议的三次握手...
  • TCP四次挥手过程

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

    2019-07-25 16:18:52
    TCP的三次握手和四次挥手通常同时被谈起,上篇文章我们说到了TCP的三次握手,那么四次挥手又是什么呢? 今天我们就聊聊什么是四次挥手。在说什么是四次挥手之前,我们还是要提出几个问题。 1.为什么要挥手那么...
  • 案例测试TCP的三次握手和四次挥手过程。包括C语言写的服务器端程序以及c#写的客户端程序,以及使用wirkshark进行的网络抓包分析TCP三次握手四次挥手的过程。
  • 三次握手与四次挥手过程详解三次握手建立连接:传输数据过程:四次握手断开连接:常见面试问题: TCP通信过程包括三个步骤:建立TCP连接通道,传输数据,断开TCP连接通道 上图主要包括三部分:建立连接、传输数据、...
  • TCP四次挥手

    2019-07-27 15:34:59
    TCP四次挥手为什么要挥手挥手的过程与状态为什么是四次 为什么要挥手 上一节我们知道TCP是全双工传输类型,所以在断开链接也需要双方都断开连接才可以。断开连接需要保证2个要点 连接的双方都能断开 连接的双发数据...
  • 描述TCP三次握手,四次挥手过程的图片
  • 三次握手四次挥手

    2019-10-17 15:49:39
    简明理解三次握手和四次挥手 三次握手与四次挥手分别对应TCP连接建立过程与断开过程,先上TCP报文格式:  ...
  • 四次挥手

    2020-03-25 21:05:15
    四次挥手过程 第一次挥手 客户端向服务端发出连接释放报文段(FIN=1),并停止再发送数据,设置其序列号为seq=u,它等于前面已传过的数据的最后一个字节的序号加1。这时客户端进入FIN-WAIT-1(终止等待1)状态,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 43,393
精华内容 17,357
关键字:

四次挥手详细过程