1、http是怎么定义的？
1.1、超文本传输协议；
超文本传输协议（英语：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。
设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
1.2、http在网络中的分层；
最开始的网络分层是分了有七层，如下；
OSI模型：
后来由于最上面三层（应用层、表示层和会话层）在TCP/IP组中是一个应用层，就合并到应用层了；
TCP/IP组模型：
而HTTP在网络分层中是属于应用层的协议；
2、http是怎么工作的？
http的工作方式通常是由客户端和服务端协同完成的；
通常，由客户端发起一个请求，创建一个到服务器指定端口（默认是80）的TCP链接，服务器则在这个端口监听客户端的请求，当接收到请求后，会根据客户端的请求，返回对应的内容，比如html文本，图片之类的，并且返回对应的状态码来告诉客户端请求的状态是否成功；
3、报文是什么？
3.1、http的报文是什么？
HTTP报文是在HTTP应用程序之间发送的数据块。
将http比喻成快递，那么http报文就是包裹的快递单，包含来姓名，地址，邮政编码，表示我这个快递要寄到哪里去，而快递中心收到这个快递后，就会通过这个快递单，来判断这个包裹要寄送到哪里去，而这个信息就是通过快递单来获取的；
那么同样http报文也是类似的道理，客户端发送一个请求，带上报文，服务端接收到请求后，解析这个报文，就知道客户端需要获取什么东西来；
而服务端想客户端返回内容时，也会带上报文，表示我返回的内容是什么，方便客户端通过报文来解析数据，并处理的流程；
3.2、http报文的格式
http报文分为请求报文和相应报文；
- 请求报文：客户端向服务器发送的报文；
- 相应报文：服务端向客户端发送的报文；
请求报文的格式：
由请求行，请求头，空行，请求数据这四部分组成
举例：请求百度的地址，打开浏览器的调试功能，查看请求报文；
响应报文的格式：
由状态行，请求头，空行，请求数据这四部分组成
举例：同样通过浏览器查看百度页面的响应报文；
4、URL是什么？
4.1、URL是怎么定义的？
URL，全称：Uniform Resource Locator 译名：统一资源定位符，用于准确描述Internet上某一资源的地址；
我们访问的网页都是有地址的，而地址通常指向某个服务器上的资源；
4.2、URL的格式是怎样的？
URL的格式是由协议类型（http，https等），服务器地址（host），端口号（port），路径（path）这几部分组成的；
比如百度的地址：www.baidu.com/；
格式如下：http://host[:port][/path]
- 协议类型：表示使用哪种网络协议来进行网络请求，比如HTTP，HTTPS；
- 服务器地址：表示主机，或者域名，或者IP地址；
- 端口号：如果没有指定的话，默认为80；
- 路径：表示指定请求资源的URL，默认会带上“/”，一般都是浏览器给我们加上的；
5、RequestMethod请求方法有哪些？
5.1、请求方法
HTTP请求的方法有很多，如下：
-
GET：使用GET的请求用于从服务器获取数据；
-
HEAD：和GET请求相似，但是没有响应体；
-
POST方法：用于将内容提交到服务器，通常用于修改或者删除服务器上的资源；
-
PUT方法：通常用于修改服务器上的数据；
-
DELETE方法：删除服务器指定的资源；
-
CONNECT方法：建立一个到由目标资源标识的服务器的隧道，用于代理服务器；
-
OPTIONS方法：用于描述目标资源的通信选项，通常用于跨域请求；
-
TRACE方法：沿着到目标资源的路径执行一个消息环回测试，用于追踪请求；
5.2、GET和POST请求的区别
我们最常用的的请求方法，基本上就是GET和POST请求了，那么我们来看一下他们的区别吧；
通常在浏览器上输入一个地址进行请求，一般都是通过GET请求方式，而POST请求一般用于提交内容，将需要提交给服务器的参数放到body里面，进行请求；
来看看w3school列举的差异点：
疑问：
1，安全性：
GET的请求在浏览器上是可以看到请求的参数的，基本上来说没有安全性可言；
而POST请求在浏览器上看不到请求参数，是不是表示就是安全的呢？
并不是，别人可以通过抓包的方式来获取到你的请求参数，所以并不是安全的，要想安全的传输只能通过有加密方式的HTTPS请求；
2，POST方法是否会产生两个TCP数据包？
答案是：不一定；
这个不是必然会产生两个TCP数据包，而是看浏览器是否做了发送两次TCP数据包的处理，如果有做处理的话就会发送两次TCP数据包；
网上已经有文章验证过了，我这里就不再多说了，经验证的结果为：Chrome和Safari浏览器会发送两次TCP数据包，而Firefox浏览器只发送了一次；
详情请参考：听说『99% 的人都理解错了 HTTP 中 GET 与 POST 的区别』？？
3，URL过长会导致什么问题？
我们先用postman来模拟一下看看，弄一个超长的URL，请求一下看会不会报错；
从图片上可以看出，postman直接返回了414 Request-URL Too Long，表示当前URL过长了；
用浏览器请求返回的错误信息也是一样：
那么这里是否会有疑问，为什么URL过长会报错？ 是服务器处理不了，还是postman处理不了？ 还是http协议规定的URL不能超过多长呢？
查看RFC的http的相关文档（RFC 2616 - HTTP/1.1）发现里面的一段话，如下：
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
翻译过来的意思就是:
HTTP协议没有对长度进行任何限制，服务器必须能够处理其任何资源的URI服务，并且应该能够处理长度不受限制的URI，如果URI较长，则应返回414（请求URI太长）状态超出服务器的处理能力；
看到这里，我们就明白了，http协议并没有限制URL的长度，对URL长度做处理的，只有服务器或者浏览器，所以URL过长导致的报错是由服务器或者浏览器处理的；
4，GET方法可以带Body吗？
答案是：可以的！
为什么GET方法可以带Body吗？不是说GET方法是通过URL来取资源的吗？
来看一下RFC的协议中，对于GET方法的定义：
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI.
翻译过来的意思就是GET方法是通过URL来检索服务器上的信息，并没有说不能带上Body；
那么到这里你是否就有疑惑了？ 他没说不就代表他可以带上Body来请求啊；别急，我们继续分析；
再来看另外一份RFC协议对于GET请求带Body的解释:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
翻译过来的意思就是带上Body的GET方法，可能会导致拒绝请求，有可能是服务器拒绝了，也有可能是浏览器或者框架拒绝请求；
结论：GET方法是可以带上Body请求的，但是可能会发生拒绝请求的错误，或者一些其他的错误出现；
那么对于GET方法带上Body的测试这里就不多说了，感兴趣的请参考：谁说 HTTP GET 就不能通过 Body 来发送数据呢？
6、State Code状态码
6.1、状态码是什么？
状态码是客户端向服务端请求后，服务端会返回一个数字来告诉端侧请求的状态，比如200，表示请求成功了，比如404，客户端错误了；这样客户端再拿到状态码之后再做相应的处理，比如是否重试，比如展示错误页面，比如提示用户操作不当之类的；
6.1、状态码有哪些？
看一下菜鸟教程对于状态码的定义：
如图所示，http状态码主要分为5种类型，分别为1xx，2xx，3xx，4xx，5xx等开头的状态码；
每一个状态码以x开头的都可归类为某一种类型的状态；比如200（请求成功），404（客户端错误）等；
状态码的种类有很多，这里就不一一介绍了；
7、Header头部
7.1、Header是用来干嘛的？
Header其实是一个键值对，是属于元数据，用于告诉服务器，我要取什么样的数据或者我要做什么样的操作；
比如：Accept: text/plain，表示客户端能接受文本数据的返回；
除了先有的一些标准的请求头，我们还可以自定义请求头，比如：user："张三"，表示我要传 "张三"的Header到服务器，服务器再做相应的处理；
7.2、Header有哪些？
HTTP头字段按照实际用途可以分为四种类型，分别为通用头，请求头，响应头和实体头这四种；
- 通用头：是客户端和服务器都可以使用的头部，可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能，如Date头部；
- 请求头：是请求报文特有的，它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据，如Accept头部；
- 响应头：便于客户端提供信息，比如，客服端在与哪种类型的服务器进行交互，如Server头部；
- 实体头：指的是用于应对实体主体部分的头部，比如，可以用实体头部来说明实体主体部分的数据类型，如Content-Type头部；
7.3、常见的Header的类型有哪些？
1，Host
客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号；
2，Content-Type
用于指定请求体的类型，主要有四种；
（1）text/html：用于告诉服务器需要响应的类型为文本数据类型；
（2）x-www-form-urlencoded：表单类型，用于web页面纯文本表单提交数据到服务器，比如注册页面数据的提交；
（3）multitype/form-data：用于web页面带二进制文件的表单提交方式，比如修改用户头像，会上传图片到服务器；
（4）application/json , image/jpeg , application/zip ...：提交单项内容到服务器，比如提交json，提交image，提交zip包到服务器；
3，Content-Length
用于指定响应体的长度，表示我这次请求需要返回多少字节的内容，多用于分块传输；
4，User-Agent
用于向服务端表明身份信息，表示我是来自手机客户端的请求，还是来自某个浏览器的请求；
5，Range
表示想从服务器取哪部分的内容，比如byte：start-end；用于多线程下载或者断点续传；
6，Accept
告诉服务器客户端能接受什么类型的数据，比如text/html；
7，Accept-Charset
告诉服务器客户端能接受的的字符集，比如utf-8；
8，Accept-Encoding
告诉服务器客户端能接受的压缩编码类型，如zip；
9，Content-Encoding
服务器告诉客户端自己使用了什么压缩方法，如gzip，deflate等；
HTTP的Header类型是在是太多了，这里就不一一介绍了，感兴趣的请参考： 「Android系列之网络（二）----HTTP请求头与响应头
8、Cache缓存
8.1、http为什么需要缓存？
1，通过网络获取内容，会受速度影响并且开销很大，需要在客户端和服务器之间建立通讯，然后通过传包的方式来进行通讯，受网络速度影响，有可能会响应比较慢，导致前端的展示体验不好；
2，减少开销，如果每一次请求都从服务器取的话，那么服务器将会面临巨大的压力，有可能会挂掉，导致访问不了；
3，使用缓存还可以减少网络带宽的占用，过多的请求会导致网络阻塞，从而响应速度也变慢；
4，减少无意义的重复请求，比如某个页面的数据，运营一天才会去修改一次，但是我每次进来这个页面都去从服务器请求数据，这样是没有意义的，只会导致资源的浪费；
所以使用缓存可以大大的提升响应速度，降低服务器压力，减少带宽的占用，因此HTTP的缓存是至关重要的；
8.2、http的缓存机制是什么？
1，通过 ETag 验证缓存的响应
（1）ETag是什么？
ETag 本质上是一个header，也被称为验证令牌，是由服务器根据根据文件生成的hash值或者其他的某个值；
（2）验证令牌的诞生旨在解决什么问题？
假如我们本地的数据是有缓存时效的，当我们从本地取数据的时候，发现缓存时效过期了，这时候就会去服务器那边取数据，但是此时从服务器取回来的数据和本地的数据是一样的，没有什么变化，只是本地的缓存时效过期了，这时候从服务器取回来的数据就没有意义了，还浪费了请求所消耗的资源；
那么验证令牌就是为了解决这类问题而诞生的；
（3）验证令牌是怎么解决这类问题的？
前面说了，验证令牌本质上是一个header，我们去服务器取数据的时候会带上这个header，比如 ETag："xxxxxx"; 服务器收到这个header之后，就会去做验证，如果验证对比了令牌后发现，没有变化，则返回“304 Not Modified”响应，告诉浏览器缓存重点数据没有发生什么变化，可以继续使用，那么我们接受到响应后，更新本地的缓存时效，进而继续使用缓存；
借用官方的图：
2，Cache-Control 缓存控制
（1）Cache-Control是用来干嘛的？
Cache-Control是用来定义缓存策略的，比如定义某个资源在什么场景下，缓存多长的时间，本质上是一个header；
Cache-Control是在 HTTP/1.1 规范中定义的；
（2）Cache-Control怎么定义缓存策略？
Cache-Control通过header定义的缓存指令来实现缓存策略，比如Cache-Control：max-age = 180；
（3）缓存指令有哪些？
请求指令：
-
no-cache：会先通过ETag验证令牌和服务器进行通讯，判断服务器的数据是否有修改过，如果有修改过，则使用服务器返回的新的数据，否则的话就取缓存，使用这个指令会和服务器进行一次通讯；
-
no-store：指令为"no-store"的情况下，一律不进行缓存，都是从服务器取数据，一般用于需要安全的场景或者需要实时刷新的场景；
-
max-age：表示当前请求的响应体的有效时间为多长，超过了这个时效则从服务器取数据；
-
public：表示可以被任何中间者（代理服务器，cdn等）或者浏览器缓存数据，通常情况下，public并不是必须的指令，有其他指令（比如max-age）表示了该请求可以被缓存；
-
private：表示不可以被任何中间者（代理服务器，cdn等）缓存数据，但是浏览器可以缓存该指令的数据；
3、Expires缓存头
Expires相应头包含日期和时间，下次请求时，会将本地时间和这个时间做比较，如果如果缓存有效，则取缓存，但是由于本地时间和服务器时间不同步，用这个来判断缓存时效会存在不准的问题，因此在HTTP1.1之后更多的是使用Cache-Control 指令，更加灵活；
4、Cache-Control在okhttp中的体现
final CacheControl.Builder builder = new CacheControl.Builder();
builder.noCache();//不使用缓存，全部走网络
builder.noStore();//不使用缓存，也不存储缓存
builder.maxAge(10, TimeUnit.MILLISECONDS);//指示客户机可以接收生存期不大于指定时间的响应。
CacheControl cache = builder.build();//cacheControl
复制代码9、http的发展史
9.1、HTTP 0.9
万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（IETF）在1991年的时候制定了 HTTP 0.9 标准，那时候只支持GET方法请求；
9.2、HTTP 1.0
从单一的GET方法请求，新增了POST请求，支持发送任何格式的内容，包括文本，视频，音乐，和二进制文件；
请求体和返回体的格式也变了，新增了头信息（Header），状态码（status code），多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等功能；
缺点：
（1）连接无法复用，浏览器和服务器只能建立短暂的TCP连接，当请求完毕之后，就关闭该TCP连接；如果需要重新请求，则需要重新建立TCP连接，会导致资源的浪费，以及响应的时间；
（2）Head-Of-Line Blocking（HOLB，队头阻塞），在TCP连接中，请求是有序的，只有当服务器处理完前一个请求后，才会处理下一个请求，如果前一个请求速度较慢，就会造成后续请求阻塞等待的情况出现；
9.3、HTTP 1.1
HTTP 1.1是当前最流行的http版本；
优化点：
（1）缓存：在 HTTP 1.0 中主要使用 header 里的 If-Modified-Since，Expires 来做为缓存判断的标准，HTTP 1.1则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since等更多可供选择的缓存头来控制缓存策略。
（2）带宽的优化：新增了range头字段，用于分块传输，允许请求当前文件的部分内容，这样可以大大减少网络带宽的占用；
（3）新增了24 个错误状态响应码
（4）长链接：头字段新增了Connection：keep-alive，表示可以复用一部分链接，在tcp连接上可以传达多个请求，以此来减少建立和连接带来的消耗；
（5）增加管线化技术（pipelining），在当前请求还没有返回时，可以发送下一个请求到服务器，以此来降低请求时间；
缺点：
（1）长链接：虽然加入长链接可以减少建立和连接带来的消耗，但是不同的域名的链接不能复用，只能重新创建长链接，会耗费资源，并且给服务器带来巨大的压力；
（2）在header中携带请求的数据量过大，造成流量的浪费，如果每次请求header的内容不变，但是header携带的数据量又很大的情况下，就会造成资源的浪费；
（3）HTTP 1.1虽然引入了pipelining来解决队头阻塞问题（Head-Of-Line Blocking），即浏览器可以同时发送多个请求给服务器，不必等到上一个请求返回之后再进行请求，但是服务器的处理是等处理完当前请求的响应之后，才会去处理下一个请求的响应，即使当前很多请求都已经处理完了，服务器还是得根据请求的顺序来进行响应；
因此它不是真正的多请求协议，但是是一个很好的改进；
9.4、HTTP 2.0
HTTP2.0基于谷歌开发的SPDY协议，而HTTP 2.0相对于HTTP 1.1带来了什么新的改进呢？
优化点:
（1）多路复用：对于HTTP1.1中，如果当前有多个请求，请求的发送都是串行执行的，对于宽带的利用效率不高，但是在HTTP 2.0中，多个请求可以并行请求，大大的提升了宽带的利用率；
（2）Header压缩：使用首部表来跟踪和存储之前发送的键值对，对于相同的内容，不会再每次请求和响应时发送。
（3）数据优先级：由于请求可以并发发送给服务器，但是服务器还是遵循先进先出的规则来处理请求，但是在HTTP 2.0中可以设置当前请求的优先级，这样服务器在处理请求的响应时，会优先返回优先级较高的请求；
（4）服务端推送：对于请求，一般都是浏览器或者客户端发送给服务器，服务器处理之后再返回，但是在HTTP 2.0中服务器可以推送相关文件给客户端，客户端再进行相应的处理，而不必等客户端发送请求之后再返回给客户端；
10、断点续传功能是怎么实现的？
10.1、原理
原理很简单，就是从停止下载的地方继续下载，比如我下载了10兆，文件总共有20兆，此时的断点下载就是从10兆开始进行续传，继续下载的；
10.2、核心
通过http的Range头字段来实现的，Range头字段支持从服务器或者指定内容范围大小的文件，比如我想要或者某个文件的前1024字节的数据，那么我只需要传 Range: bytes=0-1024 （0到1024字节的数据），这样就可以从服务器获取到对于字节的数据了；
10.3、好处
断点续传的好处就是传输效率高，比如下载一个文件，在传输过程中受网络影响中断了，这时不需要在开头重新下载，而是在停止的地方继续下载；
断点续传还可以通过多线程来提高效率，比如下载一个文件，我可以开10个线程或者20个线程来分段下载文件，这样可以大大的提高下载速度，像迅雷或者百度云大多都是这种原理，只是更加复杂；至于最多能开多少线程进行下载， 要看当前客户端的性能；
10.3、客户端的实现
数据库：用于存储断点下载的其实位置；
多线程：用于加快下载速度；
RandomAccessFile类：Java提供的对文件内容的访问，既可以读文件也可以写文件，可以访问文件的任意位置适用于由大小已知的记录组成的文件；
下面从一张图来看看具体实现：
参考&感谢
作者：Amter
链接：https://juejin.cn/post/6844904116712374285
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
290
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
