应用层
1、域名系统DNS
域名系统 DNS(Domain Name System) 是一个联机分布式数据库系统，采用C/S方式，提供了主机名和 IP 地址之间相互转换的服务。这里的分布式数据库是指，每个站点只保留它自己的那部分数据。
1.1 主要任务
- 一个由分层的DNS服务器实现的分布式数据库；
- 一个是的主机能够查询分布式数据库的应用层协议。
DNS协议运行在UDP之上，使用53端口。
DNS通常由其他的应用层协议HTTP、FTP、SMTP所使用，将用户提供的主机名解析为IP地址。
1.2 应用场景
DNS协议是应用层协议。
- 使用客户-服务器模式运行在通信的端系统之间；
- 在通信的端系统之间通过下面的端到端运输协议来传送DNS报文。
1.3 DNS运行做法
运行在用户主机上的一个浏览器请求URLhttps://www.cnblogs.com/njuptzheng/时会发生什么？
- 同一台用户主机上运行着DNS应用的客户端；
- 浏览器从上述URL中抽取主机名
www.cnblogs.com，并将这台主机名传送给DNS应用的客户端； - DNS客户向DNS服务器发送一个包含主机名的请求；
- DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址；
- 一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。
1.4 域名
每个域名都由标号组成，每个标号之间用点隔开。域名具有层次结构，从上到下依次为：根域名、顶级域名、二级域名、三级域名。
1.5 DNS传输
DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输：
- 如果返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）。
- 区域传送（区域传送是主域名服务器向辅助域名服务器传送变化的那部分数据）。
主机解析域名的顺序：浏览器缓存、找本机的 hosts 文件、路由缓存、找 DNS 服务器（本地DNS服务器、权威DNS服务器、顶级DNS服务器、根DNS服务器，通过迭代查询、递归查询）
任何DNS查询既可以是迭代的也能是递归的。从请求主机到本地DNS服务器的查询是递归的，其他查询是迭代的。
- 根DNS服务器：根DNS服务器提供TLD服务器的IP地址。
- 顶级DNS服务器(TLD：TLD服务器提供权威DNS服务器的IP地址。
- 权威DNS服务器：在因特网上具有公共可访问的机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。而权威DNS服务器收藏这些DNS记录。
- 本地DNS服务器：每个ISP都有一台本地DNS服务器。
使用 nslookup 命令可以查看域名解析的 IP 地址。
2、文件传送协议FTP
FTP 使用 TCP 进行连接，它需要两个连接来传送一个文件：
- 控制连接：服务器打开端口号 21 等待客户端的连接，客户端主动建立连接后，使用这个连接将客户端的命令传送给服务器，并传回服务器的应答。
- 数据连接：标准端口为 20，用来传送一个文件数据。
根据数据连接是否是服务器端主动建立，FTP 有主动和被动两种模式：
- 主动模式：服务器端主动建立数据连接，其中服务器端的端口号为 20，客户端的端口号随机，但是必须大于1024，因为 0~1023是熟知端口号。
- 被动模式：客户端主动建立数据连接，其中客户端的端口号由客户端自己指定，服务器端的端口号随机。
主动模式要求客户端开放端口号给服务器端，需要去配置客户端的防火墙，开放 20 和 21 端口。被动模式只需要服务器端开放端口号即可，无需客户端配置防火墙。但是被动模式会导致服务器端的安全性减弱，因为开放了过多的端口号。
3、动态主机配置协议DHCP
DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的连网方式，用户不再需要手动配置 IP 地址等信息。DHCP 配置的内容不仅是 IP 地址，还包括子网掩码、网关 IP 地址。
DHCP 工作过程如下：
- 客户端发送 Discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，被放入 UDP 中，该报文被广播到同一个子网的所有主机上。如果客户端和 DHCP 服务器不在同一个子网，就需要使用中继代理。
- DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择。
- 如果客户端选择了某个 DHCP 服务器提供的信息，那么就发送 Request 报文给该 DHCP 服务器。
- DHCP 服务器发送 Ack 报文，表示客户端此时可以使用提供给它的信息。
注意：DHCP 服务器必须设置为静态 IP 地址，如果为本网段分配 IP 地址，DHCP 服务器的作用域范围必须设置为本网段地址范围。
4、超文本传输协议HTTP
4.1 统一资源定位符URL
统一资源定位符 URL 是用来表示互联网上得到的资源位置和访问这些资源的方法。一般形式由下面四个部分组成：<协议>://<端口>/<路径>
4.2 HTTP中的非持续连接和持续连接
当客户端-服务器的交互是经过TCP进行的，应用程序就需要做一个决定，每一次的请求-响应是经一个单独的TCP连接发送，还是所有的请求-响应经相同的TCP连接发送呢？
采用前一个方法，该应用程序就被称为使用非持续连接；采用后一个方法，该程序就被称为使用持续连接。
4.2.1 采用非持续连接的HTTP
我们模拟从服务器向客户传送一个web页面的步骤。
假设该web页面含有一个HTML文件和5个JPEG图形，并且这6个对象位于同一台服务器上。假设该HTML文件的URL为https://www.cnblogs.com/njuptzheng/ 。
- HTTP客户进程在端口号80发起一个到服务器
https://www.cnblogs.com的TCP连接。该端口号是HTTP的默认端口。在客户和服务器分别有一个套接字与该连接相关联。 - HTTP客户经他的套接字向服务器发送一个HTTP请求报文。请求报文中包含路径名
/njuptzheng/。 - 服务器经他的套接字接受该请求报文，从其存储器中找到
https://www.cnblogs.com/njuptzheng/，在一个响应报文中封装对象，并通过其套接字向客户发送响应报文。 - HTTP服务器通知TCP断开该TCP连接。（TCP必须确定客户收到响应报文后才会实际中断连接）
- 客户收到响应报文，TCP连接中断。该报文指出封装的对象是一个
HTML文件，客户从响应报文中提取该文件，检查HTML文件，得到5个JPEG图形的引用。 - 对每个引用的图形重复前四个步骤。
采用非持续连接的HTTP的响应时间为两个RTT加上服务器传输HTML文件的时间。
RTT（往返时间）：一个短分组从客户到服务器再返回到客户所花费的时间。
客户和服务器之间发起一个TCP连接：涉及到一次“三次握手”过程，客户向服务器发送一个小TCP报文段，服务器返回一个小TCP报文段做出确认和响应，最后客户返回确认。三次握手的前两个部分占用一个RTT。客户在返回确认报文时发送一个HTTP请求报文。一旦该报文到达服务器，服务器就在该TCP连接上返回HTML文件。该HTTP请求/响应用于了一个RTT。
4.2.2 采用持续连接的HTTP
非持续连接有一些缺点：
*必须为每一个请求的对象建立和维护一个全新的连接。这给web服务器带来了严重的负担。
*每一个对象经受两倍的RTT的交付时延。
4.3 HTTP操作过程
HTTP 使用面向连接的 TCP 作为运输层协议，保证数据的可靠传输。但 HTTP 协议本身是无连接的，即通信双方在交换 HTTP 报文之前不需要建立 HTTP 连接。
4.4 HTTP的报文结构
HTTP 有两类报文：请求报文（从客户向服务器发送请求报文）和响应报文（从服务器到客户的回答）
HTTP 的请求报文和响应报文都是有三部分组成：
- 开始行：用于区分是请求报文还是响应报文。
- 首部行：用来说明浏览器、服务器和报文主体的一些信息。整个首部行结束后还有一空行将首部行和实体主体分开。
- 实体主体：请求报文中一般不使用这个字段，而响应报文中也可能没有这个字段。
4.5 HTTP报文格式
4.5.1 HTTP请求报文
客户端发送的 请求报文 第一行为请求行，包含了方法字段。
| 方法（操作） | 意义 |
|---|---|
| OPTION | 请求一些选项的信息 |
| GET | 请求读取由 URL 标志的信息 |
| HEAD | 获取 URL 标志的报文首部 |
| POST | 主要用来传输数据，而 GET 主要用来获取资源。 |
| PUT | 上传文件，不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。 |
| PATCH | PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改 |
| DELETE | 删除文件，与 PUT 功能相反，并且同样不带验证机制 |
| OPTIONS | 查询指定的 URL 能够支持的方法 |
| CONNECT | 要求在与代理服务器通信时建立隧道，使用 SSL 和 TLS 协议把传输内容加密后经网络隧道传输 |
| TRACE | 追踪路径，服务器会将通信路径返回给客户端 |
下面是一个完整的 HTTP 请求报文的例子：
GET /dir/index.htm HTTP/1.1 {请求行使用了相对URL}
Host: www.xyz.edu.cn {首部行的开始，给出主机的域名}
Connection: close {告诉服务器发送完请求的文档就可以释放连接}
User-Agent: Mozilla/5.0 {表明用户代理是使用火狐浏览器Firefox}
Accept-Language: cn {表示用户希望优先得到中文版本的文档}
{请求报文的最后还有一个空行}
4.5.2 HTTP响应报文
三个部分：一个初始状态行、6个首部行、实体行
HTTP/1.1 200 OK {初始状态行：协议版本字段、状态码和相应状态信息}
Connection: close {首部行告诉服务器发送完请求的文档就可以释放连接}
Date: Tue, 18 Aug 2015 15:44:04 GMT {首部行指示服务器产生并发送该响应报文的日期和时间}
Server: Apache/2.2.3 (CentOS) {首部行指示该报文是由一台Apache Web服务器产生}
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT {首部行指示对象创建或者最后修改的日期和时间}
Content-Length: 6821 {首部行指示被发送对象中的字节数}
Content-Type: text/html {首部行指示实体体中的对象是HTML文本}
(data data data data data ...)
4.6 HTTP状态码
服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。
状态码都是 3 位数，分为 5 个大类。
| 状态码 | 类别 | 含义 |
|---|---|---|
| 1XX | Informational（信息性状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |
1XX 信息
- 100 Continue：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
2XX 成功
- 200 OK
- 204 No Content：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
- 206 Partial Content：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。
3XX 重定向
- 301 Moved Permanently：永久性重定向
- 302 Found：临时性重定向
- 303 See Other：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
- 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
- 304 Not Modified：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-NoneMatch，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
- 307 Temporary Redirect：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的POST 方法改成 GET 方法。
4XX 客户端错误
- 400 Bad Request：请求报文中存在语法错误。
- 401 Unauthorized：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
- 403 Forbidden：请求被拒绝。
- 404 Not Found
5XX 服务器错误
- 500 Internal Server Error：服务器正在执行请求时发生错误。
- 503 Service Unavailable：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
常见的三种状态行的响应报文：
HTTP/1.1 202 Accepted {接收}
HTTP/1.1 400 Bad Request {错误的请求}
HTTP/1.1 404 Not Found {找不到}
5、HTTPS
HTTP 有以下安全性问题：
- 使用明文进行通信，内容可能会被窃听；
- 不验证通信方的身份，通信方的身份有可能遭遇伪装；
- 无法证明报文的完整性，报文有可能遭篡改。
HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol) 协议，它是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。
HTTPS 的全称是 Hypertext Transfer Protocol Secure，它用来在计算机网络上的两个端系统之间进行安全的交换信息(secure communication)，它相当于在 HTTP 的基础上加了一个 Secure 安全的词眼，那么我们可以给出一个 HTTPS 的定义：HTTPS 是一个在计算机世界里专门在两点之间安全的传输文字、图片、音频、视频等超文本数据的约定和规范。HTTPS 是 HTTP 协议的一种扩展，它本身并不保传输的证安全性，那么谁来保证安全性呢？在 HTTPS 中，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。
5.1 认识 SSL/TLS
TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。
我们都知道一些在线业务（比如在线支付）最重要的一个步骤是创建一个值得信赖的交易环境，能够让客户安心的进行交易，SSL/TLS 就保证了这一点，SSL/TLS 通过将称为 X.509 证书的数字文档将网站和公司的实体信息绑定到加密密钥来进行工作。每一个密钥对(key pairs) 都有一个 私有密钥(private key) 和 公有密钥(public key)，私有密钥是独有的，一般位于服务器上，用于解密由公共密钥加密过的信息；公有密钥是公有的，与服务器进行交互的每个人都可以持有公有密钥，用公钥加密的信息只能由私有密钥来解密。
X.509 是公开密钥证书的标准格式，这个文档将加密密钥与（个人或组织）进行安全的关联。
X.509 主要应用如下：
- SSL/TLS 和 HTTPS 用于经过身份验证和加密的 Web 浏览
- 通过 S/MIME 协议签名和加密的电子邮件
- 代码签名：它指的是使用数字证书对软件应用程序进行签名以安全分发和安装的过程。通过使用由知名公共证书颁发机构（例如SSL.com）颁发的证书对软件进行数字签名，开发人员可以向最终用户保证他们希望安装的软件是由已知且受信任的开发人员发布；并且签名后未被篡改或损害。
- 还可用于文档签名
- 还可用于客户端认证
- 政府签发的电子身份证
5.2 加密
HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息。
对称密钥加密
在了解对称加密前，我们先来了解一下密码学的东西，在密码学中，有几个概念：明文、密文、加密、解密
- 明文(Plaintext)，一般认为明文是有意义的字符或者比特集，或者是通过某种公开编码就能获得的消息。明文通常用 m 或 p 表示
- 密文(Ciphertext)，对明文进行某种加密后就变成了密文
- 加密(Encrypt)，把原始的信息（明文）转换为密文的信息变换过程
- 解密(Decrypt)，把已经加密的信息恢复成明文的过程。
对称加密(Symmetrical Encryption)顾名思义就是指加密和解密时使用的密钥都是同样的密钥。只要保证了密钥的安全性，那么整个通信过程也就是具有了机密性。
- 优点：运算速度快；
- 缺点：无法安全地将密钥传输给通信方。
非对称密钥加密
非对称加密(Asymmetrical Encryption) 也被称为公钥加密，相对于对称加密来说，非对称加密是一种新的改良加密方式。密钥通过网络传输交换，它能够确保及时密钥被拦截，也不会暴露数据信息。非对称加密中有两个密钥，一个是公钥，一个是私钥，公钥进行加密，私钥进行解密。公开密钥可供任何人使用，私钥只有你自己能够知道。
非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。
- 优点：可以更安全地将公开密钥传输给通信发送方；
- 缺点：运算速度慢。
HTTPS采用的混合加密方式
HTTPS 采用混合的加密机制，使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。
5.3 摘要算法
SSL 提供报文摘要功能来进行完整性保护。
HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。
MD5 的全称是 Message Digest Algorithm 5，它是属于密码哈希算法(cryptographic hash algorithm)的一种，MD5 可用于从任意长度的字符串创建 128 位字符串值。尽管 MD5 存在不安全因素，但是仍然沿用至今。MD5 最常用于验证文件的完整性。但是，它还用于其他安全协议和应用程序中，例如 SSH、SSL 和 IPSec。一些应用程序通过向明文加盐值或多次应用哈希函数来增强 MD5 算法。
HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。
可以把摘要算法理解成一种特殊的压缩算法，它能够把任意长度的数据压缩成一种固定长度的字符串，这就好像是给数据加了一把锁。
除了常用的 MD5 是加密算法外，SHA-1(Secure Hash Algorithm 1) 也是一种常用的加密算法，不过 SHA-1 也是不安全的加密算法，在 TLS 里面被禁止使用。目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。
SHA-2 的全称是Secure Hash Algorithm 2 ，它在 2001 年被推出，它在 SHA-1 的基础上做了重大的修改，SHA-2 系列包含六个哈希函数，其摘要（哈希值）分别为 224、256、384 或 512 位：SHA-224, SHA-256, SHA-384, SHA-512。分别能够生成 28 字节、32 字节、48 字节、64 字节的摘要。
有了 SHA-2 的保护，就能够实现数据的完整性，哪怕你在文件中改变一个标点符号，增加一个空格，生成的文件摘要也会完全不同，不过 SHA-2 是基于明文的加密方式，还是不够安全，那应该用什么呢？
安全性更高的加密方式是使用 HMAC，在理解什么是 HMAC 前，你需要先知道一下什么是 MAC。
MAC 的全称是message authentication code，它通过 MAC 算法从消息和密钥生成，MAC 值允许验证者（也拥有秘密密钥）检测到消息内容的任何更改，从而保护了消息的数据完整性。
HMAC 是 MAC 更进一步的拓展，它是使用 MAC 值 + Hash 值的组合方式，HMAC 的计算中可以使用任何加密哈希函数，例如 SHA-256 等。
5.4 认证
通过使用 证书 来对通信方进行认证。我们在上面的叙述过程中出现过公钥加密，私钥解密的这个概念。提到的私钥只有你一个人所有，能够辨别唯一性，所以我们可以把顺序调换一下，变成私钥加密，公钥解密。使用私钥再加上摘要算法，就能够实现数字签名，从而实现认证。
进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。
数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。
通常情况下，数字证书的申请人将生成由私钥和公钥以及证书签名请求（CSR）组成的密钥对。CSR是一个编码的文本文件，其中包含公钥和其他将包含在证书中的信息（例如域名，组织，电子邮件地址等）。密钥对和 CSR生成通常在将要安装证书的服务器上完成，并且 CSR 中包含的信息类型取决于证书的验证级别。与公钥不同，申请人的私钥是安全的，永远不要向 CA（或其他任何人）展示。
生成 CSR 后，申请人将其发送给 CA，CA 会验证其包含的信息是否正确，如果正确，则使用颁发的私钥对证书进行数字签名，然后将其发送给申请人。
