一、思维导图

二、应用层功能

应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。

应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。

主要功能总结如下：

• WWW 万维网
• 电子邮件 SMTP、POP3、IMAP
• 文件传输 FTP
• 远程传输 TALENT、SSH
• 网络管理 SNMP

三、网络应用模型

1. 客户/服务器模型 C/S

服务器：对外提供服务

• 24小时提供服务
• 永久性访问地址/域名
• 大量服务器实现可扩展性

客户机：获取服务

• 间歇性接入网络
• 可能使用动态IP地址
• 不会与其他客户机直接通信

典型的 C/S 结构：Web

2. P2P模型 Peer to Peer

• 没有永远在线的服务器
• 每个主机既可以提供服务，也可以请求服务
• 任意端系统/节点之间可以直接通讯
• 节点间歇性接入网络
• 节点可能改变IP地址

典型的 P2P 结构：文件共享

优点：高度可伸缩

缺点：难以管理

四、域名解析系统 DNS

域名系统(Domain Name System缩写 DNS，Domain Name被译为域名)是因特网的一项核心服务，它作为可以将域名和IP地址相互映射的一个分布式数据库 (这里的分布式数据库是指，每个站点只保留它自己的那部分数据)，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 地址。

域名具有层次结构，从上到下依次为：根域名、顶级域名、二级域名。

DNS 可以使用 UDP 或者 TCP 进行传输，使用的端口号都为 53。

大多数情况下 DNS 使用 UDP 进行传输，这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

在两种情况下会使用 TCP 进行传输：

• 如果返回的响应超过的 512 字节（UDP 最大只支持 512 字节的数据）。
• 区域传送（区域传送是主域名服务器向辅助域名服务器传送变化的那部分数据）。

域名解析方式：

• 递归查询（比较少用，靠别人）
• 迭代查询（靠自己）

基本原理：

• 浏览器搜索自己的DNS缓存，缓存中维护一张域名与IP地址的对应表；

• 若没有，则搜索操作系统的DNS缓存；

• 若没有，则操作系统将域名发送至本地域名服务器（递归查询方式），本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则，通过以下方式迭代查找：

  本地域名服务器向根域名服务器发起请求，根域名服务器返回com域的顶级域名服务器的地址；

  本地域名服务器向com域的顶级域名服务器发起请求，返回权限域名服务器地址；

  本地域名服务器向权限域名服务器发起请求，得到IP地址；

• 本地域名服务器将得到的IP地址返回给操作系统，同时自己将IP地址缓存起来；

• 操作系统将IP地址返回给浏览器，同时自己也将IP地址缓存起来；

至此，浏览器已经得到了域名对应的IP地址。

五、文件传送协议 FTP

FTP提供不同种类主机之间的文件传输能力

FTP 使用 TCP 进行连接，实现可靠传输，它需要两个连接来传送一个文件：

• 控制连接：服务器打开端口号 21 等待客户端的连接，客户端主动建立连接后，使用这个连接将客户端的命令传送给服务器，并传回服务器的应答。
• 数据连接：用来传送一个文件数据，数据传输使用端口号 20

六、电子邮件协议

1. 简单邮件传送协议 SMTP

SMTP 只能发送 ASCII 码，而互联网邮件扩充 MIME 可以发送二进制文件。

MIME 并没有改动或者取代 SMTP，而是增加邮件主体的结构，定义了非 ASCII 码的编码规则。

SMT通信三个阶段：

• 连接建立
• 邮件传送
• 连接释放

2. 邮局协议 POP3

POP3用来接收邮件

特点是只要用户从服务器上读取了邮件，就把该邮件删除。但最新版本的 POP3 可以不删除邮件。

3. 网际报文存取协议 IMAP

IMAP用来接收邮件。

IMAP 协议中客户端和服务器上的邮件保持同步，如果不手动删除邮件，那么服务器上的邮件也不会被删除。IMAP 这种做法可以让用户随时随地去访问服务器上的邮件。

七、动态主机配置协议 DHCP

DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的连网方式，用户不再需要手动配置 IP 地址等信息。DHCP 配置的内容不仅是 IP 地址，还包括子网掩码、网关 IP 地址。

目的：动态调整，按需分配IP地址给希望上网的用户机。

原理：地址分配服务器维护IP地址池，希望上网的用户向其申请IP地址，使用后释放IP地址，提高地址利用率

DHCP 是基于 UDP 的，客户和服务器之间采用 广播 形式进行交互

八、HTTP 协议

1. URI

URI 包含 URL 和 URN。

2. 了解HTTP

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的 WWW（万维网） 文件都必须遵守这个标准。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。

超文本指的是HTML，CSS，JavaScript和图片等，HTTP的出现是为了接收和发布HTML页面，经过不断的发展也可以用于接收一些音频，视频，文件等内容。

HTTP协议是用于客户端和服务器端之间的通信，用于客户端和服务器端之间的通信有HTTP协议和TCP/IP协议族在内的其他众多的协议。

请求访问文本或图片等资源的一方，我们叫做客户端；负责接收，提供响应的一方称为服务器端。

Client客户端请求Server服务端，Server服务端响应给Client客户端。HTTP是基于客户端/服务端的架构模型，浏览器或其他任何客户端都可以用HTTP协议的，通过URL地址向HTTP的服务器即Web服务器发送所有请求，Web服务器端在接收到请求后会做出反应，响应给对方，就是向客户端回传响应的信息。

注意：在使用HTTP协议的时候，我们一端必定是客户端，另一端必定是服务器端。

3. HTTP协议特点

• 支持客户/服务器模式。
• 基于请求/响应模型的协议。请求和响应必须成对，先有请求后有响应
• 默认使用80端口（HTTPS使用443端口）
• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，如果服务器不需要前面已处理过的信息，它的应答速度就较快。

4. HTTP协议的版本

• HTTP/1.0：发送请求，创建一次连接，获得一个web资源，连接断开
• HTTP/1.1：发送请求，创建一次连接，获得多个web资源，连接断开

HTTP1.1新特性：详细内容见下文

• 默认是长连接
• 支持流水线
• 支持同时打开多个 TCP 连接
• 支持虚拟主机
• 新增状态码 100
• 支持分块传输编码
• 新增缓存处理指令 max-age

5. HTTP协议的组成

Http协议由 Http 请求和 Http 响应组成

当在浏览器中输入网址访问某个网站时， 你的浏览器会将你的请求封装成一个Http请求发送给服务器站点，服务器接收到请求后会组织响应数据封装成一个 Http 响应返回给浏览器。即没有请求就没有响应。

a. HTTP请求报文

HTTP请求报文由3部分组成（请求行+请求头+请求体）：

• 请求行 必须在http请求格式的第一行。
• 请求头 从第二行开始，到第一个空行结束。请求头和请求体之间存在一个空行
• 请求体 通常以键值对 {key:value}方式传递数据。

① HTTP请求方法

• GET 获取资源

  • 将请求参数追加在 url 后面，不安全；

  • url 长度限制 get 请求方式数据的大小；

  • 没有请求体；

  • 一般的 HTTP 请求大多都是 GET。

• HEAD 获取报文首部

  和 GET 方法类似，但是不返回报文实体主体部分。

  主要用于确认 URL 的有效性以及资源更新的日期时间等。

• POST 传输实体主体

  POST 主要用来传输数据，而 GET 主要用来获取资源。（RESTful 风格）

  • 请求参数在请求体处，较安全。

  • 请求数据大小没有显示

  • 只有表单设置为 method=“post” 才是 post 请求，其他都是 get 请求

  • （常见 get 请求:地址栏直接访问、<a href="">、<img src="">等）

• PUT 上传文件

  • 把一个资源存放在指定的位置上。

  • 本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。

  • 由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

• PATCH 对资源进行部分修改

  PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

• DELETE 删除文件

  与 PUT 功能相反，并且同样不带验证机制。

• OPTIONS 查询支持的方法

  用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。

• CONNECT 要求在与代理服务器通信时建立隧道

  使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信

  内容加密后经网络隧道传输。

  1	CONNECT www.example.com:443 HTTP/1.1

• TRACE 追踪路径

  服务器会将通信路径返回给客户端。

  发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

② HTTP 请求头属性

以下列出常见请求头：

• Referer：表示这个请求是从哪个url跳过来的,通过百度来搜索淘宝网,那么在进入淘宝网的请求报文中,Referer的值就是:www.baidu.com。如果是直接访问就不会有这个头。常用于: 防盗链。

• Accept：告诉服务端,该请求所能支持的响应数据类型,专业术语称为MIME 类型(文件类型的一种描述方式)

  1	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

• if-Modified-Sincce：浏览器通知服务器，本地缓存的最后变更时间。

• Cookie：**客户端的Cookie就是通过这个报文头属性传给服务端的！

  1	Cookie: ``JSESSIONID``=15982C27F7507C7FDAF0F97161F634B5

• User-Agent：浏览器通知服务器，客户端浏览器与操作系统相关信息

• Connection：**表示客户端与服务连接类型；Keep-Alive表示持久连接，close已关闭

• Host：请求的服务器主机名

• Content-Length：请求体的长度

• Content-Type：请求的与实体对应的MIME信息。如果是post请求,会有这个头,默认值为application/x-www-form-urlencoded，表示请求体内容使用url编码

• Accept-Encoding：浏览器通知服务器，浏览器支持的数据压缩格式。如GZIP压缩

  1	Accept-Encoding: gzip, deflate

• Accept-Language：浏览器通知服务器，浏览器支持的语言。各国语言(国际化i18n)

• Cache-Control：指定请求和响应遵循的缓存机制。对缓存进行控制，如一个请求希望响应返回的内容在客户端要被缓存一年，或不希望被缓存就可以通过这个报文头达到目的。

  1	Cache-Control: no-cache

③ 请求体

当请求方式是 post 的时，请求体会有请求的参数，格式如下：

1
2
3
4
5
6
7

username=zhangsan&password=123
POST http://39.108.107.149:8080/vk/app/rest/ddp/iModelServiceImpl/findModelByType HTTP/1.1
User-Agent: Fiddler
Host: 39.108.107.149:8080
Content-Length: 20
 
username=zhangsan&password=123

b. HTTP响应报文

HTTP的响应报文也由三部分组成（响应行+响应头+响应体）

① 响应行

响应行包括

• 报文协议及版本；

  例如：

  1	HTTP/1.1 200 OK

• 状态码及状态描述；

  状态码：由3位数字组成，第一个数字定义了响应的类别。响应码详细如下。

② 状态码

• 1xx：指示信息，表示请求已接收，继续处理

• 2xx：成功，表示请求已被成功接受，处理。

  • 200 OK：客户端请求成功

  • 204 No Content：无内容。服务器成功处理，但未返回内容。一般用在只是客户端向服务器发送信息，而服务器不用向客户端返回什么信息的情况。不会刷新页面。

  • 206 Partial Content：服务器已经完成了部分GET请求（客户端进行了范围请求）。响应报文中包含Content-Range指定范围的实体内容

• 3xx：重定向

  • 301 Moved Permanently：永久重定向，表示请求的资源已经永久的搬到了其他位置。

  • 302 Found：临时重定向，表示请求的资源临时搬到了其他位置

  • 303 See Other：临时重定向，应使用GET定向获取请求资源。303功能与302一样，区别只是303明确客户端应该使用GET访问

  • 304 Not Modified：表示客户端发送附带条件的请求（GET方法请求报文中的IF…）时，条件不满足。返回304时，不包含任何响应主体。虽然304被划分在3XX，但和重定向一毛钱关系都没有

  • 307 Temporary Redirect：临时重定向，和302有着相同含义。POST不会变成GET

• 4xx：客户端错误

  • 400 Bad Request：客户端请求有语法错误，服务器无法理解。

  • 401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。

  • 403 Forbidden：服务器收到请求，但是拒绝提供服务

  • 404 Not Found：请求资源不存在。比如，输入了错误的url

  • 415 Unsupported media type：不支持的媒体类型

• 5xx：服务器端错误，服务器未能实现合法的请求。

  • 500 Internal Server Error：服务器发生不可预期的错误。

  • 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常

③ 响应头

响应头也是用键值对 k：v

服务器通过响应头来控制浏览器的行为，不同的头浏览器操作不同

④ Content-Type 详解

响应正文的类型：

⑤ 响应体

响应体，响应体是服务器回写给客户端的页面正文，浏览器将正文加载到内存，然后解析渲染显示页面内容

6. 连接管理

① 长连接和短连接

长连接也称持久连接，短连接也称非持久连接

在HTTP/1.0中默认使用非持久连接 close (短连接)。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。

从HTTP/1.1起，默认使用持久连接 keep-alive (长连接)，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

• TCP短连接
  模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。
  短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
• TCP长连接
  我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

② 流水线

默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟。

7. Cookie

① 用途

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

② 创建过程

服务器发送的响应报文包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中。

1
2
3
4
5
6

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[page content]

客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。

1
2
3

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

③ 分类

• 会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
• 持久性 Cookie：指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。

8. Session

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

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

使用 Session 维护用户登录状态的过程如下：

• 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
• 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
• 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

应该注意 Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

典型的 Session 应用比如购物车，通过为每个用户分配一个唯一的 Session ID来唯一标识这个用户。

① 浏览器禁用Cookie

此时无法使用 Cookie 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

② Cookie和Session的选择

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
• Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
• 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

9. 打开一个网页，整个过程会使用哪些协议

回顾一下这三个概念：物理(MAC)地址，IP地址，域名

• 连入Internet的每台主机至少有一个全网唯一的IP地址，是由数码表示的主机逻辑地址。

• 域名是Internet中为每台主机所取的一个具有一定含义又便于记忆的名字。

• MAC地址是安装在主机网卡（网络适配器）上的地址。

域名与IP地址之间的映射称为域名解析。

IP地址与物理地址之间的映射称为地址解析。

在Internet应用中，人们使用的是方便、易记的域名，为了将信息发送到对方的主机上，就必须先把域名映射为IP地址，然后把IP地址映射为相应的物理地址，从而通过物理链路进行传输.

• 应用层：首先通过DNS协议进行域名解析，具体过程如下：

  • 浏览器搜索自己的DNS缓存，缓存中维护一张域名与IP地址的对应表；

  • 若没有，则搜索操作系统的DNS缓存；

  • 若没有，则操作系统将域名发送至本地域名服务器（递归查询方式），本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则，通过以下方式迭代查找：

    本地域名服务器向根域名服务器发起请求，根域名服务器返回com域的顶级域名服务器的地址；

    本地域名服务器向com域的顶级域名服务器发起请求，返回权限域名服务器地址；

    本地域名服务器向权限域名服务器发起请求，得到IP地址；

  • 本地域名服务器将得到的IP地址返回给操作系统，同时自己将IP地址缓存起来；

  • 操作系统将IP地址返回给浏览器，同时自己也将IP地址缓存起来；

  至此，浏览器已经得到了域名对应的IP地址。

• 浏览器发送HTTP请求；

• 接下来到了传输层，TCP三次握手建立连接；

• 接下来到来网络层，建立TCP连接时需要传送数据，传送数据在网络层使用 IP协议，通过IP协议将IP地址封装为IP数据报；

  IP数据报在路由器之间进行传送的时候，需要使用路由选择协议OSPF；

  路由器在与服务器通信的时候，需要将IP地址转换为MAC地址，此时就需要使用ARP协议；主机发送信息时将包含目标IP地址，将ARP请求广播到网络上的所有主机，并接收返回消息，以此确定目标的物理地址，找到目的MAC地址；

• 接下来到了数据链路层，把网络层交下来的IP数据报添加首部和尾部，封装为MAC帧，现在根据目的MAC地址开始建立TCP连接，三次握手，接收端在收到物理层上交的比特流后，根据首尾的标记，识别帧的开始和结束，将中间的数据部分上交给网络层，然后层层向上传递到应用层；

• 服务器响应浏览器发送的HTTP请求并请求客户端要的资源，传回给客户端；

• 断开TCP连接，浏览器通过HTTP协议对页面进行渲染呈现给客户端。

总结以上过程，用到的协议依次为：

DNS ——> HTTP ——> TCP ——> IP ——> OSPF ——>ARP

10. HTTP 断点续传

概念：断点续传指的是下载传输文件可以中断，之后重新下载时可以接着中断的地方开始下载，而不必从头开始下载。断点续传需要客户端和服务端都支持。

原理：原理是客户端一块一块的请求数据，最后将下载回来的数据块拼接成完整的数据。其实就是在Http的请求上和一般的下载有所不同而已。

打个比方，浏览器请求服务器上的一个服务，所发出的请求如下：

假设服务器域名为 www.baidu.com，文件名为down.zip。

1
2
3
4
5
6
7

GET /down.zip HTTP/1.1 
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- 
excel, application/msword, application/vnd.ms-powerpoint, */* 
Accept-Language: zh-cn 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) 
Connection: Keep-Alive

服务器收到请求后，按要求寻找请求的文件，提取文件的信息，然后返回给浏览器，返回信息如下：

1
2
3
4
5
6
7
8

200 
Content-Length=106786028 
Accept-Ranges=bytes 
Date=Mon, 30 Apr 2001 12:56:11 GMT 
ETag=W/"02ca57e173c11:95b" 
Content-Type=application/octet-stream 
Server=Microsoft-IIS/5.0 
Last-Modified=Mon, 30 Apr 2001 12:56:11 GMT

所谓断点续传，也就是要从文件已经下载的地方开始继续下载。所以在客户端浏览器传给
Web服务器的时候要多加一条信息 – 从哪里开始。 比如要求从2000070字节开始。

1
2
3
4

GET /down.zip HTTP/1.0 
User-Agent: NetFox 
RANGE: bytes=2000070- 
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

仔细看一下就会发现多了一行 RANGE: bytes=2000070-

这一行的意思就是告诉服务器down.zip这个文件从2000070字节开始传，前面的字节不用传了。

服务器收到这个请求以后，返回的信息如下：

1
2
3
4
5
6
7
8

206 
Content-Length=106786028 
Content-Range=bytes 2000070-106786027/106786028 
Date=Mon, 30 Apr 2001 12:55:20 GMT 
ETag=W/"02ca57e173c11:95b" 
Content-Type=application/octet-stream 
Server=Microsoft-IIS/5.0 
Last-Modified=Mon, 30 Apr 2001 12:55:20 GMT

和前面服务器返回的信息比较一下，就会发现增加了一行：

Content-Range=bytes 2000070-106786027/106786028

返回的代码也改为 206 了，而不再是 200 了。

九、HTTPS 协议

HTTP 有以下安全性问题：

• 使用明文进行通信，内容可能会被窃听；
• 不验证通信方的身份，通信方的身份有可能遭遇伪装；
• 无法证明报文的完整性，报文有可能遭篡改。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

SSL，(Secure Socket Layer 安全套接字层)，为Netscape(网景公司)所研发，用以保障在Internet上数据传输之安全。SSL目前有三个版本，SSL1.0、SSL2.0、SSL3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。
SSL利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。SSL支持各种应用层协议。由于SSL位于应用层和传输层之间，所以可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

1. 加密

① 对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

• 优点：运算速度快；
• 缺点：无法安全地将密钥传输给通信方。

如果通信双方都各自持有同一个密钥，且没有别人知道，则两方的通信安全是可以被保证的（除非密钥被破解）。
然而，最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，这个传输过程中密钥被别人劫持，之后他就能用密钥解开双方传输的任何内容。

如果浏览器内部预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的。这样，浏览器只要预存好世界上所有HTTPS网站的密钥就可以了。显然，这样做是不现实的。
怎么办？解决这个问题，我们就需要非对称加密。

② 非对称密钥加密

基于对称加密存在的问题，又有了非对称加密。

非对称加密算法需要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容需要对应的私钥解密，私钥加密的内容需要对应的公钥解密。

私钥由服务器自己保存，公钥发送给客户端。客户端拿到公钥后可以对请求进行加密后发送给服务端，这时候就算中间被截获，没有私钥也无法解密发送的内容，这样确保了客户端发送到服务端数据的安全。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

• 优点：可以更安全地将公开密钥传输给通信发送方；
• 缺点：运算速度慢。

③ HTTPS加密方式（对称 + 非对称）

既然非对称加密耗时，我们考虑是否可以采用非对称加密+对称加密结合的方式，而且要尽量减少非对称加密的次数。
非对称加密、解密各只需一次的方法：

• 某网站拥有用于非对称加密的公钥A1、私钥A2。

• 浏览器向网站服务器请求，服务器把公钥A1明文给传输浏览器。

• 浏览器随机生成一个用于对称加密的密钥X，用公钥A1加密后传给服务器。

• 服务器拿到后用私钥A2解密得到密钥X。

• 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密即可。

相当于对称加密明文信息，非对称加密密钥

HTTPS基本就是采用了这种方案。但还是有漏洞的。

2. 中间人攻击

中间人的确无法得到浏览器生成的对称密钥X，这个密钥本身被公钥A1加密，只有服务器才能用私钥A2进行解密。然而中间人却完全不需要拿到私钥A2就能劫持信息：

• 某网站拥有用于非对称加密的公钥A1、私钥A2。

• 浏览器向网站服务器请求，服务器把公钥A1明文传输给浏览器。

• 中间人劫持到公钥A1，保存下来，把数据包中的公钥A1替换成自己伪造的公钥B1（它当然也拥有公钥B1对应的私钥B2）。

• 浏览器随机生成一个用于对称加密的密钥X，用公钥B1（浏览器不知道公钥被替换了）加密后传给服务器。

• 中间人劫持后用私钥B2解密得到密钥X，再用公钥A1加密后传给服务器。

• 服务器拿到后用私钥A2解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人得到了对称密钥X。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。那么下一步就是解决这个问题：如何证明浏览器收到的公钥一定是该网站的公钥？

3. 数字证书

现实生活中，如果想证明某身份证号一定是小明的，怎么办？看身份证。这里政府机构起到了“公信”的作用，身份证是由它颁发的，它本身的权威可以对一个人的身份信息作出证明。互联网中也有这么一个公信机构，CA 机构。
网站在使用HTTPS前，需要向“CA机构”申请颁发一数字证书，数字证书里有证书持有者、证书持有者的公钥等信息。服务器把证书传输给浏览器，浏览器从证书里取公钥就可以了。然而这里又有一个显而易见的问题：证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？数字证书怎么防伪呢？

4. 数字签名

把要传送的明文信息通过 hash 算法得出 摘录信息 MIC（摘录技术），再用私钥对 MIC 值 进行加密得到数字签名

数字签名的制作过程：

• CA拥有非对称加密的私钥和公钥。

• CA对证书明文信息进行hash。

• 对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

浏览器验证过程：

• 拿到证书，得到明文T1，数字签名S1。
• 用CA机构的公钥对S1解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S2。
• 用证书里说明的hash算法对明文T1进行hash得到T2。
• 比较S2是否等于T2，等于则表明证书可信。

关于数字签名推荐阅读这篇漫画图解 👉 分分钟理解什么是数字签名