Code Life

Filter

• Filter是Servlet规范制定的，受Servlet容器支持，接口定义在javax.servlet包中。
• Filter是被Web Server（如Tomcat）调用。
• Filter 需要在 web.xml 中定义之后才会起作用。
• Filter只在请求的前后起作用，Servlet对于Filter来说是一个黑盒。
• Filter的执行顺序是：
  • void init(FilterConfig) - 容器在初始化Filter时调用，在Filter生命周期内仅会被调用一次。方法可以抛出ServletException。
  • doFilter(ServletRequest, ServletResponse, FilterChain) - Web容器每一次请求都会调用该方法。该方法将容器的请求和响应作为参数传递进来， FilterChain用来调用下一个Filter。
  • void destroy() - 当容器销毁 Filter 实例时调用该方法，可以在方法中销毁资源，该方法在 Filter 的生命周期只会被调用一次。

Interceptor

• Interceptor是Spring容器内的，由Spring框架提供支持。接口HandlerInterceptor定义在org.springframework.web.servlet包中。
• Interceptor是被Spring调用。
• Interceptor可以深入到方法前后、异常抛出前后等，比起Filter有更大的弹性。
• Interceptor还允许用户介入请求的生命周期，可以在请求过程中获取信息，通常与请求更加耦合。
• Interceptor的执行顺序是：
  • 请求到达DispatcherServlet
  • DispatcherServlet将请求发送至Interceptor，Interceptor执行preHandle()方法
  • 请求到达Controller
  • 请求结束后，Interceptor执行postHandle()方法

最近折腾了下用Tailscale搭建虚拟局域网，在这里记录一下折腾的过程和一些心得。

就在刚刚，我一个误操作，在没有本地备份的前提下，force push了一个GitHub上的仓库。万幸最后恢复成功，数据拿回来了。惊魂未定之余，在此记录我的抢救过程以供参考。

前段时间瞎折腾，给自己的黑莓Bold 9900写了个通过NTP同步时间的小工具，顺便在这里记录一下我在实现一个NTP客户端时对这个协议的理解。

太长不看：关闭IPv6或许可以解决。如果你平时要用到IPv6，那就在更新之前先禁用IPv6，更新完了再打开；如果开不开IPv6对你来说没区别的话，那永久关闭也不是不可以。当然如果你愿意，下文提到的改注册表的方案也是可用的。

这两天在给微软模拟飞行下载更新的时候，就算挂着网易UU，速度也一直很慢，时常在0.5MB/s~5MB/s之间波动，不论怎么换节点也不能跑出正常的速度。今天经过一顿上网冲浪，发现这个问题的根源，在IPv6。

其实网上针对这个问题已经有一些解决方案了，但内容看下来都一样，不外乎教你怎么关掉IPv6。但我一方面要用到IPv6，另一方面也不想那么粗暴的解决问题，所以又稍微做了点研究，顺便写了个小工具方便其他有这个问题的玩家。 经过一段时间的试用后发现，临时/永久关闭IPv6实际上是最优雅的方案……

联动上一篇博文，在解决了OpenResty上那个SNI的问题之后，我们发现有一个Java应用也有类似的问题。而最后发现，这是因为我们当前版本的Java中有一个bug……

简单来说，就是在Java 1.8u141之前，HttpsURLConnection#setDefaultHostnameVerifier()方法会破坏SNI，而正好我们的代码里有这么一行：

1

HttpsURLConnection.setDefaultHostnameVerifier((hostname, session) -> true);

翻了下框架的代码，发现如果我不设定这个值，框架也调用这个方法来指定它默认的hostname verifier；而如果我传个null，那么它会抛个异常给我。所以，代码层面没有很方便的解决方案。

无奈，最后决定，先临时换了个没开启SNI的域名，暂时解决掉问题，然后升级Java到1.8u181，一劳永逸。

终于，我也有机会理直气壮地喊出“这是Java的bug”了！（笑

[^1]: Extended server_name (SNI Extension) not sent with jdk1.8.0 but send with jdk1.7.0
[^2]: Custom HostnameVerifier disables SNI support on client in Java 8

前段时间，我司出现了一次生产事故，调查后发现是当时的OpenResty配置不兼容SNI导致的。在这里我也记录一下整件事的排查过程，以及解决方法，供遇到类似问题的同志们参考。

前段时间在网上看到了一个叫“甜糖星愿计划”的东西，声称可以通过贡献闲置带宽来获得积分。正好我有个NAS，正好我的宽带一天从白天闲到黑夜，不如利用起来，少少挣一些零花钱。

需要注意的一点是，本文提到的镜像仅在我的群晖DS218+上测试过，虽然镜像中未使用任何群晖限定的依赖，理论上适用于任何x86架构的平台，但并不保证运行效果。而且本文目标平台是x86，如果你拥有ARM平台的机器，那根本不需要废这个劲，你可以直接运行甜糖星愿的可执行程序。

本文提到的操作全部基于Docker，故在按照本文操作前，请先确保你已经拥有足够的知识来使用Docker和docker-compose。

由于我司目前的项目都运行在Google Cloud Platform(以下简称GCP)上，那么自然而然的，我们选择了使用GCP的Logging来查看日志。在使用过程中，我们发现了一个问题，那就是我们无法直观的看到日志是从什么地方打印出来的，经常需要通过日志内容，在代码里面通过全文搜索来定位。这样就产生了一个需求：可不可以把这条日志所在的类、方法，和行数一起打印在日志中？

我们在开发过程中，为了保证项目的灵活性，经常会选择将一些值放在配置文件中，并在代码中将它注入并使用。将值注入代码最常见的一种方法，则是使用@Value()注解搭配SpEL直接注入我们需要的属性。但是鲁迅先生有云：从来如此，便对吗？这里，我想介绍一个我个人认为更好的实践：通过配置类来注入属性的值。