网络协议的初步认识-以详细案例分析


什么是协议?相当于正常交流必须掌握的一种规范,双发都懂的一种约束规则。比如要看发送和接收电报,需要有一个密码本来解密信息,这个密码本就是双方的协议。

为什么会出现协议?互联网世界可以理解为机器间的交互,若需要两台机器完成某件事,那么这两台机器的“对话”双方必须都听得懂,我们不可能要求两台机器一模一样,就像不能要求两个人一样,所以为了方便交互就制定了协议,只要大家都用各自的方式看懂协议就能交流。

协议三要素

  • 语法,就是一段内容要符合一定的规则和格式。
  • 语义,就是这一段内容要代表某种意义。例如数字减去数字是有意义的,数字减去文本一般
    来说就没有意义。
  • 顺序,就是先干啥,后干啥。必须严格遵守的秩序。

当然要完成不同的交互需要的协议自然不同,这里列举一段 HTTP 协议来看看协议长什么样?

当我们打开浏览器输入网址网购时,这个网址其实就是一种协议的格式,比如,网易考拉格式像下面这样:

HTTP/1.1 200 OK
Date: Tue, 27 Mar 2018 16:50:26 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: zh-CN
<!DOCTYPE html>
<html>
<head>
<base href="https://pages.kaola.com/" />
<meta charset="utf-8"/> <title> 网易考拉 3 周年主会场 </title>

我们来看看这符合协议三要素吗?
首先,符合语法,只有按照上面的格式,浏览器才会认识。即 状态、部首、内容
第二,符合语义,就是按照约定的意思。例如,状态 200,表示的意思就是网页成功返回,如果不成功可能就是 404
第三,符合顺序,一点浏览器,就是发送一个 HTTP 请求,然后才有上面一串 HTTP 返回的东西。

浏览器显然按照协议商定好的做了,最后一个五彩缤纷的页面就出现在你面前了。

常用的网络协议有哪些?以购物下单过程描述

用一个购物下单的过程,看看互联网世界在运行中使用了哪些网络协议。

你先在浏览器里面输入 https://www.kaola.com ,这是一个URL。浏览器只知道名字
是“www.kaola.com”,但是不知道具体的地点,所以不知道应该如何访问。于是,它打开地
址簿去查找。可以使用一般的地址簿协议DNS去查找,还可以使用另一种更加精准的地址簿查找协议HTTPDNS。

无论用哪一种方法查找,最终都会得到这个地址:106.114.138.24。这个是IP地址,是互联网
世界的“门牌号”。

知道了目标地址,浏览器就开始打包它的请求。对于普通的浏览请求,往往会使用HTTP协议;但是对于购物的请求,往往需要进行加密传输,因而会使用HTTPS协议。无论是什么协议,里面都会写明“你要买什么和买多少”。
在这里插入图片描述
DNS、HTTP、HTTPS 所在的层我们称为应用层。经过应用层封装后,浏览器会将应用层的包交给下一层去完成,通过 socket 编程来实现。下一层是传输层。传输层有两种协议,一种是无连接的协议UDP,一种是面向连接的协议TCP。对于支付来讲,往往使用 TCP 协议。所谓的面向连接就是,TCP 会保证这个包能够到达目的地。如果不能到达,就会重新发送,直至到达。

TCP 协议里面会有两个端口,一个是浏览器监听的端口,一个是电商的服务器监听的端口。操作系统往往通过端口来判断,它得到的包应该给哪个进程
在这里插入图片描述
传输层封装完毕后,浏览器会将包交给操作系统的网络层。网络层的协议是 IP 协议。在 IP 协议里面会有源 IP 地址,即浏览器所在机器的 IP 地址和目标 IP 地址,也即电商网站所在服务器的IP 地址。
在这里插入图片描述
操作系统既然知道了目标 IP 地址,就开始想如何根据这个门牌号找到目标机器。操作系统往往会判断,这个目标 IP 地址是本地人,还是外地人。如果是本地人,从门牌号就能看出来,显然电商网站不在本地,而在遥远的地方。

操作系统知道要离开本地去远方。虽然不知道远方在何处,但是可以这样类比一下:如果去国外要去海关,去外地就要去网关。而操作系统启动的时候,就会被 DHCP 协议配置 IP 地址,以及默认的网关的 IP 地址 192.168.1.1。

操作系统如何将 IP 地址发给网关呢?在本地通信基本靠吼,于是操作系统大吼一声,谁是
192.168.1.1 啊?网关会回答它,我就是,我的本地地址在村东头。这个本地地址就是MAC地
址,而大吼的那一声是ARP协议。
在这里插入图片描述
于是操作系统将 IP 包交给了下一层,也就是MAC 层。网卡再将包发出去。由于这个包里面是
有 MAC 地址的,因而它能够到达网关。

网关收到包之后,会根据自己的知识,判断下一步应该怎么走。网关往往是一个路由器,到某个IP 地址应该怎么走,这个叫作路由表。

路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家,每个国家内部相当于一个局域网,在每个国家内,都可以使用本地的地址 MAC 进行通信。

一旦跨越城关,就需要拿出 IP 头来,里面写着贫僧来自东土大唐(就是源 IP 地址),欲往西天拜佛求经(指的是目标 IP 地址)。路过宝地,借宿一晚,明日启行,请问接下来该怎么走啊?
在这里插入图片描述
城关往往是知道这些“知识”的,因为城关和临近的城关也会经常沟通。到哪里应该怎么走,这
种沟通的协议称为路由协议,常用的有OSPF和BGP。

城关与城关之间是国家,当网络包知道了下一步去哪个城关,还是要使用国家内部的 MAC
地址,通过下一个城关的 MAC 地址,找到下一个城关,然后再问下一步的路怎么走,一直到走出最后一个城关。

最后一个城关知道这个网络包要去的地方。于是,对着这个国家吼一声,谁是目标 IP 啊?目标服务器就会回复一个 MAC 地址。网络包过关后,通过这个 MAC 地址就能找到目标服务器。

目标服务器发现 MAC 地址对上了,取下 MAC 头来,发送给操作系统的网络层。发现 IP 也对上了,就取下 IP 头。IP 头里会写上一层封装的是 TCP 协议,然后将其交给传输层,即TCP层。

在这一层里,对于收到的每个包,都会有一个回复的包说明收到了。这个回复的包绝非这次下单请求的结果,例如购物是否成功,扣了多少钱等,而仅仅是 TCP 层的一个说明,即收到之后的回复。当然这个回复,会沿着刚才来的方向走回去,报个平安。因为一旦出了国门,西行路上千难万险,如果在这个过程中,网络包走丢了怎么办呢?因而到了要报个平安。

如果过一段时间还是没到,发送端的 TCP 层会重新发送这个包,还是上面的过程,直到有一天收到平安到达的回复。这个重试绝非你的浏览器重新将下单这个动作重新请求一次。对于浏览器来讲,就发送了一次下单请求,TCP 层不断自己闷头重试。除非 TCP 这一层出了问题,例如连接断了,才轮到浏览器的应用层重新发送下单请求。

当网络包平安到达 TCP 层之后,TCP 头中有目标端口号,通过这个端口号,可以找到电商网站的进程正在监听这个端口号,假设一个 Tomcat,将这个包发给电商网站。

在这里插入图片描述
电商网站的进程得到 HTTP 请求的内容,知道了要买东西,买多少。往往一个电商网站最初接待请求的这个 Tomcat 只是个接待员,负责统筹处理这个请求,而不是所有的事情都自己做。例如,这个接待员要告诉专门管理订单的进程,登记要买某个商品,买多少,要告诉管理库存的进程,库存要减少多少,要告诉支付的进程,应该付多少钱,等等。

如果告诉相关的进程呢?往往通过 RPC 调用,即远程过程调用的方式来实现。远程过程调用就是当告诉管理订单进程的时候,接待员不用关心中间的网络互连问题,会由 RPC 框架统一处理。RPC 框架有很多种,有基于 HTTP 协议放在 HTTP 的报文里面的,有直接封装在 TCP 报文里面的。

当接待员发现相应的部门都处理完毕,就回复一个 HTTPS 的包,告知下单成功。这个HTTPS的包,会像来的时候一样,经过千难万险到达你的个人电脑,最终进入浏览器,显示支付成功。

小结

一个简单的下单过程,中间会涉及到这么多协议。而管理一大片机器,更是一件特别有技术含量的事情。像云计算、容器、为服务等技术也需要借助各种协议来达成大规模机器之间的合作。在五层模型中常见的协议如下:
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/qq_40488936/article/details/106967362