http cookie，tcp syncookie 和 tcp fastopen 杂谈

syncookie 和 fastopen 的应用场景不赘述。它们均使用了 cookie 机制，返回给 client，再由 client 带回来用作识别。

说到它们的具体实现时，只要涉及 “识别” 机制，很多人都默认该机制需要 “解码 cookie”，“以 key 查 value 来定位用户”，大致就是 http cookie 那套逻辑，然而 tcp 的 syncookie 恰恰是不想在 server 保存任何可供识别的信息，而 fastopen server 在收到 client 携带的 cookie 建立连接之前，连接并不存在，何谈信息识别。这里有人要说了，连接虽没有建立，也不妨碍 server 端有一张 key-value 表，用 cookie 查询到 value，直接创建连接岂不是更帅？

还是得从现实的世界去理解，而不是老在协议技术范畴绕圈圈。我问如何理解 tcp 的各种 cookie，上来就拿 http cookie 说事，其实 cookie 这个词都有点不达意，把 cookie 叫 ticket 才更合适。

http cookie，就是现实世界的会员卡，一次消费用不完预充值的钱，下次过来店员看你会员卡就能自动关联到余额，实际上也就是一个 key 查 value 的操作，背后也没摆脱电脑。更朴素的例子，在饭店吃饭买了一瓶酒，临走时没有喝完，顾客会把酒存在店家，店家开个小票写上酒被存放的位置以及一些其它信息，下次顾客再来消费时，可以拿这张小票取出存放的酒继续喝，这就在无状态的单次消费中关联了状态。

tcp syncookie 在现实世界也容易理解，高峰旺季时期的饭店，酒店一般都会取消预订，目标是最小化顾客等待和最小化浪费，防止有人预订来不来或来得太晚，占着茅坑不拉屎的时间段内资源无法被利用。

在现实世界，当然还有更好的方案，比如预订交押金，实际到达后打折冲消费或原价返还，如果违约未到，扣除部分甚至全部押金，作为对资源闲置的补偿。 此外，对于预付费预订业务，比如机票，火车票，如果后续退票，收取大额手续费是合理的，这笔费用其实就是时间压缩成本，因为从你购票到退票，距离飞机起飞或火车开车肯定越来越近，售票方将退票再次卖出的难度越来越大，而退票者显然要为此买单。

从现实世界反射回 tcp/ip。恰恰 tcp 无法采用预订押金或退票收费这种方式缓解 ddos。按照 tcp/ip 互联网早期的假设，互联互通是免费且随时进行的，原则上，任何 ip 地址在任何地方都能访问任何别的 ip 地址，这注定了互联网上所有的连接请求都是不速之客，这是互联网安全问题的根源。

如果我们的现实世界也如此，所有的收费服务，熟人关系，票务服务均将消失，这种环境下，所有的恶意事件只能事后追查而无法事前抑制。

再来看看 fastopen，它实际上就是现实世界的 “记名不挂失的门票”，比如 “不限次数的月卡，季卡，年卡”，过期后自动作废，但在有效期内不限次数。理解了这一点就知道它和 key-value 毫无关系，server 需要做的只是一个 verify 操作，首先它要 verify 这张票是它签发的，其次它要 verify 这张票属于持票的人，这些都很容易，票上只要写上用户信息并加盖场所公章即可，检票员通过公章识别是自己签发，通过比对用户身份证和票面信息确认持票人权限。在 tcp fastopen 涉及的 coockie 中，server 通过一个密钥加密 client 的 ip 等信息作为记名门票，当 client 再次前来建立连接，server 通过解密其携带的 cookie(只有它能解密)，比对 coockie 解密后包含的 ip 地址和 client syn 报文的 ip 地址，即可确认 client 是否有 fastopen 权限。

理发店会员卡，小饭店存酒等 cookie 行为具体会在会员卡和小票上存储什么信息全由商家自主决定，可记名也可不记名，可能只要有那张纸条，就可以去饭店喝掉别人存的酒。这种行为确实完全没必要标准化，因为 cookie 行为的波及半径仅限于商家，而商家又是如此之多。http cookie 于此类似，早期的网站，只要拿到 cookie 并拼接在 url 后面，就能直接登录别人的账户，这问题只能网站自己负责，如果网站不希望这种事发生，开发者可以很容易加入一些更严格的认证逻辑，将更多信息编入 cookie。

但机票，火车票，大型酒店的各种卡几乎都是记名的，且拥有统一标准，因为它们提供的是 “基础服务” 而不是 “最终服务”，引号内的词是 传输层 和 应用层 的区别。最后，我们发现，tcp 的 cookie 生成相比 http 的 cookie 生成更加标准化，因为 tcp 提供基础运输服务，http 提供最终服务。

…

协议设计要从现实世界学习，绝大多数问题在现实世界都被解决过，如果只在技术范畴比划概念，你的设计大概率不光更复杂，更可能引入新问题。

浙江温州皮鞋湿，下雨进水不会胖。