小白自学http网站的请求命令和基础原理集锦（HTTP工作原理；GET, POST,HEAD,OPTIONS, PUT,PATCH,DELETE,TRACE 和 CONNECT 方法）

参考及引用文章：
MDN：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode
HTTP 8种请求方式介绍:
https://www.cnblogs.com/songyao666/p/11453529.html
HTTP ：
https://www.runoob.com/http/http-methods.html
如何理解HTTP协议的 “无连接，无状态” 特点？
https://blog.csdn.net/tennysonsky/article/details/44562435
HTTP请求详解含POST，GET实例
https://blog.csdn.net/phineas123/article/details/80207136
http请求报文格式和响应报文格式
https://www.cnblogs.com/linliquan/p/11362336.html

本文主要是自学记录，以及供他人免费参考我的学习整合及心得，因此可能会涉及到侵犯版权的问题和错误。
如若侵犯版权还烦请联系我，十分感谢，以及对给您造成的不便表示万分抱歉。
本文添加了很多自己的理解，错误在所难免，还望指出共同学习。

- HTTP工作原理

• 特点：

1.无连接：即每次只能处理一个请求，完成当前请求就断开连接

优点：断开连接。采用这种方式可以节省传输时间。
缺点：如果每次访问都需要建立一次 TCP 连接就显得很低效，尤其是网页中含有大量图片。

早期这么做的原因是 HTTP 协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，大部分通道实际上会很空闲、无端占用资源。因此 HTTP 的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。

解决方案：为解决无连接传输效率低的状况，提出Keep-Alive

Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。市场上的大部分 Web 服务器，包括 iPlanet、IIS 和 Apache，都支持 HTTP Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive 功能对资源利用的影响尤其突出。

2.独立媒体：可以传输任何数据，怎么处理则是客户端和服务器各自的任务。

3.无状态：对事物处理没有记忆，交换完数据，直接忘了刚才交换的是什么，啥也不管啥也不问，一忘解千愁。
优点：在服务器不需要先前信息时它的应答就较快。 缺点：缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。

客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是，两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。

解决方案：为解决无状态的问题两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。

• Cookie可以保持登录信息到用户下次与服务器的会话，换句话说，下次访问同一网站时，用户会发现不必输入用户名和密码就已经登录了（当然，不排除用户手工删除Cookie）。而还有一些Cookie在用户退出会话的时候就被删除了，这样可以有效保护个人隐私。
  Cookies 最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入 Cookies，以便在最后付款时提取信息。
• 与 Cookie 相对的一个解决方案是 Session，它是通过服务器来保持状态的。
  当客户端访问服务器时，服务器根据需求设置 Session，将会话信息保存在服务器上，同时将标示 Session 的 SessionId 传递给客户端浏览器，浏览器将这个 SessionId 保存在内存中，我们称之为无过期时间的 Cookie。浏览器关闭后，这个 Cookie 就会被清掉，它不会存在于用户的 Cookie 临时文件。

以后浏览器每次请求都会额外加上这个参数值，服务器会根据这个 SessionId，就能取得客户端的数据信息。
如果客户端浏览器意外关闭，服务器保存的 Session 数据不是立即释放，此时数据还会存在，只要我们知道那个 SessionId，就可以继续通过请求获得此 Session 的信息，因为此时后台的 Session 还存在，当然我们可以设置一个 Session 超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应 SessionId 的 Session 信息。

备注：
Cookie相当于自己手上的笔记，记下上次完成的记录和位置
而session相当于其他人的笔记，不占用自己的纸，当自己的笔记丢失了还能借鉴他人的笔记。
发明笔记的目的就是怕大家记性太差，做完事情就忘，同样也是为了让人能全身心投入下一件事，不用再管上一件事的繁文缛节而发明的。

- HTTP报文

• 1.请求报文

HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成

请求行：由方法字段、URL 字段 和HTTP 协议版本字段 3 个部分组成
请求方法 空格 URL 空格 协议版本 回车符 换行符

谷歌首页预览图

谷歌请求头文件：

从中可以看到我自己打开谷歌首页（2020.4.26-alvin解语花言chrome打开）显示：
请求方法是GET方法，请求方法写在下面。
scheme协议：https。
Accept 头属性能被用在浏览器响应能接受的media 类型，内容类型中的先后次序表示客户端接收的先后次序，可以使用XMLHttpRequest 对象中setRequestHeader函数方法来随意设置这些Header。
accept-encoding表示你发送请求时告诉服务器，我可以解压这些格式的数据。（content-encoding是指网页使用了哪种压缩方式传输数据给你）可以看到这里是gzip，deflate以及br格式

（拓展：https://zhuanlan.zhihu.com/p/35643926）

accept language：指定优先使用的语言，这里默认的是优先使用英文，其次是中文
Sec-Fetch-Dest：获取元数据报头指示该请求的目的地，即所获取的数据将如何使用，在此是使用document文档格式。

secp - fetch - site ：获取元数据头表示请求发起者的源和资源的源之间的关系。这里是没有关系。

Sec-Fetch-mode：获取模式的获取元数据头指示请求的模式。negative没找到代表什么，知道的请补充。

User-Agent：HTTP客户端运行的浏览器类型的详细信息。通过该头部信息，web服务器可以判断到当前HTTP请求的客户端浏览器类别。这里展示了我操作系统版本等等信息。
x-client-data：用于追踪使用者

• 2.响应报文
  HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成，如下图所示：
  
  状态行：状态行由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成
  状态行：
  协议版本 空格 状态码 空格 状态描述 回车符 换行符

● 状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：
　　1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;
　　2xx：表示服务器已成功接收到请求并进行处理;
　　3xx：表示服务器要求客户端重定向;
　　4xx：表示客户端的请求有非法内容;
　　5xx：表示服务器未能正常处理客户端的请求而出现意外错误;

Content-Encoding
包含的数据内容格式，这里是br，服务器收到我们可以使用 br 压缩数据。

- 请求方法

HTTP/1.1协议中共定义了九种方法（大多数教程都写八种，但是不知道为什么定义了九个，这里就写九种，有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了六种请求方法：OPTIONS, PUT, DELETE, PATCH,TRACE 和 CONNECT 方法

注意：

• 1.post特点

1、post提交数据相对于get的安全性高一些。（注意：抓包软件也会抓到post的内容，安全性要求高可以进行加密）
2、传递数据量大，请求对数据长度没有要求。
3、请求不会被缓存，也不会保留在浏览器的历史记录中。
4、用于密码等安全性要求高的场合，提交数据量较大的场合，如上传文件，发布文章等。
5、POST方式提交数据上限默认为8M（可以在PHP的配置文件post_max_size选项中修改）

• 2.GET与POST区别：

（1） 在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在HTML HEADER内提交。
（2） GET方式提交的数据最多只能有1024字节，而POST则没有此限制。
（3） 安全性问题。正如在（1）中提到，使用 Get的时候，参数会显示在地址栏上，而 Post不会。
（4） 安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。

选择：
如果这些数据是中文数据而且是非敏感数据，或是不改变服务器上的资源的请求，那么使用 get；
如果用户输入的数据不是中文字符而且包含敏感数据，或是改变服务器上的资源的请求，如：读者对文章的注解应该通过 POST请求实现，因为在注解提交之后站点已经不同了，那么还是使用 post为好。

备注：
POST 是被设计用来向上放东西的，而GET是被设计用来从服务器取东西的，GET也能够向服务器传送较少的数据，而Get之所以也能传送数据,只是用来设计告诉服务器,你到底需要什么样的数据.POST的信息作为HTTP 请求的内容，而GET是在HTTP 头部传输的；

• 3.“header”的分析

可以看到我这里请求方法是POST，因为展示的网页是交互式的动态网页，使用POST会更好。
Referrer Policy：用于指明当前流量的来源参考页面。通过这个信息，我们可以知道访客是怎么来到当前页面的。这对于Web Analytics非常重要，可以用于分析不同渠道流量分布、用户搜索的关键词等。但是也有造成数据泄露的风险。这里origin是指：在任何情况下，仅发送文件的源作为引用地址。例如 https://alvincr.com/page.html 会将https://alvincr.com/ 作为引用地址。
Remote Address：指远程连接的地址即IP。

新的Referrer规定了五种策略：
No Referrer：任何情况下都不发送Referrer信息
No Referrer When Downgrade：仅当协议降级（如HTTPS页面引入HTTP资源）时不发送Referrer信息。是大部分浏览器默认策略。
Origin Only：发送只包含host部分的referrer.
Origin When Cross-origin：仅在发生跨域访问时发送只包含host的Referer，同域下还是完整的。与Origin Only的区别是多判断了是否Cross-origin。协议、域名和端口都一致，浏览器才认为是同域。
Unsafe URL：全部都发送Referrer信息。最宽松最不安全的策略。
——转载：https://www.cnblogs.com/amyzhu/p/9716493.html

Status Code：200表示从客户端成功发出去请求到服务端了,服务端也接收到了这条请求并正确返回。204 No Content 请求已经成功了，但是却没有返回任何结果（实体），可以使用php die() exit()函数会引发204状态码。

其它返回值参照上文。也可以参照：https://www.cnblogs.com/chaoyangya/p/10490519.html