UDP/TCP协议报头详细分析

这篇具有很好参考价值的文章主要介绍了UDP/TCP协议报头详细分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

————————预备知识————————

数据段

数据段=报头+数据

netstat

netstat是一个用来查看网络状态的重要工具.
语法:netstat [选项]
功能:查看网络状态
常用选项:
n 拒绝显示别名,能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服務状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项,默认不显示LISTEN相关

pidof

在查看服务器的进程id时非常方便.
语法:pidof [进程名]
功能:通过进程名, 查看进程id

—————UDP协议报头即相关概念分析—————

UDP协议端格式

UDP/TCP协议报头详细分析,网络协议,TCP,UDP
UDP报头:也就是指图中标识的前8字节内容。

16位UDP长度: 表示整个数据报(UDP首部+UDP数据)的最大长度。

16位UDP检验和:16位UDP长度 — 接收到的UDP整体 = 0 ; 则表示UDP结构完整,校验正确。如果校验和出错, 就会直接丢弃。

UDP报头和数据分离的方案就是限定报头占前八字节,其他全为正文数据。

UDP 特点

无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层
返回任何错误信息;
面向数据报: 不能够灵活的控制读写数据的次数和数量

全双工

能同时进行读写操作

send / rec 函数的本质

send() rec() 函数的本质是拷贝函数,从应用层拷贝如内核层,再从内核层拷贝到传输层。
UDP/TCP协议报头详细分析,网络协议,TCP,UDP

UDP的缓冲区

UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;

UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃

注意:
UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部). 然而64K在当今的互联网环境下, 是一个非常小的数字. 如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;

基于UDP的应用层协议

(目前只做了解,因为没见过体)
NFS: 网络文件系统;
TFTP: 简单文件传输协议;
DHCP: 动态主机配置协议;
BOOTP: 启动协议(用于无盘设备启动);
DNS: 域名解析协议;
写UDP程序时自定义的应用层协议;

—————TCP协议报头即相关概念分析—————

TCP格式及解析

TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制。
UDP/TCP协议报头详细分析,网络协议,TCP,UDP
源/目的端口号: 表示数据是从哪个进程来, 到哪个进程去;

32位序号/32位确认号:用于确认报文是否完整,具体原理再做详细说明。

4位首部长度:表示该TCP头部有多少个32位bit(有多少个4字节); 所以TCP头部最大长度是15 * 4 = 60

6位标志位:
URG: 紧急指针是否有效
ACK: 确认号是否有效
PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段

16位窗口大小: 后续详细介绍

16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.

16位紧急指针: 标识哪部分数据是紧急数据;紧急指针指向的数据,发送优先级得到提升

32位序号/32位确认号确认TCP完整性的原理

ACK机制(确认应答机制)依托于32位序号/32位确认号。工作原理如图:
UDP/TCP协议报头详细分析,网络协议,TCP,UDP
32位序列号:TCP将每个字节的数据都进行了编号,即为序列号
32位确认号:每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发。

一些细节:
即使程序员按照时间发送的数据,实际发出的时间和实际接收到的时间都不确定的, 32位序号/32位确认号和ACK是否可以辅助数据排序? 答: 是

确认序号和位序列号不合并位一个东西的原因是:全双工,收的同时可能发送,如果和并未一个序号,这个序号可能被同时使用,产生矛盾。

——————各种TCP机制的分析——————

ACK机制(确认应答机制)

UDP/TCP协议报头详细分析,网络协议,TCP,UDP

ACK(Acknowledgment)机制是一种用于确认数据包或消息是否成功传输的机制。在网络通信中,当发送方向接收方发送数据包时,接收方会发送一个ACK信号作为确认,告知发送方数据包已经成功接收。
ACK机制的工作原理如下:

  1. 发送方发送数据包给接收方。
  2. 接收方收到数据包后,会发送一个ACK信号给发送方。
  3. 发送方在接收到ACK信号后,确认数据包已经成功传输。
  4. 如果发送方在一定时间内没有接收到ACK信号,会认为数据包丢失或未成功传输,并会重新发送数据包。

ACK丢失

简单来说就是 ACK标志位失效

ACK丢失指的是在网络通信中,发送方发送了数据包给接收方,但接收方没有及时发送ACK(Acknowledgement)报文进行确认的情况。ACK报文是用来确认接收到的数据包的,它通常会在接收方成功接收到数据后发送给发送方。
当发送方发送数据包后,它会等待一段时间来接收ACK报文。如果在规定的时间内没有收到ACK报文,发送方就会认为数据包丢失,并触发重传机制,重新发送相同的数据包。
ACK丢失可能发生在以下情况下:

  1. 网络延迟:网络延迟可能导致ACK报文在传输过程中被延迟或丢失,使得发送方无法及时收到确认。
  2. 数据包丢失:在传输过程中,数据包可能会由于网络拥塞、错误的路由或其他原因而丢失,导致接收方无法接收到数据包和发送ACK报文。
  3. 故障设备:接收方的网络设备、操作系统或应用程序可能存在故障,导致无法发送ACK报文。
  4. 防火墙或路由器配置问题:防火墙或路由器的配置问题可能会阻止ACK报文的传输,导致丢失。

特别注意:ACK丢失不代表数据包丢失

超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发.

UDP/TCP协议报头详细分析,网络协议,TCP,UDP

重发引起的数据重复

机A未收到B发来的确认应答, 也可能是因为ACK丢失了,那么A会触发重传,发出重复的内容,那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉. 这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果。

超时重传的时间确定

最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.但是这个时间的长短, 随着网络环境的不同, 是有差异的.如果超时时间设的太长, 会影响整体的重传效率;如果超时时间设的太短, 有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时
时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传.
如果仍然得不到应答, 等待 4
500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接。

举例:网络环境拥挤时,会设置更长的超时时间

TCP是全双工原理图

注意:缓冲区属于TCP协议
UDP/TCP协议报头详细分析,网络协议,TCP,UDP

连接的本质

建立链接的本质是建立一种数据结构,是数据结构就会造成负载。

SYN洪水(SYN Flood)

SYN Flood是互联网上最原始、最经典的DDoS(Distributed Denial of Service)攻击之一。 它利用了TCP协议的三次握手机制,攻击者通常利用工具或者控制僵尸主机向服务器发送海量的变源IP地址或变源端口的TCP SYN报文,服务器响应了这些报文后就会生成大量的半连接,当系统资源被耗尽后,服务器将无法提供正常的服务。

连接管理机制

三次握手(建立连接)与四次挥手(断开连接)。
UDP/TCP协议报头详细分析,网络协议,TCP,UDP

三次握手 (建立连接)

UDP/TCP协议报头详细分析,网络协议,TCP,UDP
三次握手的过程如下:

  1. 客户端向服务器发送连接请求(SYN包),其中包含一个初始序列号(ISN)用于后续数据传输的顺序标识。
  2. 服务器收到连接请求后,如果接受连接,则发送确认(ACK包)和自己的初始序列号给客户端,同时也发送一个连接请求(SYN包)给客户端。
  3. 客户端收到服务器的确认和连接请求后,向服务器发送确认(ACK包),确认服务器的初始序列号,并发送自己的初始序列号。

四次挥手(断开连接)

UDP/TCP协议报头详细分析,网络协议,TCP,UDP
四次挥手的过程如下:

  1. 主动关闭方(可能是Client方,也可能是Server方)发送连接释放请求(FIN包)给被动关闭方,表示主动关闭方不再发送数据。
  2. 被动关闭方收到连接释放请求后,发送确认(ACK包)给主动关闭方,表示已收到连接释放请求。
  3. 被动关闭方进入CLOSE_WAIT状态,继续发送剩余的数据(如果有),并等待主动关闭方发送连接释放请求。
  4. 主动关闭方收到确认后,进入TIME_WAIT状态,等待一段时间(2倍的最大报文段生存时间,即MSL)以确保被动关闭方收到确认。补充说明:(MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK))
  5. 在等待时间结束后,主动关闭方发送最后的连接释放请求(FIN包)给被动关闭方。
  6. 被动关闭方收到连接释放请求后,发送确认(ACK包)给主动关闭方,表示已收到连接释放请求。
  7. 被动关闭方进入CLOSED状态,主动关闭方等待一段时间后也进入CLOSED状态,完成连接的断开。

上述过程可以连系到一些TCP的demo代码产生的现象:

现象一:同端口号Server在断开后不能立马重启,因为此时上次刚断开的Server还处于TIME_WAIT状态,并没有真正断开。

现象二:代码层面,在完成所有服务/应答后,必须调用close()函数关闭套接字,如果没有关闭,则会无法退出,连接将一直保持打开状态,占用网络资源。这可能导致其他应用程序无法使用该端口或无法建立新的连接。
原因是不使用close()关闭套接字,就会卡在close_wait状态

如何使断开的服务端可以立刻重启

使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符

setsockopt 函数可以使用 SO_REUSEADDR 选项来设置端口复用。当一个套接字处于 TIME_WAIT 状态时,如果另一个套接字想要绑定到同样的地址和端口,通常会报错。使用 SO_REUSEADDR 选项可以允许地址和端口的重用,即使套接字处于 TIME_WAIT 状态。
下面是一个使用 setsockopt 函数设置端口复用的示例:


```cpp
c复制代码#include <sys/socket.h>
#include <netinet/in.h>

int enable_port_reuse(int sockfd) {
    int reuse = 1;
    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)) == -1) {
        // 设置失败
        return -1;
    }
    return 0;
}

TCP面向字节流的浅略理解:

应用层向TCP发送缓冲区写入时,是将数据以字符串的格式拷贝文章来源地址https://www.toymoban.com/news/detail-691728.html

到了这里,关于UDP/TCP协议报头详细分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【计算机网络实验】实验四 TCP/UDP协议分析

    目录 一、TCP连接建立过程分析 二、TCP关闭连接过程分析 三、6号报文分析 四、A方TCP报文序列号分析 五、计算 六、UDP协议分析 图 1 第一次握手 第一次握手:客户端将标志位 SYN 置为 1 ,随机产生一个值 SEQ = X = 0 ,并将该数据包发送给服务器,等待服务器确认; 图 2 第二次

    2024年02月03日
    浏览(51)
  • Wireshark抓取网卡协议分析(TCP,UDP,ARP,DNS,DHCP,HTTP超详细版本)

    使用wireshark工具抓取ping命令操作 选择本机网卡WLAN,点击开始,开始抓包 在数据列表区中选取TCP协议,在数据详细区中显示出其详细信息 (1)Frame: 物理层的数据帧概况 (2)Ethernet II: 数据链路层以太网帧头部信息 (3)Internet Protocol Version 6: 互联网层IP包头部信息 (4)Tra

    2024年02月08日
    浏览(43)
  • 网络协议分析(一)(C语言实现---ethernet、arp、ip、icmp、udp、tcp)

    以太网协议是一种局域网通信协议,它通过物理层和数据链路层的协同工作,使用媒体访问控制地址和载波监听/冲突检测协议来实现计算机之间的稳定数据传输。在数据传输过程中,以太网会将数据封装成数据帧,并根据目标MAC地址来识别需要接收数据的计算机。通过这种方

    2024年02月06日
    浏览(50)
  • UDP报头、TCP报头、IP报头、MAC头部、ARP头部

    前言:DUP报头、TCP报头、IP报头、MAC头部、ARP头部。 UDP报头由八个字节组成,每个字段都是两个字节 : 1.源端口号:发送方端口号, 需要对方回信的时候选用,不需要对方回信的时候置0 2.目的端口号:接收方端口号 , 在终点交付报文时需要用到 3.长度:UDP用户数据报的长

    2024年02月03日
    浏览(42)
  • 网络协议报文理解刨析篇二(再谈Http和Https), 加上TCP/UDP/IP协议分析(理解着学习), 面试官都惊讶你对网络的见解

    目录 前文链接(系列助学, 也为后文学习做铺垫, 可按需读取) 一. 再谈HTTP再理解 二. HTTP对比学习HTTPS HTTP和HTTPS的区别如下: 三.TCP协议  (三次握手四次挥手细节过程理解在之前的博文中有详细图解) tcp缓冲区概念的引入  (解释流量控制): 确认应答(ACK)机制的理解 (编序号)

    2023年04月09日
    浏览(60)
  • TCP协议详解—TCP各个报头属性的作用

      首先我们需要知道TCP是什么,TCP全称是传输控制协议(Transmission Control Protocol),它是一种面向连接的、可靠的、基于字节流的传输层通信协议。   网络传输,无非就是要做两件事情,一是做决策,二是做执行,在网络传输中,传输层主要做的是决策,下面的层做执行。

    2024年02月03日
    浏览(43)
  • 网络:TCP、UDP协议

    目录 netstat pidof xargs UDP协议 TCP协议 setsockopt函数 确认应答机制 超时重传机制 流量控制 滑动窗口 拥塞控制 延迟应答 捎带应答 面向字节流 粘包问题 在TCP/IP协议中, 用 \\\"源IP\\\", \\\"源端口号\\\", \\\"目的IP\\\", \\\"目的端口号\\\", \\\"协议号\\\" 这样一个五元组来标识一个通信 0- 1023:知名端口号, HTTP

    2024年04月17日
    浏览(41)
  • 【计算机网络】UDP协议与TCP协议

    端口号(Port)标识了一个主机上进行通信的不同的应用程序; 在TCP/IP协议中, 用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过netstat -n查看); 服务器的同一个服务会使用多进程或者多线程的方式,对于不同的客户端请

    2024年01月25日
    浏览(56)
  • 【传输层】网络基础 -- UDP协议 | TCP协议

    端口号(Port)标识了一个主机上进行通信的不同的应用程序 在TCP/IP协议中,用 “源IP”, “源端口号”, “目的IP”, “目的端口号”, “协议号” 这样一个五元组来标识一个通信(可以通过 netstat -n 查看) 0 - 1023:知名端口号,HTTP,FTP,SSH等这些广为使用的应用层协议,他

    2024年02月09日
    浏览(49)
  • 【计算机网络】TCP协议与UDP协议详解

    文章目录 一、传输层 1、1 再次理解传输层 1、2 再次理解端口号 1、2、1 端口号范围划分 1、2、2 认识知名端口号 1、3 网络常用指令netstat 与 pidof 二、UDP协议 2、1 UDP协议的报文 2、2 UDP的特点  2、3 UDP的缓冲区 三、TCP协议 3、1 TCP协议的报文 3、2 确认应答 3、3 按序到达 3、

    2024年02月08日
    浏览(49)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包