网络

一、HTTP 协议

1. GET / POST

GET 参数通过 url 传递，post 放在 request body 中。
GET 请求在 url 中传递的参数是有长度限制的（2083 字节(2K+35)），而 POST 没有。(是特定的浏览器及服务器对它的限制)
GET 比 POST 更不安全，因为参数直接暴露在 url 中，所以不能用来传递敏感信息。
POST 的参数传递支持更多的数据类型
GET 请求只能进行 url 编码，而 POST 支持多种编码方式
GET 请求会浏览器主动缓存，而 POST 不会。
GET 请求参数会被完整保留在浏览历史记录里，而 POST 中的参数不会被保留。
GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

应用场景：
- GET 多用于无副作用，幂等的场景，例如搜索关键字。
- POST 多用于副作用，不幂等的场景，例如注册
- 副作用：对服务器上的资源做改变
- 幂等：发送 M 和 N 次请求（两者不相同且都大于 1），服务器上资源的状态一致
是否缓存：因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存
发送的报文格式：Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
安全性：Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
参数类型：post 的参数传递支持更多的数据类型

2. POST / PUT

PUT 请求是向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次 PUT 操作，其结果并没有不同。（可以理解为时更新数据）
POST 请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）

3. 请求报文

一个 HTTP 请求报文由请求行（request line）、请求头（header）、空行和请求数据 4 个部分组成

请求行组成

如：GET /index.html HTTP/1.1

请求方法
URL
协议版本

常见请求方法

GET: 向服务器获取数据；
POST：将实体提交到指定的资源，通常会造成服务器资源的修改；
PUT：上传文件，更新数据；
DELETE：删除服务器上的对象；
HEAD：获取报文首部，与 GET 相比，不返回报文主体部分；
OPTIONS：询问支持的请求方法，用来跨域请求；
CONNECT：要求在与代理服务器通信时建立隧道，使用隧道进行 TCP 通信；
TRACE: 回显服务器收到的请求，主要⽤于测试或诊断；
PATCH：对资源进行部分修改；

OPTIONS 请求方法及使用场景

OPTIONS 是除了 GET 和 POST 之外的其中一种 HTTP 请求方法。

OPTIONS 方法是用于请求获得由 Request-URI 标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。该请求方法的响应不能缓存。

OPTIONS 请求方法的主要用途有两个：

获取服务器支持的所有 HTTP 请求方法；
用来检查访问权限。例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。

常见请求头

Accept：客户端可识别的内容类型列表（浏览器的用户代理字符串）
Accept-Charset:浏览器能够显示的字符集
Accept-Encoding：浏览器能够处理的压缩编码
Accept-Language：浏览器当前设置的语言
Connection：浏览器与服务器之间连接的类型
Content-Type：请求体的 MIME 类型（用于 POST 和 PUT 请求中）。如：Content-Type: application/x-www-form-urlencoded
Cookie：当前页面设置的任何 Cookie
Host：请求的主机名，允许多个域名同处一个 IP 地址，即虚拟主机
Referer：发出请求的页面的 URL
User-Agent：产生请求的浏览器类型。

4. 响应报文

包括：响应行（ HTTP/1.1 200 OK ）、响应头、空行、响应正文

常见相应头

Date：表示消息发送的时间，时间的描述格式由 rfc822 定义
server:服务器名称
Connection：浏览器与服务器之间连接的类型
Cache-Control：控制 HTTP 缓存
content-type:表示后面的文档属于什么 MIME 类型

content-type 常见类型：

application/x-www-form-urlencoded：浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。该种方式提交的数据放在 body 里面，数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。
multipart/form-data：该种方式也是一个常见的 POST 提交方式，通常表单上传文件时使用该种方式。
application/json：服务器消息主体是序列化后的 JSON 字符串。
text/xml：该种方式主要用来提交 XML 格式的数据。

5. 优/缺点

超文本传输协议（hypertext transfer protocol），连接客户端，网关和服务器，HTTP 是一个基于 TCP/IP 通信协议来传递数据

优点：

支持客户端/服务器模式
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
无连接：无连接就是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。（可通过设置自身属性 Keep-Alive 解决）
无状态：HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能会导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就比较快。（只能通过 cookie 和 session 来做贮存）
灵活（媒体独立）：只要客户端和服务器知道如何处理的数据内容，HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。

缺点：

无状态：HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。
明文传输：协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。
不安全
- 通信使用明文（不加密），内容可能会被窃听；
- 不验证通信方的身份，因此有可能遭遇伪装；
- 无法证明报文的完整性，所以有可能已遭篡改；

6. HTTP 1.1

连接方面，http1.0 默认使用非持久连接，而 http1.1 默认使用持久连接。http1.1 通过使用持久连接(管道 pipeline 网络传输)来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
资源请求方面，在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
缓存方面，在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
http1.1 中新增了 host 字段，用来指定服务器的域名。http1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。因此有了 host 字段，这样就可以将请求发往到同一台服务器上的不同网站。
http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT、HEAD、OPTIONS 等。

7. HTTP 2.0

二进制协议：HTTP/2 是一个二进制协议。在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。帧的概念是它实现多路复用的基础。
多路复用：HTTP/2 实现了多路复用，HTTP/2 仍然复用 TCP 连接，但是在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，这样就避免了"队头堵塞"的问题。
*在 HTTP 1 下，浏览器对一个域名下最大 TCP 连接数为 6，可以用多域名部署解决，这样可以提高同时请求的数目。
数据流：HTTP/2 使用了数据流的概念，因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。因此，必须要对数据包做标记，指出它属于哪个请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。
头信息压缩：HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。
服务器推送：HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。使用服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。这里需要注意的是 http2 下服务器主动推送的是静态资源，和 WebSocket 以及使用 SSE 等方式向客户端发送即时数据的推送是不同的。

8. Keep-Alive

HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用 Keep-Alive 模式时，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接，这就是长连接。其使用方法如下：

HTTP1.0 版本是默认没有 Keep-alive 的（也就是默认会发送 keep-alive），所以要想连接得到保持，必须手动配置发送 Connection: keep-alive 字段。若想断开 keep-alive 连接，需发送 Connection:close 字段；
HTTP1.1 规定了默认保持长连接，数据传输完成了保持 TCP 连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送 Connection：close 首部字段。

优点：

较少的 CPU 和内存的使⽤（由于同时打开的连接的减少了）；
允许请求和应答的 HTTP 管线化；
降低拥塞控制（TCP 连接减少了）；
减少了后续请求的延迟（⽆需再进⾏握⼿）；
报告错误⽆需关闭 TCP 连；

缺点：

长时间的 Tcp 连接容易导致系统资源无效占用，浪费系统资源。

9. 头部压缩算法

HTTP2 的头部压缩是HPACK 算法。在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，采用哈夫曼编码来压缩整数和字符串，可以达到 50%~90%的高压缩率。

具体来说:

在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在 HTTP/2 的连接存续期内始终存在，由客户端和服务器共同渐进地更新；
每个新的首部键值对要么被追加到当前表的末尾，要么替换表中之前的值

例如下图中的两个请求，请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。

头部压缩

10. 队头堵塞

队头阻塞是由 HTTP 基本的“请求 - 应答”模型所导致的。HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

解决方案

并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。
域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

11. HTTP 3.0

TCP 改基于 UDP 的 QUIC，新增功能：多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等

HTTP3

流量控制、传输可靠性功能：QUIC 在 UDP 的基础上增加了一层来保证数据传输可靠性，它提供了数据包重传、拥塞控制、以及其他一些 TCP 中的特性。
集成 TLS 加密功能：目前 QUIC 使用 TLS1.3，减少了握手所花费的 RTT 数。
多路复用：同一物理连接上可以有多个独立的逻辑数据流，实现了数据流的单独传输，解决了 TCP 的队头阻塞问题。
快速握手：由于基于 UDP，可以实现使用 0 ~ 1 个 RTT 来建立连接

特性：

连接迁移 tcp 里面的四元组，一条 tcp 的唯一性标识，是由源 IP，源端口，目的 IP,目的端口，四元组标识。源 IP，源端口一般比较稳定，但是目的 IP,目的端口会由于网络元素等原因发生改变，一旦改变，那么此条 tcp 连接就会断开。由于 QUIC 基于 UDP 协议，所以一条 UDP 协议不再由四元组标识，而是以客户端随机产生的一个 64 位数字作为 ID 标识。只要 ID 不变，那么这条 UDP 就会存在，维持连接，上层业务逻辑就感受不到变化。
无队头阻塞 http2.0 的多路复用正好解决了 http 层的队头阻塞，但是 tcp 的队头阻塞依然存在。因为当数据包超时确认或者丢失，会等待重传，因此会阻塞当前窗口向右滑动，造成阻塞。而 QUIC 是基于 udp 的，创新点在于 QUIC 依靠一个严格的单调递增的 packet 序列，一个数据包里面还会有 streamID 和 streamoffset 偏移量，即使中途发生丢包或者超时确认，后面的数据包不会等待，等到接收完之后根据 ID 和 offset 即可完成重新拼装，从而避免了这种问题
自定义的佣塞控制 tcp 协议是在传输层，默认存在于系统中，而 QUIC 在应用层，当想要依据实际情况来重定义拥塞算法的时候，QUIC 显然更加灵活。Google 提出了 cubic 和 newreno 提供了许多可供编程的接口。当然，和 tcp 一样，也是默认采用 cubic 算法。
前向安全和前向纠错 Google 给 QUIC 加上了这个机制：每发送一组数据之后，就对这组数据进行异或运算（效率高），并将结果也发送出去，那么接收方就有两份数据版本，可以对初始数据进行纠错和校验。以此保证了可靠性。

二、HTTPS 协议

1. 理解

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。

HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS

HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

安全层的主要职责就是对发起的 HTTP 请求的数据进行加密操作 和 对接收到的 HTTP 的内容进行解密操作

区别：

HTTPS 使用 443 端口，而 HTTP 使用 80
HTTPS 需要申请 SSL 证书，功能越强大的证书费用越高，且需要绑定 IP，不能再同一个 IP 上绑定多个域名
HTTP 是超文本传输协议，是明文传输；HTTPS 是经过 SSL 加密的协议，传输更安全
HTTPS 比 HTTP 慢，因为 HTTPS 除了 TCP 握手的三个包，还要加上 SSL 握手的九个包，增加页面的加载时间
HTTPS 需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂，支持访客稍多的网站需要投入更大的成本

2. TLS/SSL 的工作原理

TLS/SSL 全称安全传输层协议（Transport Layer Security）, 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

TLS/SSL 的功能实现主要依赖三类基本算法：散列函数 hash、对称加密、非对称加密。这三类算法的作用如下：

基于散列函数验证信息的完整性
对称加密算法采用协商的秘钥对数据加密
非对称加密实现身份认证和秘钥协商

TLS/SSL

散列函数 hash

常见的散列函数有MD5、SHA1、SHA256。该函数的特点是单向不可逆，对输入数据非常敏感，输出的长度固定，任何数据的修改都会改变散列函数的结果，可以用于防止信息篡改并验证数据的完整性。

特点：在信息传输过程中，散列函数不能三都实现信息防篡改，由于传输是明文传输，中间人可以修改信息后重新计算信息的摘要，所以需要对传输的信息和信息摘要进行加密。

对称加密

对称加密的方法是，双方使用同一个秘钥对数据进行加密和解密。但是对称加密的存在一个问题，就是如何保证秘钥传输的安全性，因为秘钥还是会通过网络传输的，一旦秘钥被其他人获取到，那么整个加密过程就毫无作用了。这就要用到非对称加密的方法。

常见的对称加密算法有 AES-CBC、DES、3DES、AES-GCM 等。相同的秘钥可以用于信息的加密和解密。掌握秘钥才能获取信息，防止信息窃听，其通讯方式是一对一。

特点：对称加密的优势就是信息传输使用一对一，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录且不能修改密码。

非对称加密

非对称加密的方法是，我们拥有两个秘钥，一个是公钥，一个是私钥。公钥是公开的，私钥是保密的。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。我们可以将公钥公布出去，任何想和我们通信的客户，都可以使用我们提供的公钥对数据进行加密，这样我们就可以使用私钥进行解密，这样就能保证数据的安全了。但是非对称加密有一个缺点就是加密的过程很慢，因此如果每次通信都使用非对称加密的方式的话，反而会造成等待时间过长的问题。

常见的非对称加密算法有 RSA、ECC、DH 等。秘钥成对出现，一般称为公钥（公开）和私钥（保密）。公钥加密的信息只有私钥可以解开，私钥加密的信息只能公钥解开，因此掌握公钥的不同客户端之间不能相互解密信息，只能和服务器进行加密通信，服务器可以实现一对多的的通信，客户端也可以用来验证掌握私钥的服务器的身份。

特点：非对称加密的特点就是信息一对多，服务器只需要维持一个私钥就可以和多个客户端进行通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密的速度慢。

综合上述算法特点，TLS/SSL 的工作方式就是客户端使用非对称加密与服务器进行通信，实现身份的验证并协商对称加密使用的秘钥。对称加密算法采用协商秘钥对信息以及信息摘要进行加密通信，不同节点之间采用的对称秘钥不同，从而保证信息只能通信双方获取。这样就解决了两个方法各自存在的问题。

3. 数字证书

因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人，截取了对方发给我们的公钥，然后将他自己的公钥发送给我们，当我们使用他的公钥加密后发送的信息，就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息，这样我们的信息就被窃取了，然而自己还不知道。为了解决这样的问题，可以使用数字证书。

首先我们使用一种 Hash 算法来对我们的公钥和其他信息进行加密生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为数字证书。

当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和我们生成的摘要进行对比，就能发现我们得到的信息是否被更改了。

这个方法最要的是认证中心的可靠性，一般浏览器里会内置一些顶层的认证中心的证书，相当于我们自动信任了他们，只有这样我们才能保证数据的安全。

数字签名

4. 通信（握手）过程

客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。
服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。
客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

5. 优/缺点

优点：

使用 HTTPS 协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器；
使用 HTTPS 协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性；
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本；

缺点：

HTTPS 需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂；
HTTPS 协议握手阶段比较费时，增加页面的加载时间；
SSL 证书是收费的，功能越强大的证书费用越高；
HTTPS 连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本；
SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名。

6. 安全流程

结合两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。

此时⼜带来⼀个问题，中间⼈问题：如果此时在客户端和服务器之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中间⼈就可以轻松解密通信双⽅所发送的所有数据。

所以这个时候需要⼀个安全的第三⽅颁发证书（CA），证明身份的身份，防⽌被中间⼈攻击。证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的 HASH 算法、证书到期时间等。

但是问题来了，如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技术，数字签名。

数字签名就是⽤ CA ⾃带的 HASH 算法对证书的内容进⾏ HASH 得到⼀个摘要，再⽤ CA 的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的 Hash 算法,再次⽣成消息摘要，然后⽤ CA 的公钥对数字签名解密,得到 CA 创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。

三、状态码

类别	原因	描述
1xx	Informational(信息性状态码)	接受的请求正在处理
2xx	Success(成功状态码)	请求正常处理完毕
3xx	Redirection(重定向状态码)	需要进行附加操作一完成请求
4xx	Client Error (客户端错误状态码)	服务器无法处理请求
5xx	Server Error(服务器错误状态码)	服务器处理请求出错

1. 2xx (成功)

(1) 200 OK

客户端发送给服务器的请求被正常处理并返回

(2) 204 No content

该状态码表示客户端发送的请求已经在服务器端正常处理了，但是没有返回的内容，响应报文中不包含实体的主体部分。一般在只需要从客户端往服务器端发送信息，而服务器端不需要往客户端发送内容时使用。

(3) 205 Reset Content

表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

(4) 206 Partial Content

该状态码表示客户端进行了范围请求，而服务器端执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

2. 3xx (重定向)

(1) 301 Moved Permanently

永久重定向，请求的网页已永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置

(2) 302 Found

临时重定向，请求的网页已临时移动到新位置。服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求

(3) 303 See Other

表示资源存在着另一个 URL，应使用 GET 方法获取资源，会把POST请求变为GET请求进⾏重定向。

(4) 304 Not Modified

未修改，自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容

(5) 307 Temporary Redirect

临时重定向，和 302 含义类似，但是期望客户端保持请求方法不变向新的地址发出请求，不会从POST变为GET

3. 4xx (客户端错误)

(1) 400 Bad Request

错误请求，服务器不理解请求的语法，常见于客户端传参错误

(2) 401 Unauthorized

未授权，表示发送的请求需要有通过 HTTP 认证的认证信息，常见于客户端未登录

(3) 403 Forbidden

禁止，服务器拒绝请求，常见于客户端权限不足

(4) 404 Not Found

未找到，服务器找不到对应资源

(5) 405 Method Not Allowed

方法不允许，请求方法（GET、POST、HEAD、DELETE、PUT、TRACE等）对指定的资源不适用，用来访问本不应访问的资源

4. 5xx (服务器错误)

(1) 500 Internal Server Error

服务器内部错误，服务器遇到错误，无法完成请求

(2) 501 Not Implemented

尚未实施，服务器不具备完成请求的功能

(3) 502 Bad Gateway

作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

(4) 503 Service Unavailable

服务不可用，服务器目前无法使用（处于超载或停机维护状态）。通常是暂时状态

(5) 504 Gateway Timeout

网关超时，服务器作为网关或者代理工作，但是没有及时从上游服务器收到请求

5. 304 缓存

服务器为了提高网站访问速度，对之前访问的部分页面指定缓存机制，当客户端在此对这些页面进行请求，服务器会根据缓存内容判断页面与之前是否相同，若相同便直接返回 304，此时客户端调用缓存内容，不必进行二次下载。

状态码 304 不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。通过特定时间内对网站抓取返回的状态码来调节对该网站的抓取频次。若网站在一定时间内一直处于 304 的状态，那么蜘蛛可能会降低对网站的抓取次数。相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。

产生较多 304 状态码的原因：

页面更新周期长或不更新
纯静态页面或强制生成静态 html

304 状态码出现过多会造成以下问题：

网站快照停止；
收录减少；
权重下降。

四、DNS 协议

1. 介绍

概念

DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。

作用

将域名解析为 IP 地址，客户端向 DNS 服务器（DNS 服务器有自己的 IP 地址）发送域名查询请求，DNS 服务器告知客户机 Web 服务器的 IP 地址。

优化

缓存、负载均衡

2. 同时使用 TCP 和 UDP

DNS 占用 53 号端口，同时使用 TCP 和 UDP 协议。

在区域传输的时候使用 TCP 协议
- 辅域名服务器会定时（一般 3 小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用 TCP 而不是 UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
- TCP 是一种可靠连接，保证了数据的准确性。
在域名解析的时候使用 UDP 协议
- 客户端向 DNS 服务器查询域名，一般返回的内容都不超过 512 字节，用 UDP 传输即可。不用经过三次握手，这样 DNS 服务器负载更低，响应更快。理论上说，客户端也可以指定向 DNS 服务器查询时用 TCP，但事实上，很多 DNS 服务器进行配置的时候，仅支持 UDP 查询包。

3. DNS 服务器域名解析过程

首先会在浏览器的缓存中查找对应的 IP 地址，如果查找到直接返回，若找不到继续下一步
将请求发送给本地 DNS 服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
本地 DNS 服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
本地 DNS 服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
本地 DNS 服务器向权威域名服务器发送请求，域名服务器返回对应的结果
本地 DNS 服务器将返回结果保存在缓存中，便于下次使用
本地 DNS 服务器将返回结果返回给浏览器

*3\4\5 是迭代查询，2\6\7 是递归查询

比如要查询 www.baidu.com 的 IP 地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地 DNS 服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表

4. 迭代查询与递归查询

实际上，DNS 解析是一个包含迭代查询和递归查询的过程。

递归查询指的是查询请求发出后，域名服务器代为向下一级域名服务器发出请求，最后向用户返回查询的最终结果。使用递归查询，用户只需要发出一次查询请求。
迭代查询指的是查询请求后，域名服务器返回单次查询的结果。下一级的查询由用户自己请求。使用迭代查询，用户需要发出多次的查询请求。

一般我们向本地 DNS 服务器发送请求的方式就是递归查询，因为我们只需要发出一次请求，然后本地 DNS 服务器返回给我们最终的请求结果。而本地 DNS 服务器向其他域名服务器请求的过程是迭代查询的过程，因为每一次域名服务器只返回单次查询的结果，下一级的查询由本地 DNS 服务器自己进行。

5. DNS 记录和报文

DNS 服务器中以资源记录的形式存储信息，每一个 DNS 响应报文一般包含多条资源记录。一条资源记录的具体的格式为

http

（Name，Value，Type，TTL）

其中 TTL 是资源记录的生存时间，它定义了资源记录能够被其他的 DNS 服务器缓存多长时间。

常用的一共有四种 Type 的值，分别是 A、NS、CNAME 和 MX ，不同 Type 的值，对应资源记录代表的意义不同：

如果 Type = A，则 Name 是主机名，Value 是主机名对应的 IP 地址。因此一条记录为 A 的资源记录，提供了标准的主机名到 IP 地址的映射。
如果 Type = NS，则 Name 是个域名，Value 是负责该域名的 DNS 服务器的主机名。这个记录主要用于 DNS 链式查询时，返回下一级需要查询的 DNS 服务器的信息。
如果 Type = CNAME，则 Name 为别名，Value 为该主机的规范主机名。该条记录用于向查询的主机返回一个主机名对应的规范主机名，从而告诉查询主机去查询这个主机名的 IP 地址。主机别名主要是为了通过给一些复杂的主机名提供一个便于记忆的简单的别名。
如果 Type = MX，则 Name 为一个邮件服务器的别名，Value 为邮件服务器的规范主机名。它的作用和 CNAME 是一样的，都是为了解决规范主机名不利于记忆的缺点。

五、CDN

1. 概念

CDN 的全称是 Content Delivery Network，即内容分发网络。是指一种通过互联网互相连接的电脑网络系统，利用最靠近每位用户的服务器，更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户，来提供高性能、可扩展性及低成本的网络内容传递给用户。

CDN 的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应。

对于 CDN 加载静态资源需要注意 CDN 域名要与主站不同，否则每次请求都会带上主站的 Cookie。

典型的 CDN 系统由下面三个部分组成：

分发服务系统：最基本的工作单元就是 Cache 设备，cache（边缘 cache）负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用户。同时 cache 还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache 设备的数量、规模、总服务能力是衡量一个 CDN 系统服务能力的最基本的指标。
负载均衡系统：主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡（GSLB）和本地负载均衡（SLB）。全局负载均衡主要根据用户就近性原则，通过对每个服务节点进行“最优”判断，确定向用户提供服务的 cache 的物理位置。本地负载均衡主要负责节点内部的设备负载均衡
运营管理系统：运营管理系统分为运营管理和网络管理子系统，负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

2. 作用

CDN 一般会用来托管 Web 资源（包括文本、图片和脚本等），可供下载的资源（媒体文件、软件、文档等），应用程序（门户网站等）。使用 CDN 来加速这些资源的访问

在性能方面，引入 CDN 的作用在于：

用户收到的内容来自最近的数据中心，延迟更低，内容加载更快
部分资源请求分配给了 CDN，减少了服务器的负载

在安全方面，CDN 有助于防御 DDoS、MITM 等网络攻击：

针对 DDoS：通过监控分析异常流量，限制其请求频率
针对 MITM：从源服务器到 CDN 节点到 ISP（Internet Service Provider），全链路 HTTPS 通信

除此之外，CDN 作为一种基础的云服务，同样具有资源托管、按需扩展（能够应对流量高峰）等方面的优势。

3. 原理

用户未使用 CDN 缓存资源的过程：

浏览器通过 DNS 对域名进行解析（就是上面的 DNS 解析过程），依次得到此域名对应的 IP 地址
浏览器根据得到的 IP 地址，向域名的服务主机发送数据请求
服务器向浏览器返回响应数据

用户使用 CDN 缓存资源的过程：

对于点击的数据的 URL，经过本地 DNS 系统的解析，发现该 URL 对应的是一个 CDN 专用的 DNS 服务器，DNS 系统就会将域名解析权交给 CNAME 指向的 CDN 专用的 DNS 服务器。
CND 专用 DNS 服务器将 CND 的全局负载均衡设备 IP 地址返回给用户
用户向 CDN 的全局负载均衡设备发起数据请求
CDN 的全局负载均衡设备根据用户的 IP 地址，以及用户请求的内容 URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求
区域负载均衡设备选择一台合适的缓存服务器来提供服务，将该缓存服务器的 IP 地址返回给全局负载均衡设备
全局负载均衡设备把服务器的 IP 地址返回给用户
用户向该缓存服务器发起请求，缓存服务器响应用户的请求，将用户所需内容发送至用户终端。

如果缓存服务器没有用户想要的内容，那么缓存服务器就会向它的上一级缓存服务器请求内容，以此类推，直到获取到需要的资源。最后如果还是没有，就会回到自己的服务器去获取资源。

CDN原理

CNAME（意为：别名）：在域名解析中，实际上解析出来的指定域名对应的 IP 地址，或者该域名的一个 CNAME，然后再根据这个 CNAME 来查找对应的 IP 地址。

4. 使用场景

使用第三方的 CDN 服务：如果想要开源一些项目，可以使用第三方的 CDN 服务
使用 CDN 进行静态资源的缓存：将自己网站的静态资源放在 CDN 上，比如 js、css、图片等。可以将整个项目放在 CDN 上，完成一键部署。
直播传送：直播本质上是使用流媒体进行传送，CDN 也是支持流媒体传送的，所以直播完全可以使用 CDN 来提高访问速度。CDN 在处理流媒体的时候与处理普通静态文件有所不同，普通文件如果在边缘节点没有找到的话，就会去上一层接着寻找，但是流媒体本身数据量就非常大，如果使用回源的方式，必然会带来性能问题，所以流媒体一般采用的都是主动推送的方式来进行。

六、网络模型

1. OSI 七层模型

ISO为了更好的使网络应用更为普及，推出了OSI参考模型。

OSI七层模型

应用层

OSI 参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。

在客户端与服务器中经常会有数据的请求，这个时候就是会用到 HTTP 或者 HTTPS.在后端设计数据接口时，我们常常使用到这个协议。
FTP 是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如百度网盘``迅雷应该是基于此协议的。
SMTP 是 simple mail transfer protocol（简单邮件传输协议）。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

表示层

表示层提供各种用于应用层数据的编码和转换功能,确保一个系统的应用层发送的数据能被另一个系统的应用层识别。如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。数据压缩和加密也是表示层可提供的转换功能之一。

在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

传输层

传输层建立了主机端到端的链接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。我们通常说的，TCP、UDP就是在这一层。端口号既是这里的“端”。

网络层

本层通过 IP 寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是通常说的 IP 层。这一层就是我们经常说的 IP 协议层。IP 协议是 Internet 的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

数据链路层

将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用 MAC 地址)来访问介质,并进行差错检测。

网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

物理层

实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。

2. TCP/IP 网络模型

TCP/IP五层协议和OSI的七层协议对应关系如下：

TCP/IP 网络模型

TCP/IP模型模型是一系列网络协议的总称，这些协议的目的是使得计算机之间可以进行信息交换，比OSI模型更加简洁，它把应用层/表示层/会话层全部整合为了应用层。

TCP/IP 模型五层架构从下到上分别是物理层，链路层，网络层，传输层，应用层

应用层:直接为应用进程提供服务。应用层协议定义的是应用进程间通讯和交互的规则，不同的应用有着不同的应用层协议，如 HTTP 协议（万维网服务）、FTP 协议（文件传输）、SMTP 协议（电子邮件）、DNS（域名查询）等
传输层:负责为两台主机中的进程提供通信服务，主要协议是 TCP、UDP
网络层:负责为两台主机提供通信服务，并通过选择合适的路由将数据传递到目标主机，主要协议是 IP 协议，
数据链路层:负责将网络层交下来的 IP 数据报封装成帧，并在链路的两个相邻节点间传送帧，每一帧都包含数据和必要的控制信息（如同步信息、地址信息、差错控制等）
物理层:确保数据可以在各种物理媒介上进行传输，为数据的传输提供可靠的环境。

设备支持： TCP/IP 网络模型设备

协议支持： TCP/IP 网络模型协议

七、TCP

TCP 的全称是传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构。

1. 特点

1）面向连接

面向连接，是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。

2）仅支持单播传输

每条 TCP 传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

3）面向字节流

TCP 不像 UDP 一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

4）可靠传输

对于可靠传输，判断丢包、误码靠的是 TCP 的段编号以及确认号。TCP 为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

5）提供拥塞控制

当网络出现拥塞的时候，TCP 能够减小向网络注入数据的速率和数量，缓解拥塞。

6）提供全双工通信

TCP 允许通信双方的应用程序在任何时候都能发送数据，因为 TCP 连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP 可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于 MSS）

2. 使用场景

效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。

例如：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

3. 重传机制

由于 TCP 的下层网络（网络层）可能出现丢失、重复或失序的情况，TCP 协议提供可靠数据传输服务。为保证数据传输的正确性，TCP 会重传其认为已丢失（包括报文中的比特错误）的包。TCP 使用两套独立的机制来完成重传，一是基于时间，二是基于确认信息。

TCP 在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的 ACK 确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号。

4. 拥塞控制机制

TCP 的拥塞控制机制主要是以下四种机制：

1）慢启动（慢开始）

在开始发送的时候设置 cwnd = 1（cwnd 指的是拥塞窗口）
思路：开始的时候不要发送大量数据，而是先测试一下网络的拥塞程度，由小到大增加拥塞窗口的大小。
为了防止 cwnd 增长过大引起网络拥塞，设置一个慢开始门限(ssthresh 状态变量)
- 当 cnwd < ssthresh，使用慢开始算法
- 当 cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
- 当 cnwd > ssthresh，使用拥塞避免算法

2）拥塞避免

拥塞避免未必能够完全避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性增长，使网络不容易出现阻塞。
思路：让拥塞窗口 cwnd 缓慢的增大，即每经过一个返回时间 RTT 就把发送方的拥塞控制窗口加一
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为 1，执行慢开始算法。

3）快速重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量

4）快速恢复

当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半。但是接下去并不执行慢开始算法。
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。

5. 流量控制机制

一般来说，流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。TCP 采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。这里说的窗口大小其实就是每次传输的数据大小。

当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。
当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告。接收方在发送的每一确认中都含有一个窗口通告。）
如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。
如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

6. 可靠传输机制

TCP 的可靠传输机制是基于连续 ARQ 协议和滑动窗口协议的。

TCP 协议在发送方维持了一个发送窗口，发送窗口以前的报文段是已经发送并确认了的报文段，发送窗口中包含了已经发送但未确认的报文段和允许发送但还未发送的报文段，发送窗口以后的报文段是缓存中还不允许发送的报文段。当发送方向接收方发送报文时，会依次发送窗口内的所有报文段，并且设置一个定时器，这个定时器可以理解为是最早发送但未收到确认的报文段。如果在定时器的时间内收到某一个报文段的确认回答，则滑动窗口，将窗口的首部向后滑动到确认报文段的后一个位置，此时如果还有已发送但没有确认的报文段，则重新设置定时器，如果没有了则关闭定时器。如果定时器超时，则重新发送所有已经发送但还未收到确认的报文段，并将超时的间隔设置为以前的两倍。当发送方收到接收方的三个冗余的确认应答后，这是一种指示，说明该报文段以后的报文段很有可能发生丢失了，那么发送方会启用快速重传的机制，就是当前定时器结束前，发送所有的已发送但确认的报文段。

接收方使用的是累计确认的机制，对于所有按序到达的报文段，接收方返回一个报文段的肯定回答。如果收到了一个乱序的报文段，那么接方会直接丢弃，并返回一个最近的按序到达的报文段的肯定回答。使用累计确认保证了返回的确认号之前的报文段都已经按序到达了，所以发送窗口可以移动到已确认报文段的后面。

发送窗口的大小是变化的，它是由接收窗口剩余大小和网络中拥塞程度来决定的，TCP 就是通过控制发送窗口的长度来控制报文段的发送速率。

但是 TCP 协议并不完全和滑动窗口协议相同，因为许多的 TCP 实现会将失序的报文段给缓存起来，并且发生重传时，只会重传一个报文段，因此 TCP 协议的可靠传输机制更像是窗口滑动协议和选择重传协议的一个混合体。

7. 三次握手

TCP三次握手

三次握手（Three-way Handshake）其实就是指建立一个 TCP 连接时，需要客户端和服务器总共发送 3 个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，此时客户端处于 SYN_SEND 状态。
首部的同步位 SYN=1，初始序号 seq=x，SYN=1 的报文段不能携带数据，但要消耗掉一个序号。
第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
在确认报文段中 SYN=1，ACK=1，确认号 ack=x+1，初始序号 seq=y
第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段 ACK=1，确认号 ack=y+1，序号 seq=x+1（初始为 seq=x，第二个报文段所以要+1），ACK 报文段可以携带数据，不携带数据则不消耗序号。

为什么需要三次，两次和四次可以吗？

为了确认双方的接收能力和发送能力都正常，防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误
如果是用两次握手，则会出现下面这种情况：
如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。
为什么不是四次握手呢
大家应该知道通信中著名的蓝军红军约定，这个例子说明，通信不可能 100%可靠，而上面的三次握手已经做好了通信的准备工作，再增加握手，并不能显著提高可靠性，而且也没有必要。

简单来说就是以下三步：

第一次握手：客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。
第二次握手：服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。
第三次握手：当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

TCP 三次握手的建立连接的过程就是相互确认初始序号的过程，告诉对方，什么样序号的报文段能够被正确接收。第三次握手的作用是客户端对服务器端的初始序号的确认。如果只使用两次握手，那么服务器就没有办法知道自己的序号是否已被确认。同时这样也是为了防止失效的请求报文段被服务器接收，而出现错误的情况。

8. 四次挥手

TCP四次挥手

最开始的时候，客户端和服务器都是处于 ESTABLISHED 状态，假设客户端主动关闭，服务器被动关闭，四次挥手的过程如下：

第一次挥手：客户端会发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即发出连接释放报文段（FIN=1，序号 seq=u），并停止再发送数据，主动关闭 TCP 连接，进入 FIN_WAIT1（终止等待 1）状态，等待服务端的确认。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号 ack=u+1，序号 seq=v），服务端进入 CLOSE_WAIT（关闭等待）状态，此时的 TCP 处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入 FIN_WAIT2（终止等待 2）状态，等待服务端发出的连接释放报文段。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号 seq=w，确认号 ack=u+1），服务端进入 LAST_ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入 TIME_WAIT（时间等待）状态。此时 TCP 未释放掉，需要经过时间等待计时器设置的时间 2MSL 后，客户端才进入 CLOSED 状态。

为什么客户端最后还要等待 2MSL

MSL（Maximum Segment Lifetime），TCP 允许不同的实现可以设置不同的 MSL 值。

保证客户端发送的最后一个 ACK 报文能够到达服务器，因为这个 ACK 报文可能丢失，站在服务器的角度看来，我已经发送了 FIN+ACK 报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个 2MSL 时间段内收到这个重传的报文，接着给出回应报文，并且会重启 2MSL 计时器。
防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个 2MSL 时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候，服务器在 LISTEN 状态下，收到建立连接请求的 SYN 报文后，把 ACK 和 SYN 放在一个报文里发送给客户端，其中 ACK 报文是用来应答的，SYN 报文是用来同步的。

而关闭连接时，服务器收到对方的 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉客户端，“你发的 FIN 报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送 FIN 报文。因此己方 ACK 和 FIN 一般都会分开发送，从而导致多了一次。

简单来说就是以下四步：

第一次挥手：若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。
第二次挥手：服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。
第三次挥手：服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。
第四次挥手：客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃）时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的，所以需要双方分别释放到对方的连接，单独一方的连接释放，只代表不能再向对方发送数据，连接处于的是半释放的状态。

最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器端不能正常关闭。

9. TCP 粘包

默认情况下, TCP 连接会启⽤延迟传送算法 (Nagle 算法), 在数据发送之前缓存他们. 如果短时间有多个数据发送, 会缓冲到⼀起作⼀次发送 (缓冲⼤⼩⻅ socket.bufferSize ), 这样可以减少 IO 消耗提⾼性能.

如果是传输⽂件的话, 那么根本不⽤处理粘包的问题, 来⼀个包拼⼀个包就好了。但是如果是多条消息, 或者是别的⽤途的数据那么就需要处理粘包.

下面看⼀个例⼦, 连续调⽤两次 send 分别发送两段数据 data1 和 data2, 在接收端有以下⼏种常⻅的情况:

先接收到 data1, 然后接收到 data2 .
先接收到 data1 的部分数据, 然后接收到 data1 余下的部分以及 data2 的全部.
先接收到了 data1 的全部数据和 data2 的部分数据, 然后接收到了 data2 的余下的数据.
⼀次性接收到了 data1 和 data2 的全部数据.

其中的 234 就是我们常⻅的粘包的情况. ⽽对于处理粘包的问题, 常⻅的解决⽅案有:

多次发送之前间隔⼀个等待时间：只需要等上⼀段时间再进⾏下⼀次 send 就好, 适⽤于交互频率特别低的场景. 缺点也很明显, 对于⽐较频繁的场景⽽⾔传输效率实在太低，不过⼏乎不⽤做什么处理.
关闭 Nagle 算法：关闭 Nagle 算法, 在 Node.js 中你可以通过 socket.setNoDelay() ⽅法来关闭 Nagle 算法, 让每⼀次 send 都不缓冲直接发送。该⽅法⽐较适⽤于每次发送的数据都⽐较⼤ (但不是⽂件那么⼤), 并且频率不是特别⾼的场景。如果是每次发送的数据量⽐较⼩, 并且频率特别⾼的, 关闭 Nagle 纯属⾃废武功。另外, 该⽅法不适⽤于⽹络较差的情况, 因为 Nagle 算法是在服务端进⾏的包合并情况, 但是如果短时间内客户端的⽹络情况不好, 或者应⽤层由于某些原因不能及时将 TCP 的数据 recv, 就会造成多个包在客户端缓冲从⽽粘包的情况。 (如果是在稳定的机房内部通信那么这个概率是⽐较⼩可以选择忽略的)
进⾏封包/拆包：封包/拆包是⽬前业内常⻅的解决⽅案了。即给每个数据包在发送之前, 于其前/后放⼀些有特征的数据, 然后收到数据的时候根据特征数据分割出来各个数据包。

为什么 udp 不会粘包？

TCP 协议是⾯向流的协议，UDP 是⾯向消息的协议。UDP 段都是⼀条消息，应⽤程序必须以消息为单位提取数据，不能⼀次提取任意字节的数据
UDP 具有保护消息边界，在每个 UDP 包中就有了消息头（消息来源地址，端⼝等信息），这样对于接收端来说就容易进⾏区分处理了。传输协议把数据当作⼀条独⽴的消息在⽹上传输，接收端只能接收独⽴的消息。接收端⼀次只能接收发送端发出的⼀个数据包,如果⼀次接受数据的⼤⼩⼩于发送端⼀次发送的数据⼤⼩，就会丢失⼀部分数据，即使丢失，接受端也不会分两次去接收。

八、UDP

UDP的全称是用户数据报协议，UDP 协议是面向无连接的，也就是说不需要在正式传递数据之前先连接起双方。在网络中它与TCP协议一样用于处理数据包，在OSI模型中，在传输层，处于IP协议的上一层。

UDP 协议没有任何控制流量的算法，不提供数据包分组、组装和不能对数据包进行排序，UDP 协议只是数据报文的搬运工，不保证有序且不丢失的传递到对端，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。总的来说 UDP 相较于 TCP 更加的轻便。

1. 特点

面向无连接：UDP 是不需要和 TCP 一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了，并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作
- 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
- 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作
传输方式：UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能
面向报文：发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文
不可靠性：
不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
总结：
- 不保证消息交付：不确认，不重传，无超时
- 不保证交付顺序：不设置包序号，不重排，不会发生队首阻塞
- 不跟踪连接状态：不必建立连接或重启状态机
- 不进行拥塞控制：不内置客户端或网络反馈机制
头部开销小，传输数据报文时是很高效的
UDP 头部包含了以下几个数据：
- 两个十六位的端口号，分别为源端口（可选字段）和目标端口
- 整个数据报文的长度
- 整个数据报文的检验和（IPv4 可选字段），该字段用于发现头部信息和数据中的错误
因此 UDP 的头部开销小，只有 8 字节，相比 TCP 的至少 20 字节要少得多，在传输数据报文时是很高效的

九、WebSocket

1. 理解

WebSocket 是 HTML5 提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于 TCP 传输协议，并复用 HTTP 的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

2. 原理

客户端向 WebSocket 服务器通知（notify）一个带有所有接收者 ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有 ID 在接收者 ID 序列中的客户端才会处理这个事件。

3. 特点

支持双向通信，实时性更强
可以发送文本，也可以发送二进制数据‘’
建立在 TCP 协议之上，服务端的实现比较容易
数据格式比较轻量，性能开销小，通信高效
没有同源限制，客户端可以与任意服务器通信
协议标识符是 ws（如果加密，则为 wss），服务器网址就是 URL
与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

4. 使用方法

// 在index.html中直接写WebSocket，设置服务端的端口号为 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客户端与服务端建立连接后触发
ws.onopen = function () {
  console.log('Connection open.');
  ws.send('hello');
};
// 在服务端给客户端发来消息的时候触发
ws.onmessage = function (res) {
  console.log(res); // 打印的是MessageEvent对象
  console.log(res.data); // 打印的是收到的消息
};
// 在客户端与服务端建立关闭后触发
ws.onclose = function (evt) {
  console.log('Connection closed.');
};

5. 即时通讯

短轮询的基本思路：浏览器每隔一段时间向服务器发送 http 请求，服务器端在收到请求后，不论是否有数据更新，都直接进行响应。这种方式实现的即时通信，本质上还是浏览器发送请求，服务器接受请求的一个过程，通过让客户端不断的进行请求，使得客户端能够模拟实时地收到服务器端的数据的变化。这种方式的优点是比较简单，易于理解。缺点是这种方式由于需要不断的建立 http 连接，严重浪费了服务器端和客户端的资源。当用户增加时，服务器端的压力就会变大，这是很不合理的。

长轮询的基本思路：首先由客户端向服务器发起请求，当服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断服务器端数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则到达一定的时间限制才返回。客户端 JavaScript 响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接。长轮询和短轮询比起来，它的优点是明显减少了很多不必要的 http 请求次数，相比之下节约了资源。长轮询的缺点在于，连接挂起也会导致资源的浪费。

SSE 的基本思想：服务器使用流信息向服务器推送信息。严格地说，http 协议无法做到服务器主动推送信息。但是，有一种变通方法，就是服务器向客户端声明，接下来要发送的是流信息。也就是说，发送的不是一次性的数据包，而是一个数据流，会连续不断地发送过来。这时，客户端不会关闭连接，会一直等着服务器发过来的新的数据流，视频播放就是这样的例子。SSE 就是利用这种机制，使用流信息向浏览器推送信息。它基于 http 协议，目前除了 IE/Edge，其他浏览器都支持。它相对于前面两种方式来说，不需要建立过多的 http 请求，相比之下节约了资源。

WebSocket 是 HTML5 定义的一个新协议议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息，而 SSE 的方式是单向通信的，只能由服务器端向客户端推送信息，如果客户端需要发送信息就是属于下一个 http 请求了。

十、其它

1. 单工/半双工/全双工通信

单工数据传输只支持数据在一个方向上传输;
半双工数据传输允许数据在两个方向上传输，但是，在某一时刻，只允许数据在一个方向上传输，它实际上是一种切换方向的单工通信；
全双工数据通信允许数据同时在两个方向上传输，因此，全双工通信是两个单工通信方式的结合，它要求发送设备和接收设备都有独立的接收和发送能力。

2. 实现登录

Cookie，Session 和 Token 都是为了能够实现客户端与服务器间的状态维持。其中：

Cookie 存储于客户端，主要用于一些简短信息的存储； HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储、
Session 存储于服务器端，维护了客户端的相关信息列表，并且通过一个唯一的身份标识 sessionId 识别各个客户端。客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。
Token 存储于客户端，其结构紧凑且自带验证功能，很好地解决了 Session 无法水平扩展服务器的局限，实现了服务器无状态但通信具备却状态维持功能。通常使用 JWT（JSON Web Token）作为 Token 的具体实现方式。

3. 单点登录

单点登录是指在同一帐号平台下的多个应用系统中，用户只需登录一次，就可访问所有相互信任的应用系统。比如你在网页中登录了百度云盘，随后你再去贴吧发帖是不需要二次登录的。

单点登录的本质就是在多个应用系统中共享登录状态。如果用户的登录状态是记录在 Session 中的，要实现共享登录状态，就要先共享 Session，比如可以将 Session 序列化到 Redis 中，让多个应用系统共享同一个 Redis，直接读取 Redis 来获取 Session。

因为不同的应用系统有着不同的域名，尽管 Session 共享了，但是一个企业不同应用的域名不同，依然可能出现跨站 or 跨域。

前端方面的实现方式:

父域 Cookie
认证中心
LocalStorage 跨域

4. 正反向代理

代理其本质上可以理解为中介。当 A 和 B 不方便进行交互时，往往会引入一个中间角色 C，那么 C 便是中介，便是代理。正向代理服务器通常位于客户端和服务器之间，类似一个跳板机，通过代理服务器可以访问到目标服务器。正向代理时，通常，客户端发送对目标服务器的请求，代理服务器在中间将请求转发给目标服务器，并将结果返回给客户端。反向代理与正向代理恰好相反，代理服务位于服务器端。对客户端来说，反向代理服务器就好像是目标服务器。反向代理服务器接收客户端发来的请求，然后将其分发到内网的服务器，并将内网服务器返回的结果返回给客户端。整个过程客户端并不会感知到反向代理后面的服务，也不需要客户端做任何设置，只需要把反向代理服务器当成真正的服务器就行。

5. GraphQL & Restful

QraphQL 是对后端 REST API 向业务层的聚合与裁剪，REST 更关注对业务细粒度的拆分与重用。其实就是增加了一个中间层对前端的请求和响应做预处理和后处理，前端的工作少了，后端的工作也没多，却加入了中端的依赖，好处是避免前端和后端的多次远距离的交互。而 graphql 存在一个很难控制的问题就是查询复杂度。在开发过程中需要把控好解析粒度，而就目前主流关系型数据库，restful api 依旧是最好的选择。graphql 准确的说在查询图结构数据时更有优势，这也是其名称的主意。

网络 ​

一、HTTP 协议 ​

1. GET / POST ​

2. POST / PUT ​

3. 请求报文 ​

请求行组成 ​

常见请求方法 ​

OPTIONS 请求方法及使用场景 ​

常见请求头 ​

4. 响应报文 ​

常见相应头 ​

content-type 常见类型： ​

5. 优/缺点 ​

6. HTTP 1.1 ​

7. HTTP 2.0 ​

8. Keep-Alive ​

9. 头部压缩算法 ​

10. 队头堵塞 ​

解决方案 ​

11. HTTP 3.0 ​

二、HTTPS 协议 ​

1. 理解 ​

2. TLS/SSL 的工作原理 ​

散列函数 hash ​

对称加密 ​

非对称加密 ​

3. 数字证书 ​

4. 通信（握手）过程 ​

5. 优/缺点 ​

6. 安全流程 ​

三、状态码 ​

1. 2xx (成功) ​

(1) 200 OK ​

(2) 204 No content ​

(3) 205 Reset Content ​

(4) 206 Partial Content ​

2. 3xx (重定向) ​

(1) 301 Moved Permanently ​

(2) 302 Found ​

(3) 303 See Other ​

(4) 304 Not Modified ​

(5) 307 Temporary Redirect ​

3. 4xx (客户端错误) ​

(1) 400 Bad Request ​

(2) 401 Unauthorized ​

(3) 403 Forbidden ​

(4) 404 Not Found ​

(5) 405 Method Not Allowed ​

4. 5xx (服务器错误) ​

(1) 500 Internal Server Error ​

(2) 501 Not Implemented ​

(3) 502 Bad Gateway ​

(4) 503 Service Unavailable ​

(5) 504 Gateway Timeout ​

5. 304 缓存 ​

四、DNS 协议 ​

1. 介绍 ​

概念 ​

作用 ​

优化 ​

2. 同时使用 TCP 和 UDP ​

3. DNS 服务器域名解析过程 ​

4. 迭代查询与递归查询 ​

5. DNS 记录和报文 ​

五、CDN ​

1. 概念 ​

2. 作用 ​

3. 原理 ​

用户未使用 CDN 缓存资源的过程： ​

用户使用 CDN 缓存资源的过程： ​

4. 使用场景 ​

六、网络模型 ​

1. OSI 七层模型 ​

应用层 ​

表示层 ​

会话层 ​

传输层 ​

网络层 ​

数据链路层 ​

物理层 ​

网络

一、HTTP 协议

1. GET / POST

2. POST / PUT

3. 请求报文

请求行组成

常见请求方法

OPTIONS 请求方法及使用场景

常见请求头

4. 响应报文

常见相应头

content-type 常见类型：

5. 优/缺点

6. HTTP 1.1

7. HTTP 2.0

8. Keep-Alive

9. 头部压缩算法

10. 队头堵塞

解决方案

11. HTTP 3.0

二、HTTPS 协议

1. 理解

2. TLS/SSL 的工作原理

散列函数 hash

对称加密

非对称加密

3. 数字证书

4. 通信（握手）过程

5. 优/缺点

6. 安全流程

三、状态码

1. 2xx (成功)

(1) 200 OK

(2) 204 No content

(3) 205 Reset Content

(4) 206 Partial Content

2. 3xx (重定向)

(1) 301 Moved Permanently

(2) 302 Found

(3) 303 See Other

(4) 304 Not Modified

(5) 307 Temporary Redirect

3. 4xx (客户端错误)

(1) 400 Bad Request

(2) 401 Unauthorized

(3) 403 Forbidden

(4) 404 Not Found

(5) 405 Method Not Allowed

4. 5xx (服务器错误)

(1) 500 Internal Server Error

(2) 501 Not Implemented

(3) 502 Bad Gateway

(4) 503 Service Unavailable

(5) 504 Gateway Timeout

5. 304 缓存

四、DNS 协议

1. 介绍

概念

作用

优化

2. 同时使用 TCP 和 UDP

3. DNS 服务器域名解析过程

4. 迭代查询与递归查询

5. DNS 记录和报文

五、CDN

1. 概念

2. 作用

3. 原理

用户未使用 CDN 缓存资源的过程：

用户使用 CDN 缓存资源的过程：

4. 使用场景

六、网络模型

1. OSI 七层模型

应用层

表示层

会话层

传输层

网络层

数据链路层

物理层