【TCP/IP】TCP/IP协议栈学习笔记

最新推荐文章于 2023-03-30 10:12:33 发布

熠熠微光

最新推荐文章于 2023-03-30 10:12:33 发布

阅读量914

点赞数

分类专栏： TCP/IP

本文链接：https://blog.csdn.net/Frederick_Fung/article/details/107226348

版权

TCP/IP 专栏收录该内容

4 篇文章 1 订阅

订阅专栏

TCP/IP协议栈

在这里插入图片描述

其实一个标准的以太网数据帧大小是：1518，头信息有14字节，尾部校验和FCS占了4字节，所以真正留给上层协议传输数据的大小就是：1518 - 14 - 4 = 1500，至于为什么是1518，详见另一篇文章：MTU学习笔记

IP协议头

在这里插入图片描述

Version：版本号
IHL：IP Header Length，IP头的长度
Type of Service：服务类型
Total Length：总长度，减去IP头的长度就等于数据的大小
Identification：拆包组装包的身份标识
Flags：三个位，一位保留，一位表示拆包，另一位表示不拆包
Fragment Offset：表示拆包之后的偏移量
Time to Live：TTL，路由的跳数，可用于NAT检测
Protocol：IP协议存储的协议类型
Header Checksum：校验码
Source Address：源地址
Destination Address：目的地址
Options：一些设置
Padding：保证32位的字节对齐

Tips：

以太网的最大传输单元（Maximum Transmission Unit）是1500字节
可通过ICMP查询最大传输单元，它通过设置IP层的Flags字段的DF，将这一比特置1，IP层将不对数据报进行分片
获得MTU的好处是传输过程中不拆包，提高传输效率，以接近MTU的方式去传输包
源地址和目的地址是IP层
端口号是指应用

参考：https://www.cnblogs.com/liquan2005/p/9113369.html

TCP协议头

在这里插入图片描述

Source Port：源端口号
Destination Port：目的端口号
Sequence Number：检查是否丢包，序列号是按字节来增长的，而不是按包，保证数据的有序性
Acknowledge Number：接收应答，保证数据的可靠性
Data Offset：数据偏移量
Reserved：保留字
URG：紧急数据标识
ACK：确认消息
PSH：发送的报文是负载数据就置1
RST：复位标记
SYN：三次握手用的
FIN：四次挥手用的
Window：窗口数，规定一次能发多少个包
Checksum：校验码
Urgent Pointer：紧急指针，与URG相匹配
Options：一些选项，比如可以传输的最大报文大小，长度不确定
Padding：保证32位字节对齐
data：真正的数据段

Tips：

在TCP中，数据不是按包排序的，而是按字节排。每个包的Seq Number代表的是发送字节的其实序号
发送的第一个包的初始序号是随机的，在创建连接的三次握手过程中交换
在TCP中，Ack Number代表的是希望对方发送数据的起始位置。例如，A向B发送了一个数据包，其Seq Number为1000，其大小为1000字节，则B收到该包后，返回的Ack Number为2001

四次挥手之WAIT_TIME

哪边主动断开连接，哪边就处于WAIT_TIME，等待的最大时常就是2倍MSL（Maximum Segment Lifetime），WAIT_TIME避免不了，（产生它的原因=它的作用）是为了确保ack消息发送给服务端，实现TCP全双工连接的可靠释放，和避免这条连接线路在未被释放的前提下建立新的连接，所以服务端没有收到ACK，在超时后就会一直发送FIN消息。若服务端处于WAIT_TIME状态并重启后发现所有端口号被占用，则可设置Reserved，这样就可以绑定端口号

参考：https://blog.csdn.net/u013616945/article/details/77510925

TCP协议流程

在这里插入图片描述

TCP ACK机制

TCP保证了有序性（Sequence）、可靠性（ACK机制）

确认应答

在这里插入图片描述

超时重传

在这里插入图片描述

滑动窗口

相当于一块缓冲区，发送端的窗口大小得和接收端的大小一致，发送端不必在每个数据包发送过去都等待确认，可以把滑动窗口区域内的所有数据包发送过去后再一次性等待确认，但是窗口内的数据若还没被确认则不能滑动
在这里插入图片描述

Delay ACK

有了滑动窗口后，如右图所示，有一个定时器，在这个定时器周期内，服务端不用回复，在周期结束后回复，这样便更高效

在这里插入图片描述

Data ACK

win：窗口大小
MSS：最大报文大小

握手阶段是双方互相确认信息传输大小

在这里插入图片描述

UDP协议

在这里插入图片描述

UDP协议的结构简单，它对于数据没有添加Sequence等一系列数据头，所以它的特点是十分高效，但同时因为它缺少了Seq和ACK机制，所以它的传输并不可靠，适合于实时通讯

RTP协议头

在这里插入图片描述

一般用在UDP这种实时传输协议上，也可以运用在TCP上，但这样就不属于实时传输协议了

sequence number：RTP的序列号是根据包来算的，比如第1个包的序列号是1，第2个包的序列号就是2，而TCP是流式的，序列号根据字节来算

timestamp：时间戳，当一块数据，最大传输单元承载不了，需要分成多个RTP包传输时，为了能够与其他数据块区分，便对同一块数据的不同包设置相同的时间戳

SSRC：全称synchronization source identifier，作为发送源的唯一标识，但在多方通讯时，标识也可能重合，这时可以通过协商重新分配SSRC

CSRC：全称contributing source identifiers，记录多路混音形成一路的音频流的标识，以备多个共享者和消费者使用，最多记录15个源，可为0

PT：payload type，不同音频和视频的格式都有不同的PT，如h264的放在一起，vp8的放在一起，用PT做区分

M：Mark，标记，不同的媒体中Mark不同，视频中mark为1则代表一帧的结束，音频为1则代表起始

CC：CSRC Count，CSRC的个数（后面是动态变化的）

X：扩展位，里面是TLV格式，如果X=1，则在RTP报头后跟有一个扩展报头

P：padding，填充位，RTP数据需要对齐（4个字节或8个字节），若数据位是奇数，则要用P来补齐

V：version，版本号，当前版本号为2

参考：https://www.cnblogs.com/qingquan/archive/2011/07/28/2120440.html

RTP包的使用

RTP可以传输音频或视频，对于音频包来说，它是连续的，所以包也不大；对于视频包来说，尤其是关键帧，一般是几十个包组成一个帧，所以它要将一个关键帧拆成很多个RTP包，最后再组合起来

在这里插入图片描述

如图所示，客户端向服务端发送数据时，接收方有一个循环队列，用于存放接收的RTP包，当RTO数据包能够组成一帧时便推出去。当然RTP包也不是按Sequence顺序入队的，它有可能延迟、乱序、丢包，如107包比105包先到达，107便插入107的位置。当一帧数据缺少RTP包并且超时后，便会丢弃掉该帧。同一组帧的RTP包的timestamp相同

重要的两个字段：Sequence Number、time stamp

RTCP协议

RTCP是RTP的控制协议，它主要控制着网络拥塞、丢包、发送了多少包或接收了多少包等。发送端给接收端发送RTP数据包，接收端会给发送端反馈RTCP数据包，接收端接收到以后并解析数据，就可以计算出当前的网络带宽、传输流量是否到达瓶颈等等

RTCP包

下图是RTCP包在整个以太网帧中所处的位置

在这里插入图片描述

RTCP Header

在这里插入图片描述

Version：版本号

P：填充位，1表示它自己，2表示除了它自己再往前找1个，以此类推

RC：RTCP Count，与后面的类型相关，代表数据包个数

PT：Payload Type，代表控制类型，表示干什么用的

Length：包的长度（包括头），Data的长度为（N-1）*4个字节

Data：数据内容

RTCP Type

在这里插入图片描述
SR：发送端的记录，包括发送信息、丢包信息等
RR：接收端的记录，包括接收信息、丢包信息等
SDES：SSRC发生冲突时，保证数据流换源后，对方还能找到相同的源
BYE：关闭传输
APP：应用层自己定义的数据报

在这里插入图片描述

FIR：新用户加入或者网络断连后重新加入，请求一个新的I帧，若不请求假设接收到的是B帧、P帧，直到下一个I帧出现之前都会出现花屏的现象。现已废弃

NACK：16位，若其中第n位置1则表示从当前Sequence起往后第n位的RTP数据包丢失。现已废弃

RTPFB：RTP Feedback，反馈包分成三类，第一类是传输层的反馈包，主要用于RTP数据的控制；第二类是payload的反馈包，是对编解码器的反馈；第三类是应用层的反馈包，对于205来说它就是传输层的反馈包

PSFB：对编解码器的控制

RTCP SR

在这里插入图片描述

Header

RTCP SR的Header部分与RTCP的Header相比，多了一个SSRC，接收端在收到这个报文后便可以知道是谁发送的这个SR报文

sender info

记录了发送者发送了多少报文

NTP timestamp：64位，网络时间戳，同一个用户共享的音视频流通过它来同步

RTP timestamp：32位，与RTP包时间戳一致

SPC：32位，发送的包数

SOC：32位，发送的数据量

在这里插入图片描述

Receiver report block

作为多方通讯的一方，有可能接收到好几路音视频流，对于每一个用户来说，最少有两路，音频和视频流

音频流有一个SSRC，视频流会有另一个SSRC

SSRC：32位，接收到的每个媒体源

fraction lost：8位，上一次报告之后从SSRC_n来包的丢包率

cumulative number of packets lsot：24位，从接收开始丢包的总和，迟到包不算丢包，重传有可能导致负数

sequence number：低16位表示收到的最大seq，高16位表示seq循环次数

jitter：RTP包到达时间间隔的统计方差，用来判断延迟

LSR：32位，NTP时间戳的中间32位

DLSR：记录接收SR的时间与发送SR的时间差

在这里插入图片描述

RTCP RR

与SR的区别：少了sender information

在这里插入图片描述

RTCP SDES

与SR、RR不同是，前者header中是RC：report count，这里是 SC：source count

在这里插入图片描述

SDES item

典型的TLV类型，Type Length Value

描述数据部分可用的字段：

CNAME：CNAME与SSRC对应，CNAME作为源的唯一标识

在这里插入图片描述

RTCP BYE

SC：SSRC的个数

可以一次给多个SSRC发送BYE

Length：8位长度

reason：3个字节+后面的可变长度位（由Length控制）

在这里插入图片描述

RTCP APP

ST：5位，自定义的子类型

name：自定义的名字

data：报文发送的数据

在这里插入图片描述

RTCP FB

1、传输层的FB：RTPFB，对传输层的控制，如NACK

NACK：丢包重传的请求
TMMBR：最大媒体流比特率请求
TMMBN：最大媒体流比特率请求的响应

2、负载层的FB：PsFB，对负载层的控制（编解码器），如PLI

PLI：图片丢失标识
SLI：如h264视频帧的slice丢失标识
RPSI：B帧丢失的标识
FIR：请求IDR帧
TSTR：空间时间交换的请求
TSTN：空间时间交换的请求的响应

3、应用层的FB：应用层自己识别，一般被认为是一种特殊的PsFB

RTCP FB Header

FMT：格式，子类型

PT：payload type，包的类型

Length：整个包的长度

SSRC of packet sender：发送包的源是谁

SSRC of media source：接受包的源是谁

在这里插入图片描述

熠熠微光

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
【TCP/IP】TCP/IP协议栈学习笔记

Version：版本号IHL：IP Header Length，IP头的长度Type of Service：Total Length：总长度，减去IP头的长度就等于数据的大小Identification：拆包组装包的身份标识Flags：三个位，一位保留，一位表示拆包，另一位表示不拆包，为了探测最大传输单元的时候可以不拆包Fragment Offset：表示拆包之后的偏移量Time to Live：TTL，路由的跳数，可用于NAT检测Protocol：IP协议存储的协议类型Header..
复制链接

扫一扫