还不懂 HTTP 协议的吗?一篇文章讲透

写在最前

超文本传输协议(Hyper Text Transfer Protocol,HTTP)是一个简单的请求-响应协议,它是基于 TCP 协议的应用层传输协议。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

HTTP 是一种无状态 (stateless) 协议, HTTP 协议本身不会对发送过的请求和响应的通信状态进行持久化处理。这样做的目的是为了保持 HTTP 协议的简单性,从而能够快速处理大量的事务,提高效率。

HTTP 请求体

HTTP 请求体是请求数据时发送给服务器的数据,毕竟向服务器拿数据,先要表明怎么要,以及要什么!

HTTP 请求体由:请求行 、请求头、请求体组成。

常用的 HTTP Method

l GET:用于请求访问已经被 URI(统一资源标识符)识别的资源,可以通过 URL 传参给服务器。

l POST:用于传输信息给服务器,主要功能与 GET 方法类似,但一般推荐使用 POST 方式。

l PUT:传输文件,报文主体中包含文件内容,保存到对应 URI 位置。

l HEAD:获得报文首部,与 GET 方法类似,只是不返回报文主体,一般用于验证 URI 是否有效。

l DELETE:删除文件,与 PUT 方法相反,删除对应 URI 位置的文件。

l OPTIONS:查询相应 URI 支持的 HTTP 方法。

Post 请求示例

# Method URL Version 请求行

POST /httpLearn/postRequest HTTP/1.1

# Request Header 请求头

Host: 127.0.0.1:8080

User-Agent: apifox/1.0.0 (https://www.apifox.cn)

Content-Length: 126

Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

# Request Message 请求体

----WebKitFormBoundary7MA4YWxkTrZu0gW

Content-Disposition: form-data; name="param"

post

----WebKitFormBoundary7MA4YWxkTrZu0gW

Get 请求示例

Get 请求没有请求体

# Method URL Version  请求行

GET /httpLearn/getRequest?param=123 HTTP/1.1

# Request Header  请求头

Host: 127.0.0.1:8080

User-Agent: apifox/1.0.0 (https://www.apifox.cn)

GET 与 POST 的区别

GET 与 POST 是我们常用的两种 HTTP Method,二者之间的区别主要包括如下五个方面:

  1. 从功能上讲,GET 一般用来从服务器上获取资源,POST 一般用来更新服务器上的资源
  2. 从 REST 服务角度上说,GET 是幂等的,即读取同一个资源,总是得到相同的数据,而 POST 不是幂等的,因为每次请求对资源的改变并不是相同的;
  3. 从请求参数形式上看,GET 请求的数据会附在 URL 之后,即将请求数据放置在 HTTP 报文的请求头中,以?分割 URL 和传输数据,参数之间以 & 相连;而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的请求体中。
  4. 从安全性上看,POST 的安全性要比 GET 的安全性高,因为 GET 请求提交的数据将明文出现在 URL 上,而且 POST 请求参数则被包装到请求体中,相对更安全。
  5. 从请求的大小看,GET 请求的长度受限于浏览器或服务器对 URL 长度的限制,允许发送的数据量比较小,而 POST 请求则是没有大小限制的。

Http 响应报文

HTTP 的响应报文是服务器返回的数据,必须先有请求体再有响应报文。

HTTP 响应报文由:状态行、响应头、响应体组成。

常见 Response Code 分类

  1. 1xx(临时响应):信息,服务器收到请求,需要请求者继续执行操作;
  2. 2xx(成功):操作被成功接收并处理;
  3. 3xx(重定向):需要进一步的操作以完成请求;
  4. 4xx(客户端错误):请求包含语法错误或无法完成请求;
  5. 5xx(服务器错误):服务器在处理请求的过程中发生了错误;

响应示例

# Version  Response Code  状态行

HTTP/1.1 200 OK

# Response Header  响应头

Content-Type:text/plain;charset=UTF-8

Content-Length:31

Date:Wed, 19 Jan 2022 11:37:00 GMT

Keep-Alive:timeout=60

Connection:keep-alive

# Response Message  响应体

post request is ok,param = post

一次完整 HTTP 请求所经历的步骤

当我们在 web 浏览器的地址栏中输入:www.baidu.com,然后回车,到底发生了什么?

  1. 由域名→ IP 地址 寻找 IP 地址的过程依次经过了浏览器缓存、系统缓存、hosts 文件、路由器缓存、 递归搜索根域名服务器(DNS解析)。
  2. 建立 TCP/IP 连接(三次握手具体过程)。
  3. 由浏览器发送一个 HTTP 请求。
  4. 经过路由器的转发,通过服务器的防火墙,该 HTTP 请求到达了服务器。
  5. 服务器处理该 HTTP 请求,返回一个 HTML 文件。
  6. 浏览器解析该 HTML 文件,并且显示在浏览器端。
  7. 服务器关闭 TCP 连接(四次挥手具体过程)。

Https

HTTP 协议运行在 TCP 之上,明文传输,客户端与服务器端都无法验证对方的身份。Https 是通过 SSL(Secure Socket Layer, 安全套接层 )或 TLS(Transport Layer Security, 安全层传输协议)的组合使用,加密 HTTP 的通信内容。属于通信加密,即在整个通信线路中加密。

HTTPS 采用共享密钥加密(对称)和公开密钥加密(非对称)两者并用的混合加密机制。若密钥能够实现安全交换,那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比,其处理速度要慢。

HTTP 的不足

  1. 窃听风险:通信使用明文(不加密),内容可能会被窃听;
  2. 冒充风险:不验证通信方的身份,因此有可能遭遇伪装;
  3. 篡改风险:无法证明报文的完整性,所以有可能已遭篡改;

两者区别

  1. 端口不同:Http 与 Http 使用不同的连接方式,用的端口也不一样,前者是80,后者是443;
  2. 资源消耗:和 Http 通信相比,Https 通信会由于加减密处理消耗更多的 CPU 和内存资源;
  3. 开销:Https 通信需要证书,而证书一般需要向认证机构购买;
  4. 如果对部署证书有兴趣可以看看:Docker通过Nginx,ACME快速部署证书

HTTPS 工作原理

【1】客户端发起 HTTPS 请求

用户在浏览器里输入一个 https 网址,然后连接到 server 的 443 端口。

【2】服务端的配置

采用 HTTPS 协议的服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面。

这套证书其实就是一对公钥和私钥,可以想象成一把钥匙和一个锁头,只是全世界只有你一个人有这把钥匙,你可以把锁头给别人,别人可以用这个锁把重要的东西锁起来,然后发给你,因为只有你一个人有这把钥匙,所以只有你才能看到被这把锁锁起来的东西。

【3】传送证书

这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间等等。

【4】客户端解析证书

由客户端的 TLS 来完成,首先会验证公钥是否有效,比如颁发机构,过期时间等等。如果发现异常,则会弹出一个警告框,提示证书存在问题。

如果证书没有问题,那么就生成一个随机值,然后用证书对该随机值进行加密,就好像上面说的,把随机值用锁头锁起来,这样除非有钥匙,不然看不到被锁住的内容。

【5】传送加密信息

用证书加密后的随机值,目的就是让服务端得到这个随机值,以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

【6】服务端解密信息

服务端用私钥解密后,得到了客户端传过来的随机值(私钥),然后把内容通过该值进行对称加密,所谓对称加密就是,将信息和私钥通过某种算法混合在一起,这样除非知道私钥,不然无法获取内容,而正好客户端和服务端都知道这个私钥,所以只要加密算法够厉害,私钥够复杂,数据就够安全。

【7】传输加密后的信息

服务段用私钥加密后的信息,可以在客户端被还原。

【8】客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息,于是获取了解密后的内容,整个过程第三方即使监听到了数据,也无法解密信息。

HTTPS 的缺点

  1. HTTPS 协议多次握手,导致页面的加载时间延长近 50%;
  2. HTTPS 连接缓存不如 HTTP 高效,会增加数据开销和功耗;
  3. SSL 涉及到的安全算法会消耗 CPU 资源,对服务器资源消耗较大;

————————————————

版权声明:本文为CSDN博主「九七年生于初夏」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/csp732171109/article/details/122608300

作者:易道云控

链接:https://www.jianshu.com/p/6153bf335d4b

来源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,793评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,567评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,342评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,825评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,814评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,680评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,033评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,687评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,175评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,668评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,775评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,419评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,020评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,206评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,092评论 2 351
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,510评论 2 343

推荐阅读更多精彩内容