Tech:网络安全(基本素养)

同属<专家之路>,写一写日常开发中必备的网络素养。这里我也不过分展开(全文展开,不算图,大概有2.5W词,只写框架则可以缩减到4K词),只是从上到下给大家捋一捋,大致框架及其部分解释。评级: 3系。

这里面的内容其实是非常多的,但是直接用于日常开发的却不多(相对比重不大),更多的是用在高阶问题排查方面,比如外放的API为什么请求超时了,为什么并发数上不去,dd命令的吞吐这么低?服务器如何对付大量的短连接,肉鸡攻击,检测生产部署环境的网络安全等。

有些层可以行云流水,有些层则不行(要看文档),下面是按照 5 层协议/4层模型中层展开的(而不是7层模型)。

应用层

这一层,可以跟着我的思路,行云流水(因为都很简单)

概略:

  • UR* 家族: URL, URI, URN… (前两者涉及较多) — 理解可拿本地文件的路径做对比(全路径名,文件名,不要后缀的名…) 值得一说的,WEB 上对外,一定谈的是 URL。(服务内才谈 URI)
  • HTTP报文的格式 (请求报文,响应报文) — 三段式,请求时需要告诉服务端哪些;响应式需要告诉客户端哪些
  • HTTP状态码 — 大分类(以1开头,2开头…5开头),以及具体常用的 Status Code 及其含义,最好有案例
    • 比如 Nginx 会返回 200 给客户端,用于告诉客户端请求的 favicon.icon 请求我受到了,但无内容返回
    • 状态码依据浏览器的实现不同,含义有略微差别;比如 302 协议规定不许把 POST 改成 GET,但是多数浏览器还是不按规矩办事,以免 307 好像是多余一样(307是确实不会改)
  • HTTP方法: 对应资源状态转移的操作行为,但是其超集,大概有9种,但常用的一般就 4 种
    • 4种依次是: GET, POST, HEAD, PATCH
    • 有些公开的服务,为了安全,甚至只对外开放 GET, POST (更多免费的API只提供 GET,常见于中国大陆)
    • GET 和 POST 的区别为什么不用 PUT 和 DELETEPATCH 相较于 PUT的优势
    • 了解 CONNECT 和 TRACE 的作用(扩展一下命令行工具 trace 的作用)
    • GET 和 POST 的区别很杂,大致可以从三个方面去谈: 生产实践的用途,数据传输及安全性,缓存意义支持上
  • HTTP无状态和面向连接的意义: 每次传输需要携带完整的信息,HTTP是一个基于TCP的应用协议
    • 为何引入 cookie 等这类客户端存储机制
  • HTTP协议版本与长连接,短连接的关系,相关优劣对比 (深刻理解 HTTP 的爸爸到底谁的问题)
    • 长短连接虽说需要客户端和服务端都支持 keep-alive,但更多的是指服务端做相关配置
  • Cookie的主要作用: 身份鉴定,会话保持,用户行为分析,个性化定制(国际化,是否已经点赞,主题配置等)
    • Cookie 为何会被淘汰,IndexedDB/WebStorage API 为何上位 (主要是性能和功能)
    • Cookie 的安全性问题 (响应报文可以写,客户端本地也可以修改): document.cookie, httponly,HttpOnly一定程度上保证了 XSS,但生产实践上更多的是外加一层保护,Cookie存储加密内容
    • Cookie 生命周期(换句话说,分类): 持久性 Cookie 和 非持久性 Cookie, expires
    • 作用域,主要是 DomainPath (特别注意,如果指定了 Domain,那么子域名也包含在内)
    • 客户端禁用了 Cookie 怎么办?(URL重写,在URL上带上 Session ID 这个 Cookie)
  • Session 的原理,为何存储在 Redis 中,而不是服务器 App,文件中
    • Session 的安全性问题,特殊场景即便 Session 认证OK,也还是需要重新验证的,比如转账就需要你重新输入密码
    • Cookie和Session分别对应了客户端和服务端存储技术,常用于认证和会话管理场景,但不要因此就把它们和认证技术等效,只能说基于 Cookie-Session 的认证技术,而不能说 Cookie 和 Session 是用于认证的(准确说,这只是他们的一个用途)
  • HTTPS 的原理,密码学原理(公钥密码术,对称密码术,摘要,数字签名,数字证书)
    • 单项散列(摘要fingerprint)不可反推 (非对称加密不可破解性: 给你结果和算法,不给秘钥,你也难反推原始信息,不可逆),例如 MD5, SHA; 单项散列本身只能验证数据完整性,不能确定消息是不是原始单位发送的 (除非和秘钥结合,指纹匹配成功,则表明既是你发送的,也是完整的)
    • 数字签名: 私钥加密,公钥解密,以验证消息或者摘要确实由原始方发送。签名其实说白了就是私钥加密过的原始信息的摘要的密文
    • 数字证书: https握手阶段,client 请求服务器网址,获取用于通讯的对称秘钥过程中,即握手过程中,使用的那个公钥(用于传递对称秘钥)真的是服务器给的么?一般而言是从第三方信任机构的数字证书里拿到的。(证书其实是用三方机构私钥对服务器的公钥签名,然后把三方机构的公钥及其签名打包,成为证书,发给client,验证通过即拿到公钥,然后进行后续的传输对称秘钥) 现实中向 CA 的申请证书原理类似,但是主导权一般在 CA (它给你生成私钥以及公钥,然后把私钥给你)
    • HTTPS优缺点 (HTTP报文篡改和劫持),HTTPS的版本及其改进
      • 中间人攻击
      • SSL和 TSL 的关系(SSL3.0和TSL,记录协议握手协议)
    • 为何 HTTPS 要同时使用两种加密技术 (对称加密性能好,加密快)
      • HTTPS协议中两种技术的分工以及握手过程 (握手不安全,明文传输)
      • 握手的过程可以了解大概 (目的就是为了协商出一份对称秘钥,根据3个 random数字,1,3由客户端生成,2由服务端生成),即了解握手协议即可
    • 公钥密码术的原理及其安全隐患(基于怎么样的数学原理以及相较于现代量子密码术的不足)
      • 用途: 加密(公钥加密),签名验证(私钥加密)
      • 为何需要第三方信任机构(验证公钥的有效性)
      • 除非知道秘钥,否则知道算法也无法破解(有限时间内) — 两种加密技术都如此
      • AES/DES, RSA的原理(不必掌握)
  • HTTP2.0 (HTTP1.1期间出现的增强HTTP协议功能的技术,大多数包含在 HTTP2.0中了)
    • 协议头压缩: HTTP/1.x每次请求,都会携带大量冗余头信息,浪费了很多带宽资源,压缩是当然的啦
      • 其实可以结合 tcp 窗口大小去看这个问题
    • 请求优先级: 请求中带有一个 31bit 的有限制,越小优先级越高,处理相应的流也越积极
    • 二进制及分帧: 1.x 是采用文本的,2.x采用的二进制传输,最小单位为帧;一个消息可以由多个帧组成,发送也可以乱序,接收后根据帧头的流标识符组装;同域名,但个连接承载所有信息
    • 多路复用: 1.x 相当于多 tcp 连接来提高并发(浏览器其实对于单域名的 tcp 连接数有限制,7-8 个,再有有请求也不能多开 tcp,只有阻塞等待);2.x 单域名只用一个 tcp 连接,当然是多路复用提高并发啦 (单 tcp 对于连接延迟,客户端/服务端内存占用都是友好的)
    • 服务器推送: 例如服务端可以主动把JS和CSS文件推送给客户端,而不需要客户端解析HTML时再发送这些请求。(客户端已经缓存的资源可以 rst 拒收)

当然还有一些网络安全(CSRF, XSS),WebSockets 等技术没有展开,有需要单独去说。

传输层

个人其实反对知道的越多越好 (知道的越多反而越不快乐,所以往往初学者最容易自满和信心爆棚)。

如果你没有听说过字节流粘包UDP本身不可靠需要编码辅助等问题,说明你至少没有在此层有过工作经历

如果你只做上层应用,那么这一层对你可有可无,学了不用也会忘记的。且协议在设计时就可以屏蔽了不相干层,即下层实现对上层透明(不可知)。意思是一直做应用的人,根本就不必看。(如果不是做后端优化,需要知道 TCP 各个状态流转情况么?可能真的不需要)

所以本文只谈基本素养,不会深入物理机,深入 tcp/ip 协议栈的实现

如果确定自己有涉及到滑动窗口分析,服务端连接处理,或者简单的 socket 编码等工作,OK,那么往下看。(否则回头是岸,活在应用层不丢人)

  • 四层模型中,为何把表示层和会话层统一放在应用层: 数据压缩处理,会话管理都可以在应用层编程处理
  • 四层模型中各层的作用:
    • 数据格式可见一斑: 报文,包,IP分组,帧+(物理层)字节流
    • 应用报文组织,(网络进程间)数据传输支持,路由选择&IP分组&IP规划,封装成帧&差错校验
  • 数据封包和拆包传输的过程 (注意一下数据链路层需要帧头帧尾)
    • 三层路由的作用(IP选择,重写)
  • 四层模型是指: 应用层,传输层,网络层,网络接口层(数据链路+物理层)
  • 常用的应用层协议对应的传输层协议是: HTTP, SMTP对应 TCP,DNS,RTP对应UDP
  • UDP和TCP特点一句话概括:
    • UDP: 面向报文(应用层的报文不拆分也不合并,直接加上UDP头),无连接,无拥塞控制,流量控制,出错重传等机制,尽最大可能的及时交付(其实不可靠),可用于一对一,一对多的实时通讯场景,比如电话,交互通讯
      • 没有相关可靠机制的检查和处理,所以UDP传输效率是高过TCP的,及时高效
      • 早期的腾讯QQ或采用UDP,但是近代通讯软件,一般会自己动手封装UDP,加上相关机制,或者直接采用TCP(因为机器性能越来越快)的socket
    • TCP: 面向字节流(会对上层报文进行拆分,合并,组织成大小不同的数据块; 一开始就当做字节流处理了),需要提前建立连接,有流量控制和拥塞控制,出错会重传,提供可靠传输,一般适用于一对一(点对点场景)
  • UDP和TCP 报文格式
    • 提到这个说明工作相关,对相关领域要求比较高(如果实在要求,可以说清楚给定报文头即可,即20字节首部)
    • 不展开,只说: 两者主要记录发送者进程端口和远端接受者端口信息,且TCP拥有保证保证可靠传输的数据位及字段(URG, ACK,FIN等,及序列号,确认号码,窗口,紧急指针)
  • TCP三次握手建立连接,四次挥手断开连接(过程及其作用)
    • 建立连接,两次不行
    • 断开连接,三次不行
    • TIME_WAIT, 2MSL
  • 如何保证可靠传输: 流量控制(滑动窗口),拥塞控制,超时重传,分割数据块(编号,重复丢弃),校验和
    • 按照上面的顺序,依次是: 按照对方缓冲区(窗口)大小动态调整发送包的大小及数量;根据网络的阻塞程度调整发包数量;定时器时间内,如果不能收到对方确认则重传;按字节分割包,编号,但无序发送,接收方按编号组织,遇到因超时重传的包则丢弃;校验数据及头部,出错包丢弃
    • 区分流量控制(窗口控制)和拥塞控制
    • 实际工作中对于上述算法的理解和优化 (比如 delay 延迟发送)
  • TCP 的状态流转
    • 通常抓包,比如用 wireshark, tcpdump 时,看到的就是这些状态,比如ESTABLISH,分析网络问题也多半需要参考这些状态,给与相应的措施
  • 超时重传,停止等待的原理及其过程

如果对上述挑出来的过程,核心,关键词非常熟悉,那么说明您修养不错。(核心在于对 tcp 状态的理解和分析,以及根据其可靠控制策略以及当前网络链路的状况优化,特别是低速链路网络中,很多原本可以进行的操作,也要改变编码策略)

网络层

做三层路由的人,或者在通讯公司从事底层协议研究的人,一般都在此层工作

  • (这一层其实内容也多,但是就编码工作而言,主要还是在上两层)

作为基本素养,一般需要了解和掌握如下:

  • IP 子网划分
    • 特殊IP: 本地回环(主要用于检测TCP/IP协议栈是否安装或者是否有异常),本地链路,广播
    • 对于 IP v6 的了解 (从其格式设计上说就可以了,不要说国际势力的较量)
    • NAT转换(对于 IP v4 的弥补)
  • IP 和 Mac 的转换
  • DHCP 协议 (自动获取IP的过程)
  • 子网掩码(mask)
    • IP 和子网掩码搭配使用的例子
  • 三层路由和二层交换机的作用和区别
  • ARP 和 RARP
    • 可以谈谈在大学期间用 arp 攻击控制局域网内他人网速的案例
  • ICMP 协议,即 Ping 的原理

学海无涯,回头是岸 (因为网络安全也是我主攻之一,后续逐个展开;始终和工作需求挂钩)

网络这一块的基本素养就这样了,专门做网络的研究员或者低一阶的运维,网管,后端优化人员等会有针对的学习一些其他的协议,或者自己设计一些协议;而普通开发人员,还是根据工作需求,以及自己的能力量力而行

如果有什么参考书籍可以看,个人建议,这类纯理论的内容,最好不要买什么图解xx技术的书(简单的理论配了大量的图,那是给外行看的),看看考研教材即可,学院派对于理论的折腾真的令人佩服。


CH-YK 2019.6 网络没意思,网络安全才有意思,攻伐谋略


文章目录
  1. 1. 应用层
  2. 2. 传输层
  3. 3. 网络层
|