传输层
负责数据能够从发送端传输接收端
端口号
端口号标识了一个主机上进行通信的不同的应用程序
在TCP/IP协议中，用“源IP”，“源端口号”，“目标IP”，“目标端口号”，“协议号”这样一个五元组来表示一个通信
（可以通过netstat -n查看）
cat /etc/services查看知名端口号，我们在写一个程序使用端口号时，要避开这些知名端口号
一个进程可以绑定多个端口号，但是一个端口号不能被多个进程绑定
netstat
netstat是一个用来查看网络状态的重要工具
* -n拒绝显示别名，能显示数字的全部转化成数字
* -l仅列出有Listen（监听）的服务状态
* -p显示简历相关连接的程序名
* -t仅显示TCP相关选项
* -u仅显示UDP相关选项
* -a显示所有选项，默认不显示LISTEN相关
pidof
pidof+进程名
通过进程名，查看进程id
UDP协议
协议端格式
*十六位UDP长度，表示整个数据报（UDP首部+UDP数据）的最大长度
*如果检验和出错，就会直接丢弃
UDP的特点
UDP传输的过程类似于寄信
*无连接：知道对短的IP和端口号就可以直接传输，不需要建立连接；
*不可靠：没有确认机制，没有重传机制；如果因为网络故障该段无法发送给对方，UDP协议层也不会给应用层返回任何错误信息；
*面向数据报：不能够灵活的控制读写数据的次数和数量
面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分也不会合并；
UDP的缓冲区
*UDP没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；
*UDP具有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报文的顺序和发送UDP报文的顺序是一致的，如果缓冲区满了，再次到达的UDP数据就会被丢弃
UDP的socket既能读，也能写，这个概念叫做全双工
UDP使用注意事项
我们知道UDP协议首部中有一个十六位最大长度，也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部），但是64K在当今的互联网环境下，是一个非常小的数字。
所以就出现了问题。如果我们需要传输的数据超过64K，就要在应用层手动的分包，多次发送，并在接收端手动拼装
基于UDP的应用层协议
*NFS：网络文件系统
*TFTP：简单文件传输协议
*DHCP：动态主机配置协议
*BOOTP：启动协议（用于无盘设备启动）
*DNS：域名解析协议
TCP协议
TCP全称为传输控制协议
*源/目的端口号：表示数据从哪个进程来，到那个进程去；
*三十二位序号/三十二位确认序号：序列号是进程发送的号码，确认序号是期望返回的号码。举个例子，比如发送序列号为10000，发送五个数据，那么如果确认序号是10006，就说明数据发送成功，如果不是，就说明了中间有数据没有发送成功，保证了TCP的可靠性。
*四位TCP包头长度：表示TCP头部有多少个32位bit（有多少个四字节）；所以TCP头部最大长度是15*4 = 60
*六位标志位：URG：紧急指针是否有效
ACK：确认号是否有效
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
RST：对方要求重新建立连接；我们把写到RST表示的称为复位报文段
SYN：请求建立连接；我们把携带SYN标识的称为同步报文段；
FIN：通知对方，本段要关闭了，我们称携带FIN标识的为结束报文段
*十六位窗口大小：标志着TCP缓冲区还剩余多少，起到一个流量控制的作用
*十六位校验和：发送端填充，CRC校验，接收端校验不通过，则认为数据有问题，此处的检验和不光包含TCP首部，也包含TCP数据部分
*十六位紧急指针：标识哪部分数据是紧急数据；