网络

cookie、session、jwt

cookie是将用户信息存在cookie中，但是不安全
session验证是登录成功后服务端将用户信息持久化，将session_id设置在cookie中。每次请求都会带上session_id，服务端根据session_id查出用户数据。
好处：更安全，不会暴露cookie
缺点：如果服务向共享用户信息，在一个页面登录另一个直接登录就可以使用。则需要共享数据库。
jwt是将用户的登录信息经过加密设置过期时间生产token返回给浏览器，每次请求都会带上token。服务端直接解析。
好处：不需要持久化，无状态。
缺点：暴露在每次请求中，会不安全

cookie跨域

path跨域
http://127.0.0.2:3000/server1/a.html的cookie在http://127.0.0.2:4000/server2/b.html取不到，因为cookie跨域了。
设置document.cookie= 'name=kimi;path=/';设置顶级path。则下面的server1和server2都可以取到

domain跨域
http://www.kimi.com:3000/a.html和http://www.yo.kimi.com:3000/b.html获取不到。
设置document.cookie= 'name=kimi;domain=kimi.com';设置顶级domain，则下面的三级域名也可以取到

http://www.yo.kimi.com com：顶级域 kimi.com 一级域名 yo.kimi.com 二级域名 www.yo.kimi.com 三级域名

输入网址到现实的过程

1.域名解析（判断url中是否有非法字符，并转义）
2.查看缓存
3.DNS解析，获取IP地址
4.TCP连接建立
5.发送报文请求
6.响应报文数据
7.浏览器解析数据
8.渲染

浏览器缓存

强缓存：满足强缓存期间内，会直接从本地读取。状态码 200
1、Expires：http1.0, 表示过期时间，Expires:Sat, 09 Jun 2018 08:13:56 GMT,但是如果客户端和服务端时间不一致则会有问题
2、Cache-control（比expires优先）：http1.1,设置缓存的设置，常见的设置如下：

max-age: 强缓存的有效时间，单位秒 max-age=30672000
no-cache：使用协商缓存，不管强制缓存。
no-store：强制关闭缓存。

from disk和memory区别。关闭浏览器memory就没了。一般css放到disk中，js、图片在memory，因为js要执行。如果在disk还需要取到memory

协商缓存：发送请求给服务，如果文件没有改变会让浏览器读本地缓存，状态码304，此时如果有强缓存设置又会进入强缓存时间，如果修改了则重新返回
1、用时间比对：Last-modified If-Modified-Since （http1.0）
服务端会返回Last-modified字段表示最新的更新时间给客户端保存
客户端会使用If-Modified-Since带上更新时间给服务端，如果服务端这段期间没有更新，用缓存
单位是秒，所以更新频率在1秒之内级别则会有文件不一致
2、用内容比对：ETag If-None-Match（http1.1）优先级更高
服务端返回文件的唯一标识ETag给客户端保存
客户端会使用If-None-Match带上文件hash给服务对比，如果一致则用缓存

get和post方法有什么区别

从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
从参数的角度，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合传输敏感信息。

HTTP状态码

1xx: 表示目前是协议处理的中间状态，还需要后续操作。

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

2xx: 表示成功状态。

200 OK是见得最多的成功状态码。通常在响应体中放有数据。
204 No Content含义与 200 相同，但响应头后没有 body 数据。
206 Partial Content顾名思义，表示部分内容，它的使用场景为 HTTP 分块下载和断点续传，当然也会带上相应的响应头字段Content-Range。

3xx: 重定向状态，资源位置发生变动，需要重新请求。

301 Moved Permanently即永久重定向，对应着302 Found，即临时重定向。
比如你的网站从 HTTP 升级到了 HTTPS 了，以前的站点再也不用了，应当返回301，这个时候浏览器默认会做缓存优化，在第二次访问的时候自动访问重定向的那个地址。
302如果只是暂时不可用，那么直接返回302即可，和301不同的是，浏览器并不会做缓存优化。
304 Not Modified: 当协商缓存命中时会返回这个状态码。详见浏览器缓存

4xx: 请求报文有误。

400 Bad Request: 开发者经常看到一头雾水，只是笼统地提示了一下错误，并不知道哪里出错了。
401鉴权失败
403 Forbidden: 这实际上并不是请求报文出错，而是服务器禁止访问，原因有很多，比如法律禁止、信息敏感。
404 Not Found: 资源未找到，表示没在服务器上找到相应的资源。
405 Method Not Allowed: 请求方法不被服务器端允许。
406 Not Acceptable: 资源无法满足客户端的条件。
408 Request Timeout: 服务器等待了太长时间。
409 Conflict: 多个请求发生了冲突。
413 Request Entity Too Large: 请求体的数据过大。
414 Request-URI Too Long: 请求行里的 URI 太大。
429 Too Many Request: 客户端发送的请求过多。
431 Request Header Fields Too Large请求头的字段内容太大。

5xx: 服务器端发生错误。

500 Internal Server Error: 仅仅告诉你服务器出错了，出了啥错咱也不知道。
501 Not Implemented: 表示客户端请求的功能还不支持。
502 Bad Gateway: 服务器自身是正常的，但访问的时候出错了，啥错误咱也不知道。
503 Service Unavailable: 表示服务器当前很忙，暂时无法响应服务。

Accept字段

1、数据格式 Content-Type

text：text/html, text/plain, text/css 等
image: image/gif, image/jpeg, image/png 等
audio/video: audio/mpeg, video/mp4 等
application: application/json, application/javascript, application/pdf, application/octet-stream

2、压缩方式

// 发送端
Content-Encoding: gzip
// 接收端
Accept-Encoding: gizp

3、支持语言

// 发送端
Content-Language: zh-CN, zh, en
// 接收端
Accept-Language: zh-CN, zh, en

4、字符集

// 发送端
Content-Type: text/html; charset=utf-8
// 接收端
Accept-Charset: charset=utf-8

HTTP 2.0

1、头部压缩
2、多路复用（二进制分帧）

HTTPS

https = http + TLS
TLS:加密协议

（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端的浏览器根据双方同意的安全等级，建立会话密钥(对称加密的公钥)，然后利用证书的公钥将会话密钥加密，并传送给网站。（非对称加密）
（4）Web服务器利用自己的私钥解密出会话密钥。（非对称加密解密出对称加密的公钥）
（5）Web服务器利用会话密钥加密与客户端之间的通信。（对称加密）

image.png

HTTPS和HTTP不同

1、http是明文传输，https是加密传输，相对更安全
2、http默认端口80，https默认443

HTTPS的不足

1、连接复杂会造成多余的连接损耗，耗费流量
2、证书需要多余的成本买

TCP/UDP协议

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。在计算机网络的OSI模型中，它完成第四层传输层所指定的功能。

UDP是一种简单的面向数据报、面向无连接、不可靠的通信协议，位于OSI模型的传输层。在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。

TCP三次握手（面向连接）

1、客户端先将SYN标志置为1，表示连接。并发送包的序号seq（一般随机）
2、服务端相应后发送ACK=1标志表示确认接受到，也发送SYN标志发起连接。并且发送已经接受到的包序号ack，和响应发出的包序号seq
3、客户端接收到发送ACK标志表示确认接受，并且发送已经收到的包序号ack（等于之前接受的seq+1）

image.png

TCP重传

TCP如果超过最大字节数限制，会根据包的大小进行分包，并且每个包上都添加上TCP头。

image.png
当客户端进行拆包时，会先算好每一块数据相当于从头开始的第几个字节，接下来在发送这一块数据时，将算好的字节数写在 TCP 头部中（seq：序号）
通过这些信息，就可以检查收到的包是否有遗漏，假设上次接收到第 1460 字节，那么接下来如果收到序号为 1461 的包，说明中间没有遗漏；但如果收到的包序号为 2921，那就说明中间有包遗漏了。
image.png
如果发生错误则会重发

滑动窗口

如果在等待服务端返回ACK的期间什么都不做，那么就比较浪费了。所以TCP采用滑动窗口机制来管理发送和ACK号的操作，就是不需要等待ACK返回，直接发送下一个包，这也是提高TCP效率的方式。

这样带来的问题是：发送方有可能发送的太快超过了接收方处理的速度，接收方缓冲区有可能溢出

解决办法：就是接收方会在收到包后，会通过 TCP 头部中的窗口字段将自己能接收的数据量告知发送方。发送方会保存。这样一来，发送方就不会发送过多的数据，导致超出接收方的处理能力了。接收方处理程序每次从缓冲区取走包时都需要发送一个剩下的窗口大小，而且这个请求不会立即发送，会稍等一下看看有没有需要返回的ACK信号一起合并发送，提高效率。所以提高窗口大小是TCP调优的方式之一

image.png

一个窗口期如果之前有错误会导致整个窗口数据重发

image.png

TCP拥塞控制

上面的窗口机制是为了控制流量的，但是为了防止过多的数据注入到网络中，让网络中的路由器或者链路不至于过载。会有拥塞控制机制有慢启动和拥塞避免两种算法
慢启动：不是一次全部发送，而是根据网络状况动态的缓慢增加。慢启动只是起点低，增长的并不是很慢，1-2-4-8-16。。。
拥塞避免：刚开始发送使用慢启动算法，但是会设定一个阈值，等发送超出阈值后，呈加法增加而不是倍数，1-2-4-8-9-10-11。。。

接受响应消息

浏览器在委托协议栈发送请求消息之后，会调用 read 程序来获取响应消息。协议栈会将数据暂存到接收缓冲区中，但这个时候请求消息刚刚发送出去，响应消息可能还没返回，协议栈会将应用程序的委托的工作暂时挂起 ，等服务器返回的响应消息到达之后再继续执行接收操作

接着协议栈会检查收到的数据块和 TCP 头部的内容，判断是否有数据丢失，如果没有问题则返回 ACK 号。然后，协议栈将数据块暂存到接收缓冲区中，并将数据块按顺序连接起来还原出原始的数据，最后将数据交给应用程序。具体来说，协议栈会将接收到的数据复制到应用程序指定的内存地址中，然后将控制流程交回应用程序。将数据交给应用程序之后，协议栈还需要找到合适的时机向发送方发送窗口更新。

数据发送完毕 -- 断开

这就是TCP的四次挥手

image.png

为什么TCP连接需要三次握手，而断开需要四次？
答：因为断开不是实时的，服务端发起断开，客户端有可能还需要等到数据处理完毕。而握手期间，SYN连接和ACK确认信号可以一起返回给客户端。所以只需要三次

UDP

UDP 不需要建立和断开连接的步骤，只要在从应用程序获取的数据前面加上 UDP 头部，然后交给 IP 进行发送就可以了，遇到错误或者丢包也一概不管。

域名解析、音视频一般采用UDP，因为域名解析包小，音视频需要保证不延迟，丢几帧包无所谓