网站开发代码交接文档书,wordpress优化教程,电商平台业务流程图,自己制作头像app软件目录 一、前导知识
1.1 TCP协议段格式
1.2 TCP全双工本质
二、三次握手
2.1 标记位
2.2 三次握手
2.3 捎带应答
2.4 标记位 RST
三、四次挥手
3.1 标记位 FIN
四、确认应答(ACK)机制
五、超时重传机制
六 TCP 流量控制
6.1 16位窗口大小
6.2 标记位 PSH
6.3 标记…目录 一、前导知识
1.1 TCP协议段格式
1.2 TCP全双工本质
二、三次握手
2.1 标记位
2.2 三次握手
2.3 捎带应答
2.4 标记位 RST
三、四次挥手
3.1 标记位 FIN
四、确认应答(ACK)机制
五、超时重传机制
六 TCP 流量控制
6.1 16位窗口大小
6.2 标记位 PSH
6.3 标记位 URG
七、滑动窗口
7.1 滑动窗口的概念
7.2 滑动窗口的相关问题
7.2.1 滑动窗口的大小
7.2.2 滑动窗口策略简单思路
7.2.2 超时重传时的数据如何保存
7.2.3 超时重传 vs 快重传
八、拥塞窗口 一、前导知识
1.1 TCP协议段格式 源/目的端口号表示数据是从哪个进程来, 到哪个进程去;32 位序号/32 位确认号后面详细讲;4 位 TCP 报头长度表示该 TCP 头部有多少个 32 位 (有多少个 4 字节)所以TCP 头部最大长度是 15(2^4 - 1) * 4 606位标志位后面具体说16位窗口大小后面再说16位校验和发送端填充CRC 校验。接收端校验不通过则认为数据有问题。此处的检验和不光包含 TCP 首部也包含 TCP 数据部分16 位紧急指针后面和标志位中的URG一起说 1.2 TCP全双工本质 在任何一台主机上 TCP 连接既有发送缓冲区 又有接受缓冲区 所以 在内核中 可以在发消息的同时 也可以收消息 即全双工。在这里收消息和发消息的本质都变成了拷贝发消息首先把应用层的数据拷贝到发送缓冲区然后再拷贝到接受方的接受缓冲区接受方再通过特殊的 API 将接受缓冲区中的数据拷贝到应用层。
二、三次握手
2.1 标记位
为什么要有标记位呢这里先做一下简单的理解 作为网络服务器服务端可以连接多个客户端但是每个客户端发送的报文分为很多种以三次握手为例该报文可能是1)请求连接 2)正文 3)请求关闭 所以客户端收到各种各样的报文这就说明TCP报文是需要类型的为了区分不同的报文类型就引入了标记位的概念。
2.2 三次握手 1. TCP建立连接时发送方先传达一个连接意愿 2. 接收方收到后需要响应这个消息若不响应发送方可能会一直重发消息。除此之外接收方还要表达连接意愿 3.发送方响应接收方的意愿。 首先需要明确的是上图中的标记位其实是一个个报文其中SYN指的是报文中SYN标记位被置为1以此类推SYN请求建立连接称携带SYN标识的报文为同步报文段。 ACK确认号是否有效。
其中当请求方发送连接意愿时就会发送将SYN标记位置1的报文接收方相应表示为ACK标记位置1同时表达连接意愿又会将SYN置1...这种方式即为捎带应答(下面会讲到)。
在这里配合着上一篇博客中对于TCP网络编程中相关的API来看 client 通过应用层的 connect 接口发送握手请求然后阻塞等待三次握手完毕再继续向后执行 server 通过 listen 接口才会受理接受的 SYN 请求否则会直接丢弃。
2.3 捎带应答
捎带应答相当于搭顺风车当不影响网络服务时ACK 会和服务器的接受意愿一起发送给客户端。但是在四次握手中并没有出现捎带应答机制者在下面会讲到。
其实不止是服务器首次回应连接意愿时会有捎带应答在后面我们要讲到的窗口大小它们在首次发送时就会将窗口大小填到报文中传输给发送端同时在两次握手后即发送端确认接受端已经可以接受数据后发送端相应的ACK就可以开始携带传输数据了
2.4 标记位 RST
在传输控制协议TCP中RST标记位Reset flag用于复位连接。RST标记位通常在以下情况下使用 拒绝连接当一方收到一个连接请求例如SYN包但不愿意或者无法建立连接时它会发送一个带有RST标记位的包来拒绝连接请求。 中止连接当一个已经建立的连接出现问题例如某一方的应用程序崩溃一方可能会发送一个带有RST标记位的包来强制终止连接。 处理错误的数据包如果一方收到一个无法识别或不符合预期的数据包它可能会发送一个带有RST标记位的包来通知发送方存在错误并终止连接。
具体来说当一个TCP数据包的RST标记位被设置时接收方会立即关闭连接并不会等待剩余的数据传输完成。这是一种快速且强制性的连接终止方式。
RST标记位的使用通常表示存在某种异常或错误情况因此在正常的TCP连接管理过程中RST标记位的出现相对较少。
三、四次挥手 1. 发送方发起断开意愿 2. 接收端响应消息 3. 接收方表达断开意愿 4. 发送方响应断开意愿 3.1 标记位 FIN
这和三次握手的规律大致相同只是把中间一条拆分成了两条其中2和3不可以合并为一条当接收方等待数据数据接收完整后才可以表达断开意愿。FIN通知对方本端要关闭了称携带FIN表示的报文为结束报文段 四、确认应答(ACK)机制
在TCP的特点中有一点叫做可靠。那么TCP的可靠指的是什么呢
TCP的可靠指的是发送方不仅要发送数据而且还要知道自己发送的数据是否被接收方接收这就依赖于TCP的确认应答机制。
TCP 将每个字节的数据都进行了编号即为序列号
TCP 将应用程序发送的字节流分割成适合传输的段每个段包含一个序列号用于在接收端重新组装数据。接收方可以根据这些序列号将数据段正确地拼接成原始的字节流。
下面将发送缓冲区简单想象成线性的数组 假设主机A发送的数据段是 1-1000 那么主机B的应答则需要是 1001 此时1001就会写到协议段中的32位确认序号中表示确认序号以前的报文全部被收到。
五、超时重传机制
若发送方未收到接受方的应答则统一约定接受方未收到报文此时有三种可能1) 传输数据丢失 2) 应答丢失 3) 被阻塞在路由器中为了避免第三种情况发送方会进行等待如果等待超时则会进行重传这就是超时重传机制。超时重传中约定的等待时间在 Linux 系统中会以500ms为基本单位进行动态调整。
六 TCP 流量控制
接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。
因此 TCP 支持根据接收端的处理能力, 来决定发送端的发送速度。这个机制就叫做流量控制。
6.1 16位窗口大小
那么假设主机A向主机B发送消息如果要进行流量控制就需要知道主机B的接受能力即接受缓冲区中剩余空间的大小。这就要求主机B要将自身的接受能力通告给主机A这里就用到了TCP协议段格式中的16位窗口大小用于标明主机B接受缓冲区中剩余空间的大小同时使用了确认应答机制与捎带应答机制。 6.2 标记位 PSH
当B的接受缓冲区中剩余空间大小为0时A在此期间会发送一个窗口探测的包如果B的接受缓冲区一直为0A就会将报文中的 PSH 标记位置1作为催促标记位要求主机B尽快将缓冲区中的数据交给上层。
当然不止是这种极端情况在日常通信中凡是有这种需求时都会将标记位 PSH 置1。
6.3 标记位 URG
以上已经介绍了五种标记位现在剩下最后一种 URG URG表示紧急指针是否有效。 在接受缓冲区中TCP按序为我们排好了很多的数据并按序向应用层进行交付紧急指针仅当URG标记位被设置时才有效。它指示了紧急数据的结束位置。紧急指针的值是一个相对序号它表示从当前序号开始到紧急数据结束的偏移量。
接受方会优先处理该报文但是URG的使用并不常见它传输的紧急数据通常是1字节表示的是一个状态码比如在传输2G的数据时接受方的缓冲区已经接受了1G此时发送方想要紧急停止传输工作就会传输一个 URG 被设置的报文接受方优先处理该报文得知其状态码意味着中断传输那么之前存放在缓冲区的1G数据也不会再向上进行交付
七、滑动窗口
在前面的讲解中我们也会意识到每次先传输数据等待应答后才能再次传输的效率太低了尤其是数据往返的时间较长的时候
7.1 滑动窗口的概念
既然这样一发一收的方式性能较低, 那么我们一次发送多条数据这些数据暂时不需要被应答可以直接发送这样就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)这种策略在发送方的体现就是以一个滑动窗口的形式
在不考虑网络的前提下将暂时不需要应答可以直接发送的数据的最大值称为发送方的滑动窗口的大小上图中滑动窗口的大小就是4000字节。
滑动窗口其实就是在发送窗口上的双指针之间的一个数据段
从上图我们可以把发送缓冲区分为三段
7.2 滑动窗口的相关问题
重中之重确认序号的意义确认序号以前的报文全部被收到
7.2.1 滑动窗口的大小
在不考虑网络速度的前提下窗口的大小一般是接受方接收缓冲区中剩余空间的大小。
7.2.2 滑动窗口策略简单思路 7.2.2 超时重传时的数据如何保存
前面提到了确认序号的意义以及滑动窗口的策略当有数据丢包时比如1001-2000丢了那么确认应答的值就为1001从滑动窗口的策略可以看出左指针仍是1001这意味着1001-2000的数据仍在滑动窗口中那么发送方就可以进行数据的重传。
当某一段报文段丢失之后, 发送端会一直收到 1001 这样的 ACK, 就像是在提醒发送端 我想要的是 1001 一样;如果发送端主机连续三次收到了同样一个 1001 这样的应答, 就会将对应的数据 1001 - 2000 重新发送; 这个时候接收端收到了 1001 之后, 再次返回的 ACK 就是 7001 了(因为 2001 -7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中; 这种机制被称为 高速重发控制(也叫 快重传)。 在滑动窗口中可以分为窗口最左侧数据丢包窗口中间数据丢包窗口最右侧数据丢包但是根据确认序号的意义每次的确认序号都会保证确认序号前面的数据全部被成功接收如果最左侧数据被丢包那么就参考以上方案。如果中间和右侧数据被丢包那么它们最后都会称为滑动窗口中的最左侧解决方案也同上一样。
7.2.3 超时重传 vs 快重传
从上面可以看出快重传的效率明显高于超时重传超时重传需要等待一定的时间而快重传接受到确认应答即可实现重传那么超时重传的存在还有意义吗
其实从7.2.2中的图中可以看出接受方需要发送3次重复的确认应答发送方也需要收到3个同样的确认应答才会重发那么总有不足3个的情况这时候发生生丢包就需要超时重传进行兜底。
八、拥塞窗口
虽然 TCP 有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题。因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。
TCP 引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据 此处引入一个概念称为拥塞窗口 1.发送开始的时候, 定义拥塞窗口大小为 1 2.每次收到一个 ACK 应答, 拥塞窗口加 1 3.每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口。 实际上拥塞窗口并不是一直呈指数增长的这里引入了新的概念即慢启动的阈值当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长 当 TCP 开始启动的时候慢启动阈值等于窗口最大值 •在每次超时重发的时候慢启动阈值会变成原来的一半同时拥塞窗口置回 1 少量的丢包, 我们仅仅是触发超时重传大量的丢包就认为网络拥塞 当 TCP 通信开始后, 网络吞吐量会逐渐上升随着网络发生拥堵吞吐量会立刻下降拥塞控制归根结底是 TCP 协议想尽可能快的把数据传输给对方但是又要避免给网络造成太大压力的折中方案。
TCP 拥塞控制这样的过程, 就好像热恋的感觉
