9月15日技能沙龙 | 怎样将智能化和运维作业相结合，完结智能运维！
2013年，慕尼黑
现在适当多的程序员都是“互联网程序员”，按说，应该对互联网的根底协议适当清楚。惋惜至少就我的面试经历来看，许多人这方面缺课太多，简略说说TCP/IP协议分层就现已难倒了不少人。至于TCP/IP的“三次握手”，能说上来的人就适当少了，假如再问问“为什么是三次握手”，底子就没人能答上来了。一般的答复都是“这个太难”，或许“结业太久，这个忘记了”。
假如临时抱佛脚，把TCP的三次握手背下来敷衍面试，的确能做到。可是要答复TCP为什么是三次握手，而不是两次或许四次握手，光靠背就不可了——不信你去网络上搜搜看，各种答复都有，议论纷纷，不少发问者一头雾水。
TCP相关的常识重要吗?我觉得挺重要的，这些年来不论互联网怎样改变，TCP协议自身都能够承载，细心探求会发现它的规划的确够奇妙，有许多值得学习的规划思维。
那么TCP真的很难吗?为什么许多人背TCP的握手流程痛苦不堪，复述起来困难重重?我觉得，原因在于咱们只把它当成“既存现实”， 就像上中学时分背前史政治那样对待。但TCP可不是毫无逻辑的胡说，一旦 你搞清了规划思维和逻辑，就会发现了解起来一点也不困难。所以，今日我来做个简略解说。
首要说说“三次握手”这个译名，我的确觉得翻译有误(翻译出书过一百多万字技能材料，我自傲仍是有把握的)。我曾经总记不住“三次握手”的进程，由于总觉得“握了三次手”，“握手”是两边一起往中心凑的进程，这显着和建连流程不符合。后来才发现，“三次握手”的说法大约有问题。
“三次握手”的原文是three-way handshake，three-way更适宜的翻译恐怕是“三步”，所以整个名词的意思是“需求三个进程才干树立握手的机制”。这么解说的优点是，“步”给人感觉更形象，就是“单方面迈一步”罢了。实际上，RFC 793里说明晰，握手进程也能够叫three-message handshake，经过三条音讯来树立的握手。
那么，为什么要三步才干树立握手呢?咱们能够暂时不睬这个问题，想想假如咱们自己来规划握手机制，应当怎样办。
咱们都知道，TCP是牢靠的通讯协议，其“牢靠性”就在于，任何一方要向另一方发数据(SYN)，都有必要收到承认回应(ACK)。一同TCP也是双向的通讯协议，所以通讯的两方都能够自动发送音讯。
这儿要弄清的一点，对许多“互联网程序员”来说，TCP是掩盖在HTTP之下的，咱们了解的HTTP，它的经典通讯形式是“一问一答”的，没有恳求就没有应对。不过这仅仅HTTP的特性，不是TCP的特性。在TCP协议里，客户端和效劳器都能够随时自意向对方发送数据——也正是由于如此，改用HTTP/2之后效劳器能够自动推送信息给客户端，而不用改动TCP协议。
回到TCP，已然它是双向、牢靠的通讯，能够想见，树立衔接就有必要承认两边到对方的通讯都是牢靠的，所以大约需求四步，发送四次音讯。
假如软件规划都这么简略，那就太好了。惋惜，世界上没有那么简略的作业。细心观察这幅图，咱们会发现几个问题：
榜首，网络通讯的成本是很高的，推迟往往无法猜测，哪怕能少发送一次音讯，也能够大大降低成本，进步功率。所以，树立衔接的进程上限应当是四步，下限是两步，越少越好。
第二，两轮SYN/ACK之间有必要有相关，由于它们的功用相对独立，都是承认到对方的通讯牢靠，却同归于一个“树立衔接”的逻辑操作。假如两轮彻底独立，那么假如两轮中心间隔了特别特别长的时刻，底子不是一个正常的树立衔接的操作，程序却无法辨认，这明显是不可的。所以，第二轮SYN/ACK有必要要能够和榜首轮SYN/ACK相关起来。
再细心看看，第二步和第三步都是从效劳端给客户端发音讯，所以是不是能够兼并起来?这样最少能够节约了一次网络通讯。
像上面这样直接在第二步把ACK和SYN兼并起来，问题就处理了?
依照之前的剖析，节约音讯发送次数仅仅考虑之一，还需求考虑的是，第二轮SYN/ACK有必要和榜首轮SYN/ACK挂钩。
上面是TCP的数据报，包括了许多的操控位，用来标识衔接的状况。其间最常见的是SYN、ACK、FIN：SYN表明synchronize，在树立衔接时运用;ACK表明acknowledge，表明“承认”收到了音讯;FIN表明finish，在断开衔接时运用。
还要留意的两个东西是SEQ NO和ACK NO。SEQ NO即Sequence Number，效劳端和客户端都会保护自己的SEQ NO，表明“现已发送了多少数据”，单位是字节;ACK NO即Acknowledge Number，用来回复承认，对应SEQ NO的数据现已收到。独自说起来，这些概念都简略了解，仅仅留意不要混杂操控位的ACK和ACK NO——ACK是布尔值用来标识数据报的类型，ACK NO是数值用来承认现已收到的数据。
根据上面的常识咱们能够知道，在树立衔接之初，数据报中的操控位SYN应当设定为1，表明“新建衔接”;一同应当包括SEQ NO。此刻的SEQ NO有个专门的名字叫ISN，也就是Initial Sequence Number(要留意，ISN仅仅用来称号这个特别SEQ NO，并不存在专门的ISN字段)。
在效劳端收到榜首个SYN音讯的时分，它当然需求发送ACK呼应，但它怎样承认其间的SEQ NO“就是”新建衔接的ISN，而不是来自缓不济急的某个陈旧衔接呢?所以有必要向客户端承认。恰恰由于第二步是ACK,SYN“合二为一”的一起呼应，所以收到这个音讯时，客户端就知道，既需求呼应其间的SYN，也需求核实其间的ACK(假如你细心读过RFC793就会知道，其间专门有一段说到了： A three way handshake is necessary because…… )
到了第三步，客户端回来的音讯里既包括对应SYN的ACK，表明收到了效劳端的音讯，一同设定SEQ NO=ISN+1，承认核实了ISN。效劳端收到这条音讯，承认无误是要树立新衔接。至此，衔接树立完毕。
大流程看起来就是这样，也不难了解。不过细心想想，仍是有不少问题得考虑的。比方状况问题，已然TCP是网络通讯，会发作推迟，那么在“信息现已发送，但还没有收到承认”的时分，应当是有个清晰状况的，不然会发作状况的紊乱。实际上TCP也的确做到了这点，它背面有一台完好的状况机，确保每时每刻，每个动作发作之后，状况都彻底可控，全部尽在把握，不会呈现任何“孤点”和“断头路”。
上图是TCP的状况搬运图的部分，覆盖了树立链接的状况，感爱好的读者能够依照自己实地逛逛看(说个题外话，“自己模拟在图上逛逛”看起来土，其实高科技范畴也挺常用。规划波音737的时分，开端咱们都不知道发动机怎样摆比较好，规划师乔·萨特就在纸上画出机身和发动机的模型，把发动机模型剪下来在飞机遍地摆放，终究发现吊在翼下最适宜)。
我在之前关于软件规划的文章里几回说到状况图、状况搬运函数，不论是用户生命周期、订单流通进程，都能够用这个东西来处理。惋惜的是，我发现还有许多规划人员不懂得或许不习惯用运用它，真实很惋惜。
回到TCP树立衔接的进程，咱们还要留意ISN。在树立衔接时有必要先断定ISN，经过它把客户端和效劳器的计数对齐。一般的教材上说，ISN是随机生成的，这样就确保了仅有性。 随机的意图是坚持仅有，但千万不要以为“随机就不会重复”，简略的“取随机数”是很简略磕碰的。所以传统的“随机”计划是保护一个时钟和一个32位的计数器，时钟每过4毫秒，计数器自增1。由于2^32毫秒就是差不多4个半小时(MSL，Max Segment Lifetime)，这底子超出了任何数据包在网络中的可能传输时刻，所以能够以为这种ISN是绝无仅有的。
但这种计划也有危险，已然这样的ISN是接连的，那么半途的恶意程序可能能够猜测ISN的生成规则，然后假造ISN…… 总归ISN的生成是个风趣的规划问题，这儿不展开了，有爱好能够自己查找材料阅览。
我在开发中遇到不少程序员，一旦需求防止重复，就想到“生成随机数”，底子不论随机数也可能磕碰。更有甚者，一旦遇到相似ISN的场合，就想当然把初始值设定为0，真是让人欲哭无泪(有没有想过ISN为什么不能设定为0呢，欢迎留言评论)。
说完了树立衔接的握手，咱们再来看停止衔接的挥手。一般咱们都知道，TCP是“三次握手，四次挥手”(尽管我很不拥护“次”，但已然它现已约定俗成，这儿仍是延用通用的说法吧)。那么，为什么要四次才干挥手呢?
知道这个答案的人比能讲清楚“三次握手”的要多。一般的答案都是：TCP是双向通讯协议，要完毕衔接，两边都有必要发送停止信号，通知对方后续再没有数据发过来了，并等候对方承认，所以总共需求2+2=4次。
假如你之前看过树立衔接的进程，大约会有这样的疑问：已然树立衔接的时分能够节约一步，把效劳端回来SYN和ACK兼并到一同，那么完毕衔接的时分，是否也能够把效劳端回来的SYN和FIN兼并起来，节约一步呢?
想到了这个问题就值得祝贺，由于你不是只满足于“知其然”，而期望“知其所以然”。不过咱们也需求想到，已然TCP衔接的树立和停止都是同一批人界说的，已然他们能想到在树立衔接时节约一步，那么他们没有理由在停止衔接时不做节约。之所以没有“节约”，一定是有理由存在的。
没错，的确是有理由的，并且这个理由很好了解，由于树立和停止衔接的场景是不一样的。在树立衔接之前，客户端和效劳器端都不会向对方发送任何数据，所以在效劳端回来ACK的时分带上SYN，客户端当然知道这是从效劳端收到的榜首个数据包。
而在完毕衔接时，客户端向效劳端发送FIN，表明“我这边不会持续发送数据过来了”，效劳端呼应ACK，这都没有问题。但此刻，效劳端之前向客户端发送数据的操作可能还没有完结，效劳端仍然在向客户端传输数据。假如效劳端把FIN和ACK兼并起来，就会呈现这样的状况：客户端的数据还没有接受完，遽然收到效劳端的音讯“后续没有数据了，停止衔接”。明显，这种状况不应当呈现，所以不能把ACK和FIN兼并在一同，所以停止衔接有必要要四步。
最近和实习生谈天，说起开发中遇到的各种问题，以及对应的模型，咱们听得着迷。过后有人问我：为什么咱们作业中遇不到这么有意思的问题呢?我知道，这是个比较典型的问题。其实答案也很典型：由于你没有去深究问题背面的原型。懂得了背面的原型，就具有了“从已知推导无知”的身手，也具有了“从无知中发现已知”的眼光。
我和朋友聊开发有个一起的判别：TCP的握手和挥手看起来简略，但真让现在的开发人员去规划握手和挥手流程，估量有超越一半的人规划不出安稳、牢靠、高效的握手和挥手流程。这样说来，许多事务体系里事务层面的通讯极不牢靠，协议规划讹夺百出，也是无法的成果了。
弥补一句。我曾在面试中遇到过这样的人，非名校结业，现已有五年作业经历，除了对盛行的结构和热点问题对答如流，对数据库理论、网络根底常识、数据结构和算法仍然如数家珍。现实充分证明，不是所有人作业之后就把大学的常识丢个精光的，现实也证明，这样的提名人的确能担大任。
