部分来源 https://github.com/LyleMi/Learn-Web-Hacking

计算机网络协议

1.1 网络基础

1.1.1 计算机通信网的组成

计算机网络由通信子网和资源子网组成。其中通信子网负责数据的无差错和有序传递，其处理功能包括差错控制、流量控制、路由选择、网络互连等。

其中资源子网是计算机通信的本地系统环境，包括主机、终端和应用程序等， 资源子网的主要功能是用户资源配置、数据的处理和管理、软件和硬件共享以及负载 均衡等。

总的来说，计算机通信网就是一个由通信子网承载的、传输和共享资源子网的各类信息的系统。

1.1.2 通信协议

为了完成计算机之间有序的信息交换，提出了通信协议的概念，其定义是相互通信的双方（或多方）对如何进行信息交换所必须遵守的一整套规则。

协议涉及到三个要素，分别为：

• 语法：语法是用户数据与控制信息的结构与格式，以及数据出现顺序的意义
• 语义：用于解释比特流的每一部分的意义
• 时序：事件实现顺序的详细说明

1.1.3 OSI七层模型

OSI（Open System Interconnection）共分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层七层，其具体的功能如下。

1.1.3.1 物理层

• 提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性

• 通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理

• 从数据链路层接收帧，将比特流转换成底层物理介质上的信号

1.1.3.2 数据链路层

• 在物理链路的两端之间传输数据

• 在网络层实体间提供数据传输功能和控制

• 提供数据的流量控制

• 检测和纠正物理链路产生的差错

• 格式化的消息称为帧

1.1.3.3 网络层

• 负责端到端的数据的路由或交换，为透明地传输数据建立连接

• 寻址并解决与数据在异构网络间传输相关的所有问题

• 使用上面的传输层和下面的数据链路层的功能

• 格式化的消息称为分组

1.1.3.4 传输层

• 提供无差错的数据传输

• 接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地

• 在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

1.1.3.5 会话层

• 提供节点之间通信过程的协调

• 负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接

• 使用上面的表示层和下面的传输层的功能

1.1.3.6 表示层

• 提供数据格式、变换和编码转换

• 涉及正在传输数据的语法和语义

• 将消息以合适电子传输的格式编码

• 执行该层的数据压缩和加密

• 从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

1.1.3.7 应用层

• 包括各种协议，它们定义了具体的面向用户的应用：如电子邮件、文件传输等

1.1.3.8 总结

低三层模型属于通信子网，涉及为用户间提供透明连接，操作主要以每条链路（ hop-by-hop）为基础，在节点间的各条数据链路上进行通信。由网络层来控制各条链路上的通信，但要依赖于其他节点的协调操作。

高三层属于资源子网，主要涉及保证信息以正确可理解形式传送。

传输层是高三层和低三层之间的接口，它是第一个端到端的层次，保证透明的端到端连接，满足用户的服务质量（QoS）要求，并向高三层提供合适的信息形式。

1.2 UDP协议

UDP是定义用来在互连网络环境中提供数据报交换的计算机通信的协议。此协议默认是IP下层协议。此协议提供了向另一用户程序发送信息的最简便的协议机制，不需要连接确认和保护复制，所以在软件实现上比较简单，需要的内存空间比起TCP相对也小。

1.2.1 主要特点

协议开销小、效率高。
UDP是无连接的，即发送数据之前不需要建立连接。
UDP使用尽最大努力交付，即不保证可靠交付。
UDP没有拥塞控制。
UDP支持一对一、一对多、多对一和多对多交互通信。
UDP的首部开销小，只有8个字节。

1.2.2 UDP数据格式与包结构

UDP包头由4个域组成，其中每个域各占用2个字节。

• （1）源端口号（16位）：UDP数据包的发送方使用的端口号。
• （2）目标端口号（16位）：UDP数据包的接收方使用的端口号。UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和rap协议正是采用这一机制，实现对同一时刻内多项应用同时发送和接收数据的支持。
• （3）数据包长度（16位）。数据包的长度是指包括包头和数据部分在内的总的字节数。理论上，包含包头在内的数据包的最大长度为65535字节。不过，一些实际应用往往会限制数据包的大小，有时会降低到8192字节。
• （4）校验值（16位）。UDP协议使用包头中的校验值来保证数据的安全。

1.3 TCP协议

1.3.1 简介

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由RFC 793定义。

1.3.2 TCP包结构

• 源端口号（ 16 位）：它（连同源主机 IP 地址）标识源主机的一个应用进程。

• 目的端口号（ 16 位）：它（连同目的主机 IP 地址）标识目的主机的一个应用进程。这两个值加上 IP 报头中的源主机 IP 地址和目的主机 IP 地址唯一确定一个 TCP 连接。

• 顺序号（ 32 位）：用来标识从 TCP 源端向 TCP 目的端发送的数据字节流，它表示在这个报文段中的第一个数据字节的顺序号。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用顺序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 2 32 － 1 后又从 0 开始。当建立一个新的连接时， SYN 标志变 1 ，顺序号字段包含由这个主机选择的该连接的初始顺序号 ISN（ Initial Sequence Number ）。

• 确认号（ 32 位）：包含发送确认的一端所期望收到的下一个顺序号。因此，确认序号应当是上次已成功收到数据字节顺序号加 1。只有 ACK 标志为 1 时确认序号字段才有效。 TCP 为应用层提供全双工服务，这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据顺序号。

• TCP 报头长度（ 4 位）：给出报头中 32bit 字的数目，它实际上指明数据从哪里开始。需要这个值是因为任选字段的长度是可变的。这个字段占 4bit ，因此 TCP 最多有 60 字节的首部。然而，没有任选字段，正常的长度是 20 字节。

• 保留位（ 6 位）：保留给将来使用，目前必须置为 0 。

• 控制位（ control flags ， 6 位）：在 TCP 报头中有 6 个标志比特，它们中的多个可同时被设置为 1 。依次为：

  • URG：为 1 表示紧急指针有效，为 0 则忽略紧急指针值。
  • ACK：为 1 表示确认号有效，为 0 表示报文中不包含确认信息，忽略确认号字段。
  • PSH：为 1 表示是带有 PUSH 标志的数据，指示接收方应该尽快将这个报文段交给应用层而不用等待缓冲区装满。
  • RST：用于复位由于主机崩溃或其他原因而出现错误的连接。它还可以用于拒绝非法的报文段和拒绝连接请求。一般情况下，如果收到一个 RST 为 1 的报文，那么一定发生了某些问题。
  • SYN：同步序号，为 1 表示连接请求，用于建立连接和使顺序号同步（ synchronize ）。
  • FIN：用于释放连接，为 1 表示发送方已经没有数据发送了，即关闭本方数据流。

• 窗口大小（ 16 位）：数据字节数，表示从确认号开始，本报文的源方可以接收的字节数，即源方接收窗口大小。窗口大小是一个16bit 字段，因而窗口大小最大为 65535字节。

• 校验和（ 16 位）：此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。

• 紧急指针（ 16 位）：只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

• 选项：最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size) 。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN 标志的那个段）中指明这个选项，它指明本端所能接收的最大长度的报文段。选项长度不一定是 32 位字的整数倍，所以要加填充位，使得报头长度成为整字数。

• 数据： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

1.3.3 三次握手

三次握手（Three-Way Handshake）是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

第一次握手客户端将标志位 SYN 置为1，随机产生一个值 seq=s ，并将该数据包发送给服务端，客户端进入 SYN_SENT 状态，等待服务端确认。

第二次握手服务端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务端将标志位 SYN 和 ACK 都置为1，ack=s+1，随机产生一个值 seq=k ，并将该数据包发送给客户端以确认连接请求，服务端进入 SYN_RCVD 状态。

第三次握手客户端收到确认后，检查ack值是否为s+1，ACK标志位是否为1，如果正确则将标志位 ACK 置为1，ack=k+1，并将该数据包发送给服务端，服务端检查ack值是否为k+1，ACK标志位是否为1，如果正确则连接建立成功，客户端和服务端进入 ESTABLISHED 状态，完成三次握手。

1.3.4 四次挥手

四次挥手（Four-Way Wavehand）指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

第一次挥手客户端发送一个 FIN ，用来关闭客户端到服务端的数据传送，客户端进入 FIN_WAIT_1 状态。

第二次挥手服务端收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到序号+1，服务端进入 CLOSE_WAIT 状态。

第三次挥手服务端发送一个 FIN ，用来关闭服务端到客户端的数据传送，服务端进入 LAST_ACK 状态。

第四次挥手客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务端，确认序号为收到序号+1，服务端进入 CLOSED 状态，完成四次挥手。

1.3.5 拥塞控制

拥塞是指网络中报文数量过多，使得服务端来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿即出现死锁现象。

TCP采用拥塞控制算法来减少或者避免拥塞现象的发生，TCP的拥塞算法有过多种实现，包括Tahoe、Reno、NewReno、Vegas、Hybla、BIC 、CUBIC、SACK、Westwood、PRR、BBR等。

1.3.6 参考链接

UDP协议分析

TCP协议分析

RFC 793 TRANSMISSION CONTROL PROTOCOL
RFC 2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
RFC 3390 Increasing TCP’s Initial Window
RFC 5681 TCP Congestion Control
TCP congestion control wik

1.4 DHCP协议

1.4.1 简介

动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) 是一个用于局域网的网络协议，位于OSI模型的应用层，使用UDP协议工作，主要用于自动分配IP地址给用户。

DHCP服务器端使用67/udp，客户端使用68/udp。DHCP运行分为四个基本过程，分别为请求IP租约、提供IP租约、选择IP租约和确认IP租约。客户端在获得了一个IP地址以后，就可以发送一个ARP请求来避免由于DHCP服务器地址池重叠而引发的IP冲突。

优点：

减少错误
减少手工配置IP地址导致的错误，如已分配的IP地址再次分配给另一设备引起的地址冲突
减少网络管理
TCP/IP配置是集中化和自动完成的，不需手工配置，集中定义全局和特定子网的TCP/IP配置
大部分路由器能转发DHCP配置请求，减少了在每个子网设置DHCP服务器的必要
客户机配置的地址变化必须经常更新，DHCP能高效而自动地进行配置

1.4.2 DHCP包结构

DHCP一共有8种报文，分别为DHCP Discover、DHCP Offer、DHCP Request、DHCP ACK、DHCP NAK、DHCP Release、DHCP Decline、DHCP Inform。各种类型报文的基本功能如下：

• DHCP Discover
  DHCP客户端在请求IP地址时并不知道DHCP服务器的位置，因此DHCP客户端会在本地网络内以广播方式发送Discover请求报文，以发现网络中的DHCP服务器。所有收到Discover报文的DHCP服务器都会发送应答报文，DHCP客户端据此可以知道网络中存在的DHCP服务器的位置。

• DHCP Offer
  DHCP服务器收到Discover报文后，就会在所配置的地址池中查找一个合适的IP地址，加上相应的租约期限和其他配置信息（如网关、DNS服务器等），构造一个Offer报文，发送给DHCP客户端，告知用户本服务器可以为其提供IP地址。但这个报文只是告诉DHCP客户端可以提供IP地址，最终还需要客户端通过ARP来检测该IP地址是否重复。

• DHCP Request
  DHCP客户端可能会收到很多Offer请求报文，所以必须在这些应答中选择一个。通常是选择第一个Offer应答报文的服务器作为自己的目标服务器，并向该服务器发送一个广播的Request请求报文，通告选择的服务器，希望获得所分配的IP地址。另外，DHCP客户端在成功获取IP地址后，在地址使用租期过去1/2时，会向DHCP服务器发送单播Request请求报文请求续延租约，如果没有收到ACK报文，在租期过去3/4时，会再次发送广播的Request请求报文以请求续延租约。

• DHCP ACK
  DHCP服务器收到Request请求报文后，根据Request报文中携带的用户MAC来查找有没有相应的租约记录，如果有则发送ACK应答报文，通知用户可以使用分配的IP地址。

• DHCP NAK
  如果DHCP服务器收到Request请求报文后，没有发现有相应的租约记录或者由于某些原因无法正常分配IP地址，则向DHCP客户端发送NAK应答报文，通知用户无法分配合适的IP地址。
  DHCP Release
  当DHCP客户端不再需要使用分配IP地址时，就会主动向DHCP服务器发送RELEASE请求报文，告知服务器用户不再需要分配IP地址，请求DHCP服务器释放对应的IP地址。

• DHCP Decline
  DHCP客户端收到DHCP服务器ACK应答报文后，通过地址冲突检测发现服务器分配的地址冲突或者由于其他原因导致不能使用，则会向DHCP服务器发送Decline请求报文，通知服务器所分配的IP地址不可用，以期获得新的IP地址。

• DHCP Inform
  DHCP客户端如果需要从DHCP服务器端获取更为详细的配置信息，则向DHCP服务器发送Inform请求报文；DHCP服务器在收到该报文后，将根据租约进行查找到相应的配置信息后，向DHCP客户端发送ACK应答报文。目前基本上不用了。

DHCP服务的8种报文的格式是相同的，不同类型的报文只是报文中的某些字段取值不同。DHCP报文格式基于BOOTP的报文格式。下面是各字段的说明。
OP：报文的操作类型。分为请求报文和响应报文。1：请求报文，2：应答报文。即client送给server的封包，设为1，反之为2。
请求报文：DHCP Discover、DHCP Request、DHCP Release、DHCP Inform和DHCP Decline。
应答报文：DHCP Offer、DHCP ACK和DHCP NAK。
Htype：DHCP客户端的MAC地址类型。MAC地址类型其实是指明网络类型，Htype值为1时表示为最常见的以太网MAC地址类型。
Hlen：DHCP客户端的MAC地址长度。以太网MAC地址长度为6个字节，即以太网时Hlen值为6。
Hops：DHCP报文经过的DHCP中继的数目，默认为0。DHCP请求报文每经过一个DHCP中继，该字段就会增加1。没有经过DHCP中继时值为0。(若数据包需经过router传送，每站加1，若在同一网内，为0。)
Xid：客户端通过DHCP Discover报文发起一次IP地址请求时选择的随机数，相当于请求标识。用来标识一次IP地址请求过程。在一次请求中所有报文的Xid都是一样的。
Secs：DHCP客户端从获取到IP地址或者续约过程开始到现在所消耗的时间，以秒为单位。在没有获得IP地址前该字段始终为0。(DHCP客户端开始DHCP请求后所经过的时间。目前尚未使用，固定为0。)
Flags：标志位，只使用第0比特位，是广播应答标识位，用来标识DHCP服务器应答报文是采用单播还是广播发送，0表示采用单播发送方式，1表示采用广播发送方式。其余位尚未使用。(即从0-15bits，最左1bit为1时表示server将以广播方式传送封包给client。)
【注意】在客户端正式分配了IP地址之前的第一次IP地址请求过程中，所有DHCP报文都是以广播方式发送的，包括客户端发送的DHCP Discover和DHCP Request报文，以及DHCP服务器发送的DHCP Offer、DHCP ACK和DHCP NAK报文。当然，如果是由DHCP中继器转的报文，则都是以单播方式发送的。另外，IP地址续约、IP地址释放的相关报文都是采用单播方式进行发送的。
Ciaddr：DHCP客户端的IP地址。仅在DHCP服务器发送的ACK报文中显示，在其他报文中均显示0，因为在得到DHCP服务器确认前，DHCP客户端是还没有分配到IP地址的。只有客户端是Bound、Renew、Rebinding状态，并且能响应ARP请求时，才能被填充。
Yiaddr：DHCP服务器分配给客户端的IP地址。仅在DHCP服务器发送的Offer和ACK报文中显示，其他报文中显示为0。
Siaddr：下一个为DHCP客户端分配IP地址等信息的DHCP服务器IP地址。仅在DHCP Offer、DHCP ACK报文中显示，其他报文中显示为0。(用于bootstrap过程中的IP地址)
Giaddr：DHCP客户端发出请求报文后经过的第一个DHCP中继的IP地址。如果没有经过DHCP中继，则显示为0。(转发代理（网关）IP地址)
Chaddr：DHCP客户端的MAC地址。在每个报文中都会显示对应DHCP客户端的MAC地址。
Sname：为DHCP客户端分配IP地址的DHCP服务器名称（DNS域名格式）。在Offer和ACK报文中显示发送报文的DHCP服务器名称，其他报文显示为0。
File：DHCP服务器为DHCP客户端指定的启动配置文件名称及路径信息。仅在DHCP Offer报文中显示，其他报文中显示为空。
Options：可选项字段，长度可变，格式为"代码+长度+数据"。

列出部分可选的选项：
代码1
长度(字节)：4
说明：子网掩码
代码3
长度：长度可变，必须是4个字节的倍数。
说明：默认网关（可以是一个路由器IP地址列表）
代码6
长度：长度可变，必须是4个字节的整数倍。
说明DNS服务器（可以是一个DNS服务器IP地址列表）
代码15
长度：长度可变
说明：域名称（主DNS服务器名称）
代码44
长度：长度可变，必须是4个字节的整数倍。
说明：WINS服务器（可以是一个WINS服务器IP列表）
代码51
长度：4
说明：有效租约期（以秒为单位）
代码53
长度：1
说明：报文类型
1: DHCP Discover
2: DHCP Offer
3: DHCP Request
4: DHCP Decline
5: DHCP ACK
6: DHCP NAK
7: DHCP Release
8: DHCP Inform
代码58
长度：4
说明：续约时间

包结构：

1.4.3 参考

DHCP Wiki

DHCP协议分析

1.5 路由算法

1.5.1 简介

路由算法是用于找到一条从源路由器到目的路由器的最佳路径的算法。存在着多种路由算法，每种算法对网络和路由器资源的影响都不同；由于路由算法使用多种度量标准 (metric)，所以不同路由算法的最佳路径选择也有所不同。

1.5.2 路由选择算法的功能

源/宿对之间的路径选择，以及选定路由之后将报文传送到它们的目的地。

路由选择算法的要求：

• 正确性：确保分组从源节点传送到目的节点
• 简单性：实现方便，软硬件开销小
• 自适应性：也称健壮性，算法能够适应业务量和网络拓扑的变化
• 稳定性：能长时间无故障运行
• 公平性：每个节点都有机会传送信息
• 最优性：尽量选取好的路由

1.5.3 自治系统 AS (Autonomous System)

经典定义：

• 由一个组织管理的一整套路由器和网络。
• 使用一种AS 内部的路由选择协议和共同的度量以确定分组在该 AS 内的路由。
• 使用一种 AS 之间的路由选择协议用以确定分组在AS之间的路由。

尽管一个 AS 使用了多种内部路由选择协议和度量，但对其他 AS 表现出的是一个单一的和一致的路由选择策略。

1.5.4 两大类路由选择协议

因特网的中，路由协议可以分为内部网关协议 IGP (Interior Gateway Protocol)和外部网关协议 EGP (External Gateway Protocol)。

IGP是在一个AS内部使用的路由选择协议，如RIP和OSPF协议，是域内路由选择 (interdomain routing)。当源主机和目的主机处在不同的AS中，在数据报到达AS的边界时，使用外部网关协议 EGP 将路由选择信息传递到另一个自治系统中，如BGP-4，是域间路由选择 (intradomain routing)。

1.5.5 RIP

路由信息协议 (Routing Information Protocol, RIP) 是一种基于距离 向量的路由选择协议。RIP 协议要求网络中的每一个路由器都要维护从它自己到自治系统内其他每一个目的网络的距离和下一跳路由器地址。

路由表的初始化 。
路由表的更新 。
对于本路由表中已有的路由项，当发送响应报文的RIP邻居相同时，不论响应报文中携带的路由项度量值是大还是小，都更新该路由项（度量值相同时只将其老化定时器清零）。
对于本路由表中已有的路由项，当发送响应报文的RIP邻居不同时，只在路由项度量值减少时，更新该路由项。
对于本路由表中不存在的路由项，在度量值小于协议规定的最大值时，在路由表中增加该路由项。
路由表的维护
rip的特性：最多 15 跳；30s一次刷新；保存25条路由信息；使用UDP协议的520端口。

1.5.6 OSPF

开放最短路径优先(Open Shortest Path First，OSPF)，这个算法名为“最短路径优先”是因为使用了 Dijkstra 提出的最短路径算法SPF，只是一个协议的名字，它并不表示其他的路由选择协议不是“最短路径优先”。

OSPF是一种典型的链路状态路由协议，运行OSPF的每一台路由器都维护一个描述AS拓扑结构的数据库，该数据库由每一个路由器的链路状态信息、路由器相连的网络状态信息、该AS的外部状态信息等组成。

1.5.7 参考

动态路由协议RIP OSPF实训

1.6 域名系统

1.6.1 简介

DNS是一个简单的请求-响应协议，是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP协议的53端口。

1.6.2 相关术语

1.6.2.1 mDNS

Multicast DNS (mDNS)，多播DNS，使用5353端口，组播地址为224.0.0.251或[FF02::FB]。在一个没有常规DNS服务器的小型网络内可以使用mDNS来实现类似DNS的编程接口、包格式和操作语义。mDNS协议的报文与DNS的报文结构相同，但有些字段对于mDNS来说有新的含义。

启动mDNS的主机会在进入局域网后向所有主机组播消息，包含主机名、IP等信息，其他拥有相应服务的主机也会响应含有主机名和IP的信息。

mDNS的域名是用.local和普通域名区分开的。

1.6.2.2 FQDN

FQDN (Fully-Qualified Domain Name) 是域名的完全形态，主要是包含零长度的根标签，例如 www.example.com. 。

1.6.2.3 TLD

Top-Level Domain (TLD) 是属于根域的一个域，例如com或jp。

TLD一般可以分为 Country Code Top-Level Domains (ccTLDs) 、Generic Top-Level Domains (gTLDs) 以及其它。

1.6.2.4 IDN

Internationalized Domain Names for Applications (IDNA) 是为了处理非ASCII字符的情况。

1.6.2.5 CNAME

CNAME即Canonical name，又称alias，将域名指向另一个域名。

1.6.2.6 TTL

Time To Live，无符号整数，记录DNS记录过期的时间，最小是0，最大是2147483647 (2^31 - 1)。

1.6.3 请求响应

1.6.3.1 DNS记录

• A记录
  • 返回域名对于IPv4地址
• NS记录
  • 域名服务器
  • 返回该域名由那台域名服务器解析
• PTR记录
  • 反向记录
  • 从IP地址到域名的记录
• MX记录
  • 电子邮件交换记录
  • 记录邮件域名对应的IP地址

1.6.3.2 响应码

• NOERROR

• FORMERR

• SERVFAIL

• NXDOMAIN

• NOTIMP

• REFUSED

• NODATA

1.6.4 域名系统工作原理

1.6.4.1 解析过程

DNS解析过程是递归查询的，具体过程如下：

• 用户要访问域名www.example.com时，先查看本机hosts是否有记录或者本机是否有DNS缓存，如果有，直接返回结果，否则向递归服务器查询该域名的IP地址
• 递归缓存为空时，首先向根服务器查询com顶级域的IP地址
• 根服务器告知递归服务器com顶级域名服务器的IP地址
• 递归向com顶级域名服务器查询负责example.com的权威服务器的IP
• com顶级域名服务器返回相应的IP地址
• 递归向example.com的权威服务器查询www.example.com的地址记录
• 权威服务器告知www.example.com的地址记录
• 递归服务器将查询结果返回客户端

1.6.4.2 域传送

DNS服务器可以分为主服务器、备份服务器和缓存服务器。域传送是指备份服务器从主服务器拷贝数据，并使用得到的数据更新自身数据库。域传送是在主备服务器之间同步数据库的机制。

1.6.5 服务器类型

1.6.5.1 根服务器

根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。

根服务器在域名树中代表最顶级的.域， 一般省略。

13台IPv4根服务器的域名标号为a到m，即a.root-servers.org到m.root-servers.org，所有服务器存储的数据相同，仅包含ICANN批准的TLD域名权威信息。

1.6.5.2 权威服务器

权威服务器上存储域名Zone文件，维护域内域名的权威信息，递归服务器可以从权威服务器获得DNS查询的资源记录。

权威服务器需要在所承载的域名所属的TLD管理局注册，同一个权威服务器可以承载不同TLD域名，同一个域也可以有多个权威服务器。

1.6.5.3 递归服务器

递归服务器负责接收用户的查询请求，进行递归查询并响应用户查询请求。在初始时递归服务器仅有记录了根域名的Hint文件。

1.6.6 DNS利用

1.6.6.1 DGA

DGA（Domain Generate Algorithm，域名生成算法）是一种利用随机字符来生成C&C域名，从而逃避域名黑名单检测的技术手段，常见于botnet中。一般来说，一个DGA域名的存活时间约在1-7天左右。

通信时，客户端和服务端都运行同一套DGA算法，生成相同的备选域名列表，当需要发动攻击的时候，选择其中少量进行注册，便可以建立通信，并且可以对注册的域名应用速变IP技术，快速变换IP，从而域名和IP都可以进行快速变化。

DGA域名有多种生成方式，根据种子类型可以分为确定性和不确定性的生成。不确定性的种子可能会选用当天的一些即时数据，如汇率信息等。

1.6.6.2 DNS隧道

DNS隧道工具将进入隧道的其他协议流量封装到DNS协议内，在隧道上传输。这些数据包出隧道时进行解封装，还原数据。

1.6.7 加密方案

作为主流的防御方案，DNS加密有五种方案，分别是 DNS-over-TLS (DoT)、DNS-over-DTLS、DNS-over-HTTPS (DoH)、DNS-over-QUIC以及DNSCrypt。

1.6.7.1 DoT

DoT方案在2016年发表于RFC7858，使用853端口。主要思想是Client和Server通过TCP协议建立TLS会话后再进行DNS传输，Client通过SSL证书验证服务器身份。

1.6.7.2 DNS-over-DTLS

DNS-over-DTLS和DoT类似，区别在于使用UDP协议而不是TCP协议。

1.6.7.3 DoH

DoH方案在发表RFC8484，使用https://dns.example.com/dns-query{?dns}来查询服务器的IP，复用https的443端口，流量特征比较小。DoH会对DNS服务器进行加密认证，不提供fallback选项。目前Cloudflare、Google等服务商对DoH提供了支持。

1.6.7.4 DNSCrypt

DNSCrypt使用X25519-XSalsa20Poly1305而非标准的TLS，且DNSCrypt的Client需要额外的软件，Server需要的专门的证书。

1.6.8 DNS相关漏洞

1.6.8.1 DNS劫持

DNS劫持有多种方式，比较早期的攻击方式是通过攻击域名解析服务器，或是伪造DNS响应的方法，来将域名解析到恶意的IP地址。

随着互联网应用的不断发展，出现了基于废弃记录的劫持方式。这种方式发生的场景是次级域名的解析记录指向第三方资源，而第三方资源被释放后，解析记录并没有取消，在这种场景下，可以对应申请第三方资源，以获取控制解析记录的能力。

1.6.8.2 拒绝服务

DNS服务通常会开启UDP端口，当DNS服务器拥有大量二级域NS记录时，通过DNS的UDP反射攻击可以实现高倍的拒绝服务。

1.7 HTTP协议簇

1.7.1 HTTP标准

1.7.1.1 报文格式

1.7.1.1.1 请求报文格式

1.7.1.1.2 响应报文格式

1.7.1.1.3 字段解释

• method
  • HTTP动词
  • 常见方法 ：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE
  • 扩展方法 ：LOCK / MKCOL / COPY / MOVE
• version
  • 报文使用的HTTP版本
  • 格式为 HTTP.
• url
  • ?/:@:/;?#

1.7.1.2 请求头列表

• Accept

  • 指定客户端能够接受的内容类型
  • Accept:text/plain,text/html

• Accept-Charset

  • 浏览器可以接受的字符编码集
  • Accept-Charset:ios-8859-5

• Accept-Encoding

  • 指定浏览器可以支持的web服务器返回内容压缩编码类型
  • Accept-Encoding:compress,gzip

• Accept-Language

  • 浏览器可以接受的语言
  • Accept-Language:en,zh

• Accept-Ranges

  • 可以请求网页实体的一个或多个子范围字段
  • Accept-Ranges:bytes

• Authorization

  • HTTP授权的授权证书
  • Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Cache-Control

  • 指定请求和响应遵循的缓存机制 Cache-Control: no-cache

• Connection

  • 表示是否需要持久连接 // HTTP 1.1默认进行持久连接
  • Connection: close

• Cookie

  • HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器
  • Cookie: role=admin;ssid=1

• Content-Length

  • 请求的内容长度
  • Content-Length: 348

• Content-Type

  • 请求的与实体对应的MIME信息
  • Content-Type: application/x-www-form-urlencoded

• Date

  • 请求发送的日期和时间
  • Date: Tue, 15 Nov 2010 08:12:31 GMT

• Expect

  • 请求的特定的服务器行为
  • Expect: 100-continue

• From

  • 发出请求的用户的Email
  • From: wpsec@email.com

• Host

  • 指定请求的服务器的域名和端口号
  • Host: www.github.com

• If-Match

  • 只有请求内容与实体相匹配才有效
  • If-Match: “737060cd8c284d8af7ad3082f209582d”

• If-Modified-Since

  • 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
  • If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

• If-None-Match

  • 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
  • If-None-Match:“737060cd8c284d8af7ad3082f209582d”

• If-Range

  • 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag
  • If-Range: “737060cd8c284d8af7ad3082f209582d”

• If-Unmodified-Since

  • 只在实体在指定时间之后未被修改才请求成功
  • If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

• Max-Forwards

  • 限制信息通过代理和网关传送的时间
  • Max-Forwards: 10

• Pragma

  • 用来包含实现特定的指令
  • Pragma: no-cache

• Proxy-Authorization

  • 连接到代理的授权证书
  • Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

• Range

  • 只请求实体的一部分，指定范围
  • Range: bytes=500-999

• Referer

  • 先前网页的地址，当前请求网页紧随其后,即来路
  • • Referer: http://www.zcmhi.com/archives/71.html

• TE

  • 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息
  • TE: trailers,deflate;q=0.5

• Upgrade

  • 向服务器指定某种传输协议以便服务器进行转换（如果支持）
  • • Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

• User-Agent

  • User-Agent的内容包含发出请求的用户信息
  • User-Agent: Mozilla/5.0 (Linux; X11)

• Via

  • 通知中间网关或代理服务器地址，通信协议
  • Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

• Warning

  • 关于消息实体的警告信息
  • Warn: 199 Miscellaneous warning

1.7.1.3 相应头列表

• Accept-Ranges

  • 表明服务器是否支持指定范围请求及哪种类型的分段请求
  • Accept-Ranges:bytes

• Access-Control-Allow-Origin

  • 配置有权限访问资源的域
  • Access-Control-Allow-Origin:|*

• Age

  • 从原始服务器到代理缓存形成的估算时间（以秒计，非负）
  • Age:12

• Allow

  • 对某网络资源的有效的请求行为，不允许则返回405
  • Allow:GET,HEAD

• Cache-Control

  • 告诉所有的缓存机制是否可以缓存及哪种类型
  • Cache-Control:no-cache

• Content-Encoding

  • web服务器支持的返回内容压缩编码类型。
  • Content-Encoding:gzip

• Content-Language

  • 响应体的语言
  • Content-Language:en,zh

• Content-Length

  • 响应体的长度
  • Content-Length:348

• Content-Location

  • 请求资源可替代的备用的另一地址
  • Content-Location:/index.htm

• Content-MD5

  • 返回资源的MD5校验值
  • Content-MD5:Q2hlY2sgSW50ZWdyaXR5IQ==

• Content-Range

  • 在整个返回体中本部分的字节位置
  • Content-Range:bytes21010-47021/47022

• Content-Type

  • 返回内容的MIME类型
  • Content-Type:text/html;charset=utf-8

• Date

  • 原始服务器消息发出的时间
  • Date:Tue,15Nov201008:12:31GMT

• ETag

  • 请求变量的实体标签的当前值
  • ETag:“737060cd8c284d8af7ad3082f209582d”

• Expires

  • 响应过期的日期和时间
  • Expires:Thu,01Dec201016:00:00GMT

• Last-Modified

  • 请求资源的最后修改时间
  • Last-Modified:Tue,15Nov201012:45:26GMT

• Location

  • 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
  • Location:http://www.zcmhi.com/archives/94.html

• Pragma

  • 包括实现特定的指令，它可应用到响应链上的任何接收方
  • Pragma:no-cache

• Proxy-Authenticate

  • 它指出认证方案和可应用到代理的该URL上的参数
  • Proxy-Authenticate:Basic

• Refresh

  • 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持）
  • Refresh:5;url=http://www.zcmhi.com/archives/94.html

• Retry-After

  • 如果实体暂时不可取，通知客户端在指定时间之后再次尝试
  • Retry-After:120

• Server

  • web服务器软件名称
  • Server:Apache/1.3.27(Unix)(Red-Hat/Linux)

• Set-Cookie

  • 设置HttpCookieSet-Cookie:UserID=JohnDoe;Max-Age=3600;Version=1

• Strict-Transport-Security

  • 设置浏览器强制使用HTTPS访问
  • max-age:x秒的时间内访问对应域名都使用HTTPS请求
  • includeSubDomains:网站的子域名也启用规则
  • Strict-Transport-Security:max-age=1000;includeSubDomains

• Trailer

  • 指出头域在分块传输编码的尾部存在Trailer:Max-Forwards

• Transfer-Encoding

  • 文件传输编码
  • Transfer-Encoding:chunked

• Vary

  • 告诉下游代理是使用缓存响应还是从原始服务器请求
  • Vary:*

• Via

  • 告知代理客户端响应是通过哪里发送的
  • Via:1.0fred,1.1nowhere.com(Apache/1.1)

• Warning

  • 警告实体可能存在的问题
  • Warning:199Miscellaneouswarning

• WWW-Authenticate

  • 表明客户端请求实体应该使用的授权方案
  • WWW-Authenticate:Basic

• X-Content-Type-Options

  • 配置禁止MIME类型嗅探
  • X-Content-Type-Options:nosniff

• X-Frame-Options

  • 配置页面是否能出现在,,,等标签中，防止点击劫持
  • • X-Frame-Options:deny

• X-XSS-Protection

  • 配置XSS防护机制
  • X-XSS-Protection:1;mode=block

1.7.1.4 HTTP状态返回代码1xx（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。

code	代码	说明
100	继续	服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
101	切换协议	请求者已要求服务器切换协议，服务器已确认并准备切换

1.7.1.5 HTTP状态返回代码 2xx （成功）

表示成功处理了请求的状态代码。

code	代码	说明
200	成功	服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201	已创建	请求成功并且服务器创建了新的资源
202	已接受	服务器已接受请求，但尚未处理
203	非授权信息	服务器已成功处理了请求，但返回的信息可能来自另一来源
204	无内容	服务器成功处理了请求，但没有返回任何内容
205	重置内容	服务器成功处理了请求，但没有返回任何内容
206	部分内容	服务器成功处理了部分GET请求

1.7.1.6 HTTP状态返回代码 3xx （重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

code	代码	说明
300	多种选择	针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301	永久移动	请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302	临时移动	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303	查看其他位置	请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304	未修改	自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305	使用代理	请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
307	临时重定向	服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

1.7.1.8 HTTP状态返回代码 4xx（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。

&l

code	代码	说明
400	错误请求	服务器不理解请求的语法。
401	未授权	请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
403	禁止	服务器拒绝请求。