网络协议-传输层(笔记)

传输层

传输层有2个协议
TCP(Transmission Control Protocol),传输控制协议
UDP(User Datagram Protocol),用户数据报协议

在这里插入图片描述

UDP( 用户数据包协议)

UTP-数据格式

UDP是无连接的,减少了建立和释放连接的开销
UDP尽最大能力交付,不保证可靠交付
因此不需要维护一些复杂的参数,首部只有8个字节(TCP的首部至少20个字节)

在这里插入图片描述
UDP长度(Length)
占16位,首部的长度 + 数据的长度

检验和( Checksum)

检验和的计算内容:伪首部 + 首部 + 数据
伪首部:仅在计算检验和时起作用,并不会传递给网络层

在这里插入图片描述

端口( port)

UDP首部中端口是占用2字节
可以推测出端口号的取值范围是:0~65535
客户端的源端口是临时开启的随机端口
防火墙可以设置开启\关闭某些端口来提高安全性
常用命令行
netstat –an:查看被占用的端口
netstat –anb:查看被占用的端口、占用端口的应用程序
telnet 主机 端口:查看是否可以访问主机的某个端口
✓ 安装telnet:控制面板 – 程序 – 启用或关闭Windows功能 – 勾选“Telnet Client” – 确定

在这里插入图片描述

TCP(传输控制协议)

TCP-数据格式

在这里插入图片描述
1、数据偏移
占4位,取值范围是0x0101~0x1111(最小54=20,最大154=60)
乘以4就是首部长度(Header Length)首部长度是20~60字节
在这里插入图片描述

2、保留
占6位,目前全为0

在这里插入图片描述

UDP和TCP数据结构区别

在这里插入图片描述
UDP的首部中有个16位的字段(Length)记录了整个UDP报文段的长度(首部+数据)

UDP和TCP之间的细节

◼ UDP的首部中有个16位的字段记录了整个UDP报文段的长度(首部+数据)
◼ 但是,TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度,并没有字段记录TCP报文段的数据长度

◼ 分析
UDP首部中占16位的长度字段是冗余的,纯粹是为了保证首部是32bit对齐
TCP\UDP的数据长度,完全可以由IP数据包的首部推测出来
✓ 传输层的数据长度 = 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度
例子如下,0=52-20-32
说明TCP除了携带了首部,没有携带额外的数据
在这里插入图片描述

在这里插入图片描述

例子如下,201=52-20-241(正确)
在这里插入图片描述

在这里插入图片描述
wireshark会自己计算TCP的数据部分长度(TCP Sement Len)

raw-relative sequence number=同次请求的唯一标识

在这里插入图片描述

TCP-检验和(Checksum)

跟UDP一样,TCP检验和的计算内容:伪首部 + 首部 + 数据
伪首部:占用12字节,仅在计算检验和时起作用,并不会传递给网络层

在这里插入图片描述

在这里插入图片描述

TCP-标志位(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时,表明数据已经发送完毕,要求释放连接

在这里插入图片描述

TCP-序号、确认号、窗口

◼ 序号(Sequence Number)
占4字节
首先,在传输过程的每一个字节都会有一个编号
在建立连接后,序号代表:这一次传给对方的TCP数据部分的第一个字节的编号
在这里插入图片描述

◼ 确认号(Acknowledgment Number)
占4字节
在建立连接后,确认号代表:期望对方下一次传过来的TCP数据部分的第一个字节的编号
在这里插入图片描述

◼ 窗口(Window)
占2字节(16位)
这个字段有流量控制功能,用以告知对方下一次允许发送的数据大小(字节为单位)

在这里插入图片描述

TCP特点

可靠传输
停止等待ARQ协议

ARQ(Automatic Repeat–reQuest),自动重传请求
在这里插入图片描述
(a)无差错情况:A发送分组M1,发送就暂停发送,等待B的确认。B收到M1就向A发送确认。A在收到了对M1的确认后,就再发送下一个分组M2。同样,在收到B对M2的确认后,再发送M3。

(b)超时重传:B接收M1时检测出了差错,就丢弃M1。(超时重传:A只要过了一段时间仍然没有收到确认,就认为刚才发送的分组丢失了,因而重传前面发送过的分组。
在这里插入图片描述

(a)无差错情况:A发送分组M1,发送就暂停发送,等待B的确认。B收到M1就向A发送确认。A在收到了对M1的确认后,就再发送下一个分组M2。同样,在收到B对M2的确认后,再发送M3。

(b)超时重传:B接收M1时检测出了差错,就丢弃M1。(超时重传:A只要过了一段时间仍然没有收到确认,就认为刚才发送的分组丢失了,因而重传前面发送过的分组。)

在这里插入图片描述
(a)确认丢失:B所发送的对M1的确认丢失了,A在设定的超时重传时间内没有收到确认,但无法知道是自己的分组出错、丢失,或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1。假定B又收到了重传的分组M1,这时丢弃这个重复的分组M1,向A发送确认。
(b)确认迟到:传输过程中没有出现差错,但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认处理很简单:收下后丢弃。B仍会收到重复的M1,并且同样要丢弃重复的M1,并重传
确认分组。

若有个包重传了N次还是失败,会一直持续重传到成功为止么?
这个取决于系统的设置,比如有些系统,重传5次还未成功就会发送reset报文(RST)断开TCP连接
在这里插入图片描述

TCP-可靠传输-连续ARQ协议+滑动窗口协议

为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。
当使用流水线传输时,就要使用连续ARQ协议和滑动窗口协议。
在这里插入图片描述
在这里插入图片描述
◼ 如果接收窗口最多能接收4个包
但发送方只发了2个包
◼ 接收方如何确定后面还有没有2个包?
等待一定时间后没有第3个包
就会返回确认收到2个包给发送方

TCP-可靠传输 -SACK(选择性确认)

在TCP通信过程中,如果发送序列中间某个数据包丢失(比如1、2、3、4、5中的3丢失了)
TCP会通过重传最后确认的分组后续的分组(最后确认的是2,会重传3、4、5)
这样原先已经正确传输的分组也可能重复发送(比如4、5),降低了TCP性能
为改善上述情况,发展出了SACK(Selective acknowledgment,选择性确认)技术
告诉发送方哪些数据丢失,哪些数据已经提前收到
使TCP只重新发送丢失的包(比如3),不用发送后续所有的分组(比如4、5)

◼ SACK信息会放在TCP首部的选项部分
Kind:占1字节。值为5代表这是SACK选项
Length:占1字节。表明SACK选项一共占用多少字节
Left Edge:占4字节,左边界
Right Edge:占4字节,右边界

在这里插入图片描述
在这里插入图片描述
◼ 一对边界信息需要占用8字节,由于TCP首部的选项部分最多40字节,所以
SACK选项最多携带4组边界信息
SACK选项的最大占用字节数 = 4 * 8 + 2 = 34

思考一个问题
◼ 为什么选择在传输层就将数据“大卸八块”分成多个段,而不是等到网络层再分片传递给数据链路层?
因为可以提高重传的性能
需要明确的是:可靠传输是在传输层进行控制的
✓ 如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传
✓ 如果在传输层分了段,一旦出现数据丢失,只需要重传丢失的那些段即可

流量控制

◼ 如果接收方的缓存区满了,发送方还在疯狂着发送数据
接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源
所以要进行流量控制

◼ 什么是流量控制?
让发送方的发送速率不要太快,让接收方来得及接收处理

◼ 原理
通过确认报文中窗口字段来控制发送方的发送速率
发送方的发送窗口大小不能超过接收方给出窗口大小
当发送方收到接收窗口的大小为0时,发送方就会停止发送数据

流量控制-特殊情况
◼ 有一种特殊情况
一开始,接收方给发送方发送了0窗口的报文段
后面,接收方又有了一些存储空间,给发送方发送的非0窗口的报文段丢失了
发送方的发送窗口一直为零,双方陷入僵局
◼ 解决方案
当发送方收到0窗口通知时,这时发送方停止发送报文
并且同时开启一个定时器,隔一段时间就发个测试报文去询问接收方最新的窗口大小
如果接收的窗口大小还是为0,则发送方再次刷新启动定时器

◼ 拥塞控制
防止过多的数据注入到网络中
避免网络中的路由器或链路过载
◼ 拥塞控制是一个全局性的过程
涉及到所有的主机、路由器
以及与降低网络传输性能有关的所有因素
是大家共同努力的结果
◼ 相比而言,流量控制是点对点通信的控制

拥塞控制

几个缩写
ssthresh(门限值):max(cwnd/2,2)
MSS(Maximum Segment Size):每个段最大的数据部分大小
在建立连接时确定
cwnd(congestion window):拥塞窗口
rwnd(receive window):接收窗口
swnd(send window):发送窗口

发送窗口的最大值:swnd = min(cwnd, rwnd)
当rwnd < cwnd时,是接收方的接收能力限制发送窗口的最大值
当cwnd < rwnd时,则是网络的拥塞限制发送窗口的最大值

慢开始(slow start,慢启动)

在这里插入图片描述
在这里插入图片描述
cwnd的初始值比较小,然后随着数据包被接收方确认(收到一个ACK)
cwnd就成倍增长(指数级)

拥塞避免(congestion avoidance)

在这里插入图片描述
◼ ssthresh(slow start threshold):慢开始阈值,cwnd达到阈值后,以线性方式增加
◼ 拥塞避免(加法增大、以一定的斜率):拥塞窗口缓慢增大,以防止网络过早出现拥塞
◼ 乘法减小:只要网络出现拥塞,把ssthresh减为拥塞峰值的一半,同时执行慢开始算法(cwnd又恢复到初始值)
当网络出现频繁拥塞时,ssthresh值就下降的很快

快速重传(fast retransmit)

◼ 接收方
每收到一个失序的分组后就立即发出重复确认
使发送方及时知道有分组没有到达
而不要等待自己发送数据时才进行确认
◼ 发送方
只要连续收到三个重复确认(总共4个相同的确认),就应当立即重传对方尚未收到的报文段
而不必继续等待重传计时器到期后再重传

在这里插入图片描述

快速恢复(fast recovery)

◼当发送方连续收到三个重复确认,说明网络出现拥塞
就执行“乘法减小”算法,把ssthresh减为拥塞峰值的一半
◼ 与慢开始不同之处是现在不执行慢开始算法,即cwnd现在不恢复到初始值
而是把cwnd值设置为新的ssthresh值(减小后的值)
然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大

拥塞控制-慢开始+拥塞避免-快重传-快恢复

在这里插入图片描述

建立连接

连接在这里插入图片描述

在这里插入图片描述
序号-确认号
在这里插入图片描述

1、最开始建立连接的时候发送方会给一个原始的序列号(相对序列号为1)给接收端
在这里插入图片描述

在这里插入图片描述
2、接收方也返回自己的原始序列号和原始确认号给发送方在这里插入图片描述
在这里插入图片描述

3、返回确认给接收端建立连接
在这里插入图片描述
(原始数据+相对数据详解)
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
连发4个包
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
三次握手
在这里插入图片描述
CLOSED: client处于关闭状态
LISTEN: server处于监听状态,等待client连接
SYN-RCVD:表示server接受到了SYN报文,当收到client的ACK报文后,它会进入到ESTABLISHED状态
SYN-SENT:表示client已发送SYN报文,等待server的第2次握手
ESTABLISHED:表示连接已经建立

前2次握手的特点
SYN都设置为1
数据部分的长度都为0

TCP头部的长度一般是32字节
固定头部: 20字节
选项部分: 12字节

双方会交换确认一些信息
比如MSS、是否支持SACK,Window scale (窗口缩放系数)等
这些数据都放在了TCP头部的选项部分中(12字节)
在这里插入图片描述
为什么建立连接的时候,要进行3次握手? 2次不行么?
主要目的:防止server端一直等待,浪费资源
如果建立连接只需要2次握手,可能会出现的情况
假设client发出的第一个连接请求报文段,因为网络延迟,在连接释放以后的某个时间才到达server
本来这是一个早已失效的连接请求,但server收到此失效的请求后,误认为是client再次发出的一个新的连接请求
于是server就向client发出确认报文段,同意建立连接口
如果不采用"3次握手" ,那么只要server发出确认,新的连接就建立了
由于现在client并没有真正想连接服务器的意愿,因此不会理睬server的确认,也不会向server发送数据
但server却以为新的连接已经建立,并一直等待client发来数据,这样, server的很多资源就白白浪费掉了

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

如何第3次握手失败了,会怎么处理?
此时server的状态为SYN-RCVD,若等不到client的ACK,server就会重新发送SYN+ACK包
如何server多次重发SYN+ACK包都等不到client的ACK,就会发送RST包,强制关闭连接

释放连接

四次挥手过程
在这里插入图片描述
状态解读
FIN-WAIT-1:表示想主动关闭连接
向对方发送了FIN报文,进入FIN-WAIT-1状态

CLOSE-WAIT:表示等待关闭
当对方发送FIN给自己,自己会回应一个ACK报文给对方,此时进入CLOSE-WAIT状态

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等

细节

TCP/IP协议栈在设计上,允许任何一方先发起断开请求。这里演示的是client主动要求断开

client发送ACK后,需要有个TIME-WAIT阶段,等待一段时间后,再真正关闭连接
一般是等待2倍的MSL (Maximum Segment Lifetime,最大分段生存期)
MSL是TCP报文在Internet上的最长生存时间
每个具体的TCP实现都必须选择一个确定的MSL值, RFC 1122建议是2分钟
可以防止本次连接中产生的数据包误传到下一次连接中(因为本次连接中的数据包都会在2MSL时间内消失了)
如果client发送ACK后马上释放了,然后又因为网络原因, server没有收到client的ACK, server就会重发FIN口这时可能出现的情况是

  1. client没有任何响应,服务器那边会干等,甚至多次重发FIN,浪费资源
  2. client有个新的应用程序刚好分配了同一个端口号,新的应用程序收到FIN后马上开始执行断开连接的操作,本来它可能是想跟server建立连接的

疑问

为什么释放连接的时候,要进行4次挥手?
TCP是全双工模式
第1次挥手:当主机1发出FIN报文段时
表示主机1告诉主机2,主机1已经没有数据要发送了,但是,此时主机1还是可以接受来自主机2的数据
第2次挥手:当主机2返回ACK报文段时·
表示主机2已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的
第3次挥手:当主机2也发送了FIN报文段时
表示主机2告诉主机1,主机2已经没有数据要发送了第4次挥手:当主机1返回ACK报文段时.
表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接

网站+wireshark抓包分析

有时候在使用抓包工具的时候,有可能只会看到“3次“挥手
其实时将第2,3次挥手合并了
在这里插入图片描述
当server接收到client的FIN时,如果server后面也没有数据要发送给client了
这时,server就可以将第2、3次挥手合并,同时告诉client两件事
✓ 已经知道client没有数据要发
✓ server已经没有数据要发了

socket网络编程+wireshark抓包分析

在这里插入图片描述

笔记内容大部分来自于小码哥教育

  • 2
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值