极端一点,买 DDoS 把网站搞瘫痪。多搞几次,就说这网站都动不动打不开,水平不行.哪天就跑路了。如果官方说是人太火爆才打不开.就告诉他是你搞的.

恰恰相反，我得出的热水定律是“当你想要一杯热水快速冷却时，这杯水真的会冷的更快！”
它的理论依据是：
1.很急喝水情况下，你会不停的用嘴去试探温度，小啜一口，这会不经意间提升你对热水的容忍程度，最后你可能在水温还是在 65 度左右就能完全喝下去了。（而且大概率是先喝一小口解渴，然后再稍微等会儿，就可以全部喝下去了）
2.平时我们感觉水冷得慢是因为我们当时不急着喝水，只会用手去触摸，有时候水温是 50 度，你手一摸好烫，然后就觉得水还没冷，先不喝。但其实它已经可以喝了。本质就是其实一杯沸水冷却到可以喝的程度其实比我们想像中的快。

解释一下:
1.原理是给伪随机数生成器一个确定的种子,那么他的随机数生成也变得确定了.保证结果可重现.
2.用这个算法,就要等到明天 9 点 30 开奖,如果想立即开奖,也可以改成今晚 12 点的比特币价格或者其它国家的股市收盘价格(建议用开 /收盘价格,它是一个定值,而比特币时刻在变).
3.运行环境可以用在线 python 工具(比如 https://c.runoob.com/compile/9)或者指定 python 版本来保证结果可重现.
4.可以再多加几层混淆,但是我觉得没必要了.

# -*- coding: UTF-8 -*-
import random

#明天开盘时的上证指数*100 的值
sh_value = 3083.39
#楼层总数
msg_count=1234

#初始化随机值
random.seed(sh_value * 100)
seed2 = random.randint(1,9999)
random.seed(seed2)

//开始抽奖
print "第一个中奖者楼层:%d" %random.randint(1,msg_count)
print "第二个中奖者楼层:%d" %random.randint(1,msg_count)
print "第三个中奖者楼层:%d" %random.randint(1,msg_count)
print "第四个中奖者楼层:%d" %random.randint(1,msg_count)
#如果上面有重复,后者用候补顶替
print "候补中奖者一:%d" %random.randint(1,msg_count)
print "候补中奖者二:%d" %random.randint(1,msg_count)

留言支持一下.

同楼上,先是完全 unblocked,可以$$直连,然后今天发现可以 ping 通,但$$怎么都连不上.
遇到这种情况,建议中间再加一层 kcptun 就好了.

eGlhbzE3MTc0QDEyNi5jb20=
你们都在国外吗,带上我

是不是漏掉个关键点,就是尽量每个 ap 尽量不要相同频段,且尽量有较大差值.

时代技术不允许.主要技术壁垒就是电池.
当然,如果电池技术突破了.你说的这事就不是事了.

@Chingim
1.你理解成我是倚老卖老也算是一种新的思路.我的本意是说你幼稚.
2.首先不是什么语言都有框架让你去认 content-type 的.裸解析 tcp 了解一下(我至少用两种语言做过这种事,因为它没有成熟的框架).其次,我已经说了假设了,假如一个 c 系程序员野蛮的把两个 json 拼接到一个 body 里.content-type 设成 text.现在要分别解析出两个 json 对象,那么这个最外层的引号就成为了一种分界标志.所以 string(string)+string(string)之后是一个 string,但是可以反解析出两个子 string.但是单纯的 string+string 是会完全合并成一个 string,不可逆的.
3.我再次强调这只是理论上的价值,有无数的理由让我们不要这样做.
4.你显然没有理解我上个回复中强调的内容.不要混淆 json 本身是个 string,即纯文本的本质.

@Chingim 应该是被成熟框架养得娇嫩的程序员吧.笑~.考虑一种情况.body 中不只是 json 或者不止一个 json 呢?
这么和你讲好了.我们可以把数据大概的看成三个层次:
1.最底层.一切皆是二进制.
2.中间层,数据都是 int/double/string/bool 等.
3.最上层,数据是 json/http/h264/mp3.
永远是越下层越通用.所以把 json 重新包装成 string,是把它通用化了.
当然,有一个概念不要混淆,json 以 string 作载体.这是协议规定的.也就是说,序列化后的 json 肯定是一个 string 即字符串.这个时候再做一次包装是 string(string).
做这个操作其实是很丑陋的.完全不建议这样用.
(可以用更好的办法规避它.比如永远保证一个 body 即是一个 json,json 里放 json 就可以了) 然而这就不在我们的讨论范围了.

我倒觉得还是有讨论价值的.
如果当成 json 对象,那么报文如下:
HTTP head
{"dds":2}
如果当成字符串,那么报文如下:
HTTP head
"{\"dds\":2}"
如果通信是使用成熟的框架肯定是第一种直接,Body 即 json.
但是如果考虑到通用性,其实第二种也有存在的价值.原因在于它被首先认为是一个字符串,这样即使在不支持 json 解析的系统中也被看成是一个整体.

@wohenyingyu03 感谢回复,不过你说的只是 kcp 本身的原理和理想情况下使用 kcp 所带来的开销.(kcp 本身并不是针对 fq 开发的(为了游戏),kcptun 倒是可以说是为了 fq 而生)
并且,你说的这些和大量重复发包并不冲突.我说的是表象,你讲的是重复发包的原因.kcptun 是基于 udp 的 kcp 实现,当你在 kcptun 中设置较高的流畅度时,在 fq 的场景下,流量 double 是很正常的.你可以实测一下.
同时倒推一下现象也不难发现,突然不能使用 kcptun 了,但同时在 kcptun 的 server 和 client 都不修改任何参数的情况下,隔一段时间又突然能上了.这不就是明显的被临时 block 端口的表现吗?那能被临时 block 端口的原因无外乎这么几个了.

kcptun 是通过大量的重复发 UDP 包来实现加速.而这种加速其实挺占带宽的.甚至看起来像是 DDOS,所以很容易被链路上的某点封端口或者临时黑名单.

另外补充一下,楼主图中的三种粘包情况的示意图,显然是一个半吊子人画的,1 和 2 还能理解是站在应用层看待 tcp 传输的,而情况 3 是不可能在应用层发生的.
情况 3 的确是 tcp 传输过程中会遇到的,但如果要讨论,这情况就多了去了:丢包,重包,乱序包.tcp 本身都已经把这些都处理掉了,所以在应用层,要么能接收到正确的数据,要么就是读不到数据.不会有情况 3 出现的.

楼主不要被楼上阵容整齐的的嘲讽给吓到了.其实很多人都吃过这个亏的.
楼主能够一本正经的整理出这么一大堆资料,也是一个认真的人.
相信你能在别的事情上成功的.
解释一下粘包,TCP 确实是没有粘包这个说法.之所以会有这个错觉产生,其实是由于自我脑补.
很多人第一次入门网络编程,往往是发一个"helloworld"到另一端,对端大多数时候一次回调或者读取就收到了整个的"helloworld".自然地就以为发了一次,收了一次.就是一个数据包的传输完成了.
这中间发生了什么呢?TCP 底层收到命令到要发送一块内存数据("helloworld"),那么发送端就一个一个字节(只是比喻,实际是 IP 数据帧)地向接收端发送.接收端也开始一个字节一个字节的接受.在发送前,两端没有任何的通信来约定这一次传输一共有多少长的数据.也就是说接收端在收到第一个字节的时候,并不知道接下来它还会收到剩余多少数据.
那么问题就来了,接收端通知你有数据可读时,是以什么为依据呢?
它的逻辑概括一下是(好久好久前的东西了,并不准确):1.收到了一些数据,并且在随后若干毫秒内就没有新数据了;2.数据缓存区满了;3.收到了其它的指令(重置,断开等).以上任意条件触发,那么就通知上层(你的程序)有 TCP 数据到来了.但是它本身并没有你所以为的另外一层含义----这是一个完整的数据包的到来.
只要清楚 TCP 的这一本质,那么你在写代码时就要知道,当你被通知有数据可以接收时,此刻能读取的这些数据本身并没有任何意义,它可能是某个完整数据包的一部分,也可能就是一个完整的数据包.只有你自己亲自去拆开(解析)它后才能判断.

只要是解码后再做操作的都是达不到 60 倍的.所以什么重采样之类的肯定是不行的.
所以核心思路是在解码前就决定出要显示多少帧画面,然后只解码这些帧,顺序播放出来.
如果是 H264 的话,提取出所有的 I 帧,基本上 I 帧都是完整压缩,而且是隔至少 1 秒才一张.
真正要做的就是挑出所有的 I 帧,然后根据快进倍速跳着解码渲染即可.