网络请求基础知识（一）HTTP 基础篇

1.报文格式

1.1 请求报文

以下是发起一个 HTTP 请求需要的主要信息，在发起网络请求时我们一般只提供 URL 和请求实体，剩下的交给框架（Okhttp3或者 Retrofit等）完成。

• 请求行：请求方法+路径+版本号

• 请求头：

  • Host: 请求的主机名

  • Connection：是否保持连接

  • User-Agent：用户信息

  • Accept：客户端接受的数据类型

  • Accept-Encoding：客户端识别的数据编码格式

  • Cookie：cookie 信息

• 请求体：内容

Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 7.0; m3 note) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
ip=172.56.168.66&imei=86521684611

1.2 响应报文

准备好http 请求信息后，接下来就可以发起网络请求了，请求一般使用socket ，具体实现可以通过 TCP/UDP 来传输。

• 状态行：版本号+状态码+状态信息

• 响应头：Content-Type，Content-Length等

• 响应体：返回内容

Server: nginx/1.8.1
Date: Thu, 03 Jan 2019 07:31:02 GMT
Content-Type: text/plain;charset=UTF-8
Content-Length: 93
Connection: keep-alive
Accept-Charset: big5, big5-hkscs, euc-jp, euc-kr, gb18030, gb2312, gbk, ibm-thai, ibm00858, ibm01140, ibm01141
​
{"adlist":{"kaiping":{"ad":{}},"yunying":{"ad":{}}},"showadtime":"10","getadlisttime":"1200"}

1.2.1 状态吗

2xx:成功,报文已成功收到并被正确处理
3xx:重定向，资源位置发生变动，需要客户端重新发送请求
4xx:客户端错误，请求报文有误，服务器无法处理
5xx:服务器错误，服务器在处理请求时内部发生了错误

```

• 200 请求成功

• 304 缓存可以继续用

• 404 地址有问题

• 500 服务器内部错误

• 301：请求的资源永久迁移到新的位置

• 302：请求的资源暂时需要从另一个地址响应，后续的请求中应该继续使用原地址

• 305：使用代理，请求的资源需要通过指定的代理访问

• 307：请求资源临时需要从新地址响应（与 302 不同的是它是 HTTP1.1 出现的；此外，如果重定向 307 的原请求不是 GET 或者 HEAD 方法，浏览器一定不能自动的进行重定向）

• 400：客户端请求语法错误

• 403：禁止访问，服务器理解请求，但由于没有授权服务器拒绝提供资源

• 404：找不到，请求的位置无法找到任何资源

• 406：无法访问，请求资源的类型和想要的不一样

1.2.2 响应头

• Cache-Control：缓存策略，private(中间节点不能缓存数据，个性信息)/public(中间节点能缓存数据，公有信息)

• Pramga：用于在旧版本兼容Cache-Control`

• Connection：连接是否要保持，在 HTTP1.1 开始允许保持连接

• Cotent-Encoding：服务器使用了什么压缩方法，客户端需要进行相应的处理

• Content-Type：返回的数据类型

• Content-Length：服务器告知相应对象的长度

• Content-Range：服务器告知该想要属于哪个部分，一般用于断点续传

• Range：客户端告知服务器自己想取对象的哪部分，一般用于断点续传

• Set-Cookie：服务端告知当前 Cookie 的使用限制，包括：过期日期、路径、域、端口、版本等

• ETag：对当前相应的一个标识，用于判断请求资源是否修改

• Expired：服务器表明该相应将在什么时候过期（过期了的对象，只有在跟服务器验证其有效性后，才能用来响应客户请求）

• Location：指定重定向的url地址，请求http://www.baidu.com重定向到https://www.baidu.com

   Location: https://www.baidu.com/
   Non-Authoritative-Reason: HSTS

• Proxy-Authenticate： 代理服务器处理的请求，要求客户端提供代理身份验证信息

• Referer：客户端告知服务器自己是从哪个 URL 点击当前请求中的 URL

• Transfer-Encoding：服务器表明自己对本响应体作了怎样的编码，比如是否分块（chunked）

• Last-Modified：服务器返回一个过期时间

• User-Agent：用户代理，实际发送请求，接受响应的浏览器和手机。（返回手机页面还是pc页面）

• Cache-Control:no-cache（下次使用时，询问一下）,no-store(不要缓存),max-age（未过期直接使用）

1.2.3 使用缓存过程如下图：

image

2.HTTP 的特点:

• 灵活可扩展

  • HTTP 协议是一个“灵活可扩展”的传输协议

    • 只规定了报文的基本格式,各个组成部分并没有严格的语法语义限制,开发者可自由定制

    • 能够传输图片,音频,视频等任意数据

• 可靠传输

  • HTTP 协议是一个“可靠”的传输协议

    • 基于 TCP/IP 的，而 TCP 本身是一个“可靠”的传输协议

    • HTTP 并不能 100% 保证数据一定能够发送到另一端，在网络繁忙、连接质量差等恶劣的环境下，也有可能收发失败.

• 应用层协议

  • HTTP 协议是一个应用层的协议

    • 对比其他应用层协议,HTTP 协议称得上是一个万能的协议,只要性能不太苛刻,几乎可以传输一切东西

• 请求 - 应答

  • HTTP 协议使用的是请求 - 应答通信模式

• 无状态

  • HTTP 协议是无状态的

    • TCP 协议:有状态,一开始处于 CLOSED 状态，连接成功后是ESTABLISHED 状态，断开连接后是 FIN-WAIT 状态，最后又是 CLOSED 状态。

    • HTTP 协议:客户端和服务器永远是处在一种“无知”的状态,建立连接前两者互不知情，每次收发的报文也都是互相独立的,没有任何的联系。收发报文也不会对客户端或服务器产生任何影响,连接后也不会要求保存任何信息。

    • UDP 协议:它是无连接也无状态的，顺序发包乱序收包，数据包发出去后就不管了,收到后也不会顺序整理。而 HTTP 是有连接无状态，顺序发包顺序收包，按照收发的顺序管理报文.

3. HTTP 的优点和缺点

3.1 优点

• 1.简单、灵活、易于扩展

• 2.应用广泛、环境成熟

3.2 双刃剑

• 无状态

  • 优点:

    • 节省资源,实现简单

    • 容易组成集群(服务器都是相同的,无状态差异)

  • 缺点:无法支持需要多个步骤的"事务操作",如电商购物,用户首先需要登陆,然后添加购物车,再下单,结算,支付,而这一系列过程都需要知道用户的身份信息才可以,又因为 http 的无状态,每一次都需要问一遍身份信息,不仅麻烦,还浪费资源.

• 明文

  协议里的报文（准确地说是 header 部分）不使用二进制数据，而是用简单可阅读的文本形式。

  • 优点:不需要借助任何外部工具,容易查看或修改,方便调试

  • 缺点:报文所有信息都暴露在传输链路里

3.3 缺点:

• 不安全

  安全有很多的方面，明文只是“机密”方面的一个缺点，在“身份认证”和“完整性校验”这两方面 HTTP 也是欠缺的。

  • 身份认证:HTTP 无法提供有效的手段来确认通信双方的真实身份,很可能会连到一个一模一样的假冒 站

  • 不支持完整性校验,数据在传输过程中容易被篡改而无法辨别真伪.

• 虽然银行可以用 MD5、SHA1 等算法给报文加上数字摘要，但还是因为“明文”这个致命缺点，黑客可以连同摘要一同修改,最终还是判断不出报文是否被窜改

如何解决：HTTPS

• 性能

概括:不算好,不够好

• 基于 TCP ,TCP的性能是不差的,但现在的互联网特点是移动和高并发,不能保证稳定的连接质量,所以在 TCP 层面上 HTTP 协议有时候就会表现的不够好

• 请求 - 应答”模式则加剧了 HTTP 的性能问题,即队头阻塞”（Head-of-line blocking),当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据

如何解决:Web 性能优化,缓存等

终极解决方案:HTTP/2 和 HTTP/3