面试中的网络协议

引言

网络协议就是计算机网络中用来通信的规则，限定数据传输是以什么方式传输的，TCP和UDP属于传输层协议，而HTTP是应用层协议，UDP提供了一种不可靠的、无连接的服务，它注重传输速度，不保证数据的有序性和完整性，TCP则相反，保证数据的完整性，基于这两种协议，HTTP协议为网页浏览、数据交换等提供了更加丰富和便捷的服务。

UDP 协议

UDP协议就是一种简单、高效、非连接的传输层协议，比如需要传输10个数据包，UDP就直接传输，会直接将这些数据包发送到目标地址，而不会等待确认或建立连接。这种"即发即走"的方式使得UDP传输非常快速，但也会带来如果网络环境不好也就是拥塞就会造成丢包的问题。且不保证数据包有序性。

特点：

面向无连接（知道了对面的 ip 后就直接传输数据）
只做数据报文的搬运工（不增加额外的报文头部）
不保证数据包的有序性
不保证数据的可靠性（丢包）
没有拥塞控制（网络环境）
高效

应用场景：适用于视频通话，突然网卡的时候，视频画面停了五秒，也就是丢包了（丢包会导致视频画面出现停顿或冻结，所以丢失的数据无法被填补），之前的画面就不会再出现了，五秒后环境好了，就显示实时的画面了。适用于直播，游戏等实时性高的应用。

TCP 协议

TCP 就是反着来的UDP协议传输数据时先建立连接，数据有序的，可靠的，面向连接的，慢启动，会进行拥塞控制（当前网络支持传输多少的数据）。

头部信息多：

Sequence Number （序列号）
Acknowledgment Number （确认号）
Window Size 窗口大小（网络环境支持传输数据量多少字节的数据）
标识符：
1. URG=1 紧急报文
2. ACK=1 确认报文
3. PSH=1 接收端应该立即将数据传给应用层
4. RST=1 复位连接
5. SYN=1 建立连接
6. FIN=1 释放连接

三次握手

数据传输前，需要建立连接，经过三次挥手。

客户端发送 SYN 报文，请求建立连接（客户端进入请求已发送（SYN-SEND）状态）
服务端收到 SYN 报文，回复 SYN+ACK 报文（服务端进入请求已接受完毕（SYN-RECEIVED）状态）
客户端收到 SYN+ACK 报文，回复 ACK 报文（客户端和服务端同时进入请求建立成功ESTABLISHED）状态）

为什么需要三次握手？两次握手行不行？

假设客户端向服务端发送一个连接请求 A，但是网络环境差，导致 A 报文丢失，TCP 的超时重传会让客户端重新再发一个连接请求 B，此时服务端顺利接收到 B 报文，然后服务端回复一个确认报文，如果此时连接就建立成功的话，客户端和服务端就开始通信，通信结束后断开连接。但 A 报文，有可能再次出现在网络环境中被接收到，此时服务端会再次回复一个确认报文，并进入 ESTABLISHEN 状态，而客户端已经下线，服务端会一直等待客户端的数据通讯，造成资源浪费。

HTTP 协议数据传输

三次握手后建立了连接然后开始http请求，http响应，进行数据传输。

四次挥手

数据传输完，断开连接的时候。

客户端向服务端发送 FIN 报文，请求断开连接（客户端进入 FIN-WAIT-1 状态）
服务端收到 FIN 报文，回复 ACK 报文（服务端进入 CLOSE-WAIT 状态）
服务端将未传输完的数据传输完，向客户端发送 FIN 报文，请求断开连接（服务端进入 LAST-ACK 状态）
客户端接收到 FIN 报文，回复 ACK 报文（客户端进入 TIME-WAit 状态，一段时间后 CLOSEED）

HTTP 协议

从最早的 http0.9 开始，http 0.9 只能传输体积很小的 html 超文本，且只有请求行，没有请求头与请求体，服务端没有返回头信息，返回的内容是以 ASCII 的字符流传输。

http 1.0

后面由于浏览器的出现，发现只有html 不够用了，浏览器还需展示 js，css，图片，音频等，且http支持不仅限于 ASCII 的编码，还需支持多种编码，于是就在 http1.0 中添加了请求头和响应头，增加了Cache 机制和用户代理。http 1.0 需要让浏览器知道服务器返回的内容是什么类型，用了什么压缩方式，浏览器要能告诉服务器自己需要的语言类型以及文件编码类型等。

请求头：
1. accept: text/html (浏览器能接受的类型)
2. accept-encoding: gzip (浏览器能接受的压缩方式)
3. accept-language: zh-CN,zh;q=0.9 (浏览器能接受的语言类型)
4. accept-charset: UTF-8,ISO-8859-1;q=0.7 (浏览器能接受的编码类型)
响应头
1. content-type: text/html; charset=utf-8 (服务器返回的类型)
2. content-encoding: br (服务器用的压缩方式)
3. content-language: zh-CN (服务器用的语言类型)

http状态码：

2xxx: 成功状态

201：成功
204：成功，没有内容
205：成功，报文不包含实体
206：成功，报文只含有实体的一部分

3xxx: 重定向

301：永久重定向
302：临时重定向
303：临时重定向，使用 GET 请求
304：协商缓存

4xxx: 客户端错误

400：客户端请求错误（报文存在语法不对）
401：未授权
403：禁止访问
404：未找到

5xxx：服务器错误

500：服务器内部错误
501：服务器不支持当前所需要的某个功能
502：作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503：服务器暂时处于超负载或正在进行停机维护，无法处理请求（服务器崩了）

http 1.1

http 1.0有个缺点就是每一次请求都要重新通过TCP协议建立连接，导致浪费资源，http 1.1为了解决这个缺点，于是增加了持久连接（一个TCP 连接中传输多个 HTTP 请求），这是主要的，允许建立 6 个TCP持久连接，增加了带宽优化机制，增加了 host 字段，客户端增加了 cookie。

但是建立持久连接，一个TCP连接中传输多个 HTTP 请求，就会造成队头阻塞：一个 TCP 连接中，前面的请求没有返回，后面的请求就会阻塞。

http 2.0

http 1.1的缺陷：

队头阻塞
带宽利用率低（TCP 慢启动，同时建立了 6 个TCP连接导致每个连接之间竞争带宽，HTTP队头阻塞（http请求级别，前面的是数据包级别））

然后 http 2.0为了解决这个问题，采用了多路复用的方法。

多路复用：

一个域名下，只建立一个 TCP 连接
二进制分帧层：将请求全部打包成帧，帧与帧之间互不干扰，并打上编号，服务端可以根据编号的优先级来处理加急的请求。

这个二进制分帧层就相当于你要把西瓜，哈密瓜和菠萝一起放入冰箱，正常的话一次只能放一个，如果前面的卡住后面就只能等，也就是阻塞了，二进制分帧层就是将三个水果切碎来，打上标签，一部分一部分地放，然后再在冰箱里面组合起来。

https 与 http

HTTPS 是 HTTP 的安全版本（HTTP + SSL/TLS），S就是从SSL/TLS（加密）身上的S来的。

TLS加密：

对称加密：两边拥有相同的密钥，两边都知道如何解密
非对称加密：（为了让两边拥有相同的密钥）

客户端生成密钥
服务端生成公钥 + 私钥
服务端将公钥发送给客户端
客户端用公钥加密密钥并传输给服务端

两者是相辅相成的，在数据传输的过程中，为了数据安全考虑，就会给数据加密，加密后为了解密，就需要客户端与服务端都知道如何解密，这个就是对称加密，为了实现这个对称加密，就需要用到非对称加密这种方法。

上面的目的就是使得两边都知道如何解密，也就是获得一个一样的钥匙。客户端生成密钥，服务端生成公钥和密钥，服务器将公钥发送给客户端，客户端使用公钥对自己生成的私钥进行加密，然后传输给服务器，服务器用自己的私钥解密，就获得了客户端的密钥了。

http 3.0

http 2.0 的缺陷：

TCP 的队头阻塞（超时重传）
TCP 慢启动（拥塞控制）
TCP 连接的建立和关闭（耗时）

为了解决以上问题，HTTP采用了QUIC协议：在 UDP 协议的基础上，采用多路复用，快速握手，流量控制，保证数据可靠性和有序性。

面试考点

TCP和UDP的区别：UDP 面向无连接直接传数据，只搬运数据，不保证数据的有序性，可靠性，没有拥塞控制（导致丢包），高效。TCP则需要建立连接，数据有序可靠，慢启动，会进行拥塞控制。
TCP为什么是三次握手？当客户端发送报文 A 给服务器，但是此时网络环境不好，又重新发送了一个报文 B 给服务器，此时服务器接收到 B 然后回复一个确认报文，如果此时就建立成功的话，就开始数据传输，结束后客户端下线，但是 A 报文有可能在网络环境中被接收到，服务端又回复一个确认报文，此时服务端就进入请求建立成功状态，而此时客户端已下线，服务端就会一直等待客户端的网络通信，造成资源浪费。
HTTP 的队头阻塞，怎么解决？采用多路复用，一个域名建立一个TCP连接，二进制分帧层，将请求全部打包成帧，并打上编号，帧与帧之间互不干扰，服务端可以根据编号的优先级来处理加急的请求。
HTTP 和 HTTPS 的区别？HTTPS是HTTP的安全版本（http+SSL/TLS），TLS采用对称加密和非对称加密。
谈谈你对 HTTP 3.0 的理解。采用了QUIC协议，在UDP协议的基础上，采用多路复用，流量控制，保证了数据可靠性和有序性。