全部都 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 我说框架版本号

@ClericPy 版本号没上 1.x 的都存疑

@tikazyq #31

> 不知道有不有相关的大佬会看到这篇文章回去升级登录验证方式的，例如用 JWT

建议先搞清楚 jwt 是什么。
而且，用这种方式绕过登录并不代表网站的验证方式有问题，和浏览器正常访问完全相同的 HTTP 报文服务器怎么区分? (不考虑请求频率

你说的这种方式确实有用，比如我不想花时间破解验证码，只想用程序批量获取登录后数据时。但你煞有介事的发个帖，给我的感觉就是半瓶子晃荡

SICP 本身和 fp 关系又不大，顶多算普及了一下 Scheme 语法

@chinemds
a12 按理差别不大，知乎上也有 Air3 白斑的

@zh92412
@heygum97
pro2018 的材料据说易弯，这一代品控真的一言难尽