仙桃企业网站建设高档网站设计公司

当前位置： 首页 > news >正文

仙桃企业网站建设,高档网站设计公司,wordpress返回,wordpress直达链接404文章目录 延时应答捎带应答面向字节流粘包问题方案一#xff1a;指定分隔符方案二#xff1a;指定数据的长度 TCP 报头首部长度保留#xff08;6 位#xff09;选项序号确认序号 延时应答 尽可能降低可靠传输带来的性能影响 提升性能让滑动窗口变大 如果我们立即返回 … 文章目录 延时应答捎带应答面向字节流粘包问题方案一指定分隔符方案二指定数据的长度 TCP 报头首部长度保留6 位选项序号确认序号 延时应答 尽可能降低可靠传输带来的性能影响 提升性能让滑动窗口变大 如果我们立即返回 ACK此时窗口大小就是 4KB其实在收到数据的时候应用程序也在源源不断的消费接收缓冲区中的数据 所以我们返回的时间可以晚一些这样应用程序就有机会读取缓冲区中更多的数据假设让 ACK 不是立即返回而是 100ms 之后再进行返回这就意味着此时在 100ms 之内应用程序可能又消费掉 2KB 的数据了此时返回的 ACK 携带的窗口大小就是 6KB 延时返回的 ACK 窗口大小大概率要比立即返回 ACK 的窗口大小更大因为在这个时间里会有一个消费数据的过程 不是一定只是有“大概率”关键取决于程序是不是在不停地读取数据、延时时间内发送方是否会新发数据过来发多了窗口还变得更小了 捎带应答 在延时应答的基础上引入的提升效率的机制把返回的业务数据和 ACK 两者合二为一了 实际网络通信中大部分情况都是“一问一答”的形式
ACK 是内核返回的是收到请求之后立即就返回 ACK响应则是应用程序返回的代码中根据请求计算得到响应再把响应写回到客户端 正常情况下ACK 和响应是不同的时机无法合并。但是ACK 涉及到“延时应答”延时应答就会使 ACK 的返回时间被往后拖这样一延时就可能赶上接下来发送响应数据的操作了也是就可以在发送响应的时候把刚才 ACK 的信息也带上 本身 ACK 报文不需要载荷包头中设置 ACK 这一位为 1设置窗口大小的值设置确认序号响应数据主要是设置载荷和 ACK 不冲突可以共存 在四次挥手中也说到过这样的情况ACK 和 FIN 是不同的时机不能合并在一起但是在延时应答之下ACK 可能返回的时间更晚此时就可能可以和 FIN 合并使四次挥手变成三次挥手 比如说你在床上口渴了但是你不想起来就等到要上厕所的时候再起来顺带把水喝了 延时应答捎带应答都是 TCP 提升性能的机制。TCP 之所以复杂不仅仅在考虑可靠传输还要在可靠传输的基础上尽可能提高效率 面向字节流 读写 100 个字节的数据 可以一次读写一个字节分 100 次一次读写 10 个字节分 10 次一次读写 50 个字节分 2 次一次读写 100 个字节一次搞定… 粘包问题 通过面向字节流的方式传输数据都是会涉及到“粘包问题” 粘的是 TCP 携带的载荷应用层数据包 aaa、bbb、ccc 分别是三个不同的应用层数据包 接收方那边就有一个接收缓冲区三个数据就进去了 应用程序需要读取接收缓冲区中的数据由于 TCP 是面向字节流的所以怎么读都可以 可以读成aaabbbccc也可以aaabbbccc存在很多种读法 但只有一是正确的读法才是完整的“应用层数据包”
应用层在 TCP 的接收缓冲区中连成一片就称为“粘包问题” 要想解决粘包问题关键就是要明确“包之间的边界” 方案一指定分隔符 前面在写 TCP Echo Server 的时候我们约定请求和响应都以 \n 结尾。 发送请求响应的时候专门使用 println 进行写数据接受请求响应的时候专门使用 scanner.next 按照 \n 进行解析 需要确认数据内容的正文中不能包含分隔符。如果传输的数据是纯文本数据的话此时使用 \n 或者 ; 之类的可能都不合适但是可以使用 ASCII 码表中的一些不常见的字符 方案二指定数据的长度 比如约定在每个应用层数据包开头的几个字节表示数据包的长度 如果是传输二进制数据这个方案就很有用 如果希望在文件中存储结构化数据也是存在这样的问题的。所以存文件也经常会使用 XML/JSON 这样的格式来存储也就是解决粘包问题 UDP 这种面向数据报的传输方式不涉及到上述问题因为 send/receive 得到的就是一个完整的 DatagramPacket这里携带的二进制的字节数组就是一个完整的应用层数据包 TCP 报头 首部长度 TCP 报头的长度 UDP 协议报头固定就是 8 个字节对于 TCP 来说报头长度是可变的 4 个比特位可表示的范围0000~1111——0x0~0xF——0~15此处的长度单位是 4 字节不是字节所以范围是 0~60 字节 保留6 位 虽然现在不用但是先把这个东西申请下来以备不时之需。用于考虑未来的可扩展性 充分吸取了 UDP 的教训UDP 的报文长度字段是没法扩展的如果未来某一天TCP 需要新增属性或者谋和属性的长度不够用就可以把保留位拿出来进行使用TCP 的结构不需要发生太大的改变这样的升级就会容易很多 关于“可扩展性”也是属于编程的时候需要考虑到的一点毕竟写的代码不可能写一份就能持续地使用。对代码做出调整做出修改是非常普遍、常见的情况 但是 选项 TCP 报头边长的主要原因。四个字节为一个单位 可以有, 也可以没有可有一个也可有多个 通过“首部长度”确定报头有多长如果是两个四个字节长度就是两个选项三个四个字节长度就是三个选项以此类推 序号 由于会出现“后发先至”的情况所以需要通过编号区分出数据的先后顺序 序号表示的就是 TCP 数据报载荷中的第一个字节的序号由于序号是连续递增知道了第一个字节的序号后续每个字节的序号也就知道了
32 位/四字节表示的范围是 0~42亿9千万0~4G因为 TCP 是面向字节流的所以一个 TCP 数据报和下一个 TCP 数据报携带的数据是可以直接进行拼装的比如要传输一个特别大的数据传输过程中本身就会通过多个 TCP 数据报来进行携带这些 TCP 数据报彼此之间携带的载荷都是可以在接受方自动拼起来的 这样就不像 UDP 存在传输的上限使用 UDP 传输大数据就需要考虑调用这一次 send 操作参数是否超过了 64KB超过了就不行使用 TCP 的话就没关系可以调用一次 write也可以调用多次 write。无论怎么进行 write在网络传输和对端接收的角度来看是没有任何差别的如果多次 write传输的总数据量超过上述的 4G 也没关系这里的数据序号是可以再从 0 开始重新设置的
确认序号 确认序号的设定方式和后发先至中发短信的例子略有差别 TCP 序号不是按照“一条两条”来编排的而是按照“字节”来编排的
TCP 的确认序号这里填写的是 1001接收方收到的数据的最后一个字节序号的下一个序号 表示的含义是 1001 的序号的数据都收到了TCP 序号是连续增长的对于应答报文来说“确认序号”就会按照收到的数据的最后一个字节序号1 的方式来填写并且六个标志位中第二个标志位ACK会设为 1 普通报文的 ACK 为 0应答报文的 ACK 为 1如果是普通报文序号是有效的确认序号是无效的如果是应答报文序号和确认序号都是有效的应答报文的序号是另一套编号体系和传输数据的序号是不一样的应答报文默认情况下是不携带数据的