http和https
从本篇文章开始总结http协议相关的知识点。http协议相关的内容可以分为四个部分:HTTP报文、HTTP请求、HTTP发展历史、HTTPS。
1. HTTP报文
HTTP全称Hyper Text Transfer Protocol,即超文本传输协议。在OSI七层网络模型中,HTTP属于上层应用层的协议,是一种基于TCP实现的应用层协议(HTTP3改为基于UDP实现)。
1.1 Http是什么?
http协议是一种无状态的、明文传输的数据传输协议。
无状态是指,前后两次请求没有必然的联系,每次请求都是独立的。无状态协议对事务处理没有记忆能力,因此需要通过一些特殊手段来保存用户状态,比如浏览器和服务器可以通过cookie和session保存登录状态。
1.2. Http常见字段有哪些?
Request Headers
HTTP请求头
Accept:自己可以接受哪些数据。
Accept:*/*
Accept-Encoding:客户端可以接受的哪些压缩方法对应的数据。Accept-Encoding:gzip,deflate,br
Connection:使用长连接,HTTP1.1默认使用长连接,为兼容老版本HTTP需要设置Connection:keep-alive
Host字段:请求头中用来指定服务器域名。Host:
Response Headers
HTTP响应头
Connection:使用长连接,HTTP1.1默认使用长连接,为兼容老版本HTTP需要设置
Connection:keep-alive
Content-Encoding:数据压缩方式。Content-Encoding:gzip
Content-Length:本次响应的数据长度Content-Type:服务器响应的数据格式。Content-Type:text/javascript;charset=utf-8
1.3. HTTP特性
HTTP最突出的优点就是简单、灵活和跨平台。另外HTTP也具有无状态和明文传输两种既是优点又是缺点的特性。
HTTP有哪些优点
简单。HTTP报文格式是header + body
,请求头、响应头也是key-value
类型简单文本格式。灵活。HTTP协议中请求方法、URL、状态码和头字段组成都允许开发人员自定义;HTTP工作在应用层,下层可以变化,如HTTPS就是在HTTP层和TCP层加了SSL/TLS安全传输层,HTTP3甚至把TCP换成了基于UDP的QUIC。跨平台。应用广泛,从浏览器到手机APP都应用到了HTTP,天然具有跨平台的优越性。
HTTP有哪些缺点
HTTP的缺点是由HTTP的特性决定的,从一个角度讲,HTTP的特性既是优点又是缺点。我们已经知道HTTP是一种无状态的明文传输协议。
无状态。
明文传输无状态的好处在于,服务器不会去记忆HTTP的状态,所以不需要额外的资源来记录状态信息,这能减轻服务器的负担,节省服务器CPU和内存资源。
无状态的坏处在于,由于服务器没有记忆能力,它在完成有关联性的操作时会非常麻烦。
明文传输意味着所有信息都暴露出来,所有信息内容将毫无隐私可言,会导致内容被窃听或者身份容易伪装,容易被人篡改。
2. HTTP请求
GET: 获取资源POST: 传输实体主体PUT: 上传文件DELETE: 删除文件HEAD: 获取报文首部PATCH: 对资源进行部分修改OPTION: 查询指定的URL能够支持的方法CONNECT: 要求用隧道协议连接代理TRACE: 追踪路径2.1. GET和POST
GET和POST区别
GET参数通过URL传递;POST放在Request body中。GET参数直接暴露在URL中,不能传递敏感信息;POST可以。GET参数在URL中,长度有限制;POST没有。GET请求会被浏览器主动缓存;POST不会,除非手动设置。GET请求的URL地址可以被收藏为书签;POST不可以。GET请求参数会被保存在浏览历史中;POST不会。
2.2. HTTP状态码
1 - 信息。服务器收到请求,请继续执行请求
2 - 成功。请求被成功接收并处理
3 - 重定向。 需要进一步操作来完成请求
4 - 客户端错误。 无法完成请求,或请求包含语法错误
5 - 服务端错误。服务器在处理请求的过程中发生错误
/banana960531/article/details/85621865
3. HTTP1.1、HTTP2、HTTP3
3.1. HTTP1.1相对于HTTP1.0提高了什么性能?
HTTP1.0采用短连接的设计,每次请求都需要经历三次握手和慢启动跟服务器建立TCP连接,响应结束就立即关闭,严重影响性能。服务器并不跟踪每个用户,也不记录过去的请求。
长连接:HTTP1.1将短连接优化成了长连接,即一个TCP连接可以处理多次http请求。在请求头或响应头中可以看到一个connection参数,等于close时可以使TCP请求使用短连接,默认情况下是keep-alive(长连接)。
问题一:HTTP层面,浏览器发送数据的过程
浏览器发送数据时,首先要先构造数据(HTTP格式);其次调用操作系统提供的功能,建立TCP连接;最后发送数据。
问题二:HTTP长连接和Socket的关系
一个Socket可以处理多个HTTP请求(Tomcat中可以设置),如Tomcat拿到一个请求后,解析connection字段中的内容。如果connection字段为closed,在处理完请求后,响应头中connection也为closed,双方就会关闭TCP连接。如果connection字段为keep-alive,在处理完请求后,响应头中connection也为keep-alive,双方就会共用TCP连接。也不是绝对,如Tomcat会设置最多保持的socket(活跃的长连接)的个数,以及一个socket(长连接)最多可以处理多少个HTTP请求(maxKeepRequestAlive选项),在Tomcat处理完指定个数的http请求后,发送的响应头中connection为closed。
问题三:长连接的缺点
长连接也存在缺点:一个TCP连接中,所有的通信数据都是按照次序进行的,服务器只有完成一个请求,才会处理下一个请求,如果前面的请求阻塞了,后面的请求会一直等待,产生“队头阻塞”。
并发:HTTP1.1支持对同一域名同时发起多个http请求(并发处理),但是针对同一域名的并发数量是有限制的。如果想要绕过并发数量的限制,可以将资源放到不同域名的服务器下。
3.2. HTTP2针对HTTP1.1做了哪些优化?
多路复用:数据传输性能显著提高。1.1版本中,多个http请求是通过开启多个TCP连接实现并发的;在2.0中,多个http请求的并发,是在同一个TCP连接中实现的。格式:HTTP 2.0采用二进制格式而非文本格式数据压缩:HTTP1.1不支持header数据压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络中传输也更快了。服务器推送:当向支持HTTP2.0的web server发起请求数据时,服务器可以将一些客户端需要的静态资源一起推送到客户端,免得客户端再次创建连接发起请求到服务器端获取。3.3. HTTP2有哪些缺陷?HTTP3做了哪些优化?
QUIC协议底层协议从TCP切换到UDP。我们知道UDP协议,没有流量控制,滑动窗口等机制,于是就不会对数据包顺序和丢包处理有要求,所以不会出现HTTP1.1中队头阻塞和HTTP2中丢包全部重传的问题。
UDP协议是不可靠传输协议,但基于UPD的QUIC协议,可以在功能上实现类似TCP的可靠性。
机制一:自定义连接机制
一条tcp连接是由四元组标识的,分别是源ip、源端口、目的端口,一旦一个元素发生变化时,就会断开重连,重新连接。再次进行三次握手,导致一定的延时。在TCP是没有办法的,但是基于UDP,就可以在QUIC自己的逻辑里面维护连接的机制,不再以四元组标识,而是以一个64机制二:自定义重传机制位的随机数作为ID来标识,而且UDP是无连接的,所以当ip或者端口变化的时候,只要ID不变,就不需要重新建立连接
tcp为了保证可靠性,通过使用序号和应答机制,来解决顺序问题和丢包问题。任何一个序号的包发过去,都要在一定的时间内得到应答,否则一旦超时,就会重发这个序号的包,通过自适应重传算法(通过采样往返时间RTT不断调整)。在TCP里面超时的采样存在不准确的问题。例如发送一个包,序号100,发现没有返回,于是在发送一个100,过一阵返回ACK101.客户端收到了,但是往返的时间是多少,没法计算。是ACK到达的时候减去第一还是第二。QUIC也有个序列号,是递增的,任何序列号的包只发送一次,下次就要加1,那样就计算可以准确了但是有一个问题,就是怎么知道包100和包101发送的是同样的内容呢?quic定义了一个offset概念。QUIC既然是面向连接的,也就像TCP一样,是一个数据流,发送的数据在这个数据流里面有个偏移量offset,可以通过offset查看数据发送到了那里,这样只有这个offset的包没有来,就要重发。如果来了,按照offset拼接,还是能够拼成一个流。机制三: 无阻塞的多路复用
机制四:自定义流量控制有了自定义的连接和重传机制,就可以解决上面HTTP2.0的多路复用问题
同HTTP2.0一样,同一条 QUIC连接上可以创建多个stream,来发送多个HTTP请求。但是,QUIC是基于UDP的,一个连接上的多个stream之间没有依赖。这样,假如stream2丢了一个UDP包,后面跟着stream3的一个UDP包,虽然stream2的那个包需要重新传,但是stream3的包无需等待,就可以发给用户。
TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update,来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的,不但在一个连接上控制窗口,还在一个连接中的每个steam控制窗口。在TCP协议中,接收端的窗口的起始点是下一个要接收并且ACK的包,即便后来的包都到了,放在缓存里面,窗口也不能右移,因为TCP的ACK机制是基于序列号的累计应答,一旦ACK了一个序列号,就说明前面的都到了,所以是要前面的没到,后面的到了也不能ACK,就会导致后面的到了,也有可能超时重传,浪费带宽QUIC的ACK是基于offset的,每个offset的包来了,进了缓存,就可以应答,应答后就不会重发,中间的空档会等待到来或者重发,而窗口的起始位置为当前收到的最大offset,从这个offset到当前的stream所能容纳的最大缓存,是真正的窗口的大小,显然,那样更加准确。
HTTPS建立连接,需要三次交互(三次握手+SSL三次握手),QUICK把这个过程缩减为了3次。因此,QUICK是一个在UDP之上的伪TCP+TLS+HTTP/2
的多路复用协议。
4. https
https使用了非对称加密技术和对称加密技术。1. 使用非对称加密技术实现共享秘钥的安全传输 2. 对传输数据的加密使用对称加密技术,秘钥就是非对称加密传输的共享秘钥。
4.1. SSL握手步骤
客户端向服务器发送连接请求。服务器收到请求后,生成一个公私钥对;服务器向客户端发送安全证书,包含服务器生成的公钥客户端收到服务器发来的安全证书,对证书进行验证;随机生成一个对称加密秘钥,用服务器发来的公钥对其进行加密;客户端将加密后的对称秘钥发送给服务器,服务器收到后用私钥解密,就得到了客户端随机生成的那个对称秘钥。 此时客户端和服务器都有了对称秘钥,就可以使用该秘钥对数据进行加密传输了。问题一:为什么不直接使用非对称加密,进行加密传输?
使用公钥对数据进行加密要比对称加密的方式复杂,效率会很低。
问题二:安全证书的作用是什么?
保证客户端收到的公钥就是服务器发送的,而不是中途有攻击者截取篡改后的。
4.2. CA证书
数字证书是由CA(Certificate Authority)发行的并且对公开密钥做了签名,它可以保证客户端收到的公钥是合法的,不是伪造的。
CA证书签发过程
服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;CA 通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;如信息审核通过,CA 会向申请者签发认证文件-证书。
证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;
签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA 的私钥对信息摘要进行加密,密文即签名;
CA证书验证
客户端 C 向服务器 S 发出请求时,S 返回证书文件;客户端 C 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;客户端然后验证证书相关的域名信息、有效时间等信息;客户端会内置信任 CA 的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA 的证书,证书也会被判定非法。
在这个过程注意几点:
申请证书不需要提供私钥,确保私钥永远只能服务器掌握;证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书;证书=公钥+申请者与颁发者信息+签名;
如果觉得《计算机网络学习笔记四 http和https》对你有帮助,请点赞、收藏,并留下你的观点哦!