TCP/IP：

TCP/IP 协议实际上是一系列网络通信协议的统称，其中最核心的两个协议是 TCP 和 IP，其他的还有 UDP、ICMP、ARP 等等，共同构成了一个复杂但有层次的协议栈。

TCP/IP 协议，它是 HTTP 协议的下层协议，负责具体的数据传输工作。TCP/IP 协议是一个“有层次的协议栈”。

TCP/IP 网络分层模型：

把复杂的网络通信划分出多个层次，再给每一个层次分配不同的职责，层次内只专心做自己的事情就好，用“分而治之”的思想把一个“大麻烦”拆分成了数个“小麻烦”，从而解决了网络通信的难题。

四层分层层次图：

从下往上看：

• 第一层叫“链接层”（link layer），负责在以太网、WiFi 这样的底层网络上发送原始数据包，工作在网卡这个层次，使用 MAC 地址来标记网络上的设备，所以有时候也叫 MAC 层。（负责数据包在设备（基站、网关、路由器等）之间的传输）
• 第二层叫“网际层”或者“网络互连层”（internet layer），IP 协议就处在这一层。因为 IP 协议定义了“IP 地址”的概念，所以就可以在“链接层”的基础上，用 IP 地址取代 MAC 地址，把许许多多的局域网、广域网连接成一个虚拟的巨大网络，在这个网络里找设备时只要把 IP 地址再“翻译”成 MAC 地址就可以了。（对数据封包从一个ip地址传到另一个ip地址）
• 第三层叫“传输层”（transport layer），这个层次协议的职责是保证数据在 IP 地址标记的两点之间“可靠”地传输，（提供主机到主机之间的通信）是 TCP 协议工作的层次，另外还有它的一个“小伙伴”UDP。TCP 是一个有状态的协议，需要先与对方建立连接然后才能发送数据，而且保证数据不丢失不重复。而 UDP 则比较简单，它无状态，不用事先建立连接就可以任意发送数据，但不保证数据一定会发到对方。两个协议的另一个重要区别在于数据的形式。TCP 的数据是连续的“字节流”，有先后顺序，而 UDP 则是分散的小数据包，是顺序发，乱序收。
• 协议栈的第四层叫“应用层”（application layer），有各种面向具体应用的协议。例如 Telnet、SSH、FTP、SMTP 等等，当然还有 HTTP。（抽象用户数据，提供应用之间的通信）

DNS：

通过IP地址来表示计算机对于计算机来说是比较方便的，当不方便人的使用。所以出现了域名系统。通过有意义的词组来代表无意义的ip地址，方便人们使用。但想要使用 TCP/IP 协议来通信仍然要使用 IP 地址，所以需要把域名做一个转换，“映射”到它的真实 IP，服务器通过真实的IP来找到对应的主机。这就是所谓的“域名解析”。

DNS 的核心系统是一个三层的树状、分布式服务，基本对应域名的结构：

• 根域名服务器（Root DNS Server）：管理顶级域名服务器，返回“com”“net”“cn”等顶级域名服务器的 IP 地址；
• 顶级域名服务器（Top-level DNS Server）：管理各自域名下的权威域名服务器，比如 com 顶级域名服务器可以返回 apple.com 域名服务器的 IP 地址；
• 权威域名服务器（Authoritative DNS Server）：管理自己域名下主机的 IP 地址，比如 apple.com 权威域名服务器可以返回 www.apple.com 的 IP 地址。

DNS解析的过程：

进入页面的时候会进行DNS查询，找到域名对应服务器（主机）的IP地址，再发送请求

比如访问 www.xyz.com

• 首先，会向浏览器缓存查找是否有域名对应的 ip地址，如果有则返回；

• 如果浏览器缓存中没有，则查找本地 hosts文件；

• 如果 hosts文件中没有，则查找本地 DNS 服务器；

• 如果本地 DNS 服务器中也没有，则向根域名服务器查询，根域名服务器会返回 .com的ip地址；

本地DNS服务器根据.com的ip地址到顶级域名服务器查询 xyz.com的ip地址并返回；

本地 DNS 服务器根据 xyz.com的 ip 地址到权威域名服务器查询 www.xyz.com的 ip 地址，到此，域名 ip 地址 找到了，返回给本地 DNS 服务器。

本地 DNS 服务器再将查询到的 ip 地址返回给浏览器，由浏览器根据 ip 地址找到服务器并发送请求。

URI/URL：

有了 TCP/IP 和 DNS，是不是我们就可以任意访问网络上的资源了呢？

还不行，DNS 和 IP 地址只是标记了互联网上的主机，但主机上有那么多文本、图片、页面，所以就出现了 URI（Uniform Resource Identifier），中文名称是 统一资源标识符，使用它就能够唯一地标记互联网上资源。URI 另一个更常用的表现形式是 URL（Uniform Resource Locator）， 统一资源定位符，也就是我们俗称的“网址”，它实际上是 URI 的一个子集，不过因为这两者几乎是相同的，差异不大，所以通常不会做严格的区分。

URI 主要有三个基本的部分构成：

• 协议名：即访问该资源应当使用的协议，如“http”；
• 主机名：即互联网上主机的标记，可以是域名或 IP 地址，如“nginx.org”；
• 路径：即资源在主机上的位置，使用“/”分隔多级目录如“/en/download.html”。

浏览器对URL为什么要解析？URL参数用的是什么字符编码？那encodeURI和encodeURIComponent有什么区别？

1.先进行 URL 解析，看看输入的内容是否符合 URL 规则（解析 URL 提取出协议、域名、端口号，对于一些特殊字符，在传递的时候需要进行编码解码）。

2.URL参数使用UTF-8编码。

3.区别：

• encodeURI、decodeURI可以对中文、空格等编码解码，适用于 URL 本身
• encodeURIComponent、decodeURIComponent范围更广，会编码解码一些特殊字符如 :/?=+@#$,适用于给参数编码解码。

HTTPS:

HTTP 与 HTTPS 有哪些区别？

• HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全⻛险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。【信息加密、校验机制、身份证书】

• HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

• HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。

• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

• https比http慢：正式传输前增加了一个TLS握手环节；产生用于密钥交换的公私钥配对；验证证书；解密（通过非对称加密+数字证书+对称密钥 = 安全+效率）

HTTPS的缺点

（1）除了和TCP连接，发送HTTP请求外，还必须和SSL通信，因此通信慢；

（2）SSL必须进行加密处理，在服务器和客户端都需要进行加密和解密的运算处理，因此更多地消耗硬件资源，导致负载增强；

（3）申请SSL证书需要费用。

SSL中的认证中的数字证书是什么？

通过使用 证书 来对通信方（也就是服务器）进行认证。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向 CA 提出公开密钥的申请注册，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。进行 HTTPS 通信时，服务器会把证书发送给客户端。

客户端取得其中的公开密钥之后，先使用数字签名（提前把CA公钥放入到浏览器或操作系统里）进行验证，如果验证通过，就可以开始通信了。

为什么有的时候刷新页面不需要重新建立 SSL 连接？

TCP 连接有的时候会被浏览器和服务端维持一段时间，TCP 不需要重新建立，SSL 自然也会用之前的。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法：

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。客户端与服务端一共生成三个随机数用于产生会话密钥。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

确保传输安全过程（其实就是rsa原理）： RSA算法：

• Client给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

• Server确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。

• Client确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这三个随机数，生成会话秘钥发给Server。Server使用自己的私钥，对会话秘钥进行解密，就得到与客户端一样的会话秘钥，再用它来加密消息。

Client和Server根据约定的加密方法，使用前面的三个随机数，生成”会话密钥”（session key），用来加密接下来的整个对话过程。

代理

代理（Proxy）是 HTTP 协议中请求方和应答方中间的一个环节，作为“中转站”，既可以转发客户端的请求，也可以转发服务器的应答。 ##代理有很多的种类，常见的有：

• 匿名代理：完全“隐匿”了被代理的机器，外界看到的只是代理服务器；
• 透明代理：顾名思义，它在传输过程中是“透明开放”的，外界既知道代理，也知道客户端；
• 正向代理：靠近客户端，代表客户端向服务器发送请求；
• 反向代理：靠近服务器端，代表服务器响应客户端的请求；上一讲提到的 CDN，实际上就是一种代理，它代替源站服务器响应客户端的请求，通常扮演着透明代理和反向代理的角色。

由于代理在传输过程中插入了一个“中间层”，所以可以在这个环节做很多有意思的事情，比如：

• 负载均衡：把访问请求均匀分散到多台机器，实现访问集群化；
• 内容缓存：暂存上下行的数据，减轻后端的压力；
• 安全防护：隐匿 IP, 使用 WAF 等工具抵御网络攻击，保护被代理的机器；
• 数据处理：提供压缩、加密等额外的功能。