HTTP之原理,长短连接,响应码,八种方法,与RPC区别

目录

学习此文章需要有OSI七层模型基础知识
点击了解三次握手四次挥手相关信息

1 HTTP原理

HTTP是一个无状态的协议。无状态是指客户机（Web 浏览器）和服务器之间不需要建立持久的连接，这意味着当一个客户端向服务器端发出请求，然后服务器返回响应(response)，连接就被关闭了，在服务器端不保留连接的有关信息.HTTP 遵循请求(Request)/应答(Response)模型。客户机（浏览器）向服务器发送请求，服务器处理请求并返回适当的应答。所有 HTTP 连接都被构造成一套请求和应答

1.1 HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另一端收到发端发出的所有包，并且顺序与发出顺序一致。TCP有可靠，面向连接的特点。

1.2 无状态的HTTP协议

HTTP协议是无状态的，指的是协议对于 事务处理 没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

1.3 与RPC区别

1.3.1 RPC简介

RPC(Remote Procedure Call：远程过程调用)：是一种进程间通信方式，是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

通俗的说法就是：比如说现在有两台服务器A和B，一个应用部署在A服务器上，另一个应用部署在B服务器上，如果A应用想要调用B应用提供的方法，由于他们不在一台机器下，也就是说它们不在一个JVM内存空间中，是无法直接调用的，需要通过网络进行调用，那这个调用过程就叫做RPC。
在这里插入图片描述
在这里插入图片描述

RPC两个核心模块：通讯，序列化
注意：无论是何种类型的数据，最终都需要序列化转换成二进制流在网络上进行传输，数据的发送方需要将对象序列化转换为二进制流，而数据的接收方则需要把二进制流反序列化为对象。

1.3.2 Restful（HTTP）

Restful 指的是一组架构约束条件和原则。如果一个架构符合 Restful 的约束条件和原则，就称它为 Restful 架构。隐藏在 Restful 背后的理念就是使用 Web 的现有特征和能力，更好地使用现有 Web 标准中的一些准则和约束。

虽然 Restful 本身受 Web 技术的影响很深， 但是理论上 Restful 架构风格并不是绑定在 HTTP 上，只不过目前 HTTP 是唯一与 Restful 相关的实例。所以这里描述的 Restful 也是通过 HTTP 实现的 Restful

1.3.3 RPC和HTTP的区别

首先，两者十分相似，有请求有响应

不同：

  • RPC 需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进行封装。
  • Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。

优点：

  • RPC更加透明，对用户方便。
  • HTTP方式更加灵活，没有规定API和语言，跨语言，跨平台。

缺点：

  • RPC需要在API层面进行封装，限制了开发的语言环境。

选择：

  • 速度方面：RPC速度比HTTP快，底层都是TCP，HTTP消息往往比较臃肿，但是可以采用gzip压缩。
  • 难度方面：RPC实现有点儿复杂，HTTP相对比较简单。
  • 灵活性方面：HTTP更灵活，不需要关系实现的细节，可以跨平台，跨语言。

未来发展方向：

  • 微服务，强调独立，自治，灵活。RPC限制较多，因此微服务框架中，一般都会采用基于HTTP的rest风格服务。

2 长短连接详解

2.1 简介

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接

2.2 TCP短连接

我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起 close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在 client/server间传递一次读写操作
短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

2.3 TCP长连接

模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应该等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

  1. 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
  2. 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
  3. 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。
  4. 客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

2.4 长连接短连接操作过程

短连接的操作步骤
建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接
长连接的操作步骤
建立连接——数据传输…（保持连接）…数据传输——关闭连接

2.5 长连接和短连接的优点和缺点

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。
在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。
长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

2.6 什么时候用长连接，短连接

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。
例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好

3 HTTP发送过程解析

3.1 概述

HTTP协议是基于请求／响应的运作方式：

  • 建立连接 ：连接的建立是浏览器通过创建套接字(Socket)实现的。浏览器打开一个套接字并把它约束在一个端口上，就可以在该端口上写数据并通过网络向外传送
  • 发送请求 ：打开一个连接后，浏览器把请求消息送到服务器的端口上，完成提出请求动作
  • 发送响应 ： 服务器在处理完客户的请求之后，向浏览器发送响应消息
  • 关闭连接：客户和服务器双方都可以通过关闭套接字来结束TCP/IP对话

3.2 传输流程

3.2.1 地址解析

如用客户端浏览器请求这个页面： http://localhost.com:8080/index.htm 从中分解出协议名、主机名、端口、对象路径等部分，对于我们的这个地址，解析得到的结果如下：
协议名： http
主机名： localhost.com
端口： 8080
对象路径： /index.htm13/04/2018 Page 165 of 283
在这一步，需要域名系统 DNS 解析域名 localhost.com,得主机的 IP 地址

3.2.2 浏览器查找域名的IP地址

浏览器缓存 – 浏览器会缓存DNS记录一段时间。 有趣的是，操作系统没有告诉浏览器储存DNS记录的时间，这样不同浏览器会储存个自固定的一个时间（2分钟到30分钟不等）。
系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用（windows里是gethostbyname）。这样便可获得系统缓存中的记录。
路由器缓存 – 接着，前面的查询请求发向路由器，它一般会有自己的DNS缓存
ISP DNS 缓存 – 接下来要check的就是ISP缓存DNS的服务器。在这一般都能找到相应的缓存记录。
递归搜索 – ISP的DNS服务器从跟域名服务器开始进行递归搜索，从.com顶级域名服务器到Facebook的域名服务器。一般DNS服务器的缓存中会有.com域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了

DNS有一点令人担忧，这就是像wikipedia.org 或者 facebook.com这样的整个域名看上去只是对应一个单独的IP地址。还好，有几种方法可以消除这个瓶颈：

  • 循环 DNS 是DNS查找时返回多个IP时的解决方案。举例来说，Facebook.com实际上就对应了四个IP地址。
  • 负载平衡器 是以一个特定IP地址进行侦听并将网络请求转发到集群服务器上的硬件设备。 一些大型的站点一般都会使用这种昂贵的高性能负载平衡器。
  • 地理 DNS 根据用户所处的地理位置，通过把域名映射到多个不同的IP地址提高可扩展性。这样不同的服务器不能够更新同步状态，但映射静态内容的话非常好。
  • Anycast 是一个IP地址映射多个物理主机的路由技术。 美中不足，Anycast与TCP协议适应的不是很好，所以很少应用在那些方案中

域名和ip地址对映示例：
主要通过DNS域名解析来完成的。域名解析的工作流程：

  • 客户端首先会发出一个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址）。
  • 本地域名服务器收到客户端的请求后，如果缓存里的表格能找到 www.server.com，则它直接返回 IP 地址。如果没有，本地 DNS 会去问它的根域名服务器：“老大， 能告诉我 www.server.com 的 IP 地址吗？” 根域名服务器是最高层次的，它不直接用于域名解析，但能指明一条道路。
  • 根 DNS 收到来自本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
  • 本地 DNS 收到顶级域名服务器的地址后，发起请求问“老二， 你能告诉我 www.server.com 的 IP 地址吗？”
  • 顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
  • 本地 DNS 于是转向问权威 DNS 服务器：“老三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS 服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
  • 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
  • 本地 DNS 再将 IP 地址返回客户端，客户端和目标建立连接。

至此，我们完成了 DNS 的解析过程。现在总结一下，整个过程我画成了一个图
在这里插入图片描述

3.2.3 封包过程

  1. 封装 HTTP 请求数据包
    把以上部分结合本机自己的信息，封装成一个 HTTP 请求数据包
  2. 封装成 TCP包并建立连接
    封装成 TCP 包，建立 TCP 连接（TCP 的三次握手）
  3. 客户机发送请求命
    客户机发送请求命令： 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和可内容。
  4. 服务器响应
    服务器接到请求后，给予相应的响应信息， 其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。
  5. 服务器关闭TCP连接
    服务器关闭 TCP 连接： 一般情况下，一旦 Web 服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive， TCP 连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

大致结构如下所示：
在这里插入图片描述

3.3 请求和响应

3.3.1 一般头字段

一般头字段可用于请求消息和响应消息

  • Cache-Contro : "max-age=10"
  • Connection : "close"
  • Date : "Tue, 11 Jul 2000 18:23:51 GMT"
  • Pragma : "no-cache"
  • Trailer : "Date"
  • Transfer-Encoding : "chunked"
  • Upgrade : "SHTTP/1.3"
  • Via : "HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
  • Warning : "112 Disconnected Operation"

3.3.2 请求报头域

常见的HTTP请求报头域：

  • Accept："text/html, image/*"，用于指定客户端接受哪些类型的信息。
  • Accept-Charset : "iso8859-5"，请求端在发送请求时的头部信息，这个标识的是当前客户端可以接受的字符编码(所谓字符编码就是对于可见或者不可见字符的编码方式)
  • Accept-Encoding："gzip, compress"，类似Accept，但是它是用于指定可接受的内容编码，这个编码与字符编码不是一个该概念，（我们经常会用到压缩文件，将正常文件进行压缩就是一种利用文件的底层编码进行的再编码）
    服务器在发个客户端数据的时候会将数据先根据请求数据中的Accept-Charset进行编码，然后对数据进行压缩，也就是说通过Accept-Encoding中可以接受的压缩算法进行压缩，这会有效减小网络压力，同时也减小了对客户端的延时，因为段数据在服务器进行压缩所用的时间与在网络上传输的时间相比还是比较理想的
    如果请求消息中没有设置这个域，服务器假定客户端对各种内容编码都可接受
  • Accept-Language："en, fr"，类似于Accept，但是它是用于指定一种自然语言。如果请求消息中没有设置这个域，服务器假定客户端对各种语言都可接受。
  • Authorization : [credentials]，授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中
  • Expect : "100-continue"，发送一个请求, 包含一个Expect:100-continue, 询问Server是否愿意接受数据，接收到Server返回的100-continue应答以后, 才把数据POST给Server
  • Host：主要用于指定被请求资源的Internet主机和端口号，它通常是从HTTP URL中提取出来的
  • From : "xxx@xxxxcom"
  • User-Agent："Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"，允许客户端将它的操作系统浏览器和其他属性告诉服务器。
  • Connnection：标明客户是否能够处理持续性HTTP连接。持续性连接允许客户或者浏览器在单个socket中读取多个文件，从而节省协商几个独立连接所需的开销。
  • Content-Encoding : "gzip"，来标识服务端压缩时所用的压缩方式，Accept-Encoding用来标识客户端能够理解的内容编码方式。 Content-Encoding用来标识主体进行了何种方式的内容编码转换
  • Cookie：向服务器返回cookie，这些cookie是之前由服务器发送给浏览器的：request.getCookies()

3.3.3 响应结构

HTTP响应由三个部分组成：

  • 状态码(Status Code)：描述了响应的状态。可以用来检查是否成功的完成了请求。请求失败的情况下，状态码可用来找出失败的原因。如果Servlet没有返回状态码，默认会返回成功的状态码HttpServletResponse.SC_OK
  • HTTP头部(HTTP Header)：它们包含了更多关于响应的信息。比如：头部可以指定认为响应过期的过期日期，或者是指定用来给用户安全的传输实体内容的编码格式。如何在Serlet中检索HTTP的头部看这里
  • 主体(Body)：它包含了响应的内容。它可以包含HTML代码，图片，等等。主体是由传输在HTTP消息中紧跟在头部后面的数据字节组成的

响应头结构示例：

  • Range : bytes=206-5513，指定一种度量单位和一个部分被请求资源的偏移范围。
  • Refener : www.myweb.com/news/search.html，一种请求头标域，标明产生请求的初始资源。对于HTML表单，它包含此表单的Web页面的地址
  • Accept-Ranges : "none"，一个响应头标，它允许服务器指明：将在给定的偏移和长度处，为资源组成部分的接受请求。该头标的值被理解为请求范围的度量单位
  • Age : "2147483648(2^31)"，允许服务器规定自服务器生成该响应以来所经过的时间长度，以秒为单位。该头标主要用于缓存响应
  • ETag : "b38b9-17dd-367c5dcd"，一种实体头标，它向被发送的资源分派一个唯一的标识符。对于可以使用多种URL请求的资源，ETag可以用于确定实际被发送的资源是否为同一资源
  • Last-Modified : "Tue, 11 Jul 2000 18:23:51 GMT"，指定被请求资源上次被修改的日期和时间
  • Location : "http://localhost/redirecttarget.asp"，对于一个已经移动的资源，用于重定向请求者至另一个位置。与状态编码302(暂时移动)或者301(永久性移动)配合使用
  • Proxy-Authenticate [challenge]，类似于WWW-Authenticate，便是有意请求只来自请求链(代理)的下一个服务器的认证
  • Retry-After : "Tue, 11 Jul 2000 18:23:51 GMT" or "60"，一种响应头标域，由服务器与状态编码503(无法提供服务)配合发送，以标明再次请求之前应该等待多长时间，此时间即可以是一种日期，也可以是一种秒单位
  • Server : "Microsoft-IIS/5.0"，一种标明Web服务器软件及其版本号的头标
  • Vary : "Date"，一个响应头标，用于表示使用服务器驱动的协商从可用的响应表示中选择响应实体。例如：Vary: *

3.3.4 HTTP响应码

HTTP响应码：

  • 1xx：临时，请求收到，继续处理
  • 2xx：成功，行为被成功地接受、理解和采纳
  • 3xx：重定向，为了完成请求，必须进一步执行的动作
  • 4xx：客户端错误，请求包含语法错误或者请求无法实现
  • 5xx: 服务器端错误，服务器不能实现一种明显无效的请求
响应码 响应信息
100 继续，请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分
101 分组交换协议，请求者已要求服务器切换协议，服务器已确认并准备切换
200 OK， 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201 已创建，请求成功并且服务器创建了新的资源
202 已接受，服务器已接受请求，但尚未处理
203 非授权信息，服务器已成功处理了请求，但返回的信息可能来自另一来源
204 无内容，请求收到，但返回信息为空
205 重置内容，服务器完成了请求，用户代理必须复位当前已经浏览过的文件
206 部分内容，服务器已经完成了部分用户的GET请求
300 多种选择，请求的资源可在多处得到
301 永久重定向，浏览器会记住，比如说从123.cn——>456.cn，浏览器不会请求123.cn，直接请求456.cn了
302 临时重定向，浏览器不会记住，比如说从123.cn——>456.cn，浏览器每次都会先请求123.cn，然后再请求456.cn
303 查看其他位置，请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码，建议客户访问其他URL或访问方式
304 未修改，自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容
305 使用代理，请求者只能使用代理访问请求的网页。请求的资源必须从服务器指定的地址得到
306 前一版本HTTP中使用的代码，现行版本中不再使用
307 暂时重定向，服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
400 错误请求，如语法错误
401 未授权，请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应
402 保留有效ChargeTo头响应，要求付费
403 禁止访问 HTTP
404 未找到，没有发现文件、查询或URl
405 方法禁用，用户在Request-Line字段定义的方法不允许
406 不接受，无法使用请求的内容特性响应请求的网页
407 需要代理授权，类似401，用户必须首先在代理服务器上得到授权
408 请求超时，客户端没有在用户指定的时间内完成请求
409 冲突，服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息
410 已删除，如果请求的资源已永久删除，服务器就会返回此响应
411 需要有效长度， 服务器不接受不含有效内容长度标头字段的请求，服务器拒绝用户定义的Content-Length属性请求
412 未满足前提条件，服务器未满足请求者在请求中设置的其中一个前提条件
413 请求实体太大，请求的资源大于服务器允许的大小
414 请求URI太大，请求的资源URL长于服务器允许的长度
415 不支持的媒体类型，请求资源不支持请求项目格式
416 请求范围不符合要求，如果页面无法提供请求的范围，则服务器会返回此状态代码
417 未满足期望值，服务器不满足请求Expect头字段指定的期望值，如果是代理服务器，可能是下一级服务器不能满足请求长，失败的预期
500 内部服务器错误
501 尚未实施，服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码
502 网关错误， 服务器作为网关或代理，从上游服务器收到无效响应
503 不可用的服务，服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态
504 网关超时，服务器作为网关或代理，但是没有及时从上游服务器收到请求
505 HTTP版本未被支持，服务器不支持请求中所用的 HTTP 协议版本

4 HTTP1.1协议八种方法

4.1 定义

http协议请求由三部分组成，分别是：请求行、消息报头、请求正文
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：　

Method Request-URI HTTP-Version CRLF

HTTP/1.1协议中共定义了八种方法（有时也叫动作）来表明Request-URI指定的资源的不同操作方式：

  1. OPTIONS
    返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送*的请求来测试服务器的功能性
  2. HEAD
    向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
  3. GET
    向特定的资源发出请求。注意：GET方法不应当被用于产生副作用的操作中
  4. POST
    向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改
  5. PUT
    向指定资源位置上传其最新内容。
  6. DELETE
    请求服务器删除Request-URI所标识的资源。
  7. TRACE
    回显服务器收到的请求，主要用于测试或诊断。
  8. CONNECT
    HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

4.2 get和post提交区别

简单来说，本质上区别：

  • GET产生 一个 TCP数据包
  • POST产生 两个 TCP数据包

也就是说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）

详细区别：

  • 数据携带上:
    GET方式：在URL地址后附带的参数是有限制的，其数据容量通常不能超过1K。
    POST方式：可以在请求的实体内容中向服务器发送数据，传送的数据量无限制。

  • 请求参数的位置上:
    GET方式：请求参数放在URL地址后面，以 ? 的方式来进行拼接
    POST方式:请求参数放在HTTP请求包中

  • 用途上:
    GET方式一般用来获取数据
    POST方式一般用来提交数据
    首先是因为GET方式携带的数据量比较小，无法带过去很大的数量
    POST方式提交的参数后台更加容易解析(使用POST方式提交的中文数据，后台也更加容易解决)
    GET方式比POST方式要快

  • GET方式比POST方式要快
    post请求包含更多的请求头
    因为post需要在请求的body部分包含数据，所以会多了几个数据描述部分的首部字段（如content-type），这其实是微乎其微的。
    post在真正接受数据之前会先将请求头发送给服务器进行确认，然后才真正发送数据

  • post请求的过程：
    [1] 浏览器请求tcp连接（第一次握手）
    [2] 服务器答应进行tcp连接（第二次握手）
    [3] 浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
    ​[4] 服务器返回100 continue响应
    [5] 浏览器开始发送数据
    [6] 服务器返回200 ok响应

  • get请求的过程：
    [1] 浏览器请求tcp连接（第一次握手）
    [2] 服务器答应进行tcp连接（第二次握手）
    [3] 浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
    [4] 服务器返回200 ok响应
    也就是说，目测get的总耗是post的2/3左右
    get会将数据缓存起来，而post不会
    post不能进行管道化传输

在FORM提交的时候，如果不指定Method，则默认为get请求，Form中提交的数据将会附加在url之后，以?分开与url分开。字母数字字符原样发送，但空格转换为+号，其它符号转换为%XX, 其中XX为该符号以16进制表示的ASCII（或ISOLatin-1）值。get请求请提交的数据放置在HTTP请求协议头中，而post提交的数据则 放在实体数据中；
get方式提交的数据最多只能有1024字节，而post则没有此限制
在表单里使用post和get有什么区别
在Form里面，可以使用post也可以使用get。它们都是method的合法取值。但是，post和get方法在使用上至少有两点不同：

  1. get方法通过URL请求来传递用户的输入。post方法通过另外的形式。
  2. get方式的提交需要用Request.QueryString来取得变量的值，而post方式提交时，必须通过Request.Form来访问提交的内容。
posted @ 2022-04-14 15:54  上善若泪  阅读(304)  评论(0)  编辑  收藏  举报