違いました。 id:yamadamn さんにコメントいただきました。



EM監視メトリックのWeblogicのアクティブ・セッションは何か - ablog


The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period, across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times. The server can maintain a session in many ways such as using cookies or rewriting URLs.

HttpSession (Java(TM) EE 7 Specification APIs)

サーブレットにアクセスしてHttpSessionオブジェクトが生成されるとWeblogicなどのJavaアプリケーションサーバでHttpSessionオブジェクトは一定期間生存する。従って、「HttpSessionオブジェクトの数 >= TCPセッション数」となると思われる。
http(s)はステートレスなプロトコル、keep-alive を使うと接続を維持するが*1、通常 keep-alive(十数秒〜1分とか)よりもセッションタイムアウト(20分とか)のほうが長いことが多い。




EM監視メトリックのWeblogicのアクティブ・セッションは何か - ablog


Currently Open Sockets: The current number of sockets registered for socket muxing on this server.



Systems Performance: Enterprise and the Cloud

Systems Performance: Enterprise and the Cloud

  • 10.4. Architecture
    • 10.4.1. Protocols

Three-Way Handshake

Connections are established using a three-way handshake between the hosts. One host passively listens for connections; the other actively initiates the connection. To clarify terminology: passive and active are from [RFC 793]; however, they are commonly called listen and connect respectively, after the socket API. For the client/server model, the server performs listen and the client performs connect.
The three-way handshake is pictured in Figure 10.6.

The TCP protocol was described earlier. This section describes performance features of the kernel TCP implementation: backlog queues and buffers.
Bursts of connections are handled by using backlog queues. There are two such queues, one for incomplete connections while the TCP handshake completes (also known as the SYN backlog), and one for established sessions waiting to be accepted by the application (also known as the listen backlog). These are pictured in Figure 10.10.
Only one queue was used in earlier kernels, and it was vulnerable to SYN floods. A SYN flood is a type of DoS attack that involves sending numerous SYNs to the listening TCP port from bogus IP addresses. This fills the backlog queue while TCP waits to complete the handshake, preventing real clients from connecting.
With two queues, the first can act as a staging area for potentially bogus connections, which are promoted to the second queue only once the connection is established. The first queue can be made long to absorb SYN floods and optimized to store only the minimum amount of metadata necessary.
The length of these queues can be tuned independently (see Section 10.8, Tuning). The second can also be set by the application as the backlog argument to listen().