gRPC 是一个典型的C/S模型，需要开发客户端 和 服务端，客户端与服务端需要达成协议，使用某一个确认的传输协议来传输数据，gRPC通常默认是使用protobuf来作为传输协议，当然也是可以使用其他自定义的。
gRPC 这项技术真是太棒了，接口约束严格，性能还高，在 k8s 和很多微服务框架中都有应用。
上一篇文章我们讲解了怎么给 GRPC 配置添加单向证书认证，这一篇我接着分享，如何让 GRPC 服务加入双向证书认证。
在go 1.15以上版本，必须使用SAN方式，否则会报"transport: authentication handshake failed: x509: certificate relies on legacy Common Name field, use SANs instead"
为了安全，你可以去购买收费的证书或者免费证书也行，这里演示我们使用 OpenSSL 自生成的证书。
gRPC 是由 Google 开发的高性能、开源的 RPC（Remote Procedure Call）框架，用于在客户端和服务器之间进行通信。它基于 Protocol Buffers（protobuf）进行消息序列化和反序列化，支持多种通信协议，如 HTTP/2、TCP 和 gRPC 提供的协议。
申请获得服务器证书有三张，一张服务器证书，二张中级ＣＡ证书。在Android微信中访问Https，如果服务器只有一张ＣＡ证书，就无法访问。 获取服务器证书中级CA证书: 为保障服务器证书在客户端的兼容性，服务器证书需要安装两张中级CA证书(以证书签发邮件为准，部分证书产品只有一张中级证书)，根证书或证书链内容，放在服务器证书内容的后边。将证书签发邮件中的从BEGIN到 END结束的服务器证书内容（包括"-----BEGIN CERTIFICATE-----"和"-----END CERTIFICAT
grpc-go本身已经支持安全通信，该文是举例介绍下双向认证的安全通信，客户端和服务端是如何实现的。
gRPC（gRPC Remote Procedure Call）是一种开源的远程过程调用（RPC）框架，由Google开发并于2015年发布。它使用HTTP/2协议进行通信，旨在简化跨网络的服务通信和跨语言的服务调用。以下是 gRPC 的一些关键特点和概念：
使用gRPC作为云平台和移动前端的连接方式，网络安全应该是必须考虑的一个重点。gRPC是支持ssl/tls安全通讯机制的。用了一个周末来研究具体使用方法，实际上是一个周末的挖坑填坑过程。把这次经历记录下来与各位分享。
gRPC 是一个高性能、通用的开源 RPC 框架，其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。
当上游出错时，作为负载均衡的Nginx可以实时更换Server，在客户端无感知的情况下重新转发HTTP请求。这一功能在Nginx指令中称为next upstream，本文将详细介绍其用法及实现原理。
gRPC安全认证介绍 gRPC被设计成可以利用插件的形式支持多种授权认证机制，你可以采用自己喜欢的，简单的，认为方便的一种方式，选择权在用户手里 支持的授权认证机制如下 SSL/TLS认证 自定义Token认证 SSL/TLS的概念可以参考下面的文章 https://www.techug.com/post/https-ssl-tls.html SSL/TLS认证方式 首先通过openssl生成证书和私钥，命令如下 //生成私钥 openssl genrsa -out server.key 2048 //生
网络安全领域在攻和防对抗规模群体已经成熟，但是两端从业者对于安全原理掌握程度参差不齐，中间鸿沟般的差距构成了漏洞研究领域的主战场。笔者“三省吾身”，在工作中会犯错误把一些加密、认证、鉴权的概念和实现方案搞混，尤其是加解密涉及算法和公私钥机制的概念不深入细节。
单向认证，只有一方需要验证对方的身份。通常是客户端验证服务器的身份。这种情况下，客户端会检查服务器提供的数字证书是否有效，以确定服务器是否合法。服务器不会验证客户端的身份。这种情况下，客户端可以确认它正在与合法的服务器进行通信，但服务器不能确定其与合法客户端通信。单向认证通常用于一些对服务器身份验证要求较高，但对客户端身份验证要求相对较低的场景，如网站访问。
gRPC被设计成可以利用插件的形式支持多种授权认证机制，你可以采用自己喜欢的，简单的，认为方便的一种方式，选择权在用户手里
到现在，我们已经完成了POS平台和前端的网络集成。不过，还是那句话：平台系统的网络安全是至关重要的。前一篇博客里我们尝试实现了gRPC ssl/tls网络连接，但测试时用的证书如何产生始终没有搞清楚。现在akka-http开发的ws同样面临HTTPS的设置和使用问题。所以，特别抽出这篇博文讨论一下数字证书的问题。
互联网上传输的数据，每时每刻都存在着被窃听和篡改的风险，SSL/TLS协议在保护用户数据机密性、完整性以及身份鉴别等方面发挥了重大作用。国际通用TLS协议并不包含中国国密局推荐使用的商用密码算法（即国密算法）套件，而绝大部分的编程语言原生TLS实现、第三方开源TLS实现大都不支持国密套件。随着国内安全合规、自主可控政策的指引，国密TLS的需求也越来越大，尤其在金融、政务领域已然成为刚需。与此同时，国密相关密码产品大多依托于硬件或者芯片，存在价格昂贵，部署成本高，部分中小企业用户难以承担的问题。国密软件产品存在以下问题也急需解决：
gRPC是Google开源的一个高性能RPC通信框架，通过Protocol Buffers作为其IDL，可以在不同语言开发的平台上使用，同时基于HTTP/2协议实现，继而提供了连接多路复用、头部压缩、流控等特性，极大地提高了客户端与服务端的通信效率。
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。 2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书 3、客户端使用服务端返回的信息验证服务器的合法性，包括：
可是朋友们，有没有想过，要是每一个客户端与服务端通信的接口都进行一次认证，那么这是否会非常多余呢，且每一个接口的实现都要做一次认证，这真的太难受了
随着微服务的迅速发展，各大互联网企业也投入到微服务的使用种。微服务最大的特点是，跨进程、跨服务、跨语言之间的调用，使得我们能够像调用本地类、函数一样。当微服务具备该特点，将我们复杂的业务拆分成不同的服务，服务之间在相互调用。这也是微服务为什么火的原因之一。
关于网络的知识，上篇分享了传输层的知识，但没有深入剖析TCP的流量控制，差错控制拥塞控制，这块后面再做个专题文章进行分享，今天我们来看下HTTP(S)协议和RPC。
在网站升级到 HTTPS 之后，我们还可以有很多玩意可以折腾，优化 HTTPS，让它更快更安全。这里是一篇 HTTPS 优化的总结，也包含问题的解决方法，不过不仅仅包括 HTTPS 的优化，也包含 HTTP 一些安全相关的配置。 因为平时用 Nginx 比较多，本文涉及到 Web Server 的大多数例子都会以 Nginx 为例。如果有错误欢迎指出。HTTPS 发展很快，尤其是在谷歌的推动之下，如果有过时的地方，也请指出。 HSTS HSTS（HTTP Strict Transport Security）
在网站升级到 HTTPS 之后，我们还可以有很多玩意可以折腾，优化 HTTPS，让它更快更安全。这里是一篇 HTTPS 优化的总结，也包含问题的解决方法，不过不仅仅包括 HTTPS 的优化，也包含 HTTP 一些安全相关的配置。
对于 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的一些变化和改进。在这篇文章中，我很高兴谈论 .NET 6 中的变化。
Nginx 在 1.13.10 中，新增了对gRPC的原生支持，Nginx 1.14.0 主线版已经发布。本文将介绍，如何配置 Nginx 中的 gRPC 服务。gRPC 服务做为一个 TCP 服务，配置方式与 HTTP/HTPTS 类似。
golang 1.15+版本上，用 gRPC通过TLS实现数据传输加密时，会报错证书的问题
Harbor 是由 VMware 开源的一款云原生制品仓库，Harbor 的核心功能是存储和管理 Artifact。Harbor 允许用户用命令行工具对容器镜像及其他 Artifact 进行推送和拉取，并提供了图形管理界面帮助用户查看和管理这些 Artifact。在 Harbor 2.0 版本中，除容器镜像外，Harbor 对符合 OCI 规范的 Helm Chart、CNAB、OPA Bundle 等都提供了更多的支持。
ssl协议是基于密码学的基础上，解决通信双方加密信道和身份鉴权的安全问题。ssl协议的算法本身是公开的，但是算法本身的输入参数（key）是由通信双方私自保存。在非对称加密中，服务端保存有一对公钥和私钥对，用于服务端鉴权和加密通信。服务端的私钥泄露会导致恶意攻击者伪造虚假的服务器和客户端通信。特别是源站把业务迁移到云或者CDN上，私钥的安全保存要求更高。
上一篇对http请求进行了封装，本章咱们接着往下进行，讲解可配置项高级选项，假如一个http接口需要进行验证，我们应该如何处理。
当服务器确定了CipherSuite后，根据CipherSuite里面的认证算法，如果需要发送证书给客户端，那么就发送 Server Certificate消息给客户端。Server Certificate总是在ServerHello之后立即发送，所以在同一个RTT里。
SSL/TLS作为一种互联网安全加密技术，原理较为复杂，枯燥而无味，我也是试图理解之后重新整理，尽量做到层次清晰。正文开始。 1. SSL/TLS概览 1.1 整体结构 SSL是一个介于HTTP协议与
本文大部分整理自网络，相关文章请见文后参考。 SSL/TLS作为一种互联网安全加密技术，原理较为复杂，枯燥而无味，我也是试图理解之后重新整理，尽量做到层次清晰。正文开始。 1.SSL/TLS概览 1.
静态资源服务是指通过本地文件系统提供静态文件（如HTML、CSS、JavaScript、图片等）的服务。这种服务通常由Web服务器来提供，比如Nginx、Apache等。
.Net Core3.0终于如约而至的来了。在3.0中增加了许多东西、也有了许多的变化。今天我们看的就是在3.0中使用gRPC并遇到的问题。gRPC现在可以非常方便简洁的在.Net Core中使用了，今天我也是尝试了一下，但是不幸了是遇到了一些阻碍。我们一起看看是啥问题吧。
复制：在这个版本中，sync_relay_log_info服务器系统变量已被弃用，并且获取或设置此变量或其等效的启动选项--sync-relay-log-info现在会引发警告。在将来的MySQL版本中，预计会删除此变量；在此之前，应用程序应该进行重写，不要依赖它。
OpenSSH 可以使用tun/tap设备来创建一个加密隧道，SSH隧道类似mode TCP模式下的OpenVPN，对于有需求快速设置一个基于IP的VPN来说非常方便。使用SSH隧道的优点：
导语 | gRPC也是RPC技术家族的一种，它由Google主导开发，是一个跨平台的调用框架，其中和go语言结合的是最紧密的，在go语言的开发和调用中占据主导地位。gRPC采用protobuf作为配置载体来实现通讯和调用。本文主要实战演示一下gRPC的几种调用通讯模式（普通、客户端流、服务端流、双向流）以及和PHP客户端的联通调用。 在学习gRPC之前，我们需要了解一下ptorobuf语法和protoc的命令，能帮助我们更加深入的学习和理解gRPC。 一、需求分析 我们这次只搞个很简单的需求，搞个用户
（Open System Interconnection Reference Model，开放式系统互联通信参考模型）网络分层模型
首先是重构了配置管理。原来是手写在代码里的，因为原来上层的 libatbus 是不依赖 protobuf 的，现在 既然已经依赖 protobuf 了就转为 protobuf 管理了。同时现在还支持YAML配置，使用 yaml-cpp 来解析YAML文件，这个库也被一些其他知名的大型项目使用了，比如 Envoy proxy 。 原来的conf/ini模式的配置也是支持的，现在加载配置的时候会尝试猜测以下配置文件是yaml还是conf/ini模式。 并且增加了统一的 YAML转protobuf 、 conf/ini转protobuf 和 指定层级配置导出到protobuf 的接口来方便使用。比较特殊的是自定义日志配置后端的接入接口有了一些小变化，问题也不大。
截至发稿，rust-lang/rust 主仓库为 10,0006 次commit！！！
描述: 当下越来越多的网站管理员为企业站点或自己的站点进行了SSL/TLS配置, SSL/TLS 是一种简单易懂的技术，它很容易部署及运行，但要对其进行安全部署的情况下通常是不容易。
Nginx 1.14.1 稳定版和 Nginx 1.15.6 主线版已发布，主要修复了 HTTP/2 （CVE-2018-16843，CVE-2018-16844）以及 MP4 模块（CVE-2018-16845）中的漏洞，具体如下：
为了统一检索和规范 API，B站内部建立了一个统一的 bapis 仓库，整合所有对内对外 API。
MySQL8.1.0与8.0.34发布了，但是看着像是8.0版本的一个小版本的bug修复。本文概括一下简要信息分享给大家。
之后的文章基本都是wpa_supplicant源码分析的介绍, wpa_supplicant 一个庞大的开源项目, 最新版本的为2016-10-V2.6。据目前来开，WiFi相关应用层的操作基本都是wpa_supplicant 的封装，包括Android 。初步统计一下,wpa_supplicant 源文件个数 552个, 20万行代码。 分析起来工作量巨大，这条路非常难走，请读者做好准备。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
