莒南县建设局网站,天津网站制作工具,wordpress开发教程,稿定设计网站官网文章目录 前言Tcp协议段格式TCP的可靠性面向字节流应答机制超时重传流量控制滑动窗口#xff08;重要#xff09;拥塞控制延迟应答捎带应答标志位具体标志位三次握手四次挥手粘包问题TCP异常情况listen的第二个参数 前言
前面我们学习了传输层协议Udp#xff0c;今天我们一… 文章目录 前言Tcp协议段格式TCP的可靠性面向字节流应答机制超时重传流量控制滑动窗口重要拥塞控制延迟应答捎带应答标志位具体标志位三次握手四次挥手粘包问题TCP异常情况listen的第二个参数 前言
前面我们学习了传输层协议Udp今天我们一起学习TcpTcp比Udp复杂但可靠非常多的场景需要这种可靠。
Tcp协议段格式 只从格式来看Tcp就比Udp复杂许多那么Tcp的报头和有效载荷应当如何分离
首先报头前20个字节一定是固定的我们先提取前20个字节找到4位首部长度 然后首部长度 * 4 -20来查看是否有选项 最后读完选项的字节剩下的就是数据。
TCP的可靠性
大量丢包乱序重复校验失败发送缓慢网络故障都是不可靠的表现正是因为传输距离变长才会引发如此多的可靠性问题为了解决这些问题。TCP引入了应答进制。
假如C给S发送了一条数据只有当S给C了应答C才认为自己的数据已经送到了S的手里如果等待一段时间后没有收到这个应答C就会认为自己发送的数据丢失了会触发超时重传。
为了提高发送的效率多个TCP报文会同步传送这也就导致到达对端的数据没有顺序而乱序正是我们要可靠问题所以TCP报文注定是有编号的
面向字节流
应用层将数据拷贝到TCP的发送缓冲区以 uint8 为一个单位将整个发送缓冲区划分。所以发送缓冲区天然带编号数组下标。
应答机制
上面我们知道TCP需要应答和编号应答其实就是一个TCP报文中携带了ACK字段而32位序号就是我们所说的编号对端需要针对这个序号对我们做出ACK应答。
例如C端发出了32位序号为10的报文S端就要返回一个32确认编号为11的报文
发送序号当前报文的编号。 确认序号表示前面的报文已经全部收到接下来应该从这个序号开始发送了。
由于Tcp报文具有捎带应答机制即S发送ACK的时候也有想要发给C的信息所以必须设计为两个独立字段而不能复用在一起。
超时重传
数据丢失的两种可能性 1、数据半路真的丢包了 2、数据没有丢包但ACK半路丢了
第一种情况必然需要我们重传数据也就要求TCP必须能做到暂时保存这些数据以支持重传。 第二种情况可以参考其他的ACK因为如果只是ACK丢失其他ACK的确认序号不会变。
等待时间各个平台不同在linux下以500ms为基准n*500的方式动态调整。
流量控制
TCP具有接收缓冲区和发送缓冲区也是全双工的但只要是缓冲区就有大小设想一下这样的场景 C将报文送到了S但S的接收缓冲区放不下了。在这种情况下S只能丢弃掉来的报文并不做应答过一段时间C会进行重传操作。 仔细一下就会发现这样是十分低效的报文千里迢迢赶到对端主机却因为对端没法接收而被丢弃为了解决这个问题TCP报文有一个叫做16位窗口大小的字段这个字段填充自己的接收缓冲区的大小对方拿到报文时就会看到这个大小并根据此大小调整增大或减小发送数据的速度、大小。
窗口探测 双端会定期向对方发送不携带数据的TCP报文以此来询问对方的接收能力调整自己发送数据的速度和大小这个过程是双向的
滑动窗口重要
TCP协议可靠性是主要的研究问题但效率问题也是TCP需要考虑的问题。
发送方并发发送一定要在对方能够接收的前提条件下才能进行并发发送。
1、一般情况
一个发送缓冲区就被滑动窗口划分成了三个区域。
左边的区域已经发送且已经确认的数据——可以被覆盖的 中间的区域可以直接发送大小限制但尚未收到应答 右边的区域尚未发送的数据区域
滑动窗口的大小应该与与对方的接收能力有关。
1.5、如何理解滑动窗口 2、特殊情况
1、滑动窗口只能向右因为左边的数据已经没有了意义
2、变大变小本质是在调整winend取决于对方的窗口大小滑动窗口是浮动的
3、变成0说明对方不能接收数据了进行窗口探测窗口通知
4、应答也要按序到达 应答编号winstart seq 应答窗口大小winend winstart win
5、丢失问题
a、第一个丢失了 重传补发
b、中间的丢失了 向右滑动又变成了第一个丢失
c、最后一个丢失 也会变成最左侧丢失
快重传高速重发 当某一个报文丢失连续收到了三个一样的确认应答后立马进行重传。
重传的下限超时重传 重传的上限快重传
拥塞控制
如果网络出现问题TCP也进行了策略控制。
同样都是丢包丢少和丢多也是不一样的如果一直在丢包那就是网络的问题。
当大量丢包的时候发送方的发送策略是 等等再发
如果网络出现瘫痪的时候所有主机再次重传会让瘫痪的网络更难以恢复所以我们采用的策略是如果发现了网络拥塞要减少发送量。总的来说要符合以下两点要求
1、保证网络拥塞不能加重 2、在网络恢复有起色时尽快恢复网络通信
TCP引入了 慢启动 机制
发生了网络拥塞发送方要基本得知网络拥塞的严重程度必须进行网络状态的探测
拥塞窗口 需要对网络状况进行衡量——拥塞窗口
网络状态时变化的衡量网络健康状态即拥塞窗口的大小一定是变化的。
因此发送方的滑动窗口 min(16位窗口大小网络的拥塞窗口)
拥塞窗口的增长速度是指数级别的慢启动指的是前期慢后期增长速度非常快。
1、慢启动有一个阈值 2、当拥塞窗口超过这个阈值后不再指数增长而是按线性增长 3、每次超时重发的时候慢启动阈值ssthresh会变成原来的一半同时拥塞窗口置为1乘法减少
延迟应答
立即返回ACK应答返回的窗口大小可能会比较小。
给对方通告出更大的win大小对方就能在更大概率上提高传送效率。给上层更多时间来读取在这段时间尽快读取且读取更多。
捎带应答
ACK搭顺风车。
标志位
标志位的本质
一个二进制位来标识不同类型的报文
为什么要有标志位
不同的标志位提供不同的服务。
具体标志位
ACK确认应答报文可能携带数据捎带应答 SYN连接请求的报文三次握手 FIN连接断开的报文四次挥手 PSH提示对方应用层尽快将缓冲区数据取走多路转接 RST告诉对方要重新连接连接被重置了 URG按序到达但我们想插队紧急数据16位紧急指针紧急数据在有效载荷中的偏移量。紧急数据带外数据只有一个字节。下载取消案例recvfrom的MSG_OOB选项。
三次握手 1、什么是连接 一个OS内一定右多个建立好的连接OS必须要把这些连接管理起来。 维护连接是有成本的必然要消耗CPU、内存资源。 2、为什么是三次 三次握手过程由双方操作系统在TCP自主完成 connect触发连接等待完成 accept等待建立完成获取连接 对于客户端来说只要发出了最后一个ACK就认为链接已经建立好了。 对于服务端来说只有收到了最后一个ACK服务器才消耗资源构建。 因此三次握手本质在赌服务端的确收到了最后一个ACK。假如没有收到ACK两者建立认知不一致了这时候客户端再给服务端发消息服务端就会回复一个RST进行连接重置 如果两次握手只要发出SYNACK就得浪费资源构建。容易被SYN洪水攻击。注意TCP本身并不考虑解决安全问题但TCP不能出现安全漏洞因此需要规避SYN洪水。如果大于3次握手仍然解决不了最后一个ACK问题如果是偶数次握手最后一个ACK是服务器端承担风险、奇数次握手是客户端承受风险。而服务器端保存着大量的数据出现异常是必然的固而两次以及偶数握手是不妥的3次握手的好处 1、没有明显漏洞出现异常成本嫁接到客户端 2、验证双方通信信道通畅情况是验证流畅全双工的最小成本收、发 3、状态变化 SYN_SENT同步发送 SYN_RCVD同步收到 ESTABLiSH建立完成
四次挥手 四次挥手是双方建立连接断开共识的最小成本必须要双方同意都不发消息
状态变化
当客户端退出服务器端不调用close的时候服务端进入CLOSE_WAIT状态服务端进入FIN_WAIT2的状态。 一段时间后客户端的FIN_WAIT2消失服务端仍是CLOSE_WAIT状态。所以对于服务器端要关掉文件描述符
调用close后服务器端立马进入LAST_ACK状态并发送FIN给对端如果对端已经关闭在经历几次重传后服务器端也会断开连接。
主动断开的一方要进入TIME_WAIT状态此时立马想要重启会失败原因是底层连接还在正处于TIME_WAIT状态。 1、为什么要进入TIME_WAIT TCP协议规定主动断开连接的一方要等待两个MSL时间一个报文在网络里存在的最大时间 1、让网络中的报文尽快消散防止对新的连接产生影响。2、保证最后一个ACK让对方收到。对方如果没收到最后一个ACK会再发送FIN。 2、如果server不想等待 //设置地址可以复用令服务器立马重启
setsockopt(int sockfd,int level,int optname,const void* optval,socklen_t optlen)
参数
sockfd套接字
level当前在哪一层SOL_SOCKET
optnameSO_REUSEADDR | SO_REUSEPORT
optval:1
optlen:len粘包问题
TCP没有UDP里面的报文长度字段我们并不知道两个数据的边界这样的问题就是粘包问题
解决明确两个包之间的边界上层去完成。
TCP异常情况
进程终止/机器重启进程终止会释放文件描述符仍然发送FIN和正常关闭一样操作系统回收所有相关资源
机器掉电/网线断开对端认为连接还在一旦接收端有写入操作发现连接不在了就会reset服务器发送保活定时器发送端也可reset
listen的第二个参数
设置第二个参数为1连接服务器一定程度后进入SYN_RECV即已经建立好的链接只能是两个。
TCP协议需要在底层维护全连接队列最大长度为第二个参数 1
将没有连接到半连接队列时间非常断。
全连接队列不能太长也不能没有。全连接的长度不是服务器处理的长度而是一个 “排队” 的地方.
1、会消耗过多的OS资源不如给server使用 2、尾部等待太长。
