虽然随着越来越多的高级组件和包的实现，关于计算机底层的知识在现在的实用性并不是那么明显，特别是在日常的工作开发中，几乎没有人在开发的时候重复的造轮子，毕竟已经有现成的马车甚至是汽车在跑了，如果还在纠结与那些轮子用什么木料的问题，就显得不合时宜，同时也是成本高昂的投入了，所以在目前的大多数开发过程中，如果存在比较成熟的技术的时候，我们就不会再去自己造轮子，甚至也不需要知道他的底层逻辑了。虽然这违背了一个技术的基本，但在业务和技术相互融合和促进的今天，业务已经不像以前那样变得过于简单了，特别是与技术融合较多的地方，业务就变得更复杂，这种趋势是必然的，技术为业务复杂提供了基础，如果技术不能为业务复杂提供支持，那么技术就失去了他真正的价值和意义了。而复杂的技术一方面就占用了普通技术开发人员的时间和精力，就更没有时间去做更加底层的开发了，所以我们目前看到了一种新的趋势，就是真正的技术和业务都趋向于专业化，而留给中间的开发人员就是他们衔接的一部分，也就是作为即是技术的同时也是业务的。这种业务技术人员的主要工作便是将业务在技术的基础上得以实现。也是目前大多数项目组中占比比较多的成员。
但一个项目组应该是对称的，也就是说，在业务和技术两个极端上应该也是极端对称的，这种对称使得项目组在纵向上有一定的深度，能够出现业务到技术的一种过渡，这种过渡的纵深线是一个项目存在的基本，如果一个项目只有技术或者只有业务，或者只有业务技术人员，那这种没有深度线的项目组会存在一种过度的匮乏，也就是无法实现他真正效能的缺陷——业务整合技术，没有这种基础，会导致项目的产出出现单极化。所以技术极端和业务极端是必要出现的，也可以整合到一个人的身上，也可以是两个人，或者多个人组成的团体。可以这么说，我们在项目中应该分组，一个技术组一个业务组，中间形成一个线性的过渡层面，从业务到技术，或者从技术到业务，一个线性的流程。这样的流程看起来是一种需要沟通和时间精力的成果转化，每个极端都应该输出一定的成果以输入到另外一个极端，没有完全是平均主义的那种高效，但针对优质的产品输出来说，这种极端正好让业务和技术都发挥更高的效能。
所以技术仍然是重要的，不是说业务技术就完全抛弃了技术，或者不求甚解，而是说需要有一个角色的定义，来实现项目深度的融合。
tcp作为网络技术一个非常重要的传输层协议，是日常用到最多的协议，也是在高并发情况下，讨论得最多的协议，虽然目前协议运行稳定高效，几乎不会出现问题，日常完全没有必要去理解他，但既然在作为技术极端的一部分，那就非常有必要理解这些底层的轮子是怎么转的，以为技术输出做准备。
tcp是一种协议，协议的意思是更多人遵守的规范，我们当然可以在网络协议中利用udp自定义自己的传输层协议，又或则完全依赖网络层定义自己的协议，但这样的做的结果就是，其他设备需要同样遵守你定义的东西，在没有被普及之前，这个成本是高昂的，就像我们经过上千年发展形成的一种文化或者一些看起来不那么实用的规范来说，改变一个东西并不是因为它好不好用，而是因为他需要付出的太多代价。所以协议是非常重要的，具有单一发布源的协议比更多机构发布的协议更具有社会价值，因为好歹我们做到了统一。更何况tcp已经算是非常成熟高效好用的协议了。
谈到tcp，让人最熟悉的莫过于他的状态，什么三次握手四次挥手，都是围绕着两端的状态变化来进行操作的，而表示这种状态多且不同的状态有特有的事件和动作的程序，一般使用的就是状态图，而将这种能够直接表示为状态图的程序，称为状态机（或许有人在计算机语言，语义分析，又或者在字符串匹配当中已经见到过这个概念——没错他们是一样的）。在状态机的表示下，理解tcp就更加清晰了。当然也可以用流程图或者其他图，但都没有这种表示更加直观，贴合tcp的真实情况。
相较于udp，tcp提供的功能就是可靠传输，接受端有序，拥塞控制。而实现这些功能，tcp内部则实现了校验，发送接收窗口，ack确认，以及慢启动，拥塞避免和快速恢复。通过这些概念，tcp实现了一整套的逻辑，完成人们对tcp功能的定义，保证数据在一定的速率下可靠有序的传输到接收方上级程序。具体实现的细节也并不复杂，其中涉及的流控概念在现在很多的网络项目中也有实践，可以说底层的轮子虽然不用再造，但造轮子的经验还是可以重复被运用到其他地方，特别是一些网络要求严格的项目中。
网友评论