详细解读传输层UDP,TCP协议

传输层
负责数据能够从发送端传输到接收端

端口号
端口号标识了一个主机上进行通信的不同程序;
在这里插入图片描述
端口号的范围划分
0-1023:知名端口号,http.ftp,ssh等这些广为使用的应用层协议,他们的端口号都是固定的。
1024-65535:操作系统动态分配的端口号,客户端程序的端口号,都是由操作系统从这个范围分配的。

知名端口号
有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下的固定端口号;

ssh服务器, 使用22端口
ftp服务器, 使用21端口
telnet服务器, 使用23端口
http服务器, 使用80端口
https服务器, 使用443

执行下面的命令可以查看知名端口号

cat /etc/services

这里要注意,一个进程可以bind多个端口号,一个端口号不能被多个进程bind

netstat
netstat是一个用来查看网络状态的重要工具
常用选项:

n 拒绝显示别名,能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服務状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项,默认不显示LISTEN相关

在这里插入图片描述
pidof
在查看服务器的进程ID是非常方便。 语法:pidof [进程名]
在这里插入图片描述
——————————————————————————————————————————————————
首先明确一个思路:
在TCP/IP协议中,用源ip,源端口号 : 目的ip,目的端口号,协议号 这样一个五元组来标识一个网络通信(通过netstat命令来查看)

那么传输层如何把有效载荷交给应用层?
1、将报头和有效载荷分离;
2、有效载荷通过某种方式交到上层(报头中必定有源端口号和目的端口号)

一、UDP协议

UDP协议格式
在这里插入图片描述
UDP协议采用定长报头(8字节),将报头和有效载荷分离;
源端口号和目的端口号:表示数据从哪个进程来,到那个进程去;
16位UDP长度:表示整个数据报(报头加数据)的最大长度;因为定长报头(8字节),所以数据长度 = 总长度-8;
16位校验和:若校验出错,会直接丢弃。

UDP协议特点–类似于寄信
1、无连接:不进行连接,只要知道对端的IP和端口号就可以直接通信;
2、不可靠:无确认机制;无重传机制;数据无有序保障;若因为网络原因没有把数据发送到对端,UDP协议也不会给应用层返回错误;
3、面向数据报:数据只能整包发,整包读。不可能出现读一包半的情况;

UDP缓冲区

没有发送缓冲区,调用sendto会把数据交给内核,由内核在把数据交给网络层…
有接受缓冲区,但是:
1、不保接收的顺序和发送的顺序一样; 2、如果接收缓冲区满了,在收到的数据会直接丢弃

UDP的socket为全双工,可同时读和写。

二、TCP协议

TCP协议格式
在这里插入图片描述
源端口号和目的端口号:表示数据从哪个进程来,从哪个进程去。
32位序号和确认序号:有三个作用:
1、请求确认机制。 2、保证数据按序到达。 3、通过序号可以得知重复的数据,实现去重。
4位首部长度:表示TCP报头有多少字节。最大为1111->16个4字节,也就是60字节(带选项)。默认为0101->5个4字节,也就是20字节(不带选项)。
————————————————————————————————————————————
六个标志位:
URG:紧急指针(优先处理字段)是否有效(有效为1,无效为0)
ACK:确认好号是否有效
PSH:提示接收端应用程序立刻从TCP缓冲区读数据
场景:TCP有接受缓冲区和发送缓冲区,如果应用层一直不读数据,客户端一直往应用层写数据,那么缓冲区有可能满了,当接收缓冲区满了,通过PSH标志位提示应用层该读数据了。
RST:如果三次握手时最后一次报文丢失,客户端会认为建立好了连接,然而服务器认为没有建立好连接,此时服务器给客户端一个RST响应,告诉客户端并没有建立好连接,当客户端收到响应;应该重新建立连接或关闭老的连接(复位报文段);
SYN:请求建立连接,三次握手成功时为1(同步报文段);
FIN:通知对方本端要关闭,四次挥手时为1(结束报文段);
—————————————————————————————————————————————
16位窗口大小:就是本端接受缓冲区剩余的大小,要把剩余的大小给对端。
16位检验和:接收端校验不通过则认为数据有问题。
16位紧急指针:因为TCP保证按序到达,所以通过紧急指针标识那部分为紧急数据,需要优先处理。

TCP链接机制:
在之前的一篇文章中有详细的介绍:
https://blog.youkuaiyun.com/aixintianshideshouhu/article/details/90115914

TCP在具有可靠性的同时,也引入一些机制来提升效率,接下来逐一介绍:

1、保证可靠性

校验和:接收端校验不通过则认为数据有问题。
序列号
TCP将每个字节的数据都进行了编号,称为序列号:
序列号保证了:1、数据按序到达; 2、确认应答; 3、通过序列号可以得知重复的数据,去重;
确认应答(ACK)机制
在这里插入图片描述
比如我发了1-100数据(按序到达),对端的确认序号就是ACK 101,表示101号之前的数据已经都确认了。

超时重传机制
在这里插入图片描述
1、A主机给B主机发送数据之后,可能因为网络的原因,数据丢包,没有到达主机B;若主机在一个特定的时间间隔没有收到B发来的确认应答,就会重发;
2、主机A没有收到B发来的确认应答,可能是因为确认应答丢包,这是通过序号得知重复的数据,得以去重。

这个特定的时间间隔是动态计算的。2^n-1500(ms)。也就是说,第一次为500ms,在重发一次为5002,在就是5004,5008…,累积到一定次数,TCP认为网络或对端有问题,直接关闭连接。
连接管理https://blog.youkuaiyun.com/aixintianshideshouhu/article/details/90115914

流量控制
在这里插入图片描述
接受端把自己的窗口大小告诉发送端,指明自己的接收缓冲区还剩多少;如果接收端上层一直不处理数据,那么窗口的大小就会一直变小,发送端就会减慢发送的速度;当接收缓冲区满了,就将窗口大小设置为0并且告知发送端,这时发送端不在发数据,但是会定时的发送一个窗口探测,探测接收端窗口的大小。

拥塞控制
在对方能接收的前提下,我直接发送一万条数据,如果收到九千九百多条应答,应该是部分丢包;如果只收到几个应答,那一定是网络的问题。
所以TCP使用慢启动机制,先发送少量数据,看看网络的拥塞情况,在决定以多大的速度传送数据。
拥塞窗口:
第一次发送,拥塞窗口为1,只发送一段数据;收到一个应答,变为2;此时一次发送两段数据,在收到两段应答,滑动窗口变为4,一次发送4个数据…这样就是以指数形式增加。(慢启动只是初始慢,但是增长的速度是非常快的)
每次发送时,将拥塞窗口和对方窗口的大小比较,去较小的值作为发送的滑动窗口。
当拥塞窗口增长到一个阈值,以线性增加。
在这里插入图片描述

2、提高性能

滑动窗口
确认应答性能较差,因为对每一个发送的数据,都要收到ACK应答才继续发送下一个,尤其是数据往返的时间较长的情况。
如果一次发送多段数据:
在这里插入图片描述
虽然一次发送多段数据,但是一次发送的数据量是有限的:
滑动窗口:
16位窗口大小指的是接收端的接收缓冲区的剩余大小,我给你发数据,你要把你能接收的大小告诉我。
接收端把它的接收缓冲区剩余大小告诉我,所以这个大小就是我无需等待确认应答而可以继续发送的最大值,图中的窗口大小就是400字节。我要维护的这个大小,发送前四段数据时,无需等待ACK,因为我知道你的接收缓冲区装的下,就算你一条没读,数据最最多会把你的接收缓冲区打满。
收到第一条确认应答(ACK 101,滑动窗口往后滑),这时需要有一个发送端维护的发送缓冲区(由对端的接收缓冲区确定),记录那些数据没有得到确认应答,而得到确认应答的数据段,就从发送缓冲区删除。
在这里插入图片描述
快重传
一次发送多段数据,如果丢包了,原因:
1、如果是认为应答包丢了,不要紧,可以根据后面的应答确认接收端已经接受了多少数据。
2、如果是数据包丢了,就需要快重传机制。

举例:当101-200这段报文丢包,接收端没有收到这段,就会一直给发送端,发送ACK 101,表示我没有收到101;当发送端连续三次收到ACK 101 ,就会重发101-200的字段;这个时候接收端接收到101之后,在返回的ACK 501(在连续三次发送ACK 101时,接收端接收的其实是 200-301 301-400 401-500的字段,只是被放到了接收缓冲区)。

延迟应答
如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小

假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K; 
但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;

嗯,窗口越大,网络的吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
一般每隔两个包。延迟200ms应答一次。

捎带应答
在延迟应答的基础上, 我们发现, 很多情况下, 客户端服务器在应用层也是 “一发一收” 的. 意味着客户端给服务器说
了 “How are you”, 服务器也会给客户端回一个 “Fine, thank you”;
那么这个时候ACK就可以搭顺风车, 和服务器回应的 “Fine, thank you” 一起回给客户端
ACK搭顺风车,和数据放在一起。就像捎带东西一样。

面向字节流
创建一个TCP的socket,同时在内核中创建一个发送缓冲区和一个接收缓冲区;

调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出
去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可
以写数据. 这个概念叫做 全双工

由于TCP缓冲区的存在,TCP程序的读和写不需要一一匹配。

写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次
read一个字节, 重复100次;
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值