图解HTTP（一）

本系列是对于《图解HTTP》的知识点整理。

《图解HTTP》出版于2014年，此时的HTTP2协议还未修订完成，故全书只讲解HTTP1.0、HTTP1.1以及会涉及到一点HTTP2.0依赖的协议。

本文涉及第一章至第三章的内容。

 

一、网络基础

HTTP/1.0

  • RFC1945 -Hypertext Transfer Protocol -- HTTP/1.0

　　https://www.ietf.org/rfc/rfc1945.txt

HTTP/1.1

  • RFC2616-Hypertext Transfer Protocol -- HTTP/1.1

　　https://www.ietf.org/rfc/rfc2616.txt

1、网络基础TCP/IP

1.1 TCP/IP协议族

　　通常使用的网络是在TCP/IP协议族的基础上运作的。而HTTP属于它内部的一个子集。

　　TCP/IP协议族按四层划分可以划分为：应用层、传输层、网络层和数据链路层。各层的作用如下。

应用层

　　应用层决定了向用户提供应用服务时通信的活动。

　　TCP/IP协议族内预存的各类通用的应用服务，FTP（File Transfer Protocol，文本传输协议）和DNS（Domain Name System，域名系统）服务就是其中两类。

　　HTTP协议当然也处于该层。

传输层

　　传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。

　　在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP （User Data Protocol，用户数据报协议）。

网络层

　　网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。网络层的作用就是在众多传输线路中选择一条传输路线。

链路层

　　用来处理连接网络的硬件部分。

1.2 TCP/IP通信传输流

　　在数据传输过程中，发送端的每一层添加该层所属的首部信息，而接收端会把对应该层的首部消去。发送端这种把数据信息包装起来的做法叫做封装。

 

2、与HTTP关系密切的协议：IP、TCP和DNS

2.1 负责传输的IP协议 

 　　按层次划分，IP（Internet Protocol，网际协议）位于网络层。几乎所有使用网络的系统都会用到IP协议。可能有人会把“IP”和“IP地址”搞混，“IP”其实是一种协议的名称。

　　IP协议的作用是把各种数据包传送给对方。而要保证传输对象的准确性，这就需要IP地址和MAC地址（Media Access Control Address）。

　　IP地址指明了节点被分配到的网络地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行匹配。IP地址可变换，但MAC地址一般不会更改。

使用ARP协议凭借MAC地址进行通信

　　在网络上，通信双方都在同一局域网（LAN）的情况是比较少的，经常会需要经过堕胎计算机和网络设备中转才能连接到对方。而在中转时会利用到下一站中转设备的MAC来搜索到下一个中转目标。此时，就会采用ARP协议（Address Resolution Protocol）。ARP是一种用于解析地址的协议，可以根据通信方的IP地址就反查出对应MAC地址。

　　没有人能够全面掌握互联网中的传输情况。在到达通信目标前的中转过程中，计算机和路由器等网络设备只能获悉粗略的传输路线。这种机制称为路由选择（routing）。

 

 2.2 确保可靠的TCP协议

　　按层次分，TCP位于传输层，提供可靠的字节流服务。

　　所谓字节流是指，在传输过程中将大块数据分割成以报文段为单位的数据包进行管理。而可靠是指正把数据准确可靠地传给对方。

　　为了准确无误地将数据送达目标处，TCP协议采用了三次握手（three-way handshaking）策略。握手协议中使用了TCP的标志（flag）——SYN（synchronize）和ACK（acknowledgement）。

　　发送端首先发送一个带SYM标志的数据包给对方。接收端收到后，回传一个带有ACK/SYN标志的数据包以示传达确认信息。最后，发送端再回传一个带有ACK标志的数据包，代表“握手”结束。

　　若在握手过程中某个阶段莫名中断，TCP协议会再次以相同顺序发送相同的数据包。

 

 　　除了上述的三次握手，TCP协议还有其他各种手段来保证通信的可靠性。

2.3 负责域名解析的DNS服务

　　DNS服务是和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务。

　　计算机可以被赋予IP地址，也可以被赋予主机名和域名。相比一组纯数字的IP地址，主机名和域名明显更任意记忆。

　　DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。

 

 2.4 各种协议与HTTP协议的关系

 

 3、URI和URL

　　与URI（统一资源标识符）相比，我们更熟悉URL（Uniform Resource Locator，统一资源定位符）。URL正是使用Web浏览器访问Web网页时需要输入的网络地址。比如，https://www.baidu.com/就是URL。

　　URI（Uniform Resource Identifier）是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型的名称。

　　采用HTTP协议时，协议方案就是http。除此之外还有ftp、mailto等。标准的URI方案有30中左右。

  • IANA - Uniform Resource Identifier(URL) SCHEMES（统一资源标识符方案）

　　https://www/iana.org/assignments/uri-schemes

　　URI用字符串标识某一网络资源，而URL表示资源的地址。可见URI是URL的子集。

3.1 URI格式

　　表示指定的URI，要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。相对URL是指从浏览器中基本URI处指定的URL，形如/image/logi.gif。

　　下面是绝对URI的格式。

　　服务器地址可以是域名，也可以是192.168.1.1这类IPv4地址，也可以是[0:0:0:0:0:0:0:1]这类IPv6地址。

【拓】RFC是征求修正意见书，但不是所有应用程序都符合RFC

二、简单的HTTP协议

1、HTTP协议是用于客户端和服务端之间的通信。

　　也就是一条通信线路上必定有一段是客户端，另一端是服务器端。

2、HTTP协议规定，请求必须从客户端发出，最后由服务端响应该请求并返回。

 

 　　下面是从客户端发送某个HTTP服务器端的请求报文中的内容。

GET /index.htm HTTP/1.1
Host: hackr.jp

　　起始行开头的GET表示请求服务器的类型，称为方法。随后的字符串/index.htm指明了请求访问的资源对象，叫做请求URI（request-URI）。最后的HTTP/1.1，即HTTP的版本号，用来提示客户端使用的HTTP协议功能。

　　请求报文是由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

　　接受到请求的服务器，会将请求内容的处理结果以响应的形式返回。

HTTP/1.1 200 OK
Data: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html

<html>
...

　　在起始行开头的HTTP/1.1表示服务器对应的HTTP版本。

　　紧挨着的200 OK表示请求的处理结果的状态码（status code）和原因短语（reason-phrase）。下一行显示了创建响应的日期时间，是首部字段（header field）内的一个属性。

　　接着以一空行分隔，之后的内容称为资源实体的主体（entity body）。

　　响应报文基本上由协议版本、状态码（表示氢气球成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。

3、HTTP是不保存状态的协议

　　HTTP是无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存，不保留之前一切的请求或响应报文的信息。

　　HTTP/1.1虽然是无状态协议，但是为了实现期望的保持状态功能，于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。

3.1 请求URI定位资源

　　当客户请求访问资源而发送请求时，URI需要将作为请求报文中的请求URI包含再内。指定请求URI的方式由很多。

    • URI为完整的请求URI

 

 

    • 在首部字段Host中写明网络域名或IP地址

 

 　　除此之外，如果不是访问特定资源而是对服务器本身发起请求，可以用一个*来代替请求URI。下面这个例子就是查询HTTP服务器端支持的HTTP方法种类。

3.2 HTTP的方法

　　下面将介绍HTTP/1.1中可使用的方法。

GET：获取资源

　　GET方法用来请求访问已被URI识别的资源。指定的资源经服务器解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果像CGI那样的程序，则返回经过执行后的输出结果。

POST：传输实体主体

　　POST方法用来传输实体的主体。

　　POST的主要目的并不是获取响应的主体内容，而是从客户端往服务器端传输实体主体。（GET也可以做到）

PUT：传输文件

　　PUT方法用来传输文件，就像FTP协议的文件上传一样，但是鉴于HTTP/1.1的PUT方法本身不带验证机制，因此一般web网站不使用该方法。

HEAD：获取报文首部

　　HEAD方法和GET方法一样，只是不返回报文主体部分，只需要响应报文的响应头和响应首部。用于确认URI的有效性及资源更新的日期时间等。

DELETE：删除文件

　　DELETE方法用来删除文件，是与PUT方法相反的方法。DELETE方法也是不带验证机制。

OPTIONS：询问支持的方法

　　OPTIONS方法用来查询针对请求URI指定的资源支持的方法。

 

 TRACE：追踪路径

　　TRACE方法是让Web服务器端将之前的请求通信返回给客户端的方法。

　　发送请求时，在Max-Forwards首部字段中填入数值，每经过一个服务器端就将该数字减1，但数字刚好减到0时，就停止继续传输，最后接收到请求的服务器端则返回状态码200 OK的响应。

　　客户端通过TRACE方法可以查询发送出去的请求是怎样被加工修改/篡改的。这是因为，请求想要连接的源目标服务器可能会通过代理中转。

　　但是，TRACE方法并不常用，且任意引发XST（Cross-Site Tracing，跨站追踪）攻击。

 

 CONNECT：要求用隧道协议连接代理

　　CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容经过网络隧道传输。

　　CONNECT方法的格式如下所示：

CONNECT 代理服务器名：端口名 HTTP版本号

 

 

　　下表列出了HTTP/1.0和HTTP/1.1支持的方法。另外，方法名区分大小写。

 

 3.3 持久连接

　　在HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。这在当年的小文本传输情况下来看是没有问题的。但是随着HTTP的普及，以及文档中包含大量图片的情况多了起来，这种行为会增加通信量的开销。

　　为了解决上述TCP连接的问题，HTTP/1.1和部分HTTP/1.0想出了持久连接（HTTP Presistent Connections，也成为HTTP keep-alive或HTTP connection reuse）的方法。

 

 　　持久连接使得多数请求以管线化方式发送成为可能。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样子就能够做到并行发送多个请求，而不需要一个接一个地等待响应了。

 

 3.4 使用Cookie的状态管理

　　HTTP引入了Cookie技术。Cookie技术通过在请求和响应报文中写入Cookir信息来控制客户端的状态。

　　Cookie会根据从服务器端发送的响应报文内的一个Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往服务器端发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后，会去找到对应客户端在服务器上的记录，就能得到之前的状态信息了。

 

 　　上图所显示的过程的报文如下。

 

三、HTTP报文中的HTTP信息 

　　HTTP报文分为请求报文和响应报文。HTTP报文本身是由多行（用CR+LF做换行符）数据构成的字符串文本。

　　HTTP报文大致可分为报文首部和报文主体两部分。

　　报文的首部内容由一下数据组成。

    • 请求行，包含用于请求的方法，请求URI和HTTP版本（请求报文）
    • 状态行，包含表明HTTP版本，响应结果的状态码和原因短语（响应报文）
    • 首部字段，包含表示请求和响应的各种条件和属性的各类首部。一般有4中首部，分别是：通用首部、请求首部、响应首部和实体首部。
    • 其他，可能包含HTTP的RFC中未定义的首部，如Cookie等

1、编码提升传输效率

　　通过在传输时编码，能有效地处理大量的访问请求，但是会消耗更多的CPU资源。

1.1 报文主体和实体主体的差异

　　报文是HTTP通信中的基本单位，由8位组字节流组成，通过HTTP通信传输。

　　实体是作为请求或响应的有效载荷数据（补充项）被传输的，其内容由实体首部和实体主体组成

　　通常报文主体等于实体主体，只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

1.2 压缩内容的内容编码

　　内容编码是指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。

 

 1.3 分割发送的分块传输编码

　　在HTTP通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。

　　这种把实体主体分块的功能成为分块传输编码（Chunked Transfer Coding）

 

 　　分块传输编码中，每一块都会用一个十六进制来标记块的大小，而实体主体最后一块会使用”0（CR+LF）“来标记

　　HTTP/1.1中存在一种称为传输编码的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。

1.4 发送多种数据的多部份对象集合

　　MIME技术允许邮件处理文本、图片、视频等多个不同类型的数据。MIME扩展中会使用一种称为多部份对象集合 （Multipart）的方法，来容纳多份不同类型的数据。

　　HTTP协议中也采纳了多部份对象集合，发送的一份报文主体内可包含多类型实体。

　　多部份对象集合包含的对象如下。

    • multipart/form-data ，在Web表单文件上传时使用

    • multipart/byteranges ，状态码206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。

 

 　　在使用多部份对象集合时，需要在首部字段里加上Content-type。

　　使用boundary字段划分多部份对象集合指明的各类实体。在boundary字符串指定的各个实体的起始行之前插入“--”标记，而在多部份对象集合对应的字符串的最后插入“--”标记“--”作为结束。

　　多部份对象集合的每个部分类型中，都可以含有首部字段。

1.5 获取部分内容的范围请求

　　使用首部字段Range来指定资源的byte范围。

 

 　　范围请求可以是一个范围，也可以是由逗号分割的多个范围。

 

 　　针对范围请求，响应会返回状态码为206 Partial Content的响应报文。对于多重范围请求，响应会在首部字段Content-Type标明multipart/byteranges后返回响应报文。

　　如果服务器无法响应范围请求，则会返回状态码200 OK和完整的实体内容。

1.6 内容协商

　　内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以语言、字符集、编码方式等为基准判断响应的资源。

　　包含在请求报文中的某些首部字段（如下）就是判断的基准。

    • Accept
    • Accept-Charset
    • Accept-Encoding
    • Accept-Language
    • Content-Language

　　内容协商技术由一下3中类型。

    • 服务器驱动协商，由服务器已请求的首部字段作为参考进行内容协商。
    • 客户端驱动协商，用户从浏览器显示的可选项列表中手动选择，还可以用JS脚本在Web页面上自动进行上述选择。
    • 透明协商，是上述两种类型的结合体，由服务器端和客户端各自进行内容协商的一种方法。
posted @ 2022-07-23 18:23  幻cat  阅读(141)  评论(0)  编辑  收藏  举报