应用层

GolangCode约 6395 字大约 21 分钟

1、HTTP、HTTPS

HTTP基本概念

HTTP是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

HTTP报文格式

http协议的请求报文和响应报文结构基本相同，有三部分组成：

起始行（请求行或状态行）：描述请求或响应的基本信息。
头部字段集合：使用key-value形式更详细地说明报文。
消息正文：实际传输的数据，他不一定是纯文本，可以是图片、视频等二进制数据。

状态码分类

常用的状态码：

**200 OK：**是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

**204 No Content：**也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

**206 Partial Content：**是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

**301 Moved Permanently：**表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

**302 Found：**表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

**304 Not Modified：**不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

**400 Bad Request：**表示客户端请求的报文有错误，但只是个笼统的错误。

**403 Forbidden：**表示服务器禁止访问资源，并不是客户端的请求出错。

**404 Not Found：**表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

**500 Internal Server Error：**与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

**501 Not Implemented：**表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

**502 Bad Gateway：**通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

**503 Service Unavailable：**表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

状态码大全

报文首部header（HTTP常见字段）

General
- Connecttion：长连接。
Request
Response
Entity
- Content-Length：本次回应的数据长度。
- Context-Type：本次数据格式。
- Context-Encoding：数据压缩方法。

URI和URL

HTTP连接

1.长连接是怎么实现的？

通过http首部字段Connect:keep-alive实现的。

2.http/1.1对头阻塞是什么？

对头阻塞是由http基本的请求-应答模型导致的，这种模型形成了一个先进先出的队列，如果队首处理时间过长就造成了阻塞。解决方案：1、域名分片，使用多个域名指向同一个服务器。2、并发连接，对同一个域名发送多条长连接。

HTTP状态

1、HTTP无状态协议是保持用户登录状态的？

HTTP是一种无状态协议，意味着每个请求都是独立的。

2、Cookie和Session有什么区别？

Cookie

Cookie是服务器委托浏览器存储的一些数据
响应报文使用Set-Cookie字段发送“key=value”形式的Cookie值
请求报文里使用Cookie字段发送多个Cookie值
为了保护Cookie，还要给他设置有效期、作用域等属性，常用的有Max-Age、Expires、Domain、HttpOnly
Cookie的最基本用途就是身份识别、实现有状态的会话事务

Session

Session代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配ID、会话信息存储、会话检索
生成Session-ID标识对象
Cookie侧重信息存储，Session侧重身份验证

3、禁用Cookie，怎么实现Session？

Session机制默认首选方法时Cookie载体，或URL重写。

4、Session和token的区别？

Session由服务器产生，所有用户信息存储到服务器中，后续交互的均为唯一标识的Session-ID，传输的信息不包含用户身份、状态信息。

token由服务器产生，保存在客户端，token中包含用户身份、状态信息。服务器端通过密钥进行身份验证。

5、分布式场景下用哪种认证方式？

token。

6、JWT是怎么实现的？

jwt有三部分：头部+载荷+签证（header+payload+signature）

header

声明类型，这里为jwt
声明加密的算法，这里是HMAC SHA256

payload

载荷就是存放有效信息的地方。

signature

签证信息。base64加密后的header和payload使用.连接起来，然后通过header中声明的加密方式进行加盐secret组合加密，然后就够成了jwt的第三部分。

HTTPS

HTTP的缺点：

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

HTTP 与 HTTPS 有哪些区别？

HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS并非是应用层的一种新协议，只是HTTP通信接口部分用SSL和TLS代替而已。

重点：HTTPS握手流程（基于RSA(非对称加密)算法的HTTPS流程）

公钥加密只能私钥解，保护数据的机密性。
私钥加密只能用公钥解，验证发送方的身份和数据的完整性。

上图是基于RSA算法的TLS握手(四次)流程：

客户端发送Client Hello，生成并传递客户端的第一随机数；
服务端收到Client Hello，先确认TLS版本是否支持，随后生成服务端的随机数（第二随机数）并传递给客户端同时发送Server Hello，服务端为了证明自己身份同时发送Certificate和公钥，最后发送Server Hello Done。
客户端验证证书并确认身份后，新生成一个随机数（预主密钥），再用服务器的RSA密钥加密，发送给服务端Client Key Exchange，服务端使用私钥解密，获得第三随机数。至此，根据这三个随机数生成会话密钥。随后，客户端发送Change Ciper Spec，Encry pted Handshake Message验证加密通信是否可用。
服务端同客户端验证加密通信是否可用，握手正式完成。

使用RSA密钥协商算法的最大问题是不支持前向保密。

若服务端的私钥丢失，将造成通信解密的问题，所以出现了ECDHE协商算法。

客户端校验数字证书的流程是怎样的？

客户端使用Hash算法获取证书的Hash值H1；
浏览器和操作系统集成了CA的公钥信息，浏览器收到证书后可以使用CA公钥解密，得到H2；
比较H1和H2，如果相同，为可信赖证书。

数字证书

数字证书是由可信任的第三方CA发布的用来证明发送方身份的文档。

数字签名（私钥签名）

数字签名是用来验证证书内容没有被篡改过，且是由可信任的第三方CA颁布的，即证书是真实可信的。

在SSL/TLS协议中，数字证书帮助验证服务器的身份，而数字签名则用于确保通信内容的完整性和不可否认性。

HTTPS一定安全可靠吗？

HTTPS协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是HTTPS不够安全。

HTTP版本

HTTP/1.1：缓存机制，默认keep-alive，明文传输，对头阻塞，不支持服务器推送。

HTTP/2：帧、多路复用、请求优先级、HTTP报头压缩、服务器主动推送资源，具有并发传输能力，解决了HTTP层面的对头阻塞。

HTTP/3：基于UDP协议的QUIC协议，解决了TCP对头的阻塞问题，以及TCP+TLS建立连接的延迟，网络迁移需要重新连接，QPACK解决动态表更新问题。

https 和 http 相比，就是传输的内容多了对称加密，可以这么理解吗？

建立连接时候：https 比 http多了 TLS 的握手过程；
传输内容的时候：https 会把数据进行加密，通常是对称加密数据；

2、DNS（重要）

DNS将域名相互映射的一个分布式数据库，能够使人更加方便地访问互联网。

DNS大概解析过程

浏览器发送解析请求通过DNS客户端解析器到本地DNS服务器；（递归查询）
本地DNS服务器咨询根域名服务器，并返回 .com 服务器地址；（接下来使用迭代查询域名对应的IP地址）
本地DNS服务器咨询com域名服务器(顶级域名)，并返回xxx.com服务器地址;
本地DNS服务器咨询xxx.com服务器地址(权威域名)，并返回该域名对应的IP地址。

DNS的完成查询过程

浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果有该解析过程将会结束。浏览器缓存域名也是有限制的，包括缓存的时间、大小，可以通过TTL属性来设置。
如果用户的浏览器缓存中没有，操作系统会先检查自己的本地DNS解析器缓存和hosts文件是否有这个网址映射，如果有，就先调用这个IP地址看，完成域名解析。
如果都没有，会找TCP/IP参数中设置的首选DNS服务器（本地DNS服务器），通过递归查询的方式向本地DNS服务器发起查询，如果本地DNS服务器中有A记录或者该域名的映射缓存，则返回。
如果都没有，本地域名服务器会开始迭代查询。

说说递归查询和迭代查询？优缺点？什么时候使用？

递归查询

DNS客户端向DNS解析服务器发送查询请求，DNS服务器会进行递归查询IP地址。

方便、高效。服务器负载高、延迟大。适用用请求解析。

迭代查询

DNS服务器去查询根域名服务器、顶级域名服务器、权威域名服务器。

减轻服务器负担、灵活性高。客户端复杂性增加、性能影响。在DNS服务器之间使用。

DNS劫持和污染

域名屏蔽，对域名直接不解析，返回错误，让你无法拿到IP地址，也就无法访问网站。

域名劫持，也叫域名污染，你要访问A网站，但DNS给了你B网站。

DNS是基于UDP还是TCP？什么时候用UDP什么时候用TCP？

DNS同时使用了TCP和UDP协议的53端口。使用UDP传输不需要三次握手，响应更快。

当传输数据大于UDP最大报文长度的时候使用TCP协议。

DNS在区域传输和DNS响应大于UDP报文最大长度的时候使用TCP协议，其他时候用UDP协议。

3、RPC、CDN

RPC是什么？有什么作用？

远程过程调用。

屏蔽远程调用和本地调用的区别，让我们感觉就是调用项目内的方法，隐藏底层网络通信的复杂性，让我们更专注于业务逻辑。

一个RPC的调用流程（你能否给我解释下RPC的通信流程）

服务提供方和服务调用方都注册到注册中心。

服务调用方把请求参数对象序列化。

服务调用方从注册中心拉取服务提供方的地址列表。

服务调用方根据负载均衡策略选择一个服务提供方，发起网络调用（gRPC基于HTTP2进行网络传输）。

服务提供方从TCP通道接收二进制数据，根据协议约定进行反序列化。服务提供方通过反射找到接口，执行调用。服务提供方得到的调用结果，进行序列化，网络传输给客户端。

客户端接收二进制数据，反序列化得到调用结果。

既然有了HTTP协议，为什么还要有RPC？

TCP的三大特点：面向连接、可靠的、基于字节流。

基于字节流：这会导致在发送数据的时候全是01串是没有边界的，不知道到那个地方算是一条消息。所以要加一些自定义的规则，用于区分消息边界。

从发展历史来说，HTTP主要用于B/S架构，而RPC主要用于C/S架构，但现在其实已经没分的那么清了，B/S和C/S在慢慢融合。很多软件支持多端，所以对外一般使用HTTP，而内部集群的微服务之间采用RPC协议。

gRPC和RPC有什么区别？grpc和HTTP有什么区别？

gRpc其实不是一个协议，它其实是一个框架，gRPC本身使用的是protobuf协议，它的本质就是基于HTTP2.0实现的，也就说这个问题就是HTTP2.0和1.0的区别：

2.0使用了头部压缩，如果头部信息相同的话，会删除，然后使用了hpack算法，客户端和服务端会维护一张表记录头部信息，只要带着索引号就可以了；
2.0使用了二进制格式，对计算机更友好，传输效率更高；
2.0引入了stream的概念，可以并发传输，1.0之前是一条tcp连接断开后才可以进行下一条连接，2.0多个stream可以复用一条tcp连接，但是由于本身tcp窗口的问题，它也有对头阻塞的问题。
2.0服务端可以主动推送资源给客户端。

json和protobuf的区别？

protobuf协议既支持HTTP请求也支持grpc请求，如果内部微服务，而且传输的数据量很大的时候推荐使用protobuf协议，因为内部服务的调用走grpc的延迟在ns之间，而HTTP请求是在ms，而且二进制格式会将数据压缩到很小。如果是对外提供接口的话，更多的是HTTP请求，使用json协议。

HTTP

1.HTTP协议的特点？

HTTP具有简单、灵活可扩展、无状态等特点，是一种广泛应用于web通信的协议。

基于文本（HTTP/1.1）
可扩展
灵活性
请求应答模式
无状态

2.HTTP报文格式？怎么分割的？

HTTP报文格式为请求行、请求头、请求体三个部分。

请求行是请求或响应的基本信息，比如请求方法、url、http 版本信息。
请求头使用key-value形式更详细地说明报文，比如host字段、Connection字段。
请求体是实际传输的数据，比如文本数据、图片数据。

请求行和请求头是通过\r\n分割，请求头和请求行是通过空白行分割的，也就是两个连续的\r\n。

3.HTTP那些方法是安全的或者幂等的？

安全的方法：GET、HEAD
不安全的方法：POST、DELETE、PUT
幂等的方法：GET、HEAD、DELETE、PUT
不幂等的方法：POST

4.GET和POST请求的区别？GET请求一定安全且幂等吗？

GET请求是从服务器获取资源，POST请求是向服务器提交数据。
GET方法是只读操作，所以安全且幂等的，而POST方法会修改服务器上的资源，并且多次POST请求，会创建多个资源，所以不是安全的，也不是幂等的。
GET请求的请求参数放在url中的查询字符串中，浏览器对url长度限制，所以GET请求参数会有长度限制，而POST请求参数是放在请求体中，POST请求参数长度没有限制。

不一定。要看实际的GET请求，如果开发者遵循了规范去处理请求，也就是GET请求的实现是获取资源，那么就是安全且幂等的，但是如果开发者处理GET请求的方式是新增数据，这时候请求就不是安全且幂等的。

5.HTTP有什么状态码？

HTTP状态码共有5类：

数字1开头的状态码表示目前是协议处理的中间状态，还需要后续操作，比如客户端请求服务端从HTTP切换为WebSocket通信的时候，服务端如果同意切换，就会返回101状态码。
数字2开头的状态码表示服务器收到并成功处理了客户端的请求，比如200状态码是代表服务端成功响应了客户端的请求。
- 204，与200类似，但响应头没有body数据。
- 206，分块下载，断点续传。
数字3开头的状态码表示服务端的资源发生了变动，需要进行重定向。
数字4开头的状态码表示客户端错误，表示客户端发送的请求报文有错误。
- 400，请求报文有错误。
- 403，服务器资源权限不够。
- 404，服务器上没有该资源。
数字5开头的状态码是服务端错误，服务器内部发生错误（一般情况下，5xx的状态码其实并不是服务器返回给客户端的，而是由网关返回的，比如nginx）。
- 500，代表服务器程序错误。
- 501，服务器不具备完成请求的功能
- 502，网关或代理错误，访问后端服务器发生错误。
- 503，服务器繁忙。
- 504，Gateway Timeout。

HTTPS

1.HTTP和HTTPS有什么区别？

我认为HTTPS和HTTP主要有4个方面的区别：

安全性：HTTP是明文传输协议，数据在传输过程中不加密，容易被窃听和篡改。而HTTPS通过使用SSL/TLS协议对数据进行加密，提供了更高的安全性和数据保护。
建立连接：HTTP连接建立相对简单，TCP三次握手之后便可以进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才可以进入加密报文传输。
端口号：HTTP默认为80，HTTPS默认为443.
证书：HTTPS需要使用数字证书来验证服务器的身份，并确保数据传输的安全性。证书由受信任的第三方机构颁发，用于证明服务器的身份和所有权。而HTTP没有使用证书进行身份验证和加密。

2.了解过那些加密算法？

我主要了解对称加密算法、非对称加密算法、哈希算法这三种加密算法。

在HTTPS协议里，对称加密算法和非对称加密算法这两种算法都会用到，对称加密算法进行加密解密，比如AES算法，非对称加密则是有两个密钥，公钥和私钥，比如RSA算法。对称加密算法适用于大量数据的加密和解密，而非对称加密算法适用于密钥交换和数字签名等场景。
哈希算法主要用过MD5算法，哈希算法是一种单向算法，用户可以通过哈希算法对目标信息生成一段特定长度的唯一哈希值，却不能通过这个哈希值重新获得目标信息，所以用于数据完整性校验方面。

3.对称加密和非对称加密是什么？各自有哪些算法？

对称加密和解密都是用同一个密钥进行操作，加密和解密过程速度较快，适合对大量数据进行加密，对称密钥必须保密，不能明文传输，常见的对称加密算法有AES、DES等。

非对称加密使用两个密钥，分别是公钥和私钥，加密和解密过程相对较慢，适合对少量数据进行加密。公钥可以任意分发，而私钥必须保密，可以通过公钥加密，私钥解密的方式，保证对称密钥的安全传输，常见的非对称加密算法有RSA、ECC等。

4.对称和非对称的加密算法的区别？

对称加密和解密都是用同一个密钥进行操作，加密和解密过程速度较快，适合对大量数据进行加密，对称密钥必须保密，不能明文传输。
非对称加密使用两个密钥，分别是公钥和私钥，加密和解密过程相对较慢，适合对少量数据进行加密。公钥可以任意分发，而私钥必须保密，可以通过公钥加密，私钥解密的方式，保证对称密钥的安全传输。

HTTPS采用的就是这样的混合加密方式：

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

5.假设有一个文件，大小未知，现在要把它上传到云端，该使用对称加密还是非对称加密？

使用对称加密算法比较好，因为对称加密算法运算速度是比非对称加密更快的，比较适合数据量大常见的加密。

6.HTTPS建立过程是怎样的？

首先，客户端和服务端先进行TCP三次握手建立TCP连接。接下来，进行TLS四次握手：

第一次TLS握手：客户端先会发送一个Client Hello消息，消息里面有客户端使用的TLS版本号、支持的密码套件列表、客户端生成的随机数，这个随机数是用来后面生成对称密钥元素之一。
第二次TLS握手：当服务端收到客户端的消息后，会返回Server Hello消息给客户端，消息里面有服务器确认的TLS版本号、密码套件、服务端生成的随机数。接着服务端为了证明自己的身份，会发送Server Certificate给客户端，这个消息里含有数字证书。随后，服务端发送Server Hello Done消息，目的是告诉客户，我已经把该给你的东西都给你了，本次握手完毕。
- 校验证书：客户端收到服务端的数字证书的时候，会校验服务端的证书，如果证书是合法的，客户端会用CA结构的公钥解密数字证书拿到服务端的公钥。
第三次TLS握手：客户端再次生成一个随机数，用服务端的公钥加密后，通过Client Key Exchange 消息传给服务端。服务端收到后，用服务端的私钥解密得到客户端的第二个随机数。到这里，服务端和客户端双方都有3个随机数，双方根据已经得到的三个随机数，会根据算法生成对称密钥。生成对称密钥后，客户端会发一个消息告诉服务端开始使用对称加密方式发送消息，并且还会对之前所有发送的数据做个摘要，再用对称加密加密一下，让服务器做个验证，验证对称加密是否可用，以及之前握手信息是否有被中途篡改。
第四次TLS握手：服务器也是同样的操作，发送消息告诉客户端开始用对称加密方式发送消息，并且也会对数据做个摘要，并用对称加密加密一下，让客户端做个校验，如果双方都验证加密和解密没问题，那么TLS四次握手正式完成。

最后，就用对称加密和解密HTTP请求和响应了。

参考资料

https://xiaolincoding.com/network/