目录
传输层和网络层是在Linu内核中实现的，Linux提供了一系列的系统调用接口，可以实现TCP/UDP通信。
一、再谈端口号
运行一个程序就是一个进程，一个进程有一个专属的进程id，而端口号标识了一个主机上进行通信的不同的应用程序，前面写的TCP/UDP通信程序中，当服务端启动之后，客户端需要通过ip:port的方式来找到服务端。port代表的就是服务器中的哪一个进程。
在TCP/IP协议中, 用 "源IP", "源端口号", "目的IP", "目的端口号", "协议号" 这样一个五元组来标识一个通信(可以通过netstat -n查看);
(一) 端口号范围划分
0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的
1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的.
(二) 认识知名端口号
有些服务器是非常常用的, 为了使用方便, 人们约定一些常用的服务器, 都是用以下这些固定的端口号
ssh服务器，使用22端口号
ftp服务器，使用21端口号
telnet服务器，使用23端口号
http服务器，使用80端口号
https服务器，使用443端口号
我们自己写程序要使用端口号的时候，要避开这些知名端口号。
查看知名端口号 cat /etc/services
(三) netstat
netstat可以查看网络状态的重要工具。
语法：netstat [选项]
功能：查看网络状态
常用选项：
n：拒绝显示别名，能显示数字的全部转化为数字
l：仅列出有在Listen(监听)的服务状态
p：显示建立相关链接的程序名
t：仅显示tcp相关选项
u：仅显示udp的相关选项
a：显示所有选项，默认不显示Listen相关(四) pidof
再查看服务器的进程id时非常方便。
语法：pidof [进程名]
功能：通过进程名，查看进程id
二、UDP协议
(一) UDP协议端格式
在使用UDP进行通信的时候，16位的源端口号和目的端口号谁填写？客户端在发送数据的时候会形成随机端口，目的端口号是在进行通信的时候用户自己写的。‘
现在我们要发送数据，当A向B使用UDP发送数据的时候，B怎么知道数据在传输的过程中没有丢失，接受到的是完整的数据呢？数据有没有可能出问题？
16位UDP长度，可以表示整个数据报(UDP首部 + UDP数据)的最大长度。最大长度减去8字节就是有效载荷的长度。
16位UDP检验和，用于检测数据传输过程中是否发生了错误。通过对UDP头部和有效载荷部分的所有16字的二进制求和，然后取反得到最终的检验和值。接收端在接受数据包时会重新计算检验和，并将计算结果与数据包中的检验和进行比较。如果不一样，就说明数据包可能已经损坏或被篡改，接收端可以选择丢弃该数据包。UDP本身不提供任何机制来纠正错误。
(二) UDP的特点
无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接
不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发送到对象，UDP协议层也不会给应用层返回任何错误信息
面向数据报：不够灵活的控制读写数据的次数和数量
(三) 面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并；
用UDP传输100个字节的数据；
如果发送端调用一次sendto，发送100个字节，那么接收端也必须调用对应的一次recvfrom，接受100个字节；而不能循环调用10次recvfrom，每次就收10个字节。
(四) UDP的缓冲区
UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作
UDP具有接受缓冲区，但是这个接受缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓冲区满了，再达到的UDP数据就会被丢弃。
UDP的socket既能读，也能写，这个概念叫做全双工。
(五) UDP使用注意事项
UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部).但是64K在当今的互联网环境下, 是一个非常小的数字.
当客户端向服务端发送了10个报文，分别是1……10，但是服务端接收到的报文一定是从1接收到……10吗？不一定，服务端接收到的报文也可能是乱序，UDP不保证可靠性，所以会直接把报文给丢弃。
(六) 基于UDP的应用层协议
NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议
当然, 也包括你自己写UDP程序时自定义的应用层协议
