admin管理员组文章数量:1603247
一.Http
🦄Http简介
HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,它是构建于 TCP/IP 协议之上的一个应用层协议(网络进行通信的规则),默认端口号是 80。HTTP协议工作于客户端-服务端架构之上。HTTP客户端通过URL向HTTP服务端发送所有请求,HTTP服务端根据接收到的请求后, 向客户端发送响应信息。HTTP 是一种无状态 (stateless) 协议,HTTP协议本身不会对发送过的请求和相应的通信状态进行持久化处理。这样做的目的是为了保持HTTP协议的简单性,从而能够快速处理大量的事务, 提高效率。 但是,很多应用场景中,我们需要保持各种状态,如:登录状态等。我们就必须引入一些技术来记录管理状态,例如Cookie等技术。目前绝大多数的Web开发,都是构建在HTTP协议之上的。
🦓Http的特点
HTTP 协议一共有五大特点:1、支持客户/服务器模式;2、简单快速;3、灵活;4、无连接;5、无状态。
1.支持客户/服务器模式
HTTP遵循请求(Request)/应答(Response)模型。 由客户端向服务器端发起建立连接请求(三次握手)连接以后发起请求消息,即Request;然后服务器返回响应到客户端,即Response,然后客户端和服务器之间的链接断开(四次挥手)。
2.简单快速
客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
3.灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type(Content-Type是HTTP包中用来表示内容类型的标识)加以标记。
4.无连接
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。 早期这么做的原因是 HTTP 协议产生于互联网,因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问,但每个客户端(即浏览器)与服务器之间交换数据的间歇性较大(即传输具有突发性、瞬时性), 并且网页浏览的联想性、发散性导致两次传送的数据关联性很低,大部分通道实际上会很空闲、无端占用资源。因此 HTTP的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接,以尽快将资源释放出来服务其他客户端。 随着时间的推移,网页变得越来越复杂,里面可能嵌入了很多图片,这时候每次访问图片都需要建立一次 TCP 连接就显得很低效。后来,Keep-Alive 被提出用来解决这效率低的问题。Keep-Alive 功能使客户端到服务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive 功能避免了建立或者重新建立连接。市场上的大部分 Web 服务器,包括 iPlanet、IIS 和 Apache,都支持 HTTP Keep-Alive。对于提供静态内容的网站来说,这个功能通常很有用。但是,对于负担较重的网站来说,这里存在另外一个问题:虽然为客户保留打开的连接有一定的好处,但它同样影响了性能,因为在处理暂停期间,本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时,Keep-Alive功能对资源利用的影响尤其突出。这样一来,客户端和服务器之间的 HTTP 连接就会被保持,不会断开(超过 Keep-Alive 规定的时间,意外断电等情况除外),当客户端发送另外一个请求时,就使用这条已经建立的连接。
5.无状态
HTTP协议是无状态协议,无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后,服务器根据请求,会给我们发送数据过来,但是,发送完,不会记录任何信息。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。 HTTP 协议这种特性有优点也有缺点,优点在于解放了服务器,每一次请求“点到为止”不会造成不必要连接占用,缺点在于每次请求会传输大量重复的内容信息。客户端与服务器进行动态交互的 Web 应用程序出现之后,HTTP 无状态的特性严重阻碍了这些应用程序的实现,毕竟交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品。于是,两种用于保持 HTTP 连接状态的技术就应运而生了,一个是 Cookie,而另一个则是 Session。Cookie可以保持登录信息到用户下次与服务器的会话,换句话说,下次访问同一网站时,用户会发现不必输入用户名和密码就已经登录了(当然,不排除用户手工删除Cookie)。而还有一些Cookie在用户退出会话的时候就被删除了,这样可以有效保护个人隐私。 Cookies最典型的应用是判定注册用户是否已经登录网站,用户可能会得到提示,是否在下一次进入此网站时保留用户信息以便简化登录手续,这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品,这些信息都会写入
Cookies,以便在最后付款时提取信息。 与 Cookie 相对的一个解决方案是 Session,它是通过服务器来保持状态的。 当客户端访问服务器时,服务器根据需求设置 Session,将会话信息保存在服务器上,同时将标示 Session 的 SessionId 传递给客户端浏览器,浏览器将这个SessionId 保存在内存中,我们称之为无过期时间的 Cookie。浏览器关闭后,这个 Cookie 就会被清掉,它不会存在于用户的 Cookie 临时文件。 以后浏览器每次请求都会额外加上这个参数值,服务器会根据这个 SessionId,就能取得客户端的数据信息。如果客户端浏览器意外关闭,服务器保存的 Session 数据不是立即释放,此时数据还会存在,只要我们知道那个 SessionId,就可以继续通过请求获得此 Session 的信息,因为此时后台的 Session 还存在,当然我们可以设置一个 Session超时时间,一旦超过规定时间没有客户端请求时,服务器就会清除对应 SessionId 的 Session 信息。
🐴HTTP的工作过程
1.域名解析
当请求一个超链接时,HTTP就开始工作了,上文说到Http是基于TCP/IP协议的,因此首先需要对域名进行解析找到正确的IP地址,然后才能进行正常的通信,DNS域名解析采用的是递归查询的方式,过程是先去找DNS缓存->缓存找不到就去找根域名服务器 根域名又会去找下一级,这样递归查找之后,找到了,域名解析步骤如下:
- 浏览器首先检查自己本地是缓存是否有对应的域名,有则直接使用(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存)。
- 如果浏览器缓存中没有,则查询系统DNS缓存中的域名表缓存,有则直接使用。
- 系统缓存中还是没有,则检查hosts文件中的映射表。【windows中hosts文件路径:C:\Windows\System32\drivers\etc】
- 本地实在找不到,则递归地去域名服务器去查找(就近查找)。【DNS服务器IP是本地配置的首选服务器,一般常用的有114.114.114.114(电信运营商提供)和8.8.8.8(Google提供)】
DNS服务器首先查找自身的缓存,有对应的域名ip则返回结果 如果缓存中查找不到,DNS服务器则发起递归DNS请求,首先向根域服务器发起请求查询,假如本次请求的是www.baidu,根域服务器发现这是一个com的顶级域名,就把com域的ip地址返回给DNS服务器DNS服务器向com域ip地址发起请求,查询该域名的ip,此时该服务器返回了baidu的DNS地址。 最后DNS服务器又向baidu的DNS地址发起查询请求,最后找到了完整的ip路径返回给DNS服务器,DNS再把ip信息返回给windows内核,内核再返回给浏览器,于是浏览器就知道该域名对应的ip地址了,可以开始进一步请求了。
2.建立TCP连接
在HTTP工作开始之前,客户端首先要通过网络与服务端建立连接。HTTP是比TCP更高层次的应用层协议, 根据规则,只有低层协议建立之后才能进行更高层协议的连接, 因此, 首先要建立TCP连接, 一般TCP连接的端口号是80。 通过域名解析找到对应主机的ip地址以后, 就可以通过三次握手建立tcp连接,进行通信。
-
第一次握手:建立连接时,客户端发送syn包(seq=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
-
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(seq=k),即SYN+ACK包,此时服务器进入SYN_RECV状态。
-
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
【建立连接的最重要目是让连接的双方交换初始序号(ISN, Initial Sequence Number),所以再响应的ACK报文中会包含序列号递增序列】
3.客户端像服务端发送请求数据
通过三次握手建立tcp连接以后,客户端就可以开始向服务端发送Http请求报文。一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成。
-
客户端首先会向服务端发送请求行,它包括了请求方法、请求 URI(Uniform Resource Identifier)和 HTTP 版本协议。 它们用空格分隔。例如:
GET/sample/hello.jsp HTTP/1.1
请求行:用于描述客户端的请求方式(GET/POST等),请求的资源名称(URL)以及使用的HTTP协议的版本号。
HTTP协议的请求方法有如下:
- GET 获取资源 (幂等)
- POST 新增资源
- HEAD 获取 HEAD 元数据 (幂等)
- PUT 更新资源 (带条件时幂等)
- DELETE 删除资源 (幂等)
- CONNECT 建立 Tunnel 隧道
- OPTIONS 获取服务器支持访问资源的方法 (幂等)
- TRACE 回显服务器收到的请求,可以定位问题。(有安全风险) -
在客户端发送请求行命令之后,还要以请求头形式发送其他一些信息,把客户端的一些基础信息告诉服务器。比如包含了客户端所使用的操作系统、客户端内核等信息,以及当前请求的域名信息、Cookie等。
Host: www.example User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive
请求头:请求头部由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息,典型的请求头有:
- Accept
- 作用:指定客户端能够接收的内容类型
- 示例:
Accept:text/html
- Accept-Charset
- 作用:客户端可以接受的字符编码集
- 示例:
Accept-Charset:utf-8
- Accept-Encoding
- 作用:指定客户端可以支持web服务器返回内容的压缩编码类型
- 示例:
Accept-Encoding:gzip
- Accept-Language
- 作用:客户端可接受的语言
- 示例:
Accept-Language:en
- Accept-Ranges
- 作用:可以请求网页实体的一个或者多个子范围字段
- 示例:
Accept-Ranges:bytes
- Authorization
- 作用:HTTP授权的授权证书类型
- Cache-Control
- 作用:指定请求和响应遵循的缓存机制
- 示例:
Cache-Control:no-cache
- Connection
- 作用:表示是否需要持久连接,注意HTTP1.1默认进行持久连接
- 示例:
Connection:close
- Cookie
- 作用:HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器
- 示例:
Cookie:$Version=1;Skin=new
- Content-Length
- 作用:请求的内容长度
- 示例:
Content-Length:348
- Content-Type
- 作用:请求与实体对应的MIME信息
- Host
- 作用:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
- Accept
-
之后客户端发送了一空白行来通知服务器, 表示它已经结束了该头信息的发送。
空行:最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再是请求头。
4.客户端发送请求数据。
GET方法并没有请求数据,在发送POST请求时才会有请求正文。
请求数据:当使用POST等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中(GET方式是保存在url地址后面)。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
4.服务端向客户端发送响应数据
服务端收到接收到HTTP请求之后,处理完自身的逻辑以后,会将HTTP响应给客户端,HTTP响应报文主要由状态行、响应头部、空行以及响应数据组成。
-
服务器会返回响应行,包括协议版本和状态码。
HTTP/1.1 200 OK
状态行:由3部分组成,分别为:协议版本,状态码,状态码描述。
其中协议版本与请求报文一致,状态码描述是对状态码的简单描述。一些常见的状态码一般分为五类:- 1xx——信息响应,这一类型的状态码,代表请求已被接受,需要继续处理,这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束,这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送1xx响应。这些状态码代表的响应都是信息性的,标示客户应该采取的其他行动。
- 2xx——成功响应,求已成功被服务器接收,理解,并接受,也就是一次成功的响应。
- 3xx——重定向,这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的Location域中指明。当且仅当后续的请求所使用的方法是GET或者HEAD时,用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。
- 4xx——客户端错误,这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。除非响应的是一个HEAD请求,否则服务器就应该返回一个解释当前错误状况的实体,以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。
- 5xx——服务端错误,表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。
-
正如客户端会随同请求发送请求头一样,服务器也会随同响应向客户端发送响应头。响应头包含了服务器自身的一些信息, 比如服务器生成返回数据的时间、返回的数据类型(JSON、HTML、流媒体等类型),以及服务器要在客户端保存的 Cookie 等信息。
响应头:响应头用于描述服务器的基本信息,以及客户端如何处理数据。 -
空格:**CRLF(即 \r\n)分割
最后一个响应头头之后是一个空行,通知客户端以下不再是响应头的内容。 -
服务器发送响应体数据,通常包含了数据返回的实际内容。
消息体:服务器返回给客户端的数据 Content-Type 表示消息体的类型,通常浏览网页其类型是HTML,当然还会有其他类型,比如图片、视频等。 -
特殊情况-重定向
如果响应行返回的状态码是 301,那么就是服务端告诉客户端,需要重定向到另外的链接获取资源,而需要重定向的网址正是包含在响应头的 Location 字段中接下来,客户端获取 Location 字段中的地址,并使用该地址重新导航,这就是一个完整重定向的执行流程。
5.服务端关闭TCP连接
一般情况下, 一旦Web服务器向浏览器发送了响应数据, 它就要关闭TCP连接(四次挥手)。 如果浏览器或者服务器在其头信息加入了这行代码:
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态。于是, 浏览器可以继续通过相同的连接发送请求. 保持连接节省了为每个请求建立新连接所需的时间, 还节约了网络带宽。
- 第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;
- 第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;
- 第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;
- 第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。
二.Https
🐣Https简介
HTTP 在传输数据的过程中,所有的数据都是明文传输,自然没有安全性可言,特别是一些敏感数据,比如用户密码和信用卡信息等,而这些明文数据会经过WiFi、路由器、运营商、机房等多个物理设备节点,如果在这中间任意一个节点被监听,传输的内容就会完全暴露,这一攻击手法叫做MITM(Man In The Middle)中间人攻击。为了解决HTTP明文传输数据可能导致的安全问题,1994年网景公司提出了HTTPS(HyperText Transfer Protocol Secure)超文本传输安全协议,数据通信仍然是HTTP,但利用SSL/TLS加密数据包。
采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书,证书是需要申请的,并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的,安全级别越高价格越贵)。 颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存,不可泄漏。公钥则是附带在证书的信息中,可以公开的。证书本身也附带一个证书电子签名,这个签名用来验证证书的完整性和真实性,可以防止证书被篡改。
🦢Https通信加密
通信需要加密是为了解决数据被窃取问题。因为HTTP不对通信内容进行加密处理,所以衍生了SSL加密技术协议,SSL采用混合加密(同时使用非对称加密和对称加密)的方式建立起安全的HTTP通信,经过加密后的内容即使被窃听了,窃听的人也无法解密对应的数据。
-
对称加密
对称加密是指加密和解密的密钥为同一个。 在通信时还需将密钥传输给对方用来解密,密钥传输过程中同样可能被截获,所以这种加密方式通信安全的前提是如何安全的传输密钥。 -
非对称加密
与对称加密不同,非对称加密的密钥是成对的(公钥和私钥)。 这种方式又被称之为公开密钥加密,使用一对非对称的密钥,一把叫做公开密钥(public key),一把叫做私有密钥(private key),其中公开密钥可以随意发送,私有密钥必须保密。 -
混合加密
虽然非对称加密很安全,但是和对称加密比起来,它的解密速度非常慢;所以通常会用混合加密的方式进行通信,混合加密是用非对称加密的方式交换双方的对称加密秘钥,交换对称加密秘钥之后双方再用对称加密的方式进行通信。
🐓Https数字证书
数字认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书,数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上,其具体的业务流程如下:
- 服务器运营人员向数字证书认证机构提出公开密钥的申请。
- 数字证书认证机构判明身份之后,会对已申请的公开密钥做数字签名,并将该公开密钥放入公钥证书后绑定在一起,服务器会将这份由数字认证机构颁发的公钥证书发送给客户端。
- 客户端获取到数字认证机构颁发的公开密钥后,对其进行数字签名验证,一是确认公开密钥是真实的数字认证机构颁发的,二是确认公开密钥的值得信赖的。
- 确认无误后,使用该公开密钥加密报文。
- 服务器使用私有密钥进行报文解密。
🦖Https请求流程
- 客户端发起请求,例如在浏览器输入
https://www/baidu
,请求服务器443端口 - 服务端收到客户端请求后,会将网站支持的证书信息(证书中包含公钥)传送一份给客户端。
- 客户端收到证书之后,读取证书中的证书所有者、有效期等信息,进行校验,主要验证:
- 证书是否过期
- 发行证书的机构是否可靠
- 返回的公钥是否能正确解开返回证书中的数字签名
- 证书域名和请求的域名是否匹配
- 客户端开始查找操作系统中已内置的受信任的证书发布机构CA,与服务器发来的证书中的颁发者CA比对,用于校验证书是否为合法机构颁发
- 如果找不到,浏览器就会报错,说明服务器发来的证书是不可信任的。
- 如果找到,那么浏览器就会从操作系统中取出 颁发者CA 的公钥,然后对服务器发来的证书里面的签名进行解密
- 客户端使用相同的hash算法计算出服务器发来的证书的hash值,将这个计算的hash值与证书中签名做对比
- 对比结果一致,则证明服务器发来的证书合法,没有被冒充
- 如果证书验证通过,客户端将生成的随机堆成加密秘钥,并通过服务端传过来的的公钥加密,发给服务器
- 服务器收到客户端用公钥加密过的随机秘钥之后,用私钥解密出秘钥
- 服务器用解出来的客户端秘钥,将要响应的内容用秘钥对称加密,响应给客户端
- 客户端将得到的内容,用刚刚自己生成的秘钥解密出内容
🐐HTTPS的缺点
- HTTPS协议多次握手,导致页面的加载时间延长近50%;
- HTTPS连接缓存不如HTTP高效,会增加数据开销和功耗;
- 申请SSL证书需要钱,功能越强大的证书费用越高。
- SSL涉及到的安全算法会消耗 CPU 资源,对服务器资源消耗较大。
🦔Https能防止被抓包吗?
HTTPS 的数据是加密的,常规下抓包工具代理请求后抓到的包内容是加密状态,无法直接查看。但是,正如前文所说,浏览器只会提示安全风险,如果用户授权仍然可以继续访问网站,完成请求。因此,只要客户端是我们自己的终端,我们授权的情况下,便可以组建中间人网络,而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书,用户需要手动把证书安装到客户端中,然后终端发起的所有请求通过该证书完成与抓包工具的交互,然后抓包工具再转发请求到服务器,最后把服务器返回的结果在控制台输出后再返回给终端,从而完成整个请求的闭环。既然 HTTPS 不能防抓包,那 HTTPS 有什么意义?HTTPS 可以防止用户在不知情的情况下通信链路被监听,对于主动授信的抓包操作是不提供防护的,因为这个场景用户是已经对风险知情。要防止被抓包,需要采用应用级的安全防护,例如采用私有的对称加密,同时做好移动端的防反编译加固,防止本地算法被破解。
彻底搞懂HTTPS的加密原理
全网最透彻HTTPS加解密原理,看完不懂你来打我
版权声明:本文标题:漫谈Http和Https 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://www.elefans.com/dianzi/1728436498a1158163.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论