目录

1. http2.0

2. Http与Https的基本概念和他们的区别

3. HTTPS工作原理

4. 常用的HTTP方法

5. GET方法与POST方法的区别

6. HTTP请求报文与响应报文格式

7. 常见的HTTP状态码

8. 一个页面从输入 URL 到页面加载显示完成，这个过程中都发生了什么？

9. HTTP优化方案

10. localStorage. sessionStorage、 Cookie不同点

11. get和post请求在缓存方面的区别

12. cookie session区别

13. cookie属性

14. https详细过程

15. TCP拥塞控制

16. TCP和UDP

17. **两个不同tab页面之间如何请求交互

18. tcp链接为什么不能为两次握手

19. tcp攻击与防范

20. 301和302状态码

21. http2.0头部压缩

22. TCP的三次握手和四次挥手，为什么不是两次握手？为什么挥手多一次呢

23. 网络中的ACK； SYN； FIN都是什么

24. http浏览器缓存机制
    25. 304状态码

25. 500状态码具体场景

26. DNS原理

27. CND原理

28. osi七层模型每层分别是什么，http在哪层，tcp在哪层

29. HTTP协议的ETag

30. head和get的区别

31. *ssl握手过程，非对称加密和对称加密的区别

32. *前端缓存

33. 滑动窗口
    35. 前端安全

34. 计算机网络的五层协议

35. HTTPS为什么要使用一个对称加密和非对称加密相结合
    39.Http与Https的基本概念和他们的区别

36. tcp粘包

37. restful级别

1. http2.0

首先补充一下，http和https的区别，相比于http,https是基于ssl加密的http协议
简要概括：http2.0是基于1999年发布的http1.0之后的首次更新。
提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比http1.0）

允许多路复用：多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息。改善了：在http1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。

二进制分帧：HTTP2.0会将所有的传输信息分割为更小的信息或者帧，并对他们进行二进制编码，他采用二进制格式传输数据而不是1.x的文本格式。

头部压缩
1.x版本中，首部用文本格式传输
2.0版本采用HPACK压缩格式压缩头部
（静态字典）索引
服务器端推送
服务器端推送使得服务器可以预测客户端需要的资源，主动推送到客户端。
例如：客户端请求index.html，服务器端能够额外推送script.js和style.css。
实现原理就是客户端发出页面请求时，服务器端能够分析这个页面所依赖的其他资源，主动推送到客户端的缓存，当客户端收到原始网页的请求时，它需要的资源已经位于缓存。
针对每一个希望发送的资源，服务器会发送一个PUSH_PROMISE帧，客户端可以通过发送RST_STREAM帧来拒绝推送（当资源已经位于缓存）。这一步的操作先于父响应（index.html），客户端了解到服务器端打算推送哪些资源，就不会再为这些资源创建重复请求。当客户端收到index.html的响应时，script.js和style.css已经位于缓存。

2. TCP三次握手与四次挥手

三次握手
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：

• 确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

• 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

握手之前主动打开连接的客户端结束CLOSED阶段，被动打开的服务器端也结束CLOSED阶段，并进入LISTEN阶段。随后开始“三次握手”：

（1）首先客户端向服务器端发送一段TCP报文，其中：

标记位为SYN，表示“请求建立新连接”;
序号为Seq=X（X一般为1）；
随后客户端进入SYN-SENT阶段。
（2）服务器端接收到来自客户端的TCP报文之后，结束LISTEN阶段。并返回一段TCP报文，其中：

标志位为SYN和ACK，表示“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接”（即告诉客户端，服务器收到了你的数据）；
序号为Seq=y；
确认号为Ack=x+1，表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值；随后服务器端进入SYN-RCVD阶段。
（3）客户端接收到来自服务器端的确认收到数据的TCP报文之后，明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文。其中：

标志位为ACK，表示“确认收到服务器端同意连接的信号”（即告诉服务器，我知道你收到我发的数据了）；
序号为Seq=x+1，表示收到服务器端的确认号Ack，并将其值作为自己的序号值；
确认号为Ack=y+1，表示收到服务器端序号Seq，并将其值加1作为自己的确认号Ack的值；
随后客户端进入ESTABLISHED阶段。
服务器收到来自客户端的“确认收到服务器数据”的TCP报文之后，明确了从服务器到客户端的数据传输是正常的。结束SYN-SENT阶段，进入ESTABLISHED阶段。

在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性。一旦出现某一方发出的TCP报文丢失，便无法继续"握手"，以此确保了"三次握手"的顺利完成。

此后客户端和服务器端进行正常的数据传输。这就是“三次握手”的过程。

为什么要进行第三次握手？
为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了SYN=1创建连接的请求(第一次握手)。

如果服务器端就直接创建了这个连接并返回包含SYN、ACK和Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，

服务器端是不知道客户端有没有接收到服务器端返回的信息的。

这个过程可理解为：

这样没有给服务器端一个创建还是关闭连接端口的请求，服务器端的端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。那么服务器端上没有接收到请求数据的上一个端口就一直开着，长此以往，这样的端口多了，就会造成服务器端开销的严重浪费。

还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。

所以我们需要“第三次握手”来确认这个过程，让客户端和服务器端能够及时地察觉到因为网络等一些问题导致的连接创建失败，这样服务器端的端口就可以关闭了不用一直等待。

也可以这样理解：“第三次握手”是客户端向服务器端发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。若发送的这个数据是“收到了”的信息，接收后服务器就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

抓包验证
下面是用抓包工具抓到的一些数据包，可用来分析TCP的三次握手：

注意到”第一次握手”客户端发送的TCP报文中以[SYN]作为标志位，并且客户端序号Seq=0；

接下来”第二次握手”服务器返回的TCP报文中以[SYN，ACK]作为标志位；并且服务器端序号Seq=0；确认号Ack=1(“第一次握手”中客户端序号Seq的值+1);

最后”第三次握手”客户端再向服务器端发送的TCP报文中以[ACK]作为标志位；

其中客户端序号Seq=1（“第二次握手”中服务器端确认号Ack的值）；确认号Ack=1(“第二次握手”中服务器端序号Seq的值+1)。

这就完成了”三次握手”的过程，符合前面分析的结果。

四次挥手

标记位为FIN，表示“请求释放连接“；
序号为Seq=U；
随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。并且停止在客户端到服务器端方向上发送数据，但是客户端仍然能接收从服务器端传输过来的数据。
注意：这里不发送的是正常连接时传输的数据(非确认报文)，而不是一切数据，所以客户端仍然能发送ACK确认报文。

（2）服务器端接收到从客户端发出的TCP报文之后，确认了客户端想要释放连接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：

标记位为ACK，表示“接收到客户端发送的释放连接的请求”；
序号为Seq=V；
确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值；
随后服务器端开始准备释放服务器端到客户端方向上的连接。
客户端收到从服务器端发出的TCP报文之后，确认了服务器收到了客户端发出的释放连接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了

（3）服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文，其中：

标记位为FIN，ACK，表示“已经准备好释放连接了”。注意：这里的ACK并不是确认收到服务器端报文的确认报文。
序号为Seq=W；
确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1作为本段报文确认号Ack的值。
随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。并且停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。

（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：

标记位为ACK，表示“接收到服务器准备好释放连接的信号”。
序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值作为本段报文序号的值。
确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值作为本段报文确认号的值。
随后客户端开始在TIME-WAIT阶段等待2MSL

为什么要客户端要等待2MSL呢？见后文。

服务器端收到从客户端发出的TCP报文之后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的连接。

客户端等待完2MSL之后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。

后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。

与“三次挥手”一样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样做保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便无法继续"挥手"，以此确保了"四次挥手"的顺利完成。

为什么“握手”是三次，“挥手”却要四次？
TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

为什么客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文

当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。

服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；

如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；
否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。

所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因

3.HTTPS工作原理

1.Client发起一个HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。

2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。

3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。

4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。

5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。

6.Server使用对称密钥加密“明文内容A”，发送给Client。

7.Client使用对称密钥解密响应的密文，得到“明文内容A”。

8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

小结：
https就是使用了非对称加密(一对公私钥进行加密解密)进行公钥传输,然后客户端通过公钥加密将自己的私钥发给服务端,以后就可以使用这个私钥进行消息的收发了

4. 常用的HTTP方法

GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

5.GET方法与POST方法的区别

1. get重点在从服务器上获取资源，post重点在向服务器发送数据
2. get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的；
   post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；
3. Get传输的数据量小，因为受URL长度限制，但效率较高；1024k
   Post可以传输大量数据，所以上传文件时只能用Post方式；
4. get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等；
   post较get安全性较高；
5. get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。
   post支持标准字符集，可以正确传递中文字符。

6.HTTP请求报文与响应报文格式

请求报文

通用首部字段（请求报文与响应报文都会使用的首部字段）

• Date：创建报文时间
• Connection：连接的管理
• Cache-Control：缓存的控制
• Transfer-Encoding：报文主体的传输编码方式

请求首部字段（请求报文会使用的首部字段）

• Host：请求资源所在服务器
• Accept：可处理的媒体类型
• Accept-Charset：可接收的字符集
• Accept-Encoding：可接受的内容编码
• Accept-Language：可接受的自然语言

响应首部字段（响应报文会使用的首部字段）

• Accept-Ranges：可接受的字节范围
• Location：令客户端重新定向到的URI
• Server：HTTP服务器的安装信息

实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）

• Allow：资源可支持的HTTP方法
• Content-Type：实体主类的类型
• Content-Encoding：实体主体适用的编码方式
• Content-Language：实体主体的自然语言
• Content-Length：实体主体的的字节数
• Content-Range：实体主体的位置范围，一般用于发出部分请求时使用

7. 常见的HTTP状态码

2xx : 代表服务端已经成功接收并处理了该请求

200——服务器成功返回网页
201——提示知道新文件的URL
202——接受和处理、但处理未完成
203——返回信息不确定或不完整
204——请求收到，但返回信息为空
205——服务器完成了请求，用户代理必须复位当前已经浏览过的文件
206——服务器已经完成了部分用户的GET请求

3xx : 通常代表客户端需要进行进一步请求用,常用来进行重定向的状态码

300——请求的资源可在多处得到
301——删除请求数据
302——在其他地址发现了请求数据
303——建议客户访问其他URL或访问方式
304——客户端已经执行了GET，但文件未变化
305——请求的资源必须从服务器指定的地址得到
306——前一版本HTTP中使用的代码，现行版本中不再使用
307——申明请求的资源临时性删除

4xx : 通常表示客户端请求有问题

400——错误请求，如语法错误
401——请求授权失败
402——保留有效ChargeTo头响应
403——请求不允许
404——请求的网页不存在

5xx : 通常表示服务端内部错误

• 500 : 服务端代码出错
• 502 : 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应
• 503: 服务器正在维护或者访问过载,过一段时间可能恢复正常
• 504 : 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应

https://www.cnblogs.com/xflonga/p/9368993.html

8. 一个页面从输入 URL 到页面加载显示完成，这个过程中都发生了什么？

1. 地址栏输入地址，浏览器自动补全url，如果浏览器中有缓存且未过期直接使用缓存呈现页面。

2. DNS解析：

查询顺序：浏览器缓存 > 系统缓存 > 路由器缓存 > ISP DNS缓存
如果缓存中没有找到，就会向DNS服务器发送URL对应IP查找域名

3. 客户端与服务器进行三次握手建立连接

“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。
①客户端先发送一个带有SYN（synchronize）标志的数据包给服务端，在一定的延迟时间内等待服务端的回复。
②服务端收到数据包后，传回一个带有SYN/ACK标志的数据包以示传达确认信息。
③客户端收到后再发送一个带有ACK标志的数据包给接收端以示握手成功。
在这个过程中，如果发送端在规定延迟时间内没有收到回复则默认接收方没有收到请求，而再次发送，直到收到回复为止。

4. 浏览器向服务器发送http请求

5. 服务器收到请求，并从文档空间中找到资源返回http响应

6. 浏览器接受到http响应，检查http header 状态码，做出不同的处理方式

• 404显示错误页面
• 304使用缓存
• 204页面不会发生更新
• 200进行下一步
• ...

7. 根据首部字段判断是否启用缓存

cache-control 可缓存
no-cache 每次使用缓存前跟服务器确认
no-store 禁止缓存

8. 拿到index.html进行解析成DOM树，遇到静态文件css，js，image 向服务器请求下载，解析成对应的DOM树，css树，开始布局绘制

为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来

9. 客户端与服务器四次挥手断开连接

终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开

①客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入FIN_WAIT_1状态。
②服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务端进入CLOSE_WAIT状态。
③服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入LAST_ACK状态。
④客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

9. HTTP优化方案

1. TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。
2. 内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
3. 压缩：将文本数据进行压缩，减少带宽
4. SSL加速（SSL Acceleration）：使用SSL协议对HTTP协议进行加密，在通道内加密并加速
5. TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。

9. localStorage. sessionStorage、 Cookie不同点

• 存储大小的不同:
  1. localStorage的大小一般为5M
  2. sessionStorage的大小一般为5M
  3. cookies的大小一般为4K
• 有效期不同:
  1. localStorage的有效期为永久有效，除非你进行手动删除。
  2. sessionStorage在当前会话下有效，关闭页面或者浏览器时会被清空。
  3. cookies在设置的有效之前有效，当超过有效期便会失效。
• 与服务器端的通信
  1. localStorage不参与服务器端的通信
  2. sessionStorage不参与服务器端的通信。
  3. cookies参与服务器端通信，每次都会存在http的头信息中。(如果使用cookie保存过多数据会带来性能问题)
• localStorage和sessionStorage的作用域的区别详解
  1. 不同浏览器无法共享localStorage或sessionStorage中的信息。
  2. 相同浏览器的不同页面间可以共享相同的localStorage (页面属于相同域名和端口)， 但是不同页面或标签页间无法共享sessionStorage的信息。

11. get和post请求在缓存方面的区别

• get请求类似于查找的过程，用户获取数据，可以不用每次都与数据库连接，所以可以使用缓存。
• post不同，post做的一般是修改和删除的工作，所以必须与数据库交互，所以不能使用缓存。因此get请求适合于请求缓存。

12. cookie session区别

1. cookie数据存放在客户的浏览器上，session数据放在服务器上。

2. cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗
   考虑到安全应当使用session。

3. session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用COOKIE。

4. 单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

13. cookie属性

拓展https://www.chinaz.com/web/2012/0905/272814.shtml
httponly http://blog.itpub.net/31556438/viewspace-2557286/
samesite属性http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html

14. https详细过程

15. TCP拥塞控制

16. TCP和UDP

https://blog.csdn.net/weixin_42092787/article/details/107668987

17. 两个不同tab页面之间如何请求交互

18. tcp链接为什么不能为两次握手

19. tcp攻击与防范

20. 301和302状态码

21. http2.0头部压缩

22. TCP的三次握手和四次挥手，为什么不是两次握手？为什么挥手多一次呢

23. 网络中的ACK； SYN； FIN都是什么

• SYN表示建立连接，
• FIN表示关闭连接，
• ACK表示响应

第一次握手：主机A发送位码为syn＝1，随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1)，syn=1，ack=1，随机产生seq=7654321的包；

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1，以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1)，ack=1，主机B收到后确认seq值与ack=1则连接建立成功。 完成三次握手，主机A与主机B开始传送数据。

24. http浏览器缓存机制

25. 304状态码

200表示成功，服务器已成功处理了请求，通常表示为服务器提供了请求的网页，304表示未修改，自从上次请求后，请求的网页未修改过，服务器返回此响应时不会返回网页内容
https://blog.csdn.net/huwei2003/article/details/70139062?utm_term=304%E7%8A%B6%E6%80%81%E7%A0%81%E6%98%AF%E4%BB%80%E4%B9%88&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2_allsobaiduweb~default-0-70139062&spm=3001.4430

26. 500状态码具体场景

http://www.xusseo.com/seoswgwsm/77367.html

27. DNS原理

https://www.cnblogs.com/gopark/p/8430916.html

28. CND原理

CDN的全称是Content Delivery Network，即内容分发网络。CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响
https://blog.csdn.net/xiangzhihong8/article/details/83147542

29. osi七层模型每层分别是什么，http在哪层，tcp在哪层

https://blog.csdn.net/weixin_42092787/article/details/107632967

30. HTTP协议的ETag

31. head和get的区别

32. *ssl握手过程，非对称加密和对称加密的区别

https://blog.csdn.net/qq_29689487/article/details/81634057

33. *前端缓存

34. 滑动窗口

35. 前端安全

https://www.cnblogs.com/zhiying/p/11018331.html
XSS攻击
DOS攻击
https://blog.csdn.net/fengyinchao/article/details/52303118

sql注入

dos注入

36. 计算机网络的五层协议

37. HTTPS为什么要使用一个对称加密和非对称加密相结合

38. 一文读懂http缓存（超详细）

39.Http与Https的基本概念和他们的区别

http的中文叫做超文本传输协议,它负责完成客户端到服务端的一系列操作,是专门用来传输注入HTML的超媒体文档等web内容的协议,它是基于传输层的TCP协议的应用层协议

https:https是基于安全套接字的http协议,也可以理解为是http+ssl/tls(数字证书)的组合

http和https的区别:

• HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
• 在 OSI 网络模型中，HTTPS的加密是在传输层完成的,因为SSL是位于传输层的,TLS的前身是SSL,所以同理
• HTTP无需认证证书,而https需要认证证书

小结：简单来说http是用来进行html等超媒体传输的,但是http不安全,为了安全,使用证书SSL和HTTP的方式进行数据传输,也就是HTTPS

40. TCP粘包

41. DNS解析过程

DNS根域名

理论上，所有域名查询都必须先查询根域名，因为只有根域名才能告诉你，某个顶级域名由哪台服务器管理。事实上也确实如此，ICANN 维护着一张列表，里面记载着顶级域名和对应的托管商。

比如，我要访问www.example.com ，就必须先询问 ICANN 的根域名列表，它会告诉我.com域名由 Verisign 托管，我必须去找 Verisign，它会告诉我example.com服务器在哪里。

再比如，我要访问abc.xyz，也必须先去询问根域名列表，它会告诉我.xyz域名由 CentralNic 公司托管。根域名列表还记载，.google由谷歌公司托管，.apple由苹果公司托管等等。

由于根域名列表很少变化，大多数 DNS 服务商都会提供它的缓存，所以根域名的查询事实上不是那么频繁。

保存 DNS 根区文件的服务器，就叫做 DNS 根域名服务器（root name server）。

2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。

3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。

5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。

6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

42. restful级别

43. token详解