NGINX发布的1.9.1版本引入了一个新的特性：允许使用SO_REUSEPORT套接字选项，该选项在许多操作系统的新版本中是可用的，包括Bsd和Linux（内核版本3.9及以后）。该套接字选项允许多个套接字监听同一IP和端口的组合。内核能够在这些套接字中对传入的连接进行负载均衡。（对于NGINX Plus客户，此功能将在年底发布的版本7中出现）SO_REUSEPORT选项有许多潜在的实际应用。其他服务也可以使用它来简单实现执行中的滚动升级（Nginx已经通过不同的办法支持了滚动升级）。对于NGINX而言，
前言：多个进程不能同时绑定同一个IP和端口，这是早期Linux内核的一个限制，这个限制给服务器带来了很多不便之处，因为服务器的架构通常不是单进程的，尤其在多核的时代，但是3.9的内核带来了新的特征SO_REUSEPORT。不仅使得服务器的代码逻辑变得简单，对服务器的性能也提升了不少。SO_REUSEPORT的意义是支持同用户下的多个进程同时监听一个IP和端口，本文介绍在Node.js中支持SO_REUSEPORT，以提升Node.js的性能。
前面，张戈博客在折腾 Nginx 的 SSL 优化时，注意到前人在 Nginx 的 listen 配置中，添加了 fastopen=3 reuseport 这 2 个参数。 于是脑补了下，原来是启用
你可能会碰到这个程序要用 443 端口，那个程序也要使用 443 的情况。这时候就要用到 nginx 的 stream 进行分流了。
nginx是一种高性能的HTTP和反向代理服务器。当我们要向外界发布应用的时候，如果只有1台服务器，那么直接将DNS配置解析到这台部署的服务器即可实现诉求，但是随着访问量的增大，我们需要部署多台服务器来增加服务的性能，这时就可以使用nginx作为反向代理，将流量均衡的分摊到每台服务器上。
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件Exciting的事情。 今天笔者就来从Linux源码的角度看下Server端的Socket在进行bind的时候到底做了哪些事情(基于Linux 3.10内核)。
面对性能调优问题，很多人往往只是单纯的套用既往的经验：先试试一个，不行再试试另一个。面对简单的问题，如此通常能事半功倍；但是当面对复杂问题的时候，单凭经验往往并不能达到立竿见影的效果，此时我们需要更精准的判断性能短板在哪里。
第一次听到的这个名词的时候觉得很是有趣，不知道是个什么意思，总觉得又是奇怪的中文翻译导致的。
使用nginx转发时，如果一个服务包含多个协议（如：http,websocket,udp）
在日常的开发过程中，经常会遇到端口占用冲突的问题。那是不是不同的进程不能同时监听同一个端口呢？这个小节就来介绍 SO_REUSEPORT 选项相关的内容。
开篇我先考大家一个小问题，如果你的服务器上已经有个进程在 listen 6000 这个端口号了。那么该服务器上其它进程是否还能 bind 和 listen 该端口呢？
后台业务一般都是通过TCP协议提供服务。服务难免需要版本升级，需要经历旧进程的退出和新进程的启动。为保证用户链接不异常中断，需要旧进程继续运行，直至处理完用户请求后再退出。这样才不会打断用户请求，这就是所谓的Graceful Shutdown：优雅退出。如果不做优雅退出，用户交互过程中任何一个步骤可能被升级打断，往小了有些不重要的业务，中断一下可以忍受，但如支付的基础服务，升级服务如果不支持优雅退出，造成大量用户掉线，进而造成恶劣的影响。所以对服务实现，不论对什么业务来说都是很有必要的。这也是为什么Go从1.8版本开始，标准库net/http对HTTPServer就添加了一个新的方法GracefulShutdown，使得进程可以把现有请求都处理完了再退出。
作者简介 竞哲，携程资深后端开发工程师，关注网络协议、RPC、消息队列以及云原生等领域。 一、背景 QUIC 全称 quick udp internet connection，即“快速 UDP 互联网连接”（和英文 quick 谐音，简称“快”），是由 google 提出的使用 udp 进行多路并发传输的协议，是HTTP3的标准传输层协议。近几年随着QUIC协议在IETF的标准化发展，越来越多的国内外大厂开始在生产环境对QUIC进行落地，以此提升某些业务场景下的服务性能。 Trip.com App作为一
workerman使用pcntl_fork()来实现master/worker的多进程模型，每个worker进程通过使用stream_socket_server()函数来创建socket，由于fork创建的worker进程具备亲缘关系，所以不同的worker进程可以对相同的端口监听；不同worker进程监听相同的socket，在该socket存在事件时，所有监听该socket的worker进程会被唤醒，所有worker进程对socket资源进行抢占式处理，但最终只有一个worker进程可以对socket进行accept；在这个过程中就存在n-1个worker进程是无效调度的，仅仅只是被唤起了然后抢占失败并再次入眠。
Discourse 官方推荐使用docker部署项目， 好处是简单快捷， 坑的是docker镜像默认占用了80端口和443端口， 对于我这种一台机器部署多个网站的人，明显不够用，我需要将 Discourse 默认占用的80和443端口映射到宿主机的其它端口，比如80映射到宿主机的20080， 443映射到宿主机的 20443
跳票许久许久的LD_PRELOAD功能模块（后续以 libff_syscall.so 代替）在 F-Stack dev 分支的 adapter/sysctall 目录下已经提交，支持 hook 系统内核 socket 相关接口的代码，降低已有应用迁移到 F-Stack 的门槛。下面将分进行具体介绍， 主要包括libff_syscall.so 相关的架构涉及其中的一些思考，支持的几种模式以及如何使用等内容。 总体结论： 原有应用程序的接入门槛比原本的 F-Stack 有所降低，大部分情况下可以不修改原有的用户
谈到Redis缓存，我们描述其性能时会这么说：支持1万并发连接，几万QPS。而我们描述Nginx的高性能时，则会宣示：支持C10M（1千万并发连接），百万级QPS。Nginx用C语言开发，而Redis是用同一家族的C++语言开发的，C与C++在性能上是同一级数的。Redis与Nginx同样使用了事件驱动、异步调用、Epoll这些机制，为什么Nginx的并发连接会高出那么多呢？（本文不讨论Redis分布式集群）
DoH（DNS over HTTPS），顾名思义，suoyis，除了最常用的UDP外，还有DoT（DNS over TLS），DNS over HTTP（服务提供商自定义）等方案，对比如下：
上期视频我们讲到了如何利用Nginx的SNI来分流Trojan的相关流量。间接实现了建站和Trojan完美运行。视频观看地址：点击播放
我刚用 OpenResty Demo 工具链从一个极简单的剧本文件，自动生成了一个短视频，上传到 B 站了：《OpenResty 实现的“你好世界”HTTP示例》。机器自动根据剧本自导、自演、自拍、自配音和自配中英字幕：一条命令搞定。
在介绍完我博客（imququ.com）的 Nginx 配置中与安全有关的一些配置后，这篇文章继续介绍与性能有关的一些配置。WEB 性能优化是一个系统工程，涵盖很多方面，做好其中某个环节并不意味性能就能变好，但可以肯定地说，如果某个环节做得很糟糕，那么结果一定会变差。
示例配置文件如下，更多特性请参考官方文档：https://nginx.org/en/docs/http/ngx_http_v3_module.html
在了解Nginx工作原理之前，我们先来了解下几个基本的概念 以及常见的I/O模型。
近期正在探索前端、后端、系统端各类常用组件与工具，对其一些常见的组件进行再次整理一下，形成标准化组件专题，后续该专题将包含各类语言中的一些常用组件。欢迎大家进行持续关注。
对Nginx配置的点滴学习总结，主要目的在于分析Nginx与性能相关的一些参数设置，以便性能调优时选择最优配置
惊群效应也有人叫做雷鸣群体效应，不过叫什么，简言之，惊群现象就是多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只可能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。
如果你不需要 brotli 压缩，请删除--add-module=/root/ngx_brotli
官方文档指出，在1.9.0版本后可以使用stream模块，但此模块不是默认编译进去的，所以需要我们在编译安装nginx的时候加上它--with-stream。
GoReplay是一款开源的用来进行http流量录制与回放的工具，因此可以通过它来进行线上真实流量录制然后将录制的流量回放到测试环境用来确认新开发的功能是否有问题，这样可以极大的提高新功能发布的信心，不得不说是一款神器。
原文地址：https://blog.flipkart.tech/linux-tcp-so-reuseport-usage-and-implementation-6bfbf642885a
Nginx (engine x) 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。在1.9.13版本后，Nginx已经支持端口转发。之前分享过《Linux安装rinetd实现TCP端口转发》，rinetd配置简单，使用方便，但遗憾的是不支持UDP转发。如果需要同时支持TCP/UDP端口转发可以使用Nginx
在Kuberntes Cluster中准备N个节点，我们称之为代理节点。在这N个节点上只部署Nginx Ingress Controller（简称NIC）实例，不会跑其他业务容器。 给代理节点打上NoExecute Taint，防止业务容器调度或运行在这些节点。 # 给代理节点打上NoExecute Taint $kubectl taint nodes 192.168.56.105 LB=NIC:NoSchedule 给代理节点打上Label，让NIC只部署在打了对应Lable的节点上。
我这里的环境是虚拟机，如果是云环境可以直接用slb的方式，这一步可以跳过。 虚拟机这里使用nginx local proxy
富 Web 时代，应用变得越来越强大，与此同时也越来越复杂。集群部署、隔离环境、灰度发布以及动态扩容缺一不可，而容器化则成为中间的必要桥梁。
作者：morganhuang，腾讯 IEG 后台工程师 "惊群"简单地来讲，就是多个进程(线程)阻塞睡眠在某个系统调用上，在等待某个 fd(socket)的事件的到来。当这个 fd(socket)的事件发生的时候，这些睡眠的进程(线程)就会被同时唤醒，多个进程(线程)从阻塞的系统调用上返回，这就是"惊群"现象。"惊群"被人诟病的是效率低下，大量的 CPU 时间浪费在被唤醒发现无事可做，然后又继续睡眠的反复切换上。本文谈谈 linux socket 中的一些"惊群"现象、原因以及解决方案。 1. A
最近这段时间主要在不同平台测试模块的稳定性，目前播放这一块没发现问题，由于条件限制，除了FreeBSD平台没测试过，Windows 7，Debian 7.x和macOS Sierra都测试过了，由于Nginx官方对Windows支持不太好，没用Windows平台最强大的IOCP接口（使用的select），所以导致Windows平台上运行效率不太高，表现在推流等待时间长，3s+，首屏时间很长，4s+，select本身原因限制客户端个数，默认是1024。推流等待时间和首屏时间最短的是macOS Sierra，本机上测试时基本上是秒推秒开。昨晚专门注意了一下，在macOS Sierra下编译时，SO_REUSEPORT和TCP_FASTOPEN两项都支持，前者让Nginx的每个子进程都可以listen，都有一个专门的accept队列，解决了惊群效应；后者则是在发起SYN时就已经携带实际数据，而不是握手完毕后再传输实际数据。秒推秒开可能跟这两个选项有关。但是macOS Sierra并不支持将某个进程绑定到某个CPU上，所以可能进程上下文切换会有开销，系统负载较大时可能效率不如Linux。由于macOS Sierra是公司的电脑，所以未做压力测试。我的笔记本装的是Debian 7.x，因为内核版本较低，所以macOS Sierra上支持的两个选项都不支持。测试时推流等待时间和首屏时间都介于Windows 7和macOS Sierra之间，在服务器上测试时（系统CentOS 6.4，支持SO_REUSEPORT但是不支持TCP_FASTOPEN）跟macOS Sierra上差不多，但是考虑到服务器的CPU性能强大得多，所以负载不高情况下，macOS Sierra的表现是最好的。由于macOS Sierra是从Mac OS X更新来的，而Mac OS X的底层最初是在FreeBSD基础上开发的，所以推测在FreeBSD上的表现应该也不错。
从文档中可以看到，该参数允许多个socket绑定到同一本地地址，即使socket是处于listen状态的。
Apisix 是一个用使用 lua 语言编写的网关控制器，相比官网介绍的 apisix 是一个网关，apisix 的实际用途更像是一个控制器。因为其本身代码不承载流量。apisix 运行于 openresty 之上，openresty 运行于 nginx 之上。
我们知道，像 Nginx、Workerman 都是单 Master 多 Worker 的进程模型。
Quic已经作为了下一代http协议HTTP3的实现。以前给大家介绍过quic的实现智能依靠Golang的quic库实现。在web中的表现即为前文所述的CADDY服务器实现quic：CentOS7.6安装Caddy服务器及PHP7.4环境，实现QUIC配置。
本文翻译自 Facebook 在 LPC 2021 大会上的一篇分享：From XDP to Socket: Routing of packets beyond XDP with BPF[1]。
由于目前浏览器对HTTP3.0/QUIC的支持性有限，可以使用 https://http3check.net/ 来验证站点启用HTTP3是否成功。
前言：今天下载了Node.js最新版代码，并为Node.js的TCP模块增加了SO_RESUEPORT的能力，本文介绍一下具体的实现，关于SO_RESUEPORT的知识可以参考之前的文章或者网上文章。
QUIC 是英文“Quick UDP Internet Connections”的简写，由 Google 创建并于 2013 年发布。Google 开发 QUIC 是为了解决传输控制协议 (TCP) 需要多次来回建立连接并开始传输数据的问题。因此，它会产生很长的往返时间，这可能会转化为糟糕的用户体验。 QUIC 改为使用用户数据报协议 (UDP) 来传输流量。UDP 减少了客户端和服务器之间的往返次数，因此加快了速度。这在移动网络上很重要，因为移动网络仍然是一个非常有争议的资源，任何可以加速它们的东西都是受欢迎的。
大家好，我是来自哔哩哔哩的郑龙，2012年至2017年我在广播电视行业从事工作，2017年我转型至互联网行业并加入了哔哩哔哩的视频云团队。在视频云团队的三年里，主要参与了哔哩哔哩的亿秒级日吞吐视频转码系统的开发与自营视频窄带高清技术的探索，以上两项服务都已上线并长期运行。
1. Requests per second（RPS）：Nginx 每秒处理的请求数（也就是 QPS）。
所谓惊群现象,简单的来说就是当多个进程或线程在同时阻塞等待同一个事件时,如果该事件发生,会唤醒在等待的所有的进程/线程,但最终只可能有一个进程/线程对该事件进行处理,其他进程/线程会在失败后重新休眠,唤醒多个进程/线程这种不必要的行为会造成系统资源的浪费(涉及到进程的上下文切换)。而常见的惊群问题有accept惊群、epoll惊群。
服务器是现代软件中非常重要的一个组成。服务器，顾名思义，是提供服务的组件，那么既然提供服务，那就要为众人所知，不然大家怎么能找到服务呢？就像我们想去吃麦当劳一样，那我们首先得知道他在哪里。所以，服务器很重要的一个属性就是需要发布服务信息，服务信息包括提供的服务和服务地址。这样大家才能知道需要什么服务的时候，去哪里找。对应到计算机中，服务地址就是ip+端口，但是ip和端口不容易记，不利于使用，所以又设计出DNS协议，这样我们就可以使用域名来访问一个服务，DNS服务会根据域名解析出ip。解决了寻找服务的问题后，接下来的问题就是服务器如何高效地处理连接。本文介绍服务器处理连接的架构演进。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
