一道腾讯面试题目：没有listen，能否建立TCP连接

TCP与UDP最大的不同&＃xff0c;就是有连接的概念&＃xff0c;而连接的建立是由内核完成的。系统调用listen&＃xff0c;就是为了告诉内核&＃xff0c;它要处理发给这个TCP端口的连接请求。所以对于这个题目&＃xff0c;最直接的想法就是由应用层自己负责TCP的连接。为了能够收到TCP的握手数据包&＃xff0c;可以尝试使用原始套接字来接收IP报文&＃xff0c;这样就可以在应用层替代内核做TCP的三次握手了。这个想法不错&＃xff0c;可惜现实比较残酷。

当没有对于TCP 套接字处于listen状态时&＃xff0c;使用raw socket处理握手报文时&＃xff0c;即使收到了syn报文并给对端发送了syn&＃43;ack报文&＃xff0c;也无法完成连接。因为内核一般会提前发送RST中断该连接。七年前&＃xff0c;我当时只知道这个结果。现在呢&＃xff0c;可以明确的知道为什么内核会发送RST报文&＃xff0c;中断连接。内核在ip_local_deliver_finish先将报文复制一份给原始套接字&＃xff0c;然后会继续后面的处理&＃xff0c;进入tcp的接收函数tcp_v4_rcv。在这个函数中&＃xff0c;要进行套接字的查找。

因为没有监听的tcp套接字&＃xff0c;自然无法找到对应的套接字。于是跳转到no_tcp_socket。

在这个错误处理中&＃xff0c;只要数据包skb的校验和没错&＃xff0c;内核就会调用tcp_v4_send_reset发送RST中止这个连接。因此&＃xff0c;这个单独使用raw socket的方案是行不通的。我们需要找到一种方法&＃xff0c;禁止内核处理该TCP报文。这时&＃xff0c;可以使用iptables的NFQUEUE&＃xff0c;在网络层将数据包取到应用层&＃xff0c;并回复syn&＃43;ack&＃xff0c;同时在reinject时通知内核该数据包被“偷”了&＃xff0c;即NF_STOLEN。这样内核就不会继续处理该数据包skb了。虽然当时我没有继续实验尝试&＃xff0c;但理论上&＃xff0c;通过这个IPtables的NFQUEUE&＃43;NFSTOLEN的方案&＃xff0c;是可以实现“没有listen&＃xff0c;建立TCP连接”的。

【文章福利】需要各一线互联网大厂面试题及C/C&＃43;&＃43; Linux服务器架构师学习资料加群812855908&＃xff08;资料包括C/C&＃43;&＃43;&＃xff0c;Linux&＃xff0c;golang技术&＃xff0c;Nginx&＃xff0c;ZeroMQ&＃xff0c;MySQL&＃xff0c;Redis&＃xff0c;fastdfs&＃xff0c;MongoDB&＃xff0c;ZK&＃xff0c;流媒体&＃xff0c;CDN&＃xff0c;P2P&＃xff0c;K8S&＃xff0c;Docker&＃xff0c;TCP/IP&＃xff0c;协程&＃xff0c;DPDK&＃xff0c;ffmpeg等&＃xff09;

可惜&＃xff0c;在与那位同学的讨论中&＃xff0c;腾讯面试题目的本意不是这个意思&＃xff0c;而是对于普通的TCP套接字来说&＃xff0c;如果没有listen调用&＃xff0c;是否可以创建连接。即使限定了条件&＃xff0c;答案依然是肯定的。只不过限定了条件之后&＃xff0c;我们需要确定2个事情&＃xff1a;

1. 与前面类似&＃xff0c;如何避免内核发送RST。在不能使用iptable的前提下&＃xff0c;这意味着在tcp_v4_rcv中&＃xff0c;要能够找到对应的套接字。
2. 没有listen状态的套接字&＃xff0c;内核是否能够完成TCP的三次握手呢&＃xff1f;

确定第一个问题&＃xff0c;比较简单。只需要对三次握手深入的思考一下&＃xff0c;就可以得到答案。在正常的三次握手中&＃xff0c;当服务端回复syn&＃43;ack时&＃xff0c;客户端实际上也没有处于listen状态的套接字&＃xff0c;但却可以完成三次握手。这意味着&＃xff0c;客户端进行connect调用后&＃xff0c;该套接字一定被加入到某个表中&＃xff0c;并可以被匹配到。跟踪内核源码tcp_v4_connect->inet_hash_connect->__inet_check_established&＃xff0c;可以看到当调用connect时&＃xff0c;对应的套接字就被加入了全局的tcp已连接的表中&＃xff0c;即tcp_hashinfo.ehash中。对应的匹配TCP套接字过程&＃xff0c;如下__inet_lookup_skb->__inet_lookup

内核是先在已经连接的表中查找&＃xff0c;再进行listen表的查找。对于客户端来说&＃xff0c;syn&＃43;ack报文必然可以在已连接表中匹配上对应的套接字。那么&＃xff0c;对于本题目来说&＃xff0c;要想两端都可以找到套接字&＃xff0c;就要求在报文到达前&＃xff0c;两端都调用了connect。也就是说&＃xff0c;当两端同时调用connect时&＃xff0c;两端的syn包就都可以匹配上本地的套接字。

接下来只需要确定对于客户端套接字来说&＃xff0c;收到syn报文&＃xff0c;是否可以正常处理。tcp_rcv_synsent_state_process函数是TCP套接字处于synsent状态&＃xff08;即调用了connect&＃xff09;的处理函数。下面是其一部分实现代码&＃xff1a;

从上&＃xff0c;可以得出&＃xff0c;对于处于synsent状态的套接字来说&＃xff0c;如果收到了syn报文&＃xff0c;则会正常回复synack&＃xff0c;完成TCP三次握手。

对于腾讯的这道面试题目来说&＃xff0c;其答案就是当两端同时发起connect调用时&＃xff0c;即使没有listen调用&＃xff0c;也可以成功创建TCP连接。

如果去掉“两端”的限制&＃xff0c;还有一个答案就是&＃xff0c;TCP套接字可以connect它本身bind的地址和端口&＃xff0c;也可以达成要求。下面是测试代码&＃xff0c;实现了一个TCP套接字成功连接自己&＃xff0c;并发送消息。

#include /* See NOTES */
#include
#include
#include
#include
#include
#include
#include #define LOCAL_IP_ADDR (0x7F000001)
#define LOCAL_TCP_PORT (34567)int main(void)
{struct sockaddr_in local, peer;int ret;char buf[128];int sock &＃61; socket(AF_INET, SOCK_STREAM, 0);memset(&local, 0, sizeof(local));memset(&peer, 0, sizeof(peer));local.sin_family &＃61; AF_INET;local.sin_port &＃61; htons(LOCAL_TCP_PORT);local.sin_addr.s_addr &＃61; htonl(LOCAL_IP_ADDR);peer &＃61; local; int flag &＃61; 1;ret &＃61; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &flag, sizeof(flag));if (ret &＃61;&＃61; -1) {printf("Fail to setsocket SO_REUSEADDR: %s\n", strerror(errno));exit(1);}ret &＃61; bind(sock, (const struct sockaddr *)&local, sizeof(local));ret &＃61; connect(sock, (const struct sockaddr *)&peer, sizeof(peer));if (ret) {printf("Fail to connect myself: %s\n", strerror(errno));exit(1);}printf("Connect to myself successfully\n");strcpy(buf, "Hello, myself~");send(sock, buf, strlen(buf), 0);memset(buf, 0, sizeof(buf));recv(sock, buf, sizeof(buf), 0);printf("Recv the msg: %s\n", buf);close(sock);return 0;
}


其连接截图如下&＃xff1a;

从截图中&＃xff0c;可以看到TCP套接字成功的“连接”了自己&＃xff0c;并发送和接收了数据包围。netstat的输出更证明了TCP的两端地址和端口是完全相同的。