专栏首页小康的自留地图解HTTP读书笔记

图解HTTP读书笔记

第一章 了解Web及网络基础

Web使用一种名为HTTP(HyperText Transfer Protocol,超文本传输协议)的协议作为规范,完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说,Web是建立在HTTP协议上通信的。

TCP/IP的分层管理

分层的好处:如果互联网只由一个协议统筹,某个地方需要改变设计时,就必须把所有部分整体替换掉。而分层之后只需把变动的层替换掉即可。把各层之间的接口部分规划好之后,每个层次内部的设计就能够自由改动了。层次化之后,设计也变得相对简单了。处于应用层上的应用可以只考虑分派给自己的任务,而不需要弄清对方在地球上哪个地方、对方的传输路线是怎样的、是否能确保传输送达等问题。

  1. 应用层 决定了向用户提供应用服务时通信的活动。 TCP/IP 协议族内预存了各类通用的应用服务。比如,FTP(File Transfer Protocol,文件传输协议)和 DNS(Domain Name System,域名系统)服务就是其中两类。HTTP 协议也处于该层。
  2. 传输层 传输层对上层应用层,提供处于网络连接中的两台计算机之间的数据传输。 在传输层有两个性质不同的协议:TCP(Transmission Control Protocol,传输控制协议)和 UDP(User Data Protocol,用户数据报协议)。
  3. 网络层(网络互连层) 网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径(所谓的传输路线)到达对方计算机,并把数据包传送给对方。 与对方计算机之间通过多台计算机或网络设备进行传输时,网络层所起的作用就是在众多的选项内选择一条传输路线。
  4. 链路层(数据链路层,网络接口层) 用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC(Network Interface Card,网络适配器,即网卡),及光纤等物理可见部分(还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内。

TCP/IP通信传输流

发送端在层与层之间传输数据时,每经过一层时必定会被打上一个该层所属的首部信息。反之,接收端在层与层传输数据时,每经过一层时会把对应的首部消去。

这种把数据信息包装起来的做法称为封装(encapsulate)。

负责传输的IP协议

IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里,则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC 地址(Media Access Control Address)。

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

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

无论哪台计算机、哪台网络设备,它们都无法全面掌握互联网中的细节。

确保可靠性的TCP协议

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

TCP 协议为了更容易传送大数据才把数据分割,而且 TCP 协议能够确认数据最终是否送达到对方。

为了准确无误地将数据送达目标处,TCP 协议采用了三次握手(three-way handshaking)策略。用 TCP 协议把数据包送出去后,TCP 不会对传送后的情况置之不理,它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志(flag) —— SYN(synchronize) 和 ACK(acknowledgement)。

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

负责域名解析的DNS服务

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

各种协议与HTTP协议的关系

统一资源标识符

URI 用字符串标识某一互联网资源,而 URL 表示资源的地点(互联网上所处的位置)。可见 URL 是 URI 的子集。

第二章 简单的HTTP协议

HTTP协议用于客户端和服务器端之间的通信

请求访问文本或图像等资源的一端称为客户端,而提供资源响应的一端称为服务器端。

在两台计算机之间使用 HTTP 协议通信时,在一条通信线路上必定有一端是客户端,另一端则是服务器端。

按实际情况,两台计算机作为客户端和服务器端的角色有可能会互换。但就仅从一条通信路线来说,服务器端和客户端的角色是确定的,而用 HTTP 协议能够明确区分哪端是客户端,哪端是服务器端。

通过请求和响应的交换达成通信

HTTP 协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应。

请求报文的构成:

响应报文的构成:

HTTP是不保存状态的协议

使用 HTTP 协议,每当有新的请求发送时,就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把 HTTP 协议设计成如此简单的。

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

请求 URI 定位资源

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

OPTIONS * HTTP/1.1 

告知服务器意图的HTTP方法

  1. GET:获取资源 GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。
  2. POST:传输实体主体 虽然用 GET 方法也可以传输实体的主体,但一般不用 GET 方法进行传输,而是用 POST 方法。虽说 POST 的功能与 GET 很相似,但 POST 的主要目的并不是获取响应的主体内容。
  3. PUT:传输文件 PUT 方法用来传输文件。就像 FTP 协议的文件上传一样,要求在请求报文的主体中包含文件内容,然后保存到请求 URI 指定的位置。 但是,鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制,任何人都可以上传文件 , 存在安全性问题,因此一般的 Web 网站不使用该方法。
  4. HEAD:获取报文首部 HEAD 方法和 GET 方法一样,只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
  5. DELETE:删除文件 DELETE 方法用来删除文件,是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。 但是,HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制,所以一般的 Web 网站也不使用 DELETE 方法。
  6. OPTIONS:询问支持的方法 OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
  7. TRACE:追踪路径 TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。 发送请求时,在 Max-Forwards 首部字段中填入数值,每经过一个服务器端就将该数字减 1,当数值刚好减到 0 时,就停止继续传输,最后接收到请求的服务器端则返回状态码 200 OK 的响应。 但是,TRACE 方法本来就不怎么常用,再加上它容易引发 XST(Cross-Site Tracing,跨站追踪)攻击,通常就更不会用到了。
  8. CONNECT:要求用隧道协议连接代理 CONNECT 方法要求在与代理服务器通信时建立隧道,实现用隧道协议进行 TCP 通信。主要使用 SSL(Secure Sockets Layer,安全套接层)和 TLS(Transport Layer Security,传输层安全)协议把通信内容加 密后经网络隧道传输。

持久连接

持久连接旨在建立 1 次 TCP 连接后进行多次请求和响应的交互

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

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

这样就能够做到同时并行发送多个请求,而不需要一个接一个地等待响应了。

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

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

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

  1. 第一次请求没有Cookie时
  • 请求报文 GET /reader/ HTTP/1.1 Host: hackr.jp*首部字段内没有Cookie的相关信息
  • 响应报文 HTTP/1.1 200 OK Date: Thu, 12 Jul 2012 07:12:20 GMT Server: Apache <Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT> Content-Type: text/plain; charset=UTF-8服务端生成了Cookie并且返回了
  1. 第二次带有Cookie时请求

请求报文 GET /image/ HTTP/1.1 Host: hackr.jp Cookie: sid=1342077140226724

第三章 HTTP报文内的HTTP信息

HTTP报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。HTTP 报文大致可分为报文首部和报文主体两块。两者由最初出现的空行(CR+LF)来划分。通常,并不一定要有报文主体。

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

编码提升传输速率

报文是 HTTP 通信中的基本单位,由 8 位组字节流(octet sequence,其中 octet 为 8 个比特)组成,通过 HTTP 通信传输。而实体是作为请求或响应的有效载荷数据(补充项)被传输,其内容由实体首部和实体主体组成。

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

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

常用的内容编码有gzip(GNU zip)compress(UNIX 系统的标准压缩)deflate(zlib)identity(不进行编码)

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

分块传输编码会将实体主体分成多个部分(块)。每一块都会用十六进制来标记块的大小,而实体主体的最后一块会使用“0(CR+LF)”来标记。

使用分块传输编码的实体主体会由接收的客户端负责解码,恢复到编码前的实体主体。

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

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

  1. multipart/form-data 在 Web 表单文件上传时使用。
  2. multipart/byteranges 状态码 206(Partial Content,部分内容)响应报文包含了多个范围的内容时使用。
  3. multipart/form-data
  4. multipart/byteranges

使用 boundary 字符串来划分多部分对象集合指明的各类实体。在 boundary 字符串指定的各个实体的起始行之前插入“–”标记(例如:–AaB03x、–THIS_STRING_SEPARATES),而在多部分对象集合对应的字符串的最后插入“–”标记(例如:–AaB03x–、--THIS_STRING_SEPARATES–)作为结束。

多部分对象集合的每个部分类型中,都可以含有首部字段。另外,可以在某个部分中嵌套使用多部分对象集合。

获取部分内容的范围请求

对一份 10 000 字节大小的资源,如果使用范围请求,可以只请求 5001~10 000 字节内的资源。

执行范围请求时,会用到首部字段 Range 来指定资源的 byte 范围。

  • 5001~10 000 字节 Range: bytes=5001-10000
  • 从 5001 字节之后全部的 Range: bytes=5001-
  • 从一开始到 3000 字节和 5000~7000 字节的多重范围 Range: bytes=-3000, 5000-7000

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

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

内容协商返回最合适内容

服务器驱动协商(Server-driven Negotiation)

由服务器端进行内容协商。以请求的首部字段为参考,在服务器端自动处理。但对用户来说,以浏览器发送的信息作为判定的依据,并不一定能筛选出最优内容。

客户端驱动协商(Agent-driven Negotiation)

由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用 JavaScript 脚本在 Web 页面上自动进行上述选择。比如按 OS 的类型或浏览器类型,自行切换成 PC 版页面或手机版页面。

透明协商(Transparent Negotiation)

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

返回结果的HTTP状态码

信息响应

状态码

描述

100 Continue

这个临时响应表明,迄今为止的所有内容都是可行的,客户端应该继续请求,如果已经完成,则忽略它

101 Switching Protocol

该代码是响应客户端的 Upgrade 标头发送的,井且指示服务器也正在切换的协议

102 Processing

此代码表示服务器已到井正在处理该请求,但没有响应可用

成功响应

状态码

描述

200 OK

请求成功

201 Created

该请求已成功,并因此创建了一个新的资源。这通常是在 PUT 请求之后发送的响应

202 Accepted

请求已经接收到,但还未响应,没有结果

203 Non-authoritative Information

服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合,而是来自本地或者第三方的拷贝

204 No Content

服务器成功处理了请求,但不需要返回任何实体内容,井且希望返回更新了的元信息

205 Reset Content

服务器成功处理了请求,且没有返回任何内容。该响应主要是被用于接受用户输入后,立即重置表单

206 Partial Content

服务器已经成功处理了部分 GET 请求

重定向

状态码

描述

300 Multiple Choice

被请求的资源有一系列可供选择的回馈信息

301 Moved Permanently

被请求的资源已永久移动到新位置

302 Found

请求的资源现在临时从不同的 URI 响应请求

303 See Other

对应当前请求的响应可以在另一个 UN 上被找到,而且客户端应当采用 GET 的方式访问那个资源

304 Not Modified

如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容自上次访问以来或者根据请求的条件)并没有改变

客户端响应

状态码

描述

400 Bad Request

语义有误,当前请求无法被服务器理解

401 Unauthorized

当前请求需要用户验证

403 Forbidden

服务器已经理解请求,但是拒绝执行它

404 Not Found

请求失败,请求所希望得到的资源未被在服务器上发现

405 Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源

服务端响应

状态码

描述

500 Internal Server Error

服务器遇到了不知道如何处理的情况

501 Not Implemented

此请求方法不被服务器支持且无法被处理

502 Bad Gateway

此错响应表明服务器作为网关需要得到一个处理这个请求的响应

503 Service Unavailable

服务器没有备好处理请求

504 Gateway Timeout

当服务器作为网关,不能及时得到响应时返回此错误代码

505 HTTP Version Not Supported

服务器不支持请求中所使用的 HTTP 协议版本

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 跨域资源共享

    CORS全称为Cross-Origin Resource Sharing,被译为跨域资源共享,新増了一组HTTP首部字段,允许服务器声明哪些源站有权限访问哪些资...

    Dreamy.TZK
  • HTTP消息

    HTTP报文,又称HTTP消息,是服务器和客户端之间交换数据的方式。有两种类型的消息:请求,由客户端发送用来触妓一个服务器上的动作;响应,来自服务器的应答。

    Dreamy.TZK
  • 拖动图片改变位置

    在线展示:https://gethtml.cn/project/2020/04/14/index.html

    Dreamy.TZK
  • HTTP基础知识

    HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。

    mcxfate
  • HTTP协议理解

    HTTP(Hyper Text Transfer Protocol)超文本传输协议,是一种请求响应式协议,类似两国会晤中需要遵守的规则。那么,其中有什么内容特点...

    用户1148399
  • JavaEE基础(03):Http请求详解,握手挥手流程简介

    地址:http://localhost:6003/servletOneImpl?userName=cicada

    知了一笑
  • HTTP 请求全解

    HTTP(Hyper Text Transfer Protocol)是一套计算机通过网络进行通信的规则。计算机专家设计出HTTP,使HTTP客户(如Web浏览器...

    码脑
  • 代码编辑器Sublime Text 3 免费使用方法与简体中文汉化包下载

    Sublime Text这款代码编辑器是Jeff 一直都在使用的,前段时间转用到版本3,因为感觉Sublime Text 3 启动速度更加快,运行更加流畅——虽...

    Jeff
  • 锦囊篇|一文遨游应用层

    从图中我们可以看到的例如HTTP、DNS、SMTP等一系列的协议都是在应用层这一层建立的。而这次我们主讲的就是面试中最常问到的HTTP和DNS了。

    ClericYi
  • HTTP你需要知道的

    HTTPS是在处于应用层的HTTP协议与处于传输层的TCP协议之间,增加了一层SSL。HTTPS对传输数据进行了加密,并且HTTPS需要CA机构wosign的颁...

    Oceanlong

扫码关注云+社区

领取腾讯云代金券