计算机网络/学习笔记三/《计算机网络（自顶向下方法 第七版）》

已于 2022-11-08 17:32:29 修改
阅读量239 收藏 1
点赞数
分类专栏： 个人学习记录_计算机网络 文章标签： 网络 udp tcp/ip 网络协议 学习
于 2022-09-17 11:55:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39328598/article/details/126794475
版权
课程资源
  1. 课程网站：http://staff.ustc.edu.cn/~qzheng/teaching.html
  2. 课程视频：https://www.bilibili.com/video/BV1JV411t7ow/
  3. 课程教材：计算机网络（自顶向下方法 第7版），机械工业出版社，2016

第三章

传输层

1、概述与传输层服务

传输层与网络层的关系
  • 网络层服务：主机之间的逻辑通信
  • 传输层服务：进程间的逻辑通信
    • 依赖于网络层的服务
      • 延时、带宽
    • 并对网络层的服务进行增强
      • 数据丢失、顺序混乱、加密
      • 有些服务是可以加强的：不可靠 -> 可靠、安全；但有些服务是不可以被加强的：带宽，延迟
Internet传输层协议
  • 可靠的、保序的传输： TCP
    • 多路复用、解复用
    • 拥塞控制
    • 流量控制
    • 建立连接
  • 不可靠、不保序的传输：UDP
    • 多路复用、解复用
    • 没有为尽力而为的IP服务添加更多的其它额外服务
  • 都不提供的服务：
    • 延时保证
    • 带宽保证

2、多路复用与多路分解

  • 多路复用：源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息（之后用于分解）从而生成报文段，然后将报文段传递给网络层
  • 多路分解：接收端，运输层检查报文段字段，标识出接收套接字，进而将报文段定向到对应套接字，将运输层报文段中的数据交付到正确的套接字
    在这里插入图片描述
无连接（UDP）多路解复用
  • 在接收端，UDP套接字用二元组标识 (目标IP地址、目标端口号)
  • 当主机收到UDP报文段：
    • 检查报文段的目标端口号
    • 用该端口号将报文段定位给套接字
  • 如果两个不同源IP地址/源端口号的数据报，但是有相同的目标IP地址和端口号，则被定位到相同的套接字
    在这里插入图片描述
面向连接（TCP）多路解复用
  • TCP套接字:四元组本地标识：
    • 源IP地址
    • 源端口号
    • 目的IP地址
    • 目的端口号
  • 解复用：接收主机用这四个值来将数据报定位到合适的套接字
  • 服务器能够在一个TCP端口上同时支持多个TCP套接字：
    • 每个套接字由其四元组标识（有不同的源IP和源PORT）
  • Web服务器对每个连接客户端有不同的套接字
    • 非持久对每个请求有不同的套接字

在这里插入图片描述

3、无连接传输：UDP（User Datagram Protocol）

在这里插入图片描述

  • 优点：
    • 不建立连接 （会增加延时）
    • 简单：在发送端和接收端没有连接状态
    • 报文段的头部很小(开销小)
    • 无拥塞控制和流量控制：UDP可以尽可能快的发送报文段
UDP校验和
  • 目标： 检测在被传输报文段中的差错 (如比特反转)
  • 发送方：
    • 将报文段的内容视为16比特的整数
    • 校验和：报文段的加法和 （1的补运算）
    • 发送方将校验和放在UDP的校验和字段
  • 接收方：
    • 计算接收到的报文段的校验和
    • 检查计算出的校验和与校验和字段的内容是否相等：
      • 不相等––检测到差错
      • 相等––没有检测到差错，但也许还是有差错
        • 残存错误
          在这里插入图片描述

4、 可靠数据传输(Reliable Data Transfer)

在这里插入图片描述

构造RDT

  1. RDT1.0: 在可靠信道上的可靠数据传输

    • 下层的信道是完全可靠的
      • 没有比特出错
      • 没有分组丢失
    • 发送方和接收方的FSM(有限状态机)
      • 发送方将数据发送到下层信道
      • 接收方从下层信道接收数据
        在这里插入图片描述

  2. RDT2.0:具有比特差错的信道

  • 下层信道可能会出错：将分组中的比特翻转

    • 用校验和来检测比特差错
    • 怎样从差错中恢复：
      • 确认(ACK)：接收方显式地告诉发送方分组已被正确接收
      • 否定确认( NAK): 接收方显式地告诉发送方分组发生了差错
        • 发送方收到NAK后，发送方重传分组
          在这里插入图片描述

  • RDT2.1：解决ACK/NAK出错（一种停等协议：发送方发送一个分组，然后等待接收方的应答）

    • 发送方
      • 在每个分组中加入序号
        • 两个序列号（0，1）就足够了：一次只发送一个未经确认的分组
      • 必须检测ACK/NAK是否出错（需要EDC ）
        • 如果ACK/NAK出错，发送方重传当前分组
    • 接收方
      • 必须检测接收到的分组是否是重复的
        • 状态会指示希望接收到的分组的序号为0还是1
      • 丢弃（不发给上层）重复分组
        在这里插入图片描述在这里插入图片描述

  • RDT2.2:无NAK的协议

    • 功能同rdt2.1，但只使用ACK(ack 要编号）
    • 接收方对最后正确接收的分组发ACK，以替代NAK
      • 接收方必须显式地包含被正确接收分组的序号
        在这里插入图片描述
  1. RDT3.0:具有比特差错和分组丢失的信道
  • 下层信道可能会丢失分组（数据或ACK）
    • 发送方等待ACK一段合理的时间
      • 发送端超时重传：如果到时没有收到ACK->重传
    • RDT3.0可以工作，但链路容量比较大的情况下，性能很差
      • 若链路容量比较大，一次发一个PDU 的不能够充分利用链路的传输能力
流水线RDT：提高链路利用率
  • 允许发送方在未得到对方确认的情况下一次发送多个分组
    • 必须增加序号的范围:用多个bit表示分组的序号
    • 在发送方/接收方要有缓冲区
      • 发送方缓冲：未得到确认，可能需要重传；
      • 接收方缓存：上层用户取用数据的速率≠接收到的数据速率；接收到的数据可能乱序，排序交付（可靠）
    • 两种通用的流水线协议：回退N步(GBN)和选择重传(SR)

  1. 通用：滑动窗口协议

    • 发送缓冲区
      • 形式：内存中的一个区域，落入缓冲区的分组可以发送
      • 功能：用于存放已发送，但是没有得到确认的分组
      • 必要性：需要重发时可用
      • 大小：一次最多可以发送多少个未经确认的分组
        • 停止等待协议=1
        • 流水线协议>1，合理的值，不能很大，链路利用率不能够超100%
      • 分组
        • 未发送的：落入发送缓冲区的分组，可以连续发送出去；
        • 已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除
    • 发送窗口：发送缓冲区内容的一个范围
      • 内容：那些已发送但是未经确认分组的序号构成的空间
      • 大小：发送窗口的最大值<=发送缓冲区的值
      • 前沿：每发送一个分组，前沿前移一个单位
      • 后沿：前移条件：收到老分组的确认
        在这里插入图片描述
    • 接收窗口=接收缓冲区
      • 功能：接收窗口用于控制哪些分组可以接收
        • 只有收到的分组序号落入接收窗口内才允许接收
        • 若序号在接收窗口之外，则丢弃；
        • 接收窗口尺寸Wr=1，则只能顺序接收；
        • 接收窗口尺寸Wr>1 ，则可以乱序接收
          • 但提交给上层的分组，要按序
      • 滑动：
        • 低序号的分组到来，接收窗口移动；
        • 高序号分组乱序到，缓存但不交付（因为要实现rdt，不允许失序），不滑动
      • 发送确认：
        • 接收窗口尺寸=1 ； 发送连续收到的最大的分组确认（累计确认）
        • 接收窗口尺寸>1 ； 收到分组，发送那个分组的确认（非累计确认）
          在这里插入图片描述

  2. GBN（Go-back-N）回退N步

  • 发送端：
    • 最多在流水线中有N个未确认的分组
    • 对最老的未确认分组的定时器
      • 只需设置一个定时器
      • 当定时器到时时，重传所有未确认分组
  • 接收端
    • 接收窗口：
      • 大小为一，只能顺序接收
      • 只要一个变量expectedseqnum表示期望的按序接收的分组序号即可
    • 接收端只是发送累计型确认cumulative ack
      在这里插入图片描述
  1. SR（Selective Repeat）选择重传
  • 发送端：
    • 最多在流水线中有N个未确认的分组
    • 发送方为每个未确认的分组保持一个定时器
      • 当超时定时器到时，只是重发到时的未确认分组
  • 接收端
    • 接收窗口：大小大于一，可以乱序接收
    • 接收方对每个到来的分组单独确认individual ack（非累计确认）
      在这里插入图片描述
  1. 对比
    在这里插入图片描述

5、 面向连接的传输： TCP

TCP连接（逻辑连接）
  • 点对点:一个发送方，一个接收方
  • 可靠的、按顺序的字节流
  • 管道化（流水线）:TCP拥塞控制和流量控制设置窗口大小
  • 发送和接收缓存
  • 全双工数据:在同一连接中数据流双向流动
    • MSS：最大报文段大小
  • 面向连接:在数据交换之前，通过握手（交换控制报文） 初始化发送方、接收方的状态变量
  • 有流量控制:发送方不会淹没接收方
    在这里插入图片描述
报文段结构

在这里插入图片描述

  • 序号Seq（sequence number）：
    • 报文段首字节的在字节流的编号，标记客户端和服务器端之间发送的不同数据包
  • 确认号Ack（acknowledge number）:
    • 期望从另一方收到的下一个字节的序号
    • 累积确认
  • 标志位：共有六个标志位，分别为每个标志位占1Bit
    • URG：紧急指针（urgent pointer）有效。
    • Ack：确认号（32位的acknowledge number）是否有效。
    • PSH：是否应将该数据包尽快将给应用层。
    • RST：重置连接。
    • SYN：建立一个新连接。
    • FIN：断开一个连接。
往返时间估计与超时
  • 怎样估计RTT
    • SampleRTT：测量从报文段发出到收到确认的时间
      • 如果有重传，忽略此次测量
    • SampleRTT会变化，因此估计的RTT应该比较平滑
      • 对几个最近的测量值求平均，而不是仅用当前的SampleRTT
  • 怎样设置TCP超时？
    • 比RTT要长
      • 但RTT是变化的
    • 太短：太早超时
      • 不必要的重传
    • 太长：对报文段丢失反应太慢，消极
  • SampleRTT的指数加权移动平均
    • EstimatedRTT = (1- α)EstimatedRTT + αSampleRTT
    • α推荐为0.125
  • 超时时间间隔设置为：TimeoutInterval = EstimatedRTT + 4*DevRTT
    • RTT偏差DevRTT= (1- β)DevRTT +β|SampleRTT-EstimatedRTT|
可靠数据传输

  • TCP在IP不可靠服务的基础上建立了RDT

    • 管道化的报文段
    • GBN or SR
    • 累积确认（像GBN）
    • 单个重传定时器（像GBN）
    • 是否可以接受乱序的：没有规范

  • 通过以下事件触发重传

    • 超时（只重发那个最早的未确认段：SR）
    • 重复的确认
      • 例子：收到了ACK50,之后又收到3 个ACK50

  • 简化的TCP发送方

    • 忽略重复的确认
    • 忽略流量控制和拥塞控制

在这里插入图片描述

在这里插入图片描述

  • 快速重传
    • 通过重复的ACK来检测报文段丢失
      • 发送方通常连续发送大量报文段
      • 如果报文段丢失，通常会引起多个重复的ACK
        在这里插入图片描述
    • 如果发送方收到同一数据的3个冗余ACK，重传最小序号的段
      • 快速重传：在定时器过时之前重发报文段
      • 它假设跟在被确认的数据后面的数据丢失了
流量控制
  • 接收方控制发送方，不让发送方发送的太多、太快以至于让接收方的缓冲区溢出
  • 接收方在其向发送方的TCP段头部的rwnd字段“通告”其空闲buffer大小
    • RcvBuffer大小通过socket选项设置 (典型默认大小为4096 字节)
    • 很多操作系统自动调整RcvBuffer
  • 发送方限制未确认(“inflight”)字节的个数≤接收方发送过来的rwnd值
  • 保证接收方不会被淹没
    在这里插入图片描述
连接管理

  • 建立连接

    • 首先由客户端发起连接请求，组件一个TCP数据包。该数据设置SYN标志位表示该数据包用来建立TCP连接。同时随机生成一个Seq序列号，填充到TCP数据包中的Seq字段
    • 服务器端接收到数据包后，检查SYN标志位，判断该数据包为客户端请求用来建立TCP连接的数据包，服务器端同样随机生成一个序列号，然后将客户端数据包序号加1，并用这个数字填充“确认号（Ack）”字段
    • 客户端收到数据包后，检测到SYN和ACK标志位，知道这是服务器端发送的“确认包”表示服务器端接收到了客户端发送的数据包，于是客户端再新建一个数据包用服务端数据包序号加1填充数据包的ACK字段发送给服务器端.
      在这里插入图片描述
      在这里插入图片描述

  • 关闭连接

    • 客户端，服务器分别关闭它自己这一侧的连接
      • 发送FIN bit = 1的TCP段
    • 一旦接收到FIN，用ACK回应
      • 接到FIN段，ACK可以和它自己发出的FIN段一起发送
    • 可以处理同时的FIN交换
      在这里插入图片描述

6、拥塞控制原理

拥塞的原因与代价

  • 拥塞：

    • 非正式的定义: “太多的数据需要网络传输，超过了网 络的处理能力”
    • 与流量控制不同
    • 拥塞的表现:
      • 分组丢失 (路由器缓冲区溢出)
      • 分组经历比较长的延迟(在路由器的队列中排队)

  • 当分组到达速率接近链路容量时，分组经历巨大的排队时延
    在这里插入图片描述

  • 发送方必须执行重传以补偿云玩缓存溢出而丢弃的分组

    • 为了达到一个有效输出，网络需要做更多的工作（重传）
    • 没有必要的重传，链路中包括了多个分组的拷贝 （超时重传）
      在这里插入图片描述

  • 当分组丢失时，任何“关于这个分组的上游传输能力”都被浪费了
    在这里插入图片描述

拥塞控制方法
  1. 端到端拥塞控制：
    • 没有来自网络的显式反馈
    • 端系统根据延迟和丢失事件推断是否有拥塞
    • TCP采用的方法
  2. 网络辅助的拥塞控制：
    • 路由器提供给端系统以反馈信息
      • 单个bit置位，显示有拥塞 (SNA, DECbit, TCP/IP ECN, ATM)
      • 显式提供发送端可以采用的速率

7、TCP拥塞控制

  • TCP使用端到端的拥塞控制机制
    • 路由器不向主机有关拥塞的反馈信息
      • 路由器的负担较轻
      • 符合网络核心简单的TCP/IP架构原则
    • 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作
拥塞感知

  • 某个段超时了（丢失事件 ）：拥塞

    • 超时时间到，某个段的确认没有来
    • 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
    • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
    • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
      在这里插入图片描述

  • 有关某个段的3次重复ACK：轻微拥塞

    • 段的第1个ack，正常，确认绿段，期待红段
    • 段的第2个重复ack，意味着红段的后一段收到了，蓝段乱序到达
    • 段的第2、3、4个ack重复，意味着红段的后第2、3、4个段收到了，橙段乱序到达，同时红段丢失的可能性很大（后面3个段都到了，红段都没到）
    • 网络这时还能够进行一定程度的传输，拥塞但情况要比第一种好
拥塞控制
  1. 速率控制方法
    • 维持一个拥塞窗口的值：CongWin
      • 发送端限制已发送但是未确认的数据量（的上限）:LastByteSent-LastByteAcked <=CongWin
      • 从而粗略地控制发送方的往网络中注入的速率
        在这里插入图片描述
    • CongWin是动态的，是感知到的网络拥塞程度的函数
      • 超时或者3个重复ack，CongWin↓
        • 超时时：CongWin降为1MSS（Maximum Segment Size最大报文段长度/一个分组的大小）, 进入SS阶段（Slow Start，慢启动阶段）然后再倍增到CongWin/2 （每个RTT），从而进入 CA阶段(Congestion Avoidance 拥塞避免阶段)
        • 3个重复 ack ：CongWin 降为CongWin/2,CA阶段
      • 否则（正常收到Ack，没有发送以上情况）：CongWin跃跃欲试↑
        • SS阶段：加倍增加 (每个RTT)
        • CA阶段：线性增加 (每个 RTT)
  • 拥塞控制和流量控制的联合控制：
    • 发送端控制发送但是未确认的量同时也不能够超过接收窗口，满足流量控制要求：
    • SendWin=min{CongWin, RecvWin}
  1. 拥塞控制策略

    • 慢启动

      • 连接刚建立, CongWin = 1 MSS
      • 可用带宽可能>> MSS/RTT
        • 应该尽快加速，到达希望的速率
      • 当连接开始时，指数性 增加发送速率，直到发生丢失的事件
        • 启动初值很低，但是速度很快
          在这里插入图片描述

    • AIMD（Additive Increase Multiplicative Decrease）：线性增、乘性减

      • 乘性减：
        • 丢失事件后将CongWin降为1，将CongWin/2作为阈值，进入慢启动阶段（倍增直到CongWin/2）
      • 线性增：
        • 当CongWin>阈值时，一个RTT若没有发生丢失事件，将CongWin加1MSS：探测

    • 超时事件后的保守策略

      • 当收到3个重复的ACKs:
        • CongWin 减半
        • 窗口（缓冲区大小）之后线性增长
      • 当超时事件发生时:
        • CongWin 重置为1 MSS，进入SS阶段
        • 之后窗口指数增长
        • 增长到一个阈值Threshold（上次发生拥塞的窗口的一半）时，再线性增加

    • 总结
      在这里插入图片描述

直到恒星内核反应殆尽
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
TCP三次握手、四次挥手详解
chenxuyuana的博客
08-25 1242
TCP 三次握手丢包情况 第一次握手丢失了，会发生什么？当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到 SYN_SENT 状态。在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的。不同版本的操作系统可能超时时间不同，有的 1 秒的，也有 3 秒的，这个超时时间是写死在内核里的，如果想要更改则需要重新编译内核，比较麻烦。当客户端在 1 秒后没收到服务端的
《计算机网络-自顶向下》第8版学习笔记
11-17
《计算机网络--自顶向下》第8版学习笔记
TCP三次握手中第三次握手时ACK丢失怎么办
MrLiar的博客
07-19 4833
Server 端 第三次的ACK在网络中丢失，那么Server 端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。 而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5. 如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接，...
tcp三次握手时，最后一个ACK丢失过程分析
火云邪神的博客
09-26 3578
客户端发送的最后一个ACK因为某些原因丢失时： 由于server端发送syn_ack报文后进入SYN_RCVD状态，就会启动tcp重传计时器，超时时就会重新发送syn_ack报文，总共发送 net.ipv4.tcp_synack_retries次；客户端在没有收到重传的syn_ack之前，发送数据给server端，由于server端的状态为SYN_RCVD状态，而不是ESTABLISHE...
流量整形，延迟以及ACK丢失对TCP发送时序的影响
热门推荐
Netfilter
06-18 2万+
TCP是一个连续不断的涓涓细流或者滚滚长江，但这只是理想情况！经过诸多中间网络设备，最终一个TCP流到达接收端的时候，将可能不再保持一个流的形式，而变成了一阵阵的突发...这些突发产生的ACK反过来反馈到发送端，进而对发送端的发送时序产生影响，也就是说对发送端的数据流进行整形，这真是一个典型的涡轮增压反馈系统，根本不是通常认为的那样不可控或者说另一个极端，仅仅是端到端！想驾驭它其实不是那么难，如果
TCP在第三次握手时的ACK丢了会出现什么问题
刘小雨的博客
03-31 870
当Client 端 三次握手是收到Server 的SYN + ACK 应答后， 其状态变为established，并发送ACK包给Server 此时ACK在网络中丢失，会怎么样？ Server端该TCP连接的状态为SYN_RECV, 并且依次等待3s,6s,12s后重新发送SYN+ACK 包，以便Client 重新发送ACK包，Server重发SYN+ACK的次数，可以通过修改配置文件修改（/proc/sys/net/ipv4/tcp_synack_retries），默认是5； 如果指定的次数后，仍然未收
计算机网络自顶向下复习笔记
06-19
这篇“计算机网络自顶向下复习笔记”主要针对本科生期末复习，特别关注TCP/IP模型。笔记可能在应用层到传输层的内容上有所欠缺，因此建议结合具体考试大纲进行补充学习。 首先，我们来看看计算机网络的基本构成。...
计算机网络自顶向下方法笔记第一章
12-11
计算机网络自顶向下方法（陈鸣译），第一章笔记 第一章：计算机网络和因特网 分组交换： 分组：源将长报文划分为较小的数据块 交换机：主要有两类：路由器和链路层交换机 存储转发传输机制：指在交换机能够开始向...
《计算机网络-自顶向下的方法》第8版详细笔记
最新发布
12-24
计算机网络详细笔记，综合《计算机网络-自顶向下的方法》第8版整理而成的思维导图
Nginx 超时事件的处理机制
资料qun832218493
06-25 328
相关视频推荐 手把手带你实现一个nginx模块丨Nginx Filter|Nginx Handler|惊群效应|error 学会nginx中锁的使用，让你对锁豁然开朗 LinuxC++后台服务器开发架构师免费学习地址 本文基于Nginx 0.8.55源代码，并基于epoll机制分析 对于nginx而言，事件机制的处理无非就是几个部分： 网络IO事件的处理 文件IO事件的处理 定时器事件的处理 （当然还有许多其他的不过我现在并不是很关心。。） 我在读Nginx定时器事件相关的代码时看到了很
运输层详解
有人_295的博客
10-12 643
一、概述 运输层: 主机到主机数据传输，负责从应用层接收消息，并传输应用层的message，到达目的后将消息上交应用。 在运行不同主机上应用进程之间提供逻辑通信 运输协议运行在端系统中 发送方：将应用报文（ messages ）划分为报文段（segments），传向网络层 接收方：将段重新装配为报文，传向应用层 应用程序可供使用的运输协议不止一个 因特网：TCP和UDP 二、多路复用和多路分解 ...
网络协议报文理解刨析篇二(再谈Http和Https), 加上TCP/UDP/IP协议分析(理解着学习), 面试官都惊讶你对网络的见解
小杰312的博客
03-12 8365
网络协议报文理解刨析篇二(再谈Http和Https), 加上TCP/UDP/IP协议分析(理解着学习), 面试官都惊讶你对网络的见解
关于TCP报文段丢失，确认号的选择
attack_5的博客
06-06 1万+
主机A向主机B连续发送了两个TCP报文段，其序号分别为70和100。解析：即题目的意思就是0-69已经全部接收完成，现在就是A发送第一个是70-99和第二个是100-n的报文段（1）第一个报文段携带了多少字节的数据？  解析：70到99一共30个字节。       答：100-70=30 字节（2）主机B收到第一个报文段后发回的确认中的确认号应当是多少？ 解析：确认号应为期望收到的报文段的第一个序...
TCP三次握手第三次握手时ACK丢失怎么办
Vi的博客
04-19 7626
当Client端收到Server的SYN+ACK应答后，其状态变为ESTABLISHED，并发送ACK包给Server； 如果此时ACK在网络中丢失，那么Server端该TCP连接的状态为SYN_RECV，并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。 Server重发SYN+ACK包的次数，可以通过设置/proc/sys/ne
TCP三次握手的第三次的 ack包丢失会怎样？
gochenguowei的博客
03-22 1万+
面试题：    在 TCP 建立连接的三次握手连接阶段，如果客户端发送的第三个ACK包丢了，那么客户端和服务端分别进行什么处理呢？    相信了解 tcp 协议的人，三次握手的过程肯定很了解了。第三次的 ack 包丢失就是说在 client 端接收到 syn + ack 之后，向 server 发送的 ack 包 由于各种原因 server 没有收到。这时 client, server 分别会进行...
TCP三次握手时ACK丢失怎么办
weixin_46248981的博客
08-31 949
服务端 服务端有个重发时间，如果在发送SYN+ACK指令之后，如果重发时间到了，会继续重发SYN+ACK，并且如果达到指定重发次数之后，仍然还没收到客户端的ACK请求，那么服务端就会自动关闭这个连接。 客户端 客户端收到SYN+ACK请求后，就已经处于Established状态，如果这时候给客户端发送数据，就会收到RST指令，就知道了ACK指令丢失，然后重传ACK包。 ...
TCP三次握手ACK包丢了 客户端也不会重传
qq_37752223的博客
03-27 1780
第三次握手，ACK包丢了的话，如果客户端接着发送数据包，服务器端可以从接收到的数据包中得到与ACK包同样的信息，所以服务端并不非要收到ACK包；如果客户端不发数据包，服务端会认为自己的SYN+ACK包丢失了，会重新发SYN+ACK包，所以ACK包不会被重发 看这张图第三、第四步，第一个发送的数据包持有的信息包含了ACK包的信息，所以ACK包丢了也不要紧的。 https://www.zhihu.c...
三次握手时第三个ACK包丢了怎么办
feifei__wang的博客
07-16 1295
面试题：    在 TCP 建立连接的三次握手连接阶段，如果客户端发送的第三个ACK包丢了，那么客户端和服务端分别进行什么处理呢？    相信了解 tcp 协议的人，三次握手的过程肯定很了解了。第三次的 ack 包丢失就是说在 client 端接收到 syn...
Computer Networking A Top Down Approach Global Edition 8th.pdf
11-22
计算机网络：自顶向下方法第8版，Global版

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值