笔记整理源于小林coding以及字节内部课（不是很完全，后续会慢慢编辑增加）
HTTP
1.基本概念:
HTTP是超文本传输协议，是一个在计算机世界里专门在两点之间传输文字、图片，音频，视频，等超文本数据的约定和规范
2.常见HTTP状态码
| 1xx | 提示信息，表示目前是协议处理的中间态，还需要后续的操作 |
|---|---|
| 200 | 服务器成功处理客户端的请求 |
| 204 | 响应头没有body数据 |
| 3xx | 客户端的请求资源发生变动，需要客户端用新的url重新发送请求获取资源 |
| 301 | 永久重定向 |
| 302 | 临时重定向，请求的资源还在，但暂时需要用另外一个Url访问(301 和302 都会在响应头里使用字段Location 指明后需要跳转的url浏览器会自动重定向到新的url) |
| 304 | 不跳转，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制 |
| 400 | 客户端请求的报文有误 |
| 403 | 服务器禁止访问资源 |
| 404 | 资源未找到 |
| 500 | 服务器中错误 |
|---|---|
| 501 | 客户端的请求的功能还不支持 |
| 502 | 服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误 |
| 503 | 服务器当前很忙，暂时无法响应客户端 |
4.get 和post 的区别
get 是从服务器获取指定资源，请求的参数一般写在url中
post 的语义是根据请求负荷（报文body)对指定的资源进行处理
5.安全 和幂等
安全: 请求方法不会破坏服务器上的资源
幂等:执行相同操作结果都是相同的
get 安全且幂等 ，因为它只读，无论操作多少次，服务器上的数据都是安全且相同的，可以对get数据进行缓存，这个缓存可以做到浏览器上，也可以做到代理上（nginx)
post 是新增或者提交数据的操作，会修改服务器上的资源，不安全，且多次提交数据会创建多个资源，所以是不幂等的
6.HTTP缓存技术
常用请求头
a.强制缓存技术
强制缓存指的是只要浏览器缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用浏览器本地缓存的主动性在于浏览器这边
返回状态码中200(from disk cache) 就是强制缓存
强缓存利用两个HTTP响应头部字段实现，他们都用来表示资源在客户端缓存的有效期
当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在response头部加上cache-control,他设置了过期时间的大小
浏览器再次访问服务器中的资源时，会先计算资源是否过期，如果没有，则使用缓存，否则则重新请求服务器
服务器再次收到请求后，会再次更新response头部的cache-control
b.协商缓存技术
与服务端协商止呕通过协商结果来判断是否可以使用本地缓存
比如;304状态码，这种通过服务端告知客户端是否可以使用缓存的方法才被称为协商缓存
协商缓存基于两种头部实现
- 请求头部的If-Modify-Since和响应头部的Lat-Modified-Since，当资源过期时，浏览器发现响应头部有Etag ，则再次向服务器发送请求时，会将请求头If-None-Match 值设置为Etag值，服务器收到请求后进行对比，如果资源没有变化返回304 ，如果资源变化就返回200
- 响应头部的If-None-Match 和响应头部的Etag 字段，唯一标识响应资源
7.HTTP/1.1的优点
1.简单
HTTP 基本的报文格式就是header+body,头部信息也是 key-value 简单文本的形式， 易于理解， 降低了学习和使用的门槛。
- 灵活和易于扩展 HTTP 协议里的各类请求方法、URl/URL、状态码、头字段等每个组成要求都没有被固定死， 都允许开发人员自定义和扩充。 同时HTTP 由于是工作在应用层 ( osI 第七层) ，则它下层可以随意变化， 比如： ·HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层; ·HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议, 而到了 HTTP/3.0传输协议改用了UDP协议。
- 应用广泛和跨平台 互联网发展至今， HTTP的应用范围非常的广泛， 从台式机的浏览器到手机上的各种APP， 从看新闻、刷贴吧到购物、理财、吃鸡， HTTP的应用遍地开花， 同时天然具有跨平台的优越性。
8.HTTP/1.1缺点
1.无状态双刃剑
无状态的好处， 因为服务器不会去记忆HTTP的状态， 所以不需要额外的资源来记录状态信息， 这能减轻服务器的负担， 能够把更多的CPU 和内存用来对外提供服务。无状态的坏处， 既然服务器没有记忆能力， 它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付， 这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的， 每次都要问一遍身份信息。这样每操作一次， 都要验证信息， 这样的购物体验还能愉快吗? 别问， 问就是酸爽！对于无状态的问题， 解法方案有很多种， 其中比较简单的方式用 Cookie技术。Cookie 通过在请求和响应报文中写入 Cookie信息来控制客户端的状态。相当于， 在客户端第一次请求后， 服务器会下发一个装有客户信息的「小贴纸」， 后续客户端请求服务器的时候， 带上「小贴纸」， 服务器就能认得了了，
2.明文传输双刃剑
明文意味着在传输过程中的信息， 是可方便阅读的， 比如 Wireshark抓包都可以直接肉眼查看， 为我们调试工作带了极大的便利性。 但是这正是这样， HTTP的所有信息都暴露在了光天化日下， 相当于信息裸奔。在传输的漫长的过程中， 信息的内容都毫无隐私可言， 很容易就能被窃取， 如果里面有你的账号密码信息，那你号没了。
3.不安全
HTTP 比较严重的缺点就是不安全： ·通信使用明文(不加密) ，内容可能会被窃听。比如， 账号信息容易泄漏， 那你号没了。 ·不验证通信方的身份， 因此有可能遭遇伪装。比如， 访问假的淘宝、拼多多， 那你钱没了。 ·无法证明报文的完整性， 所以有可能已遭篡改。比如， 网页上植入垃圾广告， 视觉污染， 眼没了。 HTTP 的安全问题， 可以用HTTPS 的方式解决， 也就是通过引入SSL/TLS层， 使得在安全上达到了极致。
9.HTTP/1.1性能如何
HTTP协议基于TCP/IP ,使用了请求-应答的通信模式。所性能的关键在于这两点里
1.长连接
早期的HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建起一次TCP连接（三次握手）而且是串行请求，做了无谓的TCP的连接和断开，增加了通信开销
HTTP/1.1持久连接的特点是只要任意一端没有明确提出断开连接，则保持TCP连接状态
当然，如果某个http长时间超过一定时间没有任何数据交互，服务端就会主动断开这个连接
2.管道网络传输
HTTP/1.1 采用了长连接的方式, 这使得管道 ( pipeline) 网络传输成为了可能。 即可在同一个TCP 连接里面， 客户端可以发起多个请求， 只要第一个请求发出去了， 不必等其回来， 就可以发第二个请求出去， 可以减少整体的响应时间。 举例来说， 客户端需要请求两个资源。以前的做法是， 在同一个 TCP 连接里面， 先发送A请求， 然后等待服务器做出回应， 收到后再发出B请求。那么， 管道机制则是允许浏览器同时发出A 请求和B 请求， 如下图：
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。 如果服务端在处理A 请求时耗时比较长， 那么后续的请求的处理都会被阻塞住， 这称为「队头堵塞」。 所以，HTTP/1.1管道解决了请求的队头阻塞， 但是没有解决响应的队头阻塞。 TIP 注意!!! 实际上HTTP/1.1管道化技术不是默认开启， 而且浏览器基本都没有支持， 所以后面所有文章讨论HTTP/1.1都是建立在没有使用管道化的前提。大家知道有这个功能， 但是没有被使用就行了。
4.队头堵塞
「请求-应答」的模式会造成HTTP 的性能问题。为什么呢? 因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时， 在后面排队的所有请求也一同被阻塞了， 会招致客户端一直请求不到数据， 这也就是「队头阻塞」， 好比上班的路上塞车。
9.HTTP 与HTTPS
- HTTP 是超文本传输协议， 信息是明文传输， 存在安全风险的问题。HTTPS 则解决 HTTP不安全的缺陷， 在 TCP 和 HTTP 网络层之间加入了：SSL/TLS安全协议， 使得报文能够加密传输。
- HTTP 连接建立相对简单, TCP 三次握手之后便可进行HTTP 的报文传输。而 HTTPS在TCP三次握手之后， 还需进行：SSL/TLS的握手过程， 才可进入加密报文传输。
- 两者的默认端口不一样， HTTP 默认端口号是80， HTTPS 默认端口号是443。
- HTTPS协议需要向CA (证书权威机构) 申请数字证书， 来保证服务器的身份是可信的。
10.HTTPS解决了HTTP的哪些问题?
HTTP是明文传输，安全上存在风险
- 窃听风险
- 篡改风险
- 冒充风险
HTTPS在HTTP与TCP之间加入了SSL/TLS协议，可以解决以上问题
- 信息加密：交互信息无法被窃取
- 校验机制：无法篡改通信内容，篡改了就不能正常显示
- 身份证书
- 混合加密
- 摘要算法
- 数字证书
1.混合加密:
HTTPS采用的是对称加密和非对称加密结合的混合加密方式
HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：
- 在通信建立前采用非对称加密的方式交换「会话秘钥」， 后续就不再使用非对称加密
- 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
- 对称加密只使用一个秘钥，运算速度快，无法做到安全的密钥交换
- 非对称加密使用两个密钥，公钥和私钥，公钥可以任意分发而四月保密解决了私钥交换问题但速度慢
2.摘要算法和数字签名
为了保证传输的内容不被篡改，我们需要对内容计算出 一个指纹 ，然后同内容一起传输给对方
对方收到后，也是先对内容计算出一个指纹，然后跟发送发发送的指纹做一个比较，如果指纹相同，说明内容没有被篡改，否则就可以判断内容被篡改了
那么，在计算机里会用摘要算法（哈希函数）来计算内容的哈希值，也就是内容的指纹，这个哈希值是唯一的，且无法通过哈希值推到出内容
通过哈希算法可以确保内容不会被篡改，但是并不能保证{ 内容加哈希值} 不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明
为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥
公钥加密，私钥解密，这个目的是为了保证传输内容的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容
私钥加密，公钥解密，这个目的是为了保证消息不会被冒充， 因为私钥是不可泄露的，如果公钥可以解出私钥加密的内容，就能证明这个消息是来源于持有私份身分的人发送的
所以非对称加密的用途主要在于通过「私钥加密， 公钥解密」的方式， 来确认消息的身份， 我们常说的数字签名算法， 就是用的是这种方式， 不过私钥加密内容不是内容本身， 而是对内容I 的哈希值加密。
私钥是由服务端保管， 然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息， 能公钥解密， 就说明该消息是由服务器发送的。
3.数字证书
但是这还远远不够， 还缺少身份验证的环节， 万一公钥是被伪造的呢? 还是拿请假的例子， 虽然你爸爸持有私钥， 老师通过是否能用公钥解密来确认这个请假条是不是来源你父亲的。 但是我们还可以自己伪造出一对公私钥啊！ 你找了个夜晚， 偷偷把老师桌面上和你爸爸配对的公钥， 换成了你的公钥， 那么下次你在请假的时候， 你继续模仿你爸爸的字迹写了个请假条， 然后用你的私钥做个了「数字签名」。 但是老师并不知道自己的公钥被你替换过了， 所以他还是按照往常一样用公钥解密， 由于这个公钥和你的私钥是配对的， 老师当然能用这个被替换的公钥解密出来， 并且确认了内容的完整性， 于是老师就会以为是你父亲写的请假条， 又允许你请假了。 好家伙， 为了一个请假， 真的是斗智斗勇。 后面你的老师和父亲发现了你伪造公私钥的事情后， 决定重新商量一个对策来应对你这个臭家伙。 既然伪造公私钥那么随意， 所以你爸把他的公钥注册到警察局， 警察局用他们自己的私钥对你父亲的公钥做了个数字签名， 然后把你爸爸的「个人信息+公钥+数字签名」打包成一个数字证书， 也就是说这个数字证书包含你爸爸的公钥。 这样， 你爸爸如果因为家里确实有事要向老师帮你请假的时候， 不仅会用自己的私钥对内容进行签名， 还会把数字证书给到老师。
老师拿到了数字证书后， 首先会去警察局验证这个数字证书是否合法， 因为数字证书里有警察局的数字签名， 警察局要验证证书合法性的时候， 用自己的公钥解密， 如果能解密成功， 就说明这个数字证书是在警察局注册过的， 就认为该数字证书是合法的， 然后就会把数字证书里头的公钥(你爸爸的) 给到老师。 由于通过警察局验证了数字证书是合法的， 那么就能证明这个公钥就是你父亲的， 于是老师就可以安心的用这个公钥解密出请假条， 如果能解密出， 就证明是你爸爸写的请假条。 正是通过了一个权威的机构来证明你爸爸的身份， 所以你的伪造公私钥这个小伎俩就没用了。 在计算机里， 这个权威的机构就是CA (数字证书认证机构) ，将服务器公钥放在数字证书(由数字证书认证机构颁发) 中， 只要证书是可信的， 公钥就是可信的。
11.HTTPS一定安全可靠吗?
客户端通过浏览器向服务端发起HTTPS请求时，被假基站转发到了一个中间人服务器，于是客户端是和中间人服务器完成了TLS握手，然后这个中间人服务器再与真正的服务端完成TLS握手
从客户端的角度来看，其实并不知道网络中存在中间人服务器这个角色，那么中间人就可以解开浏览器发起的HTTPS请求里的数据，也可以解开服务端响应给浏览器的数据，相当于，中间人能够看浏览器与服务器之间的所有通信消息
中间人服务器与客户端在 TLS 握手过程中， 实际上发送了自己伪造的证书给浏览器， 而这个伪造的证书是能被浏览器(客户端) 识别出是非法的， 于是就会提醒用户该证书存在问题。
如果用户执意点击「继续浏览此网站」， 相当于用户接受了中间人伪造的证书， 那么后续整个HTTPS 通信都能被中间人监听了。 所以， 这其实并不能说 HTTPS 不够安全， 毕竟浏览器都已经提示证书有问题了， 如果用户坚决要访问， 那不能怪HTTPS， 得怪自己手贱。 另外， 如果你的电脑中毒了， 被恶意导入了中间人的根证书， 那么在验证中间人的证书的时候， 由于你操作系统信任了中间人的根证书， 那么等同于中间人的证书是合法的， 这种情况下， 浏览器是不会弹出证书存在问题的风险提醒的。 这其实也不关HTTPS 的事情， 是你电脑中毒了才导致 HTTPS 数据被中间人劫持的。 所以， HTTPS 协议本身到目前为止还是没有任何漏洞的， 即使你成功进行中间人攻击， 本质上是利用了客户端的漏洞 (用户点击继续访问或者被恶意导入伪造的根证书) ，并不是HTTPS不够安全。
我们要保证自己电脑的安全， 不要被病毒乘虚而入， 而且也不要点击任何证书非法的网站， 这样 HTTPS 数据就不会被中间人截取到了。 当然， 我们还可以通过 HTTPS 双向认证来避免这种问题。 一般我们的 HTTPS 是单向认证， 客户端只会验证了服务端的身份， 但是服务端并不会验证客户端的身份。
如果用了双向认证方式， 不仅客户端会验证服务端的身份， 而且服务端也会验证客户端的身份。服务端一旦验证到请求自己的客户端为不可信任的， 服务端就拒绝继续通信， 客户端如果发现服务端为不可信任的， 那么也中止通信。
响应里面的set-cookie(浏览器帮我设置了一些cookie信息)
HTTP/2
1.概述：
-
更快 ，更稳定 ，更简单，兼容 HTTP/1.2
-
HTTP/2连接都是永久的，而且仅需要，每个来源一个连接
-
流控制：阻止发送发向接收方发送大量的数据机制（比较常见的就是浏览器可以拒绝服务器发送的大量数据，你在暂停视频的时候，服务器没有必要把后面的进度条内容全部返回，可以把带宽，计算资源应用在其他地方，比如你同时在和别人聊天）
-
服务器推送
-
头部压缩
-
HTTP报文都是[ head + body] 对于body ，我们可以在head中设置 [Content-Encoding] 指定body 的压缩方式 (gzip)，但是header 中 就没有办法压缩了，而且header 中也有一些头部字段，有必要压缩
-
大量的请求和响应报文中由很多字段的值都是重复的，使得带宽被占用
-
字符是SCII编码的，计算机执行效率低，有必要改成二进制编码
-
HHTP/2没采用gzip进行压缩，而是采用了HPACK算法 ,主要包括三个部分：
-
- 静态字典
- 动态字典
- Huffman编码（压缩算法）
-
客户端和服务端都会建立和维护字典，用长度较小的索引号表示重复的字符串，再用Huffman编码压缩数据
-
静态表编码
-
动态表编码
-
二进制帧
-
将 HTTP/1 的文本格式改成二进制格式传输数据，
-
并发传输
多个Stream复用一条TCP连接，达到并发的效果，解决HTTP/1.1的对头堵塞问题
1个TCP连接可以包含一个或者多个Stream
Stream 里乐意包含一个或多个Message ,Message 对应HTTP/1的请求或者响应，由HTTP的头部和包体构成;
帧: HTTP/2通信的最小单位 ，每个帧都包含帧头 ，至少也会标识出当前帧所属的数据流
Message 里包含一个或者多个frame ，frame是HTTP/2最小单位，以二进制压缩格式存放HTTP/1中的内容(头部和包体)
多个Stream跑在一条TCP连接，同一个HTTP秦秋与响应在同一个Stream中，http由frame组成 , 一个frame可以由多个TCP报文构成
针对不同的 HTTP 请求用独一无二的 Stream ID 来区分, 接收端可以通过 Stream ID 有序组装成 HTTP 消息， 不同 Stream的帧是可以乱序发送的， 因此可以并发不同的 Stream， 也就是HTTP/2可以并行交错地发送请求和响应。 比如下图, 服务端并行交错地发送了两个响应: Stream 1和 Stream 3, 这两个 Stream都是跑在一个 TCP 连接上, 客户端收到后, 会根据相同的 Stream ID 有序组装成 HTTP 消息。
2.HTTP/2有什么缺陷
HTTP/2通过Stream 的并发能力，解决了HTTP/1的对头堵塞问题，看似很完美了，但是在HTTP/2中依旧存在队头堵塞的问题，只不过问题不在于HTTP层面，而是在TCP这层
HTTP/2是基于TCP协议来传输数据的，TCP是字节流协议，TCP层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给HTTP应用，那么当前一个字节数据没有到达时，后收到的字节数据只能放在内核缓冲区里，只有等到这一个字节数据到达之后，HTTP/2应用层才能从内核中拿到数据，这就是HTTP/2队头堵塞的问题
图中发送方发送了很多个 packet， 每个 packet都有自己的序号， 你可以认为是TCP 的序列号, 其中 packet 3在网络中丢失了, 即使 packet 4-6被接收方收到后, 由于内核中的TCP数据不是连续的， 于是接收方的应用层就无法从内核中读取到， 只有等到 packet 3重传后，接收方的应用层才可以从内核中读取到数据， 这就是HTTP/2的队头阻塞问题， 是在 TCP 层面发生的。 所以， 一旦发生了丢包现象， 就会触发TCP 的重传机制， 这样在一个TCP 连接中的所有的HTTP 请求都必须等待这个丢了的包被重传回来。
3.HTTP/3做了哪些优化
HTTP/1.1有响应的对头堵塞，HTTP/2 有TCP层的堵塞（丢包导致）
HTTP/2对头堵塞是由于TCP,所以把HTTP下层的TCP协议改成了UDP
UDP是不管发送顺序的，也不管丢包的， 所以不会出现像HTTP/2队头堵塞的问题，大家都知道UDP是不可靠传输的，但基于UDP的QUIC协议可以实现类似TCP的可靠性传输
UDP有以下特点
-
无队头堵塞
QUIC协议也有类似HTTP/2Stream 与多路复用的概念，也是可以在同一条连接上并发传输多个Stream,一个Stream就可以认为是一条HTTP请求
QUIC有一套自己的机制可以保证传输的可靠性，当某个流发生丢包时，只会阻塞这个流，其他流不会收到影响，不存在队头堵塞的问题
QUIC连接上的多个Stream之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不会受影响。
-
更快的连接建立
对于HTTP/1和HTTP/2协议，TCP 和TLS 是分层的，分别属于内核实现的传输层，openssl库的表现层，需要分批次握手，先TCP 后TSL
HTTP虽然需要在传输前需要QUIC协议握手，但是这个握手过程只需要1RT ，握手的过程只需要1RTT,握手的目的是为了确认双方的连接ID，连接迁移就是基于连接ID实现的。
但是HTTP/3的QUIC协议并不是与TLS分层，而是QUIC内部包含了TLS , 他在自己的帧会携带TLS里的记录????? ,再加上QUIC使用的是TLS/1.3 ,因此仅需要一个RTT就可以同时完成建立连接与密钥协商？？？？？？
-
连接迁移
基于TCP传输协议的HTTP协议，由于是通过四元组(源IP 源端口，源目的IP , 目的端口)确定一条TCP连接。
- 那么当移动设备的网络从 4G 切换到Wifi时，意味着IP地址变化了，那么就必须要断开连接，然后重新建立连接，而建立连接的过程包含TCP三次握手和TLS四次时延，以及TCP慢启动的减速过程，给用户的体验就是网络突然卡顿了一下，因此连接的迁移成本是很高的
- QUIC 协议没有用四元组的方式来“绑定”连接， 而是通过连接ID 来标记通信的两个端点， 客户端和服务器可以各自选择一组ID 来标记自己，因此即使移动设备的网络变化后， 导致IP 地址变化了， 只要仍保有上下文信息 (比如连接ID、TLS 密钥等) ，就可以“无缝”地复用原连接， 消除重连的成本， 没有丝毫卡顿感， 达到了连接迁移的功能。
- 所以, QUIC 是一个在 UDP 之上的伪TGD+TLS+HTTP/2的多路复用的协议。
- QUIC 是新协议， 对于很多网络设备， 根本不知道什么是 QUIC， 只会当做UDP， 这样会出现新的问题， 因为有的网络设备是会丢掉UDP包的，而 QUIC 是基于UDP 实现的， 那么如果网络设备无法识别这个是 QUIC包， 那么就会当作UDP包， 然后被丢弃。 HTTP/3现在普及的进度非常的缓慢， 不知道未来 UDP 是否能够逆袭TCP。
二、场景分析
1.今日头条
a.我们来看 response 信息
b.静态资源部署方案
- 本地缓存（只能保证用户拿到的够快，但是不能保证够新）
- CDN : Content Delivery NetWork(通过用户就近性和服务器负载的判断 ，CDN确保内容以一种即为高效的方式为用户的请求提供服务)
3.文件名hash (文件每次变化，hash都会改变)
c.登录后观察请求信息
为什么会有optios的请求
跨域 cross-origin
d.跨域解决方案
-
浏览器先发送预请求（大部分情况），看服务端是否允许跨域
用这一系列的协议头帮助我们做一些跨域是否能够访问的权限控制
2.代理服务器
同源策略是浏览器的安全策略，不是HTTP的
部署一个和当前域名放在同域下的代理服务器，我们去请求的时候，先去请求代理服务器
代理服务器: 打包会用到webpack 的插件，里面有代理服务器的功能
3.Iframe （诸多不便）
e.第一次登录后返回信息
f.为什么他会记住登录状态呢
鉴权方案
1.cookie + session
2.JWT (json web token)
SSO单点登录
g.网络优化
扩展：通信方式
既然有Http协议，为什么要有websocket
不断轮询 和 长轮询本质上是客户端主动去取数据
对于扫码登录的简单场景还可以使用，如果是网页游戏，一般会有大量的数据需要从服务器主动推送到客户端
基于TCP新协议: Websocket
2.微博网站
未登录前，微博某css文件是来自于缓存，响应标头带有Etag 标识，缓存时间，返回的文本类型等
其他基本与今日头条无异
为什么一个网站会有很多cookie?等我慢慢整理出来完善..........................
