人生若只如初见。
前言
当我在台灯下,听着远隔17年前五月天的歌,而在数日后,我的文字也会纵使相隔万里远的来到你的屏幕前,就觉得这一切妙不可言。
OSI 网络七层模型
《如果把网络原理倒过来看,从无到有,一切都清晰了(上) 》
《如果把网络原理倒过来看,从无到有,一切都清晰了(中) 》
继上两篇之后,我们的网络规范和标准也逐渐清晰。可以看到国际标准化组织提出OSI 七层模型网络分层模型,如下图所示,每一层提供的功能。
每一层只需关注所在这一层的事情,而且每一层都可以使用下一层提供的服务,例如 只解决设备之间通信问题的物理层,再到在物理层之上物理链路+协议的传输层,而传输层同样也需要使用网络层提供的路由和寻址功能,传输层可以知道把数据传输到哪里去。
虽然 OSI
的七层体系理论完整,但却比较复杂,在市场上就显得不实用,而且有些功能在多个层中重复出现。
所以,七层模型就显得有些笨重,而且现在也没有了市场。虽然历史上它得到过官方的大力支持,但市场更青睐TCP/IP
四层模型。
TCP/IP模型
TCP/IP 四层模型 是目前广泛采用的一种模型,可以将 TCP/IP 模型看作是 OSI七层模型的精简版,由以下 四 层组成:
4. 应用层
3. 传输层
2. 网络层
1. 网络接口层
如下图所示:
TCP/IP 四层模型 是怎么干过 OSI 七层模型的?
其中有许多的说法,TCP/IP
在互联网上已经抢先全球范围成功运行,所以使得OSI
标准生产的设备错失市场。
以及 OSI
的专家缺乏市场经验,而且实现起来过分复杂,所以运行效率低。OSI
的层次划分不太合理,功能层次重复出现等等。
也有许多专家有过评论,其中以不知是否是段子的一个评论。
普度大学特聘教授Douglas Comer的批评最为激烈。他曾经在一篇文章里这样写过:
“最近有了一些惊人的发现:我们都知道这个七层模型是由一个小组完成的,但大家不知道的是,这个小组有一天深夜在酒吧里谈论美国的娱乐八卦。他们把迪斯尼电影里7个小矮人的名字写在餐巾纸上,有个人开玩笑说7对于网络分层是个好数字。第二天上午在标准化委员会的会议上,他们传阅了那张餐巾纸,然后一致同意昨晚喝醉时的重大发现。那天结束时,他们又给七个层次重新起了听上去更科学的名字,于是模型就诞生了。
有了钢筋水泥后,将网络再倒回来看
前两篇我们是把网络倒过来,从设计网络之初开始,到从物理世界构建起了虚拟世界的路。
也就是说虚拟世界的钢筋水泥都搭建好后,接下来是更贴近用户的网络层级(可以说是连接用户)。
那么我们不如将网络再倒回来看。
从你输入网址后发生了什么?
URL:统一资源定位符
网址其实就是一串URL(Uniform Resource Locator)
被称为 统一资源定位符,URL
的格式如下所示:
所以,浏览器第一步工作是解析 URL
后,请求发送给服务器,所以 URL
(统一资源定位符)顾名思义,就是请求服务器里的文件资源。 如下图所示。
(下图所示,Web
服务器的 ”/“ 根目录是web
股务器配置文件中指定的根路径)
DNS:域名系统
DNS(Domain Name System)
,用户与互联网上某台主机通信时,必须要知道主机的IP地址(也就是资源的所在位置)。
而用户不太容易记住点分十进制IP地址,所以DNS的出现就是为了解决这个问题。域名系统DNS能够把互联网上的主机名字转换为IP地址。
例如我们国内多数互联网产品的域名都是用拼音,例如网上购物时,你不需要记住淘宝的IP地址(也可能也记不住),但是你知道它的名字,用拼音就可以找到。
所以DNS是专门存储域名与 IP
的对应关系的服务器。
域名的分层结构
DNS
中的域名用 “.” 分隔,例如 www.xxx.com
的点来表示不同层次域名。
而域名在最后都有一个根域名,同样用 “.” 点表示,如 www.xxx.com.
。
所以,DNS分层级的规律是越靠右的位置表示其层级越高。
例如,根域在最顶层,它的下一层就是 .com
是一级域名,以此类推,再往下是 xxx.com
是三级域名。如下图所示。
而DNS为什么不叫“名字”而叫“域名”呢?
还记得中篇畅聊过的AS
(自治域)吗?所构成的庞大互联网,其实是由无数个自治域相互组成(简单的说到网络与网络的之间的连接形成的是互联网),感兴趣的伙伴可以回顾,这里就不再赘述。
当这些内部网络最后形成了规模非常大的网络时,如果让所有的路由器知道所有的网络应怎样到达,则这种路由表将非常大,处理起来也太花时间,协议都跑不过来。
而且很多不同的单位可能不愿意外界了解自身网络的布局细节和所采用的路由选择协议(这属于内部的事情),但同时还希望连接到互联网上。
就像在地球上也被划分成若干个不相同的“国家”一样。而每个国家都有自己一套货币,语言,文化,政治(管理规范和路由策略)。而这些网络被称为自治域或自治系统 (
autonomous system
),简称为AS
。—— 《如果把网络原理倒过来看,从无到有,一切都清晰了(中)》
而正因为在互联网的命名系统中使用了许多的 “域”,因此就出现了 “域名” 。
应用层
接着当来到了应用层,应用层协议给不同的应用提供了各自需要的应用层网络协议。
例如,常见的文件传输的FTP
协议,以及支持电子邮件的 SMTP
协议,还有Web
应用中的 HTTP
协议等等。
HTTP
就是用来请求来加载浏览器网页中的协议。
HTTP
HTTP(HyperText Transfer Protocol)
超文本传输协议。顾名思义是不止文本的文本,包含数据可以是文字、图片、视频等数据,而最关键是超链接,能从一个超文本跳转到另外一个超文本。
最常见的超文本就是 HTML
了,其本身是纯文字文件,但内部用很多标签,可以定义了图片、视频等的链接,再经过浏览器的解析后呈现给我们的就可以是一个既有文字、图像、视频这样有画面的网页。
所以 HTTP 协议的核心是什么?
HTTP
的工作模式非常简单,因为其他层级已经负责了底层的具体传输工作,所以 HTTP
协议基本上不用在这方面操心太多。
单从这一点上来看,所谓的“超文本传输协议”其实并不怎么管“传输”的事情,有点“名不副实”。
那么 HTTP
协议的核心部分是什么呢?其实就是它传输的报文内容。如下图所示是报文传输格式。
而HTTP
协议常见的报文字段如下:
Content-Length
字段
在服务器返回数据时,表示本次回应的数据长度。
如下面告诉浏览器本次服务器回应的数据长度是 666 个字节。
Content-Length: 666
复制代码
Connection
字段
在开启 Keep-Alive
长连接机制后,表示连接不会中断连接。(当客户端发送另一个请求时,会使用同一个连接,一直到客户端或服务器端提出断开连接)
所以 HTTP
长连接机制只要一端没有确认断开连接,则保持连接状态。
Connection: Keep-Alive
复制代码
而客户端通过服务器就可以使用 HTTP
的 长连接机制,来实现请求的复用。
在 HTTP/1.1 版本的默认连接都是长连接,但为了兼容老版本的 HTTP, Connection字段值都是为 Keep-Alive。
Content-Type
字段
在服务器回应时,告诉客户端,数据是什么格式。
例如,下面我们常见的类型表示发送的是网页,编码格式为UTF-8
。
Content-Type: text/html; charset=utf-8
复制代码
Accept
字段
在客户端请求的时候,可以声明自己可以接受哪些数据格式。
例如,下面表示客户端声明可以接受任何格式的数据。
Accept: */*
复制代码
Accept-Encoding
字段
在客户端在请求时,表示可以接受哪些压缩格式。
例如,下面表示客户端声明可以接受gzip
的压缩格 式。
Accept-Encoding: gzip,
复制代码
当各类应用在使用了FTP、SMIT、HTTP
等等,不同的应用层协议来满足自己的应用后,在计算机网络的背后就又需要来进行统一。
传输层
所以应用层的数据包会传给传输层,而传输层负责为两端主机进程通信之间提供通用的数据传输服务。
这里的通用不针对某一个网络,而是各种不同应用可以使用同一个传输层服务。就像不管是电脑、手机还是其他更多联网设备,它们都是一致的网络协议来相互通信。
传输层有以下两种协议:
TCP(Transmisson Control Protocol)
传输控制协议,是可靠的数据传输协议,所以也是大部分应用会选择TCP
协议的原因,
UDP(User Datagram Protocol)
用户数据报协议,相对来说简单,简单到只负责发送数据包,来尽最大努力的数据传输服务(但不保证数据传输的可靠性),所以它实时性更好。
而 HTTP
应用层协议,在传输层就是通过 TCP
协议服务的,所以我们可以来看这个相当复杂传输层协议。
TCP
TCP
相比 UDP
多了很多特性,比如流量控制、超时重传、拥塞控制等,这些都是为了保证数据包能更可靠地传输给对方。
TCP 报文头部的格式
我们可以直接来看TCP
的协议,其实就是TCP
报文。
在TCP
报文头部的格式中主要有:
源端口号 和 目标端口号 ;这两个端口号 解决的是数据从哪发的,以及应该发给哪个应用。
序号,为了解决包乱序的问题。
确认号,如果发送方收到了确认,那么它就知道已经安全地到达了。相反,如果是否定意味着传输过程中产生了错误,就必须重传(为了解决丢包的问题) 。
状态位。TCP 是面向连接的协议,当双方需要维护连接的状态,就会带着状态位的包发送,使双方的状态变更。
URG
紧急数据。ACK
回复。PSH
推送。RST
重新连接。SYN
发起连接。FIN
关闭连接。
窗口大小,有两个方面的控制:
流量控制,指的是端到端的通信量控制,是发送端到接收端的问题,是控制发送端发送数据的速率,以便使接收端来得及接收。
而还有 拥塞控制,是防止过多的数据注入到网络中时,导致网络路由或链路过载。
TCP 报文头部的格式,如下图所示。
TCP 建立连接
我们知道TCP
需要通过三次握手来建立连接,三次握手目的是 确保双方都有发送和接收的能力。
一图胜千言。(过程如下图所示)
TCP 释放连接。
而TCP
释放连接则需要通过四次挥手。
过程如下图所示。
生成 TCP 报文
当建立了连接后,传输层会将TCP
报文+ HTTP
头部数据打包组装好后生成 TCP
报文,再传递给下面的网络层处理。
最后
此篇为下篇,也意味着《如果把网络原理倒过来看,从无到有,一切如此清晰》上中下三篇完结。
人生若只如初见。
在写完此篇已近年底,虽然告别了这三篇,但是这个专栏还未完结。在这里做个预告,可能即将迎来 TCP系列,因为TCP是离我们最近的协议,而且这家伙很复杂,所以我决定我们一起搞搞它。
我是一颗剽悍的种子,怕什么真理无穷,进一寸,有进一寸的欢喜。感谢各位伙伴的:关注、点赞、收藏和评论 ,我们下回见!
创作不易,勿白嫖。