一篇文章搞懂TCP协议

TCP概述

  • 面向连接的运输层协议:应用程序在使用TCP协议之前,必须先建立TCP连接,数据传输完毕后,必须释放已建立的TCP连接
  • 点对点:TCP连接只能有两个端点,一对一
  • 可靠:通过TCP连接传输的数据,无差错、不丢失、不重复、按需到达
  • 全双工通信:连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据
  • 面向字节流:数据通过自己序列发送,发送和接收的字节流顺序必须完全一致

TCP报文段的首部格式

  • 源端口和目的端口:各占2个字节
  • 序号:占4字节,范围是0~2的32次方减1,TCP在传输过字节流的每一个字节都按顺序编号,编号循环使用
  • 确认号:占4字节,期望收到对方下一个报文的数据字节的序号
  • 数据偏移:占4位,标记报文段的数据起始处距离报文段的起始处的距离
  • 保留:占6位
  • 紧急URG:当URG为1时,表明紧急指针字段有效,它告诉接收方此报文段有紧急数据,必须优先接收,此时该报文不再需需要按照原定的顺序排队,直接插入到本报文数据的最前面,优先处理(比如Control + C命令)
  • 确认ACK:TCP规定,在连接建立后,所有传送的报文段都必须把ACK置为1
  • 推送PUSH:当输出某些指令后立即需要收到对方响应,在这种情况下,TCP就可以使用push操作,发送方把PUSH置为1,并立即创建一个报文发送出去,接收方收到PUSH为1的报文段时,就立即将缓冲区的报文交付给应用进程,而不再等到整个缓冲区都填满后再向上交付
  • 复位RST:当RST为1时,表明TCP连接中出现严重差错,必须释放连接重新建立连接,可用于拒绝非法报文或非法连接
  • 同步SYN :在建立连接时用来同步序列号,当SYN=1而ACK=0时,表明建立连接请求,若对方同意建立连接,则应该在响应的报文段中使用SYN=1和ACK=1
  • 终止FIN:用来释放连接,当FIN=1时,表示此报文发送方的数据已经发送完毕,请求释放TCP连接
  • 窗口:占2个字节,窗口值作为接收方让发送方设置其发送窗口的依据,可靠传输和流量控制都依赖窗口实现(后面详细说)
  • 检验和:计算检验和时要在TCP报文段前面加上伟首部,用来检验传输数据是否有错
  • 紧急指针:占2个字节,在URG=1时才有意义,标记紧急报文中的紧急数据的字节数,紧急数据结束后就是普通数据
  • 选项:规定每个报文段中的数据字段的最大长度MSS,一般在建立连接时,双方将自己能够支持的MSS写入选项中,以后就按照这个数据传输数据。
  • 数据

报文段首部格式一定要记住,至少要大概理解后,再带着疑问去看下边,否则看下边有可能会一脸懵逼。

TCP可靠传输的实现

                                                     

       TCP的可靠传输通过滑动窗口实现,滑动窗口以字节为单位。凡是已发送过的数据,在未收到确认之前都必须暂时保留,以便在超时重传时使用,窗口越大,发送方就可以在收到对方确认之前连续发送更多的数据,获得更高的传输速率。滑动窗口可以分为四部分:

  • 已发送并搜到确认
  • 已发送未收到确认
  • 允许发送但尚未发送
  • 不允许发送

       窗口依赖三个指针,P1,P2和P3,小于1的是已经发送并收到确认的字节,1和2之间的是已发送但未收到确认的字节,2和3之间是允许发送但尚未发送但字节,大于3为不允许发送的字节,1和3之间的字节数即为接收方规定的滑动窗口大小(流量控制)。接收方B只能对按需收到的最高序号给出确认,当指针2和指针3重合时,发送方必须停止发送数据,等待接收方的确认,为了保证可靠传输,A必须等到B的确认才能继续发送数据,为了保证发送方不会一直等待,到达依赖超时计时器(动态计算超时重传时间)规定的时间后,就重传这部分数据,直到收到接收方B的确认。

超时重传时间的选择采用一个自适应算法,它会记录一个报文段发出的时间,以及收到响应的确认的时间,作为往返时间RTT,计算为加权平均往返时间RTTs,RTTd为RTT的偏差的加权平均值,通过这几个值计算得到超时重传时间RTO。计算的规则是:报文段每重传一次,就把超时重传时间RTO增大一些,当不再发生报文段的重传时,根据下面公式计算RTO。

                                                                            RTO = RTTs + 4 * RTTd

TCP的流量控制

        流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收,利用滑动窗口实现。发送方的发送窗口不能超过接收方给出的接收窗口大小。当接收方接收能力下降时,会缩小自己的接收窗口,发送方通过报文头部的串口字段告知发送方。

       还以上面发送方为A,接收方为B作为例子,当B的接收缓存满之后,将自己的接收窗口置为0,通过报文的窗口字段告知发送方A,过了一段时间后,B的应用程序将接收缓冲区的数据处理了一部分,接收窗口又有了空间,假设为300,此时B向A发送报文告知对方接收窗口为300,如果该报文在传输中丢失了,A不会一直傻傻地等待,在A收到B的0窗口报文后,就会开启该连接设定的持续计时器,当超过计时器规定的时间后,A会向B发送一个0窗口探测报文段,B在收到这个探测报文后,会重新发送300的窗口报文段。此时有人会问,B的接收窗口大小为0了,怎么还能接收0窗口探测报文段?这里需要记住:TCP规定,即使接收窗口为0,也必须可以接收0窗口探测报文段、ACK=1的报文段和URG=1的报文段

TCP的拥塞控制

                                                   

TCP进行拥塞控制的算法有4个:慢开始、拥塞避免、快重传、快恢复。

  1. 慢开始:将拥塞窗口大小设置为1个发送方的最大报文段MSS(上面说过哈,报文首部的选项字段),每经过一个传输轮次,拥塞窗口就加倍,直到达到慢开始门限后开启拥塞避免。
  2. 拥塞避免:当达到慢开始门限后,每收到一次接收方的确认ACK,就将拥塞窗口大小+1,直到网络出现超时后,将慢开始门限调整为原来的一半,执行慢开始算法。
  3. 快重传:快重传算法可以让发送方尽早知道发生了个别报文段的丢失。由于接收方必须对发送方每个报文回复确认ACK,假设发送方以此发送M1、M2、M3、M4、M5、M6报文,接收方收到1和2后都及时给出了确认,由于字节都是连续都,假设接收方没有收到3,但收到了4,此时接收方会在收到4、5、6报文后都发送对2的确认,当发送方连续收到3个重复确认时,就知道接收方没有收到报文段3,此时会立即重传报文3。
  4. 快恢复:当发生快重传时,发送方知道现在只是丢失了个别字段,所以不启动慢开始,而是执行快恢复算法,将拥塞窗口调整为慢开始门限的一半,执行拥塞避免算法。

下面通过一道题来理解:

问题:设tcp的拥塞窗口的慢开始门限值初始为8,当拥塞窗口上升到12时网络发生超时,那么第13次传输时的拥塞窗口大小为多少?

解答:

  1. 慢开始:0->1->2->4->8(传输4次)
  2. 到达慢开始门限8,进入拥塞避免: 8->9->10->11->12(传输4次)
  3. 增长到12发生超时,慢开始门限调整到6,慢启动:0->1->2->4->6(传输4次)
  4. 6已经达到慢开始门限,进入拥塞避免:6->7(第十三次传输)
  5. 所以最终答案为7

TCP连接的三次握手

                                                              

  1. 最开始的 Client 和 Server 都是处于 Closed,由于服务器端不知道要跟谁建立连接,所以其只能被动打开,然后监听端口,此时 Server 处于 Listen 状态;

  2. 而 Client 会主动打开,然后构建好 TCB 「SYN= 1,seq = x」,发送给服务器端,此时 Client 会将状态置为 SYN_SEND 「同步已发送」;

  3. 服务器端收到客户端发来的同步请求后,会将状态置为 SYN_RECV「同步已接收」,同时会构建好 TCB「SYN = 1,seq = y,ACK = 1,ack = x + 1」发送给客户端;

  4. 客户端接收到了服务器端发来的传输控制块之后,会将自己的状态改为 ESTABLISHED「建立连接」,然后发送确认报文(ACK= 1,seq = x + 1,ack = y + 1);

  5. 服务器端在收到了客户端发来的报文之后,也将状态置为 ESTABLISHED「建立连接」,至此,三次握手结束,当然在这里,可以带 tcp 报文段信息过来了,因为此时客户端已经可以保证是可靠的传输了,所以在这一端可以发送报文段了。

题目1:为什么A最后还要再发送一次确认?

解答:为了防止因为网络原因迟来的A连接请求到达B,B单方面建立连接浪费B的资源。假如A发送了连接请求,但未收到确认,于是A又重传了一次连接请求,第二个连接请求正常连接并传输数据。此时A的第一个连接没有丢失,只是延迟了,又到达了B,B误以为是A又发送的一次连接,假如此时B向A发出确认后,A会丢弃B的确认,假如没有A最后一次的确认,B就会在发送确认后建立连接,白白浪费B的资源。

题目2:为何不直接在第一次握手就带上报文段消息,非要第三次才可以带?

解答:因为 TCP 是要保证数据的不丢失且可靠,如果在第一次就带上报文段消息,此次建立连接很有可能就会失败,那么就不能保证数据的不丢失了,在不可靠的机制上进行这种操作,换来的代价太大,每次发送报文段的资源也会增大,得不偿失;而第三次握手的时候,客户端已经知道服务器端准备好了,所以只要告诉服务器端自己准备好了就okay了,所以此时带上报文段信息没有任何问题。

TCP断开的四次挥手

                                                    

  1. 最开始客户端和服务器端都是 ESTABLISHED 的状态,然后客户端会主动关闭,而服务器端则是被动关闭。

  2. 客户端发送一个 FIN 报文段,seq = 结束的报文段序号 + 1「假设为 u」,告诉服务器端,客户端需要关闭了,此时将客户端的状态变为 FIN-WAIT-1,等待服务器端的反馈;

  3. 服务器在接收到了客户端发来的 FIN 包之后,会发一条 ack报文反馈给客户端,其中报文中包括 ACK = 1,seq = v,ack = u+1,告诉客户端收到了客户端要关闭的消息了,同时服务器端会通知应用进程需要关闭连接了,并将自己的状态置为 CLOSE-WAIT;

  4. 由于服务器端可能还有一些数据没处理完,所以需要一段时间的等待,当处理完了之后,会再发一条报文,其中 FIN = 1,ACK = 1,seq = w,ack = u+1,告知客户端,服务器端现在可以关闭了,并将服务器端的状态由 CLOSE-WAIT 变为 LAST-ACK;

  5. 客户端在收到了服务器端发来的消息之后,会发一条ack报文「ACK = 1,seq = u+1,ack = w+1」回去,告知服务器端,客户端已经知道了你准备好关闭了,此时会将客户端的状态由 FIN-WAIT-2 置为 TIME-WAIT,在两个最长报文段传输时间过后,会自动将客户端的状态由 TIME-WAIT 置为 CLOSED。

  6. 服务器端收到消息之后,就将状态由 LAST-ACK 置为了 CLOSED,自此,四次挥手全部结束。

题目1:在B向A发送FIN断开连接的报文后,A发送确认后做了什么?是马上断开吗?为什么要等待2个时间周期?

解答:图里很明了,并不是马上断开,而是等待了2个时间周期。原因有2个:

  • 为了保证A发送的最后一个ACK报文能到达B,在这两个时间周期内如果B收不到A的确认,会超时重传这个FIN+ACK的报文,A就会收到重传的断开确认报文,此时A会重传确认,重新启动2MSL计时器。假如A不等待2MSL,就不会收到B的重传报文,也就不会再发送一次确认报文,B就无法按照正常步骤进入CLOSE状态。
  • A在发送完最后一个ACK报文后,经过2MSL,就可以使本次连接内产生的所有报文都从网络中消失,在下一个新连接中就不会出现旧的连接报文段。

题目2:主动关闭方和被动关闭方,谁先进入CLOSE状态?

解答:看图也可以发现,是主动关闭方先进入CLOSE状态,原因上一题的答案就可以解释明白。

题目3:为何不能三次挥手呢?

解答:首先如果去掉最后一次挥手,那么服务器端就不知道自己要关闭的报文有没有传输成功,可能半路上就失败了,但是此时客户端不知道,导致客户端一直在等待服务器关闭,但是此时服务器端直接就关闭了。

展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 黑客帝国 设计师: 上身试试
应支付0元
点击重新获取
扫码支付

支付成功即可阅读