TCP恋爱史:三次握手和四次分手

TCP恋爱史:三次握手和四次分手


一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环。

以我们最近出现的

TCP协议非常重要,这里把它的连接和释放整理一下。

首先是三次握手:

1、 客户端发起,像服务器发送的报文SYN=1,ACK=0,然后选择了一个初始序号:seq=x。

SYN是干什么用的?

在链接的时候创建一个同步序号,当SYN=1同时ACK=0的时候,表明这是一个连接请求的报文段。如果对方有意链接,返回的报文里面SYN=1,ACK=1,。从这个意义上来说,SYN=1的时候,就表明这是一个‘请求’或者‘接受请求’的报文。

SYN=1的报文段不能携带数据。但是要消耗掉一个序号,

ACK是干什么用的?

仅当ACK=1的时候,确认字号(期望收到对方下一个报文段的第一个数据字节的编号)才有效。因此,TCP规定,当链接建立之后,所有往来的报文里面的ACK都应该是1(事实上,也只有客户端发起的链接请求报文的ACK没有置1)。

现在的状态:客户端进入SYN-SEND状态;

2、 服务器接收到了SYN=1,ACK=0的请求报文之后,返回一个SYN=1,ACK=1的确认报文。

同时,确认号ack=x+1,同时也为自己选择一个初始序号seq=y

现在的状态:服务器进入SYN-REVD状态;

3、 客户端接收到了服务器的返回信息之后,还要给服务器返回最后一条确认,ACK=1,确认号ack=y+1;

现在的状态:客户端进入ESTABLISHED状态。

下面说一下为什么两次握手不行,非得三次:

首先说明一种正常的情况,就是客户端发送了一条请求链接的报文,但是由于网络原因丢失了,所以,不可能接收到服务器端的确认。这个时候,客户端就就只有再一次发送原来的请求报文,这次服务器收到之后返回确认,客户端再确认一次,链接确立。

然后考虑一种不正常的情况,客户端发了两次请求链接的报文,第二条被服务器捕捉到,返回数据,完成了两次握手。数据传送完成之后,链接关闭。但是这时候,第一条拥塞的请求报文现在到达了服务器端,服务器还以为客户端要又一次建立连接,于是发送确认,然后把自己敞开,等着客户端发送过来数据。于是,很多的网络资源就是这样浪费掉了。

要是实行三次握手,服务器收到了一条过期的请求报文,返回确认信息,客户端接收到了服务器的信息之后感到莫名其妙,心想:我他妈又没要链接,你返回这个是不是疯了。于是不置一词。服务器过一段时间还没有收到第三次握手的数据,知道客户端并没有要求建立链接的请求,含泪离开。

然后是四次分手:

现在双方的状态都是ESTABLISHED状态。

1、 客户端发起请求,请求断开链接。FIN=1,seq=u。u是之前传送过来的最后一个字节的序号+1。

FIN:用来释放一个链接,当FIN=1的时候,表明此报文的发送方已经完成了数据的发送,没有新的数据要传送,并要求释放链接。

客户端进入FIN-WAIT-1状态,等着服务器返回确认;

2、 服务器收到客户端的请求断开链接的报文之后,返回确认信息。ACK=1,seq=v,ack=u+1。

服务器进入CLOSE-WAIT状态。

这个时候,客户端不能给服务器发送信息报文,只能接收。但是服务器要是还有信息要传给服务器,仍然能传送。

3、 当服务器也没有了可以传的信息之后,给客户端发送请求结束的报文。FIN=1,ACK=1,

ack=u+1,seq=w。

这个时候的状态:服务器进入LAST-ACK状态。

4、 客户端接收到FIN=1的报文之后,返回确认报文,ACK=1,seq=u+1,ack=w+1。

发送完毕之后,客户端进入等待状态,等待两个时间周期。关闭。

为什么最后还要等待两个时间周期呢?

1、 客户端的最后一个ACK报文在传输的时候丢失,服务器并没有接收到这个报文。这个候。

服务器就会超时重传这个FIN消息,然后客户端就会重新返回最后一个ACK报文,等待两个时间周期,完成关闭。如果不等待这两个时间周期,服务器重传的那条消息就不会收到。服务器就因为接收不到客户端的信息而无法正常关闭。

2、 预防上一次在三次握手中提到的失效的报文干扰。两个时间周期过去之后,所有的报文都会在网络中消失,保证下一次重新连接的时候有乱七八糟的报文影响。

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2014-09-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏王二麻子IT技术交流园地

Maven仓库-Nexus环境搭建及简单介绍

1.    环境搭建      1.1  下载 http://www.sonatype.org/nexus/     NEXUS OSS [OSS = O...

3075
来自专栏程序猿DD

TCP之三次握手四次挥手

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

18010
来自专栏coderhuo

TCP连接建立、断开过程详解

TCP连接建立过程需要经过三次握,断开过程需要经过四次挥手,为什么? 有没有其他的连接建立、断开方式?

1142
来自专栏Java架构师历程

TCP连接的状态详解以及故障排查

我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助。(总结网络上的内容)

9592
来自专栏知识分享

关于Altium Designer 提示发送错误报告解决方法

提示是这样子,,,,,, ? 稍微有点问题就提示,,,复制也提示,,,,移动也提示,,,,,,算是服了这个软件了.......真是忍无可忍,那就无需再忍,解决掉...

2624
来自专栏HTML5学堂

前端工程化 | 揭秘程序员的提速“外挂”

前端开发的工作往往需要把LESS/SASS编译成CSS文件,对多个JS、CSS文件进行合并与压缩处理,对JS、CSS进行语法的检查等,上面提到的这些都是一些重复...

39911
来自专栏杨龙飞前端

使用webpack打包vue工程

2347
来自专栏高性能服务器开发

从抓包的角度分析connect()函数的连接过程

这篇文章主要是从tcp连接建立的角度来分析客户端程序如何利用connect函数和服务端程序建立tcp连接的,了解connect函数在建立连接的过程中底层协议栈做...

1331
来自专栏专注 Java 基础分享

看懂「www.google.com」背后的逻辑

在前两篇文章中,我们完整的描述了计算机网络 OSI 五层模型的相关内容。那么,本篇将会从一个实践案例开始,带你从整体上重新认识我们的计算机网络。

940
来自专栏用户2442861的专栏

【网络协议】TCP连接的建立和释放

转载请注明出处:http://blog.csdn.net/ns_code/article/details/29382883

1501

扫码关注云+社区

领取腾讯云代金券