计网 - 计算机网络开篇

2021-08-17 10:37:56 浏览数 (1)

文章目录

  • Pre
  • 知识点
    • 网络的基础结构
    • 工作原理
    • 应用场景
  • 系统学习
    • 互联网和传输层协议
    • 网络层协议
    • 网络编程
    • Web 技术
    • 网络安全

Pre

不知道你有没有遇到过,因为 TCP 队头阻塞,没有预备方案,导致分布式集群中部分服务发生延迟,导致系统雪崩

  • DDoS
  • DNS 劫持
  • 跨机房通信问题

网络是一种工作技能, 比如

  • 很多候选人在回答“TCP 为什么要 3 次握手”这样简单的问题时,就像背经文一样,没有自己的理解;
  • 当面对“HTTPS 协议的 TTFB 传输时间”这类需要将 TCP 的原理和 HTTPS 结合起来思考的问题,就更加束手无策。

此外,工作当中也经常要用到计算机网络的知识,而且一旦用错就容易造成灾难性的后果,给公司直接带来经济损失。


但实际情况是,很多程序员对网络相关的知识一知半解,不足以应对日常的工作需求。

  • 遇到网络故障(如 DNS 故障)时,由于没有系统性地学习过网络相关的知识,对Linux 下,诸如 nslookup、telnet、lsof、netstat 等网络相关的指令一知半解,导致不知道如何定位问题;
  • 很多人使用 TCP 连接时,只考虑收发数据,不能考虑到队头阻塞、多路复用等问题,导致经常出现系统负载不高,但是吞吐量很低的情况。

一名程序员,无论是应对日常开发、日常排查,还是解决突发的网络问题(网络调试、网络优化)都离不开计算机网络。而要想成为优秀的工程师、架构师,朝着更高阶、更高薪的岗位去晋升,补足编程必备基础知识——计算机网络是绕不过去的一关。


对程序员来说,计算机网络解决的是常识问题,有了这些常识,你才能更好地利用工具解决工作中的问题。比如用 telnet 调试远程服务、用 Whireshark 抓包定位网络故障;再比如把 ulimit 设置成多少?Dubbo 异步单一连接扛不住了该怎么办?用 HTTP 协议的 Keep-Alive 维持心跳可不可行?等等。

在工作中,当你想快速进入一个领域开发程序,马上就会面临诸如:我用哪个协议?用哪个网络框架?如果计算机网络知识不扎实,很容易选错;另外,你也没有办法优化参数,或者当你承接了系统优化的工作时,由于计网知识不扎实,会陷入无穷无尽的学习。比如今天碰到 TCP 队头阻塞,明天碰到滑动窗口,后天碰到 ARP 和路由算法。


知识点

从基础结构、工作原理、应用场景三个维度,系统性地梳理和讲解计算机网络知识,解决日常工作场景中遇到的网络问题。

网络的基础结构

了解计算机网络的生态和基础设施。 讨论日常生活和工作中常见的东西,比如路由器、交换机、终端、基站等,介绍它们背后隐含的网络,比如公司网络、家庭网络、网络边界等,以及组织它们工作的网络协议栈,TCP/UDP/IP 等。

前端工程师,平时只用 HTTP 协议就够了。那需要了解吗?

一个首页日 PV 在百万级别的电商类网站。 首页有 100 多个卡片,突发奇想地做前端组件化,本来是想解决组件和服务间依赖的问题,让每个卡片自己发请求到服务端。由于上线比较晚,代码 Review 的时候并没有发现,结果变更提交到了线上。

可想而知, 服务器挂了。。。。。。

这是什么原因导致的呢?要知道每个卡片单独发请求,我们每次打开网站首页,都会发送上百个请求到服务端。这位前端同学的处理方式,直接把服务器的请求数量提升到亿级别 (百万 * 100),相当于做了一次压力测试和人肉 DDoS。

有同学说,不知者无罪,毕竟 HTTP 协议里没有讲“不能发送这么多请求”。可是,网络是有吞吐量限制的,这是一个常识问题。所谓常识,就是作为工程师本应掌握的知识。


听完这个故事,服务端同学可能很开心,暗自窃喜:“我们服务端,肯定不会犯这种常识性错误。”

维护一个中间层。请求到达中间层,还需要去其他内部服务请求数据,然后组装统一返回。结果中间层很不稳定,经常出现延迟很高,而且内存使用很高的情况。

DUMP 了一下内存,发现大量连接对象。经过排查,是因为接收每个请求,系统都会建立很多个到其他服务的连接。在网络波动期,连接持续积压,导致频繁创建 Socket 文件,最终超过操作系统的限制崩溃。

你可能会说,这是一个技术问题,可以用多路复用、长连接、队列等方式解决。但是抛开这些专业的网络 IO 技术问题,这是不是一个常识问题呢? 答案当然是。因为网络连接是有成本的,而且网络是不稳定的。不稳定的情况下,连接数应当有所限制。


工作原理

介绍网络的工作原理,里面会涉及一些算法问题,比如滑动窗口、路由和寻址。还会涉及细节问题,比如讲解一些封包格式,但更多的是理解网络的工作原理,比如多路复用、缓存设计、Socket、I/O 模型等。

有同学说,网络库一大堆,用就好了,还有必要理解原理吗?

举个例子: 数据量千万级资源仓库,对外提供RPC服务。本地集群压测报告 QPS 3000。

服务上线之前,幸好有另一位工程师对这个 3000 QPS 的设计很感兴趣。自己又写了一个压测程序,远程调用测试集群压测,结果在 1000 QPS 就打挂了。

这是怎么回事呢?因为 3000 的 QPS 是在最邻近的网络节点,用少量连接测试得到的结果。1000 QPS 则是模拟了一个延迟较高的网络,用较高的并发数连接测试的结果。

所以你凭直觉说,哪份测试报告更加靠谱?当然第二份报告更有意义,网络是一个不稳定的环境,服务端随时面临大量的并发连接。大家都使用网络库,但是如何根据自己的业务场景、网络特性、I/O 特性、计算资源特性,优化网络,这就需要你了解网络的工作原理了


应用场景

  • HTTPS 协议握手的过程?
  • RPC 是如何工作的?
  • IM 系统是如何工作的?
  • 抓包用什么工具?
  • 要注意什么安全攻防?
  • 网络出了问题怎么排查?

系统学习

互联网和传输层协议

介绍互联网的体系和整体框架,参与的硬件设备,以及它们的作用。还会介绍传输层协议 TCP 和 UDP,重点讨论它们的工作原理、算法和优化策略。这部分知识是计算机网络的基础,也最能体现网络设计的精髓。


网络层协议

围绕局域网和 IP 协议展开,包括 ARP、IPv4、IPv6、NAT 等基本概念,探讨 IPv6 的工作原理,以及 IPv6 和 IPv4 的兼容策略。IP 协议几乎是网络层的唯一协议

互联网和传输层协议 和 网络层协议 属于基础篇,是计算机网络最底层的基础知识。


网络编程

围绕 Socket 讨论网络编程,介绍各种网络 I/O 模型和编程方式的优缺点,并以 RPC 框架设计为题去落地学到的这些知识和实现。讨论在不同的并发量、针对不同服务特性选择不同的 I/O 模型,调整 TCP 关联的参数,等等,进而学习如何优化自己系统的网络。这部分内容会为企业带来实际价值,


Web 技术

讨论平时使用最多且最重要的应用层协议——HTTP 协议(包括 HTTP 2.0),并扩大讨论范围到 Web 技术生态,比如从 DNS 看缓存、从 CDN 看负载均衡、从 HTTP 协议看开发规范、从流媒体技术看协议选择,以及从爬虫技术看网络安全。


网络安全

讨论网络安全技术,一部分是基础设施,比如证书、加解密、公私钥体系、信任链等;另一部分是具体的攻击手段,比如 DDoS、XSS、SQL 注入、ARP 攻击、中间人攻击等,以及它们的防御手段。安全是所有互联网公司的高压线,学完这块内容能够帮助你屏蔽掉一些高危操作,在工作中避免出现安全问题。

0 人点赞