0%

HTTP、HTTPS、HTTP2.0

HTTP、HTTPS、HTTP2.0

本篇博客将介绍 HTTP 的相关概念。

一、基本概念

1、HTTP

HTTPHyperText Transfer Protocol:超文本传输协议)是从 WWW 服务器传输超文本到本地浏览器的传输协议,设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。

HTTP 默认工作在 TCPTransmission Control Protocol,面向连接的协议) 80 端口,用户访问网站 http:// 打头的都是标准 HTTP 服务。

2、HTTP 1.0

HTTP 协议老的标准是 HTTP/1.0。为了提高系统的效率,HTTP 1.0 规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个 TCP 连接,服务器完成请求处理后立即断开 TCP 连接,服务器不跟踪每个客户,也不记录过去的请求。

但是这样会造成一些性能上的缺陷,客户端和服务器端每次建立和关闭连接都是一个相对比较费时的过程,并且会严重影响客户端和服务器的性能

3、HTTP 1.1

为了解决 HTTP 1.0 的缺陷,HTTP 1.1 支持持久连接 Keep-Alive(持久连接、连接重用):一定时间内,在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟。这里面所说的一定时间是可以配置的,不管你用的是 Apache 还是 nginx。

什么是 HTTP 管线化?

管线化是建立在持久连接之上的,所以仅在 HTTP 1.1 才支持管线化。

并且只有 GET 和 HEAD 请求可以进行管线化,而 POST 则有所限制。

HTTP 管线化是将多个 HTTP 要求(request)整批提交的技术,而在传送过程中不需先等待服务端的回应。

但服务端必须按照接收到客户端请求的先后顺序依次回送响应结果,也就是说客户端还是要按照发送请求的顺序来接收响应,这样可以保证客户端能够区分出每次请求的响应内容。

什么是线头阻塞?

服务器是要按照顺序处理请求的,如果前一个请求非常耗时,那么后续请求都会受到影响,这就是所谓的线头阻塞(Head of line blocking)。

4、常见的请求方式

HTTP 1.0 定义了三种请求方法: GETPOSTHEAD 方法。

HTTP1.1 新增了六种请求方法:OPTIONSPUTPATCHDELETETRACECONNECT 方法。

序号方法描述
1GET请求指定的页面信息,并返回实体主体。
2HEAD类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头
3POST向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4PUT从客户端向服务器传送的数据取代指定的文档的内容。
5DELETE请求服务器删除指定的页面。
6CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7OPTIONS允许客户端查看服务器的性能。
8TRACE回显服务器收到的请求,主要用于测试或诊断。
9PATCH是对 PUT 方法的补充,用来对已知资源进行局部更新 。

摘自《菜鸟教程》

5、HTTP 的状态码

下面是 HTTP 响应报文中的状态码:

2XX 成功

  • 200 OK,表示从客户端发来的请求在服务器端被正确处理 👏
  • 201 Created 请求已经被实现,而且有一个新的资源已经依据请求的需要而建立 👏
  • 202 Accepted 请求已接受,但是还没执行,不保证完成请求
  • 204 No content,表示请求成功,但响应报文不含实体的主体部分 👏
  • 206 Partial Content,进行范围请求

3XX 重定向

  • 301 moved permanently,永久性重定向,表示资源已被分配了新的 URL
  • 302 found,临时性重定向,表示资源临时被分配了新的 URL 👏
  • 303 see other,表示资源存在着另一个 URL,应使用 GET 方法丁香获取资源
  • 304 not modified,表示服务器允许访问资源,但因发生请求未满足条件的情况
  • 307 temporary redirect,临时重定向,和 302 含义相同

4XX 客户端错误

  • 400 bad request,请求报文存在语法错误 👏
  • 401 unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息 👏
  • 403 forbidden,表示对请求资源的访问被服务器拒绝 👏
  • 404 not found,表示在服务器上没有找到请求的资源 👏
  • 408 Request timeout,客户端请求超时
  • 409 Confict, 请求的资源可能引起冲突

5XX 服务器错误

  • 500 internal sever error,表示服务器端在执行请求时发生了错误 👏
  • 501 Not Implemented 请求超出服务器能力范围,例如服务器不支持当前请求所需要的某个功能,或者请求是服务器不支持的某个方法
  • 503 service unavailable,表明服务器暂时处于超负载或正在停机维护,无法处理请求 👏
  • 505 http version not supported 服务器不支持,或者拒绝支持在请求中使用的 HTTP 版本

6、无状态

前面说到,HTTP1.0 中,每个请求/应答客户和服务器都要新建一个连接,完成之后立即断开连接,所以说 HTTP 协议为无连接的协议,也称作无状态。其实这样可以大大减少服务器的资源消耗。但是很多网站是提供用户登录功能的,如果是无状态的话,用户登录一次,第二次访问又需要输入信息重新登录,这显然是很麻烦的,为了保持状态,就有了 Cookie 这项技术。

这项技术需要在首部字段加上 Cookie 信息,这样就能够实现保持登录状态了。

7、为什么有了 HTTP 为什么还要 HTTPS ?

HTTP 协议以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息,因此,HTTP 协议不适合传输一些敏感信息,比如:信用卡号、密码等支付信息。

HTTPSHypertext Transfer Protocol Secure:超文本传输安全协议)是一种透过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信,但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性。

HTTPS 默认工作在 TCP 协议 443 端口,它的工作流程一般如以下方式:

  • TCP 三次同步握手

  • 客户端验证服务器数字证书

  • DH 算法协商对称加密算法的密钥、hash 算法的密钥

  • SSL 安全加密隧道协商完成

  • 网页以加密的方式传输,用协商的对称加密算法和密钥加密,保证数据机密性;用协商的 hash 算法进行数据完整性保护,保证数据不被篡改。

8、HTTP 与 HTTPS 区别

  • HTTP 明文传输,数据都是未加密的,安全性较差,HTTPSSSL+HTTP)数据传输过程是加密的,安全性较好。

  • 使用 HTTPS 协议需要到 CACertificate Authority,数字证书认证机构) 申请证书,一般免费证书较少,因而需要一定费用。

  • HTTP 页面响应速度比 HTTPS 快,主要是因为 HTTP 使用 TCP 三次握手建立连接,客户端和服务器需要交换 3 个包;而 HTTPS 除了 TCP 的三个包,还要加上 ssl 握手需要的 9 个包,所以一共是 12 个包。

  • HTTPHTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是 80,后者是 443

  • HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议,所以,HTTPSHTTP 要更耗费服务器资源。

9、HTTP 2 相对于 HTTP1.x 有什么优势和特点?

HTTP/2(超文本传输协议第 2 版,最初命名为 HTTP2.0),是 HTTP 协议的第二个主要版本。它的目的是在不改动 HTTP 语义、方法、状态码、URI 及首部字段的情况下,大幅度提高了 web 性能。HTTP 2 主要基于 SPDY 协议。

什么是 SPDY 协议?

SPDYSpeedy 的昵音,意为“更快”。它是 Google 开发的基于 TCP 协议的应用层协议。目标是优化 HTTP 协议的性能,通过压缩、多路复用和优先级等技术,缩短网页的加载时间并提高安全性。SPDY 协议的核心思想是尽量减少 TCP 连接数。SPDY 并不是一种用于替代 HTTP 的协议,而是对 HTTP 协议的增强。

HTTP 2.0 特点

  1. 二进制传输
  2. 多路复用
  3. Header 压缩
  4. 服务端推送
  5. 更安全

多路复用

下面重点说下多路复用。

HTTP/1.0 中,每次请求都会建立一次 HTTP 连接,也就是我们常说的 3 次握手 4 次挥手,这个过程在一次请求过程中占用了相当长的时间。

HTTP 1.1 中开启了 Keep-Alive ,解决了多次连接的问题,在一个 TCP 连接上可以传送多个 HTTP 请求和响应。但是也有这样的一个问题:浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制,超过限制数目的请求会被阻塞

我们假设 Apache 设置了最大并发数为 300,因为浏览器限制,浏览器发起的最大请求数为 6,也就是服务器能承载的最高并发为 50,当第 51 个人访问时,就需要等待前面某个请求处理完成。

所以,在 HTTP/2 中,有两个非常重要的概念,分别是帧(frame)和流(stream)。 帧代表着最小的数据单位,每个帧会标识出该帧属于哪个流,流也就是多个帧组成的数据流。 多路复用,就是在一个 TCP 连接中可以存在多条流。换句话说,也就是可以同时发送多个请求,对端可以通过帧中的标识知道属于哪个请求。通过这个技术,可以避免 HTTP 旧版本中的队头阻塞问题,极大地提高传输性能。

服务端推送(Server Push

HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。

二、TCP 三次握手和四次挥手

TCP 协议通过三次握手的形式建立一个可靠的连接,建立成功之后开始发送数据。发送数据完了之后,会以四次挥手的形式来终止连接

1、三次握手

(图片来自网络)

  • 第一次握手:客户端尝试连接服务器,向服务器发送 SYNSynchronization 的缩写)包,并且设置一个序列号 seqSequence 的缩写),假设 seq=m;发送完成之后,客户端进入 SYN_SEND 状态等待服务器确认;
  • 第二次握手:服务端接收客户端 syn 包,会做出回应;服务端会回送 SYNACK 给客户端ACK 的全写是 acknowledgment ,意为答复,ACK 的值是根据客户端发送过来的 seq 来决定的,发给给客户端时,ACK 的值是根据客户端发送的 syn=m 来确认的(假设在 m 的基础上 +1,这样客户端收到回应的时候就能准确知道是服务端的回应了;服务端回应里里的 seq = n 是服务端自己生成的,给客户端进行回应使用的。发送完成之后,服务器进入 SYN_RCVD 状态;
  • 第三次握手:客户端收到服务端的 SYN+ACK 包,向服务端发送确认包 ACKack=n+1,根据刚刚收到的服务端发送的 seq = n 确定的),此包发送完毕,客户端和服务器进入 ESTABLISHED 状态,表示连接成功,完成三次握手,这个时候就可以传输数据了。

三次握手的目的是为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

”已失效的连接请求报文段”的产生在这样一种情况下:client 发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后,就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要 server 发出确认,新的连接就建立了。由于现在 client 并没有发出建立连接的请求,因此不会理睬 server 的确认,也不会向 server 发送数据。但 server 却以为新的运输连接已经建立,并一直等待 client 发来数据。这样,server 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client 不会向 server 的确认发出确认。server 由于收不到确认,就知道 client 并没有要求建立连接。—— 谢希仁版《计算机网络》

2、四次挥手

TCP 的连接的断开需要发送四个包,因此称为四次挥手(Four-way handshake),也叫做改进的三次握手。

客户端或服务器均可主动发起挥手动作,在 socket 编程中,任何一方执行 close() 操作即可产生挥手操作。

tcp-connection-closed-four-way-handshake

(图片来自网络)

  • 第一次挥手(FIN=1,seq=x):假设客户端想要关闭连接,客户端发送一个 FINFinish 的缩写,表示结束)标志位置为 1 的包,表示自己已经没有数据可以发送了,但是仍然可以接受数据。发送完毕后,客户端进入 FIN_WAIT_1 状态。

  • 第二次挥手(ACK=1,ACKnum=x+1):服务器端确认客户端的 FIN 包,发送一个确认包,表明自己接受到了客户端关闭连接的请求,但还没有准备好关闭连接。发送完毕后,服务器端进入 CLOSE_WAIT 状态,客户端接收到这个确认包之后,进入 FIN_WAIT_2 状态,等待服务器端关闭连接。

  • 第三次挥手(FIN=1,seq=y):服务器端准备好关闭连接时,向客户端发送结束连接请求,FIN 置为 1。发送完毕后,服务器端进入 LAST_ACK 状态,等待来自客户端的最后一个 ACK

  • 第四次挥手(ACK=1,ACKnum=y+1):客户端接收到来自服务器端的关闭请求,发送一个确认包,并进入 TIME_WAIT状态,等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后,关闭连接,进入 CLOSED 状态。

    客户端等待了某个固定时间(两个最大段生命周期,2MSL2 Maximum Segment Lifetime)之后,没有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。

这里有一张简单图示,可以帮助理解三次握手和四次挥手:

three-four-handshake.png

(图片来自网络)

3、为什么握手需要三次,而挥手却需要四次?

握手的时候,AB 打个招呼,B可以直接把自己的 SYN 信息和对 A 的回应 ACK 信息一起带上,但是挥手的时候,A 说我要断开了,B 还没发完最后的数据,因此需要先回应一下 A,我收到你的断开的请求了,但是你要等我把最后的内容给你,所以这里分开了 2 步:

(1)回应 A

(2)发送自己的最后一个数据。

4、为什么 A 进入 TIME_WAIT 需要等待最大报文段生存的时间后,才能关闭?

(1)第一,为了保证 A 发送的最后一个 ACK 报文能够到达 B。这个 ACK 报文段有可能丢失,因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段,而 A 就能在 2MSL 时间内收到这个重传的 FIN+ACK 报文段。如果 ATIME-WAIT 状态不等待一段时间,而是在发送完 ACK 报文段后就立即释放连接,就无法收到 B 重传的 FIN+ACK 报文段,因而也不会再发送一次确认报文段。这样,B 就无法按照正常的步骤进入 CLOSED 状态。

(2)A 在发送完 ACK 报文段后,再经过 2MSL 时间,就可以使本连接持续的时间所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求的报文段。

三、UDP 是什么?

TCP/IP 协议是一个协议簇。里面包括很多协议的,UDP 只是其中的一个, 之所以命名为 TCP/IP 协议,因为 TCPIP 协议是两个很重要的协议,就用它们俩命名了。

UDP 传输协议是 「 无连接 」 的, 「无连接」 就是在正式通信前不必与对方先建立连接,不管对方状态就直接发送。它是一种不可靠的、面向无连接、可以实现多对一、一对多和一对一连接的通信协议。

  1. UDP 在传输数据前 「 不需要建立通道 」 ,在数据传输完毕后也不需要将通道关闭。
  2. 只要客户端给服务端发送一个请求,服务端就会 「 一次性 」 地把所有数据发送完毕。UDP 在传输数据时 「 不会对数据的完整性进行验证 」 ,在数据丢失或数据出错时也 「 不会要求重新传输 」 ,因此也节省了很多用于验证数据包的时间,所以以 UDP 建立的连接的延迟会比以 TCP 建立的连接的延迟更低。
  3. UDP 不会根据当前的网络情况来控制数据的发送速度,因此无论网络情况是好是坏,服务端都会以 「 恒定的速率 」 发送数据。虽然这样有时会造成数据的丢失与损坏,但是这一点对于一些实时应用来说是十分重要的。

基于以上三点,UDP 在数据传输方面「 速度更快 」,「 延迟更低 」,「 实时性更好 」, 因此被广泛地用于通信领域和视频网站当中。

1、TCP/UDP 的区别

  • TCP 是面向连接的,UDP 是无连接的。

  • TCP 保证了数据的可靠传输,UDP 是有可能丢包的。

  • TCP 的结构比较复杂,UDP 简单。
  • TCP 慢,UDP 快。
请我喝杯咖啡吧~
-------- 本文结束 感谢阅读 --------