ThankNeko's Blog ThankNeko's Blog
首页
  • 操作系统

    • Linux基础
    • Linux服务
    • WindowsServer笔记
    • Ansible笔记
    • Shell笔记
  • 容器服务

    • Docker笔记
    • Kubernetes笔记
    • Git笔记
  • 数据库服务

    • MySQL笔记
    • ELK笔记
    • Redis笔记
  • 监控服务

    • Zabbix笔记
  • Web服务

    • Nginx笔记
    • Tomcat笔记
  • 数据处理

    • Kettle笔记
  • Python笔记
  • Bootstrap笔记
  • C笔记
  • C++笔记
  • Arduino笔记
  • 分类
  • 标签
  • 归档
  • 随笔
  • 关于
GitHub (opens new window)

Hoshinozora

尽人事,听天命。
首页
  • 操作系统

    • Linux基础
    • Linux服务
    • WindowsServer笔记
    • Ansible笔记
    • Shell笔记
  • 容器服务

    • Docker笔记
    • Kubernetes笔记
    • Git笔记
  • 数据库服务

    • MySQL笔记
    • ELK笔记
    • Redis笔记
  • 监控服务

    • Zabbix笔记
  • Web服务

    • Nginx笔记
    • Tomcat笔记
  • 数据处理

    • Kettle笔记
  • Python笔记
  • Bootstrap笔记
  • C笔记
  • C++笔记
  • Arduino笔记
  • 分类
  • 标签
  • 归档
  • 随笔
  • 关于
GitHub (opens new window)
  • 操作系统

  • 虚拟化服务

  • 数据库服务

  • 监控服务

  • Web服务

    • Nginx笔记

      • HTTP/HTTPS介绍
        • HTTP协议
          • HTTP介绍
          • 用户访问网站的流程
          • HTTP版本
          • HTTP报文
          • HTTP常见状态码
          • HTTP协议资源
        • Cookie与Session
          • Cookie
          • Session
          • Coockie和Session区别
          • Token
        • 网站质量评测方法
          • IP
          • PV
          • UV
          • 网络的并发
        • HTTPS协议
          • HTTPS介绍
          • HTTP的DNS劫持篡改问题
          • SSL/TLS协议
          • CA机构
          • 数字证书
          • 证书签发过程
          • 证书验证流程
          • 签名的作用
          • 证书信任链
          • 证书类型
          • HTTPS注意事项
      • Nginx介绍与部署
      • Nginx配置与常用模块
      • Nginx负载均衡
      • Nginx优化
    • Tomcat笔记

  • 数据处理

  • Ops
  • Web服务
  • Nginx笔记
Hoshinozora
2023-03-26
目录

HTTP/HTTPS介绍

# HTTP协议

# HTTP介绍

  • HTTP协议即超文本传输协议(HyperText Transfer Protocol),它是一个基于请求响应的应用层协议,通常工作在TCP之上,用来规定服务端和浏览器之间数据交互的格式。
  • 我们平时使用浏览器访问网站,实际就是使用HTTP协议来和WEB服务器进行通信、获取资源的。
  • HTTP协议有以下四个特性:
    • 基于请求/响应,一次请求对应一个响应。
    • 基于TCP/IP的应用层协议,数据传输通过TCP/IP协议实现。
    • 无状态,不保存任何一次请求响应的状态,每次请求都是一次新的请求。
      • 为了能够保存状态就有了Cookie、Session技术。
    • 无连接,每次请求响应之后就断开TCP连接。
      • 这种特性在网站资源非常多的情况下会多次建立断开TCP连接,会造成资源浪费,所以在HTTP1.1及其之后的版本得到了改善,可以建立长连接。

# 用户访问网站的流程

  1. 客户端 - 浏览器输入网址后单击回车,例如:https://www.baidu.com/。
  2. 客户端 - 完成域名的解析过程(DNS),获得与域名对应的实际服务器IP。
  3. 客户端 - 请求网站服务器,与网站服务器建立TCP连接,然后发送HTTP请求报文。
  4. 服务端 - 响应客户端请求,返回HTTP响应报文。
  5. 客户端 - 浏览器渲染HTML代码,看到网站页面内容。
  6. 客户端 - 结束访问网站过程,断开TCP连接。

# HTTP版本

  • HTTP/1.0 - TCP短连接
    • 一次请求和响应就断开连接,也就是客户端收到响应数据后,会立刻断开TCP连接。
    • 对于大型网站来说,访问速度会非常慢。
  • HTTP/1.1 - TCP长连接
    • 一个连接能够进行多次请求响应,按空闲时间断开连接。
    • 客户端无请求时间超过设定时间后,服务端主动断开TCP连接。计时期间客户端再次请求服务端资源会刷新超时时间计时。
  • HTTP/2 - TCP长连接优化
    • 在HTTP/1.1的基础上提高用户并发访问的效率。

# HTTP报文

  • HTTP中有两种报文,请求报文和响应报文,所谓报文实际就是特定格式的数据。
  • HTTP请求报文是客户端向服务端请求资源使用的。
  • HTTP响应报文是服务端向客户端返回资源使用的。

# HTTP请求报文结构

# HTTP报文实际上是由一行行的字符串组成的,每行字符串的末尾用\r\n分隔。
# 例如:
POST /user/ HTTP/1.1\r\nHost: test.com\r\nUse-Agent: Chrome\r\n\r\n{"username": "test", "password": "123456"}

# 实际就是:
POST /user/ HTTP/1.1
Host: test.com
Use-Agent: Chrome

{"username": "test", "password": "123456"}
1
2
3
4
5
6
7
8
9
10
  • 请求首行
    • 请求方法
      • 请求对资源进行的操作,例如:GET、POST、PUT、DELETE。
    • 请求资源
      • 要操作的资源,指定资源路径。
    • 请求协议
      • 使用的HTTP的版本信息。
  • 请求头
    • 客户端或请求的资源相关的信息,格式为键值对。
    • 常见请求头
      • Accept - 请求的资源文件类型,例如:gif、jpeg、txt。
      • Accept-Language - 请求的语言类型,例如:zh-cn。
      • HOST - 请求的主机信息。
      • Use-Agent - 请求的用户代理程序信息 (流览器等)。
  • 空行
    • 用于分隔请求头信息和请求体信息。
  • 请求体
    • 需要提交给服务端的数据,另外使用GET方法时一般没有请求体。

# HTTP响应报文结构

  • 响应首行

    • 请求协议
      • 使用的HTTP的版本信息。
    • 状态码信息
      • 请求对应的响应状态码,描述请求是否成功、失败等。
  • 响应头

    • 服务端或响应的资源相关的信息,格式为键值对。
    • 常见响应头
      • server - 使用的网站服务与其版本,例如:Nginx/1.6.2,但为了安全一般会隐藏。
      • Date - 发送响应报文的时间
      • Content-Type - 响应的资源文件类型
      • charset - 响应的字符集编码类型
  • 空行

    • 用于分隔响应头信息和响应体信息。
  • 响应体

    • 响应返回的实际数据,例如:html代码、图片字节集等。

# HTTP常见状态码

  • 20 开头表示请求成功
    • 200 OK - 服务器正常返回。
  • 30 开头表示跳转
    • 301 - 永久跳转。
      • 第一次请求链接进行跳转之后,客户端会记录跳转信息,之后的跳转都由客户端完成,不经过服务端,就算服务端修改了跳转也一样,所以是永久跳转。
    • 302 - 临时跳转。
      • 每一次请求链接进行跳转,都需要经过服务端,客户端不保存跳转信息。
  • 40 开头表示请求失败
    • 403 Forbidden - 禁止访问。
      • 禁止访问,虽然请求合法,但由于服务器预先设置的规则而拒绝响应这个客户端请求。如非专门配置,则一般是由于资源所在目录权限配置不当导致。
    • 404 Not Found - 资源不存在。
      • 服务器找不到客户端请求的指定页面,一般是由于客户端请求了服务器上不存在的资源。
  • 50 开头表示服务器相关的错误
    • 500 Internal Server Error - 内部服务器错误
      • 内部服务器错误,服务器遇到了意料之外的情况,不能完成客户端的请求。这是一个比较笼统的报错,一般是由服务器的设置或内部程序问题导致。
    • 502 Bad Gateway - 坏的网关
      • 一般是代理服务器请求后端服务时,后端服务不可用或没有完成响应网关服务器,这通常为WEB服务节点出问题所致,反向代理服务器无法与WEB服务节点服务器建立联系。
    • 503 Service Unavailable - 服务当前不可用
      • 服务当前不可用,可能是服务器超载或者停机维护所导致的,或者是反向代理服务器后面没有可以提供服务的节点。
    • 504 Gateway Timeout - 网关超时
      • 网关超时,一般是网关代理服务器请求后端服务时,后端服务没有再特定的时间内完成处理请求,多数是服务器过载导致没有再指定的实际内返回数据给前端代理服务器。

# HTTP协议资源

  • 资源定位

    • 我们想要通过HTTP协议来访问指定资源,就需要通过URL和URI来定位该资源。

    • URL即统一资源定位符(Uniform Resource Location),一般域名后第一个斜线之前的信息为URL。

    • URI即统一资源标识符(Uniform Resource Identifier),一般域名后第一个斜线及其之后的信息为URI。

    • 他们是一个相对的概念,URL是URI的资源定位,URI是URL的资源标识。例如:

      # 对于【https://baidu.com】来说【/jpg/test.jpg】是URI
      # 因此【https://baidu.com/jpg/test.jpg】即是URL又是URI
      链接为:https://baidu.com/jpg/test.jpg
      URL为:https://baidu.com
      URI为:/jpg/test.jpg
      
      1
      2
      3
      4
      5
    • 但现实中并没有区分那么开,一般都把一串链接叫做URL。

  • 静态资源

    • 静态资源是不会经常变动更新的资源,如文本、图片、视频、音频等。
    • 他的请求过程是:客户端请求静态资源,服务端返回静态资源。
    • 优点:
      • 容易被搜索引擎收录(容易被用户搜索到)。
      • 当客户端请求时,服务端可直接从磁盘中返回数据,不需要做任何解析,响应效率高。
      • 可以做各种静态资源缓存,提高网站访问速度。
    • 缺点:
      • 没有数据库的支持,网站制作与维护工作量较大,当网站信息量很多时,完全依靠静态网页比较困难。且网页交互性较差,在功能实现方面有较大限制。
  • 动态资源

    • 动态资源就是会动态变动的资源,如asp、php、js、do等。
    • 他的请求过程是:客户端请求动态资源,服务端查询对应数据库后进行解析最终得到动态资源,然后再将动态资源返回给客户端。
    • 优点:
      • 它一般以数据库作为基础,可降低网站维护的工作量。
    • 缺点:
      • 动态资源不便于搜索引擎的收录,所以一般还会使用伪静态来将动态资源伪装成静态资源。
      • 接收到用户请求后,需要让动态服务和数据库服务进行处理,然后才能响应请求,响应效率慢。
      • 动态资源因为是经常变动的,所以无法进行资源缓存。

# Cookie与Session

# Cookie

  • Cookie是服务端在客户端上进行临时或永久保存数据的技术,它可以用于存储一些用户状态、信息等在客户端。它的格式一般为键值对,可以定义多个。
  • Cookie实现用户登录流程例子:
    • 用户登录成功之后,服务端根据用户登录信息产生一个加密的字符串Cookie。
    • 服务端将Coockie发给客户端保存,之后客户端访问服务端的时候,都携带该Cookie。
    • 服务端就可以通过该Cookie结合Session来进行校验,来判断请求是否合法。

# Session

  • Session是服务端在其本地上进行临时或永久保存数据的技术,它可以用于存储一些用户状态、信息等在服务端。它的格式一般为键值对,可以定义多个。

# Coockie和Session区别

  • 两者并无太大区别,都是用于保存状态用的。
  • 区别仅在于一个存储在浏览器客户端,一个存储在服务端。

# Token

  • Token是一种认证方式,该方式可以仅在客户端保存Cookie即可进行用于验证,而无需用Session在服务端保存数据,可以节省服务器资源。
  • Session数据是保存在服务端的,在用户量大时会很消耗系统资源,此时就可以用Token方式进行用户验证。
  • 实现方式
    • token不再将信息保存到服务端,而是对用户信息进行自定义的加密。
    • 然后再将加密前的用户信息和加密后的信息拼接在一起,发给浏览器保存,服务端则什么都不存。
    • 当客户端第二次访问时,服务端拿到token,然后会进行拆分,拿到token中未加密的用户信息。
    • 然后再对其以相同的方式加密,再将其加密后的结果,和token加密的部分进行比对校验。
    • 如果两者符合,说明请求是真实的,而非伪造的。

# 网站质量评测方法

# IP

  • 对站点中访问用户的独立IP地址数进行统计。
  • 一般仅做参考,NAT技术原因,一个局域网内的多个用户访问只会被算作一个IP访问。且重新拨号也会造成IP改变。

# PV

  • PV即页面浏览量(page view),对一个页面的被访问次数进行统计。
  • 一般仅做参考,用户每刷新一次PV也会增加,用户可能会收藏,然后重复访问。

# UV

  • UV即独立访客(unique visitor),利用Cookie开进行统计。
  • 一般记录1天内的访问,1天内重复访问多次,也只记录为1次访问。

# 网络的并发

  • 网站服务器每秒能够响应的最大用户请求数。
  • 网站服务器在单位时间内能够处理的最大连接数。

# HTTPS协议

# HTTPS介绍

  • HTTPS协议实际就上是HTTP + TLS/SSL的网络协议,它在HTTP的基础上通过TLS/SSL协议进行传输加密和身份认证来保证传输过程的安全性。
  • 它用于保证HTTP报文在传输过程中的数据保密性、数据完整性,可以防止数据泄露、数据篡改等问题。

# HTTP的DNS劫持篡改问题

  • HTTP报文在网络中是以明文形式传输的,但明文的报文可能会遭到劫持篡改等问题,例如:传输数据泄露、页面被添加恶意广告等。
  • DNS劫持过程
    • 恶意DNS服务器会把用户的请求解析到一个代理服务器上。
    • 在请求通过代理服务器时,代理服务器会根据请求报文中的地址访问真正的网站。
    • 代理服务器获取到网站响应的报文后,就可以篡改真正的网站,添加一些广告代码到网站代码中。
      • Nginx中通过sub_filter '原内容' '替换内容';就能实现。
    • 然后代理服务器再将篡改过的响应报文返回给用户,最终就实现了劫持篡改。
  • 防止DNS劫持方法
    • 服务端网站配置HTTPS,HTTPS在传输时数据就会被加密,所以可以防止劫持后被篡改。
    • 用户使用正规的DNS服务器。
    • 用户配置使用本地DNS解析。

# SSL/TLS协议

  • SSL/TLS协议提供数据机密性和数据完整性,以保证客户端和服务端在网络通信时的安全性,使用SSL/TLS协议可以确保数据安全地通过网络进行传输。
  • TLS是SSL的新版,TLS协议是在SSL协议的基础上进行改进升级的,因为改动很多所以重新起了个名字叫TLS。

# CA机构

  • 为了让服务端的公钥被大家信任,服务端的证书都是由CA也就是证书认证机构(Certificate Authority) 进行签名的。
  • CA就是网络世界里的公安局、公证中心,具有极高的可信度,所以一般由它来给各个公钥签名,而值得信任的一方签发的证书,那证书也必然是会被信任的。
  • 之所以要签名,是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改,签名的方式在下文会提到。

# 数字证书

# 数字证书的结构

  • 公钥、持有者信息、证书认证机构(CA)的信息、证书有效期、还有一些其他额外信息。
  • 最后是证书的签名,也是证书用来保证安全性重要的东西。
    • 证书指纹是用指纹算法(Hash算法) 对除了证书签名外的整个证书的内容进行Hash,所得到的Hash值内容。
    • 证书签名是用CA机构的私钥来对"证书指纹+指纹算法"进行加密,所得到的加密值内容。

# 数字证书的作用

  • 用来提供给客户端认证公钥持有者(服务端)的身份,如果验证通过则表示可信,则客户端会使用证书上的公钥加密一个随机字符串作为对称密钥发给服务端,服务端收到后用私钥进行解密得到对称密钥,之后的传输就会用对称密钥进行加密,可以防止中间人劫持并篡改站点内容。

# 证书签发过程

image-20230326153313690

  • 首先CA会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包,然后对这些信息进行加密算法进行Hash,得到一个Hash值 (指纹)。
  • 然后CA会使用CA自己的私钥将"使用的加密算法+得到Hash值"进行加密,生成证书签名。
  • 最后将其作为证书签名添加在证书上,也就是CA对证书做了签名,形成数字证书。
  • 申请好之后,CA机构会将私钥、数字证书(包含公钥)发送给申请人。
  • 然后申请人需要将私钥、证书(包含公钥),部署到WEB服务器并进行相关配置。

# 证书验证流程

image-20230326152745194

  1. 客户端向服务器请求HTTPS连接。

  2. 服务器确认并返回证书 (证书含有公钥)。

  3. 客户端验证CA证书是否为合法证书。

    • 首先客户端会使用CA的公钥来解密证书签名,从而获得该证书的指纹H1和指纹算法。
    • 之后客户端会使用得到的指纹算法,将电子证书的内容进行一次Hash,得到Hash值H2。
    • 然后浏览器会比较H1和H2是否一致,如果一致则为可信赖的证书,否则为不可信证书。
  4. 如果证书的验证结果为合法,客户端就会生成一个随机字符串K作为对称密钥,并使用证书中的服务器公钥加密后发给服务器。

  5. 服务端接收到之后使用私钥解密出随机字符串K。

  6. 此后客户端与服务端之间的通信,就会使用对称加密算法密钥K进行加密。

# 签名的作用

  • 防止数字证书被中间人修改
    • 如果中间人修改了证书内容,那么客户端计算的Hash值会与指纹不一致,就会验证失败。
    • 同时中间人也不可能在修改证书内容的同时将电子签名也修改,因为电子签名是用CA的私钥加密的,中间人不可能有CA的私钥,如果强行使用自己的私钥重新得到电子签名,那么客户端使用CA公钥是无法解密电子签名的。
  • 防止数字证书被中间人替换
    • 电子证书中是有证书的持有者的,通过对比证书上的URL和我们请求的URL是否相同,我们还是可以判断当前证书是不是服务器发的证书。

# 证书信任链

# 介绍

  • 事实上证书的验证过程中还存在一个证书信任链的问题,因为我们向CA申请的证书一般不是根证书签发的,而是由中间证书签发的,比如百度的证书的层级有三级。
  • 这是为了确保根证书的绝对安全性,将根证书隔离地越严格越好,不然根证书如果失守了,那么整个信任链都会有问题。

image-20230326153251765

# 验证方式

image-20230326153442693

  • 简而言之就是,操作系统或浏览器信任了根证书A,根证书A又信任了中间证书B,中间证书B又信任了服务器证书C,所以浏览器也会信任服务器证书C。
  • 客户端收到服务器证书后,发现这个证书的签发者不是根证书,就无法根据本地已有的根证书中的公钥去验证服务器证书是否可信。
  • 于是,客户端根据服务器证书中的签发者,找到该证书的颁发机构,然后向该机构请求它自己的证书,一般叫做中间证书。
  • 请求到中间证书后,浏览器发现该中间证书的上级证书没有再上级的签发机构,说明它是根证书,也就是自签证书。
  • 浏览器会检查此证书有否已预载于根证书清单上,如果有,则可以利用根证书中的公钥去验证中间证书,如果发现验证通过,就认为该中间证书是可信的。
  • 中间证书被信任后,就会使用中间证书中的公钥去验证服务器证书的可信性,如果验证通过,就可以信任该服务器证书。

# 验证例子

  • 客户端收到 baidu.com 的证书后,发现这个证书的签发者不是根证书,就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是,客户端根据 baidu.com 证书中的签发者,找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2",然后向 CA 请求该中间证书。
  • 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2" 证书是由 “GlobalSign Root CA" 签发的,由于 “GlobalSign Root CA" 没有再上级签发机构,说明它是根证书,也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上,如果有,则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2" 证书,如果发现验证通过,就认为该中间证书是可信的。
  • “GlobalSign Organization Validation CA - SHA256 - G2" 证书被信任后,可以使用 “GlobalSign Organization Validation CA - SHA256 - G2" 证书中的公钥去验证 baidu.com 证书的可信性,如果验证通过,就可以信任 baidu.com 证书。

image-20230326153450981

# 证书类型

  • DV域名型
    • 免费,一般用于个人站点和应用。浏览器会显示小锁标志,保护1个域名。
  • OV企业型
    • 收费,一般用于中小型企业站点。浏览器会显示小锁标志,保护5个域名。
  • EV增强型
    • 收费,一般用于大型企业和政府机构。浏览器会显示小锁标志+HTTPS+公司名称,保护通配符域名。

# HTTPS注意事项

  • 证书不支持续费,证书到期需要重新申请并进行替换。
  • 证书不支持三级域名解析,如test.test.baidu.com。
  • 浏览器中证书图标显示绿色,说明整个网站的url都是HTTPS。
  • 浏览器中证书图标显示黄色,说明网站代码中包含http的不安全连接。
  • 浏览器中证书图标显示红色,说明证书过期或者是假的。
#Web#HTTP#HTTPS#SSL/TLS
Zabbix功能配置
Nginx介绍与部署

← Zabbix功能配置 Nginx介绍与部署→

最近更新
01
二〇二五年四月十七日随笔
04-17
02
二〇二五年四月十六日随笔
04-16
03
二〇二五年四月九日随笔
04-09
更多文章>
Theme by Vdoing | Copyright © 2022-2025 Hoshinozora | MIT License
湘ICP备2022022820号-1
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式