手机版
你好,游客 登录 注册
背景:
阅读新闻

关于TCP连接建立与终止那点事

[日期:2015-09-08] 来源:Linux社区  作者:jabnih [字体: ]

0. 前言

  最近在处理公司遗留项目的时候发现自己对TCP协议一点都不懂,所以补了点关于TCP连接的建立和终止的内容,这里简单写下自己了解的部分,省略了报文序号确认序号这些无关的字段,主要讨论TCP状态的转换以及Linux下的一些问题。

  对于这篇文章来说,主要是记录自己遇到的一些问题以及学习到的一些东西。

  关于TCP/IP协议,这里推荐一本书:《TCP/IP协议详解:卷1》

1. TCP连接的建立

  学过计算机网络的都知道TCP连接的建立需要三次握手,当时在大学也这么听着,但是具体怎么三次还是最近补了才知道这么回事。

  对于客户端/服务器模型来说:

  1. 首先客户端发起连接(发送SYN报文,进入SYN_SENT状态)

  2. 服务器接收到SYN,然后响应(发送SYN ACK,进入SYN_RCVD状态,注意这个时候连接并没有建立)

  3. 客户端接受到后,发送确认报文(发送ACK,进入Established状态)

  4. 服务器收到后才进入链路建立(Established)状态。

如下图(图为百度搜出来的)

 

2. TCP连接的终止

  对于TCP连接的终止来说,却需要四次挥手来完成,这里以客户/服务器模型,客户端主动发起关闭来说明(这里服务器也可以发起主动发起关闭)。

  1. 客户端发送FIN(进入FIN_WAIT_1状态)

  2. 服务器接收到FIN后对发送ACK确认(此时服务器进入CLOSE_WAIT状态,客户端接受到该ACK后由FIN_WAIT_1 转为FIN_WAIT_2状态)

  3. 服务器调用close发送FIN(进入LASK_ACK状态)

  4. 客户端接收到服务器发送的FIN后发送ACK(进入TIME_WAIT状态)

  5. 服务器接收到后结束(LASK_ACK状态转为虚拟的CLOSED,即已经没有状态了)

如下图所示:

 

3. TCP状态转换

  其实如果看懂了上面连接的建立以及终止的话,很容易就可以看懂下面的状态转换图,上面两个就可以看做由它拆解出来的。

 

4. 遇到CLOSE_WAIT状态的一些情况

  前面说了,最近在维护一些历史遗留的项目,那代码简直是叼炸天了,直接使用两个进程共用一个select,在accept前加上文件锁,select只监听服务器端fd,其它fd不监听....(此处省略一千字),然后现在出现了大量的CLOSE_WAIT状态,我在想难道以前就没出现过?奇葩。不过被DDoS攻击有些也会出现这种现象。最后讨论了一下午说怎么样才能少改动原来的代码....最后老大拍板,重写select部分~^~,使用epoll实现。

  上面的状态图可以看出,服务器由于接收到客户端发来的FIN,会进入CLOSE_WAIT,如果此时没有监听该客户端fd并且没有调用close,那么这时会导致占用的FD没有被释放,资源就这么被泄漏掉了,这样也会导致存在大量的CLOSE_WAIT状态,以至于后续FD消耗完了的时候(一般系统默认1024),accept就会失败。(注:这里CLOSE_WAIT状态是由于应用程序没有调用close导致的,系统不会释放该资源,即会一直存在)

  (注:即使accept失败,但是对于链路来说,还是能建立成功的,因为对于Linux TCP底层实现来说,存在两个队列,一个为半链路队列,另一个为三次握手成功但是没有被服务器accept取走的链接的队列。)

  后续对于Linux下的服务器来说一般都是使用epoll来处理,效率比select高。

 

5. 补充

  这里看到一些博客说通过设置系统参数来改变CLOSE_WAIT的维持等待时间,我查阅了一下,并且也尝试过(其实不用试)。不能够通过设置系统参数来更改的,因为这时应用程序内部导致的,,而且根本就不存在说CLOSE_WAIT维持时间一说,该状态只有应用程序调用close才会转为其它状态(或者关闭应用程序),这里说通过修改系统参数一般指的时TIME_WAIT状态的维持时间。

本文永久更新链接地址http://www.linuxidc.com/Linux/2015-09/122777.htm

linux
相关资讯       TCP  TCP连接 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款