http代理服务器（二十三）由透明代理的safari引出异常处理【重点】

commit：b6051860d48806a451863554a75308bcd012e2e3

0 先前成果回顾

 

0.1 各种超时归纳整理

关于netty connect异常，3个点要注意：1）connect可能直接抛出异常 2）要设置连接超时，否则网络不通一直卡着 3）connect不抛出异常，在回调中显示连接失败，netty（十五）负载均衡实践中代码处理了这1 3情况，并重连，不过好像忘了设置2

这里补充第四点：connect回调成功，但服务端直接关闭连接进入inactive

 

0.2 netty client 连接超时设置

192.*这个ip由于网络不通，触发的是超时异常，如果是网络通的，但是服务不通，则会

java.net.ConnectException: Connection refused: /127.0.0.1:8866

 

0.3 netty（二十四）http代理服务器（八）超时

代理服务器httpclient未设置超时

 

 发现还是会访问10几个网页后出页面速度变慢，最终卡死，谷歌

 

0.4 http代理服务器（三）fiddler【重点】

异常-连接泄漏 这个洞堵上后，正常

 

0.5 本文

safari使用透明代理出现：

无法使用，debug发现端口是80；解决：contains “：443”

浏览器转圈圈-百度关掉了连接，但浏览器和代理的连接还在等response；解决：在后端的inactive里，关掉前端的连接，之后浏览器不再转圈圈

 

chrome

 safari

 

 

 80连接成果，但是被80立即切断，至此发现第4种后端连接异常

 

 

0.6 https://blog.csdn.net/weixin_46425661/article/details/142260579#CONNECT_TIMEOUT_MILLIS5_57

Netty笔记10-Netty参数调优

public static void main(String[] args) {
        NioEventLoopGroup group = new NioEventLoopGroup();
        try {
            Bootstrap bootstrap = new Bootstrap()
                    .group(group)
                    .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
                    .channel(NioSocketChannel.class)
                    .handler(new LoggingHandler());
            ChannelFuture future = bootstrap.connect("127.0.0.1", 8080);
            ChannelFuture channelFuture = future.sync();//当1秒内没有连接成功，则判断为连接超时所以抛出异常
            channelFuture.channel().closeFuture().sync();
        } catch (Exception e) {
            e.printStackTrace();
            log.debug("timeout");
        } finally {
            group.shutdownGracefully();
        }
    }

不启动服务器端直接启动客户端观察控制台

观察发现ChannelOption.CONNECT_TIMEOUT_MILLIS超时时间设置1秒和5秒时报错信息不同，原因是：

设置为5秒是因为在没有启动服务器端时，客户端两秒后判断出服务器端没启动，所以根本连不上。所以直接报错。
设置为1秒是因为还不能判断服务器端是否启动就已经超时了，所以报错连接超时。

 

 

1 本文目的：避免正常及异常状态下的

连接泄漏

内存泄漏

 

2 手段

2.1 往前端正常发送后回调，http代理无论是否success都关闭连接，tcp代理因为发的是tcp流，发完不能关；

2.2 前端pipeline异常，要不要关？关保险点

2.3 往前端发送前出现异常

2.3.1　　业务代码异常，比如0.4

2.3.2　　netty通道收到包，往后端连接异常

2.3.2.1　　　　connect超时，比如0.3；释放前端msg，总之没有调用后端ctx.write的情况，都释放

2.3.2.2　　　　connect直接报错；释放前端msg

2.3.2.3　　　　connect回调issuccess=false；释放前端msg

2.3.2.4　　　　后端关闭连接，在inactive中

2.3.2.5　　　　后端出现异常，要不要直接关闭后端与前端的ctx？关保险点，前端再有连接从头来过

 

忽略2.1，2.2，着重处理2.3

上图“后端主动关闭连接”这一块就是解决safari转圈圈 

 

检验：

本地：

由本地HttpClient直接close到代理服务器的连接

 

代理：

应该是closewait过了 

后端：

可以看到，在http请求后，后端tomcat关掉了连接