五千多字，图文并茂详解HTTP报文格式、请求响应头、cookie

2021-01-25  本文已影响0人  java小杰要加油
  • 靓仔靓女们大家好，我们又见面了，：java小杰要加油，这周来分享一篇关于HTTP协议相关的文章
  • 看完此文可以对
    • HTTP报文格式、HTTP各种请求头，HTTP响应码、 cookie属性以及HTTPS为什么安全（涉及到三种加密方式） 有个清晰的认知
  • 全文五千来字，强烈建议收藏，巩固基础
  • 若文中涉及到的知识点有所偏差的话，还请大佬们指出，小杰感激不尽，冲冲冲！~

HTTP简介

HTTP报文

  • 用于HTTP协议交互的信息叫做HTTP报文
  • 报文由报文首部和报文主体来组成，其中由空行分割
  • 请求报文和响应报文的报文结构不一样，其中最大的区别就是在报文首部中，各有各的特定的首部
image

HTTP请求报文结构

image

HTTP响应报文结构

image

注：若HTTP首部字段重复了的话，不同的浏览器处理机制不一样

  • 有些浏览器会优先处理第一次出现的字段
  • 有些浏览器会优先处理最后一次出现的字段

HTTP响应码

2xx 成功

2xx的响应结果就代表请求被正常处理了

3xx 重定向

3xx的响应结果就表明浏览器需要执行某些特殊的处理以正确处理请求

4xx 客户端错误

4xx的响应结果就表明客户端是发生错误的原因所在

5xx 服务器错误

5xx的响应结果就表明服务器本身发生错误

HTTP报文首部

HTTP1.1 规定了 以下47种首部字段

通用首部 （共9种）

首部字段 解释
1. Cache-Control 控制缓存的行为
2. Connection 逐跳首部、连接的管理
3. Date 创建报文的日期和时间
4. Pragma 报文指令
5. Trailer 报文末端的首部一览
6. Transfer-Encoding 指定报文主体的传输编码方式
7. Upgrade 升级为其他协议
8. Via 代理服务器的相关信息
9. Warning 错误通知

下面我们来看挑几个重要的属性来看下~

  1. Connection 他有两个作用
GET / HTTP/1.1
Upgrade: HTTP/1.1    // 就会把次字段删除后再从代理服务器转发出去
Connection: Upgrade   // 不再转发的首部字段名
image
  1. Pragme :是HTTP/1.1之前版本遗留的字段，仅仅是为了与HTTP/1.0向后兼容而定义
    • Pragm：no-cache :通用首部字段，在请求头中，表示所有的中间服务器不返回缓存的资源
    • 可是所有的中间服务器都以HTTP/1.1为基准的话，可以直接采用 Cache-Control：no-cache
    • 所以一般会发送两个字段Cache-Control：no-cache Pragm：no-cache

请求报文首部 （共19种）

首部字段 解释
1.Accrpt 用户代理可处理的媒体类型
2.Accrpt-Charset 优先的字符集
3.Accept-Encoding 优先的内容编码
4.Accept-Language 优先的语言（自然语言）
5.Authorization web认证信息
6.Expect 期待服务器的特定行为
7.From 用户的电子邮箱地址
8.Host 请求资源所在服务器
9.If-Match 比较实体标记（ETag）
10.If-Modified-Since 比较资源的更新时间
11.If-None-Match 比较实体标记（与If-Match相反）
12.If-Range 资源未更新时发送实体Byte的范围请求
13.If-Unmodified-Since 比较资源的更新时间(与If-Modified-Since相反)
14.Max-Forwards 最大传输逐跳数
15.Proxy-Authorization 代理服务器要求客户端的认证信息
16.Range 实体的字节范围要求
17.Referer 对请求中URI的原始获取方
18.TE 传输编码的优先级
19.User-Agent HTTP客户端程序的信息
  1. If-Match：只有当 If-Match 字段值跟 ETag 值匹配一致时，服务器才会接受请求
    • 它会告知服务器匹配资源所用的实体标记（ETag）值，这时服务器无法使用弱ETag值
    • 仅当两者一致时才会执行请求，否则返回412 Precondition Failed的响应
    • 还可以使用 * 号指定If-Match的字段值，如果这样的话，那么服务器将会忽略ETag的值，只要资源存在就处理请求。
  2. If-Modified-Since ：
    • 若资源更新时间确实在此字段指定时间之后的话，则处理该请求，否则返回304 Not Modified
    • 用于确认代理或客户端拥有本地资源的有效性，若想获取资源的更新日期时间的话可以通过确认首部字段Last-Modified来确定
  3. If-None-Match
    • 只有在If-None-Match的字段值与ETag值不一致时，才可以处理该请求，与前文中提到的If-Match作用相反
  4. If-Range
    • 他告知服务器若指定的If-Range字段值（ETag值或者时间）和请求资源的ETag值或时间一致时，则作为范围请求处理，否则，返回全体资源
  5. If-Unmodified-Since
    • 指定的请求资源只有在字段值内指定的日期时间之后未发生更新，才会执行这个请求，否则，返回412 Precondition Failed状态响应，与If-Modified-Since作用相反
  6. Max-Forwards
    • 每次请求转发时数值减一，直到0时返回响应
    • 有可能这个请求经过了多台服务器代理转发，如果突然间请求出现了什么问题导致转发失败，而客户端不知道，此时就可以用此属性来定位问题，这个时候我们就可以掌握一个出问题的转发路径，从而方便进一步的排查问题。
  7. Range:
    • 对于只需要获取部分资源的范围请求，Range字段可以指定获取资源范围Range: bytes=10001-20000
    • 例子中表示请求获取从第10001字节到20000字节的资源
    • 服务器处理请求后会返回206 Partial Content的响应。无法处理时，则会返回状态码200 OK的响应及其全部资源

响应报文首部 （共9种）

首部字段名 解释
1.Accept-Ranges 是否接受字节范围请求
2.Age 推算资源创建经过时间
3.ETag 资源的匹配信息
4.Location 令客户端重定向至指定URI
5.Proxy-Authenticate 代理服务器对客户端的认证信息
6.Retry-After 对再次发起请求的时机要求
7.Server HTTP服务器的安装信息
8.Vary 代理服务器缓存的管理信息
9.WWW-Authenticate 服务器对客户端的认证信息
  1. Accept-Ranges
    • Accept-Ranges：bytes 可以处理范围请求
    • Accept-Ranges：none 不可以处理范围请求
  2. Age
    • 可以告知客户端，源服务器多久之前创建了资源，单位是秒
    • 若创建该响应的是缓存服务器，则Age值是指缓存后的响应再次发起发起认证到认证完成的时间值。代理创建响应时必须加上首部字段Age
  3. ETag

    它是一种可将资源以字符串形式做唯一标识的方式，服务器会为每份资源分配对应的ETag值,资源被更新时，ETag值也会被更新，并没有统一的算法规则，而是由服务器来分配

    • 强ETag：无论实体发生多么细微的变化都会改变其值
    • 弱ETag：只用于提示资源是否相同，只有资源发生了根本的改变才会改变ETag值，这时会在字段值最开始加W/,
      ETag：W/"XXX"
  4. Location
    • 使用该响应字段可以将响应接收方引导至某个与请求的URI位置不同的资源
    • 基本上，该字段配合3XX，Redirection的响应，提供重定向的URI
  5. Vary

    首部字段vary可对缓存进行控制，源服务器会向代理服务器传达关于本地缓存使用方法的命令

    • 当代理服务器接收到服务器返回包含Vary指定项的响应后，仅对请求中含有相同Vary指定首部字段的请求返回缓存
    • 即使对相同资源发起请求，但是由于Vary指定的首部字段不相同，因此必须从源服务器重新获取资源
    • 例如下面这个，如果使用的Accept-Language：en-us字段的值相同，那么直接从缓存返回响应，否则从源服务器请求资源后再返回响应
      image

实体报文首部 （共10种）

首部字段名 解释
1.Allow 资源可支持的HTTP方法
2.Content-Encoding 实体主体适用的编码方式
3.Content-Language 实体主体的自然语言
4.Content-Length 实体主体的大小（单位：字节）
5.Content-Location 代替对应资源的URI
6. Content-MD5 实体主体的报文摘要
7. Content-Range 实体主体的位置范围
8. Content-Type 实体主体的媒体类型
9.Expires 实体主体过期的日期时间
10.Last-Modified 资源的最后修改日期时间

其他字段（cookie等）

cookie

  • 注 : 文中例子中的各种请求，报文，均来自 京东物流官网
  • ps：小杰个人挺喜欢JDL的标语的，有速度，更有温度，祝JDL越来越好！
image

set-cookie

属性 解释
NAME=VALUE 赋予Cookie的名称和其值（必需项）
expires = DATE Cookie的有效期（若不指定则默认为浏览器关闭为止）
path=PATH 将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domin=域名 作为Cookie适用对象的域名（若不指定则默认为创建Cookie的服务器域名）
Secure 仅在HTTPS安全通信时才会发送Cookie
HttpOnly 加以限制，使Cookie不能被JS脚本访问，主要目的是为了防止跨站脚本攻击（Cross Site Scripting，XSS）对cookie的窃取

谷歌浏览器控制台查看cookie

image image image image

因为这个属性JSESSIONID比较重要，存储的是sessionId，这个要是被别人拿到的话，别人就可以冒充我在网站上做某些事情了，像我自己一样请求某些数据了

postman 模拟拿到cookie后发送请求

image image

我把网页上的cookie拿下来，放到postman里测试，发现和我自己在网站上请求数据是一样的

cookie存储的地方，清理缓存到底是清理什么？

清理缓存主要就是清理cookie,抹去自己登陆痕迹以及浏览器中的资源缓存，重新请求网站资源

image image image

HTTP 与 HTTPS

HTTP不足

HTTPS结构

HTTPS是身披SSL（Secure Socket Layer）外壳的HTTP

image

对称加密原理

image
  • 客户端和服务端之间的共享密钥的传送问题也是一个问题，如果能够安全传送不被截获的话，那岂不是数据也可以安全的传送到不被截获？鸡生蛋蛋生鸡的问题。
  • 图中客户端和服务端传输加密数据的时候，如果双方的共享密钥泄露的被黑客截取到的话，黑客就可以用它来解开这加密的数据，所以对称加密不安全

非对称加密原理（公开密钥加密）

image
  • 问题就是，从服务端发送给客户端数据时无法保证数据的安全性，因为此时有可能黑客截获到了公钥，对私钥加密的数据进行了解密
  • 服务器端为什么不发送用公钥加密的数据？因为客户端没有私钥，无法解密。

混合加密原理

聪明的大佬们用两种加密算法混合了一下

image

我曾经以为这样就万无一失了，文章也就到此结束了，可以和血包杀手愉快的timi了，可是，你有没有听说过，中间人攻击？

中间人攻击

黑客拦截”用公开加密密钥机密后的共享密钥“后不是解密不了吗，好，那我就不拦截这个了，我拦截第一个请求好吧，我拦截服务端传给你的公开密钥，我拦截到了，我再给你个假的，（像极了《让子弹飞》中，张麻子与马邦德的关系，出任鹅城县长）。从根上就伪装成你，以后就等于我是个中间人（中转站），所有的请求，数据都要经过我，那我就可以记录下来其中你的敏感数据，可怕。

image

数字证书

写在最后

总结

  • 此文章从HTTP报文结构开始，到HTTP首部，到返回状态码，到cookie，再延伸到HTTPS加密方式，每一部分都进行了详细的介绍，希望对大家有用！

絮絮叨叨

若文章有误欢迎指出，靓仔靓女们，我们下篇文章见，关注我，开启我们的故事

上一篇 下一篇

猜你喜欢

热点阅读