Betflop Asked:2022-08-18 22:03:08 +0800 CST2022-08-18 22:03:08 +0800 CST 2022-08-18 22:03:08 +0800 CST gRPS 如何处理大量连接？ 772 我没有找到关于 gRPS 如何处理大量同时连接的正常解释？ 是不是需要把前面的nginx web服务器挂掉等等 ? 还是它本身充当 Web 服务器？ 我需要自己运行大量线程吗？还是在 gRPS 服务器本身的级别上使用您编写的语言的代码进行配置？ python 1 个回答 Voted Best Answer Pak Uula 2022-08-19T02:37:11+08:002022-08-19T02:37:11+08:00 大概在说gRPC。 gRPC当客户端连接时，服务器会创建一个新套接字并在其上挂起一个消息处理程序。这些处理程序的确切工作方式取决于编程语言。 这些go是 goroutine，运行时本身go决定在哪些线程中执行它们。因此，go几个连接的处理程序可以并行工作。 这些python是 Python 线程，但由于 Python 在单线程模式下工作，它们在运行时内切换，事实上，在任何给定时间执行的此类处理程序不超过一个。 关于 TCP 套接字如何工作的简短教育计划 由于您有关于“分发到其他套接字”的问题，我将简要描述服务器如何在套接字之上工作。 TCP 套接字有两种类型——服务器套接字和客户端套接字。客户端可以连接到服务器并可以传输数据。服务器套接字不能传输数据，但它们可以等待来自客户端的连接请求。 客户端如何连接到服务器。 在服务器端，程序执行了几个系统调用：bind将套接字绑定到 IP 地址和端口，listen切换到服务器套接字模式，accept等待连接（实际上，通常情况下，它有点复杂，但对于教育计划不是必需的）。 调用accept被阻塞，直到从客户端收到连接请求。当客户端连接时，内核内部会创建一个客户端套接字来与客户端通信。此套接字附加到服务器进程的文件表，并在调用中返回其文件描述符accept。这个新创建的套接字是一个客户端套接字，即它可以用来监听数据（recv）或发送数据（send） 接下来发生什么。 所有服务器的设置方式大致相同。一旦accept客户端套接字返回到服务器代码的荒野中的某个地方，接收数据的处理程序就会与它相关联。当套接字从客户端接收到数据时，服务端基础架构找到处理程序并调用它（这里我故意不写select/ poll）。这就是gRPCWeb 服务器的工作方式。 限制 服务器基础设施可以对连接数和流量施加各种限制。 首先，操作系统内核限制了一个进程打开的文件数量。从操作系统的角度来看，客户端套接字是一个文件，所以这个限制会导致它accept返回一个错误too many open files。我最近遇到了这个。我忘了把它提高到ulimit极限，经过几天的工作，服务器gRPC出现了这个错误。累积的打开文件的数量leveldb以及在某些不确定的时刻哎呀-服务器崩溃了。 其次，gRPC您使用的库可能会限制连接数。如果它accept返回一个新的套接字并且打开的客户端套接字的数量已经达到了指定的限制，那么新的套接字会在没有附加处理程序的情况下简单地关闭。 第三，库可以对从套接字接收的数据量施加限制。由于所有使用套接字的工作通常都是封装的，并且处理程序接收现成的数据，因此对于过于活跃的套接字，可以在计时器上访问新数据。比方说，在处理程序完成后的几秒钟内，而不是在完成后立即。 有关第一个限制，请参阅操作系统文档。特别是在 Linux 上，这是一个ulimit. 第二个和第三个在gRPC您正在使用的库的文档中。
大概在说
gRPC。gRPC当客户端连接时，服务器会创建一个新套接字并在其上挂起一个消息处理程序。这些处理程序的确切工作方式取决于编程语言。这些
go是 goroutine，运行时本身go决定在哪些线程中执行它们。因此，go几个连接的处理程序可以并行工作。这些
python是 Python 线程，但由于 Python 在单线程模式下工作，它们在运行时内切换，事实上，在任何给定时间执行的此类处理程序不超过一个。关于 TCP 套接字如何工作的简短教育计划
由于您有关于“分发到其他套接字”的问题，我将简要描述服务器如何在套接字之上工作。
TCP 套接字有两种类型——服务器套接字和客户端套接字。客户端可以连接到服务器并可以传输数据。服务器套接字不能传输数据，但它们可以等待来自客户端的连接请求。
客户端如何连接到服务器。
在服务器端，程序执行了几个系统调用：
bind将套接字绑定到 IP 地址和端口，listen切换到服务器套接字模式，accept等待连接（实际上，通常情况下，它有点复杂，但对于教育计划不是必需的）。调用
accept被阻塞，直到从客户端收到连接请求。当客户端连接时，内核内部会创建一个客户端套接字来与客户端通信。此套接字附加到服务器进程的文件表，并在调用中返回其文件描述符accept。这个新创建的套接字是一个客户端套接字，即它可以用来监听数据（recv）或发送数据（send）接下来发生什么。
所有服务器的设置方式大致相同。一旦
accept客户端套接字返回到服务器代码的荒野中的某个地方，接收数据的处理程序就会与它相关联。当套接字从客户端接收到数据时，服务端基础架构找到处理程序并调用它（这里我故意不写select/poll）。这就是gRPCWeb 服务器的工作方式。限制
服务器基础设施可以对连接数和流量施加各种限制。
首先，操作系统内核限制了一个进程打开的文件数量。从操作系统的角度来看，客户端套接字是一个文件，所以这个限制会导致它
accept返回一个错误too many open files。我最近遇到了这个。我忘了把它提高到ulimit极限，经过几天的工作，服务器gRPC出现了这个错误。累积的打开文件的数量leveldb以及在某些不确定的时刻哎呀-服务器崩溃了。其次，
gRPC您使用的库可能会限制连接数。如果它accept返回一个新的套接字并且打开的客户端套接字的数量已经达到了指定的限制，那么新的套接字会在没有附加处理程序的情况下简单地关闭。第三，库可以对从套接字接收的数据量施加限制。由于所有使用套接字的工作通常都是封装的，并且处理程序接收现成的数据，因此对于过于活跃的套接字，可以在计时器上访问新数据。比方说，在处理程序完成后的几秒钟内，而不是在完成后立即。
有关第一个限制，请参阅操作系统文档。特别是在 Linux 上，这是一个
ulimit. 第二个和第三个在gRPC您正在使用的库的文档中。