TCP的三次握手

参考链接
https://img-blog.csdnimg.cn/20210427222207169.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70#pic_center" alt="在这里插入图片描述" />

1. TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
2. TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。
3. TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。
4. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。
5. 当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

什么是syn攻击？如何防范？

攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当这个服务器返回ACK以后，攻击者不再进行确认，那这个连接就处在了一个挂起的半连接状态，那么服务器收不到再确认的一个消息，还会重复发送ACK给A。这样一来就会造成服务器的浪费。

1、最常用的一个手段就是优化主机系统设置。比如降低SYN timeout时间，使得主机尽快释放半连接的占用；
2、采用SYN cookie设置，如果短时间内收到了某个IP的重复SYN请求，我们就认为受到了攻击。我们合理的采用防火墙设置等外部网络也可以进行拦截。

为什么要是三次挥手不是四次或者两次？

原文链接

三次握手主要目的是：1、由于网络状态不稳定，三次握手就是为了解决网络不稳定状态下的保证信息的高效传输。防止消耗过多服务端资源。

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
四次握手没有必要，虽然要保证双向链路可能需要四次握手，但实际上服务端给客户端的 SYN 和 ACK 数据包可以合为一次握手，所以实际上只需要三次握手即可。

TCP的四次挥手

引用链接跳转
https://img-blog.csdnimg.cn/2021042722381152.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70#pic_center" alt="在这里插入图片描述" />
数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入**FIN-WAIT-2（终止等待2）**状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了**LAST-ACK（最后确认）**状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

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

虽然要保证双向链路可能需要四次握手。但是在建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

TCP吃close_wait

FIN(finish)
在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。

TCP 在四次挥手的过程中为什么客户端最后还要等待 2MSL(Maximum Segment Lifetime)？

引用链接跳转.

https://img-blog.csdnimg.cn/2021042722590010.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />

因为客户端要保证他的 ACK 包顺利到达服务端，如果客户端的ACK数据包丢失，则服务端或重新发送 FIN 包到客户端，而这两个过程的最长时间为 1MSL，加起来为 2MSL，如果 2MSL 后客户端还没有收到服务端重发的 FIN 包，则说明 ACK 包顺利到达，可以关闭连接了。

TCP 在握手阶段怎么管理客户端的连接？

链接
TCP 在握手阶段服务端维护了两个队列：半连接队列和全连接队列

• 半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求)，syn攻击会使得半连接队列队满。在客户端发起第一次握手时，服务端会把此请求放入半连接队列，并回复SYN+ACK 到客户端

全连接队列（accpetd队列）用来保存处于established状态。第三次握手时，服务端将此连接加入到全连接队列 如果全连接队列满，则服务端的处理方式和tcp_abort_on_overflow 参数的设置有关，如果该参数为 0，则丢弃该 ACK，如果为 1 则发送 RST 到客户端，直接放弃此次连接。

全连接队列、半连接队列溢出很容易忽视，对于一些短连接应用（比如Nginx、PHP）更容易爆发。一旦溢出，Server端从cpu、线程状态看负载正常，但压力上不去。而Client端看来,请求耗时较高，但server端记录的服务响应又很短，同时客户端会不定期出现连接超时、socket 读写超时 的现象。

防止连接队列溢出是思路：
对TCP连接失败，增加重试机制和超时时间

启用长连接机制 (可减少连接环节开销,从而降低延时)

TCP 通过哪些方式来保证数据的可靠性

链接
在数据包层面：校验和
在数据包传输层面：序列号、确认应答、超时重传
在流量控制层面：拥塞控制

1.校验和(数据安全性)

计算方式：在数据传输的过程中，将发送的数据段都当做一个 16 位的整数。将这些整数加起来。并且加上进位，最后取反，得到校验和。
TCP 与 UDP 校验方式相同

2.序列号、确认应答、超时重传

序列号：
TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。

确认应答：
接收端实体对已成功收到的字节发回一个相应的确认（ACK）；

超时重传：
如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据（假设丢失了）将会被重传。

在数据包传输的过程中，每个数据包都有一个序列号，当数据到达接收方时，接收方会发出一个确认应答，表示收到该数据包，并会说明下一次需要接收到的数据包序列号(32 位确认序列号)。如果发送端在一段时间内(2RTT 没有收到确认应答，则说明可能是发送的数据包丢失或者确认应答包丢失，此时发送端会进行数据包重传。

但发送端并不是一定要等到接收到上一个数据包的确认应答再发送下一个数据包，TCP 会利用窗口控制来提高传输速度，在一个发送窗口大小内，不用一定要等到应答才能发送下一段数据，发送窗口大小就是无需等待确认而可以继续发送数据的最大值。而发送窗口的大小是由接收端的接受窗口的剩余大小和拥塞窗口来决定的。(TCP 会话的双方都各自维护一个发送窗口和一个接收窗口)

3.拥塞控制(保证高效性）

滑动窗口、慢启动、拥塞避免、快速重传、快速恢复
发送端维持一个叫做拥塞窗口 cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送端让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。
TCP 的拥塞控制主要是采用慢启动以及增性加，乘性减的机制，TCP一开始将拥塞窗口设置的很小，在逐渐经过一段时间的指数增长后超过门限，进入增性加阶段，此时窗口大小的增长是线性的，比之前的指数增长要慢很多，而当发生网络拥塞时，拥塞窗口大小直接减半（乘性减）。
快速重传是对超时重传的改进。当源端收到对同一个报文的三个重复确认时，就确定一个报文段已经丢失，因此立刻重传丢失的报文段，而不必等到重传定时器（RTO）超时。以此减少不必要的等待时间。
快速恢复是对丢失恢复机制的改进。在快速重传之后，不经过慢启动过程而直接进入拥塞避免阶段。

拥塞控制算法
超时重传和快速重传的概念
https://img-blog.csdnimg.cn/3dc06da904cc49f49f9a2425770baa85.png?x-oss-process=image/watermark,type_ZHJvaWRzYW5zZmFsbGJhY2s,shadow_50,text_Q1NETiBATWVubGxlbnkt5ZWKTeeahOaxgueUn-S5i-i3rw==,size_20,color_FFFFFF,t_70,g_se,x_16" alt="在这里插入图片描述" />

慢启动：
初始化滑动窗口(cwnd)打下为m，每次接收到一个数据包确认 cwnd = cwnd + 1。没经过一个RTT(round-trip time), cwnd = cwnd* 2；
拥塞避免
当cwnd的值到阈值(ssthresh),开始拥塞避免增长过程：发送方每收到一个ACK数据包时将cwnd=cwnd+1/cwnd，每经过一个RTT将cwnd自增1。
超时重传
当经过一个RRT，发送方没有收到确认消息。则发送方会将数据包进行重新发送。此时cwnd = m，ssthresh设置为cwnd的一半，并又恢复到慢启动过程。
快速重传
快速重传发生在：收到比当前待确认的数据包序列号更大的序列号的确认消息时(如待接收的包序列号是8，但是却已经收到9的确认应答包)。
快速重传和超时重传的区别在于cwnd在发生拥塞时的取值。超时重传会将cwnd修改为最初的值m，也就是慢启动的值，快速重传将cwnd减半，并将进入到拥塞避免阶段。二者都将ssthresh设置为cwnd的一半(快速重传的cwnd应该是比ssthresh的大的，应该是进入拥塞避免阶段，这个阶段叫做快速恢复)。

TCP 长连接和短连接有什么区别？

链接
TCP 短连接是指客户端与服务端连接后只进行一次读写就关闭连接，一般是客户端关闭。
而长连接则是指在进行完一次读写后不关闭连接，直到服务端压力过大则选择关闭一些长时间为进行读写的连接。

TCP 短连接的优点在于管理简单，而且不会对服务端造成太大的压力，而缺点是每次读写都需要连接耗时较长。

TCP 长连接的优点是可以迅速进行多次读写，缺点是对服务端压力大，且容易被恶意连接影响服务。

长短连接的区别就在于客户端和服务端选择的关闭策略不同，具体需要根据应用场景来选择合适的策略。

TCP 粘包、拆包及解决方法？

链接
TCP是个“流”协议，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分。操作系统在发送TCP数据的时候，底层会有一个缓冲区，例如1024个字节大小，如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题；如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包，也就是将一个大的包拆分为多个小包进行发送。

由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：

1. 消息定长。发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
2. 设置消息边界。服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如FTP协议。
3. 将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段。

详细描述一下从我们在浏览器中输入网址到最后看到网页，这个过程中发生了什么？

链接
浏览器在拿到 url 时，首先会对 url 进行解析，将域名与实际的文件路径分离，然后需要使用 DNS 协议，通过域名得到 IP 地址。
浏览器会查询浏览器缓存，如果有这个网址的缓存就可以直接获取到 IP，如果没有就进一步访问本机缓存，如果本机缓存也没有才会发起 DNS 请求。
而 DNS 的服务器是一个树状结构，对于域名来说是倒着进行解析的，根节点是根 DNS 服务器，他的子节点为 com、cn 这种顶级域 dns 服务器，然后进一步向下进行解析。
以 baidu.com 为例，当我们的电脑需要发起 DNS 请求的时候，会先对根 DNS 服务器发起请求，这个服务器的 IP 地址一般在每台电脑上都有，我们一般会设置为 8.8.8.8 或者 114.114.114.114，我们的电脑在访问根 DNS 服务器后，会得到 con 域 DNS 服务器的 IP，然后会继续访问 con 域 DNS 服务器，这时就能得到 baicu.com 的 IP 地址了。

得到 ip 后浏览器会先与服务器通过 TCP 三次握手建立连接，然后构建 HTTP 请求。
在解析 url 时，我们能获取到需要请求资源的资源路径、端口号、请求参数等信息，这些信息会被存储在 http 头中，通过 DNS 请求获取到 ip 后，浏览器会构建并发送 HTTP 请求或者 HTTPS 请求，HTTPS 就是在 HTTP 的基础上加了一个 TLS 协议来进行数据加密，这个我们待会说。
HTTP 请求有很多种，但对资源的操作离不开增删改查，也就对应着 POST、DELETE、PUT、GET 请求。最常用的是 GET 和 POST，其区别在于 GET 的参数是在 url 中的，而 POST 的参数是在请求的 body 中。
以 GET 为例，当需要发送 HTTP 请求的时候，同样也不是直接就发送了，需要先查询浏览器缓存。浏览器中的缓存分为强缓存和协商缓存，浏览器发起 HTTP 请求时首先会根据 http 头信息来判断是存有强缓存，以及其是否过期，如果有强缓存且未过期则命中，不会发送请求到服务器了。如果强缓存没命中，则会向服务器发起请求，这个请求的 Header 头中会带有浏览器最后一次请求该资源的时间和一个资源校验码(使用资源修改时间、资源大小等信息生成)，服务器收到这个请求后会判断协商缓存是否过期，如果过期则返回新的资源信息，如果没过期则返回 304 状态码，表示资源未更新，可以使用缓存中的资源。

HTTP 请求发出后会将数据包交给下层协议栈处理，在传输层和网络层该数据包会被分别加上 TCP 头和 IP 头，并且被发送出去，沿路的网关会收到这个数据包并进行识别和转发，直到该数据包被服务器收到，通过相同的流程返回回复数据包。

一般来说，浏览器第一次从服务器请求的资源都是一个 HTML 文件，例如服务端默认的 index.html 等，浏览器获取到这个 HTML 文件就会对其进行解析，构建出一棵DOM树，并通过执行其中的 js 代码发起更多的请求，请求渲染页面需要的其他资源，CSS 或者一些外链的图片等，拿到 CSS 后将其与 DOM 树结合进行更进一步的渲染，我们就能看到页面了。

最后再补充一下 HTTPS，由于 HTTP 是使用信息明文传播，所以会有窃听、篡改、冒充等风险，所以 HTTPS 在 HTTP 的基础上加上了 SSL 层，通过加密的方式来保证数据安全。
SSL 通过加密防止窃听，通过签名来防止篡改，通过证书来防止冒充。
HTTPS 协议在客户端与服务端开始通信前，会进行密钥协商，通过一轮非对称加密，一般是RSA加密来传递后序通信过程使用的对称密钥，由于非对称加密较慢，后续通信过程中使用对称加密。在密钥协商的过程中，服务端会将自己的证书发送给客户端，客户端会到 CA 机构通过摘要值验证证书的合法性，从而防止中间人攻击。

http_167">什么是http协议？

HTTP协议，它是基于TCP协议的应用层传输协议，简单来说就是客户端和服务端进行数据传输的一种规则。
HTTP 是一种无状态 (stateless) 协议,这样做的目的是提高效率。
HTTP的五大特点
1、支持客户/服务器模式。
2、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4、无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。早期这么做的原因是请求资源少，追求快。后来通过Connection: Keep-Alive实现长连接
5、无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

httpmethod_176">http协议的method(请求方法)

GET： 请求获取Request-URI所标识的资源
POST： 在Request-URI所标识的资源后增加新的数据 HEAD： 请求获取由Request-URI所标识的资源的响应消息报头
PUT： 请求服务器存储或修改一个资源，并用Request-URI作为其标识
DELETE： 请求服务器删除Request-URI所标识的资源

get和post的区别

get和post都是http请求的method参数，他们都是http协议。
1、get方法的数据一般都会选择放在url上，post数据放在body中，虽然http协议并没有这样的规定，但这是浏览器Ajax api实现时的约定方法。
2、get对用户来说是明文的，因为数据在url中，post数据body中，对于用户来说是看不到的。但其实http协议本身就是明文传输的，因此无论是get还是post，都是不安全的，因此需要使用https协议保证数据安全性。
3、浏览器能接受的url长度较小，而body大概能发送2GB数据。
4、GET的参数只能支持ASCII，而POST能支持任意binary，包括中文。但是其实无论是get还是post的http都有body。

http_190">http的状态码有哪些？

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值： 1xx：指示信息 - 表示请求已接收，继续处理 2xx：成功 - 表示请求已被成功接收、理解、接受 3xx：重定向 - 要完成请求必须进行更进一步的操作 4xx：客户端错误 - 请求有语法错误或请求无法实现 * 5xx：服务器端错误 - 服务器未能实现合法的请求

200： OK - 客户端请求成功
400： Bad Request - 客户端请求有语法错误，不能被服务器所理解
401： Unauthorized - 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403： Forbidden - 服务器收到请求，但是拒绝提供服务
404： Not Found - 请求资源不存在，eg：输入了错误的URL
500： Internal Server Error - 服务器发生不可预期的错误
503： Server Unavailable - 服务器当前不能处理客户端的请求，一段时间后,可能恢复正常

httpshttps_202">什么是https?https如何防范网络攻击的？

链接
HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程，数据全部明文传输。
https://img-blog.csdnimg.cn/20210507001447268.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70#pic_center" alt="在这里插入图片描述" />
所以 HTTP 传输面临的风险有：

（1） 窃听风险：黑客可以获知通信内容。

（2） 篡改风险：黑客可以修改通信内容。

（3） 冒充风险：黑客可以冒充他人身份参与通信。

HTTPS是在HTTP的基础上和tls证书结合起来的一种协议,保证了传输过程中的安全性。

链接
链接

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

https://img-blog.csdnimg.cn/20210629143344437.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？
使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法

https链接过程

1. 客户端请求服务端的数字证书。
2. 客户端根据内置的根证书校验服务端发来的证书。
3. 如果证书可信，客户端把自己的公钥发给服务端，然后用双方的公钥推导出一个会话密钥。
4. 后续的请求内容都用会话密钥进行加密和解密。

我的理解：
证书验证过程:
1、返回证书->验证证书，该步骤使用非对称加密，证书编号使用第三方机构使用的没对称加密算法加密，除此之外还包括证书名称、证书公钥等
https://img-blog.csdnimg.cn/20210630164031685.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />
2、判断证书是否合法，使用客户端保存的第三方机构公钥进行解密，使用hash算法对证书进行hash能得到证书编号，然后用公钥加密后的证书编号进行解密。

3、随机数就是salt，由于使用对称加密算法容易被破解，因此需要使用随机数，这个随机数也是之前证书验证那么多步骤的结晶…

https_241">https的秘钥

1、对称加密

有流式、分组两种，加密和解密都是使用的同一个密钥。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。
特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

网络的分层模型

应用层：应用层是所有用户所面向的应用程序的统称,如我们进行万维网（WWW）访问用到了HTTP协议、文件传输用FTP协议、
传输层：提供应用程序间的通信，在这一层的协议有TCP和UDP。
网络层：主要定义了IP地址格式，从而能够使得不同应用类型的数据在Internet上通畅地传输，IP协议就是一个网络层协议。
链接层：负责接收IP数据包，解读0和1。如以太网协议
实体层：传送0和1的信号，可用光缆、电缆、无线电波等方式

socket的作用

链接

当客户端和服务器使用TCP协议进行通信时，客户端封装一个请求对象req，将请求对象req序列化成字节数组，然后通过套接字socket将字节数组发送到服务器，服务器通过套接字socket读取到字节数组，再反序列化成请求对象req，进行处理，处理完毕后，生成一个响应对应res，将响应对象res序列化成字节数组，然后通过套接字将字节数组发送给客户端，客户端通过套接字socket读取到字节数组，再反序列化成响应对象。
https://img-blog.csdnimg.cn/2021071921195577.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5ODYzMDkz,size_16,color_FFFFFF,t_70" alt="在这里插入图片描述" />

cookie 和 session 的区别

链接
推荐好好看看链接

Cookie 与 Session 的区别
二者都是用来跟踪浏览器用户身份的会话方式。

Cookie：
存在浏览器里，可以设置过期时间
每次访问服务器时，浏览器会自动在 header 中携带 cookie
如果浏览器禁用了 cookie，可以使用 URL 重写机制，将信息保存在 URL 里
Session:
存在服务端，由服务器维护，一段时间后 session 就失效了
本质上，session 还是通过 cookie 实现的。浏览器的 cookie 中只保存一个 sessionId，所有其他信息均保存在服务端，由 sessionId 标识
Session 失效，其实是服务器设置了失效时间。如果用户长时间不和服务器交互（比如 30 分钟），那么 session 就会被销毁；交互的话，就会刷新 session
Session 的实现 - labuladong