ARTS 20190202

本周arts:
1.Algorithm:
本周继续复习前几个月做的arts题目，有两道题是关于树的遍历，另一道题是关于二维动态规划，这道题比较难。
https://blog.csdn.net/tassardge/article/details/83214361
https://blog.csdn.net/tassardge/article/details/83378692
https://blog.csdn.net/tassardge/article/details/83277108
2.Review:
本周读了两篇英文好文章：
1)下文是一个为.net framework导入自签名ssl/tls证书的技巧：
当我们在开发环境中使用自签名的ssl/tls证书时候，往往会遇到类似于The remote certificate is invalid according to the validation procedure的错误。怎样在.net开发中避免自签名证书的认证错误呢？参考下文。
https://blogs.msdn.microsoft.com/jpsanders/2009/09/16/troubleshooting-asp-net-the-remote-certificate-is-invalid-according-to-the-validation-procedure/ 
2)下文是一篇讲述ssl/tls握手阶段的小文，写的很详细。
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
3.Technique:
我司有个产品，云端为了便于客户端通信提供了signalR服务，走的是https通道；客户端基于.net framework，通过signalR与云端通信。但是我们发现客户那边的很多客户端根本连不上云端的signalR端口。报错是：“An existing connection was forcibly closed by the remote host”。
根据经验判断，这个错要么是云端的signalR服务没有监听指定端口，要么是云端直接发了个tcp reset给客户端。前者肯定可以被排除，那么唯一的可能就是后者。
后来通过不断尝试，我们发现解决方案是微软提供的这个patch：https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358
这个patch解决的问题是早期的.net版本会在tls握手过程中使用低版本的ssl/tls协议，从而导致服务器端拒绝客户端的连接。后来发现果然是这个问题。
下文是对问题的详细描述：
https://blogs.msdn.microsoft.com/friis/2017/10/09/troubleshooting-tls-ssl-scenario-2/
问题最后虽然得到了解决，但是有一点比较遗憾，就是没有抓包，全程靠试错和log解决了这个问题。但是也没办法，我们不能在客户的设备上抓包。另外还有一个感慨就是，研发部门的windows升级非常勤，导致根本无法复现这个错误；而客户那边又太不勤，所以遇到各种版本太旧导致的奇怪问题。
4.Sharing:
在最近的工作中我需要维护自己几年前写的代码，但已经忘得干干净净了；我觉得自己应该多花时间复习以前写的代码，一是出于责任心，二是可以帮助我熟悉公司的产品，提升自己对于公司的价值，这也是未来加薪的资本：）