TCP三次握手和四次挥手的全过程_

线上幽灵007

三次握手的全过程：

四次挥手的全过程：

发表于 2018-04-10 11:18:59 回复(2)

营琪

吃鸡吗？吃！上线！

我不打了，明天早上有课。那好吧。（等待一下，看看是不是骗我）白白白白

发表于 2019-05-28 21:48:58 回复(0)

zll

第一次握手：客户端发送syn包（syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认

第二次握手：服务器收到客户端发送的syn包，必须确认客户端的syn（ack=syn+1），同时自己也发送一个SYN包（syn=y）即syn+ack，同时服务器进入SYN_RECV状态

第三次握手：客户端接收到SYN+ACK包，向服务器发送确认包（ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISH状态，完成三次握手。

四次握手：

与建立连接的三次握手类似，TCP断开连接需要四次握手。

第一次挥手：主动关闭方发送一个FIN,用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我不会再给你发送数据啦（当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方会重新发送数据），但此时主动关闭方还是可以接收数据

第二次挥手：被动关闭方收到FIN报文后，发送ACK确认报文给主动关闭方，确认序号为收到序号加1（与SYN一样，一个FIN占用一个序号）

第三次挥手：被动关闭方发送一个FIN报文，用来关闭被动关闭方与主动关闭方之间的数据传输，也就是告诉主动关闭方我的数据也发送完成了，不会再给你发送数据了。

第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号加1，至此完成四次挥手。

发表于 2016-03-20 20:35:09 回复(0)

weka

答:三次握手：
第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
四次握手
与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。
第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。
第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

发表于 2015-10-29 12:06:16 回复(0)

小星.打屁屁

m

发表于 2019-01-01 23:35:01 回复(0)

stt2019

https://blog.csdn.net/u012940886/article/details/80377203

发表于 2018-05-20 19:59:01 回复(0)

就是不告诉你

三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

但是为什么一定要进行三次握手来保证连接是双工的呢，一次不行么？两次不行么？我们举一个现实生活中两个人进行语言沟通的例子来模拟三次握手。

第一次对话：

老婆让甲出去打酱油，半路碰到一个朋友乙，甲问了一句：哥们你吃饭了么？

结果乙带着耳机听歌呢，根本没听到，没反应。甲心里想：跟你说话也没个音，不跟你说了，沟通失败。说明乙接受不到甲传过来的信息的情况下沟通肯定是失败的。

如果乙听到了甲说的话，那么第一次对话成功，接下来进行第二次对话。

第二次对话：

乙听到了甲说的话，但是他是老外，中文不好，不知道甲说的啥意思也不知道怎样回答，于是随便回答了一句学过的中文：我去厕所了。甲一听立刻笑喷了，“去厕所吃饭”?道不同不相为谋，离你远点吧，沟通失败。说明乙无法做出正确应答的情况下沟通失败。

如果乙听到了甲的话，做出了正确的应答，并且还进行了反问：我吃饭了，你呢？那么第二次握手成功。

通过前两次对话证明了乙能够听懂甲说的话，并且能做出正确的应答。接下来进行第三次对话。

第三次对话：

甲刚和乙打了个招呼，突然老婆喊他，“你个死鬼，打个酱油咋这么半天，看我回家咋收拾你”，甲是个妻管严，听完吓得二话不说就跑回家了，把乙自己晾那了。乙心想：这什么人啊，得，我也回家吧，沟通失败。说明甲无法做出应答的情况下沟通失败。

如果甲也做出了正确的应答：我也吃了。那么第三次对话成功，两人已经建立起了顺畅的沟通渠道，接下来开始持续的聊天。

通过第二次和第三次的对话证明了甲能够听懂乙说的话，并且能做出正确的应答。

可见，两个人进行有效的语言沟通，这三次对话的过程是必须的。

同理对于TCP为什么需要进行三次握手我们可以一样的理解：

为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

发表于 2016-06-20 14:14:57 回复(8)

牛客3804006号

约吗？约。走起

发表于 2017-02-03 16:16:54 回复(14)

oscarwin

三次握手：

1. 客户端发送SYN请求，进入SYN_SEND状态

2. 服务端收到SYN请求，并返回一个ACK应答，并发送一个SYN其请求，服务器进入SYN_RECV状态

3. 客户端收到服务端的SYN请求和ACK应答，发送ACK应答，客户端进入ESTABLISH状态，服务端收到应答后进入ESTABLISH。

如果没有收到应答，数据包都会根据TCP的重传机制进行重传。

四次挥手：

1. 客户端发送FIN包，请求断开连接，客户端进入FIN_WAIT1状态

2. 服务端收到FIN包后返回应答，进入CLOSE_WAIT状态

3. 客户端收到FIN的应答后进入FIN_WAIT2状态

4. 服务端发送FIN请求包，进入LAST_ACK状态

5. 客户端收到FIN请求包后，发送应答进入TIME_WAIT状态

6. 服务器收到ACK应答后，进入close状态。

发表于 2017-07-31 15:01:20 回复(2)

牛客网123321

TCP的状态 (SYN, FIN, ACK, PSH, RST, URG) 在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG. 其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是： SYN表示建立连接， FIN表示关闭连接， ACK表示响应， PSH表示有 DATA数据传输， RST表示连接重置。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。 TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。 RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。 PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。 TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。概念补充-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状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据. 摘自中国云安网(www.yunsec.net) 原文：http://www.yunsec.net/a/school/wlcs/agreement/2012/0317/10262.html

发表于 2017-03-01 13:50:17 回复(1)

殊不知

三次握手 A：老铁，听的到吗？ B：听的到，你能听到我吗？ A：我也能听的到四次挥手 A：我的东西发完了，我要关了。 B：好的，可你的东西我还没全收到。 B：好了，你的东西我全收到了。 A：好的，那我关了

编辑于 2020-09-26 22:05:49 回复(0)

永在途中

我来举了简单例子吧，当然握手和挥手过程的状态变化，以及TCP标志位的改变等等细节我就不说了，首先你要想象有两个人瞎子站在街对面通信，他们互相看不见对方但是又要建立连接通信，所以有了如下对话：

A：你在吗，我们要互相交换信息，我想跟你先建立连接；

B：你的建立连接请求我已收到，我同意，来吧；

A：你的确认同意信息我已收到，我来了。

仔细品上面三句话，少了哪句话都不行实际上，三次这个次数已经是最少的了，所以三次握手不算是人为设置而是不得已而为之。比如要是B不回答，那么A不知道B听到没有，A会想是B听到了没回，还是回了声音太小我没听到，有鉴于此A就会一直等，知道计时器到点之后A又会再喊一遍，这样就很尴尬也浪费时间，所以B的确认信息必不可少，而A之后也不回直接开始信息发送的话也是不负责，因为B不知道A收到自己信息没有，所以万一之后传输的是个****，B防护服还没穿就接收那么就只有死翘翘了。所以必须有请求有响应才能保证无法看见对方的双方进行稳定可靠的数据通信；

4次挥手：

A：好了，我信息够了，不用再废话了，断开连接吧；

B：嗯，你的断开请求我收到了

B：嗯，我的信息也都发完了，就按你之前说的断开连接吧；

A：好的，你的同意意见我收到了，那么就断开吧

这里按照三次握手意义理解不难，难点在于为何会比三次握手多一次，这里你要站在B的角度考虑，因为B在收到A的请求的时候可能信息还没有发完，这个时候按照三次握手逻辑的话，那就是同意断开请求之后直接收到A的确认信息之后就断开，这是不负责任也不符合实际的。所以作为信息输出方来讲，最终决定断开是需要他点头同意才可以的

发表于 2021-11-02 10:17:28 回复(0)

截取一线生机

三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

发表于 2021-04-27 23:20:27 回复(0)

手中的命运。

大佬们四次挥手的第二次和第三次挥手为什么不能合并客户端fin 服务端ack➕fin 客户端 ack

发表于 2021-04-08 08:29:38 回复(0)

夏倾尘

答案中有一点有问题，“握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据“。这句话表述有问题

实际上TCP连接时第三次握手是可以携带数据的，若不携带数据则不消耗序号

发表于 2021-01-23 14:43:02 回复(0)

牛仔糖

三次握手：
第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。
四次挥手
与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。
第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可以接受数据。
第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

发表于 2020-07-10 15:56:42 回复(0)

请赐我杭研offer

三次握手： 1. 客户端发送SYN请求，进入SYN_SEND状态 2. 服务端收到SYN请求，并返回一个ACK应答，并发送一个SYN其请求，服务器进入SYN_RECV状态 3. 客户端收到服务端的SYN请求和ACK应答，发送ACK应答，客户端进入ESTAB_LISHED状态，服务端收到应答后进入ESTAB_LISHED。如果没有收到应答，数据包都会根据TCP的重传机制进行重传四次挥手： 1. 客户端发送FIN包，请求断开连接，客户端进入FIN_WAIT1状态 2. 服务端收到FIN包后返回应答，进入CLOSE_WAIT状态 3. 客户端收到ACK的应答后进入FIN_WAIT2状态 4. 服务端发送FIN请求包，进入LAST_ACK状态 5. 客户端收到FIN请求包后，发送应答进入TIME_WAIT状态 6. 服务器收到ACK应答后，进入close状态。

编辑于 2020-04-02 00:17:43 回复(0)

新芽莫摘采

第一次握手：客户端发送SYN包（syn=x）给服务端，此时客户端进入SYN_SEND模式

第二次握手：服务端收到客户端传递的SYN包之后，发送ACK包（ack=x+1）和SYN包（syn=y）给客户端，此时服务端进入SYN_RECEIVED模式

第三次握手：客户端收到服务端的SYN+ACK包，发送ACK（ack=y+1）给服务端，此时双方进入ESTABLISHED状态。

tcp连接建立之后，就可以发送数据了。理想情况下，只要双方不主动断开连接，连接一直存在。

四次挥手

第一次挥手：主动关闭方发送FIN包给被动关闭方，此时主动关闭方不会再发送数据给被动关闭方，但是FIN包之前的数据没有收到ack请求的话再次发送。可以继续接受数据。

第二次挥手：被动关闭方发送ACK数据包给主动关闭方，确认序列号为收到序列号+1，表示我知道你不会再给我发送数据了。

第三次挥手：被动关闭方发送FIN包给主动关闭方，表明不会再发送数据，但是可以发送FIN之前的数据，如果没有收到ack请求的话。

第四次挥手：主动关闭方发送ACK包给被动关闭方，连接断开

编辑于 2020-02-07 15:34:06 回复(0)

TeddyTangBiSheng

http://www.zhihu.com/question/20879359

发表于 2016-02-29 19:43:20 回复(0)

TCP三次握手和四次挥手的全过程

问题信息

热门推荐

相关试题