TCP/IP会话与状态-阿里云开发者社区

开发者社区> 余二五> 正文

TCP/IP会话与状态

简介:
+关注继续查看

 一,TCP,UDP协议在OSI模型中属于传输层,传输层的功能定义了传输数据的协议和端口号。IP协议属于网络层,网络层的功能将从下层接收到的数据进程IP地址的封装与解封装。

   TCP协议的六个标志位:

   URG为紧急数据标志,如果URG为1,表示本数据包中包含紧急数据。此时紧急数据指针表示的值有效,它表示在紧急数据之后的第一个字节的偏移值(即紧急数据的总长度)。

   ACK为确认标志位。如果ACK为1,表示数据包中的确认号有效。

   PSH位,表示强迫数据传输。

   RST标志位用来复位一条连接。当RST=1时,表示出现严重错误,必须释放连接,然后再重新建立。

   SYN标志位用来建立连接,如果SYN=1而ACK=0,表明它是一个连接请求;如果SYN=1且ACK=1,则表示同意建立一个连接。

   FIN为1时,表示数据已经发送完毕,希望释放连接。

 二,下面几种情况是不合法的标志位组合。

1、所有标志位都为0。

2、SYN和FIN同时被置1。

3、SYN和RST同时被置1。

4、FIN和RST同时被置1。

5、FIN位被置1,但ACK位没有被置1。

6、PSH位被置1,但ACK位没有被置1。

7、URG位被置1,但ACK位没有被置1。

三,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状态,完成三次握手。

 在这里引入一个常见的syn攻击(dos攻击):客户端发送大量syn请求,然后服务端发送syn/ack,但是客户端并不回应ack,当服务器未收到客户端的确认包时,重发请求包,一直到超时,才将此条目从未连接队列删除。因此服务端维持大量syn请求,配合IP欺骗,SYN攻击能达到很好的效果,通常,客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送syn包,服务器回复确认包,并等待客户的确认,由于源地址是不存在的,服务器需要不断的重发直至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,目标系统运行缓慢,严重者引起网络堵塞甚至系统瘫痪。如果服务端syn_rcvd个数超出正常的时,有可能被攻击。

查看在LINUX环境下某个端囗的未连接队列的条目数:

#netstat -nt |grep SYN_RECV |grep :22 |wc -l 

 四,tcp四次断开

 

当服务端主动发达fin,等待客户端的fin时,服务端需要在内存中维持这个状态,如果控制客户端永久不发送。则当内存耗尽时将无法再响应别的请求,因此fin_wait_2是很危险的状态,所以最好不要让服务端主动断开,而且每个应用程序能打开的套接字有限,会导致别的请求无法再响应。

 五,tcp整个连接状态图,这图是简化的,正常关闭情况下的流程是这样的。

 六,解释各种状态:

closed:表示初始状态。

listen:表示socket处于监听状态,因此服务端是被动启动。

syn_rcvd:表示服务端接收到客户端的syn报文。

syn_sent:表示客户端已发送syn报文,因此客户端是主动启动。当客户端需要请求资源时,会执行socket,首先发送syn报文,随即进程syn_sent状态。

established:表示已经完成三次握手,咱们开始谈恋爱吧

fin_wait_1:客户端发送完fin后的状态。

fin_wait_2:客户端收到服务端的ack后。

time_wait:客户端发送完ack后。并在此状态等待2ms后,自动进入closing状态。

close_wait:收到客户端fin,并发送ack。

last_ack:服务端等对方的ack,当收到ack后,表示咱俩分手,永不见面。

七,在TCP/IP原始的图片中,可能还会出现下面情况

1,服务器端主动关闭,establelished(发送fin)--->fin_wait_1(等待客户端的ack)-->fin_wait_2(等待客户端的fin,此时fin_wait_2可以永久存在内存中)--time_wait

客户端被动关闭:establelished--->close_wait(发送ack,fin)---last_ack(等待对方的ack包,如果收到ack)--->closed

正常情况下,fin_wait_2存在的时间很短暂,因此,图又可以简化成这样。

2,假设都是服务端提供服务,都同时关闭,则此时不区分服务端与客户端

establelished--->fin_wait_1(同时发送ack,fin)--->closeding--->time_wait










本文转自 deng304749970 51CTO博客,原文链接:http://blog.51cto.com/damondeng/1060887,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4479 0
分析几种TCP状态转换中的非正常转换
  1、服务器从listen状态变成close状态的原因:   服务器在监听端口的时候,此时有些资源加载的有问题导致服务没开启,此时服务器会从listen状态变成closed状态。
734 0
[转载红鱼儿]kbmmw 开发点滴:kbmWTCPIPInfyClientTransport联接状态
kbmWTCPIPInfyClientTransport联接状态 当客户端请求一个Service时,kbmWTCPIPInfyClientTransport.Active是什么样呢?做一个简单的测试,原来是这样:当 kbmMWSimpleClient1.Request时,会检查使用的Transport是否Active,如果没有打开,则Active=True. 调用后,Transport.Active自动为True!当检查到已经为Active,则直接发出请求Request。
670 0
TCP的十一种状态与三次握手分析(有图)
我们知道TCP是面向连接的,我们只知道有连接断开,其实内部还有一些比较复杂的状态。去了解各个状态之间的切换有助于我们更加深入的了解TCP。下面我们就来分析各个状态。 1、如下图示(图源百度)图中显示出了10种状态。
1335 0
TCP TIME_WAIT状态解析及问题解决
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/zhaobryant/article/details/80557158 一、TCP四次挥手过程 TCP在建立连接时需要握手,同理,在关闭连接的时候也需要握手。
2001 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
3227 0
+关注
12613
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载