【网络】HTTP原理的简单理解
目录
1.HTTP的基本介绍
- HTTP协议（超文本传输协议），它是一种详细规定了浏览器和万维网（WWW）服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。
- HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议；
- HTTP默认的端口号是80，HTTPS默认的端口号为443
- 浏览网页是HTTP的主要作用，但是这并不代表HTTP就只能应用于网页的浏览。HTTP是一种协议，只要通信的双方都遵循这个协议，HTTP就能有用武之地。比如常用的QQ、迅雷这些软件，都会使用HTTP协议。
2.HTTP的特点
- 简单快速：客户向服务器请求服务时，只需传送请求方法和路劲。请求方法常用的有GRT、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快；
- 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记；
- 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理万客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间；
- 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
- 支持B/S及C/S模式。
3.认识URL
HTTP使用统一资源标识符（URI）来传输数据和建立连接。URL（统一资源定位符）是一种特殊类型的URI，包含了用于查找某个资源的足够的信息，我们通常用的就是URL。
3.1 URL
全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：
- 协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符
- 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
- 端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口
- 虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
- 文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
- 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
- 参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。
（参考文章：https://blog.****.net/ergouge/article/details/8185219）
3.2 URI和URL的区别
URI（uniform resource identifier）：是统一资源标识符，用来唯一的标识一个资源，web上可用的每种资源如HTML文档、图像、视频片段、程序等都是由一个URI来定位的。
URI有三部分组成：访问资源的命名机制；存放资源的主机名；资源自身的名称，由路径表示，着重强调于资源。
URL（uniform resource locator）：是统一资源定位符，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。
URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等
4.HTTP协议
作用：HTTP协议和TCP/IP协议族内的其他协议相同，，用于客户端和服务之间的通信。请求访问文本或图像等资源的一段称为客户端，而提供资源响应的一段称为服务端。
4.1 请求消息Request
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。
HTTP请求消息结果如下：
请求行以一个方法符开头，以空格分开，后面跟着请求的URI和协议的版本
空行将报头和有效载荷分离
解释：
- 请求行：说明请求方法+URL+版本
- 请求报头（Header）：请求的属性，冒号分割的键值对；每组属性之间使用\n分割；遇到空行表示Header部分已经结束
- 空行：它用于区分报头和有效载荷
- 正文（Boby）：也叫请求数据，空行后面的内容都是Body,Body允许为空字符串，如果Body存在，则在Header中有一个Content-Length属性来标识Body的长度
4.1.1 请求报头中Header中的属性
冒号分隔的键值对 每组属性时间用\n分隔，遇到空行请求报头结束。
- Host ：客户端告知服务器，所请求的资源是在哪个主机的那个端口上
- Content-length：正文长度 避免多读或者少读
- Origin: 完整的url请求
- Content-Type :正文类型
- User-Agent:声明用户的操作系统和浏览器的版本信息
- Accept：代表客户端所能接收的资源 如图片、html等
- Referer: 当前页面是从哪个页面跳转过来的
- Accept-Encoding、Accept-Language:客户端所有识别的编码语言
读到空行即把http请求的报头读完了，根据post、get方法了解此次协议有没有正文，根据Content-length获取正文的长度。
4.1.2 长连接和短连接
HTTP应用层，下层是TCP协议，TCP是面向连接的，想通信之前就得建立连接，即HTTP要通信就得建立连接，服务器响应连接，断开连接。
HTTP1.0中，默认使用的是短连接。即浏览器和服务器没进行一次HTTP操作，就建立一次连接，任务结束就断开连接。当浏览器访问的某个HTML或其他类型的Web页内包含有其他的Web资源（Js资源，css文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP链接。就导致一张HTML页面可能就会建立几十次连接，这种操作导致网页刷新速度变慢，影响用户的体验。
在HTTP1.1起，默认使用长连接。用以保持连接特性。（长连接通常在响应头会添加Connection:Keep-alive）使用长连接的情况下，当某个网页打开完毕之后，客户端和服务器之间的TCP连接不会关闭，如果客户单再次访问该服务器上的网页，会使用上一次已经建立的连接。长连接不是永久连接，他有一个保持时间。实现长连接的前提是客户端和服务端都需要支持长连接。
我们都知道，HTTP是基于TCP的应用层协议。HTTP的长连接和短连接，本质就上是TCP的长连接和短连接。基于TCP的协议，在数据通信之前要完成三次握手，结束通信需要完成四次挥手。每次建立连接都是需要时间代价的。
短连接：
过程：建立连接——数据传输——关闭连接……建立连接——数据传输——关闭连接
模拟一下TCP短连接的情况，Client向server发起连接请求，server接到请求，然后双方建立连接，Client向server发送消息，server回应client，然后一次读写就完成了，这是双方任意一放都可以发起close请求。一般都是client发起close请求。
短连接一般用于一点对多点通讯，C/S通信。
长连接：
过程：连接——传输数据——保持连接——传输数据——保持连接——关闭连接
长连接指三次握手建立连接后，完成一次读写操作，一段时间内，该连接不会关闭，之后如果还有向该server发起的数据读写，仍然使用该该连接。这与之前提到的TCP通信过程类似，因为要考虑在连接保持期间client始终处于正常状态（防止server端保存大量的半连接状态的socket），这就要牵扯到之前的TCP维护的四个定时器中的保活寄存器。相对于短连接而言，长连接安全性一般。
长连接和短连接的特点：
对于短连接而言，管理起来较为简单，因为短连接存在的连接都是有效的，不需使用额外的方法来维护；带来的缺点就是多次建立连接的请求，时间代价较大，占用的带宽也是一个很大的问题。
对于长连接而言，client端通常不会主动关闭连接，而是由服务器决定的。因此server需要提供一套机制来管理这些保持的连接。如果client连接server之后，长时间没有进行传递，大量的client连接会使server的负担加重，因此server需要提供一种机制，用来关闭即使client处于正常状态但长时间没有进行数据通信的连接，如果条件允许，可以在server端限制最大连接数，来避免个别客户端对服务器的拖累。
使用场合：
长连接多用于操作频繁，点对点的通信，且连接数不太多的情况。如数据库的连接使用长连接。短连接要求每次数据处理之前，都需要建立连接，对于需要大量访问数据库的操作，建立连接是对资源极大的浪费，而且容易导致socket错误。
短连接通常用于大型网站的访问。原因很简单，成千上万的client访问server，如果每个client保持一个连接，服务器是难以负荷的。即使可以调度，代价也是很大的。
4.1.3 重定向 location
客户端发起请求，响应中如果包含location字段，浏览器会自动跳转，常与3xx的状态码搭配使用，告诉客户端接下来访问哪里。
4.2 响应消息Response
一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP相应的消息。
HTTP响应也由四个部分组成：状态行、消息报头、空行和响应正文。
空行将报头和有效载荷分离
- 状态行：版本号+状态码+状态码解释
- Header: 请求的属性, 用来说明客户端要使用的一些附加信息；冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
- 空行：将报头和有效载荷分离
- Body: 空行后面的内容都是Body.，服务器返给客户端的文本信息；Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页面内容就是在body中。
4.3 HTTP的状态码
状态码有三位数字组成，第一个数字定义了相应的类别，共分为五种类别：
| 类别 | 原因 | |
| 1xx | Informational（信息性状态码） | 请求已经接受，正在处理 |
| 2xx | Success（成功状态码） | 请求正常处理完毕 |
| 3xx | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4xx | Client Error（客户端错误状态码） | 请求有语法错误或请求无法实现 |
| 5xx | Server Error（服务器错误状态码） | 服务器处理请求出错 |
常见的状态码：
2xx成功
- 200：（OK） 客户端发过来的数据被正常处理
- 204：（Not Content ）正常响应，没有实体
3xx 重定向
- 301：（Moved Permanently） 永久重定向
- 302：（Found） 临时重定向，规范要求，方法名不变，但是都会改变
- 303：（See Other ）和302类似，但必须要用GET方法
- 304：（Not Modified ）状态未改变
- 307：（Temporary Redirect） 临时重定向，不该改变请求方法
4xx 客户端错误
- 400：（Bed Request） 请求报文语法错误
- 401：（unauthorized）需要认证
- 403：（Forbidden）服务器拒绝访问对应的资源
- 404：（Not Found）服务器上无法找到资源
5xx 服务器端错误
- 500：（Internal Server Error）服务器故障
- 503：（Service Unavailable）服务器处于超负载或正在停机维护
（更多的状态码见：https://www.runoob.com/http/http-status-codes.html）
5.HTTP1.1
5.1 HTTP1.1的介绍
HTTP协议的初始版本中， 每进行一次 HTTP通信就要断开一次TCP连接，因为都是些容量很小的文本传输， 所以即使这样也没有多大问题。 但是随着HTTP的普及， 文档中包含大量图片的情况多了起来。
比如，使用浏览器浏览一个包含多张图片的HTML页面时，在发送请求访问HTML页面资源的同时，也会请求该HTM页面里包含的其他资源。因此，每次的请求都会造成无谓的TCP连接建立和断开，增加通信量的开销。
为解决上述TCP连接的问题， HTTP/1.1和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections， 也称为 HTTPkeep-alive 或HTTP connection reuse）的方法。 持久连接的特点是， 只要任意一端没有明确提出断开连接， 则保持TCP连接状态。持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销， 减轻了服务器端的负载。 另外， 减少开销的那部分时间， 使HTTP请求和响应能够更早地结束， 这样 Web 页面的显示速度也就相应提高了。
在HTTP1.1中，所有的连接默认都是持久连接的。
持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应也可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。
5.2 HTTP1.1和HTTP1.0的区别
- 带宽优化及网络连接的处理：在HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持点续传功能；HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
- 长连接：HTTP1.1支持长连接和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection：keep-alive，一定程度上弥补了HTTP1.0每次都要创建连接的缺点；
- 缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
- Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求信息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且他们共享一个IP地址。HTTP1.1的请求消息和响应消息都应该支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400）。
- 错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Confllct）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
6.HTTP的请求方法
根据HTTP标准，HTTP请求可以使用多种请求方法。
- HTTP1.0定义的三种请求方法：GET，POST，HEAD方法
- HTTP1.1新增了五种请求方法：OPTIONS,，PUT，DELETE,，TRACE 和 CONNECT 方法
| 方法 | 说明 |
| GET | 获取资源，请求指定的页面信息，并返回实体主体 |
| POST | 传输实体主体，向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。 |
| PUT | 似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| HEAD | 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头 |
| DELETE | 请求服务器删除指定的页面。 |
| OPTIONS | 允许客户端查看服务器的性能。 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
| CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| LINK | 建立和资源之间的联系 |
| UNLINE | 断开连接关系 |
（后续未完，其他博客总结）
参考：https://www.cnblogs.com/ranyonsue/p/5984001.html
参考：图解HTTP