广州市筑正工程建设有限公司网站,seo的优化方案,北京市建设厅门户网站,常州网站制作优化Linux【网络编程】之深入理解TCP协议 TCP协议TCP协议段格式4位首部长度---TCP报头长度信息 TCP可靠性#xff08;确认应答#xff09; 提高传输效率确认应答(ACK)机制32位序号与32为确认序号 16位窗口大小---自己接收缓冲区剩余空间的大小16位紧急指针---紧急数据处… Linux【网络编程】之深入理解TCP协议 TCP协议TCP协议段格式4位首部长度---TCP报头长度信息 TCP可靠性确认应答 提高传输效率确认应答(ACK)机制32位序号与32为确认序号 16位窗口大小---自己接收缓冲区剩余空间的大小16位紧急指针---紧急数据处理6位标记位---区分TCP报文类型超时重传机制 连接管理机制三次握手四次挥手与地址复用 流量控制滑动窗口拥塞控制与拥塞窗口延迟应答捎带应答面向字节流粘包问题TCP异常情况TCP小结连接队列与listen 的第二个参数 TCP协议
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制
TCP协议段格式 源端口,目的端口OS给的也就是我前面模拟基于tcp的应用层协议为什么要用16位端口号
16位校验和: 发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
16位紧急指针: 这个指针指向了紧急数据最后一个字节的下一个字节
4位首部长度—TCP报头长度信息 tcp协议是有标准长度的20字节但是报头中可能含有选项选项占一定字节也就是说报头的长度是变化的最小是20字节 当服务端收到报文后转化成一个结构化的数据就可以得到标准报头中的四位首部长度 TCP约定TCP报头总长度四位首部长度*4字节因此TCP报头长度范围是[20,60]字节。 假设报头是20字节那么首部长度就是5即0101 基于上面两条就可以得到选项的字节四位首部长度*4-20 报头全部读取完毕就可以得到有效载荷
TCP协议的解包参考以上封装就是添加报头信息同UDP分用就是根据目的端口号找到应用层对应的进程交给它 收到的报文是如何找到曾经bind过的特定port进程的 应用层维护一张port哈希表当有端口号到来就会查表找到对应进程PCB TCP可靠性确认应答 提高传输效率
网络传输中因为距离变长存在着不可靠问题常见的不可靠场景有丢包、乱序、校验错误、重复等
确认应答(ACK)机制
TCP收发消息最基本的工作模式发一个新消息给一件应答 双方再进行通信的时候除了正常的数据段还有可能带有确认数据段对于确认数据段不需要再次应答
32位序号与32为确认序号
TCP层双方通信是对等的像HTTP层客户端只能请求服务端只能应答地位是不对等的而TCP层双方都是确认应答无论是正常数据段还是确认数据段都有方式标识数据段本身只不过是包不包括数据的区别 确认应答确认序号接收方已经收到了ACK序号之前的所有(真的报文且连续)报文 例如ACK:14表示已经收到了14号报文之前的所有报文下次从14开始发 TCP将每个字节的数据都进行了编号. 即为序列号 每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发 为什么要有两组序号 这是因为TCP是全双工的当Client向Server发送的时候Client的序号与Server的确认序号为一组Server也可以向Client发送Server的序号与Client的确认序号又成为一组如下图
16位窗口大小—自己接收缓冲区剩余空间的大小
前面我们说到TCP协议有两个缓冲区发送缓冲区和接收缓冲区当双方进行通信的时候需要把数据拷贝到缓冲区内交给对方的接受缓冲区对方再交付给上层。如果发送过快或者过慢就会影响传输效率 在报头中有一个16位窗口大小的字段供发送方使用里面填写自己的接收缓冲区大小正因为不知道对方的才要填自己的来获取对方的构建的报文都是要发送给对方的这样就就换了双方的接收缓冲区剩余大小也就可以进行流量控制 由于窗口大小与缓冲区挂钩所以一次只能发64KB的数据如果想要扩容需要研究“选项”字段这里不做讨论
16位紧急指针—紧急数据处理
当报文中有紧急数据需要处理的时候(不是所有的有效载荷是有效载荷的一部分)会将报头中urg标记位置为116位紧急指针作为偏移量指向有效载荷中的紧急数据的下一字节TCP紧急指针指向的数据只能有一个字节也就是说根据偏移量找到数据后只有一个字节的数据是紧急数据
6位标记位—区分TCP报文类型
TCP报文是有类型的6位标记位就是来区分不同类型的报文 SYN: 同步标记位默认为0只有在建立连接的时候被置为1三次挥手再详谈 FIN: 断开连接标记位四次挥手详谈 ACK: 确认标记位报文带有确认就会将此标记为置1 PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走 URG: 紧急指针是否有效
RST: 复位标记位对方要求重新建立连接; 我们把携带RST标识的称为复位报文段 当客户端和服务器建立连接、断开连接的时候有可能会失败即使成功通信过程一方也可能会出问题假设服务端出现问题断开重启但是客户端并不知道依旧发送报文服务端就会发送相应报文携带RST标记位告诉客户端重新建立连接。同理客户端如果断开会给服务端发信息
超时重传机制
第一种主机A给主机B发送数据但是没有到达主机B经过特定的时间间隔没有收到来自B的确认应答就会再次给B发送数据 第二种 主机A给主机B发送数据主机B收到了给A确认应答,但是A没有收到在A看来与第一种一样过段时间再次给B发送数据 A是根据时间间隔来判断是否丢包的 前面说到重复也是不可靠的一种那么超时重传机制中B主机会收到重复数据就会曾经提到过的序列号来去重 被发出的数据不会被立即移除(为了超时重传)需要收到应答才能移除
连接管理机制 三次握手
在前面我提到过三次握手只是手段不是目的也就是说三次握手不一定会成功 在上图中三条报文前两条不用担心丢失超时重传机制需要考虑的是第三条报文丢失的情况 为什么需要三次握手一次两次四次不可以吗 一次不可以 如果只需要一次握手就会导致服务器收到来自同一个客户端多个链接服务器需要维护这些链接成本太高----SYN洪水 两次不可以 1.二次握手的话可能出现第二条报文丢失的情况导致客户端再给服务器发送连接请求出现同上的问题 2.还有一种情况是第一条报文因为延迟长时间未到服务端客户端再发一条报文与服务端建立连接进行通信当断开连接的时候之前的第一条报文到了服务端就会给客户端发送带有ACK字段的报文但是此时客户端已经断开连接了这就会让服务端一直等待造成资源浪费 三次可行 1.通信之前需要验证信道是全双工的而三次握手就是用最小成本验证该信道是通畅的 第一条可以验证客户端是可以发送的服务端是可以收到的 第二条可以验证客户端是可以收到的这里服务端虽然发送了但是无法确认被客户端收到了 第三条可以验证服务端是可以发送的 2.三次握手可以有效防止单主机对服务器进行攻击最后一条报文保证了客户端先建立好连接然后服务器建立好连接保证收到同等伤害 四次可以但没必要 1.三次握手已经最小成本建立成功了四次就显得多余了 2.如果是四次握手那么就会导致最后一条是服务端发送的如果一直丢失就会导致服务端连接一一直挂着与两次握手一样有隐患
四次挥手与地址复用
主动断开的一方最终状态是TIME_WAIT状态 被动断开的一方两次挥手完成后会进入CLOSE_WAIT状态 由于TCP双方对等主动、被动C/S都有可能 如果服务器出现了大量的close_wait原因有 1.服务器存在bug没有做close文件描述符 2.服务器有压力可能一直推送消息给client导致来不及close
当关闭服务器的时候系统层面会去执行第三次第四次挥手完成断开连接 四次挥手已经完成主动断开的一方会维持一段时间的TIME_WAIT状态等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态我们使用CtrlC终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口也就不能绑定同样的端口 解决办法添加地址复用 使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符
//设置地址复用
int opt1;
setsockopt(listen_sockfd_,SOL_SOCKET,SO_REUSEADDR,opt,sizeof(opt));为什么是TIME_WAIT的时间是2MSL?
MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的;同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重发LAST_ACK);
流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被充满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段, 通过ACK端通知发送端窗口大小字段越大, 说明网络的吞吐量越高;接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度;如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.
在TCP三次握手阶段完成窗口大小的交换未来通信的时候就可以控制发送数据大小
滑动窗口
前面我提到过发送的数据未收到应答之前会将数据暂时保存起来而保存的位置就是发送缓冲区根据课本上讲的可以将缓冲区分为以下几段 对上图进行抽象可以处理成一个一维数组而滑动窗口就是就是两个数组下标滑动窗口的移动就是数据下标的更新 滑动窗口的大小如何设置 滑动窗口大小和对方接受能力有关 滑动窗口会向左移动吗一直向右移动吗 不会向左也不会一直向右移动存在不动的情况 窗口会一直不变吗会变大吗会变小吗依据是什么 不会一直不变可能变大可能变小依据是对方接收缓冲区大小 如上图当收到对方发来的确认序号的时候滑动窗口start端会向右移动如果接收方此时接受了但是没有取出就会导致接收方缓冲区越来越小也就导致了发送方窗口大小越来越小。 当越来越小缩小为0的时候接收方把它接受缓冲区数据全拿走这个时候发送方滑动窗口就会增大
收到应答确认的时候如果不是最左端发送的报文的确认而是中间的结尾的该怎么办要滑动吗 以上存在两种丢包情况
数据没丢只是应答丢失了 根据确认应答机制确认序号表示当前序号1之前的数据已经收到了不需要再管之前的这个时候滑动窗口start端直接到确认序号的下一位置进行滑动数据丢了 如果数据真的丢了那么中间报文收到的确认序号一定是前面丢失报文的序号连续收到三个一样的这个时候就需要补发了滑动窗口不需要滑动
滑动窗口一直滑动剩余空间不够了怎么办 滑动窗口其实被内核组织成环形结构
拥塞控制与拥塞窗口
TCP连接的可靠性不仅考虑了主机之间的问题也考虑了网络的问题
少量的丢包, 我们仅仅是触发超时重传; 大量的丢包, 我们就认为网络拥塞
如果网络比较拥堵发送大量数据可能会引起大量丢包TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据
发送数据不仅要考虑点到点还需要考虑网络状况引入拥塞窗口发送开始的时候, 定义拥塞窗口大小为1指数级别的. “慢启动” 只是指初使时慢, 但是增长速度非常快.当拥塞窗口超过阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长
发送方----网络----接收方 发送方拥有滑动窗口网络拥有拥塞窗口接受方有自己的窗口大小 滑动窗口大小取决于MIN(拥塞窗口,接收方窗口大小)
拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案
延迟应答
如果接收数据的主机立刻返回ACK应答, 这时候返回的窗口可能比较小.
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;
如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M; 窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么? 肯定也不是;
数量限制: 每隔N个包就应答一次;时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms需要考虑超时重传机制
捎带应答
三次握手中服务端回复的时候SYNACK就是捎带应答不是一问一答
面向字节流
创建一个TCP的socket, 同时在内核中创建一个发送缓冲区和一个接收缓冲区;
调用write时, 数据会先写入发送缓冲区中;如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;然后应用程序可以调用read从接收缓冲区拿数据;另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配,这就是面向字节流
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;
粘包问题
首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包. 在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段. 站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中. 站在应用层的角度, 看到的只是一串连续的字节数据. 那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包. 如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界. 1.对于定长的包, 保证每次都按固定大小读取即可; 每次读取就从缓冲区从头开始按sizeof(包长)依次读取即可; 2.对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置; 3.对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可)
TCP异常情况
进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.机器重启: 和进程终止的情况相同.机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放. 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接.
TCP小结
为什么TCP这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能. 可靠性:校验和、序列号(按序到达)、确认应答、超时重发、连接管理、流量控制、拥塞控制 提高性能:滑动窗口、快速重传、延迟应答、捎带应答流量控制、拥塞控制 其他:定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)
连接队列与listen 的第二个参数
TCP协议要为上层维护一个链接队列这个队列不能没有也不能太长这个连接队列叫做全连接队列相当于咱们日常吃饭排队等待
int listen(int sockfd, int backlog);sockfd表示要监听的套接字描述符。 backlog指定在等待被接受的连接队列中允许的最大连接数。
TCP底层允许backlog1个完整链接后续来的都只能是半连接状态即三次握手中的SYN_RCVD状态 并添加到半连接队列如果后续还没完成连接就会被Server关闭转变为close_wait状态
Linux内核协议栈为一个tcp连接管理使用两个队列:
半链接队列当客户端发起 SYN 到服务端服务端收到以后会回 ACK 和自己的 SYN。这时服务端这边的 TCP 从 listen 状态变为 SYN_RCVD 此时会将这个连接信息放入【半连接队列】全连接队列accpetd队列用来保存处于established状态,包含了服务端所有完成了三次握手但是还未被应用调用 accept 取走的连接队列这也说明了accept并不参与三次握手 全连接队列的长度是listen的第二个参数1全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了
区别全连接队列中的连接和已建立好的连接就像是排队等待的人和已经进入饭店吃饭的人这个队列相当于一个连接缓冲区上层服务完毕的时候可以从缓冲区取出新连接
