网络编程-网络原理HTTP初识

TCP/IP五层协议栈

具体的内容, 我们之前的网络初始里面有, 其实就是先前的计算机的发明者把计算机网络通信分为了不同的层次, 教科书上一般是OSI五层网络架构, 我们日常开发常用的是TCP/IP五层协议栈

在先前的套接字里, 我们主要是在传输层进行工作, 但是我们日常开发使用最多的其实还是应用层, 所以应用层常用的一些协议才是我们学习的重点
我们在开发的时候, 可以使用下面两种方法组织发送的信息

• 使用自定义的协议
• 使用官方认定的协议(例如http)

---

关于自定义协议

关于自定义协议, 主要分为两个阶段

• 根据需求, 明确需要传输那些消息
• 约定好传输文件的格式

说成大白话就是你自己编一个自己能看懂的协议就行了

常见自定义协议引入

---

下面我们列举几种常见的自定义协议的方式

我们使用的案例均为: 外卖订餐的场景
我们外卖订餐的时候, 向服务器发送的请求数据一般是如下的内容(简化版本)

请求: 客户ID, 客户地址, 客户联系方式, 商家ID, 商家商品编号…
响应: 是否成功订餐(1/0), 预计多长时间送达, 福利信息(优惠卷)

---

行文本格式

在发送的时候把这些信息通过一些特定的字符进行分割, 然后拼接为一个字符串, 服务器就可以解析到, 返回的时候依然是这样的格式, 这种方法是最简单的一种自定义协议, 现在基本不用了
我们的样例使用 , 号分割

例:

请求: C1826445, 郑州市中原区郑州大学图书馆, 13645632156, S562347, SP13
响应: 1, 35分钟, 2元代金券

通过简单的行文本, 我们就可以构造自己的一种传输协议
优缺点:

• 优点: 节省网络资源
• 缺点: 可读性差, 仍然存在冗余信息(分隔符)

---

XML格式

还可以通过XML的格式进行请求和响应, XML是一种和HTML十分相似的格式, 也是通过标签来组织内容, 但是HTML的标签的内容, 都是设计HTML语言的人规定好的(HTML5也允许自定义了), 但是XML的格式是可以程序员定制的

使用XML格式的请求与响应实例如下

请求

<requset><customer_ID>C1826445</customer_ID><customer_addr>郑州市中原区郑州大学图书馆</customer_addr><customer_phoneNum>13645632156</customer_phoneNum><shop_ID>S562347</shop_ID><shop_food_ID>SP13</shop_food_ID>
</requset>

响应

<responce><isOrdered>1</isOrdered><wait_time>35</wait_time><reward>2元代金券</reward>
</responce>

优缺点:

• 优点: 可读性好
• 缺点: 冗余信息过多, 网络传输中过于消耗资源

所以在现在, XML也不作为自定义协议的首选了

---

JSON

这个是当下主流的自定义协议的方案

和XML类似, 也是使用键值对的方式来传输消息, 但是少了许多冗余信息

请求

{"customer_ID": "C1826445","customer_addr": "郑州市中原区郑州大学图书馆","customer_phoneNum": "13645632156","shop_ID": "shop_ID","shop_food_ID": "SP13"
}

响应

{"isOrdered": 1,"wait_time": 32,"reward": "2元代金券"
}

这种使用JSON作为自定义协议的方式是当下最主流的方式, 要重点记忆

优点: 可读性好, 占用资源少
缺点: 仍存在少量冗余信息

---

protobuf

这是一种基于二进制格式对数据进行压缩, 不涉及到XML, JSON的冗余信息了, 但是可读性不好, 完全没有冗余信息所以适合高性能的相关场景, 但是大部分场景使用JSON就足够了

使用二进制的方式, 客户端和服务器端规定字节区间对应的数据内容
比如上图的中的蓝色的字节区间就对应了一种数据信息…
优缺点

• 优点: 基于二进制, 冗余最小,节约资源, 适合高性能场景
• 缺点: 可读性极差

---

HTTP原理

非自定义的应用层协议

关于应用层的协议, 除了自定义的, 还有好多官方的协议

DNS(域名解析相关), URL(唯一地址标识符), HTML(超文本标记语言, 网页前端相关)
SSH(远程操控主机), FTP(文件传输相关), TELNET(网络调试工具), SSL(安全层相关)
HTTP(超文本传输协议, 也是web开发最核心的协议), HTTPS(HTTP+(S(安全)–>SSL))加上安全相关内容的HTTP协议

在这么多协议中, 我们重点学习 HTTP(HTTPS)

HTTP的发展

主要发展流程图如下

HTTP 往往是基于传输层的 TCP 协议实现的.
HTTP1.0, HTTP1.1, HTTP2.0 均为TCP实现的, 但是 HTTP3 基于UDP 实现

⽬前我们主要使⽤的还是 HTTP1.1 和 HTTP2.0, HTTP3.0普及程度不高

---

HTTP的传输模式

HTTP传输的模式属于典型的一问一答
即客户端发送一个请求, 服务器就返回一个响应

网络中还存在其他的协议模式

• 多问一答: 上传大文件场景
• 一问多答: 下载大文件场景
• 多问多答: 远程控制场景

---

HTTP协议中的代理模式和抓包工具

我们使用HTTP协议进行通信的时候, 浏览器发送一个请求的申请, 然后交给一个"代理", 通过这个代理进行转发, 服务器接收的时候也是这样, 然后服务器发送响应的时候, 又会经过这个代理…
示意图如下

每一个代理都对请求和响应进行转发, 客户端的代理(抓包工具)成为正向代理, 服务器端的代理称为反向代理
其实仔细想一想, 你电脑上的所有的请求, 都需要经过抓包工具的转发, 那其中涉及的网络安全问题其实是很严重的

---

抓包工具有

• wireshark: 可以抓很多协议, HTTP, UDP, IP, 以太网数据帧
• fiddler: 专门抓HTTP的, 使用简单

下载之后进行简单的配置就可以进行抓包了, 这里不再细说

---

简单测试一下抓包

我们尝试简单抓一个leetcode平台的http请求

打开fiddler, 不同颜色的含义如下

• 蓝色的表示获取到了一个网页(HTML)
• 红色的表示得到了一个CSS
• 绿色的表示得到了一个JS
• 灰色的表示这个响应的数据被缓存了
• 红色的表示报错

点进去右侧会显示请求和响应的信息
下面是请求信息, 点击RAW表示的请求的源文件

点击view in Notepad, 使用记事本打开

下面就是HTTP的请求文件的主体(我们之后会细致分析)

请求页面的下面是响应页面(通常需要转码)

点击RAW查看响应的源文件

具体的HTTP相关内容我们之后介绍, 本节只是一个初始, 初步了解一下HTTP是什么, 以及如何进行抓包查看HTTP请求和响应的源文件