06. 传输层 · UDP · TCP

已于 2023-11-17 10:24:17 修改
阅读量196 收藏 1
点赞数
分类专栏： 网络协议从入门到底层原理 文章标签： udp tcp/ip 网络 网络协议
于 2022-09-04 22:37:11 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/KeepPromise/article/details/126695575
版权

传输层 · UDP · TCP

网络协议从入门到底层原理

提示：本系列文章已经修订完毕，修改了纰漏，优化了文章结构。为了获得更好的阅读体验，请查看以下新专栏或新站点

CSDN 新专栏：
https://blog.csdn.net/keeppromise/category_12489629.html

我的个人博客（Github Page）：
https://blog.lens-shrine.top/categories/学习记录：网络协议/

网络互连模型

图01

请求过程

图02

网络分层

图03

传输层（Transport）

图04

UDP

数据格式：
图05

UDP长度（Length）

占16位：首部的长度 + 数据的长度

检验和（Checksum）

图06

端口

图07

常用命令 【实践】

netstat –an
查看被占用的端口

netstat –anb
查看被占用的端口、占用端口的应用程序

telnet 主机 端口
查看是否可以访问主机的某个端口

TCP

TCP的几个要点：

  • 可靠传输
  • 流量控制
  • 拥塞控制
  • 连接管理（建立连接、释放连接）

数据格式：
图08

首部

首部 - 序号

图12

首部 - 确认号

图13

首部 - 数据偏移

  • 占4位，取值范围是 0x0101 ~ 0x1111（5~15）
  • 数据偏移 * 4 = 首部长度（Header Length）
  • 首部长度是 20 ~ 60 字节

首部 - 保留

  • 占6位，目前全为0

小细节： 有些资料中，TCP首部的 保留(Reserved)字段 占3位，标志(Flags) 字段占9位（Wireshark中也是如此）
图09
图10

首部 - 标志位

标志位（Flags）

URG（Urgent）

  • 当 URG = 1 时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK（Acknowledgment）

  • 当 ACK = 1 时，确认号字段才有效

PSH（Push）

RST（Reset）

  • 当 RST = 1 时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接

SYN（Synchronization）

  • 当 SYN = 1、ACK = 0 时，表明这是一个建立连接的请求
  • 若对方同意建立连接，则回复 SYN = 1、ACK = 1

FIN（Finish）

  • 当 FIN = 1 时，表明数据已经发送完毕，要求释放连接

首部 - 窗口

图14

首部 - 检验和

检验和（CheckSum）
跟UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据。
伪首部：占用12字节，仅在计算检验和时起作用，并不会传递给网络层。
图11

要点 - 可靠传输

可靠传输是为了保证包的完整性，当有丢包、受到三次重复确认等情况，就会重新发包。

停止等待ARQ协议

ARQ（Automatic Repeat–reQuest），自动重传请求。
图15

图16

疑问： 若有个包重传了N次还是失败，会一直持续重传到成功为止么？

  • 这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送 reset报文（RST）断开TCP连接。 图22

连续ARQ协议 + 滑动窗口协议

图17
如果接收窗口最多能接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包？
等待一定时间后没有第3个包，就会返回确认收到2个包给发送方。

图18

SACK（选择性确定）

SACK（Selective acknowledgment，选择性确认）技术

  • 告诉发送方哪些数据丢失，哪些数据已经提前收到
  • 使TCP只重新发送丢失的包，不用发送后续所有的分组
    图19
    可靠传输图示：
    图20
    图21
    思考：
    为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层？
    图23

要点 - 流量控制

图01

流量控制 - 特殊情况
图02

流量控制图示
图03

要点 - 拥塞控制

图04

方法

图05

慢开始（slow start）

图06
图07
cwnd的初始值比较小，然后随着数据包被接收方确认（收到一个ACK），cwnd就成倍增长（指数级）

拥塞避免（congestion avoidance）

图08

快重传

图09
图10

快恢复

图11

快重传 + 快恢复

图12

发送窗口的最大值

发送窗口的最大值swnd = min(cwnd, rwnd)

  • 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值
  • 当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值

序号、确认号（详细）

图01
图02
图03
图04
图05
序号，确认号——相对：
图06
序号，确认号——原生：
图07

要点 - 建立连接

三次握手

图08
状态解读：

  • CLOSED：client处于关闭状态
  • LISTEN：server处于监听状态，等待client连接
  • SYN-RCVD：表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到 ESTABLISHED 状态
  • SYN-SENT：表示client已发送SYN报文，等待server的第2次握手
  • ESTABLISHED：表示连接已经建立

前2次握手的特点：
图09

疑问

图10

采用 “三次握手” 的办法可以防止上述现象发生
例如上述情况，client没有向 server的确认 发出确认，server由于收不到确认，就知道client并没有要求建立连接。

如果第3次握手失败了，会怎么处理？

  • 此时server的状态为 SYN-RCVD，若等不到client的 ACK，server会重新发送 SYN+ACK 包
  • 如果server多次重发 SYN+ACK 都等不到client的 ACK，就会发送 RST包，强制关闭连接

图11

要点 - 释放连接

四次挥手

图01
状态解读：

FIN-WAIT-1：表示想主动关闭连接

  • 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态

CLOSE-WAIT：表示在等待关闭

  • 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
  • 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方

FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文

CLOSING：一种比较罕见的例外状态

  • 表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
  • 如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
  • 表示双方都正在关闭连接

LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文

  • 当收到ACK报文后，即可进入CLOSED状态了

TIME-WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等 2MSL 后即可进入CLOSED状态了

  • 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态

CLOSED：关闭状态

由于有些状态的时间比较短暂，所以很难用 netstat 命令看到，比如SYN-RCVD、FIN-WAIT-1等

疑问

图02

细节

图03

图04

长连接、短链接

如果建立连接后不需要进行数据交互就会关闭，那就是短连接。
如果建立连接后需要进行数据交互以后再关闭，那就是长连接。

TCP完整流程

1.
图05
2.
图06

永别了，赛艾斯滴恩
关注
专栏目录
apache服务器的fin_wait1过多time_wait过多问题解决
风过无声
11-29 4233
转载：http://justwinit.cn/post/2536/
主机上大量端口处于FIN_WAIT1状态且无进程号
最新发布
Zdashuang的博客
02-14 1182
FIN_WAIT1状态处理
linux tcp fin wait1,Linux tcp状态 FIN_WAIT1、TIME_WAIT、ESTABLISHED
weixin_39952182的博客
05-15 535
命令：netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’显示服务器各种状态及其数量1、time_wait状态过多。原因：最可能的原因是服务器keepalive没有开，导致每次请求都要建立新的tcp连接，请求完成以后关闭，增加了很多time_wait的状态。另，keepalive可能会增加一部分内存的开销，但是问题...
TCP四次挥手和TIME_WAIT
啊浪的博客
10-06 1410
FIN_WAIT_1 : FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情...
网络分析流量FIN_WAIT_2状态解释
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
06-09 1万+
在HTTP应用中，存在一个问题，SERVER由于某种原因关闭连接，如KEEPALIVE的超时，这样，作为主动关闭的SERVER一方就会进入 FIN_WAIT2状态，但TCP/IP协议栈有个问题，FIN_WAIT2状态是没有超时的（不象TIME_WAIT状态），所以如果CLIENT不关闭，这个FIN_WAIT_2状态将保持到系统重新启动，越来越多的FIN_WAIT_2状态会致使内核crash。 出现fin_wait_2一般为客户端，如果为服务端出现，则表明是服务端主动发起的断开。 可能产生原因： 1。常连.
TCP.UDp.rar_UDP高级编程_tcp.udp
09-21
在计算机网络通信中，TCP（传输控制协议）和UDP（用户数据报协议）是两种常见的传输层协议。它们各自有着不同的特性和应用场景，对于开发者来说，理解和掌握这两者的高级编程技巧至关重要。本资料主要探讨TCP与UDP在...
5. 传输层(UDP)1
08-03
传输层的UDP（User Datagram Protocol）协议是一种无连接、不可靠的数据传输协议，与TCP（Transmission Control Protocol）相比，它的设计更为简洁，但也因此在某些方面具有独特的优势和应用场景。 UDP报文结构非常...
UDP.rar_UDP_tcp类
09-22
UDP（User Datagram Protocol）和TCP（Transmission Control Protocol）是网络通信中的两种主要传输协议，它们在互联网中扮演着至关重要的角色。在这个“UDP.rar_UDP_tcp类”压缩包中，我们看到有四个文件：C_UDP....
TCP.UDP.rar_C++TCP UDP通信_TCP UDp_UDP TCP_UDP 通信协议C++_网络通信 UDP
09-14
TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是两种最常用的传输层协议，它们各有特点，适用于不同的应用场景。本篇将深入探讨C++中如何实现TCP与UDP的通信，并结合提供的资源进行详细解释...
UDP-TCP.rar_TCP UDp_TCP-UDP_tcp/udp socket_网络UDP TCP
09-20
TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是互联网协议族中最核心的两种传输层协议，它们分别提供了面向连接和无连接的服务。 TCP是一种面向连接的、可靠的协议，它在数据传输前会建立...
TCP状态迁移
lanbing598235681的专栏
10-18 467
TCP状态迁移 原文链接   http://blog.chinaunix.net/space.php?uid=11988184&do=blog&cuid=2337427 大家对netstat -a命令很熟悉吧，但是，你有没有注意到STATE一栏呢，基本上显示着esta
09.TCP_02_流量控制_拥塞控制
山兔的博客
10-12 442
TCP—流量控制 ◼ 如果接收方的缓存区满了，发送方还在疯狂发送着数据 接收方只能把收到的数据包丢掉，大量的丢包会极大的浪费网络资源，还要在重传 所以要进行流量控制，由缓存区告诉对方自己接收的流量大小 ◼ 什么是流量控制？ 让发送方的发送速率不要太快，让接收方来得及接收处理 ◼ 原理 通过确认报文中窗口字段来控制发送方的发送速率 发送方的发送窗口大小不能超过接收方给出窗口大小 当发送方收到接收窗口的大小为0时，发送方就会停止发送数据 一开始接收方会告诉发送方的自己的接收窗口大小，窗口大小不是固定
服务器主动发送fin信号,tcp 服务器向客户端发送FIN
weixin_39923806的博客
08-13 1575
tcp 服务器向客户端发送FIN 内容精选换一换ELB的常见异常返回码有400、403、502、504等。若遇到这些返回码建议您先直接访问后端云服务器，查看是否是后端云服务器的异常。若后端云服务器响应正常，请参考表1排查处理。如果仍无法解决，请联系客服人员继续排查。浏览器发送邮件：在使用浏览器登录邮箱时直接使用HTTP协议，其端口号默认为80，邮件服务器之间还是使用邮件发送协议：SMTP协议。通过...
转 FIN_WAIT_2 tcp状态多原因剖析和解决
热门推荐
fei33423的专栏
03-14 2万+
a.客户端状态迁移 CLOSED->SYN_SENT->ESTABLISHED （ps：主动结束连接）->FIN_WAIT_1->FIN_WAIT_2 （如果另一方程序健壮，会发送fin过来 ）->TIME_WAIT->CLOSED b. 服务器状态迁移CLOSED->LISTEN->SYN收到 ->ESTABLISHED->CLOSE_WAIT（如果本程序健壮，会发送fin给另一方 ）->
18.6.3 FIN_WAIT_2 状态
zhaoyangjian724的专栏
02-24 431
18.6.3 FIN_WAIT_2 状态 在FIN_WAIT_2 状态我们已经发出了FIN,并且另一端也对它进行确认。除非我们在实行半关闭, 否则将等待另一端的应用层意识到它已收到一个文件结束符说明 这意味着我们这端可能永远保持这个状态,另一端也将处于CLOSE_WAIT状态, 并一直保持这个状态直到应用层决定进行关闭 tcpdump -i eth1 '((tcp) and ((...
linux tcp fin wait1,关于FIN_WAIT1
weixin_32104797的博客
05-15 979
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况：TCP Close看图可知，主动关闭的一方发出 FIN，同时进入 FIN_WAIT1 状态，被动关闭的一方响应 ACK，从而使主动关闭的一方迁移至 FIN_WAIT2 状态，接着被...
6、FIN-WAIT-1
zhaoyangjian724的专栏
03-27 566
6、FIN-WAIT-1 主动关闭的一方发送了 FIN 包，等待对端回复 ACK 时进入FIN-WAIT-1状态。 客户端: node2:/root#netstat -na | grep 8080 tcp 0 1 192.168.137.3:56713 192.168.137.2:8080 FIN_WAIT1 模拟拒绝 服...
tcp滑动窗口大小设置_TCP传输协议如何进行流量控制？
weixin_39966130的博客
12-10 3898
TCP流量控制，简单来说就是让数据传输端传输的速率不要太快，让数据接收端来得及接收，利用滑动窗口机制可以很方便的在TCP连接上实现对数据传输端的流量控制。TCP的窗口单位是字节，不是报文段，数据传输端的发送窗口不能超过接收端给出的接收窗口的数值，流量控制的机制是控制丢包率，主要目的：让数据传输端了解数据接收端当前的接收能力，可灵活调整传输速率。流量控制机制图如下图所示：滑动窗口：TCP采用大小可变...
tcp抓包返回fin_网络抓包简介及案例应用介绍
weixin_39682673的博客
12-05 2051
基础知识在庞大的系统中，出现问题一般是根据日志来定位问题。但是很多系统日志比较模糊，没有明确什么地方有问题。这个时候用网络抓包就能很清晰的看到什么组件没用返回，或者返回了什么信息，比日志更可靠。我们一般通过抓包来定位系统的问题。这里涉及到一些抓包相关的基础知识。OSI七层模型OSI7层模型定义计算机内部通信的标准。OSI七层模型，OSI为(Open System interconnect...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值