tcp传输

tcp传输特性:

面向链接,可靠性,面向字节流

链接管理:

tcp三次握手

第一次client向server发送SYN建立连接 //测试client向server通道是否连通

第二次server向client发送ACK确认应答同时发送SYN //client向server连通,测试server向client通 道是否连通

第三次client向server发送ACK确认应答(此时可以携带数据) //server向client连通

四次挥手

第一次client向server发送FIN关闭连接(此时client进入time_wait状态,此状态可以对ACK,FIN进行简单处理) // client向server发送通道请求

第二次server向client发送ACK确认应答 //server收到了client断开连接的请求

第三次server向client发送FIN关闭连接(此时server进入last_ack状态,此状态可以对ACK进行简单处理) //server向client发送通道关闭请求

第四次client向server发送确认应答 // server向client的通道彻底关闭;在进行2MSL(报文最大存活时间)等待,期间会对残留数据进行接受并丢弃,防止影响下一次连接,等待完成后client也彻底关闭

超时重传:

超过一个规定的时间就会重新发送数据

快重传:

收到3个重复的ACK就会重新发送数据

滑动窗口:

滑动窗口是发送队列维护的结构,使得窗口左边的是已经发送的数据,窗口是准备发送的数据,窗口外是未发送的数据

滑动窗口配合序列号一起使用,接受端收到数据会返回一个序列号保证在该序列号之前的数据全部都收到了,采用滑动窗口可以大大提高数据传输的效率

接收端未收到数据的情况下会怎么样?

接收端如果没有收到数据会一直等待,什么也不做;发送端在规定时间内没有收到接收端的ACK回应会触发超时重传

接收端收到数据,但是中间缺少一部分?

在接收端收到的数据不是下一个所期望的数据(比如发送端发送了1,2,3,4这些数据,接受端收到了1,3,4)时就会向发送端重复的ACK,当发送端连续收到3个重复的ACK时就会触发快重传,重新发送数据

滑动窗口大小由接收端允许接收的最大字节和拥塞窗口决定,取较小值

流量控制:

http协议中有一个字段是窗口大小,当接收端返回ACK是会告诉发送端自己当前接收缓冲区还剩多大,发送端会根据这个值来对发送端的窗口大小进行调整,如此就实现了流量控制

拥塞控制:

在我们传输数据时不只只就我们一台主机在进行网络传输,那么就会出现有时网络环境是空闲的,有时是繁忙的,在网络空闲时应该加大传输,在繁忙时应减少传输

由此引入了拥塞阈值和拥塞窗口,拥塞窗口遵循"慢启动,快增长"(为什么?在我们刚开使传输数据时并不知道网络环境是怎么样的,所以先发送少量数据进行试探,后面在快速提高发送量,直到发送失败)

拥塞阈值初始值为接受端窗口的大小,拥塞窗口为1,在拥塞窗口小于拥塞阈值时会指数增长,大于拥塞阈值会线性增长,在触发超时重传后拥塞阈值会变为原来的一半,拥塞窗口变为1。

捎带应答:

捎带应答就是将ACK应答在发送数据携带ACK

延迟应答;

延迟应答就是在收到数据后不立刻返回应答,而是在等待一段时间。为什么?因为在收到这个应答后可能在很短的时间内就将应答处理了,此时就可以返回一个更大的窗口,提高传输流量

延迟应答有以下两种:

时间限制:一般每隔200ms

数量限制:一般每隔两个包

字节流:

发送数据不需要是一个完整的数据,发送的字节太长会拆成多个tcp包发送,发送的字节太少会将多个数据合并成一个tcp包发送,所以用字节流传输数据需要设置格式。

相关推荐
不做菜鸟的网工2 天前
BGP特性
网络协议
AlfredZhao2 天前
生产环境里,为什么不建议把普通端口直接暴露到公网?
linux·https·443·80
MrSYJ2 天前
TCP协议理解
后端·tcp/ip
戴为沐3 天前
Linux内存扩容指南
linux
zylyehuo3 天前
Linux 彻底且安全地删除文件
linux
明月_清风4 天前
开发者网络概念全扫盲:一篇搞定
后端·网络协议
刘马想放假4 天前
Modbus 全栈技术解析:TCP、RTU、ASCII、RTU over TCP
数据结构·网络协议
用户805533698034 天前
主线 U-Boot 上 RK3506:和闭源 rkbin 拔河的三个隐性契约
linux·嵌入式
用户034095297914 天前
linux fcitx 5 雾凇拼音 设置在中文输入法下仍然输入英文标点
linux
王二端茶倒水5 天前
一套可落地的无线运营方案,不能只管 AP,还要管用户、计费和运维
网络协议