计算机网络基础 - 应用层和它的朋友

计算机网络基础
303

一、DNS

1.1 作用

DNS 提供了主机名和 IP 地址之间相互转换的服务

首先了解一下域名结构：

  • 根域名
  • 顶级域名
  • 二级域名

节点之间查询方式是不同的：

  • 主机向本地域名服务器的查询一般都是采用递归查询
  • 本地域名服务器向根域名服务器的查询通常是采用迭代查询

1.2 使用协议

默认情况下使用 UDP，以下两种情况使用 TCP ：

  • 返回响应超过 512 字节（因为 UDP 最大支持 512 字节）
  • 区域传送

1.3 端口

无论是使用 UDP 或者 TCP 都使用 53 号端口

二、FTP

2.1 作用

FTP 用于网络中的文件传输

网络中复制文件具有一定的复杂性：

  • 计算机存储数据的格式不同
  • 文件的目录结构和文件命名的规定不同
  • 对于相同的文件存取功能，操作系统使用的命名不同
  • 访问控制方法不同

所以，需要 FTP 协议来传输文件，它正是应对这些复杂性条件而来的

2.2 使用协议

FTP 使用的是 TCP

2.3 端口

使用两个端口：

  • 控制端口：21
  • 数据端口：20

2.4 连接

FTP 传输一个文件的过程，它使用 TCP 完成，同时需要进行两个连接：

  • 控制连接
  • 数据连接

过程如下：

  • 控制连接：服务器打开 21 号端口，等待客户端来南京，连接完成，客户端命令通过 21 端口返回给服务器
  • 数据连接，有两种选择：
    • 由服务器主动数据连接：服务器使用 20 号端口，客户端端口号随机，但必须大于 1024
    • 由客户端主动数据连接：客户端自己定一个端口号，服务器端口号随机

主动模式指的是服务器主动数据连接，需要客户端开放端口号给服务器，故客户端防火墙需要配置

被动模式指的是服务器被动数据连接，服务器开发端口号即可，不用配置防火墙，开发太多也会不安全

三、DHCP

3.1 作用

DHCP 用于自动获取网络配置的信息：

  • IP 地址
  • 子网掩码
  • 网关 IP

3.2 使用协议

DHCP 使用的是 UDP

3.3 端口

  • 发送端口：67
  • 接收端口：68

3.4 流程

获取一个配置信息的工作流程如下：

  • 客户端发发送获取信息报文
    • 报文目的地址：255.255.255.255:67
    • 报文源地址：0.0.0.0:68
    • 放入 UDP 广播给同一子网的所有主机
  • DHCP 服务器处理获取信息报文
    • DHCP 发送信息报文给客户端
  • 客户端选择信息报文
    • 可能获取到多个 DHCP 信息报文，需要做选择
    • 选择后，发送请求报文给对应的 DHCP 服务器
  • DHCP 服务器回送 ACK 报文
    • 表示该对应的客户端可以使用该服务器的信息报文

四、邮件协议

4.1 作用

收发邮件，需要邮件协议来实现

4.2 类型

分为发送协议和读取协议，根据分类，常用三种协议：

  • 发送协议：SMTP
  • 读取协议：POP3 和 IMAP

4.3 角色

邮件协议、邮件系统，用户，整一个邮件发送流程中都有对应的都有的角色组成：

  • 用户代理，其实就是用户们
  • 邮件服务器，一个中转邮件的东西，分为发送邮件服务器和接收邮件服务器两种
  • 邮件协议，用的是 SMTP、POP3、IMAP

4.4 端口

  • SMTP：25
  • POP3：110
  • IMPA：143

4.5 流程

  • 用户与服务器交互
    • 发件人使用 SMTP 给发送邮件服务器发送邮件
    • 收件人使用 POP3 从接收邮件服务器接收邮件
  • 服务器与服务器交互
    • 发送邮件使用 SMTP 取得发件人的邮件
    • 接收邮件服务器使用 POP3 发送给接收方
    • 发送邮件服务器与接收邮件服务器使用的是 SMTP 相互交互

4.6 SMTP

SMTP 只能发送 ASCII 码

4.7 POP 3

用户从服务器读取了邮件，就把邮件删除，最新版本的 POP3 可以不删除邮件

4.8 IMAP

可以让用户随时随地去访问服务器上的邮件

五、HTTP

5.1 端口

使用 TCP 协议，80 端口

5.2 状态码

状态码是服务器返回的，位于响应报文中的第一行，也就是状态行

状态码类别含义
1XXInformational（信息性状态码）接收的请求正在处理
2XXSuccess（成功状态码）请求正常处理完毕
3XXRedirection（重定向状态码）需要进行附加操作以完成请求
4XXClient Error（客户端错误状态码）服务器无法处理请求
5XXServer Error（服务器错误状态码）服务器处理请求出错

1XX 信息：

  • 100 continue：一切正常

2XX 成功：

  • 200 OK
  • 204 No Content：请求成功处理，响应报文不包含实体部分
  • 206 Partial Content：客户端进行了范围请求，响应报文包含由 Content - Range 指定范围的实体内容

3XX 重定向：

  • 301 Moved Permanently：永久性重定向
  • 302 Found：临时性重定向
  • 303 See Other：临时性重定向，但要求客户端应该使用 GET 来请求服务器
  • 304 Not Modified：不满足请求报文首部的一些条件：if-Modified-Since、if-Range 等
  • 307 Temporary Redirect：临时重定向，但不把客户端重定向的 POST 改成 GET

4XX 客户端错误：

  • 400 Bad Request：请求报文中存在错误
  • 401 Unauthorized：发送请求需要认证信息
  • 403 Forbidden：请求被拒绝
  • 404 Not Found：找不到请求的网页

5XX 服务器错误：

  • 500 Internal Server Error：服务器正在指向请求时发生错误
  • 503 Service Unavailable：服务器暂时处于超负载或正在进行停机维护，无法处理请求

5.3.1 作用

HTTP 是无状态协议，HTTP 1.1 引入 Cookie，来保存客户端的状态信息

它是服务处发送给客户端的，保存在本地的一小块数据，那么下一次客户端再次请求服务器，就会携带上 Cookie，服务器通过这样的请求报文，可以区分不同的客户端。客户端由于每次写的时候都会携带上 Cookie，所以会带来额外的性能开销

现在 Cookie 逐渐被淘汰，浏览器 API 允许直接将数据存储到本地，例如 Web Storage API，本地存储和会话存储

Cookie 可用于：

  • 购物车、用户登录状态、用户主题
  • 用户行为倾向记录

5.3.2 创建

  • 服务器发送的响应报文包含 Set-Cookie 字段
  • 客户端得到响应报文后把 Cookie 内容保存到浏览器
  • 客户端对同一服务器发送请求时，从浏览器取出 Cookie，并把它存在首部字段发送给浏览器

5.3.3 分类

  • 会话期 Cookie：只在会话期间有效
  • 持久性 Cookie：指定了一个过期时间或有效期有效，这期间有效的 Cookie

5.3.4 HttpOnly

标记为 HttpOnly 的 Cookie 不能被 JS 脚本调用，跨站脚本攻击（XSS）常常使用 JS 的 document.cookie API 窃取用户的 Cookie 信息，因此使用 HttpOnly 标记可以一定程度上避免 XSS 攻击

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

5.3.5 Secure

标记为 Secure 的 Cookie 只能通过 HTTPS 加密过才能发送给服务器

5.4 Session

5.4.1 作用

HTTP 状态的保存也可以使用 Session 存储在服务器段

5.4.2 存储

Session 可以存储在服务器上的文件、数据库或者内存中，也可存储在 Redis 这样的内存型数据中，效率会更高

5.4.3 创建

  • 用户将状态信息（例如购物车、登录等）通过 HTTP 请求发送给服务器
  • 服务器验证报文正确性，正确则把用户状态信息存储到 Redis 中，在 Redis 中的 Key 就是 Session ID
  • 服务器通过响应报文的 Set-Cookie 设置这个 Session ID
  • 用户收到响应报文，存下 Cookie 到浏览器
  • 用户每次对同一服务器请求，就带上 Cookie，也就是 Session ID
  • 服务器拿到了 Session ID ，可以知道用户状态，继续之前的操作

注意：Session ID，需要注意安全性问题，在转账等业务，不能只使用 Session 来管理用户，还有进行重验证，例如短信验证码等

5.4.4 URL 重写

表示，浏览器禁用 Cookie，则 Session ID 无法通过 Cookie 传递，所以通过 URL 参数来传递

5.5 缓存

5.5.1 作用

通过首部字段 Cache-Control 来空控制缓存

5.5.2 分类

  • 禁止缓存
    • 禁止对请求或响应的任何一部分缓存
    • Cache-Control: no-store
  • 强制确认缓存
    • 缓存服务器需要向源服务器验证缓存资源的有效性
    • Cache-Control：no-cache
  • 私有缓存
    • 将资源作为私有缓存，只能被单独用户使用
    • Cache-Control：private
  • 公有缓存
    • 将资源作为公共缓存，可被多个用户使用，一般存在代理服务器中
    • Cache-Control：public

5.5.3 过期

缓存有过期，使用两种方式

  • 指定 max-age 指令：指定缓存的最大存活时间
  • 使用 Expires 字段：告知缓存服务器该资源过期时间

六、HTTP 1.1

6.1 连接

HTTP 1.1 默认长连接

HTTP 1.0 默认短连接

6.2 传输方式

HTTP 1.1 采用了流水线传输，在长连接上，连续发出请求，而不用等待响应返回，减少延迟

HTTP 1.0 默认是顺序发出，响应后才发送下一个请求，效率较低

6.3 状态码

新增状态码 100

6.4 传输格式

HTTP 1.1 可以选择采用分块传输编码，可以把数据分割成多块，让浏览器逐步显示页面

HTTP 1.0 必须指定精确的 Content-Length，一旦响应消息体小于该值，内容就会截断

6.5 处理指令

新增处理指令 max-age

七、HTTP 2.0

7.1 “1.X” 缺陷

  • 客户端并发需要多个连接才能实现
  • 请求和响应首部无法压缩
  • 没有资源优先级，TCP 连接利用率较低

7.2 二进制分帧层

HTTP 2.0 将报文分成了二进制格式的 HEADERS 帧和 DATA 帧，1.X 到 2.0 转换如下：

通信过程中，只有一个 TCP 连接存在，双方信息是以一种双向数据流传输的：

  • 数据流中用于承载双向信息（Rquest / Response），它有一个唯一标识符和可选的优先级信息
  • 消息：请求或响应对应的完整的一系列帧
  • 帧：最小的通信单位，不同数据流的帧可以交错发送，根据每个帧头的数据流标识符重写组装

7.3 服务器推送

HTTP 2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，例如发送了 html，就会带上它的 js 和 css 文件，这样客户端下次不用额外再次请求

7.4 首部压缩

HTTP 2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，避免重复重复传输首部信息，同时使用哈夫曼编码来对首部字段进行压缩

八、HTTPS

8.1 HTTP 缺陷

HTTP 存在安全问题：

  • 明文通信，内容可能被窃听
  • 不验证通信方身份，通信方可能是伪装的
  • 无法验证明文数据完整性，报文可能造到篡改

8.2 作用

HTTPS 的提出，就是为了能够安全的传输 HTTP 的信息

HTTPS 不是一种新协议，而是 HTTP + SSL，具有以下作用：

  • 加密
  • 认证
  • 数据完整性保护

8.3 端口

HTTPS 使用的端口号是 443 端口

8.4 交互

8.5 TLS / SSL

  • SSL （Secure Socket Layer），安全套接层协议是 90 年代 NetScape 搞出来的
  • 后面 SSL 标准化，叫 TLS（Transport Layer Security），传输层安全协议
  • TLS 1.0 就是 SSL 3.1
  • 所以 SSL = TLS

8.6 加密

8.6.1 对称密钥加密

加密和解密使用同一密钥

  • 优点：计算速度快
  • 缺点：密钥传输不安全

8.6.2 非对称密钥加密

加密和解密使用不同的密钥，一般流程如下：

  • 发送方使用接收方发送的公开密钥加密
  • 接收方使用私有密钥解密，因为报文用的是接收方的公开密钥，只有有私有密钥的接收方才能解开

特点是：

  • 优点：安全地将公开密钥传输给发送方
  • 缺点：计算速度慢

8.6.3 混合加密

混合加密也是 HTTPS 采用的加密方式：

  • 使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性
  • 使用对称密钥来通信来保证通信过程的效率

意思就是：

  • 服务器 A 发送自己的公钥给别人
  • 客户端加密它自己的私钥后，发回这个加密的私钥给服务器
  • 这个过程别人偷不了，因为是服务器 A 的公钥，只有服务器 A 自己有私钥
  • 服务器 A 收到加密的私钥后，自己解密，拿到了客户端的私钥
  • 从此就通过这个私钥通信，这是对称的

于是这样，对称密钥只有发送和接收两方获得，从而能进行安全传输，具体的举例流程如下：

8.7 认证

通过认证来解决通信方的身份伪装问题

具体是通过一个客户端和服务器双方都信赖的第三方机构：数字证书认证机构（CA）来完成的

具体流程是：

  • 服务器运营人员 CA 提出公开密钥申请
  • CA 对申请公开密钥做数字签名，分配该签名过的公开密钥，将公开密钥放入公开密钥证书后绑定在一起
  • HTTP 通信，服务器把证书发送给客户端，客户端取得其中的公开密钥，使用数字签名验证，验证通过，可以开始通信

8.8 完整性保护

HTTP 提供了 MD5 报文摘要功能，但报文被篡改，重新计算 MD5 的值，通信接收方是无法意识到发生了篡改的

HTTPS 的完整性保护是由加密和认证结合保证的，一个加密后的报文造到篡改，很难从新计算报文摘要

8.9 认证握手

再进行通信时，必须经过 TLS/SSL 握手，TLS 握手根据不同算法，各不相同，但TLS 基本过程是这样的：

  • 客户端发出请求（CilentHello）
    • 支持的协议版本：例如 TLS 1.0
    • 一个客户端生成的随机数：用于生成私有密钥（对话密钥）
    • 支持的加密方法：例如 RSA 公钥加密
    • 支持的压缩方法
  • 服务器回应（ServerHello）
    • 确定使用的加密通信协议版本：例如 TLS 1.0，若客户端和服务器版本不一样，服务器关闭通信
    • 一个服务器生成的随机数：用于生成私有密钥（对话密钥）
    • 确认使用的加密方法，比如 RSA 公钥加密
    • 服务器证书
  • 客户端回应
    • 一个随机数：用于服务器公钥加密
    • 编码改变通知：表示随后信息使用双方协定的加密方法和密钥发送
    • 客户端握手结束通知
  • 服务器最后回应
    • 编码改变通知：表示随后的信息都将用双方商定的加密方法和密钥发送
    • 服务器握手结束通知：表示服务器的握手阶段已经结束

引用