网络基础二——传输层协议UDP与TCP

九、传输层协议

​ 传输层协议有UDP协议、TCP协议等;

​ 两个远端机器通过使用"源IP","源端口号","目的IP","目的端口号","协议号"来标识一次通信

9.1端口号的划分

​ 0-1023:知名端口号,HTTP,HTTPS,FTP,SSH等应用层协议,他们的端口号都是固定的;如:ssh使用的是22号端口,ftp(rzsz使用的就是ftp协议)使用的是21号端口,telnet使用的是23号端口,http使用的是80号端口,https使用的是443号端口,smtp(邮件协议)使用的是25号端口;

​ 1024-65535:操作系统动态分配的端口号,比如客户端使用的由操作系统提供的端口号;其实在这些动态分配的端口号中,也是有一些约定好的应用层端口号,如:MySQL使用3306号端口;

​ 在操作系统中有配置文件记录了知名端口号;

shell 复制代码
vim /etc/services
#可以查看知名端口号;

​ 所以在绑定端口号的时候要注意,避开这些知名端口号;

​ 一个进程可以绑定多个端口号,但是一个端口号只能绑定一个进程;

9.2stat相关指令

shell 复制代码
netstat
#可以查看本地和网络通信;
-l,列出监听状态的服务;
-t,查看tcp的服务;
-u查看udp的服务;
-a,查看所有服务;
-n,拒绝显示别名;
-p,显示相关进程;

iostat
-x,查看设备读写速度

awk '{print $2}' 
#将第二列过滤;

xargs
#将输出的多行信息,以行为单位转换成命令行参数;
#可以搭配起来实现杀死一批进程;

pidof name
#直接得到含有name关键字的一批进程的pid;

十、UDP协议

​ 传输层、网络层、数据链路层,都要考虑,1.将报头和有效载荷分离;2.有效载荷应该交付给哪一个上层协议;

10.1UDP报头

​ 1.整个报文的长度是8个字节;使用定长报头的方式实现报头和有效载荷分离;

​ 2.使用16位的目的端口号,将有效载荷上交给对应服务进程;

​ 源端口号是操作系统自动生成的,目的端口号是需要用户传递的,可以定位目的服务,便于服务响应数据个客户端;

​ 16位UDP长度指的是整个报文的长度;通过UDP长度-8就可以得到正文的长度;

​ 16位UDP检验和,当数据出现偏差时,可以检测出来然后丢弃 ,如果成功就将数据传输给上层协议;尽管是进行了数据检验,但是还是无法保证数据的可靠性;服务端收到的只可能一个完整报文和一个不完整报文

10.2UDP协议特点

​ UDP套接字是全双工的;

​ 1.无连接,不需要建立连接就可以进行通信;

​ 2.不可靠传输,a.传输过程当中出现了数据乱序;b.接收缓冲区写满了,之后到达的数据会直接被丢弃

​ 3.面向数据报传递;

​ 面向数据报:发送几次报文,接收方就需要接收几次报文;不能对报文进行拆分和合并;即每个报文一定是完整的且每次收到的一定是一个报文;不需要对数据进行报头和有效载荷的分离,直接进行反序列化

10.3UDP的缓冲区

​ UDP没有真正意义上的发送缓冲区,只有接收缓冲区用来保存来不及处理的报文;因为服务端收到的只可能一个完整报文和一个不完整报文,有对报文的检验,所以不需要发送缓冲区的存在;

10.4UDP注意事项

​ 如果发送的数据大于16位的长度即64kb,这是就需要将数据分成多个64kb的数据块,多次发送报文;

10.5站在操作系统角度理解UDP

​ 在操作系统中位UDP的报头设计了专门的结构化数据类型;类似如下位段结构

c++ 复制代码
struct udp_header
{
  uint32_t src_port:16;  
  uint32_t dst_port:16;  
  uint32_t length:16;  
  uint32_t check_code:16;  
};

​ 操作系统维护了UDP的报文结构体类型,指向了报文封装的一段空间;操作系统用双链表的形式将报文维护了起来;

c++ 复制代码
struct sk_buff{
    char* start;
    char* end;
    char* pos;
    int type;
    struct sk_buff* next;
};

​ 当操作系统进行封装报文的时候,会先创建报头对象并且添加报头字段,然后将报头对象放到空间的最开始位置,用户层缓冲区的数据放到报头对象的后面,报文的start指向空间的起始地址,end指向空间的最后位置,pos指向报文的有效部分结尾;

10.6基于UDP的应用层协议

NFS: 网络文件系统 ;

TFTP: 简单文件传输协议 ;

DHCP: 动态主机配置协议 ;

BOOTP: 启动协议(用于无盘设备启动) ;

DNS: 域名解析协议;

十一、TCP协议

​ TCP叫做传输控制协议,很多应用层协议都会使用TCP协议,因为它的传输保证可靠性还有对高效传输有一定的策略;TCP也是全双工的;

11.1TCP缓冲区的理解

​ 用户在应用层使用应用层协议进行序列化和反序列化,使用系统调用接口对用户层缓冲区和内核缓冲区的内容进行拷贝;而在传输层,只是考虑内核发送缓冲区中有什么并将其可靠高效地发送到远端的接收缓冲区当中,其实也是一种拷贝;

​ read/recvfrom等接口阻塞是因为,接收缓冲区中没有数据,资源不就绪,操作系统会将服务进程阻塞,等待着有数据了资源就绪,才会进行读取;类似于键盘等硬件资源不就绪,进程阻塞;

​ 对数据的发送是由TCP协议决定的,这体现出了TCP协议的控制特点;

11.2TCP协议的段格式

4位首部长度:包含了选项的长度,即大小是从0-15;4位首部大小的基本单位是4字节,所以大小范围是0-60字节,标准报头20个字节,选项最多是40个字节;当不考虑选项时,一般4位首部长度是5;

​ 使用端口号将有效载荷交给上层;

​ 使用固定长度+自描述字段(4位首部长度)进行有效载荷和报头的分离;

16位窗口大小:返回确认应答时,自己接收缓冲区的剩余空间大小,用于辅助流量控制的;

32位序号 :保证数据传输按序到达;TCP是面向字节流的,会将报文从左向右依次拷贝到发送缓冲区中,每一个字节天然就有了编号,即数组下标;其中报文最后一个字节的数组下标将作为32位序号的填充字段;

32位确认序号 :确认应答是哪一个报文的应答;32位确认序号填充的是收到报文的序号加1

6个标记位:区分不同的报文类型,进而使得服务器执行不同的行为;

11.3TCP协议保证可靠性

​ 1.双方通信的时候一定要保证报头信息的完整;

​ 2.可靠性要保证数据不能丢包,当服务端读到速度过慢或者其他原因,使得缓冲区很快写满,导致数据大面积丢包;这时候就需要客户端和服务器协同,控制双方的读写速度,来减少数据丢包;通过控制发送数据的速度,使得读端来得及读取数据,规避大面积丢包问题,这种方式叫做流量控制

​ 可靠性要保证丢包重传和超时重传,所以理论上是不用进行流量控制的,但是对于一个完整的报文已经到达了目标主机,直接丢弃是不合理的,会使得曾经发送消耗的成本变得没有意义,浪费掉了,控制流量明显比丢包重传更有意义更合理;

​ 3.TCP保证可靠性的最基本的一个特点就是:确认应答(一般不带数据,只有报头),通信双发都要进行确认应答;服务端对于客户端发送过来的所有请求都要进行响应;

​ 当进行TCP网络通信的时候,客户端发送消息必须带一个完整的报头,服务器收到后会向客户端发送一个确认应答,也是要带一个完整的报头;可是双方并不能很好的保证发送和读取的速度均衡,此时客户端会根据服务端的接收缓冲区剩余空间的大小调整发送的速度;客户端根据确认应答返回的响应报头属性中的16位窗口大小(填充着服务端接收缓冲区剩余空间的大小)就可以调整发送的速度;

​ 只要收到了应答就可以保证刚刚我发送出去的消息成功递达了,所以对于没有应答的消息是无法保证可靠性的;双方在发送一条消息和接收到一个应答这种模式下,总会有一个消息或者是应答是新发出去的,不能保证可靠性;

11.3.1TCP最简单最原始的通信方式

​ 由于双方通信要保证的是发送方数据的可靠性,所以不需要考虑接收方发送给发送方的应答是否可靠,只需要知道发送方接收到了应答就已经充分说明了发送方的数据是可靠了;所以 在每一次通信过程中要保证数据可靠是单个方向的,是主动方需要保证可靠

​ 一段时间内主动方没有收到应答,则会认为数据丢失,对历史数据进行超时重传;为了能够支持重传要在接收到应答之前将数据维持一段时间;

​ 现实生活中常见的不是发送消息收到应答保证发送的消息是可靠的,常见的是主动方发送消息,被动方收到了消息并会发送消息,而此消息间接地表明了主动方消息的可靠性;在TCP通信中不是发送确认应答和主动消息两个报文,而是将两报文合并成了一个报文,这种方式叫做捎带应答

11.3.2TCP常规的通信方式

​ TCP原始的通信方式对于主动方如果要发送多个消息,就必须接收到了应答才能发送下一个消息,这样串行的通信效率无疑是非常低下的;原则上发送多个消息,只要保证每一个消息都有应答就行,并不需要串行方式进行;

​ 这种并行的方式存在丢包问题,需要提出策略解决;

​ 对于并行方式的发送消息会存在乱序问题,需要进行解决保证数据的可靠性;使用32位序号就可以保证数据顺序的可靠性;

​ TCP发送是不可能按照字节去发送的,而是按照数据块发送的;为了保证不乱序需要对每一个数据块设置序号,而这个序号就是数据块最后一个字节的下标;对于一次性发送的多个消息,需要同样多个应答,但是为了区分是哪一个消息的应答,就使用了32位确认序号;

​ 确认序号表示1.主动方发送的序号消息已经被收到了;2.确认序号之前的数据已经全部收到了,如:1001表示包括0-1000的数据已经收到;3.下次发送要从确认序号指定的数字开始发送;

​ 确认序号之前的数据已经全部收到了,这样就允许有少量的应答丢包,只要最后一个应答存在就可以保证多个数据传输是可靠的;

​ 因为双方通信是地位对等的,都需要发送数据然后得到应答,所以要将两个序号区分开;而且对于被动方捎带应答的这种情况可能既要发消息(需要主动方发送确认应答)又要提交应答,即一个报文是具有两种属性的,需要不同的序号进行区分;

11.3.3TCP不同类型的报文

​ TCP通信是会先建立连接,然后数据通信,最后断开连接,这些过程都会发送TCP报文,这也就意味着报文是有着不同的类型的,使得服务器执行不同的动作;通过使用6个标记位来区分不同的报文类型,进而使得服务器执行不同的行为;

相关推荐
网安kk2 小时前
2025年三个月自学手册 网络安全(黑客技术)
linux·网络·python·安全·web安全·网络安全·密码学
沐芊屿3 小时前
IPsec VPN配置实验(固定地址)
网络
静心观复4 小时前
TCP的三次握手与四次挥手
网络·网络协议·tcp/ip
dot.Net安全矩阵4 小时前
.NET | 剖析通过 TcpClient 实现内网端口转发
服务器·网络·tcp/ip·安全·.net
Hacker_xingchen6 小时前
网络安全笔记
网络·笔记·web安全
it's all you7 小时前
CentOS设置静态IP教程(2024年12月20日)
linux·tcp/ip·centos
Liveweb视频汇聚平台9 小时前
TCP 和 UDP 的区别:解析网络传输协议
网络·tcp/ip·udp
网络安全-杰克11 小时前
《网络对抗》—— Web基础
前端·网络
李老头探索11 小时前
TCP-UDP调试工具推荐:Socket通信测试教程(附详细图解)
网络协议·tcp/ip·udp
几维安全11 小时前
出海隐私合规解决方案,一文助力中企合规出海
网络·安全