个人开发网站要多少钱,织梦cms网站模板修改,厦门seo招聘,wordpress 淘点金文章目录 1. TCP协议段格式2. 详解TCP2.1 4位首部长度2.2 32位序号与32位确认序号#xff08;确认应答机制#xff09;2.3 超时重传机制2.4 连接管理机制(3次握手、4次挥手 3个标志位)2.5 16位窗口大小#xff08;流量控制#xff09;2.6 滑动窗口2.7 3个标志位 16位紧急… 文章目录 1. TCP协议段格式2. 详解TCP2.1 4位首部长度2.2 32位序号与32位确认序号确认应答机制2.3 超时重传机制2.4 连接管理机制(3次握手、4次挥手 3个标志位)2.5 16位窗口大小流量控制2.6 滑动窗口2.7 3个标志位 16位紧急指针2.8 拥塞控制2.9 延迟应答2.10 其它2.10.1 面向字节流2.10.2 粘包问题2.10.3 异常情况 3. TCP/UDP 对比 TCP协议全称为 “传输控制协议(Transmission Control Protocol”)。 人如其名要对数据的传输进行一个
详细的控制。 可靠性: 校验和序列号(按序到达) 去重确认应答超时重传连接管理流量控制拥塞控制 提高性能: 滑动窗口快重传延迟应答捎带应答 其他: 定时器(超时重传定时器, 保活定时器, TIME_WAIT 定时器等) 1. TCP协议段格式 16位源/目的端口号表示数据是从哪个进程来 到哪个进程去;32位序号/32 位确认序号4 位首部长度 表示该 TCP 头部有多少个 32 位 bit(有多少个4 字节); 所以 TCP 头部最大长度是 15 * 4 606 位标志位 ACK确认号是否有效SYN请求建立连接我们把携带 SYN 标识的称为同步报文段FIN通知对方, 本端要关闭了, 我们称携带 FIN 标识的为结束报文段PSH 提示接收端应用程序立刻从 TCP 缓冲区把数据读走RST对方要求重新建立连接; 我们把携带 RST标识的称为复位报文段URG紧急指针是否有效 16 位窗口大小16 位校验和发送端填充CRC 校验。接收端校验不通过则认为数据有问题此处的检验和不光包含 TCP 首部也包含TCP 数据部分.16 位紧急指针标识哪部分数据是紧急数据;40 字节头部选项暂时忽略 下面的是Linux源代码中tcp报头的定义
struct tcphdr {__be16 source; // 源端口号__be16 dest; // 目的端口号__be32 seq; // 序列号__be32 ack_seq; // 确认号
#if defined(__LITTLE_ENDIAN_BITFIELD)//使用了位段__u16 res1:4, // 保留位doff:4, // 数据偏移头部长度以32位字为单位fin:1, // FIN标志结束连接syn:1, // SYN标志同步序列号rst:1, // RST标志重置连接psh:1, // PSH标志Push函数ack:1, // ACK标志确认字段有效urg:1, // URG标志紧急指针字段有效ece:1, // ECN回显标志cwr:1; // 拥塞窗口减少标志
#elif defined(__BIG_ENDIAN_BITFIELD)__u16 doff:4, // 数据偏移头部长度以32位字为单位res1:4, // 保留位cwr:1, // 拥塞窗口减少标志ece:1, // ECN回显标志urg:1, // URG标志紧急指针字段有效ack:1, // ACK标志确认字段有效psh:1, // PSH标志Push函数rst:1, // RST标志重置连接syn:1, // SYN标志同步序列号fin:1; // FIN标志结束连接
#else
#error Adjust your asm/byteorder.h defines
#endif__be16 window; // 窗口大小__sum16 check; // 校验和__be16 urg_ptr; // 紧急指针
};2. 详解TCP
2.1 4位首部长度
4位首部长度 标准报头长度 选项长度单位是4字节。
4个比特位可表示的范围是 [015]可表示的大小就是 [060]字节由于标准报头占 20 字节所以4位首部长度的范围是 [20,60]。 所以TCP解包时先读取报文的前20字节然后再根据4位首部长度将报头选项提取出来剩下的就是有效载荷的长度。
2.2 32位序号与32位确认序号确认应答机制
首先我们要知道32位序号是用来保证收到的报文的可靠性的对历史报文的可靠性。
TCP中的可靠性主要是依靠确认应答实现的否则发送方不知道自己发送的报文是否被收到了。
只要发送端收到了应答说明发送的数据一定被收到了可靠性也就保证了。接收端无需关心自己的应答是否可靠如果不可靠发送端会重发数据如果可靠发送端就发新的数据了
那什么是确认呢 确认至少是一个“裸”的tcp报头 32位序号又是什么呢
根据我们上面所说的一条请求对应一条应答没有收到应答就会重新发送请求如果是串行的话效率就太低了所以TCP选择的是并行发送。 并行发送会存在一个问题不知道应答对应哪一条请求所以必须对请求编号这个编号就是32位序号
32位确认序号就是对报文的序号1表示序号之前的内容已经收到了。 序号与确认序号不一定是一对一的多个序号可能只会有一条确认序号表示该序号之前的内容已全部收到 序号存在的另一个原因保证报文的按序到达 报文如果到达后是乱序的这也是不可靠的的表现所以可以根据序号排序然后按顺序入缓冲区。 可是报头中为什么要有两个32位序号呢一个也够用呀 两个32位序号是为了实现捎带应答机制。接收端应答的同时也想捎带着给发送端发送数据。 所以TCP报文在很大概率上既是应答也是数据。 那序号又是如何产生的呢
2.3 超时重传机制 主机 A 发送数据给 B 之后可能因为网络拥堵等原因数据无法到达主机 B如果主机 A 在一个特定时间间隔内没有收到 B 发来的确认应答就会进行重发
但是主机 A 未收到 B 发来的确认应答 也可能是因为应答丢失了 因此主机 B 会收到很多重复数据。那么 TCP 协议需要能够识别出那些包是重复的包 并且把重复的丢弃掉。 这时候我们可以利用前面提到的序列号 就可以很容易做到去重的效果。
所以为了降低重复率不能让发送方一直发需要设定一个时间超过这个时间后发送端再发这种机制叫做超时重传机制。
那超时的时间如何确定呢? 最理想的情况下 找到一个最小的时间 保证 “确认应答一定能在这个时间内返回”。但是这个时间的长短随着网络环境的不同是有差异的。 如果超时时间设的太长会影响整体的重传效如果超时时间设的太短有可能会频繁发送重复的包。 TCP 为了保证无论在任何环境下都能比较高性能的通信因此会动态计算这个最大超时时间
Linux 中(BSD Unix 和 Windows 也是如此)超时以 500ms 为一个单位进行控制每次判定超时重发的超时时间都是 500ms 的整数倍。 如果重发一次之后 仍然得不到应答 等待 2*500ms 后再进行重传。如果仍然得不到应答等待 4*500ms 进行重传 依次类推 以指数形式递增。累计到一定的重传次数 TCP 认为网络或者对端主机出现异常强制关闭连接。 2.4 连接管理机制(3次握手、4次挥手 3个标志位)
在正常情况下TCP 要经过三次握手建立连接四次挥手断开连接。 在正式学习握手、挥手之前先了解报头中的几个标志位。
在TCP报头中有6个标志位用来区分接收端收到的TCP报文的类型 (可能有多个发送端)。 ACKacknowledgement
表明自己是一个确认报文让对方关心确认序号。 因为有捎带应答机制所以大部分的TCP报文的ACK标志位都为1
SYNsynchronize
同步标志位即表明是一个建立连接的请求
FINfinish
表明自己是一个断开连接的请求一般用于通信结束时。 双方建立连接首先要进行3次握手 举个栗子 男你愿意做我女朋友吗 女好呀什么时候开始 男就现在 在上面的例子中双方用了最小的握手次数建立了关系这就叫做三次握手 双方断开连接首先要进行4次挥手 举个栗子 女我们分手吧 男好 男我也要跟你分手 女好 为什么叫做四次挥手 - 因为断开连接需要征得双方的同意 因为TCP是全双工的要关闭两个朝向上的连接 3次握手是由操作系统自动完成的。
服务器端accept返回后连接已经建立完成了。即accept等3次握手完成它不参与3次握手。 客户端connect调用后触发操作系统让操作系统发送SYN双方握手完成connect返回。 只要客户端发出去SYN它的状态就变成了SYN_SENT客户端发出去ACK就认为自己把连接建立好了状态变为established。客户端不保证发送的ACK一定能被收到所以3次握手本质就是在赌因为3次握手本来就不一定成功 服务端未收到ACK但发送端以为连接建立成功了发送端此时就会发送数据但是服务端不认识它会通过标志位RST要求重新建立连接。 一般服务端只要收到了SYN它的状态就变成SYN_RECV它收到客户端的ACK后才认为连接建立完成。所以一般是客户端认为连接先建立好。 有了四次挥手的理解3次握手的本质其实也是四次握手
所以为什么要3次握手呢
建立连接要征得双方的同意因为TCP是全双工的要建立两个朝向上的连接在3次握手期间正式通信之前双方验证了全双工信道的通畅性客户端与服务端的IO是正常的即网络是通畅的
谈了这么多到底什么是连接呢 一条连接一定会和一个文件对应因为一个连接对应一个文件描述符。那么连接在操作系统内就会存在很多个操作系统一定要管理连接。先描述在组织创建连接的struct在struct内部一定会有一个字段来表示连接的状态。 下面我们再来看一下4次挥手 介绍一个系统调用shutdown可控制关闭连接的读写端 我们具体是使用close还是shutdown取决于应用层。
在服务器这边如果不调用close关闭sockfd那就只会进行两次挥手server会一直处于close_wait状态会造成文件描述符泄漏、内存泄漏问题。
当服务器关闭后server会进入last_ack状态可是此时客户端早就关闭了没人给它应答了那么服务端在一段时间后自动进入closed状态。
那客户端的time_wait状态是什么意思呢 在四次挥手时主动断开连接的一方会进入time_wait状态要等待一个 2MSL(Max Segment Life报文最大生存时间)才会进入 CLOSED 状态 为什么会这样呢举个例子 在有些情况下双方都关闭后接收端重启并与发送端建立连接后发送方被判定为超时的报文可能又到达了。为了防止报文被接收端误处理发送方需要等待2MSL后才可再次启动。 等待2MSL的目的是 等待历史的游离报文在网络中消散若time_wait状态下的ACK丢了那么就可以以最快的速度重新发送尽可能正常的完成4次挥手断开连接 为什么是2MSL呢MSL不行吗 理想情况下1个MSL时间足以确保一个报文在网络中消散 报文在网络中传输时会经历各种延迟包括路由器处理延迟、链路传输延迟等。这些延迟是不确定的可能会导致报文在较长时间内仍然存在于网络中。 等待2MSL时间可以确保旧连接的所有报文包括丢失的报文和重传的报文在网络中完全消失。 假设MSL为30秒丢失的报文一个报文在接近30秒时丢失。重传的报文发送方在超时后假设超时时间为1秒重传该报文重传的报文也会在网络中传输其生存时间也是30秒。 总时间因此最坏情况下报文的总生存时间是30秒丢失的报文 30秒重传的报文 60秒。 如果ACK报文丢失被动关闭方重传的FIN报文也需要在网络中传输这同样需要一个MSL时间。因此总共需要2MSL时间来确保ACK报文的可靠传输和FIN报文的重传处理。 在我们前面写代码时端口号绑定失败的原因 当服务端主动关闭后其进入time_wait状态即进程没有退出端口号被占用了。若想使用旧端口号可以通过系统调用 setsockopt()设置套接字的类型 可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看 msl 的值
2.5 16位窗口大小流量控制
接收端处理数据的速度是有限的。如果发送端发的太快导致接收端的缓冲区被打满这个时候如果发送端继续发送就会造成丢包继而引起丢包重传等等一系列连锁反应不做任何处理则会浪费了各种资源(网络带宽、CPU等等)。 因此 TCP 支持根据接收端的处理能力来决定发送端的发送速度这个机制就叫做流量控制。 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段 窗口大小字段越大 说明网络的吞吐量越高发送端接受到这个窗口之后 就会提高自己的发送速度接收端一旦发现自己的缓冲区快满了就会将窗口大小设置成一个更小的值通知给发送端发送端接受到这个窗口之后 就会减慢自己的发送速度如果接收端缓冲区满了就会将窗口置为 0这时发送方不再发送数据但是需要定期发送一个窗口探测数据段使接收端把窗口大小告诉发送端。双方都要进行流量控制首次发送如何知道对方的接收能力呢 三次握手时是做过报文交换与窗口协商的 接收端如何把窗口大小告诉发送端呢? TCP 首部中有一个 16 位窗口大小字段就是存放了窗口大小信息(即自己接收缓冲区中剩余空间的大小) 那么问题来了16 位数字最大表示 65535, 那么 TCP 窗口最大就是 65535 字节么? 实际上TCP 首部 40 字节选项中还包含了一个窗口扩大因子 M实际窗口大小是窗口字段的值左移 M 位; 2.6 滑动窗口
在我们讨论了确认应答策略时 对每一个发送的数据段都要给一个 ACK 确认应答收到 ACK 后再发送下一个数据段(串行发送)。 这样做有一个比较大的缺点就是性能较差尤其是数据往返的时间较长的时候。
我们说TCP是采用并行发送的它是怎么实现的呢流量控制又是怎么实现的呢 - - 滑动窗口
窗口大小指的是无需等待确认应答就可以继续发送数据的最大值。 下图的窗口大小就是 4000 个字节(四个段) 发送前四个段的时候, 不需要等待任何 ACK, 直接发送;收到第一个 ACK 后 滑动窗口向后移动start ACK继续发送第五个段的数据(end start 16位窗口大小)依次类推;操作系统内核为了维护这个滑动窗口需要开辟发送缓冲区来记录当前还有哪些数据没有应答只有确认应答过的数据才能从缓冲区删掉窗口越大则网络的吞吐率就越高窗口越小网络的吞吐率越低。流量控制 此时就是并行发送的了
那么如果出现了丢包如何进行重传这里分两种情况讨论
情况一: 数据包已经抵达 ACK 被丢了 这种情况下 部分 ACK 丢了并不要紧因为可以通过后续的 ACK 进行确认;
情况二数据包就直接丢了 当某一段报文段丢失之后发送端会一直收到 1001 这样的 ACK就像是在提醒发送端 “我想要的是 1001” 一样滑动窗口会先向右移动到已经发送成功处然后补发丢失的报文。 如果发送端主机连续三次收到了同样一个 “1001” 这样的应答 就会将对应的数 据 1001 - 2000 重新发送;这个时候接收端收到了 1001 之后, 再次返回的 ACK 就是 7001 了(因为 2001 - 7000)接收端其实之前就已经收到了 被放到了接收端操作系统内核的接收缓冲区中 这种机制被称为 “高速重发控制”(也叫 快重传). 既然有了快重传它既快又能重传那为什么还要超时重传呢 快重传是有条件的要连续三次收到同一个应答 万一发送方只发送了2个报文呢最多就只能收到2个应答呗那就无法触发快重传只能超时重传。所以超时重传是兜底的快重传是提高效率的。 2.7 3个标志位 16位紧急指针
有了上面的理解我们来了解一下TCP报头中剩余的3个标志位
PSHpush
在进行流量控制时如果接收方的缓冲区已满那发送方也就只能发送探测报文没有别的办法了。 为了告诉对方请尽快将缓冲区中的数据交给上层就引入了PSH标志位也可利用PSH标志位告诉对端我的数据比较重要请尽快交付。
RSTreset
重置连接重新三次握手
在三次握手时服务端未收到ACK但发送端以为连接建立成功了发送端此时就会发送数据但是服务端不认识它会通过标志位RST要求重新建立连接。
URGurgent
表示紧急报文优先让上层从缓冲区中读取。
那紧急数据在哪里呢 在TCP报头中有16位紧急指针表示紧急数据在有效载荷中的偏移量通过它就可以获取紧急数据。
但是只有紧急数据的起始地址紧急数据有多长呢? TCP允许插队但不允许过度插队 紧急数据只占一个字节 以后可以在紧急数据中设置状态码如终止连接、暂停上传等等 在系统调用recv中可以设置标志位MSG_OOB来读取紧急数据。 2.8 拥塞控制
虽然 TCP 有了滑动窗口这个大杀器能够高效可靠的发送大量的数据但是如果在刚开始阶段就发送大量的数据仍然可能引发问题。
因为网络上有很多的计算机可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下贸然发送大量的数据是很有可能引起雪上加霜的。 所以TCP使用拥塞控制来考虑网络的健康状况 一旦发送的报文大量丢失则会被判定为网络拥塞。 大量报文丢失后能不能直接重传呢- - - 不能因为可能会造成网络更加的拥堵应该等一等 TCP 引入慢启动机制先发少量的数据探探路摸清当前的网络拥堵状态再决定按照多大的速度传输数据。 此处引入一个拥塞窗口的概念拥塞窗口是衡量网络拥堵的指标。
发送开始的时候定义拥塞窗口大小为 1每次收到一个 ACK 应答拥塞窗口加 1 倍
滑动窗口 min (拥塞窗口对端接收缓冲区剩余空间的大小)
像上面这样的拥塞窗口增长速度是指数级别的。“慢启动” 只是指初使时慢但是增长速度非常快 (指数级增长)。 可是为什么使用指数级增长呢 指数增长的特点是前期慢后期快既然前面慢速度发送的都没有问题那就应该尽快进行网络的恢复。 但是为了不增长的那么快不能使拥塞窗口单纯的加倍此处引入一个叫做慢启动的阈值当拥塞窗口超过这个阈值的时候不再按照指数方式增长而是按照线性方式增长 拥塞控制算法 慢启动 加法增大 乘法减小
可是这个拥塞窗口为什么一直在试探性的增大呢 拥塞窗口是网络健康状况的评估值网络的状况是一直在变化的所以要反复的试探尽量让下一次的阈值高一点。 拥塞控制归根结底是 TCP 协议想尽可能快的把数据传输给对方但是又要避免给网络造成太大压力的折中方案。
2.9 延迟应答
接收端收到数据后如果接收数据的主机立刻返回 ACK 应答这时候返回的窗口可能比较小(上层未取走刚接收到的报文)
假设接收端缓冲区为 1M一次收到了 500K 的数据如果立刻应答返回的窗口就是 500K;但实际上可能处理端处理的速度很快, 10ms 之内就把 500K 数据从缓冲区消费掉了在这种情况下接收端处理还远没有达到自己的极限 即使窗口再放大一些 也能处理过来;如果接收端稍微等一会再应答比如等待 200ms 再应答 那么这个时候返回的窗口大小就是 1M;一定要记得 窗口越大 网络吞吐量就越大 传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么? 肯定也不是 数量限制: 每隔 N 个包就应答一次;时间限制: 超过最大延迟时间就应答一次;具体的数量和超时时间依操作系统不同也有差异一般 N 取 2超时时间取 200ms; 2.10 其它
2.10.1 面向字节流
创建一个 TCP 的 socket同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区 调用 write 时 数据会先写入发送缓冲区中 如果发送的字节数太长会被拆分成多个 TCP 的数据包发出;如果发送的字节数太短就会先在缓冲区里等待等到缓冲区长度差不多了或者其他合适的时机发送出去;接收数据的时候数据也是从网卡驱动程序到达内核的接收缓冲区然后应用程序可以调用 read 从接收缓冲区拿数据;另一方面TCP 的一个连接既有发送缓冲区也有接收缓冲区那么对于这一个连接既可以读数据也可以写数据这个概念叫做全双工 由于缓冲区的存在, TCP 程序的读和写不需要一一匹配例如: 写 100 个字节数据时可以调用一次 write 写 100 个字节 也可以调用 100 次write每次写一个字节;读 100 个字节数据时也完全不需要考虑写的时候是怎么写的既可以一次read 100 个字节 也可以一次 read 一个字节重复 100 次具体传输的数据是什么由上层解释。 2.10.2 粘包问题
首先要明确粘包问题中的 “包” 是指的应用层的数据包。 在 TCP 的协议头中没有如同 UDP 一样的 “报文长度” 这样的字段 但是有一个序号这样的字段站在传输层的角度TCP 是一个一个报文过来的按照序号排好序放在缓冲区中站在应用层的角度看到的只是一串连续的字节数据那么应用程序看到了这么一连串的字节数据就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包 那么如何避免粘包问题呢? 归根结底就是一句话明确两个包之间的边界 对于定长的包保证每次都按固定大小读取即可那么就从缓冲区从头开始按固定大小依次读取即可;对于变长的包可以在包头的位置约定一个包总长度的字段从而就知道了包的结束位置;对于变长的包还可以在包和包之间使用明确的分隔符(应用层协议是程序猿自己来定的只要保证分隔符不和正文冲突即可) 思考: 对于 UDP 协议来说是否也存在 “粘包问题” 呢? 对于 UDP如果还没有给上层交付数据UDP 的报文长度仍然在同时UDP 是一个一个把数据交付给应用层就有很明确的数据边界.站在应用层的站在应用层的角度使用 UDP 的时候 要么收到完整的 UDP 报文要么不收不会出现半个的情况 2.10.3 异常情况
进程终止进程终止会释放文件描述符仍然可以发送 FIN和正常关闭没有什么区别机器重启和进程终止的情况相同.机器掉电/网线断开接收端认为连接还在一旦接收端有写入操作接收端发现连接已经不在了就会进行 reset。即使没有写入操作 TCP 自己也内置了一个保活定时器会定期询问对方是否还在如果对方不在也会把连接释放 - - - 连接保活机制。应用层的某些协议也有一些这样的检测机制。例如 HTTP 长连接中也会定期检测对方的状态。例如 QQ在 QQ 断线之后也会定期尝试重新连接
3. TCP/UDP 对比
TCP/UDP 对比
我们说了 TCP 是可靠连接那么是不是 TCP 一定就优于 UDP 呢? TCP 和 UDP 之间的优点和缺点。不能简单、绝对的进行比较
TCP 用于可靠传输的情况应用于文件传输重要状态更新等场景UDP 用于对高速传输和实时性要求较高的通信领域例如早期的 QQ、视频传输等另外 UDP 可以用于广播;
归根结底TCP 和 UDP 都是程序员的工具什么时机用具体怎么用还是要根据具体的需求场景去判定
基于 TCP 应用层协议 HTTPHTTPSSSHTelnetFTPSMTP 用 UDP 实现可靠传输(经典面试题)
先根据应用场景确定具体的应用需求可靠性要保障到什么程度再参考 TCP 的可靠性机制 在应用层实现类似的逻辑; 例如:引入序列号, 保证数据顺序;引入确认应答, 确保对端收到了数据;引入超时重传, 如果隔一段时间没有应答, 就重发数据;…
