通俗大白话来理解TCP协议的三次握手和四次分手

[jawil]

通俗大白话来理解TCP协议的三次握手和四次分手

[jawil]

学习记录一下笔记，多看看，多领会，切勿浮躁一口吃成胖子。

[jawil]

如果你是TCP/IP协议规则的制定人，你可以让ack = x + 1000都没问题，一切规范都是人为制定的，当初就是这么规定的，ack = x + 1，ack = x + 2, ack = x + 3这三种是一个效果，它们是平行的，没有任何区别，其实只要明白，制定这个规则的目的主要用来解决不丢包的问题，明白这个就行了

[mini443]

@jawil @qingywen

三次握手，这张图更准确些吧。ACK大小写有区分。

对啊 。楼主那个图越看越懵。前文说到 ACK 只有0 和1 有用。图里面的又是X+1

[qingywen]

指出一个问题，三次握手的那张配图，第二、三次握手中的ACK应该是小写，不是大写。大写的ACK代表1bit的标志位，小写的ack才是32bit的确认序列号。

[chensguo8099]

你好 我想问一下为什么客户端发送seq = x后服务器发送ack = x + 1而不是ack = x + 2, ack = x + 3等等？？

[MontageD]

通俗介绍那个例子太真实了，就像人与人的信任关系，当你送别人东西的时候，别人也会送一个给你，当第二次再送礼物的时候，两者已经构成了所谓的「关系」了

[christolan]

大概我孤陋寡闻，第一次见到用issue写博客的大佬，长见识了。
不过想想也是，又支持markdown又有评论系统，棒呆。

[chensguo8099]

受教了谢谢

[qingywen]

你好 我想问一下为什么客户端发送seq = x后，服务器发送ack = x + 1而不是ack = x + length + 1，这里的length指服务端接收到的上个报文段所携带的字节数。

• why-do-we-need-a-3-way-handshake-why-not-just-2-way
• why-tcp-connect-termination-need-4-way-handshake

由此可以看出，TCP这样做，其实是为了保证连接的可靠性

[lwannn]

为什么三次握手？为什么四次挥手？最后几段简直就是神来之笔！！！

[lzuliuyun]

@jawil @qingywen

三次握手，这张图更准确些吧。ACK大小写有区分。

[sally2015]

这里的ACK在数据传输的时候需要重复再确认一次吗

[cllgeek]

向大神学习

[oyjjpp]

通俗易懂

[codezyc]

👍

[Arima-s]

受教，受我一拜

[Thinking80s]

学习了

[ChampionPaul]

好文！！

[ChampionPaul]

tcp传输数据以字节为单位，ack＋1是代表之前的数据已经接收了，期望下次接收从下一个字节开始的数据包

[ysy950803]

GitHub大神多。

[ShawnshanksGui]

有个疑问，博主在介绍  套接字（socket）概念的时候，提到：“应 用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务“”。
本人有不同意见：传输层屏蔽了低层的实现过程，只抽象成给上层应用层使用的接口，这接口就是Socket；而不是博主说道的应用层和传输层一起通过借助Socket接口......。

[deepred5]

厉害了！

[JeffyLu]

收藏一个👨🏿‍💻

[lgselite]

奋斗的小石头

[baixiaoji]

值得学习，上次面试到这题，答的很水

[minz]

总结的不错!star

[superreyn]

多谢大神总结，面试的时候u被问到这个问题了，理解的还不是很透彻。

[qwbzjy]

感谢分享！

[yanlee26]

深入浅出

[zhisheng17]

666

[HuangHongRui]

学习共进 📕

[chenkuangAmber]

没怎么看懂~

[bb-zhang]

写的好！

[yudetchu]

謝謝分享!!!

[Ghohankawk]

不错，写的好，就应该点赞

[zhonghuasheng]

你写的让我很容易懂，Thanks

[xieyang]

写的很好，谢谢分享

[leter]

很好,标记一下,谢谢楼主.

[benmo1602]

赶紧冒个泡

[shiguiyou]

学习了！第一遍有些没看懂，过两天再看一遍！顺便mark下

[Silencesnow]

写的真好，感谢楼主

[tigercandy]

好文，易理解

[zongsizhang]

好文！个人见过tcp讲的最清楚的一篇文章

[jeromelive]

写的很好，话说这文章的很多内容是不是黏贴复制的？怎么感觉文采挺好的，内容长度也可以

[zt-faraway]

好文章,通俗易懂,描述很透彻.谢谢文主的分享

[shijiaxiong]

总结的很全面，很明了。感谢！

[liyu4]

好人一生平安

[PnPie]

Great ! 写的很好,极度make sense,我google tcp协议地一个就找到它了.就是不知道为何不写在repository里面而是在issue里(那些fork的人是想干嘛:joy:),这样的话其他人也可以一起修改,至少我就看到了有一些打错的typos,还有FIN ACK sequence number etc.那段和那个图一块感觉有些confusing. 但不管怎样,很有帮助!Thx

[werwolfGu]

请问下 4次挥手中的第二次挥手不要感觉好像也可以，1发送给2说我要主动我要断开连接了，2知道1已经没数据连接了，此时2有数据还没发送完就继续发送咯，等2发送完了再告诉1我也可以断开连接了并且关闭连接；此时1在ACK下；

[EazonYoung]

数据传输阶段，服务器收到客户端数据后，确认号Ack=收到的序列号+1？好像不对吧？应该是Ack=seq+length吧？

[liniukesi]

向先进学习。

[Pomelo1213]

thanks

[ChenLiaoyuan]

感激涕零，逻辑清晰，通俗易懂

[124design]

nice~

[chyroc]

估计协议制定者把SYN和FIN看做了一个长度的数据，这样的话

客户端发送seq = x后服务器发送ack = x + 1

[lkj41110]

在TCP报文里ACK，SYN都是标志位，也就是1或0，但是图片里用了ACK=x+1，图片的ACK里的内容应该表示序号和确认号吧？

[chyroc]

图片里面的ACK=xx指的是有ACK信号，然后ack number=xxx 这样的？

[ThinkHuang]

good + 1

[dwqs]

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议

运输层-->传输层

[backendTime-coder]

mark

[zhangolve]

感谢分享

[mikeqoo1]

感谢分享

[starstudy]

赞！👍

[zjfcabbage]

楼主，可以转载嘛

[guanhui07]

[kadisi]

非常不错，通俗易懂

[HalfAkilo]

文章通俗易懂，但不明白为什么面试会有人爱问这样的问题。。。

[fangyufan123]

ACK:有两个取值：0和1，为1的时候表示应答域有效，反之为0；ACK不是标志位吗，为啥要ACK = X+1?

[chenerzhu]

ACK:有两个取值：0和1，为1的时候表示应答域有效，反之为0；ACK不是标志位吗，为啥要ACK = X+1?

ACK为确认报文字段，ack为确认应答号，两个不同的呀

[yelongyu]

第一次握手, 客户端发送SYNC请求后, 客户端进入状态应该为 SYN_SENT, 不是 SYN_SEND : )

[ioufev]

很有收获，终于看进一篇文章去了。
了解TCP协议，即传输控制协议，我感觉是对通信过程的理解，毕竟也没要求我们去优化TCP协议 。
有助于对socket如何长连接和http请求等通信问题的理解。

[Here21]

你好，这两天遇到一个问题，想来探讨一下：
前两天我们公司测试大哥为了测试功能，修改了手机系统时间，将时间往前调了一周，然后证书验证的时候报ssl 证书错误，找了几天问题，无意间发现可能是由于修改了手机系统时间导致。在恢复正常的系统时间后，ssl证书错误也随即消失。

在网上找相关的知识想补一下，大部分都是说SSL双方系统时间不一致导致的SSL连接失败，然后怎么解决。再看了你的文章，讲到三次握手的时候，发现这么一段，不知道SSL双方系统时间不一致导致的SSL连接失败是不是因为握手的时候时间不一致导致？真心求解答，探讨。

[come888]

大佬，跪了！

[LeeChar]

还得再看几遍

[lijunyzzZ]

厉害

[SRzhangbob]

你好 我想问一下为什么客户端发送seq = x后服务器发送ack = x + 1而不是ack = x + 2, ack = x + 3等等？？

服务器发送ack= x+1，表示序号x(包含x)以前的包都已正常接收，服务器下次期待收到的包的序号为x+1

[SRzhangbob]

ACK:有两个取值：0和1，为1的时候表示应答域有效，反之为0；ACK不是标志位吗，为啥要ACK = X+1?

ACK:有两个取值：0和1，为1的时候表示应答域有效，反之为0；ACK不是标志位吗，为啥要ACK = X+1?

ACK为确认报文字段，ack为确认应答号，两个不同的呀

SYN、ACK是一个标记位，tcp包头中还有一个确认应答号字段，一般表示为ACK+包序号

[kgamecarter]

可以介紹一下QUIC協議為甚麼可以簡化握手嗎

[Arima-s]

老哥，图裂了

[1445453337]

其实应该是三向握手，而不是三次握手，三个报文结合起来才是一次握手

[stokey]

你好 我想问一下为什么客户端发送seq = x后服务器发送ack = x + 1而不是ack = x + 2, ack = x + 3等等？？

看过 “TCP三次握手四次挥手详解” https://zhuanlan.zhihu.com/p/40013850 文章和《图解TCP/IP》数据TCP首部格式内容之后此处ack应该是确认应答号（Acknowledgement Number）而不是首部控制位的ACK。两者关系是当控制位ACK=1时，确认应答号字段变为有效。确认应答号表示下一次应该收到的数据序列号。发送端收到的这个确认应答以后可以认为在这个序列号以前的数据都已经被正常接收。第二次握手数据应该是：SYN=1，ACK=1，Seq=Y，AckNum=x+1，第三次握手数据应该是：Acknum=y+1，SYN=0，ACK=1。不知道个人理解的是否正确，希望大家多交流。三次握手正确图应该是上面有位老哥提供的图：#14 (comment)

[happyHou]

如果sequence numbers绑定到整个网络时钟，是不是就不需要三次握手这个步骤了？？？

[rorschach214]

好文马克学习

[zhaozhao15]

你好 我想问一下为什么客户端发送seq = x后服务器发送ack = x + 1而不是ack = x + 2, ack = x + 3等等？？

你可以看下这个ack报文的意思，简单来说是确认收到了滴多少个字节

[Detail0805]

@jawil @qingywen
三次握手，这张图更准确些吧。ACK大小写有区分。

对啊 。楼主那个图越看越懵。前文说到 ACK 只有0 和1 有用。图里面的又是X+1

請問一下 傳輸的時候不需要在 傳遞ＡＣＫ＋1 等訊息了嗎？
這樣是否就等同於ＵＤＰ了？

[yi-jingping]

ACK是6个标志位中的一个，值是0或1，1表示确认号有效，0表示无效。可以写作ACKbit=1；
TCP报文中还包含序号（Seq）和确认号（也叫ACK），分别为自己发送数据包的序号和期望收到的对方数据包的序号。和上面的ACK处在报文的不同位置，是两个东西。可以写作ACKnum=x+1。
三次握手中除了确定双方连接正常（发送SYNbit=1，ACKbit=1）同时也交换了双方的序列号（ACKnum=x+1和ACKnum=y+1）。

[leanTim]

图呢图呢 被谁吃了

[iszhaoy]

赞一个啊 收藏了

[samz406]

666

[panchen66]

学习了！

[oneone1995]

图挂了

[okcomputerb]

有一个小小的问题，两次握手会让server浪费资源，请问这个具体浪费的是哪些资源？是连接建立过程中的一些文件读写开销吗？

[iltonmi]

还可以这样写博客，学到了

[ShenYj]

图画的很风趣