关于tcp socket出现的connection reset by peer

发表于:，更新于:，By Sally
大纲
  1. 1. 碰到的问题
  2. 2. kaminari 分页gem
  3. 3. 关于tcp socket出现的”connection reset by peer”和”broken pipe”

碰到的问题

connection reset by peer看字面意思像是：要做的事还没做完，链接就被重置了(断开了)。

潜意识里认为分业/分批加载数据更多的是为了提高用户体验，不必等到花都谢了。但貌似还有更大的阴谋：如下

今天，就出现了个这：

tcp_socket

因为本地的数据比较少，怎么测都没问题。然而，查询数据的sql是这样的: 关联了好几张表，而且还是一次全拉

tcp_socket

真实服务器上的数据比较多，拉取100条数据都绷不住，直接挂。然后用了分页就妥了，那就不得不说下下面这个好用的gem了。

kaminari 分页gem

Kaminari

使用方法炒鸡简单：

  • 在controller中这样
1
2
PER_PAGE = 20  # 常量
@decorating_case_stage_details = @decorating_case_stage_details.page(params[:page]).per(PER_PAGE)
  • 在view中这样
1
<%= paginate @decoratingcases %> 总共有<%= @decoratingcases.total_entries %>条

关于tcp socket出现的”connection reset by peer”和”broken pipe”

原文

  • “connection reset by peer”和”broken pipe”出现的场景：

1）往一个对端已经close的通道写数据的时候，对方的tcp会收到这个报文，并且反馈一个reset报文。当收到reset报文的时候，继续做select读数据的时候就会抛出Connect reset by peer的异常，。

2）当第一次往一个对端已经close的通道写数据的时候会和上面的情况一样，会收到reset报文。当再次往这个socket写数据的时候，就会抛出Broken pipe了 。根据tcp的约定，当收到reset包的时候，上层必须要做出处理，调用将socket文件描述符进行关闭，其实也意味着pipe会关闭，因此会抛出这个顾名思义的异常。