Network-codeing(1)
=======================
get 与 post的关系
get的含义就是获取网络资源
post的含义就是发布新的网络资源
安全、幂等方面,在安全方面,他们都是明文传输不存在安全的问题。然后就是get只是获取服务器的资源,不会对服务器内容进行修改所以说,不存在安全问题。
对于幂等方面,get请求得到的结果都是一样的,但是对于post而言却不是一样的。
=====================
http特征
1.良好的跨平台性。
不足:
1.明文传输。
2.无状态。
=====================
http1.1的特点:
1.长链接 connection:keep-alive
2.管道化传输,pipline
3.队头阻塞。
=====================
HTTP与HTTPS的区别:
1.HTTP是超文本传输协议,信息是明文传输,存在安全风险。对于https而言就不存在这样的问题,https在tcp和http中使用了ssl/tls来进行数据加密。
2.HTTP的建立过程相对来说简单一些,HTTP在进行了tcp/ip协议的三次握手之后建立了链接就可以进行报文传输了。然而HTTPS在TCP三次握手之后还需要进行TLS/SSL的握手才能进行通信。
3.HTTP的端口号是80,HTTPS的端口号为443.
4.HTTPS需要向CA机构申请数字证书,来保证服务器身份的可信度。
由于HTTP是明文传输所以说在传输过程中主要有以下几个问题:
- 窃听风险,通过抓包工具就可以获取到http传输过程中的数据内容。
- 篡改风险,通过抓包工具可以获取到http传输的内容进行修改之后,再发送出去。
- 冒充风险,由于冒充者可以收到发送方的信息,那么冒充者就可以冒充真正的发送方给接收方发送信息。
HTTPS在HTTP和TCP层之间加入了SSL/TLS协议,可以很好的解决这个问题,一下是SSL/TLS的一些特征。
- 信息加密,解决的窃听风险。
- 校验机制,因为https传输中都有校验和,如果被修改了,校验和将无法通过。
- 身份证书,对于冒充风险而言,利用权威机构发布的CA就可以证明该服务器的身份。
HTTPS如何来解决HTTP的三个问题的呢?
- 混合加密,首先是HTTPS使用混合加密的方式来解决窃听风险。
- 摘要算法,摘要算法的方式去实现完整性。他可以使得数据生成独一无二的指纹,指纹用于校验传输数据的完整性,解决了篡改的风险。
- CA中存放服务器公钥,冒充风险,主要来源于密钥传输的可能存在风险,那么我们就可以直接将公钥放置在证书中,让别人无法去篡改公钥,而后实现加密通信。
下面是以上三个问题的详细展开:
- 混合加密:通过混合加密的方式,解决了通信过程中的窃听风险,保证了信息的机密性。HTTPS使用的是对称加密和非堆成加密相结合的混合加密方式。
- 在通讯建立的时候使用非对称加密的方式来沟通密钥。
- 然后再正常沟通的过程中使用对称加密的方式来进行沟通。
- 采用混合加密的方式原因如下:
- 对称加密只需要使用一个密钥,加解密的速度比较快,但是密钥必须要保密,所以在进行密钥交换的时候就很困难。
- 非对称加密使用了公钥和密钥,然后公钥可以任意发放,然而密钥却需要自己保存,解决了对称加密的密钥交换问题。
- 摘要算法:客户端在发送数据之前,就会将自己的数据全部进行一次hash,得出指纹,然后用于校验和,解决了篡改问题。如果在传输过程中数据被修改了那么我们的数据包就不能通过数据校验的过程。
- 数字证书:客户端先向服务端索取共钥,然后使用公钥进行加密传输,服务端收到信息之后使用自己的私钥进行解密。但是这个时候就会存在问题,如果确保这个公钥是服务端发送过来的,中间的篡改者一样可以发送公钥给客户端,然后和客户端建立联系,然后客户端的信息产生巨大的威胁。所以就需要一个值得信任的第三方机构CA(数字证书认证机构),将服务器的公钥封锁到证书中去。只要证书是可信的,那么公钥就是可信的。因此通过数字证书的方式,保证了服务器公钥的身份,解决了冒充者的问题。
=====================
HTTPS是如何建立的,其间经历了什么?
SSL/TLS协议的基本流程为:客户端向服务端索取公钥,然后双方协商会话密钥,然后利用该会话密钥,进行加密通信。一共三步,前两步是SSL/TLS的建立过程,也就是握手阶段。握手阶段进行了四次通信。具体流程如下所示。
1.ClientHello
首先客户端向服务端发起加密通信请求。这一步中主要包含了以下信息。(1)客户端支持的SSL/TLS协议版本版本。(2)客户端生产的随机数(Client Random),后面用于生产「会话秘钥」。(3)客户端支持的加密算法,如RSA加密算法。
2.ServerHello
服务端接受到客户端发送的请求之后,返回给客户端一个回应,主要包含内容为:(1)确认SSL/TLS版本。(2)服务端生成的随机数,以后可以用于生成会话密钥。(3)客户端支持的加密算法,比如说RSA算法。(4)服务器的数字证书。
3.客户端响应
客户端收到服务器的相应之后,首先通过浏览器或者操作系统中的CA公钥,确认服务器的数字公钥的正确性。如果服务器的公钥没有问题,那么我们就会利用该公钥,对发送的内容进行加密。加密的内容主要包含了一下三个方面:(1)客户端随机数,用于会话密钥的生成。(2)服务器握手结束通知,表示服务器的握手阶段已经结束,之后的通信都用会话密钥进行通信。(3)这一项将之前所有的通信内容做一个摘要供服务端校验。
4服务端响应
(1)加密方式改变通知,(2)服务端握手结束通知,并将之前的通信做一次摘要。
至此,整个 SSL/TLS 的握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的 HTTP 协议,只不过用「会话秘钥」加密内容。
=====================
HTTP/1.1、HTTP/2、HTTP/3 演变
首先谈及的是HTTP1.1相对于HTTP1.0提升了什么。
主要(1)HTTP1.1引入了长链接,这样的发送多个HTTP请求就不需要进行多次建立连接了,使用connection:keep-alive来进行控制。(2)就是管道化网络传输(pipline),在没有接受到客户端第一个请求回应的时候,就可以发送第二个网络请求。
HTTP1.1的问题:(1)头部阻塞:在http1.1的管道化传输中,虽然可以同时发送多个请求,但是只有收到第一个请求之后才能接受之后的请求,所以说如果第一个(对头)发生了阻塞,那么我们之后所有的请求都会被阻塞。(2)头部冗长重复:每次发送http都要发送一个冗长的请求,但是绝大部分重复的部分居多。(3)在该过程中,客户端永远都是发起方,服务端永远都是被动方。
HTTP2.0相对于HTTP1.1的性能提升之处:
- 头部压缩,HTTP/2会压缩头部,对于HTTP1.1中的大量重复冗余的头部而言,可以消除重复的部分。
- 二进制格式,不再像HTTP1.1中那种纯文本格式的报文,而是全面采用了二进制格式,头信息和数据体都是二进制,紧切统称为帧:头信息帧和数据帧。二进制帧的形式,计算机在收到报文之后,不需要转化为二进制,而是直接将该报文解析,这增加了数据传输的效率。
- 数据流(多路复用):HTTP/2 中的数据包不是按照顺序发送的,同一个链接中可能包含了多个不同的回应。因此,必须要对数据包做标记,指出它属于哪个回应。能够让各个请求都能独立。
- 服务端推送:HTTP/2还在一定程度上改善了传统的请求-应答机制,服务不再是被动的等待响应,也可以主动给客户端发送消息。
HTTP3相对于HTTP2的提升?
HTTP/2 主要的问题在于,多个HTTP请求在复用一个TCP连接,下层的TCP协议是不转掉有多少个HTTP请求的。所以一旦发送丢包的情况,就会触发TCP的重传机制,这样在一个TCP连接中的所有的HTTP请求都必须要去等待这个丢了的包被重传回来。
- HTTP/1.1中的管道(pipline)传输中如果有一个请求阻塞了,那么队列后请求也统统会被阻塞住。
- HTTP/2多个请求服用一个TCP链接,一旦发生了丢包,就会阻塞住所有的HTTP请求。
这些其实都是在TCP传输层出了问题,所以HTTP3的时候就把HTTP下层的TCP更换为了UDP!UDP实现了一个不可靠传输,但是基于 UDP 的 QUIC 协议可以实现类似于 TCP 的可靠传输。
- QUIC 有自己的一套机制可以保证传输的可靠性。当某一个流发生丢包的时候,只会阻塞这个流,不会影响到其他的流。
- TLS3 升级到最新的1.3版本,头部压缩变为QPack。
- HTTPS要建立连接的话,要花费6次交互,先是要建立三次握手,然后是TLS的三次握手。QUIC直接把之前的TCP和TLS/1.3的三次握手合并为了3次,减少了交互的次数。所以说QUIC是一个新的协议,它是一个伪TCP+TLS+HTTP/2的多路复用的协议。
websocket:
websocket解决了一个HTTP的致命问题:请求只能由客户端发起的问题,即使HTTP2中新增了服务端推送,但是依然是在客户端发起请求之后才新增的。HTTP协议依然不能向客户端发起推送信息。这种单向推送造成了不少的问题,就是如果说,服务器又连续的状态变化,客户端获知就非常麻烦,只能通过轮询的方法来获取。
其特点为:
(1)建立在TCP之上,服务器的实现比较简单。
(2)与HTTP协议有着良好的兼容性。默认端口为80和443,并且握手阶段采用和HTTP一样的方式。
(3)数据格式比较轻巧
(4)可以发送文本,也可以放松二进制数据
(5)没有同源策略限制。
(6)标识符号为ws和wss