宿迁网站,wordpress 头像打岔,如何在后台做网站分页,免费制作微信网页网站文章目录 TCP 协议1. TCP 协议段格式2. TCP 报头解析3. TCP 的可靠性4. 面向字节流5. 粘包问题6. 连接队列维护 TCP 的 确认应答机制TCP 的 超时重传机制TCP 的 三次握手TCP 的 四次挥手setsockopt 函数#xff1a;设置套接字选项#xff0c;解决 TIME_WAIT 状态引起的 bind … 文章目录 TCP 协议1. TCP 协议段格式2. TCP 报头解析3. TCP 的可靠性4. 面向字节流5. 粘包问题6. 连接队列维护 TCP 的 确认应答机制TCP 的 超时重传机制TCP 的 三次握手TCP 的 四次挥手setsockopt 函数设置套接字选项解决 TIME_WAIT 状态引起的 bind 失败 TCP 的 流量控制TCP 的 滑动窗口TCP 的 拥塞控制慢启动机制 和 阈值TCP 的 延迟应答TCP 的 捎带应答TCP 的 异常情况小结 TCP 协议 TCPTransmission Control Protocol 传输控制协议 传输层协议。有连接处于通信之前也就意味着三次握手是不携带有效信息的。可靠传输有确认机制如 收到应答、超时重传、三次握手、四次挥手…面向字节流有对应的以字节为单位的缓冲区收发数据以供解析。 对比 UDP
UDPUser Datagram Protocol 用户数据报协议传输的过程类似于寄信。
- 传输层协议。
- 无连接知道对端的IP和端口号就直接进行传输不需要建立连接。
- 不可靠没有确认机制没有重传机制如果因为网络故障该段无法发到对方UDP协议层也不会给应用层返回任何错误信息。
- 面向数据报: 不能够灵活的控制读写数据的次数和数量。1. TCP 协议段格式
TCP 的首部有一块定长大小为 20 字节的空间字段用于报头信息的填写。后面接着的是一块储存选项的空间也可能没有选项信息。
既然不确定选项字段的情况如何分离报头和有效载荷呢 在 TCP 前 20 字节的定长字段之中有一个记录首部长度的空间这部分空间大小是 4 个比特位而其中记录的单位大小是 4 字节即可以记录 60 字节的长度前 20 是定长的后 40 就是给头部选项的。 所以整个首部的大小 首部长度字段 * 4 - 20如果 0则报头读取完毕剩下的就是有效载荷 2. TCP 报头解析
源 / 目的端口号
表示数据是从哪个进程来到哪个进程去
32 位序号 / 32 位确认号
对报文的编号和确认报文的编号见 TCP 的可靠性
4 位 TCP 报头长度
表示该 TCP 头部有多少个 32 位 bit有多少个 4 字节; 所以TCP头部最大长度是15 * 4 60
6 个重要标志位 ACK - - acknowledge该报文是一个确认报文确认报文可能会携带数据携带数据的确认报文的应答叫做 捎带应答。 SYN – sync请求建立连接我们把携带 SYN 标识的称为 同步报文段。 FIN请求断开连接通知对方本端要关闭了我们称携带 FIN 标识的为 结束报文段。 RST - - reset对方要求重新建立连接我们把携带 RST 标识的称为复位报文段。 PSH - - push提示接收端应用程序立刻从 TCP 缓冲区把数据读走。 URG - - urgent标识紧急指针字段是否有效。
16 位窗口大小
发送自己端接收缓冲区的剩余空间大小以作 流量控制不会导致对方发太快太多导致丢包也可以避免发的太慢效率低下的问题出现。
16 位校验和
发送端填充CRC 校验。接收端校验不通过则认为数据有问题直接丢弃。此处的检验和不光包含 TCP 首部也包含 TCP 数据部分。
16 位紧急指针
是一个偏移量标识哪部分数据是紧急数据一个字节的状态码这样的数据也叫做外带数据。
40 字节头部选项见后文。 其中 紧急数据 的处理可以在 recv 和 send 中设置 ssize_t recv(int sockfd, void *buf, size_t len, int flags);ssize_t send(int sockfd, const void *buf, size_t len, int flags);参数 flags MSG_OOB允许 接收 / 发送 非正常流中的 紧急数据 但在实际使用中 URG 使用的很少因为他能携带的信息量实在有限
更多的是多开一个端口号拿到并处理特殊信息3. TCP 的可靠性
不可靠的情况有很多比如丢包、乱序、重复、校验失败、发送太快/太慢、网络问题…
客户端发送请求在收到服务器响应才可以 100% 的确保对方是收到的也就是说 可靠性是通过收到应答机制保证的。如此也说明我们无法保证任何报文都是可靠送达但可以局部保持可靠性。
实际上客户端可以同时对服务器发送多个请求报文经过网络的传输到达服务器的情况却不一样应对不同的报文送达情况客户端有不同的应对机制判断哪个报文是哪个报文就是很有必要的。所以报文里会携带两种编号序号、确认序号。确认序号是收到序号 1 来设定的。两个序号在一段报文中注定是更高效的所以在报头中有各自不同的字段空间。
序号的设置保证了 TCP 的可靠性。
4. 面向字节流
创建一个 TCP 的 socket相当于同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区 调用 write 时数据会先写入发送缓冲区中。 如果发送的字节数太长会被拆分成多个 TCP 的数据包发出如果发送的字节数太短就会先在缓冲区里等待等到缓冲区长度差不多了或者其他合适的时机发送出去。 接收数据的时候数据也是从网卡驱动程序到达内核的接收缓冲区。 然后应用程序可以调用 read 从接收缓冲区拿数据。 另一方面TCP 的一个连接既有发送缓冲区也有接收缓冲区那么对于这一个连接既可以读数据也可以写数据。这个概念叫做 全双工。
由于缓冲区的存在TCP 程序的读和写不需要一一匹配例如
写 100 个字节数据时可以调用一次 write 写 100 个字节也可以调用 100 次 write每次写一个字节。
读 100 个字节数据时也完全不需要考虑写的时候是怎么写的既可以一次 read 100 个字节也可以一次 read 一个字节重复100次。5. 粘包问题
首先要明确粘包问题中的 “包”是指的应用层的数据包。
在 TCP 的协议头中没有如同 UDP 一样的 “报文长度” 这样的字段但是有一个序号这样的字段。
站在传输层的角度TCP 是一个一个报文过来的。按照序号排好序放在缓冲区中。站在应用层的角度看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包。
避免粘包问题 归根结底就是 明确两个包之间的边界。 对于定长的包保证每次都按固定大小读取即可。例如上面的 Request 结构是固定大小的那么就从缓冲区从头开始按 sizeof(Request) 依次读取即可。 对于变长的包可以在包头的位置约定一个包总长度的字段从而就知道了包的结束位置。 对于变长的包还可以在包和包之间使用明确的分隔符应用层协议, 是程序员自己来定的, 只要保证分隔符不和正文冲突即可
对于 UDP 协议来说是否也存在 “粘包问题” 呢?
对于 UDP如果还没有上层交付数据UDP 的报文长度仍然在。同时UDP 是一个一个把数据交付给应用层。就有很明确的数据边界。站在应用层的站在应用层的角度使用 UDP 的时候要么收到完整的UDP报文要么不收不会出现 “半个” 的情况。
6. 连接队列维护
Linux 内核协议栈为一个 TCP 连接管理使用两个队列。
半链接队列用来保存处于 SYN_SENT 和 SYN_RECV 状态的请求全连接队列accepted 队列用来保存处于established状态但是应用层没有调用accept取走的请求
全连接队列管理已连接但还没发起任务的客户端。为了保证服务器的使用率全连接队列的维护是必须维护的。也要控制这个队列不能太长。
因为可能会过多消耗 OS 本来是给 server 使用的资源且队列太长 client 会不愿意等。实际上更有效率的应该是 提高 网络吞吐量。至于队列究竟要维护多长需要看各自应用场景。
半连接队列管理半连接状态的队列。
TCP 协议需要在底层维护 全连接队列最大长度是listen() 的第二个参数 1 。 TCP 的 确认应答机制 在确认应答机制中TCP 首先将每个发出的数据在发送缓冲区中都以字节为单位进行了编号即序列号。每一个 ACK 都带有对应的确认序列号序列号 1意思是告诉发送者我已经收到了哪些数据下一次你从哪里开始发。
例如主机 A 和主机 B 通信
A to B发送数据1~1000
B to A确认应答收到了下一个从 1001 开始发
A to B发送数据1001~2000
B to A确认应答收到了下一个从 2001 开始发
...在字节单位的缓冲区中不断的读取和放置就是 TCP 的特征之一面向字节流。 TCP 的 超时重传机制
主机 A 发送数据给 B 之后可能因为网络拥堵等原因数据无法到达主机B。如果主机 A 在一个特定时间间隔内没有收到 B 发来的确认应答就会进行重发。
例如主机 A 和主机 B 通信
A to B发送数据1~1000
// 一段时间没有收到 B 的确认应答A 判定丢包开始重传
A to B发送数据1~1000
B to A确认应答收到了下一个从 1001 开始发因此主机 B 会收到很多重复数据那么 TCP 协议需要能够识别出那些包是重复的包并且把重复的丢弃掉。这时候报头里的序列号就可以很容易实现去重。
超时的时间如何确定呢
最理想的情况下找到一个最小的时间保证“确认应答一定能在这个时间内返回”。但是这个时间的长短随着网络环境的不同是有差异的如果超时时间设的太长会影响整体的重传效率如果超时时间设的太短有可能会频繁发送重复的包。
TCP 为了保证无论在任何环境下都能比较高性能的通信此会动态计算最大超时时间。
Linux 中BSD Unix 和 Windows 也是如此超时以 500ms 为一个单位进行控制每次判定超时重发的超时时间都是 500ms 的整数倍。如果重发一次之后仍然得不到应答等待 2500ms 后再进行重传。如果仍然得不到应答等待 4500ms 进行重传。依次类推, 以指数形式递增。累计到一定的重传次数TCP 认为网络或者对端主机出现异常强制关闭连接。 TCP 的 三次握手
整个 TCP 三次握手建立连接传递信息四次挥手断开连接的过程包括应用层的建立。我们需要关注的是传输和两端的状态变化流程图如下
三次握手的过程由双方的 OS 系统中的 TCP 层自主完成。
客户端connect触发连接等待完成
服务器accept等待建立完成获取连接为什么握手是三次 没有明显的设计漏洞如果是 2 次会造成客户端零成本连接服务器可能收到连接攻击而崩溃一旦建立连接出现异常成本嫁接到 client 端server 端成本较低因为最后一次发送可能丢失如果偶数次握手server 是不确定丢包与否即建立成功与否的。 可以验证双方通信信道的通畅情况三次握手是验证全双工通信信道通畅的最小成本。
三次握手除了确认信道畅通建立连接还有什么用
通过 16 位窗口大小进行流量控制。首先我们要知道TCP 是面向连接的处于正常通信之前三次握手是不携带有效数据的也就是说两端第一次传输数据不是第一次通信。在三次握手阶段首先客户端在发起连接请求时除了 SYN 标志位被置 1客户端也一定会将自己的 16 位窗口大小通告给服务器以便服务器知道该客户端的承载能力。其次服务器响应 SYN ACK 标志位被置 1服务器的 16 位窗口大小也会被填上。这样双方的承载能力就都被对方知晓了不会在第一次报文传输的时候出现流量异常导致的一系列问题。
服务器端状态转化 [CLOSED - LISTEN] 服务器端调用 listen 后进入 LISTEN 状态等待客户端连接 [LISTEN - SYN_RCVD] 一旦监听到连接请求同步报文段就将该连接放入内核等待队列中并向客户端发送 SYN 确认报文 [SYN_RCVD - ESTABLISHED] 服务端一旦收到客户端的确认报文就进入 ESTABLISHED 状态可以进行读写数据了 [ESTABLISHED - CLOSE_WAIT] 当客户端主动关闭连接调用 close服务器会收到结束报文段服务器返回确认报文段并进入 CLOSE_WAIT [CLOSE_WAIT - LAST_ACK] 进入 CLOSE_WAIT 后说明服务器准备关闭连接需要处理完之前的数据当服务器真正调用 close 关闭连接时会向客户端发送 FIN此时服务器进入 LAST_ACK 状态等待最后一个 ACK 到来这个ACK是客户端确认收到了 FIN [LAST_ACK - CLOSED] 服务器收到了对 FIN 的 ACK彻底关闭连接
客户端状态转化 [CLOSED - SYN_SENT] 客户端调用 connect发送同步报文段 [SYN_SENT - ESTABLISHED] connect 调用成功则进入 ESTABLISHED 状态开始读写数据 [ESTABLISHED - FIN_WAIT_1] 客户端主动调用 close 时向服务器发送结束报文段同时进入 FIN_WAIT_1 [FIN_WAIT_1 - FIN_WAIT_2] 客户端收到服务器对结束报文段的确认则进入FIN_WAIT_2开始等待服务器的结束报文段 [FIN_WAIT_2 - TIME_WAIT] 客户端收到服务器发来的结束报文段进入 TIME_WAIT并发出 LAST_ACK [TIME_WAIT - CLOSED] 客户端要等待一个 2 MSLMax Segment Life报文最大生存时间的时间, 才会进入 CLOSED 状态。
TCP 的 四次挥手
综合上述的描述对四次挥手进一步做些解释。
四次挥手对于主动断开的一方 进行最后一次确认后要进入 TIME_WAIT 状态这是一个临时性状态持续一会就没了。
为什么挥手是四次
建立连接后两端就是同等地位了一方断开连接都需要另一方确认。
TIME_WAIT 状态的细节 当主动断开的一方进入 TIME_WAIT 状态时连接确实就断开了但底层这个连接还没有被彻底关掉相应的端口号还在被 TIME_WAIT 状态占用在被占用的这段时间里这个端口号就是不能使用的。 如果是 server 端发起断开连接并处于 TIME_WAIT 状态而 server 端经不起等待或者更换端口时就可以调用下面的接口对套接字进行相应的选项设置无视其TIME_WAIT 状态重新使原端口可以被有效使用。
setsockopt 函数设置套接字选项解决 TIME_WAIT 状态引起的 bind 失败 #include sys/types.h /* See NOTES */#include sys/socket.hint getsockopt(int sockfd, int level, int optname,void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);参数 level 要设的属性在哪一层 参数 optname 要设的是哪一个属性 SO_REUSEADDR无视网络中的 TIME_WAIT 状态。主动关闭连接的一方处于 TIME_WAIT 的时候允许新的连接重新绑定与 TIME_WAIT 状态的连接有冲突的 IP PORT并立即接收数据。 SO_REUSEPORT SO_REUSEADDR 对完全相同的IPPORT绑定无论是具体的IP还是通配仍然出现Address already in use的错误使用SO_REUSEPORT选项可以避免此错误。 参数 optval 属性的值设成多少 参数 optlenl 属性长度是多少 ·
TIME_WAIT 状态有什么用 当退出端退出时或有正在传输的信息并未到达对端TIME_WAIT 的存在就是为了让已退出端尚未完成传输的信息消散目的是不影响对端 ACK 的序号不被先前信息影响保证下次同个端口号发送的数据能够被正常响应。 另一方面是为了保证退出端的最后一次 ACK 被对端收到。 TCP 的 流量控制
之前提到过接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力来决定发送端的发送速度。这个机制就叫做 流量控制Flow Control。 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段通过ACK端通知发送端。窗口大小字段越大, 说明网络的吞吐量越高。 接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知给发送端。发送端接受到这个窗口之后就会减慢自己的发送速度。 如果接收端缓冲区满了就会将窗口置为0这时发送方不再发送数据但是需要定期发送一个 窗口探测 数据段使接收端把窗口大小告诉发送端。 窗口探测发送方定期发出一个 TCP 报头接收方必须 对所有请求进行应答TCP 的协议内容于是返回应答中的 16位 窗口字段就可以让发送方知道什么时候可以继续发送有效载荷。
在TCP首部中有一个 16 位窗 口字段用来存放窗口大小信息。
那么问题来了16 位数字最大表示 65535, 那么 TCP 窗口最大就是 65535 字节么? 实际上, TCP 首部 40 字节选项中还包含了一个 窗口扩大因子 M实际 窗口大小是 窗口字段的值左移 M 位。 TCP 的 滑动窗口 对应确认应答策略对每一个发送的数据段都要给一个ACK确认应答收到ACK后再发送下一个数据段。如此串行工作性能较差尤其在数据往返的时间较长的时候更甚。
一发一收的方式性能较低只要一次发送多条数据就可以大大的提高性能其实是将多个段的等待时间重叠在一起了。 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值上图的窗口大小就是4000个字节四个段。 发送前四个段的时候不需要等待任何 ACK直接发送。 收到第一个 ACK 后滑动窗口向后移动继续发送第五个段的数据依次类推。 操作系统内核为了维护这个滑动窗口需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉。 窗口越大, 则网络的吞吐率就越高。
一般情况 滑动窗口往左边部分是已经发送已经确认过的无效数据可以被覆盖 滑动窗口部分暂时不用等待收到应答可以直接发送。其大小和对方的接受能力有关即应答报文中的窗口大小。 滑动窗口往右边部分是尚未发送的数据区域。
如何理解滑动窗口 所谓面向字节流的 TCP他的接收和发送缓冲区都可以理解成一个个 char 类型的 数组。 而滑动窗口在这个数组中的“滑动”实际是依赖两个指针这里做 winstartwinend划定范围通过 运算符完成的。
一些规则 “窗口” 只会向右 “滑动”左边是已经确认过的报文 一直向右移的规则并不会造成越界因为发送缓冲区的结构是环状的。 滑动窗口的大小是浮动的不是固定大小而其 变大、变小、变 0 是根据对方给本端响应报头中 窗口大小 来调节的。 窗口变大通过 winendxxx 来完成窗口变小 winend-xxx 来完成滑动窗口大小的更新更具体来说和对方发送的序列号 seq 有关在应答也是按序到达的前提下 根据应答的 seqwinstart seq;
根据应答的 winwinend winstart win;滑动窗口内部的报文可以直接发送多个报文传输肯定会发生丢失的问题。 如果第一个丢失了情况1数据丢了即使后面的收到了winstart 也不会向后移动只是等待发送方超时重传。情况2应答丢失可以通过后面传来的响应报文确定之前的一定接收到了。
如果中间或最后的丢失了随着 winstart 的右移都会转化成第一个丢失问题按上述步骤处理。数据要支持重传就必须被保存起来保存的位置就是滑动窗口 TCP 的 拥塞控制慢启动机制 和 阈值
少量的丢包我们仅仅是触发超时重传大量的丢包我们就认为 网络拥塞。
当 TCP 通信开始后网络吞吐量会逐渐上升随着网络发生拥堵吞吐量会立刻下降。
当网络拥塞出现大量丢包的情况发送方不能一直超时重传也不能完全停发。总体策略是保证网络拥塞不能加重再网络拥塞有起色的情况下尽快恢复网络通信。
而 慢启动 机制先发少量的数据探路摸清当前的网络拥堵状态再决定按照多大的速度传输数据。
此处引入一个概念程为 拥塞窗口 发送开始的时候定义拥塞窗口大小为 1 每次收到一个 ACK 应答拥塞窗口加 1 只是这样的话拥塞窗口的大小肯定是指数级上升的可实际不止如此。每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较取较小的值作为实际发送的窗口 滑动窗口 min对端主机的接受能力 win网络的拥塞窗口
winstart seq;
winend min(seq_win, 拥塞窗口);正常来说拥塞窗口增长速度是指数级别的。“慢启动” 只是指初使时慢但是增长速度非常快。为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍需要 慢启动的 阈值 进行控制。 当拥塞窗口超过这个阈值的时候不再按照指数方式增长而是按照线性方式增长。当 TCP 开始启动的时候慢启动阈值等于窗口最大值在每次超时重发的时候慢启动阈值会变成原来的一半同时拥塞窗口置回 1
拥塞控制归根结底是 TCP 协议想尽可能快的把数据传输给对方但是又要避免给网络造成太大压力的折中方案。 TCP 的 延迟应答
如果接收数据的主机立刻返回 ACK 应答这时候返回的窗口可能比较小。
假设接收端缓冲区为 1M一次收到了500K的数据
如果立刻应答返回的窗口就是500K。
但实际上可能处理端处理的速度很快10ms 之内就把 500K 数据从缓冲区消费掉了在上述情况下接收端处理还远没有达到自己的极限即使窗口再放大一些也能处理过来。
如果接收端稍微等一会再应答比如等待 200ms 再应答那么这个时候返回的窗口大小就是 1M。窗口越大网络吞吐量就越大传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。如何选择延迟应答的时机呢
选择延迟应答的时机也有不同的方案
数量限制每隔 N 个包就应答一次时间限制超过最大延迟时间就应答一次
具体的数量和超时时间依操作系统不同也有差异一般 N 取 2超时时间取 200ms。 TCP 的 捎带应答
在延迟应答的基础上我们发现很多情况下客户端服务器在应用层也是 “一发一收” 的。 意味着客户端给服务器说了 “你好吗”服务器也会给客户端回一个 “我很好”。那么这个时候 ACK 就可以和服务器回应的 “我很好” 一起回给客户端。 TCP 的 异常情况
机器重启 / 进程终止机器重启 / 进程终止会释放文件描述符仍然可以发送 FIN和正常关闭没有什么区别。
机器掉电 / 网线断开接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会进行 reset。即使没有写入操作TCP自己也内置了一个保活定时器会定期询问对方是否还在如果对方不在也会把连接释放。
另外应用层的某些协议也有一些这样的检测机制
例如 HTTP 长连接中也会定期检测对方的状态例如QQ,。
在 QQ 断线之后也会定期尝试重新连接。小结
TCP 这么复杂是因为要保证 可靠性同时又尽可能的提高性能。 可靠性 校验和 序列号(按序到达) 确认应答 超时重发 连接管理 流量控制 拥塞控制 提高性能: 滑动窗口 快速重传 延迟应答 捎带应答 其他: 定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等) 另基于TCP应用层协议有如下这些
HTTPHTTPSSSHTelnetFTPSMTP 当然, 也包括我们自己写 TCP 程序时自定义的应用层协议 如果本文对你有些帮助请给个赞或收藏你的支持是对作者大大莫大的鼓励(✿◡‿◡) 欢迎评论留言~~
