TCP与UDP的原理

传输协议的作用是,给应用层程序提供数据传输的通道。

TCP(传输控制协议)它是面向连接的,可靠的传输层协议。传输速率比UDP慢。

TCP的报文格式:

 

源端口及目的端口表是:从那个进程来到哪个进程去。

序列号表示这个数据是全体数据的第几个字节开始的。

这里的ACK确认号码表示已经收到了确认号之前的数据了,希望下一个序列号码是从这个ACK号码开始。标志位ack=1时有效。

偏移字节(首部长度)表示IP头部的大小。

6个标志位:URG置1表示紧急指针有效

ACK:置1表示已收到发送的报文

PSH:置1表示立即此报文从缓冲区中取出

RST:置1处理异常连接,表示应当重新建立连接

SYN:置1标识请求建立连接,带SYN的报文都称为同步报文。

FIN:置1表示将要断开连接了,称为结束报文。

窗口大小:用来做流量控制,用来传递服务器的窗口有多大。

校验和:用来做循环冗余校验来检验数据的完整性。

紧急指针:用来指向需要紧急处理的报文,URG标志位需为1.

UDP

用户数据协议:无连接,不可靠:没有重传机制和确认机制。但是传输的速率快。

报文格式:

 数据包长度:顾名思义表示整个数据包的长度。

校验值:如果校验和出错会直接丢弃报文。

 

tcp三次握手

为什么建立的是三次握手而不是两次或者四次呢?

原因1:tcp要确保双方的收发能力,如果只有两次握手不能确定客户端的接收能力。

原因2:如果进行两次连接,客户端没有变化任然需要服务器应答后才进入established,而服务端这需要收到连接请求就进入了established。这样的话,当客户端发送第一个请求报文但是因为种种原因,没有到达服务端,此时客户端发送第二个请求报文到服务端建立连接并且完成数据传输。此时第一个报文才发送到服务端。而此时客户端已经closed了那么会会造成服务端的资源浪费。

第一次握手客户端发送SYN报文,随机产生一个序列号x。

第二次握手服务端发送SYN,ACK报文,随机产生一个序列号y,发送确认序列号x+1。

第三次握手客户端发送ACK报文以及确认序列号。

如果第三次握手失败:

服务端会根据重传机制等待3,6,12秒后重新发送SYN与ACK报文,以便客户端重新进行第三次握手。

客户端在第三次握手失败,客户端是感知不到的,当他发送数据的时候服务端会发送一个RST标志位的报文,让客户端感知连接发生了错误。

四次挥手:

 第一次挥手:客户端向服务端发送FIN,序列号为u的报文请求断开连接。

第二次挥手:服务端回复ACK,序列号为v,确认序号为u+1的报文表示收到。

但是此时服务端还没有处理完数据。

第三次挥手:服务端处理完数据后,发送FIN,ACK,序列号为w,确认序号为u+1的报文

表示可以断开连接了。

第四次挥手:客户端向服务端发送ACK,序列号为u+1,确认序号为w+1的报文。此时服务端关闭连接。但是客户端还要等2MSL(两个最大报文生存时间)才关闭。

第四次挥手失败:服务端因为重传机制没有等到第四次挥手后便会重新第三次挥手但是如果此时已经过了2MSL后,客户端已经关闭了连接,此时服务端将一直发送第三次挥手。、

 但是tcp有保活机制,但是一般保活机制比较长默认2小时没有收到tcp数据,就会进行检测,检测间隔75秒。检测数次无响应后关闭tcp连接。

第二次挥手:注意这里服务端不会因为重传机制重新发送第二次挥手,它之后是直接发送第三次挥手的,客户端这里,如果收不到第二次挥手就无法进入FIN_WAIT_2,就无法接收第三次挥手,只能重新进行第一次挥手。

 

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

末知因素

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

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

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

打赏作者

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

抵扣说明:

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

余额充值