深入理解TCP协议

微尘丶

已于 2022-04-12 19:42:09 修改

阅读量2.7k

点赞数 1

分类专栏：计算机网络基础大学计算机文章标签：网络协议 http 网络 tcp/ip

于 2022-04-06 20:45:06 首次发布

本文链接：https://blog.csdn.net/qq_45809590/article/details/123983355

版权

大学计算机同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

计算机网络基础

2 篇文章 0 订阅

订阅专栏

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

可靠传输
- 停止等待ARQ协议
  - ARQ(Automatic Reqeat - reQuest),自动重传请求

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

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

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

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

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

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

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

流量控制
- 流量控制原理
  - 如果接收方的缓存区满了，发送方还在疯狂着发送数据
    - 接收方只能把收到的数据报丢掉，大量的丢包会极大着浪费网络资源
    - 所以要进行流量控制
  - 什么是流量控制
    - 让发送方的发送速率不要太快，让接收方来得及接收处理
  - 原理
    - 通过确认报文中窗口字段来控制发送方的发送速率
    - 发送方的发送窗口大小不能超过接收方给出窗口大小
    - 当放送方收到接受窗口的大小为0时，发送方就会停止发送数据
- 特殊情况
  - 有一种特殊情况
    - 一开始，接收方给发送方发送了0窗口的报文段
    - 后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了
    - 发送方的发送窗口一直为零，双方陷入僵局
  - 解决方案
    - 当发送方收到0窗口通知时，这时发送方停止发送报文
    - 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
    - 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器
拥塞控制
- 拥塞控制
  - 防止过多的数据注入到网络中
  - 避免网络中的路由器或链路过载
  - 拥塞控制是一个全局性的过程
    - 涉及到所有的主机、路由器
    - 以及与降低网络传输性能有关的所有因素
    - 是大家共同努力的结果
  - 相比而言，流量控制是点对点通信的控制
- 拥塞控制 - 方法
- 慢开始（slow start，慢启动）
- cwnd的初始值比较小，然后随着数据报被接收放确认(收到一个ACK)
  - cwnd就成倍增长(指数级）
拥塞避免（congestion avoidance）
- ssthresh
  - 慢开始阀值，cwnd达到阀值，以线性方式增加
- 拥塞避免(加法增大)
  - 拥塞窗口缓慢增大，以防止网络过早出现拥塞
- 乘法减小
  - 只要网络出现拥塞，把ssthresh减为拥塞峰值的一半，同时执行慢开始算法(cwnd又恢复到初始值）
  - 当网络出现频繁拥塞时，ssthresh值就下降的很快
快重传（fast retransmit）
- 接收方
  - 每收到一个失序的分组后就立即发出重复确认
  - 使发送方及时知道有分组没有到达
  - 不要等待自己发送数据时才进行确认
- 发送方
  - 只要连续收到三个重复确认(总共4个相同的确认)，就应该立即重传对方尚未收到的报文段
  - 不必继续等待重传计时器到期后再重传
快恢复（fast recovery）
几个单词缩写
- MSS（Maximum Segment Size）:每段最大的数据部分大小(在建立连接时确定)
- cwnd（congestion window）：拥塞窗口（在发送方）
- rwnd（receive window）：接收窗口
- swnd（send window）：发送窗口（swnd = min（cwnd，rwnd））
快重传 + 快恢复
- 当发送方连续收到三个重复确认，说明网络出现拥塞
  - 就执行“乘法减小”算法，把ssthresh减为拥塞峰值的一半
- 与慢开始不同之处是现在不执行慢开始算法，即cwnd现在不恢复到初始值
  - 而是把cwnd值设置为新的ssthresh值（减小后的值）
  - 然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大

发送窗口的最大值
- 发送窗口的最大值：swnd = min（cwnd，rwnd）
- 当rwnd < cwnd时，是接收方的接收能力限制发送窗口的最大值
- 当cwnd < rwnd时，是网络的拥塞限制发送窗口的最大值
序号、确认号

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个字节的数据给服务器。

连接管理
- 建立连接
  - 三次握手
  - 状态解读
    - 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次挥手
  - 状态解读
    - 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已经没有数据要发了

微尘丶

关注

1
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
深入理解TCP协议

目录可靠传输停止等待ARQ协议连续ARQ协议 + 滑动窗口协议SACK(选择性确定)流量控制流量控制原理特殊情况拥塞控制拥塞控制方法慢开始拥塞避免快重传快恢复快重传 + 快恢复发送窗口的最大值连接管理序号、确认号建立连接三次握手状态解读前2次握手的特点疑问释放连接4次挥手状态解读细节疑问抓包TCP协议（Transmission Control Protocol 传输控制协议）是一种面向
复制链接

扫一扫