文章目录
一. HTTP
概念与历史
超文本传输协议(英语:HyperText Transfer Protocol,缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。
—— wikipedia
- 历史版本
http各个发型版本的详细设计可以参见rfc(请求意见稿Request for Comments)。- HTTP/0.9
古早版本,只接受GET一种请求方法 - HTTP/1.0
http1.0 是一种无状态、无连接的应用层协议,最大的缺陷问题之一是无法复用链接
,导致每次请求都要建立新链接,进行tcp三次握手。
rfc:https://datatracker.ietf.org/doc/html/rfc1945 - HTTP/1.1
http1.1支持长链接,pipeline,响应分块等优化。
rfc:https://datatracker.ietf.org/doc/html/rfc2616 - HTTP/2
http2.0增加了二进制分帧,多路复用,头部压缩等性能优化,同时纳入tls保证链接安全。
rfc:https://datatracker.ietf.org/doc/html/rfc7540
- HTTP/0.9
随便打开一个国内网站,会发现很多都是是http2连接了。
常见请求头
HTTP头字段(HTTP header fields),是指在超文本传输协议(HTTP)的请求和响应消息中的消息头部分,是我们日常前后端开发中经常接触到的一个概念。
请求头大全:
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers
-
ContentType是一个实体Header。
其中有一些常用的格式:- application/x-www-form-urlencoded : 默认的表单媒体格式。
- application/json json格式。
- text/html html格式。
- text/plain纯文本格式。
- image/jpeg jpeg图片格式。
- multipart/form-data 可提交文件的表单媒体格式。
-
Accept
Accept: text/html 浏览器可以接受服务器回发的类型为 text/html。
Accept: / 代表浏览器可以处理所有类型。 -
Authorization
用于超文本传输协议的认证的认证信息 -
Cache-Control
用来指定在这次的请求/响应链中的所有缓存机制,如可缓存性,缓存时间等。 -
Connection
复用连接,可以指定 Connection: Keep-Alive -
Cookie
指某些网站为了辨别用户身份而储存在用户本地的数据,主要是因为http无状态导致网站设计使用cookie来传递用户信息。 -
User-Agent
传递浏览器,客户端等信息。 -
Accept-Ranges,Range
Http的Range请求头,结合响应头Accept-Ranges、Content-Range可以实现断点续传。
请求头Range表示请求的数据起始位置。响应头Accept-Ranges: bytes表示支持续传。响应头Content-Range表示返回的起始位置、总长度。
http常见响应码
大类:
1xx 信息,服务器收到请求,需要请求者继续执行操作
2xx 成功,操作被成功接收并处理
3xx 重定向,需要进一步的操作以完成请求
4xx 客户端错误,请求包含语法错误或无法完成请求
5xx 服务器错误,服务器在处理请求的过程中发生了错误
100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求,但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本
204 No Content 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP状态码
307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向
400 Bad Request 客户端请求的语法错误,服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留,将来使用
403 Forbidden 服务器理解请求客户端的请求,但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长,超时
409 Conflict 服务器完成客户端的 PUT 请求时可能返回此代码,服务器处理请求时发生了冲突
410 Gone 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息
414 Request-URI Too Large 请求的URI过长(URI通常为网址),服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed 服务器无法满足Expect的请求头信息
500 Internal Server Error 服务器内部错误,无法完成请求
501 Not Implemented 服务器不支持请求的功能,无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器,未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本,无法完成处理
from : [https://www.runoob.com/http/http-status-codes.html](https://www.runoob.com/http/http-status-codes.html)
TLS
TLS:(Transport Layer Security,传输层安全性协议,前身为SSL-Secure Socket Layer),TLS虽然带个层字,却不是体系七层之一,而是属于传输层的一部分。
我们如今经常见到的HTTPS正是HTTP+TLS。
rfc:
https://datatracker.ietf.org/doc/html/rfc8446
安全问题
数据在网络传输中,安全性会存在问题:
- 数据被他人恶意拦截窃取
- 数据被他人恶意拦截修改
- 网络通信的一方被他人恶意替代冒充
解决办法
- 对于前两个问题,只要保证数据是加密的并且加密方式不会他人攻击获取即可解决。
简单提一下对称加密/非堆成加密:
对称加密: 即通信双方都以相同的密钥,相同的加密算法进行加密解密,但是这一方式的风险是密钥如何安全同步给双方,常见算法如AES、DES等。
非对称加密:同样的算法,但是使用不同的密钥(公钥,私钥)分别进行加密解密,这样就可以实现一种有效的防止密钥泄漏的方式,常见算法如:RSA,ECC,DH。
由于公钥是所有人都可以获取的,因此想要给接收方发送消息只需要获取公钥即可,所以公钥可以用明文直接传输,因为即使是在传输过程中泄露了公钥,由于解密只能使用私钥,因此整个数据传输也还是安全的。
于是我们得出结论,使用非对称加密即可防止前两个问题的发生。
但是同时我们又要注意另一个问题,非对称加密的效率是底下的
,比如SSL中使用的DH算法,相较于对称加密来说,效率十分低下,于是SSL做了如下设计:
第一步,客户端发起请求,服务端返回非对称加密的公钥,加密算法等信息。
第二步,客户端提供自己的公钥等信息,至此双方可以通过非对称加密进行通信
。
但是由于非对称加密的效率不如对称加密,所以在此时又做了一步,交换一个双方认可的对称加密密钥,有了这个密钥,双方就可以通过对称加密通信。
- TLS通过非对称+对称加密两个步骤解决了前两个问题,但是第三个问题呢?
实际上,防止他人恶意冒充这件事情,无法做到程序的自动化,程序不知道谁是恶意冒充,谁是原版网站,于是CA证书颁发机构出现了
。
CA认证,即电子认证服务 ,是指为电子签名相关各方提供真实性、可靠性验证的活动。
CA证书,即为机构颁发的背书证书。
CA证书颁发机构,颁发证书的机构,承担公钥体系中公钥的合法性检验的责任。
于是我们就认识到了,CA证书并不神奇,他只是CA颁发机构给出的一张清单,清单上面是合法的域名,不在证书中的,就不合法,在浏览器上就会给你曝红。
这就是为什么我们有时候访问一些网站时,浏览器会弹出“网站存在安全风险”的提示。
欢迎关注微信公众号 【JAVA技术分享官】,公众号首发,持续输出原创高质量JAVA开发者知识点