epoll与多次TCP连接尝试的差异：非阻塞客户端方案对比

首先明确两种实现的核心逻辑：

方案一：固定间隔重试 #

int num_of_retry=5;
for(int i=0;i<num_of_retry;i++){
   connect(SOCKET_FD,...);
   sleep(1000ms);
}

方案二：epoll异步等待连接结果 #

connect(SOCKET_FD,...);
epoll_wait(...,5000ms)

两者的主要差异如下：

1. 响应速度与性能 #

• 方案一采用固定1秒间隔重试，即使连接在两次重试的间隔内就能建立，也必须等到下一次重试时间点才能发起新请求，整体响应延迟较高，最坏情况下要等待5秒才会结束。
• 方案二通过epoll异步监听连接状态，TCP三次握手完成（或连接失败）时会立即触发事件通知，无需等待固定间隔，能第一时间获取连接结果，响应速度远快于方案一。

2. 系统资源利用率 #

• 方案一中的sleep()会让线程进入阻塞状态，这段时间线程无法处理任何其他任务，单线程场景下整个程序完全停滞，浪费CPU和线程资源。
• 方案二的epoll_wait()虽然也是阻塞，但支持同时监听多个文件描述符，线程在等待期间可被内核调度处理其他任务，适合单线程处理多IO场景，资源利用率更高。

3. 重试逻辑灵活性 #

• 方案一的重试策略固定（5次、每次间隔1秒），无法根据实际场景调整（比如采用指数退避间隔优化重试效率），且非阻塞connect失败后，套接字处于错误状态，若不重新创建就再次调用connect会持续失败，用户代码未处理该问题存在隐患。
• 方案二可在epoll_wait返回后根据连接结果灵活控制重试逻辑：若连接失败，可关闭旧套接字、创建新套接字重新发起连接并加入epoll监听，还能根据失败原因调整重试间隔（如指数退避），灵活性更强。

4. 连接时机的准确性 #

• 方案一的重试时机完全由固定间隔决定，会错过间隔期内可能的连接机会（比如服务器在第1.5秒恢复可用，但方案一要等到第2秒才会重试）。
• 方案二是实时监听连接状态，只要TCP连接能建立，就会立刻得到通知，不会错过任何可行的连接时机。

内容的提问来源于stack exchange，提问作者Ahsan Sadeeb