。

TCP用于提供可靠的数据传输#xff0c;而UDP则适合用于广播…

文章目录

在TCP/IP协议中传输层有两个重要的协议TCP传输控制协议和UDP用户数据报协议。

TCP用于提供可靠的数据传输而UDP则适合用于广播或对细节控制要求不高的应用传输。

为了确保传输层协议能够正确地将接收到的数据交给相应的应用程序TCP和UDP都引入了端口号的概念用来识别目标应用。

一、引入端口号

可以用寄送包裹来类比这个过程。

邮递员对应网络层的IP协议根据收件地址目标IP地址将包裹数据包送到目标计算机。

包裹抵达后传输层协议会根据附带的端口号决定最终交给哪个应用程序。

我们举一个更具体的例子来说明假设快递单上只写了家庭住址和一个姓氏那么就无法准确判断包裹应该交给家庭中的哪位成员。

同样如果寄送到学校或公司只写了一个姓氏而没有明确部门或接收人的全名快递员也会遇到困难。

在实际生活中为了避免这些问题邮政系统也通常要求详细的地址和全名甚至在某些情况下还需要附上联系电话以便区分重名的收件人。

类似地在网络传输中端口号相当于应用程序的“全名”确保数据能够准确地交付给正确的应用。

因此我们就可以根据端口号识别在传输层上一层的应用层中所需要处理的具体程序一个程序可以使用多个端口。

数据链路和IP中的地址分别指的是MAC地址和IP地址。

前者用来识别同一链路中不同的计算机后者用来识别TCP/IP网络中互连的主机和路由器。

在传输层中也有这种类似于地址的概念那就是端口号。

端口号用来识别同一台计算机中进行通信的不同应用程序。

因此它也被称为程序地址。

TCP/IP的众多应用协议大多以客户端/服务端的形式运行。

客户端客户端Client具有客户的意思。

在计算机网络中是提供服务和使用服务的一方。

类似于客户的意思是请求的发起端。

而服务端服务端Server在计算机网络中则意味着提供服务的程序或计算机。

则表示提供服务的意思是请求的处理端。

另外作为服务端的程序有必要提前启动准备接收客户端的请求。

否则即使有客户端的请求发过来也无法做到相应的处理。

确认一个请求究竟发给的是哪个服务端可以通过所收到数据包的目标端口号轻松识别。

当收到TCP的建立连接请求时如果目标端口为22则转给sshd如果是80则转给httpd。

然后这些守护进程会继续对该连接上的通信传输进行处理。

上图是把传输协议的数据将被传递给HTTP应用层协议。

传输层协议通过端口号来识别这些正在通信的应用程序并确保数据准确地传递给相应的程序。

每个运行的程序都会被分配一个唯一的端口号TCP和UDP协议通过这些端口号来区分不同的应用。

例如Web浏览器使用HTTP服务时通常使用端口80而SSH客户端通常使用端口22。

传输层协议根据目标端口号确保数据包能准确地到达运行该端口的应用程序使得同一台计算机能够同时进行多种网络通信而不会发生混淆。

上图中的通信是在①和②的通信是在两台计算机上进行的。

它们的目标端口号相同都是80。

例如打开两个Web浏览器同时访问两个服务器上不同的页面就会在这个浏览器跟服务器之间产生类似前面的两个通信。

在这种情况下也必须严格区分这两个通信。

因此可以根据源端口号加以区分。

而中③跟①的目标端口号和源端口号完全相同但是它们各自的源IP地址不同。

此外还有一种情况上图中并未列出那就是IP地址和端口全都一样只是协议号表示上层是TCP或UDP的一种编号不同。

这种情况下也会认为是两个不同的通信。

因此TCP/IP或UDP/IP通信中可以采用一个五元组来识别一个通信。

它通常包括以下信息

源IP地址:

只要其中某一项不同就被认为是其他通信。

即这些信息共同定义了网络中的一个会话或连接。

通过

netstat

在实际进行网络通信时要事先确定端口号。

确定端口号的方法分为两种

Ports

这些端口号通常是由特定的网络服务或协议所使用的并且已被标准化。

它们的范围为0到1023例如

HTTP

这些端口号是预先定义好的客户端在与服务器通信时通常不需要明确指定端口号因为大家对这些标准端口已广泛了解。

Ports

这些端口号由应用程序或操作系统动态分配通常用于客户端与服务器之间的临时通信。

它们的范围为1024到65535**。

服务端有必要确定监听端口号但是接受服务的客户端没必要确定端口号。

**例如当一个客户端启动连接时操作系统可能会随机为它分配一个未使用的端口号这样可以避免与其他应用程序产生冲突。

这些端口号通常用于短期通信在通信完成后可以重新分配。

在这种方法下客户端应用程序可以完全不用自己设置端口号而全权交给操作系统进行分配。

操作系统可以为每个应用程序分配互不冲突的端口号。

例如每需要一个新的端口号时就在之前分配号码的基础上加1。

这样操作系统就可以动态地管理端口号了。

根据这种动态分配端口号的机制即使是同一个客户端程序发起的多个TCP连接识别这些通信连接的五元组也不会全部相同。

端口号由其使用的传输层协议决定。

因此不同的传输协议可以使用相同的端口号。

例如TCP与UDP使用同一个端口号但使用目的各不相同。

这是因为端口号上的处理是根据每个传输协议的不同而进行的。

当数据从传输层进入IP层时首先会检查IP首部中的协议号再根据该协议号将数据传递给相应的协议模块。

例如如果协议号指示为TCP数据将被传递给TCP模块进行处理如果协议号指示为UDP则数据会交给UDP模块进行处理。

因此即使相同的端口号被TCP和UDP同时使用数据处理仍然是各自独立的不会产生冲突或干扰。

数据到达网络接口

当数据报到达服务器的网络接口时网络接口卡NIC会通过硬件中断通知CPU。

数据报被内核处理

接收数据报操作系统内核的网络栈会接收数据报并从链路层开始逐层处理直到传输层。

解析数据报在传输层内核会解析数据报的头部信息包括源端口号、目的端口号、协议类型等。

根据端口号找到对应的进程以下是操作系统如何根据端口号将数据发送给正确的客户端进程

查找端口号内核会根据数据报的目的端口号在内部维护的一个查找表哈希表中查找。

这个查找表通常称为socket

table或port

table它记录了当前系统中所有正在监听的端口号以及它们对应的套接字描述符。

套接字描述符每个套接字都有一个唯一的描述符它是由内核在创建套接字时分配的。

这个描述符用于内核与进程之间的交互。

绑定关系当一个进程通过bind系统调用绑定一个端口号时内核会在这个查找表中为该端口号创建一个条目并将该端口号与进程的套接字描述符关联起来。

数据传递当内核找到了对应端口号的套接字描述符后它会将数据报的内容复制到该套接字的接收缓冲区中。

唤醒进程如果客户端进程正在等待接收数据例如调用了recv、recvfrom或类似的系统调用内核会将数据放入进程的缓冲区并唤醒该进程。

设置文件描述符为可读如果客户端进程没有阻塞在接收调用上内核会将对应的文件描述符标记为“可读”这样当进程下次进行轮询例如使用select、poll或epoll或阻塞在读取操作上时可以读取到数据。

客户端进程读取数据

客户端进程通过系统调用如read、recv、recvfrom等从其套接字的接收缓冲区中读取数据。

这个过程确保了数据能够根据端口号准确地发送到正确的进程。

值得注意的是这一机制适用于TCP和UDP协议尽管UDP是无连接的但数据报的发送和接收依然依赖于端口号来正确地路由到相应的进程。