传输层---深入理解UDP/TCP协议
传输层:负责数据能够从发送端传输到接收端
我们先来看一下端口号:
1> 端口号(port)标识了一个主机上进行通信的不同应用程序.
在TCP/IP当中,用"源IP","源的端口号","目的IP","目的端口号","协议号"这五元组来标识一个通信.
2> 端口号范围划分
0-1023:知名端口号,HTTP,FTP,SSH等这些广为使用的应用层协议,它们的端口号都是固定的.
1024-65535:操作系统动态分配的端口号,客户端程序的端口号,就是由操作系统从这个范围分配的
3>认识知名端口号(cat /etc/services指令可以查看端口号)
ssh服务器端口号:22
ftp服务器端口号:21
telent服务器端口号:23
http服务器端口号:80
https服务器端口号:443
注意我们自己写程序时,要尽量避开这些端口号
关于端口号我们需要注意的两个问题
1.一个进程是否可以bind多个端口号?(可以)
2.一个端口号是否可以被多个端口号绑定?(不可以,若是一个进程已经绑定,再去fork(),是可以实现的)
二.查看网络和服务器pid的重要工具
通过 netstat -n | grep 文件名 来查看网络状态
通过 pidof 进程名 查看进程id,查看服务器进程比较方便
三.UDP协议
1>UDP协议端格式
2>UDP特点
①无连接:知道对端的IP和端口号就直接进行传输,不需要进行建立连接
②不可靠:没有确认机制,没有重传机制,如果因为网络故障该段无法发到对方,UDP协议层也不会给应用层返回任何错误信息.
③面向数据报:不够灵活的控制读写数据的次数和数量.
④全双工:socket既能读也能写
面向数据报----应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并.
3>UDP缓冲区
UDP没有真正意义上的发送缓冲区,调用sendto会直接交给内核,由内核将数据传给网络层协议进行后续的传输工作.
UDP具有接收缓冲区,但是这个接收缓冲区不能保证收到的UDP报的顺序和发送的一致,如果缓冲区满了,再到达就会丢弃.
4>UDP注意事项
UDP协议首部中有一个16位的最大长度,也就是说一个UDP能够传输的数据最大长度是64K(包含UDP的首部)
那么64K在互联网环境下,是一个非常小的数字.
如果我们需要传输的数据超过64K,就需要在应用层手动的分包,多次发送,并在接收端手动拼装.
5>基于UDP的应用层协议
NFS:网络文件系统
TFTP:简单文件传输协议
DHCP:动态主机配置协议
BOOTP:启动协议(用于无盘设备启动)
DNS:域名解析协议
四.TCP协议
(传输控制协议) ---对数据的传输进行一个详细的控制
1>TCP协议段格式
2>面向字节流:
创建一个TCP的socket,同时就会再内核中创建一个发送缓冲区和接收缓冲区.由于缓冲的存在,就不需要读和写一一匹配.
3>粘包问题
由于TCP是面向字节流,所以就会出现粘包问题,那该如何处理呢?就需要明确两个包之间的边界
对于UDP不存在粘包问题,因为UDP是面向数据包的.
4>基于TCP的应用层协议
HTTP HTTPS SSH Telnet FTP SMTP
TCP机制
1>连接管理机制
在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接.
这里注意如果触发了,捎带应答机制,就有可能变成三次
客户端状态转化:
a>:[CLOSED_SYN_SENT]客户端调用connect ,发送同步报文段
b>:[SYN_SENT-->ESTABLISHED]connect调用成功,则进入ESTABLISHEND状态,开始写数据;
c>:[ESTABLISHED-->FIN_WAIT_1]客户端主动调用close,向服务器发送结束报文段,同时进入FIN_WAIT_1;
d>:[FIN_WAIT_1-->FIN_WAIT_2]客户端收到服务器对结束报文段的回应确认,则进入FIN_WAIT_2,开始等待服务器关闭
e>:[FIN_WAIT_2-->TIME_WAIT]客户端收到服务器发来的结束报文段,进入TIME_WAIT,并发送LAST_ACk给服务器;
f>:[TIME_WAIT-->CLOSED]客户端要等待一个2MSL(报文最大生存时间),才会进入CLOSED状态.