Http协议超详解

本文详细介绍了HTTP和HTTPS协议的区别,包括HTTP的基本概念、HTTPS的安全性以及它们在URL上的标识。此外,还对比了TCP和UDP在网络传输中的特点,如TCP的可靠性和UDP的效率。文章还提及了HTTP请求头的种类,如Host、Cache-Control和Connection,并讨论了无状态协议的概念以及Cookie和JWT在保持会话状态中的作用。
摘要由CSDN通过智能技术生成

一,HTTP 和 HTTPS 的区别

1. HTTP

HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。

 HTTP 主要内容分为三部分,超文本(Hypertext)、传输(Transfer)、协议(Protocol)

  • 超文本就是不单单只是本文,它还可以传输图片、音频、视频,甚至点击文字或图片能够进行超链接的跳转。
  • 上面这些概念可以统称为数据,传输就是数据需要经过一系列的物理介质从一个端系统传送到另外一个端系统的过程。通常我们把传输数据包的一方称为请求方,把接到二进制数据包的一方称为应答方
  • 而协议指的就是是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样,计算机之间的相互通信需要共同遵守一定的规则,这些规则就称为协议,只不过是网络协议

说到 HTTP,不得不提的就是 TCP/IP 网络模型,一般是五层模型。如下图所示

 但是也可以分为四层,就是把链路层和物理层都表示为网络接口层

还有一种就是 OSI 七层网络模型,它就是在五层协议之上加了表示层和会话层 

2.HTTPS

 而 HTTPS 的全称是 Hypertext Transfer Protocol Secure,从名称我们可以看出 HTTPS 要比 HTTP 多了 secure 安全性这个概念,实际上, HTTPS 并不是一个新的应用层协议,它其实就是 HTTP + TLS/SSL 协议组合而成,而安全性的保证正是 TLS/SSL 所做的工作。

也就是说,HTTPS 就是身披了一层 SSL 的 HTTP

3. 那么,HTTP 和 HTTPS 的主要区别是什么呢?

  • 最简单的,HTTP 在地址栏上的协议是以 http:// 开头,而 HTTPS 在地址栏上的协议是以 https:// 开头
 http://www.cxuanblog.com/ 
 https://www.cxuanblog.com/
  •  HTTP 是未经安全加密的协议,它的传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造;而 HTTPS 是安全的协议,它通过 密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 能够解决上面这些问题。

  

  •  HTTP 的默认端口是 80,而 HTTPS 的默认端口是 443。

4.HTTP Get 和 Post 区别

HTTP 中包括许多方法,Get 和 Post 是 HTTP 中最常用的两个方法,基本上使用 HTTP 方法中有 99% 都是在使用 Get 方法和 Post 方法,所以有必要我们对这两个方法有更加深刻的认识。

  • get 方法一般用于请求,比如你在浏览器地址栏输入 www.cxuanblog.com 其实就是发送了一个 get 请求,它的主要特征是请求服务器返回资源,而 post 方法一般用于 <form> 表单的提交,相当于是把信息提交给服务器,等待服务器作出响应,get 相当于一个是 pull/拉的操作,而 post 相当于是一个 push/推的操作。
  • get 方法是不安全的,因为你在发送请求的过程中,你的请求参数会拼在 URL 后面,从而导致容易被攻击者窃取,对你的信息造成破坏和伪造;
 /test/demo_form.asp?name1=value1&name2=value2 

 而 post 方法是把参数放在请求体 body 中的,这对用户来说不可见

 POST /test/demo_form.asp HTTP/1.1
 Host: w3schools.com
 name1=value1&name2=value2 

  • get 请求的 URL 有长度限制,而 post 请求会把参数和值放在消息体中,对数据长度没有要求。
  • get 请求会被浏览器主动 cache,而 post 不会,除非手动设置。
  • get 请求在浏览器反复的 回退/前进 操作是无害的,而 post 操作会再次提交表单请求。
  • get 请求在发送过程中会产生一个 TCP 数据包;post 在发送过程中会产生两个 TCP 数据包。对于 get 方式的请求,浏览器会把 http header 和 data 一并发送出去,服务器响应 200(返回数据);而对于 post,浏览器先发送 header,服务器响应 100 continue,浏览器再发送 data,服务器响应 200 ok(返回数据)。

get 与post差别没错。在http协议中,两者的的差别只是在语义上,get用于获取资源,post修改资源。参数附在url和body中均可以,写的那些差别只是其放在在url与http body的差别。而且post发两个tcp包也只是部分浏览器行为,与http协议无关

二,UDP 和 TCP 的区别

TCP 和 UDP 都位于计算机网络模型中的运输层,它们负责传输应用层产生的数据。下面我们就来聊一聊 TCP 和 UDP 分别的特征和他们的区别

1.UDP 是什么

UDP 的全称是 User Datagram Protocol,用户数据报协议。它不需要所谓的握手操作,从而加快了通信速度,允许网络上的其他主机在接收方同意通信之前进行数据传输。

数据报是与分组交换网络关联的传输单元。


UDP 的特点主要有

  • UDP 能够支持容忍数据包丢失的带宽密集型应用程序
  • UDP 具有低延迟的特点
  • UDP 能够发送大量的数据包
  • UDP 能够允许 DNS 查找,DNS 是建立在 UDP 之上的应用层协议。

2.TCP 是什么

TCP 的全称是Transmission Control Protocol ,传输控制协议。它能够帮助你确定计算机连接到 Internet 以及它们之间的数据传输。通过三次握手来建立 TCP 连接,三次握手就是用来启动和确认 TCP 连接的过程。一旦连接建立后,就可以发送数据了,当数据传输完成后,会通过关闭虚拟电路来断开连接。

TCP 的主要特点有

  • TCP 能够确保连接的建立和数据包的发送
  • TCP 支持错误重传机制
  • TCP 支持拥塞控制,能够在网络拥堵的情况下延迟发送
  • TCP 能够提供错误校验和,甄别有害的数据包。

3.TCP 和 UDP 的不同

  • TCP 是面向连接的协议 。 UDP 是无连接的协议
  • TCP 在发送数据前先需要建立连接,然后再发送数据 。 UDP 无需建立连接就可以直接发送大量数据
  • TCP 会按照特定顺序重新排列数据包 。 UDP 数据包没有固定顺序,所有数据包都相互独立
  • TCP 传输的速度比较慢 。 UDP 的传输会更快
  • TCP 的头部字节有 20 字节 。 UDP 的头部字节只需要 8 个字节
  • TCP 是重量级的,在发送任何用户数据之前,TCP需要三次握手建立连接。 UDP 是轻量级的。没有跟踪连接,消息排序等。
  • TCP 会进行错误校验,并能够进行错误恢复 。 UDP 也会错误检查,但会丢弃错误的数据包。
  • TCP 有发送确认。 UDP 没有发送确认
  • TCP 会使用握手协议,例如 SYN,SYN-ACK,ACK。 UDP无握手协议
  • TCP 是可靠的,因为它可以确保将数据传送到路由器。 UDP 中不能保证将数据传送到目标。

三, HTTP 常见的请求头

HTTP 标头会分为四种,分别是 通用标头实体标头请求标头响应标头

1.通用标头

Date


Date 是一个通用标头,它可以出现在请求标头和响应标头中,它的基本表示如下

 Date: Wed, 21 Oct 2015 07:28:00 GMT 


表示的是格林威治标准时间,这个时间要比北京时间慢八个小时

Cache-Control


Cache-Control 是一个通用标头,他可以出现在请求标头响应标头中,Cache-Control 的种类比较多,虽然说这是一个通用标头,但是又一些特性是请求标头具有的,有一些是响应标头才有的。主要大类有 可缓存性阈值性、 重新验证并重新加载

Connection 决定当前事务(一次三次握手和四次挥手)完成后,是否会关闭网络连接。Connection 有两种,一种是持久性连接,即一次事务完成后不关闭网络连接

 Connection: keep-alive 


另一种是非持久性连接,即一次事务完成后关闭网络连接

 Connection: close 

2. 实体标头


实体标头是描述消息正文内容的 HTTP 标头。实体标头用于 HTTP 请求和响应中。头部Content-Length、 Content-Language、 Content-Encoding 是实体头。

  • Content-Length 实体报头指示实体主体的大小,以字节为单位,发送到接收方。
  • Content-Language 实体报头描述了客户端或者服务端能够接受的语言。
  • Content-Encoding 这又是一个比较麻烦的属性,这个实体报头用来压缩媒体类型。Content-Encoding 指示对实体应用了何种编码。
    常见的内容编码有这几种: gzip、compress、deflate、identity ,这个属性可以应用在请求报文和响应报文中
 Accept-Encoding: gzip, deflate //请求头
 Content-Encoding: gzip  //响应头 

下面是一些实体标头字段 

 3.请求标头


Host
Host 请求头指明了服务器的域名(对于虚拟主机来说),以及(可选的)服务器监听的 TCP 端口号。如果没有给定端口号,会自动使用被请求服务的默认端口(比如请求一个 HTTP 的 URL 会自动使用 80 作为端口)。

 Host: developer.mozilla.org 


上面的 Accpet、 Accept-LanguageAccept-Encoding 都是属于内容协商的请求标头。

Referer


HTTP Referer 属性是请求标头的一部分,当浏览器向 web 服务器发送请求的时候,一般会带上 Referer,告诉服务器该网页是从哪个页面链接过来的,服务器因此可以获得一些信息用于处理。

 Referer: https://developer.mozilla.org/testpage.html 

If-Modified-Since


If-Modified-Since 通常会与 If-None-Match 搭配使用,If-Modified-Since 用于确认代理或客户端拥有的本地资源的有效性。获取资源的更新日期时间,可通过确认首部字段 Last-Modified 来确定。


大白话说就是如果在 Last-Modified 之后更新了服务器资源,那么服务器会响应 200,如果在 Last-Modified 之后没有更新过资源,则返回 304。

 If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT


If-None-Match


If-None-Match HTTP 请求标头使请求成为条件请求。 对于 GET 和 HEAD 方法,仅当服务器没有与给定资源匹配的 ETag 时,服务器才会以 200 状态发送回请求的资源。 对于其他方法,仅当最终现有资源的ETag与列出的任何值都不匹配时,才会处理请求。

 If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"


Accept


接受请求 HTTP 标头会通告客户端其能够理解的 MIME 类型


Accept-Charset


accept-charset 属性规定服务器处理表单数据所接受的字符集。
常用的字符集有: UTF-8 - Unicode 字符编码 ; ISO-8859-1 - 拉丁字母表的字符编码


Accept-Language


首部字段 Accept-Language 用来告知服务器用户代理能够处理的自然语言集(指中文或英文等),以及自然语言集的相对优先级。可一次指定多种自然语言集。

 4.响应标头

s-Control-Allow-Origin


一个返回的 HTTP 标头可能会具有 Access-Control-Allow-Origin ,Access-Control-Allow-Origin 指定一个来源,它告诉浏览器允许该来源进行资源访问。


Keep-Alive


Keep-Alive 表示的是 Connection 非持续连接的存活时间,可以进行指定。


Server


服务器标头包含有关原始服务器用来处理请求的软件的信息。


应该避免使用过于冗长和详细的 Server 值,因为它们可能会泄露内部实施细节,这可能会使攻击者容易地发现并利用已知的安全漏洞。例如下面这种写法

 Server: Apache/2.4.1 (Unix) 


Set-Cookie


Set-Cookie 用于服务器向客户端发送 sessionID。


Transfer-Encoding


首部字段 Transfer-Encoding 规定了传输报文主体时采用的编码方式。
HTTP /1.1 的传输编码方式仅对分块传输编码有效。


X-Frame-Options


HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上,会出现各种非标准的首部字段。


首部字段 X-Frame-Options 属于 HTTP 响应首部,用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持(clickjacking)攻击。

四,HTTPS 的工作原理 

我们上面描述了一下 HTTP 的工作原理,下面来讲述一下 HTTPS 的工作原理。因为我们知道 HTTPS 不是一种新出现的协议,而是

所以,我们探讨 HTTPS 的握手过程,其实就是 SSL/TLS 的握手过程。


TLS 旨在为 Internet 提供通信安全的加密协议。TLS 握手是启动和使用 TLS 加密的通信会话的过程。在 TLS 握手期间,Internet 中的通信双方会彼此交换信息,验证密码套件,交换会话密钥。


每当用户通过 HTTPS 导航到具体的网站并发送请求时,就会进行 TLS 握手。除此之外,每当其他任何通信使用HTTPS(包括 API 调用和在 HTTPS 上查询 DNS)时,也会发生 TLS 握手。


TLS 具体的握手过程会根据所使用的密钥交换算法的类型和双方支持的密码套件而不同。 我们以RSA 非对称加密来讨论这个过程。整个 TLS 通信流程图如下

  • 在进行通信前,首先会进行 HTTP 的三次握手,握手完成后,再进行 TLS 的握手过程
  • ClientHello:客户端通过向服务器发送 hello 消息来发起握手过程。这个消息中会夹带着客户端支持的 TLS 版本号(TLS1.0 、TLS1.2、TLS1.3) 、客户端支持的密码套件、以及一串 客户端随机数
  • ServerHello:在客户端发送 hello 消息后,服务器会发送一条消息,这条消息包含了服务器的 SSL 证书、服务器选择的密码套件和服务器生成的随机数。
  • 认证(Authentication):客户端的证书颁发机构会认证 SSL 证书,然后发送 Certificate 报文,报文中包含公开密钥证书。最后服务器发送 ServerHelloDone 作为 hello 请求的响应。第一部分握手阶段结束。
  • 加密阶段:在第一个阶段握手完成后,客户端会发送 ClientKeyExchange 作为响应,这个响应中包含了一种称为 The premaster secret 的密钥字符串,这个字符串就是使用上面公开密钥证书进行加密的字符串。随后客户端会发送 ChangeCipherSpec,告诉服务端使用私钥解密这个 premaster secret 的字符串,然后客户端发送 Finished 告诉服务端自己发送完成了。

Session key 其实就是用公钥证书加密的公钥。

  • 实现了安全的非对称加密:然后,服务器再发送 ChangeCipherSpec 和 Finished 告诉客户端解密完成,至此实现了 RSA 的非对称加密。

五,无状态协议

无状态协议(Stateless Protocol) 就是指浏览器对于事务的处理没有记忆能力。举个例子来说就是比如客户请求获得网页之后关闭浏览器,然后再次启动浏览器,登录该网站,但是服务器并不知道客户关闭了一次浏览器。
HTTP 就是一种无状态的协议,他对用户的操作没有记忆能力。可能大多数用户不相信,他可能觉得每次输入用户名和密码登陆一个网站后,下次登陆就不再重新输入用户名和密码了。这其实不是 HTTP 做的事情,起作用的是一个叫做 小甜饼(Cookie) 的机制。它能够让浏览器具有记忆能力。

也就说明你的记忆芯片通电了...... 当你想服务端发送请求时,服务端会给你发送一个认证信息,服务器第一次接收到请求时,开辟了一块 Session 空间(创建了Session对象),同时生成一个 sessionId ,并通过响应头的 **Set-Cookie:JSESSIONID=XXXXXXX **命令,向客户端发送要求设置 Cookie 的响应; 客户端收到响应后,在本机客户端设置了一个 **JSESSIONID=XXXXXXX **的 Cookie 信息,该 Cookie 的过期时间为浏览器会话结束。

接下来客户端每次向同一个网站发送请求时,请求头都会带上该 Cookie信息(包含 sessionId ), 然后,服务器通过读取请求头中的 Cookie 信息,获取名称为 JSESSIONID 的值,得到此次请求的 sessionId。这样,你的浏览器才具有了记忆能力。

还有一种方式是使用 JWT 机制,它也是能够让你的浏览器具有记忆能力的一种机制。与 Cookie 不同,JWT 是保存在客户端的信息,它广泛的应用于单点登录的情况。JWT 具有两个特点

  • JWT 的 Cookie 信息存储在客户端,而不是服务端内存中。也就是说,JWT 直接本地进行验证就可以,验证完毕后,这个 Token 就会在 Session 中随请求一起发送到服务器,通过这种方式,可以节省服务器资源,并且 token 可以进行多次验证。
  • JWT 支持跨域认证,Cookies 只能用在单个节点的域或者它的子域中有效。如果它们尝试通过第三个节点访问,就会被禁止。使用 JWT 可以解决这个问题,使用 JWT 能够通过多个节点进行用户认证,也就是我们常说的跨域认证
  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值