网络通信另个角度的认识(进程间通信),端口号(为什么要有,和pid的关系,如何封装,和进程的定位原理+对应关系)客户端如何拿到服务端的port

另一个角度认识网络通信

端口号

引入 -- 为什么要有端口号

问题

解决

端口号和pid

举例

介绍

分类

知名端口

注册端口

动态端口

客户端如何知道服务端的端口号

封装端口号

定位原理

进程和端口号的对应关系

数据如何被上层进程读到

另一个角度认识网络通信

前面我们总是说,主机a和主机b之间进行通信,但网络通信实际上真的是两台主机设备在进行通信吗?

不是的,设备之间的通信,是我们进行网络通信的基本保证
而进行通信是需要用户使用应用层软件,来进行数据的发送和接收
而软件启动起来,也就是创建了进程
所以,网络通信的本质是通过网络协议栈,借助主机的通信能力,使运行在两台主机上的两个进程能够进行数据的发送和接收
相当于在两台设备上创建了两个进程,通过网络进行进程间通信
所以,我们日常的网络间通信也可以叫进程间通信

进程间通信我们熟悉啊,有很多种方式可以实现(管道,共享内存等)

而其本质就是让通信双方看见同一份资源,这份资源作为中间介质
而网络通信的公共资源就是网络(一个向网络里写,一个从网络里读),提供的方法也就是网络协议栈

端口号

引入 -- 为什么要有端口号

问题

我们可以使用各种应用层软件,来向其他下载了该软件的人发送消息

如果对方也运行了该软件,数据就可以通过两次贯穿协议栈,将数据从服务器运输过去,对方就会显示收到了消息

假设a和b通信不需要经过服务器:

当a发给b的数据运输到b设备的传输层后,传输层肯定是要发送给微信进程的

不然发给其他软件也无法解析出有效载荷/数据被直接丢弃

但是运行的应用那么多,数据经过的都是同一个网络协议栈,它如何知道发送上层的哪一个应用呢?

解决

这种一对多的关系就必须要有可以定位的字段,也就是端口号
我们为需要网络服务的进程分配唯一的端口号(比如我们眼熟的8080,3306等等)

端口号和pid

两者都用来标识本地主机上唯一的进程,那为什么要再来一个端口号呢?

从技术角度来说,使用pid作为网络中标识进程的字段,是完全可以的

但为什么没有这样设计呢?

如果这样设计,进程管理和网络管理就会耦合,那么一旦系统修改,网络也会跟着受影响
所以就为网络功能单独设计了一个字段

举例

就像,明明身份证已经可以唯一表示我们的个人身份了,进入学校依然会有学号,进入公司会有工号

就是为了防止如果身份证取消使用了,改成了其他方式标识每个人,那么学校/公司的管理系统就得跟着改
所以,不如就直接自己规定一个字段

介绍

端口号是一个2字节16位的整数

范围是[0,65535=2^16]

分类

端口号会大致分为三类:

知名端口

[0,1023]被保留给一些广泛使用的协议和服务

例如http(端口80),https(端口443),ftp(端口21),ssh(端口22)等
需要使用root权限才可以使用这个范围内的端口

注册端口

[1024,49151]用于用户注册的应用程序，也就是说，由一些软件开发者和组织注册使用

例如,mysql(端口3306)

动态端口

为客户端应用程序动态分配的，通常用于临时性的连接
大多数操作系统动态选择一个空闲的端口分配给客户端应用程序，以便进行通信

客户端如何知道服务端的端口号

每次的网络行为,都是我们用户主动向服务端发起的

比如:打开某网页,播放某视频等等

那这样看的话,我们其实是无法得知服务端的端口号的,又是如何完成通信的呢?

即使你说可能是服务端提前告诉我们的,那服务端又是如何得知我们客户端的端口号呢?

所以就只能是 -- 每一个服务的端口号都是约定好的,被客户端知晓的
比如:mysql的默认端口号是3306
所以,是在app开发时,就将服务端的端口号内置进去了

封装端口号

有了端口号,就可以在 [a使用设备的传输层的报头] 里存放目标端口号(因为问题就出在传输层)

当报文传到b设备的传输层时,就可以解析出端口号,然后将有效载荷交给端口号匹配的进程

同理,也需要存放源端口号

当b回复消息时,需要这个源端口号来定位
在b设备的传输层将源/目的端口号反过来存,就可以准确将有效载荷交给a设备中对应的进程

定位原理

定位的原理类似于哈希表

传输层里会有一张表,里面存放着task_struct*指针,指向进程tcb
当进程分配到一个端口号后,就经过哈希运算,映射到表中某一位置
如果已经被占用,就需要重新分配 ; 如果未占用,就将该进程的指针放入该位置中

当有数据发送过来的时候,就可以直接将解析出的目的端口号进行哈希运算 -> 拿到映射的位置,也就找到了指定的那个进程