传输层中TCP和UDP

47 篇文章 0 订阅
21 篇文章 0 订阅

TCP协议介绍(传输层)

TCP(Transmisson Control Protocol)、(传输控制协议):是面向连接的、可靠的进程到进程通信协议。TCP提供双工服务,即数据可在同一时间双向传输,每一个TCP都有发送缓存和接受缓存,用来临时存放数据。

TCP报文格式

TCP将若干字节构成一个分组,叫包文段(Sement)
TCP报文段封装在IP数据报中
在这里插入图片描述
TCP报文的首部长度20~60个字节、内容如下
在这里插入图片描述
**源端口号:**为发送方进程对应的端口好。
**目标端口号:**对应的是接受端的进程,接受端接受到数据段后,根据这个端口号来确定把数据送给那个应用的进程。
序号当TCP从进程接受数据字节时,就把他们存储在发送缓存中,并对每一个字节进行编号。当数据到达目的后,接收端会按照这个序号把数据重新排列,保证数据的正确性。
**确认号:**确认号是对发送端的确认信息,用它来告诉发送端这个序列号之前的数据段都已经收到
**首部长度:**用它可以确定首部数据结构的字节长度。
**保留:**这部分保留位作为今后扩展功能用。
**URG:**紧急指针有效位。
**ACK:**只有当ACK=1时,确认序列号字段才有效;当ACK=0时,确认序列号字段无效
**PSH:**标志位位1时要求接收方尽快将数据段送达应用层。
**RST:**当RST值为1时通知从新建立TCP连接。
**SYN:**同步序列号,TCP需要建立连接时将这个值设为1。
**FIN:**发送端完成发送任务,当TCP完成数据传输需要断开连接时,提出断开连接的一方将这个值设为1。
**窗口值:**说明本地可接收数据端的数目,这个值的大小是可变的
**校验和:**要来做差错控制。若两次的校验和一致,这说明数据基本是正确的,否者将认为数据以损坏,接受端将丢弃数据。
**紧急指针:**和URG配合使用,当URG=1时有效。
**选项:**在TCP首部可以有多达40字节的可选信息。

三次握手

1、第一次握手:客户端给服务器发送一个 SYN 报文。
2、第二次握手:服务器收到 SYN 报文之后,会应答一个 SYN+ACK 报文。
3、第三次握手:客户端收到 SYN+ACK 报文之后,会回应一个 ACK 报文。
4、服务器收到 ACK 报文之后,三次握手建立完成。
在这里插入图片描述

为什么三次握手不能两次进行连接?

第一次握手:客户端发送网络包,服务端收到了。
这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
第二次握手:服务端发包,客户端收到了。
这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手:客户端发包,服务端收到了。
这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

四次挥手

1、第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

2、第二次握手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态。

3、第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

4、第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

5、服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。
在这里插入图片描述

为什么断开连接是四次挥手不是三次挥手?

ack是为了让对方闭嘴。结束,1)A不停的说,我想结束,不再发了。2)B收到后,但是还有数据没处理完,就发ack让A闭嘴。等我处理完再说。3)B终于处理完了,不停对A说,满足你结束吧。4)A
知道B要结束了,给B说,可以闭嘴了,我结束B收到结束,不再发送确认,进入关闭态
网络的可靠性不可预知,当服务端发起第三次挥手,进入 LAST-ACK 后,它需要等一个反馈,即客户端接收到了自己的消息,而不是在传输过程中丢了。这就是需要第四次握手的原因。当然,假设不需要第四次握手,第三次握手后,服务端就直接 CLOSED 了,那这个第三次握手的报文如果客户端没收到, 对于客户端来说,就以为服务端的数据还没传完,就会一直等待在 FIN-WAIT-2 这个阶段。因为第三次握手是服务端发送 FIN报文的。TCP 是一种可靠的传输层协议,这是设计上的原则

如果已经建立链接,但是客户端突然出现了故障应该怎么办?

TCP还设有一个保活计时器Q,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时问通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。

UDP协议

UDP是一个无连接、不保证可靠性的传输层协议,也就是说发送端不关心发送的数据是否到达目标主机、数据是否出错。

UDP首部报文格式

在这里插入图片描述
**源端口号:**用来标识数据发送端的进程
**目的端口号:**用来标识数据接受端的进程
**UDP长度:**用来指出UDP的总长度,为首部加上数据。
**校验和:**用来完成对UDP数据的差错校验,这是UDP提供的唯一可靠机制。

总结

主要学习了TCP和UDP协议
TCP和UDP报文格式
三次握手四次挥手

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

搞什么滚去学习

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值