HTTP与HTTPS

1、HTTP

HTTP是一个超文本传输协议,是一个基于请求与响应,无状态的,应用层的协议,基于TCP/IP协议传输数据。
特点:

  • 无状态:协议对客户端没有状态存储,不具有记忆能力,如访问一个网站需要进行重复登录;
  • 无连接:HTTP/1.1之前,由于无状态的原因,客户端每次建立连接都需要使用TCP进行三次握手,如果一个客户端在短时间内多次请求服务端,服务端每次都需要重新响应,造成不必要的时间浪费;
  • 基于请求和响应:有客户端发起请求,服务端响应;
  • 简单快速;
  • 通信使用明文,请求和响应不会对通信方进行确认,无法保证数据的完整性。

HTTP针对无状态的解决方案:

  • 使用Cookies/Session技术;
  • HTTP/1.1持久连接(HTTP keep-alive)方法,只要任意一方没有提出断开连接,TCP保持连接状态,在请求首部字段中的Connection: keep-alive即为表明使用了持久连接。
2、HTTPS

HTTPS在HTTP的基础上加入了TLS/SSL加密,验证对方身份和数据的完整性。

①、特点:

  • 采用混合加密,结合非对称加密和对称加密技术,中间者无法直接查看明文内容;
  • 验证身份:通过证书验证客户端访问的是自己的服务器;
  • 保护数据的完整性:防止传输的内容被中间人冒充或篡改。

②、对称加密与非对称加密

  • 对称加密:加密和解密使用同一把密钥;
  • 非对称加密:加密和解密使用不同的密钥,即公钥和私密

③、关于HTTPS的混合加密个人理解:
客户端生成一对私钥,使用私钥将待发送的内容加密,服务端通过某些算法生成一对公钥和私密,将公钥发送给客户端,客户端再利用服务端发来的公钥将自己生成的私钥加密,然后客户端将使用私钥加密的内容和使用公钥加密的私钥一并发送给服务端。

④、HTTPS建立连接的过程
在这里插入图片描述

  • 1、客户端访问https连接:这一步,就是相当于我们在浏览器上输入url回车的过程。这个时候浏览器或者客户端(接下来统一为客户端)会把我们客户端支持的加密算法Cipher Suite(密钥算法套件)带给服务端。
  • 2、服务端发送证书(公钥)给客户端: 服务端接收Cipher后,和自己支持的加密算法进行比对,如果不符合,则断开连接。否则,服务端会把符合的算法和证书发给客户端,包括证书时间、证书日期、证书颁发的机构。
  • 3、客户端验证服务端的证书:
    • 1、客户端验证证书,包括颁发证书的机构是否合法与是否过期,证书中包含的网站地址是否与正在访问的地址一致等

    • 2、验证通过后(或者用户接受了不信任的证书),客户端会生成一个随机字符串,然后用服务端的公钥进行加密。这里就保证了只有服务端才能看到这串随机字符串(因为服务端拥有公钥对应的私钥,RSA解密,可以知道客户端的随机字符串)。

    • 3、生成握手信息 用约定好的HASH算法,对握手信息进行取HASH,然后用随机字符串加密握手信息和握手信息的签名HASH值,把结果发给服务端。这里之所以要带上握手信息的HASH是因为,防止信息被篡改。如果信息被篡改,那么服务端接收到信息进行HASH时,就会发现HASH值和客户端传回来的不一样。这里就保证了信息不会被篡改。

  • 4、服务端接收加密信息,解密得到客户端提供的随机字符串:服务端接收到加密信息后,首先用私钥解密得到随机字符串。然后用随机字符串解密握手信息,获得握手信息和握手信息的HASH值,服务端对握手信息进行HASH,比对客户端传回来的HASH。如果相同,则说明信息没有被篡改。服务端验证完客户端的信息以后,同样使用随机字符串加密握手信息和握手信息的HASH值发给客户端。
  • 5、客户端验证服务端返回的握手信息,完成握手:客户端接收到服务端发回来的握手信息后,用一开始生成的随机字符串对密文进行解密,得到握手信息和握手信息的HASH值,像上一步服务端验证一样对握手信息进行校验,校验通过后,握手完毕。从这里开始,客户端和服务端的通信就使用那串随机字符串进行AES对称加密通信。

如何保证服务端的证书是正确的没被修改的?
证书包含的信息有:公钥、url、证书的颁发机构、证书的持有者、证书的有效期、哈希加密算法、加密证书得到的哈希值等。

在证书颁发之前,CA机构会对证书进行HASH得到一个哈希值,因为哈希值具有不可逆性,因此通过哈希值无法推出被哈希的内容,而且CA机构有一套自己的公钥和私钥,然后CA机构会使用自己的私钥对刚才得到的哈希值和哈希算法进行加密,加密后的内容也即是数字签名。

浏览器验证证书
首先从证书中会得知证书的颁发机构,然后从浏览器中寻找证书颁发机构的根证书,因为世界上权威CA机构的根证书都是预先嵌入到浏览器中的,如果找不到对应的根证书说明此机构不被信任,会发出HTTPS警告,无法验证证书真假。如果可以得到根证书,进而可以得到对应的CA机构的根公钥,从而可以解密得到证书被CA机构加密的哈希值和哈希算法,然后客户端再次对证书哈希得到另一个哈希值,对比两个哈希值是否相等即可,如果相等,对比url是否是自己的目标连接,如果是则验证成功。

参考文章:
https建立连接过程
HTTP和HTTPS协议,看一篇就够了
HTTPS的数字证书验证原理

3、get与post请求的区别

HTTP是应用层的协议,而TCP/IP是传输层的协议。
get与post请求主要有以下几点区别:

  • get在浏览器回退是无害的,而post请求回退会再次提交;
  • get请求可以加入收藏夹(Bookmark),而post请求不行;
  • get请求会被浏览器主动cache,而post则不会,除非手动设置;
  • get请求只能进行url编码,而post支持多种编码方式;
  • get请求的参数会被完整的保存在历史记录里,但是post的参数则不会被保留;
  • get请求在url中传输的长度是有限制的,但是post请求则没有;
  • 对参数的数据类型,get请求只支持ASCII字符,而post请求没有限制;
  • get请求相对不安全,因为参数直接暴露在url上;
  • get参数通过url传递,而post则放在Request Body中。

get请求只发送一个数据包,而post请求会发送两个数据包。对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。

参考文章:
Get与Post的区别?

4、cookie与session的区别

①、cookie是服务端识别客户的唯一标识的依据,客户在访问网站时候,服务端为了记住这个客户,会在服务端按照它的规则制作一个cookie数据,会将这个cookie数据保留在服务端一段时间,同时会给客户一份让它自己保留,这样就无需每次都要登录来认证自己了。 
②、会话,指用户登录网站后的一系列动作,比如浏览商品添加到购物车并购买。会话(Session)跟踪是Web程序中常用的技术,用来跟踪用户的整个会话。
Cookie通过在客户端记录信息确定用户身份,Session通过在服务器端记录信息确定

4.1、cookie
Cookie实际上是一小段的文本信息。当客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。Cookie具有不可跨域名性

4.2、session
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。事实上,用户与服务器建立连接的同时,服务器会自动为其分配一个SessionId。

当一个用户提交了表单时,浏览器会将用户的SessionId自动附加在HTTP头信息中,(这是浏览器的自动功能,用户不会察觉到),当服务器处理完这个表单后,将结果返回给SessionId所对应的用户。试想,如果没有 SessionId,当有两个用户同时进行注册时,服务器怎样才能知道到底是哪个用户提交了哪个表单呢。服务器通过SessionId作为key,读写到对应的value,这就达到了保持会话信息的目的。

当程序需要为某个客户端的请求创建一个session时,服务器首先检查这个客户端的请求里是否已包含了sessionId,如果已包含则说明以前已经为此客户端创建过session,服务器就按照sessionId把这个session检索出来使用(检索不到,会新建一个),如果客户端请求不包含sessionId,则为此客户端创建一个session并且生成一个与此session相关联的sessionId,sessionId的值是一个既不会重复,又不容易被找到规律以仿造的字符串,这个sessionId将被在本次响应中返回给客户端保存。

参考文章:
浅谈Session与Cookie的关系

5、TCP与UDP

在这里插入图片描述
①、UDP

  • UDP是面向无连接的
    也就是说UDP不需要向TCP那样建立三次握手连接之后在发送数据,UDP可以说是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。
  • UDP有单播、双播和广播方式
    UDP不仅支持一对一的形式,还支持一对多、多对多,多对一的方式。
  • UDP是面向报文的
    UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界。
  • UDP传输不可靠
    首先不可靠性体现在无连接上,通信都不需要建立连接,想发就发,这样的情况肯定不可靠。并且收到什么数据就传递什么数据,并且也不会备份数据,发送数据也不会关心对方是否已经正确接收到数据了。也就是说UDP只会把想发的数据报文一股脑的丢给对方,并不在意数据有无安全完整到达。

②、TCP

  • TCP是面向连接的
    在发送数据前会通过三次握手建立连接,之后才会发送数据 。
  • TCP只能进行单播传输
    也就是说TCP只支持点到点传输。
  • TCP是面向字节流的
    TCP在不保留报文边界的情况下以字节流方式进行传输。
  • TCP的传输是可靠的
    对于可靠传输,判断丢包,误码靠的是TCP的段编号以及确认号。TCP为了保证报文传输的可靠,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据(假设丢失了)将会被重传。
  • TCP提供拥塞控制
    当网络出现拥塞的时候,TCP能够减小向网络注入数据的速率和数量,缓解拥塞

③、TCP三次握手的原因
TCP的连接因为是全双工的,也就是Client和Server两端,发送消息两个方向的连接都要建立成功。如果要保证双向连接都成功的话,三次通信是最少的次数了。大于三次的话,后面的次数通信就没有必要了,是在浪费资源。

二次的话,会怎么样,可不可以呢?答案是不可以,我们来看下,下面的场景。

在谈论这个之前,我们先要知道TCP是基于IP协议的,而IP协议是有路由的,IP协议不能够保证先发送的数据先到达,这当中依赖于IP协议底层的网络质量,以及Client与Server之间的路由跳数。

Client在发送完Syn消息1,这里称作Syn1之后,假设因为网络原因,Syn1并没有到达Server端,这个时候Client端已经超时,Client之后重新发起SYN消息,这里称作Syn2。结果由于网络原因Syn2先到答Server,Server于是与Client基于Syn2建立了连接,结果没过多久Syn1又到达了Server,Server于是关掉了Syn2建立的那条连接,又重新建立了一条连接。对于Client来说新建立的这条连接是早就过时的,所以Client不会在这条连接上发送任何数据,这就导致了Server端长时间收不到数据,Client新的连接被断掉了。

④、TCP第4次挥手为何要等待2MSL才关闭?
在这里插入图片描述

假如第四次挥手失败了,因为丢失而未到达服务器会怎样呢?这样,服务器会一直收不到客户端的回应,也就无法得知客户端是否收到了即将要断开连接的请求。客户端此刻还蒙在鼓里,还在等待服务器继续发送消息。服务器不能判断客户端是否收到,本身就是一个BUG,于是才有的等待2MSL的情况。为了保证客户端最后一次挥手的报文能够到达服务器,若第4次挥手的报文段丢失了,服务器就会超时重传第3次挥手的报文段,所以客户端此时不是直接进入CLOSED,而是保持TIME_WAIT(等待2MSL就是TIME_WAIT)。当客户端再次受到服务器因为超时重传而发送的第3次挥手的请求时,客户端就会重新给服务器发送第4次挥手的报文(保证服务器能够受到客户端的回应报文)。最后,客户端、服务器才真正断开连接。说白了,等待2MSL就是为了确保服务器能够受到客户端最后的回应。

如果客户端直接CLOSED,然后又再次向服务器发起一个新连接,谁也不能保证新发起的连接和刚关闭的连接的端口号是不同的,有可能新、老连接的端口号就是一样的。假设新、老连接端口号一致,若老连接的一些数据仍滞留在网络中,这些滞留数据在新连接建立后才到达服务器,鉴于前后端口号一致,TCP协议就默认这些数据属于新连接,于是数据就这样乱成一锅粥了。所以TCP连接还要在TIME_WAIT状态下等待2MSL,确保所有老连接的数据都在网络中消失!

6、输入URL回车后发生了什么
  • ①、首先进行DNS解析,一次获取这个域名对应的IP地址,DNS解析过程大致如下:

    • 首先查询浏览器缓存;
    • 如果浏览器缓存没有就查询本地缓存,也就是C盘里的hosts文件;
    • 如果前两步都没有查到,则查询路由器缓存;
    • 如果以上步骤还找不到,则ISP的DNS服务器就会进行递归查询;
    • 然后进行迭代查询
      关于DNS解析参考文章:在浏览器地址栏输入URL,按下回车后究竟发生了什么?
  • ②、浏览器与目标服务器建立TCP连接,形成客户端到服务器的稳定通道,也就是TCP三次握手。

  • ③、HTTP是建立在TCP之上的,TCP完成连接后HTTP请求开始,可以进行多种请求如POST、GET。

  • ④、HTTP请求中包含请求头和请求体,请求头中包含我们希望对请求对文件的操作信息,请求体中包含传递到后台的参数。

  • ⑤、服务端接收到请求之后服务端后台开始工作,处理完相应的数据之后,将返回结果生成响应数据包,响应包含两部分即响应头和响应体,响应体中包含了响应数据。

  • ⑥、客户端加载相应数据,解析并渲染HTML界面。

  • ⑦、TCP四次挥手断开连接。

推荐阅读:
面试题之计算机网络

7、POST请求的编码方式
  • ①、application/x-www-form-urlencoded,也即是url编码,一般表单提交默认使用此种方式
  • ②、multipart/form-data,一般用于上传表单文件时使用此种方式
  • ③、application/json,传到后台是一个json串,而第一种传到后台是key-value的形式
  • ④、text/xml,参数为String类型的数据
8、为什么有了IP协议还要TCP

TCP/IP四层模型
在这里插入图片描述
负责传输的IP协议
IP协议位于网络层,几乎所有的网络都会使用IP协议,IP协议的目的就是把各种数据包传递给对方。而要保证确实传送到对方那里,则需要满足各类条件。其中两个重要的条件是IP地址和MAC地址(Media Access Control Address)。IP地址指明了节点被分配到的地址,MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对。IP地址可变换,但MAC地址基本上不会更改。

确保可靠性的TCP协议
按层次分,TCP位于传输层,提供可靠的字节流服务。所谓的字节流服务(Byte Stream Service)是指,为了方便传输,将大块数据分割成以报文段(segment)为单位的数据包进行管理。而可靠的传输服务是指,能够把数据准确可靠地传给对方。一言以蔽之,TCP协议为了更容易传送大数据才把数据分割,而且TCP协议能够确认数据最终是否送达到对方。

推荐阅读:最详细的http协议、tcp/ip协议

9、TCP粘包与拆包

加入客户端发送D1、D2两个数据包给服务端,如果服务端

  • 分别收到了D1、D2两个数据包,则没有发生粘包与拆包;
  • 一次性收到了D1与D2,成为TCP粘包
  • 服务端两次读取到了两个数据包,第一次读到了D1的完整部分和D2的部分数据,第二次读到了D2的剩余部分。 这称为TCP拆包
  • 服务端两次读取到两个数据包,第一次是D1的部分,第二次是D1的剩余部分和D2的完整部分

也有可能D1和D2非常大,期间发生多次拆包

粘包与拆包的原因

  • 发送的数据报大于缓冲区大小
  • 进行最大报文段长度(MSS)的分段
  • 以太网帧的payload大于MTU进行IP分片

解决方案

  • 消息定长,不够补空格
  • 在数据包的尾部增加回车换行符进行分割
  • 将消息分为消息头和消息体,消息头中包含消息的长度,字段等信息
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值