一文拿下HTTP

HTTP

HTTP协议

是应用层使用最广泛的协议之一,从浏览器获取到网页,就是基于http

  • 浏览器和服务器之间的交互桥梁

  • 基于传输层的TCP协议来实现的,是一种无状态的应用层协议

    • 为啥是无状态的呢

      • 简化服务器端的处理逻辑:HTTP是无状态的,服务器不必保存客户端请求的状态,这样可以减少服务器存储空间的占用和处理复杂度,更容易扩展和管理系统
      • 支持多个请求同时进行:HTTP请求和响应式独立的,浏览器可以同时发送多个请求,提高网络通信的效率
  • 一文拿下HTTP_第1张图片

HTTP请求

  • 首行

    • 方法 + URL + 版本号
      一文拿下HTTP_第2张图片

      • 认识URL

        • URL的组成
          一文拿下HTTP_第3张图片

        • 最重要的四个部分

          • 域名/IP

          • 端口号

            • HTTP默认端口号80
            • HTTPS默认端口号443
          • 带层次的路径

          • 查询字符串(以键值对的方式来组织的)

        • 举个例子

          • 一文拿下HTTP_第4张图片
      • 方法

        • 一文拿下HTTP_第5张图片

          • GET请求

            • 使用场景

              • 在浏览器地址直接输入url
              • 点击收藏夹
              • html里的link、script、img、a…
              • 通过js来构造get(form标签)
            • 举个例子

              • 一文拿下HTTP_第6张图片
          • POST请求

            • 使用场景

              • 典型的就是登录操作,登录跳转的时候会设计POST
              • 传文件
          • GET 和 POST 的区别

            • GET和POST本质没有区别,大部分场景下能够互相替代,但是在适用情况下是有差异的

            • 传参方式不同

              • GET是习惯使用query string
              • POST是习惯使用body正文传参
            • 语义差别(使用场景上的不同)

              • GET一般用于从服务器获取数据
              • POST一般用于给服务器提交数据
            • 幂等

              • GET请求一般是获取数据,设置为幂等的,每次请求的数据是一样的
              • POST提交数据,每次提交的数据不同,所以是不幂等的
            • 缓存方面

              • GET可以缓存
              • POST一般不能缓存
            • 长度限制

              • GET请求一般有长度限制
              • POST请求一般没有长度限制
  • 请求头(header)

    • 构成
      一文拿下HTTP_第7张图片

      • Host

        • 描述了服务器所在的端口,用来描述最终访问的目标。这个内容大概率和URL中是一样的,也有一定情况是不同的
      • Content-Length

        • GET请求中没有这两个字段,POST中一定有
        • body的数据长度
      • Content-Type

        • body的数据格式
      • User-Agent(UA)

        • 描述了浏览器和操作系统的版本
        • 主要分为PC和移动端
      • Referer

        • 当前页面的来源
        • 如果直接通过地址栏输入地址、直接点击收藏夹,就没有referer
        • 用于
          一文拿下HTTP_第8张图片
      • Cookie

        • 本质上是浏览器给网址提供的 本地存储数据的机制

          • 网页是默认不允许访问计算机的硬盘的(为了保证安全,浏览器对于访问硬盘作出了明确的限制),但是我们有这个需求,所以就引入了cookie
          • 通过键值对的方式组织数据
        • cookie从哪来

          • 从服务器来,服务器来决定,浏览器的cookie要存什么
          • 浏览器通过HTTP响应报头部分(set-cookie字段)来知道自己要理解和存储的,下一次请求时就带上这个cookie
        • cookie在哪存

          • 可以认为存于浏览器,也可以认为存在硬盘中
          • cookie在存的时候,是按照浏览器+域名细分的
          • cookie的内容不仅有键值对,还有过期时间,越敏感的网站,过期时间越短
        • cookie要到哪去

          • 回到服务器里去
          • 客户端会通过cookie保存当前用户使用的中间状态,当客户端访问服务器的时候,就自动把cookie内容带入请求中,服务器就知道客户端什么样子
          • cookie就像是服务器在客户端的寄存处一样,用于服务器记录客户端的状态
        • cookie的工作原理

      • session

        • Session是什么

          • 除了将用户信息通过cookie存储在用户浏览器中,也可以利用session存储在服务器端,存储在服务器端的信息更加安全。 session可以存储在服务器上的文件、数据库或者内存中。可以将session存储在Redis这种内存型数据库中,效率会更高
        • Session工作原理
          一文拿下HTTP_第9张图片

          • 客户端登录完成之后,服务器会创建对应的 session,session 创建完之后,会把 session 的 id 发送给客户端,客户端再存储到浏览器中。这样客户端每次访问服务器时,都会带着 sessionid,服务器拿到 sessionid 之后,在内存找到与之对应的 session 这样就可以正常工作了
        • 使用session维护用户登录状态过程

          • 用户进行登录时,提交包含用户名和密码的表单,放入HTTP请求报文中

          • 服务器验证该用户名和密码,如果正确则把用户信息存储在Redis中,它在Redis中的key称为SessionID

            • SessionID的安全性问题,不能让它被恶意攻击者轻易获取,那么就不能产生一个容易被猜到的SessionID值。此外,还需要经常重新生成SessionID。在安全性要求高的场景,eg转账,除了使用Session管理用户状态,还要对用户进行重复验证,eg重新输入密码、短信验证码等方式
          • 服务器返回的响应报文的Set-Cookie首部字段包含了SessionID,客户端收到响应报文之后将该Cookie值存入浏览器中

          • 客户端之后对同一个服务器进行请求时会包含该Cookie值,服务器收到之后提取出Session ID,从Redis中取出用户信息,继续之前的业务操作

        • 如果客户端禁用了cookie,那么session还能用吗

          • 可以,Session的作用是在服务端来保持状态,通过sessionid来进行确认身份,但sessionid一般是通过Cookie来进行传递的。如果Cooike被禁用了,可以通过在URL中传递sessionid
      • cookie和session的区别

        • 为啥要有cookie和session

          • HTTP是无状态的,请求和响应都是独立的,一次会话中的多次请求时无感知的,如何解决这个问题呢?这就需要借助会话持久技术,常见的就是cookie和session

            • eg,用户进行登录操作的时候,切换到其他页面,服务器无法判断是哪个用户登录的,每次进行页面跳转的时候,都需要重新登录
        • 存储位置不同

          • cookie存储在客户端
          • session存放在服务端,session存储的数据比较安全
        • 存储的数据类型不同

          • 两者都是key-value的结构,cookie的value只能是字符串类型
          • session可以存储任意数据
        • 存储的数据大小限制不同

          • cookie大小受浏览器限制,很多是4k的大小
          • session理论上受当前内存的限制
        • 生命周期的控制

          • cookie的有效期可以设置较长时间
          • session的有效期比较短
  • 空行

    • 表示header的结束标记
  • 正文(body)

    • 如果是GET请求,一般没有body

    • 如果是POST请求,一般有body

    • body的数据格式

      • 根据请求头中的Content-Type字段来知道以何种方式解码

      • application/x-www-form-urlencoded

        • 原生form表单,不设置Content-Type属性的话,就默认以这种方式进行传输
      • multipart/form-data

        • 使用表单上传文件的时候,必须让表单的Content-Type 等于 multipart/form-data
        • 支持传输多种文件格式
      • application/json

        • 用得比较多,json字符串,支持格式化数据
      • text/xml

        • 一般用来传输xml格式的文件,这种数据格式

HTTP响应

  • 例如
    一文拿下HTTP_第10张图片

  • 首行

    • 版本号+状态码+描述码
      在这里插入图片描述

      • HTTP的状态码
        一文拿下HTTP_第11张图片

        • 200 OK

          • 成功
        • 404 NotFound

          • 访问资源不存在,在服务器中没找到
        • 403 Forbidden

          • 拒绝访问,没有权限
        • 302 Found

          • 3xx都是表示重定向
          • 重定向,类似呼叫转移
          • 这样的响应报文会在header里带个location属性,通过这个属性描述要跳转到哪个新地址
        • 500 Internal Server Error

          • 服务器内部错误(服务器代码抛异常了)
        • 504 Gateway timeout

          • 请求超时(响应时间太久,浏览器等不及了)
        • 一文拿下HTTP_第12张图片

  • header响应头

  • 空行

    • 表示header的结束标志
  • body

HTTP报文格式

  • 一文拿下HTTP_第13张图片

如何构造HTTP请求

对于GET

  • 地址栏直接输入

  • 点击收藏夹

  • html中的link script img a标签

  • form标签

    • 只能构造GET、POST,无法构造PUT、DELETE、OPTIONS等请求

      • GET请求
        一文拿下HTTP_第14张图片

      • POST请求
        一文拿下HTTP_第15张图片

Ajax构造http请求

  • 浏览器提供的一种通过js构造http请求的方式

  • html中,通过Ajax发起http请求后,不必等待服务器响应,就可以继续往下执行,等服务器响应回来,再由浏览器通知到我们的代码中

  • 代码中如何使用Ajax

    • js原生提供Ajax的api,但是很难用

    • jQuery提供的api,针对原生api的封装,简单很多

      • 是一个特殊的全局对象, j Q u e r y 的 a p i 都是以 是一个特殊的全局对象,jQuery的api都是以 是一个特殊的全局对象,jQueryapi都是以的方式引出的,只有一个参数,是一个js对象
        一文拿下HTTP_第16张图片
  • 跟form比起来,Ajax的优点

    • 支持PUT、DELETE方法
    • Ajax发送的请求可以灵活设置header
    • Ajax发送的请求的body也可以灵活设置

使用postman构造请求

  • 一文拿下HTTP_第17张图片

HTTP和HTTPS

区别

  • 两者默认端口不同

    • HTTP:80
    • HTTPS:443
  • URL前缀不同

    • HTTP 的 URL 前缀是 http://
    • HTTPS 的 URL 前缀是 https://
  • 安全性和资源消耗

    • HTTP 协议运行在 TCP 之上,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议,SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。
    • HTTP 安全性没有 HTTPS 高,但是 HTTPS 比 HTTP 耗费更多服务器资源

HTTPS加密

  • 为什么需要加密

    • 因为http的内容是明文传输的,明文数据会经过中间代理服务器、路由器、WiFi热点、通信服务运营商等多个物理节点,如果信息再传输过程中被劫持,传输的内容就完全暴露了。劫持者还可以篡改传输的信息不被双方察觉,这就是中间人攻击,所以我们需要对信息进行加密,最常用的就是对称加密
    • 加密流程
      一文拿下HTTP_第18张图片
  • 对称加密

    • 一个密钥,可以加密一段信息,也可以对加密后的信息进行解密,这就是对称加密
    • 但是对称加密怎么才能保证密钥只被传输双方知晓,同时不被别人知道呢?如果传输过程密钥被别人劫持到手,他就可以用密钥解开传输的任何内容了。如果浏览器预存了网站A的密钥,就可以确保不会有人知道密钥了,但是浏览器显然不能预存所有网站的密钥。所以我们就需要非对称加密
  • 非对称加密

    • 两把密钥:公钥和私钥,用公钥加密的内容只有私钥能解开,同时用私钥加密的内容只有公钥能解开

    • 只能保证单方向传输的安全性:服务器先把公钥以明文传输给浏览器,之后浏览器向服务器传数据前先用这个公钥加密好再传,然后服务器私钥解密。但是服务器到浏览器这个明文传输的阶段,公钥被中间人劫持了怎么办?他也能用公钥解密服务器传来的信息了,只能保证浏览器到服务器传输数据的安全性

    • 两组密钥

      • 服务器拥有公钥A和私钥A,浏览器拥有公钥B和私钥B
      • 浏览器把公钥B明文传输给服务器,服务器将公钥A明文传输给浏览器
      • 浏览器向服务器传输的内容用公钥A加密,服务器使用私钥A解密。服务器向浏览器传输的内容用公钥B加密,浏览器使用私钥B解密
    • 这样做的确可以,但是非对称加密算法非常耗时,对称加密快很多

  • 非对称加密+对称加密

    • 网站服务器拥有非对称加密的公钥A,私钥A
    • 浏览器向服务器请求,服务器把公钥A明文传输给浏览器
    • 浏览器随机生成一个用于对称加密的密钥X,并且使用公钥A加密传给服务器
    • 服务器拿到私钥A解密得到密钥X,这样双方都有密钥X,且别人都无法知道它,之后的数据都通过密钥X加密解密
  • 数字证书

    • 其实非对称加密+对称加密还是会遭到中间人攻击

      • 中间人把公钥A劫持,保存下来,并且将公钥A替换为自己伪造的公钥B
      • 浏览器生成一个用于对称加密的密钥X,用公钥B加密后传给服务器
      • 中间人劫持到后用私钥B解密得到密钥X,再用公钥A加密后传输给服务器
      • 服务器拿到后用私钥A解密得到密钥X
    • 数字证书

      • 根本原因是浏览器无法确认收到的公钥是不是服务器自己的,如何证明浏览器收到的公钥是网站服务器的呢?CA机构颁发“身份证”:数字证书

      • 网站在使用HTTPS前,需要向CA机构申领一份数字证书,其中包含持有者信息、公钥信息等

      • 如何防止数字证书被篡改?

        • 数字签名
          一文拿下HTTP_第19张图片

          • 制作过程

            • CA机构拥有非对称加密的私钥和公钥
            • CA机构对证书明文数据T进行hash
            • 对hash后的值用私钥加密,得到数字签名S
          • 验证过程

            • 拿到证书,得到明文T,签名S
            • 拿CA机构的公钥对S解密,得到S(是浏览器信任的机构,浏览器保留它的公钥)
            • 用证书指明的hash算法对明文T进行hash得到T
            • 对比T和S的值,如果相等则证书可信
          • 为什么制作签名的时候要hash一次

            • 非对称加密效率差,证书信息长,比较耗时。而hash后得到的是固定长度的信息,这样解密就快很多
        • 中间人有可能篡改吗?

          • 假如中间人篡改了原文,但是它没有CA机构的私钥,无法得到加密后的签名,就无法篡改签名,此时T和解密后S的值不同,就说明被篡改了,证书不可信
        • 中间人有可能把证书掉包吗

          • 证书包含网站A的信息,包括域名,浏览器把证书的域名和请求 的域名对比一下,就知道有没有掉包了

常见的加密算法

  • 对称加密

    • DES
    • AES
  • 非对称加密

    • RSA
    • DSA
    • ECC

HTTP的长、短连接

HTTP协议和TCP/ID协议的关系

  • HTTP的长连接和短连接本质上是TCP的长连接和短连接
  • HTTP属于应用层协议,在传输层使用TCP协议,在网络层使用IP协议
  • IP协议主要解决网络路由和寻址问题,TCP协议主要解决如何在IP层之上可靠地传输数据包,使得网络上接收端收到发送端所发出的所有包,并且顺序和发送顺序一致

如何理解HTTP协议是无状态的

  • 这里的无状态,指的是协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态
  • HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接

什么是长短连接

  • HTTP/1.0默认使用短连接

    • 短连接:三次握手建立连接,一次收发数据之后就进行四次挥手
  • HTTP/1.1起,默认使用长连接

    • 长连接:一次连接可以收发多条数据,只有超过一定的时间不再发送数据 才会断开连接
    • 使用长连接的HTTP协议,会在响应头加入:Connection:keep-alive

HTTP1.0 1.1 2.0的主要区别

一文拿下HTTP_第20张图片

你可能感兴趣的:(秋招复习,计算机网络,http,网络协议,网络)