在互联网领域有所谓的全栈工程师，就是集需求分析，架构设计，软件开发，代码测试，功能验证，运营维护于一身的全能型软件工程师。因为互联网领域发展快，迭代速度快，所以传统的分工协作方式越来越不适应这种节奏，全栈工程师可以快速响应市场需求，快速交付软件功能，这种能力才是互联网领域目前最需要的人才。

对于网络设备商来说，基本还是传统硬件开发，软件开发，功能测试，故障维护等角色的分工协作方式，因为网络设备功能复杂，又涉及硬件软件等多个领域，所以这种方式倒也可以适应行业的需求。但是最近一些年，由于网络技术的发展，接口速率有了很大的提升，对应的协议和功能也复杂了不少，导致在软件开发领域有了更加细致的分工，各种协议的负责人可能是不同的，芯片驱动的特性也是不同人在开发，最终的结果是每个人都是盲人摸象，只熟悉自己的一个小领域，对于网络设备的真正现网应用，使用场景，客户与网络需求其实是没有感受的，这一部分会体现在当网络设备出现故障的时候，没有人可以从整体上分析问题，只能多领域协作讨论，解决问题效率低，反应慢。另一方面体现在，对于系统问题缺少总设计师，即缺少从全局和系统视角来进行方案和特性设计人员，导致系统性特性实现缓慢。

那么问题来了，网络设备领域是否也需要全栈工程师呢？网络设备的系统级问题的解决方式是怎样的？带着这些问题，我对于网络设备领域的全栈工程师有了一些个人的理解。

最近在看 TCP 拥塞控制的一些原理介绍，虽然 TCP 这个概念从大学时候学习计算机网络就接触了，但是一直都是模糊的印象，停留在诸如三次握手，四次挥手，面向连接，提供可靠传输这些层面。这次学习拥塞控制控制原理，突然发现有些视角和网络工程师有偏差，比如对于丢包的理解。

网络工程师一说到丢包，总会优先考虑是不是线路问题，比如链路质量不好，或者业务不通，而从 TCP 的设计者来看，丢包发生意味着发生了拥塞，在这里不考虑链路本身导致的丢包，所以 TCP 的拥塞控制主要考虑发生丢包后如何减少网络负担，然后再小心的去探测拥塞是否已经不存在了。TCP 同时还使用测量出的往返时延 RTT 变化来调整各种窗口，进而影响网络吞吐，而 RTT 会受到网络抖动的影响，比如拥塞导致的时延增大，或者转发缓存导致的时延。

拥塞丢包在实验室环境只能模拟，并不会主动发生，而模拟出的拥塞一般很严重，比如大量丢包，但实际场景下拥塞可能很严重也可能很轻微，这就会导致传输层的各种不同表现，进而影响客户对于网络质量的感知。TCP 发展到现在对于拥塞丢包已经有全面和成熟的应对策略，这表现在即使短时间发生丢包然后恢复，TCP 的网络吞吐也能很快适应过来，如果长时间大量丢包当然会影响 TCP 的表现，但这也意味着网络上出现了比如网络风暴，或者异常流量，需要网络管理人员介入排查。但是如果网络的的时延和丢包在不断变化，而且比较明显，进而影响到 TCP 性能，这个时候用户感觉就是网络慢，但是网络工程师却没有什么可以排查的办法，因为这不是直观的故障，目前的方法是用各种 SLA 或者探针工具测量一下网络性能。

网络工程师很多时候测量业务使用的是简单的二层或者三层流量，本质来说这些都是无状态的流量，无状态可以指单方向前后两个报文无关联，也可以指双方向之间的报文无关联，而实际的网络中这些都是有关联的，所以会出现用测试仪软件检测好好的网络，为什么实际业务带宽忽高忽低不稳定，或者客户抱怨网速很慢，这都是网络工程师对于网络端到端业务原理不熟悉导致的。

通过这个简单的例子，我们就可以知道，经验丰富的网络工程师，不仅仅要了解网络，还要对网络连接的客户端有所了解，比如 TCP 协议，比如最新的 QUIC 协议，以及现在数据中心使用的 RDMA/RoCE技术，现在流行的说法叫做主机网络。只有对于网络设备和连接的主机有全面的了解，才能叫做合格的网络设备全栈工程师。