精华内容
下载资源
问答
  • 为什么TCP协议中握手需要三次,挥手需要四次 握手需要三次,举个简单的例子,我们想一下日常生活中的握手的场景,首先我们要伸出手,当别人看到你伸出手时,别人也会伸出手。这羊当你看到别人的手伸出来,这样你们两...
  • 1. 为什么要用三次握手 在《计算机网络》一书中其中有提到,三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误”,这种情况是:一端(client)A发出去的第一个连接请求报文并没有...

    1. 为什么要用三次握手

    在《计算机网络》一书中其中有提到,三次握手的目的是“为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误”,这种情况是:一端(client)A发出去的第一个连接请求报文并没有丢失,而是因为某些未知的原因在某个网络节点上发生滞留,导致延迟到连接释放以后的某个时间才到达另一端(server)B。本来这是一个早已失效的报文段,但是B收到此失效的报文之后,会误认为是A再次发出的一个新的连接请求,于是B端就向A又发出确认报文,表示同意建立连接。如果不采用“三次握手”,那么只要B端发出确认报文就会认为新的连接已经建立了,但是A端并没有发出建立连接的请求,因此不会去向B端发送数据,B端没有收到数据就会一直等待,这样B端就会白白浪费掉很多资源。如果采用“三次握手”的话就不会出现这种情况,B端收到一个过时失效的报文段之后,向A端发出确认,此时A并没有要求建立连接,所以就不会向B端发送确认,这个时候B端也能够知道连接没有建立。


    2. TCP协议三次握手过程分析

    TCP(Transmission Control Protocol) 传输控制协议
    TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接:
    位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)
    Sequence number(顺序号码) Acknowledge number(确认号码)
    第一次握手:主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,主机B由SYN=1知道,A要求建立联机;
    第二次握手:主机B收到请求后要确认联机信息,向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
    第三次握手:主机A收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack number=(主机B的seq+1),ack=1,主机B收到后确认seq值与ack=1则连接建立成功。
    完成三次握手,主机A与主机B开始传送数据。

    在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。
    第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
    第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态; 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。 完成三次握手,客户端与服务器开始传送数据.

    实例:
    IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
    IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
    IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
    第一次握手:192.168.1.116发送位码syn=1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
    第二次握手:192.168.1.123收到请求后要确认联机信息,向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
    第三次握手:192.168.1.116收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,192.168.1.116会再发送ack number=1739326487,ack=1,192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。

    图解:
    一个三次握手的过程
    这里写图片描述

    这里写图片描述

    这里写图片描述

    一个完整的三次握手也就是 请求—应答—再次确认


    3. 超时重传机制

    (1) 如果第一个包,A发送给B请求建立连接的报文(SYN)如果丢掉了,A会周期性的超时重传,直到B发出确认(SYN+ACK);
    (2) 如果第二个包,B发送给A的确认报文(SYN+ACK)如果丢掉了,B会周期性的超时重传,直到A发出确认(ACK);
    (3) 如果第三个包,A发送给B的确认报文(ACK)如果丢掉了,
    A在发送完确认报文之后,单方面会进入ESTABLISHED的状态,B还是SYN_RCVD状态
    如果此时双方都没有数据需要发送,B会周期性的超时发送(SYN+ACK),直到收到A的确认报文(ACK),此时B也进入ESTABLISHED状态,双方可以发送数据;
    如果A有数据发送,A发送的是(ACK+DATA),B会在收到这个数据包的时候自动切换到ESTABLISHED状态,并接受数据(DATA);
    如果这个时候B要发送数据,B是发送不了数据的,会周期性的超时重传(SYN+ACK)直到收到A的确认(ACK)B才能发送数据。


    4. 我们再来考虑,如果不是三次握手会出现什么情况呢

    假设有A和B两端要进行通信,
    1, 第一次:首先A发送一个(SYN)到B,意思是A要和B建立连接进行通信;
    如果是只有一次握手的话,这样肯定是不行的,A压根都不知道B是不是收到了这个请求。
    2, 第二次:B收到A要建立连接的请求之后,发送一个确认(SYN+ACK)给A,意思是收到A的消息了,B这里也是通的,表示可以建立连接;
    如果只有两次通信的话,这时候B不确定A是否收到了确认消息,有可能这个确认消息由于某些原因丢了。
    3, 第三次:A如果收到了B的确认消息之后,再发出一个确认(ACK)消息,意思是告诉B,这边是通的,然后A和B就可以建立连接相互通信了;
    这个时候经过了三次握手,A和B双方确认了两边都是通的,可以相互通信了,已经可以建立一个可靠的连接,并且可以相互发送数据。
    4, 第四次:这个时候已经不需要B再发送一个确认消息了,两边已经通过前三次建立了一个可靠的连接,如果再发送第四次确认消息的话,就浪费资源了。
    如果第二个报文段B发出的(SYN+ACK)分别发送的话,也是可以理解为四次,但是被优化了,一起发送了。

    TCP协议挥手过程,已经为什么要四次挥手? < 点击传送 >

    这里写图片描述

    展开全文
  • 为什么连接的时候是三次握手,关闭的时候却是四次握手? 答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server...

    1. 为什么四次挥手?

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

    TCP协议三次握手过程分析,以及为什么要三次握手,不握手又会怎么样? < 点击跳转 >


    2. 四次挥手过程分析

    中断连接端可以是Client端,也可以是Server端。
    假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说”我Client端没有数据要发给你了”,但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,”告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息”。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,”告诉Client端,好了,我这边数据发完了,准备好关闭连接了”。Client端收到FIN报文后,”就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,”就知道可以断开连接了”。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!
    这里写图片描述

    服务端挥手流程:
    这里写图片描述

    客户端挥手流程:
    这里写图片描述

    在TIME_WAIT状态中,如果TCP
    client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放。


    3. 完整流程图

    建立TCP需要三次握手才能建立,而断开连接则需要四次握手。整个过程如下图所示:
    这里写图片描述


    展开全文
  • 目录抓包过程TCP 首部分析TCP 三次牵手过程TCP 四次分手过程常见面试经典问题为什么牵手是三次,分手是四次?为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态? 抓包过程 使用了 Wireshark...

    目录

    抓包过程

    使用了 Wireshark 进行抓包,用两个最常用的 curl 和 ping 命令来演示抓包情况,开启抓包。

    ## 先访问我自己的网站首页
     curl https://zengzhiqin.kuaizhan.com 
    ## 再查看我自己网站的地址
     ping https://zengzhiqin.kuaizhan.com
    

    Wireshark根据 ping 命令得到的地址进行条件过滤,得到上面两个命令所得到的包,主要有 TCP(https基于tcp协议)协议和 ICMP(ping命令是基于 ICMP 协议)协议的包,如下图所示:

    抓包分析
    抓包分析

    TCP 首部分析

    TCP包首部内容一一对应
    TCP包首部内容一一对应
    TCP首部
    TCP首部

    首部内容简单分析:

    1. 源端口目标端口

    包通过传输层千辛万苦找到了机器,机器那么多应用,假如这个时候艾莉给洪世贤发微信撩sao,世贤开了 QQ 又开了微信,这个时候就靠端口号来区分不同服务,QQ和微信的端口号肯定不一样,因此才能消息才能正确找到微信应用。

    1. 序列号和确认号

    数据分段传输过程中,序列号可以保证所有传输的数据按照正常的次序进行重组,而且通过确认保证数据传输的完整性。

    • 如图所示,整理分析五个连续的请求包数据的序列号确认号进行序列号分析: 连续数据包的序号和确认号

    整理分析如下: 连续请求包

    序列号可以用来确定传输内容的位置,传输到哪一个字节了,接收端接收到好根据序列号进行重组数据。相对序列号和相对确认号是用来简化随机序列号和随机确认号的。

    下一个请求包的序列号 = 上一个请求包序列号 + 数据长度

    • 请求应答过程如下
    请求应答
    请求应答

    确认号就是用来确认回复哪个序列号的多大的数据包,所以Ack=请求包的Seq+数据长度 。并且通过确认序列号,确认号,数据长度的值,可以确定此数据包是否完整。

    1. 数据偏移

    就是首部长度,因为首部除了 20 字节固定长度之外,还有选项部分,是可选可变长度,所以需要有个偏移量告诉数据首部长度位置。

    1. 保留

    此 6 bit 二进制没有用到

    1. 状态位
    请求建立连接的数据包的状态位
    请求建立连接的数据包的状态位
    状态含义
    状态含义

    小说明:大写的表示状态,如ACK,小写的表示确认号,如Ack;

    1. 窗口

    tcp是可靠传输,有接收缓存和发送缓存,缓存被叫做窗口,通过滑动窗口技术实现可靠传输(这个地方还挺复杂的,下一篇会写关于可靠传输和拥塞控制相关的)

    1. 检验和

    用来保证 TCP 头和数据的内容在抵达目的时的正确性完整性

    1. 紧急指针

    如果设置了 URG 位,这个域将被检查作为额外的指令,告诉 CPU 从数据包的哪里开始读取数据,优先处理此包的命令。插队打乱了原来的队伍顺序,把列宁同志的团队人员单独优先处理,需要记录下这部分人的信息,是这个团队的就先走。

    1. 选项

    可以规定最大数据报的长度为多少,还可以支持选择性的进行确认。

    1. 填充

    选项和填充一共40个字节,如果不够需要进行填充凑够了

    TCP 三次牵手过程

    洪世贤饰客户端,林品如饰服务端

    三次交涉牵手建立婚姻
    三次交涉牵手建立婚姻

    牵手过程:

    (客户端)世贤:品如,你好美客户端发起请求,头部设置为SYN为1表示他要请求建立连接,并且发送一个随机序列号x,此时世贤进入 SYN_SENT 求婚等待爱情状态;

    SYN包:SYN=1, ACK=0, Seq=x

    (服务端)品如:世贤,你好帅服务端接收到连接请求,头部设置SYN+ACK表示他要回应了,并且自己也随机生成一个序列号标识自己y,通过将ack确认号设置为客户端的请求序列号x +1 的方式来告诉请求的客户端他回应的是哪个客户端,因为可能有很多个客户端同时向他请求建立连接,进行相应回应,此时品如进入了 SYN_RCVD 收到求婚并且同意等待下一步指示状态

    SYN+ACK包:SYN=1, ACK=1, Seq=y, Ack=x+1

    (客户端)世贤:品如,我们结婚客户端接收到服务端回复之后,再次确认连接,头部设置为ACK表示他收到了服务端的确认请求现在进行确认,ACK为1表示他要进行确认了,ack=y+1=服务端的请求序列号+1,表示他确认的是服务端这个包的请求,seq=x+1因为上一个客户端请求序列号是x,这个请求包从 x+1 开始,此时世贤收到同意回复进入了宣布结婚 ESTABILSHED 状态, 品如收到了结婚请求也进入了结婚状态

    ACK包:ACK=1, Seq=x+1, Ack=y+1

    小结:

    因为建立连接之前是没有数据传输的,但是 SYN,ACK 等状态需要占用一个序号,所以这个地方请求序列号加的数据都是1,建立连接之后有数据传输,序列号和确认号加的数据都会是数据的长度;

    • Ack=请求序列号+数据长度;

    • 包的序列号Seq = 同一端上一个包的序列号+数据长度;

    • 下一个包的Seq = 上一个应答包的Ack

    涨姿势:借助wireshark的分析工具,点击 wireshark 的 Statistic 下面的Follow Graph,能得到如下的分析图,也可以很直观的看到牵手分手以及序列号:

    tcp
    tcp

    TCP 四次分手过程

    image
    image

    四次分手过程的序列号和确认号,和上面牵手是一样的分析,就不贴图了贴个世贤。

    四次挥手过程
    四次挥手过程

    (客户端)世贤:你不够骚

    (服务端)品如:我的衣柜不好看吗

    (服务端)品如:算了衣服你们玩,我去跳海

    (客户端)世贤:你喜欢大海,我爱过你

    这个分手过程读者自己看图吧,写下来太多了,注意看双方状态,序列号和确认号。

    常见面试经典问题

    为什么牵手是三次,分手是四次?

    三次牵手原因:

    一般如果客户端给服务端发起一个请求,服务端回复了,一来一回就能表示网络是畅通的,可以发数据。那么为什么需要第三个数据包呢?

    首先,客户端请求建立连接如果没有成功是会一直重试的,那么就会有多个建立连接请求。


    世贤和品如的故事

    世贤饰客户端A数据包,窃格瓦拉饰客户端B数据包,品如饰服务端

    1. 假如世贤第一次求爱之前先绕远路去美国买了束玫瑰花,然后 窃格瓦拉 从牢里出来了直接就去找品如求爱了,品如这时候答应了窃格瓦拉的求爱,品如等着和窃格瓦拉来约她看海;

    2. 然后世贤也到了,品如一看世贤好帅反正她没有结婚又答应了世贤的求爱,于是品如又等着世贤约她看海;

    3. 试想一下全世界男的都去找品如告白一次,那品如就有看不完的海了,主要原因是因为品如不知道哪一个男的是来真的。所以需要有人求婚,也就是第三次确认,结婚了就不用和别的男的看海了,直接放弃掉别人。


    如果只有两次,那么服务端回应了就算是建立了连接,但是服务端没法判断他回应的请求连接是否在使用,这就会导致下面两种情况:

    • 第一种是会造成很多无效连接资源不能释放。请求包因为网络慢耗时严重,客户端重复发了很多包,一段时间后这些包到了服务端回复建立起了很多不必要的连接,这些连接资源无法释放,三次牵手第三次再次确认之后服务端建立连接并且将其他的无效连接释放掉。 二次牵手造成很多无效连接资源不能释放

    • 第二种是确认包丢失造成循环死锁问题,如下图 二次牵手造成死锁

    四次分手原因

    牵手容易分手难,都市的饮食男女应该都能感受到这点。

    主要是因为服务端收到关闭请求之后,服务端的数据可能还没有传完,这个时候服务端会继续把数据传输完,然后再告诉客户端可以关闭了,客户端再关闭。

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

    MSL指一个片段在网络中最大的存活时间,2MSL是两倍的MSL(Maximum Segment Lifetime),就是一个发送和一个回复所需的最大时间。

    网络是不可靠的,如果最后的ACK包丢失了然后客户端又已经关闭了,那么服务端还会一直发送 FIN 请求关闭但是没人理他,他就会一直发FIN,那么服务端就会一直持续发 FIN 从而没法关闭了。所以客户端需要再等2MSL,这段时间一来一回的路上再也没有 FIN 包过来了,因此客户端可以放心关闭了。

    感觉自己在写剧本,满脑子都是品如的衣柜,有收获的老铁点赞或者点在看来鼓励一下作者吧,感谢观看~

    下期预告: tcp流量控制和拥塞控制的实现

    欢迎关注我的公众号看更多内容

    展开全文
  • TCP 为什么三次握手而不是两次握手(正解版)

    万次阅读 多人点赞 2018-09-19 19:10:58
    TCP 采用三次握手的原因其实非常简单, 远没有大部分博客所描述的那样云山雾绕。
  • 三次握手,四次挥手,为什么是三次握手四次挥手 四次挥手 TCP的连接的拆除需要发送四个包,因此称为四次挥手。客户端或服务器均可主动发起挥手动作。 由于TCP连接时全双工的,因此每个方向都必须单独进行关闭...
  • 前几天被一个好友问到了这个问题,让我的思绪回到了当年的“计算机网络与原理”那门课程……,是啊,为什么握手是三次,而不是两次,或者四次呢?  先来一张搞笑图哦~    如图所示,是美国三位总统的三次握手...
  • TCP为什么三次握手

    2020-10-02 09:56:59
    TCP的三次握手过程,为什么是三次呢? 三次握手过程 (1)第一次握手 客户端向服务器端发送tcp报文请求建立连接,其中: 标记位为SYN=1 序号为seq=x (2)第二次握手 服务端收到信息后知道自己与客户端是可以连接...
  • 为什么要三次握手

    2020-07-11 20:04:00
    为什么要三次握手? TCP协议握手目的是为了保证数据可靠传输,并且提高数据传输的效率,而三次握手恰好能满足以上要求 为什么要三次握手: The principle reason for the three-way handshake is to prevent ...
  • 为什么是三次握手捏::: 三次握手可以简单看做是客户发送请求,服务器对客户的请求进行确认
  • 为什么需要三次握手

    2019-10-19 11:06:58
    文章目录1. 三次握手1.1 为什么需要三次握手,两次不行吗?1.2 什么是半连接队列?1.3 ISN(Initial Sequenc...
  • 介绍 TCP 连接的三次握手?追问:为什么 TCP 握手需要三次?...为什么握手需要3次?(而不是2次或者4次?) TCP会话建立具有可靠性的关键在于双方都具有收发能力,第一次握手是为了确认客户端有发送能力,
  • TCP三次握手为什么是三次握手

    千次阅读 2015-04-25 11:17:16
    TCP三次握手为什么是三次握手TCP三次握手为什么是三次握手 TCP连接的建立 为什么要三次握手 TCP的连接释放工程四次握手 为什么A在TIME-WAIT状态必须等待2MSL的时间TCP连接的建立为什么要三次握手 为什么A还要发送...
  • TCP为什么要三次握手为什么要四次挥手? 三次握手,要保证发送端与接受端都做好连接的准备 四次挥手,要保证断开连接时数据完整的发送完毕 TCP是全双工的 为什么连接的时候是三次握手,关闭的时候却是四次握手? ...
  • 一句话概括,TCP连接握手,握的是啥? 通信双方数据原点的序列号!...参考:TCP 为什么三次握手而不是两次握手 Why do we need a 3-way handshake? Why not just 2-way? why not just us...
  • 首先为什么握手?tcp是可靠的全双工的一个双向通信传输协议,体现在就是通信的双方都需要确认对方是否收到了自己发的数据包是完整有序无差错的,如果不是就需要重发。 其次为什么握手三次?简单来说,两次不...
  • 两次握手只能保证单向连接是畅通的。 Step1 A -> B : 你好,B。 Step2 A <- B: 收到。你好,A。 这样的两次握手过程,A 向B 打招呼得到了回应,即 A 向 B 发送数据,B 是可以收到的。 但是 B 向 A 打招呼,...
  • tcp为什么要第三次握手,time_wait是做什么的?  tcp有几种状态,画出所有的状态转换图。  晚上看到的面试题,TCP三次握手的印象很深,但为什么需要3次握手,还是想不起来了。 简单而言:如果不是三次握手的话,...
  • 为什么不能两次握手:(防止已失效的连接请求又传送到服务器端,因而产生错误) 假设改为两次握手,client端发送的一个连接请求在服务器滞留了,这个连接请求是无效的,client已经是closed的状态了,而服务器认为...
  • 为什么要三次握手

    2021-05-13 11:43:53
    为什么要三次握手?蓝军1和蓝军2分别再两个山顶上,只有联手才能打印位于山谷的白军。 蓝军1给蓝军2打电话,电话接通了。 蓝军1:“我们要攻打白军了,请一同作战。“ 蓝军2:“好的。” 第一次握手是,蓝军1给蓝军2...
  • TCP 三次握手的过程掌握最重要的两点就是客户端和服务端状态的变化,另一个是三次握手过程标志信息的变化,那么掌握 TCP 的三次握手就简单多了。下面就以动画形式进行拆解三次握手过程。 初始状态:客户端处于...
  • 首先来说一下三次握手为什么需要三次握手呢?因为TCP提供的是可靠传输服务,因此它在传输之前必须要进行传输的可靠性测试和一些信息的同步,反观UDP就不用这些握手操作。三次握手正好使双方都能测试传输的可靠性,...
  • 第一次握手:主机A发送位码syn=1,随机产生seq number=x 的数据包到服务器, 主机B由SYN=1知道,A要求建立联机; 第二次握手:主机B收到请求后要确认联机信息, 向A发送ack number=(主机A的seq+1),syn=1,ack=1...

空空如也

空空如也

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

为什么握手