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

最新推荐文章于 2023-03-07 08:58:55 发布

原创最新推荐文章于 2023-03-07 08:58:55 发布 · 321 阅读

CC 4.0 BY-SA版权

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

端口号
端口号标识了一个主机上进行通信的不同程序；
在这里插入图片描述
端口号的范围划分
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次;