全贝博客

在使用httpclient的时候，偶尔能遇到 NoHttpResponseException 这个异常。

根据这个异常的一些信息，感觉起来很像是网络的因素导致，但是其实不是的，主要是因为以下原因导致：
1，nginx并发压力非常大的时候，排队都来不及处理了，nginx直接丢弃了，这个时候会报这个错误。
2，还有一种情况，网上没有进行任何报道，那是在 nginx reload 的时候，假如 httpclient 刚好在快速的进行请求，这个时候就会报这个异常。这是因为：nginx reload不会对现有的请求连接进行中断，但是对于keepalive的连接，假如刚好没有在进行数据传输，nginx会认为该连接已经请求完毕，所以就主动关闭了，而几乎在同时，httpclient还没有获得主动关闭的响应，于是认为该连接是可用的，用这个连接发送数据的时候，就会收到这个异常。

对于第二个情况，有一篇文章这么讲道：https://github.com/alibaba/tengine/issues/1074 ，但是对于nginx core不是随便人都能改的，同时这么改了后也不知是否有其他副作用，总归解决办法不是特别理想。

经过查找资料以及分析，大家都在说可以用重试的机制来解决，从上述2种原因来看，也确实重试是最好的解决办法，那么对于 httpclient 来讲，怎么实现重试呢？下面贴一段代码：

HttpClientBuilder.create().setRetryHandler((exception, executionCount, context) -> {
            if (executionCount > 1) {
                return false;
            }

            if(exception instanceof NoHttpResponseException) {
                log.info("NoHttpResponseException occured, will retry request");
                return true;
            }

            return false;
        }).build();

以上的代码对于重试，只是用了最简单重试，具体复杂的重试大家可以自行设计。

查看springboot的官方文档：https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.server.server.tomcat.keep-alive-timeout

可以看到对server.tomcat.keep-alive-timeout这个参数的定义如下：
Time to wait for another HTTP request before the connection is closed. When not set the connectionTimeout is used. When set to -1 there will be no timeout.

可是在配置文件中按照上面所说，进行了定义：（注意，单位是毫秒，spring的文档历来是垃圾中的战斗机）

server:
  tomcat:
    keep-alive-timeout: 30000

运行后，发现不起任何作用。

于是只能按照上面所说的，对connection-timeout进行设置：

server:
  tomcat:
    connection-timeout: 30000

这样就起效了，说明keep-alive-timeout没有用，文档有误。

上述是通过配置来更改，还可以通过代码来设定keepalive_timeout，如下：

@Configuration
public class Config {

    @Bean   
    public ServletWebServerFactory servletContainer() {
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory();
        tomcat
        .addConnectorCustomizers(new TomcatConnectorCustomizer() {
            @Override
            public void customize(Connector connector) {
                ((AbstractProtocol) connector.getProtocolHandler())
                        .setKeepAliveTimeout(30000);
            }
        });
        return tomcat;
    }

}

AES是对称性加密算法中最为流行的算法之一。

对于AES加密算法的流程，可以参考这篇博文：AES加密模式与填充
AES有5种模式，其中ECB模式是不安全的，已经废弃；CBC是APPLE默认的加密模式，所以我们也选用CBC来讲解。

我们用java的代码来举例AES算法的一些流程和细节问题：

public static String aesEncrypt(String plainText, String secret,String iv) {
        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

            SecretKeySpec keySpec = new SecretKeySpec(secret.getBytes("utf-8"),"AES");

            IvParameterSpec ivParameterSpec = new IvParameterSpec(iv.getBytes("utf-8"));

            cipher.init(Cipher.ENCRYPT_MODE,keySpec,ivParameterSpec);

            byte[] byteContent = plainText.getBytes("utf-8");
            byte[] result = cipher.doFinal(byteContent);
            String encryptText = Base64.getEncoder().encodeToString(result);
            return encryptText;
        } catch (Exception e) {
            throw new RuntimeException(e.getMessage(), e);
        }
    }

结合上篇博文中的CBC模式图，可以看到：
1，初始化向量(iv)就好比随机数中的种子。
2，PKCS5Padding，因为AES的数据库用128位去切分，当最后的部分不足128位的时候，那么就需要进行填充来达到128位。

其中，AES对secret（密钥）和iv的长度有规定：
1，secret有128位，192位，256位。在java中，128位的AES是jdk自带的，但是大于128位的AES，则需要引入一个额外的security包。从线上运维来看，这可能会增加一定的复杂度，所以，我从个人角度上来看，128位足够，减少运维的复杂度。加密算法的安全在乎与密码是否安全保护好，而不在于是128位还是256位。
2，iv是128位的。
3，我们在输secret的时候，往往不会在乎多少长，比如任意长度的secret，而不会刚好128位，对于iv是同样的道理。那么我们可以采用下面的方式方法来简化这个流程：

String md5 = md5Hex(secret);
secret = md5.substring(0,15);
String iv = md5.substring(16);