Java开发必会的应用层协议 - HTTP/HTTPS1. HTTP的大概理解1.1 HTTP的概念HTTP 诞生与1991年. 目前已经发展为最主流使用的一种应用层协议. 最新的 HTTP 3 版本也正在完善中, 目前Google / Facebook 等公司的产品已经支持了. HTTP 往往是基于传输层的 TCP 协议实现的. (HTTP1.0,HTTP1.1, HTTP2.0 均为TCP, HTTP3 基于UDP实现) 目前我们主要使用的还是 HTTP1.1 和HTTP2.0 . 当前课堂上讨论的 HTTP 以 1.1 版本为主.HTTP采用一问一答模式的协议客户端发一个请求服务器就返回一个响应请求和响应一一对应。我们平时打开一个网站, 就是通过 HTTP 协议来传输数据的. 当我们在浏览器中输入一个 搜狗搜索的 “网址” (URL) 时, 浏览器就给搜狗的服务器发送了一个 HTTP请求, 搜狗的服务器返回了一个 HTTP 响应网络通信中也有其他的模型多问一答主要用于上传大文件一问多答下载大文件多问多答远程控制 eg.todesk1.2 HTTP的报文格式为了学习HTTP的报文格式我们需要使用抓包工具Fidder这是一种代理工具下面我来解释一些代理其中我的助手就是正向代理代表我客户端干活1.2.1 抓包工具的原理Fiddler 相当于一个 “代理”.浏览器访问 sogou.com 时, 就会把 HTTP 请求先发给 Fiddler, Fiddler 再把请求转发给 sogou 的服务器. 当 sogou 服务器返回数据时, Fiddler 拿到返回数据, 再把数据交给浏览器. 因此 Fiddler 对于浏览器和 sogou 服务器之间交互的数据细节, 都是非常清楚的.1.2.2 抓包结果HTTP请求报文格式HTTP响应报文格式HTTP文本请求/响应协议格式总结2. 针对抓包结果分析每一部分2.1 URLurl可以描述网络上的唯一资源所在位置如果大家学过jdbc一定见过 JDBC 连接 MySQL 数据库的 URL 字符串jdbc:mysql://127.0.0.1:3306/java113?characterEncodingutf8useSSLfalse下面我们对于这个字符串进行分析我们再来看一个访问搜狗服务器的url2.2 URL encode像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义.进行转义的目的一个中文字符由 UTF-8 或者 GBK 这样的编码方式构成, 虽然在 URL 中没有特殊含义, 但是仍然需要进行转义. 否则浏览器可能把 UTF-8/GBK 编码中的某个字节当做 URL 中的特殊符号我们可以利用UrlEncode编码工具进行对于字符的转义ulrencode把数据的二进制内容每个字节取出来用16进制表示前面加上%1Byte8bit2个16进制数因此转义之后的结果是%2b2.3 认识 “方法” (method)即这次请求要干什么其中GET和POST这两个就是最常见的请求其中GET一般用来获取html,获取css,获取js等操作POST一般用来上传文件2.3.1 GET 方法GET 是最常用的 HTTP 方法. 常用于获取服务器上的某个资源.在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求.另外, HTML 中的 link, img, script 等标签, 也会触发 GET 请求用fiddler捕获的css页面用fiddler捕获的js页面GET 请求的特点• 首行的第一部分为 GET• URL 的 query string 可以为空, 也可以不为空.• header 部分有若干个键值对结构.• body 部分为空.2.3.2 POST 方法POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面).通过 HTML 中的 form 标签可以构造 POST 请求, 或者使用 JavaScript 的 ajax 也可以构造 POST 请求eg. 这是向山东大学信息化公共服务平台service.sdu.edu.cn发起的同域 AJAX 异步 HTTP POST请求目标接口为/tp_up/up/subgroup/getUsedAppsList核心用于获取用户已使用的应用列表请求格式规范且为同域合法请求POST 请求的特点• 首行的第一部分为 POST• URL 的 query string 一般为空 (也可以不为空)• header 部分有若干个键值对结构.• body 部分一般不为空. body 内的数据格式通过 header 中的Content-Type 指定. body 的长度由 header 中的 Content-Length 指定.经典面试题:谈谈 GET 和 POST 的区别语义不同: GET 一般用于获取数据, POST 一般用于提交数据.GET 的 body 一般为空, 需要传递的数据通过 query string 传递,POST 的 query string 一般为空, 需要传递的数据通过 body 传递GET 请求一般是幂等的, POST 请求一般是不幂等的. (如果多次请求得到的结果一样, 就视为请求是幂等的).比如查余额GET查 1 次和查 100 次余额不会变也不会产生新数据 → 幂等 比如下单付款POST点 1次是正常下单点 10 次可能扣 10 次钱 → 不幂等。GET 可以被缓存, POST 不能被缓存. (这一点也是承接幂等性).缓存只适合 “只读、无副作用” 的请求因为 GET 是幂等的只读、不修改数据缓存它的结果是安全的。否则会出大问题因为 POST 是不幂等的修改数据、有副作用缓存它的结果会导致严重错误反例如果缓存 POST 你发 POST /order 创建订单 → 服务器返回 “订单创建成功订单号 1001” →浏览器缓存这个结果 你不小心刷新页面再次发同样的 POST浏览器直接返回缓存的 “订单 1001”但服务器其实又创建了订单1002 → 你看到的是 “订单 1001”但服务器里多了订单 1002数据不一致关于一些网上常见说法的讨论特性GET 请求POST 请求结论传输文本✅ 可行 (短文本)✅ 可行 (长文本/复杂格式)两者皆可POST 更优传输二进制⚠️ 理论可行实际禁用✅ 标准方案只能用 POST2.3.3 其他操作这四个操作中的任何一个都能实现增删改查其实完全取决于代码怎么写2.4 请求报头(header)的关键属性GET https://gitee.com/HGtz2222 HTTP/1.1 Host: gitee.com Connection: keep-alive Cache-Control: max-age0Upgrade-Insecure-Requests:1User-Agent: Mozilla/5.0(Windows NT10.0;Win64;x64)AppleWebKit/537.36(KHTML, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/w Sec-Fetch-Site: same-origin Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document sec-ch-ua: Not;A Brand;v99,Google Chrome;v91,Chromium;v91sec-ch-ua-mobile: ?0 Referer: https://gitee.com/login Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q0.9,en;q0.8Cookie:oschina_new_userfalse;user_localezh-CN;yp_riddler_id1ce4a551-a160-4header 的整体的格式也是 “键值对” 结构.每个键值对占一行. 键和值之间使用分号分割.Host表示服务器主机的地址和端口.Content-Length表示 body 中的数据长度Content-Type表示请求的 body 中的数据格式.如果报文有 body 却缺少这两个报头Content-Length和Content-Type中的任意一个就会被视为非法或错误的 HTTP 报文因为接收方无法知道 body 的长度和格式也就无法正确解析。User-Agent(简称 UA)表示浏览器/操作系统的属性. 形如:Mozilla/5.0(WindowsNT10.0;Win64;x64)AppleWebKit/537.36(KHTML,likeGecko)其中 Windows NT 10.0; Win64; x64 表示操作系统信息AppleWebKit/537.36 (KHTML, like Gecko) 表示浏览器信息.UA的作用根据用户使用的设备进行区分通过UA中浏览器/操作系统版本区分出当前用户的设备支持个性化的体验比如前端有响应式编程一说通过CSS中的媒体查询功能感知到当前的窗口尺寸通过不同的尺寸设置不同样式一个页面就可以适配不同的窗口Referer表示这个页面是从哪个页面跳转过来的. 形如https://www.doubao.com/login如果直接在浏览器中输入URL, 或者直接通过收藏夹访问页面时是没有 Referer 的.Cookie设计Cookie的目的既满足网页 “保存本地数据” 的开发需求又通过浏览器的管控避免 JS 直接操作文件系统带来的安全风险如恶意篡改用户文件。Cookie 中存储了一个字符串, 这个数据可能是客户端(网页)自行通过 JS 写入的, 也可能来自于服务器(服务器在 HTTP 响应的 header 中通过 Set-Cookie 字段给浏览器返回数据).往往可以通过这个字段实现身份标识的功能.HTTP 协议本身是无状态的服务器记不住每次请求的用户身份Cookie 会存储服务器颁发的会话标识如 JSESSIONID、Token。用户后续访问网站时浏览器会自动将 Cookie 带入请求头服务器通过标识识别用户实现 一次登录全程免登。用户使用浏览器访问服务器过程注意Session 是服务器端的一个对象用于存储当前用户会话的详细信息如用户 ID、用户名、权限等。session可以让服务器 “记住” 用户避免每次请求都需要重新验证身份。Session 的完整工作流程2.5 HTTP 协议基于 TCP 传输时的报文结构、边界划分HTTP 报文的结构基于 TCPHTTP 协议本质上是把字符串按约定格式组织起来通过 TCP socket 传输完整结构分为 4 部分首行包含请求方法、URL、HTTP 版本号请求头多行键值对描述请求的元信息如 Host、Content-Type 等空行作为请求头和正文的分隔符正文body承载业务数据如 JSON、表单、文件等可选TCP 上如何划分 HTTP 请求的边界TCP 是面向字节流的协议一个连接上可以传输多个 HTTP 请求服务器需要明确每个请求的起止位置无 body 的请求读到空行就认为请求结束有 body 的请求先读取首行和请求头读到空行后解析 Content-Length 头再读取对应字节数的正文以此确定请求结束UDP 的特点与 TCP 对比UDP 是面向数据报的协议和 TCP 的字节流模式有本质区别读写的基本单位是UDP 数据报一个 UDP 数据报就对应一个完整的应用层数据包调用一次 receive 操作就能得到一个明确的 UDP 数据包无需额外划分边界3. HTTP 响应详解认识 “状态码” (status code)状态码表示访问一个页面的结果. (是访问成功, 还是失败, 还是其他的一些情况…).以下为常见的状态码.3.1 200 OK这是一个最常见的状态码, 表示访问成功我们打开fidder几乎都是200注意: 在抓包观察响应数据的时候, 可能会看到压缩之后的数据, 形如:网络传输中 “带宽” 是一个稀缺资源, 为了传输效率更高往往会对数据进行压缩.点击 Fiddler 中的即可进行解压缩, 看到原始的内容.3.2 404 Not Found没有找到资源.浏览器输入一个 URL, 目的就是为了访问对方服务器上的一个资源.如果这个 URL 标识的资源不存在,那么就会出现 404例如, 在浏览器中输入 www.sogou.com/index.html , 此时就在尝试访问 sogou 上的/index.html 这个资源.如果输入正确, 则可以正确访问到. 但是如果输入错误, 比如www.sogou.com/index2.html , 就会看到 404 这样的响应.HTTP/1.1404Not Found Server: nginx Date: Mon, 09 Mar202602:38:57 GMT Content-Type: text/html Connection: keep-alive Vary: Accept-Encoding Content-Length:564htmlheadtitle404Not Found/title/headbodybgcolorwhitecenterh1404Not Found/h1/centerhrcenternginx/center/body/html!-- a padding to disable MSIE and Chrome friendly error page --!-- a padding to disable MSIE and Chrome friendly error page --!-- a padding to disable MSIE and Chrome friendly error page --!-- a padding to disable MSIE and Chrome friendly error page --!-- a padding to disable MSIE and Chrome friendly error page --!-- a padding to disable MSIE and Chrome friendly error page --3.3 403 Forbidden表示访问被拒绝. 有的页面通常需要用户具有一定的权限才能访问(登陆后才能访问). 如果用户没有登陆直接访问, 就容易见到 403.例如: 查看码云的私有仓库, 如果不登陆, 就会出现 403. 参考链接:https://gitee.com/HGtz2222/blog_python3.4 405 Method Not Allowed请求的方法和服务器这边声明的注解不匹配就会出现4053.5 500 Internal Server Error服务器出现错误服务器处理逻辑的代码中抛出异常但是写代码时候没有catch到3.6 504 Gateway Timeout当服务器负载比较大的时候, 服务器处理单条请求的时候消耗的时间就会很长, 就可能会导致出现超时的情况. 这种情况在双十一等 “秒杀” 场景中容易出现, 平时不太容易见到3.7 302 Move temporarily重定向访问服务器A服务器A告诉你去找B某个网站如果想要修改域名如果直接把服务器架设在新的域名上不采取其他操作的话原来的用户无法通过原来的域名进行访问。还有一种办法就是可以把服务器架设在新的域名上同时给旧域名设置重定向可以重定向到新域名。这样用户既可以访问旧的域名也可以访问新的域名。3.8 状态码的总结4. HTTPS4.1 HTTP的缺点用户想要访问服务器下载某app可是过程中可能会路过被黑客入侵的服务器此时黑客可以对于用户访问/服务器返回的数据进行篡改非常的不安全4.2 HTTPS的概念HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层. HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.4.3 HTTPS 的工作过程既然要保证数据安全, 就需要进行 “加密”.网络传输中不再直接传输明文了, 而是加密之后的 “密文”.加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密。4.3.1 引入对称加密对称加密其实就是通过同一个密钥, 把明文加密成密文, 并且也能把密文解密成明文.但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 “密钥的密钥”. 但是问题是总得由一个密钥是需要明文传输的. 此时密钥的传输再用对称加密就行不通了.就需要引入非对称加密.4.3.2 引入非对称加密非对称加密要用到两个密钥, 一个叫做公钥, 一个叫做私钥.公钥和私钥是配对的. 最大的缺点就是运算速度非常慢比对称加密要慢很多.• 通过公钥对明文加密, 变成密文• 通过私钥对密文解密, 变成明文也可以反着用• 通过私钥对明文加密, 变成密文• 通过公钥对密文解密, 变成明文下面我们这样使用把公钥当成锁把私钥当成钥匙客户端将密文使用公钥加密之后传输给服务器由于黑客没有私钥无法解密服务器返回响应。之后客户端的密文请求采用对称加密此时使用对称加密没有问题因为黑客侵入的路由器没有私钥无法解密当前的场景有三个密钥客户端生成的对称密钥服务器生成的公钥可以给所有设备告知服务器生成的私钥只有自己知道虽然理论上客户端持有公钥服务器持有公钥和私钥然而在第一次访问一个陌生网站时客户端一开始本身没有公钥这个公钥也要从服务器获取的就会出现以下重大安全隐患客户端向服务器询问公钥pub1服务器返回pub1被黑客获取pub1.黑客不直接转发pub1而是告诉客户端公钥是pub2(黑客自己生成一对非对称密钥包括公钥pub2私钥pri2)以后客户端就会用pub2进行加密。当客户端向服务器发送以后要使用的对称密钥key(对称密钥由客户端生成)时客户端在发送之前也会使用pub2进行加密然后向服务器发送数据此时当该数据经过黑客入侵的路由器时黑客会使用自己的私钥pri2进行解密获得对称密钥key然后使用之前获得的pub1进行加密传送给服务器之后客户端传输给服务器的数据以及服务器传输给客户端的数据也会使用key进行加密黑客就可以使用对称密钥key进行解密获取机密信息了要想彻底解决这个问题需要引入证书4.3.3 引入证书从刚才的例子我们知道问题出在客户端无法识别黑客伪造的pub2是错误的公钥如果能识别出来则问题可以得到解决。引入证书之后服务端在使用HTTPS前需要向CA机构申领一份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端公钥的权威性。4.3.3.1 分工我们先讲一下分工服务器持有自身的非对称密钥对pub1 公钥、pri1 私钥需要申请合法证书证明 pub1 的身份。第三方认证机构CA公认的可信组织持有自身的非对称密钥对pub2 公钥、pri2 私钥pub2 会预装在所有正规操作系统 / 浏览器中。客户端自身持有pub2可以通过验证 CA 签名确认服务器公钥的真实性4.3.3.2 阶段 1服务器向 CA 申请数字证书线下 / 前置操作服务器搭建完成后需向 CA 申请证书仅需申请一次后续长期保存使用提交材料服务器向 CA 提交核心信息包括自身公钥 pub1、服务器域名、持有者信息、证书有效期等。阶段1CA 生成证书核心签名流程步骤 1生成校验和CA 将服务器提交的核心信息通过哈希算法如 SHA256计算出一个固定长度的校验和类似 “数据指纹”。步骤 2加密签名CA 使用自己的私钥 pri2对这个校验和进行加密生成数字签名。步骤 3封装证书将服务器原始信息、CA 数字签名、CA 公钥标识等内容封装形成最终的数字证书下发给服务器。阶段 2证书分发客户端请求证书防范中间人拦截客户端发起请求客户端向服务器发送 “大哥大哥咱的证书是啥”请求获取服务器证书。黑客拦截尝试黑客入侵路由器拦截该请求同时也向服务器转发请求拿到服务器的真实证书。黑客伪造失败黑客试图用自己的公钥伪造证书但因没有 CA 的私钥 pri2无法生成合法的数字签名只能转发服务器的真实证书给客户端伪造证书会被后续验证直接拦截。阶段 3客户端验证证书核心安全环节对应图中 3 步校验客户端收到证书后通过3 步校验确认证书合法性核心是利用系统内置的 CA 公钥 pub2 验证签名校验证书基础字段先检查证书的颁布机构是否可信、有效期是否过期、域名是否与当前访问的服务器一致基础合法性筛查。双重计算校验和核心验签a.计算校验和 1客户端提取证书中的服务器原始信息用与 CA 相同的哈希算法重新计算出一个校验和。b.解密校验和 2客户端使用系统内置的 CA 公钥 pub2对证书中的CA 数字签名进行解密得到 CA 当初生成的原始校验和。对比校验判定结果验证通过若校验和 1 校验和 2说明证书未被篡改服务器的公钥 pub1 是真实合法的。验证失败若两者不一致说明证书被黑客篡改或为伪造证书客户端立即终止通信弹出 “不安全连接” 警告。如果验证通过当客户端向服务器传输自己生成的对称密钥key之前会使用pub1进行加密黑客由于没有pri1所以无法解密。服务器得到对称密钥key之后客户端服务器的通信使用key进行通信由于黑客无对称密钥key仍然无法解密所以是安全的。4.4 HTTPS面试考点总结