tcp有限状态机分析

简介:

tcp有限状态机

 

这幅图是TCP的状态机,看了2个小时,分析总结如下:

(1)CLOSED 状态时初始状态。

(2)LISTEN:被动打开,服务器端的 状态变为LISTEN(监听)。被动打开的概念:连接的一端的应用程序通知操作系统,希望建立一个传入的连接。这时候操作系统为连接的这一端建立一个连 接。与之对应的是主动连接:应用程序通过主动打开请求来告诉操作系统建立一个连接。

(3)SYNRECVD:服务器端收到SYN后,状态为SYN;发送SYN ACK;

 (4) SYN_SENTY:应用程序发送SYN后,状态为SYN_SENT;

(5)ESTABLISHED:SYNRECVD收到ACK后,状态为ESTABLISHED; SYN_SENT在收到SYN ACK,发送ACK,状态为ESTABLISHED;

(6)CLOSE_WAIT:服务器端在收到FIN后,发送ACK,状态为CLOSE_WAIT;如果此时服务器端还有数据需要发送,那么就发送,直到数据发送完毕;此时,服务器端发送FIN,状态变为LAST_ACK;

(7)FIN_WAIT_1:应用程序端发送FIN,准备断开TCP连接;状态从ESTABLISHED——>FIN_WAIT_1;

(8)FIN_WAIT_2:应用程序端只收到服务器端得ACK信号,并没有收到FIN信号;说明服务器端还有数据传输,那么此时为半连接;

(9)TIME_WAIT:有两种方式进入 该状态:1、FIN_WAIT_1进入:此时应用程序端口收到FIN+ACK(而不是像FIN_WAIT_2那样只收到ACK,说明数据已经发送完毕)并 向服务器端口发送ACK;2、FIN_WAIT_2进入:此时应用程序端口收到了FIN,然后向服务器端发送ACK;TIME_WAIT是为了实现TCP 全双工连接的可靠性关闭,用来重发可能丢失的ACK报文;需要持续2个MSL(最大报文生存时间):假设应用程序端口在进入TIME_WAIT后,2个 MSL时间内并没有收到FIN,说明应用程序最后发出的ACK已经收到了;否则,会在2个MSL内在此收到ACK报文;

 

 2011.9.14补充:

关闭的状态转换比较复杂:现在设通信双方是A,B,A是主动发起关闭方

(1)      主动发起关闭方:

A首先主动发起FIN报文,准备关闭TCP连接,然后进入FIN_WAIT1状态;然后,如果A收到了ACK报文,就进入FIN_WAIT2状态;而如果A收到的是ACK + FIN,A进入TIME_WAIT状态。

进入FIN_WAIT2状态,说明B还有数据发给A。过了不久之后,B发送FIN给A,然后,A发送ACK,并进入TIME_WAIT状态。当2个MSL内,没有收到FIN信号,那么TIME_WAIT就自动转化为CLOESD。(为什么TIME_WAIT状态要进过2个MSL(Maximum Segment Lifetime.)才能进入CLOSED状态?假设网路是不可靠的,最后A发出的ACK信号丢失,那么B就没有收到ACK,此时B还需要重新发一个FIN给A,这个过程最多需要2MSL,所以如果过了2MSL,没有再次收到B的FIN,那么,说明之间A发出的ACK被B收到了,所以可以可靠地关闭连接。)

(2)      被动接收方

B在收到A的FIN报文后,知道A准备关闭 TCP连接了(注意只是A单方面关闭,也就是说,A还可以收数据,但是不准备发数据了)。B将发送ACK给A,然后B进入CLOSED_WAIT状态。如 果此时B也有数据发送给A,那么就一直发送好了,反正A不会发数据了。此时A处于FIN_WAIT2状态。当B的数据发送完毕之后,那么B发送FIN给 A,B进入LAST_ACK状态。当收到A发过来的ACK信号后,A进入CLOSED状态。

问题:

1、 为什么建立连接协议是三次握手,而关闭连接却是四次握手呢
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后,它可以把ACK和SYN(ACK起应答作用,而SYN起同步作用)放在 一个报文里来发送。但关闭连接时,当收到对方的FIN报文通知时,它仅仅表示对方没有数据发送给你了;但未必你所有的数据都全部发送给对方了,所以你可以 未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后,再发送FIN报文给对方来表示你同意现在可以关闭连接了,所以它这里的ACK报 文和FIN报文多数情况下都是分开发送的。

TCP的关闭连接的时候,状态很多,以刚才的例子分类:一个是主动发起方涉及的状态,一个被动发起方涉及的状态:

 

主动发起方:

FIN_WAIT1(发出FIN信号)

FIN_WAIT2(收到ACK信号)

TIME_WAIT(收到FIN信号)

CLOSED(2个MSL后,没有再次收到FIN,进入)

 

被动接收方:

CLOSED_WAIT(收到FIN信号)

LAST_ACK(发出FIN信号)

CLOSED(收到ACK信号,如果没有,再次发出FIN信号)

2.为什么能三次握手、四次挥手可靠地建立关闭连接?

注意可靠。

答:在建立连接的时候,首先需要发起方发出请求(即发出带有SYN的报文),接收方收到后必须给发起方一个回应(ACK+SYN)

,关键是这里还没有完毕。因为网络是不可靠地,(a)如果发起方没有收到应答方的ACK+SYN报文,显然,说明报文丢失,必须重发请求;(b)如果发起方收到ACK+SYN后,不再向接收方发出ACK信号(更正于2011.9.17)(也 就是只有两次握手,此时开始传递报文),那么从发起方的角度来看,它认为自己发出的ACK+SYN报文丢失了,接收方没有收到,所以它会再次重发。(c) 当发起方发出ACK信号后,如果没有收到接收方再次发来的ACK+SYN报文,那么说明接收方收到了自己发出的ACK报文,所以可以建立连接了。

举个例子,如何保障可靠通信:

现在A和B两支军队准备在10:00同时发起进攻,如何才能保证这两支军队同时呢?

现在A发出电报,“要求在10:00同时发起进攻”;

B收到后,显然必须向A回复“收到,可以”。

A在收到“收到,可以”的消息后,直到B已 经收到了自己发出的消息。注意,这里还没有完,如果你站在B的角度去思考:“我发出了‘收到,可以’的消息,必须要求A给我一个回应。如果我没有收到回 应,那么就说明我的这个消息没有送到A那里去”,那么,我得再传一次“收到,可以”的消息跟A。所以,A必须再次发出“你的消息已经收到”的消息发送给 B。此时,如果A没有再次收到B发来的“收到,可以”的消息,就可以认为自己的“你的消息已经收到”送给了B。而实际上,如果B收到A发来的“你的消息”我已经收到,说明,自己此前发出的消息已经被A收到。

这样,就可以保证A,B可靠地收到消息,保证他们在10:00准时发起进攻。




本文转自 fenghao.cn 51CTO博客,原文链接:http://blog.51cto.com/linuxguest/722199,如需转载请自行联系原作者
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
网络协议 C语言
Wireshark lua dissector 对TCP消息包合并分析
Wireshark lua dissector 对TCP消息包合并分析
1015 0
|
网络协议
Wireshark抓包分析/TCP/Http/Https及代理IP的识别
前言   坦白讲,没想好怎样的开头。辗转三年过去了。一切已经变化了许多,一切似乎从没有改变。   前段时间调研了一次代理相关的知识,简单整理一下分享之。如有错误,欢迎指正。 涉及 Proxy IP应用 原理/层级wireshark抓包分析 HTTP head: X-Forwarded-For/ Proxy-Connection/伪造  X-Forwarded-For/ 以及常见的识别手段等几个方面。
2849 0
|
监控 网络协议 Java
netstat统计的tcp连接数与⁄proc⁄pid⁄fd下socket类型fd数量不一致的分析
新blog地址: http://hengyunabc.github.io/netstat-difference-proc-fd-socket-stat/ 最近,线上一个应用,发现socket数缓慢增长,并且不回收,超过警告线之后,被运维监控自动重启了。
2122 0
|
网络协议
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
ACK的累加规则-wireshark抓包分析-不包含tcp头部、ip头部、数据链路层头部等。
|
网络协议 安全 测试技术
TCP 编程快速入门案例分析 | 学习笔记
快速学习 TCP 编程快速入门案例分析
TCP 编程快速入门案例分析 | 学习笔记
|
监控 网络协议 NoSQL
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密
TCP的开销到底有多大,能否进行量化。一条TCP连接的建立需要耗时延迟多少,是多少毫秒,还是多少微秒?能不能有一个哪怕是粗略的量化估计?
841 0
不为人知的网络编程(十一):从底层入手,深度分析TCP连接耗时的秘密
|
Web App开发 网络协议 架构师
接口协议之抓包分析 TCP 协议
TCP 协议是在传输层中,一种面向连接的、可靠的、基于字节流的传输层通信协议。 ## 环境准备 对接口测试工具进行分类,可以如下几类: - 网络嗅探工具:tcpdump,wireshark - 代理工具:fiddler,charles,anyproxyburpsuite,mitmproxy - 分析工具:curl,postman,chrome Devtool - ## 抓包分析TCP协
|
Web App开发 网络协议 架构师
接口协议之抓包分析 TCP 协议
TCP 协议是在传输层中,一种面向连接的、可靠的、基于字节流的传输层通信协议。 ## 环境准备 对接口测试工具进行分类,可以如下几类: - 网络嗅探工具:tcpdump,wireshark - 代理工具:fiddler,charles,anyproxyburpsuite,mitmproxy - 分析工具:curl,postman,chrome Devtool - ## 抓包分析TCP协
|
Web App开发 网络协议 测试技术
接口协议之抓包分析 TCP 协议
接口协议之抓包分析 TCP 协议

热门文章

最新文章