精华内容
下载资源
问答
  • TCP 三次握手和四次挥手,面试题详解,图文并茂,欢迎技术交流
  • TCP三次握手和四次挥手不管是在开发还是面试中都是一个非常重要的知识点,它是我们优化web程序性能的基础。欢迎学习,一起进步 文章目录一.TCP简介二.TCP数据报结构三.TCP的三次握手四.TCP的四次挥手 一.TCP简介 TCP...
  • TCP三次握手和四次挥手 相对于SOCKET开发者,TCP创建过程链接折除过程是由TCP/IP协议栈自动创建的。因此开发者并不需要控制这个过程.但是对于理解TCP底层运作机制,相当有帮助。 这里简单的介绍一下各个标志位...

    TCP三次握手和四次挥手

    相对于SOCKET开发者,TCP创建过程和链接折除过程是由TCP/IP协议栈自动创建的。因此开发者并不需要控制这个过程.但是对于理解TCP底层运作机制,相当有帮助。

                         

    这里简单的介绍一下各个标志位:

                        字段                          含义
            URG(urgent紧急) 紧急指针是否有效。为1,表示某一位需要被优先处理
    ACK(acknowledgement 确认)  确认号是否有效,一般置为1。
               PSH(push传送)提示接收端应用程序立即从TCP缓冲区把数据读走。
               FIN(finish结束)希望断开连接。
               RST(reset重置) 对方要求重新建立连接,复位。
    SYN(synchronous建立联机)请求建立连接,并在其序列号的字段进行序列号的初始值设定。建立连接,设置为1

    TCP的三次握手:

    所谓三次握手(Three-way Handshake),是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。

    三次握手的目的是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。在socket编程中,客户端执行connect()时。将触发三次握手。

                                      

    第一次握手:客户端发送一个SYN位置1的数据包到服务器,并进入SYN_SENT状态,等待服务器确认。

                                        

    第二次握手:服务器收到数据包并发回SYN标志位和ACK标志位均为1的确认包(ACK)应答。此时服务器进入SYN_RECV状态。

                                        

    第三次握手:客户端收到服务器发送的确认包,再次发送SYN标志位为0,ACK标志位为1的确认包。此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

    **SYN攻击**
    在三次握手过程中,服务器发送SYN-ACK之后,收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后,服务器转入ESTABLISHED状态.
    Syn攻击就是客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送syn包,服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直 至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。
    Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
    netstat -n -p TCP | grep SYN_RECV
    一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击,修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
    但是不能完全防范syn攻击。

     

    TCP四次挥手:

    TCP的连接的拆除需要发送四个包,因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作,在socket编程中,任何一方执行close()操作即可产生挥手操作。

                                  

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

    第一次挥手:客户端进程发出FIN=1的连接释放报文,并停止发送数据,用来关闭客户端到服务器的数据传送。

    第二次挥手:服务器收到连接释放报文,发出确认报文ACK。客户端收到服务器的确认请求后,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)

    第三次挥手:服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,等待客户端的确认。

    第四次挥手:客户端收到服务器的连接释放报文后,发出确认。服务器只要收到了客户端发出的确认,立即进入CLOSED状态。

    常见面试题:

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

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

    2. 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

    答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。

    3. 为什么不能用两次握手进行连接?

    答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。

           现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。

    4. 如果已经建立了连接,但是客户端突然出现故障了怎么办?

    TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
     

    • TCP协议和UDP协议的区别是什么
      • TCP协议是有连接的,有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接,会话结束之后也要结束连接。而UDP是无连接的
      • TCP协议保证数据按序发送,按序到达,提供超时重发来保证可靠性,但是UDP不保证按序到达,甚至不保证到达,只是努力交付,即便是按序发送的序列,也不保证按序送到。
      • TCP协议所需资源多,TCP首部需20个字节(不算可选项),UDP首部字段只需8个字节。
      • TCP有流量控制和拥塞控制,UDP没有,网络拥堵不会影响发送端的发送速率
      • TCP是一对一的连接,而UDP则可以支持一对一,多对多,一对多的通信。
      • TCP面向的是字节流的服务,UDP面向的是报文的服务。

    TCP流量控制和拥塞控制

    参考出处:https://www.cnblogs.com/zmlctt/p/3690998.html

                      https://blog.csdn.net/qq_38950316/article/details/81087809

    感谢两位的分享!

    展开全文
  • TCP协议是很有讲究的。推荐先了解基础原理。从最基础的原理开始了解,欢迎大家一起学习。
  • TCP三次握手和四次挥手详解(面试常见问题)

    万次阅读 多人点赞 2019-05-16 23:06:51
    大概两个月前,一位朋友在面试360集团时,在面试过程中被问及TCP三次握手和四次挥手的相关知识,他当时只知道大概,但当时面试官问他TCP三次握手过程中发送的数字是多少,他一下子就懵住了,因为这也是他第一次参加...

      大概两个月前,一位朋友在面试360集团时,在面试过程中被问及TCP三次握手和四次挥手的相关知识,他当时只知道大概,但当时面试官问他TCP三次握手过程中发送的数字是多少,他一下子就懵住了,因为这也是他第一次参加面试,准备的并不充分,也根本没想到会问到具体发送的数字,结果显而易见,最后被刷了。由此可见,TCP三次握手和四次挥手在面试中是面试官非常喜欢的问题,所以掌握这个知识是十分重要的。

      TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP的运输连接有三个过程,即建立连接数据传输连接释放。

      TCP连接建立过程中要解决以下三个问题:

      (1):要使每一方都能够确认对方的存在。

      (2):要允许双方协商一些参数

      (3):能够对运输实体资源进行分配

       TCP连接的建立采用客户机/服务器模式,主动发起连接建立的应用进程叫做客户机,而被动等待连接建立的应用进程叫做服务器。

       TCP的连接建立:

      1.首先,客户机与服务器的TCP进程都处于CLOSED(关闭)状态,当要进行TCP连接时,客户机主动打开连接服务器被动打开连接(这是因为服务请求总是由客户机向服务器发起,因为想要请求的资源都在服务器上,所以客户机想要获取资源就必须主动向服务器发起请求,而不能是等待服务器向自己(客户机)发起请求)。

       2.然后,服务器的TCP进程先创建传输控制块TCB(传输控制块TCB存储了每一个连接中的重要信息,如:TCP连接表,指向发送和接收缓存的指针,指向重传队列的指针,当前的发送和接收序号,等等),此时,服务器就处于LISTEN(收听)状态。同样的,客户机也会首先创建一个传输控制块TCB发送给服务器。这样,准备工作就做好了。

      3.现在就可以开始真正的三次握手了。首先,客户机先向服务器发送连接请求报文段,该报文段中将首部中的同步位SYN置为1(只有当SYN置为1时,才能表明客户机想要和服务器建立连接),并且随机选择一个初始序号x,注意此时的SYN数据报中并没有携带数据,但是仍旧要消耗掉一个序号(意思就是下次客户机发送数据的时候,序号为x+1),此时客户机进入到SYN-SENT(同步已发送)状态。

      4.此时,服务器收到客户机的请求时,如果同意与该客户机进行连接,则需要向客户机发送确认报文。在发送报文中需要将SYN与ACK都置为1(当ACK置为1时,表明服务器同意与客户机进行连接;同时将SYN置为1,表明服务器想要和客户机建立连接),并且随机选择一个初始序号y,确认号为x+1(确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号,因为之前发送了x,所以下一个序号为x+1),注意此时的SYN数据报中并没有携带数据,但是也要消耗掉一个序号(同样的,也就是说服务器下次发送数据的时候,序号为y+1),此时TCP服务器进程进入到SYN-RCVD(同步收到)阶段。

      顺便提一句,在这两个阶段会发送SYN Flooding攻击,可以看本人另外一篇博客SYN Flooding攻击

           5.TCP客户端收到服务器的确认后,还要再向服务器给出确认。确认报文段中ACK置为1,确认号为ack=y+1(因为之前服务器给客户机发送的序号为y,因此现在客户机向服务器发送的确认号为ack=y+1,意思是客户机渴望收到的下一个报文段的第一个数据字节为y+1)此时客户机的发送序号为x+1(这是因为刚才刚才客户机向服务器发送连接请求时消耗了序号x,因此此时的序号为x+1)注意:在进行第三次握手时,ACK报文段可以携带数据,也可以不携带数据,如果携带数据,则消耗一个序列,这样客户机下次发送报文段时的序号为x+2,如果不携带数据则不消耗序号,下次客户机发送报文段时的序号为x+1。这时TCP连接已经建立,客户机和服务器都进入到ESTABLISHED(已建立连接)状态。

      其实上面的三次握手实质上就相当于是下列的对话:

    -客户机:服务器,我想要和你建立连接,你同意吗?(SYN=1)

    -服务器:客户机,我同意和你建立连接(ACK=1);我也想和你建立连接,你同意吗?(SYN=1)

    -客户机:服务器,我同意和你建立连接。(ACK=1)

    .  其实,在进行第二次握手时(即服务器向客户机进行应答时),可以看作时发了两次包,先回答客户机的服务请求(ACK=1,ack=x+1),然后再向客户机发出请求(SYN=1,seq=y)

    常见面试问题:

    问:三次握手中,为什么客户机最后还要再向服务器发送一次确认呢?

    答:这是为了防止已失效的连接请求报文段突然又传到了服务器。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常的情况,客户机发出连接请求,但因为连接请求报文丢失而未收到确认。于是客户机再重传了一次连接请求,后来收到了确认,建立了连接。数据传输完后,就释放了连接。客户机共发送了两个连接请求报文段,其中第一个丢失,第二个到达了服务器,没有所谓的“已失效的连接请求报文段”。

      但是如果出现了一种异常情况,即客户机发出的第一个报文段并没有丢失,而是在某个节点上长时间滞留了,直至客户机向服务器发送了第二个报文段并且已经完成数据传输释放了连接,此时,第一个报文到达服务器后会被误以为是客户机重新发起的一次连接请求,实质上是一个早已失效的连接请求。如果没有第三次握手,那么这个连接就建立了,但是客户机并不会向服务器发送任何请求,这样连接就会一直持续,白白的消耗网络资源。

    TCP的连接释放:

      1.数据传输结束后,通信的双方都可以释放连接。此时,客户机和服务器都处于ESTABLISHED(已建立连接)状态

      2.假设客户机请求完资源了,想要释放连接。首先,客户机的应用进程先向服务器发出连接释放报文段,该报文段中将首部的终止控制位FIN置为1(只有当FIN置为1时,才能表明客户机想要和服务器断开连接),并且序号为u(注意:此时的u不是随机产生的,而是之前客户机传送的数据的最后一个字节的序号加1。此时客户机进入到FIN-WAIT-1(终止等待1)状态,等待服务器的确认。

      3.服务器收到连接释放报文后发出确认,在发送报文中将首部中的ACK置为1(ACK置为1,表面服务器同意与客户机释放连接),并且产生序号v(注意:此时的v不是随机产生的,而是之前服务器传送的数据的最后一个字节的序号加1),并且发出确认号为u+1(确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号,因为之前发送了u,所以下一个序号为u+1)。此时服务器就进入CLOSE-WAIT(关闭等待)状态,客户机进入FIN-WAIT-2状态。

            此时,从客户机到服务器这个方向的连接就被释放了,也就是说,客户机已经没有数据要向服务器发送了,但是如果服务器向客户机发送数据,客户机仍要接收数据。也就是说:从客户机到服务器的连接已经被释放了,但是从服务器到客户机的连接还没被释放。此时,TCP连接处于半关闭状态。

            4.如果服务器向客户机也没有要发送的数据的话,那么服务器的应用进程就可以向客户机发出连接释放报文段(注意此时还是服务器向客户机发送数据),该报文段中将首部的终止控制位FIN置为1(只有当FIN置为1时,才能表明客户机想要和服务器断开连接),ACK也置为1,并且序号为w(重点注意,此时的w不一定等于v+1。如果在客户机释放了连接之后,服务器向客户机仍旧发送了一部分数据,那么此时w不等于v+1,但是如果期间没有再发送数据,那么w就等于v+1。总而言之,这个w等于服务器上一次发送的数据的最后一个字节加1),并且发送确认号为u+1(确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号,因为之前发送了u,所以下一个序号为u+1)。此时服务器就进入了LAST-ACK(最后确认)状态。

           5.客户机收到服务器的连接释放报文后,必须对此报文进行确认。在该报文段中将ACK置为1,确认号为w+1(确认号表明服务器渴望收到的下一个报文段的第一个数据字节的序号,因为之前发送了w,所以下一个序号为w+1),产生序号为u+1(因为上一个发送的数据的序号为u)。此时服务器进入到TIME-WAIT(等待时间)状态。但是,此时TCP连接还没有被释放掉。必须经过2MSL后服务器才能进入到CLOSED状态。(注:MSL叫做最长报文段寿命,RFC建议为两分钟,也就是说,要经过四分钟才能进入到CLOSED状态)。

    其实上面的四次挥手实质上就相当于是下列的对话:

    -客户机:服务器,我想和你断开连接,你同意吗?(FIN=1)

    -服务器:我同意(ACK=1)

    (在此期间,服务器可能还会向客户机发送数据,但是客户机却不能再向服务器发送数据)

    -服务器:客户机,我想要和你断开连接,你同意吗?(FIN=1)

    -客户机:我同意。(ACK=1)

    再等待2MSL时间后就真正断开了连接。

    常见面试问题:

    问:为什么客户机发送完最后一个数据后要在TIME-WAIT状态等待 2MSL(四分钟)的时间呢?

    答:第一:为了保证客户机最后发送的那个ACK报文段能够到达服务器。这个ACK报文段可能会丢失。因而使处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。服务器会超时重传这个FIN+ACK报文段,而客户机就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着客户机重传一次确认,重新启动2MSL计时器,最后客户机和服务器都可以进入到CLOSED(关闭)状态。如果没有2MSL等待时间,那么就无法收到重传的FIN+ ACK包,无法进入正常的CLOSED状态。

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

    总结:再三次握手和四次挥手中这些数字都比较重要,最好都记住,以防后面会用到。

    展开全文
  • 建议首先了解三次握手四次挥手的过程再分析网络包信息:计算机网络传输层—TCP连接的建立终止(详解三次握手四次挥手) 首先开启wireshark监听网口,然后访问了google,输入简单的过滤规则进行过滤,抓包如下: ...

    从wireshark抓包来分析TCP三次握手和四次挥手

    建议首先了解三次握手和四次挥手的过程再分析网络包信息:计算机网络传输层—TCP连接的建立和终止(详解三次握手四次挥手)

    首先开启wireshark监听网口,然后访问了google,输入简单的过滤规则进行过滤,抓包如下:
    在这里插入图片描述

    通过筛选主机的IP和TCP协议得到了初步筛选结果,可以看到简要信息中,标记处有SYN报文,SYN报文是三次握手的标志性报文,因此标记的三个报文就是三次握手报文,对此进行详细分析。

    第一次握手报文分析:
    在这里插入图片描述
    在这里插入图片描述

    也就是说,第一个包中SYN位置为1,表示要和目的主机同步序列号,同时附加有MSS信息以及窗口大小信息等

    第二次握手信息分析:
    在这里插入图片描述
    在这里插入图片描述

    第三次握手分析:
    在这里插入图片描述
    在这里插入图片描述

    完成三次握手后,就建立了TCP连接,之后就可以正常的进行数据发送和接收。

    当完成数据发送后,双方要结束对话,由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭,故需要经过四次挥手完成TCP的断开。

    首先找到四次挥手报文,标志就是 FIN
    在这里插入图片描述
    可以看到,源和目的分别发送了一个FIN报文,加上对应的ACK,就是四次挥手结束连接。
    第一次挥手:
    在这里插入图片描述
    第二次挥手:
    在这里插入图片描述
    第三次挥手和第四次挥手与前两次基本一致:
    在这里插入图片描述
    在这里插入图片描述
    至此,对TCP三次挥手和四次挥手的报文分析完成。

    展开全文
  •   简述TCP三次握手和四次挥手的过程理解   在讲解之前先来熟悉一下TCP报文头部   源端口、目标端口:计算机上的进程要其他进程通信是要通过计算机端口的, 而一个计算机端口某个时刻只能被一个进程占用,...

      简述TCP三次握手和四次挥手的过程和理解

      在讲解之前先来熟悉一下TCP报文头部

    在这里插入图片描述
      源端口、目标端口:计算机上的进程要和其他进程通信是要通过计算机端口的, 而一个计算机端口某个时刻只能被一个进程占用,所以通过指定源端口和目标 端口,就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的, 可推算计算机的端口个数为2^16个。

      序列号:表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的字节流的每一个字节都会按顺序编号。由于序列号由32位表示,所以每2^32个 字节,就会出现序列号回绕,再次从 0 开始。

      确认号:表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。 也就是告诉发送方:我希望你(指发送方)下次发送的数据的第一个字节数据 的编号为此确认号。

      数据偏移:表示TCP报文段的首部长度,共4位,由于TCP首部包含一个长度可 变的选项部分,需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数 据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为 计算单位),4位二进制最大表示15,所以数据偏移也就是TCP首部最大60字节。

      URG:表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段(urgent pointer)只有当URG=1时才有效。

      ACK:表示是否前面确认号字段是否有效。只有当ACK=1时,前面的确认号字段才有效。 TCP规定,连接建立后,ACK必须为1,带ACK标志的TCP报文段称为确认报文段。

      PSH:提示接收端应用程序应该立即从TCP接收缓冲区中读走数据,为接收后续数据腾出空 间。如果为1,则表示对方应当立即把数据提交给上层应用,而不是缓存起来,如果应用程序 不将接收到的数据读走,就会一直停留在TCP接收缓冲区中。

      RST:如果收到一个RST=1的报文,说明与主机的连接出现了严重错误(如主机崩溃),必 须释放连接,然后再重新建立连接。或者说明上次发送给主机的数据有问题,主机拒绝响应, 带RST标志的TCP报文段称为复位报文段。

      SYN:在建立连接时使用,用来同步序号。当SYN=1,ACK=0时,表示这是一个请求建立连 接的报文段;当SYN=1,ACK=1时,表示对方同意建立连接。SYN=1,说明这是一个请求 建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1,带SYN标志的TCP报文 段称为同步报文段。

      FIN:表示通知对方本端要关闭连接了,标记数据是否发送完毕。如果FIN=1,即告诉对方: “我的数据已经发送完毕,你可以释放连接了”,带FIN标志的TCP报文段称为结束报文段。

    三次握手过程

    在这里插入图片描述
      1.第一次握手:客户机将标志位SYN置为1,随机产生一个值seq=x,并将该数据包发送给服务器,客户机进入SYN_SENT状态,等待服务器确认。

      2.第二次握手:服务器收到数据包后,由标志位SYN=1知道客户机请求建立连接,服务器将标志位SYN和ACK都置为1,ack=x+1,随机产生一个值seq=y,并将该数据包发送给客户机以确认连接请求,服务器进入SYN_RCVD状态。

      3.第三次握手:客户机收到确认后,检查ack是否为x+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=y+1,并将该数据包发送给服务器,服务器检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,客户机和服务器进入ESTABLISHED状态,完成三次握手,随后客户机与Se服务器之间可以开始传输数据了。

    四次挥手

    在这里插入图片描述
      1.第一次挥手:客户机发送一个FIN,用来关闭客户机到服务器的数据传送,客户机进入FIN_WAIT_1状态。

      2.第二次挥手:服务器收到FIN后,发送一个ACK给客户机,确认序号为收到序号+1,则服务器进入CLOSE_WAIT状态。

      3.第三次挥手:服务器发送一个FIN,用来关闭服务器到客户机的数据传送,服务器进入LAST_ACK状态。

      4.第四次挥手:客户机收到FIN后,客户机进入TIME_WAIT状态,接着发送一个ACK给服务器,确认序号为收到序号+1,服务器进入CLOSED状态,完成四次挥手。

      注意:TCP连接时全双工的,每个方向都必须要单独进行关闭。这一原则是当一方完成数据发送任务后,发送一个FIN来终止本方向的连接,收到一个FIN只是意味着发送方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到另一方向也发送了FIN,这个循环才会终止。首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭。

    展开全文
  • 在建立TCP的过程中,会用到三次握手四次挥手,三次握手四...那么在TCP协议编程的过程中,哪一步用到了三次握手四次挥手?通过一张图来看一下: 这是一个利用TCP构建的一个C/S模型,这里只做简略介绍(Java构建C...
  • 简述TCP三次握手和四次挥手流程

    千次阅读 2018-07-14 15:30:32
    关于TCP的连接过程,很多从事程序开发的小伙伴应该都听过三次握手,可这三次握手的细节还是有很多人不太清楚的,特别是有些参数记不清楚,我也经常弄错,所以我根据自己的理解画了两张图,将TCP连接断开的流程简单...
  • 简述TCP三次握手和四次挥手过程

    万次阅读 多人点赞 2018-03-06 09:31:00
    TCP握手协议 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认; SYN:同步序列编号(Synchronize ...
  • 经常在前端的面试群中发现有人会碰到面试官去询问tcp的握手挥手问题,诸如你了解tcp吗,解释一下tcp三次握手和四次挥手,我认为如果只是简单的了解这2个问题,真的那么有意义吗?所以,不防试着去多了解一点网络...
  • TCP三次握手和四次挥手详解 --- 转载

    千次阅读 2020-08-09 20:20:30
    文章目录 1、三次握手 1.1connect()、listen()accept()三者之间的关系 1.1三次握手的过程 1.2三次握手的状态转换安全问题 ... 3.1TCP编程中三次握手和四次挥手的全过程 3.2TCP状态..
  • TCP/IP协议中,TCP三次握手和四次挥手机制 这个问题必问,你就说是不是吧。看了一些资料讲解视频,整理下。 上部分是比较详细的讲解,“专业范”, 下部分是比较通俗的讲解,“易懂范”。 面试根据自己情况,想...
  • 案例测试TCP的三次握手四次挥手过程。包括C语言写的服务器端程序以及c#写的客户端程序,以及使用wirkshark进行的网络抓包分析TCP三次握手四次挥手的过程。
  •  TCP连接的建立需要经过三次握手,连接的关闭需要经过四次挥手。读TCP/IP协议不是很好理解,通过工具手动抓包分析会对协议有更深刻的理解。因为工作中经常用到wireshark,所以就通过wireshark来分析,记录自己的...
  • 【动画详解】TCP 三次握手和四次挥手图文详解

    万次阅读 多人点赞 2019-09-03 21:44:00
    TCP/IP 协议可以说是整个互联网的基石。” 01 — TCP 是什么? 为了直接认识 TCP 是什么,直接在命令行执行: tcpdump是在linux下的一款很好用的抓包工具,(运行此命令需要...
  • 该文档详细描述了wireshark抓包分析tcp三次握手四次挥手详解及网络命令,亲自整理,适合新手借鉴
  • 说明:系统是windos10的,调用http接口来看TCP三次握手的连接及四次挥手的过程。 wireshark安装很好安装,官网下载自己系统的版本然后下载一键默认安装即可,安装完毕双击启动。就是如下图片: 也可以点击菜单...
  • TCP三次握手和四次挥手的全过程
  • TCP三次握手和四次挥手是计算机网络中很经典的问题,作为互联网的开发者们必须掌握的问题,也是面试高频题。 本篇对该问题做了详细的解释,并且把常用面试题进行了总结
  • TCP三次握手和四次挥手的全过程  TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接: 位码即tcp标志位,有8种表示: SYN(synchronous建立联机) ACK(acknowledgement 确认) ...
  • TCP三次握手和四次挥手详解.docx
  • 描述TCP三次握手四次挥手的过程的图片
  • TCP三次握手建立链接过程 我们知道TCP建立链接之前需要三次握手,那考虑一个问题,server端收到client的SYN请求后并进行ACK确认后为什么还要等待client的确认呢?两次就行了,为什么需要进行三次握手? 答:这主要是...
  • TCP三次握手四次挥手这是一个非常重要的知识点,我也来总结一下。 关于面试最经常问的问题无非就是: 握手为什么是3次? 2次可以吗? 为什么不是4次呢? 你能不能详细的介绍一下TCP三次握手的详细过程? 能不能说...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 55,483
精华内容 22,193
关键字:

tcp三次握手和四次挥手