总结的在平常学习中遇到的一些问答，如有不对，请理性指正

200，204，301，302，304这些请求头代表什么意思，什么场景下会出现

200 表示成功处理了请求，一般情况下都是返回此状态码
204 表示请求执行成功，但是没有数据，浏览器不用刷新页面，也不用导向新的页面。例如当我们提交表单的时候或者是a标签跳转的时候，如果目标页面返回的状态码为204，页面就不会发生跳转。

使用场景：只需要返回是否成功的情况下，可以考虑使用状态码204来作为返回信息，从而省掉多余的数据传输，例如跨域时发送的预检请求(OPTIONS)

301 表示永久性重定向。即请求的资源分配了新url，以后都应使用新url

使用场景：1. 域名到期不想续费（或者发现了更适合网站的域名），想换个域名 2. 在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个 3. 服务器空间重新分配

302 表示临时性重定向，请求的资源临时分配了新url，本次请求暂且使用新url。在以后的请求中重定向的url还有可能还会改变

使用场景：未登陆的用户访问用户中心重定向到登录页面，访问404页面重新定向到首页，广告页面等使用302可能会导致网址劫持的问题

304 表示自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。即与浏览器的缓存有关

与响应头的Last Modified/If Modified Since/ETags/if-none-matched 字段配合来进行协商缓存

常见的HTTP状态码有哪些，分别代表什么意思

1xx协议处理的中间状态

101 在HTTP升级为WebSocket的时候，如果服务器同意变更，就会发送状态码 101

2xx成功

200 客户端的请求被服务端正确处理 204 请求成功但响应报文不包含实体的主体部分 206 范围请求,客户端进行了部分请求,服务端返回指定部分的内容 205 与204作用一致但要求请求方重置内容

3xx重定向

301 永久性重定向,表示资源已被分配了新的url 302 临时性重定向,表示资源临时被分配了新的url 304 当客户端拥有可能过期的缓存时，会携带缓存的标识 etag、时间等信息询问服务器缓存是否仍可复用，而304是告诉客户端可以复用缓存。 303 资源存在另一个url,服务端要求客户端使用get请求 307 临时重定向,向新的url发送同样的请求

4XX客户端错误

400 请求报文存在语法错误 401 发送的请求需要有通过 HTTP 认证的认证信息 403 对请求资源的访问被服务器拒绝,资源允许访问,但请求不满足条件 404 在服务器上没有找到请求的资源 405 当前的请求方法不被允许 415 不支持的媒体类型,检查Content-Type

5XX 服务器错误

500 服务器端在收到请求后后，执行相关动作时发生了错误 502 bad gate无效网关 501 表示服务器不支持当前请求所需要的某个功能 503 表明服务器暂时处于超负载或正在停机维护，无法处理请求

五层原理模型

数据封装如下

http与https有什么区别

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

SSL它什么优缺点

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

优点：

可靠性：认证用户和服务器，确保数据发送到正确的客户机和服务器；
机密性：加密数据以防止数据中途被窃取；
完整性：维护数据的完整性，确保数据在传输过程中不被改变。

缺点：

技术门槛比较高，申请证书比较烦琐
信息传输比HTTP更复杂
加密解密，密钥协商需要一定时间，增加了时延

非对称加密与对称加密的原理是什么，有什么区别

对称加密：加密和解密用的是同一个密码或者同一套逻辑的加密方式,最常用的AES算法包括了 AES-128 AES-192 AES-256 (密钥的长度不同)
非对称加密：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。使用最广泛的有RSA 算法

大致过程

A要向B发送信息，A和B都要产生一对用于加密和解密的公钥和私钥。
A的私钥保密，A的公钥告诉B；B的私钥保密，B的公钥告诉A。
A要给B发送信息时，A用B的公钥加密信息，因为A知道B的公钥。
A将这个消息发给B（已经用B的公钥加密消息）。
B收到这个消息后，B用自己的私钥解密A的消息。其他所有收到这个报文的人都无法解密，因为只有B才有B的私钥。

https中哪个阶段使用了非对称加密，哪个阶段使用对称加密，为什么

通信建立前交换秘钥的时候采用非对称加密的方式交换会话秘钥
在通信的过程之中采用对称加密的的会话密钥的方式加密明文数据
对称加密的效率较高，在传输的过程中往往需要传输的数据多，所以在通信的过程中使用对称加密，在交换公钥的工程中为了保证安全性使用非对称加密

非对称加密一般有哪些实现的算法

RSA:它的安全性基于大数分解，使用两个超大素数的乘积作为生成密钥的材料
ECC：它基于椭圆曲线离散对数的数学难题，使用特定的曲线方程和基点生成公钥和私钥
Elgamal: 基于离散对数问题

websocket链接过程是怎样的

Browser与WebSocket服务器通过TCP三次握手建立连接，如果这个建立连接失败，那么后面的过程就不会执行，Web应用程序将收到错误消息通知。
在TCP建立连接成功后，Browser/UA通过http协议传送WebSocket支持的版本号，协议的字版本号，原始地址，主机地址等等一些列字段给服务器端。
WebSocket服务器收到Browser/UA发送来的握手请求后，如果数据包数据和格式正确，客户端和服务器端的协议版本号匹配等等，就接受本次握手连接，并给出相应的数据回复，同样回复的数据包也是采用http协议传输。
Browser收到服务器回复的数据包后，如果数据包内容、格式都没有问题的话，就表示本次连接成功，触发onopen消息，此时Web开发者就可以在此时通过send接口想服务器发送数据。否则，握手连接失败，Web应用程序会收到 onerror消息，并且能知道连接失败的原因。

详见： www.ruanyifeng.com/blog/2017/0…

http1与http2的区别

http1只能压缩body的部分，不能压缩header在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。在 HTTP /2 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。
http2采取了多路复用的技术，即在一个TCP连接中发送多个流，流表示每个请求或回应的所有数据包（帧）。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能，解决了http/1.1的管道阻塞问题
http2可以实现服务端推送。服务器不再是被动的响应也可以主动向客户端发送消息
http2报文全面采用了二进制格式，增加了传输效率

http2还有一个问题：就是多个http请求在复用同一个tcp连接，但是传输层的tcp协议是不知道有多少个http请求的，一旦发生了丢包触发了重传机制，这个tcp连接中所有http请求都必须等待这个包

ajax与http的关系

AJAX就是浏览器发出的HTTP请求，只不过是浏览器加上了一个同源策略限制而已。AJAX请求的对象就是浏览器开放给JS调用HTTP请求用的
AJAX请求受到浏览器的同源策略限制，存在跨域问题
AJAX在进行复杂请求时，浏览器会预先发出OPTIONS预检（HTTP自己是不会预检的）
从使用角度上说，AJAX使用简单一点，少了些底层细节，多了些浏览器特性（如自动带上同域cookie等）
ajax请求通过xhr或者fetch发送，http请求可以通过键入并转到url、提交表单、加载外部文件发送
ajax请求的头部x-requested-with字段的值为XMLHttpRequest
ajax与js的交互性更强可以获取相应数据

在浏览器中输入url发出的请求与ajax的区别

输入url

网页刷新
js无法获取响应数据
只能发送get请求，参数必须包含在url里
不受跨域限制

发送ajax

网页不会刷新
js可以获取响应数据
能发送多种请求，参数可以包含在url及body里
受跨域限制

OSI七层模型

物理层传输的单位是什么

比特，传输二进制光电信号什么的

GET是否可以在body中放置内容

可以，http规范任何方法都能发送请求实体。他们报文时没有任何区别的，但是在浏览器中，因为XMLHttpRequest规范的限制，浏览器中ajax发送的http请求，因此不推荐在get请求中携带实体

http请求body是否有大小限制

对于post请求，浏览器对body大小没有限制，但是web服务器有限制，可以在web服务器中进行配置

http包是如何到达服务器的

地址解析 -协议 -端口 -主机名:DNS解析出主机IP地址 -对象路径
封装Http请求数据包
封装成tcp包,建立tcp连接(3次握手)
客户端发送请求
服务端响应
关闭TCP连接(4次挥手)

保持链接的方案:在请求/响应头中加入 Connection:keep-alive就可以保持链接打开状态

TLS工作原理

混合加密，非对称加密保证会话密钥安全，对称加密使用会话密钥加密数据保证信息传输安全
完整性，将数据跟数据摘要一同加密进行发送，解密后将数据取摘要与解密出来的摘要对比是否一致
数字证书：利用CA公开的公钥去验证服务器发送的公钥证书是否可信

TLS1.2的四次握手

客户端发出请求，包括了：一个随机值(用于生成对话秘钥) ，支持的协议，加密套件列表(包括了生成随机数算法，对称加密算法，哈希摘要算法)，支持的压缩的方法
服务端收到客户端的请求，向客户端发出回应包括了：一个随机值(用于生成对话秘钥) 确定使用的协议确定使用的加密方式服务器使用的证书
客户端收到服务端的证书并验证是否有效，如果证书没问题,向服务端发送一个请求，包括了：生成一个随机值(用证书公钥加密) ，编码改变通知(随后的信息将使用双方商定的加密方法和秘钥发送) ，客户端握手结束通知(前面发送的所有内容的hash值，用来提供给服务端校验)
服务端最后响应: 包括了: 服务器收到客户端的第三个随机数之后(用私钥解密)结合之前的两个明文随机数，计算生成本次会话所用的"会话密钥",编码改变通知(随后的信息都将用双方商定的加密方法和密钥发送),服务器握手结束通知(前面发送的所有内容的hash值，用来提供给客户端校验

TLS1.3的改进 TLS1.3 在 TLS1.2 的基础上废除了大量的算法，提升了安全性。同时利用会话复用节省了重新生成密钥的时间，利用 PSK（第一次发送验证时直接带上数据）做到了0-RTT连接

客户端如何知道服务端下发的CA证书是没有被劫持篡改过的

总结一下就是:使用CA公钥对服务器下发的CA证书中的数字签名进行解密，再跟CA证书中的服务器公钥取摘要进行比对，若一致，则未被篡改

客户端如何验证CA证书是合法的

服务器把自己的公钥注册到CA
CA用自己的私钥将服务器的公钥数字签名并且颁发证书，数字签名：服务器公钥取摘要再用认证机构私钥加密
服务器将公钥证书发送给客户端，客户端验证公钥证书
客户端使用CA认证机构的公钥去解密公钥证书里的数字签名，从而得到服务器公钥摘要
客户端对服务器公钥取摘要，对比上一步的公钥摘要是否相同
客户端成功获取公钥后对报文进行加密后发送，服务器用自己的私钥解密

常见的摘要算法： SHA384,SHA256 数字代表多少bit长的哈希值

GET与POST区别

相比而言GET方法是幂等的无副作用，POST方法会修改服务器上的资源不是幂等的，有副作用
GET通过拼接url进行传递参数；POST通过body传输参数
Get会缓存,Post不能，所以在页面后退时POST会重新请求，但是GET不会
URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的，POST的body长度通常是服务器确定的
Post相对与Get安全一点(Get请求参数包含在Url中,也可以写在body里面),但抓包情况下都是一样的（说白了都是http协议）
GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。两次包的TCP在验证数据包完整性上，有非常大的优点。

http请求URL长度限制是多少

HTTP协议没有对URL长度做出限制，但是不同的浏览器有不同的长度限制

http常用请求方法有哪些

GET：从服务器取数据
POST：提交数据给服务器处理
HEAD：从服务器获取文档首部
PUT：将请求的主体内容存在服务器上
DELETE：从服务器删除数据
OPTIONS：预检请求，沟通哪些请求方法、头部字段是可以使用的

什么情况下请求方法是options

在W3C标准中，用于跨域的标准方案是CORS，即跨域资源共享
在CORS中，将请求分为两类：简单请求，非简单请求
简单请求
- 请求方法是：HEAD/GET/POST之一
- HTTP的头信息不超出以下几种字段：
  - Accept
  - Accept-Language
  - Content-Language
  - Last-Event-ID
- Content-Type, 只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
不是简单请求即是非简单请求
当发送跨域的非简单请求时，会在正式通信之前，增加一次HTTP查询请求，称为预检请求
预检请求用的请求方法就是OPTIONS，用来询问服务器支持的请求方法跟接受的请求头部

资料：www.ruanyifeng.com/blog/2016/0…

http2的多路复用如何工作的

http2把原来http所传输的信息划分为多个粒度更小的帧，并对其进行二进制编码，然后将其映射到属于特定流的消息。
在一个 TCP 连接上，我们可以向对方不断发送帧，每帧的 stream identifier 标明这一帧属于哪个流，然后在对方接收时，根据 stream identifier 拼接每个流的所有帧组成一整块数据。
我们可以把每个请求或者响应都当作一个流，那么多个请求变成多个流，这不同流的数据被分成多个帧，在一个连接中交错地发送给对方，这就是 http2 中的多路复用。

HTTP/2 中的二进制帧

结构如下

流的特点：

并发性。一个 HTTP/2 连接上可以同时发多个帧，这一点和 HTTP/1 不同。这也是实现多路复用的基础。
自增性。流 ID 是不可重用的，而是会按顺序递增，达到上限之后又新开 TCP 连接从头开始。
双向性。客户端和服务端都可以创建流，互不干扰，双方都可以作为发送方或者接收方。
可设置优先级。可以设置数据帧的优先级，让服务端先处理重要资源，优化用户体验。

什么是帧id，他有什么作用

帧头部的流标识符Stream Identifier，用来表示属于哪一个流

如果一个请求服务器要处理很久才能响应，有哪些办法在服务端处理完后,客户端能第一时间接收到

客户端不断轮询，直到服务器处理返回
使用websocket，服务器处理完成后通知客户端

请求超时时间可以设置为24h吗

可以。需要服务器和前台一起完成相关的配置

概述TCP与UDP

TCP：传输控制协议 UDP：用户数据报协议

TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
TCP首部开销20字节;UDP的首部开销小，只有8个字节
TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
TCP有拥塞控制和流量控制,UDP没有

四次挥手的过程

数据传输结束后，通信的双方都可释放连接现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP连接，A 把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待 B 的确认
B 发出确认，确认号 ack = u + 1，而这个报文段自己的序号 seq = v。TCP 服务器进程通知高层应用进程。从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。B 若发送数据，A 仍要接收
若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接
A 收到连接释放报文段后，必须发出确认。在确认报文段中 ACK = 1，确认号 ack = w +1，自己的序号 seq = u + 1。

三次握手,每次握手的作用

三次握手的过程

A 的 TCP 向 B 发出连接请求报文段，其首部中的同步位 SYN = 1，并选择序号 seq = x，表明传送数据时的第一个数据字节的序号是 x
B 的 TCP 收到连接请求报文段后，如同意，则发回确认。
- B 在确认报文段中应使 SYN = 1，使 ACK = 1，其确认号ack = x + 1，自己选择的序号 seq = y。
A 收到此报文段后向 B 给出确认，其 ACK = 1，确认号 ack = y + 1。 A 的 TCP 通知上层应用进程，连接已经建立。
B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程：TCP 连接已经建立。

每次握手的作用

第一次握手：客户端发送网络包，服务器端收到了，这样服务器端就能证明：客户端的发送能力、以及服务器端的接收能力都是正常的.
第二次握手: 服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。
第三次握手: 客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。

三次握手的目的

客户端和服务器端通信前需要连接，而”握手“作用就是为了证明，客户端的发送能力和服务器端的接受能力都是正常的
防止已经失效的连接请求报文段突然又传到服务端，因而产生错误
交换初始的序列号，通过seq和ack

TCP“握手”为什么不能是1次或者2次

若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源
若建立连接只需一次握手，客户端发送连接请求后，没有收到服务端的应答，是没法判断连接是否成功的

http2的特点

多路复用，采用二进制分帧
头部压缩，使用HPACK算法建立一个索引表
服务端推送
设置请求优先级

如何使用http2,http2的使用条件

如何使用
- 使用Nginx搭建HTTP2服务器
使用条件
- 支持Http2的服务端与客户端(opens new window)
- 域名就必须是https(基于TLS/1.2或以上版本的加密连接)
- 服务器的openssl版本必须大于1.0.2

HTTP3中使用的QUIC协议基于UDP的原因

不管是http1中的队头阻塞问题，还是http2中在多路复用的时候只要有一个请求丢包，其他所有请求都会等待，这些都是基于tcp才会有的，并且tcp建立连接也会花费很多时间

一个http请求是线程还是进程

每个HTTP请求都需要使用一个线程来控制

在浏览器中http有请求数量限制吗,它的策略是怎样的

有，每个域名下，最多同时建立6-8个TCP连接

https是如何保证数据安全的

利用CA证书，保证服务器的真实性
利用非对称加密，保证会话密钥的保密性
利用对称加密，保证会话的保密性
利用数字签名，保证数据的完整性

http2是如何消除队头阻塞的

在HTTP1的基础上HTTP2不使用管道化的方式，而是引入了二进制帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输层是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

TCP/IP分别属于哪一层(OSI)

TCP属于传输层，主要负责应用之间的通信(指定端口，区分不同的应用) IP属于网络层，主要负责路由分组转发（指定ip，便于选择转发路径），负责不同host之间的通信

HTTP常见头部(请求头，响应头)

常见的请求头

请求头	说明	示例
Accept	可接受的响应内容类型（Content-Types）	Accept: text/plain
Accept-Charset	可接受的字符集	Accept-Charset: utf-8
Accept-Encoding	可接受的响应内容的编码方式。	Accept-Encoding: gzip, deflate
Accept-Language	可接受的响应内容语言列表。	Accept-Language: en-US
Authorization	用于表示HTTP协议中需要认证资源的认证信息	Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE==
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。	Cache-Control: no-cache
Connection	客户端（浏览器）想要优先使用的连接类型	Connection: keep-alive
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie	Cookie: $Version=1; Skin=new;
Content-Length	以8进制表示的请求体的长度	Content-Length: 348
Content-Type	请求体的MIME类型（用于POST和PUT请求中）	Content-Type: application/x-www-form-urlencoded
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），与etag配合使用	If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd"
If-Modified-Since	允许在对应的资源未被修改的情况下返回304未修改	If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT
Origin	发起一个针对跨域资源共享的请求（该请求要求服务器在响应中加入一个Access-Control-Allow-Origin的消息头，表示访问控制所允许的来源）。	Origin: www.itbilu.com
User-Agent	浏览器的身份标识字符串	User-Agent: Mozilla/……
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面	Referer: itbilu.com/nodejs

常见响应头

响应头	说明	示例
Access-Control-Allow-Origin	指定哪些网站可以跨域源资源共享	Access-Control-Allow-Origin: *
Age	响应对象在代理缓存中存在的时间，以秒为单位	Age: 12
Allow	对于特定资源的有效动作;	Allow: GET, HEAD
Cache-Control	通知从服务器到客户端内的所有缓存机制，表示它们是否可以缓存这个对象及缓存有效时间。其单位为秒	Cache-Control: max-age=3600
Connection	针对该连接所预期的选项	Age: 12
ETag	对于某个资源的某个特定版本的一个标识符，通常是一个消息散列	ETag: "737060cd8c284d8af7ad3082f209582d"
Expires	指定一个日期/时间，超过该时间则认为此回应已经过期	Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified	所请求的对象的最后修改日期	Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT
Location	用于在进行重定向，或在创建了某个新资源时使用。	Location: www.itbilu.com/nodejs

更多的：www.cnblogs.com/honghong87/…

TCP/IP参考模型

应用层，负责具体的应用协议，如：HTTP, FTP, SMTP, DNS等
传输层，负责应用间通信的协议，如：TCP、UDP
网际层，负责分组在网络中转发的协议，如：IP
网络接口层，负责具体的信号表示(物理层)，以及将分组从一个结点发往另一个结点(数据链路层)

其中，原OSI七层参考模型中，应用层、传输层之间的表示层、会话层被舍弃。数据链路层跟物理层合并成为网络接口层

TCP的特性,为什么建立链接需要三次握手,断开4次挥手

握手三次

如果只握一次，则客户端不能判断连接是否创建成功
如果只握二次，则当请求连接的包在网络中滞留一段时间后，再被服务器接收，会导致服务器单方面的创建连接
因此握手三次，当服务端发送连接请求时，客户端如果不同意(不发ACK)，则服务器不会建立链接

挥手四次

当第二次挥手的时候可能服务端还在传输数据，所以服务端会先发送一个应答给客户端，避免客户端继续发送，然后在服务端传输完成之后进行第三次挥手告诉客户端数据传输完毕了
第四次挥手时，客户端收到服务端发送的FIN包，发送ACK确认信息，让服务端断开连接

客户端如何判断服务端下发的公钥是没有被中间人篡改的

服务端下发的公钥证书，其中包含由CA私钥加密的公钥摘要，及公钥
客户端拿到公钥证书后，使用本地配置的CA公钥将CA私钥加密的公钥摘要解密，并对公钥证书中包含的公钥取摘要
通过对比解密出来的摘要与计算出来的摘要是否一致，则可以判断有没有被中间人篡改

传输层有哪些那些协议

TCP：可靠的字节流传输协议
UDP：不可靠的数据报传输协议

网络层的ip协议作用是什么

给数据加上ip头，封装成ip数据报，其中包含源/目的地址，用于帮助路由器分组转发，提供了一种将数据从A主机跨网络送至B主机的能力

TCP的报文组成,有哪些头部，分别代表什么

源端口和目的端口字段——各占 2 字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现
序号字段——占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。seq
确认号字段——占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。
数据偏移（即首部长度）——占 4 位，它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。“数据偏移”的单位是 32 位字（以 4 字节为计算单位）。
保留字段——占 6 位，保留为今后使用，但目前应置为 0。紧急 URG —— 当 URG  1 时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)。确认 ACK —— 只有当 ACK  1 时确认号字段才有效。当 ACK  0 时，确认号无效。推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的报文段，就尽快地交付接收应用进程，而不再等到整个缓存都填满了后再向上交付复位 RST (ReSeT) —— 当 RST  1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
同步 SYN —— 同步 SYN = 1 表示这是一个连接请求或连接接受报文。终止 FIN (FINish) —— 用来释放一个连接。FIN  1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。
窗口字段 —— 占 2 字节，用来让对方设置发送窗口的依据，单位为字节。
检验和 —— 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
紧急指针字段 —— 占 16 位，指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）。URG= 1 才有用
选项字段 —— 长度可变。TCP 最初只规定了一种选项，即最大报文段长度 MSS。MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。” MSS (Maximum Segment Size) 是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的 TCP 报文段。所以，MSS是“TCP 报文段长度减去 TCP 首部长度”
填充字段 —— 这是为了使整个首部长度是 4 字节的整数倍。

TCP如何检查到丢失了报文数据的

校验，通过首部的校验和
序号，tcp采用的是累计确认的机制，TCP包每次发出时，会通过ack指明自己想要接收的下一个包的序号，如果接收到的包与自己期望的不一致，则丢失了报文数据

状态码304与403的分别代表什么

304:当客户端拥有可能过期的缓存时，会携带缓存的标识 etag、时间等信息询问服务器缓存是否仍可复用，而304是告诉客户端可以复用缓存,说白了就是协商缓存
403:对请求资源的访问被服务器拒绝,资源允许访问,但请求不满足条件

如何设置cookie

服务端设置cookie

服务端在响应头(Response Header)中添加一个Set-Cookie字段

`Set-Cookie:"name=value;expires=session;path=/;domain=.sugarat.top;HttpOnly;secure;sameSite=lax"`

采用键值对的形式

document.cookie = 'name=xxx;value=xxx'

cookie有哪些属性

常见的值

cookie属性	简介	特殊说明
name	键	---
value	值	---
Expires	过期时间	一个固定的时间,其值为默认session,即关闭浏览器时此cookie就过期失效
Max-Age	过期时间	收到此cookie后多久后过期，优先级大于Expires,大于0：会将cookie存到本地文件中,等于0：立即删除,小于0：等价于会话性cookie
Domain	可以送达的主机名(域名)	没有指定：默认值为当前文档访问地址中的主机部分(不包含子域名),如果设置为.a.com那么a.com,a.a.com，b.a.com等都能访问,即a.com的子域名都可以访问到这个cokie
path	生效路径	路径必须出现在要请求的资源的路径中才可以发送
Secure	安全标志	只有使用HTTPS协议的时候才会携带此cookie
HTTPOnly	安全标志	不允许使用脚本去更改/获取这个cookie,有助于避免 XSS 攻击
SameSite	安全标志	控制跨站请求获取cookie,可以设置让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）
PRIORITY	优先级	定义了三种优先级，Low/Medium/High，当cookie数量超出时，低优先级的cookie会被优先清除

SameSite属性的值

Strict:仅允许一方请求携带 Cookie，即浏览器将只发送相同站点请求的 Cookie，当前网页 URL 与请求目标 URL 完全一致才发送
Lax:允许部（导航到目标网址的 Get 请求）分第三方请求携带 Cookie
None:无论是否跨站都会发送 Cookie
之前默认值是 None ，在Chrome稳定版80及更高版本上默认是 Lax

MSL是什么

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。通常为两分钟
MSL 与 ip头部中的TTL 的区别：MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

为什么TCP最后一次”挥手“，需要等待 2MSL 时间后才进入 CLOSED 状态

消除掉网络中旧连接的数据包
充分保证ACK包的可达。当ACK包丢失时若接收到服务端超时重传的FIN包可以回复ACK包(且重新计时2MSL)使得服务端进入CLOSED状态。

TCP的应用场景，UDP的应用场景

TCP：适用于要求可靠传输的应用，例如文件传输
UDP：适用于实时应用（IP电话、视频会议、直播等）

如何解决浏览器对同一域名的http请求数量的限制

使用HTTP2，仅需建立一个TCP连接，多个请求和响应全部看成帧交替传输
对同一台服务器绑定多个域名，前端请求时，分别使用不同的域名，则可以解决浏览器对TCP并发最多6-8个的限制

三次握手的过程可以携带数据吗

RFC793文档里带有SYN标志的过程包是不可以携带数据的，也就是说三次握手的前两次是不可以携带数据的（逻辑上看，连接还没建立，携带数据好像也有点说不过去）
当客户端收到服务器响应的ACK + SYN包后，建立与TCP相关的资源，此时客户端、服务器端都建立了TCP连接相应资源，因此第三次握手发送ACK包的时候，可以携带数据

UDP首部格式

源端口：这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的 UDP 端口。接收端的应用程序利用这个字段的值作为发送响应的目的地址。这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段中。如果不写入端口号，则把这个字段设置为 0。这样，接收端的应用程序就不能发送响应了。
目的端口：接收端计算机上 UDP 软件使用的端口，占据 16 位。
长度：该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度。因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8。
校验值：该字段占据 16 位，可以检验数据在传输过程中是否被损坏。

TCP是如何保证传输可靠的

可靠:保证接收方进程从缓存区读出的字节流和发送方发出的字节流是一致的

校验和：通过对TCP包头部的校验和进行判断，如果传输错误则会被丢弃，并由网际控制报文协议ICMP发出错误信息
超时重传：当发送方没有收到接收方的ACK确认数据时，就默认数据包丢失，将重新发送，或者收到三个对一个包的重复确认
赋予每一个包对应的序号，采用了累计确认的机制，确定了有序性

http的缓存机制

首先只有 GET 请求获取的资源才能被缓存缓存的机制大致如下总结一下就是

浏览器在加载资源时，根据请求头的expires和cache-control判断是否命中强缓存，是则直接从缓存读取资源，不会发请求到服务器
如果没有命中强缓存，浏览器一定会发送一个请求到服务器，通过last-modified和etag验证资源是否命中协商缓存，如果命中，服务器会将这个请求返回，但是不会返回这个资源的数据，依然是从缓存中读取资源
如果前面两者都没有命中，直接从服务器加载资源

Cache-Control

首先是请求头中的Cache-Control与Pragma字段

Pragma: no-cache可以兼容http 1.0 ，而Cache-Control: no-store是http 1.1提供的。因此，Pragma: no-cache可以应用到http 1.0和http 1.1,而Cache-Control: no-store只能应用于http 1.1。

下面介绍Cache-Control字段主要取值

取值	作用
public	资源可被任何中间节点（客户端和代理服务器）缓存
private	只有客户端可以缓存，Cache-Control的默认取值
max-age=< seconds >	表示缓存内容将在xxx秒后失效
s-maxage=< seconds >	同max-age作用一样，只在代理服务器中生效（比如CDN缓存），s-maxage优先级高于max-age
no-cache	可以缓存，但每次都应该去服务器验证缓存是否可用，进入协商缓存阶段。不使用 Cache-Control 的缓存控制方式做前置验证，而是使用 Etag 或者Last-Modified字段来控制缓存。相当于max-age:0, must-revalidate
no-store	所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
must-revalidate	可缓存但必须再向源服务器进确认
proxy-revalidate	要求中间缓存服务器对缓存的响应有效性再进行确认

强缓存

对于强缓存而言，只会向浏览器请求数据

浏览器在加载资源时，根据请求头的expires和cache-control判断是否命中强缓存，是则直接从缓存读取资源，不会发请求到服务器

主要步骤

查看Cache-Control的max-age属性与Date属性属性比较是否过期
如果不含有max-age属性就去查看是否包含Expires属性，，通过比较Expires的值和头里面Date属性的值来判断是否缓存还有效。

如果 max-age 和 expires 属性都没有，找找头里的 Last-Modified 信息。如果有，缓存的寿命就等于头里面 Date的值减去Last-Modified的值除以10

协商缓存

强缓存没有命中的话就会触发以下步骤

会在请求头里寻找If-None-Match字段，其值为服务器上次返回的ETag响应头的值
如果请求头里没有If-None-Match字段，则会在请求头中寻找If-Modified-Since字段，其值为服务器上次返回的Last-Modified响应头中的日期值
- 如果If-None-Match与If-Modified-Since都没有，则会直接向服务器请求数据。
如果请求头中带有If-None-Match或If-Modified-Since，则会到源服务器进行有效性校验，如果源服务器资源没有变化，则会返回304；如果有变化，则返回200；

If-None-Match与etag比较，If-Modified-Since与Last-Modified```比较

如何控制http缓存

较好的使用http缓存机制，是能够达到减少请求，更多地使用本地的资源，给用户更好的体验的同时，也减轻服务器压力。所以最佳实践就应该是尽可能命中强缓存，同时能在更新版本的时候让客户端的缓存失效
目前的策略是，HTML：使用协商缓存，CSS、JS、图片：使用强缓存，文件命名带上hash值。
原因是，当页面更新，HTML是协商缓存，因此肯定可以拿到最新的页面。而在CSS、JS、图片打包时，因为文件名加上了hash值，如果文件被修改过，请求的链接将是不一样的，相当于第一次请求，会重新从服务器拉取最新资源

设置强缓存

res.setHeader('Cache-Control', 'public, max-age=xxx');

设置协商缓存

res.setHeader('Cache-Control', 'public, max-age=0');	// 强缓存过期，则走协商缓存，或者直接设置成 public, no-cache
res.setHeader('Last-Modified', xxx);
res.setHeader('ETag', xxx);

HTTP的请求构成

不管是请求还是应答都由四部分构成：起始行头部空行实体

大致结构如图所示

什么是CDN，基本工作原理是什么

CDN，中文名叫做「内容分发网络」，它的作用是减少传播时延，找最近的节点

核心功能有两个:

缓存:把资源 copy 一份到 CDN 服务器上这个过程
回源:CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程

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

用户通过浏览器访问未使用CDN加速的网站大致过程如下：

用户在浏览器中输入要访问的域名；
浏览器向DNS服务器请求对该域名的解析；
DNS服务器返回该域名的IP地址给浏览器；
浏览器使用该IP地址向服务器发送请求内容；
服务器将用户请求的内容返回给浏览器；

用户访问的网站使用了CDN，其过程会变成以下这样：

用户向浏览器输入www.processon.com这个域名，浏览器第一次发现本地没有DNS缓存，则向网站的DNS服务器请求；
浏览器向DNS服务器请求对该域名的解析。由于CDN对域名进行了调整，DNS服务器最终会将域名解析权交给CNAME指向CDN专用的DNS服务器；
CND的DNS负载均衡系统解析域名，把对用户响应速度最快的IP地址返回给用户；
用户向该IP地址（CND服务器）发出请求；
CND负载均衡设备会为用户选择一台合适的缓存服务器提供服务；
用户向缓存服务器发出请求；
缓存服务器响应用户请求，将用户所需的内容返回给用户；

从输入url到显示页面这个过程发生了什么

解析URL

  - GET 只能进行 URL 编码，只能接收 ASCII 字符
  - url编码的规则是utf-8 ，中文使用gb2312编码
  - 可以使用```encodeURIComponent```进行编码

构建请求行

GET   /     HTTP/1.1
方法  请求路径 请求的协议/版本

查找强缓存

  - 检查资源是否存在强缓存,存在的话直接进行资源解析

DNS解析

  - 浏览器先检查自身缓存中有没有被解析过的这个域名对应的ip地址，如果有，解析结束
  - 检查操作系统缓存中有没有对应的已解析过的结果(win中的hosts文件)
  - 请求本地域名服务器（LDNS）来解析这个域名,没有则进行下一步
  - DNS 根服务器查询

建立TCP连接

  - 三次握手

判断是否https请求

  - 是，进行TLS握手

客户端发送HTTP请求，服务器处理请求响应结果,并返回Http报文

  - 200:进入下一步，如果 4xx 或 5xx 的话就会报错，如果 3xx 进行重定向继续解析
  - 如果是gzip格式的话会先解压一下，然后通过文件的编码格式去解码文件

浏览器解析渲染页面

如果 Content-Type 字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束。但如果是HTML，那么浏览器则会继续进行导航流程。
浏览器为页面分配渲染进程开始解析HTML文件
- 词法分析:标记化
- 语法分析:构建DOM树
- 分配进程的策略：正常打开新的界面,就会创建新的渲染进程，如果新打开的界面和之前存在的界面是同一站点,那么就会复用之前的渲染进程，如果新打开的界面和之前的界面不属于同源站点,则创建新的进程
解析HTML(超文本标记语言)-->DOM(文档对象模型)树
- 遇到 script 标签的话，会判断是否存在 async 或者 defer属性 - async: 并行进行下载,下载完成后并执行js - defer: 先并行下载文件，然后等待 HTML 解析完成后顺序执行。 - 如果都没有: 就会阻塞住渲染流程直到 JS 下载并执行完毕
- 遇到link下载并解析CSS(层叠样式表)-->CSSOM(CSS对象模型)树 - link标签引用 - style标签中的样式 - 元素的内嵌style属性 - 标准化属性值

DOM树 + CSSOM树 --> Layout Tree(布局树):CSSOM 树和 DOM 树构建完成后开始生成布局树（计算出 DOM 节点的具体样式规则包括了继承规则，层叠样式表）

- Layout Tree 进行界面元素的尺寸位置信息的确认(回流过程发生在这里),和元素的像素信息的绘制(重绘流程发生在这里)

- 对RLayout Tree进行分层，并生成分层树。（界面中有很多复杂的效果,为了方便这些效果的实现,渲染引擎需要为特定的节点生成特殊的图层,并生成一棵对应的图层树）

- 为每个图层生成绘制列表，并将其提交到渲染引擎的合成线程。

- 合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。通常情况下,栅格化的操作都会使用 GPU 加速来完成（渲染进程和GPU 进程通信）

- 所有的图块都光栅化处理完成后，合成线程发送绘制图块命令 ```DrawQuad``` 给浏览器进程。

- 浏览器进程根据 ```DrawQuad``` 消息生成页面，并显示到显示器上。

回流与重绘

回流(Layout):根据生成的渲染树,回流得到节点的几何信息(位置,尺寸) - 计算可见的Dom节点在设备视口的位置和尺寸,这个计算阶段就是回流 - 为了知道每个可见节点在视口的确切大小和位置,浏览器从渲染树的根节点进行遍历
重绘(Painting):根据渲染树与回流得到的节点几何信息,得到节点的绝对像素 - 经过生成的渲染树和回流阶段,得到了所有可见节点具体的几何信息与样式,然后将渲染树的每个节点转换成屏幕上的实际像素,这个阶段就叫重绘节点

由上面的关系可知 回流必将引起重绘,而重绘不一定会引起回流

断开TCP连接

  - 四次挥手

tcp的流量控制

利用滑动窗口实现流量控制，主要有选择重传和后退n步两种方法

详见： www.bilibili.com/video/BV19E…

看了就懂

tcp的拥塞控制

主要有四种算法

慢开始
拥塞避免
快重传
快恢复详见： juejin.cn/post/684490…

常见的一些前端网络知识点（持续更新中）