# HTTP
# 1.http和https的区别?
- http传输的是明文数据,https传输的是加密后的数据
- http端口是80,https端口是443
- https是基于SSL加密的http协议
# 2.https如何用ssl协议加密?
- https是http+ssl;https采用的是对称加密和非对称加密结合的方式。证书验证用非对称加密,信息传输用对称加密。
ssl加密流程:
- 客户端发起请求,服务端返回证书给客户端,证书里有公钥
- 客户端通过公钥对加密数据的密钥进行非对称加密
- 服务端通过私钥,解密获得密钥,后续数据传输都用这个密钥对数据进行对称加密。
如何解决非对称加密效率低和保证发送公钥的就是正确的人?可以通过CA证书
# 3.常见状态码?
200 OK 请求成功
201 Created 成功请求并创建新的资源
204 No Content 成功但服务器无返回
206 Partial Content 服务器成功处理了部分请求 =》断点续传
301 Moved Permanently永久移动 域名跳转 =》会缓存,新旧域名更替
302 Found 临时移动 未登录用户重定向到登陆页 =》没有缓存
304 Not Modified 未修改 此时服务器不会返回任何请求资源。客户端通常会缓存访问过的资源。=》协商缓存
307 Temporary Redirect 临时重定向 重定向时不会改变method(301和302都会把method改成get)
308 Permanent Redirect 永久重定向 重定向时不会改变method
400 Bad Request 错误请求
401 Unauthorized 需要用户身份认证
403 Forbidden 服务器拒绝
404 Not Found 服务器找不到资源
405 Method Not Allowed 请求中的方法被禁止
408 Request Time-out 请求超时
413 Request Entity Too Large 请求实体过大,服务器无法处理
429 Too Many Requests 接口请求次数超过限制
500 Internal Server Error 服务器内部错误
503 Service Unavailable 服务不可用 =》服务器维护
2开头都是成功
3开头都是重定向
4开头代表客户端错误
5开头代表服务器错误
# 4.get和post区别?
- get参数通过url传递,post参数通过请求体传递
- get传递的参数有长度限制(浏览器限制或服务器限制),post没有
- get请求,浏览器把header和参数一起发送给服务器,而post浏览器会先发送 header,服务器返回100 continue,再发送参数(data)
# 5.get和post请求在缓存上的区别?
get常用来获取数据,可以不用每次都查询数据库,所以适合做缓存,post常用来修改和删除数据,必须与数据库交互,所以不适合
# 6.tcp三次握手(建立连接)与四次挥手(断开连接)?
# 三次握手=>握手不传递数据,等三次握手成功后才开始传输数据
- 客户端先发送syn(syn=j,syn是同步序列编号)包到服务端,进入SYN_SENT状态
- 服务端收到后确认客户的syn(ack=j+1),同时也发送一个syn包(syn=k,即syn+ack)给客户端,此时进入SYN_RECV状态
- 客户端收到服务端的syn包,向服务端发送确认ACK包(ack=K+1),此时都进入ESTABLISHED(TCP连接成功)状态
# 四次挥手=》tcp规定FIN报文即使不带数据,也消耗一个序号
- 客户端发送释放报文,(FIN=1,序列号为seq=u,u等于最后数据的最后一个字节序号+1),此时客户端进入FIN-WAIT-1(终止等待1)状态
- 服务端收到后,发送确认报文,ack=1,ack=u+1,(并且带上自己的seq=v),此时服务端进入了CLOSE-WAIT(关闭等待)状态 客户端收到确认报文后,客户端进入FIN-WAIT-2(终止等待2)状态=>(在此之前服务端如果发送数据客户端还能接收到)
- 服务端将最后的数据发送完毕,向客户端发送释放报文,FIN=1,ack=u+1,服务端进入LAST-ACK(最后确认状态)
- 客户端收到服务端的释放报文后,发送确认报文,ack=1,ack=w+1,而自己的序列号是seq=u+1,此时客户端进入TIME-WAIT(时间等待)状态, 等待2倍MSL(报文最大生存时间)后,客户端进入CLOSED状态
# *seq作用?
seq是初始化序列号,这个序号作为后面通讯的序号,保证数据不乱序
# 为什么两次握手就可以建立链接,还要第三次握手?
双方都确认自己都发送和接收都是正常的 =》为了防止失效的链接请求的报文段被服务端接收,从而产生错误(网络超时,由于超时重试的机制重发的被服务端收到了,但此时客户端已经变成close状态)
# 为什么要等待2MSL(MSL报文最大生存时间,具体MSL时间不一定)
主要防止最后一个ack包对方没收到。2倍MSL就是一个发送和一个回复所需的最大时间
# 为什么要四次挥手才能断开连接?
因为TCP全双工,发送方和接收方都要FIN和ACK报文。
# 全双工是指什么?(半双工不能同时进行信号的双向传输)
可以进行信号的双向传输。
# 滑动窗口=>流量控制(流量控制作用是防止传输速度太快缓冲区被填满,后续发送的数据都丢失)
- 滑动窗口是用来做流量控制的,在TCP中服务端和客户端都维护着窗口:发送端窗口和接收端窗口
- 发送端窗口包含已发送未收到应答的数据和可以发送但未发送的数据,发送端窗口由接收端窗口剩余大小决定的,接收方会把剩余大小写入应答报文,发送端根据应答报文设置窗口大小
# 拥塞控制?
主要作用于接收端,保证能来得及接收数据,防止过多的数据阻塞网络
# TCP/IP如何保证数据包传输的有序可靠?
对字节流进行分段和编号,通过ACK确认和超时重发来保证
- 发送方必须把已发送的数据保留在缓冲区,以保证数据包的可靠传输
- 并且为每个已发送的包启动一个定时器,如果定时器之前收到应答信息,释放缓冲区
- 否则,重传该数据包,直到收到应答或者超过规定的最大次数
- 接收方收到后,先进行CRC校验,正确把数据交给上层协议,然后给发送方一个应答(如果有数据要传给发送方,也可以带过去)
# 7.TCP和UDP区别?
- TCP需要连接,UDP无连接。(UDP发送数据前不需要先建立连接)
- TCP更可靠(重传机制=》发送数据时会设置一个定时器,超过指定时间没有收到对方ACK确认应答报文,就会重发),UDP可能会丢失数据,不可靠
- TCP只支持1对1传输,UDP不仅支持1对1,还支持1对多
- *TCP有拥塞控制,UDP没有
# 用途:
- TCP:电子邮件SMTP,终端连接SSH,文件传输FTP
- UDP:域名解析DNS
# tcp如何保证传输的可靠性?
超时重传机制=》发送数据时会设置一个定时器,超过指定时间没有收到对方ACK确认应答报文,就会重发
# 8.ajax是什么,有什么优缺点?
- ajax从名称翻译过来就是异步js和xml
- 优点:能在不刷新整个页面的情况下与服务器通信,与服务器通信是异步的
- 缺点:ajax不利于搜索引擎优化。如果请求慢会导致页面空白。=》服务端渲染
# axios底层如何实现?
var axios = {
get: function(url) {
return new Promise((resolve, reject) => {
var xhr = new XMLHttpRequest()l
xhr.open('GET', url, true);
xhr.onreadystatechange = function() {
if (xhr.readyState == 4 && xhr.status == 200) {
resolve(xhr.reponseText)
}
}
xhr.send();
})
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
# 9.网络层有什么协议?udp在哪一层,各个层次的代表设备?
从上往下
- 应用层:FTP,HTTP
- 表示层:URL编码
- 会话层:session,断点续传
- 传输层:UDP,TCP
- 网络层:IP,路由器,防火墙
- 数据链路层:网卡,网桥,交换机
- 物理层:集线器,中继器,网线
# 10.跨域=》非简单请求(复杂请求)?
- 如果请求方法是PUT或DELETE或Content-Type字段是application/json都是非简单请求
- 浏览器发现是非简单请求,会自动发送options请求(预检操作),服务器检查origin之后确认允许跨域请求,浏览器才会发送正式的请求。后面就和简单请求一样,
- cors的请求头会多出origin,响应头会多access-control-allow-origin (cors默认不发送cookie,开启需要服务端设置Access-Control-Allow-Credentials: true 客户端withCredentials = true)
# 复杂请求如何实现只预检一次?
后端设置access-control-max-age: 600=》设置一定时间内不用再预检
# 简单请求定义
同时满足:
- 请求方法是HEAD|GET|POST
- HTTP头信息只有Accept|Accept-Language|Content-Language|Last-Event-ID|Content-Type =》其中Content-Type只允许application/x-www-form-urlencoded|multipart/form-date|text-plain
# 11.//TODO
# 12.301,302状态码?
都表示重定向,301代表永久性,302是暂时性。302浏览器会保留旧的地址,301浏览器会把旧的地址替换成重定向后的地址
- 301会缓存 =》 用了301之后每次都会自定重定向到对应的地址
- 301用于更换域名 没有权限跳转到提示页可以用302
- 307临时重定向 重定向时不会改变method
- 308永久重定向 重定向时不会改变method
# 14.HTTP1.0/1.1/2.0/3.0区别?
# http1.1
- HTTP1.1支持长连接(默认开启Connection:Keep-Alive)
- 新增了状态码100(在post请求中有应用。先发送header等服务端返回100 continue才发送body)
- 协商缓存多了Etag/If-None-Match(1.0只有If-Modified-Since)
# http2.0
- http1.1是通过文本传输,2通过二进制格式传输(传输帧和流)
- http1.1有线头阻塞问题,一次连接如果提交多个请求效率比较低,http2采取多路复用解决(多个低速信道合并成一个高速信道,提高了传输效率)
- 压缩了headers(因为headers在请求中常常是相似的,压缩后可以提高传输速度)
- http2支持主动向客户端推送内容
# HTTP2还存在什么问题?
http2解决了http线头阻塞的问题,但是没有解决tcp线头阻塞问题。 http3解决的tcp线头阻塞问题,使用了QUIC协议(使TCP到UDP的网络转换上更加流畅=》减少TCP三次握手时间)
# 15.http常用请求头?
- accept 接受的内容类型 accept:text/plain accept-charset 接受的字符集 accept-charset: utf-8 accept-encoding 接受的编码方式 accept-encoding: gzip
- cache-control 缓存设置 cache-control: no-cache if-match 用来判断是否使用缓存 if-match: "737060cd8c284d8af7ad3082f209582d" if-modified-since 返回304为修改 if-modified-since: Sat, 29 Oct 1994 19:43:31 GMT if-none-match 返回304未修改 if-none-match: "737060cd8c284d8af7ad3082f209582d" if-unmodified-since 特定时间内未被修改 if-unmodified-since: Sat, 29 Oct 1994 19:43:31 GMT
- connection 连接类型 connection: keep-alive
- content-length 请求体长度 content-length: 300
- date 发送该消息的日期和时间 date: Tue, 15 Nov 1994 08:12:31 GMT
- expect 客户端要求服务器做出特殊行为 expect: 100-continue
- origin 发起跨域资源共享的请求 需要服务端设置 origin: http://www.example-social-network.com
- referer 表示浏览器所访问的前一个页面,由这个页面的某个链接带到当前页面 referer: http://zh.wikipedia.org/wiki/Main_Page
- content-type 请求体的(MIME)类型
- host 服务器域名及监听的端口号 host: zh.wikipedia.org:80
- user-Agent 身份标识
- via 告知服务器这个请求是由哪些代理发出的 via: 1.0 fred, 1.1 example.com (Apache/1.1)
# 16.http常用响应头?
- Access-Control-Allow-Origin 指定哪些网站可以跨域资源共享 access-control-allow-origin: *
- Age 响应对象在代理缓存中存在的时间,单位为秒 age: 13
- Cache-Control 通知从服务器到客户端内的所有缓存机制,表示它们是否可以缓存这个对象及缓存时间,单位为秒 cache-control: max-age: 3600
- content-disposition 让客户端下载文件并建议文件名 content-disposition: attachment; filename="a.txt"
- content-encoding 数据上使用的编码类型 content-encoding: gzip
- content-length 响应体长度 content-length: 50
- etag 缓存标识符 etag: "737060cd8c284d8af7ad3082f209582d"
- expires 缓存时间 expires: Thu, 01 Dec 1994 16:00:00 GMT
- last-modified 最后修改日期 last-modified: Tue, 15 Nov 1994 12:45:26 GMT
- location 重定向 location: http://www.w3.org/pub/WWW/People.html
- set-cookie 设置cookie set-cookie: UserID=JohnDoe; Max-Age=3600; Version=1
- via 告诉客户端,响应是从哪里发出的 via: 1.0 fred, 1.1 example.com (Apache/1.1)
# 17.ajax解决浏览器缓存问题?
- 发送前加上setRequestHeader('If-Modified-Since','0')
- 发送前加上setRequestHeader('Cache-Control', 'no-cache')
- url后面添加一个随机数fresh+=Math.random()
# 18.fetch和axios区别?
- fetch由浏览器提供,axios是社区封装XHR
- fetch不支持进度检测,axios支持
- axios可以自动转换JSON数据,fetch需要手动处理
- axios可以防止CSRF
- axios拦截器,拦截请求
# fetch的credentials作用?
发送请求时是否应当发送cookie
- omit 从不发送
- same-origin 同源时发送(默认值)
- include 同源和跨域都发送