计算机网络
本文转载自 牛客网计算机网络面试题总结（风雨下钟山）
计算机常用端口
| 应用 | 应用层协议 | 端口号 | 传输层协议 | 备注 |
|---|---|---|---|---|
| 域名解析 | DNS | 53 | UDP/TCP | 长度超过512个字节时，使用 TCP |
| 动态主机配置协议 | DHCP | 67/68 | UDP | |
| 简单网络管理协议 | SNMP | 161/162 | UDP | |
| 文件传输协议 | FTP | 20/21 | TCP | 控制连接 21，数据连接 20 |
| 远程终端协议 | TELNET | 23 | TCP | |
| 超文本传输协议 | HTTP | 80 | TCP | |
| 简单邮件传送协议 | SMTP | 25 | TCP | |
| 邮件读取协议 | POP3 | 110 | TCP | |
| 网际报文存取协议 | IMAP | 143 | TCP |
OSI 与 TCP/IP 各层的结构与功能都有哪些协议
-
应用层（application-layer）：
应用层的任务是通过应用进程间的交互来完成特定网络应用应用层的协议定义的是应用进程之间的通信和交互的规则，对于不同的网络应用，需要不同的应用层协议
在互联网中，应用层的协议很多，如 域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议 等等
进程： 主机中正在运行的程序
应用层交互的数据单元称为报文
-
传输层（transport-layer）：
传输层的主要任务是负责两台主机进程之间的通信，提供通用的数据传输服务应用进程利用该服务传送应用层报文
通用的，指，并不是针对一个特定的网络应用，而是多种应用可以使用同一个传输层服务
由于一台主机可以同时运行多个线程，因此运输层有 复用和分用的功能，复用即指多个应用层进程可以同时使用下面传输层的服务，分用指运输层把收到的信息分别交付上面应用层中的相应进程
传输层主要使用以下两种协议：
传输控制协议TCP（Transmission Control Protocol）：
提供 面向连接的、可靠的 数据传输服务
用户数据协议UDP（User Datagram Protocol）：
提供 无连接的、不可靠的 数据传输服务 -
网络层：
在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网，网络层的任务就是选择合适的网间路由和交换节点，确保数据及时传送
在发送数据时，网络层把传输层产生的报文段或者用户数据报封装成分组和包进行传送
在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报
传输层的 “用户数据报UDP” 与网络层的 “IP数据报” 并不相同，无论那一层的数据单元，都可以笼统地用 “分组” 表示
互联网是由大量的异构网络通过路由器互相连接起来的，互联网的网络层也叫作 网际层或者 IP 层
-
数据链路层（data-link-layer）：
数据链路层，即链路层；两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层协议
在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧
每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制等）
在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层
控制信息还使接收端能够检测到所收到的帧中有无差错。
如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要，可以改正数据在链路层传输时出现的差错（这就是说，数据链路层不仅要检错，而且还要纠错） -
物理层（physical-layer）：
在物理层上传送的数据单位是 比特
物理层的作用是实现相邻计算机节点之间比特流的透明传输，尽可能屏蔽掉具体传输介质和物理设备之间的差异；使其上面的数据链路层不必考虑网络的具体传输介质是什么
为什么会发生 TCP 粘包、拆包
- 应用程序写入的数据大于套接字缓冲区大小，就会发生 拆包
- 应用程序写入的数据小于套接字缓冲区大小，网卡将用多次写入的数据发送到网络上，这将会发生 粘包
- 进行 MSS(最大报文长度) 大小的 TCP 分段，当
TCP 报文长度 - TCP 头部长度 > MSS的时候将发生 拆包 - 接收方不及时读取套接字缓冲区数据，这将发生 粘包
粘包，是指发送方发送的若干包数据到接收方接收时，粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。只有TCP有粘包现象，UDP不会
延伸：如何处理粘包和拆包
常用方法如下：
-
使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容
-
设置定长消息，服务端每次读取既定长度的内容作为一条完整消息，当消息不够长时，空位补上固定字符
-
设置消息边界，服务端从网络流中按消息边界分离出消息内容，一般使用
‘\n ’ -
更为复杂的协议
从输入 URL 到页面加载，发生了什么
总体来说，分为以下几个过程：
- DNS 解析（即，找到 URL 对应的 IP 地址）
- TCP 连接
- 发送 HTTP 请求
- 服务器处理请求并返回 HTTP 报文
- 浏览器解析渲染页面
- 连接结束
HTTP 协议建立在 TCP 协议之上， HTTP 请求之前，需要先进行 TCP 连接，形成客户端到服务器的稳定通道，俗称 TCP的三次握手
TCP 连接完成后，HTTP 请求开始，请求有多种方式，常见的有 GET、POST 等
HTTP 请求包含请求头，也可能包含请求体两部分，请求头中包含我们希望对请求文件的操作的信息，请求体中包含传递给后台的参数
服务器收到 HTTP 请求后，后台开始工作，如负载平衡、跨域等，这里就是后端的工作
文件处理完毕，生成响应数据包，响应也包含两部分，响应头和响应体，响应体就是所请求的文件
经过网络传输，文件被下载到本地客户端，客户端开始加载
客户端浏览器加载了 HTML 文件后，由上到下解析 HTML 为 DOM 树
遇到 CSS 文件，CSS 中的 url 发起 HTTP 请求
这是第二次 HTTP 请求，由于 HTTP1.1 协议增加了Connection: keep-alive 声明，故 TCP 连接不会关闭，可以复用
HTTP 连接是 无状态连接，客户端与服务器端需要重新发起请求–响应。在请求CSS的过程中，解析器继续解析 HTML ，然后到了 script 标签
由于 script 可能会改变 DOM 结构，故解析器停止生成 DOM 树，解析器被 js 阻塞，等待 js 文件发起 HTTP 请求，然后加载。这是第三次HTTP请求。js 执行完成后解析器继续解析
由于 CSS 文件可能会影响 js 文件的执行结果，因此需等 CSS 文件加载完成后再执行
浏览器收到 CSS 文件后，开始解析 CSS 文件为 CSSOM 树（CSS Rule Tree）
CSSOM 树生成后，DOM Tree 与 CSS Rule Tree 结合生成渲染树（Render Tree）
Render Tree 会被 CSS 文件阻塞，渲染树生成后，先布局，绘制渲染树中节点的属性(位置，宽度，大小等)，然后渲染，页面就会呈现信息
继续边解析边渲染，遇到了另一个 js 文件，js 文件执行后改变了 DOM 树，渲染树从被改变的 DOM 开始再次渲染
继续向下渲染，碰到一个 img 标签，浏览器发起 HTTP 请求，不会等待 img 加载完成，继续向下渲染，之后再重新渲染此部分
DOM 树遇到 HTML 结束标签，停止解析，进而渲染结束
GET 和 POST 有什么区别
-
作用：
GET 用于获取资源，而 POST 用于传输数据 -
参数：
GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中 -
安全
GET 方法是安全的，而 POST 却不是安全就是说请求方法不会改变服务器状态，也就是说它只是可读的
因为 POST 的目的是传送数据，这个数据可能是用户上传的表单，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。所以，从这个方面来讲，POST是不安全的 -
幂等：
GET 方法都是幂等的，但 POST 方法不是幂等就是说，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。所以，幂等方法不应该具有副作用
TCP 的三次握手
- 客户端 - 发送带有 SYN 标志的数据包 - 一次握手 - 服务端
- 服务端 - 发送带有 SYN/ACK 标志的数据报 - 二次握手 - 客户端
- 客户端 - 发送带有 ACK 标志的数据包 - 三次握手 - 服务端
延伸：为什么要三次握手
三次握手的目的是建立可靠的通信信道
通讯，简单来说就是数据的发送与接收，而 三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的
第一次握手：Client 什么都不能确认，但是 Server 可以确认对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常，但是 Server 只确认了对方发送正常、自己接收正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常，Server 确认了：自己发送、接收正常，对方发送、接收正常
所以三次握手就能确认双发收发功能都正常，缺一不可
延伸：为什么要传回 SYN
接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了
SYN 是 TCP/IP 建立连接时使用的握手信号
在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK( Acknowledgement [确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误 ] ）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递
延伸：传了 SYN，为什么还要传 ACK
双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证
TCP 四次挥手
断开一个 TCP 连接则需要 “四次挥手”：
- 客户端 - 发送一个 FIN，用来关闭客户端到服务器的数据传送
- 服务器 - 收到这个 FIN，发回一个 ACK，确认序号为收到的序号+1；和 SYN 一样，一个 FIN 将占用一个序号
- 服务器 - 关闭与客户端的连接，发送一个 FIN 给客户端
- 客户端 - 发回 ACK 报文确认，并将确认序号设置为收到序号+1
延伸：为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态；当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接
e.g.
A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束
TCP、UDP 协议的区别
-
UDP
UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等 -
TCP
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务，难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源
TCP 一般用于文件传输、发送和接收邮件、远程登录等场景
TCP 的可靠体现在
TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源
TCP 协议如何保证可靠传输
-
应用数据被分割成 TCP 认为最适合发送的数据块
-
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把 有序数据 传送给应用层
-
校验和： TCP 将保持它首部和数据的检验和。这是一个 端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段
-
TCP 的接收端会丢弃重复的数据
-
流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
-
拥塞控制： 当网络拥塞时，减少数据的发送。
-
ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组
-
超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段
延伸：ARQ 协议是什么
自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。 它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送
ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议
-
停止等待 ARQ 协议
- 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
- 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；
优点： 简单
缺点： 信道利用率低，等待时间长 -
连续 ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了
优点： 信道利用率高，容易实现，即使确认丢失，也不必重传
缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条 消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息
延伸：滑动窗口和流量控制
TCP 利用滑动窗口实现流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率
将窗口字段设置为 0，则发送方不能发送数据
拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫 拥塞
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载
拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷
拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素
相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收
为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个
TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生
-
慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍
-
拥塞避免：
拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1 -
快重传与快恢复：
在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误
当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作
301 和 302 状态码的区别
-
301
301 是永久性重定向( Permanently Moved )，表示一个旧的网址所代表的资源已经被永久地移除了，不能再访问了，并且搜索引擎在获取新的资源的同时也将旧的网址转换为重定向之后的地址 -
302
302 是临时重定向(Temporarily Moved)，这个重定向只是临时地从一个旧的地址跳转到一个新的地址，旧的地址的资源还在，还可以继续访问，搜索引擎会获取资源并保存旧的地址
HTTP 长连接和短连接
在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话
从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。 Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接
HTTP 是不保存状态的协议，如何保存用户状态
HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存
那么我们保存用户状态呢？
Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）
在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪
延伸：Cookie 被禁用怎么办
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面
延伸：Cookie 的作用是什么？和 Session 有什么区别？
Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样
Cookie 一般用来保存用户信息
比如
①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
③登录一次网站后访问网站其他页面不需要重新登录
Session 的主要作用就是通过服务端记录用户的状态
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端
Cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密
HTTP 1.0和HTTP 1.1的主要区别
HTTP1.0 最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而 HTTP1.1 则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议
主要区别主要体现在：
-
长连接 :
在 HTTP/1.0 中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于 TCP/IP 协议的，每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求
HTTP 1.1起，默认使用长连接，默认开启
Connection： keep-alive。 HTTP/1.1 的持续连接有非流水线方式和流水线方式 。流水线方式 是客户在收到 HTTP 的响应报文之前就能接着发送新的请求报文。与之相对应的 非流水线方式 是客户在收到前一个响应后才能发送下一个请求 -
错误状态响应码 :
在 HTTP1.1 中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除
-
缓存处理 :
在 HTTP1.0 中主要使用 header 里的 If-Modified-Since，Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since，If-Match，If-None-Match 等更多可供选择的缓存头来控制缓存策略
-
带宽优化及网络连接的使用 :
HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接
URI 和 URL
URI(Uniform Resource Identifier) 是同一资源标志符，可以唯一标识一个资源
URL(Uniform Resource Location) 是同一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源
URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息
HTTP 与 HTTPS
-
端口 ：
TTP 的 URL 由
“HTTP://”起始且默认使用端口 80
而 HTTPS 的 URL 由“https://”起始且默认使用端口 443 -
安全性和资源消耗：
HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份
HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用 对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源
对称加密：
密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有 DES、AES 等
非对称加密：
密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有 RSA、DSA 等
扫一扫
12万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
