了解 Web 及网络基础
对端传输
发送端在层与层间传输数据时,没经过一层都会被加上首部信息,接收端每经过一层都会删除一条首部
多种协议作用
IP 协议,TCP 协议和 DNS 服务在使用 HTTP 协议过程中发挥的作用
简单的 HTTP 协议
请求报文和响应报文
客户端像服务器发起请求时会生成一段请求报文,请求报文是由请求方法,URL,协议版本,可选的请求首部字段和内容实体构成。
请求报文
接收到请求的服务器,会将请求内容的处理结构以响应的形式返回。响应报文基本上由协议版本,状态码,用以解释状态的原因短语,可选的响应首部字段以及实体主体构成。
响应报文
HTTP 是不保存状态的协议和 Cookie 的简单介绍
HTTP 协议对于发送的请求和响应不做持久化处理。这时候引入了 Cookie 技术用于状态管理。Cookie 对用与登录的状态管理,没有 Cookie 这个技术的话,因为 HTTP 不保存状态,每次打开新网页都必须再次登录。
Cookie 会根据响应报文中的 Set-Cookie 字段来通知客户端自动保存 Cookie。下次请求时会自动发送 Cookie,服务器会比对数据得到状态结果。
先引入副作用和幂等的概念。
副作用指对服务器上的资源做改变,搜索是无副作用的,注册是副作用的。
幂等指发送 M 和 N 次请求(两者不相同且都大于1),服务器上资源的状态一致。注册10个和11个帐号是不幂等的,对文章进行更改10次和11次是幂等的。
在规范的应用场景上说,Get 多用于无副作用,幂等的场景,例如搜索关键字。Post 多用于副作用,不幂等的场景,例如注册。
在技术上说:
- Get 请求能缓存,Post 不能
- Post 相对 Get 安全一点点,因为Get 请求都包含在 URL 里,且会被浏览器保存历史纪录,Post 不会,但是在抓包的情况下都是一样的。
- Post 可以通过 request body来传输比 Get 更多的数据,Get 没有这个技术
- URL有长度限制,会影响 Get 请求,但是这个长度限制是浏览器规定的,不是 RFC 规定的
- Post 支持更多的编码类型且不对数据类型限制
常见状态码
常见状态码
2XX 成功
- 200 OK,表示从客户端发来的请求在服务器端被正确处理
- 204 No content,表示请求成功,但响应报文不含实体的主体部分
- 206 Partial Content,进行范围请求
3XX 重定向
- 301 moved permanently,永久性重定向,表示资源已被分配了新的 URL
- 302 found,临时性重定向,表示资源临时被分配了新的 URL
- 303 see other,表示资源存在着另一个 URL,应使用 GET 方法丁香获取资源
- 304 not modified,表示服务器允许访问资源,但因发生请求未满足条件的情况
- 307 temporary redirect,临时重定向,和302含义相同
4XX 客户端错误
- 400 bad request,请求报文存在语法错误
- 401 unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息
- 403 forbidden,表示对请求资源的访问被服务器拒绝
- 404 not found,表示在服务器上没有找到请求的资源
5XX 服务器错误
- 500 internal sever error,表示服务器端在执行请求时发生了错误
- 503 service unavailable,表明服务器暂时处于超负载或正在停机维护,无法处理请求
HTTP 首部
通用首部
指请求报文和响应报文都可以使用的字段
- Cache-Control no-cache 指客户端不缓存过期资源 no-store 指不进行缓存 max-age 指缓存资源的缓存时间比指定的值小,那么客户端就接受缓存资源,且缓存服务器不对资源有效性进行再次确认
- Connection 指控制不再转发给代理的首部字段(Hop-by-hop),管理持久连接 close 指服务器像明确断开连接 Keep-Alive 指保存持久连接,HTTP/1.1前默认连接是非持久性的,如需要保存持久连接,需要增加此字段
- Upgrade 可以用来指定一个完全不同的通信协议,对于这个字段,服务器可以返回101状态码
请求首部字段
- Accept 指用户代理能够处理的媒体类型及媒体类型的相对优先级
- Accept-Encoding 指用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序
- Authorization 指用来告知服务器,用户代理的认证信息
- Host 当一个 IP 下存在多个域名时,帮助服务器知道要请求的具体主机
- User-Agent 会讲创建请求的浏览器和用户代理名称等信息传达给服务器
HTTPS
HTTPS 是 HTTP 建立在 SSL/TLS 安全协议上的。
在 IOS 中,客户端本地会存放着 CA 证书,在HTTPS 请求时,会首先像服务器索要公钥,获得公钥后会使用本地 CA 证书验证公钥的正确性,然后通过正确的公钥加密信息发送给服务器,服务器会使用私钥解密信息。
SSL/TLS握手阶段分为五步:以下引自 阮一峰的网络日志第一步,爱丽丝给出协议版本号、一个客户端生成的随机数(Client random),以及客户端支持的加密方法。第二步,鲍勃确认双方使用的加密方法,并给出数字证书、以及一个服务器生成的随机数(Server random)。第三步,爱丽丝确认数字证书有效,然后生成一个新的随机数(Premaster secret),并使用数字证书中的公钥,加密这个随机数,发给鲍勃。第四步,鲍勃使用自己的私钥,获取爱丽丝发来的随机数(即Premaster secret)。第五步,爱丽丝和鲍勃根据约定的加密方法,使用前面的三个随机数,生成"对话密钥"(session key),用来加密接下来的整个对话过程。
HTTPS 相对于 HTTP 性能上差点,因为多了 SSL/TLS 的几次握手和加密解密的运算处理,但是加密解密的运算处理已经可以通过特有的硬件来加速处理。
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。