Monthly Archives: February 2022
Netty 入门 — 什么是 Netty？
Netty 是 一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。
Netty 是一个 NIO 客户端服务器框架，可以快速轻松地开发协议服务器和客户端等网络应用程序。它极大地简化和流线了网络编程，例如 TCP 和 UDP 套接字服务器。
“快速和简单”并不意味着生成的应用程序会受到可维护性或性能问题的影响。Netty 是经过精心设计的，它借鉴了许多协议（如 FTP、SMTP、HTTP 以及各种基于二进制和基于文本的遗留协议）的实现经验。因此，Netty 成功地找到了一种方法，可以在不妥协的情况下实现易于开发、性能、稳定性和灵活性。
View DetailsJava网络编程IO模型 — BIO、NIO、AIO详解
1.1 I/O模型基本说明
I/O模型的简单理解：I/O模型就是用什么样的通道进行数据的发送和接受，很大程度上决定了程序通信的性能
1.2 Java支持的3种网络编程I/O模式：BIO、NIO、AIO
1.3 JavaBIO（同步阻塞）
1.4 JavaNIO （同步非阻塞）
1.5 JavaAIO（异步非阻塞）
解决出现“未能加载文件或程序集“System.Net.Http.Formatting, Version=5.2.3.0”的问题
我们在使用C#开发WebApi等相关程序时，可能因为某些原因会出现如下图所示的错误，原因就是我们在编译的时候，使用的dll库可能和最初的发生了改变，导致版本不一致造成的。
View Details
Windows下安装docker后的默认操作系统密码
通过DockerToolbox在win7上构建了docker的环境，启动了ORACLE VM VirtualBOX下的Default 操作系统。
这个操作系统默认的IP是192.168.99.100，可以直接通过ORACLE VM VirtualBOX的控制台“显示”按钮展现shell（以root账号进入的）。
这种访问的缺点：
就是默认的shell展现屏幕不够大，使用不够方便；
解决方案：
通过SSH客户端访问，这里我使用putty访问这个系统；
docker run参数-v的rw、ro详解
众所周知，如果启动容器时不使用-v挂载宿主机的文件或文件夹，容器中的配置文件只能进入容器才能修改，输出的日志文件也是在容器里面，查看不方便，也不利于日志收集，所以一般都是使用-v参数来挂载文件或文件夹。
View Details
踩坑备忘录—Nginx反向代理之server_name与ip
我们的系统依赖一个第三方的服务，该服务是通过IP限制访问权限的。出于安全考虑，我们的系统会校验证书，因此我们采用Nginx反向代理去访问该服务。该服务迁移到cloud上之后，我们系统出现了问题。 Nginx的配置文件如下所示：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
http { upstream backend.example.com { server backend1.example.com:443; } server { listen 80; server_name www.example.com; location /upstream { proxy_pass https://backend.example.com; proxy_ssl_certificate /etc/nginx/client.pem; proxy_ssl_certificate_key /etc/nginx/client.key; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt; proxy_ssl_verify on; proxy_ssl_verify_depth 2; } } } |
Debug 在出现线上问题的时候，第一时间检查了配置文件的改动记录 ⇒ 配置文件没有改到。 接着检查了，证书是否过期⇒没有过期。 通过域名curl请求 ⇒ 第三方服务正常，证书正确。 在我们没有任何改动的情况下，第三方服务也是单纯地做了迁移，然后就挂了。 思考了很久之后，Nginx没有任何改动，那么出问题的一定不是我们。那么出问题一定是第三方，最直接的方式是联系第三方提供商，联系渠道很繁琐，时间成本也会很高。为了快速修复问题，我们决定盲调Bug。 尝试解决 第一次尝试，已知curl请求一切正常。尝试着将upstream干掉，直接写道proxy_path中。依旧是失败，错误日志中出现了”https://1.1.1.1:443 TLS handshake failed”。推断，proxy_path会将域名转换成ip。 第二次尝试，尝试检查curl ip来访问服务。失败。推断，IP和域名指向了两个不同的服务。到这里算是找到root cause了。 解决思路：反向代理时候，通过域名访问而不是IP访问。 查询文档，发现可以使用配置项：proxy_ssl_server_name，该配置项默认值是off，需要将一些内容写到配置文件中：
|
1 |
proxy_ssl_server_name on; |
第三次尝试，将proxy_ssl_server_name on写入到配置文件中。成功。 什么是server_name 服务器名称指示（Server Name Indication, SNI）是对TLS协议的扩展。在握手过程开始时，通过该协议，客户端指示其尝试连接的主机名。该协议允许服务器上的同一个IP和TCP端口拥有多个证书，因此允许同一个IP地址为多个HTTPS网站提供服务，且无需所有网站使用相同的证书。 from:https://www.realks.com/2021/03/07/nginx-proxy-ssl-server-name/
View Detailsdocker export import后，导入镜像，启动时的错误，Error response from daemon: No command specified
Docker的流行与它对容器的易分享和易移植密不可分，用户不仅可以把容器提交到公共服务器上，还可以把容器导出到本地文件系统中。同样，我们也可以把导出的容器重新导入到Docker运行环境中。Docker的容器导入导出分别用import和export命令完成。
View Detailsdocker: Error response from daemon: No command specified. 解决
一般来说产生这个报错是因为启动的容器是被docker export出来的镜像。
Command可以通过下面命令查询到：docker ps -a --no-trunc
查询到Command之后，运行容器：docker run --name nginx-import-test -d -p 4000:80 nginx-import-test:1.0 /docker-entrypoint.sh nginx -g 'daemon off;'