三次握手 订阅
所谓的“三次握手”:为了对每次发送的数据量进行跟踪与协商,确保数据段的发送和接收同步,根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系,并建立虚连接。 [1]  为了提供可靠的传送,TCP在发送新的数据之前,以特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。 [1] 展开全文
所谓的“三次握手”:为了对每次发送的数据量进行跟踪与协商,确保数据段的发送和接收同步,根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系,并建立虚连接。 [1]  为了提供可靠的传送,TCP在发送新的数据之前,以特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。 [1]
信息
外文名
Three-way handshake
别    称
TCP握手协议
应用学科
计算机传输协议
中文名
三次握手
适用领域范围
计算机
三次握手简介
为了建立连接TCP连接,通信双方必须从对方了解如下信息: [2]  1、对方报文发送的开始序号。 [2]  2、对方发送数据的缓冲区大小。 [2]  3、能被接收的最大报文段长度MSS。 [2]  4、被支持的TCP选项。 [2]  在TCP协议中,通信双方将通过三次TCP报文段彭对以上信息的了解,并在此基础上建立一个TCP连接,而通信双方的三次TCP报文段的交换过程,也就是通常所说的TCP连接建立实现的三次握手(Three-Way Handshake)过程。 [2]  当连接建立完成之后,则: [2]  1、TCP连接的通信双方均可知道连接上对方将被发送的第一个字节的序列号(发给对方的确认号,A发给B的确认号就是B将发送的序列号,同样B也是); [2]  2、双方均可知道连接上能发送的MSS,从而即可选取握手阶段双方交换的SYN报文和SYN+ACK报文中MSS选项中较小的值作为实际值; [2]  3、双方均可知道对方的接收缓冲区大小; [2]  4、双方均可知道对方能否使用SACK、窗口缩放等选项。 [2]  基于这些信息,双方即可建立一个TCP连接(x,y)并基于该连接开始报文段的传输。 [2]  采用三次握手法建立TCP连接,如果有两台主机同时企图在同样的套接字之间建立一个连接,则结果将只有一个连接被建立起来(这两个连接被看作完全相同,即为同一个连接),因为所有的连接都是由它们的端点来标识的。若第一个请求导致建立了一个由(x,y)标识的连接,而第二个请求也建立了一个由(X,y)标识的连接,则在TCP实体内部只会存在一个TCP连接表项(x,y)。 [2] 
收起全文
精华内容
参与话题
问答
  • TCP三次握手详解-深入浅出(有图实例演示)

    万次阅读 多人点赞 2018-08-08 21:13:48
    TCP三次握手 TCP三次握手简单如下图: TCP三次握手的过程描述: 1.客户主动(active open)去connect服务器,并且发送SYN 假设序列号为J, 服务器是被动打开(passive open) 2.服务器在收到SYN后,它...

    TCP是属于网络分层中的传输层,因为OSI分为7层,感觉太麻烦了,所以分为四层就好了,简单。
    分层以及每层的协议,TCP是属于传输层,如下两张图:
    图1
    这里写图片描述

    TCP三次握手会涉及到状态转换所以这里贴出TCP的状态转换图如下:
    这里写图片描述

    TCP三次握手简述

    TCP三次握手如图:
    这里写图片描述

    第一次握手

    客户主动(active open)去connect服务器,并且发送SYN 假设序列号为J,
    服务器是被动打开(passive open)

    第二次握手

    服务器在收到SYN后,它会发送一个SYN以及一个ACK(应答)给客户,
    ACK的序列号是 J+1表示是给SYN J的应答,新发送的SYN K 序列号是K

    第三次握手

    客户在收到新SYN K, ACK J+1 后,也回应ACK K+1 以表示收到了,
    然后两边就可以开始数据发送数据了

    使用tcpdump观察如下:因为都是在本机同时运行client和server所以命令为:tcpdump -i lo port 5555, 只能监听回路lo接口,结果如下
    这里写图片描述
    如图用红色圈起来的就是3次握手,但是为什么最后一次握手,为什么ack = 1,而不是369535922 呢,
    这是因为这里的第三次握手tcpdump显示的是相对的顺序号。但是为了便于观察我们需要把tcpdump的
    顺序号变为绝对的顺序号。

    命令只需要加-S(大写)便可,即:tcpdump -i lo port 5555 -S
    加上之后结果就正常了如下图:
    这里写图片描述
    从tcpdump的数据,可以明显的看到三次握手的过程是:
    第一次握手:client syn 2322326583 —> server
    第二次握手:server syn 3573692787, ack 2322326583 + 1 —> client
    第三次握手:client ack 3573692787 + 1 -->server

    TCP三次握手详细解析过程:

    这里写图片描述

    第一次握手

    客户在socket() connect()后主动(active open)连接上服务器, 发送SYN ,这时客户端的状态是SYN_SENT
    服务器在进行socket(),bind(),listen()后等待客户的连接,收到客户端的 SYN 后,

    1.半连接队列(syn queue)未满

    服务器将该连接的状态变为SYN_RCVD, 服务器把连接信息放到半连接队列(syn queue)里面。

    2.半连接队列(syn queue)已满

    服务器不会将该连接的状态变为SYN_RCVD,且将该连接丢弃(SYN flood攻击就是利用这个原理,
    对于SYN foold攻击,应对方法之一是使syncookies生效,将其值置1即可,路径/proc/sys/net/ipv4/tcp_syncookies,
    即使是半连接队列syn queue已经满了,也可以接收正常的非恶意攻击的客户端的请求,
    但是这种方法只在无计可施的情况下使用,man tcp里面的解析是这样说的,
    这里写图片描述
    但是我不知道为什么Centos6.9默认是置为1,所以这让我很疑惑
    这里写图片描述)。
    半连接队列(syn queue)最大值 /proc/sys/net/ipv4/tcp_max_syn_backlog
    这里写图片描述
    SYN flood攻击

    攻击方的客户端只发送SYN分节给服务器,然后对服务器发回来的SYN+ACK什么也不做,直接忽略掉,
    不发送ACK给服务器;这样就可以占据着服务器的半连接队列的资源,导致正常的客户端连接无法连接上服务器。-----[维基百科]

    (SYN flood攻击的方式其实也分两种,第一种,攻击方的客户端一直发送SYN,对于服务器回应的SYN+ACK什么也不做,不回应ACK, 第二种,攻击方的客户端发送SYN时,将源IP改为一个虚假的IP, 然后服务器将SYN+ACK发送到虚假的IP, 这样当然永远也得不到ACK的回应。)

    第二次握手

    服务器返回SYN+ACK给到客户端,客户端收到SYN+ACK后,状态从SYN_SENT变为ESTABLISHED,
    也即是connect()函数的返回。

    第三次握手

    全连接队列(accept queue)的最大值 /proc/sys/net/core/somaxconn (默认128)
    这里写图片描述
    全连接队列值 = min(backlog, somaxconn)
    这里的backlog是listen(int sockfd, int backlog)函数里面的那个参数backlog

    1.全连接队列(accept queue)未满

    服务器收到客户端发来的ACK, 服务端该连接的状态从SYN_RCVD变为ESTABLISHED,
    然后服务器将该连接从半连接队列(syn queue)里面移除,且将该连接的信息放到全连接队列(accept queue)里面。

    2.全连接队列(accept queue)已满

    服务器收到客户端发来的ACK, 不会将该连接的状态从SYN_RCVD变为ESTABLISHED。
    当然全连接队列(accept queue)已满时,则根据 tcp_abort_on_overflow 的值来执行相应动作
    /proc/sys/net/ipv4/tcp_abort_on_overflow 查看参数值
    这里写图片描述

    2.1 tcp_abort_on_overflow = 0

    则服务器建立该连接的定时器,

    这个定时器是一个服务器的规则是从新发送syn+ack的时间间隔成倍的增加,
    比如从新了第二次握手,进行了5次,这五次的时间分别是 1s, 2s,4s,8s,16s,
    这种倍数规则叫“二进制指数退让”(binary exponential backoff)

    给客户端定时从新发回SYN+ACK即从新进行第二次握手,(如果客户端设定的超时时间比较短就很容易出现异常)
    服务器从新进行第二次握手的次数/proc/sys/net/ipv4/tcp_synack_retries
    这里写图片描述

    2.2 tcp_abort_on_overflow = 1

    关于tcp_abort_on_overflow的解析如下:
    这里写图片描述
    意思应该是,当 tcp_abort_on_overflow 等于1 时,重置连接(一般是发送RST给客户端),
    至于怎么重置连接是系统的事情了。
    不过我在查资料的过程发现,阿里中间件团队博客说并不是发送RST, —[阿里中间件团队博客]

    这个博客跑的实例观察到的是服务器会忽略client传过来的包,然后client重传,一定次数后client认为异常,然后断开连接。
    当然,我们写代码的都知道代码是第一手的注释,实践是检验真理的唯一标准
    最好还是自己以自己实践为准,因为可能你的环境跟别人的不一样。)

    查看全连接队列(accept queue)的使用情况
    这里写图片描述
    如上图,第二列Recv-Q是,全连接队列接收到达的连接,第三列是Send-Q全连接队列的所能容纳最大值,
    如果,Recv-Q 大于 Send-Q 那么大于的那部分,是要溢出的即要被丢弃overflow掉的。

    感想:
    1.本来想写TCP连接的建立和终止的,没想到要讲清楚TCP连接的建立已经很大的篇幅了,就只讲TCP连接的建立而已。
    2.以前看书的时候,没有解决一个问题的来的深刻或者说脉络清晰,这个就是主题阅读的好处吧。
    3.以前没有养成一个遇到问题深入解析,解决问题的习惯,今后慢慢养成。

    下面的参考1有实例,会比较详细一点,清晰一些。
    参考:

    1. http://jm.taobao.org/2017/05/25/525-1/
    2. https://coolshell.cn/articles/11564.html
    3. https://zh.wikipedia.org/wiki/SYN_cookie
    4. https://zh.wikipedia.org/wiki/SYN_flood
    5. https://www.cnblogs.com/menghuanbiao/p/5212131.html
    展开全文
  • 面试官,不要再问我三次握手和四次挥手

    万次阅读 多人点赞 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:协议》


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

    在这里插入图片描述

    展开全文
  • TCP的三次握手与四次挥手理解及面试题(很全面)

    万次阅读 多人点赞 2018-07-17 20:56:17
    本文经过借鉴书籍资料、他人博客总结出的知识点,欢迎提问 序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;...

     本文经过借鉴书籍资料、他人博客总结出的知识点,欢迎提问

        序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。

        确认号ack:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。

        确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效

        同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。

        终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接

        PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。

     

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

    三次握手过程理解

     

    第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。

    第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;

    第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。

    四次挥手过程理解 

    1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,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(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
    6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

     常见面试题

    【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

    答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送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的三次握手与四次挥手

    万次阅读 多人点赞 2017-06-04 21:53:54
    背景描述 通过上一篇中网络模型中的IP层的介绍,我们知道网络层,可以实现两个主机之间的通信。但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在...

    背景描述

    通过上一篇中网络模型中的IP层的介绍,我们知道网络层,可以实现两个主机之间的通信。但是这并不具体,因为,真正进行通信的实体是在主机中的进程,是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机,但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。

    UDP,在传送数据前不需要先建立连接,远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付,但是正是因为这样,省去和很多的开销,使得它的速度比较快,比如一些对实时性要求较高的服务,就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

    TCP,提供面向连接的服务,在传送数据之前必须先建立连接,数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务,但是正因为这样,不可避免的增加了许多的开销,比如确认,流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。


    常用的熟知端口号

    应用程序 FTP TFTP TELNET SMTP DNS HTTP SSH MYSQL
    熟知端口 21,20 69 23 25 53 80 22 3306
    传输层协议 TCP UDP TCP TCP UDP TCP TCP TCP

    TCP的概述

    TCP把连接作为最基本的对象,每一条TCP连接都有两个端点,这种断点我们叫作套接字(socket),它的定义为端口号拼接到IP地址即构成了套接字,例如,若IP地址为192.3.4.16 而端口号为80,那么得到的套接字为192.3.4.16:80。

    TCP报文首部

    1. 源端口和目的端口,各占2个字节,分别写入源端口和目的端口;
    2. 序号,占4个字节,TCP连接中传送的字节流中的每个字节都按顺序编号。例如,一段报文的序号字段值是 301 ,而携带的数据共有100字段,显然下一个报文段(如果还有的话)的数据序号应该从401开始;
    3. 确认号,占4个字节,是期望收到对方下一个报文的第一个数据字节的序号。例如,B收到了A发送过来的报文,其序列号字段是501,而数据长度是200字节,这表明B正确的收到了A发送的到序号700为止的数据。因此,B期望收到A的下一个数据序号是701,于是B在发送给A的确认报文段中把确认号置为701;
    4. 数据偏移,占4位,它指出TCP报文的数据距离TCP报文段的起始处有多远;
    5. 保留,占6位,保留今后使用,但目前应都位0;
    6. 紧急URG,当URG=1,表明紧急指针字段有效。告诉系统此报文段中有紧急数据;
    7. 确认ACK,仅当ACK=1时,确认号字段才有效。TCP规定,在连接建立后所有报文的传输都必须把ACK置1;
    8. 推送PSH,当两个应用进程进行交互式通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应,这时候就将PSH=1;
    9. 复位RST,当RST=1,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立连接;
    10. 同步SYN,在连接建立时用来同步序号。当SYN=1,ACK=0,表明是连接请求报文,若同意连接,则响应报文中应该使SYN=1,ACK=1;
    11. 终止FIN,用来释放连接。当FIN=1,表明此报文的发送方的数据已经发送完毕,并且要求释放;
    12. 窗口,占2字节,指的是通知接收方,发送本报文你需要有多大的空间来接受;
    13. 检验和,占2字节,校验首部和数据这两部分;
    14. 紧急指针,占2字节,指出本报文段中的紧急数据的字节数;
    15. 选项,长度可变,定义一些其他的可选的参数。

    TCP连接的建立(三次握手)

    这里写图片描述

    最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端,被动打开连接的是服务器。

    1. TCP服务器进程先创建传输控制块TCB,时刻准备接受客户进程的连接请求,此时服务器就进入了LISTEN(监听)状态;
    2. TCP客户进程也是先创建传输控制块TCB,然后向服务器发出连接请求报文,这是报文首部中的同部位SYN=1,同时选择一个初始序列号 seq=x ,此时,TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。
    3. TCP服务器收到请求报文后,如果同意连接,则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号是ack=x+1,同时也要为自己初始化一个序列号 seq=y,此时,TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文也不能携带数据,但是同样要消耗一个序号。
    4. TCP客户进程收到确认后,还要向服务器给出确认。确认报文的ACK=1,ack=y+1,自己的序列号seq=x+1,此时,TCP连接建立,客户端进入ESTABLISHED(已建立连接)状态。TCP规定,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。
    5. 当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。
      三次握手

    为什么TCP客户端最后还要发送一次确认呢?

    一句话,主要防止已经失效的连接请求报文突然又传送到了服务器,从而产生错误。

    如果使用的是两次握手建立连接,假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。

    如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

    TCP连接的释放(四次挥手)

    这里写图片描述

    数据传输完毕后,双方都可释放连接。最开始的时候,客户端和服务器都是处于ESTABLISHED状态,然后客户端主动关闭,服务器被动关闭。

    1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,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(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
    6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

    四次挥手

    为什么客户端最后还要等待2MSL?

    MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。

    第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。

    第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

    为什么建立连接是三次握手,关闭连接确是四次挥手呢?

    建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
    而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。

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

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




    如果觉得本文不错,给予一点点赞助。

    微信 支付宝
    展开全文
  • TCP协议三次握手和四次握手机制-动画详解

    万次阅读 多人点赞 2018-08-25 20:19:44
    TCP三次握手和四次挥手的问题在面试中是最为常见的考点之一。很多读者都知道三次和四次,但是如果问深入一点,他们往往都无法作出准确回答。 本篇尝试使用动画来对这个知识点进行讲解,期望读者们可以更加简单地地...
  • 三次握手

    2018-09-29 09:24:52
    第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。...第三次握手:客户端收到服务器的SY...
  • 简述TCP的三次握手和四次挥手过程

    万次阅读 多人点赞 2018-05-11 10:28:40
    ①TCP是一种精致的,可靠的字节流协议。 ②在TCP编程中,三路握手一般由客户端(Client)调用Connent函数发起。... 图 .TCP三次握手 (1)第一次握手:Client将标志位SYN置为1,随机产生一个值s...
  • TCP 为什么三次握手而不是两次握手(正解版)

    万次阅读 多人点赞 2018-09-19 19:10:58
    TCP 采用三次握手的原因其实非常简单, 远没有大部分博客所描述的那样云山雾绕。
  • TCP三次握手

    千次阅读 2019-03-22 16:42:42
    TCP协议三次握手分析 在TCP/IP协议中,TCP(Transmission Control Protocol)是可靠传输协议,是传输层的重要协议,提供可靠的连接服务,采用三次握手来建立连接。 一般来说,我们把发起连接的称为客户端(C),接收...
  • TCP协议中的三次握手和四次挥手(图解)

    万次阅读 多人点赞 2011-08-07 20:43:02
    建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示: 先来看看如何建立连接的。 首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接分配资源。Client端接收...
  • 计算机网络—三次握手/四次握手

    千次阅读 2017-12-25 16:44:24
    计算机网络基础 三次握手 四次握手
  • TCP三次握手四次挥手

    千次阅读 多人点赞 2017-07-18 23:02:07
    TCP三次握手四次挥手的实现流程 为什么有三次握手四次挥手
  • TCP三次握手和四次挥手

    千次阅读 多人点赞 2019-08-29 18:22:18
    TCP三次握手和四次挥手 文档来源:https://www.cnblogs.com/qdhxhz/p/8470997.html 文章目录TCP三次握手和四次挥手@[toc]一、TCP三次握手二、TCP数据的传输过程三、TCP的四次挥手四、SYN(洪水)攻击五、TCP和UDP的...
  • 动画:用动画给面试官解释 TCP 三次握手过程

    万次阅读 多人点赞 2019-10-12 07:55:38
    TCP 三次握手过程对于面试是必考的一个,所以不但要掌握 TCP 整个握手的过程,其中有些小细节也更受到面试官的青睐。 对于这部分掌握以及 TCP 的四次挥手,小鹿将会以动画的形式呈现给每个人,这样将复杂的知识简单...
  • TCP三次握手,四次挥手

    千次阅读 多人点赞 2015-06-29 21:13:15
    图解三次握手四次挥手的过程,以及需要三次握手四次挥手的原因 程序员面试常考的网络题目
  • 大白话解释TCP三次握手 原文地址:http://www.cnblogs.com/yuilin/archive/2012/11/05/2755298.html 一、TCP三次握手 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 1、第一次握手:建立...

空空如也

1 2 3 4 5 ... 20
收藏数 25,393
精华内容 10,157
关键字:

三次握手