Network
网络协议
HTTP
（HyperText Transfer Protocol，超文本传输协议）
五层模型
- 应用层
- 为应用软件提供了很多服务，构建于协议之上。
- 传输层
- 数据的传输都是在这层定义的，数据过大分包分片。
- 网络层
- 为数据在节点之间传输创建逻辑链路
- 数据链路层
- 通讯实体间建立数据链路连接。
- 物理层
- 主要作用是定义物理设备如何传输数据（光缆、网线）
发展
HTTP 0.9
- 只有一个GET，发送完毕就关闭tcp协议。
HTTP 1.0
- 增加了GET POST HEAD
- Status Code
- Header
- 多字符集支持
- 权限
- 缓存
- 内容编码
- 多部分发送
缺点：每个TCP连接都只能发送一个请求，发送数据完毕连接就关闭。如果还要请求其他资源就必须再新建一个连接。但是TCP新建连接的成本很高，因为客户端和服务器需要三次握手，而且刚开始发送的时候效率很慢。有些浏览器为了解决这个问题使用了一个非标准的Connection字段
Connection:Keep-alive这个字段要求服务器不要关闭TCP连接，以便其他请求复用。HTTP 1.1
- 增加了OPTIONS、PUT、PATCH、DELETE、TRACE、CONNECT
- 持久连接
- 增加host
缺点：虽然1.1版本支持TCP复用，但是同一个TCP连接中，所有数据通信是按照次序进行的，服务器只有处理完一个回应才会进行下一个回应。会造成队头堵塞，这就导致一些网页优化技巧：合并脚本和样式表、图片嵌入CSS代码、域名分片等。
HTTP 2.0
- 二进制传输
- 信道复用
- 分帧传输
- Sever Push
三次握手
- 第一次握手: 发送SYN报文, 传达信息: “你好, 我想建立连接”
- 第二次握手: 回传SYN+ACK报文, 传达信息: “好的, 可以建立链接”;
- 第三次握手: 回传ACK报文, 传到信息: “好的, 我知道了, 那我们连接”。然后建立连接
TCP为什么要进行三次握手：因为网络传输有延迟，客户端发送请求到服务器端要求建立连接，如果服务器端直接返回的话可能会产生丢 包的情况导致客户端接收不到数据，客户端会因为超时就关闭了，可能就去发送新的请求了，然而服务端并不知道丢包导致客户端没有接收数据，服务端端口就一直开着，造成了额外的开销。所以需要三次握手确认 这个过程。
报文
- 请求报文
- 请求组成：请求行，消息报头，请求正文
- 响应报文
- 响应组成：状态行，消息报头，响应正文
状态码
- 1XX：指示信息–表示请求已接收，继续处理。
- 2XX：成功–表示请求已被成功接受、理解、接受。
- 3XX：重定向–要完成请求必须进一步操作。
- 4XX：客户端错误–请求有语法错误或无法实现。
- 5XX：服务端错误–服务端未能实现合法的请求。
Cache-Control
Cache-Control 是一个 HTTP 协议中关于缓存的响应头，它由一些能够允许你定义一个响应资源应该何时、如何被缓存以及缓存多长时间的指令组成。 当浏览器保存了资源的副本从而达到 快速访问的目的 的时候也就是 HTTP 发生了缓存。
- 可缓存性：
- public 任何都可以
- private 只有它发起浏览器可以缓存
- no-cache 去服务端验证才能使用
- no-store 彻底不能
- no-transform 代理服务器、客户端实体不能改动返回内容
- 到期时间
- max-age 最大时间
- s-maxage 只有在代理服务器才会生效
- max-stale 只能在发起端设置 就算max-age时间过期 max-stale时间没过期也会走缓存
长连接
Connection：keep-alive/close 打开关闭
打开的话就是TCP连接上把HTTP请求的内容发送并接受完返回，不需要多次握手。
这里可以设置关闭时间，也有些浏览器会有TCP并发限制，比如Chrome浏览器就是6次并发请求限制。
数据协商
请求
Accept 什么类型
Accept-Encoding 压缩方式
Accept-Language 语言
user-Agent 浏览器信息
返回
Content-type 类型
Content-Encoding 压缩类型
Content-Language 语言
CSP 内容安全策略
- 限制方式：Content-Security-Policy:””
如果没有按照限制的方式加载会发回一个错误信息
HTTPS
HTTPS是通过握手进行加密，通过公钥进行加密，通过私钥进行解密。
- 流程
- 客户端请求服务器获取
证书公钥 - 客户端解析证书
- 生成随机值
- 用
公钥加密随机值生成密钥 - 客户端将
秘钥发送给服务器 - 服务器用
私钥解密得到随机值 - 将信息和随机值混合在一起进行对称加密
- 将加密的内容发送给客户端
- 客户端用
秘钥解密信息
- 客户端请求服务器获取
跨域
跨域原因
浏览器的同源策略限制了跨域请求资源。
JSONP跨域
JSONP（JSON with Padding）是一个非官方的协议，它允许在服务器端集成Script tags返回至客户端，通过javascript callback的形式实现跨域访问。具体来说，当一个网页想要从另一个域名获取数据时，它会向那个域名发送一个请求，然后在返回的响应中插入一段script标签，这段标签的src属性就是数据所在的URL。这样，浏览器就会去执行这段script标签中的JavaScript代码，从而获取到数据。但是这种方法存在一定的安全风险，因为它绕过了浏览器的同源策略。
跨域的限制
- 默认跨域允许的方法只有GET、POST、HEAD，其他的方法都不允许。
- 默认允许Content-type以下三个，其他的预请求验证，通过就能发送。
- text/plain
- multipart/form-data
- application/x-www-form-urlencoded
- 请求头限制，自定义的请求头是不允许的，预请求验证才能通过。
Cookie & Session & Token 的区别
Cookies
客户端的浏览器发出HTTP请求，服务器会进行Cookie设置，也就是set-Cookie，Cookie发送给浏览器之后，浏览器会保存起来，之后发送的每一个请求都会附上这个Cookie。
但是Cookie本身是有有被篡改风险的，同时用户可能禁用、容量限制4KB。
Session
相当于加密版的Cookie，首先也是浏览器发出HTTP请求，服务器这边会设置一个SessionID，并把此ID和会话结束时间一起记录到Cookie返回到客户端，然后不带有用户的密码，只带有SessionID和会话结束时间，在结束时间到的时候就删除cookie，然后由于cookie性质，每次访问都会附上cookie，所以就可以实现长时间登录了。
但是如果多很多用户，那么SessionID对于服务器将是一个巨大的负担；如果拥有多台服务器的话，那么SessionID又需要去共享给每一台服务器。太笨拙了。
Token
多服务器的情况下，如果想要存储SessionID的话，可以放到数据库中，但是如果数据库和后端连接的某个地方又炸了呢。种种情况下催生出了JWT(JSON Web Token)
也是像上面那样的，首先是浏览器发出HTTP请求，给到一个JSON格式的账号密码给服务端，服务端将其转化为JWT签名密文发给客户端，根据Cookie的性质，每次都会把JWT密文发回给服务端，这样就可以认证登录了。
JWT是由三个部分构成的
header.payload.signature
header部分声明需要用什么算法来生成签名。payload部分是一些特殊的数据，比如有效期之类的。
headerpayload的JSON格式Base64编码之后 服务器保存的一段密码对这俩进行算法运算，算出来的东西就是signature
总结
Cookie是一个载体，Session是保存在服务器那边的下信息，Token是诞生于服务器但是保存在浏览器这边。
Session Storage & Local Storage & Cookie 的区别
Session Storage
Session Storage 是用于本地存储一个会话中的数据，当会话结束时数据就会被销毁，也就是浏览器关闭的时候就会被销毁。Session Storage 和 Session 不是一个东西 。
是 Web Storage 用于本地存储的一个方式。
Local Storage
Local Storage 是持久化的存储数据，不删除（通过各种方式）是不会消失的。
是 Web Storage 用于本地存储的一个方式。
Cookie
Cookie 是存储在浏览器端的一小段文本数据，每次向服务端发送请求的时候Cookie都会被发送过去。故Cookie不能作为前端的数据缓存。将token存储到cookie中一般是由后端实现。
是HTTP规范的一部分。