网络相关的知识,GET和POST有什么区别
GET和POST区别
GET和POST区别请求是拼接在url后面 POST请求参数是在Body里面
GET和POST区别限制参数的长度为2048字节 POST则没有
GET和POST区别请求不安全 POST请求比较安全
GET
安全的 不应该引起server端的任何状态变化 还有 HEAD OPTIONS请求
幂等的 同一个请求方法一次和请求多次执行的效果完全相同 PUT DELETE
可缓存的
POST
非安全的 非幂等的 不可缓存的
状态码
1xx 2xx 3xx 4xx 5xx
除了常见的GET和POST请求外 你还知道哪些请求方法
DELETE 用作服务器删除资源
PUT 向服务器上传资源
PATCH 用作修改服务器的部分资源信息
三次握手与四次挥手
三次握手
1.第一次握手: 客户端给服务器发送一个 SYN 报文。
第一次握手: 客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
2.第二次握手: 服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文。
第二次握手: 服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
3.第三次握手: 客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文。
第三次握手: 客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。
服务器收到 ACK 报文之后,三次握手建立完成。
四次挥手
1.第一次挥手: 客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于CLOSED_WAIT1状态。
2.第二次握手: 服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于CLOSE_WAIT2状态。
3.第三次挥手: 如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
4.第四次挥手: 客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
这里特别需要注意的就是TIME_WAIT这个状态了,这个是面试的高频考点,就是要理解,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。
服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。
三次握手过程中可以携带数据吗?
第三次握手的时候,是可以携带数据的。也就是说,第一次、第二次握手不可以携带数据,而第三次握手是可以携带数据的。
第一次握手如果可以放数据的话,其中一个简单的原因就是会让服务器更加容易受到攻击了。
第三次的话,此时客户端已经处于 established 状态,也就是说,对于客户端来说,他已经建立起连接了,并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据页没啥毛病
为什么要四次挥手?
由于 TCP 的半关闭(half-close)特性,TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了TCP连接。
通俗的来说,两次握手就可以释放一端到另一端的 TCP 连接,完全释放连接一共需要四次握手。
怎样判断一个请求是否结束?
Content-length 1024 通过请求数是否达到了请求长度 chunked 最后会有一个空的chunked
常见的网络状态码有哪些?
2xx:响应成功
200 网络请求成功
201 请求成功并创建新的资源
3xx:重定向
301 请求的资源被永久移动到新的URI,响应包括新的URI
304 资源未被修改,客户端可以使用缓存的版本
4xx:客户端错误
403 服务器拒绝请求 一般用户鉴权时效 以及后序的退出登录等处理
404 请求的资源未找到 一般网页端的比较显著 请求一个内容不存在的url就会返回该信息
5xx:服务器错误
500 服务器错误
Charles抓包原理是怎样的?
利用http中间人攻击
https的建立连接的流程?
客服端请求服务器端 要先进行证书校验 通过之后才能发起连接
HTTPS都使用了哪些加密手段?为什么?
连接建立过程使用非对称加密。非对称加密很耗时 后续通信过程使用户对称加密
非对称加密
一个加密用公钥或者私钥,解密私钥或者公钥
对称加密
加密解密都是同一个密钥
TCP和UDP
建立一个 TCP 连接需要三次握手,而终止一个 TCP 连接要经过四次挥手
TCP 面向连接 传输数据之前需要建立连接 可靠传输 面向字节流 流量控制 拥塞控制 文件传输、发送和接收邮件、远程登录等场景 UDP 是不需要建立连接的 尽最大努力交付 面向报文->既不合并也不拆分 复用 分用 差错检测(IM即时聊天用户发送消息) QQ 语音、 QQ 视频 、直播等等
DNS解析 解析之中常见的问题
域名到ip的映射,DNS解析请求采用UDP数据报,且明文
DNS劫持问题
劫持你的域名给你返回一个其他的ip地址的
怎样解决劫持?
可以通过httpDNS或者长连接来解决
什么是httpDNS?
原本是DNS协议向DNS服务器的53端口进行请求 现在改为 -> 通过HTTP协议向服务端的80端口进行请求
长连接是怎样解决劫持的问题的?
在客户端和服务端之间建议一个长连的server(代理服务器) 客户端和长连建议一个长连通道 然后服务端和长连服务端进行交互
DNS劫持和HTTP的关系是怎样的
没有关系 因为解析是发生在HTTP建立连接之前的 DNS解析请求使用UDP数据报,端口号是53
DNS解析转发
把你的请求转发给其他的DNS解析方
Session/Cookie
Cookie
通过对HTTP协议无状态特点的补偿
Cookie主要用来记录用户状态,区分用户
状态保存在客户端
怎样修改Cookie
新Cookie覆盖旧Cookie
如果是删除Cookie 可以设置一个过期的时间就可以进行删除
怎样保证Cookie的安全
对Cookie进行加密处理
只在https上携带Cookie
设置Cookie为httpOnly,防止跨站脚本攻击
Session
Cookie主要用来记录用户状态,区分用户
状态保存在服务端
Session的工作需要依赖Cookie来实现
用户端请求的时候 客户端会生成一个seeionId 然后通过Cookie发给客户端 然后客户端下次请求的时候携带上这个sessionId 服务端就可以识别用户了