从管理风格的角度看 TCP/IP
从一道经典的问题说起
请描述一下TCP与UDP协议的不同
这有什么好讲的，即使是初入职场的同学们多少都可以答上一些，再不济也能答上一句：“TCP是面向可靠连接的协议而UDP则不是。”，好一些的会接着从协议的角度来答TCP是通过什么样的机制来保证连接的可靠性（3次握手和4次挥手、流量控制、超时重传、拥塞控制等等）。
这些都是知识性的信息，能回答出TCP通过什么样的机制来保证连接的可靠性说明你在这块的知识是结构化的，同时侧面体现出你有建立自己知识结构的习惯（嗯，在面试中可能是个加分项）。然而今天的这篇文章并不想从这些已有的知识中进行知识整理和挖掘，想从这个问题的一个引申结论谈起。
UDP协议要比TCP协议好
先抛开观点的对错不说，这样的一种表述其实就不是客观的，在一个讨论问题的环境中很容易就引起一片争论不休的情绪碰撞，场面很可能不亚于“PHP是最美的编程语言”和“最好编辑器”的争论。
其实稍微客观点的描述会是：
同等条件下，UDP协议的实现性能会优于TCP协议实现
持这样观点的同学的依据是：
- UDP在协议层仅仅是在数据报文前添加传输层头部信息，而TCP做了3次握手和4次挥手等其他保证传输可靠性的工作
和管理又有什么关系
如果你熟悉TCP协议，熟悉其中的三次握手和四次挥手的协议细节，如果将协议中的这几个角色做一下替换，看看会有什么的结论：
应用层：大老板
传输层：中层管理者
网络层：一线工程师
网络包：工作任务
UDP：希望用行政手段解决问题的管理者
TCP：懂技术细节的希望用技术手段解决问题的管理者
三次握手：项目按照立项流程启动
四次挥手：项目按照工程管理流程进行总结结项
哎～是不是感觉好像还真的对上号了。
大老板负责定方向、提需求，具体是用技术的方式管理还是行政的方式管理项目不是他该关心的部分。
技术风格的中层管理者拿到立项的项目就需要想了：
- 这个任务是不是大到需要拆分的程度（是否需要网络分包）
- 如果是拆分，需要拆成几期（每个网络包的大小该是多少）
- 用什么策略来控制项目进度？
由于是新的团队还不知道工程师实际的工程能力，所以打算实行前期多一些设计工作和逐步增加任务的策略去找出团队交付速度的临界点（TCP慢启动），到任务饱和点（临界窗口值）的时候，考虑适当减少任务安排并保持现有的交付速度（拥塞避免）。 - 和需要合作的其他团队该用什么策略和机制沟通进度？
前期大家都不太熟悉、对按时完成任务的目标都没有信心，所以沟通的频度会高一些，比如一天两次或者一天一次；
后来大家发现，很多资源都浪费到召开沟通会议上了，反而影响了交付的效率，所以决定降低开会确认进度的频率（TCP延迟确认），进度报告也选择在有个稍微大一些进度的时候进行信息同步（Nagle算法）
行政风格的中层管理者在处理相同场景的任务时就是另一个风格了：
这是上面老大（应用层）的给的需求，你们看着办。
底下的兄弟们（网络层）听到是大老板的需求，自然也不敢怠慢，可是具体该怎么做能搞定这个大需求也是一头雾水，只能先按功能数量进行任务拆分，什么系统架构，系统伸缩性的都不管了，老夫上来就是coding一把梭（UDP将分包直接交给IP层进行）。
幸运的是这样的项目机制在前期还比较顺利，但是随着项目规模的逐渐变大（数据包增大）、项目中其他因素的影响不断增多（网络信道环境变化）出现bug增多（丢包）的情况，由于交付物中也没有日志和必要的提示信息，所以合作团队只能给简单的反馈“产品有bug”（UDP丢包反馈），收到反馈的工程师们由于没有反馈信息，排查起来也是一头雾水，所以管他三七二十一先重新打个包发过去再说（UDP 丢包整包重传）。
所以故事讲到这里，你还认为“UDP的性能要比TCP好”么？
难道真的就是一无是处了
当然不是，行政风格（特别是公司就只有大老板一个人担任这个角色的时候）的管理在一家初创公司的初期阶段也有着积极的意义：
- 不需要遵从繁琐的各种公司流程，只要是有利于业务的事情就去做，团队执行力强。
- 不需要层层汇报，大老板直接拍板决定，决策效率高。
- 快速执行、快速试错、快速验证商业模式。
所以行政式的管理风格并不是一无是处，效率低只是用错了场景。
