做百度推广网站咱们做,湖南纯手工seo电话,销售crm,重庆网站建设师一、TCP协议格式 我们看到报头固定有20字节#xff0c;最后选项大小不固定。
4位首部长度#xff08;二进制0000 ~ 1111#xff0c;十进制范围[0, 15]#xff09;单位是4字节#xff08;存放字节大小范围[0, 60]#xff09;包括了20字节固定长度 选项长度。若选项大小为…一、TCP协议格式 我们看到报头固定有20字节最后选项大小不固定。
4位首部长度二进制0000 ~ 1111十进制范围[0, 15]单位是4字节存放字节大小范围[0, 60]包括了20字节固定长度 选项长度。若选项大小为0四位首部长度是5即0101用于解包。
二、TCP各种机制
1、确认应答机制
保证双方请求发送可靠性。 发送方和接收方不一定就是 client 和 server 身份可以互换上图举例。
只要 client 收到应答就能保证上次 client 发送的请求 server 一定接收到了这是保证了从 client 到 server 的数据发送可靠性。但是我们不能对应答再次应答来保证从 server 到 client 数据发送的可靠性因为这样会死循环所以一般不对应答进行处理。
可靠性不是TCP协议保证每一个请求都能让发送方收到应答而是能确认接收方是否得到了请求如果得到发送方收到应答没有就是发送方没收到应答。
TCP通信模式
首先由于应用层会有发送缓冲区和接收缓冲区来进行通信Linux中把缓冲区以字节为单位逻辑上看成是数组数字就是数组的下标序号与确认序号就是这样的缓冲区中的数组下标。 2、超时重传机制
由确认应答机制可以知道我收到了 ACK 就说明对方一定收到了数据经过一段时间我没有收到 ACKTCP协议规定我认为对方没有收到数据我要补发数据。
没有收到 ACK 两种情况 那么经过多长时间进行数据补发呢与网络相关Linux 中第一次超时0.5s第二次超时1s第三次超时2s第一次超时4s...重复一定次数还没有收到就关闭不传了。
3、连接管理机制
正常情况下三次握手建立连接四次挥手断开连接。
1三次握手建立连接
标记位 SYN 表示申请建立连接
标记为 RST 表示要再次建立连接 我们看到最后一次服务器没有对 ACK 进行应答实际上就算连接在最后一步出现问题导致没有连接成功客户端在发起 ACK 之后就认为连接已经建立此时对服务器发送请求时服务器发现没有连接成功就会返回 RST客户端看到后就知道没有建立连接重新三次握手建立连接。
2四次挥手断开连接 第一次挥手表示客户端向服务器发送的数据已经发完之后客户端不会主动发消息给服务器但由于没有第二次挥手服务器还可以继续给客户端发消息客户端也必须 ACK 应答但应用层已经关闭只能发 ACK 应答报头。
所以允许客户端还要收到服务器的消息就只能关闭套接字的写端。
用函数 int shutdown(int sockfd, int how) how中的选项 SHUT_WR 关闭写端。
3建立连接为什么要三次握手
网络中有许多连接为了管理连接就要先描述再组织连接就是一个结构体既要有空间存储也要有时间来进行属性更新。所以三次握手也是在维护双方的连接结构体。
而且三次握手要有三次才能建立连接对抗 SYN 洪水效果好。
原因
a、验证全双工即保证双方网络连通性用最小的次数验证。
b、建立双方通信共识客户端发送 SYN 说明客户端想连接服务器服务器也发 SYN 说明服务器想连接客户端。
c、协商双方接受能力在 ACK 应答报头中会带有16位窗口大小这就是说当前接受缓冲区剩余量用于为下一次数据发送进行发送量的确定。
4四次挥手中状态含义
服务器 CLOSE_WAIT 状态客户端已经退出服务器知晓但是还不能立即关闭自己的 connfd
客户端 TIME_WAIT 状态TCP规定处于 TIME_WAIT 状态下在 2 * MSLmaximum segment lifetime 报文最大生存时间 时间内不能再次监听同一个端口。
主动断开连接的一方最终会进入 TIME_WAIT 状态。
那如何不用等就可以重新监听端口呢
int setsockopt(int sockfd, int level, int optname, void* optval, socklen_t* optlen)
level所在层SOL_SOCKET
optname选项名字SO_REUSEADDR重新使用地址
optval选项值int opt 1
optlen选项大小sizeof opt
函数作用是允许创建端口号相同但IP地址不同的 socket 描述符不用等就可以连接相同端口。
为什么要等 2MSL 时间要有 TIME_WAIT ?
a、保证两个朝向尚未接受或迟到的报文在 2MSL 时间内被接受后丢弃因为已经是超时报文如果没有 TIME_WAIT立即建立相同的连接就会接收到之前的旧数据导致数据错误。
b、同时也保证四次挥手最后的 ACK 服务器能就收到要是没有 TIME_WAIT客户端立即退出ACK 传递出错服务器再次向客户端发送 FIN 时客户端退出就会导致错误。
5连接管理总流程 4、流量控制
发送方会根据接收方的接收缓冲区剩余空间来动态调整发送速度。
所以接收方可以在 ACK 应答中的16窗口大小填写缓冲区剩余量来告知发送方。 窗口探测主机A给主机B发空报头B必须 ACK 应答带上窗口大小主机A就能了解情况。
窗口更新通知主机B终于能有空间接收请求时会给主机A发消息提醒他可以发数据了。
标记位 URG紧急指针标记位0无效1有效数据中有紧急数据16位紧急指针就会标识紧急数据在数据中的偏移量。因为TCP协议中紧急数据大小1字节所以只有偏移量没有大小。举例0代表正常1代表暂停2代表取消...读取紧急数据知晓方法对应上层对于数据的处理方法。
recv 和 send 函数里面的 flag 标记设成 MSG_OOB 就可以对紧急数据设置。
5、滑动窗口
问题
流量控制具体怎么控制发送数据大小
超时重传超时时间内已发送的数据不能丢弃保存在哪里
发送方规定了一个滑动窗口在窗口内的数据可以直接发送暂时不用收到应答。 根据感性的理解滑动窗口是可以变大变小变成0只能向右移。
构建模型
缓冲区在Linux里面逻辑上看成是字节为单位的数组则滑动窗口就是用双指针(win_start , win_end)维护的内存空间。
接收到 ACK 应答之后win_start 确认序号win_end win_start 16位窗口大小。
考虑一个问题如果数据丢包滑动窗口如何移动
建立模型 1、最左侧报文丢失
即2000的报文丢失此时传来的 ACK 确认序号只能是1001由于我们一次发送多条数据应答回来的都是1001超过3次重复应答发送方就会意识到1001~2000的报文已经丢失再次补发下一次 ACK 确认序号就直接是5001这就是快重传机制。 上述情况是报文丢了但如果应答丢了呢没关系只要相信最新一次应答的确认序号就能确定下一次报文从哪里开始发送由确认序号定义得知
所以最左侧报文丢失移动策略 a、由于确认序号规定的约束滑动窗口左边界不动。
b、快重传和超时重传对左侧报文补发。
快重传 vs 超时重传
快重传要连续3次相同确认序号才能触发保证效率但是在极端情况下超时重传一定能识别到报文丢失保证安全
2、中间报文丢失
a、win_start 确认序号此时新滑动窗口就是最左侧报文丢失
b、由于确认序号规定的约束滑动窗口左边界不动。
c、快重传和超时重传对左侧报文补发。
3、最右侧报文丢失
a、win_start 确认序号此时新滑动窗口就是最左侧报文丢失
b、由于确认序号规定的约束滑动窗口左边界不动。
c、快重传和超时重传对左侧报文补发。
所以最后我们来回答最开始的两个问题。
流量控制具体怎么控制发送数据大小滑动窗口机制
超时重传超时时间内已发送的数据不能丢弃保存在哪里滑动窗口里面出问题转化成最左侧报文丢失问题即可解决。
6、拥塞控制
1介绍网络拥塞
由于网络拥堵导致发送报文大面积的丢包TCP会采用慢启动机制先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据。
TCP解决网络拥塞的问题最大的价值在于在多个使用同一网络进行通信的主机有拥塞避免的共识。即TCP协议是全体主机都要遵守的在网络拥塞的情况下不能只从一台主机考虑全体主机都必须减少报文发送才能缓解网络拥塞。
具体的拥塞控制发送方的滑动窗口 min(接收方的应答窗口拥塞窗口)
2拥塞窗口
网络状况是浮动的就说明拥塞窗口的大小肯定也是动态变化的。所以要经过多轮尝试才能得出准确的拥塞窗口大小。
慢启动机制 但是如果只是单纯向上面一样指数级增长就会导致测出来的拥塞窗口不准确所以慢启动之后我们要让拥塞窗口线性增长来保证准确。 加法增大达到阈值之后只能线性增长来探测到准确的网络拥塞值。
乘法减少上一次的网络拥塞值的一半就是下一次慢启动的阈值。
但是不会无限线性增大下去一定会有拥塞窗口极限值限制线性增长。
7、延迟应答
收到一批报文之后不会立即应答等上层处理完一些请求之后能空出更多的接收窗口了再 ACK 应答告知对方有更大的接收窗口可以在网络不拥堵时保证传输效率。
但是延迟应答也有限制。 数量限制 : 每隔 N 个包就应答一次。 时间限制 : 超过最大延迟时间就应答一次。 具体的数量和超时时间 , 依操作系统不同也有差异。 一般 N 取 2, 超时时间取 200ms。 8、捎带应答
发送数据时带上上一次的应答数据
三、理解TCP面向字节流 创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区。 流程 调用 write 时 , 数据会先写入发送缓冲区中。 如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出。 如果发送的字节数太短, 就会先在缓冲区里等待 , 等到缓冲区长度差不多了 , 或者其他合适的时机发送出去。 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区 ; 然后应用程序可以调用 read 从接收缓冲区拿数据。 全双工 TCP 的一个连接 , 既有发送缓冲区 , 也有接收缓冲区 , 那么对于这一个连接, 既可以读数据 , 也可以写数据。 面向字节流特点 由于缓冲区的存在, TCP 程序的读和写不需要一一匹配 。 例如: 写 100 个字节数据时, 可以调用一次 write 写 100 个字节 , 也可以调用 100 次write, 每次写一个字节。读 100 个字节数据时 , 也完全不需要考虑写的时候是怎么写的 , 既可以一次 read 100 个字节 , 也可以一次 read 一个字节 , 重复 100 次。 四、TCP粘包问题
1、介绍粘包问题 首先要明确 , 粘包问题中的 包 , 是指的应用层的数据包。 在 TCP 的协议头中 , 没有如同 UDP 一样的 报文长度 这样的字段 , 但是有一个序号这样的字段。 序号只保证数据到应用层的有序性。 站在传输层的角度, TCP 是一个一个报文过来的。 按照序号排好序放在缓冲区中。 站在应用层的角度, 看到的只是一串连续的字节数据。 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包。 2、解决粘包问题 1对于定长的包 , 保证每次都按固定大小读取即可。 例如上面的 Request 结构 , 是固定大小的, 那么就从缓冲区从头开始按 sizeof(Request) 依次读取即可。 2对于变长的包, 可以在包头的位置 , 约定一个包总长度的字段 , 从而就知道了包的结束位置。 3对于变长的包, 还可以在包和包之间使用明确的分隔符 ( 应用层协议 , 是程序员自己来定的, 只要保证分隔符不和正文冲突即可 3、UDP不用考虑粘包问题 对于 UDP, 如果还没有上层交付数据 , UDP 的报文长度仍然在 . 同时 , UDP 是一个一个把数据交付给应用层. 就有很明确的数据边界。 站在应用层的站在应用层的角度, 使用 UDP 的时候 , 要么收到完整的 UDP 报文, 要么不收 . 不会出现 半个 的情况。面向数据报。 五、TCP异常 进程终止 : 进程终止会释放文件描述符 , 仍然可以发送 FIN依然可以四次挥手 。 机器重启 : 和进程终止的情况相同。 机器掉电 / 网线断开 : 接收端认为连接还在 , 一旦接收端有写入操作 , 接收端发现连接已经不在了, 就会进行 reset. 即使没有写入操作 , TCP 自己也内置了一个保活定时器 , 会定期询问对方是否还在. 如果对方不在 , 也会把连接释放。 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如 HTTP 长连接中, 也会定期检测对方的状态. 例如 QQ, 在 QQ 断线之后, 也会定期尝试重新连接. 六、TCP小结
可靠性: 校验和序列号(按序到达) 确认应答机制超时重传机制连接管理机制流量控制机制拥塞控制机制 提高性能: 滑动窗口快速重传机制 延迟应答机制捎带应答机制 七、TCP / UDP对比 我们说了 TCP 是可靠连接 , 那么是不是 TCP 一定就优于 UDP 呢 ? TCP 和 UDP 之间的优点和缺点, 不能简单 , 绝对的进行比较。 TCP 用于可靠传输的情况 , 应用于文件传输 , 重要状态更新等场景。 UDP 用于对高速传输和实时性要求较高的通信领域 , 例如 , 早期的 QQ, 视频传输等. 另外 UDP 可以用于广播。 归根结底 , TCP 和 UDP 都是程序员的工具 , 什么时机用 , 具体怎么用 , 还是要根据具体的需求场景去判定。 八、用UDP实现可靠性传输
1、引入超时重传机制防止丢包
2、引入确认应答机制保证对方收到数据
3、引入序号保证数据接收顺序
