深入理解TCP协议

目录

可靠传输

停止等待ARQ协议

连续ARQ协议 + 滑动窗口协议

SACK(选择性确定)

流量控制

流量控制原理

特殊情况

拥塞控制

拥塞控制

方法

慢开始

拥塞避免

快重传

快恢复

快重传 + 快恢复

发送窗口的最大值

连接管理

序号、确认号

建立连接

三次握手

状态解读

前2次握手的特点

疑问

释放连接

4次挥手

状态解读

细节

疑问

抓包


TCP协议(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,用户数据报协议(UDP)是同一层内 另一个重要的传输协议。 

  • 可靠传输

    • 停止等待ARQ协议

      • ARQ(Automatic Reqeat - reQuest),自动重传请求

深入理解TCP协议_第1张图片

深入理解TCP协议_第2张图片

  • 若有包重传了N次还是失败,会一直持续重传到成功为止吗?
    • 取决于系统的设置,有些系统,重传5次还未成功就会发送reset报文(RST)断开TCP

深入理解TCP协议_第3张图片

  • 连续ARQ协议 + 滑动窗口协议

深入理解TCP协议_第4张图片

深入理解TCP协议_第5张图片

  • 假设每一组数据是100字节,代表一个数据段的数据。每一组给一个编号 

深入理解TCP协议_第6张图片

  • SACK(选择性确定)

  • 在TCP通信过程中,如果发送序列中间某个数据报丢失(比如1、2、3、4、5中的3丢失了)
    • TCP会通过重传最后确认的分组后续的分组(最后确认的是2,会重传3、4、5)
    • 这样原先已经正确传输的分组也可能重复发送(比如4、5),降低了TCP性能
  • 为改善上述情况,发展了SACK(Selective Acknowledgment,选择性确认)技术
    • 告诉发送方哪些数据丢失,哪些数据已经提前收到
    • 使TCP只重新发送丢失的包(比如3),不用发送后续所有的分组(比如4、5)

深入理解TCP协议_第7张图片

  •  SACK信息会放在TCP首部的选项部分
    • kind:占1字节,值为5代表这是SACK选项
    • Length:占1字节,表明SACK选项一共占用多少字节
    • Left Edge:占4字节,左边界
    • Right Edge:占4字节,右边界
    • TCP首部选项部分最多40字节,SACK选项中最多携带4组边界信息(4 * 8 + 2 = 34)

深入理解TCP协议_第8张图片

为什么选择在传输层就将数据“大卸八块”分成多个段,而不是等到网络层再分片传递给数据链路层?

  • 可以提高重传的性能
  • 可靠传输是在传输层进行控制的
    • 如果在传输层不分段,一旦出现数据丢失,整个传输层的数据都得重传
    • 如果在传输层分段,一旦出现数据丢失,只需要重传丢失的那些段即可
  • 流量控制

    • 流量控制原理

      • 如果接收方的缓存区满了,发送方还在疯狂着发送数据
        • 接收方只能把收到的数据报丢掉,大量的丢包会极大着浪费网络资源
        • 所以要进行流量控制
      • 什么是流量控制
        • 让发送方的发送速率不要太快,让接收方来得及接收处理
      • 原理
        • 通过确认报文中窗口字段来控制发送方的发送速率
        • 发送方的发送窗口大小不能超过接收方给出窗口大小
        • 当放送方收到接受窗口的大小为0时,发送方就会停止发送数据
    • 特殊情况

      • 有一种特殊情况
        • 一开始,接收方给发送方发送了0窗口的报文段
        • 后面,接收方又有了一些存储空间,给发送方发送的非0窗口的报文段丢失了
        • 发送方的发送窗口一直为零,双方陷入僵局
      • 解决方案
        • 当发送方收到0窗口通知时,这时发送方停止发送报文
        • 并且同时开启一个定时器,隔一段时间就发个测试报文去询问接收方最新的窗口大小
        • 如果接收的窗口大小还是为0,则发送方再次刷新启动定时器
  • 拥塞控制

    • 拥塞控制

      • 防止过多的数据注入到网络中
      • 避免网络中的路由器或链路过载
      • 拥塞控制是一个全局性的过程
        • 涉及到所有的主机、路由器
        • 以及与降低网络传输性能有关的所有因素
        • 是大家共同努力的结果
      • 相比而言,流量控制是点对点通信的控制
        深入理解TCP协议_第9张图片
    • 拥塞控制 - 方法

    • 慢开始(slow start,慢启动)

      深入理解TCP协议_第10张图片


      深入理解TCP协议_第11张图片

    • cwnd的初始值比较小,然后随着数据报被接收放确认(收到一个ACK)
      • cwnd就成倍增长(指数级)
  • 拥塞避免(congestion avoidance)

    深入理解TCP协议_第12张图片

    • ssthresh
      • 慢开始阀值,cwnd达到阀值,以线性方式增加
    • 拥塞避免(加法增大)
      • 拥塞窗口缓慢增大,以防止网络过早出现拥塞
    • 乘法减小
      • 只要网络出现拥塞,把ssthresh减为拥塞峰值的一半,同时执行慢开始算法(cwnd又恢复到初始值)
      • 当网络出现频繁拥塞时,ssthresh值就下降的很快
  • 快重传(fast retransmit)
    深入理解TCP协议_第13张图片

    • 接收方
      • 每收到一个失序的分组后就立即发出重复确认
      • 使发送方及时知道有分组没有到达
      • 不要等待自己发送数据时才进行确认
    • 发送方
      • 只要连续收到三个重复确认(总共4个相同的确认),就应该立即重传对方尚未收到的报文段
      • 不必继续等待重传计时器到期后再重传
  • 快恢复(fast recovery)

  • 几个单词缩写
    • MSS(Maximum Segment Size):每段最大的数据部分大小(在建立连接时确定)
    • cwnd(congestion window):拥塞窗口(在发送方)
    • rwnd(receive window):接收窗口
    • swnd(send window):发送窗口(swnd = min(cwnd,rwnd))
  • 快重传 + 快恢复

    深入理解TCP协议_第14张图片

    • 当发送方连续收到三个重复确认,说明网络出现拥塞
      • 就执行“乘法减小”算法,把ssthresh减为拥塞峰值的一半
    • 与慢开始不同之处是现在不执行慢开始算法,即cwnd现在不恢复到初始值
      • 而是把cwnd值设置为新的ssthresh值(减小后的值)
      • 然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大
  • 发送窗口的最大值

    • 发送窗口的最大值:swnd = min(cwnd,rwnd)
    • 当rwnd < cwnd时,是接收方的接收能力限制发送窗口的最大值
    • 当cwnd < rwnd时,是网络的拥塞限制发送窗口的最大值
  • 序号、确认号
    深入理解TCP协议_第15张图片

    深入理解TCP协议_第16张图片

    深入理解TCP协议_第17张图片

    深入理解TCP协议_第18张图片

1.客户端第一次发送请求(SYN=1,ACK=0)给服务器建立连接,所以seq相对和ack相对都是0,,s1是随机生成的随机数

2.服务器第一次发送东西(SYN=1,ACK=1)给回客户端,seq相对也是0,ack相对是1,是告诉客户端收到了它的0个字节,希望客户端能够发第ack相对个字节(1)的数据给服务器。s2是服务器随机生成的值。只有前二次SYN是1,后面SYN都是0。

3.客户端收到服务器给回的信息后,从第一个字节开始发送东西,所以seq相对是1,ack相对是对上一个服务器的回应,表示收到服务器的0个字节,并且希望接下来从1开始发

4.客户端开始向服务器发送HTTP请求(k个字节),seq相对和ack相对都是对上一个服务器的回应,所以都还是1

5.服务器收到客户端的k个字节数据,所以服务器的ack相对是k+1,希望客户端接下来发送第k+1个数据包给服务器

6.第5点中服务器发送给客户端b1个字节了,接下来开始发送第b1+1的数据包给客户端,ack表示要客户端发送第k+1个数据包给服务器

7.第6点中服务器发送给客户端b2个字节了,接下来开始发送第b2+b1+1的数据包给客户端,ack表示要客户端发送第k+1个数据包给服务器

7.第7点中服务器发送给客户端b3个字节了,接下来开始发送第b3+b2+b1+1的数据包给客户端,ack表示要客户端发送第k+1个数据包给服务器

8.客户端接收到服务器的数据后,开始发送第k+1个数据,所以seq相对是k+1,ack相对是告诉服务器,客户端一共收到了b1+b2+b3+b4+1个数据

  • 客户端seq服务器ack是一对,服务器seq客户端ack是一对。
  • 客户端seq相对是0,服务器ack是1,表示客户端发送0个字节数据给服务器,服务器接收客户端的0个字节数据,并且希望客户端能够发第1个字节的数据给服务器。
  • 服务器seq相对是0,客户端ack是1,表示服务器发送0个字节数据给客户端,客户端接收服务器的0个字节数据,并且希望服务器能够发第1个字节的数据给服务器。
  • 连接管理

    • 建立连接

      • 三次握手 

        深入理解TCP协议_第19张图片

      • 状态解读

        • CLOSED(关闭)
          • ​​​​​​​client处于关闭状态
        • LISTEN(监听)
          • ​​​​​​​​​​​​​​server处于监听状态,等待client连接
        • SYN - RCVD(同步已发送)
          • ​​​​​​​表示server接受到SYN报文,当收到client的ACK报文后,它会进入到ESTABLISHED状态
        • SYN - SENT(同步已接收)
          • ​​​​​​​表示client已发SYN报文,等待server的第2次握手
        • ESTABLISHED(连接已经建立)
          • ​​​​​​​表示连接已经建立
      • 前2次握手的特点

        • SYN都设置为1,数据部分的长度都为0
        • TCP头部的长度一般都是32字节
          • 固定头部:20字节,选项部分:12字节
        • 双方会交换确认一些信息
          • 如MSS、是否支持SACK、Window scale(窗口缩放系数)等
          • 这些数据都放在TCP头部都选项部分中(12字节)
      • 疑问

        • 为什么建立连接的时候,要进行3次握手?2次不行吗?
          • 主要目的:防止服务器端移植等待,浪费资源
        • 如果建立连接只需要2次握手,可能会出现的情况
          • 假设client发出的第一个连接请求报文段,因为网络延迟,在连接释放以后的某个时间才到达server
          • 本来这是一个早已失效的连接请求,但服务器收到此失效的请求后,误以为是client再次发出的一个新的连接请求
          • 于是server就向client发出确认报文段,同意建立连接
          • 如果不采用“3次握手”,那么只要server发出确认,新的连接就建立了
          • 由于现在client并没有真正想连接服务器的意愿,因此不会理睬server的确认,夜不会向server发送数据
          • 但server却以为新的连接已经建立,并一直等待client发来数据,这样,server的很多资源就白白浪费了
        • 采用“3次握手”的办法可以防止上述现象发生
          • 上述情况,client没有向server的确认发出确认,server由于收不到确认,就知道client并没有要求建立连接
        • 第3次握手失败了,会怎么处理?
          • 此时server的状态为SYN - RCVD,若等不到client的ACK,server会重新发送SYN + ACK包
          • 如果server多次重发SYN + ACK都等不到client的ACK,就会发送RST包,强制关闭连接
    • 释放连接

      • 4次挥手

        深入理解TCP协议_第20张图片

      • 状态解读

        • FIN-WAIF-1(终止等待-1)
          • ​​​​​​​表示想主动关闭连接
          • 向对方发送了FIN报文,此时进入到FIN-WAIF-1状态
        • CLOSE-WAIT(关闭等待)
          • ​​​​​​​表示在等待关闭
          • 当对方发送FIN给自己,自己会回应一个ACK报文给对方,此时则进入到CLOSE-WAIT状态
          • 在此状态下,需要考虑自己是否还有数据要发送给对方,如果没有,发送FIN报文给对方
        • FIN-WAIT-2(终止等待-2)
          • ​​​​​​​只要对方发送ACK确认后,主动方就会处于FIN-WAIT-2状态,然后等待对方发送FIN报文
        • CLOSING
          • 一种比较罕见的例外状态
          • 表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文
          • 如果双方几乎在同时准备关闭连接的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态
          • 表示双方都正在关闭连接
        • LAST-ACK​​​​​​​(最后确认)
          • 被动关闭一方在发送FIN报文后,最后等待对方的ACK报文
          • 当收到ACK报文后,即可进入CLOSED状态了
        • TIME-WAIT(时间等待)
          • 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可进入CLOSED状态了
          • 如果FIN-WAIT-1状态下,收到了对方同时带FIN标志和ACK标志等报文时
          • 可以直接进入到TIME-WAIT状态,而无须经过FIN-WAIT-2状态
        • CLOSED(关闭)
          • 关闭状态
          • 由于有些状态到时间比较短暂,所有很难用netstat命令看到
          • 如:SYN-RCVD、FIN-WAIT-1等
      • 细节

      • TCP/IP协议栈在设计上,允许任何一方先发起断开请求。这里是client主动要求断开
        • ​​​​​​​client发送ACK后,需要有个TIME-WAIT阶段,等待一段时间后,再真正关闭连接
        • 一般是等待2倍的MSL(Maximum Segment Lifetime 最大分段生存期)
          • MSL是TCP报文在Internet上的最长生存时间
          • 每个具体的TCP实现都必须选择一确定的MSL值,RFC 1122建议是2分钟
          • 可以防止本次连接中产生的数据包误传给下一次连接中(因为本次连接中的数据包都会在2MSL时间内消失了)
        • ​​​​​​​如果client发送ACK后马上释放了,然后又因为网络原因,server没有收到client的ACK,server就会重发FIN
          • ​​​​​​​这时候可能出现的情况是
            • ​​​​​​​client没有任何响应,服务器那边会干等,甚至多次重发FIN,浪费资源
            • client有个新的应用程序刚好分配了同一个端口号,新的应用程序收到FIN后马上开始执行断开连接的操作,本来它可能是想跟server建立连接的​​​​​​​
      • 疑问

        • 为什么释放连接的时候,要进行4次挥手
          • TCP是全双工模式
          • 第一次挥手
            • 主机1发出FIN报文段时
              • 表示主机1告诉主机2主机1已经没有数据要发送了,但是此时主机1还是可以接受来自主机2的数据
          • 第二次挥手
            • 主机2返回ACK报文段时
              • 表示主机2已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1
          • 第三次挥手
            • 主机2也发送了FIN报文段时
              • 表示主机2告诉主机1主机2已经没有数据要发送了
          • 第四次挥手
            • 主机1返回ACK报文段时
              • 表示主机1知道主机2没有数据发送了,随后正式断开TCP连接
      • 抓包

        • 有时候在使用抓包工具的时候,有可能只会看到“3次”挥手
          ​​​​​​​

          • 这其实是将第2、3次挥手合并了​​​​​​​ 
        • 当server接受到client的FIN时,如果server后面也灭有数据要发送给client了
          • 这是嘛,server就可以将第2、3次挥手合并,同时告诉client两件事
            • 已经知道client没有数据要发
            • server已经没有数据要发了

你可能感兴趣的:(计算机网络基础,大学计算机,网络协议,http,网络,tcp/ip)