楼主加个验证码限制一下频率啊

Django 和 flask 都是慢的真实，sanic 和 tornado 也好不到哪去。虽说是 io 密集操作，语言本身性能不是非常重要，但就是被隔壁 PHP7 吊起来打。原来看过有个 japronto 标榜的很强，基本都是 c 写的，但版本号还没上 0.2

光这几个域名怎么判断是黑产，有可能只是 ping 一下看网通不通。可以尝试逆一下固件，看看有没有可疑的 c2 服务器地址。或者没人用的时候监控一下路由器看有没有和奇怪的主机通信

@lcj2class 理解了，确实，`m := map[int][1]int{1: {1}}; m[1][0] = 99`也不行

以前还没注意到`m[1].name = "2"`会报错，不过刚试了下：`map[int][]int`的`m[1][0] = 2`和`m[1] = append(m[1], 0)`操作都是允许的，这就奇怪的

@whoami9894 #2
又看了一下，还有点问题
如果你那个`infimanage.Sync`是个 interface 并且实际类型是个 pointer 的话才会出现我#2 说的问题，不过看你最后生成的数据里只有`{false 1KB-2KB}`相同，后面的 uuid 是不同的，那么就排除我#2 说的情况。猜测是你后两次迭代的 JSON 数据中`{false 1KB-2KB}`字段有误（比如字段名出错），导致只 unmarshal 了后面的正常数据到你复用的 sync 里，然后把 sync 的拷贝 append

而且你粘贴的输出明显有问题：
`{[] [{false 1KB-2KB}] [] []}}`
`{[]{false 1KB-2KB}] [] []}}`
`{[{false 1KB-2KB}] [] []}}`
建议按上面几点自己排查一下

全部都 unmarshal 到同一块内存了，你应该每轮迭代定义个新 sync

输两次只有一个目的：防止用户手误。前端校验一下两个 input 值相同就 OK 了。后端再校验一次的意义是啥? 咋还扯到 mitm 了

@lcdtyph 还是相同的 SSL_ERROR_SYSCALL

@GDC 鹅厂，今天又发了封面试邀请邮件。看不懂，也不知道是不是同一个部门

安研有吗

安全岗貌似全是 base 上海 or 北京啊

@rio
我明白你的意思，楼主用 io.ReadFull 处理 packet，用 header 记录 body length 确实是不理解 UDP，也肯定没有看过 io.ReadFull 的实现，所以楼主的问题是需要补一下计网的知识
至于多大才是足够大，如果是收发自己设计的应用协议，那就按约定的格式来，设计尽量处于 ethernet MTU 的大小范围内。但假如是收发未协商大小的包，比如做 UDP 端口转发，每个 buffer 需要给到 65507

@rio
你的回复在说`net.PacketConn.ReadFrom`返回值的第一个就是 body 长度。假设我给个 1024 bytes 的 buffer，实际 packet 有 1400 bytes，ReadFrom 给我返回的一定是 1024。packet 长度确实是确定的，但 ReadFrom 传进去的 buffer 该分配的大小在事先是不知道的（在没有提前协商的前提下）。就好比我需要知道 length 才能调用 Read，你告诉我你调用 Read 就知道 length 了一样。楼主确实看起来没有 UDP 编程经验，所以直接告诉他分配一个足够大的 buffer，不需要像 stream 一样去做额外的上层分包就行了

requests.post(url, data={'json_download': '{"docs":[.......]}')

你这样传参应该编码成%2f 吧

@ydongd 应该不用考虑 ether 的 MTU 吧，给的 buffer 大于 1500 应该也会在内核缓冲区拼接的（我猜的）

@rio 楼主问当不知道 UDP packet 长度时怎么分配 buffer 大小，buffer 给小了导致后面数据被 drop，你答 UDPConn.ReadFrom 第一个返回值就是 body 长度？你听明白他问啥了？你答的又是啥？

@dawniii 一个是 stream 一个 packet，TCP 一次读不完还存在协议栈缓冲区，UDP 按报文划分，buffer 过小后面数据直接 drop 了

@rio #18 你这逻辑，先后次序都颠倒了

@ClericPy 我说框架版本号