TCP && UDP

文章目录

目录

文章目录

前言

[1 . 传输层的作用](#1 . 传输层的作用)

[​编辑1.1 理解传输层](#编辑1.1 理解传输层)

[1.2 两种传输层协议](#1.2 两种传输层协议)

[2 . 端口号](#2 . 端口号)

[2.1 定义](#2.1 定义)

[2.2 网络五元组](#2.2 网络五元组)

[2.3 端口号如何分配](#2.3 端口号如何分配)

[3 . UDP](#3 . UDP)

[3.1 特点](#3.1 特点)

[3.2 协议格式](#3.2 协议格式)

[4 . TCP](#4 . TCP)

[4.1 特点](#4.1 特点)

[4.2 可靠传输的实现](#4.2 可靠传输的实现)

丢包问题

丢失数据包

丢失ACK

[4.3 超时重传时间如何确定](#4.3 超时重传时间如何确定)

[4.4 连接管理(三报文握手,四报文挥手)](#4.4 连接管理(三报文握手,四报文挥手))

三报文握手

四报文挥手

[4.5 滑动窗口机制](#4.5 滑动窗口机制)

丢包问题

ACK丢失

报文段丢失

[4.6 流量控制](#4.6 流量控制)

[4.7 拥塞控制](#4.7 拥塞控制)

拥塞窗口

拥塞控制算法

慢开始

拥塞避免

快重传

快恢复

[4.8 协议格式](#4.8 协议格式)

[4.9 拓展](#4.9 拓展)

Nagle算法

延迟确认应答

捎带应答

总结


前言

大家好,今天给大家介绍一下传输层中两个非常重要的协议TCP和UDP


1 . 传输层的作用

1.1 理解传输层

在IP协议的首部有一个协议字段, 用来标识网络层的上一层使用的是哪一个传输层协议,根据这个协议号就可以区分出传递的数据是基于TCP还是UDP

IPV4

同样的,我们为了区分出传递的数据需要交给哪个应用程序,就需要借助一种手段 端口号

1.2 两种传输层协议

在TCP/IP协议栈中能实现传输层功能并且具有代表性的协议是TCP和UDP,除此之外还有UDP-Lite

SCTP,DCCP等协议(不需要了解)

TCP

TCP是面向连接, 可靠的,基于流来进行传输的协议

UDP

UDP是不具备可靠传输的数据保协议,美其名曰,将广播和细节控制交给用户

也就是除了发送消息之外啥也不干,不像TCP,基本上啥都提供了,后面细说

拓展

连接

链接是指网络中的两个应用程序直接为了相互传递消息而专有的,虚拟的通信线路,也叫做虚拟线路

理解面向连接: 搭建虚拟线路用以传输数据

理解非面向连接: 发送一个数据包之后就不管了 你让我发我发就是了, 我也不管对面是不是能收到

2 . 端口号

2.1 定义

数据链路层和IP中的地址指的是MAC地址和IP地址, 前者用来标识一段链路中不同的物理主机否则负责表示网络中的主机和路由器。

在传输层中也有这样的概念, 那就是端口号, 用来标识同一台计算机中进行网络通信的不同应用程序因此, 它也被称为程序地址

2.2 网络五元组

内容: 源IP 目标IP 源端口 目标端口 协议号

作用: 用来标识一个网络通信

①和③ 不是一个通信: 源IP不同 其他相同

①和② 不是一个通信: 源端口不同 其他相同

②和③ 不是一个通信: 源端口不同 源IP不同 其他相同

大家好好理解,缺一不可

2.3 端口号如何分配

知名端口号:

HTTP, FTP, TELNET等广为使用的协议被分配到固定的端口号,便于访问 , 知名端口号一般由 0~1023 的数字分配而成, 应用程序应该避免使用知名端口号进行既定目的之外的通信避免产生冲突

动态分配端口号: 客户端可以自己指定端口号,也可以让操作系统进行动态分配


3 . UDP

UDP是User DataGram Protocol(用户数据报协议)的缩写

3.1 特点

UDP不提供复杂的控制机制, 利用IP提供的面向无连接的通信服务。

即使在网络拥堵的情况下, UDP也无法进行流量控制,拥塞控制这样的行为,此外如果在传输过程中出现了丢包问题, UDP也不负责重发, 简而言之, 不提供可靠的传输, 啥也不提供, 只提供发送数据报这个最基本的功能

基于此总结一下它的特点

无连接 不可靠 面向数据报 全双工(可以在同时收和发)

应用

  • 包总量较少的通信(DNS,SNMP等)
  • 视频, 音频等所媒体通信(即使通信)
  • 广播通信(广播, 多播)

3.2 协议格式

  • 源端口号: 表示发送端端口号, 字段长16位。该字段是可选项, 不选即为0
  • 目标端口号: 表示接收端端口号, 字段长度16位
  • 包长度: UDP数据包的长度(最大为64KB)
  • 校验和: 用于校验UDP首部和数据是否出错

UDP校验和是如何计算的?

  1. 首先将UDP伪首部的各字段与UDP首部以及数据部分按16位进行分组,如果数据部分长度不是16位的倍数,则需要在末尾添加0补齐。

  2. 将这些16位的数据字段依次相加,如果相加的结果超过16位,则将溢出部分加到低16位上。

  3. 将得到的结果取反得到校验和字段的值。

UDP伪首部

为什么在计算校验和时引入伪首部?

UDP首部只包含了五元组中的两个, 如果其他三项被破坏了会产生怎样的后果呢?

前面提到过, 缺一不可, 所以为了避免该数据包发送到不该被发送的地方

在计算校验和时就引入了伪首部这个概念

4 . TCP

4.1 特点

TCP(传输控制协议)

为了实现可靠传输,需要考虑很多的事情, 如: 数据损坏, 丢包, 重复, 失序等等, 如果不能解决这些问题, 那就不能称之为可靠传输, 那么问题来了, TCP是如何解决这些问题的呢? 我们一起来来看看吧

特点

面向连接 可靠传输 面向字节流 全双工

4.2 可靠传输的实现

在TCP中, 当发送端的数据到达接受方主机时, 接收方主机就会给发送方主机返回一个消息通知, 我们称之为确认应答(ACK)

TCP通过确认应答实现可靠传输。当发送端将数据发出之后就等待对端的确认应答。如果有确认应答, 说明数据已经成功到达对端, 反之数据丢失的可能性很大。

为什么通过确认应答可以实现可靠传输?

小明: 小花, 你吃饭了吗?

小花:

小明: 你咋不回我话?

小花

小明: 无影脚

上面的情况就属于是没有ACK的情况, 小明并不知道小花听没听到, 发送发主机并不清楚接收方主机是否收到消息, 这肯定是不行的, 我们在生活中, 别人问话我们肯定是要回复的, 在网络的世界同样是一个道理

丢包问题

以上的情况都是理想情况, 有没有可能出现数据包丢失或者ACK丢失的情况呢? 答案是肯定的

丢失数据包

以上的过程就是所谓的超时重传,学过计组的应该不会陌生! 注意这里的特定时间间隔(后面会说)


丢失ACK

在这个过程中主机A不过是重发了一次数据, 问题不大!

但是主机B已经接收过一次该数据了, 为了对上层提供可靠的传输, 它就必须丢弃重复收到的数据,那主机B如何才能知道收到的是不是重复数据呢? 为此, 就必须添加一种机制, 它能够识别是否已经接收该数据, 又能判断出是否需要接收!

这个机制就是序列号, 序列号是指按顺序给每个发送数据的每一个段(八位字节)都标上对应的编号

4.3 超时重传时间如何确定

这是一个很复杂的问题, 不好搞

RTT: 报文段的往返时间

RTO: 超时重传时间

RTT会随着数据包途径的网络环境的确变化而时刻变化, 就意味着RTO也是时刻变化的

如果RTO<RTT

如果RTO远大于RTT

显然 RTO比RTT大一点点是最优解

具体如何计算 大家参考 Karn算法

4.4 连接管理(三报文握手,四报文挥手)

三报文握手

ACK是否多余? 并不多余,防止连接请求在网络之中阻塞后再次到达

四报文挥手

有必要等待, 防止最后一次ACK丢失导致服务器无法关闭

上述握手过程理应也是四次的, 但是发生了合并, 即捎带应答(后面会提)

4.5 滑动窗口机制

提高传输效率(让TCP在可靠传输的前提下, 效率不要太拉胯)

TCP以一个段为单位, 每发一个段进行一次确认应答的处理

为了解决这个问题,TCP引入了窗口这个概念。 即使在往返时间较长的情况下, 它也能控制网络性能的下降

丢包问题

ACK丢失

少部分ACK丢失不影响 , 只要有后面序号大的ACK到达, 会默认前面的数据已经收到

报文段丢失

高速重发控制 : 默认收到三个相同的ACK时,表名该报文段丢失, 不必等待超时重传, 可以立即重传

4.6 流量控制

发送方以自己的实际情况发送数据, 但是没有考虑到接收方的接收能力, 这个肯定是不行的。接收方每接收一个数据包, 都会花上一定时间去处理, 倘若发送发不考虑接收方的处理能力,会导致接收方处在高负荷的状态下, 从而无法接收任何新的数据, 将新来的数据丢弃, 从而导致网络流量被无端浪费

所谓流量控制就是: 发送发要根据接收方的接收能力发送数据

那么如何得知接收方的接收能力呢?在TCP首部中有一个专门的字段用来通知窗口大小。 接收主机可以将自己可以接受的缓冲区大小放入这个字段中通知给发送端,这个字段的值越大, 说明网络的吞吐量越高。

流量控制图解

为了防止窗口更新通知在传输途中丢失, 发送端每隔一段时间就会发送一个窗口探测报文。

4.7 拥塞控制

上面的流量控制是考虑的发送和和接收方主机之间的通信能力, 没有考虑到数据在网络中传输的情况, 如果网络十分拥塞, 而发送发还是按照原来的窗口大小进行发送数据, 无疑会产生丢包问题, 情况严重的话, 网络直接瘫痪!!

拥塞窗口

为了调节发送方要发送的数据量, 定义了一个叫"拥塞窗口" 这样的概念

实际上的发送窗口大小 = Math.min(拥塞窗口, 接收端主机通知的窗口大小)

那么问题来了, TCP到底是如何计算拥塞窗口大小的呢?


拥塞控制算法

慢开始

慢开始(Slow Start)是TCP拥塞控制算法中的一种机制,用于在连接刚建立或者在网络中出现拥塞时,控制发送端的发送速率,避免导致网络拥塞恶化。

  1. 初始时,拥塞窗口大小为1个报文段的大小(通常为MSS,最大报文段长度)。
  2. 每经过一个往返时间(RTT),拥塞窗口大小加倍。
  3. 当拥塞窗口大小达到一定阈值(慢开始门限),就会进入拥塞避免阶段。
拥塞避免
  1. 当拥塞窗口大小达到慢开始门限时,进入拥塞避免阶段。
  2. 在拥塞避免阶段,每经过一个往返时间(RTT),拥塞窗口大小线性增加,即每经过一个RTT,拥塞窗口大小加1。
  3. 如果发生丢包事件(超时或接收到重复的冗余ACK),将慢开始门限设置为当前拥塞窗口大小的一半,并将拥塞窗口大小重新设置为1,然后重新开始慢开始算法。

慢开始门限(Slow Start Threshold)

快重传

快重传的原理是当发送端接收到连续三个重复的确认(Duplicate ACK)时, 就知道现在只丢失了个别的报文段, 于是不启动慢开始算法, 改为快重传

  1. 发送端发送报文段并启动定时器等待确认。
  2. 如果接收端收到乱序的报文段,会发送一个重复的确认。
  3. 当发送端连续收到三个重复的确认时,立即重传丢失的报文段。
  4. 在重传后,发送端继续正常的拥塞控制算法(如拥塞避免)。
快恢复

快恢复的原理是在发送端收到第一个重复的确认(Duplicate ACK)时,将拥塞窗口大小减半,然后进入快恢复状态。在快恢复状态下,发送端继续以每收到一个重复的确认就将拥塞窗口大小加1,直到达到慢开始门限(ssthresh)为止。此时,发送端会进入拥塞避免状态继续发送数据。

  1. 发送端发送报文段并启动定时器等待确认。
  2. 如果接收端收到乱序的报文段,会发送一个重复的确认。
  3. 当发送端收到第一个重复的确认时,将拥塞窗口大小减半,并进入快恢复状态。
  4. 在快恢复状态下,每收到一个重复的确认,将拥塞窗口大小加1,直到达到慢开始门限为止。
  5. 当拥塞窗口大小达到慢开始门限时,发送端进入拥塞避免状态继续发送数据。

4.8 协议格式

  • 源端口号(16 bits):标识发送端口号
  • 目的端口号(16 bits):标识接收端口号。
  • 序列号(32 bits):用于对数据包进行排序和重组。
  • 确认号(32 bits):表示期望接收的下一个字节的序列号。
  • 数据偏移(4 bits):指示TCP头部的长度。
  • 保留(6 bits):保留字段,用于将来的扩展。
  • 控制位(6 bits):包括URG、ACK、PSH、RST、SYN、FIN等标志位。(不必理会)
  • 窗口大小(16 bits):接收端的接收窗口大小,用于流量控制。
  • 校验和(16 bits):用于检验TCP头部和数据的完整性。
  • 紧急指针(16 bits):仅在URG标志位被设置时有效,指示紧急数据的位置。
  • 选项(可变长度):包括最大报文段长度、时间戳、窗口扩大因子等选项

4.9 拓展

Nagle算法

TCP中为了提高网络的利用率, 经常使用一个叫做Nagle的算法。

该算法是指发送端即使还有应该要发送的数据,但是如果这部分数据很少的话, 则进行延迟发送的一种处理机制。具体来说, 就是仅在下列任意一种条件下才可以发送数据,如果都不满足, 则延迟发送。

  • 已发送的数据都已经收到确认应答时
  • 可以发送最大长度(MSS)的数据时

根据这个算法虽然网络利用率可以提高, 但是会产生延迟。 为此, 在窗口系统以及机械控制等领域中使用TCP时,禁用该算法。

延迟确认应答

实际上, 大可不必为每一个数据段都进行一次确认应答。 TCP采用滑动窗口机制,即使少一些ACK,也问题不大!

捎带应答

捎带应答(Piggybacking)是一种优化网络通信的技术,通常用于减少网络传输中的额外开销和提高网络利用率。在TCP通信中,捎带应答指的是在发送数据的同时,将确认信息(ACK)捎带在数据包中一起发送,而不是单独发送确认信息。

具体来说,当接收端收到数据包后,如果有需要发送的确认信息,通常会将确认信息放入接收缓冲区,并等待一定时间后再发送确认信息。但是,如果接收端有数据要发送给发送端,可以利用这个时机将确认信息捎带在数据包中一起发送。这样,可以减少额外的确认信息传输,提高网络利用率。


总结

以上就是这篇博客的主要内容了,大家多多理解,下一篇博客见!

相关推荐
FeelTouch Labs13 分钟前
Netty实现WebSocket Server是否开启压缩深度分析
网络·websocket·网络协议
千天夜2 小时前
使用UDP协议传输视频流!(分片、缓存)
python·网络协议·udp·视频流
follycat2 小时前
[极客大挑战 2019]HTTP 1
网络·网络协议·http·网络安全
earthzhang20213 小时前
《深入浅出HTTPS》读书笔记(5):随机数
网络协议·http·https
xiaoxiongip6663 小时前
HTTP 和 HTTPS
网络·爬虫·网络协议·tcp/ip·http·https·ip
JaneJiazhao3 小时前
HTTPSOK:SSL/TLS证书自动续期工具
服务器·网络协议·ssl
JaneJiazhao3 小时前
HTTPSOK:智能SSL证书管理的新选择
网络·网络协议·ssl
城南vision5 小时前
计算机网络——HTTP篇
网络协议·计算机网络·http
懒大王就是我7 小时前
C语言网络编程 -- TCP/iP协议
c语言·网络·tcp/ip
海绵波波1078 小时前
Webserver(4.3)TCP通信实现
服务器·网络·tcp/ip