《图解 HTTP》读书笔记(未完待续)

ARP 协议(Address Resolution Protocol)一种以解析地址的协议,根据通信双方的 IP 地址就可以查出对应的 MAC 地址。
MAC( Media Access Control Address)地址是指网卡所属的固定的地址
MIME,多部分对象集合(Multipurpose Internet Mail Extensions,多用途因特网邮件扩展),它是一种允许处理文本、图片、视频等多种不同类型的数据。

第一章:了解 Web 及网络基础

在浏览器地址栏输入 URL 时,可以看到 Web 页面。当然 Web 页面是不能凭空显示出来,它需要根据指定的 URL 到服务器获取文件资源,然后让浏览器显示 Web 页面。

Web 使用一种名为 HTTP 的协议作为规范。HTTP 全称 HyperText Transfer Protocol,超文本传输协议。

网络基础 TCP/IP

TCP/IP 协议族

什么是协议?
定义如何探测到通信目标,由哪一方发起通信,使用什么语言通信,怎样结束通信,不同的硬件、操作系统之间的通信的规则。

TCP/IP 是互联网相关的各类协议族的总称,包括各式内容,从电缆规格到 IP 地址的选定方法、寻找异地用户的方法、双方建立通信的顺序、以及 Web 页面显示需要处理的步骤等

TCP/IP 的分层管理

TCP/IP 协议族分为4层:应用层、传输层、网络层和数据链路层
作用:

  • 应用层:决定了向用户提供应用服务时通信的活动,HTTP 协议也处于该层
  • 传输层:对上层应用层,提供处于网络连接中的两台计算机之间的数据传输
  • 网络层:又名网络互联层,用来处理在网络上流动的数据包
  • 链路层:又名数据链路层、网络接口层,用来处理连接网络硬件部分(属于硬件范围)

TCP/IP 通信传输流

TCP/IP 通信传输流

利用 TCP/IP 协议族进行网络通信时,发送端(客户端)从应用层往下走,接收端(服务端)从链路层网上走

用 HTTP 举例:

  1. 应用层(发送端)发送 HTTP 请求
  2. 传输层(TCP协议)把从应用层接收到的数据(HTTP报文)进行分割,并在各个报文上打上标记序号及端口号后发给网络层
  3. 在网络层(IP协议)增加作为通信目的的 MAC 地址后转发给链路层(发往网络的通信请求就准备齐全了)
  4. 接收端在链路层接收到数据,按序网上层发送,达到应用层后,才能算真正接收到发送端发过来的请求


    image

    发送端在每层之间传输时,会打上该层所属的首部信息;接收端在曾与层之间传输时,每经过一层会删除对应的首部信息。
    这种把数据包转起来的做法叫做封装

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

负责传输的 IP 协议

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

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

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

IP 间的通信依赖 MAC 地址。在网络上,通常是经过多台计算机和网络设备中转才能连接到对方,在中转时,会利用下一站中转设备的 MAC 地址来搜索下一个中转目标,这是会采用 ARP 协议
(Address Resolution Protocol)。ARP 协议是一种以解析地址的协议,根据通信双方的 IP 地址就可以查出对应的 MAC 地址。


image

确保可靠的 TCP 协议

TCP 协议位于传输层,提供可靠的字节流服务,所谓字节流服务是将大块数据分割层以报文段为单位的数据包进行管理,方便传输。

为了确保准确无误的送达目的地,TCP 采用三次握手策略,数据发送出去之后,一定的会向对方确认是否成功送达。握手的过程中采用 TCP 的标志——SYN(synchronize)和 ACK(acknowledgement)。

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

如果某个阶段莫名结束,TCP 协议会再次以相同顺序发送相同的数据包。


image

负责域名解析的 DNS 服务

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

用户通常通过域名来访问网站,相比于 IP 地址,域名更符合人类的记忆习惯。DNS 服务便应运而生,逆向从 IP 地址反查域名服务。

各协议与 HTTP 协议的关系

image

URI 和 URL

URI(Uniform Resource Identifier)统一资源标识符
URL(Uniform Resource Locator)统一资源定位符

image
  • 登录信息:指定用户名和密码作为服务器端获取资源时必要的登录信息(可选)
  • 服务器地址:必须指定待访问的服务器地址
  • 服务器端口号:指定服务器连接的网络端口号(可选,省略的话使用默认端口号)
  • 带层次的文件路径:指定服务器上的文件路径来定位特指的资源
  • 查询字符串:针对已指定的文件路径内的资源,可以使用查询字符串传入任意参数(可选)
  • 片断标识符:使用片段标识符通常可标记出以获取资源中的资资源(可选)

第二章:简单的 HTTP 协议

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

HTTP 协议规定,请求从客户端发出,服务端响应该请求并返回。

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


image

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


image

HTTP 不保存状态协议

HTTP 是一种不保存状态,即无状态协议。它自身不具备保存之前发送过的请求或响应的功能,为了实现保持状态的功能,引入了 Cookie 技术。

告知服务器意图的 HTTP 方法

方法 用途 备注
GET 获取资源
POST 传输实体主体
PUT 传输文件
HEAD 获取报文首部
DELETE 删除文件 响应返回的状态码是 204
OPTIONS 询问支持的方法
TRACE 追踪路径
CONNECT 要求用隧道协议连接代理

向请求 URI 指定的资源发送请求报文时,采用称为方法的命令。方法名要用大写字母。

持久连接节省通信量

在 HTTP 初始版本中,由于传输数据容量比较小,每进行一次 HTTP 通信就要断开一次 TCP 连接;
随着 HTTP 普及,传输数据越来越大,未解决 TCP 连接问题,引入了持久连接(HTTP Persistent Connections,也成为 HTTP keep-alive 或 HTTP connection reuse),特点是:只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。

管线化

持久化连接是的多数请求以管线化方式发送称为可能,可以同时并行发送多个请求,而不需要一个接一个等待响应。

使用 Cookie 的状态管理

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
服务器在接受到请求后,在响应报文内加入 Set-Cookie,通知客户端保存 Cookie,当下次在发送请求时,会在请求报文中加入 Cookie 后发送出去。服务器在根据发送过来的 Cookie 去对比,从而保存状态信息。

第三章:HTTP 报文内的 HTTP 信息

用于 HTTP 协议交互的信息被称为 HTTP 报文,请求端(客户端)的报文叫做请求报文,响应端(服务端)的叫做响应报文。

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

HTTP 报文 大致可分为报文首部和报文主体,两者之间由空行(CR+LF)来划分。
请求报文


image

响应报文


image
  • 请求行:包含用于请求的方法,请求 URI 和 HTTP 版本
  • 状态行:包含表明响应结果的状态码,原因短语和 HTTP 版本
  • 首部字段:包含表明请求和响应的各种条件和属性的各类首部,一般有4种首部:通用首部、请求首部、响应首部、实体首部
  • 其他:可能包含 HTTP 的 RFC 里未定义 的首部,如:Cookie

编码提升传输速率

HTTP 在传输数据时可以按照数据原貌直接传输,也可以在传输时通过编码提升传输速率,但这样会消耗更多的 CPU 等资源

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

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

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

压缩传输的内容编码

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

常用的内容编码

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

分割发送的分块传输编码

在 HTTP 通信过程中,在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面的功能称为分块传输编码(Chunked Transfer Coding)。

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

HTTP 协议采用了多部分对象集合——MIME机制(Multipurpose Internet Mail Extensions,多用途因特网邮件扩展),它是一种允许处理文本、图片、视频等多种不同类型的数据。

在 HTTP 报文中使用 多部分对象集合时,需要在首部字段里加上 Content-type,使用 boundary 字符串来划分各个实体的起始行,需要在起始行前插入 "--" 标记,,最后以 "--" 结束。

获取部分内容的范围请求

指定范围发送的请求叫做范围请求

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

请求:
Range: bytes = 5001-10000

响应:
Content-Range: bytes 5001-10000/10000

针对范围请求,响应会返回状态码为 206 Partial Content 的响应报文,如果服务器无法响应范围请求,则会返回状态码 200 OK 和完成的实体内容。

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

同一个 Web 网站可能会存在多份相同内容的页面,比如英文版和中文版,当浏览器默认语言为中文时,访问 URI 的 Web 页面时,则会显示中文版的 Web 页面,这种机制称为内容协商(Content Negotiation)。

内容协商机制会在请求报文中用到下面首部字段:

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

内容协商技术有3种类型:

  • 服务器驱动协商:由服务器端进行内容协商。以请求的首部字段为参考,在服务端自动处理。
  • 客户端驱动协商:由客户端进行内容协商。用户利用浏览器提供的可选项列表手动选择;还可以利用 JavaScript 脚本在 Web 页面上自动进行选择。
  • 透明协商:是服务器驱动和客户端驱动的结合体,是由服务器端和客户端各自进行内容协商的一种方法。

第四章:返回结果的 HTTP 状态码

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

状态码的职责是当客户端向服务器端发送请求时,描述返回的请求结果。
状态码由三位数字和原因短语组成,其中数字第一位指定了相应类别,后两位无分类。

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

状态码

  1. 2XX 成功:表示请求被正常处理了
  • 200 OK 表示从客户端发来的请求在服务器端被正常处理了。
  • 204 No Content 请求处理成功,返回的响应报文中不含实体的主体部分
  • 206 Partial Content 表示客户端进行范围请求
  1. 3XX 重定向:表明浏览器需要执行某些特殊处理以正确处理请求
  • 301 Moved Permanently 永久重定向
  • 302 Found 临时重定向
  • 303 See Other 表示由于请求对应的资源存在着另一个 URI,应使用 GET 方法定向获取请求的资源
  • 304 Not Modified 表示客户端发送附带条件的请求,服务器端允许请求访问资源,但因发生请求未满足条件的情况后,直接返回 304 Not Modified。304 状态码返回时,不包含任何响应的主体部分,304 虽然被划分在 3XX 类别中,但和重定向没有关系
  • 307 Temporary Redirect 临时重定向,和 302 差不多,它不会把 POST 变成 GET
  1. 4XX 客户端错误:表明客户端发生错误的原因所在
  • 400 Bad Request:表示请求报文中存在语法错误
  • 401 Unauthorized:表示发送的请求需要有通过 HTTP 认证的认证信息
  • 403 Forbidden:表示请求资源被服务器拒绝了
  • 400 Not Found:表示服务器上无法找到请求资源
  1. 5XX 服务器错误:表明服务器本身发生错误
  • 500 Internal Server Error:表示服务器在执行请求时发生了错误
  • 503 Serveice Unavailable:表示服务器暂时处于超负荷或正在停机维护,无法处理请求。

第五章:与 HTTP 协作的 Web 服务器

HTTP/1.1 允许一台 HTTP 服务器搭建多个 Web 站点
在互联网上,域名通过 DNS 服务映射到 IP 地址之后访问目标网站,在相同 IP 下,发送 HTTP 请求时,必须在 Host 首部内完整指定主机名和域名的 URI

通信数据转发程序:代理、网关、隧道

  • 代理:是一种有转发功能的应用程序,它扮演了位于服务器和客户端“中间人”的角色
  • 网关:网关是转发其他服务器通信数据的服务器,接受从客户端发来的请求时,它就像自己拥有资源的源服务器一样对请求进行处理
  • 隧道:相隔甚远的客户端和服务器两者之间进行中转,并保持双方通信连接的应用程序

代理

使用代理服务器的理由:利用缓存技术减少网络带宽的流量,组织内部针对特定网站的访问控制,以获取访问日志为主要目的

缓存代理:代理转发时,缓存代理会预先将资源的副本缓存到代理服务器上,当代理再次接收到相同资源的请求时,就可以不从源服务器那里获取资源,而是将缓存的资源作为响应返回

透明代理:转发请求或响应时,不对报文做任何加工的代理类型称为透明代理

网关:

网关能使通信线路上的服务器提供非 HTTP 协议服务。
利用网关能提高通信的安全性

隧道

隧道的目的是确保客户端能与服务器进行安全的通信,隧道本身不会去解析 HTTP 请求,隧道会在通信双方断开连接时结束

保存资源的缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问,因此也节省了通信流量和通信时间。

缓存的有效期

缓存服务器内缓存室友有效期的,如果资源更新,缓存就没有用了,需要重新获取新的资源
客户端的缓存同缓存服务器一样

第六章:HTTP 首部

HTTP 协议的请求和响应报文中必须必定包含 HTTP 首部。首部内容为请求或响应所需要的信息

HTTP 请求报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成
HTTP 响应报文由 HTTP 版本、状态码、HTTP 首部字段组成

HTTP 首部字段

HTTP 首部字段是构成 HTTP 报文的要素之一。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

4种 HTTP 首部字段类型

  • 通用首部字段:请求报文和响应报文都会使用的首部
  • 请求首部字段:从客户端向服务器端发送请求报文时使用的首部
  • 响应首部字段:从服务器端向客户端返回响应报文时使用的首部
  • 实体首部字段:针对请求报文和响应报文的实体部分使用的首部

通用首部字段

首部字段名 说明
Cache-Control 控制缓存的行为
Connection 逐跳首部、连接的管理
Date 创建报文的日期时间
Pragma 报文指令
Trailer 报文末端的首部一览
Transfer-Encoding 指定报文主体的传输编码方式
Upgrade 升级为其他协议
Via 代理服务器的相关信息
Warning 错误通知

请求首部字段

首部字段名 说明
Accept 用户代理可处理的媒体类型
Accept-Charset 优先的字符集
Accept-Encoding 优先的内容编码
Accept-Language 优先的语言(自然语言)
Authorization Web 认证信息
Expect 期待服务器的特定行为
From 用户的电子邮箱地址
Host 请求资源所在的服务器
If-Match 比较实体标记(ETag)
If-Modified-Since 比较资源的更新时间
If-None-Match 比较实体标记(与If-Match相反)
If-Range 资源未更新时发送实体 Byte 的范围请求
If-Unmodified-Since 比较资源的更新时间(与 If-Modified-Since 相反)
Max-Forwards 最大传输逐跳数
Proxy-Authorization 代理服务器要求客户端的认证信息
Range 实体的字节范围
Referer 对请求中 URI 的原始获取方
TE 传输编码的优先级
User-Agent HTTP 客户端程序的信息

响应首部字段

首部字段名 说明
Accept-Ranges 是否接收字节范围请求
Age 推算资源创建经过时间
ETag 资源的匹配信息
Location 令客户端重定向至指定 URI
Proxy-Authenticate 代理服务器对客户端的认证信息
Retry-After 对再次发起请求的时机要求
Server HTTP 服务器的安装信息
Vary 代理服务器缓存的管理信息
WWW-Authenticate 服务器对客户端的认证信息

实体首部字段

首部字段名 说明
Allow 资源可支持的 HTTP方法
Content-Encoding 实体主体适用的编码方式
Content-Language 实体主体的自然语言
Content-Length 实体主体的大小(单位:字节)
Content-Location 替代对应资源的 URI
Content-MD5 实体主体的报文摘要
Content-Range 实体主体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体主体过期的日期时间
Last-Modified 资源的最后修改日期时间

第七章:确保 Web 安全的 HTTPS

HTTP的缺点:

  • 通信使用明文(不加密),内容可能会被窃听
  • 不验证通信方的身份,因此有可能遭遇伪装
  • 无法证明报文的完整性,所以有可能已遭篡改

通信的加密
HTTP 和 SSL(Secure Socket Layer,安全套连接)或 TLS(Transport Layer Security,安全传输层协议)组合使用,被称为 HTTPS(HTTP Secure,超文本传输安全协议)

内容的加密
把 HTTP 报文里所含的内容进行加密,前提需要客户端和服务器同时具备加密和解密机制

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

未完待续...

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容