一、了解Web及网络基础

1、网络基础TCP/IP

TCP/IP协议族按层次分别为一下4层：应用层、传输层、网络层和数据链路层

应用层：HTTP

传输层：TCP、UDP

网络层：IP

数据链路层：网络

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

IP地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址可以和MAC地址进行配对。IP地址可变换，但MAC地址基本上不会改变。

当不在同一局域网时，在进行中转时会利用下一站中转设备的MAC地址来搜索下一中转目标，会采用ARP协议

ARP：是一种用以解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

用TCP协议把数据包送出去后，TCP不会对传达后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了TCP的标志——SYN和ACK。

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

3、负责域名解析的DNS服务

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

用户通常使用主机名和域名来访问对方的计算机，而不是直接通过IP地址来访问。DNS协议提供通过域名查找IP地址，或逆向从IP地址反查域名的服务。

4、各种协议与HTTP的关系

image-20241027154037526

二、简单的HTTP协议

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

img

响应报文基本上是由协议版本、状态码、用以解释状态码的原因短语、可选的响应式头部字段以及实体主体构成

img

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

HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。

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

2、请求URI定位资源

HTTP协议使用URI定位互联网上的资源。，在互联网上的任意位置的资源都能访问到。

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

  • URI为完整的请求URI

    GET http://hackr.jp/index.html HTTP/1.1

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

    GET index.html HTTP/1.1

    Host:hackr.jp

除此之外，如果不是访问特定资源而是对服务器本身发起请求，可以用*来代替URI。

OPTIONS * HTTP/1.1

3、告知服务器意图的HTTP方法

GET：获取资源

请求 GET /index.html HTTP/1/1
Host:www.hackr.jp
响应 返回index.html的页面资源
请求 GET /index.html HTTP/1/1
Host:www.hackr.jp
if-Modified-Since:Thu, 12 Jul 2012 07:30:00 GMT
响应 仅返回2012年7月12日7点30分以后更新过的index.html页面资源。
如果未有页面更新，则以状态码304 Not Modified作为响应返回。

POST：传输实体的主体

虽然GET方法也可以传输实体的主体，但一般不用GET方法进行传输，而是用POST方法。虽说POST功能与GET很相似，但POST的主要目的并不是获取响应的主体内容。

请求 POST /submit.cgi HTTP/1/1
Host:www.hackr.jp
Content-Length: 1560（1560字节的数据）
响应 返回submit,cgi接收数据的处理结果

PUT：传输文件

PUT方法用来传输文件，就像FTP协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。

请求 PUT /example.html HTTP/1.1
Host:www.hackr.jp
Content-Type:text/html
Content-Length:1560
响应 响应返回状态码204 No Content（该html已存在于服务器上）

HEAD：获得报文首部

HEAD方法和GET方法一样，只是不反悔报文主体部分。用于确认URI的有效性及资源更新的日期时间等。

请求 HEAD /index.html HTTP/1.1
Host:www.hackr.jp
响应 返回index.html有关的响应首部

DELETE：删除文件

DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按请求URI删除指定的资源。

请求 DELETE /example.html HTTP/1.1
Host:www.hackr.jp
响应 响应返回状态码204 No Content

OPTIONS：询问支持的方法

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

请求 OPTION * HTTP/1.1
Host:www.hackr.jp
响应 HTTP/1.1 200 OK
Allow:GET、POST、HEAD、OPTIONS

TRACE：追踪路径

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

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

请求 TRACE / HTTP/1.1
Host:hackr.jp
Max-Forwards:2
响应 HTTP/1.1 200 OK
Content-Type:message/http
Content-Length:1024
TRACE / HTTP/1.1
Host:hackr.jp
Max-Forwards:2

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

CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要使用SSL和TLS协议把通信内容加密后经网络隧道传输。

请求 CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host:proxy.hackr.jp
响应 HTTP/1.1 200 OK
方法 说明 支持的HTTP协议版本
GET 获取资源 1.0、1.1
POST 传输实体主体 1.0、1.1
PUT 传输文件 1.0、1.1
HEAD 获得报文首部 1.0、1.1
DELETE 删除文件 1.0、1.1
OPTIONS 询问支持的方法 1.1
TRACE 追踪路径 1.1
CONNECT 要求用隧道协议连接代理 1.1
LINK 建立和资源之间的联系 1.0
UNLINK 断开连接关系 1.0

4、持久连接节省通信

HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接。

以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着HTTP的普及，文档中包含大量图片的情况多了起来。

比如，使用浏览器浏览一个包含多张图片的HTML页面时，在发送请求访问HTML页面资源的同时，也会请求该HTML页面包含的其他资源。因此，每次的请求都会造成无谓的TCP连接建立和断开，增加通信量的开销。

4.1 持久连接

为解决上述TCP连接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。

持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面地显示速度也就相应提高了。

在HTTP/1.1中，所有的连接默认都是持久连接，但在HTTP/1.0内并未标准化。虽然有一部分服务器通过非标准化的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需要支持持久连接。

4.2 管线化

持久连接使得多数请求以管线化方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。

比如，当请求一个包含10张图片的HTML Web页面，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术则比持久连接还要快。请求数越多，时间差就越明显。

使用Cookie的状态管理

HTTP是无状态协议，它不对之前发生过的请求和响应的状态进行管理。也就是说，无法根据之前的状态进行本次的请求处理。

假设要求登录认证的Web页面本身无法进行状态的管理，那么每次跳转新页面就要再次登录，或者要在每次请求报文中附加参数来管理登录状态。

保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了Cookie技术，Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

Cookie会根据从服务端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。

服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

  • 没有Cookie信息状态下的请求

    1. 发出请求
    2. 在响应中添加Cookie后返回

  • 第2次以后（存有Cookie信息状态）的请求

    1. 请求中添加Cookie后发送

    2. 检查Cookie

三、HTTP报文内的HTTP信息

1、HTTP报文

用于HTTP协议交互的信息被称为HTTP报文。请求端的HTTP报文叫做请求报文，响应端的叫做响应报文。HTTP报文本身是由多行（用CR+LF作换行符）数据构成的字符串文本。

HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。

2、请求报文及响应报文的结构

  • 请求报文

    • 请求行

      GET/ HTTP/1.1

    • 各首部字段

      Host:hackr.jp
      User-Agent:Mozilla/5.0 (window NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
      Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
      Accept-Language:ja,en-us;q=0.7,en;q=0.3
      Accept-Encoding:gzip,deflate
      DNT:1
      Connection:keep-alive
      Pragma:no-cache
      Cache-Control:no-cache
      空行(CR+LF)

  • 响应报文

    • 状态行

      HTTP/1.1 200 OK

    • 各种首部字段

      Date:fri, 27 Oct 2024 13:14:00 GMT
      Server:Apache
      Last-Modified:Fri, 31 Aug 2007 02:02:20 GMT
      ETag:"45beal-16a-46d776ac"
      Accept-Ranges:bytes
      Content-Length:362
      Connection:close
      Content-Type:text/html
      空行(CR+LF)

    • 报文主体

      <html xmlns="http://www.w3.org/1999/xhtml">
      <head>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <title>hackr.jp</title>
      </head>
      <body>
      <img src="hackr.gif" alt="hackr.jp" width="240" height="84" />
      </body>
      </html>

    1. 请求行

      包含用于请求的方法，请求URI和HTTP版本

    2. 状态行

      包含表明响应结果的状态码，原因短语和HTTP版本

    3. 首部字段

      包含表示请求和响应的各种各样条件和属性的各类首部

      一般有4种首部，分别是：通用首部，请求首部，响应首部和实体首部

3、编码提升传输速率

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

  • 报文

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

  • 实体

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

HTTP报文的主体用于传输请求或响应的实体主体。

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

3.2 压缩传输的内容编码

向待发送邮件内增加附件时，为了使邮件容量变小，我们会先用ZIP压缩文件之后再添加附件发送。HTTP协议中有一种被称为内容编码的功能也能进行类似的操作。

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

常用的内容编码有以下几种。

  • gzip（GNU zip）
  • compress（UNIX系统的标准压缩）
  • deflate（zlib）
  • identity（不进行编码）

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

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

3.4 发送多种数据的多部分对象集合

发送邮件时，我们可以在邮件里写入文字并添加多份附件。因为采用了MIME机制，允许邮件处理文本、图片、视频等多个不同类型的数据。而在MIME扩展中会使用一种称为多部分对象集合的方法，来容纳多份不同类型的数据。

相应的，HTTP协议中页采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。

多部分对象集合包含的对象如下：

  • multipart/form-data

    在Web表单文件上传时使用

  • mulitipart/byteranges

    状态码206响应报文包含了多个范围的内容时使用

在HTTP报文中使用多部分对象集合时，需要在首部字段里加上Content-type。

使用boundary字符串来划分多部分对象集合指明的各类实体。

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

以前用户不能使用现在这种高速的宽带访问互联网，当时，下载一个尺寸稍大的图片或文件就已经很吃力了。如果下载过程中遇到网络中断的情况，那就必须重头开始。为了解决上述问题，需要一种可恢复的机制。所谓恢复是指能从之前下载中断处恢复下载。

要实现该功能需要指定下载的实体范围。指定范围发送的请求叫做范围请求。执行范围请求时，会用到首部字段Range来指定资源的byte范围。

3.6 内容协商返回最合适的内容

同一个Web网站有可能存在着多份相同内容的页面。比如英语版和中文版的Web页面，他们内容上虽然相同，但使用的语言却不同。

当浏览器的默认语言为英语或中文，访问相同URI的Web页面时，则会显示对应的英语版或中文版的Web页面。这样的机制称为内容协商。

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

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

内容协商技术有以下3种类型。

服务器驱动协商

客户端驱动协商

透明协商：是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。

4、返回结果的HTTP状态码

4.1 状态码告知从服务器端返回的请求结果

类别 原因短语
1XX Informational（信息性状态码） 接受的请求正在处理
2XX Success（成功状态码） 请求正常处理完毕
3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
4XX Client Error（客户端错误状态码） 服务器无法处理请求
5XX Server Error（服务器错误状态码） 服务器处理请求出错

4.2 2XX 成功

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

4.2.1 200OK

表示从客户端发来的请求在服务器端被正常处理了。

4.2.2 204 No Content

该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。

4.2.3 206 Partial Content

该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

4.3 3XX 重定向

3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理

4.3.1 301 Moved Parmanently

永久性重定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。也就是说，如果已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI重新保存。

4.3.2 302 Found

临时重定向。该状态码表示请求的资源已被分配了新的URI，希望用户能使用新的URI访问。

4.3.3 303 See Other

该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。

4.3.4 304 Not Modified

该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发送请求未满足条件的情况后，直接返回304，返回时，不包含任何响应的主体部分。304虽然被划分在3XX类别中，但是和重定向没有关系。

4.3.5 307 Temporary Redirect

临时重定向。该状态码与302有着相同的含义，尽管302标准禁止POST变换成GET，但实际使用时大家并不遵守。

4.4 4XX 客户端错误

4XX的响应结果表明客户端是发生错误的原因所在

4.4.1 400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像200OK一样对待该状态码。

4.4.2 401 Unauthorized

该状态码表示发送的请求需要通过HTTP认证的认证信息。另外若之前已进行过1次请求，则表示用户认证失败。

返回含有401的响应必须包含一个适用于被请求资源的www-authenticate首部用以质询用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。

4.4.3 403 Forbidden

该状态码表明对请求的访问被服务器拒绝。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。

4.4.4 404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

4.5 5XX 服务器错误

4.5.1 500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时故障

4.5.2 503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。