计算机网络-0-知识点汇总.md

分层

应用层
- 应用层
  - DNS 域名解析协议
    - 域名解析协议是能够来将域名和 IP 地址相互映射，使人更方便地访问互联网的协议。
  - FTP 文件传输协议
    - FTP 协议是基于 TCP 的传输，FTP 采用双 TCP 连接方式，提供一种在服务器和客户机之间上传和下载文件的有效方式，支持授权与认证机制，提供目录列表功能。
  - SMTP 简单邮件传输协议
    - SMTP 简单邮件传输协议是一种提供可靠且有效的电子邮件传输的协议，它控制两个相互通信的 SMTP 进程交换信息。有以下三个阶段，连接建立、邮件传送、连接释放。
  - HTTP 超文本传输协议
    - HTTP 超文本传输协议是用于从万维网服务器传输超文本到本地浏览器的传送协议，它一个无状态的请求/响应协议，是因特网上应用最为广泛的一种网络传输协议，所有的 WWW 文件都必须遵守这个标准，HTTP 超文本传输协议基于 TCP/IP 通信协议来传递数据。
- 表示层
- 会话层
传输层
- 传输层协议为不同主机上运行的应用进程提供逻辑通信
- 传输层则负责将数据可靠地传送到相应的端口（端到端），传输层提供了主机应用程序进程之间的端到端的服务。传输层利用网络层提供的服务，并通过传输层地址提供给高层用户传输数据的通信端口，使高层用户看到的只是在两个传输实体间的一条端到端的、可由用户控制和设定的、可靠的数据通路。
网络层
- 网络层协议为不同主机提供逻辑通信。
- 网络层只是根据网络地址将源结点发出的数据包传送到目的结点（点到点），其主要任务是：通过路由选择算法，为报文或分组通过通信子网选择最适当的路径。该层控制数据链路层与传输层之间的信息转发，建立、维持和终止网络的连接。具体地说，数据链路层的数据在这一层被转换为数据包，然后通过路径选择、分段组合、顺序、进/出路由等控制，将信息从一个网络设备传送到另一个网络设备。
- 路由器的主要功能
  - 路由选择、分组转发，掌握原理
- 动态路由算法
  - 距离向量路由算法、链路状态路由算法
- IP 地址
  - IP 地址是 IP 协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异
- MAC 地址
  - MAC 是地址物理地址，用来定义网络设备的位置，在 OSI 模型中，第三层网络层负责 IP 地址，第二层数据链路层则负责 MAC 地址。
网络接口层
- 数据链路层
  - 可靠传输机制
    - 序列号、校验和、确认应答机制、超时重传、连接管理（三次握手四次挥手）、流量控制、拥塞控制
- 物理层
  - 物理层的几种复用
    - 频分复用、时分复用、波分复用、码分复用

网络层协议

IP

IP 协议用于屏蔽下层物理网络的差异，为上层提供统一的 IP 数据报。
IP 协议提供无连接的、不可靠的、尽力的数据报投递服务
- 无连接的投递服务
  - 发送端可于任何时候自由发送数据，而接收端永远不知道自己会在何时从哪里接收到数据。每个 IP 数据报独立处理和传输，一台主机发出的数据报序列，可能会走不同的路径，甚至有可能其中的一部分数据报会在传输过程中丢失
- 不可靠的投递服务
  - IP 协议本身不保证 IP 数据报投递的结果。在传输的过程中，IP 数据报可能会丢失、重复、延迟和乱序等，IP 协议不对内容作任何检测，也不将这些结果通知收发双方
    - IP 数据报的丢失，通过路由器发 ICMP 报文告知；必要时，由高层实体（如 TCP）负责差错恢复动作
- 尽力投递服务
  - 每个数据链路上会规定一个最大传输单元 MTU，如果 IP 数据报的长度超过 MTU，那么网络层就会把这些报文分割成一个一个的小组（分组）进行传送，以适应具体的传输网络
报文
- IP 数据报中含有收/发方的 IP 地址

ICMP

ICMP（Internet Control Message Protocol）Internet 控制报文协议。它是 TCP/IP 协议簇的一个子协议，用于在 IP 主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
ICMP 使用 IP 的基本支持，就像它是一个更高级别的协议，但是，ICMP 实际上是 IP 的一个组成部分，必须由每个 IP 模块实现。
PING 命令是利用 ICMP 协议

SSL/TSL

SSL
- SSL（Secure Socket Layer 安全套接层）以及其继承者 TSL（Transport Layer Security 传输层安全）是为了网络通信安全，提供安全及数据完整性的一种安全协议。TLS 与 SSL 在传输层对网络连接进行加密。
- SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
- SSL 协议可分为两层：
  - SSL 记录协议（SSL Record Protocol）
    - 它建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  - SSL 握手协议（SSL Handshake Protocol）
    - 它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
TSL
- TLS（Transport Layer Security）传输层安全是 IETF 在 SSL3.0 基础上设计的协议，实际上相当于 SSL 的后续版本。
- 结构
  - TLS主要分为两层
    - 底层的是 TLS 记录协议，主要负责使用对称密码对消息进行加密。
    - 上层的是 TLS 握手协议，主要分为握手协议，密码规格变更协议和应用数据协议 4 个部分。
      - 握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是 4 个协议中最最复杂的部分。
      - 密码规格变更协议负责向通信对象传达变更密码方式的信号
      - 警告协议负责在发生错误的时候将错误传达给对方
      - 应用数据协议负责将 TLS 承载的应用数据传达给通信对象的协议。

传输层协议

TCP

报文
- 报文头部
流程
- 在 TCP 中，有个 FLAGS 字段，这个字段有以下几个标识
  - SYN
    - 表示建立连接
  - FIN
    - 表示关闭连接
  - ACK
    - 表示响应
    - ACK 是可能与 SYN，FIN 等同时使用的
  - PSH
    - 表示有 DATA 数据传输
  - RST
    - 表示连接重置
  - URG
- TCP 状态表
  - CLOSED
    - 关闭状态，没有连接活动或正在进行
  - LISTEN
    - 监听状态，服务器正在等待连接进入
  - SYN RCVD
    - 收到一个连接请求，尚未确认
  - SYN SENT
    - 已经发出连接请求，等待确认
  - ESTABLISHED
    - 连接建立，正常数据传输状态
  - FIN WAIT 1
    - （主动关闭）已经发送关闭请求，等待确认
  - FIN WAIT 2
    - （主动关闭）收到对方关闭确认，等待对方关闭请求
  - TIME WAIT
    - 完成双向关闭，等待所有分组死掉
  - CLOSING
    - 双方同时尝试关闭，等待对方确认
  - CLOSE WAIT
    - （被动关闭）收到对方关闭请求，已经确认
  - LAST ACK
    - （被动关闭）等待最后一个关闭确认，并等待所有分组死掉
由客户端端口+服务端端口+客户端IP+服务端IP+传输协议组成的五元组可以明确的标识一条连接
使用 TCP 的协议：FTP（文件传输协议）、Telnet（远程登录协议）、SMTP（简单邮件传输协议）、POP3（和 SMTP 相对，用于接收邮件）、HTTP 协议等。
安全性
- 初始化序列号 ISN（Initial Sequence Number）
  - 三次握手过程是建立 TCP 连接的第一步，所以这里的序列号叫初始序列号 ISN。在后续通信中的序列号都是基于 ISN 计算出来的。所以 ISN 是后续通信的基础，如果在后续的报文中检查序列号不匹配，这个报文将被认为是非法报文，做丢弃处理。
  - ISN 生成基本规则
    1. 递增，直到超过最大值，再从较小的值开始。ISN 如果不是递增的，就可能因为网络延迟导致 ISN 重复，引起后续通信错乱，连接失败。
    2. 随机，ISN 必须是不可预测的随机数，如果 ISN 可以预测，将会引起很多安全问题。
拆包、封包
- TCP 是个”流”协议，所谓流，就是没有界限的一串数据。大家可以想想河里的流水，是连成一片的，其间是没有分界线的。但一般通讯程序开发是需要定义一个个相互独立的数据包的，比如用于登陆的数据包，用于注销的数据包。
- 由于 TCP “流”的特性以及网络状况，在进行数据传输时会出现以下几种情况
  1. 先接收到 data1，然后接收到 data2
  2. 先接收到 data1 的部分数据,然后接收到 data2 余下的部分以及 data2 的全部
  3. 先接收到了 data1 的全部数据和 data2 的部分数据，然后接收到了 data2 的余下的数据
  4. 一次性接收到了 data1 和 data2 的全部数据
  - 2、3、4 的情况就是大家经常说的”粘包”，就需要我们把接收到的数据进行拆包，拆成一个个独立的数据包。为了拆包就必须在发送端进行封包。
    - 封包
      - 封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了。
      - 包头其实上是个大小固定的结构体，其中有个结构体成员变量表示包体的长度，这是个很重要的变量，其他的结构体成员可根据需要自己定义。根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。
保活机制（keepAlive）
- 保活机制是由一个保活计时器实现的。当计时器被激发，连接端将发送一个保活探测报文，另一端接收报文的同时会发送一个 ACK 作为响应。
- 相关配置
  - 保活时间：默认 7200 秒（2 小时）
  - 保活时间间隔：默认 75 秒
  - 保活探测数：默认 9 次
- 过程描述
  - 连接中启动保活功能的一端，在保活时间内连接处于非活动状态，则向对方发送一个保活探测报文，如果收到响应，则重置保活计时器，如果没有收到响应报文，则经过一个保活时间间隔后再次向对方发送一个保活探测报文，如果还没有收到响应报文，则继续，直到发送次数到达保活探测数，此时，对方主机将确认为不可到达，连接被中断。
- TCP 保活功能工作过程中，开启该功能的一端会发现对方处于以下四种状态之一：
  - 对方主机仍在工作，并且可以到达。此时请求端将保活计时器重置。如果在计时器超时之前应用程序通过该连接传输数据，计时器再次被设定为保活时间值。
  - 对方主机已经崩溃，包括已经关闭或者正在重新启动。这时对方的 TCP 将不会响应。请求端不会接收到响应报文，并在经过保活时间间隔指定的时间后超时。超时前，请求端会持续发送探测报文，一共发送保活探测数指定次数的探测报文，如果请求端没有收到任何探测报文的响应，那么它将认为对方主机已经关闭，连接也将被断开。
  - 客户主机崩溃并且已重启。在这种情况下，请求端会收到一个对其保活探测报文的响应，但这个响应是一个重置报文段 RST，请求端将会断开连接。
  - 对方主机仍在工作，但是由于某些原因不能到达请求端（例如网络无法传输，而且可能使用 ICMP 通知也可能不通知对方这一事实）。这种情况与状态 2 相同，因为 TCP 不能区分状态 2 与状态 4，结果是都没有收到探测报文的响应。
- 弊端
  - 在出现短暂的网络错误的时候，保活机制会使一个好的连接断开；
  - 保活机制会占用不必要的带宽；
- 保活功能在默认情况下是关闭的。没有经过应用层的请求，Linux 系统不会提供保活功能。
- 相关问题
  - TCP 连接时，一方如何知道另一方【异常断开连接】?
    - TCP 不是轮询的协议，否则 TCP 将占用大量网络带宽。可以说 TCP 属于事件触发的协议，对等方的异常断链只能在应用层通过 send() 函数来判断，所以业界通常的做法是定时 send HEARTBEAD。TCP 还有个套接字 Option，设置后每隔 2 小时如果没有数据交互的话协议会自动检测。
确保可靠性的方式：
- 校验和
  - 计算方式
    - 在数据传输的过程中，将发送的数据段都当做一个 16 位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
  - 发送方：在发送数据之前计算检验和，并进行校验和的填充。
  - 接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
  - 如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。
- 序列号、确认应答
  - 序列号
    - TCP 传输时将每个字节的数据都进行了编号，这就是序列号。
  - 确认应答
    - TCP 传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送 ACK 报文。这个 ACK 报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
  - 序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。这也是TCP传输可靠性的保证之一。
- 超时重传
  - 发送方没有介绍到响应的ACK报文原因可能有两点：
    - 数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
    - 接收方接收到了响应的数据，但是发送的ACK报文响应却由于网络原因丢包了。
  - 重传机制就是发送方在发送完数据后等待一个时间，时间到达没有接收到 ACK 报文，那么对刚才发送的数据进行重新发送。如果是刚才第一个原因，接收方收到二次重发的数据后，便进行 ACK 应答。如果是第二个原因，接收方发现接收的数据已存在（判断存在的根据就是序列号，所以上面说序列号还有去除重复数据的作用），那么直接丢弃，仍旧发送ACK应答。
    - 最大超时时间（也就是等待的时间）是动态计算的
      - 在 Linux 中（BSD Unix 和 Windows 下也是这样）超时以 500ms 为一个单位进行控制，每次判定超时重发的超时时间都是 500ms 的整数倍。重发一次后，仍未响应，那么等待 2*500ms 的时间后，再次重传。等待 4*500ms 的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP 就认为网络或者对端出现异常，强制关闭连接。
- 连接管理
  - 握手、挥手
    - 三次握手
      - 过程描述
        
        第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SEND 状态。
        
        首部的同步位 SYN=1，初始序号 seq=x，SYN=1 的报文段不能携带数据，但要消耗掉一个序号。
        
        第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
        
        在确认报文段中 SYN=1，ACK=1，确认号 ack=x+1，初始序号 seq=y。
        
        SYN-ACK 重传次数
        
        服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。
        
        注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…
        
        第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
        
        确认报文段 ACK=1，确认号 ack=y+1，序号 seq=x+1（初始为 seq=x，第二个报文段所以要 +1），ACK 报文段可以携带数据，不携带数据则不消耗序号。
        
        发送第一个 SYN 的一端将执行主动打开（active open），接收这个 SYN 并发回下一个 SYN 的另一端执行被动打开（passive open）。
    - 四次挥手
      - 过程描述
        
        第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
        
        即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭 TCP 连接，进入 FIN_WAIT1（终止等待 1）状态，等待服务端的确认。
        
        第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
        
        即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号 ack=u+1，序号 seq=v），服务端进入 CLOSE_WAIT（关闭等待）状态，此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入 FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
        
        第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
        
        即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号 ack=u+1），服务端进入 LAST_ACK（最后确认）状态，等待客户端的确认。
        
        第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
        
        即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入 TIME_WAIT（时间等待）状态。此时 TCP 未释放掉，需要经过时间等待计时器设置的时间 2MSL 后，客户端才进入 CLOSED 状态。
        
        收到一个 FIN 只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入 TIME_WAIT 是正常的，服务端通常执行被动关闭，不会进入 TIME_WAIT 状态。
    - 相关问题
      - 为什么要三次握手？
        
        防止失效的连接请求报文段被服务端接收，从而产生错误。
        
        失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。
        
        若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入 ESTABLISHED 状态，而服务端在收到连接请求后就进入 ESTABLISHED 状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入 ESTABLISHED 状态，等待发送数据或主动发送数据。但此时的客户端早已进入 CLOSED 状态，服务端将会一直等待下去，这样浪费服务端连接资源。
      - 什么是半连接队列？
        
        服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
        
        当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
      - 为什么要四次挥手？
        
        试想一下，假如现在你是客户端你想断开跟 Server 的所有连接该怎么做？第一步，你自己先停止向 Server 端发送数据，并等待 Server 的回复。但事情还没有完，虽然你自身不往 Server 发送数据了，但是因为你们之前已经建立好平等的连接了，所以此时他也有主动权向你发送数据；故 Server 端还得终止主动向你发送数据，并等待你的确认。其实，说白了就是保证双方的一个合约的完整执行！
      - 为什么 TIME_WAIT 状态需要经过 2MSL（最大报文段生存时间）才能返回到 CLOSE 状态？
        
        为了保证 Server 能收到 Client 的确认应答。
        
        若 Client 发完确认应答后直接进入 CLOSED 状态，那么如果该应答丢失，Server 等待超时后就会重新发送连接释放请求，但此时 Client 已经关闭了，不会作出任何响应，因此 Server 永远无法正常关闭。
- 流量控制与拥塞控制
  - 流量控制
    - 接收端在接收到数据后，对其进行处理。如果发送端的发送速度太快，导致接收端的结束缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁反应，超时重传呀什么的。而 TCP 根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。
    - 在 TCP 协议的报头信息当中，有一个 16 位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送 ACK 报文时，将自己的即时窗口大小填入，并跟随 ACK 报文一起发送过去。而发送方根据 ACK 报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为 0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
    - 16 位的窗口大小最大能表示 65535 个字节（64K），但是 TCP 的窗口大小最大并不是 64K。在 TCP 首部中 40 个字节的选项中还包含了一个窗口扩大因子 M，实际的窗口大小就是 16 为窗口字段的值左移 M 位。每移一位，扩大一倍。
  - 拥塞控制
    - TCP 传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
    - TCP 引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到 ACK 应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
    - 拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。
    - 操作步骤
      - 慢开始：最开始发送方的拥塞窗口为 1，由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次，拥塞窗口 cwnd 加倍。当 cwnd 超过慢开始门限，则使用拥塞避免算法，避免 cwnd 增长过大。
      - 拥塞避免：每经过一个往返时间 RTT，cwnd 就增长1。另外在慢开始和拥塞避免的过程中，一旦发现网络拥塞，就把慢开始门限设为当前值的一半，并且重新设置 cwnd 为 1，重新慢启动。（乘法减小，加法增大）
      - 快重传：接收方每次收到一个失序的报文段后就立即发出重复确认，发送方只要连续收到三个重复确认就立即重传（尽早重传未被确认的报文段）。
      - 快恢复：当发送方连续收到了三个重复确认，就乘法减半（慢开始门限减半），将当前的拥塞窗口设置为慢开始门限，并且采用拥塞避免算法（连续收到了三个重复请求，说明当前网络可能没有拥塞）。
      - 采用慢开始和拥塞避免算法的时候
        
        一旦 cwnd > 慢开始门限，就采用拥塞避免算法，减慢增长速度
        
        一旦出现丢包的情况，就重新进行慢开始，减慢增长速度
      - 采用快恢复和快重传算法的时候
        
        一旦 cwnd > 慢开始门限，就采用拥塞避免算法，减慢增长速度
        
        一旦发送方连续收到了三个重复确认，就采用拥塞避免算法，减慢增长速度
  - 发送端实际可用的窗口：接收端通知窗口（流量控制中的发送窗口）和拥塞窗口中的较小者。
相关问题
- 滑动窗口的作用：
  - 流量控制
    - 接收端窗口大小，代表接收端缓冲区还有多少大小，从而控制发送端发送大小，达到流量控制的目的。
  - 拥塞控制
    - 拥塞控制也就是考虑当前的网络环境，动态调整窗口大小，没有发生拥塞情况，则窗口增大，拥塞了窗口减小，如此往复，最终应该接近与接收端的窗口大小。
  - 提高传输效率
    - 在确认应答机制中，对每一个发送的数据段，都要给一个 ACK 确认应答，收到 ACK 后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。而有了滑动窗口，通信双方就不用发送一个报文后，收到此报文的确认后再发送下一个报文，而是可以连续发送多个报文，只要别超过窗口大小限制。
      - 粘包
        
        发送端为了将多个发往接收端的包，更加高效的的发给接收端，于是采用了优化算法（Nagle算法），将多次间隔较小、数据量较小的数据，合并成一个数据量大的数据块，然后进行封包。
        
        产生原因
        
        发送方原因
        
        接收方原因
        
        TCP 接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP 将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果 TCP 接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。
        
        TCP 本来就是基于字节流而不是消息包的协议，按长度解析包就行。

UDP

UDP 是无连接的，即发送数据之前不需要建立连接，减少了开销和发送数据之前的时延。UDP 使用尽最大努力交付，即不保证可靠交付，主机不需要维持复杂的连接状态表。UDP 面向报文，发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
Quic
- Quic 全称 quick udp internet connection，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 Google 提出的使用 udp 进行多路并发传输的协议。
- Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：
  - 减少了 TCP 三次握手及 TLS 握手时间；
  - 改进的拥塞控制；
  - 避免队头阻塞的多路复用；
  - 连接迁移；
  - 前向冗余纠错。
- 需要 QUIC 的原因
  - 问题描述
    - 协议历史悠久导致中间设备僵化；
    - 依赖于操作系统的实现导致协议本身僵化；
    - 建立连接的握手延迟大；
    - 队头阻塞。

应用层协议

HTTP

HTTP（HyperText Transfer Protocol）: 超文本传输协议。是互联网上应用最广泛的一种网络协议。所有 www 文件都必须遵守的一个标准，是以 ASCII 码传输，建立在 TCP/IP 协议之上的应用层规范。简单点说就是一种固定的通讯规则。
HTTP 状态码
- 已定义范围分类
  
  1XX 100-101 信息提示
  
  2XX 200-206 成功
  
  3XX 300-305 重定向
  
  4XX 400-415 客户端错误
  
  5XX 500-505 服务器错误
- 常见状态码：
  - 200 OK。服务器成功处理了请求（这个是我们见到最多的）
  - 301/302 Moved Permanently（重定向）。请求的 URL 已移走。Response 中应该包含一个 Location URL, 说明资源现在所处的位置
  - 400 Bad Request（坏请求）。告诉客户端，它发送了一个错误的请求。
  - 404 Not Found。未找到资源
  - 500 Internal Server Error（内部服务器错误）。服务器遇到一个错误，使其无法为请求提供服务
生命周期
- HTTP 的生命周期通过 Request 来界定，也就是一个 Request 一个 Response，那么在 HTTP1.0 中，这次 HTTP 请求就结束了。
- 在 HTTP1.1 中进行了改进，使得有一个 keep-alive，也就是说，在一个 HTTP 连接中，可以发送多个 Request，接收多个 Response。
特点
- 被动性：只能由客户端发起请求
请求方式
- 分类
  - POST
    - 浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）
  - GET
    - 请求过程
      - 浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）
  - PUT
  - DELETE
- GET 和 POST 的区别
  - get 参数通过 url 传递，post 放在 request body 中。
  - get 请求在 url 中传递的参数是有长度限制的，而 post 没有。
  - get 比 post 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
  - get 请求只能进行 url 编码，而 post 支持多种编码方式。
  - get 请求会浏览器主动 cache。
  - get 请求参数会被完整保留在浏览历史记录里，而 post 中的参数不会被保留。
  - GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
  - GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。
发展历史
- HTTP/0.9 版本
  - 这是最早定稿的HTTP版本，这个版本中它的内容非常地简单。
    - 首先它只有一个命令 GET。对应到现在的 GET 请求和 POST 请求，这些叫做 HTTP 的命令或者方法。
    - 它没有 HEADER 等描述数据的信息。因为这个时候的请求非常简单，它需要达到的目的也非常简单，没有那么多数据格式。
    - 服务器发送完内容之后，就关闭 TCP 连接。这里需要注意一点，这里的 TCP 连接和 http 请求是不一样的。http 请求和 TCP 连接不是一个概念。一个 http 请求通过 TCP 连接发送，而一个 TCP 连接里面可以发送很多个 http 请求（HTTP/0.9 不能这么做，但是 HTTP/1.1 可以这么做，而且在 HTTP/2 这方面会更大程度地优化，来提高 HTTP 协议传输的效率以及服务器的性能），所以一个 TCP 连接对应的是多个 http 请求，一个 http 请求肯定是在某一个 TCP 连接里面进行发送的。
- HTTP/1.0 版本
  - 这个版本和 HTTP/1.1 差不多，在 HTTP/0.9 版本基础上进行了改进。
    - 增加了很多命令。比如：POST、PUT、HEADER 这些命令。
    - 增加了 status code 和 header 相关的内容。
      - status code 是用来描述服务器端处理某一个请求之后的状态的；
      - header 主要包含：请求和发送数据的描述以及对这部分数据进行操作的方法。
    - 增加了多字符集支持、多部分发送、权限、缓存等相关的内容。这些内容有利于更好地使用 http 请求去实现 WEB 服务。
- HTTP/1.1 版本
  - 这个版本是在 HTTP/1.0 的基础上增加了一些功能来优化网络连接的过程。
    - 在这个版本支持了持久连接。在 HTTP/1.0 版本里面，一个 http 请求要发送就要先在客户端和服务器端之间创建一个 TCP 连接，创建完这个 TCP 连接之后，等服务器端返回完数据之后，这个 TCP 连接就关闭了。
    - 增加了 pipeline。可以在同一个 TCP 连接里面发送多个 http 请求，就是上面说的那样。但是在 HTTP/1.1 里面，虽然是可以在同一个 TCP 连接里面发送多个 http 请求，但是服务器端对于进来的请求，是要按照顺序进行数据返回的。
      - 因此，如果前一个请求等待时间非常长，而后一个请求处理得比较快。这个时候后一个请求不能先发送，而是要等第一个请求数据全部发送完成之后，才能进行发送，即是串行的。等待的这部分时间就体现出了与并行传输性能之间的差距 【这个在HTTP/2里面得到了优化。】。
    - 增加了 HTTP 的头 host 和其他一些命令。其中比较重要的就是 host，有了 host 之后就可以在同一台服务器（物理服务器）上同时跑多个 web 服务。比如说一个 Node.js 的 web 服务，一个 Java 的 web 服务。
- HTTP/2 版本
  - 所有数据都是以二进制进行传输的。在 HTTP/1.1 里面大部分的数据传输是通过字符串，所以数据的分片方式是不太一样的。在 HTTP/2 里面所有的数据都是以帧进行传输的。
  - 多路复用。同一个连接里面发送多个请求时，服务器端不再需要按照顺序来返回处理后的数据了。而是可以在返回第一个请求里面数据的时候，同时返回第二个请求里面的数据。这样的并行传输能够更大限度地提高 web 应用的传输效率。
  - 新增头信息压缩以及推送等功能，提高了传输效率。HTTP/2 其实主要就是改善了 HTTP/1.1 里面造成性能低下的一些问题。
    - 头信息的压缩
      - 在 HTTP/1.1 里面每一次发送请求和返回请求，很多 http 头都是必须要进行完整的发送和返回的，但是这一部分头信息里面有很多的内容比如说：Headers 字段、Content-Type、accept 等字段是以字符串的形式保存的。
      - 所以占用较大的带宽量。所以 HTTP/2 里面对头信息进行了压缩，可以有效地减少带宽使用
    - 推送的功能
      - 指的是 HTTP/2 之前，只能由客户端发送数据，服务器端返回数据。客户端是主动方，服务器端永远是被动方。在 HTTP/2 里面有了”推送”的概念，也就是说服务器端可以主动向客户端发起一些数据传输。
      - 例子
        
        一个 web 页面加载时会要求一些 html、css、js 等文件，css 和 js文件是以链接的形式在 html 文本里面显示的，只有通过浏览器解析了 html 里面的内容之后，才能根据链接里面包含的 URL 地址去请求对应的 css 和 js 文件。
        
        在 HTTP/2 之前，这个传输过程会包含顺序问题，需要先请求到 html 的文件，通过浏览器运行解析这个 html 文件之后，才能去发送 css 的请求和 js 的请求。
        
        HTTP/2 中有了推送功能之后，在请求 html 的同时，服务器端可以主动把 html 里面所引用到的 css 和 js 文件推送到客户端，这样 html、css 和 js 的发送就是并行的而不是串行的，整体的传输效率和性能就提高了不少。
- HTTP/3
  - 之前协议的问题
    - 虽然 HTTP/2 解决了很多之前旧版本的问题，但是它还是存在一个巨大的问题，虽然这个问题并不是它本身造成的，而是底层支撑的 TCP 协议的问题。
      - 因为 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。
      - 因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。
      - 那么可能就会有人考虑到去修改 TCP 协议，其实这已经是一件不可能完成的任务了。因为 TCP 存在的时间实在太长，已经充斥在各种设备中，并且这个协议是由操作系统实现的，更新起来不大现实。
      - 基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，当然 HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。
  - HTTP3 核心新功能
    - QUIC
      - QUIC 是基于 UDP 实现的，UDP 协议虽然效率很高，但是并不是那么的可靠。QUIC 虽然基于 UDP，但是在原本的基础上新增了很多功能，比如多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能。
        
        多路复用
        
        虽然 HTTP/2 支持了多路复用，但是 TCP 协议终究是没有这个功能的。QUIC 原生就实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。
        
        并且 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。
        
        0-RTT
        
        通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了。
        
        纠错机制
        
        假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。
        
        当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。
        
        当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。

	已定义范围	分类
1XX	100-101	信息提示
2XX	200-206	成功
3XX	300-305	重定向
4XX	400-415	客户端错误
5XX	500-505	服务器错误

HTTPS

原理
- 非对称加密+对称加密
- 流程
  1. 某网站有用于非对称加密的公钥 A、私钥 A’。
  2. 浏览器向网站服务器请求，服务器把公钥 A 明文给传输浏览器。
  3. 浏览器随机生成一个用于对称加密的密钥 X，用公钥 A 加密后传给服务器。
  4. 服务器拿到后用私钥 A’ 解密得到密钥 X。
  5. 这样双方就都拥有密钥 X 了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。
- 相关问题
  - 如何证明浏览器收到的公钥一定是该网站的公钥？
    - 利用数字证书
  - 为什么不用两组公钥私钥非对称加密方案？
    - 流程
      1. 某网站服务器拥有公钥 A 与对应的私钥 A’；浏览器拥有公钥 B 与对应的私钥 B’。
      2. 浏览器把公钥 B 明文传输给服务器。
      3. 服务器把公钥 A 明文给传输浏览器。
      4. 之后浏览器向服务器传输的内容都用公钥 A 加密，服务器收到后用私钥 A’ 解密。由于只有服务器拥有私钥 A’，所以能保证这条数据的安全。
      5. 同理，服务器向浏览器传输的内容都用公钥 B 加密，浏览器收到后用私钥 B’ 解密。同上也可以保证这条数据的安全。
    - 原因
      - 很重要的原因是非对称加密算法非常耗时，而对称加密快很多
      - 会有中间人攻击
        
        中间人攻击
        
        流程
        
        某网站有用于非对称加密的公钥 A、私钥 A’。
        
        浏览器向网站服务器请求，服务器把公钥 A 明文给传输浏览器。
        
        中间人劫持到公钥 A，保存下来，把数据包中的公钥A替换成自己伪造的公钥 B（它当然也拥有公钥 B 对应的私钥 B’）。
        
        浏览器生成一个用于对称加密的密钥 X，用公钥 B（浏览器无法得知公钥被替换了）加密后传给服务器。
        
        中间人劫持后用私钥 B’ 解密得到密钥X，再用公钥 A 加密后传给服务器。
        
        服务器拿到后用私钥 A’ 解密得到密钥 X。
数字证书
- 网站在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。
- 数字签名
  - 数字签名的制作过程
    1. CA 机构拥有非对称加密的私钥和公钥
    2. CA 机构对证书明文数据 T 进行 hash
    3. 对 hash 后的值用私钥加密，得到数字签名 S
  - 浏览器验证过程
    1. 拿到证书，得到明文 T，签名 S
    2. 用 CA 机构的公钥对 S 解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到 S’
    3. 用证书里指明的 hash 算法对明文 T 进行 hash 得到 T’
    4. 显然通过以上步骤，T’ 应当等于 S‘，除非明文或签名被篡改。所以此时比较 S’ 是否等于 T’，等于则表明证书可信
  - 111
- 相关问题
  - 如何放防止数字证书被篡改？
    - 我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。
  - 为什么制作数字签名时需要 hash 一次？
    - 最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而 hash 后得到的是固定长度的信息（比如用 md5 算法 hash 后可以得到固定的 128 位的值），这样加解密就快很多。
  - 怎么证明 CA 机构的公钥是可信的？
    - 操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有 CA 机构的根证书，这样就可以拿到它对应的可信公钥了。
    - 实际上证书之间的认证也可以不止一层，可以 A 信任 B，B 信任 C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
    - 另外，不知你们是否遇到过网站访问不了、提示需安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。
  - 每次进行 HTTPS 请求时都必须在 SSL/TLS 层进行握手传输密钥吗？
    - 服务器会为每个浏览器（或客户端软件）维护一个 session ID，在 TLS 握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的 session ID 下，之后浏览器每次请求都会携带 session ID，服务器会根据 session ID 找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

WebSocket

特点
- 建立在 TCP 协议之上，服务器端的实现比较容易。
- 与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
- 数据格式比较轻量，性能开销小，通信高效。
- 可以发送文本，也可以发送二进制数据。
- 没有同源限制，客户端可以与任意服务器通信。
- 协议标识符是 ws（如果加密，则为 wss），服务器网址就是 URL。
对比技术
- ajax 轮询
  - 让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。
- long poll
  - 原理跟 ajax轮询差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回 Response 给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

请求过程

网页请求过程
1. 对网址进行 DNS 域名解析，得到对应的 IP 地址
  - DNS 域名解析采用的是递归查询的方式，过程是，先去找 DNS 缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的 web 浏览器
2. 根据这个 IP，找到对应的服务器，发起 TCP 的三次握手
3. 建立 TCP 连接后发起 HTTP 请求
4. 服务器响应 HTTP 请求，浏览器得到 HTML 代码
5. 关闭TCP连接
  - 一般情况下，一旦 Web 服务器向浏览器发送了请求的数据，它就要关闭 TCP 连接，但是如果浏览器或者服务器在其头信息加入了这行代码：Connection:keep-alive。TCP 连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。
6. 浏览器解析 HTML 代码，并请求 HTML 代码中的资源（如 js、css、图片等）（先得到 HTML 代码，才能去找这些资源）
7. 浏览器对页面进行渲染呈现给用户

DNS

网络编程

网络编程模型

Acceptor-Connector 模式
- 这种模式是面向连接的 TCP/IP 协议。
- 模式思想
  - 此模式只负责连接的建立，不管有多少连接上来，这个模式都能应对。
  - 至于连接建立之后如何通信，那是通信处理器的事情，与此模式不再有任何关系。
  - 资源的管理总是通过调用函数的返回值来做约定的处理。不用类型如果有特殊的资源管理需求，均可以覆盖父类的方法。
Asynchronous Completion Token 模式
- ACT 就是应对应用程序异步调用服务操作，并处理相应的服务完成事件。
- 例子
  - 比如，通常应用程序会有调用第三方服务的需求，一般是业务线程请求都到，需要第三方资源的时候，去同步的发起第三方请求，而为了提升应用性能，需要异步的方式发起请求，但异步请求的话，等数据到达之后，此时的我方应用程序的语境以及上下文信息已经发生了变化，你没办法去处理。
  - ACT 解决的就是这个问题，采用了一个 token 的方式记录异步发送前的信息，发送给接受方，接受方回复的时候再带上这个 token，此时就能恢复业务的调用场景。
Proactor 模式
- Proactor 模型运用于异步 I/O 操作。
Reactor 模式
- Reactor 模型用于同步 I/O。Reactor 模式是一种典型的事件驱动的编程模型。
- Reactor 模型中定义的三种角色：
  - Reactor
    - 负责监听和分配事件，将 I/O 事件分派给对应的 Handler。新的事件包含连接建立就绪、读就绪、写就绪等。
  - Acceptor
    - 处理客户端新连接，并分派请求到处理器链中。
  - Handler
    - 将自身与事件绑定，执行非阻塞读/写任务，完成 channel 的读入，完成处理业务逻辑后，负责将结果写出 channel。可用资源池来管理。
- 流程
  - Reactor 处理请求的流程：
    - 读取操作：
      1. 应用程序注册读就绪事件和相关联的事件处理器
      2. 事件分离器等待事件的发生
      3. 当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器

网络攻击

常见攻击
入侵检测
- 通过对行为、安全日志或审计数据或其它网络上可以获得的信息进行操作，检测到对系统的闯入或闯入的企图
- 分类
  - 基于主机的入侵检测系统
    - 在主机上装一个 Agent，然后通过 Agent 监视系统的状态和各种进程
  - 基于网络的入侵检测系统
    - 通过被动地监听网络上传输的原始流量，对获取的网络数据进行处理，从中提取有用的信息，再通过与已知攻击特征相匹配或与正常网络行为原型相比较来识别攻击事件。此类检测系统不依赖操作系统作为检测资源，可应用于不同的操作系统平台；配置简单，不需要任何特殊的审计和登录机制；可检测协议攻击、特定环境的攻击等多种攻击。但它只能监视经过本网段的活动，无法得到主机系统的实时状态，精确度较差
  - 分布式 IDS
- 按引擎检测机制分类
  - 基于签名检测的 IDS
    - 根据已知的签名进行检测，这种方法能有效识别签名库中已有的攻击，但无法识别未知攻击和已知攻击的变种。
  - 基于异常行为检测的 IDS
    - 通过学习网络流量行为来对流量进行分类，可以检测未知的攻击。
    - 再分类
      - 基于机器学习的入侵检测技术
        
        数理统计（Statistical）：通过检查用户或系统的正常行为和异常行为来创建统计模型，统计模型可以用来识别新的攻击。常用的统计方法有主成分分析、卡方分布、高斯混合分布。
        
        支持向量机（Support Vector Machine，SVM）：支持向量机是一种在数据样本有限的情况下检测入侵事件的有效方法。向量机的目标是以最合适的方式用一个特征向量来区分两种类型数据。它们有很多应用领域，如人物识别、声音识别等，是机器学习中的经典模型。
        
        数据挖掘（Data Mining）：数据挖掘是从采集的海量数据中提取大量的信息，通过分析用户与数据之间的关联关系来提取关键规则，是用户行为分析的常用方法。
        
        基于规则集（Rule-Based）：由安全研究人员分析网络中的攻击流量，提取关键规则，从而在这基础上降低数据维度后再对入侵行为进行检测。该方法在一定程度上可以减少检测计算量，提高检测效率。
        
        人工神经网络（Artificial Neural Network，ANN）：人工神经网络是一种智能的信息处理模型，它模拟人类大脑对信息进行加工、存储和处理。神经网络通过学习获得知识，并将学到的知识存储在连接点的权重中。该模型具有学习性和自适应性，并且可以识别未知入侵。
      - 基于深度学习的入侵检测技术
- 工具
  - IDS-snort
- 数据集
  - KDD Cup99
  - NSL-KDD
  - UNSW-NB15
  - CIC-IDS 2017
态势感知
- 网络安全态势感知系统通常是集合了防病毒软件、防火墙、入侵监测系统、安全审计系统等多个数据信息系统，将这些系统整合起来，对目前的整个网络情况进行评估，以及预测未来的变化趋势。
- 网络安全态势感知系统主要分为四个部分
  - 数据采集
    - 就是对当前整个网络状态进行数据提取，包括网站安全日志、漏洞数据库、恶意代码数据库等多个数据进行统筹整理，一般各个厂家都会有自己对应的信息数据库。
  - 特征提取
    - 通过第一步收集了大量的数据之后，从这些数据中提取有用的数据进行相应的预处理工作，为后面接下来的工作做好数据准备。数据采集和特征提取都是整个网络安全态势感知系统的最底层，数据准备工作。
  - 态势评估
    - 态势评估主要是通过对关联事件进行数据融合处理，从时间、空间、协议等多个方面进行关联识别。简单来说，就是结合数据信息、对当前的时间进行危险评估、判断危险等级。
  - 安全预警
    - 在通过了上面的几个步骤提取了大量的网络状态数据之后，系统就会根据指定的标准对目前的网络状态以及未来的网络状态进行评估和预测，进而给出相应的分析报告和安全状态预警处理。

其他

路由器和交换机
- 路由器
  - DHCP
    - DHCP 是动态主机设置协议的简称
    - 主要有两个用途
      - 用于内部网或网络服务供应商自动分配IP地址；
      - 给用户用于内部网管理员作为对所有计算机作中央管理的手段。
- 区别
  - 工作层次不同
    - 交换机主要工作在数据链路层（第二层）
    - 路由器工作在网络层（第三层）
  - 转发依据不同
    - 交换机转发所依据的对象时：MAC 地址。（物理地址）
    - 路由转发所依据的对象是：IP 地址。（网络地址）
  - 主要功能不同
    - 交换机主要用于组建局域网。
    - 路由主要功能是将由交换机组好的局域网相互连接起来，或者接入Interne。
    - 交换机能做的，路由都能做。
    - 交换机不能分割广播域，路由可以。
    - 路由还可以提供防火墙的功能。
    - 路由配置比交换机复杂。

网闸和防火墙

网闸
- 网闸（GAP）全称安全隔离网闸。安全隔离网闸是一种由带有多种控制功能专用硬件在电路上切断网络之间的链路层连接，并能够在网络间进行安全适度的应用数据交换的网络安全设备。
- 基本原理
  - 切断网络之间的通用协议连接；将数据包进行分解或重组为静态数据；对静态数据进行安全审查，包括网络协议检查和代码扫描等；确认后的安全数据流入内部单元；内部用户通过严格的身份认证机制获取所需数据。
- 安全隔离与信息交换系统 SGAP 一般由三部分构成
  - 内网处理单元
  - 外网处理单元
  - 专用隔离硬件交换单元
防火墙
- 防火墙是由一些软、硬件组合而成的网络访问控制器，它根据一定的安全规则来控制流过防火墙的网络包，如禁止或转发、能够屏蔽被保护网络内部的信息、拓扑结构和运行状况，从而起到网络安全屏障的作用。
- 防火墙安全策略
  - 白名单策略：只允许符合安全规则的包通过防火墙
  - 黑名单策略：禁止与安全规则相冲突的包通过防火墙
- 主要功能
  - 过滤非安全网络访问
  - 限制网络访问
  - 网络访问审计
  - 网络带宽控制
  - 协同防御
- 防火墙类型与实现技术
  - 包过滤
    - 是在 IP 层实现的防火墙技术，根据包的源 IP 地址、目的 IP 地址、源端口、目的端口及包传递方向等包头信息判断是否允许包通过，对用户透明。基于包过滤技术的防火墙简称为包过滤型防火墙（Packet Filter）
    - 优点：低负载、高通过率、对用户透明
    - 缺点：不能在用户级别过滤，不能识别地址伪造，容易被绕过
  - 状态检查技术
    - 利用 TCP 会话和 UDP “伪”会话的状态信息进行网络访问控制。建立并维护一张会话表，当有符合已定义安全策略的 TCP 连接或 UDP 流时，防火墙会创建会话项，依据状态表项检查，与会话相关联的包才能通过
    - 主要步骤
      1. 接收到的数据包
      2. 检查数据包有效性，若无效，则丢弃并审计
      3. 查找会话表，若找到，进一步检查数据包的序列号和会话状态，如有效，则进行地址转换和路由，转发该数据包；否则，丢弃并审计
      4. 当会话表中没有新到的数据包信息时，查找策略表，若符合，则增加会话条目，进行地址转换和路由，转发数据包了否则，丢弃并审计
  - 应用服务代理
    - 代替受保护网络的主机向外部网发送服务请求，并将外部服务请求响应的结果返回给受保护网络的主机。由代理服务程序和身份验证服务程序构成，能够提供应用级别网络安全访问控制，如 FTP 代理、Telnet 代理、HTTP 代理
    - 优点
      - 不允许外部主机直接访问内部主机
      - 支持多种用户认证方案
      - 可以分析数据包内部的应用命令
      - 可以提供详细的审计记录
    - 缺点
      - 速度比包过滤慢
      - 对用户不透明
      - 与特定的应用协议相关联
  - 网络地址转换技术
    - NAT（Network Address Translation）：本质：解决 IPv4 公开地址不足问题。安全方面：能透明地对所有内部地址做转换，使外部网络无法了解内部网络的内部结构，从而提高内部网络的安全性。
    - 实现方式
      - 静态 NAT（static NAT）：内部网络中的每个主机都被永久映射成外部网络中的某个合法的地址
      - NAT 池（pooled NAT）：在外部网络中配置合法的地址集，采用动态分配的方法映射到内部网络
      - 端口 NAT（PAT）：内部地址映射到外部网络的一个 IP 地址的不同端口上
  - WAF
    - 用于保护 Web 服务器和 Web 应用的网络安全机制
    - 常见功能
      - 允许/禁止 HTTP 请求类型
      - HTTP 协议头各个字段长度限制
      - 后缀名过滤
      - URL 内容关键字过滤
      - Web 服务器返回内容过滤
    - 抵御典型攻击
      - SQL 注入
      - XSS 跨站脚本攻击
      - Web 应用扫描
      - Webshell
      - Cookie 注入攻击
      - CSRF 攻击
    - 开源框架
      - ModSecurity
      - WebKnight
      - Shadow Daemon
  - 数据库防火墙技术
    - 一种用于保护数据库服务器的网络安全机制
    - 技术原理
      - 协议深度分析：“源地址、目标地址、源端口、目标端口、SQL 语句”
      - 虚拟补丁：创建安全屏障层，监控所有数据库活动
  - 工控防火墙技术
    - 用于保护工业设备及系统的网络安全机制
    - 技术原理
      - 工控协议深度分析（Modbus TCP、IEC 61850、OPC、Ethernet/IP、DNP3）
  - 下一代防火墙技术（NGFW）
    - 应用识别和管控。不依赖端口，通过数据包深度内容分析，实现应用层协议与应用的识别和控制。
    - 入侵防护（IPS）。
    - 数据防泄漏。对传输的文件和内容进行识别和过滤
    - 恶意代码防护。基于信誉的恶意检测技术。
    - URL 分类与过滤。构建 URL 分类库
    - 带宽管理与 QoS 优化。
    - 加密通信分析。对 SSL、SSH 等加密的网络流量进行监控分析

区别

功能项	防火墙	安全隔离网闸
产品定位	在保障互联互通的前提下，尽可能保障安全。	在保证高度安全的前提下，尽可能实现互联互通。
设计思想	网络访问控制设备。防火墙部署于网络边界，在保证双方网络访问连接的同时，根据策略对数据报文进行访问控制，并在不影响设备性能的前提下进行内容过滤。	网络隔离交换设备。模拟人工拷盘实现数据信息在两个网络之间交换。对于网络间通过网闸实现数据同步的应用，网闸主动监控并读取所隔离的两个网络中的服务器数据从而实现数据同步，而非服务器主动发起连接请求；对于网络间的客户端和服务器之间通过网闸访问控制的应用，网闸的一个主机系统中断访问连接，另一主机系统重新建立连接，两主机系统中在应用层进行数据报文重组，重在进行数据内容的检查。
硬件结构设计	防火墙为单主机结构，报文在同一个主机系统上经过安全检测后，根据策略转发。	安全隔离网闸基于“2+1”的体系结构，即由两个主机系统和一个隔离交换硬件组成，隔离交换硬件为专有硬件，不受主机系统控制。数据信息流经网闸时是串行流经三个系统的。
操作系统设计	防火墙一般采用单一的专用操作系统。	安全隔离网闸的两个主机系统各自有专用操作系统，相互独立。
协议处理程度	不同类型的防火墙，可能分别或综合采用分组包过滤、状态包过滤、NAT、应用层内容检查等安全技术，工作在OSI协议栈的第三至七层，通过匹配安全策略规则，依据IP头、TCP头信息、应用层明文信息，对进出防火墙的会话进行过滤。	所有到达安全隔离网闸外网的会话都被中断原有的TCP/IP连接，隔离设备将所有的协议剥离，将原始的数据写入存储介质。根据不同的应用，可能有必要对数据进行完整性和安全性检查，如防病毒和恶意代码等。对所有数据在应用层进行协议还原的基础上，以专有协议格式进行数据摆渡，综合了访问控制、内容过滤、病毒查杀等技术，具备全面的安全防护功能。
安全机制	采用包过滤、代理服务等安全机制。	在GAP技术的基础上，综合了访问控制、内容过滤、病毒查杀等技术，具有全面的安全防护功能。
抵御基于操作系统漏洞攻击行为	防火墙通过防止对内扫描等设置，可以部分防止黑客发现主机的操作系统漏洞。但无法阻止黑客通过防火墙允许的策略利用漏洞进行攻击。	安全隔离网闸的双主机之间是物理阻断的，无连接的，因此，黑客不可能扫描内部网络的所有主机的操作系统漏洞，无法攻击内部，包括安全隔离网闸的内部主机系统。
抵御基于TCP/IP漏洞的攻击	防火墙需要制定严格的访问控制策略对连接进行检查以抵御TCP/IP漏洞攻击，只能对大部分已知TCP/IP攻击实施阻断。	由于安全隔离网闸的主机系统把TCP/IP协议头全部剥离，以原始数据方式在两主机系统间进行“摆渡”，网闸的接受请求的主机系统与请求主机之间建立会话，因此，对于目前所有的如源地址欺骗、伪造TCP序列号、SYN攻击等TCP/IP漏洞攻击是完全阻断的。
抵御木马将数据外泄	防火墙部署时，一般对于内部网络向外部的访问控制是全部开放的，因此内部主机上的木马会很容易将数据外泄。并且黑客也容易通过木马主动建立的对外连接实现对内主机的远程控制。	安全隔离网闸对于每个应用都是在应用层进行处理，并且策略需按照应用逐个下达，同时对于目的地址也要唯一性指定，因此内部主机上的木马是无法实现将数据外泄的。并且木马主动发起的对外连接也将直接被隔离设备切断。
抵御基于文件的病毒传播	防火墙可以根据应用层访问控制策略对经过防火墙的文件进行检查，或根据对文件类型的控制，只允许低级文件格式，如无病毒的文本格式内容穿过防火墙。等方式来抵御病毒传播。	安全隔离网闸在理论上是完全可以防止基于文件的攻击，如病毒等。病毒一般依附在高级文件格式上，低级文件格式则不会有病毒，因此进行文件“摆渡”的时候，可以限制文件的类型，如只有文本文件才可以通过“摆渡”，这样就不会有病毒。另外一种方式，是剥离重组方式。剥离高级格式，就消除了病毒的载体，重组后的文件，不会再有病毒。这种方式会导致效率的下降，一些潜在的危险的格式可能会被禁止。
抵御DoS/DDoS攻击	防火墙通过SYN代理或SYN网关等技术，可以较好的抵御现有的各种DoS攻击类型。但对于大规模DDoS攻击方式，还没有有效的防护手段。	安全隔离网闸自身特有的无连接特性，能够很好的防止DoS或DDoS攻击穿过隔离设备攻击服务器。但也不能抵御针对安全隔离设备本身的DDoS攻击。
管理安全性	通过网络接口远程管理。但如攻击者获得了管理权限，可以通过远程调整防火墙的安全策略，从而达到攻击目的。	内外网主机系统分别有独立于网络接口的专用管理接口，同时对于运行的安全策略需要在两个系统分别下达，并通过统一的任务号进行对应。以此达到高安全。
可管理性	管理配置有一定复杂性。	个人认为管理配置不比防火墙简单。
遭攻击后果	被攻破的防火墙只是个简单的路由器，将危及内网安全。	即使系统的外网处理单元瘫痪，网络攻击也无法触及内网处理单元。
与其它安全设备联动性	目前防火墙基本都可以与IDS设备联动。	可结合防火墙、IDS、VPN等安全设备运行，形成综合网络安全防护平台