HTTP 基础摘要

Posted 2023-05-03

参考技术A

注：以下内容摘自《图解 HTTP》，仅作学习记录。若有断章取义之处，望阅原文。

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

TCP/IP 是互联网相关的各类协议族的总称。

TCP/IP 协议族：EEEE 802.3、IP、ICMP、PPPoE、DNS、TCP、UDP、FTP、FDDI、HTTP、SNMP...

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

按层次分，IP（Internet Protocol）网际协议位于 网络层 。

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

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

IP 间的通信依赖 MAC 地址。在网络上，通信的双方在同一局域网 （LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的 MAC 地址来搜索下一个中转目标。这时，会采用 ARP 协议 （Address Resolution Protocol）。 ARP 是一种用以解析地址的协议，根据通信方 的 IP 地址就可以反查出对应的 MAC 地址 。

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

所谓的 字节流服务 （Byte Stream Service）是指，为了 方便传输 ，将大块数据分割成以 报文段 （segment）为单位的数据包进行管理。而 可靠的传输服务 是指，能够把数据准确可靠地传给对方。

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

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

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

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

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

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

URI 是 Uniform Resource Identifier 的缩写。

URI 是由某个协议方案表示的资源的定位标识符 。

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

HTTP 是一种不保存状态，即 无状态（stateless）协议 。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说 在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理 。

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

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

每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。

为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久连接 （HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是， 只要任意一端没有明确提出断开连接，则保持 TCP 连接状态 。

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

💡 在 HTTP/1.1 中，所有的连接默认都是持久连接。

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

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

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

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

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

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

HTTP 在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中 通过编码提升传输速率 。通过在传输时编码，能 有效地处理大量的访问请求 。但是，编码的操作需要计算机来完成，因此会 消耗更多的 CPU 等资源 。

HTTP 协议中有一种被称为 内容编码 的功能也能进行类似压缩邮件文件的操作。

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

在 MIME 扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。

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

在 HTTP 报文中使用多部分对象集合时，需要在首部字段里加上 Content-type 字段。使用 boundary 字符串来划分多部分对象集合指明的各类实体。

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

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

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

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

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

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

在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定义的 47 种首部字段。还有 Cookie 、 Set-Cookie 和 Content-Disposition 等在其他 RFC 中定义的首部字段，它们的使用频率也很高。

HTTP 首部字段将定义成 缓存代理 和 非缓存代理 的行为，分成 2 种类型。

下面列举了 HTTP/1.1 中的 逐跳首部字段 。除这 8 个首部字段之外，其他所有字段都属于端到端首部。

HTTP/1.1 使用的认证方式如下所示：

分布式技术追踪 2017年第一期

 

分布式系统实践

1. 大话分布式系统理论基础

http://dwz.cn/4UWN7i

摘要: 一致性是分布式系统的理论基础, 这篇文章从2PC, 3PC开始, 概述了支撑分布式系统一致性的各个理论, 便于大家再进行更深入和细致的学习.

2. 美团云混合存储系统

http://dwz.cn/4VpOzJ

摘要: (编者的话)美团云的李慧霸分享的混合存储系统议题非常独特，美团云的存储系统是自己开发的，没有使用开源系统，整个建设思路和方法值得借鉴，因此特别分享下李慧霸的PPT。

服务化和虚拟化技术

1. 京东容器集群建设之路

http://dwz.cn/4VTIRl

摘要: 京东应该是引入docker比较早的公司了, 借助于在OpenStack上的经验, 基于OpenStack开发了第一代容器云平台, 运行的容器多达15万. 本文介绍了京东容器云建设之路, 为大规模的容器应用提供了一个良好的案例.

2. 网易蜂巢基于万节点kubernetes支撑大规模云应用实践

http://dwz.cn/4VZOhy

摘要: 网易蜂巢容器云平台, IaaS层基于OpenStack支持计算, 存储, 网络的虚拟化, PaaS层使用k8s实现容器的编排, 同时提供缓存, 数据库等通用SaaS, 是一个典型的虚拟机+容器的实践.

高可用技术

1. 微信PaxosStore内存篇：十亿Paxos/分钟的挑战

http://dwz.cn/4WMcoE

摘要: 今年微信开源了很多东西, 特别是一些列围绕paxos的应用, 比如之前介绍过的PhxSQL等, 可见微信团队在Paxos上进行了不少的工程实践, 值得我们学习和借鉴.

2. Google是如何做负载均衡的？

http://dwz.cn/4Xj633

摘要: Google 使用的技术一般都自带光环，吸引程序员的注意，基础设施方面的东西就更是如此，年初 Google 发布了篇论文介绍内部的负载均衡器的实现，让我们有机会一睹可能是全球最好的负载均衡器。Maglev修改源IP为路由器IP, 让响应包绕过负载均衡器直接, 直接面向网卡编程, 绕过linux内核协议栈, 使用一致性hash硬生生的把有状态的服务改成了无状态.

运维和DevOps技术

1. Netflix Conductor：微服务编排器

http://dwz.cn/4UX6U5

摘要: 工作流引擎是管理例行运维的最有效工具, 一直想找一个好用的工作流引擎, 类似amazon SWF, 可惜SWF不开源. 很多开源的工作流引擎都在支持DAG上下功夫, 然而对于运维任务来说, 对于DAG没有强需求, 强需求是简单可编程的工作流管理. 下来可以仔细研究研究.

2. 万台分布式数据库的创新运营

http://dwz.cn/4VSVZD

摘要: 数据服务这种有状态的服务一直是运维的"灾区", 因为不能丢数据, 所以在运维处理上必须非常小心谨慎. 这篇文章介绍了腾讯万台规模的分布式KV存储系统的运维经验, 文章谈到的使用访问密度刻画服务负载能力, 存储备机的复用, 自动扩缩容和数据搬迁, 不同访问密度的服务混布, 故障自愈能力等方面都非常值得学习.

基础和文化

1. 一种NVMe SSD友好的数据存储系统设计

http://dwz.cn/4VqcUS

摘要: 传统存储系统的很多设计理念不再适用于闪存存储系统, 因此不管是我们自身还是业界都在寻找SSD友好的存储引擎, 这篇文章介绍的存储引擎将随机写转换成顺序写, 而随机读保持不变, 同时针对设计了针对SSD垃圾回收的垃圾回收策略, 从而实现了面向SSD友好的存储引擎设计.

2. Docker背后的内核知识——Namespace资源隔离

http://dwz.cn/4W0izO

摘要: namespace隔离是实现容器隔离的技术手段之一, 这篇文章科普了namespace隔离的机制, 包括了linux 六大namespace, 文章分为上下两部分. 链接中的是上篇, 下篇http://dwz.cn/4WLWEb

---

分布式技术动态周刊运转一年半以来受到了很多同学的好评, 不过一直发布在公司的内部wiki上. 为了让更多的朋友也能看到, 我申请了一个微信公众号, 每周同步发布, 希望能够帮助大家在众多技术类文章中挑选出分布式技术方向比较优秀的文章, 让不同层次的朋友都能有所收获.