第二十九章 计算机网络知识点（应用层常见协议）

HTTP：超文本传输协议

功能：为了Web浏览器与服务器之间的通信设计的。当使用浏览器浏览网页的时候，网页是通过HTTP请求进行加载的。
过程如下：
HTTP协议是基于TCP协议，发送HTTP请求之前首先要建立TCP连接，也就是要经历3次握手。在HTTP协议1.1中，默认开启Keep-Alive，这样是建立的连接就可以在多次请求中被复用。

注意：HTTP协议是无状态的协议，代表无法记录客户端用户的装态，一般都是通过Session来记录客户端用户的状态。

SMTP：简单邮件传输协议

基于TCP协议，用来发送电子邮件。

电子邮件的发送过程

邮箱是“xxx”，我要向“xxx”发送邮件，整个过程可以简单分为下面几步：

1. 通过 SMTP 协议，我将我写好的邮件交给163邮箱服务器（邮局）。
2. 163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。
3. qq邮箱服务器接收邮件之后就通知邮箱为“xxx”的用户来收邮件，然后用户就通过 POP3/IMAP 协议将邮件取出。

如何判断邮箱是真正存在

很多场景(比如邮件营销)下面我们需要判断我们要发送的邮箱地址是否真的存在，这个时候可以利用 SMTP 协议来检测：

1. 查找邮箱域名对应的 SMTP 服务器地址
2. 尝试与服务器建立连接
3. 连接成功后尝试向需要验证的邮箱发送邮件
4. 根据返回结果判定邮箱地址的真实性

接受邮件的协议不是 SMTP 而是 POP3 协议

POP3/IMAP：邮件接收的协议

只需要了解 POP3 和 IMAP 两者都是负责邮件接收的协议即可。另外，需要注意不要将这两者和 SMTP 协议搞混淆了。SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP。IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。大部分网络邮件服务提供商都支持POP3和IMAP。

FTP：文件传输协议

FTP协议主要 提供文件传输服务，是基于TCP实现的可靠的传输。好处是可以屏蔽操作系统和文件存储方式
分析：
FTP是基于客户-服务器（C/S）模型设计的，在客户端和FTP服务器之间建立两个连接。

FTP区别于其他客户服务器最大的不同点是：它在两台通信的主机之间使用了两条TCP连接。两条TCP连接是:

1. 控制连接：用于传输控制信息，包括命令和响应
2. 数据连接：用于数据传送
   可以把命令和数据分开传送，大大提高了FTP的效率

Telnet:远程登陆协议

通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的安全的协议所取代的主要原因。

SSH:安全的网络传输协议

SSH（ Secure Shell） 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。

HTTP和HTTPS

HTTP

HTTP协议是规范超文本的传输。就是规范浏览器和服务器端的行为。
超文本：网上的包括文本在内的各种的信息。
HTTP是一个无状态的协议，即：服务器不维护任何有关客户端过去所发起的请求的消息

HTTP协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：

1. 服务器在 80 端口等待客户的请求。
2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
3. 服务器接收来自浏览器的 TCP 连接。
4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
5. 关闭 TCP 连接。

HTTP 协议优点

扩展性强、速度快、跨平台支持性高

HTTPS

HTTPS是HTTP的加强安全版本。是基于HTTP的，用TCP作为底层协议。额外使用SSL、TLS协议作为加密和安全认证，默认端口号是443

SSL通道使用基于密钥的加密算法，密钥长度通常是40或128比特

HTTPS协议优点

保密性好，信任度高

SSL，TLS协议

对通信数据进行加密，解决了HTTP数据透明的问题
SSL和TLS没有台打区别：
SSL是安全套接字协议。新版本被命名为TLS1.0，因此TLS是基于SSL之上的，通常把HTTPS中核心加密协议混称为SSL、TLS
工作原理：
SSL核心要素是非对称加密。采用两个密钥–一个公钥一个私钥。
在通信时，私钥由解密者保存；公钥由 任何一个加密者
公钥和私钥的生成依赖于 单向陷门函数

非对称加密设计了较为复杂的数学算法，在实际通信过程中，代价高，效率低。SSL，TLS实际对消息的加密使用是对称加密
对称加密：通信双方共享唯一的密钥，加密算法已知，加密方用密钥加密，解密方用密钥解密，保密性依赖于密钥的保密性

对称加密的密钥生成代价比公私钥对的生成代价低得多，那为什么 SSL/TLS 还需要使用非对称加密呢？
因为对称加密的保密性完全依赖于密钥的保密性。在双方通信之前，需要商量一个用于对称加密的密钥。网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。

公钥传输的信赖性

举例：
客户端和服务器想使用SSL，TLS通信。则客户端需要先知道服务器的公钥，获取公钥的唯一途径是把服务器的公钥在网络信道中传输。
注意（网络信道通信有几点）：
任何人都可以捕获通信包；通信包的保密性是由发送者设计的；保密算法设计方案默认公开，而解密默认是安全
假设，服务器的公钥不做加密，在信道中传输。若存在攻击者，发送给客户端一个诈包，假装是服务器的公钥，实则诱惑服务器的公钥，当客户端收获了假的公钥，客户端后续会使用假的公钥对数据进行加密，并在公开信道中传输，那么客户端将捕获的加密包会用假的私钥解密，那么攻击者就截获了本来客户端要给服务器发送的内容。并且服务器端还不知道发过来的是啥内容

证书颁发机构（CA）

CA默认是受信任的第三方。会给各个服务器颁发证书，证书存储在服务器上，并附有CA的电子签名。
当客户端，也就是浏览器向服务器发送HTTPS请求时，必须先获取目标服务器的证书，根据证书上的信息，检查证书的合法性。一旦检测证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

数字签名

数字签名要解决的问题，是防止证书被伪造。第三方信赖机构 CA 之所以能被信赖，就是 靠数字签名技术 。数字签名，是 CA 在给服务器颁发证书时，使用散列+加密的组合技术，在证书上盖个章，以此来提供验伪的功能。具体行为如下：
CA 知道服务器的公钥，对证书采用散列技术生成一个摘要。CA 使用 CA 私钥对该摘要进行加密，并附在证书下方，发送给服务器。现在服务器将该证书发送给客户端，客户端需要验证该证书的身份。客户端找到第三方机构 CA，获知 CA 的公钥，并用 CA 公钥对证书的签名进行解密，获得了 CA 生成的摘要。客户端对证书数据（包含服务器的公钥）做相同的散列处理，得到摘要，并将该摘要与之前从签名中解码出的摘要做对比，如果相同，则身份验证成功；否则验证失败。

带有证书的公钥传输机制如下：

1. 设有服务器 S，客户端 C，和第三方信赖机构 CA。
2. S 信任 CA，CA 是知道 S 公钥的，CA 向 S 颁发证书。并附上 CA 私钥对消息摘要的加密签名。
3. S 获得 CA 颁发的证书，将该证书传递给 C。
4. C 获得 S 的证书，信任 CA 并知晓 CA 公钥，使用 CA 公钥对 S 证书上的签名解密，同时对消息进行散列处理，得到摘要。比较摘要，验证 S 证书的真实性。
5. 如果 C 验证 S 证书是真实的，则信任 S 的公钥（在 S 证书中）。

HTTP1.0 VS HTTPS1.1

主要比较维度：
响应状态码
缓存处理
连接方式
Host头处理
带宽优化

响应状态码

HTTP/1.0仅定义了16种状态码。
HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。举例如下：
100 (Continue)——在请求大资源前的预热请求
206 (Partial Content)——范围请求的标识码
409 (Conflict)——请求与当前资源的规定冲突
410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址

缓存处理

作用：缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟。

HTTP/1.0提供的缓存机制非常简单。
服务器端使用Expires标签来标志（时间）一个响应体，在Expires标志时间内的请求，都会获得该响应体缓存。服务器端在初次返回给客户端的响应体中，有一个Last-Modified标签，该标签标记了被请求资源在服务器端的最后一次修改。
在请求头中，使用If-Modified-Since标签，该标签标志一个时间，意为客户端向服务器进行问询：“该时间之后，我要请求的资源是否有被修改过？”
通常情况下，请求头中的If-Modified-Since的值即为上一次获得该资源时，响应体中的Last-Modified的值。如果服务器接收到了请求头，并判断If-Modified-Since时间后，资源确实没有修改过，则返回给客户端一个304 not modified响应头，表示”缓冲可用，你从浏览器里拿吧！”。如果服务器判断If-Modified-Since时间后，资源被修改过，则返回给客户端一个200 OK的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。

TTP/1.1的缓存机制在HTTP/1.0的基础上，大大增加了灵活性和扩展性。
基本工作原理和HTTP/1.0保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是Cache-Control

连接方式

HTTP/1.0 默认使用短连接 ，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的“握手报文”和“挥手报文”占用了带宽。

为了解决 HTTP/1.0 存在的资源浪费的问题， HTTP/1.1 优化为默认长连接模式 。 采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。有必要说明的是，HTTP/1.0仍提供了长连接选项，即在请求头中加入Connection: Keep-alive。同样的，在HTTP/1.1中，如果不希望使用长连接选项，也可以在请求头中加入Connection: close，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。实现长连接需要客户端和服务端都支持长连接。

Host头处理

域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题，假设我们有一个资源URL是http://xxx.org/home.html，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。
因此，HTTP/1.1在请求头中加入了Host字段。加入Host字段的报文头部将会是:

GET /home.html HTTP/1.1
Host: xxx.org

带宽优化

主要分为三个方面：范围请求和状态码100，压缩

范围请求

HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1可以在请求中加入Range头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略Range头部，也可以返回若干Range响应。
如果一个响应包含部分数据的话，那么将带有206 (Partial Content)状态码。该状态码的意义在于避免了HTTP/1.0代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。在范围响应中，Content-Range头部标志指示出了该数据块的偏移量和数据块的长度。

状态码100

HTTP/1.1中新加入了状态码100。该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以作为指示请求是否会被正常响应，过程有两种：

1. 客户端向服务器请求资源，但服务器不想响应回应4xx
2. 客户端向服务器请求资源，服务器先回应100，代表可以响应客户端，客户端收到后进行响应资源

而在HTTP/1.0中，并没有100 (Continue)状态码，要想触发这一机制，可以发送一个Expect头部，其中包含一个100-continue的值。

压缩

许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。
HTTP/1.1则对内容编码（content-codings）和传输编码（transfer-codings）做了区分。内容编码总是端到端的，传输编码总是逐跳的。

HTTP/1.0包含了Content-Encoding头部，对消息进行端到端编码。
HTTP/1.1加入了Transfer-Encoding头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了Accept-Encoding头部，是客户端用来指示他能处理什么样的内容编码。

HTTP常见状态码总结

１XX(信息性状态码)–接受的请求正在处理

2XX(成功状态码)–请求正常处理完毕

200 OK ：请求被成功处理。比如发送一个查询用户数据的HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
201 Created ：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
202 Accepted ：服务端已经接收到了请求，但是还未处理。
204 No Content ： 服务端已经成功处理了请求，但是没有返回任何内容。（204状态码描述的是我们向服务端发送 HTTP 请求之后，只关注处理结果是否成功的场景。也就是说我们需要的就是一个结果：true/false。）

3XX(重定向状态码)–需要进行附加操作以完成请求

301 Moved Permanently ： 资源被永久重定向了。比如你的网站的网址更换了。
302 Found ：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

4XX(客户端错误状态码)–服务器无法处理请求

400 Bad Request ： 发送的HTTP请求存在问题。比如请求参数不合法、请求方法错误。
401 Unauthorized ： 未认证却请求需要认证之后才能访问的资源。
403 Forbidden ：直接拒绝HTTP请求，不处理。一般用来针对非法请求。
404 Not Found ： 你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
409 Conflict ： 表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

5XX(服务端错误状态码)–服务器处理请求出错

500 Internal Server Error ： 服务端出问题了（通常是服务端出Bug了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
502 Bad Gateway ：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。