2http简体概况

Posted 2021-04-26 茄子的笔记

http整体概况

我不知将去何方，但我已经在路上。
                                                                                                    --《千与千寻》

简单的一句话，包含了不少的唏嘘，送给正在努力的你。

写前的话:

今天继续上一篇分享的<<图解HTTP>>书的第一章后，第二篇博文，本章是从书中2,3,4,5 章的内容中抽离出来，看起来一本书的4章似乎很多，但其实内容并不多。

1 简单的http协议概况

1.1http无状态协议

http是一种不保存状态，即无状态协议，说白了，就是不保存请求和响应之间的通信状态，这些请求和响应都不做持久化处理。这样做的好处就是能尽快的处理大量事务，可是后来随着技术发展，业务需要状态保存，引入了cookie技术。有了cookie再加上http协议通信就可以管理状态了。

1.2 URI和URL 傻傻分不清楚

URI是  Uniform  Resource Identifier 的缩写，其中

Uniform ：表示规定统一的格式，例如使用ftp协议传输URI 的前缀是“ftp:”开头，而用http协议传输URI的前缀是“http:” 这样的目的是为了扩展更多的协议，

Resource: 表示可以标识的任何东西，万物不在皆对象了，而是万物皆为资源，例如文件图像，或服务等....

identifier: 表示可标识的对象。也称为标识符。

总结：就是某个协议方案表示资源的定位标识符。

长连接的来由：原始的http协议，每次通信都要断开一次tcp连接。因为当年传输访问的容量很小的文本传输，但是现在一个html文档中会包含多个图片，所以为了省去无谓的tcp连接建立和断开增加了通信的开销，出现了持久连接的解决方案，称为HTP keep-alive,只要任意一方没有明确提出断开连接，则保持tcp连接状态。

好处是，减小了时间开销，http请求和响应能更早结束，减轻服务器压力。在http1.1中默认是长连接，并且这种连接的保持应该是服务端和客户端同时支持才行。

管线化：因为持久连接的出现，使得请求以管线方式发送称为可能，因为之前是发送请求，等待并接收到响应后才能，发送另一个请求，其实应该称为并发了，在简而言之，长连接相当于建立一个平稳的管道，而管道可以并行建立多个。

cookie：状态的协议有优点是减少服务器的cpu资源及内存的消耗，想想一个画面，成千上万的浏览器请求，一个服务器，但是一个服务器来记录每一个请求的状态，肯定吃不消。可是随着业务逻辑的发展越来越多需要保存状态，流程如下：

1 客户端发送请求，服务端返回响应，其中响应中一定有Set-Cookie的首部字段信息，客户端接受会保存，而服务端会自己记录这个cookie发送给了哪个客户端。

2 客户端第二次请求时，请求中会带着上一次响应给的cookie

编码提升传输效率：http传输时可以通过编码提升传输效率，但是编码需要用到cpu的资源，所以这是一个权衡利弊的一个点，而内容编码后的实体内容由客户端接收并解码。编码方式有以下几种：

gzip,compress (UNIX系统的标准压缩) ，deflate(zlib),identity(不进行压缩)

一般 为  Content-Encoding:gzip

分块传输编码：客户端请求大量数据时，服务端通过把数据分割成多块，能够让浏览器逐步显示页面，是不是明白了为啥网卡的时候，一个图片是一点一点显示出来，而不是一下子完整展现的了。注意：每次数据包会用一个十六进制标记块的大小，而实体最后一块用 “0（CR+LF）”来表示

1.2 http结构定义

名词解释：

客户端(client)：发起请求的一端。【web开发时通常是浏览器】

服务端(server)：回复（响应）请求的一端。【一般是指我们的服务程序响应的结果，而这个结果基本上是被包装】

前提：client与server ，间建立起通信，肯定是从客户端开始建立的，服务端在没有接受到请求之前不会发送响应

以下出示两个请求报文和响应报文的小例子

有电脑可以看此链接原图：https://www.processon.com/view/link/5fff143b1e0853437c436bd4

请求报文结构图如下

响应报文结构图如下

根据上面我的绘图，后续我们主要分析请求与响应中的报文首部区域，报文首部区域由四部分组成，状态行，请求/响应首部字段，通用首部字段，实体首部字段，组成的。

•     首先分析状态行：

  请求报文的状态行

  GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1

  方法   URI                                                                 协议版本         // (此行对应上一行映射)

  其中方法有：

  GET：一般用于URL的参数拼接。

  POST：一般为传输实体对象，后台入参通常为一个实体对象。

  PUT:一般用来传输文件，但是没有验证机制，任何人都可以穿，所以一般web网站不使用。

  DELETE:删除文件的方法，是PUT的反方法，所以一般不会做。

  HEAD：和get方法一样，区别是不返回报文主体。

  OPTIONS:查询某个URI制定的资源，支持哪些方法。

  
  

  响应报文的状态行

  HTTP/1.1    200     OK

  协议版本  状态码  状态码短语         //（此行对应上一行映射）

  协议版本忽略，直接分析下状态码。

  ---

  状态码

  2XX

  2XX的响应结果表明请求被正常处理了。

求被正常处理了 ，并且返回实体资源。

请求被正常处理了，但是没有实体资源可以返回。举例：如果一个表单提交的地址为xx.htm ,正常情况下会跳转到这个页面中去，但是如果，不想跳转则响应码应该改为204，所以对于一些提交到服务器处理的数据，`只需要返回是否成功`的情况下，可以考虑 使用状态码204来作为返回信息，从而省掉多余的数据传输。

 

当客户端请求，某个资源的部分片段时候，响应码为206，而客户端头部头部通常会含有Content-Range字段,一般用于客户端去加载，或者下载一个未完成的下载较大的文件，其实通常是我们下载某个大文件时，因为网络的中断，浏览器会有选项选择继续下载，或者取消。
我们从一个设计者的角度来看待，关于客户端请求     服务端的 大文件资源部分片段，需要考虑哪些因素

从客户端角度来出发：
先假定这样的场景：
100M 的大文件 ，已经下载50M,而目前由于网络中断，还有50M没有下载，想继续下载后面50M要有这些考虑
1 前50M的文件现在还准不会不会有人已经更新了内容，所以让服务端那边帮忙校验下服务端的资源，到底改没改，并且是校验下，这个资源在某时某刻之后没有被更改，因为更改了那就不是我最初想要下载的文件了。
2 如果上一步没问题，便能继续请求服务端返回剩下的50M资源了，例如请求头中增加一个范围字段，表明告诉服务端要从哪个部分返回。额文字描述还是不太好....还是画个图吧。

之所以说介绍了这么多206码，它可以增加我们的想象空间，如果将来做文件下载时不考虑网络带宽情况下，并发下载，增加下载速度无疑提高性能。

补充：

如果服务器发现该资源的版本与客户端所请求的版本不匹配,则会返回一个HTTP/412 Precondition Failed响应.如果客户端使用If-Range请求头而不是If-Match发送了上次收到的ETag响应头的值,且服务器发现客户端请求的版本与当前资源的版本不匹配,则服务器会返回整个资源数据

Range：字段

Range头域可以请求实体的一个或者多个子范围，Range的值为0表示第一个字节，也就是Range计算字节数是从0开始的：表示头500个字节：Range: bytes=0-499表示第二个500字节：Range: bytes=500-999表示最后500个字节：Range: bytes=-500表示500字节以后的范围：Range: bytes=500-第一个和最后一个字节：Range: bytes=0-0,-1也可以同时指定几个范围：Range: bytes=500-600,601-999

参考

https://blog.csdn.net/dong123dddd/article/details/52038729

https://www.cnblogs.com/simonbaker/p/5190675.html

---

 3XX重定向

永久重定向服务端请求的资源，已经换了URI，客户端将重新访问新的页面。URL浏览器上将去访问新的地址。

临时重定向，服务端会去改变的资源下返回资源给客户端，URL在浏览器上没哟变化

询问服务端，某某URL的资源地址是否变化。但客户端请求必须为get

和重定向没有 任何关系，客户端请求的资源，服务器找到了，但是客户端还有附加的条件，而未符合条件请求。

---

4XX客户端错误

请求报文中存在语法错误，就是客户端发送了错误的请求内容

请求资源的访问被服务器拒绝了，服务器一般不会必要给出理由，如果想做说明的话，可以在实体主体部分对原因进行描述

404就不说 了，因为就是没有这个资源

---

5XX服务器错误

内部资源故障，一般是web应用存在的bug或某些临时的故障

如果你能看到这里了，不如点赞鼓励一下，我会认真分享每一篇博文。大家共同成长。