[网络协议] HTTP协议理解及服务端与客户端的设计实现(1)

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> HTTP协议理解及服务端与客户端的设计实现(1) -> 正文阅读

[网络协议]HTTP协议理解及服务端与客户端的设计实现(1)

HTTP协议理解及服务端与客户端的设计实现(1)

网络参考模型和 HTTP 协议

TCP/IP 和 HTTP 的数据结构

实现 HTTP 服务端和客户端

HTTP 的传输数据的几种方式

HTTP 常见响应码和响应头的组合使用

收获：

TCP/IP 协议、HTTP 协议和 Socket 有什么区别？
如何基于 TCP/IP 实现一个 HTTP 服务端或者客户端？
服务端 HTTP API 发生未处理异常时为什么不会崩溃？
HTTP 在哪些情况下会请求超时？
Cookie 和 Session 有什么区别和联系？

1.网络参考模型和 HTTP 协议

HTTP 是超文本传送协议（HyperText Transfer Protocol）的缩写，要想具象的描述清楚 HTTP，我们需要先了解OSI 参考模型和TCP/IP 参考模型。
如果有人要我们介绍一下 HTTP 是什么，我相信大多数人会这样回答

HTTP 是基于 TCP/IP 协议的一个应用层协议。

那么TCP/IP协议是什么？

OSI 参考模型

个人认为 TCP/IP 相当于开放式系统互联通信参考模型中的的传输层和网络层，根据该模型的英文单词缩写，它被简称为OSI 参考模型，OSI 参考模型是一个尝试让全世界计算机互联为网络的概念性框架，它只是一个参考模型，并没有提供某种具体的实现方法或者标准，换句话说它是一个为定制标准提供参考的概念性框架。
OSI 参考模型中将计算机网络体系结构划分为 7 层，从下至上依次是

物理层：光纤和网卡等，负责通信设备和网络媒体之间的互通
数据链路层：以太网，用来加强物理层功能
网络层：IP 协议和 ICMP 协议等，负责数据的路由的选择与数据转寄
TCP 协议和 UDP 协议等，承上启下，控制连接，控制流量
会话层：建立和维护会话关系
表达层：把数据转换为接受者系统可兼容的格式
应用层：HTTP、FTP、SMTP 和 SSH 等，粗犷的理解为程序员层

OSI 参考模型定义了开放系统的层次结构和各层次之间的相互关系，它作为一个框架来协调和组织各层所提供的服务，如果要说的更贴近一点，它更像是一款行为规范，贴近生活的例子就是一个企业的企业文化。

TCP/IP 参考模型

TCP/IP 协议代表一整个网络传输协议家族，而不仅仅是 TCP 协议和 IP 协议，TCP 协议和 IP 协议是该协议家族中最早通过的最核心的两个协议标准，因此该协议家族被称作TCP/IP 协议族，也就是我们通常所说的 TCP/IP 协议。
要完成一个任务需要该协议家族的各种协议分工协作，就好比程序员分为前端、后端和 DB 等一样，把这些协议根据它们的责任分类，因此 TCP/IP 产考模型应运而生，在该参考模型中的网络体系结构一共分为 4 层，从下至上依次是：

网络连接层：主机与网络相连的协议，如：以太网
网络互联层：IP 协议和 ICMP 协议等，负责数据的路由的选择与数据转寄
传输层：TCP 协议和 UDP 协议等，控制端对端的连接、流量和稳定性
应用层：HTTP、FTP、SMTP 和 SSH 等，粗犷的理解为程序员层

TCP/IP 参考模型看起来和 OSI 参考模型有有一定的相似性，然而由于各种应用层实现的不同，它们之间没有一种绝对的对称关系，我们可以大致的将它们按照以下对应关系来理解和区分：
在这里插入图片描述

HTTP 协议与 TCP/IP 协议

如果认真的看了上面的表格，我们可以知道，HTTP 是 TCP/IP 参考模型中应用层的其中一种实现。HTTP 协议的网络层基于 IP 协议，传输层基于 TCP 协议，因此就引出了我们开头说到的：HTTP 协议是基于 TCP/IP 协议的应用层协议。

上文中提到，可以把应用层理解为“程序员层”，TCP/IP 协议需要向程序员提供可编程的 API，该 API 就是 Socket，它是对 TCP/IP 协议的一个重要的实现，几乎所有的计算机系统都提供了对 TCP/IP 协议族的 Socket 实现。综上所述，我们就可以使用 Socket 来进行网络通信了，而 HTTP 协议也需要向程序员提供可编程的 API，该 API 的实现也就基于 Socket 来实现了。

如何理解 Socket 呢？就像在生活中打电话一样，有打电话的一端，就有接电话的一端，Socket 也是一样的，作为 TCP/IP 协议族的的实现，生来就是为了完成通信。虽然每一台主机设备都可以作为打电话的一端（客户端），也可以作为接电话的一端（服务端），但是打电话和接电话的动作在行为上来看是不同的。因此计算机系统的 Socket 实现也提供了两套 API，我们在这里约定一下，提供服务端能力的称作ServerSocket，提供客户端能力的称作Socket。
在这里插入图片描述
Nginx 是基于 Socket 实现的 HTTP 服务端，OkHttp、URLCollection 等都是基于 Socket 实现的 HTTP 客户端，而浏览器就是这些 HTTP 客户端的具象。
到这里，我们就可以回答第一个问题了：

TCP/IP 协议、HTTP 协议和 Socket 有什么区别？

我们先来看几张图，从纵向来看，它们的继承关系是这样的：
在这里插入图片描述
从横向来看，它们的继承关系是这样的

总结一下，TCP/IP 是一个协议族，Socket 是对 TCP/IP 协议族 API 实现；HTTP 是超文本传输协议的简称，属于 TCP/IP 参考模型的应用层，HTTP 的 API 实现一般都要依靠 TCP/IP 的 API 实现。也就是说一般情况下， HTTP 服务端或者客户端都是基于 Socket 来实现的，而像 Nginx、Apache、Chrome 和 IE 等软件都是基于 HTTP 服务端或者客户端而开发来的。

TCP/IP 和 HTTP 的数据结构

HTTP 作为 TCP/IP 参考模型的应用层，谈到它的数据结构势必要了解 TCP/IP 参考模型中其他层的数据结构，把 HTTP 放到 TCP/IP 参考模型中，它们的继承结构是这样的：
在这里插入图片描述
在上述继承结构中，每一层都有各自的结构，就好比爷爷、爸爸和儿子虽然是父子孙关系，但是爷爷有爷爷特点，爸爸有爸爸的特点，儿子有儿子的特点。同样的，上述每一层的结构大致是相同的，基本都是Header + Body这样的结构，以太网还多一层尾部，所以以太网层的结构式是Header + Body + Footer。
如果我们以以太网作为最底层，在 TCP/IP 参考模型中它们的整体的数据结构是：IP 作为以太网的直接底层，IP 的头部和数据合起来作为以太网的数据，同样的 TCP/UDP 的头部和数据合起来作为 IP 的数据，HTTP 的头部和数据合起来作为 TCP/UDP 的数据
在这里插入图片描述
在上图中的传输成我使用了 TCP 来代替，实际上还可以使用 UDP 来实现，例如 HTTP3 种就使用了 UDP 作为了传输层。本文中还是依然以 TCP 协议作为传输层讲解。
在 HTTP 中，以太网层的数据结构对于普通开发者来说太底层了，估计讲了也难以理解，我们从普通开发者可以接触到的 IP 层开始讲起。

IP 的数据结构和交互流程

我们都知道在一个成功的 HTTP 请求中，服务端可以在一个请求中获取到客户端 IP 地址，也可以获取到客户端请求的主机的 IP 地址。然而这是怎么做到的呢？这就有赖于 IP 协议了，在 IP 协议中规定了，IP 的头部必须包含源 IP 地址和目的 IP 地址，这也是为什么在 TCP/IP 参考模型中IP 处在网络互联层，其中一个原因就是可以定位服务端地址和客户端地址，我们来看一下 IP 的数据结构：
在这里插入图片描述
可以很清晰的看到源 IP 地址和目的 IP 地址，在 IP 的头部各占 32 位，而 IPV4 的 IP 地址是用点式十进制表示的，例如：192.168.1.1，在 IP 头部用二进制表示的话，刚好是 4 个字节 32 位。

不过 32 位可以表示的 IP 地址是有限的，目前在全球来看北美拥有 30 多亿个 IP 地址，中国拥有近 3 亿左右个 IP 地址，无奈中国的网民实在太多了，于是使用了 IP 地址转换技术 NAT。例如 ABC 三个小区的所有设备可能公用了一个公网 IP，通过 NAT 技术分给每一户一个私有 IP 地址，大家在小区内交流时可能使用的是私有 IP 地址，但是向外交流时就用公网 IP

当客户端要和服务端建立连接时，需要指定服务端的域名或者 IP 地址，在一般情况下，一个主机的 IP 地址是固定且唯一的，在一个主机上也可以部署多个应用。当客户端使用 IP 地址直链服务端的时候，由于通过地址无法确定客户端要要连接的应用，只能通过指定端口来确定要连接的应用，而要记忆IP + Port对于用户来说非常不友好，所以要通过同一个端口（甚至基于某个应用的默认端口，例如 HTTP 默认使用 80 端口）要连接同一个主机的多个应用只能从地址来下手。同时由于 IP 地址的特点，让 IP 地址的数量变得有限，并且 IP 地址实际上都被 ISP 所持有，只是租赁给开发者使用，因此当开发者更换了 ISP 时 IP 地址是不会跟着开发者变更的。基于以上两点就产生了域名，域名是无限多的，如果让多个域名都解析到同一个 IP 地址，那么这么这个主机就拥有了多个别名，当外部应用通过不同的域名来连接该主机时，在该主机内部就可以通过不同的别名，把该连接指向不同的应用。

举个栗子：
在你所工作的公司里，有一台服务器，IP 地址是192.168.1.11，在这台服务器上部署了文档网站、设计网站和办公网站，在没有域名的时候分别这样访问这三个网站：

文档网站：http://192.168.1.11:8080
设计网站：http://192.168.1.11:9090
办公网站：http://192.168.1.11:8899

甚至在另一台主机上还部署了 CRM 系统和 CMS 系统等等，这样就要记忆（或者写到小本本上）多个 IP 和不同的端口，现在假设我们公司的域名是666.com，如果我们使用域名的话，上述的地址嫁将会变得很好记忆：

文档网站：http://doc.666.com
设计网站：http://ui.666.com
办公网站：http://oa.666.com
CRM系统：http://crm.666.com

现在，当客户端使用域名连接服务端的时候，需要通过 IP 寻址来确定服务器在网络中的位置，主要是以下两步：

通过 hosts 或者 DNS 查找主机名对应的 IP 地址
通过 ARP 寻址查找主机对应的 MAC 地址

上述两步的主要目的是查到 MAC 地址进行网络连接层的封装和数据发送，MAC 地址是根据 IP 地址进行 ARP 寻址找到的。因此首先得知道指定的域名对应的 IP 地址，此时需要通过 DNS 缓存来查找域名对应的 IP 地址，一般情况下有这么几级：

查找系统的 hosts 中配置的 DNS 映射
查找系统自身的 DNS 缓存
查找路由器中的 DNS 缓存
查找 IPS 的 DNS 缓存
每一级的 DNS 缓存都是有时效性的，在上一层找到对应的映射后就不会向下寻找了。获得了 IP 之后，根据 IP 地址和子网掩码计算出自己所在的网段，在网段内查找对应主机的 MAC 地址，然后在数据链路层进行封装和数据发送。