超文本传输协议
它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应
常见状态码:
1类:协议处理的中间状态。
2类:200请求成功,非HEAD请求有body部分。204,请求成功但是只有head,206,请求成功但是body是一部分数据,不是全部。
3类:需要重定向,301永久重定向,302临时重定向,304缓存资源重定向。
4类:客户端请求错误,400是个笼统的错误,未指明,403拒绝客户端访问,404客户端请求的资源不存在。
5类:500笼统错误,501功能未开放,502服务器后端出问题,503服务器忙响应不了
常见字段
host:客户端指定自己想访问的http服务器的域名/IP 地址和端口号。
content-length:内容长度单位字节。
connection:默认keep-alive
content-type:数据的格式,html,css,js
accept:可以接收的数据类型,同上。*/*表示全部
content-encoding:数据的压缩格式,gzip,deflate
accept-encoding:可以接收的压缩格式
charset:字符编码方式,UTF-8
get和post的关系:GET是向服务器请求数据,post是传数据给服务器,get将参数写在头部,post写在body
http优点:简单:报文格式就是head+body,头部信息也是key-value形式,很容易看懂
灵活易扩展:头部字段由用户自定义
应用平台广泛:从浏览器到手机里的各种app都有
缺点:无状态,明文传输
无状态:不方便同一个用户进行相关联的请求,比如淘宝的添加到购物车,怎么验证是添加到谁的购物车。通过cookie解决。
明文传输:方便调试和阅读,不可以存储重要的数据,会被抓包,所以用HTTPS改进。
HTTP1.1相比于1.0:
长连接:1.0是短连接,发送和接收一个请求之后就要断开连接,效率不高,http1.1改用了长连接,
管道网络传输,不用等第一个请求回应之后再发送第二个请求,可以在第一个请求发送完之后直接发送第二个。
http2.0
基于HTTPS
压缩头部:hpack算法 客户端和服务器端各维持一张头部字段索引表,当发送重复的头部字段的时候可以用索引号来代替,节省空间。
二进制格式:不再像之前的ascii字符纯文本格式报文一样,现在改用二进制比特流格式,头部和body都是二进制数字,并且统称为帧。头信息帧+数据帧,以前是请求头+空行+请求体。提高了数据的传输效率。
数据流发送:数据包不再是按顺序发送,而是按数据流的方式,一个连续的数据包可能属于不同的请求和回应,一个请求或者回应的所有数据包称为一个数据流,为了区分,会给每个数据包编号,一般客户端是奇数号,服务器端是偶数号。
多路复用:可以多个请求并发发出,服务器端也不用按顺序回复,避免了队头阻塞。
服务器推送:服务器不再被动的接收客户端的请求,服务器可以把客户端可能需要的数据提前发送给客户端。比如在请求HTMl文件的时候,可能把相关的css,js文件也发过去。
http3: 2中多个请求复用一个tcp连接,导致一个请求出错,全部请求堵塞或者重传。
所以3使用UDP,并且用QUIC协议实现可靠传输
https握手过程:
第一步:clienthello
发送一个随机数clientkey
发送支持密码套件,协议的版本信息。
第二步:severhello
发送一个随机数,确认密码套件,还有一个数字证书,这个证书里面有一个公钥,是服务器端通过非对称加密算法得出来的,例如RSA,服务器的公钥向CA机构注册,CA机构会用摘要算法算出摘要,并用CA的私钥进行加密,得到数字签名,然后向服务器端颁发数字证书,这个证书包括证书颁布时间,颁布机构,有效期等信息。
第三步:
客户端验证数字证书,用CA的公钥来验证,这个公钥是事先就置入到浏览器或者操作系统中的。公钥解密获得数字签名,用相同的摘要算法(数字证书里面有)算出摘要,和数字证书里的摘要进行比对,相等就证明证书合法。然后取出公钥,加密第三个随机数,发送给服务器端。
这样客户端就可以用三个随机数生成一个对称加密的密钥,之后加解密都用这个。
客户端结束握手,将之前的所有握手信息做成一个摘要发送给服务器端,供服务器端检查验证。
第四步:
服务器端收到第三个随机数,用私钥解密,然后获得了对称加密的公共密钥。将之前的所有握手信息做成一个摘要,发送给客户端,结束握手过程。
然后客户端收到之后开始使用密钥进行对称加密的数据传输。
非对称加密算法:常用RSA,Elgamal、背包算法、Rabin
对称加密:AES、DES、RC4
摘要算法:SHA1,MD5
数字签名过程:首先是将服务器公钥,证书信息等等制作成一个电子文件,然后再用哈希算法算出摘要,用私钥加密的过程称为数字签名。
中间人攻击: