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</pre>
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"}</pre>
1.2.1 状态吗
2xx:成功,报文已成功收到并被正确处理 3xx:重定向，资源位置发生变动，需要客户端重新发送请求 4xx:客户端错误，请求报文有误，服务器无法处理 5xx:服务器错误，服务器在处理请求时内部发生了错误</pre>```
-
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</pre>
-
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
网友评论