第二节我们的网络

最新推荐文章于 2026-06-14 01:38:24 发布

转载最新推荐文章于 2026-06-14 01:38:24 发布 · 592 阅读

标签

#网络 #http服务器 #tcp #互联网 #工作

关于一些问题的讨论专栏收录该内容

7 篇文章

订阅专栏

1. 网络模型
不知道诸位在浏览网页的时候有没有想过, 通过网线传来的这些信号是如何被转换成这些漂亮的东西的?
请看下面的图:

图1: OSI 7 层模型

图中的 7 层模型就是 OSI 模型. 也是网络的基础之一. 位于最下面的 Transmission Medium 就是传输介质, 对于我们来说最常见的可能就是网线. 而用户所处的位置就在第 7 层的上面.
网线中的数据通过每层之后都会被处理. 就像工厂里的流水线一样 --- 原材料通过介质被传入后, 一级一级的被加工, 最后以成品形式交付用户.
而用户发送数据的情况类似 --- 只不过方向相反而已: 在进行一级一级的加工之后, 数据进入传输介质并被传输至目的地.

但是, OSI 只是模型, 并不是一个实例. 就像上级要求某单位要落实安全, 安全的内容是防火防盗. 这个 "安全" "防火防盗" 只是一个模型, 或者说思路, 而不是一个具体的解决办法.
所以单位负责人便下令 "安装防盗网" "加装灭火器" --- 这个问题便得到了解决. 换句话说, "安全" 的模型通过 "安装防盗网和灭火器" 得到实现.

那么 OSI 模型是如何实现的?
继续上图:

图2: TCP/IP 模型 (互联网 5 层模型)

大家可以看到原本的 7 层模型在这里变成了 5 层. 很多书把这个 5 层模型命名为互联网模型. 其实这个是 TCP/IP 协议套件模型.
我们可以把这个看成是对 OSI 模型的一个 "实现".

TCP/IP 模型分为 5 层, 从下至上计算, 分别为:
第一层: 物理层
第二层: 数据链路层
第三层: 网络层
第四层: 传输层
第五层: 应用层

其中, 每层均有其自己的地址标识, 以保证其机制正确运行
比如大家熟悉的 MAC 地址就是第二层的地址
IP 地址就是网络层地址
端口号就是第四层地址.
进程标识符可以看做第五层地址.
模型的每层也都有工作在该层的一些协议. 比如 ARP 协议工作在数据链路层, TCP 协议工作在传输层.

例:
局域网 IP 为 192.168.0.2 的计算机需要连接 192.168.0.7 的 21 端口下载文件.
首先其会查询目标主机的 MAC 地址 (第二层地址). 然后获取其 IP 地址 (第三层地址).
然后连接其 TCP 21 端口 (第四层地址).
目标计算机会查询该机绑定 21 端口的的程序是那个程序 (第五层地址)
如此完成传输

2. 模型中用户数据的传递
数据在 5 层模型中传输的时候, 每经过一层, 相应的驱动程序 (具体请见后章) 就会将其打包.
当然这个 "打包" 也是一个模型, 具体的实现就是加入一些供识别验证等作用的附加信息.
请大家注意本节图 2 的右侧. 可以看到在应用层的时候, 用户数据还是类似原材料一样的摆在那 (绿色块), 在向下传输 (出站) 的过程中逐渐被加入了每层的信息 (这些信息包括每层的地址等), 最后进入网络介质的信息其实是用户信息加上一些附加信息. 也就是这些附加信息确保了我们的东西可以被正确的发送至正确的地方.
反之, 当数据被传输至本机 (入站) 的时候, 在流入上层之前也会被层层拆解. 如果拆解的时候出现问题, 那么这些有问题的数据就会被丢掉. 这个过程由相应的程序完成, 并不需要用户参与 (而且你也感觉不到这个操作在运行)

3. 理解网络端口
在应用于计算机网络的 TCP 和 UDP 协议中, 端口是出现在数据包头部 (图2 中粉色的部分) 的特定号码. 端口的主要作用是: 将数据分配到计算机上运行的特定进程.
让我们来打个形象的比喻: 假设 IP 地址是一栋大楼的地址, 那么端口号就代表着这栋大楼的不同房间. 如果一封信 (数据包) 上的地址仅包含了这栋大楼的地址 (IP) 而没有具体的房间号 (端口号码), 那么没有人知道谁 (计算机服务) 应该去接受它. 为了让邮递成功, 发信人不仅需要写明大楼的地址, 还需要标注具体的收信人门牌号, 这样这封信才能被顺利的交到它应该前往的住所.
这里是一个具体的例子: 一台用来收发电子邮件服务器可能同时提供 SMTP 和 POP3 服务. 这些服务将被不同的服务端进程所处理, 而端口号码则被用来决定数据应该被关联到哪个进程上. 根据计算机惯例, SMTP 服务端将监听 25 端口, POP3 服务则监听 110 端口. 尽管在理论上使用其它端口也是可行的.
从图2 中可以看出, 不是所有的网络传输层都使用网络端口; 例如, 尽管 UDP 和 TCP 使用端口, ICMP 则不使用.
端口号也许会经常在网站的地址中被看到. 在默认情况下, HTTP 使用 80 端口, HTTPS 则使用 443 端口, 不过像这样的 URL "www.example.com:8000/blah/" 将尝试连接到一个使用 8000 来代替 80 端口进行工作的 HTTP 服务器.

在 TCP (传输控制协议) 和 UDP (用户数据报协议) 中, 每个数据包头部将指定一个源端口 (source port) 和目标端口 (destination port), 它们均为一个 16 位无符号整数 (从 0 至 65535). 指定源地址和目标地址 (IP 号码) 的道理与其类似. 某个进程可能会 "绑定" 一个特定的端口 (也就是接下来两句话中的 "该端口") 来收发数据, 也就是说它会监听目的端口符合该端口号码的入站数据包, 同时还可能会发送源端口设置为该端口的出站数据包. 一个进程也可能同时绑定多个端口.

本节扩展阅读:
(1) TCP/IP 协议取代了旧的网络核心协议 (NCP, Network Core Protocol), 从而成为今天的互联网的基石. 最早的 TCP/IP 由文顿·瑟夫和罗伯特·卡恩两位开发, 慢慢地通过竞争战胜了其他一些网络协议的方案, 比如国际标准化组织 ISO 的 OSI 模型. TCP/IP 的蓬勃发展发生在上世纪的 90 年代中期. 当时一些重要而可靠的工具的出世, 例如页面描述语言 HTML 和浏览器 Mosaic, 导致了互联网应用的飞速发展.
随着互联网的发展, 目前流行的 IPv4 协议已经接近它的功能上限.

(2) 应用程序对于一般服务的实现通常是通过监听 (被行业惯例定义以及与被给定的协议协同使用的) 指定端口来实现的. 一般来说这些端口号都偏低. 在 Unix 中只有被 superuser (超级用户) 所享有的进程才有权力监听 0 至 1023 端口. 这确保了不被信任的程序无法被充当为系统服务进行工作. 相反的, 客户端连接通常使用范围更大的高端口.
端口号码构成了数据包头部的一部分, 因此不仅是收发机器, 其它的网络底层设备也能够轻易的读取它. 特别是防火墙 (无论是基于硬件或软件) 经常根据数据包的源端口号码和目标端口号码来区分对待它们. 端口映射也是这类应用中的一种.

(3) 进程通过套接字实现对 TCP 和 UDP 端口的连接. 套接字是一个传输终端, 进程可以在此被创建并绑定一个套接字地址. 在 TCP 或 UDP 中, 一个套接字地址由一系列的端口和一个 IP 地址组成. 套接字既可以被设定为在一个时间内仅接收或发送数据 (这也称为半双工), 或同时收发数据 (这也称为全双工). 除了 TCP 和 UDP 端口外, 套接字也可以成为单一计算机系统上, 连接网络端口和内部程序的桥梁.