我的意思是使用 HTML5 套接字并且不需要安装的纯 javascript 客户端，只需在浏览器中打开单个 js 文件。是否有可能编写这样的客户端？
有没有办法在 Linux 下查看侦听套接字上的队列长度，与netstat -LFreeBSD 的输出相同？即你可以在netstat -L输出中看到 X/Y/Z ，但 Linux 下的 netstat 不支持-L标志。
TIME_WAIT在 Mac OS X 上没有通常，当 TCP 连接关闭时，close()首先被调用的那一侧的套接字将保持在该TIME_WAIT状态。
当其中一个对等方是 Mac OS X (Lion) 机器时，如果在 Mac 端首先调用，则在 Mac上不TIME_WAIT列出 by 。然而，似乎插座的实际状态，因为试图调用一次（不使用套接字选项）会导致失败。netstat -anclose()TIME_WAITlisten()SO_REUSEADDRlisten()
等待 2*MSL（Maximum Segment Lifetime，在 Mac OS X Lion 上为 15 秒，由 报告sysctl net.inet.tcp.msl）清除TIME_WAIT状态，并且listen()可以再次调用而不会出错。
为什么我看不到插座TIME_WAIT？
这里有两个简单的 Python 测试程序。
服务器
#!/usr/bin/env python
import socket
HOST = ''
PORT = 50007
l = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
l.bind((HOST, PORT))
l.listen(1)
print("Listening …我正在尝试使用 siege 和以下命令在我自己的服务器中进行压力测试：
$ siege -c 500 myweb.com/somefile.php
但我收到此错误：
[error] descriptor table full sock.c:119: Too many open files
我也收到了这个警告：
libgcc_s.so.1 must be installed for pthread_cancel to work
但是我使用的是 Ubuntu 15.04（开发分支）并且我已经安装了 libgcc1 包，所以我不知道它为什么要抱怨那个 .so 共享库。
如何解决打开的文件过多和 libgcc 警告？
在许多 TCPIP 和 Web 调试指南中，建议在收到错误“打开的文件太多”时增加文件描述符的最大数量
但是，我在“lsof -i”的输出中看不到 TIME_WAIT
有谁知道 TIME_WAIT 消耗文件描述符？或不
Tomcat 给我留下了 CLOSE_WAIT 套接字，最终使最大连接数饱和。
我在我的客户端和服务器代码中尝试了很多方法来摆脱这些都无济于事，包括关闭连接、调用 System.gc() 等。
现在我试图找到一种方法来简单地在操作系统中快速超时。我有 conntrack 工作，但不知道如何使用它来终止这些连接。我还将 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait 设置为 1，这当然太低了，但连接仍然存在。
有没有办法杀死这些僵尸套接字？
运行 Ubuntu。
我们有一个 Web 层，其中一个 Web 节点偶尔会攻击我们的数据节点（复数），如果我们可以看到 MB/秒在所有套接字或单个套接字上进入该机器，我们可以立即知道哪个 Web 节点启动大量涌入做事。这对我们的监控能力非常有用。
有没有办法查看机器“当前”的 MB/s 摄入量？
我不想使用测试节点之间带宽的工具，而只想测量当前状态。
是否有可能为 unix 套接字创建硬链接？我正在创建一个监狱并且符号链接不起作用，所以我正在寻找一个解决方案，如何在 chrootted 环境中提供一个 unix 套接字。
我遇到的唯一想法是使用类似 netcat 的东西，但有没有可靠的可能性？
在装有 Ubuntu 14.04 的计算机中，我可以执行以下操作：
$ nc -l 5349 -vvv
Listening on [0.0.0.0] (family 0, port 5349)
或这个：
$ nc -vvv -l 192.168.254.96 5349
Listening on [192.168.254.96] (family 0, port 5349)
并打开一个套接字以侦听我本地 IP 地址 (192.168.254.96) 上的输入连接。显然我可以从另一端连接并传输数据。
但是在带有 Debian 8.0 Jessie 的 NAT 后面的服务器中，我收到了这个奇怪的错误：
$ nc -vvv -l 5349
5349: inverse host lookup failed: Unknown host
nnetfd reuseport failed : Protocol not available
listening on [any] 38541 ... : Protocol not available
或者：
$ nc -vvv -l 10.1.6.189 5349
10.1.6.189: inverse host …我最近了解了 FreeBSD 的accept_filter套接字选项，它可以允许工作进程避免上下文切换，例如，等待直到收到完整的 HTTP 请求accf_http：
这是一个放置在套接字上的过滤器，该套接字将使用 accept() 接收传入的 HTTP 连接。
它阻止应用程序通过 accept() 接收连接的描述符，直到内核缓冲了完整的 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求。
如果收到的不是 HTTP/1.0 或 HTTP/1.1 HEAD 或 GET 请求，内核将允许应用程序通过 accept() 接收连接描述符。
accf_http 的效用使得服务器在执行请求的初始解析之前不必多次上下文切换。这通过将预分叉服务器（如 Apache）中的活动进程保持在较低水平并减少需要由接口（如 select()、poll() 或基于 kevent() 的服务器。
我的直觉是，在现代硬件上，通过高速连接（电缆调制解调器/DSL 速度或更好）向客户端提供流量，这可能是一种微优化。鉴于它accf_http不能用于 HTTPS 或 HTTP/2 连接并且accf_data只等待第一个字节，我在这里看不到太多优势。也许他们会保存一两个上下文切换？
是否有任何最近的（可能是 2015 年之后？）关于 FreeBSDaccept_filter实际可以提高多少性能或吞吐量/并发性的基准测试？