计算机网络学习笔记

 

最近整理了之前学习计算机网络的笔记,这里简单总结一篇博客,备忘。

一、OSI 模型及 TCP/IP 模型

OSI 七层及 TCP / IP 五层协议

计算机网络中常见的有 OSI 七层模型及 TCP / IP 五层模型。前段时间听同事讨论,公司里不同服务的交互是用什么协议,使用七层还是五层模型?这才意识到自己原先光记着这些东西,没有仔细思考过两者的区别。典型的学生思维。

简单说我的理解,不同层需要封装不同的头部信息,来处理该层负责的事情(第二部分再说对分层的理解),见下图 OSI 七层数据模型图。例如在传输层,数据会在上层基础里封装 TCP / UDP 头,再向下传递到网络层,再进一步封装 IP 包头。

所以当层次越少,这种封装,解封还原的处理也越少,传输耗时,复杂度相应减少。因此追求更快的交互时,往往会直接用传输层 TCP / UDP 协议,而不是用应用层 HTTP 协议。

OSI 七层数据模型图

二、OSI 为什么分层

这一段是之前看《图解 TCP/IP》时的一点心得,由于种种原因,书还没看完,比较可惜。

OSI(Open System Interconnection,开发系统互联) 分为 7 层,但是为什么会分层?

之前对这个问题没有深入思考过,只知道教材这样写,老师这样教。直到现在读起了《图解 TCP/IP》,突然对分层的思想有了一些自己的理解。

以书中 1.5.2 节的例子说明。

A 和 B 正在通过电话聊天,而他们说的是普通话。

这个例子中,虽然 A 和 B 感觉上是在实时通话,但实际情况是进行了一系列的处理,简单来说便是这样:电话接收 A 的音频输入,转换成特定的电信号,通过物理链路传递到 B 的电话,再转换成对应的音频输出。

再来想想另一个列子:

A 和 B 还是在用普通话聊天,不过这次使用的是对讲机。

没错,这第二个例子中,A 的声音传递到 B 中所做的处理其实与第一个例子大致相应,但这次由电话变成了对讲机,因此,声音的具体转换方法是不一样的。最后看第三个例子:

A 和美国朋友 C 电话聊天,因为 C 不懂普通话,因此他们只能用英语来沟通。

对比第一个和第三个例子,我们知道,虽然电话接收到的是不同语言的输入,可在电话层面来说是毫无区别的,电话只能理解到输入的是音频,然后对音频做特定处理,而并不关心具体哪种语言。

所以我们在这里可以简单的抽象出两个层次来:语言层,通信设备层。这样一分层,我们可以发现:

语言层的替换,对通信设备层没有影响 同样通信设备层的替换,对语言层也没有影响

因此可以说分层做到了可扩展性、灵活性、以及模块化

回到 OSI 7 层模型,同理,每一层其实都是通信过程中负责具体某一个功能的抽象,以此来最大程度的实现通信系统的灵活以及可扩展。

三、HTTP 及 TCP/IP 介绍

HTTP 介绍

HTTP 是一个无状态的应用层协议。无状态是指客户端和服务器之间不需要建立持久的连接,意味着当一个客户端向服务器端发出请求,然后服务器返回响应(response),连接就被关闭了,在服务器端不保留连接的有关信息

HTTP 传输过程

了解 HTTP 的传输过程,可以比较粗略的回答,在浏览器地址栏输入一个 URL,点击确定到页面显示内容的过程,下面便来简单总结一下。

  1. 地址解析

    例如从地址栏输入这样的 URL:https://jluncc.github.io/ ,这里浏览器会解析 URL

    • 协议名:https

    • 主机名:jluncc.github.io

    • 端口:80(当前 URL 隐藏了端口号,这里写一个默认的)

    • 对象路径:/(单一 / 也可表示请求主页的信息)

    此外,主机名需要进一步的解析成 IP 地址,因此该主机名是人读的,计算机并不能理解,计算机能识别的是 IP 域名。在这一步,需要域名系统 DNS 解析域名 jluncc.github.io,得主机的 IP 地址。

  2. 封装 HTTP 请求数据包

    把以上部分结合本机自己的信息,封装成一个 HTTP 请求数据包,然后向下层(OSI 七层模型,见上图)传输。

  3. 封装成 TCP 包并建立连接

    封装成 TCP 包,建立 TCP 连接(建立连接的过程就是 TCP 的三次握手,见下面总结)。

  4. 客户机发送请求命令

    建立连接后,最终数据会流转到最底层,通过物理链路(如光纤)发送一个请求给服务器。

  5. 服务器响应

    服务器接到请求后,按照请求的数据进行相应的处理,例如当前例子,会去获取主页的资源,组装相应数据返回,给予相应的响应信息。

  6. 服务器关闭 TCP 连接

    一般情况下,一旦 Web 服务器向浏览器发送了请求数据,它就要关闭 TCP 连接,然后如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive,TCP 连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽

TCP / IP 介绍

TCP 是面向连接的传输层协议,它提供可靠的报文传输和对上层应用的连接服务。为此,除了基本的数据传输外,它还有可靠性保证、流量控制、多路复用、优先权和安全性控制等功能。

UDP 同样是传输层协议,与 TCP / IP 不同的是,UDP 是面向无连接的不可靠传输的协议,主要用于不需要 TCP 的排序和流量控制等功能的应用程序。

三次握手与四次挥手

TCP 建立连接要进行三次握手,而断开连接要进行四次。先来看看三次握手的图示(图片来源:TCP 协议):

TCP 三次握手

为何要进行三次,而不是两次?简单说说我的理解(这篇文章讲解三次握手很生动:TCP/IP 之 大明王朝邮差)。

第一次握手,是客户端发送信息,服务端收到信息。这时,服务端知道,自己收信及客户端发信的能力都是正常的。可客户端还处于不知道这些情况的状态。

第二次握手,是服务端发送确认信息,客户端接收到服务端的确认信息。这时,客户端便知道自己的发信、收信能力都是正常的,同时服务端的发信收信能力也是正常的。但此时服务端并不知道自己的确认信息有没有发成功,并不知道自己的发信能力是否正常,因此才需要第三次握手。

第三次握手,客户端发送接收到服务端信息的确认信息,当服务端接收到该确认信息,才确定自己的发信能力也是正常的,终于,客户端与服务端都明白自己发收信息的能力没有问题,可以保证信息的正常传递。

对断开连接的四次挥手,也是可以类似思考,头两次的挥手,客户端确认了服务端不再接受自己的信息,服务端会断开,但是服务端除了处理当前这个客户端,还可能同时处理其他多个客户端(全双工),因此服务端也需要确认客户端与自己断开连接,后两次的作用便是如此,服务端确认了客户端不会再接收自己的信息,客户端会断开。

至此两方都确认了对方不会再传输数据,连接终止。图示如下:

TCP 四次挥手

参考文章

TCP 协议
TCP/IP 之 大明王朝邮差

END