目录
一、传输层
在进行网络传输时，应用层需先将数据交给传输层，由传输层对数据做进一步处理后再将数据继续向下进行交付，该过程贯穿整个网络协议栈，最终才能将数据发送到网络中
1.1 端口号
端口号（Port）标识一个主机上进行网络通信的不同的应用程序。当主机从网络中获取到数据后，需要自底向上进行数据的交付，而这个数据最终应该交给上层的哪个应用程序，就由该数据中的目的端口号来决定的。从网络中获取的数据进行向上交付时，在传输层就会提取出该数据对应的目的端口号，进而确定该数据应该交付给当前主机上的哪一个进程
端口号是属于传输层的概念的，在传输层协议的报头中包含与端口相关的字段
五元组标识一个通信
在TCP/IP协议中，用"源IP地址"，"源端口号"，"目的IP地址"，"目的端口号"，"协议号"一个五元组来标识一个通信。
如有多台客户端主机同时访问服务器，这些客户端主机上可能有一个客户端进程，也可能有多个客户端进程，都在访问同一台服务器
服务器通过"源IP地址"，"源端口号"，"目的IP地址"，"目的端口号"，"协议号"来识别一个通信:
- 先提取出数据中的目的IP地址和目的端口号，确定该数据是发送给当前服务进程的
- 然后提取出数据当中的协议号，为该数据提供对应类型的服务
- 最后提取出数据中的源IP地址和源端口号，将其作为响应数据的目的IP地址和目的端口号，将响应结果发送给对应的客户端进程。
协议号 && 端口号
- 协议号是存在于IP报头中的，其长度是8bit位。协议号指明了数据报所携带的数据是使用的何种协议，以便让目的主机的IP层知道应该将该数据交付给传输层的哪个协议进行处理
- 端口号是存在于UDP和TCP报头中的，其长度是16bit位。端口号的作用是唯一标识一台主机上的某个进程
- 协议号是作用于传输层和网络层之间的，而端口号是作用于应用层于传输层之间的
端口号的范围划分
端口号的长度是16位，因此端口号的范围是0 ~ 65535：
- 0 ~ 1023：知名端口号。如HTTP、FTP、SSH等应用层协议，其端口号都是固定的
- 1024 ~ 65535：操作系统动态分配的端口号。客户端程序的端口号就是操作系统从这个范围分配的，也可供程序员自行绑定
知名端口号
- ssh服务器：使用22端口
- ftp服务器：使用21端口
- telnet服务器：使用23端口
- http服务器：使用80端口
- https服务器：使用443端口
查看/etc/services文件，该文件是记录网络服务名和对应使用的端口号及协议
注意：文件中的每一行对应一种服务，由4个字段组成，分别表示"服务名称"、"使用端口"、"使用协议"、"别名"
1.2 关于端口的常见问题
一个端口号是否可以被多个进程绑定？
不可以，因为端口号的作用就是唯一标识一台主机上的某个进程，若绑定一个已经被绑定的端口号，就会出现绑定失败的问题
一个进程是否可以绑定多个端口号？
可以。这与"端口号唯一标识一个进程"并不冲突，只不过多个端口唯一标识的是同一个进程罢了。因此一个进程是可以绑定多个端口号的，可以通过多个端口号找到该进程
1.3 netstat && pidof
netstat命令
netstat是一个用来查看网络状态的重要工具
- n：拒绝显示别名，能显示数字的全部转换成数字
- l：仅列出处于LISTEN（监听）状态的服务
- p：显示建立相关链接的程序名
- t(tcp)：仅显示tcp相关的选项
- u(udp)：仅显示udp相关的选项
- a(all)：显示所有的选项，默认不显示LISTEN相关
查看TCP相关的网络信息时，一般使用 nltp 组合选项
查看UDP相关的网络信息时，一般使用 nlup 组合选项
若想查看LISTEN状态以外的连接信息，可以删去 l 选项
pidof命令
以往查看进程id都是使用ps命令、grep命令与匿名管道配合来进行查询。使用pidof命令可以通过进程名查看进程id，更加便捷
pidof命令可以配合kill命令快速杀死一个进程
二、UDP协议
2.1 UDP协议格式
UDP协议位置
网络套接字编程时用到的各种接口，是位于应用层和传输层之间的一层系统调用接口，这些接口由系统提供的，可以通过这些接口搭建上层应用协议，如HTTP。HTTP是基于TCP的，实际就是因为HTTP在TCP套接字编程上搭建的
而socket接口往下的传输层实际就是由操作系统管理的，因此UDP是属于内核当中的，是操作系统本身协议栈自带的，其代码不是由上层用户编写的，UDP的所有功能都是由操作系统完成，可以认为网络也是操作系统的一部分
UDP协议格式
- 16位源端口号：表示数据从哪里来
- 16位目的端口号：表示数据要到哪里去
- 16位UDP长度：用来表示整个数据报（UDP首部+UDP数据）的长度
- 16位UDP检验和：若UDP报文的检验和出错，则直接将报文丢弃
之前socketUDP编程时，端口号的类型使用的都是uint16_t，其根本原因就是因为传输层协议中的端口号就是16位的
注意：UDP协议报头中的UDP最大长度是16位的，因此一个UDP报文的最大长度是64K（包含UDP报头的大小）。然而64K在如今的互联网环境下，是一个非常小的数字。若需要传输的数据超过64K，就需要在应用层进行手动分包，多次发送，并在接收端进行手动拼装
UDP如何将报头与有效载荷进行分离？
UDP采用的是一种定长报头，报头中只包含四个字段，每个字段的长度都是16位，总共8字节。因此，UDP在读取报文时读取完前8个字节后剩下的就都是有效载荷了
UDP如何决定将有效载荷交付给上层？
UDP上层也有很多应用层协议，UDP必须将有效载荷交给对应的上层协议，即交给应用层对应的进程。应用层的每一个网络进程都会绑定一个端口号，服务端进程必须显示绑定一个端口号，客户端进程通常由系统动态绑定一个端口号。UDP通过报头中的目的端口号来找到对应的应用层进程的
注意： 内核中用哈希的方式维护了端口号与进程ID之间的映射关系，因此传输层可以通过端口号得到对应的进程ID，进而找到对应的应用层进程
如何理解报头？
Linux操作系统由C语言写的，UDP协议属于内核协议栈的一部分，因此UDP协议也一定是用C语言编写的，UDP报头实际就是一个位段结构
UDP数据封装：
- 当应用层将数据交给传输层后，在传输层会创建一个UDP报头类型的变量，然后填充报头中的各个字段，此时就得到了一个UDP报头
- 此时操作系统再在内核中开辟一块空间，将UDP报头和有效载荷拷贝到一起，此时就形成了UDP报文
UDP数据分用：
- 当传输层从下层获取到一个报文后，就会读取该报文的前8个字节，提取出对应的目的端口号
- 通过目的端口号找到对应的上层应用层进程，然后将剩下的有效载荷向上交付给该应用层进程
2.2 UDP协议特点
- 无连接：知道对端的IP和端口号就直接进行数据传输，无需建立连接
- 不可靠：没有确认机制，没有重传机制；若因为网络故障该段数据无法发到对方，UDP协议层也不会给应用层返回任何错误信息
- 面向数据报：不能够灵活的控制读写数据的次数和数量
注意： 报文在网络中进行路由转发时，并不是每一个报文选择的路由路径都是相同的，因此报文发送的顺序和接收的顺序可能是不同的
面向数据报
应用层交给UDP多长的报文，UDP就原样发送，不会拆分，也不会合并
比如用UDP传输100个字节的数据：若发送端调用一次sendto()，发送100字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节；而不能循环调用10次recvfrom，每次接收10个字节
2.3 UDP缓冲区
- UDP没有真正意义上的发送缓冲区。调用sendto会直接将报文交给内核，由内核将数据传给网络层协议进行后续的传输动作
- UDP具有接收缓冲区。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；若缓冲区满了，再到达的UDP数据就会被丢弃
- UDP的socket既能读，也能写，拥有两条信道，因此UDP是全双工的
为什么UDP要有接收缓冲区？
若UDP没有接收缓冲区，那么就要求上层及时将UDP获取到的报文读取，若一个在UDP处的报文没有被读取，那么此时UDP从底层获取上来的报文数据就会被迫丢弃
一个报文从一台主机传输到另一台主机，在传输过程中会消耗主机资源和网络资源。若UDP收到一个报文后仅仅因为上次收到的报文没有被上层读取，而被迫丢弃一个可能并没有错误的报文，这就造成了浪费主机资源和网络资源以及丢包
因此UDP本身是会维护一个接收缓冲区的，当有新的UDP报文到来时就会把这个报文放到接收缓冲区中，此时上层在读数据的时就直接从这个接收缓冲区中进行读取即可，而若UDP接收缓冲区中没有数据那上层在读取时就会阻塞。因此UDP的接收缓冲区的作用就是，将接收到的报文暂时的保存起来，供上层读取
2.4 基于UDP的应用层协议
- NFS：网络文件系统
- TFTP：简单文件传输协议
- DHCP：动态主机配置协议
- BOOTP：启动协议（用于无盘设备启动）
- DNS：域名解析协议
- 编程UDP程序时自定义的应用层协议