文档章节

几种TCP连接中出现RST的情况

costaxu
 costaxu
发布于 2013/05/04 11:40
字数 1669
阅读 60033
收藏 38

应该没有人会质疑,现在是一个网络时代了。应该不少程序员在编程中需要考虑多机、局域网、广域网的各种问题。所以网络知识也是避免不了学习的。而且笔者一直觉得TCP/IP网络知识在一个程序员知识体系中必需占有一席之地的。

在TCP协议中RST表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的。发送RST包关闭连接时,不必等缓冲区的包都发出去,直接就丢弃缓存区的包发送RST包。而接收端收到RST包后,也不必发送ACK包来确认。

其实在网络编程过程中,各种RST错误其实是比较难排查和找到原因的。下面我列出几种会出现RST的情况。

1 端口未打开

服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去telnet一个未打开的TCP的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下,操作系统也会完全不理会这些发到未打开端口请求。

比如在下面这种情况下,主机241向主机114发送一个SYN请求,表示想要连接主机114的40000端口,但是主机114上根本没有打开40000这个端口,于是就向主机241发送了一个RST。这种情况很常见。特别是服务器程序core dump之后重启之前连续出现RST的情况会经常发生。

当然在某些操作系统的主机上,未必是这样的表现。比如向一台WINDOWS7的主机发送一个连接不存在的端口的请求,这台主机就不会回应。

2 请求超时

曾经遇到过这样一个情况:一个客户端连接服务器,connect返回-1并且error=EINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看,客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。

比如像下面这样:

有89、27两台主机。主机89向主机27发送了一个SYN,表示希望连接8888端口,主机27回应了主机89一个SYN表示可以连接。但是主机27却很不友好,莫名其妙的发送了一个RST表示我不想连接你了。

后来经过排查发现,在主机89上的程序在建立了socket之后,用setsockopt的SO_RCVTIMEO选项设置了recv的超时时间为100ms。而我们看上面的抓包结果表示,从主机89发出SYN到接收SYN的时间多达110ms。(从15:01:27.799961到15:01:27.961886, 小数点之后的单位是微秒)。因此主机89上的程序认为接收超时,所以发送了RST拒绝进一步发送数据。

3 提前关闭

关于TCP,我想我们在教科书里都读到过一句话,'TCP是一种可靠的连接'。 而这可靠有这样一种含义,那就是操作系统接收到的来自TCP连接中的每一个字节,我都会让应用程序接收到。如果应用程序不接收怎么办?你猜对了,RST。

看两段程序:


//server.c

int main(int argc, char** argv)  
{  
    int listen_fd, real_fd;  
    struct sockaddr_in listen_addr, client_addr;  
    socklen_t len = sizeof(struct sockaddr_in);  
    listen_fd = socket(AF_INET, SOCK_STREAM, 0);  
    if(listen_fd == -1)  
    {  
        perror("socket failed   ");  
        return -1;  
    }  
    bzero(&listen_addr,sizeof(listen_addr));  
    listen_addr.sin_family = AF_INET;  
    listen_addr.sin_addr.s_addr = htonl(INADDR_ANY);  
    listen_addr.sin_port = htons(SERV_PORT);  
    bind(listen_fd,(struct sockaddr *)&listen_addr, len);  
    listen(listen_fd, WAIT_COUNT);  
    while(1)  
    {  
        real_fd = accept(listen_fd, (struct sockaddr*)&client_addr, &len);  
        if(real_fd == -1)  
        {  
            perror("accpet fail  ");  
            return -1;  
        }  
        if(fork() == 0)  
        {  
            close(listen_fd);  
            char pcContent[4096];
            read(real_fd,pcContent,4096);
            close(real_fd);  
            exit(0);              
        }  
        close(real_fd);  
    }     
    return 0;  
}
这一段是server的最简单的代码。逻辑很简单,监听一个TCP端口然后当有客户端来连接的时候fork一个子进程来处理。注意看的是这一段fork里面的处理:



char pcContent[4096];
read(real_fd,pcContent,4096);
close(real_fd);
每次只是读socket的前4096个字节,然后就关闭掉连接。


然后再看一下client的代码:


//client.c
int main(int argc, char** argv)  
{  
    int send_sk;  
    struct sockaddr_in s_addr;  
    socklen_t len = sizeof(s_addr);  
    send_sk = socket(AF_INET, SOCK_STREAM, 0);  
    if(send_sk == -1)  
    {  
        perror("socket failed  ");  
        return -1;  
    }  
    bzero(&s_addr, sizeof(s_addr));  
    s_addr.sin_family = AF_INET;  

    inet_pton(AF_INET,SER_IP,&s_addr.sin_addr);  
    s_addr.sin_port = htons(SER_PORT);  
    if(connect(send_sk,(struct sockaddr*)&s_addr,len) == -1)  
    {  
        perror("connect fail  ");  
        return -1;  
    }  
    char pcContent[5000]={0};
    write(send_sk,pcContent,5000);
    sleep(1);
    close(send_sk);
}
这段代码更简单,就是打开一个socket然后连接一个服务器并发送5000个字节。刚才我们看服务器的代码,每次只接收4096个字节,那么就是说客户端发送的剩下的4个字节服务端的应用程序没有接收到,服务器端的socket就被关闭掉,这种情况下会发生什么状况呢,还是抓包看一看。


前三行就是TCP的3次握手,从第四行开始看,客户端的49660端口向服务器的9877端口发送了5000个字节的数据,然后服务器端发送了一个ACK进行了确认,紧接着服务器向客户端发送了一个RST断开了连接。和我们的预期一致。

4 在一个已关闭的socket上收到数据

如果某个socket已经关闭,但依然收到数据也会产生RST。

代码如下:

客户端:

int main(int argc, char** argv)  
{  
    int send_sk;  
    struct sockaddr_in s_addr;  
    socklen_t len = sizeof(s_addr);  
    send_sk = socket(AF_INET, SOCK_STREAM, 0);  
    if(send_sk == -1)  
    {  
        perror("socket failed  ");  
        return -1;  
    }  
    bzero(&s_addr, sizeof(s_addr));  
    s_addr.sin_family = AF_INET;  

    inet_pton(AF_INET,SER_IP,&s_addr.sin_addr);  
    s_addr.sin_port = htons(SER_PORT);  
    if(connect(send_sk,(struct sockaddr*)&s_addr,len) == -1)  
    {  
        perror("connect fail  ");  
        return -1;  
    }  
    char pcContent[4096]={0};
    write(send_sk,pcContent,4096);
    sleep(1);
    write(send_sk,pcContent,4096);
    close(send_sk);
} 
服务端:

int main(int argc, char** argv)  
{  
    int listen_fd, real_fd;  
    struct sockaddr_in listen_addr, client_addr;  
    socklen_t len = sizeof(struct sockaddr_in);  
    listen_fd = socket(AF_INET, SOCK_STREAM, 0);  
    if(listen_fd == -1)  
    {  
        perror("socket failed   ");  
        return -1;  
    }  
    bzero(&listen_addr,sizeof(listen_addr));  
    listen_addr.sin_family = AF_INET;  
    listen_addr.sin_addr.s_addr = htonl(INADDR_ANY);  
    listen_addr.sin_port = htons(SERV_PORT);  
    bind(listen_fd,(struct sockaddr *)&listen_addr, len);  
    listen(listen_fd, WAIT_COUNT);  
    while(1)  
    {  
        real_fd = accept(listen_fd, (struct sockaddr*)&client_addr, &len);  
        if(real_fd == -1)  
        {  
            perror("accpet fail  ");  
            return -1;  
        }  
        if(fork() == 0)  
        {  
            close(listen_fd);  
            char pcContent[4096];
            read(real_fd,pcContent,4096);
            close(real_fd);  
            exit(0);              
        }  
        close(real_fd);  
    }     
    return 0;  
} 
客户端在服务端已经关闭掉socket之后,仍然在发送数据。这时服务端会产生RST。

总结

总结,本文讲了几种TCP连接中出现RST的情况。实际上肯定还有无数种的RST发生,我以后会慢慢收集把更多的例子加入这篇文章。

参考文献:

1 从TCP协议的原理来谈谈RST攻击 http://russelltao.iteye.com/blog/1405349

2 TCP客户-服务器程序例子http://blog.csdn.net/youkuxiaobin/article/details/6917880
 

© 著作权归作者所有

共有 人打赏支持
costaxu

costaxu

粉丝 147
博文 56
码字总数 86451
作品 0
深圳
程序员
私信 提问
加载中

评论(7)

d
dante502

引用来自“哈喽楷体”的评论

第四点我有疑问,服务器发送fin后,本来就是可以继续接受客户端的数据的。

引用来自“novohust”的评论

需要搞清close和shutdown的区别,虽然二者都是发送FIN,但前者的语义是关闭读和写,后者仅关闭写(所以是半关闭);向前者继续发送数据将得到RST,因为close意味着“不愿意再收到数据了”,后者是可以正常读的。
为什么我把第四个程序运行后,客户端的write一直返回4096,并不是一个0或者-1呢?
去开原
去开原
还有一种情况,楼主没说道,当服务端一直zero window的时候,客户端也会发送RST
inu1255
inu1255
出现这个问题最主要的原因是gfw
novohust
novohust

引用来自“哈喽楷体”的评论

第四点我有疑问,服务器发送fin后,本来就是可以继续接受客户端的数据的。
需要搞清close和shutdown的区别,虽然二者都是发送FIN,但前者的语义是关闭读和写,后者仅关闭写(所以是半关闭);向前者继续发送数据将得到RST,因为close意味着“不愿意再收到数据了”,后者是可以正常读的。
novohust
novohust

引用来自“小树成长”的评论

你好,我对第三点有点小小疑问哇。我觉得关闭操作是发送fin包还是rst包,应该不是单单根据缓冲区有无数据决定的哦。应该还和socket的一些其他设置有关哦?
SO_LINGER可以设置close()发送RST还是FIN断开连接。
哈喽楷体
哈喽楷体
第四点我有疑问,服务器发送fin后,本来就是可以继续接受客户端的数据的。
小树成长
你好,我对第三点有点小小疑问哇。我觉得关闭操作是发送fin包还是rst包,应该不是单单根据缓冲区有无数据决定的哦。应该还和socket的一些其他设置有关哦?
几种TCP连接中出现RST的情况

快速浏览 正常情况tcp四层握手关闭连接,rst基本都是异常情况,整理如下: 1. GFW 2. 对方端口未打开,发生在连接建立   如果对方sync_backlog满了的话,sync简单被丢弃,表现为超时,而不...

moodlxs
2016/05/13
55
0
TCP控制字段标志:URG、ACK、PSH、RST、SYN、FIN

在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG. 其中,对于我们日常的分析有用的就是前面的五个字段。 它们的含义是: URG:Urget pointer is valid (紧急指...

cnsytem
2014/04/30
0
0
linux网络编程常见socket错误分析

常见socket错误码 EINTR: 阻塞的操作被取消阻塞的调用打断。如设置了发送接收超时,就会遇到这种错误。 只能针对阻塞模式的socket。读,写阻塞的socket时,-1返回,错误号为INTR。另外,如果...

水海云
2013/11/21
3.4K
0
TCP的几种状态: (SYN, FIN, ACK, PSH, RST, URG)

在TCP层,有个FLAGS字段,这个字段有以下几个标识:SYN, FIN, ACK, PSH, RST, URG. 其中,对于我们日常的分析有用的就是前面的五个字段。它们的含义是:SYN表示建立连接,FIN表示关闭连接,A...

souldepth
2014/06/16
0
0
tcp短连接TIME_WAIT问题解决方法大全

tcp连接是网络编程中最基础的概念,基于不同的使用场景,我们一般区分为“长连接”和“短连接”, 长短连接的优点和缺点这里就不详细展开了,有心的同学直接去google查询,本文主要关注如何解...

zhangyujsj
2016/10/12
65
0

没有更多内容

加载失败,请刷新页面

加载更多

MySQL查询执行

当我们希望MySQL能够以更高的性能运行查询时,最好的办法就是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点,很多查询优化工作实际上就是遵循一些原则让优化器能够按照预想的合理方式...

Linux就该这么学
3分钟前
0
0
爱可生开源社区官网正式发布啦!

近期大事记 2018/12/31 DBLE年度报告发版 2019/01/07 DBLE 2.18.12.0 新版发布,修复 issue 60+ 2019/01/09 DBLE 2.18.12.0 Release Notes 详细解读 2019/01/15 DBLE Logo 首发 + DBLE 团队迎......

爱可生
11分钟前
0
0
【分布式缓存系列】Redis实现分布式锁的正确姿势

一、前言   在我们日常工作中,除了Spring和Mybatis外,用到最多无外乎分布式缓存框架——Redis。但是很多工作很多年的朋友对Redis还处于一个最基础的使用和认识。所以我就像把自己对分布式...

编辑之路
22分钟前
0
0
3.x 在Unix系统上面启动守护进程

12.14 在Unix系统上面启动守护进程 问题 你想编写一个作为一个在Unix或类Unix系统上面运行的守护进程运行的程序。 解决方案 创建一个正确的守护进程需要一个精确的系统调用序列以及对于细节的...

dragon_tech
22分钟前
0
0
ES6中的class

class Point {constructor(x, y, z) {this.x = x;this.y = y;this.z = z;}toString() {return `${this.x},${this.y}`}get prop() {return `获取的是get${this.z...

chinahufei
25分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部