计算机网络(3)--应用层协议--HTTP与HTTPS

一、HTTP

HTTP协议(超文本传输协议HyperText Transfer Protocol),它是基于TCP/IP协议的应用层传输协议,简单来说就是客户端和服务端进行数据传输的一种规则。HTTP本身是一种无状态的协议,也就是说下一次请求时不记得上一次请求发送了什么的,但是如果在多个页面中需要记住用户的登录状态,那么该怎么办?于是乎引入了Cookie技术,利用Cookie来记录管理

1.1 URL与URI?

  • URI:uniform resource identifier,统一资源定位符,可以用来标识唯一的一个资源
  • URL:uniform resource locator,统一资源定位器,是一种具体的URI,使用URL可以标明一个资源,而且还指明了如何指向locate这个资源

URI相当于身份证ID,使用身份证ID可以标识一个人,而URL则更加细化,是URI的子集,形象的说可以使身份证上的地址,无论是身份证ID或者是一个人的家庭住址,都可以唯一的标识这个人,而URL更注重的是locator是如何找到这个人,找到这个资源,而在网络上更多使用的是URL

1.2 HTTP请求报文

HTTP请求报文由四部分组成:请求行、请求头、请求空行、请求正文。

请求行

请求行由三部分组成:请求方法,请求路径,请求版本,一般的格式如下:

GET / HTTP/1.1

请求方法有以下几种:

  • GET: 请求获取Request-URI所标识的资源
  • POST: 在Request-URI所标识的资源后增加新的数据
  • HEAD: 请求获取由Request-URI所标识的资源的响应消息报头
  • PUT: 请求服务器存储或修改一个资源,并用Request-URI作为其标识
  • DELETE: 请求服务器删除Request-URI所标识的资源
  • TRACE: 请求服务器回送收到的请求信息,主要用于测试或诊断
  • CONNECT: 保留将来使用
  • OPTIONS: 请求查询服务器的性能,或者查询与资源相关的选项和需求

GET与POST方式的区别:

  • GET方式携带的参数在url后面使用key=val形式以及&拼接,而POST方法携带的数据在请求体里面
  • GET方式请求的url是有空间大小的,而POST没有
  • 使用GET方式因为参数都携带在请求url里面,所以相对不安全
  • 本质上说,两者都是使用TCP协议

请求头

请求头由一系列的键值对组成,允许客户端向服务器端发送一些附加信息或者客户端自身的信息

常见请求头:

  • User-Agent:浏览器告诉服务器,浏览器的版本信息

    可以在服务器端获取该头的信息,解决浏览器的兼容性问题

  • Referer:告诉服务器,当前请求从哪里来

    作用:防盗链和统计工作

请求空行

用来分割POST请求的请求头和请求体的

请求体

只有在发送POST请求时才有请求体

1.3 HTTP响应报文

HTTP响应报文与HTTP请求报文格式大致一样,也是有四部分:响应行、响应头、响应报文、响应体

响应行

响应行由三部分组成:HTTP协议的版本号、状态码、以及对应状态码的描述

HTTP/1.1 200 OK (CRLF)

状态码:

  • 1xx:服务器就收客户端消息,但没有接受完成,等待一段时间后,发送1xx多状态码(少见)

  • 2xx:成功。代表:200

  • 3xx:重定向。代表:302(重定向),304(访问缓存)

  • 4xx:客户端错误。代表:404(请求路径没有对应的资源) 405:请求方式没有对应的doXxx方法

  • 5xx:服务器端错误。代表:500(服务器内部出现异常)

响应头

头名称: 值

常见的响应头

  • Content-Type:服务器告诉客户端本次响应体数据格式以及编码格式

  • Content-disposition:服务器告诉客户端以什么格式打开响应体数据

    值:1. in-line:默认值,在当前页面内打开

    ​ 2.attachment;filename=xxx:以附件形式打开响应体。文件下载

1.4 长连接?短连接?

在HTTP1.0中默认使用的就是短连接,也就是说客户端和服务端每进行一次HTTP操作,就建立一次连接,任务结束就中断链接,当客户端浏览器访问某个HTML或其他类型的web页中含有其他的web资源的时候,每次遇到这个资源就需要重新建立一个链接

从HTTP1.1开始,默认使用长连接,用以保持连接特性,使用长连接的HTTP协议,会在响应头加入这行请求头

Connection:keep-alive

在使用长链接的情况下,当一个网页打开完成后,客户端与服务器端的连接将不会立马断开,客户端再次访问这个服务器时会继续使用这条已经建立的连接,当然keep-alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件上进行设置这个时间

往下抽象的话,长短连接的实现实际上是TCP的长短连接的实现,当使用TCP协议的时候,在进行读写操作之前需要先建立连接,当读写操作完成之后双方不需要这个链接了就可以进行释放连接,使用三次握手建立连接,四次挥手释放连接,每一次的连接的建立和释放都是需要消耗一些资源的

长短连接的优点和缺点:

  • 使用长连接可以省去比较多的TCP建立和连接的操作,减少浪费节约时间,适合于频繁请求资源的场景
  • 短连接对于服务器来说管理比较简单,存在的连接都是有用的连接,不需要额外的控制手段,适用于请求资源部频繁的情况

1.5 HTTP保存用户状态?

因为HTTP是无状态的,每次连接都与上一次连接无关,而要解决在多个网页下同一用户的识别可以有以下两种方案:

  • 利用Cookie,基于Cookie的保存是在客户端的,只需要每次发送HTTP请求的时候带上Cookie即可保存用户的状态、
  • 利用Session,基于Session的保存是在服务器端的,在会话开始的时候,服务器会将会话保存起来,然后分配一个会话标识给客户端,一般这个会话标识是保存在Cookie的,每次浏览器发请求都会带上Cookie中的Sessionid到服务器,服务器通过会话标识就可以把之前保存在服务器中的用户状态读取出来,从而实现了会话保存,一个典型的应用场景是购物车,当用户需要添加商品到购物车的时候,由于服务器无法识别是哪一个用户,但是如果有了Sessionid之后就可以识别这个用户。

基于Session的方案的优点是安全性比较高,但是也带来了服务器的压力,在分布式微服务的架构下,请求需要通过Nginx(负载均衡器)才能到达服务器,但是多次请求到达的不是同一个服务器,要解决同一个SessionId的问题,可以将Session保存在缓存中间件入Redis里面,同样也可以放在数据库里面,但是通过数据库的效率就更低了

如果客户端禁用了Cookie了怎么办?可以将SessionId放在请求url里面

1.6 Cookie? Session?

上面其实也已经说到了一些Cookie和Session的作用与不同,下面再次进行加深与理解:

  • Cookie一般用于保存用户的信息,例如我们已经在csdn上登录成功了,而下次访问页面的时候Cookie可以帮助用户自动的填写一些登录的信息
  • Session的主要作用就是通过服务器记录用户的状态,最典型的例子就是上面购物车的例子

Cookie存储在客户端中,而Session存在服务器端,相对来说Session更加安全,如果有一些敏感信息,可以使用非对称加密在客户端进行加密,然后到服务器端进行解密

1.7 HTTP1.0? HTTP1.1?

HTTP1.0最早使用是在1996年,而HTTP1.1则是在1999年才开始广泛应用于浏览器网页吗,可见HTTP1.1通过如此多年的考验,已经相当成熟,在前面介绍长连接和短连接的时候其实已经说到过HTTP1.0和HTTP1.1的一些区别,下面在具体的聊一聊:

  • 缓存处理:在HTTP1.0的时候主要使用请求头中的If-Modified-Since来作为缓存判断的标准,而HTTP1.1引入了更多的缓存控制策略
  • 带宽优化和网络连接的使用: 在HTTP1.0中存在部分带宽浪费的现象,并且不支持断点续传的功能,HTTP1.1在请求头里添加了range头域,运行只请求资源的一部分,且返回码为206
  • 错误通知处理:在HTTP1.1中新增了24个错误状态响应码
  • Host头处理:在HTTP1.0中认为每台服务器都只能绑定一个IP地址,所以在请求URL中并没有带上Host请求头,但是随着虚拟技术的发展,一台计算机可以拥有多个虚拟主机绑定多个ip地址,所以在HTTP1.1请求头(响应头)上就需要带上一个Host信息,如果没有则报出一个400错误
  • 长链接:HTTP1.0默认使用的是短连接,而HTTP1.1默认使用的是长链接

二、HTTPS

HTTP具有以下缺点:

  • 通信使用的是明文,可以使用抓包工具抓取其中内容,导致内容被窃听
  • 不能验证通信对方的身份,可能会遭到伪装
  • 无法验证报文的完整性

为了解决上面几个问题,出现了安全的HTTPS协议,HTTPS协议其实就是身披SSL外壳的HTTP协议,也就是说客户端与服务端进行通信的时候先经过SSL进行加密,拥有了SSL的保护功能HTTP就变为了HTTPS,可以解决通信明文,能验证身份,保证完整性

2.1 对称加密与非对称加密

在说HTTPS之前,先来了解一下密码学中的对称加密和非对称加密

  • 对称加密:加密和解密都会使用到用一把密钥,没有
  • 密钥就无法进行解密,也就是说只要拿到了密钥,就能对进行解密
  • 非对称加密:加密和解密使用不同的密钥,发送方使用公钥进行加密,而接收方使用密钥进行加密

在使用对称加密时,如果攻击者拿到了密钥,那么加密就失去了意义,要让密钥让接收方和发送方都拿到也需要进行传输,那理论上传输数据时不安全的那么传输密钥也是不安全的,所以只使用对称加密也是不可靠的;

非对称加密需要使用公钥进行加密,私钥进行解密,这是很耗费资源的,处理速度也很慢;

所以在HTTPS的SSL中采取了一种折中的办法,在初次建立连接的时候使用非对称加密将双方共同的密钥进行传输,而下一次就可以使用对称加密进行传输了,这样既保证了安全性也保证了效率

2.2 证书

使用非对称加密和对称加密混合的方式解决了通信使用的是明文的方式,但是可惜的是没有解决验证通信双方的身份,为了解决上面这个问题,可以采取数字认证机构和其他相关机构颁发的公开密钥证书,数字证书认证机构处于客户端和服务器daunt都信赖的第三方机构

首先是有服务器的运营人员向权威数字认证机构提出申请证书,服务器拿到证书后将公开密钥放入到证书中,然后服务器将这份证书发送给客户端,客户端开始对证书进行确定,一旦验证通过即可验证服务器的身份,一般浏览器的做法是现在内部植入常用认证机关的公开密钥

2.3 HTTP? HTTPS

总结一下HTTP和HTTPS之间的区别:

  • 端口:HTTP默认使用80端口,而HTTPS默认使用443端口
  • 安全性和资源消耗:HTTP建立在TCP之上,所有的传输都是明文传输,也无法验证双方的身份,HTTPS是建立在SSL/TLS之上的HTTP协议,所有的传输内容都是经过加密,加密方式采取的是对称加密与非对称加密混合的方式,HTTPS的安全性比HTTP高但是资源消耗也更多,所以一般需要很强安全性的服务才使用HTTPS,否则还是使用HTTP

猜你喜欢

转载自blog.csdn.net/weixin_44706647/article/details/115257576