首页 / 资讯中心 / 文章详情

Linux——HTTP协议与HTTPS协议

Linux——HTTP协议与HTTPS协议 ★ FEATURED ARTICLE
一、HTTP协议一什么是HTTP协议HTTP协议全名是超文本传输协议HTTP协议是一个应用层协议在传输层基于TCP协议实现的是一个简单的请求-响应协议客户端发送了一个请求服务端进行响应结束后连接断开二HTTP协议格式HTTP协议格式首行、头部、正文1.HTTP协议请求格式HTTP协议请求格式首行、头部、正文1首行包含三个要素请求方法、URL、xxx要素之间以空格进行间隔末尾以\r\n结尾。以GEThttps://www.baidu.com/s?wdC%2B%2BHTTP/1.1为例1请求方法GET告诉服务器我要请求获取一个资源HEAD与GET类似区别在于响应中不要实际的响应数据POST向服务器提交数据请求某个功能PUT提交数据给服务器请求某个功能DELETE告诉服务器要删除某个资源GET与HEAD的区别都是用于请求获取资源但是HEAD不要响应正文GET与POST的区别GET用于获取数据POST用于提交数据GET也能提交数据在URL中但是有长度限制4 或 8KBPOST提交的数据在正文中长度不受限制2URL统一资源定位符https://www.baidu.com/s?wdC%2B%2B此例子只含有部分要素全要素协议类型://用户名:密码域名或IP地址:端口号/资源路径?查询字符串#片段标识符红色部分是间隔符协议类型http超文本传输协议https加密的http协议用户名:密码处于弃用状态当前有些服务器已经不支持域名或IP地址用于定位网络上的服务器主机域名www.baidu.com最终还是要先转换为一个服务器IP地址再发起请求端口号用于定位指定主机上的处理进程HTTP协议默认是 80 端口HTTPS协议默认是 443 端口/资源路径用于定位服务器上的资源路径以/相对根目录起始查询字符串GET或HEAD请求时向服务器提交的数据以键值对的形式存在。格式keyvalkeyvalkeyval....URL编码URL的资源路径与查询字符串中可能存在特殊字符而这些特殊字符可能会与URL的间隔符产生冲突因此需要对URL进行编码处理将URL的资源路径与查询字符串中的特殊字符进行特殊处理编码方式将特殊字符的ASCII值转换为2个字符的16进制并以 % 作为前缀。不需要编码的特殊字符/、.、-、_、~、a~z、A~Z、0~9在资源路径中/不需要编码在查询字符串中/需要编码举例C%2B%2B是由 C 转换的以此为例C 不需要编码 的ASCII值为43转换为16进制就是 2B再加上 % 前缀最终C C%2B%2BURL解码解码方式逐字符进行遍历URL遇到 %就认为仅随其后的2个字符是需要解码的数据将这2个字符转化为十进制ASCII码就可以被解释成所对应的特殊字符举例C%2B%2B将 % 后的2个字符转化为十进制ASCII码2B的十进制为43所对应的特殊字符就是 最终C%2B%2B C片段标识符标识HTML网页内部位置打开网页后就可以直接跳转到指定位置2协议版本HTTP协议的发展历程HTTP/0.9不成熟的版本HTTP/1.0完善了协议格式首行、头部、正文新增了更多的请求方法GET、HEAD、POST新增并完善更多的头部字段对请求进行更加细致的描述HTTP/1.1性能上的改进连接方式实现了长连接管线化传输增加了更多的请求方法PUT、DELETE、....头部中增加了缓存管理HTTP/2.0性能上的改进使用二进制传输、头部压缩、多路复用的使用、解决了队头阻塞的问题、数据的服务器主动推送3.0弃用...HTTP/3.0性能上的改进传输层协议改用QUIC协议UDP头部压缩的优化连接迁移2头部组成是由一个个的键值对组成的格式key: val\r\nkey:val\r\n....典型请求头Host服务器地址信息User-Agent个人本地浏览器配置信息服务器可以进行个性化响应Referer当前请求的来源路径Accept客户端能够接收的相应类型正文类型、语言、压缩格式等Connection控制当前的连接方式closed短连接keep-alive长连接Content-Type正文类型决定了对端如何对正文进行解析处理Content-Length正文长度3正文提交给服务器的数据post、put、delete...注意get 方法没有正文头部与正文之间的间隔符\r\n与上一个头部字段末尾的\r\n共同组成\r\n\r\n标志着最后一个头部字段的结束2.HTTP协议响应格式HTTP协议响应格式首行、头部、正文1首行三个要素协议版本、响应状态码、状态码描述例如HTTP/1.1200OK格式以空格间隔以\r\n结尾响应状态码本质就是一个数字有五大类1xx一些描述或协议切换2xx标识本次请求成功被处理200完全成功传输文件时文件完整传输完成201创建成功206部分成功传输文件时发生断点续传文件部分内容传输成功3xx表示本次请求被重定向通常与响应头部字段中的 Location 搭配使用301永久重定向本次客户端请求了重定向的新链接后下次请求原资源直接请求新链接302临时重定向本子客户端请求了重定向的新链接后下次请求原资源使用老链接4xx用于表示客户端本次请求错误400客户端请求的语法错误服务器无法理解404请求的资源不存在5xx用于表示服务端本次处理错误500内部错误502网关无效504网关请求超时状态码描述文本字符串仅针对状态码进行文字描述没有其他作用2头部格式key: val\r\nkey:val\r\n....典型头部Location搭配3xx状态使用进行资源重定向Connection控制当前的连接方式closed短连接keep-alive长连接Content-Type正文类型决定了对端如何对正文进行解析处理Content-Length正文长度3正文响应给客户端的数据头部与正文之间的间隔符\r\n与上一个头部字段末尾的\r\n共同组成\r\n\r\n标志着最后一个头部字段的结束三Cookie、Session、Token1.Cookie机制由来HTTP协议是一种短连接、无状态协议意味着每次请求可能都是一个新连接这种设计用起来非常简单但是针对特殊场景例如身份识别就很麻烦因为服务端总是无法识别到客户端身份和状态。基于这个问题提出了 Cookie机制。概念Cookie 是HTTP协议的状态维护机制响应头部字段Set-Cookie用于向客户端返回一些需要保存在客户端本地并需要每次请求服务器时提交给服务器的数据请求头部字段Cookie用于将 Set-Cookie 保存的数据进行填充自动提交给服务器流程通过Cookie机制服务器就可以将客户端身份标识、状态标识放在 Set-Cookie 中返回给客户端客户端每次请求服务器的时候将这些信息通过 Cookie 提交给服务器服务器再取出请求头中的Cookie数据对客户端进行身份状态识别缺陷Cookie机制不够安全会导致在频繁的通信中持续将用户敏感信息暴露在外存在泄露隐私的风险并且存在客户端篡改信息的风险2.Session机制Session 机制就是在 Cookie 机制的基础上做的改进流程服务端保存客户端的敏感信息并生成一个会话ID通过Cookie机制返回给客户端客户端之后请求的时候将ssid提交给服务器服务器通过ssid查找Session会话找到客户端的身份信息进行识别这样做就避免了客户端篡改信息以及泄漏隐私的风险缺陷服务端负载大每一个登录用户服务器都要存一条 session 记录对于服务器的负载很大分布式多服务器时处理复杂如果项目部署多台服务器做负载均衡 用户第一次登录落在服务器 Asession 存在 A下次请求分到服务器 BB 没有这个 session用户就会掉线。 解决办法session 共享但是会增加额外开发成本并且服务器的负载很大3.Token机制核心把关键信息交给客户端在客户端本地进行存储。使用的头部字段Authorization流程服务器将客户端的身份状态信息使用hash计算、私钥加密等方法进行签名组成一个字符串返回给客户端客户端在下次请求服务器的时候将这串字符串放到Authorization头部中提交给服务器服务器使用hash对数据进行计算得到一个字符串然后使用公钥对末尾内容进行解密也得到一个字符串将两个字符串进行比较若一致则表示信息没有被篡改缺陷无法灵活的对Token进行生命周期管理解决方法在Token中增加过期时间不够灵活若要立即失效就需要在服务器上建立Token黑名单需要在服务器上保存黑名单refresh token机制access token访问鉴权token用于身份识别增加一个很短的过期时间refresh token用于获取新的access token的token长期有效服务器上对fresh token进行保存管理一旦删除了refresh token下次客户端通过refresh token请求服务器的时候就会失败二、HTTPS协议一什么是HTTPS协议1.本质底层还是HTTP协议但是在HTTP的基础上进行了加密处理2.SSL/TLS加密流程身份验证需要保证通信双方的身份是受信任的身份加密传输有非对称加密、对称加密、混合加密三种加密方式二传输加密1.对称加密加密和解密使用同一套密钥加密解密逻辑一致缺点密钥协商过程容易被监听窃取加密将毫无意义优点加密解密速度快2.非对称加密其中一方基于RSA、ECC、DH算法生成一对密钥私钥公钥私钥加密的数据只有公钥可以解密公钥加密的数据只有私钥能够解密有了非对称密钥通信前就可以将公钥交给对方对方发送数据的时候使用公钥加密优点不怕密钥被劫持监听安全性更高缺点加解密算法较为复杂加解密效率较低3.混合加密先使用非对称加密传输让双方协商生成对称密钥往后的通信使用对称密钥加密三身份验证加密传输只能保证数据不怕被监听劫持但是无法保证通信双方的身份是受信任的关键点需要有一个双方都信任的权威机构存在在双方之间做担保实现CA证书数字签名CA证书由权威机构颁发的一个用于进行身份证明的数字证书
阅读完成 · 觉得有帮助?
咨询建站