http1.0 http1.1 http2.0的区别
HTTP 1.0(1996年)
- 任意数据类型都可以发送
- 有GET、POST、HEAD三种方法
- 无法复用TCP连接(长连接)
- 有丰富的请求响应头信息。以header中的
Last-Modified/If-Modified-Since和Expires作为缓存标识
HTTP 1.1(1997年)
- 引入更多的请求方法类型
PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT - 引入长连接，就是TCP连接默认不关闭，可以被多个请求复用，通过请求头connection:keep-alive设置
- 引入管道连接机制，可以在同一TCP连接里，
同时发送多个请求 - 强化了缓存管理和控制
Cache-Control、ETag/If-None-Match - 支持分块响应，断点续传，利于大文件传输，能过请求头中的
Range实现 - 使用了
虚拟网络，在一台物理服务器上可以存在多个虚拟主机，并且共享一个IP地址
缺点：主要是连接缓慢，服务器只能按顺序响应，如果某个请求花了很长时间，就会出现请求队头阻塞
虽然出了很多优化技巧：为了增加并发请求，做域名拆分、资源合并、精灵图、资源预取...等等
最终为了推进从协议上进行优化，Google跳出来，推出SPDY协议
HTTP 2.0(2015年)
说出http2中至少三个新特性？
- 使用新的
二进制协议，不再是纯文本，避免文本歧义，缩小了请求体积 多路复用，同域名下所有通信都是在单链接(双向数据流)完成，提高连接的复用率，在拥塞控制方面有更好的能力提升- 使用
HPACK算法将头部压缩，用哈夫曼编码建立索表，传送索引大大节约了带宽 - 允许
服务端主动推送数据给客户端 - 增加了安全性，使用HTTP 2.0，要求必须至少TLS 1.2
- 使用虚拟的流传输消息，解决了应用层的队头阻塞问题
缺点
- TCP以及TCP+TLS建立连接的延时，HTTP2使用TCP协议来传输的，而如果使用HTTPS的话，还需要TLS协议进行安全传输，而使用TLS也需要一个握手过程，在传输数据之前，导致我们花掉3~4个RTT
- TCP的队头阻塞并没有彻底解决。在HTTP2中，多个请求跑在一个TCP管道中，但当HTTP2出现丢包时，整个TCP都要开始等待重传，那么就会阻塞该TCP连接中的所有请求
HTTP1 和 HTTP2
- HTTP2是一个
二进制协议，HTTP1是超文本协议，传输的内容都不是一样的 - HTTP2报头压缩，可以使用HPACK进行
头部压缩，HTTP1则不论什么请求都会发送 - HTTP2
服务端推送(Server push)，允许服务器预先将网页所需要的资源push到浏览器的内存当中 - HTTP2遵循
多路复用，代替同一域名下的内容，只建立一次连接，HTTP1.x不是，对域名有6~8个连接限制 - HTTP2引入
二进制数据帧和流的概念，其中帧对数据进行顺序标识，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况，同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。HTTP2对同一域名下所有请求都是基于流的，也就是说同一域名下不管访问多少文件，只建立一次连接
HTTP 3.0/QUIC
由于HTTP 2.0依赖于TCP，TCP有什么问题那HTTP2就会有什么问题。最主要的还是队头阻塞，在应用层的问题解决了，可是在TCP协议层的队头阻塞还没有解决。
TCP在丢包的时候会进行重传，前面有一个包没收到，就只能把后面的包放到缓冲区，应用层是无法取数据的，也就是说HTTP2的多路复用并行性对于TCP的丢失恢复机制不管用，因此丢失或重新排序的数据都会导致交互挂掉
为了解决这个问题，Google又发明了QUIC协议
并在2018年11月将QUIC正式改名为HTTP 3.0
特点：
- 在传输层直接干掉TCP，用
UDP替代 - 实现了一套新的
拥塞控制算法，彻底解决TCP中队头阻塞的问题 - 实现了类似TCP的
流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性 - 实现了
快速握手功能。由于QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或者1-RTT来建立连接，这意味着QUIC可以用最快的速度来发送和接收数据。 - 集成了TLS加密功能。目前QUIC使用的是TLS1.3
http & https
HTTP 和 HTTPS 的区别
- HTTP是
明文传输，不安全的，HTTPS是加密传输，安全的多 - HTTP标准端口是
80，HTTPS标准端口是443 - HTTP不用认证证书
免费，HTTPS需要认证证书要钱 连接方式不同，HTTP三次握手，HTTPS中TLS1.2版本7次，TLS1.3版本6次- HTTP在OSI网络模型中是在
应用层，而HTTPS的TLS是在传输层 - HTTP是
无状态的，HTTPS是有状态的
网络模型
五层： 应用层，传输层、网络层、数据链路层、物理层
七层：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
GET 和 POST 的区别
-
GET在浏览器回退时是无害的，而POST会再次发起请求 -
GET请求会被浏览器主动缓存，而POST不会，除非手动设置 -
GET请求参数会被安逗保留在浏览器历史记录里，而POST中的参数不会被保留 -
GET请求在URL中传递的参数有长度限制(浏览器限制大小不同)，而POST没有限制 -
GET参数通过URL传递，POST放在Request body中 -
GET产生的URL地址可以被收藏，而POST不可以 -
GET没有POST安全，因为GET请求参数直接暴露在URL上，所以不能用来传递敏感信息 -
GET请求只能进行URL编码，而POST支持多种编码方式 -
对参数的数据类型，
GET只接受ASCII字符，而POST没有限制 -
GET产生一个TCP数据包，POST产生两个数据包(Firefox只发一次)。GET浏览器把 http header和data一起发出去，响应成功200，POST先发送header，响应100 continue，再发送data，响应成功200
常见 HTTP 状态码
1xx: 指示信息——表示请求已接收，继续处理
2xx: 成功——表示请求已被成功接收
3xx: 重定向——表示要完成请求必须进行进一步操作
4xx: 客户端错误——表示请求有语法错误或请求无法实现
5xx: 服务端错误——表示服务器未能实现合法的请求
常见状态码：
| 状态码 | 描述 |
|---|---|
| 200 | 请求成功 |
| 206 | 已完成指定范围的请求(带Range头的GET请求),场景如video,audio播放文件较大,文件分片时 |
| 301 | 永久重定向 |
| 302 | 临时重定向 |
| 304 | 请求资源未修改，可以使用缓存的资源，不用在服务器取 |
| 400 | 请求有语法错误 |
| 401 | 没有权限访问 |
| 403 | 服务器拒绝执行请求，场景如不允许直接访问，只能通过服务器访问时 |
| 404 | 请求资源不存在 |
| 500 | 服务器内部错误，无法完成请求 |
| 503 | 请求未完成，因服务器过载、宕机或维护等 |
dns解析的过程
dns是应用层协议，它是为其他的应用层协议服务的，包括但不局限于http、ftp、smtp等。
我们的浏览器或者手机端都运行了dns客户端，当用户输入域名的时候，第一步会将url中的域名抽取出来，然后发送给dns服务端。
dns服务端会根据传输过来的域名，找到对应的ip地址进行返回。
dns预解析
dns预解析的用法
<link rel="dns-prefetch" href="https://baidu.com/">
背后的原理：
- 浏览器缓存
- 系统缓存
- 路由器缓存
- ISP(运营商)DNS缓存
- 根域名服务器
- 顶级域名服务器
- 主域名服务器
一次预解析可减少至少15-300ms的时间
dns-prefetch 相当于在浏览器缓存之后，在本地操作系统中做了DNS缓存，个人理解，为的是给浏览器缓存做保障，尽量让DNS解析出本地，以此来做了又一层DNS解析优化。
csrf攻击的防范方法
- 验证码
- 同源检测 根据refer字段检测
- Token
tcp的拥塞控制是什么？tcp怎么保证可靠传输的？
网络中的路由器会有一个数据包处理队列，当路由器接收到的数据包太多而一下子处理不过来时，就会导致数据包处理队列过长。此时，路由器就会无条件的丢弃新接收到的数据封包。 这就会导致上层的 TCP 协议以为数据包在网络中丢失，进而重传这些数据包，而路由器又会丢弃这些重传的数据包，如此以往，就会导致网络性能急剧下降，引起网络瘫痪。因此，TCP 需要控制数据包发送的数量来避免网络性能的下降。
拥塞控制使用了两个重要的算法： 慢启动算法， 拥塞避免算法
慢启动算法： 慢启动算法的思路是，不要一开始就发送大量的数据，先试探一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。慢算法中，每个传输轮次后将 cwnd 加倍。
拥塞避免算法： 拥塞避免算法也是逐渐的增大 cwnd 的大小，只是采用的是线性增长 而不是像慢启动算法那样的指数增长。 具体来说就是每个传输轮次后将 cwnd 的大小加一（加法增大），如果发现出现网络拥塞的话就按照上面的方法重新设置ssthresh的大小（乘法减小，原来的二分之一）并从cwnd=1开始重新执行慢开始算法。
TCP 的可靠传输的原理就是超时重传机制，而重发机制有两种：超时重传机 和 快重传
tcp && udp
对比
| UDP | TCP | |
|---|---|---|
| 是否连接 | 无连接 | 面向连接 |
| 是否可靠 | 不可靠传输，不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 连接对象个数 | 支持一对一，一对多，多对一和多对多交互通信 | 只能是一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 首部开销 | 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
| 适用场景 | 适用于实时应用（IP电话、视频会议、直播等） | 适用于要求可靠传输的应用，例如 |
